COPYRIGHT (C) 1984-2025 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES ALL
=========================MEMBER=CHANGE43================================
/* COPYRIGHT (C) 1984-2025 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG VERSION 43.01 was re-dated Apr 9, 2025 thru Change 43.020.
MXG VERSION 43.01 was dated Apr 1, 2025 thru Change 43.014.
REDATED MXG VERSION 42.42 was dated Jan 24, 2025, thru Change 42.105
ANNUAL MXG VERSION 42.42 was dated Jan 3, 2025, thru Change 42.101
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 43.01 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 43.01.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains old Technical Notes. many of which are still
valid, but the last was in 2018. Now, TECHNOTES and FLASHes are in
CHANGES/CHANGESS. which are also online.
Member CHANGES contains the changes made in this current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
CHANGESS and NEWSLTRS are also online at http://www.mxg.com,
========================================================================
I. MXG VERSION 43.01 RE-DATED Apr 9 2025, THRU CHANGE 43.020
==MAJOR CHANGES ADDED IN MXG 43.01, RE-DATED Apr 9, 2025 THRU 43.019.==
ERRORS CORRECTED
BUILDPD3 43.020 ERROR: Attempt to %GLOBAL a name (BUILDPDB).
ERROR ONLY IN BUILDPD3.
VMACBVIR 43.017 INPUT EXCEEDED BVIRTYPE=33 in History File record.
VMACIMS 43.010 MACRO _SIMS45 missing semicolon, 1375 vars IMS450FT.
VMXGRMFI 43.015 R71MAX list of variables corrected from MX to AV.
VMAC120 43.007 Undoc SMF 120 ST 100 ODM Offset, no ABEND, bad data.
NEW SUPPORT
VMAC115 43.003 Support for V933 MQ SMF 115 Subtype 216 TY115216.
VMAC119 43.001 Support for SMF 119 Subtype 11 Policy Segment
VMAC98 43.011 Support for Type 92 Subtype 1025 creates TYPE98JI.
VMAC30 43.013 Variable SMF30_RAXFLAG6 z/OS 3.1+ new description.
========================================================================
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M8 (9.4M8),
"M8", or with options VERSIONLONG;
"SAS 9.4 (9.04.01M8P080520)" on z/OS
9.4 (TS04.01M8P08052020)" on ASCII.
SAS V9.4 M8 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M6 or SAS Version 9.3 M0-M2.
SAS V9.4.M7 and M8 for ASCII execution require SAS HOT FIX 69871.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.128 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL B support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 causes JCLTEST9/TESSOTHR to ABEND, TOO MANY ARGUMENTS
FOR COUNTW() requires SAS Version 9.2 so 9.1.3 can NOT
safely be used for MXG. See CHANGE 41.046, Jun 21, 2023.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V9.1.3 SAS Problem Note 17038 Hot Fix is required for
DSNTYPE=LARGE.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But CONFIMXG is required for sites with NLS issues, and you must
use JCLCONFI to create/update the MXG.FORMATS catalog if you use
CONFIG='MXG.SOURCLIB(CONFIMXG)'.
For no NLS, you can use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 43.01 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 was STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 4.04 (04.04.01.00.005305 has been tested.
DO NOT USE 4.03.01 nor 4.04.00, INVALID CPU BUSY in TYPE70.
Error was introduced in 4.03.01 and 4.04.00. See Change 39.171.
Must be at 4.03.02.00.8569+ or 4.04.00.03.3277+/
WPS Version 4.01 USER 4037 ABEND, See Change 37.116.
WPS Version 4.0 reportedly fixed version 3 problems.
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
-Support for z/16 processor data.
MXG 38.07 or later is needed, but 40.01 will ABEND, see below
SMF: Only SMF 113 records were incompatibly changed, but there is no
execution error as only counter labels and values were changed,
causing coefficients for the calculated variables (RMI,etc) to
also be changed and default coefficients are changed to z/16,
You should use separate SAS steps for each processor type; MXG
will OUTPUT only the processor type you requested in //SYSIN,
and will skip other processor type records, so you do NOT need
to pre-process SMF records to select processor type. You will
want to rename one pair of datasets if you want to put them in
the same PDB Data Library.
For z/15 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11F %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
and for z/16 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11G %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
to get correct values in TYPE1131 and ASUM1131 datasets.
MXG Support for z/16 for SMF 113 requires 40.05 for z/OS and
40.03 for zVM.
MXG 40.01 will ABEND due to a TYPE30 error exposed by the z/16.
with z/OS 2.5 or APAR OA61511. You can correct by changing the
line 1812 in VMAC30 from 192 to 220, or ask support for the
current VMAC30 member with Change 40.050.
Many other SMF and Data Gatherer records were updated in 40.04.
RMF ASMRMFV processes RMF III data with no errors, Change 40.068
added some new fields. New DNG3 table support was in 40.05.
-Support for z/15 processor data.
The z/15 and z/15 T02 processors INCOMPATIBLY changed the SMF 113
records by inserting 32 new EXTEND and 4 CRYPTO counters, causing
ARRAY SIZE EXCEEDED with BUILDPDB which processes the SMF 113s.
Support for counter changes for both models was in MXG 37.08.
If you use MIPS in reports, the format $MGRMIPS provides the
MIPS/MSU value for each processor; the z15 values were updated
in MXG 37.08, and the z15 TO2 values were updated in MXG 38.04.
These MXG programs use $MGRMIPS: ASUMMIPS GRAFCEC GRAFWLM
GRAFWRKX and TYPERMFV (RMF III).
The z/14 also inserted SMF 113 fields, supported in MXG 36.07.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
And z/VM on the z15 requires MXG 38.02, PRCMFC/MFM COUNTERS caused
HARDWARE COUNTER messages, PRCMFC/PRCMFM no obs. Change 38.048.
The z13 processor INCOMPATIBLY CHANGED, the new SMT-MODE RMF 70, and
MXG 34.03 was REQUIRED (PCTCPUBY WRONG!), to read the SMT-format RMF
(which are written if you have zIIP engines AND have enabled the new
PROCVIEW CORE option for Multi-Threading, even if only one thread is
enabled).
SMF Back Levels: MXG 37.08 or later is required for both z15 & z/16
SMF 113 change, but those back level versions could fail due
to other records changed by subsystem updates you made for the
z/16 (e.g.CICS TS/6.1 which requires MXG 40.02) that didn't
exist when that back=level was created..
The new zEDC/EADM compression hardware requires MXG 38.05 to support
new metrics.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z/OS 2.4 Compatible from SMF Manual Sep 2019 37.166 37.07.
z/OS 2.4 Compatible from SMF Manual May 2020 38.105 38.05.
z/OS 2.4 Compatible from SMF Manual Apr 2021 39.075 39.03.
z/OS 2.4 Compatible RMF III PGMR Apr 1 2021 39.074 39.03.
z/OS 2.5 Compatible from SMF Aug 12,2021 39.06.
z/OS 2.5 Compatible RMF III Aug 12,2021 39.08.
z/OS 2.5 RMF III 4 new tables Aug 12,2021 39.08.
z/OS 2.5 Protects Possible New 72.3 fields (40.078) 40.04.
z/OS 3.1 Support in MXG 39.08 New vars in 41.05 CH 41.092.
z/OS 3.1 MXG 42.03 required for RMF III TYPERMFV CH 42.069
z/OS 3.1 Support is in MXG 41.05+ (42.03 for RMF III RMFV).:
Change 41.092 Support for z/OS 3.1 SMF Manual changes (COMPATIBLE).
VMAC26J2 We and several customers have tested z/OS 3.1 records
VMAC30 with back levels of MXG that support z/OS 2.5 (39.08)
VMAC7072 with no errors reported, and we expect no issues.
VMAC79 Change 41.096 added the new AI data in TYPE99 and
Oct 26, 2023 there were other APARs in 3.1, but we expect no issues.
New variables were added, see Change 41.092 full text.
This change was in MXG 41.05.
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
z15 New SMF 113 fields INCOMPAT Nov 18, 2020 37.08
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
z15 ANAL9914 Support CH 39.006 Jan 14, 2021 39.01
z/16 NEW SMF113 values, NO ABEND See CHANGE 40.070 40.03
z/16 MXG 38.07 OR LATER IS NEEDED. 38.07
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS/TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS/TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS/TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS/TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS/TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS/TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS/TS 3.2 Compressed Records Nov 3, 2007 25.11
CICS/TS 4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS/TS 4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS/TS 4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS/TS 4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS/TS 4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS/TS 5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS/TS 5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS/TS 5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS/TS 5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS/TS 5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS/TS 5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS/TS 5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS/TS 5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS/TS 5.3 GA date Dec 11, 2015 33.33
CICS/TS 5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS/TS 5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS/TS 5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS/TS 5.4 GA Jun 17, 2017 35.03
CICS/TS 5.5 GA (INCOMPAT) Jan 29, 2018 36.11
CICS/TS 5.6 GA (INCOMPAT) Jun 1, 2020 38.07
CICS/TS 5.6 NEW DATA (COMPAT) Oct 5, 2020 38.09
CICS/TS 6.1 ONE NEW (INCOMPAT) Jan 11, 2020 40.01
CICS/TS 6.1 ONE NEW (INCOMPAT) Sep 20, 2020 40.02
CICS/TS 6.1 UTILEXCL/IMACEXCL OK Aug 15, 2022 40.05
CICS/TS 6.1 VMAC110 NO IMACEXCL May 31, 2023 41.02
CICS/TS 6.2 INCOMPATIBLE BETA16 Sep 20, 2023 41.04
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
DB2 13.1 NEW DATA NO ERRORS Jan 2017 40.40
DB2 13.1 IDAA/NETEZZZ ONLY ABEND Mar 19, 2013 41.01
DB2 13.1 ABEND 41.06/41.41 102 Jan 12, 2024 42.01
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
z/VM 6.40061802 ABEND Jan 22, 2019 37.02
z/VM 7.1 INCOMPAT ABEND Feb 14, 2019 37.02
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
IMS log 15.4 NO CHANGES Mar 1, 2018 35.07
IMS log 15.4 Minor Chg 42.033 May 8, 2024 42.02
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA-BROADCOM
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2, 5.3, 5.4 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 42.42.
1. Incompatibilities introduced in MXG 42.42:
a. Changes in MXG architecture made between 42.42 and prior versions
that can introduce known incompatibilities.
IF YOU HAVE MEMBER E2TY70 IN YOUR USERID.TAILORING SOURCE LIBRARY,
YOU MUST CHANGE _LTY70 to _WTY70 in that member. CHANGE 38.105.
The error before this correction will be:
ERROR: DATA SET "PDB.TYPE70" was not specified on the DATA stmt.
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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 43.01:
Dataset/
Member Change Description
TECHNOTE 43.008 Don't Install MXG in a SAS Directory
VMAC115 43.003 Support for V933 MQ SMF 115 Subtype 216 new vars.
VMAC119 43.001 Support for SMF 119 Subtype 11 Policy Based TYP11911
VMAC120 43.007 Undoc SMF 120 ST 100 ODM Offset, no ABEND, bad data.
VMAC30 43.013 Variable SMF30_RAXFLAG6 z/OS 3.1+ new description.
VMAC98 43.011 Support for Type 92 Subtype 1025 creates TYPE98JI.
VMACBVIR 43.017 INPUT EXCEEDED BVIRTYPE=33 in History File record.
VMACIMS 43.010 MACRO _SIMS45 missing semicolon, 1375 vars IMS450FT.
VMXGRMFI 43.015 R71MAX list of variables corrected from MX to AV.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at https://www.mxg.com.
Inverse chronological list of all Changes in MXG Version 43.01.
.
NEXTCHANGE:
====== CHANGES THRU 43.020 ARE IN MXG 43.02 DATED Apr 9, 2025 ======
Change 43.020 ERROR: Attempt to %GLOBAL a name (BUILDINGPDB) which
BUILDPD3 exists in a local environment, BUILDPD3 ONLY, 42.42+
BUILDPDB Remove the %GLOBAL BUILDPDB; %LET BUILDPDB; statements
VMXGRMFI Move the %LET BUILDINGPDB statement from VMXGRMFI to
VMXGINIT the VMXGINIT member.
Thanks to Graham Cornwell,
Change 43.019 APAR OA62970 will set R744SLTM to zero, reporting that
VMAC74 it is unreliable and can not be accurately captured.
Apr 8, 2025 R744SLTM='MAXIMUM*LOCK TABLE*ENTRIES USED'
Change 43.018 -Dataset T102S254 new variables:
VMAC102 QW0254AR='DATA*AREA*RESIDENCY*TIME'
Mar 26, 2025 QW0254ER='DIRECTORY*ENTRY*RESIDENCY*TIME'
-Dataset T102S196 variable QW0196ET value corrected.
Thanks to Jan Tielemans, KBC, BELGIUM
Change 43.017 BVIR History File BVIRTYPE=33x has a short 64 byte last
VMACBVIR segment, now detected and only GCDTTRIN and GCDTTRFM are
Mar 26, 2025 are INPUT so GCLVMTOC and subsequent variables in BVIR331
dataset will be missing values in those observations, and
the INPUT STATEMENT EXCEEDED STOPOVER is avoided.
-New BVIRTYPE=36 record is not yet supported.
Thanks to Harald Seifert. HUK-COLBURG, GERMANY.
Thanks to Maria Paola Bramost, V-TServices.com
Change 43.016 SMF Record Type 105 has subtypes but the MVSXAFLG bit 1
VMACSMF that says a record has subtypes is not on so SUBTYPE=0
Mar 25, 2025 was set, impacting ANALID reports on SMF records, but
not impacting 105 processing as VMAC105 INPUT SUBTYPE.
ID=105 is added in _SMF to the INPUT for those IDs that
don't set the subtype bit: 42,103,105,108,119,120
Thanks to Scott Barry, SBBTechLLC, USA.
Change 43.015 The R71MAX= list of variables contained some variables
VMXGRMFI that did not have a MAX value; they were changed to use
Mar 24, 2025 the Average value. These are the changed variables:
CSFRSRAV CSFRWLAV CSFRFXAV CSFRLSAV CSFRTOAV CSFRAVMX
ESFRLSAV ESFRTOAV ESFRAVMX ESFRSRAV ESFRWLAV ESFRHSAV,
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND
====== CHANGES THRU 43.014 WERE IN MXG 43.01 DATED Apr 1, 2025 ======
Change 43.014 The maximum text length of an IPV4 IP address is $15
VMAC119 which is the length of most IPV4 variables in TYPE 119
Mar 19, 2025 datasets, where the $CHAR4 record field is converted to
text. However, four fields input as $16 were kept as $16
and that raised a conflict when datasets were merged.
The %VMXGIPV4 %macro is pervasive, changing it to $15
could create more serious errors. so the circumvention is
to use DATA TYP119xx;
LENGTH SMF119SC_SARIP $15 ;
SET PDB.TYP119xx;
if one of these variables is used in a MERGE
SMF119SC_SARIP SMF119SC_SALIP
S11912SASRVIP S11912SACLTIP
Thanks to Michael K Yuan, Navy Federal Credit Union, USA
Change 43.013 Variable SMF30_RAXFLAG6 new description RAX6*R2V*UNAUTH,
VMAC30 added in the z/OS Release after 3.1.
Mar 14, 2025
Change 43.012 Cosmetic Cleanup with no error. BASExxxx token is used
VMXGALOC to name the directory where output is written, but three
Mar 11, 2025 tokens, BASECICS, BASEDB2, and BASEMQ created directories
and set KEEP* when they were not used. Now the default
is to do nothing when they are not specified.
Thanks to Richard Way, Office Depot, USA.
Change 43.011 Support for Type 98 Subtype 1025 record creates new
EXTY98JI DDDDDD DATASET Description
VMAC98 TY98JI TYPE98JI IMS EXCEPTIONAL JOB LIST
VMXGINIT These datasets now contain both IMS and CICS SUBTYPEs
FORMATS TY98B1 TYPE98B1 CICS IMS BUCKET 1
Mar 10, 2025 TY98B2 TYPE98B2 CICS IMS BUCKET 2
TY98EX TYPE98EX CICS IMS EXCEPTIONAL INDEX
and this data set is unchanged
TY98JB TYPE98JB CICS EXCEPTIONAL JOB LIST
Thanks to Luxmi Gnanamuttu, TD, CANADA.
Thanks to Cornelio Navarro, TD, CANADA.
Thanks to Lynn Ly, TD, CANADA.
Change 43.010 The MACRO _SIMS45V was missing the ending semicolon in
VMACIMS line 1619 causing MACRO _VIMS45O to be undefined which
Feb 20, 2025 caused 1375 variables to be created in dataset IMS450FT.
Thanks to Bradley Leis, TELUS, CANADA.
Change 43.009 Cosmetic. MXG 42.42 replaced some average variables
VMXGRMFI with maximum value variables (xxxxxxAV to yyyyyyMX)
Feb 19, 2025 CSLPFXAV FIXEDAV FIXLOAV LPAFXAV LSQAFXAV PRVFXAV
PVTAFCAV SQAFXAV
but they were still in LABEL and LENGTH statements, so
those variables were created with missing values.
They are removed and no longer created.
Thanks to Piara Bhamra, Lloyds Banking Group, ENGLAND.
Change 43.008 We do NOT RECOMMEND Installing MXG in a "SAS" DIRECTORY,
TECHNOTE like SASHOME or WorldProgramming or their subdirectories
Feb 9, 2025 BECAUSE A NEW SAS INSTALL OR UPDATE could wipe out MXG
SOURCLIBs and ANY Tailored/Updated members you or your
predecessor might have made.
Change 43.007 SMF 120 Subtype 100 ODM Offset changed trashing values
VMAC120 but NOT causing an ABEND. No documenting of the change.
Feb 9, 2025
Thanks to Scott Barry, SBBTechLLC, USA.
CHANGE 43.006 Change 38.107 modified the allowable length of INCODE
ADOCABND from 32767 to 65535 but then checked it for LE 32767.
VMXGSUM Now checks for the value of 65535. Member ADOCABND was
Feb 6, 2025 updated to match the corrected error message
Change 42.005 VMXGALOC prints a critical error message on the log and
BLDSMPDB terminates processing if one or more LIBNAMEs could not
VMXGALOC be allocated. This change enhances the visibility of the
Feb 6, 2025 message and adds a new message to VMXGALOC when it is
not called by BUILDPDB
Change 43.004 SMF 113 calculation of MEMP for the z16 was wrong, and
ASUM113 caused large values for RNI, because the z15 equation was
VMAC113 used. Martin Packer's MEMLP and MEMRP variables were also
Feb 6, 2025 wrongly using the z15 equation.
Thanks to Michael Flessig, HUK-COBURG, GERMANY
Thanks to Jan Tielemans, KBC, BELGIUM
Change 43.003 Support for V933 MQ SMF 115 SUBTYPE 216 added 64 vars
VMAC115 to dataset TY1152216.
Feb 3, 2025
Thanks to Jan Tielemans, KBC, BELGIUM
Change 43.002 Typo in line 934 of BUILD005 of aPUN30_1= SUM(SPUN30_1
BUILD005 fortunately has no impact. While the count field is
Jan 30, 2025 not incremented, the spinning record is correctly output
and the count field in one of the other records for this
job will be used to determine the OKFLAG status.
Thanks to Bradley Leis, TELUS, CANADA.
Change 43.001 Dataset TYP11911 has four new variables added from
VMAC119 the new segment Subtype 11 'Policy Based Enforcement'
Jan 30, 2025 SMF119IPSECPOL='ZERT*IPSEC*POLICY*RULE*NAME'
SMF119TLSPOL ='ZERT*TLS*POLICY*RULE*NAME'
SMF119SSHPOL ='ZERT*SSH*POLICY*RULE*NAME'
SMF119NOPOL ='ZERT*NONE*POLICY*RULE*NAME'
Thanks to Douglas C. Walter, CITIGROUP, USA..
LASTCHANGE: Version 43.
=========================MEMBER=CHANGE42================================
/* COPYRIGHT (C) 1984-2025 MERRILL CONSULTANTS DALLAS TEXAS USA */
REDATED MXG VERSION 42.42 is dated Jan 24, 2025, thru Change 42.105
ANNUAL MXG VERSION 42.42 was dated Jan 3, 2025, thru Change 42.101
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 42.42 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 42.42.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains old Technical Notes. many of which are still
valid, but the last was in 2018. Now, TECHNOTES and FLASHes are in
CHANGES/CHANGESS. which are also online.
Member CHANGES contains the changes made in this current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
CHANGESS and NEWSLTRS are also online at http://www.mxg.com,
========================================================================
I. MXG VERSION 42.42 REDATED Jan 24, 2025, THRU CHANGE 42.105
==MAJOR CHANGES ADDED IN MXG 42.42, RE-DATED Jan 24, 2025 THRU 42.105.==
ERRORS CORRECTED
READDB2 42.105 Parm PACKAGE printed WARNINGS, did not use PACKAGE
UTILBLDP 42.104 Missing Parens cause sytax errors that cause ABEND
VMAC7072 42.102 Variable R725ENRC not input in TYPE725K/L/M datasets
NEW SUPPORT
ENHANCEMENT
VMACIMS 42.103 Variable DLOGRTKN added to IMS5050 Dataset.
==MAJOR CHANGES ADDED IN MXG 42.42, DATED Jan 3, 2025 THRU 42.101.====
ERRORS CORRECTED
VMACHSM 42.095 Datasets HSMDSRFU/HSMVSRFU only output first 13.
VMACATF 42.077 Omegamon IMSATF SUMMARY outputs all transactions
VMACHSM 42.095 HSM datasets HSMDSRFU and HSMFSRFU only outputted 13
WPS 42.092 WPS fails with character strings longer than 32767.
READDB2 42.089 READDB2 failed if PACKAGE= parameter was used.
NEW SUPPORT
VMAC98 42.097 Support for SMF 98 Subtypes 5,6,7 and 8.
VMAC82 42.090 Support Type 82 subtype 49 + new TAG datasets.
VMAC74 42.079 Support for APAR OA66017 Subtype 8 for DS8K.
VMAC102 42.076 Support for DB2 SMF 102 IFCID 499 populates T102S499
VMAC119 42.075 Support for new variables SMF 119 Subtype 2 TYP11902
VMACIMS 42.074 Support for IMS Log Record LCODE 45 STATTYPE 16.
ENHANCEMENT
SAGANAL 42.094 BOOST changes TYPE30 LOSU_SEC to maximum in family.
DODSCRDT 42.088 DODSCRDT selects INFILE records by creation date.
VMXG70PR 42.087 Clock "FALL BACK" needs one hour wait.
ANALMSUS 42.081 MIPS now calculated for all reports.
VMAC121 42.098 Some CPU varibles were not labeled or not formatted.
==MAJOR CHANGES ADDED IN MXG 42.03, DATED Sep 15, 2024 THRU 42.072.====
ERRORS CORRECTED
VMACRMFV 42.069 z/OS 3.1 ERROR Array Subscript out of range.
VMAC80A 42.052 TYPE80A INPUT EXCEEDED, long TOKXUGROUPS field.
VMAC119 42.049 Support for TYP11938 Subtype 38 dataset EXCEEDED.
VMAC102 42.054 SMF 102 IFCID 196 misaligned, IBM stored zero.
VMAC119 42.071 Correction to dataset TYP11906 & TYP11945 variables.
VMAC119 42.065 Only first segment SMF 119 Subtype 44 was output.
NEW SUPPORT
VMAC113 42.064 IBM changed z/16 RNI coeff from 4.3 to 4.1
VMAC7072 42.070 Support for Martin Packers Home Address blog post.
VMAC122A 42.037 Support SMF 122 Subtype 2 IBM Dependency.
VMAC1415 42.063 z/OS 3.1 new variables in TYPE1415.
VMAC30 42.062 Variables IOUNITS IOCOEFF MSOUNITS MSOCOEFF zeroed.
ENHANCEMENT
==MAJOR CHANGES ADDED IN MXG 42.02, DATED Jun 22, 2024 THRU 42.048.====
ERRORS CORRECTED
VMXG70PR 42.048 OBS count wrong in ASUMCEC, MSUHR Values wrong.
VMAC102 42.041 TYPE102 IFCID 365 INPUT EXCEEDED REDORD LENGTH.
VMAC82 42.042 CPU LOOP with SMF 82 SUBTYPE 40.SMF82_Tag increased
NEW SUPPORT
VMAC119 42.047 Support for new variables in TYP11912 TLS.
VMAC102 42.037 Support for new ZPARMS in T102S106
VMAC80A 42.025 Support for RACF APAR OA61951 PHRASEINT.
VMAC99 42.022 Support for APAR OA65652 new variables TYPE99Q2.
VMAC122A 42.037 Support SMF 122 Subtype 2 IBM Dependency.
VMAC80A 42.025 Support for APAR OA61951 RACF PHRASEINT
VMAC80A 42.038 Support for new Tokens TOKDBV2 and TOKOWNERS
ENHANCEMENT
VMAC119 42.045 ZERT TYP11912DN missing observations
==MAJOR CHANGES ADDED IN MXG 42.01, DATED MAR 15, 2024 THRU 42.022.====
ERRORS CORRECTED
VMAC102 42.001 Records with QWHSNSDA GT 4 had missing values.
UCICSCNT 42.002 Utility INPUT STATEMENT EXCEEDED CICS subtype 2.
VMAC102 42.001 Many Missing Values in Many TYPE102 datasets.
VMAC102 42.013 DB2 SMF 102 IFCID 172 INPUT EXCEEDED LENGTH ZERO
VMAC102 42.019 DB2 SMF 102 IFCID 365 INPUT EXCEEDED LENGTH ZERO
VMAC112 42.006 Omegamon for CICS ONDV SUPRA INPUT EXCEEDED.
VMAC119 42.017 ZERT SMF 119 Subtype 12 TYP1192SUM corrections
CICSIFUE 42.020 CICSIFUE Decompression U4038LE Abend with WPS.
ENHANCEMENT
ANAL115 42.004 Major overhaul of report/analysis member for MQ.
VMAC30 42.008 Support for APAR OA65055 TYPE30 JAVA CPU ZIP SU
VMAC99 42.009 Support for APAR OA65055 TYPE99SL JAVA CPU ZIP SU
VMAC99 42.022 Support for APAR OA65652 SMF 99 Subtype 2
VMACRACF 42.016 Support for RACF IRRDBU00 RACTYPE=0161 records.
VMXGSUM 42.007 New Parameter NOMXGECHO suppress print of parms.
========================================================================
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M8 (9.4M8),
"M8", or with options VERSIONLONG;
"SAS 9.4 (9.04.01M8P080520)" on z/OS
9.4 (TS04.01M8P08052020)" on ASCII.
SAS V9.4 M8 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M6 or SAS Version 9.3 M0-M2.
SAS V9.4.M7 and M8 for ASCII execution require SAS HOT FIX 69871.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.128 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL B support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 causes JCLTEST9/TESSOTHR to ABEND, TOO MANY ARGUMENTS
FOR COUNTW() requires SAS Version 9.2 so 9.1.3 can NOT
safely be used for MXG. See CHANGE 41.046, Jun 21, 2023.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V9.1.3 SAS Problem Note 17038 Hot Fix is required for
DSNTYPE=LARGE.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But CONFIMXG is required for sites with NLS issues, and you must
use JCLCONFI to create/update the MXG.FORMATS catalog if you use
CONFIG='MXG.SOURCLIB(CONFIMXG)'.
For no NLS, you can use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 42.42 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 was STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 4.04 (04.04.01.00.005305 has been tested.
DO NOT USE 4.03.01 nor 4.04.00, INVALID CPU BUSY in TYPE70.
Error was introduced in 4.03.01 and 4.04.00. See Change 39.171.
Must be at 4.03.02.00.8569+ or 4.04.00.03.3277+/
WPS Version 4.01 USER 4037 ABEND, See Change 37.116.
WPS Version 4.0 reportedly fixed version 3 problems.
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
-Support for z/16 processor data.
MXG 38.07 or later is needed, but 40.01 will ABEND, see below
SMF: Only SMF 113 records were incompatibly changed, but there is no
execution error as only counter labels and values were changed,
causing coefficients for the calculated variables (RMI,etc) to
also be changed and default coefficients are changed to z/16,
You should use separate SAS steps for each processor type; MXG
will OUTPUT only the processor type you requested in //SYSIN,
and will skip other processor type records, so you do NOT need
to pre-process SMF records to select processor type. You will
want to rename one pair of datasets if you want to put them in
the same PDB Data Library.
For z/15 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11F %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
and for z/16 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11G %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
to get correct values in TYPE1131 and ASUM1131 datasets.
MXG Support for z/16 for SMF 113 requires 40.05 for z/OS and
40.03 for zVM.
MXG 40.01 will ABEND due to a TYPE30 error exposed by the z/16.
with z/OS 2.5 or APAR OA61511. You can correct by changing the
line 1812 in VMAC30 from 192 to 220, or ask support for the
current VMAC30 member with Change 40.050.
Many other SMF and Data Gatherer records were updated in 40.04.
RMF ASMRMFV processes RMF III data with no errors, Change 40.068
added some new fields. New DNG3 table support was in 40.05.
-Support for z/15 processor data.
The z/15 and z/15 T02 processors INCOMPATIBLY changed the SMF 113
records by inserting 32 new EXTEND and 4 CRYPTO counters, causing
ARRAY SIZE EXCEEDED with BUILDPDB which processes the SMF 113s.
Support for counter changes for both models was in MXG 37.08.
If you use MIPS in reports, the format $MGRMIPS provides the
MIPS/MSU value for each processor; the z15 values were updated
in MXG 37.08, and the z15 TO2 values were updated in MXG 38.04.
These MXG programs use $MGRMIPS: ASUMMIPS GRAFCEC GRAFWLM
GRAFWRKX and TYPERMFV (RMF III).
The z/14 also inserted SMF 113 fields, supported in MXG 36.07.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
And z/VM on the z15 requires MXG 38.02, PRCMFC/MFM COUNTERS caused
HARDWARE COUNTER messages, PRCMFC/PRCMFM no obs. Change 38.048.
The z13 processor INCOMPATIBLY CHANGED, the new SMT-MODE RMF 70, and
MXG 34.03 was REQUIRED (PCTCPUBY WRONG!), to read the SMT-format RMF
(which are written if you have zIIP engines AND have enabled the new
PROCVIEW CORE option for Multi-Threading, even if only one thread is
enabled).
SMF Back Levels: MXG 37.08 or later is required for both z15 & z/16
SMF 113 change, but those back level versions could fail due
to other records changed by subsystem updates you made for the
z/16 (e.g.CICS TS/6.1 which requires MXG 40.02) that didn't
exist when that back=level was created..
The new zEDC/EADM compression hardware requires MXG 38.05 to support
new metrics.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z/OS 2.4 Compatible from SMF Manual Sep 2019 37.166 37.07.
z/OS 2.4 Compatible from SMF Manual May 2020 38.105 38.05.
z/OS 2.4 Compatible from SMF Manual Apr 2021 39.075 39.03.
z/OS 2.4 Compatible RMF III PGMR Apr 1 2021 39.074 39.03.
z/OS 2.5 Compatible from SMF Aug 12,2021 39.06.
z/OS 2.5 Compatible RMF III Aug 12,2021 39.08.
z/OS 2.5 RMF III 4 new tables Aug 12,2021 39.08.
z/OS 2.5 Protects Possible New 72.3 fields (40.078) 40.04.
z/OS 3.1 Support in MXG 39.08 New vars in 41.05 CH 41.092.
z/OS 3.1 MXG 42.03 required for RMF III TYPERMFV CH 42.069
z/OS 3.1 Support is in MXG 41.05+ (42.03 for RMF III RMFV).:
Change 41.092 Support for z/OS 3.1 SMF Manual changes (COMPATIBLE).
VMAC26J2 We and several customers have tested z/OS 3.1 records
VMAC30 with back levels of MXG that support z/OS 2.5 (39.08)
VMAC7072 with no errors reported, and we expect no issues.
VMAC79 Change 41.096 added the new AI data in TYPE99 and
Oct 26, 2023 there were other APARs in 3.1, but we expect no issues.
New variables were added, see Change 41.092 full text.
This change was in MXG 41.05.
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
z15 New SMF 113 fields INCOMPAT Nov 18, 2020 37.08
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
z15 ANAL9914 Support CH 39.006 Jan 14, 2021 39.01
z/16 NEW SMF113 values, NO ABEND See CHANGE 40.070 40.03
z/16 MXG 38.07 OR LATER IS NEEDED. 38.07
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS/TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS/TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS/TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS/TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS/TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS/TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS/TS 3.2 Compressed Records Nov 3, 2007 25.11
CICS/TS 4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS/TS 4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS/TS 4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS/TS 4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS/TS 4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS/TS 5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS/TS 5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS/TS 5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS/TS 5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS/TS 5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS/TS 5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS/TS 5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS/TS 5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS/TS 5.3 GA date Dec 11, 2015 33.33
CICS/TS 5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS/TS 5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS/TS 5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS/TS 5.4 GA Jun 17, 2017 35.03
CICS/TS 5.5 GA (INCOMPAT) Jan 29, 2018 36.11
CICS/TS 5.6 GA (INCOMPAT) Jun 1, 2020 38.07
CICS/TS 5.6 NEW DATA (COMPAT) Oct 5, 2020 38.09
CICS/TS 6.1 ONE NEW (INCOMPAT) Jan 11, 2020 40.01
CICS/TS 6.1 ONE NEW (INCOMPAT) Sep 20, 2020 40.02
CICS/TS 6.1 UTILEXCL/IMACEXCL OK Aug 15, 2022 40.05
CICS/TS 6.1 VMAC110 NO IMACEXCL May 31, 2023 41.02
CICS/TS 6.2 INCOMPATIBLE BETA16 Sep 20, 2023 41.04
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
DB2 13.1 NEW DATA NO ERRORS Jan 2017 40.40
DB2 13.1 IDAA/NETEZZZ ONLY ABEND Mar 19, 2013 41.01
DB2 13.1 ABEND 41.06/41.41 102 Jan 12, 2024 42.01
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
z/VM 6.40061802 ABEND Jan 22, 2019 37.02
z/VM 7.1 INCOMPAT ABEND Feb 14, 2019 37.02
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
IMS log 15.4 NO CHANGES Mar 1, 2018 35.07
IMS log 15.4 Minor Chg 42.033 May 8, 2024 42.02
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA-BROADCOM
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2, 5.3, 5.4 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 42.42.
1. Incompatibilities introduced in MXG 42.42:
a. Changes in MXG architecture made between 42.42 and prior versions
that can introduce known incompatibilities.
IF YOU HAVE MEMBER E2TY70 IN YOUR USERID.TAILORING SOURCE LIBRARY,
YOU MUST CHANGE _LTY70 to _WTY70 in that member. CHANGE 38.105.
The error before this correction will be:
ERROR: DATA SET "PDB.TYPE70" was not specified on the DATA stmt.
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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 42.42:
Dataset/
Member Change Description
ANAL115 42.004 Major overhaul of report/analysis member for MQ.
ANALMSUS 42.081 MIPS now calculated for all reports.
BUILDPDB 42.021 New variable MAXWKSET MAXIMUM*WORKING*SET added.
CICSIFUE 42.020 CICSIFUE Decompression U4038LE Abend with WPS.
DODSCRDT 42.088 DODSCRDT selects INFILE records by creation date.
READDB2 42.089 READDB2 failed if PACKAGE= parameter was used.
READDB2 42.105 Parameter Package did not select
SAGANAL 42.094 BOOST changes LOSU_SEC to maximum in family.
UCICSCNT 42.002 Utility INPUT STATEMENT EXCEEDED CICS subtype 2.
UTILBLDP 42.104 Missing Parens Syntax Error, %LEFT MACRO UNRESOLVED
VMAC102 42.001 Many Missing Values in Many TYPE102 datasets.
VMAC102 42.013 DB2 SMF 102 IFCID 172 INPUT EXCEEDED LENGTH ZERO
VMAC102 42.019 DB2 SMF 102 IFCID 365 INPUT EXCEEDED LENGTH ZERO
VMAC102 42.037 Support for new ZPARMS in T102S106
VMAC102 42.041 TYPE102 IFCID 365 INPUT EXCEEDED REDORD LENGTH.
VMAC102 42.054 SMF 102 IFCID 196 misaligned, IBM stored zero.
VMAC102 42.076 Support for DB2 SMF 102 IFCID 499 populates T102S499
VMAC112 42.006 Omegamon for CICS ONDV SUPRA INPUT EXCEEDED.
VMAC113 42.064 IBM changed z/16 RNI coeff from 4.3 to 4.1
VMAC119 42.017 ZERT SMF 119 Subtype 12 TYP1192SUM corrections
VMAC119 42.045 ZERT TYP11912DN missing observations
VMAC119 42.049 Support for TYP11938 Subtype 38 dataset EXCEEDED.
VMAC119 42.065 Only first segment SMF 119 Subtype 44 was output.
VMAC119 42.071 Correction to dataset TYP11906 & TYP11945 variables.
VMAC119 42.075 Support for new variables SMF 119 Subtype 2 TYP11902
VMAC122A 42.037 Support SMF 122 Subtype 2 IBM Dependency.
VMAC1415 42.063 z/OS 3.1 new variables in TYPE1415.
VMAC30 42.008 Support for APAR OA65055 TYPE30 JAVA CPU ZIP SU
VMAC30 42.062 Variables IOUNITS IOCOEFF MSOUNITS MSOCOEFF zeroed.
VMAC7072 42.070 Support for Martin Packers Home Address blog post.
VMAC7072 42.102 Datasets TYPE752K/TYPE752L/TYPE752M INPUT misaligned
VMAC74 42.079 Support for APAR OA66017 Subtype 8 for DS8K.
VMAC80A 42.025 Support for APAR OA61951 RACF PHRASEINT
VMAC80A 42.038 Support for new Tokens TOKDBV2 and TOKOWNERS
VMAC80A 42.052 TYPE80A INPUT EXCEEDED, long TOKXUGROUPS field.
VMAC82 42.042 CPU LOOP with SMF 82 SUBTYPE 40.SMF82_Tag increased
VMAC82 42.090 Support Type 82 subtype 49 + new TAG datasets.
VMAC98 42.097 Support for SMF 98 Subtypes 5,6,7 and 8.
VMAC99 42.009 Support for APAR OA65055 TYPE99SL JAVA CPU ZIP SU
VMAC99 42.022 Support for APAR OA65652 SMF 99 Subtype 2
VMACATF 42.077 Omegamon IMSATF SUMMARY outputs all transactions
VMACHSM 42.095 HSM datasets HSMDSRFU and HSMFSRFU only outputted 13
VMACIMS 42.074 Support for IMS Log Record LCODE 45 STATTYPE 16.
VMACRACF 42.016 Support for RACF IRRDBU00 RACTYPE=0161 records.
VMACRMFV 42.069 z/.OS 3.1 ERROR Array Subscript out of range.
VMXG70PR 42.048 OBS count wrong in ASUMCEC, MSU Values wrong.
VMXG70PR 42.087 Clock "FALL BACK" needs one hour wait.
VMXGSUM 42.007 New Parameter NOMXGECHO suppress print of parms.
WPS 42.092 WPS fails with character strings longer than 32767.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at https://www.mxg.com.
Inverse chronological list of all Changes in MXG Version 42.42
.
NEXTCHANGE:
====== CHANGES THRU 42,105 ARE IN MXG 42.42 RE-DATED Jan 24, 2025 ======
Change 42.105 Parameter PACKAGE printed WARNINGS after Change 42.089
READDB2 and did not select on Package, but did not ABEND. Line .
Jan 13, 2025 1652 was changed to %PACKAGE instead of &PACKAGE.
Thanks to Matthew T. Chappell, Queenslad Transport, AUSTRALIA
Change 42.104 -First 42.42 UTILBLDP SYNTAX ERROR due to missing parens.
UTILBLDP ERROR, so far at only one site. Change lines 899-900 to
Jan 24, 2025 %LET USERADD=%SYSFUNC(COMPBL(%STR(&PART1) ID));
%LET MACFILEX=%SYSFUNC(COMPBL(_CDEID MACFILEX));
-ERROR UNRESOLVED MACRO LEFT or CMPRES or TRIM can occur
if you do not have a SASAUTOS call in CONFIGxx/AUTOEXEC
from the MXG examples. In first 42.42, %LEFT and %CMPRES
were added in UTILBLDP and %LEFT in READDB2; %LEFT was
removed by this change but %CMPRES couldn't be replaced.
Also, members VMXGALOC VGETALOC ANALWHO all use %CMPRES
so restoring the SASAUTOS call is the only correction.
SASAUTOS=(SOURCLIB SASAUTOS) in CONFIGxx or in AUTOEXEx
OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS)
Only one site has reported the missing SASAUTOS error.
-An unrelated exposure was circumvented in this change:
%UTILBLDP would fail if your MACyyyyX= or USERADD= code
exceeded the 32K limit on Character variable size. The
logic was changed to use a macro string variable which
has a 64K limit.
Thanks to Douglas C. Walter, CITIGROUP, USA..
Change 42.103 Variable DLOGRTKN, RECOVERY TOKEN, was added to IMS5050
VMACIMS dataset.
Jan 8, 2025
Thanks to Camilo Lopez Calderon, ITNow, SPAIN.
Change 42.102 Datasets TYPE752K, TYPE752L, TYPE752M failed to INPUT the
VMAC7072 variable R725ENRC, causing misalignment and wrong values
Jan 8, 2025 in R725ENSU/R725ENTI/R725ENS1/R725ENS2.
Thanks to Jan Tielemans, KBC, BELGIUM
====== CHANGES THRU 42.101 ARE IN MXG 42.42 DATED Jan 3, 2025 =========
Change 42.101 Line 2339 had double slash // at end of the line, which
VMAC119 caused the INPUT statement to move to the next line which
Jan 2, 2025 misaligned the input of subsequent variables in dataset
TYP11901. There was no execution error, only this NOTE:
NOTE: Invalid argument to function INPUT _ERROR=1.
except that if the next SMF record was an ID=3, which is
only 14 bytes long, an Input Record Was Not Long Enough
caused a STOPOVER ABEND. Since ERRORABEND is in effect, I
would have thought that _ERROR_=1 would have caused that
ABEND, but there is an obscure note that says ERRORABEND
is not honored for any Invalid Data type errors!
Thanks to Declan Vibert, Altair, ENGLAND.
Thanks to James McCubbin, Altair, ENGLAND.
Change 42.100 MXGWARN messages about FMTSEARCH added by Change 42.046
VMXGINIT were removed but the test for the existence or back level
Jan 2, 2025 of the FORMATS library remain.
Thanks to Joe McCann, PennMutual, USA.
Change 42.099 Further updates for Omegamon IMSATF SUMMARY records.
VMACATF
Dec 31, 2024
Thanks to Donald Cleveland, Elevance Health, USA.
Change 42.098 Some CPU variables were not labeled or not formatted.
EXTY121
Dec 30, 2024
Change 42.097 Support for Type 98 subtype 5 6 7 8 creates 12 datasets
EXTY985A TYPE98A ENHANCED READ BUCKET
EXTY985B TYPE98B ENHANCED READ JOBINDEX
EXTY985C TYPE98C ENHANCED READ JOB LIST
EXTY985A TYPE98A BASIC READ BUCKET
EXTY985B TYPE98B BASIC READ JOBINDEX
EXTY985C TYPE98C BASIC READ JOBLIST
EXTY985A TYPE98A ENHANCED WRITE BUCKET
EXTY985B TYPE98B ENHANCED WRITE JOBINDEX
EXTY985C TYPE98C ENHANCED WRITE JOB LIST
EXTY985A TYPE98A BASIC WRITE BUCKET
EXTY985B TYPE98B BASIC WRITE JOBINDEX
EXTY985C TYPE98C BASIC WRITE JOBLIST
FORMATS
VMAC98
Dec 27, 2024
Thanks to Craig S Bigler, Progressive, USA
Thanks to Ann Knapik, Progressive, USA
Change 42.096 Dataset TYPE11912TLS variable S11912SS_TLS_NET_CIPHER
FORMATS FORMAT $MG119CF expected '4040'x for the last two chars
Dec 17, 2024 but the data has '0000'x, format revised for both.
Thanks to Jan Tielemans, KBC, BELGIUM
Change 42.095 HSM datasets HSMDSRFU and HSMVSRFU only outputted the
TYPEHSM the first 13 function values, although $MGHSMFU format
Dec 12, 2024 decoded these additional types, they were not output.
14='14:VOL OR DS RESTORE'
15='15:ABACKUP FUNCTION'
16='16:ARECOVER FUNCTION'
17='17:EXPIRE PRI OR MIGRATED DATA SET'
18='18:PARTIAL RELEASE FUNCTION'
19='19:EXPIRE OR ROLL OFF INCREMENTAL BACKUP'
20='20:(H)BDELETE INCREMENTAL BACKUP'
21='21:FAST REPLICATION BACKUP FUNCTION'
22='22:FAST REPLICATION RECOVER FUNCTION'
23='23:FAST REPLICATION DELETE FUNCTION'
24='24:CLASS TRANSITION'
25='25:MIGRATION TO CLOUD'
26='26:RECALL FROM CLOUD'
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 42.094 The SAGANAL program uses SMF 30 Intervals to track the
SAGANAL hourly MSU of the four SAS work types, but suddenly the
Dec 8, 2024 MSU Values were extremely small, because IBM raises
intervals when BOOST is active, to the value of the
fastest processor in that family. For a 8562 D04 with
normal LOSU_SEC of 6950, IBM changes the LOSU_SEC value
from 6950 to 88218.
To support multiple processors with different LOSU_SEC
values the program normalizes the CPUTM in the 30s to the
speed of the fastest processor, using the ratio of each
system's LOSU_SEC to the maximum value, MAXSUFACT, as
documented in this note in SAGANAL
CALCULATION OF MSU FROM SMF 30S FOR SAG.
THE RECORDED CPUTM FOR AN INTERVAL IS MULTIPLIED BY THE
RATIO OF THIS SYSTEM'S SPEED LOSU_SEC DIVIDED BY THE
MAXSUFACT TO NORMALIZE THE CPU TIME TO THE SPEED OF THE
FASTEST MACHINE, AND THEN THAT NORMALIZED CPUTM IS
MULTIPLIED BY SMF70CPA, THE CEC'S SU_SEC, TO GET THE MSU.
The equation used to normalize the CPUTM is
IF MAXSUFACT GT 0 AND LOSU_SEC GT 0 THEN
CPUTM=FLOOR(100*CPUTM*LOSU_SEC/MAXSUFACT)/100;
IF ONLY ONE SYSTEM'S DATA IS SELECTED, THE LOSU_SEC AND
MAXSUSEC ARE THE SAME, SO THE CPUTM IS UNCHANGED, AND THE
MSU CALCULATION IS THE SAME.
WHEN THERE ARE MULTIPLE SYSTEMS, EACH CPUTM IS NORMALIZED
TO THE FASTEST MACHINE ON THE CEC, SO THOSE SLOWER
MACHINES WILL HAVE THEIR CPU TIME REDUCED WHEN LOSU_SEC
IS LESS THAN MAXSUSEC. THE REDUCED CPUTM WILL THEN BE
MULTIPLIED BY SMF70CPA TO GET THE (SMALLER) MSU FOR THAT
SYSTEM.
MAXSUFACT=88218
LOSU_SEC=6950
6950/88218=.078
SMF70CPA=4722
A SYSTEM with an hour interval with 3600 seconds of CPUTM
(frequently true for ADABAS) has an hourly SYSTEM MSU of
3600*4722=17 MSU per engine, so with 4 engines the hourly
CECMSU HAS 17*4=68 MSU which is exactly the hourly value
in CECMSU capacity in the SMF record. But when
Normalized, with the 88218 maximum value, that 68 MSU CEC
CAPACITY is only 5.3!
The solution is to delete those intervals when BOOST is
active as they not only corrupt the MSU values, they are
not representative of normal system values, using
IF BOOSTACTIVE GT 0 THEN DELETE;
Change 42.093 -If you used RMFINTRV or VMXGRMFI with PDB=SMF, the input
VMXGRMFI SMF file was read twice. Now it doesn't.
BUILDPDB -Added an example of testing a new RMFINTRV member.
BUILDPD3 -For protection, macro variable BUILDINGPDB=YES is added
Dec 6, 2024 to the two BUILDPDx members, to prevent second read.
Change 42,092 WPS fails with character strings longer than 32767 bytes
UTILBLDP when using SYSFUNC(COMPBL... Corrected using %LEFT from
BLDSMPDB SASAUTOS. .
Jan 24. 2025. See Change 42.003 which removed %LEFTS
Dec 6, 2024
Change 42.091 Dataset T102S196 variables QWn196HL, UOWID, contained
VMAC102 unexpected hex values that distorted PROC PRINT output.
Nov 19, 2024 Replaced by QWn196HL1 and QWn196HL2 variables..
Change 42.090 Support for Type 82 subtype 49 updated TYPE82AU dataset
EXTY8291 created TYPE8249 for COMPLIANCE and created five new
EXTY8293 datasets to support duplicated tags.
EXTY8294 TAG DATASET
EXTY8295 0201 TYPE8291
EXTY8297 0213 TYPE8293
FORMATS 0214 TYPE8294
VMAC82 0205 TYPE8295
VMXGINIT 0206 TYPE8295
Dec 12, 2024 0207 TYPE8297
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 42.089 If you tried to use PACKAGE= parameter it failed with a
READDB2 macro error. Problem was fixed and examples added to doc
Nov 9, 2024 in the member.
Thanks to Kammara Bheema Linga Prasad, Allstate, USA.
Change 42.088 DODSCRDT lets you select INFILE records to be selected
DODSCRDT based on the creation date of the z/OS file. An example
Nov 1, 2024 %INCLUDE was added to the commented execution example.
Change 42.087 If you did not wait an hour after rolling the clocks
TECHNOTE back you would get NOT SORTED errors on CPS70PR8 and
VMXG70PR CPS70PRA because GMTOFFTM was not in the BY list.
Nov 8, 2024
When you change clocks for DST or back to standard
time there can be anomalies in the data. In the
spring there will be a hole in the data - an hour
will be missing and sometimes will be longer than
expected for jobs steps that were running at the
time you moved the clock. In the fall any datasets
that are summarized by Tod will have an hour that
will be twice what is normal unless you quiesce
the system for an hour.
Thanks to Gregory Rudder, Shelter Insurance, USA.
Change 42.086 Skipped Change Number
Nov 12, 2024
Change 42.085 -Expand RMFBSAM LRECL support to 16K-1 (16777215) bytes
VMACRMFV -Add support for data conversion of table formats to/from
Dec 24, 2024 versions with new field to document the prior to
conversion version identifier, The following tables
were affected:
ASIG3, CATG3, CFIG3, CPCDB, CPDG3, CPUG3, CPUDB,
CRYG3, CSRG3, DVTG3, ENCG3, ENTG3, GEIG3, IQDG3,
LOKG3, OPDG3, PCIG3, RCDG3, SCMG3, SCMCM, SCMDI,
SPGG3, SSHG3, SVPG3, LOKG3, XCFG3, ZXFG3
Change 42.084 Value of 11 was added to MGSARTY format for variable
FORMATS variable SMFVOTYP in multiple SARRUnn datasets.
Oct 28, 2024
Thanks to Steven W. Erkkila, USBANK, USA.
Change 42.083 Support for IMS LCODE=50x Log Record creates IMS5050
EXIMS550 dataset.
FORMATS
VMACIMS
VMXGINIT
NOV 5, 2024
Change 42.082 Values of 7 and 11 were added to MG0748L format for
FORMATS variable R748LTYP in dataset TYPE748L.
Oct 23, 2024
Change 42.081 MIPS now added to all reports.
ANALMSUS
Oct 12, 2024
Change 42.080 Variable TISTATUS created in dataset TYPE11901
VMAC119 TISTATUS /*TCP*SOCKET*STATUS*S=SERVER*C=CLIENT*/
Oct 14, 2024
Change 42.079 Support for APAR OA66017 for TYPE74 Subtype 8 for DS8K
VMAC74 storage systems compression statistics. This coding adds
Oct 7, 2024 these variables to dataset TYPE748X:
R748CMPX='COMPRESSION*EXTENT*POOL'
R748SZVL='VALID*EXTENT*SIZES'
R748XEPS='EXTENT*SIZES IN*EXTENT POOL'
R748XTLC='TOTAL*LOGICAL*CAPACITY'
R748XTPC='TOTAL*PHYSICAL*CAPACITY'
R748XULC='USED*LOGICAL*CAPACITY'
R748XUPC='USED*PHYSICAL*CAPACITY'
and this variable to TYPE748A:
R748AAS6='DDM CLASS*COMPRESSED'
Change 42.078 -TYPE8231 variables STARTED and ENDED were not converted
VMAC82 to local time zone. The type 82 records do not provide
Oct 3, 2024 a GMT Offset variable, one has to compare the SMFTIME and
hope there is an "ending" time TODSTAMP variable to use
to calculate the offset. Variable SMF82SXT in TYPE8221
and SMF82AUD_JOB_ENTRY_DATETIME in TYPE82AU have no end
time variable, so GMT is added to the variable's label.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 42.077 Revised support for Omegamon IMSATF SUMMARY records now
VMACATF outputs all transactions. The original 2015 MXG support
Oct 1, 2024 found one transaction per record, with no clue that there
could be multiple transactions i.e. no count field so MXG
only output the first transaction in each record. That no
MXG User noticed suggests no one was ever using these ATF
log records.
Thanks to Donald Cleveland, Elevance Health, USA.
Thanks to Vitali Mints, Rocket Software, USA.
Thanks to John Bubenheim,IBM,USA.
Change 42.076 Support for DB2 SMF 102 IFCID 499 populates T102S499.
FORMATS
VMAC102
Sep 27, 2024
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND
Change 42.075 Support for new variables in SMF 119 Subtype 2 TYP11902
FORMATS TTSMCREASON='SMC-R*LINK*FAILURE*REASON*CODE'
VMAC119 TTXRT32='RETRANSMISSIONS*REQUIRED*/
SEP 29, 2024 TTSMCDREASON='SMC-D*LINK*FAILURE*REASON*CODE'
TTSMCDEID='SMC-DV2*ENTERPRISE*ID'/
TTSMCFLAGS='SMC-R*FLAG'
TTSMCDSTATUS='SMC-D*LINK*STATUS'
TTSMCFLAG2='TTSMCVERSION'
TTTTLSSESSIDLEN='AT-TLS*SESSION*ID*LENGTH'
TTTTLSSESSID='AT-TLS*SESSION*ID'/
TTTTLSSRU='SSL*SESSION*REUSE'
TTTTLSNKS='AT-TLS*NEGOTIATED*KEY*SHARE'
-FORMAT $MG119RX-TTSMCREASON and $MG119RY for TTSMCDREASON
HAVE OTHER NON-ZERO REASON CODE VALUES:
INTERNAL ERROR, IF SMF119AP_TTSMCRSNRMT (X'80') BIT .
BIT IS OFF IN SMF119AP_TTSMCFLAGS.
REMOTE PEER SET VALUE, IF SMF119AP_TTSMCRSNRMT (X'80')
BIT IS ON IN SMF119AP_TTSMCFLAGS.
SEE THE DOCUMENTATION OF THE PEER PRODUCT FOR MORE INFON.
Thanks to Richard Davey, Bank of America, USA.
Change 42.074 Support for IMS Log Records LCODE 45 STATTYPE 16 creates
EXIMS45S four new datasets with Fast Path Buffer Pool statistics:
EXIMS45T DDDDDD DATASET Eye Catcher Description
EXIMS45U IMS45S IMS45162 DBFBPNO2 FPBM GLOBAL STATISTICS
EXIMS45V IMS45T IMS45163 DBFBPNO3 FP SUBPOOL STATISTICS
FORMATS IMS45U IMS45164 DBFBPNO4 FP SUBPOOL EXTENT STATS
VMACIMS IMS45V IMS45165 DBFBPNO9 FP BUFFER STATISTICS
VMXGINIT
Sep 24, 2024
Thanks to Kurt Gramling, TSYS, USA
Change 42.073 UNUSED CHANGE NUMBER.
Sep 19, 2024
====== CHANGES THRU 42.072 ARE IN MXG 42.03 DATED Sep 15, 2024 =========
Change 42.072 You can now send MQ data to a separate database with
BLDSMPDB different numbers of pseudo-GDGs on ASCII.
VMXGALOC To use you must either use the reroutex options in
Sep 13, 2024 BLDSMPDB or override the _L****** macro in MACKEEP.
Change 42.071 -Dataset TYP11906 variables IFINBITRT/IFOUBITRT/IFBITRATE
VMAC119 could have missing values because they were calculated
Sep 6, 2024 before DURATM had been correctly populated from IFDURTM.
-Dataset TYP11945 variable DM_ISDURATION incorrectly input
as datetime instead of duration.
Thanks to Karl Lasecki,CAS, USA.
Change 42.070 -Support for Martin Packer's RMF Processing Home Address
VMAC7072 Fields in his blog https://mainframeperformancetopics.com
VMAC74 /2024/06/14/engineering-part-7-rmf-processor-home-address
Aug 31, 2024 fields/
Sep 26, 2024 -Dataset TYPE74CF from SMF 74 Subtype 4 Segment PO:
Labels added for CFPBGS01-16 and CFPCCT01-16.
Numeric variables CFPTLE01-16 are set to missing values;
they were incorrectly created as numeric variables and
are replaced by $HEX32 Character variables CFPTLECH01-16
-Dataset TYPE70PR from SMF 70 Logical Processor Section
Labels for SMF70CORTn which should have been SMF70CORDn
provide additional decoding of their contents.
SMF70CORT1='DISPATCH*LOC*TOPO NESTING*LEVEL1*ZERO'
SMF70CORT2='DISPATCH*LOC*TOPO NESTING*LEVEL2*CHIP'
SMF70CORT3='DISPATCH*LOC*TOPO NESTING*LEVEL3*DCM'
SMF70CORT4='DISPATCH*LOC*TOPO NESTING*LEVEL4*DRAWER'
SMF70CORT5='DISPATCH*LOC*TOPO NESTING*LEVEL5*ZERO'
SMF70CORT6='DISPATCH*LOC*TOPO NESTING*LEVEL6*ZERO'
-Format MG070NL for SMF70MAXNL='MAXIMUM*TOPOLOGY*NESTING'
decodes these values:
0='0:NO INFORMATION'
1='1:NO NESTING STRUCTURE'
2='2:NESTING LEVELS AVAILABLE'
3='3:NESTING LEVELS AVAILABLE'
4='4:NESTING LEVELS AVAILABLE'
5='5:NESTING LEVELS AVAILABLE'
6='6:NESTING LEVELS AVAILABLE'
-Martin also added these technical notes:
If you see non-zero L4RP or MEMRP numbers in SMF 113
don't be alarmed now, it's just a spring clean ??
er um it's quite normal because there are things that
have nothing to do with LPAR cross-drawer activity.
There are several benign causes, but if the values in.
L4RP or MEMRP become significant that's a different.
matter, and, as always, things like CPI - preferably at
the engine level - help tell the story. And you can
pretty much ignore home address for VL processors,
especially if 70-1 says they are parked.
Thanks to Martin Packer,IBM, UK.
Change 42.069 VMACRMFV experiencing two issues with zoS 3.1
VMACRMFV -ERROR: Array subscript out of range at line 22512
Aug 26, 2024 -Incorrect navigation to service/report class data zos 3.1
Oct 10, 2024 Failing instruction (ACTTIME=RTSTHR) occurs when all
buckets in RCDDEN are zero and the DO loop sweeping the
array exits with the implied array element pointer left
at 15 (beyond the array boundary).
With 3.1 the Resource collection data entry added
RCDSRVFLG and a two byte reserved field that triggered
mis-aligning the class data input statement. Navigation
to the class data now makes use of the RCDSCOF/RCDRCOF
plus RCDCLX fields to locate the class data.
NOTE:Changed VMACRMFV was not in MXG 42.03 library..
It was moved to master source library Oct 10, 2024.
Thanks to Kurt Gramling, TSYS, USA.
Change 42.068 Variable RACF263 path name has been increased to maximum
VMAC80A length 1024 from the arbitrary length 255 definition of
Aug 21, 2024 the pathname.
Thanks to David Obernoder, DATEV eG, GERMANY.
Change 42.067 -Corrections/additions in TYP11938 Subtype 38 dataset.
VMAC119 Only first segment was output, is corrected.
Aug 17, 2024 Variable DM_LSDURATION formatted TIME12.2..
Variable DM_LSPNETID was not Kept.
Two new variables added.
DM_LSRMTHOSTNAME.
DM_LSEID ='SMC-D*ENTERISE*ID*EID'
Variables input as $CHAR format $HEX corrections
DM_LSLCLGID DM_LSRMTGID $HEX16.
Thanks to Karl Lasecki,CAS, USA.
Change 42.066 The label for IECZSTC3='ZSORT*PH1*TCB TIME is corrected
VMAC16 to 'ZSORT*PH3*TCB TIME'.
Aug 7, 2024
Thanks to John Donoghue, AIB, IRELAND>
Change 42.065 Only the first segment of SMF 119 Subtype 44 was output..
VMAC119
Aug 5, 2024
Thanks to Svend Zaunick, F-I, GERMANY.
Thanks to Fynn Schoelzel, F-I, GERMANY.
Change 42.064 IBM Changed the z/16 coefficient for RNI from 4.3 to 4.1.
ASUM113 Doc is at https://www.ibm.com/support/pages/node/6354583.
VMAC113
Aug 5, 2024
Thanks to John Burg, IBM, USA.
Change 42.063 Updates in z/OS 3.1 SMF Manual dated Jul 23, 2024;
TYPE1415 -TYPE1415 new variables
Jul 29, 2024 DSENCRYP='DSENCRYP*TOK'
DSENHKEY='DSENCARC*HKEY'
DSENCREJ='DSENCREJ'
-TYPE99Q2 Support for APAR OA65652 added by Change 42.022.
Change 42.062 Variables IOUNITS IOCOEFF MSOUNITS MSOCOEFF are zero.in
TYPE30 TYPE30xx and TYPE72GO datasets starting in z/OS 2.5/3.1.
TYPE7072 IBM fields R723CIOC R723MIOC R723CMSO R723MMSO are listed
Jul 29, 2024 "always zero" in the SMF Manual for 2.5 dated May 24,2022
and SMF03LOC SMF30MSC coefficients are "always zero" in
the SMF manual for z/OS 3.1 dated Apr 19, 2024. And the
variable EXCPRMF in TYPE30xx is also zero as it was based
on IOUNITS. I've not found any IBM notes on when/why.
Change 42.061 Variables SMF70PMU='AVG BLKED*DISPATCH*UNITS*PROMOTED' in
TYPE7072 dataset TYPE70 was incorrectly calculated.
Jul 24, 2024
Thanks to Jan Tielemans, KBC, BELGIUM
Change 42.060 MXG TYPExxxx members normally output dataset to WORK,
TYPE99 while TYPSxxxx members sort and output to PDB, but if all
Jul 18, 2024 dataset's have accumulated data, the _Sxxxx Product Sort
macro is added in the TYPExxxx member, or if only some of
the datasets are accumulated, the _Sdddddd Data Set Sort
macro is added so that the DIF() functions are invoked to
deaccumulate and output the correct data to PDB.
These SMF datasets have accumulated data:
all datasets 99 103 113 79
some datasets MQM NPM TPX WECR.
The _S99 was missing in MXG 42.01 and 42.02 in TYPE99.
Thanks to Keith C. Shaffer, Evernorth, USA.
Thanks to Altino Pimentel, Evernorth, USA.
Change 42.059 Dataset ASUM70GL the Group Capacity LPAR detail, variable
VMXG70PR MINENTIT, the Minimum Entitlement of an LPAR in a
Jul 17, 2024 capacity group, was incorrectly calculated as the LPARs
group weighted share of the total complex MSU (which,
among other things, is greater than the complex weighted
share of the total complex MSUs). MINENTIT incorrectly
was greater than the MAXENTIT.
Thanks to Matthew T. Chappell, Queensland Government, AUSTRALIA
Change 42.058 New variables added to DCOLLECT DCOLMIGS Data Set
VMACDCOL UM_CLOUD_NAME_LENGTH='CLOUD*CONNECTION*NAME*LENGTH'
Jul 16, 2024 UM_CLOUD_NAME='CLOUD*NETWORK*CONNECTION*NAME'
UM_CONTAINER_NAME='CLOUD*NETWORK*CONNECTION*NAME'
UM_OBJ_NUMBER= 'NUMBER*OF OBJECTS*STORED'
UM_CLD_COMP_PERCENT='PERCENT*SAVED BY*TCT COMPRESSION'
Thanks to Raj C. Xavier, FMR, USA.
Thanks to Kulvinder Makkar,FMR,USA.
Change 42.057 If you run CICINTRV and look at the log you would see a
UTILDUR bogus MXGWARN message. It can be ignored as it is a
VMXGCICI result of VMXGSUM printing the code it generates. UTILDUR
Jul 15, 2024 now checks the durations in the data and if it is larger
than the requested interval produces an MXGWARN message.
Thanks to John Roderick, DC GOV, USA.
Change 42,056 Example 4 failed. Doc was corrected and member
UTILBLDP TYPEJOBS was created.
TYPEJOBS
JCLPDBJB
Jul 4, 2024
Change 42.055 New variables added to ASUM1131 dataset by Martin show
ASUM113 the components of MEMP, the Percent Sourced from Memory:
VMAC113 MEMLP ='PERCENT*SOURCED*SAME*DRAWER'
Jul 4, 2024 MEMRP ='PERCENT*SOURCED*OTHER*DRAWER'
The calculations are for z/16 and exposed MXG values for
MEMP used the z/15 equations.
Thanks to Michael Fleissig, Huk-Coburg, Germany
Thanks to Martin Packer, IBM, ENGLAND.
Change 42.054 SMF 102 IFCID 196 dataset T102S196 was misaligned because
VMAC102 the undocumented IBM change to store zero in the triplet
Jul 3, 2024 length field and store the length value in the first two
bytes of the segment was not correctly handled in MXG.
Thanks to James Lieser, Optum, USA.
Thanks to Peter Vikeras, Optum,USA
Change 42.053 If you used SPINSTC, you could get 0 obs in pdb.jobs
BUILD005 because of faulty logic. The code checked the value of
BUIL3005 SPINSTC and entered a DO loop that then checked the
Jul 4, 2024 typetask for STC and prevented the ELSE DO from
being executed and setting OKFLAG from being set to 1
which causes jobs to be output. The check for STC was
added to check for SPINSTC and ELSE DO removed.
Thanks to Shivang Sharma,ENSONO, USA.
Thanks to Dana A Mccreary, UPS, USA
Thanks to Arnold Kim, UPS, USA.
Thanks to D. Barry, UPS, USA.
Change 42.052 -TYPE80A INPUT EXCEEDED due to unexpected short length 7
VMAC80A for TOKXUGROUPS field, now using $VARYING INFORMAT.
Jun 29, 2024 -Support for TYPE80Z TOKXRGROUPS field also using VARYING.
Thanks to Swapna Gavini, Kyndryl, AUSTRALIA.
Change 42.051 Utility program IMACDSCK finds all DSNAMES.is enhanced to
EXDCODSN look at datasets created by DCOLLECT.
EXDCOCLU
EXDCOMIG
EXDCOBKP
IMACDSCK
Jun 28, 2024
Thanks to Scott Barry, SBBTechLLC, USA.
Change 42.050 Format $MGCICDS for variables SMDDSAIN in dataset CICSMD
FORMATS and variable SMSDSAIN in dataset CICSMDSA values 0Ax-0Dx.
Jun 25, 2024 were added.
Thanks to Matthew T. Chappell, Queensland Government, AUSTRALIA
Change 42.049 SMF 119 Subtype 38 INPUT STATEMENT EXCEEDED INVALID DATA
VMAC119 for PIB4 because lines 4035-4040 were missing the period
Jun 24, 2024 at the end of the &PIB.4. INFORMAT. SAS Only detects the
error when that code is executed, i.e. for a subtype=38.
Thanks to Janet Harris, NTRS, USA.
Thanks to Leopoldo E. Esparza, NTRS, USA.
Thanks to Suresh Upputuri, NTRS, USA.
====== CHANGES THRU 42.048 ARE IN MXG 42.02 DATED Jun 22, 2024 =========
Change 42.048 -IFLMSUHR was calculated incorrectly and additional OBS
VMXG70PR were output because a SET was used instead of a MERGE.
Jun 22, 2024 This caused incorrect ASUMCEC observation counts and
some incorrect duration values that were introduced in
MXG Version 42.01.
-MSUHR totals were wrong (ZIPMSUHR ICFMSUHR IFLMSUHR
IFAMSUHR)
-ASUM70GC dataset was incorrectly summarized at the
LPAR level instead of capacity group.
Thanks to Matthew T. Chappell, Queensland Government, AUSTRALIA
Change 42.047 New variables added to TYP11912TLS dataset:
FORMATS S11912SS_TLS_SRV_HS_SM /*SERVER*HS_SIG_METHOD*/
VMAC119 S11912SS_TLS_CLI_HS_SM /*CLIENT*HS_SIG_METHOD*/
Jun 20, 2024 S11912SS_TLS_NEG_KEY_SH /*NEGOTIATED*KEY_SHARE*/
Thanks to Luis Mendoza, ICE, USA.
Change 42.046 The below test for FMTSEARCH was removed from MXG 42.42.
VMXGINIT The MXGWARN caused confusion, the problem was obscure
Jun 15, 2024 and rarely encountered. The tests for the existence of
Jan 2, 2025 a FORMAT library or for a Back Level FORMATS remain.
Original Change Text:
Modified to check FMTSEARCH for values other than (WORK
LIBRARY) or to see if you are using WPS; then the check
for old or non-existent formats is bypassed. Using
IMACFMTS and keeping formats in LIBRARY rather than
using FMTSEARCH is recommended. NOTE: on z/OS, those
ddnames must have DISP=NEW or OLD if you plan to add or
modify formats.
Change 42.045 ZERT dataset TYP11912DN and TYP11912SUM were missing obs
VMAC119 because the triplet count fields NUM11906 and NUM11907
Jun 14, 2024 in Subtype 12 records were always one, but IBM never
documented that one segment could contain many obs and
never provided the actual count. The DO to NUM11906/07
was replaced with DO WHILE LENLEFT logic to determine the
actual number of observations that are in the segment.
Thanks to Jorge Fong, City of New York, USA.
Change 42.044 Now allows you to specify how many LPARS to keep in
VMXG70PR ASUMCEC/70pr New parameter LPARS2KEEP= lets you specify
Jun 7, 2024 the number of LPARS to keep. This can significantly
reduce the size of the resulting dataset. In one test
using 20 the size of ASUMCEC was reduced by 61%! In order
to simplify the logic 5 10 20 or 30 LPARS are kept so if
you specify 4 5 are kept. If you specify a number smaller
than the number of LPARS found in the data a WARNING
message is created and LPARS2KEEP is set to a null
string.
Change 42.043 If you added a PROC COPY after CICINTRV it failed since
CICINTRV the datasets had been deleted by VMXGCICI. Deletion was
VMXGCICI removed from VMXGCICI and left inside of comments in
JUN 3, 2024 CICINTRV.
Thanks to Keith C. Shaffer, Evernorth, USA.
Change 42.042 CPU LOOP with SMF 82 SUBTYPE 40. SMF82_TAG '010F'x was
VMAC82 increased to 16 bytes.
Jun 3, 2024
Thanks to Jan Tielemans, KBC, BELGIUM
Change 42.041 TYPE102 IFCID 365 INPUT EXCEEDED RECORD MXG 42.01.
VMAC102 New fields added that exposed issues with QLSTLEN not
May 27, 2024 matching actual length of data.
QLSTNTPLH='TERMINATED*HIGH*PERFORMANCE'
QLSTNTILS='TERMINATED*TOP*SOCKET*CLOSED'
Thanks to John Kim, Morgan Stanley, USA
Change 42.040 The TYPE70 dataset has 18 Arrays with 255 variables that
VMAC7072 have suffix M0-M8,MA-MZ,YA-YC,ZA-ZZ.102-255 & start with
May 27, 2024 CPUEDT CPUPAT CPUPDT CPUWAI IFATYP IFAWAI
IORATE MVSWAI PCTCPB PCTIFB PCTONL PCTTPI
PCTZIB ZIPWAI LCPUDE LCPUWA PCTCIB CAI
that contain the metrics for each CPU.
It's highly likely that you have never used any of these
per-CPU variables in this poor design, because each array
is summed into the actual metric of interest that you
have been using, for example CPUEDTTM is the Effective
Dispatch Time for the interval and there aren't any knobs
to turn for each of the individual CPUs. But there might
be a need to examine some of those individual CPU metrics
when SMT is active, which is why the TYPE70EN per-engine
dataset was created with a single set of variables and an
observation per engine per thread per interval so those
unwieldy array variables in TYPE70 are not really needed.
And that's good, because with SMT, they are incorrectly
stored in the wrong array entry. For example, the IORATEx
variables for CPU 0,1,2,and 3 are not in the expected
IORATE0/IORATE1/IORATE2/IORATE3 variables, but are found
in IORATE0/IORATE2/IORATE4 with missing values in those
IORATE1/3/5 variables: MXG confused CPUID with THREAD.
But as those individual rates are summed into the IORATE
variable which is the interval value, no data was lost.
Only a single MXG user has reported this error, and this
code was implemented in the Spring of 2015. With no other
reported issues with these unlikely-to-be-needed TYPE70
variables, and with the availability of TYPE70EN dataset,
and the exposure of creating a new problem in the very
complex support for the SMF 70 record, this error can not
be corrected safely.
Change 42.039 TYPE 119 formats $MG119CF and $MG119KA were corrected.
FORMATS
May 20, 2024
Thanks to Matthew T. Chappell, Queensland Government, AUSTRALIA
Change 42.038 Support new tokens TOKDB2 and TOKOWNERS in TYPE80TK.
VMAC80A
May 19, 2024
Thanks to Bruce Henson, CITIGROUP, ENGLAND
Thanks to Harald Seifert. HUK-COLBURG, GERMANY.
Change 42.037 New DB2 Zparms added to dataset T102S106.
VMAC102 MXG Variable IBM ZPARM
May 19, 2024 QWP4AUDIWU ALLOW_UPD_DEL_INS_WITH_UR
QWP4DSSAR DISALLOW_SSARAUTH
QWP4FCXC FLASHCOPY*XCXC
QWP4LSSIC LA_SINGLESEL_ISOCS_CDY
QWP4LIRO LOAD_RO_OBJECTS
QWP4MXUDF MAX_UDF
QWP4MXAIDC MAX_MEMORY_FOR_AI_DATA_CACHING
QWP4PKGDEPLVL PACKAGE_DEPENDENCY_LEVEL
QWP4RTNP REORG_TS_NOPAD_DEFAULT
QWP4LTMX SPREG_LOCK_TIMEOUT_MAX
QWP1STIMM STATIME_MAIN
QWP4STPGS STATPGSAMP
QWP4TCNE TABLE_COL_NAME_EXPANSION
QWP4TSCT TS_COMPRESSION_TYPE
QWP4UTHIST UTILITY_HISTORY
QWP4UBCDC UTILS_BLOCK_FOR_CDC
Thanks to Lai Fai Wong, Bank of America, USA.
Change 42.036 Support for TOKDANAM values XUHSTORY XUTIMING XUGROUPS in
VMAC80A TYPE80TK.
May 15, 2024 Support for EV44VAL length greater than 80 error messages
RACF EV(44) ERROR. INVALID RACFDLNN and INPUT EXCEEDED.
Thanks to Bheema Linga Prasad Kammara, NAB, AUSTRALIA.
Thanks to Bhuvaneshwari Shanmugam, NAB, AUSTRALIA.
Change 42.035 Change 41.085 opens the format library to check and be
VMXGINIT sure it is current. That means that if you use fmtsearch
May 15, 2024 to point at user formats you must specify disp=old on
the dd statement if you want to update it (zOS only).
Note: This Change was doc only. See Change 42.046.
Thanks to Raymond Smith, OPTUM, USA.
Change 42.034 -Using a TAPE (SEQUENTIAL) data library for the PDB data
VMXGSUM library has NEVER been wise due to the restrictions that
May 15, 2024 only one dataset can be open at a time, which required
protection in BUILDPDB logic, and, in the past, the time
needed for rewinds, now nonexistent with virtual tape,
but also the loss of datasets after an existing dataset
if that existing dataset is updated. MXG has protected
the BUILDPDB process to allow use of tape, but a change
to VMXGSUM is needed to permit that process. There has
always been a warning message for SEQUENTIAL PDB DD.
Change 42.033 -IMS LOG ENQFLAG=0CX and FLAG2=41X is output to IMS35P.
VMACIMS -Variable LG50RTKN kept in IMS5950 and TPCPRTKN kept in
May 9, 2024 IMS56FA.
Thanks to Oscar Curero, NTTDATA, SPAIN
Change 42.032 Documentation only, note that only one DEST will be set.
VGETDEST
May 1, 2024
Change 42.031 -New variable MAXWKSET 'MAXIMUM*WORKING*SET (K BYTES)' is
BUILD005 created in PDB.JOBS with the maximum value of any step.
BUIL3005 -Using a TAPE (SEQUENTIAL) data library for the PDB data
SPUNJOBS library has NEVER been wise due to all of the rewinds
May 13, 2024 needed to retrieve PDB datasets, MXG has protected the
BUILDPDB process to support it, but a change to VMXGSUM
is needed to protect that process. And, virtual tape has
mitigated those concerns.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 42.030 -The TYPE30_6 Early Address Space SMF 30 subtype 6 records
VMAC30 variables SRVSRBTM and SRVTCBTM and CPUTOTTM were wrong
Apr 25, 2024 when BOOST was active because they were calculated prior
to the DIF() deaccumulate logic. These three variables
are not the standard CPUTCBTM CPUSRBTM and CPUTM times
that are in the SMF 30 records. The three variables are
calculated from Service Units and added when it was
claimed that they were more accurate than TIME fields.
-Variable BOOSTCLASS was wrong if BOOSTACTIVE was missing
value in the TYPE30xx datasets, when it should have been
blank.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 42.028 DELTATM in PDB.VXINTUSR was incorrectly divided by the
VMACVMXA number of configured engines ENGCONFG; that division is
Apr 18, 2024 removed.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 42.027 Support for IBM Dependency Based Build SMF 122 Subtype 2.
VMAC122A Note the product suffix is 122A because there was an
Apr 18, 2024 earlier Tivoli SMF 122 record.
Thanks to Jan Tielemans, KBC, BELGIUM
Change 42.026 DCB Attributes RECFM=F LRECL=660 are added to the INFILE
VMACCTLT CONTROLT so that file can be read from a pipe. Normally,
Apr 9, 2024 the FILENAME statement is used to supply attributes but
those attributes are not available with a pipe.
Since the CONTROL-T file is unlikely to ever be changed,
there was no need to use macro variables for them.
Change 42.025 Support for APAR OA61951 which added RACF PHRASEINT, the
FORMATS PASSWORD PHRASE CHANGE INTERVAL for both PASSWORD and for
VMAC80A SETROPTS with these added changes:
Apr 3, 2024 -Added new KW18 vars for PHRASEINT.
-Commented out the references to KW24S102 to KW24S109,
these were created from an IBM reserved field in error.
The correct values are in the following byte and already
decoded as KW24SP70- KW24SP77. Unfortunately the
subsequent keyword specified and keyword ignored flag
numbers are now out of sync as a result.
-Removed newly added KW24PA00-KW24PA01 as KW24PALG turned
out not to be a bit masked field.
https://www.ibm.com/docs/en/zos/3.1.0?topic=records-reco
rd-type-80-racf-processing-record incorrectly shows
these values as bits 0 and 1 but data had a value of 01X
for KDFAES. KW24PALG is now formatted to display values.
ftp://public.dhe.ibm.com/s390/zos/racf/pdf/oa43999.pdf
shows the correct definition (0=existing algorithm,
1=KDFAES).
-Flags KW24I108, KW24I109, KW24S116, KW24S117 (originally
for EIMREGISTRY and NOEIMREGISTRY) have been repurposed,
I108/S116 is now ENHANCEDGENERICOWNER and I109/S117 is a
reserved bit. This changed in the manuals in z/OS V2R3.
-Corrected XMBALLRACF to XBMALLRACF in two labels.
-KW24SCLV label has been changed from
"SECURITY*AUDIT*VALUE" to "SECLABEL*AUDIT*VALUE"
-KW24SP40 fixed typo in label
-Added KW24MLSO KW24POPT KW24PWSR to $HEX formats and to
&MXGNOTRA.
-Fixed CHGINTRV to set missing when 0FFX, not 0FFFFFFFFX.
Confirmed this with a PASSWORD USER(xxx) NOINTERVAL.
-Dataset TYPE8018 new variables CHGINTRV PHRINTRV.
-Dataset TYPE8024 new variables KW24PALG KW24PHRI.
-Variables USRSEKTN KW24PWSR are $HEX formatted.
Thanks to Matthew T Chappell, Queensland Government, AUSTRALIA.
Change 42.024 Variable SIISPCT for z16 in SMF 113 datasets, using E164
ASUM1134 counter instead of E170.
VMAC113
Mar 21, 2024
Thanks to Jan Tielemans, KBC, BELGIUM
Change 42.023 ANAL9914 report CECTYPE test did not include Z16 so no
ANAL9914 REPORT=JIM was produced, even though there is no change
Mar 19, 2024 for the 16.
Thanks to Marvin L. Silverman, Bank of America, USA.
====== CHANGES THRU 42.022 ARE IN MXG 42.01 DATED MAR 15, 2024 =========
Change 42.022 Support for APAR OA65652 which adds variables to TYPE99Q2
VMAC99 PQAVQREQ='AVERAGE*QUEUED*REQUESTS'
Mar 12, 2024 PQBATQTM='BATCH*QUEUE*TIME'
PQBATSEL='BATCH*JOBS*SELECTED'
Change 42.021 INVALID REFERBACK IN THE COND FIELD in JCLASMXG example
JCLASMXG that assembles all MXG ASM members due to ASMRMFX in the
Mar 9, 2024 COND instead of ASMRMFI.
Thanks to MP Welch, Bank of America, USA.
Change 42.020 Using CICSIFUE under WPS results in U4038 LE abend with
CICSIFUE the following error message:
Mar 12, 2024 CEE3194E An attempt was made to initialize an AMODE24
program when the XPLINK(ON) run-time option was in
effect. AMODE24 programs are not supported in an
XPLINK environment.
So AMODE 31 and RMODE 31 statements were added to each
CSECT in CICSIFUE. CICSIFUE is the z/OS Exit to
decompress CICS and DB2 SMF records; see EXITCICS to
install the exit, which saves significant CPU Time
processing those data records.
Change 42.019 DB2 SMF 102 IFCID 365 now has the Length QWT02R2L zero
VMAC102 requiring revision to read the Length at the Offset.
Mar 6, 2024 I can find no documentation when individual IFCIDS are
being changed, I fear maybe every time an IFCID is to
be updated. The advantage of the header zero length
is that the individual segments can be different lengths.
Thanks to Harald Seifert, HUK-COLBURG, GERMANY.
Change 42.018 When I/O velocity is not enabled, the VELOCCPU was not
VMAC7072 correct; it should have been set to VELOCITY. Observed
Mar 6, 2024 that R723CTOU contains both GP and IIP usage but R723CCUS
only contains GP usage.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 42.017 ZERT SMF 119 Subtype 12 dataset TYP11912SUM (ZERT COMMON)
VMAC119 2024 observations were not output if there was a sixth triplet
Mar 1, 2024 (Certificate DN) segment, causing S11912SASECPROTOS to
only contain 0 (NO CRYPTO) and S11912SASESSIONID only C
so none of the observations were for encrypted sessions..
Thanks to Richard A Warren, USBank, USA.
Thanks to ???, IBM SMF 119 Support, USA.
Change 42.016 Support for RACF IRRDBU00 Unload RACTYPE=0151 creates new
EXRAC151 RACF0151 dataset 'Group CSDATA Custom Fields'.
IMACRACF GPCSD_NAME ='GROUP*NAME'
VMACRACF GPCSD_TYPE ='DATA*TYPE*FOR*CUSTOM*FIELD'
VMXGINIT GPCSD_KEY ='CUSTOM*FIELD*KEYWORD'
Mar 1, 2024 GPCSD_VALUE='CUSTOM*FIELD*VALUE'
Thanks to Nathan Battles, Navy Federal, USA.
Change 42.015 -SMF70CSF was missing for ICF IFL LPARS. Now added as
VMXG70PR the MAX value for all LPARS. ICF/IFL MSU values were
Feb 25, 2024 added to ASUMCELP. Count of ICF LPARS added to ASUMCEC.
Mar 9, 2024 -Unrelated, could have a SORT ERROR on GMTOFFTM and the
Mar 15, 2024 variable was not carried forward into ASUMCELP dataset.
Thanks to Scott Barry, SBBTechLLC, USA.
Thanks to Perry Metzel, Alight, USA.
Change 42.014 NOTE: INVALID NUMERIC DATA "xxxxxxxx'x for some datetime
VMACBETA variables in BETA30 and BETA31 datasets due to typo were
Feb 20, 2024 present since last update in 2021. No ABEND, just NOTES.
Thanks to Tino Buschmann, ITZBund, GERMANY.
Change 42.013 -INPUT EXCEDED SMF 102 IFCID 172 when QWT02R2L NOT ZERO.
VMAC102 Change 41.112 supported the undocumented case when the
Feb 20, 2024 length field was zero, but records with zero length were
not correctly decoded.
-ZERO OBSERVATIONS in T102S196 due to debugging statement
IF QWTR22L=196 THEN DELETE. But the 196 has similar
length issues as the preceding 172 structure. Code was
revised and tested for QWT02R2N=1 records, but records
with QWT02R2N=2 are needed to verify.
Thanks to John Milne, Kyndryl, AUSTRALIA.
Change 42.012 LINUX ONLY. ASCII IEBUPDTE to build directory of files
IEBUPDTE would have built directories with a backslash \ rather
Feb 19, 2024 than a forward slash / if the last character was not /.
Change 42.011 Testing corrections. S031PSTP had missing period in the
VMACBETA $EBCDIC8 informat, but subtype 30 and 31 are misaligned
Feb 19, 2024 and doc is needed to investigate.
Thanks to Tino Buschmann, ITZBund, GERMANY
Change 42.010 Variable CRYIAES='AVG BYTES*PER AES ENCRYPT*SERVICE CALL'
VMAC7072 was incorrectly formatted as a time when it is just a
Feb 18, 2024 numeric value.
Thanks to Graham Harris, Natwest, ENGLAND.
Change 42.009 Support for APAR OA65055 which adds JAVA CP and zIIP
VMAC99 service units to dataset TYPE99SL:
Feb 15, 2024 S99RTCAPLEADTIME ='RTCAP*LEAD*TIME*MINUTES'
S99TIME_TO_CAP ='TIME*TO*CAP*SECONDS'
S99TIME_TO_CAP_GROUP='TIME*TO*CAP*GROUP*SECONDS'
S99SUS_ZIIP ='ZIIP*ELIG*UNWEIGH*SU ON*ZIIP'
S99SUS_ZIIP_ON_CP ='ZIIP*ELIG*UNWEIGH*SU ONCP'
S99SUS_JAVA_ON_ZIIP ='ZIIP*ELIG*UNWEIGH*JAVA SU*ON ZIIP'
S99SUS_JAVA_ON_CP ='ZIIP*ELIG*UNWEIGH*JAVA SU*ON CP'
Thanks to Jan Tielemans, KBC, BELGIUM
Change 42.008 Support for APAR OA65055 which adds JAVA CP and zIIP time
VMAC30 to TYPE30_V, TYPE30_4, TYPE30_5, PDB.SMFINTRV datasets:
Feb 8, 2024 SMF30_TIME_JAVA_ON_ZIIP ='JAVA*WORK*ON ZIP'
SMF30_ENCLAVE_TIME_JAVA_ON_ZIIP ='JAVA*ENCLAVE*ON ZIP'
SMF30_DEPENC_TIME_JAVA_ON_ZIIP ='JAVA*DEPENC*ON*ZIP'
SMF30_TIME_JAVA_ON_CP ='JAVA*WORK*ON*CP'
SMF30_ENCLAVE_TIME_JAVA_ON_CP ='JAVA*ENCLAVE*ON*CP'
SMF30_DEPENC_TIME_JAVA_ON_CP ='JAVA*DEPENC*ON*CP'
Thanks to Jan Tielemans, KBC, BELGIUM
Change 42.007 Added VMXGSUM parameter MXGNOECHO= to suppress printing
VMXGSUM all of the VMXGSUM parameters, enabled by specifying YES
Feb 8, 2024 in your VMXGSUM invocation. Added %GLOBAL macro variable
NOMXGECHO which can be externally set before VMXGSUM is
invoked, with %LET NOMXGECHO=YES; to suppress listing.
Thanks to Harald Seifert, HUK-COLBURG, GERMANY.
Change 42.006 INPUT STATEMENT EXCEEDED for Omegamon for CICS ONDV
VMAC112 for SUPRA records. The MXG TEST for FOCVER GE 'V560'
Feb 6, 2024 should have been for V550 to INPUT SATTACH since that
field was present in the V550 record and its INPUT
then aligned SUSEDF and SRECLEN correctly.
Thanks to Gaetan Martel, Intact, CANADA
Change 42.005 -JCL examples added and comments revised to show how to
GRAFCEC use ODS for reports instead of the MXGODSxxxx arguments
Feb 7, 2024 that should not have been created.
-Corrected duplicate BY statement missed by SAS.
Thanks to Tom Maccabe, Dominion Energy, USA.
Change 42.004 Significant overhaul of this MQ report/analysis program.
ANAL115 New parameters added to simplify report criteria.
Jan 31, 2024 INCODECFS=code to limit CFS report
INCODEBUF=COde to limit buffer report
INCODELOG=code to limit LOG report
INCODEMSG=code to limit db2 REPORTS
Parameters were put in alpha order.
TY115201 ADDED as input to LOG report
TY115215 ADDED as input to buffer report
Change 42.003 If you run with RUNWEEK=NO and FIRSTRUN=YES option OBS=0
BLDSMPDB was set to copy PDB to days of week but 0 OBS was not
Jan 18, 2024 reset so anything after BUILDPDB had 0 OBS. Statement was
moved so that it will always be run.
Thanks to Jim Poletti, Edward Jones, USA.
Change 42.002 INPUT STATEMENT EXCEEDED reading subtype 2 Statistics
UCICSCNT records which are not compressed because MXGDECOM was
Jan 17, 2024 incorrectly invoked for subtypes one and two.
Thanks to Raymond Smith, OPTUM, USA.
Thanks to Ronald W. Bassett, OPTUM, USA.
Change 42.001 MXG 41.06 and 41.41. Change 41.112 accidentally changed
VMAC102 the INPUT names for QWT02R4L-QWT02R9L to QWT02R4LX-R9LX
Jan 12, 2024 so the correct named variables were missing values and
those segments were not input, causing missing values for
all of the variables that should have been input.
Impacted all IFCIDS with QWHSNSDA GT 4.
Thanks to Jan Tielemans, KBC, BELGIUM
LASTCHANGE: Version 42.
=========================MEMBER=CHANGE41================================
/* COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG VERSION 41.41 was dated Jan 10, 2024, thru Change 41.122.
MXG VERSION 41.06 was dated Dec 15, 2023, thru Change 41.117.
MXG VERSION 41.05 was dated Nov 16, 2023, thru Change 41.108.
MXG VERSION 41.04 was dated Sep 20, 2023, thru Change 41.086.
MXG VERSION 41.03 was dated Aug 11, 2023, thru Change 41.069.
MXG VERSION 41.02 was dated Jun 5, 2023, thru Change 41.038.
MXG VERSION 41.01 was dated Mar 24, 2023, thru Change 41.015.
ANNUAL MXG VERSION 40.40 was dated Feb 3, 2023, thru Change 40.162.
New TECHNOTES previously in NEWSLTRS are now in CHANGESS.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 41.41 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 41.41.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains old Technical Notes. many of which are still
valid, but the last was in 2018. Now, TECHNOTES and FLASHes are in
CHANGES/CHANGESS. which are also online.
Member CHANGES contains the changes made in this current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
CHANGESS and NEWSLTRS are also online at http://www.mxg.com,
========================================================================
I. MXG ANNUAL VERSION 41.41 DATED Jan 12, 2024, THRU CHANGE 41.112.
==MAJOR CHANGES ADDED IN MXG 41.41, DATED Jan 12, 2024 THRU 41.112.====
NONE
==MAJOR CHANGES ADDED IN MXG 41.06, DATED Dec 15, 2023 THRU 41.117.====
VMXG70PR 41.107 ASUMCELP MSU variables for each CPU type added.
UCICSCNT 41.106 CICS Utility INPUT STATEMENT EXCEEDED MNSEGCL 5
ANALCEC 41.105 CEC Analysis new SORTBYADDS to control reports.
VMACDB2H 41.102 ASUMUOW merge of CICSTRAN and DB2ACCT fewer SPUN.
==MAJOR CHANGES ADDED IN MXG 41.05, DATED Nov 16, 2023 THRU 41.108.====
NEW SUPPORT
Change 41.092 Support for z/OS 3.1 SMF Manual changes (COMPATIBLE).
VMAC26J2 We and several customers have tested z/OS 3.1 records
VMAC30 with back levels of MXG that support z/OS 2.5 (39.08)
VMAC7072 with no errors reported, and we expect no issues.
VMAC79 Change 41.096 added the new AI data in TYPE99 and
Oct 26, 2023 there were other APARs in 3.1, but we expect no issues.
New variables were added, see Change 41.092 full text.
This change was in MXG Version 41.05.
VMAC123A 41.094 Support for z/OS Connect V3.0.74.0 new variables.
VMAC26J2 41.092 Support for z/OS 3.1 SMF Manual Changes COMPATIBLE
VMAC110 41.081 Support for CICS/TS 6.2 BETA16 INCOMPATIBLE inserts.
VMACVIRS 41.080 Support for VIRTEL/VIRSTAT versions 640/641.
VMAC99 41.096 Support for AI Data Section WLM AI Batch INITs.
ERRORS CORRECTED
UCICSCNT 41.106 CICS Utility INPUT STATEMENT EXCEEDED MNSEGCL 5
ENHANCEMENT
VMACMARS 41.099 Corrections to Hitachi Mainframe Analysis Recorder
VMAC110 41.095 CICSTRAN variable WBURISCN spelled WBIRISCN.
VMAC99 41.090 TYPE99_6 variables SERVER01-05 SERVPN01-05 wrong.
VMXG70PR 41.107 ASUMCELP MSU variables for each CPU type added.
ANALCEC 41.105 CEC Analysis new SORTBYADDS to control reports.
VMACDB2H 41.102 ASUMUOW merge of CICSTRAN and DB2ACCT fewer SPUN.
CICINTRV 41.087 CICINTRV now supports a ONEMINUTE value for _CICINTV
ANALAVAI 41.098 Availability report can now grouped on program name
JAVA 41.091 Two JAVA memory options were found needed in z/OS.
FORMATS 41.097 CICS 6.1 dynamic storage areas not in $MGCICLO.
==MAJOR CHANGES ADDED IN MXG 41.04, DATED Sep 20, 2023 THRU 41.086.====
NEW SUPPORT
VMAC110 41.081 Support for CICS/TS 6.2 BETA 16 INCOMPATIBLE
New field inserted in SMF CICSTRAN record.
ERROR CORRECTED:
UTILEXCL 41.075 UTILEXCL error in Change 41.063 ABCODE (MXG 41.03).
Caused CPUTM GT ELAPSED Msgs if both ABCODEs kept.
ENHANCEMENTS
VMACSARR 41.073 SARR/CAVIEW Subtype 36 datasets now populated
TYPE7072 41.071 Variable CECSER6 is added to TYPE70/70PR/RMFINTRV
TYPEXAN 41.071 Variable CECSER6 is added to XAMSYS
TYPE119 41.070 TYP11906 added 5th Home Address variables.
==MAJOR CHANGES ADDED IN MXG 41.03, DATED Aug 11, 2023 THRU 41.069.====
ABENDS CORRECTED:
VMAC99 41.066 SMF 99 Subtype 9 INPUT EXCEEDED, ERROR IN SMF MANUAL
VMAC74 41.052 BMC CMF Only Subtype 9 INPUT STATEMENT EXCEEDED.
VMAC98 41.049 SMF 98 CICS Subtype 1024 ABEND, only ST 1 supported
ERRORS CORRECTED:
UTILBLDP 41.068 %CLEARDB2 addition caused VARIABLE STARTHR errors.
VMAC116 41.067 DB2H Header Variables QWHCAID/QWHCOPID in TYPE116.
VMACDB2 41.065 DB2 IDAA variables Q8STINSC-Q8STVLCS shifted, wrong.
VMAC119 41.064 Dataset TYP11910 UCLIPV6 was wrong, had blanks.
VMAC74 41.064 TYPE74CA storage variables CSCONF+ are GB not MB.
VMAC71 41.041 Correction to CSTORE which was too small.
ENHANCEMENTS
UTILEXCL 41.063 Protection for EXCLUDEd CICS Field 114 ABCODEC.
VMAC30 41.053 Support for APAR OA62355 new TYPE30 Containers.
VMACRMFV 41.043 Support for z/OS 3.1 RMF III variables in ZRBASI/GEI
VMAC71 41.042 Support for z/OS 3.1 Dedicated memory variables.
==MAJOR CHANGES ADDED IN MXG 41.02, DATED Jun 5, 2023 THRU 41.038.====
ERRORS CORRECTED:
Change 41.038 -Support for CICS/TS 6.2 INCOMPATIBLE, FIELDS INSERTED,
UTILEXCL MANY WRONG VALUES (Neg TASZIPTM, MAXTASKS 3.2 Billion)
VMAC110 but no error messages. Tested now with OPEN BETA BUILD12.
May 31, 2023 -CORRECTION for CICS/TS 6.1 with default VMAC110 but was
ok if UTILEXCL was used to create an IMACEXCL for 6.1.
Default VMAC110 in 41.01 and earlier was misaligned, with
possible error message "CPUTM 10X LARGER THAN ELAPSED".
This change is in MXG 41.02 dated Jun 5, 2023.
VMAC7072 41.025 LARGE VALUE FOR LCPUPDTM IBM Error protected.
VMACXAM 41.021 zVPS VSICPU misaligned, floating point error.
VMAC102 41.016 SMF 102 IFCID 389 INPUT STATEMENT EXCEEDED error.
ENHANCEMENTS
TYPE83 41.019 Support for TYPE 83 Subtype 7 Multi-Factor record
TYPE113 41.033 Support for HIS SMF 113 MT Diagnostic Counters
VMAC80A 41.036 Support new TOKDANAM values and EV944 ERROR fixed.
VMAC102 41.035 Support for DB2 TRACE IFCIDS 411 and 412
VMACEREP 41.034 JCL Examples to create EREP History File.
VMAC113 41.033 Support for HIS SMF 113 MT Diagnostic Counters
VMACNDM 41.029 Dataset NDMRT enhanced with Parameter values.
ASMRMFI 41.028 Version 2 of ASMRMFI for SPLIT70 processing
VMACTRMS 41.026 Support for TRMS Version 7.02 subtypes 6 and 7
VMAC90A 41.023 Support for SMF 90 Subtype 42 BOOT VALIDATION.
VMACRACF 41.020 New RACF Unload IRRDBU00 datasets.
VMAC93 41.019 Support for TYPE83MF Multi Factor Authentication
==MAJOR CHANGES ADDED IN MXG 41.01, DATED Mar 24, 2023 THRU 41.015.====
ERRORS CORRECTED:
VMACDB2 41.013 DB2 Subtype 1 EXCEEDED LENGTH if Q8STNAME length LT 8
SASHOTFIX 41.012 SAS HOTFIX 69871 ASCII PLATFORMS REQUIRED SPLIT70.
TYPE113 41.005 TYPE1131 for z/15 L2P variable was wrong
TYPE89 41.004 TYPE89 variable SMF89SOLUTION ID off by 1 byte.
TYPE99 41.001 SMF 99 Subtype 1 INPUT EXCEEDED, S99SLLN=80 not doc.
ASMRMFX 41.003 Revision to Change 40.140 SPLIT70 and CICSIFUE.
VMAC71 41.008 TYPE71 CSFRLSAV missing value
ENHANCEMENTS
SPLIT70 41.011 New ASMRMFI using IBM GRBSMFR z/OS 2.5 SPLIT70
VMACDB2 41.010 Support for DB2 V13 100/101 (COMPATIBLE, New Vars)
VMAC102 41.010 Support for DB2 V13 102 (New IFCID 396)
FORMATS 41.007 $MGRMIPS format updated for z/16 processor types.
SPLIT70 41.011 New ASMRMFI using IBM GRBSMFR z/OS 2.5 SPLIT70
ASMRMFX 41.003 Revision to Change 40.140 SPLIT 70s and CICSIFUE.
VMAC30 41.015 More new Direct Memory (z/OS 3.1) variables added.
SPLIT70 41.012 SAS HOT FIX 69871 on ASCII for LRECL GT 32756.
SPLIT70 41.011 ASMRMFI using IBM BRBSMFR for LRECL GT 32756.
VMACRMFV 41.009 New RMF III variables added Data Gatherer Pgmr Guide
TYPE113 41.005 TYPE1131 for z/15 L2P variable was wrong
TYPE89 41.004 TYPE89 variable SMF89SOLUTION ID off by 1 byte.
ASMRMFX 41.003 Revision to Change 40.140 SPLIT 70s and CICSIFUE.
TYPE99 41.001 SMF 99 Subtype 1 INPUT EXCEEDED, S99SLLN=80 not doc.
FORMATS 41.007 MIPS values for z/16 Processor Format $MGRMIPS.
========================================================================
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M8 (9.4M8),
"M8", or with options VERSIONLONG;
"SAS 9.4 (9.04.01M8P080520)" on z/OS
9.4 (TS04.01M8P08052020)" on ASCII.
SAS V9.4 M8 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M6 or SAS Version 9.3 M0-M2.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.128 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 causes JCLTEST9/TESSOTHR to ABEND, TOO MANY ARGUMENTS
FOR COUNTW() requires SAS Version 9.2 so 9.1.3 can NOT
safely be used for MXG. See CHANGE 41.046, Jun 21, 2023.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But CONFIMXG is required for sites with NLS issues, and you must
use JCLCONFI to create/update the MXG.FORMATS catalog if you use
CONFIG='MXG.SOURCLIB(CONFIMXG)'.
For no NLS, you can use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 41.41 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 was STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 4.04 (04.04.01.00.005305 has been tested.
DO NOT USE 4.03.01 nor 4.04.00, INVALID CPU BUSY in TYPE70.
Error was introduced in 4.03.01 and 4.04.00. See Change 39.171.
Must be at 4.03.02.00.8569+ or 4.04.00.03.3277+/
WPS Version 4.01 USER 4037 ABEND, See Change 37.116.
WPS Version 4.0 reportedly fixed version 3 problems.
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
-Support for z16 processor data.
SMF: Only SMF 113 records were incompatibly changed, but there is no
execution error as only counter labels and values were changed,
causing coefficients for the calculated variables (RMI,etc) to
also be changed and default coefficients are changed to z16,
You should use separate SAS steps for each processor type; MXG
will OUTPUT only the processor type you requested in //SYSIN,
and will skip other processor type records, so you do NOT need
to pre-process SMF records to select processor type. You will
want to rename one pair of datasets if you want to put them in
the same PDB Data Library.
For z/15 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11F %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
and for z/16 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11G %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
to get correct values in TYPE1131 and ASUM1131 datasets.
MXG Support for z/16 for SMF 113 requires 40.05 for z/OS and
40.03 for zVM.
MXG 40.01 will ABEND due to a TYPE30 error exposed by the z16.
with z/OS 2.5 or APAR61511. You can correct by changing the
line 1812 in VMAC30 from 192 to 220, or ask support for the
current VMAC30 member with Change 40.050.
Many other SMF and Data Gatherer records were updated in 40.04.
RMF ASMRMFV processes RMF III data with no errors, Change 40.068
added some new fields. New DNG3 table support was in 40.05.
-Support for z15 processor data.
The z15 and z15 T02 processors INCOMPATIBLY changed the SMF 113
records by inserting 32 new EXTEND and 4 CRYPTO counters, causing
ARRAY SIZE EXCEEDED with BUILDPDB which processes the SMF 113s.
Support for counter changes for both models was in MXG 37.08.
If you use MIPS in reports, the format $MGRMIPS provides the
MIPS/MSU value for each processor; the z15 values were updated
in MXG 37.08, and the z15 TO2 values were updated in MXG 38.04.
These MXG programs use $MGRMIPS: ASUMMIPS GRAFCEC GRAFWLM
GRAFWRKX and TYPERMFV (RMF III).
The z/14 also inserted SMF 113 fields, supported in MXG 36.07.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
And z/VM on the z15 requires MXG 38.02, PRCMFC/MFM COUNTERS caused
HARDWARE COUNTER messages, PRCMFC/PRCMFM no obs. Change 38.048.
The z13 processor INCOMPATIBLY CHANGED, the new SMT-MODE RMF 70, and
MXG 34.03 was REQUIRED (PCTCPUBY WRONG!), to read the SMT-format RMF
(which are written if you have zIIP engines AND have enabled the new
PROCVIEW CORE option for Multi-Threading, even if only one thread is
enabled).
SMF Back Levels: MXG 37.08 or later is required for both z15 & z16
SMF 113 change, but those back level versions could fail due
to other records changed by subsystem updates you made for the
z16 (e.g.CICS TS/6.1 which requires MXG 40.02) that didn't
exist when that back=level was created..
The new zEDC/EADM compression hardware requires MXG 38.05 to support
new metrics.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z/OS 2.4 Compatible from SMF Manual Sep 2019 37.166 37.07.
z/OS 2.4 Compatible from SMF Manual May 2020 38.105 38.05.
z/OS 2.4 Compatible from SMF Manual Apr 2021 39.075 39.03.
z/OS 2.4 Compatible RMF III PGMR Apr 1 2021 39.074 39.03.
z/OS 2.5 Compatible from SMF Aug 12,2021 39.06.
z/OS 2.5 Compatible RMF III Aug 12,2021 39.08.
z/OS 2.5 RMF III 4 new tables Aug 12,2021 39.08.
z/OS 2.5 Protects Possible New 72.3 fields (40.078) 40.04.
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
z15 New SMF 113 fields INCOMPAT Nov 18, 2020 37.08
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
z15 ANAL9914 Support CH 39.006 Jan 14, 2021 39.01
z16 NEW SMF113 values, NO ABEND See CHANGE 40.070 40.03
z16 MXG 38.07 OR LATER IS NEEDED.
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS/TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS/TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS/TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS/TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS/TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS/TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS/TS 3.2 Compressed Records Nov 3, 2007 25.11
CICS/TS 4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS/TS 4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS/TS 4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS/TS 4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS/TS 4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS/TS 5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS/TS 5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS/TS 5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS/TS 5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS/TS 5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS/TS 5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS/TS 5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS/TS 5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS/TS 5.3 GA date Dec 11, 2015 33.33
CICS/TS 5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS/TS 5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS/TS 5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS/TS 5.4 GA Jun 17, 2017 35.03
CICS/TS 5.5 GA (INCOMPAT) Jan 29, 2018 36.11
CICS/TS 5.6 GA (INCOMPAT) Jun 1, 2020 38.07
CICS/TS 5.6 NEW DATA (COMPAT) Oct 5, 2020 38.09
CICS/TS 6.1 ONE NEW (INCOMPAT) Jan 11, 2020 40.01
CICS/TS 6.1 ONE NEW (INCOMPAT) Sep 20, 2020 40.02
CICS/TS 6.1 UTILEXCL/IMACEXCL OK Aug 15, 2022 40.05
CICS/TS 6.1 VMAC110 NO IMACEXCL May 31, 2023 41.02
CICS/TS 6.2 INCOMPATIBLE BETA16 Sep 20, 2023 41.04
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
z/VM 6.40061802 ABEND Jan 22, 2019 37.02
z/VM 7.1 INCOMPAT ABEND Feb 14, 2019 37.02
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA-BROADCOM
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2, 5.3, 5.4 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 41.41.
1. Incompatibilities introduced in MXG 41.41:
a. Changes in MXG architecture made between 41.41 and prior versions
that can introduce known incompatibilities.
IF YOU HAVE MEMBER E2TY70 IN YOUR USERID.TAILORING SOURCE LIBRARY,
YOU MUST CHANGE _LTY70 to _WTY70 in that member. CHANGE 38.105.
The error before this correction will be:
ERROR: DATA SET "PDB.TYPE70" was not specified on the DATA stmt.
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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 41.41:
Dataset/
Member Change Description
ANALAVAI 41.098 Availability report can now grouped on program name
ANALCEC 41.105 CEC Analysis new SORTBYADDS to control reports.
ASMRMFI 41.028 Version 2 of ASMRMFI for SPLIT70 processing
ASMRMFX 41.003 Revision to Change 40.140 SPLIT 70s and CICSIFUE.
CICINTRV 41.087 CICINTRV now supports a ONEMINUTE value for _CICINTV
FORMATS 41.007 MIPS values for z/16 Processor Format $MGRMIPS.
FORMATS 41.097 CICS 6.1 dynamic storage areas not in $MGCICLO.
JAVA 41.091 Two JAVA memory options were found needed in z/OS.
SASHOTFIX 41.012 SAS HOTFIX 69871 ASCII PLATFORMS REQUIRED SPLIT70.
SPLIT70 41.011 ASMRMFI using IBM BRBSMFR for LRECL GT 32756.
SPLIT70 41.011 New ASMRMFI using IBM GRBSMFR z/OS 2.5 SPLIT70
SPLIT70 41.012 SAS HOT FIX 69871 on ASCII for LRECL GT 32756.
TYPE113 41.005 TYPE1131 for z/15 L2P variable was wrong
TYPE119 41.079 TYP11906 added 5th Home Address variables.
TYPE7072 41.071 Variable CECSER6 is added to TYPE70 and TYPE70PR
TYPE89 41.004 TYPE89 variable SMF89SOLUTION ID off by 1 byte.
TYPE99 41.001 SMF 99 Subtype 1 INPUT EXCEEDED, S99SLLN=80 not doc.
UCICSCNT 41.106 CICS Utility INPUT STATEMENT EXCEEDED MNSEGCL 5
UTILBLDP 41.068 %CLEARDB2 addition caused VARIABLE STARTHR errors.
UTILEXCL 41.063 Protection for EXCLUDEd CICS Field 114 ABCODEC.
UTILEXCL 41.075 UTILEXCL error introduced in Change 41.063 ABCODE
VGETOBS 41.088 %VGETOBS sets &VGETOBS=1 if lib is on tape.
VMAC102 41.010 Support for DB2 V13 102 (New IFCID 396)
VMAC102 41.016 SMF 102 IFCID 389 INPUT STATEMENT EXCEEDED error.
VMAC102 41.035 Support for DB2 TRACE IFCIDS 411 and 412
VMAC102 41.112 DB2 SMF 102 IFCID 172 no obs, Length field zero.
VMAC110 41.081 Support for CICS/TS 6.2 BETA16 INCOMPATIBLE inserts.
VMAC110 41.095 CICSTRAN variable WBURISCN spelled WBIRISCN.
VMAC110 41.113 CICS 110 SUBTYPE 1 MNSEGCL 5 INPUT EXCEEDED.
VMAC113 41.033 Support for HIS SMF 113 MT Diagnostic Counters
VMAC113 41.115 Updates to the CPU MF formulas for z14 and z15.
VMAC116 41.067 DB2H Header Variables QWHCAID/QWHCOPID in TYPE116.
VMAC119 41.064 Dataset TYP11910 UCLIPV6 was wrong, had blanks.
VMAC123A 41.094 Support for z/OS Connect V3.0.74.0 new variables.
VMAC26J2 41.092 Support for z/OS 3.1 SMF Manual Changes COMPATIBLE
VMAC30 41.015 More new Direct Memory (z/OS 3.1) variables added.
VMAC30 41.053 Support for APAR OA62355 new TYPE30 Containers.
VMAC7072 41.025 LARGE VALUE FOR LCPUPDTM IBM Error protected.
VMAC7072 41.111 Support for APAR OA64781 TYPE70 Variable capacity
VMAC71 41.008 TYPE71 CSFRLSAV missing value.
VMAC71 41.041 Correction to CSTORE which was too small.
VMAC71 41.042 Support for z/OS 3.1 Dedicated memory variables.
VMAC74 41.052 BMC CMF Only Subtype 9 INPUT STATEMENT EXCEEDED.
VMAC74 41.064 TYPE74CA storage variables CSCONF+ are GB not MB.
VMAC80A 41.036 Support for TOKDANAM values and EV944 ERROR fixed.
VMAC90A 41.023 Support for SMF 90 Subtype 42 BOOT VALIDATION.
VMAC93 41.019 Support for TYPE83MF Multi Factor Authentication
VMAC98 41.049 SMF 98 CICS Subtype 1024 ABEND, only ST 1 supported
VMAC99 41.066 SMF 99 Subtype 9 INPUT EXCEEDED, ERROR IN SMF MANUAL
VMAC99 41.090 TYPE99_6 variables SERVER01-05 SERVPN01-05 wrong.
VMAC99 41.096 Support for AI Data Section WLM AI Batch INITs.
VMACDB2 41.010 Support for DB2 V13 100/101 (COMPATIBLE, New Vars)
VMACDB2 41.010 Support for DB2 V13 new variables COMPATIBLY ADDED
VMACDB2 41.013 DB2 Subtype 1 EXCEEDED LENGTH if Q8STNAME length LT
VMACDB2 41.065 DB2 IDAA variables Q8STINSC-Q8STVLCS shifted, wrong.
VMACDB2H 41.102 ASUMUOW merge of CICSTRAN and DB2ACCT fewer SPUN.
VMACEREP 41.034 JCL Examples to create EREP History File.
VMACMARS 41.099 Corrections to Hitachi Mainframe Analysis Recorder
VMACNDM 41.029 Dataset NDMRT enhanced with Parameter values.
VMACRACF 41.020 New RACF Unload IRRDBU00 datasets.
VMACRACF 41.109 Support for RACF TYPEs 0141/0209/0290/02C9/0509.
VMACRMFV 41.009 New RMF III variables added Data Gatherer Pgmr Guide
VMACRMFV 41.043 Support for z/OS 3.1 RMF III variables in ZRBASI/GEI
VMACSARR 41.073 SARR/CAVIEW Subtype 36 datasets now populated.
VMACTRMS 41.026 Support for TRMS Version 7.02 subtypes 6 and 7
VMACVIRS 41.080 Support for VIRTEL/VIRSTAT versions 640/641.
VMACXAM 41.021 zVPS VSICPU misaligned, floating point error.
VMXG70PR 41.107 ASUMCELP MSU variables for each CPU type added.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at https://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE:
====== CHANGES THRU 41.122 ARE IN MXG 41.41 DATED Jan 10, 2024 =========
Change 41.122 WPS ABENDs reading ID=79 SUBTYPE=15 RMF record which does
VMACSMF not have an RMF Product Segment, which caused OFFRMFP to
VMACSMFL be a missing value, and WPS failed on INPUT @OFFRMFP+40
Jan 8, 2024 due to that offset's missing value. (SAS does NOT fail.)
The code with that INPUT statement was not in the prior
block that executed IF NOT (ID=79 AND SUBTYPE=15) so it
is relocated into that code block to not INPUT @OFFRMFP
for the 79 subtype 15, while WPS investigates why they
failed. The error message with the USER 999 ABEND is
"ERROR: The input record was not long enough for INPUT."
There are thousands of INPUT @offset statements in MXG,
where offset could be a missing value, but they are all
protected with a test for IF NRTRIPLET GT 0 so the INPUT
isn't executed when there is no segment. But while the
SMF manual states the subtype 15 does NOT have a Product
Segment, there actually is one, and the count in SMF70PRN
is 1, so SAS tolerated the missing offset value and the
INPUT @OFFRMFP was executed, but with incorrect alignment
causing a large value in SMF70RAN and incorrect values in
MVSLEVEL and PRODVERSION in the _SMF Header variables.
Those _SMF variables are now correctly missing values.
(Those variables are/were correct in the VMAC79 code and
in the TYPE7915 ILRM dataset built by SAS.)
Change 41.121 During QA testing we found that sometimes a VMXGSUM with
ASUMDBDS NEWSHIFT=Y failed looking for a variable SHIF rather than
ASUMMWNT SHIFT if the DATETIME= var was also in the by list.
ASUMSTC These members were all exposed, DATETIME was corrected.
ASUMVMON From VMXGSUM documentation in comments:
TRNDVDEV The variable "DATETIME" was never intended to be in
Dec 28, 2023 the output data set, but early on it was kept by
accident, and users wrote code expecting it, so it has
to be kept by default, but you can and should use the
DROPDT=YES, option to tell VMXGSUM to drop the variable
named "DATETIME", as it is not needed, is not a
descriptive name and can be confusing. ASUMDBDS
summarizes MONIDBDS dataset.
Change 41.120 Support for CICS Optional CMR segment variable CMDUDAT2.
IMACICMX Note: for new variables in optional segments supported in
UTILEXCL IMACICxx members, the new variable does not need to be in
Dec 28, 2023 VMAC110. UTILEXCL must be run to create the new IMACEXCL,
and it is updated to add the new variable to the _VCICTRN
macro, which is the list of all variables to be kept.
Thanks to Ankush Dudhbavare, Ensono, USA.
Thanks to Bob Olah, Ensono, USA.
Thanks to Shantanu Gupta, Ensono, USA.
Thanks to Sashank Samarth, Ensono, USA.
Thanks to Rahul Raj, Ensono, USA.
Change 41.119 DB2 IDAA variable Q8ACTWDP was not divided by 4096 and
IMACDBNZ was not FORMATed to TIME13.3. Q8ACNWDP was incorrectly
Dec 27, 2023 divided by 4096.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 41.118 The new code to check for backlevel FORMATS caused error
VMXGINIT message "MGFMTVR 484" if the FORMATS library did not
Dec 27, 2023 exist even though the NOFMTERR option was enabled. This
error message had no impact, but the message is removed.
Thanks to Steve Estle, Peraton, USA.
====== CHANGES THRU 41.117 ARE IN MXG 41.06 DATED Dec 15, 2023 =========
Change 41.117 Failed if no libname.memnames matching the specified
VMXGCOPY parameters with an invalid DO loop. Now detects and shuts
Dec 13, 2023 down.
Change 41.116 New z/OS 3.1 variable is added to RACF0200 dataset:
VMACRACF USBD_PHR_INTERVAL='DAYS*PASSWORD*CAN BE*USED'.
Dec 12, 2023
Thanks to Gaetan Martel, INTACT, CANADA.
Change 41.115 Updates to the CPU MF formulas for the z14 and z15 are
ASUM113 made because the z16 algorithm was improved in capturing
VMAC113 Finite Time so the z14 and z15 metrics are adjusted for
Dec 8, 2023 consistency. The website http://www.ibm.com/support/
Dec 28, 2023 techdocs/atsmastr.nsf/Webindex/TC000066 has the details.
Variables ESTFINCP & ESTSCP1M calculations were changed.
This change was wrong in 41.06, corrected in 41.41. The
test for version was misspelled SMF113VN2 vs SM113VN2.
Thanks to John Burg, IBM, USA.
Change 41.114 Variable SV36RID was not kept.
VMACSARR
Dec 1, 2023
Thanks to Steven W. Erkkila, USBANK, USA.
Change 41.113 SMF 110 SUBTYPE 1 MNSEGCL 5 RESOURCE (NOT CICSTRAN) ABEND
VMAC110 INPUT STATEMENT EXCEEDED due to 2 typos for MNR5OFFU that
Nov 29, 2023 should have been MNR5OFFW. Error introduced in 38.114,
Thanks to Robin van Westendorp, Standard Bank of South Africa, S.A.
Thanks to Jorge J. Quintela, Standard Bank of South Africa, S.A.
Change 41.112 DB2 SMF 102 IFCID 172 no obs because QWT02R2L length is
VMAC102 zero, now a flag that the length is in the first two
Nov 30, 2023 bytes pointed to by the QWT02R2O offset, an undocumented
change for SMF 102 records, although previously observed
in other DB2 SMF records.
Thanks to Jan Tielemans, KBS, BELGIUM.
Change 41.111 Support for APAR OA64781 and OA65494 TYPE70 dataset adds
VMAC7072 SMF70MDL_VAR='MODEL*VARIABLE*CAPACITY*IDENTIFIER'
Nov 21, 2023 SMF70MVCR ='MODEL*VARIABLE*CAPACITY*RATING'
SMF70NVCR ='MODEL*VARIABLE*CAPACITY*NOMINAL'
SMF70ZSU_ON_ZIIP='UNWEI ZIIP*ELIGIBLE*SU*ON ZIIP'
SMF70ZSU_ON_CP ='UNWEI ZIIP*ELIGIBLE*SU*ON CP'
SMF70JSU_ON_ZIIP='UNWEI ZIIP*ELIGIBLE*JAVA SU*ON ZIIP'
SMF70JSU_ON_CP ='UNWEI ZIIP*ELIGIBLE*JAVA SU*ON CP'
SMF70CPE_LO ='LOW*CPENABLE*THRESHOLD*VALUE'
SMF70CPE_HI ='HI*CPENABLE*THRESHOLD*VALUE'
Change 41.110 Variable T103ERIP, Remote IP Address, in TYPE103E dataset
VMAC103 was incorrectly input, the +1 should have been +4.
Nov 21, 2023
Thanks to Niels Oksholm, FDC, DENMARK.
Change 41.109 Support for RACF TYPE 0141/0209/0290/02C9/0509 creates
EXRAC141 five new datasets.
EXRAC209
EXRAC290
EXRAC2C0
EXRAC509
FORMATS
IMACRACF
VMACRACF
VMXGINIT
Nov 21, 2023
Thanks to Ervin Claxon, CSX, USA.
====== CHANGES THRU 41.108 ARE IN MXG 41.05 DATED Nov 16, 2023 =========
Change 41.108 Variable SV36MED was incorrectly input as numeric but
VMACSARR changing it to character would expose compatibility
Nov 15, 2023 issues, so now SV30MED is INPUT and kept in SARRU36.
Thanks to Steven W. Erkkila, USBANK, USA.
Change 41.107 Dataset ASUMCELP adds variables ICFMSU IFAMSU IFLMSU
VMXG70PR ZIPMSU and ZIPMSUHR to ASUMCELP with MSU totals for
Nov 14, 2023 each CPU Type.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 41.106 UCICSCNT utility INPUT STATEMENT EXCEEDED for MNSEGCL=5
UCICSCNT SUBTYPE=1 Resource Record, URIMAP and WEBSVC were not
Nov 14, 2023 decoded causing misalignment, and MXGDECOM code to
decompress SMF 110 records was not in this old utility.
Thanks to Raymond J Smith, OPTUM, USA.
Change 41.105 New parameter SORTBYADDS lets you add variables to the
ANALCEC by list.
Nov 6, 2023
Change 41.104 Option STOPOVER added to INFILE statements so bad record
VMXGHSM will be identified; without STOPOVER option SAS reports
Nov 6, 2023 LOST CARD that doesn't identify the problem record.
Change 41.103 If you changed times for Daylight Savings on an active
VMXG70PR system, a PROC MEANS could fail creating GRCAPS3 due to
Nov 6, 2023 GMTOFFTM out of order. This change moves GMTOFFTM
to an ID statement.
Thanks to Gennady Katsnelson, Kyndryl, USA.
Change 41.102 ASUMUOW merge of CICSTRAN and DB2ACCT could have many obs
VMACDB2H sent to SPINUOW because the CICSTRAN SMFTIME resolution is
Nov 2, 2023 .01 seconds and QWHSSTCK resolution is .000001 seconds and
the DELTAGMT included fractional seconds where the GMT
offset must be in whole seconds. Changing the DELTAGMT
derivation, using DELTAGMT=ROUND(SMFTIME-QWHSSTCK); gives
the correct whole seconds, also populating the blank value
in TRANNAME in PDB.ASUMUOW, and providing the correct DB2
event order with or without ASUMUOW.
Change 41.101 TYPE80xx Resource Name variables RESNAME, RESNAMEx and
VMAC80A RES25MEx were INPUT as $VARYING64 but they can be $245
Nov 3, 2023 so are now increased in TYPE8001/8009/8024/8025/8033
datasets..
Thanks to Bill Arrowsmith, Euroclear, BELGIUM
Thanks to Geoff Moverley, Euroclear, BELGIUM
Change 41.100 Dataset TYPE3804 reread the first segment because OFFTHREE
VMAC38 was not updated, and the _ETY3804 statement was not inside
Oct 31, 2023 the DO loop so many observations were not output.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND
Thanks to Mark Tomlinson, Lloyds Banking, ENGLAND
Change 41.099 Corrections to Hitachi Mainframe Analysis Recorder MAR SMF
VMACMAR Variables MARS3CSWO MARS3CRFO now kept in MARST03 dataset
Oct 25, 2023 Dataset MARST03 variables MARS3CSWO MARS3CRFO now kept.
Dataset MARST03 BY List added MARSSN.
-Dataset MARST05 byte variables were not converted from KB
-Dataset MARST05 time variables were incorrect informat and
not multiplied by 128.
Thanks to Jan Tielemans, KBC, BELGIUM
Change 41.098 Availability reporting can now be grouped on program name
ANALAVAI rather than job name to specify application groups.
Oct 24, 2023
Thanks to Laszlo Horvath, Kyndryl, Germany
Thanks to Thomas Tesche, Intergo, Germany
Thanks to Attila Halacsy, Lumdru, Germany
Change 41.097 CICS 6.1 dynamic storage areas PCDSA PUDSA EPCDSA EPUDSA
FORMATS were not included in the $MGCICLO format.
Oct 23, 2023
Thanks to David Price, NatWest, SCOTLAND.
Change 41.096 Support for AI Data Section which exists only for periods
EXTY99AI participating in WLM AI batch initiator management.
FORMATS Added in z/OS 3.1, creates new TYPE99AI dataset:
IMAC99 SM992AIMODELNAME ='MODEL*NAME*IDENTIFIER'
VMAC99 SM992AIMODELVERSION='MODEL*VERSION'
VMXGINIT SM992AIMODELUSECASE='MODEL*USECASE'
Oct 18, 2023 SM992AIFLAGS ='AI*FLAGS*SEE AIPRED*AISIMU'
SM992AIINFTIME ='LAST*INFERENCE*DURATION'
SM992AIDATA0 ='LAST*INFERENCE*RESULT'
SM992AIDATA1 ='ACTIVE*SERVER*PREDICTION'
SM992AIDATA2 ='ACTIVE*SERVER*PREDICTION*ERROR'
SM992AIDATA3 ='CP*SERVICE*PREDICTION'
SM992AIDATA4 ='CP*SERVICE*PREDICTION*ERROR'
SM992AIDATA5 ='ZIIP*SERVICE*PREDICTION'
SM992AIDATA6 ='ZIIP*SERVICE*PREDICTION*ERROR'
SM992AIDATA7 ='MODEL*DATA*FETCH*TIME'
SM992AIDATA8 ='MODEL*PROCESSING*TIME'
SM992AIPRED='AI*PREDICTIONS*ENABLED*THIS SRVCLASS?'
SM992AISIMU='AI*PREDICTIONS*IN SIMULATION*MODE?'
-AI-powered WLM batch initiator management augments WLM
with AI to optimize the management of IBM Z workloads.
These iteratively delivered capabilities will allow z/OS
to intelligently predict upcoming batch workload and
react by allocating an appropriate number of initiators.
This is designed to optimize system resources and batch
management, thus eliminating overhead from manual fine-
tuning and trial-and-error approaches. AI-powered WLM
batch management is the initial use case leveraging the
AI Framework for IBM z/OS.
Change 41.095 CICSTRAN variable WBURISCN was incorrectly spelled as
UTILEXCL WBIRISCN, now corrected.
VMAC110
Oct 17, 2023
Thanks to Scott Barry, SBBTechLLC, USA.
Change 41.094 Support for z/OS Connect V3.0.74.0 adds two variables to
VMAC123A SM123MAJOR='CONNECT*FEATURE*MAJOR*VERSION'
Oct 16, 2023 SM123MINOR='CONNECT*FEATURE*MINOR*VERSION'
Change 41.093 Variable NAMENODE was input $24 but is $64, and this
VMACXAM caused variables LOCATION MAP and TCPRELEASE to be
Oct 12, 2023 misaligned in XMTCPSYS dataset.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 41.092 Support for z/OS 3.1 SMF Manual changes (COMPATIBLE).
VMAC26J2 We and several customers have tested z/OS 3.1 records
VMAC30 with back levels that support z/OS 2.5 (MXG 39.08).
VMAC7072 Change 41.096 added the new AI data in TYPE99 and
VMAC79 there were other APARs in 3.1, but we expect no issues.
Oct 26, 2023 -Dataset TYPE26J2 new variables:
SMF26UNL='SYS_HOLDUNTIL*DATETIME'
SMF26DNL='SYS_DEADLINE='DATETIME
SMF26JTK='SYS_JOBTOKEN*SIGNATURE'
SMF26JT1='LOCAL*JOB*SIGNATURE*ONE'
SMF26JT2='LOCAL*JOB*SIGNATURE*TWO'
SMF26TZO='GMT*OFFSET'
The GMT Offset is NOT exact, with values that follow the
SMFTIME, producing values of 09:29:59.28 .03 .05 .01
for South Australia which should be 9:30:00.00.
SMF26UNL and SMF26DNL haven't been tested with non-zero
and SMF26TSO is not added to them until validated.
-Dataset TYPE30_4 TYPE30_5 TYPE30_V new variables
SMF30JCLID1='LOCAL*JOB8SIGNATURE*ONE'
SMF30JCLID2='LOCAL*JOB8SIGNATURE*TWO'
SMF30JCLTOKEN='IDENTIFIER*FOR THE*JOB'
SMF30HOLDUNTIL'HOLDUNTIL*DATETIME'
SMF30DEADLINE='DEADLINE*DATETIME'
-The two changes for 26 and 30 were added by APAR OA64643.
-Dataset TYPE72GO new variable:
R723CPUCRIT='SERVICE*CLASS*IMPLICITLY*CPU CRITICAL'
Comment added for bit 7 R723MFLG WLMBATCH AI INFUSED
-Comment added for bit 7 for R791FLG3 in dataset TYPE791
and R792FLG3 in dataset TYPE792.
Change 41.091 Two JAVA memory options are found needed in z/OS CONFIGxx
ANALMSUS for graphs with ANALMSUS and may be needed for other uses
CONFIMXG of JAVA, even though REGION=0M was specified. JAVA
CONFIGxx required those min and max sizes to be at least 512m,
Oct 8, 2023 or the JAVA JVM failed to load.
JREOPTIONS=(
-Xmx512m
-Xms512m
-Dsun.java2d.fontpath=append:&SASHOME./
ReportFontsforClients/9.4
-With the above name for the FONTs directory, SAS messaged
that something in the fontpath was not a directory and
failed in the ODS and EXCELDEST statements. That error
was because the site had changed the SAS Default value of
NOCAPS to CAPS, which translates INPUT characters to
upper case. MXG hadn't previously had an issue with CAPS
so MXG does NOT force NOCAPS.
-However, the option NOCAPSOUT, SAS Default, z/OS only was
forced by Change 39.144 because ODS, USS, & Linux command
text in SASLOG messages needs to be printed in mixed case
so support can see the exact text that was used. That
change overlooked CONFIMXG, which is now corrected.
Thanks to Gene Pate, Hawaii Government, USA.
Change 41.090 TYPE99_6 dataset variables SERVER01-05 & SERVPN01-05 were
VMAC99 incorrect due to misalignment.
Oct 7, 2023
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 41.089 Cosmetic. INVALID DATA FOR RMFSTART SMF 79 SUBTYPE 15 has
VMACSMF no impact other than that message and a hex dump of the
VMACSMFL SMF record and possibly 4000+ lines of a PUT _ALL_ even
Oct 4, 2023 when NOT processing type 79 subtype 15 records. The _SMF
macro decodes the SMF Header and many Product Headers
and it expected all RMF records have a Product segment,
but the RMF 79.15 is documented that it doesn't, and the
MXG logic in VMAC79 for the actual decode of the full
79.15 record knows there isn't one, skipping that INPUT.
Now, the _SMF Header logic also skips that INPUT.
Thanks to Brian Sanger, Barclays, ENGLAND.
Thanks to Lalit Patil, Barclays, ENGLAND.
Thanks to Heimir Hauksson, Barclays, ENGLAND
Thanks to IBM Support whose time I wasted as this was an MXG error.
Change 41.088 For CICS CMF 110 SUBTYPE=1 MNSEGCL=1 Dictionary Records,
ASMDICTS ASMDICTS is a USER2 EXIT to IBM's IFASMFDP or IFASMFDL
ADOCDICT "SMF DUMP" programs that selects only the Dictionary
JCLDICTS records, skipping the other 110 records.
Oct 3, 2023
Change 41.087 CICINTRV now supports a ONEMINUTE value for _CICINTV for
VMXGCICI one minute statistics interval in CICINTRV dataset.
Sep 22, 2023
Thanks to Naveed Jeddy, ATOS, INDIA.
====== CHANGES THRU 41.086 ARE IN MXG 41.04 DATED Sep 20, 2023 =========
Change 41.086 %VGETOBS sets these values for &VGETOBS macro variable:
VGETOBS If the dataset does not exist, VGETOBS=0
Sep 19, 2023 If the dataset does exist, on DISK, VGETOBS= obs count,
so VGETOBS=0 if zero or the actual count of obs.
If the dataset does exist, on TAPE, and has two+ obs,
VGETOBS=1.
If the dataset does exist, on TAPE, zero obs, VGETOBS-0.
Note that finding the size of a dataset on a tape data
library requires reading the full tape until SAS finds
the dataset of interest, so this change to find that a
tape data set actually has observations can increase the
elapsed runtime significantly, and we have no solution.
And this also applies if the access method is SEQ to
read a SEQ dataset on disk, i.e LIBNAME PDB V9SEQ;
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 41.085 IBM confirms the Interval Duration in Subtype 6 and 7 of
TECHNOTE the TYPE 119 records can be either less than or greater
TYPE119 than the actual SMF Interval and they will not fix it.
Sep 19, 2023 The problem is that the STARTIME calculation depends on
the correct DURATM, and when the duration is less than,
the STARTIME is in a different 15 minute interval.
STARTIME=900*FLOOR((STARTIME+1)/900); WILL CORRECT.
but MXG won't use that and will preserve original values.
Thanks to Jorge Fong, City of New York, USA.
Change 41.084 Syntax error, single % where double %% is needed.
ASUMMSUS
Sep 19, 2023
Thanks to Gene Pate, Hawaii Government, USA.
Change 41.083 ARRAY RANGE EXCEEDED error with more than 256 SYSTEMs in
VMAC7072 the SMF file. Limit increased to 1024.
Sep 17, 2023
Thanks to Robert Olah, Ensono, USA.
Change 41.082 New initialization messages if the FORMATS library had
VMXGINIT not been created or if the FORMATS were not created by
Sep 16, 2023 the current version. This WARNING removed Change 42.046.
Change 41.081 Support for CICS/TS 6.2 BETA 16 INCOMPATIBLE. Inserted
VMAC110 new variable TCLSTSKS='ACTIVE +*QUEUED TASKS IN TRANCLASS
UTILEXCL
Sep 15, 2023
Change 41.080 Support for VIRTEL/VIRSTAT records, incompatibly changed
VMACVIRS in version 640/641.
Sep 14, 2023
Thanks to Ervin Claxon, CSX, USA.
Change 41.079 Variable GEIFLG22 could be wrong, typo lost end comment.
VMACRMFV Format CPUPHYAD CAN NOT BE FOUND when ZRBCPU has 0 obs?
Sep 14, 2023 Add ZRBCPU to ASMRMFV selection and/or Contact Support.
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 41.078 ERROR: FOLLOWING COLUMNS WERE NOT FOUND: FILEREF XENGINE
VMACSMF in the PROC SQL in %MACRO SMFFTP execution in VMACSMF was
Sep 14, 2023 found ONLY because there was an innocuous SAS Note
THE SAS OPTION CATCACHE WAS SET TO 0 BECAUSE SAS OPTION
MINSTG (MINIMUM STORAGE IS ON) that prevented those
columns from being created in the PROC SQL view of
DICTIONARY.EXTFILES.
Change 41.077 Corrected MIPS calculations. Only a problem if the LPAR
ANALCEC was not capped and the available MSU/MIPS were missing
Sep 12, 2023 values.
Change 41.076 Dataset Label TYPE71 corrected to 'RMF PAGING ACTIVITY'.
VMAC71 Starting in MXG 37.37, when TYPE71 was sorted, label was
Sep 8, 2023 TY71: deaccumulated dataset label.
Thanks to Raymond Smith, OPTUM, USA.
Thanks to Ronald W Bassett, OPTUM, USA.
Change 41.075 Change 41.063 corrected error in created IMACEXCL when
UTILEXCL ABCODEC (second ABEND CODE) was excluded but created new
Sep 6, 2023 CPUTM 10X LARGER THAN ELAPSED error when it wasn't.
Thanks to Daniel D. Hamiel, Nedbank, SOUTH AFRICA.
Thanks to Graeme G. Smeda, Nedbank, SOUTH AFRICA.
Change 41.074 On WINDOWS if you are installing a new release of SAS
TECHNOTE with STUDIO installed, you MUST disable some STUDIO
Aug 31, 2023 services. You will get an errors trying to create the
private java runtime directory because services have a
lock on the directory. From Windows Command Box, enter
SERVICES.MSC and scroll to find SAS and stop these tasks:
SASStudioSpawner
SASStudioWebAppServer
Change 41.073 Support for Subtype 36 SARR (CAVIEW) SMF Record populates
VMACSARR SARRU36 SARRT36 and SARRI36 datasets which previously had
Aug 29, 2023 zero observations.
Thanks to Steven W. Erkkila, USBank, USA.
Thanks to Troy Wegener, USBank, USA.
Change 41.072 CICS/TS 6.2 will suppress SMF records with zero-counting
TECHNOTE fields in these type of statistics (SMF 110 Subtype 2):
Aug 23, 2023 Interval Stata
Perform Stats (CEMT PERFORM STAT)
Perform Reset (CEMT PERFORM STAT RESET)
These types of statistics are NOT suppressed to reflect
there was a change in stats.
End of day statistics
(so zero-count ones will appear in SMF once a day).
Unsolicited statistics
In other types of statistics records just after the
resource is being created in CICS (to reflect the
change in stats.
This suppression is automatically enabled with no toggle.
-One region, 500,000 transactions, 97% not being used.
-75.8 MiB SMF data for transaction statistics DFHXMRDS
-saved per day.
-One region, 500,000 programs with 70% not used.
-40 MiB SMF data for Program Usage stats (DFHLDRDS)
savings per interval
Change 41.071 Variable CECSER6 is added to TYPE70/TYPE70PR/RMFINTRV for
VMAC7072 z/OS and to XAMSYS for Velocity.
VMACXAM CECSER ='CEC 4 DIGIT*SERIAL NUMBER*OF THE CEC'
VMXGRMFI CECSER6 ='CPC 6 DIGIT*SERIAL NUMBER*OF THE CPC'
Sep 12, 2023
Thanks to Douglas C Walter, CITIGROUP, USA.
Change 41.070 Dataset TYP11906 arbitrarily kept only 4 Home Address but
VMAC119 site has 5 so two new variables (IFADDLIx5) are added.
Aug 15, 2023
Thanks to Karl Lasecki, Chemical Abstracts, USA.
====== CHANGES THRU 41.069 ARE IN MXG 41.03 DATED Aug 11, 2023 =========
Change 41.069 MXG 41.03 Early Adopter ONLY. Missing asterisk caused
UTILEXCL errors in the created IMACEXCL.
Aug 9, 2023
Thanks to John Compton, Altair, UK
Change 41.068 %CLEARDB2 inserted by prior (unreleased) change 41.062
UTILBLDP caused STARTHR NOT FOUND in MOBWRK02.
Aug 7, 2023
Change 41.067 DB2H Header variables QWHCAID and QWHCOPID were increased
VMAC116 to $128 but VMAC116 also inputs both variables, but only
Aug 2, 2023 length $8. If DB2 and 116 are processed together and the
first reference is 116 - UTILBLDP(USERADD=116 DB2) - then
the DB2 variables were truncated. Both variables are now
set to $128 length in VMAC116 to protect the DB2 values.
Thanks to Harald Seifert, HUK-COBURG, GERMANY
Change 41.066 SMF 99 Subtype 9 INPUT STATEMENT EXCEEDED because the SMF
VMAC99 manual showed length of 5 for field at offset 91 in the
Jul 28, 2023 channel path data entry section but length is only one as
the next offset in the manual is 92. There was also an
INVALID DATA FOR S999CHNR because it's PIB.1. was missing
the second period, and the INPUT statement was missing
S999FLG1 AND S999FLGS, which are now added to the dataset
TYPE999I. The record also looks invalid as all fields
after S999FLGS are hex zeros.
Thanks to Mayank Vyas, ATOS, ???
Change 41.065 MXG 41.01 and 41.02, IDAA variables Q8STINSC to Q8STVLCS
VMACDB2 in lines 12303 to 12334 were shifted right beyond column
Jul 28, 2023 72, truncating the */ end of comment, which caused wrong
values but no error.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 41.064 Dataset TYP11910 variable UCLIPV6 was wrong, containing
VMAC119 blanks ('20'x or '40'x) for the first five segments for
Jul 27, 2023 Local IP addresses that were not IPV6 because the wrong
"High" bits variable was used in its calculation.
Thanks to Miguel Fco. Monferrer Carvajal, ITNOW, SPAIN.
Change 41.063 REPLACED BY CHANGE 41.075.
UTILEXCL If CICS field 114 ABCODEC is EXCLUDEd but 113 ABCODEO is
Jul 26, 2023 not, IMACEXCL wasn't aligned and you will likely get
ERROR.VMAC110 CPUTM 10X LARGER THAN ELAPSED and the
value in MCTSSDRL in that message is 4 less than
COL-SEGSTART. Change 38.113 originally circumvented.
This change detects the EXCLUDEd ABCODEC and sets macro
variable MXGCICSABCODELN=4 to correct the MXG error.
By default, UTILEXCL creates variable ABCODE $EBCDIC8.
from the two 4-byte fields ABCODEO and ABCODEC 113/114,
but if only ABCODEO 113 exists, that INPUT statement
needed to be ABCODE $EBCDIC4.
Thanks to Paul Beesley, ATOS, UK.
Change 41.062 Modified to check the value of LRGLRECL and if gt 32760
UTILBLDP and you have asked for BUILDPDB with CICS DB2 or you are
Jul 22, 2023 using USERADD to read 110 or DB2 data without the CICS
INFILE exit on zOS LRGLRECL is set to 32760 with:
MXGNOTE: LRGLRECL MODIFIED FROM &LRGLRECL TO 32760;
If DB2 data is being processed issues %cleardb2 before
reading data.
Change 41.061 Previously, use of ENCODING=EBCDIC1047 could cause wrong
VMXGINIT values and ENCODING=OPEN_ED-1047 was required to resolve,
Jul 18, 2023 as was documented in Change 37.267, but that is no longer
true, the same values are created with either ENCODING.
This change removes the ERROR message for EBCDIC1047 and
only prints the ENCODING value when MXGDEBUG is enabled.
Change 41.060 SORTS added to correct ERROR: BY VARIABLES WORK.GETCPA,
ANALMSUS that only occurred when multiple CECs data was analyzed.
Jul 17, 2023
Thanks to Robert Hamilton, Fifth Third Bank, USA.
Change 41.059 Total lines added to reports 7 and 8 and new report 9
UTILRMFI added that compares control and report class CPU times.
Jul 13, 2023 If total line on report 9 does not match between control
and report classes you cannot use report class to define
workloads.
Change 41.058 Blank or missing values for QWHCxxxx variables in the DB2
VMAC102 T102Snnn trace datasets can be due to the absence of the
Jul 14, 2023 Correlation Header, which is optional:
The DB2 manual on "start trace", specifies:
If you omit the TDATA option, correlation headers and
distributed headers (if present) are included by
default. However, I changed my command from:
START TRACE(STAT) DEST(SMF) IFCID(412) CLASS(11)
To:
-START TRACE(STAT) DEST(SMF) IFCID(412) CLASS(11) TDATA(COR)
And I am getting the data I expect.
Thanks to Robert Hagle, State Farm, USA.
Change 41.057 Variable QBACSYIT was not divided by 1E6 in the DB2ACCTP
VMACDB2 dataset.
Jul 11, 2023
Thanks to Scott Barry, SBBTechLLC, USA.
Change 41.056 Variable PCTMVSBY was not created in PDB.ASUMCELP.
VMXG70PR ANALCEC now recognizes the system is under z/VM.
Jul 5, 2023
Jul 17, 2023
Thanks to Naveed Jeddy, ATOS,
Change 41.055 No code change, example added:
UTILBLDP EXAMPLE 24.
Jul 4, 2023 BUILDPDB suppresses DB2 and CICS. Add 38, LLA, X37,
FTP, and TCP. Defer PDBAUDIT. Run ASUNSMFI ASUMJOBS.
After UTILBLDP run ASUMMIPS and %INCLUDE YOUR OWN CODE.
Finally, run PDBAUDIT.
Change 41.064 TYPE74CA storage variables CSCONF CSAVAIL CSPINNED CSOFFL
VMAC74 CNCONF and CNPINNED were displayed as MB but they are GB.
Aug 1, 2023 Originally documented in KB when R745SFT=1, now IBM sets
R745SFT=2 but the values are still in KB with either 1/2.
MXG now multiplies by 1024 for either value in R745SFT.
Thanks to Shivang Sharma, ENSONO, USA.
Change 41.053 Support for APAR OA62355 which adds new TYPE 30 Container
BUILD005 section, adding these variables to TYPE30_4 TYPE30_5
BUIL3005 and PDB.STEPS:
VMAC30 SMF30_CONTAINER_ID $EBCDIC64. /*CONTAINER*ID*/
Jul 1, 2023 SMF30_CONTAINER_QUAL $EBCDIC32. /*CONTAINER*QUALIFIER*
SMF30_POD_ID $EBCDIC64. /*POD*ID*/
Change 41.052 BMC CMF, TYPE 74 SUBTYPE 9 INPUT STATEMENT EXCEEDED only
VMAC74 if a PCIE Function was CONFIGURED online or offline.
Jun 29, 2023 Corrected by BMC APAR BQM1865 (available in May 2023).
The reconfiguration record created a PCIE Function ID
segment that did not have a matching Sync I/O segment but
R749SION was not a zero.
Thanks to Raymond J. Smith, OPTUM, USA.
Change 41.051 Variable WBIRISCN was misspelled in UTILEXCL as WBURISCN.
UTILEXCL Variable WBJSNRPL was misspelled in VMAC110 as WBJBNRPL.
Jun 29, 2023
Change 41.050 Previously, only ID=102 SMF records had Subtype GT 255,
FORMATS and MXG protected that ID, but now, SMF 98 records with
VMACSMF subtype 1024 & 1025 exposed an ancient circumvention for
Jul 2, 2023 for a bad MIM record that had only a one byte subtype.
That MXG fix input only MIM's first byte, but that one
byte input now, with subtype GT 255, incorrectly makes
the subtype value wrong, to a 4 for 1024/1025 or to 127
for a subtype of 32767. This change removes that code
and now, subtypes 0 to 32767 are now correctly input.
HOWEVER, the large subtypes impact the calculated value
of the ANALID reporting variable SMFIDSUB that has only
three subtype positions (098.001), creating an unexpected
value of 99.024 for the ID 98 Subtype 1024 record!
Fortunately, all of the ANALID reports use the $MGSMFID
format for printing SMFIDSUB, so adding an entry for
' 99.024'='098.1024' now displays the expected value,
avoiding a risky revision of the SMFIDSUB creation logic.
Change 41.049 -WIC SMF 98 CICS Subtype 1024 ABEND, INPUT STATEMENT WAS
EXTY98B1 EXCEEDED because only the Subtype 1 was documented in the
EXTY98B2 SMF Manual. Now, the z/OS Workload Interaction Correlator
EXTY98EX CICS 1024 WIC (an IBM Priced Product) is documented in
EXTY98JB HTTPS://WWW.IBM.COM/DOCS/EN/CICS-TS/5.6?TOPIC=CAEZWIC-
IMAC98 DATA-FIELDS-SMF-TYPE-98-SUBTYPE-1024-RECORDS
VMAC98 and this change creates four new datasets from the 1024.
VMXGINIT DDDDDD DATASET DESCRIPTIONS
Jun 26, 2023 TY98B1 TYPE98B1 CICS BUCKET 1
Jun 26, 2023 TY98B2 TYPE98B2 CICS BUCKET 2
Jul 2, 2023 TY98EX TYPE98EX CICS EXCEPTIONAL INDEX
TY98JB TYPE98JB CICS EXCEPTIONAL JOB
Thanks to Harald Seifert, HUK-COBURG, GERMANY
Change 41.048 -Cleanup of datasets that were left in //WORK after SORTs:
ANALID VMAC7072:
ASUMMIPS Delete WORK.TYPE70PR in _STY70.
BUILDPDB Delete WORK.TYPE70 WORK.TYPE72GO in _STY72GO
BUILDPD3 ASUMMIPS:
VMAC7072 Delete RMF70SUM RMF72SUM SMFSUM.
Jun 25, 2023 ASUMMIPS is now defined as a %MACRO so that you can
invoke only %ASUMMIPS; instead of having to specify
_RMFMIPS and _SMFMIPS. There is a single parameter
REPORTS= with a default of ALL which will run both.
REPORTS=RMF will run _RMF and REPORTS=SMF _SMF.
ANALID:
Delete SMFRECST.
-New TYPE30CP and TYPE30NP output to PDB in BUILDPDB/PD3.
-MXG 41.01 Only. SMF70MTTT wasn't DIF()'d missed semicolon
Change 41.047 The selection order for //SOURCLIB DD is from the FIRST
TECHNOTE DSNAME in the concatenation, but the selection order for
Jun 23, 2023 //CONFIG DD is the LAST DSNAME in the concatenation.
Change 41.046 ERROR 72-185 COUNTW HAS TOO MANY ARGUMENTS with SAS 9.1.3
TECHNOTE signals the death of that ancient version for MXG use.
Jun 20, 2023 The third argument was not added until SAS Version 9.2.
Fortunately, only six ancient (2013) Websphere Flat File
processing members VMACXD-fg/ns/sp/ss/ti/ts have the 3rd
argument, but they do cause JCLTEST9/TESSOTHR to ABEND.
Change 41.045 CICSEXCE Exception Records are only written for ABENDING
TECHNOTE tasks, so transactions that have long wait delays, but do
Jun 20, 2023 run (i.e., socket wait that eventually clears) won't have
observations.
Change 41.044 SMF Type 30s with SRVCLASS=SYSOTHER can be created by the
TECHNOTE Veloci-Raptor product documented in their note:
Jun 14, 2023 There is a very brief period of time during mode switch
or during a policy activation where SRM and WLM control
blocks are still being created. If SMF writes type 30
records during this time when the control blocks are
not present, it will record the address space as being
associated with service class SYSOTHER. So even if an
installation fully classifies all work, that site might
see an occasional job associated with SYSOTHER in 30s.
Change 41.043 Ten Dedicated Memory variables are added to ZRBASI.
VMACRMFV Four Dedicated Memory variables are added to ZRBGEI.
Jun 12, 2023 Thes fields are new in z/OS 3.1.
Change 41.042 Twelve sets of MIN/MAX/AVG Dedicated Memory variables are
VMAC71 added (new in z/OS 3.1) to TYPE71 dataset.
Jun 10, 2023
Change 41.041 SMF71GFX (MAX TOTAL 2GB FRAMES CAN BE USED) is added into
VMAC71 CSTORE replacing incorrect SMF71GRX (MAX 2GB PAGES FIXED)
Jun 7, 2023 which caused CSTORE to be too small.
Thanks to Ann Knapik, Progressive, USA.
Change 41.040 Dino Software's Veloci-Raptor subtype 5-6 and 16-21 have
EXVELO00 only the header thru DSNAME decoded so all are output in
IMACVELO new VELOST00 dataset with VELBUBTY format
VMACVELO
VMXGINIT
FORMATS
Jun 7, 2023
Thanks to Philip E. Barchat, Broadridge, USA.
Change 41.039 MXGDEBUG new option MACRO sets MPRINT SYMBOLGEN MLOGIC
VMXGINIT options and will display the ENCODING OPTION in effect of
Jun 6, 2023 MXGDEBUG is non-blank.
====== CHANGES THRU 41.038 ARE IN MXG 41.02 DATED Jun 5, 2023 =========
Change 41.038 -Support for CICS/TS 6.2 INCOMPATIBLE, FIELDS INSERTED,
UTILEXCL MANY WRONG VALUES (Neg TASZIPTM, MAXTASKS 3.2 Billion)
VMAC110 but no error messages. Tested now with OPEN BETA BUILD12.
May 31, 2023 -CORRECTION for CICS/TS 6.1 with default VMAC110 but was
Jun 4, 2023 ok if UTILEXCL was used to create an IMACEXCL for 6.1.
Default VMAC110 in 41.01 and earlier was misaligned, with
possible error message "CPUTM 10X LARGER THAN ELAPSED".
This change is in MXG 41.02 dated Jun 5, 2023.
June 4 "cosmetic" updates previously overlooked:
Variables now KEPT in CICSTRAN:
WBJSNRPL
Variables added to compiler faker (only to prevent an
"uninitialized variable" note if excluded):
ASFTCHTM=.; ASRMATTM=.; WMQASRTM=.;
ASFTCHCN=.; ASRMATCN=.; WMQASRCN=.;
WBJSNRPL=.;
Variables formatted TIME16.6:
ASFTCHTM ASRMATTM WBSVINTM WBURIOTM WBURIRTM
WBURISTM WMQASRTM
Change 41.037 Dino Software's Veloci-Raptor datasets were misaligned
VMACVELO after the header DSNAME field due to a 3 byte reserved
May 30, 2023 field that was not skipped. Only subtypes 1, 2, 3 & 4
have data fields described in the DSECT so only those
subtypes are processed, with subtype 3 and 4 both output
in VELOST04 pending documentation from the vendor.
Thanks to Phillip Barchat, Broadridge, USA.
Change 41.036 Support for TOKDANAM values XUHSTORY XUTIMING XUGROUPS in
VMAC80A TYPE80TK.
May 22, 2023 Support for EV44VAL length greater than 80 error messages
RACF EV(44) ERROR. INVALID RACFDLNN and INPUT EXCEEDED.
Thanks to Bheema Linga Prasad Kammara, NAB, AUSTRALIA.
Thanks to Bhuvaneshwari Shanmugam, NAB, AUSTRALIA.
Change 41.035 Support for DB2 TRACE IFCIDs 411 and 412 creates two new
EX102411 datasets:
EX102412 DDDDDD DATASET DESCRIPTION
FORMATS 102411 T102S411 APPLICATION STATISTICS
IMAC102 102412 T102S412 USER STATISTICS
VMAC102
VMXGINIT
May 19, 2023
Thanks to Rohini Bachina, FMR, USA
Change 41.034 JCL example creates EREP History File that MXG can read
VMACEREP //UNLTAP EXEC PGM=IFCEREP1,PARM='ACC=Y,PRINT=NO,ZERO=N'
May 16, 2023 //SERLOG DD DISP=OLD,DSN=SYS1.LOGREC
//ACCDEV DD DISP=(MOD,KEEP),DSN=EREP.HISTORY(0)
//TOURIST DD SYSOUT=*
//SYSIN DD DUMMY
//EREP EXEC MXGSAS
//SYSIN DD *
//EREP DD DSN=EREP.HISTORY(0),DISP=SHR
//PDB DD DSN=EREP.PDB(0),DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(TYPSEREP);
Thanks to Tom Medland, Kyndryl, USA.
CHANGE 41.033 Support for HIS SMF 113 MT Diagnostic Counters in dataset
ASUM113 TYPE1131 and ASUM1131 for z/OS.
VMAC113
May 12, 2023
Thanks to David Cogar, Wells Fargo, USA.
CHANGE 41.032 Format MG099PT created for variable S99CCCCPT to identify
FORMATS the processor type, CP or ZIIP. Labels changed to
VMAC99 S99CPUA ='MVS*CP*PERCENT*BUSY'
May 9, 2023 SMF99_SUPA='MVS*ZIIP*PERCENT*BUSY'
and format for SUPA now matches CPUA 5.1.
Thanks to Joe Faska, DTCC, USA.
CHANGE 41.031 Some tests for FOCVER=560 for VSAM records were found to
VMAC112 apply to FOCVER=550, causing UNKNOWN SUBSUBTYPE FFFF
May 5, 2023 message and no output.
Thanks to Murikipudi Devanand, ALLSTATE, USA.
CHANGE 41.030 If you did not execute the _SUOWSPN macro you got a
VMXGUOW DATASET NOT FOUND error for SPIN.SPINUOW. NODSNFERR and
May 5, 2023 NOVNFERR are now set at top of VMXGUOW and reset at end.
Thanks to Andy Mashburn, Trustmark, USA.
Thanks to Laura Bridges, Trustmark, USA.
CHANGE 41.029 Dataset NDMRT enhanced with 9 Parameter Value variables,
VMACNDM and 9 length of parameter values:
May 3, 2023 NDMRTPAR1='PARM*ONE'
Jul 27, 2023 NDMRTPAR2='PARM*TWO'
... ...
NDMRTPAR9='PARM*NINE'
NDMRTPARLEN1='LENGTH*OF*PARM*ONE'
NDMRTPARLEN2='LENGTH*OF*PARM*TWO'
... ...
NDMRTPARLEN9='LENGTH*OF*PARM*NINE'
NDMRTPARCT='COUNT*OF*PARMS'
Thanks to Kerry L. Turk, FMR, USA.
Change 41.028 -Version 2 of ASMRMFI for SPLIT70 processing.
ASMRMFI -GRBSMFR found to be leaving the reassembly area from
JCLRMFI the RSQ=1 "broken" (split) record of the set of records
JCLRMFIL used to reassemble long record. To prevent the long
May 7, 2023 record from being detected as a "broken" record, the
reassembly triplet will now be zeroed out for 7x
records longer than 32767 bytes.
-SYSPRINT added with identification and maintenance
levels and summary statistics showing basic counts of
records processed and actions performed.
-Return/reason code detection for records not converted
to "current" added.
-For Diagnostic S0C1 abends R15 now points to GRBSMFR
answer area.
-JCLRMFIL had invalid refer-back.
CHANGE 41.027 The _SMF header macro now populates VMSYSTEM, CPUTYPE,
VMACSMF PRODCMF and RMFSTART, to enhance the use of _SMF for the
VMACSMFL selection of SMF records to be read and reported, using
May 15 2023 %LET MACFILE= %QUOTE ( IF whatever ) ; for selection.
CHANGE 41.026 Support for Seasoft TRMS Version 7.02 new subtype 6 and 7
EXTRMS06 and new variables including decoding S05KEY. Datasets:
EXTRMS07 DDDDDD DATASET DESCRIPTION
FORMATS TRMS06 TRMS06 TRMS REPORT RESTORE
IMACTRMS TRMS07 TRMS07 TRMS REPORT TRANSFORMATION
VMACTRMS
VMXGINIT
Apr 29, 2023
Thanks to Tom Welch, ???, ???
Thanks to Larry Dinwiddie, Seasoft, USA.
Thanks to Randall Evans, Seasoft, USA.
Thanks to Hector Torres Aguilar, ATOS, MEXICO.
Thanks to Naveed Jeddy, ATOS, INDIA.
CHANGE 41.025 LARGE VALUE FOR LCPUPDTM message revised and LCPUPDTM is
VMAC7072 set to zero when LCPUPDTM GT DURATM+60 DETECTED. Problem
Apr 25, 2023 is under investigation, found only with LPARNAME=PHYSICAL
in ten cases in 12,000 type 70 subtype 1 records from 40
systems at z/OS 2.3 2.4 and 2.5.
CHANGE 41.024 CPCMSU was not carried into GROUP level datasets and
VMXG70PR caused an unitialized message. If you had multiple
Apr 25, 2023 systems with different GMT offsets it could fail with
data out of order because BY list was different for
the PROC SORT than the following PROC MEANS for the
GRCAPS2.
Change 41.023 Support for SMF 90 Subtype 42 BOOT VALIATION records
VMAC90A creates three datasets
IMAC90A DDDDDD DATASET DESCRIPTION
FORMATS T9042A TYP9042A BOOT VALIDATION AUDIT
VMXGINIT T9042B TYP9042B BAD BOOT CERTIFICATE
EXT9042A T9042C TYP9042C BOOT VALID CERT EXTRACT
EXT9042B APARs OA62783 and OA63507 create the new subtype.
EXT9042C
Apr 25, 2023
Change 41.022 Variable SMFTIME is not kept in TYPE30_1, TYPE30_4, and
TECNOTE TYPE30_5 datasets because it is stored in the variables
Apr 15, 2023 JINTTIME in 30_1, TERMTIME in 30_4 and JTRMTIME in 30_5.
Thanks to Phil J. Grasser, NSCORP, USA.
Change 41.021 MXG code to process Velocity Software zVPS VSICPU data
VMACXAM was misaligned causing very large (E75) values that were
Apr 14, 2023 not detected when the dataset was created, but caused
Floating Point errors when a PROC COMPARE was used to
read that dataset.
Thanks to Raymond J. Smith, Optum, USA.
Thanks to Ralph J. Romano, Optum, USA
Change 41.020 -Support for RACF Unload IRRDBU00 utility creates three
EXRA1210 new datasets
EXRAC20A TYPE DDDDDD DATASET DESCRIPTION
EXRAC2F0 02F0 RAC2F0 RACF02F0 EIM LDAPBIND PROFILE NAME
EXRAC530 020A RAC20A RACF020A MFA FACTOR
EXRAC5E0 1210 RA1210 RACF1210 MFA FACTOR TAGS
EXRAC5H0 05E0 RAC5E0 RACF05E0 CFDEF
FORMATS 05H0 RAC5H0 RACF05H0 MFA FACTOR DEFINITION
IMACRACF 0530 RAC530 RACF0530 GEN RES SSIGNON
VMACRACF -Record Types 0130 0208 0280 02B0 0508 are decoded into
VMXGINIT existing datasets.
Apr 14, 2023 -Dataset RACFID now has undecoded Record Types.
Their existing datasets had only header variables.
Thanks to Gaetan Martel, Intact, CANADA.
Thanks to Serge-TI Belanger, Intact, CANADA.
Change 41.019 -Support for new TYPE83MF Multi Factor Authentication
EXTY83MF dataset from SMF 83 Subtype 7.
IMAC83 -MG080SE format (IBM ICHRUTKN) new decimal value 21 added.
VMAC83
VMXGINIT
FORMATS
Apr 3, 2023
Thanks to Andre Gustavo Moretto, Kyndryl, USA.
Change 41.018 If you want to see/use the actual byte values for MGBYTES
FORMATS formatted variables, for example to download to a CSV and
Mar 31, 2023 plot with EXCEL, you can create this temporary format:
PROC FORMAT; VALUE MGBYTES;
to replace MXG's MGBYTES format. The temporary format
will only be used for the step/session with PROC FORMAT.
Change 41.017 If you wanted a report of INITs by SYSTEM, it failed
ANALINIT because JOBCLASS was hardcoded in some &SORTBY code.
Mar 30, 2023 Code was revised to support multiple &SORTBY values.
Thanks to Jim S. Horne, Lowe's, USA.
Change 41.016 DB2 SMF 102 IFCID 389 variable QW0389FF added causing MXG
VMAC102 INPUT STATEMENT EXCEEDED error. Now alignment corrected.
Mar 30, 2023
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
====== CHANGES THRU 41.015 ARE IN MXG 41.01 DATED Mar 24, 2023 =========
Change 41.015 More new Direct Memory (z/OS 3.1) variables were added to
VMAC30 the initial list in Change 40.087. The full set of new
Mar 21, 2023 variables are these:
S30DMREQUESTED2G S30DMMINREQUESTED2G S30DMASSIGNED2G
S30DMINUSEAS2G S30DMINUSEASFIXED1M
S30DMINUSEASPAGEABLE1M S30DMINUSEAS4K
S30DMINUSEASDATTABLES S30DMINUSEAS4KHWM
S30DMINUSEASPAGEABLE1MHWM S30DMINUSEASFIXED1MHWM
S30DMINUSEASDM2GHWM S30DMINUSEASDATTABLESHWM
S30DMINUSEHWM S30DM2GFAILED S30DM1MFAILED S30DM4KFAILED
S30NUMINUSEAS2GHWM S30NUM2GFAILED S30DMINUSEAS2GHWM
S30DM2GNOTAVAIL S30OBTAINSHOMESPACE
S30IARV64OBTAINHOMESPACE S30FRAMESFIRSTREFERENCEBACK
S30SUMREAL1M S30SUMSQUARESREAL1M S30NUMSAMPLES
S30HWMHVREAL1M
Change 41.014 -Variables P0RCDI and P1RCDI are now correctly FORMATTED
VMACBVIR as HEX4 instead of MGBYTES and removed from &MXGBYLN.
Mar 21, 2023 -Variable MAXAHCT was INPUT one byte too soon, +1 added.
Thanks to Pierre Pascal Joulin, SOCGEN, FRANCE.
Change 41.013 INPUT STATEMENT EXCEEDED for DB2NETZA Q8ST IDAA SMF 100
VMACDB2 SUBTYPE 1 DB2NETZA records, due to MXG error in heuristic
Mar 19, 2023 calculation of the offset to the next segment, BUT ONLY
if variable length field Q8STNAME is Less than 8 bytes.
This is not new MXG code and only one site so far has
seen the error and all prior test data did have 8 bytes.
You can circumvent the error with
%LET MACFILE= %QUOTE(IF ID=100 AND SUBTYPE=1) THEN DELETE;
in your SYSIN, or ask MXG Support to email the VMACDB2.
The site with this error is not actually using NETEZZA
and I'm asking IBM for help in understanding why the Q8ST
segment is created, can it be disabled, and where the
installation defines that character field and its length.
The LENQ8ST length of segment field is INPUT before the
loop so it is not updated for each instance of the Q8ST
segments. It was 897 for all three segments, but the hex
dump shows that they are 897, 900 and 900 bytes long.
Those wrong LENQ8ST values and the Q8STNAMELEN length of
QBSTNAME were used in MXG's heuristic calculation of the
location of the next segment, but that code was WRONG if
QBSTNAMELEN was NOT 8 bytes, causing the OFFQ8ST location
of next segment to be mis-aligned; the MXG calculation
logic error was also assisted by the undocumented 2-byte
field found after the Q8STNAME field.
That undocumented 2-field after the QBSTNAME field may
have been an IBM attempt to provide the actual LENQ8ST
for each segment, but its value is wrong, containing 898
(+2=900) in the first two segments when it should have
been 895 (+2=897) and 898 (+2=900). It has a value of 116
in the last segment, but that is not used as there is no
next segment, and there are 133 undocumented bytes after
it, and none of the other triplets point to that area.
Q8STNAME is the Accelerator Server Identifier and you can
verify the non-8 value in QBSTNAMELEN variable in the log
in the PUT _ALL_ after the hex dump if you get the ABEND.
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Change 41.012 -SAS Support for SPLIT70 LRECL GT 32760 Windows and Unix.
SASTECH Changes 40.140 40.150 150A 150B 41.003 and 40.011 require
SPLIT70 SAS HOT FIXES in SAS Note 69871 for ASCII Platforms.
Mar 10, 2023 A fix for this issue for Base SAS 9.4_M8 is available at
https://tshf.sas.com/techsup/download/hotfix/HF2/L8X.html#69871
A fix for this issue for Base SAS 9.4_M7 is available at
https://tshf.sas.com/techsup/download/hotfix/HF2/I9R.html#69871
-MXG (i.e. SAS) can read VBS records with LRECL greater
than 32K. However, IBM reassembly architecture of RMF
records (introduced in 2015 with z/OS 2.2) resulted in
splitting the data in the original long LRECL records
(have seen 3.7M) into records
smaller than 32k. This splitting resulted in related
triplet sections assumed by MXG coding to all to be in
the same record to no longer be a valid assumption. To
resolve the issue, reassembly of the original long
record was developed on z/OS, but during testing of the
reassembly process on SAS/PC, it was found that using
RECFM=S370VBS for the output LARGE LRECL, those files
were not being properly created. This hotfix addresses
that issue with SAS/PC.
Change 41.011 -Addition of ASMRMFI program using IBM GRBSMFR service
ADOCRMFI to reassemble "broken" (split) RMF (7x) long records
ASMRMFI (where the LRECL is greater than 32756 bytes)
JCLASMXG -Revision of ADOCRMFX to include reference to ASMRMFI
JCLRMFI - Addition of JCLRMFI assemble/link of ASMRMFI
SPLIT70 - ASMRMFI added to JCLASMXG
Mar 10, 2023
Change 41.010 Support for DB2 V13 new variables (COMPATIBLY ADDED).
FORMATS -New IFCID 396 creates new T102S396 dataset which is a low
EX102396 overhead trace record for index page splits, low overhead
IMAC102 as it's only generated when elapsed time of index page
VMXGINIT split is unusually high (GT 1 second) and provides both
FORMATS the UR ID and data sharing member number.
VMACDB2 -Variables added to DB2ACCT AND DB2STAT5 (IFCID 369):
VMAC102 QWAC_AIDB_FNS_ELAP='ELAP TIME*SQL DATA*INSIGHTS'
Mar 6, 2023 QWAC_AIDB_FNS_CP ='CPU TIME*SQL DATA*INSIGHTS'
QWAC_AIDB_FNS_ZIIP='ZIIP TIME*SQL DATA*INSIGHTS'
QWAC_AIDB_COUNT ='SQL DATA*INSIGHTS*EVENTS'
-Variables added to DB2STAT0 and DB2STATS:
Q9STCTDM='CMD*DIS*ML'
Q9STCTSM='CMD*START*ML'
Q9STCTPM='CMD*STOP*ML'
Q9STCTDR='CMD*DISPLAY*SERVICE'
Q9STCTSR='CMD*START*SERVICE'
Q9STCTPR='CMD*STOP*SERVICE'
Q9STCTS1='CMD*START*CDDS'
Q9STCTS2='CMD*STOP*CDDS'
Q9STCTBL='CMD*DISPLAY*BLOCKERS'
Q9STCTX6='CMD*RUN*MLUTIL'
Q9STCTX7='CMD*DISPLAY*STATS'
QSSTDISYES='64-BIT DISCARDDATA*KEEPREAL'
QDSTNLSC='ILOS*CANCELS*CPU*CONTENTION'
QDSTNAKD='CURR DBATS*ACTIVE*KEEPDYNAMIC*YES'
QDSTMAKD='MAX DBATS*ACTIVE*KEEPDYNAMIC*YES'
QDSTNDBT='DBATS*TERMINATED*SINCE DDF*STARTED'
QDSTNTPL='DBATS*TERMINATED*IN POOL GT*POOLINAC'
QDSTNTRU='DBATS*TERMINATED*REUSED*LIMIT'
QDSTDBPQ='CURR DBATS*SUSPENCED*PROFILE*EXCEPTION'
QDSTMDPQ='MAX DBATS*SUSPENDED*PROFILE*EXCEPTION'
-Variables added to DB2ACCT DB2STAT1 and DB2STATS
QXSTTIMEFROMAPPL='SET*CURRENT*LOCK*SQL8TIMEOUTS'
QXSTTIMEFROMPROF='SET*CURRENT*LOCK*PROFILE*TIMEOUTS'
-Variables added to DB2STAT1 and DB2STATS
QTPCGBP ='INFREQUENT*ACCESSED DS*PHYSICALLY CLOSED'
QTPCUT ='UTIL-ACCESS-ONLY*PHYSICALLY*CLOSED'
QTAUCNOT='PLANAUTH*CHECKS*NOT USE*PLAN AUTH CACHE'
QTAUCOW1='OVERWRITES*AUTHID*IN PLAN*AUTH CACHE'
QISTCONDLKF='FAILED*COND LOCK*DURING*INSERT'
QISTRETRYLK='FAILED*COND LOCK*RETRY*UNCOND'
-Variables added to DB2GBPST
QBGLWX='IXLCACHE*REQ WITH*ASYNC XI'
QBGLSU='IXLAXISN*SYNCH-UP*CALLS'
QBGLAS='IXLAXISN*SUSPENDS*AWAIT XI*TO COMPLETE'
-Variables added to DB2GBPAT
QBGBART ='DATA*AREA*RESIDENCY*TIME'
QBGBERT ='DIRECTORY*ENTRY*RESIDENCY*TIME'
Change 41.009 RMF Monitor III new data Data Gatherer Programmer Guide
VMACRMFV GC31-5701-50 dated Feb 20, 2023
Mar 2, 2023 -Dataset ZRBLCP New Variables
LCPUHPPW='HDW*PROC*PMA*WEIGHT'
LCPUMTNL='MAX*TOPOLOGY*NESTING*LEVELS'
LCPUCRD1='COORDINATE*NESTING*LEVEL*1'
LCPUCRD2='COORDINATE*NESTING*LEVEL*2'
LCPUCRD3='COORDINATE*NESTING*LEVEL*3'
LCPUCRD4='COORDINATE*NESTING*LEVEL*4'
LCPUCRD5='COORDINATE*NESTING*LEVEL*5'
LCPUCRD6='COORDINATE*NESTING*LEVEL*6'
-Dataset ZRBCPD new variables
CPDCCMC ='CHARACTERISTICS*PART'
CPDCCMD ='MEASUREMENT*PART'
CPDCCMX ='EXTENDED*CHAN*GROUP*DATA'
CPDPNETID1='PNETID*ACCESS*FROM*FIRST PORT'
CPDPNETID2='PNETID*ACCESS*FROM*SECOND PORT'
Change 41.008 Change 40.108 caused CSFRLSAV to be missing. CSTORE was
VMAC71 revised to include SMF71GRX, and relocated after GRX had
Mar 2, 2023 been input, but CSFRLSAV was not moved and depends on the
the value in CSTORE. CSFRLSAV moved to after CSTORE calc.
Thanks to Bradley Leis, TELUS, CANADA.
Change 41.007 The MIPS values for the z/16 processor types were added
FORMATS to the $MGRMIPS format.
Mar 1, 2023
Thanks to Arnold Kim, UPS, USA.
Thanks to Aylee ??, UPS, USA.
Thanks to Ggail??, UPS, USA.
Thanks to Jessica Sanchez, UPS, USA.
Thanks to dlicamara ??, UPS, USA.
Thanks to jrivera ??, UPS, USA.
Thanks to Dana A McCreary, UPS, USA.
Change 41.006 The variables in dataset ZRBASI added in Change 40.085
VMACRMFV ASI_EJST ASI_SRBT ASICPUTA_CP ASI_CP_PHTM
Feb 28, 2023 were 1000 times too small as they were incorrectly input
with &PIB.4.6 when they should have used &PIB.4.3.
Thanks to Graham Harris, NatWest, SCOTLAND.
Change 41.005 The test in line 1996 was corrected to SM113VN2 IN (5,6)
VMAC113 because the calculated L2P sourced-from variable was
Feb 26, 2023 non-zero in TYPE1131. Values in ASUM1131 were correct.
Thanks to Graham Harris, NatWest, SCOTLAND.
Change 41.004 TYPE89 variables SMF89ZNV SMF89SNF SMF80SEQ and
VMAC89 SMF89SOLUTIONID were off by one byte because a one byte
Feb 17, 2023 reserved field was not skipped.
Thanks to Joe Faska, DTCC, USA.
Thanks to Madison Harris, DTCC, USA.
Change 41.003 -Revisions to existing programs to reassemble "broken"
ADOCRMFX (split) RMF records into the original long (greater
ASMMACS than 32756 bytes) records
ASMRMFX -Addition of two new reassembly routines:
EXITRMFX RMFXIFUE an updated version of CICSIFUE to reassemble
JCLASMXG "broken" RMF records as well as decompress
JCLRMFXA CICS 110.1/112 and DB2 100/101/102 records for
JCLRMFXL 110.1 decompression, RMFXIFUE now checks for
JCLRMFXS records too short to contain the full length
RMFXE35 of the CICS product section and now chains
RMFXIFUE through the CICS product section to locate the
Feb 20, 2023 CRL field that indicates whether the record is
Mar 6, 2023 compressed. The 112 record mapping is now also
separate from the original single DSECT with
hardcoded offsets.
RMFXE35 a replacement for ERBPPE35 in the sample
RMF post-processing sort example that
front-ends ERBPPE35 to restore the swapped
fields from ERBPPE15 processing, then uses the
restored records to reassemble the "broken"
RMF records. All RMF records are written to
DDNAME LONGVBS to retain the processing
sequence while avoiding sort's record length
limitations.
-Addition of assemble and link steps for RMFXE35 and
RMFXIFUE in JCLASMXG
-Revision of ADOCRMFX to reflect current status of RMFX
members
-$CHGLOG member added to ASMMACS for tracking changes
-Revision to ASMRMFX to remove IBM RMF macros and replace
them with custom coding of the RMF product section data
structures
-Addition of program structure documentation to ASMRMFX
-Addition of EXITRMFX JCl to assemble and link RMFXIFUE
-Addition of JCLRMFXA example of ASMRMFX use
-Addition of JCLRMFXL example of ASMRMFX assemble/link
-Addition of JCLRMFXS example of RMFXE35 use
Change 41.002 Dataset TYPE123C variable SM123S2_API_REQ_NAME is the
VMAC123A same as variable SM123APISN in TYPE123A and TYPE1232 and
Feb 6, 2023 is needed for MERGEs, so variable SM123APISN is now added
to dataset TYPE123C.
Thanks to Wayne A. Schumack, USBank, USA.
Change 41.001 SMF 99 Subtype 1 INPUT EXCEEDED, unexpected S99SLLN=80
VMAC99 segment length when S99SLLN=104 was expected.
Feb 4. 2023
Thanks to Naveed Jeddy, ATOS, USA
Thanks to Vinod Kumar Panatula, ATOS, USA.
Thanks to Ashutosh Purohit, ATOS, USA.
Thanks to Mayank Vyas, ATOS, USA
Thanks to PURNENDU JOSHI, ATOS, USA.
LASTCHANGE: Version 41.
=========================MEMBER=CHANGE40================================
/* COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG VERSION 40.40 is dated Feb 3, 2023, thru Change 40.162.
MXG VERSION 40.07 was dated Jan 16, 2023, thru Change 40.154.
MXG VERSION 40.06 was dated Oct 23, 2022, thru Change 40.134.
MXG VERSION 40.05 was dated Aug 15, 2022, thru Change 40.101.
MXG VERSION 40.04 was dated Jun 29, 2022, thru Change 40.078.
MXG VERSION 40.03 was dated Jun 23, 2022, thru Change 40.077.
First MXG VERSION 40.03 was dated Jun 15, 2022, thru Change 40.073.
MXG VERSION 40.02 was dated May 5, 2022, thru Change 40.055.
MXG VERSION 40.01 was dated Mar 5, 2022, thru Change 40.032.
First MXG VERSION 40.01 was dated Mar 4, 2022, thru Change 40.031.
ANNUAL MXG VERSION 39.39 was dated Jan 5, 2022, thru Change 39.227.
New TECHNOTES previously in NEWSLTRS are now in CHANGESS.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 40.40 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 40.40.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains old Technical Notes. many of which are still
valid, but the last was in 2018. Now, TECHNOTES and FLASHes are in
CHANGES/CHANGESS. which are also online.
Member CHANGES contains the changes made in this current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
CHANGESS and NEWSLTRS are also online at http://www.mxg.com,
========================================================================
I. MXG VERSION 40.40 DATED Feb 3, 2023, THRU CHANGE 40.162.
==MAJOR CHANGES ADDED IN MXG 40.40, DATED Feb 3, 2023 THRU 40.162.====
ENHANCEMENTS
VMAC113 40.162 Support for z16 AI WAIUCPU/CAIUCPU/AIUCPU/AIUCPI
VMAC1154 40.158 Initial Support 4 subtypes of SMF 1154 Compliance
==MAJOR CHANGES ADDED IN MXG 40.07, DATED Jan 16, 2023 THRU 40.154.====
INCOMPATIBILITY SUPPORTED
TYPERMFX 40.150 IBM change to SMF 70.1 SPLIT records, TYPE70PR IMPACT
Requires REASSEMBLY of SPLIT into VBS LRECL GT 32760
Only sites with many LPARS & ENGINES have 70.1 splits
USE RMFSPLIT program to see if you have SPLIT 70.1.
See Change 40.150 and 40.150A for reassembly support.
ERRORS CORRECTED
VMXGGETM 40.147 UTILGETM utility Memory Failure SAS Hot Fix 66883.
VMACVMXA 40.141 OUT OF ORDER error sorting VXUSEACT, BY list wrong.
VMACVMXA 40.140 RNI in VXPRCMFC was always zero, ++ syntax accepted.
VMACCIMS 40.139 UOWTIME in CIMSTRAN wrong prevented CICSTRAN merge.
VMACDB2H 40.138 QWHCCTKN QWHCEUID QWHCEUTX QWHCEUWN not %U Unicode.
VMAC7072 40.137 BOOSTACTIVE=2 /*BOTH*/ was never tested.
VMXGINIT 40.136 SAS VIYA error, blank needed after close paren.
ENHANCEMENTS
VMAC115 40.154 Support for SMF 115 Subtype 216 creates TY115216.
ZMAC110 40.149 Possible Update for CICS/TS 6.2, not data tested yet.
VMAC99 40.148 Support for TYPE 99 Subtypes 9 and 10.
ASUM70PR 40.146 ICF LPARs can be output in ASUMCELP and ASUM70LP.
ANALCEC 40.145 New report on how LPARs on your CEC
VMAC102 40.135 DB2 Function Level 501 revised labels new fields.
==MAJOR CHANGES ADDED IN MXG 40.06, DATED Oct 23, 2022 THRU 40.134.====
ENHANCEMENTS
TYPE113 40.121 TYPE113 can only validly process one CPU type.
TYPE110 40.129 Support for CICS/TS 6.1 Stat variables in CICWBG.
TYPE110 40.129 Support for CICS/TS 6.1 new CICTLS Stat dataset.
GRAFCEC 40.126 Support for TREND data restored.
SMFMANUL 40.125 Updates from Sep 26, 2022 SMF Manual Refresh.
ERRORS CORRECTED
TYPE0 40.127 Zero obs in PDB.IPL dataset for some IPLs.
TYPE90A 40.107 Correction for TYPE9040 Boost variable SMF9040T.
TYPE30 40.105 INTBTIME/INTETIME Missing in SMFINTRV corrected.
TYPE7072 40.104 Variable SMF70TYP in TYPE70PR always 2:IIP.
UTILEXCL 40.100 CICS/TS 6.1 ERROR 22-322, comma should be period.
IBM APARS
TYPE7072 40.102 IBM APAR OA62064 corrects CPUSER/SMF70SER '5555'X.
==MAJOR CHANGES ADDED IN MXG 40.05, DATED Aug 15, 2022 THRU 40.101.====
ERRORS CORRECTED
UTILEXCL 40.100 CICS/TS 6.1 SOFLAG SYNTAX ERROR IN CREATED IMACEXCL.
TYPE30 40.098 MXG 40.01 only INPUT EXCEEDED,SMF30CONFOLOW invalid.
TYPE74 40.096 TYPE749 PCIE Statistics only first bucket was output.
VMAC119 40.086 TYP11911 variables corrected, formats updated.
VMAC73 40.084 Invalid counters SMF73CMG=2 when CHPID was Varied.
ENHANCEMENTS
VMXGHSM 40.099 z/OS 2.5 dataset SFSMSHSM new variables added.
VMACVMXA 40.095 Support for z/VM 7.2 MONWRITE VXPRCMFC HIS counters.
TECHNOTE 40.090 MXG Variables/Datasets that include RUCSA metrics.
VMACSVIE 40.089 New variables added to SV34TRAN and SV35TRAN.
VMAC42 40.088 Support for APAR OA59611 adds S42DS2MV
VMAC30 40.087 Dedicated Memory variables added.
VMACRMFV 40.085 New ZRBASI time variables added in z/OS 2.4 & 2.5.
BUILD005 40.082 Sixty variables added to TYPE30_4 now in PDB.STEPS.
==MAJOR CHANGES ADDED IN MXG 40.04, DATED Jun 29, 2022 THRU 40.078.====
Change 40.078 MXG 39.09 and earlier fail with APAR OA61811/OA62502.
VMAC7072 due to an MXG error for SMF 72 Subtype 3 TYPE72GO that
Jun 25, 2022 failed to test for new fields after the last segment,
which caused INPUT mis-alignment and invalid data values.
-WE STRONGLY SUGGEST YOU INSTALL THE CURRENT MXG 40.04
WHICH AVOIDS THE COMPLEXITY OF THE BELOW CIRCUMVENTION
AND PROVIDES SIGNIFICANT OTHER ENHANCEMENTS AFTER YOUR .
BACKLEVEL VERSION. PLEASE USE THE FORM AT
HTTPS://WWW.MXG.COM/SOFTWARE_DOWNLOAD_REQUEST
You can circumvent this MXG error by:
-Download files at http://www.mxg.com/downloads/
The APAR inserted new fields in SMF 72 Subtype 3 TYPE72GO
that exposed an MXG coding error that failed to test for
new added fields after the last new segment, causing the
INPUT misalignment and invalid data values to be created.
There MAY be INVALID DATA FOR R723IFAT messages or other
fields printed, but those are accidental and there might
not be ANY log messages that the error occurred. And even
if there are INVALID DATA messages, they do not set a
CONDITION CODE, so there may be no clue on the log that
the error occurred.
MXG 39.39 thru MXG 40.03 correctly input the new data.
but only this change or MXG 40.04 has the protection for
additional new fields in any future IBM updates..
PTFs: z/OS 2.3 UJ07991
PTFs: z/OS 2.4 UJ07990
PTFs: z/OS 2.5 UJ07989
==MAJOR CHANGES ADDED IN MXG 40.03, DATED Jun 23, 2022 THRU 40.077.====
ERRORS CORRECTED
VGETDDS 40.075 MEMBER FROM 40.02 REPLACED FIRST 40.03 MEMBER
VMXGSET 40.075 MEMBER FROM 40.02 REPLACED FIRST 40.03 MEMBER
VMAC42 40.076 ERROR: SHORT 42 SUBTYPE 6 ACCESS METHOD SECTION.
ENHANCEMENTS
VMACNDM 40.074 NDMCT new TLSVERSION variable (1.1,1.2,1.3) added.
==MAJOR CHANGES ADDED IN MXG 40.03, DATED Jun 15, 2022 THRU 40.073.====
ERRORS CORRECTED
VMAC110 40.063 CICSTRAN variables DSAPTHTM JVMTHDTM MAXHTDTM wrong.
VMACBVIR 40.056 Dataset BVIR302 had only half the observations.
ENHANCEMENTS
FORMATS 40.062 TYPE119SSH KEX_METHOD and KEX_ALG $MG119KX updated.
VMACEDGR 40.061 Datasets EDGRDEXT and EDGRXEXT updates.
VMACRMFV 40.060 RMF III updates for ZRBRED, and FORMATS.
BUILD005 40.057 Protection for DUPLICATE TYPE30 SUBTYPE 1 message.
NEW SUPPORT
VMAC80A 40.059 Support for SMF 80 RACFTYPE=67 updated TYPE8081.
VMAC90A 40.058 Support for APAR OA60660 for TYPE9040 BOOST.
==MAJOR CHANGES ADDED IN MXG 40.02, DATED May 5,2022 THRU 40.055.
CHANGE 40.042 in MXG 40.02 is REQUIRED for CICS/TS 6.1 BETA 25+
which removed fields from CICS 110 Records (May 2022)..
Change 40.001 in MXG 40.01 was required for CICS/TS 6.1 BETA 22
(March 2022) which also incompatibly changed the CICS 110 records.
TYPE30 ABEND with MXG 40.01 with z/OS 2.5 or APAR OA61511 that
is corrected by Change 40.050 in MXG 40.02.
ERRORS CORRECTED
ASMRMFV 40.028 -ASMRMFV now accepts PARM='F=Y,T=Y' syntax (CC=08)
ASMRMFV 40.036 Logic for ZEROLP option corrected for CPCDB.
TECHNOTE 40.040 IBM APAR PH40410 corrects negative DB2 QPACZITM.
TYPE0 40.039 z/OS 2.5 TYPE 0 IPL lengths 78/83 not in table.
TYPE30 40.050 Support for OA61511 Crypto/NNPI counts in SMF 0 & 30.
TYPE7072 40.034 TYPE70 vars SMF70PMT/SMF70PMU were corrected.
TYPEDCOM 40.038 Reserved fields overlooked, misalignment.
TYPERMFV 40.029 ERROR: ARRAY SUBSCRIPT 51 OUT OF RANGE ARRAY ALHTNEXT
VMXG70PR 40.035 Vars SMF70GMU/SMF70CPA/SMF70WLA missing in ASUMCELP.
VMXGUOW 40.041 LIBNAME PDB NOT FOUND if did not ask for MQ data.
==MAJOR CHANGES ADDED IN MXG 40.01, DATED Mar 5, 2022 THRU 40.032.
NEW MXG VERSION 40.01 REQUIRED FOR CICS/TS 6.1 BETA 22.
TYPE110 40.001 CICS/TS 6.1 BETA 22 INSERT NEW FIELD, INCOMPATIBLE.
ERRORS CORRECTED
TYPE74 40.005 R742PUTx variables in TYPE74PA divided by 1E-6 twice.
TYPE16 40.014 BAD SMF 16 DFSORT, JOB had S222, INPUT EXCEEDED
TYPEVMXA 40.010 Broken Control Record ABEND z/VM 7.2.21.02.
TYPERMFV 40.029 ERROR: ARRAY SUBSCRIPT 51 OUT OF RANGE ARRAY ALHTNEXT
TYPERMFV 40.028 -ASMRMFV now accepts PARM='F=Y,T=Y' syntax (CC=08).
ENHANCEMENTS
ASUM115 40.002 Summarization/Trending for MQ SMF 115 and 116.
All of these enhancements are described in the Change Log, below.
========================================================================
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M7 (9.4M7),
"M7", or with options VERSIONLONG;
"SAS 9.4 (9.04.01M7P080520)" on z/OS
9.4 (TS04.01M7P08052020)" on ASCII.
SAS V9.4 M7 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M6 or SAS Version 9.3 M0-M2.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.128 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But CONFIMXG is required for sites with NLS issues, and you must
use JCLCONFI to create/update the MXG.FORMATS catalog if you use
CONFIG='MXG.SOURCLIB(CONFIMXG)'.
For no NLS, you can use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 36.11 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 4.04 (04.04.01.00.005305 has been tested.
DO NOT USE 4.03.01 nor 4.04.00, INVALID CPU BUSY in TYPE70.
Error was introduced in 4.03.01 and 4.04.00. See Change 39.171.
Must be at 4.03.02.00.8569+ or 4.04.00.03.3277+/
WPS Version 4.01 USER 4037 ABEND, See Change 37.116.
WPS Version 4.0 reportedly fixed version 3 problems.
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
-Support for z16 processor data.
SMF: Only SMF 113 records were incompatibly changed, but there is no
execution error as only counter labels and values were changed,
causing coefficients for the calculated variables (RMI,etc) to
also be changed and default coefficients are changed to z16,
You must use separate SAS steps for each processor type and
read only SMF 113 from that processor type.
For z/15 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11F %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
and for z/16 you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA11G %
%INCLUDE SOURCLIB(TYPS113,ASUM113);
to get correct values in ASUM1131 dataset.
MXG Support for z/16 for SMF 113 requires 40.05 for z/OS and
40.03 for zVM.
MXG 40.01 will ABEND due to a TYPE30 error exposed by the z16.
Change line 1812 in VMAC30 from 192 to 220 or ask support for
the current VMAC30 member with Change 40.050.
Many other SMF and Data Gatherer records were updated in 40.04.
RMF ASMRMFV processes RMF III data with no errors, Change 40.068
added some new fields. New DNG3 table support was in 40.05.
-Support for z15 processor data.
The z15 and z15 T02 processors INCOMPATIBLY changed the SMF 113
records by inserting 32 new EXTEND and 4 CRYPTO counters, causing
ARRAY SIZE EXCEEDED with BUILDPDB which processes the SMF 113s.
Support for counter changes for both models was in MXG 37.08.
If you use MIPS in reports, the format $MGRMIPS provides the
MIPS/MSU value for each processor; the z15 values were updated
in MXG 37.08, and the z15 TO2 values were updated in MXG 38.04.
These MXG programs use $MGRMIPS: ASUMMIPS GRAFCEC GRAFWLM
GRAFWRKX and TYPERMFV (RMF III).
The z/14 also inserted SMF 113 fields, supported in MXG 36.07.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
And z/VM on the z15 requires MXG 38.02, PRCMFC/MFM COUNTERS caused
HARDWARE COUNTER messages, PRCMFC/PRCMFM no obs. Change 38.048.
The z13 processor INCOMPATIBLY CHANGED, the new SMT-MODE RMF 70, and
MXG 34.03 was REQUIRED (PCTCPUBY WRONG!), to read the SMT-format RMF
(which are written if you have zIIP engines AND have enabled the new
PROCVIEW CORE option for Multi-Threading, even if only one thread is
enabled).
SMF Back Levels: MXG 37.08 or later is required for both z15 & z16
SMF 113 change, but those back level versions could fail due
to other records changed by subsystem updates you made for the
z16 (e.g.CICS TS/6.1 which requires MXG 40.02) that didn't
exist when that back=level was created..
The new zEDC/EADM compression hardware requires MXG 38.05 to support
new metrics.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z/OS 2.4 Compatible from SMF Manual Sep 2019 37.166 37.07.
z/OS 2.4 Compatible from SMF Manual May 2020 38.105 38.05.
z/OS 2.4 Compatible from SMF Manual Apr 2021 39.075 39.03.
z/OS 2.4 Compatible RMF III PGMR Apr 1 2021 39.074 39.03.
z/OS 2.5 Compatible from SMF Aug 12,2021 39.06.
z/OS 2.5 Compatible RMF III Aug 12,2021 39.08.
z/OS 2.5 RMF III 4 new tables Aug 12,2021 39.08.
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
z15 New SMF 113 fields INCOMPAT Nov 18, 2020 37.08
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
z15 ANAL9914 Support CH 39.006 Jan 14, 2021 39.01
z16 NEW SMF113 values, NO ABEND See CHANGE 40.070 40.03
z16 MXG 38.07 OR LATER IS NEEDED.
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS/TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS/TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS/TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS/TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS/TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS/TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS/TS 3.2 Compressed Records Nov 3, 2007 25.11
CICS/TS 4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS/TS 4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS/TS 4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS/TS 4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS/TS 4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS/TS 5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS/TS 5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS/TS 5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS/TS 5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS/TS 5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS/TS 5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS/TS 5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS/TS 5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS/TS 5.3 GA date Dec 11, 2015 33.33
CICS/TS 5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS/TS 5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS/TS 5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS/TS 5.4 GA Jun 17, 2017 35.03
CICS/TS 5.5 GA (INCOMPAT) Jan 29, 2018 36.11
CICS/TS 5.6 GA (INCOMPAT) Jun 1, 2020 38.07
CICS/TS 5.6 NEW DATA (COMPAT) Oct 5, 2020 38.09
CICS/TS 6.1 ONE NEW (INCOMPAT) Jan 11, 2020 40.01
CICS/TS 6.1 ONE NEW (INCOMPAT) Sep 20, 2020 40.02
CICS/TS 6.1 UTILEXCL SOFLAG Aug 15, 2022 40.05
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
z/VM 6.40061802 ABEND Jan 22, 2019 37.02
z/VM 7.1 INCOMPAT ABEND Feb 14, 2019 37.02
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA-BROADCOM
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2, 5.3, 5.4 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 40.40.
1. Incompatibilities introduced in MXG 40.40:
a. Changes in MXG architecture made between 40.40 and prior versions
that can introduce known incompatibilities.
IF YOU HAVE MEMBER E2TY70 IN YOUR USERID.TAILORING SOURCE LIBRARY,
YOU MUST CHANGE _LTY70 to _WTY70 in that member. CHANGE 38.105.
The error before this correction will be:
ERROR: DATA SET "PDB.TYPE70" was not specified on the DATA stmt.
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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 40.40:
Dataset/
Member Change Description
ANALCEC 40.145 New report on how LPARs on your CEC
ASMRMFV 40.028 -ASMRMFV now accepts PARM='F=Y,T=Y' syntax (CC=08)
ASMRMFV 40.036 Logic for ZEROLP option corrected for CPCDB.
ASUM115 40.002 Summarization/Trending for MQ SMF 115 and 116.
ASUM70PR 40.146 ICF LPARs can be output in ASUMCELP and ASUM70LP.
BUILD005 40.057 Protection for DUPLICATE TYPE30 SUBTYPE 1 message.
BUILD005 40.082 Sixty variables added to TYPE30_4 now in PDB.STEPS.
FORMATS 40.062 TYPE119SSH KEX_METHOD and KEX_ALG $MG119KX updated.
GRAFCEC 40.126 Support for TREND data restored.
JCLRMFX 40.150 Support for IBM INCOMPATIBLE CHANGE RMF 70 ST 1.
SMFMANUL 40.125 Updates from Sep 26, 2022 SMF Manual Refresh.
TECHNOTE 40.040 IBM APAR PH40410 corrects negative DB2 QPACZITM.
TECHNOTE 40.090 MXG Variables/Datasets that include RUCSA metrics.
TYPE0 40.039 z/OS 2.5 TYPE 0 IPL lengths 78/83 not in table.
TYPE0 40.127 Zero obs in PDB.IPL dataset for some IPLs.
TYPE110 40.001 CICS/TS 6.1 BETA 22 INSERT NEW FIELD, INCOMPATIBLE.
TYPE110 40.001 CICS/TS 6.1 OPEN BETA 22 REQUIRES MXG 40.01 INCOMPAT.
TYPE110 40.042 -CICS/TS 6.1 BETA 25 removed fields, INCOMPATIBLE.
TYPE110 40.129 Support for CICS/TS 6.1 Stat variables in CICWBG.
TYPE113 40.070 -Support for z16 SMF 113 Labels and Equations INCOMPT
TYPE113 40.121 TYPE113 can only validly process one CPU type.
TYPE113 40.128 Code block for LSPRWKLD missing in TYPE1131/TYPE113.
TYPE16 40.014 TRUNCATED SMF 16 DFSORT record, INPUT EXCEEDED
TYPE30 40.017 TYPE30_4/30_5 EXCPTOTL wrong for MULTIDD='Y'
TYPE30 40.025 Support or OA61511 Crypto/NNPI counters ABEND 40.01
TYPE30 40.098 MXG 40.01 only INPUT EXCEEDED,SMF30CONFOLOW invalid.
TYPE30 40.105 INTBTIME/INTETIME Missing in SMFINTRV corrected.
TYPE7072 40.034 TYPE70 vars SMF70PMT/SMF70PMU were corrected.
TYPE7072 40.102 IBM APAR OA62064 corrects CPUSER/SMF70SER '5555'X.
TYPE7072 40.104 Variable SMF70TYP in TYPE70PR always 2:IIP.
TYPE74 40.005 R742PUTx variables in TYPE74PA divided by 1E-6 twice.
TYPE74 40.096 TYPE749 PCIE Statistics only first bucket was output.
TYPE90A 40.107 Correction for TYPE9040 Boost variable SMF9040T.
TYPEDCOM 40.038 Reserved fields overlooked, misalignment.
TYPERMFV 40.029 ERROR: ARRAY SUBSCRIPT 51 OUT OF RANGE ARRAY ALHTNEXT
TYPEVMXA 40.010 Broken Control Record ABEND z/VM 7.2.21.02.
TYPEZCOS 40.037 New ZCOS01TI='ZCOS*DATETIME' created.
UTILEXCL 40.100 CICS/TS 6.1 ERROR 22-322, comma should be period.
VMAC102 40.135 DB2 Function Level 501 revised labels new fields.
VMAC110 40.063 CICSTRAN variables DSAPTHTM JVMTHDTM MAXHTDTM wrong.
VMAC110 40.129 New dataset CICTLS (CICS TLS CIPHER) STID=151.
VMAC115 40.154 Support for SMF 115 Subtype 216 dataset TY115216.
VMAC119 40.086 TYP11911 variables corrected, formats updated.
VMAC1154 40.158 Initial Support 4 subtypes of SMF 1154 Compliance
VMAC30 40.087 Dedicated Memory variables added.
VMAC42 40.088 Support for APAR OA59611 adds S42DS2MV
VMAC7072 40.137 BOOSTACTIVE=2 /*BOTH*/ was never tested.
VMAC73 40.084 Invalid counters SMF73CMG=2 when CHPID was Varied.
VMAC80A 40.059 Support for SMF 80 RACFTYPE=67 updated TYPE8081.
VMAC90A 40.058 Support for APAR OA60660 for TYPE9040 BOOST.
VMAC99 40.148 Support for TYPE 99 Subtypes 9 and 10.
VMACBVIR 40.056 Dataset BVIR302 had only half the observations.
VMACCIMS 40.139 UOWTIME in CIMSTRAN wrong prevented CICSTRAN merge.
VMACDB2H 40.138 QWHCCTKN QWHCEUID QWHCEUTX QWHCEUWN not %U Unicode.
VMACEDGR 40.061 Datasets EDGRDEXT and EDGRXEXT updates.
VMACRMFV 40.060 RMF III updates for ZRBRED, and FORMATS.
VMACRMFV 40.085 New ZRBASI time variables added in z/OS 2.4 & 2.5.
VMACSVIE 40.089 New variables added to SV34TRAN and SV35TRAN.
VMACVMXA 40.095 Support for z/VM 7.2 MONWRITE VXPRCMFC HIS counters.
VMACVMXA 40.140 RNI in VXPRCMFC was always zero, ++ syntax accepted.
VMACVMXA 40.141 OUT OF ORDER error sorting VXUSEACT, BY list wrong.
VMXG70PR 40.035 Vars SMF70GMU/SMF70CPA/SMF70WLA missing in ASUMCELP.
VMXGGETM 40.147 UTILGETM utility Memory Failure SAS Hot Fix 66883.
VMXGHSM 40.099 z/OS 2.5 dataset SFSMSHSM new variables added.
VMXGINIT 40.136 SAS VIYA error, blank needed after close paren.
VMXGUOW 40.041 LIBNAME PDB NOT FOUND if did not ask for MQ data.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at https://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE
====== CHANGES THRU 40.162 ARE IN MXG 40.40 DATED Feb 3, 2023 =========
Change 40.162 New z/16 AI variables in TYPE1131 and ASUM1131 are added:
ASUM113 WAIUCPU='WAITING*FOR ACCESS*TO AIU'
VMAC113 CAIUCPU='EXECUTING*AIU'
Feb 2, 2023 AIUCPU='TOTAL*AIU*CPU'
AIUCPI='AIU*EXECUTING*CYCLES PER*INSTRUCTION'
These values and other z16 enhancements are in John
Burg's paper "How To Measure Those New z16 Capabilities"
from the IBM WSC Tech Bytes Conference, available at:
https://www.ibm.com/support/pages/wsc-tech-bytes-
conference-proceedings
Change 40.161 Format MG030NP for variable SMF30_NNPICTRS_ENTRY_ID in
VMAC30 dataset TYPE30NP decodes the 27 NNPA AIU Entry IDs.
Jan 29, 2023 Format MG030CP for variable SMF30_CRYPTRS_ENTRY_ID in
dataset TYPE30CP decodes the 156 Crypto Entry IDs.
Thanks to Mark C. Smith, IRS, USA.
Thanks to Mike R. Deneseus, IRS, USA.
Change 40.160 Variable S11912SS_SSH_SKEY_LEN in dataset TYPE11912SSH's
VMAC119 label was corrected from CLIENT to SERVER. The slash in
Jan 26, 2023 label for variable SMF119SC_SSH_CKEY_TYPE was removed.
Thanks to John Milne, Kyndryl, AUSTRALIA
Change 40.159 TYPE74ST variable R744QFLG was incorrectly formatted as a
VMAC74 one-byte $HEX2 value variable, but it is a bit-value and
Jan 27, 2023 these new variables decode the individual bits:
R744QFLG0='NORMAL*ACTIVE*INSTANCE*OF STRUCTURE'
R744QFLG1='NEW*INSTANCE*DURING*REBUILD'
R744QFLG2='OLD*INSTANCE*DURING*REBUILD'
R744QFLG3='JUST*ADDED OR*DELETED*INSTANCE'
R744QFLG4='IN HOLD*DELETION*NOT*FINISHED'
R744QFLG5='DUMP*INITIATED*FOR STRUCTURE'
R744QFLG6='STRUCTURE*REBUILD*IN*PROGRESS'
R744QFLG7='IN PROGRESS*REBUILD*IS DUPLEXING'
Thanks to Keith C. Shaffer, Cigna, USA.
Change 40.158 Initial support for 4 subtypes of SMF 1154 Compliance
EXB5401A-I Monitoring data. These are the 23 datasets created from
EXB5402A-B Subtype 01-04 and there are another 19 subtypes so this
EXB5403A-H will take some time to complete.
EXB5404A-D dddddd dataset description subtype
FORMATS B5401A TYB5401A TCP/IP STACK 01
IMAC1154 B5401B TYB5401B IPV4 CONFIG 01
TYPE1154 B5401C TYB5401C IPV6 CONFIG 01
TYPS1154 B5401D TYB5401D TCP CONFIG 01
VMAC1154 B5401A TYB5401A TCP/IP STACK 01
VMXGINIT B5401B TYB5401B IPV4 CONFIG 01
Jan 24, 2023 B5401C TYB5401C IPV6 CONFIG 01
B5401D TYB5401D TCP CONFIG 01
B5401E TYB5401E UDP CONFIG 01
B5401F TYB5401F GLOBAL CONFIG 01
B5401G TYB5401G PORT CONFIG 01
B5401H TYB5401H MANAGEMENT CONFIG 01
B5401I TYB5401I NETWORK CONFIG 01
B5402A TYB5402A FTP DAEMON GENERAL 02
B5402B TYB5402B FTP DAEMON DATA 02
B5403A TYB5403A TN3270 TELNET GENERAL 03
B5403B TYB5403B TM3270 TELNET GLOBAL 03
B5403C TYB5403C TN3270 TELNET PARMS 03
B5403D TYB5403D TN3270 PARMS GROUPS 03
B5403E TYB5403E TN3270 PARMS MAP 03
B5403F TYB5403F TN3270 LUMAP 03
B5403G TYB5403G TN3270 PRTMAP 03
B5403H TYB5403H TN3270 RESTRICT APPL 03
B5404A TYB5404A CSSMTP IDENTIFICATION 04
B5404B TYB5404B CSSMTP CONFIGURATION 04
B5404C TYB5404C CSSMTP TARGET SERVER 04
B5404D TYB5404D CSSMTP CONFIGURATION DA 04
Change 40.157 New variables in XMSYTCUV dataset:
VMACXAM LCXHGPCP='LPAR*GROUP*CAPACITY'
Jan 20, 2023 CALGCAPV='LPAR*GROUP*CAPPING'
LCUCWCPL='WAIT*COMPLETION*FLAG?'
LCUCCAPP='ON*PARTITION*CAPPING?'
LCXCCON ='CPU*ONLINE*FLAG?'
LCXPOLTP='CORE*POLARIZATION'
Change 40.156 Change 40.105 failed to remove the IF SUBSTEP GT 0 test,
SMFINTRV causing INTBTIME and INTETIME in PDB.SMFINTRV to still be
VMAC30 missing values. The corrected member was not moved from
Jan 20, 2023 the test to production sourclib.
Thanks to Peter A. Vikeras, OPTUM, USA.
Thanks to Raymond J. Smith, OPTUM, USA.
Thanks to Ralph J. Romano, OPTUM, USA.
Change 40.155 TYPE74 variables AVGIOQMS, DEVIOQTM and AVGRSPMS were
VMAC74 incorrect because they used NRREQENQ instead of SMF74IOS
Jan 20, 2023 for the duration. Variable AVGENQUE could also be missing
because it tested a "no longer used" bit in DEVIND that
is sometimes used!
Thanks to Jan Tielemans, KBC, BELGIUM.
====== CHANGES THRU 40.154 ARE IN MXG 40.07 DATED Jan 16, 2023 =========
Change 40.154 Support for SMF 115 Subtype 216 creates TY115216 dataset.
VMAC115
Jan 16, 2023
Change 40.153 TYPE8500 variables R850RC and R850RS labels incorrectly
VMAC85 had "TIME" but they are not time variables.
Jan 12, 2023
Thanks to Scott Rowe, SSA, USA.
Change 40.152 -TYPE71 variables SMF71S3A/SMF713S3M/SMF713S3X labels
VMAC71 were corrected from "ON SCM" to "IN CSTORE".
Jan 11, 2023
Thanks to Rick Southby, IAG, AUSTRALIA.
Change 40.151 -Variables added to SYSVIEW dataset SV34TRAN:
VMACSVIE IMTR_CLK_OPNCLS_ELAP='APPLICATION*OPEN/CLOSE*TIME'
Jan 3, 2023 IMTR_CNT_BYTES_IN ='TOTAL*INPUT*BYTES'
IMTR_CNT_BYTES_OUT ='TOTAL*OUTPUT*BYTES'
-Variables added to SYSVIEW dataset SV35TRAN:
IMRA_APPL_ELAPSED ='APPLICATION*ELAPSED*TIME'
IMRA_CNT_BYTES_IN ='AVERAGE*I/P*MESSAGE*BYTES'
IMRA_CNT_BYTES_OUT ='AVERAGE*O/P*MESSAGE*BYTES'
Change 40.150B Updates for Change 40.150 Split RMF 70 Subtype 1:
ASMRMFX ASMRMFX - ASM CODE FOR REASSEMBLY (USE IN JCLRMFX1)
JCLRMFXA JCLRMFXA- JCL TO ASSEMBLE ASMRMFX FOR REASSEMBLY
JCLASMXG JCLASMXG- Assemble all SEVEN MXG ASM MEMBERS
JCLRMFX JCLRMFX - Three STEP SAS REASSEMBLY JOB (TYPERMFX)
JCLRMFX1 JCLRMFX1- Three Step ASM REASSEMBLY JOB (ASMRMFX)
TYPERMFX TYPERMFX- SAS CODE FOR REASSEMBLY (USE IN JCLRMFX)
ASMMACS ASMMACS - MACROS FOR ASM PROGRAMS
ADOCRMFX ADOCRMFX- DOCUMENT REASSEMBLY PROGRAMS/JOBS
Jan 30, 2023 SEE CHANGE 41.012 for REQUIRED SAS HOT FIXES.
Change 40.150A Updates for Change 40.150 Split RMF 70 Subtype 1 were
JCLRMFX made. Only SMF 70 subtype 1 records are processed, the
TYPS7001 RMF 73 was included only because split 73s were available
Jan 15, 2023 for testing the reassembly and there is no need for any
other Split records to be reassembled at this time.
The TYPS7073 program was renamed to TYPS7001.
The TYPERMFX reassembly program works on z/OS with both
SAS and WPS, but does not currently work on ASCII; so we
are developing an ASMRMFX for ASCII sites.
Reassembled large LRECL records can be processed on ASCII
directly with the FTP ACCESS method using SITE RDW and
S370VS. or downloaded with RECFM=U,BLKSIZE=32760 and then
using S370VBS on the ASCII INFILE statement.
SEE CHANGE 41.012 FOR REQUIRED SAS HOT FIXES.
Thanks to Thomas D Foster, SSA, USA.
Thanks to Mark London, SSA, USA
Thanks to Ashley Klunk, SSA, USA
Thanks to Jaipal Nimmala, SSA, USA.
CHANGES THRU 40.150 WERE IN MXG 40.07 DATED Jan 16, 2023 Early Adopters
Change 40.150 -INCOMPATIBLE CHANGE TO SMF 70.1 FOR SITES CREATING SPLIT
ADOCRMFX SMF records. ONLY IMPACTS MXG TYPE70PR PR/SM DATASET.
FORMATS -ONLY SITES WITH LOTS OF ENGINES AND LPARS CREATE THEM.
JCLRMFX This program will tell you if you have split records:
RMFSPLIT //SPLITS EXEC MXGSAS94 (your SAS JCL Procedure)
TYPERMFX //SMF DD DSN=YOUR.SMF,DISP=SHR
TYPS7001 %INCLUDE SOURCLIB(VMACSMF);
VMAC7072 DATA;_SMF;IF ID=70 AND SUBTYPE=1;
VMACSMF INPUT @OFFSMF+47 NRCPUD &PIB.2.
VMACSMFL @OFFRMFP+74 SMF70RAN &PIB.2.
VMXGINIT @OFFRMFP+104 SMF70RBR &PIB.2.
Jan 16, 2023 @;
PUTLOG _N_= SYSTEM= SMFTIME= RMFSRCL= HEX2.
SMF70RAN= SMF70RBR= LENGTH= NRCPUD=;
IF NRCPUD=0, that SYSTEM uses the alternate algorithm and
its SMF 70.1 records must be reassembled, with MXG 40.07.
You can also use the 40.07 RMFSPLIT program report.
-SPLIT records are created when the length of data for an
interval exceeds 32760 bytes and multiple 32760 byte
blocks are created. If LPAR COUNT*ENGINE COUNT*88 is GT
26,000 you have split records (10 LPARS and 30 ENGINES).
APARs OA62064 and OA63108 changed IBM's "old" breaking
algorithm to the "new" breaking algorithm but with no
mention of that change!!!
-The good news with the new SPLIT records is that the
TYPE70 dataset is CORRECTLY created. It is ONLY the
TYPE70PR PR/SM dataset that has missing or incorrect
values that were previously populated from those
now-non-existent segments. Fortunately, there is no
execution error, just bad data in TYPE70PR and in the
ASUMxxxx datasets created from TYPE70PR.
-Previously, for the SMF70 Subtype 1 record, each SPLIT
record repeated the CPU Data Sections and the Logical
Core Sections, so the TYPE70PR PR/SM dataset could be
created, since some fields from CPUD and CORE segments
are needed, but the new algorithm no longer writes those
sections in the 2nd and subsequent SPLIT records, and
this broke the back of the MXG PR/SM implementation,
which had been designed to match the record contents.
-IBM Claims the change was NOT INCOMPATIBLE, stating that
it has ALWAYS BEEN A REQUIREMENT TO SORT and Reassemble
the split records into a single VBS Record with the
larger LRECL, (77,000 in this case), using the fields in
the Reassembly Area fields, but IBM does NOT provide a
utility to create those records, and neither IFASMFDP nor
DFSORT can process records with LRECL greater than 32760.
-The alternate splitting logic was already implemented
with z/OS 2.2 but with APAR OA62064 (which introduces
record level x'8F' for SMF 70 subtype 1) additional
fields were added to the CPU data section so that in
case of large LPARs with many processors it becomes more
likely that the alternate splitting is used.
-If the alternate algorithm is used, the value of NRCPUD,
the count of CPU Detail Sections, will be zero in the
second and subsequent split records, RMFSPLIT provides
that reporting, and NRCPUD is available in _SMF. header.
-In z/OS 2.5 IBM does offer the GRBRMFR service that can
be called to assist with the reassembly, but that service
will NOT be provided for z/OS 2.4 or earlier releases.
-The MXG Solution is the new TYPERMFX SAS program and the
example JCLRMFX whose first step Selects and SORTS the
70.1 and 73 SMF records (the SORT ensures split records
are in the correct order required for reassembly). The
second step uses the SAS TYPERMFX program to reassemble
and write out the Large LRECL records, which are then
read by the SAS TYPS7001 program in the third step to
create the TYPE70 TYPE70EN TYPE70PR and TYPE73 datasets,
and which %includes ASUM70PR to create these datasets
ASUM70GC ASUM70GL ASUM70LP ASUMCELP ASUMCEC
in the output PDB Data Library, which can then be used
for reports, and/or copied into the daily PDB library.
Changes made:
-JCLRMFX is the three step reassembly & PDB create job.
-TYPERMFX SAS program to reassemble into Large LRECL recs
-TYPS7001 reads LRECL SMF and creates the PDB.
-VMACSMFL replaces _SMF to use &LRGLRECL for SMF to input
the Large LRECLs and should only be used with JCLRMFX.
-VMACSMF and VMACSMFL were updated to decode SMF70RAN and
other RMF reassembly variables available for _SMF..
-FORMATS set RMFSRCL HEX2. so '8F'x is printed.
-VMXGINIT GLOBALs &LRGLRECL and sets it to 264000; the
largest reassembled LRECL was 77000 bytes.
-VMAC7072 was updated to add SMF70RAN/RBR/RSQ reassembly
variables to TYPE70.
-New RMFSPLIT program reads today's SMF data and alert
you if you have split records and whether data is lost.
-New member ADOCRMFX has detail documentation on the
Reassembly program TYPERMFX and the JCLRMFX example.
-SAS and WPS both work correctly with a download LRGLRECL
reassembled file with RECFM=U on the download.
-SEE CHANGE 41.012 FOR REQUIRED SAS HOT FIXES.
Change 40.149 -Support for CICS/TS 6.2 new fields added. New fields:
ZMAC110 XSNLNACT - DFHTASK 048 - FAILED AUOR NOLOG NOTAUTH
ZTILEXCL XSNLNFCT - DFHTASK 049 - FAILED AUOR NOLOG NOTFIND
FORMATS -SMFPSRVR is 75 for CICS/TS 6.2 so formats were updated:
Jan 8, 2023 MGVERCIC $MGVERCIC $MGSYIL
-The two members ZMAC110 and ZTILEXCL (ONLY in 40.40 with
BUILTBY= JAN 26, 2023 Change 40.149) are the updated code
for the CICS/TS 6.2, but they have not been tested with
6.2 Records. You can copy/rename them to UTILEXCL and
VMAC110 in your "USERID.SOURCLIB" to test and validate
this change, and advise of your success to support.
Thanks to Todd Gagle, Broadcom, USA.
Change 40.148 Support for TYPE 99 Subtypes 9 and 10.
VMAC99
Dec 2, 2022
Change 40.147 Array size of 2047,33165 required 550MB Region and caused
VMXGGETM Memory Failure errors if SAS Hot Fix 66883 for z/OS was
Dec 1, 2022 not applied. The array was much larger than was needed.
The first size (2047) is the number of possible SMF IDs
(2047) and 33165 was set to the number of combinations,
but it only needs to be the number of possible subtypes
for an ID. Current maximum subtype is 499 for the DB2
DB2 101 trace records, but 4096 was chosen since that
only requires a 110 MB REGION size. And, VMXGGETM is only
used to create a test file of two of your SMF records so
it's not routinely executed by UTILGETM.
Thanks to Allana Jacob, Kyndryl, CANADA.
Thanks to Pranav Yader, Kyndryl, CANADA.
Thanks to Amha Tsegaye, Kyndryl, CANADA.
Change 40.146 -Corrections to ASUMCELP dataset. SMF70LAC is now the MAX
ASUM70PR value to more accurately match SCRT reports, and GMTOFFTM
VMXG70PR and SMF70CPA are now populated.
Nov 28, 2022 -The ICF LPARS observations can now be created in ASUMCELP
Dec 3, 2022 and ASUM70LP datasets if you specify %LET ICFLPARS=YES;
before your %INCLUDE SOURCLIB(ASUM70PR) statement.
That will increase the number of obs in ASUMCELP/ASUM70PR
and most of the current LPAR variables will have missing
values, as only the ICF metrics are populated in the ICF
observations and the ICF metrics are missing values in
other LPAR observations. The ICF observations will have
LPARICFS NE 0.
Thanks to Joseph Montana, BKFS, USA.
Change 40.145 A report program that will show you in spreadsheet form
ANALCEC how the LPARs on your CEC are defined. It will tell you
Nov 21, 2022 how many MSU/MIPS are available to MVS based on the
Dec 25, 2022 lowest of cap values and CPUs assigned to LPAR.
Thanks to Miguel Fernandez, BNYMellon, USA.
CHANGE 40.144 The last line of MDIZERO was an unclosed comment causing
MDIZERO SLP to abend. MDIZERO now creates the OUT_DIR if it does
IEBUPDTE not exist. IEBUPDTE cosmetic updates with PUTLOGS.
Nov 21. 2022
Change 40.143 Change 40.103 was still incorrect, RECFM=VBS is needed to
VMACDCOL support any BLKSIZE value in the dumped DCOLLECT or IMS
VMACIMS VB records.
Nov 21, 2022
Thanks to Richard Egan, Westpac, AUSTRALIA.
Change 40.142 Uninitialized S30DM2GFAILED variable corrected, variable
BUILD005 D30DMINUSEADM2GHWM now output, and some labels for these
BUIL3005 new Dedicated Memory metrics were corrected.
VMAC30
Nov 18, 2022
Change 40.141 Variable CALTODON was incorrectly in the MACRO _BUSEACT
VMACVMXA sort list for VXUSEACT, causing an OUT OF ORDER error.
Nov 15, 2022 triggered by the Daylight Savings Time Change.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 40.140 -z/VM VXPRCMFC (SMF113 equivalent) RNI was always zero due
VMACVMXA to a typo that caused L3P to always be a missing value.
Nov 16, 2022 -Lines 6310 (z14/15) and 6375 (z16) creating L4RP both had
++ but the SAS Compiler did not flag that error, which
did not impact the value in L4RP for the z16, as all of
the EXTND counts in that statement were zero on this box
which only had one drawer. L4RP is non zero in others.
Thanks to Graham Harris, NatWest, SCOTLAND
Change 40.139 Change 37.095 incorrectly decoded UOWTIME which prevented
VMACCIMS merging CIMSTRAN and CICSTRAN datasets.
Nov 14, 2022
Thanks to Charles Piggott, R+V Allgemeine Versicherung AG, GERMANY.
Change 40.138 DB2 variables QWHCCTKN QWHCEUID QWHCEUTX QWHCEUWN are not
VMACDB2H %U Unicode fields, but MXG incorrectly converted them
Nov 3, 2022 with $ASCII128 informat (when they were "truncated" with
offset). Now they are converted with $EBCDIC128.
Thanks to Paul Weissman, UBS, USA.
Change 40.137 Bit test to set BOOSTACTIVE=2 /*BOTH*/ was never tested
VMAC7072 if either ZIP or SPEED boost was active.
Oct 26, 2022
Thanks to Peter J. Gray, ANZ DXC, AUSTRALIA.
Change 40.136 SAS VIYA error %SUBSTR(&SYSVER,1,1)EQ V needed a blank
VMXGINIT between the ) and the V.
Oct 26, 2022
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 40.135 DB2 ZPARM ADDED by Function Level 501 replacing FL 100.
FORMATS -T102S106 labels revised:
VMAC102 QWP4TSCT='COMPRESSION*TYPE*F=FIXED*H=HUFFMAN'
Oct 27, 2022 QWP4ENKL='ENCRYPTION*KEYLABEL'
Nov 14, 2022 QWP4AUTCSU='AUTH*COMPATIBILITY*SELECT FOR UNLOAD'
QWP4CDSTL='CACHDYN*BOTH*CAPTURE*LOAD*NONE'
QWP4CDRL='COMPRESS*DIRLOB?'
QWP4SFPR='STATFDBK*PROFILE?'
QWP4DDLM='DDL*MATERIALIZATION*IMMEDIATE*PENDING'
QWP4DINA='DEFAULT*INSERT*ALGORITHM'
QWP4PSPN='PAGESET*PAGENUM*ABSOLUTE*RELATIVE?'
-T102S106 new variables:
QWP4DSSAR='DISALLOW*SSARAUTH?'
QWP4UBCDC/*UTILS*BLOCK*FOR*CDC?*/
QWP4LIRO /*LOAD*RO*OBJECTS?*/
QWP4UZS /*UTIL*USE*ZSORT?*/
QWP4RINSU/*REORG*INDEX*NOSYSUT1?*/
QWP4RICLD/*REORG*IC LIMIT*DASD*/
QWP4RICLT/*REORG*IC LIMIT*TAPE*/
QWP4LDISCALE/*LOAD*DEL*IMPLICIT*SCALE*/
QWP4SUBSTRCP='SUBSTR*COMPATABILITY*P=PREV*C=CURR'
Thanks to Lai Fai Wong, Bank of America, USA.
====== CHANGES THRU 40.134 ARE IN MXG 40.06 DATED Oct 23, 2022 =========
Change 40.134 BMC CMF MXGWARN:IMPOSSIBLE VALUE DETECTED TYPE70PR CPU
VMAC7072 LCPUPDTM Dispatch Time z/16 Data under z/OS 2.4, not RMF.
Oct 21, 2022 MANY of those messages were printed, now limited to ten.
Nov 2, 2022 Some LCPUADDR engines had hundreds of hours of LCPUPDTM
Nov 14, 2022 Partition Dispatch Time for PHYSICAL LPAR. This message
has always and continues to set LCPUPDTM to zero,
Nov 2: BMC reports their error was introduced in BQM1809,
workaround is to back out BQM1809 and a circumvention is
given in that Case if you can't back it out.
Nov 14: BMC APAR BQM1868 will correct when available.
Change 40.133 New parameter added and now listed in alphabetic order.
ANALDB2R New LISTIDS=NO (DEFAULT) suppresses the reports from
ANALDBTR VFMT102 that listed all of the OBID DBIDs found and used
READDB2 in the PROC FORMAT. Generally only useful for debugging.
VFMT102
Oct 23, 2022
Change 40.132 DB2ACCTP variables QBACSYI QBACSYIT and QBACIOC were
VMACDB2 missing values because they were missing in the revised
Oct 19, 2022 INPUT statement.
Thanks to Raymond J. Smith, OPTUM, USA.
Thanks to Ralph J. Romano, OPTUM, USA.
Change 40.131 Support for new TYPE7 variable SMF7DTYPX to report flood
VMAC7 filtered SMF records for all types (0-2047), to replace
Oct 11, 2022 SMF7DTYP which was only one byte for only 0-255 records.
If the dropped record is greater than 255, SMF7DTYP will
contain 126, which is the extended type indicator value.
Change 40.130 Support for SMF 106, updated and validated with all four
VMAC106 records creating these four datasets:
Oct 11, 2022 (LABEL='TY1061: BCPII HWISET API CALLS'
(LABEL='TY1062: BCPII HWICMD API CALLS'
(LABEL='TY1063: BCPII HWIREST NO OPS API CALLS'
(LABEL='TY1064: BCPII HWIREST OPS API CALLS'
Thanks to Hans Langeveld, KLM, THE NETHERLANDS.
Thanks to Mark Duifs, KLM, THE NETHERLANDS.
Change 40.129 Support for CICS/TS 6.1 (COMPATIBLE) new vars/dataset:
EXCICTLS -New variables in CICWBG (CICS URIMAPS) STID=101.
FORMATS WBGENRFC='ENTRYPOINT*REF*COUNT'
SCICSORT WBGDIUTA='DIRECT*USER*TRAN*ATT'
VMAC110 WBGSJMSR='SCHEME*JMS*REQUEST'
VMXGINIT WBGSIIOR='SCHJEME*IIOP*REQUEST'
Oct 12, 2022 WBGPIPEL='PIPELINE*REQUESTS'
-New variables in CICSJS (JVMSERVER) STID=116.
SJSCOCAU='CODE*CACHE*USED'
SJSCOCAA='CODE*CACHE*ALLOCATED'
SJSDACAU='DATA*CACHE*USED'
SJSDACAA='DATA*CACHE*ALLOCATED'
SJSCLSTU='CLASS*STORAGE*USED'
SJSCLSTA='CLASS*STORAGE*ALLOCATED'
SJSCLCAS='CLASSCACHE*SIZE'
SJSCLCAF='CLASSCACHE*FREE'
-Cosmetic. CICS/TS 6.1 WARNING about SKIPPED FIELDS for
STID's 48 is now skipped, as the new fields are
reserved fields.
-New dataset CICTLS (CICS TLS CIPHER) STID=151.
OCCIPHER='TLS*CIPHER*CODE'
OCTLSINB='INB CICS*CONFIG*TLS*CIPHERS'
OCTLSOUT='OUT CICS*CONFIG*TLS*CIPHERS'
OCATTINB='INB ATTLS*CIPHERS'
OCATTOUT='OUT ATTLS*CIPHERS'
OCDATETM='TLS*DATETIME'
-This should be the last update to CICS/TS 6.1 SMF data.
Thanks to Rob D'Andrea, NATWEST, SCOTLAND.
Change 40.128 The Code Block to create variable LSPRWKLD was missing in
VMAC113 TYPE1131/TYPE113 datasets, but only TYPE1131/ASUM1131 is
Oct 6, 2022 used, as IBM no longer updates the subtype 2.
Thanks to Ronald W. Basset, OPTUM, USA.
Change 40.127 -WARNING SMF 90-10 WITHOUT PRECEEDING TYPE0 message and/or
VMAC0 zero observations in PDB.IPL dataset. DOWNTM calculation
VMAC90A revised and used to confirm ID=0 IPL SMF was found before
Oct 7, 2022 ID=90.10 IPL SRM.
-Blank LABELs in VMAC90A updated.
Thanks to Karthick Bojjireddy, HSBC, USA.
Change 40.126 A prior change dropped support for the TREND data. That
GRAFCEC is now restored and ODS PROCLIB added to make indices
Oct 4, 2022 more meaningful.
Thanks to Tom S. MacCabe, Dominion Energy Services, Inc., USA.
Change 40.125 Updates from Sep 26, 2022 SMF Manual Refresh.
VMAC74 TYPE74CA Variables R745INCR/BYTR/BYTW/RTIR/RTIW Reserved.
Oct 3, 2022 TYPE74CA Variables CSDS/CSIM reserved.
TYPE74DU Variable R744RFLG='STATUS*FLAGS'
TYPE75 Doc updated: UCBTYPE is only valid if Page Space
Type is not SCM, i.e., SCMPGTYP NE 'Y'.
Change 40.124 ERROR: UNABLE TO RESTORE 'BASE.FREQ.ONEWAYFREQA' FROM
PROC FREQ TEMPLATE STORE! is due to back level SAS at 9.1.3 and
Oct 2, 2022 issuing ODS commands in VMXGINIT. Install Current SAS.
Change 40.123 If a DB2 subsystem is restarted during the period covered
VFMT102 by the input SMF data, it is possible to get duplicate
Oct 1, 2022 values for a given DBID OBID. This change detects that
and flags the problem with an MXGWARN message and keeps
only the last OBS found when there is more than one.
Change 40.122 Typo, LENGT(& should be LENGTH(&
GRAFCEC
Sep 30, 2022
Thanks to Tom S. MacCabe, Dominion Energy Services, Inc., USA.
Change 40.121 TYPE113 can only validly process one CPU type at a time,
ASUM113 but prior to this change, all CPU types were incorrectly
VMAC113 output, and only observations from the default CPU type
Sep 30, 2022 (z15 in 40.02- SM113VN2=6, z16 in 40.03+ SM113VN2=7) or
the requested CPU type (if you reset MACRO _XLA113 per
Change 40.095) contained valid data values and correct
variable's labels. This change detects the value in MACRO
_XLA113 and only outputs those observations, printing an
MXGWARN message if other types were found in SMF data,
and creating 0 obs in TYPE113/TYPE1131 if no requested
CPU type records were found.
Note that if you have multiple CPU Types, z16 and z15,
you would use the default z16 in your normal BUILDPDB and
output the TYPE1131 and ASUM1131 datasets to your normal
PDB data library, and would run a second step, changing
changing _XLA113 to _XLA113F for the z15 and changing the
//PDB DD to a DIFFERENT DATA LIBRARY as the two datasets
TYPE1131/ASUM1131 CAN NOT BE COMBINED and they must be
separately analyzed. The simplest job is
// EXEC MXGSASV9
//SMF DD DSN=YOUR.SMF113.DATA,DISP=SHR
//PDB DD DSN=YOUR.Z15.TYPE113.PDB,DISP=OLD
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA113F % ;
%INCLUDE SOURCLIB(TYPS113,ASUM113);
but the more complete job which enhances the ASUM1131
data set with TYPE70PR data would be
// EXEC MXGSASV9
//SMF DD DSN=YOUR.SMF113.SMF70.DATA,DISP=SHR
//PDB DD DSN=YOUR.Z15.TYPE113.PDB,DISP=OLD
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA113F % ;
%UTILBLDP(BUILDPDB=NO,USERADD=7072 113,
OUTFILE=INSTREAM,
WANTSMF=70.1 113.1,
INCLAFTR=ASUM70PR ASUM113);
%INCLUDE INSTREAM; RUN;
You could tailor your BUILDPDB to create an SMF file with
only the needed SMF records for the second job adding the
//SMFOUT DD DSN=YOUR.SMF113.SMF70.DATA,DISP=(,CATLG). . .
and using
//SYSIN DD *
%LET MACFILE=
%QUOTE(
FILE SMFOUT DCB=SMF;
IF (ID=70 AND SUBTYPE=1) OR (ID=113 AND SUBTYPE=1)
THEN PUT _INFILE;
FILE LOG; );
-ASUM113 was corrected to CRYPTO83 instead of CRYPTO70.
Thanks to Ralph J. Romano, OPTUM, USA.
Change 40.120 Flag variables added to TYPE16:
VMAC16 ICETOOL ='CALLED*BY*ICETOOL?'
Sep 28, 2022 APFAUTH ='RUNNING*APF*AUTHORIZED?'
MOBJWORK='MEMORY*OBJECTS*USED FOR*WORK?'
JOINKEY1='INVOKED*JOINKEYS*SUBTASK 1?'
JOINKEY2='INVOKED*JOINKEYS*SUBTASK 2?'
Thanks to Pierre Pascal Joulin, SOCGEN, FRANCE.
Change 40.119 If you add type120 data to the PDB you could get an array
VGETSORT subscript out of range message in a weekly or monthly
Sep 27, 2022 job. VGETSORT is used to build a list of the datasets
that could possibly be added to the week or month and
includes the variables in the SORTEDBY list. This was
kept in an array that was 20 deep but some some of the
type 120 datasets have very long _B lists and exceeded
the array size. Array was expanded to 50.
Change 40.118 Unused Change Number
Sep 22, 2022
Change 40.117 Format MGXAMPO is created to map values of PFXPOLAR for
FORMATS the Polarization and PFXPOLAR is now a numeric value.
VMACXAM
Sep 21, 2022
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 40.116 New DB2 V12 variables added in DB2STAT0/DB2STATS:
VMACDB2 QTGSLCAIC QTGSDGBL QTGSLICNT QTGSGICNT QTGSGCONT
Sep 20, 2022 QTGSFCONT QTGSCPLOK QTGSCNOTY
New DB2 V12 variables added in DB2STAT1/DB2STATS and
DB2ACCTP and DB2ACCT:
QTXALCMM QTXALCMU QTXALCSM QTXACRLK QTXACWLK
QTXACRUK QTXACWUK QTXACRCH QTXACWCH QTXACRNT
QTXACNNT QTXACRCP QTXACWCP QTXACRAL QTXACWAL
QTXACWSY QTXASRCL QTXAUCNT QTXALCCP QTXACGEN
QTXACRQF QTXACWQF QTXADLCL QTXATOUT QTXARTRY
QTXANRTY QTXASUSP QTXARSUM QTXASTAT QTXADEAD
QTXATIME
Thanks to Scott Barry, SBBTechLLC, USA.
Change 40.115 Support for DB2 IFCID 314.
FORMATS Format MGD314R added.
VMAC102
Oct 11, 2022
Thanks to Lai Fai Wong, Bank of America, USA.
Change 40.114 UTILGETM/VMXGGETM ERROR: Array Subscript out of range.
VMXGGETM This utility, used only in JCLTESx program to create the
SMFSMALL file, still had the old limit of SMF Type values
of 256, but now the maximum TYPE is 2047, with 0-127 and
1152-2047 for IBM with 128-1151 available for users.
The actual record type in the record is 126, which tells
MXG this is an Extended SMF Header record with the true
ID in that header. The specific record was TYPE=1153,
the JES2 Monitor record.
Thanks to Jim S. Horne, Lowe's, USA.
Thanks to Saddam Hussain, Lowe's, USA
Change 40.113 Updates from Aug 23, 2022 SMF Manual:
VMAC7072 -TYPE70 new variable:
VMAC73 ALTVMMACHINE='RUNNING*UNDER*ALTERNATE*VM MACHINE'
Sep 10, 2022 -TYPE73 new variables:
Oct 17, 2022 SMF73NT1='PNET ID OF*ETHERNET*NETWORK*1ST PORT'
SMF73NT2='PNET ID OF*ETHERNET*NETWORK*2ND PORT'
-Note that no SMF 78 Subtype 3 records are written if your
system is running under an Alternate Virtual Machine.
-Oct 17: VMAC73 Early Adopter's 40.06 STOPOVER corrected.
Change 40.112 CICS TS/6.1 is SMFPSRVR 74 but FORMATs printed TS5.7.
FORMATS No impact on code as all tests are for 74.
Aug 6, 2022
Change 40.111 -The CICS Resource & Identity records, 110 subtype 1 with
TYPE110 MNSEGCL=5 or 6 create these seldom needed datasets that
UTILBLDP can take a lot of disk space and they compress poorly:
Sep 2. 2022 MNSEGCL=5 RESOURCE
COUNTER SEG DATASET
MNR5NUMI CICSRDS CICS RESOURCE DATA CLASS
MNR5NUMF CICSRDFI CICS RESOURCE FILE DETAIL
MNR5NUMT CICSRDQU CICS RESOURCE TSQUEUE DETAIL
MNR5NUMD CICSRDPL CICS RESOURCE DPL DETAIL
MNR5NUMU CICSRDUR CICS RESOURCE URIMAP DETAIL
MNR5NUMW CICSRDWB CICS RESOURCE WEBSVC DETAIL
MNSEGCL=6 IDENTITY
COUNTER DATASET
MNI6NUMI CICSIDNT CICS IDENTITY TRANSACTION INFO
MNI6NUMD CICSIDND CICS IDENTITY REALM/DISTING
They can be made zero obs dataset using
%LET MACFILE=
%QUOTE(
IF ID=110 AND SUBTYPE=1 AND MNSEGCL IN (5,6)
THEN DELETE; );
in your SYSIN, or with UTILBLDP by adding MNSEGCL5
and/or MNSEGCL6 or MNSEGCL to the SUPPRESS= parameter.
In addition, when TYPS110 is used, they are never sorted
nor written to the PDB data library, in VMAC110 comments:
MACRO S110:
/* SUBTYPE=1, CICS MONITOR DATASETS: */
/* _SCICTRN - CICSTRAN IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICRDS - CICSRDS IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICRDD - CICSRDPL IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICRDF - CICSRDFI IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICRDQ - CICSRDQU IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICRDU - CICSRDUR IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICRDW - CICSRDQB IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICIDN - CICIDNTY IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICIDD - CICIDNDD IS NOT SORTED TO PDB, HIGH VOLUME.*/
/* _SCICACC - CICSACCT NOT SORTED, PRE-CICS/ESA ONLY. */
/* _SCICSYS - CICSYSTM NOT SORTED, PRE-CICS/ESA ONLY. */
Change 40.110 -If you specified FIRSTRUN=YES and RUNWEEK=NO the SAS
BLDSMPDB OPTION OBS=0 was still in effect, causing all subsequent
Sep 2, 2022 datasets to have 0 OBS which could also cause an ERROR.
Thanks to Doug Medland, Kyndryl, CANADA
Change 40.109 ERROR 557-185:Variable SETPDB is not an object because
ANAL307X SET&PDBMXG..TYPExxxx was missing the blank between SET
Aug 30, 2022 and &PDBMXG.
Thanks to Karl Lasecki, American Chemical Society, USA.
Change 40.108 The LFAAREA was introduced in 2017 but no one noticed in
VMAC71 those 5 years that it was not included in the CSTORE size
Aug 30, 2022 which suggest memory is not the critical resource it once
was! Variable CSTORE is updated to include SMF71GRX,
the maximum frame size of the LFA, converted to bytes to
match CSTORE UNITS.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 40.107 Correction for TYPE9040 BOOST dataset SMF9040T/IBM _ETOD,
VMAC90A which is valid in both START and END event records, but
Aug 27, 2022 in the START record is the projected END of BOOST time.
and was incorrectly compared with SMFTIME to create the
GMTOFF9040 offset value. New variables:.
SMF9040STR the SMFTIME of the START event.
SMF9040EGMT the SMF9040T before GMTOFFSET in END
SMF9040SGMT the SMF9040T before GMTOFFSET in START
SMF9040TE the SMF9040T after GMTOFFSET in END
The last three variables are needed for the GMTOFF9040
calculation (by descending sort and retained from END.)
You must use %INCLUDE SOURCLIB(TYPS9040) or
%INCLUDE SOURCLIB(TYPE9040); _STY9040
because the GMT correction is in the dataset SORT.
-Note that the CAPTURAT in RMFINTRV can be over 100% in
Boosted intervals, and IBM says that is correct and will
eventually provide a documentation update.
Thanks to Peter Relson, IBM z/OS Core Design, USA.
Thanks to Jim S. Horne, Lowe's, USA.
Change 40.106 Support for new variables in MONITASK dataset, added by:
VMACTMO2 PTF TH04514 in V4.2 for CICS/TS 5 AND 6.
Aug 25, 2022 TAHWMRUL='RULE*RECORD'
TARECSEQ='RECORD*SEQUENCE*FLAG'
TAABNCD2='ABEND*CODE'
Thanks to Daniel D. Hamiel, NEDBANK, SOUTH AFRICA.
Change 40.105 Variables INTBTIME/INTETIME were missing if the first 30
VMAC30 was a subtype 2/3 for an OMVS (SUBSTEP GT 0) record.
SMFINTRV Change 25.089 set SMF30IST to missing IF SUBSTEP GT 0
Aug 24, 2022 because in 2007 it contained the original INITTIME and
not the current interval's start time, and could not be
used to create the GMTOFF30 (that MXG must calculate
because IBM has never put it in the 30 records!).
Now, the value in SMF30IST for OMVS jobs is valid and
no longer set missing and the INTBTIME/INTETIME are
now valid in that first 30 record.
See Change 40.156 correction.
Thanks to Ronald W. Bassett, OPTUM, USA.
Change 40.104 Variable SMF70TYP in TYPE70PR was always 2:IIP, while in
VMAC7072 TYPE70EN, it correctly mapped 0:CP 1:IFA 2:IIP, which are
Aug 22, 2022 the only engine types in TYPE70EN. But in TYPE70PR, the
Dec 10, 2022 correct variable is SMF70CIX which maps all five engines:
1:CP 3:IFA 4:IFL 5:ICF and 5:ZIIP. But now SMF70TYP does
correctly map it's three engine types in TYPE70PR.
Thanks to Pat Perreca, Wakefern, USA.
Change 40.103 The INFILE statement for IMSLOG didn't supply attributes
VMACDCOL LRECL and RECFM for the execution system, needed if they
VMACIMS are not supplied in the FILENAME IMSLOG statement. There
Aug 22, 2022 was also a logic error in both VMACIMS/VMACDCOL INFILEs.
Thanks to Ervin Claxon, CSX, USA.
Thanks to David Feimer, Luminex, USA.
Change 40.102 APAR OA62064 corrects invalid CPUSER/SMF70SER '5555'x
VMAC7072 values, although that is not stated in the text, which
Aug 18, 2022 notes that APAR introduces z16 support. IBM says the
bad serial number is also addresses in that APAR.
No change was made to MXG code.
Thanks to Rob D'Andrea, NATWEST, SCOTLAND
====== CHANGES THRU 40.101 ARE IN MXG 40.05 DATED Aug 15,2022 ==========
Change 40.101 TYPE6 ESS segments with GEPARNLN=0 are valid null values,
IMAC6ESS so the MXGERROR INVALID IMAC6ESS RECORD SKIPPED is now
Aug 8, 2022 only written if GEPARMNL GT LENGTH.
Change 40.100 CICS/TS 6.1 ERROR 22-322 using UTILEXCL -SOFLAG $CHAR4,
UTILEXCL the comma after CHAR4 should be a period.
Aug 8, 2022
Thanks to Gennady Katsnelson, Kyndryl, USA
Change 40.099 -Support for VMXGHSM DFSMSHSM Data Areas z/OS 2.5 Chap 15,
VMXGHSM DVL-Dump Volume Record adds these variables to HSMDVL:
Aug 6, 2022 DVLDEVT='SOURCE VOL*UCB TYPE'
DVLFVALD='VOLUME HAS*VALID COPIES'
DVLMEDIA='MEDIA*TYPE'
DVLSEQNR='SEQUENCE*NUMBER'
DVLSTACK='NUMBER*OF DUMPS*STACKED'
Thanks to Lindsay Oxenham, Defense, AUSTRALIA
Change 40.098 MXG 40.01 only. INPUT STATEMENT EXCEDED, INVALID data for
VMAC30 SMF30CONFOLOW because the INFORMAT &PIB.2 was missing the
Aug 4, 2022 final period, It should have been &PIB.2. with period.
Thanks to Mary Kay Pettengill, Sirius, USA.
Change 40.097 If you are using Luminex MDI you could get a S013 ABEND
MDIZERO in your z/OS job, if it did not produce any output in
Aug 4, 2022 SASLIST. This change adds a data step that creates a
single page of output to prevent the ABEND, You may want
to add this datastep to your tailored IMACINIT or to
every job you submit to the MDI from z/OS.
data _null_;
file print;
put 'page output to prevent s013 abend. Change 40;097';
run;
Change 40.096 Dataset TYPE749, PCIE Statistics, only output the first
VMAC74 SYNC I/O Response Distributions buckets. Sets of 10 FLG,
Aug 4, 2022 Read, and Write Range and Sample Counts are created.
Thanks to Raymond J. Smith, OPTUM, USA.
Thanks to Ralph J. Romano, OPTUM, USA.
Change 40.095 -Support for z/16 MONWRITE VXPRCMFC Hardware HIS data with
FORMATS z/VM Release 7.2.21.2 and new CRYPTO types in VXPRCAPM.
VMAC113 The z16 changed labels and uses different variables and
VMACVMXA coefficients in the RNI and other metrics calculations.
Aug 3 2022 The calculations/coefficients are correct for each CPU,
but the variable labels default to those for the z16.
To process z15 and get correct labels you must use:
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA113F %
Thanks to Graham Harris, NatWest, SCOTLAND.
Change 40.094 If you don't want to run a week but do want to run a
VMXGALOC month-to-date, both members had problems. VMXGALOC
BLDSMPDB did not create the MONTH directories and BLDSMPDB did
Aug 1, 2022 not execute the MTD code and tried to initialize the
non-existent week directories when FIRSTRUN=YES was
used.
Thanks to Doug Medland, Kyndryl, CANADA;
Change 40.093 Using the SAS FTP ACCESS method, the ftp process can hang
TECHNOTE if HSM is migrating the SMF data file either from disk to
Jul 26, 2022 or tape back to disk. Writing SMF data to tape will
eliminate the exposure.
Change 40.092 ANALMQ and ANALAVAI were not honoring the PDB= parameter,
ANALMQ instead always looked in DDNAME of PDB. Now, the PDB=
ANALAVAI argument is honored for the LIBNAME.
Jul 26, 2022
Change 40.091 The first step in moving MXG to a LUMINEX MDI is to copy
MDIZERO USERID.SOURCLIB from z/OS to LINUX. This JCL uses the
Jul 26, 2022 PROC SOURCE on ZOS to create an IEBUPDTE input file that
is then decoded and reconstructed on LINUX using the
IEBUPDTE.SAS program in the MXG Sourclib.
Change 40.090 MXG Variables/Datasets that contain/include RUCSA metrics
TECHNOTE Dataset TYPE78VS
Jul 26, 2022 R782FLG='RUCSA*IS*DEFINED?'
R782RUCA='RUCSA*ADDRESS*BELOW*16M'
R782RUCS='RUCSA*SIZE*BELOW*16M'
R782ERUCA='RUCSA*ADDRESS*ABOVE*16M'
R782ERUCS='RUCSA*SIZE*ABOVE*16M'
From IBM FIELD R782CSAU:
CSAUSED0='CSA*USED*MIN BELOW'
CSAUSED1='CSA*USED*MIN BELOW TIME'
CSAUSED2='CSA*USED*MAX BELOW'
CSAUSED3='CSA*USED*MAX BELOW TIME'
CSAUSED4='CSA*USED*AVERAGE BELOW'
CSAUSED5='CSA*USED*MIN ABOVE'
CSAUSED6='CSA*USED*MIN ABOVE TIME'
CSAUSED7='CSA*USED*MAX ABOVE'
CSAUSED8='CSA*USED*MAX ABOVE TIME'
CSAUSED9='CSA*USED*AVERAGE ABOVE'
From IBM FIELD R782CSAF:
CSAFREE0='CSA*FREE*MIN BELOW'
CSAFREE1='CSA*FREE*MIN BELOW TIME'
CSAFREE2='CSA*FREE*MAX BELOW'
CSAFREE3='CSA*FREE*MAX BELOW TIME'
CSAFREE4='CSA*FREE*AVERAGE BELOW'
CSAFREE5='CSA*FREE*MIN ABOVE'
CSAFREE6='CSA*FREE*MIN ABOVE TIME'
CSAFREE7='CSA*FREE*MAX ABOVE'
CSAFREE8='CSA*FREE*MAX ABOVE TIME'
CSAFREE9='CSA*FREE*AVERAGE ABOVE'
From IBM FIELD R782CSLF:
CSALARG0='CSA*LARGEST*FREE*MIN BELOW'
CSALARG1='CSA*LARGEST*FREE*MIN BELOW TIME'
CSALARG2='CSA*LARGEST*FREE*MAX BELOW'
CSALARG3='CSA*LARGEST*FREE*MAX BELOW TIME'
CSALARG4='CSA*LARGEST*FREE*AVERAGE BELOW'
CSALARG5='CSA*LARGEST*FREE*MIN ABOVE'
CSALARG6='CSA*LARGEST*FREE*MIN ABOVE TIME'
CSALARG7='CSA*LARGEST*FREE*MAX ABOVE'
CSALARG8='CSA*LARGEST*FREE*MAX ABOVE TIME'
CSALARG9='CSA*LARGEST*FREE*AVERAGE ABOVE'
From IBM FIELD R782CSAL:
CSAALOC0='CSA*ALLOC*MIN BELOW'
CSAALOC1='CSA*ALLOC*MIN BELOW TIME'
CSAALOC2='CSA*ALLOC*MAX BELOW'
CSAALOC3='CSA*ALLOC*MAX BELOW TIME'
CSAALOC4='CSA*ALLOC*AVERAGE BELOW'
CSAALOC5='CSA*ALLOC*MIN ABOVE'
CSAALOC6='CSA*ALLOC*MIN ABOVE TIME'
CSAALOC7='CSA*ALLOC*MAX ABOVE'
CSAALOC8='CSA*ALLOC*MAX ABOVE TIME'
CSAALOC9='CSA*ALLOC*AVERAGE ABOVE'
Dataset TYPE71 IBM NAME
CSAPGAV ='CSA TOTAL*CSTORE*FRAMES*AVERAGE' SMF71AVP
CSAPGMN ='CSA TOTAL*CSTORE*FRAMES*MINIMUM' SMF71MNP
CSAPGMX ='CSA TOTAL*CSTORE*FRAMES*MAXIMUM' SMF71MXP
CSLPFXAV='CSA FIXED*CSTORE*FRAMES*AVERAGE' SMF71AVC
CSLPFXMN='CSA FIXED*CSTORE*FRAMES*MINIMUM' SMF71MNC
CSLPFXMX='CSA FIXED*CSTORE*FRAMES*MAXIMUM' SMF71MXC
Change 40.089 New variables added to dataset SV34TRAN:
VMACSVIE IMTR_CNT_SYNCPOINT='TOTAL*SYNCPOINT*COUNT'
Jul 26, 2022 IMTR_CLK_SYNC_ELAPSED='SYNCPOINT*ELAPSED*TIME'
IMTR_CLK_OSAM_SYNC ='OSAM*SYNCPOINT*TIME'
IMTR_CLK_VSAM_SYNC ='VSAM*SYNCPOINT*TIME'
IMTR_CLK_APPL_ELAPSED='APPLICATION*ELAPSED*TIME'
New variables added to dataset SV35TRAN:
IMRA_SYNC_ELAPSED ='TOTAL*SYNCPOINT*ELAPSED*TIME'
IMRA_DB2_ELAPSED ='TOTAL*DB2*ELAPSED*TIME'
IMRA_MQ_ELAPSED ='TOTAL*MQ*ELAPSED*TIME'
IMRA_DB2_SQL ='TOTAL*DB2*SQL*CALLS'
IMRA_SYNCPOINT ='TOTAL*SYNCPOINT*COUNT'
IMRA_OSAM_SYNC ='TOTAL*OSAM*SYNCPOINT*TIME'
IMRA_VSAM_SYNC ='TOTAL*VSAM*SYNCPOINT*TIME'
IMRA_APPL_ELAPSED ='APPLICATION*ELAPSED*TIME'
Change 40.088 Dataset TYPE42DS variable S42DS2DL is labeled and new
VMAC42 variable S42DS2MV is created. APAR OA59611.
Jul 18, 2022.
Change 40.087 Dedicated Memory variables added to TYPE30_4 (PDB.STEPS),
BUILD005 and TYPE30_V (PDB.SMFINTRV).
BUIL3005 S30DMREQUESTED2G S30DMMINREQUESTED2G S30DMASSIGNED2G
VMAC30 S30DMINUSEAS2G S30DMINUSEASFIXED1M
Jul 18, 2022 S30DMINUSEASPAGEABLE1M S30DMINUSEAS4K
S30DMINUSEASDATTABLES S30DMINUSEAS4KHWM
S30DMINUSEASPAGEABLE1MHWM S30DMINUSEASFIXED1MHWM
S30DMINUSEAS2GHWM S30DMINUSEASDATTABLESHWM
S30DMINUSEHWM S30DM2GFAILED S30DM1MFAILED S30DM4KFAILED
S30DMINUSEAS2GHWM S30DM2GFAILED
Change 40.086 -Dataset TYP11911 Variable SMF119SC_SSH_KEX_METHOD is now
FORMATS created and the incorrect spelled SMF119SC_SSH_KEX_ALG is
VMAC119 set to '0000'X and LABELed 'DO NOT USE'.
Jul 15, 2022 -Format $MG119KX METHOD and $MG119KA ALGORITHM updated to
match the z/OS 2.5 IP Programmer's Guide values.
Thanks to Joe Faska, DTCC, USA.
Change 40.085 New ZRBASI time variables added in z/OS 2.4 and 2.5
VMACRMFV ASI_EJST='TCP*PROCESSOR*TIME*ALL TYPES'
Jul 12, 2022 ASI_SRBT='NON-PREMPT*SRB TIME*ALL TYPES'
ASICPUTA_CP='ALL*NONENCLAVE*TIME*ON CP'
ASI_CP_PHTM='PREEMPT*CLASS SRB*TIME*ON CP'
Change 40.084 TYPE73 data for SMF73CMG=2 Channel Measurement Group has
VMAC73 counters with invalid counts if the CHPID was VARIED in
Jul 11, 2022 the interval. These variables are now set missing for
those intervals CHFACTV/DFER/RATE/XACTV/XDFER/CHFXRATE
PBUSBY PCHANBY PNCHANBY SMF73EOC/EOD/EOS/ETC/ETD/ETS/PUC
TBC/SMF73TUC.
The three Channel Measurement Groups are described as:
1 - Channels like CNC or CTC
2 - Ficon or OSA Express
3 - Hypersockets
Thanks to Vance Breckenridge, FMR, USA.
Change 40.083 If you specified PATHLIST=YES to get a report of the
PDBAUDIT active LIBNAMES there were duplicate lines (SAS only)
Jul 8, 2022 caused by the return of 4 lines per LIBNAME from the PROC
SQL. A sort was added with NODUP to eliminate the extra
lines.
Change 40.082 There are 60 variables added by IBM to the TYPE30_4 data
BUILD005 that were not also added to the PDB.STEPS BUILDPDB data
BUIL3005 set, that are now added for completeness:
Jul 6, 2022 ASID CPUZIPTM_CPUIFATM_INST ENCLACTM ENCLCPSU
ENQTIME EXCPERR EXSRMERR IARVAPIN IARVEPIN IARVPSEC
IEFUSICH IEFUSIME SMF30ACB SMF30ACR SMF30CAI SMF30CCR
SMF30CHC SMF30CONFLAG1 SMF30CONFLAG2 SMF30CONFLAG3
SMF30CONFOLOW SMF30CR SMF30CRM SMF30DAS SMF30DSCC
SMF30HQT SMF30INV SMF30JF1 SMF30JQT SMF30NCR
SMF30NRDS SMF30PCF SMF30PF1 SMF30PF2 SMF30PFF
SMF30PFL SMF30PIN SMF30PRJ SMF30RQT SMF30RTR SMF30SCF
SMF30SLM SMF30SME SMF30SQT SMF30T32 SMF30T33 SMF30TF2
SMF30TIH SMF30TIS SMF30TIU SMF30_INCOMPLETE_DATA
SMF30_INSTCAPTDISRUPTION SMF30_INST_FLGS1_MRS
SMF30_RAXFLAG5 SMF30_RAXFLAG6 SMF30_RCMTADJN SRBCOEFF
SRMNODAT SUBSTEP WLMNAME
Change 40.081 If you did not have an SMF DD or FILENAME statement and
VMACSMF your program tried to read SMF data you got a very odd
Jul 5, 2022 failure caused by the failure to create the SMFENG macro
variable. The variable is now initialised to NO SMF
INFILE FOUND and will be set to DISK or FTP with SAS or
a blank value with WPS.
Change 40.080 In the process of debugging the problem for which 40.006
VMXGSUM was the fix we added an UPCASE function as well as a
Jul 5, 2022 COMPBL function against the incode. Since all character
compares in SAS are case sensitive this can cause an
invalid compare if you are trying to compare values in
the INCODE and are expecting a lower case value. This
change removes the UPCASE but leaves the COMPBL which was
really the solution to the problem.
Thanks to Matthew I. Chappell, Queensland Government, AUSTERALIA
Change 40.079 NOTE: "Variable LENTYP50 may not be initialized" had no
VMAC50 real impact, as that variable was only to be kept and was
Jun 30, 2022 not actually used. Now, correctly set to LENGTH.
Thanks to Randy Schlueter, Fiserv, USA.
====== CHANGES THRU 40.078 ARE IN MXG 40.04 DATED Jun 29,2022 ==========
Change 40.078 MXG 39.09 and earlier fail with APAR OA61811/OA62502,
VMAC7072 due to an MXG error for SMF 72 Subtype 3 TYPE72GO that
Jun 25, 2022 failed to test for new fields after the last segment,
which caused INPUT mis-alignment and invalid data values.
PTFs: z/OS 2.3 UJ07991
PTFs: z/OS 2.4 UJ07990
PTFs: z/OS 2.5 UJ07989
-WE STRONGLY SUGGEST YOU INSTALL THE CURRENT MXG 40.04
WHICH AVOIDS THE COMPLEXITY OF THE BELOW CIRCUMVENTION
AND PROVIDES SIGNIFICANT OTHER ENHANCEMENTS AFTER YOUR .
BACKLEVEL VERSION. PLEASE USE THE FORM AT
HTTPS://WWW.MXG.COM/SOFTWARE_DOWNLOAD_REQUEST
You can circumvent this MXG error by:
-Downloading files at http://www.mxg.com/downloads/
The APAR inserted new fields in SMF 72 Subtype 3 TYPE72GO
that exposed an MXG coding error that failed to test for
new added fields after the last new segment, causing the
INPUT misalignment and invalid data values to be created.
There MAY be INVALID DATA FOR R723IFAT messages or other
fields printed, but those are accidental and there might
not be ANY log messages that the error occurred. And even
if there are INVALID DATA messages, they do not set a
CONDITION CODE, so there may be no clue on the log that
the error occurred.
MXG 39.39 thru MXG 40.03 correctly input the new data.
but only this change or MXG 40.04 has the protection for
additional new fields.
Change 40.077 -Variables SYNCNCIN SYNCNCON SYNCKEXN are added and they
FORMATS are decoded by format $MGSYNNG. Format $MGSYNEQ updated
VMACSYNC for 'C9'X for SORTL.
Jun 24, 2022 -Format $MGSYNNG for Reason Code is missing values of
Nov 14, 2022 '06'x '07'x '0F' '10'x '11'x '13'x '18'x
Nov 21, 2022 -Variable SYNCEQLS is a multi-bit flag variable that is
correctly decoded, but to identify SORTL was used, you
must test the values of '08'x or 'C9'x so now there are
eight one=byte variables for each bit for simpler tests:
SYNSOTRP='SORTOUT*DATA*STRIPING?'
SYNSITRP='SORTIN*DATA*STRIPING?'
SYNBPSI ='BATCHPIPES*MVS*DATASET*SORTIN?'
SYNBPDS ='BATCHPIPES*MVS*DATASET*PRESENT?'
SYNEQUON='EQUALS*ON?'
SYNCMPO ='COMPRESSED*SORTOUT*WITH*STARTIO?'
SYNCMPI ='COMPRESSED*SORTOUT*WITH*STARTIO?'
SYNSORTL='SORTL*ALGORITHM*USED?'
Thanks to Jan Tielemans, KBC, BELGIUM.
====== CHANGES THRU 40.076 ARE IN MXG 40.03 DATED Jun 23,2022 =========
Change 40.076 ERROR: SHORT 42 SUBTYPE 6 ACCESS METHOD SECTION due to
VMAC42 a reserved field that was overlooked.
Jun 23, 2022
Thanks to Robert Chavez, Florida Power & Light, USA.
Change 40.075 Members VGETDDS and VMXGSET in First MXG 40.03 were
VGETDDS replaced with those members from 40.02, Change 40.072
VMXGSET "enhanced" those members to support more than 99 DDs, but
Jun 23, 2022 the enhancement could fail (only one report).
Change 40.074 Variable TLSLEVEL 1.1/1.2/1.3 is added to NDMCT dataset.
VMACNDM
Jun 21, 2022
Thanks to Luis Mendoza, BKFS, USA.
====== CHANGES THRU 40.073 ARE IN MXG 40.03 DATED Jun 15,2022 =========
Change 40.073 S11912SAFLAGX40,20,10,08,04 were byte-tested ('80'X) so
VMAC119 only one bit was tested, but the field can have multiple
Jun 14, 2022 bits so the fields now are bit-tested ('1.......'B).
Thanks to Tom White, Bank of America, USA.
Thanks to Charlie Carlson, Bank of America, USA.
Change 40.072 Hardcoded limit of 99 DDs in VMXGSET limited VGETDDS.
VGETDDS Limit replaced by better logic with no limit; IBM has
VMXGSET increased the maximum number of generations to 999.
Jun 10, 2022
Thanks to Scott Barry, SBBTechLLC, USA.
Change 40.071 Explanation of DB2 differences with PROC COMPARE.
VMACDB2 -DB2ACCT QB1C/QB2C/QB3C/QB4C suffix HPG/HRE/HRF/HWF/HWR
VMACDB2H and SWU are always missing values after Change 39.200,
Jun 5, 2022 they were replaced by SYIT/SYI/IOC/RSV3/RSV2/RSV1.
All other DB2ACCT variables matched.
-Datetime variables QWHSSTCK BEGTIME ENDTIME MXG 39.04+
(Change 39.099) were 26 seconds early due to MXG logic
that creates DB2GMTDB GMT Offset (IBM does not provide)
which incorrectly thought leap seconds were included in
the TODSTAMP fields. The subtraction was removed.
BUT: No site ever reported that 26 second delta!
-DB2STAT4 QW0225 variables are larger; were 4 bytes now 8,
and _REAL now includes _AUX & _DPAGE. (and AUX is 12288).
Variable QW0225_WARN is corrected to bytes from blocks.
-Datasets DB2ACCTR DB2ACCTW DB2STAT1 and DB2STAT2 match.
-Dataset DB2ACCTB variables QBACCIOD/SYI/SYIT are also
missing after Change 39.200 which reused their slots..
-All Q8ACxxxx and Q8STxxxx variables are only populated
with DB2NETEZZA.
Change 40.071 SMF42 Subtype 6 enhanced with new TYPE42DS variables:
VMAC42 S42JDVER='VERSION*NUMBER'
Jun 2, 2022 S42JDST1='STEP*NUMBER'
S42JDSTN='STEP*NAME'
Change 40.070 Support for z16 HIS SMF 113 data.
VMAC113 -Many labels are changed, and different counters are used
ASUM113 for RNI and the other metrics so the default support in
Jun 2, 2022 40.03 is only for the z16 metrics. You will need to use
separate jobs/steps to process each hardware platform.
For the z/15 SMF you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA113F %
and for the z/16 SMF you would use
//SYSIN DD *
%LET MACKEEP= MACRO _XLA113 _XLA113G %
(or just use the default without a %LET statement.
Change 40.069 Updates from May 22, 2022 SMF Manual:
VMAC30 -TYPE30_4 TYPE30_5 TYPE30_6 TYPE30_V datasets
VMAC7072 New variables:
VMAC74 SMF30CONFOLOW SMF30CONFLAG1-SMF30CONFLAG3
VMAC90A
May 31, 2022
Change 40.068 Updates from May 24, 2022 Data Gatherer Manual:
VMACRMFV -ZRBASI dataset
May 31, 2022 New flag variables:
ASITRGRP='TENANT*RESOURCE*GROUP?'
ASIRCVBO='RECOVERY*BOOST?'
-ZRBLCP dataset
New variable
LCPUTOPC='TOPOLOGY*HAS*CHANGED'
-ZRBDNG NEW Dataset:
Await Test Data to update ASMRMFV and then VMACRMFV.
Change 40.067 -Service policy selection correction post-IPL checking to
ASMRMFV enable sample set BEG/END time to coincide policy's.
May 30, 2022 -Cosmetic: correct RMFV008 DSORG alignment
-Cosmetic: match ASM field names to match VMACRMFV
-Restored REDID type variables to correct type
-Errors processing UWDG3 record corrected.
-Two sites have received CC=4 due to the BEG/END & REDIT
change, because IBM Data Gatherer Support has been unable
to replicate the warning, and we need to know if other
sites have the issue. If so, please use SENDVSAM to send
your VSAM RMF III file so we can get it to IBM support.
-It is also possible to get CC=4 for "WARNING:DEAD SPACE"
but we are examining if that should be INFORMATIONAL for
the next iteration of ASMRMFV.
Change 40.066. Variable ECMTSTMP in z/VM dataset VXSYTEPM was wrong; it
VMACVMXA was not scaled by 128 microseconds.
May 27, 2022
Thanks to Scott Barry, SBBTechLLC, USA.
Change 40.065. TYPS103 ERROR: Attempt to open two sequential members
VMAC103 if //PDB was on tape. The _STY1032 sort macro had //PDB
May 27, 2022 library for both the INPUT and OUTPUT.
Thanks to Cesar V. Cocco, JPMorgan Chase, USA.
Change 40.064. Reserved Change.
May 31, 2022
Change 40.063. Variables DSAPTHTM JVMTHDTM MAXHTDTM in CICSTRAN are
VMAC110 correct if UTILEXCL was used to create your IMACEXCL,
May 24, 2022 but those variables were NOT divided by 4096 (for STCK)
if you didn't use UTILEXCL and didn't have an IMACEXCL.
This change adds the missing /4096 for those variables.
And WTOTIOTM was also wrong because it includes DSAPTHTM
Thanks to Lorena Ortenzi, Kyndryl, ITALY.
Thanks to Alessandro Cappobianco, Kyndryl, ITALY.
Change 40.062. Dataset TYP11912SSH variable S11912SS_SSH_KEX_METHOD and
FORMATS S11912SS_SSH_KEX_ALG that are formatted with $MG119KX did
May 20, 2022 not decode new values added by z/OS 2.4. Now values are:
VALUE $MG119KX
'0000'X='UNKNOWN'
'0001'X='NONE'
'0002'X='DIFFIE-HELLMAN-GROUPEXCHANGESHA256'
'0003'X='DIFFIE-HELLMAN-GROUPEXCHANGESHA1'
'0004'X='DIFFIE-HELLMAN-GROUP14-SHA1'
'0005'X='DIFFIE-HELLMAN-GROUP1-SHA1'
'0006'X='ECDH-SHA2-NISTP256'
'0007'X='ECDH-SHA2-NISTP384'
'0008'X='ECDH-SHA2-NISTP521'
'0009'X='GSS-GROUP1-SHA1'
'000A'X='GSS-GROUP14-SHA1'
'000B'X='GSS-GEX-SHA1'
'000C'X= 'DIFFIE-HELLMAN-GROUP14-SHA256'
'000D'X= 'DIFFIE-HELLMAN-GROUP16-SHA512'
'000E'X= 'DIFFIE-HELLMAN-GROUP19-SHA512'
'000F'X= 'CURVE25519-SHA256'
'1002'X= 'DIFFIE-HELLMAN-GROUP19-EXCHANGESHA256(ICSF)'
'1003'X= 'DIFFIE-HELLMAN-GROUP19-SHA1(ICSF)'
'1004'X= 'DIFFIE-HELLMAN-GROUP14-SHA1(ICSF)'
'1005'X= 'DIFFIE-HELLMAN-GROUP1-SHA1(ICSF)'
'1006'X= 'ECDH-SHA2-NISTP256(ICSF)'
'1007'X= 'ECDH-SHA2-NISTP256(ICSF)'
'1008'X= 'ECDH-SHA2-NISTP521(ICSF)'
'1009'X= 'GSS-GROUP1-SHA1(ICSF)'
'100A'X= 'GSS-GROUP14-SHA1(ICSF)'
'100B'X= 'GSS-GEX-SHA1(ICSF)'
;
Thanks to Eviatar Farchy, DTCC, USA.
Change 40.061.-RMM Extract Dataset EDGRDEXT new variables added:
VMACEDGR RDLRED ='LASTREF*EXTRA DAYS'
May 20, 2022 RDWHILECATON='WHILE*CATALOG=ON*Y,N?'
RDWHILECATUX='WHILE*CAGALOG*UNTIL*EXPIRED*Y?'
-RMM Extract Dataset EDGRXEXT new variables added:
XVKEYLABEL1='ENCRYPTION*KEY*LABEL 1'
XVKEYENCOD1='ENCRYPTION*ENCODING*METHOD 1'
XVKEYLABEL2='ENCRYPTION*KEY*LABEL 2'
XVKEYENCOD2='ENCRYPTION*ENCODING*METHOD 2'
XVMEDINF ='MEDIA*INFORMATION'
XVIRMMUSE ='IRRM*USED?'
XVWORM ='WORM*USED?'
XVHOLD ='VOLUME*HOLD?'
XVESB ='EXPD*SET BY*VOLUME'
XDESB ='VEXPDT*SET BY*DATASET'
XVUCDATE ='VOLUME*LAST*USER*CHANGE*DATE'
XVUCTIME ='VOLUME*LAST*USER*CHANGE*TIME'
XDUCDATE ='DATASET*LAST*USER*CHANGE*DATE'
XDUCTIME ='DATASET*LAST*USER*CHANGE*TIME'
XDVEX ='VRSEL*EXCLUDE?'
XVRETMET ='RETENTION*METHOD'
XVRMSB ='RETENTION*SET*BY'
XVCOMP_RAT ='COMPRESSION*RATIO*FOR VOLUME'
XVPHYS_USED='ACTUAL*SPACE*USED*ALL FILES'
XDCOMP_RAT ='COMPRESSION*RATIO*FOR FILE'
XDPHYS_SIZE='DATA ON*TAPE*AFTER*COMPRESSION'
XDLRED ='LASTREF*EXTRA*DAYS'
XVEXRB ='EXPDT*RETAINBY'
XVEDM ='VOLUME*EDM?'
XDWHILECATON='DSN*WHILECATALOG*ON?'
XDWHILECATUX='DSN*WHILECATALOG*UX?'
Thanks to John E. Benik, Optum, USA.
Change 40.060. RMF III update for ZRBRED dataset, and for FORMATS.
FORMATS
VMACRMFV
May 16, 2022
Change 40.059 -Support for SMF 80 RACFTYPE=67 records adds variables to.
VMAC80A RACF dataset TYPE8081:
May 12, 2022 RA67BITS='PASSTICKET*EVAL*HEX'
RA67RTRN='PASSTICKET*RETURN*CODE*HEX'
RA67REAS='PASSTICKET*REASON*CODE*HEX'
RA67NAME='PASSTICKET*APPLICATION*NAME'
-Only 5 UNKNOWN RACFTYPE messages are printed.
Thanks to Craig S. Bigler, Progressive, USA.
Thanks to Martha A. Knapik, Progressive, USA.
Change 40.058 Support for APAR OA60660 for TYPE9040 BOOST.
FORMATS -New values for Formats MG090ID for SMF9040IDNR and
VMAC90A MG090EV for SMF9040E.
May 23, 2022 -New variables
BOOSTLEVEL='BOOST*LEVEL'
RPBDISABLE='RPB*DISABLED?'
SMF9040RPBDU='RPB*DURATION*DELTA'
SMF9040RPBPO='RPB*DURATION*POTENTIAL'
SMF9040RPBPD='RPB*DURATION*POT DELTA'
SMF9040RPBPE='RPB*DURATION*POT E'
SMF9040RPBED='RPB*DURATION*POT E DELTA'
Change 40.057 BUILDPDB CRITICAL ERROR DUPLICATE TYPE30 SUBTYPE 1 FOUND
BUILD005 can result when testing BUILDPDB jobs that ABENDED or if
BUIL3005 the same SMF file was read in multiple BUILDPDB jobs.
May 9, 2022 This enhancement inserts a PROC SORT NODUPKEY to remove
any duplicates, printing log notes if any were found.
Thanks to John Barnes, Zions Bank Corp.
Change 40.056 Dataset BVIR302 had only half the number of observations
VMACBVIR it should have had starting in MXG 39.04 thru MXG 40.02.
May 6, 2022 due to a 2 byte misalignment for the second of the pair.
====== CHANGES THRU 40.055 ARE IN MXG 40.02 DATED May 5,2022 =========
Change 40.055 -Variable ZCOS01TI corrected.
VMACZCOS -Support for subtype 5 in progress, text will be updated
Apr 29, 2022 if/when subtype 5 data with populated triplets received.
Thanks to Virginie Peigney, CA-GIP, FRANCE.
Thanks to Claude Tetard, CA-GIP, FRANCE.
Change 40.054 Variables added to TYPE122A dataset:
VMAC122A SMF122T1S3F_VUON ='CLIENT*ACTIVATION CODE*PROVIDED?'
Apr 28, 2022 SMF122T1S4_UUID ='UUID'
SMF122T1S1_SYSPLEX='SYSPLEX*NAME'
ZEXPLAPIVERSIONCLIENT='ZEXPLAPI*VERSION*CLIENT'
ZEXPLAPIVERSIONHOST='ZEXPLAPI*VERSION*HOST'
PRODUCTAPIVERSIONHOST='PRODUCTAPI*VERSION*HOST'
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 40.053 -Variables SMF92WID added to all datasets.
VMAC92 -Subtype 11 and 16 records are both output in TYPE9211;
Apr 26, 2022 the value in SMF92STP identifies the subtype.
Dataset TYPE9216 will always have zero observations.
-New variables in Dataset TYPE9211:
SMF92CF4='Y';/*FILE*WAS*CACHED?*/
SMF92CF5='Y';/*FILE*HAD*DENY*READ?*/
SMF92CF6='Y';/*FILE*HAD*DENY*WRITE?*/
-Tests for length SMF92ILN changed to GE 72 or 32 vs EQ.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 40.052 Variables TVCSIZE and TVCSIZE8 are now correct.
VMACBVIR
Apr 26, 2022
Thanks to Maria Paola Bramosi, Kyndryl, ITALY
Thanks to Lorena Ortenzi,Kyndryl, ITALY
Thanks to Valeria Consiglio, Kyndryl, ITALY.
Change 40.051 -Clean-up of ZRBASM dataset corrected alignments and added
VMACRMFV new variables
Apr 26, 2022 ASMZLP='OUTPUT*ZERO*LP*LPARS?'
ASMIFE='IF=*KEY*WORD*ERRORS?;
ASMSLSIZ='EXECUTION*STEP LVL*PGM SIZE'
ASMDCPCRX='MAXIMUM*CPCNAME*RANGES'
ASMDCPCPX='MAXIMUM*CPCNAME*PATTERNS'
ASMDLPRRX='MAXIMUM*LPARNAME*RANGES'
ASMDLPRPX='MAXIMUM*LPARNAME*PATTERNS'
-These variables were retained from ZRBSSHG3 and output in
ZRBBDSIH and the six ZRBSVCx datasets, but they are now
removed because they are either missing or have wrong
values, retained from from a prior sample set when there:
are multiple sample sets input:
GMTOFF SSHGOSYN SHIFT CPC_CECNAME LPARNAME SSHTIBEG
SSHTIEND SSHRMFVN SSHMPRNR SSHGOMNT
-If you use PROC APPEND, you MUST specify FORCE and NOWARN
when there are changes between DATA= and BASE= datasets,
to allow the APPEND and to prevent the WARNING MESSAGE
and to prevent the CONDITION CODE 4.
Change 40.050 -MXG 40.01, SMF30 ABEND with z/16 SMF or APAR OA61511 due
VMAC30 to MXG coding error for new Crypto counters. Line 1812
Apr 22, 2022 IF OFFPROD GE 193 THEN DO; in VMAC30 needs to be GE 220
to circumvent this error. That APAR was in RSU2301.
Change 40.049 An extra paren in the Dataset Label for IFCID 100 and 101
VMAC102 did not impact their creation, but VMXGPRAL died when it
Apr 20, 2022 tried to print those dataset labels.
Change 40.048 -ASUM70PR Hardware Capping variables SMF70HWGRNAME,
VMXG70PR SMF70HWGR_CAP_LIMIT and SMF70HW_CAP_LIMIT are added to
Apr 25, 2022 dataset ASUMCELP.
-TYPE70PR variable SMF70HWGR_CAP_LIMIT LABEL statement
updated to 'IN NR ENGINES'.
-CODE WARNING Message YES or not NO suppresses report.
Thanks to Shantanu Gupta, ENSONO, USA.
Change 40.047 Support for IBM CL/SuperSession V3.1 found undocumented
VMACNAF bytes and incorrect record lengths and invalid SMFSTAMP
Apr 16, 2022 values that had '20'x instead of '01'x for century bit.
Thanks to Linda S. Berkley, DISA, USA.
Change 40.046 HSMFSRBO and HSMFSRST dataset variable FSR2_UNAM was
VMACHSM INPUT as VARYING1024 but INPUT(FSR2_UNAM,$EBCDIC128.).
Apr 12, 2022 kept only the first 128 bytes. Now all 1024 are kept.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 40.045 Support for APAR OA61609 for TYPE82 records.
FORMATS -FORMAT $MG082AL updated for STAT_ENG_ALG_NAM in SMF8231.
VMAC82 -FORMAT $MG082LA updated for SMF82_TAG_KEY_ALG in SMF8241.
Apr 7, 2022 -Variable STAT_ENG_CARD_ID is now readable in SMF8231.
-These Subtypes have changes in this APAR but I don't have
test data: 1,41,42,45,46,48
-Support for Z16 Hardware ICSM-CEX8S for Dilithium 6-5 R3,
and 8-7 R3 Support in CCA and PKCS, Kyber in CCA/PKCS.
Thanks to Luis Mendoza, BKFS, USA.
Change 40.044 No impact, but three TYPE70 variables are now reserved:
VMAC7072 SMF70MDL_CBP SMF70MCR_CBP and SMF70NCR_CBP were intended
Apr 7, 2022 to be populated for the CBP (Container Based Processor)
engine which was never implemented, and IBM confirms
there is no plan to do so going forward. The CBP fields
replaced the discontinued zAAP fields. MXG was updated to
support the ESP sites that also never happened. All zAAP
variable's names were unchanged, but CBP was added to all
labels; I don't intend to remove the CBP text..
Change 40.043 Replaced with Change 40.067.
Change 40.042 CICS/TS 6.1 BETA 25 removed fields 291 (SOCPSCT) and 293
VMAC110 (SOPSHWM) from CICSTRAN records. INCOMPATIBLE.
Apr 4, 2022
Change 40.041 If you ran VMXGUOW in a SAS session without a PDB DDNAME,
VMXGUOW and you did not ask for MQ data (MXGMQAdd=yes) you could
Apr 4, 2022 get an error LIBREF PDB NOT FOUND.
Thanks to Roger Lowe, NT Government, AUSTRALIA
Change 40.040 In May 2021 negative values in DB2 QPACZITM Package Ziip
TECHNOTE time was reported to IBM. The error is addressed by APAR
Mar 31, 2022 PH40410 with PTF UI79705 for DB2 V12.1. This error
impacts users of external stored procedures and UDFs when
a stored procedure or UDF is cancelled in the middle of
its processing. The SP/UDF recovery processing will get
control, and in that recovery processing, code is missing
or incorrect to record the times for the DB2 Accounting
Record. Code was added or fixed in the cancel thread
scenario.
Thanks to Glenn Bowman, Wakefern, USA.
Change 40.039 z/OS 2.5 TYPE 0 IPL record lengths 78 and 83 were not in
VMAC0 the list of valid record lengths causing ***VMAC0.ERROR
Mar 31, 2022 messages and those records were not input. For a true IPL
the ERROR message is followed by a 90-10 PUTLOG which is
the confirmation the type 0 was for an IPL.
Thanks to Andreas Menne, Finanz Informatik, GERMANY
Change 40.038 DATACOM INPUT missed reserved field causing misalignment
VMACDCOM and incorrect values. New variables added..
Mar 30, 2022
Thanks to Linda S. Berkley, DISA, USA.
Change 40.037 New variable ZCOS01TI is created as a datetime value from
VMACZCOS character variable ZCOS01TM. Missing values are created
Mar 25, 2022 for values of 00.000.00-00:00 or all zeroes.
Thanks to Pier-Pascal Jouilin, SOCGEN, FRANCE
Change 40.036 -ASMRMFV ZEROLP logic has been corrected to properly build
ASMRMFV CPCDB records. With 39.227, the logical processor
ADOCRMFV sections were padded with binary zeros which tripped up
Mar 22, 2022 VMACRMFV analysis of the CPCDB records.
CHANGE 40.035 Variables SMF70GMU, SMF70CPA, and SMF70WLA were missing
VMXG70PR values in dataset ASUMCELP.
Apr 23, 2022 This is not yet implemented. Contact Support.
CHANGE 40.034 TYPE 70 BLOCKED WORKLOAD variables SMF70PMT and SMF70PMU
VMAC7072 were corrected. SMF70PMU is rounded up to next 1% in the
Mar 21, 2022 RMF Report, but MXG has left the actual value.
Thanks to Flavio Lima, Kyndryl, USA.
CHANGE 40.033 VM Accounting VMID='C0'x and USER='RCSC' INVALID DATA FOR
TYPEVM CPUMODEL because the format of the record changes and the
Mar 30, 2022 C0 record for RSCS has not yet been found. CPUMODEL is
protected.
Thanks to Linda Berkley, DISA, USA.
====== CHANGES THRU 40.032 ARE IN MXG 40.01 DATED Mar 4, 2022 =========
CHANGE 40.032 -If you ran VMXGUOW in a different SAS session than the
ASUMUOW one that created the input data sets, VMACDB2,VMAC110 and
VMXGUOW VMAC116 members are needed to resolve MACROs, but MXG
Mar 17, 2022 39.39 and earlier did not include VMAC116, causing zero
obs in the MQ data since the step would try to use the
_LTY116 and _LTY1161 which do not exist without VMAC116.
-ASUMUOW example in comments was updated.
Thanks to Nagaraj Pudukotai,
====== CHANGES THRU 40.031 ARE IN MXG 40.01 DATED Mar 4, 2022 =========
CHANGE 40.031 Replaced by Change 40.032.
Change 40.030 IMTR_TRN_ fields after STEPNAME were misaligned; the four
VMACSVIE UNDOC bytes after IMTR_TRN_CLASS1 should be after USERID.
Mar 2, 2022 Select WHEN statements had underscore in text that should
be dashes. Variable IMTR_DAC_DBDLET was added to KEEP and
to MACRO _DR3ADA
Thanks to James Robbins, Broadcom, USA.
Thanks to Don Cleveland, KYNDRYL, USA
Change 40.029 ERROR: ARRAY SUBSCRIPT 51 OUT OF RANGE ARRAY ALHTNEXT.
VMACRMFV The default array size of 50 lock holders was too small;
Mar 2, 2022 the temporary arrays were increased to 500 taking only
2Mib virtual storage to eliminate any exposure.
Thanks to Randy Schlueter, Fiserv, USA.
Change 40.028 -ASMRMFV now accepts PARM='F=Y,T=Y' syntax which caused
ASMRMFV CC=8 in 39.39 (and EA 40.01) due to Change 39.100.
Mar 2, 2022 Syntax of PARM='FROM=FROM,TO=Y' will work with 39.39.
Thanks to Len Shenfield, ADP, USA.
Thanks to David Dittmar, ADP, USA.
Change 40.027 $MGSMFID Format for ANALID new 90.040 (BOOST INFORMATION)
FORMATS and 90.41 (CVTLSO CHANGE). values added.
Feb 25, 2022
Change 40.026 TYPE72GO variables RDCENDxx were not input, because the
VMAC7072 test for LENSCS GE 815 should have been 813.
Feb 25, 2022
Change 40.025 Support for OA61511 Crypto/NNPI counts in SMF 0 and 30
EXTY30CP ABENDS SMF 30 in MXG 40.01, See Change 40.050 in 40.02.
EXTY30NP -New variables added to TYPE0 dataset.
IMAC30 SMF0_NUM_CRYPCTRS='CRYPTO*COUNTERS*SUPPORTED'
VMAC30 SMF0_NUM_NNPICTRS='NNPI*COUNTERS*SUPPORTED'
VMAC0 SMF0_FLAGS='SMF0*FLAGS'
VMXGINIT -New TYPE30CP and TYPE30NP datasets Crypto/NNPI counts.
Feb 25, 2022 TYPE30CP - CRYPTO COUNTERS
SMF30CONFLAG1='FIRSTREC*SET OF*TWO OR*MORE'
SMF30CONFLAG2='SECOND*NOT*LAST'
SMF30CONFLAG3='LAST OF*TWO OR*MORE'
SMF30_CRYPCTRS_ENTRY_ID='CRYPTO*COUNTER ENT ID'
SMF30_CRYPCTRS_VALUE ='CRYPTO*COUNTER*VALUE'
SMF30CPA='SMF30CPA SECTIONS SUBSEQUENT'
TYPE30NP - NNPI COUNTERS
SMF30CONFLAG1='FIRSTREC*SET OF*TWO OR*MORE'
SMF30CONFLAG2='SECOND*NOT*LAST'
SMF30CONFLAG3='LAST OF*TWO OR*MORE'
SMF30_CRYPCTRS_ENTRY_ID='CRYPTO*COUNTER ENT ID'
SMF30_CRYPCTRS_VALUE ='CRYPTO*COUNTER*VALUE'
SMF30NPA='SMF30NPA SECTIONS SUBSEQUENT'
Change 40.024 Macro variables MXGALERT MXGMAILFROM MXGMAILTO added for
VMXGINIT a future enhancement.
Feb 25, 2022
Change 40.023 SMF 102 IFCID 220 Argument to function MDY IS INVALID
VMAC102 was caused by +4 misalignment of the INPUT statement.
Feb 23, 2022
Thanks to Randall Schlueter, FISERV, USA.
Change 40.022 Format $MGRMFRE decodes variable REDREDID in ZRBRED
FORMATS
VMACRMFV
Feb 13, 2022
Change 40.021 TYPETPMX variable JCLJJR was not decoded because TOKFIELD
VMACTPMX contains a lower case character that was not expected.
Feb 9, 2022
Thanks to Ralph J. Romano, OPTUM, USA.
Change 40.020 Added second TESTSTRING2 to delete invalid records that
VMACCTLC have a blank in byte 9.
Feb 9, 2022
Thanks to Craig Collins, State of Wisconsin, USA.
Thanks to Maggie Buday, State of Wisconsin, USA.
Change 40.019 Format MGKILO was extended to decode EXABYTE VALUES.
FORMATS
Feb 8, 2022
Thanks to Jorge Fong, DOITT.NYC.
Change 40.018 Dataset TYPE115S was misaligned because 8 bytes were
VMAC115 added to the SM1152NQ segments.
Feb 8, 2022
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 40.017 The TYPE30_4/TYPE30_5 dataset variables EXCPTOTL/EXCPNODD
VMAC30 IOTMTOTL/IOTMNODD counts are wrong for jobs/steps that
Feb 7, 2022 have MULTIDD='Y' records. These are additional SMF 30
records created when there are more DDs than will fit in
one 32K record and they contain the extra TODD counts.
The "real" step record that contains the address space
EXCPTOTL/IOTMTOTL counts has MULTIDD=' ' with some TODD
counts, but NODD=TOTL-TODD can't be calculated in that
MULTIDD=' ' record because of the TODD counts that are in
those other MULTIDD='Y' records. And NODD can't be
calculated in those records that don't have the TOTLs.
The logic to combine those MULTIDD='Y' records and to
create a single TYPE30_4/TYPE30_5 obs with correct counts
is in the BUILDPDB logic, and you can use this example to
create only the PDB.STEPS and PDB.JOBS datasets and use
them in place of TYPE30_4 and TYPE30_5:
%LET MXGANALID=NO;
%LET MACFILE= %QUOTE (
IF ID=6 OR ID=26 OR (ID=30 AND SUBTYPE IN (1,4,5) ); );
%INCLUDE SOURCLIB(BUILD001,BUILD005);
PROC DATASETS LIB=PDB;
DELETE
DB2ACCT DB2ACCTB DB2ACCTG DB2ACCTP DB2ACCTR DB2ACCTW
DB2GBPAT DB2GBPST DB2NETZA DB2ST225 DB2STAT0 DB2STAT1
DB2STAT2 DB2STAT4 DB2STAT5 DB2STATB DB2STATR DB2STATS
DB2STSBP NJEPURGE PRINT SMFINTRV SPIN26 SPIN30TD
SPIN30_1 SPIN30_4 SPIN30_5 SPIN6 SPUNJOBS;
Thanks to Jeffrey S. Britton, IRS, USA.
Thanks to Mark C. Smith, IRS, USA.
Thanks to Twanna G. Wiley, IRS, USA.
Change 40.016 z/OS 1.12 and 1.13 write SMF 42 Subtype 5 with LENSR=96
VMAC42 that MXG detected and deleted with a warning message, but
Feb 2, 2022 APAR OA53110 (2017) that added the new zHPF fields and
set LENSR=160 is not available for these back-levals.
However the records are valid for those 96 bytes and are
now output with no message.
Thanks to Jeffrey Fracas, ENSONO. USA.
Change 40.015 ASCII execution. If you use VMXGALOC and choose to send
VMXGALOC DB2 or CICS to a different location than the BASEDIR=
Jan 28, 2022 directory, the aging of directories failed because it was
looking for that directory. Now, BASEDB2 and BASECICS are
used.
NOTE: VMXGALOC only deletes the directory indicated by
the KEEP&&&&- parameters so if you have been running for
a while you may need to do a manual cleanup. Assume today
is Jan 28 and you used CICSKEEP=3. CICS220127 would be
created and CICS220124 would be deleted leaving
220125-220127 but any prior to 220124 would remain and
would need to be manually deleted
Thanks to Jose Rivera, UPS, USA.
Change 40.014 TYPE 16 SORT records can have offsets that point beyond
VMAC16 the record length causing INPUT STATEMENT EXCEEDED error.
Jan 28, 2022 Now prints TRUNCATED SMF 16 RECORD INDS or OTDS log
message that identifies the job that created the record,
and the record is deleted. One bad record was created
by a job using PGM=ICETOOL that had an ABEND S222.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 40.013 Format $MGSYNEQ decodes variable SYNEQULS.
FORMATS
VMACSYNC
Jan 31, 2022
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 40.012 Variable R742PUSE in dataset TYPE74PA is changed from the
VMAC74 count of 1K blocks to the number of bytes and formatted
Jan 28, 2022 MGBYTES so it can be directly compared with R742PMXM.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 40.011 -Variable TPCRELEASE added to dataset XMTCPSYS.
EXVSIDIA -Support for VSIDIA Segment with Linux Diagnose Codes
FORMATS creates XMVSIDIA dataset.
VMACXAM
VMXGINIT
Jan 31, 2022
Thanks to Douglas C. Walter, CITIGROUP, USA.
Thanks to Arthur Koerner, CITIGROUP, USA
Change 40.010 z/VM 7.2.21.02 ABEND with Broken Control Record corrected
VMACVMXA
Jan 27, 2022
Thanks to Rob D'Andrea, NATWEST, SCOTLAND.
Change 40.009 Variables QCSTSLSN/QCSTSLCN/QCSTSLCS are added to dataset
TYPE116 MQCHININ.
Jan 26, 2022
Thanks to Gennady Katsnelson, Kyndryl, USA.
Change 40.008 The DCB Attributes were incorrectly added to VMACBVIR in
TYPEBVIR line 55 in VMACBVIR. They are now removed and only the
Jan 24, 2022 JFCB=BVIRJFCB is set for z/OS execution.
Thanks to Jorge Fong, DOITT.NYC.
Change 40.007 -If you did not specify an offset for a system 0 was used
TIMEBILD and if you did not specify a GMT offset 0 was used again.
VMAC30 Now both produce MXGNOTEs and the offset is still set to
Jan 31, 2022 0 and the GMT offset is to the same value as the offset.
-Variable INTBTIME was corrected for TIMEBILD.
Thanks to Rob G. Hollingum, HSBC,
Change 40.006 Very odd problem from an ASCII user. It appears that
VMXGSUM their IMACSHFT member may have been created using a
VMXGRMFI TEXT EDITOR that leaves out the CRLF at the end of each
Jan 23, 2022 line creating a long string. When that string hit the
incode logic it choked and probably broke a line in the
middle or a word. THere were two solutions and both are
implemented. First VMXGSUM was modified and the COMPBL
function is used to get rid of blanks. Second the
redundant IMACSHFT call in the first TYPE75 summary was
removed. Error surfaced as INDEX VALUE error on log.
Change 40.005 R742PUTx variables in TYPE74PA were divided by 1E-6 after
VMAC74 being INPUT with INFORMAT &PIB.8.6 which also divides the
Jan 19, 2022 PIB8 value by one million.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 40.004 Hard-coded DATA FINL70PR1/VIEW=FINL70PR1 was overlooked
VMXG70PR and its VIEW could not be disabled with %LET MXGVIEW=NO.
VMXGINIT Now, macro variable &VWTY70PR is used. Early WPS did not
Jan 14, 2022 support VIEWS.
Thanks to John Compton, World Programming, ENGLAND.
Thanks to Chris Hill, World Programming, ENGLAND.
Change 40.003 PDB.RMFINTRV new variable MSUSCRT=CPUEFFTM*SMF70CPA/1E6
VMXGRMFI estimates the MSU reported by IBM's SCRT.
Jan 12, 2022
Thanks to Thomas Heitlinger, Atruvia, GERMANY
Change 40.002 Summarization and Trending for MQ SMF 115 data. MXG 39.39
ASUM115X had added ASUMMQAC and TRNDMQAC for MQ SMF 116 data.
TRND115X
VMXGINIT
Jan 11, 2022
Change 40.001 CICS/TS 6.1 OPEN BETA 22 Jan 22, 2022 REQUIRES MXG 40.01
TYPE110 because a second new field was inserted in the CICSTRAN
UTILEXCL record. The first was added/supported in MXG 39.07.
Jan 11, 2022
LASTCHANGE: Version 40.
=========================MEMBER=CHANGE39================================
/* COPYRIGHT (C) 1984-2022 MERRILL CONSULTANTS DALLAS TEXAS USA */
E.A. MXG VERSION 39.39 is dated Dec 30, 2021, thru Change 39.225..
MXG VERSION 39.09 was dated Dec 2, 2021, thru Change 39.213.
MXG VERSION 39.08 was dated Oct 15, 2021, thru Change 39.199.
MXG VERSION 39.07 was dated Sep 20, 2021, thru Change 39.190.
MXG VERSION 39.06 was dated Aug 12, 2021, thru Change 39.167.
MXG VERSION 39.05 was dated Jul 16, 2021, thru Change 39.149.
MXG VERSION 39.04 was dated Jun 1, 2021, thru Change 39.116.
MXG VERSION 39.03 was dated May 3, 2021, thru Change 39.092.
MXG VERSION 39.02 was dated Apr 4, 2021, thru Change 39.066.
First MXG VERSION 39.02 was dated Apr 1, 2021, thru Change 39.063.
MXG VERSION 39.01 was dated Feb 17, 2021, thru Change 39.028.
First MXG VERSION 39.01 was dated Feb 16, 2021, thru Change 39.026.
ANNUAL MXG VERSION 38.38 was dated Jan 4, 2021, thru Change 38.234.
New TECHNOTES previously in NEWSLTRS are now in CHANGESS.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 39.39 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 39.39.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains old Technical Notes. many of which are still
valid, but the last was in 2018. Now, TECHNOTES and FLASHes are in
CHANGES/CHANGESS. which are also online.
The Final MXG Newsletter SIXTY-NINE was dated Jan 3, 2018.
Member CHANGES contains the changes made in this current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
CHANGESS and NEWSLTRS are also online at http://www.mxg.com,
========================================================================
I. MXG VERSION 39.39 DATED Jan 5, 2022 THRU CHANGE 39.225.
==MAJOR CHANGES ADDED IN MXG 39.39, DATED Jan 5, 2022 THRU 39.225.
NEW SUPPORT
ASUMMQAC 39.220 Summarization of MQMACCT (SMF116).
TRNDMQAC 39.220 Trending of MQMACCT (SMF116).
UTILWORK 39.219 Create Workload Definitions for RMFINTRV
VMXGINIT 39.214 Support for SAS Viya INCOMPAT Version Format Change
==MAJOR CHANGES ADDED IN MXG 39.09, DATED Dec 2, 2021 THRU 39.213.
NEW SUPPORT
TYPEDB2 39.200 Support for DB2 zHyperlink new data.
TYPE90A 39.206 FORMAT MG090CM for CMDMVS new values decoded.
TYPESVIE 39.207 Sysview SV27DB2/SV27PROG/SV27TRAN updated.
FNDMXGJB 39.210 Find probable MXG Job execution SAS/SOURCLIB/LIBRARY.
TYPERACF 39.212 Support for RACF Unload 0207 and 05B0 records.
ENHANCEMENTS
ANALDB2R 39.209 DB2 DBID/OBID Decoded if there is an IFCID 105.
TYPEDB2 39.208 DB2STATB/S variables AGET/ASGE/ASSE/ASYN deaccumed.
DODSCRDT 39.204 CREATEDATE Year 1772 in 2028 corrected.
ERRORS CORRECTED
TYPE82 39.203 SMF 82 Subtype 24 INPUT STATEMENT EXCEEDED corrected.
TYPETLC 39.202 Protect BMC Control-D CSV invalid quotes protected.
TYPE50 39.201 MXG 39.08-39.08 Error if no //INSTREAM DD.
TYPE6156 39.213 Protection for TYPE6156 record with short segment.
==MAJOR CHANGES ADDED IN MXG 39.08, DATED Oct 15, 2021 THRU 39.199.
ERROR CORRECTED:
TYPE6156 39.196 MXG 39.07 INPUT EXCEEDED, SMF6XSTCKE incorrect..
TYPE30 39.194 AVGWKSET,CPUTOTTM,CPUUNITS could be too large.
TYPE50 39.198 TYPE50 OSA Express Accel TY50PKAC misspelled.
NEW SUPPORT:
TYPESVIE 39.199 Support for MainView IMS Updates/Enhancements
FORMATS 39.197 SMF 119 $MG119CF NEG-CIPHER decoded for ZERT.
TYPERMFV 39.192 RMF III for z/OS 2.5 plus new tables supported.
ENHANCEMENTS
BLDSMPDB 39.195 USEVMXGSET adds OPEN=DEFER for z/OS save drives.
SELSMF 39.192 Select and write SMF records from each system.
ICETOOL 39.191 Select records on z/OS for ASCII execution example.
==MAJOR CHANGES ADDED IN MXG 39.07, DATED Sep 20, 2021 THRU 39.190.
FLASH
WPS ONLY 39.171 WPS Errors in 4.3.1 fixed in 4.3.3.
NEW SUPPORT:
TYPE110 39.176 Support for CICS/TS 6.1 CICSTRAN/UTILEXCL.
TYPEDB2 39.188 Support for CICS-DB2 ATTACH APAR PH31440 fields.
TYPEVELO 39.179 Support for Dino VelociRaptor SMF records.
TYPEPRF 39.178 Support for Dell PRF Monitor MFE SMF records.
TYPECTLC 39.175 Support for BMC CONTROL-D CSV audit file.
TYPE1415 39.173 Support for SMF14DSENCARCHKEY encrypted flat.
TYPERMFV 39.168 Support for RMF III z/OS 2.5 existing tables.
TYPE30 39.186 Support for APAR OA61368 new RAXFLAGS bits.
ENHANCEMENTS
TYPE110 39.180 Enhanced MXGABND can set Condition Code.
BUILD005 39.181 Variables BOOSTACTIVE/BOOSTCLASS in PDB.STEPS.
IMACABND 39.180 MXGABND can set a condition code instead of ABEND.
TYPENDM 39.173 New format $MGNDMCP decodes NDMCPEA Cipher values.
ERRORS CORRECTED
TYPE90A 39.170 Conflict with variable SMF9040ID, char vs numeric.
==MAJOR CHANGES ADDED IN MXG 39.06, DATED Aug 12, 2021 THRU 39.167.
NEW SUPPORT:
TYPE1153 39.163 Support for SMF ID=1153 JES 2 Monitor.
TYPEQSEL 39.158 Support for Quick Select product's SMF records.
TYPEVIRS 39.154 Support for VIRTEL AUDIT VIRSTATA SMF records.
TYPE83 39.153 Support for new datasets and variables.
==MAJOR CHANGES ADDED IN MXG 39.05, DATED Jul 16, 2021 THRU 39.153.
ERRORS CORRECTED
VMAC110 39.145 SMF 110 Subtype 1 MNSEGCL=5 (NOT CICSTRAN) ABEND 5.3.
VMXGALOC 39.148 ERROR: Libref TREND not assigned.
ANALMSUS 39.140 Using READSMF=YES and PDBOUT=WORK ERRORed
VFMT102 39.139 ANALDB2R failed FORMAT NOT FOUND if no subtype 104.
VMXGRMFI 39.136 Special Characters in Class Names not supported
ANALDB2R 39.135 Superfluous %END z/OS only ABEND after Change 39.080
VMACNDM 39.133 NDM HW/H2 records do not match DSECT, IBM SR open.
UTILBLDP 39.129 ERROR: Old-style macro name _ID102 xxx must contain.
VMAC71 39.128 Variables PAGBLAV and PAGEBLMX were reversed.
VMAC16 39.123 INVALID ENDTIME in TYPE16 z/SORT records.
ASMRMFV 39.122 ASMRMFV failed with back-level ASM UI60362 (2020).
VMXGALOC 39.120 MXGERRORs if FIRSTRUN=YES was not used first time.
UTILCPLG 39.118 ASCII Copy Log to File utility doesn't if blanks.
VMAC30 39.117 JOBCLAS8='STC' erroneously set one byte JOBCLASS='S'.
IBM ERRORS CORRECTED
VMAC7072 39.138 If Configuration changed NRCPUs LCPUPDTM invalid.
VMAC92 39.125 STCKE GMTOFF92 wrong, IBM date was +60 years 2081!
ENHANCEMENTS
VMACSVIE 39.141 Updates to SYSVIEW IMS datasets SV34TRAN & SV35TRAN
MONTHPDB 39.146 New generic example for Monthly PDB.
VMAC110 39.147 CICSTRAN OADATA1X created for SMF 123A merge.
FORMATS 39.132 FORMAT values added for Recovery Boost Start/End.
VMAC50 39.131 Updates and Corrections for VTAM Tuning.
VMAC123A 39.127 Liberty SMF 123 SYSNAME was CVTSNAME.
VGETALOC 39.124 Enhanced support and Linux example in the member.
VMACHSM 39.119 Support for HSM ZEDC Compression in HSMFSRST.
==MAJOR CHANGES ADDED IN MXG 39.04, DATED Jun 1, 2021 THRU 39.116.
ERRORS CORRECTED
TYPEDCOL 39.093 Correction to sizes in DCOLLECT DATASETS.DATASETS.
VMACDB2H 39.099 Correction of DB2 GMT Offset to include Leap Seconds.
NEW SUPPORT
VMAC123A 39.102 Support for z/OS Connect EE SMF 123 Subtype 2 record.
VMACBVIR 39.108 Support for BVIR Version R5.x 8.50.x.x
VMAC0 39.103 Support for more than 4TB of Real Storage.
VMACDB2 39.099 Support for DB2 Netezza/IDAA Accelerator new data.
ASMRMFV 39.100 ASMRMFV Field Data Filter for CRYG3 Crypto table.
ENHANCMENTS
TYPE89 39.096 New SMF89SOLUTIONID for Tailored Fit Pricing SOLUT.
ASUM70PR 39.097 New NOTALLLPARS=YES suppresses missing LPAR message.
VMAC110 39.104 New %LET MACEXCL=IMACEXCL supports multiple IMACEXCL.
VMACSMF 39.109 More examples using _SMF for record selection.
==MAJOR CHANGES ADDED IN MXG 39.03, DATED May 3, 2021 THRU 39.092.
ERRORS CORRECTED
ASUMUOW 39.085 Variable TRANNAME in PDB.ASUMUOW only one character.
ANALDB2R 39.080 ANALDB2R can fail if PMAUD02 requested but no data.
VMXGRMFI 39.077 VMXGRMFI(PDB=SMF) could fail, UTILBLDP now used.
UTILEXCL 39.078 MXG 39.02. EXCLUDED FIELDS ERROR typo $CHAR54 vs 64.
NEW SUPPORT
TYPEHSM 39.086 Support for HSM UNIX CLOUD statistics variables.
TYPERMFV 39.079 Support for RMF III CRYG3 Cryptographic Hdw Table.
TYPERMFV 39.071 RMF III Percents in System Info and CPC Summary.
TYPE102 39.091 Support for new variables in IFCID=402.
TYPE80A 39.090 Support for RACF Pass Ticked Eval, TYPE8081 PTEVAL.
TYPE84 39.076 Support for Phoenix JES3plus SMF 84 subt correction.
TYPE106 39.075 Support for new SMF 106 subtypes HWIREST API data.
TYPERMRV 39.074 Support for RMF III Feb 2021 Updates, BOOST, etc.
TYPEDB2 39.070 Support for DB2 APAR PH31684 zSORT and NETEZZA.
TYPE42 39.075 SMF Manual update new variable in TYPE42DS.
VMXGALOC 39.068 New parm to leave WORK uncompressed, PDB compressed.
TYPEXAM 39.089 Velocity XAM storage variables MXGBYTE formatted.
ASUM70PR 39.072 ZIPOVHTM and PCTZIPOV added to four outputs datasets.
==MAJOR CHANGES ADDED IN MXG 39.02, DATED Apr 4, 2021 THRU 39.066.
ABEND CORRECTED
TYPE16 39.057 INPUT EXCEEDED SMF 16 ZSORT APAR PH32395 cannot use
Sort Exits E15/E35 with zSORT. Also caused 0C4 in
Broadcom's CA7 SASSHISS program. See Change text.
ASMRMFV 39.060 HLASM UI73933 worked, UI60352 didn't, corrected.
TYPECDC 39.023 Short Infosphere records caused INPUT EXCEEDED.
NEW SUPPORT
TYPENDCD 39.033 Support for NDM-CDI SMF (default 133) APAR PH35087.
TYPE90A 39.028 Support for SMF 90 subtype 41, CVTLOS value changed.
TYPECLTA 39.026 Support for IBM TAPE CLOUD CONNECTOR SMF record.
ENHANCEMENT
ASMRMFV 39.039 Field Data Filter can reduce size of RMFBSAM file.
VMACSMF 39.025 Example _SMF for selection, CICS Dictionary records.
TYPE110 39.053 z/OS EE Connect CICSTRAN vars OADATA1/2/3 decoded.
CORRECTIONS
TYPE120 39.036 Negative CPU WebSphere SMF 120 TYP120BL APAR PH35442.
TYPEBETA 39.031 BETA 93 subtype 5 shortened, many variables gone.
TYPE0 39.059 GMT Offset CVTTZ in TYPE0 was off by 1 second.
==MAJOR CHANGES ADDED IN MXG 39.01, DATED Feb 17, 2021 THRU 39.028.
ABEND CORRECTED:
ANAL9914 39.018 Some ANAL9914 invocations mismatched %DO-%END logic.
VMACDB2 39.017 DB2 NETEZZA IDAA 100-1 INPUT STATEMENT EXCEEDED.
ASMRMFV 39.013 MXG 34.06-38.38 ABEND if STOREGROUP GT 1361 vols.
CORRECTIONS
UTILWORK 39.020 UTILWORK creates RMFINTRV code member, enhanced.
VMXG70PR 39.021 Override PSU70PR/LP/GC/GL DD's may not work.
VGETJESN 39.002 WARNING TYPETASK NOT DECODED SUBSYS=SAR
VMACXAM 39.022 Variables missing values in XAMSYS corrected.
VMXGPRNT 39.019 SP_REMV='Y' truncated some labels.
ANALMSUS 39.015 The JOB report now includes all TASKTYPEs.
ANALID 39.004 ANALID did not identify CICS Compressed Records.
VMAC102 38.010 DB2 IFCID 172 dataset T102s172 variables corrected
VMAC80A 39.003 TYPE80TK observation count is smaller now.
VGETJESN 39.002 TYPETASK not decoded for SUBSYS='SAR'.
TECHNOTES
TECHNOTE 39.012 z/OS SAS ODS may need to increase MEMLEAVE option.
TECHNOTE 39.008 z/OS SAS ODS can use zIIPs, Java error may prevent.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M7 (9.4M7),
"M7", or with options VERSIONLONG;
"SAS 9.4 (9.04.01M7P080520)" on z/OS
9.4 (TS04.01M7P08052020)" on ASCII.
SAS V9.4 M7 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M6 or SAS Version 9.3 M0-M2.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.128 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But CONFIMXG is required for sites with NLS issues, and you must
use JCLCONFI to create/update the MXG.FORMATS catalog if you use
CONFIG='MXG.SOURCLIB(CONFIMXG)'.
For no NLS, you can use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 36.11 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
DO NOT USE 4.03.01 nor 4.04.00, INVALID CPU BUSY in TYPE70.
Error was introduced in 4.03.01 and 4.04.00. See Change 39.171.
Must be at 4.03.02.00.8569+ or 4.04.00.03.3277+/
WPS Version 4.01 USER 4037 ABEND, See Change 37.116.
WPS Version 4.0 reportedly fixed version 3 problems.
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
The z15 and z15 T02 processors INCOMPATIBLY changed the SMF 113
records by inserting 32 new EXTEND and 4 CRYPTO counters, causing
ARRAY SIZE EXCEEDED with BUILDPDB which processes the SMF 113s.
Support for counter changes for both models was in MXG 37.08.
If you use MIPS in reports, the format $MGRMIPS provides the
MIPS/MSU value for each processor; the z15 values were updated
in MXG 37.08, and the z15 TO2 values were updated in MXG 38.04.
These MXG programs use $MGRMIPS: ASUMMIPS GRAFCEC GRAFWLM
GRAFWRKX and TYPERMFV (RMF III).
The z/14 also inserted SMF 113 fields, supported in MXG 36.07.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
And z/VM on the z15 requires MXG 38.02, PRCMFC/MFM COUNTERS caused
HARDWARE COUNTER messages, PRCMFC/PRCMFM no obs. Change 38.048.
The z13 processor INCOMPATIBLY CHANGED, the new SMT-MODE RMF 70, and
MXG 34.03 was REQUIRED (PCTCPUBY WRONG!), to read the SMT-format RMF
(which are written if you have zIIP engines AND have enabled the new
PROCVIEW CORE option for Multi-Threading, even if only one thread is
enabled).
The new zEDC/EADM compression hardware requires MXG 38.05 to support
new metrics.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z/OS 2.4 Compatible from SMF Manual Sep 2019 37.166 37.07.
z/OS 2.4 Compatible from SMF Manual May 2020 38.105 38.05.
z/OS 2.4 Compatible from SMF Manual Apr 2021 39.075 39.03.
z/OS 2.4 Compatible RMF III PGMR Apr 1 2021 39.074 39.03.
z/OS 2.5 Compatible from SMF Aug 12,2021 39.06.
z/OS 2.5 Compatible RMF III Aug 12,2021 39.08.
z/OS 2.5 RMF III 4 new tables Aug 12,2021 39.08.
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
z15 New SMF 113 fields INCOMPAT Nov 18, 2020 37.08
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
z15 ANAL9914 Support CH 39.006 Jan 14, 2021 39.01
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS/TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS/TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS/TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS/TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS/TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS/TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS/TS 3.2 Compressed Records Nov 3, 2007 25.11
CICS/TS 4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS/TS 4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS/TS 4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS/TS 4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS/TS 4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS/TS 5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS/TS 5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS/TS 5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS/TS 5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS/TS 5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS/TS 5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS/TS 5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS/TS 5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS/TS 5.3 GA date Dec 11, 2015 33.33
CICS/TS 5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS/TS 5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS/TS 5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS/TS 5.4 GA Jun 17, 2017 35.03
CICS/TS 5.5 GA (INCOMPAT) Jan 29, 2018 36.11
CICS/TS 5.6 GA (INCOMPAT) Jun 1, 2020 38.07
CICS/TS 5.6 NEW DATA (COMPAT) Oct 5, 2020 38.09
CICS/TS 6.1 INSERTS (INCOMPAT) Sep 20, 2020 39.07
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
z/VM 6.40061802 ABEND Jan 17, 2019 37.02
z/VM 7.1 INCOMPAT ABEND Feb 14, 2019 37.02
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2, 5.3, 5.4 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 39.39.
1. Incompatibilities introduced in MXG 39.39:
a. Changes in MXG architecture made between 39.39 and prior versions
that can introduce known incompatibilities.
IF YOU HAVE MEMBER E2TY70 IN YOUR USERID.TAILORING SOURCE LIBRARY,
YOU MUST CHANGE _LTY70 to _WTY70 in that member. CHANGE 38.105.
The error before this correction will be:
ERROR: DATA SET "PDB.TYPE70" was not specified on the DATA stmt.
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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 39.39:
Dataset/
Member Change Description
ANAL9914 39.018 Some ANAL9914 invocations mismatched %DO-%END logic.
ANALDB2R 39.135 Superfluous %END z/OS only ABEND after Change 39.080
ANALDB2R 39.209 DB2 DBID/OBID Decoded if there is an IFCID 105.
ANALID 39.004 ANALID did not identify CICS Compressed Records.
ANALMSUS 39.015 The JOB report now includes all TASKTYPEs.
ANALMSUS 39.140 Using READSMF=YES and PDBOUT=WORK ERRORed
ASMRMFV 39.013 MXG 34,06-38.38 ABEND if storegrop 1361 vols.
ASMRMFV 39.039 Field Data Filter can reduce size of RMFBSAM file.
ASMRMFV 39.060 HLASM at UI73933 works, UI60352 doesn't assemble.
ASMRMFV 39.100 ASMRMFV Field Data Filter for CRYGE Crypto table.
ASMRMFV 39.122 ASMRMFV failed with back-level ASM UI60362 (2020).
ASUM70PR 39.097 New NOTALLLPARS=YES suppresses missing LPAR message.
ASUMMQAC 39.220 Summarization of MQMACCT (SMF116).
BUILD005 39.181 Variables BOOSTACTIVE/BOOSTCLASS in PDB.STEPS.
DODSCRDT 39.204 CREATEDATE Year 1772 in 2028 corrected.
FNDMXGJB 39.210 Find probable MXG Job executionsSAS/SOURCLIB/LIBRARY.
FORMATS 39.132 FORMAT values added for Recovery Boost Start/End.
IMACABND 39.180 MXGABND can set a condition code instead of ABEND.
MONTHPDB 39.146 New generic example for Monthly PDB.
TECHNOTE 39.012 z/OS SAS ODS may need to increase MEMLEAVE option.
TRNDMQAC 39.220 Trending of MQMACCT (SMF116).
TYPE0 39.059 GMT Offset CVTTZ in TYPE0 was off by one second.
TYPE0 39.103 Support for more than 4TB of Real Storage.
TYPE102 38.010 DB2 IFCID 172 dataset T102s172 variables corrected
TYPE110 39.053 z/OS EE Connect CICSTRAN vars OADATA1/2/3 decoded.
TYPE110 39.104 New %LET MACEXCL=IMACEXCL supports multiple IMACEXCL.
TYPE110 39.145 INPUT STATEMENT EXCEEDED MNSEGCL=5 CICS 5.3.
TYPE110 39.147 CICSTRAN OADATA1X created for SMF 123A merge.
TYPE110 39.176 Support for CICS/TS 6.1 CICSTRAN/UTILEXCL.
TYPE1153 39.163 Support for SMF ID=1153 JES 2 Monitor.
TYPE120 39.036 Negative CPU WebSphere SMF 120 TYP120BL APAR PH35442.
TYPE123A 39.102 Support for z/OS Connect EE SMF 123 Subtype 2 record.
TYPE123A 39.127 Liberty SMF 123 SYSNAME was CVTSNAME.
TYPE1415 39.173 Support for SMF14DSENCARCHKEY encrypted flat.
TYPE16 39.057 Protection for truncat SMF 16, ZSORT triplet no data.
TYPE16 39.123 INVALID ENDTIME in TYPE16 z/SORT records.
TYPE30 39.117 JOBCLAS8='STC' erroneously set one byte JOBCLASS='S'.
TYPE30 39.186 Support for APAR OA61368 new RAXFLAGS bits.
TYPE50 39.131 Updates and Corrections for VTAM Tuning.
TYPE50 39.201 MXG 39.08-39.08 Error if no //INSTREAM DD.
TYPE71 39.128 Variables PAGBLAV and PAGEBLMX were reversed.
TYPE80A 39.003 TYPE80TK observation count is smaller now.
TYPE82 39.203 SMF 82 Subtype 24 INPUT STATEMENT EXCEEDED corrected.
TYPE83 39.153 Support for new datasets and variables.
TYPE89 39.096 New SMF89SOLUTIONID for Tailored Fit Pricing SOLUT.
TYPE90A 39.028 Support for SMF 90 subtype 41, CVTLOS value changed.
TYPE90A 39.170 Conflict with variable SMF9040ID, char vs numeric.
TYPE90A 39.206 FORMAT MG090CM for CMDMVS new values decoded.
TYPE92 39.125 STCKE GMTOFF92 wrong, IBM date was +60 years 2081!
TYPEBETA 39.031 BETA 93 subtype 5 shortened, many variables gone.
TYPEBVIR 39.108 Support for BVIR Version R5.x 8.50.x.x
TYPECDC 39.023 Short Infosphere records caused INPUT EXCEEDED.
TYPECLTA 39.026 Support for IBM TAPE CLOUD CONNECTOR SMF record.
TYPECTLC 39.175 Support for BMC CONTROL-D CSV audit file.
TYPEDB2 39.017 DB2 NETEZZA IDAA 100-1 INPUT STATEMENT EXCEEDED.
TYPEDB2 39.099 Support for DB2 Netezza/IDAA Accelerator new data.
TYPEDB2 39.200 Support for DB2 zHyperlink new data.
TYPEDB2 39.208 DB2STATB/S variables AGET/ASGE/ASSE/ASYN deaccumed.
TYPEDB2H 39.099 Correction of DB2 GMT Offset to include Leap Seconds.
TYPEDCOL 39.093 Correction to sizes in DCOLLECT DATASETS.DATASETS.
TYPEHSM 39.119 Support for HSM ZEDC Compression in HSMFSRST.
TYPENDCD 39.033 Support for NDM-CDI SMF (default 133) APAR PH35087.
TYPENDM 39.133 NDM HW/H2 records do not match DSECT, IBM SR open.
TYPENDM 39.173 New format $MGNDMCP decodes NDMCPEA Cipher values.
TYPEPRF 39.178 Support for Dell PRF Monitor MFE SMF records.
TYPEQSEL 39.158 Support for Quick Select product's SMF records.
TYPERMFV 39.168 Support for RMF III z/OS 2.5 existing tables.
TYPESMF 39.025 Example _SMF for selection, CICS Dictionary records.
TYPESMF 39.109 More examples using _SMF for record selection.
TYPESVIE 39.141 Updates to SYSVIEW IMS datasets SV34TRAN & SV35TRAN
TYPESVIE 39.207 Sysview SV27DB2/SV27PROG/SV27TRAN updated.
TYPETLC 39.202 Protect BMC Control-D CSV invalid quotes protected.
TYPEVELO 39.179 Support for Dino VelociRaptor SMF records.
TYPEVIRS 39.154 Support for VIRTEL AUDIT VIRSTATA SMF records.
TYPEXAM 39.022 Variables missing values in XAMSYS corrected.
UTILBLDP 39.129 ERROR: Old-style macro name _ID102 xxx must contain.
UTILCPLG 39.118 ASCII Copy Log to File utility doesn't if blanks.
UTILWORK 39.020 UTILWORK creates RMFINTRV code member, enhanced.
UTILWORK 39.219 Create Workload Definitions for RMFINTRV
VFMT102 39.139 ANALDB2R failed FORMAT NOT FOUND if no subtype 104.
VGETALOC 39.124 Enhanced support and Linux example in the member.
VGETJESN 39.002 WARNING TYPETASK NOT DECODED SUBSYS=SAR
VMXG70PR 39.021 Override PSU70PR/LP/GC/GL DD's may not work.
VMXGALOC 39.120 MXGERRORs if FIRSTRUN=YES was not used first time.
VMXGALOC 39.148 ERROR: Libref TREND not assigned.
VMXGINIT 39.214 Support for SAS Viya INCOMPAT Version Format Change
VMXGPRNT 39.019 SP_REMV='Y' truncated some labels.
VMXGRMFI 39.136 Special Characters in Class Names not supported
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at https://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE
====== CHANGES THRU 39.225 ARE IN MXG 39.39 DATED Dec 30, 2021 =========
Change 39.225 Correction to TY50HIPP, TY50HIPB and TY50PKCN overflow
VMAC50 additions.
Dec 30, 2021
Thanks to Tom White, Bank of America, USA.
Change 39.224 -Support for RMF III APAR OA61811 (SMF) OA62502 (RMF) new
VMACRMFV ERBRCDG3 variables in ZRBRCDS and TYPE72GO datasets:
VMAC7072 RCDENCTRXNUM='TRANS*PROCESSED*WITHIN*ENCLAVES'
Dec 27, 2021 RCDENCTRXCALLS='TIMES*REPORTED*WHEN*DELETING'
May 16, 2022 RCDENCTRXET='EXECUTION*TIME FOR*RCDENCTRXNUM'
RCDENCTRXETS='SUM OF*SQUARED*FOR*RCDENCTRXNUM'
-Variable R723CETSX corrected in May;; it has been
twice prior to this change MXG 39.39.
Thanks to Ralph J. Romano, OPTUM, USA.
Change 39.223 Support for SMF TYPE 42 APARS OA61495 OA61393 OA31392
VMAC42 adds new bit flags to the SUBTYPE=27 TYPE4227 dataset:
Dec 27, 2021 SMF42REOS2'='EOS*OVERWRITE*SUCCESSFUL'
SMF42REOS3'='DADSM*UNMAP*ATTEMPTED'
SMF42REOS4'='DADSM*UNMAP*SUCCESSFUL'
Change 39.222 Support for Axway AMPLIFY Transfer CFT 3.6 V24 SMF data..
VMACAXWY
Dec 24, 2021
Thanks to Steve McKee, Fidelity, USA.
Change 39.221 -Support for Velocity TYPEXAM new MDISK2 segment which is
VMACXAM output to XAMDMINI dataset with some fields larger than
Dec 29, 2021 the original MDISK segment (still supported).
-Support for Velocity TYPEXAM new SEKSE2 segment which is
output to XMSEKSEK dataset.
Thanks to Arthur Koerner, CITIBANK,USA.
Change 39.220 ASUM and TRND members for MQMACCT (SMF116) dataset.
ASUMMQAC QWHSSTCK is used to set the interval, but is a UTC/GMT
TRNDMQAC value. See the comments in the members.
Dec 17, 2021
Change 39.219 UTILWORK creates RMFINTRV workload definitions from your
UTILWORK TYPE72GO data, with a Workload for each Service Class.
Dec 17, 2021 You can use Reporting Class, but UTILWORK will detect
if the sum of Reporting Class CPUTM is less than the
sum of Service Class CPUTM (which happens when not all
of your workloads are in a Reporting Class), and UTILWORK
will revert to using Service Classes.
Read the extensive comments in UTILWORK.
Change 39.218 Correction for DBID/OBID update
ANALDB2R
VFMT102
Dec 16, 2021
Change 39.217 If you suppressed DB2ACCT the sometimes large datasets
UTILBLDP went to work. Now all DB2ACC datasets and their sorts
Dec 15, 2021 are suppressed with SUPPRESS=DB2ACCT.
Change 39.216 Typo OUTEETAL corrected to OUTDETAL.
ANALTAPE
Dec 15, 2021
Change 39.215 SAS Version 9.3 TS3M1,"ERROR 71-185 MAX function call
VMACSVIE does not have enough arguments" for this statement that
Dec 10, 2021 was introduced in MXG 39.04
MAXTIME=MAX(IMTR_ESS_REQ_MAX);
but SAS 9.4 does NOT raise that error! Correct statement
MAXTIME=MAX(MAXTIME,IMTR_ESS_REQ_MAX);
This error occurred in TESTUSR1.
Thanks to Pete Osborne, HSBC, ENGLAND.
Change 39.214 -Support for SAS Viya INCOMPATIBLE Version format change
GRAFDB2B from '9.4' to 'V.03.05', i.e., from numeric to character.
RMFINTRV ERROR:"A character operand . . . in the %EVAL function
VGETENG where a numeric operand is required, condition was V."
VMXGINIT MXG uses the &SYSVER macro variable to determine the SAS
VMXGODSC version, which always has been a numeric value. Because
VMXGRMFI &SYSVER is a Read-Only macro variable, new &SSYSVER is
VMXGSUM created in VMXGINIT and set to 9.4 for Viya and set to
VMXGUOW &SYSVER for the rest. All references to &SYSVER were
Dec 15, 2021 changed to &SSYSVER (54 members).
-VGETENG, the %EVAL was removed.
RMFINTRV/VMXGRMFI workload names permit 32 characters.
-VMXGSUM had code to set the length of variable names to 8
to be in KEEP list for V6 compatibility, but there are
many long length variables that could have been truncated
and causing Variable Not Found errors, length is now 32.
-We do not test MXG under SAS Viya, but so far, this is
the sole problem that has been encountered.
SAS Viya provides a CAS Server (Cloud Analytic Server)
which automatically multi-threads across as many
servers as you define, but some SAS statements can NOT
be multi-threaded, and that includes both INFILE and
INPUT statements, which are re-directed to a single-
threaded workspace server, and which limits the value
of Viya to MXG.
Thanks to Christian Lechtenberg, CONCORDIA, GERMANY
====== CHANGES THRU 39.213 ARE IN MXG 39.09 DATED Dec 2, 2021 ========
Change 39.213 Protection for TYPE6156 Catalog record segment with the
VMAC6156 2 byte length field populated but no data following,
Dec 2, 2021 causing an INPUT STATEMENT EXCEEDED ERROR.
Thanks to Bruce Hewson, CITIBANK, SINGAPORE.
Change 39.212 Support for RACF Unload Record Types 0207 and 05B0 are
VMACRACF now populated; previously only the header was output.
Dec 1, 2021
Thanks to Karl Laseki, American Chemical Society, USA.
Change 39.211 The TMS warning message DENSITY IS MISSING is removed and
VMACTMS5 variable DEN=0 is set when it is not available.
Nov 30, 2021
Change 39.210 Find probably MXG job executions, i.e., PROGRAM=:'SAS'
FNDMXGJB and both SOURCLIB and LIBRARY DDnames.
Nov 22, 2021
Change 39.209 The decoding of DB2 DBID/OBID from SMF 102 IFCID 105
VFMT102 has been a long time challenge, with mostly partial
ANALDB2R success, but now, all IDs are correctly decoded if there
Nov 17, 2021 is an IFCID 105 record. New parameter PRINTFMTS=YES will
PROC PRINT the input values to the $MGDB2DB and $MGDB2OB
formats.
Thanks to Chuck Hopf, Independent MXG Consultant, USA.
Change 39.208 DB2STATB variables QBSTAGET/QBSTASGE/QBSTASSE/QBSTASYN
VMACDB2 were not deaccumulated, causing the DB2STATS variables
Nov 17, 2021 QBnAGET/QBnASGE/QBnASSE/QBnASYN for the four sets of
buffer pool counters to also be incorrect.
Thanks to Johnny Meek, Fidelity FMR, USA.
Change 39.207 -Sysview dataset SV27DB2 variable PROGRAM (Package name)
FORMATS was changed from ASCII to EBCDIC, at least in V16. New
VMACSVIE variable PROGRAM_EB will contain the EBCDIC value.
Nov 23, 2021 -FORMAT MGD145S was updated for new values and applied
to variable STATETYPE_DB2 in SV27DB2 dataset.
-Variables TRANNUM,OTRANNUM,LASTTRANNUM are correctly
now INPUT as &PD.4 in SV27TRAN dataset.
-Forty pairs of _TIME, _COUNT variables added to SV27TRAN
dataset and alignment corrected.
-New fields were added to SV27PROG dataset.
Thanks to Martyn Jones, CPTGLOBAL, ENGLAND.
Change 39.206 FORMAT MG090CM for TYPE90A variable CMDMVS (SUBTYPE) is
FORMATS updated for CMDMVS values 35-41 to describe why each
Nov 15, 2021 record is created.
Thanks to Jim S. Horne, Lowe's, USA.
Change 39.205 Cosmetic. Variable BPHITRAT was correctly added to the
VMACDB2 PDB.DB2STATB in Change 39.160, created in the _SDB2STB
Nov 3, 2021 deacccumlate DATA step, but it was incorrectly added to
the _VDB2STB list of variables created in the SMF pass,
where is not is created. The only impact was a note
on the log, and only if your AUTOEXEC/CONFIGxx options
did not contain the MXG default OPTIONS DKROCOND=NOWARN,
which overrides the SAS WARN default. The variable was
removed from that KEEP= list. MXG exploits DKROCOND to
allow variables to exist in the KEEP= list even when they
are not created, for example for the optional CICSTRAN
variables, so they can be added when you tailor IMACICxx
members and not have to touch the KEEP= list..
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 39.204 The %MACRO DODSCRDT creates CREATEDATE from INFILEs but
DODSCRDT YEAR=INPUT(SUBSTR(&DSCB,10,1),?? IB1.)+1900;
Nov 2, 2021 will create YEAR=1772 in 2028 because the IB1. input will
see '80'x with the sign bit on. INPUT PIB1. corrects, and
the ?? was not required, since any byte value is valid.
Thanks to Declan Vibert, Worldprogramming, ENGLAND.
Change 39.203 SMF 82 Subtype 24 INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC82 because MXG expected label length of 64, but at least
Nov 2, 2021 since 2019, the length is shown as 72. This update
protects both lengths.
Thanks to Nick Varley, Precisely, USA.
Change 39.202 Protection for invalid BMC Control-D CSV records that
VMACCTLC did not have a pair of double quotes, and subsequent
Oct 23, 2021 records that did not have a valid datetime.
Change 39.201 MXG 39.06-39.08, ERROR: PHYSICAL FILE DOES NOT EXIST if
VMAC50 you have added SMF 50 (VTAM) processing to your BUILDPDB,
Oct 22, 2021 AND if your JCL does NOT have an //INSTREAM DD. Full text
ERROR: PHYSICAL FILE DOES NOT EXIST userid.INSTREAM.DATA
Debugging statement referencing INSTREAM was not removed.
The //INSTREAM DD is in all of the MXGSASxx JCL examples:
//INSTREAM DD UNIT=SYSDA,SPACE=(CYL,(1,20)),
// RECFM=FB,LRECL=80,BLKSIZE=0
and it is used in several MXG programs when MXG creates
SAS code "in stream" and then %INCLUDE INSREAM; is used
to execute that code.
Thanks to Wayne A. Schumack, USBank, USA.
Change 39.200 Support for DB2 zHyperlink new data.
VMACDB2 -Dataset DB2ACCTB and DB2ACCTP new variables.
Oct 21, 2021 QBACIOC ='READS*WITH DISK*CACHE HITS'
QBACSYI ='SYNC I/O*READS WITH*ZHIPERLINK'
QBACSYIT='CPU TIME*FOR SUCCESS*ZHYPERLINK*READS'
QBACSWU, QBACHRE, QBACHRF, QBACHWR, QBACHWF Reserved
-Dataset DB2ACCT new variables
QB1CIOC/SYI/SYIT QB2CIOC/SYI/SYIT QB3CIOC/SYI/SYIT
QB4CIOC/SYI/SYIT
-Dataset DB2STATB new variables.
QBSTNSG ='FAILED*CONDITIONAL*SEQUENTIAL*GETPAGE'
QBSTSYIO='SUCCESS*READ I/O*USING*ZHYPERLINK'
QBSTSIOC='READ I/O*DISK CACHE*NO ZHL'
-Dataset DB23STATS
QB1TNSG/SYIO/SYC QB2TNSG/SYIO/SYC QB3TNSG/SYIO/SYC
QB4TNSG/SYIO/SYC
Thanks to Scott Barry, SBBTechLLC, USA.
====== CHANGES THRU 39.199 ARE IN MXG 39.08 DATED Oct 15, 2021 ========
Change 39.199 Support for Broadcom SYSVIEW 16.0 and PTF LU02954.
VMACSVIE -IMS SV34TRAN variables IMTR_TRN_ENQPCB/ABCODE/CPUTIME are
Oct 12, 2021 now always INPUT; previously they were erroneously input
only for Fast Path Transactions. And new variables are
added in SV34TRAN:
IMTR_CNT_LOCK_HWM/LOCK_TOTAO/DB2SQL IMTR_CLK_IFP_CPU
IMTR_CLK_UNKN IMTR_CLK_DB2 IMTR_CLK_MQ IMTR_CLK_WOLA
IMTR_CLK_LAST_DLI
and added in SV35TRAN:
IMRA_DB_CALL_TIME IMRA_MSG_CALL_TIME
IMRA_IFP_ROUTECODE IMRA_IFP_TRANCODE
IMRA_IFP_TRANCOUNT IMRA_IFP_MSGIWAIT
IMRA_RGN_OCCUPYRATIO IMRA_RGN_STARTSQ6
IMRA_RGN_ACCUMSQ6 IMRA_LOCK_HWM IMRA_LOCK_TOTAL
IMRA_LAST_DLI IMRA_MAX_DLI_DB IMRA_MAX_DLI_DC
IMRA_MAX_ESS
In addition, the variables output in dataset SV34DAC now
create a set of variables in SV34TRAN, one per DLI call
type:
IMTR_DAC_DBGU IMTR_DAC_DBGN IMTR_DAC_DBGNP
IMTR_DAC_DBGHU IMTR_DAC_DBGHN IMTR_DAC_DBGHNP
IMTR_DAC_DBISRT IMTR_DAC_DB IMTR_DAC_DBREPL
IMTR_DAC_TOTDB_CALLS IMTR_DAC_MSGGU IMTR_DAC_MSGGN
IMTR_DAC_MSGISRT IMTR_DAC_MSGPURGE IMTR_DAC_TEST_ENQ
IMTR_DAC_TEST_ENQ_WT IMTR_DAC_TEST_DEQ
IMTR_DAC_QCMD_ENQ IMTR_DAC_QCMD_ENQ_WT
IMTR_DAC_QCMD_DEQ IMTR_DAC_UPDT_ENQ
IMTR_DAC_UPDT_ENQ_WT IMTR_DAC_UPDT_DEQ
IMTR_DAC_EXCL_ENQ IMTR_DAC_EXCL_ENQ_WT
IMTR_DAC_EXCL_DEQ IMTR_DAC_MSG_CMD IMTR_DAC_MSG_GCMD
IMTR_DAC_MSG_CHNG IMTR_DAC_MSG_AUTH IMTR_DAC_MSG_SETO
IMTR_DAC_APSB_CALLS IMTR_DAC_DPSB_CALLS
IMTR_DAC_GMSG_CALLS IMTR_DAC_ICMD_CALLS
IMTR_DAC_RCMD_CALLS IMTR_DAC_CHKP_CALLS
IMTR_DAC_XRST_CALLS IMTR_DAC_ROLB_CALLS
IMTR_DAC_ROLS_CALLS IMTR_DAC_SETS_CALLS
IMTR_DAC_SETU_CALLS IMTR_DAC_INIT_CALLS
IMTR_DAC_INQY_CALLS IMTR_DAC_LOG_CALLS
IMTR_DAC_DLI_DB_DEQ IMTR_DAC_VSAM_READS
IMTR_DAC_VSAM_WRITES IMTR_DAC_OSAM_READS
IMTR_DAC_OSAM_WRITES IMTR_DAC_TOTAL_IO
IMTR_DAC_ESAF_NORM IMTR_DAC_FLD_CALLS
IMTR_DAC_POS_CALLS IMTR_DAC_RLSE_CALLS
IMTR_DAC_SAVE_CALLS IMTR_DAC_RSTR_CALLS
IMTR_DAC_COPY_CALLS IMTR_DAC_ICAL_CALLS SYSTEM SMFTIME
In addition, the variables output in dataset SV34SUMM now
create a set of three IMTR variables in SV34TRAN, one set
for each DC Monitor Event type, and variables output in
dataset SV35EVNT create a set of three IMRA variables in
SV35TRAN one for each DC Monitor Event type:
IMTR_EVNT_BALG_DEQUEUE_COUNT
IMTR_EVNT_BALG_DEQUEUE_MTIME
IMTR_EVNT_BALG_DEQUEUE_TTIME
IMTR_EVNT_CHECKPOINT_COUNT IMTR_EVNT_CHECKPOINT_MTIME
IMTR_EVNT_CHECKPOINT_TTIME
IMTR_EVNT_DEDB_LOCK_IWAIT_COUNT
IMTR_EVNT_DEDB_LOCK_IWAIT_MTIME
IMTR_EVNT_DEDB_LOCK_IWAIT_TTIME
IMTR_EVNT_DEDB_OTHRD_IWAIT_COUNT
IMTR_EVNT_DEDB_OTHRD_IWAIT_MTIME
IMTR_EVNT_DEDB_OTHRD_IWAIT_TTIME
IMTR_EVNT_DEDB_READ_IWAIT_COUNT
IMTR_EVNT_DEDB_READ_IWAIT_MTIME
IMTR_EVNT_DEDB_READ_IWAIT_TTIME
IMTR_EVNT_DLA_DB_COUNT IMTR_EVNT_DLA_DB_MTIME
IMTR_EVNT_DLA_DB_TTIME IMTR_EVNT_DLA_MSG_COUNT
IMTR_EVNT_DLA_MSG_MTIME IMTR_EVNT_DLA_MSG_TTIME
IMTR_EVNT_DMB_LOAD_IWAIT_COUNT
IMTR_EVNT_DMB_LOAD_IWAIT_MTIME
IMTR_EVNT_DMB_LOAD_IWAIT_TTIME
IMTR_EVNT_DMB64_LOAD_IWAIT_COUNT
IMTR_EVNT_DMB64_LOAD_IWAIT_MTIME
IMTR_EVNT_DMB64_LOAD_IWAIT_TTIME
IMTR_EVNT_ESS_CALL_COUNT IMTR_EVNT_ESS_CALL_MTIME
IMTR_EVNT_ESS_CALL_TTIME IMTR_EVNT_IFP_ACTIVITY_COUNT
IMTR_EVNT_IFP_ACTIVITY_MTIME
IMTR_EVNT_IFP_ACTIVITY_TTIME
IMTR_EVNT_IFP_BUFFER_ACT_COUNT
IMTR_EVNT_IFP_BUFFER_ACT_MTIME
IMTR_EVNT_IFP_BUFFER_ACT_TTIME
IMTR_EVNT_IFP_MSG_IWAIT_COUNT
IMTR_EVNT_IFP_MSG_IWAIT_MTIME
IMTR_EVNT_IFP_MSG_IWAIT_TTIME
IMTR_EVNT_HSAM_IWAIT_COUNT IMTR_EVNT_HSAM_IWAIT_MTIME
IMTR_EVNT_HSAM_IWAIT_TTIME
IMTR_EVNT_ICAL_DLI_CALLS_COUNT
IMTR_EVNT_ICAL_DLI_CALLS_MTIME
IMTR_EVNT_ICAL_DLI_CALLS_TTIME
IMTR_EVNT_MSDB_WRITE_IWAIT_COUNT
IMTR_EVNT_MSDB_WRITE_IWAIT_MTIME
IMTR_EVNT_MSDB_WRITE_IWAIT_TTIME
IMTR_EVNT_OSAM_IWAIT_COUNT IMTR_EVNT_OSAM_IWAIT_MTIME
IMTR_EVNT_OSAM_IWAIT_TTIME
IMTR_EVNT_PI_ENQUEUE_IWAIT_COUNT
IMTR_EVNT_PI_ENQUEUE_IWAIT_MTIME
IMTR_EVNT_PI_ENQUEUE_IWAIT_TTIME
IMTR_EVNT_PSB_LOAD_IWAIT_COUNT
IMTR_EVNT_PSB_LOAD_IWAIT_MTIME
IMTR_EVNT_PSB_LOAD_IWAIT_TTIME
IMTR_EVNT_PSB64_LOAD_IWAIT_COUNT
IMTR_EVNT_PSB64_LOAD_IWAIT_MTIME
IMTR_EVNT_PSB64_LOAD_IWAIT_TTIME
IMTR_EVNT_QMGR_IWAIT_COUNT IMTR_EVNT_QMGR_IWAIT_MTIME
IMTR_EVNT_QMGR_IWAIT_TTIME
IMTR_EVNT_SCHEDULER_IWAIT_COUNT
IMTR_EVNT_SCHEDULER_IWAIT_MTIME
IMTR_EVNT_SCHEDULER_IWAIT_TTIME
IMTR_EVNT_STORAGE_IWAIT_COUNT
IMTR_EVNT_STORAGE_IWAIT_MTIME
IMTR_EVNT_STORAGE_IWAIT_TTIME
IMTR_EVNT_SYNC_CALLOUT_COUNT
IMTR_EVNT_SYNC_CALLOUT_MTIME
IMTR_EVNT_SYNC_CALLOUT_TTIME
IMTR_EVNT_VSAM_IWAIT_COUNT IMTR_EVNT_VSAM_IWAIT_MTIME
IMTR_EVNT_VSAM_IWAIT_TTIME
IMTR_EVNT_VSO_AREA_CASTOUT_COUNT
IMTR_EVNT_VSO_AREA_CASTOUT_MTIME
IMTR_EVNT_VSO_AREA_CASTOUT_TTIME
IMTR_EVNT_VSO_PRELOAD_COUNT
IMTR_EVNT_VSO_PRELOAD_MTIME
IMTR_EVNT_VSO_PRELOAD_TTIME
Adding IMTR_DAC and IMTR_EVNT and IMRA_EVNT variables
will DOUBLE the size of the SV34TRAN (1658 per obs vs
812) and of the SV35TRAN (1147 vs 661), and they are
still available in the much smaller SV34DAC/SV34SUMM
and SV35EVNT datasets. Typically only a handful of
those variables will be populated in the transaction
observations, but they still take space. They can be
removed and only the IMS datasets written to //PDB with
%LET MACKEEP=
MACRO _IDSVIE 255 %
MACRO _KSV34TR DROP= _DR34DA _DR34EV %
MACRO _KSV35TR DROP= _DR35EV %
_NSVIE
MACRO _WSV34TR SV34TRAN %
MACRO _WSV34DA SV34DAC %
MACRO _WSV34DL SV34DLI %
MACRO _WSV34SU SV34SUMM %
MACRO _WSV34ES SV34ESS %
MACRO _WSV35TR SV35TRAN %
MACRO _WSV35EV SV35EVNT %
MACRO _SSVIE
_SSV34TR _SSV34DA _SSV34DL _SSV34SU _SSV34ES
_SSV35TR _SSV35EV
%
;
%INCLUDE SOURCLIB(TYPSSVIE);RUN;
If you do not want to sort any of the datasets, and
want the two TRAN datasets written to separate DDs
with the smaller datasets going to PDB, you can use:
%LET MACKEEP=
MACRO _IDSVIE 255 %
MACRO _KSV34TR DROP= _DR34DA _DR34EV %
MACRO _KSV35TR DROP= _DR35EV %
;
%LET WSV34TR=SV34TRAN;
%LET WSV35TR=SV35TRAN;
%LET WSV34DA=PDB;
%LET WSV34DL=PDB;
%LET WSV34SU=PDB;
%LET WSV34ES=PDB;
%LET WSV35EV=PDB;
%INCLUDE SOURCLIB(TYPESVIE);RUN;
Thanks to Don Cleveland, Anthem BCBS, USA.
Thanks to James Robbins, Broadcom, USA.
Change 39.198 TYPE50 OSA Express Accelerated Packets was added by
VMAC50 Change 39.198, but was incorrectly spelled. The correct
Oct 8, 2021 spelling is TY50PKAC.
Thanks to Tom White, Bank of America, USA.
Thanks to Jim Sherpey, Bank of America, USA.
Change 39.197 Format $MG119CF only decoded a handful of the 357 Hex
FORMATS values, many for ZERT, for dataset TYP119111 variable
Oct 7, 2021 S11912SC_TLS_NEG_CIPHER and S119SS_TLS_NEG_CIPHER in
TYP11912TLS dataset. The doc is located in the TLS Cipher
Suite registry at http://www.iana.org/assignments/
tls-parameters/tlsparameters.xhtml
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 39.196 MXG 39.07. Change 39.183 added SMF6XSTCKE to TYPE6156,
VMAC6156 but the insert caused an INPUT STATEMENT EXCEEDED. The
Oct 7, 2021 code is bypassed until test data is received. You can use
%LET MACFILE= %QUOTE(IF ID IN (61,65,66)) THEN DELETE;
to circumvent, but request the new VMAC6156 from Support
Thanks to Jim S. Horne, Lowe's, USA.
Change 39.195 New parameters USEVMXGSET=YES & DEFER=YES adds OPEN=DEFER
BLDSMPDB to the SET statement when building weekly PDB. Use only
VSETMNTH when running on zOS and tape drives are at a premium and
Nov 26, 2021 daily PDBs are on tape. As always when using OPEN=DEFER
only variables that exist in the first dataset are
carried forward, so the first DDNAME should be the day of
the week pointed to by the WEEKSTART argument.
Thanks to Robert Olah, ENSONO, USA.
Change 39.194 Change 39.137 MXG39.05 CPUTOTTM incorrectly higher than
VMAC30 CPUTM because the calculation of SRVTCBTM which affects
Sep 30, 2021 CPUTOTTM was being done before the removal of ZIPUNITS.
Variables AVGWKSET CPUTOTTM CPUUNITS were corrected, but
the CPUTM, which is a direct value in the SMF record, has
always been correct. The CPUTOTTM based on Service Units
was created because at one time some folks incorrectly
thought the service unit based metric was significantly
more accurate than the recorded time.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND
Thanks to Mark Tomlinson, Lloydsbanking, ENGLAND.
Change 39.193 SELSMF program is similar to UTILGETM/VMXGGETM, to select
SELSMF and write SMF records of each type, but it adds SYSTEM
Oct 6, 2021 and for DB2 and CICS, the RELEASE to the criteria, and
writes the first 50 records for each selection. You can
also use MACFILE to choose which IDs you want to select;
see the example in comments.
Thanks to John Donoghue, AIB, IRELAND.
Change 39.192 -Dataset ZRBRCD added wait fields RCDWTY1-RCDWT15.
ADOCRMFV -Dataset ZRBSCL added R741Dxxx variables originally added
ASMRMFV to TYPE 74 Subtype 10 Monitor I by Change 38.089.
IMACRMFV -z/OS 2.5 MXG RMF Monitor III support.
VMACRMFV -New MXG Support for 4 more RMF III tables:
Oct 8, 2021 CPUDB IQDG3 LOKG3 VRIG3
*** New Support ***
-Support for the RMF Monitor III CPU Data Block Table
(CPUDB) recently documented with z/OS 2.5 . The CPUDB
table has existed at least since z/OS 2.1.
-The CPUDB selection option is CPV (alias N). The CPUDB
filtering option is NOCPV (aliases -CPV, -N). CPUDB is
also selected if the BASIC select group option is used.
-The CPUDB is a companion table to the CPCDB and CPUG3
tables. If any one is selected all 3 are selected. If
any one is filtered all 3 are filtered.
-Support for the RMF Monitor III I/O Queuing Performance
Data Table (IQDG3) table recently documented with z/OS
2.5 . The IQDG3 table has existed at least since z/OS
2.1.
-The IQDG3 selection option is IQD (alias Q). The IQDG3
filtering option is NOIQD (aliases -IQD, -Q). IQDG3 is
also selected if the MOST group selection option is used.
-The IOQ parameter in the RMF III startup member defaults
to IOQ(DASD). Other device classes are also supported
for IOQ by RMF III. See the RMF User's Guide (z/OS 2.3
and earlier) or the Data Gatherer User's Guide (z/OS 2.4
and up) for more details. NOIOQ will suppress the
generation of IQDG3 table.
-Support for the RMF Monitor III Lock Performance Data
Table (LOKG3) table recently documented with z/OS 2.5 .
The LOKG3 table has existed at least since z/OS 2.1.
-The LOKG3 selection option is LOK (alias #). The LOKG3
filtering option is NOLOK (aliases -LOK, -#). LOKG3 is
also selected if the MOST group selection option is used.
-The LOCK parameter in the RMF III startup member defaults
to NOLOCK. NOLOCK will suppress the generation of LOKG3
table and related MXG data sets. Specify LOCK to
generate the LOKG3 table.
-Support for the RMF Monitor III VSAM RLS Information
Data Table (VRIG3) table recently documented with z/OS
2.5 .
-The VRIG3 selection option is VRI (alias $). The VRIG3
filtering option is NOVRI (aliases -VRI, -$). VRIG3 is
also selected if the MOST group selection option is used.
-The VRIG3 collection parameter in the RMF III startup
member defaults to VSAMRLS and data is grouped by storage
class. In addition, up to 50 VSAM data set sphere masks
may be specified. See the RMF User's Guide (z/OS 2.3 and
earlier) or the Data Gatherer User's Guide (z/OS 2.4 and
up) for more details. NOVSAMRLS will suppress the
generation of VRIG3 table and related MXG data sets.
*** Enhancements ***
-Auto Selection of any field in the CPCDB and CPUG3 table
when using an IF= expression for FDF will now Auto Select
all 3 CPU companion tables (CPCDB/CPUDB/CPUG3). Auto
Selection occurs when an IF= expression references a
field name in a table that has not been explicitly
selected.
-These documentation sections in member ADOCRMFV are all
updated:
2 Terminology
4 RMF III Table Selection Parameters
12 Messages
13 Filtered Records
15 Program and IBM Limitations
23 RMF III Options That Effect Data
26 ASMRMFV and MXG PDB Data Relationship
31 Field Data Filtering (FDF)
32 Data Dictionary Descriptions
57 Summary
58 Bibliography
Change 39.191 An example z/OS ICETOOL job that selects MVIMS xF9 & xFA
ICETOOL log records to reduce the size of the IMSLOG file to be
Sep 21, 2021 read with the ftp access method for ASCII MXG execution.
Thanks to Sir Hari Kolusu, IBM DFSORT, USA.
====== CHANGES THRU 39.190 ARE IN MXG 39.07 DATED Sep 20, 2021 =======
Change 39.190 -ASMRMFV Field Data Filter (FDF) support for the RMF III
ADOCRMFV CPC data control block (CPCDB) and the Processor Data
ASMRMFV Control Block (CPUG3).
VMACRMFV -The Field Data Filter (FDF) feature of RMF III was added
Sep 19, 2021 in MXG Change 37.089 and supports filtering of raw or MXG
derived RMF data values when ASMRMFV reads the RMF III
VSAM file, reducing the size of the created RMFBSAM file
and the size of the result MXG PDB.
-RMF III table entries can be filtered by FDF based on one
or more numeric/character/bit fields using AND/OR logic.
FDF is intended for advanced MXG users building ad hoc
PDBs of RMF III data for studies and investigations.
-A z/OS LPAR is a z/VM guest if this message appears in
the ASMRMFV log:
RMFV009I ORIGIN : CPCNAME=VMGUEST
-NOTE: For LPARs running as z/VM guests the CPC LPAR and
Logical Processor Sections in the CPCDB table are created
by RMF III as binary zeros and cannot be filtered with
FDF. MXG PDB variables sourced from the CPC LPAR and
Logical Processor sections will have SAS missing values
in the result PDB.
In this case only the sparse CPCDB header will be written
to RMFBSAM. Any FDF filters for fields in either of
these two sections will be bypassed. They are NOT
counted as IGNORE in message RMFV080I.
-NOTE: For z/OS LPARs running as z/VM guests RMF III
creates the Home LPAR section in the CPCDB table as all
binary zeros and these fields cannot be filtered with
FDF. MXG PDB variables sourced from the Home LPAR
section will have SAS missing values in the result PDB.
In this case any FDF filters for fields in the Home LPAR
section will be counted as IGNORE in message RMFV080I.
-FDF VNT (Variable Name Table) derived floating point
variables with ASISASSC as a divisor were using a fixed
point binary divisor instead of a short floating point
divisor.
- FDF VNT entry for derived variable R745IORATE had
incorrect data type of FP instead of FPAVG.
-Further reduction of ASMRMFV assembly output with
NODXREF, NOESD, NORLD, USING(NOMAP) added to *PROCESS
statements.
-Expand RMFV092E table error message from 2 to 4 lines to
show more RMF III information at time of the error.
-FDF calculations for CRYG3 table MXG derived variables
CRYTIME0-CRYTIME5 were incorrect.
-FDF calculations for CRYG3 table MXG derived variables
CRYUTIL0-CRYUTIL5 were incorrect.
-FDF calculations for DVTG3 table for 6 MXG derived
variables DVTAVG* were incorrect. These were being
handled as floating point while the source fields are
fixed binary.
-FDF IF evaluation code not correctly checking for PCI
format code when comparing a variable that has one.
-FDF IF evaluation code tests for STOP/NOSTOP and
SYNC/NOSYNC for FDF SSHG3 table were incorrect.
-XCFSTAT variable was missing from XCFG3 FDF VNT table.
-Message RMFV017I now displays z/OS 2.5 when processing
RMF Monitor III data from that release.
-New filter options ZEROLP/NOZEROLP added for CPCDB table
processing. The default is NOZEROLP.
- ZEROLP says to output to RMFBSAM all LPAR sections and
their respective Logical Processors Sections from the
CPCDB table even if zero Logical Processors were defined
for an LPAR. This was the behavior of prior ASMRMFV
versions.
-NOZEROLP says to only output to RMFBSAM LPAR sections
from the CPCDB table that have a non-zero number of
Logical Processors defined. NOZEROLP is the default.
-ZEROLP/NOZEROLP option added to message RMFV006I.
-ASMRMFV no longer outputs zero Logical Processor Sections
to RMFBSAM for those undefined for a specific LPAR. The
CPCDB table reserves 240 Logical Processor Sections for
each LPAR. The actual number defined will be far less.
-In a test using a single RMF III VSAM data set with the
default NOZEROLP in effect output to RMFBSAM for the
CPCDB table was reduced by 8MB. Actual results may vary.
-In ASMRMFV detail and summary reports TOTAL BYTES OUTPUT
in message RMFV104I did not match ALL total of detail or
summary lines in message RMFV105I by a consistent value
of 3400 bytes less.
-First RMF and Z/OS Version numbers added to MXG01 record.
-Last RMF and Z/OS Version numbers added to MXG02 record.
-Data Dictionaries in the ADOCRMFV member have been
updated or added for all FDF supported RMF III tables.
-Many Data Dictionary entries now have additional notes
describing the entry in addition to similar text already
present in the corresponding section documentation.
-Following Sections are updated or added in the ADOCRMFV
documentation member:
Section Contents
------- --------
0 Contents
7 Output Data Control Parameters
12 Messages
15 Program and IBM Limitations
26 ASMRMFV and MXG PDB Data Relationships
31 Field Data Filtering (FDF)
32 Data Dictionary Descriptions
33 Filtering The ASIG3 Table
34 Filtering The CATG3 Table
35 Filtering The CFIG3 Table
36 Filtering The CPCDB Table
37 Filtering The CPDG3 Table
38 Filtering The CPUG3 Table
39 Filtering The CRYG3 Table
40 Filtering The CSRG3 Table
41 Filtering The DSIG3 Table
42 Filtering The DVTG3 Table
43 Filtering The ENCG3 Table
44 Filtering The ENTG3 Table
45 Filtering The GEIG3 Table
46 Filtering The OPDG3 Table
47 Filtering The PCIG3 Table
48 Filtering The SCMG3 Table
49 Filtering The SPGG3 Table
50 Filtering The SSHG3 Table
51 Filtering The XCFG3 Table
52 Filtering The ZFXG3 Table
57 Summary
58 Bibliography
Change 39.189 Variable SMF70TYP is now KEPT in TYPE70PR, eliminating an
VMAC7072 UNINITIALIZED variable message that had no impact but was
Sep 16, 2021 un-needed.
Change 39.188 Support for CICS-DB2 ATTACH APAR PH31440 "accounting"
FORMATS fields to DB2ACCT dataset:
VMACDB2 QMDAAEYE $EBCDIC36. /*QMDAAEYE*EYE*CATCHER*/
Sep 16, 2021 QMDAADT1 $EBCDIC64. /*QMDAADT1*1ST*ADAPTER*/
QMDAADG2 $EBCDIC64. /*QMDAADT1*2ND*ADAPTER*/
QMDAADG3 $EBCDIC64. /*QMDAADT1*3RD*ADAPTER*/
Note: LENQMDA=260,24 undoc bytes after DG3 PH31447.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 39.187 New TYPE80TK values create new variables
VMAC80A TOKHUKID TOKCRITIC TOKZERTI TOKTECHNIK TOKORGA
Sep 15, 2021 TOKMASTERID TOKBMKS TOKCREATED TOKABPFZ TOKINTERVAL
TOKINFO TOKVERANTW1-TOKVERANTW4
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 39.186 Support for APAR OA61368 which populates two bits in the
VMAC30 RAXFLAGS which are new variables in TYPE30 datasets:
Sep 13, 2021 SMF30_RAXFLAG5='RAX5*ATTEMPT*EARLY*RUCSA?'
SMF30_RAXFLAG6='RAX6*ALLOW*EARLY*RUCSA?'
Change 39.185 IMACKEEP included so that you can customize and tailor
ASUMCICS without touching the ASUM member.
Sep 8, 2021
Change 39.184 -Support for NDM-CDI PTF UI76063 that sets a flag bit if
VMACNDM NDMNODEF='S' (CDZ was acting as SNODE) the PNODE/SNODE
Sep 4,2021 values were wrong and had been corrected for Version 6 or
for Version 5.2, if the bit is NOT on, then MXG has made
the correction. MXG sets NDMFLAG'N' for the NDM change
or NDMFLAGX='M' if MXG reversed the PNODE and SNODE, in.
the CT, FI, and MC records.
-Support for PTF UI76043 which corrects the NDMCPU Time
("TIMEUSED" field) which was wrong (too large) in 6.0.
Thanks to Tom White, Bank of America, USA.
Change 39.183 New variable SMF6XSTCKE, the SMF datatime in STCKE is
VMAC6156 added to TYPE6156 dataset.
Sep 4, 2021 See Change 39.196.
Change 39.182 The UTILEXCL tailoring MACRO _ECICDIC contained a LABEL
UTILEXCL statement that restricted the use of that exit; the LABEL
Sep 3, 2021 variables were moved to the existing LABEL statement at
the top of the code block.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.181 Variables BOOSTACTIVE and BOOSTCLASS are added to the
BUILD005 PDB.STEPS dataset, and BOOSTCLASS is only populated if
BUIL3005 BOOSTACTIVE is populated in SMF 30 and SMF 89 records.
FORMATS Format MG090EV was expanded and typo corrected.
VMAC30
VMAC89
Aug 30, 2021
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.180 Enhanced MXGABND can set Condition Code instead of ABEND,
IMACABND The use of %LET MXGABND=nnn in your tailoring was added
VMAC110 and documented in Change 23.184 to cause an ABEND for
Aug 28, 2021 some error messages, but this caused BUILDPDB to ABEND
due to an SMF 110 EXCLUDED fields errors. This change
lets you choose to set a Condition/Return Code so that
you can identify there was a problem, but BUILDPDB will
complete and you can find the ERROR message in the log.
You can test for the Condition Code in a new step and
send a message that a change was detected.
In addition, the ABEND will only occur on z/OS; on ASCII
the ABEND kills the current session which is nasty to
debug! Currently the IMACABND is only implemented in
the SMF 110 processing. To change, you would tailor
IMACABND per its comments into your "USERID" PDS.
Thanks to Dawn Clarke, ENSONO, USA.
Change 39.179 Support for Dino VelociRaptor SMF records,
EXVELO01 DDDDDD DATASET DESCRIPTION
EXVELO02 VELO01 VELOST01 VSAM OPTIMIXATION
EXVELO04 VELO02 VELOST02 QSAM BUFFER OPTIMIZATION
FORMATS VELO04 VELOST04 QSAM BLOCKSIZE OPTIMIZATION
IMACVELO
TYPEVELO
TYPSVELO
VMACVELO
VMXGINIT
Aug 27, 2021
Thanks to Kihun Cha, Navy Federal, USA
Change 39.178 Support for Dell PRF Monitor MFE Version 8.5 SMF data.
EXPRFDBK DDDDDD DATASET DESCRIPTION
EXPRFDEV PRFSYM PRFSYMME SYMMETRIX
EXPRFDMF PRFDBK PRFDBKEN BACKEND
EXPRFDOP PRFDOP PRFDOPEN OPEN SYSTEM
EXPRFDPO PRFDMF PRFDMFRA MAINFRAME
EXPRFDSR PRFDSR PRFDSRDF SRDF
EXPRFSYM PRFDPO PRFDPORT PORTS
EXPRFTDV PRFDEV PRFDEVIC DEVICE
FORMATS PRFTDV PRFTTDAT TDAT DEVICE
IMACPRF
TYPEPRF
TYPSPRF
VMACPRF
VMXGINIT
Sep 1, 2021
Change 39.177 JES3 ONLY, and only if you tailored UTILBLDP BUILDPDB=NO
VMAC110 and USERADD=25 26J3 with INCLAFTR=BUIL3005. The 25 caused
Aug 24, 2021 the WORK.TYPE25 data set to be created and sorted to the
PDB.TYPE25 (done for all USERADD=) but also WORK.TYPE25
was deleted, but BUIL3005 expected WORK.TYPE25, causing
ERROR: DATA SET WORK.TYPE25 WAS NOT FOUND. Removing the
%VMXGDEL in _S25 macro leaves WORK.TYPE25 to correct.
Change 39.176 Support for CICS/TS 6.1 (INCOMPATIBLE, field inserted).
VMAC110 One new field, SOTLSLVL='INBOUND*TLS*LEVEL*SELECTED'
UTILEXCL is added to dataset CICSTRAN. Because the CICSTRAN
Aug 23, 2021 record is a concatenation of control blocks, when IBM
adds a field at the end of a control block, it still
shifts all subsequent fields, requiring an MXG Update.
This change is only for CICSTRAN; other new fields for
other datasets will be added when test data is available.
Change 39.175 Support for BMC CONTROL-D CSV FILE, a log for audit of
EXCTLCSV the webserver. The INFOLE name is BMCCSVIN to create:
IMACCTLC DDDDDD DATASET DESCRIPTION
TYPECTLC CTLCSV CTLDCSV CONTROL-D CSV
TYPSCTLC
VMACCTLC
VMXGINIT
Aug 22, 2021
Thanks To Craig Collins, State of Wisconsin, USA.
Thanks to Maggie Buday, State of Wisconsin, USA.
Change 39.174 TYPE41VF dataset, variables SMF41YAG and SMF41MAG contain
VMAC41 "high" values of 0FFFFFFFF which indicate that no
Aug 19, 2021 trimming occurred, but confused calculations, so those
values are now set to a missing value.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.173 New Format $MGNDMCP for variable NDMCPEA decodes the
FORMATS CIPHER Suite values.
VMACNDM VALUE $MGNDMCP
Aug 19, 2021 '01'X='01X:NULL_MD5'
'02'X='02X:NULL_SHA'
'03'X='03X:RC4_MD5_EXPORT'
'04'X='04X:RC4_MD5_US'
'05'X='05X:RC4_SHA_US'
'06'X='06X:RC2_MD5_EXPORT'
'09'X='09X:DES_SHA'
'0A'X='0AX:TRIPLE_DES_SHA_US'
'2F'X='2FX:AES_128_SHA'
'3C'X='3CX:???????????'
'3D'X='3DX:???????????'
'35'X='35X:AES_256_SHA'
'9C'X='9CX:???????????'
'9D'X='9DX:???????????'
'E7'X='E7X:???????????'
'EF'X='EFX:???????????'
OTHER=?< $HEX2. ?>
Change 39.172 Support for SMF14DSENCARCHKEY flag that indicates that
VMAC1415 the encrypted dataset is being accessed with an archived
VMAC62 key that only supports decrypt operations in TYPE1415.
Aug 18, 2021 Support for SMF62ARCKEY flag that encrypted data set is
being accessed with an archive key that only supports
decryption.
Change 39.171 WPS ONLY. A problem has been found with the use of the
FLASH INPUT statement reading values into temporary array
Aug 18, 2021 members with informats, resulting with incorrect values
(zero or a missing value) for these "TYPE70" variables:
NRZIPCPU NRPHYCPS AVCPSCPU AVICFCPU
AVIFACPU AVIFLCPU AVZIPCPU NRCPSCPU
PLATBUSY PLATCPUS PLATZIPBUSY PLATZIPCPUS
PLATIFLBUSY PLATIFLCPUS PLATICFBUSY PLATICFCPUS
PARTNCPU PARTNICF PARTNIFL PARTNZIP
as their INPUT includes S70CTN(_I_) &PIB.2. array syntax.
The error was introduced in wps-4.03.01, but earlier
versions (4.00, 4.01, 4.02, and 4.03.00 are unaffected.
The error was fixed in these releases:
WPS 4.04.00.03.3277 15-Aug-2021 (MB)
First maintenance version of WPS 4.4 containing the fix
WPS 4.04.00.03.3369 7-Sep-2021 (EA3)
Current EA version of 4.4, containing the fix.
WPS 4.03.02.00.8569 13-Aug-2021 (MB)
First maintenance version of WPS 4.3 containing the fix
WPS 4.03.03.00.8595 2-Sep-2021 (GA)
Current GA version of WPS 4.3, containing the fix.
Change 39.170 Variable SMF9040ID was defined as a character thru 39.03,
VMAC90A but was decoded as numeric in 39.05, so combining old and
Aug 11, 2021 new TYPE9040 data sets raised a conflict. Now, SMF9040ID
is no longer created and TYPE9040IDNR is numeric and is
decoded. You may need to copy your old TYPE9040 dataset
and drop variable TYPE9040ID before you run that WEEKBLD.
Thanks to Jim S. Horne, Lowe's, USA.
Change 39.169 Unused Change Number.
Change 39.168 -Improvements and corrections to PROCSVP subroutine
ASMRMFV segmentation of SVPG3 table when longer than 32756 bytes.
VMACRMFV -PROCSVP subroutine always moves 32760 bytes to output
EXZRBV15 buffer for unsegmented SVPG3 tables even if not needed.
EXZRBV16 -ZOSTABLE updated to 797 for RMF version for z/OS 2.5.
EXZRBIQD -Debugging PUTLOGs (added in 39.06) for SVP removed.
IMACRMFV -ASMRMFVF and ASMZOSVF fields added to MXG01 record with
VMXGINIT first RMF and first z/OS version in each RMF III VSAM
Aug 22,2021 file, and ASMRMFVL and ASMZOSVL fields added to MXG02
record with last RMF and last z/OS version. Those fields
and the ASMRMFV Version and Create Date are printed on
the log of the TYPERMFV execution.
-There are three new RMF III tables added by z/OS 2.5,
IODG3, LOKG3, VRIG3, and old table CPUDB is documented,
to be supported when we have we have an interested user
with those tables enabled.
-MXG 39.06 supports all existing tables in z/OS 2.5.
-New variables in /OS 2.5 manual added to ZRBRCDS dataset.
RCDTETX='TOTAL*TRANSACTION*ELAPSED'
RCDXETX='TOTAL*TRANSACTION*EXECUTION'
RCDQDTX='QUEUE*DELAY*TIME'
RCDADTX='RESOURCE*AFFINITY*DELAY*TIME'
RCDCVTX='JCL*CONVERSION*DELAY'
RCDIQTX='INELIGIBLE*QUEUE*TIME'
RCDRTDM='MIDPOINT*OF RESPONSE*TIME'
RCDPRS ='PAGE*RESIDENCY*TIME'
RCDCIOU='TOTAL*I/O*USINGS'
RCDCIOD='DASD*I/O*DELAY*SAMPLES'
RCDCIDL='IDLE*SAMPLES'
RCDCUNK='UNKNOWN*SAMPLES'
RCDPADJSCF='SCALING*FACTOR*FOR*RCDPADJ'
RCDPADJ='PHYSICAL*CPU*ADJUST*FACTOR*FOR CP'
====== CHANGES THRU 39.167 WERE IN MXG 39.06 DATED Aug 12, 2021 ========
Change 39.167 PDBOUT= parameter added so that you can retain the
ANALINIT datasets created.
Aug 10, 2021
Change 39.166 COMPALL is a test programs that compiles all MXG programs
TECHNOTE that process SMF records in a single step, to detect any
COMPALL cases where temporary variables (not kept) in products
COMPIBM have conflicting attributes (especially NUM and CHAR).
Aug 10, 2021 It also reports the resources needed for this irrational
program. Windows 10 required 3693 MiB, but failed on
z/OS where only 1588 MiB was available. The 940,00
lines of code required 3 minutes elapsed, 30 CPU seconds.
COMPIBM tests only the IBM created SMF records, and that
program did complete on z/OS where it needed 903 MiB.
Change 39.165 Format $MGSMFID is updated for SMF ID=1153 and 1154 types
FORMATS and comments in IMACSMFF revised since IBM owns 0-127 and
IMACSMFF 1152-2047 and 128-1151 are now the available USER types.
Aug 9, 2021
Thanks to MP Welch, BOA, USA.
Change 39.164 NMONUARG records containing only the PID and FULLCOMD
VMACNMON were previously deleted, but now THCOUNT=1 is set so the
Aug 2, 2021 record is output.
Change 39.163 Support for JES2 Monitor SMF Type 1153 record replacement
EX1153J2 for Type 84 Subtype 21 JES2 Monitor in z/OS 2.5. Three
EX1153JM data sets are created:
EX1153JR DDDDDD DATASET LABEL SUBTYPE
IMAC1153 11532 J11532 JES2 PRODUCT + GENERAL n/a
TYPE1153 1153JM J1153JM JES2 MEMORY 1
TYPS1153 1153JR J1153JR JES2 RESOURCES 1
VMAC1153 This is the first IBM record with Extended SMF Header
VMACSMF which has the "normal" SMF ID=126 in original header,
VMXGINIT and the real ID in the extended header. IBM owns the
Aug 9, 2021 IDs 0-127 & 1152-2047 while 128-1151 are for users.
Change 39.162 Some variables had a length of 8 that should have been
VMXGRMFI set to 5 on zOS or 6 on ASCII.
Aug 1, 2021
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.161 INHERIT KEEPLEN are now always invoked in PROC MEANS in
VMXGSUM VMXGSUM to preserve input variable attributes.
Aug 1, 2021
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.160 Data set DB2STATB now has BPHITRAT kept and the equation
VMACDB2 was revised based on IBM DB2 12 Performance Guide.
Jul 30, 2021
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.159 New variable in RMF III dataset ZRBGEI added:
VMACRMFV GEIFLG22='RUCSA*IS*DEFINED?'
Jul 30, 2021
Change 39.158 Support for Quick Select SMF records creates 5 datasets:
EXQSEL00 dddddd dataset description
EXQSEL01 QSEL00 QSELSM00 QSELSM START
EXQSEL02 QSEL01 QSELSM01 QSELSM THREAD
EXQSEL03 QSEL02 QSELSM02 QSELSM QSEL STOP
EXQSELPG QSEL03 QSELSM03 CACHE DEALLOCATION
FORMATS QSELPG QSELSMPG PROGRAMS
IMACQSEL
TYPEQSEL
TYPSQSEL
VMACQSEL
VMXGINIT
Jul 29, 2021
Change 39.157 ONLY if you installed MXG's IEFU84 SMF Exit to put the
IEFU84 INITNUMB and INITNAME fields in the SMF 30 records,
Jul 28, 2021 WPS did not correctly handle 'NOT IN' when the (...)
text had both character and hex strings, causing blank
in INITNAME and bad INITNUMB. The WPS Error was fixed
in WPS version 4.3.2 Build 8525
("wps-4.3.2.0.8525-ga-maintenance-zos").
Change 22.136 describes MXG's IEFU84 SMF Exit.
Thanks to Steve Bagshaw, ITMetrics, ENGLAND.
Change 39.156 WPS does not yet support compress on a LIBNAME statement.
VMXGALOC Now, if compress=yes is specified, it is set to null.
Jul 28, 2021
Change 39.155 DB2 removed Hiperpools and Buffer Pools in DATA SPACES in
VMACDB2 DB2 V8.1, but QDBPHPSZ appears to be reused by IBM, so it
Jul 28, 2021 is now set missing for 8.1 or later.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.154 Support for VIRTEL AUDIT VIRSTAT SMF record creates:
EXVIRSTB DDDDDD DATASET DESCRIPTION
EXVIRSTC VIRSTB VIRSBIN VIRTEL BINARY HTTP INBOUND
EXVIRSTH VIRSTC VIRSTAT VIRTEL VIRSTAT CLASSIC FORMAT
IMACVIRS VIRSTH VIRSHTTP VIRTEL HTTP INBOUND.
TYPEVIRS -VIRSTIME and VIRSDURCALL corrected Aug 17, 2021.
TYPSVIRS
VMACVIRS
VMXGINIT
Jul 28, 2021
Aug 17, 2021
Thanks to Maggie Buday, State of Wisconsin, USA.
Thanks to Craid Collins, State of Wisconsin, USA.
Change 39.153 -New variables in TYPE83LD dataset:
EXTY8308 LDAP_TARGET_MESSAGE_ID LDAP_DISCONNECT_CAUSE
EXTY8311 -Five Relocate Segments have multiple observations that
EXTY8312 create these new datasets with the list of attributes:
EXTY8313 TYP83208 LDAP ADD ATTR
EXTY8320 TYP83211 LDAP MOD ATTR DEL
IMAC83 TYP83212 LDAP MOD ATTR ADD
VMAC83 TYP83213 LDAP MOD ATTR REP
VMAC83 TYP83220 LDAP SEARCH ATTRS
VMXGINIT -Those datasets may not be useful and they can be quite
Jul 26, 2021 large. If you determine you don't need them, insert
this statement in //SYSIN and they will all have zero
observations and will take no space.
%LET MACKEEP=
MACRO _ETY8308 %
MACRO _ETY8311 %
MACRO _ETY8312 %
MACRO _ETY8313 %
MACRO _ETY8320 %;
Thanks to Nathan Loewenthal, CITIGROUP, USA.
Change 39.152 New parameter TRNDOUTCODE allows you to insert SAS code
VMXGRMFI before the OUTPUT TRNDRMFI is executed.
Jul 22, 2021
Change 39.151 New variables that were not kept in CIMSTRAN now are:
VMACCIMS TRNMISCH TRNOTEIP TRNOVHD TRNW5GSP
Jul 22, 2021
Thanks to Sieghart Seith, FICUCIA, GERMANY.
Change 39.150 The read and write bucket count pairs are now correctly
VMACRMFV read in a pair of 4-byte READ PCIRDREADVARnn and 4-byte
Jul 19,2021 WRITE PCIRDWRITCNTnn for each of the 15 counters pair.
====== CHANGES THRU 39.149 ARE IN MXG 39.05 DATED Jul 16, 2021 ========
Change 39.149 The rarely used DB2STATB DB2 Buffer Pool dataset has been
VMACDB2 wrong for some time for 8-byte DIF()d counters, just now
Jul 15, 2021 reported.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.148 A missing ; on the LIBNAME TREND statement caused this
VMXGALOC ERROR: Libref TREND is not assigned.
Jul 16, 2021 -If you invoked VMXGALOC from IMACINIT with READONLY
set to NO a CC=8 was generated and a scary sounding
message was on the log. Now no CC is set, the
message is suppressed unless MXGDEBUG=VMXGALOC is
used and READONLY is set to YES.
Thanks to Ervin Claxon, CSX, USA
Change 39.148 A missing ; on the LIBNAME statement caused this error:
VMXGALOC ERROR: Libref TREND is not assigned.
Jul 15, 2021 -If you invoked VMXGALOC from IMACINIT with READONLY
set to NO a CC=8 was generated and a scary sounding
message was on the log. Now no CC is set, the
message is suppressed unless MXGDEBUG=VMXGALOC is
used and READONLY us set to YES.
-If you dont want to run weekly and/or monthly, WEEKKEEP=0
and MNTHKEEP=0 will suppress the creation and allocation
of WEEKS and MONTHS.
Change 39.147 -CICSTRAN variable OADATA1 is decoded into datetime+text,
VMAC110 but the hex value is needed to match TYPE123A records so
Jul 15, 2021 new variable ADATA1X is the $CHAR64 input $HEX128 format,
-If you have an tailored IMACEXCL in USERID.SOURCLIB, you
need to find MACRO _VCICTRN ABCODE and add OADATA1X:
MACRO _VCICTRN KEEP= ABCODE OADATA1X
A later change will add OADATA1X when UTILEXCL creates a
new IMACEXCL.
Variable ISIOWTTM is now correctly formated TIME12.2
Thanks to Al Hirst, Wells Fargo, USA.
Change 39.146 -MONTHBL3 the JES3 monthly for BUILDPD3, had two instances
MONTHBL3 of _MNTHBLD and the second was missing an IF statement
MONTHPDB that dropped OBS where ZDATE was less than the start of
Jul 12, 2021 the last week, resulting in some duplicate OBS in
monthly datasets.
-New MONTHPDB member is an example generic monthly job
that is easier to tailor since you can specify what
datasets to keep and which to drop. It is also simpler to
rerun if needed without the need to edit MXG MACROS.
Change 39.145 SMF 110 Subtype 1 MNSEGCL=5 (NOT CICSTRAN) ABEND CICS 5.3
VMAC110 INPUT STATEMENT EXCEEDED if CICSRDPL Resource DPL Detail
Jul 11, 2021 optional dataset is enabled with CICS/TS 5.3. The CICRDD
segment in this back-level CICS was only 32 bytes but MXG
expected 40, and apparently no other 5.3 site had turned
on the optional DPL segment. The circumvention is to put
%LET MACFILE=
%QUOTE(IF ID=110 AND SUBTYPE=1 AND MNSEGCL=5
THEN DELETE; ) ;
in your //SYSIN.
And if you are unable to easily EDIT your job's SYSIN,
you can override the //SYSIN in your JCL with:
// EXEC MXGSASxx
//SYSIN DD *
%LET MACFILE=
%QUOTE(IF ID=110 AND SUBTYPE=1 AND MNSEGCL=5
THEN DELETE; ) ;
// DD DSN=YOUR.NORMAL SYSIN,DISP=SHR
Thanks to Bryan Willers, Sirius, USA.
Thanks to Ned Day, Sirius, USA
Change 39.144 The z/OS NOCAPSOUT option prints SASLOG messages in mixed
CONFIGXX case, which we need for debugging. With ODS, USS, LINUX
Jul 9, 2021 commands in SYSLOG messages, we need to see the exact
text that was executed Even though it is the default,
it is set in CONFIGs to override a SAS CAPSOUT option.
Change 39.143 Format $MGSMFID did not describe SMF 123 Subtype 2,
FORMATS Liberty z/OS Connect Endpt.
Jul 9, 2021
Thanks to MP Welch, Bank of America, USA.
Change 39.142 Model 204 requires a separate SMF record ID for each3of
VMACM204 the four macros defined in VMACM204 lines 26-37.
Jul 8, 2021 Some character hex variables are now formatted $HEX.
Thanks to Linda Berkeley, DISA Mainframe, USA.
Change 39.141 Updates to SYSVIEW IMS datasets SV34TRAN and SV35TRAN.
VMACSVIE Many new fields have been added, with some corrections.
Jul 14, 2021
Change 39.140 If you specified READSMF=YES and PDBOUT=WORK an error
ANALMSUS resulted:
Jul 8, 2021 ERROR: UPDATE VIEWS ARE NOT SUPPORTED.
caused by using the same name on output and on input in a
data step where a VIEW was specified.
Thanks to Roger Lowe, NT.GOV, AUSTRALIA.
Change 39.139 Change 39.092 erroneously bypassed the creation of the
VFMT102 FORMAT and QA failed with a FORMAT NOT FOUND. Now the
Jul 6, 2021 FORMAT is created even when zero OBS are detected.
Change 39.138 A new RMF Interval is started when the processor speed is
VMAC7072 changed, but changing only the number of CPUs does NOT,
Jul 7, 2021 and the TYPE70 had a negative value for LCPUPDTM in the
PHYSICAL LPARNAME, but when read as a positive binary.
those leading 'FFFF...'x became 256E09 corrupting all of
the CPU reporting for PHYSICAL. MXG now protects by
detecting the LCPUPDTM is greater than the DURATM and
setting it to zero. A service report is open with IBM
RMF Data Gathering and an APAR is expected.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 39.137 Change 29.025 dealt with small negative CPUUNITS and set
VMAC30 CPUUNITS=0 if CPUTCBTM was 0, and AVGWKSET was only
Jul 1, 2021 calculated if CPUUNITS were non-zero. By relocating the
SRVTCBTM to use the original CPUUNITS, and then using
MAX(CPUTCBTM,SRVTCBTM) for the AVGWKSET more obs were
populated.
Thanks to Stephen Hoar, LLoyds Banking, ENGLAND.
Change 39.136 SAS does not permit special characters in variable names,
RMFINTRV except for the underscore. If you have service classes
UTILWORK names with a special character and use UTILWORK to build
VMXGRMFI your RMFINTRV code, VMXGRMFI fails with syntax errors.
Jul 1, 2021 because the service class/report class name is used as
the first part of the variable name; class BAT#PROD
becomes BAT#PRODCPU etc. MXG now detects the bad names
flags them with error messages, and changes them to a
name of BADNAMEx where x is the number of bad names that
were detected. RMFINTRV file is created, but CC=5 is
set as a warning.
Thanks to Miguel Fernandez, BNYMELLON, USA.
Change 39.135 Change 39.080 caused an ABEND on zOS, but not on ASCII,
ANALDB2R because of a superfluous %END statement error, even
PMAUD02 though the error message said the statement would be
Jun 29, 2021 ignored. This behavior was due to the differing values
for ERRORABEND, which is NOT enabled in ASCII AUTOEXECs,
but is enabled in the z/OS CONFIG members.
Specifying NOERORRABEND the same job ran with CC=8.
Thanks to Wayne A. Schumack, USBank, USA.
Change 39.134 Unused Change Number
Change 39.133 Support for Record 'DB' created new NDMDB dataset.
EXNDMDB NDMRTYPE "HW" and "H2" records do not match the DSECT; at
VMACNDM present these records are skipped until documentation
VMXGINIT matches data. NDMRTYPE "SF" is also skipped as it
Jun 25, 2021 only contains a timestamp of no value.
Jul 16, 2021 -Updated Jul 16 and DB record validated.
-Since version 26, NDM has a truncated NDMCERT field that
no one has complained about, so I have suppressed the
ERROR message until a user actually needs NDMCERT and
wants to pursue with NDM Support.
Thanks to Robert Chavez, Florida Power and Light, USA.
Thanks to Rob D'Andrea, NATWEST, SCOTLAND.
Change 39.132 Support for Recovery Boost Start/End values in MG090EV
FORMATS format for variable SMF9040E, and and Requestor_ID values
VMAC90A 2021 in MG090ID format for variable SMF9040ID.
Jun 22, 2021 In Error, SMF9040ID was changed to numeric from char.
Aug 16, 2021 in dataset TYPE9040. See Change 39.170.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 39.131 Updates and corrections for SMF TYPE 50 VTAM Tuning.
VMAC50 New variables in dataset TYPE502R and TYPE502W
Jun 22, 2021 INPIOS ='INBOUND*PIUS*(IPIU)'
OUTPIOS ='INBOUND*PIUS*(OPIU)'
TSWEEP ='TIMER*SWEEPS*(TSWEEP'
QSWEEP ='QUEUE*SWEEPS*(QSWEEP)'
NRWRIREC ='NUMBER*OF WRITE*RECORDS'
NRREAREC ='NUMBER*OF READ*RECORDS'
Change 39.130 If you did not specify PDBOUT= or used PDBOUT=WORK a
READDB2 message was generated telling you that the output would
Jun 21, 2021 go to WORK. Message is now suppressed if PDBOUT=WORK.
Change 39.129 If you asked for 102.xxx or ID you could get this error
UTILBLDP when UTILBLDP built the code to clear the substitution
Jun 21, 2021 macros
ERROR: Old-style macro name _ID102.xxx must contain...
Change 39.128 TYPE71 variables PAGBLAV and PAGBLMX were reversed.
VMAC71
Jun 16, 2021
Thanks to Greg Goshia, Westfield, USA.
Change 39.127 The Liberty SMF Type 123 Subtype 2 4-byte variable SYSTEM
VMAC123A INPUT from the SMF Header was overwritten by the 8-byte
Jun 17, 2021 SYSNAME/CVTSNAME field that I had incorrectly also INPUT
into SYSTEM. Now the SYSTEM and SYSNAME are correct.
Thanks to Al Hirst, Wells Fargo, USA.
Change 39.126 The PRINT=YES option only printed 20 observations instead
VMXGFIND of printing all observations of each datasets.
Jun 15, 2021
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.125 The STCKE GMTOFF92 was wrong; the STCKE returned value
VMAC92 is 60 years larger than current, causing invalid times
Jun 14, 2021 for those datetime variables.
Change 39.124 Enhanced to support specification of multiple basedirs.
VGETALOC See the Linux example in the member.
Jun 11, 2021
Change 39.123 -INVALID DATA FOR ENDTIME in TYPE16 record had only the
VMAC16 the time part populated. IBM support pointed out that the
Jun 21, 2021 ICERSUB=3 is a "Short Record Unsuccessful Execution" and
"Depending on the severity of an unsuccessful run,
information might not be provided in some fields in the
SMF record. There were 17 records with 3, but only one
with invalid ENDTIME, and now the dump and error message
are suppressed if that variable is invalid.
-IBM variable ICESZRNU identifies why zSORT was NOT USED,
and a zero value is supposed to mean zSORT WAS used, but
these records with a zero also have ICEFLBY5='N' flag
that zSORT was NOT used. Now, MXG sets IZESZRNU=-1 for
these records that did NOT use zSORT. But only one site
had this issue, a second site only had ICESZRNU=0 only
for zSORT use.
-The zSORT segments were never being INPUT because the
variable LENLEFT was not populated. Variable
Thanks to Rob D'Andrea, NATWEST, SCOTLAND.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.122 -ASMRMFV VAR macro code was inadvertently regressed, still
ASMRMFV using the ISHEX macro function that is not supported for
VMACRMFV back level ASM Assembly program. UI47658 is current,
Jun 11, 2021 failure was with UI60352 Dec 18, 2020.
-INPUT STATEMENT EXCEEDED on CPUG3 record, CPCUDBOFF was
a missing value which was only set for CPUVERG=6.
-Additional ASMRMFV validation checks for RMF III SSHG3
table for SSHTIBEG LT SSHTIEND and SSHSMPNR (number of
MINTIME samples) non zero, and will delete the interval
if not satisfied. We have seen only one instance.
Change 39.121 A rerun within the same SESSION failed because we did not
UTILBLDP reset the MACRO _IDs, with ERROR: Old-style macro name
Jun 6, 2021 must contain only letters, digits and underscores.
Change 39.120 VMXGALOC is only for ASCII execution where it allocates
VMXGALOC and manages all of the MXG SAS PDB Data Libraries. IF
Jun 4, 2021 you did not specify FIRSTRUN=YES the first time you ran
it, many libraries were not allocated causing MXGERRORs.
The FIRSTRUN=YES logic should have been used only for
the copy functions and should not have been used to
control the allocation of new PDBs. Now the directory's
existence is tested and allocated if doesn't exist.
Change 39.119 -Support for HSM ZEDC Compression adds variables to the
FORMATS HSMFSRST dataset.
VMACHSM FSR_ZEDC_COMPRESS_PPRCNT='PERCENT*SAVED*BY ZEDC'
Jun 8, 2021 FSR_USER_DATASIZE='FSR*USER*UNCOMPRESSED*DATASIZE'
FSR_COMP_DATASIZE='FSR*COMP*COMPRESSED*DATASIZE'
FSR_COMP='ZEDC*OMPRESSED*BEFORE*MIGRATION?
FSR_ZEDC='ZEDC*COMPRESSED*DURING*MIGRATION?'
FSRFMB='FSRBYTR*AND*FSRBYTW*CONVERTED*TO BYTES?'
-USER_DATASIZE/COMP_DATASIZE are valid when FSR_COMP='Y'.
and the PRCNT is valid when FSR_ZEDC='Y'
Thanks to Michael Friske, FMR, USA.
Change 39.118 UTILCPLG utility will copy the SAS log to a file, when
UTILCPLG MXG executes as a batch job, but the log was not copied
Jun 3, 2021 if there were spaces in the directory names. Wrapping
the names in " resolved the error.
Change 39.117 If the eight byte JOBCLAS8 is populated and the one-byte
BUIL3005 JOBCLASS is blank, MXG moved the first byte of JOBCLAS8
VMAC30 into JOBCLASS. But IBM now sets JOBCLAS8='STC' causing
Jun 1, 2021 MXG to set JOBCLASS='S' when there was no such job class.
Now, the original one-byte JOBCLASS is not changed.
Thanks to Robert Chavez, Florida Power and Light, USA.
====== CHANGES THRU 39.116 ARE IN MXG 39.04 DATED Jun 1, 2021 ========
Change 39.116 Support for z/OS 2.5 SMF Manual Changes are all included
May 28, 2021 in MXG 39.04 and there were no INCOMPATIBLE changes.
Change 39.115 If USEBANDS=YES, an annoying note that STAGGERTHIN was
GRAFCEC not valid and THIN was used. STAGGERTHIN was removed.
May 25, 2021
Change 39.114 An INVALID IMAC6ESS GEPARMKY 0027x caused message that
IMAC6ESS the segment was invalid, but the reporting site does not
May 24 2021 use those TYPE6 ESS variables and was unwilling to pursue
with IBM Support. New message ask for you to contact MXG
Support.
Change 39.113 TYPE6 variable SMF6URI is added to the PDB.PRINT
BUILD005 dataset.
BUIL3005
May 21 2021
Thanks to Ervin Claxon, CSX, USA.
Change 39.112 Formats $MGIBMPR and $MGIBMIM add new product name
FORMATS 5655-TM4. These formats are used in SCRT in TYPE89 and
May 26, 2021 and caused NO MWP for IMS Workload.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 39.111 If you are moving from zOS to ASCII and had a hard-coded
VMACSMF SMFEXIT=CICS in an IMAC**** member you could get:
May 23, 2021 NOTE 138-205:
Line generated by the macro variable "SMFEXIT".
82249 cics
----
23
ERROR 23-2: Invalid option name CICS.
when reading SMF data. The SMFEXIT only works on z/OS.
-Remove the %LET SMFEXIT=CICS; statement from the IMAC.
-Documentation Only, VMACSMF was not changed.
Change 39.110 Documentation update for SUPPRESS.
UTILBLDP
May 19, 2021
Change 39.109 More Details for SMF Record Selections, Change 39.025.
VMACSMF showed how _SMF and %LET MACFILE can be used for SMF
May 18, 2021 record selection with a CICS Dictionary example, but the
also creates these "PRODUCT" variables that can be used
for selection, You must set %LET MXGDECOMP=DB2; in SYSIN
to decode Compressed DB2 records using _SMF.
DB2: SUBSYSTEM COMPRESSFLAG ACCUMACFLAG DB2IFCID
QWHSRELN
CICS: SMFPSRVR SUBSYSTEM MNSEGCL MCTSSDCN MCTSSDRL
COMPRESSFLAG
30: SUBSYSTEM
RMF: PRODCMF MVSLEVEL PRODVERSION
80: SUBTYPE=RACFEVNT
MQ: SUBSYSTEM SM115REL PRODVERSION
6: SUBSYSTEM
26: SUBSYSTEM
Change 39.108 Support for BVIR Version R5.x, 8.50.x.x:
VMACBVIR -New variables in BVIR30 for BVIRVERS GE 8:
May 24, 2021 TMPTHROT='TEMP*PREMIG*THROTTLE*THRESHOLD'
TMPPRIOR='TEMP*PREMIG*PRIORITY*THRESHOLD'
Eight Byte input for TVCSIZE USDCACHE USDFLASH
-New variables in BVIR302 for BVIRVERS GE 7:
EHSMRECA='DATA*RESIDENT*IN CACHE'
EHSMNOTY='DATA*UNPREMIGRATED'
EHSMAWRE='DATA*AWAITING*REPLICATION'
EHWMSZPK='DATA*TOTAL SIZE*PREFER*KEEP'
EHWMSZPR='DATA*TOTAL SIZE*PREFER*REMOVE'
EHWMSZPV='DATA*TOTAL SIZE*PINNED*VOLUMES'
EHWMSZRV='DATA*TOTAL SIZE*RESIDENT*WAITING'
EHWMSOBI='OBJECTS*IN TVC*ASSIGNED*PREFGROUP'
-New variables in BVIR11 for BVIRVERS GE 7:
ATMDLCQA='AVERAGE*TIME*DELAYED*COPY*QUEUE*AGE'
ATMDTOCA='DATA XFER*TO THIS*CACHE*FROM DS8K'
ATMDTODI='DATA XFERYFROM THIS*CACHE*TO DS8K'
-New EXTENDED GRID CONTAINER awaits data to decode.
-New PARTSIZE/MIGRSIZE array awaits data to decode
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.107 Long ago there was a 32K limit to the size of macro
VMXGSUM variables and VMXGSUM flagged a warning if INCODE
May 14, 2021 exceeded 30000 bytes (spaces count). Now if SAS is V9 or
higher the limit is 65534.
Change 39.106 This error occurs if you have an old VMAC7072 in USERID
VMAC7072 from MXG Versions 36 or 37. You must always remove any:
May 14, 2021 VMACxxxx or VMXGyyyy members from your USERID tailoring
because your old member will prevent the current member
from being used:
NOTE: Line generated by the macro variable "WTY70".
186016 WORK
____
455
ERROR 455-185: Data set was not specified on the DATA statement
Change 39.105 Infile options EOV=BVIREOV and JFCB=BVIRJFCB are added to
VMACBVIR the BVIRHIST infile to permit creation of the variable
May 12, 2021 SYSTEM. Option END=ENDOFINP already exists.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.104 VMXGINIT sets new macro variable %LET MACEXCL=IMACEXCL;
VMAC110 and VMAC110 is now %INCLUDE SOURCLIB(&MACEXCL); so that
VMXGINIT you can have multiple IMACEXCx member names if needed.
May 13, 2021
Change 39.103 Support for more than 4TB of Real Storage. MXG Variable
VMAC0 REALSIZE (SMF0RST) 1K Blocks is only valid up to 4T-1 and
May 11, 2021 new variable SMF0RS4K counts 4K blocks online at IPL.
z/OS 2.5 plans to allow up to 16 Terabytes of memory.
Change 39.102 Support for z/OS Connect EE SMF 123 Subtype 2 record adds
VMAC123A new variable SM123S2_TRACKING_TOKEN in dataset TYPE1232.
May 11, 2021
Change 39.101 Unused Change Number.
May 11, 2021
Change 39.100 -New ASMRMFV Field Data Filter (FDF) support for the RMF
ADOCRMFV III Cryptographic Hardware Data Table (CRYG3}.
ASMRMFV -The Field Data Filter (FDF) feature of RMF III was added
VMACRMFV in MXG Change 37.089 and supports filtering of raw or MXG
May 11, 2021 derived RMF data values when ASMRMFV reads the RMF III
VSAM file, reducing the size of the created RMFBSAM file
and the result MXG PDB.
-RMF III table entries can be filtered by FDF based on one
or more numeric/character/bit fields using AND/OR logic.
FDF is intended for advanced MXG users building ad hoc
PDBs of RMF III data for studies and investigations.
-The minimum hardware level required to run ASMRMFV is
raised from a z9 to a z10 machine. IBM end of support
for the z10 was December 2019. This allows ASMRMFV to
use more efficient and fewer machine instructions.
-MXG can provide an archival stabilized ASMRMFV level for
continuing z9 users if needed. This level does NOT have
FDF CRYG3 support and will NOT be further enhanced.
-ADOCRMFV now contains ASMRMFV support status information
for all IBM processor families.
-Improved Table Error Diagnostics (ITED) are added for all
supported RMF III tables. When an RMF III table error
is detected (which should be rare) instead of only
counting the table skip, a dynamically tailored RMFV092E
message will also be issued with further details.
Return Code 0008 will result for RMF III table errors
rather than Return Code 0004 as previously. These merit
contact with MXG Technical Support to resolve the
problem.
-There is an internal ASMRMFV limit of 10 RMFV092E
messages for each RMF III VSAM data set processed. If
reached new message RMV093I is issued and further
RMFV092E messages are suppressed for that data set.
-When AUTOSEL (default) is in effect ASMRMFV now shows the
field name that trigged that automatic RMF III table
selection in message RMFV082I.
Example:
RMFV002I SYSIN : IF=(ASIJOBNA EQ 'MXGJU')
RMFV082I -->NOTE : RMF III ASI TABLE AUTO SELECTED BY
ASIJOBNA <--
-When AUTOSEL (default) in in effect use of any of the
following additional ASMRMFV parameters (and their
respective aliases) will now cause the corresponding RMF
III table to be selected without having to also
explicitly code the corresponding table selection:
Parameter Auto Selects
--------- ---------------
ASIAND ASIG3
ASIOR ASIG3
CSRAND CSRG3
CSROR CSRG3
DVTAND DVTG3
DVTOR DVTG3
OPDAND OPDG3
OPDOR OPDG3
SPGAND SPGG3
SPGOR SPGG3
DEVTYPE= DVTG3
CPCSYSTEM= CPCDB CPUG3
CPUSYSTEM= CPUG3 CPCDB
-Data Dictionaries in the ADOCRMFV member have been
updated or added for these FDF supported RMF III tables:
ASIG3 CFIG3 CRYG3 GEIG3.
-Many tables and charts in ADOCRMFV have been converted to
boxed figures for improved legibility.
-Following Sections are updated or added in the ADOCRMFV
documentation member:
Section Contents
------- --------
0 Contents
2 Terminology
3 Execution JCL
4 RMF III Table Selection Parameters
5 Input Data Selection Parameters
8 Error Handling Parameters
9 JCL and SYSIN Parameter Usage
12 Messages
13 Filtered Records
32 Data Dictionary Descriptions
33 Filtering The ASIG3 Table
34 Filtering The CFIG3 Table
39 Filtering The CRYG3 Table
40 Filtering The GEIG3 Table
53 ASMRMFV Execution and Methods Overview
54 PDB Build Examples With Direct JCL Method
55 PDB Build Examples With TSO Clist Method
56 PDB Build Examples With Dynamic Method
57 Summary
58 Bibliography
-Variable LCPUHWLW='HDW*GROUP*CAPACITY*LIMIT' in ZRBLCP
dataset was misspelled as LCPUHWCA in the INPUT.
-Dataset ZRBCPU variable CPCVALAVL added and CPCABSMSU
is correctly labeled:
CPCABSMSU='ABSMSU*CAPPING*OPTION*SET?'
CPCVALAVL='CAPACITY*VALUES*AVAILABLE?'
-The 96 CPUSTAnn variables in dataset ZRBCPU have been
reserved since z/OS 1.2. They are removed.
Change 39.099 Support for DB2 Netezza/IDAA Accelerator new data fields,
VMACDB2 and correction to DB2 GMT Offset calculation . DB2 does
VMACDB2H not provide a GMT Offset, forcing MXG to use the delta
VMACSMF between SMFTIME-TODSTAMP with fuzzy logic, because SMF is
May 23, 2021 in hundredths while TODSTAMPs are in microseconds, but
MXG logic did NOT account for the 26 leap seconds that
are in all TODSTAMPs, but not in SMFTIMEs, that made the
converted local time 26 seconds later than actual. Now,
the 26 seconds are subtracted from QWHSSTCK before the
GMT corrected calculation and QWHSSTCK is correctly
converted to local time zone to match SMF, and the
GMT Offset is now integer hours.
-Leap Seconds are periodically added (6 since 1997) and
when the next one is scheduled, I'll use the date to
subtract the 27th.
-I've discovered both TODSTAMP and MSEC variables can show
8 decimal digits, with DATATIME28.8 or TIME20.8 formats,
but SAS Support says both only have 6 decimals are valid.
-Protection for invalid offset added in VMACSMF.
Thanks to Marc Di Edwardo, Memorial Sloan Kettering, USA.
Change 39.098 With PDB=SMF the display of VMXGRMFI options was
VMXGRMFI suppressed.
May 11, 2021 -If you specified imacwork=no in lower case it
was not recognized and you could get the out of
balance message. Now IMACWORK USECNTRL USEREPRT
are upcased before any compares are made.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 39.097 New parameter NOTALLLPARS=NO defaults to running the PROC
VMXG70PR FREQ that tells you which LPARs are missing from the PDB.
May 7, 2021 Specifying NOTALLLPARS=YES suppresses these messages for
when you don't have the RMF data from all LPAR's.
Change 39.096 New variable SMF89SOLUTIONID, the SOLUT= system parameter
VMAC89 is added to datasets TYPE89 and TYPE892. This is the
May 6, 2021 Tailored Fit Pricing Solution ID.
Change 39.095 Typos in comments. For CMODIDNT='393' DEC=394 corrected
UTILEXCL to DEC=393, and WBURIRND corrected to WBURIRCV.
May 6, 2021
Thanks to Charles Piggott, RUV, GERMANY.
Change 39.094 Debugging macro variable DCOLEXIT is defined in VMXGINIT
VMACDCOL and &DCOLEXIT is added to the INFILE so that you can use
VMXGINIT %LET DCOLEXIT=FIRSTOBS=250 OBS=300;
May 5, 2021 to control what records are read. If you instead used
OPTIONS FIRSTOBS=250 OBS=300;
the DATA step will correctly read those selected records,
but the following SORTs and STEPs will fail because they
FIRSTOBS=1 OBS=MAX.
Change 39.093 -DCOLLECT DAILYDSN/VMXGDSN creation of DATASETS.DATASETS
VMXGDSN has been wrong since Change 37.065 in MXG 37.03. In the
May 5, 2021 creation of DATASETS, the original code output the pair
of DATA/INDX obs from DCOLDSET for VSAM files, setting
SPACE1=DCDALLSP (Allocated Space) for each obs.
-That change replaced that pair of obs with one obs from
DCOLCLUS, DSNAME=Cluster Name and with SPACE1=DCAHARBA
as the size of each VSAM cluster, But the total DASD
space is significantly smaller after that change.
-This change follows IBM recommendation to use DCAHARBC,
instead of DCAHARBA and to continue to discard the VSAM
DATA/INDX space from DCOLDSET.
-After this change, the obs count in DATASETS is smaller,
and the VSAM sizes increased to pre-37.065 change.
DASD Space is DCDALLSP - VSAM-DCDALLSP + DCAHARBC
-See also Change 15.108.
Thanks to Terry Chao, Office of Chief Technology Officer, USA.
====== CHANGES THRU 39.092 ARE IN MXG 39.03 DATED May 3, 2021 ========
Change 39.092 Some ANALDB2R reports attempt to map database and object
VFMT102 names using this format but if there were no subtype 105
Apr 29, 2021 records the format could could not be built and a format
not found error could result. Now tells you there was no
data and sets NOFMTERR.
Change 39.091 Support for new variables DB2 IFCID 402 T102S402 dataset:
VMAC102 QW0402OW ='IDLE*THREAD*THRESHOLD*EXCEEDED'
May 2, 2021 QW0402TC ='CURRENT*ACTIVE*THREAD*COUNTER'
QW0402TS ='CURRENT SUSPENDED THREAD COUNTER.
QW0402TH ='HWM*THREAD*COUNTER*SINCE*DDF START'
QW0402CC ='CURRENT*CONNECTIONS*COUNTER'
QW0402CH ='HWM*CONNECTIONS*COUNTER*SINCE START'
QW0402TN1_OFF ='OFFSET*TO FIRST*TOKEN*VALUE'
QW0402TN2_OFF ='OFFSET*TO SECOND*TOKEN*VALUE'
QW0402TN1_LEN ='LENGTH OF FIRST*TOKEN FIELD'
QW0402TN1_VAR ='FIRST*TOKEN*VALUE'
QW0402TN2_LEN ='LENGTH OF*SECOND*TOKEN*FIELD'
QW0402TN2_VAR ='SECOND*TOKEN*VALUE'
-QWHCEUTX='END*USER*TRANSACTION*NAME was added _V102CMN
so it will be kept in ALL T102Snnn Trace Datasets.
Thanks to Manoel DeSouza, FMR, USA.
Thanks to Jonathan D. Brown, FMR, USA
Change 39.090 Support for RACF Pass Ticket Evaluation (8081 PTEVAL)
EXTY8081 creates new TYPE8081 dataset.
FORMATS
IMAC80A
VMAC80A
VMXGINIT
Apr 28, 2021
Thanks to Jim Guzlecki, REFINITIV, USA.
Change 39.089 Velocity XAM storage variables are in pages, but were not
VMACXAM converted to bytes nor formatted with the MGBYTES format.
Apr 27, 2021 These are now internally in bytes, MGBYTES formatted:
RSASTORE SYSTORS SYSVRSZ SYSVRFRE SYSTRCPC
HCPMM1S HCPMM4S RSAPGABL RSANONPG RSAOFFLN
RSARIOSZ CALSCMAX SYSSCMEX RSAGSTOR RSAGOFFL
RSALGFRM SXSSIZE PFXSTLEN PFXFTLEN RSAFNOTI
FIXEDSTO SYSGSTBY SYSGSTRS RSACKMB2G RSACKMA2G
RSAPIN0B RSAPIN0A RSAPIN1B RSAPIN1A RSAPINWP
RSAPINFP
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 39.088 Report to Count Character Variables with FREQ=FREQ did
ANALJOBN not print anything because there was no TABLES statement,
Apr 27, 2021 causing VMXGPRAL to fail, exposing Change 39.087.
Change 39.087 If there were no variables not in the BYLIST a syntax
VMXGPRAL error occurred pointing at /MISSING.
Apr 27, 2021
Thanks to Rahul Raj, ENSONO, USA.
Change 39.086 Support for HSM UNIX CLOUD Statistics variables added to
FORMATS HSMFSRST dataset for FSRTYPE 25 and 26.
VMACHSM FSRUNIXF='UNIX*SEGMENT*PRESENT?'
Apr 29, 2021 FSRTYPE ='FSR*FUNCTION*TYPE'
FSRCLNML='CLOUD*CONNECTION*NAME*LENGTH'
FSRCLNR ='CLOUD*NETWORK*CONNECTION*NAME'
FSRCLCNT='DFHSMHSM*CONTAINER*NAME*USED'
FSRCLOBN='OBJECTS*CREATED'
FSRPFXNM='PREFIX*OF*OBJECT'
FSR2_UNML/*UNIX*FILENAME*LENGTH'
FSR2_FLGS/*UNIX*FILENAME*FLAGS'
FSR2_UNAM/*UNIX*FILENAME'
FSRFMB ='FSRBYTR*AND*FSRBYTW*WERE IN*MB?'
FSRFXPLC='EXPIRED*FROM*CLOUD?'
-HSM Variable FSRTYPE has additional values that are now
decoded by format MGMSMFU:
24='24:CLASS TRANSITION'
25='25:MIGRATION TO CLOUD'
26='26:RECALL FROM CLOUD'
-Records with FSRTYPE=24 are not output until test data
is available to validate it's contents.
Thanks to Macarena Alonso Alvar, Silk Aplicaciones SLU, SPAIN.
Change 39.085 PDB.ASUMUOW variable TRANNAME should have LENGTH $4 but
VMXGUOW contained only 1 character if MQ data records preceded
Apr 24, 2021 the other records, and SPIN.SPINUOW had observation(s).
Thanks to John Holiday, Queensland Government, AUSTRALIA
Change 39.084 We all know that IO delays can be a problem but we may
TECHNOTE not consider terminal delays to be part of the problem.
Apr 23, 2021 Now that everyone is working from home running SAS in
the foreground (interactive) can be profoundly affected.
Working with a customer on a Linux install we noticed
that SAS initialization took over 1 minute for 1 user
but only 45 seconds for another and locally on my PC a
couple of seconds. Running BUILDPDB against a 6GB SMF
dataset in the foreground took 13 minutes but running
in the background (a batch job) the same program and
the same SMF data ran in 90 seconds. The moral of the
story is IO still matters and LOGS and OUTPUTs back
to your online session are IO and matter.
Change 39.083 Format $MGSMFID did not describe SMF 83 Subtype 7, MFA,
FORMATS Multi-Factor Authentication
Apr 23, 2021
Thanks to MP Welch, Bank of America, USA.
Change 39.082 Variable QDSTNCQC was misspelled as QDSTNQWC.
VMACDB2
Apr 23, 2021
Thanks to R. Indumathy, FMR, USA.
Change 39.081 A few non-impacting %PUT "DEBUG" messages were replaced
READDB2 with a conditional test that &MXGDEBUG was enabled.
Apr 21, 2021
Change 39.080 ANALDB2R could fail if PMAUD02 report was requested and
ANALDB2R there were no observations, due to misplaced GOTO.
Apr 20, 2021
Change 39.079 Support for RMF III CRYG3 Cryptographic Hardware Table
EXZRBCRY creates new dataset ZRBCRY.
FORMATS
IMACRMFV
VMACRMFV
VMXGINIT
Apr 28, 2021
Thanks to MP Welch, Bank of America, USA.
Change 39.078 -MXG 39.02. ERRORs EXCLUDED FIELDS - SECOND RECORD error
UTILEXCL using the IMACEXCL created by UTILEXCL; there was a typo
IMACICCU $CHAR54 instead of $CHAR64 that caused misalignment.
Apr 15, 2021 -The %INCLUDE inside IMACICCU should be IMACICCD.
Thanks to Negri Gianvittorio, SAS, ITALY
Thanks to Mark Wittie, FMR, USA.
Thanks to Kelly Ballamis, Zions Bank, USA.
Change 39.077 Changes in TYPE70 processing caused PDB=SMF to fail.
VMXGRMFI Logic to read the RMF SMF data needed for RMFINTRV was
Apr 15, 2021 replaced with a %UTILBLDP invocation.
Thanks to Michael Friske, FMR, USA.
Change 39.076 Support for Phoenix JES3plus SMF 84 error correction that
VMACSMF was reported in APAR OA58963 but not corrected by IBM.
VMAC84 The 84 subtype was not in 19-20 so IBM SMF utilities
Apr 15, 2021 could not use SUBTYPE for record selection, The APAR was
closed as a permanent restriction for JES3, but JES2 will
write a new record with ID=126 and four-digit ID=1153
that has subtype in the expected location. For JES3,
JES3plus relocates the subtype to expected location.
This MXG update correctly inputs the SUBTYPE in the
_SMF header macro for all possibilities.
Change 39.075 Updates from SMF Manual dated Apr 5, 2021.
VMAC42 -TYPE42DS New variable: (APAR OA59611)
Apr 12, 2021 S42SNTWJ='SYNC ZHL*WRITES*DISABLED*NEW LAYER'
-TYPE106 New Datasets
TY1063 TYPE1063 BCP ST-1 HWIREST API
TY1064 TYPE1064 BCP ST-2 HWIREST API
Change 39.074 RMF III z/OS 2.4 Updates from Feb 2021 Programmer Guide:
VMACRMFV -Dataset ZRBLCP new variables:
Apr 11, 2021 CPC_BOOSTACTIVE='BOOST*ACTIVE*INTERVAL'
CPC_BOOSTCLASS ='BOOST*CLASS'
-Dataset ZRBCFI new variables
CFISTSC1='INDEX OF*FIRST CFICONNS'
CFISTMRC='NUMBER OF*CFICONNS*ENTRIES'
CFISTMTM='SUMMED*QUEUE*TIME'
-Dataset ZRBASI new variables
ASIORMP ='STORE/OUTR*DELAY*SAMPLES*SR7'
ASIRUCSAA ='RUCSA*ALLOCATION'
ASIERUCSAA ='ERUCSA*ALLOCATION'
-Dataset ZRBGEI new variables
GEIGLUSE='1GB FRAMES*IN USE*MEM OBJECTS'
GEIGLTOT='1GB FRAMES*IN CENTRAL*STORAGE'
Thanks to MP Welch, Bank of America, USA.
Change 39.073 Format $MGMARET for TYPEMAR printed 3990 instead of 3390.
FORMATS
Apr 12, 2021
Thanks to Lloyd Christensen, Hitachi Vantara, USA.
Change 39.072 ZIPOVHTM and PCTZIPOV variables added to ASUMCELP ASUMCEC
VMXG70PR ASUM70PR and ASUM70LP datasets.
Apr 13, 2021
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 39.071 RMF III percentages on System Information and CPC Summary
VMACRMFV reports are identified/revised/created:
Apr 8, 2021 -Dataset ZRBCPU.
These variables are on RMF System Information report.
PCTCPUBY='AVG CPU*PHYSICAL*PERCENT*BUSY';
PCTLOGBY='AVG CPU*LOGICAL*PERCENT*BUSY';
PCTLOGBY/CPUG3_LOGITI. MVS view of logical processor
utilization based on wait time for the processor.
This is "Avg CPU UTIL%" on System Information report.
PCTCPUBY/CPUG3_PHYSTI PR/SM view of physical processor
utilization based on dispatch times.
This is "Avg MVS UTIL%" on System Information report.
-Dataset ZRBLCPLPARS new variables; you must use TYPSRMFV
or invoke _SRMFV to create dataset PDB.ZRBLCPLPARS.
These variables are on the CPC Summary report;
CPUPCTEF='PHYSICAL*EFFECTIVE*PERCENT*BUSY'
CPUPCTBY='PHYSICAL*TOTAL*PERCENT*BUSY'
LOGPCTEF='LOGICAL*EFFECTIVE*PERCENT*BUSY'
LOGPCTBY='LOGICAL*TOTAL*PERCENT*BUSY'
and ZRBLCPLPARS has an observation for each CPU TYPE.
Thanks to Ervin Claxon, CSX, USA.
Change 39.070 Support for DB2 APAR PH31684, SORT usage counters in
IMACDBNZ three datasets, sort sizes for zSORT in IFCID=96, and
VMAC102 these two new NETEZZA variables in DB2ACCT;
VMACDB2 Q8ACTWDP='TIME*WAITED*FOR DELAY*PROTOCOL'
Apr 6, 2021 Q8ACNWDP='STATEMENTS*WITH*EXPIRED*PROTOCOL'
New variables added to DB2STAT1 DB2STATS DB2ACCT
QXSTSRT ='TIMES*RDS SORT*PERFORMED'
QXSTSRTL='TIMES*RDS SORT*USED SORTL'
QXSTMLSRT='TIMES*SORT*FEEDBACK*USED'
QXSTMLSDFND='PREPARE*STABILIZED'
New variables added to T102S096 for IFCID=96:
QW0096RU='QW0096RU*SERVICEABILITY'
QW0096PN_OFF='OFFSET TO PROGRAM NAME'
QW0096PC_OFF='OFFSET TO PACKAGE COLLECTION ID'
QW0096DZ='SORT*DATA AREA*SIZE WITH*SORTL'
QW0096KZ='SORT KEY*SIZE WITH*SORTL'
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 39.069 Some XAMSYS variables were in the KEEP= list for XAMUSR
VMACXAM but they should have been kept in XAMSYT.
Apr 5, 2021
Change 39.068 -Some users have found savings of time using COMPRESS=NO
VMXGALOC as datasets in work have to be repeatedly compressed and
Apr 5, 2021 decompressed. A parameter was added to allow the PDBs
Apr 9, 2021 being created to be compressed while leaving work at the
value specified in your AUTOEXEC. COMPRESS=YES is now the
default value added to every LIBNAME statement issued by
VMXGALOC. Specify COMPRESS=blank or anything other than
YES to disable.
-On Linux only, if you did not specify a BASEYEAR you
could get a SUBSTR OUT OF RANGE error.
Thanks to Arnold Kim, UPS, USA.
Change 39.067 New value '20X:REMOUNT' added to $MG092FM format for
FORMATS variable SMF92MFG in dataset TYPE9201 and SMF92UFG in the
Apr 5, 2021 dataset TYPE9205. ICN 1830.
====== CHANGES THRU 39.066 ARE IN MXG 39.02 DATED Apr 4, 2021 ========
Change 39.066 New parameter USEBANDS= added with a default of NO, will
GRAFCEC creates 'band' charts rather than bar charts.
Apr 4, 2021
Change 39.065 Change 39.029 incorrectly coded PROC FORMAT for the
GRAFWRKX formats $TMPSUEC and $TMPNRCPI that set SU/Sec and NRCPU.
Apr 4, 2021
Change 39.064 The Apr 1 Change 39.060 for HLASM back level protection
ASMRMFV was revised. USE ONLY ASMRMFV DATED APR 2 IN LINE2.
Apr 2, 2021
Thanks to Otto Burgess, OPM.GOV, USA.
Thanks to Robert Richards, OPM.GOV, USA.
====== CHANGES THRU 39.063 ARE IN MXG 39.02 DATED Apr 1, 2021 ========
Change 39.063 Dataset IMS56FA variable DLRDMR is now kept, DLRSMR typo.
VMACIMS
Apr 1, 2021
Thanks to Nick Varley, Precisely, ENGLAND.
Change 39.062 JCL and source to run BUILPDB creating the PDB on a tape
JCLTAPDB and at the same time sending CICSTRAN to tape and all of
BLDTAPDB the DB2 accounting datasets to a third tape dataset.
Mar 31, 2021
Change 39.061 Change 37.260 added JOB_IDENTIFIER but MXG did not change
VMACIDMS the +50 to +42 to preserve alignment.
Mar 30, 2021
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.060 Some versions of the HLASM Assembly program fail on the
ASMRMFV ISHEX function, with error message ASMA089E when the
Apr 2, 2021 function appears in a macro definition. Single character
parsing is now used to validate hex characters.
UI73993 Feb 17, 2021 works, UI60352 Dec 19, 2018) failed.
Thanks to Otto Burgess, OPM, USA.
Thanks to
Change 39.059 The GMT Offset in CVTTRZ in TYPE0 was off by one second;
VMAC0 the CEIL and FLOOR functions were reversed.
Mar 30, 2021
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 39.058 Second period for DATA=&PDBMXG..STEPS was missing.
ANALABND
Mar 28, 2021
Change 39.057 INPUT EXCEEDED for defective SMF 16 record with ZSORT
VMAC16 triplet populated, but no ZSORT data, APAR PH32395:
Apr 1, 2021 UI90068 WHEN ZSORT=Y IS IN EFFECT. ERROR DESCRIPTION:
The ZSORT feature does not support SORTs that are program
invoked and using E15 and/or E35 EXITS for input and
output. In this case ZSORT needs to be disabled and use
the traditional sorting techniques, otherwise program
failures like ABEND0C4 may occur. This APAR will improve
this check. One site's data populated ICEFLBY5='Y' that
ZFSORT was invoked, but the offset pointed to the end
of the record where there was no data. A second site
had ten-digit decimal offsets in the ZSORT triplet but
ICEFLBY5 was not y.
-The BroadCom CA-7 SASSHISS program ABENDED with 0C4 as
noted in this document:
https://knowledge.broadcom.com/external/article/209582/
sasshis5-c0c4-abend-was-issued.html
Thanks to Rob D'Andrea, NATWEST. SCOTLAND.
Change 39.056 New parameters WEEKINCODE= MNTHINCODE= let you insert
BLDSMPDB code just after the SET statements for weekly and monthly
Mar 28, 2021 processing. An example was added to the comments using
WEEKINCODE to validate the data using ZDATE and to
determine using RMFINTRV if data is not complete (less
than 24 hours in a day) or outside the bounds of the
week. Will issue a WARNING message if problems are found,
print a report of what was found for each day of the
week, and optionally can set cc=4;
Thanks to Denise Willers, ENSONO, USA.
Change 39.055 AUDITAFTER= default value changed to YES. This means that
UTILBLDP PDBAUDIT will run after everything in your INCLAFTR
Mar 28, 2021 parameter rather than after BUILDPDB. The first time you
run you will see a lot of new datasets that are not
really new but were created by MXGINCL and INCLAFTR
members after BUILDPDB ran.
Change 39.054 Variable LOSTRECS/SMF7NROX was conditionally input but
VMAC7 the field is always present, and subsequent variables
Mar 26, 2021 (SMF7LSN,SMF7TBLS) were not input.
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 39.053 The CICSTRAN data for z/OS EE Connect Adapter and for MQ
VMAC110 related tasks create variables OADATA1/OADATA2/OADATA3
Mar 31, 2021 with these different values:
For MQ Related Task
OADATA1=QMGR=MSQ1
OADATA2=INITQ=CICSS001.INITQ
OADATA3=QNAME=MQS1.MQIN.TEST.REPORT
OADID =ID=IBM WebSphere MQ for z/OS V9
For z/OS Connect Related Task
OADATA1 BAQvllPLXTNKX A580 TODSTAMP.
The v field contains 01x= a version number?,
the ll field contains length of data following,
PLXTNKX is the SYSPLEX and A580 is the SYSTEM and
the TODSTAMP (converted with MCTMNTAD to LOCAL)
is always earlier than the SMF time.
But those binary values in the z/OS Connect OADATA1
cause problems if you try to move the data to EXCEL.
So the z/OS Connect record is decoded and the datetime
is now a text field:
OADATA1='BAQ PLXTNKX A580 15MAR2021:11:10:54.217948.
Thanks to Simon Foley, CPT Global, AUSTRALIA.
Thanks to Martyn Jones, CPT Global, ENGLAND.
Change 39.052 TABULATEs consolidated so that for each category you get
ANALINIT one page rather than a page per jobclass. Formats added
Mar 26, 2021 to PROC PRINTs.
Change 39.051 JCLSPGDG example creates GDGs for all MXG "PDB" datasets.
JCLSPGDG The limit for the number of generations in a GDG was 255,
Mar 21, 2021 but in z/OS 2.2, the new EXTENDED option allows up to 999
generations. So you can start a Daily PDB with GDG=1 on
Jan 1, with a limit of 366 and have the GDG number
match the julian date!
Thanks to MP Welch, Bank of America, USA.
Change 39.050 Error Messages from PROC PLOT for all values missing were
JCLPDB94 caused by incorrect OR/AND logic. JCL94PDB now executes
ANALRMFI with CC=0.
ANALMPL
Mar 20, 2021
Thanks to MP Welch, Bank of America, USA.
Change 39.049 Format $MGSMFID describes SMF record type and subtype for
FORMATS ANALID reports; the format was missing 116.010.
Mar 18, 2021
Thanks to MP Welch, Bank of America, USA.
Change 39.048 The example PDS allocation for MXG.SOURLIB had only 1199
JCLINSTT directory blocks. Without PDS Statistics, 459 blocks are
JCLINSTL used, with PDS statistics, 1607 are needed so examples
Mar 17, 2021 now allocate 1999 blocks so you can have statistics.
Thanks to Jerry Terpstra, Bank of Montreal, CANADA.
Change 39.047 If you tried to run without running _SUOWSPN you got
VMXGUOW errors with SPUNCNT undefined and if you set _LASCICS
ASUMUOW to CICSTRAN.CICSTRAN and bypassed _SUOWCIC you got an
Mar 17, 2021 undefined macro reference. Both problems are fixed.
_SUOWSPN is not needed since the data has to be in the
correct order when it is created. It is commented out
in both the examples and the executable code. It will
not hurt to run it but it will save some time to skip
this sort.
Change 39.046 If you asked for 106 records and did not add T102106=YES
READDB2 the T102S106 dataset was not created. Now if 106 is in
Mar 14, 2021 the IFCIDS and T102106 NE NO it will be built and sorted
into the PDBOUT= LIBNAME.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.045 If all values to be charted were missing, a blank page
GRAFWRKX was created and if all were 0 a meaningless chart of a
Mar 13, 2021 flat line at 0 on the Y-axis was created. Now charts only
values GT 0.
Change 39.044 Since the second part of the WORKX= was set to SRVCLASS,
UTILWORK which is then used as the label for variables created by
Mar 14, 2021 VMXGRMFI, unless you wrote the WLM policy SRVCLASS may
not be sufficient to identify what the workload
represents. Now, UTILWORK uses the first 20 bytes of the
service class description, except when the service class
is SYSTEM SYSSTC or SYSOTHER.
Change 39.043 Support for z/OS Connect SMF 123 Subtype 2 record creates
ANAL123A New Data Set:
EXTY123C DDDDDD DATASET DESCRIPTION
IMAC123A TY123C TYPE123C z/OS CONNECT API REQUEST
VMAC123A Member ANAL123A will merge the TYPE123C REQUEST dataset
VMXGINIT observation with the corresponding CICSTRAN obs to create
Mar 23, 2021 dataset PDB.CICS123.
Change 39.042 CICS optional CMODHEAD=USER AND CMODNAME=USER incorrectly
IMACICXA pointed to IMACICDU but that should be IMACICXA.
UTILEXCL
Mar 10, 2021
Thanks to Mark Wittie, FMR, USA.
Change 39.041 -If you want to change the destination library to other
ASUM70PR than PDB, VMXG70PR failed with error messages that your
VMXG70PR TYPE70 and TYPE70PR datasets were not found. Now, it
Mar 24, 2021 uses VMXGWORL to try to find it, or if you specify
PDB=yourdd, that will be used.
-If you specified PDB=PDB and the datasets did not exist
a dataset not found error resulted. PDB=libname always
overrides the results of VMXGWORL.
Change 39.040 Defective SMF 1415 records with NUCB=6 but only 5 UCBs
VMAC1415 have invalid SMF14STY values due to that misalignment,
Mar 9, 2021 causing blank values for STEPNAME PROGRAM JCTJOBID and
JESNR is a missing value. All of these records are for
DSNAME='SYS1.HASPACE' and new SMFSTY14='1234567890' is
created to list the subtypes in each record; the value
0 at the end are those with invalid subtypes.
A CASE/PMR is in progress with IBM to correct.
Change 39.039 -The Field Data Filter (FDF) feature of RMF III was added
ASMRMFV in MXG Change 37.089 and allows you to filter raw RMF
ADOCRMFV data values when ASMRMFV reads the RMF III VSAM file,
Mar 8, 2021 reducing the size of the created RMFBSAM file and the
result PDB.
-You can filter RMF III table entries based on one or more
numeric, character, or bit string fields using AND/OR
logic. This feature is intended for advanced MXG users
building ad hoc data PDBs of RMF III data.
-ASMRMFV now supports some MXG Derived Variables from bit
string settings. This relieves some of the cumbersome
lookup and error prone use of bit strings in FDF IF
expressions. Not all bit settings are assigned to a PDB
variable when an MXG PDB build is run. ASMRMFV mimics the
derivation that occurs during the build.
-Bit string MXG Derived Variables are added for RMF III
tables: ASIG3, CATG3, DVTG3, ENCG3, GEIG3, SCMG3, SPGG3.
Other tables supported by FDF do not have bit string
related variables.
-Example: Select Address Spaces using the CPU Protection
bit from the ASIG3 table:
Rather than code the IF bit string expression:
IF=(ASIMSTS EQ B'..1.....')
Now this user friendly alternative is possible:
IF=(ASICPUPR EQ 'Y')
-Data Dictionaries have been updated for all 17 FDF
supported RMF III tables. Derived Variable support is
available where the characters "MASK" appear in a Data
Dictionary entry.
-Many Data Dictionary entries now include one or two NOTEs
to add further information about a Fieldname.
-DEV is now valid as a prefix for some Fieldnames for the
RMF III DVTG3 table. This shortens some long Fieldnames
that formerly all required a DVT prefix.
-Error message RMFV092S is now issued with an error code
should a rare table validation error occur for either the
CATG3 table or SMF 74.5 record within the CATG3 table.
-New Section 32 Data Dictionary Descriptions is added to
the ADOCRMFV member. This provides a central reference
location for this information rather than repeating it
for every FDF supported RMF III table.
-New Section 34 Filtering The Cache Data Information Table
(CATG3) is added to the ADOCRMFV member for the new
support.
-TIP:
When filtering with FDF on the first n characters of a
character field there are two ways to accomplish this
as shown in the examples below:
1) Use a pattern match (* in compare value string)
IF=(ASIJOBNA EQ 'PROD*')
2) Use a shortened compare length (: after operator)
IF=(ASIJOBNA EQ: 'PROD')
Either method will select jobs starting with 'PROD' for
output to the RMFBSAM file.
However, the SECOND method is MUCH MORE efficient.
With Method 1 ASMRMFV must call the internal MATCH
subroutine for EVERY job to evaluate the pattern. With
Method 2 ASMRMFV sets the compare length ONCE (in this
case to a value of 4) for all job name comparisons.
TUTORIAL:
MXG Derived Variable ASICX for the RMF III ASIG3 table
can be useful with ASMRMFV for data selection by Address
Space Type when building a filtered PDB.
Possible ASICX values are:
A ASCH Task AO ASCH Task OMVS Related
B Batch Job BO Batch Job OMVS Related
S Started Task SO Started Task OMVS Related
T TSO User TO TSO User OMVS Related
O OMVS Task
To select Started Tasks only use:
IF=(ASICX EQ 'S') or IF=(ASICX = 'S')
To select OMVS related Started Tasks only use:
IF=(ASICX EQ 'SO') or IF=(ASICX = 'SO')
To select all Started Tasks use:
IF=(ASICX EQ: 'S') or IF=(ASICX =: 'S')
Note that 2 IF expressions are NOT needed.
To select all Started Tasks and all Batch Jobs use:
IF=(ASICX EQ: 'S') or IF=(ASICX =: 'S')
IF=(ASICX EQ: 'B') or IF=(ASICX =: 'B')
Note in this case 2 IF expressions are needed.
-Following Sections are updated or added in the ADOCRMFV
documentation member:
Section Contents
------- --------
0 Contents
2 Terminology
12 Messages
13 Filtered Records
31 Field Data Filtering (FDF)
32 Data Dictionary Descriptions
33 Filtering The ASIG3 Table
34 Filtering The CATG3 Table
35 Filtering The CFIG3 Table
36 Filtering The CPDG3 Table
37 Filtering The CSRG3 Table
38 Filtering The DSIG3 Table
39 Filtering The DVTG3 Table
40 Filtering The ENCG3 Table
41 Filtering The ENTG3 Table
42 Filtering The GEIG3 Table
43 Filtering The OPDG3 Table
44 Filtering The PCIG3 Table
45 Filtering The SCMG3 Table
46 Filtering The SPGG3 Table
47 Filtering The SSHG3 Table
48 Filtering The XCFG3 Table
49 Filtering The ZFXG3 Table
51 PDB Build Examples With Direct JCL Method
52 PDB Build Examples With TSO Clist Method
53 PDB Build Examples With Dynamic Method
54 Summary
55 Bibliography
Change 39.038 Dataset TYPE74CA variable CSSCLN wasn't kept, variable
VMAC74 CSSCOPYST was not INPUT nor kept.
Mar 6, 2021
Change 39.037 Many variables containing percentages were not formatted
VMAC30 with 5.1.
VMAC7072
VMAC74
Mar 2, 2021
Change 39.036 APAR PH35442 corrects Negative CPU time in WebSphere SMF
VMAC120 120 TYP120BL dataset. There were many SMF 120 Subtype 11
Feb 28, 2021 records that had ZERO values for the GMT OFFSET
(SM120BBT), for the TOTAL CPU CLOCK AT REQUEST END
(SM120BCA1), for the CP ONLY CPU CLOCK AT REQUEST END
(SAM1230BCA2), and these zero values cause negative
values in the calculated delta start-to-end times.
Variables SM120BCPUTM SM120BCPCPUTM SM120BZIPCPU were
wrong. Note also that because the GMT OFFSET is 0 in
these records, while the other non-zero records actual
GMT OFFSET is 1, these zero records have their END
DATETIME (SM120BBX) one hour earlier than the SMFTIME!
Change 39.035 Variables ASICR and ASICX were not kept in ZRBASI.
VMACRMFV
Feb 28, 2021
Change 39.034 The LABELs for the pair of SINCE CREATION and SINCE OPEN
VMAC64 variables were reversed; the ACCxxxxx are SINCE CREATION.
Feb 24, 2021
Thanks to Jorge Fong, DOITT NYC GOVERNMENT, USA
Change 39.033 Support for new NDM-CDI SMF record (default 133) creates
EXNDCDHW new dataset:
IMACNDCD DDDDDD DATASET DESCRIPTION
TYPENDCD NDCDHW NDCDCDHW CDzOS High Water Mark
TYPSNDCD You will have to set the MACRO _IDNDCD to 133 or your
VMACNDCD chosen record type. APAR PH35087 is needed to correct
VMXGINIT errors in the initial record contents.
Feb 23, 2021
Thanks to Luis Mendoza, Black Knight, USA.
Change 39.032 No error has been reported with VMXG70PR in MXG 39.01 but
VMXG70PR the DROP/KEEP/INPUT exposure is eliminated.
Feb 22, 2021
Change 39.031 The BETA 93 subtype 50 record was shortened and many
VMACBETA variables no longer exist in dataset BETA50.
Feb 22, 2021
Thanks to Andreas Menne, Finanz Informatik, GERMANY
Change 39.030 Variables added to dataset TYPE3804:
FORMATS S38GMODE ='FUNCTION*STATUS'
VMAC38 S38GDOM ='NETVIEW*DOMAIN'
Feb 22, 2021 and new format MG038GM decodes variable S38GMODE.
Thanks to Stephen Hoar, LLoyds Banking, ENGLAND.
Change 39.029 The $TMPSUEC and $TMPNRCPI FORMATS were updated for all
GRAFWRKX z14 and z15 processors.
Feb 22, 2021
====== CHANGES THRU 39.028 ARE IN MXG 39.01 DATED Feb 17, 2021 ========
Change 39.028 Support for SMF 90 subtype 41 when CVTLSO is changed.
EXTY9041 DDDDDD DATASET DESCRIPTION
IMAC90A TY9041 TYPE9041 CVTLSO CHANGED
VMAC90A
VMXGINIT
Feb 17, 2021
Change 39.027 If you had sorted the CICS stats data to tape (this is
VMXGCICI strongly not recommended) VMXGCICI would first fail with
Feb 17, 2021 an undefined macro variable and when that was corrected
would fail with multiple datasets open in a sequential
data library. While this is NOT a recommended practice it
will now work.
Thanks to Lu Ming, CPF, SINGAPORE.
====== CHANGES THRU 39.026 ARE IN MXG 39.01 DATED Feb 16, 2021 ========
Change 39.026 Support for IBM TAPE CLOUD CONNECTOR SMF record creates;
VMACCLTA DDDDDD DATASET DESCRIPTION
EXCLTA01 CLTA01 CLOUTAP1 CLOUD TAPE STAGE TO DISK
EXCLTA02 CLTA02 CLOUTAP1 CLOUD TAPE COPY TO CLOUD
EXCLTA03 CLTA03 CLOUTAP1 CLOUD TAPE DELETE FROM CLOUD
EXCLTA04 CLTA04 CLOUTAP1 CLOUD TAPE DELETE PROFILE
EXCLTA05 CLTA05 CLOUTAP1 CLOUD TAPE RESTORE FROM CLOUD
IMACCLTA
TYPECLTA
TYPSCLTA
FORMATS
Feb 13, 2021
Change 39.025 Documentation and EXAMPLES for SMF record selections.
VMACSMF In _SMF, which process just the SMF Header, there are
Feb 12, 2021 these subsystem variables created and available in the
IMACFILE/&MACFILE exit to select only wanted records.
RMF 70-79 PRODCMF MVSLEVEL
RMF 78.2 VSTORE
DB2: 100 101 102 SUBSYSTEM COMPRESSFLAG QWHSRELN
PRODVERSION ACCUMACFLAG
SUBTYPE=IFCID FOR SMF 102.
CICS: 110 SMFPSRVR SUBSYSTEM MNSEGCL MCTSSDCN
MCTSSDRL
SMF 30 SUBSYSTEM
SMF 80 SUBTYPE=RACFEVENT
SMF 115,116 SUBSYSTEM SM115REL PRODVERSION
SMF 6 SUBSYSTEM
SMF 36 SUBSYSTEM
1. Duplicate RMF/CMF records CANNOT BE PROCESSED, YOU
MUST SELECT THE DESIRED RECORDS, AND YOU WOULD USE
//SYSIN DD
%LET MACFILE= %QUOTE(IF PRODCMF=:'RMF';); or
%LET MACFILE= %QUOTE(IF PRODCMF=:'CMF';);
This may be required with z/OS 2.5 with CMF, because
z/OS BASE will write RMF 70 records (so sites without
RMF will have 70s for SCRT reports).
2. To detect if you have records from both products,
//SMF DD
//SYSIN DD *
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
RETAIN CURRPROD;
IF CURRPROD=' ' THEN CURRPROD=PRODCMF;
ELSE IF PRODCMF NE CURRPROD THEN DO;
PUT / '***POTENTIAL ERROR. SEE CHANGE 39.025.'/
' CMF AND RMF RECORDS ARE BOTH FOUND. ' SMFTIME=
ID= SYSTEM=
/+2 PREVSYS= 'PREVPROD=' CURRPROD 'NEWPROD='
PRODCMF +1 PREVTIME= 'ID=' PREVID PREVSYS=;
CURRPROD=PRODCMF;
END;
3. You can create a file of only CICS dictionary records:
//SMF DD DSN=SMF,DISP=SHR
//SMFOUT DD DSN=NEWDICTS,DISP=(,CATLG). .
//SYSIN DD *
%INCLUDE SOURCLIB(VMACSMF);
%LET MACFILE= %QUOTE(
IF ID=110 AND SUBTYPE=1 AND MNSEGCL=1;
FILE SMFOUT DCB=SMF;
PUT _INFILE_;
FILE LOG;
);
RUN;
%INCLUDE SOURCLIB(VMACSMF);
RUN;
DATA _NULL_;
_SMF;
RUN;
4. You can create a file of 1000 CICSTRAN records from
CICS/TS 5.6 with:
//SMF DD DSN=SMF,DISP=SHR
//SMFOUT DD DSB=NEWTRAN,DISP=(,CATLG) . . ..
//SYSIN DD *
%INCLUDE SOURCLIB(VMACSMF);
%LET MACFILE= %QUOTE(
IF ID=110 AND SUBTYPE=1 AND MNSEGCL=3 AND
SMFPSRVR=73;;
FILE SMFOUT DCB=SMF;
PUT _INFILE_;
FILE LOG;
NFOUND+1;
IF NFOUND GT 1000 THEN STOP;
);
RUN;
%INCLUDE SOURCLIB(VMACSMF);
RUN;
DATA _NULL_;
_SMF;
RUN;
Change 39.024 Three new ESS (IEFDOKEY) variables are added to TYPE6:
IMAC6ESS ESSPAGEL='DPAGELBL'
VMAC6 ESSSYSAR='SYSAREA'
Feb 9, 2021 ESSDUPLX='DUPLEX'
Thanks to Jerry Ellis, Liberty Mutual, USA.
Change 39.023 TYPECDC (Infosphere change data capture) records with
VMACCDC only the 92-byte header and no data caused INPUT
Feb 9, 2021 STATEMENT EXCEEDED error. Short records are deleted.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 39.022 Variables NCPCAPABIZE OVERCOMMIT STORAGESIZE XSTORESIZE
VMACXAM in dataset XAMSYS were misaligned and had missing values.
Feb 8, 2021
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 39.021 Override PSU70PR/LP/GC/GL DD's may not have worked.
VMXG70PR Depending on how you tried to change the destination,
Feb 12, 2021 with those macro variable DDnames with %LET may not
have been used, and those datasets could have been
written to &PDBMXG (normally PDB) instead of your %LET.
This change corrects to match the documentation.
Change 39.020 UTILWORK creates an RMFINTRV member with your Workloads.
IMACWORK New parameters enhance the useability of UTILWORK.
UTILWORK -IMACWORK=NO suppresses the use of IMACWORK.
Feb 6, 2021 With IMACWORK=YES, you can not have a WORKxx name that
matches an entry in IMACWORK; RMFINTRV will detect the
conflict and terminate.
SYSTEM= if you have multiple systems and you want to
define workloads differently SYSTEM=YES will add the
SYSTEM ID to each workload.
SYSPLEX= if you have multiple sysplex and you want to
define workloads differently, SYSPLEX=YES will add the
SYSPLEX ID to each workload.
In addition the first section of each workload (which
resolves to variable names) is now set to the SRVCLASS
since the restriction on 8 byte names is history.
Finally, the RMFINTRV member created is now printed
on the SASLOG.
Change 39.019 Using SP_REMV='Y', some labels were truncated because the
VMXGPRNT variable LABELR was not set to $80 nor blank padded.
Feb 2, 2021
Thanks to Scott Barry, SBBTechLLC, USA.
Change 39.018 -Some invocations of ANAL9914 caused mismatched %DO-%END
ANAL9914 errors because of a DO instead of a %DO statement. Logic
Feb 4, 2021 was rearranged, conditional execution of SGPANEL removed
and reordering of %VMXGOPTR executions.
-REPORT=JIM is not useable under WPS at this time; REPORT=
RAY is now forced for WPS.
Thanks to Virginie Peigney, CA-GIP, FRANCE.
Change 39.017 DB2 NETEZZA IDAA 100-1 INPUT STATEMENT EXCEEDED due to
VMACDB2 these new DB2 V12 fields and wrong LENREAD calculation.
Jan 31, 2021 You can use %LET MACKEEP= MACRO STOPOVER MISSOVER % ;
in SYSIN to circumvent the ABEND.
This change has not been tested with non-zero values;
only records with all values zero have been read so
none of the accumulated fields are deaccumed.
Please use member SENDDATA to send your SMF 100-1's.
-Variables added to DB2STAT1,DB2STATS,DB2NETZA:
Q8STTMUD='TOTAL MEM*AVAIL*USER DATA*IN MB'
Q8STTMPS='TOTAL MEM AVAIL*SQL/DML*IN MB'
Q8STCQLS='CURRENT*QUEUE*LENGTH'
Q8STOFLW='SORT*OVERFLOWS IN*ACCELERATOR*BACKEND'
Q8STABHR='ACCELERATOR*BUFFERPOOL*HIT RATIO'
Q8STANUI='CURRENT*IN RATE*ACCEL AND DB2*IN KB/S'
Q8STANUO='CURRENT*OUT RATE*ACCEL AND DB2*IN KB/S'
Q8STTSA ='DISK SPACE*IN MB FOR*TEMPORARY*DATA'
Q8STLSA ='DISK SPACE*IN MB FOR*LOG DATA'
Q8STTDPS='SUCCESSFUL*QUERY*REQUESTS*DELAY*PROTO'
Q8STEDPS='QUERY*REQUESTS*EXPIRED*DELAY*PROTOCOL'
Q8STTDPA='SUCCESSFUL*QUERY*REQUESTS*ALL DLYPRO'
Q8STEDPA='QUERY*REQUESTS*EXPIRED*WAITFORDATA'
Q8STVLCS='REPLICATION*VELOCITY*DB2 LOG SEC*PER SEC'
Q8STLRCP='CPU TIME*INT.S.S*ASYNC*LOG READER'
Q8STLRZI='ZIIP TIME*INT.S.S*ASYNC*LOG READER'
Q8STLRZE='ZIIP ELIGIBLE TIME*INT.S.S*ASYNC*LOG'
-Variables added to DB2STAT1,DB2STATS:
QISTLRCP='QISTLRCP*CPU*TIME'
QISTLRZI='QISTLRZI*ZIIP*TIME'
QISTLRZE='QISTLRZE*ZIIP*ELIGIBLE*TIME'
Thanks to Negri Gianvittorio, SAS, ITALY.
Thanks to Alberto Sturla, Banca Carige S.p.a, ITALY
Change 39.016 INCODE and OUTCODE parameters were not displayed with the
VMXGSUM other parameters, so logic that could cause zero obs was
Jan 30, 2021 not shown.
Change 39.015 Job report collected only TYPETASK=JOB so if the problem
ANALMSUS child was an STC it was missed. Now all OBS are used and
Jan 30, 2021 TYPETASK is added to the report.
Thanks to Mike Martin, NCSECU, USA.
Change 39.014 Parameters added to enhance flexibility and allow you to
EMAIL attach files rather than doing a PROC PRINT.
Jan 30, 2021 There are new examples in the member.
New parameters:
ATTACH- list of datasets to attach to email
BODY= text for body of email
the above only apply when attaching a file,
which is mutually exclusive with printing a
dataset. with printing a dataset,
These apply when printing a dataset:
LINESIZE=100
PAGESIZE=100
WHERE= a where clause for the PROC PRINT
Change 39.013 -MXG 34.06-38.38 ASMRMFV ABEND if a Storage Group has over
ASMRMFV 1,361 volumes. Change 34.191 introduced the potential 0C4
Jan 29, 2021 in subroutine PROCSPG when processing RMF III SPGG3 Table
(Storage Group and Volume Data) table, but we had no test
data with that large number of volumes.
Thanks to Victor Li, ATOS, HONG KONG
Thanks to Paul Leung, ATOS, HONG KONG
Change 39.012 z/OS SAS ODS may need an increase in the MEMLEAVE option
TECHNOTE (set in your CONFIGxx member) and MUST use REGION=0M. One
Jan 24, 2021 case SAS Tech Support recommended 1500M and that worked!
This note was originally to be Change 38.235.
Change 39.011 SAGANAL could fail when there unmatched RMF 70 and SMF 30
SAGANAL intervals, so data with SMFTIME GT the last 70 interval
Jan 30, 2021 are deleted.
Change 39.010 DB2 IFCID 172 T102S172 dataset variables QW0172Q4/Q8 are
VMAC102 INPUT $CHAR8 FORMAT $HEX16., QW0172HZ/WZ are INPUT &PIB.8
Jan 21, 2021 and Labels for QW0172HZ/WZ added Holder/Waiter.
Thanks to Jack Hyde, OPTUM, USA.
Thanks to Peter Vikeras, OPTUM, USA.
Change 39.009 TYPE70 PLATxxxxBUSY variables were incorrectly calculated
VMAC7072 adding the PHYSICAL LCPUPDTM to each calculation, but the
Jan 21, 2021 PLAT variables do NOT report this LPAR's utilization as
they calculate the utilization on ALL ENGINES IN THE CEC.
Thanks to Mark Tomlinson, Lloyds Bank, ENGLAND.
Change 39.008 zOS only. SAS ODS Graphics always uses Java, and Java can
TECHNOTE run on zIIP engines with significant CP CPU savings, but
Jan 18, 2021 a JVM file must be APF Authorized when your Java SYSPROG
installed Java. This z/OS message is printed in JOBLOG
(NOT SASLOG) and the JVM still executed correctly and
ended with CC=0, but the zIIP engines are not used:
JVMJ9VM082E Unable to switch to IFA processor
- issue "extattr +a 099 libj9ifa26.so"
"The JVM failed to switch to an IFA (Integrated Facility
for Applications) processor because the JVM library file
libj9ifa%s.so requires APF authorization."
One job running GRAFWRKX and GRAFCEC creating a PDF file
went from 484 CP secs to 107 CP + 146 ZIP = 253 secs.
The zIIP time is not reported by SAS, but the CPU time on
the SAS log is the sum of CP and zIIP can be much larger
than elapsed when zIIPs are used.
Change 39.007 Variable INTRVSYN (is RMF Sync with SMF?) was blank in
VMAC7072 datasets TYPE70xx and TYPE72xx, MXG38.05-38.38.
Jan 15, 2021
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 39.006 ANAL9914 Topology Report tests for &CECTYPE=Z15 added to
ANAL9914 support the z/15 processors, and the default is now Z15.
Jan 14, 2021
Thanks to Virginie Peigney, CA-GIP, FRANCE.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 39.005 Change 38.215 dropped these 4 variables from ASUMCELP.
VMXG70PR IFA70ACS IFA70BPS IFL70ACS IFL70BPS which are now kept.
Jan 8, 2021 IFA values will always be missing or 0.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 39.004 ANALID report did not identify CICS Compressed records;
VMACSMF VMACSMF incorrectly bypassed the test to set 'C'.
Jan 8, 2021
Thanks to MP Welch, Bank of America, USA.
Change 39.003 -Support for new variables TOKRABOID TOKKSTNPLTS in
VMAC80A dataset TYPE80TK.
Jan 10, 2021 -Dataset TYPE80TK will have fewer observations; each
token outputs an observation, but now there is a single
observation for each record with all tokens.
Thanks to Andreas von Imhof, RABOBANK, THE NETHERLANDS.
Change 39.002 ***WARNING - TYPETASK NOT DECODED SUBSYS=SAR. TYPE 6 SAR
VGETJESN records do not have a JCTJOBID which is used to create
Jan 5, 2021 TYPETASK. IF SUBSYS='SAR' THEN TYPETASK='SAR'; added.
Thanks to Joey TU, Los Angeles Department of Water and Power, USA
Thanks to Jon Hoang, Los Angeles Department of Water and Power, USA
Change 39.001 Cosmetic. DATEFMT=DATE7., was added to arguments.
VGETDDS
Jan 5, 2021
Thanks to Kenneth W. Pressley, Salt River Project, USA.
LASTCHANGE: Version 39.
=========================MEMBER=CHANGE38================================
/* COPYRIGHT (C) 1984-2020 MERRILL CONSULTANTS DALLAS TEXAS USA */
ANNUAL MXG VERSION 38.38 is dated Jan 4, 2021, thru Change 38.234.
MXG VERSION 38.10 was dated Nov 23, 2020, thru Change 38.213.
MXG VERSION 38.09 was dated Nov 4, 2020, thru Change 38.196.
First MXG VERSION 38.09 was dated Nov 2, 2020, thru Change 38.194.
MXG VERSION 38.08 was dated Sep 28, 2020, thru Change 38.163.
MXG VERSION 38.07 was dated Aug 22, 2020, thru Change 38.141.
MXG VERSION 38.06 was dated Jul 25, 2020, thru Change 38.123.
Second MXG VERSION 38.06 was dated Jul 25, 2020, thru Change 38.122.
First MXG VERSION 38.06 was dated Jul 24, 2020, thru Change 38.120.
MXG VERSION 38.05 was dated Jul 15, 2020, thru Change 38.112.
MXG VERSION 38.04 was dated May 25, 2020, thru Change 38.081.
MXG VERSION 38.03 was dated May 7, 2020, thru Change 38.071.
MXG VERSION 38.02 was dated Mar 23, 2020, thru Change 38.048.
MXG VERSION 38.01 was dated Feb 17, 2020, thru Change 38.027.
Annual MXG VERSION 37.37 was dated Jan 6, 2020, thru Change 37.272.
The Final MXG Newsletter SIXTY-NINE was dated Jan 3, 2018.
New TECHNOTES previously in NEWSLTRS are now in CHANGESS.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 38.38 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 38.38.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame, although there are
no new NEWSLTRS updates; they are now found in CHANGESS as TECHNOTEs.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG VERSION 38.38 DATED Jan 4, 2021, THRU CHANGE 38.234.
==MAJOR CHANGES ADDED IN MXG 38.38, DATED Jan 4, 2021 THRU 38.234.
ABEND CORRECTED:
TYPE90A 38.220 z/OS 2.2, MXG 38.09-10 SMF 90 ST 9 ABEND INPUT EXCEED
UTILBLDP 38.224 ERROR: OPTION NOT FOUND if UTILBLDP has SUPPRESS=ID
VMXGSUM 38.223 VMXGSUM ignored %LET MXGCLASSNWAY=YES, DSN NOT FOUND.
ASMRMFV 38.226 MXG 38.09-10. RMF III CFIG3 record error.
NEW SUPPORT:
TYPETMO2 38.228 Support for TMON/CICS 4.1 revisions, INSTREAM TMON.
TYPE92 38.222 Support for APAR OA60306, adds 8-byte memory fields.
TYPESY2K 38.221 Support for SYSTEM 2000 Flat File.
TYPE42 38.216 Support for APAR OA59581 new TYPE42DS SYNC fields.
TYPESYNC 38.214 New SYNCSORT zIIPSaver add-on variables.
CORRECTION:
TYPE70PR 38.215 TYPE70PR var CP70BPS/ZIP70BPS/CP70ACS/ZIP70ACS wrong.
==MAJOR CHANGES ADDED IN MXG 38.10, DATED Nov 23, 2020 THRU 38.213.
ABEND CORRECTED
TYPE110 38.205 SMF 110 ST 1 MNSEGCL=5 INPUT STATEMENT EXCEEDED.
TYPE42 38.204 TYPE 42 ST 5 incorrect MXG logic INPUT EXCEEDED.
NEW SUPPORT:
ASUM113 38.201 New z/15 EXTND256-EXTND287 were not kept in ASUM1131.
TYPEBETA 38.200 Support for BETA93 and BETA97 new data and updates.
TECHNOTE 38.199 Compressed SMF 110 expensive without EXITCICS on z/OS
ASMVVDS 38.197 Updates to read VVDS records and output to file/SMF.
==MAJOR CHANGES ADDED IN MXG 38.09, DATED Nov 4, 2020 THRU 38.196.
ABEND CORRECTED
UTILBLDP 38.195 UTILBLDP with SUPPRESS=110 and BUILDPDB NE 'NO'
ABENDED with ERROR:WORK.CICSEXCE.DATA not found.
==MAJOR CHANGES ADDED IN MXG 38.09, DATED Nov 2, 2020 THRU 38.194.
NEW SUPPORT:
TYPE110 38.168 Support for CICS/TS 5.6 STID=43, 46, and new STID=61.
TYPE16 38.164 Support for APAR PH03207 for DFSORT ZSORT stats.
ASMRMFV 38.188 Support for RMF III EXECVEL and PERFINDX variables.
ASMRMFV 38.181 New Field Data Filter support for CFIG3 table.
TYPE102 38.179 Support for DB2 ZPARM MFA_AUTHCACHE_UNUSED_TIME.
TYPE38 38.178 Support for z NetView 6.3 Subtype 4 Command stats.
ANALAVAI 38.183 Enhanced reporting on availability.
ERRORS CORRECTED:
UTILEXCL 38.180 Optional "Candle" CICS segment kept wrong variables.
TYPE50 38.177 VSAM Tuning data sets were misaligned.
==MAJOR CHANGES ADDED IN MXG 38.08, DATED Sep 28, 2020 THRU 38.163.
VMAC30 38.163 Support for APAR OA59813 for BOOSTCLASS='RECO'.
TYPE74 38.152 Support for APARs OA58724/58729 new Monopoly in ST=4.
UTILBLDP 38.157 BUILDMXG fails if you didn't specify OUTFILE=.
TYPE119 38.156 Tokens for TYP11924/11925 were not in _N119.
ANAL119 38.150 Errors corrected if you didn't have //IPHOSTS file.
ANALSIIS 38.149 SM113TM replaced by TIMESTMP for better match up.
READDB2 38.147 ACCTSORT=NO caused redirects to not be honored.
VMXGDUR 38.145 If interval LT actual duratm, warning is printed.
VMXG70PR 38.142 Support for ASUM70WK to keep full hours.
VMXGPRAL 38.159 MXG 38.07 only, 180 Syntax Error citing SP_NOBS.
TYPERMFV 38.124 Many dupes in ZRBXCG/XCP/XCS datasets.
TYPERMFV 38.162 Datasets ZRBCHP and ZRBSCM had zero observations.
PDBAUDIT 38.161 Value of PDBAUDIT incorrectly set, revised.
==MAJOR CHANGES ADDED IN MXG 38.07, DATED Aug 22, 2020 THRU 38.141.
TYPE26J2 38.137 Support for APAR OA57466 new TYPE26J2 compress data.
ASMRMFV 38.128 Field Data Filter FDF Support adds XCFG3, FDF fix.
TYPE7072 38.126 SMF sysplex data with SMF Logger INTERLEAVES ALL SMF.
TYPERMFV 38.124 Many dupes in ZRBXCG/XCP/XCS datasets.
==MAJOR CHANGES ADDED IN MXG 38.06, DATED Jul 25, 2020 THRU 38.123.
VMXGCICI 38.123 Tailored CICxxxxx statistics in PDB and WORK failed.
TYPE110 38.122 Some CICS Statistics datasets (CICxxxxx) were sorted
because %INCLUDE SOURCLIB(SCICSORT) after line 6281
was accidentally deleted.
==MAJOR CHANGES ADDED IN MXG 38.06, DATED Jul 24, 2020 THRU 38.120.
TYPE110 38.114 New CICSRDUR/URIMAP, CICSRDWB/WEBSVC datasets.
TYPEDB2 38.117 Support for DB2 APAR PH16111 IFCID 365 SMF 100.
TYPE102 38.117 Support for DB2 APAR PH16111 IFCID 365 SMF 102.
TYPEMVCI 38.116 Support for BMC Mainview for CICS 7.1 (COMPATIBLE).
==MAJOR CHANGES ADDED IN MXG 38.05, DATED Jul 15, 2020 THRU 38.112.
ABEND CORRECTED:
TYPE7072 38.103 MXG 38.03/38.04 TYPE7072 fails if //PDB on TAPE.
ASCII 38.091 MXG on Windows, AV Products, LOCK NOT AVAILABLE
SAS 38.087 ERROR: Utility File Open Failed PROC MEANS/SUMMARY.
TYPE83 38.090 SMF 83 ST 3 INPUT STATEMENT EXCEEDED.
NEW SUPPORT:
TYPE110 38.084 Support for CICS/TS 5.6 (INCOMPAT, FIELDS INSERTED).
TYPE7072 38.107 Support for APAR OA59330 new variables in TYPE7002.
MANY 38.105 Support for May 2020 SMF Manual Changes zOS 2.4.
TYPETPMX 38.102 Support for Thruput Manager TMT7123/TMT7124 Jul 2020.
TYPE85 38.100 Support for SMF 85 OAM Cloud Tier.
TYPE74 38.098 Support for SMF 74 CMF from BMC PTF BQM12658/59.
TYPE78 38.097 Support for APAR OA56684 TYPE78IO EADM/SCM variables.
TYPEDB2 38.096 Support for APAR PI98851 new variables DB2STATS.
TYPE30 38.093 Support for APAR OA59126, dataspaces variables.
TYPE74 38.089 Support for new EADM variables in TYPE7410.
TYPESARR 38.088 Support for CA View SARR SMF Subtypes 34 and 35.
ANALINIT 38.083 Enhanced JOB EXEC/QUEUED/HELD/etc analysis
TYPE110 38.099 CICS Statistics Records revisions.
ASMRMFV 38.082 ASMRMFV FDF Support for new tables.
CMF+RMF 38.095 Variable CMFPROD to select CMF vs SMF if both are on.
UCICSCNT 38.085 Enhanced counts/bytes for SMF 110 including STIDs.
==MAJOR CHANGES ADDED IN MXG 38.04, DATED MAY 25, 2020 THRU 38.081.
ABEND CORRECTED:
BLDSMPDB 38.081 MXG 38.03 only. BLDSMPDB WEEKLY JOB ABENDS, typo.
Line 667 has 1 %END; remove the "1".
Only on z/OS and only if WEEK is a GDG.
ERRORS CORRECTED:
TYPE30_6 38.072 Revised deaccumulate for accumulated subtype 6.
TYPEDB2 38.075 Support for APAR PH14037 DB2ACCTP QPACPKID truncated.
No MXG Change, IBM APAR corrected wrong offset.
ANAL119 38.073 Cleanup and removal of a typo.
NEW SUPPORT:
FORMATS 38.080 Support for z15 T02 values in $MGRMIPS format.
TYPE42 38.079 Support for APAR OA59541 for Type 42 Subtype 27.
TYPE102 38.077 SMF102 IFCID 143/144 increase length QW014xUR.
==MAJOR CHANGES ADDED IN MXG 38.03, DATED MAY 16, 2020 THRU 38.071.
EXPOSURE CORRECTED:
AUTOINST 38.054 ASCII Unique INSTREAM create for Concurrent Sessions.
-ALL ASCII SITES SHOULD PUT %AUTOINST IN IMACINIT.
ERRORS CORRECTED
TYPE123A 38.061 Datetime values were 2080 instead of 2020, MXG error.
TYPECMFV 38.063 CMF VSAM INVALID DATA messages, wrong informat.
TYPECIMS 38.058 CIMS/IMF CIMSDBD/DB2/MQ Zero Obs 37.37-38.02
VMXGOPTR 38.056 ANALHSM caused Error "SAS Option Name OPTIONS 1".
TYPE70 38.055 PCTMVSBY incorrect after 37.123. (NOT PCTCPUBY!!!).
ASMRMFV 38.064 Support for APAR OA58759, caused Condition Code 4.
TYPEXCOM 38.069 XCOM input did not skip the 461 bytes added in 12.0.
New Support
TYPE119 38.068 Support for Comm Server SMF 119 Subtype 11 ZERT data.
TYPE110 38.060 SET MONITOR FREQ hourly CICSTRAN for long runners.
UTILROLL 38.065 UTILROLL example to combine PDBs created every 4hr.
TYPEDB2 38.062 Support DB2 APAR PI92652,PI82191 and DPAGE support.
TYPESVIE 38.057 Support for SYSVIEW Subtype 2 record one min detail.
TYPEXAM 38.059 zVPS XAMCUV LCPUID=96 Totals records now deleted.
VMACSMF 38.051 SAS FTP Access Method &MXGABND=1 set to print errors.
TYPE42 38.067 Yet another TYPE42 invalid LENSR in subtype 5 42's.
==MAJOR CHANGES ADDED IN MXG 38.02, DATED MAR 23, 2020 THRU 38.048.
ERRORS CORRECTED
VMACSMF 38.033 SMF Signature Type 2 St 1/2 MANY BACK2BACK LOG msgs
TYPE112 38.040 OMEGAMON TEMS St 38 INVALID ARGUMENT LENGTH CHANGED.
TYPE73 38.038 Variable SHIFT was not populated.
New Product Support
TYPEVMXA 38.048 z/VM MONWRITE 6.4.19.1 z15 INCOMPATIBLE.
Many Log Messages, PRCMFC/PRCMFM empty, rest okay.
TYPE70 38.031 Support for APAR OA56683 SMFBOOST System Recovery
TYPE62 38.041 Support for APAR OA57105, adds JOBID SYSPLEX.
TYPE64 38.041 Support for APAR OA57105, adds JOBID SYSPLEX.
TYPETPMX 38.039 Support for new INREI and JCLJJ in TYPETPMX.
Enhancements
TYPE116 38.037 MQMACCTQ/MQMACCT/MQCFSTAT/MQMQUEUE/ revisions.
TYPE113 38.035 TYPE113 Counters EXTND247/252/264/265 now labeled.
TYPEVMXA 38.019 z/VM VXAPLSLM variable SHARERAM zero if not RHEL8.
TYPE89 38.034 APAR OA59002 corrects TYPE89 var SMF89UZT values.
==MAJOR CHANGES ADDED IN MXG 38.01, DATED Feb 17, 2020 THRU 38.027.
ERRORS CORRECTED
CONFIMXG 38.004 MXG 37.37 only, 1024 should be OPEN_ED=1047.
TYPE80A 38.017 INPUT EXCEEDED due to a HOME segment with no data.
ANALID 38.010 ERROR "OPTORG4" if you changed SMFAUDIT to NO.
UTILBLDP 38.008 Error after Change 37.149 if first USERADD is IDMS.
New Product Support
FORMATS 38.020 Support for SMF73CPT 33/34 connection types.
TYPE102 38.019 Support for DB2 APAR PH18739 var QW0389IT in T102S389
TYPEIMS 38.014 Support for APAR PH14569/PH21001 IMS 22 log record.
TYPEBETA 38.013 Support for BETA (93) and BETA97 Version 7.1.0
TYPEBE97 38.013 Support for BETA (93) and BETA97 Version 7.1.0
TYPE42 38.011 Support for APAR OA57718, zHyperLink TYPE42DS stats.
TYPEIAM 38.006 Support for IAM 9.3 Spin 3 INCOMPATIBLE inserts.
FORMATS 38.003A R744HOPM $MG074HO new '50x:CL5 10GBIT/S CEE ROCE'.
TYPEIDMS 38.003 IDMSTAS UOW/NETNAME added, TASUFLD1-3 corrected.
TYPETMS5 38.002 Variables BYTEPRC and BESKEY added to TMS/DSNBRECD.
BUILDIMS 38.001 All selections now work, new INPUTCLNR variable.
New Analysis/Reporting
ANAL95TH 38.018 PROC TABULATE 95th pct response stats CICSTRAN/JOBS.
ANALATNC 38.005 Report Code for Latent Demand analysis, examples of
reports: https://www.mxg.com/downloads/analatnc
DOCVLONG 38.012 Creates a DOCVLONG with all DOCVER data on one line.
ANALSIIS 38.009 Analysis of Store Into Instruction Stream enhanced.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M7 (9.4M7),
"M7", or with options VERSIONLONG;
"SAS 9.4 (9.04.01M7P080520)" on z/OS
9.4 (TS04.01M7P08052020)" on ASCII.
SAS V9.4 M7 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M6 or SAS Version 9.3 M0-M2.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.128 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But CONFIMXG is required for sites with NLS issues, and you must
use JCLCONFI to create/update the MXG.FORMATS catalog if you use
CONFIG='MXG.SOURCLIB(CONFIMXG)'.
For no NLS, you can use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 36.11 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 4.1 USER 4037 ABEND, See Change 37.116.
WPS Version 4.0 reportedly fixed version 3 problems.
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
The z15 and z15 T02 processors INCOMPATIBLY changed the SMF 113
records by inserting 32 new EXTEND and 4 CRYPTO counters, causing
ARRAY SIZE EXCEEDED with BUILDPDB which processes the SMF 113s.
Support for counter changes for both models was in MXG 37.08.
If you use MIPS in reports, the format $MGRMIPS provides the
MIPS/MSU value for each processor; the z15 values were updated
in MXG 37.08, and the z15 TO2 values were updated in MXG 38.04.
These MXG programs use $MGRMIPS: ASUMMIPS GRAFCEC GRAFWLM
GRAFWRKX and TYPERMFV (RMF III).
The z/14 also inserted SMF 113 fields, supported in MXG 36.07.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
And z/VM on the z15 requires MXG 38.02, PRCMFC/MFM COUNTERS caused
HARDWARE COUNTER messages, PRCMFC/PRCMFM no obs. Change 38.048.
The z13 processor INCOMPATIBLY CHANGED, the new SMT-MODE RMF 70, and
MXG 34.03 was REQUIRED (PCTCPUBY WRONG!), to read the SMT-format RMF
(which are written if you have zIIP engines AND have enabled the new
PROCVIEW CORE option for Multi-Threading, even if only one thread is
enabled).
The new zEDC/EADM compression hardware requires MXG 38.05 to support
new metrics.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z/OS 2.4 Compatible from SMF Manual Sep 2019 37.166 37.07.
z/OS 2.4 Compatible from SMF Manual May 2020 38.105 38.05.
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
z15 New SMF 113 fields INCOMPAT Nov 18, 2020 37.08
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS-TS/5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS-TS/5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS-TS/5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS-TS/5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS-TS/5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS-TS/5.3 GA date Dec 11, 2015 33.33
CICS-TS/5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS-TS/5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS-TS/5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS-TS/5.4 GA Jun 17, 2017 35.03
CICS-TS/5.5 GA (INCOMPAT) Jan 29, 2018 36.11
CICS-TS/5.6 GA (INCOMPAT) Jun 1, 2020 38.07
CICS-TS/5.6 NEW DATA (COMPAT) Oct 5, 2020 38.09
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
z/VM 6.40061802 ABEND Jan 17, 2019 37.02
z/VM 7.1 INCOMPAT ABEND Feb 14, 2019 37.02
z15 z/VM MFC counters, INCOMPAT Mar 23, 2020 38.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2, 5.3, 5.4 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 38.38.
1. Incompatibilities introduced in MXG 38.38:
a. Changes in MXG architecture made between 38.38 and prior versions
that can introduce known incompatibilities.
IF YOU HAVE MEMBER E2TY70 IN YOUR USERID.TAILORING SOURCE LIBRARY,
YOU MUST CHANGE _LTY70 to _WTY70 in that member. CHANGE 38.105.
The error before this correction will be:
ERROR: DATA SET "PDB.TYPE70" was not specified on the DATAA stmt.
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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 38.38:
Dataset/
Member Change Description
ANAL95TH 38.018 PROC TABULATE 95th pct response stats CICSTRAN/JOBS.
ANALATNC 38.005 Report Code for Latent Demand analysis, examples at
https://www.mxg.com/downloads/Latent_Demand
ANAL119 38.073 Cleanup and removal of a typo.
ANAL119 38.150 Errors corrected if you didn't have //IPHOSTS file.
ANALAVAI 38.183 Enhanced reporting on availability.
ANALID 38.010 ERROR "OPTORG4" if you changed SMFAUDIT to NO.
ANALINIT 38.083 Enhanced JOB EXEC/QUEUED/HELD/etc analysis
ANALSIIS 38.009 Analysis of Store Into Instruction Stream enhanced.
ANALSIIS 38.149 SM113TM replaced by TIMESTMP for better match up.
ASCII 38.091 MXG on Windows, AV Products, LOCK NOT AVAILABLE
ASMRMFV 38.064 Support for APAR OA58759, caused Condition Code 4.
ASMRMFV 38.082 ASMRMFV FDF Support for new tables.
ASMRMFV 38.128 Field Data Filter FDF Support adds XCFG3, FDF fix.
ASMRMFV 38.181 New Field Data Filter support for CFIG3 table.
ASMRMFV 38.226 MXG 38.09-10. RMF III CFIG3 record error.
ASMVVDS 38.197 Updates to read VVDS records and output to file/SMF.
ASUM113 38.201 New z/15 EXTND256-EXTND287 were not kept in ASUM1131.
AUTOINST 38.054 ASCII Unique INSTREAM needed for Concurrent Sessions.
BLDSMPDB 38.081 MXG 38.01 only. BLDSMPDB WEEKLY JOB ABENDS, typo.
BUILDIMS 38.001 All selections now work, new INPUTCLNR variable.
CMF+RMF 38.095 Variable CMFPROD to select CMF vs SMF if both are on.
CONFIMXG 38.004 MXG 37.37 only, 1024 should be OPEN_ED=1047.
DOCVLONG 38.012 Creates a DOCVLONG with all DOCVER data on one line.
FORMATS 38.003A R744HOPM $MG074HO new '50x:CL5 10GBIT/S CEE ROCE'.
FORMATS 38.020 Support for SMF73CPT 33/34 connection types.
FORMATS 38.080 Support for z15 T02 values in $MGRMIPS format.
MANY 38.105 Support for May 2020 SMF Manual Changes zOS 2.4.
READDB2 38.147 ACCTSORT=NO caused redirects to not be honored.
SAS 38.087 ERROR: Utility File Open Failed PROC MEANS/SUMMARY.
TECHNOTE 38.199 Compressed SMF 110 expensive without EXITCICS on z/OS
TYPE102 38.019 Support for DB2 APAR PH18739 var QW0389IT in T102S389
TYPE102 38.077 SMF102 IFCID 143/144 increase length QW014xUR.
TYPE102 38.117 Support for DB2 APAR PH15111 for IFCID 365. SMF 102.
TYPE102 38.179 Support for DB2 ZPARM MFA_AUTHCACHE_UNUSED_TIME.
TYPE110 38.060 Long Running CICS Trans, SMF 110 every hour.
TYPE110 38.060 SET MONITOR FREQ hourly CICSTRAN for long runners.
TYPE110 38.084 Support for CICS/TS 5.6 (INCOMPAT, FIELDS INSERTED).
TYPE110 38.099 CICS Statistics Records revisions.
TYPE110 38.114 New CICSRDUR/URIMAP, CICSRDWB/WEBSVC datasets.
TYPE110 38.114 New CICSRDUR/URIMAP, CICSRDWB/WEBSVC datasets.
TYPE110 38.168 Support for CICS/TS 5.6 STID=43, 46, and new STID=61.
TYPE110 38.205 SMF 110 ST 1 MNSEGCL=5 INPUT STATEMENT EXCEEDED.
TYPE112 38.040 OMEGAMON TEMS St 38 INVALID ARGUMENT LENGTH CHANGED.
TYPE113 38.035 TYPE113 Counters EXTND247/252/264/265 now labeled.
TYPE116 38.037 MQMACCTQ/MQMACCT/MQCFSTAT/MQMQUEUE/ revisions.
TYPE119 38.068 Support for Comm Server SMF 119 Subtype 11 ZERT data.
TYPE119 38.156 Tokens for TYP11924/11925 were not in _N119.
TYPE123A 38.061 Datetime values were 2080 instead of 2020, MXG error.
TYPE16 38.164 Support for APAR PH03207 for DFSORT ZSORT stats.
TYPE30 38.093 Support for APAR OA59126, dataspaces variables.
TYPE30_6 38.072 Revised deaccumulate for accumulated subtype 6.
TYPE38 38.178 Support for z NetView 6.3 Subtype 4 Command stats.
TYPE42 38.011 Support for APAR OA57718, zHyperLink TYPE42DS stats.
TYPE42 38.067 Yet another TYPE42 invalid LENSR in subtype 5 42's.
TYPE42 38.079 Support for APAR OA59541 for Type 42 Subtype 27.
TYPE42 38.204 TYPE 42 ST 5 incorrect MXG logic INPUT EXCEEDED.
TYPE42 38.216 Support for APAR OA59581 new TYPE42DS SYNC fields.
TYPE50 38.177 VSAM Tuning data sets were misaligned.
TYPE62 38.041 Support for APAR OA57105, adds JOBID SYSPLEX.
TYPE64 38.041 Support for APAR OA57105, adds JOBID SYSPLEX.
TYPE70 38.031 Support for APAR OA56683 SMFBOOST System Recovery
TYPE70 38.055 PCTMVSBY incorrect after 37.123. (NOT PCTCPUBY!!!).
TYPE7072 38.103 MXG 38.03/38.04 TYPE7072 fails if //PDB is on TAPE.
TYPE7072 38.106 Support for APAR OA59330 new variables in TYPE7002:
TYPE7072 38.126 SMF sysplex data with SMF Logger INTERLEAVES ALL SMF.
TYPE70PR 38.215 TYPE70PR vars CP70BPS/ZIP70BPS/CP70ACS/ZIP70ACS wrong
TYPE73 38.038 Variable SHIFT was not populated.
TYPE74 38.089 Support for new EADM variables in TYPE7410.
TYPE74 38.098 Support for SMF 74 CMF from BMC PTF BQM12658/59.
TYPE74 38.152 Support for APARs OA58724/58729 new Monopoly in ST=4.
TYPE78 38.097 Support for APAR OA56684 TYPE78IO EADM/SCM variables.
TYPE80A 38.017 INPUT EXCEEDED due to a HOME segment with no data.
TYPE83 38.090 SMF 83 ST 3 INPUT STATEMENT EXCEEDED.
TYPE85 38.100 Support for SMF 85 OAM Cloud Tier.
TYPE89 38.034 APAR OA59002 corrects TYPE89 var SMF89UZT values.
TYPE90A 38.220 z/OS 2.2, MXG 38.09-10 SMF 90 ST 9 ABEND INPUT EXCEED
TYPE92 38.222 Support for APAR OA60306, adds 8-byte memory fields.
TYPEBE97 38.036 Support for BETA (93) and BETA97 Version 7.1.0
TYPEBETA 38.036 Support for BETA (93) and BETA97 Version 7.1.0
TYPEBETA 38.200 Support for BETA93 and BETA97 new data and updates.
TYPECIMS 38.058 CIMS/IMF CIMSDBD/DB2/MQ Zero Obs 37.37-38.02
TYPECMFV 38.063 CMF VSAM INVALID DATA messages, wrong informat.
TYPEDB2 38.062 Support DB2 APAR PI92652,PI82191 and DPAGE support.
TYPEDB2 38.075 Support for APAR PH14037 DB2ACCTP QPACPKID truncated.
TYPEDB2 38.096 Support for APAR PI98851 new variables DB2STATS.
TYPEDB2 38.117 Support for DB2 APAR PH16111 SMF 100 Locations.
TYPEIAM 38.006 Support for IAM 9.3 Spin 3 INCOMPATIBLE inserts.
TYPEIDMS 38.003 IDMSTAS UOW/NETNAME added, TASUFLD1-3 corrected.
TYPEIMS 38.014 Support for APAR PH14569/PH21001 IMS 22 log record.
TYPEMVCI 38.116 Support for BMC Mainview for CICS 7.1 (COMPATIBLE).
TYPERMFV 38.124 Many dupes in ZRBXCG/XCP/XCS datasets.
TYPESARR 38.088 Support for CA View SARR SMF Subtypes 34 and 35.
TYPESVIE 38.057 Support for SYSVIEW Subtype 2 record one min detail.
TYPESY2K 38.221 Support for SYSTEM 2000 Flat File.
TYPESYNC 38.214 New SYNCSORT zIIPSaver add-on variables.
TYPETMO2 38.228 Support for TMON/CICS 4.1 revisions, INSTREAM TMON.
TYPETMS5 38.002 Variables BYTEPRC and BESKEY added to TMS/DSNBRECD.
TYPETPMX 38.039 Support for new INREI and JCLJJ in TYPETPMX.
TYPETPMX 38.102 Support for Thruput Manager TMT7123/TMT7124 Jul 2020.
TYPEVMXA 38.019 z/VM VXAPLSLM variable SHARERAM zero if not RHEL8.
TYPEVMXA 38.047 z/VM MONWRITE 6.4.19.1 z15 INCOMPATIBLE.
TYPEXAM 38.059 zVPS XAMCUV LCPUID=96 Totals records now deleted.
TYPEXCOM 38.069 XCOM input did not skip the 461 bytes added in 12.0.
UCICSCNT 38.085 Enhanced counts/bytes for SMF 110 including STIDs.
UTILBLDP 38.008 Error after Change 37.149 if first USERADD is IDMS.
UTILBLDP 38.157 BUILDMXG fails if you didn't specify OUTFILE=.
UTILBLDP 38.224 ERROR: OPTION NOT FOUND if UTILBLDP has SUPPRESS=ID
UTILEXCL 38.180 Optional "Candle" CICS segment kept wrong variables.
UTILROLL 38.065 UTILROLL example to combine PDBs created every 4hr.
VMACSMF 38.033 SMF Signature Type 2 St 1/2 MANY BACK2BACK LOG msgs
VMACSMF 38.051 SAS FTP Access Method &MXGABND=1 set to print errors.
VMXG70PR 38.142 Support for ASUM70WK and ASUM70P3 to keep full hours.
VMXGDUR 38.145 If interval LT actual duratm, warning printed.
VMXGINIT 38.046 SAS Option REUSE=YES is forced to REUSE=NO DEFAULT.
VMXGOPTR 38.056 ANALHSM caused Error "SAS Option Name OPTIONS 1".
VMXGSUM 38.223 VMXGSUM ignored %LET MXGCLASSNWAY=YES, DSN NOT FOUND.
TYPEXAM 38.234 zVPS/XAM datasets XAMIFLBY & XAMIFLTO have zero obs.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at https://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE
====== CHANGES THRU 38.234 ARE IN MXG 38.38 DATED Jan 4, 2021 ========
Change 38.234 zVPS/XAM datasets XAMIFLBY & XAMIFLTO now have zero obs.
VMACXAM Dataset XAMCPUTO contains the CPID=TOTAL/GPs/IFLs types
Dec 29, 2020 (TOTAL is all engines, GPS GP engines IFLS IFL engines)
for each interval. (Previously only had TOTAL and GPS).
The individual CPnn engine values are in XAMCPUBY and the
PFXCPUTY variable identifies if the engine is GP or IFL.
-HEX format added for CALMNEST RCCTOPDS DSVASSOC DSVUNPRK
-CPID is UPCASED so GPs or IFLs values will be GPS/IFLS.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 38.233 Six variables added to TRNDRMFI:
VMXGRMFI MAXZIPBY - maximum PCTZIPBY
Dec 23, 2020 MAXZIPTM - maximum ZIP time
MAXZIETM - maximum ZIP eligible time
MAXCPUTM - maximum CPU time
CPCFNAME - processor type
LPARSHAR - initial LPAR share
to prevent UNINIT messages and missing values using
GRAFWRKX with PDB=TREND.
Change 38.232 ANAL119 report TNRPTS has TTTELUNA/APIREMOT UNINITIALIZED
ANAL119 if there is no //IPHOSTS file. Logic to read IPHOSTS was
Dec 21, 2020 revised to skip incomplete entries.
====== CHANGES THRU 38.231 WERE IN EARLY ADOPTER 38.38 Dec 23, 2020 ====
Change 38.231 GOUT is suppressed when running WPS since WPS does not
GRAFCEC support graphic catalogs. These members also did not
GRAFWRKX recognize PDB=TREND and printed blank pages when the
Dec 18, 2020 response variable was missing values in all OBS. Both
issues were corrected.
Change 38.230 -The UTILWORK report helps you set up RMFINTRV WORKLOADS.
UTILWORK If the sum of CPUTM from service classes is greater than
Dec 31, 2020 the sum for report classes that means not all workloads
have a report class defined and you may not use report
classes to define workloads. Now USERPRT is set to NO to
force using service class.
-If you have an environment with multiple plexes then the
WLM policies may be different. UTILWORK now adds SYSTEM
and SYSPLEX to the skeleton RMFINTRV member. These can be
removed in your editing of the member if they are not
needed in your environment.
Change 38.229 Four variables added to TRNDRMFI:
VMXGRMFI MAXZIPBY - maximum PCTZIPBY
Dec 18, 2020 MAXZIPTM - maximum ZIP time
MAXZIETM - maximum ZIP eligible time
MAXCPUTM - maximum CPU time
Change 38.228 Support for TMON/CICS changes to 4.1, INCOMPATIBLE
IMACTMO2 No ERROR Messages, but INVALID Values because fields were
VMACTMO2 increased from 4 to 8 bytes.
Dec 16, 2020 -MONIARQ dataset, TAARQRCN was increased to 8 bytes,
misaligning TAARQRTM,TAARQRCN,TAARQWTM TAARQTXT,TAARQICT
which were also increased to 8 bytes.
-MONISYS dataset. TIHDASSZ and TITERILG byte counts have
some negative values; they were 1E19 when INPUT as PIB8.
-MONITASK dataset PRIINCHR byte counts can be negative.
Variable FILEIOCN was increased to 8 bytes causing
FCDELCN,FCGETCN,FCBROCN,FCADDCN and FCUPDCN to be wrong
and those fields were also increased to 8 bytes.
-MONIEXT dataset. All EBCDIC64 variables translate '00'x
to a blank.
-MONIDBDS dataset, for DB2 the VOLSER starts with two null
bytes and only the last four bytes are populated.
-MONIAWT dataset. TAAWTTCN was increased to 8 bytes
misaligning TAAWTTTM TAAWTFLG TAAWTWRC TAAWTWRT variables
that were also increased to 8 bytes.
-MEMBER IMACTMO2 example enables TMON exit in SYSIN; using
the EXITMON6/TMON Infile Exit saves significant CPU time.
Thanks to MP Welch, Bank of America. USA.
Change 38.227 SMF 119 Subtype 3 FCBYTES with z/OS 2.1 is wrong; there
VMAC119 are two inputs, the original PIB8 64-bit binary field and
Dec 16, 2020 the RB8 float field added to support larger values. Data
records with valid binary (9.2 million) and invalid float
(1.16225) values are created, and that float value is the
one that is output. This change inputs float as FCBYTES2
IF FCBYTES2 GT FCBYTES THEN FCBYTES=FCBYTES2;
Thanks to Perry Lim, MUFG Union Bank, USA.
Change 38.226 -ASMRMFV when processing RMF III CFIG3 can issue a warning
ASMRMFV message: RMFV035W **WARNING: DETAIL nnn CFI TABLES
Dec 14, 2020 SKIPPED DUE TO VALIDATION ERRORS : ***PLEASE CONTACT
SUPPORT@MXG.COM***
-Change number 38.188 incorrectly altered CFIG3 table
processing when validating Connection entries.
-Affects only ASMRMFV at 38.188 level,MXG version 38.09-10
Thanks to MP Welch, Bank of America, USA.
Thanks to Gary Wyper, Natwest, SCOTLAND
Thanks to Rob D'Andrea, Natwest, SCOTLAND.
Change 38.225 WPS did not support Views so the MXG Defaults MXGVIEW=NO.
VMXGINIT Current WPS versions now support views. You can use
WPSVIEWS //SYSIN DD
Dec 12, 2020 %INCLUDE SOURCLIB(WPSVIEWS);
to enable their use to save CPU and I/O resources.
Change 38.224 ERROR: OPTION NOT FOUND if your UTILBLDP has SUPPRESS=ID
ANALID to prevent that dataset from being created. Originally in
UTILBLDP Change 38.056, and partially corrected in 38.174, this
Dec 12, 2020 change protects ANALID for DONEANALID case.
Change 38.223 If you used %LET MXGCLASSNWAY=YES in SYSIN for %VMXGSUM,
VMXGSUM to set CLASSNWAY=YES, VMXGSUM ignored it and it caused an
Dec 12, 2020 ERROR: DSNAME NOT FOUND trying to delete VMXGSUM1. See
Change 34.137 which introduced CLASSNWAY.
Change 38.222 Support for APAR OA60306 which adds 8-byte memory metrics
VMAC92 for more than 2GB in type 92 subtype 12 and 23 records:
Dec 10, 2020 TYPE9212: SMF92MLSZ='BYTES*BEING*MEMORY*MAPPED'
TYPE9213: SMF92MULSZ='BYTES*BEING*MEMORY*MAPPED'
Change 38.221 Support for SYSTEM 2000 Flat File, work in progress.
EXSY2KA
EXSY2KB
EXSY2KC
EXSY2KD
IMACSY2K
TYPESY2K
TYPSSY2K
VMACSY2K
VMXGINIT
Dec 9, 2020
Change 38.220 z/OS 2.2, MXG 38.09-.10 SMF 90 ST 9 ABEND INPUT EXCEEDED
VMAC90A RECORD LENGTH because MXG added INPUT of SMF90STE in MXG
Dec 5, 2020 Change 38.186 SMF Manual Update, but IBM added that field
in z/OS 2.3. Now, it is kept and INPUT if it exists.
Use this statement in //SYSIN to circumvent the ABEND:
%LET MACFILE= %QUOTE(IF ID=90 AND SUBTYPE=9 THEN DELETE;);
The subtype 9 is only written for an IPL SMF event,
Thanks to Randy Hewitt, DXC, USA.
Change 38.219 -Labels for S42DSGSR/S42DSLSR/S42DSRLS/S42DSNSR removed
VMAC42 "COMPRESSED"; only if S42DSEFC='Y' are they compressed.
Dec 10, 2020 Labels S42AMRIB/S42AMWIB are now VSAM*BYTES*read/write,
S42DSHWR label corrected to COUNT and S42DSIOS changed.
to S42DSIOS='TOTAL METRO*MIRROR*IO-S'.
Thanks to Michael Friske, FMR, USA.
Change 38.218 Change 36.049 added and extra / causing a failure to
VGETALOC communicate with the operating system and could result in
Dec 3, 2020 no allocations and a failure of a following VMXGSET. Now
there should be only 1.
Thanks to Ken Pressley, SRPNET, USA.
Change 38.217 -NOTRAN attribute support for WPS is added in VMXGINIT so
VMXGINIT that z/OS WPS datasets can be downloaded to ASCII and the
TESSOTHR $HEX formatted variables will not be translated. See
VMACXDFG Change 27.014 for the &MXGNOTRA/&MXGNOTRB addition.
VMACXDNS -TESSOTHR and the six VMACXDxx members were updated for
VMACXDSP WPS QA. A test for &SASVER prevented their WPS execution.
VMACXDSS
VMACXDTI
VMACXDTS
Dec 8, 2020
Change 38.216 Support for APAR OA59581, new TYPE42DS variables:
VMAC42 S42SNTWK='SYNC*WRITES*HYPERLINK*NOT PERFORMED'
Dec 10, 2020 S42SNTWV='SYNC*WRITES*RESERVED*DEVICE'
S42SNTWY='SYNC*WRITES*HYPER DISABLED*TOKEN ERROR'
S42SNTWU='SYNC*WRITES*HYPER DISABLED*COPY'
S42SNTWF='SYNC*WRITES*HYPER DISABLED*PAGE BOUNDARY'
S42SNTWQ='SYNC*WRITES*HYPER DISABLED*INVALID'
S42SNTWZ='SYNC*WRITES*HYPER DISABLED*ZHPF DISABLED'
S42SNTWW='SYNC*WRITES*HYPER DISABLED*INTERNAL ERR'
S42SNTWH='SYNC*WRITES*HYPER DISABLED*DUAL LOGGING'
S42SNTDR='SYNC*WRITES*DUAL*LOGGING'
S42SNTDX='SYNC*WRITES*HYPER DISABLED*ASYNC'
S42SNDWI='SYNC*WRITES*ASYNC*INVALID*TOKEN*/
S42SNDWK='SYNC*WRITES*ASYNC*ZHYPERLINK*/
S42SNDWV='SYNC*WRITES*ASYNC*RESERVED*DEVICE*/
Change 38.215 TYPE70PR variables CP70BPS/ZIP70BPS/CP70ACS/ZIP70ACS were
VMAC7072 sometimes incorrectly populated and were a missing value
VMXG70PR in ASUMCELP dataset. The variable labels were corrected.
Nov 27, 2020
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 38.214 New variables in dataset SYNCSORT by zIIPSaver add-on:
VMACSYNC SYNCMPIN $CHAR1. /**CMPI*NOGO*REASON*CODE*/
Dec 1, 2020 SYNCMPON $CHAR1. /**CMPO*NOGO*REASON*CODE*/
SYNCMPRT &PIB.2. /**COMPRESSION*RATIO*SORTOUT*/
Variables CPUZIPTM and CPUCPTM are now correctly located
and correctly input. The DSECT does not match the data.
Thanks to Glen Bowman, Wakefern, USA.
====== CHANGES THRU 38.213 ARE IN MXG 38.10 DATED Nov 23, 2020 ========
Change 38.213 New DB2STAT1 (IFCID=0002) APAR PH29098 variables:
VMACDB2 QISTINPR ='IAG2*PIPE*RENABLE*ATTEMPTS'
Nov 21, 2020 QISTINPE ='IAG2*PIPE*RENABLE*SUCCESS'
QISTCONDLKF='CONDITIONAL*LOCK*FAILURES'
QISTRETRYLK='UNCONDITIONAL*LOCK*RETRIES'
Change 38.212 In the TYPE70EN dataset, when the engine was parked for
VMAC7072 the full interval, PCTCPUBY and PCTMVSBY could be small
Nov 20, 2020 negative values due to resolution differences in DURATM
with 2 decimals and SMF70PAT with 6. Now, the negative
value is replaced with zero.
Thanks to Pierre Pascal Joulin, SOCGEN, FRANCE.
Change 38.211 New variables added in Oct 25, 2020 SMF Manual:
VMAC7072 -Dataset TYPE72TR new variables
VMAC89 R723GMLT='GGMN/GGMX*ARE IN*MSU/HR?'
VMAC78 R723GMLZ='ZIP*INCLUDED*GGMN*GGMX?'
Nov 20, 2020 -Dataset TYPE892 new variables
BOOSTACTIVE BOOSTCLASS (were in TYPE89 but not TYPE892)
-Dataset TYPE78VS new variables
R782FLG='RUCSA*IS*DEFINED?'
R782RUCA='RUCSA*ADDRESS*BELOW*16M'
R782RUCS='RUCSA*SIZE*BELOW*16M'
R782ERUCA='RUCSA*ADDRESS*ABOVE*16M'
R782ERUCS='RUCSA*SIZE*ABOVE*16M'
Change 38.210 New variables added to TYPE9040 dataset SMF 90 ST 40:
VMAC90A SMF9040ID='ID OF*START*REQUESTOR'
Nov 19, 2020 SMF9040DU='RECOVERY*PROCESS*BOOSTS*DURATION'
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.209 zERT variable SMF119SC_TLS_PROT_VER format $MG119PX now
FORMATS decodes '0304'x as TLSV1.3.
Nov 19, 2020
Thanks to Thomas Liu, ANZ, AUSTRALIA.
Change 38.208 Variable RESPAVG is added to ASUMCICS/ASUMCICT/TRNDCICS
ASUMCICS as it already existed in ASUMCICX. Variable IRESPTM is
ASUMCICT the SUM of all transaction response times.
TRNDCICS
Nov 18, 2020
CHANGE 38.207 If you are rolling up interval data to weeks and your
TECHNOTE week does not start on Monday you can use the STARTDAY
VMXGDUR macro variable to start weeks on the day of the week
TRND**** you choose by inserting this line in IMACINIT or any
Nov 18, 2020 code where you are using VMXGDUR to summarize data to
a week (all of the TRND**** members).
%LET STARTDAY=day 1 of MON TUE WED THU FRI SAT SUN
Change 38.206 Format MG116CT for TYPE116 variable QCSTCHTY in dataset
FORMATS MQCHININ had 9='9:DLUSSCR' typo, now is 9='9:CLUSSDR'.
Nov 18, 2020
Thanks to Rob Hollingum, HSBC, ENGLAND.
Thanks to Matt Crawford, HSBC, ENGLAND.
Change 38.205 SMF 110 St 1 MNSEGCL=5 Resource Record extra 14 bytes
VMAC110 caused INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Nov 18, 2020 WHILE (LENLEFT GT 0) changed to WHILE (LENLEFT GT 140).
You can circumvent with this added to your //SYSIN:
%LET IHDR110= %QUOTE(IF MNSEGCL=5 THEN DELETE;) ;
Thanks to Martha A. Knapik, Progressive, USA.
Thanks to Craig S. Bigler, Progressive, USA
Thanks to Diana L. Laskovich, Progressive, USA.
Change 38.204 Type 42 St 5 MXG logic to correctly calculate SRLEN was
VMAC42 exposed to INPUT STATEMENT EXCEEDED LENGTH error because
Nov 17, 2020 SRLEN=160 is valid, but the optional SYNC segment length
Nov 19, 2020 is included in SRLENGTH=OFFVOL-OFFSR which misled to
the incorrect recalculation, which is now bypassed.
Thanks to Andrew Petersen, DXC, AUSTRALIA.
Change 38.203 CHANGE 37.267 added an ERROR:INCORRECT ENCODING message
VMXGINIT on the log, but the code was inserted before &OPSYS was
Nov 17, 2020 populated, so the message was never printed.
Thanks to John Compton, World Programming, ENGLAND
Change 38.202 Variable DCDCTYPE='COMPRESSION*TYPE' was not kept in the
VMACDCOL DCOLDSET dataset.
Nov 16, 2020
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 38.201 The new z/15 TYPE 113 counters EXTND256-EXTND287 were not
ASUM113 kept in the PDB.ASUM1131 dataset. Only EXTND264/EXTND265
Nov 11, 2020 are described, and neither is used in any calculations.
but now, all will exist, and be populated if on z z/15.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 38.200 Support for BETA 93 and BETA 97 new data and corrections:
EXTYBETO -New variables added to dataset BETA50:
EXTYBETU BETAINDI='IP*ADDRESS*INDICATOR'
FORMATS BETAIFLGS='ADDRESS*TYPE*INDICATOR'
VMACBE97 BETAHOSTPORT='HOST*PORT'
VMACBETA BETASERVPORT='SENDING*PORT OF*SERVER'
VMXGINIT BETAIPHOST ='HOST*IP*ADDRESS'
Nov 17, 2020 BETAIPCLIENT='WEB*BROWSER*CLIENT*IP'
BETAIPSERV ='WEB*APP SERVER*IP'
BETAIPSERVI ='WEB*INTERNAL*FORMAT'
BETALUSED='LDD*TABLE*USED?'
BETALJOBN='MASK USED*JOB*NAME*FIELD'
BETALSTPD='MASK USED*STEP*NAME*FIELD'
-Two new BETA 93 datasets from subtype 43
DDDDDD DATASET DESCRIPTION
TYBETO BETA43 ST43 ARCHIVE DATE CHANGE
TYBETU BETA43DS ST43 CHANGE DATASETS
-Corrections to BETA93 subtypes 50 and 55.
-Corrections to BETA97 subtypes 0, 22, 51 and 55.
Thanks to Andreas Menne, Finanz Informatik, GERMANY
Change 38.199 Processing compressed SMF 110 Records without the INFILE
TECHNOTE decompression exit (EXITCICS) is VERY expensive on z/OS.
Nov 24, 2020 Each test processed the same 50000 110 records & created
668,652 OBS in CICSTRAN.
Uncompressed records were 7.4GB, compressed were 1.5GB.
STEPNR CPUTM SELAPSTM EXCP EXCP
3390 TAPE
zOS EXTRACT ONLY 110.1 0:03:23.39 0:05:04.72 5493 653324
zOS DFH$MOLS 0:00:12.84 0:00:55.97 2 93621 Xfer:
zOS READ COMP USE EXIT 0:00:20.56 0:00:20.56 42866 117MB/sec
zOS READ COMP NO EXIT 0:03:30.25 0:04:31.70 42870 3673KB/sec
zOS READ UNCOMPRESSED 0:00:12.12 0:00:17.20 63949 99MB/sec
Win FTP compressed 0:00:37.12 0:01:28.56 11MB/sec
Win FTP unpacked 0:00:43.45 0:02:03.78 12MB/sec
Win Read compressed FTP 0:03:32.10 0:03:36.68 3783KB/sec
Win Read unpacked FTP 0:00:56.40 0:02:06.41 12MB/sec
Win Read comp local 0:03:49.73 0:04:23.97 4590KB/sec
Win Read unpacked local 0:00:21.18 0:00:21.40 74MB/sec
Change 38.198 GOUT suppressed when running WPS since WPS does not
GRAFCEC support graphic catalogs.
GRAFWRKX
Nov 6, 2020
Change 38.197 -Updates to ASMVVDS program that reads VVDS records with
ASMVVDS output to a sequential flat file and/or output as SMF
JCLASMXG records.
Nov 4, 2020 -Default setting of 0 for @UCB31 (UCBs below 16MB) line
changed to a setting of 1 (UCBs above 16MB) which is more
appropriate for modern z/OS systems.
-Two assembly errors are also fixed.
-NOTE: ASMVVDS must be APF authorized. That requires parm
of AC(1) in program binder step and the load library must
also be authorized.
-See ASMVVDS source member for full installation and usage
instructions.
-Sample JCL for assembly and linkedit of ASMVVDS was added
to member JCLASMXG (which Assembles all MXG ASM program).
Thanks to Victor Li, Atos, Hong Kong
====== CHANGES THRU 38.196 ARE IN MXG 38.09 DATED Nov 4, 2020 ========
Change 38.196 New parameter COMPANY added with default of MXG to allow
GRAFWLM you to insert your COMPANY NAME in titles. The Parameter
NOV 4, 2020 list was sorted into alphabetic order..
Change 38.195 ERROR: WORK.CICSEXCE.DATA does not exist if SUPPRESS=110
UTILBLDP and BUILDPDB NE 'NO' were specified in your invocation;
Nov 4, 2020 the null _SCICEXC, _SCICSYS, _INTCICS macros were not
created, causing the ABEND.
Thanks to Jim S. Horne, Lowe's Companies, USA.
====== CHANGES THRU 38.194 ARE IN MXG 38.09 DATED Nov 2, 2020 ========
Change 38.194 Support for dataset TYPE80TK new variables:
VMAC80A TOKMACCOUNT TOKMP9ACTION TOKMTSSTATUS BUILDING TOKMDEPT
NOV 2, 2020 TOKMEMPNO TOKMLANG TOKMPRINTER TOKMPROVINCE
TOKMUSERTYPE TOKMLDAPPROF
Thanks to Gaetan Martel, INTACT, CANADA.
Thanks to Serte-TI Belanger, INTACT, CANADA.
Change 38.193 Correction for IDMSTAS variables TASUFLD1-TASUFLD3 input;
VMACIDMS the extra 8-bytes do not exist in TASTTYPE='40'x records.
OCT 31, 2020
Thanks to Dennis Jamiel, Travelport, USA.
Thanks to Marcos Villasenor, Travelport, USA.
Change 38.192 Support for ThruPut Manager TMT7124 update, which adds.
VMACTPMX these variables to dataset TYPETPMX:
OCT 30, 2020 TPMTMNOM='NUMBER*OF THIS*RECORD'
TPMTMNON='TOTAL*NUMBER OF*RECORDS'
TPMTMAPP='KNOWN APPLICATIONS'
TPMTMELR='ELAPSED*TIME ON*READER'
TPMTMCAC='CATALOG*CPU*TIME'
TPMTMCAE='CATALOG*ELAPSED*TIME'
TPMTMDJC='DAL/JAL*CPU TIME''
TPMTMDJE='DAL/JAL*ELAPSED*TIME''
TPMTMSSC='DTMSSREQ*CPU TIME'
TPMTMSSE='DTMSSREQ*ELAPSED*TIME'
TPMTMUXC='USER EXIT*CPU TIME'
TPMTMUXE='USER EXIT*ELAPSED*TIME'
TPMTMJ2C='JES2 INTERFACE*CPU TIME'
TPMTMJ2E='JES2 INTERFACE*ELAPSED*TIME'
TPMTMTLC='TAPE*LIBRARY*CPUT TIME'
TPMTMTLE='TAPE*LIBRARY*ELAPSED*TIME'
TPMTMANA='ANALYSER*START*DATETIME'
Change 38.191 Support for CICS optional HUMTRAN field INPUT $EBCDIC8.
UTILEXCL Change 38.115 had added support for $16 and $24 INPUTs.
OCT 29, 2020 Variable HUMTRAN is length $24 with either INPUT.
Thanks to Dave Baker, HCA Healthcare, USA.
Thanks to Lisa Gascoigne, HCA Healthcare, USA.
Change 38.190 The report of all job activity only printed the first 500
ANALJOBE lines of the report; now all lines are printed.
OCT 28, 2020
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 38.189 Format $MG119SP decodes variable SMF119SC_SASECPROTOS:
FORMATS VALUE $MG119SP /*$MG119SC FORMAT FOR VMAC119*/
VMAC119 '00'X='00X:NO PROTECTION'
Oct 28, 2020 '80'X='80X:TLS/SSL'
'40'X='40X:SSH'
'20'X='20X:IPSEC'
;
Thanks to Joe Faska, DTCC, USA.
Change 38.188 -New MXG variables EXECVEL (Execution Velocity) and
ADOCRMFV PERFINDX (Performance Index) are added to PDB data set
ASMRMFV ZRBRCDT (RMF III RESPTIME SERVICE CLASSES).
VMACRMFV -New MXG variable EXECVEL (Execution Velocity) added to
Oct 27, 2020 PDB data set ZRBRCDX (RMF III RESPTIME REPORTING
CLASSES).
-If for some reason a Response Time Distribution Array was
not present in the RCDG3 RMF III table the corresponding
Service Class or Report Class period would not be output
to the PDB.
-Rarely RMF III may generate an SSHG3 (Sample Set Header)
table where the sample begin datetime and sample end
datetime are the same. Effectively this is a null table
with zero samples. With this condition an Abend S002 in
ASMRMFV is possible.
-ASMRMFV will now detect this condition, then issue a new
RMFV023W message:
**WARNING: SAMPLE START/STOP DATE TIMES ARE IDENTICAL.
ENTIRE SAMPLE SET WILL BE SKIPPED***
and the entire SSHG3 table will be skipped and output to
the RMFSKIP DD file (if present).
-This condition may be due to the timing sequence in a
system shutdown process. Both RMFGAT and RMF Started
Tasks should be completely terminated before the process
continues.
-Warning message RMFV022W was not formatted correctly.
-Warning message RMFV023W was duplicated.
-Section 12 Messages in ADOCRMFV updated to include the
new RMFV023W message.
-TUTORIAL 1:
Execution Velocity is a WLM measurement based on system
states which are continuously collected by sampling.
System states describe when a work request uses a system
resource (a using state) and when it must wait for it
because it is used by other work (a delay state).
# Using Samples
Execution Velocity = --------------------------- * 100
# Using + # Delay Samples
Execution Velocities thus range from 0 to 100.
A value of 100 means the unit of work is running with no
WLM DETECTED delays. A value of 0 means the that unit of
work is not running at all either because it has no
access to the resources needed or it is idle.
The Execution Velocity formula does not include the
unknown state. This state includes delays not tracked by
WLM, such as locks or enqueues. So an Execution Velocity
of 100 does not necessarily mean the work unit is running
totally unencumbered.
-TUTORIAL 2:
Performance Index (PI) is a calculation of how well work
is meeting its WLM defined goal.
For work with response time goals, the Performance Index
is the actual response divided by the goal response.
For work with velocity goals, the Performance Index is
the goal velocity divided by actual velocity.
A Performance Index of 1.0 indicates the Service Class
period is exactly meeting its goal. A Performance Index
greater than 1 indicates the Service class period is
missing its goal. A Performance Index of less than 1.0
indicates the Service Class period is beating its goal.
Work with a Discretionary goal is defined to have a fixed
Performance Index of .81 . Service Classes for System
address space have no Performance Index as they do not
have goals.
Each Service Class period has a Sysplex and a Local
Performance Index.
The Sysplex Performance Index represents the performance
of a Service Class period across all systems in the
Sysplex. The RMF III SYSSUM report shows this assuming
it has access to all RMF III VSAM data sets for the
Sysplex in the time period being reported.
The Local Performance Index represents only the
performance on a single local system. PERFINDX in MXG
is a Local Performance Index.
Thanks to Rodger Foreman, Black Knight, Jacksonville, FL, USA
Thanks to Len Shenfield, ADP, Roseland, NJ, USA
Change 38.187 -If you suppressed CICSSTAT that also unintentionally
UTILBLDP suppressed ASUMUOW and ASUMCICX. Now if you want to
Oct 27, 2020 suppress ASUMUOW ASUMDBAA or ASUMDBSS you can add them to
the SUPPRESS= parameter by name. In the case of ASUMUOW
this also suppresses ASUMCICX but if you did not suppress
CICSTRAN then ASUMCICS is substituted. These four members
CICSSTAT ASUMUOW ASUMDBAA and ASUMDBSS are all resource
intensive, and if you don't use them you can save those
resources by suppressing them.
-If you suppressed ID and used BUILDPDB=JES3 you got an
error message that the type of VIEW could not be
determined. There were many other spots which looked only
for YES or NO that were fixed. The value of BUILDPDB is
now validated and if it is not blank, NO, YES, or JES3
UTILBLDP will end with error messages.
Change 38.186 MXG estimate of DOWNTM prior to an IPL used the PREVTIME
VMAC0 of the last record, but what was needed was the PREVTIME
VMAC90A of the ID=0 record, and the IPLTIME of the ID=0 is now
Oct 26, 2020 retained in TMP0TIME and used for the IPLTIME in the
DOWNTM calculation in the ID=90 ST=10 IPL SRM record.
-Processing ID=0 record, the GMTOFF was off by one second.
-Variable SMF90STE was INPUT, but see Change 38.220 ABEND.
Thanks to Tore Hansson, IBM Services, NORWAY.
Change 38.185 MXG 38.03 Change 38.051 set MXGABND=1 for missing SMFTIME
VMACSMF value when using the SAS FTP Access Method, because we
VMXGINIT have seen that associated with an FTP "hang" until it was
Oct 21, 2020 cancelled, and by forcing an ABEND you can avoid the hang
and if you've pointed the LOG option to a file, you can
see if there were other error conditions. But MXGABND is
is macro variable used in many members so you can choose
an ABEND instead of ERROR messages (like TYPE110, where
some sites want an ABEND alert when EXCLUDED FIELDS are
detected). In this case, the CPUTM GT ELAPSED condition
in TYPE110 tested MXGABND GT 0 and cause an unwanted
ABEND. Now, macro variable SMFMISS is created and can be
used to cause the abend when SMFTIME is missing using the
FTP access method, using %LET SMFMISS=NNN; in your SYSIN
to cause ABORT ABEND NNN instead of the ERROR and a hang.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 38.184 MXG 38.08. ERROR: File WORK.PDBTYPE70.DATA does not exist
VMXG70PR if you tailor and invoke %VMXG70PR with no PDB= argument.
Oct 19, 2020 We recommend you always use %INCLUDE SOURCLIB(ASUM70PR);
instead of putting a tailored VMXG70PR in USERID because
IBM changes may require incompatible changes in VMXG70PR,
but we can protect ASUM70PR from the need for change.
In general, if there is an ASUMxxxx that invokes VMXGxxxx
its always safer to use the ASUMxxxx member.
Thanks to Otto A. Burges, OPM, USA.
Change 38.183 -The detail report did not correctly report outages. The
ANALAVAI beginning was the beginning of the interval when it came
Oct 29, 2020 back up and the ending was the time when that interval
Nov 4, 2020 ended.
-A new month-to-date summary report was added and the
availability is now calculated as the
(uptime-outagetime + scheduledtime)/86400*100;
-Changed Parameter values:
CYCLE=M1 has not been changed but a null value will
let you accumulate many months of data.
- New Parameters:
MINOUTAGE=5 number of outage seconds to ignore
OUTCODE= a stub of code just after PCTAVAIL is
calculated
SCHEDULED= stub of code allowing you to specify
scheduled outages for each app.
see doc and examples in member.
Update in MXG 38.09 dated Nov 4, 2020:
If you were not very careful building schedules and
outages, duplicate obs could skew percentages. SORTS with
NDDUP added to eliminate duplicate obs. Also outages were
not carried into month totals resulting in availability GT
100%.
An Example of invoking %ANALAVAI:
When building schedules it is critical that you always
output either outages or scheduled for each app with a
schedule.
%ANALAVAI(
COMPANY=YOUR COMPANY,
SCHEDULED=
IF APP IN('SYSA','SYSB','SYSC')
AND WEEKDAY(DATE) = 1 THEN DO;
IF APP IN('SYSB','SYSA')
AND BEGSKED GE '03:00'T
AND ENDSKED LE '03:30'T
THEN OUTPUT SCHEDULED;
IF APP='SYSC'
AND BEGSKED GE '03:00'T
AND ENDSKED LE '04:00'T
THEN OUTPUT SCHEDULED;
ELSE OUTPUT OUTAGES; *critical statement;
END;
ELSE IF APP = 'PRODCICS' THEN DO;
IF WEEKDAY(DATE) NE 7
AND BEGSKED GE '23:15'T
AND ENDSKED LE '06:05'T
THEN OUTPUT SCHEDULED;
ELSE IF BEGSKED GE '23:15'T
AND ENDSKED LE '07:05'T
THEN OUTPUT SCHEDULED;
ELSE OUTPUT OUTAGES; *critical statement;
END;
ELSE IF APP = 'ADABAS' THEN DO;
IF WEEKDAY(DATE) EQ 1
AND BEGSKED GE '23:15'T
AND ENDSKED LE '02:05'T
THEN OUTPUT SCHEDULED;
ELSE OUTPUT OUTAGES; *critical statement;
END;
ELSE OUTPUT OUTAGES; *required final statement;
,
APP1=SYSB/SYSC IS UP/JES2,
APP2=SYSA/SYSA IS UP/JES2,
APP3=SYSC/SYSC IS UP/JES2,
APP4=SYSA/ADABAS/ADABAS,
APP5=SYSC/PRDCICS/CICSPTOR CICSPAOR CICCSPFOR,
DDIN=PDB,
ODSTYPE=,
TYPERUN=BUILDR
);
RUN;
Thanks to Shantanu.Gupta, ENSONO, USA.
Thanks to Ankush Dudhbavare, ENSONO, USA.
Thanks to Rahul Raj, ENSONO, USA.
Change 38.182 -If you specified BUILDPDB=NO with SUPPRESS=x you got an
UTILBLDP invalid compare on several FLAGxx macro variables used to
Oct 21, 2020 keep track of suppressed items for BUILDPDB. SUPPRESS= is
ignored when BUILDPDB is set to NO as the only records
read are those in USERADD=. Comments updated for MXGINCL.
-If you specified OUTFILE=XYZ and XYZ did not exist you
got an unresolved macro reference. On zOS you must have
a DD or a filename statement for the OUTFILE= parameter
unless you use the recommended INSTREAM.
-Comments added to handle products with multiple SMF IDs.
Thanks to Thomas Liu, ANZ. NEW ZEALAND.
Change 38.181 -New ASMRMFV Field Data Filter (FDF) support for the RMF
ADOCRMFV III Coupling Facility Information Table (CFIG3).
ASMRMFV -New Section 33 Filtering The CFIG3 Table added to
Oct 16, 2020 documentation member ADOCRMFV. Following section
numbers all incremented by 1.
-FDF filtering is supported for the Header, Coupling
Facility, Structure, and Structure Extension sections in
the RMF III CFIG3 table.
-After a Structure Extension section in CFIG3 with no
connections occurs, ASMRMFV did not output following
connection entries for subsequent Structure Extensions in
the same Coupling Facility to RMFBSAM.
-TUTORIAL:
The result of a FDF IF=/ORIF=/ANDIF= expression compare
is one of the following:
TRUE FALSE IGNORE
An expression is IGNOREd when:
1) The input RMF III data is for a release that does not
support the Fieldname. This is the most common reason.
IBM may have discontinued the Fieldname, moved it to
another offset with a different Fieldname, or added it in
a higher RMF release than the data being processed.
2) The RMF III table section containing the Fieldname is
absent. Not every section is always present in every RMF
III table. Some sections depend on RMF III startup
options.
NOTE: In the case of the CFIG3 table the Structure
Extension, Connections, and/or Storage Class Memory
sections may not exist. In some cases the Structure
and/or Channel Path sections may not exist. The CFIG3
does not exist at all for LPARs running as z/VM guests.
3) The known offset for Fieldname is beyond the length of
the table section being processed. This could be an
internal ASMRMFV or RMF III error.
4) ASMRMFV treats an IGNORE condition as a TRUE condition
and the data is NOT filtered.
-Example:
The Fieldname CFISTMAE is part of the Structure Extension
section in the CFIG3 table. But if NOCFDETAIL is in
effect in the RMF Monitor III start options, then the
Structure Extension section will not exist for that LPAR.
Assume there are 35,020 structures in the RMF III VSAM
file for the CFIG3 table. Recall that the table is
generated for each RMF III MINTIME interval.
The IF expression is:
RMFV002I SYSIN : IF=(CFISTMAE GT 0)
RMFV088I IF= : CFISTMAE GT 0 X'00000000'
The result will be:
RMFV080I COMPARES: TRUE= 0 FALSE= 0 IGNORE= 35,520
TOTAL= 35,520
Change 38.180 These optional "Candle" CICS segments' variables were not
UTILEXCL correctly kept in the _VCICTRN created by UTILEXCL:
Oct 14, 2020 CANFLAGS CANGMTOF CANUSRWK CANSUPRN CANSUPRT CANDCOMN
CANDCOMT CANRES01. The names in the "Link to IMACICxx:"
were in the wrong "xx:" labels.
Thanks to Shantanu Gupta, ENSONO, USA.
Change 38.179 Support for DB2 ZPARM MFA_AUTHCACHE_UNUSED_TIME value in
VMAC102 seconds in variable QWP4MFAT in T102S106 dataset.
Oct 14, 2020
Thanks to Lai Fai Wong, Bank of America, USA.
Change 38.178 Support for Z NetView 6.3 subtype 4 Command Statistics
EXTY3804 creates new dataset TYPE3804 which contains these
VMAC38 S38DCMDN ='COMMAND*NAME'
VMXGINIT S38DALTN ='COMMAND*ALTERNATE*NAME'
Oct 19, 2020 S38DPRNT ='PARENT*NAME'
S38DTSK ='NETVIEW*TASK*NAME'
S38DSTCK ='START*DATETIME'
S38DETCK ='END*DATETIME'
S38DSTCK ='CPU*TIME'
S38DSTG ='STORAGE*HWM'
S38DIOC ='TOTAL*I/O'
S38DAUSR ='AUTHORIZED*USER*NAME'
S38DELAP='ELAPSED*DURATION'
Thanks to Mark Tomlinson, Lloydsbanking, ENGLAND.
Change 38.177 VTAM Tuning SMF 50 record datasets 502R/502W/504R/504W
VMAC50 were misaligned.
Oct 16, 2020
Thanks to Thomas Doster, IBM, USA.
Thanks to Kristen Lamastr, IBM,USA.
Change 38.176 User tailoring %LET PDBMXG=yourdd; failed with PDB NOT
VMXG70PR FOUND if there was no PDB=LIBNAME argument, or ASUM70GC
Oct 9, 2020 and ASUM70GL were written to PDB instead of "yourdd" if
the PDB libname exists. MXG 38.08 only.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 38.175 MXG 38.08 only. Change 38.170 added support for suppress
UTILBLDP 115 and 116 records, but if you suppressed ID and did not
Oct 8, 2020 set VWVMACID to null you could get an error message from
SAS that the type of VIEW could not be determined, but
only with older SAS versions.
Change 38.174 The Change 38.056 "Error: Unrecognized SAS option name"
ANALID only occurred if ID was suppressed, now that's protected.
Oct 9, 2020
Change 38.173 The ANALID format for SMF 72.4 and 72.5 is changed from
FORMATS RMF I to RMF III because the data gatherer source for
Oct 6, 2020 both of those records written by RMF I is RMF III.
Thanks to Randy Hewitt, DXC Technology
Change 38.172 Variable ZCOSTIME is now numeric with DATETIME20. format.
VMACZCOS
Oct 6, 2020
Thanks to Pierre Pascal Joulin, SOCGEN, FRANCE.
Change 38.171 The title for the report for DEVMNTMX and DEVMNTAV was
ANALBVIR reversed and is now "INST MIN MAX AVG THRUPUT"/
Oct 5, 2020
Thanks to John Donoghue, AIB, IRELAND
Change 38.170 This utility to create tailored BUILDPDB input code adds
UTILBLDP MQ option to SUPPRESS= so both the 115 and 116 records
Oct 3, 2020 can be skipped.
Change 38.169 Corrected a JCL error in the IBM DFH$MOLS CICS program
DFH$MOLS that decompresses SMF 110 (SUBTYPE 1 ONLY) records.
Oct 2, 2020
Change 38.168 Support for new CICS/TS 5.6 Statistics Variables added to
EXCICXSG STID=43 (CICDQR), eliminate spurious message STID=46 that
SCICSORT new fields were added,and new CICXSG dataset from STID=61
VMAC110 SMF 110 Subtype 2 records.
VMXGINIT
Oct 5, 2020
Change 38.167 Labels for TYPE64 SINCE*OPEN and SINCE*CREATION were
VMAC64 reversed. Variables ACCLEVEL ACCNEXTS ACCNRECS ACCDELET
Oct 1, 2020 ACCINSRT ACCUPDAT ACCRETRV ACCUNUCI ACCISPLT ACCASPLT and
ACCEXCPS are SINCE*OPEN and variables INDXLVLS NREXTNTS
RECORDS DELETES INSERTS UPDATES RETRVALS UNUSEDCI
CISPLTS CASPLITS and EXCPS are SINCE CREATION.
Thanks to Michael Friske, FMR, USA.
Change 38.166 New utility that will help you decide if you should run
UTILUOW ASUMUOW and whether you should use CASE1 or CASE2 from
Oct 1, 2020 IMACUOW if you do decide to run it. ASUMUOW is used to
create the ASUMUOW observations for each UOW in an MRO
by combining the CICSTRAN observations from TOR/AOR/DOR
so you have the valid TRANNAME for the CSMI transactions.
If there is little use of MRO, then it is not worth the
CPU expense. And if there is MRO usage, you need to chose
CASE1 or CASE2 for your IMACUOW tailoring.
Change 38.165 Error "Attempt to open two sequential members" if PDBOUT
READDB2 is on tape (which we DO NOT RECOMMEND) and ACCTSORT=NO
Sep 30, 2020 is specified with READDB2. A circumvention that creates
only the below account datasets is to use TYPSDB2:
%cleardb2;
%let mackeep=%quote(
macro _sdb2acp data _lDb2acp; set _wdb2acp; %
macro _sdb2acr data _lDb2acr; set _wdb2acr; %
macro _sdb2acg data _lDb2acg; set _wdb2acg; %
macro _sdb2acw data _lDb2acw; set _wdb2acw; %
macro _sdb2pat data _lDb2pat; set _wdb2pat; %
);
%include sourclib(typsdb2);
But if your READDB2 did selection (like SSID), that PDB
could have a lot more observations, and any other IFCID
in the original READDB2 would not be created.
An alternative is to use READDB2 but point PDBOUT to a
temporary disk data library, and then PROC COPY to the
tape data library, so all selections are supported.
But the temp disk data library could be quite large,
and might require multi-volumes.
Change 38.164 Support for APAR PH03207 for DFSORT ZSORT statistics that
FORMATS are added to TYPE16 dataset:
VMAC16 ICECOLLK ='ACTIVE*COLLKEY*VALUE'
Sep 29, 2020 ICETCBT ='TOTAL*TCB*TIME'
ICEFLBY5 ='ZSORT*WAS*USED?'
ICEZSRNU ='ZSORT*NON*USAGE*CODE'
ICEZSFLG ='ZSORT*FLAGS'
ICEZSPH1 ='ZSORT*PH1*ELAPSED'
ICEZSPH3 ='ZSORT*PH3*ELAPSED'
ICESSTC1 ='ZSORT*PH1*TCB TIME'
ICESSTC3 ='ZSORT*PH3*TCB TIME'
ICEZSDIA ='ZSORT*DIAGNOSTIC*AREA'
ICEZSDIV ='ZSORT*DIAGNOSTIC*VERSION'
Note: you must specify DFSORT parameter SMF=FULL to
populate these ZSORT variables (Not SHORT).
Thanks to Sri H Kolusu, IBM DFSORT, USA.
====== CHANGES THRU 38.163 ARE IN MXG 38.08 DATED Sep 28, 2020 ========
Change 38.163 Support for APAR OA59813 which adds RECOVERY BOOST so new
VMAC30 value BOOSTCLASS='RECO' is added to IPL or SHUT values.
VMAC7072
VMAC89
VMAC90A
VMAC99
Sep 23, 2020
Change 38.162 Datasets ZRBCHP and ZRBSCM had zero observations because
VMACRMFV the test for valid length needed -1 subtracted
Sep 22, 2020
Change 38.161 Macro always looked for PDB rather than the value of
PDBAUDIT PDBAUDIT as it should have. Now it looks for PDBAUDIT and
Sep 21, 2020 if not found on zOS looks in EXTFILES and issues a
LIBNAME statement and if that is successful starts over.
On z/OS, if not successful, or if the LIBNAME's engine is
sequential, or on ASCII, if the LIBNAME is not found,
PDBAUDIT is set to WORK.
Thanks to MP Welch, Bank of America, USA.
Thanks to Randy Hewitt, DXC Technology, USA.
CHANGE 38.160 Initial support for dataset DB2NETZA new variables:
VMACDB2 Q8STTMUD='MEMORY*AVAILABLE*USER DATA*MB'
Sep 18, 2020 Q8STTMPS='MEMORY*AVAILABLE*FOR SQL REQ*MB'
Q8STCQLS='CURRENT*QUEUE*LENGTH'
Q8STOFLW='SORT*OVERFLOWS*IN*BACKEND8'
Q8STABHR='ACCELERATOR*BUFFER*HIT*RATIO'
Q8STANUI='INBOUND*TRANSFER*RATE*KB/SEC'
Q8STANUO='OUTBOUND*TRANSFER*RATE*KB/SEC'
Q8STSA ='DISK SPACE*TEMPORARY*DATA*MB'
Q8STLSA ='DISK SPACE*LOG DATA*MB'
Q8STTDPS='SUCCESSFUL*QUERY*REQUESTS*THIS DB2'
Q8STEDPS='QUERY*REQUESTS*EXPIRED*THIS DB2'
Q8STTDPA='SUCCESSFUL*QUERY*REQUESTS*ALL DB2'
Q8STEDPA='QUERY*REQUESTS*EXPIRED*ALL DB2'
Q8STVLCS='REPLICATION*VELOCITY*LOG SEC*PERSEC'
Q8STLRCP='CPU TIME*INTEGRATED*SYNC'
Q8STLRZI='ZIIP TIME*INTEGRATED*SYNC'
Q8STZRZE='ZIIP TIME*ELIGIBLE'
Please contact support@mxg.com before using, because only
test data with one record was available, so the fields
that are accumulated could not be identified/validated.
This update was NOT in MXG 38.08/09/10, need test data.
CHANGE 38.159 MXG 38.07 only, 180 Syntax Error citing SP_NOBS=&NOBS,
VMXGPRAL due to an incorrect and undocumented &VARLST change.
Sep 16, 2020
Thanks to MP Welch, Bank of America, USA.
CHANGE 38.158 Format $MGSMFID didn't map SMF 119 subtypes 11, 12, 81,
FORMATS and 101-104, but those records were already supported in
Sep 16, 2020 VMAC119, although 101-104 subtypes are not written and
are only available thru an API.
Thanks to MP Welch, Bank of America, USA.
CHANGE 38.157 OUTFILE= defaults to BUILDMXG though the more common
UTILBLDP usage is INSTREAM and INSTREAM exists in all of the MXG
Sep 14, 2020 PROCs and AUTOEXECs. But if you fail to specify an
OUTFILE or the one you specified does not exist your job
would fail with FILE NOT FOUND errors. Now it is detected
and tells you what the problem was but it will still
ABEND and cause errors in your job.
Thanks to Arnold Kim, UPS, USA.
Thanks to George Carlquist, UPS, USA
Change 38.156 Dataset tokens for datasets TYP11924 and TYP11945 were
VMAC119 not in the _N119 list of all datasets.
Sep 14, 2020
Change 38.155 Debugging Option DKROCOND=WARN found many non-references
ANALDB2R that were typo's and did cause some variables to not be
IMACICVH kept, This was a long time on my to-do-list, now done.
IMACICWV -VMAC71 DELTATM is not created in WORK.TYPE71 but is added
UTILEXCL in the _S71 Sort Step, removed from KEEP= list for WORK.
VMAC110 -VMACCMFV variables starting with PRRE_G in CMFV82.
VMAC116 -VMACMVAO variables HHMM and YYYYMMDD were typos.
VMAC120 -VMAC85 R850SUB was spelled R50SUB.
VMAC71 -VMAC89 variable PRODMOD was spelled PROCMOD.
VMAC85 -VMAC92 variable SMF92DTY in TYPE9217, typo, not kept.
VMAC89 -VMAC99 typos in S99EEHMxx, S99SLET, S99CVCM in TYPE99SL.
VMAC92 -VMAC110 variable SSMVSSTM typo for SMMVSSTM, now kept.
VMAC99 -VMAC110 WBJCNRPL typo in CICSTRAN.
VMACCMFV -IMACICVH was not in PRODTEST with comment removed.
VMACMVAO -IMACICWV still had comment block in PRODTEST.
VMXGUOW -UTILEXCL variable SSMVSSTM typo for SMMVSSTM, now kept.
Sep 13, 2020 -VMAC110 variable MNGAPPLS typo for MNGAPPNS, now kept.
VMAC112 -VMAC110 SORTCPIPSMAXPERSIST underscores removed.
VMACWSF -VMAC110 IMSTM NRIMS removed from KEEP.
VMACCTCP -VMAC112 T112JOB replaced OMCIJOB, T112NUMB/OBJTYPE gone.
-VMAC116 WTSAWQCT typo for WTASWQCT.
-VMAC120 GMTOFFDOM typo for SM120GMT.
-ANALDB2R Variable QWHSSSID not on S102S083.
-VMXGUOW SPURIOUS WARNs are printed if MXGEXIMSG=YES.
-VMACWSF ACCCHOST typo ACCHOS, S1ODS typo ACCS1ODS.
-VMACCTCP CTCP32CA/B/C/D gone, CTCPSUBS typo SUBSYS.
Change 38.154 Labels for variables D06xxxxx in VMACIMS and GAVxxxxx in
VMAC99 VMAC99 had unbalanced quotes, which cause no error but
VMACIMS labels were not correct.
Sep 11, 2020
Change 38.153 Syntax revisions to prevent spurious log messages about
ASUMPRTR ancient DATETIME syntax.
TRNDPRTR
Sep 11, 2020
Thanks to Wayne Bell, UNIGROUP, USA.
Change 38.152 Support for APARs OA58729/OA58724 which added these new
VMAC74 Resource Monopoly fields in dataset TYPE74ST subtype 4:
Sep 11, 2020 R744SMRC='REQUESTS*DELAYED*MONOPOLY'
R744SMTM='SUMMED*QUEUE*TIME*FOR*MONOPOLY'
R744SMSQ='SUMMED*SQ OF*QUEUE TIME*MONOPOLY'
R744SMTO='OPS*QUEUED*MONOPOLY*AVOID'
R744SMHT='HI OPS*QUEUED*MONOPOLY*AVOID'
R744SMMN='MIN OPS*QUEUED*MONOPOLY*AVOID'
R744SMMX='MAX OPS*QUEUED*MONOPOLY*AVOID'
R744SMHN='MIN HI OPS*QUEUED*MONOPOLY*AVOID'
R744SMHX='MAX HI OPS*QUEUED*MONOPOLY*AVOID'
Thanks to Kurt Gramling, T-SYS, USA.
Change 38.151 Unused Change Number.
Change 38.150 If you did not have a //IPHOSTS or FILENAME IPHOSTS,
ANAL119 errors including divide by zero occurred. Now, if it
Sep 6, 2020 doesn't exist, an MXGWARN message is printed and the
processing continues creating the zero obs dataset.
Change 38.149 TYPE113 SM113TM was not an interval time and this would
ANALSIIS only occasionally match to SMFINTRV records. Now a new
Sep 6, 2020 interval TIMESTMP is calculated. SYNC59=YES added to the
parameter list.
Thanks to Pierre Pascal Joulin, SocGen, FRANCE.
Change 38.148 VMXGSUM calls were added to prevent errors or warnings
VMXGSUM when deleting work files that do not always exist.
Sep 10, 2020
Change 38.147 ACCTSORT=NO was not suppressing SORTS and caused
READDB2 accounting datasets to be sorted to output libname
Sep 12, 2020 instead of being directly written to libname when
PDBOUT=libname, and any redirects of output (eg.
DB2ACCTP to libname DB2ACCTP) were not honored.
-IFCIDS=DB2GBPAT was not recognized; now is.
Change 38.146 After _N7072, MACRO _WTY70 TYPE70 % was added.
SAGANAL
Sep 4, 2020
Change 38.145 If you are rolling up interval data and specify an
VMXGDUR interval LT the actual duration in the data the results
Sep 10, 2020 may not be what is expected. VMXGDUR now detects this
when the input data contains a DURATM variable and puts
an MXGNOTE on the log.
Change 38.144 Line 55 had "SAAV" text that was accidentally found in
TESTIBM2 MXG 38.05-38.07.
Aug 31, 2020
Thanks to Altino Pimentel, Express-Scrips, USA.
Change 38.143 -Variable CFISCVER in ZRBSCM is replaced by CFISCVERCH as
VMACRMFV that variable should have been input as $CHAR8, but was
Aug 28,2020 incorrectly INPUT as a datetime, and name must be changed
to prevent errors if merging old and new ZRBSCM.
-Variables CFISCMAX,CFISCFAU,CFISCIAU,CFISIUS were not
multiplied by 4096 to store bytes instead of KB.
Change 38.142 -When creating PDB.ASUMCELP and PDB.ASUMCEC datasets with
ASUM70PR CECINTRV=HOUR, from PDB.TYPE70/PDB.TYPE70PR with QTRHOUR
ASUM70WK intervals, the ASUMCELP/ASUMCEC has 23 valid hourly obs,
VMXG70PR with two additional obs, one from the last interval of
Aug 25, 2020 yesterdaq with (DURATM 15 min) and one from the last hour
of today (DURATM 45 min). To report only full hours, you
can select obs with IF DURATM GT 3400; in your reports.
-This new ASUM70WK program reads your WEEK.TYPE70/70PR to
create two weekly hourly WEEK.ASUMCEHR and WEEK.ASUMLPHR
(like CEC/CELP) with all intervals one hour. The two
partial intervals are not output, but they are from the
SMFDUMP time on the weekends and presumably unimportant.
-Enhancements were needed in VMXG70PR.
-The PDB= argument for the libname of input datasets was
incorrectly ignored, and the &PTY70 and &PTY7072 tokens
were used. Now it will be used, but VMXG70PR checks for
the existence of TYPE70 & TYPE70PR if PDB= is nonblank,
and terminates if either has zero obs or isn't there.
-New PDBOUT= argument names the output LIBNAME for the
two new datasets, if argument is non-blank.
-OUTCODE70PR= Your SAS code that will let you control
what observations are output to ASUM70PR.
-OUTCODE70LP= Your SAS code that will let you control
what observations are output to ASUM70LP.
-OUTCODECEC = Your SAS code that will let you control
what observations are output to ASUMCEC/ASUMCEHR
-OUTCODECELP= Your SAS code that will let you control
what observations are output to ASUMCELP/ASUMLPHR
-OUTCODE70GL= Your SAS code that will let you control
what observations are output to ASUM70GL.
-OUTCODE70GC= Your SAS code that will let you control
what observations are output to ASUM70GC.
-The ASUM70WK defaults to PDB=WEEK, PDBOUT=WEEK, and
the two OUTCODEs use IF DURATM GT 3400; to only create
full hourly data for the week.
%VMXG70PR (PDB=WEEK,INTERVAL=QTRHOUR,CECINTRV=HOUR,
OUT70LP=WEEK.ASUMLPHR,
OUTCODE70PR=IF DURATM GT 3400;,
OUTCELP=WEEK.ASUMCEHR,
OUTCODECELP=IF DURATM GT 3400;,
OUTCEC=_NULL_,
OUT70PR=_NULL_,
OUT70GL=_NULL_,
OUT70GC=_NULL_
);
====== CHANGES THRU 38.141 ARE IN MXG 38.07 DATED Aug 22, 2020 ========
Change 38.141 -Processing CICS Statistics records in BUILDPDB can be
EXCICLDR very CPU/Elasped intensive for very little daily value.
EXCICSDR The SMF 110 Subtype 2 records are tactical data for the
EXCICSMD resolution of CICS problems, which happen so rarely that
EXCICSMT it would be better to only process them with TYPS110-2 if
EXCICTCR and when your CICS folks actually have need of that data.
EXCICXMR IBM CICINTRV dataset default 3 hour interval is also not
SCICSORT much use for tactical analysis. To suppress processing
VMXGCICI of the statistics records in BUILDPDB/TYPE110
Aug 21, 2020 you can insert this at the top of your //SYSIN
Aug 21, 2020 %LET MACFILE=
%QUOTE( IF ID=110 AND SUBTYPE=2 THEN DELETE;);
With UTILBLDP, SUPPRESS=CICSSTAT will suppress sorts and
CICINTRV and all of the Statistics datasets will have
obs so they take no space, but will exist so subsequent
reports won't fail.
And if you ONLY want CICSTRAN with no other account nor
statistics datasets, add this and the MACFILE to SYSIN.
%LET MACKEEP= %QUOTE
(_N110 _S110 MACRO _WCICTRN CICSTRAN.CICSTRAN % );
%INCLUDE SOURCLIB(TYPE110);
(and always have a blank between percent and paren).
-For sites that do use those data, there are large counts
of observations created during intervals of no activity
that increased CPU, elapsed time and disk space needed.
For example CICXMR created 1,173,518 obs in WORK.CICXMR
but only 4061 obs were output in PDB.CICXMR. With this
change, these seven datasets are only output in WORK if
there was activity: FCR LDR SDR SMD SMT TCR XMR, but that
test can be tailored to create all obs in the EXCICxxx.
-%INCLUDE SOURCLIB(UCICSCNT) will report how many obs were
written to SMF and not output for each STID. MXG member
IMAC110 documents the CICxxxxx dataset for each STID.
-This change significantly reduced the CPU and elapsed
time for a 5GB SMF file with lots of "idle" hours, with
lots of regions, ET from 17:24 to 6:21, CPU 517 to 258.
There were 104 Regions and the data was from a Monday.
Thanks to Vijay Singh, IBM, NEW ZEALAND.
Change 38.140 Variable CMM, CMM BALOON is added to XMUCDSYS dataset.
VMACXAM
Aug 20, 2020
Thanks to Raymond J. Smith, OPTUM, USA.
Change 38.139 Change 38.037, in MXG 38.02 MQMQUEUE these variables
VMAC116 QWHCNID QWHCOPID QWHCTASK QWHCTNO QWHCTRN
Aug 17, 2020 were in the Change text, but were dropped from the KEEP
list; the KEEP list now includes them.
Thanks to Pietro Rosella, Canadian National Railway, CANADA.
Change 38.138 Unused Change Number
Change 38.137 Support for APAR OA57466 which adds variables to TYPE26J2
VMAC26J2 SMF26BYU='TOTAL JOB*UNCOMPRESSED*BYTES'
Aug 15, 2020 SMF26BYC='TOTAL JOB*COMPRESSED*BYTES'
SMF26CCT='COMPRESSED*DATASETS'
SMF26ECT='ENCRYPTED*DATASETS'
Change 38.136 If you rerouted CICXMG to PDB all sorts of strangeness
VMXGCICI occurred since VMXGCICI was looking for CICXMR rather
Aug 13, 2020 than CICXMG.
Thanks to Nilton de Oliveira Mello Junior, IBM, Brazil.
Change 38.135 -Change 38.128 wasn't released, but a severe error message
ASMRMFV RMFV016S >>>SEVERE: RMF III TABLE ID MISMATCH -
Aug 13, 2020 EXPECTED: CPUG3 ACTUAL: CPUG3 (C3D7E4C7F3X)<<<
incorrectly appears. A table id validation test branch
was incorrect.
Change 38.134 -Example added to output ALL Service/Report Classes even
ASUMMIPS those with CPUTM=0, which are not normally output.
Aug 11, 2020
Thanks to Nestor D Rossi, BANCOGALICiA, ARGENTINA.
Change 38.133 -Support for IMS LOG Record 67D0 Subtype 6 creates new
BUILDIMS dataset IMS67D006.
EX67D006 -BUILDIMS requires REPORT=YES (to avoid a MAJOR rewrite)
IMACIMS so it is now always forced.
VMACIMS
VMXGINIT
Aug 14, 2020
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 38.132 DCOLLECT ABEND B37 (SPACE). New UNIX fields were added in
EXDCOBKU Change 38.102 (MXG 38.05), adding 1231 bytes to each obs,
IMACDCOL in DCOLBKUP, Unix or Not. The variables are now removed
VMACDCOL from DCOLBKUP and new DCOLBKUU dataset is now created for
VMXGINIT Unix dataset information.
Aug 7,2020
Thanks to Bill Davis, Transamerica, USA.
Change 38.131 Unused Change Number
Change 38.130 Support for Thruput Manager IZWS fields.
VMACTPMX
Aug 5, 2020
Thanks to Kurt Gramling, T-SYS, USA.
Change 38.129 -Writing SMF with SYNC=59 has NEVER BEEN RECOMMENDED, it
VMXG70PR was required with MICS, and while MXG summarization can
Jul 30, 2020 take it into account, there is intrinsic inaccuracy as
Aug 13, 2020 only SYNC=0 will provide exact 00,15:30:45 intervals.
The hourly summarization in VMXG70PR forces those exact
interval start to the exact value, but other RMF datasets
will still have 59:14:29:44 starts. This change creates
the new OUTCODE70PR argument for VMXG70PR, which you can
add in your ASUM70PR member's invocation of VMXG70PR:
%VMXG70PR (PDB=PDB,INTERVAL=QTRHOUR,CECINTRV=HOUR,
OUTCODE70PR= STARTIME=STARTIME-60;
SMF70GIE=SMF70GIE-60;);
-A blank TITLE was added at the end to prevent carry.
Thanks to Linda Berkeley, DISA Mainframe, USA.
Change 38.128 -ASMRMFV Field Data Filter (FDF) support for the RMF III
ADOCRMFV XCF Activity Data Table (XCFG3) and an IMPORTANT FDF FIX.
ASMRMFV -The Field Data Filter (FDF) feature of RMF III was added
Jul 30, 2020 in MXG Change 37.089 and allows you to filter raw RMF
reducing the size of the created RMFBSAM file. You can
filter table entries based on one or more numeric and/or
character fields, and is intended for advanced MXG users
building ad hoc data collection of RMF III data.
-ASMRMFV FDF can fail to correctly translate X'00'
characters to X'40' blank characters for RMF III field
names in FDF expressions that can contain nulls. This can
cause filter comparisons to be FALSE instead of TRUE.
-The example JCLRMFV/JCLCRMFV/JCLDRMFV members have been
integrated into Sections 48, 49, 50 in ADOCRMFV, with new
FDF examples; the old members are pointers to ADOCRMFV.
- J is now an alias for SCM table selection.
- -J is now an alias for SCM table exclusion.
-See Change 38.135 correction; 38.128 was never released.
-Following updated or added in the ADOCRMFV documentation
member:
Section Contents
------- -------------------------------
0 Contents
2 Terminology
3 Execution JCL
5 Input Data Selection Parameters
32 Filtering The ASIG3 Table
33 Filtering The CPDG3 Table
34 Filtering The CSRG3 Table
35 Filtering The DSIG3 Table
36 Filtering The DVTG3 Table
37 Filtering The ENCG3 Table
38 Filtering The ENTG3 Table
39 Filtering The GEIG3 Table
40 Filtering The OPDG3 Table
41 Filtering The PCIG3 Table
42 Filtering The SCMG3 Table
43 Filtering The SPGG3 Table
44 Filtering The SSHG3 Table
45 Filtering The XCFG3 Table
46 Filtering The ZFXG3 Table
47 ASMRMFV Execution and Methods Overview
48 PDB Build Examples With Direct JCL Method
49 PDB Build Examples With TSO Clist Method
50 PDB Build Examples With Dynamic Method
51 Summary
-TUTORIAL:
This level of ASMRMFV introduces the concept of
Independent Data Sections when using FDF.
An Independent Section is an ASMRMFV term for a RMF III
data section containing data unrelated to other sections
in the same RMF Monitor III table. Examples of this are
the Group Data, Path Data, and System Data Sections of
the XCFG3 table.
ASMRMFV does not support logical FDF ANDing of filters
from two different Independent Sections because the data
is not logically related.
ASMRMFV FDF processes each Independent Section
separately. If ANDIF= expressions for 2 fields in two
different Independent Sections occur FDF will bypass any
IF expressions for fields not contained in the section
being currently processed.
Data dictionary sections in ADOCRMFV for tables now
identify the Section when Independent Sections are
applicable an RMF III table.
Change 38.127 Using ANAL119 with PDB=SMF without a PDBOUT=, 0 OBS were
ANAL119 found for the FTP report. Now if PDBOUT= is null PDB is
Jul 30, 2020 set to &MXGWORK.
Thanks to Jennifer D. Ayers, West Virginia Government, USA.
Change 38.126 When SMF Logger outputs sysplex data for multiple systems
VMAC7072 records are interleaved, so it is no longer possible to
VMXGINIT retain TYPE70 variables like CECSER/CPCMODEL from the 70
Jul 29, 2020 into the TYPE72GO dataset, where they are frequently
missing values. This change revises the _STY72GO dataset
sort macro to sort and merge the two datasets to populate
CECSER and CPCMODEL whenever possible (if a 70 ends an
SMF dataset, the subsequent 72 read tomorrow won't have a
matching 70 even with the new sorting logic).
-All of the 7072 processing programs that sort and create
PDB datasets, like BUILDPDB/BLDSMPDB/UTILBLDP/TYPS7072
already invoke the _STY72GO macro so this change will be
transparent. However, if you use only TYPE7072 to write
only to //WORK, you will need to use this syntax to sort
and create the correctly populated TYPE72GO dataset:
%INCLUDE SOURCLIB(TYPE7072);
%LET PTY70=WORK;
%LET PTY72GO=WORK;
_STY72GO;
RUN;
-And new macro variable &SSTY72GO is added in _STY72GO so
you can insert code to create new variables from the
CECSER/CPCMODEL variables into your TYPE72GO dataset.
Thanks to Kurt Gramling, T-SYS, USA.
Change 38.125 Change 38.117 test for QLSTVRSN='000001' was changed to
VMACDB2 'F0F0F0F0F0F1'x to detect new data on EBCDIC or ASCII.
VMAC102
Jul 26, 2020
Change 38.124 -RMF III datasets ZRBXCG, ZRBXCP and ZRBXCS had many dupes
VMACRMFV because the offset was not updated and so only the first
Jul 26, 2020 segment was read and re-read and output XCFxDATN times.
Jul 30, 2020 Caused incorrect ZRBXCG INVALID TRIPLET messages.
-Dataset ZRBZFS variable ZFX_FS_AGGRREADKBYTES corrected.
====== CHANGES THRU 38.123 WERE IN MXG 38.06 DATED Jul 25, 2020 ========
Change 38.123 Change 38.121 overlooked one dataset causing the refresh
VMXGCICI on Saturday morning.
Jul 25, 2020
Change 38.122 Some CICS Statistics datasets (CICxxxxx) were incorrectly
VMAC110 sorted because the %INCLUDE SOURCLIB(SCICSORT) statement
Jul 25, 2020 was accidentally deleted.
Change 38.121 If you tailored CICS statistics datasets and some were in
VMXGCICI WORK and some were in PDB, a dataset not found error due
Jul 25, 2020 to MXG expecting all in one place. Individual locations
now are tested, and the sorts commented out.
====== CHANGES THRU 38.120 WERE IN MXG 38.06 DATED Jul 24, 2020 ========
Change 38.120 Variables decoded from SMF30SLM weren't kept in SMFINTRV:
VMAC30 SMF30SLMRB SMF30SLMRA SMF30SLMSB SMF30SLMSA SMF30SLMML
Jul 24, 2020 SMF30SLMBY
Thanks to Randy Hewitt, DXC Technology
Change 38.119 Type 92 subtype 16 records are the same as subtype 11 so
VMAC92 both subtypes are now output in TYPE9211 and SMF92STP is
Jul 23, 2020 kept to identity which subtype was output.
Thanks to Nathan Lowenthal, CITIGROUP, USA.
Change 38.118 -ASMRMFV FDF message RMFV088I can be incorrectly formatted
ASMRMFV showing the hex value of a number in an IF expression
JCLASM3 as zeros. Processing is not impacted. The message only
Jul 21, 2020 appears when FDF is used.
-After Change 38.082 to reduce SYSOUT output from an
ASMRMFV assembly condition code 0002 can occur after an
assembly. The XREF(SHORT) option in the JCLASM3 sample
member is no longer required. ASMRMFV will override this
value to NOXREF, so no JCL change is required.
Thanks to Randy Hewitt, DXC Technology
Change 38.117 Support for DB2 APAR PH16111 adds location variables to
VMACDB2 the QLST segment,in IFCID 365 in dataset T102S365 and in
VMAC102 SMF 100 Subtype 1 datasets DB2STAT0/DB2STATS/DB2STATR.
Jul 21, 2020
Thanks to Harald Seifert, Huk-Coberg, GERMANY.
Change 38.116 Support for BMC Mainview for CICS Version 7.1 (COMPAT).
VMACMVCI -New variables in dataset CMRDETL:
Jul 20, 2020 T6EXSVPT='TOTAL*PASSWORD*VERIFY*TIME'
T6EXSVPN='TOTAL*PASSWORD*VERIFY*COUNT'
T6EXSVPF='TOTAL*PASSWORD*VERIFY*FLAG'
T6EXSVBT='TOTAL*BASIC AUTH*VERIFY*TIME'
T6EXSVBN='TOTAL*BASIC AUTH*VERIFY*COUNT'
T6EXSVBF='TOTAL*BASIC AUTH*VERIFY*FLAG'
T6EXSVKT='TOTAL*KERBEROS*VERIFY*TIME'
T6EXSVKN='TOTAL*KERBEROS*VERIFY*COUNT'
T6EXSVKF='TOTAL*KERBEROS*VERIFY*FLAG'
T6EXSVJT='TOTAL*JSON JWT*VERIFY*TIME'
T6EXSVJN='TOTAL*JSON JWT*VERIFY*COUNT'
T6EXSVJF='TOTAL*JSON JWT*VERIFY*FLAG'
T6ESMMWT='TOTAL*Z/OS SOS*WAIT*TIME'
T6ESMMWN='TOTAL*Z/OS SOS*WAIT*COUNT'
T6ESMMWF='TOTAL*Z/OS SOS*WAIT*FLAG'
-Complete revision of MXG Code for CMRFPROG.
T6EPGTELCN='PROGRAM*ELAPSED*COUNT'
T6EPGTELTM='PROGRAM*ELAPSED*TIME'
T6EPGCNT='PROGRAM*SUMMARIZATION=1'
T6EPGNM ='PROGRAM*NAME1'
Change 38.115 Support for Optional CICS Field HUMTRAN with multiple
UTILEXCL INPUT lengths of $16 and $24. The length of variable
VMAC110 HUMTRAN is $24.
VMXGINIT
Jul 16, 2020
Change 38.114 New CICS datasets SMF 110 Subtype 1 MNSEGCL=5 Resource
EXCICRDU class datasets:
EXCICRDW DDDDD Dataset Description
IMAC110 CICRDU CICSRDUR URIMAP Resource
VMAC110 CICRDW CICSRDWB WEBSVC Resource
VMXGINIT
Jul 16, 2020
Change 38.113 SMF records that EXCLUDE ABCODEC, field 114, have a four
UTILEXCL byte misalignment when UTILEXCL is used, so this change
VMXGINIT created macro variable MXGCICSABCODELN which could be set
Jul 15, 2020 in UTILEXCL SYSIN to 4 to change INPUT ABCIDEO $EBCDIC8.
Jul 26, 2023 to EBCDIC4. But this change was replaced by Change 41.063
which detects the EXCLUDE for you and creates the correct
INPUT ABCODE $EBCDIC4. statement.
Thanks to Bradley Leis, TELUS, CANADA.
====== CHANGES THRU 38.112 WERE IN MXG 38.05 DATED Jul 15, 2020 ========
Change 38.112 Support for DFSMS APAR OA59510 OA59830 collects UNIX file
VMACDCOL Backup information in DCOLLECT, new DCOLBKUP variables
Jul 14, 2020 UBUNIX ='UNIX*FILE*BACKUP?'
UBUNIXDIR='UNIX*FILE OR*DIRECTORY?'
UBENCRYPTA='DATASET*ENCRYPTION'
UBENCRPT='ENCRYPTION*TYPE*0100-AES256*FFFF-NO'
UBENCRPL='ENCRYPTION*KEY*LABEL'
UBPATHL='LENGTH*OF THE*FILENAME'
UBUPATHN='UNIX*PATH*NAME'
Change 38.111 TYPE1415 Space Allocation Unit is set to SPACE='AVG' for
VMAC1415 AVGREC when JFCBCTRI='90'x and based on values in SMF
Jul 13, 2020 that matches the job's JCL. Previously these records had
SPACE='TRK' because the '80'x bit was detected.
Thanks to Bruce Sloss, PNC, USA.
Thanks to Walt Unterbrink, PNC, USA.
Change 38.110 -38.05 Early Adopter, test IF LENPDGS GE 2296 in line 2094
VMAC71 should be IF LENPDGS GE 2440. This could cause a STOPOVER
Jul 12, 2020 INPUT EXCEEDED RECORD LENGTH error.
Change 38.109 -38.05 Early Adopter, period missing in VMAC98 line 876.
VMAC98 Should be $CHAR16. (with the period).
Jul 12, 2020
Change 38.108 -RMF III dataset ZRBENC PROC SORT removed more duplicates
VMACRMFV than intended; the _BZRBENC sort list needed the two
Jul 16, 2020 added variables at the end:
MACRO _BZRBENC SYSPLEX SYSTEM SSHTIBEG EDEUSER ENCTOKEN%
-Variable SSHGOSYN='GATHERER*SYNC*OPTION?' is added to all
datasets.
-Data sets ZRBXCG, XRBXCP, ZRBSCS have added variables
SSHRMFVN SSHSMPNR
XCFVER XCFSID XCFPART XCFREL XCFSYSN CSFSTAT XCFESTAT
Thanks to Kurt Gramling, TSYS, USA.
Change 38.107 Some macro variables were unresolved because they needed
ANAL119 to %GLOBALed.
Jul 11, 2020
Thanks to Jennifer D. Ayers, West Virginia Government, USA.
TECHNOTE - z/OS ONLY
Jul 8, 2020
The PDB library written by BUILDPDB CAN'T BE ON TAPE, neither
REAL TAPE or VIRTUAL TAPE or V9SEQ libraries on DASD.
We have NEVER recommended the PDB be written directly to TAPE
because BUILDPDB reads and writes to and from //PDB, multiple
times, and since sequential datasets have no directory, each
action requires a rewind to the beginning of the dataset and a
read until it finds the desired dataset, increasing run time.
And PROC DATASETS fails with ERROR: Proc Datasets is not able
to process a sequential library. Consider using PROC CONTENTS
or PROC COPY instead.
If you want your PDB on TAPE, point //PDB to Temporary DASD,
then PROC COPY to TAPE dataset at the end.
The more insidious issue is the potential for lost data.
Assume that you want to create a SAS data library with
datasets A B C D and then find that you need to rewrite
dataset B to add a variable. You can do it but you would then
lose datasets C and D PERMANENTLY. If you try to access them
you will get a DATASET x NOT FOUND error.
SAS Technical Support documentation for sequential libraries:
Due to the nature of sequential devices, SAS allows only two
types of operations with members of a sequential bound
library:
-reading an existing member and writing a new copy
-writing a new copy of a member to the library.
The following types of operations are not
supported for sequential access bound libraries.
-Having multiple members in the library open at same time
-Updating the contents or attributes of a member of the
library
-Renaming or deleting a member of the library.
-Using BLKSIZE GT 32760 with SAS 9.4M1 or earlier which did
not support LBI. Error is ABEND 013 Return E1.
-PROC DATASETS is not able to process a sequential dataset.
CAUTION
SAS deletes all members of a sequential bound library that are
subsequent to the library member that you replace.
By default, when writing a member of a sequential bound
library, SAS scans the entire library from the beginning to
determine whether a member having the specified name already
exists in the library. If such a member already exists in the
library, then the new copy of the member is written starting
at the position in the library data set where the old copy of
the member began, and all subsequent members of the library
are deleted. If the specified member does not already exist in
the library, it is appended to the end of the library. This
behavior is not influenced by the REPLACE system option
because NOREPLACE is not supported by the TAPE engine.
When the FILEDISP=NEW data set option is specified for a
member to be written to a sequential access bound library, SAS
replaces all of the members that previously existed in the
library, even if they were protected by an ALTER password. The
ALTER password is not checked even for the member being
replaced.
When the COPY procedure is used to write members to a
sequential access bound library, the rules regarding member
replacement (discussed in the previous topic) apply only to
the first member being processed by a COPY statement or PROC
COPY invocation. All other members involved in the COPY
operation are appended to the end of the library data even if
they already exist in the library. Therefore, it is possible
to cause a library to contain two copies of the member, only
the first of which is recognized. You should plan all COPY
operations carefully so that you avoid this outcome.
Some specialized SAS procedures repeatedly process a group of
observations that have the same value for a specific variable.
This situation requires SAS to interrupt its sequential access
pattern and reposition to a previous location in the library
data set. However, SAS does not support repositioning to a
location on a previous volume of a multi-volume tape data set.
When this situation occurs, SAS issues the following error
message:
ERROR: A POINT operation was attempted on sequential library
SEQLIB.
A volume switch has occurred on this library since the last
NOTE operation, making the POINT results unpredictable.
Should this situation occur, you can avoid the limitation by
copying the member to a library on disk.
When using the LIBNAME statement to dynamically allocate SAS
libraries on tape, it is not possible to simultaneously
allocate multiple MVS data sets on the same tape volume.
Therefore, it is necessary to use the SAS LIBNAME CLEAR
statement to deassign the library before you attempt to assign
another MVS data set on the tape.
The mode in which SAS opens the library data set is primarily
governed by the type of access that is being performed. When
reading a member, listing the members in the library, or
retrieving information about the library, the library data set
is opened for INPUT. When writing a member, the library data
set is opened for INOUT (unless DISP=NEW and the data set has
not been previously opened. In that case, OUTIN is used). SAS
does not write to a library that is allocated with DISP=SHR or
LABEL=(,,,IN), issuing an ERROR message instead. Before
opening the library data set, SAS first checks the RACF
authorization, but only for libraries that reside on disk, and
only if NOFILEAUTHDEFER is in effect.
Thanks to Jill Ackerman, SAS Technical Support, USA.
Change 38.106 Support for APAR OA59330 new variables in TYPE7002:
VMAC7072 R702FPTI='INSTRUCTIONS*TO TRANSLATE*USING FPE'
Jul 7, 2020 R702FXEC='CALLS TO*ENCIPHER*USING*FFX'
R702FXEB='BYTES*ENCIPHERED*USING*FFX'
R702FXEI='INSTRUCTIONS*TO ENCIPHER*USING*FFX'
R702FXDC='CALLS TO*DECIPHER*USING*FFX'
R702FXDB='BYTES*DECIPHERED*USING*FFX'
R702FXDI='INSTRUCTIONS*TO DECIPHER*USING*FFX'
R702FXTC='CALLS TO*TRANSLATE*USING*FFX'
R702FXTB='BYTES*TRANSLATEED*USING*FFX'
R702FXTI='INSTRUCTIONS*TO TRANSLATE*USING*FFX'
R702DQGC='CALLS TO*GENERATE*QSA DIGITAL*SIGNATURE'
R702DQVC='CALLS TO*VERIFY*QSA DIGITAL*SIGNATURES'
Change 38.105 Support for May 2020 SMF Manual Changes (still-40).
EXTY9040 -TYPE02 Records
FORMATS -Subtype 1 new variables in TYPE0201
VMAC0203 SMFGFLG2='RESERVED?'
VMAC25 SMFGFLG2='APAR OA55526*APPLIED?'
VMAC30 SMFGFLG2='SELF*DEFINING*SECTION?'
VMAC42 There is a new Self Defining Section "triplet" for the
VMAC7072 new ARECSIGN section, I need data to decode.
VMAC71 -Subtype 2 new variables in TYPE0201
VMAC89 SMFIFLG24='RESERVED?'
VMAC90A SMFIFLG25='NOT DOCUMENTED?'
VMAC98 SMFIFLG26='APAR*OA55526*APPLIED'
VMAC99 SMFIFLG27='SELF*DEFINING*SEGMENT?'
VMAC106 There is a new Self Defining Section "triplet" for the
VMXGINIT new ARECSIGN section, I need data to decode.
Jul 3, 2020 -TYPE 25 SMF Records
-Label changed for TYPE25 SMF25NTF.
-TYPE 30 SMF Records
-ZEDC section
-z15 changes:
SMF30_US_COMPRREQ only counts authorized request
SMF30_US_DEF_COMPROUT, INF_DECOMPROUT, DEF_COMPRATIO
are now always zero.
-Variables added to TYPE30_V/_4,_5,_6:
BOOSTACTIVE='BOOST*ACTIVE*ZIP*SPEED*BOTH'
BOOSTCLASS='BOOST*CLASS*IPL*SHUTDOWN'
-TYPE 42 Records
Variable S42VTUNC count is zero with APAR OA55709.
There is no volume metrics section when there are no
SSCH instructions for this volume, and no system I/O
section when no system I/O to this volume, and no
background activity section when there no background
activity.
-TYPE 70 records
-Subtype 1
New variable SMF70CPC_TYPE (8561) to TYPE70 dataset.
-Subtype 2
New FORMATS value 0Dx:CEX7C for R7023CT/R7024CT/R7025CT
crypto type in TYPE7002/TYPE70X2/TYPE7Y3 datasets.
-TYPE 71 SMF Records
New variables in TYPE71 dataset:
SMF71M6C='MIN FRAMES*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71X6C='MAX FRAMES*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71A6C='AVG FRAMES*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71M6F='MIN FIXED*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71X6F='MAX FIXED*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71A6F='AVG FIXED*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71M6B='MIN 24-BIT*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71X6B='MAX 24-BIT*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71A6B='AVG 24-BIT*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71M6A='MIN AUXSLOTS*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71X6A='MAX AUXSLOTS*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71A6A='AVG AUXSLOTS*BACK*64-BIT*SHARED*PAGE GROUPS'
SMF71M6S='MIN SCM BLOCKS*BACK*64-BIT*SHARED*PAGE GROUPS
SMF71X6S='MAX SCM BLOCKS*BACK*64-BIT*SHARED*PAGE GROUPS
SMF71A6S='AVG SCM BLOCKS*BACK*64-BIT*SHARED*PAGE GROUPS
SMF71M6T='MIN 64-BIT*SHARED*PAGE GROUPS'
SMF71X6T='MAX 64-BIT*SHARED*PAGE GROUPS'
SMF71A6T='AVG 64-BIT*SHARED*PAGE GROUPS'
-TYPE 72 SMF RECORDS
-Variables BOOSTACTIVE and BOOSTCLASS added to TYPE72GO.
(In 70, BOOSTINFO flags partial boost, but there is no
field for partial boost in 72).
-TYPE 89 SMF Records
-Variables BOOSTACTIVE and BOOSTCLASS added to TYPE89,
but there are no bits for full boost, only partial.
-TYPE 90A SMF Records
- New subtype 40, SET BOOST, creates TYPE9040 dataset.
-TYPE 98 SMF Records (Last updated 2017!)
-Variables added to TYPE9801 dataset:
SMF98_CVTLSO= 'LEAP*SECOND*OFFSET'
SMF98_ECVTLDTOCH ='ETOD*LOCAL*OFFSET*CHAR'
SMF98_ECVTLSOCH ='ETOD*LEAP*SECOND*OFFSET*CHAR'
-The Workload Interaction Correlator WICDATA records
require more documentation from each exploiter and
won't be decoded without actual data records:
"These mappings are incomplete and depend on the
particular data to be recorded for each exploiter.
Use the mapping produced by the subtype holder."
-TYPE 99 SMF Records
-Variable added to TYPE99_1 - BOOSTINFO
-Variables TOD added to TYPE99EH subtype 14.
S99EVCMHWLEVEL='HW*LEVEL'
S99EEVCMDURRTOD='CURRTOPO_TOD'
-Await a USER with need+data for new subtypes 9 and 10
and updates to subtype 12.
-TYPE 106 SMF Records
-New FORMAT MG106CT values for SMF6ACTP=CONNECT*TYPE.
-TYPE 124 SMF Records
- Await a USER with need+data for new subtypes 2-5.
Change 38.104 Dataset XAMUSR variable USERTYPE='ACCT' is now set if the
VMACXAM value in the record was A.
Jun 30, 2020
Thanks to Randy Hewitt, DXC Technology, USA.
Change 38.103 -MXG 38.03/38.04 TYPE7072 fails if PDB is on TAPE, with
E2TY70 ERROR: DATASET PDB.TYPE70PR NOT FOUND (after it had been
VMAC7072 created, and there was no DELETE statement on the log).
Jun 30, 2020 -Changing from TAPE to DASD accidentally circumvents the
error that was introduced in Change 38.055.
-But this correction in VMAC7072 is INCOMPATIBLE requiring
you to see IF YOU HAVE MEMBER E2TY70 in your tailoring
'USERID.SOURCLIB' library, as you must change _LTY70 to
_WTY70 in that member. Fortunately, I doubt any site
has actually ever used that obscure exit member, and with
this change, the MXG default is _WTY70.
-But we have NEVER recommended the PDB library be on
tape for the BUILDPDB process for several reasons:
-tapes have no directory, so the full tape has to be
read from the start to find each dataset, and
-BUILDPDB has many datasets that are written to and
then read from the PDB library, causing many rewinds
which increases the job run time.
Thanks to Silambarasan Shanmugam, IBM, INDIA.
Change 38.102 Support for Thruput Manager TMT7123/TMT7124 JUL 2020.
VMACTPMX Compatible Changes:
Jun 26, 2020 -New variables in dataset TPM10:
TPMCMSTA='TENANT*4HRA*MSU PER*HOUR'
TPMCMSTI='TENANT*INT USE*MSU PER HOUR'
-New variables in dataset TPMSLM
TPMSLJF2='MISCELLANEOUS*FLAGS*2'
TPMSLJF3='MISCELLANEOUS*FLAGS*3'
TPMSLJFM='MISCELLANEOUS*FLAGS*M'
These flags are decoded in the comments.
-See Change 38.132 which creates DCOLBKUU for Unix.
Change 38.101 The TYPE42DS original default display FORMAT TIME13.3 for
VMAC42 duration variables to display milliseconds is changed to
Jun 26, 2020 TIME13.6 to display the full microsecond resolution that
has been in the stored values for decades (MVS/ESA?).
Thanks to John Burg, IBM, USA.
Thanks to Mark Rader, IBM, USA.
Thanks to Kathleen C McManus, Aetna, USA.
Change 38.100 Support for OAM Cloud Tier
EXTY8500 -New variables in TYPE85AC dataset:
FORMATS R85INST ='INSTANCE*ID'
IMAC85 R85CLDID='ID OF*ENTRY IN*CLOUDID*PROVIDER'
VMAC85 R85CINST='CLOUD*INSTANCE*ID'
VMXGINIT -Many new variables added to TYPE85ST:
Jun 23, 2020 R85PEWO R85PERO R85PEDO R85PDWB R85PDRB R85PDDB
Aug 14, 2020 R85POWB R85PORB R85PODB R85PTWB R85PTRB R85PTDB
R85BOWB R85BORB R85BODB R85BTWB R85BTRB R85BTDB
R85B2OWB R85B2ORB R85B2ODB R85B2TWB R85B2TRB R85B2TDB
R85RCLB R85PUWB R85PURB R85PUDB R85PEWB R85PERB
R85PEDB R85BOAO R85B2OAO R85BTAO R85B2TAO R85BOAB
R85B2OAB R85BTAB R85B2TAB R85PCWB R85PCRB R85PCDB
R85PCWO R85PCRO R85PCDO
-New variables in TYPE85SO dataset:
R85DSL ='DISK*SUBSYSTEM*RECOVERED*OBJECT'
R85TCLID='ID OF*ENTRY IN*CLOUDID*TABLE'
-New variable in TYPE85IB dataset:
R85SCLID='ID OF*ENTRY IN*CLOUDID*TABLE'
-New variable in TYPE85RE dataset:
R85CLDID='ID OF*ENTRY IN*CLOUDID*TABLE'
-New dataset TYPE8500 for new subtypes 100,101,102,103
dddddd dataset description
TY8500 TYPE8500 LCS CLOUD WRITE READ DELETE
with new cloud variables
R850CID ='ID OF*ENTRY IN*CLOUDID*TABLE'
R850SGN ='OBJECT*STORAGE*GROUP*NAME'
R850COLN='COLLECTION*NAME'
R850OBJN='OBJECT*NAME'
R850INST='INSTANCE*ID'
R850FLGS='PROCESSING*FLAGS'
R850OLEN='OBJECT*LENGTH'
R850OOFF='OBJECT*OFFSET'
R850LIQT='LCS*INPUT*WORK*QUEUE*TIME'
R850LDQT='LCS*DISPATCHER*QUEUE*TIME'
R850LEQT='LCS*EXECUTION*QUEUE*TIME'
R850LCLT='LCS*CLOUD*ACCESS*TIME'
R850RC ='LCS*RETURN*CODE*TIME'
R850RS ='LCS*REASON*CODE*TIME'
and R850SUB identifies the Subtype/Event
Thanks to Scott Rowe, SSA, USA.
Change 38.099 Sorts of CICS stats sometimes calculated negative DURATM
VMAC110 values for CICS statistics datasets. We also found that
SCICSORT some no longer needed to be deaccumulated. The sort order
UTILBLDP was changed to correct the DURATMs and the DIF logic was
VMXGCICI removed. In addition, only the records which contained
Jul 3, 2020 activity are now output. VMXGCICI was revised to remove
sorts and DIFs that were being done and many steps were
eliminated since it is now a single VMXGSUM execution.
-The CICLDR dataset was missing obs and incorrectly
and accidentally had a number of LDGxxxxx variables
that are now removed. Note that the new logic will
only output observations that had activity. For LDR,
there were 1,098,909 WORK.CICLDR observations but
only 2982 obs were in PDB.CICLDR that actually had
any activity.
-CICFCR dataset now only contains obs with activity,
with 15195 WORK.CICFCR and only 214 PDB.CICFCR.
-Protection for new MNSEGCL=5 5th and 6th triplets for
URIMAP and WEBSVC prevents a STOPOVER, but the two new
datasets were not created until Change 38.114.
Change 38.098 BMC SMF 74 CMF records variable R744STRC was zero, now
VMAC74 corrected by PTF BQM1658 for 6.1, BQM1659 for 6.2.
Jun 23, 2020 Note that MXG can not process both CMF and RMF records
in the same SMF Input file. See Change 38.095.
Change 38.097 Support for APAR OA56684 adds variables in TYPE78IO:
VMAC78 R783GFLX='ALIAS*MANAGEMENT*GROUPS*AVAILABLE?'
Jun 30, 2020 R783GFLX1='EADM*COMPRESSION*FACILITY*AVAILABLE?'
R783GFLX2='SCM*MEASUREMENT*AVAUILABLE?'
R783ISCB='TIMES*BUSY*SCM*OPERATIONS'
R783IECB='TIMES*BUSY*COMPRESS/DECOMPRESS'
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.096 Support for APAR PI98851 adds two variables to DB2STATS:
VMACDB2 QWOSREAL='REAL*STORAGE*ON LPAR*IN MB'
Jun 18, 2020 QWOSFLG1='80X IF*QWOSREAL*IS VALID'
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.095 Variable CMFPROD is now created for all SMF 70-79 records
VMACSMF and will be RMF or CMF-CPM or CMF-IPM and must be used
Jun 17, 2020 TO SELECT CMF or RMF if BOTH ARE WRITING SMF 70-79 data.
MXG can NOT correctly process that duplicated data in
one job. You would use this logic in //SYSIN:
%LET MACFILE= %QUOTE(IF CMFPROD=:'RMF';); or
%LET MACFILE= %QUOTE(IF CMFPROD=:'CMF';);
Change 38.094 SPINCOPY tests for macro variables were UPCASED to
BUILD005 protect for user typing LIBNAME in lower case.
BUIL3005
Jun 15, 2020
Change 38.093 Support for APAR OA59126 which adds two variables to
VMAC30 TYPE30_V,. TYPE30_4, and TYPE30_5 datasets:
Jun 12, 2020 SMF30NRDS='HWM*IN USE*DATA SPACES*DSPSERV'
SMF30DSCC='DATA*SPACES*CREATED*PROBLEM*STATE'
Change 38.092 Labels added.
VMACXAM
Jun 12, 2020
Change 38.091 Running MXG on Windows SAS, the Carbon Black AV product
TECHNOTE (and probably other Anti-Virus programs) caused Errors:
Jun 10, 2020 ERROR: Permanent copy of file Libref.Entity.UTILITY was
deleted. SAS Note 41488 notes show these messages:
WORK._tf000NN.UTILITY /*Where NN is a number. */
WORK.'SASTMP-000NN'n.UTILITY /*Where NN is a number.*/
WORK.ZFMMEM.UTILITY
WORK.SASMACR.CATALOG
and recommends these extensions be excluded:
sd7 sc7 sas7bdat sas7butl sas7bput sas7bcat
sas7bpgm sas7bndx sas7bvew sas7bacs sas7bmdb
sas7bfdb sas7bitm sas7baud sas7bbak sas7bdmd
sas7bods
-ERROR: A lock is not available for WORK.OPTVAR.DATA.
This is extremely random and can occur anywhere in the
SAS job. It may also occur with other anti-virus types
of software as noted in SAS NOTE 36803. SAS suggested
that the following types of datasets be excluded from
monitoring. Disabling Carbon Black resolved the error.
or updating the Anti-Virus program to exclude these file
suffixes is recommended by SAS,
SASWORK
.lck
.sd2
.sc2
.SPDS
.sas*
.utl
ERROR: A lock is not available for WORK.OPTVAR.DATA when
executing MXG on WINDOWS (could be another file name).
The SAS Support reply:
-The lock on the file means the file is locked by another
processes when SAS tries to lock it. That other process
is often a third party application. SAS opens data sets
to update them but closes them at the end of the PROC or
DATA STEP. It is when the data set is closed that the 3rd
party applications open the files (i.e. lock them) and
prevent the next PROC or DATA STEP from opening the data
set. In some cases for a fraction of a second.
-In most cases, a good workaround is to set FILELOCKWAIT
at the top of your sasv9.cfg.
-You can find the location of your sasv9.cfg with
PROC OPTIONS OPTION=CONFIG; RUN;
-How to edit the sasv9.cfg:
The default SAS configuration file(sasv9.cfg) on Windows
is almost always protected by User Account Control (UAC)
because it is in c:\program files. Run notepad (or other
plain text editor like Notepad++) as an administrator to
edit the configuration file so that you can save changes.
-Wikipedia has a good definition of UAC here:
http://en.wikipedia.org/wiki/User_Account_Control
-Click the start circle or go to the start screen so you
can search for notepad in white box type notepad to
search for it(do not open yet)
-Right click on notepad|notepad++ and choose "Run as
Administrator".
-In notepad click File | Open.
-Change the file type you are looking for to all files
*.*
-Browse to the configuration path referenced above and
open the sasv9.cfg
-Make the change and save the sasv9.cfg. (you can leave
it open)
-You do not need to restart your machine and you can do
this live on a system. Any SAS session already running
will not have the setting but all future SAS sessions
will have the setting(s).
-ONLY USE A PLAIN TEXT EDITOR, DO NOT USE MICROSOFT WORD
TO EDIT THE SASV9.CFG
-After you start a new session of SAS you can check
that you have the setting by submitting:
PROC OPTIONS OPTION=FILELOCKWAIT;RUN;
-An alternative: copy sasv9.cfg to another directory, and
add to your SAS startup command:
-config 'newdir\sas.cfg'
Thanks to Kelly Ballamis, Zions Bancorporation NA, USA.
BUT TEN YEARS AGO, MXG NEWSLETTER FIFTY-FIVE, Jan 20, 2010 Reported:
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.
Change 38.090 -SMF 83 Subtype 3 INPUT STATEMENT EXCEEDED because RELO
VMAC83 218 length 1415 exceeded $VARYING1024 guess for maximum.
Jun 10, 2020 LDAP document still shows length 256 for 218.
-RELO segments 113/114 are now supported, new variables
LDAP_POLICY_UPDATED and LDAP_FLGS.
-User observed last update was in 2013, "I did notice the
code had a significant vintage!"
Thanks to Graham Harris, RBS, ENGLAND.
Change 38.089 -Variable R7410FLG (TYPE IS*VIRTUAL*FLASH*MEMORY?) was not
VMAC74 set to 'Y' when true ('80'x), due to typo R710FLG='Y'.
Jun 9, 2020 -Support for these new EADM variables in TYPE7410.
Jun 23, 2020 R7410DFLG='EADM*COMPRESSION*IS*AVAILABLE?'
R7410DOCC='COMPRESSION*OPERATIONS'
R7410DOCD='DECOMPRESSION*OPERATIONS'
R7410DISC='1MB*INPUT*BLOCKS*COMPRESSION'
R7410DOSC='1MB*OUTPUT*BLOCKS*COMPRESSION'
R7410DISD='1MB*INPUT*BLOCKS*DECOMPRESSION'
R7410DOSD='1MB*OUTPUT*BLOCKS*DECOMPRESSION'
This was added by APAR OA56684.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.088 Support for CA VIEW SARR SMF Subtypes 34 and 35 create
EXSARR36 four new datasets:
EXSARR35 DDDDDD Dataset Description
EXSARI36 SARR35 SARRU35 REPORT ARCHIVAL DATE CHANGE
EXSART36 SARR36 SARRU36 CHANGE ARCHIVAL DATE ACTIVITY
VMACSARR SART36 SARRT36 TAPES ACCESSED
VMXGINIT SARI36 SARRI36 INDEXEX ACCESSED
Jun 9, 2020
Thanks to Steven W. Erikkila, USBANK, USA
Change 38.087 ERROR: Utility file open failed using PROC MEANS/SUMMARY
AUTOEXEC with a CLASS statement that includes many variables.
AUTOEXEU -To circumvent the problem, include the NWAY option in the
AUTOEXQA PROC MEANS/ PROC SUMMARY statement. SAS Note 17594 notes:
AUTOEZOS -Without the NWAY option, the procedure tries to create
CONFIG94 with a CLASS statement that includes many variables.
CONFIGEZ being created. This results in the error message above.
CONFIGT9 -Other circumventions include adding the NOTHREADS option
CONFIGVM to the PROC MEANS or PROC SUMMARY statement and/or using
CONFIMXG a BY statement instead of a CLASS statement, or in your
TECHNOTE AUTOEXEC file or CONFIG file.
Jun 8, 2020 -NOTHREADS option was already in CONFIGV9/9N/V9/T9 due to
Change 22.207 and is added in CONFIMXG/CONFIG94/EZ/VM,
and to AUTOEXEC/EXQA/EZOS/EXEU, for the circumvention of
this error.
-NOTE: THE LISTED MEMBERS ARE EXAMPLES: YOUR AUTOEXxx
and/or CONFIGxx are likely changes and will be in your
USERID.SOURCLIB dataset.
Change 38.086 Unused Change Number.
Change 38.085 UCICSCNT analyzes counts and bytes written for SMF 110
FORMATS records by SUBTYPE, APPLID, STID. and MNSEGCL. PROC FREQ
UCICSCNT and DATA steps were replaced with PROC TABULATE, and
Jun 3, 2020 duration added to the final report to see the frequency
of records. Both the average and maximum values are
reported but the MAX is more likely to reflect the actual
DFHSIT record interval for CICS statistics records.
In addition the number of bytes in the subtype segments
and the percentage of the total bytes is included.
-FORMAT $MGCICVER was added to decode the CICS Version.
-An INCODE= exit is added for tailoring, and examples
were added.
-The four Resource Records and the two Identity records,
Subtype 1 MNSEGCL 5 and 6, were not counted, nor were
Subtype 4 Exception records.
CICS RECORD SUBTYPES AND CORRESPONDING MXG DATASETS CREATED:
0=JOURNAL SEGMENT
CICSJOUR (DEFAULT IF UNKNOWN JOURNAL).
CICSSAP (IF IMACICSA ENABLED FOR SAP).
CICSSMED (IF IMACICSM ENABLED FOR SHAREDMED).
1=MONITOR/TRANSACTION
MNSEGCL=1 DICTIONARY RECORD - USED ONLY BY UTILEXCL.
MNSEGCL=2 CICSACCT (NO LONGER, ONLY EXISTED PRE ESA)
MNSEGCL=3 PERFORMANCE CLASS: CICSBAD, CICSTRAN
MNSEGCL=4 EXCEPTION: CICSEXCE
MNSEGCL=5 RESOURCE
COUNTER DATASET
MNR5NUMI CICSRDS CICS RESOURCE DATA CLASS
MNR5NUMF CICSRDFI CICS RESOURCE FILE DETAIL
MNR5NUMT CICSRDQU CICS RESOURCE TSQUEUE DETAIL
MNR5NUMD CICSRDPL CICS RESOURCE DPL DETAIL
MNSEGCL=6 IDENTITY
COUNTER DATASET
MNI6NUMI CICSIDNT CICS IDENTITY TRANSACTION INFO
MNI6NUMD CICSIDND CICS IDENTITY REALM/DISTING
2=STATISTICS ALL OTHER CICXXXXX
3=TS DATA SHARING STATS: CICXQ1,CICXQ2,CICXQ3,CICXQ4
STID: 121 122 123 124
4=CF DATA TABLE STATS: CICFS6D,CICSF7D,CICFS8D,CICFS9D
STID: 126 127 128 129
5=NAMED COUNTER STATS: CICNS4D,CICNS5D
STID: 124 125
Thanks to Luis Mendoza, BKFS, USA.
Change 38.084 Support for CICS/TS 5.6 (INCOMPATIBLE, FIELDS INSERTED).
VMAC110 -New Variables in CICSTRAN:
UTILEXCL SMMVSSCN='SHORT ON*STORAGE*COUNT'
Jun 1, 2020 SMMVSSTM='SHORT ON*STORAGE*DELAY*TIME'
XZZFYPTM='PASSWORD*VERIFICATION*TIME'
XSVFYPCN='PASSWORD*VERIFICATION*COUNT'
XSVFYKTM='KERBEROS*VERIFICATION*TIME'
XSVFYKCN='KERBEROS*VERIFICATION*COUNT'
-New Variables IN CICMNG:
MNGRMI='RMI*OPTION?' (Y/N)
MNGAPPNS='APPLICATION*NAMING*SUPPORT?' (Y/N)
MNGFREQ='FREQUENCY*HHMMSS'
MNGMCTNM='MCT*PROGRAM*NAME'
Change 38.083 Updated and enhanced parameters allow you to select the
ANALINIT reports of interest. Substantial doc improvements, using
May 28, 2020 PDB.JOBS.
Change 38.082 -New ASMRMFV Field Data Filter (FDF) support for the RMF
ADOCRMFV III Enclave Data Table (ENCG3) and an IMPORTANT FIX.
ASMRMFV -The Field Data Filter (FDF) feature of RMF III was added
May 29, 2020 in MXG Change 37.089 and allows you to filter raw RMF
data values when ASMRMFV reads the RMF III VSAM file,
reducing the size of the created RMFBSAM file. You can
filter table entries based on one or more numeric and/or
character fields, and is intended for advanced MXG users
building ad hoc data collection of RMF III data.
Section 31 in ADOCRMFV documents the FDF implementation.
-ASMRMFV can issue incorrect error message RMFV086E FIELD
NAME IS INVALID for a FDF IF expression. Some Variable
Name Table (VNT) entries were missing a required flag
byte thus causing the search for the expression field
name to fail. But some expressions worked fine.
-This is a PERVASIVE problem with the FDF feature and any
MXG users needing to use FDF for RMF III data filtering
should use this version of ASMRMFV, as it impacts all use
of FDF with MXG 37.03 or later.
-ASMRMFV now supports RMF III table fields up to 512
characters in length such as the EDEACCT field in the
ENCG3 table.
-Message RMFV088I is upgraded to support to the new
extended field lengths. There can be several continuation
RMFV088I messages until all character data has been
displayed as well as the equivalent value as hex digits
(0-9, A-F).
-However, when EBCDIC characters are used in an IF
expression as the user provided value ASMRMFV has an
internal limit of 64 hex digits shown in the RMFV088I
message. This is to prevent long repetitive strings of
X'40' hex digits in RMFV088I. The character value is
displayed in full.
-TUTORIAL:
The ENCG3 Enclave Data Table contains some very large
character fields from 32 up to 512 bytes that have
bearing on how an IF expression for these is coded.
When a character string is used in an IF expression all
possible characters are shown in RMFV088I messages
including trailing blanks.
For large fields such as the 512 byte EDEACCT field this
can result in many RMFV088I continuation messages in the
ASMRMFV log showing only repetitive trailing blanks.
Use the ':' (colon) operator modifier in the IF
expression to control the number of RMFV088I messages and
improve the efficiency of the compare process as well.
In this case only the number of characters in the IF
expression are shown in RMFV088I and only those
characters are used in the compare process.
As an example in ASMRMFV SYSIN instead of coding:
IF=(EDEACCT EQ C'ABC') 512 characters shown in RMFV088I
and all 512 are compared.
Use:
IF=(EDEACCT EQ: C'ABC') 3 characters shown in RMFV088I
and only 3 characters compared.
-Assembler options NOXREF and NORXREF added internally to
reduce ASMRMFV assembly output by 41,000 lines or 22%.
-ASMRMFV now automatically uppercases user specified
values in IF expressions for:
Service Class Names
Report Class Names
Workload Names
Resource Group Names
For example:
IF=(ASICNM EQ 'hot batch')
becomes:
IF=(ASICNM EQ 'HOT BATCH')
The WLM ISPF application does not accept lower case
for these names and neither will ASMRMFV. Descriptions
for these names may be mixed case for WLM or ASMRMFV.
-PROCENC subroutine was outputting one less ENCG3 entry in
a RMFBSAM record when there was still room in the output
buffer for one more.
-ADOCRMFV member's documentation has been updated for:
Section Contents
------- --------
0 Contents
5 Input Data Selection Parameters
12 Messages
13 Filtered Records
26 ASMRMFV and MXG PDB Data Relationships
31 Field Data Filtering (FDF)
37 Filtering The ENCG3 Table
40 Filtering The OPDG3 Table
42 Filtering The SCMG3 Table
46 Summary
====== CHANGES THRU 38.081 WERE IN MXG 38.04 DATED MAY 25, 2020 ========
Change 38.081 MXG 3803 only. The WEEKLY BLDSMPDB failed due to a typo
BLDSMPDB in line 667, which has 1 %end;
May 25, 2020 Remove that 1.
The error only occurs if BLDSMPDB is run on z/OA AND only
if WEEK points to a GDG.
Thanks to Jim S. Horne, Lowe's, USA.
Change 38.080 Support for z15 T02 8562 processor's (156 models) values
FORMATS in $MGRMIPS format, used in ASUMMIPS,GRAFCEC,GRAFWLM,
May 24, 2020 GRAFWRKX and VMACRMFV(RMFIII) to map the MIPS per MSU.
If you use those programs to report MIPS, you need 38.04.
Change 38.079 Support for APAR OA59541 for TYPE42 Subtype 27, adds new
FORMATS variables;
VMAC42 SMF42REOS='ERASE*ON*SCRATCH?'
May 28, 2020 SMF42RZRTY='ZHPF*CHANNEL*PROGRAM*FAILED?'
SMF42RCTCAH='TRANSPORT*COMMAND*AREA*HEADER*7FX'
SMF42RCTCAL='TCA*LENGTH'
SMF42RCFDCW='FIRST*DEVICE*COMMAND*WORD'
SMF42RCDSCB='DSCBS*WRITTEN'
SMF42RCLRAB='LOCATE*RECORD*AUXILARY*BYTE'
SMF42RCLRIC='LOCATE*RECORD*IMBEDDED*OP CODE'
SMF42RCLRC ='LOCATE*RECORD*COUNT'
SMF42RCLROP='LOCATE*RECORD*OPERATION'
SMF42RCLROPOR='ORIENTATION'
SMF42RCLROPOB='OPERATION*CODE'
SMF42RCLRAB0='TRANSFER*LENGTH*FACTOR?'
SMF42RCLRAB7='READ* COUNT*CCW?'
SMF42RCLRIC='LOCATE*RECORD*IMBEDDED*OP CODE'
Format $MG042VT was updated for new values, and new
MG042OR and MXG042OB are created.
Change 38.078 zVPS PLSDSPCN LABEL contained an unintended & character.
VMACXAM
May 22, 2020
Change 38.077 DB2 SMF 102 IFCID 143/144 fields QW0143UR/QW0144UR were
ANALDB2R increased to 10 bytes, 6 reserved bytes and new QW0143SI
VMAC102 and QW0144SI were inserted before QW014xUR in VMAC102,
May 22, 2020 and the format for QW0143UR/144UR in ANALDB2R updated.
Thanks to Terry Chao, DC Government, USA.
Change 38.076 Comments revised for the MIPFACTR which is now set from
GRAFWRKX the CPFCNAME using the $MGRMIPS format.
May 20, 2020
Change 38.075 DB2 APAR PH14037/UI65711 corrects the offset in DB2ACCTP
VMACDB2 records for QPACLOCN/QPACCOLN/QPACPKID/QPACASCH/QPACAANM
May 20, 2020 variables, which caused them to still be truncated. The
error was introduced by APAR PH05989/UI61107. There was
no change to MXG code, the IBM APAR corrected the offset.
Change 38.074 PDBAUDIT in BUILDPDB audits the daily PDB size metrics,
PDBAUDIT including the SAS compression percent PCOMPRESS, which
May 19, 2020 can be a negative value, whenever compressing a dataset
would have increased its size, and is reported by SAS:
"Compressing dataset PDB.STCVSM15 increased by 11.43 pct"
These datasets always have a small number of variables.
Thanks to Randy Hewitt, DXC Technology, USA.
Change 38.073 Significant cleanup of ANAL119 after a typo was found in
ANAL119 37.37 version (extraneous 3 preceding a RUN.) IPHOSTS DD
May 16, 2020 is no longer required but will be used if it is present
and all data steps are skipped if the input datasets are
not found.
Thanks to Tom Kelman, ATOS, USA.
Change 38.072 Type 30 Subtype 6 records have accumulated values but not
VMAC30 all INST counts were deaccumulated, CPUASRTM correction
May 15, 2020 was subtracted from raw rather than DIF'd values causing
a spurious warning message, and minimum SMF time .01 sec
was only a few hundred CPUUNITS which caused some small
negative values when CPUASRTM was non-zero.
The subtype 6 interval records are written instead of 2/3
for Early ASIDs, STCs that start before JES is up, like
ALLOCAS CAMASTER CONSOLE GRS JES2AUX PCAUTH RASP
SMSPDSE SMSPDSE1 TRACE
Thanks to Harald Seifert, Huk-Coberg, GERMANY.
====== CHANGES THRU 38.071 WERE IN MXG 38.03 DATED MAY 7, 2020 ========
Change 38.071 SAGANAL option SYNC59 was incorrectly flooring ENDTIME,
SAGANAL but now uses VMXGDUR to set the Interval Started. SYNC59
May 6, 2020 adds 1 minute and uses that hour, so with 15 min interval
data written at SYNC59, these are the hour intervals into
which the 15 min interval data is assigned.
Original 15:59 16:14 16:29 16:44 16:59 17:14
SYNC 0 hour 15 16 16 16 16 17
SYNC 59 hour 16 16 16 16 17 17
Using SYNC59 for SYNC59 data matches common sense.
Change 38.070 CICS Statistics 110-2 with SMFSTRQT='EOD' End of Day data
VMAC110 have invalid large values, with the same value repeated
May 2, 2020 for dozens of unique events in time sequence that would
normally be accumulated values with zero deltas when they
are deaccumulated, BUT EOD are NOT accumulated data. Each
obs is a separate event, and most values are wrong. In
addition, when EOD obs go thru MXG deaccum, obs are lost.
Intervals of 24 hours are not very useful for analysis.
EOD was accidentally set, and you can sum INT data to get
daily totals if that's what you need.
So, I can not make a business case that the EOD interval;
is needed, and with a circumvention, I'm not going to
pursue a PMR that would waste IBM and Customer time.
-When EOD records go thru Deacculation, many observations
are lost; I experimented with CICXML to bypass deaccum
for EOD, which did preserve observations, but I'm not.
going to implement that for other statistics datasets.
DO NOT USE EOD FOR SMFSTRQT STATISTICS REQUEST TYPE.
Change 38.069 XCOM input did not skip the 461 bytes added in 12.0.
VMACXCOM
May 1, 2020
Thanks to Peter J. Gray, DXC, AUSTRALIA.
Change 38.068 Support for Comm Server SMF 119 Subtype 11 ZERT revised
EXT119ZE to create new TYP119ZE dataset for each Zert instance,
IMAC119 which can have more than one obs per record, and remove
VMAC119 those variables from TYP11911 which has only one obs per
VMXGINIT SMF 119 subtype 11 record.
Apr 30, 2020 Updates to 73/74 for ICN1762 for IKET are not done, may
need data.
Change 38.067 Yet another TYPE42 invalid LENSR in Subtype 5 records has
VMAC42 revised the logic to compare the delta between offsets
Apr 30, 2020 with NRSR*LENSR, and if they do not, recalculate length
by dividing the delta by the NRSR, and if the CALCSRLEN
is an integer, use the new length for LENSR, or delete.
This was from old customer data and may not be a current
value, but this should finally eliminate exposures.
Thanks to John Compton, World Programming, ENGLAND
Change 38.066 Dataset ASUMCAPT was not labeled.
VMXGCAPT
Apr 24, 2020
Thanks to Randy Hewitt, DXC, USA.
Change 38.065 UTILROLL will rollup all observations in all datasets in
UTILROLL a data library into all datasets in another data library.
Apr 29, 2020 New examples added to combine PDBs created every four
hours into a daily PDB library, and to copy multiple days
back to WORK for reporting. Modified to use PROC SQL to
get the engine of the output libname on z/OS so it works
for tape or sequential PDBs. Also added FORCE to the
PROC APPEND to prevent warnings and added SORTEDBY and
ALLDATA datasets created by the macro to ROLLDROP.
Change 38.064 -After New Function APAR OA58759 of 3/26/2020 for RMF the
ASMRMFV ERB3RDEC decompression load module does not contain an
Apr 24, 2020 expected FMID. As a result ASMRMFV issues warning message
RMFV091W that the module is not from IBM. Processing
continues normally, but Return Code 0004 is set.
-ASMRMFV will now also check for an 'IBM' character string
in ERB3RDEC before issuing RMFV091W. The RMFV091W message
was also incorrectly formatted.
Change 38.063 Variables WKRSENCP/WKRSENCV/WKRIENCP/WKRIENCV caused
VMACCMFV INVALID DATA messages because they were INPUT as &RB.4.
Apr 24, 2020 (which worked fine when the fields were zeros) but they
are non-zero and are input with &PIB.4 informat.
Thanks to John Kim, TELUS, CANADA.
Change 38.062 -DB2STAT0 variable QW0225_WARN was incorrectly treated as
VMACDB2 bytes, and it is SERVICEABILITY.
Apr 22, 2020 -Support for APAR PI92652 that adds I/O Interrupt CPU time
variables QWSxIIPT variables in dataset DB2STAT4.
-Support for APAR PI82191 that adds 3 _DPAGE variables to
dataset DB2STAT4, which per the APAR text, are now also
subtracted to correct the three _REAL variables. The
APAR text listed a fourth PVTSTG_DPAGE field, but it
does NOT exist in the records with segment length 320.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.061 Support for z/OS Connect EE SMF 123 Version 2 Subtype 1
EXTY1232 records create new TYPE1232 dataset:
IMAC123A DDDDDD DATASET Description SUBTYPE
VMAC123A TY123A TYPE123A Z/OS CONNECT EE AUDIT V1 1
VMXGINIT TY1232 TYPE1232 z/OS CONNECT EE AUDIT V2 1
Apr 30, 2020 TY123C TYPE123C z/OS CONNECT EE API REQUEST 2
Jul 15, 2020 The subtype 1 new version 2 record created new TYPE1232
Feb 2, 2024 to replace TYPE123A because of many new variables.
-Member TYPE123A creates TYPE123A and TYPE1232 for EE
from subtype 1 and added TYPE123C from subtype 2
in Change 39.043 in 2021.
-Member TYPE123 is archaic, for the S/390 Parallel Query
Server SPQS SMF 123 Record datasets DB2SPQS/DB2SPQAB.
-Jul 15 typo spelling SM123SORRCVD corrected.
-Feb 2: no code change, this text was clarified.
Thanks to Adam Banbury, PNC, USA.
Thanks to Robert Carter, PNC, USA.
Thanks to Robert Richards, PNC, USA.
Change 38.060 CICSTRAN observations are written at task termination,
VMAC110 so long running transactions won't have observations,
Apr 9, 2020 but the CICS SET MONITOR command FREQUENCY argument will
create interval CICSTRAN observations, which can be
identified with RTYPE='F'. RTYPE formatted values:
'C'='C:TERMINAL CONVERSE'
'D'='D:USER EMP DELIVER REQUEST'
'F'='F:FREQUENCY REQUEST'
'M'='M:SEMI-PERMANENT MIRROR SUSPEND'
'S'='S:SYNCPOINT'
'T'='T:TASK TERMINATION'
Thanks to Rob Hollingum, HSBC, ENGLAND
Thanks to Renata Hoyland, HSBC, ENGLAND
Change 38.059 -zVPS XAMCUV records with LPARNAME='TOTAL' weren't output
EXXAMCUV because they duplicate the detail record's values. zVPS
FORMATS now sets LCUCPUID=96 for all total records, so the test
VMACXAM to NOT output in EXXAMCUV now tests to skip the 96's.
Apr 8, 2020 This test is located in the Data Set Exit member so that
you can always override my decision to not OUTPUT them.
-Variables LCUCPUID LCXCPTYP are added to the _BXAMCUV BY
list for dataset XAMCUV.
-XAMCUV records have LCXCPTYP=1 for CP/GP engine instead
of zero, so the MGXAMTY format now maps that value also.
Thanks to John Holiday, Queensland Government, AUSTRALIA.
Change 38.058 CIMS/IMF datasets CIMSDBD,CIMSDB2,CIMSMQ had zero obs
VMXGINIT in 37.37-38.02 because the three SELECTDBD/DB2/SELECTMQ
Apr 21, 2020 macro variables added for BUILDIMS were only %GLOBALed
in VMXGINIT where they should have been %LET to defaults.
The three statements have been added to VMXGINIT, but you
can insert these three statements in your //SYSIN for
your CIMS/IMF processing jobs and they will be populated.
%LET SELECTDBD=%STR(OUTPUT _WIMFDBD;) ;
%LET SELECTDB2=%STR(OUTPUT _WIMFDB2;) ;
%LET SELECTMQ =%STR(OUTPUT _WIMFMQ;) ;
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 38.057 Support for SYSVIEW Subtype 2 record creates new datasets
IMACSVIE PDB.SV02INT - Interval Data - One Obs per Minute.
VMACSVIE Merge of 263 datasets, 1440 Obs daily.
VMXGINIT PDB.SV02MQ - MQ Interval Data - One obs per MQ Subsys
Apr 20, 2020 Merge of 25 datasets, 2880 Obs daily.
PDB.SV02LP - LPAR Interval Data - one per ARGEIGHT,
individual LCPUADDR 0000-000B, and ALL
CP,IFA,IIP,SP, 24480 obs THIS LPAR.
PDB.SV02CP - CPUPLPAR for all LPARs, 47520 obs.
PDB.SV02WL - WLM Service/Reporting Class 250560 obs.
PDB.SV02PLOT - Control Variables, one obs/record.
Thanks to Nagaraj Pudokotia, ATOS, INDIA.
Thanks to Martyn Jones, CPTGLOBAL, ENGLAND.
Change 38.056 -If you tried to reset an option with VMXGOPTR to ORIGINAL
ANALHSM that hadn't previously been set using VMXGOPTR, the code
VMXGOPTR generated here was "OPTIONS 1;" which caused ERROR 13-12:
Apr 6, 2020 Unrecognized SAS option name 1, and execution terminated.
-Now: VMXGOPTR detects that that option had not been set,
stores the current value and does not execute OPTIONS.
-ANALHSM was the culprit that exposed the error and was
corrected.
Thanks to Jack Hyde, OPTUM, USA.
Change 38.055 Change 37.123 (MXG 37.04) incorrectly changed variable
VMAC7072 PCTMVSBY which impacted PLCPRDYQ and SHORTCPS in datasets
VMXGRMFI PDB.TYPE70 and PDB.RMFINTRV.
Apr 30, 2020
Thanks to Paul Naddeo, Fiserv, USA.
Thanks to David Bixler, Fiserv, USA
Thanks to Robin Hanley, Fiserv, USA
Thanks to Bernie Ethridge, Fiserv, USA.
Change 38.054 -ALL ASCII SITES SHOULD ENABLE %AUTOINST IN IMACINIT.
AUTOINST -Concurrent ASCII SAS sessions can error due to INSTREAM
IMACINIT file sharing. The same INSTREAM.SAS file is used on ASCII
May 3, 2020 for every session, so multiple concurrent sessions error
because of the unintended file sharing. The new &AUTOINST
%MACRO creates the temporary INSTREAM file in the session
WORK libname, which is not sharable with other sessions.
FILENAME INSTREAM CATALOG 'WORK.TEMP.INSTREAM.SOURCE';
a. Put the %AUTOINST; statement in the member IMACINIT
in your "USERID.SOURCLIB" tailoring library and the
unique file name will always be allocated.
b. Put the %AUTOINST; in AUTOEXEC, replacing the
INFILE INSTREAM statement.
c. Issue the %AUTOINST; in your SYSIN at start.
-ALL ASCII SITES SHOULD PUT %AUTOINST IN IMACINIT.
-z/OS sites can enable %AUTOINST in IMACINIT and then the
INSTREAM filename will always be created if it was not
already allocated.
Change 38.053 Typo, variable not found, QHSSSID should be QWHSSSID.
ANALDB2T
Mar 30, 2020
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 38.052 Spurious WARNING: MISSING %MEND Statement for VMXG344 is
BUILDPDB sometimes printed after prior error conditions; adding
BUILDPD3 the name of the %MACRO to the %MEND eliminates message.
BUILD001
BUIL3001
Mar 29, 2020
Change 38.051 Using the SAS FTP Access Method, &MXGABND=1 is now set so
VMACSMF that errors (e.g. the SMF file is in use) that can cause
Mar 27, 2020 the SAS Session to hang doing nothing, instead will now
terminate with USER ABEND 69.
If the session still hangs, and you have access to the
directory where the SAS log is being written by that
active session, you should be able to get read access to
the active session's log to see if there are messages
before you kill the session.
Thanks to Richard Way, Office Depot, USA.
Thanks to Amlan Mitra, Office Depot, USA.
Change 38.050 Variable QBSTPCO in dataset DB2STATB was always a
VMACDB2 missing value after DB2 Version 9 due to MXG logic
Mar 24, 2020 error for its INPUT.
Thanks to Flavio Lima, US.IBM.COM, USA.
Change 38.049 -New parameter ROLLWEEKS=5 added to let you keep more
BLDSMPDB weeks than the 5 needed to build a month. NOTE: this
Mar 24, 2020 only applies on zOS or ASCII with STATIC libnames.
With GDGs on zOS or AUTOALOC on ASCII ROLLWEEK is
disabled.
-So if you want to keep 6 weeks of rolling weekly
data specify rollweeks=6. If the WEEK6 LIBNAME is
not found an error message is generated.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
====== CHANGES THRU 38.048 WERE IN MXG 38.02 DATED Mar 23, 2020 ========
Change 38.048 Support for z15 INCOMPATIBLE z/VM MONWRITE 6.4.19.1 due
VMACVMXA to insertion of new EXTND256-EXTND287 counters in dataset
Mar 20, 2020 VXPRCMFC and new variables CORCTLMT CORTLSEQ in VXPRCMFM.
Many ERROR. PRCMFC HARDWARE COUNTER UNEXPECTED messages,
and datasets VXPRCMFC/VXPRCMFM have no observations, but
all the other z/VM MONWRITE datasets are not impacted
Thanks to David Campbell, SunTrust, USA.
Change 38.047 Variables R7023DID/R7024DID, Domain ID, are added to the
VMAC7072 end of the BY List for datasets TYPE7002 and TYPE70X, and
Mar 18, 2020 R7023DID is kept in TYPE7002.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 38.046 Data Set Labels were revised:
VMACDB2 DB2PST: DB2 STATS GLOBAL BUFF POOL
Mar 17, 2020 DB2PAT: DB2 GLOBAL BUFF POOL ATTRIBS
Change 38.045 MXG sets option REUSE=NO to prevent a User change to YES
VMXGINIT in this just-discovered obscure option, that controls how
Mar 17, 2020 free-space is used when new observations are added to an
existing compressed SAS dataset, i.e., whether new obs
are inserted in free space or added at the end, but with
REUSE=YES, and COMPRESS=YES, the POINT= dataset option
ABENDs because it cannot open compressed SAS datasets.
MXG uses POINT= and sets COMPRESS=YES default value.
PROC APPEND disregards REUSE=YES, adding new obs at the
end of the dataset. REUSE is an attribute of the dataset
and cannot be changed for that dataset.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
Change 38.044 VSAM Extended Addressability datasets values for sizes
VMAC60 VVRDSHA VVRDSHU VVRHARBA VVRHURBA must be multiplied by
Mar 15, 2020 VVRAMCIV, the CISIZE. New variable VVREXTAD='Y' if this
is an Extended Addressability dataset (not to be confused
with Extended Format datasets).
Thanks to Michael Friske, FMR, USA.
Change 38.043 Documentation only. Example 10 show ways to select or
READDB2 exclude data by QWHSSSID SubSystem ID.
Mar 14, 2020
Change 38.042 Your USER SMF record type descriptions are in IMACSMFF in
IMACSMFF your tailoring, which adds them to $MGSMFID when FORMATS
Mar 13, 2020 is run, but the MXG syntax - an eight-character VALUE,
with a leading blank if TYPE is LT 1000 - was not stated.
A seven-character value without blank caused no error,
but those types had no description in ANALID reports.
Thanks to Jeff Harder, Indiana Farm Bureau Insurance, USA.
Change 38.041 Support for APAR OA57105, adds to TYPE62/64
VMAC62 Dataset TYPE62 New Variables
VMAC64 SMF62JOBID ='JOB*ID'
Mar 12, 2020 SMF62SYSPLEX='SYSPLEX'
Variable SMF62DEF removed, did not exist and caused
variables SMF62DET and SMF62DKL to be missing/blank.
Dataset TYPE64 New Variables
SMF64JOBID ='JOB*ID'
SMF64SYSPLEX='SYSPLEX'
Change 38.040 OMEGAMON TEMS Subtype 35 INVALID ARGUMENT THREE because
VMAC112 the text length was increased from MXG's original guess
Mar 14, 2020 of 256 with a length of 261, so the lengths are now 512.
Thanks to Jim Czechanski, Northwestern Mutual, USA.
Change 38.039 Support for new variables INREI and JCLJJ in TYPETPMX.
VMACTPMX
Mar 5, 2020
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.038 Dataset TYPE73 variable SHIFT was not populated; the code
VMAC73 for IMACSHFT was only in the code blocks for TYPE73P/L.
Mar 4, 2020
Thanks to Mark Hiltbruner, State of South Dakota, USA.
Change 38.037 -MQM Header/Correlation variables that are now kept:
VMAC116 Dataset MQMACCTQ
Mar 11, 2020 QWHCAID QWHCCVMQ QWHCCN
QWHCPSB QWHCPST QWHCTASK QWHCTNO QWHCTRN QWHCXTYP
QWHSACE QWHSIDMQ QWHSISEQ QWHSMTN QWHSRN QWHSSTCK
QWHSWSEQ WTCORREL
Dataset MQMACCT
QWHCAID QWHCCN QWHCCVMQ QWHCNID QWHCOPID QWHCPSB
QWHCPST QWHCTASK QWHCTNO QWHCTRN QWHCXTYP QWHSACE
QWHSIDMQ QWHSISEQ QWHSRN QWHSSTCK QWHSWSEQ
Dataset MQCFSTAT
DSECT WTCORREL WTASINTE WQBASENA
Dataset MQCHININ
QWHSACE QWHSIDMQ QWHSISEQ QWHSMTN QWHSRN QWHSSTCK
QWHSWSEQ
Dataset MQMQUEUE
QWHCAID QWHCCCMQ QWHCCN
QWHCPSB QWHCPST QWHCTASK QWHCTNO QWHCTRN QWHCXTYP
QWHSACE QWHSIDMQ QWHSISEQ QWHSMTN QWHSRN QWHSSTCK
QWHSWSEQ
-Alignment of the WTAS INPUT now populates WTAS variables.
-The code segment for SUBTYPE=2 was relocated.
-Dataset MQMACCTQ is only output for SUBTYPE=1.
Thanks to Richard Simpson, CPTGLOBAL, AUSTRALIA.
Thanks to Martyn Jones, CPTGLOBAL, ENGLAND.
Change 38.036 -TYPEBETA variables L030SRCJCSY/JCUS, S055IPSERVI were
VMACBETA incorrectly spelled in the KEEP= list and are now kept
VMACBE97 as L030SRCJCSYS/L030SRCRCUSR/S055IPSEVI.
Mar 1, 2020 -TYPEBE97 variables B9759STY_1HEX B9759STY_2HEX were also
corrected to B9759STY_1_HEX andB975STY_2_HEX.
Change 38.035 TYPE1131 vars EXTND247/252/264/265 now KNOWN COUNTERs.
VMAC113
Feb 28, 2020
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 38.034 APAR OA59002 corrects invalid values in SMF89UZT in the
TECHNOTE TYPE89 dataset.
Feb 27, 2020
Thanks to Nick Varley, SYNCSORT, USA.
Change 38.033 -SMF Signature Type 2 Subtype 1 and 2 can print MANY log
VMACSMF "BACK2BACK HEADER" messages, if you have changed the
Feb 28, 2020 IFASMFDL program default option SIGSTRIP to NOSIGSTRIP.
IFASMFDL is the "SMFDUMP" program for SMF LogStreams, and
that SIGSTRIP default is to "Strip", i.e. NOT WRITE the
SMF Type 2 Subtype 1/2 records to the Output SMF file.
-The MXG _SMF Record Processing logic that writes those
Header/Trailer/First/Last diagnostics messages was not
updated when the VMAC0203 was updated in 2017, and these
new type 2 records caused spurious log messages. Datasets
TYPE0201/TYPE0202/TYPE0203 were correct as the messages
have no impact on output datasets. You can use
==> TO SUPPRESS PRINTING OF ALL SMF DIAGNOSTIC MESSAGES, USE:
==> //SYSIN DD *
==> %LET SMFPUTHD=NO;
or you can restore your IFASMFDL JOB to SIGSTRIP default,
or you can use VMACSMF with Change 38.033+ (MXG 38.02).
-If you are back-level at MXG 36.04, then you will also
also need the DODSCRDT/READRATE/VMXGINIT members.
Macro variable SMFPUTHD was added in MXG 31.31.
-This _SMF header code is ALWAYS USED WHEN MXG READS SMF,
so you will see those diagnostic messages, when TYPE 2,
subtype 1 or 2 records are present, in the SMF file,
even if you didn't request Type 02 record processing.
Change 35.266 notes "Even After OA?????, SYSTEM='DUMY'
Type 02 14 byte records were still found." and they
still are; the first SMF Header Message with NOSIGSTRIP
has "DUMY' and not the actual system, but the "FIRST"
message that follows will have the actual SYSTEM name.
(The APAR number in that APAR change is lost.)
-There were fifty ID=2 ST 1/2 messages per minute, or
about 288,000 SYSOUT print lines per day, which could
could cause a 722 SYSTEM ABEND.
How did I miss this in 2017 when subtype support was
added? The original customer could not ftp SMF data, so
LIST; was used to print a hex dump of each subtype,
which UTILBHEX converted to readable records, so there
were (only) two back to back (expected) ID=2 records.
You must be at MXG 37.06 or later to use this VMACSMF.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 38.032 Many missing values in WSFAUDIT dataset from TYPEWSF are
VMACWSF valid as the record only contains nulls starting in byte
Feb 26, 2020 153. Vendor is to be contacted.
Change 38.031 Support for APAR OA56683 adds SMFBOOST variables (System
FORMATS Recovery Boost) to dataset TYPE70:
VMAC7072 BOOSTACTIVE='BOOST*ACTIVE*FULL*INTERVAL'
Feb 20, 2020 BOOSTINFO ='BOOST*INFO*PARTIAL*INTERVAL'
BOOSTCLASS ='BOOST*CLASS'
and FORMAT MG070SB decodes BOOSTACTIVE and BOOSTINFO as
ZIP or SPEED or BOTH. CLASS is either IPL or SHUTdown.
Thanks to Martin Packer, IBM, EUROPE!
Change 38.030 The example user tailoring for multiple TMS catalogs in
ADOCTMS5 ADOCTMS5 (that you EDIT into your IHDRTMS5) ABEND 992 if
Feb 20. 2020 the CRDDD days value was greater than 366; now an error
message and hex dump of the first 5 eliminates the ABEND.
Change 38.029 z/VM MONWRITE dataset VXAPLSLM (Z/VM LINUX MEMORY)
VMACVMXA variable SHARERAM is zero if Linux is not RHEL8.
Feb 14. 2020
Change 38.028 -FDF (Field Data Filter) support added for the RMF Monitor
ADOCRMFV III ZFXG3 (zFS Performance Data Table). General ASMRMFV
ASMRMFV support for this table already existed.
VMACRMFV -Sysout output lines from ASMRMFV assembly reduced.
Feb 21, 2020 ** IMPORTANT **
Feb 28, 2020 -National character (@#$) pattern filter is now the '^'
caret character NOT the '.' period character. There was
a conflict when an RMF III table field contained a
DSNAME. The caret character may not print with some
SYSOUT character sets.
-This documentation section in member ADOCRMFV is added
for new FDF support:
44 Filtering The ZFXG3 Table
Remaining existing section numbers are incremented by 1.
-FDF GOVAT macro call for ZFXG3 table was incomplete.
Table selection would not occur when needed if ZFXG3 was
not explicitly selected when using FDF.
-VMACRMFV did not populate variable ENCCFL2 in ZRBENC.
====== CHANGES THRU 38.027 WERE IN MXG 38.01 DATED Feb 17, 2020 ========
Change 38.027 -TYPE42D3 and TYPE42D4 datasets had the below variables
VMAC42 incorrectly INPUT as SMF42Gxx instead of SMFA2Gxx so they
Feb 13, 2020 were not kept nor labeled.
Dataset TYPE42D3
SMFA2GUA SMFA2GUB SMFA2GUD SMFA2GUE SMFA2GUF SMFA2GUG
SMFA2GSH SMFA2GSI SMFA2GSJ SMFA2GSK
Dataset TYPE42D3
SMFA2GVA SMFA2GVB SMFA2GVD SMFA2GVE SMFA2GVF SMFA2GVG
SMFA2GTH SMFA2GTI SMFA2GTJ SMFA2GTK
Some SMF42Gxx and SMFA2Gxx variable's label incorrectly
had "*DASD" which was removed.
Thanks to Michael Friske, FMR, USA.
Change 38.026 -New variables STC28CTP and STC28FLG are now INPUT and
VMACSTC kept in dataset STCVSM28, variables STC19CTP and STC28CTP
Feb 13, 2020 are formatted $MGSTCCT to display Cartridge Type.
Thanks to Randy Hewitt, DXC, USA.
Change 38.025 Support for CICSTRAN Optional CPICAOR/CPICAOR user field
IMACICXC that populates USERCHAR.
UTILEXCL
Feb 12, 2020
Change 38.024 -Support for zVM VXPRCAPM dataset Crypto Types 11,12,13
VMACVMXA CEX5S/CEX6S/CEX7S, which printed "UNDECODED CRYPTO TYPE".
Feb 10, 2020 -Variable IODSSCH in VXIODDEV dataset is incorrect for
intervals with more than 65K I/Os, short by 65K counts,
but RDEVSKCT captures all I/Os, so MXG now sets variable
IODSSCH=RDEVSKCT for those intervals.
Thanks to Graham Harris, RBS, ENGLAND.
Change 38.023 RMF ZFX variables ZFX_IO_WAIT_TIME, ZFX_LOCK_WAIT_TIME
VMACRMFV and ZFX_MONITORED_SLEEP_TIME in dataset ZRBZFX can be
Feb 10, 2020 negative values because the ZfS interface bases average
response times on requests since last statistics reset,
which can be very long. zFS development is aware of their
design flaw but have not yet responded with a correction.
Change 38.022 Label for EXTEND164 was changed for the z14 and z15 to:
VMAC113 EXTND164='DIRWRIT*TO L1-I*ON CHIP*L3 INTVNT'
Feb 10, 2020
Thanks to George A. Frey, PNC, USA.
Change 38.021 PROC TIMEPLOT example to show concurrent job executions
ANALJOBS and SGPLOTS of ANALCNCR statistics for all jobs or for
Feb 9, 2020 selected jobs.
%ANALJOBS(PDB=PDB,INCODE=if JOB I: ('SYS','PAY'));
Change 38.020 Support for TYPE73 variable SMF73CPD Connection Types are
FORMATS added to $MG073CD format.
Feb 7, 2020 '33'X='33X:COUPLING EXPRESS SR' /*OSM*
'34'X='34X:COUPLING EXPRESS LR' /*OSM*
Thanks to Ehren Bailey, Progressive Insurance, USA.
Change 38.019 Support for DB2 APAR PH18739 EPIC 1016 that adds a new
VMAC102 variable QW0389IT='NUMBER*OF INDEX*TRANSVERSALS' to
Feb 6, 2020 dataset T102S389, COMPATIBLE, using a reserved field.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 38.018 SAS levels prior to TS1M6 for ODS PDF should avoid use
TECHNOTE of CONTENTS on the ODS statement. There are several
Feb 5, 2020 errors that can be caused and any graphs may overlay
the contents. For details see:
http://support.sas.com/kb/20/666.html
Change 38.017 -TYPE80A INPUT EXCEEDED ERROR due to a HOME segment that
VMAC80A had no data following, now protected.
Feb 11, 2020 -Support for TYPE80TK fields TOKMARCHIDE,TOKMSISEMAIL,
TOKMARCSISID TOKMIRRDAUTO.
-SMF 80 SHORT EXTENDED RELOCATE FOUND messages were caused
when a field input with $VARYINGnn LEN was increased with
the actual data length LEN that is greater than the nn.
-The TYPE80TOK segments with TOKSUBSY='CSDATA' are "user"
or "customer" fields added by vendors or installations.
One CSDATA record where TOKDANAM=SISLAST was the last in
the record was truncated, with length 16 with only 14
bytes followed. Other SISxxxx segments were the last in
the record and were not truncated. An MXGNOTES is printed
when truncation is detected and protected.
Thanks to Joe Faska, DTCC, USA.
Change 38.016A ANAL95TH uses PROC TABULATE to create 95th percentile,
ANAL95TH mean and max response and resource statistics, with
Feb 5, 2020 two examples of CICSTRAN.CICSTRAN by TRANNAME, one
across all executions and one by TRANNAME for 15 min
intervals, and one for PDB.JOBS by JOBCLASS for hour
intervals, but the syntax can be used for any data.
Thanks to Robert Barth Cross, IBM, USA.
Change 38.016 SGPLOTS referenced &PDBMXG..NATADAPCT which did not
ANALNATR exist. Changed to PDBOUT.NATADAPCT.
Feb 5, 2020
Thanks to Mark Hiltbruner, State of South Dakota, USA.
CHANGE 38.015 See Change 38.061.
CHANGE 38.014A ASCII Execution ERROR: Template 'Styles.MXGxxxx' was
TECHNOTE unable to write to template store when attempting to
Jan 29, 2020 update the FORMAT directory, because a separate SAS
Windows session was using the LIBRARY catalog.
CHANGE 38.014 Support for IMS APAR PH14569(v14) and PH21001 (V15)
VMACIMS which populates the USERID field in IMS 22 log record.
Jan 29, 2020
CHANGE 38.013 Support for BETA93 and BETA97 Version 7.1.
FORMATS -Variables added to BETA9749 dataset:
VMACBETA B9749PGM B9749VER B9749PTF B9749CDT B9749CTM B9749RC
VMACBE97 B9749IC B9749STIME B9749ETIME B9749INFO B9749SELPTM
EXTYB97T B9749SCPUTM B9749SGETIO B9749SPUTIO
EXTYB97U and the accounting fields are correctly aligned now.
EXTYB97V -New dataset BETA9755 variables:
VMXGINIT B9755INDICAT B9755USER B9755IPCLN B9755IPSEV
Feb 13, 2020 B9755IFLGS B9755HOSTIPORT B9755SERVPORT B9755IPHOST
B9755IPCLIENT B9755IPSERV B9755IPSERVI
-New dataset BETA9759 variables:
B9759MAXSUBT B9759CURSUBT B9759STBYTE B9759RQUST
B9759VERSION B9759INTERCNT B9759INTERTIME B9759NTAB1
B9759NTAB2 B9759STY_1 B9759STY_2 B9759ALLCNTW
B9759ALLCNTN B9759ALLCNTS B9759ALLCNTB
-New dataset BETA9759SFF variables:
B9759MJRCPU B9759MJRCPUN B9759MJRSRB B9759MJRSRBN
B9759MJRZIIP B9759MJRZIIPN B9759MJRCPU B9759MJRCPUN
B9759MJRSRB B9759MJRSRBN B9759MJRZIIP B9759MJRZIIPN
-New dataset BETA9759SFF variables:
B9759MNRCPUN B9759MNRSRB B9759MNRSRBN B9759MNRZIIP
B9759MNRZIIPN B9759MNRCPU B9759MNRCPUN B9759MNRSRB
B9759MNRSRBN B9759MNRZIIP B9759MNRZIIPN
-Datasets BETA0, BETA1, BETA55, BETA59 also have new
variables; they are listed in DOCVER38.
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
CHANGE 38.012 The MXG member DOCVER documents all variables in all MXG
DOCVLONG datasets, originally one line per variable, but the long
Jan 25, 2020 variable names and MXG's 72-character z/OS limit caused
two lines to be needed. The DOCVLONG program creates the
"DOCVLONG.TXT" file with one line per variable with new
LRECL=94 to contain all the information. This change
corrected an ERROR if the variable name ended in NUM and
was 13 characters long.
ON Z/OS:
// EXEC MXGSASV9
//INDOCVER DD DSN='MXG.SOURCLIB(DOCVER),DISP=SHR
//DOCVLONG DD DSN='MXG.DOCVLONG,TXT,DISP=(,CATLG),
// DD RECFM=FB LRECL=94 BLKSIZE=34500.
// DD SPACE=(CYL,(40,4))
//SYSIN DD *
%INCLUDE SOURCLIB(DOCVLONG);
ON ASCII:
FILENAME INDOCVER 'D:\MXG\SOURCLIB\DOCVER.SAS';
FILENAME DOCVLONG 'D:\MXG\USERID\DOCVLONG.TXT';
%INCLUDE SOURCLIB(DOCVLONG);
CHANGE 38.011 Support for APAR OA57718 that adds new zHyperlink write
VMAC42 statistics to TYPE42DS dataset.
Jan 23, 2020
Change 38.010 If you changed the default SMFAUDIT=YES option to NO,
ANALID to suppress the SMF Audit Report (BUILDPDB,ANALID),
Jan 24, 2020 inside ANALID, the VMXGOPTR utility could fail
MXGNOTE: END OF ANALID
NOTE: Line generated by the macro variable "OPTORG4".
Change 37.245's setting options with VMXGOPTR in ANALID
were mis-located inside SMFAUDIT=YES block in MXG 37.08,
now relocated in MXG 38.01.
Thanks to John Milne, IBM, AUSTRALIA
Change 38.009 If you specified GRAPHS=YES and your system is old and
ANALSIIS not have the option SYSODSGRAPHICS or you are on z/OS
READRATE where it is 0 until an ODS GRAPHICS command is issued,
Jan 24, 2020 the code defaulted to using PROC PLOT where XAXIS is not
supported. ANALSIIS and READRATE were both modified to
use the version executing to choose SGPLOT vs PLOT, and
XAXIS was removed from the PROC PLOT.
Thanks to Mike Martin, North Carolina NCSECU, USA.
CHANGE 38.008 Change 37.149 was in error if first USERADD= was IDMS.
UTILBLDP
Jan 22, 2020
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.007 The BY LIST for PROC MEANS DATA=_LVMAINT inside INTVBLD
VMACVMXA is changed to BY CECSER SYSTEM, removing BEGINMTR, which
Jan 21, 2020 caused tens of thousands of useless statistics.
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.006 Support for IAM 9.3 Spin 3 INCOMPATIBLE due to relocation
VMACIAM and insertion of fields; many new variables in TYPEIAM.
Feb 5, 2020
Thanks to Mike Jacques, BBandT, USA.
Change 38.005 "Expressing Latent Demand as a Single Number" report code
ANALATNC starts by graphing a latency number for all systems by
Feb 5, 2020 interval on a single graph and drills down to individual
systems from there, displaying SMF70U00-15 variables in a
stacked bar graph with the latency number and MVS Busy
for each systems as lines on top of the bar. Latency is a
number based on bucket sizes of the SMF70U: (or SMF70Q:
for older OSes), designed to compress all the buckets to
a single number and allow multiple systems on a single
graph. While interesting, it takes interpretation to make
sense of it, especially since it is logarithmic. I think
IBM may have done this deliberately because the SMF70Q:
variables worked out to exactly 9 using the obvious max
bucket value. I fudged the max bucket value when I went
to SMF70U: variables to make it come out to 10. The main
purpose though is to allow the drill down from a common
start to the system details.
Jim's full paper, and report examples are found at:
https://www.mxg.com/downloads/Latent_Demand
Thanks to Jim S. Horne, Lowe's, USA.
Change 38.004 MXG 37.37 ERROR: INVALID VALUE FOR OPTION ENCODING is
CONFIMXG due to 1024 in CONFIGMXG should be OPEN_ED-1047.
Jan 15, 2020 The JOB fails with 999 ABEND and NO SASLOG is created.
Thanks to Jeff.Harder, Indiana Farm Bureau Insurance, USA.
Change 38.003A FORMAT $MG074OM for dataset TYPE74HO variable R744HOPM
FORMATS has new value '50'x='50x:CL5 10 GBIT/S CEE ROCE'
Jan 15, 2020
Thanks to Scott Barry, SBBTechLLC, USA.
Change 38.003 IDMSTAS dataset now contains UOW and NETNAME variables:
VMACIDMS TASCUOWI='CICS*UOW*ID'
Jan 24, 2020 TASCUOWS='CICS*UOW*SEQ'
TASCNETN='CICS*NETWORK*UOW*ID'
-Variables TASUFLD1-TASUFLD3 are now correctly input for
CICS records (IDM6623 corrected IDM6618).
Thanks to Scott Barry, SBBTechLLC, USA.
Thanks to Paola Rosero, Centre de services partages du Quebec, CANADA
Change 38.002 Variable BYTEPRC='PCT OF*BYTES*WRITTEN' is added to both
VMACTMS5 TMS.TMS and variable BESKEY='TAPE*ENCRYPTION*KEY*INDEX
Feb 7, 2020 is added to TMS.DSNBRECD.
Thanks to Umamaheswara Reddy, JPMCHASE, USA.
Change 38.001 BUILDIMS now works correctly with all selection options.
BUILDIMS See Change 37.221 for details
FORMATS -Variable LTERM in CIMSTRAN dataset from IMF records can
VMACCIMS contain '00'x, which are now translated to blanks.
VMACIMS -New variable INPUTCLNR in dataset CIMSTRAN and LASTCLNR
VMXGINIT in dataset CIMSPROG are created with the decimal class
Jan 20, 2020 number. INPUTCL2 and LASTCLA2 have the HEX values.
====== CHANGES THRU 37.275 WERE IN MXG 38.01 DATED Jan 20, 2020 ========
Change 37.275 SYNCSORT SMF WRKDVTYP and STWKSDEV device type variables
FORMATS values were changed some time in the way past 3350 era,
Jan 9, 2020 but MXG Format MGSYNDV was not updated until now.
Thanks to Randy Hewitt, DXC. USA.
Change 37.274 TYPE1415 Harmless NOTE: DUPLICATE BY VARIABLES, because
VMAC1415 OPENTIME was repeated in _BTY1415 was supposedly fixed
Jan 7, 2020 but wasn't until 38.01.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 37.273 Using TYPE26J2 incorrectly to read JES 3 records caused
VMAC26J2 INPUT STATEMENT EXCEEDED. Change 37.026 had added logic
Jan 7, 2020 to delete those JES3 records when using TYPE26J2/BUILDPDB
but tested for SUBS=3, when SUBS=5 is the JES3 SUBSYS.
LASTCHANGE: Version 38.
=========================MEMBER=CHANGE37================================
/* COPYRIGHT (C) 1984-2020 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG VERSION 37.37 is dated Jan 6, 2020, thru Change 37.272.
MXG VERSION 37.09 was dated Dec 20, 2019, thru Change 37.268.
EarlyA MXG VERSION 37.09 was dated Dec 20, 2019, thru Change 37.267.
MXG VERSION 37.08 was dated Nov 26, 2019, thru Change 37.256.
MXG VERSION 37.07 was dated Oct 22, 2019, thru Change 37.239.
Third MXG VERSION 37.07 was dated Oct 14, 2019, thru Change 37.236.
Second MXG VERSION 37.07 was dated Oct 12, 2019, thru Change 37.235.
First MXG VERSION 37.07 was dated Oct 9, 2019, thru Change 37.234.
MXG VERSION 37.06 was dated Aug 30, 2019, thru Change 37.190.
First MXG VERSION 37.06 was dated Aug 22, 2019, thru Change 37.184.
MXG VERSION 37.05 was dated Jul 8, 2019, thru Change 37.154.
Second MXG VERSION 37.05 was dated Jul 6, 2019, thru Change 37.153.
First MXG VERSION 37.05 was dated Jul 5, 2019, thru Change 37.152.
MXG VERSION 37.04 was dated Jun 5, 2019, thru Change 37.124.
MXG VERSION 37.03 was dated Apr 19, 2019, thru Change 37.091.
MXG VERSION 37.02 was dated Mar 11, 2019, thru Change 37.057.
Updated MXG VERSION 37.01 was dated Feb 3, 2019, thru Change 37.031.
First MXG VERSION 37.01 was dated Feb 1, 2019, thru Change 37.029.
Annual MXG Version 36.36 was dated Jan 4, 2019, thru Change 36.255.
The Last MXG Newsletter SIXTY-NINE was dated Jan 3, 2018.
New TECHNOTES for NEWSLTRS are now in CHANGESS.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 37.37 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 37.37.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame, although there are
no new NEWSLTRS updates; they are now found in CHANGESS as TECHNOTEs.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG VERSION 37.37 DATED Jan 6, 2020, THRU CHANGE 37.272.
==MAJOR CHANGES ADDED IN MXG 37.37, DATED Jan 6, 2020 THRU 37.272.
BUILDIMS 37.271 %BUILDIMS creates all possible IMS data plus report.
CONFIMXG 37.267 DO NOT USE ENCODING=EBCDIC1047, use OPEN_ED-1047.
Data values are corrupted with EBCDIC1047.
ADOCABND 37.270 A TECHNOTE documenting recovery from MXG ABENDS,
TYPE71 37.269 TYPE71 variables SMF72PIS/POS now deaccumulated.,
==MAJOR CHANGES ADDED IN MXG 37.09, DATED Dec 20, 2019 THRU 37.268.
SAS OPTION ISSUE FOR Z/OS ONLY, FOR NONLSCOMPATMODE ISSUES:
which is the z/OS default. EBCDIC1047 corrupts output SAS dataset.
ABENDS CORRECTED
TYPE42 37.261 SMF 42 Subtype 1 TYPE42DS INPUT STATEMENT EXCEEDED.
ASUMMSUS 37.265 ERROR PARM OPTNE NOT DEFINED, typo.
NEW SUPPORT
TYPE99 37.264 SMF 99 Subtype 2 TYPE99_2 new variables added.
TYPEIMS 37.259 IMS SYNCPOINT Log Records IMS5937/5938 keeps all vars
TYPEIDMS 37.260 IDMS dataset IDMSTAS USER Fields were misaligned.
==MAJOR CHANGES ADDED IN MXG 37.08, DATED Nov 26, 2019 THRU 37.256.
TYPE42 37.250 SMF 42 ABEND due to SRLEN=208, now all protected.
VMACSMF 37.249 Using FTP ACCESS from z/OS fails with JFCB issue.
ERRORs CORRECTED
TYPERMFV 37.246 Variables PCIFTET/PCIFTQT in ZRBPCI incorrect.
VMXGSUM 37.245 KEEPALL=NO with INCODE= could cause UNINIT message.
TYPE82 37.241 Several MG082xx formats had wrong hex value.
TYPE102 37.240 Variable QWP4STPGS=STASTPGSAMP/N/Y/S is now INPUT.
NEW SUPPORT
TYPE79 37.242 Support for BMC SMF 70 Subtype 255 creates TYPE70FF.
TYPE70PR 37.243 Vars SMF70LACM/LACA/LACB are now kept in TYPE70PR.
ASMRMFV 37.255 RMF III FDF support for PCIE and SCMG3 tables.
ENHANCEMENT
TECHNOTE 37.247 Example RACF analysis, why USERID was revoked.
TYPE119 37.244 Subtype 3 SMF 119 not written, USERID no SMF access.
DIFFROSC 37.256 New ROSCOE dataset ROSCOMON with all MONITORS.
==MAJOR CHANGES ADDED IN MXG 37.07, DATED Oct 22, 2019 THRU 37.239.
ERROR CORRECTED
TYPE113 37.239 Support for new SMF 113 CRYPTO17-20 for z/15,
caused ABEND: ARRAY SUBSCRIPT OUT OF RANGE,
only if HIS CRYPTO counters are enabled, and.
only on z/15.
==MAJOR CHANGES ADDED IN MXG 37.07, DATED Oct 14, 2019 THRU 37.236.
ERROR CORRECTED
TYPE113 37.236 Support for new SMF 113 EXTND255-287 for z/15.
Caused ABEND: ARRAY SUBSCRIPT OUT OF RANGE,
only on z/15.
==MAJOR CHANGES ADDED IN MXG 37.07, DATED Oct 12, 2019 THRU 37.235.
ERROR:
BLDSMPDB 37.235 CRITICAL ERROR if BLDSMPDB and VMXGALOC are used,
(only on ASCII) due to an extra comma in line 949.
"ERROR:All positional parameters must precede ..."
LIBNAME PDB NOT FOUND.
Remove that comma on line 949 in BLDSMPDB.
==MAJOR CHANGES ADDED IN MXG 37.07, DATED Oct 9, 2019 THRU 37.234.
ERROR
ASUMMIPS 37.228 Warning message DURATM=INTERVAL conflict.
ANALMSUS 37.217 EXCELDEST not protected for length 0 Warning.
CICINTRV 37.210 Warning if CICINTRV INTERVAL requested can't be used.
IMACICDB 37.200 Optional CICS DBCTL var STATCTM1 too large.
ASUMDB2A 37.199 Correct count of THREADS in DB2 ASUMDB2A/B/G/P/R.
TYPEBETA 37.198 BETA 93 Subtypes 12/17/30/31/55 are now output.
TYPEBE97 37.197 BETA 97 Subtype 51 did not input "New Area" fields.
BUILD005 37.195 PDB.PRINT only populated ACCOUNTn in first obs.
VMXGDSN 37.191 RMM/EDGR in VMXDSN had zero obs for TAPES/TAPEDSNS.
VMACEDGR 37.225 RMM/EDGR dataset EDGRXEXT RDPHYSIZE too small.
NEW SUPPORT
TYPESAPZ 37.222 Support for SAP Z Connector USER SMF record.
TYPE123A 37.221 Support for z/OS Connect EE SMF 123 Version 2.
TYPECADK 37.219 Support for CA-DISK/Sterling DMS DSINDEX file.
TYPEFOCU 37.215 Support for FOCUS Version 7.7 USER SMF Record.
TYPE80A 37.213 Support for RACF TYPE80TK TOKDANAM=AUTOLOGIN.
TYPE113 37.212 Support for z15 Processor SMF 113 RNI equation.
ASMRMFV 37.204 Support for RMF III CRYG3 and XCFG3 and more FDF.
TYPETLMS 37.192 Support for TLMS creates two new datasets.
TYPE0203 37.216 Support SMF Type 2 ST 1/2 GSIG/ISIG variable length.
ENHANCEMENT
TYPE42 37.194 TYPE42DS variables S42DSENT/DSCMT identify zEDC.
ANAL82AU 37.214 ANAL82AU combines SERV and USER obs for TYPE82AU.
VMXGALOC 37.224 Note if you added VMXGALOC to your IMACINIT.
==MAJOR CHANGES ADDED IN MXG 37.06, DATED AUG 30, 2019 THRU 37.190.
TYPEAAM 37.186 Support for IBM Tivoli Advanced Allocation SMF
DODSCRDT 37.189 Spurious INVALID VALUE FOR INPUT FUNCTION message
==MAJOR CHANGES ADDED IN MXG 37.06, DATED AUG 22, 2019 THRU 37.184.
ERROR
ASMRMFV 37.178 Possible S0C4 (37.05) or S0C7 (using FDF)
TYPE82 37.165 TYPE8201 variables SMF82ITE/CKD/LML/USR/PKD wrong.
TYPEBETA 37.160 BETA 93 610 (back level) subtype 40/49 wrong.
TYPE72GO 37.179 Variables METGOAL and PCTMETGOL were wrong.
NEW SUPPORT
TYPERMFV 37.167 z/OS 2.4 Updates for RMF MONITOR III datasets
TYPE74 37.166 z/OS 2.4 Updates for TYPE7402 dataset.
TYPE82 37.183 Support for SMF 82 new Audit TYPE82AU & subtypes.
TYPEMAR 37.181 Support for Hitachi MAR Mainframe Analytics 9.1
TYPEIMS 37.176 Support for IMS LOG TYPE '02'x.
ENHANCEMENT
TYPE1131 37.175 New SIISPCT=STORE INTO*INSTRUCTION*STREAM*PERCENT.
TYPE1415 37.172 Variable SMF14DEF='Y' if dataset is encrypted.
TYPE110 37.168 CICS "identity" variables not kept with UTILEXCL.
DODSCRDT 37.161 New z/OS-ONLY CREATDATE variable can be created.
ANALMSUS 37.157 MSU Consumption from TYPE89 and TYPE30 charts etc.
==MAJOR CHANGES ADDED IN MXG 37.05, DATED Jul 8, 2019 THRU 37.154.
ERROR
TYPE110 37.154 SMF 110 Subtype 1 MNSEGCL=5 INPUT EXCEEDED error.
==MAJOR CHANGES ADDED IN MXG 37.05, DATED Jul 6, 2019 THRU 37.153.
ERROR
TYPE120 37.153 SMF 120 Subtype 3 INPUT STATEMENT EXCEEDED error.
==MAJOR CHANGES ADDED IN MXG 37.05, DATED Jul 5, 2019 THRU 37.153.
FLASH: 37.144: MISSING PERIOD 2/3 OBS IN TYPE72GO MXG 36.07 or prior
after IBM RMF Maintenance for SCM and CRYPTO are applied.
There is NO ERROR with MXG 36.08 (Oct 2018) or later. See Text.
NEW SUPPORT
ANALMSUS 37.157 Powerful set of reports of SOFTWARE MSUs consumption.
READRATE 37.142 New analysis of Read Rate MB/Sec reading SMF data.
TYPEVM 37.130 New VM Account datasets supported.
TYPE42 37.135 Eight more invalid LENSR= TYPE42 subtype 5.
TYPE119 37.127 New variables in datasets TYP11902/TYP11994/TYP11995.
TYPE123A 37.125 Variable/format changes z/OS Connect EE 3.0 SMF 123.
ENHANCEMENT
MXGSTEP 37.152 MXGSTEP tailoring identifies MXG executions.
==MAJOR CHANGES ADDED IN MXG 37.04, DATED Jun 5, 2019 THRU 37.124.
ERRORS CORRECTED
TYPE1415 37.116 WPS 4.1 ONLY, U4087 ABEND,OPTIONS NOWPSSCATTERCOMP.
TYPENDM 37.113 NDM-CDI 24 byte short record INPUT EXCEEDED.
TYPETPX 37.107 Misaligned TPXETIME reported as 8a Oct 27, 1935.
TYPE102 37.100 DB2 zPARM T106S102 variables misaligned.
NEW SUPPORT
TYPEBETA 37.114 Support for updated BETA 93 V6R2 (INCOMPATIBLE).
TYPE7072 37.109 Support for z/OS 2.4 SMF Manual 04Mar19 changes.
TYPE120 37.105 Support for SMF 120 WAS and LIBERTY (COMPATIBLE).
TYPEIMS 37.103 Support for IMS Log Records 5607/5610/5904/5950.
TYPE110 37.102 Support for CICS/TS 5.5 new Statistics (COMPAT).
TYPE110 37.102 All _SCICxxx Statistic SORTS deaccumulate.
TYPE29 37.093 Support for IMS ODBM Accounting SMF 29 Subtype 1.
TYPETMPX 37.121 Support for ThruPut Manager Release 18.02 v7r1.0.
ENHANCEMENTS
TYPEWSF 37.111 Final revisions for WSF/EOS WSFAUDIT AUDACT/OBJN.
BLDSMPDB 37.106 Updated features and documentation.
TYPE7072 37.104 Variables CECSER/CPCMODEL added to TYPE72GO.
TYPECIMS 37.095 New variables in TYPEDBDS (IMF from BMC).
TECHNOTES
TECHNOTE 37.110 Difference between TYPExxxx and TYPSxxxx.
TECHNOTE 37.097 APAR OA65762 NEGATIVE SMF30_TIME z/OS 2.2 only.
==MAJOR CHANGES ADDED IN MXG 37.03, DATED Apr 19, 2019 THRU 37.091.
ERRORS CORRECTED
TYPE92 37.085 SMF 92 Subtype 52 INPUT EXCEEDED, TRSN doc 52 bytes.
TYPEVMXA 37.084 z/VM VXPRCAPM dataset vars CMB10C0-X4 wrong values.
TYPEBE97 37.080A Datasets BETA9706/BETA9706D were not output to PDB.
TYPE74 37.078 TYPE748S var R748SIID fmt $HEX4, no dupes now.
TYPE125 37.075 INPUT STATEMENT EXCEEDED, period missing.
TYPEDB2 37.074 QBSTBPIN always incorrectly calculated before DIF.
VMAC82 37.060 INPUT EXCEEDED SMF 82 ST 31, incorrect length.
NEW SUPPORT
TYPERMFV 37.067 Support for RMF III PCI/SCM/ZFX segments 4 datasets.
TYPEHSM 37.076 Support for HSM FSR Record, Unix filename added.
TYPE99 37.082 SMF 99 ST 12 Capacity Incr/Decr individual decodes.
ANALRMF3 37.068 CF Activity Report, Structure Level, in ANALRMF3.
TYPEDCOL 37.069 zEDC Compression type values revised DCOLDSET/DCOLDC.
TYPE102 37.059 Final corrections for IFCIC 319 support.
ENHANCEMENTS
TYPEXAM 37.081 Analyzing VPS USER dataset, must use INTORSUM='SU'.
TYPEWSF 37.083 Logic revised to use OBJT/ACT for Input choice.
TYPERMFV 37.080 SVPCNM and RPRTCLAS added to all RCD datasets.
TYPEBBMQ 37.073 UNEXPECTED RTIN messages, BBMQ Version 5.4 no change.
ANALID 37.063 Report now shows 26.002 or 26.003 for JES2/JES3.
GRAFWLM 37.061 Bar charts of ZIP and ZIP Eligible added.
TYPE30 37.058 Cosmetic: Uninitialized variable CBPERROR no impact.
TECHNOTE 37.072 ODS Stat graphics procs use JAVA, memory intensive.
==MAJOR CHANGES ADDED IN MXG 37.02, DATED Mar 11, 2019 THRU 37.057.
ERRORS CORRECTED
TYPENDM 37.047 NDM-CDI dataset NDMCT var NDMCPU 256 times too large.
READDB2 37.042 MXG 37.01. Blank WANTONLY Cosmetic %SYSFUNC message
TYPE74 37.040 TYPE749 variable R7491DEFCOMPRATIO wrong value.
TYPE42 37.034 Two more ABENDS invalid SMF 42 LENSR 520/592 protect.
TYPE74 37.032 TYPE749 z/EDC Divide by ZERO protection failed.
TYPE7072 37.044 BMC CMF VERSNRMF values 792 and 794 for z/OS 2.3.
NEW SUPPORT
TYPEDCOL 37.041 Support for APAR OA54897, DCDEXFLG not used FOR zEDC.
MANY 37.037 Support for SMF Manual Changes in Jan 14, 2019 Doc.
TYPEAXW 37.033 Support for Axway V3.3.2 2018/06/27 restructure.
UTILMISS 37.053 Utility to remove all variables that are all missing.
TYPEDB2 37.035 DB2 V12 overlooked Package variables in DB2ACCTP.
TYPE102 37.051 IFCID 319 new variables created and kept.
ENHANCEMENT
JCLPDBJB 37.048 Example "BUIDPDB" creates only JOB-related datasets.
TYPERMFV 37.055 CFACT Coupling Facility Structure Activity Report.
ANALMQ 37.039 MQ Reports replicating IBM's MQSMF program.
ANALHSM1 37.038 Combined TYPE6156+HSMFSRST report, thrashing pri-mig?
TYPE70PR 37.046 SMF70BPS/SMF70ACS expanded for each engine type.
TECHNOTE 37.043 Executing MXG on ASCII, WORK needs to be local.
==MAJOR CHANGES ADDED IN MXG 37.01, DATED Feb 3, 2019 THRU 37.030.
ASMRMFV 37.030 ASMRMFV 36.12-37.01 NOZEROCPU filter didn't.
Caused out of space condition. Typically, NOZEROCPU
filters out 3/4 of the ZRBASI records.
==MAJOR CHANGES ADDED IN MXG 37.01, DATED Feb 1, 2019 THRU 37.030.
ABEND Avoidance
TYPEDB2 37:014 ABEND: DB2 SMF 100 ST 1 NETEAZZA/IDAA DB2STATS.
TYPEVMXA 37.012 ABEND: ZVM MONWRITE NEW 40061802 Service Level.
TYPEVMXA 37.028 ABEND: ZVM MONWRITE new z/VM 7.1 (INCOMPAT).
ERRORS CORRECTED
TYPE92 37.002 TYPE9208 INPUT STATEMENT EXCEEDED, manual wrong.
TYPERMFV 37.001 Some RMF III ZRBASI fields blank/wrong in 36.36.
TYPE119 37.003 TYP11952 SMF119ML_IP_IPV4 wrongly compressed TIRIP.
VMXGPRAL 37.006 Unbalanced parens in variable label, non fatal.
TYPE92 37.017 Many non-fatal corrections were made to type 92.
TYPEEDGR 37.015 RMM variable EDGRTIME had missing values.
ANALCNCR 37.013 New Concurrency example counts steps and tapes.
NEW SUPPORT
TYPEBETA 37.007 Support for Beta93 V6.2 Subtypes 1-3.
TYPE102 37.005 Support for DB2 102 Trace IFCID 404.
TYPESTC 37.018 Support for STC HSC Subtype 32 and 33 new datasets.
TYPE26J2 37.026 Local SubSystem TYPE26J2 not output, SMF6SBS NE 2.
VMXGALOC 37.021 New parms YR2KEEP and BASEYEAR for Yearly PDB.
ENHANCEMENT
EMAIL 37.027 Example added to email SAS CondCode from ASCII SAS.
ANALID 37.016 New report showing total/min/max for each SYSTEM.
VMXGUOW 37.011 Enhanced for easy CICSTRAN-only PDB.ASUMUOW.
ANAL89 37.029 Reference line SMF70LAC (4HRAV) added to MSU plots.
TECHNOTES
TECHNOTE 37.004 Reading z/OS DATA with SAS FTP Access needs RCMD
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M6 (9.4M6), "M6",
or "SAS 9.4 (9.04.01M6P110718)" if the OPTION VERSIONLONG is
enabled.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M6 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M6 or SAS Version 9.3 M0-M2.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.128 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But CONFIMXG is required for sites with NLS issues, and you must
use JCLCONFI to create/update the MXG.FORMATS catalog if you use
CONFIG='MXG.SOURCLIB(CONFIMXG)'.
For no NLS, you can use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 36.11 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
The z15 did INCOMPATIBLY change the SMF 113 records by adding 32
new EXTEND and 4 CRYPTO counters, and those fields were supported
in MXG 37.07 dated Oct 22, 2019. The z/14 also INCOMPATIBLY changed
the SMF 113 record, and that was supported way back in MXG 36.07.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
MXG 37.07 supports the new z/OS 2.4 SMF manual fields, COMPATIBLY.
The z13 processor INCOMPATIBLY CHANGED, the new SMT-MODE RMF 70, and
MXG 34.03 was REQUIRED (PCTCPUBY WRONG!), to read the SMT-format RMF
(which are written if you have zIIP engines AND have enabled the new
PROCVIEW CORE option for Multi-Threading, even if only one thread is
enabled).
The new zEDC compression hardware requires MXG 33.07 to support the
new metrics.
For z/VM, MXG REQUIRES MXG 33.02 to support the z/13 changes.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z/OS 2.4 Compatible from SMF Manual Sep 2019 37.166 37.07.
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
z15 New SMF fields (COMPAT) Oct 22, 2018 37.07
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS-TS/5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS-TS/5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS-TS/5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS-TS/5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS-TS/5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS-TS/5.3 GA date Dec 11, 2015 33.33
CICS-TS/5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS-TS/5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS-TS/5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS-TS/5.4 GA Jun 17, 2017 35.03
CICS-TS/5.5 GA (COMPAT) Jan 29, 2018 37.01
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
z/VM 6.40061802 ABEND Jan 17, 2019 37.02
z/VM 7.1 ABEND Feb 14, 2019 37.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2, 5.3, 5.4 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 37.37.
1. Incompatibilities introduced in MXG 37.37:
a- Changes in MXG architecture made between 37.37 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 37.08 after MXG 36.36:
Dataset/
Member Change Description
ANAL82AU 37.214 ANAL82AU combines SERV and USER obs for TYPE82AU.
ANALCNCR 37.013 New Concurrency example counts steps and tapes.
ANALHSM1 37.038 Combined TYPE6156+HSMFSRST report, thrashing pri-mig?
ANALID 37.016 New report showing total/min/max for each SYSTEM.
ANALID 37.063 Report now shows 26.002 or 26.003 for JES2/JES3.
ANALMQ 37.039 MQ Reports replicating IBM's MQSMF program.
ANALMSUS 37.136 Powerful set of reports of SOFTWARE MSUs consumption.
ANALMSUS 37.157 MSU Consumption from TYPE89 and TYPE30 charts etc.
ANALMSUS 37.217 EXCELDEST not protected for length 0 Warning.
ANALRMF3 37.068 CF Activity Report, Structure Level, in ANALRMF3.
ASMRMFV 37.030 ASMRMFV 36.12-37.01 NOZEROCPU filter didn't.
ASMRMFV 37.178 Possible S0C4 (37.05) or S0C7 (using FDF)
ASMRMFV 37.204 Support for RMF III CRYG3 and XCFG3 and more FDF.
ASMRMFV 37.254 MXG 37.05-37.07 CPC parameter PARMS KEYWORD NULL
ASMRMFV 37.255 RMF III FDF support for PCIE and SCMG3 tables.
ASUMDB2A 37.199 Correct count of THREADS in DB2 ASUMDB2A/B/G/P/R.
ASUMMIPS 37.228 Warning message DURATM=INTERVAL conflict.
BLDSMPDB 37.106 Updated features and documentation.
BUILD005 37.195 PDB.PRINT only populated ACCOUNTn in first obs.
CICINTRV 37.210 Warning if CICINTRV INTERVAL requested can't be used.
DIFFROSC 37.256 New ROSCOE dataset ROSCOMON with all MONITORS.
DODSCRDT 37.161 New z/OS-ONLY CREATDATE variable can be created.
DODSCRDT 37.189 Spurious INVALID VALUE FOR INPUT FUNCTION
EMAIL 37.027 Example added to email SAS CondCode from ASCII SAS.
GRAFWLM 37.061 Bar charts of ZIP and ZIP eligible added.
IMACICDB 37.200 Optional CICS DBCTL var STATCTM1 too large.
JCLPDBJB 37.048 Example "BUIDPDB" creates only JOB-related datasets.
MANY 37.037 Support for SMF Manual Changes in Jan 14, 2019 Doc.
READDB2 37.042 MXG 37.01. Blank WANTONLY Cosmetic %SYSFUNC message
READDB2 37.185 APPARENT SYMBOLIC REFERENCE LDB LDB@ACT, no impact.
TECHNOTE 37.004 Reading z/OS DATA with SAS FTP Access needs RCMD
TECHNOTE 37.043 Executing MXG on ASCII, WORK needs to be local.
TECHNOTE 37.072 ODS Stat graphics procs use JAVA, memory intensive.
TECHNOTE 37.097 APAR OA65762 NEGATIVE SMF30_TIME z/OS 2.2 only.
TECHNOTE 37.110 Difference between TYPExxxx and TYPSxxxx.
TECHNOTE 37.247 Example RACF analysis, why USERID was revoked.
TYPE0203 37.216 SMF Type 2 Subtypes 1/2 GSIG/ISIG variable length.
TYPE102 37.005 Support for DB2 102 Trace IFCID 404.
TYPE102 37.051 IFCID 319 new variables created and kept.
TYPE102 37.059 Final corrections for IFCIC 319 support.
TYPE102 37.100 DB2 zPARM T106S102 variables misaligned.
TYPE102 37.240 Variable QWP4STPGS='STASTPGSAMP/N/Y/S is now INPUT.
TYPE110 37.102 All _SCICxxx Statistic SORTS deaccumulate.
TYPE110 37.102 Support for CICS/TS 5.5 new Statistics (COMPAT).
TYPE110 37.168 CICS "identity" variables not kept with UTILEXCL.
TYPE113 37.212 Support for z15 Processor SMF 113 RNI equation.
TYPE1131 37.175 New SIISPCT=STORE INTO*INSTRUCTION*STREAM*PERCENT.
TYPE119 37.003 TYP11952 SMF119ML_IP_IPV4 wrongly compressed TIRIP.
TYPE119 37.127 New variables in datasets TYP11902/TYP11994/TYP11995.
TYPE119 37.244 Subtype 3 SMF 119 not written, USERID no SMF access.
TYPE120 37.105 Support for SMF 120 WAS and LIBERTY (COMPATIBLE).
TYPE123A 37.125 Variable/format changes z/OS Connect EE 3.0 SMF 123.
TYPE123A 37.221 Support for z/OS Connect EE SMF 123 Version 2.
TYPE125 37.075 INPUT STATEMENT EXCEEDED, period missing.
TYPE1415 37.116 WPS 4.1 ONLY, U4087 ABEND,OPTIONS NOWPSSCATTERCOMP.
TYPE1415 37.172 Variable SMF14DEF='Y' if dataset is encrypted.
TYPE26J2 37.026 Local SubSystem TYPE26J2 not output, SMF6SBS NE 2.
TYPE29 37.093 Support for IMS ODBM Accounting SMF 29 Subtype 1.
TYPE30 37.058 Cosmetic: Uninitialized variable CBPERROR no impact.
TYPE42 37.034 Two more invalid SMF 42 LENSR 520 and 592 added.
TYPE42 37.135 Eight more invalid LENSR= TYPE42 subtype 5.
TYPE42 37.194 TYPE42DS variables S42DSENT/DSCMT identify zEDC.
TYPE42 37.250 SMF 42 ABEND due to SRLEN=208, now all protected.
TYPE7072 37.044 BMC CMF VERSNRMF values 792 and 794 for z/OS 2.3.
TYPE7072 37.104 Variables CECSER/CPCMODEL added to TYPE72GO.
TYPE7072 37.109 Support for z/OS 2.4 SMF Manual 04Mar19 changes.
TYPE70PR 37.046 SMF70BPS/SMF70ACS expanded for each engine type.
TYPE70PR 37.243 Vars SMF70LACM/LACA/LACB are now kept in TYPE70PR.
TYPE72GO 37.179 Variables METGOAL and PCTMETGOL were wrong.
TYPE74 37.032 TYPE749 z/EDC Divide by ZERO protection failed.
TYPE74 37.040 TYPE749 variable R7491DEFCOMPRATIO wrong value.
TYPE74 37.078 TYPE748S var R748SIID fmt $HEX4, no dupes now.
TYPE74 37.166 z/OS 2.4 Updates for TYPE7402 dataset.
TYPE79 37.242 Support for BMC SMF 70 Subtype 255 creates TYPE70FF.
TYPE80A 37.213 Support for RACF TYPE80TK TOKDANAM=AUTOLOGIN.
TYPE82 37.060 INPUT EXCEEDED SMF 82 ST 31, incorrect length.
TYPE82 37.165 TYPE8201 variables SMF82ITE/CKD/LML/USR/PKD wrong.
TYPE82 37.183 Support for SMF 82 new Audit TYPE82AU dataset.
TYPE82 37.241 Several MG082xx formats had wrong hex value.
TYPE92 37.002 TYPE9208 INPUT STATEMENT EXCEEDED, manual wrong.
TYPE92 37.017 Many non-fatal corrections were made to type 92.
TYPE92 37.085 SMF 92 Subtype 52 INPUT EXCEEDED, TRSN doc 52 bytes.
TYPE99 37.082 SMF 99 ST 12 Capacity Incr/Decr individual decodes.
TYPEAAM 37.186 Support for IBM Tivoli Advanced Allocation SMF
TYPEAXW 37.033 Support for Axway V3.3.2 2018/06/27 restructure.
TYPEBBMQ 37.073 UNEXPECTED RTIN messages, BBMQ Version 5.4 no change.
TYPEBE97 37.080A Datasets BETA9706/BETA9706D were not output to PDB.
TYPEBE97 37.197 BETA 97 Subtype 51 did not input "New Area" fields.
TYPEBETA 37.007 Support for Beta93 V6.2 Subtypes 1-3.
TYPEBETA 37.007 Support for Beta93 Version 6.2 subtypes 2 and 3.
TYPEBETA 37.114 Support for updated BETA 93 V6R2 (INCOMPATIBLE).
TYPEBETA 37.160 BETA 93 610 (back level) subtype 40/49 wrong.
TYPEBETA 37.198 BETA 93 Subtypes 12/17/30/31/55 are now output.
TYPECADK 37.219 Support for CA-DISK/Sterling DMS DSINDEX file.
TYPECIMS 37.095 New variables in TYPEDBDS (IMF from BMC).
TYPEDB2 37.035 DB2 V12 overlooked Package variables in DB2ACCTP.
TYPEDB2 37.074 QBSTBPIN always incorrectly calculated before DIF.
TYPEDB2 37.251 DB2 Storage Contraction new vars DELTAAV0/AVA/AVB.
TYPEDB2 37:014 ABEND: DB2 SMF 100 ST 1 NETEAZZA/IDAA DB2STATS.
TYPEDCOL 37.041 Support for APAR OA54879, DCDEXFLG not used FOR zEDC.
TYPEDCOL 37.069 zEDC Compression type values revised DCOLDSET/DCOLDC.
TYPEEDGR 37.015 RMM variable EDGRTIME had missing values.
TYPEFOCU 37.215 Support for FOCUS Version 7.7 USER SMF Record.
TYPEHSM 37.076 Support for HSM FSR Record Unix filename added.
TYPEIMS 37.103 Support for IMS Log Records 5607/5610/5904/5950.
TYPEIMS 37.176 Support for IMS LOG TYPE '02'x.
TYPEMAR 37.181 Support for Hitachi MAR Mainframe Analytics 9.1
TYPEMDM 37.015 RMM variable EDGRTIME had missing values.
TYPENDM 37.047 NDM-CDI dataset NDMCT var NDMCPU 256 times too large.
TYPENDM 37.113 NDM-CDI 24 byte short record INPUT EXCEEDED.
TYPERMFV 37.001 Some RMF III ZRBASI fields blank/wrong in 36.36.
TYPERMFV 37.055 CFACT Coupling Facility Structure Activity Report.
TYPERMFV 37.067 Support for RMF III PCI/SCM/ZFX segments 4 datasets.
TYPERMFV 37.080 SVPCNM and RPRTCLAS added to all RCD datasets.
TYPERMFV 37.167 z/OS 2.4 Updates for RMF MONITOR III datasets
TYPERMFV 37.246 Variables PCIFTET/PCIFTQT in ZRBPCI incorrect.
TYPESAPZ 37.222 Support for SAP Z Connector USER SMF record.
TYPESTC 37.018 Support for STC HSC Subtype 32 and 33 new datasets.
TYPETLMS 37.192 Support for TLMS creates two new datasets.
TYPETPX 37.107 Misaligned TPXETIME reported as 8a Oct 27, 1935.
TYPEVM 37.130 New VM Account datasets supported.
TYPEVMXA 37.012 ABEND: ZVM MONWRITE NEW 40061802 Service Level.
TYPEVMXA 37.028 Support for z/VM 7.1 (INCOMPAT, BROKEN CONTROL).
TYPEVMXA 37.084 z/VM VXPRCAPM dataset vars CMB10C0-X4 wrong values.
TYPEWSF 37.083 Logic revised to use OBJT/ACT for Input choice.
TYPEWSF 37.111 Final revisions for WSF/EOS WSFAUDIT AUDACT/OBJN.
TYPEXAM 37.081 Analyzing VPS USER dataset, must use INTORSUM='SU'.
UTILMISS 37.053 Utility to remove all variables that are all missing.
VMACEDGR 37.225 RMM/EDGR dataset EDGRXEXT RDPHYSIZE too small.
VMACSMF 37.249 Using FTP ACCESS from z/OS fails with JFCB Issue.
VMXGALOC 37.021 New parms YR2KEEP and BASEYEAR for Yearly PDB.
VMXGALOC 37.224 Note if you added VMXGALOC to your IMACINIT.
VMXGDSN 37.191 RMM/EDGR in VMXDSN had zero obs for TAPES/TAPEDSNS.
VMXGOPTR 37.252 Restores ORIGINAL, used to always reset if changed.
VMXGPRAL 37.006 Unbalanced parens in variable label, non fatal.
VMXGSUM 37.245 KEEPALL=NO with INCODE= could cause UNINIT message.
VMXGUOW 37.011 Enhanced for each CICSTRAN-only PDB.ASUMUOW.
CONFIMXG 37.267 DO NOT USE ENCODING=EBCDIC1047, use OPEN_ED-1047.
ASUMMSUS 37.265 ERROR PARM OPTNE NOT DEFINED, typo.
TYPE99 37.264 SMF 99 Subtype 2 TYPE99_2 new variables added.
TYPE42 37.261 SMF 42 Subtype 1 TYPE42DS INPUT STATEMENT EXCEEDED.
TYPEIDMS 37.260 IDMS dataset IDMSTAS USER Fields were misaligned.
TYPEIMS 37.259 IMS SYNCPOINT Log Records IMS5937/5938 keeps all vars
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at http://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE
====== CHANGES THRU 37.272 WERE IN MXG 37.37 DATED Jan 6, 2020 ========
Change 37.272 If you did not specify EXCELDEST you could get WARNINGs:
ANALMSUS Argument 2 to macro function %SUBSTR is out of range
Jan 5, 2020 Argument 3 to macro function %SUBSTR is out of range
Change 37.271 %BUILDIMS can create all current MXG IMSLOG datasets and
BUILDIMS REPORT=YES (default) prints counts of bytes/records for
FORMATS each LSUBCODE; REPORT=ONLY will produce only the report.
VMACCIMS Not all IMS Log Records create MXG datasets; many records
VMACIMS are for database recovery with no performance metrics,
VMXGINIT but support will be added upon request and test data.
Jan 5, 2020 // EXEC MXGSASV9
//IMSLOG DD DSN=YOUR.IMS.LOG.DATA,DISP=SHR
//PDB DD DSN=YOUR.IMS.PDB,DISP=(,CATLG),SPACE=....
//SYSIN DD *
%BUILDIMS(REPORT=YES,
WANT= F9 FA 56FA,
IMSVER=14.1,
START= '01JAN2020:08:00:00'DT,
END = '01JAN2020:10:00:00'DT);
Note: REPORT=YES reports all IMS Log Records in input and
is not impacted with WANT/START/END/IMSSYSTEM selections.
See comments in member BUILDIMS for documentation.
Thanks to Randy Hewitt, DXC. USA.
Change 37.270 A TECHNOTE documenting how to recover from MXG ABENDS.
ADOCABND
Jan 1, 2020
Change 37.269 TYPE71 variables SMF71PIS/SMF71POS, 4K TO/FROM SCM are
VMAC71 accumulated fields, so they are correct only when TYPS71
Dec 23, 2019 (or BUILDPDB) is used, since the deaccumulation is done
in the _STY71 Data Set Sort Macro, and will always be
missing values in the first obs from each SYSTEM.
Thanks to Graham Harris, RBS, ENGLAND.
====== CHANGES THRU 37.268 WERE IN MXG 37.09 DATED Dec 20, 2019 ========
Change 37.268 Variable SM116EVT in MQMACCTQ and MQMQUEUE datasets was
VMAC116 not set for Task Terminated; test for '21'x was wrong and
Dec 20,2019 changed to four byte test for '200800000'x for Terminate
and '00080000'x for Initiate.
Thanks to Scott Barry, SBBWORKS, INC, USA.
====== CHANGES THRU 37.267 IN EARLY ADOPTER MXG 37.09 DATED Dec 20, 2019
Change 37.267 z/OS: ENCODING=EBCDIC1047 corrupts data; OPEN_ED-1047 is
CONFIMXG and has been REQUIRED for MXG, and is the z/OS Default.
VMXGINIT With ENCODING=EBCDIC1047 character variables with '15'x
Dec 12, 2019 byte value are changed to '25'x, and byte values of '25'x
are changed to '15'x! Those are the New Line & Line Feed
characters that swap. You can display your options with:
PROC OPTIONS OPTION=ENCODING;
PROC OPTIONS OPTION=LOCALE;
PROC OPTIONS OPTION=NLSCOMPATMODE;
-You can add an ENCODING=OPEN_ED-1047 statement in your
CONFIGV9/CONFIMXG/CONFIGxx tailoring member, or you can
set with // EXEC SAS94,OPTIONS='ENCODING=OPEN_ED-1047'
-Not only can character bit tests and formatted values be
wrong, some numeric TODSTAMP datetime fields are created
from character variables when shorter than 8-bytes, using
DATETIME=INPUT(CHAR6!!'0000'x),TODSTAMP8.);
Changing the second byte from '15'x to '25'x is 30 days.
-VMXGINIT is enhanced to print error message if ENCODING
option is not OPEN_ED-1047.
-And, OPEN_ED-1047 does work with NONLSCOMPATMODE, And SAS
in 2016 without documenting it, said they were NOT going
to remove NLSCOMPATMODE nor NONLSCOMPATMODE options.
-If you depend on NLS characters, the CONFIMXG option was
created by SAS to support NLS sites, see that member.
Thanks to Andrew Gadsby, SAS UK, ENGLAND.
Thanks to Andy Knight, SAS UK, ENGLAND.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Thanks to Mark Tomlinson, Lloyds, ENGLAND
Change 37.266 Parameters DATETIME= and INTERVAL= were not specified in
TRNDDB2P VMXGSUM invocation, causing little or no summarization.
TRNDDB2R
Dec 11, 2019
Thanks to Marybeth Delphia, CPA.TEXAS.GOV, USA.
Change 37.265 If you did not specify PDBOUT the correct dataset(s)
ANALMSUS names were not generated.
Dec 11, 2019 -The use of substitution macros in IMACKEEP made ANALMSUS
fail if you tried to run it twice in a single SAS
session. Those affected macros are now nulled out.
-OPTIONS NOBYLINE was set but there were no BY values
in the TITLE statements - there are now.
-MXG 37.09 ONLY. ERROR KEYWORD PARM OPTNME NOT DEFINED,
now correctly spelled as OPTNAME.
-Eliminated a WARNING about SUBSTR out of range when
EXCELDEST was NULL.
Thanks to Jan Tielemans, KBC, BELGIUM
Change 37.264 SMF 99 Subtype 2 TYPE99_2 dataset did not input the many
VMAC99 variables that had been added in z/OS 2.3.
Dec 15, 2019
Thanks to Betty Wong, Bank of America, USA.
Change 37.263 READDB2 didn't create the T102SSSS and T102S000 datasets
READDB2 when a numeric IFCID was in the IFCIDS= parameter. Now,
Dec 10, 2019 it does unless T102SSS/T102000 are set to NO.
Logic to parse strings for each dataset was simplified
and relocated to a separate macro to simplify ongoing
maintenance.
Change 37.262 Replaced by Change 37.271.
BUILDIMS
Jan 1, 2020
Change 37.261 TYPE42 INPUT STATEMENT EXCEEDED subtype 6 due to a short
VMAC42 S42DSSNL=72 segment when SMF manual had 80, probably due
Dec 7, 2019 one of the APARs in Change 37.250.
-Subtype 5, LENSR=208 records were deleted (Change 37.260)
with log message, but now they are output and the extra
48 bytes are skipped.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
Change 37.260 IDMS dataset IDMSTAS fields were misaligned because the
VMACIDMS new variable TASBJBID was inserted in the record.
Dec 6, 2019
Thanks to Paola Rosero, Government of Quebec, CANADA
Change 37.259 IMS SYNCPOINT Log Records IMS5937 and IMS5938 only kept a
VMACIMS small number of variables, now all fields in the record
Dec 16, 2019 are kept.
Thanks to Randy Hewitt, DXC. USA.
Change 37.258 Earlier releases of the %SCAN function of the %MACRO
READDB2 COMPILER returned the input string if there was only
Dec 1, 2019 a single string for the delimiter that was used, which
required extra MXG logic to correct, and which could fail
if AAAA was used, with no BBBB, and there was a CCCC but
no space between the two slashes, causing CCCC to be seen
as the BBBB argument, raising a WORD2 macro error. Now,
SAS returns the string correctly so the excess MXG logic
could be removed along with this (rare) exposure.
-If all you requested with WANTONLY was DB2ACCT DB2ACCTW
was also produced.
Thanks to Ervin Claxon, CSX, USA.
Change 37.257 This member will work but is obsolete and has been
TRNDRMFN replaced by TRNDRMFI. The biggest difference is in the
Nov 29, 2019 input dataset. This member uses PDB.RMFINTRV which would
only get a single days PDB as input while the TRNDRMFI
member uses WEEK.RMFINTRV which would be all of the days
of the week.
Thanks to Wayne Bell, UNIGROUP, USA.
====== CHANGES THRU 37.256 WERE IN MXG 37.08 DATED Nov 26, 2019 ========
Change 37.256 ROSCOE new dataset PDB.ROSCOMON contains an observation
DIFFROSC for each of these MONITOR values:
Nov 19, 2019 ALL AMS ATT CON CPL DIS DSF ETS HEX IMP
JCL LIB LOO OTH OUT PUR SOR UTI VTO ZAP
and variable MONITOR contains the monitor acronym.
The Monitors AUD AWS RPS SHU STA VPE are not included,
as they have always had a separate ROSCOxxx dataset.
Thanks to Linda S. Berkley, DISA, USA.
Change 37.255 -FDF support added for the RMF Monitor III PCIG3 (PCIE
ADOCRMFV Activity Data Table) and SCMG3 (Storage Class Memory Data
ASMRMFV Table). General ASMRMFV support for these tables already
Nov 19, 2019 existed.
-Improved ASMRMFV FDF handling of 16 byte binary
Fields using Extended Floating Point arithmetic.
-Minor corrections made to ASI, CPD, GEI, OPD, SPG, and
SSHG3 FDF Variable Name Tables.
-Main storage reduction made for FDF Alias and True
Name entries in Variable Name Tables.
-FDF now uses only 1 pattern table for all character
Fieldnames instead of a pattern table for every character
Fieldname when a user character pattern compare occurs.
-Message RMFV088I now shows XFP (Extended Floating Point)
tag for 16 byte quadword fields during FDF processing.
-Floating point fields were not always scaled by FDF
when required prior to comparisons to a user value.
-When the maximum 32K LRECL output length to RMFBSAM would
be exceeded in PROCCPU, PROCCFI, and PROCRCD subroutines
the entire RMF III table will now be skipped. This should
be a very rare event.
-Section 12 Messages updated in ADOCRMFV.
-These documentation sections in member ADOCRMFV are
added for new FDF support:
40 Filtering The PCIG3 Table
41 Filtering The SCMG3 Table
Remaining existing section numbers are incremented by 2.
Change 37.254 -MXG 37.05-37.07. When CPC parameter was specified,
ASMRMFV Message RMFV057I PARMS KEYWORD VALUE IS NULL printed
Nov 16, 2019 and neither CPCDB nor CPUG3 tables were selected.
-PCIG3 table support was not checking the z/OS release.
Only z/OS 2.3 and higher releases are supported.
Inputting a PCI table from a lower release results in an
MXG build failure. PCIG3 tables from older releases will
now be ignored. Applies to MXG Releases 37.03 and up.
Change 37.253 Cosmetic. Labels were blank for these variables/datasets
ASUM70PR STCVSM32 variable SMLSSMF32
VMAC102 ASUMCEC variable CPUICFTM
VMAC113 TYPE1131 EXTND22x variables had COUNTER 225 UNDEFINED
VMAC120 FOCUSMSO variables FOCUMEMA,FOCUMEMB
VMAC26J2 TYPE26J2 variable SUBS
VMAC82 TYPE82 variable SMF82_TAK_KEY_EVENT
VMACSTC TYPE120 variable SMF1209HW
Nov 18, 2019 T102S106 variable QWO4ADM2-QWO4SADM
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 37.252 During QA testing we found that 250 members changed a
VMXGOPTR SAS system option but did not return that option to its
MANY original value, which could impact subsequent programs
Nov 18, 2019 in that SAS job step or SAS Session. Previously, with
NEWVALUE=ORIGINAL, VMXGOPTR reset the option to its
value PRIOR to the LAST VMXGOPTR invocation, but now
it is restored to the original value of the SAS Session
or batch STEP, and all 250 members now have pairs of
VMXGOPTR to change and to then reset options to their
ORIGINAL value.
Example of use of VMXGOPTR with this change with the
original option DSNFERR having value DSNFERR:
%VMXGOPTR(OPTNAME=DSNFERR,NEWVALUE=NODSNFERR);
this code executes with NODSNFERR
%VMXGOPTR(OPTNAME=DSNFERR,NEWVALUE=NODSNFERR);
this code executes with NODSNFERR
%VMXGOPTR(OPTNAME=DSNFERR,NEWVALUE=ORIGINAL);
subsequent code executes with DSNFERR.
With the original VMXGOPTR, the subsequent code was
executed with NODSNFERR, which was wrong.
-The report members also set TITLE and FOOTNOTEs to null
to prevent carry-forward for following program reports.
Change 37.251 New DB2STATS variables DELTAAV0/AVA/ACB are negative when
VMACDB2 storage contraction starts, and the value is the number
Nov 7, 2019 of pages needed. Values for Available, DBM1 and DIST are
created. IBM reports, with this ZPARM (xxxxxxxx) "AUTO",
contraction will begin when paging is detected and DB2
will try to bring a system to a point where paging is
minimal or non-existent. DB2 will enter a full
contraction mode if 100% of REALSTORAGE_MAX is hit, when
message DSNS0003I is issued, and the discard will start,
if PM99575 is applied. DB2STATS variable QSST_RSMAX_WARN
counts the number of times the REALSTORAGE_MAX Warning
was reached in each interval.
Thanks to Sieghart Seith, FICUCIA, GERMANY.
Change 37.250 SMF 42 Subtype 5 APAR OA52133 causes ABEND with LENSR=208
VMAC42 in SMF42SRL and a 208 byte segment, APAR OA54663 corrects
Nov 7, 2019 setting SMF42SRL=160 with only a 160 byte segment. New
length was introduced by the usermod ++APAR for OA52133,
when it was still in development, and before OA54663.
-Below Change Text was insufficient to protect for 208,
and logic was completely revised in Change 37.261, 37.09.
To protect for future invalid lengths to avoid ABENDs,
MXG logic first tests for a delta of 160 bytes between
Storage Class Name fields and uses LENSR=160 if true,
or the SMF42SRL value is tested for a valid delta, and
uses that value if true. Otherwise, the record is
skipped with an MXGNOTE on the log.
Thanks to Hiroshige Koshigoe, FTB CA, USA.
Thanks to Sarel Swanepoel, SARS, SOUTH AFRICA.
Change 37.249A The FTP ACCESS method executing on z/OS to read z/OS data
CHCK4FTP fails because the expected JFCB/DSCB tokens do not exist
Nov 22, 2019 with the SAS FTP Access method.
-Most MXG use of the FTP ACCESS method executes on ASCII
to read z/OS SMF data, which does not have this exposure.
-There are two ways to use z/OS to z/OS ftp:
Using SMF as an example DDNAME/INFILE name:
FILENAME SMF FTP "'MYSMFDATA'" HOST='IP ADDRESS'
USER='USERNAME' PASS='PASSWORD' S370VBS LRECL=32760
RCMD='SITE RDW';
%LET MXGJFCB=;
%LET MXGDSCB=;
%INCLUDE SOURCLIB(BUILDPDB);
or
FILENAME SMF FTP "'MYSMFDATA'" HOST='IP ADDRESS'
USER='USERNAME' PASS='PASSWORD' S370VBS LRECL=32760
RCMD='SITE RDW';
%CHCK4FTP(DDNAME=SMF);
%INCLUDE SOURCLIB(BUILDPDB);
-The %CHCK4FTP(DDNAME=yourdd); in example two validates
that that DDNAME is allocated and then detects the engine
type, and for FTP, MXGJFCB and MXGDSCB macro variables
are blanked to prevent the JFCB/DSCB error.
Thanks to Mike Martin, NC State Employee's Credit Union, USA.
Change 37.249 %DSCRDT now defaults to a null value and is enabled by
DODSCRDT using %INCLUDE SOURCLIB(DODSCRDT); in your //SYSIN.
VMXGINIT -These INFILE names can be enabled for these TYPExxxx:
Nov 26, 2019 TYPExxxx: TYPECTLT TYPEDCOL TYPEEDGR TYPERMFV
INFILE: CONTROLT DCOLLECT EDGHSKP RMFBSAM
TYPExxxx TYPETMS5 TYPEIMS
INFILE: TMC IMSLOG
See change 37.161 for the original addition.
Change 37.248 Unused Change Number.
Nov 4, 2019
Change 37.247 Example analysis to track down why USERID was revoked.
TECHNOTE
Nov 4, 2019
SUMMARY: Userid for an inbound FTP process had the wrong password,
eventually userid was revoked, but the MVS RACF SYSLOG message was
misleading, as it was expected to be a VTAM LU, but it is the value
"A86CF325" in message that matches the RACFTERM:
MVS SYSLOG excerpt
ICH408I USER(FCADOU4 ) GROUP(ADOFTP ) NAME(FTPS ID CDS T4) 546
LOGON/JOB INITIATION - INVALID PASSWORD ENTERED AT TERMINAL A86CF325
IRR013I VERIFICATION FAILED. INVALID PASSWORD GIVEN.
MXG TYPE8001
RACF*USER*NAME [RACFUSER] FCADOU4
EVENT*CODE*QUALIFIER [RACFQUAL] 101:INVALID PASSWORD
RACF/VTAM*TERMINAL*NAME USED [RACFTERM] A86CF325
MXG VMAC80A: INPUT RACFTERM $EBCDIC8. /*@43 SMF80TRM*/
RACF MACROS and INTERFACES Documentation
SMF80TRM 8 EBCDIC Terminal ID of foreground user (zero if not avail)
MXG TYP11902
CONNECTION*ESTABLISHMENT [TTSTIME] 26OCT2019:09:03:17.99
TIMEWAIT OR*LASTACK [TTETIME] 26OCT2019:09:03:18.22
REMOTE*IPV6*ADDRESS [TTRIPV6] 0000:0000:0000:0000:0000:FFFF:A86C:F325
(matches RACFTERM from Type 80, and the MVS RACF ICH408I message)
Change 37.246 Dataset ZRBPCI variables PCIFTET and PCIFTQT were input
VMACRMFV incorrectly as milliseconds (PIB8.3) units, but they are
Oct 31, 2019 both microseconds (PIB8.6), with TIME13.3 print format.
Change 37.245 If you KEEPALL=NO or %LET MXGKEEP=NO and your VMXGSUM
VMXGSUM invocation had an INCODE= you might have gotten an
Oct 30, 2019 UNINIT message on one or more variables in the INCODE
that were not also referenced in one of the parameters.
This change modifies KEEPALL to YES if INCODE is used.
Change 37.244 Observations from Subtype 3 SMF 119 records were not
VMAC119 output because some of the Production UserIds did not
Oct 30, 2019 have read access to the SMF unix Facility, which is
required for SMF record to be written.
Thanks to Aslyona Bertneski, Express-Scripts, USA.
Change 37.243 Variables SMF70LACM SMF70LACA and SMF70LACB are now kept
VMAC7072 in TYPE70PR dataset to aid in SCRT comparisons. They
Oct 28, 2019 have been in TYPE70 since Version 33.
Thanks to Ken Deering, Compuware, USA.
Change 37.242 Support for BMC SMF79 Subtype 255 creates new dataset:
EXTY79FF DDDDDD Dataset Description
FORMATS TY79FF TYPE79FF BMC SMF 79 SUBTYPE 255
IMAC79
VMAC79
VMXGINIT
Oct 28, 2019
Thanks to Randy Hewitt, DXC, USA.
Change 37.241 Several MG082xx format for SMF 82 records had wrong hex
FORMATS value displayed, but the text description was correct.
Oct 27, 2019
Thanks to Ron Rust, Worldpay, USA.
Change 37.240 DB2 Variable QWP4STPGS='STATPGSAMP/N/Y/S' was not INPUT
VMAC102 in T102S106 dataset.
Oct 24, 2019
Thanks to Lai Fai Wong, Bank of America, USA.
====== CHANGES THRU 37.239 WERE IN MXG 37.07 DATED Oct 22, 2019 ========
Change 37.239 Support for z/15 SMF113 records new CRYPTO17-CRYPTO20
VMAC113 counters (ERROR: ARRAY SUBSCRIPT OUT OF RANGE ABEND),
Oct 22, 2019 only if you had enabled the HIS CRYPTO counters.
Thanks to Steven W Erkkila, USBANK, USA.
Change 37.238 Support for NDM-CDI 'S#' record type is now output in
VMACNDM existing NDMAE dataset.
Oct 16, 2019
Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.
Change 37.237 Cosmetic. STARTIME syntax modified to eliminate notes
ASUM42DS from VMXGSUM internal invocation.
Oct 15, 2019
====== CHANGES THRU 37.236 WERE IN MXG 37.07 DATED Oct 14, 2019 ========
Change 37.236 Support for z/15 SMF 113 records new EXTEND256-EXTEND287
ANALSIIS counters, with corresponding ARRAY size increases, CAUSED
VMAC113 ERROR:ARRAY SUBSCRIPT OUT OF RANGE ABEND. In ANALSIIS,
Oct 14, 2019 SORT order was corrected.
Thanks to Tony Curry, BMC, USA.
====== CHANGES THRU 37.235 WERE IN MXG 37.07 DATED Oct 12, 2019 ========
Change 37.235 CRITICAL ERROR if BLDSMPDB+VMXGALOC is used on ASCII.
BLDSMPDB An ending comma in line 949 of BLDSMPDB caused
Oct 12, 2019 ERROR: All positional parameters must precede keyword.
Remove the comma in line 949 of BLDSMPDB.
====== CHANGES THRU 37.234 WERE IN MXG 37.07 DATED Oct 9, 2019 ========
Change 37.234 DB2 variables added to DB2ACCT and DB2STATS datasets:
VMACDB2 QXSTEHLST='EXECUTION*HISTORY.LOST'
Oct 8, 2019 QXSTHVLST='HV*RECORDING*HISTORY*LOST'
QXRFMIAP='RID*LIST*PROCESSING*NOT USED'
Thanks to Warren Cravey, Fidelity, USA.
Change 37.233 CICS variable ABCODE created by UTILEXCL was the concat
UTILEXCL of ABCODE113!!ABCODE114, but using INPUT ABCODE $EBCDIC8.
Oct 8, 2019 eliminated the need for that statement, which caused
ERROR: The name ABCOD113§§ABCOD114 is not a valid SAS name
when UTILEXCL was run on Linux. A track with SAS will be
opened to resolve that error, because double exclamation
points are used 6900 times in MXG for concatenation, but
this code matches the VMAC110 code and should have been
there some time ago, just for consistency, but now for
circumvention.
Change 37.232 -If CICS Dynamic Transaction Routing, DTR is used, the
VMAC110 CICSTRAN has PROGRAM='########' which historically was
VMXGINIT ONLY used when there was an invalid transaction name
Oct 9, 2019 typed in by the user, which caused many fields to be
missing values, so MXG instead output the transaction
to the CICSBAD dataset. But now, if you enable DTR,
the observation count in CICSTRAN may drop dramatically
by the number of obs output in CICSBAD. There does not
appear to be a flag that identifies DTR was used.
You will need to set
%LET MXGCICSDTR=YES;
to cause MXG to output ALL transactions with '########'
values to CICSTRAN instead of to CICSBAD.
-The original test for CICSBAD also tested TRANFLAG for
a bit that indicated invalid times in the record, but
IBM removed that bit, so that bit test was removed.
-Changes 23.312 and 24.155 document PROGRAM='########';
Thanks to Scott Barry, SBBWORKS, INC, USA.
Change 37.231 z/VM 6.4.18.2 BROKEN CONTROL RECORD in IODVSW extended
VMACVMXA INPUT for SKIP GE 20 was missing the @ at the end.
Oct 7, 2019
Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.
Change 37.230 If you specified DURATM=INTERVAL with INTERVAL= values of
VMXGSUM TWOMIN THREEMIN or TWENTYMIN the DURATM was not created.
Oct 6, 2019
Change 37.229 Doc only change - corrected spelling and syntax.
ANALCAPD
Oct 5, 2019
Change 37.228 -Format $MGRMIPS is updated for the z/15 processor type
ASUMMIPS 8561 to map the CPCFNAME ('8561-401') to the MIPS per MSU
FORMATS value (267), used in ASUMMIPS and other 'MIPS' calcs.
Oct 5, 2019 -Protection for CPCFNAME not found in $MGRMIPS format now
gracefully terminates with a message from ASUMMIPS.
Change 37.227 QLACRLNU was not added to DB2ACCTB nor DB2ACCTG causing
VMACDB2 UNINIT messages in ASUMDB2B and ASUMDB2G.
Oct 4, 2019
Change 37.226 TYPE 120 dataset TY120100 variables SM120RULEXCALLS (was
VMAC120 always -1) and SM120RULEXFSUM were in the wrong order in
Oct 3, 2019 the INPUT statement.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 37.225 RMM/EDGR dataset EDGRXEXT variable RDPHYSIZE was not
VMACEDGR multiplied by the RDFACTOR(KB/MB/GB) so it was too small.
Oct 1, 2019 The value was correct in the other EDGR datasets.
Thanks to Bradley Leis, TELUS, CANADA.
Change 37.224 If you correctly added VMXGALOC to your IMACINIT so that
VMXGALOC you would always have the current PDBs allocated to each
BLDSMPDB SAS/MXG session and changed the number of PDBs (daily,
Oct 1, 2019 weekly, monthly, etc.) in BLDSMPDB you could possibly
wipe out old directories unintentionally. VMXGALOC now
detects that it has already run and unless the new
INVOKEBY= parameter is set to bldsmpdb sets the READONLY
parameter to YES to prevent deletion of old directories.
VMXGALOC in IMACINIT should always specify READONLY=YES
so this is only insurance that will produce and MXGWARN
message and set condition code 8.
Change 37.223 DB2 IFCID 376 variable QW0376SINR (statement count) was
VMAC102 not kept in 8 bytes, causing small differences in the
Sep 30, 2019 MXG value (222986880) vs IBM (222986962) = 82 smaller.
With stored length of 8 bytes, the values match.
Thanks to Warren Cravy, FMR, USA.
Change 37.222 Support for SAP Z Connector USER SMF Record creates
EXSAPZCO DDDDDD DATASET DESCRIPTION
IMACSAPZ SAPZCO SAPXCO SAP Z CONNECTOR
TYPESAPZ
TYPSSAPZ
VMACSAPZ
VMXGINIT
Sep 30, 2019
Thanks to Nestor D Rossi, BancoGalica, ARGENTINA.
Change 37.221 Reserved Change.
Change 37.220 If you specified SYNC59=NO (the default) the intervals
VMXGDUR always landed (for example with INTERVAL=QTRHOUR) on the
Sep 26, 2019 quarter at 0 15 30 45 minutes. If you wanted to keep the
actual intervals you would have needed to subtract 1
minute. VMXGDUR will now do that for you with the new
USE59 parameter. YES will subtract 60 seconds from the
calculated value and get the QTRHOUR back to 59 14 29 44
minutes. You can implement this globally be inserting in
IMACINIT: %LET SYNCTO59=YES;
The purpose of SYNC59 was always to put the start of
intervals on the hour since that usually makes more sense
on management reports and graphs. But if you choose to
use this on interval data without modifying the FLORCEIL
parameter to CEIL and you use SYNC59=NO you will be
getting the STARTIME of the prior interval rather than
the current interval since 12:59 with the FLORCEIL=FLOOR
set resolves to 12:45:
FLOOR('12:59't/900)*900;
Examples using default of SYNC59=NO
FLORCEIL=FLOOR
TIMESTMP=29AUG18:12:59:00 datetime=29AUG2018:12:45:00
FLORCEIL=FLOOR USE59=YES
TIMESTMP=29AUG18:12:59:00 datetime=29AUG2018:12:44:00
FLORCEIL=CEIL
TIMESTMP=29AUG18:12:59:00 datetime=29AUG2018:13:00:00
FLORCEIL=CEIL USE59=YES
TIMESTMP=29AUG18:12:59:00 datetime=29AUG2018:12:59:00
Thanks to Randy Hewitt, DXC, USA.
Change 37.219 Support for CA-DISK/Sterling DMS file DSNINDEX.
EXCAARCH INFILE is CADISK, creates two new dataset:
EXCADISK DDDDDD DATASET DESCRIPTION
FORMATS CADISK CADISK DSNINDEX ARCHIVED OR BACKED UP.
IMACCADK CAARCH CAARCH ARCHLOGS ARCHIVED DATASETS.
TYPECADK -Invalid LEAP YEAR dates (year 2025, day 366) can't be
TYPSCADK set to a numeric value, variable DSNDS1EDLEAP will now
VMACCADK have the invalid date as character (2026366).
VMXGINIT
OCT 2, 2019
OCT 30, 2019
Thanks to Pierre-Pascal Joulin, SOCGEN, FRANCE.
Change 37.218 DURATM=INTERVAL conflicted with DURATM in the SUM=
ASUMMIPS parameter which raised an MXGWARN message. DURATM
SEP 26, 2019 was removed from the SUM= list.
MXGWARN: DURATM=INTERVAL WAS SPECIFIED BUT THE DURATM
MXGWARN: VARIABLE CONTAINS NON-MISSING VALUES. THIS
MXGWARN: MAY BE AN ERROR CONDITION. VALUE OF DURATM
MXGWARN: IN THE OUTPUT DATA IS: 0:15:00.00
Change 37.217 A test of EXCELDEST was not protected for length of 0
ANALMSUS and generated a WARNING message but still ran albeit
Sep 26, 2019 with condition code 4.
Thanks to Robert Sample, TOMY, USA.
Change 37.216 SMF Type 2 Subtypes 1 and 2 fields SMF2GSIG and SMF1ISIG
TYPE0203 were documented as 512 bytes long, but IBM updated their
Sep 26, 2019 doc that they are variable length fields, so the INPUT
is revised to use the SMF2GSIGLEN and SMF2ISIGLEN fields
to input the variable length data.
Change 37.215 Updates for FOCUS USER SMF record changes version 7.7.
ADOCFOCU -VMACFOCU was changed to accommodate a change by IBI in
FORMATS their SMF records somewhere around version 7.7 of
VMACFOCU WebFOCUS (vendor support wasn't clear about when the
Sep 25, 2019 change happened).
Nov 14, 2019 -User ID fields were changed from 8 to 20 bytes and a
'security provider' value was prepended to each user ID
with a '\' as separator. These changes caused other
fields in the SMF record to be in different columns than
they were previously. Fields were also added for zIIP
time and zIIP-on-CP time.
-There is no version field in the SMF record, so this code
uses the record subtype and the length of the record to
determine which record format to use. There are four
subtypes - 1,2,4, and 5, which are Logon, Logoff, Begin
Query, and End Query, respectively. Old format records
are shorter than new format records, so the code checks
to see if a record is shorter than the new format, and if
it is, uses the old format. Older format records will
have missing or blank values for old variables that no
longer exist in the new records.
-Each user ID variable (Logon User ID, Security User ID,
Pooled User ID) now has a corresponding security provider
variable. The provider will be blank if an older format
record was used.
-zIIP time and zIIP-on-CP time variables are normalized,
according to the vendor. We are not sure of the accuracy
of these fields, and would not count on them for serious
reporting.
-Members ADOCFOCU and VMACFOCU were changed to reflect
these changes. Some labels were changed to reflect that
these records are produced by the vendor's WebFOCUS
product in addition to the FOCUS MSO (Multi-System
Option). In addition two new values are added in the
new MGFOCTY format to reflect subtypes 4 (Begin Query)
and 5 (End Query).
Thanks to Tim Hare, Hare Systems, USA.
Change 37.214 ANAL82AU combines the separate SERV and USER observations
ANAL82AU into one observation with two sets of variable names.
Sep 25, 2019
Thanks to Alexander Bitter, Worldpay, USA.
Thanks to Rib Rust, Worldpay, USA.
Thanks to Brian Bowling, Worldpay, USA.
Change 37.213 Support for RACF 80A TOKDANAM=AUTOLOGIN creates new
VMAC80A variable TOKAUTOLOGIN in TYPE80TK dataset.
Sep 24, 2019
Thanks to Andrew Krink, Northern Territory Government, AUSTRALIA.
Change 37.212 Support for z15 processor SMF 113 RNI equation changed to
ASUM113 RNI=2.9*(0.45*L3P+1.5*L4LP+3.2*L4RP+6.5*MEMP)/100;
VMAC113
Sep 23, 2019
Change 37.211 Updates to TYPERMFV.
IMACRMFV -Variable PCIFTYPHEX added to ZRBPCI dataset.
VMACRMFV -Support for XCFG3 segment creates three datasets
Oct 2, 2019 that contain the same data as RMF I XCF records:
DDDDDD DATASET DESCRIPTION SAME DATA
ZRBXCG ZRBXCG RMF III XCF GROUP TYPE74ME
ZRBXCP ZRBXCP RMF III XCF PATH TYPE74PA
ZRBXCS ZRBXCS RMF III XCF SYSTEM TYPE74SY
Change 37.210 If the default requested INTERVAL=_CICINTRV (HALFHOUR)
CICINTRV doesn't match your actual CICS Statistics interval, or
Sep 20, 2019 isn't an exact integer multiple, MXG printed a warning
that the resultant CICINTRV dataset was invalid, as it
built using your _CICINTRV value.
Now, your _CICINTRV value is compared with the maximum
DURATM in your data, and if your requested _CICINTRV can
be honored it will be; otherwise the interval of your
data is used, and a warning of the change is printed.
Change 37.209 Spurious log messages INVALID VALUE FOR INPUT FUNCTION
DODSCRDT that occur only if INFILE is on TAPE are harmless with no
Sep 19, 2019 impact on the output MXG datasets. Thought removed by the
Aug 30 MXG 37.06 Change 37.189, they weren't until this.
Thanks to Betty Wong, Bank of America, USA.
Change 37.208 ID & 89 added to the list of product suffix found in your
UTILBLDP USERADD= argument that are already in BUILDPDB=YES and
Sep 19, 2019 would have caused an error if honored.
Thanks to Randy Hewitt, DXC, USA.
Change 37.207 -New format MG110XL is created for UCICSCNT report so you
QA9464 can choose the display of the CICS STID variable:
UCICSCNT MG110XN - IBM Description: 2:Storage Manager DSA
UTILVREF MG110XD - MXG Dataset Name 2:CICSMDSA
FORMATS MG110XL - MXG Dataset + Label 2:CICSMDSA:SMS STATS
VMXGINIT The existing default MG110XN format is unchanged.
Sep 18, 2019 In your SYSIN %LET UCICSFMT=MG110XD.; sets your choice.
-New format $MGDSNLAB maps MXG Dataset Name to the Dataset
Label for all MXG datasets.
Thanks to MP Welch, Bank of America, USA.
Change 37.206 BUILDPDB PDB.STEPS & PDB.JOBS are enhanced with variable
BUILD005 CPUZIPTM_CPUIFATM_INST to count zIIP instructions; the
BUIL3005 CP instruction count is already in variable CPU_INST.
Sep 13, 2019
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 37.205 TYPE71 LFAREA 1Mb FRAMES can be broken up into smaller
VMAC71 pages, and the number of BrokenUP frames is in the new
Sep 13, 2019 variable SMF71BRKUP='PGBL 1MB*BREAKUP*FRAMES', calculated
as the delta between installed 1MB Pageable frames and
the used 1MB frames.
Thanks to Joe Faska, DTCC, USA.
Thanks to Toni Skrajnar, IBM Support, USA.
Change 37.204 -z/OS 2.4 MXG RMF Monitor III support.
ADOCRMFV -New MXG Support for RMF III XCRG3 table:
ASMRMFV -New ASMRMFV Field Data Filtering (FDF) support for
VMACRMFV 4 more RMF III tables: CPDG3 ENTG3 GEIG3 OPDG3.
Sep 12, 2019 -15 ASMRMFV corrections for conditions found during
Sep 20, 2019
Sep 26, 2019
Oct 3, 2019 *** New Support ***
Oct 8, 2019
-Support for the RMF Monitor III Cryptographic Hardware
Data table (CRYG3) table new with z/OS 2.4 . The CRYG3
table does not exist for prior z/OS releases.
-The CRYG3 selection option is CRY (alias K).
The CRYG3 filtering option is NOCRY (aliases -CRY, -K).
CRYG3 is also selected if the MOST option is used.
-Support for the RMF Monitor III XCF Activity Data table
(XCFG3) which has existed at least since z/OS 1.13 but
was undocumented.
-The XCFG3 selection option is XCF (alias X).
The XCFG3 filtering option is NOXCF (aliases -XCF, -X).
XCFG3 is also selected if the MOST option is used.
-FDF support added for the RMF III Channel Data table
CPDG3. Information on CPD FDF filtering appears in
Section 33 Filtering The CPD Table in the ADOCRMFV
documentation member. There is a data dictionary listing
all the CPDG3 field names supported by FDF.
-FDF support added for the RMF III Enqueue Name table
ENTG3. Information on ENT FDF filtering appears in
Section 37 Filtering The ENT Table in the ADOCRMFV
documentation member. There is a data dictionary listing
all the ENTG3 field names supported by FDF.
-FDF support added for the RMF III OMVS Process Data table
OPDG3. Information on OPD FDF filtering appears in
Section 39 Filtering The OPD Table in the ADOCRMFV
documentation member. There is a data dictionary listing
all the OPDG3 field names supported by FDF.
-FDF support added for the RMF III General Information
table GEIG3. Information on GEI FDF filtering appears in
Section 38 Filtering The GEI Table in the ADOCRMFV
documentation member. There is a data dictionary listing
all the GEIG3 field names supported by FDF.
-Support for new release z/OS 2.4 RMF III fields added to
existing FDF Variable Name Tables.
*** Enhancements ***
-FDF support expanded for up to 256 byte character fields
raised from 8 bytes. But FDF IF expressions for
character field filtering may still not exceed the actual
size of the field or an error is flagged.
-Pattern matching subroutine MATCH now supports up to 256
characters in a pattern.
-FDF now translates X'00' to blank X'40' for selected
character field source data fields similar to what the
VMACRMFV SAS member does during a PDB build.
-Messages RMFV080I and RMFV088I now support character
string displays up to 105 characters. Longer character
strings are either output as a separate message or a '+'
flag is shown in the last byte of the message to indicate
the message has been truncated.
-Messages RMFV080I and RMFV088I now show tags of 'SFP' for
short floating point fields or 'LFP' for long floating
point fields instead of only showing 'FP'.
-Messages RMFV080I and RMFV088I now show the full IF
expression used if space allows.
-The SHOWBYTE subroutine now supports formatting of
storage byte values in kibibytes (kilobytes) 1024 through
yobibytes (yottabytes) 1024**8 in message RMFV088I.
However, current implementation restrictions at this time
limit values to a maximum of 9,223,372,036,854,775,807 or
about 1.22 pebibytes (petabytes).
-These documentation sections in member ADOCRMFV are all
updated for new support, enhancements, z/OS 2.4 and
corrections:
2 Terminology
3 Execution JCL
4 RMF III Table Selection Parameters
5 Input Data Selection Parameters
6 Report Control Parameters
7 Output Data Control Parameters
8 Error Handling Parameters
9 JCL and SYSIN Parameter Usage
12 Messages
13 Filtered Records
15 Program and IBM Limitations
21 Extended ASIG3/ENCG3/RCDG3/UWDG3 Record Support
22 RMF III VSAM Data Set Index Usage and Sizing
23 RMF III Options That Effect Data
24 RMF III Sysplex Master Gatherer
25 Ranges and Patterns
26 ASMRMFV and MXG PDB Data Relationships
31 Field Data Filtering (FDF)
32 Filtering The ASI Table
33 Filtering The CPD Table
34 Filtering The CSR Table
35 Filtering The DSI Table
36 Filtering The DVT Table
37 Filtering The ENT Table
38 Filtering The GEI Table
39 Filtering The OPD Table
40 Filtering The SPG Table
41 Filtering The SSH Table
42 Summary
43 Bibliography
*** Corrections ***
-All of these possible corrections apply to ASMRMFV in
MXG Versions 37.03-37.06.
-The last character of the 3 character day name in message
RMFV041I was truncated.
-Hex characters used in IF expressions for character
fields were not handled correctly.
-FDF IF expression numeric values with both a fraction and
exponent were not correctly scaled in subroutine IFNUM.
-Possible S0C7 Abend with large IF expression numeric
value and a Scale Multiplier in FDF IFNUM subroutine.
-Possible S0C7 Abend in FDF IFNUM subroutine processing
short or long floating point values.
-Possible Abend S0C4 in FDF SETIF subroutine because VNT
extension length was not added to base VNT entry length
to determine when IF entry array expansion was required.
-Incorrect formatting for a fixed binary number with a
fraction in FDF RMFV088I message.
-Incorrect digit shifting for fixed binary numbers in FDF
IF expression coded with a fractional part.
-Abend S0C4 in FDF SETIF subroutine when NOSHOWARR option
(default) was in effect and an IF array expansion
occurred.
-Possible S0C4 Abend in FDF SETIF subroutine when the
fieldname in an FDF IF expression was an alias.
-Incorrect formatting of some fractional numbers by
SHOWDEC subroutine in RMFV088I messages.
-Message RMFV088I after a FDF floating point precision
loss is detected incorrectly showed the original user IF
expression value instead of the true floating point value
actually in effect for comparisons.
-FDF subroutine IFNUM did not shift out any fractions from
the original user value in the IF expression to create an
integer when determining whether a floating point
precision loss had occurred.
-Possible incorrect byte display in FDF RMFV088I message
from SHOWBYTE subroutine for large values.
-Possible S0C1 Abend if a Fieldname entry in a FDF
Variable Name Table incorrectly has an alias equal to
itself.
*** FDF Limits ***
These are the current FDF supported limits for Change
37.204 as FDF IF expression values.
In no case may the IF expression value exceed the size of
the RMF III source field whether numeric or character.
Field Type Value range
---------- -------------------------------------------
Fixed Binary
1 byte 0-255
X'00'-X'FF'
2 byte 0-65,535
X'0000'-X'FFFF'
4 byte 0-4,294,967,295
X'00000000'-X'FFFFFFFF'
8 byte 0-9,223,372,036,854,775,807 *
X'0000000000000000'-X'7FFFFFFFFFFFFFFF' *
* the limit for a 8 byte binary number is imposed by the
need for ASMRMFV to convert the input number to binary.
A grande 64-bit register only holds X'7FFFFFFFFFFFFFFF'
as a high order sign bit is required.
Floating Point **
4 byte 0-9,223,372,036,854,775,807
8 byte 0-9,223,372,036,854,775,807
** the limit for a floating point number is imposed by
the need for ASMRMFV to convert the input number to
binary before conversion to floating point. A grande
64-bit register only holds X'7FFFFFFFFFFFFFFF' as a high
order sign bit is required.
Bit String
1 byte 0-255
X'00'-X'FF' without don't cares
1 byte .......0-1111111. with don't cares
Percentage 0.0-100.0
Time of Day 01JAN2000:00:00:00-17SEP2042:23:53:46 ***
*** The of day limit is imposed by the 64 bit TOD clock
which wraps to all binary ones in September 2042. The
addition of leap seconds may affect this value.
Time ****
4 byte 0-4,294,967,295
X'00000000'-X'FFFFFFFF'
8 byte 0-9,223,372,036,854,775,807
X'0000000000000000'-X'7FFFFFFFFFFFFFFF'
**** Time units depend on the default time unit for the
RMF III field or the explicit time unit coded by the
user. They can range from microseconds to days.
TOD date only 01JAN2000-17SEP2042
TOD Time only 00:00:00-23:59:59
Change 37.203 Unused Change Number.
Sep 11, 2019
Change 37.202 Support for truncated SMF 61 catalog record from z/OS 2.3
VMAC6156 causing INPUT STATEMENT EXCEEDED error.
Sep 9, 2019
Thanks to Mike Jacques, BB&T, USA.
Change 37.201 The MGBYTES format is extended to decode storage units in
FORMATS zettabytes and yottabytes.
Sep 27, 2019
Change 37.200 Optional CICSTRAN DBCTL segment variable STATCTM1 was
IMACICDB 10 times too large (4 usec should be 0.4 usec) due to
Sep 9, 2019 incorrect STCK informat, corrected to TU4.
Thanks to Scott Barry, SBBWorks, INC., USA.
Change 37.199 -Variables QWACPCTT/QLACRLNU are used to get the correct
VMACDB2 count of THREADS when ROLLUPS (DB2PARTY=R) are in use:
ASUMDB2A DB2ACCT variable QWACPCTT is summed into THREADS in
ASUMDB2B ASUMDB2A unless QLACRLNU is GT 0 and used instead.
ASUMDB2G DB2ACCTP variable QPACRLNU is summed into PACKCNT in
ASUMDB2P ASUMDB2P
ASUMDB2R DB2ACCTB variable QWACPCTT is summed into THREADS in
Sep 7, 2019 ASUMDB2B unless QLACRLNU is GT 0 and used instead.
Sep 16, 2019 DB2ACCTG variable QLACPCTT is summed into THREADS in
ASUMDB2G unless QLACRLNU is GT 0 and used instead.
DB2ACCTR variable QLACRLNU is summed into THREADS
-Previously THREADS in DB2ACCT and COUNT in DB2ACCTP
counted each record; so counts will be larger and
correct in the ASUMs and in ANALDB2R which uses them,
unless the count is one, which does happen.
-This change means that the average values reported in
ANALDB2R will be more accurate but it still precludes
detail problem analysis from rolled up records since
the best you can get is an average value.
Variable QWACPCTT is now kept in DB2ACCTB/DB2ACCTG/
DB2ACCTR so it can be used in those ASUMs.
Change 37.198 BETA 93 Subtypes 12,17,30,31,55 were not input because
VMACBETA they weren't added to the IF SUBTYPE IN list of subtypes,
Sep 11, 2019 and they were not sorted to the PDB data library.
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 37.197 BETA 97 Subtype 51 Dataset BETA9751D did not input the
VMACBE97 "New Area" fields for BETA9751REC='U', UPDATE records.
Sep 11, 2019 An undocumented test to skip U records was removed.
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 37.196 Member IMACTIME and CHANGESS had references to "OKJOB"
IMACTIME that should be OKFLAG for consistency; no impact as the
CHANGESS member is optional and "OKJOB" is in comments.
Sep 5, 2019
Thanks to Scott Barry, SBBWorks, INC., USA.
Change 37.195 The PDB.PRINT dataset ACCOUNT variables were populated
BUILD005 only in the first observation for each job, and TYPETASK
Sep 5, 2019 had the SUBSYS6 value (PSF/VPS) instead of TYPETASK (JOB)
Thanks to Scott Barry, SBBWorks, INC., USA.
Change 37.194 Formats added for TYPE42DS variables S42DSENT/S42DSCMT to
FORMATS decode the Encryption Type and Compression TYPEs.
VMAC42 ET=AES-256,CT=None/Generic/Tailored/zEDC.
Sep 3, 2019
Thanks to Luis Mendoza, BKFS, USA.
Change 37.193 Format $MG110EX for dataset CICSEXCE variable EXCMNTYP
FORMATS did not map value '0004'X to 04:POLICY THRESHOLD instead
Sep 3, 2019 printing a confusing '00'X value.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 37.192 TLMS dataset TYPETLMS from the "B" record is updated and
EXTYTLMC two new TLMS datasets TYPETLMC/TYPETLMD are now created
EXTYTLMD from the "C" and "D" TLMS records:
IMACTLMS DDDDDD DATASET DESCRIPTION
VMACTLMS TYTLMC TYPETLMC MASTER FILE CONTROL RECORD
VMXGINIT TYTLMD TYPETLMD VOLUME MASTER FILE MULTI DATASET
Sep 25, 2019
Thanks to Pierre Pascal Joulin, SOCGEN, FRANCE.
Change 37.191 RMM/EDGR processing in VMXGDSN had zero obs for TAPES and
VMXGDSN TAPEDSNS MXG 37.03-MXG 37.06; the SORT input dataset was
Sep 2, 2019 incorrectly changed to EDGRDEXT instead of EDGRXEXT.
Thanks to Wayne Bell, UNIGROUP, USA.
Thanks to John Fulton, UNIGROUUP,USA
====== CHANGES THRU 37.190 ARE IN MXG 37.06 DATED AUG 30, 2019 =========
Change 37.190 New macro %MXGFINFO creates dataset EXTFILES with these
MXGFINFO variables for every external filename (INFILE)
Aug 30, 2019 -z/OS: FILEREF DSNAME DEVICE and CREATEDATE
-ASCII FILEREF XPATH and CREATEDATE.
CREATEDATE will be missing if the ftp access method is
used.
Change 37.189 Spurious INVALID VALUE FOR INPUT FUNCTION in first 37.06
DODSCRDT had no impact, except for lots of lines on the log. It
Aug 30, 2019 occurs when the INFILE is on TAPE, because the DSCB that
SAS returns is the VOL2HDR instead of the date-containing
DSCB, so the CREATEDATE variable is always missing for
INFILE on Tape.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 37.188 Example 2 had a Missing "END;" statement
IMACUOW
Aug 29, 2019
Change 37.187 Labels for Tennant TRG_SUCP,TRG_SUIFA,TRG_SUSP variables
VMAC7072 are changed from *MSU* to *HDW MSU* because those values
Aug 29, 2019 are NOT the Software MSU (4HR AV) we normally use when
discussing MSU. This link shows IBM uses the "Hardware"
SU_SEC value to convert those service units to engine
counts:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/
com.ibm.zos.v2r3.izsc100/cserbb200195.htm
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 37.186 Support for IBM Tivoli Advanced Allocation Management SMF
EXTYAAM1 record; this product replaces the old X37 product.
EXTYAAM3 DDDDDD DATASET DESCRIPTION
FORMATS TYAAM1 TYPEAAM1 SUBSYSTEM ACTIVITY
IMACAAM TYAAM3 TYPEAAM3 PROCESSING ACTIVITY
TYPEAAM Subtype 3 have been data tested; IBM provided additional
TYPSAAM bit values for DNV/DST/ADP and reported SPCF incorrectly
VMACAAM sets '80'x bit causing 'C0'x for TRACKS, to be corrected,
VMXGINIT but MXG's format maps both 'C0'x and '40'x to TRACKS.
Aug 28, 2019 Subtype 3 event records have only SMFTIME & JOB (AAMJBN),
Sep 24, 2019 no READTIME nor JCTJOBID/JESNR, so they can not be easily
interleaved/merged with other JOB-related records.
Thanks to Cha Kihun, Navy Federal, USA.
Thanks to Richard Champouillon, Navy Federal,USA
Change 37.185 Warning: APPARENT SYMBOLIC REFERENCE LDB and LDB@ACG has
READDB2 no impact on the results, DB2ACCTG is correctly sent to
Aug 23, 2019 your LDB2ACG= argument with correct message text.
Thanks to Douglas C. Walter, CITIGROUP,USA.
====== CHANGES THRU 37.184 ARE IN MXG 37.06 DATED AUG 22, 2019 =========
Change 37.184 Delete of temp dataset SRTIRC was relocated so it is
VMXGCICI always deleted (to free WORK space).
Aug 14, 2019
Change 37.183 Support for SMF 82 subtypes 30 and 40-48 new datasets
FORMATS DDDDDD DATASET DESCRIPTION
EXTY82AU TY8230 TYPE8230 KDS ARCHIVE/CRYPTOPERIOD
EXTY8248 TY8240 TYPE8240 CCA SYMMETRIC KEY LIFECYCLE
IMAC82 TY8241 TYPE8241 CCA ASYMMETRIC KEY LIFECYCLE
VMAC82 TY8242 TYPE8242 PKCS#11 KEY LIFECYCLE EVENT
VMXGINIT TY8243 TYPE8243 RCS CONFIGURATION CHANGE (not decoded)
Aug 21, 2019 TY8244 TYPE8244 CKDS KEY USAGE
Aug 27, 2019 TY8245 TYPE8245 PKDS KEY USAGE
Oct 30, 2019 TY8246 TYPE8246 PKCS#11 KEY USAGE
TY8247 TYPE8247 PKCS#11 NOKEY USAGE
TY8248 TYPE8248 WARN MODE
Subtype 43 is not decoded, pending test data records.
Subtypes 40,41,44,45,48 have been tested.
Subtypes 42,46,47 are decoded but not tested.
Thanks to Alexander Bitter, Worldpay, USA.
Thanks to Lethika Panicker, Worldpay, USA.
Thanks to Ron Rust, Worldpay, USA.
Change 37.182 Variable SMF74SCMR was incorrectly spelled SMF74SKCR.
VMAC74
Aug 14, 2019
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 37.181 Support for Hitachi MAR Mainframe Analytics Recorder 9.1
EXMAR07 creates new MARST07 PARM Section Dataset.
IMACMAR
VMACMAR
VMXGINIT
Aug 13, 2019
Change 37.180 MXG DB2 Formats $MGTMDOB, $MGTMDRM, $MGTMDRE, MGTMDRC are
FORMATS updated with new values.
Aug 13, 2019
Thanks to Randy Hewitt, DXC, USA.
Change 37.179 TYPE72GO variables METGOAL and PCTMETGO were wrong, now:
VMAC7072 IF TRANS GT 0 THEN DO M=1 TO 6;
Aug 9, 2019 METGOAL=SUM(METGOAL,RTSTRN(M));
PCTMETGO=100*METGOAL/TRANS;
END;
ELSE PCTMETGO=.;
Thanks to James Peddycord, Northern Trust, USA.
Thanks to Karl S. Huf, Northern Trust, USA.
Thanks to Arati Khodaskar, IBM Global Services, USA.
Change 37.178 -MXG 37.05 only, possible S0C4 Abend in ASMRMFV PROCSSH
ASMRMFV subroutine when comparing current RMF Version to a z/OS
Aug 9, 2019 2.3 Version number, after Change 37.140.
Aug 20, 2019 -That PROCSSH code was redundant with similar code in the
FINDPOL subroutine that is RMF Version independent and
has been removed to eliminate the S0C4 possibility.
-MXG 37.03-37.05, ONLY if you use FDF IF expressions.
ABEND S0C7 when a hex value is coded for a numeric field
in an FDF IF expression. For example: IF=(ASIDP EQ X'FF')
-Incorrect handling of exponents when coded for a numeric
field in an FDF IF expression causing an incorrect
compare value to be calculated.
For example: IF=(ASI1MBFF GT 1E2)
-Invalid hex value can be shown in RMFV080I and RMFV088I
messages.
Thanks to Kurt Gramling, GTS Tech-Support: CRM, USA
Change 37.177 Variables R745BYTR/BYTW/RTIR/RTIW were never populated by
VMAC74 IBM, as they were replaced by R7451CT1-R7451CT4, but they
Aug 8, 2019 are now populated by those replacement values rather than
being missing values. See Change 23.314.
Thanks to Otto Burgess, OPM, USA.
Change 37.176 Support for IMS LOG '02'x record creates IMS02 dataset or
EXIMS02 prints a message if a multi-segment command record is
VMACIMS found to send your IMSLOG so it can be supported.
VMXGINIT
Aug 7, 2019
Change 37.175 New metric, SIISPCT='STORE INTO*INSTRUCTION*STREAM*PCT'
ANALSIIS is added to TYPE1131 and ASUM1131 datasets, to identify
VMAC113 potential timeframes based on percent of certain I writes
Aug 6, 2019 vs D Writes sourced, to identify when it happens, but NOT
who is causing it.
-ANALSIIS identifies intervals with SIISPCT GT 10 percent
and identifies what programs were running in descending
CPUTM or CPUZIPTM depending on CPU type during that high
SIISPCT interval.
Thanks to Kathy Walsh, IBM zSystems, USA.
Thanks to John Burg, IBM zSystems, USA.
Change 37.174 Non-fatal Divide By Zero when QBSTVPL=0 was corrected.
VMACDB2
Aug 5, 2019
Ron van der Zande, KLM Information Systems, THE NETHERLANDS.
Change 37.173 Support for TPMX $JCL_JJR, variable JCLJJR in TYPETPMX.
VMACTPMX Only 9 lines of "new field" messages are now printed.
Aug 4, 2019
Thanks to Jack Hyde, Optum Technology, USA.
Change 37.172 Dataset Encryption Variable SMF14DEF='Y' identifies data
VMAC1415 sets that are encrypted, and SMF14DET='0100'x to indicate
Aug 4, 2019 AES ('01'x) and 256 Bits ('00'x). INPUT was corrected.
Change 37.171 Variables R723GGTI, R723GGTN, R723GGKY and R723MFLG are
VMAC7072 kept in dataset TYPE72GO, and variable R723GGKY is now
Aug 4, 2019 INPUT correctly as $EBCDIC64 instead of 32.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 37.170 Variable DESTNATN is added to PDB.TYPE6 dataset.
BUILD005
BUIL3005
Aug 2, 2019
Thanks to Scott Barry, SBBWorks, INC., USA.
Change 37.169 Variable INITTIME in dataset TYPE30_6 is created using
VMAC30 INITTIME=SMFTIME-ACTIVETM;
Aug 2, 2019 which can then be used to count unique step executions.
Thanks to Scott Barry, SBBWorks, INC., USA.
Change 37.168 Four CICS "identity" variables weren't kept in CICSTRAN
UTILEXCL when UTILEXCL was used: APPLID JOB SMFPSSPN SMFPSRVR, and
VMAC110 these new "identity" variables MVSLEVEL LOCLINFO MCTSSCRL
Aug 2, 2019 are added to CICSTRAN whether UTILEXCL is used or not.
All could be deleted with
%LET MACKEEP=
MACRO _KCICTRN
DROP=APPLID JOB SMFPSSPN SMFPSRVR
MVSLEVEL LOCLINFO MCTSSCRL
%
:
in your SYSIN.
Thanks to Scott Barry, SBBWorks, INC., USA.
Change 37.167 z/OS 2/4 updates for RMF MONITOR III:
VMACRMFV -VMACRMFV in MXG 37.05 (only) fails with z/OS 4.2 CSR data
Aug 2, 2019 and was corrected in 37.06 by this change (which changed
only line 6871, from /48 to /CSRENTLE).
-New RUCSA variables added to ZRBCSR dataset:
CSRRUCSA ='RUCSA*AMOUNT'
CSRERUCSA='ERUCSA*AMOUNT'
-New RUCSA variables added to ZRBGEI dataset:
GEIRUCSASZ='IPL SIZE*RU CSA*BELOW 16MB'
GEIERUCSAZ='IPL SIZE*RU CSA*ABOVE 16MB'
GEIRUCSAMX='MAX RUCSA*BELOW 16MB'
GEIERUCSAX='MAX RUCSA*ABOVE 16MB'
GEIRUCSASP='ALLOCATED RUCSA*BELOW 16MB'
GEIERUCSAP='ALLOCATED RUCSA*ABOVE 16MB'
GEIRUCSAAV='ACCUM RUCSA*BELOW 16MB'
GEIERUCSAV='ACCUM RUCSA*ABOVE 16MB'
GEIRUCSARE='UNALLOCATED*RUCSA BELOW 16MB'
GEIRUCSAAS='ACCUM RUCSA*BELOW 16MB*BY SYSTEM'
GEIERUCSAS='ACCUM RUCSA*ABOVE 16MB*BY SYSTEM'
GEIBATRUCSA='ACCUM RUCSA*BELOW 16MB*BY BATCH'
GEIBATERUCSA='ACCUM RUCSA*ABOVE 16MB*BY BATCH'
GEIASCRUCSA='ACCUM RUCSA*BELOW 16MB*BY ASCH'
GEIASCERUCSA='ACCUM RUCSA*ABOVE 16MB*BY ASCH'
GEIOMVRUCSA='ACCUM RUCSA*BELOW 16MB*BY OMVS'
GEIOMVERUCSA='ACCUM RUCSA*ABOVE 16MB*BY OMVS'
-New variables with time to LPAR/Group Capping in ZRBCPU:
CPC_TIME_TO_CAPL='TIME TO*LPAR*CAPPING'
CPC_TIME_TO_CAPG='TIME TO*GROUP*CAPPING'
Thanks to Kurt Gramling, TSYS, USA.
Change 37.166 z/OS 2/4 updates:
VMAC74 -Type 74 Subtype 2 additions to dataset TYPE74PA, virtual
VMAC78 storage for the optional Private Address Space data:
Aug 2, 2019 R742PUTM1 ='PATH1*TIME USED*AT PCT UTIL'
R742PUTMS1='PATH1*SQRD TIME USED*AT PCT UTIL'
R742PUCN1 ='PATH1*COUNT USED*AT PCT UTIL'
R742PUSCN1='PATH1*SIGNAL COUNT SENT'
R742PUPCT1='PATH1*PCT UTIL'
R742PUTM2 ='PATH2*TIME USED*AT PCT UTIL'
R742PUTMS2='PATH2*SQRD TIME USED*AT PCT UTIL'
R742PUCN2 ='PATH2*COUNT USED*AT PCT UTIL'
R742PUSCN2='PATH2*SIGNAL COUNT SENT'
R742PUPCT2='PATH2*PCT UTIL'
R742PUTM3 ='PATH3*TIME USED*AT PCT UTIL'
R742PUTMS3='PATH3*SQRD TIME USED*AT PCT UTIL'
R742PUCN3 ='PATH3*COUNT USED*AT PCT UTIL'
R742PUSCN3='PATH3*SIGNAL COUNT SENT'
R742PUPCT3='PATH3*PCT UTIL'
R742PUTM4 ='PATH4*TIME USED*AT PCT UTIL'
R742PUTMS4='PATH4*SQRD TIME USED*AT PCT UTIL'
R742PUCN4 ='PATH4*COUNT USED*AT PCT UTIL'
R742PUSCN4='PATH4*SIGNAL COUNT SENT'
R742PUPCT4='PATH4*PCT UTIL'
R742PNIBTM='PATH TOTAL TIME*NO INBOUND*BUFFER IMPACT'
R742PNIBTS='PATH SQUARED TIME*NO INBOUND*BUFFER IMPACT'
R742PNIBCN='PATH COUNT*NO INBOUND BUFFER'
/* XCFMGD */
-Type 78 subtype 2 dataset TYPE78VS Virtual Storage new:
R782RUCA ='RUCSA ADDRESS*BELOW 16MB'
R782RUCS ='RUCSA SIZE*BELOW 16MB'
R782ERUCA='RUCSA ADDRESS*ABOVE 16MB'
R782ERUCS='RUCSA SIZE*ABOVE 16MB'
Thanks to Kurt Gramling, TSYS, USA.
Change 37.165 Dataset TYPE8201 (Initialization) variables SMF82ITE/CKD/
VMAC82 IML/USR/PKD were misaligned by a one byte reserved field.
Jul 29, 2019
Thanks to Matthew T Chappel,CQueensland Dept Transport, AUSTRALIA
Change 37.164 Variable TTTTLSSP in dataset TYP11902 is decoded by new
FORMATS $MG119PT format:.
VMAC119 VALUE $MG119PT /*TTTTLSPP*/
Jul 28, 2019 '0200'X='0200X:SSL V2'
'0300'X='0300X:SSL V3'
'0301'X='0301X:TLS 1.0'
'0302'X='0302X:TLS 1.1'
'0303'X='0303X:TLS 1.2'
Variable TTTTLSNC documents '4X'x='USE TTTTLSNC4 instead'
but values of '0A'x '35'x and '6B'x are found in data
but are not documented.
Thanks to Joe Faska, DTCC, USA.
Change 37.163 Labels for these variables were made consistent
VMAC71
Aug 2, 2019 SMF71L4A='AVG*1MB*PAGEABLE*FRAMES*IN DREF'
SMF71L4M='MIN*1MB*PAGEABLE*FRAMES*IN DREF'
SMF71L4X='MAX*1MB*PAGEABLE*FRAMES*IN DREF'
SMF71L5A='AVG*1MB*AVAILABLE*FRAMES*IN DREF'
SMF71L5M='MIN*1MB*AVAILABLE*FRAMES*IN DREF'
SMF71L5X='MAX*1MB*AVAILABLE*FRAMES*IN DREF'
SMF71L6A='AVG*1MB*PAGEABLE*FRAMES*USED*IN DREF'
SMF71L6M='MIN*1MB*PAGEABLE*FRAMES*USED*IN DREF'
SMF71L6X='MAX*1MB*PAGEABLE*FRAMES*USED*IN DREF'
SMF71L8A='AVG 1MB*PAGEABLE*FRAMES*IN CSTORE'
SMF71L8M='MIN 1MB*PAGEABLE*FRAMES*IN CSTORE'
SMF71L8X='MAX 1MB*PAGEABLE*FRAMES*IN CSTORE'
SMF71L9A='AVG 1MB*AVAILABLE*FRAMES*IN CSTORE'
SMF71L9M='MIN 1MB*AVAILABLE*FRAMES*IN CSTORE'
SMF71L9X='MAX 1MB*AVAILABLE*FRAMES*IN CSTORE'
SMF71PLA='AVG*1MB*PAGEABLE*FRAMES*USED*IN CSTORE'
SMF71PLM='MIN*1MB*PAGEABLE*FRAMES*USED*IN CSTORE'
SMF71PLX='MAX*1MB*PAGEABLE*FRAMES*USED*IN CSTORE'
Aug 2, 2019
Thanks to Joe Faska, DTCC, USA.
Change 37.162 ANALSIZE failed due to a missing semicolon in VMXGSIZE.
VMXGSIZE
Jul 25, 2019
Thanks to Richard Haynes, BCBSKS, USA.
Change 37.161 -New z/OS-Only SAS Date Variable CREATEDATE can be created
DODSCRDT for INFILE names of SAS CONTROLT DCOLLECT RMFBSAM TMC
VMACCTLT EDGHSKP IMSLOG OPCLOG, and is that variable is available
VMACDCOL the IHDRxxxx exit for your selection criteria, and/or it
VMACEDGR can be kept using the _Kdddddd dataset KEEP macro.
IHDRTMS5 -You must enable its creation with %LET DSCRDT=YES; in the
VMACIMS SYSIN or %DSCRDT can be added for any z/OS INFILE by
VMACSMF adding JFCB=MXGJFCB DSCB=MXGDSCB to the INFILE statement
VMACRMFV and inserting %DSCRDT after the first INPUT statement:
VMACTMS5 DATA MYSTUFF;
VMXGINIT INFILE MYFILE JFCB=MXGJFCB DSCB=MXGDSCB;
Aug 7, 2019 INPUT ;
Aug 11, 2019 %DSCRDT(JFCB=MXGJFCB);
Nov 26, 2019 SAS automatically prints the Create Date on the SAS log
in its "INFILE IS " message, but DSCRDT can print its
own log message if you use %LET MXGEXIMSG=YES;
SEE CHANGE 37.249 FOR REVISION.
Thanks to Linda S. Berkley, DISA, USA
Change 37.160 Unused Change Number.
Change 37.159 BETA 93 610 Subtype 40 and 49 misaligned, INVALID DATA
VMACBETA messages for variables BETASTME and BETAETME in 49 and
Jul 18, 2019 BETAALT in subtype 40.
Change 37.158 BLDSMPDB adds SPIN: SPUN: to WEEKDROP MNTHDROP if they
BLDSMPDB are not present. New parameters added WEEKBASE MNTHBASE
Jul 15, 2019 that both default to blanks which will then become
yesterday and used to determine which datasets will be
included in the weekly and monthly PDBs. This ensures
that your most current PDB is used to build the
weekly/monthly datasets. So if you decided to add
something on the day before it will be propagated into
the weekly/monthly jobs. The fact that it may not exist
in all of the input PDBs is not a problem. These should
only be used if you wish to force a specific PDB to be
the basis for the weekly/monthly PDBs and if it does not
exist via either a LIBNAME or a DD the job will fail.
Change 37.157 A new macro that will drill down through MSU consumption
ANALMSUS from the TYPE89 records and the type 30 interval data. It
Jul 13, 2019 can produce bar charts, tabular reports, and EXCEL
Aug 27, 2019 spreadsheets as you choose.
Change 37.156 Variables ABEND CONDCODE added to PDB.SMFINTRV and the
VMAC30 TYPE30_V datasets. The values will only be populated from
Jul 13, 2019 the subtype 3 records.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 37.155 Support for CICS Optional field USER/AGENCY.
IMACAAAA
IMACICXB
UTILEXCL
VMAC110
Thanks to Mark Hiltbruner, State of South Dakota, USA.
====== CHANGES THRU 37.154 ARE IN MXG 37.05 DATED Jul 8, 2019 =========
Change 37.154 SMF 110 Subtype 1 MNSEGCL=5 INPUT EXCEEDED ERROR due to
VMAC110 8 byte reserved field inserted in DPL ENTRY segment. Skip
Jul 8, 2019 the records (causing zero obs in CICSRDPL dataset) with:
%LET MAC110H= %QUOTE(IF MNSEGCL=5 THEN DELETE; ) ;
This was added in CICS/TS 5.5 to these (seldom used) CICS
Resource segment.
Thanks to Jack Hyde, Optum Technology, USA.
====== CHANGES THRU 37.153 ARE IN MXG 37.05 DATED Jul 6, 2019 =========
Change 37.153 SMF 120 Subtype 3 INPUT STATEMENT EXCEEDED ERROR due to
VMAC120 incorrect MXG logic that has accidentally worked: there
Jul 6, 2019 were only three ABENDS since Dec 2018. One circumvention
which usually skips over the failing record was tried:
OPTIONS STOPOVER MISSOVER % but because the code error
was a loop on the same INPUT location, MXG created 500
million observations in TYP120SR filling fifteen WORK
volumes before dying with a B37 no more extents error.
The alternative circumvention was to skip that subtype:
%LET MACFILE=%QUOTE(IF ID=120 AND SUBTYPE=3;);
until this update corrected the MXG code error.
I think not related, but site had WebSphere 8.5.5 FP12.
====== CHANGES THRU 37.152 ARE IN MXG 37.05 DATED Jul 5, 2019 =========
Change 37.152 MXGSTEP populates new variable MXGSTEP='Y' in SMF 30's to
MXGSTEP identify job steps that execute MXG programs, populating
Jul 5, 2019 TYPE30_V and TYPE30_4 with (TYPE30) and in PDB.SMFINTRV
and PDB.STEPS with (BUILDPDB), or any MXG program that
processes SMF 30 records, if PROGRAM='SAS' and DDNAMES
SOURCLIB and LIBRARY are in this STEP, as both are
required for MXG Execution.
Thanks to Deepa Rajendran, DXC, SINGAPORE.
Change 37.151 ASUMMIPS now uses the $MGRMIPS format built from the IBM
ASUMMIPS LSPRITR table to lookup CPCFNAME (eg 3906-716) for the
VMXGINIT MIPSFACT (eg 8.34), the MIPS per MSU. Previously you
Jul 4, 2019 had to provide your own MIPSFACT.
Jul 5, 2019
Thanks to Randy Hewitt, DXC, USA.
Change 37.150 Support for DATACOM log file.
EXDCOM
IMACDCOM
TYPEDCOM
TYPSDCOM
VMACDCOM
VMXGINIT
Jul 2, 2019
Thanks to Linda S. Berkley, DISA, USA.
Change 37.149 If you add ID to USERADD it must be the last entry
UTILBLDP in the list. If you happened to make it first the
Jul 2, 2019 list will be adjusted.
Change 37.148 BLDSMPDB adds SPIN: SPUN: to WEEKDROP MNTHDROP if they
BLDSMPDB are not present. New parameters added WEEKBASE MNTHBASE
Jun 23, 2019 that both default to &WEEKDATE (yesterday) are used to
decide which datasets can be included in the weekly and
monthly PDBs. This ensures that your most current PDB is
used to build the weekly/monthly datasets. So if you
decided to add something on the day before it will be
propagated into the weekly/monthly jobs. The fact that it
may not exist in all of the input PDBs is not a problem.
Change 37.147 CICS Statistics datasets CICMPR and CICSJN were not in
VMAC110 the _N110_, _S110, and _S110ST optional tailoring macros.
Jul 1, 2019
Change 37.146 Macro variable &MACSPIN added to IMACSPIN for "instream"
IMACSPIN tailoring of SPINCNT.
VMXGINIT
Jul 1, 2019
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 37.145 The "PROC PRINT" output with Label and Name column heads
VMXGPRA1 VMXGPRA1 and VMXGPRAL utilities now protect if you have
VMXGPRAL changed the OBS option. Their temp dataset has one obs
Jun 28, 2019 per variable, but if your OBS was too small, some heads
were wrong and missing parens. Now the OBS value is held.
the print is accomplished and your original OBS restored.
Thanks to Scott Wiig, US Bank, USA.
Change 37.144 FLASH: MISSING PERIODS 2/3 TYPE72GO if MXG 36.07 or prior
VMAC7072 is used and IBM RMF APARs for SCM and Crypto are applied.
Jul 1, 2019
There is no error with MXG 36.08 (Sept 2018) or later.
One z/OS 2.3 site reported these were applied:
UA98434 APAR OA56461
UA98529 APAR OA56672
UA98759 APAR OA56826
UA98999 APAR OA56860
and one z/os 2.2 site reported this was applied
UA98433 APAR OA56747
but there may be other maintenance involved.
You can examine your SMF 72 Subtype 3 period data with
PROC FREQ DATA=PDB.TYPE72GO;
TABLES SYSTEM*PERIOD;
TITLE TABLE OF PERIOD VALUES IN SMF 72 SUBTYPE 3;
to see if you are missing values for your periods.
These missing periods will cause the system Capture
Ratio to decrease significantly, and the workload that
normally have period data will have reduced CPU time in
TYPE72GO and RMFINTRV datasets, and reports from them.
Change 37.143 Expanded Storage doesn't exist in all z/OS systems so the
IMAC71 56 ESTORE variables in TYPE71 can be dropped by removing
Jun 28, 2019 the comment block when you EDIT the IMAC71 tailoring
member into your "USERID.SOURCLIB" tailoring library.
You do need to examine any reporting programs that use
the TYPE71 dataset to see if those variables are used.
Thanks to Arnold Kim, UPS, USA.
Change 37.142 New READRATE %MACRO will measure the Read Rate (MiB/Sec)
READRATE of MXG processing SMF data records, printing an interval
VMACSMF trace on the log, a PLOT of READRATE vs RUNTIME, and PROC
VMXGINIT TABULATE report with 1 sec default interval. Additional
options are in the comments in READRATE. Syntax:
Jul 1, 2019 %READRATE(READRATE=1,RESULTS=BOTH);
%INCLUDE SOURCLIB(TYPE30); RUN;
&READRATEREPORT;
Change 37.141 Format MG119CD 17:UCP corrected to 17:UDP.
FORMATS
Jun 26, 2019
Thanks to Jenny Chen, DXC Technology, AUSTRALIA.
Change 37.140 -More RMF Monitor III tables are supported by FDF (Field
ADOCRMFV Data Filter) in ASMRMFV: DSI, SPG, SSH
ASMRMFV -New CDF (Character Data Filters) added for RMF III VSAM
Jun 26, 2019 data set level filtering:
CPCNAME= (aliases CPC=, CECNAME=, CEC=)
LPARNAME= (alias LPAR=)
-LPAR names and CPC names are validated for correct syntax
when these filters are used.
-FDF now supports character patterns for character fields.
Only Equal (= EQ) and Not Equal (^= =^ NE NEQ NOT NOTEQ
NOT=) operators may be used in an IF expression with a
character pattern. A pattern either matches or it does
not. Other FDF operators are flagged as an error.
-New DSIAND/DSIOR parameters which have the same function
as the prior SYSAND/SYSOR parameters which are now
respective aliases.
-RMFV014I message now shows counts for RMF III data sets
bypassed by CPCNAME= and/or LPARNAME= CDF keywords.
-Duplicate counts are no longer shown in RMFV014I message
if DUPDSN option is in effect (no duplicate checking).
-Space analysis messages RMFV030I, RMFV031I are no longer
issued for filtered RMF III VSAM data sets.
-MAXDSNS= added as a further alias of MAXDSNAMES=.
-Always force upper case for these CDF keyword values
because lower case letters are always invalid and
would be flagged as an error otherwise:
CPCNAME= SYSPLEX= LPARNAME= SYSTEM=
ASISUBSYS= ASIJOBCLASS= ASIJOBNAME= ASIJESID=
CSRJOBNAME= CSRJESID= DVTDEVNUM=
OPDJOBNAME= OPDPROCNAME= OPDUSERNAME=
-Support validation for all characters allowed for CDF
Workload Names, Service Classes, Report Classes, and
Resource Groups
-Field descriptions in data dictionary entries in ADOCRMFV
for FDF supported RMF III table expanded for better
clarity.
-TRUENAME Fieldnames in FDF data dictionary entries in
ADOCRMFV documentation now show all possible aliases.
-GMT offset value in Summary First Sample Begin Date/Time
selected message RMFV013I could be incorrect.
-RMFV013I selection messages were incorrectly displayed in
Summary report when all RMF III data sets were filtered.
-CDF keywords and aliases may now be used as Fieldnames
in FDF IF expressions (minus the = suffix).
-Message RMFV014I now includes a counter for FDF filters.
-Negative values are now supported in FDF, but only for
GMT offset fields xxxSTDIF and xxxGMTOFF where xxx is a 3
character RMF table id.
-For example this is a valid IF expression:
IF=(ASISTDIF EQ -5H)
-New second RMFV103I message is added to Detail and
Summary reports to display Sample Set filter reason
counts.
-New options AUTOSEL (alias AUTO) and NOAUTOSEL (alias
NOAUTO) added.
-AUTOSEL is the default and will result in the RMF III
table being automatically selected with any CDF or FDF
filter if the table was not already selected. This is a
convenience feature.
-New message RMFV082I appears when a table is auto
selected. In addition in message RMFV105I Y* will
appear in the SELECT column for auto selected tables.
-NOAUTOSEL provides the prior ASMRMFV behavior and the
unselected table condition generates an error. However,
it may be helpful if JCL with CDF and/or FDF filters is
routinely reused to avoid the PDB build overhead of
automatically selecting a table that is no longer wanted.
-For tables not referenced by CDF and/or FDF it is still
necessary to select the RMF III tables of interest.
-The SPGVOLSER= CDF filter could have incorrect results.
-Following documentation sections in ADOCRMFV are added or
updated:
Section Description
0 Contents
2 Terminology
3 Execution JCL
4 RMF III Table Selection Parameters
5 Input Data Selection Parameters
6 Report Control Parameters
8 Error Handling Parameters
9 JCL and SYSIN Parameter Usage
12 Messages
13 Filtered Records
16 Return Codes
20 FREE=CLOSE For VSAM Data Sets
21 Extended ASI/ENC/RCD/UWD Record Support
25 Ranges and Patterns
26 ASMRMFV and MXG PDB Data Relationships
31 Field Data Filtering (FDF)
32 Filtering The ASI Table
33 Filtering The CSR Table
34 Filtering The DSI Table
35 Filtering The DVT Table
36 Filtering The ENT Table (Future)
37 Filtering The GEI Table (Future)
38 Filtering The OPD Table (Future)
39 Filtering The SPG Table
40 Filtering The SSH Table
41 Summary
Change 37.139 Reserved Change.
Change 37.138 The label for variable QW0199TRS in DB2 102 IFCID 199 was
VMAC102 corrected to 'END TIME*OF*INTERVAL', which is strange as
Jun 24, 2019 the SMFTIME was available for the end time.
Thanks to Xing Su, DXC Technology, AUSTRALIA.
Thanks to Peter J. Gray, DXC Technology, AUSTRALIA.
Change 37.137 -Variables INDXUSEP and POLYUSEP percentages are created
VMACRMFV in dataset ZRBDISH to track index usage. The 1110 is the
Jun 21, 2019 maximum number of sample indexes in a 32K DSI table and
50 is the maximum number of policy indexes.
-Strange RMF III intervals can be created if the values
in SMFPRMxx don't match ERBRMFxx options. A site had
SMF INTVAL(10) SYNCVAL(59) with RMF MINTIME(300) SYNC(0)
for RMF III, which created a 4 minute interval (:55 -:59)
when the RMF III MINTIME expired, a one minute (:59-:00)
interval when the SMF Interval Expired, and a five minute
(:00-:05) when the RMF Interval Expired.
Change 37.136 ANALMSUS is a powerful set of reports of SOFTWARE MSUs
ANALMSUS from ASUMCELP, SMFINTRV, TYPE72GO, TYPE89 records, that
Jun 21, 2019 has many different bar charts, tabular reports, and EXCEL
spreadsheets as you choose, with report examples in the
comments, and with numerous report examples available
online at http://www.mxg.com/downloads/analmsus/
ANALMSUS.PDF
ASUMCELPMSU.XLSX
JOBSMSU.XLSX
MSU89.XLSX
REPORTCLASS.XLSX
SERVICECLASS.XLSX
TYPETASK.XLSX
(Don't be confused with archaic ASUMMSUS member.)
Change 37.135 Type 42 Subtype 5 Invalid LENSR values were individually
VMAC42 detected and LENSR=160 set, but now there are a total of
Jun 21, 2019 22 different values for records, because IBM populates
Jun 24, 2019 the total length and not the 160 first segment length.
But with 22 tests, I'm now forcing LENSR=160 always, as
that will ONLY fail if IBM actually changes that first
segment size in the future, you won't be ABENDing on
each new LENSR value. These are the known invalids:
IF LENSR IN (232,240,320,376,400,480,448,304,520,560,592,
720,640,1040,1120,1200,960,1360,1280,1440,880,800)
THEN LENSR=160;
Thanks to Robert Obee, Ensono, USA.
Change 37.134 CHART option changed to NONE because DSIG option is no
ANALACTM longer supported after SAS 9.3. The four coefficients
Jun 15, 2019 (CPU SRB MSO IOC) are added to WLM definitions report.
Change 37.133 TYPE42HI dataset, variables S42VSXST/S42VSXRT/S42VSXID
VMAC42 added in MXG 37.02 and MXG 37.03 incorrectly as character
Jun 17, 2019 variables with $EBCDIC8 informat. Change 37.019 in 37.04
corrected them to &PIB.4. numeric variables, but if you
build WEEKLY PDBs with some days created by 37.02/03 and
other days by 37.04 or later, you will need to either
DROP those variables from the 02/03 day's PDB, or just
remove the creation of TYPE42HI for that week.
It is always best if a new version of MXG is installed
to run on the first day of your week, so that all of
those daily PDBs will have identical structure.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 37.132 Addition of a semi-colon following &OUTCODEx argument in
ASUM4HRS %VMXGSUM invocations to prevent rare errors.
GRAFCEC
GRAFWLM
VMXGRMFI
VMXGSUM
VMXGSUM
VMXGUOTT
Jun 14, 2019
Change 37.131 ANALCNCR fails with multiple errors if there are 0 OBS in
ANALCNCR the input datasets. Now detected and ANALCNCR ends.
Jun 21, 2019
Change 37.130 -New VM Account datasets supported.
EXVMCAPD dddddd Dataset Description
EXVMCAPE CHGD VMCAPCHD CAPABILITY*CHANGED
IMACVM CHGE VMCAPCHE CAPABILITY*CONTINUATION
TYPEVM -Under investigation with IBM Support:
VMXGINIT -Records with blank RECID (bytes 79-80).
Jun 25, 2019 -VMSESSN records overlap, with ACCTTIME greater than the
STARTIME=ACCTTIME-CONECTTM of the next record for the
User TCPIP, trying to use this data for availability
measurement.
Thanks to William Marshall, Ensono, USA.
Change 37.129 Member INSTALL and the listed members were updated with
INSTALL more consistent names in the examples.
MXGWPSV4 -The WPS V4 JCL Procedure need a new DD for 4.1:
JCLINSTW //MAPS DD DSN=&WPSHLQ..MAPS,DISP=SHR
MXGWPSV3
MXGWPSV4
JCLINSTL
JCLINSTT
CONFIGW4
Jun 12, 2019
Change 37.128 SMF 82 ICSF updates from ICN1633 for a future release:
FORMATS -New variable SMF82CSF in TYPE8201 identifies source of
VMAC82 the startup member name, formatted MG082CS.
Jun 12, 2019 -Variable SMF82UCB, SMF82TKF bits are decoded in TYPE8209.
-Variable SMF82TKF bits are decoded in TYPE8209
-Variable SMF82BOT bits are decoded in TYPE8213.
Change 37.127 -Formats created for TYP11902 dataset variables TTTTLSCS,
FORMATS TTTLSPD, TTTERMCD, TTSMCSTATUS, and values updated in
VMAC119 format $MG119RE for variable T119REAS.
Jun 11, 2019 -New TYP11902 variables:
TTSMCSTATUS='SMC-R*STATUS'
TTIPSECFLAGS='IP*SECURITY*STATUS'
TTLCLSMCBUFSZ='LOCAL RMB*BUFFER*SIZE KB'
TTRMTSMCBUFSZ='REMOTE RMB*BUFFER*SIZE KB'
-New TYP11994/TYP11995 OPENSSH new variables.
SSH_FIPSMODE ='RUNNING*IN*FIPS*MODE?'
SSH_KEXMETHOD ='KEY*EXCHANGE*METIOD*USED'
Thanks to Randy Hewitt, DXC, USA.
Change 37.126 z/VM MONWRITE deaccumulated field deltas are sometimes a
VMACVMXA negative value, especially in user fields like VMDTTIME,
Jun 7, 2019 usually related to a VM system event, but the original
assumption was that the negative value was due to a wrap
of the 4-byte accumulated value, so 4294967296 is added,
a guess at the full word wrap value, but these negatives
are not due to a wrap, and you get a very large value.
This change now sets the variable to a MISSING VALUE when
a negative delta is found, so those spikes won't impact.
Thanks to Terry Chao, DC Government, USA.
Change 37.125 Reserved Change.
====== CHANGES THRU 37.124 ARE IN MXG 37.04 DATED Jun 5, 2019 =========
Change 37.124 Variable ID added to the TYPE60,TYPE6156,TYPE62,TYPE64,
VMAC60 TYPE6367,TYPE68,TYPE69 datasets so a direct merge can be
Jun 5, 2019 made without added data passes.
Thanks to Tony Curry, BMC, USA.
Change 37.123 MXG calculation of TYPE70 variable CPUMVSTM/PCTMVSBY was
VMAC7072 too small because Parked Time was incorrectly subtracted
Jun 5, 2019 from CPUUPTM which already has Parked Time removed.
Variables PLCPRDYQ (Ready Queue Delay Percent) and
SHORTCPS were also too small and corrected. Impact was
typically less than ten percent.
Thanks to Ken Deering, COMPUWARE, USA.
Thanks to Selby Shanly, COMPUWARE, USA.
Change 37.122 Support for two new variables in RACF OFFLOAD RACF0200
VMACRACF dataset, with values of YES or NO:
Jun 3, 2019 USBD_ROAUDIT ='USER*HAS*ROAUDIT*ATTRIBUTE?'
USBD_MFA_FALLBACK='USE*PASSWORD*MFA UNAVAIL?'
Thanks to Karl Laseki, American Chemical Society, USA.
Change 37.121 Support for ThruPut Manager Release 18.02 v7r1.0.
VMACTPMX -New variables added to TPM10 dataset:
May 30, 2019 TPMCMLFL='TPMCMLFL*FLAG*BYTE'
TPMCMLCL='SLM*CAPACITY*LEVEL*1-5'
TPMCMLCP='CAPPED*PERCENT*LAST 5*MINUTES'
TPMCMLCC='CEC*CAPACITY*MSU/HR'
TPMCMLAG='AVG GS*JOBS*LAST*5 MIN'
TPMCMLAP='AVG PCS*JOBS*LAST*5 MIN'
TPMCMLAT='AVG GS+PCS*JOBS*LAST*5 MIN'
TPMCMSNM='LPAR*SET*NAME'
TPMCMSLM='LPAR*SET*LIMIT*MSU/HR'
TPMCMSA4='LPAR*SET*4HRAV*MSU/HR'
TPMCMSI5='LPAR*SET*5MINAV*MSU/HR'
TPMCMSFL='TPMCMSFL*FLAG*BYTE'
TPMCMSCL='LPAR*SET*CMP LIMIT*MSU/HR'
TPMCMSC4='CMP-WIDE*4HRAV*MSU/HR'
TPMCMSCI='CMP-WIDE*5MINAV*MSU/HR'
TPMCMSMA='MOBILE*4HRAV*MSU/HR'
TPMCMSBA='CATEGORY A*4HRAV*MSU/HR'
TPMCMSMI='CATEGORY B*4HRAV*MSU/HR'
TPMCMSMI='MOBILE*INTERVAL*USAGE*MSU/HR'
TPMCMSAI='CATEGORY A*INTERVAL*MSU/HR'
TPMCMSBI='CATEGORY B*INTERVAL*MSU/HR'
-New variable added to TPMSLM dataset
TPMSCLVL='MAXIMUM*CAPACITY*LEVEL'
Change 37.120 Mobile Service Units on GP and IIP ARE included in the
VMAC7072 CPUTM and ZIPCPUTM variables in TYPE72GO and TYPE72TR.
May 28, 2019 The comments in Change 36.253 are wrong and the proposed
CPUTM_ALL=SUM(CPUTM,CPUMOBILCP) is now CPUTM_ALL-CPUTM
and labeled EQUAL*TO*CPUTM. Using a WLM Policy that
classified the entire workload for a service class as
MOBILE, the Service Units were the same in the sum of
R723CCPU and R723CSRB (CPUTCBTM and CPUSRBTM), and in
R723TSUCP and in R723MSUCP (Total GP and Total Mobile).
Thanks to Ken Deering, Compuware, USA.
Thanks to Selby Shanly, Compuware, USA.
Change 37.119 Label for PTECP2 is 'CPU TIME*ZIP*ELIGIBLE' instead of
VMACNDM "QUALIFIED".
May 28, 2019
Thanks to Joe Faska, DTC, USA.
Change 37.118 Sites with NLS issues must use CONFIMXG, but to build the
JCLCONFI new FORMATS catalog, you must use the JCLCONFI example.
May 27, 2019
Change 37.117 The optional CICS DBCTL SMF 110 segment can be 164 or 256
IMACICDB but the order was the 164 first, so if you opened both of
May 23, 2019 the comment blocks, the 256 segment was misaligned. Now,
the 256 segment is first and both blocks can be opened to
support both lengths.
Thanks to Steven W. Erkkila, USBank, USA.
Change 37.116 -WPS U4087 ABEND in WPS 4.1 but not in WPS 4.0 due to the
CONFIGW4 new data copier added in 4.1, can be circumvented with
AUTOEXEW OPTIONS NOWPSSCATTERCOMP; which turns off the facility.
May 22, 2019 -This correction also fixed a CPU Loop in WPS 4.1.
Jun 17, 2019 -CONFIGW4 for z/OS and AUTOEXEW for ASCII have the option
added, but commented out, and for WPS 4.1 you must remove
the comment block. That option did not exist in 4.0.
Jul 3: Corrected in WPS 4.1.2.0.17535.
Change 37.116A Variable OPENTIME was repeated in _BTY1415 By List macro,
VMAC1415 causing NOTE:DUPLICATE BY VARIABLES. Second OPENTIME was
May 22, 2019 removed. Change 35.166 revised the BY list.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 37.115 Wrong SMF record types for the example IFASMFDP step when
UTILBLDP BUILDJCL=YES was specified. 23 should have been 25 and
May 22, 2019 26J2/26J3 should be 26.
Change 37.114 Support for updated BETA 93 V6R2 (INCOMPATIBLE changes).
EXTYBET9 Offset to data was changed for some records.
EXTYBETP New subtypes create new datasets:
EXTYBETQ DDDDDD DATASET Description
EXTYBETR TYBET9 BETA9 RECORDS LIST/REPORT CVRTD
EXTYBETS TYBETP BETA12 PRINT HEADER PAGES
EXTYBETT TYBETQ BETA17 RECORDS MAILING OUTPUT
FORMATS TYBETR BETA30 DSC DATA CONVERTED LISTS
IMACBETA TYBETS BETA31 DSC RESRCS CVRTED LISTS
VMACBETA TYBETT BETA55 LOGOFF REQS WEB ENABLER
VMXGINIT Only BETA12 & BETA55 new datasets have been data tested.
May 22, 2019 Variable SYSUSRJOBCORR is INPUT and KEPT for subtypes
May 27, 2019 that contain it.
Thanks to Andreas Menne, Finanz Informatik-Sicherheitshinweis,GERMANY
Thanks to Martina Ruminski, Fin Informatik-Sicherheitshinweis,GERMANY
Change 37.113 NDM-CDI 24-byte record INPUT EXCEEDED ERROR; the header
VMACNDM length is 28 bytes, so a test for length is added and an
May 19, 2019 error message printed and the record deleted.
Thanks to Kurt Gramling, T-SYS, USA.
Change 37.112 New options CLEARALL=ONLY will clear any normal MXG
VMXGALOC associated LIBNAMEs allocated to your session without
May 19, 2019 trying to allocate new libnames.
Clears these libnames:
PDB SPIN MON TUE WED THU FRI SAT SUN WEEK
WEEK1-WEEK5 WTD MONTH MTD TREND
only if they are allocated.
Change 37.111 Final revisions for WSF/EOS WSFAUDIT variables AUDACT
FORMATS and AUDOBJN and their FORMATS, replaces Change 37.083.
VMACWSF -Dataset WSFACCT will always have zero observations; it
May 14, 2019 was never correct and is replaced by the four datasets
WSFDSN, WSFERD, WSFEVTSC, and WSFEVTPR.
Change 37.110 MXG Members TYPExxxx create output datasets in //WORK,
TECHNOTE MXG Members TYPSxxxx always SORT from WORK to PDB, and
May 11, 2019 the _Sxxxx sort macro all datasets for product xxxx and
deaccumulates those datasets with accumulated fields.
Exception: TYPEDB2 invokes the _SDB2 macro that sorts
all DB2 datasets except for DB2ACCT, and _SDB2
deaccumulates the DB2 datasets listed below
that need deaccumulation. They are also listed
in member DIFFDB2 lists sort/nonsort datasets.
NOTE: DB2ACCTP is sorted by _SDB2, but if you
only want Stats sorted, use _S100.
Exception: TYPE110/TYPE110S _S110 never sort these:
SUBTYPE=1, CICS MONITOR DATASETS:
_SCICTRN - CICSTRAN IS NOT SORTED, HIGH VOLUME
_SCICRDS - CICSRDS IS NOT SORTED, HIGH VOLUME
_SCICRDD - CICSRDPL IS NOT SORTED, HIGH VOLUME
_SCICRDF - CICSRDFI IS NOT SORTED, HIGH VOLUME
_SCICRDQ - CICSRDQU IS NOT SORTED, HIGH VOLUME
_SCICIDN - CICIDNTY IS NOT SORTED, HIGH VOLUME
_SCICIDD - CICIDNDD IS NOT SORTED, HIGH VOLUME
_SCICACC - CICSACCT NOT SORTED, PRE-CICS/ESA ONLY.
_SCICSYS - CICSYSTM NOT SORTED, PRE-CICS/ESA ONLY
PRODUCT DATASETS THAT ARE ACCUMULATED DDDDDD/DATASET
28 028IN7/NPMINPMT
30 TY30U6/TYPE30_6
50 DIF() ONLY FOR INTERVAL DELTA
79 TY791/TYPE791 TY792/TYPE792 TY799/TYPE799
TY79C/TYPE79C
99 TY99BG/TYPE99BG
102 102380/T102S380 102402/T102S402
103 TY1032/TYPE1032 TY103D/TYPE103D
108 TY1083/TYPE1083
110 INTTC/CICTC INTTSR/CICTSR INTDMG/CICDMG
INTVT/CICVT INTAUT/CICAUTO INTLDS/CICLDG
INTDTB/CICDTB INTTCR/CICTCR INTDQR/CICDQR
INTDQG/CICDQG INTTSQ/CICTSQ INTDS/CICDS
INTST/CICST INTFCR/CICFCR INTM/CICM
INTTDG/CICTDG INTSDG/CICSDG INTSMS/CICSMDSA
INTAUS/CICAUSS INTCO3/CICCONMR INTCO1/CICCONSR
INTDL3/CICDLIG INTDL1/CICDLIR INTDBU/CICDBUSS
INTPGG/CICPAUTO INTIRC/CICIRCB INTDMR/CICDMR
INTFEP/CICFEPIP INTFEC/CICREPIC INTFET/CICFEPIT
INTJCR/CICJCR INTLDR/CICLDR INTLS3/CICLSRFR
INTLS1/CICLSRR INTSDR/CICSDR INTSMD/CICSMD
INTSMT/CICSMT INTTC1/CICTCLR INTTDR/CICTDR
INTXMC/CICXMC INTUSG/CICUSG INTXMG/CICXMG
INTXMR/CICXMR
113 TY113/TYPE113 TY1131/TYPE1131
AIX ALL AIX Datasets
DB2 DB2PST/DB2PSTXX DB2NET/DB2NETXX DB2ST5/DB2STAT5
DB2ST0/DB2STAT0 DB2ST1/DB2STAT1 DB2STS/DB2STATS
DB2SBP/DB2STSBP DB2STB/DB2STATB DB2STR/DB2STATR
HSM HSMDSR/HSMDSRST HSMFST/HSMFSRTP HSMFUN/HSMDSRFU
HSMVSF/HSMVSRFU HSMVSR/HSMVSRST
IMS IMS452/4/6/7/8/9/C/D/E/F/O/P/G/H/I/J/K/L/M/N
UNS56B
MPLX MPLXIN/XSE/XGA/XRT/XPE/XPM/XPO
NDM NDMCT
ASI CPUTA_LF,TCBTA_LF,IOCNT_S,TRCA_S,TET,TRT
TCP TYTCPS/TYPETCPS
TPX TPXINT/TPXINTRV
VMXA SYTSYP/SYTPRP/SYTRSG/SYTRSP/SYTXSP/SYTASG/SYTSHS
SYTUSR/SYTCPC/SYTSCG/SYTCOM/SUTUWT/SYTSCP/SYTXSG
SYTCUG/SYTCUP/SYTCUM/SYTCPM/SYTSYG/SYTEPM/SYTLCK
SYTLCX/SCLADL/SCLDDL/SCLAEL/SCLSRM/SCLSTP/STORSG
STORSP/STOSHR/STOASP/STOBPG/STOXSG/STOXSU/STOASS
STOASI/STOSHD/STOVDK/USEDFC/USEATE/USEITE/PRCPRP
PRCIOP/PRCAPM/PRCMFC/PRCPUP/PRCMFM/IODDEV/IODMOF
IODVSW/VMDSES/ISFISA/ISFNOD/APLSRV/APLSLM/APLSLP
APLSL0/APLSLN/APLCMS/APLVMR/APLLXP/APLTC0/APLTC3
APLTC4/APLTC5/APLTC7/APLTC8/APLTC9/APLTCA/APLTCB
SSISCS/SSISMI/SSIXLK/SSIXDI
Change 37.109 Support for z/OS 2.4 SMF Manual 04MAR19 are already in
VMAC7072 place in MXG 37.02+, Change 37.037 from 14JAN19 Manual,
VMAC74 except for
May 10, 2019 -SMF70CPC_TYPE, listed in "Summary of Changes" page xxii,
but the field is not found in in the manual,query raised.
-New SMF70PRTCTV='SMF70OS*PRTCT*IS VALID?' flag in TYPE70.
compatibly added in this change.
Change 37.108 Bit mapping documentation for NDN-CDI CNF1/CNF2 fields:
VMACNDM NDMCNF1 $CHAR1. /*SECURE*COPY*FLAG1*/
May 9, 2019 /* BIT MAPPINGS FOR NDMCNF1 AND CISECNF1
PCEF EQU X'80' PNODE ENCRYPT.DATA
SCSI EQU X'40' SNODE SECURE.SIGNATURE
PCSI EQU X'20' PNODE SECURE.SIGNATURE
CCSI EQU X'10' COPY SECURE.SIGNATURE
SCEF EQU X'08' SNODE ENCRYPT.DATA
SSL EQU X'04' SSL.ENABLED=Y
TLS EQU X'02' TLS.ENABLED=Y
STS EQU X'01' STS.ENABLED=Y */
NDMCNF2 $CHAR1. /*SECURE*COPY*FLAG2*/
/* BIT MAPPINGS FOR NDMCNF2
CSIN EQU X'80' SIGNATURE = CURRENT KEY
PSIN EQU X'40' SIGNATURE = PREVIOUS KEY
TLS EQU X'20' TLSV10 ENABLED
STS EQU X'10' STS.ENABLED
IPV6 EQU X'08' IPV6 ADDRESS
TLS1 EQU X'04' TLSV11 ENABLED
TLS2 EQU X'02' TLSV12 ENABLED
ZFBA EQU X'01' ZFBA WAS USED */
NDMCPEA $CHAR1. /*MERGED*SECURE*ENCRYPT*NUMBER*/
Change 37.107 A change in the length of TPX05LEN misaligned TPXETIME &
VMACTPX TPXATIME; they incorrectly INPUT blanks, which TODSTAMP8
May 9, 2019 reported as 8am on Oct 27, 1935.
Thanks to Craig Bigler, Progressive, USA.
Thanks to Ann Knapik, Progressive, USA.
Change 37.106 A check of SYSFILRC that should have been inside a DO
BLDSMPDB loop checking SMFIN could cause a spurious critical error
May 8, 2019 saying that the allocation of the SMF file failed if some
May 13,2019 other earlier FILENAME statement had failed. FILENAME
May 19, 2019 statements don't tell us when they have a problem until
you try to use them unless you check the SYSFILRC macro
variable for a non-zero value.
-If you run a weekly job independently of a daily job and
are using AUTOALOC=YES and need to rerun the week using
FORCEDAY it pointed at the incorrect day and did not
recognize the start of the week. FORCEDAY should always
be the date of the data being processed so if your week
starts on Monday FORCEDAY should point at Sundays date.
If you are running a weekly or monthly job the code
validating parameters still looks at the value in
BUILDPDB and if it did not match what was expected could
cause a failure. Now you can either omit the parameter
and allow it to default or you can specify BUILDPDB=NO.
-If you run TREND daily and needed to rerun a WEEK, the
trending ran as if it were daily. If you are using
AUTOALOC this just repeats what was already done and
there will be no duplication of data. Now BLDSMPDB checks
to see that RUNDAY is NE NO.
-BLDSMPDB now sets SYSCC=16 if it detects any errors, and
displays that condition code value at the end.
Change 37.105 Support for SMF 120 WAS and LIBERTY COMPATIBLE new data:
VMAC120 -Subtype 11. TYP120BL. SM120BDL='ON IF*CVTZCBP*IS ON?'
May 6, 2019 -Subtype 09. TYP1209N. SM1209HW='ON IF*CVTZCBP*IS ON?'
SM1209HX='WORKER*THREADS*PRESENT'
-Subtype 12. TYP12012. SM120CEJ='ON IF*CVTZCBP*IS ON?'
Change 37.104 Variables CECSER and CPCMODEL are added to TYPE72GO data
VMAC7072 set, retained from prior 70. However, they are set blank
May 6, 2019 if the PREVVSYS system is not the SYSTEM of this record,
May 19, 2019 which could happen if the SMF data was sorted before MXG
or if an SMF Dump happens to start with type 72 records.
Thanks to Andrew Petersen, DXC Technology, AUSTRALIA.
Change 37.103 Support for IMS Log Records 5607/5610/5904/5950 creates
EXIMS567 new datasets:
EXIMS56A DDDDDD DATASET DESCRIPTION
EXIMS594 IMS567 IMS5607 MCS/PICOS
EXIMS595 IMS56A IMS5610 START PHASE 1 SYNCPOINT
IMACIMS IMS569 IMS5609 CCTL DISCONNECT FROM DBCTL
VMACIMS IMS56B IMS5611 END OF PHASE 1 SYNCPOINT
VMXGINIT IMS56F IMS5615 RRS RESTART DONE
May 15, 2019 IMS594 IMS5904 REGION OCCUPANCY RECORD
IMS595 IMS5950 DATA BASE LOG RECORD
Change 37.103A FORMAT $MGFSMFID updated for DB2 102 IFCIDS for ANALID.
ANALID
FORMATS
May 15, 2019
Change 37.102 Support for CICS/TS 5.5 new Statistics, COMPATIBLE, two
EXCICMPR new datasets, and all _SCICxxx sorts now deaccumulate.
EXCICSJN For 5.5, fields were inserted into reserved areas.
FORMATS -New Dataset CICMPR for STID=145 CICS Policy statistics.
IMAC110 MPR_POLICY_NAME ='POLICY*RESOURCE*NAME'
VMAC110 MPR_RULE_NAME ='POLICY*RULE*NAME'
VMXGINIT MPR_POLICY_USERTAG='POLICY*USERTAG'
May 6, 2019 MPR_BUNDLE_NAME ='POLICY*BUNDLE*NAME'
May 18, 2019 MPR_BUNDLE_DIR ='POLICY*BUNDLE*DIR'
Jun 2, 2019 MPR_RULE_TYPE ='RULE*TYPE'
MPR_RULE_SUBTYPE ='RULE*SUB*TYPE'
MPR_ACTION_TYPE ='ACTION*TYPE'
MPR_ACTION_COUNT ='RULE*ACTION*COUNT'
MPR_ACTION_TIME ='RULE*LAST*ACTION*TIME'
-New Dataset CICSJN for STID=150 NODEJSAPP statistics.
SJN_NAME ='NODEJSAPP*NAME'
SJN_LE_RUNOPTS ='NODEJSAPP*LE*RUNOPTS'
SJN_STATE ='NODEJSAPP STAT'/
SJN_DEFINE_SOURCE ='GROUP*INSTALLED*FROM'
SJN_CHANGE_TIME ='CHANGE*CREATE*TIME'
SJN_CHANGE_USERID ='CHANGE*USERID'
SJN_CHANGE_AGENT ='CHANGE*AGENT'
SJN_INSTALL_AGENT ='INSTALL*AGENT'
SJN_INSTALL_TIME ='INSTALL*CREATE*TIME'
SJN_INSTALL_USERID ='INSTALL*USERID'
SJN_CREATION_LCL ='CREATION*TIME*LOCAL'
SJN_PID ='NODEJSAPP*PID'
SJN_BUNDLE_NAME ='BUNDLE*NAME'
SJN_CPU ='TOTAL*CPU*TIME'
SJN_HEAP_CURRENT ='ALLOCATED*HEAP'
SJN_HEAP_RUNTIME ='HEAP*USED BY*RUNTIME'
SJN_HEAP_APP_DATA ='HEAP*USED FOR*DATA'
SJN_HEAP_MAX ='MAX*POSSIBLE*HEAP'
SJN_INVK ='COMPLETED*INVOKES'
SJN_INVK_ERR ='COMPLETED*INVOKES*IN ERROR'
SJN_INVK_CUR ='CURRENT*INVOKES*IN PROGRESS'
SJN_INVK_PEAK ='PEAK*INVOKES IN*PROGRESS'
SJN_NODEHOME ='NODEHOME*PROFILE*ENTRY'
SJN_PROFILE ='PROFILE'
SJN_STARTSCRIT ='ENTRY*JAVASCRIPT'
SJN_STDERR ='STDERR*FILE'
SJN_STDOUT ='STDOUT*FILE'
SJN_TRACE ='TRACE*FILE'
SJN_LOG ='LOG*FILE'
-Dataset CICDB2GL STID=102 new variable
D2GTCBPR='TCB*PROTECTED*CURRENT'
-Dataset CICCONSR STID=52 new variables.
A14EAHWM='MAX*AIDS'
A14EALL expanded to 4 bytes, used reserved area.
-Dataset CICMNG STID=81 new variables
MNGIR ='IDENTITY*RECORDS'
MNGIRS ='IDENTITY*RECORDS*SUPP BY EXIT'
MNGDPLRL='DPL*RESOURCE*LIMIT'
MNGURIRL='URIMAP*RESOURCE*LIMIT'
MNGWEBRL='WEBSVC*RESOURCE*LIMIT'
-Dataset CICXMR STID=11 variable
XMRAENDC='ABEND*COUNT'
-Previously _SCICddd Statistic Dataset Sort Macros only
PROC SORTed from WORK to PDB; there was no deaccumulation
so fields with accumulated values were wrong. Now, all
_SCICddd macros de-accumulate correctly into the PDB.
The _S110 macro sorts account and all statistics datasets
the _S110ST macro sorts only the statistics datasets.
-By DEFAULT, TYPE110 & BUILDPDB do NOT invoke _S110ST. All
datasets are left in work, where you can tailor EXPDBOUT
to sort all or individual datasets. You can use
%LET EPDBOUT= _S110ST ; in your SYSIN to sort the stats
datasets AND deaccumulate to correct errors in CICINTRV.
-But if UTILBLDP is used to create your tailored BUILDPDB,
and if CICS data was requested, then _S110 is invoked, so
your PDB.CICINTRV will be valid as soon as you use 37.04.
-TYPS110 invokes _S110, TYPE110 does not.
-Revised deaccumulation logic needed JOB READTIME added
to the BY list, and logic NOT FIRST.READTIME used to
eliminate large values created when back-to-back regions
had forward times.
-A new _SCICxxx sort macros option MXGCICRQTSORT can be
used to only read and use the SMFSTRQT='INT' interval
records with this statement in your //SYSIN:
%LET MXGCICRQTSORT=%QUOTE(WHERE SMFSTRQT='INT');
This needs testing when you have multiple RQTs.
The MXG default continues to use ALL record types.
-A new macro variable &MXGCICSORTED is set to YES in
_S110 and _S110ST macros so that the logic in VMXGCICI
knows to use the PDB deaccumulated data. You would only
need to set it to YES if you are building CICINTRV in
a separate job from the one that created the stats PDB.
Change 37.101 MXG 37.03, if you used USERADD=102.nnn syntax for DB2
UTILBLDP IFCID subtype, and used BUILDPDB=YES, the generated code
May 6, 2019 was wrong and failed with 455-185 W102nnn error.
Thanks to Tim Hare, Florida Department of Transportation, USA.
Change 37.100 DB2 zPARM T102S106 vars were wrong in V11/V12 because
VMAC102 QWP4CYR input $EBCDIC8 but it is only one byte:
May 3, 2019 QWP4CYFR QWP4DDLM QWP4CDSTL QWP4ZHYPL QWP4STACS
These zPARM variables in DB2 V12 are now supported:
QWP4RTNP ='REORG*TS_NOPAD*DEFAULT?'
QWP4DYNPFSW ='QWP4DYNPFSW'
QWP4PSPN ='PAGESET*PAGENUM*ABSOLUTE*RELATIVE?'
QWP4RDS_DM_BLKFI='QWP4RDS*DM*BLKFI'
QWP4NIDX ='QWP4NIDX'
QWP4IXMC ='INDEX_MEMORY_CONTROL'
QWP4UHMDH ='UTILS*HSM_MSGDS*HLQ'
QWP4DINA ='DEFAULT*INSERT*ALGORITHM'
QWP4MISD ='QWP4MISD'
QWP4FLT ='QWP4FLT'
QWP4IXMT ='QWP4IXMT'
QWP4AUTC ='AUTH*COMPATIBILITY'
QWP4TSCT ='QWP4TSCT'
QWP4ENKL_OFF ='OFFSET*FOR*ENCRYPTION*KEYLABEL'
QWP4CDRL='COMPRESS*DIRLOB'
QWP4SFPR='STATFDBK*PROFILE'
QWP4AUTCSU='SELECT*FOR*UNLOAD'
Thanks to Lai Fai Wong, Bank of America, USA.
Change 37.099 Two formats for CICS Version variable SMFPSRVR displayed
FORMATS 72 instead of 'TS5.5' or '5655-Y04 in MOBILE data.
May 2, 2019
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 37.098 -Possible Abend S0C7 when using the CDF Filter SYSPLEX=
ASMRMFV after ASMRMFV change 36.241. Affects MXG releases
May 1, 2019 36.12-37.03. HAS NOT OCCURRED, exposure was observed.
-Options message RMFV037I incorrectly shows SHOWASI,
but SHOWASI option is not actually in effect. Affects
MXG release 37.03 only.
Change 37.097 APAR OA56762 NEGATIVE SMF30_TIME_ZIIP_ON_CP zOS 2.2 only,
TECHNOTE FLASH caused LARGE CPU time of 42,949,672 seconds because MXG
Apr 30, 2019 input as PIB4 expecting positive values. The INVALID
DATA BIT in SMF30TF2 for this time field WAS NOT ON.
This is variable CPUZIETM='ZIP-ELIGIBLE*CPU TIME*ON CP'
in MXG TYPE30 datasets, and the defect was in eight
subtype 3 interval termination records in this SMF file
Thanks to Jutta Gleixner-Schmid, ALLIANZ. GERMANY.
Change 37.096 RMF III dataset ZRBASI variables ASIFRXB_LF,ASIFRXA_LF
VMACRMFV and ASIFRXH_LF are the sum variables that should have
Apr 26. 2019 been divided by ASISMPCT to report their average value.
The labels are also corrected. Variables CPC_CECNAME
and LPARNAME are added to dataset ZRBBDSIH.
Thanks to Karl Laseki, American Chemical Society, USA.
Change 37.095 New variables added to TYPEDBDS (IMF from BMC):
FORMATS -DBTRIOTM DBTWIOTM DBTFLAG2 DBTFLAG3
VMACCIMS DBTNOI DBTNOO DBTBFSTK DBTBFSTN
VMACIMS -Formats for DBTFLAG2 and DBTFLAG3 created.
Apr 25, 2019 -IMS07 ENDTIME could be missing due to 8 bytes
May 3, 2019 found but not documented; detection/protection
was added.
-Variable BHTOON is added to CIMSTRAN and CIMSDBDS;
it was already kept in CIMSPROG.
-Variable ALPCPTRN was incorrectly formatted $HEX8 and
incorrectly used to create UOWTIME.
-UOWTIME was incorrectly created like CICS UOWTIME with
only 6-bytes of datetime, but IMS UOWTIME is 8-bytes in
UOWTRANS, now used to create the IMS UOWTIME.
Thanks to Randy Hewitt, DXC, USA.
Change 37.094 CICS 110 Stats CICLSRR dataset accumulated variables that
VMAC110 end with BFF/CRF/CRS/CWF/CWS/FRD/UIW are now correctly
Apr 24. 2019 deaccumulated in _SCICLS1 sort macro when TYPS110 is used
Apr 26, 2019 or it can be added after TYPE110 is included.
See Change 37.102, all CICS Statistics are deaccumulated.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 37.093 Support for IMS ODBM Accounting SMF Type 29 Subtype 1
EXTY29OD record creates the new TY29ODBM dataset.
VMAC29
Apr 24, 2019
Thanks to Kurt Gramling, T-SYS, USA.
Change 37.092 TRENDINCODE= parameter added to both macros to allow you
VMXGRMFI to limit the trend datasets. You could limit the amount
VMXGDBSS of data retained by specifying (using VMXGDBSS here) by:
Apr 20, 2019 TRENDINCODE=IF DATEPART(BEGTIME) GE TODAY()-732;
to impose a 2 year limit on the data.
====== CHANGES THRU 37.091 ARE IN MXG 37.03 DATED Apr 19, 2019 =========
Change 37.091 -TYPE42 Subtype 5 INPUT EXCEEDED when new MCO/SYO/BGO data
VMAC42 segments exist, MXG miscoded the new segments, MXG 37.02.
VGETUTKN -Hex 00 protection for UTKNPOE/UTKNSCL/SMF42GAO/SMFA2GAO/
Apr 18, 2019 SMF42FAJ/SMF42FBN/SMFA2FAJ/SMFA2FBN/SMF42GAN/SMFA2GAN.
ST 5 Error caught by Early Adopter tester in MXG 37.03EA.
-Jun 17: Variables S42VSXST and S42VSXRT were created in
MXG 37.02-03 incorrectly with $EBCDIC8 informat. This
change corrected them to &PIB.4. numeric variables in
TYPE42HI dataset, but if you build WEEKLY PDBs with some
days 37.02/37.03, and some 37.04 or later, you will need
to DROP those variables from the 02/03-built PDB.
Change 37.090 When BUILDPDB=YES is used with %UTILBLDP, the SMF 113
UTILBLDP records are automatically processed, and ASUM113 is run
Apr 15, 2019 after BUILDPDB. Now, SUPPRESS=113 can be used if you
don't want those datasets.
Change 37.089 -Major enhancements to ASMRMFV and VMACRMFV.
ADOCRMFV -New Field Data Filter (FDF) feature supports field level
ASMRMFV data selection for the RMF III ASI, CSR, and DVT tables.
VMACRMFV -The ANDIF=, ORIF=, IF= keywords are used to specify a
Apr 16, 2019 FDF filter called an IF expression.
-FDF complements the existing Character Data Filter (CDF)
feature. CDF has no numeric data filtering capability.
-If both CDF and FDF filters are used, then CDF filtering
occurs first. Entries filtered by CDF are never passed
to FDF.
-FDF supports character, fixed point, floating point,
percent, bit string, hex string, time, and time of day
fields for filtering depending on the format and content
of each field.
-FDF uses IF expressions with 3 components enclosed in
required matched left/right parentheses in this order:
1. RMF III field name or MXG variable name when
supported
2. Comparison operator
3. Character, numeric, bit string, hex string, percent,
time, or time of day value as appropriate to the
field being filtered.
-See documentation Sections 31-34 for full details on the
use of FDF.
-New RMFV080I-RMFV088I messages added for FDF support.
-New options SHOWARR (alias SHARR) and NOSHOWARR (alias
NSHARR) added to display IF expression memory storage
array activity. Default is NOSHOWARR. see Section 6
Report Control Parameters for more details.
-New options SHOWIF (alias SHIF) and NOSHOWIF (alias
NOSHIF) added to display IF expression compare results
in both Detail and Summary reports in message RMFV080I.
Default is SHOWIF. see Section 6 Report Control
Parameters for more details.
-New option IFERR= controls handling of errors detected
while processing ANDIF=/IF=/ORIF= expressions. Possible
settings are ABEND, ERROR, WARN, IGNORE. Default is
IFERR=ERROR. See Section 8 Error Handling Parameters
For more details.
-Three recently documented RMF Monitor III tables are now
supported for PDB builds: PCI, SCM, and ZFS.
-The PCIE Activity Data Table may be selected with the
PCI, P, MOST, or ALL table select options.
-The Storage Class Memory Data Table may be selected with
the SCM, MOST, or ALL table select options.
-The ZFS Performance Data Table may be selected with the
ZFS, Z, MOST, or ALL table select options.
RMF III data set.
-ASMRMFV will now detect quoted strings and not apply any
translations regardless of UPCASE/NOUPCASE settings.
-ASMRMFV will no longer check for Control Unit Busy or
Switch Port Busy when filtering DVT entries with the
NOZEROIO option. These DVT fields became obsolete and
unused with z/OS 1.4 in September 2002.
-Almost all documentation for ASMRMFV now resides only
in the ADOCRMFV member.
-ADOCRMFV has been reformatted to take advantage of full
72 column width for better legibility.
-Message RMFV033* showed an incorrect value for index
count if an I/O error occurs reading the first or last
MINTIME interval.
-Many documentation sections have been updated and 4 new
sections are added:
Section 31 Field Data Filtering (FDF)
Section 32 Filtering The ASI Table
Section 33 Filtering The CSR Table
Section 34 Filtering The DVT Table
Change 37.088 DB2 102 IFCID 106 truncated variables longer lengths are
VMAC102 now supported:
Apr 15, 2019 QWP4SADM='INSTALLATION*SYSTEM*ADMIN*USERID'
QWP4DFID='SYSTEM*DEFAULT*USERID'
QWP4ADM2='SYSTEM*ADMIN*ID2'
QWP4OPR1='MVS*OPERATOR*ID'
QWP4OPR2='MVS*OPERATOR*ID2'
QWP4REGC='DDL*REG*TABLE*OWNER'
QWP4REGA='DDL*REG*ART*NAME'
QWP4REGO='DDL*REG*ORT*NAME'
QWP4OZUS='ONLINE*ZPARM*USERID*MONITOR'
QWP4FCCD='UTILS*FCCOPYDDN*PARM*DEFAULT'
Thanks to Lai Fai Wong, Bank of America, USA.
Change 37.087 SMF 50 VTAM Tuning record subtypes 02 and 05 don't match
VMAC50 the record documentation and IBM has acknowledged and
Apr 15, 2019 will revise their doc, when this text will be updated.
This change only reverses the order of RDUX/REDE.
Thanks to Svend Zaunick, Finanz Informatik, GERMANY.
Change 37.086 MXG Support for the new Japanese Reiwa era dates is in
TECHNOTE place as MXG does not use any Japanese informats, but
Apr 10, 2019 SAS Note 63973 reports an update is needed to provide
support in NENGO and JNENGO informats/formats.
Change 37.085 SMF 92 Subtype 52 INPUT EXCEEDED. because SMF92TRSN was
VMAC92 documented as 52 EBCDIC on page 846, but there are only
Apr 10, 2019 8 bytes at the end of the record for the name, and the
segment length is 48 to match a final 8-byte field.
But I believed the SMF manual and INPUT 52 without an
extra test to see if the bytes were there.
Thanks to Joe Faska, DTCC, USA.
Change 37.084 Variables CMB10C0-CMB10C4 in VXPRCAPM are wrong because
VMACVMXA their DIF() calls had the wrong variable.
Apr 10, 2019
Thanks to Graham Harris, RBS, ENGLAND.
Change 37.083 -Ignore the first two sections of this original text.
VMACWSF -WSF/EOS revisions corrected misalignment in WSFAUDIT
VMACWSF dataset, but AUDOBJT values of '6C'x and 'B4'x are not
Apr 10, 2019 documented, and the order of AUDACT and AUDOBJT is NOT
Apr 19, 2019 consistent with the documentation, which has always has
May 14, 2019 ACT then OBJT, but for ACT values of '60'x or higher,
I've observed OBJT is first, and the value of OBJT has
to be used to decode the multiple uses of the AUDOBJI
field into the correct variable.
-Also, OBJT values of '6C'x,'B4'x are found but not
documented in the DSECT.
-Dataset WSFACCT will always have zero observations; it
was never correct and is replaced by the four datasets
WSFDSN, WSFERD, WSFEVTSC, and WSFEVTPR.
-May 14, 2019. See Change 37.111.
Change 37.082 SMF 99 ST 12 dataset TYPE99CC Capacity Increase/Decrease
VMAC99 bit variables S99CCCCAPINCR/S99CCCCAPDECR/S99_VCM_D2-4
Apr 9, 2019 are decoded into individual variables:
S99CCCCAPINCR0='ADJUST*CAPACITY*INCREASE?'
S99CCCCAPINCR1='ADJUST*CAPACITY*INCREASE*BY UNPARK'
S99CCCCAPINCR2='UNPARK*REQUEST?'
S99CCCCAPINCR3='UNPARK*ALL*REQUEST?'
S99CCCCAPINCR4='RESERVED'
S99CCCCAPINCR5='UNPARK*CAPACITY*BELOW?'
S99CCCCAPINCR6='CAPPED*UNPARK*HIGH VH*UTILIZATION?'
S99CCCCAPINCR7='RESERVED'
S99CCCCAPDEC00='ADJUST*CAPACITY*DECREASE?'
S99CCCCAPDEC01='ADJUST*CAPACITY*DECREASE*BY UNPARK'
S99CCCCAPDEC02='PARK*REQUEST?'
S99CCCCAPDEC03='PARK*ALL*REQUEST?'
S99CCCCAPDEC04='MVSBUSY*TOO*LOW?'
S99CCCCAPDEC05='VL*EFFECT*TOO LOW?'
S99CCCCAPDEC06='SMALL*VM/VL*EFFECTIVENESS?'
S99CCCCAPDEC07='NO*VM/VL*EFFECTIVENESS?'
S99CCCCAPDEC08='IF*NO*VH*EXISTS?'
S99CCCCAPDEC09='NO DECREASE*LOW*CEC*UTILIZATION?'
S99CCCCAPDEC10='PR/SM*CAPPED*PARK ALL?'
S99CCCCAPDEC11='PR/SM*CAPPED*PARK ALL*HI CEC UTIL?'
S99CCCCAPDEC12='PR/SM*CAPPED*VH UTIL*LOW?'
S99CCCCAPDEC13='PR/SM*CAPPED*VL*EFFECT*TOO LOW?'
S99CCCCAPDEC14='PR/SM*CAPPED*MVS BUSY*TOO LOW?'
S99CCCCAPDEC15='PR/SM*CAPPED*ADJUST*CAPACITY*DECR?'
S99CCCCAPDEC16='PARK ALL*REQUEST*unpark*threshold?'
S99CCCCAPDEC17='PR/SM CAPPED*NO DECR*LOW CEC UTIL?'
Thanks to Jan Tielemans, KBC, BELGIUM
Change 37.081 Velocity VPS USER records are either Interval or Summary
VMACXAM but only the top ten users get Interval records, so when
Apr 5, 2019 analyzing the USER data,you MUST select IF INTORSUM='SU'
to see the total resource usage.
Thanks to Deeresh Naidoo, First Rand Bank of South Africa.
Change 37.080A Datasets BETA9706 and BETA9706D were not output to PDB
VMACBE97 when TYPSBE97 was used to sort from work to PDB.
Apr 4, 2019
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 37.080 Variables SVPCNM Service Class and RPRTCLAS Report class
VMACRMFV are added to all the RCD datasets.
Apr 4, 2019
Thanks to Claudio A. Rodriguez, BancoGFalicia, ARGENTINA
Change 37.079 New variables DBS_DD and DBS_D are created in TYPETPMX.
VMACTPMX Variables SYSTEM,SMFTIME added to ERROR messages.
Apr 2, 2019 Variable $JCL_S decoded and output, Apr 19.
Apr 19, 2019
Thanks to Jack Hyde, OPTUM, USA.
Change 37.078 BY variable R748SIID in dataset TYPE748 format is now
VMAC74 HEX4 (was HEX2), and there are no duplicate observations
Apr 2, 2019 in TYPE748S as R748SIID is unique to each record, due
to that too-short format, false duplicates could have
been deleted in the past.
Thanks to Douglas C. Walter, CITRIBANK, USA.
Change 37.077 Enhanced to sort and remove intervals where a SYSTEM is
SAGANAL on multiple CECs, as when it was moved from one CEC to
Apr 3, 2019 another. New time range report of input SMF 30/70s.
Thanks to Bob Berg, American Family, USA.
Change 37.076 Support for HSM FSR Record addition of Unix filename in
VMACHSM dataset HSMFSRBO variable FSR2_UNAM because FSRDSN is
Apr 2, 2019 only 44 bytes, When FSR2_UNML is greater than 44, FDRDSN
will contain the first part of the name, then ... and
then the last part of the name, while FSR2_UNAM will
contain the full name (up to 128 char).
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 37.075 INPUT STATEMENT EXCEEDED and INVALID DATA for SM125THA
VMAC125 because INFORMAT &PIB.2. was missing the final period.
Mar 30, 2019
Thanks to MP Welch, Bank of America, USA.
Change 37.074 QBSTBPIN was always incorrectly calculated before the
VMACDB2 variables used in the calculation had been DIF()'d
Mar 30, 2019 yielding unrealistically high values. The calculation is
now done in DIFFDB2 after the DIF() calls are done.
Thanks to Randy Hewitt, DXC, USA.
Change 37.073 BBMQ processing reported UNEXPECTED RTINs, when you have
VMACBBMQ multiple BMC products writing to a common history file.
Mar 29, 2019 MXG BBMQ now selects only E1x-E8x, skipping other values
eliminating those log messages. There were no changes
to BBMQ 5.3 records in 5.4.
Thanks to James Wajda, Credit-Suisse, USDA.
Change 37.072 ODS Statistical graphics procedures make extensive use
TECHNOTE of JAVA, which can be very memory intensive on zOS. This
Mar 28, 2019 is any procedure starting with SG or any ODS HTML or ODS
PDF outputs. SAS recommends REGION=512M minimum but the
MXG recommendation is always REGION=0M on the JOB card
on zOS. We have seen REGION usage as high as 900M+ for
jobs running the ANAL9914 Topology report with HTML.
Change 37.071 %MACRO variables INTIME70,INTIME70EN,INTIME70PR can be
VMXG70PR used by ASUM70PR to convert time zones of LPARs to a
VMXGINIT common timezone. This example shifts all times to GMT.
Mar 27, 2019
%LET INTIME70=
%QUOTE(
STARTIME=STARTIME-GMTOFFTM;
SMF70GIE=SMF70GIE-GMTOFFTM;
MACHTIME=MACHTIME-GMTOFFTM;
);
%LET INTIME70EN=
%QUOTE(
STARTIME=STARTIME-GMTOFFTM;
SMF70GIE=SMF70GIE-GMTOFFTM;
);
%LET INTIME70PR=
%QUOTE(
STARTIME=STARTIME-GMTOFFTM;
SMF70GIE=SMF70GIE-GMTOFFTM;
MACHTIME=MACHTIME-GMTOFFTM;
);
%INCLUDE SOURCLIB(ASUM70PR);
This is an initial design, which may be revised.
Thanks to Berthold Willing, AXA, GERMANY.
Change 37.070 Unused Change Number.
Mar 25, 2019
Change 37.069 zEDC Compression types for DCOLLECT datasets revised:
FORMATS Dataset DCOLDSET, variable DCDCTYPE formated values
VMACDCOL 0=0:Not Compressed
Mar 25, 2019 1=1:Generic
2=2:Tailored
3=3:ZEDC
DCDCTYPE replaced DCOLMTYP, now always missing.
Dataset DCOLDC, variable DDCCT format MGDCOCT:
0=0:Generic
1=1:Tailored
2=2:ZEDC
Change 37.068 CF Activity Report Structure Level is moved to ANALRMF3
ANALRMF3 from VMACRMFV. Additional RMF III report examples will
Mar 21, 2019 be added in ANALRMF3.
Change 37.067 Support for RMF III PCI, SCM, ZFX segments create four
EXZRBPCI datasets ZRBPCI, ZRBSCL, ZRBZFX (System Data) and
EXZRBSCL ZRBZFS (File Server Data). ZRBSCL was used for SCM
EXZRBZFX because there already is a ZRBSCM dataset (for CFISSCMS).
EXZRBZFS
IMACRMFV
VMACRMFV
VMXGINIT
Mar 29, 2019
Change 37.066 New TOKEN variables added to TYPE80TK dataset:
VMAC80A TOKMCTOKENKY TOKMCTOKENTM TOKMSISCCNO TOKMEMPLID
Mar 21, 2019
Thanks to Mark Kerr-Delworth, Express ICS, ENGLAND.
Change 37.065 Major rewrite of this macro to eliminate repeating the
VMXGDSN same logic 3 different times. New parameter added to ID
Mar 19, 2019 your HSM managed tape volumes with a default of HSM.
Labels on VOLUMES and TAPE variables corrected to show
that they are actually counts of datasets and not a
count of volumes.
Change 37.064 Doc ONLY. Examples add to suppress 110.1 or 101 or both
UTILBLDP when BUILDPDB=YES.
Mar 20, 2019
Change 37.063 -The ANALID report showed only IDANDSUM=26.000 for either
ANALID JES2 or JES3; now the SUBS (2 for JES2, 5 for JES3) is
VMACID stored in SUBTYPE to create 26.002:JES2 or 26.005:JES3.
Mar 16, 2019 -A non-impacting note about DELETE SMFREC01/02 removed.
Change 37.062 Faulty logic prevented creation of zip eligible chart.
GRAFWRKX
Mar 15, 2019
Change 37.061 Bar charts of ZIP and ZIP eligible added.
GRAFWLM
Mar 15, 2019
Change 37.060 SMF Type 82 subtype 31 INPUT STATEMENT EXCEEDED for
VMAC82 TAG='0204' because MXG incorrectly expected 8 bytes when
FORMATS that TAG only has 8 bytes. FORMAT MG082SN revised to
Mar 20, 2019 include SERVER name.
Thanks to Randy Springs, BB&T, USA.
Change 37.059 Further corrections for IFCID 319 support.
VMAC102
Mar 10, 2019
Change 37.058 Cosmetic: Uninitialized variable CBPERROR.
VMAC30
Mar 11, 2019
====== CHANGES THRU 37.057 ARE IN MXG 37.02 DATED Mar 11, 2019 ========
Change 37.057 Analysis of what your WLM Classification Rules do, using
ANALRULE SMF 30, 101 and 110 to produce three reports for where
Mar 10, 2019 work is sent by SYSTEM and TYPETASK, routing for CICS
transactions by SYSTEM and APPLID, and routing for DDF.
Change 37.056 Unused Change.
Change 37.055 RMF III dataset ZRBCFI, CFACT Coupling Facility Activity
FORMATS Report, which is actually a CF per-Structure report, is
VMACRMFV printed by invoking _CFACT after TYPSRMFV. Macro _CFACT
Mar 9, 2019 is defined at the bottom of VMACRMFV.
Mar 21: MOVED TO NEW ANALRMF3 Report Member. CH 37.068.
Thanks to Ervin Claxon, CSX, USA.
Change 37.054 Using report classes to define workloads in RMFINTRV is a
UTILWORK good way to group workloads but will only work if all
Mar 9, 2019 workloads have a default report class, UTILWORK now
detects this condition and warns that the use of report
classes should not be attempted until this can be
resolved
Change 37.053 New utility contribution, UTILMISS, will create a data
UTILMISS set from an existing dataset, removing all variables that
Mar 8, 2019 have all numeric missing values, and characters blank.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 37.052 Variable CPUERROR in TYPE30 datasets is a two-byte field
VMAC30 but was accidentally made length $4 some time ago due to
Mar 7, 2019 a blank that gave it $HEX8 format which forced length 4.
The correct $HEX4. format is now applied, but LENGTH $4
is also forced, since a change in length will cause PROC
APPEND to fail if the user didn't specify FORCE. These
TYPE30xx datasets are too critical to not protect.
-Flag variables SMF30T32 and SMF30T33 are now kept.
Change 37.051 -IFCID 319 variable QW0319FL is replaced by a variable
VMAC102 for each bit:
Mar 7, 2019 QW0319UR='CALLER*PASSED*USER*REG*NAME?'
QW0319AE='AES*ENCRYPTION*BEING*USED?'
QW0319SC='COMPATIBLE*WITH*TCPALVER?'
QW0319SE='SECURE*CONNECTION?'
-Variable QW0319RI is INPUT and Kept.
-Variables QW0319AE QW0319IY QW0319SC QW0319SE kept.
-New variable QW0319LU='LUNAME*IF*SNA' is created
Thanks to Warren Cravey, FMR, USA.
Change 37.050 UTILBLDP now accepts USERADD=100 or 101 or both, and
UTILBLDP invokes USERADD=DB2, but if only 100 or 101 alone are
Mar 6, 2019 requested, the other record's datasets are _NULL_ed.
UTILBLDP now accepts USERADD=CICS (to read SMF 110)
Change 37.049 Variable ASIQSCANREQ is kept in RMF III ZRBASI dataset.
VMACRMFV
Mar 6, 2019
Change 37.048 Example to "BUILDPDB" only JOB-related Datasets enhanced
JCLPDBJB to support both JES2 and JES3.
Mar 5, 2019
Change 37.047 NDM-CDI dataset NDMCT variable NDMCPU was 256 times too
VMACNDM large and character NDMRIUP6/NDMTYPFK shifted because of
Mar 1, 2019 a 1 byte misalignment in the MXG Input Statement.
Thanks to Mike Creech, BKFS, USA.
Thanks to Roger Foreman, BKFS, USA.
Thanks to Glenn Halligan, BKFS, USA.
Thanks to David Kelley, BKFS, USA.
Change 37.046 Variables SMF70BPS/SMF70ACS for each SMF70CIN engine
VMAC7072 type are variables CP70BPS/IFA70BPS/ZIP70BPS/IFL70BPS
Mar 5, 2019 and CP70ACS/IFA70ACS/ZIP70ACS/IFL70ACS in PDB.TYPE70PR.
and PDB.ASUMCELP (recommended LPAR analysis) and ASUM70LP
(which is BY SYSTEM and has duplicate data.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 37.045 The CTG Version, CTGRVN was added to each of the CTG
VMAC111 datasets created from SMF 111 Records and variables
Mar 5, 2019 CTGIALRQ CTGLCNFA are kept in dataset TY111CXI.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 37.044 The BMC CMF Product generally updates VERSNRMF only on a
VMAC7072 CMF Release Boundary; values of both 792 (2.2) and 794
VMAC71 (2.3) exist on z/OS 2.3. MXG does NOT use VERSNRMF for
VMAC73 any logic, but this correction for CMF records sets the
VMAC74 VERSNRMF=794 if it was 792 and RMFSRCL Record Level is
VMAC75 81 or 82 depending on subtype.
VMAC76
VMAC77
VMAC78
VMAC79
Mar 1, 2019
Thanks to Joe Faska, DTCC, USA.
Change 37.043 Executing MXG on ASCII under a VM product, or with WORK
TECHNOTE on a network drive, bad things can happen. We SRONGLY
Feb 21, 2019 recommend keeping the WORK file local to the system on
which you are executing SAS.
Two Known Errors:
-This error was found with WORK on a network drive:
ERROR: Unable to obtain valid utility file pathname.
-This error was found under VM with WORK on a network
drive:
ERROR: A lock is not available for WORK.OPTVAR.DATA.
This one can be circumvented by adding
-filelockwait 30
to your SAS command or as an OPTION in SAS.CFG file.
Change 37.042 Change 37.024 did not protect for a blank WANTONLY, but
READDB2 only generated a cosmetic error that %SYSFUNC did not
Feb 19,2019 have right number of arguments.
Change 37.041 DCOLLECT APAR OA54879 reports that DCDEXFLG is NOT USED
VMACDCOL for zEDC compression and is now "DATA SIZES NOT VALID'
Feb 19,2019 and is for non-VSAM Extended Format Data Sets.
Data set sizes that are not valid in either or both of
DCDUDSIZ or DCDCUDSZ variables, which might contain non
zero values, but should not be used.
Thanks to Robert Chavez, FPL, USA.
Change 37.040 Dataset TYPE749 variable R7491DEFCOMPRATIO wrong value
VMAC74 is corrected to
Feb 19,2019 IF R7491IOB GT 0 THEN
R7491INFCOMPRATIO=R7491IIB/R7491IOB;
ELSE R749INFCOMPRATIO=.;
Variables were reversed in the calculation.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 37.039 Three MQ reports matching IBM's MQSMF program. Currently
ANALMQ the reports are a queue summary, a detail report of PUTS,
Feb 14,2019 and a detail report of GETS. The GETS/PUTS reports can
be output to either or both SYSOUT or CSV files.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 37.038 Simple report that combines catalog records (TYPE6156)
ANALHSM1 with HSM activity (HSMFSRST) to generate a report of
Feb 14, 2019 datasets that may be thrashing between primary and
migration.
Thanks to Richard Way, Office Depot, USA.
Change 37.037 Updates found in the Jan 14, 2019 SMF Manual,
FORMATS with more changes to come in 37.03 when validated.
VMAC124 -New Datasets
VMAC41 TYPE42VO='PER-VOLUME STATISTICS'
VMAC42 TYPE42HI='HIGH RESPONSE TIME JOBS'
VMAC7072 -TYPE70 New variables
VMAC74 SMF70_IPL_TIME ='IPL*DATETIME*OF*PARTITION'
VMAC78 SMF70_TRG_M_COUNT='TRG*MEMORY*CONSUMPTION*SAMPLES'
Feb 19, 2019 -TYPE70TR New variable
TRG_MEM ='TENANT*MEMORY*CONSUMPTION*MGBYTES'
-TYPE7002 New variables
R7023SCOPE='80X=CPC SCOPE*40X=SYSTEM*SCOPE'
R7023DID='DOMAIN*ID'
-TYPE70X2 New variables
R7024SCOPE='80X=CPC SCOPE*40X=SYSTEM*SCOPE'
R7024DID='DOMAIN*ID'
-TYPE70Y3 New variables
R7025SCOPE='80X-CPC SCOPE*40X=SYSTEM*SCOPE'
R7025DID ='DOMAIN*ID'
-TYPE749 New Variables
R749LKID='SYNC*I/O*LINK*IDENTIFER'
-TYPE78IO Change
R783DSTX relocated.
-TYPE41 Change
SKIP LOGIC protection for future, no impact now.
-TYPE 42 SUBTYPE 5 New Variables
S42VRID1='DELAYS*TIME*1-10 MICROSEC'
S42VRID3='DELAYS*TIME*100-10000 MICROSEC'
S42VRID4='DELAYS*TIME*1-10 MILLISEC'
S42VRID5='DELAYS*TIME*10-100 MILLISEC'
S42VRID6='DELAYS*TIME*OVER*100 MILLISEC'
S42VRIDM='MAXIMUM*I/O*INTERRUPT*DELAY TIME'
S42VRIDT='DATETIME*OF THE*MAXIMUM'
S42VRIDA='AVERAGE*I/O*INTERRUPT*DELAY TIME'
S42VRBSY='TOTAL*BUSY*TIME'
S42VRRSP='COMMANDS*DELAYED*BASE*RESERVED'
S42VRRSN='CHANNEL*PROGRAMS*WITH*RESERVE'
S42VRRES='DURATION*WHEN*RESERVED'
S42VRREX='LONGEST*CONTINUOUS*RESERVED'
S42VRRSR='AVERAGE*RESPONSE*PROGS WITH*RESERVE'
-TYPE 42 SUBTYPE 6 New Variables
S42SNAVGARDELAY ='AVG APPLICATION*RESUME*DELAY'
S42SNARDELAYCOUNT='AVG APPLICATION*RESUME*DELAYS'
S42DXMXI ='STORAGE*SUBSYSID*FOR S42DSMXR'
-TYPE124 New variable
SM124S1WWPN='WORLDWIDE*PORT*NAME'
Change 37.036 Some IFA variables were not populated in the four output
VMAC7072 datasets created by ASUM70PR; all IFA variable names are
VMXG70PR unchanged, but all "ZAAP" text in labels is now "ZCBP".
Mar 5, 2019
Change 37.035 DB2 V12 overlooked Package Variables now INPUT and KEEP:
VMACDB2 QPACAWLH ='LATCH*WAIT*TIME'
Feb 7, 2019 QPACANLH ='WAITS*TRACE*EVENTS*LATCH'
Mar 5, 2019 QPACRLNU ='THREADS*TO ROLL DATA'
QPACAACC ='WAITS*TRACE*EVENTS*ACCELERATOR'
QPACAACW ='WAIT TIME*ACCELERATOR*REQUESTS'
QPAC_PQS_WAIT ='WAIT TIME*TO SYNC*PARALLEL*QUER'
QPAC_PQS_COUNT ='SUSPENDS*WAITING*SYNC*PARALLEL'
QPAC_PIPE_WAIT ='WAIT TIME*PIPE'
QPAC_PIPE_COUNT ='WAITS*FOR*PIPE'
QPAC_COPYID ='PACKAGE*COPY*ID'
-Macros _N100/N101/_S100/_S101 defined for UTILBLDP.
Change 37.034 Two more SMF 42 subtype 5 ABENDING invalid LENSR=520/592
VMAC42 length values added to the test. APAR OA54668 corrects.
Feb 7, 2019 LENSR IN(232,240,320,376,400,480,448,304,520,560,592,640)
Change 37.033 Support for Axway V3.3.2 2018/06/27 restructured User
VMACAXWY SMF record.
Feb 6, 2019
Thanks to Warren Cravey, FMR, USA.
Change 37.032 TYPE749 z/EDC data, DIVIDE BY ZERO protection failed if
VMAC74 both R7491DCT and R7491ICT were zero; R741BPS had been
Feb 5, 2019 included in the test, but it's always non-zero so the
test now is IF SUM(R7491DCT,R7491ICT) GT 0 THEN
R749FPGBPRT=(1048576*R7491BPC/((R7491DCT+R7491ICT)*R7491BPS));
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
====== CHANGES THRU 37.031 WERE IN MXG 37.01 DATED Feb 3, 2019=========
Change 37.031 Bar charts of MIPS and % CPU added to the analysis work
GRAFWLM by IMPORTANCE, originally based on Peter Enrico's paper.
Feb 3, 2019
Change 37.030 MXG 36.12-37.01 ASMRMFV ASI NOZEROCPU filter stopped
ASMRMFV filtering which could cause a significant increase in the
Feb 3, 2019 size of the RMFBSAM file and the PDB.ZRBASI dataset.
ASICPUTA_LF was added by Change 36.241 to that filter,
but it is an accumulated field that can not be used as it
is always non-zero. NOZEROCPU is supported for z/OS 2.2+
-Section 5 "Input Data Control Parameters" is updated.
====== CHANGES THRU 37.029 WERE IN MXG 37.01 DATED Feb 1, 2019=========
Change 37.029 A reference line of the values for SMF70LAC (overall
ANAL89 rolling 4 hour avg MSU) added to interval MSU charts.
Feb 1, 2019
Change 37.028 Support for z/VM 7.1 (INCOMPAT, BROKEN CONTROL RECORD)
VMACVMXA due to insert in VXPRCDHF plus the change in HCPCPEID
Jan 31, 2019 value for the Service Level test from '40061802 for 6.4
Feb 14, 2019 to '10071802' for 7.1 that failed when tested for 'GE'.
New variable ZVMVERS='07.1.18.1' is created so GE can be
used for IF ZVMVERS GE tests. There were 32 bytes added
to PRCDHF, but the 7.1 DSECT only shows on byte added.
-Heuristic (ZZQUCT+1) test revised, false positive caused
large VMDTTIME value.
Thanks to Graham Harris, RBS, ENGLAND.
Change 37.027 Example added to email the final condition code of a SAS
EMAIL job running in the background on ASCII.
Jan 31, 2019
Change 37.026 If you create your own SUBSYSTEM that handles JES2 output
VMAC26J2 the SUBS value in SMF 26 records is not the expected 0002
Jan 30, 2019 for JES2 (or 0003 for JES3), but instead is a two byte
character field. Previously, MXG TYPE26J2 only output
SUBS=2 execution purge records. Now, if the SUBS is 3,
the JES3 record is deleted with MXGERROR messages that
TYPE26J3/BUILDPD3 must be used for JES3. If the SUBS is
other than 2, the records are presumed to be valid JES2
records, but MXGWARN messages print the SUBSYSTEM name.
Thanks to Randy Hewitt, DXC, USA.
Change 37.025 CICS variable A11ACTCI in CICS Statistics dataset CICDQG
VMAC110 was INPUT but not KEPT.
Jan 29, 2019
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 37.024 Using READDB2 with WANTONLY arguments DB2ST/DB2PST caused
READDB2 ERROR: Char Operand in the %EVAL, due to a superfluous
Jan 29, 2019 AND in an %IF statement that also exposed that PDBOUT=YES
Feb 1, 2019 failed in the PROC SORT of the DB2STATx datasets.
The WANTONLY doc has been updated to note that
WANTONLY DOES NOT SUPPORT DB2STATS DB2STATR DB2GBPST
DB2STATB DB2SDTSBP AND DB2STAT5 DATASETS.
Thanks to Keith C. Shaffer, Cigna, USA.
Thanks to James Cyr. Cigna, USA.
Change 37.023 Unused Change Number.
Change 37.022 The new $MGRMIPS format that maps IBM processor model to
GRAFWRKX MSU and MIPS capacity (created in 37.001) is now used in
GRAFCEC these Graphs, which use PDB.ASUMCELP which has variable
Jan 28, 2019 CPCFNAME so MIPS can be calculated from percent busy:
MIPS=PCTBUSY/100*PUT(CPCFNAME,$MGRMIPS.);
The CPCFNAME is constructed from CPU TYPE and MODEL as
CPCFNAME=PUT(CPUTYPE,$HEX4.)!!'-'!!CPCMODEL;
programmatically, or manually as '3906-420' for that z14.
Thanks to Ervin Claxon, CSX, USA.
Change 37.021 If you run on ASCII with autoaloc=yes and did not put an
VMXGALOC execution of VMXGALOC in your IMACINIT (strongly our
Jan 28, 2019 recommendation) but added a second execution of VMXGALOC
and the parameters did not precisely match those you used
in BLDSMPDB and did not specify READONLY=YES to suppress
the aging off of old directories you could potentially
lose data as it deleted old directories. This change now
looks to see it you specified READONLY as NO and the
current days PDB has already been created it will
generate an MXGNOTE and set READONLY to YES.
-YR2KEEP and BASEYEAR parameters are added to let you
allocate a yearly PDB, Defaults to 0, so it won't be
created or allocated unless you enable it, and you will
need to update your BLDSMPDB to add the dataset names
you want created in the yearly directories. Contact
support@mxg.com if you need help.
Change 37.020 Unused Change Number.
Change 37.019 Documentation note for VMXGUOW/ASUMUOW. If you have a
VMXGUOW tailored CICSTRAN dataset and have dropped any variables,
Jan 25, 2019 you may get an UNITIALIZED message for those variables in
ASUMUOW. While this is an expected and non-critical error
you can remove the error by editing the _KUOWIDC _KUOWCIC
or _Kuowcix macros where the variables appear and simply
remove the variable(s) from the list.
Change 37.018 Support for STC HSC Subtype 32 & 33 create new datasets
EXSTCV32 STCVSM32='RESERVED,INTERNAL USE'
EXSTCV33 STCVSM33='MVCPOOL USAGE'
VMXGINIT
VMACSTC
Jan 27, 2019
Thanks to Randy Hewitt, DXC, USA.
Change 37.017 Many non-fatal corrections were made to type 92:
VMAC92 -Several 16-byte STCKE datetimes inputs were wrong:
Jan 24, 2019 SMF92CCT,SMF92MCT,SMF92CCT,SMF92FSMN
-GMT92OFF had to be relocated around the STCKE INPUT.
-Subtype 50+ have 72 byte data section, 32 for LT 50.
-Subtype 50 variables LRP-LRN only in SMF92EVENT=1,
and INPUT changed from &PIB.4.3 to &PIB.4.0.
-Subtype 50 variables OVS/OCH only in SMF92EVENT=4
-Poor Labels SMF92EVENT/SMF92VOL/SMF92CCHH/SMF92VCN
were enrichened.
-Subtype 50 SMF92OCH corrected format to HEX for CCHH.
-Variable SMF92ADN only kept in TYPE9217 dataset.
-Subtype 59 only the first instance was output.
-Subtype 52 and 54 had incorrect SKIP values.
-Subtype 58 SMF92TRL relocated outside the loop.
-Subtype 59 2 byte filler removed with STCKE fix.
This demonstrates the difficulty in writing new code
with no SMF records to test. SMF 92 code was updated
in Aug 2017 in Change 35.180, expecting a user to send
SMF data if problems were observed, and that didn't
happen until January 2019, with most of the above fixes
mostly done by these two users:
Thanks to John Compton, World Programming Ltd, ENGLAND.
Thanks to Steve Bagshaw, ITMetrics, ENGLAND.
Change 37.016 Report showing total bytes/counts and min/max datetimes
ANALID for each SYSTEM is added as the second report.
Jan 19, 2019
Change 37.015 Variable EDGRTIME had missing values with DATEFORM=E/A/I;
FORMATS RHDTFORM logic moved ahead of EDGRTIME for H record and
VMACEDGR label corrected to EDGRTIME='REPORT*DATE TIME'
Jan 20, 2019
Thanks to Lindsay Oxenham, Department of Defence, AUSTRALIA.
Change 37.014 INPUT EXCEEDED DB2STAT1 SMF 100 Subtype 1 NETEZZA/IDAA
VMACDB2 record because IBM changed the length of OFFQ8ST segment
Jan 18, 2019 but couldn't change LENQ8ST because it is a single field
in the header that should apply to all segments. But the
correct length is now set with LENQ8ST=Q8STNAME_OFF+8;
using the end of the name field for the actual length.
Thanks to Graham Harris, RBS, ENGLAND.
Thanks to Randy Hewitt, DXC, USA.
Change 37.013 New example to count both TAPEDRVS and STEPS, and the
ANALCNCR Concurrency with only one pass of the data.
Jan 20, 2019
Thanks to Randy Hewitt, DXC, USA.
Change 37.012 z/VM Service Level 40061802 INPUT STATEMENT EXCEEDED due
VMACVMXA to VMMTRSYS inserting 60 bytes in the 1.04 record.
Jan 17, 2019
Thanks to Craig S. Bigler, Progressive Insurance, USA.
Change 37.011 Variables QXFETCH/QWACSPEB UNINITIALIZED due to misspell.
VMXGUOW Enhanced to make it easy to only process CICSTRAN data:
Jan 19, 2019 IF _LDB2ACC=_NULL_, DB2 data will not be read.
Jan 25, 2019 IF _INMQ=_NULL_ MQ data will not be read.
Counts of OBS before and after are created and if the
OBS reduction is LT 2, an MXGNOTE advises you to skip
using ASUMUOW which can be very CPU intensive and is
really needed for heavy CICS MRO sites, to consolidate
those multiple CICSTRAN observations into one UOW,
Unit of Work observation.
Thanks to Gary Keeres, Indianapolis Power & Light, USA.
Change 37.010 Reserved Change Number.
FORMATS
VMAC89
Jan 16, 2019
Change 37.009 The $%VGETOBS(DDNAME=&PDBMXG should be (DDNAME=&PDBMXG1
GRAFCEC although no error occurred unless you had set a value
Jan 14, 2019 other than "PDB" for the location of the input PDB.
Thanks to Tom MacCabe, Dominion Energy, USA.
Change 37.008 Enhancement, addition of INCODE= parameter to allow
GRAFWRKX selection by date or system with your inserted code.
Jan 11, 2019 Suppressed a no longer needed graphics catalog note.
Change 37.007 -Support for Beta93 Version 6.2 subtypes 2 and 3, which
VMACBETA both have a lot of undocumented data: subtype 2 docs 140
Jan 22, 2019 but length is 208 and subtype 3 docs 156 with 224 length.
Change 37.006 -If MXGDEBUG has length GT 0 and DSNSTRING or DATASET are
VMXGPRAL zero, debugging messages are created by VMXGPRAL.
VMAC102 -Unmatched parens in data set labels read by VMXGPRAL
Jan 11, 2019 caused non-fatal error messages for datasets with obs:
ERROR: Expected close parenthesis after macro function.
All MXG dataset's labels were examined and VMAC102 for
IFCIDs 84 85 86 87100 101 174 AND 175 were corrected.
Change 37.005 Support for DB2 102 Trace IFCID/SUBTYPE 404 populates
VMAC102 T102S404 (Authorization Compatibility) dataset with
Jan 10, 2019 QW0404xx variables.
Thanks to Warren Cravey, FMR, USA.
Change 37.004 Reading z/OS DATA using the SAS FTP Access method needs
TECHNOTE the RCMD='SITE RDW' argument:
Jan 9, 2019 FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )
USER='XXXXXX' HOST='YYYYYYY' DEBUG
S370VS RCMD='SITE RDW' LRECL=32760
PASS='XXXXXXXX' PASSIVE;
If RCMD is not used, the transfer will time out when
PASSIVE is specified, or will produce a RACF ERROR
if PASSIVE was not specified.
Change 37.003 SMF119 dataset TYP11952 variable SMF119ML_IP_IPV4 was
VMAC119 wrongly compressed of blanks from variable TIRIP instead
Jan 8, 2019 of from SMF119ML_IP_IPV4 in line 4519.
Thanks to Randy Shumate, RELX Group, USA
Change 37.002 -SMF92 Subtype 8 INPUT STATEMENT EXCEEDED because the
VMAC92 documented length of SMF92GDD in the SMF Manual is 4,
Jan 8, 2019 but the length in the record is 8 bytes.
-There were also numerous non-fatal corrections:
-SMF92 Subtype 50, SMF92STHCL missing period, and names
SMF90OIOCCL/SMF82VCX were corrected to SMF92.
Thanks to Miroslav Kubik, IBM Corporation, CZECH REPUBLIC.
Thanks to John Compton, World Programming Ltd, ENGLAND.
Change 37.001 -Improve ability to propagate variables of interest to
ADOCRMFV multiple SAS data sets during RMF III PDB build.
ASMRMFV -RMF III CPCDB table fields CPC_CecMSU, CPC_LparMSU, and
FORMATS CPC_HomeLPName, are added to MXG01 record from the first
VMACRMFV MINTIME interval for each RMF III VSAM dataset at open,
Jan 6, 2019 but those MXG01 values are the values only at start.
Jan 14, 2019 -Format $MGRMIPS is created to map GEIMODEL/GEIIMDL to
Jan 29, 2019 create the CPC_CECMIPS using IBM's LSPRITR table:
Feb 2, 2019 IBM Resource Link: Large Systems Performance Reference
https://www-01.ibm.com/servers/resourcelink/
lib03060.nsf/pages/lspritrzOsv2r2?OpenDocument
-RMF III GEI table fields GEIMODEL and GEIMDL added to
MXG01 record from the first MINTIME interval for each
RMF III VSAM data set, but the MXG01 value is only the
RMF III start. But by RETAINing these fields from the
GEI and CPU records, and by relocating the write of the
GEI, CPU, and CPCDB records before the ASI records for
each interval, the CEC MODEL/Speed and MSU/MIPS capacity
variables CPC_CECNAME CPUCEMSU CPUCEMIPS CPULPMSU
GEIMODEL GEIIMDL and LPARNAME are populated in ZRBASI
and several other datasets.
-NOTE: Not all the fields mentioned above are always
static. Use the RMF III DATASET SWITCH option to force
RMF III to overwrite the oldest data set whenever it is
started if separation of configuration changes by data
set is desired.
-CSVQUERY macro added to show load module size in Change
36.241 for ASMRMFV destroyed pointer to SCT (Step Control
Table). This caused ASMPGM and ASMSTEPN fields in MXG00
record to be garbage and also in message in VMACRMFV.
-Section 12 "Messages" is updated.
-In MXG 36.36 the fields GEIIMDL/GEIMODE were added to
ZRBASI, but they could be incorrect, precipitating
this change in logic in VMACRMFV.
LASTCHANGE: Version 37.
====-====================MEMBER=CHANGE36================================
/* COPYRIGHT (C) 1984-2019 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG ANNUAL VERSION 36.36 is dated Jan 4, 2019, thru Change 36.255.
MXG VERSION 36.12 was dated Dec 25, 2018, thru Change 36.246.
MXG VERSION 36.11 was dated Dec 3, 2018, thru Change 36.236.
MXG VERSION 36.10 was dated Nov 21, 2018, thru Change 36.229.
MXG VERSION 36.09 was dated Oct 18, 2018, thru Change 36.197.
MXG VERSION 36.08 was dated Sep 10, 2018, thru Change 36.170.
MXG Version 36.07 was dated Aug 8, 2018, thru Change 36.149.
MXG Version 36.06 was dated Jul 9, 2018, thru Change 36.128.
MXG Version 36.05 was dated Jun 13, 2018, thru Change 36.119..
MXG Version 36.04 was dated May 8, 2018, thru Change 36.091.
MXG Version 36.03 was dated Apr 2, 2018, thru Change 36.064.
MXG Version 36.02 was dated Mar 5, 2018, thru Change 36.050.
First MXG Version 36.01 was dated Feb 6, 2018, thru Change 36.026.
Annual MXG Version 35.36 was dated Jan 8, 2018, thru Change 35.309.
The Last MXG Newsletter SIXTY-NINE was dated Jan 3, 2018.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 36.36 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 36.36.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame, although there are
no new NEWSLTRS updates; they are now found in CHANGESS as TECHNOTEs.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG ANNUAL VERSION 36.36 DATED Jan 4, 2019, THRU CHANGE 36.255.
==MAJOR CHANGES ADDED IN MXG 36.36, DATED Jan 4, 2019 THRU 36.255.
New Product Support
TYPEDB2 36.254 Support for Fast Traversal Index adds variables.
TYPE72GO 36.253 MOBILE Service Units CPU Time not in CPUTM variable.
Incorrect, see Change 37.120.
TYPE102 36.251 Support to populate T102S126 for DB2 102 IFCID 126.
TYPE119 36.250 New variables added to TYP11952 subtype 52 dataset.
ENHANCEMENT
DOCVLONG 36.247 Utility to create DOCVER with all info on one line.
VMXGSUM 36.249 OBS=0 protection adds non-zero SYSCC Error test.
==MAJOR CHANGES ADDED IN MXG 36.12, DATED Dec 25, 2018 THRU 36.246.
TYPERMFV 36.241 CPC_CECNAME added, ASITRT/TET corrected, MSU ACT.
New Product Support
TYPEMGCR 36.240 Support for MegaCryption MEGACR34, subtype 3 and 4.
TYPEBETA 36.246 BETA 93 Version 6.2.0 updates subtypes 0/22/25/50/59
ERROR Correction
TYPEIMS 36.238 MXG 36.11 IMS 14.1 invalid offset ABEND IMS56FA.
TYPEVMXA 36.237 MXG 36.11 old z/VM 6.3 DATA LOSS ABEND MTRSYS 1.04.
VMXGALOC 36.243 Protection for READONLY=YES with FIRSTRUN=NO
BLDSMPDB 36.242 Protection for AUTOALOC=YES and FIRSTRUN=YES
VMXGSUM 36.245 VMXGSUM with user's INCODE GT 32756 chars, ABEND.
ENHANCEMENT
TYPE110 36.244 CICS Variable D2GDB2ID added to CICDB2GL BY list.
==MAJOR CHANGES ADDED IN MXG 36.11, DATED Dec 3, 2018 THRU 36.236.
New Product Support
TYPE110 36.235 Support for IBM CICS/TS 5.5 SMF 110 CICSTRAN INCOMPAT
UTILEXCL 36.235 Support for IBM CICS/TS 5.5 SMF 110 CICSTRAN INCOMPAT
Yes, you need MXG 36.11 for CICS/TS 5.5 because fields were
inserted into SMF 110 CICSTRAN records and using old MXG will
have trashed values due to the misalignment, but MXG could run
and only print error messages, which might be false positives,
or could execute with no errors nor log messages, especially if
you have a tailored IMACEXCL, but your CICSTRAN dataset will
still be invalid.
TYPETMO2 36.236 Support for ASG-TMON CICS for z/OS V4.2 - NO CHANGES.
TYPEMVCI 36.234 Support for BMC's MainView for CICS(v69) COMPATIBLE.
ERROR Correction
TYPEPOEX 36.231 Protection for truncated POEX File Segment records.
TYPE119 36.230 ZERT SMF 119 Subtypes 11 and 12 minor corrections.
Enhancements
ANAL9914 36.232 SMF99 ST 14 Processor Topology Report Enhanced.
==MAJOR CHANGES ADDED IN MXG 36.10, DATED Nov 21, 2018 THRU 36.229.
ERROR Correction
TYPEVMXA 36.221 MONWRITE DEFECT caused large values, LCUPPNUM issue.
TYPE110 36.220 Variable WTOTIOTM could exceed ELAPSTM
TYPE72GO 36.215 Variable MSUSOFT, Software MSU frequently missing.
TYPE102 36.212 Protection for IFCID 376 invalid offsets STOPOVER.
TYPE74 36.211 TYPE749 variables added and corrected.
TYPERMFV 36.201 MXG 36.09, z/OS 2.2 only, ASIxxx text misaligned.
TYPERMFV 36.201 WPS failed ERROR: format '$ CPUPHYAD' invalid
TYPEVMXA 36.198 z/VM VXBYUSR High CPU, records not on same second.
New Product Support
TYPE21 36.218 Support for APARs OA52915 and OA52940, 4 byte counter
TYPEBE97 36.217 Support for new BE97 subtype 6 and subtype 22 update
TYPE7072 36.208 Support for APAR OA56011 for TYPE70 OSPROTECT.
TYPE122A 36.207 Support for zExplorer SMF 122 Subtype 2.
TYPEBETA 36.199 Beta 93 Subtype 51 and subtype 22 updates.
Enhancements
GRAFMSU 36.204 Plots/Tabulate of MSU 4HR usage and capacity.
ANALRMFR 36.203 CPU report with INTERVAL=HOUR was incorrect.
TECHNOTE 36.209 APARs of interest for z/OS.
ASUMCICR 36.226 Major revision to CICS RESPONSE TIME SLA reports.
TYPESTC 36.222 Numerous STC formats were updated with new values.
==MAJOR CHANGES ADDED IN MXG 36.09, DATED Oct 18, 2018 THRU 36.197.
ERROR Correction
TYPE42 36.194 Another 42 Subtype 5 LENSR=376 invalid value ABEND.
TYPEXAM 36.195 zVPS MTRSYS Serious Error ABEND, undoc SEGLEN=336.
TYPEPOEX 36.183 Power Exchange USER SMF STOPOVER if File Length zero
TYPE74 36.191 Type 74 Subtype 8 R748Sxxx Sync I/O misaligned.
TYPEXAM 36.181 Support for zVPS/XAM USEDIAG segment (INCOMPAT).
UTILBLDP 36.180 UTILBLDP with RMFINTRV=NO/BUILDPD=YES, no PDB.TYPE70.
TYPE89 36.178 New Target Resource Group TYPE89R2 incomplete/wrong.
READDB2 36.172 READB2(IFCIDS=0-999) failed at highest IFCID 367.
UTILBLDP 36.176 MXG 36.08, Extraneous % with EXPDBOUT= 180 ABEND.
New Products Support
TYPE30 36.188 Support for SMF 30 USERKEY RAX Bit 4 CSA RAXFLAGS.
APAR OA53355 added SMF30_RAXFLAGS, MXG in 35.09
This change decodes each bit.
TYPEIMST 36.192 Support for IMS Version 15 IMS56FA (COMPATIBLE).
ANAL9914 36.171 Support for z/14 Clusters IBM Processor Topology rpt.
TYPERMFV 36.196 Support for new z/OS 2.3 variables (COMPATIBLE)
TYPECMFV 36.173 Support for Mainview MVS History Records new datasets
TYPEZCOS 36.174 Support Auto Soft Capping (ZCOS) Version 4.2 INCOMPAT
UTILEXCL 36.179 Support for USER CICS fields USER3/USER3 and ATOUSER.
Enhancements
TYPETMS5 36.193 Estimated bytes after IDRC added variables.
TYPE84 36.184 JES 2 JMF Subtype 21 INPUT EXCEEDED ABEND.
==MAJOR CHANGES ADDED IN MXG 36.08, DATED SEP 10, 2018 THRU 36.170.
ERROR Correction
TYPE70 36.166 CRITICAL ERROR: PDB.TYPE70 MAY BE WRONG WITH 33 ENGS
RMFINTRV 36.166 CRITICAL ERROR: PDB.TYPE70 MAY BE WRONG WITH 33 ENGS
New Products Support
TYPECIMS 36.167 Support for BMC Energizer for IMS Connect for IMF.
TYPE30 36.150 Support for APAR OA54589, OSPROTECT, TRUSTED.
TYPECIMS 36.162 Support for multiple IMS SYSTEMS, using JFCB DSNAME.
TYPEVMXA 36.155 Support for z/VM LINUX LNXAPPL Process & Summary data
TYPE106 36.152 New SMF 106 variables decoded and formatted.
TYPE42 36.151 New variables from Jul 30, 2018 SMF Manual.
TYPE62 36.151 New variables from Jul 30, 2018 SMF Manual.
Enhancements
ANAL89 36.165 Analysis of SMF 89 data, including MSU from CPU time.
TYPECIMS 36.163 IMS56FA obs for CPI-C had incorrect INPQUETM.
GRAFWLM 36.153 New HIGHTOLOW parm to reverse IMPORTANCE order.
==Major CHANGES added in MXG 36.07, dated Aug 8, 2018 thru 36.149.
New Products Support
TYPERSDA 36.143 Support for RSD Folders Version 6.0 AUDIT (INCOMPAT).
TYPEPOEX 36.135 Support for PowerExchange Version 10.
TYPEWSF 36.132 Support for EOS Version 160 (INCOMPATIBLE).
Enhancements
COMPINTV 36.144 Compare RMF/SMF/CICS/DB2 Interval CPU Time captured.
READDB2 36.140 New SORT102=NO option can suppress T102Snnn sorts.
UTILBLDP 36.139 AUDITAFTER, SUPPRESS=ID, SORTOUT=NO revisions.
RMFINTRV 36.136 MXGABNDRMFI option will ABEND if OTHER Work found.
ERROR Correction
TYPE102 36.138 Dataset T102S018 was misaligned.
TYPERHEL 36.137 Invalid data for variable MICROCODE.
TYPE120 36.134 WebSphere SMF 120 subtypes 5/6 only first was output.
ASUM113 36.133 Variable LPARBUSY was not calculated for z14.
TYPESMF 36.131 MXGREADSMF=LOGGER didn't invoke CICSIFUE exit.
Technical Notes
MXGNOTE 36.141 zHPF Channel Utilization
SASNOTE 36.129 SAS Not 61906 SAS 9.4 TS1M3 High CPU fixed in M4/M5.
==Major CHANGES added in MXG 36.06, dated Jul 9, 2018 thru 36.128.
ABEND Circumvention
TYPE42 36.124 SMF 42 ABEND, more invalid values found, protected.
APAR OA54663 corrects IBM Invalid values.
New Products Support
TYPEBVIR 36.120 Support for BVIR V412 History HSM Compression data.
TYPE119 36.127 Support for ZERT SMF type 119 Subtype 12
ERROR Correction:
READDB2 36.121 READDB2(IFCIDS=ALL) did not create DB2STATS dataset.
==Major CHANGES added in MXG 36.05, dated Jun 13, 2018 thru 36.119.
New Products Support
TYPESRDF 36.112 Support for SRDF Symmetric Remote Data Facility VV.RR
TYPE80A 36.108 Support for RACF TOKENs REQTCRE and ADMINCII'
TYPE102 36.102 Support for DB2 V11 APARS PI71903/PI84045/PI82755.
TYPE101 36.101 Support for NDM-CDI OP record.
Enhancements:
JCLCPORT 36.111 Sample JCL to move WPS datasets to SAS.
TYPENMON 36.109 Significant CPU reduction processing NMON data.
TYPERHEL 36.109 Significant CPU reduction processing RHEL data.
ASUMUOW 36.107 Using ROLLUPS is useless with ASUMUOW, suppress DB2.
ERROR Correction:
ASMRMFV 36.110 SOC7 ABEND reading non-Extended Format VSAM dataset.
TYPEDB2 36.114 DB2ACCTR dataset has been misaligned, NRQLAC GT 1.
TYPEDB2 36.113 Incorrect test for QPAC_PIPE_WAIT/COUNT in DB2ACCTP.
THIS HAS NOT BEEN TESTED WITH DB2 V12 NRQLAC GT 1.
A POSTING TO MXG-L WILL REPORT SUCCESS/PROBLEMS.
TYPE42 36.106 TYPE42DS Encryption variables were not kept.
TYPESYSX 36.105 TYPESYSL renamed to TYPESYSX to avoid conflict.
TYPEACF2 36.100 ACF2 6.2 Change 36.076 didn't correct STOPOVER.
READDB2 36.092 ACCTSORT=NO was not working, data ended up in WORK.
==Major CHANGES added in MXG 36.04, dated May 8, 2018 thru 36.091.
New Products Support
TYPE122A 36.066 Support for IBM Devel z Systems IDZ SMF 122 record.
TYPE119 36.079 Support for SMF 119 subtypes 24, 38, 39, 40, and 45.
TYPEACF2 36.075 ACF2 INVALID SMF RECORD, ACSMFREL=0, should be 6.2.
TYPEIAM 36.071 INPUT STATEMENT EXCEEDED IAM 9.2 Length Changed.
TYPE7072 36.073 Support for z14 ZR1, new SMF70MAXPU variable COMPAT.
Enhancements:
ANALID 36.081 Support for four-digit SMF Record type reporting.
TYPEDCOL 36.086 z/OS 2.3 DCOLLECT Encryption Variables added DCOLDSET
TYPE99 36.072 New EWLM & SERV variables added to TYPE99_6 dataset.
CONFIG 36.067 MXG default CAPSOUT option for z/OS now NOCAPSOUT.
ERROR Correction:
TYPESTC 36.084 Dataset STCVSM11 Change 34.237 variables corrected.
TYPEDB2 36.082 DB2 BPHITRAT corrected.
CONFIG 36.078 OPTION SORTBLKREC corrects DFSORT OC4 in SAS 9.4 M3.
TYPE110 36.077 CICDS Dispatcher Statistics DSGTWT corrected.
TYPEBETA 36.074 Variables BETALOG reversed, subtype 51 doesn't match.
==Major CHANGES added in MXG 36.03, dated Apr 2, 2018 thru 36.064.
New Products Support
TYPEQACS 36.051 AS/400 Ver 7.3, INCOMPAT LRECL, undoc fields.
TYPE74 36.057 z/OS RMF 2.3 Enhancements, APARs, new SMF manual.
TYPEXBM 36.060 Support for BMC Extended Buffer Mgr XBM User SMF
All updates in the Jan, 2018, SMF Manual are included in 36.03.
Enhancements:
TYPE74 36.056 DEVNR5HEX displays 5-hex-nybble zWrite DEVICE NR.
SMFINTRV 36.053 SMF Interval INTBTIME/INTETIME all DATETIME25.6
ERROR Correction:
TYPEVMXA 36.062 VXBYUSR deaccum corrected for new _MT1 variables.
TYPEXAM 36.061 Invalid SYTNLPS value in SYTCUP prevented output.
UTILBLDP 36.059 CHAR OPERAND FOUND if USERADD=ID was requested.
TYPE82 36.055 New TYPE8231 was misaligned, trunc 0203 protected.
BLDSMPDB 36.054 &PDBPATH was not initialized, when MTD requested.
ANALDB2R 36.058 36.02 Only, missing %END corrected.
==Major CHANGES added in MXG 36.02, dated Mar 5, 2018 thru 36.050.
New Products Support
TYPEIMS 36.040 Support for unpopulated IMS 56FA with APAR UI50912.
TYPEXCOM 36.047 Support for XCOM Version 36.02 (COMPATIBLE).
TYPENDM 36.046 Support for NDM-CDI Version 5.2, corrects NDMCPU plus
TYPERHEL 36.043 Initial support for NMON Red Hat Linux RHEL monitor.
TYPE82 36.036 Support for new SMF 82 subtype 82 JOB-Level Crypto.
ERROR Correction:
ASUM70PR 36.041 MXGERROR:MISSING TYPE70 now MXGWARN:MISSING TYPE70.
TYPE119 36.038 "INVALID SMF 119 TYPE 81" corrected, not invalid.
TYPEDB2 36.037 Var QWHSACE missing from DB2STSBP sort, ABEND
ANALCAPD 36.042 ERROR: FOUND "IF" when the CEC= option was used.
TYPE7072 36.035 Incorrect LPAR/ZIP SHAR/SHAC if last engine was IFL.
Enhancements:
MOBWORK 36.045 Enhanced Mobile Work 4 Hour MSU reporting datasets.
TYPEIMS 36.044 Variable IMSVERS, the value in your _IMSVERS is kept.
TYPE70PR 36.039 TYPE70PR variable LPARZIPS, online zips, added.
==Major CHANGES added in MXG 36.01, dated Feb 6, 2018 thru 36.026.
New Products Support
TYPE120 36.022 Support for Liberty 8.9.1.0 SMF 120 ST 100 (COMPAT).
TYPEVMXA 36.025 Support for zVM64 Level 40061701/1702 (INCOMPATIBLE).
36.01 is required for these levels, Broken CR errors.
TYPETPMX 36.024 Support for ThruPutManager Release 18.02 TMT7113.
TYPE70TR 36.003 New 70 Tenant Resource Group TRG updated/validated
TYPE72TR 36.003 New 72 Tenant Resource Group TRG updated/validated
TYPE89 36.003 New 89 Tenant Resource Group TRG updated/validated
UTILBPV 36.007 Program to examine the BPV cylinder value for EAV.
TYPE110 36.008 CICS/TS 5.3 CPU variables in Statistics CICM dataset.
TYPEPOEX 36.002 PowerExchange updated, trashed CPU values, open prob.
ERROR Correction:
TYPE42 36.023 Yet another STOPOVER ABEND, due to Invalid LENSR=232.
TYPE0 36.009 INVALID TYPE 0 LENGTH=70 is valid, wrongly deleted.
ASUM70PR 36.026 MXGERROR: MISSING TYPE 70 RECORDS impact ASUMCEC/LP.
TYPE30 36.012 The created GMTOFF30 could be .01 seconds plus/minus.
PDBAUDIT 36.011 %PDBAUDIT(LIBNAMES="Not All" fails with syntax error.
TYPE73 35.010 TYPE73 dataset, variable CHFXRATE slightly wrong.
TYPE119 36.008 Variable TTAPLDAT in dataset TYP11902 misaligned.
TYPE119 36.018 STOPOVER ABEND: SMF 119 Subtype 81, at IBM now.
TYPE115 36.005 QWHSDURN different in subtype 231, new vars, cleanup.
TYPEDB2 36.004 DB2 V11 IFCID 376 INPUT STATEMENT EXCEEDED. V11 only.
TYPETCP 36.001 TYPETCP (archaic 118) APISTART date was on GMT.
TYPEBETA 36.015 ERROR when TYPEBETA and TYPE70 used together.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M5 (9.4M5), "M5",
or "SAS 9.4 (TS04.01M5P09132017)" if the OPTION VERSIONLONG is
enabled.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36+ because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
described in SAS Note 61672. But SAS apparently does not plan for
a defect correction since the MXG Circumvention solves for MXG and
the text of 61672 simply describes the circumvention needed because
MXG's use of OPTIONS OBS=0 without NOERRORSTOP exposed the defect.
See Change 35.309 for more details on using NOERRORSTOP for your
own PROC SQLs.
SAS V9.4 M5 is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M2 or M4-M5 or SAS Version 9.3 M0-M2.
SAS V9.4 M5 is REQUIRED with z/OS 2.3 with Eight-Byte USERIDs
for Interactive TSO (DMS) SAS Sessions. SAS Note 61339.
SAS V9.4 M3 is NOT RECOMMENDED. See Change 36.129 SAS Note 61906
that reports 40% Increase in CPU time with M3.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 36.11 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows TEN and
Linux on 64-bit hardware, but MXG users execute MXG on MANY
(ALL??) SAS platforms, including AIX, Linux, and other 'nix'
variants, on many different hardware platforms, and since they all
work we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
THE Z14 CHANGED ONLY THE SMF 113 RECORD INCOMPATIBLY and that
was supported in MXG 35.11, but ASUM113 variable LPARBUSY was
missing until corrected in MXG 36.07. The new SMF70MAXPU variable
was added in MXG 36.04.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
However, for the z13 processor on z/OS, the new SMT-MODE RMF 70 was
INCOMPATIBLY CHANGED, and MXG 34.03 is REQUIRED (PCTCPUBY WRONG!), to
read the SMT-format RMF records (which are written if you have zIIP
engines AND have enabled the new PROCVIEW CORE option for
Multi-Threading, even if only one thread is enabled).
The new zEDC compression hardware requires MXG 33.07 to support the
new metrics.
For z/VM, MXG REQUIRES MXG 33.02 to support the z/13 changes.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 INCOMPAT, ABEND Oct 2, 2017 35.11
z14 113 LPARBUSY missing value Aug 8, 2018 36.07
z14 ZR1 New SMF70MAXPU variable May 8, 2018 36.04
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS-TS/5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS-TS/5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS-TS/5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS-TS/5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS-TS/5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS-TS/5.3 GA date Dec 11, 2015 33.33
CICS-TS/5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS-TS/5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS-TS/5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS-TS/5.4 GA Jun 17, 2017 35.03
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 35.07
IMS log 15.1 NO CHANGES Mar 1, 2018 35.07
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 was 16.04 but ABEND, ACSMFREL=0 May 2018 36.05
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
IMF 5.3 a/k/a Mainview IMS 35.03
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 36.11.
1. Incompatibilities introduced in MXG 36.36:
a- Changes in MXG architecture made between 36.36 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 36.36 after MXG 35.36:
Dataset/
Member Change Description
ANAL89 36.165 Analysis of SMF 89 data, including MSU from CPU time.
ANAL9914 36.171 Support for z/14 Clusters in IBM Processor Topology.
ANAL9914 36.232 SMF99 ST 14 Processor Topology Report Enhanced.
ANALCAPD 36.042 ERROR: FOUND "IF" when the CEC= option was used.
ANALID 36.081 Support for four-digit SMF Record type reporting.
ANALRMFR 36.203 CPU report with INTERVAL=HOUR was incorrect.
ASCIIDSN 36.020 ASCII version of JCLDAYDS with SAS FTP for TMC/DCOL.
ASMRMFV 36.110 SOC7 ABEND reading non-Extended Format VSAM dataset.
ASUM113 36.133 Variable LPARBUSY was not calculated for z14.
ASUM70PR 36.026 MXGERROR: MISSING TYPE 70 RECORDS impact ASUMCEC/LP.
ASUM70PR 36.041 MXGERROR:MISSING TYPE70 now MXGWARN:MISSING TYPE70.
ASUMCICR 36.226 Major revision to CICS RESPONSE TIME SLA reports.
ASUMCICR 36.226 Major revision to CICS RESPONSE TIME SLA reports.
ASUMUOW 36.107 Using ROLLUPS is useless with ASUMUOW, suppress DB2.
BLDSMPDB 36.242 Protection for AUTOALOC=YES and FIRSTRUN=YES
CONFIG 36.067 MXG default CAPSOUT option for z/OS now NOCAPSOUT.
CONFIG 36.078 OPTION SORTBLKREC corrects DFSORT OC4 in SAS 9.4 M3.
DOCUMENT 36.013 APAR OA27291 OC4 USEZOSV1R9RULE(NO) z/OS 1.10+
DOCVLONG 36.247 Utility to create DOCVER with all info on one line.
GRAFMSU 36.204 Plots/Tabulate of MSU 4HR usage and capacity.
GRAFWLM 36.153 New HIGHTOLOW parm to reverse IMPORTANCE order.
JCLCPORT 36.111 Sample JCL to move WPS datasets to SAS.
MOBWORK 36.045 Enhanced Mobile Work 4 Hour MSU reporting datasets.
MXGNOTE 36.141 zHPF Channel Utilization
PDBAUDIT 36.011 %PDBAUDIT(LIBNAMES="Not All" fails with syntax error.
READDB2 36.092 ACCTSORT=NO was not working, data ended up in WORK.
READDB2 36.121 READDB2(IFCIDS=ALL) did not create DB2STATS dataset.
READDB2 36.140 New SORT102=NO option can suppress T102Snnn sorts.
READDB2 36.172 IFCIDS=0-999 failed, only 367 are defined, now warns.
RMFINTRV 36.136 MXGABNDRMFI option will ABEND if OTHER Work found.
RMFINTRV 36.166 CRITICAL ERROR: PDB.TYPE70 MAY BE WRONG WITH 33 ENGS
SASNOTE 36.129 SAS Not 61906 SAS 9.4 TS1M3 High CPU fixed in M4/M5.
TECHNOTE 36.209 APARs of interest for z/OS.
TYPE0 36.009 INVALID TYPE 0 LENGTH=70 is valid, wrongly deleted.
TYPE101 36.101 Support for NDM-CDI OP record.
TYPE102 36.102 Support for DB2 V11 APARS PI71903/PI84045/PI82755.
TYPE102 36.138 Dataset T102S018 was misaligned.
TYPE102 36.212 Protection for IFCID 376 invalid offsets STOPOVER.
TYPE102 36.251 Support to populate T102S126 for DB2 102 IFCID 126.
TYPE106 36.152 New SMF 106 variables decoded and formatted.
TYPE110 36.008 CICS/TS 5.3 CPU variables in Statistics CICM dataset.
TYPE110 36.077 CICDS Dispatcher Statistics DSGTWT corrected.
TYPE110 36.220 Variable WTOTIOTM could exceed ELAPSTM
TYPE110 36.235 Support for IBM CICS/TS 5.5 SMF 110 CICSTRAN INCOMPAT
TYPE110 36.244 CICS Variable D2GDB2ID added to CICDB2GL BY list.
TYPE115 36.005 QWHSDURN different in subtype 231, new vars, cleanup.
TYPE119 36.008 Variable TTAPLDAT in dataset TYP11902 misaligned.
TYPE119 36.018 STOPOVER ABEND: SMF 119 Subtype 81, at IBM now.
TYPE119 36.038 "INVALID SMF 119 TYPE 81" corrected, not invalid.
TYPE119 36.079 Support for SMF 119 subtypes 24, 38, 39, 40, and 45.
TYPE119 36.127 Support for ZERT SMF type 119 Subtype 12
TYPE119 36.230 ZERT SMF 119 Subtypes 11 and 12 minor corrections.
TYPE119 36.250 New variables added to TYP11952 subtype 52 dataset.
TYPE120 36.022 Support for Liberty 8.9.1.0 SMF 120 ST 100 (COMPAT).
TYPE120 36.134 WebSphere SMF 120 subtypes 5/6 only first was output.
TYPE122A 36.066 Support for IBM Devel z Systems IDZ SMF 122 record.
TYPE122A 36.207 Support for zExplorer SMF 122 Subtype 2.
TYPE21 36.218 Support for APARs OA52915 and OA52940, 4 byte counter
TYPE30 36.012 The created GMTOFF30 could be .01 seconds plus/minus.
TYPE30 36.150 Support for APAR OA54589, OSPROTECT, TRUSTED.
TYPE30 36.175 Support for SMF 30 User Key CSA RAXFLAGS OA53355.
TYPE42 36.023 Another invalid LENSR=232, STOPOVER ABEND OA54668.
TYPE42 36.106 TYPE42DS Encryption variables were not kept.
TYPE42 36.124 SMF 42 ABEND, more invalid values protected.
TYPE42 36.151 New variables from Jul 30, 2018 SMF Manual.
TYPE62 36.151 New variables from Jul 30, 2018 SMF Manual.
TYPE70 36.166 CRITICAL ERROR: PDB.TYPE70 MAY BE WRONG WITH 33 ENGS
TYPE7072 36.035 Incorrect LPAR/ZIP SHAR/SHAC if last engine was IFL.
TYPE7072 36.073 Support for z14 ZR1, new SMF70MAXPU variable COMPAT.
TYPE7072 36.208 Support for APAR OA56011 for TYPE70 OSPROTECT.
TYPE70PR 36.039 TYPE70PR variable LPARZIPS, online zips, added.
TYPE70TR 36.003 New 70 Tenant Resource Group TRG updated/validated
TYPE72GO 36.215 Variable MSUSOFT, Software MSU frequently missing.
TYPE72GO 36.253 MOBILE Service Units CPU Time not in CPUTM variable.
TYPE72TR 36.003 New 72 Tenant Resource Group TRG updated/validated
TYPE73 35.010 TYPE73 dataset, variable CHFXRATE slightly wrong.
TYPE74 36.211 TYPE749 variables added and corrected.
TYPE80A 36.108 Support for RACF TOKENs REQTCRE and ADMINCII'
TYPE82 36.036 Support for new SMF 82 subtype 82 JOB-Level Crypto.
TYPE89 36.003 New 89 Tenant Resource Group TRG updated/validated
TYPE99 36.072 New EWLM & SERV variables added to TYPE99_6 dataset.
TYPEACF2 36.075 ACF2 INVALID SMF RECORD, ACSMFREL=0, should be 6.2.
TYPEACF2 36.100 ACF2 6.2 Change 36.076 didn't correct STOPOVER.
TYPEBE97 36.217 Support for new BE97 subtype 6 and subtype 22 update
TYPEBETA 36.015 ERROR when TYPEBETA and TYPE70 used together.
TYPEBETA 36.074 Variables BETALOG reversed, subtype 51 doesn't match.
TYPEBETA 36.199 Beta 93 Subtype 51 and subtype 22 updates.
TYPEBETA 36.246 BETA 93 Version 6.2.0 updates subtypes 0/22/25/50/59
TYPEBVIR 36.120 Support for BVIR V412 History HSM Compression data.
TYPECIMS 36.162 Support for multiple IMS SYSTEMS, using JFCB DSNAME.
TYPECIMS 36.163 IMS56FA obs for CPI-C had incorrect INPQUETM.
TYPECIMS 36.167 Support for BMC Energizer for IMS Connect for IMF.
TYPECMFV 36.173 Support for Mainview MVS History Records new datasets
TYPEDB2 36.004 DB2 V11 IFCID 376 INPUT STATEMENT EXCEEDED. V11 only.
TYPEDB2 36.037 Var QWHSACE missing from DB2STSBP sort, ABEND
TYPEDB2 36.082 DB2 BPHITRAT corrected.
TYPEDB2 36.113 Incorrect test for QPAC_PIPE_WAIT/COUNT in DB2ACCTP.
TYPEDB2 36.114 DB2ACCTR dataset has been misaligned, NRQLAC GT 1.
TYPEDCOL 36.086 z/OS 2.3 DCOLLECT Encryption Variables added DCOLDSET
TYPEIAM 36.071 INPUT STATEMENT EXCEEDED IAM 9.2 Length Changed.
TYPEIMS 36.040 Support for unpopulated IMS 56FA with APAR UI50912.
TYPEIMS 36.044 Variable IMSVERS, the value in your _IMSVERS is kept.
TYPEIMS 36.238 MXG 36.11 protection for IMS 14.1 IMS56FA offset.
TYPEMGCR 36.240 Support for MegaCryption MEGACR34, subtype 3 and 4.
TYPEMVCI 36.234 Support for BMC's MainView for CICS(v69) COMPATIBLE.
TYPENDM 36.046 Support for NDM-CDI Version 5.2, corrects NDMCPU plus
TYPENMON 36.109 Significant CPU reduction processing NMON data.
TYPEPOEX 36.002 PowerExchange updated, trashed CPU values, open prob.
TYPEPOEX 36.135 Support for PowerExchange Version 10.
TYPEPOEX 36.231 Protection for truncated POEX File Segment records.
TYPERHEL 36.043 Initial support for NMON Red Hat Linux RHEL monitor.
TYPERHEL 36.109 Significant CPU reduction processing RHEL data.
TYPERHEL 36.137 Invalid data for variable MICROCODE.
TYPERMFV 36.201 MXG 36.09, z/OS 2.2 only, ASIxxx text misaligned.
TYPERMFV 36.201 WPS failed ERROR: format '$ CPUPHYAD' invalid
TYPERMFV 36.241 CPC_CECNAME added, ASITRT/TET corrected, MSU ACT.
TYPERSDA 36.143 Support for RSD Folders Version 6.0 AUDIT (INCOMPAT).
TYPESMF 36.131 MXGREADSMF=LOGGER didn't invoke CICSIFUE exit.
TYPESRDF 36.112 Support for SRDF Symmetric Remote Data Facility VV.RR
TYPESTC 36.084 Dataset STCVSM11 Change 34.237 variables corrected.
TYPESTC 36.222 Numerous STC formats were updated with new values.
TYPESYSX 36.105 TYPESYSL renamed to TYPESYSX to avoid conflict.
TYPETAND 36.118 Support for Tandem TMF Transaction DATA, TANDTMF.
TYPETCP 36.001 TYPETCP (archaic 118) APISTART date was on GMT.
TYPETMO2 36.236 Support for ASG-TMON CICS for z/OS V4.2 - NO CHANGES.
TYPETPMX 36.024 Support for ThruPutManager Release 18.02 TMT7113.
TYPEVMXA 36.025 Support for zVM64 Level 40061702 (INCOMPATIBLE).
TYPEVMXA 36.155 Support for z/VM LINUX LNXAPPL Process & Summary data
TYPEVMXA 36.198 z/VM VXBYUSR High CPU, records not on same second.
TYPEVMXA 36.221 MONWRITE DEFECT caused large values, LCUPPNUM issue.
TYPEVMXA 36.237 z/VM 6.3 PROBABLE DATA LOSS ABEND MTRSYS 1.04
TYPEWSF 36.132 Support for EOS Version 160 (INCOMPATIBLE).
TYPEXCOM 36.047 Support for XCOM Version 36.02 (COMPATIBLE).
TYPEZCOS 36.174 Support for AutoSoftCapping ZCOS Version 4.2 INCOMPAT
UTILBLDP 36.139 AUDITAFTER, SUPPRESS=ID, SORTOUT=NO revisions.
UTILBLDP 36.176 MXG 36.08, Extraneous % with EXPDBOUT= 180 ABEND.
UTILBPV 36.007 Program to examine the BPV cylinder value for EAV.
UTILEXCL 36.220 Variable WTOTIOTM could exceed ELAPSTM.
UTILEXCL 36.235 Support for IBM CICS/TS 5.5 SMF 110 CICSTRAN INCOMPAT
VMXGALOC 36.243 Protection for READONLY=YES with FIRSTRUN=NO
VMXGSUM 36.245 VMXGSUM with user's INCODE GT 32756 chars, ABEND.
VMXGSUM 36.249 OBS=0 protection adds non-zero SYSCC Error test.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at http://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE
====== CHANGES THRU 36.255 WERE IN MXG 36.36 DATED Jan 4, 2019=========
Change 36.255 T102S083 was incorrectly input to the report twice. One
ANALDB2R report line with the correct AUTH CHG type was printed,
Jan 4, 2019 a report line with type that is blank in PMAUD02 report.
Thanks to Henry Boone, GEICO, USA.
Change 36.254 Support for Fast Traversal Index adds these variables to
VMACDB2 DB2STATS dataset:
Jan 4, 2019 QISTTRAVMIN='FTB*THRESHOLD'
QISTFTBCANT='INDEXES*THAT*MEET*FTP CRITERIA'
QISTFTBCAN='INDEXES*THAT*MEET*TRAVERSE OK'
QISTFTBSIZE='TOTAL*MEMORY*ALLOCATION'
QISTINBNUMP='INDEXES*FTB*EXIST*PREVIOUS'
QISTINBNUMC='INDEXES*FTP*EXIST*CURRENT'
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 36.253 MOBILE Service Units on CP (GP) and SP (zIIP) engines are
VMAC7072 in TYPE72GO and TYPE72TR datasets, in variables R723MSUCP
Jan 3, 2019 and R723MSUSP, but their CPU times were not created, and
May 28, 2019 the GP CPU time is NOT included in CPUTM. New variables
CPUMOBILECP and CPUMOBILESP are created, but the CP CPU
time is still not added into CPUTM at this time. Instead
CPUTM_ALL=SUM(CPUTM,CPUMOBILCP) is created so the values
can be examined and validated; if you have MOBILE work,
please contact support@mxg.com to discuss how this new
new data can be best presented.
May 28: See Change 37.120; CPUTM_ALL=CPUTM, text wrong.
Thanks to Kare Martin Torsvik, EVRY,
Change 36.252 -Cosmetic cleanup of blank variable labels and spellings:
Many VMACNDM: NDMOPSEQ
Jan 3, 2019 VMAC119: DM_LSVLANID,UC_LTEDATE GMTOFFTM
VMAC74 and VMAC79: DEVNR5HEX
VMAC78: IOPDSTX
VMAC89: SMF89NUM was changed to SMF89_NUM
VMACWSF: ACCSTAT, AUDOBJRN
VMACBETA: BETASSI
Thanks to Chris Weston, SAS ITRM, USA.
Change 36.251 Support for DB2 102 IFCID 126, but all fields are (S) for
VMAC102 "serviceability" with no descriptions, and a 4095 byte
Jan 3, 2019 field that is mixed binary and character, but no info.
The R1O is 41 and R1L is 4096 so 4137 bytes are described
and read, but records have 4448 bytes, 311 undocumented.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 36.250 New variables added to TYP11952 Subtype 52 dataset:
VMAC119 SMF119ML_IP_CONCOUNT=CONNECTION*COUNT'
Jan 3, 2019 SMF119ML_IP_CONFAILCOUNT=CONNECTION*FAILURE*COUNT'
SMF119ML_IP_RCVDBYTES='RECEIVED*BYTES'
SMF119ML_IP_SENTBYTES='SENT*BYTES'
SMF119ML_IP_ESMTP='ESMTP*SUPPORTED?'
Thanks to Randy Shumate, RELX Group, USA
Change 36.249 OBS=0 protection adds test of non-zero SYSCC Error code
VMXGSUM to confirms a prior SAS error had set OBS=0, which can
Jan 1, 2019 cause VMXGSUM to fail, depending on the arguments used,
so VMXGSUM can be gracefully stopped with MXGERRORs that
no dataset was output and to look on the log for ERROR
and correct it.
Change 36.248 CICS variables TASELGTM CPUTONTM CPUTONCN are added to
ASUMCICS the PDB.ASUMUOW dataset from CICSTRAN, and CICS variables
ASUMCICX TASELGTM TASZIPTM CPUTONTM CPUTONCN OFFLCPTM OFFLCPCN are
VMXGUOW added to PDB.CICS created from PDB.ASUMUOW by ASUMCICX,
Dec 31, 2018 or created from CICSTRAN.CICSTRAN by ASUMCICS, but read
the comments in ASUMCICS that suggest ASUMCICX is better.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.247 A utility program to create a copy of the DOCVER file
DOCVLONG with all info on a single line for each MXG variable. MXG
Dec 27, 2018 variable names can be the 32 character max SAS allows, so
DOCVER descriptions are split if the name is 9 or more.
This program creates 94-byte records for each variable.
Thanks to MP Welch, Bank of America, USA.
====== CHANGES THRU 36.246 ARE IN MXG 36.12 DATED Dec 25, 2018==========
Change 36.246 BETA 93 Version 6.2.0 updates for subtype 0/22/25/50/59.
VMACBETA Versions 4.x.x and earlier may not be supported, contact
Dec 21, 2018 MXG Support if you are still at that BETA93 level.
Contact Support if you have other 6.2.0 subtypes so they
can be validated and supported.
Thanks to Robert Gilbert, BNP Paribas Fortis, FRANCE.
Change 36.245 MXG 36.05-36.11, VMXGSUM fails if user option INCODE text
VMXGSUM exceeds 32756. Change 36.109 added detection of "BY" in
Dec 19, 2018 your VMXGSUM INCODE= argument, but 32K is the limit that
is permitted by the %INDEX function. Now, INCODE string
is compressed of blanks to mitigate that length issue and
the test for BY is only executed if resultant length is
LT 32755. MXGWARN messages are written to the log at 30K
length, suggesting the use of INCODE1= option if needed.
Note that the counts of INCODE length can be different
between z/OS and ASCII.
Thanks to Bill Davis, TransAmerica, USA.
Change 36.244 CICS Variable D2GDB2ID is added to the BY List for the
VMAC110 NODUP PROC SORT of dataset CICDB2GL, which may be needed
Dec 17, 2018 for NODUP protection.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.243 If you specified READONLY=YES (which suppresses the aging
VMXGALOC of old directories) and a directory did not exist, it was
Dec 15, 2018 created but not populated. This could cause dataset not
found errors but suppressing that creation could cause
LIBNAME statements to fail. Now, VMXGALOC detects all of
these conditions and only allocates the LIBNAMES that are
found and does not create new ones with READONLY=YES and
FIRSTRUN=NO.
Change 36.242 Using BLDSMPDB with AUTOALOC=YES does two things. First,
BLDSMPDB it allocates all of the directories needed to satisfy the
Dec 15, 2018 parameters you specified - 5 weeks, 1 month, 7 days, etc.
Then at the end of the daily processing it makes a 0 OBS
copy of all of the datasets contained in the PDB. But if
you ran (incorrectly) with FIRSTRUN=YES a second time,
all of those datasets were set to 0 OBS by this process
(intended to prevent DATASET NOT FOUND errors when
running a weekly or a monthly process). Now, with
FIRSTRUN=YES, it first looks to see if there are any
datasets in the libref and if there are any datasets
present, it's assumed you did not really mean it, it
prints a warning message, and bypasses the 0 OBS copy.
Change 36.241 -Variables CPC_CECNAME GEIIMDL GEIMODEL kept in several
ADOCRMFV more ZRBxxx datasets where they are likely to be useful.
ASMRMFV -The original MXG01 record written at CLOSE is now split
EXZRBAS2 into an MXG01 written at VSAM OPEN, so the CPC_CECNAME
IMACRMFV could be captured for all RMF III datasets (it's kept
VMACRMFV kept where it makes sense). and an MXG02 record written
Dec 18, 2018 at CLOSE with those statistics.
Dec 23, 2018 -Datasets ZRBAS1 and new ZRBAS2 decode the MXG01 and MXG02
records.
-ZRBASI variables ASITRT/ASITET are 1024 microsecond units
but weren't multiplied by 1024. ASIDCTIA_S is 128 usec
but wasn't multiplied by 128.
-New ASIPHTCP='ENCLAVE*ON*GP*TIME=ASIPHTMA-ASIPHTZI is
created to complete the CPU Schematic in ZRBASI:
<------------GP------------><----ZIIP---->
<--ASICPUTA--><--ASIPHTCP--><--ASIPHTZI-->
0.083 0.048 37.692
0.131
ASIPHTMA=37.740 ASITRT/ASITET=29.696
-In dataset ZRBLCPLPAR, the CPC Capacity report, the value
under MSU ACT is the variable ZRBLCPCPUMSUHR, but that is
the interval MSU extended to an hour by MSU*3600/DURATM
so it is NOT the 4HR MSU value.
-Incremental improvements and some fixes.
-Positioning for a future new filtering feature.
-FROMTIME= and TOTIME= now support optional seconds for
time values in ASMRMFV. The time format used depends on
the number of digits coded as follows:
# Digits Time Result
-------- ----------------------------
0 RMFV057I NULL VALUE message
1 000M00
2 00MM00
3 0HMM00
4 HHMM00
5 0HMMSS
6 HHMMSS
> 6 RMFV004E ERROR message
Example Full Equivalent Time
--------------- --------------- --------
FROMTIME=1 FROMTIME=000100 00:01:00
FROMTIME=12 FROMTIME=001200 00:12:00
FROMTIME=123 FROMTIME=012300 01:23:00
FROMTIME=1234 FROMTIME=123400 12:34:00
FROMTIME=12345 FROMTIME=012345 01:23:45
FROMTIME=123456 FROMTIME=123456 12:34:56
-Seconds are NOT supported in Relative Time values such as
FROMTIME=*-nnS because this time offset unit from the
current time is too small to be of practical use when
building a PDB. The minimum Relative Time is 1 minute.
-Origin message RMFV009I for each RMF III data set
processed will now include the CPCNAME (aka CECNAME) for
z/OS Release 3.3 and up. If the LPAR is running under
z/VM then the CPCNAME will display as VMGUEST. For lower
z/OS releases the CPCNAME shows as N/A as RMF III does
not track this information at lower levels.
-New information only message RMFV057I KEYWORD VALUE IS
NULL issued when an ASMRMFV keyword has no value
assigned. For example, FROMDATE= . Before this change
the keyword would be ignored with no user notice.
-Warning message RMFV085W is now issued when a filter or
or parameter requires a specific RMF III table, but the
table has not been selected.
Avoid this message by specifying all desired RMF III
tables first before any other parameters that need them.
For example, ASIJOBNAME=MYJOB11 requires the ASI table.
-Improved display format when a single character error is
detected showing both EBCDIC and hexadecimal values for
the character.
-Initialization message RMFV001I now shows the size in
bytes of the step level program used to invoke ASMRMFV
(usually ASMRMFV itself).
-New message RMFV091I is issued when the IBM modules
ERBR3DEC (RMF III Decompression) or IGGCSI00 (Catalog
Search Interface) are loaded into the user region.
Warning message RMFV091W is issued if the module cannot
be identified as an IBM module. In this case this could
be a duplicate naming problem with a third party product.
-MXG table MXG01 has been split into two tables for each
RMF III data set processed. MXG01 contains VSAM data set
Open statistics and MXG02 contains VSAM data set Close
Statistics. These both appear in the ASMRMFV log in
Detail and Summary reports.
-Former message RMFV075W is now message RMFV090W.
RMFV075* is now used for table id mismatch errors.
ASMRMFV errors corrected:
-Error message RMFV005E could be incorrect when more than
one ASMRMFV parameter appeared in one SYSIN record.
-Messages RMFV012I and RMFV013I could show incorrect GMT
offset values for the last sample range and last selected
times.
-Space message RMFV031I always showed an EF (Extended
Function) VSAM type even for non-EF VSAM data sets.
-Message RMFV035* showed an incorrect reason in ASMRMFV
Summary report when an SPG table Internal Error was
detected.
-Except for the DSIG3 table any RMF III table id mismatch
errors now result in an Abend U0998 Reason Code 2. A
table id mismatch is a serious non-recoverable data
error. A DSIG3 error can be recovered by processing the
next RMF III data set but is still very undesirable.
-Each ASMRMFV parameter now has a PLACEMENT section in
documentation to explain where in the input stream it
should appear.
-Numerous documentation updates in:
Section 4 "RMF III Table Selection Parameters"
Section 5 "Input Data Selection Parameters"
Section 6 "Report Control Parameters"
Section 7 "Output Data Control Parameters"
Section 8 "Error Handling Parameters"
Section 12 "Messages"
Section 26 "ASMRMFV and MXG PDB Data Relationships"
Change 36.240 Support for MegaCryption new MEGACR34 dataset with new
EXMGCR34 subtype 3 and 4 replacing old records but keeping all of
IMACMGCR the original fields and adding these new variables:
VMACMGCR MGCRFUNC='FUNCTION*E ENCRYPT*D DECRYPT ?'
VMXGINIT MGCRALGO='ALGORITHM*USED'
Dec 8, 2018 MGCDSSUF='ADRDSSU*DUMP*RESTORE*COPYDUMP'
MGCRDSN1='INPUT*DSN'
MGCRVOL1='INPUT*VOLSER'
MGCRSTY1='INPUT*FILE*TYPE'
MGCRDSN2='OUTPUT*DSN'
MGCRVOL2='OUTPUT*VOLSER'
MGCRSTY2='OUTPUT*FILE*TYPE'
Thanks to Jennifer D. Ayers, West Virginia State Goverment, USA.
Change 36.239 Enhanced to display all used parameters, only on the
VMXG2DTE first execution in a SAS session. On subsequent execute
Dec 7, 2018 DDIN DDOUT PDB DATASET and INITIT are displayed only if
Dec 23, 2018 they are different and others only if present.
Thanks to Tom MacCabe, Dominion Energy, USA
Change 36.238 IMS 14.1 IMS56FA INPUT EXCEEDED RECORD ABEND due to an
VMACIMS invalid offset value of 2500 in DLRRXTOF/TPCEXTOF in a
Dec 7, 2018 record that has only 572 bytes. Previous 14.1 56FA data
Dec 23, 2018 didn't populate that offset to that new TPCX segment, but
the 64-byte segment was present but not input. Since the
segment contains nothing of value, rather than protecting
for an invalid offset, the code for the TPCX segment is
bypassed awaiting data from a site that wants the TPCX
data. This is not worth a PMR at this time.
-You can use this logic in your IMS job's SYSIN safely
since this segment is at the end of the IMS LOG record:
//SYSIN DD *
MACRO STOPOVER MISSOVER %
%INCLUDE SOURCLIB(TYPSIMST);
but you should remove that MACRO statement when you
update MXG.
-New message if 56FA record IMSVERSN value is not equal to
your site's _IMSVERS old-style macro value that you set
in the job's SYSIN - see TYPEIMST/TYPSIMST JCL examples.
But _IMSVERS is NOT USED in the 56FA records; it is used
only in old IMS log records hex 07 08 0A 31 35 36 40 59.
Dec 23, 2018: Variable TPCXLEN re-kept in IMS56FA always
a missing value until IBM populates the segment.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.237 z/VM 6.3 MONWRITE record ABEND at HCPCPEID='30061701:
VMACVMXA PROBABLE DATA LOSS MESSAGE exposed incorrect new SKIP
Dec 6, 2018 logic for 6.4 that failed with 6.3 in MTRSYS, 1.04..
SKIP logic revised to protect old versions.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
====== CHANGES THRU 36.236 ARE IN MXG 36.11 DATED Dec 3, 2018==========
Change 36.236 Support for ASG-TMON CICS for z/OS V4.2, is there now, as
TYPETMO2 there were no changes to the performance records.
Nov 28, 2018
Change 36.235 Support for IBM CICS SMF 110 CICS/TS 5.5 INCOMPATIBLE,
VMAC110 as is ALWAYS the case for CICS because they insert
UTILEXCL fields in existing records. You can use the VMAC110
Nov 30, 2018 with this Change (36.235), if you have records, with no
excluded fields and no optional segments, but if you
have either (the existence of a tailored IMACEXCL member
in your "USERID.SOURCLIB" tailoring proves you do), you
will need to use UTILEXCL from this Change to create a
new IMACEXCL that knows about these new variables that
were INSERTED in Subtype 1 records:
NJSAPPNM='NODE.NJS.APPPLICATION*NAME'
SOCONMSG='FIRST*MESSAGE*PROCESSED'
WBURIOTM='URI*WEBB OPEN*WAIT*TIME'
WBURIOCN='URI*WEBB OPEN*WAIT*COUNT'
WBURIRTM='URI*WEBB RECV*WAIT*TIME'
WBURIRCN='URI*WEBB RECV*WAIT*COUNT'
WBURISTM='URI*WEBB SEND*WAIT*TIME'
WBIRISCN='URI*WEBB SEND*WAIT*COUNT'
WBURVITM='URI*INVOKE*SERVICE*WAIT*TIME'
WBURVICN='URI*IINVOKE*SERVICE*WAIT*COUNT'
Yes, you need MXG 36.11 for CICS/TS 5.5 because fields were
inserted into SMF 110 CICSTRAN records and using old MXG will
have trashed values due to the misalignment, but MXG could run
and only print error messages, which might be false positives,
or could execute with no errors nor log messages, especially if
you have a tailored IMACEXCL, but your CICSTRAN dataset will
still be invalid.
Change 36.234 Support for BMC's MainView for CICS(v69) with support for
VMACMVCI CICS/TS 5.5 COMPATIBLY added these variables to DMRDETL:
Nov 30, 2018 T6E72XCT='72 EXTENSIONS'
T6ESOCNM='FIRST*MSG*PROCESSED'
T6EUROPT='URI*WEB OPEN*WAIT TIME'
T6EUROPF='URI*WEB OPEN*WAIT FLAG'
T6EUROPC='URI*WEB OPEN*WAIT COUNT'
T6EURRPT='URI*WEB RECV*WAIT TIME'
T6EURRPF='URI*WEB RECV*WAIT FLAG'
T6EURRPC='URI*WEB RECV*WAIT COUNT'
T6EURSPT='URI*WEB SEND*WAIT TIME'
T6EURSPF='URI*WEB SEND*WAIT FLAG'
T6EURSPC='URI*WEB SEND*WAIT COUNT'
T6EWSIVT='URI*INVOKE*SERVICE**WAIT TIME'
T6EWSIVF='URI*INVOKE*SERVICE**WAIT FLAG'
T6EWSIVC='URI*INVOKE*SERVICE**WAIT COUNT'
T6ENJAPN='NODE.JS*APPLICATION*NAME'
Change 36.233 Change 36.211 changed the KB definition to 1000 based on
VMAC74 an IBM document that is now confirmed as misleading and
Nov 27, 2018 the multiplier of 1024 is restored for these variables:
R7491BPC R7491BPS R749DCTBYTR R749FPGBYTR
R749FPGBYTS R749FPGCOBS R749FPGDCBS R749ICTBYTR
R749PCIBYTR R749PCIBYTT R749PCIDMAR R749PCIDMAW
-APAR OA55984 corrects high zEDC execution time and SSQ
values when a time stamp wrapped.
Change 36.232 The SMF 99 Subtype 14 Processor Topology Report provided
ANAL9914 by RAY back in Change 33.139 has a new version by Jim
Nov 29, 2018 and the report program is now a %MACRO ANAL9914 so you
can select CECTYPE and SYSTEM and REPORT with
%ANAL9914(CECTYPE=Z14,SYSTEM=SYS1 SYS2,REPORT=JIM);
REPORT=JIM uses PROC SGPANEL (SAS only) for prettiness!
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Raymond J. Smith, OPTUM, USA.
Change 36.231 Truncated POEX record caused INPUT STATEMENT EXCEEDED now
VMACPOEX the short record is detected and reported on the log. the
Nov 26, 2018 record had POEXNUM=35 File Segments expected, but the
record only had room for 15.
Thanks to Jack Hyde, UHC, USA.
Change 36.230 -SMF 119 ZERT subtype 12 dataset TYP11912IPOSEC was out of
VMAC119 alignment for these last 4 variables: ENCAPMODE/AUTHPROTO
Nov 26, 2018 were incorrectly input as $CHAR2.
S119SS_IPS_ENCAPMODE S119SS_IPS_AUTHPROTO
S119SS_IPS_AUTHALG S119SS_IPS_ENCALG
-MXG ZERT subtype 11 dataset TYP11911's GMTOFFTM create is
valid with current records, but 2017 records had missing
values that caused incorrect values, because SAETIME was
often missing and on a different time zone.
Thanks to Luis Mendoza, Black Knight, USA
====== CHANGES THRU 36.229 ARE IN MXG 36.10 DATED Nov 21, 2018==========
Change 36.229 If you specified a dataset name in ASCII and did not
UTILBLDP change the value of ECHO= to NO, a syntax error was
Nov 21, 2018 generated when the created code was read back in to be
displayed. If you used a filename (preferred) there was
no error.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.228 The MXGWARN:MISSING TYPE70/TYPE70PR could be printed for
VMAC7072 ICF-only LPARs, because MXGCIN was set to 'VM' in very
VMXG70PR old logic, prior to SMF70CIN being provided by IBM.
Nov 29, 2018 Now, MXGCIN is always set to SMF70CIN in VMAC7072, and
the ICF LPARs with SMF70STN non-blank are skipped in
VMXG70PR.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.227 New IHDRCTLT "Header" Exit created for record selection,
IHDRCTLT and macro variable &MACCTTH created for instream use.
VMACCTLT Missing value messages for dates eliminated.
VMXGINIT
Nov 16, 2018
Thanks to Randal Schlueter, FirstData, USA.
Change 36.226 Major revision to CICS RESPONSE TIME SLA MEMBER.
ASUMCICR
Nov 20, 2018
Change 36.225 Documentation only. Examples clarified.
ANALCAPD
Nov 16, 2018
Change 36.224 Documentation only. Examples added to select specific
UTILBLDP subtypes of records to be added to PDB, Example 2 was.
Nov 16, 2018 missing quotes.
Change 36.223 -PMACC02 could generate an UNITIALIZED variable message
ANALDB2R for PACKTYPE.
Nov 19, 2018 -Variable QB3TDIO was misspelled in PMSTA02 causing
another unitialized message.
Change 36.222 Numerous STC formats were updated with new values for
FORMATS HSC 7.3. Calculation of MSZ with CTP test, and new
VMACSTC $MGSTCRR format added, so please update FORMATS.
Nov 21, 2018
Thanks to Randy Hewitt, HPE, USA.
Change 36.221 MONWRITE defect, LCUPPNUM was NOT changed and an interval
VMACVMXA was skipped when the number of IFL engines was changed
Nov 15, 2018 from 5 to 3. MXG's attempt to detect wrap was invoked
causing large values in LCUCACTM LCUCLPTM LCXCMTIT.
The logic was revised to detect and delete the defective
interval in VXSYTCUP. A PRM will be raised with IBM.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.220 -Variable WTOTIOTM could exceed ELAPSTM because WTWEIOTM,
UTILEXCL is included in RMISIOTM, and -SUM(WTDISPTM,WTSYIOTM);
VMAC110 are overlapped with the sum of all of the other waits.
Nov 20, 2018 -The WTOTIOTM created in UTILEXCL (when you have EXCLUDED
fields) did not include these wait variables:
DSAPTHTM DSCHMDTM DSMMSCTM DSTCBMTM FCVSWTTM
GNQDELTM ISALWTTM JVMSUSTM MAXJTDTM MAXOTDTM
MAXSTDTM MAXXTDTM PTPWAITM RQPWAITM RQRWAITM
RRMSWATM RUNTRWTM SRVSYWTM SYNCDLTM TCALWTTM
TDELWTTM TDILWTTM
but only one, DSCHMDTM, is populated.
-This is the new code for WTOTIOTM
WTOTIOTM=SUM(
DSPDIOTM,ENQDIOTM,GNQDELTM,WTICIOTM,WTLMIOTM,
WTWCIOTM,RUNTRWTM,SRVSYWTM,RQRWAITM,
RQPWAITM,SYNCDLTM,MAXOTDTM,MAXJTDTM,MAXSTDTM,
MAXXTDTM,RRMSWATM,PTPWAITM,RMISIOTM,JVMSUSTM,
DSTCBMTM,DSMMSCTM,WTDWIOTM,DSCHMDTM,FCVSWTTM,
ISALWTTM,TCALWTTM,TDELWTTM,TDILWTTM,DSAPTHTM);
IF (WTOTIOTM GT SUM(WTDISPTM,WTSYIOTM)) AND
(WTOTIOTM-SUM(WTDISPTM,WTSYIOTM)) GT 0 THEN
WTOTIOTM=WTOTIOTM-SUM(WTDISPTM,WTSYIOTM);
Thanks to Jim Franklin, DXC Technology, USA.
Change 36.219 Misspelling of miscellaneous corrected in 15 of 876 uses,
Many and many other spelling errors have been corrected.
Nov 13, 2018
Thanks to Michael R. Novak, USPS, USA.
Change 36.218 Support for APARs OA52915 and OA52950 for SMF 21 counts
VMAC21 to use the 4-byte 3590 counters instead of the original
Nov 13, 2018 3-byte 3490 counters is already in place since the 4-byte
counters were added. A minor non-impacting change to
the test that sets the 3-byte counters with FFFFFFx to a
missing value was made.
Change 36.218 Reserved Change Number.
Change 36.217 -Support for new subtype 6 BETA97 record, which creates
FORMATS two new datasets:
EXTYB976 DDDDDD Dataset Description
EXTYB97S TYB976 BETA9706 BETA97 ST 06
IMACBE97 TYB97S BETA9706D BETA97 ST 06 DATASET
VMACBE97 -Support for the Relocate data in subtype 22 BETA972REL
VMXGINIT now decodes the expiration date fields to SAS dates and
Nov 9, 2018 the B97RELTY values are decoded..
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 36.216 -ASMRMFV IDERR subroutine upgraded to display MINTIME
ASMRMFV interval when a RMF III table id mismatch occurs as
Nov 8, 2018 RMFV075E messages.
-Extraneous ')' in message RMFV008I when processing a GDG
for RMFBSAM.
-NOSHOWZERO option not showing any table detail lines
except for MXG00.
Thanks to Randall Schleuter, First Data Corporation
Change 36.215 Variable MSUSOFT, the interval Software MSU in TYPE72GO
VMAC7072 for each Service/Reporting Class, can often be a missing
Nov 7, 2018 value due to incorrect logic used to populate the
CECSUSYSTEM and CECSUVALUE arrays from the preceding type
70 to provide SMF70CPA for the MSU calculation. If there
is no preceding 70 from this system, "new" variable
R723CPA is used so MSUSOFT will always be populated. And,
if it is really the 4 Hour Average value you want, member
ASUM4HRS will create that value for any variable in any
dataset!
Thanks to Thomas Heitlinger, FIDUCIAGAD, GERMANY.
Change 36.214 If OPTIONS OBS=0 has been set by SAS due to an error,
VMXGSUM VMXGSUM produced unclear messages and zero obs created.
Nov 7, 2018 Now, OBS=0 is detected and VMXGSUM shut down with error
message that is clear.
Thanks to Glen Bowman, Wakefern, USA.
Change 36.213 Cosmetic. Non-impacting NOTE: _UN98309 UNINITIALIZED is
VMAC110 removed.
Nov 7, 2018
Change 36.212 Protect for DB2 Trace IFCID 376 invalid offset STOPOVER.
VMAC102 One record with two offsets (SC_OFF and SQL_OFF) that
Nov 6, 2018 were larger than the record LENGTH caused the error.
Offset lengths are now compared to LENGTH and if larger,
log messages are printed.
QW0376SC_OFF=48392 LENGTH=5210 IFCID376 SC ERROR
QW0376SQL_OFF=27283 LENGTH=5210 IFCID 376 SQL ERROR
These offsets, added in DB2 V11, are after VERSION but
Version Length is ZERO in all records, and the first
eight bytes of VERSION are nulls, so possibly the
offsets are in those first eight bytes, so I've added
variable VERSION1ST to display their value.
A PMR will be raised with IBM DB2 Support.
Thanks to Glen Bowman, Wakefern, USA.
Change 36.211 -These AVG and STD values were not created in TYPE749:
VMAC74 R7491DISAVG='AVG*INDIVIDUAL*DEFLATE*INPUT*BYTES'
Oct 31, 2018 R7491DISSTD='SSQ*INDIVIDUAL*DEFLATE*INPUT*BYTES''
Nov 3, 2018 R7491DOSAVG='AVG*INDIVIDUAL*DEFLATE*OUTPUT*BYTES'
Nov 28, 2018 R7491DOSSTD='SSQ*INDIVIDUAL*DEFLATE*OUTPUT*BYTES''
R7491IISAVG='AVG*INDIVIDUAL*INFLATE*INPUT*BYTES'
R7491IISSTD='SSQ*INDIVIDUAL*INFLATE*INPUT*BYTES''
R7491IOSAVG='AVG*INDIVIDUAL*INFLATE*INPUT*BYTES'
R7491IOSSTD='SSQ*INDIVIDUAL*INFLATE*INPUT*BYTES''
and these variables are now uncommented and kept
/* SSQ VARIABLES NOW COMMENTED OUT SINCE STD EXIST
R749FSQE R749FSQQ R7491DIS R7491DOS R7491IIS R7491IOS*/
This link https://www.ibm.com/support/knowledgecenter/en/
SSLTBW 2.1.0/com/ibm.zos.v2r1.erbb200/erbb200205.htm
with PCIE Function Activity overview calculations show
that the "MegaBytes" and "KiloBytes" are 1000 and not the
1024 per KiloByte that IBM uses in other 74 subtypes, so
the 1024s in subtype 9 code are changed to 1000.
-Nov 28: Change 36.233 reverted back to 1024 as IBM has
confirmed the KB are 1024 and not 1000.
-R749FPGBPRT is now the in-use buffer percent of memory.
-R749BPC is relabeled AVERAGE*IN-USE*BUFFER*SIZE in bytes.
-R749PCIUTIL was incorrectly calculated.
Thanks to Heimir Hauksson, Barclays, ENGLAND
Anthony T. Sofia, IBM, USA.
Change 36.210 The _N119 "Null Macro" missed TYP11924 and TYP11945 so
VMAC119 they were created when not wanted when _N119 was used.
Oct 31, 2018
Change 36.209 Documentation of APARs of interest for z/OS:
TECHNOTE -APAR OA55602 RMF PP WLMGL TOTAL STORAGE INVALID after
Oct 31, 2018 APAR OA52694; impacted only the TOTAL STORAGE and the
STORAGE SHARED in RMF Report, 1000 times too large.
-APAR OA53459 SMF TYPE 65 IS MISSING THE HLQ FOR THE
GENERATION DATA SET WHEN DELETE GDG FORCE PURGE IS
ISSUED on z/OS 2.2, not on 2.1. 2.3 not mentioned.
-OA52950 3490 CHANNEL (PRE-COMPRESSION) BYTES AND DEVICE
(POST-COMPRESSION) BYTES BEING REPORTED INCORRECTLY.in
RMM (MXG TYPEDGR) and SMF 21 statistics, too high.
-OA54992 SMSVSAM SMF TYPE 42 SUBTYPE 15 RECORDS MAY
INCORRECTLY RECORD ABOVE THE BAR BMF STATISTICS FOR DATA
SETS. Occurs with a data set is assigned to a dataclass
with above the bar usage set to yes, but the data set is
not actually using above the bar buffers, which happens
if RLSABOVETHEBARMAXPOOLSIZE is not set or if the change
was made and the data set hasn't gone through a CLOSE to
refresh the information. LOCAL FIX: Ensure data sets
assigned to data class with above the bar usage are
using above the bar buffers.
-APAR OA56000 SMF RECORD LENGTH FOR SMF TYPE 98 HFTS
RECORDS EXCEEDS THE MAX ALLOWABLE X'7FF4' (32,756).
Subtype 1 are defined as x'8000' (32,768) and these
records have caused CA SMF DIRECTOR product to fail and
reject these records as invalid.
-APAR PI96628 MQ V9: SMF116 RECORDS CONTAIN INVALID
VALUES IN FIELD WTASMSTC, time spent in IXLLSTM call,
and WTASSSTC for CICS and CHINIT connections accessing
shared queues.
-APAR PH99111 WMQ V9.0 SMF116 LATENCY RECORD FIELDS SET
TO ZERO FOR SOME QUEUES. Fields MAXLATNT MINLATNT and
TOTLATNT are zeroed after migrate to Version 9.0, for
some queues.
-APAR OA55594 SMF78 SUBTYPE 3 SUPERVPAV VALUES NOT
REPORTED DUE TO R783DST BIT 7 FLAG NOT BEING SET
R783XIND, causing I/O Queueing Activity Report to be
missing the Alias Management Groups and/or the Logical
Control Units section is missing the Alias Management
Group field. Happens when the first device on a
SuperPAV XPAV Control Units is offline. LOCAL FIX:
Vary the first device on all SuperPAV XPAV Control
Units online.
-APAR OA55292 RMF FICON DIRECTOR STATISTICS REPORT HAS AN
OCCASIONAL VERY LARGE VALUE FOR A PORT BANDWIDTH, READ
OR WRITE. APAR IS OPEN.
Change 36.208 Support for APAR OA56011 which added these two variables
VMAC7072 to the TYPE70 dataset:
Oct 31, 2018 SMF70LACCR='LONGTERM*MSU*DFSMS*DATASET*ENCRYPTION'
SMF70OS_PRTCT='OSPROTECT*VALUE'
Change 36.207 Support for SMF 122 Subtype 2 zExplorer IBM Dependency
EXTY122B Based Build, DBB, Release 1.0.3, which records usage of
IMAC122A the DBB toolkit by z/OS users, creates new dataset.
VMAC122A DDDDDD DATASET DESCRIPTION
VMXGINIT
Oct 30, 2018 TY122B TYPE122B ZEXPLORE DBB DEPEND BASED BUILD
Change 36.206 When the input DD is tape or sequential, VMXGSUM and
VMXGSUM VGETOBS cannot reasonably detect the presence or absence
Oct 28, 2018 of datasets and have always tried to process them but if
DSNFERR was on failed with a dataset not found error.
But, if DSNFERR was set to NODSNFERR it then tried to
process and if the dataset did not exist could generate
UNINITIALIZED variable messages and a 0 OBS output. Now
if VGETOBS detects a sequential LIBNAME and NODSNFERR
MXGNOTEs are produced to let you know what may happen.
Change 36.205 -IBM updated the RMF III SVP table and altered the Service
ASMRMFV Class, Report Class, and Resource Group Information
Oct 26, 2018 Sections.
-The SVP version level was raised from X'03' to X'04.
-Either or both version levels may exist in z/OS 2.3
systems depending on the software currency of z/OS.
-ASMRMFV has been changed to input these Sections using
actual rather than documented lengths.
-The SVP, ASI, ENC, and RCD RMF III tables are all
affected when the SVP version level is X'04'.
-MXG Changes 36.191 and 36.201 support new MXG variables
for the new data in the VMACRMFV member.
-ZEROCPU and ZERODVT parameters were not recognized due
to a length specification error in the parameter table.
Change 36.204 Plots and or TABULATE of MSU capacity GRAFMSU Reports.
GRAFMSU For General purpose CPUs:
Nov 16, 2018 CPC Capacity .
LPAR Rolling 4 hr Avg Usage
LPAR Hourly Usage
LPAR Defined Capacity
LPAR Capacity based on % SHARE
LPAR Capacity based on # CPUs
For IIP and IFA/CBP CPUs:
CPC Capacity .
LPAR Rolling 4hr Avg MSU (Estimated)
LPAR Hourly Usage
LPAR Capacity based on % SHARE
LPAR Capacity based on # CPUs
See doc in the member for examples of usage and see
change 36.156 for examples of wrapping in ODS statements
to create HTML or PDF output.
Change 36.203 CPU report with INTERVAL=HOUR actually was produced at
ANALRMFR number of CPUs*intervals so a CEC with 4 CPUs on a 15
Oct 26, 2018 minute interval showed up with 4 hour intervals. DURATM
is now set to the INTERVAL= specified.
Change 36.202 Used primarily inside of other macros to detect the
VGETOBS existence and other information about SAS datasets. But,
Oct 25, 2018 if you happened to pass incomplete text, like .ASUMCELP
(where it should have been DDNAME.ASUMCELP) you could get
strange errors and an ABEND, due to the period. Now, both
sides are validated, or if only one is, WORK is used as
the DDNAME with the DATASET to become WORK.ASUMCELP.
Change 36.201 -MXG 36.09, z/OS 2.2, only, text classification variables
VMACRMFV (ASICNM ASISCWN AISCRN ASIRNM ASIWNM) in dataset ZRBASI
Oct 26, 2018 could be misaligned. Introduced in Change 36.196.
-Some WPS 4.0 iterations failed with
ERROR: The format name '$ CPUPHYAD' invalid
because WPS didn't like the blank in FMTNAME ' CPUPHYAD'
Removing the blank didn't impact SAS but it healed WPS.
Thanks to Rodger Foreman, Black Knight, USA
Change 36.200 Logic rearranged to put error checking at the top, some
VMXG2DTE additional error checking added and abort changed to a
Oct 24, 2018 soft landing with error messages.
Thanks to Tom MacCabe, Dominion Energy, USA
Change 36.199 -Beta 93 Subtype 51 variables now output in BETA51 dataset
FORMATS that are also input in BE97 BETA9751D dataset:
VMACBETA BETALCMD='LINE*COMMAND'
Oct 30, 2018 BETARPOS='POINTER*TO*VALUE*AREA'
-BETA 97 subtype 22 variable B97RELTY in dataset BETA9722
has new values decoded by updated FORMAT MGBETET.
-New BETA 97 subtype 6 will create new datasets when test
records are available.
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 36.198 z/VM VXBYUSR High CPU, MRHDRTOD isn't the same second any
VMACVMXA more in VXUSEACT and VXUSEINT datasets, which caused that
Oct 22, 2018 merge to create multiple obs, which caused deaccumulated
VMDTTIME/VMDVTIME to be very large for those intervals.
MXG used MRHDRTOD=FLOOR(MRHRTOD); to truncate to whole
seconds for the merge, as the value was always :00, but
now, the start of the write of the USER records is often
near the end of the 00: second (e.g. 0.999919 microsec)
and the write extends into the :01 second, and sometime
the ACT record is at :00 and INT is at :01, mismatched.
Now, MRHDRTOD=FLOOR(MRHDRTOD)-MOD(FLOOR(MRHDRTOD),10);
is used to force the minute intervals to always be :00 in
the PDB.VXBYUSE MONWRITE dataset.
The MRHDRTOD one minute interval datetime value that is
used to merge VXUSEACT and VXUSEINT datasets to create
VXBYUSR previously happened to always be on the same
second, so using MRHDRTOD=FLOOR(MRHDRTOD) to truncate
that microsecond value to seconds, the merge matched
observations correctly.
However, the newer data shows that there can be a pair of
records with the USEACT record at :00 seconds and the
paired USEINT record at :01 seconds, causing that merge
pair to create multiple observations.
What has happened? The older data shows the start of the
write of the USEACT/USEINT pairs began at 0.885 seconds
after the pop and the write completed after writing all
of them in 478 microsec, in that one second, but the
newer data shows the write didn't start until 0.999 secs
and the 406 microseconds write time ended in the next
second causing ACT at :00 and INT at :01. Some of the
new values don't even start write until the :01 second.
Sept Data:
03:36:30.885294 Minute 36 Second 30 First USEACT
5 microsec
03:36:30.885299 Minute 36 Second 30 Paired USEINT
471 microseconds (write 78 pairs)
03:36:30.885770 Minute 36 Second 30 Last USEACT
2 microseconds
03:36:30.885772 Minute 36 Second 30 Paired USEINT
==> 78 pair written in 478 microseconds for Minute 36.
But new data has pairs with different seconds values:
Oct Data:
09:36:00.999919 Minute 36 Second 00 First USEACT
3 microseconds
09:36:00.999922 Minute 36 Second 00 Paired USEINT
76 microseconds (write 21 pairs)
09:36:00.999998 Minute 36 Second 00 First USEACT
2 microseconds
09:36:01.000000 Minute 36 Second 01 Paired USEINT
324 microseconds (write 65 pairs)
09:36:01.000324 Minute 36 Second 01 First USEACT
1 microseconds
09:36:01.000325 Minute 36 Second 01 Paired USEINT
==> 86 pair written in 406 microsec for minute 36.
Thanks to Graham Harris, RBS, ENGLAND.
====== CHANGES THRU 36.197 ARE IN MXG 36.09 DATED Oct 18, 2018==========
Change 36.197 Support for new TRAD/TRG count variables in TYPE89,
VMAC89 in z/OS 2.4.
Oct 17, 2018 ICN 1662.
Change 36.196 Support for new z/OS 2.3 RMF III variables (COMPATIBLE)
VMACRMFV added to ZRBASI/ZRBRCDD/ZRBRCDP/ZRBRCDS/ZRBRCDT/ZRBRCDX
Oct 15, 2018 and ZRBSVPC. The new variables are listed in DOCVER36.
-ZRBASI, existing variables now correctly populated:
ZRBDCTIA/ZRBGMN/ZRBGMX/ZRBIDLE/ZRBWNM/ZRBGDE/ZRBDNM.
Change 36.195 zVPS MTRSYS segment with undocumented SEGLEN=336 caused
VMACXAM Serious Error messages and missing output data.
Oct 15, 2018
Thanks to Patricia Hansen, ADP, USA.
Change 36.194 Yet another invalid LENSR value TYPE42 Subtype 5 ABEND,
VMAC42 value LENSR=376 added to Change 36.124.
Oct 15, 2018
Change 36.193 Estimated bytes after IDRC compression added to TMS as
TYPETMS5 TAPEBYTC and to DSNBRECD as DSNBYTEC. Just like the
Oct 11, 2018 TAPEBYTE and DSNBYTE variables (estimates based on
BLKSIZE*BLKCNT) these are best guess estimates.
Change 36.192 Support for IMS Version 15 (COMPATIBLE) dataset IMS56FA.
VMACIMS New string TPCPTHRSESSN contains the pair of TPCPTHRS and
Oct 11, 2018 TPCPESSN for up to six External Subsystems, TPCXLEN has
the length of the TPCX, still 60 reserved bytes.
Thanks to Robert Taylor, Wisconsin Dept of Administration, USA.
Change 36.191 New Type 74 Subtype 8 dataset TYPE748S SYNC I/O variables
VMAC74 R748SCWT R748SNBW R748SNWO R748SNWS R748SNWT were INPUT
Oct 11, 2018 and FORMATted and LENGTHed and LABELed incorrectly.
Thanks to Steve Olenik, IBM, USA.
Change 36.190 A reference line showing the memory allocated to each
GRAFWRKX LPAR was added to the memory graph. The scale on the Y
Oct 11, 2018 axis is 0 to the MAX memory for any LPAR in the data.
Change 36.189 Variable SM113CPT added to the SMF 113 report to show
ANAL113 the engine type.
Oct 9, 2018
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 36.188 Support for new Bit 4 of SMF30_RAXFLAGS and creation of
BUILD005 these new bit-level variables with explanation in label
BUIL3005 SMF30_RAXFLAG0='RAX0*USERKEY*COMMON*AUDIT*ENABLED?'
VMAC30 SMF30_RAXFLAG1='RAX1*USERKEY*COMMON*AUDIT*USAGE?'
Oct 16, 2018 SMF30_RAXFLAG2='RAX2*USERKEY*CADS*USAGE?'
SMF30_RAXFLAG3='RAX3*USERKEY*CHANGE*KEY*USAGE?'
SMF30_RAXFLAG4='RAX4*USERKEY*RUCSA*USAGE?'
that are added to TYPE30_4/TYPE30_5/TYPE30_6/TYPE30_V
and PDB.STEPS for BUILDPDB (JES2) and BUILDPD3 (JES3).
(Variable RAXFLAGS was added in MXG 35.09.)
Thanks to MP Welch, Bank of America, USA.
Change 36.187 WPS does not honor OPTIONS NOXWAIT so there may be times
BLDSMPDB when it is necessary to respond to a message.
PROCSRCE
UTILCPLG
VMXGALOC
Oct 5, 2018
Change 36.186 Labels for variables RECORDS, INSERTS, RETRVALS, UPDATES
VMAC16 and DELETES are now consistent for these three records.
VMAC64
VMACSYNC
Oct 4, 2018
Thanks to Warren Cravey, FMR, USA.
Change 36.185 For want of an & PDB= was not honored but always looked
GRAFCIMP for the data in PDB.
Oct 4, 2018
Change 36.184 JES 2 JMF subtype 21 INPUT RECORD EXCEEDED LENGTH because
VMAC84 triplets were misaligned and this was the first instance
Oct 3, 2018 of that subtype to test.
Oct 11, 2018 -Value of JMFINTRV is 60+ hours, JMFDELTA is 90 minutes,
so the two percentage calculations use JMFDELTA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Joe Faska, DTCC, USA.
Change 36.183 -Power Exchange USER SMF record STOPOVER if the File Name
VMACPOEX had zero length. Invalid record detected and printed on
Oct 3, 2018 log and skipped, while vendor investigates.
Oct 18, 2018 -Invalid new triplet record with no SECT segment deleted,
Nov 20, 2018 and a record with truncated General Section is deleted.
-The GMT offset depends on POEXENDT; if it's missing the
offset can't be calculated. Pending a vendor correction,
MXG Retains the GMTOFFEX and uses that value instead,
which could cause missing values for STRT/ENDT.
Nov 20: The Informatica fix number for this problem is
PWX-7566 and it will be in code base PWX V10.2.0 Hotfix2
currently scheduled for Q1 of 2019.
Thanks to Scott Wiig, US Bank, USA.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 36.182 MXG 36.07-36.08. Possible syntax error in a SYSFUNC due
MONTHBLD to Change 36.145, which changed a QCMPRES to a SYSFUNC
MONTHBL3 (changed only to protect possible user typing errors)
MONTHBL3 but should have used QSYSFUNC, because SYSFUNC saw the
MONTHDSK commas as operands and failed. The member from 36.06 all
MONTHASC the way to 32.05 can be used. Fortunately, MONTHBLD is
PRODTEST normally tailored into the "USERID.SOURCLIB" so the ERROR
PRODTESW only impacts new users of the MONTHPDB in 36.07-36.08.
Oct 3, 2018 -Dec 31: MONTHBL3 was missing a semicolon, found in QA.
Dec 31, 2018
Change 36.181 Support for zVPS USEDIAG segment adds variables DIAGNBR
VMACXAM and DIAGVALUE to datasets XMUSVCPU and XAMUSR.
Oct 2, 2018
Thanks to Patricia Hansen, ADP, USA.
Change 36.180 -UTILBLDP with RMFINTRV=NO and BUILDPDB=YES did not create
UTILBLDP PDB.TYPE70 nor the other PDB.TYPE7x datasets. The "NO"
Oct 4, 2018 should have suppressed only the %INCLUDE of RMFINTRV in
MACRO _INTRMF, but it also suppressed the seven _S7xxxxx
data set sort macros. RMFINTRV=YES is automatic with
BUILDPDB=YES, and now RMFINTRV=NO and BUILDPDB=YES will
create the 70s but not create PDB.RMFINTRV. If you want
to build PDB.RMFINTRV and the ASUM70PR datasets from only
the 70 and 72 SMF records, see EXAMPLE 3A/3B in UTILBLDP.
Thanks to Ralph Gifford, AIG, USA.
Change 36.179 Support for USER CICS fields USER3/USER3 and ATOUSER.
IMACAAAA
IMACICWZ
IMACICXA
VMAC110
UTILEXCL
Sep 28, 2018
Thanks to Richard Baker, ATO, AUSTRALIA.
Change 36.178 Target Resource Group dataset TYPE89R2 was incomplete and
VMAC89 fields were misaligned.
Sep 28, 2018
Thanks to Greg Goshia, Ohio Farmers Insurance, USA.
Change 36.177 Reserved Change Number.
Change 36.176 Extraneous % in UTILBLDP could cause 180 ERROR and ABEND.
UTILBLDP Line 665 had a stray percent sign, MXG 36.08 only.
Sep 20, 2018 The EXPDBOUT= argument exposes the error.
Thanks to Tom MacCabe, Dominion Energy, USA
Change 36.175 Support for SMF 30 User Key CSA Audit Enhancements adds
VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and
Sep 28, 2018 the TYPE30_5 datasets. Change 35.212 (MXG 35.09+) Sep
Feb 28, 2018 2017 made the code change but the change text was still
Sep 20, 2018 a "Reserved Change" until Feb 28, 2018, but had the old
35.212 Change Number, so it was only in CHANGESS member.
The IBM Record Change was made by APAR OA53355, but will
only be needed thru z/OS 2.3, as User Key Common Storage
usage support ends there.
This is Health Check ZOSMIGV22R3_NEXT_VSM_USERKEYCOMM.
These APARs required no additional code changes:
OA53434 Corrects IBM macros SMF30RPS,SMF30SDS lengths
not field lengths so it has no impact on MXG.
OA53289 Corrects value of SMF30HVR from zero to valid.
OA45767 APAR that added the extra triplet caused OA53434
See Change 36.188 which added new bit-level variables.
Change 36.174 Support for Auto Soft Capping (ZCOS) Version 4.2 added
VMACZCOS these variables, INCOMPATIBLY, due to a new field that
Sep 21, 2018 was inserted prior to a triplet.
Dataset ZCOS01:
ZCOS01PC4HA='TOTAL*CATEGORYA*R4H OF LPARS'
ZCOS01PC4HB='TOTAL*CATEGORYB*R4H OF LPARS'
ZCOS01PC4HM='TOTAL*MOBILE*R4H OF LPARS'
ZCOSDETO='SMF*INTERVAL*END*TIME'
ZCOSDDTO='SMF*INTERVAL*DURATION'
ZCOSDOTO='GMT*OFFSET'
Dataset ZCOS02:
ZCOSPR4HA='4H CATEGORYA MSU AVERAGE'
ZCOSPR4HB='4H CATEGORYB MSU AVERAGE'
ZCOSPR4HM='4H MOBILE MSU AVERAGE'
ZCOSPS4H ='4H TOTAL MSU AVERAGE AT SMF IV TIME'
ZCOSPS4HA='4H CATEGORYA MSU AVERAGE AT SMF IV TIME'
ZCOSPS4HB='4H CATEGORYB MSU AVERAGE AT SMF IV TIME'
ZCOSPS4HM='4H MOBILE MSU AVERAGE AT SMF IV TIME'
ZCOSPSTIM='ZCOSPSTIM*DATETIME*STAMP'
Dataset ZCOS04GP:
ZCOSMOBT='MOBILE*TARGET*R/S/D'
ZCOSCMPR='MANAGE*BILLING*CPM?'
ZCOSCMPF='CMP*FLYING*MSU MGT?'
Dataset ZCOS04CP:
ZCOS04CTHR='CPC*CONTROL*THRESHOLD'
Dataset ZCOS04LP:
ZCOS04PDLV='MSU*DISTRIB*LEVEL*BOUNDARY'
Change 36.173 -Support for Mainview MVS History Records. The new BMC
EXCMFV02 MD73 utility creates these 28 new RTIN records, which
EXCMFV09 create these 44 new datasets with CMRDETL information.
EXCMFV0C
EXCMFV0D
EXCMFV0F DDDDDD Dataset Description
EXCMFV10
EXCMFV16 CMFV10 CMFV10 Address Space 10 ADRE
EXCMFV17 CMFV16 CMFV16 Lock 16 LKRE
EXCMFV18 CMFV17 CMFV17 VSAN RLS Activity 17 RLRE
EXCMFV20 CMFV18 CMFV18 VSAM RLS LRU 18 RURE
EXCMFV21 CMFV181 CMFV181 DEVICE 83 DLRE
EXCMFV2E CMFV20 CMFV20 COUPLING FACILITY
EXCMFV34 CMFV21 CMFV21 System Summary 21 SLRE
EXCMFV46 CMFV2E CMFV2E Data Set 23 DSRE
EXCMFV47 CMFV34 CMFV34 Unix Process 34 UPRE
EXCMFV48 CMFV46 CMFV46 PROCESS
EXCMFV49 CMFV47 CMFV47 WLM Extended Period 47 MXRE
EXCMFV50 CMFV48 CMFV48 WLM Addr Space/Enclave 48 MTRE
EXCMFV51 CMFV49 CMFV49 WLM Enclave Classify 49 MCRE
EXCMFV52 CMFV50 CMFV50 XCF Path 50 XPRE
EXCMFVES CMFV51 CMFV51 XCF System 51 XSRE
EXCMFV54 CMFV52 CMFV52 XCF Source/Destination 52 XDRE
EXCMFV70 CMFVES CMFVES ES CRITERIA 53 ----
EXCMFV71 CMFV54 CMFV54 WLM Server 54 MWRE
EXCMFV72 CMFV70 CMFV70 System Summary 70 SBRE
EXCMFV73 CMFV71 CMFV71 Device 71 DBRE
EXCMFV74 CMFV72 CMFV72 Address Space 72 ABRE
EXCMFV80 CMFV73 CMFV73 WLM 73 WBRE
EXCMFV81 CMFV74 CMFV74 LPAR 74 LBRE
EXCMFV82 CMFV80 CMFV80 ZFS Aggregate 80 ZSRE
EXCMFVC0 CMFV81 CMFV81 ZFS Cache 81 ZCRE
EXCMFVC1 CMFV82 CMFV82 PCIE Activity 82 PCRE
EXCMFVC2 CMFVC0 CMFVC0 PROCESS C0 PRRE
EXCMFVC4 CMFVC1 CMFVC1 THREAD C1 THRE
EXCMFVCC CMFVC2 CMFVC2 MOUNTED FILE SYSTEM C2 FMRE
EXCMFVCD CMFVC4 CMFVC4 SYSTEM PARAMETERS C4 PMRE
EXCMFVCE CMFVCC CMFVCC PROCESS/TTY CC P1RE
EXCMFVCF CMFVCD CMFVCD VSAM COMMON STORAGE CD P2RE
EXCMFVD0 CMFVCE CMFVCE PROCESS/COMMAND CE P3RE
EXCMFVD1 CMFVCF CMFVCF USS PROCESS CWD CF CFRE
EXCMFVD2 CMFVD0 CMFVD0 MOUNTED FS/MOUNT POINT D0 F1RE
EXCMFVD3 CMFVD1 CMFVD1 MOUNTED FS/MOUNT PARMS D1 F2RE
EXCMFVD4 CMFVD2 CMFVD2 HFS GLOBAL D2 HGRE
EXCMFVFD CMFVD3 CMFVD3 HFS FILESYSTEMS D3 HFRE
EXCMFW18 CMFVD4 CMFVD4 HFS BUFFERS D4 HBRE
IHDRCMFV CMFVFD CMFVFD SCM FD FDRE
IMACCMFV CMFWC0 CMFVC0 PROCESS 18-1 DLRE
VMACCMFV
VMXGINIT -The three files contain these RTIN values:
Oct 30, 2018 SHRT only contains 70x 71x 72x 73x 74x
LONG only contains 0Cx 10x 18x 21x
NORM contains all except 0Cx 10 11 12 13 14 15
and contains C0 C1 C2 C4 CC CD CE CF D0 D1 D2 D3 D4.
-RTIN 18 appears both in LONG (1) and NORM (0), so the
CMFV18 and CMFW18 DDDDDDs create CMFV18 and CMFV181.
-These RTINs were supported, no longer documented:
25 26 27 28 29 33 41 42 43 45 53 96 97
-These RTINs are not yet supported, await DSECTs:
11 12 13 15 1E 2A 2B 2C 2D
-Truncated RTIN '47'x with ENTL=1204 vs 1536 protected.
Thanks to Michael Oujesky, DTCC, USA.
Change 36.172 READDB2(IFCIDS=0-999) failed when it got past IFCID 367,
READDB2 the current high IFCID. That syntax requires contiguous
Sep 13, 2018 values, so if you specify a value GT 367 the upper limit
is reset to 367 and a note is printed on the log. If you
really want to create ALL of the IFCIDS use IFCIDS=ALL.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.171 Support for z/14 Clusters added to IBM Processor Topology
ANAL9914 Report.
Sep 13, 2018
Thanks to Raymond J. Smith, OPTUM, USA.
====== CHANGES THRU 36.170 ARE IN MXG 36.08 DATED SEP 10, 2018==========
Change 36.170 For sites with 8-byte values for SMF70STN or SYSNAME or
SAGANAL with 4-byte values that don't match SYSTEM, or MXGWARNs
Sep 9, 2018 about TYPE70 or TYPE70PR data missing, you will need to
Nov 11, 2018 use the output of this PROC FREQ report
PROC FREQ DATA=PDB.TYPE70PR (WHERE=(SMF70STN=SYSNAME));
TABLES SYSNAME*SMF70STN/NOROW NOCOL NOCUM NOPCT;
to update the new SELSTN macro variable to set the SYSTEM
from the corresponding SMF70STN value:
%LET SELSTN=
%QUOTE(
IF STN(_I_) EQ 'DHECPROD' THEN STN(_I_)='DHEC';
ELSE IF STN(_I_) EQ 'DHECTEST' THEN STN(_I_)='DHCT';
ELSE IF STN(_I_) EQ 'PROD' THEN STN(_I_)='SYS1';
ELSE IF STN(_I_) EQ 'TEST' THEN STN(_I_)='SYST';
ELSE PUTLOG _N_= _I_= STN(_I_)= SYSTEM=;
);
Thanks to Henry Jenkins, South Carolina State Government, USA.
Change 36.169 Change 36.077 checked for the word BY in the first 2
VMXGSUM bytes of INCODE but there is no reason the BY would have
Sep 8, 2018 to be in the first two bytes, so logic was revised to
find any " BY " text in the INCODE. If the first text
in the INCODE= was a %INCLUDE, it failed because the
percent sign needed to be protected with %SUPERQ().
Change 36.168 Dataset BVIR20 variables MAX/AVE AHCT/BHCT were incorrect
VMACBVIR as the +46 after DEVINTDL is their input location and
Sep 8, 2018 removed.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.167 Support for BMC Energizer for IMS Connect which populates
VMACCIMS TRNOTxxx variables in CIMSTRAN dataset, but TRNOTCON was
Sep 7, 2018 not converted to local, and new CONNECT*SERVICE*DURATION
in new CONNECTM variable.
Thanks to Randy Hewitt, DXC, USA.
CRITICAL ERROR: PDB.TYPE70 MAY BE WRONG WITH 33+ TOTAL ENGINES.
NO IMPACT TO PDB.TYPE70PR,ASUMCELP/ASUMCEC/ASUM70PR/ASUM70LP.
Change 36.166 Dataset PDB.TYPE70 skips LCPUADDR/CPUID 64 and higher and
VMAC7072 does NOT include any of those engine's CPU time, UP time,
Sep 9, 2018 nor NRCPUS count, causing CPUACTTM for CPs to be less
than the CPUTM in TYPE72GO Service Classes, which causes
log messages NEGATIVE UNCAPTURED CPU TIME in RMFINTRV.
-This error can occur with as few as 33 total engines; as
in this case, with 13 CPs and 19 zIIPs, IBM skipped every
other LCPUADDR so the last ZIP was '3F'x, and when a 14th
CP was added, it became '40'X and exposed the MXG error.
-ONLY PDB.TYPE70/PDB.RMFINTRV are impacted; PDB.TYPE70PR
and PDB.ASUMCELP/ASUMCEC/ASUM70PR/ASUM70LP datasets that
are created from TYPE70PR capture all engines' data.
-This MXG error was introduced in 2013 in 31.04 support
for 255 engines; previously separate variables for every
engine, 0 thru 63 were created and kept; but new dataset
TYPE70EN was created with all engines details so new vars
were not needed to be kept, but they were still created
for the summary into TYPE70, but the old logic to update
the IFATYPE array still stopped at engine 63.
You can use this program to read your PDB.TYPE70PR data
to see if you are exposed, and the CPU TIME lost, if any:
DATA CPUMISSED;
SET PDB.TYPE70PR;
IF LCPUPDTM GT 0 AND SMF70CIN IN ('CP' 'IIP');
KEEP SMF70CIN SYSTEM LCPUPDTM RANGE;
IF LCPUADDR LT 64 THEN RANGE='INCLUDED-LT 64 ';
IF LCPUADDR GE 64 THEN RANGE='NOT INCLUDED-GT 64';
PROC FREQ;
TABLES SMF70CIN*RANGE*SYSTEM/NOCOL NOCUM NOROW;
WEIGHT LCPUPDTM;
TITLE LOST/INCLUDED PDB.TYPE70 CPU TIMES HIGH LCPUADDR;
to see how much CPU was included or lost in PDB.TYPE70.
-Normally, CPs LCPUADDR start at zero, followed by zips,
so the impact is more likely for zip metrics, but when
CPs are added dynamically, they get the next LCPUADDR.
Only PDB.TYPE70 and PDB.RMFINTRV datasets are impacted.
and only resources summed from individual engines; the
4HR Average MSU SMF70LAC and similar "interval variables"
are not impacted by this error.
Neither the PDB.TYPE70PR nor the four ASUM70PR datasets
PDB.ASUMCELP,ASUMCEC,ASUM70PR,ASUM70LP are impacted.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 36.165 Analysis of SMF 89 data, including conversion of CPU time
ANAL89 into MSU values, with several reports.
Sep 10, 2018
Thanks to Edward Cornish, Verisk, USA.
Change 36.164 Variable SMF82KVL is added to TYPE8207 with number of
VMAC82 nibbles in SMF82KV field. ICN 1652.
Aug 30, 2018
Change 36.163 IMS56FA observations for CPI-C PROGTYPHX='10'X do not
VMACIMS have an ARRVTIME so their INPQUETM can't be known, but
Sep 7, 2018 MXG incorrectly calculated wrong values. Now INPQUETM
is missing when ARRVTIME is unknown.
Change 36.162 Variable SYSTEM does not exist in IMS Log Records but MXG
IHDRIMS can set it from SYSPARM() on the // EXEC JCL statement,
VMACIMS but that applies to the entire IMS log that was read.
VMXGINIT Now, to process multiple IMS system's logs in one job,
Aug 28, 2018 JFCB=IMSJFCB is added so the DSNAME in the first 44 bytes
can be used in tailoring member IHDRIMS or instream use
%LET MACIMSH= in your SYSIN to set the variable SYSTEM.
For example, if the second node in your DSNAME is SYSTEM,
%LET MACIMSH= %QUOTE( SYSTEM=SCAN(IMSJFCB,2,'.'); );
will populate variable SYSTEM with that value.
-Variable PROGTYPE='C' is now set for PROGTYHX='10'X.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.161 If OUT70GL=WORK.xxxxxxxx, ASUM70PR program failed with
VMXG70PR DATASET PDB.ASUM70GL NOT FOUND because the _LSU70GL
Aug 28, 2018 token instead of macro variable &OUT70GL was used.
Thanks to Jutta Gleixner-Schmid, Allianz, GERMANY.
Change 36.160 MXG 36.07 only. Debugging PUTLOG statements that filled
VMACCIMS the log were disabled.
Aug 27, 2018
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 36.159 DB2STAT2 field QDBPFRAM, Frame Size, in SMF is $EBCDIC2
VMACDB2 with text values of 4K, 1M, 2G, but MXG input QDBPFRAM
Aug 27, 2018 as PIB2 numeric causing wrong values (62151 for 2G).
New QDBPFRAMCH character variable has the 4K/1M/2G text,
and QDBPFRAM remains numeric now with the correct bytes
(for calculations), printing 4K, 1024K, 2048M with the
MGBYTES format.
Thanks to Lori A. Masulis, FMR, USA
Change 36.158 Support for APARs OA55574/OA55609/OA55610 adds new
VMACDCOL variables in dataset DCOLDSET:
Aug 25, 2018 DCDCMPTV='COMPRESSION*TYPE*VALID'?
DCDCTYPE='COMPRESSION*TYPE'
See Change 37.064 for revised change. ICN 1650.
Change 36.157 -Variable FCVSWTTM in CICSTRAN was incorrect, containing
VMAC110 the same value in FCXCWTTM.
Aug 26, 2018 -Variable SMFPSSPN, the Specific APPLID is now kept in the
CICSTRAN dataset.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.156 While these ODS members do work within the limitations of
VMXGODSO their programming, ODS is evolving so quickly and there
VMXGODSC are so many permutations and combinations that they are
TECHNOTE no longer a practical answer for most applications.
Aug 23, 2018 Some MXG GRAFxxxx and ANAL members have ODS parameters,
but you may find it preferable to wrap many reports in a
single ODS package. For example, to run GRAFWRKX+GRAFCEC
and send the results to a single ODS PDF file, use:
ODS LISTING CLOSE; /* always needed on zOS */
OPTIONS ORIENTATION=LANDSCAPE;
ODS GRAPHICS/ WIDTH=10IN HEIGHT=7.5IN;
ODS PDF FILE='D:/MYPDF.PDF' STYLE=MXGSTYLE1;
%GRAFWRKX;
%GRAFCEC;
RUN;
ODS PDF CLOSE;
RUN;
-MXGSTYLE1 was used here because the default style used by
ODS results in bars of solid colors so close together it
can be difficult to tell one bit of the bar from another.
MXGSYLE1 uses brighter colors and patterns to make it
simpler to tell who is on first. MXGSTYLE1 is created
and stored in the FORMATS library by the FORMATS member.
STYLE is just one of many ODS options you may wish to
use which is what makes VMXGODSO/VMXGODSC obsolete.
-Pasted directly from the SAS site to create CSV file:
ods html close;
options obs=15;
ods csvall body='procprintcsvall.csv';
ods markup tagset=chtml body='procprintchtml.html'
(title= 'This Text Identifies Your Content.');
title 'Leading Grain-Producing Countries';
proc print data=grain_production;
run;
ods csvall close;
ods markup tagset=chtml close;
Change 36.155 Support for Z/VM LINUX LNXAPPL Process & summary APL data
EOAPLLXP creates these new datasets:
EXAPLLXF dddddd dataset description
EXAPLLXP APLLXF VXAPLLXF LNXAPPL FILE SYSTEM DATA
EXAPLLXS APLLXS VXAPLLXS LNXAPPL SUMMARY DATA
IMACVMXA APLLXP VXAPLLXP LNXAPPL PROCESS DATA
VMACVMXA -The VXAPLLXP process dataset only outputs a process that
VMXGINIT had non-zero TOTAL_TIME or CTOTAL_TIME; if you want all
Aug 25, 2018 process records to be output, edit member EOAPLLXP into
Sep 13, 2018 your tailoring library and remove the conditional test.
-SAMPTIME and UPTIME are not valid values, investigating.
-Crypto Type 12:CEX6C is now recognized and output in the
VXPRCAPM dataset.
-Dataset VXPRCMFC is now populated for z14, CSVN=5.
-Sep 13: RESID corrected to RESIDENT, comments deleted.
Thanks to Graham Harris, RBS, ENGLAND.
Change 36.154 Support for CMODHEAD=NRXENTRY CMODNAME=NRXDATA optional
IMACAAAA CICS SMF 110 CICSTRAN segment and new NRXENTRY variable.
IMACICWY
UTILEXCL
VMAC110
Aug 18, 2018
Change 36.153 New parameter added that can be used to reverse the
GRAFWLM order of data on the charts produced. GRAFWLM has
GRAFWRKX always produced bar charts with the most important
Aug 24, 2018 work at the top and the least important (discretionary)
at the bottom. Now this parameter HIGHTOLOW (default
is YES, original order) if set to NO reverses the order.
-Old default YES has UNCAPTURED at top and DISCRETIONALY
at bottom, NO reverses that order.
-Some ODS logic was corrected - changed from NE to EQ.
-Some statements reordered for logical ordering
Preceding changes were only in GRAFWLM.
-Only in GRAFWRKX, the default values for width and height
were reduced to 7.5 and 10 inches to eliminate warning
messages that the values were too large.
Thanks to Daniel McKinzie, Zions Bank, USA.
Change 36.152 -New Formats created to decode SMF 106 variables
FORMATS SMF6ACTP MG106CT. SMF6ACTY MG106CD. SMF6ATYP MG106SE.
VMAC106 -TYPE1061 dataset SMF6ASET has character and numeric value
Aug 17, 2018 that are not documented; MXG creates multiple SMF6ASETxx.
-TYPE1062 dataset SMFCMDPM contains two binary fields that
are decoded in SMF6A001/002 variables but seem too large
to be look up tables for parameters.
Thanks to Joe Faska, DTCC, USA.
Change 36.151 Updates from SMF Manual Jul 30, 2018.
FORMATS -Format MG022ET adds values
VMAC42 5='5:COUPLING FACILITY CONTROL UNIT'
VMAC62 6='6:LOGICAL PARTITION ENTRY'
Aug 12, 2018 9='9:PCIE FUNCTION'
-Variables added to TYPE42SR dataset:
S42SCRRU='AVG*RANDREAD*CACHEHIT*RESPTM'
S42SCRSU='AVG*RANDREAD*CACHEHIT*SERVICTM'
-Variables added to TYPE62 dataset:
SMF62IND_2='CATALOG*OR CRA*RECORD?'
SMF62IND_3='VVDS*OR*ICF*RECORD?'
SMF62IND_4='SMS*CLASS*INFO*INCLUDED?'
SMF62IND_5='DATASET*IS*ENCRYPTED?'
Change 36.150 Support for APAR OA54589, OSPROTECT/TRUSTED/NOTRUSTED
BUILD005 adds these new variables to TYPE30_4 and PDB.STEPS:
BUIL3005 SMF30CAS_OA54589_0='SMF30CAS*OA54589*BYTE 0'
VMAC30 SMF30CAS_OA54589_1='SMF30CAS*OA54589*BYTE 1'
Aug 12, 2018 SMF30CAS_OA54589_2='SMF30CAS*OA54589*BYTE 2'
Aug 27, 2018 SMF30CAS_OA54589_3='SMF30CAS*OA54589*BYTE 3'
These variables are created from the bit tests for the
preceding Byte variables listed in the SMF Manual:
SMF30CAS_OSPROTECT='OSPROTECT';
SMF30CAS_UNTRUSTED='UNTRUSTED?'
SMF30CAS_TRUSTED='TRUSTED?'
====== Changes thru 36.149 are in MXG 36.07 dated Aug 8, 2018==========
Change 36.149 One site's IMF data has TRNETIME/TRNSTCKE two hours early
VMACCIMS (STRTTIME,ENDTIME) but TRNCVTTZ (GMT Offset) is zero and
VMXGINIT the site has not responded with their local/GMT times, so
Aug 8, 2018 this may be a temporary circumvention, but macro variable
IMFGMTOFF is created with value of zero and when it was
set &LET IMFGMTOFF=7200; before the %INCLUDE, the times
were correct. This change text will be updated when it
is known why these times, previously always the same time
zone as the ARRVTIME, are now different at this site.
Change 36.148 The combination of a PROC DATASETS with no MT= option and
ANALRMFR with a DELETE statement with a wildcard S: caused QA job
Aug 8, 2018 to fail with WPS because it honored the MT=ALL default to
delete both datasets starting with S, but unexpectedly
also deleted the SASMACR CATALOG dataset, which caused QA
to subsequently fail. But SAS only deleted datasets so QA
did not fail. Since the actual intent was to only delete
datasets, adding MT=DATA to the PROC DATASETS corrected
for both SAS and WPS. However, using MT=ALL with SAS
still only deleted datasets, printing this note:
WORK.SASMACR cannot be deleted because it's in use.
Change 36.147 Support for APAR OA52810 Data Set Encryption in DCOLMIGS
FORMATS dataset, adds new variables:
VMACDCOL
Aug 8, 2018
Thanks to Luc Gielis, KBC, BELGIUM
Change 36.146 -If you are not running MRO or you do not see a reduction
ASUMUOW in the OBS count between CICSTRAN and ASUMUOW on the
MXG NOTE order of 2:1 or better, it may indicate that the use of
Aug 7, 2018 MRO is not significant and it may be that running ASUMUOW
is a waste of resources. ASUMUOW has to sort all of the
CICSTRAN and DB2ACCT and MQ records to be able to merge
everything together and can be very resource intensive.
-If you have DB2 ROLLUPS that data becomes very suspicious
since one DB2 record can represent many transactions and
it is best in that case to not use ASUMUOW with DB2 data
as documented in change 36.107.
-If you find that running ASUMUOW is expensive or that you
are not achieving any serious reduction in OBS in ASUMUOW
dataset using ASUMUOW compared to the OBS in CICSTRAN,
then don't run ASUMUOW: instead, use ASUMCICS to create
the PDB.CICS dataset.
-All of the DB2 CPU time is captured in the CICS records;
only the class 3 wait times/counts are lost, but those
are primarily deep diagnostics, where it may be much
better to run ANALDB2R against the PDB.DB2ACCT dataset
selecting the desired transaction.
Change 36.145 QCMPRES is an AUTOCALL macro and we try to avoid using
ANALDB2R them since they have caused issues in the past. This
MONTHASC change replaces QCMPRES by a %SYFUNC(COMPBL) call to
MONTHBLD compress blanks for safety.
MONTHBL3
MONTHDSK
PRODTEST
PRODTESW
Aug 7, 2018
Change 36.144 -Compare Interval CPU time Captured RMF/SMF/CICS/DB2 with
COMPINTV totals and plots of each system. The ancient program was
Aug 8, 2018 restructured as a macro that can either read SMF data or
extract the data from an existing PDB. Parameters allow
you to limit the scope of the data being analyzed. The
output is a combination of PROC MEANS, TABULATEs, and
SGPLOTs and will show you capture ratios for RMF and SMF
for both CPUs and ZIPs as well as the CPU times from
RMF, SMF, CICS, and DB2.
-See the member for documentation on parameters and
usage.
-Some examples of usage
Read SMF and create reports on half hour intervals
%compintv(compinterval=halfhour);
-Get data from pdb and report on half hour intervals
%compintv(compinterval=halfhour,readsmf=no);
Change 36.143 Support for RSD Folders Version 6.0 Audit Records with
FORMATS INCOMPATIBLE updates. Only version 6.0 is supported, and
VMACRSDA one inconsistent record format is under investigation
Aug 5, 2018 and is not output.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 36.142 The MXGKEEP= default was incorrectly changed to NO in
VMXGINIT MXG 36.04, but the default MXGKEEP=NO is restored, as
Aug 5, 2018 YES can cause errors if there are INCODE variables.
Change 36.141 zHPF Channel Utilization
MXG Note zHPF was introduced by IBM to reduce channel utilization
Jul 31, 2018 and to improve data transfer performance. At the core,
the difference between zHPF enabled and traditional
FICON channels is the schema employed to transmit
channel programs and data. For traditional CCWs, a
channel program (comprised of multiple CCWs) is
transmitted from the channel to the subsystem in very
small chunks, CCWs and data blocks. Each turn around
increases channel utilization and as the utilization
increases, the acknowledgement coming back from the
subsystem experience delays like Volkswagens driving in
a sea of semis.
What zHPF does is it packs the CCWs and data blocks into
Transmission Control Words, i.e., TCWs. By reducing the
number of turnarounds required to transmit CCWs and data
blocks, the portion of channel utilization resulting
from the turnarounds is reduced. Moreover, by reducing
the number of turnarounds required for data transfer,
the effective data transfer rate is increased.
Finally, your mileage may vary. If your I/O stream
primarily supports VSAM or DB2 datasets, you will see a
lot of difference. If you have a large fraction of
traditional access methods, your level of benefits may
be reduced.
The TYPE73 Channel Busy is the primary indicator of the
benefit of zHPF.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 36.140 New READDB2 parameter SORT102 with SORT102=YES default
READDB2 can be changed to SORT102=NO to suppress the sorting of
Jul 27, 2018 T102Sxxx trace datasets and to suppress VFMT102 execution
that creates $MGDB2DB and $MGDB2OB formats when 105/107
IFCIDS are selected. They are used by ANALDB2R to match
DBID/OBID in trace datasets.
Thanks to Laifai Wong, Bank of America, USA.
Change 36.139 UTILBLDP enhancements and corrections.
UTILBLDP -If you asked for DB2 trace records and specified
Aug 7, 2018 SORTOUT=NO the T102xxxx datasets were still sorted.
-New parameter AUDITAFTER added with a default of NO.
With BUILDPDB=NO, PDBAUDIT is not executed by UTILBLDP.
With BUILDPDB=YES and AUDITAFTER=NO, there is no change:
PDBAUDIT is executed after BUILDPDB but before MXGINCL
and INCLAFTR programs are executed.
With BUILDPDB=YES and AUDITAFTER=YES, PDBAUDIT is now
executed after all of the specified MXGINCL and INCLAFTR
members are executed.
With BUILDPDB=YES and AUDITAFTER=NEVER, PDBAUDIT is not
executed.
-Now if you specify SUPPRESS=ID with BUILDPDB=YES, the
creation of dataset ID and execution of ANALID are
suppressed. Previously this caused an ABEND.
Thanks to Laifai Wong, Bank of America, USA.
Change 36.138 DB2 IFCID 18 dataset T102S018 was misaligned with wrong
VMAC102 input lengths, for both DB2 V12 and V11.
Jul 27, 2018
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 36.137 -INVALID DATA for variable MICROCODE that MXG input as a
VMACRHEL numeric, is caused by character values '0x3c', so new
Jul 30, 2018 MICROCODECH character variable is created and MICROCODE
is set to a missing value to prevent VARIABLE NOT FOUND
errors.
-WARNING COUNT USER IN DROP/KEEP/RENAME list was printed
if the MXG Default OPTIONS DKROCOND=NOWARN was changed,
but they shouldn't have been in the KEEP list and are now
removed, and PROGNAME has been added to RHELUARG dataset.
-Datasets left in WORK are now deleted.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 36.136 If you want to ABEND when RMFINTRV workload definitions
VMXGRMFI fall thru to OTHER, i.e., a Service or Reporting Class
VMXGINIT was found that was not mapped in your WORK= definitions,
Jul 23, 2018 you can force a user ABEND nnnn using non-zero NNNN in
%LET MXGABNDRMFI=nnnn; in your sysin.
The log will list the first undefined SRVCLASS value.
Thanks to Wayne Bell, UNIGROUP, USA.
Change 36.135 -Support for PowerExchange Version 10 was redesigned as
VMACPOEX some variables should not have been output in some of
Jan 9, 2018 the datasets, and a number of new variables are kept.
Jan 22, 2018 The four CPU times POEXCPUG, CPUC, CPUD, and POEXCPUL:
Jul 20 ,2018 POEXLIST keeps only POEXCPUG and POEXCPUL
POEXCLIE keeps only POEXCPUG and POEXCPUC; the variables
from FILE and DB2 segments are removed as they
were only from the last segment.
POEXDB2 keeps only POEXCPUG and POEXCPUD
POEXFILE has no CPU times.
-New CPU time variables are added to POEXLIST POEXCLIE:
POEXGSID='POWER*CENTER*SESSION*ID'
POEXGMNM='MAP*NAME'
POEXGTCP='CPU*TIME*ON*CP'
POEXGTOT='CPU*TIME*ON*ZIIP'
POEXGTOF='CPU OFFLOAD*ELIGIBLE*ON*CP'
-New DB2 variable added to POEXDB2 dataset:
POEX2QTY='DB2*CONNECTION*02X=CAF*12X=RRSAF'
Thanks to Scott Wiig, US Bank, USA.
Change 36.134 WebSphere SMF 120 subtypes 5 and 6 only output the first
VMAC120 method per bean, but there can be many. The logic was
Jul 20, 2018 corrected and all are now output in TYP120JC/TYP120JI.
Thanks to Nick Varley, SYNCSORT, USA.
Change 36.133 Variable LPARBUSY was not calculated for z14 processor
ASUM113 in dataset PDB.ASUM1131.
Jul 18, 2018
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.132 Support for EOS Version 160 (INCOMPATIBLE) Audit/Account
VMACWSF records. Only the END records (subtype 4 and 20) have
Aug 5, 2018 valid begin and end times and have their GMT times reset
Sep 26, 2018 to local time zone.
Change 36.131 Reading compressed DB2/CICS data with MXGREADSMF=LOGGER
VMACSMF did not invoke the EXITCICS CICSIFUE exit; the &SMFEXIT
Jul 12, 2018 macro variable was not in the LOGGER's INFILE statement.
-If you have compressed CICS or DB2 records and want to
read the LOGGER data, you must use the CICSIFUE INFILE
exit (EXITCICS); the internal MXG decompression code is
not supported for that combination.
Thanks to John Compton, World Programming, ENGLAND.
Change 36.130 Variable NDMUID is now populated from NDMZUID in NDMCT
VMACNDM and NDMFI datasets with the full 64 byte user id.
Jul 12, 2018
Thanks to Amlyn Parry, Barclays, ENGLAND
Thanks to Heimir Hauksson, Barclays, ENGLAND
Change 36.129 SAS Note 61906 reports SAS 9.4 TS1M3 on z/OS might
SAS NOTE experience poor performance in DATA steps, with CPU time
Jul 12, 2018 increase of 40% reported. The issue is fixed in TS1M4
Aug 8, 2018 and later. See http://support.sas.com/kb/61/906.html
A hot fix was planned for TS1M3, note created Feb 28 and
modified Mar 8, 2018; no Hot Fix was created since M4/M5
corrected the poor performance. But Aug 8, 2018 SAS Tech
Support suggested for SAS 9.4 at TS1M3 that using
// EXEC SASPROC,OPTIONS='MSYMTABMAX=20000000'
to increase the size of the macro symbol table from 1M to
19M would and did eliminate the CPU time increase.
Subsequently, Tech Support said using 2M syntax would and
did resolve the problem.
====== Changes thru 36.128 are in MXG 36.06 dated Jul 9, 2018==========
Change 36.128 z/OS SAS 9.4 M2 Note 58492 reports reading tape data sets
SAS NOTE can fail with ERROR: LIBRARY WEEK31 IS NOT A VALID FORMAT
Jul 4, 2018 FOR ACCESS METHOD SASV7SEQ, but that error message is not
correct. The error is not an invalid format, but is a
memory allocation error. SAS 9.4 M2 added support for LBI
(Large Block Interface), which allocates a buffer for
each tape data library below the 16MB line, and a large
number of SAS tape libraries can exhaust that memory
area. Unfortunately, increasing the REGION size does NOT
increase the below the line size. Reducing the number of
tape data libraries can circumvent the error, which is
corrected in SAS 9.4 M4, and there is a Hot Fix for M2
and M3.
Change 36.127 Support for ZERT SMF type 119 subtype 12 creates datasets
EXT11912 DDDDDD Dataset Description
EXT119C1 T11912 TYP11912SUM ZERT 12 SUMMARY
EXT119C2 T119C1 TYP11912TLS ZERT 12 TLS
EXT119C3 T119C2 TYP11912SSH ZERT 12 SSH
EXT119C4 T119C3 TYP11912IPSEC ZERT 12 IPSEC
FORMATS T119C4 TYP11912DN ZERT 12 DISTINGUISHED NAME
IMAC119
VMAC119
VMXGINIT
Jul 3, 2018
Thanks to Rodger Foreman, Black Knight, USA
Thanks to Luis Mendoza, Black Knight, USA
Change 36.126 Variables added to dataset TYPE70:
VMAC7072 SMF70MDL_CBP SMF70MCR_CBP SMF70NCR_CBP SMF70LAC_CBP
Jul 2, 2018 SMF70CPA_ACTUAL_CBP
Change 36.125 Variable SRDGCOMM was replaced by SRDGNAME, but due to
VMACSRDF use of SRDGCOMM in existing reports, both are kept now.
Jun 29, 2018
Thanks to Joe Faska, DTCC, USA.
Change 36.124 SMF 42 Subtype 5 ABEND, more invalid LENSR=560/640.
VMAC42 As reported in Change 36.027, APAR OA54663 corrects.
Jun 29, 2018 MXG circumvention extended to protect these values:
IF LENSR IN(232,240,320,376,400,448,480,560,640)
THEN LENSR=160;
LENSR=376 added Oct 15 in Change 36.124.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 36.123 Error Documentation: BMC's CMF SMF 74 Subtype 8 SMF74IET
VMAC74 field is incorrect, and causes R748AEBC to be invalid.
Jun 26, 2018 BMC1316 corrects. NO MXG CODE CHANGE.
Change 36.122 Examples in comments for both z/OS and ASCII execution
SAGANAL are revised and enhanced to create HTML output files in
Jun 22, 2018 either a PDSE or in a ZFS File System or ftp to MXG.
Jul 6, 2018 The KEEP CPI: CPU: replaced by specific list of TYPE30_V
Jul 22, 2018 variables, reducing kept from 1533 to the intended 64.
Thanks to Tennie Olson, TIAA,USA.
Change 36.121 If you specified READDB2(IFCIDS=ALL), dataset DB2STATS
READDB2 wasn't created; circumvent with (IFCIDS=ALL STATISTICS).
Jun 16, 2018 MXG 35.03-36.05.
Thanks to Hans Coolen, Allianz Technology, THE NETHERLANDS.
Change 36.120 Support for BVIR History HSM Compression Container V412
EXBVR303 creates new dataset:
FORMATS DDDDDD Dataset Description
VMACBVIR BVR303 BVIR303 HSM COMPRESSION CONTAINER
Jun 16, 2018 and new format MGBVIME decodes Compression Method
Thanks to Bradley Leis, TELUS, CANADA.
====== Changes thru 36.119 are in MXG 36.05 dated Jun 13, 2018==========
Change 36.119 -Formats MG119CI and MG119MA did not decode new values for
FORMATS variables SSH_CIPHER and SSH_MAC in TYP11994 & TYP11995,
VMAC119 and protection for unknown values prints the $HEX4 value.
Jun 13, 2018 -New variable T119RCID='RECORD*ID' added to all datasets.
Change 36.118 Support for TANDEM TMF data creates new TANDTMF dataset.
EXTANTMF DDDDDD DATASET DESCRIPTION
IMACTAND TANTMF TANDTMF TMF TRANSACTION DATA
VMACTAND
VMXGINIT
Jun 11, 2018
Thanks to Kurt Gramling, TSYS, USA.
Change 36.117 SORTBY= is not a valid option for the PMAUD02 trace
ANALDB2R report. If you happened to specify QWHSSSID it worked
Jun 11, 2018 but that was a coincidence. Now produces a message to
tell you and sets SORTBY to QWHSSTCK QWHSSSID.
Change 36.116 STCVSM11 variables NIO and CUB in VSM6 are now bytes so
VMACSTC new variables are created with B added as last character.
Jun 13, 2018 The previous code did not initialize the six calculated
Jun 15, 2018 variables, causing their sum to be greater than the CUB
Jun 22, 2018 and NIO variables; that is corrected.
Jul 2, 2018 -Jun 15: First 36.05. Two Debugging PUTLOGs removed.
-Jun 22: Test to identify VSM6 vs earlier now tests for
VSM6 or ELSE DO; for any other STC11VTS name value.
-Jul 2: Test to identify VSM6 now tests STC11CSP for
values of 1000 or 8000 based on this site's values for
STC11INM to modify that test:
PROC SORT DATA=STCVSM11;
BY STC11CSP;
PROC FREQ;
TABLES STC11CSP*STC11TOL/NOROW NOCOL NOPERCENT;
TITLE STCVSM11 TABULATIONS;
RUN;
PROC FREQ;BY STC11CSP;
TABLES STC11INM*STC11TOL/NOROW NOCOL NOPERCENT;
TITLE STCVSM11 TABULATIONS;
RUN;
PROC MEANS N MIN MAX SUM; BY STC11CSP;RUN;
Thanks to Randy Hewitt, DXC, USA.
Change 36.115 Unused Change Number.
Change 36.114 DB2ACCTR dataset has been misaligned when QLACOFF1 is not
VMACDB2 zero, i.e. if QLACLOCN field is longer than 16 bytes, and
Jun 10, 2018 there is more than one QLAC segment, due to 2 undoc bytes
in the second and subsequent segments, but it was only
INVALID DATA FOR QLACCPUL/QLACDBWT messages that exposed
the error - no user had reported the bad QLACxxxx values,
suggesting DB2ACCTR has not been important nor used!
And those QLAC variables are also kept in DB2ACCT, but
only from the LAST QLAC segment, because originally there
was only one QLAC segment.
Option a: Leave the QLAC variables in DB2ACCT as-is
with this documentation that they are only
from the last segment.
Option b: Set all QLAC variables in DB2ACCT missing
but keep them; dropping existing variables
by MXG is unsafe because it could cause
an ABEND with VARIABLES NOT FOUND if you
have an old report that references then.
I have NOT chosen this option.
Option c: Create macro _DRPQLAC listing all QLAC vars
kept in DB2ACCT so you can add
MACRO _KDB2ACR DROP=_DRPQLAC %
in your IMACKEEP to always drop them from
DB2ACCT, or use you can use
%LET MACKEEP=
MACRO _KDB2ACR DROP=_DRPQLAC % ;
in the //SYSIN of your DB2ACCT create job.
MACRO DRPQLAC is created and available, but
it does not drop QLACLOCN,QLACCNVR due to
references to those variables in others.
Thanks to Scott Wiig, US Bank, USA.
Change 36.113 Incorrect test for GE 526 corrected to GE 538 to input
VMACDB2 QPAC_PIPE_WAIT and QPAC_PIPE_COUNT to correct those two
Jun 5, 2018 variable's values.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.112 Support for Dell EMC Mainframe Enablers 8.30, previously
EXSRDF02 SRDF, Symmetric Remote Data Facility, creates separate
EXSRDF03 datasets for each subtype:
EXSRDF04 DDDDDD DATASET DESCRIPTION
EXSRDF06 SRDF02 SRDFA02 TOLERANCE MODE CHG
EXSRDF07 SRDF03 SRDFA03 ACT CHANGE
EXSRDF08 SRDF04 SRDFA04 SECONDARY DELAY
IMACSRDF SRDFAA SRDFAA REGULAR INTERVAL 05
VMACSRDF SRDF06 SRDFA06 RECULAR MSC INTERVAL
VMXGINIT SRDF07 SRDFA07 WRITE PACING GROUP
Apr 27, 2018 SRDF08 SRDFA08 WRITE PACING DEVICE
Jun 5, 2018
Change 36.111 JCL examples to CPORT/CIMPORT data from WPS to SAS,
JCLCPORT and vice versa on z/OS and ASCII.
Jun 4, 2018
Change 36.110 -S0C7 Abend reading non-Extended Function VSAM dataset in
ADOCRMFV SHOWSP subroutine after Change 36.068 (MXG 36.04 only).
ASMRMFV Extended Function VSAM datasets support striping and
Jun 2, 2018 compression and extended addressability. It is an
attribute of the Data Class. LISTC ENT('dataset') ALL
command will display EXTENDED attribute if file is EF.
-Common RMFV030I and RMFV031I messages now issued for
either EF or non-EF VSAM data sets.
-Documentation Section updated to support the above
changes: Section 12 "Messages"
Thanks to Randy Shumate, RELX Group, USA
Change 36.109 INPUT X $VARYING32000 is very CPU/Elapsed expensive when
TYPENMON the maximum length of the input records is small. Adding
TYPERHEL LENGTH X $1926; reduced 111 CPU seconds to only 40, so a
TYPSNMON _NULL_ data step is added to TYPENMON to find the maximum
TYPSRHEL record length, and the INPUT NMONTEXT $VARYING32000.; is
VMACNMON replaced with this logic, using the _INFILE_ variable:
VMACRHEL LENGTH NMONTEXT $ &NMONLENGTH ;
Jun 5, 2018 NMONTEXT=TRANWRD(_INFILE_,',,',', ,');
It is the actual LENGTH of NMONTEXT that is the major
impact on CPU and Elapsed times, but on z/OS, the LRECL
has some impact, so you need to use an LRECL that is
greater than the MAXNMONLENGTH, printed on the SAS log.
The calculation of the NRWORDSIN that was needed for SAS
V8 and early WPS was revised with added CPU reduction.
The same changes are made for the RHEL/NMON processing.
Steve Bagshaw gets credit for this discovery!
Thanks to Steve Bagshaw, ITMetrics, ENGLAND.
Thanks to Steve McCulloch, TMX, CANADA.
Change 36.108 Support for RACF TOKENs REQTCRE and ADMINCII creates
VMAC80A TOKMADMINCII='TOKEN*ADMINCII'
Jun 1, 2018 TOKMREQTCRE='TOKEN*REQTCRE'
variables in TYPE80TK dataset.
Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.
Change 36.107 If you are using ROLLUPS in DB2 to reduce the volume of
ASUMUOW data then it becomes unlikely that you will get a good
VMXGUOW match between CICSTRAN and DB2ACCT. Further with some
May 31, 2018 of the more recent changes in VMAC110 other than the
class 3 wait times and counts from DB2ACCT there is
not a lot of information added to ASUMUOW from the
DB2ACCT data. To suppress the use of DB2ACCT in your
ASUMUOW invocation all you need to do is to modify the
_LDB2ACC substitution macro to point to _NULL_ as shown
in this code:
%LET MACKEEP=%QUOTE(
MACRO _YESOBS %
MACRO _NOOBS %
MACRO _LDB2ACC _NULL_ %
);
OPTIONS SOURCE SOURCE2;
%INCLUDE SOURCLIB(VMXGUOW);
_NOOBS
OPTIONS NODSNFERR NOVNFERR;
_SUOWCIC /* SORT CICSTRAN DATA */
_SUOWDB2 /* SORT DB2 DATA */
_SUOWMQ /* SORT MQ SERIES DATA */
_SUOWSPN /* CREATE ASUMUOW DATASET */
%VMXGUOW;
_YESOBS
OPTIONS DSNFERR VNFERR;
The new VMXGUOW drops the DB2ACCT variables with the
above suppression, keeping only 99 in the new
PDB.ASUMUOW, previously there were 144.
Only comments were added in ASUMUOW with this example.
Change 36.106 TYPE42DS Encryption variables were INPUT but not KEPT nor
VMAC42 labeled nor formatted:
May 31, 2018 S42AMRIB='S42AMRIB*BYTES*READ'
S42AMWIB='S42AMWIB*BYTES*WRITTEN'
S42AMRBD='READ BYTES*DECRYPTED*OR ELIGIBLE'
S42AMWBE='WRITE BYTES*ENCRYPTED*OR ELIGIBLE'
S42AMRCI='VSAM*CI-S READ OR*PHYSICAL*BLOCKS'
S42AMWCI='VSAM*CI-S WRITTEN*PHYSICAL*BLOCKS'
With the large number of TYPE42DS observations, if you
want to only select datasets with encryption counts:
%LET MACFILE=
%QUOTE(IF ID=42 THEN DO; IF SUBTYPE=6; END; );
%LET MACKEEP=
%QUOTE(
MACRO _ETY42DS
IF S42AMRBD GT 0 OR S42AMWBE GT 0 THEN DO;
OUTPUT _WTY42DS;
END;
% );
%INCLUDE SOURCLIB(TYPE42);RUN;
which will only populate TYPE42DS when bytes GT zero.
Syntax note: The original MACFILE syntax suggested
%LET MACFILE= %QUOTE( IF ID=42 AND SUBTYPE=6; );
is fine for ONLY the TYPE42 program, but if that was
used with BUILDPDB, only the 42.6 would be read, hence
the above, safer selection will pass all other SMF
records in case you want to process other records.
Thanks to David Cogar, Wells Fargo, USA.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.105 Example SYSLOG processing TYPESYSL/TYPSSYSL/VMACSYSL that
TYPESYSL was added in 34.04 renamed TYPESYSX/TYPSSYSX/VMACSYSX due
May 24, 2018 to conflict with TYPESYSL dataset created by TYPETMNT.
Change 36.104 z/OS 2.4 SMF 30 enhancement adds these fields:
VMAC30 SMF30TIH='HWM*TIOT SPACE*USED'
Jun 11, 2018 SMF30TIS='AVAILABLE*TIOT*SPACE FOR*ENTRIES'
SMF30TIU='CURRENT*TIOT*SPACE*USED'
ICN 1634 May 23, 2018.
Change 36.103 Format MGSTCCS for variable STC11CSP in STCVSM11 dataset
FORMATS has new value '8000'x='8000X:VSM6 FICON CHANNEL'.
May 23, 2018
Thanks to Randy Hewitt, DXC, USA.
Change 36.102 DB2 V11 APARS PI71903,PI84045,PI82755 added offsets _SC,
VMAC102 _PR, _INC, and _SQL to populate those fields that were
May 22, 2018 previously only in DB2 V12. MXG test changed to GE 11.1.
The timestamp variable QW0376TS in old data was invalid
(e.g. '1A6CE0BD12FCB083'x, a date in 1914!) and was set
to a missing value; now whatever is there is input so it
may still be incorrect.
Thanks to Joachim Sarkoschits, DATEV, GERMANY.
Change 36.101 Support for NDM-CDI OP (Operator Clist Record) creates
EXNDMOP NDMOP dataset.
VMACNDM
VMXGINIT
May 21, 2018
Thanks to Michael Oujesky, DTCC, USA.
Change 36.100 ACF2 Version 6.2 circumvention in Change 36.075 exposed
VMACACF2 another STOPOVER as LENLEFT was not correctly calculated.
May 23, 2018
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Mohammed Naseer, Lowe's USA.
Change 36.099 Support for RACF TOKDANAM IBMLABEL creates new TOKLABEL
VMAC80A variable in TYPE80TK dataset.
May 23, 2018
Thanks to Coen Wessels, IBM, GERMANY
Change 36.098 Format MGMOCTY, used for Information Builder's FOCUS,
FORMATS has two new values for BEGIN and END. Only FORMAT was
VMACFOCU changed, no change was made to VMACFOUU.
May 17, 2018
Thanks to Tim Hare, Hare Systems, USA.
Change 36.097 The default triplet length for CICS/TS 5.2 to detect and
VMAC110 report there are excluded fields is corrected to 365/3260
May 14, 2018 from 373/3356 (which had included optional fields).
Thanks to Paul Maradin, DXC, USA
Thanks to Larry McCulley, DXC, USA
Change 36.096 Line seven should have two periods, &PDBMXG..ACF2AR.
ANALACF2
May 14, 2018
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.095 The %LET MXGABND=nnnn; option to abend instead of error
VMACBBMQ is added to the BBMQ processing. See Change 21.384.
May 11, 2018
Change 36.095 New 4-digit example format in tailoring IMACSMFF fails on
IMACSMFF WPS Version 4, under investigation, but add the comments
May 9, 2018 as shown here to circumvent:
/* COMMENT OUT - DEFAULT BREAKS WPS V4
'2047.000'='2047.000:MAX VALUE AND LABEL NO SUBTY'
'2047.001'='2047.001:MAX VALUE LABEL WITH SUBTYPE'
END COMMENT */
The default IMACSMFF is always executed when SMF is read.
Change 36.094 MXG 35.12-36.04. If you use IMACFMTS to add your site's
FORMATS own FORMATs, the RUN; statement in member FORMATS after
Apr 10, 2018 the VALUE $MGRMVOS statement should NOT have been added.
Thanks to Robert Debartolo, Cognizant, USA.
Change 36.093 CICS Dispatcher Statistics CICDS dataset, DSGTMADQ was
VMAC110 too large; field is now input &PIB.4.2 with two decimals.
Apr 9, 2018
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.092 ACCTSORT=NO was not working as advertised. The datasets
READDB2 ended up in WORK rather than PDBOUT.
Apr 9, 2018
====== Changes thru 36.091 are in MXG 36.04 dated May 8, 2018==========
Change 36.091 If DB2ACCT existed but had 0 OBS input was set to _NULL_
VMXGUOW resulting in many UNITIALIZED variable messages. VMXGUOW
May 7, 2018 now checks only for the existence of the dataset and if
it does not exist sets it to _NULL_.
Change 36.090 If you tailored IMACDB2 to redefine MACRO _Lxxxxxx's and
ANALDB2R you specified only a single level name, so those datasets
May 3, 2018 are written to WORK, and did not specify a PDBOUT,
you could get this syntax error
ERROR: THE FUNCTION COMPBL REFERENCED BY THE %SYSFUNC
OF %QSYSFUNC MACRO FUNCTION HAS TOO FEW ARGUMENTS.
due to incorrect logic, now corrected, in ANALDB2R.
Originally posted to MXG-L as possible issue with SAS
V9.3 to V9.4 migration, the thread was updated/corrected.
Change 31.104, MXG 31.03, May 2013, created the exposure;
the user's good run was with MXG 31.01.
Thanks to Dennis Longnecker, State of Washington Courts, USA.
Change 36.089 APAR OA54884 for z/OS 2.3 ONLY reports very high I/O EXCP
DOCUMENT counts in EXCPTOTL (Address Space Total, SMF30TEX) that
May 1, 2018 was observed in the MASTER address space, but could occur
in any address space.
Change 36.088 SAS Note 51008 Java versions 1.6/1.7/1.8 can cause errors
DOCUMENT ERROR: The Java proxy could not create a new xxxxxxxx.
May 1, 2018 ERROR: shmag() failed in Java extension rc -1 errno 124
ERROR: Unable to attach current thread.
on z/OS. That Note the circumvention is to add this line
JREOPTIONS=(
-Djava.lang.ClassLoader.lazyInitialization=false)
to your SASHLQ.CONFIG(SITE) configuration PDS member.
SAS Support reported SAS does not support Java 8 yet;
see also SAS Note 51195.
Change 36.087 Unused Change Number.
Change 36.086 DCOLLECT Encryption Variables are now kept in DCOLDSET:
VMACDCOL indicates if the LCU contains at least one FICON channel.
Apr 24, 2018 DCDTYPE ='ENCRYPTION*TYPE'
May 20, 2019 DCDKLBL ='ENCRYPTION*KEY*LABEL'
The IBM Documentation does not provide DCDTYPE values to
decode. These fields were added by z/OS 2.3.
-Unfortunately, DCDTYPE was changed from CHAR to NUM in
this change, which will cause ERROR BOTH CHAR AND NUM
if you merge PDBs built with this change with earlier
PDBs. You can use MACRO _KDCODSN DROP=DCDTYPE= % in
your SYSIN in your TYPEDCOL job to eliminate the conflict
to circumvent this badly designed change. May 20/2019.
Thanks to Mike Creech, Black Knight, USA.
Thanks to Robert Hamilton, Fifth Third Bank, USA.
Change 36.085 Variable IOPDSTX is now kept in TYPE78IO dataset; bit 1
VMAC78 indicates if the LCU contains at least one FICON channel.
Apr 24, 2018
Thanks to Lane Thorne, Honda of America Manufacturing, USA.
Change 36.084 Dataset STCVSM11 variables added by Change 34.237 were
VMACSTC incorrectly labeled and inconsistent, now corrected:
Apr 23, 2018 STC11NHR='HOST*INTERFACE*I/OS'
STC11NHW='HOST*INTERFACE*CUBUSY*DURATION'
STC11NRR='REMOTE*INTERFACE*I/OS'
STC11NRW='REMOTE*INTERFACE*CUBUSY*DURATION'
STC11NIR='IP*INTERFACE*I/OS'
STC11NIW='IP*INTERFACE*CUBUSY*DURATION'
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.083 EXPDBINC EXPDBVAR EXPDBCDE can now be used with UTILBLDP
UTILBLDP and BUILDPDB=NO so you can create your own custom dataset
Apr 27, 2018 with control of variables, etc. This example creates the
PDB.SMFHEADER dataset with four variables kept from every
SMF header:
%UTILBLDP(USERADD=ID 118,BUILDPDB=NO,
EXPDBVAR=PDB.SMFHEADER
(KEEP=SYSTEM SMFTIME ID SUBTYPE),
EXPDBCDE=OUTPUT PDB.SMFHEADER;,
OUTFILE=INSTREAM
);
%INCLUDE INSTREAM;
-Unrelated, unprintable '08'x character introduced 35.09
is removed.
Thanks to Randy Hewitt, DXC, USA.
Change 36.082 Correction for DB2 BPHITRAT variable to replace the sum
VMACDB2 of RIO/SPP/DPP/LPP with DIO/LIO/RIO/SIO.
Apr 19, 2018
Change 36.081 Support for four-digit SMF Record Type ID (MAX 2047) for
ANALID the ANALID report.
FORMATS -Format $MGSMFID text shifted one byte to the right; a few
IMACSMFF record descriptions lost 1 character to keep 37 maximum.
VMACID -VMACID,VMACSMF formats are now SMFIDSUB $8. SMFIDCH $4.
VMACSMF increasing the LENGTH of those variables by one byte,
Apr 23, 2018 format 7.3 references are changed to 8.4 for IDANDSUB.
Apr 27, 2018 -Unfortunately, if you have used IMACSMFF to label your
user SMF Record Descriptions, you will need to replicate
all and insert a blank at the beginning of each existing
3-character record type, to match the new example in that
IMACSMFF member:
'2047.001'='2047.001:MAX POSSIBLE VALUE AND LABEL'
-One line summary report with total records and bytes and
the time range of the input SMF file is added.
Change 36.080 VMXGGETM utility accepts SMF selection syntax nnnn.mmm
VMXGGETM where nnnn is the SMF Record Type (max is now 2047) and
Apr 18, 2018 where mmm is the subtype. VMXGGETM creates an output SMF
file with example records of each selected type.
Change 36.079 -Support for new SMF 119 subtypes 24, 38, 39, 40, and 45.
EXT11924 creates these new datasets:
EXT11938 dddddd Dataset Description
EXT11939 T11924 TYP11924 TNPROFILE
EXT11940 T11938 TYP11938 SmcdLnkStats
EXT11945 T11939 TYP11939 SmcdLnkStart
IMAC119 T11940 TYP11940 SmcdLnkEnd
VMAC119 T11945 TYP11945 IsmStats
VMXGINIT Untested with data.
Apr 18, 2018 -New BitRate variables added to TYP11906 dataset:
Apr 26, 2018 IFINBITRT='INBOUND*BITS PER*SECOND'
IFOUBITRT='OUTBOUND*BITS PER*SECOND'
IFBITRATE='TOTAL*BITS PER*SECOND'
-CO:Z subtypes 192 and 193 are validated with data.
Change 36.078 z/OS, SAS 9.4 M3 with IBM DFSORT, ABEND 0C4 in SASVZSR1,
CONFIGxx when sorting a large dataset. SAS notes 57676 and 58629
Apr 17, 2018 circumvent the error with these options
// EXEC MXGSAS94,OPTIONS='SORTBLKMODE SORTBLKREC=5000'
which could alternately be specified in your CONFIGxx,
but SORTBLKMODE has been the SAS Default for years. The
SORTBLKREC option is not yet documented by SAS.
http://support.sas.com/kb/57676
http://support.sas.com/kb/58629
This is documentation only, no code was changed.
Change 36.077 With a BY statement in your VMXGSUM INCODE, there is no
VMXGSUM guarantee that the data order will be correct, and if you
Apr 14, 2018 also %LET MXGSUMCLASS=YES or CLASSNWAY to YES, the data
May 8, 2018 step may fail. VMXGSUM now looks at the first word in the
INCODE= and if it is BY sets CLASSNWAY to NO.
Change 36.076 CICS Statistics Dispatcher CICDS dataset set DSGTWT to
VMAC110 DURATM when DSGTWT was greater (Change 35.264), but that
Apr 14, 2018 should only have been done for SMFSTRQT='INT' as DURATM
doesn't exist in the 'REQ', 'USS', nor 'EOD' records.
Thanks to Paul Volpi, UHC, USA.
Change 36.075 ACF2 INVALID SMF RECORD, ACSMFREL=0 VS 6.2, ERRRORABEND.
VMACACF2 MXG tests for the last release, 6.2, but new ACF2 record
Apr 14, 2018 has '00'x instead of '62'x in byte 119, causing MXG test
for 6.2 to fail. This change forces ACSMFREL=6.2 if it
is zero for this INCOMPATIBLE CHANGE to the ACF2 record.
The CA fix is PI24126 and a reassembly of DMGSMF exit.
Thanks to Michael K Yuan, Navy Federal Credit Union, USA.
Change 36.074 -Variables BETALOG in BETA50 and B97LOG in BETA9750 were
VMACBETA reversed, OFF was ON and ON was OFF, bit test corrected.
VMACBE97 -TYPEBE97 subtype 31 revised: like TYPEBETA, there can be
Apr 17, 2018 an R1 and R2 value for each FIELDNAME, but TYPEBETA PUT
May 15, 2018 the text value into a character variable for R1 and R2,
but those values were then difficult to test. TYPEBE97
instead creates nine pair of variables with true values
(like Dates, Times, HEX, etc).
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 36.073 Support for z14 ZR1 adds new variable to TYPE70 dataset:
VMAC7072 SMF70MAXPU='CORES*PHYSICALLY*AVAILABLE*THIS MODEL'
Apr 12, 2018
Change 36.072 Variables now INPUT for TYPE99_6 subtype 6 dataset:
VMAC99 PSERV ='SERVICE*DURING*INTERVAL'
Apr 12, 2018 PISERV ='ZAAP*SERVICE*DURING*INTERVAL'
PSSERV ='ZIIP*SERVICE*DURING*INTERVAL'
TIME_AT_PDP_USING='TIME AT*PDP USING*SAMPLES'
TIME_AT_PDP ='TIME AT*PDP*ACCUMULATOR'
PCT_USING_PDP ='PCT*TIME*USING*SAMPLES'
SMF996_FLAGS ='SMF996_FLAGS'
EWLM_LOCAL_PI ='EWLM*LOCAL*PI'
EWLM_GLOBAL_PI ='EWLM*GLOBAL*PI'
SMF996EWLM ='EWLM*MANAGED?'
SMF996IOPR ='I/O*PRIORITY?'
SMF996INEL ='ZIP*INELIGIBLE?'
SMF99_NUM_EXT_SC='EXTERNAL*SERVICE*CLASSES'
Thanks to Randall Schlueter, First Data, USA.
Change 36.071 IAM User SMF INPUT STATEMENT EXCEEDED because unexpected
VMACIAM short segment lengths IAMIAINL=148 (MXG expected 204) and
Apr 8, 2018 IAMIASTL=148 (MXG Expected 204) were encountered, and now
protected for these IAM 9.2 records.
Thanks to Paul Naddeo, FISERV, USA.
Change 36.070 VMXGDUR rejected INTERVAL=THREEHOUR but the warning
VMXGDUR message said that was correct. It was looking for THREEHR
Apr 8, 2018 but will now accept THREEHOUR, EIGHTHOUR, or TWELVEHOUR.
Change 36.069 Dataset CICSTRAN variables DURATM and DSGTWT were missing
VMXGCICI values in CICS Statistics SMFSTREQ='USS','REQ',or 'EOD'
Apr 6, 2018 records as the DURATM only exists in the 'INT' records.
But using the DIF(COLLTIME) a pseudo DURATM is created
and used to populate/correct DSGTWT and DURATM.
Change 36.068 -Two new enhancements.
ADOCRMFV -A new RMFBSAM record with an MXG01 id is now output
ASMRMFV for every successfully processed RMF III VSAM data set.
VMACRMFV VSAM attributes and statistics are included as well as
Apr 6, 2018 many ASMRMFV statistics and counters, and the record is
May 5, 2018 output in new dataset ZRBAS1.
May 9, 2018 -Between the existing MXG00 record and the new MXG01
record nearly all information on an ASMRMFV log is
captured. The MXG01 data becomes the ZRBASMDS (?) data
set in the result PDB.
-MXG01 records are only created for RMF III VSAM data sets
that open and close successfully. There are no MXG01
records generated for:
Empty VSAM data sets (VSAM considers this an error)
VSAM data sets that are not an RRDS type
VSAM data with an invalid CISIZE for RMF III data
VSAM data with an invalid LRECL for RMF III data
Non-VSAM data sets
The above conditions have been flagged in the ASMRMFV
Log for a long time.
-Two new parameters UPCASE/NOUPCASE control the handling
of values assigned in keyword=value usage.
-UPCASE (alias UC) is the default and provides the same
behavior as in prior ASMRMFV versions which force all
PARM and SYSIN (or alternative) input data to upper case
internally.
-NOUPCASE (alias NOUC) is the default and does not alter
any values assigned to a keyword. And thus lower case
values can be assigned to a keyword.
-However, for most (if not all) data filters currently
supported by ASMRMFV only upper case values are accepted.
For example, Sysplex Ids, System Ids, Job Names, Job
Classes, and so on are all required by IBM syntax rules
to be in upper case. Lower case values are flagged as
errors by ASMRMFV validation routines.
-NOUPCASE is a feature primarily intended for future
filtering enhancements where lower case values could
be accepted.
-NOINDEXES and/or NOSPACE parameters might not work
correctly in all situations and this has been corrected.
Messages were not always suppressed when they should
have been.
-Message RMFV105I produced for ASMRMFV Detail and
Summary reports now shows the full 5 character RMF III
table id instead of just the first 3 characters. This
change was needed to distinguish MXG00 and MXG01 output
record statistics.
-Minor changes to messages RMFV037I, RMFV041I, RMFV051*
(*= S,E,W,I), and RMFV106W.
-Several documentation Sections are updated to support
the above changes:
Section 5 "Input Data Selection Parameters"
Section 12 "Messages"
Section 31 "Summary"
Section 32 "Bibliography"
Change 36.067 z/OS, MXG's default CAPSOUT option causes lower case text
CONFIGxx to be upper cased, but MXG recommends NOCAPSOUT for ODS,
Apr 5, 2018 and the SAS default on z/OS is NOCAPSOUT. I don't know
why I changed the SAS default years ago, but "CAPSOUT" is
removed from all of the example MXG CONFIGxx members, so
your site's default value will be used.
Change 36.066 Support for "IBM Developer for z Systems IDZ" SMF 122
EXTY122A subtype 1 record creates new dataset TYPE122A. TYPE122A
IMAC122A is used because there is a TYPE122 record (that is/was?)
TYPE122A previously written by Tivoli Allocation. The Product Name
TYPS122A The Product Name field contains 'C2AE'x before and after
VMAC122A the name, where 'AE'x is the ASCII registered copyright
VMXGINIT symbol, but 'C2'x is a Danish A with a ring above! Both
Apr 4, 2018 are printed on ASCII SAS, but both are blank on z/OS, and
on z/OS lower case characters are converted to upper case
by the $ASCIIn. INFORMAT.
Thanks to Tory Lepak, Aetna, USA.
Change 36.065 AS400 7.3 QAPMDISK new fields below are now documented
VMACQACS and are added to QAPMDISK dataset, transparently.
Apr 3, 2018 MXG created the PCTCLEAN and DSFSMAPBY variables:
DSFSMAPSZ ='FREE SPACE*MAP 4K*PAGES*COUNT'
DSFSCLEAN ='CLEAN*4K PAGES*FREE SPACE*COUNT'
DSFSCLEAN0='LEVEL 0*CLEAN BLOCKS*PAGES 1-7'
DSFSCLEAN1='LEVEL 1*CLEAN BLOCKS*PAGES 8'
DSFSCLEAN2='LEVEL 2*CLEAN BLOCKS*PAGES 16'
DSFSCLEAN3='LEVEL 3*CLEAN BLOCKS*PAGES 32'
DSFSCLEAN4='LEVEL 4*CLEAN BLOCKS*PAGES 64'
DSFSCLEAN5='LEVEL 5*CLEAN BLOCKS*PAGES 128'
DSFSCLEAN6='LEVEL 6*CLEAN BLOCKS*PAGES 156'
DSFSFRAGIX='FREE SPACE FRAGMENTATION INDEX'
DSFSDIRTY ='DIRTY*4K PAGES*FREE SPACE*COUNT'
DSFSDIRTY0='LEVEL 0*DIRTY BLOCKS*PAGES 1-7'
DSFSDIRTY1='LEVEL 1*DIRTY BLOCKS*PAGES 8'
DSFSDIRTY2='LEVEL 2*DIRTY BLOCKS*PAGES 16'
DSFSDIRTY3='LEVEL 3*DIRTY BLOCKS*PAGES 32'
DSFSDIRTY4='LEVEL 4*DIRTY BLOCKS*PAGES 64'
DSFSDIRTY5='LEVEL 5*DIRTY BLOCKS*PAGES 128'
DSFSDIRTY6='LEVEL 6*DIRTY BLOCKS*PAGES 256'
PCTCLEAN='PERCENT*CLEAN*PAGES IN*FREE SPACE'
DSFSMAPBY='FREE*SPACE*SIZE*MGBYTES'
====== Changes thru 36.064 are in MXG 36.03 dated Apr 2, 2018=========
Change 36.064 All updates in the Jan, 2018, SMF Manual are included in
SMF MANUAL MXG Version 36.03, except new SMF 122, which is not in
Mar 30, 2018 that SMF Manual.
Change 36.063 DB2 V9 ONLY, zero obs in DB2STATB and other statistics
VMACDB2 datasets listed in Change 35.299, which revised deaccum
Mar 29, 2018 logic and expected one minute statistics intervals, but
that IBM Change to force the DB2 Statistics Interval to
one minute wasn't introduced until DB2 Version 10!
Thanks to Don Blaszka, Wipro Limited, USA.
Change 36.062 Further VXBYUSR logic revised to use only 2 decimals for
VMACVMXA all _MT1 DIF() functions; these data have only two digit
Apr 1, 2018 time resolution, but the divide by 4096 produced false
digits in 3rd and 4th place that, coupled with these
very large 2-complement numbers, cause MXG to falsely
detect a break in deaccumulation. See also 36.052.
Change 36.061 Invalid SYTNLPS value in SYTCUP records prevented their
VMACXAM output; pending Velocity fix, SYTNLPS=(SEGLEN-28)/20; is
Mar 20, 2018 used to calculate the actual number of segments.
Change 36.060 Support for BMC Extended Buffer Manager XBM SMF Record.
EXXBMDS -The Data Set Statistics Record can have seven OIDs:
EXXBMCA OID Variables Segment
EXXBMCC 113 xbmDSSnn Dataset Statistics
EXXBMCE 113 xbmSDSnn Snapshot Data Set Statistics
EXXBMCS 154 xbmDB2nn DB2 Statistics
IMACXBM 158 xbmSUSnn Snapshot Utilities Statistics
TYPEXBM 199 xbmVSAnn VSAM Statistics
TYPSXBM 272 xbmEPSnn Extended Prefetch Statistics
VMACXBM 242 xbmIMSnn IMS Statistics
VMXGINIT and all seven segments are output in XBMDSET dataset.
Mar 21, 2018 DDDDDD Dataset Description
Sep 9, 2020 XBMDS XBMDSET XBM Data Set Record
(Only the first four OID's have been data-validated).
-The Cache Statistics Record can have four OIDs,
1 xbmCSSnn Configuration Start Section
2 xbmCEEnn Configuration End/Stop Section
3 xbmCCCnn Configuration Change Statistics
106 xbmCACnn Cache Statistics Section
and each is output in a separate dataset:
DDDDDD Dataset Description
XBMCA XBMCACHE XBM Cache Record
XBMCS XBMCSTRT XBM Configuration Start
XBMCE XBMCEND XBM Configuration End
XBMCC XBMCHG XBM Configuration Change
-Sep 9 2020: Apparently unused, KEEP list was wrong.
Thanks to Flavio Lima, MetLife, USA.
Change 36.059 -If you specified USERADD=ID a CHAR OPERAND FOUND IN %EVAL
UTILBLDP error indicated that a numeric was needed, which was due
Mar 21, 2018 to the compiler interpreting %STR(/VIEW=ID) as a formula.
Resolved by using %QUOTE rather than %STR, like the other
references in UTILBLDP.
-The SMF AUDIT report was not being produced, now is.
Change 36.058 Missing %END in PMAUD02 corrected and BEGTIME and ENDTIME
ANALDB2R parameters enabled for MXGDB2B1 report. MXG 36.02 only,
Mar 23, 2018 introduced by Change 36.048.
Thanks to Randy Hewitt, DXC, USA.
Change 36.057 Support for z/OS 2.3 RMF Changes (SHARE Sacramento 2018):
EXTY748S -Support for APAR OA53411 for more than 65535 devices adds
FORMATS SMF74SMF bit and populates existing SMF74LSN with a flag
IMAC74 when multiple logical SMF records were created, but these
VMAC7072 variables are not kept, and don't impact MXG's reading of
VMAC74 the individual physical SMF records; the variables are
VMXGINIT available in the EXTY74 exit, if ever of interest.
Mar 26, 2018 -Support for APAR OA50760 72.3/4, was in Change 35.125.
-Support for APAR OA50761 74.10, was in Change 35.273.
-Support for APAR OA52694 72.3 TYPE72TR+ in Change 36.050.
-Support for APAR OA50762 74.9 new bit existing R749FLAG.
-Support for APAR OA50693 70.2 CEX6C/CEX6A/CEX6P Crypto
updated $MGRMFCX/$MGRMFCY/MGRMFCZ formats.
-Support for APAR OA50755 74.1 was in Change 35.193.
-Support for APAR OA50755 74.9 was in Change 35.146.
-Support for APAR OA53411 adds 74.5 vars to TYPE74CA.
R7451SRR='SYNC I/O*CACHE*READ*REQUESTS'
R7451SRH='SYNC I/O*CACHE*READ*HITS'
R7451SWR='SYNC I/O*CACHE*READ*REQUESTS'
R7451SWH='SYNC I/O*CACHE*READ*HITSS'
-Support for APAR OA53411 74.8 adds new Synchronous I/O
Link Statistics Segment that creates new TYPE748S data
set with these variables:
R748SIID='SYNC*I/O*INTERFACE*ID'
R748STYP='SYNC*I/O*LINK*TYPE'
R748SSPD='SYNC*I/O*LINK*SPEED'
R748SWDH='SYNC*I/O*LINK WIDTH*LANES'
R748SSTE='SYNC*I/O*LINK*STATE'
R7451INC='BYTES*TIME*INDETERMINABLE'
R748SCBR='SYNC I/o*CACHE*BYTES*READ'
R748SCro='SYNC I/o*CACHE*READ*OPERATIONS'
R748SCRS='SUCCESSFUL*CACHE*READ*OPERATIONS'
R748SCRT='SYNC I/o*CACHE*READ*TIME'
R748SCBW='SYNC I/o*CACHE*BYTES*WRITE'
R748SCWO='SYNC I/o*CACHE*WRITE*OPERATIONS'
R748SCWS='SUCCESSFUL*CACHE*WRITE*OPERATIONS'
R748SNBW='SYNC I/O*CACHE*WRITE*TIME'
R748SNWO='NVS*BYTES*WRITTEN'
R748SNWS='NVS*WRITE*OPERATIONS'
R748SNWT='NVS*WRITE*TIME'
-Support for APAR OA51913, z14 physical core addresses
greater than 191, was protected in MXG 31.04, which
supports the maximum possible value of 255, even though
z/OS doesn't even support 191.
-Support for Jan 2018 SMF Manual and APAR OA52003 that
added these variables to TYPE74ST Structure dataset:
R744SIAD R744SADN R744SIXC R744SXSC R744SXST R744SXSQ
R744SADO R744SADR R744SQCH R744SXFL R744SWDR R744SWAC
R744SRDR R744SRAC R744SWEC R744SREC R744SWED R744SWES
R744SRED R744SRES
R744SIAD R744SADN R744SIXC R744SXSC R744SSXT R744SXSQ
R744SADR R744SQCH R744SXFL
R744SWDR R744SWAC R744SRDR R744SRAC R744SWEC R744SREC
R744SWED R744SWES R744SRED R744SRES
-Support for Jan 2018 SMF Manual which added to TYPE74DU:
R744RSST R744RIDP R744RCPI R744RCPN R744RSGS R744RSA1
R744RSA2 R744RSA3 R744RSA4 R744RSA5 R744RSA6 R744RSA7
R744RSA8 R744RSID R744RSC R744RAMC R744RAMS R744RAMS
R744RAMP R744RAMN
Change 36.056 zHyperwrite enables DB2 to perform parallel log writes to
VMAC74 PPRC primary and secondary volumes, but they are the same
VMAC79 4-hex-digit DEVNR, and because they can be concurrently
Mar 15, 2018 active, RMF Reports now display 5-hex-digit DEVNR, with
the first nybble containing the SubChannel ID, 'sdddd'X,
where the SubChannel ID is 0,1,2 or 3. No change was made
to the SMF 74/79 records, as the SubChannel ID is already
in those records, and the 5-hex-digit display is only in
RMF reports/data: they won't exist in other SMF records.
MXG variable DEVNR5HEX is created in TYPE74, TYPE74CA,
TYPE748 and TYPE796 as DEVNR5HEX=65536*SMF74SCS+DEVNR
with FORMAT DEVNR5HEX HEX5. format.
Change 36.055 New TYPE8231 dataset was misaligned and the VMXGINIT for
VMAC82 _WTY8231 thru _WTY8247 was corrected to write to WORK
VMXGINIT rather than to PDB.
Mar 13, 2018 -Mar 20: Invalid Subtype 31 with only 4 bytes for 0203 TAG
Mar 20, 2018 encountered, circumvented, and reported to IBM.
Apr 12, 2018 -Apr 12: MXG's problem was that the SMF82_TRIPL_LENGTH
field was presumed to be the length following it, but it
was 8 with when 4 bytes remained, so I presumed there was
truncated data for the TAG 0203 segment. IBM Support
responded with a very detailed decoding of the record
with their utility that matched MXG's values, concluding:
"To sum up, the length of 08 that you are referencing
does not mean that 8 bytes will follow. It means the
length in the record is composed of the length of the
data item (4 bytes) plus the length of the tag and
size info (another 4 bytes)."
While TAGs have different lengths, since each TAG's
length is fixed, MXG did not need to use that field,
so no MXG code change was required, and no data was
truncated.
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Thanks to David A. Hilliard, IBM Support, GERMANY.
Change 36.054 A missing paren caused BLDSMPDB to fail, and %macro
BLDSMPDB &PDBPATH was not initialized in PDBAUDIT. BLDSMPDB only
PDBAUDIT failed when MTD was used which then caused SAS to set
Mar 13, 2018 OBS=0 and caused PROC SQLs in PDBAUDIT to then fail.
PDBAUDIT is now protected for the 0 OBS case
Thanks to Harold Zbiegien, American Greetings, USA.
Change 36.053 INTBTIME and INTETIME variables are now all DATETIME25.6
BUIL3005 formatted, even though only those INPUT with TODSTAMP8
BUILD005 will have all six decimals populated, SMFSTAMP informat
SMFINTRV only has 2 decimals. INTETIME in SMF 91 with TODSTAMP8
VMAC30 informat forced the format change, since you can't have
VMAC91 different formats for the same variable name in datasets
Mar 8, 2018 created in the same DATA step.
Thanks to Randy Hewitt, DXC, USA.
Change 36.052 Revision to z/VM VXBYUSR logic to correct large values
VMACVMXA in many deaccumulated durations when there were multiple
Mar 7, 2018 logon values in CALTODON for the same user, and/or when
a guest has been relocated. Logic to recalculate DELTATM
from HFRATE*HFQCNT was causing output of first instances,
so it was removed. A heuristic was added to test that
the record DELTATM was not more than 2*INTERVAL since
that also detects a return of a relocate to delete.
See Change 36.062.
Thanks to Graham Harris, RBS, ENGLAND.
Change 36.051 Support for AS/400 Version 7.3 Collection Services.
VMACQACS -New GDES fields added to QAPMCONF dataset for keys
Mar 7, 2018 FL PM TY TZ T1 T2 T3 T4 U1 U2 U3 U4 XS
Mar 16, 2018 -New DATETIMECH,UTCTIMECH 26-character datetimes and
Mar 23, 2018 DSQUEOPS counter added to QAPMDISK record, which now
Mar 26, 2018 has LRECL=751 (YOU MUST SET IN YOUR JCL/FILENAME).
See change 36.065.
The 26 character format is YYYY-MM-DD-HH.MI.SS.999999
====== Changes thru 36.050 are in MXG 36.02 dated Mar 5, 2018=========
Change 36.050 TYPE72GO variables R723CPA_ACTUAL and R723CPA_SCALING
VMAC7072 added by APAR OA52694, were trashed because they were
Mar 2, 2018 input when they shouldn't have been; the test for INPUT
Mar 6, 2018 should have been GE 276 instead of repeated GE 268.
Mar 6: New variable ORG70CPA was added to TYPE70 and
TYPE70PR, but the label statement had OGT70CPA causing
a harmless UNINIT variable message on the log.
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 36.049 Change 35.200 left off the trailing / or ] on the
VGETALOC directory names if you did not supply it and it could
Mar 2, 2018 result in no allocations and a failure of a following
VMXGSET. Now if we don't find the / or \ we supply it.
Thanks to Richard Krueger, Sentry, USA.
Change 36.048 For PMAUD02 report SORTBY use is restored, but the first
ANALDB2R variable in the list must be QWHSSSID, and variables not
Mar 2, 2018 in the below list will terminate with error messages.
The default values are QWHSSSID QWHSSTCK; if that first
variable is not DB2 or QWHSSSID, QWHSSSID is inserted.
Allowed variables are:
DB2 - THE DB2 SUBSYSTEM ID
PLAN - THE DB2 PLAN NAME
AUTHID - THE AUTHORIZATION ID
CONNID - THE CONNECTION ID
CONNTYPE - THE CONNECTION TYPE
CORRID - THE CORRELATION ID
QWHSSSID - THE DB2 SUBSYSTEM ID
QWHCPLAN - THE DB2 PLAN NAME
QWHCAID - THE AUTHORIZATION ID
QWHCOPID - THE ORIGINAL AUTHORIZATION ID
QWHCCN - THE CONNECTION ID
QWACATYP - THE CONNECTION TYPE
QWHCCV - THE CORRELATION ID
QWHSSTCK - THE TIME OF THE EVENT
Thanks to Scott Swindling, PREMERA, USA.
Change 36.047 Support for XCOM Version 12.0 (COMPATIBLE) adds variables
VMACXCOM XCOMGWDP='GATEWAY*DPATH'
Feb 28, 2018 XCOMSSLT='SSL*VERSION'
XCOMCIPHN='SSL*CIPHER*NAME'
XCOMRCNT='RESTART*COUNT'
XCOMPLEXQ='ORIGIN*PLEXQ*GROUP*NAME'
Thanks to Alfredo Antonio Gonzalez Ortega, ITNOW, SPAIN
Thanks to Sergi Vilaseca Punti, ITNOW, SPAIN
Thanks to Miguel Fco. Monferrer Carvajal, ITNOW, SPAIN
Change 36.046 Support for NDM Version 5.2 corrects NDMCPU and adds
VMACNDM these variables to the NDMCT dataset:
Mar 1, 2018 NDMCLASS ='PROCESS*SESSION*CLASS'
Apr 6, 2018 NDMCTFLAG17='FASP17*OVERRIDE*TO FASP=NO'
NDMCTFLAG18='FASP18*OVERRIDE*TO FASP=NO'
NDMCTGPF ='GENERAL*PURPOSE*FLAG'
NDMDBLKSZ ='DESTINATION*BLKSIZE'
NDMDDSORG ='DESTINATION*DSORG'
NDMDLRECL ='DESTINATION*LRECL'
NDMDRECFM ='DESTINATION*RECFM'
NDMFASPBW ='FASP*BANDWIDTH*KBITS'
NDMFASPFT ='FASP*FILESIZE*THRESHOLD'
NDMFASPPL ='FASP*POLICY'
NDMPNRLS ='PNODE*C:D*VERSION'
NDMSBLKSZ ='SOURCE*BLKSIZE'
NDMSDSORG ='SOURCE*DSORG'
NDMSLRECL ='SOURCE*LRECL'
NDMSMFID ='SMFID*THAT*CREATED'
NDMSMRLS ='SNODE*C:D*VERSION'
NDMSRECFM ='SOURCE*RECFM'
NDMSTEPOS ='STEP*OFFSET*IN*TCQ'
NDMUSERN='USER*SENSE*FROM*FMH71'
NDMXDATE ='PROCESS*STOP*DATE'
NDMXTIME ='PROCESS*STOP*TIME'
NDMZFLAG='Z*FEATURE*FLAGS'
NDMZWINR ='COMPRESSION*WINDOW*SIZE'
-Apr 6: Reported Truncated CERI and CERT to IBM.
-Apr 16: IBM APAR PI24126 corrects the truncation,
but makes no mention of the truncation. That fix
required reassembly of DGMSMF.
Thanks to Heimir Hauksson, Barclays Technology Center, ENGLAND.
Thanks to Robert Richards, OPM, USA.
Thanks to Walter J Freeman, OPM, USA.
Thanks to Otto A. Burgess, OPM, USA.
Change 36.045 Support for enhanced Mobile Work 4HOUR MSU reporting.
FORMATS -New parameter, TYPE=, for the type of mobile work, to
MOBMWRT be added to your %MOBMWRT invocation in your MOBWRKxx
MOBWRK72 tailored members, where TYPE=DB2 CICS IMS WAS or MQ to
MOBWRK73 create the WORK.MWRT_BLD_SUM_&TYPE dataset that is then
MOBWRKMS used to create the new MOBILE.MSU_&TYPE dataset with the
Feb 28, 2018 4 hour rolling average MSU for that &TYPE of workload.
-MOBWRKMS provides reporting on the new &TYPE datasets.
-Some improvements in SMF70CPA calculation in MOBWRK73,
and ORIGCPUTM/CPUCPONLY/CICDSCPUTM are init to missing
in MOBWRK72.
-FORMAT mwrtdt is enhanced to support years beyond 2042.
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 36.044 The value you set in MACRO _IMSVERS mm.n % is now kept
VMACIMS in variable IMSVERS in IMS0708 and IMS07 datasets.
Mar 1, 2018 (The IMS56FA transaction dataset already has IMSVERSN
that is created from that IMS log record.)
Thanks to Alfredo Gonzalez, La Caixa, SPAIN.
Change 36.043 Initial support for NMON Nigel's Monitor for RHEL Release
EXRHELAA 14i with Red Hat Enterprise Linux 6.7.
EXRHELBP The data with 1 second interval is suspect as the times
EXRHELCI of the interval are often 2 or 3 seconds apart.
EXRHELME The developers page is at 'http://nmon.sourceforge.net'
EXRHELNS The BBBP fields are not currently decoded since the RHEL
EXRHELCD text is not consistent with the NMON contents.
EXRHELDS -Mar 6: FULLCOMD in RHELUARG expanded to 4096 bytes and
EXRHELIN WORK dataset CPUBUSY is deleted; the values of CPU_ALL
EXRHELJF variables are output in RHELINTV Interval Dataset.
EXRHELNT
EXRHELTO DDDDDD MXG MXG
EXRHELUA DATASET DATASET DATASET
EXRHELMT SUFFIX NAME LABEL
IMACRHEL
TYPERHEL RHELAA RHELAAA RHEL MONITOR AAA CONFIGURATION
TYPSRHEL RHELBP RHELBBBP RHEL MONITOR BBBP CONFIGURATION
VMACRHEL RHELCI RHELBBBPCPUINFO RHEL BBBP CPUINFO
VMXGINIT RHELME RHELBBBPMEMINFO RHEL BBBP MEMINFO
Mar 1, 2018 RHELMT RHELBBBPMOUNT RHEL BBBP MOUNT
Mar 6, 2018 RHELNS RHELBBBPNETSTAT RHEL BBBP NETSTAT
Mar 14, 2018 RHELCD RHELCPUD RHEL CPU DETAIL
Mar 28, 2018 RHELDS RHELDISK RHEL DISK
Apr 6, 2018 RHELIN RHELINTV RHEL MONITOR INTERVAL
RHELJF RHELJFSF RHEL JFSFILE
RHELNT RHELNETW RHEL NETWORK
RHELTO RHELTOP RHEL TOP PROCESS
RHELUA RHELUARG RHEL UARG PROCESS
-Apr 6: RHELAAA now output for each concatenated input
file; only the first was output previously.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Thanks to Andreas Windisch, HUK-COBURG, GERMANY.
Change 36.042 ANALCAPD ERROR: FOUND "IF" when expecting ... when the
ANALCAPD CEC= options was used, due to a missing semicolon.
Feb 22, 2018
Thanks to Norbert T. Wagner, Deutsche-Boerse, GERMANY.
Change 36.041 The MXGERROR:MISSING TYPE70 message is now MXGWARN:MISS
VMXG70PR because it's only an alert to be examined (Change 36.026)
Feb 20, 2018 to see if the SYSTEMs listed are the systems of interest.
Only variables in dataset ASUMCELP observations for those
LPARs whose 70s were not read are impacted, and in many
cases the message is generated because the SMF data from
a sandbox LPAR was not present in that day's SMF input.
These variables will have missing values in PDB.ASUMCELP;
SMF70CPA SMF70LAC SMF70PAT SMF70WTI SMF70WTS SMF70WTI.
Thanks to Ed Wieszczek, Zions Bank Corporation, USA.
Change 36.040 Support for IMS 56FA Record APAR UI50912. COMPATIBLE as
VMACIMS it uses a reserved field for the new TPCEXTOF offset to
Feb 19, 2018 the TPCE DSECT, but TPCEXTOF is zero so the extension
is not populated by THIS APAR, so it is also not input.
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 36.039 Enhancement to dataset TYPE70PR creates new LPARZIPS with
VMAC7072 the number of online ZIIP engines for each LPAR for each
Feb 19, 2018 interval.
Thanks to Kurt Gramling, TSYS, USA.
Change 36.038 The MXG "INVALID SMF 119 TYPE 81" message in MXG 36.01
VMAC119 bypassed an INPUT STATEMENT EXCEEDED LENGTH ERROR ABEND,
Feb 19, 2018 but I had misunderstood the DS_DOOFF offset to be the
offset into the SMF buffer to the DORU field; IBM L3
Support corrected me: it is the offset into the RU that
will be moved into the DORU field, if the DORU is larger
than 4096 bytes, so that the anomaly's data will be in
in the SMF record. The circumvention is removed and the
DORU variable is correctly populated.
-Variable IST119DS_SID was changed from numeric to char
with $HEX16. format.
Thanks to Gary Zaetz, IBM z/OS Communications Server Support, USA.
Thanks to David Campbell, SUNTRUST, USA.
Change 36.037 Variable QWHSACE was missing from the BY list for dataset
VMACDB2 ZZDB2SBP causing READDB2/TYPEDB2/BUILDPDB to ABEND with
Feb 19, 2018 INPUT STATEMENT EXCEEDED. This code has been executing
and accidentally working since MXG 35.10, last year,
before two site's data records with multiple QWHSACEs
exposed my coding error.
Thanks to Lori A Stratford,The Auto Club Group AAA Michigan, USA.
Thanks to Kare Martin Torsvik, IBM Services, NORWAY
Change 36.036 Support for new Subtype 31 SMF 82 JOB-level crypto stats.
EXTY8228
EXTY8229
EXTY8230
EXTY8240
EXTY8241
EXTY8242
EXTY8243
EXTY8244
EXTY8245
EXTY8246
EXTY8247
IMAC82
VMAC82
VMXGINIT
Feb 14, 2018
During testing of this update, Error Message UNDECLARED
ARRAY YPE8231 (note T is missing) was caused by VMXGINIT
typo setting PTY8231=DEFAULT instead of setting WTY8231.
Just a developers note as for that " YPExxxx" error text
shows up in testing from time to time.
Change 36.035 If the last engine type in an LPAR was an IFL, the MXG
VMAC7072 calculation of LPARSHAR/LPARSHAC and LZIPSHAR/LZIPSHAC
Feb 14, 2018 was incorrect in the TYPE70 dataset.
Thanks to Andrew Petersen, DXC, AUSTRALIA.
Change 36.034 Some debugging options added when MXGEXIMSG=YES and a bad
VGETOBS branch to end modified so that if the dataset you seek
Feb 14, 2018 does not exist and debugging is on you will get the
message that it did not exist.
Change 36.033 Analysis of different I/O counts between SMF 42 subtype 6
ANAL4274 and type74 subtype 1.
Feb 13, 2018
Change 36.032 WebSphere INVALID Subtype 9 messages were cause by the
VMAC120 absence of ELSE clauses that are now corrected.
Feb 12, 2018
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 36.031 INVALID DB2 RECORD CREATED BY ASG/TMON is NOT an ASG
VMACDB2H issue, but rather is due to BMC APPTUNE SMF 102 records
Feb 11, 2018 with Data Sharing Group sections that were incorrectly
decoded by MXG logic, now corrected. The ERROR is real
in that observations were NOT output in some datasets.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 36.030 Old-style substitution macro _HSMINTV added so you can
ASUMHSM easily change the default HOUR interval to you choice.
Feb 6, 2018 If you want the interval to be QTRHOUR and the final
output written to dataset HSM.QTRHOUR, you would use:
%LET MACKEEP=%QUOTE(
MACRO _LSUHSM HSM.QTRHOUR % /* SETS OUTPUT DSN */
MACRO _HSMINTV QTRHOUR % /* SETS INTERVAL */
);
%INCLUDE SOURCLIB(ASUMHSM);
Thanks to Randy Hewitt, DXC, USA.
Change 36.029 Variables SM120RULEXFBOM/DEB/MON/FTRC are one-bit fields
VMAC120 that MXG incorrectly INPUT as one-byte variables.
Feb 8, 2018
Thanks to Paul Volpi, UHC, USA.
Thanks to Jack Hyde, UHC, USA.
Change 36.028 Change 35.124 introduced code that stopped PDBAUDIT with
PDBAUDIT a memory limitation problem with WPS when more than 20
Feb 8, 2018 LIBNAMEs were found. Change 35.201 then accidentally
circumvented that error by removing duplicate entries,
but the real error was that DICTIONARY.MEMBERS returned
all libname.member entries, (THOUSANDS in MXG QA JOB),
rather than the LIBNAME entries from DICTIONARY.LIBNAMES.
The error message is inactive.
Thanks to Earl Kline, Luminex, USA.
Change 36.027 More invalid LENSR=304 and 448 for SMF 42 Subtype 5;
VMAC42 IF LENSR IN(232,240,320,400,448,480) THEN LENSR=160;
Feb 8, 2018 The line was also moved up to after the DO because
those large values with lots of SR segments caused the
MXG test for INVALID SR Length exceeds record length.
The correcting APAR number is OA54663, but it did not
acknowledge the multiplicity of incorrect values when
it "Updated SMF42SRL to contain only length of SMF4205A".
Thanks to Luis Mendoza, Black Knight, USA.
Thanks to Lori A Stratford,The Auto Club Group AAA Michigan, USA.
====== Changes thru 36.026 are in MXG 36.01 dated Feb 6, 2018=========
Change 36.026 MXGERROR:MISSING TYPE70 RECORDS impacts ASUMCEC/ASUMCELP
VMXG70PR datasets, with some incorrect values in those datasets
Feb 5, 2018 when those messages are printed, not just SMF70LAC, when
either the data from a system is not input, or if your
LPARNAME/SYSTEM/SYSNAME/SMF70STN names are inconsistent.
Change 35.144 introduced the message and provided a way
if your SMF70STN matches LPARNAME, but you may need the
below logic to create consistent names.
%LET INCODE70FOR70PR=%QUOTE(
LENGTH SMF70STN $8;
IF SYSNAME='ZUT1ACP1' THEN SYSTEM='ACP1';
ELSE IF SYSNAME='ZUT1DEV1' THEN SYSTEM='DEV1';
ELSE IF SYSNAME='ZUT1PRD1' THEN SYSTEM='PRD1';
IF SYSNAME='ZUT1ACP1' THEN SYSNAME='ACP1';
ELSE IF SYSNAME='ZUT1DEV1' THEN SYSNAME='DEV1';
ELSE IF SYSNAME='ZUT1PRD1' THEN SYSNAME='PRD1';
IF SMF70STN='ZUT1ACP1' THEN SYSTEM='ACP1';
ELSE IF SMF70STN='ZUT1DEV1' THEN SYSTEM='DEV1';
ELSE IF SMF70STN='ZUT1PRD1' THEN SYSTEM='PRD1';
IF SMF70STN='ZUT1ACP1' THEN SMF70STN='ACP1';
ELSE IF SMF70STN='ZUT1DEV1' THEN SMF70STN='DEV1';
ELSE IF SMF70STN='ZUT1PRD1' THEN SMF70STN='PRD1';
IF SYSNAME='ZUT1ACP1' THEN SYSTEM='ACP1';
ELSE IF SYSNAME='ZUT1DEV1' THEN SYSTEM='DEV1';
ELSE IF SYSNAME='ZUT1PRD1' THEN SYSTEM='PRD1';
IF SYSNAME='ZUT1ACP1' THEN SYSNAME='ACP1';
ELSE IF SYSNAME='ZUT1DEV1' THEN SYSNAME='DEV1';
ELSE IF SYSNAME='ZUT1PRD1' THEN SYSNAME='PRD1';
);
%INCLUDE SOURCLIB(ASUM70PR);
These are the variables that will have missing values
in PDB.ASUMCECLP and ASUMCEC for those LPARs listed:
SMF70CPA SMF70LAC SMF70PAT SMF70WTI SMF70WTS SMF70WTI.
Thanks to Ed Wieszczek, Zions Bank, USA.
Change 36.025 Support for zVM64 Level 40061701 and 1702 INCOMPATIBLE.
VMACVMXA Changes to MTRSYS 1.04 for SKIP calculation and MTREND
Feb 6, 2018 1.11 logic required for new instance where the rest of
the record contains only nulls.
Thanks to Graham Harris, RBS, ENGLAND.
Change 36.024 Support for ThruPutManager Release/Version 18.02 COMPAT,
VMACTPMX PTF Level TMT7113, adds new variable JXJBSTXT to dataset
Feb 1, 2018 TYPETPMX, with label 'JXJBSSYSAFF*TEXT'.
Long labels and variables with blank labels corrected.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.023 Yet another ID 42 ST 5 INPUT STATEMENT EXCEEDED due to
VMAC42 yet another invalid LENSR of 232 that should be 160.
Jan 29, 2018 NOW: IF LENSR IN(232,240,320,400,480) THEN LENSR=160;
See Change 35.302 and 35.305 original invalid LENSRs.
IBM APAR OA54663 has been opened to fix the reported
problem. (Note IBM calls it "reported", apparently
until they have accepted and fixed the issue!)
Thanks to Bradley A. Foxhall, BNY, USA.
Change 36.022 Support for Liberty 8.9.1.0 SMF 120 Subtype 100 (COMPAT)
VMAC120 added two new fields to dataset TY120100:
Jan 29, 2018 SM120RULEXSIZE='RULESET*SIZE IN*NUMBER*OF RULES*/
SM120RULEXPNUM='RULESET*NUMBER OF*PARAMETERS*/
-Unknown Subtype logic added to print a hex dump if found.
Thanks to Paul Volpi, UHC, USA.
Thanks to Jack Hyde, UHC, USA.
Change 36.021 Allocation utility VMXGALOC is enhanced so that if your
VMXGALOC have specified DB2KEEP=0 or CICSKEEP=0 or SPINKEEP=0, the
Jan 25, 2018 directories are not created. This is primarily for
specialized tailoring where you want to send output data
to different directories than the normal PDB processing,
as SPIN CICSTRAN and DB2 are neither needed or desirable
with those arguments (DAILYDSN being a good example).
Change 36.020 ASCII version of JCLDAYDS that uses the SAS FTP engine to
ASCIIDSN process TMC and DCOLLECT data.
Jan 25, 2018
Change 36.019 Change to output dataset label to reflect the correct
TRNDDSNS source of the data.
Jan 25, 2018
Change 36.018 Obscure DB2 GTF file ASCII-only conversion utility to
UDB2GTFA assemble 256 byte pieces had the COL=OUTCOL that should
Jan 25, 2018 have been COL=OUTLOC, causing no output records. Was NOT
reported, accidentally discovered. But nasty to find.
Change 36.017 INVALID SMF 119 SUBTYPE 81 RECORD has IST1219DS offset
VMAC119 of 2899 and IST1219DS length of 2164 but the record is
Jan 25, 2018 only 3076 bytes long, causing INPUT STATEMENT EXCEEDED.
Test added to print MXGERROR and delete the record while
opening a problem with IBM support.
Thanks to David Campbell, Suntrust, USA.
Change 36.016 Enhancement to create optional SMFHEADER dataset with
TYPEID selected variable from the SMF header when READSMF=YES
VMXGINIT is used. These two macros (default blank) enable:
Jan 24, 2018 %LET SMFHEADERDATASET1=
PDB.SMFHEADER (KEEP=SYSTEM SMFTIME ID SUBTYPE) ;
%LET SMFHEADERDATASET2=
%QUOTE( OUTPUT PDB.SMFHEADER; ) ;
%ANALID(READSMF=YES,PRINT=YES,PDBOUT=PDB);
Thanks to Randy Hewitt, DXC, USA.
Change 36.015 Variable CPUID $EBCDIC8 ERROR when TYPEBETA and TYPE70
VMACBETA records were processed together - CPUID is a numeric but
Jan 24, 2018 VMACBETA had an incorrect/old BETA93 reference.
Thanks to Lothar Koppe, Provinzial, GERMANY.
Change 36.014 ANALHSM Report 3 Title was overlaid if BYVAL was used.
ANALHSM
Jan 22, 2018
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.013 Documentation only. APAR OA27291 corrects ABEND S0C4 if
NEWSLTRS USEZOSV1R9RULE(NO), the default, is used with Netview
Jan 22, 2018 NvDM at z/OS 1.10 or higher, in DIAGxx member of parmlib.
Thanks to Lizette Koehler, Albertsons/Safeway Stores, USA.
Change 36.012 The created GMTOFF30 value could be .01 seconds more or
VMAC30 .01 less than the exact hourly offset when SMF30IST was
Jan 22, 2018 not the same second as INTBTIME, complicated by the two
different resolutions, .01 in SMF30IST/SMFSTAMP8/local,
.000001 in the higher resolution INTBTIME/TODSTAMP/GMT,
the only source of the GMT delta in SMF 30s. This change
impacts variables ACTDLYTM EXECTM INTBTIME INTETIME and
SYNCTIME with the PROC COMPARE difference less than .01.
And note that if you have not specified SYNC in SMFPRMxx,
the TYPE30_V/SMFINTRV datasets are useless for any type
of interval totals.
Change 36.011 -MXG 35.09-36. Using %PDBAUDIT(LIBNAMES='Not _ALL_",
PDBAUDIT overriding the internal _ALL_ default, the program
Jan 19, 2018 failed with a syntax error pointing to a Paren.
-If LIBNAMES=PDB was used, and //PDB DD is tape, the
program fails with PDB.PDBAUDIT NOT FOUND, because the
option EXCLUDESEQ=YES is the default to NOT READ tape
PDB libraries. Now, if your PDBAUDIT= is on tape, and
EXCLUDESEQ=YES, the program will tell you that you must
change that to NO, so the program will report on the
contents of the tape Data Library, but there is no output
of the PDB.PDBAUDIT dataset to that tape, as that could
destroy existing datasets on the sequential mode tape.
-It is NOT recommended that you build your PDB on tape
because of performance issues: tapes have no directory
so the full tape has to be read to determine its contents
for PDBAUDIT, and worse for BUILDPDB, where datasets are
written AND read-from the //PDB, each reference has to
start at the beginning of the tape and read all data
to get to that dataset.
-If you do want your daily PDB on tape, you should write
to temp DASD for the //PDB, to eliminate the rereads, and
then PROC COPY from //PDB to tape after all your reports
were created from the temp DASD PDB. And, since this PDB
for BUILDPDB is NOT on tape, PDB.PDBAUDIT will be created
and output to the temp PDB so it is included in the copy.
-Note that if you do use EXCLUDESEQ=NO with PDB on tape,
there are no observation counts in the PDBAUDIT reports.
Thanks to Peter Ten Eyck, American National, USA.
Change 36.010 TYPE73 dataset variable CHFXRATE should have been divided
VMAC73 SMF73PTI, the corrected elapsed time, and not by DURATM.
Jan 18, 2018
Thanks to Steve Olenik, IBM, USA.
Change 36.010A Support for z/OS 2.4 SMF 89 Dataset TYPE89R2 new TRG
FORMATS variables SMF89TRGDATATYPE SMF89TRGDATACPU SMF89TRGDATA.
VMAC89 ICN1674.
Jan 16, 2019
Change 36.009 Message: INVALID TYPE 0 RECORD with LENGTH=70 was deleted
VMAC0 but that length is now valid when SMF0TBUF was added, but
Jan 18, 2018 its length was not added to the test for valid lengths.
The test for each valid TYPE 0 record length is needed
because, many times, sysprogs installing a product that
writes SMF records, incorrectly fail to set a record ID
and the product writes type 0 records, which were not
valid IPL records, and thus were deleted by MXG, with
the message. I failed to add 70 to the test.
-And, this site had records that were LENGTH=52 that are
not IPL records, accidentally written. Do you recognize
what product has values like these in that record?:
CHAR ;... 3....E09ZBLOK. .. 3....LIDPOST BLKLDPSTLOADED 52
ZONE 5003DF0101CFFECDDD0503DF0101DCCDDEE4CDDDCDEEDDCCCC44
NUMR E000B3181F509923622800B3181F394762302323472336145400
Thanks to Bruce Sloss, PNC, USA.
Change 36.008 Variable TTAPLDAT in dataset TYP11902 was mis-aligned due
VMAC119 to INPUT that should have been INPUT @OFF11905 TTAPLDAT.
Jan 15, 2018
Thanks to Bob Davidson, LloydsBanking, ENGLAND.
Change 36.007 Scott Barry posted the UTILBPV program to examine the BVP
UTILBPV cylinder value to minimize wasted space in the Cylinder
Jan 15, 2018 Managed Area using EAV Volumes, using your DCOLLECT data.
Datasets larger than the BPV value are written to the
Cylinder-Managed Space, while dataset smaller than BPV
are written to the Track-Managed Space.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.006 -CICS/TS 5.3 new CPU variables in Statistics CICM dataset:
VMAC110 MNGCPUT ='TOTAL*CPU*TIME'
Jan 15, 2018 MNGTONCP='TOTAL*CPU*TIME*ON CP'
MNGOFLCP='TOTAL*CPU*TIME*OFFLOAD*ON CP'
-Variable MNGWLMCC now tests the correct bit.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.005 -TYPE115 header variable QWHSDURN in SMF 115 subtype 231
VMACDB2H has a value that requires a divide by 4096, while that
VMAC115 same field in all other SMF 115 subtypes is microseconds.
Jan 18, 2018 -Header variable QWHSTIME and QWHSDURN are added to all
Feb 2, 2018 datasets that have the 52-byte DB2 QWHS header segment:
MQMLOG MQMBUFER MQMCHIN MQMDSP MQMADP MQMSSL MQMDNS
TYPE115201 TYPE115215, subtypes 1, 201, 215, and 213.
-Variable QIS1EXPF is INPUT and kept in TYP115201 dataset.
-The BY lists for 1155/115A/115L/115N were revised and now
duplicates are removed (the 1155 and 1156 have MANY dupes
normally).
-Variables QSSTCN64/QSSTCR64, ABOVE THE BAR CONTRACTIONS
and SHORT ON STORAGE counts added to MQMLOG dataset.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 36.004 Correction for DB2 V11 IFCID 376 INPUT STATEMENT EXCEEDED
VMAC102 STOPOVER ERROR because the code incorrectly expected the
Jan 14, 2018 V12 truncated offsets that are now unread with DB2 V11.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 36.003 -TYPE70TR TRG dataset misalignment was corrected when data
VMAC7072 records were received from IBM, but with these questions:
VMAC89 Split 70 records have a 70 TRG segment in each record,
Jan 17, 2018 and the second record's TRG data is identical.
-TYPE72TR TRG dataset has negative values for R723TSUCP:
IBM RMF replies: Negative values can occur in certain
cases. When transaction processor usage is reported to
WLM through IWM4RPT or IWM4MNTF services, the consumed
service units are accounted to the transaction service or
report classes, and deducted from the region's service
and report classes. If the number of transactions is very
small and a single transaction reports high processor
times, it can occur that processor times become negative.
R723CETSX is natively in "squared microseconds" but is
converted to "squared millisecs" to match R723CETS units.
-TYPE89 documentation had offset at 64 with length 80, but
actual offset/length are 36/52, causing the original MXG
code to not INPUT the TRG TRO/TCO segments, so datasets
TYPE80TI, TYPE89R1, and TYPE89R2 had zero observations.
-With these changes, Tenant Resource Group, TRG datasets
have been validated with data.
Change 36.002 See Change 36.135.
VMACPOEX
Jul 20, 2018
Change 36.001 TYPETCP (SMF 118) APISTART datetime was on GMT, the only
VMACTCP field with SMFSTAMP informat not on local time zone.
Jan 9, 2018 Labels with MBYTES changed to BYTES since they all use
the MGBYTES format that prints the suffix letter.
Thanks to Randy Hewitt, DXC Technology, USA.
LASTCHANGE: Version 36.
=========================member=CHANGE35================================
/* COPYRIGHT (C) 1984-2018 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 35.36 was dated Jan 8, 2018, thru Change 35.309
MXG Version 35.35 was dated Jan 3, 2018, thru Change 35.303
MXG Version 35.12 was dated Dec 26, 2017, thru Change 35.298
EA test MXG Version 35.12 was dated Dec 20, 2017, thru Change 35.294
MXG Version 35.11 was dated Dec 1, 2017, thru Change 35.279
MXG Version 35.10 was dated Nov 6, 2017, thru Change 35.255
First MXG Version 35.10 was dated Nov 6, 2017, thru Change 35.254
MXG Version 35.09 was dated Oct 2, 2017, thru Change 35.217
First MXG Version 35.09 was dated Oct 2, 2017, thru Change 35.215
MXG Version 35.08 was dated Aug 24, 2017, thru Change 35.186
MXG Version 35.07 was dated Aug 2, 2017, thru Change 35.171
MXG Version 35.06 was dated Jun 30, 2017, thru Change 35.151
MXG Version 35.05 was dated May 15, 2017, thru Change 35.121
MXG Version 35.04 was dated May 1, 2017, thru Change 35.104
\XG Version 35.03 is dated Mar 27, 2017, thru Change 35.072
First MXG Version 35.03 was dated Mar 22, 2017, thru Change 35.069
MXG Version 35.02 was dated Feb 10, 2017, thru Change 35.035
MXG Version 35.01 was dated Jan 20, 2017, thru Change 35.014
ANNUAL MXG Version 34.34 was dated Jan 3, 2017, thru Change 34.284
ANNUAL MXG Version 34.34 was dated Jan 3, 2017, thru Change 34.284
MXG Newsletter SIXTY-NINE was dated Jan 3, 2018.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 35.36 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 35.36.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG Version 35.36 dated Jan 8, 2018, thru Change 35.309.
==Major CHANGES added in MXG 35.36, dated Jan 8, 2018 thru 35.309.
ERROR Protection:
Many 35.308 SAS Defect 9.4 M5 z/OS PROC SQL NOERRORSTOP protect.
SAS Note 61672 will address, this circumvents need.
ERROR Correction:
TYPE42 35.305 Third incorrect SRLEN STOPOVER correction.
ANALDB2R 35.307 Broken DO Syntax, 35.11-35.35, if PDBOUT=PDB is used.
UTILBLDP 35.306 SUPPRESS=74 variable DEVN NOT FOUND ERROR.
VGETxxxx 35.309 Protection for DATASET=PDB.dataset syntax.
==Major CHANGES added in MXG 35.35, dated Jan 3, 2018 thru 35.303.
New Products Support
MDIJCL 35.299 Support for Luminex MDI box to run MXG on Linux.
Error Corrections
TYPE42 35.302 Incorrect SRLEN in SMF 42 Subtype 5 APAR STOPOVER.
TYPERMFV 35.300 CPUPHYAD format could fail causing ABEND.
==Major CHANGES added in MXG 35.12, dated Dec 26, 2017 thru 35.298.
New Products Support
TYPE7072 35.285 Support for Container Pricing, new TYPE72TR dataset.
TYPEBETA 35.297 Support for BETA 93 Version 610 (update) 620 (added).
TYPE0203 35.283 Support for APAR OA52828, SMF Temporary Buffer size.
TYPEQACS 35.288 Support for QAPMDISK with LENGTH=695.
TYPE42 35.289 TYPE42 APARs OA52132, OA52133, OA61734 now tested.
Error Corrections
TYPERMFV 35.287 MXG 35.10/35.11 RMF III ZRBASI ASICPUTA was WRONG.
Enhancements
TYPEDB2 35.280 Exit Members EXDB2STS and _EDB2STS are now valid.
RMFINTRV 35.282 New PLATxxxyyy xxx=zip/ifl/icf yyy=cpus/busy added.
TYPE70 35.282 New PLATxxxyyy xxx=zip/ifl/icf yyy=cpus/busy added.
UTILEXCL 35.293 &MXGCIEXC "exit" to correct USER CMODHEAD typos.
UTILCMPR 35.292 Utility compares numeric variables in OLD/NEW dataset
==Major CHANGES added in MXG 35.11, dated Dec 1, 2017 thru 35.279.
New Products Support
TYPE42 35.274 Support for APAR OA53110 new TYPE42 variables.
TYPE74 35.273 Support for APAR OA50761 Virtual Flash memory.
TYPE89 35.271 Support for Container Pricing in SMF 89.
TYPE70 35.270 Support for Container Pricing in SMF 70.
TYPE113 35.279 Support for Dec 2017 z14 CPU MF formula update.
Error Corrections
TYPERMFV 35.259 35.10: ZRBASI deaccumulation was not correct.
TYPEDB2 35.267 DB2 Netezza IDAA variables Q8STxxxx corrected.
TYPEDB2 35.277 New IFCID=225 QWA225PRISTG_PAGE variable added.
VMACSMF 35.266 SMF ID=2 SYSTEM=DUMY 14 byte records protected.
CICINTRV 35.264 CICDS Dispatch dataset DISP+WAIT GE Interval DURATM.
TYPEBVIR 35.260 BVIR History updated for 3.3 media codes and BVIR302.
TYPEPOEX 35.257 Protection for truncated Power Exchange SMF record.
TYPETMS5 35.278 Correction for TMS Stacked Tape Files wrong values.
Enhancements
TYPE102 35.262 New DB2 zPARMS variables created in T102S106 dataset.
TYPETPMX 35.261 Execution time for TYPETPMX halved by restructure.
TYPERMFV 35.259 New ZRBLCPLPAR dataset with per-LPAR totals.
TYPERMFV 35.259 IBM 4HR MSU (CPUAVB4H) in ZRBCPU per) interval.
VMXGSET 35.256 Example to read "concatenated" PDBs with PROC SQL.
==Major CHANGES added in MXG 35.10, dated Nov 6, 2017 thru 35.255.
New Products Support
TYPERMFV 35.249 Support for z/OS 2.3 RMF III CPUG3 ZRBCPU changes.
TYPE113 35.246 SMF113/HIS formula for z14 L3P/RNI/SM1132SP changed.
TYPEPOEX 35.242 Support for Power Exchange Version 10.1.1.
TYPE42 35.240 Support for APARS OA52132/OA52133/OA61734 UNTESTED.
Error Corrections
TYPE119 35.220 Zero observations in TYP11920 dataset.
TYPE119 35.245 SMF 119 Subtype 81 INPUT STATEMENT EXCEEDED.
TYPEDB2 35.229 PDB.DB2STATB/STSBP protection for large gaps in data.
TYPEDB2 35.248 Four QWA225 and QWB225 variables now kept/input.
FORMATS 35.243 MOBILE WORK CSV files for CICS/TS 5.3 missing prod.
ANAL118 35.241 Typo, NEDNC=SMFTIME should be NENDC=SMFTIME.
TYPEXAM 35.218 XAMSYPUP dataset variables are now correctly aligned.
TYPEXAM 35.223 zVPS/XAM extra SYTCUP with totals is now decoded.
TYPEVMXA 35.221 zVM MONWRITE VXPRCPUP dataset corrected.
Enhancements
GRAFCEC 35.230 Replaces GRAFLPR, CPU/zIIP/4HR MSU graphs.
UTILBLDP 35.225 New EXPDBVAR/EXPDBCDE/EXPDBOUT to create subset.
BUILDPDB 35.234 New EXPDBKEP lets you KEEP=/DROP= vars in JOBS/STEPS+
TYPE80A 35.231 RACFDIRECTED allows DELETE of RACF records DTP=44.
DEDUP701 35.236 Duplicate 70 Subtype 1 records can cause bad results.
TYPERMFV 35.235 RMF III ZRBCPU enhanced with decodes of CPC_HOMEFLAG.
TYPE116 35.219 MQMACCT variable NETSNAME new format decoded.
UTILEXCL 35.228 Support for 20 user character fields in CICSTRAN.
==Major CHANGES added in MXG 35.09, dated Oct 2, 2017 thru 35.225.
MXG 35.09+ is required for:
z14 processor, ONLY the SMF 113 records were incompatibly changed.
z/OS 2.3 SMF 2 and 90 records incompatibly changed.
z/VM 6.1.17.1 MONWRITE records incompatibly changed.
Error Corrections
TYPE0203 35.190 SMF type 2 subtype 2 (SMF Signature enabled) STOPOVER
TYPEVMXA 35.203 z/VM 6.4.17.1 INCOMPATIBLE fields.
TYPENMON 35.208 Nigel's Monitor changed HH:MM to N MINS, INCOMPAT.
TYPE90A 35.199 z/OS 2.3 type 90 subtype 38 INPUT STATEMENT EXCEEDED
New Products Support
TYPE113 35.310 Support for z14 SMF type 113 (INCOMPATIBLE).
TYPEBETA 35.209 Support for BETA 93 Version 610 (INCOMPATIBLE).
TYPEBE97 35.196 Support for BETA 97 Extended 610 Header (INCOMPATIBL)
TYPE102 35.204 Support for new IFCID 376 variables in T102S376.
TYPERMFV 35.191 Support for z/OS 2.3 ZRBASI and ZRBUWD new fields.
TYPEXAM 35.195 Support for zVPS XAM XAMPUP segment.
TYPE6156 35.207 TYPE6156 enhancement adds FIRSTGEN and LASTGEN.
BUILD005 35.206 New %LET SPINSTC=365 keeps STC Account fields longer.
TYPE30 35.205 Documentation of what is counted in SMF 30 EXCPs.
TYPECIMS 35.197 IMF variables STRTTIME/ENDTIME now in microseconds.
Many 35.194 Unrequested log messages MXGDEBUG: VMXGOPTR
BLDSMPDB 35.200 New daily/weekly/monthly optional paths.
TYPE74 35.193 Alignment for sync I/O variables.
TYPE116 35.192 MQMQUEUE INTS/STRT populated in subtype 2 records.
==Major CHANGES added in MXG 35.08, dated Aug 24, 2017 thru 35.186.
Error Corrections
TYPE74 35.182 MXG 34.07 INPUT STATEMENT EXCEEDED RMF 74 SUBTYPE 8.
TYPE92 35.180 SMF 92 Subtype 50 INPUT STATEMENT EXCEEDED RECORD.
TYPEVMXA 35.174A MONWRITE VXBYUSR _MT1 and _PRO (SMT times) corrected.
TYPEROSC 35.177 PDB.ROSCOE, ROSIGNON Logon Time, CONNECTM, corrected.
New Products Support
TYPE119 35.173 Support for SMF 119 Subtype 11 Zert record.
TYPE102 35.183 IFCIDs 389,404,413,414,477 support.
TYPEBBMQ 35.176 Support for BBMQ QSDSTYPE='DISTRIBUTED SYSTEM TYPE'.
BUILDPDB 35.174 CPITCITM/CPISRITM Init, CPITCTTM/CPISRTTM added.
==Major CHANGES added in MXG 35.07, dated Aug 2, 2017 thru 35.171.
New Products Support
TYPEmany 35.166 Support for z/OS 2.3, many additions.
TYPEVMXA 35.165 New variables added to VXMTRMEM dataset.
TYPEXAM 35.164 New variables added to XAMSYS dataset.
TYPEZDP 35.162 Support for Dell/EMC Mainframe Enabler zDP
TYPEMVCI 35.161 Support for BMC Mainview/CICS Version 7.1.
TYPEAXWY 35.150 Support for AXWAY Version 3.1.3, incomplete.
IMACICWU 35.158 Support for Mainview/CICS 7.1 SMF 110 BMCMVCIC.
TYPEBE97 35.152 Support for Beta 97 Subtype 22 for version 430/610.
Error Corrections
ASUMUOW 35.157 Variable DB2TCBTM removed from CPUUOWTM.
TYPETPX 35.155 STOPOVER when IP Port was changed from 4 to 5 digit.
ASMRMFV 35.154 STOPOVER using TYPERMFV if UWD records are created.
TYPE7002 35.153 IBM RMF CRYPTO report TOTAL EXEC is AVERAGE EXEC.
==Major CHANGES added in MXG 35.06, dated Jun 30, 2017 thru 35.151.
Error Corrections
ASMRMFV 35.148 Must specify both SVP and RCD for RMF III CPUTM
TYPERMFV 35.148 RMF III CPUTM wrong if RCD without SVP selected.
TYPEVMXA 35.145 zVM SMT INTERVAL vars were incorrectly DIF()'d.
TYPE74 35.146 TYPE749 Corrections, vars R749FPGBYTx, and R749Dxxx.
TYPE103 35.134 Dataset TYPE103D vars T103DBYT/T103DREQ corrected.
TYPEVMXA 35.131 Variable CALENMT incorrect, new CALSHARE variable.
TYPE30_6 35.127 Negative values for Early Address Spaces corrected.
TYPE30_6 35.127 Negative values for Early Address Spaces corrected.
VMAC38 35.136 NETVIEW ID=38 unexpected S38CCALR length corrected.
New Products Support
TYPE42 35.137 APAR OA44319 improves accuracy for I/O durations.
TYPE991 35.123 New z/OS 2.2 variables added to TYPE991 dataset.
TYPEVMXA 35.132 Support for zVM 6.4 APAR VM66026 new variables.
TYPEBETA 35.139 BETA93 and BETA97 Subtype 25 restructure support.
TYPEXAM 35.147 Support for XAM new VSIDSK and XAMPRC segments.
Enhancements
UTILBLDX 35.149 New BUILDJCL=YES creates IFASMFDP code to select SMF.
SIGNIFICANT CPU SAVINGS for Ad Hoc SMF read when only
a few SMF records are wanted from a large file.
See Change Text. Will replace UTILBLDP next version.
ASUM70PR 35.150 Option %LET CECONLY=YES creates ASUMCEC/ASUMCELP only
ASUM70PR 35.144 MXGERROR:MISSING TYPE 70 RECORDS message.
TYPE113 35.141 SMF 113 Formula for RNI updated for z13.
IMACINIT 35.128 Note: OPTIONS NOCAPSOUT recommended for ODS users.
ASMRMFV 35.135 RMF III Enhancements, Filtering.
UTILBLDP 35.143 Options SUPPRESS enhanced, NEVER corrected.
==Major CHANGES added in MXG 35.05, dated May 15, 2017 thru 35.121.
Error Corrections
TYPEDB2 35.111 DB2 12.1 INVALID QLAC, CONTINUOUS DELIVERY CAUSED.
THIS IS IMPORTANT: LOOK FOR INVALID QLAC ERROR ON
YOUR SAS LOG - OBSERVATIONS ARE NOT OUTPUT.
THE FIELDS WERE INSERTED BY APAR PI74456.
TYPE7072 35.113 35.04 only. TYPE79 SHARE weights wrong, ASUMCELP ok.
VMXGPRNT 35.120 WPS only, MXG 35.04 Only, Blank Label ERROR.
VMXGFIND 35.117 Multiple input PDBs were read, only one was output.
JCLTEST9 35.116 35.04 only. //MVJEIN DD in wrong step.
VGETSORT 35.112 35.04 only. ERROR Truncated SORTBY (name GT 32).
TYPE129 35.109 Variables SM1209EX/EY/EZ/FA were dropped.
ANALID 35.108 ANALID report TITLE for BUILDPDB can be tailored.
New Products Support
TYPEIAM 35.107 Support for IAM Version 9.0.
Enhancements
TYPE110 35.105 CICS duration fields are now formatted TIME16.6.
==Major CHANGES added in MXG 35.04, dated May 1, 2017 thru 35.104.
Error Corrections
TYPE7072 35.093 MXG 35.03 only. PLATBUSY/PCTOF HDW TYPE70/RMFINTRV.
TYPEVMXA 35.079 z/VM 6.3 SMT in VXSYTPRP, VXAPLSO0 corrections.
TYPEXAM 35.074 Velocity XAM SYTCPU invalid errors at vendor.
TYPEDB2 35.081 DB2ACCTP, truncated QPACLOCN/COLN/PKID/ASCH/AANM
New Products Support
TYPEMVJE 35.094 Support for BMC Mainview for Java Environment.
TYPEVMXA 35.092 Updated support for z/VM 6.4 (INCOMPAT, SYTLCK).
Enhancements
ANALFTP 35.087 New ANALFTP analysis provided five new reports.
ANALCNCR 35.091 New example count/plot concurrent TELNET sessions.
IHDRNDM 35.089 New NDM-CDI IHDRNDM exit for NDMRTYPE selection.
BUILDPDB 35.088 Running MXG on ASCII, free SMF alloc at read end.
TYPEOPSS 35.090 Support for CA's OPSS Product User SMF Record.
==Major CHANGES added in MXG 35.03, dated Mar 27, 2017 thru 35.072.
VMAC1415 35.072 First MXG 35.03. Debug HEX DUMPS on log, no ERROR.
Not serious, but easily corrected with this update.
==Major CHANGES added in MXG 35.03, dated Mar 22, 2017 thru 35.069.
Significant Correction/Documentation
TYPE7072 35.064 SMT Mode corrections, "Inflated" CPUZIPTM in MT=2
ONLY IMPACTS 72 and 30 - TYPE 70 DATA JUST FINE!
New Products Support
TYPE110 35.069 Support for CICS/TS 5.4 BETA 11 CICSTRAN new vars.
TYPESVIE 35.059 Support for CA SYSVIEW for IMS 14, missing values.
TYPEIMS 35.058 Support for IMS LOG 67D0 DIAGNOSTIC DC Log Record.
TYPEMVIP 35.055 Support for Mainview for IP PTF BPN2331 adds flag.
TYPE120 35.051 Support for Liberty 17.0.0.1 SMF 120 ST 12 new data.
TYPEOPC 35.048 Support for IWS/TWS/OPC Version 9.3 ST 66 was ST 23.
TYPE102 35.047 Support for IFCID 316 ACCESS CONTROL AUTH EXIT PARMS.
TYPE102 35.046 Support for IFCID 125 Truncated fields.
TYPEVMXA 35.040 Support for Velocity ZWRITE z/VM MONWRITE records.
TYPEXAM 35.063 Support for XAMSYS wrong length, XMTCPSYS NAMENODE.
TYPEMVCI 35.062 Support for Mainview CICS CMRDETL file VER 6700.
TYPE30 35.066 APAR OA59593 adds INELIGHONOR flag to SMF 30s.
Enhancements
TYPEDCOL 35.064A Multi-Volume DCOLDSET fields retained & populated.
ASUMCELP 35.061 Variable SMT_NUM added to PDB.ASUMCELP with MT mode.
TYPE120 35.060 SMF 120 ST 11 TYP120BL CP and zIIP variables added.
GRAFCAPS 35.042 Example report of Resource Group CPU use and CAPPING.
ASUM70PR 35.061 Enhancement adds SMT_NUM to PDB.ASUMCELP dataset.
TYPE120 35.060 Enhancement adds TOTAL/CP ONLY/ZIP CPU to TYP120BL.
ASMRMFV 35.054 RMF Monitor III Enhancement for OPD data filtering.
ASUM70PR 35.050 Error message if PDB.ASUMCELP does not have all 70s.
Corrections
VMXGSUM 35.056 Correction for KEEPMNTH= (very rarely used) option.
TYPERMFV 35.044 ZRBCP SMT vars missing, new CPC_CECNAME variable.
TYPE1415 35.040A IBM APAR OA51325 corrects missing UCB segment.
CICINTRV 35.038 MXG correction for ITRM to NOT delete CICINTRV
==Major CHANGES added in MXG 35.02, dated Feb 10, 2017 thru 35.035.
Execution Errors Corrected:
VMXGSUM 35.022 COMPBL too few arg, VARIABLE QWACBSC ALREADY...
Rare and obscure, only three reports, but nasty
if encountered deep in your daily run, so please
"drop in" 35.02, which is a very good LEVEL SET.
VMXGSUM 35.020 MXG 35.01. Ignore MXGWARN VMXGSUM BACKLEVEL msg.
UTILEXCL 35.023 MXG 35.01.Old Dictionary Records were not used.
TYPEVMXA 35.025 Using _VMINPUT. z/VM variable VMDUSER was 1 byte.
Variables corrected:
TYPEDB2 35.027 DB2STATS QISTxxxx Storage multiplied by 4K vs 1K.
TYPE78 35.021 TYPE78PA variables R782LSMO/GMFO/GFRR are wrong.
GRAFWRKX 35.018 WARNING but ZIPTM, IFATM, and ZIETM were not plotted.
TYPE120 35.024 Subtype 9 variables SMF1209EV,FI,EW no longer kept.
VMXGALOC 35.033 Month begin/logic revised, MNTHKEEP zero protected
TYPE42 35.031 Variable S42DSIOS added to TYPE42DS.
TYPEDB2 35.030 DB2STAT4 _REAL variables way too large.
New Products Support
TYPE102 35.017 New DB2 ZPARMS added to T102S106 dataset.
TYPE117 35.015 Support for SMF 117 GTZ record.
TYPE125 35.015 Support for SMF 125 GTZ record, untested.
TYPE80A 35.029 RACFTYPE=6 seg increased in length, message, no fail.
TYPERMFV 35.028 New RMF III ZRBENC "long names" now input and kept.
IMACDBNZ 35.027 Support for DB2ACCT NETEZZA Q8AC "Accumu" variables.
TYPEBBMQ 35.034 Support for BBMQ BMC Utility BBM9MD73 restructure.
Enhancements
UTILRMFI 35.026 Enhanced reporting if SRVCVLASS=SYSOTHER detected.
TYPETPX 35.035 Protection for invalid TPX subtype 7 record.
==Major CHANGES added in MXG 35.01, dated Jan 20, 2017 thru 35.015.
POTENTIALLY SERIOUS Error Corrected:
RMFINTRV 35.006 Duplicate RMFINTRV if Multiple Capacity Groups exist.
Culprit was MXG's addition of variable SMF70GNM to PDB.RMFINTRV
back in MXG 34.01 in Feb, 2016, but only reported now by only
two sites. THERE IS NO ERROR MESSAGE ON THE LOG.
PROC FREQ DATA=PDB.RMFINTRV; TABLES SMF70GNM;
will show if you are exposed. %INCLUDE SOURCLIB(RMFINTRV);
with //PDB DD DISP=OLD with this Change will rebuild
PDB.RMFINTRV correctly for each mis-built PDB data library.
Errors Corrected:
UTILEXCL 35.004 ERROR PDB.CICSDICT not FOUND - USE THIS UTILEXCL.
TYPE115 35.011 For local time zones with +GMT, GMT115TM wrong.
TYPE120 35.007 Liberty SMF 120 st 12 SM120CCC/CCD Year 2027.
TYPEPOEX 35.002 INVALID SMF Records caused STOPOVER ABEND.
TYPEOSEM 35.010 OSEM User SMF INPUT EXCEEDED, invalid, circumvented.
New Products Support
TYPE71 35.009 Support for APAR OA48913 with 2GB Memory Frames
Enhancements
TYPERMFV 35.005 Dataset ZRBLCP obs created for ONLINE LCPUADDRs.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M5 (9.4M5), "M5",
or "SAS 9.4 (TS04.01M5P09132017)" if the OPTION VERSIONLONG is
enabled.
Only on z/OS, SAS 9.4 "M5" requires MXG 35.36 because it adds the
NOERRORSTOP option to protect all MXG PROC SQLs from the M5 defect
that will be corrected in SAS Note 61672 defect. See Change 35.308
for more details on using NOERRORSTOP for your own PROC SQLs.
SAS V9.4 M5 Is RECOMMENDED, but MXG executes without error
using SAS Version 9.4 M0-M4 or SAS Version 9.3 M0-M2.
SAS V9.4 (ALL) and SAS V9.3 (ALL) are at LEVEL A SAS Support.
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works ok.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 on z/OS 1.10 requires SAS Hot Fix for SN-35332 and is at
Support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS!
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 35.36 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows Seven and
Eight (64-bit) on 64-bit hardware, and sometimes on Centos 6.4,
but MXG users execute MXG on MANY (ALL??) SAS platforms, including
AIX, Linux, and other 'nix' variants, on many different hardware
platforms, and since they all work we don't need to list them. If
SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
However, for the z13 processor on z/OS, the new SMT-MODE RMF 70 was
INCOMPATIBLY CHANGED, and MXG 34.03 is REQUIRED (PCTCPUBY WRONG!), to
read the SMT-format RMF records (which are written if you have zIIP
engines AND have enabled the new PROCVIEW CORE option for
Multi-Threading, even if only one thread is enabled).
The new zEDC compression hardware requires MXG 33.07 to support the
new metrics.
For z/VM, MXG REQUIRES MXG 33.02 to support the z/13 changes.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z/OS 2.3 Many new variables Sep 24, 2017 35.166 35.09*
z/OS 2.3 RMF III Support Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 2 st 2 STOPOVER Sep 24, 2017 35.190 35.09*
z/OS 2.3 type 90 st 38 STOPOVER Sep 24, 2017 35.199 35.09*
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
z13 SMT MT=2 CPUZIPTM TYPE70 Mar 21, 2016 35.03
z14 SMF 113 Records INCOMPAT Oct 2, 2017 35.09
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS-TS/5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS-TS/5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS-TS/5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS-TS/5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS-TS/5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS-TS/5.3 GA date Dec 11, 2015 33.33
CICS-TS/5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS-TS/5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS-TS/5.4 OPEN BETA Nov Nov 11, 2016 34.09
CICS-TS/5.4 GA Jun 17, 2017 35.03
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.08
DB2 12.1 NETEZZA CORRECTIONS Oct 5, 2016 34.08
DB2 12.1 QLAC INSERTS DB2ACCT May 15, 2017 35.05*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
Websphere MQ Series 9.1 Mar 20, 2017 35.03
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
z/VM 6.4 SYTLCK Incompat Apr 26, 2016 34.04
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.13
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
TMON/CICS 4.1 (for CICS/TS 5.3 - Change 34.257 34.08
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 35.36.
1. Incompatibilities introduced in MXG 35.36:
a- Changes in MXG architecture made between 35.36 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 35.36 after MXG 34.34:
Dataset/
Member Change Description
Many 35.308 SAS Defect 9.4 M5 PROC SQL NOERRORSTOP circumvention.
Many 35.166 Support for z/OS 2.3 (many new variables), COMPAT.
Many 35.194 Unrequested log messages MXGDEBUG: VMXGOPTR
ANAL118 35.241 Typo, NEDNC=SMFTIME should be NENDC=SMFTIME.
ANALCNCR 35.091 New example count/plot concurrent TELNET sessions.
ANALDB2R 35.307 Broken DO Syntax in 35.11-35.35 if PDBOUT=PDB is used
ANALFTP 35.087 New ANALFTP analysis provided five new reports.
ANALID 35.108 ANALID report TITLE for BUILDPDB can be tailored.
ASMRMFV 35.054 RMF Monitor III Enhancement for OPD data filtering.
ASMRMFV 35.135 RMF III Enhancements, Filtering.
ASMRMFV 35.148 Must specify both SVP and RCD for RMF III CPUTM
ASMRMFV 35.154 STOPOVER using TYPERMFV if UWD records are created.
ASUM70PR 35.050 Error message if PDB.ASUMCELP does not have all 70s.
ASUM70PR 35.061 Enhancement adds SMT_NUM to PDB.ASUMCELP dataset.
ASUM70PR 35.144 MXGERROR:MISSING TYPE 70 RECORDS message.
ASUM70PR 35.150 Option %LET CECONLY=YES creates ASUMCEC/ASUMCELP only
ASUMCELP 35.061 Variable SMT_NUM added to PDB.ASUMCELP with MT mode.
ASUMUOW 35.157 Variable DB2TCBTM removed from CPUUOWTM.
BLDSMPDB 35.167 VGETSORT revisions for PDB name, internal.
BLDSMPDB 35.200 New daily/weekly/monthly optional paths.
BUILD005 35.206 New %LET SPINSTC=365 keeps STC Account fields longer.
BUILDPDB 35.088 Running MXG on ASCII, free SMF alloc at read end.
BUILDPDB 35.174 CPITCITM/CPISRITM Init, CPITCTTM/CPISRTTM added.
BUILDPDB 35.234 New EXPDBKEP lets you KEEP=/DROP= vars in JOBS/STEPS+
CICINTRV 35.038 MXG correction for ITRM to NOT delete CICINTRV
CICINTRV 35.264 CICDS Dispatch dataset DISP+WAIT GE Interval DURATM.
DEDUP701 35.236 Duplicate 70 Subtype 1 records can cause bad results.
FORMATS 35.243 MOBILE WORK CSV files for CICS/TS 5.3 missing prod.
GRAFCAPS 35.042 Example report of Resource Group CPU use and CAPPING.
GRAFCEC 35.230 New graphs CPU/zip Hours/4HR MSU, replaces GRAFLPAR.
GRAFCEC 35.230 Replaces GRAFLPR, CPU/zIIP/4HR MSU graphs.
GRAFWRKX 35.018 WARNING but ZIPTM, IFATM, and ZIETM were not plotted.
IHDRNDM 35.089 New NDM-CDI IHDRNDM exit for NDMRTYPE selection.
IMACDBNZ 35.027 Support for DB2ACCT NETEZZA Q8AC "Accumu" variables.
IMACICWU 35.158 Support for Mainview/CICS 7.1 SMF 110 BMCMVCIC.
IMACINIT 35.128 Note: OPTIONS NOCAPSOUT recommended for ODS users.
JCLTEST9 35.116 35.04 only. //MVJEIN DD in wrong step.
MDIJCL 35.299 Support for Luminex MDI box to run MXG on Linux.
RMFINTRV 35.006 Duplicate RMFINTRV if Multiple Capacity Groups exist.
RMFINTRV 35.282 New PLATxxxyyy xxx=zip/ifl/icf yyy=cpus/busy added.
SMFINTRV 35.067 New START15INT/30INT/HRINT interval Starttimes.
TYPE0203 35.190 SMF type 2 subtype 2 (SMF Signature enabled) STOPOVER
TYPE0203 35.283 Support for APAR OA52828, SMF Temporary Buffer size.
TYPE102 35.017 New DB2 ZPARMS added to T102S106 dataset.
TYPE102 35.046 Support for IFCID 125 Truncated fields.
TYPE102 35.047 Support for IFCID 316 ACCESS CONTROL AUTH EXIT PARMS.
TYPE102 35.204 Support for new IFCID 376 variables in T102S376.
TYPE102 35.262 New DB2 zPARMS variables created in T102S106 dataset.
TYPE102 35.262 Support for new DB2 zPARMS added by RSU1708 and 1709.
TYPE103 35.134 Dataset TYPE103D vars T103DBYT/T103DREQ corrected.
TYPE110 35.105 CICS duration fields are now formatted TIME16.6.
TYPE113 35.141 SMF 113 Formula for RNI updated for z13.
TYPE113 35.246 SMF113/HIS formula for z14 L3P/RNI/SM1132SP changed.
TYPE113 35.310 Support for z14 SMF type 113 (INCOMPATIBLE).
TYPE115 35.011 For local time zones with +GMT, GMT115TM wrong.
TYPE116 35.192 MQMQUEUE INTS/STRT populated in subtype 2 records.
TYPE116 35.219 MQMACCT variable NETSNAME new format decoded.
TYPE117 35.015 Support for SMF 117 GTZ record.
TYPE119 35.173 Support for SMF 119 Subtype 11 Zert record.
TYPE119 35.220 Zero observations in TYP11920 dataset.
TYPE119 35.245 SMF 119 Subtype 81 INPUT STATEMENT EXCEEDED.
TYPE120 35.007 Liberty SMF 120 st 12 SM120CCC/CCD Year 2027.
TYPE120 35.024 Subtype 9 variables SMF1209EV,FI,EW no longer kept.
TYPE120 35.051 Support for Liberty 17.0.0.1 SMF 120 ST 12 new data.
TYPE120 35.060 Enhancement adds TOTAL/CP ONLY/ZIP CPU to TYP120BL.
TYPE120 35.060 SMF 120 ST 11 TYP120BL CP and zIIP variables added.
TYPE125 35.015 Support for SMF 125 GTZ record, untested.
TYPE129 35.109 Variables SM1209EX/EY/EZ/FA were dropped.
TYPE1415 35.040A IBM APAR OA51325 corrects missing UCB segment.
TYPE30 35.066 APAR OA59593 adds INELIGHONOR flag to SMF 30s.
TYPE30 35.205 Documentation of what is counted in SMF 30 EXCPs.
TYPE30_6 35.127 Negative values for Early Address Spaces corrected.
TYPE42 35.031 Variable S42DSIOS added to TYPE42DS.
TYPE42 35.137 APAR OA44319 improves accuracy for I/O durations.
TYPE42 35.240 Support for APARS OA52132/OA52133/OA61734 UNTESTED.
TYPE42 35.274 Support for APAR OA53110 new TYPE42 variables.
TYPE42 35.289 TYPE42 APARs OA52132, OA52133, OA61734 now tested.
TYPE42 35.305 Third incorrect SRLEN STOPOVER correction.
TYPE6156 35.207 TYPE6156 enhancement adds FIRSTGEN and LASTGEN.
TYPE70 35.270 Support for Container Pricing in SMF 70.
TYPE70 35.282 New PLATxxxyyy xxx=zip/ifl/icf yyy=cpus/busy added.
TYPE7002 35.153 IBM RMF CRYPTO report TOTAL EXEC is AVERAGE EXEC.
TYPE7072 35.064 SMT Mode corrections, "Inflated" CPUZIPTM in MT=2
TYPE7072 35.093 Variables PLATBUSY/PCTOFHDWQ TYPE70/RMFINTRV wrong.
TYPE7072 35.113 35.04 only. TYPE79 SHARE weights wrong, ASUMCELP ok.
TYPE7072 35.285 Support for Container Pricing, new TYPE72TR dataset.
TYPE71 35.009 Support for APAR OA48913 with 2GB Memory Frames
TYPE74 35.146 TYPE749 Corrections, vars R749FPGBYTx, R749Dxxx.
TYPE74 35.182 MXG 34.07 INPUT STATEMENT EXCEEDED RMF 74 SUBTYPE 8.
TYPE74 35.193 Alignment for sync I/O variables.
TYPE74 35.273 Support for APAR OA50761 Virtual Flash memory.
TYPE78 35.021 TYPE78PA variables R782LSMO/GMFO/GFRR are wrong.
TYPE80A 35.029 RACFTYPE=6 segment increased in length, error msgs.
TYPE80A 35.231 RACFDIRECTED allows DELETE of RACF records DTP=44.
TYPE80A 35.231 RACFDIRECTED allows delete of multiple RACF records.
TYPE89 35.271 Support for Container Pricing in SMF 89.
TYPE90A 35.199 z/OS 2.3 type 9 subtype 38 INPUT STATEMENT EXCEEDED
TYPE92 35.180 SMF 92 Subtype 50 INPUT STATEMENT EXCEEDED RECORD.
TYPE991 35.123 New z/OS 2.2 variables added to TYPE991 dataset.
TYPEAXWY 35.150 Support for AXWAY Version 3.1.3, incomplete.
TYPEBBMQ 35.034 Support for BBMQ BMC Utility BBM9MD73 restructure.
TYPEBBMQ 35.176 Support for BBMQ QSDSTYPE='DISTRIBUTED SYSTEM TYPE'.
TYPEBE97 35.152 Support for Beta 97 Subtype 22 for version 430/610.
TYPEBE97 35.196 Support for BETA 97 Extended 610 Header (INCOMPATIBL)
TYPEBETA 35.139 BETA93 and BETA97 Subtype 25 restructure support.
TYPEBETA 35.209 Support for BETA 93 Version 610 (INCOMPATIBLE).
TYPEBETA 35.297 Support for BETA 93 Version 610 (update) 620 (added).
TYPEBVIR 35.260 BVIR History updated for 3.3 media codes and BVIR302.
TYPEBVIR 35.260 Support for new media/devices and BVIR302 correction.
TYPECIMS 35.197 IMF variables STRTTIME/ENDTIME now in microseconds.
TYPEDB2 35.016 DB2STATS QISTxxxx Storage multiplied by 4K vs 1K.
TYPEDB2 35.030 DB2STAT4 _REAL variables way too large.
TYPEDB2 35.081 DB2ACCTP, truncated QPACLOCN/COLN/PKID/ASCH/AANM
TYPEDB2 35.111 DB2 12.1 INVALID QLAC, CONTINUOUS DELIVERY CAUSED.
TYPEDB2 35.229 PDB.DB2STATB/STSBP protection for large gaps in data.
TYPEDB2 35.248 Four QWA225 and QWB225 variables now kept/input.
TYPEDB2 35.267 DB2 Netezza IDAA variables Q8STxxxx corrected.
TYPEDB2 35.277 New IFCID=225 QWA225PRISTG_PAGE variable added.
TYPEDB2 35.280 Exit Members EXDB2STS and _EDB2STS are now valid.
TYPEDCOL 35.064A Multi-Volume DCOLDSET fields retained & populated.
TYPEIAM 35.107 Support for IAM Version 9.0.
TYPEIMS 35.058 Support for IMS LOG 67D0 DIAGNOSTIC DC Log Record.
TYPEMVCI 35.062 Support for Mainview CICS CMRDETL file VER 6700.
TYPEMVCI 35.161 Support for BMC Mainview/CICS Version 7.1.
TYPEMVIP 35.055 Support for Mainview for IP PTF BPN2331 adds flag.
TYPEMVJE 35.094 Support for BMC Mainview for Java Environment.
TYPENMON 35.208 Nigel's Monitor changed HH:MM to N MINS, INCOMPAT.
TYPEOPAV 35.163 Support for Dell/EMC Mainframe Enabler PAV Optimizer
TYPEOPC 35.048 Support for IWS/TWS/OPC Version 9.3 ST 66 was ST 23.
TYPEOPSS 35.090 Support for CA's OPSS Product User SMF Record.
TYPEOSEM 35.010 OSEM User SMF INPUT EXCEEDED, invalid, circumvented.
TYPEPOEX 35.002 INVALID SMF Records caused STOPOVER ABEND.
TYPEPOEX 35.242 Support for Power Exchange Version 10.1.1.
TYPEPOEX 35.257 Protection for truncated Power Exchange SMF record.
TYPEQACS 35.288 Support for QAPMDISK with LENGTH=695.
TYPERMFV 35.005 Dataset ZRBLCP obs created for ONLINE LCPUADDRs.
TYPERMFV 35.028 New RMF III ZRBENC "long names" now input and kept.
TYPERMFV 35.044 ZRBCP SMT vars missing, new CPC_CECNAME variable.
TYPERMFV 35.191 Support for z/OS 2.3 ZRBASI and ZRBUWD new fields.
TYPERMFV 35.235 RMF III ZRBCPU enhanced with decodes of CPC_HOMEFLAG.
TYPERMFV 35.259 35.10: ZRBASI deaccumulation was not correct.
TYPERMFV 35.259 IBM 4HR MSU (CPUAVB4H) in ZRBCPU per) interval.
TYPERMFV 35.259 MSU Count variables added to ZRBASI/ZRBCPU/ZRPLCP.
TYPERMFV 35.259 New ZRBLCPLPAR dataset with per-LPAR totals.
TYPERMFV 35.287 MXG 35.10/35.11 RMF III ZRBASI ASICPUTA was WRONG.
TYPERMFV 35.300 The CPUPHYAD format could fail creation with ABEND.
TYPEROSC 35.177 PDB.ROSCOE, ROSIGNON Logon Time, CONNECTM, corrected.
TYPESVIE 35.059 Support for CA SYSVIEW for IMS 14, missing values.
TYPETMS5 35.278 Correction for TMS Stacked Tape Files wrong values.
TYPETPMX 35.261 Execution time for TYPETPMX halved by restructure.
TYPETPMX 35.261 Execution time reduction.
TYPETPX 35.035 Protection for invalid TPX subtype 7 record.
TYPETPX 35.155 STOPOVER when IP Port was changed from 4 to 5 digit.
TYPEVMXA 35.025 Using _VMINPUT. z/VM variable VMDUSER was 1 byte.
TYPEVMXA 35.040 Support for Velocity ZWRITE z/VM MONWRITE records.
TYPEVMXA 35.079 z/VM 6.3 SMT in VXSYTPRP, VXAPLSO0 corrections.
TYPEVMXA 35.092 Additional support for z/VM 6.4 (INCOMPAT, SYTLCK).
TYPEVMXA 35.093 MXG 35.03 only. PLATBUSY/PCTOF HDW TYPE70/RMFINTRV.
TYPEVMXA 35.131 Variable CALENMT incorrect, new CALSHARE variable.
TYPEVMXA 35.132 Support for zVM 6.4 APAR VM66026 new variables.
TYPEVMXA 35.145 zVM SMT INTERVAL vars were incorrectly DIF()'d.
TYPEVMXA 35.165 New variables added to VXMTRMEM dataset.
TYPEVMXA 35.174A MONWRITE VXBYUSR _MT1 and _PRO (SMT times) corrected.
TYPEVMXA 35.203 z/VM 6.4.17.1 INCOMPATIBLE fields.
TYPEVMXA 35.221 zVM MONWRITE VXPRCPUP dataset corrected.
TYPEXAM 35.063 Support for XAMSYS wrong length, XMTCPSYS NAMENODE.
TYPEXAM 35.074 Velocity XAM SYTCPU invalid errors at vendor.
TYPEXAM 35.164 New variables added to XAMSYS dataset.
TYPEXAM 35.195 Support for zVPS XAM XAMPUP segment.
TYPEXAM 35.218 XAMSYPUP dataset variables are now correctly aligned.
TYPEXAM 35.223 zVPS/XAM extra SYTCUP with totals is now decoded.
TYPEZDP 35.162 Support for Dell/EMC Mainframe Enabler zDP
UTILBLDP 35.143 Options SUPPRESS enhanced, NEVER corrected.
UTILBLDP 35.225 New EXPDBVAR/EXPDBCDE/EXPDBOUT to create subset.
UTILBLDP 35.306 SUPPRESS=74 variable DEVN NOT FOUND ERROR.
UTILBLDX 35.149 New BUILDJCL=YES uses IFASMFDP to save CPU time.
UTILCMPR 35.292 Utility compares numeric variables in OLD/NEW dataset
UTILEXCL 35.004 MXG 34.34 PDB.CICSDICT not FOUND - GET NEW UTILEXCL.
UTILEXCL 35.023 MXG 35.01.Old Dictionary Records were not used.
UTILEXCL 35.228 Support for 20 user character fields in CICSTRAN.
UTILEXCL 35.293 &MXGCIEXC "exit" to correct USER CMODHEAD typos.
UTILRMFI 35.026 Enhanced reporting if SRVCVLASS=SYSOTHER detected.
VGETSORT 35.112 35.04 only. ERROR Truncated SORTBY (name GT 32).
VGETxxxx 35.309 Protection for DATASET=PDB.dataset syntax.
VMAC38 35.136 NETVIEW ID=38 unexpected S38CCALR length corrected.
VMACSMF 35.266 SMF ID=2 SYSTEM=DUMY 14 byte records protected.
VMXGALOC 35.033 Month begin/logic revised, MNTHKEEP zero protected
VMXGFIND 35.117 Multiple input PDBs were read, only one was output.
VMXGPRNT 35.120 WPS only, MXG 35.04 Only, Blank Label ERROR.
VMXGSET 35.256 Example to read "concatenated" PDBs with PROC SQL.
VMXGSUM 35.020 MXG 35.01. Disregard MXGWARN VMXGSUM BACKLEVEL msg.
VMXGSUM 35.056 Correction for KEEPMNTH= (very rarely used) option.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at http://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE
====== Changes thru 35.309 are in MXG 35.36 dated Jan 13, 2018=========
Change 35.309 All of these macros have both a DDNAME and a DATASET
VGETFMT parameter but if you specified DATASET=PDB.dataset they
VGETLABL would all fail since they looked for WORK.PDB.dataset.
VGETLEN This change looks at the code and if DDNAME is null looks
VGETVAR at dataset and uses the first 'word' delimited by '.' of
Jan 8, 2018 DATASET as the DDNAME and the second for the DATASET. If
there is no '.' then DDNAME is set to &MXGWORK.
Change 35.308 SAS defect in SAS 9.4 M5 PROC SQL, only M5 on z/OS, when
ASUMUOW PROC SQL is executed after OPTION OBS=0 was set, caused
Jan 6, 2018 "SQL SET NOEXEC OPTION" error message and ERRORABEND.
Error occurred in default ASUMUOW, but ONLY if you did
NOT enable IMACUOW to create observations, as then, MXG
sets OBS=0 prior to this failing PROC SQL (which had no
prior error message than the NOEXEC and which is still
under investigation by SAS Support: SAS NOTE 61672.
The circumvention is to add NOERRORSTOP to this PROC SQL
and to the several hundred other PROC SQLs in 51 members,
and do it now to hopefully avoid the need for a SAS fix.
Most of the SAS examples of PROC SQL use NOERRORSTOP and
no MXG written PROC SQL has ever had a syntax error, so
this circumvention will likely be permanent.
Option ERRORSTOP is the SAS Default for batch, and it
determines whether PROC SQL stops executing if it
encounters an error; option NOERRORSTOP instructs PROC
SQL to execute the statements and to continue checking
the syntax after an error occurs.
Change 35.307 ANALDB2R fails with broken DO syntax due to Change 35.263
ANALDB2R (MXG 35.11) which incorrectly set the count of SORTBY=
Jan 6, 2018 arguments, resulting in an error in the data steps, if
option PDBOUT=PDB is used.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 35.306 UTILBLDP with SUPPRESS=74 variable DEVN NOT FOUND ERROR.
UTILBLDP If you specified SUPPRESS=74 the sort of the TYPE74CA
Jan 6, 2018 dataset failed with BY variable DEVN not found.
When UTILBLDP found RMF datasets that are needed for
RMFINTRV are SUPPRESSED, we chose to still create them in
WORK so that RMFINTRV would find them and not fail.
But a change to SUPPRESS logic nulled MACRO _CDE74 and
only 16 variables were kept (those that were INPUT in the
other _CDEnnnn macros), and the _STY74 failed.
This change reinstates the logic that nulls the _Sxxxx
macro for suppressed RMF records so sorts will not fail,
but if you also want RMFINTRV to be valid, but don't want
the high volume TYPE74's processed, then you should use
ZEROOBS=74 so the datasets will be created but with zero
OBS, so RMFINTRV will be happy.
Change 35.305 -Jan 04: MXG 35.35 didn't protect LENSR=480 length, caused
VMAC42 STOPOVER if you happen to have that length/APAR.
Jan 4, 2018 -Jan 04, IBM confirmed their incorrect values and will now
set SRLEN=160, and note that that does NOT include the
SYNC segment's 80 bytes when present.
-Change 35.302 in MXG 35.36 was the original change.
-Change 36.023 in MXG 36.01 added invalid LENSR=232.
Change 35.304 New variables in TYPE71 in z/OS 2.3:
VMAC71 SMF71L8M ='MIN 1MB*FRAMES*IN CSTORE'
Jan 4, 2018 SMF71L8X ='MAX 1MB*FRAMES*IN CSTORE'
SMF71L8A ='AVG 1MB*FRAMES*IN CSTORE'
SMF71L9M ='MIN 1MB*AVAILABLE*FRAMES*IN CSTORE'
SMF71L9X ='MAX 1MB*AVAILABLE*FRAMES*IN CSTORE'
SMF71L9A ='AVG 1MB*AVAILABLE*FRAMES*IN CSTORE'
SMF71L10M='MIN 1MB*FRAMES*IN-USE BY*MEM OBJECTS'
SMF71L10X='MAX 1MB*FRAMES*IN-USE BY*MEM OBJECTS'
SMF71L10A='AVG 1MB*FRAMES*IN-USE BY*MEM OBJECTS'
====== Changes thru 35.303 are in MXG 35.35 dated Jan 3, 2018=========
Change 35.303 One z/OS SAS 9.4 M5 site gets SQL SET NOEXEC OPTION that
VMXGUOW terminates the job, currently under investigation by SAS
Jan 4, 2018 support, but adding NOERRORSTOP option to the PROC SQL
does circumvent the error, so it has been added to the
one failing PROC SQL in hopes thats the only one needed.
This note will be revised when more is known.
Change 35.302 SMF 42 st 5/6 with OA54112 now has three SRLEN values of
VMAC42 of 240 and 400, and 480 from OA52132/OA52133/OA61745 in
Jan 2, 2018 Change 35.289, and all three are wrong.
Jan 3, 2018 The actual length of the SR segment in each record is
Jan 4, 2018 variable, with 160 bytes if there is no SYNC segment, or
240 bytes when the SYNC segment is present. All three
are now protected. The error caused STOPOVER ABEND.
-New variable S42SNCONC='CONCURRENT*SYNC I/O*READ+WRITE'
added to TYPE42SR and TYPE42DS datasets.
-Jan 03: another incorrect SRLEN value of 320 protected in
MXG 35.36.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 35.301 If in your ASUMUOW you defined _LDB2ACC as something
VMXGUOW other than DB2ACCT.DB2ACCT (like DB2.DB2ACCT) and the
Dec 30, 2017 DDNAME did not exist in your LIBNAME or DD statements
ASUMUOW would ABEND with a LIBREF not found. Now the
code looks for this condition, gives you an MXGWARN
message and sets _LDB2ACC to _NULL_ so that ASUMUOW
will run.
Change 35.300 The CPUPHYAD format could fail to be created with error
VMACRMFV messages of overlapped values, when there were multiple
Dec 31, 2017 values of CPUPHYAD (CEC Speed), as when you change the
number of engines for an LPAR; that error caused the
TYPERMFV job to ABEND USER 999.
Thanks to MP Welch, Bank of America, USA.
Change 35.299 Luminex now offers a small Linux appliance called an MDI
MDIADHOC (Mainframe Data Integration) that provides another way to
MDIJCL move MXG jobs off of zOS and onto an ASCII platform. Jobs
MDIJCL1 are still submitted from zOS, so your scheduling system
MDIJCL2 is still in control, but the actual processing of the SMF
MDIJCL3 data occurs on the LINUX platform, and the output PDB's
MDIJCL4 live on storage attached to the MDI. Reports can be sent
MDIPDB back to zOS or routed on your network wherever the MDI
MDIPDB1 can attach. Each job uses 2-3 virtual tape devices, for
MDIPDB2 the SMF input, the SASLOG, and the SASLIST. One site had
MDIPDB3 1TB of SMF, split when SMF was dumped into three outputs,
MDIPDB4 DB2, CICS, for each of 12 LPARS, so 36 concurrent jobs
Dec 31, 2017 processed that data in a bit less than two hours on a
Jan 6, 2018 single MDI.
These sample members provide examples of JCL and code
to run jobs on the MDI. The JCL is very case sensitive
and casing for program names must match the case as
stored in your USERID.SOURCLIB. Also the names and case
of the LOG and LIST datasets in the LUMXPROC must match
the program name.
MDIJCL /MDIPDB runs a basic BUILDPDB adding the 42
and 6156 data to the PDB using
UTILBLDP and BLDSMPDB wirh AUTOALOC
MDIJCL1/MDIPDB1 runs a basic BUILDPDB adding the 42
and 6156 data to the PDB using
UTILBLDP and BLDSMPDB wirh AUTOALOC
and suppressing CICS and DB2 data
MDIJCL2/MDIPDB2 runs VMXGALOC with READONLY=YES
(which suppresses the aging of the
directories) and then runs TYPS110
and CICINTRV.
MDIJCL3/MDIPDB3 runs VMXGALOC with READONLY=YES
(which suppresses the aging of the
directories) and then runs READDB2.
MDIJCL4/MDIPDB4 runs VMXGALOC with READONLY=YES
(which suppresses the aging of the
directories) and after MDIJCL2 and
MDIJCL3 have run will run ASUMUOW.
MDIADHOC JCL for adhoc reporting allows you to
write your program on z/OS and run the
MDI.
Thanks to Chuck Hopf, Independent Consultant, USA.
Thanks to Earl Kline, Luminex, USA
Thanks to Paul Massengill, Luminex, USA
Thanks to Daniel Saunders, Luminex, USA
Thanks to David Feimer, Luminex, USA
====== Changes thru 35.298 are in this MXG 35.12 dated Dec 26, 2017=====
Change 35.298 While all MXG Variables are upper case, mixed case names
VGETFMT are allowed, so you can easily create variable names with
VGETLABL lower case characters, but the listed macros all failed
VGETLEN to find those variable names. The macros are revised to
VGETVAR UPCASE both sides of the compare without changing the
Dec 23, 2017 returned variable name.
Change 35.297 Support for BETA 93 Version 610 (update) and 620 (added).
EXTYBETK -BETA1 blank values for BETADCR corrected and new vars:
EXTYBETL I001PTYPE='PROTOCOL*TYPE'
EXTYBETM I001IPADDR='IP*ADDRESS'
EXTYBETN I001HOST ='HOST*NAME'
FORMATS I001PORT ='HOST*NAME'
VMACBETA I001QUEUE ='HOST*NAME'
VMXGINIT I001FFPARM='HOST*NAME'
Dec 23, 2017 -Support for 620 new subtype 59 creates three datasets and
subtype 22 record is now decoded and creates BETA22VAL:
TYBETK BETA59 SUBTYPE 59 STC START/STOP
TYBETL BETA59RFF SUBTYPE 59 SFF JOB STATS
TYBETM BETA59SFF SUBTYPE 59 SFF JOB STATS
TYBETN BETA22VAL SUBTYPE 22 VALUES
Change 35.296 A WHERE clause in PROC SQL is case sensitive, and if you
VGETLABL create your own variable NAMEs with low case characters,
VGETFMT your variable will NOT be found; only upper case variable
VGETLEN names are found. MXG does not create low case names, and
Dec 20, 2017 cannot detect them in the WHERE clause. No code changed.
Change 35.295 Support for 164-byte DBCTL segment for CICSTRAN dataset.
IMACICDB
Dec 20, 2017
Thanks to Ervin Claxon, CSX Technology, USA.
====== Changes thru 35.294 are in this MXG 35.12 dated Dec 20, 2017=====
Change 35.294 SMF 116 records with MQMSSSID mismatched to QWHSIDMQ
VMAC116 printed MISMATCHED message on the log for every mismatch;
Dec 19, 2017 now, only the first three are printed.
Thanks to Denise Williers, Wipro, USA.
Change 35.293 &MXGCIEXC is a new "exit" for UTILEXCL wherein you can
UTILEXCL correct misspellings in USER CMODHEAD field causing the
VMXGINIT DUPLICATE CONN report (same offset has two names, usually
Dec 19, 2017 caused by a typo by the CICS SYSPROG who does the DFHMCT
assembly of that Monitor Control Table). This change
circumvents the need to reassemble. You would use:
//SYSIN DD *
%LET MXGCIEXC=
%QUOTE(
IF CMODHEAD='PSB ACTV' THEN DO;
PUTLOG _N_= CMODNAME= CMODHEAD=
SMFPSRVR= MCTSSDRL= MCTSSDCN=;
CMODHEAD='PSB ACTI';
END; );
%INCLUDE SOURCLIB(UTILEXCL);
_BLDDICT _BLDEXCL _RPTEXCL
Thanks to Denise Williers, Wipro, USA.
Change 35.292 A utility to Compare numeric variables values in OLD and
UTILCMPR NEW versions of the same SAS dataset, using PROC MEANS to
Dec 30, 2017 compare the value of each statistic of each variable.
%UTILCMPR(IN1=OLD.ZRBASI,IN2=NEW.ZRBASI);
Change 35.291 GCHART AXIS statements were made compatible with WPS
GRAFCEC 03.03.02.00.0222553, and some code was simplified and
GRAFLPAR logic added to STOP if no obs in RMFINTRV and to not
GRAFWRKX plot eligible times if there were none.
GRAFWRKC The WPS graphs are printed in different order, all for a
Dec 15, 2017 particular metric, whereas SAS prints all for an LPAR.
Jun 28, 2019 While GRAFLPAR is supported, it is obsolete and GRAFCEC
should be used instead, as it has superior reports.
Jun 28, 2019: This statement is not true in WPS 4.1.
-As WPS does not support SGPLOT, GRAFWRKC plots had to be
duplicated using the GBARLINE and GCHART procedures and
INCODE= added for data selection.
Change 35.290 Clear of _HSMPLEX macro added at end so that you can
ASUMHSM execute ASUMHSM multiple times in a single job.
Dec 13, 2017
Change 35.289 Support for TYPE42 APARs OA52132, OA52133, and OA61734,
VMAC42 originally coded in Change 35.240, has now been revised.
Dec 12, 2017 A Subtype 5 STOPOVER was caused by new records with the
SRLEN=480 but with actual SR Segment length of 160, or
240 if the new SYNC segment is present, but the actual
length of the SYNC segment is 80 bytes with APAR only
documenting 72. Finally, records with SRLEN=208 and no
SYNC segment are written with only 160 bytes documented.
Change 35.288 Support for new TYPECONF GKEYPM variable and new length
VMACQACS of QAPMDISK of 695 to align those records, although no
Dec 11, 2017 new fields are input in this iteration, awaiting doc.
Thanks to Larry E. Hanus, DST Systems, USA.
Change 35.287 -MXG 35.10 and 35.11 RMF III ZRBASI deaccumulate was WRONG
VMACRMFV DESIGN: should NOT replace ASICPUTA with ASICPUTA_LF, and
Dec 15, 2017 WRONG IMPLEMENTATION: insufficient QA tests, causing the
Dec 21, 2017 value in both variables to be frequently wrong, and if
there were multiple CEC Speeds (CPUPHYAD values) the MSU
value in ZRBASICPUMSU=ZRBASI*CPU MSU*COUNT was wrong.
-This change restores the original ASICPUTA value and the
deaccumulated higher resolution value is in ASICPUTA_LF
so YOU can choose to use the variable of YOUR choice.
-This change also adds variable CPC_CECNAME to ZRBLCP and
ZRBLCPLPAR datasets, and creates a format for CPUPHYAD
lookup (by SYSPLEX SYSTEM) from ZRBCPU to pass CPUPHYAD
into the ZRBASI dataset for MSU calculations.
-Duplicate ASI records for the same task in an interval do
exist, as when a task changes it's JOB name, and they are
visible in RMF III reports, but the deaccumulate can be
a missing value as IBM has not provided a way to identify
which was the first observation and which was the second.
In addition, records with seconds of CPUTCBTA value and
microseconds for CPUTCBTA_LF have been observed, so the
value of using CPUTCBTA_LF needs to be examined in your
data. These issues are open with RMF development, and
this text will be updated when more is known.
-Dec 21: Invalid INPUT for PHYCPUAD message had no impact
but was corrected; was printed when no ZRBCPU matched.
Thanks to MP Welch, Bank of America, USA.
Change 35.286 MXG variable IOTMNOCA, uncaptured IO Connect Time in 30s,
BUILD005 was incorrectly calculated in BUILDPDB and SMFINTRV using
BUIL3005 SMF30AIC-IOTMTOTL instead of -IOTMDASD causing negative
SMFINTRV values. But SMF30AIC is the connect time for the ASID
Dec 6, 2017 and Dependent Enclaves, but does NOT include FICON chans
which could also cause negative values.
Thanks to Randy Hewitt, DXC Technology, USA.
Change 35.285 Support for Container Pricing in RMF 72 records creates
EXTY72TR new TYPE72TR dataset for Tenant Resource Group that are
IMAC7072 added by APAR OA52694. TYPE72TR has the same variables
VMAC7072 that are in TYPE72GO with new variables for TRG
VMAC79 R723GGTI='TENANT*IDENTIFIER'
VMXGINIT R723GGTN='TENANT*NAME'
Dec 7, 2017 R723GGKY='TENANT*SOLUTION*ID'
R723GGTF='TENANT*RESOURCE*GROUP?'
and these variables added to both TYPE72GO and TYPE72TR:
R723CPA_ACTUAL ='PHYSICAL*CPU*ADJUSTMENT*FACTOR'
R723CPA_SCALING='SCALING*FACTOR*FOR*R723_ACTUAL'
-Flag variables added to TYPE792 and TYPE795 dataset
R792FLG32='R792RGRP*IS A*TRG?'
R795FLG6='R795RGRP*IS A*TRG?'
Change 35.284 -MXG 35.11 inserted statements to create ZRBCPUxxxMSU vars
VMACRMFV incorrectly inside MACRO _EZRBCPU and _EZRBLCP definition
Dec 6, 2017 causing UNINIT variable if you had tailored EZRBCPU.
Dec 8, 2017 -Missing values for ZRBCPUZIPMSU were corrected. The new
Dec 9, 2017 ZRBLCPLPAR dataset requires the CPUG3 CPCDB, and SSHG3
tables, or ASMRMFV Table IDs of CPU and CPC, since SSH is
always selected.
Thanks to MP Welch, Bank of America, USA.
Change 35.283 Support for APAR OA52828 which allows customization of
VMAC0203 the size of the SMF Temporary Buffer used to hold SMF
VMAC7 data during IPL processing.
VMAC23 TYPE0 dataset new variable
Dec 5, 2017 SMF0TBUF='SMFTBUFF*PARAMETER*SPECIFIED*MEGABYTES'
TYPE7 dataset new variable
SMF7TBLS='BYTES LOST*DURING SMF*INITIALIZATION';
TYPE23 dataset new variable
SMF23MBU='MAX BYTES*STORED IN*SMFTBUFF'
Change 35.282 A new set of variables added to TYPE70 and RMFINTRV to
VMAC7072 capture the number and usage of IIP, IFL, and ICF CPS
VMXGRMFI for the platform (CEC).
Dec 5,2017 PLATZIPCPUS - The number of IIPs on the CEC
PLATZIPBUSY - The total % busy of all the IIPs
PLATIFLCPUS - The number of IFLs on the CEC
PLATIFLBUSY - The total % busy of all the IFLs
PLATICFCPUS - The number of ICFs on the CEC
PLATICFBUSY - The total % busy of all the ICFs
Change 35.281 TACI802 dataset variable FINTIME was not converted from
VMACMVIP GMT to LOCAL Time zone.
Dec 4, 2017
Thanks to Paul Volpi, UHC, USA.
Change 35.280 The Exit member EXDB2STS and _EDB2STS macro are now used
VMACDB2 to give control of the output of PDB.DB2STATS; previously
Dec 6, 2017 defined but not used.
Thanks to Scott Barry, SBBWorks Inc., USA.
====== Changes thru 35.279 are in this MXG 35.11 dated Dec 1, 2017=====
Change 35.279 Support for Dec 2017 z14 CPU MF formula update.
ASUM113 The EXTND158 counter was moved from L3P to L4LP.
VMAC113 -John's updated formulas are available at
VMACVMXA
Nov 30, 2017
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TC000066
Change 35.278 Correction for TMS Stacked Tape Files; these variables
TYPETMS5 were not retained from the first DSNB record into the
VMACTMS5 "CHANGED" records so they were incorrect:
Nov 30, 2017 RFILSEQ RLRECL RBLKSIZE RRECFM RSTPNAME RFILPERC;
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 35.277 Support for IFCID=225 new fields in DB2STAT4 dataset:
VMACDB2 QWA225PRISTG_PAGE /**DBM1*PRVT ELIG*PGSTEAL*/
Nov 28, 2017 QWB225PRISTG_PAGE /**DIST*PRVT ELIG*PGSTEAL*/
Dec 6, 2017 IBM DSECT notes these fields contain:
Number of Private discarded pages eligible for Page
Steal. Currently backed frames which are still charged
to DB2, minus this count, is the true REAL Storage
usage at this time.
I can not find the "currently backed frames" fields and
have asked IBM for help; this note will be updated when
the correct fields are known so the usage variable can
be created.
IBM DB2 Support response Nov 30:
All IFCID225 fields are described in the dataset
'DSNB10.SDSNIVPD(DSNWMSGS)'. It does not look like we
capture that statistic. The values are captured from
RMF and are included with DB2 statistics records to
assist with reporting. Anything not contained will
still be available in RMF.
-Dec 6: UNINIT PRISTGDPAGE and correct spell as _PAGE.
Change 35.276 Support for CICSTRAN User field RFSEMP01/RFSDATA creates
IMACICWX seven variables, RFSEMP01F1-RMSEMP01F7.
IMACAAAA
UTILEXCL
VMAC110
Nov 27, 2017
Change 35.275 Addition of TYPE70TR dataset required protection in the
ANALRMFR PDB=SMF part of the program to prevent the
Nov 26, 2017 ERROR: No dataset open to look up variables.
when the _STY70TR was executed without prior build.
Change 35.274 Support for APAR OA53110 adds new variables:
VMAC42 S42DSRRU='AVG RESPONSE*RANDOM*READ*CACHE'
Nov 22, 2017 S42DSRSU='AVG SERVICE*RANDOM*READ*CACHE'
SMF42IFW='AVERAGE*FAST-WRITE WAITS*PER MINUTE'
SMF42IHR='AVERAGE*HIT*RATIO'
Change 35.273 Support for APAR OA50761 adds new R7410FLG='Y' if the
VMAC74 resource is Virtual Flash Memory.
Nov 22, 2017
Change 35.272 Change 34.151 set SYSLAST to the value of OUTDATA so that
VMXGSUM subsequent PROC steps would automatically find the output
Nov 22, 2017 of VMXGSUM as the last dataset created, but if you added
any dataset options like (KEEP or (INDEX then while the
dataset was correctly created, an error message was
generated that either told you the dataset name was
invalid or that it exceeded 42 bytes depending on the SAS
version you were running. NOTE: there must be a space
between the dataset name and any options you choose to
specify.
Thanks to Robert Gilbert, BNP Paribas Fortis, BELGIUM.
Change 35.271 Support for Container Pricing in SMF 89 records creates
EXTY89R1 New variables in TYPE89 and TYPE892:
EXTY89R2 SMF89COREMODECP='CPUS*ACTIVE*ON CP*CORE'
EXTY89TI SMF89COREMODEZAAP='CPUS*ACTIVE*ON ZAAP*CORE'
IMAC89 SMF89COREMODEZIIP='CPUS*ACTIVE*ON ZIIP*CORE'
VMAC89 New variables in TYPE892:
VMXGINIT SMF89CURREGS ='INSTANCES*OF CURRENT*REGISTRATIONS'
Nov 27, 2017 SMF89TRGREGS ='INSTANCES*OF CURRENT TRG*REGISTRATIONS'
SMF89DELTAREGS='INTERVAL*DELTA*CURRENT*REGISTRATIONS'
SMF89DELTATRG ='INTERVAL*DELTA*TRG*REGISTRATIONS'
New dataset TYPE89TI 'INTERSECTION TENANT RESOURCE GROUP'
PRODOWNR= 'SMF89TCPO PRODUCT*OWNER'
PRODNAME= 'SMF89TCPN PRODUCT*NAME'
PRODVERS= 'SMF89TCPV PRODUCT*VERSION'
PRODQUAL= 'SMF89TCPQ PRODUCT*QUALIFIER'
PRODID = 'SMF89TCPI PRODUCT*ID'
SMF89TIPO 'INTERSECTING*PRODUCT*OWNER'
SMF89TIPN 'INTERSECTING*PRODUCT*NAME'
SMF89TIPV 'INTERSECTING*PRODUCT*VERSION'
SMF89TIPQ 'INTERSECTING*PRODUCT*QUALIFIER'
SMF89TIPI 'INTERSECTING*PRODUCT*ID'
SMF89_TRG 'TENANT*RESOURCE*GROUP'
SMF89TCFG 'TENANT*USAGE*ENTRY*FLAGS'
SMF89TCCT 'TENANT*PRODUCT*INTERSECT*CP TCB TIME'
SMF89TCZT 'TENANT*PRODUCT*INTERSECT*ZIIP TIME'
New dataset TYPE89R1 'TENANT RESOURCE GROUP DATA'
SMF89TIPO='INTERSECTING*PRODUCT*OWNER'
SMF89TIPN='INTERSECTING*PRODUCT*NAME'
SMF89TIPV='INTERSECTING*PRODUCT*VERSION'
SMF89TIPQ='INTERSECTING*PRODUCT*QUALIFIER'
SMF89TIPI='INTERSECTING*PRODUCT*ID'
SMF89_TRG='TENANT*RESOURCE*GROUP'
SMF89TCFG='TENANT*USAGE*ENTRY*FLAGS'
SMF89TCCT='TENANT*PRODUCT*INTERSECT*CP TCB TIME'
SMF89TCZT='TENANT*PRODUCT*INTERSECT*ZIIP TIME'
New dataset TYPE89R2 'TENANT RESOURCE GROUP DATA'
SMF89TIPO='INTERSECTING*PRODUCT*OWNER'
SMF89TIPN='INTERSECTING*PRODUCT*NAME'
SMF89TIPV='INTERSECTING*PRODUCT*VERSION'
SMF89TIPQ='INTERSECTING*PRODUCT*QUALIFIER'
SMF89TIPI='INTERSECTING*PRODUCT*ID'
SMF89_TRG='TENANT*RESOURCE*GROUP'
SMF89NRTRG'CURRENT*TRG*REGISTRATIONS'
Change 35.270 Support for Container Pricing in RMF 70 records creates
EXTY70TR new TYPE70TR dataset with these Tennant Resource Group
VMAC7072 variables in APAR OA52694:
VMXGINIT TRG_NAME ='TENANT*RESOURCE*GROUP*NAME'
Nov 22, 2017 TRG_DESC ='TENANT*RESOURCE*GROUP*DESCRIPTION'
TRG_TNTID ='TENANT*IDENTIFIER'
TRG_TNTNAME='TENANT*NAME'
TRG_SBID ='TENANT*SOLUTION*ID'
TRG_SUCP ='TENANT*CP*MSU*UNITS'
TRG_SUIFA ='TENANT*ZAAP*MSU*UNITS'
TRG_SUSUP ='TENANT*ZIIP*MSU**UNITS'
TRG_SULAC ='TENANT*CP 4HR*AVERAGE*MSU'
Change 35.269 Support for CICS User field USERPRC1/WANLUPRC.
IMACAAAA
IMACICWV
PRODTEST
UTILEXCL
VMAC110
Nov 21, 2017
Change 35.268 SAS 9.1.3 SP4 (SAS (R) 9.1 (TS01.01M3P02022006) failed
SAS* with ERROR: OBTAIN FAILED FOR FILE SMF, RC=24. because
Nov 19, 2017 the new parm EATTR=OPT was enabled for non-VSAM datasets,
so they can reside on EAV volumes, but that was not
supported until SAS 9.2
Thanks to Jeffery Kirsch, Compuware, USA.
Change 35.267 -DB2 Netezza IDAA variables Q8STDSKB and Q8STDSKU were
VMACDB2 both wrong; Q8STDSKU was incorrectly multiplied and DSKB
Nov 17, 2017 was missing that multiplication.
-Variables Q8STINSC/UPDC/DELC/DRPC/CRTC/CMTC/RBKC/OPNC
WERE ALL WRONGLY SET EQUAL TO Q8STACPU.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.266 SMF ID=2 SYSTEM=DUMY "SMF Signature Enabled" records that
VMACSMF are only 14 bytes were still created after APAR OA50483
Nov 17, 2017 was installed, causing INPUT STATEMENT EXCEEDED error, as
MXG expected these records to contain additional data in
either a subtype 1 or 2 record. Now, MXG tests for the
length=14 and deletes these 'DUMY' records, silently.
The APAR reported the exposure was only when Logstream
data is read, and infrequently.
In IBM's unstated defense, the "subtypes are valid" bit
wasn't turned on, justifying the original 14 byte length,
but MXG had keyed off that unique system name of DUMY.
If you see the DUMY in a hex dump, you can circumvent
with MACRO STOPOVER MISSOVER % as your first //SYSIN.
to prevent the ABEND until you have this VMACSMF update.
Update: See Change 38.033.
Thanks to Paul Volpi, UHC, USA.
Thanks to Brian D. Peterson, UHC, USA.
Thanks to Donald R. Striegel, UCH, USA.
Change 35.265 MXG 35.10. BPHITRAT always missing in DB2STATB because
VMACDB2 line 4057 (BPHITRAT=.;) should have been deleted. You
Nov 14, 2017 can recalculate in your reporting using
IF QBSTGET GT 0 THEN BPHITRAT=
(QBSTGET-(QBSTRIO+QBSTSPP+QBSTDPP+QBSTLPP))/QBSTGET;
ELSE BPHITRAT=.;
Thanks to Rick Southby, Insurance Australia Group, AUSTRALIA.
Change 35.264 CICS interval statistics in the Dispatcher Records, CICDS
VMAC110 dataset, have the sum of DSGTDT+DSGTWT, DISP+WAIT time
VMXGCICI that is greater than the interval DURATM, with DSGTWT as
Nov 14, 2017 much as 5900 seconds for a 3600 second interval (and the
DSGTDT in those segments are milliseconds or less); that
sum was used calculate STARTIME and DURATDS. Now, DURATM
is stored in DSGTWT and used for calculations, and then
DSGTWT=DURATM-DSGTDT recalculates the possible wait time.
See Change 36.076.
-The message "ERROR: IF YOU USE CICINTRV..." when MXG
detected the condition (DURATM GT INTERVAL REQUESTED)
is change to "MXGWARN:..." as few actually use CICINTRV.
-This data has only been seen from ancient CICS/TS 4.2.
Thanks to Ed Wieszczek, Zions Bank, USA.
Change 35.263 If you didn't specify a SORTBY= parameter for the ACCOUNT
ANALDB2R report, it could fail trying to resolve a macro variable
Nov 10, 2017 that did not exist.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 35.262 New DB2 zPARMS added include
FORMATS QWP4MUDI='MORE*UNION*DISTRIBUTION' which is decoded by
VMAC102 a new format
Nov 22, 2017 QWPRSTACS='STATCKGSRT'
QWP4BSACP='ALTERNATE*CP'
QWP4UDBSG='UTIL*DBBSG'
QWP4ULBSG='UTIL*LGBSG'
QWP4CYFR ='COPY*FAST*REPLICATION'
QWP4DDLM ='DDL*MATERIAL*IMMED*PEND'
QWP4CDSTL='CACHDYN*BOTH*CAPTURE*LOAD*NONE'
QWP4ZHYPL='ZHYPERLINK*ENABLE*DISABLE*BDATABASE'
Change 35.261 Execution run time for TYPETPMX halved by restructuring
VMACTPMX the 700 WHEN clauses into 13 subgroups of first letter of
Nov 8, 2017 the WHEN argument text value.
Thanks to Kurt Gramling, TSYS, USA.
Change 35.260 BVIR History file updated for formats for 3.3 media codes
FORMATS and BVIR302 fields were corrected.
VMACBVIR
Nov 9, 2017
Thanks to Spain.
Change 35.259 -RMF III Interval MSU variables in ZRBASI/ZRBCPU/ZRBLCP
VMACRMFV with these counts of Million Service Units
Nov 8, 2017 ZRBASICPUMSU='ZRBASI*CPU MSU*COUNT'
Nov 12, 2017 ZRBCPUCPUMSU='ZRBCPU*CPU MSU*COUNT'
Nov 18, 2017 ZRBCPUZIPMSU='ZRBCPU*ZIP MSU*COUNT'
Nov 24, 2017 ZRBLCPCPUMSU='ZRBLCP*CPU MSU*COUNT'
Nov 30, 2017 where the Software MSU Coefficient CPUPHYAD is used by
ZRBCPUCPUMSU=CPUPHYSI*CPUPHYAD/1000000;
So, an LPAR in a CEC with CPUPHYAD=20000, with the CPU
Partition Dispatch time of 15 seconds in an interval,
would have an MSU Count = (15*20000)/1000000 =0.3 MSU.
If the interval duration was one minute, the IBM ACT
"Actual" MSU on the RMF III CPC report, a projection
of this interval's value to an hourly total as if all
intervals were this value, would be 60*0.3=18 MSU per
hour, which is the value in this new variable:
ZRBLCPCPUMSUHR='ZRBLCP*IBM ACT MSU*PROJECTED*HRLYMSU'
-Dataset ZRBLCP contains data on ALL LPARS in a SYSPLEX,
reading data from only one SYSTEM in that SYSPLEX, but it
has an obs for each LCPUADDR in each LPAR. This change
creates new ZRBLCPLPAR dataset when ZRBLCP is sorted,
with the LPAR totals for each LCPUPRTY engine for each
interval, but there is no 4HR AVG MSU variable in ZRBLCP.
To create ZRBLCPLPAR the CPUG3, CPCDB and SSHG3 tables
are needed.
-The actual IBM 4HR MSU (CPUAVG4H) is in ZRBCPU dataset
at one minute or even 30 second intervals, but you have
to read the data from every system to populate ZRBCPU for
all LPARs.
-MXG 35.10, the deaccumulation of the six ZRBASI variables
(actually added by z/OS 2.2) was not sufficiently tested
and could have incorrect values in these variables:
ASICPUTA_LF ASITCBTA_LF ASIIOCNT_S ASITRCA_S ASITET ASITRT
for jobs that have duplicate names with different ASID-NR
and only if you used TYPSRMFV or _SZRBASI to sort ZRBASI.
The new-in-35.10 MXG deaccumulation of CPU_LF fields by
_SZRBASI failed to include the ASID number, PERIOD, and
JCTJOBID to deaccumulate those six variables.
The ZRBASI dataset created by TYPERMFV was not in error.
-As documented in Change 35.249, the value in ASICPUTA is
is larger with 35.10 because the higher resolution CPU in
ASICPUTA_LF is stored in ASICPUTA, with ASICPUTA_ORIG
keeping the original lower value.
-Nov 30: LPARNAME in ZRBCPU is now always populated.
Change 35.258 35.09-35.10, Macro Language error, missing double periods
ANALID in line ANALID: &PDBMXG..SMFRECNT DOES NOT EXIST;
Nov 7, 2017
Change 35.257 Power Exchange User SMF INPUT STATEMENT EXCEEDED ERROR;
VMACPOEX the record should have 21 POEX segments but has only 3,
Nov 7, 2017 and the last segment is only 90 versus 95 bytes.
This change will be updated when the vendor's records are
correct. This was from 9.6.1, but I've recently read
that version's records with no errors.
Thanks to Tracey Davidson, USBank, USA.
Change 35.256 No code change, but a new example using PROC SQL to read
VGETDDS "concatenated" PDB data libraries.
VMXGSET // EXEC MXGSASV9
Nov 7, 2017 //PDB1 DD
//PDB2 DD
%VGETDDS(DDNAMES=PDB: );
DATA MYVIEW/VIEW=MYVIEW;
%VMXGSET(DATASET=MNTHJOB);
PROC SQL;
SELECT YEAR(DATEPART(JINITIME)) AS MYYEAR LABEL= 'YEAR',
MONTH(DATEPART(JINITIME)) AS MYMONTH LABEL = 'MONTH',
SYSTEM, JOB, TYPETASK ,
ACCOUNT1, SUM(NORMCPU) AS TOTALNORMCPU ,
JOB FROM MYVIEW
WHERE JOB LIKE 'MYJOB%'
AND MONTH(DATEPART(JINITIME)) = 09
GROUP BY JOB, SYSTEM ;
Thanks to Paul W Schreiber, AT&T, USA.
====== Changes thru 35.255 are in this MXG 35.10 dated Nov 6, 2017=====
Change 35.255 -MXG 35.10, Change 35.240 DIVIDE BY ZERO error when the
VMAC42 IOCCOUNT=0 in TYPE42SR, now protected, but had no impact
Nov 6, 2017 on the TYPE42SR dataset, DCMEPCT still missing.
Nov 14, 2017 -Subtype 5 INPUT STATEMENT EXCEEDED when 68 bytes were
added for the SYNC segment, but SYNC Offset was zero.
Thanks to Jim S. Horne, Lowe's Companies, Inc., USA.
Thanks to Stan Adriaensen, AXA-Tech, BELGIUM.
====== Changes thru 35.254 are in this MXG 35.10 dated Nov 6, 2017=====
Change 35.254 Variables QW0225_ECSA_aaaa and QW0225_ESQA_aaaa were
VMACDB2 incorrectly multiplied by 4096.
Nov 5, 2017
Thanks to Rick Southby, IAG, AUSTRALIA.
Change 35.253 Some of the macro variables coming back from PROC SQL
PDBAUDIT are longer than the 262 character literal length since
Nov 5, 2017 the spaces count and could generate spurious messages
particularly in the QA stream.
Change 35.252 MXGWARN message variable JESNR missing value and blank
VGETJESN TYPETEST is suppressed for records with SUBSYS='SMS' and
Nov 4, 2017 JCTJOBID='INIT'; variable values are unchanged as those
records for tasks in initiation have neither.
VGETJESN already suppressed warning for JCTJOBID='MSTR'.
Change 35.251 Support for CICS/TS 5.4 Statistics STID=21, adds BMS 3270
EXCICASG counters to the CICVT (VTAM) dataset, new STID=149 record
VMAC110 creates new CICASG Statistics for the AS Domain.
VMXGINIT
Nov 3, 2017
Thanks to Perry Lim, Union Bank, USA.
Change 35.250 Support for Thruput Manager fields JBAACT JBDEA JLIMT and
VMACTPMX REQUIRED.
Nov 4, 2017
Thanks to Kurt Gramling, TSYS, USA.
Change 35.249 -Support for z/OS 2.3 RMF III CPUG3 record dataset ZRBCPU
VMACRMFV changed CPUHOOFF offset value caused some variables to
Nov 3, 2017 be wrong, notable the Capacity Group Name and adjacent.
-Variable ASICPUTA in ZRBASI dataset will be larger with
this change, as IBM has added new accumulated ASICPUTA_LF
(long float) field with higher resolution, which is now
deaccumulated and REPLACES ASICPUTA's original value.
New variable ASICPUTA_ORIG contains the original value.
The ASICPUTA_LF was 18% larger than ASICPUTA_ORIG.
-These accumulated fields are also now deaccumulated:
ASITET ASITRT ASITCBTA_LF ASIIOCNT_S ASITRCA_S
Thanks to Kurt Gramling, TSYS, USA.
Change 35.248 Variables QWA225SS and QWB225SS are now kept in DB2STATS,
VMACDB2 and two new-in-DB2 V12 REAL2G variables are input/kept.
Nov 1, 2017 QWA225SS='DBM1*31-BIT*IN-USE*SYSTEM*AGENTS'
QWB225SS='DIST*31-BIT*IN-USE*SYSTEM*AGENTS'
QWA225HVPAGESINREAL2G='DBM1*HVPAGES*IN*REAL2G'
QWB225HVPAGESINREAL2G='DIST*HVPAGES*IN*REAL2G'
Thanks to Rick Southby, IAG, AUSTRALIA.
Change 35.247 Removed a debugging statement and corrected an 'uninit'
ANALDB2R variable message
Oct 30, 2017 -If you used INTERVAL=, BEGTIME=, or ENDTIME= and did not
specify a SORTBY= the default is BY QWHSSSID QWHCPLAN and
QWHCAID, so datetime variable QWACBSC is not carried
forward and no accounting report was created; this could
also cause duplicate variables in SORTBY list if QPACPKIC
PACKTYPE or QWHSTCK were in the tailored SORTBY list.
Change 35.246 -SMF 113/HIS formulas for the z14 were updated by IBM with
ASUM113 L3P changed, which is also impacted the RNI value which
VMAC113 uses L3P.
VMACVMXA -The z13 code set the SM1132SP Speed value to 5000 because
Oct 27, 2017 the value was wrong, but that code was removed for the
z14, as those records contain the expected 5208 MHz.
-John's updated formulas are available at
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TC000066
Thanks to John P. Burg, IBM, USA.
Thanks to Nick Varley, SYNCSORT, USA.
Change 35.245 SMF 119 Subtype 81 INPUT STATEMENT EXCEEDED because MXG
VMAC119 expected full 4096 length for DIRU and DORU fields; now
Oct 27, 2017 DILEN and DOLEN length of text are used for $VARYING4096.
Thanks to David Campbell, Sun Trust, USA.
Change 35.244 New parameters TRNDKEEP and SPINKEEP added to let you
VMXGALOC control how many copies of each are retained.
Oct 27, 2017
Change 35.243 MOBILE WORK CSV files for CICS/TS 5.3+ were missing the
FORMATS CICS Product Number; format MGIBMCI needed a new entries
Nov 1, 2017 with 70='5655-Y04' and 71='5655-Y04'.
Other related formats were also updated.
Thanks to Patrick J. Holloman, Navy Federal Credit Union, USA.
Change 35.242 Support for Power Exchange Version 10.1.1.
VMACPOEX
Oct 25, 2017
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 35.241 -Typo, NEDNC=SMFTIME should be NENDC=SMFTIME.
ANAL119 -Uninit variables and incorrect date corrected 12/31.
Oct 23, 2017
Dec 31, 2017
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Thanks to Earl Kline, Luminex, USA.
Change 35.240 Support for APARs OA52132, OA52133, and OA61734, some of
VMAC42 which fields were listed in the z/OS 2.3 SMF Manual.
Oct 23, 2017 CODE HAS NOT BEEN TESTED WITH NEW RECORDS.
See Change 35.288.
Change 35.239 MXG 34.09. RMFINTRV fails with macro GOT70PR not resolved
VMXGRMFI when the PDB did not contain the expected PDB.TYPE70PR.
Oct 22, 2017
Thanks to Tracy Davidson, USBank. USA.
Change 35.238 A typo BASEWEEJ should have been BASEWEEK - only affected
VMXGALOC the aging off of old WEEK directories.
Oct 22, 2017
Change 35.237 Internal utility; if the LIBNAME being searched was empty
VGETSORT a spurious message about an invalid DO loop was printed.
Oct 20, 2017
Change 35.236 Duplicate SMF 70 Subtype 1 records can cause bad results
DEDUP701 due to the Split 70s duplicates, added SMT merges and the
Oct 20, 2017 multiple datasets that create TYPE70 that prevent the use
of the normal NODUP in the final sort to remove dupes.
Hash logic from ANALDUPE is executed in the IMACFILE exit
as SMF is read, examining only SMF 70 subtype 1, deleting
duplicates prior to their input and reporting the first
three DUPES on the log if any were found.
You enable the 70 subtype 1 duplicate removal with
//SYSIN DD *
%let macfile=%quote(%include sourclib(dedup701););
Thanks to MP Welch, Bank of America, USA.
Thanks to Garth Bloomfield, DXC Technology, AUSTRALIA.
Thanks to Peter Gray, DXC Technology, AUSTRALIA.
Change 35.235 RMF III ZRBCPU is enhanced with CPC_HOMEFLAG decoded:
VMACRMFV CPCCAPAVAIL='CAPACITY*VALUES*AVAILABLE?'
Oct 20, 2017 CPCVARYCPU ='VARYCPU*OPTION*SET?'
CPCLPARMGT ='WLM*LPAR*MANAGEMENT*ENABLED?'
CPCMTMETRIC='MULTI*THREADING*METRICS*AVAILABLE?'
CPCABSMSU ='ABSMSU*CAPPING*OPTION*SET?'
Thanks to MP Welch, Bank of America, USA.
Change 35.234 BUILDPDB/BUILDPD3 exit EXPDBKEP lets you KEEP= or DROP=
BUILD005 all variables in JOBS/STEPS/SMFINTRV/NJEPURGE/PRINT.
BUIL3005 Macros _KDBJOBS/_KDBSTEPS/_KDB30UV/_KDBNJEP/_KDBPRIN
EXPDBKEP were defined but were not referenced. You put all your
Oct 21, 2017 definitions in EXPDBKEP in your USERID.SOURCLIB using
MACRO _DBJOBS KEEP= A B C D . . %
or
MACRO _DBJOBS DROP= A B C D . . %
and then you instantiate them in BUILDPDB SYSIN using
%LET MACKEEP= %QUOTE( %INC SOURCLIB(EXPDBKEP); );
%INCLUDE SOURCLIB(BUILDPDB);
Thanks to Thomas Orlando, UBS, SWITZERLAND.
Change 35.233 Protection for truncated SMF 80 Extended Relocate segment
VMAC80A with 12 fields expected but only 10.5 fields are in the
Oct 19, 2017 SMF record. MXGERROR for the first three instances.
Record may have been truncated by ftp processing.
Change 35.232 Documentation. The zIIP CPU time for BMC Utilities is
TYPE30 not recorded in SMF 30 records for the JOB/ASID of the
Oct 19, 2017 Batch Utility job, but is in the 30s for BMC's XBM
Started Task. IBM Utilities do record zIIP CPU time in
the SMF 30 for the batch job.
Change 35.231 Macro variable RACFDIRECTED allows DELETE of RACF records
VMAC80A using the SMF80DTP/RACFTYPE=44 relocate segment, using
VMXGINIT segments with the subkeyword/EV44TXT='ORIGINATED_FROM'.
Oct 18, 2017 MXG now populates variables NODE80A USERID and DIRECTED
Dec 7, 2017 with values of DIRECTED_BY_AT, DIRECTED_BY_ONLY_AT or
DIRECTED_AUTOMATICALLY. You would use this syntax:
%LET RACFDIRECTED=
%QUOTE( IF NODE80A IN ('NODE1','NODE2') AND
USERID IN ('USERID1','USERID2')
THEN DELETE; ) ;
%INCLUDE SOURCLIB(TYPS80A);
-Dec 7: NODE was changed to NODE80A to avoid a conflict if
TYPE80A and TYPE6 were used together. The three fields
are created for the test but are not kept.
Thanks to Kerry J. Sommers, John Deere, USA.
Thanks to Joan T. Keemle, John Deere, USA.
Thanks to Francois Vancoppenolle, P&V Group, BELGIUM.
Change 35.230 -GRAFCEC adds graphs of CPU and zIIP hours and the 4HR MSU
GRAFCEC Avg consumption. GRAFCEC now creates all of the charts
GRAFLPAR previously produced by GRAFLPAR, plus some new ones, thus
Oct 17, 2017 GRAFLPAR obsolete. And GRAFCEC now allows multiple input
libnames. Dataset ASUMCELP must exist in the first data
library and must have non-zero obs, or GRAFCEC will die
with a dataset not found error.
-GRAFLPAR error if you specified PDB=PDB PDB1 and using
SAS/GRAPH, it failed trying to write the graphics catalog
to two libnames. Catalog will only be written to the
first of the two or more libnames specified by PDB=.
But note GRAFLPAR is now obsolete, replaced by GRAFCEC.
Thanks to Daniel Mckinzie, Zions Bank, USA.
Change 35.229 -Revised logic for DB2 Statistics Datasets deaccumulation
VMACDB2 now protects for lost/skipped intervals of input data for
Oct 23, 2017 for these datasets:
DB2STATB DB2STSBP DB2GBPST DB2NETZA
DB2STAT5 DB2STAT0 DB2STAT1 DB2STATR.
Large gaps (like missing a day) with repeated values in
QWHSISEQ caused large DURATM which caused BEGTIME to be a
different date. Since DB2 SMF 100 stat records can only
be written at one minute intervals, MXG now detects a gap
of more than 120 second as the start of a new interval,
and it is DIF()'d but not output.
However, neither BEGTIME nor ENDTIME are on the minute
DURATM values of a few seconds up to 100 seconds have
been observed, hence the test value of 120 seconds.
-DB2STATS Variables QISEDPSL QISEDPSC QISEDPSM QISEDPSF
were incorrectly input with DB2 V11; the test GE 32 is
corrected to GE 232 for their input.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.228 Support for up to 20 user character fields in CICSTRAN,
IMACICAU USERCHAR1-USERCHAR20, increased from only nine fields.
IMACICBU
IMACICCU
IMACICDU
IMACICEU
IMACICFU
IMACICGU
IMACICHU
IMACICIU
IMACICJU
IMACICKU
IMACICLU
UTILEXCL
VMAC110
Oct 11, 2017
Change 35.227 If you specified RMFINTRV=NO many bad things could have
UTILBLDP happened. First, if you did not also suppress one or
Oct 17, 2017 more of the records used by BUILDPDB, then RMFINTRV=NO
was ignored because the code looking for it was inside
of the SUPPRESS= logic. If you DID suppress something
then you could have hit a problem with a missing %
sign on a MACRO.
-User ABENDS are replaced by messages on the OUTFILE to
tell you there was an error that terminated UTILBLDP.
-if you suppress type 26 without specifying J2 or J3
it will now generate an error
-if you useradd 102 without specifying the subtype
it will now generate an error
Thanks to Trevor Holland, ANZ, AUSTRALIA.
Change 35.226 Unused Change Number.
Change 35.225 WARNING: VARIABLE YSTEM NEVER REFERENCED because SYSTEM
VMACTMO2 was missing the first S.
Oct 10, 2017
Thanks to Derek Purves, FDIC, USA.
Change 35.225 -New UTILBLDP Parameters EXPDBVAR/EXPDBCDE/EXPDBOUT added
UTILBLDP to enable more tailoring and specifically to make it easy
Oct 8, 2017 to create a new dataset with a subset of variables and
obs from an existing MXG dataset, like this example to
create new CICSTRIM dataset with a subset of CICSTRAN
variables, and output only for selected CICS APPLIDs:
USE EXPDBVAR TO BUILD A SUBSET OF CICSTRAN DATA FOR
REPORTING PURPOSES
%UTILBLDP(OUTFILE=INSTREAM,
BUILDPDB=YES,
OUTFILE=INSTREAM,
EXPDBVAR=
CICSTRIM (KEEP=APPLID TRANNAME STRTTIME ENDTIME
CPUTM ELAPSTM TASKNR USER ABCODE),
EXPDBOUT=
PROC SORT DATA=CICSTRIM OUT=PDB.CICSTRIM;
BY ENDTIME APPLID TRANNAME TASKNR;,
MACKEEPX=
MACRO _ECICTRN
IF (RTYPE= 'E3'X OR RTYPE = 'T')
AND APPLID
IN('CICSZFN3','CICSAUD3','CICSDBS')
THEN OUTPUT CICSTRIM;
OUTTPUT _WCICTRN; %
);
Change 35.224 The _N110 "Product Null Macro" to suppress all CICS data
VMAC110 sets for tailoring had new datasets added which caused
Oct 8, 2017 only one dataset listed per line; that statement now has
two datasets per line, half as many lines/bytes.
Change 35.223 The extra zVPS/XAM SYTCUP segment with totals was not
VMACXAM included in the SYTNLPS count of segments, and there is
Oct 7, 2017 no LENDATA value for each subsegment, so MXG assumed 20
for LENDATA and detected the extra subsegment when SEGLEN
was NE 20*SYTNLPS, but the 35.09 correction statement
SYTNLPS=SYTNLPS+1 was mistyped as SYTNLPS=SYTNLPS=1; so
only one obs per LPAR was output in XAMSYT dataset.
But other MXG corrections have increased the obs count,
depending on past MXG Version (eg. 35.06 to 35.09).
There will be one obs for each LCPUADDR in each LPARNAME,
and an extra "total" obs with LCPUADDR='60'x (doc '40'x)
for each Engine Type in each LPARNAME, but these "total"
obs all have zero values in 4303 and 4313 releases.
There are also a pair of original LPARNAME='Totals'
subsegments at the start of each SYTCUP segment that are
not output by MXG.
Thanks to Paul Volpi, UHC, USA.
Thanks to David A. Sadler, UHC, USA.
Change 35.222 Unused Change Number
Change 35.221 Many zVM VXPRCPUP dataset variables values were not
VMACVMXA divided by 65536, two variables needed deaccumulation.
Oct 4, 2017 The segment SSIZE is 96 but only 72 are documented.
Thanks to Pat Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
Change 35.220 MXG 35.09. Zero observations in TYP11920 dataset due to
VMAC119 a debugging asterisk left where it shouldn't have been in
Oct 4, 2017 line 2942 of VMAC119.
Thanks to Paul Volpi, UHC, USA.
Change 35.219 MQMACCT variable NETSNAME is created from QWHCTOKN if it
VMAC116 is populated, or from QWHCNID in not, but the format of
Oct 4, 2017 the raw data is different; heuristics were revised to
recognize two formats found in this site's data, with
values AAAAAAAA.BBBBBBBB if QWHCTOKN is populated or
values CCCCCCCC.L when QWHCTOKN is not populated.
NETSNAME is also kept in MQMACCT1 and MQMQUEUE but it
should not have been, as it is always blank for those two
datasets. And NETSNAME is not populated in MQMACCT
observations from BATCH/TSO Attach.
Thanks to Jim Poletti, Edward D Jones, USA.
Thanks to Art Morelock, Edward D Jones, USA.
Change 35.218 XAMSYPUP dataset's INPUT is now correctly aligned once it
VMACXAM was explained that PL/1 "3 rsrvd(4) Char(4)" is SAS +16.
Oct 3, 2017
====== Changes thru 35.217 are in this MXG 35.09 dated Oct 2, 2017=====
Change 35.217 Cosmetic, but format $MGSMFID had undetected-by-SAS
ANALID unbalanced quotes that impacted SMF ID=80 descriptions in
FORMATS the ANALID SMF Report (default is on in BUILDPDB).
Oct 2, 2017 Also option UNIFORM was added to the SUMMARY PROC PRINTs.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 35.216 New macro that lets you 'join' variables from DB2ACCT
JOINDB2 to the corresponding DB2ACCTP observations. Written
Oct 2, 2017 specifically to capture QWACWLME since the DB2ACCTP
records do not contain the QWAC segments but will
copy as many variables as you like from DB2ACCT to
DB2ACCTP. NOTE: QWACWLME only exists in DDF records
and that is by IBM's design.
====== Changes thru 35.215 are in this MXG 35.09 dated Oct 2, 2017=====
Change 35.215 TRENDINT defaulted to WEEK rather than the value of the
VMXGRMFI INTTRND macro variable as documented. Also the TRNDRMFI
TRNDRMFI member was updated to include the TRENDINT parameter so
Oct 2, 2017 that you can more easily see how to modify the interval.
Thanks to Steve Carlson, UCOP, USA.
Change 35.214 Modified for efficiency. If you specify ROLLSORT=NO
UTILROLL it now uses PROC APPEND instead of a data step which had
Sep 30, 2017 to read both the input (ROLLTO) and output (ROLLFROM)
datasets.
Change 35.213 z/VM variable VMDUFACT in dataset PDB.VXBYUSR should not
VMACVMXA have been deaccumulated as it is an end of interval count
Sep 28, 2017 of frames.
Thanks to Graham Harris, RBS, ENGLAND.
Change 35.212 Support for SMF 30 User Key CSA Audit Enhancements adds
VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and
Sep 28, 2017 the TYPE30_5 datasets. This code change has been in MXG
Feb 28, 2018 35.09 and later, but this change text replaced previous
"Reserved Change" on Feb 28, 2018. This field was added
by APAR OA53355, but will only be needed thru z/OS 2.3,
as User Key Common Storage usage support ends there.
This is Health Check ZOSMIGV22R3_NEXT_VSM_USERKEYCOMM.
These APARs required no additional code changes:
OA53434 Corrects ASM DSECT Lengths, no MXG impact
OA53289 Corrects value of SMF30HVR from zero to valid.
OA45767 APAR that added the extra triplet caused OA53434
Change 35.211 Documentation. Variables QWACWLME QWACBSC QWACESC should
VMACDB2 not have been kept in DB2ACCTP after IBM moved the DB2
Sep 27, 2017 Package Data (IFCID 129) to its own ID=101 Subtype=1
record, which does not contain a QWAC segment.
Thanks to Glen Bowman, Wakefern, USA.
Change 35.210 Support for z14 SMF 113 records (INCOMPAT, EXTENDED array
ASUM113 now has 128 entries). Default LABELs are now for z14.
VMAC113 To change the default labels for z13, you would use:
Sep 27, 2017 //SYSIN DD *
Oct 1, 2017 %LET MACKEEP= MACRO _XLA113 _XLA113D % ;
%INCLUDE SOURCLIB(TYPS113,ASUM113);
To create correct labels with both z13 and z14 data, you
must create separate datasets:
//SYSIN DD *
%INCLUDE SOURCLIB(VMACF113);
DATA PDB.ASUM1131Z13;
LABEL _XLA113D ;
SET PDB.ASUM1131;
IF SM113VN2=4;
DATA PDB.ASUM1131Z14;
LABEL _XLA113E ;
SET PDB.ASUM1131;
IF SM113VN2=5;
RUN;
Many of the RNI and other equations were changed for z14.
-You can use OPTIONS OBS=99; _RPT113; RUN; to print those
calculated variables values from PDB.ASUM1131, the data
set you should use, as it contains interval data. The
original ASUM113 data set was accumulated and obs were
lost in deaccumulation.
Thanks to Elie Sawaya, RBC, CANADA.
Change 35.209 -Support for BETA 93 Version 610, altered header fields
FORMATS and three new variables are added to dataset BETA0:
VMACBETA BETAPABS='MAX*PABS'
Sep 29, 2017 BETASPAG='FIRST SPLIT*OVER GT*1 PAB'
Nov 22, 2017 BETABMOD='PAB PAGE*BREAK*MODE'
-New values added to $MGBETAT format for BETA0.
-Support for subtype 51 RDATA1 and RDATA2 fields and
all segments are read and output - previously the first
segment was repetitively output.
See Change 36.074 for Subtype 51 update.
Thanks to Andreas Menne, Finanz Infoirmatik, GERMANY.
Change 35.208 Nigel's Monitor for AIX and LINUX changed BBBP Endtime
VMACNMON was always "HH:MM" text, but new "N MINS" tripped MXG
Sep 27, 2017 variables BBBPENDING051, UPHOURS, and BBBPENDING052,
UPTIME.
Thanks to Steve McCulloch, TMS/CDS Group, CANADA.
Change 35.207 Enhancement for GDG datasets to add FIRSTGEN and LASTGEN
VMAC6156 values of GATGEN to know the range of Generation values.
Sep 25, 2017 No change, but variables GATEXTNO GATVER GATGEN GATWRAP
are from each GAT segment, so they should not have been
kept as they contain only the value of the last cell.
Thanks to Satish Kodavatiganti, John Deere, USA.
Change 35.206 If you need ACCOUNTn fields for long-running STCs in your
BUILD005 PDB.SMFINTRV dataset, you had to set SPINCNT in IMACSPIN
BUIL3005 longer than the number of days between IPLs; if you had a
VMXGINIT smaller value, then only that number of days of the
Sep 25, 2017 PDB.SMFINTRV would have the ACCOUNTn fields populated.
This change creates optional macro variable &SPINSTC to
enable this change and to keep that many day's SPIN30_1
for STCs in the SPIN library for STC accounting, and you
can then set a much smaller value for the spining of you
other jobs. Use %LET SPINSTC=365; to keep a year's data.
A large SPINCNT used to be important when you had lots
of held print output, since BUILDPDB waits for the
PURGE (26) record to know all SMF records for the job
have been created. But now, with output typically sent
to a spool handler, almost all jobs PURGE right after
they terminate on z/OS, so now, you can set a small
SPINCNT (1 or 2) and only SPIN the jobs that were in
execution when SMF was dumped, or that run for more
than a full day or two.
Thanks to Gennady Katsnelson, IBM Global Technology Services, USA.
Change 35.205 Documentation of what is counted in SMF 30 EXCP counts,
TYPE30 from a posting to IBM-Main:
Sep 25, 2017 The EXCP count fields count whatever the IOS Driver
decided to pass into SMF in the IFASMFEX exit that
accumulates the type 30 EXCP fields.
For example:
-For SAM, EXCP (an IOS driver) lets SAM do the calls
to IEASMFEX.
-For non-SAM use of EXCP, EXCP calls IEASMFEX with
a count of 1 so for non-SAM use of EXCP, it is the
count of EXCPs
-And IEWFETCH (an IOS driver which fetches load modules)
counts the number of SSCH for non-VIO data sets, and
uses EXCP for VIO data sets. So either way, it is the
number of channel programs executed.
Thanks to Jim Mulder z/OS Diagnosis,Design,Development,Test IBM Corp
Change 35.204 Support for DB2 APARs PI71903 and PI84045 adds these
VMAC102 new variables to IFCID 376 T102S376 dataset:
Sep 28, 2017 QW0376SC='SCHEMA*NAME'
Oct 11, 2017 QW0376PR='SPECIFIC*NAME'
Dec 7, 2017 QW0376INC='INCOMPAT*PARMS'
QW0376SQL='SQL*TEXT';
Dec 7: Offsets for VL/VN corrected, no data for these
new fields yet.
Thanks to Lori A. Masulis, FMR, USA
Thanks to Steve McKee, FMR, USA.
Change 35.203 z/VM 6.4.17.1 INCOMPATIBLE, fields inserted in SYTCUP and
EXSYTLCX SYTLCK, and new VXSYTLCX data set created.
VMACVMXA -In SYTLCK when there are no shared/exclusive lock entries
VMXGINIT (CALNMSXE=0) there are 8 bytes inserted where that second
Sep 28, 2017 array should not have existed.
-In SYTCUP, SKIP logic was not correct with new data.
Thanks to Dr. Wolfgang Kueller, IT Solutions, AUSTRIA
Change 35.202 Typo TEN should have been TUE. Most likely not an issue
VMXGALOC since that section of code was only used to CLEAR any
Sep 18, 2017 existing LIBNAMEs before allocating new ones (which in
any case would happen when a new LIBNAME statement was
issued).
Thanks to Steve Bagshaw, Marks & Spencer, ENGLAND.
Change 35.201 Modified to limit the number of LIBNAMEs reported where
PDBAUDIT the path name is the same. First looks for a PATH where
Sep 18, 2017 the LIBNAME is PDB and deletes any other LIBNAMEs with
that path then sorts on PATH and LIBNAME eliminating
all but the first occurrence of each PATH so that there
are not a lot of duplicate lists. Needed for MXG QA.
-A new parameter PATHLIST= added with a default value
of NO. Change to YES to create report of the LIBNAMES
by PATH. Useful if you are running with AUTOALOC=YES.
Change 35.200 New BLDSMPDB parameters support writing daily, weekly,
VMXGALOC monthly and trend "PDB's" to different paths (drives or
VGETALOC directories). All default to the BASEDIR if left blank.
BLDSMPDB BASEWEEK= sets the location of weekly database
Sep 13, 2017 BASEMONTH= sets the location of monthly database
BASETREND= sets the location of TREND database
If you choose to use these new destinations for your
output of BLDSMPDB, be aware and use caution since the
old destination's files will NOT be aged off, nor will
they be allocated for monthly/weekly processing. You will
need to copy old data from the old path to the new path.
Change 35.199 z/OS 2.3 type 90 subtype 38 INPUT STATEMENT EXCEEDED due
VMAC90A to incorrect offset and field length in the GA SMF manual
Sep 17, 2017 for SMF90T38_UTOKENUSERID which is 16 not 8 and at offset
112 and not 118. Subtype 38/39 datetimes are now local.
Thanks to Bernie Ethridge, Fiserv, USA.
Thanks to Paul Naddeo, Fiserv, USA.
Change 35.198 z/VM 6.2.11 SYTLCK "BROKEN RECORD" error because SKIP was
VMACVMXA not calculated correctly.
Sep 11, 2017
Thanks to Kare Martin Torsvik, EVRY, NORWAY.
Change 35.197 IMF CIMSTRAN dataset datetime variables all now have
VMACCIMS microsecond resolution; MXG had overlooked the MIJUs.
Sep 16, 2017 ACTARRV ARRVTIME STRTTIME TRNETIME ENDTIME TRNSTCKE
Oct 26, 2017 INPQUETM, SERVICTM and RESPNSTM are now calculated from
those datetimes for microsecond resolution.
Thanks to Randy Hewitt, DXC Technology, USA.
Change 35.196 Support for BETA 97 extended header (INCOMPATIBLE) V 610.
EXTYB97D All variables in all datasets are now INPUT and correct.
IMACBE97 New dataset BE979751D is created from Subtype 51 with the
VMACBE97 database field details.
VMXGINIT
Sep 15, 2017
Thanks to Andreas Menne, Finanz Infoirmatik, GERMANY.
Change 35.195 Support for PRCPUP segment in zVPS XAMSYS records creates
EXXAMPUP new dataset DDDDDD DATASET DESCRIPTION
IMACXAM XAMPUP XAMSYPUP PRCPUP DATA
VMACXAM -The test for invalid SYTCUP segment was revised when the
VMXGINIT old test incorrectly reported an invalid segment.
Sep 15, 2017
Change 35.194 Unrequested log messages containing MXGDEBUG: VMXGOPTR
ANAL116 were printed if you %LET MXGDEBUG= to a non-blank value.
ANALDB2R The LENGTH(&MXGDEBUG) test was removed from VPUTMSG and
ASUMDB2A relocated to each calling member, with revised logic:
ASUMDB2R %IF %UPCASE(&MXGDEBUG) NE VMXGSUM1 %THEN %DO;
ASUMNTIN %VMXGOPTR(OPTNAME=NOTES,NEWVALUE=NONOTES);
TESTTRND %END;
TRNDNTIN The MXGDEBUG macro variable is primarily for internal MXG
VGETALOC testing and it exists in only a few members; the enable
VMACDB2 values are documented in each member's test statements.
VMXG70PR With this correction. MXGDEBUG=VMXGSUM1 was used for MXG
VMXGALOC QA which exposed these overlooked corrections:
VMXGDSN -ASUMDB2A QXHJINT typo was observed and removed.
VMXGOPTR -VMXG70PR LPMSUHR was missing.
VMXGRMFI -ANAL116 had a superfluous ID=ENDDT argument, removed.
VMXGSUM -VGETALOC/VMXGALOC protected for blank MXGDEBUG.
VPUTMSG -VMXGSUM many calls to VPUTMSG revised so VMXGSUM1 now
Sep 10, 2017 is also enabled if 2/3/4 are requested.
-VMACDB2 did not keep SHIFT in DB2ACCTR dataset.
-VMXGRMFI had spurious SMF70GMN SMF70GMU MXGDEBUGs.
-ASUMNTIN did not keep one variable
-TESTTRND builds PDB.CICS from ASUMCICX, clearing the
first PDB.CICS created by ASUMCICS which had different
kept variables and is not the recommended CICS summary.
-ASUMDB2R needs KEEPALL=YES for missing variable notes.
-TRNDNTIN needed a variable added to KEEP list.
Thanks to Donald Blaszka, WiPro, USA.
Change 35.193 Alignment correction for SMF74SBR/SBW/SQR/SQW sync I/O
VMAC74 variables, and new SMF74SQRRATE/SMF74SQWRATE sync rates.
Aug 30, 2017
Change 35.192 Variables WTASINTE/WTASINTS/WTASSTRT in MQMQUEUE dataset
VMAC116 are missing values in obs created from SMF 116 Subtype 2
Aug 29, 2017 (continuation) records, but now INTS/STRT are populated
by WQTTTIME and INTE is populated by SMFTIME.
Thanks to Raymond J. Smith, OPTUM, USA.
Change 35.191 -Support for z/OS 2.3 ZRBASI and ZRBUWD new fields are now
VMACRMFV validated so the bypass execution tests (-99 EQ 99) are
Sep 5, 2017 are now removed.
-Variable GEIFLG2 is now INPUT and kept in ZRBGEI dataset.
-Unpopulated Extended Length EDE segment overlaid original
INPUT of variables EDEPCKG EDEPROC EDEUSER EDETRXN EDEACC
with blank values.
-Overlooked OPD variables now INPUT and kept:
OPDDCTIIP='DELTA*TCB TIME*FOR*ZIIP'
OPDCTIIP='PROCESS*SYSTEM*USER COMPUTE*ON ZIIP'
Thanks to Kurt Gramling, T-SYS, USA.
Change 35.190 SMF type 2 subtype 2 (SMF Signature enabled), ERROR INPUT
VMAC0203 EXCEEDED RECORD LENGTH due to MXG INPUT mis-alignment.
VMACSMF -Dataset TYPE0202 now keeps those signature variables, and
Aug 28, 2017 dataset TYPE0203 reverts to the way it originally was,
keeping only the header variables.
-BUT: the type 2 subtype 1/2 records have SYSTEM='DUMY'
in the SMF header! Since that is not a real system name,
and because it could confuse any SMF Audit or analysis,
MXG's handling of the _SMF header in VMACSMF now detects
type=2 subtype=1/2 and SYSTEM='DUMY' and changes SYSTEM
to the actual SYSTEM (SMF2IRSID/SMF2GRSID) name.
Note: See Change 38.034 for revisions.
Thanks to Daniel Erikols, Svenska Handelsbanken, SWEDEN.
Change 35.189 Variables QPAC_PIPE_WAIT and QPAC_PIPE_COUNT are INPUT
VMACDB2 and kept in dataset DB2ACCTP.
Aug 25, 2017
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.188 If default was set to "work" rather than "WORK" the case
VMXGDEL mismatch caused datasets to be deleted,
Aug 25, 2017
Change 35.187 Variable SM123USERNM was not kept, spelled SM123TARURI in
VMAC123A the KEEP= list.
Aug 23, 2017
Thanks to Patricia Hansen, ADP, USA.
====== Changes thru 35.186 are in this MXG 35.08 dated Aug 24, 2017=====
Change 35.186 New variables MKFLAGA/MKRLSOPT/MKLRTIME are created and
VMACEDGS kept in EDGSKREC dataset; variable MKSTORE2 is no longer
Aug 23, 2017 valid, as it now contains the time part of MKLRTIME.
Aug 25, 2017 MKLRTIME='LAST*REFERENCE*DATETIME'
MKFLAGA ='FLAG-A'
MKRLSOPT='RELEASE OPTIONS'
-Aug 25: MKLRTIME was missing value because 2-byte field
before the new date value was not documented, but the
hex record and doc offset showed 2 bytes were inserted.
Thanks to Marybeth Delphia, CPA Texas, USA.
Change 35.185 Change 35.167 forced you to have a PDB libname when you
BLDSMPDB may not have needed one. There are 4 executions of
Aug 22, 2017 VGETSORT within BLDSMPDB with differing needs.
If running with RUNWEEK=YES the LIBNAME pointed to by
WEEKSTRT is used
If running with RUNWEEK=WTD the LIBNAME pointed to by
PDB is used
If running with RUNMNTH=YES the LIBNAME pointed to by
WEEK1 is used
If running with RUNMNTH=MTD the LIBNAME pointed to by
PDB is used
Change 35.184 Test for LIBNAME count was removed as unneeded and it
PDBAUDIT caused termination of the QA test job with 35 libraries,
Aug 23, 2017 and PDB.PDBAUDIT and SPIN.SPINAUDIT datasets not created.
The original error it was supposed to prevent was found
to be unrelated the LIBNAME count.
Change 35.183 Five IFCIDS create new datasets, but only T102S389 and
EX102389 T102S477 have the IFCID-specific variables; the three
EX102404 others identify the event, but keep only the thirty-six
EX102413 variables from the DB2 Header and Product segments.
EX102414 DDDDDD DATASET DESCRIPTION
EX102477 102389 T102S389 ALL INDEXES WITH FTPS
IMAC102 102404 T102S404 AUTHORIZATION COMPATIBILITY
VMAC102 102413 T102S413 BEGIN WAIT FOR PIPE SUSPEND
VMXGINIT 102414 T102S414 END WAIT FOR PIPE SUSPEND
Aug 22, 2017 102477 T102S477 ALOC/DEALOC FAST TRAVERSE BLOCK
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 35.182 MXG 35.07. INPUT STATEMENT EXCEEDED RMF 74, Change 35.166
VMAC74 tested SMF748LL instead of SMF748CL for the INPUT of the
Aug 17, 2017 new field, which "worked" when there were link segments,
but this record had only the control segment and non-zero
R748CRTN Return Code.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 35.181 Support for four new SYTSTSCP variables added:
VMACXAM
Aug 16, 2017
Change 35.180 MXG 35.07. SMF 92 Subtype 50 INPUT STATEMENT EXCEEDED due
VMAC92 to MXG typo of 44 vs 4 in the INPUT, but also the 16-byte
Aug 18, 2017 STCKE format SMF92T50 was not decoded correctly. IBM also
changed the format of SMF92RVN from NUM2. to PIB2., which
caused INVALID DATA FOR SMF92RVN error messages.
Change 35.179 Utility reads SMF and writes records for wanted JOBnames.
UWRITSMF
Aug 16, 2017
Change 35.178 Support for APAR OA49692 which adds variables to the BCP
VMAC98 SMF type 98 record:
Aug 14, 2017
SM98SIG_AVG_CPUBUSY_CP='AV CP PCT*CPU BUSY*HIGH MTTW*/
SM98SIG_AVG_CPUBUSY_ZAAP='AV ZAAP PCT*CPU BUSY*HIGH MTTW*/
SM98SIG_AVG_CPUBUSYR_ZIIP='AV ZIIP PCT*CPU BUSY*HIGH MTTW*/
SM98SIG_AVG_FDISPSPERWAKEUP_CP='AV CP FOREIGN*DISPATCHES*HIGH MTTW*/
SM98SIG_AVG_FDISPSPERWAKEUP_ZAAP='AV ZAAP FOREIGN*DISPATCHS*HIGH MTTW*/
SM98SIG_AVG_FDISPSPERWAKEUP_ZIIP='AV ZIIP FOREIGN*DISPATCHS*HIGH MTTW*/
SM98SIG_TOP_CPU_CP='CP CPU WITH*LARGEST*MTTW VALUE*/
SM98SIG_TOP_CPU_ZAAP='ZAAP CPU WITH*LARGEST*MTTW VALUE*/
SM98SIG_TOP_CPU_ZIIP='ZIIP CPU WITH*LARGEST*MTTW VALUE*/
SM98SIG_2ND_CPU_CP='CP CPU*2ND LARGEST*MTTW VALUE*/
SM98SIG_2ND_CPU_ZAAP='ZAAP CPU*2ND LARGEST*MTTW VALUE*/
SM98SIG_2ND_CPU_ZIIP='ZIIP CPU*2ND LARGEST*MTTW VALUE*/
SM98SIG_TOP2_MTTW_CP_TIMETOD='AV MTTW VALUE*FOR TOP*CP CPUS*/
SM98SIG_TOP2_MTTW_ZAAP_TIMETOD='AV MTTW VALUE*FOR TOP*ZAAP CPUS*/
SM98SIG_TOP2_MTTW_ZIIP_TIMETOD='AV MTTW VALUE*FOR TOP*ZIIP CPUS*/
SM98AVG_FDISPSPERWAKEUP_CP='AV FOREIGN*DISPATCHES*CP CPUS*/
SM98AVG_FDISPSPERWAKEUP_ZAAP='AV FOREIGN*DISPATCHES*ZAAP CPUS*/
SM98AVG_FDISPSPERWAKEUP_ZIIP='AV FOREIGN*DISPATCHES*ZIIP CPUS*/
Change 35.177 PDB.ROSCOE dataset Logon Time ROSIGNON was incorrectly
VMACROSC set to the ROSTIME, Roscoe ASID Step Initiate Time, also
Aug 11, 2017 causing thee CONECTTM calculation to be incorrect.
Thanks to Janne Jarvinen, CGI, FINLAND.
Change 35.176 Support for new BBMQ QSDSTYPE='DISTRIBUTED*SYSTEM*TYPE'
FORMATS variable added (compatibly) to BBMQQUES dataset with new
VMACBBMQ $MGBBMQT format decoding A=AS400, W=Windows, U=Unix.
Aug 10, 2017
Change 35.175 Support for these APARs required no MXG code changes:
VMAC30 OA53289 Corrects value of SMF30HVR from zero to valid.
Aug 9, 2017 OA53434 Corrects ASM DSECT Lengths, no MXG impact
OA45767 APAR that added the extra triplet caused OA53434
Change 35.174 The original CPITCBTM/CPISRBTM "step initiator" CPU times
BUILD005 are totals, but CPITCITM CPISRITM are the "init" time of
BUIL3005 day, at step initiation, and CPITCTTM CPISRTTM are the
Aug 8, 2017 "term" time of day so those CPU times can be assigned to
the correct time of day (ALOCTIME or TERMTIME). All four
are now kept in both PDB.STEPS and PDB.JOBS.
that separated the original CPITCBTM/CPISRBTM
are now correctly input and are negatively deaccumulated
Thanks to David E. Kibitelsky, Broadridge, USA.
Change 35.174A zVM VXBYUSR dataset variables _MT1 and _PRO (SMT times)
VMACVMXA are now correctly input and are negatively deaccumulated
Aug 5, 2017 with -DIF() while many CALxxxxx accumulated variables are
positively DIF'ed, with no clue in the doc if the accum
is descending or ascending, except to look at data.
Change 35.173 Support for SMF 119 Subtype 11 for ZERT data creates two
EXT11911 new datasets
EXT119DN DDDDDD DATASET DESCRIPTION
FORMATS T11911 TYP11911 ZERT ENCRYPTION SUBTYPE
IMAC119 T119DN TYP119DN ZERT DISTINGUISHED NAME
VMAC119 -There is no GMT offset in Subtype 11 records; for the
VMXGINIT SAEVENT 03x and 04x Termination records, SAETIME is used
Aug 4, 2017 and for 01x and 02x Connection records, SASTIME is used
Aug 20, 2017 with SMFTIME and fuzzy logic to reset SASTIME/SAETIME to
Aug 30, 2017 the local time zone.
-Only records with TLS or SSH protocol have been tested
with data; no IP-Filter nor IPSEC records have been read.
-Aug 30: INPUT EXCEEDED. Line 2775 in VMAC119 should be:
SMF119SC_TLS_CCERT_SER_LEN &PIB.1.
instead of &PIB.1. This was not in MXG 35.08.
Thanks to Thomas Liu, Australia New Zealand Banking Group, AUSTRALIA
Change 35.172 New ThruputManager fields INCLA1 JXJOU JXSTA1 JXSTA2 are
VMACTPMX supported.
Aug 3, 2017
Thanks to Scott Wiig, USBank, USA.
====== Changes thru 35.171 are in this MXG 35.07 dated Aug 2, 2017=====
Change 35.171 zVM SMT Equivalent Time _MT1 variables in VXBYUSR dataset
VMACVMXA now divided by /4096 to convert value to seconds.
Aug 2, 2017
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.170 MXG spuriously reported MISSING TYPE 70 RECORDS for VM
VMXG70PR LPARs on IFLs. Now both MXGCIN and VMSYSTEM are used to
Aug 2, 2017 remove those unwanted observations.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 35.169 The incorrectly spelled variable QPSTDTW was kept in both
VMAC115 MQMBUFER and TY115215, but the correctly spelled QPSTDWT
Jul 31, 2017 was only valid in MQMBUFER, and was missing in TY115215.
Now both variables are valid in both datasets.
Thanks to Doris Bentrez, IBM, USA.
Change 35.168 Two errors both would show up when PDB= pointed at more
ANALDB2R than one LIBNAME. First the VGETOBS looking for the
Jul 28, 2017 DB2 datasets would fail looking at multiple libnames.
Once that was fixed ANALDB2R only used the first in the
list of LIBNAMES - now it will use them all.
Change 35.167 BLDSMPDB uses VGETSORT to determine the contents of
BLDSMPDB your LIBNAMES and the sort sequences (or lack) of
Jul 28, 2017 all of the datasets. It inconsistently used differing
libnames to make that determination which could miss
newly added datasets or changed sort orders. It will
now use the BASEPDB (usually PDB) LIBNAME in all cases
so that it will find the most recent examples.
-New option added to RUNWEEK. RUNWEEK=FORCE will force
the running of the weekly processing. Point FORCEDAY
to the last date in the week if running with AUTOALOC.
-If you are running on ASCII with AUTOALOC=YES we do
not recommend using WTD or MTD processing as it can
make ABEND recovery difficult if the WTD or MTD
processing was done prior to the ABEND.
We also do NOT recommend modifying default SORTEDBY
value from NO to YES since a change in sort orders
(as unusual as it might be) could cause problems.
Change 35.166 Support for z/OS 2.3 changes, many new variables, COMPAT.
EXTY9208 -Support for SMF Record Types 127-2047, with ID 0-127 and
EXTY9250 1152-2047 reserved for IBM use, and ID 127-1151 for USER
EXTY9251 SMF record types. The SMF header was extended by using
EXTY9252 never-used ID=126 record type to identify this record has
EXTY9253 the extended header. Note that new SMF exit IEFU86 is
EXTY9254 taken for ALL SMF records, with or without the extended
EXTY9255 header, and existing SMF exits IEFU83/84/85 are called
EXTY9256 ONLY for records with standard header.
EXTY9257 -Dataset TYPE1415 new variables:
EXTY9258 SMF14DEF='ENCRYPTION*FLAG*BYTE'
EXTY9259 SMF14DET='ENCRYPTION*TYPE'
IMAC92 SMF14DKL='DASD*DATA SET*KEY*LABELS'
VMAC1415 Fields exist only if Encryption Subtype 9 exists.
VMAC42 -Dataset TYPE4227 new variables:
VMAC62 SMF42RDSC_OLD='SMF42RDSC*OLD DSCB*DATA*FIELD'
VMAC7072 SMF42RDSC_NEW='SMF42RDSC*NEW DSCB*DATA*FIELD'
VMAC71 SMF42RKEY_OLD='SMF42RKEY*OLD DSCB KEY*DATASET*NAME'
VMAC92 SMF42RKEY_NEW='SMF42RKEY*NEW DSCB KEY*DATASET*NAME'
VMACSMF The _ETY4227 output macro was relocated correctly so it
VMXGINIT is outside the LN2 DO group, causing observations to
VMAC73 now be created that were not previously output.
VMAC74 Tested.
VMAC75 -Dataset TYPE62 new variables:
VMAC76 SMF62DEF='ENCRYPTION*FLAG*BYTE'
VMAC77 SMF62DET='ENCRYPTION*TYPE'
VMAC78 SMF62DKL='DASD*DATA SET*KEY*LABEL'
VMAC79 -Dataset TYPE71 new variables, APAR OA52452 added.
VMACRMFV SMF71RFL='SMF71RFL*FLAGS'
Jul 18, 2017 SMF71NNF='AVG NON-NUC*FRAMES*COMPRISING*STORAGE'
Jul 28, 2017 SMF71LSI='AVG SYS-INIT*DEMOTIONS*LARGE*TO 4K'
SMF71LRI='AVG REQ-INIT*DEMOTIONS*LARGE*TO 4K'
SMF71MHW='HWM 1MB*FRAMES*USED FOR*FIXED 1MB'
SMF71PIS='AVG 4KB*PAGEINS*FROM SCM'
SMF71POS='AVG 4KB*PAGEOUTS*TO SCM'
SMF71PI1='AVG 1MB*PAGEINS*FROM SCM'
SMF71PO1='AVG 1MB*PAGEINS*FROM SCM'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF71DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF71DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Tested.
-Dataset TYPE72GO new variable:
R723GMLM='MEMORY*LIMIT*SPECIFIED?'
R723GMML='MEMORY*LIMIT*GB of*resgroup'
R723CTETX='TOTAL*TRANSACTION*ELAPSED*TIME'
R723CXETX='TOTAL*TRANSACTION*EXECUTION*TIME'
R723CETSX='SUM*ELAPSED*TIME*SQUARED'
R723CQDTX='TOTAL*QUEUE*DELAY*TIME'
R723CADTX='TIME*BATCH JOBS*INELIGIBLE*TO RUN'
R723CCVTX='TIME*BATCH JOBS*SPENT*IN JCL CVTR'
R723CIQTX='TIME*BATCH JOBS*INELIGIBLE*IN JOBQ'
Tested; 35.06 only kept first two variables.
-Dataset TYPE7204 new variable:
R724ETX='TOTAL*EXECUTION*TIME*GROUP'
R724QTX='TOTAL*QUEUE*TIME*GROUP'
R724OR7A='MEMORY*POOL*SHORTAGE'
Tested.
-Dataset TYPE73 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF73DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF73DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Tested.
-Dataset TYPE74 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF74DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF74DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
SMF74ATD='I/O DELAYS*PAV*ALIAS*THROTTLING'
Tested.
-Dataset TYPE74CA new variable:
R745XSCS='SUBCHANNEL*SET*ID'
Tested.
-Dataset TYPE748 new variable:
R748CFSC='SUBCHANNEL*SET*ID*PHYS CONFIG'
R748CSCS='SUBCHANNEL*SET*ID OF*FAILING*DEVICE'
Tested/Corrected Change 35.182.
-Dataset TYPE75 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF75DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF75DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
SMF75SCS='SUBCHANNEL*SET*ID'
Tested.
-Dataset TYPE76 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF76DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF76DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Tested.
-Dataset TYPE77 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF77DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF77DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Tested.
-Dataset TYPE78 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF78DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF78DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
No Observations to test.
-TYPE78CF dataset had zero observations with VMAC78 from
MXG 34.06 - corrected by 34.223 (34.07), 35.021 (35.02)
or 35.166 (in MXG 35.07).
-Dataset TYPE791 update:
R791SRC new MP Swap Reason Memory Pool Shortage
No Observations to test.
-Dataset TYPE796 new variables:
R796SCS='SUBCHANNEL*SET*ID'
No Observations to test.
-Dataset TYPE79B new variables:
R79BSCS='SUBCHANNEL*SET*ID'
No Observations to test.
-TYPE92xxx datasets not tested, no data.
-NEW dataset TYPE9208: ZFS FILE SYSTEM MIGRATED
SMF92GLUGNU='LOCAL*OR*REMOTE*MOUNT?'
SMF92GSN='FILE*SYSTEM*OWNER?'
SMF92GTM='DATETIME*OF*MIGRATION'
SMF92GMO='OFFSET OF*MOUNT*PARM*SECTION'
SMF92GFT='FILE*SYSTEM*TYPE*MNTENTFSTYPE'
SMF92GFM='FILE*SYSTEM*MODE*MNTENTFSMODE'
SMF92GDN='FILE*SYSTEM*DEVICE NUMBER*MNTENTFSDEV'
SMF92GDD='DDNAME*SPECIFIED*ON MOUNT*MNTENTFSDDNAME'
SMF92GTN='FILE*SYSTEM*TYPE NAME*MNTENTFSTNAME'
SMF92GFN='MIGRATION*TARGET*FILE*SYSTEM*NAME'
SMF92GON='MIGRATION*SOURCE*FILE*SYSTEM*NAME'
SMF92GBL='FILE*SYSTEM*BLOCK*SIZE'
SMF92GST='TOTAO*SPACE*IN FILE*SYSTEM'
SMF92GSU='ALLOCATED*SPACE IN*FILE*SYSTEM'
SMF92GFG='FIRST*BINARY*FLAG'
SMF92GF2='SECOND*BINARY*FLAG'
-NEW dataset TYPE9250: ZFS FILE SYSTEM EVENTS
SMF92FSN='FILE*SYSTEM*NAME'
SMF92VOL='VOLSER*FIRST*EXTEND'
SMF92CCHH='CCCCHH*OF FIRST*EXTEND'
SMF92EVENT='FILE*SYSTEM*NAME'
SMF92SIZ='FORMATTED*SIZE OF*FILE*SYSTEM'
SMF92T50=' STKE *FILE*SYSTEM*EVENT'
SMF92CODE='FAILED*OPERATIONS*ERROR*CODE'
SMF92RSN='REASON*CODE'
SMF92OVS='PRIOR*VOLUME*SERIAL'
SMF92OCH='CCCCHH*OF PRIOR*VOLUME*SERIAL'
SMF92LRT='LOGFILE*RECOVERY*TIME'
SMF92LRP='LOG*PAGES*PROCESSED'
SMF92LRR='LOG*RECORDS*PROCESSED'
SMF92LRD='LOG*BLOCKS*MODIFIED'
SMF92LRE='REDO*DATA*RECORDS*PROCESSED'
SMF92LRF='FILL*RECORDS*PROCESSED'
SMF92LRN='NEW BLOCK*SECURITY*RECORDS*PROCESSED'
SMF92SYS='SYSTEM*NAME*REPORTING*EVENT'
-NEW dataset TYPE9251: COUNTS/RESPONSE TIME ZFS CALLS
SMF92CCT='EVENT*DATETIME'
SMF92VCC='CALLS TO*FILE SYS*OWNED LOCALLY*OR R/O'
SMF82VCX='CALLS*REQUIRED*TRANSMIT*FOR LOCAL'
SMF92VCR='CALLS TO*FILE SYS*OWNED*REMOTELY'
SMF92VCRX='CALLS*REQUIRED*TRANSMIT*FOR REMOTE'
SMF92VCT='AVG TIME*PER CALL*LOCALLY*OWNED'
SMF92VCRT='AVG TIME*PER CALL*REMOTELY*OWNED'
SMF92VCN='CALLS TO*FILE SYS*LOCAL OR*REMOTE'
-NEW dataset TYPE9252: STATISTICS FOR ZFS USER FILE CACHE
SMF92UCT =' STCKE DATETIME*WHEN*STATISTICS'
SMF92UCSCH='TIMES*DIRTY DATA**SKED FOR*WRITE TO DISK'
SMF92UCSET='CALLS*TO CHANGE*ATTRIBUTES*OF A FILE'
SMF92UCFSY='CALLS*TO SYNC*ALL DIRTY DATA*SYNC WAIT'
SMF92UCUNM='CALLS*TO PURGE*USER CACHE'
SMF92UCRD ='CALLS*TO READ*FROM FILE*IN USER CACHE'
SMF92UCRDA='ASYNC*READ-AHEADS*SCHEDULED*SEQUENTIALLY'
SMF92UCWR ='CALLS*TO WRITE*TO FILE*IN USER CACHE'
SMF92UCGET='CALLS CACHE*TO OBTAIN ATTRIBUTES'
SMF92UCFL ='CALLS CACHE*TO FLUSH*ALL DATA FOR*FILE SYS'
SMF92UCDEL='WRITES*OF DIRTY DATA*AVOIDED'
SMF92UCRDF='READ CALL*TO FILE CACHE*FOUND*A CACHE MISS'
SMF92UCWRF='WRITE CALL*TO FILE CACHE*FOUND*A CACHE MISS
SMF92UCRIO='READ I/OS*TO DISK*USER FILE CACHE'
SMF92UCWRS='NORMAL*WRITE I/OS*SKED*BY FILE CACHE'
SMF92UCWRE='WRITE I/OS*SKED*ERROR FOUND'
SMF92UCWRR='WRITE I/OS*SKED*RECLAIM-STEAL'
SMF92UCRWR='TASK WAITS*FOR SKED READ*FROM DISK'
SMF92UCWW ='TASK WAITS*FOR WRITE*FILE*PENDING I/O'
SMF92UCWWF='TASK WAITS*FOR PENDING I/O*FOR FSYNC CALLS'
SMF92UCWWE='TASK WAITS*FOR I/O*ERROR*PROCESSING'
SMF92UCWWR='TASK WAITS*FOR I/O*RECLAIM-STEAL*PROCESSING
SMF92UCRST='TIMES*RECLAIM-STEAL*PROCESSING*WAS INVOKED'
SMF92UCCS ='CACHES*SPACES*LRU QUEUES* AND PAGEPOOLS'
SMF92UCPCS='PAGES*IN EACH*CACHE SPACE'
SMF92UCSS ='SIZE OF*INDIVIDUAL*FILE SEGMENT'
SMF92UCPGS='SIZE OF*A PAGE*IN THE USER*FILE CACHE'
SMF92UCPGT='TOTAL PAGES*IN THE USER*FILE CACHE'
SMF92UCPGF='FREE PAGES*IN THE USER*FILE CACHE'
SMF92UCSGC='ALLOCATED*SEGMENT*STRUCTURES*IN FILE CACHE'
SMF92UCDSL='LENGTH*PER-CACHE*SPACE RECORD'
-NEW dataset TYPE9252X:CACHE SPACE NAME SEGMENT
SMF92DSNAM='NAME OF*THE CACHE SPACE'
SMF92DSAS ='SEGMENTS*ALLOCATED'
SMF92DSFR ='FREE PAGES*IN CACHE LIST'
-NEW dataset TYPE9253: STATISTICS FOR ZFS METADATA CACHE
SMF92MCT ='DATETIME*WHEN*STATISTICS*WRITTEN'
SMF92MCB ='BUFFERS IN THE METADATA CACHE.'
SMF92MCLK='SEARCH CALLS*FOR BUFFER*IN METADATA CACHE'
SMF92MCHT='SEARCH CALLS*CACHE HITS'
SMF92MCWP='CALLS TO*UPDATE*METADATA CACHE*BUFFER.'
SMF92MCPW='PARTIAL*BUFFERS*WRITTEN'
SMF92MCBS='BYTES IN*METADATA*CACHE BUFFER.'
-NEW dataset TYPE9254: STATISTICS FOR ZFS LOCKING AND SLEE
-NEW dataset TYPE9255: GENERAL ZFS DISK IO STATISTICS
-NEW dataset TYPE9256: TOKEN MANAGER
-NEW dataset TYPE9257: ZFS USE OF MEMORY
-NEW dataset TYPE9258: TRANSMIT/RECEIVES BETWEEN ZFS MEMBE
-NEW dataset TYPE9259: PER-FILE SYSTEM USAGE
-RMF III UPDATES for z/OS 2.3:
-ASMRMFV Recent versions will execute without error to
create RMFBSAM output, but these new variables are output
with this VMACRMFV update:
-Dataset ZRBASI new variable:
ASISTAFL ASI2GMEMOBJ ASI2GPGSBKD
-Dataset ZRBDVT new variables:
DVTSSID ='SUBCHANNEL*SET'
DVTDEVN2='DEVICE*NUMBER*DVTDEVNR'/
DVTENIDX4='INDEX OF*THIS*DVTG3*ENTRY'/
DVTPREVI4='INDEX OF*PREVIOUS*DVTG3*ENTRY'
-Dataset ZRBGEI new variables:
GEIGRMO ='FIXED*MEMOBJ*BACKED IN*2GB FRAMES'
GEIGRPR ='2GB FRAMES*FIXED IN*CSTORE'
GEIGFUSE='2GB FRAMES*USED IN*FIXED*MEMOBJ'
GEIGSIZ ='2GB FRAMES*CAN BE*USED 2GB MEMOBJ'
-Dataset ZRBUWD new variables:
UWDDEVNR4=DEVICE*TABLE*DVTG3*INDEX'
Change 35.165 Variables added to VXMTRMEM dataset:
VMACVMXA RSAPIN0B ='PINNED*PAGES*CLASS 0*BELOW 2G'
Jul 28, 2017 RSAPIN0A ='PINNED*PAGES*CLASS 0*ABOVE 2G'
Aug 2, 2017 RSAPIN1B ='PINNED*PAGES*CLASS 1*BELOW 2G'
RSAPIN1A ='PINNED*PAGES*CLASS 1*ABOVE 2G'
RSAPINWP ='PINNED*PAGE COUNT*CAUSES WARNING'
RSAPINFP ='TOTAL*PINNED*PAGE*COUNT'
RSAIOUSD ='BYTES*IOAT*SUBPOOL'
RSAIOSIZE='SIZE (MB)*IOT*SUBPOOL'
RSAIOWRNP='WARNING*PCT*IOAT*USED'
SYSHPIOM ='MAX*CONCURNT*PG*RQSTS'
SYSHPFLG ='HYPERPAV*PAGING*FLAGS'
RSAAGEFL ='GLOBAL*AGING*LIST*FLAGS'
Variables added to VXSYTRSG dataset:
RSAPIN0B ='SYS TOT*PINNED*PAGES*CL 0 LT 2G'
RSAPIN0A ='SYS TOT*PINNED*PAGES*CL 0 GT 2G'
RSAPIN1B ='SYS TOT*PINNED*PAGES*CL 1 LT 2G'
RSAPIN1A ='SYS TOT*PINNED*PAGES*CL 1 GT 2G'
RSAPINWP ='PCT PINNED*CAUSED*WARNING'
RSAPINFP ='PCT PINNED*CAUSED*FAILURE'
RSAPINWC ='TIMES*WARNING*PCT*EXCEEDED'
RSAPINFC ='TIMES*FAILURE*PCT*EXCEEDED'
RSAIOUSD ='BYTES*USED*IOAT*SUBPOOL'
RSAIOWRNP='PCT*IOAT*SUBPOOL*VS SIZE'
RSAIOWRNC='TIMES*IOAT*SUBPOOL*WARNING'
RSAIOFALS='TIMES*IOAT*SUBPOOL*NOT AVAIL'
RSAIOFAIL='TIME*NOT AVAIL*IOAT AND*AVAILLIST'
Variables corrected in VXBYUSR dataset, all
were missing the divide by 4096.
Thanks to Patricia Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
Change 35.164 Variables added to XAMSYS dataset:
VMACXAM RSACKMB2G='CP FRAMES*LT 2G*FOR DUMP'
Jul 26, 2017 RSACKMA2G='CP FRAMES*GT 2G*FOR DUMP'
RSAPIN0B ='PINNED*PAGES*CLASS 0*BELOW 2G'
RSAPIN0A ='PINNED*PAGES*CLASS 0*ABOVE 2G'
RSAPIN1B ='PINNED*PAGES*CLASS 1*BELOW 2G'
RSAPIN1A ='PINNED*PAGES*CLASS 1*ABOVE 2G'
RSAPINWP ='PINNED*PAGE COUNT*CAUSES WARNING'
RSAPINFP ='TOTAL*PINNED*PAGE*COUNT'
RSAIOUSD ='BYTES*IOAT*SUBPOOL'
RSAIOSIZE='SIZE (MB)*IOT*SUBPOOL'
RSAIOWRNP='WARNING*PCT*IOAT*USED'
SYSHPIOM ='MAX*CONCURNT*PG*RQSTS'
SYSHPFLG ='HYPERPAV*PAGING*FLAGS'
RSAAGEFL ='GLOBAL*AGING*LIST*FLAGS'
Thanks to Patricia Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
Change 35.163 Support for Dell EMC Mainframe Enablers for z/OS V8.2 for
EXPAVO01 their z Systems PAV Optimizer, PAVO product's user SMF
EXPAVE01 record creates two new datasets:
IMACPAVO DDDDDD DATASET DESCRIPTION
TYPEPAVO TYPAVO TYPEPAVO PAVO OPTIMIZER DATA
TYPSPAVO TYPAVE TYPEPAVE PAVO EVENT
VMACPAVO
VMXGINIT This support is incomplete and in active development;
Aug 25, 2017 please contact SUPPORT@MXG.COM for current status.
Change 35.162 Support for Dell EMC Mainframe Enablers for z/OS V8.2 for
EXZDPVDG their z Systems Data Protector, zDP product's user SMF
IMACZDP record creates new TYPEZDP dataset:
TYPEZDP DDDDDD DATASET DESCRIPTION
TYPSZDP ZDPVDG TYPEZDP ZDP DATA
VMACZDP
VMXGINIT
Jul 24, 2017
Change 35.161 Support for BMC Mainview/CICS Version 7.1 (CICS/TS 5.4)
FORMATS adds many new fields and updated formats.
VMACMVCI
Jul 23, 2017
Change 35.160 Support for AXWAY Version 3.1.3; the documentation does
VMACAXWY not match the actual data records and some fields are not
Jul 21, 2017 input, pending feedback from the vendor.
Thanks to Michael Reines, Decadis, GERMANY.
Change 35.159 VGETSORT now adds formats to the output for the sorted by
VGETSORT variables for each dataset. For each found member, there
Jul 28, 2017 will be a MACRO variable FMTx corresponding to the SRTx
variable that will contain the formats of the variables
in the SORTEDBY list. Where there is no specified format
CHAR is substituted.
Change 35.158 Support for Mainview/CICS Optional SMF 110 BMCMVCIC field
IMACICWU in dataset CICSTRAN.
UTILEXCL
VMAC110
Jul 18, 2017
Change 35.157 MXG 35.01-35.06. Variable DB2TCBTM was removed from the
VMXGUOW CPUUOWTM value in PDB.ASUMUOW back in Change 32.014, but
Jul 18, 2017 was put back in the equation in 35.01, in error, so it
is again removed from the equation, per text of 32.104.
Thanks to Rick Southby, Insurance Australia Group, AUSTRALIA
Change 35.156 ERROR: VARIABLE DTOKEN/IMSRECCH NOT FOUND because they
VMACIMS were in the BY list for the IMS06 dataset sort but were
Jul 16, 2017 not kept; now they are kept in IMS06.
Thanks to Randy Hewitt, DXC, USA.
Change 35.155 TPX STOPOVER because the change in length of IP Port from
VMACTPX 4 to 5 digits was not fully protected. Variable
Jul 16, 2017 TPXIPPRT in datasets TPXTRMON/TPXTRMOF and variable
TPXIPADR in dataset TPXAPLOF values are now correct.
CA's record length change was in Feb, 2016, RO85818.
Thanks to Paul Naddeo, FISERV, USA.
Change 35.154 -MXG 35.06 only, STOPOVER abend during TYPERMFV execution
ASMRMFV processing RMF III with option UWD (Use/Wait table) after
Jul 11, 2017 Change 35.148. Message RMFV006I may show incorrect RMF
Jul 21, 2017 Monitor III table selections, but processing of the
actual selected tables still occurred. Message RMFV006I
could show NOZEROCPU when the default ZEROCPU setting was
in effect for the ASI table. Only ASMRMFV was changed.
-With this change if the NOSVP table option is in effect
then the RCD option will be forced to NORCD.
-Invalid RMFV012I and/or RMFV013I Sample RANGE and
SELECTED messages when RMF III data originates from a
time zone with time stamps later than the current TOD in
the time zone where ASMRMFV is executing.
Thanks to Betty Wong, Bank of America, USA
Thanks to Roger Lowe, Northern Territory Government, AUSTRALIA.
Change 35.153 The IBM RMF CRYPTO report shows a TOTAL EXEC TIME with a
VMAC7072 value of 0.120 but that is actually the AVERAGE EXEC TIME
Jul 7, 2017 per call, and the unstated units are milliseconds, so the
actual average value was 120 microseconds. In TYPE7002
dataset, the actual average value was 120 microseconds.
MXG Variable CRYCTE is the calculated average value,
0.000120 seconds, which is 120 microseconds. When printed
with TIMW13.3 format, only three decimals were displayed
(0:00:00.000), so crypto duration variables are now
formatted TIME14.6 to display as 0:00:00.000120 to show
microseconds.
Thanks to Martha A. Knapik, Progressive, USA.
Thanks to Douglas Wells, Progressive, USA.
Change 35.152 Support for BETA 97 Subtype 22 record for both version
EXTYB97Q 430 and 610, although only 430 records have been read.
EXTYB97R New dataset BETA9722REL is created with the relocate
FORMATS segments for Subtype 22 records.
VMACBE97
VMXGINIT
Jul 9, 2017
====== Changes thru 35.151 are in this MXG 35.06 dated Jun 30, 2017=====
Change 35.151 BMC CMF TYPE74 subtype 8 records requires BMC PTF BQM1335
TYPE74 after IBM SuperPav support is installed, even if you are
Jun 28, 2017 NOT using SuperPAVs. After IBMSuperPAV PTFs, the ESS Rank
data are incorrect. No code was changed in MXG.
Thanks to Jerry Ellis, Liberty Mutual, USA.
Change 35.150 Option %LET CECONLY=YES; creates PDB.ASUMCEC keeping only
VMXG70PR the 68 CEC-Level variables, dropping 2794 LPAR-specific
Jun 28, 2017 variables (generally useless, with unique variable names
for 60 LPARs) and creates PDB.ASUMCELP (no changes, but
with one observation per LPAR, it is THE dataset to use
to report LPAR data, with ONE set of variable names.)
NOTE: ALL LPARS in the CEC are summed into ASUMCEC.
Only the first 60 have sets of kept unique names.
The ASUM70PR/ASUM70LP and ASUM70GC/ASUM70GL datasets are
not created when %LET CECONLY=YES; is placed in your
//SYSIN prior to the INCLUDE of ASUM70PR.
Change 35.149 New BUILDJCL=YES option creates JCL for two step job with
UTILBLDP PGM=IFASMFDP control statements to select ONLY the SMF
Jun 30, 2017 records needed for your UTILBLDP selections.
Sep 30, 2017 On Sep 30, UTILBLDX from this change became UTILBLDP as
had been planned in the original text of this change,
and UTILBLDX was removed from MXG 35.09.
-comparison of CPU savings:
Using IFASMFDP to select SMF records can save CPU time,
especially for Ad Hoc jobs that select a relatively small
number of SMF records. Tests with a 15 GigaByte SMF file
with 25 million records was used, but only 1.4 Million of
those records (1 GB) were actually decoded and output.
But they had to be read and that costs CPU time:
MM:SS
READ ALL RECORDS 14:56
USE MXG MACFILE EXIT TO SKIP UNWANTED 12:43
IFASMFDP READ ALL SELECT/WANTED 0:10
READ SELECTED/WANTED 2:25
-Using MACFILE, _SMF decodes the full header and then
deletes unwanted. Decoding DATETIME variables is the
most expensive INFORMAT so I inserted an exit to skip
the unwanted immediately after the ID was input and
prior to any DATETIME field, but the savings were much
less than hoped for and much less than using IFASMFDP.
MM:SS
READ ALL with _SMF THEN DELETE UNWANTED 6:29
READ ALL, DELETE AFTER ID READ 4:45
-BUILDJCL for extreme cases provides extreme results:
Selecting 194 SMF 115 records in a file of 300 million
records (1 MB from 137 GB) dropped the CPU time from
25 min to only 46 seconds, elapsed from 28 to 13 min.
Change 35.148 RMF III CPUTM in datasets ZRBRCDS and ZRBRCDR is wrong if
ASMRMFV ASMRMFV selected RCD records but didn't select SVP table.
ADOCRMFV Creation of CPUTCBTM/CPUSRBTM from Service Units requires
VMACRMFV the SVPCPU and SVPSRB coefficients. ASMRMFV now selects
Jun 27, 2017 SVP records when RCD is selected. Additionally, variable
CPUTM is set missing if there are no SVP data.
SO YOU MUST HAVE BOTH RCD AND SVP TABLES IN ASMRMFV.
-However, if the SVP table is selected, then the RCD table
is NOT forced. The SVP table is now also moved to the
BASIC option table selection group from the MOST option
table selection group because the RCD was always part of
the BASIC option table group.
-Minor performance improvement to UWD table processing
logic.
-Several documentation Sections are updated to support the
above changes:
Section 0 "Contents"
Section 4 "RMF III Table Selection Parameters"
Section 13 "Filtered Records"
Section 26 "ASMRMFV and MXG PDB Data
Thanks to MP Welch, Bank of America, USA.
Change 35.147 Support for new segments create two new datasets:
EXVSIDSK DDDDDD DATASET DESCRIPTION
EXXAMPRC VSIDSK XMVSIDSK VSIDISK Data
IMACXAM XAMPRC XAMSYPRC LIMPOOL Data
VMACXAM
VMXGINIT
Jun 28, 2017
Thanks to Patricia Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
Change 35.146 -TYPE749 vars R749FPGBYTR and R749FPGBYTS were incorrectly
VMAC74 multiplied by 256; the two input variables had already
Jun 23, 2017 been converted to bytes.
-TYPE749 variables decoded from SMF74DO offset were wrong;
the +17 added to SMF74DO should have been +16.
R749DMAR R749DMAW R749DFMT R749DBYR R749DBYT
R749DFMT R749DPKR R749DPKT R749DWUP R749DWUM
R749DFMT R749DBYX R749DFMT
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.145 Some zVM VXSYTPRP new SMT variables were incorrectly
FORMATS tested for error conditions with GT 8000000Nx values
VMACVMXA that no longer existed after their INPUT, causing large
Jun 25, 2017 values in occasional observations. They are now INPUT
with IB4 or IB4.3 INFORMATS so the first-bit-value causes
a negative value, and the error tests are now LT 0 to
detect and delete them. The MGVXAER format was revised
decode the negative values to print the error messages on
the SAS log (for the first 3 of each error type).
-Some INTERVAL variables were incorrectly deaccumulated
that also caused occasional large values.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.144 These error messages, introduced in Change 35.050:
ASUM70PR MXGERROR:DATASETS ASUMCEC ASUMCELP ARE NOT VALID. YOU ARE
VMXG70PR MXGERROR:MISSING TYPE 70 RECORDS FOR ONE OR MORE SYSTEMS.
Jun 23, 2017 MXGERROR:SMF70LAC VALUES FOR THOSE SYSTEMS/CECS ARE INVALID
MXGERROR:SEE CHANGE 35.144 TO CORRECT.
impact the important ASUMCEC and ASUMCELP CEC-level data.
Datasets ASUM70PR and ASUM70LP are impacted, but they
are SYSTEM-Level and are NOT recommended for analysis.
The messages will result if you did NOT process type 70
records from ALL OF YOUR z/OS SYSTEMS in the CEC; for
that case, you need to read all 70 SMF records.
They can also result if your z/OS configuration uses z/OS
SYSTEM names that are set in your SYS1.PARMLIB's IEASYSxx
and are NOT the same as the SMF SYSTEM ID: for example,
if you set SYSTEM names in IEASYSxx to the LPARNAME.
-This change creates a new INCODE70 argument that can be
set externally by macro variable &INCODE70FORPR, so you
can change those SYSTEM name to LPARNAME. Note, this is
only done internally in ASUM70PR code; there is no SYSTEM
variable in ASUMCEC/ASUMCELP. To use INCODE70FORPR, you
first need run this program and look at the output of
PROC FREQ DATA=PDB.TYPE70PR;
TABLES LPARNAME*SMF70STN/NOROW NOCOL NOCUM NOPERCENT;
to verify that LPARNAME equals SMF70STN for ALL systems.
IF THAT IS TRUE, then you need to use either INCODE70= in
your tailored ASUM70PR member (in your USERID.SOURCLIB),
or set the value prior to your ASUM70PR include, using:
%LET INCODE70FOR70PR=%QUOTE(
IF SYSTEM NE LPARNAME THEN SYSTEM=LPARNAME;
);
-Newly added, once you have verified the preceding is TRUE
you can let MXG do the heavy lifting and specify:
%LET INCODE70=ENABLEAUTO;
(this %LET was corrected Aug 29, 2022, originally the
change text had INCODE70FORPR which was wrong)
and MXG will generate the needed code to correct.
Don't hesitate to contact support@mxg.com for help.
See Change 36.026 for an example when LPARNAME is not
equal to SMF70STN.
See Also Change 37.071 that added INTIME70xx macros.
These are the variables that will have missing values
in PDB.ASUMCECLP and ASUMCEC for those LPARs listed:
SMF70CPA SMF70LAC SMF70PAT SMF70WTI SMF70WTS SMF70WTI.
Change 35.143 -The UTIILBLDP option SUPPRESS is enhanced to recognize
UTILBLDP CICS to be the same as 110.
Jun 21, 2017 -If you specified SORTOUT=NEVER (not really recommended,
intended only for internal testing) it didn't work right:
only the datasets where sort IS required were NOT sorted,
(i.e. DIF() required for deaccumulate members) and all
other datasets WERE sorted. Now, NEVER sorts NOTHING,
and SORTOUT=NO option now sorts ONLY those members that
must be sorted for DIF().
Change 35.142 Format MG080QU has been updated with new z/OS 2.2 values
FORMATS for decoding variable RACFQUAL='EVENT*CODE*QUALIFIER'
Jun 16, 2017
Thanks to Lindsay Oxenham, Australia Defence Department, AUSTRALIA.
Change 35.141 John Burg's 2017 formula for RNI for the z13 was changed
ASUM113 from the 2.6 factor introduced in Change 33.033 in 2015
VMAC113 to the new value of 2.3. John's paper can be found at:
VMACVMXA http://www-03.ibm.com/support/
Jun 15, 2017 /techdocs/atsmastr.nsf/WebIndex/TC000066
Thanks to David Cogar, WellsFargo, USA.
Change 35.140 Support for short sub-sub-type ZPRTR1PL=188.
VMACZPRO
Jun 15, 2017
Change 35.139 -Support for restructured BETA93 Subtype 25 (VMACBETA)
VMACBETA and for restructured BETA97 Subtype 25 (VMACBE97) which
VMACBE97 adds new BE97DTKN DTOKEN variable.
Jun 21, 2017 -Variable BETALEXT has length $16 in VMACBETA subtypes
Jun 26, 2017 21 and 25, but the first INPUT for subtype 0 and other
earlier subtype are length $12, so the kept length was
only 12. Now, LENGTH BETALEXT $16 is set so the kept
variable length is the maximum 16 bytes.
Thanks to Thomas Wigger, Finanz Informatik, GERMANY.
Thanks to Dieter Haak, Finanz Informatik, GERMANY.
Thanks to Robert Gilbert, BNP Paribas Fortis, BELGIUM.
Change 35.138 TPX corrections to TPXIPPRT and TPXTRMON dataset.
VMACTPX The '07'x records are only LENGTH=101, so the TPXAPLON
Jun 9, 2017 data set is still missing TPXIPADR and TPXIPPRT fields.
Thanks to Scott Wiig, USBank, USA.
Change 35.137 Datasets TYPE42DS, TYPE42SR & TYPE42VT with APAR OA44319
VMAC42 have increased accuracy for these I/O duration variables:
Jun 6, 2017 RESPTIME AVGCONTM AVGPNDTM AVGDISTM AVGCUQMS S42CONTM and
AVGIOQMS.
Thanks to Ron Hawkins, Hitachi, USA.
Change 35.136 Correction for NETVIEW ID=38 record with S38CCALR length
VMAC38 less than expected length of 8 bytes. Record is valid,
Jun 14, 2017 MXG expected fixed length of 8 characters.
Thanks to Stuart Wildey, Morgan Stanley, ENGLAND.
Change 35.135 -Enhancements for 4 numeric data filters for RMF Monitor
ADOCRMFV III ASI (Address Space Information) table.
ASMRMFV -A pair of data filters are added to filter ASI entries
VMACRMFV based on the ASICPUTA (Total TCB+SRB time) field for each
Jun 6, 2017 MINTIME interval. These filters are effective only if
the ASI table is selected.
New Parameter Alias(es)
------------- ------------------------------------------
ZEROCPU ZCPU Default
NOZEROCPU NOZCPU, NZCPU
-ZEROCPU is the default and results in all ASI entries
being output to the RMFBSAM file and thus all becoming
observations in the MXG PDB data set ZRBASI (depending
on other ASI filters that may be in use).
The default provides a compatible behavior with prior
ASMRMFV versions.
-NOZEROCPU results in all ASI entries with ASICPUTA=0
being filtered (depending on other ASI filters that may
be in use) and thus these do NOT become observations in
the MXG PDB data set ZRBASI. The data volume to generate
the PDB can be significantly reduced.
In a test group of 21 RMF Monitor III VSAM data sets
78.3% of all ASI entries had ASICPUTA=0. Actual results
may vary.
-While the NOZEROCPU setting might seem to be ALWAYS
desirable there are other considerations:
1) Filtering zero CPU time ASI entries will result in
time series gaps for some Address Spaces in some MINTIME
intervals in charts, plots, or reports.
If such gaps are not acceptable, use the default ZEROCPU
parameter instead. However, there will be a higher
number of PDB ZRBASI data set observations as in prior
ASMRMFV versions.
2) Zero CPU time conditions are NOT always due to pure
idleness for an Address Space.
RMF Monitor III detected delays such as Processor,
Enqueue, Operator Reply, and Operator Mount separately or
in combination can prevent accumulation of any CPU time
for an Address Space in a single MINTIME interval.
The NOZEROCPU parameter used alone with the NOKEEPDELAYS
default will filter out these entries so that further
investigation of a zero CPU time Address Space in a
MINTIME interval based on delays is impossible.
-With the above use of NOZEROCPU in mind an additional
pair of data filters are added to further filter ASI
entries based on the ASISWAIN (Number of Single State
Samples Delayed by ANY Resource) field for each MINTIME
interval.
This filter pair is effective only if the NOZEROCPU
parameter is in effect.
New Parameter Alias(es)
------------- ------------------------------------------
KEEPDELAYS KDELAYS, KDLYS, KEEPD
NOKEEPDELAYS NOKDELAYS, NOKDLYS, NOKEEPD Default
-With NOZEROCPU and NOKEEPDELAYS in effect all ASI entries
with ASICPUTA=0 are filtered regardless if any delays
occurred or not during a MINTIME interval (if not already
filtered by other ASI filters).
-With NOZEROCPU and KEEPDELAYS in effect only ASI entries
with both ASICPUTA=0 AND ASISWAIN=0 (zero delays) in a
MINTIME interval are filtered (if not already filtered
by other ASI filters).
In a test group of 21 RMF Monitor III VSAM data sets with
NOZEROCPU and KEEPDELAYS 75.8% of all ASI entries had
ASICPUTA=0 and ASISWAIN=0 and so were filtered.
This was only 2.5% less data filtered than with NOZEROCPU
used alone. Once again actual results may vary.
-NOZEROCPU and KEEPDELAYS are likely the best compromise
settings between ASI data reduction and retention of
delay information. Neither are defaults.
However, for maximum data reduction use NOZEROCPU alone
if subsequent delay analysis is not required.
-If ZEROCPU/NOZEROCPU is specified multiple times the last
occurrence takes effect.
-If KEEPDELAYS/NOKEEPDELAYS is specified multiple times
the last occurrence takes effect, but both are ignored
if ZEROCPU is in effect.
-The following chart shows ASI entries output to the
RMFBSAM file and thus also to the subsequent observations
in MXG PDB ZRBASI data set based on the settings of
ZEROCPU/NOZEROCPU, KEEPDELAYS/NOKEEPDELAYS:
---------------------------------------------------------
| NOKEEPDELAYS | KEEPDELAYS
| (Default) |
---------------------------------------------------------
ZEROCPU |All ASI entries output |All ASI entries output
(Default)| |
---------------------------------------------------------
NOZEROCPU|Only ASI entries output|Only ASI entries output
|with ASICPUTA NE 0 |with ASICPUTA NE 0
| |OR ASISWAIN NE 0
---------------------------------------------------------
-ASIAND/ASIOR does NOT apply to ZEROCPU/NOZEROCPU and
KEEPDELAYS/NOKEEPDELAYS filters. These are evaluated
independently of other ASI filters.
-The order of ASI filter application is:
1) ASISUBSYS= <----
2) ASIWORKLOAD= |
3) ASIRESGROUP= |
4) ASISRVCLASS= |--< ASIAND/ASIOR applies only
5) ASIRPTCLASS= | to these filters 1) to 8)
6) ASIJOBCLASS= |
7) ASIJOBNAME= |
8) ASIJESID= <----
9) ZEROCPU/NOZEROCPU
10) KEEPDELAYS/NOKEEPDELAYS
-The MXG00 record version is raised to x'09' from x'08'.
New fields added to the MXG00 record include:
ZEROCPU/NOZEROCPU and KEEPDELAYS/NOKEEPDELAYS settings
-Update message RMFV006I to show new output filters
ZEROCPU/NOZEROCPU/KEEPDELAYS/NOKEEPDELAYS.
-Several documentation Sections are updated to support
the above changes:
Section 0 "Contents"
Section 2 "Terminology"
Section 4 "RMF III Table Selection Parameters"
Section 5 "Input Data Selection Parameters"
Section 6 "Report Control Parameters"
Section 7 "Output Data Control Parameters"
Section 12 "Messages"
Section 13 "Filtered Records"
Section 31 "Summary"
Change 35.134 Variables T103DBYT and T103DREQ are accumulated fields
VMAC103 that are now correctly deaccumulated in TYPE103D dataset.
Jun 5, 2017 Variables T103DDNS and T103DKEE are always zero in test
data, so it is unknown if they also are accumulated.
Thanks to Joe Faska, DTCC, USA.
Change 35.133 Test program COMPALL updated for new SMF products. This
COMPALL utility compiles all of the SMF processing programs to
Jun 5, 2017 ensure no CHAR/NUM conflicts in temporary variables.
Can not be run on z/OS because it requires 3292MB which
is more than the largest z/OS Private Area available.
Change 35.132 Support for zVM 6.4 APAR VM66026 adds new variables;
VMACVMXA -Variable CUIDSSID='SUBSYSTEM*ID*SSID' is added to dataset
Jun 3, 2017 VXMTRDEV, VXIODVON, and VXIODDEF.
-Variables added to VXIODVON
PREFPATH RDEVHPPL CUIDSSID EQIDUID EQIEQID DEVCHAR
EDEVATTR
-Variables added to VXIODDEV
RDEVNOAL RDEVYSAL RDEVIOQT RDEVIOQS CUIFCXPE RDEVWRAL
RDEVRDAL RDEVWXAL RDEVEXAL
Change 35.131 zVM variable CALENTMT was incorrectly divided by 16, and
VMACVMXA new variable CALSHARE='Hiperdispatch*Processor*SHARE is
Jun 1, 2017 now created as CALSHARE=CALENTMT/65536;
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.130 Changes in VMXGSUM invocation in little used and mostly
ASUM* obsolete members so that WPS can handle QA stream:
MNTH* ASUMHPAI ASUMHPCS ASUMHPSU ASUMHPUX ASUMMWUX
TRND* MNTH70 MNTH70PR MNTH71 MNTH72 MNTH72GO MNTHCICS MNTHJOBS
May 31, 2017 TRND70 TRND70SH TRND71 TRND72 TRND72GO
Change 35.129 Support for 7th, 8th, and 9th CICS User field.
UTILEXCL
IMACIC7D
IMACIC8D
IMACIC9D
IMACIC7U
IMACIC8U
IMACIC9U
May 31, 2017
Change 35.128 Documentation Note. ZFS and ODS users may need to change
IMACINIT the MXG default CAPSOUT option to NOCAPSOUT since those
May 26, 2017 system need to support both cases. I don't think it is
safe for me to change the option as it could impact the
existing users on z/OS where it was originally needed.
But you can add OPTIONS NOCAPSOUT: in the IMACINIT
member of your tailoring library if you determine it can
be changed with no impact.
Change 35.127 Dataset TYPE30_6 could have negative values for Early
VMAC30 Address Spaces (ASIDs that start prior to JES init that
May 26, 2017 have missing READTIME and JESNR) because of multiple
of the same JOB name, but adding variable ASID to the
BY list in MACRO _BTY30U6 corrects these errors.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.126 Variable SMF30SLM is decoded into these new variables in
BUILD005 TYPE30_4 and PDB.STEPS in BUILDPDB and BUILDPD3:
BUIL3005 SMF30SLMRB='REGIONBELOW*NONEXTENDED*REGION?'
VMAC30 SMF30SLMRA='REGIONABOVE*EXTENDED*REGION?'
May 26, 2017 SMF30SLMSB='SYSRESVBELOW*NONEXTENDED*REGION?'
SMF30SLMSA='SYSRESVABOVE*EXTENDED*REGION?'
SMF30SLMML='MEMLIMIT*ACTED ON*MEMLIMIT?'
SMF30SLMBY='IEFUSI*BYPASSED*ALL*SMFLIM?'
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 35.125 Support for z/OS 2.3 changes. See also Change 35.166.
EXTY9208 -Support for SMF Record Types 127-2047, with ID 0-127 and
EXTY9250 1152-2047 reserved for IBM use, and ID 127-1151 for USER
EXTY9251 SMF record types. The SMF header was extended by using
EXTY9252 never-used ID=126 record type to identify this record has
EXTY9253 the extended header. Note that new SMF exit IEFU86 is
EXTY9254 taken for ALL SMF records, with or without the extended
EXTY9255 header, and existing SMF exits IEFU83/84/85 are called
EXTY9256 ONLY for records with standard header.
EXTY9257 -Dataset TYPE1415 new variables:
EXTY9258 SMF14DEF='ENCRYPTION*FLAG*BYTE'
EXTY9259 SMF14DET='ENCRYPTION*TYPE'
IMAC92 SMF14DKL='DASD*DATA SET*KEY*LABELS'
VMAC1415 Fields exist only if Encryption Subtype 9 exists.
VMAC42 -Dataset TYPE4227 new variables:
VMAC62 SMF42RDSC_OLD='SMF42RDSC*OLD DSCB*DATA*FIELD'
VMAC7072 SMF42RDSC_NEW='SMF42RDSC*NEW DSCB*DATA*FIELD'
VMAC71 SMF42RKEY_OLD='SMF42RKEY*OLD DSCB KEY*DATASET*NAME'
VMAC92 SMF42RKEY_NEW='SMF42RKEY*NEW DSCB KEY*DATASET*NAME'
VMACSMF The _ETY4227 output macro was relocated correctly so it
VMXGINIT is outside the LN2 DO group, causing observations to
VMAC73 now be created that were not previously output.
VMAC74 Tested.
VMAC75 -Dataset TYPE62 new variables:
VMAC76 SMF62DEF='ENCRYPTION*FLAG*BYTE'
VMAC77 SMF62DET='ENCRYPTION*TYPE'
VMAC78 SMF62DKL='DASD*DATA SET*KEY*LABEL'
VMAC79 -Dataset TYPE71 new variables, APAR OA48913 added.
VMACRMFV SMF71RFL='SMF71RFL*FLAGS'
Jul 18, 2017 SMF71NNF='AVG NON-NUC*FRAMES*COMPRISING*STORAGE'
Jul 28, 2017 SMF71LSI='AVG SYS-INIT*DEMOTIONS*LARGE*TO 4K'
SMF71LRI='AVG REQ-INIT*DEMOTIONS*LARGE*TO 4K'
SMF71MHW='HWM 1MB*FRAMES*USED FOR*FIXED 1MB'
SMF71PIS='AVG 4KB*PAGEINS*FROM SCM'
SMF71POS='AVG 4KB*PAGEOUTS*TO SCM'
SMF71PI1='AVG 1MB*PAGEINS*FROM SCM'
SMF71PO1='AVG 1MB*PAGEINS*FROM SCM'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF71DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF71DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Fields not present, LENPDGS/SMF71PDL is 2160 bytes,
but should be 2224.
-Dataset TYPE72GO new variable:
R723GMLM='MEMORY*LIMIT*SPECIFIED?'
R723GMML='MEMORY*LIMIT*GB of*resgroup'
R723CTETX='TOTAL*TRANSACTION*ELAPSED*TIME'
R723CXETX='TOTAL*TRANSACTION*EXECUTION*TIME'
R723CETSX='SUM*ELAPSED*TIME*SQUARED'
R723CQDTX='TOTAL*QUEUE*DELAY*TIME'
R723CADTX='TIME*BATCH JOBS*INELIGIBLE*TO RUN'
R723CCVTX='TIME*BATCH JOBS*SPENT*IN JCL CVTR'
R723CIQTX='TIME*BATCH JOBS*INELIGIBLE*IN JOBQ'
Tested; 35.06 only kept first two variables.
-Dataset TYPE7204 new variable:
R724ETX='TOTAL*EXECUTION*TIME*GROUP'
R724QTX='TOTAL*QUEUE*TIME*GROUP'
R724OR7A='MEMORY*POOL*SHORTAGE'
Tested.
-Dataset TYPE73 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF73DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF73DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Tested.
-Dataset TYPE74 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF74DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF74DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
SMF74ATD='I/O DELAYS*PAV*ALIAS*THROTTLING'
Tested.
-Dataset TYPE74CA new variable:
R745XSCS='SUBCHANNEL*SET*ID'
Tested.
-Dataset TYPE748 new variable:
R748CFSC='SUBCHANNEL*SET*ID*PHYS CONFIG'
R748CSCS='SUBCHANNEL*SET*ID OF*FAILING*DEVICE'
No Observations to test.
-Dataset TYPE75 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF75DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF75DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
SMF75SCS='SUBCHANNEL*SET*ID'
Tested.
-Dataset TYPE76 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF76DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF76DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Tested.
-Dataset TYPE77 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF77DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF77DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
Tested.
-Dataset TYPE78 new variables:
ZARCHMDE='SYSTEM*IS IN*Z/ARCH MODE?'
IFAAVAIL='AT LEAST*ONE ZAAP*INSTALLED'
ZIPAVAIL='AT LEAST*ONE ZIIP*INSTALLED'
SMF78DAT1='ENHANCED*DAT*FACILITY 1*AVAILABLE'
SMF78DAT2='ENHANCED*DAT*FACILITY 2*AVAILABLE'
No Observations to test.
-Dataset TYPE791 update:
R791SRC new MP Swap Reason Memory Pool Shortage
No Observations to test.
-Dataset TYPE796 new variables:
R796SCS='SUBCHANNEL*SET*ID'
No Observations to test.
-Dataset TYPE79B new variables:
R79BSCS='SUBCHANNEL*SET*ID'
No Observations to test.
-TYPE92xxx datasets not tested, no data.
-NEW dataset TYPE9208: ZFS FILE SYSTEM MIGRATED
SMF92GLUGNU='LOCAL*OR*REMOTE*MOUNT?'
SMF92GSN='FILE*SYSTEM*OWNER?'
SMF92GTM='DATETIME*OF*MIGRATION'
SMF92GMO='OFFSET OF*MOUNT*PARM*SECTION'
SMF92GFT='FILE*SYSTEM*TYPE*MNTENTFSTYPE'
SMF92GFM='FILE*SYSTEM*MODE*MNTENTFSMODE'
SMF92GDN='FILE*SYSTEM*DEVICE NUMBER*MNTENTFSDEV'
SMF92GDD='DDNAME*SPECIFIED*ON MOUNT*MNTENTFSDDNAME'
SMF92GTN='FILE*SYSTEM*TYPE NAME*MNTENTFSTNAME'
SMF92GFN='MIGRATION*TARGET*FILE*SYSTEM*NAME'
SMF92GON='MIGRATION*SOURCE*FILE*SYSTEM*NAME'
SMF92GBL='FILE*SYSTEM*BLOCK*SIZE'
SMF92GST='TOTAO*SPACE*IN FILE*SYSTEM'
SMF92GSU='ALLOCATED*SPACE IN*FILE*SYSTEM'
SMF92GFG='FIRST*BINARY*FLAG'
SMF92GF2='SECOND*BINARY*FLAG'
-NEW dataset TYPE9250: ZFS FILE SYSTEM EVENTS
SMF92FSN='FILE*SYSTEM*NAME'
SMF92VOL='VOLSER*FIRST*EXTEND'
SMF92CCHH='CCCCHH*OF FIRST*EXTEND'
SMF92EVENT='FILE*SYSTEM*NAME'
SMF92SIZ='FORMATTED*SIZE OF*FILE*SYSTEM'
SMF92T50=' STKE *FILE*SYSTEM*EVENT'
SMF92CODE='FAILED*OPERATIONS*ERROR*CODE'
SMF92RSN='REASON*CODE'
SMF92OVS='PRIOR*VOLUME*SERIAL'
SMF92OCH='CCCCHH*OF PRIOR*VOLUME*SERIAL'
SMF92LRT='LOGFILE*RECOVERY*TIME'
SMF92LRP='LOG*PAGES*PROCESSED'
SMF92LRR='LOG*RECORDS*PROCESSED'
SMF92LRD='LOG*BLOCKS*MODIFIED'
SMF92LRE='REDO*DATA*RECORDS*PROCESSED'
SMF92LRF='FILL*RECORDS*PROCESSED'
SMF92LRN='NEW BLOCK*SECURITY*RECORDS*PROCESSED'
SMF92SYS='SYSTEM*NAME*REPORTING*EVENT'
-NEW dataset TYPE9251: COUNTS/RESPONSE TIME ZFS CALLS
SMF92CCT='EVENT*DATETIME'
SMF92VCC='CALLS TO*FILE SYS*OWNED LOCALLY*OR R/O'
SMF82VCX='CALLS*REQUIRED*TRANSMIT*FOR LOCAL'
SMF92VCR='CALLS TO*FILE SYS*OWNED*REMOTELY'
SMF92VCRX='CALLS*REQUIRED*TRANSMIT*FOR REMOTE'
SMF92VCT='AVG TIME*PER CALL*LOCALLY*OWNED'
SMF92VCRT='AVG TIME*PER CALL*REMOTELY*OWNED'
SMF92VCN='CALLS TO*FILE SYS*LOCAL OR*REMOTE'
-NEW dataset TYPE9252: STATISTICS FOR ZFS USER FILE CACHE
SMF92UCT =' STCKE DATETIME*WHEN*STATISTICS'
SMF92UCSCH='TIMES*DIRTY DATA**SKED FOR*WRITE TO DISK'
SMF92UCSET='CALLS*TO CHANGE*ATTRIBUTES*OF A FILE'
SMF92UCFSY='CALLS*TO SYNC*ALL DIRTY DATA*SYNC WAIT'
SMF92UCUNM='CALLS*TO PURGE*USER CACHE'
SMF92UCRD ='CALLS*TO READ*FROM FILE*IN USER CACHE'
SMF92UCRDA='ASYNC*READ-AHEADS*SCHEDULED*SEQUENTIALLY'
SMF92UCWR ='CALLS*TO WRITE*TO FILE*IN USER CACHE'
SMF92UCGET='CALLS CACHE*TO OBTAIN ATTRIBUTES'
SMF92UCFL ='CALLS CACHE*TO FLUSH*ALL DATA FOR*FILE SYS'
SMF92UCDEL='WRITES*OF DIRTY DATA*AVOIDED'
SMF92UCRDF='READ CALL*TO FILE CACHE*FOUND*A CACHE MISS'
SMF92UCWRF='WRITE CALL*TO FILE CACHE*FOUND*A CACHE MISS
SMF92UCRIO='READ I/OS*TO DISK*USER FILE CACHE'
SMF92UCWRS='NORMAL*WRITE I/OS*SKED*BY FILE CACHE'
SMF92UCWRE='WRITE I/OS*SKED*ERROR FOUND'
SMF92UCWRR='WRITE I/OS*SKED*RECLAIM-STEAL'
SMF92UCRWR='TASK WAITS*FOR SKED READ*FROM DISK'
SMF92UCWW ='TASK WAITS*FOR WRITE*FILE*PENDING I/O'
SMF92UCWWF='TASK WAITS*FOR PENDING I/O*FOR FSYNC CALLS'
SMF92UCWWE='TASK WAITS*FOR I/O*ERROR*PROCESSING'
SMF92UCWWR='TASK WAITS*FOR I/O*RECLAIM-STEAL*PROCESSING
SMF92UCRST='TIMES*RECLAIM-STEAL*PROCESSING*WAS INVOKED'
SMF92UCCS ='CACHES*SPACES*LRU QUEUES* AND PAGEPOOLS'
SMF92UCPCS='PAGES*IN EACH*CACHE SPACE'
SMF92UCSS ='SIZE OF*INDIVIDUAL*FILE SEGMENT'
SMF92UCPGS='SIZE OF*A PAGE*IN THE USER*FILE CACHE'
SMF92UCPGT='TOTAL PAGES*IN THE USER*FILE CACHE'
SMF92UCPGF='FREE PAGES*IN THE USER*FILE CACHE'
SMF92UCSGC='ALLOCATED*SEGMENT*STRUCTURES*IN FILE CACHE'
SMF92UCDSL='LENGTH*PER-CACHE*SPACE RECORD'
-NEW dataset TYPE9252X:CACHE SPACE NAME SEGMENT
SMF92DSNAM='NAME OF*THE CACHE SPACE'
SMF92DSAS ='SEGMENTS*ALLOCATED'
SMF92DSFR ='FREE PAGES*IN CACHE LIST'
-NEW dataset TYPE9253: STATISTICS FOR ZFS METADATA CACHE
SMF92MCT ='DATETIME*WHEN*STATISTICS*WRITTEN'
SMF92MCB ='BUFFERS IN THE METADATA CACHE.'
SMF92MCLK='SEARCH CALLS*FOR BUFFER*IN METADATA CACHE'
SMF92MCHT='SEARCH CALLS*CACHE HITS'
SMF92MCWP='CALLS TO*UPDATE*METADATA CACHE*BUFFER.'
SMF92MCPW='PARTIAL*BUFFERS*WRITTEN'
SMF92MCBS='BYTES IN*METADATA*CACHE BUFFER.'
-NEW dataset TYPE9254: STATISTICS FOR ZFS LOCKING AND SLEE
-NEW dataset TYPE9255: GENERAL ZFS DISK IO STATISTICS
-NEW dataset TYPE9256: TOKEN MANAGER
-NEW dataset TYPE9257: ZFS USE OF MEMORY
-NEW dataset TYPE9258: TRANSMIT/RECEIVES BETWEEN ZFS MEMBE
-NEW dataset TYPE9259: PER-FILE SYSTEM USAGE
-RMF III UPDATES:
-ASMRMFV Recent versions will execute without error,
but new variables will not be output without the new
VMACRMFV update:
-Dataset ZRBASI new variable:
ASISTAFL ASI2GMEMOBJ ASI2GPGSBKD
-Dataset ZRBDVT new variables:
DVTSSID ='SUBCHANNEL*SET'
DVTDEVN2='DEVICE*NUMBER*DVTDEVNR'/
DVTENIDX4='INDEX OF*THIS*DVTG3*ENTRY'/
DVTPREVI4='INDEX OF*PREVIOUS*DVTG3*ENTRY'
-Dataset ZRBGEI new variables:
GEIGRMO ='FIXED*MEMOBJ*BACKED IN*2GB FRAMES'
GEIGRPR ='2GB FRAMES*FIXED IN*CSTORE'
GEIGFUSE='2GB FRAMES*USED IN*FIXED*MEMOBJ'
GEIGSIZ ='2GB FRAMES*CAN BE*USED 2GB MEMOBJ'
-Dataset ZRBUWD new variables:
UWDDEVNR4=DEVICE*TABLE*DVTG3*INDEX'
Change 35.124 Running WPS with more than 20 libnames caused WPS to fail
PDBAUDIT so now with WPS if there are more than 20 LIBNAMES after
May 22, 2017 removing the LIBNAMES not related to PDBAUDIT, MXG shuts
down with a message that only the first 20 were used.
Change 35.123 Support for z/OS 2.2 updates to TYPE991 dataset adds many
VMAC99 new variables.
May 22, 2017
Thanks to David Cogar, WellsFargo, USA.
Change 35.122 Two new parameters added:
ANALCAPD COMPANY= lets you override MXG in title statements
May 22, 2017 OUTDATA= lets you preserve the dataset with actuals and
rolling 4 hour MSU values for further analysis.
-GRAPHICS code is enabled for WPS at 3.3 or higher.
====== Changes thru 35.121 are in this MXG 35.05 dated May 15, 2017=====
Change 35.121 ERROR: MACRO KEYWORD DO APPEARS AS TEXT because the quote
ANALAVAI after "DO'" and several other syntax errors corrected.
May 13, 2017
Thanks to Hai Huynh, Freddie Mac, USA.
Change 35.120 WPS only, MXG 35.04, Change 35.085. A variable with no
VMXGPRNT label generated unintended text with multiple quotes
May 16, 2017 Varname1='Label*(varname)''(next vrname)'
which is valid text for a SAS label, defined as the text
after an equal sign up to the text before the next token
that is followed by an equal sign, but this syntax was
was not accepted by WPS as a label, causing an ERROR.
The circumvention is to create a LABEL='NOLABEL' for
variables that do not have a label.
-VMXGPRNT is used in ANAL113, ANAL116, VMXGFIND, VMXGPRAL
VMXGPRA1, VMXGPRNT, VMXGSRCH, and JCLPDB members.
Change 35.119 READDB2 had a hard coded limit of 450 for IFCID, and 499
READDB2 had been added in TYPE102s. Now limit is 999.
May 11, 2017
Thanks to Lynn Hong, UCLA, USA.
Change 35.118 Notes on the use of VIEWs in DATA steps that create more
Document than one DATASET.
May 11, 2017 -Only one DATASET can be a view in a DATA step (and the
BUILDPDB program already has one).
-Any of the datasets can be the view, but that view MUST
be the first dataset referenced (read/sorted), or none
of the other datasets will exist.
-Views can dramatically reduce elapsed and CPU times and
I/O counts and durations, for instance for a DATA step
followed by a SORT, where the VIEW eliminates the write
and read of the dataset that is created without a VIEW.
The VIEW doesn't have any impact on the resources used
by the SORT.
-This example started as TYPE120 with the lower case
lines added. WORK needs to be cleared in case there was
a dataset of the same name, whether it was a view or a
dataset. The /view=typ1209r enables the view and names
the one dataset, and the _st1209r "data set sort macro"
is invoked first, and then made blank so the _S120
"product sort macro" can sort the other datasets:
proc datasets ddname=work mt=all kill;
%INCLUDE SOURCLIB(VMACSMF,VMAC120,IMACKEEP);
DATA
_VAR120 /view=typ1209r
_SMF
_CDE120
run;
_st1209r
run;
macro _st1209R %
_S120;
RUN;
The DATA/SORT took 6 hours, the VIEW/SORT took 2.
Thanks to Joe Faska, DTCC, USA.
Thanks to Michael Oujesky, DTCC, USA.
Change 35.117 -VMXGFIND did not correctly build the output dataset names
VMXGFIND when multiple input PDBs were to be read; while all were
May 11, 2017 read, only one was output.
Thanks to David A. Sadler, Optum, USA.
Change 35.116 35.04 only. The TYPSMVJE test was in TESSUSR1 but should
JCLTEST9 have been in TESSOTHR member, so TESSUSR1 step failed
May 16, 2017 because //MVJEIN DD was not found in that step's JCL.
Add //MVJEIN DD DUMMY to the TESSUSR1 step.
TYPSQACS replaced TESSQACS in //TESTQAPM step.
Thanks to Tony Ferullo, MIB, Inc., USA.
Thanks to Rod Feak, MIB, Inc., USA.
Change 35.115 TYPE 749 new var Support for Synchronious I/O zos 2.3
VMAC74 R749SRBF='BYTES*READ*THIS*FUNCTION'
May 10, 2017 R749SWBF='BYTES*WRITTEN*THIS*FUNCTION'
R749DFMT='FORMAT'
R749SSRF='SUCCESSFUL*REQUESTS*THIS'
R749SLRF='LOCAL*REJECTS*THIS'
R749SRRF='REMOTE*REJECTS*THIS'
R749STPF='PROCESSING*TIME*THIS'
R749SRBC='BYTES*READ*ALL*FUNCTIONS'
R749SWBC='BYTES*WRITTEN*ALL*FUNCTIONS'
R749SSRC='SUCCESSFUL*REQUESTS*ALL'
R749SLRC='LOCAL*REJECTS*ALL'
R749SRRC='REMOTE*REJECTS*ALL'
R749STPC='PROCESSING*TIME*ALL'
Note that the type 74 subtype 9 record requires RMF III
to be active on this system, and the ERBRMFxx member of
SYS1.PARMLIB must have PCIE=YES specified, to be created.
Change 35.114 New variables added to TYPE749 PCIE data found in SMF
VMAC74 manual refresh:
May 10, 2017 R749FLAG='VALIDITY*FLAG'
R749NET1='1ST*PORT*PNET ID'
R749NET2='2ND*PORT*PNET ID'
R749DBYX='BYTES*TRANSMITTED*BY PCIE*FUNCTION'
Change 35.113 MXG 35.04 only, TYPE70 SHARE weights wrong, although the
VMAC7072 PDB.ASUMCELP values were correct and recommended for the
May 10, 2017 analysis of LPAR weights.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 35.112 -MXG 35.04 Only, only with variable names longer than 32
VGETSORT bytes. ERROR Truncated SORTBY variable name not found.
May 9, 2017 The LENGTH for the new SORT variables is $32 now.
May 11, 2017 VGETSORT is used in BLDSMPDB, UTILROLL and MULTIPDB.
-VGETSORT: Cosmetic, UNINIT variable NOBS message because
it was not in the KEEP list, but had no impact.
Change 35.111 DB2 12.1, INVALID QLAC SEG ERROR, LENQLAC=218, new
VMACDB2 field QLACPRLV was inserted by DB2 CONTINUOUS DELIVERY,
VMACDB2H but was unknown to MXG as there was no notification by
May 9, 2017 IBM that a field was inserted. MXG detected the change,
May 11, 2017 printed the ERROR message, and deleted the record, so
some observations in DB2ACCT were not output. The error
led to the discovery of an updated DB2 MACLIB with this
text in DSNDQLAC member:
e26995 Continuous Delivery.
Product functional/build level. QLACPRLV. s28617
but a search for s28617 discovered nothing. Only a
search for the new field, QLACPRLV found it was added.
But there were no other references to the s28617 nor
e26995 tokens in the other MACLIB members.
Of course, now that I know this new field name, Google
found both fields referenced in APAR PI74456:
"IFCID 3 accounting information will now provide the
partner's functional/service/build level in a new
QLACPRLV field."
"IFCID 365 location statistics information will now
provide the partner's functional/service/build level
in a new QLSTPRLV field."
The real issue raised with DB2 support and unanswered
as of this writing is: HOW AM I SUPPOSED TO KNOW that
fields were inserted by Continuous Delivery.
These header fields are now kept in DB2ACCT:
QWHS_MOD_LVL='MOD LEVEL FOR*CONTINUOUS*DELIVERY'
QWHS_REC_INCOMPAT='INCOMPATIBLE*CHANGE*VALUE'
QWHS_REC_COMPAT='COMPATIBLE*CHANGE*VALUE'
QWHS_REC_VALIDITY='CHECK*NEEDED FOR*INCOMPAT*COMPAT'
The current MOD_LVL is V12R1M100 and MXG's COMPAT and
INCOMPAT count of changes is zero before and after this
INCOMPAT change. It is unclear how these fields could
be used, since they are after the record was changed.
Thanks to Dennis Gaetner, Fiduciagad, GERMANY.
Thanks to Sieghart Seith, Fiduciagad, GERMANY.
Change 35.110 Processing //PRISMAPR DD caused ERROR: UNDETERMINED I/O
VMACPRPR FAILURE because the DCB attributes were set for SMF, but
May 9, 2017 PRISMAPR input records are FB/256/27904.
Thanks to Gene Heikkinen, Blue Cross Minnesota, USA.
Change 35.109 Variables SM1209EX/EY/EZ/FA were accidentally dropped by
VMAC120 Change 35.024 from dataset TYP120R; you can correct with
May 5, 2017 MACRO _KT1209R SM1209EX SM1209EY SM1209EZ SM1209FA %
in your IMACKEEP tailoring member until you update MXG.
Thanks to Larry A. Gray, Lowes, USA.
Change 35.108 The ANALID report's TITLE can be changed with the TITLE=
ANALID argument, if you invoke %ANALID yourself, but BUILDPDB's
VMXGINIT invocation is internal, so this new macro variable
May 5, 2017 %LET MXGTITLEANALID=SMF RECORDS AUDIT REPORT;
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 35.107 Support for IAM Version 9.0.
VMACIAM
May 4, 2017
Change 35.106 Adds an array of system IDs SYS1-SYS10 and creates new
VMXGUOW variables SYSTEMCICS (system of origin of the 110) and
May 4, 2017 SYSTEMDB2 (system where the 101 was found) to the
PDB.ASUMUOW dataset.
Change 35.105 The CICS duration fields are now formatted TIME16.6
VMAC110 to show the full resolution to the microsecond. FORMATS
May 4, 2017 only impact the printed/displayed value of the variable.
====== Changes thru 35.104 are in this MXG 35.04 dated May 1, 2017=====
Change 35.104 Support for EDGR/RMM APAR OA46947 which prints asterisks
VMACEDGR for RVCOMPRAT and RVPHYUSED when values can't be derived.
May 2, 2017 Only warning and hex dumps were printed; the output data
sets were correctly built; this change suppressed the
log messages when the values are asterisks.
Thanks to Craig Collins, State of Wisconsin, USA.
Change 35.103 If you specified "defer=yes" in lower case and the input
VMXGSET was on tape you got a 413 ABEND because the compare to
Apr 28, 2017 defer= was comparing to upper case. Not reported, found.
Change 35.102 -z/VM 6.3 and 6.4, BROKEN CONTROL RECORD ERROR because the
VMACVMXA INPUT STSI $VARYING255 STSILEN @; failed when STSILEN was
Apr 28,2017 greater than 255; increased to 512 in VXMTRTOP.
-Also 6.3, VXIODVSW code didn't protect the undocumented
extra 4 bytes. And these new variables are now created:
LANFORW ='LAN*FORWARDING*FLAGS'
OASPORTN ='OSA*PORT*NUMBER'
ACCTYPE ='ACCESS*LIST*TYPE*FLAG'
-New variables in VXSTSYG dataset:
RCCSCAPF='BFP*ZIP*CAPABILITY'
RCCCCAPF='BFP*CP*CAPABILITY'
RCCNCAPF='NOMINAL*CP*CAPABILITY'
SSI1PCPS='CP CORE*SPEED*CYCLE*PER MICRO'
SSI1SCPS='ZIP CORE*SPEED*CYCLE*PER MICRO'
-New variables in VXSTSYG dataset:
RSAWRTHROTS='TIMES*LIMITED*PAGING*BANDWIDTH'
RSAPRTHROTS='TIMES*PARTIAL*WRITE*THROTTLE'
RSANDMREC='GLOBAL*RECLAIM*TASK*INITIATED'
RSANDMRND='NDMBKS*RETURNED*GLOBAL*RECLAIM'
-New variables in VXSTORSP dataset:
PLSNDMRQ='FROM*RECYCLE'
PLSNDMLO='NDMBK REQS*RECYCLE*LOCAL*SUPPLIED'
PLSNDMGL='NDMBK REQS*RECYCLE*GLOBAL*SUPPLIED'
PLSNDMG2L='NDMBKS MOVED*GLOBAL*TO LOCAL'
PLSNDMDX='TIMES*TASK*RETURNED*CHAIN*TO LOCAL'
PLSNDMRET='NDMBKS*RETURNED*TO LOCAL'
PLSNDML2G='NMDBKS*MOVED*LOCAL TO*GLOBAL'
PLSNDMREL='NMDBKS*RETURNED*TO FREE'
PLSNDMREC='TIME*LOCAL*RECLAIM*INITIATED'
PLSNDMRND='NDMBKS*RETURNED*TO FREE*LCL RECLAIM'
PFXCLPLCNT='FRAMES*CLEARED*LOCAL*AVAIL*PLUS'
PLSCLALLO='CLEARED*LOCAL*AVAILABLE*LLOW THRESH'
PLSCLALHI='CLEARED LOCAL AVAILABLE*LHIGH THRESH'
PLSCLALADDED='FRAMES*ADDED TO*CLEARED*LOCAL'
PLSCLALFWREMOVED='FRAMES*ADDED TO*PROCESSED*LIST'
PLSCLALTRIMMED='FRAMES*TRIMMED*CLEARED*LOCAL'
PLSFPPFENTERED='TIMES*FPP FAULT*ENTERED*FOR GUEST'
PLSFPPFSUCCESS='TIMES*FPP FAULT*SUCCESSFUL'
PLSCPPFENTERED='TIMES*FPP FAULT*ENTERED*FOR CP'
PLSCPPFSUCCESS='TIMES*FPP FAULT*SUCCESSFUL*FOR CP'
PLSCPPFMDC='TIMES*FPP FAULT*EXITED*CACHE'
PLSCLALREQUESTS1='TIMES*FRAME REQ*CLEARED*AVAIL LIST'
PLSCLALUNFILLED1='TIMES*REQUEST*FOUND LAL*EMPTY'
PLSCLALREPLENOD='TIMES*REQUEST*FOUND CLA*EMPTY*DEMAND'
PLSCLALUNFILLED2='TIMES*REQUEST*FOUND CLA*EMPTY*BEFORE'
PLSCLALREQUESTS2='TIMES*REQUEST*FROM*CLA LIST'
PLSCLALUNFILLED3='TIMES*REQUEST*FOUND CLA*EMPTY*BEFORE3'
PLSBGCTM='CPU TIME*BACKGROUND*REPLEN*CL GAL'
PLSCGALREQUESTS='TIMES*WANTED*MOVE FRAMES*CGAL TO CLLA'
PLSCGALFRAMESR='FRAMES*WANTED*MOVE*CGAL TO CLLA'
PLSCGALMOVED='FRAMES*MOVED*CGAL TO CLLA'
PLSCGALNOLOCK='TIMES NOT*MOVED*CGAL TO CLLA*LOCK'
PLSCGALUNFILLEDN='FRAMES NOT*MOVED*CGAL TO CLLA*FILL'
PLSCGALWANTING='TIMES*CGLA*INSUFFICIENT*FRAMES'
PLSCGALUNFILLEDW='FRAMES NOT*MOVED*CGAL TO CLAL*DW'
PLSULALCNT='FRAMES ON*UNCLEARED*LAL'
PLSULALLO='UNCLEARED*LOCAL*AVAILABLE*LIST LOW TH'
PLSULALHI='UNCLEARED*LOCAL*AVAILABLE*LIST HI TH'
PLSULALREQUESTS1='FRAME REQ*UNCLEARED*LAL'
PLSULALUNFILLED1='TIMES REQ*UNCLEAR LAL*BEFORE*ATTEMPT'
PLSULALREPLENOD='TIMES REQ*UNCLEAR LAL*AND*ATTEMPT'
PLSULALUNFILLED2='TIMES REQ*UNCLEAR LAL*BEFORE*FILLED'
PLSSWPROCLCNT='FRAMES*ON THE*SOFTWARE*PROCESSED LIST'
Thanks to James T. Barton, Veterans Administration, USA.
Change 35.101 New parameter OUTCODE= lets you insert some code just
VMXGGETM prior to the end of VMXGGETM. Should be complete data
Apr 28,2017 or PROC STEPS.
Thanks to Craig Collins, State of Wisconsin, USA.
Change 35.100 SYSLOG code has been updated; the old code was 2016.
SYSLOG
May 2, 2017
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 35.099 ANALID relocate.
Change 35.098 RMF III Filter enhancements.
ADOCRMFV -Enhancements for character data filtering for RMF Monitor
ASMRMFV III CPU (Processor Data Control Block), CPC (CPC Data
VMACRMFV Control Block), improved message RMFV029* DEAD SPACE
Apr 26, 2017 controls, better error message formats and content, and
other usability and performance gains.
-1 new character filter is added to support CPU entry
selection from this table to the RMFBSAM output file.
This filter is effective only if the CPU or CPC table is
selected and applies to BOTH tables.
New Keyword Aliases
------------ ------------------------------------------
CPUSYSTEM= CPUSYSID=, CPUSID=
Since this is the only filter for this table there are NO
CPUAND/CPUOR parameters.
Syntax and usage mirrors that used for the existing
SYSTEM= parameter for selection by SMF Sysid using ranges
and/or patterns.
-1 new filter is added to support CPC entry selection
from this table to the RMFBSAM output file. This filter
applies ONLY to the CPC (not the CPU) table.
New Keyword Aliases
------------ ------------------------------------------
CPCSYSTEM= CPCSYSID=, CPCSID=
Since this is the only filter for this table there are NO
CPCAND/CPCOR parameters.
Syntax and usage mirrors that used for the existing
SYSTEM= parameter for selection by SMF Sysid using ranges
and/or patterns.
-TUTORIAL:
The new CPCSYSTEM= parameter may appeal to large
installations running multiple z/OS LPARs on a CEC
(Central Electronic Complex) and using RMF Monitor III
gathering data on several of them.
RMF Monitor III creates the CPCDB (Central Processing
Complex Data Block) table for each instance of RMF
Monitor III on a given CEC except if the LPAR is a z/VM
guest.
The CPCDB (aka CPC) has LPAR settings and Logical
Processor data for every image on the CEC whether it be
a z/OS LPAR or not.
There is no RMF III option to turn off CPC data
collection, so this parameter is an alternative.
As long as the RMF Monitor III MINTIME, CYCLE, and SYNC
options are identical redundant CPC tables for every RMF
Monitor III native (non-guest) LPAR on the CEC are
created at every MINTIME interval.
The MXG PDB build will create a ZRBLCP observation for
each Logical Processor for each LPAR for every MINTIME
interval. For installations with several RMF Monitor III
LPARs on a CEC this can result in a lot of extra, but not
useful duplicate SAS ZRBLCP observations.
See new documentation Section 30 "CPC Data Relief
Technique" for more details on use of CPCSYSTEM=.
It is a user responsibility to set up CPCSYSTEM= for each
CEC configuration properly and to track any LPAR SYSID
changes as they occur. An incorrect CPCSYSTEM=
specification will result in loss of data in the MXG
ZRBLCP SAS data set should the SYSID no longer exist
or be misspelled.
-CSR (Common Storage Remaining) processing now moves CSR
entries in blocks for as many entries that fit to the
RMFBSAM output buffer when NO CSR character data filters
are used.
When these filters were added in MXG Change 34.373
processing changed to move one CSR entry at a time to the
output buffer. However, this is an unnecessary overhead
if no CSR filtering is in effect. The earlier processing
technique is restored for this case.
A test with 21 RMF Monitor III sample data sets at the
35.098 level showed about a 1% CPU reduction for CSR
processing with no filters used compared to the 34.373
level. This will vary with the number of CSR entries
and RMF III VSAM data sets processed.
-The MXG00 record version is raised to x'08' from x'07'.
New fields added to the MXG00 record include:
CPUSYSTEM= and CPCSYSTEM= Range/Pattern maximums
CPUSYSTEM= and CPCSYSTEM= Range/Pattern table sizes
% of available TIOT entries used
ASMCPCRX='MAXIMUM*CPCSYSTERM*RANGES'
ASMCPCPX='MAXIMUM*CPCSYSTERM*PATTERNS'
ASMCPURX='MAXIMUM*CPUSYSTERM*RANGES'
ASMCPUPX='MAXIMUM*CPUSYSTERM*PATTERNS'
ASMSHSPL='WARNING*LIMIT*PCT SPACE*USE'
ASMCPCRS='SIZE*CPCSYSTEM*RANGE*TABLE'
ASMCPCPS='SIZE*CPCSYSTEM*PATTERN*TABLE'
ASMCPURS='SIZE*CPUSYSTEM*RANGE*TABLE'
ASMCPUPS='SIZE*CPUCSYSTEM*PATTERN*TABLE'
-TIOT entries used percentage is added to the RMFV000I
message. TIOT usage information is grouped on a single
report line.
-Support for ILIMIT= (alias ILIM=) and SLIMIT= (alias
SLIM=) keywords is added to control appearance of
the RMFV029* DEAD SPACE message (*=I,W,E,S).
Previous versions of ASMRMFV could issue this message for
exhausted RMF III indexes even when the VSAM data set
usage was relatively high. In this case re-allocating
the VSAM data set to make it smaller is not productive.
ILIMIT= specifies a percentage in the range of 0 to 100
as a threshold for RMF III VSAM Data Set Header (DSH)
indexes usage. The default is 100.
SLIMIT= specifies a percentage in the range of 0 to 100
as a threshold for RMF III VSAM Data Set space usage.
The default is 95.
The defaults of ILIMIT=100 and SLIMIT=95 with INDEXES and
SPACE options in effect mean that if all 1110 sample
indexes are exhausted in the Data Set Header (DSH)
record, but the RMF Monitor III VSAM data set is 95% or
more utilized no DEAD SPACE condition is flagged.
See the documentation for RMFV029* for how the settings
of NOINDEXES/INDEXES, NOSPACE/SPACE, ILIMIT=, and SLIMIT=
parameters interact.
Users who find RMFV029* a nuisance rather than an aid
can suppress it completely with ILIMIT=0 and SLIMIT=0.
ILIMIT= and SLIMIT= values in effect are displayed in
message RMFV037I.
Section 22 RMF III VSAM Data Set Index Usage and Sizing
is updated to discuss use of ILIMIT= and SLIMIT= options.
-There are now 4 distinct levels for messages that can
have variable severity based on the settings of the
various existing *ERR= condition keywords:
*ERR Message Return
Setting Suffix Meaning Code
------- ------ ------------------------- ---------
IGNORE I Ignore error/continue No change
WARN W Warn error/continue 0004
ERROR E Issue error/may continue 0008
ABEND S Issue error/Abend U0998 N/A (1)
(1) Abends have a distinct Reason Code but no Return
Code.
In past ASMRMFV versions 'E' suffixed messages
inconsistently may or may not have resulted in an Abend.
-Distributed *ERR settings remain as:
Keyword DEFAULT CONTROLS
--------- ------- -------------------------
ALLOCERR= WARN DYNAMIC ALLOCATION ERRORS
ATTRERR= WARN DATA SET ATTRIBUTE ERRORS
CATERR= WARN CSI CATALOG LOOKUP ERRORS
DEADERR= WARN VSAM DEAD SPACE ERRORS
DSIGERR= WARN DSIG ID (DSH) ERRORS
DSNERR= WARN CSI DSNAME LOOKUP ERRORS
DUPERR= WARN DUPLICATE DSNAME ERRORS
EMPTYERR= IGNORE EMPTY VSAM DATA SET ERRORS
PATTERR= ABEND PATTERN AND/OR RANGE ERRORS
READERR= ABEND VSAM READ I/O ERRORS
TABERR= WARN RMF III TABLE VALIDATE ERRORS
TYPEERR= WARN DATA SET TYPE ERRORS
RCERR= WARN REPORT CLASS FIND ERRORS
RGERR= WARN RESOURCE GROUP FIND ERRORS
SCERR= WARN SERVICE CLASS FIND ERRORS
WLERR= WARN WORKLOAD FIND ERRORS
-ASMRMFV will now generate the correct message format for
variable severity messages during assembly based on the
defaults above. This avoids unnecessary tailoring during
ASMRMFV initiation. Any user overrides of the above
settings will still require tailoring of related
messages by ASMRMFV during start up.
-Internal error message generation interface updated for
following messages:
RMFV004E, RMFV005*, RMFV007S, RMFV034S, RMFV035*,
RMFV056* (*=I,W,E,S)
Improvements for these messages include:
3 separate error messages subroutines replaced by one
for code path length reduction.
Extraneous blanks in these error messages eliminated
for better legibility.
Clearer and less cryptic error descriptions.
-RMFV006E message had incorrect timestamp when FROMDATE=
exceeded TODATE=
-RMFV007S message missing DDNAME when RMFBSAM DD was not
present.
-RMFV007S message will now show N/A when a Reason Code is
not available for a failed function or service.
-Improve logic of DOW= keyword processing when using a
range, i.e. DOW=day1:day2 to examine the last half of
the day of week range if an error is found in the first
half. Also leading and trailing colons are stripped
before length checking.
-Former documentation Section 30 Summary is now Section 31
and former Section 31 Bibliography is now Section 32.
-Several documentation Sections are updated to support
the above changes:
Section 0 "Contents"
Section 5 "Input Data Selection Parameters"
Section 6 "Report Control Parameters"
Section 8 "Error Handling Parameters"
Section 12 "Messages"
Section 13 "Filtered Records"
Section 16 "Return Codes"
Section 25 "Ranges and Patterns"
Section 30 "CPC Data Relief Technique"
Section 31 "Summary"
Section 32 "Bibliography"
Change 35.097 Four IMF variables that are INPUT with TODSTAMP8 are now
VMACCIMS formatted DATETIME25.6 to display full microseconds. The
Apr 25, 2017 other datetimes are limited to DATETIME21.2 resolution.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 35.096 New UTILROLL utility combines all SAS datasets from one
UTILROLL or more SAS data libraries (think "hourly" PDB runs) into
JCLROLL1 another LIBNAME (think "daily" PDB), either concatenating
JCLROLL2 the new data, or interleaving to preserve the sort order.
VGETSORT If the ROLLTO LIBNAME is empty or the dataset being added
Apr 24, 2017 added to does not exist the code will ignore the ROLLTO
LIBNAME and use only the ROLLFROM to create the ROLLTO
datasets.
-VGETSORT could return bad information if there was
a variable name longer than 8 bytes. Length was
increased to 32 and NOBS ENG were added to the output.
Change 35.095 APPL PCT variables are created in TYPE72GO to match the
VMAC7072 RMF Workload report values:
Apr 24, 2017 APPLCP ='APPL PCT*OF 1 CPU*CPU TIME*ON CP'
APPLAAPCP='APPL PCT*OF 1 CPU*ZAAP ELIG*ON CP'
APPLIIPCP='APPL PCT*OF 1 CPU*ZIIP ELIG*ON CP'
APPLAAP ='APPL PCT*OF 1 CPU*CPU TIME*ON ZAAP'
APPLIIP ='APPL PCT*OF 1 CPU*CPU TIME*ON ZIIP'
with this code:
IF R723MCF GT 0 THEN
APPLCP= 100*CPUTM/(DURATM*R723MCF);
IF R723MCFI GT 0 THEN DO;
APPLAAPCP=100*CPUIFETM/(DURATM*R723MCFI);
APPLAAP= 100*(256*CPUIFATM/R723NFFI)/(DURATM*R723MCFI);
END;
IF R723MCFS GT 0 THEN DO;
APPLIIPCP=100*CPUZIETM/(DURATM*R723MCFS);
APPLIIP= 100*(256*CPUZIPTM/R723NFFS)/(DURATM*R723MCFS);
END;
Thanks to Ray Bole, IBM Global Services, USA.
Change 35.094 Support for BMC Mainview for Java Environment creates
EXMVJE01 DDDDDD MXG MXG
EXMVJE02 DATASET DATASET DATASET
EXMVJE04 SUFFIX NAME LABEL
EXMVJE07
EXMVJE08 MVJE01 MVJE01 JMX MEMORY SUMMARY
EXMVJE12 MVJE02 MVJE02 JMX THREAD SUMMARY
IMACMVJE MVJE04 MVJE04 JMX CLASS LOADING SUMMARY
TYPEMVJE MVJE07 MVJE07 JMX GARBAGE COLLECTION SUMMARY
TYPSMVJE MVJE08 MVJE08 JMX MEMORY POOLS
VMACMVJE MVJE12 MVJE12 JMX CPU USAGE
VMXGINIT
Apr 25, 2017
Change 35.093 MXG 35.03 only, variable PLATBUSY in TYPE70/RMFINTRV and
VMAC7072 PCTOFHDW in RMFINTRV were incorrect after Change 35.064
Apr 22,2017 revised the SHARE calculations.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to Robin Hanley, FISERV, USA.
Thanks to David Bixler, FISERV, USA.
Change 35.092 Support for z/VM 64 (INCOMPATIBLE).
VMACVMXA -Dataset VXSYTCUG new variables
Apr 20,2017 SSI2MTIF='MULTITHREADING*CONFIGURATION'
SSI2MTGF='MULTITHREAD*GENERAL*PROC*CONFIG'
SSI2MTID='MULTITHREAD*MAX*TID'
LCUTCTOD='DATETIME*WHEN CORE*INFO*FETCHED'
-Dataset VXMTRSYS new variable
CALFLAG3-'MISCELLANEOUS*FLAGS*/
-Datasets VXUSEACT and VXUSELOF new variables
VMDTTIME_MT1='TOTAL*MT-1*EQUIVALENT*TIME'
VMDVTIME_MT1='RUN*MT-1*EQUIVALENT*TIME'
VMDVTMP_MT1 ='EQUIV*MT-1*VTIME*ON PRIMARY'
VMDTTTP_MT1 ='EQUIV*MT-1*VTIME+SIM*PRIMARY'
VMDVTMS_MT1 ='EQUIV*MT-1*VTIME*ON SECNDRY'
VMDTTMS_MT1 ='EQUIV*MT-1*VTIME+SIM*SECNDRY'
VMAVTMP_PRO ='TOTAL*MT-1*PRORATED*CORE*PRI'
VMATTMP_PRO ='RUN*MT-1*PRORATED*CORE*PRI'
VMAVTMS_PRO ='TOTAL*MT-1*PRORATED*CORE*SEC'
VMATTMS_PRO ='RUN*MT-1*PRORATED*CORE*SEC'
PROBITS='PRORATED*CORE*TIME*BITS'
-Datasets VXPRCPUP new variables
WHIOCAPV='MAX*CORES*PERMITTED'
WHIOCTVR='CALCULATED*T/V*RATIO'
WHIOPTVR='CEILING*PROJECTED*T/V*RATIO'
SRXTVCNF='CONFIDENCE*PERCENTAGE'
CALTVALG='CEILING*PROJECTION*ALGORITHM'
WHIOTVCT='CEILING*PROJECTION*VALID*SAMPLES*/
WHIOGCPV='MAXIMUM*AGGREGATE*CORES'
-Datasets VXIODVSW new variables
VQSAFLAG ='LACP*CONFIGURATION'
NIDLAPRE ='PREVIOUS*LOAD*BALANCE'
NIDLACUR ='CURRENT*LOAD*BALANCE'
NID_TOTPFCNT='PREVIOUS*LOAD*BALANCE*FRAMES'
-New segments IODPAD,IODPON,MTRPCI are not yet supported.
-These 6.4 segments don't exist in my test data so these
changes have NOT been validated yet:
PRCCUP SYTCUG SYTCUM SYTCUP
Thanks to Diana L. Bodner, Progressive, USA.
Change 35.091 -Sometimes failed with a two level dataset name (unknown
ANALCNCR cause). VGETOBS logic modified. Now will run SGPLOT
Apr 22, 2017 if your SAS version is GE 9.3.
-New example to count/plot concurrent TELNET sessions from
the TYP11921 dataset.
Change 35.090 -Support for CA'S OPSS Product USER SMF Record.
VMACOPSS These datasets are created:
Apr 22, 2017
May 9, 2017 DDDDDD MXG MXG
DATASET DATASET DATASET
SUFFIX NAME LABEL
OPSS01 TYPOPSS1 SS TERMINATION SUMMARY
OPSS02 TYPOPSS2 SS OSF SERVER TERMINATION
OPSS03 TYPOPSS3 SS AOF RULE DISABLEMENT
OPSS04 TYPOPSS4 SS GLOBAL VARIABLE
OPSS05 TYPOPSS5 SS SQL STATISTICS
OPSS06 TYPOPSS6 SS IMS BMP STATISTICS
OPSS07 TYPOPSS7 SS OSF TRANSACTION
OPSS08 TYPOPSS8 SS EPI STATS
Thanks to Bruce Sloss, PNC, USA.
Change 35.089 The NDM-CDI new IHDRNDM exit member allows selection of
IHDRNDM which NDM Record Types are output with this logic:
VMACNDM //SYSIN DD *
VMXGINIT %LET MACNDMH= %QUOTE( IF NDMRTYPE='CT';) ;
Apr 19, 2017 %INCLUDE SOURCLIB(TYPSNDM);
Change 35.088 -Running MXG on ASCII to read SMF using ftp access method
BUILDPDB can free the SMF allocation when SMF read is completed
Apr 15, 2017 with this tailoring in your //SYSIN:
%LET EPDBOUT=%QUOTE(
FILENAME SMF CLEAR;
);
If your SMF data is a GDG, this will unblock the base GDG
name as soon as possible.
-If running MXG on z/OS, add FREE=CLOSE to the //SMF DD to
also free the allocation when the read is complete.
Change 35.087 New ANALFTP analysis of FTP has five report examples:
ANALFTP GENERATE REPORTS FROM PDB
Apr 14, 2017 GENERATE REPORTS FROM SMF
GENERATE REPORTS FROM SMF AND STORE DATA IN PDB
GENERATE REPORTS FROM SMF LOOKING FOR A USER
GENERATE REPORTS FROM SMF LOOKING FOR A DATASET
Reports are from TYPE119 records; see also ANAL119 and
ANALCNCR for additional reports.
Change 35.086 New variable FSBYTERATE='TRANSMISSION*BYTE*RATE' is added
VMAC119 to TY119070 dataset.
ANALFTP
Apr 13, 2017
Change 35.085 Possible exposure with too long a code line generated by
VMXGPRNT VMXGPRAL print with variable name and label as heading.
Apr 13, 2017 With 32 character variable name and 40 character label,
the line generated could be 109 characters, exceeding the
z/OS limit of 72 (S=72,S2=72). Two lines are now created
and the label truncated (no more than 5 lost) to trim if
needed.
Change 35.084 UTILCOPY failed if it found no datasets to copy with an
UTILCOPY undefined macro variable NUMMEM. Now it tells you that
Apr 10, 2017 it did not find anything to copy.
Change 35.083 DB2 Trace IFCID=316 dataset T102S316 variable QW0316TS is
VMAC102 now correctly converted to a datetime value.
Apr 10, 2017
Change 35.082 Revision to SAG reports to capture COMPLETE ONLINE and
SAGANAL NATURAL ONLINE in new variables based on PROGRAM name.
Apr 2, 2017
Change 35.081 DB2ACCTP dataset, these "truncated" variables
VMACDB2 QPACLOCN QPACCOLN QPACPKID QPACASCH QPACAANM
Apr 2, 2017 were increased to $128 LENGTH, but the longer length text
was not input when QPACOFFn was non-zero due to incorrect
circumvention for prior invalid length in Change 31.015.
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 35.080 *New z/OS 2.2 Changes found in Jan 2017 SMF Manual.
VMAC30 -VMAC30.
Apr 1, 2017 New variable SMF30JF1='JOB/SESS*ID'
*This change is incomplete.
Change 35.079 Some accumulated z/VM 6.3 SMT fields in VXSYTPRP dataset
VMACVMXA weren't deaccumulated, and the below new unaccumulated
Mar 31, 2017 counters contain an error code '80'x in first bit when
Apr 5, 2017 the counter cannot be populated that is now decoded and
Apr 11, 2017 the first two instances of each error is printed on the
FORMATS SAS log, although there is nothing you can do for these
these error conditions, and the variable is set to a
missing value for these intervals.
SYTPRP_CAL_CAPBYTYPE SYTPRP_CAL_MAXCAPBYTYPE
SYTPRP_CAL_MTUTILBYCORE SYTPRP_CAL_MTUTILBYTYPE
SYTPRP_CAL_PRODBYCORE SYTPRP_CAL_PRODBYTYPE
-Dataset VXAPLSL0 was "hosed" because my loop was
DO CPUNR=1 TO NRCPUS, but first CPU is CPUNR=0, and
the CPUNR at the end of the segment had been overlooked.
-PFXPRKWT is now deaccumulated.
-The VXAPLSLx dataset only has observations output when
there was activity by the Linux machine; the LINXTIME is
the "wake up" time in this interval and is used to create
DELTALINXTM=MRHDRTOD-LINXTIME with the maxiumum duration
of an interval that that VMDUSER could have been active.
-These variables added to VXMTRSYS:
RCCCCAPF RCCSCAPF SYSMTFLG RCCMTRSM RCCMTCFM RCCMTPMT
RCCMTTDW RCCMTFRS RCCCOMXT RCCCOALL
CAL_RCCACMNT1-4='CPUTYPE-1-4*ACTIVATED*THREADS'
CAL_CPUTYPE1-4='CPUTYPE-1-4*CPU*TYPE'
CAL_RCCSYMNT1-4='CPUTYPE-1-4*MAXIMUM THREADS*SOFTWARE'
CAL_RCCHWMNT1-4='CPUTYPE-1-4*MAXIMUM*THREADS*HARDWARE'
CAL_RCCCOMNT1-4='CPUTYPE-1-4*REQUESTED*THREADS'
CAL_RCCCRMNT1-4='CPUTYPE-1-4*REQUESTED*THREADS'
CAL_RCCSMMNT1-4='CPUTYPE-1-4*SPECIFIED*THREADS'
-These variables added to VXSYTCUP:
LCXCMTIT='MT*IDLE*TIME'
LCXCHPCP='LPAR GROUP*ABS CAPACITY*CAP VALUE'
CALGCAPV='ABSOLUTE*CAP*AMOUNT'
-Variable RDEVCTRG is removed from the DIDIO test to
create VXIODDEV because it is always non-zero and the
only non-zero field for non-DASD records.
-The SMT Busy Time calculation was revised to
LCXCMTBY=(2*LCUCACTM)-LCXCMTIT
Thanks to Graham Harris, RBS, ENGLAND.
Change 35.078 If you specified SORTEDBY=YES and you run the daily and
BLDSMPDB weekly/monthly processing in the same SAS execution of
Mar 31, 2017 BLDSMPDB the SORTEDBY= was ignored because VMXGSUM used
the same MACRO variable name making it a GLOBAL macro
variable to VMXGSUM and overriding the BLDSMPDB used
parameter. NO data was lost - just not in the order
you may have expected. Circumvented by holding the
value in a LOCAL macro variable and the reinstating
it after DAILY processing is completed.
Change 35.077 Comments only. Some enhanced comments in examples
UTILBLDP and a redundant WANTSMF in one example was removed.
Mar 31, 2017
Thanks to John Compton, WPS, ENGLAND.
Change 35.076 Some long RMF III variables have '00'x null characters
VMACRMFV instead of blanks at the end; they are converted to
Mar 29, 2017 blanks.
Change 35.075 TYPE1415 records have subtype 5 segments for TAPE and all
FORMATS datasets with a Data Class. For records without subtype 5
VMAC1415 the below flag variables are now set to 'FF'x and will
Mar 29, 2017 print "NOT AVAILABLE" with new $MGNOTAV format:
SMF14BFG SMF14FLGS SMF14FLG2 DEB2XUPF EADSCBOK
DCBEEX31 XTIOTYES
Variable SMF14ALIAS will be blank and SMF14LBS will be a
missing value.
Thanks to Michael Oujesky, DTCC, USA.
Change 35.074 -INVALID SYTCPU segment messages with SEGLEN=48 and NRCPS
EXXAMPRC 30 (SEGLEN should be 684) are valid and a problem is open
EXXMVPID with Barton.
FORMATS -New VSIPID Process Segment creates XMVISPID dataset.
IMACXAM -New PRCCPU LIMPOOL Segment creates XAMSYPRC dataset, but
VMACXAM values for FLAGSPRC have '60'x for both limited cpuaffon.
VMXGINIT
Mar 28, 2017
Change 35.073 DB2ACCT variables QWACALOG and QWACALCT are now always
VMACDB2 missing values; they have been reserved for years, but
Mar 28, 2017 MXG code had still INPUT them causing confusion.
Thanks to Peter Gray, HPE Australia, AUSTRALIA.
====== Changes thru 35.072 are in this MXG 35.03 dated Mar 27, 2017=====
Change 35.072 -MXG 35.03. VMAC1415, hex dumps but no error, because
VGETJESN line 962 in VMAC1415 IF VOLSER NE VOLSER1 THEN LIST;
VMAC1415 left from debugging needs to be deleted.
Mar 24, 2017 -WARNING TYPETASK NOT DECODED, JCTJOBID=A0000022 expected
Mar 27, 2017 either 'ASCH' or 'OMVS' in to be stored in TYPETASK from
variable SUBSYS, but this task has SUBSYS blank. Now, if
SUBSYS is blank, TYPETASK='APPC' is stored.
Thanks to Paul Naddeo, Fiserv, USA.
Change 35.071 Support for z/OS 2.3 RACF 482 segment added to input the
VMAC85 extended LOGSTR text in 1100-byte LOGSTR variable.
Mar 23, 2017 Documented in ICN1560 Mar 23, 2017.
Change 35.070 New fields are added to zPROTECT SMF records:
VMACZPRO New variable in ZPROT05:
Mar 23, 2017 ZPRRAUSR='ALTERNATE*USERID'
New variable in ZPROT16:
ZPRTMINP='MIN*REQUEST*PERFORMANCE*TIME'
ZPRTMAXP='MAX*REQUEST*PERFORMANCE*TIME'
ZPRTAVGP='MEAN*REQUEST*PERFORMANCE*TIME'
ZPRTAUSR='ALTERNATE*USERID'
ZPRNPROT='PROTECT*OPERATIONS'
ZPRNACCE='ACCESS*OPERATIONS'
====== Changes thru 35.069 are in this MXG 35.03 dated Mar 22, 2017=====
Change 35.069 Support for CICS Version TS/5.4 Beta 11 adds three new
UTILEXCL variables to CICSTRAN:
VMAC110 LPARNAME='LPAR*NAME'
Mar 21, 2017 MPSRACT='TIMES WHEN*POLICY*EVALUATED*AND TRIGGERED'
MPSRECT='TIMES WHEN*POLICY*RULES WERE*EVALUATED'
Thanks to Andy Wharmby, IBM CICS Hursley, ENGLAND.
Change 35.068 Support for MQ Version 9.1 SMF 115 new Subtype 201 record
EXTY115Y creates new dataset:
FORMATS dddddd dataset description
IMAC115 TY115Y MQ115201 MQ SUBTYPE 201 PAGESET STATS
VMAC115 Mar 27: FORMATS MG115EX and MG115PS added.
VMXGINIT
Mar 20, 2017
Mar 27, 2017
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.067 -Standalone execution failed because &PDBMXG.SMFINTRV
SMFINTRV needed to be &PDBMXG..SMFINTRV, but MXG invocations in
Mar 14, 2017 BUILDPDB/BUILDPD3 were correct so no error there.
Apr 18, 2017 -Three new interval START datetimes are created so you
can directly summarize to that interval by your choice of
START15INT='FIFTEEN*MINUTE*INTERVAL*START'
START30INT='THIRTY*MINUTE*INTERVAL*START'
STARTHRINT='HOUR*INTERVAL*START'
Apr 11: Revised. Those three variables are now created
by VMXGDUR, with the DEFAULT SMFINTSYNC59 "SYNC59" option
defaulting to YES, to be consistent with RMFINTRV.
If your records are NOT "SYNC59", i.e., are written :00
use %LET SMFINTSYNC59=NO; in your //SYSIN.
Unlike other "INTRV" programs that invoke VMXGDUR to
create new summary datasets, SMFINTRV does NOT summarize
TYPE30_V records; instead it only combines the multiple
SMF 30 records (MULTIDD='Y' steps with LOTS of DDs) into
one observation per interval with all EXCPs totaled.
If you do want to summarize PDB.SMFINTRV across intervals
the ANALSMFI program provides that example.
Change 35.066 APAR OA59593 adds new flag variable
BUIL3005 SMF30CAS_INELIGHONOR='ELIG WORK*IS NOT*OFFLOADED*TO CP?'
BUILD005 to SMF 30 TYPE30_V/TYPE30_4/TYPE30_V datasets to identify
VMAC30 jobs whose eligible work was NOT offloaded to CPs for
Mar 19, 2017 help. The variable is also added to PDB.SMFINTRV and
PDB.STEPS datasets.
Change 35.065 Almost "cosmetic": READDB2 could create dataset DB2STATR
READDB2 even though you did not request it, due to Change 34.265
Mar 14, 2017 that overlaid a token for DB2NETZA. No obs were output.
Change 35.064 SMT Mode corrections and enhancements.
VMAC7072 -ZIPACTTM in PDB.ASUMCELP is the best source of per-LPAR
Mar 13, 2017 hardware zIIP CPU busy, created in BUILDPDB/ASUM70PR.
This change adds SMT_NUM to PDB.ASUMCELP to identify the
SMT mode.
-Variable ZIPACTTM in PDB.TYPE70 could be too small for
an LPAR when in SMT_NUM=2; in rare cases the last LPAR's
was not included.
-Correction for ZIPACTTM in TYPE70 also caused
PLATBUSY LPARSHAC LPARSHAR TOTSHARC TOTSHARE
ZIPSHARC ZIPSHARE LZIPSHAC LZIPSHAR
to also be corrected/changed values in compares.
-TYPE70/TYPE70PR variables CPUID SMT_CORE_ID LCPUADDR and
(new) SMT_THREAD are now formatted numeric HEX2. to
to match RMF reporting formats.
-In the ASID TYPE30 and Service Class TYPE72GO data, the
recorded MT=2 CPUZIPTM/ZIPUNITS values are "inflated"
above the actual hardware zIIP time, and the hardware
equivalent can not be calculated using R723MCFS, the
Maximum Multi-Threading Capacity Factor.
LPAR with 7 zIIP engines in SMT_NUM=2 MT=2 mode:
UPTIME: 1:45 ZIPACTTM: 1:31 72-CPUZIPTM: 2:05 hh:mm
105 min 91 min 125 min
"Above Inflation Factor" 125/91=1.37
Interval R723MCFS =1.17871
"MCSF Equivalent zIIP CPU= 125/1.17871 = 106 min
but that is as large as the UPTIME of 105 minutes.
And IBM's range of R723MCFS values is 1.1 to 1.4,
with a theoretical max of 2.0.
So: what to do? Maybe Nothing. This is what is recorded
now in SMF 30/72 records in MT=2 mode (AND ONLY in ASID
and SRVCLASS records): NO INFLATED VALUES IN RMF 70 SMF
data that are used for zIIP capacity metrics. So, while
the values are too large, their interval sum can be used
to determine the proportion of the MT=2 zIIP usage for
each workload, job, or service class.
Apr 10: IBM SMT folks have examined these data and have
confirmed my conclusions that the values are inflated.
August: IBM confirmed that at very high or very low util
the SMT values are inflated; it's unclear if that will
ever change.
Daniel Rosa's available online 2015 SHARE paper "IBM z
Systems z13 Simultaneous Multi-Threading R(Evolution)"
discusses the MT=2 metrics.
Jul 30, 2018: The CAPZIPRT can exceed 100% due to this
inflation of 30/72 CPUZIPTM when SMT Mode is enabled.
Change 35.064A Multi-Volume DCOLDSET records populate some fields only
VMACDCOL in the first (DCDVOLSQ=1) record. When TYPSDCOL program
Mar 10, 2017 is used, these fields are retained from the first record
and are now output in PDB.DCOLDSET.
-Records with DCDVOLSQ=0 were created in WORK.TYPEDCOL
but were then not output in the first record logic, but
now they are output to PDB.DCOLDSET.
Change 35.063 -XAMSYS records with SYTCUP SEGLEN=148 but SYTNLPS=2 or 3
VMACXAM are wrong, protected by changing SYTNLPS to 5 while the
Mar 10, 2017 problem is opened with Barton now to resolve.
-XMTCPSYS dataset variable NAMENODE was blank because the
128-byte CONTACT was reduced to 64, then NAMENODE, then
64 bytes are inserted to keep the original SEGLEN.
Thanks to Matthew L. Rennebohm, State of Wisconsin, USA.
Change 35.062 Support for Mainview for CICS CMRDETL file VER 6700
VMACMVCI changes that caused INPUT STATEMENT EXCEEDED error.
Mar 6, 2017
Thanks to DJ Chen, AST/Southwood Shared Resource Center, USA.
Change 35.061 Enhancement for PDB.ASUMCELP (per-LPAR CEC data) adds the
VMXG70PR variable SMT_NUM to identify the SMT Mode of zIIPs, from
Mar 7, 2017 the PDB.TYPE70EN dataset, and protection if that dataset
was not copied to the PDB data library. SMT_NUM will be a
missing value for PHYSICAL and IFL-Only LPARS, or LPARS
with no zIIPs.
Change 35.060 Enhancement for SMF 120 Subtype 11 TYP120BL new variables
VMAC120 containing TOTAL, CP ONLY, and ZIP ONLY CPU times:
Mar 5, 2017 SM120BCPUTM='TOTAL*CPUTIME*USED*BCA1-BBZ1'
SM120BCPCPUTM='CP ONLY*CPUTIME*USED*BCA2-BBZ2'
SM120BZIPCPUTM='ZIP ONLY*CPUTIME*USED'
are calculated, thanks to the IBM WebSphere Developer who
educated me that the 16-byte binary TIMEUSED format used
in this record for the START and END Accumulated CPU data
contains two 8-byte CPU times: the TOTAL CP+ZIIP in the
first 8 bytes and the CP ONLY CPU time in the second 8.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.059 Support for CA SYSVIEW for IMS 14.0 update in 2014 Change
VMACSVIE 32.170 has now been tested with actual data, and these
Mar 4, 2017 variables had missing values that are now corrected.
Mar 27, 2017 IMTR_CLK_SUBQ06_TIME IMTR_CLK_MPP_CPU IMTR_CLK_SMB_ENQ
IMTR_CLK_CNT_ENQ IMTR_CLK_MXG_END IMTR_CLK_CNT_GU
IMTR_CLK_UOW_END IMTR_CLK_UOW_START
IMTR_CLK_SCHEDULE_TIME
-Mar 23: Several TODSTAMP variables were not converted
from GMT to local time zone.
Thanks to Denise Williers, Wipro, USA.
Change 35.058 Support for IMS LOG 67D0 DIAGNOSTIC RECORD for DC '02'x
EX67D002 created new IMS67D002 dataset. Note that both D0TIME and
FORMATS IMSSTCK are both GMT because there is no GMT offset in
IMACIMS the 67D0 log record.
VMACIMS
VMXGINIT
Mar 2, 2017
Thanks to Rosa Maria Martinez Alonso, Bustia, SPAIN.
Change 35.057 Support for z/OS 2.3 OAM SMF 85 (COMPAT) addition of
VMAC85 these variables to support multiple OAM Systems in z/OS:
Mar 1, 2017 R85POSUB='OAM*SYSTEM*ID'
R85PSSID='DB2*SYSTEM*ID'
Documented in ICN1552 March 1, 2017
Change 35.056 -If you used KEEPMNTH= (very rare) an MDY() could fail.
VMXGSUM -If your INCODE= contains a DATA step, the CLASSNWAY
Mar 1, 2017 option failed, but now a DATA step's existence in the
INCODE is parsed, and if found, SUMBYCLASS is reset.
Change 35.055 Support for Mainview for IP PTF BPN2331 that adds
VMACMVIP variable TNDSTATX='CONNECTION*STATE*ACTIVE*CLOSED?'
Mar 1, 2017 variable to the I490 dataset.
Change 35.054 -RMF Monitor III enhancement for OPD (OMVS Process Data)
ADOCRMFV table character data filtering and usability.
ASMRMFV -These filters are intended for building ad hoc MXG RMF
VMACRMFV III PDBs for studies avoiding the overhead of generating
Mar 1, 2017 a full OPD table-based PDB. They control which OPD table
entries are output to the RMFBSAM file.
-Five new filters are added to support OPD entry selection
from this table to the RMFBSAM output file. These
filters are effective only if the OPD table is selected.
They are applied in the order shown when multiple
different keywords are used.
New Keyword Aliases
------------ ------------------------------------------
OPDPROCNAME= OPDPROCNA=, OPDPROCNM=, OPDPROC=, OSDPROC=
OPDPN=
OPDJOBNAME= OPDJOBNA=, OPDJOBNM=, OPDJOB=, OPDJN=
OPDUSERNAME= OPDUSERNA=, OPDUSERNM=, OPDUSER=, OPDUN=
OPDAND None
OPDOR None
The order of OPD filter application is:
1) OPDPROCNAME=
2) OPDJOBNAME=
3) OPDUSERNAME=
-TUTORIAL:
Ranges of the form keyword=first:last may be used with
any of the above keywords except OPDAND and OPDOR.
The colon character ':' is required for a paired range
specification. All entries GE the first value and LE the
last value are selected for output to the RMFBSAM file.
The first value may not exceed the last value in EBCDIC
collating sequence or an error is flagged.
Single unpaired values may be specified for a range
simply as keyword=first and in this case the colon ':' is
omitted.
Patterns may also be used with any of the above keywords
except OPDAND and OPDOR and include one or more Wild Card
characters to match the respective OPD data field.
A pattern contains one or more special Wild Card
characters as follows:
Wild
Card Matches
---- ------------------------------------------------
* 0 or more characters
% 1 Non-blank character
+ 1 Numeric character (0-9)
_ 1 Alphabetic character or _ (a-z, A-Z, _)
. 1 National character (@, #, $)
! 1 Special character (not a-z, A-Z, 0-9, @, #, $)
? A blank string if used by itself
? 1 Blank character (X'40') if used with any other
characters
Ranges may not be wild carded. If wild carded the range
value becomes a pattern instead and is processed as such.
See Section 25 "Ranges and Patterns" in the ADOCRMFV
member or ASMRMFV source code for more details on usage
of ranges and patterns.
-OPDPROCNAME= selects OPD tables by 1-8 character z/OS JCL
Procedure Name. Proc Name characters are validated to
those allowed by JCL syntax. Both ranges and patterns
with wild cards may be specified. Up to 16 ranges and 16
patterns are supported. The default is OPDPROCNAME=ALL.
NOTE: There is only ONE OSDPROC field per OPD table. If
the OPDPROCNAME= value does not match, then the ENTIRE
OPD table with all entries is excluded. Use OPDPROCNAME=
with care and discretion and only if the OSDPROC contents
are well understood. Almost always OSDPROC is simply
'OMVS'.
-OPDJOBNAME= selects OPD entries by 1-8 character z/OS
Job Name. Job Name characters are validated to those
allowed by JCL syntax. Both ranges and patterns with
wild cards may be specified. Up to 32 ranges and 32
patterns are supported. The default is OPDJOBNAME=ALL.
Job Names must be 1-8 characters in length and may
include any characters A-Z, #, $, or @. Numeric digits
(0-9) may be used only after the first character.
-Examples for OPDJOBNAME= :
OPDJN=PROD1234:PROD5678 selects only address spaces with
a z/OS Job Name GE 'PROD1234' and LE 'PROD5678' as a
range. Note use of the keyword alias OPDJN for coding
convenience.
OPDJOBNAME=.* is a pattern that selects only address
spaces with a Job Name that begins with a national
character.
OPDJOBNAME=*++ is a pattern that selects only address
spaces with a Job Name that ends with 2 numeric digits.
OPDJOBNAME=ABC:ABC88888 is a range that selects only
address spaces with a Job Name that is GE 'ABC ' and
LE 'ABC88888'.
-OPDUSERNAME= selects OPD entries by 1-8 character z/OS
User Name. User Name characters are validated to those
allowed by JCL syntax. Both ranges and patterns with
wild cards may be specified. Up to 32 ranges and 32
patterns are supported. The default is OPDUSERNAME=ALL.
User Ids must be 1-8 characters in length (1-7 characters
for TSO Ids) and may include any characters A-Z, #, $, or
@. Numeric digits (0-9) may be used only after the first
character.
-Examples for OPDUSERNAME= :
OPDUSERNAME=JOE8888 selects only address spaces with a
login User Name of 'JOE8888'.
OPDUSERNAME=JOE:JOE8888 selects only address spaces with
a login User Name that is GE 'JOE' and LE 'JOE8888'.
OPDUSERNAME=.* selects only address spaces with a login
User Name that begins with a national character (@, #,
$).
OPDUSERNAME=*++ selects only address spaces with a login
User Name that ends with 2 numeric digits (00-99).
-OPDAND (default) indicates that selection results from
the two different OPD filter keywords are logically
ANDed.
-OPDOR indicates that selection results from the two
different OPD filter keywords are logically ORed.
Example 1 with OPDAND in effect:
OPDJOBNAME=ABC* OPDUSERNAME=SAM*
only selects Address Spaces in the RMF Monitor III
OPD table that have a Job Name starting with 'ABC'
AND a User Name beginning with 'SAM'.
Otherwise the Address Space is filtered and will NOT
appear in the result MXG PDB.
The logical AND results in more restrictive
filtering because 2 conditions must be met for an
OPD entry to be selected.
Example 2 with OPDOR in effect:
OPDJOBNAME=ABC* OPDUSERNAME=SAM*
selects Address Spaces in the RMF Monitor III OPD table
that have a Job Name starting with 'ABC' OR a User Name
beginning with 'SAM'.
If the Address Space does not match either selection it
is filtered and will not appear in the result MXG PDB.
The logical OR results in less restrictive filtering than
Example 1 above because any of the 2 conditions results
in data selection of an OPD entry.
-The JOBNAME= (alias JOB=) keyword for multi-table
selection is expanded to include job names from the OPD
table as well as the ASI and CSR tables. This is a
convenience feature to avoid having to code the Job Name
parameter three times when the same job names from all
three tables are of interest.
-The ASI, CSR, and OPD tables must all be selected for the
JOBNAME= multi-table selection keyword to function
completely. Otherwise only entries from selected tables
are filtered.
Note that most RMF III tables do not contain common
character data fields, but in this case the ASI, CSR, and
OPD tables all do contain a Job Name.
JOBNAME= Examples:
JOBNAME=ABC88888 selects only address spaces with a Job
Name of 'ABC88888' in either ASI, CSR, or OPD tables and
is equivalent to coding:
ASIJOBNAME=ABC88888
CSRJOBNAME=ABC88888
OPDJOBNAME=ABC88888
JOBNAME=ABC:ABC88888 selects only address spaces with a
Job Name that is GE 'ABC' and LE 'ABC88888' in either
ASI, CSR, or OPD tables and is equivalent to coding:
ASIJOBNAME=ABC:ABC88888
CSRJOBNAME=ABC:ABC88888
OPDJOBNAME=ABC:ABC88888
JOBNAME=.* selects only address spaces with a Job Name
that begins with a national character in either ASI, CSR,
or OPD tables and id equivalent to coding:
CSRJOBNAME=.*
OPDJOBNAME=.*
-Some RMFV001I Execution Environment messages have been
reformatted to include DFSMS/MVS version, CPC Name, LPAR
Name (if not a VM Guest), or VM Userid (if a VM Guest).
TIOT statistics are now grouped on the same message line.
-The Creation date was not valid when non-VSAM data set
was incorrectly provided as a RMF III data set. CRDATE
is removed from the RMFV008I message in this case.
-The MXG00 record version is raised to x'07' from x'06'.
New fields added to the MXG00 record are:
IPL timestamp in LOCAL and GMT time
IPL volume serial
TIOT size in K and bytes
TIOT maximum and used entries
CPC Name, LPAR Name, and VM UserId
DFSMS/MVS level
-Several documentation Sections are updated to support
the above changes:
Section 5 "Input Data Selection Parameters"
Section 12 "Messages"
Section 13 "Filtered Records"
Section 25 "Ranges and Patterns"
Section 30 "Summary"
-VMACRMFV was updated to add new variables to ZRBASM:
ASMDFLVL='EXECUTION*DFSMS/MVS*LEVEL'
ASMOPNRX='MAXIMUM*OPDPROCNAME*RANGES'
ASMOPNPX='MAXIMUM*OPDPROCNAME*PATTERNS'
ASMOJNRX='MAXIMUM*OPDJOBNAME*RANGES'
ASMOJNPX='MAXIMUM*OPDJOBNAME*PATTERNS'
ASMOUNRX='MAXIMUM*OPDUSERNAME*RANGES'
ASMOUNPX='MAXIMUM*OPDUSERNAME*PATTERNS'
ASMOJNRS='SIZE*OPDJOBNAME*RANGE*TABLE'
ASMOJNPS='SIZE*OPDJOBNAME*PATTERN*TABLE'
ASMOPNRS='SIZE*OPDPROCNAME*RANGE*TABLE'
ASMOPNPS='SIZE*OPDPROCNAME*PATTERN*TABLE'
ASMSPGAO='SPG*MULTI*FILTER*LOGIC*I/O?'
ASMSINDD='SYSIN/SYSINA*DCB*DDNAME'
ASMVFREE='FREE=CLOSE*OPTION?'
ASMSINMG='SYSIN*MEMBER*OR*GENERATION'
ASMOUNRS='SIZE*OPDUSERNAME*RANGE*TABLE'
ASMOUNPS='SIZE*OPDUSERNAME*PATTERN*TABLE'
ASMIPLTL='LAST IPL*LOCAL*TIME'
ASMIPLTG='LAST IPL*GMT*TIME'
ASMTIOTB='MAXIMUM*TIOT SIZE*BYTES'
ASMTIOTK='MAXIMUM*TIOT SIZE*IN K'
ASMTIOTX='MAXIMUM*TIOT*ENTRIES'
ASMTIOTU='CURRENT*TIOT*ENTRIES*IN USE'
ASMCPCNM='CPC*NAME'
ASMLPARN='LPAR*NAME'
ASMVMUID='VM*USERID'
ASMIPLVL='IPL*VOLUME*SERIAL*NUMBER'
Change 35.053 SYSOTHER checking is enhanced. Test for CPUTM NE 0 added
VMXGRMFI to SYSOTHER detection, since if the CPUTM is 0 it cannot
Feb 28, 2017 impact totals, but workload names and descriptions are
identified so you can find the culprit, since nothing
should ever fall thru to Service Class SYSOTHER.
Change 35.052 DATETIME syntax was revised per change 35.022, although
TRNDVMXA the new VMXGSUM correctly supported the old syntax with
Feb 28, 2017 no error.
Change 35.051 Support for Liberty 17.0.0.1 SMF 120 Subtype 12 COMPAT
VMAC120 enhancements, adds these variables to TYP12012 dataset:
Feb 28, 2017 SM120CDO='REFERENCE*TYPE' MG120CD format decodes:
1='1:READER'
2='2:PROCESSOR'
3='3:WRITER'
4='4:CHECKPOINT'
5='5:BATCHLET'
6='6:PARTITION_MAPPER'
7='7:PARTITION_REDUCER'
8='8:PARTITION_COLLECTOR'
9='9:PARTITION_ANALYZER'
10='10:DECIDER'
SM120CDU='PHYSICAL*CPU*ADJUSTMENT*RCTPCPUA'
SM120SU_SEC='CPU*RATE*ADJUSTMENT*RMCTADJC'
SM120CDW='REPOSITORY*TYPE*JPA* OR MEM'
SM120CDX='JOB*STORE*REF*ID'
SM120CDY='SM120CDY*FLAGS'
Next six variables are only valid in step end record
SM120CDZ='STEP*START*LIMIT'
SM120CEA='CHUNK*STEP*CHECKPOINT*POLICY' decodes:
0='0:ITEM'
1='1:CUSTOM'
SM120CEB='CHUNK*STEP*ITEM*COUNT'
SM120CEC='CHUNK*STEP*TIME*LIMIT'
SM120CED='CHUNK*STEP*SKIP*LIMIT'
SM120CEE='CHUNK*STEP*RETRY*LIMIT'
Change 35.050 PDB.ASUMCELP REQUIRES SMF 70s from ALL SYSTEMs to be read
VMXG70PR to correctly populate all variables. Each SMF 70 record
Feb 27, 2017 contains a "This System" segment that populates TYPE70,
and an "LPAR Segment" for each LPAR, for TYPE70PR, so the
LPAR data can be reported & summarized from a SMF 70 from
only one system, but then all the "This System" variables
are wrong, notably, SMF70LAC, the IBM 4HR AVG MSU, which
will contain ONLY the MSU from the one "This System".
This change compares TYPE70 and TYPE70PR to detect if
there are missing TYPE70 or TYPE70PR data, printing a
a PROC FREQ with missing systems identified, and printing
a log message that SMF70LAC will be wrong.
Change 35.049 Support for MAINVIEW FOR IMS 5.3 a/k/a IMF or CIMS which
VMACCIMS COMPATIBLY added these variables to the CIMSTRAN dataset:
Mar 12, 2017 TRNMSYS ='MQ*REMOTE*SYSTEM*NAME'
TRNDSYS ='DB2*REMOTE*SYSTEM*NAME'
TRNFLTRD='SOME*CALLS*NOT TRACED*FILTERS?'
TRNPRELD='PGM*WAS*PRELOADED'
TRNINFL ='TRN WAS*CAUGHT*INFLIGHT'
Change 35.048 Support for IWS Version 9.3, a/k/a TWS and was OPC, which
VMACOPC replaces subtype 23 with new subtype 66 with the original
Feb 24, 2017 variables plus these four new variables
TRLDURS23='DURATION'
TRLOID23 ='OPERATION*ID'
TRLOLDST23='OLD*STATUS'
TRLREADY23='START*DATETIME*WAIT*OPR'
The new subtype 66 record is output in the OPC23 dataset
so your reports won't have to be changed.
Thanks to Teuvo Virsu, TIETO,
Change 35.047 Support for IFCID 316 ACCESS CONTROL AUTH EXIT PARMS.
VMAC102
Feb 24, 2017
Change 35.046 Support for IFCID 125 Truncated Package Collection and
FORMATS Package Name fields, and new variables for Runtime
VMAC102 Adaptive Index in T102S125 dataset:
Feb 20, 2017 QW0125TI='INDEX*PROBING*RIDS IN*INDEX'
QW0125QI='INDEX*PROBING*RIDS*IN*KEYRANGE'
QW0125_TRSN='REASON*LEG*WAS*TERMINATED?'
QW0125_PRSN='REASON*LEG*NOT*PROBED?'
QW0125_ORSN='REASON*LEG*WAS*REORDERED?'
QW0125_FRSN='REASON*LEG*WAS*MARKED FULL?'
Change 35.045 ANALDB2R variable QWHSRELN format expanded from 3.1 to
ANALDB2R 4.1 to print full 10.1 Release value in reports.
Feb 20, 2017
Change 35.044 -The new ZRBCPU SMT Multithreading variables were always
VMACRMFV missing due to an invalid MXG test for LENLEFT.
Feb 20, 2017 -New variables found in the Dec 2016 Programmers Guide:
Dataset ZRBCPU:
CPC_CECNAME='CPC*CEC*NAME'
LPARHWGR='LPAR*HW*GROUP*NAME'
Dataset ZRBLCP:
LCPUHWLW='HW*GROUP*CAP*LIMIT'
LPARHWGR='LPAR*HW*GROUP*NAME'
-APAR OA58688 adds these new fields.
Thanks to MP Welch, Bank of America, USA.
Change 35.043 SMF74NID, the Network ID, contains 26 EBCDIC and 2 hex
VMAC74 bytes that don't "print pretty". Variable SMF74NIDTWO
Feb 20, 2017 keeps those two bytes, formatted $HEX4. for printing.
Thanks to Pierre Pascal Joulin, Societe Generale, FRANCE.
Change 35.042 Sample code that creates charts of resource group CPU
GRAFCAPS usage and capping.
Feb 17, 2017
Change 35.041 DCOLLECT format MGDCOSG adds new 6='6:COPYPOOL' value to
FORMATS map that value in variable DSGFTYPE.
Feb 17, 2017
Thanks to J. Alan Gray, CareFirstBlueCrossBlue Shield, USA.
Thanks to Stanley M. Helms, CareFirstBlueCrossBlue Shield, USA.
Change 35.040A IBM APAR OA51325 corrects invalid SMF 15 record missing
VMAC1415 the UCB segment causing VOLSER to be truncated to two
Feb 17, 2017 characters. No code change to support the corrections.
Change 35.040 Support for Velocity Software ZWRITE file z/VM MONWRITE
VMACVMXA records which have a new BEGINMTR value for each (hour)
VMXGINIT period, which caused the first interval of each (hour) to
Feb 15, 2017 be lost, because normal MONWRITE records have a single
BEGINMTR value for each file. But the ZWRITE records are
contiguous in spite of changed BEGINMTR, so this support
is enabled with %LET MXGZWRITE=YES; in SYSIN which
will set BEGINMTR only from the first instance so only
the very first interval is lost per day.
// EXEC MXGSASV9
//VMINPUT DD DSN=YOUR.ZWRITE.MONWRITE.DATA,DISP=SHR
//PDB DD DSN=YOUR.ZWRITE.PDB,DISP=OLD
//SYSIN DD *
%LET MXGZWRITE=YES;
%INCLUDE SOURCLIB(VMACVMXA,IMACKEEP);
_TESTVM /*READS VMINPUT */
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 35.039 MQMQUEUE variable WQQTYPE is mapped by MG116QT format
FORMATS VALUE MG116QT
VMAC116 1='1:LOCAL'
Feb 15, 2017 2='2:MODEL'
3='3:ALIAS'
6='6:REMOTE'
7='7:CLUSTER'
-GMTOFF116 calculation revised correcting occasional
missing values in WQCLOSTI, WQOPENTI, and WQTTTIME.
(WQCLOSTI can be validly missing).
-APAR PI70580 corrects invalid WQBASENA variable values,
which seem to occur in every second segment in each
SMF record, but other segment's values are valid.
Thanks to Raymond Smith, Optum TECH, USA.
Thanks to Pietro Rosella, Canadian National Rails, CANADA
Change 35.038 MXG 34.04 added PROC DELETE DATA=:CIC after PDB.CICINTRV
CICINTRV had been created, intending to delete ONLY CICS Stats
VMXGCICI datasets to free up //WORK space for subsequent use, but
Feb 14, 2017 if CICINTRV was intentionally left in //WORK, it was then
unintentionally deleted by that colon modifier, and ITRM
expected it to be left in WORK as it had been previously.
Since no one had actually asked for this cleanup, it has
been removed from VMXGCIC. But, added at the bottom of
the CICINTRV member, inside a comment block, is the code
to delete all of those CICS Stats, if you do wish to.
Thanks to Don Barnard, North Carolina State Government, USA.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 35.037 ASUMDB2P expected variables QPACDBRM/QPACPACK would be
ANALDB2R populated, but those bits were removed in DB2 V10, so now
ASUMDB2P PACKTYPE is blank.
Feb 14, 2017 -ANALD2R was not correctly rolling up the control break
totals in the Accounting SHORT report.
Change 35.036 VMXGSUM will now tell you with an MXGNOTE when it cannot
VMXGSUM use CLASS NWAY and why it cannot. There are two cases:
Feb 11, 2017 - Use of DESCENDING in the SUMBY
- same dataset name for input and output and no OUTCODE
specified
It will also now display the final setting of SUMBYCLASS.
Thanks to Tim Hare, Southwood Shared Resource Center, USA.
====== Changes thru 35.035 are in this MXG 35.02 dated Feb 10, 2017=====
Change 35.035 Protection for Invalid TPX Subtype 7 record with Segment
VMACTPX TPX07LEN=93 but only 44 bytes remain in the record. MXG
Feb 10, 2017 silently deleted the record, because of prior invalid 07x
Feb 14, 2017 causing zero obs in TPXAPLON Logon dataset. The first 44
are now INPUT, and the remainder conditionally input.
-Feb 14: Correction for undocumented 8 byte insert
in '06' and a blank in TPXSNAME.
-Feb 14: Each pair of subtype 01 TPXSTART records have the
same SMF time, but the second record is a continuation of
the first record, which is not supportable; a problem
report will be opened with TPX Support.
-TPX PTFS R088919 and R085818 correct some errors, while
CA Fix TR95030 corrects the bad subtype 1 records which
turned out to subtype 2 records with wrong subtype.
Thanks to Scott Wiig, USBank, USA.
Thanks to Paul Volpi, UHC, USA.
Change 35.034 Support for the BBMQ large segment record structure that
VMACBBMQ are created by the BMC BBM9MD73 utility program that
Feb 10, 2017 extracts the records from the history file for TYPEBBMQ
to then process. Both old and new format records are
supported with this change and there were no changes to
the MXG datasets. This is support for BBMQ 5.3.
Change 35.033 Logic to determine the begin/end of month was robusted
VMXGALOC and non-zero length MNTHKEEP will always display the
Feb 9, 2017 MONTH Libname value.
Change 35.032 Documentation Only. DCOLLECT records can contain the JOB
VMACDCOL and STEP and the TIME of the Creating JOB for DISP=NEW
Feb 9, 2017 datasets, but the EATTR option must be specified either
in the DATACLASS definition or with a DD statement.
Thanks to Paul Newton, IBM RDP Dallas, USA.
Change 35.031 Variable S42DSIOS='RW TO*METRO*MIRROR*SECONDARY' is added
VMACDB2 to dataset TYPE42DS, having been overlooked.
Feb 9, 2017
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND
Change 35.030 DB2 statistics dataset DB2STAT4 QW0225_LMWRITE_REAL and
VMACDB2 _QW0225_LMCTYRL_REAL were incorrectly very large due to
Feb 7, 2017 a 4-byte misalignment.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.029 RACF SMF70DTP/RACFTYPE=6 segment was increased in length
VMAC80A from 124 to 136 but had not been protected for a change.
Feb 7, 2017 Three additional keyword variables ADDLKEY1-ADDLKEY3
are added to TYPE8010 and TYPE8013 datasets.
Thanks to Coen Wessels, GTS Infrastructure, SWITZERLAND.
Change 35.028 Support for RMF III dataset ZRBENC new "long name" fields
ASMRMFV that were added by z/OS 2.1 but not captured by ASMRMFV.
VMACRMFV Variables EDEPCKG EDEPROC EDEUSER EDETRXN ECEACCT were
Feb 6, 2017 increased in length and these new variables are kept:
EDESCHEDENV ='SCHEDULING*ENVIRONMENT*NAME'
EDESCHEDENVLN ='S E NAME LENGTH'
EDESUBSYSCOLLECT ='SUBSYSTEM*COLLECTION*NAME'
EDEPCKGLN ='PACKAGE*NAME*LENGTH'
EDEPROCLN ='PROCEDURE*NAME*LENGTH'
EDECLIENTIPADDR ='CLIENT*IP*ADDRESS'
EDECLIENTIPADDRLN ='CLIENT*IP*ADDRESS*LENGTH'
EDEUSERLN ='CLIENT*USERID*LENGTH'
EDETRXNLN ='CLIENT*TRANSACTION*NAME*LENGTH'
EDECLIENTWRKSTATION ='CLIENT*WORKSTATION'
EDECLIENTWRKSTALN ='CLIENT*WORKSTATION*LENGTH'
EDEACCTLN ='CLIENT*ACCOUNT*LENGTH'
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 35.027 Support for DB2 NETEZZA DB2ACCT Q8AC Accumulated fields:
IMACDBNZ Q8ACINSC='INSERT*STATEMENTS*SENT TO IDAA*FROM DB2'
Feb 6, 2017 Q8ACUPDC='UPDATE*STATEMENTS*SEND TO IDAA*FROM DB2'
Q8ACDELC='DELETE*STATEMENTS*SEND TO IDAA*FROM DB2'
Q8ACDRPC='DROP*STATEMENTS*SEND TO IDAA*FROM DB2'
Q8ACCRTC='CREATE*STATEMENTS*SEND TO IDAA*FROM DB2'
Q8ACCMTC='COMMIT*STATEMENTS*SEND TO IDAA*FROM DB2'
Q8ACRBKC='ROLLBACK*STATEMENTS*SEND TO IDAA* FROM DB2'
Q8ACOPNC='OPEN*STATEMENTS*SEND TO IDAA*FROM DB2'
Q8ACROWI='ROWS*INSERTED*TO IDAA*BY DB2'
Q8ACROWU='ROWS*UPDATED*ON IDAA*BY DB2'
Q8ACROWD='ROWS*DELETED*ON IDAA*BY DB2'
Q8ACROWC='ROWS*RETURNED*BY IDAA*TO DB2'
These variables are output in DB2ACCT, but they appear
to be defective, as they are supposed to be ACCUMULATED
but the 2012 and 2013 test data I have has breaks in the
expected monotonic increase, so if you are interested in
these fields, please send current SMF 101 data so I can
investigate if the accumulation is now valid.
Change 35.026 If MXG detects Service Class Name of SYSOTHER, error msgs
UTILRMFI are printed when SMF 72 records are processed. SYSOTHER
Feb 1, 2017 should never happen; it is the fall thru service class
when WLM can't classify work and runs at the lowest DPRTY
in MTTW mode, and thus should NOT ever happen! Now, when
UTILRMFI is run to examine the problem, it will also read
the PDB.SMFINTRV or PDB.TYPE30_4 dataset to find what
tasks were classified into SYSOTHER, reporting JOB name,
READTIME, JESNR, and SRVCLASS and RPTCLASS. If there are
type 30 records they will be reported but there may not
be any, if no tasks actually went to the service classes,
or the workload is one where there is no type 30 record
(e.g., DDF). All workloads in your WLM classification
rules should have a default service class SPECIFIED:
-Unclassified work will default to one of two places
- Started Tasks default to SYSSTC
- All other work defaults to SYSOTHER
Neither is a good choice. SYSSTC runs at very high DP
and SYSOTHER runs at very LOW DP. While very low may be
appropriate for workloads you do not know, very high is
almost certainly not.
-Reports 1 thru 3 already exist.
-Report 4 is added to give you the job names, read times
jes numbers, service and report class where the service
class is SYSOTHER, from 30_4 and SMFINTRV.
-Report 5 is added to show you any DB2ACCT records that
may have landed in SYSOTHER as they may not be in a type
30 record.
-Report 6 is added to show you all tasks falling into
SYSSTC, from 30_4, SMFINTRV and 30_6.
-Report 7 is added as a table of CPU consumption by
service class and system, from TYPE72GO.
-Report 8 is added as a table of CPU consumption
by report class and system from TYPE72GO.
Change 35.025 Using the _VMINPUT macro to read VB z/VM MONWRITE data
VMACVMXA incorrectly set the length of VMDUSER to only one byte.
Feb 1, 2017
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 35.024 SMF 120 Subtype 9 variables SM1209EV/EW/SM1209FI are not
VMAC120 kept. In TYP1209U detail dataset, they are output either
Feb 3, 2017 in new variables SM1209xxEJBDET or SM1209xxWEBDET, and in
datasets TYP1209R and TYP1209N they are summed and output
in SM1209xxEJB and SM1209xxWIB variables.
The TIME format was removed from the EW count variables.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.023 MXG 35.01. If UTILEXCL executed with //PDB DD DISP=OLD,
UTILEXCL only the NEW dictionary records read from SMF are used
Jan 29, 2017 to create the IMACEXCL, and old dictionary records are
lost; only the new records are output in PDB.CICSDICT.
(The step DATA _LCICDIC; SET _WCICDIC; to add the LABEL
was changed to SET _LCICDIC to correct this error.)
Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
Change 35.022 ANCIENT syntax of DATETIME in SUMBY in user tailored
VMXGSUM invocation of VMXGSUM (pre MXG Version 21 example!) can
Jan 29, 2017 cause VMXGSUM, which is used EXTENSIVELY internally in
MANY MXG members, to fail, sometimes with only a message
WARNING: VARIABLE QWACBSC ALREADY EXISTS ON WORK.MXGSUM3
or it can ABEND with ERROR FUNCTION COMPBL TOO FEW ARGS.
Only three sites reported the error with MXG 35.01/34.34.
Primary exposure was this syntax,
SUMBY= . . .DATETIME . . . ,
ID= . . . QWACBSC . . . ,
DATETIME= QWACBSC,
which caused the output dataset variables QWACBSC and
DATETIME have missing values.
The correct syntax replaces DATETIME in the SUMBY= :
with the DATETIME= variable, and removes the DATETIME=
variable from the ID= argument,
This error was exposed in MXG 34.05 in Change 34.151 for
the CLASSNWAY update that is also corrected. But, even
though unlikely, this change detects the old syntax with
DATETIME in SUMBY= argument, changes to correct syntax,
and tells you what was done for you in a log note.
If you had DATETIME in the SUMBY= list and also did NOT
explicitly use the DROPDT=NO option, then DATETIME
variable is kept in the output dataset.
-Unrelated, this change adds the FLORCEIL parameter to
VMXGSUM so you can create interval start or end times as
you can do in VMXGDUR. Setting FLORCEIL=CDIL sets the END
time or FLORCEIL=FLOOR sets the START time, and the label
indicates START or END.
-Note: this internal MXG Change could be INCOMPATIBLE with
programs that worked perfectly previously; send your code
VMXGSUM invocation and we will update your code.
Thanks to Paul Volpi, UHC, USA.
Change 35.021 MXG 35.01, TYPE78PA variables R782LSMOxx and R782GFMOxxx
VMAC78 and R782GFFRxxx are incorrect; R782LSMOMIN should have
Jan 27, 2017 been INPUT before R782LSMONTME, but statement was lost
causing R782LSMOMIM UNINIT message.
Thanks to Paul Naddio, FISERV, USA.
Change 35.020 MXG 35.01. Spurious MXGWARN: VMXGSUM BACKLEVEL MXG 3434
VMXGSUM note has no impact; the VMXGDUM in 35.01 is correct, but
Jan 25, 2017 the VMXGVERS call was not updated with '35.01' text.
Change 35.019 -Support for changed SYTCPU with SYTNLPS=1 SEGLEN=48
VMACXAM that caused INVALID SEGMENT record, XAMSYT dataset.
Jan 26, 2017 -Support for new SYTLC3 segment in XAMSYS records
Mar 2, 2017 was added on March 2, adding these new variables:
CALLCKID='CALL*CHECKID'
INDEX ='TO MATCH*HISTORY DATA'
SECONDS ='SECONDS'
CALXSCNT='TOTAL*SPIN*TIMES*EXCLUSIVE'
CALXTIME='TOTAL*SPIN*TIME'
CALSSCNT='SPIN*TIMES*SHARED'
CALSTIME='SPIN*TIME*SHARED*MODE'
CALCADSH='CAD*INSTRUCTIONS*OBTAIN*LOCK'
CALCADEX='CAD*INSTRUCT*OBTAIN*EXCL LOCK'
-Support for new HSTME2 segment in XAMTCP was added
on March 2, changing only the length of DESCR to
60 bytes.
Thanks to Patricia Hansen, ADP, USA.
Change 35.018 An extraneous character in the SU_SEC format raised a
GRAFWRKX WARNING but did not cause an error, but ZIPTM, IFATM, and
Jan 26, 2017 ZIETM were not being properly summed, causing the ZIP ZAP
and ZIE graphs to be suppressed.
-ODS PROCLABEL statements added to make the index 'pretty'
when creating HTML or PDF output.
Thanks to Tom MacCabe, Dominion Resources Services, Inc., USA.
Change 35.017 New DB2 ZPARMs are added to T102S106 Dataset:
VMAC102 QWP4MNSU='MATERIALIZE*NODET*SQLTUDF?'
Jan 25, 2017 QWP4DSINUN='DISALLOW*SELINTO*UNION?'
QWP4MTAD='MOVE*TO*ARCHIVE*DEFAULT'
Thanks to Lai Fai Wong, Bank of America, USA.
Change 35.016 DB2STATS dataset, these seven storage variables
VMACDB2 QISTWSTG QISTDGTTSTG QISTDGTTCTO QISTDGTTMXU
Jan 24, 2017 QISTWFSTG QISTWFCTO QISTWFMXU
were multiplied by 4096 (page size) instead of by 1024
to convert KB to bytes for MGBYTES. format.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 35.015 Support for SMF 117 written by GTZ (conflicts with 117
VMAC117 from Message Broker), now GTZ record is ID=125.
VMAC125 -If you use TYPE117, it will delete any GTZ records and
Jan 20, 2017 tell you that they were NOT Message Broker records.
-To process the 117s from GTZ, use this in //SYSIN DD
until you have the APAR that writes them as 125's:
%LET MACFILE=
%QUOTE(IF ID=117 THEN DO;
INPUT @15+OFFSMF SM117SSI $EBCDIC4. @;
IF SM117SSI='GTZ ' THEN ID=125;
END;
);
and tell MXG to process both 117 and 125 records.
====== Changes thru 35.014 are in this MXG 35.01 dated Jan 20, 2017=====
Change 35.014 A variable with DATETIME embedded in the name caused an
VMXGSUM branch in the code building the SUMBY string and caused
Jan 19, 2017 the SORT to fail with a variable not found.
Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
Change 35.013 If you used AUTOALOC=YES with RUNMNTH=MTD on the second
BLDSMPDB day of the month, the previous month may have been
Jan 18, 2017 deleted.
Change 35.012 Old protection for APAR OA24074 caused ZERO DIVIDE ID=70
VMAC7072 if CPUUPTM and CPUPATTM were identical, now protected.
Jan 18, 2017
Thanks to Job Varkey, Verisk Analytics, USA.
Thanks to Cesar V. Cocco, Verisk Analytics, USA.
Change 35.011 For local time zones with +GMT, variable GMT115TM was
VMAC115 one hour too large, fortunately impacting only variables
Jan 17, 2017 QJSTIOMAXIOT1-4 and QJSTIOMAXSUST1-4 in MQMLOG dataset.
Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
Change 35.010 OSEM User SMF INPUT STATEMENT EXCEEDED, invalid record
VMACOSEM with length of last segment not provided if there was
Jan 26, 2017 more than one segment. The year 2000 vendor DSECT does
Apr 3, 2018 show a '00'x terminates the record, so that is now used
to detect the length of the last segment.
Code sent in Mar, 2018 but VMACOSEM updated in 36.04.
Thanks to Nilton D Junior, IBM, BRAZIL.
Change 35.009 Support for APAR OA48913 metrics for 2GB Memory Frames.
VMAC71 -New variables in TYPE 71:
Jan 13, 2017 SMF71GAA='AVG 2GB FRAMES*IN LFA*NOT IN-USE'
SMF71GAM='MIN 2GB FRAMES*IN LFA*NOT IN-USE'
SMF71GAX='MAX 2GB FRAMES*IN LFA*NOT IN-USE'
SMF71GFA='AVG TOTAL*2GB FRAMES*CAN BE USED'
SMF71GFM='MIN TOTAL*2GB FRAMES*CAN BE USED'
SMF71GFX='MAX TOTAL*2GB FRAMES*CAN BE USED'
SMF71GOA='AVG FIXED 2GB*OBJECTS*ALLOCATED'
SMF71GOM='MIN FIXED 2GB*OBJECTS*ALLOCATED'
SMF71GOX='MAX FIXED 2GB*OBJECTS*ALLOCATED'
SMF71GRA='AVG 2GB PAGES*FIXED*IN CSTORE'
SMF71GRM='MIN 2GB PAGES*FIXED*IN CSTORE'
SMF71GRX='MAX 2GB PAGES*FIXED*IN CSTORE'
SMF71GUA='AVG 2GB FRAMES*IN LFA*IN-USE*BY FIXED MEMOBJ'
SMF71GUH='HWM*2GB FRAMES*USED'
SMF71GUM='MIN 2GB FRAMES*IN LFA*IN-USE*BY FIXED MEMOBJ'
SMF71GUX='MAX 2GB FRAMES*IN LFA*IN-USE*BY FIXED MEMOBJ'
-New variables in TYPE78PA:
R782GFMOMIN ='MIN FIXED*MEMOBJ*BACKED IN*2GB FRAMES'
R782GFMONTME='TIME STAMP*OF MIN*MEMOBJ*BACKED*IN 2GB'
R782GFMOMAX ='MAX FIXED*MEMOBJ*BACKED IN*2GB FRAMES'
R782GFMOXTME='TIME STAMP*OF MAX*MEMOBJ*BACKED*IN 2GB'
R782GFMOAVG ='AVG FIXED*MEMOBJ*BACKED IN*2GB FRAMES'
R782GFFRMIN ='MIN 2GB PAGES*FIXED*IN CSTORE'
R782GFFRNTME='TIME STAMP*OF MIN*PAGES*FIXED*IN CSTORE'
R782GFFRMAX ='MAX 2GB PAGES*FIXED*IN CSTORE'
R782GFFRXTME='TIME STAMP*OF MAX*PAGES*FIXED*IN CSTORE'
R782GFFRAVG ='AVG 2GB PAGES*FIXED*IN CSTORE'
Change 35.008 TYPE42 variable S42CSID, the SSID is now formatted HEX4.
VMAC42 as are the other SSID variables in TYPE42 datasets.
Jan 12, 2017
Thanks to Michael Friske, FMR, USA.
Change 35.007 Liberty SMF 120 subtype 12 TYP12012 dataset variables
VMAC120 SM120CCC and SM120CCD had year 2027 plus 1 day later
Jan 12, 2017 because MXG added the DEL6070 seconds between 1960-1970
TWICE. Variable SM120CCB, also on the 1970 epoch, was
correct as DEL6070 (315619200) was only added ONCE.
Thanks to Steve McKee, FMR, USA.
Change 35.006 Duplicate RMFINTRV obs were created if multiple Capacity
VMXGRMFI Group Names existed in the TYPE70PR data; MXG did not
Jan 10, 2017 select the obs with SYSTEM=SMF70STN and inadvertently
Jan 25, 2017 output duplicated records; Most values were exact dupes,
but SMF70GNM SMF70GMU TOTMEMR values were different.
-This error was introduced in MXG 34.01, Change 34.029.
-Protected archaic DURSET and DETAIL interval Jan 25.
Thanks to Joachim Sarkoschitz, DATEV, DENMARK.
Thanks to Frank Fischer, Concordia, GERMANY.
Change 35.005 RMF III dataset ZRBLCP observations were created for each
VMACRMFV LCPUADDR in the LPAR, only if the LCPU Dispatch Time was
Jan 10, 2017 non-zero, but that test is changed to output LCPUADDRs
that are ONLINE (by testing LCPUONL), so that ZRBLCP has
an observation for every ONLINE LCPU Address, to match
the RMF CPC screen data.
Thanks to MP Welch, Bank of America, USA.
Change 35.004 MXG 34.34. Debugging PROC CONTENTS statements were left
UTILEXCL that caused DATASET PDB.CICSDICT NOT FOUND errors, if the
Jan 10, 2017 //PDB DD had DISP=NEW, Lines 891, 892, and 898 need to be
deleted, but that only exposed a second error causing the
same error message; the PROC APPEND had transposed the _W
and _L tokens - Base must be _L and NEW must be _W.
Thanks to Tom MacCabe, Dominion Resources Services, Inc., USA.
Change 35.003 Cosmetic. Variables ADSRXXXX, ADSRYYYY, ADSR5ST are now
VMACEREP converted to EBCDIC..
Jan 6, 2017
Change 35.002 Another INVALID SMF RECORD Informatica POWER EXCHANGE
VMACPOEX caused STOPOVER ABEND because POEXLEN=52 but there are
Jan 6, 2017 are only 32 bytes left in the record; its missing the
last five counters for the Client POEXCLIE dataset.
Datetime variables POEXSTRX/POEXENDX are now kept.
Thanks to Scott Wiig, USBank, USA.
Change 35.001 The year end interval with STARTTIME=31DEC2016:23:55:00
VMACNMON incorrectly had ENDTIME=01JAN2016:00:00 because MXG used
Jan 4, 2017 the AAA record's DATECH value to get the year, but that
was the date of the start of the monitor. Now, the DATE
in the ZZZZ record is used.
Thanks to Florent Boulesteix, INOVANS partenaire CAAGIS, FRANCE.
LASTCHANGE: Version 35.
=========================member=CHANGE34================================
/* COPYRIGHT (C) 1984-2016 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 34.34 is dated Jan 3, 2017, thru Change 34.284
MXG Newsletter SIXTY-EIGHT is dated Jan 3, 2017.
MXG Version 34.10 was dated Dec 25, 2016, thru Change 34.280
MXG Version 34.09 was dated Dec 16, 2016, thru Change 34.279
MXG Version 34.08 was dated Nov 25, 2016, thru Change 34.269
MXG Version 34.07 was dated Oct 7, 2016, thru Change 34.232
MXG Newsletter SIXTY-SEVEN was dated Oct 7, 2016.
First MXG Version 34.07 was dated Oct 5, 2016, thru Change 34.230
MXG Version 34.06 was dated Aug 18, 2016, thru Change 34.198
MXG Version 34.05 was dated Jul 25, 2016, thru Change 34.173
MXG Version 34.04 was dated Jun 23, 2016, thru Change 34.144
MXG Version 34.03 was dated May 10, 2016, thru Change 34.114
MXG Version 34.02 was dated Apr 5, 2016, thru Change 34.083
Final MXG Version 34.01 was dated Mar 21, 2016, thru Change 34.062
Third MXG Version 34.01 was dated Mar 14, 2016, thru Change 34.058
Second MXG Version 34.01 was dated Mar 14, 2016, thru Change 34.057
First MXG Version 34.01 was dated Mar 7, 2016, thru Change 34.048
ANNUAL: MXG Version 33.33 was dated Jan 18, 2016, thru Change 33.327
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 34.34 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 34.34.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG Version 34.34 dated Jan 3, 2016, thru Change 34.284
This is the MXG "ANNUAL VERSION" for 2017.
Major CHANGES added in MXG 34.34, dated Jan 3, 2016 thru 34.284.
TYPEIDML 34.282 Support for IDMS Log (INCOMPAT, third record).
TYPEDB2 34.281 DB2 IDAA variable Q8STDSKU format/label corrected.
Major CHANGES added in MXG 34.10, dated Dec 25, 2016 thru 34.280.
TYPEVMXA 34.280 z/VM Linux Appl VXAPLSLM/N/P/0 deaccum corrected.
TYPEVMXA 34.280 z/VM VXBYUSR had some obs with negative values.
Major CHANGES added in MXG 34.09, dated Dec 16, 2016 thru 34.278.
CRITICAL CHANGE:
TYPE110 34.274 Support for CICS/TS 5.4 BETA 6 (INCOMPAT CICSTRAN).
ENHANCEMENTS
TYPETMD2 34.275 Support for ASG/TMON for DB2 IDAA SA and SB records.
TYPE115 34.272 Support for MQ SMF 115 Subtype 231 DSP/ADP/SSL/DNS
ANALDCO1 34.271 New ANALDCO1 provides simple DCOLLECT reports.
ASMRMFV 34.273 Internal Performance improvement for RMF III support
Major CHANGES added in MXG 34.08, dated Nov 25, 2016 thru 34.269.
CRITICAL CHANGE:
TYPE7072 34.239 SMT Corrections to TYPE70PR "OTHER SYSTEM" LPARs.
TYPETPX 34.269 Support for INCOMPATIBLE TPX PTF R085512/R085513.
ChangeS:
TYPEDB2 34.248 DB2 Netezza IDAA Q8STxxxx in new DB2NETZA dataset.
ANAL9914 34.255 z13 Topology Report typo corrected.
CICINTRV 34.254 CICS Dispatcher DSGSRBT SRB Time Kept in CICINTRV.
VMXGALOC 34.253 UPCASE removed for BASExxx path for Linux casing.
TYPE119 34.252 TYP11950 dataset only contained first KEY.
TYPEVMXA 34.249 z/VM Linux Appldata VXAPLSLM/SLN/SLP corrections.
TYPE42 34.245 SMF 42 TYPE42L1 dataset misaligned at SMF42HUA.
ANALDB2R 34.265 ANALDB2R 33.33-34.07 could require temp //PDB DD.
ENHANCEMENTS
TYPE110 34.260 Support for SMF 110 Subtype 2 STID=32 creates CICLDY.
TYPETMO2 34.257 Support for TMON/CICS Version 4.1 (COMPATIBLE)
TYPE80A 34.251 Support for TOP SECRET RDT Table decoding.
TYPERACF 34.247 Support for RACF APAR OA43999 RACF UNLOAD database.
TYPE117 34.243 Support for SMF 117 Version 2 (INCOMPATIBLE) format.
TYPEZCOS 34.241 Support for AutoSoftCapping Version V4 (COMPATIBLE).
TYPETHAL 34.261 Support for Thales Security Records with/wo subtype
IMACCADI 34.263 Support for CAA/DISPATCH type 6 change (INCOMPAT)
ASMRMFV 34.262 ASMRMFV enhancement for Parameters.
VGETJESN 34.240 Hex zeros in JCTJOBID in SMF 42 ST 27 protected.
ANAL3CPC 34.238 Example RMF III CPC data report.
TYPESTC 34.237 New variables added to STCVSM11 dataset.
Major CHANGES added in MXG 34.07, dated Oct 7, 2016 thru 34.232.
CRITICAL CHANGE:
TYPE7072 34.232 First 34.07. CRITICAL ARRAY EXCEEDED ERROR fixed.
DO NOT USE Oct 5 34.07 for TYPE 70 processing.
Major CHANGES added in MXG 34.07, dated Oct 5, 2016 thru 34.229.
ENHANCEMENTS
TYPEDB2 34.229 Support for DB2 V12. (COMPATIBLE).
TYPE70 34.228 Support for APAR OA48688, ABSOLUTE MSU LPAR CAP.
TYPE1415 34.224 Support for APAR OA50256 for TYPE1415/SMF14DSVER.
TYPE74 34.223 Support for APAR OA49415 for SuperPAV support.
TYPE78 34.223 Support for APAR OA49415 for SuperPAV support.
TYPE42 34.222 Support for APAR OA51097 for subtype 19 fields.
TYPE6156 34.219 Support for SMF Type 65 GDGCOMPL/GDCNOEXT/GDGLIMIT
TYPE98 34.216 Support for SMF 98 High Freq Thruput Stats record.
TYPEPROS 34.215 Support for PRO/SMF (previously X37) Version 7.8.
TYPE30 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE42 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE74 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE79 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE90A 34.214 Support for new subtypes 38 and 39 in SMF 90.
TYPE119 34.213 Support for SMF 119 Subtype 81 Intrusion Detection.
TYPE80A 34.206 Support for Top Secret Release R15 &R16 (INCOMPAT).
TYPECDHW 34.202 Support for Connect Direct Simultaneous Session CDHW
DB2COUNT 34.209 "DB2 is filling my SMF, how do I find out who/why?"
RMFINTRV 34.207 VMXGRMFI with INTERVAL=DATE s/b INTERVAL=DATESHIFT.
TYPE110 34.203 READTIME in all "CICS EXCLUDED" messages for DICT.
TYPE115 34.200 MQMLOG enhanced with new variables, protection added.
CORRECTIONS
TYPE29 34.221 Support for new SMF Type 29 IMS JAVA/GC validated.
TYPEBVIR 34.217 BVIR301 and BVIR302 datasets were wrong, too few obs.
ASUM4HRS 34.218 Four Hour Average analysis was incorrect initialized.
Major CHANGES added in MXG 34.06, dated Aug 18, 2016 thru 34.198.
CRITICAL ERROR CORRECTED:
TYPE78 34.196 SMF 78 ST 3 INPUT EXCEEDED if APAR O44525 installed.
MXG 33.07-MXG 34.05. Circumvention in Change text.
ENHANCEMENTS:
TYPE99 34.194 Support for SMF 99 Subtype 1 Hardware Absolute CAP.
TYPE124 34.187 Support for SMF 124 I/O Supervisor IOS (z/OS 2.2).
TYPEMVIP 34.186 Support for Mainview for IP RTIN 34x TAC9I220 dataset
TYPE110 34.183 Partial Support for CICS/TS 5.4 OPEN BETA.
TYPE80A 34.178 Support for RACF 80 TOKDANAM new values.
ASMRMFV 34.191 Enhanced RMF III data filtering reduces data volume.
ASMRMFV 34.198 RMF III Relative Time filtering, e.g, last hour.
TYPERMFV 34.192 RMF III variable GMTOFF kept in all ZRB datasets.
TYPETMO2 34.195 TMON/CICS new vars TASZIPTM/TASELGTM recalc TASCPUTM.
ERRORS CORRECTED:
TYPEHSM 34.193 Invalid HSM VSR/DSR with '62'x vs 'S' protected.
TYPE119 34.189 MXG 34.05 ONLY, INPUT EXCEEDED more than 3 Homeaddr.
TYPE74 34.181 Defective BMC CMF type 74 subtype 4 SMF74ML=0 bypass.
TYPEATF 34.180 Omegamon XE ATF times are now on local time zone.
TYPE80A 34.176 RACFTYPE=6 RACFEVNT=19 skipped segment message.
TYPEVMXA 34.175 zVM 6.3.16.1 inserted in PRCPUP, PROBABL DATA LOSS.
Major CHANGES added in MXG 34.05, dated Jul 25, 2016 thru 34.173.
ENHANCEMENTS:
TYPE120 34.170 Support for WebSphere Liberty Batch SMF 120 Subty 12.
TYPE120 34.163 Support for WAS Liberty V16.0 SMF 120 Subtype 11.
TYPE120 34.148 Support for ODM Version 8.8 SMF 120 subtype 100.
TYPE119 34.168 Support for SMF 116 Subtype 6 Home IP Address segment
TYPE87 34.166 Support for SMF Type 87 Subtype 2 ENQ/DEQ records.
TYPE117 34.157 Support for SMF 117 Integration BUS V10 INCOMPATIBLE.
TYPEIDMS 34.164 Support for IDMS Version 19 (INCOMPAT with R084146).
BUILDPDB 34.162 Support for z/OS 2.2 JES2 8-char JOBCLAS8 in BUILDPDB
BLDSMPDB 34.153 Change 33.031 missed two instanced of LOWCASE().
ERRORS CORRECTED:
TYPEVMXA 34.169 zVM HIS macros for PRCMFC PRCMFM now work correctly.
CHECKSTN 34.167 Detection/Protection of duplicate SMF70STN values.
VMXGALOC 34.160 Revised for Linux, case sensitive directory names.
TYPERMFV 34.156 INVALID DATA for ASIQSCANxxx, incorrect informat.
ASMRMFV 34.152 The RMF III DOW filter was not working.
VMXGSUM 34.151 SYSLAST is now correctly set to last output dataset.
BUILDPDB 34.147 Large SPIN.SPIN6 due to PRINTWAY records cleared.
Major CHANGES added in MXG 34.04, dated Jun 25, 2016:
ENHANCEMENTS:
VMXGSUM 34.137 New MXGSUMCLASS option can save CPU time, TEST IT!!
ASMRMFV 34.133 RMF III GMT offset feature for multiple time zones
selects data for the data center hardware time zone.
This is a new feature, so please test first.
TYPE102 34.123 Support for DB2 IFCID 365 and 376 corrections.
ANALCSQX 34.122 Concurrent MQ Apps logged on from SYSLOG CSQX msgs
TYPESYSL 34.121 Formal support of SYSLOG with all normal MXG tokens.
TYPE30 34.118 MXG created variable CPUZIPTM_CPUIFATM_INST wrong.
TYPEEDGR 34.116 RMM datasets enhanced with SYSTEM and EDGRTIME.
TYPEDCOL 34.115 DCDTIMEC Data Set Create Time not populated note.
ERRORS CORRECTED:
BLDSMPDB 34.131 ERROR: Invalid date constant " .":d, FORCEDAY= fix
ANALRANK 34.127 NOT SORTED if only one variable was examined
VMXGCNFG 34.119 CPU Loop after program ended, if //SOURCLIB DD.
Major CHANGES added in MXG 34.03, dated May 10, 2016:
ERRORS CORRECTED:
TYPEDB2 34.108 DB2 Sim Buff Pool DB2STSBP QBSP variables corrected.
ASUMCELP 34.106 z13 SMT_MODE SMT_NUM=2, NRZIPCPU finally correct.
TYPERMFV 34.100 ZRBASI ASILPGSZ, ZRBGEI many GEIxxxxx corrected.
TYPEVMXA 34.099 zVM 6.3 circumvent, 5.20 HWCLEN=384, new PRCAPMCT=11.
VMACRMFV 34.092 MXG 34.01-34.02. ZRBCPU variables CPCGRPxx wrong.
TYPEIMS 34.087 MXG 34.02, IMS 12.1, IMS 07 misalign, DLRAZAAP fixed.
MOBWRKI2 34.084 ERROR: FILE WORK.SUMSTSBP.DATA DOES NOT EXIST fixed.
ASMRMFV 34.095 Some ASMRMFV log dates off by one day, output fine.
ENHANCEMENTS:
TYPE72PD 34.111 New TYPE72PD RMF WLM POLICY DEFINITIONS dataset.
TYPE123A 34.105 Support for SMF 123 Liberty z/OS Connect EE Audit.
TYPE117 34.103 Support for IBM Integ Bus V 90005 SMF 117 INCOMPAT
READDB2 34.102 Support for IFCID=58's second dataset T102SA58.
IHDRRMFV 34.092 Support for IHDRRMFV "Header" Exit selection member.
TYPE80A 34.086 Support for TYPE8069 R_PKISERV GENCERT event SMF 80.
TYPEVMXA 34.085 Support for z/VM VXSYTEMP third section, plus more.
TYPEIMS 34.091 Support for IMS Log 16x Sign On/Sign Off log record.
TYPESAMS 34.089 Support for SAMS VANTAGE User LSPOOLPO INCOMPAT.
ANALUOW 34.110 Parameter INCODE= added for tailoring/selection.
ANAL9914 34.107 SMT Topology Report typo, reports all systems.
GRAFWRKC 34.101 Improved CPU and MSU and Group Capacity SGPLOTs.
Major CHANGES added in MXG 34.02, dated Apr 5, 2016:
ERRORS CORRECTED:
MOBSRK05 34.075 MOBILWORK SCRT/MWRT FATAL ERROR IF CLOCK CHANGE OCCURS.
YOU NEED THE UPDATED MOBWRK05 or MXG 34.02 and must run
between April 2 and 9th for the March report.
TYPEIMST 34.083 IMS56FA, ARRVTIME wrong if GMT offset NE ENDTIME GMT.
TYPE110 34.065 CICS/TS 5.3, MNSEGCL=5 TSQUEUE INPUT EXCEEDED ERROR.
TYPE7072 34.072 R723DNST NOT EQUAL TO R723RTYP message eliminated.
TYPE85 34.067 z/OS 2.2 OAM SMF 85 INPUT STATEMENT EXCEEDED fixed.
RMFINTRV 34.078 RMFINTRV 33.33 and 34.01 had errors in MSU72/MSUSOFT/
TYPESTC 34.081 Oracle/STC User SMF record GMTOFFTM "slightly" wrong.
ENHANCEMENTS:
TYPEVMXA 34.080 Support for z/VM SMT MODE, caused BROKEN REC ERROR.
TYPE102 34.072A Support for SMF 102 IFCID 58 Added segment.
TYPE73 34.068 Support for SPLIT RMF 73 records, optional _STY73EX
TYPEBBMQ 34.064 Circumvention BBMQ Short E6 records, datetimes fixed.
TYPE0203 34.074 SMF2IHASHMETH/SMF2ISIGTYPE were blank, bad bit test.
TYPE74 34.073 Dataset TYPE749 (PCIE) is enhanced with new vars.
TYPEVMXA 34.066 z/VM VXBYUSR enhanced, option forces USER 8709 ABEND.
TYPE42 34.070 I/O Connect Time S42CONNTM is calculated.
Major CHANGES added in FOURTH MXG 34.01, dated Mar 21, 2016:
TYPE7072 34.060 ITRM. VMXG70PR. "&PDB" must be "&PDBMXG" twice.
Major CHANGES added in THIRD MXG 34.01, dated Mar 14, 2016:
Critical ERROR that caused the re-date:
VMXGINIT 34.052 WPS ONLY, 1st 34.01, RUN: in VMXGINIT FAILS INIT.
Circumvent by deleting that line with the colon.
New Products Support
TYPE120 34.055 Proper Support of 120 ST 9 TYP1209R/TYP1209N datasets
ST 9 is either a REQUEST or ASYNC Event, only those
two datasets are valid, with separate variable sets.
TYPE102 34.053 BMC APPTUNE defective FIX BPU3604, INPUT EXCEEDED.
Errors Corrected:
TYPE60 34.056 TYPE 60 variable SMF60ELP misaligned.
TYPE42 34.054 Variable SMF42LAN was not converted to EBCDIC.
TYPETMO2 34.049 TMON V4.0 microsec/tod change missed 15 variables.
(None were in the important MONITASK dataset.)
Major CHANGES added in MXG 34.01, dated Mar 7, 2016:
New Products Support
TYPERMFV 34.047 Support for z/OS 2.2 RMF III data records (COMPAT).
TYPE102 34.032 Support for DB2 Trace IFCIDS 311 and 321.
TYPE29 34.221 Support for SMF 29 IMS JAVA CPU and Garbage Collect
TYPEATF 34.041 Support for ATF V531 Enhanced Summarization Phase 2.
TYPEBBMQ 34.026 Support for MVMQ PTF BPL2558, times are microseconds.
TYPENDM 34.017 Support for NDM-CDI SE Session End record.
TYPEPKSZ 34.020 Support for PK-ZIP INCOMPATIBLE increase field length
TYPEVMXA 34.005 Support for zVM HIS (SMF 113) VXPRCMFC z/13 data.
TYPEDVS 34.014 Support for Rocket Software DVS User SMF record.
TYPEDCOL 34.042 Support for FLAG4 MegaByte format size variables.
Errors Corrected:
ITRM 34.011 Possible MXG 33.33 issues with ITRM documented.
TYPE113 34.027 TYPE113 CPU Speed SM1132SP wrong on Sub-Capacity z13.
TYPECIMS 34.007 Correction for IMF 5100 incorrect values, no ABEND.
TYPESTC 34.019 Corrections/enhancements for Oracle STC SMF record.
UTILRMFI 34.006 UTILRMFI report was dropped accidentally in 33.024
VGETOBS 34.001 OPTION CHARCODE caused ERROR: CHAR OPERAND.
PDBAUDIT 34.003 FILE _TMPLIB.XTY70CP.DATA does not exist.
TYPE71 34.043 New variables SMF71CPx,SMF714Kx,SMF71PLx were wrong.
Enhancements
ANALGRCA 34.015 New analysis of Group Capacity
GRAFWRKC 34.044 New Capacity Group report of CEC resources by LPAR.
RMFINTRV 34.029 Capacity Group variables SMF70GNM/GMU added
TYPEHSM 34.002 New datetime and duration variables in HSMFSRST.
TYPE116 34.008 New Variables added to MQMACCTQ
TYPE7072 34.010 TYPE72GO MSUxxxxx variables labeled/documented.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M3 (9.4M3) printed
as "SAS 9.4 (TS1M3)" or was "SAS 9.4 (TS04.01M2P07232014)" for
"SAS 9.4 (TS1M2)" (on SASLOG, if OPTION VERSIONLONG enabled),
for SAS 9.4 Maintenance Level M3 and m2.
SAS V9.4 M3 Is RECOMMENDED, but MXG executes without error using
SAS Version 9.4 M0, M1, M2, and M3 or SAS Version 9.2 M1 and M2.
SAS V9.4 M2 is USABLE. SAS 9.4 M2 is at LEVEL A SAS Support
SAS V9.4 M1 and M0 had no errors and are at LEVEL A SAS Support
SAS V9.3 SAS 9.3 TS1M2 is USABLE. SAS 9.3 TS1M1 works.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03. SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit, but SAS V9.2 does execute ok.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 must be at Service Pack 4. Additionally, on z/OS 1.10
only, 9.1.3 requires SAS Hot Fix for SN-35332.
9.1.3 is support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 IS SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS94 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 34.07 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows Seven and
Eight (64-bit) on 64-bit hardware, and sometimes on Centos 6.4,
but MXG users execute MXG on MANY (ALL??) SAS platforms, including
AIX, Linux, and other 'nix' variants, on many different hardware
platforms, and since they all work we don't need to list them. If
SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 3.02 (03.02.03.00.016221) is required Change 34.266.
and other errors with 3.00 or 3.01 have been corrected in the
current WPS version.
WPS Version 3.01.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
However, for the z13 processor on z/OS, the new SMT-MODE RMF 70 was
INCOMPATIBLY CHANGED, and MXG 34.03 is REQUIRED (PCTCPUBY WRONG!), to
read the SMT-format RMF records (which are written if you have zIIP
engines AND have enabled the new PROCVIEW CORE option for
Multi-Threading, even if only one thread is enabled).
The new zEDC compression hardware requires MXG 33.07 to support the
new metrics.
For z/VM, MXG REQUIRES MXG 33.02 to support the z/13 changes.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.1 - INPUT STATEMENT EXCEEDED ERROR SMF 74 33.10
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z/OS 2.2 OAM SMF 85 ABEND 33.067 Apr 5, 2016 34.02
z/OS 2.2 SPLIT 73, ABEND 33.068 Apr 5, 2016 34.02
z/OS 2.2 JES2 8-char JOBCLASS Oct 7, 2016 34.07
z/OS 2.2 NEW SMF 124 IOS Spvr Oct 7, 2016 34.07
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
z13 SMT Mode NRZIPCPU 34.106 May 10, 2016 34.03
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS-TS/5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS-TS/5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS-TS/5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS-TS/5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS-TS/5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS-TS/5.3 GA date Dec 11, 2015 33.33
CICS-TS/5.3 MNSEGCL=5 INPUT ERR Mar 21, 2016 34.02
CICS-TS/5.4 OPEN BETA Aug Aug 11, 2016 34.06
CICS-TS/5.4 OPEN BETA Nov Nov 11, 2016 34.09
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
DB2 12.1 COMPATIBLE Oct 5, 2016 34.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
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
z/VM 6.3 z/13 Jan 23, 2016 33.33
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.13
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
IDMS 18 32.05
IDMS 19 (INCOMPAT after PTF R084146 Change 34.164) 33.05
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS *34.01
IMF 5.2 a/k/a Mainview IMS 34.01
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for IP 34.??
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 34.34.
1. Incompatibilities introduced in MXG 34.34:
a- Changes in MXG architecture made between 34.34 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
COSMETIC Some Changes will start with COSMETIC. This indicates
that that change only alters a displayed value or may
be a spelling error in a label, but it is "cosmetic"
in that it ONLY affected the display, and the output
data sets created are NOT impacted by this change.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 34.34 after MXG 33.33:
Dataset/
Member Change Description
ANAL3CPC 34.238 Example RMF III CPC data report.
ANAL9914 34.107 SMT Topology Report typo, reports all systems.
ANAL9914 34.255 z13 Topology Report typo corrected.
ANALCSQX 34.122 Concurrent MQ Apps logged on from SYSLOG CSQX msgs
ANALDB2R 34.265 ANALDB2R 33.33-34.07 could require temp //PDB DD.
ANALDCO1 34.271 New ANALDCO1 provides simple DCOLLECT reports.
ANALGRCA 34.015 New analysis of Group Capacity
ANALRANK 34.127 NOT SORTED if only one variable was examined
ANALUOW 34.110 Parameter INCODE= added for tailoring/selection.
ASMRMFV 34.095 Some ASMRMFV log dates off by one day, output fine.
ASMRMFV 34.133 RMF III GMT offset collects multiple time zones data.
ASMRMFV 34.152 The RMF III DOW filter was not working.
ASMRMFV 34.191 Enhanced RMF III data filtering reduces data volume.
ASMRMFV 34.262 ASMRMFV enhancement for Parameters.
ASMRMFV 34.273 Internal Performance improvement for RMF III support
ASUM4HRS 34.218 Four Hour Average analysis was incorrect initialized.
ASUMCELP 34.106 z13 SMT_MODE SMT_NUM=2, NRZIPCPU finally correct.
BLDSMPDB 34.131 ERROR: Invalid date constant " .":d, FORCEDAY= fix
BLDSMPDB 34.153 Change 33.031 missed two instanced of LOWCASE().
BUILDPDB 34.147 Large SPIN.SPIN6 due to PRINTWAY records cleared.
BUILDPDB 34.162 Support for z/OS 2.2 JES2 8-char JOBCLAS8 in BUILDPDB
CHECKSTN 34.167 Detection/Protection of duplicate SMF70STN values.
CICINTRV 34.254 CICS Dispatcher DSGSRBT SRB Time Kept in CICINTRV.
DB2COUNT 34.209 "DB2 is filling my SMF, how do I find out who/why?"
GRAFWRKC 34.044 New Capacity Group report of CEC resources by LPAR.
GRAFWRKC 34.101 Improved CPU and MSU and Group Capacity SGPLOTs.
IHDRRMFV 34.092 Support for IHDRRMFV "Header" Exit selection member.
IMACCADI 34.263 Support for CAA/DISPATCH type 6 change (INCOMPAT)
ITRM 34.011 Possible MXG 33.33 issues with ITRM documented.
JCLTESxx 34.259 Some JCLTESxx members still included gone TYPEQAPM.
MOBWRK05 34.075 SCRT/MWRT REPORT WILL ABEND IF CLOCK CHANGE INCLUDED
MOBWRKI2 34.084 ERROR: FILE WORK.SUMSTSBP.DATA DOES NOT EXIST fixed.
PDBAUDIT 34.003 FILE _TMPLIB.XTY70CP.DATA does not exist.
READDB2 34.102 Support for IFCID=58's second dataset T102SA58.
RMFINTRV 34.029 Capacity Group variables SMF70GNM/GMU added
RMFINTRV 34.078 33.33 and 34.01 had errors in MSU72/MSUSOFT/etc.
RMFINTRV 34.207 VMXGRMFI with INTERVAL=DATE s/b INTERVAL=DATESHIFT.
TYPE0203 34.074 SMF2IHASHMETH/SMF2ISIGTYPE were blank, bad bit test.
TYPE102 34.032 Support for DB2 Trace IFCIDS 311 and 321.
TYPE102 34.053 BMC APPTUNE defective FIX BPU3604, INPUT EXCEEDED.
TYPE102 34.072A Support for SMF 102 IFCID 58 Added segment.
TYPE102 34.123 Support for DB2 IFCID 365 and 376 corrections.
TYPE110 34.065 CICS/TS 5.3, MNSEGCL=5 TSQUEUE INPUT EXCEEDED ERROR.
TYPE110 34.183 Partial Support for CICS/TS 5.4 OPEN BETA.
TYPE110 34.203 READTIME in all "CICS EXCLUDED" messages for DICT.
TYPE110 34.260 Support for SMF 110 Subtype 2 STID=32 creates CICLDY.
TYPE110 34.274 Support for CICS/TS 5.4 BETA 6 (INCOMPAT CICSTRAN).
TYPE113 34.027 TYPE113 CPU Speed SM1132SP wrong on Sub-Capacity z13.
TYPE115 34.200 MQMLOG enhanced with new variables, protection added.
TYPE115 34.272 Support for MQ SMF 115 Subtype 231 DSP/ADP/SSL/DNS
TYPE116 34.008 New Variables added to MQMACCTQ
TYPE117 34.103 Support for IBM Integ Bus V 90005 SMF 117 INCOMPAT
TYPE117 34.157 Support for SMF 117 Integration BUS V10 INCOMPATIBLE.
TYPE117 34.243 Support for SMF 117 Version 2 (INCOMPATIBLE) format.
TYPE119 34.168 Support for SMF 116 Subtype 6 Home IP Address segment
TYPE119 34.189 MXG 34.05 ONLY, INPUT EXCEEDED more than 3 Homeaddr.
TYPE119 34.213 Support for SMF 119 Subtype 81 Intrusion Detection.
TYPE119 34.252 TYP11950 dataset only contained first KEY.
TYPE120 34.055 Proper Support of 120 ST 9 TYP1209R/TYP1209N datasets
TYPE120 34.148 Support for ODM Version 8.8 SMF 120 subtype 100.
TYPE120 34.163 Support for WAS Liberty V16.0 SMF 120 Subtype 11.
TYPE120 34.170 Support for WebSphere Liberty Batch SMF 120 Subty 12.
TYPE123A 34.105 Support for SMF 123 Liberty z/OS Connect EE Audit.
TYPE124 34.187 Support for SMF 124 I/O Supervisor IOS (z/OS 2.2).
TYPE1415 34.224 Support for APAR OA50256 for TYPE1415/SMF14DSVER.
TYPE29 34.221 Support for SMF 29 IMS Java CPU and Garbage Collect
TYPE29 34.221 Support for new SMF Type 29 IMS JAVA/GC validated.
TYPE30 34.118 MXG created variable CPUZIPTM_CPUIFATM_INST wrong.
TYPE30 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE42 34.054 Variable SMF42LAN was not converted to EBCDIC.
TYPE42 34.070 I/O Connect Time S42CONNTM is calculated.
TYPE42 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE42 34.222 Support for APAR OA51097 for subtype 19 fields.
TYPE42 34.245 SMF 42 TYPE42L1 dataset misaligned at SMF42HUA.
TYPE60 34.056 TYPE 60 variable SMF60ELP misaligned.
TYPE6156 34.219 Support for SMF Type 65 GDGCOMPL/GDCNOEXT/GDGLIMIT
TYPE70 34.228 Support for APAR OA48688, ABSOLUTE MSU LPAR GROUP CAP
TYPE7072 34.010 TYPE72GO MSUxxxxx variables labeled/documented.
TYPE7072 34.072 R723DNST NOT EQUAL TO R723RTYP message eliminated.
TYPE7072 34.232 First 34.07. CRITICAL ARRAY EXCEEDED ERROR fixed.
TYPE7072 34.239 SMT Corrections to TYPE70PR "OTHER SYSTEM" LPARs.
TYPE71 34.043 New variables SMF71CPx,SMF714Kx,SMF71PLx were wrong.
TYPE72PD 34.111 New TYPE72PD RMF WLM POLICY DEFINITIONS dataset.
TYPE73 34.068 Support for SPLIT RMF 73 records, _S73 required.
TYPE74 34.073 Dataset TYPE749 (PCIE) is enhanced with new vars.
TYPE74 34.181 Defective BMC CMF type 74 subtype 4 SMF74ML=0 bypass.
TYPE74 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE74 34.223 Support for APAR OA49415 for SuperPAV support.
TYPE78 34.223 Support for APAR OA49415 for SuperPAV support.
TYPE79 34.214 Support for new variables in Sep 2016 SMF manual.
TYPE80A 34.086 Support for TYPE8069 R_PKISERV GENCERT event SMF 80.
TYPE80A 34.176 RACFTYPE=6 RACFEVNT=19 skipped segment message.
TYPE80A 34.178 Support for RACF 80 TOKDANAM new values.
TYPE80A 34.206 Support for Top Secret Release R15 & R16 (INCOMPAT).
TYPE80A 34.251 Support for TOP SECRET RDT Table decoding.
TYPE85 34.067 z/OS 2.2 OAM SMF 85 INPUT STATEMENT EXCEEDED fixed.
TYPE87 34.166 Support for SMF Type 87 Subtype 2 ENQ/DEQ records.
TYPE90A 34.214 Support for new subtypes 38 and 39 in SMF 90.
TYPE98 34.216 Support for SMF 98 High Freq Thruput Stats record.
TYPE99 34.194 Support for SMF 99 Subtype 1 Hardware Absolute CAP.
TYPEATF 34.041 Support for ATF V531 Enhanced Summarization Phase 2.
TYPEATF 34.180 Omegamon XE ATF times are now on local time zone.
TYPEBBMQ 34.026 Support for MVMQ PTF BPL2558, times are microseconds.
TYPEBBMQ 34.064 Circumvention BBMQ Short E6 records, datetimes fixed.
TYPEBVIR 34.217 BVIR301 and BVIR302 datasets were wrong, too few obs.
TYPECDHW 34.202 Support for Connect Direct Simultaneous Session CDHW
TYPECIMS 34.007 Correction for IMF 5100 incorrect values, no ABEND.
TYPEDB2 34.108 DB2 Sim Buff Pool DB2STSBP QBSP variables corrected.
TYPEDB2 34.229 Support for DB2 V12. (COMPATIBLE).
TYPEDB2 34.248 DB2 Netezza IDAA Q8STxxxx in new DB2NETZA dataset.
TYPEDB2 34.281 DB2 IDAA variable Q8STDSKU format/label corrected.
TYPEDCOL 34.042 Support for FLAG4 MegaByte format size variables.
TYPEDCOL 34.115 DCDTIMEC Data Set Create Time not populated if.
TYPEDVS 34.014 Support for Rocket Software DVS User SMF record.
TYPEEDGR 34.116 RMM datasets enhanced with SYSTEM and EDGRTIME.
TYPEHSM 34.002 New datetime and duration variables in HSMFSRST.
TYPEHSM 34.193 Invalid HSM VSR/DSR with '62'x vs 'S' protected.
TYPEIDML 34.282 Support for IDMS Log (INCOMPAT, third record).
TYPEIDMS 34.164 Support for IDMS Version 19 (INCOMPAT with R084146).
TYPEIMS 34.087 MXG 34.02, IMS 12.1, IMS 07 misalign, DLRAZAAP fixed.
TYPEIMS 34.091 Support for IMS Log 16x Sign On/Sign Off log record.
TYPEMVIP 34.186 Support for Mainview for IP RTIN 34x TAC9I220 dataset
TYPENDM 34.017 Support for NDM-CDI SE Session End record.
TYPEPKSZ 34.020 Support for PK-ZIP INCOMPATIBLE increase field length
TYPEPROS 34.215 Support for PRO/SMF (previously X37) Version 7.8.
TYPERACF 34.247 Support for RACF APAR OA43999 RACF UNLOAD database.
TYPERMFV 34.092 MXG 34.01-34.02. ZRBCPU variables CPCGRPxx wrong.
TYPERMFV 34.100 ZRBASI ASILPGSZ, ZRBGEI many GEIxxxxx corrected.
TYPERMFV 34.156 INVALID DATA for ASIQSCANxxx, incorrect informat.
TYPERMFV 34.192 RMF III variable GMTOFF kept in all ZRB datasets.
TYPESAMS 34.089 Support for SAMS VANTAGE User LSPOOLPO INCOMPAT.
TYPESTC 34.019 Corrections/enhancements for Oracle STC SMF record.
TYPESTC 34.081 Oracle/STC User SMF record GMTOFFTM "slightly" wrong
TYPESTC 34.237 New variables added to STCVSM11 dataset.
TYPESYSL 34.121 Formal support of SYSLOG with all normal MXG tokens.
TYPETHAL 34.261 Support for Thales Security Records with/wo subtype
TYPETMD2 34.275 Support for ASG/TMON for DB2 IDAA SA and SB records.
TYPETMO2 34.049 TMON V4.0 microsec/tod time change missed 15 vars.
TYPETMO2 34.195 TMON/CICS new vars TASZIPTM/TASELGTM recalc TASCPUTM.
TYPEVMXA 34.005 Support for zVM HIS (SMF 113) VXPRCMFC z/13 data.
TYPEVMXA 34.066 z/VM VXBYUSR enhanced, option to USER 8709 ABEND.
TYPEVMXA 34.080 Support for z/VM SMT MODE, caused BROKEN REC ERROR.
TYPEVMXA 34.085 Support for z/VM VXSYTEMP third section, plus more.
TYPEVMXA 34.099 zVM 6.3 circumvent, 5.20 HWCLEN=384 new PRCAPMCT=11.
TYPEVMXA 34.169 zVM HIS macros for PRCMFC PRCMFM now work correctly.
TYPEVMXA 34.175 zVM 6.3.16.1 inserted in PRCPUP, PROBABL DATA LOSS.
TYPEVMXA 34.249 z/VM Linux Appldata VXAPLSLM/SLN/SLP corrections.
TYPEVMXA 34.280 z/VM Linux Appl VXAPLSLM/N/P/0 deaccum corrected.
TYPEVMXA 34.280 z/VM VXBYUSR had some obs with negative values.
TYPEZCOS 34.241 Support for AutoSoftCapping Version V4 (COMPATIBLE).
UTILRMFI 34.006 UTILRMFI report was dropped accidentally in 33.024
VGETJESN 34.240 Hex zeros in JCTJOBID in SMF 42 ST 27 protected.
VGETOBS 34.001 OPTION CHARCODE caused ERROR: CHAR OPERAND.
VMXGALOC 34.160 Revised for Linux, case sensitive directory names.
VMXGALOC 34.253 UPCASE removed for BASExxx path for Linux casing.
VMXGCNFG 34.119 CPU Loop after program ended, if //SOURCLIB DD.
VMXGINIT 34.052 WPS ONLY, First 34.01, RUN: in VMXGINIT FAILS INIT.
VMXGSUM 34.137 New MXGSUMCLASS option can save CPU time, TEST IT!!
VMXGSUM 34.151 SYSLAST is now correctly set to last output dataset.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at http://www.mxg.com.
Inverse chronological list of all Changes:
NEXTCHANGE
====== Changes thru 34.284 were in this MXG 34.34 dated Jan 3, 2017====
Change 34.284 Primarily used internally by MXG. If it was being used
VMXGOPTR to restore an option to its original setting but had not
Jan 2, 2017 been previously invoked to set the option and the option
required an = (LINESIZE=xxx) it failed lacking the name
of the option and the = so LINESIZE resolved to:
OPTIONS 132;
Change 34.283 -PDBAUDIT failed if the last "PDB" data library happened
PDBAUDIT to be Sequential Format (tape), with the error message:
Dec 31, 2016 WARNING: APPARENT SYMBOLIC REFERENCE LIBCOUNT NOT RES....
Jan 1, 2016 -Could also fail if zero LIBNAMES were selected, with an
error "INVALID OPTION 132".
Thanks to Steve Gear, Integrysgroup, USA.
Change 34.282 Support for IDMS Log records (INCOMPATIBLE, as a third
VMACIDML record per event was added with additional fields).
Dec 29, 2016 Only the IDMLOG02 TASK dataset, has been validated with
Jan 4, 2017 data records, but IDMLOG03 TRANSACTION dataset should be
valid. Unfortunately, there is no GMT offset value in the
log records, so you will need to set the value with
//SYSIN DD *
%LET MACKEEP= MACRO _GMTIDML -4 % ;
for the minus 4 hour GMT offset for US EST.
Thanks to Torstein Netland, CSC, NORWAY.
Change 34.281 IDAA variable Q8STDSKU is disk utilization not bytes, so
VMACDB2 the format and length were removed and the label changed.
Dec 27, 2016 And variables Q8STCCPU_64 Q8STWCPU_64 are also percents.
Jan 13, 2017
Thanks to Tim King, BCBSSC, USA.
Thanks to Terry Johnson, BCBSSC, USA.
====== Changes thru 34.280 were in this MXG 34.10 dated Dec 25, 2016====
Change 34.280 z/VM Linux Appl Datasets VXAPLSLM,SLN,SLP,SL0 deaccum now
VMACVMXA uses new SYNCCNT1=1 OR SYNCCNT2=1 variable's values to
Dec 18, 2016 recognize a reset in accumulated values has occurred. The
Dec 28, 2016 ancient MXG heuristic of a negative time delta to detect
a wrap of the accumulated field (plus first-dot tests)
is insufficient for these four datasets, and caused very
large values or negative values in some variables.
Also, the interval is deleted if SYNCCNT1 NE SYNCCNT2, as
that means the record was updated on the Linux side while
z/VM was still collecting the data, which could then be
inconsistent.
-Dataset VXBYUSR had observations with DELTATM=-9999 that
should not have been output, causing some negative values
in other variables.
Thanks to Graham Harris, RBS, ENGLAND.
Change 34.279 Documentation of ANCIENT z/OS, z/VM APAR OA35675 (2011).
TYPE7072 Support for z/OS under z/VM new RMF VMGUEST option with
Dec 18, 2016 APAR OA35675, populates the Partition Dispatch CPU Time
in two "simplified" Partition Data sections in TYPE 70
RMF records, one with LPARNAME='PHYSICAL' with the z/VM
CPU consumption (IBM RMF Reports LPARNAME *VMSYSTEM*),
and one with LPARNAME='VMSYSTEM' with the z/OS Partition
CPU Dispatch time. Note that SMF70ONT, Online Time is
NOT Populated. From z/VM, this bit on is STILFE.
-MXG Version 29 added variable VMSYSTEM=Y, true for Bit 5
in 2011, but only from the SMF Manual; it was a post by
Martin today that educated me to the actual impact!
Thanks to Martin Packer, IBM, EUROPE!!
====== Changes thru 34.278 were in this MXG 34.09 dated Dec 16, 2016====
Change 34.278 If you specified 0 OBS for 26J2 or 26J3 and did NOT
UTILBLDP specify SPINCNT=something then SPINCNT is set to 0 to
Dec 13, 2016 keep jobs from sitting in SPIN until the SPINCNT is
reached.
Change 34.277 New RMF III ASI fields in z/OS 2.2 suffixed with _LF are
VMACRMFV Long Floating point and with _S are Short Binary informat
Dec 9, 2016 but that was not known and they were incorrectly input.
Some of these fields contain (HATED!) accumulated values,
which have NEVER been in RMF III, and are hated because
the deaccumulation requires two more passes of the data.
But for the important CPU accumulated fields, there is
already an interval variable (e.g., ASICPUTA), so no
deaccumulation was previously necessary. But the higher
microsecond resolution of ASICPUTA_LF, records 20-40%
more CPU time than ASICPUTA, with 1 millisecond.
-However, the several fields that are accumulated are not
always monotonically increasing, so further analysis is
in progress and this text will be revised and MXG will
provide optional deaccumulation if adequate heuristics
can be tested.
Change 34.276 ASCII only, BLDSMPDB would fail to create a weekly and/or
BLDSMPDB monthly PDB if a prior error has set OBS=0, with no clue.
Dec 8, 2016 Now, BLDSMPDB will tell you there were zero observations,
in a WARNING message.
-WTD and MTD processing may have gone to the incorrect
directory - ASCII only and only with AUTOALOC=YES
-New parameter ERASESPIN will delete everything in the
SPIN libname when set to yes - primarily for MXG support
-Checks added to ensure that PDB SPIN TREND WEEK WTD MONTH
and MTD libnames are allocated as needed by the other
parameters used. In the case of WTD/MTD if they are not
found but WEEK/MONTH are a warning is issued and the
libnames that were found are substitute
Change 34.275 Support for ASG/TMON for DB2 IDAA SA and SB records
EXTMD2SA creates three new datasets:
EXTMD2SB DDDDDD DATASET DESCRIPTION
EXTMD2SX TMD2SA TMD2SA IDAA SA Summary
IMACTMD2 TMD2SB TMD2SB IDAA SB Summary
VMACTMD2 TMD2SX TMD2SBD IDAA SB Detail
VMXGINIT
Dec 12 2016
Thanks to Daniel Hamiel, NedBank, SOUTH AFRICA.
Thanks to Mike Lotter, NedBank, SOUTH AFRICA.
Change 34.274 Support for CICS/TS 5.4 Beta 6 INCOMPAT, new CICSTRAN
EXCICMQR fields inserted.
FORMATS -New variables added to CICSTRAN:
IMAC110 ASFREECT='EXEC CICS*FREE CHILD*COUNT'
UTILEXCL ASFTCHCT='EXEC CICS*FETCH*COMMANDS'
VMAC110 ASFTCHCN='ASYNC API*FETCH*WAIT*COUNT'
VMXGINIT ASFTCHTM='ASYNC API*FETCH*WAIT*DURATION'
Dec 15, 2016 ASNATCN='ASYNC API*RUN DELAYEDCOUNT'
ASRMATTM='ASYNC API*RUN DELAYED*DURATION'
ASRUNCT ='EXEC CICS*RUN*TRANSID*COUNT'
ASTOTCT ='ASYNC API*COMMANDS*COUNT'
PTCOUNT ='PREVIOUS*TRANSACTION*COUNT'
PTSTART ='PREVIOUS*TRANSACTION*START*DATETIME'
PTTRAN ='PREVIOUS*TRANSACTION*TRANSID'
PTTRANNO='PREVIOUS*TRANSACTION*sequence*number'
-New CICMQR MQ Monitor statistics dataset from STID=148
is created.
Change 34.273 Internal restructure of ASMRMFV for possible performance
ADOCRMFV improvements and better design for maintenance.
ASMRMFV -Mitigate Store In Instruction Stream (SIIS) conditions
Dec 6, 2016 and other improvements.
-Updating data imbedded in an instruction stream or
modifying instructions results in additional CPU overhead
maintaining the data and instruction caches.
-ASMRMFV is changed to isolate and align all data used in
subroutines on 256 byte cache boundary lines. This
increases the size of the ASMRMFV load module about 7% to
about 272K.
-IBM Service Call macros for OPEN, CLOSE, RDJFCB, and so
on are split into Execute and List forms because standard
macro expansions update parameters in the instruction
stream.
-Limited volume testing showed about a 1% CPU Time
reduction that may vary in actual production use.
-The MODCB Service Call function is no longer used to
alter the VSAM ACB and RPL control blocks. ASMRMFV only
makes trivial changes to these during processing and
Execute and List forms of MODCB generated a lot of
instructions.
-The MODCBERR subroutine used to process MODCB errors
is deleted.
Change 34.272 Support for the MQ SMF 115 Subtype 231 DSP/ADP/SSL/DNS
EXTY115A segments, each of which creates new dataset:
EXTY115D DDDDDD DATASET DESCRIPTION
EXTY115L TY115D MQMDSP MQM DISPATCHER
EXTY115N TY115A MQMADP MQM ADAPTER
IMAC115 TY115L MQMSSL MQM SSL
VMAC115 TY115N MQMDNS MQM DNS
VMXGINIT Their unique variables that were previously incorrectly
Dec 2, 2016 kept in dataset MQMCHIN have been dropped.
-Each segment contains QCTCPTM and QCTELPT, CPU & Elapsed
time; many observations have CPU Time slightly larger
than Elapsed time (largest 15 with QCTCPTM 364 seconds).
IBM Explains:
CPU start and end times are taken directly from the
TCB to minimize performance impact. This field is only
updated when the TCB is undispatched, so if the TCB
has been dispatched for a while when the TCB CPU time
is taken at the start of the request, this value
could be a bit low, which could mean that the TCB CPU
interval calculation returns a value which is slightly
high. This is as-designed, and the data is still
useful. When elapsed time and CPU time are similar,
or when CPU time appears greater than elapsed time,
the task is getting all the CPU it needs, and you can
interpret elapsed time as an approximation for CPU
time. When elapsed time is significantly larger than
CPU time, then the task is having to wait for CPU or
for some internal wait, and that difference may be of
interest.
-APAR PI46585 is required to correct negative or invalid
values in QCTWTTM, QCTLSTM, and QCXTLGTM in these new
ADP/DSP/SSL/DNP datasets.
-The subtype 215 record replaced the subtype 2 record when
OPMODE(NEWFUNC) is specified; the buffer manager data
that was output in dataset MQMBUFER is now instead output
in dataset TY115215.
Thanks to Carol Arnold, Brown Brothers Harriman, USA.
Thanks to Kevin Colish, Brown Brothers Harriman, USA
Thanks to Richard Harran, IBM MQ Support, ENGLAND.
Change 34.271 New ANALDCO1 provides simple DCOLLECT reporting, using
ANALDCO1 the datasets created by JCLDAYDS. See examples in the
Nov 30, 2016 comments.
Change 34.270 -With PDB=RAWDATA and PDBOUT=WORK, a dataset not found was
VMXGDSN created when summarizing data that had been cleaned up
Nov 30,2016 prior to running the code to read tape data.
-Enhanced to allow you to suppress TAPEDATE by using new
TAPEDATA=null string.
====== Changes thru 34.269 were in this MXG 34.08 dated Nov 25, 2016====
Change 34.269 Support for INCOMPATIBLE TPX PTF R085512 and R085513 that
VMACTPX increased Port Number from 4 to 5 digits.
Nov 23, 2016
Thanks to Johanne Goulet, Government of Quebec, CANADA.
Thanks to Christian Roy, Government of Quebec, CANADA.
Change 34.268 Truncated POEX record with only 54 bytes caused STOPOVER.
VMACPOEX Now, the OFFSET just read is compared with LENGTH and the
Nov 22, 2016 first bad record is reported in the log and all deleted.
Thanks to Scott Wiig, USBank, USA.
Change 34.267 Support for RACF OIMID Token creates TOKOIMIC variable
VMAC80A and support for RACF LTL Token creates TOKMLTL variable
Nov 21, 2016 in TYPE80TK dataset.
Thanks to Mark Tomlinson, Lloydsbanking, ENGLAND.
Change 34.266 WPS Only. %MACRO VMXGPRNT invocation with text on col 72
ANAL113 caused error with WPS 3.00 (03.00.02.00.29316 but was
Nov 20, 2016 parsed correctly with WPS 3.02 (03.00.03.00.016221).
The error had ASIC03 for what should have been BASIC03.
Shortening the line did not eliminate the error.
Change 34.265 ANALDB2R could require //PDB DD because updates to READB2
ANALDB2R for DB2SBP and DB2NET had incorrect tokens that should be
READDB2 WORK. MXG code is now corrected, but circumvent with:
Nov 20, 2016 //PDB DD UNIT=SYSDA,SPACE=(CYL,(500,500),DISP=(,PASS)
on temp DASD, since they were not intended to be kept.
Thanks to John Ordman, Wipro, USA.
Change 34.264 -The section of code creating the prior TREND database was
VMXGALOC incorrect and failed to create the directory on the first
Nov 23, 2016 VMXGALOC execution resulting in an error.
-A FORCEDAY test did not have both side's UPCASEd.
Thanks to Job Varkey, VERISK, USA.
Thanks to Patricia J. Jones, DST, USA.
Change 34.263 SMF 6 CA/Dispatch records were increased to LENGTH=371,
IMACCADI adding two new fields CADIDES2 CADICHAR INCOMPATIBLY due
VMAC6 to MXG tests for LENGTH=347 to detect the V10 vs V11 data
Nov 18, 2016 records; those tests for LENGTH and SMF6LEN are unneeded
now and are removed.
Thanks to Glen Bowman, Wakefern, USA.
Change 34.262 -Support for z/OS 2.1+ PARMDD= EXEC statement JCL
ADOCRMFV parameter, enhanced SYSIN DD support, other improvements
ASMRMFV and fixes.
Nov 19, 2016 -PARMDD= is a new JCL parameter available with z/OS 2.1
and up. PARMDD= specifies a ddname of a file containing
parameters to be passed to the invoked program coded with
PGM=.
-If the ddname does not exist within the JCL step a
JCL error occurs with the message:
IEF689I JOB jobname FAILED PARMDD DID NOT OPEN
-The ddname may reference a physical sequential file,
PDS/PDSE member, or subsystem DD * or DD DATA data set.
-Unlike the 100 character PARM= parameter limit the
PARMDD= file may contain up to 32760 characters after
data assembly. If this limit is exceeded a JCL error
occurs.
-During data assembly of the PARMDD=ddname file trailing
blanks are stripped from each record and entirely blank
records are discarded by z/OS.
-Also during data assembly PARMDD=ddname fixed records are
checked for sequence numbers and also stripped if found.
There is no sequence number checking for variable
records.
-Any data stripped from a PARMDD=ddname file does NOT
count towards the 32760 character limit.
-The PARM= and PARMDD= parameters on the JCL EXEC
statement are mutually exclusive. If both are coded,
a JCL error occurs with message:
IEFC009I KEYWORD PARMDD IS MUTUALLY EXCLUSIVE WITH
KEYWORD PARM ON THE EXEC STATEMENT
-The PARMDD= parameter supports any RECFM of F, FB, V, or
VB. RECFM=U and Spanned records are not supported.
-The PARMDD=ddname file may have an LRECL up to 32760 for
fixed length records or 32756 for variable length
records.
-The PARMDD=ddname file may be concatenated with other DDs
in accord with usual concatenation rules.
-These are all valid examples of PARMDD=ddname usage:
//stepname EXEC PGM=ASMRMFV,PARMDD=ddname
//ddname DD DISP=SHR,DSNAME=dsname
//stepname EXEC PGM=ASMRMFV,PARMDD=ddname
//ddname DD DISP=SHR,DSNAME=dsname(member)
//stepname EXEC PGM=ASMRMFV,PARMDD=ddname
//ddname DD *
//stepname EXEC PGM=ASMRMFV,PARMDD=ddname
//ddname DD DATA
-For further details see Section 29 "PARMDD=ddname
Support" in the ASMRMFV source or ADOCRMFV members.
-Similar to PARMDD=ddname usage the ASMRMFV SYSIN DD (or
alternate ddname) now supports RECFM FB, F, VB, or V.
RECFM=U and Spanned records are not supported. Prior to
this change only RECFM=FB or RECFM=F was allowed.
-The ASMRMFV SYSIN DD (or alternate ddname) LRECL may
range up to 32760 for fixed length records or 32756 for
variable length records. Prior to this change only
LRECL=80 was allowed.
-A new built-in alternate ddname for SYSIN named SYSINA
may be provided in JCL and will be used instead of SYSIN
if found. It is not necessary to code the SYSIN=SYSINA
ASMRMFV parameter to use this alternate. However, any
other alternate ddnames require SYSIN= in the PARM= field
or PARMDD=ddname file.
-The order of ddname selection precedence for SYSIN is::
1) The SYSIN=ddname parameter in either the JCL PARM=
field or PARMDD=ddname file if present.
2) The //SYSINA DD in JCL if present.
3) The //SYSIN DD in JCL if present.
-A new built-in alternate ddname for SYSPRINT named
SYSPRINA may be provided in JCL and will be used instead
of SYSPRINT if found. If both SYSPRINA and SYSPRINT are
present SYSPRINT is ignored. There is NO SYSPRINT=ddname
parameter because the ASMRMFV log must be opened well
before any parm processing.
-When processing a PARMDD=ddname or SYSIN (or alternate)
files with data exceeding 100 characters in length, the
data is displayed in the existing RMFV002I message in 100
character sections.
-The first and last RMFV002I sections are always shown,
but any intermediate blank sections are not displayed.
The rightmost column for each section display shows the
number of characters remaining to be shown.
-SYSTSIN and SYSPRINA are added reserved ddnames when
SYSIN=ddname is specified.
-RECFM and LRECL are validated for all SYSIN (or
alternate) data sets.
-After MXG Change 34.226 the SYSIN OPEN subroutine
incorrectly attempts to obtain the DSCB for a //SYSIN DD
DUMMY statement. This results in Abend U0998 Reason Code
0018 and has been corrected.
-MXG Change 34.226 incorrectly altered VSAM TESTCB macro
results test for an VSAM RRDS type data set causing a
VSAM KSDS to be accepted as valid as an RMF III data set.
This caused an I/O error on the first read with Abend
U0998 Reason Code 0029 and has been corrected.
-RMFV008I DATASET LAST OPEN and RMFV009I ORIGIN messages
can be missing from ASMRMFV log for some RMF III data
sets after MXG Change 34.133 and this is also corrected.
-Message RMFV056S is now issued when PATTERR=ABEND instead
of RMFV056E as this is considered a severe error.
-SYSIN=ddname processing now correctly issues message
RMFV004E instead of RMFV056E.
-Incorrect test for '*/' end of imbedded comment string
fixed.
-Expand RMFV005E message to contain first 100 characters
of a bad parameter up from 80 as maximum that will fit
within the 126 character WTO text limit. If the
parameter in error exceeds 100 characters only the first
100 characters are shown.
-Correct SRST search handling for parameter strings
exceeding 256 bytes in length.
-Add short problem description text to RMFV005E message
if displayed parameter length will allow.
-Change '=' character search in keyword parameter
processing in PARMS subroutine to use SRST instruction
for better performance.
-FINAL subroutine setting Return Code 0016 when only
warnings for RED Invalid Processor and SPG Internal
error exist is fixed to issue Return Code 0008.
-RMFV018S SYNAD I/O error message loop can result after a
subsystem DD * data set for SYSIN (or an alternate)
specifies an LRECL other than 80 in JCL. z/OS apparently
continues to call the SYNAD routine for the same error
repeatedly with a WRONG LENGTH RECORD indication. The
problem has been circumvented.
-RMFV007S message was not always showing Reason Code of
blanks when the Reason Code is not available for the
service in error.
-Documentation Section 17 is retitled to "U0998 Abend
Reason Codes".
-Documentation Section 19 "Output LRECL" is retitled as
"Input and Output" LRECL.
-Former documentation Section 29 Summary is now Section
30.
-Former documentation Section 30 Bibliography is now
Section 31.
-New documentation Section Section 29 "PARMDD=ddname
Support" added.
-Updated following documentation sections for alternate
SYSIN/SYSPRINT and PARMDD=ddname support:
Section 3 "Execution JCL"
Section 5 "Input Data Selection Parameters"
Section 6 "Report Control Parameters"
Section 9 "JCL and SYSIN Parameter Usage"
Section 10 "Parameter Syntax Rules"
Section 11 "Parameter Coding Examples"
Section 12 "Messages"
Section 15 "Program and IBM Limitations"
Change 34.261 Support for Thales Security Record Version x.y INCOMPAT.
VMACTHAL This update supports records with and without subtypes.
Nov 17, 2016 For mapping by record ID, you must define these macros
with YOUR SMF record Ids, either in your IMACKEEP member
or in a %LET MACKEEP= argument in your //SYSIN:
%LET MACKEEP=
%QUOTE(
MACRO _IDTHALS 195 % /*SMF ID FOR SUMMARY RECORD*/
MACRO _IDTHALN 196 % /*SMF ID FOR SNAPSHOT RECORD*/
MACRO _IDTHALC 199 % /*SMF ID FOR CDS RECORD*/
MACRO _IDTHALE 198 % /*SMF ID FOR EXCEPTION RECORD*/
MACRO _IDTHALV 197 % /*SMF ID FOR SECURITY RECORD*/
MACRO _IDTHALR 194 % /*SMF ID FOR RESPONSE*/
);
To process records with SUBTYPES, you need these macros
either in IMACKEEP or with %LET MACKEEP= in //SYSIN:
%LET MACKEEP=
%QUOTE(
MACRO _IDTHALX 200 % /*SMF RECORD ID FOR NO SUBTYPES*/
MACRO _SUBTHAL
IF SUBTYPE GT . THEN DO;
IF SUBTYPE=0 THEN ID=_IDTHALC;
ELSE IF SUBTYPE=4 THEN ID=_IDTHALE;
ELSE IF SUBTYPE=8 THEN ID=_IDTHALV;
ELSE IF SUBTYPE=12 THEN ID=_IDTHALS;
ELSE IF SUBTYPE=16 THEN ID=_IDTHALN;
ELSE IF SUBTYPE=32 THEN ID=_IDTHALR;
END;
%
);
Thanks to Randy Schlueter, FirstData, USA.
Change 34.260 Support for SMF 110 Subtype 2 STID=32 creates new dataset
EXCICLDY DDDDDD DATASET DESCRIPTION
FORMATS CICLDY CICLDY CICS LOADER PRIVATE LIBRARY
IMAC110 that is added in CICS/TS 5.4 OPEN BETA.
VMAC110
VMXGINIT
Nov 18, 2016
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 34.259 Three JCL Test examples still had Includes of TYPSQAPM
JCLTEST9 which was replaced by TYPSQACS for the AS/400.
JCLTESS9
JCLTES92
Nov 14, 2016
Thanks to Earl Kline, Luminex, USA.
Change 34.258 Variable SMT_CORE_FLAG='LPARBUSY*VALID?' with value Y/N
VMAC7072 is now kept in TYPE70EN dataset.
Nov 14, 2016
Thanks to Jim S. Horne, Lowe's Companies, Inc., USA.
Change 34.257 Support for TMON/CICS Version 4.1 (COMPATIBLE, no change
EXMONCSE to the existing MXG datasets) and support for the CS CTG
EXMONCSW records create three new datasets:
EXMONCSX DDDDDD DATASET DESCRIPTION
IMACTMO2 TMOCSE MONICSE LANDMARK CS-CSE SEGMENT
VMACTMO2 TMOCSW MONICSW LANDMARK CS-CSW SEGMENT
VMXGINIT TMOCSX MONICSX LANDMARK CS-CSX SEGMENT
Nov 13, 2016
Change 34.256 -DB2STATS variables QISEDPSC QISEDPSF QISEDPSL QISEDPSM
Many QVASBRPT QVASBRP QVASACEB QVASACEF QJSTDPXN QJSTDPXT are
Nov 11, 2016 kept and labeled and QWHCJOBSTEP is labeled.
-TYPE117 variables SM117NOR,SM117RSQ are labeled.
-TYPEIAM variables IAMACFL0-7,IAMACIN0-1,IAMCRIN0-8 and
IAMBOPCR IAMBUFCR IAMCOREO IAMCOREX IAMDDL IAMDSNL and
IAMRLSFP are labeled.
-TYPE42 variables SMF42FSH/FSI/FSJ/FSK correctly labeled.
-TYPE64 variable SMF64UTY extra asterisk removed in label.
-TYPE71 variables SMF71C3A/CPM/CPX extra asterisk removed.
-TYPE73 variables SMF73HEN and EXTENDSEG are now labeled.
-TYPE74 variables R748RAI is labeled in TYPE748R dataset.
-TYPE99 variables S99EE_CP_CHIPID S99EE_CP-BOOKID labeled.
Thanks to Chris Weston, SAS ITRM, USA.
Change 34.255 The z13 Topology Report had a typo Z!3 instead of Z13 and
ANAL9914 variable SYSTEM was added to the second report.
Nov 10, 2016
Thanks to Trevor Holland, ANZ, AUSTRALIA.
Change 34.254 CICS Dispatcher CICDS dataset variable DSGSRBT, SRB time
CICINTRV is now kept in the CICINTRV dataset.
Nov 9, 2016
Thanks to Randy Schlueter, FirstData, USA.
Change 34.253 Change 34.160 removed UPCASE function for BASExxx path
VMXGALOC names, but that segment was inadvertently deleted and is
Nov 9, 2016 restored. Impacted only Linux due to case sensitivity.
Change 34.252 SMF 119 Subtype 50 Dataset NUM11905 is NOT the count of
VMAC119 KEY segments, but is ALWAYS One, causing MXG to output
Nov 8, 2016 the first KEY. (And LEN11905 is the TOTAL length of all
KEY segments plus the 4 bytes for LEN/KEY itself).
The number of KEY segments is NOT provided, but MXG now
uses LENLEFT to find and INPUT and output to TYP11950 for
each KEY.
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Thanks to Ronald Kristel, Rabobank, THE NETHERLANDS.
Change 34.251 SMF 80 Top Secret records, format $MG080TS maps all of
FORMATS RDT table entries for variable TSFLCLAS.
VMAC80A Member VMAC80A has the SAS program in comments to update
Nov 9, 2016 the $MG080TS table.
Nov 15, 2016 Variable TSRESNAME contains the Resource Name.
Dec 6, 2016
Change 34.250 SMF 120 Subtype 100 ODM records had the order of two
VMAC120 variables, SM120RULEXFSUM/SM120RULEXCALLS reversed.
Nov 2, 2016
Thanks to Paul Volpi, UHC, USA.
Change 34.249 z/VM Linux Appldata datasets VXAPLSLM,VXAPLSLN,VXAPLSLP
EOAPLSLM had occasional large values; the logic to de-accumulate
EOAPLSLN was not reset for FIRST.VMDUSER. For these datasets that
EOAPLSLP are written for each interval for each user whether or
VMACVMXA not any resources were consumed, MXG only outputs an obs
Nov 1, 2016 when an interval had activity, and now the DURATM will
contain the actual duration since the last interval that
was output.
Thanks to Graham Harris, RBS, ENGLAND.
Change 34.248 DB2 Netezza IDAA Q8STxxxx variables were incorrectly
CLEARDB2 output in DB2STAT1/DB2STATS, which is a one instance per
EXDB2NET interval dataset, but there can be multiple Q8ST segments
IMACDB2 per interval (only the first segment was output).
READDB2 Now, ALL Q8STxxxx variables in DB2STATS/DB2STAT1 are set
VMACDB2 to a missing value, and the new DB2NETZA is created with
VMXGINIT one observation for each Q8ST segment.
Nov 1, 2016
Thanks to Erling Andersen, SMT, DENMARK.
Change 34.247 Support for APAR OA43999 RACF Database UNLOAD adds these
VMACRACF new variables to RACF0200 dataset:
Oct 28, 2016 USBD_PWD_ALG='ALGORITHM*USED TO*PROTECT*PASSWORD*/.
USBD_LEG_PWDHIST_CT='LEGACY*PASSWORD*HISTORY*ENTRIES*/
USBD_XPW_PWDHIST_CT='KDFAES*PASSWORD*HISTORY*ENTRIES*/
USBD_PHR_ALG='ALGORITHM*USED TO*PROTECT*PASSPHRASE*/.
USBD_LEG_PHRHIST_CT='LEGACY*PASSPHRASE*HISTRY*ENTRIES*/
USBD_XPW_PHRHIST_CT='KDFAES*PASSPHRASE*HISTRY*ENTRIES*/
and these overlooked RACF0200 variables are now created:
PWDENV_EXISTS='PASSWORD*PKCS#7*ENVELOPE*CREATED?'
PWD_ASIS ='EVALUATE*PASSWORD*ENTERED*CASD?'
PHRDATE ='EVALUATE*PASSWORD*ENTERED*CASD?'
PHRGEN ='PASSPHRASE*GENERATION*NUMBER'
CERT_SEQN ='PASSPHRASE*GENERATION*NUMBER'
Dataset RACF0560 missing values messages eliminated .
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 34.246 RMF III dataset ZRBASI variable ASIDP did not exist in
VMACRMFV z/OS 1.13 nor z/OS 2.1, but the MXG test for ASIVERG3
Oct 27, 2016 used GE '16'x, causing ASIDP to contain characters. IBM
didn't document that the ASI record version was changed
to '1A'x (discovered only in 2.2 data records). Now,
ASIDP is missing in 1.13 or 2.1 and populated in 2.2.
Thanks to Randy Hewitt, HPE Enterprise Services
Change 34.245 MXG 33.08-34.07. SMF 42 dataset TYPE42L1 had misaligned
VMAC42 fields starting with SMF42HUA, causing these variables
Oct 27, 2016 to be wrong: SMF42HUA-SMF42HUG, SMF42HCA-SMF42HCX and
and SMF42HEH-SMF42HEK.
Thanks to Ann Knapik, Progressive Insurance, USA.
Thanks to David Buckmiller, Progressive Insurance, USA.
Thanks to William Keezer, Progressive Insurance, USA.
Thanks to Chris Weston, SAS ITRM, USA.
Change 34.244 A large number of regions could cause ARRAY EXCEEDED
UTILEXCL errors and/or invalid DCN/DRL test values in IMACEXCL if
Nov 9, 2016 an existing PDB.CICSDICT was appended with dictionary
Dec 14, 2016 records with the same SMF times. The MAX NREC value is
now created from PDB.CICSDICT and used for the new NREC
to separate those identical records.
-The Nov 9 change increased arrays from 1999 to 2999 but
the correction eliminated the need for the increase, and
on site encountered a record too long to sort with the
Host sort on z/OS; using the SAS Sort circumvented but
the arrays were reset to 1999 on Dec 14.
Thanks to Erling Andersen, SMT, DENMARK.
Change 34.243 Support for SMF 117 IBM Integration Bus Version 2 format
VMAC117 record (INCOMPATIBLE) that inserted two 26-byte datetime
Oct 22, 2016 fields that do NOT match the existing start/end times.
IBM Support is being contacted.
Change 34.242 If you specified multiple datasets in the INDATA= and
VMXGSUM one of those datasets was also the OUTDATA= and there
Oct 22, 2016 was no OUTCODE= specified AND YOU had told VMXGSUM to
use CLASSNWAY rather than a BY, VMXGSUM would fail with
an error message that you could not open the output
dataset because it was part of SASDSVX. Now if VMXGSUM
sees that the INDATA is not the same as the OUTDATA but
the OUTDATA is part of the INDATA and the length of
OUTCODE is 0 it turns off CLASSNWAY.
Change 34.241 Support for AutoSoftCapping Version V4 (COMPATIBLE) adds
VMACZCOS -Dataset ZCOS01 New Variables
Oct 21, 2016 ZCOS01CMAX='CPCMAX'
ZCOS01CMIN='CPCMIN'
-Dataset ZCOS02 New Variables
ZCOS02PMAX='MSUMAX'
ZCOS02PMIN='MSUMIN'
-Dataset ZCOS04CP New Variables
ZCOS04CMAX='CPCMAX'
ZCOS04CMIN='CPCMIN'
-Dataset ZCOS04GP New Variables
ZCOS04MODE='MODE*MESSAGES*ACTIVE*REPORT?'
-Dataset ZCOS04PL New Variables
ZCOS04ACAP='ABSOLUTE*CAP*TO SET'
-These subtype 4 variables are no longer available and are
blank:
ZCOS04CCAP ZCOS04CAIP ZCOS04CPIP ZCOS04PAIP
ZCOS04PORT ZCOS04CFAM ZCOS04CMOD ZCOS04CSID
Change 34.240 New SMF 42 Subtype 27 had JCTJOBID containing HEX zeros
VGETJESN which VGETJESN did not like, printing WARNING TYPETASK
Oct 19, 2016 NOT DECODED. TEST for nulls in JCTJOBID and SUBSYS of
'SMS' protects this subtype and possible future ones.
Thanks to Joe Babcock, General Motors, USA.
Change 34.239 TYPE70PR data for "OTHER SYSTEM" LPARs could have wrong
VMAC7072 LCPUADDR/SMF70CIN values, which could impact the Dispatch
Oct 20, 2016 (CPU) time and other fields in ASUMCELP/ASUMCEC datasets,
if "THIS SYSTEM" is in SMT MODE, but ONLY if there were
NO type 70 records for this "OTHER SYSTEM". Each RMF 70.
record has the details for THIS SYSTEM (70) and for THIS
LPAR (70PR), but only incomplete data in TYPE70PR for
each of the "OTHER LPARs" on the CEC this LPAR reports.
For ASUMCELP/ASUMCEC/TYPE70PR to be perfect, you must
read SMF 70 records for ALL SYSTEMS, so there will be a
"THIS SYSTEM" obs for every LPAR with complete data, and
if you do your own reporting from PDB.TYPE70PR you then
must select the "THIS SYSTEM" obs in TYPE70PR using:
IF PARTISHN=LPARNUM OR LPARNAME='PHYSICAL';
When you don't have 70s for all LPARS, the PDB.ASUMCELP
dataset has only "OTHER SYSTEM" incomplete data, where
these variables always have missing values:
SMF70LAC SMF70PAT SMF70WTS SMF70WTU SMF70WTI SMF70WLA
and where these variables have incorrect values:
LPARCPUS LPARDUR SMF70ONT LPCTBY LPCTOV SMF70WST
PCTZIPBY ZIPCPUS ZIPUPTM ZIPPATTM ZIPWSTTM.
Variable PARTISHN was not kept in PDB.ASUMCELP, but to
select only the "THIS SYSTEM" from PDB.ASUMCELP, use
IF SMF70PAT GT . OR ZIPPATTM GT .;
-Note that in the ASUMCELP dataset, MXG's NRCPUS should be
the number of CP engines ONLINE AND NOT PARKED, the true
capacity available, in the "THIS SYSTEM" LPAR obs. But in
"OTHER SYSTEM" obs, NRCPUS is the number of ONLINE CPs,
because the Parked time is not in the OTHER SYSTEM data.
(In RMF Partition Reports, IBM only reads THIS SYSTEM
so they have to use the ONLINE count, incorrectly,
to calculate the LPAR CPU utilization.)
-ARRAY statements with braces changed to parenthesis to
avoid character translation issues from ASCII to EBCDIC.
Thanks to Peter Sisak, T-SYSTEMS, GERMANY.
Thanks to Gabor Markon, T-SYSTEMS, GERMANY.
Thanks to Lorinc Homor, T-SYSTEMS, GERMANY.
Change 34.238 Example RMF III CPC data report.
ANAL3CPC
Oct 19, 2016
Change 34.237 New variables added to STCVSM11 dataset:
VMACSTC STC11NHW='BYTES*WRITTEN*HOST*INTERFACE'
Oct 12, 2016 STC11NHR='BYTES*WRITTEN*RTD*INTERFACE'
STC11NRR='BYTES*WRITTEN*IP*INTERFACE'
STC11NRW='BYTES*READ*HOST*INTERFACE'
STC11NIR='BYTES*READ*HTD*INTERFACE'
See Change 36.084 which corrected these variables.
Change 34.236 -If you have multiple SYSPLEX values on a single CEC or
VMXG70PR multiple capacity groups then ASUM70LP/ASUMCELP could
Oct 12, 2016 have invalid value unless you read all of the data from
all of the LPARs involved in the CEC. VMXG70PR now will
detect these conditions, WARN you about them and drop
the observations that are bad. There are two distinct
cases involved.
-If the LPAR is not part of the same plex as the system
that wrote the 70PR record then that OBS is dropped since
the weights will reflect the weights from the LPAR that
created the TYPE70PR record.
-If the LPAR is not found in the TYPE70 data you will get
a WARNING that there is missing data and some may be
erroneous for those LPARs that are missing but the OBS
are kept.
Change 34.235 Cosmetic. Variables DSGNAME and DVLSTGRP had '00'x pad
VMACDCOL characters if the name was less than eight bytes that are
Oct 11, 2016 now changed to blanks, and variable DSGCSMSS is labeled.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 34.234 MQ Series TYPE116 variable WQUSECNT, USE_COUNT, can be a
VMAC116 negative value (-1) to represent a CLOSE with (+1) OPEN,
Oct 11, 2016 so the INFORMAT &IB.4. is now used instead of &PIB.4.
Oct 19, 2016 Variable WTASPRCT is now correctly divided by 4096.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 34.233 TYPEXCOM format MGXCMST was not found due to a blank in
FORMATS the VALUE statement.
Oct 10, 2016
Thanks to Jim S. Horne, Lowe's Companies, Inc., USA.
======= Changes thru 34.232 were in this MXG 34.07 dated Oct 7, 2016===
Change 34.232 MXG 34.07 first iteration ERROR:ARRAY SUBSCRIPT OUT OF
VMAC7072 RANGE due to insufficient testing with enough data in
Oct 7, 2016 the TYPE70 Processing. My apology.
Thanks to Robert B. Richards, OPM, USA.
Change 34.231 MXG 34.07 first iteration lost an "@;" causing STOPOVER.
VMAC87 Datetimestamps are now converted to local, $CHARx fields
Oct 6, 2016 fields are properly $HEXxx formatted and SMF70DUR valid.
Thanks to Keith McWhorter,IBM Global Technology Services, USA.
======= Changes thru 34.230 were in this MXG 34.07 dated Oct 5, 2016===
Change 34.230 Corrections for CDHW support, INVALID DATA messages from.
VMACCDHW unprotected PD and PK fields.
Oct 5, 2016 -Oct 24. The INPUT of JULDATE was deleted causing missing
Oct 24, 2016 and/or wrong values.
Change 34.229 Support for DB2 V12 QWHS_MOD_LVL,_REC_INCOMPAT,REC_COMPAT
VMACDB2H variables INPUT in DB2 Header but not kept, and adjacent
VMACDB2 variable QWHCJOBSTEP that is kept, only in DB2ACCT.
VMAC102 -New variables added to DB2STATS:
Oct 5, 2016 Q9STCTDA='DISPLAY*ACCEL*COMMANDS'
Q9STCTSA='START*ACCEL*COMMANDS'
Q9STCTXA='STOP*ACCEL*COMMANDS'
Q9STLEN altered to match data, 220 read, Q9STLEN=256.
-New Contiguous Buffer Pool variables in DB2STATB
QBSTAGET='OVERFLOW*TOTAL*RANDOM*GETPAGES'
QBSTASGE='OVERFLOW*TOTAL*SEQUENTIAL*GETPAGES'
QBSTASYN='OVERFLOW*TOTAL*SYNC READ*RANDOMS'
QBSTASSE='OVERFLOW*TOTAL*SYNC READ*SEQUENTIAL'
-QJSTLEN test changed to 256 from 268, +116 VS avail128.
-LENQISE test GE 232 changed from 32.
-New variables in T102S053 and T102S058:
QW0053SECTN='RDI*SECTION*NUMBER'
QW0058SECTN='RDI*SECTION*NUMBER'
-New variables in T102S199, microsecond resolution.
QW0199S1='AVERAGE*SYNC*I/O*DELAY'
QW0199S2='MAXIMUM*SYNC*I/O*DELAY'
QW0199A1='AVERAGE*ASYNC*I/O*DELAY'
QW0199A1='MAXIMUM*ASYNC*I/O*DELAY'
-Five new DSNDQXST variables are kept in DB2ACCT and in
DB2STATS:
QXREFTBL ='REFRESH TABLES'
QXTRNOWN ='TRANSFER*OWNERSHIP*AVAILABLE'
QXRSDMAD ='DM NOT CALLED RAI PREDETERMINE'
QXR1BOAD ='FETCHED ONE BLOCK AN NEVER MORE '
QXSTSFND ='PREPARE SATISFIED FROM SYSDYNQRY'
-New fields are added to the end of QW0018 segment
QW0018SK='DATA ROWS SKIPPED*INCOMPATIBLE*LOCK HELD'
QW0018FI='DATA ROWS INSERTED*VIA*FAST INSERT'
QW0018FS='DATA ROWS*COULD NOT*USE FAST INSERT'
QW0018FA='DATA FAST INSERT*PIPE*REFILLS'
QW0018FW='DATA DB2 WAITS*FOR FAST*INSERT'
QW0I18SK='INDEX ROWS SKIPPED*INCOMPATIBLE*LOCK HELD'
QW0I18FI='INDEX ROWS INSERTED*VIA*FAST INSERT'
QW0I18FS='INDEX ROWS*COULD NOT*USE FAST INSERT'
QW0I18FA='INDEX FAST INSERT*PIPE*REFILLS'
QW0I18FW='INDEX DB2 WAITS*FOR FAST*INSERT'
-The below TYPE 102 IFCID updates can't be made until test
SMF data is available; DB2 DSECTS do not document the
internal format (TODSTAMP?/SMFSTAMP?/DB2INTERNAL?) nor
the epoch date, showing then as only CHAR8 in the DSECT.
-New IFCIDS: 389 380 404 413 414 477
-Changed IFCIDS: 018 125 316 401 53 58 with these notes:
IFCID 018 Statistics Class 1 Insert Algorithm 2
IFCID 058 Statistics Class 1 Insert Algorithm 2
IFCID 316/401 new wait times for Child/Page/L-Locks/P-
IFCIDs 53/58 statement level section for PREPARE
Change 34.228 Support for APAR OA48688, ABSOLUTE MSU LPAR GROUP CAPPING
VMAC7072 -TYPE70 new variable SMF70ABSMSU='Y' from SMF70HHF bit if
Oct 4, 2016 active for this partition.
-TYPE70PR new variables
CAPLIMCH='HARDWARE GROUP CAPACITY LIMIT CHANGED?'
SMF70HGWGRNAME='HARDWARE GROUP OF THIS PARTITION'
SMF70HWGR_CAP_LIMIT='HARDWARE*GROUP*ABSLIMIT'
Change 34.227 The $MGSMFID used by ANALID to describe SMF records is
ANALID enhanced to identify which product creates the record and
FORMATS with better descriptions, and a footnote added that the
Oct 1, 2016 MXG member IMACAAAA contains the MXG Product Suffix XXXX
each SMF Record Type, so you know what TYPEXXXX member to
use to process that SMF record. (Each IMACxxxx member has
the list of datasets that will be created for each XXXX.)
Thanks to MP Welch, Bank of America, USA.
Change 34.226 -Support for alternate SYSIN ddname input, user control
ADOCRMFV of VSAM CLOSE=FREE for RMF III data sets, and other
ASMRMFV improvements.
Oct 3, 2016 -A new keyword SYSIN=ddname allows ASMRMFV to input
parameters from a file with a ddname other than SYSIN.
This may be useful if ASMRMFV is executed under another
program such as SAS.
-The ddname must be a valid ddname for use in JCL and must
be present in the execution JCL or an error is flagged.
-SYSIN=ddname may ONLY appear in the JCL PARM= field NOT
in the SYSIN stream itself. Otherwise an error is
flagged.
-The SYSIN=ddname value must NOT be a reserved DDNAME used
by z/OS, JES2/JES3, or other important programs. If such
a ddname is used an error is flagged. For a full list of
these ddnames see documentation Section 5 "Input Data
Control Parameters" by SYSIN=ddname.
-The OPEN of the DCB for SYSIN or an alternate ddname now
validates that DSORG=PS, RECFM=FB or RECFM=F, and
LRECL=80 are attributes for the input file to prevent I/O
errors and other undesirable behavior. If these criteria
are not met ASMRMFV abends during parameter processing.
-VFREE (alias VF) and NOVFREE (alias NOVF) are a pair of
new parameters that control how RMF Monitor III VSAM data
sets are processed when closed.
-VFREE deallocates each RMF III data set thus releasing
the SHR enqueue for each data set as processed before the
entire ASMRMFV step ends while NOVFREE keeps the enqueues
for all RMF III data sets until the complete step end.
-For step program names ASMRMF* or IKJEFT* (*=any valid
program name characters), the default is VFREE. NOVFREE
is the default for other step program names.
-VFREE/NOVFREE has been tested successfully under z/OS 2.2
but may not necessarily have effect in other z/OS
releases.
-A new RMFV037I message displays the status of Input
Control parameters SYSIN=ddname and VFREE/NOVFREE.
-The RMFV035* message did not fully support the
TABERR=WARN option. All table errors were counted as
Severe Errors rather than as Warnings.
-When the only table errors are SPG Internal Problem
errors the final return code will now be 0008 instead of
0016.
-SPG Internal Problem errors occur when a coded Storage
Group name is misspelled or is nonexistent in the RMF III
SGSPACE start up parameter. These are NOT fatal to the
MXG PDB build process. There simply are no observations
in the result ZRBSPG SAS data set in the PDB. The
SGSPACE Storage Group name(s) must be corrected for
ZRBSPG to have observations.
-TIOT ddname search performance is improved.
-There is a new Abend Reason Code 40 for a GETDSAB service
failure.
-Additional descriptive problem text is added for OPEN,
CLOSE, and RDJFCB service failure RMFV007S messages.
-ASMRMFV could Abend S0C4 if a non-VSAM data set was coded
with an RMFV*, RMFC*, or RMFD* DDNAME and then opened as
a VSAM data set. Now this condition will be detected and
an error flagged.
-A new additional RMFV008I message will now display the
PDS member name or GDG relative generation if coded in
JCL for a file.
-The MXG00 record version is raised from X'05' to X'06'
and a new Input Options section is added.
-SYSIN=ddname and VFREE/NOVFREE features are not supported
by ASMRMFV versions prior to MXG Change 34.226. If
specified a parameter error will be flagged.
-Documentation Section 20 is retitled as "FREE=CLOSE for
VSAM Data Sets".
-Following documentation sections are
updated:
Section 5 "Input Data Control Parameters"
Section 8 "Error Handling Parameters"
Section 12 "Messages"
Section 14 "Skipped Records"
Section 16 "Return Codes"
Section 17 "Abend Reason Codes"
Section 20 "FREE=CLOSE for VSAM Data Sets"
Section 29 "Summary"
Change 34.225 If you used ANALHSM and do not have SAS/GRAPH and are on
ANALHSM SAS 9.2 or earlier, some graphic statements that should
Sep 30, 2016 have been bypassed caused error messages,
Change 34.224 Support for APAR OA50256 for TYPE1415 corrects SMF14DSVER
FORMATS field's values, from which MXG variable SMF14DSTYPE using
VMAC1415 the $MG014EF format, updated by this change. There was
Sep 30, 2016 no change made to VMAC1415; listed here for impact only.
Change 34.223 Support for APAR OA49415 for SuperPAV Support, adds data:
VMAC74 -Added to TYPE74 dataset:
VMAC78 2016 SUPERPAV='SUPERPAV*MODE?'
Sep 30, 2016 SMF74AGC='CONTROLLER*ALIAS*MANAGEMENT*GROUP*NUMBER'
SMF74AGS='ASSOCIATED*ALIAS*MANAGEMENT*GROUP*NUMBER'
-Added to TYPE78IO dataset:
R783GFLX='IOQ*GLOBAL*FLAGS*EXTENDED'
-Added to TYPE78CF dataset:
R783AMGC &PIB.1./*CONTROLLER*ALIAS*MGMT*GROUP*NUMBER*/
R783AMGS &PIB.4./*ASSOCIATED*ALIAS*MGMT*GROUP*NUMBER*/
-Added to TYPE78CU dataset:
R783XANC='ALIAS*NEEDED*TO START*AN I/O'
R783XAUC='ALIAS*USED*TO START*AN I/O'
R783XNHC='ALIAS*NEEDED*NONE*AVAILABLE'
R783XABC='ALIAS*BORROWED*FROM*PEER LCU'
R783XCBC='CONCURRENTLY*BORROWED*ALIAS'
R783XHBC='HWM*CONCURRENTLY*BORROWED*ALIAS'
R783XALC='ALIAS*LOANED*TO A*PERR LCU'
R783XCLC='CONCURRENTLY*LOANED*ALIAS'
R783XHLC='HWM*CONCURRENTLY*LOANED*ALIAS'
R783CNAG='BORROW*ATTEMPTS*NONE*AVAILABLE'
R783XCQD='CUM I/O*QUEUED*WHERE*ALIAS*NEEDED'
R783XCIU='CUM ALIAS*DEFINED*AND IN USE'
Change 34.222 Support for APAR OA51097 that documents new fields that
VMAC42 weren't in the SMF manual for SMF type 42 subtype 19.
Sep 30, 2016 Variables added to TYPE42X2 dataset:
SMF42JUC='LOW FIXED 4K PAGES IN USE'
SMF42JUD='HIGH FIXED 4K PAGES IN USE'
SMF42JUE='AVG FIXED 4K PAGES IN USE'
SMF42JUF='MAX FIXED STORAGE'
SMF42JUG='PCT REAL*CAN BE USED*FOR FIXED'
Variables added to TYPE42X4 dataset:
SMFA2JUC='LOW FIXED 4K PAGES IN USE'
SMFA2JUD='HIGH FIXED 4K PAGES IN USE'
SMFA2JUE='AVG FIXED 4K PAGES IN USE'
SMFA2JUF='MAX FIXED STORAGE'
SMFA2JUG='PCT REAL*CAN BE USED*FOR FIXED'
Change 34.221 Support for new SMF Type 29 IMS JAVA CPU and Garbage Coll
EXTY29GC creates new datasets
EXTY29JA DDDDDD MXG MXG
IMAC29 DATASET DATASET DATASET
TYPE29 SUFFIX NAME LABEL SUBTYPE
TYPS29
VMAC29 TY29GC TY29GC IMS JVM GARBAGE COLLECTION 2
VMXGINIT TY29JA TY29JAVA IMS JVM CPU USAGE 2
Sep 30, 2016 These members were added in MXG 34.01 Change 34.039 but
only now has VMAC29 been corrected and validated with
data records.
Thanks to Tony Curry, BMC, USA.
Change 34.220 WARNING R749PCIPAKTR in DROP KEEP RENAME never referenced
VMAC74 because it should have been spelled R749PCIPAKT. Warning
Sep 27, 2016 is printed only when the MXG OPTION DKROCOND=NOWARN is
changed to WARN; MXG expects/exploits DKROCOND=NOWARN as
it permits variable names in the KEEP= list that are not
output if their optional code is not enabled (especially
in CICSTRAN with its many possible optional variables.
Thanks to Andrew Krink, Northern Territory Government, AUSTRALIA.
Change 34.219 -Variables GDGCOMPL and GDGNOEXT and GDGLIMIT kept.
VMAC6156 -New undocumented catalog record '07' has two fields that
Sep 24, 2016 are input and kept for investigation.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 34.218 Arrays were incorrectly being initialized causing the
ASUM4HRS 4HR Averages to not be calculated and the resultant value
Sep 24, 2016 for each interval was the interval's value rather than
the average value. Note that if you request 4 Hours then
there will be no average calculated until the 5th Hour.
You may have to read TWO day's SMF to populate the 4 Hour
Average for all hours of today.
Thanks to Tony P. Steward, CSC, ENGLAND.
Change 34.217 -Dataset BVIR30 variables USDCACHE and USDFLASH were INPUT
VMACBVIR but were not kept.
Sep 22, 2016 -Datasets BVIR301 and BVIR302 were both wrong, having too
Sep 26, 2016 few observations and keeping wrong variables. BVIR301
now has one observation for each CACHEPARTNR (0 thru 7)
and BVIR302 one for each CONTAINER and Performance Group.
Thanks to Pierre Pascal Joulin, SOCGEN, FRANCE.
Change 34.216 Support for SMF 98 High Frequency Throughput Statistics
EXTY9801 HFTS record creates nine new datasets. The TYPE9801 data
EXTY98EE set contains all of the segments that occur only once per
EXTY98LD record; the eight TYPE98SD-TYPE98SL data sets contain the
EXTY98LL segments that can occur more than once per record:
EXTY98LS
EXTY98PB DDDDDD MXG MXG
EXTY98SD DATASET DATASET DATASET
EXTY98SL SUFFIX NAME LABEL
EXTY98WU
FORMATS TY9801 TYPE9801 TYPE 98 HFTS SUBTYPE 1
IMAC98 TY98SD TYPE98SD HFTS SPINLOCK DETAIL
TYPE98 TY98LS TYPE98LS HFTS LOCK SUSPEND SUMMARY
TYPS98 TY98LD TYPE98LD HFTS LOCK SUSPEND DETAIL
VMAC98 TY98LL TYPE98LL HFTS LOCK LOCAL CML DETAIL
VMXGINIT TY98PB TYPE98PB HFTS PRIORITY BUCKET
Sep 20, 2016 TY98EE TYPE98EE HFTS CONSUME EXECUTION EFFICIENCY
Aug 17, 2016 TY98WU TYPE98WU HFTS CONSUME WORK UNITS
TY98SL TYPE98SL HFTS CONSUME SPIN LOCK SUMMARY
Thanks to Nicholas Jones, IBM, USA.
Thanks to Daniel V. Rosa, IBM, USA.
Change 34.215 Support for PRO/SMS (previously X37) Version 7.8 RSL1607
VMACPROS which INCOMPATIBLY replaced 60 bytes after PROCSTEP with
Sep 22, 2016 102 bytes, causing misalignment of all subsequent fields
but only impacting the PRORECOV dataset.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 34.214 New SMF fields documented in new Sept 2016 SMF Manual:
VMAC30 -VMAC30, datasets TYPE30_V/TYPE30_4/TYPE30_5/TYPE30_6:
VMAC42 new variable SMF30SLM='MEMLIMIT*ACTION*TAKEN*FLAGS'
VMAC74 -VMAC42, dataset TYPE42S1: was wrong, 16-bytes skipped.
VMAC79 new variable SMF42FY3='VALID*COUNTS*FLAGS'
VMAC90A Initially, I thought IBM had inserted 16 bytes but they
VMXGINIT have been there at least since z/OS 1.13. But, when I
EXTY9038 thought I was going to have to test for version, users
EXTA9038 found these values in their data:
EXTB9038
EXTY9039 PRODUCT SUBTYPES PRODLVL
Sep 18, 2016
CA PDSMAN 24 7.7.0
MVS/OS390 10 HDZ1D10
MVS/OS390 10 HDZ2220
Z/OS18 15/17/18/19 DFSMVS18
DFSMS/MVS 1/5/6 HDZ1D10
DFSMS/MVS 1/5/6 HDZ2220
DFSMS/MVS 4 1.3.0
MVS/DFP 2 HDZ1D10
MVS/DFP 2 HDZ2220
Z/OS DFSMS 9 1.12.0
Z/OS DFSMS 20/21/24 V01R13M0
Z/OS DFSMS 20/21/24/25 V02R02M0
Z/OS DFSMS 27 HZD2220
-VMAC42, dataset TYPE42S2 new variables:
SMF42FSH='COMP1*CLASS4*LOCKS'
SMF42FSI='COMP1*CLASS4*TRUE*CONTENTION'
SMF42FSJ='COMP1*CLASS4*FALSE*CONTENTION'
SMF42FSK='COMP1*CLASS4*RELEASE*LOCKS'
-VMAC42, dataset TYPE42S3 new variables:
SMFA2FPHA='COMP1*CLASS4*LOCKS'
SMFA2FPIA='COMP1*CLASS4*TRUE*CONTENTION'
SMFA2FPJA='COMP1*CLASS4*FALSE*CONTENTION'
SMFA2FPKA='COMP1*CLASS4*RELEASE*LOCKS'
-VMAC74, dataset TYPE74CA new variable
R745CFDV='FAILING*DEVICE'
-VMAC77, dataset TYPE77 new variables
SMF77CSC='CONTENTION*STATUS*CHANGE*EVENTS'
SMF77NOD='NO*SEPARATE*CONTENTION*DETAIL'
-VMAC79, variables R79ETCMW/R79ECTRD could be missing
values, test for APAR additions revised.
-VMAC90A, Support for new datasets from new subtypes:
TY9038 TYPE9038 38:SET IEFOPZ
TYA038 TYPE9038A 38A:OLD NEW DSNAME
TYB038 TYPE9038B 38A:DD JOBNAME
TY9039 TYPE9039 39:SET SMFLIM
Change 34.213 Support for the SMF 119 Subtype 81 Intrusion Detection
EXT11981 Service creates new dataset
FORMATS DDDDDD DATASET DESCRIPTION
IMAC119 T11981 TYP11981 INTRUSION DETECTION SERVICE
VMAC119
VMXGINIT
Sep 16, 2016
Thanks to Nathan Loewenthal, CitiGroup, USA.
Change 34.212 The ANALID report value for MVSLEVEL was incorrectly read
VMACSMF when the VSAM SMF file was input; an +OFFSMF was needed.
Sep 16, 2016
Thanks to MP Welch, Bank of America, USA.
Change 34.211 Support for SMF 80 TOKDANAME='TOKMFILEPROCMAX' adds new
VMAC80A variable TOKMFILEPROCMAXNR.
Sep 15, 2016
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 34.210 Some USS RACF Event values (28 thru 58 decimal) were not
FORMATS decoded in MG080EV and $MGSMFID formats.
Sep 15, 2016
Thanks to MP Welch, Bank of America, USA.
Change 34.209 "DB2 is filling my SMF, how do I find out who/why" may be
DB2COUNT answered with DB2COUNT program that reads SMF 101 records
Sep 13, 2016 creating a stripped down PDB.DB2ACCT with the identity
variables and PROC FREQs to provide counts of who/why and
then ANALDB2T reports on the top resource consumers.
Change 34.208 -These compression Rate variables were labeled "MB PERSEC"
VMAC74 but they contained bytes. Now they are in MB Per Second:
Sep 11, 2016 R749PCIDMAR/MAW R749FPGCOBS/DCBS R749PCIBYTR/BYTT
R749FPGBYTS. And R749FPGBYTR Average Request is now KB.
-Variable R749FPGBPRT is now equated to R7491BPC for the
Buffer Pool utilization.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 34.207 VMXGRMFI summarization with large INTERVAL= DATE or SHIFT
VMXGRMFI or even TWOHOUR could produce incorrect results with no
Sep 14, 2016 error messages. The value of SHIFT could be incorrect,
which could cause the date to be one day wrong. Only
user-created invocation of VMXGRMFI are exposed; none of
the MXG-supplied VMXGRMFI members have large intervals.
-The exposure is when the requested INTERVAL spanned a
shift boundary or did not align perfectly with the shift
times; to get FOURHOUR FOURHOUR summary you must have
SHIFT boundaries of at 0/4/8/12/16/20.
-Using INTERVAL=SHIFT produced wrong results if your
interval spans a shift boundary, but it is likely that
what you really wanted was by DATE and SHIFT, so VMXGRMFI
has new INTERVAL=DATESHIFT/WEEKSHIFT/MONTHSHIFT/
MONTHSHIFT/QUARTERSHIFT/SEMIANNSHIFT/ANNUALSHIFT. These
new options set the INTERVAL=DATE/WEEK/etc., and add
variable SHIFT to the end of the SUMBY list. In
addition, new &RMFIBY macro variable with default
RMFIBY=SYSPLEX SYSTEM SYSNAME STARTIME
is created to allow more extensive tailoring if needed.
If you use this interval structure (xxxxSHIFT) you must
also use the same RMFIBY to put the resulting data
through TRENDing to preserver the SHIFT value.
-SHIFT added to the RMFWKLRV dataset.
-SHIFT is blank for INTERVAL= that span shifts (DATE, etc)
since there is no value possible with multiple shifts.
-Two PROC SORTs were replaced by MEANS with CLASS..
-If Reporting Classes are used for Workload Definitions,
the WKLDDESC='REPORTING CLASS' value is set for that
variable because they don't have WLM WORKLOAD values.
-Messages that SRVCLASS='SYSOTHER' was found in TYPE72GO
input are now always printed; this is NOT due to MXG but
is a fall-thru service class used by IBM when your WLM
rules failed to classify work, and should never exist.
Thanks to Andre Gustavo Moretto, IBM Global at Delta, USA.
Change 34.206 -Support for Top Secret R15. Changed was RACFVRSN='F0'x.
VMAC80A Without change, dataset TYPE80TS had zero observations.
Sep 7, 2016 -Support for Top Secret R16. Added RACFVRSN='10'x test on
Oct 5, 2016 Oct 5.
Nov 5, 2016 -Format $MG080TS created to map Resource Code to Class by
FORMATS reading the RDT.TXT table. A program to re-create that
format is in comments at the end of this VMAC80A.
Thanks to Carl D. Ellis, Wells Fargo, USA.
Change 34.205 SMF 6 UNDECODED KEYS and INPUT EXCEEDED STOPOVER error
IMAC6ESS because MXG only expected 4 USERLIB segments. ESSULIB5/6
VMAC6 are now input and kept and more than 6 now protected.
Sep 6, 2016
Thanks to Sabrina Mandelatz, ProvinzialRheinlandVersicherung, GERMANY
Change 34.204 -Variable SHIFT is added to RMFWRKLV DATASET in VMXGRMFI.
VMXGRMFI -TRND70PR incorrectly used variable name DATETIME when it
TRND70PR should have used STARTIME in the SUMBY list, which worked
Sep 2, 2016 accidentally.
Oct 2, 2016 -STARTIME removed from ID statement Oct 2.
Thanks to Andre G. Moretto, Delta Air Lines, USA.
Change 34.203 Cosmetic. All "CICS EXCLUDED FIELDS FOUND" messages now
VMAC110 contain the READTIME value of that APPLID, which is when
Sep 2, 2016 the CICS Dictionary Record is written, so you know what
SMF data to select for UTILEXCL
Change 34.202 Support for Connect Direct Simultaneous Session CDHW SMF
EXCDHWSS creates new dataset
IMACCDHW DDDDDD DATASET DESCRIPTION
TYPECDHW CDHWSS CDHWSSES CD SIMULTANEOUS SESSIONS
TYPSCDHW
VMACCDHW
VMXGINIT
Aug 29, 2016
Thanks to Scott Wiig, USBank, USA.
Thanks to David Magoon, USBank, USA.
Change 34.201 Support for CDI-NDM Version 5.2 (INCOMPATIBLE).
VMACNDM Incomplete, not moved to 34.07, no data yet.
Aug 29, 2016
Thanks to Michael Oujesky, DTCC, USA.
Change 34.200 -SMF 115 dataset MQMLOG is enhanced with new variables
VMAC115 QWHSDURN='INTERVAL*DURATION'
VMACDB2H PCTLOGBY='PERCENT*LOG*BUSY'
Aug 24, 2016 QWHSTIME='MQ*INTERNAL*START*DATETIME'
Sep 13, 2016 -Sep 13: Protection for old versions with QWHSLEN=36 added
Sep 16, 2016 and missing values calculations eliminated.
Sep 22, 2016 -Sep 16: Variables added to MQMLOG dataset:
Sep 24, 2016 QJSTSLPTU ='PHYSICAL*WRITER*SLEEP*DURATION'
Oct 11, 2016 QJSTIOSQU1='SSQ*IO TIME*1ST HALF'
QJSTIOSQU2='SSQ*IO TIME*2ND HALF'
-Sep 22: QJST busy time is now created and calculated as
QJSTBUSY=100*(QWHSDURN-QJSTSLPTU)/QWHSDURN;
-Sep 24: GMT115TM is now correctly calculated and used to
shift the QJSTIOMAXxxxx datetimestamps to LOCAL zone.
-Oct 11: Labels improved for vars QJSTBUSY, QJSTSLPTU.
Thanks to Carolina W. Sumilang, DTCC, USA.
Thanks to Joe Faska, DTCC, USA
Change 34.199 -RMF III dataset ZRBDVT variable DVTLCUNR was always zero
VMACRMFV and DVTSAMPP was trashed, due to mis-alignment in MXG.
Aug 24, 2016 -Variable DVTSSID='SUBCHANNEL*SET' is now INPUT and KEPT.
Aug 30, 2016 -Variable GEIAHUIC is now INPUT as Floating Point.
-Variable GEIFLG1 is now INPUT and KEPT.
======= Changes thru 34.198 were in MXG 34.06 dated Aug 18, 2016========
Change 34.198 -Enhancement for Relative Time filtering for FROMTIME=
ADOCRMFV and TOTIME= parameters using the current Time of Day
ASMRMFV (TOD) timestamp.
Aug 18, 2016 -The TOD value as shown in the ASMRMFV RMFV001I log
Aug 20, 2016 message and obtained as execution begins is the basis for
Relative Time calculations.
-Relative Times are specified as either hour or minute
offsets from the current TOD. The default is hours if
the unit is not explicitly coded.
-Improved handling of midnight crossover condition when
Relative Time offset exceeds current TOD Time.
-All of the following formats are supported for FROMTIME=
Relative Times:
FROMTIME=*- FROMTIME=- FROMTIME=*-
FROMTIME=*-0 FROMTIME=-0
FROMTIME=*-00 FROMTIME=-00
FROMTIME=*-0H FROMTIME=-0H
FROMTIME=*-00H FROMTIME=-00H
FROMTIME=*-0M FROMTIME=-0M
FROMTIME=*-00M FROMTIME=-00M
FROMTIME=*-000M FROMTIME=-000M
FROMTIME=*-0000M FROMTIME=-0000M
h is hours (0-9) hh is hours (00-24)
m is minutes (0-9) mm is minutes (00-99)
mmm is minutes (000-999) mmmm is minutes (0000-1440)
-The maximum hour offset supported is 24 hours.
The maximum minute offset supported is 1440 minutes.
-'H' suffix is optional for hour offsets.
'M' suffix is required for minute offsets.
-The default offset is 0 hours for these formats:
FROMTIME=* FROMTIME=*- FROMTIME=-
-The following forms for FROMTIME= all result in the
current TOD being used as a data selection start
time:
FROMTIME=*- FROMTIME=- FROMTIME=*-
FROMTIME=*-0 FROMTIME=-0
FROMTIME=*-00 FROMTIME=-00
FROMTIME=*-0H FROMTIME=-0H
FROMTIME=*-00H FROMTIME=-00H
FROMTIME=*-0M FROMTIME=-0M
FROMTIME=*-00M FROMTIME=-00M
FROMTIME=*-000M FROMTIME=-000M
FROMTIME=*-0000M FROMTIME=-0000M
-These forms are of no practical use when FROMDATE=*
(current date) is also coded because the selection start
time will result in little if any data being actually
output.
-The use of Relative Time with FROMTIME= does not change
the FROMDATE= value whether defaulted or coded. These
two parameters remain independent.
-The Relative Time process for FROMTIME= follows these
steps:
-1. The hour or minute time offset requested is deducted
from the time portion of the current TOD clock value.
-2. If the result of the time offset deduction is negative
and the active FROMDATE= value also the current date,
then the FROMTIME= value is forced to 00:00:00.000000
(midnight).
-3. If the result of the offset deduction is negative and
the active FROMDATE= value is NOT the current date, then
the portion of hours or minutes that exceeds the elapsed
time for the current date crosses midnight. See example
below for more detail.
-To summarize the midnight crossing support where '*'
represents the current date:
FROMTIME=
FROMDATE= Time Offset Result
--------- ------------- ------------------
* LE Current TOD Midnight cross N/A
* GT Current TOD FROMTIME 00:00:00.000000
Not * LE Current TOD Midnight cross N/A
Not * GT Current TOD Midnight crossed
The midnight cross time is calculated as:
Current time - FROMTIME time offset + time in 1 day
-4. The FROMTIME= value for an hours offset is truncated
to the start of the hour while the FROMTIME= value for a
minutes offset is truncated to the start of the minute.
This is a practical aid to prevent data selection
from beginning at an odd time.
-To summarize the Relative Time results for
FROMTIME=:
TIME TRUNCATED
OFFSET UNIT FROMTIME=
----------- ---------------
Default (Hours) HH:00:00.000000
H (Hours) HH:00:00.000000
M (Minutes) HH:MM:00.000000
-Examples for FROMTIME= Relative Time usage follow.
For these examples assume the current TOD is:
DATE=2016.251 01SEP2016 THU TIME=09:26:56.776233
-Example 1: FROMDATE=* FROMTIME=*-3
is a 3 hour TOD Relative Time offset for the current day
results in:
FROM DATE=2016.251 01SEP2016 THU TIME=06:00:00.000000
TO DATE=2042.259 16SEP2042 TUE TIME=23:59:59.999999
Note that a pure offset of 3 hours only would have
resulted in a FROMTIME= of 06:26:56.776233 which is an
awkward time stamp for the start of data selection. So
the start of the hour is provided.
-Example 2: FROMDATE=* FROMTIME=*-10
is a 10 hour TOD Relative Time offset and results in:
FROM DATE=2016.251 01SEP2016 THU TIME=00:00:00.000000
TO DATE=2042.259 16SEP2042 TUE TIME=23:59:59.999999
since the Relative Time offset extends beyond midnight
into the prior day and FROMDATE= is the current date,
the FROMTIME= was forced to midnight.
-Example 3: FROMDATE=*-1 FROMTIME=*-10
is a 3 hour current TOD Relative Time offset with a
FROMDATE= of yesterday and results in:
FROM DATE=2016.250 31AUG2016 WED TIME=23:00:00.000000
TO DATE=2042.259 16SEP2042 TUE TIME=23:59:59.999999
since FROMDATE= is NOT the current date, the FROMTIME=
offset is allowed to cross midnight by 1 hour in this
example. To achieve the cross midnight time behavior
FROMDATE= must NOT be the current date.
-To use the midnight crossing feature effectively a user
must anticipate a midnight crossover based on the size of
the Relative Time FROMTIME= offset being used and when
ASMRMFV is going to be run. Usually FROMDATE=*-1 is
coded rather than FROMDATE=* if the midnight time
crossover is expected.
-However, any FROMDATE= value that is not the current date
may be used and the midnight crossing will still occur.
-Example 4: FROMDATE=* FROMTIME=*-30M
is a 30 minute current TOD Relative Time offset and
results in:
FROM DATE=2016.251 01SEP2016 THU TIME=08:56:00.000000
TO DATE=2042.259 16SEP2042 TUE TIME=23:59:59.999999
-Example 5: FROMDATE=* FROMTIME=30M
is a parameter error because at least the '-' character
must follow FROMTIME= to indicate a Relative Time.
ASMRMFV will abend.
-All of the following formats are supported for TOTIME=
Relative Times:
TOTIME=*
TOTIME=*- TOTIME=-
TOTIME=*-h TOTIME=-h
TOTIME=*-hh TOTIME=-hh
TOTIME=*-hH TOTIME=-hH
TOTIME=*-hhH TOTIME=-hhH
TOTIME=*-mM TOTIME=-mM
TOTIME=*-mmM TOTIME=-mmM
TOTIME=*-mmmM TOTIME=-mmmM
TOTIME=*-mmmmM TOTIME=-mmmmM
-The meanings for h, hh, m, mm, mmm, mmmm, H, and M are
the same as for the FROMTIME= parameter.
-Hour and minute offset limits are the same as for
FROMTIME= Relative Times.
-'H' suffix is optional for hour offsets
'M' suffix is required for minute offsets
-The default offset is 0 hours for these formats:
TOTIME=* TOTIME=*- TOTIME=-
-The following forms for TOTIME= all result in the
current TOD being used as a data selection end time:
TOTIME=*- TOTIME=- TOTIME=*-
TOTIME=*-0 TOTIME=-0
TOTIME=*-00 TOTIME=-00
TOTIME=*-0H TOTIME=-0H
TOTIME=*-00H TOTIME=-00H
TOTIME=*-0M TOTIME=-0M
TOTIME=*-00M TOTIME=-00M
TOTIME=*-000M TOTIME=-000M
TOTIME=*-0000M TOTIME=-0000M
-However, when TODATE=* is also used it is unnecessary to
code these forms because the default TOTIME= is:
DATE=2042.259 16SEP2042 TUE TIME=23:59:59.999999
-The use of Relative Time with TOTIME= does not change the
TODATE= value whether defaulted or coded. These two
parameters remain independent.
-The Relative Time process for TOTIME= follows these
steps:
-1. The hour or minute time offset requested is deducted
from the time portion of the current TOD clock value.
-2. If the result of the offset deduction is negative and
the active TODATE= value is also the current date, then
the TOTIME= value is forced to 00:00:59.999999.
-3. If the result of the offset deduction is negative and
the active TODATE= value is NOT the current date, then
the portion of hours or minutes that exceeds the elapsed
time for the current date crosses midnight. See example
below for more detail.
-To summarize the midnight crossing support where
'*' represents the current date:
TOTIME=
TODATE= Time Offset Result
--------- ------------- ------------------
* LE Current TOD Midnight cross N/A
* GT Current TOD TOTIME 00:00:59.999999
Not * LE Current TOD Midnight cross N/A
Not * GT Current TOD Midnight crossed
The midnight cross time is calculated as:
Current time - TOTIME time offset + time in 1 day
-4. The TOTIME= value for an hours offset is truncated to
the start of the hour while the TOTIME= value for a
minutes offset is truncated to the start of the minute
depending on the time offset unit. In either case
00:00:59.999999 is added to the result.
-TOTIME= values are set with 59.999999 seconds as the last
part of the time stamp so that any data time stamped
within the minute is sure to be selected. TOTIME= in
ASMRMFV has always been inclusive of the entire end
minute.
-5. However, if the time offset is zero then the final
time value is only adjusted to the end of the minute
whether the time offset unit is in hours or minutes.
-To summarize the adjustment with non-zero TOTIME=
offsets:
TIME FINAL
OFFSET UNIT TOTIME=
----------- ---------------
Default (Hours) HH:00:59.999999
H (Hours) HH:00:59.999999
M (Minutes) HH:MM:59.999999
-To summarize the adjustment with a zero TOTIME=
offset:
TIME FINAL
OFFSET UNIT TOTIME=
----------- ---------------
Default (Hours) HH:MM:59.999999
H (Hours) HH:MM:59.999999
M (Minutes) HH:MM:59.999999
-Examples for TOTIME= Relative Time usage follow.
For these examples assume the current TOD is:
DATE=2016.251 01SEP2016 THU TIME=09:26:56.776233
-Example 1: TODATE=* TOTIME=*-3
is a 3 hour current TOD Relative Time offset and results
in:
FROM DATE=2000.001 01JAN2000 SAT TIME=00:00:00.000000
TO DATE=2016.251 01SEP2016 THU TIME=06:00:59.999999
-Example 2: TODATE=* TOTIME=*-10
is a 10 hour current TOD Relative Time offset and results
in:
FROM DATE=2000.001 01JAN2000 SAT TIME=00:00:00.000000
TO DATE=2016.251 01SEP2016 THU TIME=00:00:59.999999
since the Relative Time offset extends beyond midnight
into the prior day and TODATE= is the current date, then
the TOTIME= was forced to midnight + 00:00:59.999999 .
-Example 3: TODATE=*-1 TOTIME=*-10
is a 10 hour current TOD Relative Time offset with a
TODATE= of yesterday and results in:
FROM DATE=2000.001 01JAN2000 SAT TIME=00:00:00.000000
TO DATE=2016.250 31AUG2016 WED TIME=23:00:59.999999
since TODATE= is NOT the current date, the TOTIME= offset
is allowed to cross midnight by 1 hour in this example.
To achieve the cross midnight time behavior TODATE= must
NOT be the current date.
-To use the midnight crossing feature effectively a user
must anticipate a midnight crossover based on the size of
the Relative Time TOTIME= offset being used and when
ASMRMFV is going to be run. Usually TODATE=*-1 is coded
rather than TODATE=* if the midnight time crossover is
expected.
-However, any TODATE= value that is not the current date
may be used and the midnight crossing will still occur.
-Example 4: TODATE=* TOTIME=*-30M
is a 30 minute current TOD Relative Time
offset and results in:
FROM DATE=2000.001 01JAN2000 SAT TIME=00:00:00.000000
TO DATE=2016.251 01SEP2016 THU TIME=08:56:59.999999
-Example 5: TODATE=* TOTIME=30M
is a parameter error because at least the '-' character
must follow TOTIME= to indicate a Relative Time. ASMRMFV
will abend.
-Documentation Section 5 "Input Data Selection Parameters"
is updated to explain use of Relative Times for FROMTIME=
and TOTIME= parameters.
-The Relative Time feature is not supported by earlier
ASMRMFV versions prior to MXG Change 34.198. If
specified a parameter error will be flagged.
Change 34.197 More Support for BE93 Version 6.1.0 (INCOMPATIBLE) due to
VMACBETA changed BETAFLAG that contains '81'x, but the MXG test
Aug 19, 2016 for the extended header existence tested for '80'x, and
there were new fields inserted in the subtype=1 record
causing misalignment and invalid values in BETA1 dataset.
Thanks to Sabrina Mandelatz, Provinzial Rheinland Versicher, GERMANY
Change 34.196 -SMF 78 ST3 INPUT STATEMENT EXCEEDED when APAR OA44525
VMAC78 zHPF Extended Distance II is installed, MXG 33.07-34.05,
Aug 18, 2016 because MXG Change 33.156 for that APAR incorrectly had
INPUT R783TMWM/R783TRDM in the DCS segment for TYPE78CF,
but that APAR had added those fields in the ASS segment.
MXG properly INPUTs them and keeps them in TYPE78CU
instead of TYPE78CF. The STOPOVER ABEND that results
can be circumvented adding MACRO STOPOVER MISSOVER %
statement at the top of your //SYSIN, and/or you can
request just the VMAC78 member from support@mxg.com
-Added May 2017: This change caused a massive increase in
the number of observations in TYPE78CF; prior code read
only output the first CU (8 obs/record) but there are 356
obs typically in each record.
-Unrelated, APAR OA49415 added new fields now in TYPE78CU:
R783AMGC='ALIAS*MGMT*GROUP*NUMBER*PHYSICAL CU'
R783AMGS='ALIAS*MGMT*GROUP*NUMBER*THIS LCU'
Thanks to Gadi Ben-Avi, MALAM, ISREAL.
Change 34.195 TMON/CICS new variables TASZIPTM and TASELGTM created and
VMACTMO2 kept in MONITASK dataset, and TASCPUTM is corrected to
Aug 15, 2016 contain ONLY the CP CPU time (previously it had the sum
of CP and zIIP time).
And, only for TMON 3.4, TASCPOT/TASCPUT were not divided
by 4096.
Change 34.194 Support for SMF 99 Subtype 1 additional segments create
EXTY99SL new datasets:
EXTY99ST DDDDDD DATASET DESCRIPTION
EXTY99PT TY99SL TYPE99SL SOFTWARE LICENSING
EXTY99PI TY99ST TYPE99ST SOFTWARE LICENSING TABLE
EXTY99ZE TY99PT TYPE99PT CP PRIORITY TABLE
EXTY99PS TY99PI TYPE99PI ZAAP PRIORITY TABLE
VMAC99 TY99ZE TYPE99ZE ZIIP ENTITLEMENT
VMXGINIT TY99PS TYPE99PS ZIIP PRIORITY TABLE
Aug 13, 2016 The new TYPE99SL dataset has the new Hardware Absolute
Group Capping metrics added by APAR OA47752.
-Variable S99BUNUS in TYPE99BG can now be negative MSU
when capped.
Thanks to Scott Wiig, USBank, USA.
Thanks to Tony P. Steward, CSC, ENGLAND.
Change 34.193 HSM SMF VSR records with '62'x instead of the "S" in VSR
VMACHSM test field printed "INVALID HSM RECORD" messages and the
Aug 12, 2016 (six out of 100) records were skipped. Now, if DSRVSR
Jan 3, 2017 is NOT DSR but starts with a V, the record will be read
as a VSR record, while IBM HSM Support investigates.
-Turns out this had nothing to do with HSM, but was an
error that touched man SMF records, if you used LOGGER
and had a MAXBUFSIZE that was NOT 65532. APAR OA51823.
Thanks to Scott Wiig, USBank, USA.
Change 34.192 RMF III variable GMTOFF is now kept in each ZRB dataset
VMACRMFV to aid in processing data from multiple timezones. It is
Aug 11, 2016 INPUT from each SSH record and retained for all of the
following records in that interval.
(Only the first SSH record is output in ZRBSSH by logic
in member EXZRBSSH).
Thanks to MP Welch, Bank of America, USA.
Change 34.191 -Enhancement for character data filtering for RMF Monitor
ADOCRMFV III SPG (Storage Group and Volume Data) table and other
ASMRMFV usability improvements.
VMACRMFV -These filters are intended for building ad hoc MXG RMF
Aug 11, 2016 III PDBs for studies to avoid the overhead of generating
a full SPG table based PDB. They control which SPG table
entries are output to the RMFBSAM file.
-Please see the new documentation Section 28 "Collection
of DASD Usage with RMF Monitor III" in the ADOCRMFV
member or ASMRMFV source member for the requirements and
setup of DASD usage measurement in the SPG table. There
are multiple Storage Group name entries in the SPG each
with many Volume Data entries when collection is active.
-Four new filters are added to support SPG entry selection
from this table to the RMFBSAM output file. These
filters are effective only if the SPG table is selected.
New Keyword Aliases
------------- -----------------------------------------
SPGSTORGROUP= SPGSTORGRP=, STORGRUP=, SPGGRP=, SGPSNM=,
SPGSG=
SPGVOLSER= SPGVOLI=, SPGVOL=, SPGSER=, SPGV=
SPGAND None
SPGOR None
The order of SPG filter application when both keywords
are present is:
1) SPGSTORGROUP= (or any alias for SPGSTORGROUP=)
2) SPGVOLSER= (or any alias for SPGVOLSER=)
Selection results from repeats of the same SPG filter
keyword (or any of its aliases) are always logically
ORed.
-TUTORIAL:
Ranges of the form keyword=first:last may be used with
any of the above keywords except SPGAND and SPGOR.
The colon character ':' is required for a paired range
specification. All entries GE the first value and LE the
last value are selected for output to the RMFBSAM file.
The first value may not exceed the last value in EBCDIC
collating sequence or an error is flagged in message
RMFV056E.
Single unpaired values may be specified for a range
simply as keyword=first and in this case the colon ':' is
omitted.
Patterns may also be used with any of the above keywords
except SPGAND and SPGOR and include one or more Wild Card
characters to match the respective SPG data field.
A pattern contains one or more special Wild Card
characters as follows:
Wild
Card Matches
---- -------------------------------------------------
* 0 or more characters
% 1 Non-blank character
+ 1 Numeric character (0-9)
_ 1 Alphabetic character or _ (a-z, A-Z, _)
. 1 National character (@, #, $)
! 1 Special character (not a-z, A-Z, 0-9, @, #, $)
? A blank string if used by itself
? 1 Blank character (X'40') if used with any other
characters
Ranges may not be wild carded. If wild carded the range
value becomes a pattern instead and is processed as such.
See Section 25 "Ranges and Patterns" in the ADOCRMFV
member or ASMRMFV source code for more details on usage
of ranges and patterns.
-SPGSTORGROUP= (or any of its aliases) selects SPG Storage
Group name entries from 1-8 characters. Storage Group
names are defined for System Managed Storage (SMS) and
are 1-8 alphabetic characters including A-Z, 0-9, $, @,
#, *, or %. The first character must be alphabetic
(A-Z). Both ranges and patterns with wild cards may be
specified. Up to 64 ranges and 64 patterns are
supported. The default is SPGSTORGROUP=ALL.
-In all of the following examples assume the following
Storage Group names and Volume Serials are defined to SMS
in this highly simplified configuration and that RMF
Monitor III is actively measuring them:
Storage Volume
Group Serials
-------- ---------------------------
PRODPOOL PRD001 PRD002 PRODAA PRODBB
TESTPOOL TST001 TST002 TESTAA TESTBB
WORKPOOL WRK001 WRK002 WORKAA WORKBB
-Examples for SPGSTORGROUP= :
SPGSTORGROUP=PRODPOOL:TESTPOOL is a range that selects
only Storage Groups with a name GE 'PRODPOOL' and LE
'TESTPOOL'. All the volume serials in these pools will
be selected. No volumes in WORKPOOL are selected.
SPGSG=P* is a pattern that selects only Storage Group
names that begin with 'P'. Only volumes from the
PRODPOOL are selected. Note use of the keyword alias
SPGSG= for coding convenience.
STORGRUP=A* is a pattern that selects only Storage Groups
with a name that begins with an 'A'. No Storage Groups
will be selected in this example. Note use of an alias.
SPGGRP=*L is a pattern that selects only Storage Groups
with a name that ends with 'L'. All Storage Groups will
be selected in this example. This is the default if no
filter keywords are coded. Note use of an alias.
See Section 25 "Ranges and Patterns" in the ADOCRMFV
member or ASMRMFV source code for more details on usage
of ranges and patterns.
-SPGVOLSER= (or any of its aliases) selects SPG entries by
Volume Serial number. Both ranges and patterns with wild
card characters may be specified. Up to 64 ranges and 64
patterns are supported. The default is SPGVOLSER=ALL.
Any valid 1-6 character Volume Serial with or without
pattern characters may be specified. Per JCL syntax a
Volume Serial Number is 1 through 6 alphanumeric,
national ($,#,@), or special characters.
NOTE: Since just about any keyboard character is valid in
a Volume Serial please take extra care when coding to
avoid unintended results in the MXG PDB data set ZRBSPG.
NOTE: Data filtering by Volume Serial only is much less
efficient than filtering by Storage Group because every
volume in every Storage Group must be matched against the
ranges and patterns provided. There are usually many
more volumes than Storage Groups. Use of SPGSTORGROUP=
instead is recommended if feasible.
NOTE: If one or more SPGVOLSER= filters is coded and a
Storage Group has zero volume data entries the Storage
Group is filtered as this is considered a mismatch.
-Examples for SPGVOLSER=
SPGVOLSER=PRODBB selects the volume serial PRODBB only.
However, ASMRMFV will search every Storage Group until it
is found.
SPGV=TST000:TST999 selects all volume serials GE
'TST000' and LE 'TST999'. In this example volumes TST001
and TST002 will be selected. Note use of an alias.
SPGSER=WORK* selects all volume serials starting with
'WORK' followed by up to 2 more characters. In this
example volumes WORKAA and WORKBB will be selected. Note
use of an alias.
SPGVOL=*+++ selects all volume serials ending in 3
digits. In this example volumes PRD001, PRD002, TST001,
TST002, WRK001, and WRK002 are all selected. Note use of
an alias.
SPGVOLI=P*A selects all volume serials starting with 'P'
that have a final character 'A' with up to 4 intervening
characters. In this example only volume PRODAA is
selected. Note use of an alias.
-SPGAND (default) indicates that selection results from
the two different SPG filter keywords (and any of their
respective aliases) are logically ANDed.
-SPGOR indicates that selection results from the two
different SPG filter keywords (and their respective
aliases) are logically ORed. SPGOR must be coded if
desired.
-Examples of SPGAND/SPGOR:
-With SPGAND (default) in effect:
SPGSTORGROUP=WORKPOOL SPGVOLSER=WRK*
only selects volumes in the WORKPOOL Storage Group AND
that have a volume serial number that starts with 'WRK'.
SPGSTORGROUP= may appear redundant since only one pool
has WRK* volumes, but it keeps ASMRMFV from matching many
Volume Serials in other Storage Groups if only SPGVOLSER=
were present.
SPGSTORGROUP=WORKPOOL SPGVOLSER=WRK* SPGVOLSER=WORK*
only selects volumes in the WORKPOOL Storage Group AND
that have a volume serial number that starts with either
'WRK' or 'WORK'. In this example omitting SPGVOLSER=
would have produced the same result and is redundant.
SPGVOLSER= in this case adds unnecessary overhead.
STORGRUP=PRODPOOL SPGSG=TESTPOOL
only selects volumes that are in either the PRODPOOL
or TESTPOOL Storage Groups. Note the use of aliases.
SPGSTORGROUP=WORKPOOL SPGVOLSER=PRD*
selects NO volumes in this example using SPGAND because
the PRD* volumes are in the PRODPOOL AND not in the
WORKPOOL. There will be zero observations in the ZRBSPG
data set in the result MXG PDB.
SPGAND (default) logical ANDing provides more restrictive
SPG entry filtering than SPGOR.
-With SPGOR in effect:
SPGSTORGROUP=WORKPOOL SPGVOLSER=WRK*
only selects volumes that are in the WORKPOOL Storage
Group OR that have a volume serial number that starts
with 'WRK'. In this example omitting SPGVOLSER= would
produce the same result and is redundant. SPGVOLSER=
adds unnecessary overhead in this case with SPGOR because
ASMRMFV will search all other Storage Groups trying to
match that volume serial.
SPGSTORGROUP=WORKPOOL SPGVOLSER=WRK* SPGVOLSER=WORK*
only selects volumes that are in the WORKPOOL Storage
Group OR that have a volume serial number that starts
with either 'WRK' or 'WORK'.
All volumes in WORKPOOL will be selected so that the
SPGVOLSER= keywords are redundant in this example.
SPGVOLSER= adds unnecessary overhead in this case with
SPGOR because ASMRMFV will search all other Storage
Groups trying to match those volume serials.
STORGRUP=PRODPOOL SPGSG=TESTPOOL
only selects volumes that are in either the PRODPOOL
or TESTPOOL Storage Groups. Note the use of aliases.
This example produces the same result as with SPGAND
because two keywords (or any of their aliases) for the
same selection are always logically ORed.
SPGSTORGROUP=WORKPOOL SPGVOLSER=PRD*
selects all volumes in the WORKPOOL Storage Group OR
any volumes that start with 'PRD' in the PRODPOOL
Storage Group.
This is a MUCH different result with SPGOR than if SPGAND
is in effect. With SPGAND no volumes are selected.
ASMRMFV will search all Storage Groups for a match with
the SPGVOLSER= value.
The logical OR with SPGOR results in less restrictive
filtering because any of the 2 conditions in this example
results in data selection of a SPG volume data entry.
-Support for a new multi-table selection filter VOLSER=
(aliases VOLUME=, VOLI=, SER=, VOL=) to allow selection
by Volume Serial from both the RMF Monitor III DVT and
SPG tables with one keyword.
This is a convenience feature to avoid having to code the
Volume Serial parameter twice when the same volume from
both tables is of interest. Both the DVT and SPG tables
must be selected for this multi-table selection keyword
to function completely. Otherwise only entries from the
one selected table are filtered.
Note that most RMF III tables do not contain common
character data fields, but in this case the DVT and SPG
do.
-Example of VOLSER= :
VOLSER=ABC* is equivalent to coding
DVTVOLSER=ABC*
SPGVOLSER=ABC*
-ASMRMFV now supports keywords up to 14 characters in
length up from 12.
-Support +13 / -13 hour offset or +780 / -780 minutes
GMTOFFSET= value for locations near International Date
Line using Daylight Saving Time such as New Zealand.
-MXG00 record version is now X'05' from X'04' and includes
new range and pattern table statistics for SPG filtering.
New ASMxxxxx variables added to ASM00 dataset.
-Add new items to Section 2 "Terminology" :
Enclave, Report Class, Resource Group, Service Class,
Storage Group, and Workload.
-Former Section 27 "Summary" is now Section 29.
-Update documentation for SPGSTORGROUP=, SPGVOLSER=,
and GMTOFFSET= support:
Section 5 "Input Data Selection Parameters"
Section 8 "Error Handling Parameters"
Section 9 "JCL and SYSIN Parameter Usage"
Section 12 "Messages"
Section 13 "Filtered Records"
Section 15 "Program and IBM Limitations"
Section 25 "Ranges and Patterns"
Section 29 "Summary"
-New documentation Section 27 "GMT Offset Support" better
explains use of the GMTOFFSET= keyword added by MXG
Change 34.133 .
-New documentation Section 28 "Collection of DASD Usage
with RMF Monitor III" details the requirements and setup
of DASD usage measurement in the SPG table.
-New documentation Section 30 "Bibliography" lists IBM
manuals and numbers for the Resource Measurement Facility
(RMF) for z/OS 2.2 back to z/OS 1.10.
-Count information messages and include in final RMFV999I
message with documentation update.
Change 34.190 COSMETIC. INVALID ARGUMENT TO FUNCTION DATEJUL(1900000)
VMACTPMX and a hex dump was printed if the DUE OUT time values are
Aug 10, 2016 all zeros. Had no impact on the output TPMX datasets.
Thanks to Scott Wiig, USBank, USA.
Change 34.189 MXG 34.05 ONLY. INPUT STATEMENT EXCEEDED if more than 3
VMAC119 ADDL HOME ADDR fields exist; Change 34.168 update didn't
Aug 10, 2016 protect more than 3. Since this site had 4, now there
are 4 fields kept, and the more than 4 is protected.
Thanks to Scott Wiig, USBank, USA.
Change 34.188 WPS ONLY, and only with user tailoring. The ARRAY CAI
VMAC7072 statement did not specify $1 to set the array to CHAR;
Aug 10, 2016 if the user dropped variable CAI0, WPS failed because it
couldn't identify the type. While this is an internal
WPS issue that will be resolved, adding $1 to the ARRAY
statement removes the exposure.
Change 34.187 Support for SMF 124 I/O Supervisor Information (z/OS 2.2)
FORMATS DDDDDD DATASET DESCRIPTION
EXTY1241 TY1241 TYPE1241 I/O Supervisor Information
IMAC124 The SM124RETTIME field is an invalid value, with the four
TYPE124 byte packed decimal date value first and then the time,
TYPS124 reversed from the standard SMFSTAMP format with time and
VMAC124 then the date. MXG code detects/corrects either format.
VMXGINIT
Aug 15, 2016
Thanks to Scott Barry, SBBWorks Inc., USA
Change 34.186 Support for Mainview for IP RTIN='34'x, TAC9I220 dataset.
FORMATS DDDDDD DATASET DESCRIPTION
IMACMVIP VMIP34 TAC9I220 PIUTRACE
VMACMVIP (Note that IMACMVIP controls which RTIN values are read.)
Aug 15, 2016
Change 34.185 Unused Change Number.
Change 34.184 New percentage variables added to RMF III ZRBSPG dataset:
VMACRMFV SPGFREEP='PERCENT*OF VOLUME*FREE'
Aug 5, 2016 SPGUSEDP='PERCENT*OF VOLUME*USED'
Change 34.183 Support for CICS/TS 5.4 OPEN BETA.
VMAC110 -New variables added to CICSTRAN DCN=416 DRL=3588.
Aug 7, 2016 but no dictionary records were produced at startup so the
new CICSTRAN fields are unknown, and it is also unknown
if new fields were inserted or appended. Current MXG
code falls thru and uses 5.3 INPUT code for 5.4 records
but that is WRONG if there were INSERTS.
-Type 110 Subtype 2 STID 108 statistics CICTCPIP new vars:
SORTCPIPSMAXPERSIST='MAXIMUM*PERSISTENT*CONNECTIONS'
SORTCPIPSNONPERSIST='NON*PERSISTENT*CONNECTIONS'
SORTOTALCONNS ='TOTAL*CONNECTIONS'
SORNONPATMAXPERSIST='MADE*NON-PERSISTENT*MAXPERSIST*REACHED'
SORNONPATTASKLIMIT ='NEW NON*CONN MADE*TASK LIMIT*EXCEEDED'
SORDISCATTASKLIMIT ='DISCONNECTS*TASK LIMIT*EXCEEDED'
SORDISCATMAXUSES ='DISCONNECTS*MAX USERS*EXCEEDED'
SORCURRBACKLOG ='CURRENT*BACKLOG*Q-DEPTH'
SORCONNSDROPPED ='CONNECTIONS*DROPPED'
SORCONNLASTDROPPED ='DATETIME*LAST*CONNECTION*DROPPED'
SORCURRMAXBACKLOG ='BACKLOG*CURRENTLY*IN USE'
SORREQUESTS ='REQUESTS*PROCESSED'
Change 34.182 MIMPRID=2 Record sample count variable MIMCFNBR=0, but
VMACMIM numerous fields are divided by Sample Count, so their
Aug 3, 2016 divide caused DIVIDE BY ZERO messages and missing values
in those variables. Temporarily, those divides are now
inside a IF MIMCFNGR GT 0 DO group so the numbers are
not set missing, while vendor contact is pursued.
Change 34.181 -Defective BMC CMF type 74 subtype 4 records with SMF744ML
VMAC74 zero (no SCM segments) but with non-zero R744RISC (SCM
Aug 3, 2016 segment expected) caused R744Mxxx SCM variables to be
Aug 11, 2016 INPUT when there was no data. Now, SCM segment is INPUT
only when both R744RISC and SMF744MN are non-zero.
This has been reported as a defect to the vendor; one
record has the triplet populated with no segments and the
next record has the data but the triplet count is zero.
-SCM Variables R744MRBT and R744MWBT are now converted to
bytes from KB and formatted MGBYTES. like other SCM byte
containing variables.
-Missing values notes for R749PCIxxx variables eliminated
by wrapping conditional INPUTs with DO Group and moving
the multiply inside the appropriate DO Group.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Thanks to Paul Volpi, UHC, USA.
Change 34.180 -Omegamon XE ATF datetimestamps are now on the LOCAL zone
VMACATF and variable ATFTU2L, the GMT Offset, is now kept in all
Jul 29, 2016 ATF datasets.
Sep 5, 2016 -To correlate the MXG variables with the CSV files from
Oct 14, 2016 IMS Performance Analyzer, these variables are now kept
in all ATF datasets ATFCORI/ATFCORP/ATFCORT to match the
IBM AESCORID/AESCORPPST/AESCORTIME and variable ATFCREKEY
is concat of AESCREID/AESREOASN/AESRECOMN/ATFCRE.
-Summary variables ATFSUD2N/D2E/D2C from IMSATFD2 into the
IMSATFA0 dataset incorrectly included ITEM CODE 9, the
TOTALs, which were double accounted.
-Oct 14. ATFSTART corrected to local time zone.
Thanks to Robert Gilbert, BNPParibasFortis, FRANCE.
Change 34.179 -Updated CHECKSTN, failed only in JCLTES92 in ASUM113 QA
CHECKSTN test, because PDB.TYPE70PR was presumed to exist; now the
VMXGINIT program verifies it exists, or prints note on the log if
Jul 28, 2016 it can't be executed, and why not.
-The CHECKSTN program was added to the ASUM113 program to
report if duplicates exist in your TYPE70PR data, but you
you can suppress its execution with in your //SYSIN with
%LET MXGSTNCK=NO;
Thanks to Anon, Anon, USA.
Change 34.178 Support for RACF 80 TOKDANAM values CRSGUID, SISMIDDL,
VMAC80A SISCCNO, SISDMPID, SISCOMPY, SISECVT, SISFIRST, SISLAST.
Jul 27, 2016 creates new variables
TOKMCSRGUID/TOKMSISMIDDL/TOKMSISCCNO/TOKMEMPID/
TOKMSISCOMPY/TOKMSISECVT/TOKMSISFIRST/TOKMSISLAST
in dataset TYPE80TK.
Thanks to Michael Oujesky, DTCC, USA.
Change 34.177 Cosmetic. TMON/CICS History file with TMONPROD='D' have
VMACTMO2 LENMONI=0. causing "SHORT RECORD" warnings on the log,
Jul 27, 2016 but these records with TMMDREC='DD' are not the records
wanted, so they are now deleted prior to the length text.
Thanks to Rodger Foreman, Transunion, USA.
Change 34.176 RACFTYPE=6 COMMAND RACFEVNT=19:PERMIT with RACFDLN=12
VMAC80A caused invalid segment skipped message because MXG only
Jul 27, 2016 expected 11.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 34.175 zVM 6.3.16.1 added 4 bytes to PRCPUP segment but MXG did
VMACVMXA not protect correctly, causing PROBABLY DATA LOSS ERROR
Jul 26,2016 on the SAS log. SKIP logic is corrected and the dataset
VXPRCPUP is now output for each segment; previously, only
the last segment was output with the Park/Unpark metrics.
Thanks to Joe Faska, DTCC, USA
Change 34.174 New NOTYPE= parameter lets you specify a list of SMF IDs
VMXGGETM to not be copied. They will be counted in the input but
Jul 26,2016 not in the output counts. Column percentages were added
to the output report. VMXGGETM creates an SMF output file
selecting N records of each SMF ID.
======= Changes thru 34.173 were in MXG 34.05 dated Jul 25, 2016========
Change 34.173 Support for IAM Shorter Record INPUT STATEMENT EXCEEDED.
VMACIAM Change 34.008A in MXG 34.01 added support for V9.2 with
Jul 25, 2016 segment lengths of 292 and 264 bytes for IAMIAINL and
IAMIASTL, but V9.0 has shorter 204/148 segment lengths
that are now detected and protected.
Thanks to Paul Naddeo, Fiserv, USA.
Thanks to Bernie Ethridge, Fiserv, USA.
Change 34.172 See Change 34.216.
Change 34.171 The "IHDR" member for BMC MAINVIEW FOR IP did not contain
IHDRMVIP the MACMVIH macro variable, which also needed to be
VMXGINIT defined in the %GLOBAL statement in VMXGINIT.
Jul 24, 2016
Change 34.170 Support for WebSphere Liberty Batch SMF 120 subtype 12.
EXT12012 Creates new dataset:
VMAC120 dddddd dataset description
VMXGINIT T12012 TYP12012 WAS LIBERTY BATCH
Jul 23, 2016
Change 34.169 The zVM HIS macros _TPRCMFC/_TPRCMFM/_XPRCMFC/_XPRCMFM
VMACVMXA must also create VXMTRPRP to populate the PFXCPT array.
Jul 19, 2016 The _Tdddrrr macros read VMINPUT and the _Xdddrrr macros
read the MWINPUT file to create each VXdddrrr dataset.
Thanks to Scott Barry, SBBWorks Inc., USA
Change 34.168 Support for SMF 119 Subtype 6 Home IP Address section
VMAC119 adds these first three instances to dataset TYP11906:
Jul 16, 2016 IFADDLIN1='IFADDINTFNAME*1'
IFADDLIH1='IFADDINTFHOME*1'
IFADDLIN2='IFADDINTFNAME*2'
IFADDLIH2='IFADDINTFHOME*2'
IFADDLIN3='IFADDINTFNAME*3'
IFADDLIH3='IFADDINTFHOME*3'
Thanks to Wolfgang Kueller, S-Itsolutions, AUSTRIA
Change 34.167 Protect for duplicate SMF70STN values in TYPE70PR data.
ASUM113 ONLY NEEDED IF YOU HAVE LPARs WITH THE SAME SYSTEM NAME.
CHECKSTN
VMAC7072 -New SOLUTION FOR THE ASUM113 PROBLEM:
VMXGINIT The text below shows SMF70STN can not be used to match
Jul 16, 2016 TYPE1131 data with TYPE70PR data, but an alternative to
Jul 25, 2016 identify which TYPE70PR obs belong to this SMF record:
Jul 28, 2016 IF PARTISHN(SMF70PTN)=LPARNUM(SMF70LPN) in TYPE70PR,
that LPAR is the LPAR of this SMF 70 record, which is
then selected to be merged with TYPE1131s. BUT YOU
MUST have BOTH 70s and 113s, and ONLY from one LPAR,
for ASUM113 to create valid PDB.ASUM1131 dataset.
-NO SOLUTION FOR THE ASUM70PR PROBLEM:
If you have duplicate SMF70STN values with CHECKSTN,
there is NO SOLUTION to use ASUM70PR to combine the
multiple LPAR's TYPE70PR data; those duplicates cause
PCTCPUBY to be incorrect (over 100%) with other metrics
also wrong. YOU MUST PROCESS EACH DUPLICATED LPAR's
SMF/RMF data into a SEPARATE PDB FOR EACH OF THE LPARs.
-The new CHECKSTN program can be run to read PDB.TYPE70PR
to produce a report ONLY if duplicate SMF70STN values for
different LPARNAMEs are found in your data:
// EXEC MXGSAS94
//PDB DD DSN=YOUR.TYPE70PR.PDB,DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(CHECKSTN);
-Original Change text, prior to Jul 25:
IN GENERAL, MXG CAN NOT HANDLE MULTIPLE SYSTEM NAMES THAT
ARE FOR UNIQUE SYSTEMS TO BE COMBINED. YOU MUST CREATE
SEPARATE PDB DATA LIBRARIES FOR EACH SYSTEM AND THEY CAN
NOT BE MERGED/COMBINED.
The SMF70STN (LPAR's SYSTEM name) is needed in ASUM113
as it is the only mapping from the z/OS SMF SYSTEM name
to that systems LPARNAME, and must be used there so the
TYPE70PR LPAR utilization variables can be added to the
PDB.ASUM1131 dataset. But RMF data with the same SMF70STN
for different LPARNAMEs has occurred and that corrupts
the PDB.ASUM1131 dataset with incorrect values and
creating multiple LPARNAMEs when there was only one
system's SMF 113 records.
The original solution required you to tell MXG the real
SYSTEM name of those LPARNAMEs that are duplicated, using
the new "exit" MXGSTNFX macro variable:
%LET MXGSTNFX=
%QUOTE( IF LPARNAME='EJQ1' THEN SMF70STN='EJQ1';
ELSE IF LPARNAME='EJQ2' THEN SMF70STN='EJQ2';
);
That statement can be put in "USERID.SOURCLIB(IMACKEEP)"
so it is always used when TYPE70s are processed, or it
can be the top of the SYSIN for a specific job.
But it may not be required with the PARTISHN fix.
Thanks to Jim Poletti, EdJones, USA.
Change 34.166 Support for SMF Type 87 Subtype ENQ/DEQ records.
EXTY8702 Code has been syntax checked, await subtype 2 records to
VMAC87 validate the updated code.
VMXGINIT
Jul 14, 2016
Change 34.165 -RMF Type 74 dataset TYPE74SL variable R748LFBC was input
FORMATS as RB4. but it is a binary value, now input as PIB4.
VMAC74 R748LFBC /*FI CHAN*BIT*ERROR*RATE*/
Jul 13, 2016 -Format MG0748L had value decimal 7 for 10GB Ethernet but
that may have been a guess for the undocumented value
that is now documented as 10x or 16 decimal.
Thanks to Scott Barry, SBBWorks Inc., USA
Change 34.164 Support for IDMS Version 19 (which is INCOMPATIBLE only
VMACIDMS when you install IDMS PTF R084146)! There was no change
Jul 13, 2016 in the V19 SMF record's format, but R084146 changed the
value of SMFHDR to 1900, which caused this error message:
UNKNOWN IDMS RECORD PMHRTYPE=201
FOUND AND SKIPPED. SMFHVER=1900 _N_=2 START COL=25
because MXG had one test for SMFHVER='1800' that needed
to be changed to GE '1800' to read records with the PTF.
Thanks to William Marshall, Ensono, USA.
Change 34.163 Support for SMF Type 120 Subtype 11 Liberty 16.0.0.2 that
EXT120BL created three new datasets:
EXT120BC dddddd dataset description
EXT120BU T120BL TYP120BL Liberty Server Request Network
FORMATS T120BC TYP120BC Liberty Classify Segments
VMAC120 T120BU TYP120BU Liberty User Segments
VMXGINIT For the User segment, SM120BDH is $CHAR32 with $HEX64
Jul 13, 2016 format, and can be decoded in EXT120BU and _KT120BU can
be tailored to add the new variables you created.
Unfortunately, NONE of these new fields have IBM-provided
field names; MXG had to create names beginning SM120Bxx
to be somewhat consistent with previous IBM name choices.
You will have to use the variable label to actually map
back to the marginal documentation of these new records.
-Subtype 11 datasets TYP12011 and TYP120BU both have zero
observations now, with internal record version 2 records.
Thanks to David Follis, IBM, USA
Thanks to Steve McKee, FMR, USA.
Change 34.162 Support for z/OS 2.2 JES2 8-character JOBCLAS8 variable,
BUILD005 which is now added to the JES2 PDB.JOBS and PDB.STEPS
VMAC26J2 datasets, so both the 1-char JOBCLASS and the 8-char
Jul 11, 2016 JOBCLAS8 variables are kept. JOBCLAS8 variable has been
Jul 24, 2016 kept in SMF 30s, from either JES2 or JES3, but TYPE26J2
Jul 29, 2016 is now updated to also keep JOBCLAS8 variable.
Note that JES3 PDB.JOBS and PDB.STEPS, changes variable
JOBCLASS to 8-characters.
Jul 24: UNINIT JOBCLAS8 in SPIN.SPIN26J2 corrected.
Jul 28: JOBCLAS8 added to TYPE26J2 dataset.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 34.161 -Missing values for variables WQTTTIME/WQOPENTI/WQCLOSTI
VMAC116 in dataset MQMQUEUE were created from (only) subtype=2
Jul 11, 2016 records. IBM does NOT provide a GMT offset field in 116,
but MXG heuristically created the offset value in the
subtype 1 (where the WTASINTE interval end can be used
with SMFTIME), but there is no similar end time field
in subtype 2 records. Now, GMT116OFF is created and
retained and used for subtype 2 records. The name was
changed to not impact other SMF records with GMTOFF.
-Missing values were created for variable WTASPRET for
old WTASVER LT 8 records; the /4096 was always executed
but is now only calculated for GE 8 records.
Change 34.160 -VMXGALOC did not check for the valid YYMMDD format in the
VMXGALOC DATEFMT= parameter and could then fail with an invalid
Jul 11, 2016 format error. If you used YYMMDD6 or YYMMDD8 it worked.
-VMXGALOC previously upcased directory names, anticipating
possible name comparisons with upper case source text;
this was fine for Windows, but only worked on Linux if
the directory name was all upper case, because names on
Linux are case-sensitive (i.e., directory A is NOT a).
The upcase was removed, but on Linux you must use the
exact casing of the directory name in your BASEDIR=.
-The BASEDIR= directory must exist, or VMXGALOC will shut
itself down, setting MXGRTRN to ABEND, and printing an
additional message on Linux with the name you supplied to
remind you casing is required there.
Thanks to Joe Varkey, Verisk Analytics, USA.
Change 34.159 If you did not use the ODSTYPE parameter ANALAVAI failed,
ANALAVAI looking for a macro variable created by VMXGODSO, which
Jul 11, 2016 was not executed. Now checks the value of ODSTYPE and if
it is NO or NULL, suppresses VMXGODSC.
Change 34.158 Cosmetic. If you specified BUILDPDB=NO, the display of
UTILBLDP parameters you entered showed the internal default list
Jul 11, 2016 MXGINCL of members to be included. Those members were
NOT included with BUILDPDB=NO, but the displayed list
was not accurate. Now only the USED (i.e., non-blank)
members included are displayed on the log.
Change 34.157 Support for SMF 117 IBM Integration Bus Version 10.0.0.5
VMAC117 which INCOMPATIBLY removed fields in the FLOW segment.
Jul 10, 2016 But MXG didn't keep some identity variables from FLOW in
the other three datasets. Previously known as Websphere
Message Broker.
Thanks to Betty Wong, Bank of America, USA.
Change 34.156 RMF III NOTE: INVALID DATA FOR ASIQSCANxxxxx because some
VMACRMFV variables with PIB informat were input with RB informat.
Jul 10, 2016
Change 34.155 New type 42 subtypes that contain a JOB variable did not
IMACJBCK include the IMACJBCK Job Name Check macro that allows you
VMAC42 to select observations to be output. IMACJBCK has been
Jul 9, 2016 added for these TYPE42xx datasets: 4220/4221/422A/4222/
4223/424A/4224/4225/4227/4237/42VS. In case you were not
aware, these comments document IMACJBCK selection:
SPECIFIC JOB CAN BE SELECTED. WHEN INVOKED, ALL OF THESE
VARIABLES HAVE BEEN READ AND ARE VALID FOR TESTING:
ID JOB READTIME SMFTIME SYSTEM
NOT ALL RECORDS WITH JOB NAME HAVE A JESNR FIELD, BUT
6 25 26 30 32 42 59 91
RECORDS HAVE INPUT JESNR WHEN THIS EXIT IS INVOKED.
FOR SMF 30 RECORDS, NRCPU=0 IF THIS IS A MULTIDD='Y'
RECORD. AND %LET MACJBCK can be used instream.
Thanks to Michael Oujesky, DTCC, USA.
Change 34.154 Support for TYPE41VF new fields in z/OS 2.3:
VMAC41 SMF41LRG='LARGEST*OBJECT EVER*ATTEMPTED'
Jul 9, 2016 SMF41TIM='LAST*SUCCESSFUL*COFDEFIN'
SMF41AAG='CURRENT*ALERTAGE*VALUE'
SMF41YAG='YOUNGEST*TRIMMED*OBJECT*SINCE LAST'
SMF41MAG='YOUNGEST*TRIMMED*OBJECT*SINCE MAXVIRT'
SMF41CAG='AGE*EXECPTIONS*RAISED'
From ICN1494.
Change 34.153 Change 33.031 missed two instances of the LOWCASE()
BLDSMPDB function that should have been converted to UPCASE().
Jul 6, 2016
Thanks to Richard Krueger, Sentry, USA.
Change 34.152 -DOW= filter was not working and all days of the week were
ASMRMFV selected instead.
Jul 5, 2016 -Message RMFV014W ALL DATA SETS BYPASSED was not shown
when applicable.
Thanks to Randy Hewitt, HPE Enterprise Services
Change 34.151 When VMXGSUM finished SYSLAST was not pointing at the
VMXGSUM output dataset created but rather at an intermediate
Jul 1, 2016 dataset created. Now when VMXGSUM is done SYSLAST is set
to the output dataset created so that you can then do a
PROC whatever without a dataset name.
Change 34.150 FORMAT MGCICUU for CICS variable WBRUSAGE has two new
FORMATS values of 4:ATOM and 5:JVMSERVER.
Jun 30, 2016
Thanks to Wayne Bell, UNIGROUP, USA.
Change 34.149 Reserved Change.
Change 34.148 Support for ODM Version 8.8.0.1 SMF type 120 subtype 100
VMAC120 adds variables to TY120100 dataset:
Jun 30, 2016 SM120RULEXETYP='RULESET*ENGINE*TYPE'
SM120RULEXEVER='RULESET*ENGINE*VERSION'
SM120RULEXFBOM='RULESET*IS*BOMS*SUPPORT*ENABLED?'
SM120RULEXFDEB='RULESET*IS*DEBUG*ENABLED?'
SM120RULEXFMON='RULESET*IS*MONITORING*ENABLED?'
SM120RULEXFTRC='RULESET*IS*TRACE*ENABLED?'
While the SMF 120 record is created by WebSphere, the
subtype 100 was given to ODM and is not from WAS.
Thanks to Paul Volpi, UHC, USA.
Change 34.147 BUILDPDB processing of PRINTWAY/INFOPRINT product SMF 6
BUILD005 records that have no matching 30s nor 26s were left in
VGETJESN SPIN.SPIN6 until SPINCNT expired when they were finally
VMAC6 output to PDB.PRINT dataset. There are two types of
Jun 28, 2016 PRINTWAY records. MXG decodes them setting variables
BASIC: TYPETASK/SUBSYS/SUBSYS6 are set to 'TCP'.
EXTENDED: TYPETASK/SUBSYS/SUBSYS6 are set to 'TCPE'
and the logic in BUILDPDB outputs all 'TCP ' records to
PDB.PRINT, while 'TCPE' records that didn't match today
are held in SPIN.SPIN6 to match the other records from
those jobs.
Trivia: JCTJOBID for BASIC contains PSnnnnnn which
is not documented and is different than PSFnnnnn for
type 6 records created by PDF.
Thanks to Paul Maradin, HP Advanced Solutions, USA.
Thanks to Grayg Mitrou, HP Advanced Solutions, USA.
Change 34.146 FORMATS MGSRDFC/M/G/S decode SRDCONST/MODE/GROUP/CONSI.
FORMATS
VMACSRDF
Jun 28, 2016
Thanks to Joe Faska, DTCC, USA
Change 34.145 -IFCID 106 new variables QWPBSQLL and QWP4DDLTO parms are
VMAC102 input and kept in dataset T102S106.
VMACDB2H -QWHSRELN value could be truncated and print 10.0999999.
Jun 27, 2016 Now it is forced to print as 10.1.
Jul 3, 2016 -QWPRRENAMETABLE decoded from QWP4MISB and kept.
Thanks to Scott Barry, SBBWorks Inc., USA
Thanks to Lai Fai Wong, Bank of America, USA.
======= Changes thru 34.144 were in MXG 34.04 dated Jul 25, 2016========
Change 34.144 -RMFINTRV message MSU variables are UNINITIALIZED has no
VMXGRMFI actual impact; LENGTH was defined in R72HOUR but those
VMXGSUM variables are not initialized until the MERGE RMF70HOUR.
Jun 23, 2016 Relocated the LENGTH statement to eliminate messages.
-VMXGSUM with NOSORT=YES printed note that MXGSUM2 could
not be deleted, but it doesn't exist with that option, so
also no actual impact. Note no longer printed.
Change 34.143 ZVPS 4.2.3 variable CPUUTIL in dataset XAMSYS was likely
VMACXAM zero because new SYTCUV segment also input CPUUTIL for
Jun 21, 2016 each CPU and the last value was kept in XAMSYS. Now,
from SUBSUM segment is renamed at input and renamed back
at XAMSYS output.
Thanks to Douglas C. Walter, CitiCorp, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 34.142 Change 34.010 did not set the lengths for the new
VMXGRMFI variables created and could result in multiple length
Jun 21, 2016 error messages when running TRNDRMFI.
Change 34.141 WARNING: MEMNAME HAS DIFFERENT LENGTHS is eliminated.
VMXGSRCH
Jun 20, 2016
Change 34.140 Housekeeping. BUILD001 intentionally leaves all of the
ANALID CICS Statistics Data Sets in //WORK after the SMF DATA
ASUMTAPE step, so they are available to be copied by EXPDBOUT if
BUIL3005 desired, and so that CICINTRV can be created in BUILD004,
BUILD005 by VMXGCICI, but now those datasets are deleted after the
PDBAUDIT PDB.CICINTRV has been created. Other members similarly
SPUNJOBS left unneeded datasets in //WORK that are deleted now, to
VMAC113 minimize the required disk space.
VMAC73
VMAC74
VMACDB2
VMXGCICI
Jun 19, 2016
Change 34.139 The highest memory usage in BUILDPDB was in the VMXGSUM
BUILD005 step that created INTVSIOS, but that dataset is already
BUIL3005 sorted, so the option to use CLASSNWAY is suppressed and
Jun 17, 2016 NOSORT=YES is specified to bypass the sort and PROC MEANS
is executed with a BY statement which reduced memory from
242MB to 195MB, and now the DATA step is largest, also
requiring 195MB for this tailored BUILDPDB execution.
Change 34.138 Cosmetic. Variable OVOLSER was 20 bytes ending with a
TYPETMS5 period in byte 20 unless Site Tailoring for Multiple CA/1
Jun 16, 2016 catalogs was used (Change 27.111). Period is now gone.
Thanks to Doug Medland, IBM Global Services, CANADA.
Change 34.137 Major revision to VMXGSUM that could save CPU time.
ASUMCACH This change creates a new parameter, CLASSNWAY with the
VMXGINIT default value of &MXGSUMCLASS, which itself has default
VMXGSUM value of blank, so that you can enable the new logic with
Jun 17, 2016 only %LET MXGSUMCLASS=YES; in //SYSIN, which changes
the current summarization logic to use the CLASS/NWAY
feature of PROC MEANS, instead of the original default.
-The default VMXGSUM logic can be a four step process with
an optional DATA step created (if INCODE=, NORMx=, or
INTERVAL=x arguments are used) to feed the PROC SORT that
feeds the PROC MEANS which may be followed by another
optional DATA step (if NORMx= or OUTCODE= are used).
-The MXGSUMCLASS=YES revision alters the default logic to
remove the SORT and instead invokes the CLASS and NWAY
options on the PROC MEANS, which can greatly reduce the
amount of CPU time consumed since the SORT is eliminated
(in one simple test the zOS CPU time went from 68 seconds
to 28 seconds!
-But, it is VERY possible for the use of CLASS to require
a significant increase in the virtual storage (REGION)
required, in return for reduced CPU time.
-The original MXG design was required because when first
created, virtual memory was an extremely limited resource
and the algorithm minimized memory required. But now,
with memory no longer so restricted nor expensive, using
MXGSUMCLASS option lets test and observe the trade off
to see which options is of benefit to your invocation.
-Executing MXG on z/OS using MXGSUMCLASS=YES:
It is possible you could save some CPU time but the
cost is an increase in high memory usage - more than
doubled in some tests and the CPU time saved will be
primarily in ASUM* TRND* ANAL* GRAF* members run after
BUILDPDB (BUILD005 only has 3 VMXGSUMs, but VMXGCICI
for PDB.CICINTRV has many that may or may not be helped.)
MXGSUMCLASS=YES did fail once because the utility files
used filled the //WORK space, so that specific case in
ASUMCACH has disabled MXGSUMCLASS to circumvent.
The amount of CPU time saved is a complex function of
the complexity of the data - the number of OBS, BY
groups, and count of intersects - each impact memory
utilization so that you must test across several day's
data since the results can vary from day to day as the
complexity changes.
-%LET MXGSUMCLASS=YES; applies to ALL VMXGSUM invocations
after that statement in that job step. You can change any
VMXGSUM invocation after that to revert to the original
logic by adding CLASSNWAY=NO to that VMXGSUM invocation.
-Executing on ASCII thus far has not shown a significant
benefit with MXGSUMCLASS but 'your mileage may vary'.
-These are test results from zOS running SAS 9.3 and using
UTILBLDP with inclusion of many of the ASUMxxxx members,
all of which are VMXGSUM invocations:
%UTILBLDP(USERADD=42 6156,OUTFILE=INSTREAM,BUILDDB=YES);
%INCLUDE INSTREAM;
JOB CPU % CPU CPU
CPU % CHG READING READING PROCESSING
TEST TIME CPU DATA DATA DATA
BY USED 1:17:53.66 . 0:46:28.06 59.65 0:31:25.60
CLASS USED 1:10:19.36 9.72 0:47:12.14 67.12 0:23:07.22
% CPU % CPU
PROCESSING CHANGE TOTAL % CHANGE TOTAL
TEST DATA PROCESSING EXCP EXCP IO TIME
BY USED 40.35 . 1478119 . 0:28:39.67
CLASS USED 32.88 26.43 1199259 18.87 0:17:11.95
HIGH % CHANGE
% CHANGE MEMORY HIGH
TEST IO TIME USED MEMORY
BY USED . 280M .
CLASS USED 39.99 242M 13.38
And here are some further tests comparing BUILDPDB on zOS
and Windows 10. The same input data was used in both
but the DB2/CICS data was compressed so on zOS the CICS
SMF INFILE exit was used but on Windows more CPU time was
consumed to read the data. zOS is running SAS 9.3 and
Win 10 is running 9.4.
Test BUILDPDB Only zOS NWAY zOS BY Win NWAY Win BY
Data step elapsed 0:10:35 0:10:59 0:07:07 0:07:03
Data step CPU 0:08:51 0:08:53 0:07:09 0:07:02
Data Step MAX K Memory 173496 173496 320388 320388
Job elapsed Time 0:14:30 0:14:54 0:08:35 0:08:32
Job CPU 0:11:25 0:11:30 0:08:13 0:08:08
Job MAX K High 173496 173500 449928 449928
Step with HIGH memory DATA STEP DATA STEP SORT SORT
DB2ACCTP DB2ACCTP
Test with ASUMs Win 10 NWAY Win 10 BY
Data step elapsed 0:07:28 0:07:08
Data step CPU 0:07:15 0:07:09
Data Step MAX K Memory 320388 320388
Job elapsed Time 0:10:02 0:10:58
Job CPU 0:09:24 0:09:54
Job MAX K High 727880 449928
Step with HIGH memory ASUMCACH SORT
DB2ACCTP
DB2ACCTP
TECHNOTE: Using MXGSUMCLASS=YES on zOS
Thus far this applies only to zOS. There are no known exposures on
ASCII. Members that have failed:
BUILD005/BUIL3005 - automatically suppressed on zOS
ASUMCACH - automatically suppressed on zOS
ASUMCICS
ASUMCICX
ASUMDB2A
ASUMDB2P
There are two failure modes.
1) UTILITY files fill up work and cannot expand
2) Memory failures as memory expands
The problems will occur if you have many OBS (at least tens of
millions possibly hundreds) and many BY groups which create a large
number of intersections.
If you have a failure, bring the member that failed into your
USERID.SOURCLIB.
The simplest change is to add CLASSNWAY=NO to the parameter list of
the VMXGSUM invocation. That will revert to the original logic for
VMXGSUM of DATA STEP/SORT/MEANS/DATA STEP but also means you will
not be saving any time.
A more complex option is to modify the parameters. For each BY
group MEANS must build a counter for each of the variables in any
of the SUM MEANS MAX etc parameters. That can quickly add up to a
lot of space. So you can either reduce the complexity by reducing
the variables in the BY list or by reducing the number of variables
being SUMMed MEAned MAXed etc.
An example using ASUMCICX (only a partial copy):
MACRO _BSUCICS APPLID OPERATOR USER TERMINAL STRTTIME TRANNAME
SYSTEM SHIFT %
Are OPERATOR USER TERMINAL really necessary in your summarized
data? In many cases TERMINAL is an IP address that is largely
meaningless. OPERATOR and USER may be the same. Reducing the
number of variables in the BY list can help.
%VMXGSUM(INVOKEBY=ASUMCICX,
KEEPALL=&KEEPALL,
INDATA= _LSUUOW ,
OUTDATA= _LSUCICS ,
DSNLABEL=SUCICS: CICSTRAN &SUCIINTV SUMMARY,
DATETIME=STRTTIME,
SUMBY= _BSUCICS ,
DURATM =INTERVAL,
INTERVAL=&SUCIINTV,
SYNC59=NO,
NEWSHIFT=Y,
MAX= RESPMAX,
SUM= DSPDIOCN DSPDIOTM FCAMCNT IRESPTM RESPBKT1-RESPBKT8
TASCPUTM TRMCHRCN WTDISPCN WTDISPTM WTFCIOCN WTFCIOTM
WTIRIOCN WTIRIOTM WTJCIOCN WTJCIOTM WTRLIOCN WTRLIOTM
WTTDIOCN WTTDIOTM WTTSIOCN WTTSIOTM SSQELAP CPUTM
CLASS3TM CLASS3WT DB2CONCN DB2CONTM DB2IDLE DB2RDYCN
DB2RDYTM DB2REQCT DB2SRBTM DB2TCBTM DB2TRAN DB2WAICN
DB2WAITM MROTRAN,
In the SUM= list do any of your reports depend on all of these
variables? If not eliminate those variables. Do any of your CICS
transactions use DB2? If not eliminate the DB2 variables.
The key to getting the advantage of reduced CPU and elapsed time on
zOS with these members is reducing the complexity.
Change 34.136 Support for up to six USERCHAR fields, and revisions
UTILEXCL to support USER fields that are in the middle of the
IMACIC3U segment, which were not correctly handled.
IMACIC4U
IMACIC5U
IMACIC6U
IMACIC3D
IMACIC4D
IMACIC5D
IMACIC6D
Jun 8, 2016
Change 34.135 Additional Q8ST variables are INPUT if they exist:
VMACDB2 Q8STINSC='INSERT*STATEMENTS*SENT TO*IDAA FROM DB2'
Jun 7, 2016 Q8STUPDC='UPDATE*STATEMENTS*SENT TO*IDAA FROM DB2'
Q8STDELC='DELETE*STATEMENTS*SENT TO*IDAA FROM DB2'
Q8STDRPC='DROP*STATEMENTS*SENT TO*IDAA FROM DB2'
Q8STCRTC='CREATE*STATEMENTS*SENT TO*IDAA FROM DB2'
Q8STCMTC='COMMIT*STATEMENTS*SENT TO*IDAA FROM DB2'
Q8STRBKC='ROLLBACK*STATEMENTS*SENT TO*IDAA FROM DB2'
Q8STOPNC='OPEN*STATEMENTS*SENT TO*IDAA FROM DB2'
Change 34.134 VMXGCOPY copies from multiple inputted SAS Data Libraries
VMXGCOPY to one output Data Library with member selection, etc.
Jun 7, 2016 If your parameters were lower case nothing was found to
copy since the values passed back for LIBNAME and MEMNAME
are uppercase and the compare was always false. To make
it worse it also failed with a bad macro variable name
reference because the variable was not constructed when
nothing was found.
Thanks to Tim Hare, Southwood Shared Resource Center, USA.
Change 34.133 -Support for GMT Offset in MINTIME Sample Set filtering,
ASMRMFV improved MXG00 table data, and other minor enhancements.
ADOCRMFV -The GMT offset feature scales RMF MONITOR III Sample Set
JCLCRMFV begin (SSHTIBEG) and end (SSHTIEND) timestamps to a
JCLDRMFV common user specified GMT time offset ranging from -12 to
JCLRMFV +12 hours or -720 minutes to +720 minutes.
VMACRMFV IMPORTANT: This support does NOT modify any timestamps
Jun 11, 2016 in the output RMFBSAM file. The SSHTIBEG and SSHTIEND
time stamps are modified temporarily ONLY during the
FROMDATE=/TODATE= FROMDATE=/TODATE= filter processing.
-The purpose of the support is to allow an installation to
input RMF III data sets from different time zones and
build a PDB with data relative to a specific time zone.
-Although GMT (Greenwich Mean Time) is technically an
obsolete term replaced by the modern UTC (Coordinated
Universal Time) term, GMT still appears extensively in
RMF documentation and within MXG itself. So the term GMT
is still used for historical consistency.
-The new ASMRMFV keyword to specify a GMT offset is
GMTOFFSET=. Aliases are GMTOFF=, GMT=, GMTOFFSET,
GMTOFF, and GMT.
-When the '=' is missing then GMTOFFSET=0 is implied. The
'=' is required to specify a non-zero GMT offset value.
-Any of the following formats are supported for GMTOFFSET=
(and aliases GMTOFF=,GMT=) :
h -h +h
hh -hh +hh
hH -hH +hH
hhH -hhH +hhH
where h ranges from 0 to 9 and hh from 00 to 12. Values
over 12 are flagged as errors and will abend ASMRMFV. An
h or hh value of zero means scale timestamps to GMT time.
Unsigned h or hh values imply a positive GMT offset. A
'-' sign is required to specify a negative offset.
The capital 'H' suffix is optional and is provided just
to make the unit measure clear if desired.
-Positive GMT offsets are for time zones east of GMT up to
the International Date Line including most (if not all)
of Europe, Africa, Asia, Australia, and many island
groups.
-Negative GMT offsets are for time zones west of GMT up to
the International Date Line including North and South
America and some island groups.
-A few time zones have GMT offsets that are not integer
hour values such as India, some Australian zones, and
some island groups. For example, India is GMT+5:30.
-For the support of these non-integer offset time zones
any of the following formats are supported for GMTOFFSET=
(and aliases GMTOFF=, GMT=) in minutes:
mM -mM +mM
mmM -mmM +mmM
mmmM -mmmM +mmmM
where m ranges from 0 to 9, mm from 00 to 99, and mmm
from 000 to 720 (12 hours). Values over 720 are flagged
as errors and will abend ASMRMFV. An m, mm, or mmm value
of zero means scale timestamps to GMT time. Unsigned m,
mm, or mmm values imply a positive GMT offset. A '-'
sign is required to specify a negative offset.
Any user can still specify this form even for integer
hour offsets by converting the hours x 60 to get minutes.
For example, GMT=-4 and GMT=-240M are equivalent.
The 'M' suffix is REQUIRED for a GMT minutes offset. If
omitted the value will be handled as an hour value
instead.
-NOTE: When using GMTOFFSET= the FROMDATE=/TODATE= and
FROMTIME=/TOTIME= filter values MUST be coded based on
the REQUESTED offset time zone. This is NOT necessarily
the Local Time for the time zone where ASMRMFV is
executing.
-GMTOFFSET= processing follows these steps for each RMF
Monitor III MINTIME Sample Set:
1) The Sample Set begin (SSHTIBEG) and end (SSHTIEND)
timestamps are first converted to GMT time using the
SSHSTDIF GMT offset field from the Sample Set Header
(SSH) present for each Sample Set. Then they are set
into temporary timestamp fields for filtering.
2) If GMTOFFSET=0 is in effect, then no further changes
are applied to the temporary timestamps and filtering
continues with the timestamps in GMT Time. They are
compared to the FROMDATE=/TODATE= and FROMTIME=/TOTIME=
option settings.
3) If GMTOFFSET= is non-zero then the temporary timestamp
fields are further altered with the negative or positive
offset value. These altered timestamps are referred to
as Adjusted Time in ASMRMFV documentation and messages.
They are compared to the FROMDATE=/TODATE= and
FROMTIME=/TOTIME= option settings.
4) As noted earlier any selected Sample Set tables are
output to the RMFBSAM file with their original timestamps
unchanged.
-Examples of GMTOFFSET= use follow. In all cases it is an
installation responsibility to transfer the multi time
zone RMF Monitor III data sets to the ASMRMFV execution
site prior to processing. The RMF provided ERBV2S and
ERBS2V Clists are one method to create and retrieve a
sequential copy of an RMF Monitor III VSAM data set.
-Example 1: A London based company wants build an RMF III
PDB for yesterday with RMF III VSAM data sets input from
several different time zones in Europe and Asia for their
peak hours of 09:00 to 15:00. They want to see what
other activity is occurring elsewhere during this time.
ASMRMFV statements:
FROMDATE=YESTERDAY TODATE=YESTERDAY
FROMTIME=0900 TOTIME=1500 GMT
-Example 2: A New York corporation wants build an RMF III
PDB for two days ago in June with RMF III VSAM data sets
input from several different time zones in the United
States for the prime time hours of 08:00 to 17:00. They
need to see if some moving some workloads might result in
fewer delays. They are using Daylight Saving Time and
their time zone is at GMT=-4.
ASMRMFV statements:
FROMDATE=*-2 TODATE=*-2
FROMTIME=0800 TOTIME=1700 GMTOFF=-4
-NOTE: For sites using GMTOFFSET= processing and Daylight
Saving Time the GMT offset changes during the fall
transition to Standard Time and the GMT offset increases
by 1 hour. In the example above it becomes GMTOFF=-5.
One advantage of using pure GMT offsets is that time
changes such as this are not an issue because RMF III
keeps the GMT offset for each Sample Set. RMF III does
not have any awareness of Daylight Saving Time and so it
is a user responsibility to code GMTOFFSET= correctly
before and after a time change.
-Example 3: An India enterprise wants build an RMF III PDB
for the last five days with RMF III VSAM data sets input
from several different time zones in Asia and Europe for
their early morning hours of midnight to 07:00. India
Time is at GMT+05:30 hours. They want to see if some
workload balancing might be possible across multiple data
centers to reducing processing delays or take advantage
of available CPU cycles.
ASMRMFV statements:
FROMDATE=*-5 TODATE=*-1 WINDOW
FROMTIME=0000 TOTIME=0700 GMT=+330M
-Most ASMRMFV timestamp messages are revised or added to
now display the GMT time when GMTOFFSET is used. These
include:
RMFV001I Current Time and Last IPL Time
RMFV008I Input data set Last Open Time
RMFV012I Sample Set Found Begin and End Times
RMFV013I Sample Set Selected Begin and End Times
RMFV017I RMF and z/OS Version Found Time
RMFV023W Sample Set Date/Time - Service Policy missing
RMFV032E Sample Set Date/Time - Program service failure
RMFV039I Sample Set Date/Time - SHOWSAMP option info
RMFV070* Sample Set Date/Time - Service Class Find error
RMFV071* Sample Set Date/Time - Report Class Find error
RMFV072* Sample Set Date/Time - Workload Name Find error
RMFV073* Sample Set Date/Time - Resource Group Find error
RMFV076I Sample Set Date/Time - SHOWASI option info
RMFV078I Sample Set Date/Time - Prior Service Policy use
(* = E, W, or I depending on error settings)
-In addition all above messages (except RMFV001I and
RMFV008I) display the Adjusted Time if GMTOFFSET is
non-zero. So it is possible to get up to three messages
for each timestamp display when GMTOFFSET= is in effect:
Local Time, GMT Time, and Adjusted Time. These provide
an audit trail and verify program operation is correct.
-New parameter SHOWGMT (aliases SHGMT, SG) will display
GMT versions of timestamp messages even if GMTOFFSET is
not in effect. SHOWGMT is forced if GMTOFFSET is in
effect. Updated message RMFV037I displays SHOWGMT
setting.
-New parameter NOSHOWGMT (aliases NOSHGMT, NOSG) will
suppress GMT versions of timestamp messages. NOSHOWGMT
is the default so there should be little need to code
this option.
-New parameter SHOWASI (alias SHASI) displays some ASI
entry data when selected. This is intended primarily for
debugging as it will produce voluminous output in the
ASMRMFV log. This function formerly required a
re-assembly and re-link to be enabled. Updated RMFV037I
message shows status of this setting.
-New parameter NOSHOWASI (alias NOSHASI) suppresses ASI
data display. This is the default and should not need to
be coded.
-New RMFV006I message shows GMTOFFSET status and offset
value.
-New RMFV014I message displays when all tables have been
excluded due to filtering that were not originally
excluded by an entire data set bypass condition. For
example, this can occur when using range and/or pattern
filters to select specific jobs that did not run in the
selected time range.
-New aliases added SHSAMP for SHOWSAMP and NOSHSAMP for
NOSHOWSAMP (default)
-New aliases added SHMATCH for SHOWMATCH and NOSHMATCH for
NOSHOWMATCH (default).
-New aliases added SHZERO for SHOWZERO (default) and
NOSHZERO for NOSHOWZERO.
-New aliases added SHALL for SHOWALL and NOSHALL for
NOSHOWALL (default).
-Add sections to MXG00 ASMRMFV Initialization table for
table capacities, table sizes, buffer/workarea settings,
multiple filter logic options, filter options, GMT offset
settings, report options, output options, error options,
and table selection options. Updated BUILD00 subroutine.
Nearly all ASMRMFV parameter options are now saved except
contents of range and pattern tables. These fields
become variables in the ZRBASM data set in the MXG PDB.
-Raise MXG00 record version to X'04' from X'03'.
-Code path improvements for SHOWTS and STCKCONV
subroutines.
-Some data set names and volume serial numbers were
incorrect in the MXG00 ASMRMFV Initialization table.
-The CAT and CPC tables were not included in example
discussions in the JCLRMFV, JCLCRMFV, and JCLCRMFV
members.
-Documentation updates to:
Section 2 Terminology (Timestamps)
Section 5 Input Data Selection Parameters
Section 6 Report Control Parameters
Section 12 Messages
Section 13 Filtered Records
Section 15 Program and IBM Limitations
Section 26 ASMRMFV and MXG PDB Data Relationships
Section 27 Summary
Thanks to MP Welch, Bank of America, USA.
Change 34.132 Unused.
Change 34.131 ERROR: Invalid date constant " .":d with BLDSMPDB was
BLDSMPDB caused by a typo, the lack of an underscore on the old
Jun 1, 2016 style _TODAY macro, causing LASTWEEK to be miscalculated.
Impacts MONTHLY job, but FORCEDAY=01JUN16 circumvents.
Thanks to Jim Hayes, Huntington Bank, USA.
Change 34.130 New variable GEICSARE, Unallocated Common Area Left, is
VMACRMFV now input and kept in RMF III dataset ZRBGEI, formatted
May 31, 2016 with MGBYTES.
Thanks to Dave Cogar, Wells Fargo, USA.
Change 34.129 Variable R723MCPG, the number of periods in this service
VMAC7072 class, is now kept in dataset TYPE72PD.
May 30, 2016
Thanks to Jim S. Horne, Lowe's Companies, Inc., USA.
Change 34.128 Zen CSM records ZOSAPOOL dataset new ZOSA_POOL_TYPE is
VMACZOSA 'E' for ECSA Pool or 'D' for DataSpace Pool.
May 27, 2016
Thanks to Jerome Vitner, Experian, USA.
Change 34.127 If only one variable was being examined, a NOT SORTED
ANALRANK error could occur due to an insufficiently specified
May 24, 2016 BY list.
Thanks to Tom MacCabe, Dominion Resources Services, Inc., USA.
Change 34.126 TYPETMS5 observations for tapes created by old versions
VMACTMS5 of DFDSS contained zeros for BLKSIZE but PGM='ADRDSSU'
May 23, 2016 tapes are always BLKSIZE=65520, so MXG sets that value
for these old tapes.
Thanks to Jim Agrippe, Cleveland Clinic, USA.
Change 34.125 Documentation only. Mainview for IMS IMF/CIMS maintenance
VMACCIMS PUT 1502 PTFs BQI2154, BPK2892 were supposed to correct
May 23, 2016 corrects zIIP CPU times where zIIP Eligible time TRXZIOCP
was greater than the CPU time on CP, TRXZONCP, but does
not appear to correct the problem as of this date.
Change 34.124 MXG Format MGD044K for DB2 Trace Dataset T102S044 updated
FORMATS with new values.
May 18, 2016
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 34.123 -Support for IFCID 365 populates T102S365 dataset.
VMAC102 -Support for IFCID 376 corrects QW0376VN so only QW0376VL
May 18, 2016 bytes are input. Variable QW0376TS is an invalid 8-byte
Jun 1, 2016 value: '1982A5641F29CA5A'x and '0E5F1F1D09F14040'x
are not valid TODSTAMP nor 10-byte DB2 time fields.
Thanks to Lai Fai Wong, Bank of America, USA.
Change 34.122 ANALCSQC counts concurrent MQ Applications from SYSLOG in
ANALCSQX this tailored use of TYPSSYSL that selects only logon
May 17, 2016 +CSQX500I and logoff +CSQX501I MSGID to create a session
event observation, which ANALCNCR then processes to count
and plot concurrent sessions for each quarter hour.
Thanks to Tom M. Kane, AT&T, USA.
Change 34.121 Formal support for SYSLOG (including multi-line messages)
EXSYSLOG with all MXG dataset tokens, to replace SYSLOG member, in
FORMATS particular, so EXSYSLOG/_ESYSLOG dataset exit exists so
IMACSYSL only desired MSGID are output. TYPESYSL exists but only
TYPESYSL creates raw data in WORK.SYSLOG; TYPSSYSL must be used as
TYPSSYSL it invokes the _SSYSLOG sort macro that combines multi
VMACSYSL messages into one observation and writes out PDB.SYSLOG.
VMXGINIT
May 17, 2016
Change 34.120 ERROR: SPIN.SPINPDBAUDIT.DATA HAS TOO LONG A MEMBER NAME
PDBAUDIT occurs if your //SPIN DD was created with SAS Version 6,
May 17, 2016 which allowed only 8-character SAS dataset/member names.
You need to create a new VERSION 9 format data library by
copying the current //SPIN DD data to a NEW V9 SPIN DSN:
// EXEC MXGSASV9
//SPIN DD DSN=YOUR.OLD.SPIN,DISP=SHR
//SPINNEW DD DSN=YOUR.NEW.SPIN,DISP=(,CATLG),SPACE...
//SYSIN DD *
PROC COPY IN=SPIN OUT=SPINNEW MT=DATA;
and then delete OLD and then rename NEW to OLD.
You probably also need to examine all of your re-used SAS
data libraries (PDB,MON,TUE,...WEEK,MONTH, i.e., those
with DISP=OLD that are re-written each time), to see if
any were also created with SAS V6, with the output of
PROC CONTENTS DATA=PDB._ALL_ NODS DETAILS
to see what ENGINE created each of those data libraries.
While MXG has had long dataset names for some time, this
is the first instance in the "mainline" SMF processing
code members used in BUILDPDB, and was introduced in MXG
33.07 in the new PDBAUDIT report of your PDB libraries.
(SAS 6.08 dates back to 1992, so this site's
SPIN dataset has stood the test of time!!)
Thanks to Jeanne Vetter, Dell Services, USA.
Change 34.119 There is a known SAS exposure that can cause a CPU loop
VMXGCNFG after a program has finished, in SAS termination, if you
May 17, 2016 try to dynamically allocate a DD that was already in JCL.
If you use the CONFIG= CONFIMXG option as your MXG JCL
//MXGSTEP EXEC SAS,CONFIG=MXG.SOURCLIB(CONFIMXG)
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),
it does dynamically allocate the SOURCLIB and LIBRARY DD,
but the restriction was only documented. This change
prevents the loop by testing for their allocation, and
causing the job to USER ABEND 777 before the SAS program
actually starts.
Change 34.118 MXG created variable CPUZIPTM_CPUIFATM_INST was wrong and
VMAC30 usually negative because the three component variables
May 15, 2016 should have been added to get the IFA/ZIP Instructions.
Thanks to Paul Volpi, UHC, USA.
Change 34.117 CPU and SU_SEC values for z13 processors added to the
GRAFWRKX formats so that you can model these newer systems with
May 12, 2016 your existing data. This is a very simplistic model
that will only convert the CPU time from the current
model to whatever model you specify with NEWMODEL=.
Change 34.116 Enhancement for RMM/EDGHSKP/TYPEEDGR adds new variables
VMACEDGR SYSTEM and EDGRTIME to all datasets, retained from the
May 13, 2016 Header record.
Thanks to Linda Berkeley, USPS, USA.
Change 34.115 Variable DCDTIMEC, Data Set Create Time in DCOLDSET is
VMACDCOL only populated if
May 11, 2016 - the dataset is on an EAV volume (more than 65K CYL)
- the volume is the first volume for the dataset
(DCDTIMEC is zero in the DSCB for other volumes)
- for non-VSAM, EATTR=OPT must be specified (JCL or
Data Class), because EATTR=NO is the default for
non-VSAM, EATTR=OPT is the default for VSAM.
The DCDTIMEC comes from the FORMAT 9 DSCB control block
(in the VTOC), created for EAS-eligible datasets on EAV
that have EATTR=OPT, except that these datasets
do not have FORMAT 8/9 DSCBs.
Thanks to Donna Roff, FISA NYC GOV, USA.
======= Changes thru 34.114 were in MXG 34.03 dated May 10, 2016========
Change 34.114 Enhancement to TCP analysis %ANALTCP program that allows
ANALTCP selection by user name remote IP address for FTP, API, or
ANAL119 Telnet datasets from SMF 118 (TCP) or 119.
Jun 8, 2016
Thanks to Dave Ireland, USDA, USA.
Change 34.113 Support for COMPUWARE Hiperstation SIEM User SMF record.
EXSIEM01 Also called Hiperstation Application Audit.
EXSIEM02 New datasets are created from these subtypes:
EXSIEM03 dddddd dataset description
IMACSIEM SIEM01 SIEM3270 SIEM 3270 Session 01
TYPESIEM SIEMA1 SIME3270A SIEM 3270 Screen Lines 01
TYPSSIEM SIEM02 SIEMTCP SIEM TCP 02
VMACSIEM SIEM03 SIEMMQ SIEM MQ 03
May 9, 2016 Currently, only subtype 1 is created and supported.
May 19, 2016 -May 19. Variable SIEMLPAR NOT FOUND corrected.
Change 34.112 MXG 34.01,34.02. DCOLLECT dataset DCOLBKUP variables
VMACDCOL UBDSIZE and UBRECSP were incorrectly multiplied by the
May 9, 2016 original *1024 that should have been removed when the
tests for UBFLAG4 was added in Change 34.042.
Thanks to Thomas Peiper, TIETO SWEDEN AB, SWEDEN.
Change 34.111 New TYPE72PD, RMF WLM POLICY DEFINITIONS dataset is now
EXTY72PD created for every service and reporting class.
IMAC7072
VMAC7072
VMXGINIT
May 6, 2016
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 34.110 Parameter INCODE= added so you can add selection SAS
ANALUOW code on all variables and not just time and transaction
May 3, 2016 name. Logic added to detect that no data was found and
terminate ANALUOW
Thanks to Dave Ireland, USDA, USA.
Change 34.109 DB2 Package Dataset DB2ACCTP does not contain QX......
VMACDB2 variables. QX variables exist only in DB2ACCT and the
May 4, 2016 DB2STATB datasets (initially from DB2STAT1).
Thanks to Jane S. Stock, USPS, USA.
Change 34.108 DB2 Simulated Buffer Pool DB2STSBP/DB2STATS variables
VMACDB2 QBSPIUS, QBSPSUS (current) and QBSPHSU, QBSDPHUS (hwmark
May 3, 2016 pages) should not have been deaccumulated.
Variable QBSPREADS is now correctly deaccumulated.
And variable QBSTRHS in DB2STATB is now deaccumulated.
Thanks to Lai Fai Wong, Bank of America, USA.
Change 34.107 -A typo, SYSTYPE instead of &SYSTYPE caused unresolved
ANAL9914 macro because no observations were created. The correct
May 3, 2016 syntax for the report for SYSTEM=SYS1 and SYSTYPE=Z13 is
May 4, 2016 %ANAL9914(SYSTEM=SYS1,SYSTYPE=Z13);
May 5, 2016 -No longer restricted to a single system unless you use
the SYSTEM= parameter; by default reports on all SYSTEMS.
Cleans up after itself and produces NOTES to tell you
when there is a problem.
Thanks to Luis A. Mendoza, TRANSUNION, USA.
Change 34.106 z13 in SMT_MODE with SMT_NUM=2, variable NRZIPCPU, count
VMAC7072 of zIIP engines in the CEC, can be wrong in datasets
VMXG70PR PDB.TYPE70, PDB.ASUMCELP, and PDB.ASUMCEC, but is correct
Apr 30, 2016 in PDB.TYPE70PR, and variable ZIPCPUS, zIIPs online to an
LPAR, was also correct in those datasets.
-Note that IBM's CPC Report counts ONLINE ZIPs per LPAR,
but MXG's ZIPCPUS='ONLINE*AND*NOT*PARKED'
-Do NOT use the PDB.ASUM70PR nor PDB.ASUM70LP datasets;
they are by SYSTEM and thus selection is required, and
they don't have correct data on system's whose SMF data
was not read; those LPARs are in PDB.ASUMCELP.
Thanks to Elie Sawaya, Royal Bank of Canada, CANADA.
Change 34.105 Support for SMF 123 Liberty z/OS Connect EE Audit Record:
EXTY123A DDDDDD DATASET DESCRIPTION
IMAC123A TY123A TYPE123A z/OS CONNECT EE AUDIT
TYPE123A -In 2009, IBM used SMF 123 for S/390 Parallel Query Server
TYPS123A which is still in TYPE123, although I presume that record
VMAC123A is no longer created.
VMXGINIT
Apr 30, 2016
May 19, 2016
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Don Bagwell, Aetna, USA.
Change 34.104 Support SMF 112 OMEGAMON CICS recorded version 530, which
VMACOMCI was not listed in the test for valid versions.
Apr 28, 2016
Thanks to Bob Duchesneau, Northwestern Mutual, USA.
Change 34.103 Support for IBM Integration Bus, Version 9.0.0.5 SMF 117
VMAC117 INCOMPATIBLE changes to the FLOW record.
Apr 28, 2016
Thanks to Ben Thompson, Northern Territory Government, AUSTRALIA.
Change 34.102 -For IFCIDs that create more than one T102Sxxx dataset,
READDB2 READDB2 needs IFCID-specific logic, but the new T102SA58
VMAC102 dataset for IFCID=58 was overlooked.
Apr 28, 2016 -Support for T102SA58 dataset in Change 34.072 was correct
only for DB2 V12 with a longer new segment; this change
supports and validates the shorter DB2 10.1 record.
-No "Truncated" name fields existed in test records so the
support for those longer 0058 names awaits test data.
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 34.101 Revision to the graphics code to add a solid black line
GRAFWRKC indicating where the group cap lies on both the percent
Apr 28, 2016 CPU and the MSU charts. This required summarization of
the data so that there was only a single OBS per by
group and uses the VLINE parameter of SGPLOT. The graphs
only work if you are running SAS 9.3 or higher. If not
a message will be on the log and a PROC TABULATE will
be run instead.
Change 34.100 -ZRBASI dataset variable ASILPGSZ was incorrect.
VMACRMFV -ZRBGEI dataset variables below are now correctly divided
Apr 28, 2016 by SSHSMPNR:
May 5, 2016 GEISASL GEIRSTRF GEILCPR GEILCMO GEILF4K GEILP4K
May 16, 2016 GEILPFRI GEILPFCI GEILCMU GEILCPU GEILFPF GEILSMO
GEIRFREM GEISUSE GEILPAG GEILFUSE GEILPUSE GEIRSTRF,
and variable GEIRSHR is now kept in dataset ZRBGEI.
Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
Change 34.099 zVM 6.3 z13 SMT-Mode MONWRITE support and correction.
VMACVMXA -PRCMFM (5.20) HIS SMT-Mode-Only was not as presumed. I
Apr 23, 2016 had thought the new HIS record would be like the new z/OS
Apr 26, 2016 SMF 113 Subtype 1, with interval data instead of the
May 9, 2016 accumulated fields. But the new PRCMFM is unrelated to
existing HIS counters in PRCMFC, and reports only the new
MT-diagnostic counters, with only two (MTDIA448-MTDIA449)
documented, and three others (MTDIA452,MTDIA453,MTDIA456)
are populated, but IBM has claimed them proprietary so
their content is not documented.
But all five are kept in VXPRCMFM dataset.
-PRCAPM (5.10) CRYPTO record has undefined Crypto Type 11
that is now supported after IBM z/VM Support UPDATED the
documentation today at
http://www.vm.ibm.com/PUBS/MON630/MRPRCAPM.HTML
Thanks to Wolfgang Kueller,s IT Solutions, AUSTRIA.
Change 34.098 If the same POLICY-NAME is used in different SYSPLEX, the
ANALACTM report did not print the WLM definitions because of the
Apr 23, 2016 filter criteria. This revision adds SYSPLEX variable to
protect for this unwise choice.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 34.097 RESERVED CHANGE NUMBER.
Change 34.096 Cosmetic. Using WANTONLY=DB2ACCT,IFCIDS=ACCOUNT, READDB2
CLEARDB2 unexpectedly also created the WORK.DB2STSBP dataset; the
READDB2 READDB2 code to suppress it was not added to the MACKEEP,
Apr 21, 2016 and a typo in CLEARDB2 had changed _WDB2SBP to _WDB2SBR.
Change 34.095 -Gregorian dates were not displayed correctly in ASMRMFV
ASMRMFV message log due to incorrect leap year testing in
ADOCRMFV FINDGREG code. Dates of the form ddmmmyyyy were listed
Apr 20, 2016 as one day later than actual. Day of the week values in
Apr 27, 2016 these messages were also one day later than actual.
May 11, 2016 Julian dates of the form yyyy.ddd are correct.
-NOTE: RMFBSAM output data was NOT affected only the dates
in ASMRMFV log messages. ASMRMFV does not modify dates
in the RMFBSAM output file.
-A S0C4 Abend could occur when an VSAM I/O Read Error
happened processing the Sample Set Header (SSH) RMF III
table. This Abend was also possible processing the Data
Set Header (DSH) and Service Policy (SVP) tables.
-Several buffer handling improvements for performance are
added and described below.
-Three initial buffer size adjustments are changed to
reduce FREEMAIN/GETMAIN overhead when an increase is
needed during processing. These are applied to the 32752
RMF III VSAM Record Size to avoid buffer expansions.
Buffer Prior x Record Size New x Record Size
------------- ------------------- -----------------
Decompression 2 160
Sample 1 2
Service Policy 1 18
-Decompression buffer expansions are particularly CPU
expensive because the IBM ERB3RDEC decompression program
must decompress the data first to find out if it fits in
the buffer. If not, the buffer must be expanded and the
decompression repeated on the subsequent call.
-The increases in buffer sizes are offset by new logic
that only applies the adjustments to the first buffer
acquisition. Any subsequent expansions now only request
the actual memory needed, but should be rare. In prior
ASMRMFV versions the adjustment was applied to every
GETMAIN so the buffer areas became unnecessarily large
when several expansions of the same buffer were needed.
-In testing with 12 various RMF Monitor III data sets
buffer memory used was actually slightly less than the
current production ASMRMFV level. Your actual results
will vary. REGION=300M was used for these jobs.
ASMRMFV 33.274 ASMRMFV 34.095
LSR 16000K LSR 16000K
INDEX 32K INDEX 32K
SAMPLE 2207K SAMPLE 3198K
DECOMP 7521K DECOMP 5118K
SVP 96K SVP 1151K
====== ======
*ALL* 25855K *ALL* 25499K
Expands 6 Expands 0
-The assembler symbols &MULTD, &MULTS, and &MULTP remain
tailorable in ASMRMFV by the user as before. These set
the initial buffer size multipliers for the
Decompression, Sample, and Service Policy buffers
respectively. Any change to these values requires an
assembly and link of ASMRMFV.
-The BUFFERS parameter in ASMRMFV provides a listing after
each RMF Monitor III data set processed to show buffer
usage and expansions. Ideally expansions should be zero.
The default is NOBUFFERS and the display is suppressed.
-NOASIX parameter causes ABEND S0C4 or RMFV075W messages;
tests for this parameter were incomplete, but it is an
emergency parameter to suppress ASI extension data,if ASI
data needed to be bypassed. NOASIX causes data loss and
was intended to be used only when recommended by support.
Next ASMRMFV will correct; this is just a don't use note!
Thanks to Randy Hewitt, HPE Enterprise Services, USA.
Thanks to Randy Shumate, Reed Elsevier Technology Services, USA.
Change 34.094 PDB.JOBS observations with ABEND='JCL' were created for
BUILD005 purge records that were for job transmission. Now,
Apr 18, 2016 IF JSTRTIME=. AND SYSEXEC LE ' ' AND SYSTRANS GT ' '
Apr 19, 2016 the TYPE26J2 purge observation is output in PDB.NJEPURGE
instead of PDB.JOBS.
-Variable INTRDR is now kept in PDB.JOBS.
Thanks to Ian Porter, NISSAN-NEDC, ENGLAND.
Change 34.093 New parameter GRAPHS= with a default of YES added so that
GRAFWRKX you can specify TABULATE=YES without creating any graphs.
Apr 16, 2016 Tabulate was cleaned up so that there is only a single
table generated rather than a table for each variable.
Change 34.092 -Support for IHDRRMFV "Header" Exit member to select which
IHDRRMFV RMF III records are to be read by TYPERMFV from RMFBSAM.
IMACRMFV Your selection code can be put in member IHDRRMFV in your
VMACRMFV "USERID.SOURCLIB(IHDRRMFV)" tailoring library, or you can
VMXGINIT use the macro variable MACRMFVH "instream" to select:
Apr 13, 2016 //SYSIN DD *
Apr 15, 2016 %LET MACRMFVH= %QUOTE(IF ERBDTYPE='ASIG3'; );
Apr 21, 2016 %INCLUDE SOURCLIB(TYPERMFV);
would only populate the ZRBASI dataset.
-Removed incorrect second INPUT of CPCGRPNM/CPCGRPLM that
could cause STOPOVER INPUT STATEMENT EXCEEDED ERROR.
-These ZRBASI variables are now input as PIB versus RB:
ASI_LVSHR4KB ASI_LVSHR1MGBYTES ASI_FREEMAINEDFRAMES
Thanks to Randy Hewitt, Hewlett Packard, USA.
Change 34.091 Support for IMS Log 16x Sign On/Sign Off record creates
EXIMS16 new IMS16 dataset.
FORMATS dddddd dataset description
IMAC16 IMS16 IMS16 IMS SIGN ON / SIGN OFF
VMACIMS
VMXGINIT
Apr 15, 2016
Thanks to Gene Heikkinen, Blue Cross Minnesota, USA.
Change 34.090 TYPE115 Macro _WTY115X wasn't listed in _N115 null macro.
VMAC115 TYPECIMS Macro _WIMFMQ wasn't listed in _N116 null macro
VMACCIMS UTILBLDP, cosmetic, extra blank lines were printed in the
UTILBLDP code that clears the old style macros.
Apr 13, 2016 A new QA report will detect _Nxxxx omissions.
Thanks to Andre G. Moretto, IBM Global Technology Services/Delta, USA
Change 34.089 Support for SAMS VANTAGE User LSPOOLPO record INCOMPAT
VMACSAMS changes. These new variables in SAMSLSPC dataset:
Apr 14, 2016 SAMSBYFR ='FREE*BYTES'
SAMSCLFR ='MAXIMUM*FREE*EXTENT IN*TRACKS'
SAMSDSCBPCT='PERCENT*USED*DSCBS'
SAMSEAV ='EXTENDED*ADDRESS*VOLUME?'
SAMSFREEC ='TOTAL*FREE*SPACE IN*CYLINDERS'
SAMSHASG='GLOBAL*HASH*VALUE'
SAMSHASL='LOCAL*HASH*VALUE'
SAMSLPAR='LPAR WHERE VANTAGE RUNS'
SAMSMFEB ='MAX FREE*EXTENT*IN BYTES'
SAMSSHR ='DASD*VOLUME*SHARE*STATUS'
SAMSSUBS='SUBSYSTEM WHERE VANTAGE*RUNS'
SAMSSYSP='SYSPLEX WHERE VANTAGE RUNS'
SAMSTCYLS ='TRKMGDSPACE*TOTAL*FREE*CYL'
SAMSTEXTNT='TRKMGDSPACE*FREE*EXTENTS'
SAMSTINDEX='TRKMGDSPACE*FRAGMENTATION*INDEX'
SAMSTMCYLS='TRKMGDSPACE*MAX EXT*CYL PORTION'
SAMSTMTRKS='TRKMGDSPACE*MAX EXT*ADDL TRKS'
SAMSTTRKS ='TRKMGDSPACE*ADDITIONAL*FREE*TRKS'
SAMSTVTRKM='TRKMGDSPACE*TOTAL TRACKS'
SAMSTVTRKS='TOTAL*TRACKS ON*VOLUME'
and variable SAMSRSVD, a reserved field, is not kept.
-SAMSPOOL record was also INCOMPATIBLY changed but no
new variables were created.
Thanks to Emmanuelle Tanguy, ARKEA, FRANCE.
Change 34.088 Unused Change Number.
Change 34.087 -MXG 34.02, IMS 12.1, IMS 07 record was misaligned due to
VMACIMS 8 overlooked added bytes, and incorrect input of DLRAZAAP
Apr 12, 2016 that was added in IMS 13.1, not 12.1.2
-Zero divide fix if MXGRDTM=0 (fast read on ASCII).
-Variable LINTSY2 is formatted $HEX16.
Thanks to Paul Volpi, UHC, USA.
Change 34.086 Support for TYPE8069 RACFEVNT 8069 R_PKISERV GENCERT
EXTY8069 event, including protection for truncated TP2=322 and
IMAC80A doc errors for TP2=343 and TP2=351.
VMAC80A
VMXGINIT
Apr 8, 2016
Thanks to Joe Faska, DTCC, USA
Thanks to William M. Vender, DTCC, USA.
Change 34.085 Support for these new z/VM VXSYTEMP dataset variables
FORMATS from the extended (third) segment:
VMACVMXA NCM_TCT_FCOP='FICON*OPERATIONS'
Apr 8, 2016 NCM_TCT_DFCOP='DEFERRED*FICON*OPERATIONS'
Apr 12, 2016 NCM_SCT_FCOP='SUMM COUNT*FICON*OPERATIONS'
Apr 14, 2016 NCM_TCT_FCXTM='FICON*TRANS-MODE*OPERATIONS'
Apr 21, 2016 NCM_TCT_DFCXTM='DEFERRED*FICON*TRANS-MOD*OPS'
Apr 24, 2016 NCM_SCT_FCXTM='SUMM COUNT*FICON*TRANS-MODE'
Apr 26, 2016 -Variables PCTLPABY and PCTCPCBY are now correctly
May 4, 2016 calculated AFTER the deaccumulation.
May 16, 2016 -Format $MGVXACH is updated for new Channel Types.
May 23, 2016 -Dataset VXSTOVDK variable QDIIOCNT is now deaccum'd.
-Dataset VXSYTLCK variables CALS/CALX/SYN deaccum'd.
-Dataset VXAPLSL0 is now properly deaccumulated; note that
only observations with TICKS GT 0 are output.
-Dataset VXSYTLCK variable CALSSCNT is DIF()d and SYNATT4S
second DIF() corrected to SYNFTG4S.
-Dataset VXBYUSR variables that are now deaccumulated:
VMUYPLTL0-5,VMUSTLT0-5,VMUVMTL0-5,VEBALERT/HDWAI/SVSCT/
TPIAI/TVSCT/VEBVIRAI,VMDUFOCT/UOFTM/SLCNT
-Dataset VXIODVSW is now deaccumulated with sort order
corrected.
-Some deaccumulated datasets had observations output with
DELTATM value negative; those are now correctly deleted
(they are the first instance so no deaccum is possible).
-Dataset VXMTREND now has DELTATM=. as it is not accumed.
-Dataset VXIODDEV variable VIUTIMIN's TIME12.2 reinstated.
These variables had missing values and missing labels:
RDEVSKSM64 RDEVWXCT RDEVRXCT SCMIDTIM SCMPDTIM PAVIDTIM
PAVPDTIM
-May 16: Variable ASMSSCH in dataset VXSTOASP is only two
bytes, so its accumulation wraps at a value of 65536; MXG
had incorrectly used FFFFFFFFx, causing large values.
But variable SCGSSCH is four bytes and would be safer.
Thanks to Graham Harris, RBS, ENGLAND.
Change 34.084 The MOBWRKI2 is now updated for the new DB2STSBP data,
MOBWRKI2 preventing ERROR: FILE WORK.SUMSTSBP.DATA DOES NOT EXIST.
Apr 7, 2016
Thanks to Jan Tielemans, KBC, BELGIUM.
======= Changes thru 34.083 were in MXG 34.02 dated Apr 5, 2016========
Change 34.083 IMS56FA ARRVTIME value is wrong for transactions that
VMACIMS arrived from a system whose GMT offset is not the same as
Apr 5, 2016 this system. Now, the GMT delta between the two systems
is added to ARRVTIME when there is a difference so that
all datetime values are local to this IMS system.
Note that you must use TYPSIMST ("S" for SORT) program to
invoke the _SIMS56G for the Chain correction. Use the
JCL example in the TYPSIMST member's comments.
-The INPQUETM is a zero value if the ENDTIME of the prior
transaction in a chain is LATER than the STRTTIME of this
transaction. Why this happens is not understood yet.
-The _IMSVERS macro is NOT USED for the IMS56FA processing
because the actual version is in the 56FA record and is
used by MXG to control version differences, so multiple
IMS version's 56FA records can be processed together.
The MXG NOTE/WARN messages about _IMSVERS are removed.
Macro _IMSVERS is used ONLY for 07/08/0A/31/35/36/40/59
IMS log records, but only the 07/08 records need 10.1 or
11.1 or 12.1 to be specified and processed separately.
Thanks to Michael J. Lamdin, Verizon, USA.
Thanks to David A. Bernhardt, Verizon, USA.
Thanks to Matthew E Bogart, Verizon, USA.
Thanks to Mark Albert, Verizon, USA.
Thanks to Stephen P. Nathan, IBM, USA.
Change 34.082 DB2 Trace IFCID 196 variables QWn196HY (0-8), QW0196WY,
VMAC102 are formatted $HEX4 and INPUT $CHAR2 and QW0196W9 is
Apr 5, 2016 formatted $HEX16.
Apr 16, 2016 -Some _S102348-_S102355 dataset sort macros had repeated
PROC SORTs, but there were no errors, just wasted time.
Change 34.081 -Oracle/STC User SMF records GMTOFFTM could be "slightly"
VMACSTC wrong with a slightly larger (seconds to a minute) and a
Apr 4, 2016 non-integer value for a few observations, depending on
the SMFTIME delta to the earlier STC timestamp; the GMT
algorithm used in VMACSTC was unique and now uses the
normal calculation.
-Some VMXGTIME calls were revised, and dataset STCVSM28
has new variable REPDURTM=DURATION*OF*REPLICATION added.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 34.080 -z/VM 6.3.15.2 SMT MODE, BROKEN CONTROL RECORD ERROR due
VMACVMXA to new fields added to SYTCUP segment that now create:
Apr 5, 2016 LCXPMTST='PARTITION*MULTITHREADING*STATUS'
LCXHGPNM='LPAR*GROUP*NAME'
-Unrelated, CECSER was not populated in VXMTRSYS because
that 1.4 record is written before the 1.5 record that has
the CECSER is written. If you use TYPSVMXA to invoke
sorting of all datasets, this update will populate CECSER
into the VXMTRSYS dataset. Or you could use
%INCLUDE SOURCLIB(TYPEVMXA);
_SMTRSYS
_SMTRPRT
RUN;
Thanks to Graham Harris, RBS, ENGLAND.
Change 34.079 RMF III ZRBASI dataset new variables are created/decoded:
FORMATS ASICX='ADDRESS*SPACE*TYPE'
VMACRMFV VALUE $MGRMFCX
Apr 3, 2016 'S '='S:STARTED TASK'
'T '='T:TSO'
'B '='B:BATCH'
'A '='A:ASCH'
'O '='O:OMVS'
'? '='?:UNKNOWN'
'E '='E:ENCLAVE'
'SO'='S:STARTED TASK WITH OMVS PROCESS'
'TO'='T:TSO WITH OMVS PROCESS'
'BO'='B:BATCH WITH OMVS PROCESS'
'AO'='A:ASCH WITH OMVS PROCESS'
'OO'='O:OMVS WITH OMVS PROCESS'
'?O'='?:UNKNOWN WITH OMVS PROCESS'
'EO'='E:ENCLAVE WITH OMVS PROCESS'
;
ASICR='WLM*CRITICAL*STATUS'
VALUE $MGRMFCR
'C '='C:CPU CRITICAL'
'S '='S:STORAGE CRITICAL'
'SC'='SC:BOTH CRITICAL'
;
Change 34.078 -MXG 34.01. TYPE72GO variable MSUSOFT was wrong, because
VMAC7072 the correct calculation in Change 34.010 was overridden
VMXGRMFI by the un-removed original calculation (TCBPART/SRBPART).
Apr 2, 2016 -MXG 33.33. RMF72 had MSU72, MSUINTRV, MSUPERHR variables
incorrectly containing Software MSU, while MSU4HRAV did
have the correct Hardware MSU. MXG 34.01 changed those
three variables to correctly contain Hardware MSU, and
created three new variables with Software MSU, but the
MSU4HRAV was changed to Hardware MSU. This 34.02 change
corrects MSU4HRAV also to contain Hardware MSU. The
MSU4HRAV in RMFINTRV is only the Software MSU captured
in the TYPE72GO Service Class records; the IBM Four Hour
Average Software MSU actually used for software costs is
in the TYPE70LAC variable in PDB.TYPE70.
-RMFINTRV MSU variables for Software MSU all have an "S":
Software: MSUSOFT MSUINTRVS MSUPERHRS MSU4HRAV
Hardware: MSU72 MSUINTRV MSUPERHR n/a
-MSUSOFT will be missing if ONLY type 72 records are read;
70s always precede 72s and CECSUSEC is retained from that
type 70 to calculate MSUSOFT.
Thanks to Randy Shumate, Reed Elsevier, USA.
Change 34.077 Support for optional CICSTRAN variable USERCT01.
IMACICWT
UTILEXCL
VMAC110
Apr 1, 2016
Thanks to Niels Ole Kjeldsen, KMD, DENMARK.
Change 34.076 Support for dataset TYPE80TK new variables TOKMREVOKED,
VMAC80A TOKMREVREAS and TOKMFIREACCS/
Mar 31, 2016
Thanks to Roger X Baker, GLIC, USA
Thanks to Frank Bauer, GLIC, USA.
Change 34.075 -THIS IS A FATAL ERROR AND SCRT/MWRT REPORT WILL ABEND,
MOBWRK05 if you included data with the CLOCK CHANGE hours. Your
Mar 31, 2016 MARCH REPORT MUST RUN BETWEEN APR 2-9 WITH this update.
When the clock is changed for winter/summer/daylight time
two rows were created in MWRT_LOOKUP89 that caused
"REPEATS OF BY VALUES" messages. This change keeps only
the first row and eliminates the message.
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Thanks to Rudi Claes, KBC, BELGIUM.
Thanks to Graham Harris, RBS, ENGLAND.
Change 34.074 The bit tests for the new TYPE0201 and TYPE0202 datasets
VMAC0203 for decoding variables SMF2IHASHMETH and SMF2ISIGTYPE
Mar 31, 2016 were missing the final "B", causing blank values.
Thanks to Robert Sample, TOMY, USA.
Change 34.073 Dataset TYPE749 (PCIE) is enhanced with new calculated
VMAC74 variables used in RMF reports.
Mar 30, 2016
Thanks to Michael Friske, FMR, USA.
Change 34.072A Support for SMF 102 IFCID 58 Added Segment creates new
EX102A58 DDDDDD DATASET DESCRIPTION
IMAC102 102A58 T102SA58 Added END SQL STATEMENT EXEC
VMAC102 See Change 33.102 (in MXG 34.03) which corrected VMAC102
VMXGINIT and validated the new data.
Mar 30, 2016
Change 34.072 RMF 73 Subtype 3 ERROR R723DNST NOT EQUAL TO R723RTYP is
VMAC7072 for the seldom-used TYPE72DL, in only one record, which
Mar 30, 2016 had one WRS pair with RTYP='CB' and RDNN=6 with six DSNTs
Mar 31, 2016 that matched, but the RTYP='DB2' pair also had RDnn=6 but
there were no segments with DSNT='DB2'. Other RTYP='DB2'
records have RDNN=0. While I believe the record is wrong,
and should have RDNN=0, IBM noted that all of the sample
counts in R723RW01-R723RW15 are zero and there could be
no name table entries, so MXG now circumvents by only
reading the name table when there are samples recorded.
(Variables R723RN01-R723RN15 are blank if no table.)
-But this investigation exposed a logic error in MXG
reading the name table; the OFFDSN was NOT incremented,
so only the first segment was being input, repeatedly,
which is now corrected.
Thanks to Lorena Ortenzi, UniCredit Group, ITALY
Thanks to Paolo Uguccioni, UniCredit Group, ITALY
Change 34.071 Cosmetic. Label for R749DBYR and R749DBYT were corrected.
VMAC42
Mar 29, 2016
Thanks to Michael Friske, FMR, USA.
Change 34.070 I/O Connect time S42CONNTM=AVGCONMS*IOCOUNT/1000 is now
VMAC42 calculated and kept in TYPE42DS, TYPE42SR and TYPE42VT
Mar 27, 2016 datasets, formatted TIME13.3.
Change 34.069 -Variable RNI is now kept in TYPE1131.
ASUM113 -The SORTED BY list had SM113STM SM113CPU transposed.
VMAC113 -Dataset TYPE1131 _KTY1131 "variable keep" macro now
Mar 24, 2016 works for both TYPE1131 and ASUM1131.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 34.068 z/OS 2.2 SMF 73 INPUT EXCEEDED due to Split 73 record not
VMAC73 supported. VMAC73 now detects split records, but IBM
Mar 24, 2016 plans a 2ndQ APAR that redesigns the 73 split so that
Mar 31, 2016 self-contained records are written (EIX=HEN), and that
May 4, 2016 design is already supported in the existing 73 code.
These are the variables populated from the extended seg:
SMF73ECP SMF73EOC SMF73EOD SMF73EOS SMF73ETC SMF73ETD
SMF73ETS CHFRATE CHFACTV CHFDFER CHFXRATE CHFXACTV
CHFXDFER
So, if you don't have the APAR and want those variables
added, you would use n the _STY73EX macro.
%INCLUDE SOURCLIB(VMAC73,VMACSMF,IMACKEEP);
DATA _VAR73; _SMF ; _CDE73; _STY73EX;
The TEMP73EX dataset is created with the split segments
from the second (split) record (when EIX GT HEN) and the
new _STY73EX replaces the _STY73 dataset sort macro to
sort and merge TEMP73EX into TYPE73. This split record
had 158 valid channels but only 105 fit in the first 32K
record (because IBM writes 256 channel segments in every
every record, including offline, so the other 53 Extended
Channel segments were in the second record.
-May 4: APAR OA50254 eliminates the split 73 records and
each record will be self-contained with matching channel
path data sections and extended channel path sections.
Thanks to Joachim Sarkoschitz, DATEV, GERMANY
Change 34.067 z/OS 2.2 OAM SMF 85 INPUT STATEMENT EXCEEDED because MXG
VMAC85 tested R85PVRM for specific versions but not for '2020'.
Mar 24, 2016 However, that ancient test is no longer needed for the
subtypes 78,79, and 88 since all records now have the
missing early fields that needed that test, so new z/OS
versions' won't need VMAC85 to be updated for R85PVRM.
Thanks to Joachim Sarkoschitz, DATEV, DENMARK.
Change 34.066 -zVM MONWRITE dataset VXBYUSR is enhanced with these three
VMACVMXA memory variables, VMDUFACTC, VMDUFIBRC and VMDCTPNS.
Mar 21, 2016 -New: You can specify %LET MXGABND=8709; so that the
BROKEN CONTROL RECORD ERROR will now also cause the job
to ABEND with a USER 8709 abend code, so the error can't
be overlooked. (This error usually occurs when a back
level of MXG tries to read data from a new zVM version.)
Thanks to Graham Harris, RBS, ENGLAND.
Change 34.065 CICS/TS 5.3 MNSEGCL=5 INPUT STATEMENT EXCEEDED error due
VMAC110 to MXG read of 128 bytes but the segment is only 120.
Mar 21, 2016 You have to have enabled TSQUEUE Resource Class data to
populate dataset CICSRDQU to encounter this error.
Thanks to Bob Duchesneau, Northwestern Mutual, USA.
Change 34.064 -Circumvention for BBMQ Short E6 records. The last segment
VMACBBMQ in every E6 record is 4 bytes shorter than ENTL, but the
Mar 21, 2016 four bytes are unused, so this heuristic detects the last
Mar 28, 2016 record condition and the last segment is now output in
the BBMQQUES dataset (which will have more observations.)
-Circumvention for incorrect ENTL for E4 which caused the
BBMQLMGR to be trashed. ENTL=1336 in header but only 1275
exist.
-BY lists updated for NODUP removal for BBMQBUFF, BBMQCHAN
BBMQLMGR and BBMQPAGE, although no duplicates have ever
been created, just to be consistent.
-Mar 28: Datetimes were incorrectly set to GMT in 34.01.
now corrected to local.
Thanks to Jim Swinarski, Credit-Suisse, USA.
Change 34.063 ERROR START GREATER THAN END creating DBID/OBID format is
ANALDB2R corrected with this rewrite of VMFMT102 and the dropping
VFMT102 of the system and timestamps from the keys to the format.
Mar 22, 2016 The FORMATs are now the same whether you use POINTINTIME
Mar 31, 2016 or the T102S105/107 records but POINTINTIME will always
be more accurate since it is a snapshot of what DB2 sees
while the 105/107 records will only reveal databases
that have been opened.
Thanks to Jutta Gleixner-Schmid, Allianz, GERMANY
==== Changes thru 34.062 were in FINAL MXG 34.01 dated Mar 21, 2016====
Change 34.062 Cosmetic. With MXGREADSMF=LOGGER or =BOTH, log messages
VMACSMF "LAST RECORD" and the SMF Summary box of times/bytes read
Mar 17, 2016 were not printed. Superfluous code was removed.
Thanks to Chris Weston, SAS ITRM, USA.
Change 34.061 Support for BMC MAINVIEW FOR IP, creates these three
EXMVIP2C datasets of primary interest:
EXMVIP2F DDDDDD MXG MXG
EXMVIP03 DATASET DATASET DATASET RECORD
FORMATS SUFFIX NAME LABEL SUBTYPE
IMACMVIP
VMACMVIP MVIP2C TAC9I490 TN3270PERF 2C
VMXGINIT MVIP2F TAC9I350 SAWDATA 2F
Feb 26, 2016 MVIP03 TAC9I820 TACCONS 03
Mar 15, 2016
May 7, 2016 Note that IMACMVIP is tailored to only create these
May 30, 2016 three datasets.
Jun 1, 2016 Labels added Jun 1.
Aug 2, 2016 The MXG support for Mainview for IP requires the BMC
utility program BBM9MD73 to "dump" the BMC VSAM file
to a valid VB file that MXG can process.
Aug 2: SWSTOPTX corrected to local time.
Change 34.060 ITRM ONLY, MXG 34.01 ONLY, CRITICAL ERROR because &PDB
VMXG70PR was used instead of &PDBMXG in two places; &PDBMXG has
Mar 15, 2016 always been the intended default macro variable for the
default "PDB" destination, and is required by ITRM.
Thanks to Chris Weston, SAS ITRM, USA.
Change 34.059 Short type 119 subtype 41 with only one triplet populated
VMAC119 caused INPUT STATEMENT EXCEEDED. The record does not
Mar 14, 2016 contain any subtype 41 data. The first three instances
print a DELETED message on log.
==== Changes thru 34.058 were in THIRD MXG 34.01 dated Mar 14, 2016=====
Change 34.058 MXG 34.01: CRITICAL: TYPE72GO only PERIOD 1 was output.
VMAC7072 Change 34.010 added MSU72 but used DO _I_= inside a DO
Mar 14, 2016 that already used DO _I_, which terminated the first DO.
Thanks to Randy Shumate, Reed Elsevier, USA.
=== Changes thru 34.057 were in SECOND MXG 34.01 dated Mar 14, 2016=====
Change 34.057 Documentation only. Member JCLINSTT example has steps to
JCLINSTL FTP download, Unterse, and create USERID and FORMATS; new
JCLINSTT JCLINSTL example has only USERID and FORMATS create, if
VMXGCNFG you have already downloaded and untersed the new version.
Mar 11, 2016 Example DSNAMES are MXG.MXGVVNN.SOURCLIB/FORMATS in these
members and in the ftp instruction email text.
The install instructions stress that if you now depend on
the SAS NLSCOMPATMODE option to handle local characters
(British Pound, French accents, umlauts, etc.) you will
have to change your JCL for MXG to use your site's SAS
JCL procedure, with the CONFIMXG option, because SAS has
stated their intention to remove that option in a future
version.
See examples and comments in member VMXGCNFG.
//MXGSTEP EXEC SAS,CONFIG=MXG.SOURCLIB(CONFIMXG)
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
Thanks to Tom MacCabe, Dominion Resources Services, Inc., USA.
Change 34.056 TYPE 60 dataset variable SMF60ELP was misaligned, VVRKEY
VMAC60 was not converted to EBCDIC text, and these address space
Mar 11, 2016 size/address variables are formatted MGBYTES
VVRDSHA VVRDSHU VVRHARBA VVRHURBA
VVRXEBA1-VVRXEBA5 VVRAMASP
Thanks to Michael Friske, FMR, USA.
Change 34.055 TYPE 120 ST 9 new TYP1209R (REQUEST) and TYP1209N (ASYNC,
EXT1209N Non-Request) datasets completely replace four existing
EXT1209R TYP1209x datasets. The subtype 9 is either a REQUEST or
IMAC120 ASYNC event, and the two new datasets contain only the
VMAC120 variables that are appropriate for that event. These two
VMXGINIT new datasets eliminate the need to populate the A/C/E/S
Mar 11, 2016 datasets, which can be created with zero observations
Mar 16, 2016 by tailoring each _Edddddd "dataset output macro" to
Mar 21, 2016 replace the OUTPUT statement with a blank, either in your
Apr 11, 2016 //SYSIN for jobs that create TYPE120 datasets with
%LET MACKEEP=
MACRO _ET1209A % MACRO _ET1209C %
MACRO _ET1209E % MACRO _ET1209S %
;
or you can put the two macro lines in your IMACKEEP
member in your USERID.SOURCLIB tailoring PDS/directory.
Mar 21:
-The TYP1209U CPU detail dataset contains up to 20 obs
per event, and variable REQASYNC identifies the event,
and added variables identify the source of that event.
The CPU detail dataset metrics are summarized into the
TYP1209N or TYPE1290R dataset.
-The 1209C and 1209S segments have three or 12 obs per
event, so new variables SM1209ES1-SM1209ES3 and
SM1209EO1-SM1209E12 are created with those IDENTITY and
CLASSIFICATION values, eliminating any need for
TYP1209C/TYP1209S datasets. And new variable REC1209SEGS
identifies which segments were populated in each
TYP1209R/TYP1209N/TYP1209U observation.
-The order of segment processing was revised.
-The value of SM1209CI can be negative: That means that
the request didn't finish. The TCB CPU time at the start
is held, and the TCB CPU time at the end is subtracted to
get the SM1209CI value. If the servant abended or some
other bad thing happened and the request never finished,
there was no 'end time', so you get a negative value.
It's actually an indicator that something went wrong!
Apr 11: Labels for the CPU variables are clarified:
SM1209DA='ENCLAVE*TOTAL*CPUTIME'
SM1209DB='ENCLAVE*ZAAP*CPUTIME'
SM1209DC='ENCLAVE*ZAAP*ELIGIBLE*ON CP'
SM1209DD='ENCLAVE*ZIIP*ELIGIBLE*ON CP'
SM1209DE='ALWAYS*ZERO*QUALIFIED*CPU TIME'
SM1209DF='ENCLAVE*ZIIP*TIME*ON ZIIP'
SM1209HG='ENCLAVE*TOTAL CPUTIME'
SM1209HH='ENCLAVE*ZAAP*CPUTIME'
SM1209HI='ENCLAVE*ZAAP*ELIGIBLE*ON CP'
SM1209HJ='ENCLAVE*ZIIP*ELIGIBLE*ON CP'
SM1209HK='ALWAYS*ZERO*QUALIFIED*TIME'
SM1209HL='ENCLAVE*ZIIP TIME*ON ZIIP'
Thanks to Joesph Faska, DTCC, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 34.054 Variable SMF42LAN was not converted to EBCDIC after the
VMAC42 INPUT SMF42LAN $VARYING64. causing unprintable text.
Mar 10, 2016
Change 34.053 BMC APPTUNE FIX BPU8604 caused INPUT STATEMENT EXCEEDED
VMAC102 error for subtype 8005x because the R8 triplet has R8N=1,
Mar 10, 2016 R8O=1512 with R8L=0 in a record that is only 1511 bytes
long. That INPUT is now skipped when the R8L is zero,
pending a correction from BMC.
Thanks to Rudi Claes, KBC, BELGIUM.
Change 34.052 WPS Only, First MXG 34.01 Only. A typo RUN: with colon
VMXGINIT in line 3667 of VMXGINIT must be deleted as it caused
Mar 10, 2016 WPS to fail to initialize. I would have normally caught
this in my QA with that ABEND, but my SETINIT expired and
I had a condition code rather than an ABEND overlooked.
Change 34.051 Change 33.240 updated MACRO _IO30TM but had replicated
IMAC30IO IOTM3390 causing WARINING: VARIABLE IOTM3390 EXISTS.
Mar 10, 2016 Delete the second IOTM3390.
Thanks to Randy Shumate, Reed Elsevier, USA.
Change 34.050 Variables SM1209CM, SM1209CR, SM1209CS were incorrectly
VMAC120 kept in datasets TY1209C, TY1209S, and TY1209U, and were
Mar 9, 2016 used incorrectly in the _ST1209C and _ST1209U BY lists,
so combining multiple PDBs build with and without this
change could fail with a NOTSORTED error on either.
This Change was included in 34.055, above.
Thanks to Joesph Faska, DTCC, USA.
Change 34.049 Support for ASG/TMON Version 4.0 for CICS, REQUIRED.
VMACTMO2 Version changed all duration fields from microsecond to
Mar 9, 2016 todstamp units, but these 15 variables were not divided
by 4096 (the other 399 were), so these variables will
have values larger by that 4096 factor.
CICOVHTM FILEIOTM TAARQRTM TAARQWTM TAAWTTTM TAAWTWRT
TADSPCPU TADSPDTM TADSPSTM TADSPWRT TATCBSTM TATCBSTM
TATCBSTM TIIWTWRT TMCGADT
Fortunately, none of these duration variables are in the
primary MONITASK dataset.
Thanks to Miguel Machin, CAREFIRST, USA
Thanks to Alan Gray, CAREFIRST, USA.
=== Changes thru 34.048 were in FIRST MXG 34.01 dated Mar 7, 2016======
Change 34.048 Support for BE93 Version 6.1.0 (INCOMPATIBLE, header was
VMACBETA relocated). No new variables nor datasets.
Mar 7, 2016
Thanks to Rudolf Sauer, T-SYSTEMS INTERNATIONAL GmbH, GERMANY.
Change 34.047 Support for z/OS 2.2 RMF III data records.
VMACRMFV -No change is needed for the ASMRMFV program that reads
Mar 6, 2016 the Compressed VSAM file to create the RMFBSAM data file.
-New variables in ZRBASI dataset:
ASICPUTA_LF ='CPU*TIME'
ASIDCTIA_S ='CHANNEL*CONNECT*TIME'
ASIDP ='DISPATCHING*PRIORITY'
ASIFRXA_LF ='FIXED*FRAMES*ABOVE'
ASIFRXB_LF ='FIXED*FRAMES*BELOW'
ASIFRXH_LF ='FIXED*FRAMES*HIGH'
ASIIOCNT_S ='EXCPS'
ASIQSCANRES ='QSCAN*RESOURCES*RETURNED'
ASIQSCANRESSQ1 ='QSCAN*ASIQ*SCANRES*SSQ1'
ASIQSCANRESSQ2 ='QSCAN*ASIQ*SCANRES*SSQ2'
ASIQSCANSPECREQ='QSCAN*SPECIFIC*REQUESTS'
ASIQSCANTIME ='QSCAN*REQUESTS*ISSUED'
ASIQSCANTIMESQ1='QSCAN*ASIQ*SCANTIME*SSQ1'
ASIQSCANTIMESQ2='QSCAN*ASIQ*SCANTIME*SSQ2'
ASITCBTA_LF ='TCB*TIME'
ASITRCA_S ='TRANSACTIONS'
ASITRT ='TRANSACTION*RESIDENT*TIME'
ASI_FREEMAINEDFRAMES='FREEMAINED*FRAMES'
ASI_HVSHRPAGEVALIDATIONS='PAGE*VALIDATONS*HI SHARE'
ASI_LVSHR1MGBYTES='HWM*HIGH*VIRTUAL*SHARED'
ASI_LVSHR1MNMOMB='SHARED*1M*MEMORY*OBJECTS'
ASI_LVSHR4KB ='SHARED*BYTES*HI VIRT'
-New variables in ZRBCPU dataset:
CPC_ATD_AAP ='AVERAGE*THREAD*DENSITY*AAP'
CPC_ATD_CP ='AVERAGE*THREAD*DENSITY*CP '
CPC_ATD_IIP ='AVERAGE*THREAD*DENSITY*IIP'
CPC_CAPF_AAP ='MT CORE*CAPACITY*FACTOR*AAP'
CPC_CAPF_CP ='MT CORE*CAPACITY*FACTOR*CP '
CPC_CAPF_IIP ='MT CORE*CAPACITY*FACTOR*IIP'
CPC_MAXCAPF_AAP='MT CORE*MAXIMUM*CAPACITYAAP'
CPC_MAXCAPF_CP ='MT CORE*MAXIMUM*CAPACITYCP '
CPC_MAXCAPF_IIP='MT CORE*MAXIMUM*CAPACITYIIP'
CPC_MODE_AAP ='MT CORE*MODE*AAP'
CPC_MODE_CP ='MT CORE*MODE*CP '
CPC_MODE_IIP ='MT CORE*MODE*IIP'
CPC_PROD_AAP ='MT CORE*PRODUCTIVITY*AAP'
CPC_PROD_CP ='MT CORE*PRODUCTIVITY*CP '
CPC_PROD_IIP ='MT CORE*PRODUCTIVITY*IIP'
CPU_PARK_CP ='PARKED*TIME*CP'
CPU_PARK_IFA ='PARKED*TIME*IFA'
CPU_PARK_ZIP ='PARKED*TIME*ZIP'
CPU_ONLINE_CP ='ONLINED*TIME*CP'
CPU_ONLINE_IFA ='ONLINE*TIME*IFA'
CPU_ONLINE_ZIP ='ONLINE*TIME*ZIP'
-New variables in ZRBGEI dataset:
GEILSMO ='MEM OBJ*HI VERT*BACKED IN*1MB FRAMES'
GEIRFREM='FREEMAINED*FRAMES*ALL ASIDS'
Change 34.046 ASUMCACH now works without RMF III data and supports tape
ASUMCACH or disk. When the PDB is on tape, TYPE74 is copied to
Mar 5, 2016 //WORK to prevent having two open tape datasets.
Change 34.045 JES2 SMF 26 z/OS 1.13 TRIPLET segment before PRINT caused
VMAC26J2 INPUT STATEMENT EXCEEDED ERROR on z/OS, or a FLOATING
Mar 5, 2016 POINT EXCEPTION on ASCII. The unexpected order
misaligned the input of offset variable SMF26OJC to have
a value of 3,806,577,725, which then caused the error
when INPUT @SMF26OJC was executed with that large value.
The SMF manual has always shown all 7 segments at offset
50, so it's the order in the SMF manual that has
previously defined their order in the record. This
change heuristically detects the order of those two
segments.
-Change 33.046 added support for the SMF26JCR field in MXG
33.02 last year, and that new code failed on the reversed
records at this one site, where all records on some
systems were reversed, and all records on other systems
had the correct segment order.
Thanks to Rich Kuehn, Global eXchange Services, Inc., USA.
Change 34.044 New Capacity Group reports of CEC resources consumed by
ANALGRCA LPARS within a capacity group by RMFINTRV workloads,
GRAFWRKC reporting percent CPU, total CPU time, estimated hourly
Mar 6, 2016 software MSU, and memory consumption by workloads and
then by LPAR.
ANALGRCA and GRAFWRKC both report on Group Capacity.
A good place to start is gragwrkc - it will take your
RMFINTRV dataset and build a picture by CEC and Capacity
Group of %CPU busy, CPU time, estimated hourly MSU, and
memory with a pair of graphs for each, the first by your
RMFINTRV workloads, the second by LPAR within the
Capacity Group. You can narrow down the squeaky wheel
to a workload and/or lpar, and then you can use ANALGRCA
to fine tune the analysis.
ANALGRCA will do much the same thing but lets you zero-in
on what is pushing you to the cap or to a threshold you
specify. The threshold can be an absolute number of MSU
or a percentage of the total group capacity. It will look
at the LPARS in the group using ASUMCELP, the workloads
using RMFINTRV, and the SMFINTRV dataset to look at
tasks. There are parameters to specify the date to
examine, the interval to use (but it must be the same as
the cecintrv in asumcelp.) and for workload and job level
data only those intervals that exceeded the threshold are
used in reporting.
Change 34.043 MXG 33.33. Change 33.316 missed the four reserved bytes,
VMAC71 causing SMF71CPx, SMF714Kx, & SMF71PLx to be misaligned.
Mar 2, 2016
Thanks to Rick Southby, Insurance Australia Group, AUSTRALIA.
Change 34.042 Support for DCOLLECT FLAG4 bits that indicate each
VMACDCOL size variables are now in MegaBytes, previously in
Mar 7, 2016 KiloBytes, in DCOLBKUP and DCOLMIGS datasets.
Mar 8, 2016 -Mar 8. UBALLSP and UMALLSP 024* changed to 1024*.
Mar 22, 2016 -Mar 22. All ten UBFLAG and UMFLAG bit tests corrected.
May 8, 2016 -May 8: Change 34.112 corrected UBDSIZE high by 1024.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 34.041 Support for ATF V531 Enhanced Summarization Phase 2
FORMATS inserted these new variables:
VMACATF ATFPGMSW ='PROGRAM*SWITCHES'
Mar 6, 2016 ATFXSNOTN='OTHER*ITEMS**VAR'
Mar 9, 2016 ATFXSNOTL='OTHER*ITEMS**LENGTH'
Apr 5, 2016 ATFXSUOW ='TRANSACTION*UOW'
and the DLI-DB/DLI-TM/DBD/DB2/MQ/OTHERA/OTHERB segments
have new GROUP BUCKET NUMBERs and/or ITEM CODES that are
decoded in new FORMATS.
-Mar 9: (after 34.01) Short 8-byte DBD supported, DLI DB
and DLI TM and OTHER-A segments have been validated.
-Apr 5: Variables ATFXSRSP ATFXSACP ATFXSIQT were wrongly
divided by 4096 twice.
Change 34.040 TYP11921 variable NTHOSTTN is increased from $8 to $64 to
VMAC119 support host names that are fully qualified TCP/IP domain
Mar 2, 2016 name.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Thanks to Gary Nash, Lloyds Banking, ENGLAND.
Change 34.039 Support for new SMF Type 29 IMS JAVA CPU and Garbage Coll
EXTY29GC creates new datasets
EXTY29JA DDDDDD MXG MXG
IMAC29 DATASET DATASET DATASET
TYPE29 SUFFIX NAME LABEL SUBTYPE
TYPS29
VMAC29 TY29GC TY29GC IMS JVM GARBAGE COLLECTION 2
VMXGINIT TY29JA TY29JAVA IMS JVM CPU USAGE 2
Mar 2, 2016 See Change 34.221 which revised and validated with data.
Change 34.038 New variables created in TYPE1209 dataset:
VMAC120 SM1209HE='ENCLAVE*JOINED OR*CREATED?'
Mar 1, 2016 SM1209HF='ENCLAVE*SCHEDULED?'
Thanks to Joe Faska, DTCC, USA.
Change 34.037 Using %LET MXGREADSMF=BOTH caused ERROR 181-185 VARIABLE
VMACSMF SMFINFILE already exists. Code revised to use LOGINFILE
Feb 28, 2016 variable for the INFILE LOGGER.
Thanks to Chris Weston, SAS ITRM, USA.
Change 34.036 TYPE30_5 dataset can have ABEND='SYSTEM' CONDCODE=0000 if
FORMATS a step had a SYSTEM or USER ABEND, but the last step did
VMAC30 not ABEND (e.g., a FLUSH step followed the ABEND). Since
Mar 1, 2016 the type of ABEND is unknown in the TYPE30_5 JOB record,
MXG now sets ABEND='ABEND' instead of ABEND='SYSTEM' in
TYPE30_5. However, in PDB.JOBS, MXG populates both ABEND
and CONDCODE from the LAST step that ABENDed, so you will
not see ABEND='ABEND' except in TYPE30_5. And, since it
is really STEPS that ABEND, and not JOBS, you should use
the PDB.STEPS or TYPE30_4 for ABEND analysis.
Thanks to Linda S. Berkley, USPS, USA.
Change 34.035 These SYNCSORT variables are now kept, formatted $HEX2:
VMACSYNC SYNRETRY='RETRY*FLAG'
Feb 25, 2016 SYNMISCF='SMFFLAG3*MISC*FLAG'
Thanks to Bruce Bordonaro, Pershing, USA.
Change 34.034 Reserved Change Number.
Feb 28, 2016
Change 34.033 Change 31.118 added new fields in the EXGRXEXT (Extended
VMACEDGR Record), but those fields are also in the basic dataset
Feb 28, 2016 records EDGRDEXT and the volume records EDGRVEXT, and
this change adds them to those two datasets.
Thanks to Thomas Giordano, Australian Defence Department, AUSTRALIA.
Change 34.032 Support for DB2 Trace IFCIDS 311 and 321.
VMAC102
Feb 24, 2016
Change 34.031 Cosmetic. If your _IMSVERS does not match the version in
VMACIMS the IMS56FA record, the previous MXGNOTE is now MXGWARN.
Feb 24, 2016 and the text is clearer when they do match.
Change 34.030 TYPE42D4 DATASET variables SMFA2GTAA & SMFA2GTAB are now
VMAC42 correctly INPUT and kept, replacing incorrectly spelled
Feb 22, 2016 SMFA2GSA and SMFA2GSB, with the CA and CI Splits.
Thanks to Michael Friske, FMR, USA.
Change 34.029 Variables SMF70GNM and SMF70GMU added to PDB.RMFINTRV to
VMXGRMFI enable reporting of workloads by Capacity Group.
Feb 22, 2016
Change 34.028 MXG 33.33. ASUM70PR Change 33.306 required PDB.TYPE70 to
VMXG70PR exist in the //PDB data library, so the group capacity
Feb 22, 2016 metrics could be created, but it was not documented that
that the TYPE70 dataset was required. Normally TYPE70 is
in the PDB with the TYPE70PR dataset, but if TYPE70 was
not found in the //PDB library, the ASUM70PR failed.
Now VMXG70PR verifies that TYPE70 exists and uses it if
found, or does not read it if not found, which causes the
new Group Variables to not exist in the ASUM output.
Or, with 33.33 you can circumvent the error using this
code ahead of your ASUM70PR include:
%LET MACKEEP=%QUOTE( MACRO _LTY70 NEWPDB.TYPE70 % );
Change 34.027 MXG set the TYPE1131 CPU Speed SM1132SP to 5000 for z13
VMAC113 because early records contained either 5208 for CP or had
Feb 22, 2016 ZERO for the IP speed. But that is now wrong with the new
Feb 29, 2016 sub-capacity z13s (Speed=3173), so the logic now forces
the 5000 value only if the record contains zero or 5208.
Thanks to Andrew Hebden, Barclays, ENGLAND.
Change 34.026 Support for MVMQ (BBMQ) PTF BPL2558 which was to change
VMACBBMQ all duration fields from TODSTAMP to microseconds, but
Feb 22, 2016 BMC now reports that pre and post that PTF, the values
Mar 10, 2016 have always been in seconds with microsecond fractions.
Mar 22, 2016 MXG was dividing by 4096 presuming TODSTAMP, which is
known to have always been wrong and is now corrected.
Apparently, the primary use has been counts and events
and not durations, as no one noticed!
-Mar 10: Cosmetic typo QSCLOSETTIME to QSCLOSTTIME.
-Unrelated, but observed, that all character date/times
were on GMT zone; new datetime numeric variables replace
them and are set to the local time zone.
Change 34.025 Dataset TYPE70EN, variable PCTMVSBY=100 was incorrectly
VMAC7072 calculated when SMF70PAT, Parked Time, was close to the
Feb 12, 2016 DURATM, but did not exactly match. A 1 second delta is
now required to calculate a non-zero PCTMVSBY=0.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 34.024 Dataset TYPE72GO, variable RESPSTD, Standard Deviation of
VMAC7072 Response time was 2% larger than IBM Value; the 1.04875
Mar 1, 2016 conversion factor is corrected to 1.024.
Thanks to Richard Stuchell, VISA, USA.
Change 34.023 Parameter list was alphabetized and the parameters used
UTILBLDP are displayed on the log. A check was added to the list
Feb 12, 2016 of parameters where an = should not exist as that is
normally an indication that a comma was left off of one
of the parameters.
Change 34.022 -DB2STAT2 statistics dataset new variables:
VMACDB2 QDBPFRAM='FRAMESIZE'
Feb 11, 2016 QDBPVPMI='VPSIZEMIN'
Feb 28, 2016 QDBPVPMA='VPSIZEMAX'
Mar 23, 2017 QDBPSPSZ='SIMULATED*BUFFER*POOL*SIZE'
QDBPSPST='SIMULATED*SEQ*THRESHOLD'
-DB2ACCTP Package dataset, new flag variable
QPACINCO='INCOMPATIBLE*FUNCTION?'
-Documentation: In DB2ACCTP, if QPACRUSM='Y', these fields
are listed by IBM as invalid:
QPACCRNT QPACINSP QPACPAC QPACPKNM QPACCOLN QPACPKID
QPACCONT QPACSCB QPACSCE QPACBJST QPACEJST QPACASCH
QPACAANM QPACAAFG QPACINCO
-Added Mar 23, 2017:
Existing Rollup flag variable DB2PARTY='R' is also set
if QPACRUSM, the new Rollup Summary flag variable is set.
When DB2PARTY='R', the four datetime variables above
QPACBJST QPACEJST QPACSCB QPACSCE
are always zero for BJST/EJST and missing for SCB/SCE.
Those were the individual package event datetimes that
are lost with DB2 ROLLUP summarization.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 34.021 CICSTRAN variable TRANFLAG creates variables from each
FORMATS byte, some are decoded with new formats:
VMAC110 TRANFLAGTF='TRANFLAG*TRANSACTION*FACILITY*NAME'
Feb 12, 2016 VALUE $MGCICTF
'0'='BIT0:NONE'
'1'='BIT1:TERMINAL'
'2'='BIT2:SURROGATE'
'3'='BIT3:DESTINATION'
'4'='BIT4:3270 BRIDGE'
;
TRANFLAGID='TRANFLAG*TRANSACTION*IDENTIFICATION'
VALUE $MGCICTI
'0'='BIT0:SYSTEM TRANSACTION'
'1'='BIT1:MIRROR TRANSACTION'
'2'='BIT2:MIRROR TRANSACTION DPL'
'3'='BIT3:ONC RPC ALIAS TRANS'
'4'='BIT4:WEB ALIAS TRANSACTION'
;
TRANFLAGWL='WLM*STATUS'
VALUE $MGCICWL
'0'='BIT0:WLM REPORT'
'1'='BIT1:WLM NOTIFY COMPLETION'
'2'='BIT2:WLM NOTIFY'
;
TRANFLAGIN='INDOUBT*STATUS'
VALUE $MGCIC8I
'0'='BIT0:INDOUBT WAIT=NO'
'1'='BIT1:INDOUBT ACTION=COMMIT'
'2'='BIT5:INDOUBT FAILURE'
;
TRANFLAGUO='UOW*STATUS'
VALUE $MGCIC8U
'0'='BIT2:UOW INDOUBT ACTION'
'1'='BIT3:UOW SHUNT'
'2'='BIT4:UOW UNSHUNT'
'3'='BIT5:INDOUBT FAILURE'
;
TASKDATALOC='TASKDATALOC*BELOW?'
TASKDATAKEY='TASKDATAKEY*CICS?'
TASKISOLATE='TASKISOLATE*NO?'
TASKDYNAMIC='TASKDYNAMIC*YES?'
Thanks to Perry Lim, Union Bank, USA.
Change 34.020 PK-ZIP SMF records INPUT STATEMENT EXCEEDED error due to
VMACPKSZ one field expanded from 2 to 4 bytes.
Feb 10, 2016
Thanks to Dorothy Yeung, Toyota, USA.
Change 34.019 -STC Variables STC26MST & STC26MET were on GMT time zone,
FORMATS now corrected to local to match other datetimes.
VMACSTC -STC variables STCxxADR were $HEX8 formatted, but that
Feb 9, 2016 is removed as they contain EBCDIC text, not HEX.
Feb 11, 2016 -STC variables STCxxRID are now HEX4 formatted, as they
Feb 24, 2016 contain numeric hex values.
-New format $MGSTCMV maps values in variable STC16MVC.
-New variables decode bits of SMF17DFL:
STC17DRX='RETENTION*PERIOD*REDUCED?'
STC17DAR='AUTO*RECALL?'
STC17DMF='FULL*MVS?'
STC17DYV='RTD*VARY*COMMAND?'
STC17DSW='MVC OR*RTD*REQUIRED?'
STC17DRT='RETAIN*PERIOD*APPLIED?'
and RID variables show 0-F as their range.
-STC11TOL has a third value now supported.
-STC11CSP is relabeled CHANNEL TYPE and formatted.
-Some labels with "MVS" are corrected to "MVC".
Thanks to Randy Hewitt, Hewlett Packard, USA.
Change 34.018 Reserved Change Number.
Change 34.017 Support for NDM-CDI SE Session End record creates
EXNDMSE DDDDDD DATASET DESCRIPTION
IMACNDM NDMSE NDMSE NDM SESSION END
VMACNDM
VMXGINIT
Feb 8, 2016
Thanks to Gerard Bosker, RaboBank, THE NETHERLANDS.
Change 34.016 New variables in MAR 02 record.
VMACMAR TO DO: Subtype 7. Await data in March.
Feb 6, 2016
Change 34.015 New analysis of Group Capacity.
ANALGRCA Inputs are PDB.RMFINTRV,PDB.SMFINTRV,PDB.ASUMCELP.
Feb 6, 2016 See Change 34.044 for GRAFWRKC and a comparison.
Change 34.014 Support for Rocket Software DVS User SMF record ST 1 & 2.
EXDVS01 New datasets created
EXDVS02 DDDDDD DDATASET DESCRIPTION
IMACDVS DVS01 DVS01 DVS CLIENT SYSTEM RECORD
TYPEDVS DVS02 DVS02 DVS INTERVAL SUMMARY RECORD
TYPSDVS -The DVS01 interval dataset is written for each Connection
VMACDVS ID, variable DVS1CNID. This is IBM DVM Data Virtual Mgr.
VMXGINIT -Mar 3: The two lines in the LENGTH statement extended
Feb 5, 2016 beyond 72 characters; on z/OS only, those variables
Mar 3, 2016 were kept in 4 instead of 8 stored bytes, so there would
have been some truncation of datetime values, worst case
255 seconds.
Change 34.013 DB2 dataset T102S166 for IFCID 166 variable QW0166SI is a
VMAC102 statement identifier input $CHAR8 and format $HEX16, but
Feb 4, 2016 it is the statement number, so new variable QW0166SINR is
the numeric statement number; labels clarified.
Thanks to Akhil Vasudevan, Capital One, USA.
Change 34.012 MSU chart modified to reflect an estimated hourly MSU
GRAFWRKX value so that you can see which workloads are making
Feb 2, 2016 the largest contributions to the rolling 4 hour avg.
Change 34.011 -MXG 33.33 with ITRM can cause these errors:
ITRM ERROR: File WORK.SUMSTSBP.DATA does not exist.
Feb 2, 2016 because the new DB2STSBP dataset is now added into the
PDB.DB2STATS dataset, but the new _SDB2SBP sort macro
was not known in ITRM ("NEW"!).
-The correction is easy for BUILDPDB:
ITRM 2.7: Originally reported in 33.301 and MXG 33.33 GA:
ITRM users MUST add this statement
%LET EPDBOUT= _SDB2SBP;
inserted between %CMPROCES... and %CPSTART....
ITRM 3.4-3.6: New in this change:
ITRM users MUST add
%LET EPDBOUT= _SDB2SBP ;
at the top of their SYSIN input.
-For TYPSDB2 program, instead of BUILDPDB, create a new
TYPSDB2 member in your USERID.SOURCLIB "tailoring"
library with these statements:
%INCLUDE SOURCLIB(VMACSMF,VMACDB2,IMACKEEP);
DATA
_VARDB2
_SMF
_CDEDB2
_SDB2SBP
_SDB2
-ITRM 3.7, when released later this year, eliminates this
exposure by invoking the _SDB2 macro which MXG protects.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 34.010 -TYPE72GO variable MSU72, HARDWARE MSU, was re-labeled and
GRAFWLM variable MSUSOFT corrected and also re-labeled:
VMAC7072 MSU72 ='CAPTURED*HARDWARE*MSU 72*COUNT*NOT A RATE'
VMXGRMFI MSUSOFT ='CAPTURED*SOFTWARE*MSU 72*COUNT*NOT A RATE'
Feb 4, 2016
HARDWARE MSU: ORIGINAL MSU - SU_SEC BASED - LARGER
SOFTWARE MSU: NEW MSU - SMF70CPA/CECSUSEC BASED, FOR
SOFTWARE PRICING.
MSU72 =CPUTM*SU_SEC/1000000;
MSUSOFT=CPUTM*CECSUSEC/1000000;
MSUSOFT can be a missing value if no prior RMF 70 for
this system was found, since it needs SMF70CPA from the
same-system's RMF 70 to calculate in the RMF 72 code.
-These MSU variables are created in RMFINTRV and TRNDRMFI
with per interval values:
MSUINTRV ='TOTAL*HARDWARE*MSU 70*COUNT*NOT A RATE'
MSUPERHR ='TOTAL*HARDWARE*MSU 70*EXTENDED*HOURLY RATE'
MSUINTRVS='TOTAL*SOFTWARE*MSU 70*COUNT*NOT A RATE'
MSUPERHRS='TOTAL*SOFTWARE MSU 70*EXTENDED*HOURLY RATE'
-New Workload XXXXMSU variables (BATMSU,CICSMSU) and
XXXXMSUS (BATMSUS,CICSMSUS) variables for each workload
are created with these labels:
BATMSU ='BATCH*CAPTURED*HARDWARE*MSU 72*COUNT'
BATMSUS ='BATCH*CAPTURED*SOFTWARE*MSU 72*COUNT'
-New chart of estimated hourly MSU used by IMPORTANCE in
GRAFWLM (need all three of these updated members).
Change 34.009 -BASECICS and BASEDB2 parameters added to match VMXGALOC
VGETALOC logic and allow for different directories to hold the
Feb 2, 2016 often large CISTRAN/DB2ACCT datasets.
-The message that a LIBNAME could not be found is now
suppressed unless MXGEXIMSG is YES.
Change 34.008 -WebSphere variable WTASCTSR was 4096*E6 too large, as it
VMAC115 was input as PIB8 instead of PIB8.6 and was missing the
VMAC116 2016 the required divide by 4096 to convert to seconds.
Jan 29, 2016 -New variables added to MQMACCTQ dataset.
Feb 12, 2016 WTASPBHW='PUBLISH*HIGH*WATER*MARK'
WTASPBTT='PUBLISH*TOTAL*ELAPSED*TIME'
WTASPRCT='PREPARE*CPU*TIME'
WTASPRET='PREPARE*ELAPSED*TIME'
WTASPRN ='PREPARES'
WTASSMRB='MESSAGE*BLOCKS*READ FROM*SMDS'
WTASSMRP='PAGES*OF DATA*READ FROM*SMDS'
WTASSMRS='SMDS*READS SAVED*DATA IN*BUFFER'
WTASSMWB='MESSAGE*BLOCKS*WRITTEN TO*SMDS'
WTASSMWP='PAGES*OF DATA*WRITTEN TO*SMDS'
WTASSMWT='WAIT TIME*FOR SMDS I/O*COMPLETION'
WTASTPCT='TOPIC*CPU*TIME'
WTASTPET='TOPIC*ELAPSED*TIME'
WTASTPN ='TOPIC*COUNT'
Variable WTASCTSR is corrected in value and formatted
as TIME16.6.
-Type 115 dataset TYPE115S variable QESDBFPT was wrong;
it contained QESDBFBT instead of BFPT.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 34.007 Change 33.153 for IMF/MAINVIEW FOR IMS for IMF 5100 was
VMACCIMS not correct, because new variables only in 5200 were read
Jan 26, 2016 when they should not have been. Logic revised for 5100.
Thanks to Betty Wong, Bank of America, USA.
Change 34.006 -Change 33.024 incorrectly overlaid UTILRMFI with UTILWORK
UTILRMFI when the SYSOTHER message was added, which eliminated the
UTILWORK report.
Jan 25, 2016 -UTILRMFI generates reports using your RMFMINTRV WORKnn
definitions, finding any duplications, by comparing the
SMF30s and RMF72s CPU times.
-UTILWORK generates a skeleton RMFINTRV member based on
SERVICE class or REPORTING class.
Thanks to Michael Gebbia, Eddie Bauer, USA.
Change 34.005 -Support for zVM HIS (SMF 113) PDB.VXPRCMFC accumulated.
VMAC113 -Support for zVM HIS (SMF 113) PDB.VXPRCMFM intervaled.
VMACVMXA Dataset VXPRCMFC is the old SMF 113 subtype 2 accumulated
Jan 30, 2016 and VXPRCMFM is the newer SMF 113 subtype 1 intervaled,
Feb 8, 2016 and only VXPRCMFM will be updated by IBM in the future.
Feb 25, 2016 -SMF 113 EXTND counter labels for z13 were incorrect; the
Feb 27, 2016 values and equations were correct, and now both VMAC113
Feb 29, 2016 (z/OS) and VMACVMXA (z/VM) have the same labels, which
default to the labels for the z13 counters.
(See Change 31.172 to change _XLA113 to earlier CPUs.)
-All zVM MONWRITE VXdddddd datasets now have SYSTEM kept
(most did), and all now have CECSER to identify both the
software and hardware identifications.
-RNI for zEC12 was updated to use 2.3 factor in VMACVMXA.
-All calculated variables for the zEC12 were wrong; while
VMAC113 was updated, VMACVMXA was not for VN2=3 data.
-Support for Multiple CECs/SYSTEMs zVM data changed the
sort order of all datasets by inserting CECSER SYSTEM
ahead of BEGINMTR: BY CECSER SYSTEM BEGINMTR other vars.
Thanks to David Cogar, Wells Fargo, USA.
Thanks to Carl D. Ellis, Wells Fargo, USA.
Change 34.004 End Comment was missing around JCL example, caused 180
FDRCRYPT syntax error.
Jan 20, 2016
Thanks to Michael Gebbia, Eddie Bauer, USA.
Change 34.003 A tailored BUILDPDB created a libname with view that
PDBAUDIT caused an error when a PROC SQL read DICTIONARY.TABLES
Jan 28, 2016 and returned a LIBNAME of _TMPLIB that didn't exist:
ERROR: FILE _TMPLIB.XTY70CP.DATA DOES NOT EXIST.
The error was in PROC SQL FROM DICTIONARY.TABLES and was
difficult to diagnose as there are NO other references on
the log to either that libname or that dataset name. This
similar example causes an obscure LIBREF not found error:
LIBNAME FRED (SASUSER);
DATA FRED.DATA;
A=1;
RUN;
PROC SQL;
CREATE VIEW WORK.WILMA AS SELECT * FROM FRED.DATA;
QUIT;
LIBNAME FRED CLEAR;
PROC SQL;
CREATE TABLE TABLES AS SELECT *
FROM DICTIONARY.TABLES WHERE LIBNAME='WORK';
QUIT;
The error message is that libref FRED is not assigned,
but if you weren't the author of this code, you wouldn't
have had a clue that you needed a libref called FRED.
-This MXG change excludes MEMTYPE EQ 'VIEW' from PROC SQL
since only real data libraries are wanted in PDBAUDIT.
-PDBAUDIT already skips reports on known SAS LIBNAMES,
since its purpose is to audit YOUR data libraries;
these additional LIBNAMES are also now skipped:
APFMTLIB CTRLLIB ITMACR MAILLIB
STMFMT STPSAMP ZOSRSTG1
-The PDBAUDIT report can be skipped if you chose, using
%LET MXGPDBAUDIT=NO;
in your SYSIN input.
Change 34.002 HSMFSRST dataset contains three dates (READ,REQUEST,SMF)
ASUMHSM but four times (REQUEST, ALLOC, START, END) have no date,
VMACHSM and if an HSM event spanned one or more days, those
Jan 20, 2016 time values couldn't be used to calculate durations. This
change creates these four new DateTime variables
FSRTIMRDT='DATETIME*REQUEST*ISSUED'
FSRTIMSDT='DATETIME*REQUEST*STARTED'
FSRTIMADT='DATETIME*ALLOCS*COMPLETED'
FSRTIMEDT='DATETIME*REQUEST*ENDED'
from those four times, using END-SMF, then ALLOC-END and
START-ALLOC deltas to detect when a prior event happened
on the prior day and correct the date part.
And these two new durations are now created:
FSRQUEUETM='FSR*QUEUE*TIME*REQ TO*START'
FSRSERVICTM='FSR*SERVICE*TIME*START*TO END'
- The comparison of TIMEPART(SMFTIME)-FSRTIME, an 8-byte
and a 4-byte stored variable produced non-zero deltas
on the order of E-08, so the ROUND(delta,.01) function
was needed to prevent false positives.
-ASUMHSM was updated to use the new datetime variables.
Thanks to Randy Hewitt, Hewlett Packard, USA.
Change 34.001 If the OPTION CHARCODE is enabled, text (??) in VGETOBS
VGETOBS is incorrectly parsed causing CHARACTER OPERAND ERROR:
Jan 19, 2016 MXGNOTE: VGETOBS LAST UPDATED MAR 17, 2015 CHANGE 33.063
ERROR: CHARACTER OPERAND WAS FOUND IN THE %EVAL FUNCTION
THE CONDITION WAS: %LENGTH(&VGETDSN) = 0
ERROR: THE MACRO VMXGWORL WILL STOP EXECUTING.
Changing the text to ( ?? ) resolves the parse. The SAS
default is NOCHARCODE, and the only MXG code that needs
CHARCODE, member FORMATS, resets to NOCHARCODE, and that
program is only run once to update formats for new MXG.
Using CHARCODE in FORMATS allows one member to create the
MXG formats on both ASCII and EBCDIC platforms, but the
rest of MXG code is only validated with NOCHARCODE.
Thanks to Francois Vancoppenolle, PVGroup, BELGIUM.
LASTCHANGE: Version 34.
=========================member=CHANGE33================================
/* COPYRIGHT (C) 1984-2016 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 33.33 is dated Jan 18, 2016, thru Change 33.327
First MXG Version 33.33 was dated Jan 11, 2016, thru Change 33.321
MXG Version 33.13 was dated Dec 23, 2015, thru Change 33.311
First MXG Version 33.13 was dated Dec 21, 2015, thru Change 33.309
MXG Version 33.12 was dated Dec 1, 2015, thru Change 33.286
First MXG Version 33.12 was dated Nov 27, 2015, thru Change 33.284
MXG Version 33.11 was dated Nov 2, 2015, thru Change 33.260
MXG Version 33.10 was dated Oct 20, 2015, thru Change 33.250
MXG Version 33.09 was dated Sep 15, 2015, thru Change 33.217
MXG Version 33.08 was dated Aug 20, 2015, thru Change 33.195
First MXG Version 33.08 was dated Aug 17, 2015, thru Change 33.189
MXG Newsletter SIXTY-SIX was dated Aug 17, 2015.
MXG Version 33.07 was dated Jul 22, 2015, thru Change 33.172
First MXG Version 33.07 was dated Jul 17, 2015, thru Change 33.170
MXG Version 33.06 was dated Jun 11, 2015, thru Change 33.141
MXG Version 33.05 was dated May 19, 2015, thru Change 33.128
Second MXG Version 33.05 was dated May 12, 2015, thru Change 33.124
First MXG Version 33.05 was dated May 12, 2015, thru Change 33.123
MXG Version 33.04 was dated Apr 29, 2015, thru Change 33.112
MXG Version 33.03 was dated Mar 31, 2015, thru Change 33.085
Second MXG Version 33.03 was dated Mar 29, 2015, thru Change 33.084
First MXG Version 33.03 was dated Mar 27, 2015, thru Change 33.083
MXG Version 33.02 was dated Feb 27, 2015, thru Change 33.047
First MXG Version 33.01 was dated Feb 20, 2015, thru Change 33.044
ANNUAL: MXG Version 32.32 was dated Jan 6, 2015, thru Change 32.309
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 33.33 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 33.33.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG Version 33.33 re-dated Jan 18, 2016, thru Change 33.327.
Major CHANGES added in MXG 33.33, dated Jan 18, 2016:
TYPE110 33.326 MXG 32.10-First MXG 33.33. Increased CPU in SMF 110s
from 300 to 500 seconds for 22GB SMF 110s, corrected.
TYPEVMXA 33.327 Data set VMBYUSR missing many observations.
VMXGALOC 33.325 Correction for WEEK1 allocation.
TYPEXAM 33.324 zVPS variable CALENTMT changed from numeric, conflict
Major CHANGES added in MXG 33.33, dated Jan 11, 2016:
TYPEXAM 33.320 Support for zVPS z13 SMT mode new variables.
TYPE70EC 33.318 Data Set SORT70EC NOT SORTED, configuration changed.
TYPE42 33.316 New variables compatibly added by z/OS 2.2.
TYPE64 33.316 New variables compatibly added by z/OS 2.2.
TYPE71 33.316 New variables compatibly added by z/OS 2.2.
TYPE74 33.316 New variables compatibly added by z/OS 2.2.
TYPE99 33.308 New variables compatibly added by z/OS 2.2.
SMFSRCH 33.307 Support for multiple text strings in LOOKFOR=.
ASUMCELP 33.306 Variables SMF70GNM, SMF70GMU, SMF70WLA added.
ANALACTM 33.312 Correction for more than one service policy.
Major CHANGES added in MXG 33.13, dated Dec 23, 2015:
UTILBLDP 33.311 Execution stops if BUILDPDB=YES, with &SPINUOW error.
Major CHANGES added in First MXG 33.13, dated Dec 21, 2015:
Critical Change for ITRM USERS (MXG 33.12+):
ITRM 33.301 ITRM users MUST add %LET EPDBOUT= _SDB2SBP;
inserted between %CMPROCES... and %CPSTART....
ERROR: File WORK.SUMSTSBP.DATA does not exist.
Critical Change for z/OS 2.2 MXGTMNT/TAPE MOUNT MONITOR:
ASMTAPEE 33.207 ML-55 of ASMTAPEE/MXGTMNT REQUIRED for z/OS 2.2.
IBM changes cause ABEND S0E0-28, must reassemble.
New Products Support
TYPEIMS 33.298 Support for IMS 14.1 log records (COMPATIBLE)
TYPE74 33.305 z/OS 2.2 RMF 74 Subtype 10 creates TYPE7410/TYPE74SC,
(new Storage Class Memory data).
TYPE78 33.305 z/OS 2.2 new variables in TYPE78PA.
TYPEVMXA 33.299 Support for zVM 6.3 MONWRITE z13 SMT MODE.
Errors Corrected:
TYPEDB2 33.303 Multiple DB2 100 Subtype 1 created multiple DB2STATS.
TYPE102 33.294 SMF 102 IFCIDs 81E5-8160,8051x INPUT EXCEEDED DRROR
Enhancements
ANALIDDY 33.290 ANALIDDY tabulates ANALID SMF data by date, used to
investigate SMF dumping problems.
Major CHANGES added in MXG 33.12, dated Dec 1, 2015:
Reason for this new version:
TYPE7072 33.280 PDB.TYPE70 z13 SMT mode ZIPCPUS value may be wrong.
New Products Support:
TYPEDB2 33.279 Support for DB2 Simulated Buffer Pool PDB.DB2STSBP.
MOBWRK02 33.279 Support for DB2 Simulated Buffer Pool dataset.
TYPE102 33.264 Support for APPTUNE 11.2 INCOMPATIBLE change in 8005.
TYPE119 33.262 Support for SMF 119 subtypes 2, 5, 6, 7, 41-44, 97.
Errors corrected:
TYPE102 33.273 DB2 SMF 102 IFCID=109 INVALID DO LOOP CONTROL ERROR.
TYPE1415 33.270 Variable SMF14ALIAS misspelled so it was not kept.
TYPE120 33.267 SMF 120 dataset TYP120JI only output first instance.
TYPEXAM 33.266 MXG 33.11 only. ERROR VARIABLE SYTPN NOT FOUND.
TYPETPMX 33.265 ThruputMgr TPMSLM variables TPMSLXGF/LXGN wrong.
Enhancements:
JCLASMXG 33.275 Assemble/Link Edit all five MXG ASM programs install.
ASMRMFV 33.274 ASMRMFV Updates.
MXGLOG 33.162 MXGLOG write enabled by //MXGLOG or FILENAME MXGLOG,
automatically.
Major CHANGES added in MXG 33.11, dated Nov 2, 2015:
Reason for this new version:
TYPE110 33.257 CICS/TS 5.3 BETA CICSTRAN new field added INCOMPAT
This should be the last REQUIRED MXG update for CICS/TS 5.3.
New Products Support:
TYPEXAM 33.259 Support for zVPS Release 4230 for z13 SMT mode.
Enhancements:
TYPEIMST 33.252 Variable SYSTEM can be added to TYPE56FA with SYSPARM
Major CHANGES added in MXG 33.10, dated Oct 20, 2015:
New Products Support:
TYPE121 33.231 Support for JZOS Java Runtime Performance SMF 121.
TYPEATF 33.245 Support for OMEGAMON ATF IMS Log Record LCODE A2.
TYPE6 33.233 Support for APAR OA46136 adds IPADDR in PSF SMF 6.
TYPEVMXA 33.242 Support for zVM 6.3.15.0 VXSYSPRT for z13 SMT mode.
TYPERACF 33.238 Support for RACF IRRDBU00 Record Type 1560.
TYPEEDA 33.237 Support for EDA V7706 (INCOMPATIBLE, data inserted).
TYPETPMX 33.232 Support for Thruput Manager VARNAME=$ORIGIO.
TYPEDOS 33.248 Support for zVSE/Power Version 9 Release 2 accounting
Enhancements:
ANALCAPD 33.225 Major revision to analysis of Capping, now by LPAR.
ASMRMFV 33.222 RMF III DVT Character data Filtering saves DASD.
ANAL2642 33.230 Example to select TYPE26 and match with TYPE42.
ANAL1430 33.230 Example to select TYPE14 and match with TYPE30.
VMACUCB 33.245 DEVCLASS=41 decode identifies specific CTC type.
TYPE80A 33.243 RACF Type 80 record "subtypes" (RACFEVNT) for ANALID.
IMAC30IO 33.240 EXCPxxxx and IOTMxxxx can be dropped for nonexistent.
TYPE7072 33.239 New _KTY70DR to drop variables from TYPE70 dataset.
TYPE102 33.236 All DB2 zPARM QWP4xxxx fields are now correct.
TYPE42 33.230 Summed vars S42READS,S42WRITES added to TYPE42DS.
Error Corrections:
TYPE74 33.234 TYPE74HO false duplicates were being removed.
TYPENDM 33.229 NDM PT records INPUT EXCEEDED, INCOMPAT inserts.
TYPE22 33.227 Dataset TYPE22PB RECONFIG PCIE had zero observations.
TYPE74 33.228 SMF 74 St 9 z/OS 2.1 z/13 INPUT STATEMENT EXCEEDED.
TYPE103 33.223 Short SMF 103 Subtype 13 INPUT EXCEEDED error.
TYPE102 33.250 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED.
Major CORRECTIONS added in MXG 33.09, dated Sep 15, 2015:
ASMTAPEE 33.207 ML-55 of ASMTAPEE/MXGTMNT REQUIRED for z/OS 2.2.
IBM changes cause ABEND S0E0-28, must reassemble.
TYPE7072 33.217 z13, SMT Mode, error: LPARCPUS=0 in PDB.TYPE70PR.
TYPE110 33.198 CICS/TS 5.3 BETA, MNSEGCL=5, INPUT STATEMENT EXCEEDED
IBM inserted new data. Datasets CICSRDS/RDFI/RDQU.
TYPETMO2 33.210 More TMON/CICS Version 3 and Version 4 corrections.
MONITASK in V3.3 fixed, MONISYST in V3.3 and 4.0.
ASG APAR corrects two obscure fields in 4.0.
TYPE7072 33.216 Support for APAR OA47042 WLM MOBILE Resources in RMF.
TYPECDC 33.201 Support IBM INFOSPHERE CHANGE DATA CAPTURE CDC V10.2
TYPEAXWY 33.199 Support for AXWAY SMF record, INCOMPATIBLE, inserts.
TYPE120 33.213 Support for WASODM Operational Decision Manager 8.7.
TYPEMGCR 33.212 Support for MEGACRYPTION Version 6, INCOMPATIBLE.
TYPE30 33.206 z/OS 2.2 Job Correlation SMF30COR input/kept.
BUILDPDB 33.204 Variable IOTMNODD was never calculated in PDB.JOBS.
TYPEXAM 33.202 Velocity ZVPS 5.4 XAMSYT had zero observations.
TYPE113 33.197 Variable LPBUSY created in ASUM113 like TYPE113.
TYPEDB2 33.205 DB2ACCTP variables QPACPKID/LOCN/ may be truncated.
TYPEBVIR 33.196 TCVSIZE is now MGBYES, AVGCPUSE/DEFTH corrected.
TYPE70 33.200 TYPE70xx datasets now have VARYed interval data kept.
Major CORRECTIONS added in MXG 33.08, dated Aug 20, 2015:
CRITICAL, REQUIRED CHANGES (that caused redate/refresh of 33.08):
TYPETMO2 33.195 TMON/CICS Version 4 was still wrong in 1st 33.08.
Major enhancements added in FIRST MXG 33.08, dated Aug 18, 2015:
CRITICAL, REQUIRED CHANGES:
TYPE7072 33.186 z13 INCOMPATIBLE ERROR, SMT-MODE, if VARY CP online.
The VARY put the new CP after the IIPs which broke
MXG logic so the new engine was not seen, causing the
CPU metrics to be wrong for all intervals after the
VARY, requiring redesign of the MXG SMT logic.
TYPETMO2 33.188 TMON/CICS Version 4.0, REQUIRED, MXG coding error.
TYPESYNC 33.184 Support for SYNCSORT Release 1.4 (INCOMPAIBLE).
NEW SUPPORT ITEMS:
TYPExxxx 33.189 Support for z/OS 2.2 COMPATIBLE, but many additions.
TYPEMAR 33.183 Support for MAR Hitachi Command Suite Mainframe
VMAC115 33.180 Support for MQ Version 8 subtype 215 record
TYPEBBMQ 33.175 New IHDRBBMQ "Infile Header Exit" for selection.
ASMRMFV 33.182 New filters for RMF III ASI Filtering reading RMFVSAM
CORRECTIONS:
TYPE74 33.185 zEDC TYPE749 zero divide fixed, R749DFMT formatted.
TYPE70PR 33.174 IFL Processor count corrected to number in LPAR.
TYPE7072 33.179 TYPE70EN z13 SMT Mode, blank LPARNAME, SMF70MTTT fix.
TYPE113 33.173 z13 SM1132SP incorrectly forced, should be 5000 MHz.
OTHER ENHANCEMENTS:
TYPE102 33.187 Dataset T102S106 zPARM variables added.
TYPE30 33.185 zEDC variables labels now INFLATE/DEFLATE.
RMFINTRV 33.181 Enhancement to ADD variables to be kept in RMFINTRV.
JCLPDB9 33.178 JCL Example for BUILDPDB, ANALxxxx members revised.
Major enhancements added in MXG 33.07, dated Jul 20, 2015:
TYPE120 33.171 Many SMF 120 ST 9 UNEXPECTED MULTIPLE SEGMENT on log
Major enhancements added in MXG 33.07, dated Jul 17, 2015:
TYPE74 33.155 TYPE74ST now has SCM variables, TYPE74MO is no more.
TYPE78 33.156 Support for APAR OA44525, zHPF Extended Distance II.
TYPE115 33.151 Support for MQ V8.0 MQCHIN, ERROR.VMAC115.OFFQCCT.
TYPE116 33.151 Support for MQ V8.0 MQCHININ, ERROR.VMAC116.LENQWHS.
TYPE119 33.144 Support for Type 119 new subtypes 94 and 95.
TYPECZA 33.166 Support for Correlog z/OS Agent User SMF record.
MXGLOGDO 33.162 "MXGLOG" option to send MXG Messages to MXGLOG.
TYPE22 33.146 New TYPE22PB dataset created for Reconfigured PCIE.
SMFSRCH 33.159 Support for compressed SMF in SMFSRCH LOOKFOR
ANALID 33.159 Support for compressed SMF for DB2 Version/Subtype.
ANALQBAT 33.147 Analysis of Batch Queue Times SMF30HQT/JQT/RQT/SQT.
TYPEXAM 33.157 zVM XAM ERROR SYTCUP SEGMENT LENGTH corrected.
TYPEBVIR 33.145 BVIR VTS Grid dataset BVIR33 wrong for second plus.
TYPENDM 33.143 INPUT STATEMENT EXCEEDED NDM-CDI PT record.
IMAC6ESS 33.158 Type 6 ESS zero len segment INPUT STATEMENT EXCEEDED.
Major enhancements added in MXG 33.06, dated Jun 11, 2015:
TYPERMFV 33.140 RMF III RCD records INCOMPATIBLY CHANGED for z13.
TYPE7072 33.138 z13 in SMT Mode zIIP variables in TYPE70xx datasets,
especially TYPE70EN, could be missing, or DUPLICATE
RECORD message could be printed. REQUIRED FOR SMT.
The MXG SMT support has come in several iterations as
new sequences of data exposed untested logic but this
appears to finally resolve the one-to-many merge.
If you testing SMT on z13, please email MXG Support
with subject: SMT UPDATES so we can inform you if
there are any further required changes for SMT mode.
Aug 17, 2015: MXG 33.08 is NOW required for SMT mode.
See Change 33.186.
TYPE30 33.132 Support for zEDC metrics in TYPE30 is now correct.
ANAL9914 33.139 z13 Processor Topology Report from SMF TYPE9914 data.
SMFSRCH 33.131 SMFSRCH enhancements, ANALID, LOOKFOR list, AND/OR.
TYPEAA 33.137 Support for Compuware ABEND-AID USER SMF Record.
TYPECIMS 33.136 Support for MainView for IMS 5.2 (a/k/a IMF).
TYPEOSEM 33.133 ZOSEM User SMF - INPUT STATEMENT EXCEEDED error.
TYPETMS5 33.129 Support for TMS new TRTCH values for TS1140.
ASUM113 33.130 Missing values in SMF70xx merged into PDB.ASUM113.
ANALDB2R 33.134 Number reports mis-reported,ANALID added, headings.
Major enhancements added in MXG 33.05, dated May 19, 2015:
Sites with z13 in SMT-mode or sites with zEDC need this refresh:
TYPE7072 33.128 Zero OBS in TYPE70 for non-SMT if SMT SMF read first
TYPE74 33.127 zEDC TYPE749 dataset was finally revised correctly.
Aug 17,2015 added: MXG 33.08 required for SMT mode.
Major enhancements added in MXG 33.05, dated May 12, 2015:
TYPE7072 33.121 z13 SMT-mode TYPE70/TYPE70PR data is WRONG 33.03-04.
ONLY SMT-mode type 70 records were wrong.
TYPETANZ 33.123 Support for Tandem ZMS Style records.
TYPEZCOS 33.116 Support for ZCOST AutoSoftCapping Version V3.0.00
SMFSRCH 33.117 SMFSRCH corrections, TYPE30_D now populated.
TYPEBBMQ 33.115 Mainview for Mq BBMQBUFF variables corrected.
TYPECIMS 33.114 IMF/CIMS variable CPUZIPTM was not KEPT in CIMSTRAN.
TYPE102 33.113 Some T102S106 DB2 zPARM values were misaligned/wrong.
TYPE120 33.120 New IHDR120 header exit created for TYPE120 tailoring
IMACICMX 33.119 The optional IMACICMX for length=384 had missing END.
Major enhancements added in MXG 33.04, dated Apr 29, 2015:
TYPE110 33.112 Support for CICS/TS 5.3 OPEN BETA (INCOMPATIBLE).
Note: IBM Changed CICS 5.3 Default to STGPROT=YES
Note: MXG 33.08-plus is required. Change 33.192.
TYPETMO2 33.099 TMON/CICS V3.4, MXG 32.13-33.03, TASCPUTM WRONG.
TYPEBBMQ 33.090 Support for BBMQ PTF BLL2458/BPL2459 (INCOMPAT)
TYPE42 33.108 Support for APARs OA45944,OA45897 new SMF 42 metrics.
TYPE74 33.087 Support for RMF 74 Subtype 9 zEDC Accelerator.
TYPESYNC 33.102A Support for SYNCSORT Release 2.1 (INCOMPATIBLE).
TYPEQACS 33.101 Support for iSeries 7.2 (COMPATIBLE, new LRECLs).
TYPEXAM 33.086 Support for Velocity Software zVPS XAM Version 5.4.
TYPENMON 33.104 Support for NMON CPUnr with three digits.
TYPE110 33.106 CICSEXCE variable EXCMTYPE decodes Exception type.
UTILCVRT 33.105 Alternate table needed for no TRANSCODE PROC CPORT.
ASMRMFV 33.100 Protect invalid ASI table index in UWD, 0C4 ABEND.
TYPE7072 33.096 z13 with SMT PROCVIEW=CORE, SMT-NUM not kept.
TYPENMON 33.092 Some NMON BBBPnnnn variables were mis-assigned.
Major enhancements added in MXG 33.03, dated Mar 29, 2015:
TYPE7072 33.071 FULL z13 SUPPORT. MXG 33.03 IS REQUIRED FOR SMT MODE,
i.e., for PROCVIEW CORE. FOR non-SMT, PROCVIEW CPU,
the many changes were COMPATIBLY made.
Aug 17,2015: See Change 33.186, MXG 33.08 IS NOW REQUIRED FOR SMT.
For SMT PROCVIEW CORE Mode, MXG Change 33.046 in 33.02
updated the TYPE70 dataset, but this Change 33.071 in MXG
33.03 is required to update the new SMT metrics correctly
in the TYPE70PR dataset, to get the CPUID, LCPUADDR, and
CORE_ID from the four segments that don't have the same
number of segments: OFFCPUD and SMF70COS have 20 for the
6 online CPs, 4 offline CPs, and 5 zIIPs with CPU_NUM=2,
while SMF70BDN/LPARCPUX has only 18 segments (with the
CORE_NUM needed to look-up the LCPUADDR), and there are
only 14 Core_ID values.
This was a complex update to a CRITICAL MXG MEMBER, with
500+ lines of code inserted lines into the 27,000 lines.
The SMT Mode data has been validated with RMF records,
with a wide range of LPAR configurations. When in SMT
mode, please examine the new data carefully and contact
support@mxg.com if you have questions.
Note: If you read the changed SMT mode RMF 70s with an
old MXG, RMFINTRV may have NEGATIVE CPUOVHTM values and
the %PCTCPUBY values may be over 100%.
TYPE99 33.053 Support for z13 updates to type 99 subtype 14.
TYPE113 33.052 z13 Support for HIS SMF 113, many new equations.
UTILEXCL 33.049 New reports, trans without dictionary, READTIME.
VMXGINIT 33.062 %LET MXGDEBUG=FULL; shows OPTIONS, enables diags.
TYPEDOL 33.060 DCOLLECT Cluster/Multi-VOL now have Class variables.
TYPE102 33.067 DB2 Trace IFCID=220 misaligned, ILLEGAL ARGUMENT.
TYPE105 33.061 GDPS SMF 105 INPUT STATEMENT EXCEED if no XVMX seg.
ANALDB2R 33.069 SAS 9.3 does not have dictionary for DESTINATIONS.
TYPEDB2 33.068 Variable Q8STCCPU not kept after Change 30.133.
TYPETHAO 33.059 Support for Thales Security Resource Mgr RF1100.
FTPING 33.056 OPTIONS OBS=0 fails read with ftp access method.
ANALHSM 33.050 Graphics part had a NOT SORTED condition.
TYPETPMX 33.070 TOKENID INCLAI, three $LIST_L and $RESTAR added.
Many 33.078 All %MACROs from SASAUTOS are replaced by %SYSFUNC()
Major enhancement added in MXG 33.02, dated Feb 27, 2015:
Many 33.046 Support z/OS on z13 RMF/SMF APARs for z/OS 2.1+
MXG 33.01 CHANGES noted one z13 site had NEGATIVE CPUOVHTM,
but that was ONLY IF z/OS on z13 is in MULTI-THREADING MODE.
MXG was unaware of IBM's restructuring the RMF type 70 SMF
record's calculation of CPU BUSY time for the new MT mode,
but this MAJOR CHANGE restructured TYPE70 processing in MXG
to order by CORE_ID and CPU_NUM rather than CPUID/LCPUADDR.
If you have ANY non-MXG programs that read RMF 70s to get the
CPU BUSY time, they MUST BE REWRITTEN for MT Mode records.
A Technical Newsletter note on Multi_Threading is planned;
this original note then stated an initial opinion of mine:
"although relatively few sites have workloads that will be
able to exploit that architecture, which can increase thruput
but elongate individual tasks elapsed time", but I've changed
my opinion about "relatively few sites": ANY SITE with zIIPs
or IFLs are VERY LIKELY to find SMT to be a benefit.
Major enhancement added in MXG 33.01, dated Feb 23, 2015:
Many 33.023 Support z/OS on z13 RMF/SMF APARs (z/OS: COMPATIBLE)
However: One site's z13 stress test shows TYPE70 CPU time MUCH LESS
than TYPE72 Service Class CPU time (which matches 30s) for
many intervals, but valid data before and after the test,
causing NEGATIVE CPUOVHTM messages on the log and RMFINTRV
observations will have negative CPUOVHTM (uncaptured CPU).
NOTE: THIS ERROR WAS CORRECTED IN MXG 33.02, SEE ABOVE NOTE.
TYPEVMXA 33.016 Support for zVM 6.3 on z13 (INCOMPATIBLE).
TYPEMWLX 33.037 Support for HP MeasureWare for Linux -
VMAC30 33.005 Support for APAR OA45767 adds zEDC statistics.
TYPEBBMQ 33.030 Support for BMC Mainview for MQ 5.2 (REQUIRED)
TYPENTMU 33.028 Support for EDS User SMF Record from NETMENU program.
TYPEXPTR 33.040 Support for SystemWare XPTR 5.2 subtype 140, ex-st-40
SMFSRCH 33.041 SMFSRCH redesigned to read the SMFOUT with UTILBLDP.
ASUM70PR 33.032 New SMF70WTI/WTS/WTU added to ASUM70LP/ASUMCELP
MOBWRKSU 33.039 Summarization of Mobile Work CSV file combines split.
TYPEDB2 33.025 QBSTBPIN, Buffer Pool I/O Intensity, added DB2STATB.
RMFINTRV 33.024 ANY work in service class SYSOTHER, new log messages.
ASMRMFV 33.021 ASMRMFV skips RCD if no Reporting Classes defined.
TYPEQACS 33.020 iSeries change in record length can force USER ABEND.
TYPE60 33.038 Type 60 with no VVR INPUT STATEMENT EXCEEDED again.
TYPE80A 33.036 RACF SMF 80 record, TOKxxxxx fields increased length
TYPEIMS 33.034 Variables SYSABEND,USRABEND decoded in IMS56FA.
TYPEVMXA 33.043 zVM VXUSEACT/VXUSEINT NOT SORTED ERROR.
UTILBLDP 33.042 Using INCLAFTR=BUIL3005 for JES3 PDB.TYPE25 not found
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M3 (9.4M3) printed
as "SAS 9.4 (TS1M3)" or was "SAS 9.4 (TS04.01M2P07232014)" for
"SAS 9.4 (TS1M2)" (on SASLOG, if OPTION VERSIONLONG enabled),
for SAS 9.4 Maintenance Level M3 and m2.
SAS V9.4 M3 Is RECOMMENDED, but MXG executes without error using
SAS Version 9.4 M0, M1, M2, and M3 or SAS Version 9.2 M1 and M2.
SAS V9.4 M2 Is RECOMMENDED. SAS 9.4 M2 is at LEVEL A SAS Support
SAS V9.4 M1 and M0 had no errors and are at LEVEL A SAS Support
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03. SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit, but SAS V9.2 does execute ok.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 must be at Service Pack 4. Additionally, on z/OS 1.10
only, 9.1.3 requires SAS Hot Fix for SN-35332.
9.1.3 is support level C by SAS Institute, Sep 30, 2013.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS V8.2 IS SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS93 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 33.03 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG Versions
26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.4, on z/OS, on Windows Seven and
Eight (64-bit) on 64-bit hardware, and sometimes on Centos 6.4,
but MXG users execute MXG on MANY (ALL??) SAS platforms, including
AIX, Linux, and other 'nix' variants, on many different hardware
platforms, and since they all work we don't need to list them. If
SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 3.1.1 maintenance level 731 required for PDB to tape
WPS Version 3.01 (also shows 3.1.1) is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS Hardware changes, but:
The z/EC12 with 85+ engines required MXG 30.07.
Support for 255 engines was added in MXG 31.04.
The z/13 with 61+ LPARs requires MXG 32.05 IF NON-SMT MODE.
However, for the z13 processor on z/OS, the new SMT-MODE RMF 70 was
INCOMPATIBLY CHANGED, and MXG 33.09 is REQUIRED (PCTCPUBY WRONG!), to
read the SMT-format RMF records (which are written if you have zIIP
engines AND have have enabled the new PROCVIEW CORE option for
Multi-Threading, even if only one thread is enabled).
The new zEDC compression hardware requires MXG 33.07 to support the
new metrics.
For z/VM, MXG REQUIRES MXG 33.02 to support the z/13 changes.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z/OS 2.2 COMPATIBLE CH 33.189 Aug 19, 2015 33.08
z/OS 2.2 MXGTMNT ABEND S0E0-28 Sep 15, 2015 33.09
REQUIRES ASMTAPE ML-55 Sep 15, 2015 33.09
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
zEC12 Nov 14, 2012 30.07
z13 non-SMT Mode May 27, 2014 32.05
z13 SMT Mode Change 33.217 Sep 15, 2015 *33.09
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 *29.05
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 *30.01
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 *30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 *30.30
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 *31.03
CICS-TS/5.2 COMPATIBLE CICSTRAN Jun 13, 2014 *31.03
CICS-TS/5.2 INCOMPAT Statistics Jun 13, 2014 *32.03
CICS-TS/5.3 INCOMPAT CICSTRAN Apr 29, 2015 33.04
CICS-TS/5.3 OPEN BETA Sep 31, 2015 33.08
CICS-TS/5.3 RESOURCE SEGCL=5 Sep 31, 2015 33.09
CICS-TS/5.3 CICSTRAN INCOMPATIBL Oct 29, 2015 33.11
CICS-TS/5.3 GA date Dec 11, 2015 33.??
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 *23.09
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 *28.07
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 *28.28
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 *29.07
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 *30.07
DB2 10.1 DBID/OBID decode Jan 21, 2013 *30.30
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 *31.04
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 *27.01
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 *26.01
IMS log 10.1 Mar 06, 2007 *26.01
IMS log 11.1 Apr 1, 2010 *28.02
IMS log 12.1 Jan 23, 2012 *29.29
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
IMS log 14.1 COMPATIBLE Dec 19, 2015 33.13
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
TMON/CICS 3.4 (for CICS/TS 5.1) 30.30-32.12
(Do not use 32.13,32.32,33.01,33.02,33.03 for 3.4)
TMON/CICS 3.4 (for CICS/TS 5.1 - Change 33.099) 33.04
TMON/CICS 4.0 (for CICS/TS 5.2 - Change 33.195) *33.09
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
The Monitor for MVS/ESA 3.0 - 19.19
TMON/MVS Version 4.4 32.04
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V11R2 SMF 102 33.11 33.264
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
IMF 3.3 (for IMS 7.1 and 8.1) *22.08
IMF 4.1 (for IMS 9.1) *26.02
IMF 4.4 (for IMS 9.1) *31.08
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS *31.08
IMF 5.1 a/k/a Mainview IMS 31.08
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for MQ Version 5.2 33.01
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
SYNCSORT
2.1 33.05
1.4 33.08
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
XVPS 4.2 31.06
ZVPS 5.4 *33.07
V. Incompatibilities and Installation of MXG 33.33.
1. Incompatibilities introduced in MXG 33.33:
a- Changes in MXG architecture made between 33.33 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 33.33 after MXG 32.32:
Dataset/
Member Change Description
ANAL1430 33.230 Example to select TYPE14 and match with TYPE30.
ANAL2642 33.230 Example to select TYPE26 and match with TYPE42.
ANAL9914 33.139 z13 Processor Topology Report from SMF TYPE9914 data.
ANALACTM 33.312 Correction for more than one service policy.
ANALCAPD 33.225 Major revision to analysis of Capping, now by LPAR.
ANALDB2R 33.069 SAS 9.3 does not have dictionary for DESTINATIONS.
ANALDB2R 33.134 Number reports mis-reported,ANALID added, headings.
ANALHSM 33.050 Graphics part had a NOT SORTED condition.
ANALID 33.159 Support for compressed SMF for DB2 Version/Subtype.
ANALIDDY 33.290 ANALIDDY tabulates ANALID SMF data by date.
ANALQBAT 33.147 Analysis of Batch Queue Times SMF30HQT/JQT/RQT/SQT.
ASMRMFV 33.021 ASMRMFV skips RCD if no Reporting Classes defined.
ASMRMFV 33.100 Protect invalid ASI table index in UWD, 0C4 ABEND.
ASMRMFV 33.182 New filters for RMF III ASI Filtering reading RMFVSAM
ASMRMFV 33.222 RMF III DVT Character data Filtering saves DASD.
ASMRMFV 33.274 ASMRMFV Updates.
ASMTAPEE 33.207 ML-55 of ASMTAPEE/MXGTMNT REQUIRED for z/OS 2.2.
ASUM113 33.130 Missing values in SMF70xx merged into PDB.ASUM113.
ASUM70PR 33.032 New SMF70WTI/WTS/WTU added to ASUM70LP/ASUMCELP
ASUMCELP 33.306 Variables SMF70GNM, SMF70GMU, SMF70WLA added.
BLDSMPDB 33.031 Wrong Start Week date with FORCEDAY and low case.
BUILDPDB 33.204 Variable IOTMNODD was never calculated in PDB.JOBS.
FTPING 33.056 OPTIONS OBS=0 fails read with ftp access method.
IMAC30IO 33.240 EXCPxxxx and IOTMxxxx can be dropped for nonexistent.
IMAC6ESS 33.158 Type 6 ESS zero len segment INPUT STATEMENT EXCEEDED.
IMACICMX 33.119 The optional IMACICMX for length=384 had missing END.
ITRM 33.301 ITRM users MUST use %LET EPDBOUT= _SDB2SBP.
JCLASMXG 33.275 Assemble/Link Edit all five MXG ASM programs install.
JCLPDB9 33.178 JCL Example for BUILDPDB, ANALxxxx members revised.
MANY 33.046 SUPPORT for z13 processor in MULTITHREADING MODE.
MOBWRK02 33.279 Support for DB2 Simulated Buffer Pool dataset.
MOBWRKSU 33.039 Summarization of Mobile Work CSV file combines split.
RMFINTRV 33.024 ANY work in service class SYSOTHER, new log messages.
RMFINTRV 33.181 Enhancement to ADD variables to be kept in RMFINTRV.
SMFSRCH 33.041 SMFSRCH redesigned to read the SMFOUT with UTILBLDP.
SMFSRCH 33.117 SMFSRCH corrections, TYPE30_D now populated.
SMFSRCH 33.131 SMFSRCH enhancements, ANALID, LOOKFOR list, AND/OR.
SMFSRCH 33.159 Support for compressed SMF in SMFSRCH LOOKFOR
SMFSRCH 33.307 Support for multiple text strings in LOOKFOR=.
TYPE102 33.067 DB2 Trace IFCID=220 misaligned, ILLEGAL ARGUMENT.
TYPE102 33.113 Some T102S106 DB2 zPARM values were misaligned/wrong.
TYPE102 33.126 BMC APPTUNE 102 INPUT EXCEEDED if DATA SHARING.
TYPE102 33.187 Dataset T102S106 zPARM variables added.
TYPE102 33.236 All DB2 zPARM QWP4xxxx fields are now correct.
TYPE102 33.250 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED.
TYPE102 33.264 Support for APPTUNE 11.2 INCOMPATIBLE change in 8005.
TYPE102 33.273 DB2 SMF 102 IFCID=109 INVALID DO LOOP CONTROL ERROR.
TYPE102 33.294 SMF 102 IFCIDs 81E5-8160,8051x INPUT EXCEEDED DRROR
TYPE103 33.223 Short SMF 103 Subtype 13 INPUT EXCEEDED error.
TYPE105 33.061 GDPS SMF 105 INPUT STATEMENT EXCEED if no XVMX seg.
TYPE110 33.106 CICSEXCE variable EXCMTYPE decodes Exception type.
TYPE110 33.198 CICS/TS 5.3 BETA, MNSEGCL=5, INPUT STATEMENT EXCEEDED
TYPE110 33.257 CICS/TS 5.3 CICSTRAN (final) new field added INCOMPAT
TYPE110 33.326 MXG 32.10-First MXG 33.33. Increased CPU in SMF 110s
TYPE113 33.052 z13 Support for HIS SMF 113, many new equations.
TYPE113 33.173 z13 SM1132SP incorrectly forced, should be 5000 MHz.
TYPE113 33.197 Variable LPBUSY created in ASUM113 like TYPE113.
TYPE115 33.151 Support for MQ V8.0 MQCHIN, ERROR.VMAC115.OFFQCCT.
TYPE116 33.151 Support for MQ V8.0 MQCHININ, ERROR.VMAC116.LENQWHS.
TYPE119 33.144 Support for Type 119 new subtypes 94 and 95.
TYPE119 33.262 Support for SMF 119 subtypes 2, 5, 6, 7, 41-44, 97.
TYPE120 33.120 New IHDR120 header exit created for TYPE120 tailoring
TYPE120 33.213 Support for WASODM Operational Decision Manager 8.7.
TYPE120 33.267 SMF 120 dataset TYP120JI only output first instance.
TYPE121 33.231 Support for JZOS Java Runtime Performance SMF 121.
TYPE1415 33.270 Variable SMF14ALIAS misspelled so it was not kept.
TYPE22 33.146 TYPE22PB dataset created for Reconfigured PCIE.
TYPE22 33.227 Dataset TYPE22PB RECONFIG PCIE had zero observations.
TYPE30 33.132 New zEDC metrics in TYPE30 are now correct.
TYPE30 33.185 zEDC variables labels now INFLATE/DEFLATE.
TYPE30 33.206 z/OS 2.2 Job Correlation SMF30COR input/kept.
TYPE42 33.108 Support for APARs OA45944,OA45897 new SMF 42 metrics.
TYPE42 33.230 Summed vars S42READS,S42WRITES added to TYPE42DS.
TYPE42 33.316 New variables compatibly added by z/OS 2.2.
TYPE6 33.233 Support for APAR OA46136 adds IPADDR in PSF SMF 6.
TYPE60 33.038 Type 60 with no VVR INPUT STATEMENT EXCEEDED again.
TYPE64 33.316 New variables compatibly added by z/OS 2.2.
TYPE70 33.200 TYPE70xx datasets now have VARYed interval data kept.
TYPE7072 33.071 z13 SUPPORT. MXG 33.03 REQUIRED ONLY FOR SMT MODE
TYPE7072 33.096 z13 with SMT PROCVIEW=CORE, SMT-NUM not kept.
TYPE7072 33.121 z13 SMT-mode TYPE70/TYPE70PR data is WRONG 33.03-04.
TYPE7072 33.125 SMF70CAN/CTN restored, CPUWAIT-LPARBUSY for zIIPs.
TYPE7072 33.128 Zero OBS in TYPE70 for non-SMT if SMT SMF read first
TYPE7072 33.138 z13 in SMT Mode, TYPE70EN had missing values for ZIP.
TYPE7072 33.179 TYPE70EN z13 SMT Mode, blank LPARNAME, SMF70MTTT fix.
TYPE7072 33.186 z13 INCOMPATIBLE ERROR, SMT-MODE, when VARY CP online
TYPE7072 33.217 z13 in SMT MODE ONLY: LPARCPUS=0 in PDB.TYPE70PR
TYPE7072 33.239 New _KTY70DR to drop variables from TYPE70 dataset.
TYPE7072 33.280 PDB.TYPE70 z13 SMT mode ZIPCPUS value may be wrong.
TYPE7072 33.318 Data Set SORT70EC NOT SORTED corrected with sort.
TYPE70EC 33.318 Data Set SORT70EC NOT SORTED, configuration changed.
TYPE70PR 33.174 IFL Processor count corrected to number in LPAR.
TYPE71 33.316 New variables compatibly added by z/OS 2.2.
TYPE74 33.087 Support for RMF 74 Subtype 9 zEDC Accelerator.
TYPE74 33.127 zEDC TYPE749 dataset was finally revised correctly.
TYPE74 33.155 TYPE74ST now has SCM variables, TYPE74MO is no more.
TYPE74 33.185 zEDC TYPE749 zero divide fixed, R749DFMT formatted.
TYPE74 33.228 SMF 74 St 9 z/OS 2.1 z/13 INPUT STATEMENT EXCEEDED.
TYPE74 33.234 TYPE74HO false duplicates were being removed.
TYPE74 33.305 z/OS 2.2 RMF 74 Subtype 10 creates TYPE7410/TYPE74SC.
TYPE74 33.316 New variables compatibly added by z/OS 2.2.
TYPE78 33.156 Support for APAR OA44525, z HPF Extended Distance II.
TYPE78 33.305 z/OS 2.2 new variables in TYPE78PA.
TYPE80A 33.036 RACF SMF 80 record, TOKxxxxx fields increased length
TYPE80A 33.243 RACF Type 80 record "subtypes" (RACFEVNT) for ANALID.
TYPE99 33.053 Support for z13 updates to type 99 subtype 14.
TYPE99 33.308 New variables compatibly added by z/OS 2.2.
TYPEAA 33.137 Support for Compuware ABEND-AID USER SMF Record.
TYPEATF 33.245 Support for OMEGAMON ATF IMS Log Record LCODE A2.
TYPEAXWY 33.199 Support for AXWAY SMF record, INCOMPATIBLE, inserts.
TYPEBBMQ 33.030 Support for BMC Mainview for MQ 5.2 (REQUIRED)
TYPEBBMQ 33.090 Support for BBMQ PTF BLL2458/BPL2459 (INCOMPAT)
TYPEBBMQ 33.115 Mainview for Mq BBMQBUFF variables corrected.
TYPEBBMQ 33.175 New IHDRBBMQ "Infile Header Exit" for selection.
TYPEBVIR 33.145 BVIR VTS Grid dataset BVIR33 wrong for second plus.
TYPEBVIR 33.196 TCVSIZE is now MGBYES, AVGCPUSE/DEFTH corrected.
TYPECDC 33.201 Support IBM INFOSPHERE CHANGE DATA CAPTURE CDC V10.2
TYPECIMS 33.114 IMF/CIMS variable CPUZIPTM was not KEPT in CIMSTRAN.
TYPECIMS 33.136 Support for MainView for IMS 5.2 (a/k/a IMF).
TYPECZA 33.166 Support for Correlog z/OS Agent User SMF record.
TYPEDB2 33.025 QBSTBPIN, Buffer Pool I/O Intensity, added DB2STATB.
TYPEDB2 33.068 Variable Q8STCCPU not kept after Change 30.133.
TYPEDB2 33.142 Variables QWACATWT and QWACPQCT corrected.
TYPEDB2 33.205 DB2ACCTP variables QPACPKID/LOCN/ may be truncated.
TYPEDB2 33.279 Support for DB2 Simulated Buffer Pool PDB.DB2STSBP.
TYPEDB2 33.303 Multiple DB2 100 Subtype 1 created multiple DB2STATS.
TYPEDOL 33.060 DCOLLECT Cluster/Multi-VOL now have Class variables.
TYPEDOS 33.248 Support for zVSE/Power Version 9 Release 2 accounting
TYPEEDA 33.237 Support for EDA V7706 (INCOMPATIBLE, data inserted).
TYPEID 33.045 ANALID report printed '110.001' vice '110.1.1'.
TYPEIMS 33.034 Variables SYSABEND,USRABEND decoded in IMS56FA.
TYPEIMS 33.298 Support for IMS 14.1 log records (COMPATIBLE)
TYPEIMST 33.252 Variable SYSTEM can be added to TYPE56FA with SYSPARM
TYPEMAR 33.183 Support for MAR Hitachi Command Suite Mainframe
TYPEMGCR 33.212 Support for MEGACRYPTION Version 6, INCOMPATIBLE.
TYPEMWLX 33.037 Support for HP MeasureWare for Linux -
TYPENDM 33.143 INPUT STATEMENT EXCEEDED NDM-CDI PT record.
TYPENDM 33.229 NDM PT records INPUT EXCEEDED, INCOMPAT inserts.
TYPENMON 33.092 Some NMON BBBPnnnn variables were mis-assigned.
TYPENMON 33.104 Support for NMON CPUnr with three digits.
TYPENTMU 33.028 Support for EDS User SMF Record from NETMENU program.
TYPEOSEM 33.133 ZOSEM User SMF - INPUT STATEMENT EXCEEDED error.
TYPEQACS 33.020 iSeries change in record length can force USER ABEND.
TYPEQACS 33.101 Support for iSeries 7.2 (COMPATIBLE, new LRECLs).
TYPERACF 33.238 Support for RACF IRRDBU00 Record Type 1560.
TYPERMFV 33.140 RMF III RCD records INCOMPATIBLY CHANGED for z13.
TYPESYNC 33.102A Support for SYNCSORT Release 2.1 (INCOMPATIBLE).
TYPESYNC 33.184 Support for SYNCSORT Release 1.4 (INCOMPAIBLE).
TYPETANZ 33.123 Support for Tandem ZMS Style records.
TYPETHAO 33.059 Support for Thales Security Resource Mgr RF1100.
TYPETMO2 33.099 TMON/CICS V3.4, MXG 32.13-33.03, TASCPUTM WRONG.
TYPETMO2 33.188 TMON/CICS Version 4.0, REQUIRED, MXG coding error.
TYPETMO2 33.210 More TMON/CICS Version 3 and Version 4 corrections.
TYPETMS5 33.129 Support for TMS new TRTCH values for TS1140.
TYPETPMX 33.070 TOKENID INCLAI, three $LIST_L and $RESTAR added.
TYPETPMX 33.232 Support for Thruput Manager VARNAME=$ORIGIO.
TYPETPMX 33.265 ThruputMgr TPMSLM variables TPMSLXGF/LXGN wrong.
TYPEVMXA 33.043 zVM VXUSEACT/VXUSEINT NOT SORTED ERROR.
TYPEVMXA 33.242 Support for zVM 6.3.15.0 VXSYSPRT for z13 SMT mode.
TYPEVMXA 33.299 Support for zVM 6.3 MONWRITE z13 SMT MODE.
TYPEVMXA 33.327 Data set VMBYUSR missing many observations.
TYPEXAM 33.086 Support for Velocity Software zVPS XAM Version 5.4.
TYPEXAM 33.157 zVM XAM ERROR SYTCUP SEGMENT LENGTH corrected.
TYPEXAM 33.202 Velocity ZVPS 5.4 XAMSYT had zero observations.
TYPEXAM 33.259 Support for zVPS Release 4230 for z13 SMT mode.
TYPEXAM 33.266 MXG 33.11 only. ERROR VARIABLE SYTPN NOT FOUND.
TYPEXAM 33.320 Support for zVPS z13 SMT mode new variables.
TYPEXAM 33.324 zVPS variable CALENTMT changed from numeric, conflict
TYPEXPTR 33.040 Support for SystemWare XPTR 5.2 subtype 140, ex-st-40
TYPEZCOS 33.116 Support for ZCOST AutoSoftCapping Version V3.0.00.
UTILBLDP 33.042 Using INCLAFTR=BUIL3005 for JES3 PDB.TYPE25 not found
UTILBLDP 33.159 BUILDPDB=NO incorrect for type 102 2 byte subtypes.
UTILCVRT 33.105 Alternate table needed for no TRANSCODE PROC CPORT.
UTILEXCL 33.049 New reports, trans without dictionary, READTIME.
UTILEXCL 33.255 ARRAY EXCEEDED when more than 999 connectors.
VGETDDS 33.208 z/OS Only. Multiple tape mounts with DDNAMES=PDB:.
VMAC115 33.180 Support for MQ Version 8 subtype 215 record
VMAC30 33.005 Support for APAR OA45767 adds zEDC statistics.
VMACUCB 33.245 DEVCLASS=41 decode identities specific CTC type.
VMXGALOC 33.325 Correction for WEEK1 allocation.
VMXGINIT 33.062 %LET MXGDEBUG=FULL; shows OPTIONS, enables diags.
VMXGINIT 33.162 "MXGLOG" option to send MXG Messages to MXGLOG.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at http://www.mxg.com
Inverse chronological list of all Changes:
NEXTCHANGE
====== Changes thru 33.327 were in MXG 33.33 dated Jan 18, 2016=========
Change 33.327 Dataset VMBYUSR was missing many observations because the
VMACVMXA timestamp in MRHDRTOD in VXUSEACT did not exactly match
Jan 15, 2016 the MRHDRTOD in VXUSEINT which are key MERGE variables.
Circumvention was to merge with the FLOOR(MRHDRTOD).
Thanks to Joe Faska, DTCC, USA.
Change 33.326 -MXG 32.10-MXG 33.33. Increase in CPU time for SMF 110
VMAC110 record processing, 300 to 500 seconds, 22 GB, due to
Jan 15, 2016 multiple executions of RESOLVE function where only one
was needed, to populate character variable CICXLTR, which
is only used to enhance error messages if EXCLUDED fields
are found.
-Too many warning messages were printed if Compressed CICS
data was read on z/OS without the CICSIFUE INFILE exit,
and too many "ok on ASCII" messages were printed.
Thanks to Perry Lim, Union Bank, USA.
Change 33.325 -Change 32.220 added new BASECICS and BASEDB2 parameters
BLDSMPDB that let you send DB2 and/or CICS datasets to a different
VMXGALOC drive, but did not tell you that if you did not use them,
UTILBLDP those datasets were written to BASEDIR. Default is now
Jan 17, 2016 a NULL string so that behavior is unchanged and the log
Jan 18, 2016 now notes where CICSTRAN and DB2ACCT are allocated.
-Change 32.262 incorrectly set the WEEK WEEK1 libnames to
be the current week when RUNWTD was NO and when RUNWTD
was YES the WTD LIBNAME was not allocated. Fortunately,
the only exposure is that if a user wanted to run a
report with WEEK1, it would have been empty since the
week had not been run to populate it.
-UTILBLDP failed to include ASUMDBSS because an AND in the
macro was misspelled as AMD and the compiler does not see
it as a syntax error.
-BLDSMPDB debugging statements left in code.
Thanks to Richard Krueger, Sentry, USA.
Change 33.324 zVPS variable CALENTMT was changed from numeric to char
VMACXAM causing a conflict if OLD and NEW datasets were combined.
Jan 13, 2016 CALENTMT is restored to CHAR, new variable CALENTMTN has
the actual numeric CPU ENTITLEMENT value.
Thanks to David A. Sadler, OPTUM, USA.
Change 33.323 New fields added to Thruput Manger are supported:
VMACTPMX CONTR ='CONTR'
Jan 12, 2016 JCL_SJB ='JCL_SJB'
JCL_SJC ='JCL_SJC'
JCL_SJG ='JCL_SJG'
JAL_T ='JAL_T'
There is a defective entry with ' ST_L' that should be
'LIST_L' that prints an error message that it was skipped
while we investigate with the vendor.
Change 33.322 The new JOB Correlation Token SMF30COR and SMF26JCR are
VMAC26J2 populated with 64 bytes of '00'x for OMVS and most STCs,
VMAC30 which then print as 64 unprintable characters. The '00'X
Jan 12, 2016 are translated to blanks. But it is unclear why this new
token is created; the READTIME JOB JESNR uniquely match
and only require 24 bytes, and are in many more SMF
records than just these two.
====== Changes thru 33.321 were in MXG 33.33 dated Jan 11, 2016=========
Change 33.321 -Change 33.297 failed if OPTIONS USER=PDB is used, because
VMAC7072 the PROC DATASETS (to change a label) coded a LIB=WORK
Jan 9, 2016 which failed when USER=PDB. The LIB=&MXGWORK argument
Aug 31, 2017 now finds the dataset (replacing a WORK.TEMP70EN fix.)
-BUT: IN GENERAL MXG DOES NOT SUPPORT OPTIONS USER=PDB,
"out of the box": both BUILDPDB and UTILBLDP can fail
or can NOT fail but produce missing values when USER=PDB
is used, and it typically requires additional tailoring
for a specific purpose, especially when accumulated data
requires DIF(), and may require a second execution of
%VMXGINIT. Contact support@mxg.com if you have a need.
-Aug 2017: Note that using WORK=PDB in CONFIG has the same
exposure and thus that is also not supported.
Thanks to Scott Wiig, USBank, USA.
Change 33.320 Support for zVPS z13 SMT Mode adds these variables:
VMACXAM -Dataset XAMCPUTO:
Jan 7, 2016 CALENTMT='ENTITLEMENT'
CORID ='CORE*ID'
PFXPOLAR='POLARIZATION'
RCCTOPDI='DSVBK*INDEX'
TID ='THREAD*ID'
-Datasets XAMCPUBY, XAMIFLBY, XAMIFLTO, XAMCPUTO:
AVGTDBYCORE='AVG*TD*BY CORE'
AVGTDBYTYPE='AVG*TD*BY TYPE'
BUSYTIMEBYCORE='BUSY*TIME*BY CORE'
BUSYTIMEBYTYPE='BUSY*TIME*BY TYPE'
CAPBYTYPE='CAP*BY TYPE'
INTERVALTIMEBYCORE='INTERVAL*TIME*BY CORE'
INTERVALTIMEBYTYPE='INTERVAL*TIME*BY TYPE'
MAXCAPBYTYPE='MAX*CAP*BY TYPE'
MTUTILBYCORE='MT*UTIL*BY CORE'
MTUTILBYTYPE='MT*UTIL*BY TYPE'
PF2CADCT ='COUNT CAD*FOR*SPINLOCK*NODLAY'
PF2TSCAD ='COUNT CAD*DURING*TSGET*REQSTS'
PF2TSCNT ='COUNT*TSGET*REQUESTS'
PF2TSGTM ='ELAPSED*CONSUMED*BY TSGET'
PFXPRKWT ='PARKED*WAIT TIME*TOT UNIT'
PRODBYCORE='PROD*BY CORE'
PRODBYTYPE='PROD*BY TYPE'
SAMPLEDCORESBYTYPE='SAMPLED*CORES*BY TYPE'
SAMPLES='SAMPLES'
Change 33.319 The OPTION NONOTES statement added for the MXGLOG option
VMXGINIT must be reset to NOTES prior to the %MACRO statement. In
Jan 8, 2016 some cases the NONOTES remained incorrectly in effect,
Jan 22, 2016 which could suppress the INFILE SMF information and the
"dataset has nnn obs" notes on the SAS log. The Exposure
was limited to 33.07-33.13, and only with a tailored MXG
execution with a VIEW driven by a PROC SORT.
Jan 23: The OPTION NOTES was mis-located, suppressing the
printing of NOTE: Fileref=SOURCLIB and the DSNAMEs.
Thanks to Scott Wiig, US Bank, USA.
Change 33.318 Data Set SORT70EC NOT SORTED was corrected with an extra
VMAC7072 PROC SORT. It appears a change in the configuration was
Jan 5, 2016 made during the interval that caused the not sorted data.
Thanks to Paul Volpi, UHC, USA.
Change 33.317 Documentation of APARs corrections; NO CHANGES WERE MADE.
VMAC1415 -TYPE1415 APAR OA47899 corrects SMF 14/15 written at EOV
VMAC92 that did not contain the Type 1 Compressed Format data
VMAC74 set section.
VMAC80A -TYPE92 APAR OA49128 corrects invalid value in SMF92CTO.
VMAC116 -TYPE74 APAR OA48860 corrects SMF74DTS,SMF74DCT that are
Jan 3, 2016 not set correctly for a device after HYPERSWAP.
-TYPE80A APAR PI52900 for CICS/TS 5.2, adds CICS NETNAME
to SMF 80 record when DFHSN1102 SIGNON FAILS.
-TYPE116 APAR PI53551 MQ z/OS V8 Class 3 data may be
incorrect for CICS and CHIN Thread Control Blocks.
-Users of IBM CICS PA V5.1/5.2 NEED APAR PI43779 to
correct report files, especially LIST, that have file
blocking of ONE, wasting DISK space and CPU time.
Change 33.316 -The many new variables added in z/OS 2.2 in Change 33.189
VMAC42 are now kept.
VMAC64 -TYPE64 new variables
VMAC71 SMF64SSR='SECONDARY*SPACE*REDUCTION?'
VMAC74 SMF64FCC='BEGINNING*CCHH'
Dec 30, 2015 SMF64TCC='BENDING*CCHH'
SMF64VSN='VOLUME*SERIAL*NUMBER'
SMF64CUU='DEVICE*NUMBER'
SMF64IND='SPINDLE*IDENTIFICATION'
SMF64UTY='*UNIT*TYPE'
-TYPE71 new variables
SMF714KA='AVB*1MB FIXED*USED*4K REQ'
SMF714KM='MIN*1MB FIXED*USED*4K REQ'
SMF714KX='MAX*1MB FIXED*USED*4K REQ'
SMF71C2A='AVG*HIGH VIRTUAL*COMMON*1MB FIXED'
SMF71C2M='MIN*HIGH VIRTUAL*COMMON*1MB FIXED'
SMF71C2X='MAX*HIGH VIRTUAL*COMMON*1MB FIXED'
SMF71C3A='*AVG*HIGH VIRTUAL*SHARED*1MB CSTORE'
SMF71C3M='MIN*HIGH VIRTUAL*SHARED*1MB CSTORE'
SMF71C3X='MAX*HIGH VIRTUAL*SHARED*1MB CSTORE'
SMF71CPA='AVB*HI VIRT*COMMON*INUSE'
SMF71CPM='*MIN*HI VIRT*COMMON*INUSE'
SMF71CPX='*MAX*HI VIRT*COMMON*INUSE'
SMF71PLA='AVB*1MB PGBL*BACKED*1MB PGBL'
SMF71PLM='MIN*1MB PGBL*BACKED*1MB PGBL'
SMF71PLX='MAX*1MB PGBL*BACKED*1MB PGBL'
SMF71S2A='AVG*OBJECTS*SHARED MEM*BACK 1MB'
SMF71S2M='MIN*OBJECTS*SHARED MEM*BACK 1MB'
SMF71S2X='MAX*OBJECTS*SHARED MEM*BACK 1MB'
SMF71S3A='AVG*FRAMES*SHARED HIGH*4K*ON SCM'
SMF71S3M='MIN*FRAMES*SHARED HIGH*4K*ON SCM'
SMF71S3X='MAX*FRAMES*SHARED HIGH*4K*ON SCM'
SMF71S4A='AVG*HIGH VIRTUAL*SHARED*1MB CSTORE'
SMF71S4M='MIN*HIGH VIRTUAL*SHARED*1MB CSTORE'
SMF71S4X='MAX*HIGH VIRTUAL*SHARED*1MB CSTORE'
-TYPE74 new variable
R748RAI ='RANK*ADAPTER*PAIR*ID'
Change 33.315 z/OS 2.2 JOB='*MASTER*' JCTJOBID='MSGR' SUBSYS='SMS' was
VGETJESN not expected, caused WARNING TYPETASK NOT DECODED, now
Dec 27, 2015 is protected, with TYPETASK='STC' now set.
Change 33.314 Unused Change Number.
Change 33.313 Documentation. Type 30 EXCP/IOTM NODD/TODD/TOTL variables
TYPE30 in the "raw" TYPE30_4/TYPE30_5/TYPE30_V datasets created
Dec 24, 2015 directly from SMF, are wrong or misleading for jobs with
MULTIDD='Y' continuation records (they contain only EXCP
and IOTM fields). The variables ARE VALID in the datasets
PDB.JOBS/PDB.STEPS/PDB.SMFINTRV, built by BUILDPDB or the
ONLYINTV program, where MXG logic combines the MULTIDDs
and then correctly populates those variables.
For MULTIDD='Y' jobs, the first record can be a FLUSH
that contains NO DD segments, so NUMDD=0 and the TODD
variables are missing values. The TOTL in the MULTIDD
records is missing, since that field is the total for
the step, and that is only in the first SMF 30 record.
And since NODD=TOTL-TODD, the NODD is also missing.
And since they can be individually wrong, the sum of
these variables in those "raw" TYPE30xx datasets is
unusable.
Change 33.313 Cosmetic. Comments enhanced.
BLDSMPDB
Dec 23, 2015
Change 33.312 If you had more than a single service policy in your data
ANALACTM the report of the WLM service definition was not sorted
Dec 23, 2015 by the policy name resulting in reports printed by the
importance level instead of the service policy.
====== Changes thru 33.311 were in MXG 33.13 dated Dec 23, 2015=========
Change 33.311 -UTILBLDP with IMACKEEP= fails execution with syntax error
UTILBLDP due to invalid comment termination in the generated code
Dec 23, 2015 that referenced &SPINUOW macro variable.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 33.310 MXG's ANALZPCR is no longer usable, nor needed, since IBM
ANALZPCR zPCR will now read a "printed" IBM RMF CPU report to
Dec 21, 2015 create the zPCR input in External File Format V2.0 that
is required for zPCR V8.7.
====== Changes thru 33.309 were in First MXG 33.13 dated Dec 21, 2015===
Change 33.309 Variable QCSTDNRT, previously reserved, is now input and
VMAC116 formatted as a time, with NS*RESOLUTION*TIME' in
Dec 21, 2015 dataset MQCHININ.
Thanks to Robert Miles Standish, UBS, USA.
Change 33.308 Support for z/OS 2.2 new variables SMF 99 ST 14 added
VMAC99 S99E_AN_CI ='CPU/CORE*CONTAINER*INFO*/
Dec 21, 2015 S99E_AN_CI_FLAGS='CI_FLAGS'
Dec 22, 2015 S99E_AN_CI_NL ='CPU/CORE*TOPOLOGY*INFO'
S99E_AN_CI_NL1 ='CONTAINER*ID OF*NESTING*LEVEL 1'
S99E_AN_CI_NL2 ='CONTAINER*ID OF*NESTING*LEVEL 2'
S99E_AN_CI_NL3 ='CONTAINER*ID OF*NESTING*LEVEL 3'
S99E_AN_CI_NL4 ='CONTAINER*ID OF*NESTING*LEVEL 4'
S99E_AN_CI_NL5 ='CONTAINER*ID OF*NESTING*LEVEL 5'
S99E_AN_CI_NLINUSE='HIGHEST*NESTING*LEVELUSED'
S99E_AN_INFO ='AFFINITY*NODE*INFO'
S99E_AN_TOPO ='CPU/CORE*TOPOLOGY*INFORMATION'
S99E_CP_BOOKID ='BOOK*ID'
S99E_CP_CHIPID ='CHIP*ID'
to dataset TYPE99EN, and these variables to TY99EP:
S99E_CP_BOOKID ='BOOK*ID'
S99E_CP_CHIPID ='CHIP*ID'
-Each subtype 14 dataset now has all of the header
variables kept.
Thanks to Erling Andersen, SMT, DENMARK.
Change 33.307 -SMFSRCH was supposed to support multiple text strings in
SMFSRCH LOOKFOR=, with ANDOR=, but it only supported one string;
VMXGSRCH multiple strings caused nothing to be found.
Dec 21, 2015 Now, multiple LOOKFOR= strings are supported, but only
Dec 29, 2015 with "OR" logic, i.e., any LOOKFOR= string will be found.
It's impractical to support multiple ANDed stings with
LOOKFOR=, but the SELECTION= alternative to LOOKFOR=
provides complete control including ANDs of strings.
-VMXGSRCH messages when a VALUE= was found now print the
VALUE= that was searched, or when a VARS= is used, then
all of the matching variables names are listed, instead
of a blank line.
Change 33.306 The Group Capacity Variables SMF70GNM (Group Name) and
VMXG70PR SMF70GMU (MAXIMUM LICENSE UNITS) are kept in the Per-LPAR
Dec 20, 2015 CEC-Level dataset PDB.ASUMCELP (built automatically in
Dec 22, 2015 BUILDPDB by the include of member ASUM70PR).
Jan 8, 2015 -SMF70WLA is added to ASUMCELP for the systems whose SMF
70's were read.
-Variable ZIPCPUS was ROUNDed to two decimal places, to
print pretty, as the calculated value often was x.99999,
and debugging _PRN70PR macro was added to VMXG70PR.
Change 33.305 -Support for z/OS 2.2 RMF 74 Subtype 10 SCM Storage Class
EXTY7410 Memory statistics creates new datasets:
EXTY74SC
IMAC74 dddddd dataset description
VMAC74 TY7410 TYPE7410 SCM EADM AGGREGATE STATS
VMAC78 TY74SC TYPE74SC SCM CONFIGURATION MEASUREMENT
Dec 18, 2015 -New z/OS 2.2 variables (COMPATIBLE) in TYPE78PA:
R782LSMOMIN ='MIN FRAMES*ARE USED*SHARED*MEMOBJ='
R782LSMONTME='TIME STAMP*OF MIN*SHARED*MEMOBJ='
R782LSMOMAX ='MAX FRAMES*ARE USED*SHARED*MEMOBJ='
R782LSMOXTME='TIME STAMP*OF MAX*SHAREDMEMOBJ='
R782LSMOAVG ='AVG FRAMES*ARE USED*SHARED*MEMOBJ='
Change 33.304 Dataset TYP120xx variable SM120RULEXSUM was a typo for
VMAC120 SM120RULEXFSUM and now, SM120RULEXSUM doesn't exist.
Dec 16, 2015
Thanks to Homayoun Riazi, OPTUM, USA.
Change 33.303 "Duplicate" obs were created in PDB.DB2STATS when DB2
VMACDB2 used more than 24 buffers in an interval, because DB2
Dec 16, 2015 creates (unexpected) multiple SMF 100 subtype 1 records
for that interval, but the QWHSSTCK time is not exactly
the same, and QWHSSTCK must be used because DB2 stats
records don't contain an interval start time value. There
were no actual duplicated data, but additional obs with
the same SMFTIME and only buffer metrics were created in
the PDB.DB2STATS statistics summary dataset.
Now, the data is ordered by QWHSISEQ and the QWHSSTCK of
the first instance is stored in both PDB.DB2STATB and in
the new PDB.DB2STSBP buffer datasets, and the corrected
QWHSSTCK is used to create PDB.DB2STATS.
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 33.302 Support for two optional CICS user fields:
IMACICWR CMODHEAD CMODNAME Variable
IMACICWS OMEGCICS OMEGCICS OMEGCICS $EBCDIC104.
IMACAAAA USER STARPOL STARPOL $EBCDIC92.
UTILEXCL
VMAC110
Dec 15, 2015
Change 33.301 ITRM 33.12+ ERROR: WORK.SUMSTSPB.DATA does not exist.
ITRM -ITRM users of MXG 33.12+ MUST use EPDBOUT macro variable
Dec 11, 2015 to correctly sort the new DB2STSBP Simulated Buffer Pool
with this %LET statement inserted:
%CMPROCES . . .
%LET EPDBOUT= _SDB2SBP ;
%CPSTART . . .
-If you have not installed the ITRM Hot Fix 45583/41019,
you already have an EPDBOUT= _SDB2ST4 _SDB2225, so your
circumvention would be:
%LET EPDBOUT=_SDB2ST4 _SDB2225 _SDB2SBP ;
Thanks to Richard Schwarz, IBM, USA.
Change 33.300 New variables added to DB2ACCTx and DB2STATx datasets by
ASUMDB2A DB2 Version 11 are added to existing summary datasets.
ASUMDB2B The new dataset DB2STSBP summary is added in VMXGDBSS.
ASUMDB2G
ASUMDB2P
VMXGDBSS
Dec 11, 2015
Dec 14, 2015
Thanks to Wayne Bell, UNIGROUP, USA.
Change 33.299 Support for zVM 6.3 MONWRITE z13 SMT Mode; fields were
VMACVMXA inserted (INCOMPATIBLE) in SYTPRP after Change 33.242.
Dec 11, 2015 zVM 6.3.15.1 records have been validated. These
records have been validated. These variables are added
to VXSYTPRP dataset:
PF2CADCT ='UNDELAYED*CAD*INSTRUCTIONS'
PF2TSCAD ='CAD*INSTRUCTIONS*EXECUTED'
PF2TSCNT ='TSGET*REQUESTS'
PF2TSGTM ='TSGET*REQUEST*ELAPSED*TIME'
PFXPOLSR ='CORE*POLARIZATION'
SYTPRP_CAL_PLSIPTEI='IPTE 1/2*ACQUISITIONS'
SYTPRP_COREXTCT='COUNT*MT*COUNTERS*EXTRACTED'
SYTPRP_COREXTTT='DURATION OF*EXTRACT*MT*COUNTERS'
SYTPRP_PFXCPUCH='TIMES WHEN*SIEIHCPU FFFF*SWITCHES'
SYTPRP_PFXPRGCT='TIMES WHEN*SIEIHCPU FFFF'
SYTPRP_PLSIIA ='IPTE 2*ACQUISITIONS'
SYTPRP_PLSIIADD='TIMES WHEN*ACQUIRED*AS SHARE'
SYTPRP_PLSIIHDSSQCH='SSQ TIME*CONTINUOUS*HELD'
SYTPRP_PLSIIWTSSQCH='SSQ TIME*CONTINUOUS*HELD'
SYTPRP_PLSIIHLD='DURATION*CONTINUOUS*HELD'
SYTPRP_PLSIINHLD ='INTERVAL*COUNT*CONTINUOUS*HELD'
SYTPRP_PLSIIWTM='WAIT TIME*IPTE*INTERLOCK*ACQUISITION'
SYTPRP_PLSPTLCA='CALLS SET*PENDING*NON-LOCAL'
SYTPRP_PLSPTLCD='CALLS SET*PENDING*HOST TLB'
SYTPRP_PLSPTLCL='CALLS TO*PURGE*LOCAL*TLB'
Change 33.298 Support for IMS 14.1 log records (COMPATIBLE).
VMACIMS The IMS56FA dataset added two new variables
Dec 10, 2015 DLRDIR='DL/I*IR*CALLS'
DLRDMR='DL/I*MR*CALLS'
in existing reserved bytes.
Change 33.297 -Label for PCTCPUBY was corrected for PDB.TYPE70EN, which
VMAC7072 had incorrectly been "LPAR*CPU*BUSY".
VMXGWORL -VMXGWORL enhanced to parse the result into two macro vars
Dec 10, 2015 &MXGWORLLIB and &MXGWORLDSN so that PROC DATASETS, which
requires them separately, could be used to change labels.
Change 33.296 If you specified IMACKEEP= to retain the IMACKEEP that is
UTILBLDP generated, invalid syntax for _TIMEDIF/_SPINUOW/_SPINCNT
Dec 9, 2015 could be generated; the NULL value default should have
suppressed the generation of these macros; now it does.
The ECHO=YES default will now display the IMACKEEP text.
Thanks to Richard Krueger, Sentry, USA.
Change 33.295 Cosmetic. Prints messages when there are datasets in OLD
VMXGCOMP that are not in NEW, or vice versa.
Dec 8, 2015
Change 33.294 INPUT EXCEEDED ERROR for SMF 102 records written by BMC's
FORMATS Mainview for DB2, IFCIDs 815Ex-8160x - Accounting Rollup
VMACDB2H and IFCID 80F1x - Data Collector, which were unknown and
Dec 9, 2015 unsupported in MXG. These records contain unique SMF 102
Dec 18, 2015 header segments that do not match MXG expectations that
caused the error. But since no one has actually asked
for these subtypes, this change circumvents the problem
Decimal IFCIDS deleted are 33009,33118,33119,and 33120.
by skipping these subtypes in SMF 102 processing in MXG.
-The ANALID report (VMACID,FORMATS) is updated to be aware
of and describe these 102 subtypes in its reports.
Change 33.293 MACRO _TIMEDIF % set instead of MACRO _TIMEDIF 0 % caused
UTILBLDP a 22-322 Syntax Error.
Dec 5, 2015
Change 33.292 When printing of the found datasets is requested, the
VMXGFIND heading has the LIBNAME and MEMNAME printed.
Dec 5, 2015
Change 33.291 Support for BMC Mainview for CICS Version 7.0 (COMPAIBLE)
VMACMVCI adds these new variables for CICS/TS 5.3 to CMRDETL:
Dec 6, 2015 T6E70XCT='70*EXTENSIONS*LENGTH'
T6EDSAWC='ALLOCATE*THREAD*WAIT*COUNT'
T6EDSAWF='ALLOCATE*THREAD*WAIT*FLAG'
T6EDSAWT='ALLOCATE*THREAD*WAIT*TIME'
T6EEIBTR='INTERNAL*PROCESSING*FIELD'
T6EJSRPL='JSON*RESPONSE*MSG LENGTH'
T6EJSRQL='JSON*REQUEST*MSG LENGTH'
T6ELSTN_ACPTOK ='SUCCESSFUL*ACCEPTS'
T6ELSTN_CHILDTK='CHILD*SUBTASKS*STARTED'
T6ELSTN_DISPROG='DISABLED*PROGRAM'
T6ELSTN_DISTRAN='DISABLED*TRANSACTION'
T6ELSTN_GVSKTFL='GIVESOCKET*FAILURES'
T6ELSTN_REJAUTH='REJECTED*NOT AUTH'
T6ELSTN_REJSECU='REJECTED*SECURITY'
T6ELSTN_REJTDIO='REJECTED*TD*I/O'
T6ELSTN_REJTDLN='REJECTED*TD*LENGTH'
T6ELSTN_REJTDNS='REJECTED*TD*NO SPACE'
T6ELSTN_TACPTOK='TERM*SUCCESSFUL*ACCEPTS'
T6ELSTN_TCHILDTK ='TERM*CHILD*SUBTASKS*STARTED'
T6ELSTN_TDISPROG ='TERM*DISABLED*PROGRAM'
T6ELSTN_TDISTRAN ='TERM*DISABLED*TRANSACTION'
T6ELSTN_TGVSKTFL ='TERM*GIVESOCKET*FAILURES'
T6ELSTN_TREJAUTH ='TERM*REJECTED*NOT*AUTH'
T6ELSTN_TREJSECU ='TERM*REJECTED*SECURITY'
T6ELSTN_TREJTDIO ='TERM*REJECTED*TD*I/O'
T6ELSTN_TREJTDLN ='TERM*REJECTED*TD*LENGTH'
T6ELSTN_TREJTDNS ='TERM*REJECTED*TD*NO SPACE'
T6ELSTN_TUNDTRAN ='TERM*UNDEFINED*TRANSACTION'
T6ELSTN_UNDTRAN='UNDEFINED*TRANSACTION'
T6ENCGET='COUNTER*DCOUNTER*REQUESTS'
T6ETOTL_TINITT ='TOTAL*INIT*TIME'
T6ETOTL_TOTHRT ='TOTAL*OTHER*TIME'
T6ETOTL_TREADT ='TOTAL*READ*TIME'
T6ETOTL_TSLCTT ='TOTAL*SELECT*TIME'
T6ETOTL_TWRITT ='TOTAL*WRITE*TIME'
T6ETRUE_ATTACH ='DYNAMIC*SUBTASK*COUNT'
T6ETRUE_INITCKC='INIT*CALL*COUNT'
T6ETRUE_INITCKF='INIT*CALL*FLAG'
T6ETRUE_INITCKT='INIT*CALL*CLOCK'
T6ETRUE_OPENAPI='OPEN*API*COUNT'
T6ETRUE_OTHRCKC='OTHER*CALL*COUNT'
T6ETRUE_OTHRCKF='OTHER*CALL*FLAG'
T6ETRUE_OTHRCKT='OTHER*CALL*CLOCK'
T6ETRUE_READCKC='READ*CALL*COUNT'
T6ETRUE_READCKF='READ*CALL*FLAG'
T6ETRUE_READCKT='READ*CALL*CLOCK'
T6ETRUE_REUS ='REUSABLE*COUNT'
T6ETRUE_SLCTCKC='SELECT*CALL*COUNT'
T6ETRUE_SLCTCKF='SELECT*CALL*FLAG'
T6ETRUE_SLCTCKT='SELECT*CALL*CLOCK'
T6ETRUE_TATTACH='TERM*DYNAMIC*SUBTASK*COUNT'
T6ETRUE_TCBLIM ='TCB*LIMIT*REACHED*COUNT'
T6ETRUE_TINIT='TASK TERM*TOTAL INITS'
T6ETRUE_TOPENAPI ='TERM*OPEN*API*COUNT'
T6ETRUE_TOTHR='TASK TERM*TOTAL OTHERS'
T6ETRUE_TREAD='TASK TERM*TOTAL READS'
T6ETRUE_TREUS='TERM*REUSABLE*COUNT'
T6ETRUE_TSLCT='TASK TERM*TOTAL SELECTS'
T6ETRUE_TTCBLIM='TERM*TCB*LIMIT*COUNT'
T6ETRUE_TWRIT='TASK TERM*TOTAL WRITES'
T6ETRUE_WRITCKC='WRITE*CALL*COUNT'
T6ETRUE_WRITCKF='WRITE*CALL*FLAG'
T6ETRUE_WRITCKT='WRITE*CALL*CLOCK'
T6ETSGSC='SHARED*TS*GETS'
T6ETSPSC='SHARED*TS*PUTS'
In addition, these existing file segments that have no
extended data now create these variables:
PSEUDOFILE='PSEUDO*FILE*NAME'
PSEUDOFILT='PSEUDO*FILE*DURATION'
PSEUDOFILC='PSEUDO*FILE*COUNT'
ADABASFILE='ADABAS*FILE*NAME'
ADABASFILT='ADABAS*FILE*DURATION'
ADABASFILC='ADABAS*FILE*COUNT'
SAPFILE='SAP*FILE*NAME'
SAPFILT='SAP*FILE*DURATION'
SAPFILC='SAP*FILE*COUNT'
DATACOMFILE='DATACOM*FILE*NAME'
DATACOMFILT='DATACOM*FILE*DURATION'
DATACOMFILC='DATACOM*FILE*COUNT'
IDMSFILE='IDMS*FILE*NAME'
IDMSFILT='IDMS*FILE*DURATION'
IDMSFILC='IDMS*FILE*COUNT'
SUPRAFILE='SUPRA*FILE*NAME'
SUPRAFILT='SUPRA*FILE*DURATION'
SUPRAFILC='SUPRA*FILE*COUNT'
S2KFILE='S2K*FILE*NAME'
S2KFILT='S2K*FILE*DURATION'
S2KFILC='S2K*FILE*COUNT'
GENFILE='GEN*FILE*NAME'
GENFILT='GEN*FILE*DURATION'
GENFILC='GEN*FILE*COUNT'
Change 33.290 The ANALID report tabulates all SMF data in the SMF file;
ANALIDDY the new ANALIDDY tabulates the SMF data by DATE of the
TYPEIDDY SMFTIME so day-to-day counts can be compared.
VMACID The syntax for the new report is:
VMACIDDY
Dec 4, 2015 %ANALIDDY(READSMF=YES,PRINT=YES,PDBOUT=WORK);
Dec 5, 2015
Thanks to Lizette Koehler, Albertsons/Safeway Stores, USA.
Change 33.289 z/OS only. If you used BLDSMPDB to build a MONTHLY PDB:
BLDSMPDB -If the 1st of the month fell on a Sunday then the code
Dec 3, 2015 miscalculated the start of the last weekly and caused
the last few days of the month to be missing.
-If the 1st of the month did not match the start of the
week then the last few days were duplicated because the
logic looked for daily data GE then the start of the
week and should have looked for GT.
Change 33.288 Reserved Change.
Change 33.287 -The PDB.CICDS CICS Dispatcher Statistics dataset now has
ADOC110 variable DSxPCT='AA TCB*PERCENT*USAGE', the IBM estimate
VMAC110 of each CICS TCB's percentage usage.
Dec 3, 2015 -ADOC110 now documents the new TCBs added in CICS/TS 2.2.
====== Changes thru 33.286 were in MXG 33.12 dated Dec 1, 2015=========
Change 33.286 Six TYP1194L variables LxLCLLNKID and LxRMTLNKID were
VMAC119 incorrectly changed from numeric to character in first
Dec 1, 2015 33.12. They were corrected in final Dec 1 refresh.
All six are formatted with HEX8 format for consistency.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 33.285 Cosmetic, eliminate non-impacting warning that numeric
ASUMTALO variable AVGDRIVE has different lengths in ASUMTALO and
TRNDTALO TRNDTALO, because an ancient statement in member ASUMTALO
Nov 30, 2015 specified LENGTH AVGDRIVE 4 while TRNDTALO invoked
VMXGSUM which sets LENGTH DEFAULT=&MXGLEN that is the
correct syntax to set stored length 5 on EBCDIC or 6 on
ASCII, which are the required lengths for SAS variables
that fully support 4-byte input fields. Observed in QA.
====== Changes thru 33.284 were in MXG 33.12 dated Nov 27, 2015=========
Change 33.284 Warning message in TYPE26J2 that the MXG created variable
VMAC26J2 INREASON is blank is removed; not all purge records have
Nov 27, 2015 enough information to populate the created variable, e.g.
JCL error in INTRDR populates only READTIME, JPURTIME and
SYSREAD.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 33.283 -INVALID DATA for WORD5UP in BBBP ENDING UPTIME because
VMACNMON the expected HH:MM format is sometimes 'HH HRS' when the
Nov 26, 2015 value is 'HH:00'. The HRS text is now removed so the 11
hour value is valid eliminating the error message.
-NMON records missing data and the LF delimiter exist and
they cause strange errors.
-One record with TYPE of DISKBSIZEAAA is clearly missing
data and an LF before the AAA, which is a new record
TYPE. This record caused an INVALID ARRAY error because
MXG tested for TYPE=:'DISKBKSIZE', starting with, for
possible numeric suffixes often used in NMON.
-Another record had only CPAAA, causing an UNKNOWN TYPE
log message.
-A third TYPE=LPAR has 22 valid fields but was missing
the LF separator and had a valid AAA record concat.
This record caused an INVALID INPUT error because MXG
expected numbers in the up to 24 fields in TYPE LPAR.
-Because NMON is character data, all numeric fields are
created with INPUT() functions, but now, with these bad
data records, the INPUT functions are now protected with
the ?? token to suppress the ERROR, PUT _ALL_, and LIST
log messages.
-Disk error messages "NRCOUNTERS NE DSKSEQNR" that were
cited as due to bad data in Change 31.164 are corrected.
They were due to new DISKBUSY1/DISKREAD1/etc objects that
NMON created when there were more than 150 devices that
were NOT supported until now.
Thanks to Steve McCulloch, TMX/CDS Group, CANADA.
Change 33.282 SMF 90 records contain the ENCRYPTED/MASKED UTOKEN value
FORMATS as documented in Change 33.189, which noted IBM does plan
VMAC90A to change to the UNMASKED value, but the encryption logic
Nov 25, 2015 is only an Exclusive OR with '55'x and mapping the result
Nov 27, 2015 into a one byte character which is then INPUT as $EBCDIC,
Dec 1, 2015 so the TOKxxxxx variables in the TYPE90A dataset are now
plain text values if the field was MASKED.
-The 80-byte SMF90T37UTOKEN is decoded into its TOKxxxxx
variables, now set to LENGTH $8 (they are INPUT() with a
SUBSTR() which defaults to length of the input variable),
and so it is no longer kept.
-New FORMAT MGHEXNM was needed to map the XOR value to the
character hex value for the output.
-Dec 1: Error +; was corrected.
Thanks to Peter Relson, IBM z/OS Development, USA.
Change 33.281 A valid WARNING was printed from an SQL step due to a
VMXGSIZE WHERE clause. Logic reordered to eliminate the warning.
Nov 24, 2015
Change 33.280 PDB.TYPE70 for z13 in SMT mode could have the wrong count
VMAC7072 in ZIPCPUS, ZIP70PAT, and ZIPUPTM because SMF70PAT was
Nov 21, 2015 incorrectly added to ZIP70PAT when SMF70ONT is missing.
Thanks to Joachim Sarkoschitz, DATEV, GERMANY.
Change 33.279 -Support for DB2 Simulated Buffer Pool statistics segment,
ANALDB2R creates new PDB.DB2STSBP dataset with per pool data, and
ASUMDBSS four sets of QBnSxxxx interval totals in PDB.DB2STATS and
EXDB2SBP ASUMDBSS creates new ASUMDBSP summary dataset.
IMACDB2 -MOBILEWORK programs QAMOB and MOBWRK02 required updates
MOBWRK02 to support/protect this new dataset
QAMOB -Buffer Hit Ratios for the SBP are created but set to a
READDB2 missing value, pending data for validation.
VMACDB2 -ANALDB2R compile fakers for QWxxxxDB were corrected.
VMXGDBSS -The names of tokens/datasets for SBP mirror STB:
VMXGINIT DB2STB DB2SBP
Nov 18, 2015 DB2STSTB DB2STSBP
Nov 22, 2015 DB2STAB DB2STSB
Nov 23, 2015 ASUMDBSB ASUMDBSP
Nov 26, 2015 MACSTAB MACSTSB
Dec 18, 2015 D2BPSIN D2SBPIN
D2SBPIN D2SBPOU
-There is no count of pages-not-in-the-pool so there is no
buffer hit ratio for the simulated buffer pool that I can
calculate. Variable QBSPREADS is the total number of
requests that caused a read.
Thanks to Lai Fai Wong, Bank of America, USA.
Change 33.278 If you used INTERVAL=MONTH, MXGDURTM was missing for the
VMXGDUR 31-day months, except December, when it was non-missing
Nov 18, 2015 but was 41 days of seconds, because the statement
IF MONTH IN(1.3.5.7.8.10,12) THEN MXGDURTM=41*86400;
should have been
IF MONTH IN(1,3,5,7,8,10,12) THEN MXGDURTM=31*86400;
periods are not allowed, but do NOT create a SAS error.
This is old, present in MXG 30.09 but not in MXG 26.26.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 33.277 If you tried to use Example TWO to create ASUMUOW, an
IMACUOW error resulted due to a misplaced percent sign; Example
Nov 19, 2015 THREE did not tell you how to create "MYDATA", and while
Example FIVE did work, it was inconsistent with others.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 33.276 RMF III variables GEILF4K and GEILP4K in dataset ZRBGEI
VMACRMFV were reversed in their INPUT order; GEILF4K precedes
Nov 16, 2015 GEILP4K now.
Thanks to Kurt Gramling, Total Systems.
Change 33.275 Assemble/Link Edit all five MXG ASM programs for install.
ASMRMFV The existing single ASM/LKED members are restructured so
CICSIFUE the ASM code is isolated from the JCL so the new JCLASMXG
EXITCICS member will create all five loadlib members in one job.
JCLASMXG ASMRMFV - Used in JCLRMFV to process RMF III VSAM file,
MNVWIFUE output RMFBSAM read by TYPERMFV.
MXGTMNT (Individual ASM/LKED is in JCLASM3/ASMRMFV)
TMONEXIT CICSIFUE - Used in TYPEDB2/TYPE110/TYPE112 to decompress
Nov 16, 2015 IBM SMF records 100, 101, 102, 110, and 112.
Nov 23, 2015 (Individual ASM/LKED is in EXITCICS)
Nov 27, 2015 MNVWIFUE - Used in TYPEBBMQ to read compressed BBMQVSAM
and in TYPECMFV to read BMC MainView data.
(Individual ASM/LKED is in ASMMNVW)
MXGTMNT - The MXG Tape Mount Monitor Program, read by
TYPETMNT
(Individual ASM/LKED is in ASMTAPEE)
TMONEXIT - Used in TYPETMO2 to decompress MONICICS
TMON/CICS data.
(Individual ASM/LKED is in EXITMON6)
The original documentation comments are in appendices
at the end of JCLASMXG.
Thanks to MP Welch, Bank of America, USA.
Change 33.274 -Enhancement for character data filtering for RMF Monitor
ADOCRMFV III CSR (Common Storage Remaining) table and other
ASMRMFV usability improvements.
Nov 16, 2015 -These filters are intended for building ad hoc MXG RMF
III PDBs for studies avoiding the overhead of generating
a full CSR table based PDB. They control which CSR table
entries are output to the RMFBSAM file.
-Four new filters are added to support CSR entry selection
from this table to the RMFBSAM output file. These
filters are effective only if the CSR table is selected.
They are applied in the order shown when multiple
different keywords are used.
New Keyword Aliases
------------ -----------------------------------------
CSRJOBNAME= CSRJOBNA=, CSRJOBNM=, CSRJOB=, CSRJN=
CSRJESID= CSRJESNO=, CSRJESNUM=, CSRJESNR=, CSRJID=
CSRAND None
CSROR None
-TUTORIAL:
Ranges of the form keyword=first:last may be used with
any of the above keywords except CSRAND and CSROR.
The colon character ':' is required for a paired range
specification. All entries GE the first value and LE the
last value are selected for output to the RMFBSAM file.
The first value may not exceed the last value in EBCDIC
collating sequence or an error is flagged.
Single unpaired values may be specified for a range
simply as keyword=first and in this case the colon ':' is
omitted.
Patterns may also be used with any of the above keywords
except CSRAND and CSROR and include one or more Wild Card
characters to match the respective CSR data field.
A pattern contains one or more special Wild Card
characters as follows:
Wild
Card Matches
---- -------------------------------------------------
* 0 or more characters
% 1 Non-blank character
+ 1 Numeric character (0-9)
_ 1 Alphabetic character or _ (a-z, A-Z, _)
. 1 National character (@, #, $)
! 1 Special character (not a-z, A-Z, 0-9, @, #, $)
? A blank string if used by itself
? 1 Blank character (X'40') if used with any other
characters
Ranges may not be wild carded. If wild carded the range
value becomes a pattern instead and is processed as such.
See Section 25 "Ranges and Patterns" in the ADOCRMFV
member or ASMRMFV source code for more details on usage
of ranges and patterns.
-CSRJOBNAME= selects CSR entries by 1-8 character z/OS
Job Name. Job Name characters are validated to those
allowed by JCL syntax. Both ranges and patterns with
wild cards may be specified. Up to 64 ranges and 64
patterns are supported. The default is CSRJOBNAME=ALL.
-Examples for CSRJOBNAME= :
CSRJN=PROD1234:PROD5678 selects only address spaces with
a z/OS Job Name GE 'PROD1234' and LE 'PROD5678' as a
range. Note use of the keyword alias CSRJN for coding
convenience.
CSRJOBNAME=.* is a pattern that selects only address
spaces with a Job Name that begins with a national
character.
CSRJOBNAME=*++ is a pattern that selects only address
spaces with a Job Name that ends with 2 numeric digits.
CSRJOBNAME=ABC:ABC88888 is a range that selects only
address spaces with a Job Name that is GE 'ABC ' and
LE 'ABC88888'.
-CSRJESID= selects CSR entries by 8 character JES Job
Identification. Both ranges and patterns with wild cards
may be specified. Since a JES Id is one subsystem
character followed by 7 digits or three subsystem
characters followed by 5 digits not all pattern
characters may be used with this keyword.
See Section 25 "Ranges and Patterns" in the ADOCRMFV
member or ASMRMFV source code for more details on usage
of ranges and patterns.
-For convenience any leading zeros in the numeric portion
of the JES Id may be omitted and will be filled in
automatically. Up to 64 ranges and 64 patterns are
supported. The default is CSRJESID=ALL.
-Examples for CSRJESID= :
CSRJID=J0000100:J0001123 is a range that selects all
address spaces with batch JES Id numbers GE 100 and LE
1123. Note use of keyword alias CSRJID for coding
convenience.
CSRJID=J100:J1123 is a range that selects the same
address spaces as above with the leading zeros omitted
for coding convenience.
CSRJESID=JOB12345:JOB32001 is a range that selects all
address spaces with batch JES Id numbers GE 12345 and LE
32001 for installations with 5 digit JES Id numbers as a
range.
CSRJESID=J1* is a range that selects all address spaces
with a JES ID that begins with 'J1'. This would include
J1000000 through and including J1999999.
-CSRAND (default) indicates that selection results from
the two different CSR filter keywords are logically
ANDed.
-CSROR indicates that selection results from the two
different CSR filter keywords are logically ORed.
-Examples of CSRAND/CSROR:
With CSRAND (default) in effect:
CSRJESID=J10* CSRJOBNAME=XYZ*
are two patterns that select ONLY jobs whose JES ID
begins with 'J10' AND Job Name begins with 'XYZ'.
CSRAND provides more restrictive CSR entry selection.
With CSROR in effect:
CSRJESID=J10* CSRJOBNAME=XYZ*
are two patterns that select jobs whose JES ID begins
with 'J10' OR Job Name begins with 'XYZ'. CSROR provides
less restrictive CSR entry selection.
-Selection results from repeats of the same CSR filter
keyword are always logically ORed.
-The order of CSR filter application is:
1) CSRJOBNAME=
2) CSRJESID=
-New support for the concept of multi-table selection with
filters JOBNAME= (alias JOB=) and JESID= (alias JID=) to
allow selection by Job Name and/or JES Identification
jobname from both the RMF Monitor III ASI and CSR tables
with one keyword.
-This is a convenience feature to avoid having to code the
Job Name or JES ID selection parameters twice when the
same jobs from both tables are of interest.
-Both the ASI and CSR tables must be selected for these
multi-table selection keywords to function completely.
Otherwise, only entries from the one selected table are
filtered.
Note that most RMF III tables do not contain common
character data fields, but in this case the ASI and CSR
do.
-Example of JOBNAME= :
JOBNAME=ABC* or JOB=ABC* is equivalent to coding
ASIJOBNAME=ABC*
CSRJOBNAME=ABC*
-Example of JESID= :
JESID=JOB01000:JOB01999 or JID=JOB01000:JOB01999
is equivalent to coding
ASIJESID=JOB01000:JOB01999
CSRJESID=JOB01000:JOB01999
NOTE: If a job has ended before the selected MINTIME
intervals it will ONLY appear in the MXG ZRBCSR data set
and NOT the MXG ZRBASI data set.
-Reduced processing overhead for CSR tables.
-RMFV056* (*=I,W,E) message is no longer issued twice when
a single unpaired range value is in error.
-All invalid characters detected in a pattern are now
shown in multiple RMFV056* (*=I,W,E) messages. Before
only the first character in error was displayed. This
could result in repeated runs of ASMRMFV just to find all
the invalid characters in a pattern.
-The error message generation process has been rewritten
for improved efficiency, consistency, clarity, and
usability.
For example, the problem data area in RMFV004* and
RMFV056* messages that shows the text in error is
expanded from 24 to 63 characters. Also all length
errors are displayed in the same format.
-Added new documentation Section 26 "ASMRMFV and SAS PDB
Relationships" that explains which RMF III tables
correspond to which eventual MXG SAS datasets. If the
required RMF III table is not selected in ASMRMFV the MXG
dataset will have zero observations.
All ASMRMFV users should review this useful information.
-Old documentation Section 26 "Summary" is now Section 27.
-The PATTERR= parameter was not effective because it was
not processed until all parameters were read. This was
too late because pattern error handling must occur during
the actual parameter process as patterns are being
scanned.
-PATTERR= parameter handling now occurs immediately when
found in the JCL PARM field or SYSIN DD stream including
severity tailoring of message RMFV056* (*=I,W,E).
-The default value for PATTERR= is now PATTERR=ABEND.
Before the default was PATTERR=WARN. An incorrect
pattern value could result in a waste of processing
resources building an MXG PDB that did not contain the
data desired and so that default was inappropriate.
-The documentation is updated to make it clear that
PATTERR= applies to BOTH pattern AND range errors. There
is no RANGEERR= parameter.
-DISK is now supported as a value alias for the DEVTYPE=
keyword in DVT table filtering so that DEVTYPE=DISK may
be used. Any truncation of 'DISK' as a character value
(DIS,DI,D) is also allowed.
-DVTT= was missing in documentation as an alias for
DEVTYPE= although it was always supported.
-First message RMFV001I now also displays the system GMT
offset as GMT OFFSET=-hh:mm:ss or GMT OFFSET=+hh:mm:ss as
extracted from the z/OS Communication Vector Table (CVT)
in addition to the existing current date and time of
ASMRMFV beginning execution.
-A new RMFV001I message shows the ASMRMFV beginning
execution date and time in GMT.
-A MAXDSNAMES= value exceeding maximum supported &DSNMAX
value was not flagged as an error.
-Message RMFV034S did not correctly display the number of
used table entries when a range or pattern table was
exhausted.
-Several documentation Sections are updated to support
the above changes:
Section 5 "Input Data Selection Parameters"
Section 8 "Error Handling Parameters"
Section 12 "Messages"
Section 13 "Filtered Records"
Section 17 "Abend Reason Codes"
Section 25 "Ranges and Patterns"
Section 26 "ASMRMFV and SAS PDB Relationships" (NEW)
Section 27 "Summary"
Change 33.273 DB2 SMF 102 Trace IFCID=109 INVALID DO LOOP CONTROL ERROR
VMAC102 was caused by unexpected/invalid QWT02R10/L/N triplet
Nov 12, 2015 with all zeros; which is the only segment in the 109 with
QW0109RC, the Bind Return code, so I presumed it was the
purpose for the record and did not test for the existence
of a non-zero count. Now, I do test, and still output an
observation, which will have QW0109RC a missing value.
Thanks to Karl-Olaf, JN Data, DENMARK.
Change 33.272 Cosmetic change to eliminate numeric conversion messages.
ASUMTALO
VMXGRMFI
Nov 11, 2015
Change 33.271 TYPETMO2 processing of compressed records did not print
VMACTMO2 the warning message if the internal MXG decompression is
Nov 11, 2015 used on z/OS instead of the EXITMON6 Infile Exit.
Change 33.270 Variable SMF14ALIAS, the Alias Data Set Name in TYPE1415,
VMAC1415 added by z/OS 2.2 and MXG 33.01, was spelled SMR14ALIAS
Nov 10, 2015 in the KEEP= list so it was not kept. With MXG 33.01+
use MACRO _KTY1415 SMF14ALIAS % in your IMACKEEP to
keep the variable until you drop in the next MXG Version.
Field was added by APAR PI69296.
Thanks to Robert Obee, IMS Health, USA.
Change 33.269 UTILBLDP changes the default to ECHO=YES, so that the
UTILBLDP generated code is automatically printed on the SAS log,
Nov 9, 2015 so we can examine the output without requesting a rerun
to enable ECHO, if there is a problem in execution.
Change 33.268 -Support for SEVEN USER-USER fields in CICSTRAN, and
IMACICVY several other unique fields.
IMACICVZ To enable these user fields, you need to specify
IMACICWA %LET NREXCLUSER=7;
IMACICWB %INCLUDE SOURCLIB(UTILEXCL);
IMACICWC _BLDDICT
IMACICWD _BLDEXCL
IMACICWE _RPTEXCL
IMACICWF -Variable JOB is added to CICSTRAN.CICSTRAN (the JOB name
IMACICWG of the CICS region).
IMACICWH
IMACICWI
IMACICWJ
IMACICWL
IMACICWM
IMACICWN
IMACICWP
IMACICWQ
UTILEXCL
VMAC110
VMXGINIT
Nov 11, 2015
Thanks to Jens Ove Stogaard, NORDEA, SWEDEN.
Change 33.267 SMF 120 dataset TYP120JI only output the first instance;
VMAC120 the offset for the INPUT was not updated by the length.
Nov 6, 2015
Thanks to Elie Sawaya, Royal Bank of Canada, CANADA.
Change 33.266 MXG 33.11 only. ERROR: VARIABLE SYTPN NOT FOUND, only if
VMACXAM _SXAM is used to sort the zVPS datasets; SYTPN should not
Nov 6, 2015 be in the new _BXAMCU2 and _BXAMCUV "By List" macros as
it does not exist in those two new datasets.
Thanks to Matthew Brooks, OPM, USA.
Thanks to Robert Richards, OPM, USA.
Thanks to Leslie W. Mitchell, OPM, USA.
Change 33.265 ThruputManager dataset TPMSLM variables TPMSLXGF/TPMSLXGN
VMACTPMX are TODSTAMP8. STCK datetimes, so their incorrect INPUT
Nov 6, 2015 with &PIB.8.6 and subsequent divide by 4096 was invalidly
creating dates in 2076, since that is a duration value
(same as MSEC8) rather than a datetime value.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.264 Support for APPTUNE 11.2 INCOMPATIBLE changes to the 8005
VMAC102 IFCID record. Some truncated 8005 records are created
Nov 5, 2015 that MXG detects and reports the first instance, and the
Nov 23, 2015 vendor reports a correction will be provided. Datasets
T1028004, T1028005, and T102800B have been data-tested.
Thanks to Rudi Claes, KBC, BELGIUM.
Change 33.263 Support for User CICS field BTMASK.
IMACAAAA
IMACICVX
UTILEXCL
VMAC110
Nov 4, 2015
Change 33.262 Support for SMF 119 subtypes 41-44 (previously, zero obs)
FORMATS and for the below fields added in z/OS 2.1 or earlier
VMAC119 that had been overlooked.
Nov 6, 2015 -Subtype 2, dataset TYP11902:
TTLCLSMCLINKID='LOCAL*SMC-R*LINK*ID '
TTRMTSMCLINKID='REMOTE*SMC-R*LINK*ID'
TTSMCREASON ='SMC-R*LINK*FAILURE*REASON*CODE'
TSMCFLAGS ='SMC-R*FLAG'
FORMAT $MG119RC is created to decode the Reason Code.
-Subtype 5, dataset TYP11905:
TSSMCRACTIVEOPENED ='ACTIVE*TCP*CONNECTIONS*ACROSS*SMC-R LINKS'
TSSMCRACTLNKOPENED ='ACTIVE*SMC-R*LINKS*OPENED'
TSSMCRCONNCLOSED ='CLOSED*TCP*CONNECTIONS*ACROSS*SMC-R LINKS'
TSSMCRCURRESTAB ='TCP*CONNECTIONS*ACROSS*SMC-R LINKS'
TSSMCRCURRESTABLNKS='CURRENT*ACTIVE*SMC-R*LINKS'
TSSMCRINRSTS ='SMC-R*INBOUND*WRITE*OPERATIONS*ABNORMAL*CLOSE'
TSSMCRINSEGS ='SMC-R*INBOUND*WRITE*OPERATIONS'
TSSMCRLNKACTTIMEOUT='SMC-R*LINK*ACTIVATION*TIMEOUTS'
TSSMCRLNKSCLOSED ='SMC-R*LINKS*CLOSED'
TSSMCROUTRSTS ='SMC-R*OUTBOUND*WRITE*OPERATIONS*ABNORMAL*CLOSE'
TSSMCROUTSEGS ='SMC-R*OUTBOUND*WRITE*OPERATIONS'
TSSMCRPASLNKOPENED ='PASSIVE*SMC-R*LINKS*OPENED'
TSSMCRPASSIVEOPENED='PASSIVE*TCP*CONNECTIONS*ACROSS*SMC-R LINKS'
TSTCEPHPORTAVAIL ='AVAILABLE*TCP*EPHEMERAL*PORTS'
TSTCEPHPORTEXH ='BIND*FAILS*NO TCP*EPHEMERAL*PORTS'
TSTCEPHPORTINUSE ='TCP*EPHEMERAL*PORTS*CURRENTLY*IN USE'
TSTCEPHPORTMXUSE ='MAXIMUM*TCP*EPHEMERAL*PORTS*USED'
TSUDPBFA='BIND*FAILS*NO*UDP*EPHEMERAL'
TSUDPAVA='AVAILABLE*UDP*EPH*EPHEMERAL'/
TSUDPUSE='INUSE*UDP*EPH*EPHEMERAL'
TSUDPMAC='MAXIMUM*UDP*EPH*EPHEMERAL'/
TS6CEALO='ECSA*CURRENT'
TS6CENIU='ECSA*FREE'
TS6CPALO='PRIVATE*CURRENT'
TS6CPNIU='PRIVATE*FREE'
TS6SMCFC='SMCR*FIXED*CURRENT'/
TS6SMCFM='SMCR*FIXED*MAX'
TS6SMCSC='SMCR*SEND*CURRENT'
TS6SMCSM='SMCR*SEND*MAX'
TS6SMCRC='SMCR*RECV*CURRENT'
TS6SMCRM='SMCR*RECV*MAX'
-Subtype 6, dataset TYP11906:
IFQDXNET='PHYSICAL*NETWORK*ID'
-Subtype 7, dataset TYP11907:
FFSESSID='FTP*ACTIVITY*SESSION*ID'
-Subtypes 41-44, all datasets are now populated.
-Subtypes 97. Variable SSH_FSPATH2 now INPUT and kept;
The three variables SSH_FSPATH/FSPATH1/FSPATH2 should
have been named FCPATH to match their IBM field names.
-Variables EXTWTRNM,JESUBSYS,JOB,LOCLINFO,READTIME are
not kept in datasets TYP11941/42/43/44/4L, where they
don't exist and should never have been kept.
Thanks to James T. Sherpey, Bank of America, USA.
Thanks to David M. Wrobel, Bank of America, USA.
Thanks to Jennifer D. Ayers, West Virginia State Government, USA.
Change 33.261 Internal code change, to make user tailoring easier.
VMAC7072 In dataset TYPE72GO, only two variables are kept for the
Nov 4, 2015 calculated percentage variables, PCTxxxxx and VALDSAMP,
since the numerator value R723yyyy can be re-calculated
in the EXTY72GO exit and KEPT in the _KTY72GO macro in
your tailored IMACKEEP. But by changing the variable
name in the INPUT to the R723yyyy field name and using it
for the PCTxxxxx calculation, those R723yyyy variables
can be added to TYPE72GO with only _KTY72GO tailoring, so
the EXTY72GO tailoring is not required. The code for the
TYPE72MN dataset was similarly revised internally.
Thanks to Erling Andersen, SMT, DENMARK.
====== Changes thru 33.260 were in MXG 33.11 dated Nov 2, 2015=========
Change 33.260 ANALSMDU report analyzes an SMF file for duplicate data
ANALSMDU showing if/when duplicate data exists in separate dump
Nov 2, 2015 groups, with record numbers so duplicates can be removed,
and tabulating if duplicate data exists in individual SMF
dumps.
Thanks to Lizette Koehler, Albertsons/Safeway Stores, USA.
Change 33.259 Support for zVPS Release 4230 for z13 is SMT mode
EXXAMCUV creates two new datasets:
EXXAMCU2 dddddd dataset description
IMACXAM XAMCU2 XAMCU2
VMACXAM XAMCUV XAMCUV
VMXGINIT
Oct 30, 2015
Change 33.258 Support for CICS USER field TORM.
UTILEXCL
VMAC110
Oct 30, 2015
Thanks to Don Deckard, Wal*Mart, USA.
Thanks to Cheryl Jordan, Wal*Mart, USA.
Change 33.257 This change is REQUIRED for CICS/TS 5.3. The final new
UTILEXCL CICS/TS 5.3 field, as always inserted, INCOMPATIBLY,
VMAC110 DSAPTHWT, is now supported, supported, creating variables
Oct 29, 2015 DSAPTHCN='WAIT COUNT*FOR DSA*PATH'
DSAPTHTM='WAIT TIME*FOR*DSA*PATH'
Field was added in Beta 14.
Thanks to Anthony Hirst, Wells Fargo, USA.
Change 33.256 CICS Count of TCB Change Mode Requests was originally in
VMAC110 IBM CMODIDNT=248 CHMODECT, a four byte counter, but that
Oct 29, 2015 was replaced in CICS/TS 1.3 with CMODIDNT=247 DSCHMDLY
which is an 8-byte wait duration plus update counter that
created these two variables that are now re-labeled:
DSCHMDCN='DSCHMDLY*COUNT*TCB*CHANGE MODE*REQUESTS'
DSCHMDTM='DSCHMDLY*DURATION*CHANGE MODE*REQUESTS'
Change 33.255 UTILEXCL failed with ARRAY EXCEEDED when more than 999
UTILEXCL connectors exist; arrays increased to 1999.
Oct 27, 2015
Thanks to Erling Andersen, SMT, DENMARK.
Change 33.254 MXG 33.09-33.10. Using WORK=SASWORK caused TYPE7072 code
VMAC7072 to fail; temporary datasets TYPE70EC and TYPE70EN did not
VMXGINIT have &Wdddddd/&Pdddddd in their _Wdddddd/_Ldddddd tokens,
Oct 26, 2015 so they were written to //WORK instead of //SASWORK, no
Oct 31, 2015 error, but inconsistent. Change 33.217 for z/13+SMT 70's
revised MXG code for TYPE70EC/EL/EN datasets had replaced
_WTY70EN with DATA TYPE70EN (the same when WORK=WORK),
but the VMXGDEL deleted DATASET WORK.TYPE70EN when it
should not have. There is nothing illegal about setting
Options WORK=SASWORK, and it was previously supported,
but it had not been recommended by MXG, and is unneeded
since //WORK can be multi-volume.
Thanks to Scott Bickel, Kansas State Government, USA.
Change 33.253 Added processing of TYPE32 records to tabulate TSO MSU
SAGANAL for each COMMAND in new Report 32. Report 19, PROC PLOT
Oct 30, 2015 was removed from _RPTALL as it was only used in testing.
Nov 3, 2015 New Report 32 tabulates HOURLY TSO MSU for NAT commands.
Change 33.252 IMS Transaction dataset TYPE56FA does not contain SYSTEM,
TYPEIMST the MVS SYSTEM ID, but you can pass the SYSTEM name into
VMACIMS SAS from each JOB's JCL using the SYSPARM() statement:
Oct 22, 2015 // EXEC MXGSAS94,OPTIONS='SYSPARM="SYSA"'
or the SYSTEM can be set with SYSPARM in your //SYSIN
OPTIONS SYSPARM="SYSA";
Then, inside MXG first-time logic that creates ZDATE and
ZTIME, retrieves that value with SYSTEM=SYSPARM(); and
variable SYSTEM is RETAINED and OUTPUT in each dataset.
-SHIFT was added to all IMS datasets based on IMSSTCK.
Only VMACIMS was changed; TYPEIMST is just for reference.
-For years, the only JCL for SYSPARM that worked had EIGHT
quotes before and FIVE after the text, and I have a 2013
example, but that syntax now fails with SAS 9.4, and SAS
now documents the much cleaner double quote syntax.
Both IMS and BVIR require you to supply the SYSTEM thru
SYSPARM=, and other members use SYSPARM to enable debug.
All of the JCL examples with OPTIONS=SYSPARM= now use the
double quotes for both instream and in JCL.
-Variable ZTIME is added to all IMS datasets that have the
ZDATE variable now.
Thanks to David A Bernhardt, Verizon, USA.
Change 33.251 CICSTRAN variable OSTART=ORIGINATING*TASK*START*DATETIME
UTILEXCL was on GMT; MXG overlooked the need to convert it to the
VMAC110 local time zone.
Oct 20, 2015
Thanks to David Shaw, M & T Bank, USA.
Thanks to Douglas Donoho, M & T Bank, USA.
====== Changes thru 33.250 were in MXG 33.10 dated Oct 20, 2015=========
Change 33.250 -SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC102 because QWT02R2L is two bytes shorter than the actual
Oct 18, 2015 DB2 10.1 records.
-SMF 102 IFCID 220 INVALID ARGUMENT appears to be a truly
invalid record, with DSNAME where DDNAME should be. The
error is circumvented by validating the DHMS arguments
while the record is investigated. Variable QW0220OT is
the datetime stamp being calculated from characters, and
will be missing for invalid input, without the error.
Thanks to Joe Babcock, General Motors, USA.
Change 33.249 Decoding of DEVCLASS=41 now identifies specific CTC type:
VMACUCB DEVTYPE DEVICE Description
Oct 15, 2015 previous CTC
05X CTC-OSA OSA
06X CTC-OSAD OSA DIAG DEV
07X CTC-IQD HIPERSOCKETS
09X CTC-OSAN OSA ZBX NETWK
0AX CTC-OSAM OSA ZBX MGMT NETWK
32X CTC-FIC FICON
other CTC
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.248 Support for zVSE/Power Version 9 Release 2 Accounting.
TYPEDOS Only minor changes were required, including protection
Oct 13, 2015 for SEGCNT larger than the number of device segments in
the record (caused STOPOVER).
Change 33.247 -If you use UTILEXCL and have more than four "triplets":
VMAC110 WARNING: THE QUOTED STRING CURRENTLY BEING PROCESSED HAS
Oct 14, 2015 BECOME MORE THAN 262 CHARACTERS message is printed.
This warning has NO impact. Change 33.203 added the text
in MACRO _CICXLTR (the list of "triplets" in IMACEXCL) to
MXG diagnostic PUT statements about EXCLUDED fields. Each
triplet test is one line of text so four triplets exceed
a SAS internal limit of 262 character for quoted text in
PUT statements in macro resolution. Change 33.203 used
$LENGTH CICXLTR $32000;
%LET CICXLTR=%QUOTE(_CICXLTR);
CICXLTR=SYMGET('CICXLTR');
to store the text in macro variable &CICXLTR, and then
used "&CICXLTR" to print the text in the PUT statement,
but that's the macro resolution causing the warning!
Now, by using
CICSXLTR=RESOLVE('_CICXLTR');
to directly store the old-style macro text into the data
step variable CICSXLTR, that variable can be used in the
PUT statement, with no macro resolution needed and hence
no warning message. Sites with SAS 9.1 may need to
change RESOLVE to COMPRESS. Contact support@mxg.com.
This shows how easy it is to store the text contents of
an old-style substitution macro into a variable.
-CICS/TS 5.3, close comment missing for TSQIOSCN in the
INPUT statement, causing new-in-5.3 variables in CICSRDQU
Resource dataset TSQGESTM/GESCN/PUSTM/PUSCN/GESBY/PUSBY
to be wrong.
-CICS/TS 5.2 MNSEGCL=5 records with MNR5LENT=96 caused
STOPOVER because MXG expected 104 (5.3 value).
Change 33.246 -Using UTILBLDP with BUILDPDB=YES, if you suppressed type
UTILBLDP 6, 26, or 30, the job failed in BUILD005 when it tried
ZTILBLDP to process the non-existent datasets. Now, if any of the
Oct 20, 2015 datasets are not created, then BUILD005 is suppressed,
and warning message is printed.
-A second execution of UTILBLDP in the same SAS Session
failed with old-style macro errors that are now resolved
and UTILBLDP can be re-executed as often as needed.
-The changes to support second execution were extensive
and thus extensively tested, but, just in case, the prior
UTILBLDP from MXG 33.09 is stored in ZTILBLDP.
Thanks to Michael Reines, Decadis, GERMANY.
Change 33.245 Support for OMEGAMON ATF IMS Log Record LCODE A0 records:
EXATFA0 dddddd dataset description
IMACATF ATFA0 IMSATFAO ATF IMS LCODE A0
TYPEATF ATFDB IMSATFDB ATF IMS DBD
TYPSATF ATFDL IMSATFDL ATF IMS DLI DB
TYPEATFI ATFDT IMSATFDT ATF IMS DLI TM
TYPSATFI ATFD2 IMSATFD2 ATF IMS DB2
VMACATF ATFMQ IMSATFMQ ATF IMS MQ
VMACIMS ATFOA IMSATFOA ATF IMS OTHER A
VMXGINIT ATFOB IMSATFOB ATF IMS OTHER B
Oct 19, 2015 -Application Trace Facility is a component of Omegamon XE
Nov 17, 2015 for IMS v531. Detail trace data from intercepts capture
application execution for IMS related threads, including
DB2 and MQ API calls from an IMS application. The detail
data, possibly millions of intercepts per transaction, is
summarized into new IMS LOG A0 record. It's unlikely to
trace everything always, so this is not a replacement for
the IMS 56FA Log Record (TYPEIMST) for IMS chargeback and
response/resource reporting, but there is more data in
ATF - notably the DBD information - than in the 56FA, so
if selectively enabled for trouble children, it might be
a useful source for IMS trouble shooting.
-TYPEATFI reads IMSLOG format records, TYPEATF reads the
alternate destination, ATFLOG, if that option is chosen.
-MXG member TYPEIMS7 is updated to process ATF records if
found along with all other IMS Log records.
-The IBM default is A0, but that can be changed with the
MACRO _IDATF using %LET MACKEEP= tailoring in //SYSIN.
-ATF replaces the old ITRF component of Omegamon/XE.
-This is the support for Phase I. Additions are coming.
-Nov 17: INPUT @LOCVARSEG+ATFXSNzzO syntax is REQUIRED
because ATFXSNzzO offset can be zero, and the SAS syntax
INPUT @A+B is NOT the same as INPUT @B+A and the first
variable MUST ALWAYS BE NON-ZERO. When in doubt, use
LOC=A+B; INPUT @LOC.
Change 33.244 Unused Change Number.
Change 33.243 RACF Type 80 records don't have variable SUBTYPE because
ANALID the RACFEVNT value is used instead, but now, RACFEVNT is
FORMATS INPUT in the SMF Header processing and stored in SUBTYPE
UTILBLDP so that the ANALID report will tabulate (and describe,
VMACSMF using the updated SMFID format) each type 80 subtype.
Oct 10, 2015 And, UTILBLDP selection by SUBTYPE (WANTSMF=80.02) is now
supported for ID=80 records.
NEVER USE TYPE80/TYPS80, ALWAYS USE TYPE80A/TYPS80A.
Change 33.242 Support for z/VM 6.3.15.0 VXSYSPRT (0.02) z13 SMT mode.
VMACVMXA New SMT-related variables added to the end of the record.
Oct 10, 2015 But: See Change 33.299, REQUIRED.
Change 33.241 A SUM statement is added to the audit report of datasets
PDBAUDIT in your BUILDPDB that reports the total number of pages,
Oct 9, 2015 variables, size, and bytes in each PDB data library.
Change 33.240 TYPE30xx device summary variables for non-existent device
IMAC30IO types (EXCP3350/IOTM3350) can be dropped from all TYPE30s
Oct 9, 2015 and PDB.JOBS and PDB.STEPS by tailoring IMAC30IO to save
disk space (one PDB reduced 400MB from 2500MB to 2100MB).
A new example in comment block can be enabled to keep
only the variables for current device types.
Change 33.239 Some TYPE70 variables can't be DROPped using _KTY70 with
VMAC7072 DROP= because the TYPE70 dataset is not created directly
Oct 8, 2015 as SMF is read (when _KTY70 is used for TYPE70SP). TYPE70
is created from TYPE70SP and TYPE70PR with multiple DATA
DATA steps and Split Record processing. Using _KTY70
also has a risk of dropping a variable needed in the data
steps that follow. This change creates _KTY70DR, a null
old-style MACRO that can be used to drop any variables in
TYPE70 dataset, safely. This syntax in your //SYSIN:
%LET MACKEEP= MACRO _KTY70DR DROP= IF: VF: APPC: % ;
drops all variables starting with IF, VF, or APPC.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.238 Support for RACF Flat File of IRRDBU00 record type 1560
EXRA1560 creates new dataset
IMACRACF DDDDDD DATASET DESCRIPTION
VMACRACF RA1560 RACF1560 GENERAL RESOURCE CERTIFICATE INFORMATION
VMXGINIT CERTN_NAME ='GENERAL*RESOURCE*NAME'
Oct 8, 2015 CERTN_CLASS_NAME ='GENERAL*RESOURCE*PROFILE*CLASS'
CERTN_ISSUER_DN ='ISSUERS*DISTINGUISHED*NAME'
CERTN_SUBJECT_DN ='SUBJECTS*DISTINGUISHED*NAME'
CERTN_SIG_ALG ='CERTIFICATE*SIGNATURE*ALGORITHM'
Thanks to Robert Miles Standish, UBS, USA.
Change 33.237 Support for EDA v7706 (INCOMPATIBLE, two existing 8-byte
VMACEDA user fields were expanded in place to 20 bytes). There
Oct 6, 2015 is no version field in their record; the length of the
record for each subtype is now used to create EDAVERS to
read either the new or old version records transparently.
Thanks to Valentine Wudarczyk, BNYMellon, USA.
Change 33.236 DB2 zPARM QWP4xxxx fields marked (S)-SERVICEABILITY were
VMAC102 not always kept, but IBM is now using these three fields
Oct 14, 2015 QWP4INLP='INLISTP'
QWP4MXOS='MAX*OPT*STOR'
QWP4SHDE='SUPPRESS*HINT*SQLCODE*DYN'
QWP4XMLO='XML*PROCESSING*OPTIONS'
The first two were kept but unlabeled. Now all (S) are
kept and labeled in T102S106 dataset. The first six have
actual labels, the others have their name as LABEL.
QWP4ACCS QWP4ADMT QWP4INLP QWP4MXOS QWP4SHDE QWP4XMLO
QWP4AST QWP4CDE1 QWP4COC1 QWP4COC2 QWP4CTHR QWP4CUT
QWP4FLKT QWP4LTDM QWP4MQTH QWP4MS4A QWP4MXCE QWP4MXOC
QWP4MXOE QWP4MXTB QWP4PLIM QWP4RMTI QWP4SCLC QWP4SCTM
QWP4SELD QWP4SPC QWP4SPS QWP4STHR QWP4TJTH QWP4TTRS
QWP4ULB2 QWP4ULFR QWP4ZUT
-Variables QWP4ACCS and QWP4DFID character values were not
correct when test was EBCDIC, and QWP4OZTM is now numeric
datetimestamp instead of $CHAR8. hex value.
Thanks to Lai Fai Wong, Bank of America, USA.
Change 33.235 Documentation. RED ALERT APAR OA48941 IS REQUIRED BY ALL
VMAC74 z/OS SITES and MUST BE INSTALLED PRIOR TO DEC 15 2015 to
Oct 6, 2015 prevent failure at IPL if the APAR is NOT installed.
The error is in Unicode Service Conversation iconv()
calls which is NOT USED IN MXG. but TELNET and many other
programs are impacted.
Change 33.234 Change 33.155 added R744SNAM to TYPE74HO dataset, which
VMAC74 accidentally corrected an unreported error in the NODUP
Oct 4, 2015 sort to create PDB.TYPE74HO: false duplicates were being
deleted, so the prior PDB.TYPE74HO dataset was incorrect.
The number of obs correctly increased with this change.
And R744CNAM and R744SNAM are added to the end of the
_BTY74HO BY List to formally correct the NODUP sort.
Thanks to Paul Volpi, UHC, USA.
Change 33.233 Support for APAR OA46136 that adds File Transfer Section
VMAC6 with IP Address and Port Number to PSF-created SMF 6.
Oct 1, 2015 No change was required; fields automatically INPUT/KEPT
when the section exists.
Change 33.232 Support for Thruput Manager VARNAME=$ORIGIO NOT FOUND
VMACTPMX message creates new ORIGIO='ORIGINAL*INSYSID' variable
Sep 30, 2015 in the TYPETPMX dataset.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.231 Support for JZOS Java Runtime Performance Stats SMF 121
EXTY121 creates three new datasets:
EXTY121G dddddd dataset description
EXTY121G TY121 TYPE121 JZOS JAVA RUNTIME STATISTICS
FORMATS TY121G TYPE121G JZOS JAVA RUNTIME GARBAGE COLLECTION
TYPE121 TY121T TYPE121T JZOS JAVA RUNTIME THREADS
TYPS121 and new FORMAT $MG121TC for thread category.
VMXG121
VMXGINIT
Oct 8, 2015
Change 33.230 -Example ANAL1430 selects TYPE1415 (non-VSAM) and TYPE64
ANAL1430 (VSAM) records by DSNAME, then merges BY READTIME JOB to
ANAL2642 select the the TYPE30_4 (Step end) for that JOB to get
VMAC42 the RACFUSER field that opened that dataset.
Sep 30, 2015 HOWEVER, this example in ANAL1430 can ONLY capture those
datasets that were CLOSED, and ONLY if that JOB had a
step terminate record in the SMF file.
-Example ANAL2642 selects TYPE26J2 (Job Purge) by SUBMUSER
and selects TYPE42DS (Interval Dataset Activity) by DSN
to report each JOB and DSNAME for that SUBMUSER.
-Type 42 subtype 6 TYPE42DS dataset has new variables
S42READS=SUM(S42AMDRB,S42AMSRB,S42AMZRG,S42DSHRD);
S42WRITES=SUM(S42AMDBW,S42AMSWB,S42AMZWB,S42DSHWR);
the sum of direct and sequential BLOCKS, directory reads/
writes, and zHPF reads and writes.
Thanks to Alyona Bertneski, JPMorgan, USA.
Change 33.229 Support for NDM PT records with zIIP CPU times (INCOMPAT)
VMACNDM inserted these three new variables in NDMPT dataset:
Sep 28, 2015 PTECP0='CPU TIME*SPENT ON*CP'
PTECP1='CPU TIME*SPENT ON*ZIIP'
PTECP2='ZIIP*QUALIFIED*PART OF*PTECP0'
The inserted data caused INPUT STATEMENT EXCEEDED ERROR.
The prior PT record format's UNC and UNN variables were
cleaned up.
Thanks to David Guess, Blue Cross Blue Shield of South Carolina, USA.
Change 33.228 z/OS 2.1 z/13 SMF 74 St 9 INPUT STATEMENT EXCEEDED for a
VMAC74 record with R749DEVN='Hardware Accelerator' but without
Sep 25, 2015 expected Hardware Accelerator and Hardware Compression
segments that MXG INPUT because of that DEVN value. The
record is valid as it contains zeros in the two triplet's
NUMBER OF fields, SMF749FN,SMF7491N, so MXG logic now
knows to test those fields prior to the input of the
SMF749FO,SMF7491O segments, while the reason for their
absence is being investigated.
Thanks to David Marone, SGS-BP, ITALY.
Change 33.227 Dataset TYPE22PB 'RECONFIGURED PCIE PFIDS' had zero obs
VMAC22 due to misalignment in the MXG INPUT statement. See also
Sep 23, 2015 Change 33.146.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.226 Documentation. ERROR: THE GIF DRIVER CAN NOT FIND ANY
MXGSAS92 FONTS and PHYSICAL FILE MVS:SYS3.SAS.SASMONO.TTF.. DOES
Sep 23, 2015 NOT EXIST occurred on z/OS when the old MXGSAS92 PROC
was used for SAS 9.4, instead of using MXGSAS94 PROC.
This DD statement was added and is required for SAS 9.4
// DD DSN=&SASHLQ..CONFIG(COMMON),DISP=SHR
in the //CONFIG DD concatenation.
Change 33.225 Major Revision to this Analysis of Capping now uses the
ANALCAPD PDB.ASUMCELP dataset with data for each LPAR, rather than
Sep 20, 2015 using only the PDB.ASUMCEC summary dataset for the CEC,
with new parameters to allow for selection by LPAR and/or
to set different cap values for different LPARs:
INCODE= a stub of code for selecting data
CEC= one or more CEC serials separated by spaces
LPAR=one or more LPAR/cap values separated by spaces
The plot shows the "Overflow MSU", an estimate of how
long it would take at the cap to get the same number of
MSUs consumed when the rolling 4 hour avg was over the
cap. So the total MSU consumed above the cap based on
the rolling average pro-rated across the four hour
average keeping the system at the cap until all of the
excess MSUs are consumed.
Change 33.224 Cosmetic. Unexpected Unit Address SMFWKUAD='000000'X
VMACSYNC (which normally is a 3-byte EBCDIC like '181'/'F1F8F1'x)
Sep 18, 2015 for a SYNCSORT SORTWK DD segment caused ILLEGAL ARGUMENT
message when it was used to create SYNCDV and SYNCUN with
SYNCDV=INPUT(SMFWKUDA,HEX6.) syntax, as the HEX6 informat
doesn't support the null value. This DD segment also has
" 0 " for the value in VOL variable. Null now protected.
Thanks to Joe Faska, DTCC, USA.
Change 33.223 Short SMF 103 Subtype 13 record caused INPUT STATEMENT
VMAC103 EXCEEDED Error. The segment is documented to contain 56
Sep 18, 2015 bytes plus a name field, but the record contains only 48
bytes. Circumvention: Use the Name-Length Field and its
location to determine if this is 48 or 56 length. Input
normal for 56. For short 48 record, the two 8-byte fields
are changed to 4 so the NAME field aligns, causing Bytes
and Requests are zero in the short records, but the
short record will be output with valid server name.
Thanks to Shabida Khan, Royal Bank of Canada, CANADA.
Change 33.222 -Major enhancement for character data filtering for RMF
ADOCRMFV Monitor III DVT (Device Table) entries and other
ASMRMFV improvements.
Sep 18, 2015 -These filters are intended for building ad hoc MXG RMF
Sep 21, 2015 III PDBs for studies avoiding the overhead of generating
a full DVT table based PDB. They control which DVT table
entries are output to the RMFBSAM file.
-Four filters are added to support DVT entry selection
from this table to the RMFBSAM output file. These
filters are effective only if the DVT table is selected.
They are applied in the order shown when multiple
different keywords are used.
New Keyword Aliases
------------ --------------------------------------
DVTDEVNUM= DVTDEVNO= DVTDEVNR= DVTDEV= DVTN=
DVTVOLSER= DVTVOLI= DVTVOL= DVTSER= DVTV=
DVTAND None
DVTOR None
-TUTORIAL:
Ranges of the form keyword=first:last may be used with
any of the above keywords except DVTAND and DVTOR.
The colon character ':' is required for a range
specification. All entries GE the first value and LE
the last value are selected for output to the RMFBSAM
file.
The first value may not exceed the last value or an error
is flagged.
Ranges may not be wild carded. If wild carded the range
value becomes a pattern instead.
Single values may be specified for a range simply as
keyword=first and in this case the colon ':' is omitted.
Patterns may also be used with any of the above keywords
except DVTAND and DVTOR and include one or more wild
card characters to match the respective DVT data field.
Wild
Card Matches
---- ------------------------------------------------
* 0 or more characters
% 1 Non-blank character
+ 1 Numeric character (0-9)
_ 1 Alphabetic character or _ (a-z, A-Z, _)
. 1 National character (@, #, $)
! 1 Special character (not a-z, A-Z, 0-9, @, #, $)
? A blank string if used by itself
? 1 Blank character (X'40') if used with any other
characters
See Section 25 in the ADOCRMFV member for more details on
usage of ranges and patterns.
-DVTDEVNUM= (and any of its aliases) selects DVT entries
by Device Number. Both ranges and patterns with wild
card characters may be specified. Up to 64 ranges and
64 patterns are supported. The default is DVTDEVNUM=ALL.
Any valid 4 hex character device number with or without
pattern characters in the range of 0000-FFFF may be
specified.
For ranges the Device Number is treated as a binary
number in arithmetic comparisons.
For patterns the Device Number is converted to hex
characters (0-F) prior to pattern matching.
NOTE: Due to the nature of hexadecimal characters not all
characters and/or patterns may be used with DVTDEVNUM=.
See documentation for details.
-Examples for DVTDEVNUM=
DVTDEVNUM=0A00 selects the device with address 0A00 only.
DVTDEVNUM=0A00:0FFF selects all devices with addresses GE
0A00 and LE 0FFF.
DVTDEVNUM=A00:FFF selects the same devices as above with
the leading zeros omitted for coding convenience.
All leading zeros may be omitted if desired when ranges
are used. Leading zeros may NOT be omitted when
patterns are used unless they are included in the
pattern.
DVTDEVNUM=0*F and DVTDEVNUM=*F produce quite different
results.
DVTDEVNUM=B* selects all devices with addresses from B000
through and including BFFF.
DVTDEVNUM=10* selects all devices with addresses from
1000 through and including 10FF.
DEVDEVNUM=C*FE selects all devices with addresses C0FE,
C1FE, C2FE, C3FE, C4FE, C5FE, C6FE, C7FE, C8FE, C9FE,
CAFE, CBFE, CCFE, CDFE, CEFE, and CFFE.
DEVDEVNUM=C+FE selects all devices with addresses C0FE,
C1FE, C2FE, C3FE, C4FE, C5FE, C6FE, C7FE, C8FE, and C9FE
as '+' is a digit (0-9) pattern character.
DVTDEVNUM=C%FE selects all devices with addresses C0FE,
C1FE, C2FE, C3FE, C4FE, C5FE, C6FE, C7FE, C8FE, C9FE,
CAFE, CBFE, CCFE, CDFE, CEFE, and CFFE as '%' is a
placeholder pattern character.
DVTDEVNUM=C_FE selects all devices at addresses CAFE,
CBFE, CCFE, CDFE, CEFE, and CFFE as '_' is an alphabetic
pattern character.
-DVTVOLSER= (and any of its aliases) selects DVT entries
by Volume Serial Number. Both ranges and patterns with
wild card characters may be specified. Up to 64 ranges
and 64 patterns are supported. The default is
DVTVOLSER=ALL.
Any valid 1-6 character Volume Serial with or without
pattern characters may be specified. Per JCL syntax a
Volume Serial Number is 1 through 6 alphanumeric,
national ($,#,@), or special characters.
NOTE: Since just about any keyboard character is valid in
a Volume Serial please take extra care when coding to
avoid unintended results in the MXG PDB.
-Examples for DVTVOLSER=
DVTVOLSER=C99999 selects the volume serial C99999 only.
DVTVOLSER=C00000:C99999 selects all volume serials GE
'C00000' and LE 'C99999'.
DVTVOLSER=10* selects all volume serials starting with
'10' followed by up to 4 more characters.
DVTVOLSER=H+++++ selects all volume serials starting with
'H' followed by 5 digits.
DVTVOLSER=K*A selects all volume serials starting with
'K' that have a final character 'A' with up to 4
intervening characters.
-DVTAND (default) indicates that selection results from
DVTDEVNUM= and DVTVOLSER= DVT filter keywords are
logically ANDed. DVTAND is effectively ignored if DVT
records are NOT selected
Results for selected Devices for the same DVTxxxxxx=
keyword are ALWAYS logically ORed.
NOTE: The DVT filters DEVTYPE=ALL/DASD/TAPE and
ZEROIO/NOZEROIO are applied independent of the use of
DVTAND.
-DVTOR indicates that selection results from DVTDEVNUM=
and DVTVOLSER= DVT filter keywords are logically ORed.
DVTOR is effectively ignored if DVT records are NOT
selected
Results for selected Devices for the same DVTxxxxxx=
keyword are ALWAYS logically ORed.
NOTE: The DVT filters DEVTYPE=ALL/DASD/TAPE and
ZEROIO/NOZEROIO are applied independent of the use of
DVTOR.
-Examples with DVTAND in effect: DVTDEVNUM=CA00:CAFF
DVTVOLSER=SMF* only selects device entries in the DVT
table that have a Device Number GE CA00 and LE CAFF AND
that have a Volume Serial Number that starts with 'SMF'.
DVTDEVNUM=CA00:CAFF DVTVOLSER=SMF* DVTVOLSER=PAG* only
selects device entries in the DVT table that have a
Device Number GE CA00 and LE CAFF AND that have a Volume
Serial Number that starts with either 'SMF' or 'PAG'.
-Examples with DVTOR in effect: DVTDEVNUM=CA00:CAFF
DVTVOLSER=SMF* selects device entries in the DVT table
that have a Device Number GE CA00 and LE CAFF OR that
have a Volume Serial Number that starts with 'SMF'.
DVTDEVNUM=CA00:CAFF DVTVOLSER=SMF* DVTVOLSER=PAG*
selects device entries in the DVT table that have a
Device Number GE CA00 and LE CAFF OR that have a Volume
Serial Number that starts with 'SMF' or 'PAG'.
The logical OR results in less restrictive filtering
because any of the 3 conditions results in data
selection of a DVT entry.
NOTE: The DVT filters DEVTYPE=ALL/DASD/TAPE and
ZEROIO/NOZEROIO are applied independent of the use of
DVTOR.
-The order of DVT filter application is:
1) DEVTYPE=
2) DVTDEVNUM=
3) DVTVOLSER=
4) ZEROIO/NOZEROIO
-Section 5 "Input Data Selection Parameters" in
documentation is updated with discussion of all the new
DVT selection keywords and aliases.
-Section 26 "Summary" in documentation is updated for the
new DVT keywords.
-Message RMFV034I did not display correctly on a Device
Number match with DVTDEVNUM= and SHOWMATCH options in
effect.
-Version entry for z/OS 2.2 in RMF release table was not
Correct.
Change 33.221 RMF III data with CPUHOLEN GT 480 and CPUVERG3 EQ 5 ABEND
VMACRMFV INPUT STATEMENT EXCEEDED RECORD LENGTH error when IBM
Sep 17, 2015 changed CPUHOLEN to 740 but did not update CPUVERG3.
Change 33.220 Mini-tutorial on how the INFORMAT in an INPUT function
SAGANAL caused the MSU values to be off by a factor of 100 (an
Sep 17, 2015 error that was immediately obvious!). SAGANAL builds
format $SYS2CAP that maps SMF70CPA to TIME+SYSTEM, and
then retrieves a value with this INPUT function that
uses the 10.2 INFORMAT to "read" the $SYS2CAP value:
SMF70CPA=INPUT(PUT(TIMESYS,$SYS2CAP.),10.2);
which worked, but only accidentally, because all previous
$SYS2CAP values contained a decimal. But if the value in
$SYS2CAP was an integer, the .2 in the 10.2 INFORMAT told
SAS to divide by 100. Removal of the .2 that never should
have been there corrects the error.
Change 33.219 MXG 33.09 Only. VARIABLE MAXCCPUC IS UNINITIALIZED msg,
VMACBVIR typo, caused MAXDCUPC to be a missing value in BVIR10.
Sep 17, 2015
Change 33.218 MXG-created variable WTTOTIOTM (DBMS/IO TOTAL OTHER WAIT)
ADOC110 did not include these recently-added wait variables:
VMAC110 DSCHMDTM FCVSWTTM VCXCWTTM ISALWTTM TCALWTTM TDELWTTM
Sep 16, 2015 TDILWTTM
====== Changes thru 33.217 were in MXG 33.09 dated Sep 15, 2015=========
Change 33.217 z13 in SMT Mode ONLY: LPARCPUS=0 in PDB.TYPE70PR.
VMAC7072 This is the last reported issue with MXG code for z13 in
Sep 13, 2015 SMT mode, and both SMT=1 and SMT=2 data have been tested.
So this change in MXG 33.09 is REQUIRED for z13 SMT mode.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.216 Support for APAR OA47042 adds MOBILE RESOURCES in RMF 70
VMAC7072 and 72 for MOBILE PRICING that eliminates the need to
Sep 11, 2015 process the CICS and IMS transaction records, by using
new WLM Service Definition Qualifier types of Connection
Type (CT) and/or Client Transaction Name (CTN) to set the
new WLM Classification "Reporting Attribute" that can be
set to NONE/MOBILE which WLM uses to identify mobile work
in these new variables.
-Dataset TYPE70 new variables:
SMF70LACM='MOBILE*LONGTERM*AVERAGE*MSU/HR'
SMF70LACA='CAT A*LONGTERM*AVERAGE*MSU/HR'
SMF70LACB='CAT B*LONGTERM*AVERAGE*MSU/HR'
-Dataset TYPE72GO new variables:
R723TSUCP ='TOTAL*GP*SERVICE*MSU/HR'
R723TSUSP ='TOTAL*ZIIP*SERVICE*MSU/HR'
R723TSUOCP='TOTAL*ELIGIBLE*SERVICE*MSU/HR'
R723MSURCP='MOBILE*GP*SERVICE*MSU/HR'
R723MSURSP='TOTAL*ZIIP*SERVICE*MSU/HR'
R723MSUOCP='TOTAL*ELIGIBLE*SERVICE*MSU/HR'
R723ASUCP ='CAT A*GP*SERVICE*MSU/HR'
R723ASUSP ='CAT A*ZIIP*SERVICE*MSU/HR'
R723ASUOCP='CAT A*ELIGIBLE*SERVICE*MSU/HR'
R723BSUCP ='CAT B*GP*SERVICE*MSU/HR'
R723BSUSP ='CAT B*ZIIP*SERVICE*MSU/HR'
R723BSUOCP='CAT B*ELIGIBLE*SERVICE*MSU/HR'
These metrics may be available for z/OS 2.2 and z/OS 2.1
later this year.
Note that R723TSUCP=SUM(CPUUNITS,SRBUNITS);
Change 33.215 Documentation change only. Added an example of using
VMXGSUM VGETDDS to drive the input to VMXGSUM.
Sep 9, 2015
Change 33.214 If UTILBLDP was executed twice in the same session, and
UTILBLDP the USERADD= option was used, the second execution failed
Sep 10, 2015 because the _IDxxxx "SMF Record Macros" were not cleared.
Thanks to Michael Reines, Decadis, GERMANY.
Thanks to Ron Hawkins, HDS, USA.
Change 33.213 Support for WASODM Operational Decision Manager 8.7.1 SMF
VMAC120 Type 120 Subtype 100 (MXG Dataset TY120100) INCOMPATIBLE.
Sep 10, 2015 The record was completely restructured internally, and
Oct 8, 2015 these ruleset statistics now exist in SM120HDV=3 records:
SM120RULEXBAD ='RULESET*FAILED*EXECUTION*COUNT'
SM120RULEXCALLS='RULESET*NUMBER*OF*CALLS'
SM120RULEXCMAX ='RULESET*MAX*CPU*JAVA TIME'
SM120RULEXCMIN ='RULESET*MIN*CPU*JAVA TIME'
SM120RULEXCPU ='RULESET*TOTAL*CPU*JAVA TIME'
SM120RULEXFSUM ='RULESET*SUM OF*FIRED*RULES'
SM120RULEXNUM ='RULESET*SUCCESSFUL*EXECUTION*COUNT'
SM120RULEXPATH ='RULESET*EXECUTION*PATH'
SM120RULEXTIME ='RULESET*TOTAL*ELAPSED*JAVA TIME'
SM120RULEXTMAX ='RULESET*MAX*ELAPSED*JAVA TIME'
SM120RULEXTMIN ='RULESET*MIN*ELAPSED*JAVA TIME'
-SM120HDV=1 records (in Versions 8.5.1.0 and 8.6.0.0) and
SM120HDV=2 records (in Versions 8.5.1.2) contain only
these counters: SM120RULEXNUM SM120RULEXBAD SM120RULEXSUM
-Records with no Extension segment are now output; these
appear to be interval records when there was no activity.
New variable SM120EXNNR identifies if the record has an
extension, and if so, which one.
-The prior TY120100 dataset was incorrectly/wrongly built
with the number of observations in WORK.TY120100 higher
than the number of input records, and the number of obs
in PDB.TY120100 too few (and wrong).
Thanks to Scott Barry, SBBWorks Inc., USA.
Thanks to Paul Volpi, UHC, USA.
Change 33.212 Support for MEGACRYPTION Version 6 SMF records,
VMACMGCR (MGCRLEV='2') which incompatibly increased the length of
Sep 8, 2015 the MGCRBYTE and MGCRKS fields from 4 to 8 and 40 to 60.
Thanks to Randy Schlueter, First Data Corporation, USA
Change 33.211 New variables are added in DB2 Trace Dataset T102S199.
VMAC102 QW0199SC='LAST TIME*DATABASE*STATISTICS*UPDATED'
Sep 8, 2015 QW0199ID='MORE*RECORDS*OR*LAST?'
QW0199SD='SHADOW*COPY?'
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 33.210 More TMON/CICS Version 3 AND Version 4 corrections.
VMACTMO2 -MONITASK for Version 3 was wrong in MXG 33.08, with
Sep 11, 2015 misalignment starting at variable CICOVHTM.
-MONITASK Version 4 requires ASG PTF TH03803 to correct
invalid values in variables TASTCPUC and TASTCPOC.
-The MONISYST dataset was misaligned and has been updated
and validated with both 3.3 and 4.0 records.
Thanks to Francois Vancoppenolle, PV Group, BELGIUM.
Change 33.209 Cosmetic changes from ITRM Validation.
VMAC102 -VMXG70PR: Temporary variable N60PLUSLPAR no longer kept
VMAC110 in PDB.ASUM70PR and PDB.ASUMCEC datasets.
VMAC119 -VMAC110: Variables DS7START,DS7LSTRT now labeled.
VMAC50 -VMAC102: The nineteen QWn196Ha variables added by 31.236
VMAC7072 are now labeled/formatted/Length consistently.
VMAC74 -VMACNDM: Offset variable NDMGPE1D is no longer kept in
VMAC75 NDMRT dataset.
VMAC76 Variables NDMZLIBR/LIBS PTRESTRECORD labeled.
VMAC77 -VMACSTC: STC14TOD and STC27TPX variables are labeled.
VMAC99 -VMAC119: Variables SMF119SM_ and SMF119FT_ are labeled.
VMACNDM -VMAC50: Variable TY40EXTL labeled.
VMACSTC -VMAC7072: Temp variables R725QSR1/QSR2/QST1/QST2 are not
VMACXCOM kept since they were already used to create the
VMXG70PR SSQ variables R725QSRQ R725QSTQ.
Sep 6, 2015 -VMAC74-7: Variables SMF74/75/76/77/GIE are labeled.
-VMAC99: Variables S99CMTFLGS1/2 label typo corrected.
-VMACXCOM: Many XCOxxxxx variables are labeled.
Thanks to Chris Weston, SAS Institute, USA.
Change 33.208 z/OS ONLY. If you use VGETDDS with DDNAMES=PDB: syntax
VGETDDS (to read all DDNAMEs starting with PDB), and those DDs
Sep 6, 2015 are on tape, VGETDDS mounted all of the tapes twice, once
to detect is is a SAS dataset and then once to actually
read the data. Now, once VGETDDS finds that a PDBn DD
points to a tape device, it will presume all the others
are also tape, and thus eliminate the double mounts. But,
if a DDNAME that matches the test is NOT a SAS dataset
the job ABENDs with ERROR:LIBRARY PDBn IS NOT IN A VALID
FORMAT FOR ACCESS METHOD V9SEQ or if UNIT=AFF is used but
DEFER=YES was NOT, then a SYSTEM 413 ABEND occurs trying
to open all tape devices at the same time.
-The typically unneeded MXGNOTE messages are now skipped
with the MXGEXIMSG option.
Change 33.207 z/OS 2.2: REQUIRES ML-55 of MXGTMNT, for ABEND S0E0-28.
ASMTAPEE In z/OS 2.2, IBM's CSRPOOL service, called by MCSOPMSG in
Sep 8, 2015 ASMTAPEE, puts diagnostic data into GR0, AR0, and AR15,
none of which are expected to be preserved, but R15 was
used by ASMTAPEE, because it was unused and available.
Now ASMTAPEE clears AR15 to eliminate the ABEND exposure.
Change 33.206 z/OS 2.2 Job Correlation Variables SMF30COR is now INPUT
BUILD005 kept in TYPE30xx datasets, and also output in PDB.JOBS,
VMAC30 PDB.STEPS, and PDB.SMFINTRV. Variable SMF26JCR was INPUT
Sep 4, 2015 and kept in TYPE26J2 previously, but now it is also kept
in PDB.JOBS and PDB.NJEPURGE datasets with BUILDPDB.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.205 DB2ACCTP variables QPACPKID/QPACLOCN/QPACASCH/QPACAANM
VMACDB2 and QPACCOLN could be truncated even though they have
Sep 2, 2015 valid extended name segments. The LENGTH test for the
new PAR QUERY fields wrongly INPUT them when they did not
exist, causing the DELFIX circumvention to incorrectly be
invoked, causing the extended segments to not be input.
Thanks to Tom Adams, State Farm, USA.
Thanks to Shankar Chatterjee, State Farm, USA.
Change 33.204 Variable IOTMNODD was never calculated in PDB.JOBS/STEPS,
BUIL3005 and the value in IOTMTODD was actually IOTMNODD. The
BUILD005 three calculations of IOTMTODD= should be IOTMNODD=.
Sep 2, 2015
Thanks to Rick Southby, Insurance Australia Group Limited, AUSTRALIA.
Change 33.203 Cosmetic. EXCLUDED FIELDS FOUND messages now print your
VMAC110 site's IMACEXCL testing values, so you can see if this is
Sep 1, 2015 for a new dictionary triplet that needs a UTILEXCL rerun.
This was originally added in Change 29.262, but somehow,
the needed quotes and ampersand "&CICXLTR" syntax got
changed to CICXLTR, which printed nothing.
Change 33.202 Velocity ZVPS 5.4 dataset XAMSYT has zero observations
VMACXAM because Change 33.157's recalculated SYTNLPS was zero.
Aug 29, 2015 The actual SYTNLPS+1 in the non-Total record is now used
Sep 2, 2015 and the false INVALID SYTCUP SEGMENT message is removed.
Sep 11, 2015 -Unexpected CPID='GPs' value is now output in XAMCPUTO as
there were no records with CPID='Total".
Thanks to Douglas C. Walter, CitiCorp, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 33.201 Support IBM INFOSPHERE CHANGE DATA CAPTURE VERSION 10.2.1
VMACCDC adds many new variables to the CDI, CDO, CDW, DLR, DSL,
Aug 30, 2015 DTC, OSC, SCT, SDT, TCT, and new TDT segments. However,
the SCT and TCT data does not match the documentation and
both SCTCPU and TCTCPU are invalid with this iteration.
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 33.200 -TYPE70xx datasets have always contained ONLY data for the
VMAC7072 engines that were ONLINE at interval end, and that had
Aug 28, 2015 NOT been VARYed ONLINE (i.e., CAI='01'X). Engines that
were IPL's (CAI='03'X) were NOT output, because the data
in those startup intervals was inconsistent in early MVS.
However, those partial interval's data is not only valid,
it is actually now required to prevent wrong or missing
values for CECSER in TYPE70/TYPE70PR/TYPE70EN datasets,
and to capture the IPL interval's resources.
-TYPE70EN variable CPUBSYTM is now correctly set missing
for zIIP/zAAP engines, since it is a CP engine metric.
-More observations are now output, so PROC COMPARE will
see differences in these variables:
TYPE70: CECSER CPUACTTM CPUMVSTM CPUWAITM PCTCPUBY
PCTMVSBY PCTRDYWT PLCPRDYQ SHORTCPS
TYPE70PR: CECSER
TYPE70EN: CECSER CPUBSYTM CPUMVSBY
Change 33.199 The AXWAY SMF record was INCOMPATIBLY changed by an
VMACAXWY increase of a field length.
Aug 31, 2015
Thanks to Rachel Holt, FMR, USA.
Change 33.198 -CICS/TS 5.3 BETA, Resource Class (MNSEGCL=5) could cause
VMAC110 INPUT STATEMENT EXCEEDED INPUT because only 112 bytes of
Aug 27, 2015 the MNR5LENT=120 bytes were read.
Change 33.197 -Variable LPBUSY in TYPE113 is the TOTAL BUSY for all CPs
ASUM113 and can exceed 100% with multiple engines, but variable
VMAC113 LPARBUSY in ASUM113 is the CPU BUSY OF ONE ENGINE. New
Aug 24, 2015 variable LPBUSY is now created in ASUM113 with TOTAL BUSY
to provide both perspectives on percent busy.
-Variable SRBSTATE is now created in ASUM113 to complement
the existing PRBSTATE variable.
Thanks to David Cogar, Wells Fargo, USA.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.196 BVIR variable's values are revised to match IBM reports.
VMACBVIR TVCSIZE is now internally in bytes, formatted MGBYTES,
Aug 30, 2015 and the label corrected.
AVGCPUSE is now percent (95.5) instead of 0.95 fraction.
AVGDEFTH is now correct, was 1000 too large.
Thanks to Patricia J. Jones, DST Systems, USA.
====== Changes thru 33.195 were in MXG 33.08 dated Aug 20, 2015=========
Change 33.195 TMON/CICS Version 4.0 Support was still wrong, with an
VMACTMO2 extra 8 bytes INPUT that shouldn't have been, so that
Aug 20, 2015 MXG 33.08 dated Aug 20 is NOW required for version 4.0.
-Variables TASTCPUC and TASTCPOC in dataset MONITASK have
invalid data values, await PTF from ASG.
Thanks to Francois Vancoppenolle, PV Group, BELGIUM.
Thanks to Dirk Thys, PV Group, BELGIUM.
Change 33.194 -The modern CLRMFV Clist is incompatible with the archival
ZCLRMFV ZASMRMFV program because RMF III files are allocated with
Aug 19, 2015 RMFC prefixed DDNAMEs and the archival version of
ZASMRMFV is not aware of these. This results in message:
RMFV015E +++ERROR: NO VALID RMF III INPUT FILES FOUND+++
-A new Clist ZCLRMFV for use with ZASMRMFV only is created
with this change that will only allocate RMF III data
sets with RMFV DDNAME prefixes.
Thanks to Tom Drager, Aurora Health Care
Change 33.193 ANALDSET abend IEC145I 413-04 with DDNAME=ADDPROG because
ANALDSET the DATA step inserted by Change 32.187 broke the logic
Aug 19, 2015 for UNIT=AFF by trying to read and write to and from the
same tape device.
Thanks to Randy Hewitt, HP Canada, CANADA.
Change 33.192 -CICS/TS 5.3 Beta added two new variables to CICSTRAN that
UTILEXCL caused UTILEXCL to report UNKNOWN WBJSNRQL and WBJSNRPL
VMAC110 fields, but the IMACEXCL it created has a syntax error,
Aug 18, 2015 And, since the two fields were INSERTED, the MXG INPUT
without IMACEXCL caused subsequent fields to be invalid
as they were misaligned. Now, 70/378/3376 are expected
values for 5.3 default SMFPSRVR, MCTSSDCN, and MCTSSDRL.
(Other values will generate the RUN UTILEXCL messages.)
-The CICSRDQU records have new reserved fields inserted,
that caused misalignment.
=====================================================
CICS/TS 5.3 IS STILL IN BETA, with final GA is Sep 31,
so IBM is still free to make other changes.
=====================================================
Thanks to Paul C. Gordon, Bank of America, USA.
Change 33.191 UTICBLDP error message COMPBL HAS TOO MANY ARGUMENTS was
UTILBLDP due to an unneeded second COMPBL invocation for MACKEEPX.
Aug 18, 2015 The second execution was removed, but the error was also
triggered by comments with "* comment text ;" syntax, and
using " /* comment text */ " syntax also circumvented the
error. In general, that second syntax is more robust,
but in this case, placing the comments OUTSIDE the MACRO
circumvents the need to parse either comment syntax.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.190 While the WORK.TY115215 dataset is created by TYPE115,
VMAC115 using TYPS115 did not create PDB.TY115215 because the
VMXGINIT _STY115X dataset sort macro for TY115215 was not added
Aug 17, 2015 in the _S115 "product" sort macro for SMF type 115s.
This caused dataset TY115215 to not be listed in DOCVER.
====== Changes thru 33.189 were in MXG 33.08 dated Aug 17, 2015=========
Change 33.189 Support for z/OS 2.2 (COMPATIBLE, but LOTS NEW STUFF):
BUILD005 -TYPE0203: Support for new ID=2 SUBTYPE=1 and 2 records
EXTY4227 create two new datasets in VMAC0203:
EXTY9037 DDDDDD DATASET DESCRIPTION
FORMATS TY0201 TYPE0201 TYPE 2 SUBTYPE 1 SIGNATURE GROUP
IMAC42 TY0202 TYPE0202 TYPE 2 SUBTYPE 2 SIGNATURE INTERVAL
IMAC90A -TYPE1415: Change 33.026 added support for LONG WANTED new
VMAC0203 variables SYSPLEX JESNR JCTJOBID TYPETASK, but the pre-
VMAC104 GA SMF Manual had the order of SYSPLEX/JCTJOBID while
VMAC106 the actual order is JCTJOBID/SYSPLEX and the typo will
VMAC1415 be corrected for the Sub-type 3 record.
VMAC30 -Sub-type 5, length is 72 but 70 in SMF Manual; two bytes
VMAC42 are skipped
VMAC6156 -SMF14ALIAS now created.
VMAC74 -SMF14DSVER value is '01'x but bits 0, 1, 2, are listed
VMAC90A in the SMF Manual. Await IBM answer.
VMAC99 -JOB variable has un-printable characters in the 14/15s,
VMACCTLG but valid characters are in JOB variable in 30s, in pre-
VMXGINIT GA data. Await IBM answer. SMF14ESL=26 STY=5 (old
Mar 8, 2015 length) protected.
Jun 8, 2015 -TYPE26J2: New IBM JCTJOBID=:'G' value will set the MXG
Jul 21, 2015 TYPETASK='JOBG', only in TYPE26J2 Purge Records for a
Jul 24, 2015 JOBGROUP's logging job's purge, which is the only place
Aug 4, 2015 that 'G' value is externalized in SMF records.
Aug 17, 2015 -TYPE30 : New ABEND='EVICT' value set in TYPE30 for jobs
Mar 1, 2016 evicted with $EJ,STEP,HOLD.
-TYPE42: Change 33.026 added support for new TYPE4227
dataset provide the VTOC AUDIT LOG with these variables:
JCTJOBID ='SMF42RNJO*JOB NUMBER'
JESNR ='JES*NUMBER'
TYPETASK ='TYPE*OF*TASK;
SMF42RIND ='SMF42RIND*RECORD*INDICATOR'
SMF42RSEEK='SMF42RSEEK*VTOC*TRACK*ID'
SMF42RSRCH='SMF42RSRCH*VTOC*RECORD*ID'
SMF42RCMDS='SMF42RCMDS*CCW*COMMAND*CODES'
SMF42RUPSW='SMF42RUPSW*CALLERS*ADDRESS'
SMF42RUTOK='SMF42RUTOK*USER*SECURITY*TOKEN'
SMF42RRSV ='SMF42RRSV*DEVICE*IS*RESERVED?'
SMF42RKEY ='SMF42RKEY*DSCB KEY*DATASET*NAME'
SMF42RDSC ='SMF42RDSC*DSCB*DATA*FIELD'
SMF42RACT ='SMF42RACT*ACTIVITY*TYPE'
with these possible activities in SMF42RACT that are
decoded by $MG042VT format:
'D***'='D***:DFSMS ACTIVITY'
'DCVF'='DCVF:CVAFDIR'
'DCRE'='DCRE:DADSM DATASET CREATE'
'DEXT'='DEXT:DADSM DATASET EXTEND'
'DPAR'='DPAR:DADSM DATASET PARTIAL RELEASE'
'DREN'='DREN:DADSM DATASET RENAME'
'DDEL'='DDEL:DADSM DSCB SCRATCH'
'DUPD'='DUPD:DADSM DSCB UPDATE'
'DFRG'='DFRG:DFSMSDSS DEFRAG'
'DCON'='DCON:DFSMSDSS CONSOLIDATE'
'DDMP'='DDMP:DFSMSDSS DUMP'
'DRST'='DRST:DFSMSDSS RESTORE'
'IOBE'='IOBE:IOBE NOT PROVIDED'
'USER'='USER:IOBEUSER NOT SPECIFIED'
-TYPE42: Support subtype 5/6 APAR OA44322/OA44319 CMR+
and new microsecond metrics was added in Change 32.113.
-TYPE74: Change 32.305 added support for new TYPE 74
variables: R744MNEL R744MNEC R744NSRK
-TYPE90A: Updated for new Type 90 subtype 37 to create
new TYPE9037 dataset that reports any changes to APF
status. The RACF UTOKEN has '55'X values in SMF data
because it's value is "MASKED", i.e., encrypted, while
MXG expected the "UNMASKED" values that are in UTOKEN in
other SMF records (42, 80, 119). The existing SMF 90
subtypes 29 and 31 also contain the MASKED UTOKEN, but
IBM Development has stated their intention to change to
UNMASK the UTOKEN in all three of those 90 subtypes.
HOWEVER: SEE CHANGE 33.282 - MXG now "unencrypts".
The RACROUTE REQUEST=TOKENMAP can do the "unmasking",
and can be used even on a system that was not the one
on which the SMF record was created, but that can only
be used on z/OS; even there it would take SIGNIFICANT
effort to issue a RACROUTE from within a SAS data step.
But since the data length is 80 bytes either way, and
the data is not secret, it really needs to be UNMASKED
to be of value, so IBM's future correction is welcome.
-TYPE90A: Two variables added to TYPE9037 dataset.
Formats added to TYPE9037 variables.
-TYPE99 : Five variables added to TYPE9912 dataset.
-TYPE104: Platform Types that create SMF Type 104 records
are expanded and format updated:
VALUE MG104PT
0='0:AIX ON SYSTEM P'
1='1:LINUX ON SYSTEM X'
2='2:LINUX ON Z SYSTEM'
3='3:WINDOWS ON SYSTEM X'
-TYPE106: Support for new ID=106 SUBTYPE=1 and 2 records
create two new datasets in VMAC106
DDDDDD DATASET DESCRIPTION
TY1061 TYPE1061 BCPII HWISET API CALLS
TY1062 TYPE1062 BCPII HWICMD API CALLS
Mar 1, 2016: Incorrect length for SMF6ASDL, corrected
to input 4 bytes.
-VMACCTLG and VMAC6156 were updated Nov 27, 2014.
Support for GDGE, GDG Extended GDGLIMIT=999 in z/OS 2.2.
New variable GATEXTND='E' flags the extended mode, new
variables GATLIMTE/GATCNTE are INPUT but also kept in the
existing GATLIMIT/GATCNT to preserve existing reports.
Some overlooked flag variables in the 05 Catalog Segment
are now decoded and kept in datasets TYPE6156 (from SMF
(type 61, 65, 66) and TYPECTLG (from the IDCAMS EXPORT
CATALOG flat file). These are all the 05 fields now:
GATALLOC='GATALLOC*FIFO OR*LIFO?'
GATCNT ='GDG*COUNT'
GATDELET='DELETE*WHEN*LIMIT*EXCEEDED*0=OLD*1=ALL?'
GATEXTND='GATEXTND*EXTENDED*OR CLASSIC?'
GATEXTNO='GATEXTNO'
GATGEN ='GATGEN '
GATLIMIT='MAXIMUM*GDS*ENTRIES*IN GDG*BASE'
GATLIMTE='EXTENDED*GAT*GATLIMIT'
GATPURGE='GATPURGE*YES OR*NO?'
GATSCRTH='SCRATCH*FORMAT 1*DSCB*0=NO*1=YES?'
GATVER ='GATVER '
GATWRAP ='GATWRAP '
GDGATTR ='GDGATTR'
-BUILD005 protects for TYPETASK='JOBG' in JCTJOBID.
Change 33.188 TMON/CICS Version 4.0, these four MONITASK variables were
VMACTMO2 divided by 4096, TWICE:
Aug 13, 2015 TASTCPUT TASTCPOT TACNTRTM TACNTWTM
and these MONIAMQ variables were NOT divided because the
test was GT 4 and it should have been GE 4.
TAAMQOPT TAAMQCLT TAAMQGTT TAAMQPTT TAAMQP1T
TAAMQIQT TAAMQSTT
This change is REQUIRED to support TMON/CICS Version 4.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.187 DB2 T102S106 didn't keep variables QWP4RSMX and QWP4ACAN
VMAC102 and these zparms were not input.
Aug 14, 2015 QWP1CSMF='SMFCOMP'
Aug 20, 2015 QWP1FLG2='QWP1FLG2*FLAG*BITS'
QWP1LOGT='LOG*CHECKPOINT*TYPE'
QWP4ABVC='QWP4ABVC*SERVICEABILITY'
QWP4ACAN='QWP4ACAN*SERVICEABILITY'
QWP4CGAA ='GET_ACCEL_ARCHIVE*0=NO*1=YES*/
QWP4CQAC ='QUERY*ACCELERATION'
QWP4EXQRY ='QWP4EXQRY'
QWP4FCPPRC='FLASHCOPY*PPRC'
QWP4QACO ='QUERY*ACCEL*OPTIONS'
QWP4RFRP ='REC_FASTREPLICATION'
QWP4RLPR ='REORG*LIST*PROCESSING'
QWP4RPSN ='REORG*PART*SORT*NPSI'
QWP4RSMX='QWP4RSMX*SERVICEABILITY'
QWP4STMN ='REALSTORAGE*MANAGEMENT'
QWP4WFRD ='MAX RID*BLOCKS*TEMP STG*PER RID LIST'
QWP4_BIF_COMPAT='BIF*COMPATIBILITY'
QWP9DDFCIP='DDF COMPAT*IDENTITY*PRIOR VERSION*NNR'
Thanks to Lai Fai Wong, Bank of America, USA.
Change 33.186 -An INCOMPATIBLE z13 ERROR, only in SMT-MODE, and only if
VMAC7072 a CP engine is varied online, is now corrected. When a
Aug 16, 2015 a z13 in SMT mode varied a new CP online, MXG did not see
the new engine, causing PDB.TYPE70 and PDB.TYPE70EN to
be wrong, with incorrect PCTCPUBY and NRCPUS=. and no
dispatch times for the new CP engine in PDB.TYPE70.
An IBM error is only partially responsible: after the
VARY, the value for SMF70CIX in the PR/SM LP Data Section
is incorrect (1, for CP, instead of 6, for zIIP) in both
of the zIIP sections for the second zIIP engine, causing
MXG to identify those zIIPs as CP Engines, mismatching
the engines in the CPU Data Section. That error is
circumvented by revising MXG to use the SMF70TYP value
from the CPU data section (which is clearly what IBM had
to use in their RMF reports). A second error was MXG's:
the new CP Engine PR/SM section was located AFTER those
zIIP sections, but MXG's original SMT logic was correct
only when all CPs preceded the zIIPs. That incorrect
MXG logic was revised to now be order independent.
-TYPE70PR does NOT contain SMT variables, those data are
only output in PDB.TYPE70EN since they can only be
populated from "this" system's TYPE70 records.
Thanks to Douglas C. Walter, CitiCorp, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 33.185 -Labels for TYPE30 ZEDC variables with _INF_/_DEF_ are now
FORMATS spelled out as INFLATE and DEFLATE.
VMAC30 -TYPE74 subtype 9 DIVIDE BY ZERO caused by R749FRQC=1 is
VMAC74 eliminated by changing test to R749FRQC GT 1 since more
Aug 11, 2015 than one instance is required to calculate STD (Standard
Aug 17, 2015 Deviation) statistic.
Aug 20, 2015 New variable PCTCRDBY added to TYPE749 dataset for card
Aug 30, 2015 busy percentage.
-TYPE74 variables used to create SSQ (Sums of Squares) are
no longer kept since the STD variables are calculated.
-Variable R749DFMT is now labeled 'PCIE*FUNCTION*TYPE' and
is decoded by MG074DF format to describe which sets of
variables are populated:
0='0:DMA COUNTERS'
1='1:ETHERNET INTERFACE'
2='2:WORK UNITS'
However, records with SMF749DL=16 do not contain R749DFMT
so R749DFMT will be missing, causing all of these sets of
variables to have missing values:
0: R749DMAR R749DMAW R749DBYR R749DBYT R749DPKR
1: R749DBYR R749DBYT R749DPKR R749DPKT
2: R749DWUP R749DWUM
SMF749DL=40 is required for PCIE Function Type Data to
actually exist.
-Aug 17: INVALID type 30 zEDC segments (SMF30USO points
to the middle of the EXCP Section, or points beyond the
end of the record) were just confirmed by IBM support,
and occur because the SMF30USN count is not being reset
to zero in the "Continuation", MXG MULTIDD='Y' records.
The MXG Logic now only inputs the SMF30USO segment when
MULTIDD=' ', i.e., only for the base/original record.
Aug 25: IBM APAR OA48717 will correct the invalid zEDC
triplet information in the TYPE30 record.
-Aug 20: zEDC Compression Ratios for Inflate/Deflate are
created and kept in all TYPE30 datasets.
-Aug 30: zEDC Compression Ratios for Inflate/Deflate are
created and kept in TYPE749 datasets.
Thanks to Joe Faska, DTCC, USA.
Change 33.184 Support for SYNCSORT Release 1.4 (INCOMPATIBLE). Change
VMACSYNC 33.102A added support for Release 2.1, which has the same
Aug 11, 2015 SMF data, so this change now tests SYNCVAL GE 1.4 to now
populate READTIME and many other variables that are wrong
without this change.
Thanks to Joe Faska, DTCC, USA.
Change 33.183 Support for MAR Hitachi Command Suite Mainframe Analytics
EXMAR01 Recorder, user SMF records creates these dataset:
EXMAR02
EXMAR03 DDDDDD MXG MXG
EXMAR04 DATASET DATASET DATASET
EXMAR05 SUFFIX NAME LABEL
EXMAR06
IMACMAR MAR01 MARST01 LOST SMF INFORMATION
TYPEMAR MAR02 MARST02 LDEV INFORMATION
TYPSMAR MAR03 MARST03 MPB INFORMATION
VMACMAR MAR04 MARST04 PRGP INFORMATION
VMXGINIT MAR05 MARST05 PORT INFORMATION
Aug 11, 2015 MAR06 MARST06 MP USAGE TO TWENTY
Change 33.182 -Major enhancement for character data filtering for ASI
ADOCRMFV RMF Monitor III table entries and other improvements.
ASMRMFV -These filters are intended for building ad hoc MXG RMF
Aug 1, 2015 III PDBs for studies avoiding the overhead of generating
a full ASI table based PDB. They control which ASI table
entries are output to the RMFBSAM file.
-10 new filters are added to support ASI entry selection
from this table to the RMFBSAM output file. These
filters are effective only if the ASI table is selected.
They are applied in the order shown when multiple
different keywords are used.
New Keyword Aliases
------------ --------------------------------------
ASISUBSYS= ASISUB= TYPETASK=
ASIWORKLOAD= ASIWKLD= ASIWNM= ASIWL=
ASIRESGROUP= ASIRESGRP= ASIGNM= ASIRG=
ASISRVCLASS= ASISCLASS= ASICNM= ASISC=
ASIRPTCLASS= ASIRCLASS= ASIRNM= ASIRC=
ASIJOBCLASS= ASIJCLAS= ASICLASS= ASIJC=
ASIJOBNAME= ASIJOBNA= ASIJOBNM= ASIJOB= ASIJN=
ASIJESID= ASIJESNO= ASIJESNUM= ASIJESNR= ASIJID=
ASIAND None
ASIOR None
-TUTORIAL:
Ranges of the form keyword=first:last may be used with
any of the above keywords except ASIAND and ASIOR. The
colon character ':' is required for a range
specification.
However, single values may be specified for a range
simply as keyword=first and in this case the colon ':'
can be omitted.
All ASI entries GE the first value and LE the last value
are selected for output to the RMFBSAM file. Ranges may
not be wild carded only patterns. The first value in a
range may not be GT the last value or an error is noted.
Patterns may also be used with any of the above keywords
except ASIAND and ASIOR and include one or more wild card
characters to match the respective ASI data field.
Wild
Card Matches
---- -------------------------------------------------
* 0 or more characters
% 1 Non-blank character
+ 1 Numeric character (0-9)
_ 1 Alphabetic character or _ (a-z, A-Z, _)
. 1 National character (@, #, $)
! 1 Special character (not a-z, A-Z, 0-9, @, #, $)
? A blank string if used by itself
? 1 Blank character (X'40') if used with any other
characters
See Section 25 in the ADOCRMFV member for more details on
usage of ranges and patterns.
-ASISUBSYS= selects ASI entries by host Subsystem Name:
APPC, JOB, OMVS, STC, TSU, UNKN.
More than one subsystem may be requested. Ranges and/or
patterns may also be used, but are generally unnecessary
given the limited possible choices. Only those IBM
subsystems defined in the ASI table are supported.
Subsystem names are validated. The default is
ASISUBSYS=ALL.
For ease in coding and recall there are several value
aliases allowed with ASISUBSYS=.
Subsystem
Name Supported Values
--------- -----------------------------------------
APPC A, AP, APP, APPC, AS, ASC, ASCH
JOB J, JO, JOB, JOBS, B, BA, BAT, BATC, BATCH
OMVS O, OM, OMV, OMVS
STC S, ST, STC, STA, STAS, STASK, STASKS
TSU T, TS, TSO, TSU, TSUS
UNKN U, UN, UNK, UNKN, UNKNO, UNKNOW, UNKNOWN,
UNKNOWNS
-Examples for ASISUBSYS=
ASISUBSYS=JOB selects only Batch jobs.
ASISUBSYS=J:S selects Batch jobs, OMVS address spaces,
and Started Tasks because these all fall into the range.
ASISUBSYS=JOB ASISUBSYS=TSO selects Batch job and
TSO user address spaces.
-ASIWORKLOAD= selects ASI entries by 8 character WLM
Workload Name. Both ranges and patterns with wild card
characters may be specified. Up to 64 ranges and 64
patterns are supported. The default is ASIWORKLOAD=ALL.
-Examples for ASIWORKLOAD=
ASIWL=PROD:TEST selects all WLM Workloads GE 'PROD' and
LE 'TEST' using a range. Note use of keyword alias
ASIWL.
ASIWORKLOAD=PROD* selects only address spaces with a WLM
Workload Name that begins with 'PROD' as a pattern.
ASIWORKLOAD=TEST+++ selects only address spaces with a
WLM Workload Name that begins with 'TEST' followed by 3
digits as a pattern.
ASIWORKLOAD=? selects only address spaces with a blank
WLM Workload Name as a pattern.
ASIWORKLOAD=%* selects only address spaces with a
non-blank WLM Workload Name as a pattern.
-ASIRESGROUP= selects ASI entries by 8 character WLM
Resource Group Name. Both ranges and patterns with wild
card characters may be specified. Up to 32 ranges and 32
patterns are supported. The default is ASIRESGROUP=ALL.
-Examples for ASIRESGROUP=
ASIRG=CAP10:CAP20 selects all WLM Resource Groups GE
'CAP10' and LE 'CAP20' as a range. Note use of keyword
alias ASIRG.
ASIRESGROUP=CAP__ selects only address spaces with a WLM
Resource Group Name that begins with 'CAP' followed by 2
alphabetic characters as a pattern.
ASIRESGROUP=CAP%%% selects only address spaces with a WLM
Resource Group Name that begins with 'CAP' followed by 3
characters as a pattern
ASIRESGROUP=? selects only address spaces with a blank
WLM Resource Group Name as a pattern.
ASIRESGROUP=%* selects only address spaces with a
non-blank WLM Resource Group Name as a pattern.
-ASISRVCLASS= selects ASI entries by 8 character WLM
Service Class Name. Both ranges and patterns with wild
cards may be specified. Up to 64 ranges and 64 patterns
are supported. The default is ASISRVCLASS=ALL.
-Examples for ASISRVCLASS=
ASISC=BATHIGH:BATLOW selects all WLM Service Classes GE
'BATHIGH' and LE 'BATLOW' as a range. Note the use of
keyword alias ASISC.
ASISRVCLASS=*HIGH selects only address spaces with a WLM
Service Class Name that ends with 'HIGH' as a pattern.
ASISRVCLASS=*+* selects only address spaces with a WLM
Service Class Name that contain only one numeric
character as a pattern.
ASISRVCLASS=? selects only address spaces with a blank
WLM Service Class Name as a pattern.
ASISRVCLASS=%* selects only address spaces with a
non-blank WLM Service Class Name as a pattern.
-ASIRPTCLASS= selects ASI entries by 8 character WLM
Report Class Name. Both ranges and patterns with wild
cards may be specified. Up to 64 ranges and 64 patterns
are supported. The default is ASIRPTCLASS=ALL.
-Examples for ASIRPTCLASS=
ASIRC=DB2:TSO selects all WLM Report Classes GE 'DB2' and
LE 'TSO' as a range. Note the use of keyword alias
ASIRC.
ASIRPTCLASS=LOW.%%% selects only address spaces with a
WLM Report Class Name that begins with with 'LOW',
followed by a national character, and then followed by 3
more characters as a pattern.
ASIRPTCLASS=MED++* selects only address spaces with a WLM
Report Class Name that begins with 'MED', followed by 2
digits, and then possibly other characters as a pattern.
ASIRPTCLASS=? selects only address spaces with a blank
WLM Report Class Name as a pattern.
ASIRPTCLASS=%* selects only address spaces with a
non-blank WLM Report Class Name as a pattern.
-ASIJOBCLASS= selects ASI entries by JES Job Class.
Both ranges and patterns with wild cards may be
specified. Up to 32 ranges and 32 patterns are
supported. The default is ASIJOBCLASS=ALL.
-Examples for ASIJOBCLASS=
ASIJC=A:D selects only address spaces with a JES Job
Class of A, B, C, or D as a range. Note use of the
keyword alias ASIJC.
ASIJOBCLASS=+ selects only address spaces with a numeric
JES Job Class of 0-9 as a pattern.
ASIJOBCLASS=? selects only address spaces with a blank
JES Job Class as a pattern.
ASIJOBCLASS=%* selects only address spaces with a
non-blank JES Job Class as a pattern.
-ASIJOBNAME= selects ASI entries by 8 character z/OS Job
Name. Job Name characters are validated to those allowed
by JCL syntax. Both ranges and patterns with wild cards
may be specified. Up to 64 ranges and 64 patterns are
supported. The default is ASIJOBNAME=ALL.
-Examples for ASIJOBNAME=
ASIJN=PROD1234:PROD5678 selects only address spaces with
a z/OS Job Name GE 'PROD1234' and LE 'PROD5678' as a
range. Note use of the keyword alias ASIJN.
ASIJOBNAME=.* selects only address spaces with a Job Name
that begins with a national character as a pattern.
ASIJOBNAME=*++ selects only address spaces with a Job
Name that ends with 2 numeric digits as a pattern.
-ASIJESID= selects ASI entries by 8 character JES Job
Identification. Both ranges and patterns with wild cards
may be specified. Since a JES Id is one character
followed by 7 digits or three characters followed by 5
digits not all pattern characters may be used with this
keyword. For convenience any leading zeros in the
numeric portion of the JES Id may be omitted and will be
filled in automatically. Up to 64 ranges and 64 patterns
are supported. The default is ASIJESID=ALL.
-Examples for ASIJESID=
ASIJID=J0000100:J0001123 selects all address spaces
with batch JES Id numbers GE 100 and LE 1123 as a
range. Note use of keyword alias ASIJID.
ASIJID=J100:J1123 selects the same address spaces as
above with the leading zeros omitted for coding
convenience.
ASIJESID=JOB12345:JOB32001 selects all address spaces
with batch JES Id numbers GE 12345 and LE 32001 for
installations with 5 digit JES Id numbers as a
range.
ASIJESID=J1* selects all batch address spaces with a
JES ID that begins with '1' as a pattern.
-ASIAND (default) indicates that selection results from
two or more different ASI filter keywords are logically
ANDed.
-ASIOR indicates that selection results from two or more
different ASI filter keywords are logically ORed.
-Examples of ASIAND/ASIOR:
With ASIAND in effect
ASISUBSYS=BATCH ASIJOBNAME=XYZ*
selects ONLY batch jobs whose those job names begin with
'XYZ'. ASIAND (default) provides more restrictive ASI
entry selection.
With ASIOR in effect
ASISUBSYS=BATCH ASIJOBNAME=XYZ*
selects ALL batch jobs OR any job names beginning with
'XYZ' even if they ran under another subsystem. ASIOR
provides less restrictive ASI entry selection.
-Selection results from repeats of the SAME ASI filter
keyword are always logically ORed.
-New parameter SYSAND (default) indicates that selection
results from the SYSPLEX= and SYSTEM= filter keywords for
the Data Set Header (DSH) table when both are specified
are logically ANDed.
-New parameter SYSOR indicates that selection results from
the SYSPLEX= and SYSTEM= filter keywords for the Data Set
Header (DSH) table when both are specified are logically
ORed. SYSOR must be coded when needed.
-Examples of SYSAND/SYSOR:
With SYSAND in effect
SYSPLEX=PROD SYSTEM=SYSP
selects ONLY RMF III data sets originating from the PROD
sysplex AND the SYSP LPAR. SYSAND (default) provides
more restrictive RMF III data set selection.
With SYSOR in effect
SYSPLEX=PROD SYSTEM=SYSP
selects ALL RMF III data sets originating from the PROD
sysplex OR any data sets for the SYSP LPAR even if SYSP
is part of a different Sysplex. SYSOR provides less
restrictive RMF III data set selection.
-Selection results for multiple SYSPLEX= values are always
logically ORed.
-Selection results for multiple SYSTEM= values are always
logically ORed.
-The '_' pattern character now matches lower case in
addition to upper case alphabetic characters in a source
string.
-The '_' pattern character will now match an underscore in
a source string. While this character is not technically
alphabetic, the underscore is sometimes used in some WLM
names for better legibility.
-A new pattern character '?' will allow selection of
completely blank source strings when used only by itself.
When '?' is used with other characters in a pattern a
single imbedded blank in a source string is matched.
-Example of ? pattern character:
ASIRPTCLASS=? selects all ASI entries that do not have a
WLM Report Class assigned or that could not be found by
ASMRMFV. That field in the ASI entry must be completely
blank to select that entry.
-A new pattern character '!' will match special characters
in a source string. For this purpose special characters
are those bytes in the EBCDIC code table that are NOT
alphabetic (a-z, A-Z), numeric (0-9), national (@,#,$),
or blank (X'40') and have been assigned to a character.
-Example of ! pattern character:
X'5C' is assigned the EBCDIC asterisk '*' and would match
the ! pattern character. However, X'00' does not match
this pattern character because no EBCDIC character is
assigned to this byte.
ASIJOBNAME=!MASTER! selects the *MASTER* address space.
Coding ASIJOBNAME=*MASTER* in this case instead may
produce different results because the '*' is a pattern
character itself representing zero to many characters.
So any job name with 'MASTER' imbedded would be selected.
-Section 5 "Input Data Selection Parameters" is updated
with discussion of all the new ASI selection keywords and
aliases.
-A new Section 25 "Ranges and Patterns" has been added to
the documentation to explain use of these features in
detail.
-A new Section 26 "Summary" is added to replace the old
Section 25 and includes a summary of the new ASI keywords
and all pattern characters.
-New parameter SHOWALL (alias SA) indicates that the
settings for all possible filter keywords that take range
and/or pattern values are to be displayed in the ASMRMFV
log in message RMFV006I even when no filters have
actually been specified for a particular keyword. These
display as keyword=ALL.
-New parameter NOSHOWALL (alias NOSA) indicates that only
filter keywords that have actual range and/or pattern
values specified are to be displayed in the ASMRMFV log
in message RMFV006I. This option helps reduce the size
of the ASMRMFV log. NOSHOWALL is the default.
-Section 6 "Report Control Parameters" is updated to add
SHOWALL/NOSHOWALL parameters.
-Several messages are slightly changed either to
accommodate longer ASMRMFV keywords for the ASI filter
selection or to display their settings.
Change 33.181 Enhancement for RMFINTRV/TRNDRMFI to ADD variables to be
VMXGRMFI kept. While the existing VMXGRMFI program provides many
Jul 30, 2015 arguments (R70ID, R70MAX, R70SUM, etc) that can be used
in your tailored %VMXGRMFI call, those arguments require
you to list ALL of the variables to be kept. This change
adds the ADD70ID=, ADD70MAX=, etc., arguments that only
list the variables to be added.
Thanks to Joachim Sarkoschitz, DATEV, GERMANY.
Change 33.180 Support for MQ Version 8 subtype 215 record which creates
VMAC115 DDDDDD DATASET DESCRIPTION
VMXGINIT TY115X TY115215 TYPE 115 ST 215 BUFFER STATS
Jul 30, 2015 -New variables QPSTFLAG0 and QPSTFLAG1 added to TY115215
and MQMBUFER datasets.
Change 33.179 -z13 in SMT Mode could have blank LPARNAME in TYPE70EN and
VMAC7072 MXG variable SMF70MTTT (misnamed, IBM field is SMF70MTIT)
Jul 29, 2015 is now deaccumulated in PDB.TYPE70EN.
Aug 4, 2015 -For SMT Mode, for complete detail per-engine data, use
the PDB.TYPE70EN dataset instead of PDB.TYPE70.
-This change also populated SMF70WTI/WTS/WTU in TYPE70PR
with zeros or real values that were previously missing.
-Aug 4. Corrected SORT error due to delete with TYPE7072.
Change 33.178 Many of the ANAL* members in JCLPDB9 were old (some had
JCLPDB9 not been touched in decades) or archaic and in some cases
Jul 29, 2015 had been replaced by more robust and up to date members.
These are ONLY included as examples; it is NOT likely
that you would execute ALL of these example ANALxxxx
reports in your production BUILDPDB.
ANALCONT - replaced by VMXGPRAL
ANALMPL - replaced by ANALINIT
ANALTURN - replaced by ANALINIT
ANALAVAL - removed since successful execution requires
user tailoring
ANALESV - obsolete
GRAFWRKX - added
GRAFCEC - added
All report members now have comments describing them
Commented ODS statement added to route output to PDF
Change 33.177 -A new parameter PRINT was added. A value of ALL/DETAIL
ANALRANK generates a report for each of the variable named in the
ANALPROG VARS parameter, and a summary report with the rankings
Jul 28, 2015 of ALL variables is produced.
A value of DETAIL generates only the individual named
variable report.
A value of SUMMARY only generates the summary report.
SUMMARY is assumed if PRINT is left blank.
-A third example generates a report similar to ANALPROG.
Change 33.176 Unused Change.
Change 33.175 Support for IHDRBBMQ "Infile Header Exit" for TYPEBBMQ
IHDRBBMQ and associated macro variable &MACBBMH permits selection
VMACBBMQ of data to be output after the BBMQ Header has been read.
VMXGINIT
Jul 27, 2015
Change 33.174 The number of IFL processors in an LPAR was incorrectly
VMXG70PR set to the number of IFLS on the CEC and IFL busy was
Jul 21, 2015 also incorrect since it was based on the CEC not on the
LPAR.
Change 33.173 For the z13, SM1132SP was forced because the value in the
ASUM113 z13 SMF 113 records is not correct, but SM1132SP=5000 is
VMAC113 the correct value, not 5. This impacted only EFFGHZ and
Jul 22, 2015 LPARBUSY values.
Thanks to David Cogar, Wells Fargo, USA.
====== Changes thru 33.172 were in MXG 33.07 dated Jul 22, 2015=========
Change 33.172 -If you specified USERADDS=NOUSERID and IDs over 128 were
ANALID found, an EOF test that built the macro variable that was
Jul 22, 2015 used in UTILBLDP was never executed.
-A superfluous RETURN; caused an error if you specified
SMFAUDIT=NO.
Change 33.171 MXGLOG code failed to wrap a PUT with a DO group, causing
VMAC120 potentially MANY of these log messages to be printed"
Jul 20, 2015 ***SMF 120 SUBTYPE 9 UNEXPECTED MULTIPLE SEGMENT.
_N_=2 SYSTEM=XX SMFTIME=19JUL2015:00:04:54.20 SM1209AK=1
Thanks to Jim S. Horne, Lowe's Companies, USA.
====== Changes thru 33.170 were in MXG 33.07 dated Jul 17, 2015=========
Change 33.170 The test to identify IPV6 IP address was incorrect.
VMACCTCP
Jul 16, 2015
Change 33.169 The z13 protection for zero divide for TLB1CYCL,PTEPCTMI,
ASUM113 TLB1MSRT still used the zEC12 EXTND133+EXTND140 values
Jul 16, 2015 but the z13 changed the divisor to EXTND129+EXTND134,
which should have been also been used for the zero test.
Luckily, the incorrect test was non-zero so the correct
values were calculated.
Thanks to David Cogar, Wells Fargo, USA.
Change 33.168 The SMF 30 INSTRUCTION count variables require HIS to be
VMAC30 enabled, or all _INST counters will be missing values.
Jul 15, 2015 These two new variables are now created to identify why.
SMF30_INSTCAPTDISRUPTION='NO*INSTRUCTION*COUNTERS'
SMF30_INCOMPLETE_DATA='INSTRUCTION*COUNTERS*INCOMPLETE'
From Bob Rodgers SHARE 2014 SYSPROG Goody Bag notes:
- To get instruction counts in Counter Data Section,
HIS must activate the CPU Measurement Facility to
collect at least the basic counter set.
- MODIFY HIS,BEGIN,CTRONLY,CTRSET=(B) is minimal
- MODIFY HIS,BEGIN,CTRONLY,CTRSET=(B,E) is recommended
- SMFPRMxx must contain the keyword SMF30COUNT
Thanks to Alfred Holz, Express-Scripts, USA.
Change 33.167 MXGDB2B1 report checked for a macro variable that could
ANALDB2R only be defined if you are on SAS 9.4 or higher. A %LET
Jul 13, 2015 was added to instantiate the variable to protect ancient
versions.
Change 33.166 Support for Correlog z/OS Agent SMF User record created
EXTYCZA new dataset.
IMACCZA dddddd dataset Description
TYPECZA TYCZA TYPECZA Correlog z/OS AGENT
TYPSCZA
VMACCZA
VMXZGINIT
Jul 29, 2015
Change 33.165 Subtype 24 XPTR records decoded
VMACXPTR
Jul 9, 2015
Change 33.164 -If you specified READDB2 with IFCIDS=ALL and PDBOUT=WORK
READDB2 some IFCIds (22 and 217) that create multiple datasets
VMAC102 failed in their sort of those additional datasets looking
Jul 8, 2015 for a PDB LIBNAME. In addition if you specifically
requested (for example) IFCIDS=I22 it would fail looking
for _C102I22 since the code to create that dataset is in
_C102022. READDB2 now converts I22 to 22 U17 v17 T17 to
217.
-The _S102 "sort all 102s" macro now skips 202/225/230/239
and 369 because they are NOT 102s and instead are created
in 100.2, 100.4, 100.3, 101.1, and 100.5 ID/Subtypes.
Change 33.163 CICSTRAN variable PHSTARTM was incorrectly INPUT as PIB4
VMAC110 time of day, and PHSTARCN was input as a counter, but now
UTILEXCL PHSTARTM is INPUT TODSTAMP8, formatted DATETIME21.2, and
Jul 7, 2015 converted to local zone; PHSTARCN should never have been
created so it no longer is.
Thanks to David Shaw, M&T Bank, USA.
Thanks to Doug Donoho, M&T Bank, USA.
Change 33.162 "MXGLOG" option to send MXG Messages to MXGLOG filename.
VMXGINIT Macros %MXGLOGDO, %MXLOGPUT and MXLOGEND are defined in
VMACSMF VMXGINIT. If an //MXGLOG DD or FILENAME MXGLOG is used,
Jul 10, 2015 MXG will automatically enable and send MXG messages to
Jul 12, 2015 the MXGLOG file on z/OS; on ASCII you send those messages
Jul 14, 2015 to FILENAME MXGLOG 'c:\mxg\mxglog.txt'; but note that the
Nov 23, 2015 file is written with MOD, so you may need to clear the
file with DATA _NULL_; FILE MXGLOG;
Status: These members' messages are updated:
VMAC0 VMAC0203 VMAC10 VMAC113 VMAC115
VMAC116 VMAC120 VMAC21 VMAC22 VMAC23 VMAC26J2
VMAC30 VMAC42 VMAC6 VMAC6156 VMAC7 VMAC7072
VMAC71 VMAC73 VMAC74 VMAC75 VMAC76 VMAC77
VMAC78 VMAC89 VMAC8911 VMACDB2 VMACID VMACTMNT
VMACSMF VMXG70PR
These include all members in the default BUILDPDB.
The last change-date wasn't updated in these members, as
the changes did not impact the output datasets.
The syntax of the messages written to MXG log will be
MXGLOG::MXGtype.member.nnn
where type is INFO, WARNING or ERROR,
member is the member name that creates the message
nnn is a sequence number in that member name.
Thanks to MP Welch, Bank of America, USA.
Change 33.161 Support for MOBILEWRK to read BMC's IMF/CIMSTRAN FA IMS
MOBWRKI3 log records to create CIMSTRAN and use in MOBWRKI3, or
MOBWRKI4 to use existing CIMSTRAN dataset(s) in MOBWRKI4.
MOBILWRK Only comments updated in MOBILWRK.
Jul 6, 2015
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 33.160 Reserved Change Number, now Unused.
Change 33.159 Support for ANALID and VMXGSRCH to decompress DB2 or CICS
ANALID records, on z/OS when EXITCICS/CICSIFUE exit is not used,
DB2DECOM or on ASCII, where EXITCICS cannot be installed.
MXGDECOM -For ANALID, the DB2 Product section, containing IFCID and
SMFSRCH SUBTYPE and DB2 Version, is compressed, so those values
UTILBLDP are missing. Optional new SMFDECOMP=DB2 argument invokes
VMAC110 the MXG internal code to decompress 101 and 102 records
VMACDB2 so those values can be reported. (Not needed for CICS as
VMACSMF its version/subtype is the uncompressed area.)
VMXGINIT -For SMFSRCH, compressed CICS 110 and DB2 101/102 records
Jul 17, 2015 couldn't be searched. New SMFDECOMP=BOTH or DB2 or CICS
argument will invoke the MXG decompression code so those
records can be searched for the LOOKFOR text.
-WARNING: The internal Code decompression requires A LOT
more CPU time than the EXITCICS exit. A 5GB DB2 SMF file
required 34 CPU minutes with the internal algorithm, but
only 13.5 CPU minutes using EXITCICS. That is why YOU
must choose to enable the SMFDECOMP decompression.
-You can also force decompression of CICS and/or DB2 data
when only the _SMF (decode SMF header macro) is used:
%LET MXGDECOMP= BOTH or DB2 or CICS ;
%INCLUDE SOURCLIB(VMACSMF);
DATA; _SMF;
The decompressed record will be in variable _INFILE_.
-UTILBLDP is invoked by SMFSRCH to create all datasets in
the selected SMF records; testing exposed an incorrectly
built macro for type 102 when BUILDPDB=NO and the IFCID
was only 2 characters long.
-The decompression %MACROs MXGDECOM and DB2DECOM are now
defined in those members and the redundant definitions
in VMACSMF, VMAC110 and VMACDB2 are removed, since the
AUTOCALL facility will resolve them when referenced.
Change 33.158 Type 6 ESS zero length segment caused INPUT STATEMENT
IMAC6ESS EXCEEDED STOPOVER error condition when the segment was
Jul 3, 2015 the last ESS segment. GEPARMKY=0016x and 0027x have been
observed with zero segment length, which would seem to be
an IBM error (to be investigated with IBM Support) but
protection is added to prevent the STOPOVER error.
In testing this change with on-hand SMF 6 records from
other users four new ESS segments are now decoded:
ESSCKPTPAGE ESSOVERLAYB ESSOVERLAYF ESSDUPLEX
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 33.157 zVM XAM ERROR SYTCUP SEGMENT LENGTH occurs if the online
VMACXAM engine count is changed, because XAM does NOT change the
Jul 1, 2015 value in SYTNLPS, which always contains the number of
INSTALLED engines (and the same is true of variable NCPUS
from the SUBSUM segment). This change recalculates the
number of engines into SYTNLPS based on SEGLEN, which XAM
does update, and which is then used to input the actual
online CP segments.
Thanks to Patricia Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
Change 33.156 Support for APAR OA44525, zHPF Extended Distance II.
VMAC78 -New variables added to TYPE78CF dataset:
VMAC79 R783CTMW='TRANSPORT*MODE*WRITE*COUNT'
Jun 30, 2015 R783CTRD='1ST XFER*READY*DISABLED*WRITE COUNT'
R783TMWM='XPORT*WRITE*COUNT*DCM CHANNELS'
R783TRDM='1ST XFER*READ*DISABLED*DCM CHANNELS'
-New variables added to TYPE79EF dataset:
R79ECTRD='1ST XFER*READY*DISABLED*WRITE COUNT'
R79ETMWM='XPORT*WRITE*COUNT*DCM CHANNELS'
R79ETRDM='1ST XFER*READ*DISABLED*DCM CHANNELS'
PCTPTHBY='PERCENT*CHPID PATH*BUSY'
Change 33.155 -TYPE74ST dataset now has Storage Class Memory variables
VMAC74 that were incorrectly output in TYPE74MO dataset, which
Jul 5, 2015 should never have been created and no longer is.
Oct 4, 2015 -Text added Oct 4, 2015:
Variable R744SNAM=STRUCTURE NAME was added to TYPE74DU
and TYPE74HO datasets, but not noted in the change text,
nor was it added to the _BTY74HO BY List, but in Oct it
was observed that the addition of R744SNAM to TYPE74HO
caused a CORRECT INCREASE in number of observations in
PDB.TYPE74HO (even though the WORK.TYPE74HO had the same
number of observations). Because R744SNAM was not kept,
the previously NODUP sort was incorrectly removing obs
that were not duplicates, and its addition accidentally
prevented their removal. Change 33.234 now updates the
BY list to explicitly include R744SNAM.
-MXG Internal Note on no longer creating a dataset: The
macro variables PTY74MO/WTY74MO in VMXGINIT, and all
the _xTY74MO old-style macro tokens must still be
defined in VMAC74, just in case they were used in user
tailoring. Member EXTY74MO also must exist to protect
tailored code, and the_STY74MO token was removed from
_STY74 to prevent a dataset not found condition.
Thanks to Sandy Stromberg, OPTUM, USA.
Change 33.154 BY statement was missing on SGPLOT and GPLOT so title1
ANALCAPD had #BYVAL1 rather than the value of CECSER.
Jun 25, 2015
Change 33.153 IMF version 5100 record caused INPUT STATEMENT EXCEEDED
VMACCIMS ERROR due to MXG misalignment of the Trace Table that
Jun 24, 2015 caused TRNEXTEN=1 when it should have been zero.
Change 33.152 ANALWHO (WHO deleted/modified my Dataset) is revised to
ANALWHO check and see if any data was found and now confirms
Jun 24, 2015 in an MXGNOTE that observations were NOT found.
The REPORT data that is created is now deleted before
ending. JOB parameter is added to allow you to specify
a specific job name to seek.
Thanks to Dave Ireland, USDA, USA.
Change 33.151 ERROR.VMAC115.OFFQCCT. INVALID SECTION TRIPLET.
VMAC115 ERROR.VMAC116.LENQWHS. INVALID PRODUCT SECTION TRIPLET.
VMAC116 are corrected. Change 32.172 created new MQ V8.0
Jun 24, 2015 datasets MQCHIN and MQCHININ, but documented that the
Jun 30, 2015 code had not been tested with data. Now it has been.
-The MQCHIN 115 records ADP, SSL, and DSN segments are
significantly longer than documented and don't agree
with their contents in CSQDQCTA; this will be pursued
with IBM MQ Support.
-The MQCHININ 116 dataset is only output if there was
activity; that logic is in _ETY116A if you do want to
output all segments.
-Jun 30: WTASCTSR is now correctly aligned and non-zero.
Thanks to Robert Miles Standish, UBS, USA.
Thanks to Thomas Orlando, UBS, USA.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.150 Variable PCTDLZIP='ZIP*DELAY*PERCENT' is created in the
VMAC7072 TYPE72GO dataset.
Jun 22, 2015
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 33.149 Dataset TYPE115 variable QESDBFPT was not divided by
VMAC115 4096.
Jun 22, 2015
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.148 -SMFSRCH can't search for text in compressed DB2 or CICS
SMFSRCH SMF records unless the EXITCICS INFILE exit is installed
Jun 22, 2015 on z/OS.
-At present, on ASCII, SMFSRCH can not search compressed
records because the internal decompression algorithm is
executed AFTER the _INFILE_ has been populated. This is
under investigation for a possible solution.
-If SMFSRCH found type 102 records with an IFCID LT 100,
it incorrectly called UTILBLDP with a token of 102.83,
which should have been 102.083. Now fixed.
-SMFSRCH will now suppress processing of 102 records if a
subtype of 0 is found, since this means the data is
compressed, and you are not using the EXITCICS exit.
-If a subtype GE 8000 is found the subtype is then
converted to BMC.
Change 33.147 Analysis of batch queue times using SMF30HQT SMF30JQT
ANALQBAT SMF30RQT and SMF30SQT variables rather than values that
Jun 20, 2015 are calculated as in ANALINIT. This is a member which
you need to tailor in your USERID.SOURCLIB. There are
changes you must make (look for CHANGE HERE in the
member.) It requires are least SAS 9.3 since it uses
ODS and creates PDF output.
Change 33.146 There are two SECID='0B'x SMF Type=22 records. RECIND=9
EXTY22PB records create the existing TYPE22_B with the I/O Config
IMAC22 changes. New TYPE22PB dataset is created from SECID='0B'x
VMAC22 that do not have RECIND=9, with Reconfigured PCIE.
VMXGINIT function identifiers.
Jun 19, 2015
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.145 BVIR VTS Grid dataset BVIR33 was incorrect for the second
VMACBVIR and subsequent Grid-Cluster Containers.
Jun 18, 2015 Variable TMDLYCPY is now kept in BVIR33, overlooked.
Jul 7, 2015 Variables MAXAHCT AVEAHCT MAXBHCT AVEBHCT are now kept in
BVIR20.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Thanks to Mike Creech, Black Knight Financial Services, USA.
Change 33.144 Support for SMF Type 119 new Subtypes 94 and 95 create
EXT11994 dddddd dataset description
EXT11995 T11994 TYP11994 SSH Client Connect Start
FORMATS T11995 TYP11995 SSHD Server Connect Start
IMAC119 The $MG110AM/CI/MA/CO formats were updated with new
VMAC119 values.
VMXGINIT
Jun 23, 2015
Thanks to Hyrum Smith, Schwab, USA.
Change 33.143 -INPUT STATEMENT EXCEEDED NDM-CDI PT RECORD, shortened by
VMACNDM 4 bytes, variable PTUNCH34 now $EBCDIC30 vs 34.
Jun 15, 2015 -Truncated fields for CT record - MXG Message is correct,
vendor contacted.
Change 33.142 Variable QWACATWT was missing the divide by 4096 and the
VMACDB2 variable QWACPQCT should have been input &PIB.4.
Jun 15, 2015
Thanks to Scott Barry, SBBWorks Inc., USA.
====== Changes thru 33.141 were in MXG 33.06 dated Jun 11, 2015=========
Change 33.141 Documentation only. The EXITCICS/CICSIFUE INFILE exit
EXITCICS WILL NOT work with VSAM SMF input, on SAS log shown as
Jun 11, 2015 DSNAME=SYS1.MAN1,
VOLUME=Z21SMF,DISP=SHR,UNIT=3390,
TYPE=NONINDEXED,SPANNED=YES,
RECORDSIZE=(.,32767),AMP=('AMORG'),RECORDS=0
Maybe the DSNAME=SYS1.MAN1 is a clue, but it is the AMP=
parameter that identifies the SMF file as a VSAM file.
The SAS log also reported:
MXGNOTE: SMF EXIT CICS IS IN USE.
ERROR: ERROR DETECTED BY INFILE/FILE EXIT: .
FATAL: UNRECOVERABLE I/O ERROR DETECTED IN THE
EXECUTION OF THE DATA STEP PROGRAM.
Thanks to Greg Meyer, ISUZU, USA.
Change 33.140 RMF III RCD records INCOMPATIBLY changed for z13 causing
VMACRMFV invalid values in SVCLCNM and other variables in RBRCDR.
Jun 11, 2015 The change apparently was RMF APAR OA44101 supporting
Jun 16, 2015 Simultaneous MultiThreading (SMT) on the IBM z13 server
that extended the Resource Collection Data Period Data
(RCDPD) array entries in the RMF Monitor III RCD table.
-Test IF RCDPLSC GE 0 corrected to IF RCDPLSC GT 0. When
RCDPLSC=0, there is no LC Service Class Extension. Have
NOT ACTUALLY seen RCDPLSC=0, so this is for safety and
not an actual error.
Thanks to Michael Kampert, Schwab, USA.
Change 33.139 Contributed Processor Topology Report for z13, using SMF
ANAL9914 Type 99 Subtype 14 records. Syntax for SYS1 report, Z13:
Jun 9, 2015 %ANAL9914(SYSTEM=SYS1,SYSTYPE=Z13)
Thanks to Raymond J. Smith, OPTUM, USA.
Change 33.138 -z13 in SMT Mode, TYPE70EN had missing or mis-aligned
VMAC7072 values when there was a second zIIP engine.
Jun 9, 2015 -z13 in SMT Mode, PCTMVSBY was incorrect by a few percent
Jun 11, 2015 because LPARBUSY time was incorrectly subtracted.
-z13 in SMT Mode zIIP variables in TYPE70xx datasets,
could be missing, or DUPLICATE RECORD message could be
printed. REQUIRED FOR SMT. The MXG SMT support has come
in several iterations as new sequences of data exposed
untested logic but this appears to finally resolve the
one-to-many merge. If you are testing SMT on z13, please
email MXG Support with subject: SMT UPDATES so we can
inform you if there are any further required changes for
SMT mode.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Thanks to Scott Wiig, US Bank, USA.
Thanks to Douglas C. Walter, CitiCorp, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 33.137 Support for Compuware ABEND-AID USER SMF Record creates
FORMATS new ABENDAID dataset with many details on each intercept.
EXABNAID
IMACAA
TYPEAA
TYPSAA
VMACAA
VMXGINIT
Jun 5, 2015
Change 33.136 Support for MainView for IMS 5.2 (a/k/a IMF, CONTROL/IMS)
FORMATS for COMPATIBLE changes.
VMACCIMS -New variables added to CIMSTRAN:
Jun 3, 2015 TRNDLCMX='MAX*DC*CALL*TIME'
TRNDLDMX='MAX*DB*CALL*TIME'
TRNESSMX='MAX*ESS*CALL*TIME'
TRNDLWMX='MAX*WAIT*NOT-IO*TIME'
TRNDLDTH='DLI DB*OR*ESS CALLS*GE THRESHOLD'
TRNDLCTH='DLI*DC* GE*THRESHOLD'
TRNDLDER='DLI*CALL*ERRORS'
TRNESSER='ESS*CALL*ERRORS'
TRN1STCP='SCHD*FIRST*DLI*CPU'
-New values added to variables SMQFLAG, PROGTYPE
FLGSPCHR.
Change 33.135 Support for Optional CICS User CMODNAME=VMX CMODHEAD=VMX
IMACICVP segments.
IMACICVQ
IMACICVR
IMACICVT
IMACICVU
IMACAAAA
UTILEXCL
VMAC110
Jun 9, 2015
Change 33.134 -ANALDB2R mis-reported the number of reports produced
ANALDB2R when accounting reports were requested but no data met
READDB2 the selection criteria.
May 26, 2015 -READDB2 applied selection criteria inappropriately to
the 105 106 and 107 IFCIDS which are subsystem specific.
-ANALID parameter added to ANALDB2R to pass to READDB2 so
that you can see what records were in the input data.
-Page headings on PMSPR01 were incorrect for the first
page of the second and subsequent DB2 subsystems reports.
-If the input to PMLOL02 and PMLOK03 was a SAS dataset on
tape, the T102S172 dataset was missing from the PROC COPY
that moves the data to DASD (zOS only) since there must
be concurrent dataset open for these reports
Thanks to Judy Xu, WiPro, USA.
Change 33.133 ZOSEM User SMF INPUT STATEMENT EXCEEDED because MXG had
VMACOSEM expected an 8-byte Resource field length. Since this
May 21, 2015 resource looks like it might be a DSNAME, the resource
array variables are expanded to 44 bytes.
Thanks to John Schoenbeck, IBM Global Services, USA.
Change 33.132 These eight new TYPE30 variables with zEDC metrics were
VMAC30 misaligned because the triplet was incorrectly input:
May 21, 2015 SMF30_US_COMPRREQ SMF30_US_COMPRREQ_PROB
Jan 4, 2016 SMF30_US_QUEUETIME SMF30_US_EXECTIME
SMF30_US_DEF_UNCOMPRIN SMF30_US_DEF_COMPROUT
SMF30_US_INF_COMPRIN SMF30_US_INF_DECOMPROUT
These variables now also have "ZEDC" in their label.
-Jan 2016: APAR OA48268 corrects invalid values in the
first four variables above, especially when SMF data
is from logstream processed by IFASMFDL.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 33.131 -SMFSRCH failed if the SMF file contained only one USER
SMFSRCH record type and you had specified that nnn type value in
UTILBLDP your USERADD=XXXX/nnn argument. The USERADD= erroneously
May 22, 2015 had nnn which generated a call to INCLUDE VMACnnn.
May 25, 2015 -SMFSRCH now invokes %ANALID report to tabulate the SMF
records, subtypes, versions, etc., that were selected;
any undefined user records selected are identified.
-SMFSRCH LOOKFOR= supports multiple strings with ANDOR
choice, and new SELECTION= argument lets you write your
own IF statement for the selection.
-UTILBLDP needed revision to delete the ID VIEW that was
introduced with the addition of %ANALID. If ID is found
in a non-BUILDPDB context the _SID sort is suppressed and
the ID VIEW is deleted.
-ASCII only, SMFSRCH. LENGTH from INFILE statement is now
used in place of LENGTH=LENGTH(_INFILE_) for the written
length, after an SMF 79 record with a blank last byte was
truncated, and detected by an MXG ERROR message, causing
the SAS documentation TO BE READ, that stated that the
LENGTH() function returns the length of the string, but
EXCLUDING any trailing blanks.
Thanks to Mike Obrien, Bank of America, USA.
Change 33.130 Missing values in SMF70xxx variables in PDB.ASUM1131 and
ASUM113 (now archaic PDB.ASUM113 from no longer supported subtype
May 20, 2015 2 Type 113s) if the SMF SYSTEM variable in Type 70 does
not match SMF70STN in the PR/SM LCPUADDR segments. This
logic has been used since always to read from TYPE70PR
IF SYSTEM=SMF70STN;
SYSTEM=SYSNAME; (IBM SMF70SNM - From IEASYSXX)
to use the SYSNAME for the merge with TYPE113.
In this new data with SYSTEM NOT matching SMF70STN, it
was observed that SMF70STN matched SYSNAME, but now, the
original SYSTEM is unchanged:
IF SYSTEM=SMF70STN OR SYSNAME=SMF70STN;
IF SYSTEM=SMF70STN THEN SYSTEM=SYSNAME;
/* ELSE LEAVE THE SMF 70 ORIGINAL SYSTEM FOR MATCH */
-Do not use Subtype 2 SMF 113 with accumulated data; they
may not always match up with 70PR because 113 data is
lost. Always use Subtype 1 INTERVAL HIS data. IBM has
stated they will NOT update Subtype 2 records.
Thanks to Virginie Peigney, CA-SILCA, FRANCE.
Change 33.129 Support for TMS new TRTCH values for Device Type TS1140,
VMACTMS5 EE4/EE4M/EE4X and EF4/EF4M/EF4X.
May 20, 2015
Thanks to Scott Barry, SBBWorks, Inc., USA.
====== Changes thru 33.128 were in MXG 33.05 dated May 19, 2015=========
Change 33.128 z13 with one or more LPARs enabled for SMT-mode will have
VMAC7072 zero observations in the TYPE70 dataset from all NON-SMT
May 19, 2015 mode systems, UNLESS, ACCIDENTALLY, the SMT-mode systems
are all at the end of your input SMF file. The SMTSEGNR
variable that identifies this is an SMT-mode record was
incorrectly retained.
Thanks to Scott Wiig, US Bank, USA.
Change 33.127 Dataset TYPE749 zEDC PCIE and Hardware Accelerator FIXED.
VMAC74 Change 33.124 replaced with logic to match all segments.
May 18, 2015 This change is required for valid TYPE749 data.
May 22, 2015 May 22: STD and AVG variables created for Queue/Execute
durations, which are now formatted TIME16.6.
Thanks to David Cogar, Wells Fargo, USA.
Thanks to Carl D. Ellis, Wells Fargo, USA.
Change 33.126 APPTUNE SMF 102 INPUT STATEMENT EXCEEDED if DATA SHARING
VMACDB2H (32) header is present. The product section for APPTUNE
May 19, 2015 records is not at the end of the SMF 102 but instead is
at the beginning of the record. Change 32.148 revised the
header input logic, to support unexpected out-of-order
headers, but the LENLEFT calculations used record LENGTH.
Now for APPTUNE 102s (QWHSIID GE 8000x), the ENDPROD is
used to determine the LENLEFT for all header segments.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 33.125 Further SMT-related changes.
VMAC7072 -CPUWAITM now subtracts LPARBUSY from CPUWAITM for zIIPs.
May 16, 2015 earlier code had the subtraction for CPs, with no impact.
-SMF70CAN/SMF70CTN variables are again kept in TYPE70PR.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
====== Changes thru 33.124 were in MXG 33.05 dated May 12, 2015=========
Change 33.124 MXG support for 74-9 zEDC was revised again, when it was
VMAC74 discovered that only the first card was output, and that
May 13, 2015 the number of PCIE pairings of the PO/DO segments is not
May 18, 2015 the same as the number of Hardware Accelerator FO/10
segments. Original change text here removed, See 33.127.
-Variable R749LAID was removed; there is no adapter id.
-These new variables were added from the DO segments
R749DBYR R749DBYT R749DFMT R749DPKR R749DPKT
R749DWUP R749DWUM
-May 18: See Change 33.127, which is REQUIRED.
Thanks to David Cogar, Wells Fargo, USA.
Thanks to Scott Barry, SBBWorks, Inc., USA.
====== Changes thru 33.123 were in MXG 33.05 dated May 12, 2015=========
Change 33.123 Support for Tandem ZMS Style of records; the previous MXG
VMACTANZ support was for what are now "Legacy Style" records.
May 12, 2015
Thanks to Mark Goforth, First National of Nebraska, USA.
Change 33.122 Reserved Change.
Change 33.121 z13 SMT-mode TYPE70/PR data IS WRONG in MXG 33.03-33.04.
VMAC7072 In ONLY RMF 70 records written in SMT-mode, the datasets
May 12, 2015 TYPE70, TYPE70PR, RMFINTRV, ASUM70PR, ASUM70LP, ASUMCEC,
and ASUM70PR can have incorrect values. MXG 33.03 support
for z13 SMT-mode records continued to use LCPUADDR from
the PHYSICAL to merge with CPUID in the CPUD segment and
the results matched initial RMF reports, but now I find
that the LCPUADDR won't always match the CPUID value!
And, one mismatch destroys the merge, trashing both the
TYPE70 and TYPE70PR datasets.
The code had to be redesigned to sort and merge on the
physical sequence to pair up the two segments to create
the per-LCPUADDR TYPE70PR dataset and populate TYPE70.
IBM RMF Support confirmed that "LCPUADDR/SMF70VPA in the
PHYSICAL segment is retrieved from the Diag 204 interface
and is generated by the hardware/firmware when the core
is brought into the configuration. It does not match the
logical core id in SMF70VPA which is provided by z/OS in
the PR/SM logical processor data section(s) of the home
partition"
The example had an LCPUADDR=7 in PHYSICAL for a zIIP, but
there was no corresponding CPUID=7 in the CPUD segment.
I was also confused when a box with 5 CP cores and 5 zIIP
cores in PHYSICAL had SIX unique CORE_IDs, but that was
because the home partition had 4 logical CP cores and 2
logical zIIP cores, which results in the 8 CPU data
sections, with 6 unique CORE_IDs.
Change 33.120 New member IHDR120 for the SMF TYPE=120 WebSphere record
IHDR120 in %INCLUDEd after the header and Product segments have
VMAC120 been INPUT, and the "instream" macro variable MAC120H is
VMXGINIT defined so that you can select/tailor after those header
May 6, 2015 variables have been input.
Change 33.119 The optional IMACICMX member for Omegamon with CMRDATA of
IMACICMX length 384 was missing a final END; statement, causing a
May 6, 2015 syntax error if UTILEXCL told you to tailor IMACICMX.
Change 33.118 -The RESULTS window now lists the report number and short
SAGANAL title for all reports produced by PROCs that support the
May 7, 2015 CONTENTS= option to label the result. (Procs FREQ, MEANS,
and CONTENTS do not support that feature.)
-Report 31 added with top ten MSU hours for CICS DFHSIP.
-Number of variables kept reduced to 68 from 1533; syntax
CPU: and CPI: for TYPE30 kept TYPE70PR CPU: variables.
Change 33.117 -MXG 33.04. SMFSRCH found no records if USERADDS= was not
SMFSRCH specified. Logic added for USERADDS=NOUSERID was wrong.
UTILBLDP Logic corrected, but USERADDS=XXXX/nnnn (even if _IDXXXX
May 6, 2015 is already defined in IMACKEEP) will circumvent.
-It was also possible to skip all user record selection
due to an ENDOFFILE test that is removed.
-The TYPE30_D dataset (each DD in SMF 30) is not populated
by MXG default, and although the only text is the DDNAME,
since SMFSRCH is to find and print all SMF records found,
new TY30UD argument is defined in UTILBLDP (default is
blank), and TY30UD=YES default is set in SMFSRCH, so that
dataset TYPE30_D will be populated if type 30 records are
selected, or you can use TY30UD=NO in your SMFSRCH call
to prevent any observations to be created in TYPE30_D.
-ECHO=YES specified in SMFSRCH to always print the MXG
created by UTILBLDP on the log.
-In testing, an exposure was observed: multiple uses of
the file INSTREAM caused text to be overridden, which did
not cause an error, but some sites have made INSTREAM to
be a permanent dataset, and this exposure could lead to
errors for those sites.
The //INSTREAM DD was intended to be temporary and used
internally as the destination for writing SAS code that
is then executed with %INCLUDE INSTREAM. These members
no longer use INSTREAM; instead, each writes/reads from
FILENAME TMXGxxxx CATALOG 'WORK.MXGTEMP.TMXGxxxx.LOG';
in the WORK file so no DD is required, and no conflict!
A few members (notably UTILBLDP) do externalize INSTREAM,
and they were not changed.
ANALCOMP VMXGPRAL VMXGPRNT QAWPS8 QA94648 SAGANAL
PRINTLOG ONLYJOBS ASUMMSUS ANALRRTM ANALPGM ANALCOMP
Thanks to MP Welch, Bank of America, USA.
Change 33.116 Support for ZCOST AutoSoftCapping Version V3.0.00 adds
EXZCO02S subtypes and data. These are the datasets MXG creates:
EXZCO02W DDDDDD Dataset Description
EXZCO04C ZCO01 ZCOS01 ZCOST CPC
EXZCO04G ZCO02 ZCOS02 ZCOST LPAR
EXZCO04L ZCO02S ZCOS02S ZCOST SERVICE CLASS PERIOD
EXZCO04P ZCO02W ZCOS02W ZCOST WLM INPORTANCE
EXZCO04R ZCO03 ZCOS03 ZCOST SYSPLEX/CPC
VMACZCOS ZCO04G ZCOS04GP ZCOST GENERAL PARMS
VMXGINIT ZCO04C ZCOS04CP ZCOST CPC PARMS
May 5, 2015 ZCO04L ZCOS04LP ZCOST LPAR PARMS
May 28, 2015 ZCO04P ZCOS04PG ZCOST GENERAL PERIOD PARMS
ZCO04R ZCOS04PL ZCOST LPAR PERIOD PARMS
This support was completed in MXG 33.06.
Change 33.115 Mainview for MQ BBMQBUFF dataset EFFICIENCY variables are
VMACBBMQ now correctly input as RB4 instead of PIB. Variables are
Apr 29, 2015 SBPIAWPE SPBRAWPE SBPSAWPE.
Change 33.114 BMC IMF/CIMS variable CPUZIPTM was not KEPT in CIMSTRAN;
VMACCIMS it was incorrectly in the CIMSDBDS dataset KEEP=list.
Apr 29, 2015 "zAAP" in Label changed to 'ZIP' (Feb 2006):
CPUZIPTM='CPU TIME*ON ZIP*ENGINES'
TRXZAOCP='CPU TIME*ZIP ELIGIBLE*RAN ON CP'
Thanks to Betty Wong, Bank of America, USA.
Change 33.113 Some T102S106 variables (DB2 zPARM flags and values) were
FORMATS misaligned, not INPUT, or had wrong/no decoding format.
VMAC102 Align: QWP2DMIN,QWP2DSEC
Apr 30, 2015 Format: Use $MGD361U for QWP4SECA1_TYPE, QWP4SECA2_TYPE
Format: New $MGD106P for QWPBDL, QWPBSDL
Input: QWP4S1IL for DB2 V10, was only V11 and wrong.
Thanks to Lai Fai, Bank of America, USA.
====== Changes thru 33.112 were in MXG 33.04 dated Apr 29, 2015=========
Change 33.112 -Support for CICS/TS 5.3 OPEN BETA (INCOMPATIBLE) AND:
UTILEXCL NOTE THAT 5.3 now sets STGPROT=YES as the IBM DEFAULT, to
VMAC110 INTENTIONALLY cause an ABEND for storage overlays caused
Apr 29, 2015 by dubious programming techniques where a task has
May 1, 2015 modified storage owned by another task. These ABENDs
will need application programmer design changes; the APP
should have been fixed long ago - IBM is looking forward!
-New variables (INCOMPATIBLE) inserted in CICSTRAN dataset
NCGETCN ='NAMED*COUNTER*SERVER*REQUESTS'
TSGETSCN='SHARED*TEMP*STORAGE*GETS'
TSPUTSCN='SHARED*TEMP*STORAGE*PUTS'
May 1: Original Note wrong here, NO ERROR in TSTOTCN.
-New variables inserted in CICSRDQU dataset (MNSEGCL=5):
TSQGESTM='SHARED*TSQUEUE*GET*TIME'
TSQGESCN='SHARED*TSQUEUE*GET*COUNT'
TSQPUSTM='SHARED*TSQUEUE*PUT*TIME'
TSQPUSCN='SHARED*TSQUEUE*PUT*COUNT'
TSQGESBY='SHARED*TSQUEUE*GET*BYTES'
TSQPUSBY='SHARED*TSQUEUE*PUT*BYTES'
-"WRITING OF PERFORMANCE DATA IS MORE EFFICIENT WHEN
FIELDS ARE NOT EXCLUDED." was noted in a comment.
Change 33.111 -The ANALID report that tabulates SMF record types is
ANALID enhanced to optionally invoke %UTILBLDP to create MXG
SMFSRCH code to build all possible MXG datasets from ALL records
UTILBLDP in the input SMF file, and to optionally run the program,
VMXGPRAL -This change originally documented macro variables UTILBLD
VMXGINIT VMXGPRA but they were removed in Change 33.117, unused.
Apr 27, 2015 -VMXGPRAL revised to print the LIB.DSNAME + LABEL without
May 27, 2015. extra blanks and periods.
Thanks to MP Welch, Bank of America, USA.
Change 33.110 -Support for TS7700 HYDRA Version 3.2A (COMPATIBLE)
EXBVR302 creates new BVIR302 dataset with the Extended HSM Cache
FORMATS Partition Container Statistics from subtype 30 record.
IMACBVIR -Variables added to BVIR01 dataset:
VMACBVIR THRUPUT AHEADCNT BEHNDCNT
VMXGINIT -Changed records have BVIRVERS=6.
Apr 24, 2015
Thanks to Tim Campbell, TELUS, CANADA.
Change 33.109 -Support for TYPE 23 zEDC variables SMF23BBC/SMF23BAC has
VMAC23 been corrected and validated. Those two variables plus
Apr 23, 2015 SMF23PFT SMF23PFM SMF23PFH SMF23CWN SMF23NCN are now
correctly aligned and are now output in dataset TYPE23LS
and removed from dataset TYPE23.
-Two new fields were documented in the z/OS 2.1 SMF Manual
but IBM has confirmed they only exist in z/OS 2.2:
SMF23BBC='ZEDC*UNCOMPRESSEDSED*BYTES*TOTAL'
SMF23BAC='ZEDC*COMPRESSED*BYTES*TOTAL'
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 33.108 Support for APARs OA45944 and OA45897 which adds new data
VMAC42 for contention counts for record locks, component1 and
Apr 23, 2015 component2 locks:
-New variables in dataset TYPE42S1:
SMF42FUA ='ACCUMULATION*WAITERS FOR*RECORD LOCK'
SMF42FUB ='RECORD LOCKS*HASHED TO*SAME ENTRY(/
SMF42FUD ='ACCUMULATION*WAITERS*FOR DIWA*LOCK'
SMF42FUE ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMF42FUF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42FUG ='LOCKS*HASHED TO*SAME*ENTRY'
-New variables in dataset TYPE42S2:
SMF42FVA ='ACCUMLATION*WAITERS*FOR RECORD*LOCK'
SMF42FVB ='RECORD LOCKS*HASHED TO*SAME ENTRY'
SMF42FVD ='ACCUMULATION*WAITERS*FOR DIWA*LOCK'
SMF42FVE ='ACCUMULATION*WAITERS*FOR UPGRADELOCK'
SMF42FVF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42FVG ='LOCKS*HASHED TO*SAME*ENTRY'
-New variables in dataset TYPE42S3:
SMFA2FUA ='ACCUMULTION*WAITERS*FOR RECORD*LOCK'
SMFA2FUB ='LOCKS*HASHED*TO SAME*ENTRY'
SMFA2FOD ='ACCUMULTION*WAITERS*FOR DIWA*LOCK'
SMFA2FOE ='ACCUMULTION*WAITERS*FOR UPGRADE*LOCK'
SMFA2FOF ='ACCUMULTION*WAITERS*FOR COMP2*LOCK'
SMFA2FOG ='LOCKS*HASHED*TO SAME*ENTRY'
-New variables in dataset TYPE42S4:
SMFA2FVA ='ACCUMULATION*WAITERS*FOR RECORD*LOCK'
SMFA2FVB ='LOCKS*HASHED*TO SAME*ENTRY'
SMFA2FVD ='ACCUMULATION*WAITERS*FOR DIWA*LOCK'
SMFA2FVE ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMFA2FVF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMFA2FVG ='LOCKS*HASHED*TO SAME*ENTRY'
-New variables in dataset TYPE42D1:
SMF42GUA ='ACCUMULATION*WAITERS*FOR RECORD*LOCK'
SMF42GUB ='LOCKS*HASHED*TO SAME*ENTRY'
SMF42GUD ='ACCUMULATION*WAITERS*FOR DIWA*LOCK'
SMF42GUE ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMF42GUF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42GUG ='LOCKS*HASHED*TO SAME*ENTRY'
-New variables in dataset TYPE42D2:
SMF42GVA ='ACCUMULATION*WAITERS*FOR RECORD*LOCK'
SMF42GVB ='LOCKS*HASHED*TO SAME*ENTRY'
SMF42GVD ='ACCUMULATION*WAITERS*FOR DIWA*LOCK'
SMF42GVE ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMF42GVF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42GVG ='LOCKS*HASHED*TO SAME*ENTRY'
-New variables in dataset TYPE42D3:
SMF42GUA ='ACCUMULATION*WAITERS*FOR RECORD*LOCK'
SMF42GUB ='LOCKS*HASHED*TO SAME*ENTRY'
SMF42GUD ='ACCUMULATION*WAITERS*FOR DIWA*LOCK'
SMF42GUE ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMF42GUF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42GUG ='LOCKS*HASHED*TO SAME*ENTRY'
-New variables in dataset TYPE42D4:
SMF42GVA ='ACCUMULATION*WAITERS*FOR RECORD*LOCK'
SMF42GVB ='LOCKS*HASHED*TO SAME*ENTRY'
SMF42GVD ='ACCUMULATION*WAITERS*FOR DIWA*LOCK'
SMF42GVE ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMF42GVF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42GVG ='LOCKS*HASHED*TO SAME*ENTRY'
-New variables in dataset TYPE42L1:
SMF42HUA ='ACCUMULATION*WAITERS*FOR RECORD*LOCK'
SMF42HUB ='LOCKS*HASHED*TO SAME*ENTRY'
SMF42HUD ='ACCUMULATION*WAITERS*FOR DIWA2*LOCK'
SMF42HUE ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMF42HUF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42HUG ='LOCKS*HASHED*TO SAME*ENTRY'
-New variables in dataset TYPE42L2:
SMF42HVA ='ACCUMULATION*WAITERS*FOR RECORD*LOCK'
SMF42HVB ='LOCKS*HASHED*TO SAME*ENTRY'
SMF42HVC ='ACCUMULATION*WAITERS*FOR DIWA2*LOCK'
SMF42HVD ='ACCUMULATION*WAITERS*FOR UPGRADE*LOCK'
SMF42HVF ='ACCUMULATION*WAITERS*FOR COMP2*LOCK'
SMF42HVG ='LOCKS*HASHED*TO SAME*ENTRY'
Change 33.107 -DB2PM-like reports PMACC02/4 class 3 delay section was
ANALDB2R missing TCP/IP LOB and the global contention corrected
Apr 26, 2015 from only parent locks to include all contention delays.
-In PMAUD02 there were uninitialized variables corrected.
-The z/OS external sort can not be used if the length of
an observation is greater than 32760 bytes, and many of
the DB2 102 records contain 32K SQL Text variables.
For the AUDIT reports, the SQL text is reduced to 80
bytes, since that is all IBM's DB2PM reports, and the
full text is still in the T102Snnn dataset.
-If you asked for AUTHCHG in the AUDIT= parameter and
there were any IFCID 83 records the selection criteria
were not applied and that caused missing timestamps in
the report headers.
-If there were 0 OBS in the IFCID 142 dataset then a
a work file was not cleaned up.
Thanks to Neil Ervin, Wells Fargo, USA
Change 33.106 New variable EXCMTYPE in CICSEXCE (Exception) dataset
FORMATS is created to describe the exception event:
VMAC110 1='DATABASE REQUEST POLICY RULE'
Apr 22, 2015 2='FILE REQUEST'
3='PROGRAM REQUEST'
4='START REQUEST'
5='STORAGE REQUEST'
6='SYNCPOINT REQUEST'
7='TD QUEUE REQUEST'
8='TIME REQUEST'
9='TS QUEUE REQUEST'
10='WAIT FOR CF LOCKING REQUEST'
11='WAIT FOR CF NON-LOCKING REQUEST'
12='WAIT FOR UDSA'
13='WAIT FOR EUDSA'
14='WAIT FOR CDSA'
15='WAIT FOR ECDSA'
16='WAIT FOR SDSA'
17='WAIT FOR ESDSA'
18='WAIT FOR RDSA'
19='WAIT FOR ERDSA'
20='WAIT FOR GCDSA'
21='WAIT FOR GUDSA'
22='WAIT FOR GSDSA'
23='WAIT FOR TEMPORARY STORAGE'
24='WAIT FOR STRING FOR FILE'
25='WAIT FOR STRING FOR LSRPOOL'
26='WAIT FOR STRING FOR DFHTEMP'
27='WAIT FOR BUFFER FOR LSRPOOL'
28='WAIT FOR BUFFER*FOR DFHTEMP'
Thanks to Bahman Nejad, Union Bank, USA.
Thanks to Perry Lim, Union Bank, USA.
Change 33.105 Using PROC CPORT to copy z/OS data libraries to ASCII can
IMACFMTS corrupt values in character variables with $HEX format if
UTILCVRT those variables did not have the TRANSCODE=NO attribute
Apr 21, 2015 set, or they were built with an ancient SAS version prior
to that attribute. If you have downloaded PDBs and see
$HEX variables are wrong (check CPUTYPE in TYPE70), the
UTILCVRT program can be used to convert those $HEX vars
back to their correct values. Maybe. The default mapping
table is the $MGAS2EB format in FORMATS, using a table
created in 2009 for PROC CPORT translation, replacing an
earlier table created from IND$FILE. However, now using
the CPORT table under both Windows and Linux does NOT map
characters correctly; the alternative $MGAS2EB table from
IND$FILE must be used. That alternative format is defined
in Example 2 in a comment block in the IMACFMTS member.
Copy IMACFMTS to your USERID.SOURCLIB, remove the comment
block in Example 2, and run the FORMATS step of JCLINSTL
(%INCLUDE SOURCLIB(FORMATS); with DISP=OLD on //LIBRARY)
and the alternative table values will be used.
Thanks to Warren Cravey, Fidelity, USA.
Thanks to Rachel Holt, Fidelity, USA.
Change 33.104 NMON CPU records can now contain three digits, CPU001, so
VMACNMON the logic to create CPUNR now decodes two or three digits
Apr 21, 2015 for CPUnnn, PCPUnnn and SCPUnnn.
Thanks to Raissa Moussu, METROLOGFIE AIX EN PROVENCE, FRANCE.
Change 33.103 VMXGPRAL (PRINT/MEAN/FREQ ALL datasets &ALL variables in
VMXGPRAL a "PDB" data library, with both Label and Variable Name)
Apr 15, 2015 enhanced for FREQ with TABLE= option to choose what
variables are tabulated. TABLES=_CHAR_, will only show
the character variables. Without the TABLES= argument,
all variables will be tabulated.
Thanks to MP Welch, Bank of America, USA.
Change 33.102A Support for SYNCSORT Release 2.1 (INCOMPATIBLE, test for
VMACSYNC SYNCLVL for ancient Release 3.7 conflicted) causing many
Apr 15, 2015 variables to be missing values with no error message,
notably, CPUZIPTM is a missing value without this change.
Thanks to Roger Foreman, Transunion, USA.
Change 33.102 DB2 V10 INVALID DATA FOR QLACCPUR and QLACDBAT when field
VMACDB2 QLACLOCN was relocated because it's longer than 8 bytes,
Apr 14, 2015 but the length of the relocated field in XLENLOCN is NOT
in LENLOCN causing misalignment when XLENLOCN GT 20.
Thanks to Betty Wong, Bank of America, USA.
Change 33.101 Support for iSeries 7.2 (COMPATIBLE with new LRECLS).
VMACQACS Comments in VMACQACL list LRECLs and 7.2 records tested.
Apr 13, 2015 -New variables in QAPMDISK:
DSLVLMP ='LEVEL OF*MIRRORED*PROTECTION'
DSLSCNDS='LOG*SENSE*COMMANDS*ISSUED'
DSLSRT ='LOG*SENSE*RESPONSE*TIME'
-New variables in QAPMJOBM (QAPMJOBMI):
JBTNAME ='THREAD*NAME'
JBSLTCNT ='SHORT*LIFESPAN*ENTRY*COUNT'
JBSACPU ='ACCUMULATED*JOB*SCALED*CPU TIME'
JBINDCPU ='THREAD*UNSCALED*CPU TIME*USED'
JBSINDCPU ='THREAD*SCALED*CPU TIME*USED'
JBCPUWC ='PROCESSOR*ELAPSED*TIME'
JBVPDLY ='VIRTUAL*PROCESSOR*DELAY*TIME'
JBSEIZECNT ='SIEZE*COUNT'
JBPSLCKCNT ='PROCESS*SCOPED*LOCK*COUNT'
JBTSLCKCNT ='THREAD*SCOPED*LOCK*COUNT'
JBPSRCDLCK ='PROCESS*SCOPED*DATABASE*LOCK*COUNT'
JBTSRCDLCK ='THREAD*SCOPED*DATABASE*LOCK*COUNT'
JBNFOGDT ='OFF-GROUP*DISPATCH*TIME'
JBNFOGMA ='OFF-GROUP*PAGE*FRAMES'
JBPGEZSTL ='PAGES*MARKED*EASY TO*STEAL'
JBSQLCLK ='SQL*CLOCK*TIME'
JBSQLCPU ='THREAD*UNSCALED*SQL*TIME'
JBSQSCPU ='THREAD*SCALED*SQL*CPU TIME'
JBSQLDBR ='SQL*SYNCHRONOUS*DATABASE*READS'
JBSQLNDBR ='SQL*SYNCHRONOUS*NONDATABASE*READS'
JBSQLDBW ='SQL*SYNCHRONOUS*DATABASE*READS'
JBSQLNDBW ='SQL*SYNCHRONOUS*NONDATABASE*READS'
JBSQLADBR ='SQL*ASYNCHRONOUS*DATABASE*READS'
JBSQLANDBR ='SQL*ASYNCHRONOUS*NONDATABASE*READS'
JBSQLADBW ='SQL*ASYNCHRONOUS*DATABASE*WRITES'
JBSQLANDBW ='SQL*ASYNCHRONOUS*NONDATABASE*WRITES'
JBAGCRT ='ACTIVATION*GROUPS*CREATED'
JBPGMSACT ='PROGRAM*ACTIVATIONS*CREATED'
JBCURTMP ='CURRENT*TEMPORARY*STORAGE'
JBPEAKTMP ='PEAK*TEMPORARY*STORAGE'
JBMAXTMP ='MAXIMUM*TEMPORARY*STORAGE'
JBTMPPGA ='4K UNITS*ALLOC*TEMPORARY*STORAGE'
JBTMPPGD ='4K UNITS*DEALLOC*TEMPORARY*STORAGE'
JBHSQLSTMT ='HIGH*LEVEL*SQL*STATEMENTS'
JBTICC ='THREAD*INSTRUCTION*COUNT*CHARGED'
JBTICU ='THREAD*INSTRUCTION*COUNT*USED'
JBTTMBU ='THREAD*VIRTUAL*TIME'
JBPICC ='PROCESS*HDW INSTR*COUNT*CHARGED'
JBPRRSCPTY ='PROCESSOR*RESOURCE*PRIORITY'
-New variables in QAPMJOBO (QAPMJOBOS):
JBFSOPN 'FILE*SYSTEM*OPENS''
JBFSDC 'FILE*SYSTEM*DIRECTORY*CREATES'
JBFSNDC 'FILE*SYSTEM*NON-DIRECTORY*CREATES*
JBFSDD 'FILE*SYSTEM*DIRECTORY*DELETES'
JBFSNDD 'FILE*SYSTEM*NON-DIRECTORY*DELETES*
JBSPLFC 'SPOOLED*FILES*CREATED*BY THIS JOB*
JBSBMJOBS'JOBS*SUBMITTED*OR SPAWNED.'
JBSQLSTMT'SQL*STATEMENTS'
JBLWTSQL 'SQL*RELATED*DATABASE*WRITES*(LOGIC
JBLRDSQL 'SQL*RELATED*DATABASE*READS*(LOGICA
JBDBUSQL 'SQL*RELATED*DATABASE*MISCELLANEOUS
JBPASCMP 'SQL*PAS*COMPRESSIONS*ALL THREADS'
JBPKGCMP 'SQLPKG*COMPRESSIONS'
JBCTHD 'CONNECTED*THREAD*IDENTIFIER'
JBCJNAM 'CONNECTED*JOB*NAME'
JBCJUSR 'CONNECTED*JOB*USER'
JBCJNBR 'CONNECTED*JOB*NUMBER'
-New variables in QAPMPOLB (QAPMPOOLB):
POPGS4 ='POOL*4K*PAGES'
POPGS64 ='POOL*64K*PAGES'
PODBF4 ='POOL*DATABASE*4K*PAGE*FAULTS'
PODBF64 ='POOL*DATABASE*64K*PAGE*FAULTS'
PONDBF4 ='POOL*NONDATABASE*4K*PAGE*FAULTS'
PONDBF64 ='POOL*NONDATABASE*64K*PAGE*FAULTS'
PODBPG4 ='POOL*DATABASE*4K*PAGES*READ'
PODBPG64 ='POOL*DATABASE*64K*PAGES*READ'
PONDPG4 ='POOL*NONDATABASE*4K*PAGES*READ'
PONDPG64 ='POOL*NONDATABASE*64K*PAGES*READ'
POUNAL4 ='UNALLOCATED*4K*PAGES'
POUNAL64 ='UNALLOCATED*64K*PAGES'
POAGED4 ='POOL*4K*PAGES*AGED/
POAGED64 ='POOL*64K*PAGES*AGED'
POSTLN4 ='POOL*4K*PAGES*STOLEN'
POSTLN64 ='POOL*64K*PAGES*STOLEN'
POUNUSE4 ='POOL*4K*PAGES*UNUSED'
POUNUSE64 ='POOL*64K*PAGES*UNUSED'
POSYNC4 ='POOL*4K*PAGE*SYNC I/O'
POSYNC64 ='POOL*64K*PAGE*SYNC I/O'
POASYNC4 ='POOL*4K*PAGE*ASYNC I/O'
POASYNC64 ='POOL*64K*PAGE*ASYNC I/O'
POPGOUT4 ='POOL*4K*PAGE*OUTS'
POPGOUT64 ='POOL*64K*PAGE*OUTS'
POPGABLE4 ='POOL*4K*PAGES*PAGEABLE'
POPGABLE64='POOL*64K*PAGES*PAGEABLE'
POATMPT4 ='POOL*4K*ALLOCATION*ATTEMPTS
POATMPT64 ='POOL*64K*ALLOCATION*ATTEMPTS
POAPS4 ='POOL*4K*AFFINITY*SUCCESSES
POAPS64 ='POOL*64K*AFFINITY*SUCCESSES
POAPMIG4 ='POOL*4K*AFFINITY*MISSES
POAPMIG64 ='POOL*64K*AFFINITY*MISSES
POAPMOG4 ='POOL*4K*AFFINITY*MISSES*OFFGROUP'
POAPMOG64 ='POOL*64K*AFFINITY*MISSES*OFFGROUP'
POCRTPG64 ='POOL*4K*PAGES*CREATED'
POBRKPG64 ='POOL*64K*PAGES*BROKEN*UP'
POPOSIZB ='POOL*SIZE*KB'
POUNALB ='UNALLOCATED*POOL*SPACE*KB'
-New variables in QAPMSYST (QAPMSYSTEM):
SYVPID ='VIRTUAL*SHARED*POOL ID'
SYVPCAP ='VIRTUAL*SHARED POOL*ENTITLED*CAPACITY'
SYPPLU ='PHYSICAL*SHARED POOL*CPU TIME*USED'
SYPPLA ='PHYSICAL*SHARED POOL*CPU TIME*AVAILABLE'
SYPTHV ='HYPERVISOR*CPU*TIME'
SYPTINT ='INTERRUPT*CPU*TIME'
SYPTWS ='WAITTASK*TIME'
SYPTDN ='DONATED*CPU*TIME'
SYSSPTU ='SCALED*CPU*TIME*USED'
SYUCAPF ='PARTITION*UNCAPPED*FLAG'
SYDONF ='PARTITION*DONATION*FLAG'
SYPTWAIT ='VIRTUAL*PROCESSOR*THREAD WAIT*EVENT TIME'
SYPTREADY ='VIRTUAL*PROCESSOR*THREAD WAIT*READY TIME'
SYPTLATEN ='VIRTUAL*PROCESSOR*THREAD DISPATCH*LATENCY'
SYPTACT ='VIRTUAL*PROCESSOR*THREAD*ACTIVE TIME'
SYPTIDLE ='VIRTUAL*PROCESSOR*THREAD*IDLE TIME'
SYPTINTR ='VIRTUAL*PROCESSOR*THREAD*INTERRUPT TIME'
SYFRMCPU ='PROCESSOR*FIRMWARE*TIME USED'
SYFRMSCPU ='PROCESSOR*SCALED*FIRMWARE*TIME USED'
SYPFOLDSW ='PROCESSOR*FOLDING*SWITCH*STATE'
SYPFOLDST ='PROCESSOR*FOLDING*STATE'
SYEMMAJCDE='ENERGY*MANAGEMENT*MAJOR CODE'
SYEMMINCDE='ENERGY*MANAGEMENT*MINOR CODE'
SYEMATTR ='ENERGY*MANAGEMENT*ATTRIBUTES'
SYEMPWRLMT='ENERGY*MANAGEMENT*POWER DRAW*LIMIT WATTS'
SYSQLCPU ='UNSCALED*SQL*CPU TIME*USED'
SYSQLSCPU ='SCALED*SQL*CPU TIME*USED'
SYOSTMP ='CURRENT*TEMPORARY*STORAGE*ALLOCATED*NONDB'
SYDBTMP ='CURRENT*TEMPORARY*STORAGE*ALLOCATED*DB'
SYAJOBTMP ='CURRENT*TEMPORARY*STORAGE*CHARGED*ACTIVE'
SYEJOBTMP ='CURRENT*TEMPORARY*STORAGE*CHARGED*EMDED'
SYUSERTMP ='CURRENT*USER*TEMPORARY*STORAGE'
SYPSLPU ='PHYSICAL*SHARED POOL*SCALED*CPU TIME*USED'
SYTRUNIC ='HARDWARE*INSTRUCTIONS'
SYTRUNVTB ='NON-IDLE*PROCESSOR*VIRTUAL*TIME'
SYTITUIC ='INTERRUPT*INSTRUCTION*COUNT'
SYTFRMIC ='FIRMWARE*INSTRUCTION*COUNT'
Thanks to Raymond J. Smith, United Health Group, USA.
Change 33.100 -Protect RMF III for invalid ASI table index in UWD table
ASMRMFV entry that caused ABEND S0C4 in FINDAS when the invalid
Apr 12, 2015 index value was really bad, i.e., it exceeded the number
of entries in the ASI table and an attempt was made to
access data from well beyond the ASI table's end.
Thanks to Randy Schlueter, First Data Corporation, USA
Change 33.099 MXG 32.13-MXG 33.03. TMON/CICS Version 3.4 AND EARLIER.
VMACTMO2 -Dataset MONITASK CPU time (TASCPUTM) and ALL DURATION
Apr 11, 2015 variables are WRONG, TOO SMALL, by a factor of 4096.
In TMON Version 4, all durations were changed from the
original microseconds to TODSTAMP, which requires the
division by 4096, but the MXG code inserted for MONITASK
was mis-located and applied to all TMON versions.
-Less critical, and wrong ONLY with Version 4 records: ALL
duration variables in all OTHER MONIxxxx datasets were
NOT divided by 4096, so they are TOO LARGE by 4096.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 33.098 NMON (AIX/LINUX) CPU variables in PDB.NMONCPUD and in the
VMACNMON PDB.NMONINTV were revised and missing values corrected.
Apr 10, 2015 The individual CPUNR data in PDB.NMONCPUD from the three
CPUnn, PCPUnn, and SCPUnn records are the variables
prefixed with CPUNxxxx,PCPUNxxxx,SCPUNxxxx with suffixes
BUSY,IDLE,SYS,USER,WAIT.
The interval CPU_ALL, PCPU_ALL, and SCPU_ALL record's
in PDB.NMONINTV are prefixed PCPUxxxx,APCPUxxxx,ASCPUxxxx
with the same suffixes (plus variable APCPUENTCAP).
The BUSY variables are calculated for all observations.
Thanks to Florent Boulesteix, INOVANS partenaire CAAGIS, FRANCE.
Change 33.097 -SMFSRCH utility (select SMF records containing text and
SMFSRCH create all MXG datasets from those selected records) adds
Apr 9, 2015 new PRINT= option with YES/NO/nnn to print all, none, or
the first nnn observations of each dataset. The PRINTIT=
argument's YES or NO are still supported, but the PRINT=
argument is the more common spelling in MXG macros.
-Set USERADDS=NOUSERID, and all matching SMF types are
reported, but the 128-255 USER SMF records are skipped,
This avoids an abend if not all of your USER records are
mapped in IMACKEEP, MACKEEP, OR USERADDS= argument.
Thanks to MP Welch, Bank of America, USA.
Change 33.096 -z13 with SMT PROCVIEW=CORE, dataset TYPE70PR, variable
VMAC7072 SMT_NUM, the count of threads for each core, wasn't kept.
Apr 12, 2015 -TYPE70PR variable SMF70MTTT, MULTI-THREADING*IDLE*TIME,
which is actually SMF70MTIT mis-spelled, is accumulated,
requiring an additional sort and DIF() to deaccumulate.
As is ALWAYS the case when IBM writes ACCUMULATED values,
the value for the first instance of each LCPUADDR in each
LPAR will be a missing value. Some cases when the next
accumulated value was slightly smaller than the prior are
also set to missing value, but if they occur in your data
a PMR should be raised with IBM support. The label for
SMF70MTTT now contains 'SMF70MTIT' to compensate.
Thanks to Don Deese, Computer Management Sciences, USA.
Change 33.095 Optional SUMMARY=SMFBYTES/SMFRECNT argument will produce
ANALID a report sorted by DESCENDING &SUMMARY to print largest
Apr 3, 2015 first.
Change 33.094 Format MGSMFID did not describe SMF 115 records subtypes
FORMATS 5, 6, and 7.
Apr 3, 2015
Thanks to Paul Bennett, Euroclear, BELGIUM.
Thanks to Edmond Dierickx, Euroclear, BELGIUM.
Change 33.093 MXG 33.03. Disabled debug statement *PUTLOG +2 'DEBUG..;
VMAC7072 was followed by an unmatched */, but there was no syntax
Apr 3, 2015 error, because SAS recognized the asterisk as the start
of another comment, that ended with the semicolon of the
next statement, HOLICFTM=ICFACTTM;, so that statement was
absorbed and not executed. Fortunately, only ICF time in
some unusual circumstances, when the time had to be held,
might have been impacted.
Thanks to MP Welch, Bank of America, USA.
Change 33.092 -Some BBBPnnn variables were mis-assigned values: BBBP040
VMACNMON and BBBP049 because the BBBP40 'MAXIMUM CAPACITY' text
Apr 8, 2015 overlapped with BBBP49 'MAXIMUM CAPACITY OF POOL'. All
text tests are expanded to prevent the overlap.
-The MERGE of CPUD/CPUNP/CPUNS datasets had DUPLICATE
MERGE VARIABLES when the number of CPUs (observations)
in those datasets were not equal. Since CPUD has the
the primary CPU metrics, the MERGE was split into two
steps, first the three CPUD/CPUNP/CPUNS with CPUNR added
to the BY list, and now OUTPUT only if CPUD is present,
whether or not the other two datasets are present for
this CPUNR. Then the second step MERGES the output with
SNAPMAP to create PDB.NMONCPUD with the CPU metrics for
each CPUNR.
-Diagnostic tests for DISKBUSY counter errors corrected.
Thanks to Raissa Moussu, METROLOGFIE AIX EN PROVENCE, FRANCE.
Change 33.091 Support for CICS User fields USERAGT, ORIGUOW, and
IMACAAAA ORIGTGID.
IMACICVM
IMACICVN
IMACICVO
UTILEXCL
VMAC110
Apr 2, 2015
Thanks to Rob Hollingum, HSBC, ENGLAND.
Change 33.090 Mainview for MQ PTFs corrected the Offset ENTO value from
VMACBBMQ the always incorrect prior value of 28 for BBMQQUES 'E6'
Apr 2, 2015 to the correct value of 32, but this is an INCOMPATIBLE
change which mis-aligned MXG input, because MXG has known
to skip over those four bytes. Logic revised to support
either value since the records are otherwise unchanged.
BPL2458(MVMQ51) and BPL2459(MVMQ52) were the PTFs.
Thanks to Jim Swinarski, Credit-Suisse, USA.
Change 33.089 Not Used.
Change 33.088 Some duration variables in RMF III ZRBxxxx datasets still
VMACRMFV had TIME12.2 format but have millisecond resolution, so
Apr 1, 2015 they are all changed to TIME13.3 to show all decimals.
Change 33.087 -RMF Type 74 Subtype 9 zEDC Hardware Accelerator support.
VMAC74 The TYPE749 dataset was created with RMF 2.1 support back
Apr 1, 2015 in Change 31.153, but that INPUT was inhibited, awaiting
May 4, 2015 test records, and this update has been validated with
May 6, 2015 zEDC PCIE type 74 subtype 9 records.
-May 4: Variables R7491IIS and R74i1IOS corrected to add
II2 and IO2 instead of II1 and IO1.
-May 6: Variables R7491BPS and R7491BPC were incorrectly
multiplied in conversion to bytes - way too large.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 33.086 Support for Velocity Software zVPS a/k/a XAM Version 5.4.
VMACXAM Status April 9:
Apr 7, 2015 -All updates have been made with these exceptions:
EXXAMIFL Segments not documented, have data records, skipped:
EXXAMIFT TCP: LINMEM LINCPU LINITF
VMXGINIT DEV: IODSZI
Apr 9, 2015 New Segments, no data, not skipped, will print msg.
Apr 23, 2015 TCP:ORASYS ORAPGA ORASGA ORAWTS
VSECFG VSESYS VSECPU JVMSYS
-INFILE XAMCPU changes:
NEW dataset XAMIFLBY for individual IFL engine stats.
NEW dataset XAMIFLTO for TOTAL IFL engine stats.
-INFILE XAMUSR changes:
-New variables in USRCON segment added to dataset XAMUSR:
CALCFGEM ='CALICFCT'
CALCPCT ='CALCPCT'
CALICFCT ='CALICFCT'
CALIFLCT ='CALIFLCT'
CALZAPCT ='CALAZPCT'
CALZIPCT ='CALZIPCT'
LIMPOOL ='POOL*NAME*USER IS*ASSIGNED'
RDMMMASK ='LGR*DMN*BITMASK*SSI SLOTS'
RDMNAME ='LGR*DOMAIN*FROM*USEACT'
RELO1 ='CAUSED*BY*LGR?'
RLOMVOPT ='LGR*FLAG*BYTE'
SSHABSSH ='ABSOLUTE*SHARE'
SSHFLG1 ='SSHFLG1*SHARE*FLAG'
SSHLIMH ='LIMIT IS*HARD?'
SSHMXLSH ='MAXIMUM*SHARE'
SSHMXSHA ='MAX*SHARE*IS IN*ABS?'
SSHNMSHA ='NORMAL*SHARE*IS IN*ABS?'
SSHRELSH ='RELATIVE*SHARE'
VMDIDENT ='IDENTITY*VMDBK?'
VMDREOFL ='REORDER ON?'
VMDREOFL1='VMDREOFL1*FLAG'
VMDRLLST ='DATETIME*WHEN*LGR*ADDED'
VMDRLOLG ='ORIGINAL*MEMBER*LOGGED ON'
VMDRLSRC ='NAME FROM*WHERE LAST*LGR'
-New variables in USRACT segment added to dataset XAMUSR:
AGLA2G ='PRIVATE AGELIST >2GB'
AGLB2G ='PRIVATE AGELIST <2GB'
CALCPFNR ='PGS IBR WRITTEN, REREF'
CALCPFRY ='PGS IBR BACKED'
CALCPINT ='PRIVATE PAGES INSTANTD'
CALCPINV ='PGS MADE IBR'
CALCPPFA ='PGS RE-REFD AGELIST'
CALCPPFI ='PGS RE-REFD IBR'
CALCPREL ='PGS RELEASE DAG10/214'
CALCPXRL ='PGS XSTORE RELEASED'
CALCTXBK ='EXSTOR PG BLOCKS'
CALDSPCT ='COUNT TIMES DISPATCHED'
CALDWTCT ='COUNT READY TO BE DISPATC'
IBRA2G ='PRIVATE IBR PGS < 2GB'
IBRB2G ='PRIVATE IBR PGS <2GB'
INS ='PRIVATE PAGES'
RABISA2G ='NON REF'D PGS > 2GB'
RABISB2G ='NON REF'D PGS < 2GB'
VMACPSN ='VMACPSN'
VMAIIA ='IPTE ILOCK ACQ'S METHOD 2'
VMAIIADD ='IPTE ILOCK ADDED HOST SHR'
VMAIIHLD ='TIME HOST SHARES HEALD'
VMAIINHLD ='INTERVALS HOST SHARES HLD'
VMAIIWTM ='TIME WAITING IPTE ILOCK'
VMAIPTEI ='IPTE ILOCK ACQUISITIONS'
VMATTIME_PRO='VMATTIME_PRO'
VMATTMP_PRO ='VMATTMP_PRO'
VMATTMS_PRO ='VMATTMS_PRO'
VMAVTIME_PRO='VMAVTIME_PRO'
VMAVTMP_PRO ='VMAVTMP_PRO'
VMAVTMS_PRO ='VMAVTMS_PRO'
VMDCACHN ='MDC INSERTS'
VMDCPUCH ='SIE INTERUPTS'
VMDCRPGM ='REFERENCED PGMBK'
VMDCTSTA ='SIGP STARTS'
VMDCTSTO ='SIGP STOPS'
VMDCUPGM ='UNREFERENCED PGM'
VMDDSRSV ='TIMES LIMIT SET RESRVD'
VMDDTPLX ='DETACH COMMANDS SSI'
VMDDTTOD ='SSI DETACH CMD VTIME'
VMDDTTOT ='DETACH COMMANDS'
VMDLKPLX ='LINK COMMAND, SSI'
VMDLKTOD ='SSI LINK CMD VTIME'
VMDLKTOT ='LINK COMMANDS,'
VMDPBKCT ='PGMBK COUNT'
VMDSSIZE ='VMDSSIZE'
VMDSTFHW ='HI WATER STEAL WEIGHT'
VMDSTLFC ='STEAL WEIGHT FACTOR'
VMDTMORD ='PGMBK REORDERED'
VMDTTIME_MT1='VMDTTIME_MT1'
VMDTTMP ='TOT TCPU PRIMARY CPU'
VMDTTMP_MT1 ='VMDTTMP_MT1'
VMDTTMS ='TOT TCPU SECONDARY CPU'
VMDTTMS_MT1 ='VMDTTMS_MT1'
VMDUFACTC ='FRAMES OF UFO ACTIVE'
VMDUFIBRC ='FRAMES OF IBR'
VMDUFOLKCT ='UFO SPIN LOCK COUNT'
VMDUFOLKTM ='UFO SPIN LOCK TIME'
VMDVTIME_MT1='VMDVTIME_MT1'
VMDVTMP ='TOT VCPU PRIMARY CPU'
VMDVTMP_MT1 ='VMDVTMP_MT1'
VMDVTMS ='TOT VCPU SECONDARY CPU'
VMDVTMS_MT1 ='VMDVTMS_MT1'
VMDWASTE ='TIMES PGFLTS AGELIST'
VMDWKPLX ='WRKALLEG COUNTS, SSI'
VMDWKTOD ='VTIME, WRKALLEG SSI'
VMDWKTOT ='WRKALLEG COUNTS'
VMUDSPETM ='TIME DISPATCHED'
VMUDWTETM ='TIME READY TO BE DISPATCH'
VMUNREBAL ='CONFIG REBALANCES'
VMUREBAL ='VMUREBAL'
VMUVMLTL0='1ST*TOPOLOGY*STEALS'
VMUVMLTL1='2ND*TOPOLOGY*STEALS'
VMUVMLTL2='3RD*TOPOLOGY*STEALS'
VMUVMLTL3='4TH*TOPOLOGY*STEALS'
VMUVMLTL4='5TH*TOPOLOGY*STEALS'
VMUVMLTL5='6TH*TOPOLOGY*STEALS'
VMUVMTL0='1ST*TOPOLOGY*MOVES*FOR WORK'
VMUVMTL1='2ND*TOPOLOGY*MOVES*FOR WORK'
VMUVMTL2='3RD*TOPOLOGY*MOVES*FOR WORK'
VMUVMTL3='4TH*TOPOLOGY*MOVES*FOR WORK'
VMUVMTL4='5TH*TOPOLOGY*MOVES*FOR WORK'
VMUVMTL5='6TH*TOPOLOGY*MOVES*FOR WORK'
-INFILE XAMCPU changes:
Known problem, to be corrected in zVPS next iteration:
IFL records have only CPUID='IFLs' with TOTAL values.
There are no CPUID='IFLnnn' records for each IFL, and
the values in that CPUID='IFLs' record are the same as
the values in the CPUID='TOTAL' record.
-New variables in SYTSYP segment added to both datasets
XAMCPUBY and XAMCPUTO:
PLSPAGPS='COUNT*SSCH*FOR PG/SPOOL'
PLSSTKPE='ETS*DROP*COUNT'
PLSTMRCE='GUEST*ENABLE*COUNT'
PLSPRVSC='SVC*INTERUPT*COUNT'
-New variables in SYTPRP segment added to both datasets
XAMCPUBY and XAMCPUTO:
CPUCOUNT='CPU*COUNTS*FOR NCPU+1'
PFXFST44='SIMULATION*DIAG44'
PFXFSTPX='PARTIAL*EXECUTION*INTERUPTS'
PFXFSTSG='SIMULATION*SIGP'
PFXFSTXC='REFLECTIONS*GUEST*EXTERN '
PLS9CDSP='ALREADY*DISPATCHED'
PLS9CNR ='VMDSTATE*LT*VMDREADY'
PLS9CSWT='AND*SOFT*WAIT'
PLS9CWT ='AND*IN WAIT*STATE'
STEALPCT='LPAR*STEAL*TIME'
-New variables in SYTRSP segment added to both datasets
XAMCPUBY and XAMCPUTO:
PLSALECL='LT*2GB*LIST'
PLSALECG='GT*2GB*LIST'
-New variables in SYTCOM segment added to both datasets
XAMCPUBY and XAMCPUTO:
PLSIUCVT='TOTAL*IUCV*COUNT'
PLSISEVS='VSWITCH*TO A VM*SUCCESS'
PLSISTVS='VM TO A*VSWITCH*SUCCESS'
PLSISUVS='FAILED*VSWITCH IUCV'
PLSISEAS='ASYNCMD*TO A VM*SUCCESS'
PLSISTAS='VM TO A*ASYNCMD*SUCCESS'
PLSISUAS='FAILED*ASYNCMD IUCV'
PLSISESC='SCLP TO A*VM*SUCCESS'
PLSISTSC='VM TO A*SCLP*SUCCESS'
PLSISUSC='FAILED*SCLP*IUCV'
PLSISEVE='VMEVENT*TO A VM*SUCCESS'
PLSISTVE='VM TO A*VMEVENT*SUCCESS'
PLSISUVE='FAILED*VMEVENT*IUCV'
-New variable in SYTSCP segment added to both datasets
XAMCPUBY and XAMCPUTO:
PLSDSPCN='100*LOOP CNT*ON*&SCHED LCK'
-New variable in STORSP segment added to both datasets
XAMCPUBY and XAMCPUTO:
PLSASFCG='TIMES*ONE PAGE*FROM*GT 2G*LIST'
PLSASFCL='TIMES*ONE PAGE*FROM*CONTIG*LIST'
PLSESSA ='ESSA*INSTRUCTION*COUNT'
PLSLTDPE='LONG TERM*DORM*EMERGENCY*PASSES'
PLSPCPAG='CMM*MAYBE*VOLATILE*STOLEN'
PLSPUPAG='CMM*MAYBE*VOLATILE*UNCH PGS*STOLEN'
PLSUPAGE='CMM*UNUSED*STOLEN'
PLSUPREC='CMM*UNUSED'
PLSVPAGE='CMM*VOLATILE*STOLEN'
-New variable in PRCMFC segment added to both datasets
XAMCPUBY and XAMCPUTO:
CCFCPUSP ='CPU*SPEED '
CYCLECNT ='CYCLE*COUNT*NOT IN*WAIT'
INSTRCNT ='INSTRUCTIONS*EXECUTED'
L1ICACHW ='LEVEL 1*ICACHE*DIRECTORY'
L1IPENAL ='L1*PENALTY*CYCLE*COUNT'
L1DCACHW ='LEVEL 1*DCACHE*DIRECTORY'
L1DPENAL ='L1*PENALTY*CYCLE*COUNT'
PCYCLECNT ='CYCLE*COUNT*NOT IN*WAIT'
PINSTRCNT ='INSTRUCTIONS*EXECUTED'
PL1ICACHW ='LEVEL 1*CACHE*DIRECTORY'
PL1IPENAL ='L1*PENALTY*CYCLE*COUNT'
PL1DCACHW ='LEVEL 1*CACHE*DIRECTORY'
PL1DPENAL ='L1*PENALTY*CYCLE*COUNT'
CCFEXT0='0TH*COUNTER'
CCFEXT1='1ST*COUNTER'
. . .
CCFEXT62='62TH*COUNTER'
CCFEXT63='63TH*COUNTER'
CPI ='CYCLES*PER*INSTRUCTION'
PRB ='PERCENT*PROBLEM*STATE'
L1MP ='LEVEL 1*MISS*PER INST'
L2P ='PCT FROM*LEVEL 2'
L3P ='PCT FROM*LEVEL 3*SAME'
L4LP ='PCT FROM*LEVEL 4*SAME'
L4RP ='PCT FROM*LEVEL 4*REMOTE'
MEMP ='PCT*FROM*MEMORY'
-New variable in PRCRCD segment added to both datasets
XAMCPUBY and XAMCPUTO:
CALENTMT='CPU*ENTITLEMENT'
RCCTOPDS='TOPOLOGY*BIT*MASK'
PFXDSPCS='LONG*PATHS*THRU*DISP2'
PLSDSPCM='TIMES*DISP*VMDBK*MOVED'
PLSSTLTL0='0TH*CNT*STOLEN*VMDBKS'
PLSSTLTL1='1ST*CNT*STOLEN*VMDBKS'
PLSSTLTL2='2ND*CNT*STOLEN*VMDBKS'
PLSSTLTL3='3RD*CNT*STOLEN*VMDBKS'
PLSSTLTL4='4TH*CNT*STOLEN*VMDBKS'
PLSSTLTL5='45H*CNT*STOLEN*VMDBKS'
-New variable in PRCDHF segment added to both datasets
XAMCPUBY and XAMCPUTO:
DSVASSOC ='ONLINE*CPUS'
DSVUNPRK ='UNPARKED*CPUS'
HFUSERZ ='TIMES*NO VMDBK*IN DLIST'
-INFILE XAMSYS changes:
/* SYTEP2 */
TCT_FCOP ='FICON*OPS*FCX*CMDS'
TCT_DFCOP='DEFRD*FICON/FCX*OPS'
SCT_FCOP ='SUMMATION*COUNT*OPS'
TCT_FCXTM='FCX*TRANSFER*OPS'
TCT_DFCXTM='DEFERRED*FCX*XFERS'
SCT_FCXTM ='SUMMATION*FCX*XFERS'
/* STOSHR */
ASCCTRSV='RESERVED*BY*SET*RESERVED'
ASCDSRSV='CNTLIMITED*BY*SET*RESERVED'
/* SYTCUM */
LCUSMTM='SYSTEM*MGMT*TIME'
PCTSYSM='PCT*SYSTEM*MGMT TIME'
/* SYTSYG */
MAI_MISS='MISSING*ADAPTR*INTERUPTS'
MAI_UREC='UNRECOVERABLE*ADAPTR*INT'
FXRDONE ='FCX*I/O*COMPLETE'
FXRWRITE='FCX*WRITES'
/* STORSG */
SECONDS ='SECONDS'
RSAAVCLT ='LT 2G*CONTIG*AVAIL LIST*LO'
RSAAVCHT ='LT 2G CONTIG*AVAIL LIST*HI'
RSAAVCLG ='GT 2G CONTIG*AVAIL LIST*LO'
RSAAVCHG ='GT 2G CONTIG*AVAIL LIST*HI'
RSAEMLO ='LOW*THRESHOLD'
RSAEMHI ='HI*GHREHSOLD'
RSAEMCPC ='CURRENT*POOL*SIZE'
RSAEMERG ='EMERGENCY*PGMBK*REQUESTS'
RSAEMBLO ='TIMES*CPC LT LO'
RSAEMPTY ='TIMES*CPC*EMPTY'
RSAEMDFR ='TIMES*PGMBK*DEFERRED'
RSASWPWT ='PG WRITES*TO*DISK LT 2GB'
RSASWP2G ='PGMBK WRITES*TO*DISK GT 2GB'
RSAAGEPC ='RSAAGEPC'
RSARSDMX ='SET*RESERVED*SYSMAX'
RSAAGESZ ='TARGET*AGING*LIST'
RSAAGINC ='FRAMES*ON AGING*LIST'
RSAEWNDD ='CHANGED*PGS ON*AGELST'
RSAEWRFO ='REF-D*PGS ON*AGELIST'
EWCIF ='CHNGED*PGS*PAGING*OUT'
EWRIF ='FEF-D*PGS*PAGING*OUT'
AGRDY ='TOTAL*FRMS*ON*AGELIST'
AGRDYRFW ='REF-D*PGS*WRITTEN'
AGRDYRFN ='REF-D*PGS*NOT*WRITTEN'
AVLCTB2S ='AVAILLIST*LT*2GB*SNGL'
AVLCTB2C ='AVAILLIST*LT*2GB*CONTI'
AVLCTA2S ='AVAILLIST*GT*2GB*SNGL'
AVLCTA2C ='AVAILLIST*GT*2GB*CONTI'
DSTMACT ='TOD*DEMAND*SCAN*RUNNG'
CHGWRTOL ='CHNGD*PGS*RE-WRITOLD'
REFWRTBY ='REF-D*PGS*BYPASS WRT'
CHGWRTNW ='CHNGD*PGS*RE-WRITNEW'
REFWRTNW ='REF-D*PGS*RE-WRITTEN'
AGRECLM ='PGS*RECLAIMED*AGELIST'
EXMET ='DEMAND*SCAN*COMPLETES'
EXTIM ='DEMNDSCAN*INCOMPLETES'
EXCPU ='DEMANDSCAN*SLOWCPU'
INVUFO ='PRIVATE*PGS*INVALDTED'
INVVUFO ='PRIVATE*VDSKINVALDTED'
INVSUFO ='SHARED*PGS*INVALIDATD'
RVLUFO ='PRIVATE*PGS*RE-VALID'
RVLVUFO ='PRIV*VDISK*PGS*RE-VAL'
RVLSUFO ='SHARED*PGS*REVALIDATD'
RVLAGL ='PGS*REVALID*ON*AGELST'
WRTONDMD ='PGS*RECLAIMED*POSTWRT'
DSCYCLE ='DEMAND*SCANS'
USRVISIT ='USERS*VISITED'
USRSKIP ='USERS*SKIPPED'
RSAALSKL ='AGELIST*PGS*PINNED'
RSAALSKF ='AGELST*FRMSERIALIZED'
RSAALSKP ='AGELST*PGSERIALIZED'
RSAALSKR ='AGLSTSETRESERVED'
AGRVLRFN ='REREF-D*PGS*NOTWRITTN'
AGRVLRFW ='REREF-D*PGS*WRITTEN'
AGRVLCHN ='REREF-D*CHNGD*PGS NW'
AGRVLCHW ='REREF-D*CHNGD*PGS WRT'
AVLRQB2S ='SNGLPG*REQUESTS*LT 2GB'
AVLRQA2S ='SNGLPG*REQUESTS*GT 2GB'
AVLRQB2C ='CONTIG*REQUESTS*LT 2GB'
AVLRQA2C ='CONTIG*REQUESTS*GT 2GB'
AVLRETB2S='RETURNS*SINGLE*LT 2GB'
AVLRETA2S='RETURNS*SINGLE*GT 2GB'
AVLRETB2C='RETURNS*CONTIG*LT 2GB'
AVLRETA2C='RETURNS*CONTIG*GT 2GB'
AVLPTA2GC='PROTECT* GT 2GB*LIST SIZ'
AVLPTB2GS='PROTECT*SNGLS* LT 2GB'
WRTHROTS ='DEMAND*SCAN*THROTTLES'
PRTHROTS ='PARTIAL*THROTTLES'
/* MTRSCH */
SRMFLAGS='SRMFLAGS'
/* MTRSYS */
SYSCMODE='SYSCMODE'
VCPUF ='VCPU ACCOUNTING FACTOR'
TCPUF ='TCPU ACCOUNTING FACTOR'
DIOF ='DASD I/O FACTOR '
STORF ='RESIDENT STORAGE FACTOR'
CHARGE ='CHARGE PER UNIT'
SYSCCR ='CAPCHANGE*REASON*STSI*1.1.1'
SYSCAI ='CAPADJUSTMENT*STSI*1.1.1 '
SYSESTAT='ENSEMBLE*STATUS'
STITODOF='STP*TOD*CLOCK*OFFSET'
SYSSTPFL='STP*CONFIGURATION*INFO'
SYSSTPF2='FLAGS'
SYSPLVOL='SSI*PDR*VOLUME*SERIAL'
SYSCSSID='CHANNEL*SUBSYSTEM*(CSS)*ID'
SYSCPMOD='CP*LOAD*MODULE'
HCPLODCK='TOD OF*SYSTEM*GENERATION'
SLMENSID='URM*ENSEMBLE*ID'
/* MTRMEM */
SYSGSTBY='STANDBY*REAL*STORAGE*SIZE'
SYSGSTRS='RESERVED*REAL*STORAGE*SIZE'
/* SYTXSG */
TCMPINVA='PAGE*FAULTS*RESOLVED*PGINTRK'
TCMSTKEX='TIMES*CPEBK*DEFERED*TRKWRT'
CMSTKPFK='TIMES*CPEBK*DEFERED*TRKFLT'
/* SYTUWT */
CALLLCP ='LIMIT*LIST*CP WAIT'
CALLLZAP='LIMIT*LIST*ZAP WAIT'
CALLLIFL='LIMIT*LIST*IFL WAIT'
CALLLZIP='LIMIT*LIST*ZIP WAIT'
CALCFCP ='CF WAIT*WAIT FOR*CP'
CALCFZAP='CF WAIT*WAIT FOR*ZAP'
CALCFIFL='CF WAIT*WAIT FOR*IFL'
CALCFZIP='CF WAIT*WAIT FOR*ZIP'
CALSWCP ='SIM WAIT*WAIT FOR*CP'
CALSWZAP='SIM WAIT*WAIT FOR*ZAP'
CALSWIFL='SIM WAIT*WAIT FOR*IFL'
CALSWZIP='SIM WAIT*WAIT FOR*ZIP'
CALCWCP ='CPU WAIT*WAIT FOR*CP'
CALCWZAP='CPU WAIT*WAIT FOR*ZAP'
CALCWIFL='CPU WAIT*WAIT FOR*IFL'
CALCWZIP='CPU WAIT*WAIT FOR*ZIP'
CALCRCP ='VMDBKS*RUNNING*ON CP'
CALCRZAP='VMDBKS*RUNNING*ON ZAP'
CALCRIFL='VMDBKS*RUNNING*ON IFL'
CALCRZIP='VMDBKS*RUNNING*ON ZIP'
CALLLICF='LIMIT*LIST*IN ICF'
CALCFICF='CONSOLE*FUNCTION*MASTER'
CALSWICF='SIMULATION'
CALCWICF='CPU*WAIT'
CALCRICF='RUNNING'
/* SYTUSR */
RLOIB='ACTIVE*INBOUND*LGRS'
RLOOB='ACTIVE*OUTBOUND*LGRS'
/* SYTRSG */
RSASNG2G='SINGLE*FRAMES*GT 2GB*AVAIL'
RSASNGAV='SINGLE*FRAMES*LT 2GB*AVAIL'
/* SUBSUM */
NCPCAPABIZE='CPU*CAPABILITY*FACTOR'
OVERCOMMIT ='OVERCOMMIT'
STORAGESIZE='STORAGE*SIZE'
XSTORESIZE ='XSTORE*SIZE'
-INFILE XAMDEV changes:
-New variable in CONFIG segment added to XAMDEV dataset:
EDEVATTR='EDEVATTR'
RDEVHPPL='HYPERPAV*POOL*NUMBER'
CALDEVFLAGS='CALDEVFLAGS'
DEVPTHS ='DEVPTHS'
/*IODDEV */
PAVINELG ='I/O*INELIGIBLE*TO STEAL'
PAVUSES ='I/O*STEALS'
PAVSSCH ='BASE*PAV*SSCH'
PAVCOUNT ='PAV*DEVICE*COUNT'
PAVCNTIM ='PAV*ALIAS*CONNECT*TM'
PAVCPTIM ='PAV*ALIAS*PEND*TM'
PAVCDTIM ='PAV*ALIAS*DISC*TM'
PAVCQTIM ='PAV*ALIAS*QUEUE*TM'
PAVCATIM ='PAV*ALIAS*ACTIVE*TM'
PAVDBTIM ='PAV*ALIAS*SUBCHAN*TM'
PAVIRTIM ='PAV*ALIAS*QUEUE*TM'
PAVCC3S ='PAV*ALIAS*CC3*IO CNT'
RDEVSKSM64='TOTAL*SEEK*CYCLINDERS'
RDEVWXCT ='COUNT*FCX*WRITES'
RDEVRXCT ='COUNT*FCX*READS'
-INFILE XAMTCP changes:
/*VSIUSR*/
STGSAMPS='STGSAMPS'
VMPEAK ='PEAK*USAGE'
VMSIZE ='CURRENT*USAGE'
VMLCK ='CURR*MLOCKED*MEMORY'
VMHWM ='PEAK*RSS'
VMRSS ='RESIDENT*SET*SIZE'
VMDATA ='SIZE*DATA*SEGMENT'
VMSTK ='SIZE*OF*STACK'
VMEXE ='SIZE*TEXT*SEGMENT'
VMLIB ='SHARED*LIBRARY*USAGE'
VMPTE ='PAGETABLE*ENTRIES*SIZE'
VMSWAP ='SWAP*SPACE*USED'
/*VSINAP*/
STGSAMPS ='STGSAMPS'
VMPEAK ='PEAK*USAGE'
VMSIZE ='CURRENT*USAGE'
VMLCK ='CURR*MLOCKED*MEMORY'
VMHWM ='PEAK*RSS'
VMRSS ='RESIDENT*SET*SIZE'
VMDATA ='SIZE*DATA*SEGMENT'
VMSTK ='SIZE*OF*STACK'
VMEXE ='SIZE*TEXT*SEGMENT'
VMLIB ='SHARED*LIBRARY*USAGE'
VMPTE ='PAGETABLE*ENTRIES*SIZE'
VMSWAP ='SWAP*SPACE*USED'
PROCID ='PROCID'
PPIDL ='PPIDL'
PROCNAMEL='PROCNAMEL'
PATHNAMEL='PATHNAMEL'
APPLIDSS ='APPLIDSS'
/*VSISFT*/
PRTY ='PRTY'
STGSAMPS ='STGSAMPS'
VMPEAK ='PEAK*USAGE'
VMSIZE ='CURRENT*USAGE'
VMLCK ='CURR*MLOCKED*MEMORY'
VMHWM ='PEAK*RSS'
VMRSS ='RESIDENT*SET*SIZE'
VMDATA ='SIZE*OF DATA*SEGMENT'
VMSTK ='SIZE*OF*STACK'
VMEXE ='SIZE*OF TEXT*SEGMENT'
VMLIB ='SHARED*LIBRARY*USAGE'
VMPTE ='PAGETABLE*ENTRIES*SIZE'
VMSWAP ='SWAP*SPACE*USED'
PROCID ='PROCID'
PPIDL ='PPIDL'
PROCNAMEL='PROCNAMEL'
PATHNAMEL='PATHNAMEL'
APPLIDSS ='APPLIDSS'
/*VSISYS*/
PROCTOT ='PROCTOT'
STATIC ='STATIC'
TIMED ='TIMED'
RELEASEP ='RLS RATE*IN PAGES'
RELEASETM='RLS TIME*IN SECONDS'
SWAPINESS='SWAPINESS'
CPUCOUNT ='CPUCOUNT'
/*HSTMEM*/
RWFLAG ='RWFLAG'
BOOTFLG='BOOTFLG'
BUFFER ='BUFFER'
BUFFERCH='BUFFERCH'
DESCR is expanded to 32 positions (Apr 23)
/*UCDSYS*/
ANONYMOUS='ANONYMOUS'
SHARED ='SHARED'
====== Changes thru 33.085 were in MXG 33.03 updated Mar 31, 2015=======
Change 33.085 Change 33.078 VGETDDS removal of SASAUTOS was incorrect,
VGETDDS causing ERROR 22-322 generated by Macro Variable TOSET;
Mar 30, 2015 DDNAMES was corrected to DDOUT.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 33.084 Change 33.018 was dropped between 33.01 and 33.02.
EXTY8036 New dataset TYPE8036 (EXEC WITH SETUID/SETGID) and new
EXTY8056 dataset TYPE8056 (CHECK FILE OWNER) are now created and
IMAC80A variable TOKMPROCUSERMAX is now spelled correctly so the
VMAC80A UNINIT TOKPROCUSERMAX message is eliminated.
VMXGINIT
Mar 29, 2015
====== Changes thru 33.083 were in MXG 33.03 dated Mar 27, 2015=========
Change 33.083 Summary datasets PDB.ASUM70PR/PDB.ASUM70LP have INCORRECT
VMXG70PR values for intervals when ALL LPARs are NOT active for
Mar 27, 2015 the full summary interval you requested, e.g., you set
INTERVAL=HOUR (in your TAILORED ASUM70PR member or your
%VMXG70PR invocation) but the first RMF records in each
SMF file was the 23:50 START, written at 00:00.01, which
created an ASUM70PR HOURLY observation, (for EACH system,
as each SYSTEM creates TYPE70PR for each LPAR it "sees")
with a START of 23:00, but with only 10 minutes DURATM.
Or, if you activate an LPAR at 10:30, the ASUM70PR obs
will have only 30 minutes DURATM. The incorrect DURATM
impacts the individual LPAR durations, and the PCTCPUBY
in ASUM70PR (the SYSPLEX value, and NOT the busy of the
SMF SYSTEM that created the ASUM70PR observation) is
wrong and can be greater than 100%.
-These defective observations can be deleted by testing
that DURATM is less than your requested summary INTERVAL.
-OR: THE CORRECT VALUES ARE IN THE PDB.ASUMCEC/ASUMCELP
datasets, and since there is only one observation in the
PDB.ASUMCEC for each interval (for each CECSER), you do
not have to select which SYSTEM's record is used in your
reports (and your reports will be produced even if that
SYSTEM goes away!).
And, at this time, the underlying error in VMXG70PR has
NOT been resolved; it is related to the PER-SYSTEM logic
which is clearly vulnerable to individual system metrics,
but the newer and more robust per-CEC logic resolves the
error, or the defective observations can be deleted.
(If these are abnormal hours, maybe you still want to
delete them, even when using the PDB.ASUMCEC data!).
With 60 PROC/DATA steps in the complex VMXG70PR logic,
the risk of damage to the good might not justify trying
to repair
-No logic was changed; debugging PROC PRINTs were inserted
but are disabled.
Change 33.082 DCOLLECT dataset DCOLDSET now contains variable DCDCTYPE
VMACDCOL to identify compression type, using MG014CT (added 33.01)
Mar 26, 2015 with these possible values:
0='0:NOT COMPRESSED/UNKNOWN'
1='1:GENERIC'
2='2:TAILORED'
3='3:ZEDC'
This text was revised Mar 25, 2019, See Change 37.063.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 33.081 -New _READALL macro processes 70s, 72s,and 30s in one pass
SAGANAL of SMF to significantly reduce elapsed run time.
Mar 27, 2015 -The 4HR Average Zip Eligible MSU is added to REPORT 3.
Apr 8, 2015 -New REPORT 30 with the CAPTURE RATIO shows the IBM 4HOUR
IMACSAG AVERAGE MSU and the TOTAL MSU CAPTURED in the RMF 72
VMXGINIT Service Class records.
Apr 13, 2015 -New IMACSAG and &MACSAG exits permit report selection for
specific dates.
Change 33.080 Documentation note. The default BUILDPDB builds the ID
TYPEID dataset using a VIEW and then invokes %ANALID to report.
Mar 24, 2015 The VIEW is NOT deleted, but if you have added code that
uses the ID dataset (like PROC SORT DATA=ID), the entire
SMF INPUT FILE WILL BE READ AGAIN, or, if you have used
FREE=CLOSE, that second read will fail with FILE SMF NOT
ASSIGNED. You can prevent the second read by disabling
the view, using %LET VWVMACID=; to disable for ID, but
that will require more //WORK disk space.
Change 33.079 Protection for truncated SMF Type 22 Subtype 11 LRECL=32
VMAC22 (LENGTH=28) when that subtype must be at least 140 bytes.
Mar 24, 2015
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 33.078 %MACROs that SAS puts in SASAUTOS (%TRIM,%LOWCASE,others)
UTILBLDP have been completely removed from all MXG members, since
Mar 23, 2015 we still find sites that do not have FILENAME SASAUTOS to
resolve those functions (that SHOULD, IMO, been delivered
as real functions and avoid 20 years of SASAUTO errors).
These were the final members that now use %SYSFUNC().
ANALRANK BLDNTPDB READDB2 UTILBLDP UTILDUMP VGETALOC
VGETDDS VMXGALOC VMXGCAPT VMXGFIND VMXGPRAL VMXGSRCH
ZAUTOCHK VMXGPARS
Change 33.077 WPS Only. MXG TYP120xx SMF 120 datasets can have strange
VMAC120 characters in UCS text because there were two tests for
VMXGINIT &SYSVER GE 8.2 that are now corrected to &SASVER GE 8 in
Mar 23, 2015 VMAC120 and VMXGINIT (which incorrectly set &UCS2B4).
For WPS, the &SYSVER returns 3.01 (and is 9.4 for SAS),
and it is used when the sub-version is needed, but MXG
intended to set &SASVER to 8 for WPS, and use the first
digit of &SYSVER for &SASVER for SAS, for both WPS/SAS
and SAS V8/V9 selections.
8 for WPS (and is 9 for SAS) so that &SASVER can be used
to detect WPS and/or SAS V9 features. And, in VMXGINIT
the actual value set for &SASVER was 8.2 instead of 8 for
WPS. And since I needed to find any other exposures, I
removed a number of archaic tests for &SASVER 5 and 6 in
these members:
BUIL3001 BUILD001 BUILDPD3 BUILDPDB DOCPDB FORMATS
IMACPDBX JCLUXRE6 MONTHBL3 MONTHBLD MONTHBLS MONTHWEK
PRODTEST PRODTESW TYPSIMS TYPSIMS7 VFMT102 VMAC120
VMAC7072 VMACIMS VMXGINIT WEEKBL3D WEEKBL3T WEEKBLDD
WEEKBLDT
Thanks to Erling Andersen, SMT, DENMARK.
Change 33.076 Support for IMS56FA Chained/Switched INPQUETM correction.
TYPEIMST INPQUETM for chained transactions (have same ARRVTIME) is
TYPSIMST revised to use the prior transaction's HELDENDTIME as the
VMACIMS the "ARRVTIME" for the next transaction. Variable SWITCH
Mar 24, 2015 identifies if this was the first, or subsequent, switched
transaction, and HELDENDTIME is kept in IMS56FA. Variable
RESPNSTM is also recalculated with the new INPQUETM.
The correction is made in the _SIMS56G dataset sort macro
so it requires a full sort of the IMS56FA dataset; the
TYPSIMST member has the JCL and SYSIN example to use to
correct INPQUETM and create the IMS56FA.IMS56FA dataset.
The TYPEIMST member creates WORK.IMS56FA, unsorted and
uncorrected.
Or, to create ALL of the IMS log datasets and correct
the INPQUETM, you can use
%INCLUDE SOURCLIB(TYPEIMS7);
which invokes the _SIMS46X sort macro to sort both the
46x and 56x IMS log records and fix IMS56FA's INPQUETM,
writing all IMS datasets to //WORK, but you can use
%LET PIMSxxx=YOURDD; to send individual datasets to your
chosen DDNAME.
Thanks to Thomas Peiper, TIETO, FINLAND.
Change 33.075 When VMXGDBAA was run, the KEEPIN= logic in VMXGSUM could
VMXGSUM fail, resulting in UNINITIALIZED VARIABLEs notes for
VMXGDBAA QWACESC and other variables. Exposed when removing the
Mar 22, 2015 AUTOCALL macros from VMXGDBAA, was not actually reported.
Change 33.074 Support for Mainview for MQ version 5.2 BBMQQUES 'E6'
VMACBBMQ with these new variables added:
Mar 22, 2015 QSAC6NXG ='NEXT*AC6 RECORD*WITH THIS*HASH'
QSIBGETC ='CONSUMED*MQGET*BYTES'
QSIBGTCF ='GET*BYTES*CONSUMED*RATE'
QSIFPUT ='FAST*PUT*COUNT'
QSILMPUT1='LARGEST*MQPUT1*SESSION'
QSISMPUT1='SMALLEST*MQPUT1*INTERVAL'
QSISTCKB ='INTERVAL*START*DATETIME*STAMP'
QSQUDPTH ='UNCOMMITTED*MESSAGES'
QSSBGETC ='CONSUMED*MQGET*BYTES'
QSSBGTCF ='GET*BYTES*CONSUMED*RATE'
QSSBGTCR ='GET*BYTES*CONSUMED*RATE'
QSSFPUT ='FAST*PUT*COUNT'
QSSFPUT1 ='FAST*PUT1*COUNT'
QSSLMPUT1='LARGEST*MQPUT1*SESSION'
QSSSMPUT1='SMALLEST*MQPUT1*SESSION'
QSSSTCKB ='SESSION*START*DATETIME*STAMP'
QWIFPUT1 ='FAST*PUT1*COUNT'
and these old variables are no longer input and will be
missing values in BBMQQUES:
QSIFBGTF QSIFBGTR QSIFBP1F QSIFBP1R QSIFBPT1 QSIFBPTF
QSIFBPTR QSIFBPUT QSINDSCR QSSFBGTF QSSFBP1F QSSFBPT1
QSSFBPTF QSSFBPTR QSSFBPUT
Thanks to Paul Volpi, UHC, USA.
Change 33.073 New variable FCBYTERATE added to TYP11903 and TYP11907
VMAC119 datasets.
Mar 22, 2015
Change 33.072 SMF 103 Documentation. For the Apache Server (which must
VMAC103 be used in z/OS 2.2 where the prior Domino Server is not
Mar 22, 2015 supported), the JOB name can be passed into the D record
with a variable - export JOBNAMEH="WEBSRV02" - in the
shell scripts that start the Apache Web Server and using
this JOBNAMEH variable as ServerName ${JOBNAMEH} in the
httpd.conf file.
The SMF 103 record has been written by the same product
since its inception, but the IBM product names have
included these:
"HTTP Web Sphere Server"
Lotus Domino GO Webserver R4
Internet Connection Secure Server (R3,R2)
and now, in 2015, Apache Server.
Thanks to Joe Faska, DTCC, USA.
Change 33.071 z13 SUPPORT. MXG 33.03 REQUIRED ONLY FOR PROCVIEW CORE.
VMAC7072 For PROCVIEW CPU non-SMT, NO CHANGES WERE MADE TO RMF 70.
Mar 21, 2015
For SMT PROCVIEW CORE Mode, MXG Change 33.046 in 33.02
updated the TYPE70 dataset, but this Change 33.071 in MXG
33.03 is required to update the new SMT metrics correctly
in the TYPE70PR dataset, to get the CPUID, LCPUADDR, and
CORE_ID from the four segments that don't have the same
number of segments: OFFCPUD and SMF70COS have 20 for the
6 online CPs, 4 offline CPs, and 5 zIIPs with CPU_NUM=2,
while SMF70BDN/LPARCPUX has only 18 segments (with the
CORE_NUM needed to look-up the LCPUADDR), and there are
only 14 Core_ID values.
This was a complex update to a CRITICAL MXG MEMBER, with
500+ lines of code inserted lines into the 27,000 lines.
The SMT Mode data has been validated with RMF records,
with a wide range of LPAR configurations. When in SMT
mode, please examine the new data carefully and contact
support@mxg.com if you have questions.
Note: If you read the changed SMT mode RMF 70s with an
old MXG, RMFINTRV may have NEGATIVE CPUOVHTM values and
the %PCTCPUBY values may be over 100%.
Specifically, if z/OS is IPL'd with LOADxx PROCVIEW CORE, on
a processor that is SMT capable, then whether or not MT is
Active, and even if MT=1 is specified, then the RMF 70 record
is restructured with CORE_ID.
This support was validated with z/OS 2.1 and z13 data.
Change 33.070 New INCLAI, three $LIST_L and $RESTAR TOKENIDs, added by
VMACTPMX ThruPut Manager AE+ V7R1.0 create five new variables
Mar 20, 2015 INCLA1 JBL54043 JBL54L44 JBL54L45 RESTAR
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 33.069 SAS 9.4 has a dictionary entry for DESTINATIONS but
ANALDB2R older releases do not. On zOS, report MXGDB2B1 used this
Mar 20, 2015 to see if the active destination for ODS was listing and
to bypass the graphics code in that report. The PROC SQL
is now only used when we find SAS 9.4 or greater.
-Spurious message were produced indicating reports were
requested when you specified report=NO because the code
was checking the length and not the value.
-If the DB2STATB dataset was empty or non-existent the
macro variable GOTRMF did not exist and raised an
unresolved MACRO variable error.
Thanks to Randy Hewitt, HP, USA.
Change 33.068 Change 30.133 typo caused Q8STCCPU to not be kept.
VMACDB2
Mar 20, 2015
Thanks to Tim King, Blue Cross Blue Shield of South Carolina, USA.
Change 33.067 DB2 Trace ID=102 IFCID=220 misaligned, causing ILLEGAL
VMAC102 ARGUMENT TO MDY function. The QW0220xx variables are
Mar 17, 2015 now kept.
Thanks to Randy Hewitt, HP, USA.
Change 33.066 VMXGPPDS failed when used as documented, unable to find
VMXGPPDS MYPDS because the last few lines of the macro incorrectly
Mar 17, 2015 tried to execute the macro with the defaults.
Change 33.065 If %VGETLIBS found no LIBNAMEs were allocated, it failed
VGETLIBS with MACRO variables not found. Now if there are none
Mar 17, 2015 found, it dies a graceful death and tells you that it
found no matching LIBNAMES.
Change 33.064 Format $MGSTCRT new values for SMF19RTM/RTE variables:
FORMATS '07'X='07X:VTV MOVE'
Mar 16, 2015 '08'X='08X:ALTERNATE RECALL'
Thanks to Mike Jacques, BB&T, USA.
Change 33.063 In parsing a quoted literal such as '15MAR2015'D, to make
VMXGPARS the text more readable, the D could be separated from the
Mar 26, 2015 Quote, resulting in a 180 Syntax Error. VMXGPARS now
recognizes a DT following a quote and/or any non-blank
character and extends the string.
Change 33.062 -In Change 31.209, VMXGSUM's %TRIM AUTOCALLed function was
VMXGSUM replaced by the internal %SYSFUNC function, to circumvent
VMXGINIT errors when sites don't have AUTOCALL/MAUTOSOURCE/etc set
Mar 16, 2015 up correctly, but %TRIM crept back in VMXGSUM and is now
VMXGPARS again replaced with %SYSFUNC.
-MXGDEBUG=FULL option executes PROC OPTIONS VALUE, to show
each option's value and how it was set, PROC PRINTs the
SASHELP tables VLIBNAM to show all LIBNAMES, and VEXFL to
show all External FILENAMES - (is there a SASAUTOS??),
and enables these full source code diagnostic options
OPTIONS SOURCE SOURCE2 MACROGEN MPRINT SYMBOLGEN;
to print full source with line numbers on the SAS log.
Invoke the FULL option in //SYSIN with this syntax:
%LET MXGDEBUG=FULL; %VMXGINIT;
-The %LEFT in %VMXGPARS was replaced.
Change 33.061 GDPS SMF 105 INPUT STATEMENT EXCEEDED when XVMX segment
VMAC105 was not present; the bit test was insufficient to confirm
Mar 16, 2015 the segment was extended so a length test was added.
Thanks to Paul Volpi, UHC, USA.
Change 33.060A Change text was lost, added May 2016.
ANAL113 Dataset ASUM113 was replaced by ASUM1131 for reports.
Mar 11, 2015
Change 33.060 -DCOLLECT Cluster dataset DCOLCLUS now contains variables
VMACDCOL DCDDATCL,DCDMGTCL,DCDSTGCL, Data/Management/Storage Class
Mar 11, 2015 that are retained from the immediately preceding type D
Mar 21, 2015 record prior to the type A record, when the "D" record's
DSNAME matches the "A" records' Cluster Name.
-In DCOLDSET dataset, multi-volume records now contain
those three Class variables in all observations; in the
DCOLLECT records, those fields are only populated in the
DCDVOLSQ=1 records. This change revised the _SDCODSN
Data Set Sort to propagate from the first to subsequent
volume's observations. You MUST USE TYPSDCOL to invoke
that _SDCODSN data set sort or classes will be blank in
the 2nd and subsequent volumes.
-Mar 21: DCOLDSET dataset label added to PROC SORT.
Thanks to John Kim, Worker's Compensation Board of Alberta, CANADA.
Change 33.059 Support for Thales Security Resource Manager RG1100.
EXTHALRT -New variables added to THALSUMD dataset:
IMACTHAL THAASID ='SSID OF*ORIGIN*APPL-AS'
VMACTHAL THADBUSY='BUSY*WITH*USER*REQUESTS'
VMXGINIT THADINTV='INTERVAL*DURATION'
Mar 10, 2015 THADNCNT='REQUESTS*PROCESSED'
Mar 24, 2015 THADOVER='BUSY*WITH*SRM*REQUESTS'
Apr 15, 2015 THADUFLG='DEVICE*CONTINUOUS*USE*OR NOT'
-New THALRESP Response Time dataset, with variables:
THAASID ='SSID OF*ORIGIN*APPL-AS'
THAJBNM ='JOBNAME*OF ORIGIN*USER APPL'
THARSTCK ='USER*MESSAGE*INITIATION*TIME'
THARFDBK ='FEEDBACK*CODE*SET BY*SRM'
THARPRI ='MESSAGE*PRIORITY'
THAMTYPE ='MESSAGE*TYPE*HSM*CODE'
THAERRCD ='ERROR*CODE*SET BY*HSM'
THARINTV1='1ST*INTERVAL*ELAPSED*TIME'
. . .
THARINTV12='12TH*INTERVAL*ELAPSED*TIME'
-Note: TYPETHAL replaced TYPESRHS.
-Mar 24: THAHSM formatted $HEX16, THAHSMR $HEX32.
-Apr 15: THALRESP updated and validated with data.
Datasets THALEXCE,THALVIOL,THALSUMD,THALRESP have these
variables decoded from THAHAM/THAHAMR:
THAHSMCH='HSM*CHANNEL*DEVICE*NAME'
THAHSMIP='HSM*IP*ADDRESS'
THAHSMAX='HSM*IP*AUXILLARY*PORT'
THASMVT ='HSM*VTAM*DEVICE*NAME'
Thanks to Yves Cinq-Mars, IBM Global Services, CANADA.
Change 33.058 Support for CICS User Field DNDBKR/DNDBKR in CICSTRAN.
IMACICVK
UTILEXCL
VMAC110
Mar 8, 2015
Thanks to Michael Creech, Black Knight Financial Services, USA.
Change 33.057 ECHO= option added in Change 32.154 but not documented:
UTILBLDP If you want to see the code that was created by UTILBLDP,
VMXGPARS it can be printed on the LOG by specifying either the new
Mar 10, 2015 ECHO=YES (or ECHO=Y) argument, or with MXGEXIMSG=YES.
Mar 20, 2015 -%LEFT replaced in VMXGPARS.
Change 33.056 Using OPTIONS OBS=0 to create zero-observation datasets
SAGANAL from SMF data, read via the ftp access method, executing
UTILBLDP on ASCII, failed with these messages:
Mar 11, 2015 NOTE: <<< 451 Transfer aborted: send error.
NOTE: >>> QUIT
ERROR: Bad request. Use the debug option for more info
SAS Note http://support.sas.com/kb/14/679.html documents
that OBS=0 can not be used with ftp access method.
Tailoring to build RMFINTRV from only 70s and 72s used
%INCLUDE SOURCLIB(TYPS7072);
to create the TYPE70 and TYPE72GO datasets for input to
create the RMFINTRV dataset with CPU metrics, but using
OPTIONS OBS=0;
%%INCLUDE SOURCLIB(TYPS71,TYPS73,TYPS74,TYPS75,TYPS78);
RUN;
to create the other datasets required for RMFINTRV, but
creating them with zero observations so they take no disk
space, preventing B37 if high volume ID=74 SMF records
were accidentally in the input SMF file. Each TYPS member
opens the SMF filename, although no records are read.
This ancient and inefficient syntax was replaced with
%UTILBLDP(OUTFILE=INSTREAM,
BUILDPDB=NO,
USERADD=7072 71 73 74 75 78,
ZEROOBS=71 73 74 75 78);
%INCLUDE INSTREAM;
-But using UTILBLDP under Linux raised errors because some
macros (%QCMPRES, %LEFT) were not found because SASAUTOS
is not allocated by default under Linus (CH 33.051) and
were unresolved. But Change 31.209 had stated that those
macros were replaced by SYSFUNC calls to avoid the long
standing problem trying to use SAS-supplied SASAUTOS
macros, so UTILBLDP is now free of SASAUTO macros.
Thanks to David F. Salsieder, American Family Insurance, USA.
Change 33.055 Support for CICS User Field USER/MEBTRAN in CICSTRAN.
IMACICVK
UTILEXCL
VMAC110
Mar 8, 2015
Thanks to Jeff Fracas, WiPro, USA.
Change 33.054 Reserved Change Number.
Change 33.053 -Support for z13 updates to type 99 subtype 14, STRONGLY
VMAC99 RECOMMENDED by IBM to be enabled for PROCVIEW CORE to
Mar 8, 2015 allow you to see which LPARs end up where.
Variables were added to both TYPE99EM and TYPE99EP.
Change 33.052 z13 Support updates.
VMAC113 -With PROCVIEW CORE, SMF 113 was INCOMPATIBLY changed to
ASUM113 add COREID etc to support SMT, with changes to MANY of
Mar 14, 2015 the calculated variables that were not in Change 33.023.
Apr 10, 2015 -The SPEED value for the zIIP can incorrectly be zero but
MXG sets SM1132SP=5 for the z13 to circumvent the known
occasional incorrect value.
-With PROCVIEW CPU, non-SMT mode, RNI was incorrect, with
a negative value, that was also corrected by this change.
-Apr 10: zEC12 RNI 1st factor changed from 2.2 to 2.3.
Change 33.051 MXG initialization revised so the FILENAME SASAUTOS isn't
VMXGINIT listed in the list of input source libraries, as Linux by
Mar 3, 2015 default does not have a SASAUTOS filename allocated.
Change 33.050 Graphics code had a not sorted condition caused by the
ANALHSM order of the variables in the BY list. Protection added
Mar 3, 2015 for all missing values in a variable, which caused ODS
graphics to print warning and suppressed changes in the
tick value formats by using XAXIS YAXIS code.
Thanks to Lindsay Oxenham, IBM, AUSTRALIA.
Change 33.049 Three new UTILEXCL reports may be printed. REPORT 00 will
UTILEXCL print all dictionary records read in today from SMF.
Mar 2, 2015 REPORT 00 prints any Transaction Records that do NOT have
a dictionary record, and REPORT 000 shows each of the
APPLIDs that did not have a dictionary record. Both 00
and 000 reports show the SYSTEM and READTIME of those
Transaction Records, since THAT is when the dictionary
record was written, so you know which day's SMF to read
to find those missing dictionary triplet records.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 33.048 -When a GETDSAB error occurred the Reason Code was
ADOCRMFV displayed as NNNN in severe error message RMFV007S.
ASMRMFV The Reason Code is only valid if the Return Code is
Feb 27, 2015 12. In all other cases the Reason Code for this
situation will display as blanks.
-Update documentation for message RMFV007S.
-REQUIREMENT: In order to implement these features the
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Thanks to Wayne Bell, UniGroup, Inc.
====== Changes thru 33.047 were in MXG 33.02 dated Feb 27, 2015=========
Change 33.047 -UTILEXCL updated to skip the CICS/TS 3.2 OMEGAMON CMRDATA
IMACICM0 segment when it is the incorrect length of 200 bytes.
UTILEXCL Change 28.027 discusses, but only told you to install the
Feb 27, 2015 correction; this change circumvents by telling you to use
the IMACICM0 (instead of the normal IMACICMR) to skip.
Thanks to Donald Blaszka, Wipro, USA.
Thanks to Jeff Fracas, Wipro, USA.
Change 33.046 New variables in TYPE70 for z13 MULTITHREADING:
FORMATS
VMAC23 MXG 33.01 CHANGES noted one z13 site had NEGATIVE CPUOVHTM,
VMAC26J2 but that was ONLY IF z/OS on z13 is in MULTI-THREADING MODE.
VMAC26J3 MXG was unaware of IBM's restructuring the RMF type 70 SMF
VMAC7072 record's calculation of CPU BUSY time for the new MT mode,
VMAC71 but this MAJOR CHANGE restructured TYPE70 processing in MXG
VMAC75 to order by CORE_ID and CPU_NUM rather than CPUID/LCPUADDR.
Feb 26, 2015
If NOT Multi-Threading, new metrics were COMPATIBLY ADDED.
Mar 21, 2015
Specifically, if z/OS is IPL'd with LOADxx PROCVIEW CORE, on
a processor that is SMT capable, then whether or not MT is
Active, and even if MT=1 is specified, then the RMF 70 record
is restructured with CORE_ID. While this change in MXG 33.02
updated the TYPE70 dataset, MXG 33.03 is REQUIRED now for the
complete support for the TYPE70PR changes as well.
SMF70MCF ='MULTITHREADING*MAXIMUM*CAPACITY*GP'
SMF70MCFS='MULTITHREADING*MAXIMUM*CAPACITY*ZIIP'
SMF70MCFI='MULTITHREADING*MAXIMUM*CAPACITY*ZAAP'
SMF70CF ='MULTITHREADING*CAPACITY*GP'
SMF70CFS ='MULTITHREADING*CAPACITY*ZIIP'
SMF70CFI ='MULTITHREADING*CAPACITY*ZAAP'
SMF70ATD ='AVERAGE*THREAD*DENSITY*GP'
SMF70ATDS='AVERAGE*THREAD*DENSITY*ZIIP'
SMF70ATDI='AVERAGE*THREAD*DENSITY*ZAAP'
New variables in TYPE70PR
SMF70MTID='MAXIMUM*THREAD*IDENTIFICATION'
SMF70MTTT='MULTI*THREADING*IDLE*TIME'
Variables SMF70CAN/SMF70CTN are now correctly missing
values for an LPAR with no engines (LCPUADDR=. also).
These variables were previously incorrectly populated.
The order of these offline LPARS may be different now.
New variables in TYPE71
SMF71MCF='MULTITHREADING*MAXIMUM*CAPACITY'
And several PIB4 variables are now INPUT as RB8.
TYPE75 SMF75AVL now input as floating point.
New variables in TYPE799 dataset:
R799CUQ ='CU*QUEING*TIME'
R799CN2 ='DEVICE*FLAG*ESTENSION*2'
R799CSC ='SUBCHANNEL*SET*IE'
New variables in TYPE89 dataset:
SMF89CR ='0=CP CREDITS*1=IB CREDITS'
New variables in TYPE9005 dataset:
SMF90ESWT='SWT*VALUE'
SMF90ETWT='TWT*VALUE'
New variables in TYPE23 dataset:
SMF23BBC='ZEDC*UNCOMPRESSEDSED*BYTES*TOTAL'
SMF23BAC='ZEDC*COMPRESSED*BYTES*TOTAL'
New variable in TYPE26J2 and TYPE26J3
SMF26JCR='JOB*CORRELATOR'
In multi-threading mode, the TYPE70PR data is changed
from a one-to-one mapping of CPUID and LCPUADDR to the
CORE_ID, and a core can have 2 CPUs. The CPUID value from
the CPU Data Section is used to select the suffix for
those datasets that have a unique set of variable names
for each LPAR (TYPE70,ASUM70PR,ASUMCEC).
Change 33.045 The SMF 110 ST 1 record descriptions in the ANALID report
VMACID incorrectly stored 110.001 in variable IDANDSUB instead
VMACSMF of values 110.101-110.106, so only '110.001' was printed
Feb 23, 2015 instead of these possible descriptions;
110.1.1:CICS DICTIONARY MNSEGCL=1
110.1.3:CICS TRANSACTION MNSEGCL=3
110.1.4:CICS EXCEPTION MNSEGCL=4
110.1.5:CICS RESOURCE MNSEGCL=5
110.1.6:CICS IDENTITY MNSEGCL=6
While this is only a cosmetic error, these are important
enough that I refreshed 33.01 to add this change.
Thanks to Andre G Amoretto, IBM Global Services, BRAZIL.
====== Changes thru 33.044 were in MXG 33.01 dated Feb 20, 2015=========
Change 33.044 See Change 33.155. These data are now in TYPE74ST.
VMAC74 Corrections for TYPE74MO SCM Structure dataset. The test
Feb 19, 2015 for length had incorrect syntax, but fortunately did not
cause a false positive. There was a missing */ in the
INPUT that misaligned data. Also, it appears, from this
note 2 on page 366 of z/OS V2R1.0 RMF Report Analysis
that TYPE74MO can have zero observations because:
"SCM statistics are only included in the SCM Structure
Summary for those structures that make use of the SCM
storage extension and have set a non-zero maximum SCM
size. If none of the structures is configured to exploit
SCM, the SCM Structure Summary displays message: No
storage class memory data available."
Thanks to Otto Burgess, ATPCO, USA.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.043 DATASET VXUSEACT/VXUSEINT NOT SORTED ERROR because the BY
VMACVMXA lists for the MERGE were not identical.
Feb 19, 2015
Thanks to Chris Weston, SAS Institute, USA.
Change 33.042 Using INCLAFTR=BUIL3005 for JES3 failed with PDB.TYPE25 ,
UTILBLDP not found because UTILBLDP incorrectly blanked _STY25.
Feb 19, 2015
Thanks to Paul Volpi, UHC, USA.
Change 33.041 SMFSRCH did not read the SMFOUT file of selected records,
FORMATS due to an undocumented change in VMXGINIT that replaced
SMFSRCH &SMF with SMF, preventing changing the input DDNAME and
VMXGINIT causing the full input SMF file to be read by TYPESMF,
Feb 18, 2015 287 times! TYPESMF is replaced by a tailored UTILBLDP
Feb 23, 2015 invocation that only processes the selected record types,
Feb 24, 2015 and in only one step. And a PROC FORMAT that could fail
with overlapped values was replaced in the new design.
The selected record types are reported, and if you have
user SMF records selected, you will need to use USERADDS
%SMFSRCH(USERADDS=xxxx/nnn yyyy/mmm) to tell MXG which
xxxx product has which nnn SMF record type.
-Format MGSMFPR maps SMF Record Type to Product Suffix for
the UTILBLDP USERADD= argument.
-Feb 23: Harmless APPARENT UNRESOLVED ADDIDS if no records
were selected corrected.
-If SMFSRCH failed to find your text in SMF, it generated
a call to UTILBLDP with BUILDPDB=NO and USERADD= to null
which caused UTILBLDP to fail with MACRO variables not
found. Now if no records are found, it terminates with:
MXGNOTE: NO RECORDS WERE FOUND CONTAINING &LOOKFOR;
MXGNOTE: SMFSRCH WILL BE TERMINATED;
and if UTILBLDP has BUILDPDB=NO and USERADD=blank it will
terminate with:
MXGERROR: YOU SPECIFIED BUILDPDB=NO BUT DID NOT;
MXGERROR: SPECIFY A USERADD= SO UTILBLDP DOES;
MXGERROR: NOT HAVE ANYTHING TO DO AND WILL SET;
MXGERROR: THE OUTFILE TO A NULL DATASET;
and since the OUTFILE is NULL a following include of that
file will not fail since it is empty.
Change 33.040 Support for SystemWare XPTR 5.2 subtype 140 record which
VMACXPTR now contains what used to be in their subtype 40 record.
Feb 18, 2015
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 33.039 Summarization of Mobile Work CSV files to combine hours
MOBWRKSU that were split between two CSV files. All files from a
Feb 19, 2015 family are concatenated to the //CSVINPUT DD and the
summarized CSV data is written to //CSVSUMRY DD.
-CSVSUMRY was originally DISP=MOD, to collect the input
from four sources, but DISP=MOD can not be used for a
PDSE member, so the MOD file is written to an internal
catalog file, which is then copied to //CSVSUMRY.
Change 33.038 Change 30.082 added protection for SMF type 60 record
VMAC60 with no VVR segment, but the protection was insufficient,
Feb 17, 2015 and an INPUT STATEMENT RECORD EXCEEDED error could still
occur. Now, the remaining length is verified.
Thanks to Tabbitha Flink, FirstData, USA.
Change 33.037 Support for HP MeasureWare for Linux.
ADOCMWLX -ADOCMWLX has the REPORT command to extract the fields MXG
EXMWLXAP expects, so it must be used to create MXG's input data.
EXMWLXCO -CPU Times in the MWLXGLOB dataset are presumed to be the
EXMWLXDS per-CPU values in the record; they have been multiplied
EXMWLXGL by the number of CPUs. Other times are as found.
EXMWLXLA -ALL STORAGE variables contain BYTES and are formatted
EXMWLXPR with MGBYTES for total bytes and MGBYTRT for byte rates.
EXMWLXTT Fields in the record in KB have been converted to bytes.
IHDRMWLX -IHDRMWLX or &MACMWLH can be used to select which TYPE
IMACMWLX records are to be read.
TYPEMWLX
TYPSMWLX
VMACMWLX
VMXGINIT
Feb 13, 2015
Feb 20, 2015
Thanks to Roman Gudz, Penske, USA.
Change 33.036 -RACF SMF 80 record, SMF80TP2=301, Command Segment Data
VMAC80A segments "CTOKENKY" and "CTOKENTM" are supported.
Feb 12, 2015 -The variable length TOKxxxxx fields do not document their
max length, and MXG can get INPUT RECORD EXCEEDED errors
if an input field is longer than the defined length in
its $VARYINGnn informat. These variables are increased to
$VARYING64 to hopefully avoid the error condition:
TOKCOMPANY TOKCOUNTRY TOKFNAME TOKMNAME TOKLNAME
TOKMCARRIER TOKMCANSWR1 TOKMCANSWR2 TOKMCANSWR3
TOKMCBADCNT
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 33.035 RACF SMF 80 record, SMF80TP2=301, Command Segment Data
VMAC80A segment "AUTOGID" decodes 4 variables but their contents
Feb 11, 2015 is not known at this time:
TOKMAUTOGID01 TOKMAUTOGID02 TOKMAUTOGID03
TOKMAUTOGID04
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 33.034 The variables SYSABEND and USRABEND were created but not
VMACIMS decoded in the IMS56FA transaction dataset. Now, COMPCODE
Feb 10, 2015 is decoded into these two useful IMS transaction abend
code variables in all record that contain it.
Thanks to Raymond J. Smith, OPTUM, USA.
Change 33.033 WPS 3.1.1 maint level 731 will now write multiple output
WEEKBLD datasets to sequential format data libraries without the
Feb 10, 2015 need to use DISP=MOD. Without MOD and 731, each write
overwrote the prior, leaving only the last dataset.
Change 33.032 -Variables SMF70WTI/SMF70WTS/SMF70WTU (new WTI-s) were ok
VMAC7072 in dataset TYPE70EN, but were always zero in TYPE70PR.
VMXG70PR TYPE70PR is now corrected, but those values only exist
Feb 8, 2015 in the "THIS PART" TYPE70 records, so you must read ALL
system's TYPE70s to properly populate these variables.
They are always missing in the LPARNAME='PHYSICAL's
-VMXG70PR is updated so the PDB.ASUM70LP and PDB.ASUMCELP
LPAR Summary datasets contain those variables, but only
if RMF type 70 records from ALL systems are input.
Change 33.031 Using BLDSMPDB and FORCEDAY to re-run a daily job could
BLDSMPDB incorrectly calculate the start of week, depending on the
VMXGALOC case of your typed code. Now when you specify FORCEDAY
Feb 19, 2015 to rerun SMF data, ZDATE will be set to FORCEDAY+1.
Feb 26, 2015 Error was introduced in MXG 32.11, Change 32.253.
And all of the tests where casing can impact are now
now protected with %UPCASE compiler functions, but the
members remain lower case because of earlier problem in
casing in Linux systems; it might not still be required,
but not worth the exposure and time spent for no value.
Change 33.030 Mainview for MQ 5.2 support is corrected; the wrong byte
VMACBBMQ was used to detect compressed records, causing spurious
Feb 5, 2015 messages that individual records were compressed.
Thanks to Greg Tuben, BMC Software, Inc., USA.
Change 33.029 The iSeries a/k/a AS400 QAPM "suffix" was replaced by the
TYPEQACS "QACS" suffix years ago, but those old QAPM members are
Feb 4, 2015 now removed; they were causing false positives in the MXG
QA tests, and served no purpose. All of the xxxxQAPM are
deleted, and these exit members that weren't carried into
the QACS product were also deleted.
dddddd exit dddddd exit
token member token member
_WQAPASY EXQAPASY _WQAPPOO EXQAPPOO
_WQAPBSC EXQAPBSC _WQAPRWS EXQAPRWS
_WQAPDDI EXQAPDDI _WQAPSTD EXQAPSTD
_WQAPECL EXQAPECL _WQAPSTL EXQAPSTL
_WQAPFRL EXQAPFRL _WQAPSTY EXQAPSTY
_WQAPIDL EXQAPIDL _WQAPX25 EXQAPX25
_WQAPJOB EXQAPJOB
_WQAPLAP EXQAPLAP
While the SUFFIX QAPM is retired, the names of all of the
datasets created by TYPEQACS are unchanged and all start
with QAPMxxxx.
Change 33.028 Support for EDS User SMF Record from NETMENU Program,
COMPALL creates new dataset:
EXTYNTMU DDDDDD DATASET DESCRIPTION
FORMATS TYNTMU NETMENU SMF NETMENU RECORD DATABASE
IMACNTMU
TYPENTMU
TYPSNTMU
VMACNTMU
VMXGINIT
Feb 3, 2015
Thanks to Joe Babcock, General Motors, USA.
Change 33.027 Example from SAS Help to delete all GLOBAL'ed USER MACRO
VMXGDELV Variables, used only in the QA JOB when new code caused
Feb 3, 2015 an unexplained error (the "TURN SPOOL ON" message) in
Step 34, but there was no error when Step 34 ran first.
By clearing all Global Macros before Step 34, the actual
unresolved macro variable error was then unmasked, but
maybe only accidentally! To clear and re-initialize
%VMXGDELV;%INCLUDE SOURCLIB(VMXGINIT);%VMXGINIT;
is needed so that the GLOBAL statement in VMXGINIT is
re-executed. And because %VMXGDELV cleared the flag
variable MXGINIT, %VMXGINIT prints the Welcome To MXG
message, instead of the the re-initialization message.
Change 33.026 Reserved Change Number.
Change 33.025 -Variable QBSTBPIN='BUFFER*POOL*IO*INTENSITY' based on IBM
ANALDB2R Tivoli calculation is added to DB2STATB dataset and also
VMACDB2 ANALDB2R reports the value.
VMXGDBSS QBSTBPIN=SUM(QBSTRIO,QBSTSPP,QBSTLPP,QBSTDPP,QBSTIMW,
Feb 3, 2015 QBSTWIO)/QBSTVPL;
Feb 26, 2015 -ASUMDBSB now reports both average and maximum QBSTBPIN.
-Debugging test IF SYSTEM='SYSG' removed from DB2B1 Buffer
Pool Statistics reports
-Feb 26: Protected QBSTBPIN from divide by zero error when
QBSTVPL=0 when no buffers were allocated in the pool.
Thanks to Tim Hare, Hare Systems Support, USA.
Thanks to Jonathan Bathmaker, Southern California Electric, USA.
Thanks to Tom Buie, Southern California Electric, USA.
Change 33.024 Test added to detect ANY work in service class SYSOTHER.
UTILRMFI The UTILRMFI utility is cited in error messages that your
UTILWORK CPUTM does not match CPU72TM when building RMFINTRV: run
VMXGRMFI UTILRMFI to examine your VMXGRMFI workload definitions to
Feb 3, 2015 find what work was overlooked. However, if there is any
work in the SYSOTHER Service Class (which itself is an
error in your site's WLM Classification Rules), that may
cause the mismatch, since that work probably also doesn't
have a Reporting Class. Now you are alerted of the WLM
definition error. Note that SYSOTHER is also undesired
because that work is MTTW DISCRETIONARY, so whatever is
falling thru is NOT going to get much service.
Change 33.023 Support for new z/OS z13 hardware metrics (COMPATIBLE):
FORMATS -APAR OA43493 RMF Support Cryptographic Express5S cards:
VMAC30 New Crypto Processor types in R7023CT/24CT/25CT variables
VMAC7072 decoded by $MGRMFCY/MGRMFCZ formats in datasets TYPE7002,
VMAC74 TYPE70X2, and TYPE70Y3.
VMAC113 New variables in TYPE70Y2 dataset:
VMACVMXA R702AMGB='DATA BYTES*FOR*GENERATE*AES MACS'
Jan 29, 2015 R702AMGC='CALLS TO*GENERATE*AES MACS'
ASUM113 R702AMGI='INSTRUCTIONS*TO GENERATE*AES MACS'
Feb 25, 2015 R702AMVB='DATA BYTES*FOR*VERIFIED*AES MACS'
May 21, 2015 R702AMVC='CALLS TO*VERIFY*AES MACS'
R702AMVI='INSTRUCTIONS*TO VERIFY*AES MACS'
R702DEGC='CALLS*TO GENERATE*ECC*SIGNATURES'
R702DEVC='CALLS*TO VERIFY*ECC*SIGNATURES'
R702DRGC='CALLS*TO*GENERATE*RSA*SIGNATURES'
R702DRVC='CALLS TO VERIFY*RSA*SIGNATURES'
R702FPDB='DATA BYTES*DECIPHERED*USING FPE'
R702FPDC='CALLS TO*DECIPHER*USING FPE'
R702FPDI='INSTRUCTIONS*TO DECIPHER*USING FPE'
R702FPEB='DATA BYTES*ENCIPHERED*USING FPE'
R702FPEC='CALLS TO*ENCIPHER*USING*FPE'
R702FPEI='INSTRUCTIONS*TO ENCIPHER*USING FPE'
R702FPTB='DATA BYTES*TRANSLATED*USING FPE'
R702FPTC='CALLS TO*TRANSLATE*DATA*USING FPE'
R702FPTI='INSTRUCTIONS*TO TRANSLATE*USING FPE'
-APAR OA44502 RMF Support Coupling Channel Path Type CS5:
Format $MG074OM updated and applied to variable R744HOPM
in dataset TYPE74HO.
-APAR OA30563, Enhanced SMF 30 and 89 recording; metrics
listed in the updated APAR were added in Change 28.175.
The APAR adds new MAXEVENTINTRECS with zero default,
so the new capacity changed interval 30/89 records will
not be created with that zero value.
-APAR OA35175, SMFPRMxx options DSPSIZMAX; the TYPE23
dataset updates were actually made in Change 29.177.
-APAR OA45985, RMF support for zHYPERWRITE in 2107 CU.
Adds new variable HYPERWRT='Y' to TYPE74 if requested.
-SMF 113 has new z13 counters and revised calculations,
including RNI and its component variables:
RNI=2.6*(0.4*L3P+1.6*L4LP+3.5*L4RP+7.5*MEMP)/100;
Corrections made March 5. However, the new counter
descriptions do not yet exist.
Note that variables L15P L2LP L2RP are always missing
values on the z13.
Without this change, negative RNI values for z13 even in
non-SMT mode were created.
-May 21: ZEDC added to the label for those eight metrics.
Change 33.022 A JES3 site TERSE with UNPACK failed with DCB attributes
DOC //SYSPRINT DD RECFM=FBA,LRECL=133,BLKSIZE=13232, but with
Jan 28, 2015 only the message AMA504I RETURN CODE: 12 and no clue.
Removal of the DCB attributes successfully untersed.
However, it was NOT the non-multiple of LRECL for BLKSIZE
that was the error. A prior IDCAMS step had a //SYSPRINT
DD that JES3 made into a temporary DSNAME, and the same
DSNAME was then used in the TERSE step, but the different
BLKSIZE caused the conflict and RETURN CODE. That's my
story and I'm stikin' to it until I learn more about why
JES3 passed a temporary DSNAME for //SYSPRINT. However,
there is NO need for DCB attributes on SYSOUT= DDnames,
so to avoid ANY future exposure, I've removed all DCB
from those DDs in all MXG examples.
-All //OUTPUT DDs for PGM=FTP were removed, as //SYSPRINT
is used for all messages when there is no //OUTPUT DD.
Thanks to Tom Adams, State Farm Mutual Automobile Insurance, USA.
Change 33.021 -If no Reporting Classes were defined, ASMRMFV skipped all
ADOCRMFV RCD tables as invalid due to a faulty calculation, with a
ASMRMFV RMFV035W **WARNING:159 RCD TABLES SKIPPED DUE TO ERRORS
CLRMFV and ultimately set a Return Code 16. Should be very rare
JCLRMFV since most sites DO define Reporting Classes.
JCLCRMFV -Change 32.055 did not fully resolve the RED table issue:
JCLdRMFV RMFV035E:1 RED TABLES SKIPPED DUE TO INVALID ID OR FLAG
Jan 26, 2015 the Invalid Resource bit may be set for Processor entries
in the RED table in a MINTIME interval due to normal
processor change events, so these are not true RED table
errors and ASMRMFV was incorrectly issuing an RMFV035W
warning message and Return Code 16 for this transient and
insignificant return code.
-ASMRMFV now will NOT alter the Return Code, issuing a
distinct RMFV035I information message for this condition
regardless of the setting of the TABERR= option:
RMFV035I -IGNORED-: nnnnn RED TABLES SKIPPED DUE TO
INVALID PROCESSOR RESOURCE FLAG---
-After Change 32.289 the number of Policy Indexes Used
in informational message RMFV028I as triggered by the
INDEXES option could be incorrect.
-The MXG table was shown in the Detail Report with the
NOSHOWZERO option in effect even when zero records were
output. This table is only output once for the first
RMF III data set processed.
-The RMFV006I FILTER message for ASI, DVT, and CFI table
specific options is now always shown even if none of
these tables are selected for a minor performance gain,
as selection logic for what to display was revised.
-Unnecessary checks for I/O errors on the SYSPRINT file
are removed. An ABEND occurs with any I/O error on this
file so the additional checks were unneeded.
-Updates for revised messages RMFV006I and RMFV035I are
made to Section 12 "Messages" in ASMRMFV and ADOCRMFV
documentation members.
-REQUIREMENT: In order to implement these features the
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Thanks To John Wynn, IBM Global Technology Services, USA.
Change 33.020 AS/400 iSeries fixed-length records change lengths with a
VMACQACS new version, so you may have to change the LRECL in your
Feb 2, 2015 FILENAME statement on ASCII or in your JCL on z/OS.
The length change is usually detected with MXG messages
on the log with "PAD RECORD FOUND AND DELETED".
Now, you can specify %LET MXGABND=NNNN; in //SYSIN to
force USER ABEND NNNN if more than 10 PAD records
are found. Use 0001 thru 4096 for the NNNN value.
New messages identify the filename and dsname being read.
Thanks to Raymond J. Smith, OPTUM, USA.
Change 33.019 Variables TOKQUEST1-TOKQUEST3, TOKCANSWR1-TOKCANSWR3 and
VMAC80A CBADCNT are added to dataset TYPE80TK.
Jan 21, 2015
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 33.018 -RACF TYPE8025 Record with DTP=30 segment with 'C0'X value
VMAC80A for the status ('80'x=ACTIVE,'40'x=BACKUP) caused ERROR:
Jan 21, 2015 INVALID RACF ID=80 RACFTYPE=30 SEGMENT SKIPPED, because I
Feb 5, 2015 didn't realize a DSNAME could be both ACTIVE and its own
Feb 23, 2015 BACKUP, so I had created two sets of variable names, with
RACFDBxx for the ACTIVE segment and RACFDKxx for BACKUP.
Test for '80'x first, now stores into RACFDBxx variables,
or '40'x or 'C0'x store into RACFDKxx variable names.
-For BACKUP-ONLY ('40'x) segments, both UNIT NAME/VOLSER
are not populated, while both are in the ('C0'X) record.
-Feb 23: TOKMPROCUSERMAX variable decoded.
See Change 33.084.
Thanks to Karl Lasecki, American Chemical Society, USA.
Change 33.017 Documentation only! Example added that sends all of the
UTILBLDP DB2ACCTx datasets to a single //DB2ACCT LIBNAME, and uses
Jan 21, 2015 MACKEEPX in UTILBLDP to control dataset destinations and
sorts and could also be used to limit variables. The
DB2KEEP= parameter in BLDSMPDB is used to tailor the
number of generations retained to control the storage
needed for these normally-large datasets (ASCII only with
AUTOALOC=YES).
Change 33.016 Support for z/VM 6.3 on z13 processor (INCOMPATIBLE).
VMACVMXA -The PRCMFC 5.13 record's new CSVN=4 hardware counters
Jan 20, 2015 caused MXG code to fail with "BROKEN CONTROL RECORD".
Circumvented by skipping the extra 24 bytes, await
the actual documentation of those new counters before
decoding.
IN PROGRESS.
Change 33.015 DCOLLECT variable DCDCREAT-DATETIME*WHEN*DATASET*CREATED
VMACDCOL is added to dataset DCOLDSET; the time part wasn't in the
Jan 20, 2015 original record, but was added by APAR OA30006 in 2009.
DCDCREAT is only populated if both DCDCREDT and DCDTIMEC
are non-zero.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.014 Support for z/13 processor increase to 85 LPARs was added
VMAC7072 in MXG 32.06, Change 32.162, July, 2014, changing the
Jul 27, 2015 statement to ARRAY S70LPCP {86} _TEMPORARY_; to support
Jan 19, 2015 85 "real" LPARs plus the PHYSICAL "LPAR". Support for
255 engines was added silently in MXG 31.04 in 2013.
Change 33.013 Support for CTG Version 9.1 (COMPATIBLE).
EX111WS -Variable added to CTGSE System Environment dataset:
EX111WSX CTGC31MAX='LIMIT OF*USED*MEMORY*ELOAL'
IMAC111 -Two new segments, WS and WSX create new datasets:
VMAC111 DDDDDD DATASET DESCRIPTION
VMXGINIT 111WS TY111WS WEB SERVICE ALL
Jan 20, 2015 111WSX TY111WSX WEB SERVICE INSTANCE
Thanks to David Marone, SGS, ITALY.
Change 33.012 Unused Change Number.
Change 33.011 -INPUT STATEMENT EXCEEDED, DFSORT SMF 16, OFFSTAT=640 and
VMAC16 LENSTAT=64, but record is TRUNCATED with LENGTH only 636,
Jan 14, 2015 so there is no STAT segment in the record.
A PUTLOG ERROR message is written for the first three
instances, the TYPE116 dataset is output, but variables
RECIND01-RECIND16 will be missing values. This text will
be revised when an APAR exists. DFSORT Release 2.01.
-These variables added in DFSORT 2.01, but not listed in
the manual's changes, nor marked as new with the expected
vertical bars, are now added to dataset TYPE16:
ICEDYINC='INITIAL*INCREMENT'
ICEDYMAX='FINAL*EXPMAX*DYNAMIC*VALUE'
ICEDYOLD='FINAL*EXPOLD*DYNAMIC*VALUE'
ICEDYRES='FINAL*EXPRES*DYNAMIC*VALUE'
ICETUNE ='TUNE*VALUE*IN*EFFECT'
Thanks to Kerry Sommers, John Deere, USA.
Change 33.010 No errors have been reported, but ARRAY WORDS statements
VMAC112 raised conflicts if TYPE112/TYPEEZAM/TYPETMNT are read
VMACEZSM together; only one ARRAY NAME can be used in a DATA step.
VMACTMNT These are temporary arrays for parsing with different
Jan 12, 2015 dimensions and variable lengths, so the ARRAY NAMEs are
made unique to eliminate the exposure.
Change 33.009 IBM Updates to SMF 14/15 for zEDC Compression Indicator
FORMATS SMF30XF1 adds values and is now decoded by $MG014ED:
VMAC1415 '0'='0:SIZE VALUES INVALID'
Jan 12, 2015 '1'='1:COMPRESSION REJECTED'
'2'='2:ZEDC WRITTEN UNCOMPRESSED'
'3'='3:ZEDC SOFTWARE DECOMPRESSED'
and new SMF14CMPTYPE='Compression Type' variable is
added and decoded by MG014CT format:
0='0:NOT COMPRESSED/UNKNOWN'
1='1:GENERIC'
2='2:TAILORED'
3='3:ZEDC'
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.008 ONLYCIDS example creates ONLY the PDB.CICDS Dispatcher
ONLYCIDS Statistics dataset, that contains interval CPU time for
Jan 12, 2015 each CICS Interval, and can be used for CPU Time Metric
in IBM Mobile Work Discount
Thanks to Scottie Long, Navy Federal Credit Union, USA.
Change 33.007 TYPERMF incorrectly requires a //PDB DD because it was
TYPERMF not updated when the 2005 "SPLIT70 logic" created the
Jan 11, 2015 TYPE70EN dataset, written to PDB by default. Like the
two existing %LETS for PTY70 and PTY70PR in TYPERMF,
a %LET PTY70EN=WORK; is needed so //PDB is not used.
Thanks to George Baranoff, Safeway, USA.
Change 33.006 -SAS Error "No MKLEs found" and "ERROR: VM 1319:" is a
DOCUMENT virtual storage issue, usually too small a REGION= size,
Jan 11, 2015 but also a known SAS Version 9.2 defect, see below.
-The MXG QA "BUILDPDB" JOB (with a few added SMF types)
increased from 130MB in 31.31 to 140MB in 32.32.
-Each new MXG version adds new variables, datasets, and
code which cause the REGION size to increase a little.
Unfortunately, the z/OS REGION is a LIMIT not a BENEFIT,
so you get to periodically increase the REGION= value,
and/or check with your site's "REGION SIZE POLICE" to
find their actual limit for REGION=0M, and/or what JOB
CLASS/RACFUSER will let you allocate the REGION needed.
-There is NO ACTUAL RESOURCE "consumed" by REGION size.
-The actual step region size is in the IEF032I message on
joblog for each step: EXT: 130,852K SYS: 12,088K
EXT is the region size "Above the 16MB Line" and SYS is
the size of the Private Area on this system. Their sum is
the region size allocated to this step, or
130,852+12,088=142,940K=140MB REGION size.
-The SAS log shows "And 130852K Above the Line" matching
the EXT value exactly. SAS also reports a value for the
"Below the Line", but it is (small) amount used, not the
actual size of the Private Area, which must be included
in the REGION limit.
-One site moving from an ancient MXG version still had
REGION=6M on their JOB Card from the prior millennium.
You get the system default of 32MB Above the Line plus
the Private Area, or about 42MB, but because their daily
job was split into parallel pieces, it actually had
worked (accidentally?) until 32.32.
-SAS needs REGION size for referenced FORMATS, for dataset
buffers, for arrays, for SAS VIEWs, and for the CICSIFUE
SMFEXIT=CICS INFILE exit to load.
-SAS Version 9.2 is Class C support from SAS and it had
fatal errors in virtual storage on z/OS that were ONLY
corrected by SAS 9.3 or 9.4.
-One 9.2 site's tailored BUILDPDB ran in 130MB with 30.01,
needed 159MB with 32.32, but when the CICSIFUE exit was
enabled, the job failed and IEF032I reported only 97MB
had been allocated. Rerun with 32.32 and SAS 9.4 and
WITH the exit needed 179 MB, and ran with no error.
-MXG 33.03 QA BUILDPDB on z/OS 2.1, SAS 9.4(TS1M2) needed:
142M with View Disabled and no CICS EXIT Enabled.
147M with the View Enabled (default), and no Exit.
149M with both the VIEW (ID, for ANALID) and with EXIT.
Copied from NEWSLTRS:
SAS USER U1319 ABEND if EXITCICS/CICSIFUE and /VIEW=_WCICTRN used,
or with BUILDPDB, if back level SAS 9.1.3 SP4 without Hot Fix 37166
is used. SAS Error is corrected in SAS 9.2.
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).
But the same error message will occur with BUILDPDB due to the view
for VMACID. This error can be circumvented by inserting this
statement in your //SYSIN
%LET VWVMACID=;
which disables that sole VIEW in the BUILDPDB.
Change 27.260 is a VERY-EXPENSIVE-ON-Z/OS-alternative to EXITCICS.
Thanks to Jerry Massey, Compuware, USA.
Thanks to Dave Greene, Compuware, USA.
Change 33.005 Support for APAR OA45767 adds compression statistics for
VMAC30 the zEDC compression engines to the TYPE30_4,_5,_V,_6,
BUILD005 PDB.STEPS and PDB.SMFINTRV datasets, and these variables
BUIL3005 (plus the _INST_ variables added by Change 31.153) are
Jan 9, 2015 now also summed into the PDB.JOBS dataset.
SMF30_US_COMPRREQ SMF30_US_COMPRREQ_PROB
SMF30_US_DEF_COMPROUT SMF30_US_DEF_UNCOMPRIN
SMF30_US_EXECTIME SMF30_US_INF_COMPRIN
SMF30_US_INF_DECOMPROUT SMF30_US_QUEUETIME
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 33.004 -(Archaic) SAS V9.1.3 JCLTES91 messages with MXG 32.32.
JCLTES91 Running the JCLTES91 with SAS V9.1.3 & MXG 32.32:
VMACIDMJ -VMACIDMJ contains FORMAT RECDATE DATE11.; which is not
Jan 9, 2015 supported in SAS V9.1.3; if you use VMACIDMJ (unlikely!)
change to DATE9.
-JCLTES91 TESTOTHR step needed //IMSMERGE DD DUMMY after
the existing //IMSLOG DD DUMMY. Added.
Thanks to Lee Lewis, SPVM Quebec, CANADA.
Change 33.003 Support for user CICS USERMOB and USEREOT segments.
IMACAAAA -UTILEXCL was updated for these two user fields.
IMACICVI -Testing exposed that the MXG "EXCLUDED FIELDS" detection
IMACICVJ in TYPE110 does NOT work if there are optional segments
PRODTEST that INCREASE the MCTSSDRL, since MXG can only detect if
UTILEXCL MCTSSDCN/MCTSSDRL are SMALLER than the default size for
VMAC110 that SMFPSRVR. UTILEXCL is now updated to not only read
Jan 8, 2015 the Dictionary records, but also any CICSTRAN records to
Jan 15, 2015 produce two new reports of any APPLID/TRIPLETs that are
Jan 19, 2015 found in transactions but don't have Dictionary records.
-For completeness, there are two additional tests in the
TYPE110 processing that can detect excluded fields:
a. TASKNR is a Packed Decimal, and that will be a
missing value if the INPUT is mis-aligned.
Unfortunately, TASKNR is near the front of the
record, and most Excludes are newer fields further
into the record.
b. A test for CPUTM GT 10*ELAPSTM, because CPU fields
are further into the record. See Change 29.076 why
the factor of 10 is needed (for knee-capped CPs).
Thanks to Rob Hollingum, HSBC, ENGLAND.
Change 33.002 z/OS 2.1 overlooked variables are added in TYPE74OM.
VMAC74 OMVSCLMN='MIN SHARED*STORAGE MB*ALLOCATED PER CYCLE'
Jan 8, 2015 OMVSCLMX='MAX SHARED*STORAGE MB*ALLOCATED PER CYCLE'
OMVSCSLR='ACCUM SHARED*STORAGE*ALLOCATED*INTERVAL'
OMVSMQDS='MAX*QUEUED SIGNALS*ALLOWED*PER PROCESS'
OMVSMSLR='MAXIMUM*STORAGE MB*AVAIL*SHAREDM'
OMVSOLMN='MIN ATTEMPTS*EXCEED MAXIMUM*REGION PER CYCLE'
OMVSOLMX='MAX ATTEMPTS*EXCEED MAXIMUM*REGION PER CYCLE'
OMVSOQDS='ACCUM ATTEMPT*EXCEED MAX*QUEUED*INTERVAL'
OMVSOQMN='MIN ATTEMPT*EXCEED MAX QUEUED PER CYCLE'
OMVSOQMX='MAX ATTEMPT*EXCEED MAX QUEUED PER CYCLE'
OMVSOSLR='ACCUM ATTEMPTS*EXCEED MAX*INTERVAL'
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 33.001 Typo, variable ESTBUTES corrected to ESTBYTES.
ANALTLMS
Jan 6, 2015
Thanks to Pierre-Pascal Joulin, SOCGEN, FRANCE.
LASTCHANGE: Version 33.
=========================member=CHANGE32================================
/* COPYRIGHT (C) 1984-2015 MERRILL CONSULTANTS DALLAS TEXAS USA */
ANNUAL: MXG Version 32.32 is dated Jan 6, 2015, thru Change 32.309
MXG Version 32.12 was dated Dec 23, 2014, thru Change 32.304
MXG Version 32.11 was dated Dec 2, 2014, thru Change 32.283
First MXG Version 32.11 was dated Dec 1, 2014, thru Change 32.281
MXG Version 32.10 was dated Oct 16, 2014, thru Change 32.240
First MXG Version 32.10 was dated Oct 10, 2014, thru Change 32.237
MXG Version 32.09 was dated Sep 9, 2014, thru Change 32.218
MXG Version 32.08 was dated Aug 21, 2014, thru Change 32.201
MXG Version 32.07 was dated Aug 3, 2014, thru Change 32.181
MXG Version 32.06 was dated Jul 21, 2014, thru Change 32.170
MXG Version 32.05 was re-dated Jun 18, 2014, thru Change 32.138
First MXG Version 32.05 was dated Jun 16, 2014, thru Change 32.136
Actual MXG Version 32.04 was dated Apr 27, 2014, thru Change 32.101
First MXG Version 32.04 was dated Apr 23, 2014, thru Change 32.099
MXG Version 32.03 was dated Apr 3, 2014, thru Change 32.078
MXG Version 32.02 was dated Feb 26, 2014, thru Change 32.042
MXG Version 32.01 was dated Feb 6, 2014, thru Change 32.025
ANNUAL MXG Version 31.31 was dated Jan 20, 2014, thru Change 31.296
MXG Newsletter SIXTY-TWO was dated Sep 1, 2013.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 32.32 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 32.32.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG Version 32.32 dated Jan 6, 2015, thru Change 32.309.
Major enhancement added in MXG 32.32, dated Jan 6, 2015:
TYPETMO2 32.309 Support for ASG TMON/CICS Version 4 INCOMPATIBLE.
TYPE50 32.307 TYPE50 LENGTH=254, INPUT STATEMENT EXCEEDED.
BLDSMPDB 32.306 RUNDAY=NO incorrectly executed the PDBAUDIT report.
Major enhancement added in MXG 32.12, dated Dec 23, 2014:
Errors corrected:
VMACSMF 32.300 MXG 32.11-WPS ONLY. CANT READ SMF ON ASCII, MXG ERROR
TYPEWECR 32.301 WPS ONLY. DATA SET "WORK.WEBSCRAU" NOT FOUND.
TYPE112 32.295 Long BY list, HOST SORT CAN NOT BE USED, MXG error.
UTILVREF 32.295 QA UTILVREF now detects long BY lists for HOST SORT.
TYPENDM 32.284 NDM 'PT' INVALID SUBSTR, A#/C#/D#/S$/U#/UK supported.
TYPE22 32.288 MXG 32.03-MXG 32.11 Type 22 UNKNOWN SECID=40 error.
New Support:
TYPE105 32.291 Support for GDPS SMF 105 2-byte fields APAR PI26702.
TYPEIMS7 32.290 Larger DLREXTIM time now used for (archaic) IMSCPUTM.
ASMIMSL6 32.290 Larger DLREXTIM time now used for (archaic) IMSCPUTM.
VGETJESN 32.296 &MACJESN can delete records by TYPETASK (e.g. OMVS).
ASUMDB2A 32.293 Warning when "Rollups" are detected, summarized data.
AUTOEXEC 32.292 Old MXG SORTSIZE=400M removed, default SORTSIZE used.
BLDSMPDB 32.299 %PDBAUDIT invocation can capture ALL "PDBs".
PDBAUDIT 32.297 %PDBAUDIT can be bypassed with PRINTAUDIT=NO.
Major enhancement added in MXG 32.11, dated Dec 2, 2014:
MOBILWRK 32.279 MOBWRK02,MOBWRK05 enhanced, STARTHR in all merges.
PDBAUDIT 32.274 Report enhanced, SORTEDBYSIZE, commas in numbers.
SMFINTRV 32.271 New SMFINTRV member creates PDB.SMFINTRV from SMF.
IHDRBVIR 32.270 The IHDRBVIR "BVIR Header" exit was overlooked.
ANALDSCK 32.268 New "DSNAME Check" reads all SMF with a DSNAME.
ANALID 32.257 ANALID reports 78.2.1 and 78.2.2 VSTORE enabled.
TYPEVMXA 32.254 Support for z/VM concatenated MONWRITE mult systems.
TYPEEZSM 32.252 Support for EzSM 4.2.0 creates new datasets.
ASMRMFV 32.250 Further ASMRMFV parsing/command/filtering updates.
TYPEBVIR 32.249 Support for BVIR Version 2 short '32'x Record.
TYPECLAR 32.247 Support for EMC's Clarion Flare Firmware V26-V33.
UTILEXCL 32.265 Support for 2nd CMODNAME='USER',CMODHEAD='USER'.
TYPE119 32.278 TYP11902 TTTTLSxx variables misaligned.
TYPE7072 32.277 R7023MEG/R7023CRT were not multiplied by R7024SF.
TYPENDM 32.275 Variable NDMRTCPU in NDMRT was incorrectly INPUT.
TYPERACF 32.273 ASCII only. Variable LIOBTIME in RACF0200 wrong.
TYPEXAM 32.272 ERROR IN XAMSYS, SEGNAME=CMS, MXG coding error.
ODS 32.269 Documentation of two common ODS errors on z/OS.
TYPE7072 32.267 TYPE70X2 variables CRYAC1U/CRAM3U need mult 100.
WEEKBLxx 32.264 WPS ONLY. Test for &SYSVER GE 6 s/b &SASVER GE.
Many 32.263 MXG PROC COPY have MEMTYPE=DATA, ITEMSTORE fails.
BLDSMPDB 32.262 WTD with WEEKKEEP, or WTD with AUTOALOC, failed.
VMACDB2H 32.261 DB2 variable JOB could be incorrect LENGTH $12.
VMXGDSNL 32.260 MXG on Linux to process AS400 data, slash issue.
TYPE102 32.259 IFCID=220: Invalid Argument corrected.
MONTHxxx 32.253 BLDSMPDB,MONTHBLD, z/OS, out of order daily GDGs.
TYPE30 32.251 Variables EXCP/IOTM-NODD/TODD/TOTL inconsistent.
BLDSMPDB 32.248 WPS, z/OS, BLDSMPDB, RECFM=S370VBS not supported.
TYPE7072 32.246 TYPE72GO's PERFINDX can be missing when it's large.
MOBWRK73 32.244 MOBWRK73 in 32.10 incorrectly required //PDB DD.
TYPEVMXA 32.243 z/VM Interval ENDTIME wrong if first 0.1 not CPU 0.
TYPEVMXA 32.243 Each START MONITOR message is a LOST interval.
Major enhancement added in MXG 32.10, re-dated Oct 16, 2014:
TYPE6 32.240 First 32.10 - OS 2.1 TYPE6 PRINTWAY records caused
INPUT EXCEEDED error. This is the re-date reason.
TYPE120 32.239 WebSphere SMF 120 ST 9 TYP1209E DELTA120TM negative.
TYPETAND 32.238 Support for all Tandem records in a single file.
Major enhancement added in MXG 32.10, dated Oct 10, 2014:
VMACaaaa 32.234 The _IDaaaa=512 detection was removed.
TYPE6 32.236 Support for z/OS 2.1 ACCOUNTn in TYPE6 records.
TYPEDB2 32.231 Support for DB2 V11 IFCID 225 ILRM STORAGE Info.
TYPEBBMQ 32.223 Support for MainView for MQ Version 5.2 (COMPAT).
TYPE1415 32.230 TYPE 14 SMF14STY=01 with LEN 81 caused skipped segs
TYPEIMS 32.228 IMS Log 01 MSGTEXT INPUT expanded for MOBILE WORK.
TYPEIMST 32.222 IMS56FA obs not OUTPUT if NMSGPROC is missing.
TYPE38 32.233 Netview SMF 38 Subtype 3 INPUT EXCEEDED error.
UTILBLDP 32.226 SPINCNT/SPINUOW/TIMEDIF not correctly created.
TYPENDM 32.229 All NDM datasets are now PROC SORTed by TYPSNDM.
Major enhancement added in MXG 32.09, dated Sep 9, 2014:
ASMTAPEE 32.212 MXGTMNT Monitors ASM SLOTs + IWMWSYSQ MSU/IMPORTANCE.
New subtask wakes, writes interval record, sleeps.
TYPE50 32.210 Support for SMF 50 z/OS 2.1 INCOMPATIBLE + REDESIGN.
TYPE103 32.209 Support for SMF 103 HTTP Apache Subtypes 13 and 14.
VMACNDM 32.208 Support for New NDM-CDI CPU CP/zIIP/QUAL times.
VMXGODSO 32.217 Support for ODS TYPEs CSV CSVALL EXCEL and TAGSETS.
TYPEDB2 32.214 DB2 V10 var QW0225DMH and V11 var QW0225AR now INPUT.
TYPEBVIR 32.218 BVIRVERS=04, dataset BVIR301, values were wrong.
TYPEZOSA 32.215 Zero observations in TYPEZOSA, incorrect MXG test.
PDBAUDIT 32.206 WARNING: Multiple lengths for MEMLABEL CC=4, removed.
TYPE119 32.204 SMF 119 St 52 fields misaligned after JESDPERC.
ANALID 32.203 Protection for 2nd execution of ANALID.
ONLYJOBS 32.203 ONLY create PDB.JOBS/etc example, 2nd ANALID removed.
TYPE102 32.202 DB2 102 IFCID 196 "MORE HOLDERS", only 3 now printed.
Major enhancement added in MXG 32.08, dated Aug 21, 2014:
IMACUOW 32.185 MXG 32.07 only, 180 ERROR: with default IMACUOW.
And only in JCLTESTx if you do NOT use ASUMUOW.
(If you actually use ASUMUOW, you would have had a
tailored IMACUOW).
PDBAUDIT 32.183 %PDBAUDIT compares today's and yesterday's PDBs.
New audit report of differences and report of all
of today's output LIBNAMEs/DATASETs.
BUILDPDB 32.192 BUILDPDB/PD3/001 now use a VIEW for WORK.ID.
Could be a BIG reduction in //WORK space, for free.
VMACSMF 32.191 Using _INFILE_=SMFINFILE allows VIEW with MXGDECOM.
Which is also required for Change 32.192.
TYPEOMSM 32.184 Support for Omegamon for SMS Version 510 (INCOMPAT)
ANALSET 32.187 OPENTM added for TYPE64, new RECFOUND variable.
ANAL116 31.186 Now reports on dataset MQMACCT when it exists.
VMACaaaa 32.198 Zero OBS if _IDaaaa has two ID values, false 512.
Major enhancement added in MXG 32.07, dated Aug 3, 2014:
ERROR: 32.06: ZERO OBS IN ALL USER-ADDED BUILDPDB/UTILBLDP DATASETS:
If you use UTILBLDP(BUILDPDB=YES,USERADD=...) or EXPDBVAR/CDE/OUT
members in your USERID.SOURCLIB to add other SMF record types to
your BUILDPDB/BUILDPD3, AND YOU DO NOT PROCESS MXGTMNT/TYPETMNT
SMF records (i.e., you do NOT set MACRO _IDTMNT 238 %), then ALL
of the datasets built AFTER TYPETMNT will have zero observations.
This error was introduced in Change 32.149, which incorrectly had
added a DELETE statement that should not be there.
CIRCUMVENTIONs for this 32.06-Only ERROR: (INSTALL 32.07+ !!)
-Remove the DELETE; statement in line 265 of VMACTMNT, OR
-Add this statement in your //SYSIN at the top:
%LET MACKEEP= MACRO _IDTMNT 999 % ;
-Or: with USERADD= in UTILBLDP, add TMNT/999
Many 32.180 Correction to Zero OBS in BUILDPDB/UTILBLDP datasets.
TYPEWECR 32.173 Support for Websphere MQ for z/OS Crypto Audit SMF.
TYPE115 32.172 Support for Websphere MQ Version 8.1 115 Subtype 231
TYPE116 32.172 Support for Websphere MQ Version 8.1 116 Subtype 10
TYPE120 32.171 Support for Websphere Liberty z/CONNECT 120 Subtp 11.
TYPCTCP 32.178 Support for AES CleverView USER SMF subtypes 30-40.
TYPETMD2 32.176 TMON/DB2 compressed records not decoded on ASCII.
ANALID 32.175 View used for READSMF=YES, documentation updated.
TYPEDB2 32.174 DB2 V11 new QX variables not in DB2STATS.
MXG Version 32.06 dated Jul 21, 2014, thru Change 32.170.
Major enhancement added in MXG 32.06, dated Jul 21, 2014:
MOBILWRK 32.168 Support for MOBILE WORK CSV File to submit to IBM.
TYPESTC 32.155 Support for Oracle ELS/VTCS 7.2 HSC SMF changes.
ASMTAPEE 32.160 ML-53 MXGTMNT Monitor protects for IODF Activate OC4.
TYPE102 32.141 Support for IFCID=376.
TYPEPOEX 32.150 Revised support for Informatica POWER EXCHANGE SMF.
VMACaaaa 32.149 USER SMF Record Processing enhanced - tells if 512.
VMACSMF 32.136 CICS Version SMFPSRVR formatted prints TS5.1 vs 68.
ASUM70PR 32.166 31.09-3205. Default CECINTRV=HOUR was not in effect.
TYPENDM 32.168 Truncated CT records INPUT STATEMENT circumvention.
TYPENDM 32.161 Support for NDM-CDI M2 record, output in NDMMC.
ANALRANK 32.165 New GROUPBY parameter allows variable selections.
TYPEDB2 32.169 Some DB2STATS QDSTxxxx variables were wrong.
VMXGSUM 32.164 FREQ option created lower case variable names.
GRAFCEC 32.157 New WIDTRH HEIGHT FOOTNOTE parameters for tailoring.
ASUMCICX 32.156 New RESPAVG variable contains average response time.
ANALID 32.154 ID parameter with UTILBLDP must be first, for now.
IMACICVH 32.153 Support for optional CICS User ADP fields.
TYPE74 32.151 BY lists for some TYPE74xx did not remove duplicates.
VMACDB2H 32.148 DB2 Headers in any order are now processed correctly.
READDB2 32.148 IFCIDS=BMC worked on ASCII, failed on z/OS.
ODS 32.147 ODS doesn't support character variables with $HEX.
JMP 32.147 JMP doesn't support variables with TRANSCODE ATTRIB.
TYPE110 32.144 Invalid STID=60 CICS TS/2.3 (YES, 2.3!!!).
TYPESYNC 32.143 CPUZIPTM for SYNCSORT COPY was a missing value.
READDB2 32.142 Failed if user set FIRSTOBS or OBS insufficiently.
TYPE80A 32.140 RACF SMF 80 EXCEEDED for STATE='DISTRICT OF COLUMBIA'
TYPE113 32.130 *PUTLOG caused error, /* PUTLOG didn't, with BUILDPDB
Major enhancement added in MXG 32.05, re-dated Jun 18, 2014:
MOBILWRK 32.125 Preliminary tools to measure Mobile Work for Discount
See MVS Technical Note in Newsletter SIXTY-FOUR or
the same text in MOBILWRK member.
TYPEIMST 32.119 Support for IMS56FA for IMS 13.1 (INCOMPATIBLE).
TYPERMFV 32.130 Support for APAR OA35811, GEIRPOOL/GEIRSTRF.
TYPE113 32.126 Support for new Subtype 1 HIS SMF TYPE 113 INTERVAL.
TYPERSDS 32.123 Support for EOS RSD USER SMF ACCOUNTING Version 2.1.
TYPERSDA 32.123 Support for EOS RSD USER SMF AUDIT Version 2.1.
TYPE42 32.113 Support for APAR OA44319/OA44322 SMF 42 ST 5/6.
TYPEIDMS 32.111 Support/corrections for IDMS Version 18.
VMXGSUM 32.133 Support for "concatenated" PDBs as INPUT.
TYPEBVIR 32.134 Some POOLs were not output in BVIR322/323/324.
TYPERMFV 32.108 RMF III Fixes, Enhancements, Documentation upgrade.
TYPEXAM 32.116 XAM CRITICAL ERROR SEGLEN=84 is a false error.
TYPE30 32.104 CPUUNITS/SRBUNITS corrected by moving ASRUNITS to SRB
TYPE119 32.110 Variables FSCIPHER/FCCFIPS140/FCCIPHER4 added.
TYPEVMXA 32.106A z/VM MONWRITE divide by zero protection HFCOUNT=0.
TYPEDCOL 32.103 DCOLMIGS variable UMLRECL always zero correction.
READDB2 32.114 READDB2 with PDBOUT="not //PDB" corrections.
READDB2 32.131 %READDB2(IFCIDS=BMC) for APPTUNE failed, _S102BMC.
IMACICVG 32.107 Support for optional CICS segment ESIUSER.
IMACICMR 32.106 Optional CMRDETL CICS Segment INCOMPATIBLE 384 bytes.
IMACICSD 32.120 Support for optional CICS user SDA fields.
DOCVER 32.124 DOCVER member enhanced to list SORTED BY variables.
VMXGDEL0 32.127 New %VMXGDEL0 utility deletes all zero-obs datasets.
TYPE7072 32.103 Support for OS/390 RMF data!!! Zero obs after 30.30.
Major enhancement added in MXG 32.04, dated Apr 27, 2014:
VGETOBS 32.100 Correction to VGETOBS in First 32.04.
MXG 32.04 was redated on Monday for VGETOBS change 32.100 to add the
possibly-needed RUN; statement, and removal of the FEXIST() function
that did not exist in SAS 9.1 and didn't always work with 9.2.
TYPE102 32.101 Duplicate DB2 SMF ID=102 Trace records removed.
This enhancement was ready, so it's a bonus in the redated 32.04.
Major enhancement added in MXG 32.04, dated Apr 23, 2014:
VGETOBS 32.091 MXG 32.03 VGETOBS z/OS increased EXCPs, Elapsed time.
This performance hit on VGETOBS is the primary reason for 32.04; the
exposure only exists if you have tape device DDs in your MXG job.
The increase was VERY significant with lots of tape volsers to read.
AUTOEZOS 32.090 AUTOEZOS/CONFIGEZ - new "EAZY" MXG JCL for z/OS.
A new alternative JCL to run MXG that is quite simple.
TYPE120 32.087 Support for SMF 120 Subtype 100 ODM (Oper Decision).
TYPENMON 32.088 Support for NMON BBBPMOUNT and BBBPNETSTAT records.
TYPE92 32.094 Support for SMF ID=92 Subtypes 16 and 17.
NEARTIME 32.099 NEARTIME updates a daily PDB library each SMF dump.
TYPE30 32.089 CPUASRTM subtracted from CPUTCBTM added to CPUSRBTM.
TYPETMVS 32.092 Initial support for TMON/MVS Version 4.4 (INCOMPAT)
TYPE102 32.085 Many QWP1/4/5/9 T102S106 dataset vars overlooked.
TYPEDB2 32.082 Some NETEZZA/IDAA Q8ST vars incorrectly DIF()'d.
ANALDB2R 32.080 Default Select "Starting With" can be changed.
ADOCRMFV 32.093 Major addition to RMF III documentation.
ADOCx All ADOC members are updated with current contents.
Major enhancement added in MXG 32.03, dated Apr 3, 2014:
TYPE110 32.077 Support CICS/TS 5.2: CICSTRAN COMPATIBLE, STATs NOT.
_SMF 32.073 New MXGREADSMF=SMF/LOGGER/BOTH option to read SMF.
ANALBVIR 32.063 Hydra TS7700 IBM reports are replicated.
GRAFCIPM 32.061 Graphs from SHARE 2014 (SinRam/Enrico) using SGPLOT:
CPU used by importance level and service class level,
then service class within importance, and a scatter
plot of service class level within importance.
ANALDB2R 32.068 Report from SHARE 2014 (Catterall) DB2 Buffer Pools.
TYPE112 32.052 Support for Tivoli Enterprise Mon Server SMF 112-35.
TYPE87 32.043 Support for SMF ID=87, GRS Component Information.
TYPETMO2 32.070 Support for ASG-TMON CICS v3.4 (NO MXG UPDATE NEEDED)
TYPEEJES 32.047 Support for (E)JES Version 05.30 SMF record changes.
TYPEXCOM 32.046 Support for XCOM R32 - 11.5 (INCOMPATIBLE).
TYPEPCF 32.045 Support for MQ PCF Files.
TYPEZOSA 32.059 Support for ZEN 2280 new CSM records (INCOMPAT).
TYPETMO2 32.070 Support for ASG-TMON CICS TS 3.4 (NO UPDATE NEEDED).
TYPE80A 32.076 INPUT STATEMENT EXCEEDED, TODANAM UID, FTEL/MTEL.
TYPE79 32.062 Variables R791PHTA/PHTI/FLG3 and R792PHTA/PHTI kept.
TYPETPMX 32.058 INVALID ARG TPMPI - previous $EBCDIC1 is now PIB1.
TYPEXAM 32.057 Doc: FTP: Use TYPE E and MODE BLOCK for z/VM to z/ZOS
VGETOBS 32.056 CANNOT CLONE BUFFSIZE during PROC COPY could be bad.
ASMRMFV 32.055 New RMF III selection/filter options BASIC, MOST etc.
TYPE7072 32.054 z/OS 2.1 SMF70CPA created with RATIO=SCALING/ACTUAL.
TYPE21 32.053 SMF21CRR/CRW compress ratio populated for non-3590s.
TYPE102 32.074 IFCID 402 dataset T102S402 now outputs all segs.
TYPEDB2 32.072 IDAA/NETEZZA variables added to DB2ACCT/DB2STATS.
TYPENDM 32.071 Connect-Direct NDMCPU and other variables added.
Major enhancement added in MXG 32.02, dated Feb 26, 2014:
VMACDB2H 32.027 32.01: INVALID DB2 V10 HEADER RECORDS DELETED only if
the 2012 DB2 APAR PM62481, is NOT installed.
(Only a FEW sites have hit this missing APAR ABEND.)
TYPEBVIR 32.039 MAJOR restructure BVIR/TS7700/HYDRA datasets created.
REALLY MAJOR: 10,000 fewer lines, 3000 fewer vars.
The "horizontal" dataset with suffixed variable names
are replaced with "vertical" dataset with ONE set of
variable names. Yes, some minor pain expected as the
dataset names and some variable's names were changed.
TYPE74 32.031 TYPE74 ESS Subtype 8 TYPE748x datasets restructured.
None of the TYPE748x datasets were really valid.
TYPE120 32.035 Sort order NODUP support for TYP1209C/E/S/U.
TYPEXPTR 32.033 Support for XPTR 5.2 creates 23 new datasets.
TYPEIMST 32.038 IMS56FA dataset could have IMSSTCK incorrect.
TYPEDB2 32.032 DB2STATS variable QISTWMQM zero, QW0371CL/DA fixed.
VMXGPRAL 32.029 ERROR 72-322 or COMPBL HAS TOO MANY ARGUMENTS.
ASMRMFV 32.037 RMF III Enhancements, filters, RED TABLE error fix.
TYPETMVT 32.040 TMON/VTAM vendor maintenance now populates fields.
TYPEBETA 32.028 Protection for BETA93 truncated subtype 51 record.
Major enhancement added in MXG 32.01, dated Feb 6, 2014:
ASMTAPEE 32.010 IBM APAR OA43921/OA44049 cause MXGTMNT ABEND 0E0 RC28
VGETOBS 32.012 MANY spurious MXGWARN: DATASET PDB.CICxx DOES NOT msg
ASUMUOWT 32.011 ASUMUOWT (TMON/CICS) USER ABEND 1950 no CICSTRAN DD.
TYPE111 32.007 MXG 31.31. SMF ID=111 INPUT STATEMENT EXCEEDED ERROR.
TYPE21 32.006 PDB.TYPE21/ASUMTAPE BYTEWRIT for 3590s may be too low
TYPE90A 32.005 Support for SMF ID=90 Subtype 35 TYPE9035 dataset.
FORMATS 32.005 Format $MGSMFID 38, 85, 90, 118 IDs decoded.
FORMATS 32.005 ALL MXG FORMAT's VALUES ARE NOW COMMA-FREE, for csv.
TYPEDB2 32.002 DB2 V10 new var QWHCAACE, QWHCEUTX/EUWN now $128.
TYPENTSM 32.001 TCP/TCPV4/TCPV6 and WEBSRVCA, ASPNETAP new variables.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Versions
The current version nomenclature is SAS 9.4 TS1M2 (9.4M2). That is
printed as "SAS 9.4 (TS1M2)" or as "SAS 9.4 (TS04.01M2P07232014)"
on the SASLOG if the VERSIONLONG option is enabled.
SAS V9.4 M2 Is RECOMMENDED. SAS 9.4 M2 is at LEVEL A SAS Support
SAS V9.4 M1 and M0 had no errors and are at LEVEL A SAS Support
SAS V9.3 SAS 9.3 TS1M2 was RECOMMENDED. SAS 9.3 TS1M1 works.
But SAS 9.3 at TS1M0, the HOT FIX for SAS Note SN-43828,
see CHANGE 29.169, IS REQUIRED:
The %MACRO compiler error is in processing %LET
statements. While only two MXG members failed
repeatedly in MXG QA tests on z/OS, there were random
%LET errors in ASCII QA tests, so ANY use of %LET
statement on ANY platform are vulnerable to this
error, as the %MACRO compiler is SAS portable code,
used on all platforms. So this is NOT just an MXG
error, but impacts ALL SAS programs.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN.
SAS9.3 is LEVEL A support from SAS.
SAS V9.2 Was recommended, prior to 9.3, and was error-free with
MXG 26.03 SAS Hot Fix for SAS Note 37166 is required to
use a VIEW with the MXG EXITCICS/CICSFIUE CICS/DB2
Decompression Infile Exit. but SAS V9.2 does execute on
that platform.
9.2 is LEVEL B Support from SAS, as of Sep 30, 2013.
SAS V9.1.3 must be at Service Pack 4. Additionally, on z/OS 1.10
only, 9.1.3 requires SAS Hot Fix for SN-35332.
9.1.3 is support level C by SAS Institute, Sep 30, 2013.
SAS V8.2 IS SUPPORT LEVEL C BY SAS INSTITUTE; NOT ALL OF MXG WORKS
with SAS 8.2.
SAS 8.2 is Level C Support from SAS as of Dec 31, 2011.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS93 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 32.10 will execute under the previously listed
SAS Versions on all supported platforms
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I cannot guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
If you are absolutely stuck on V8, you need to copy MXG member
V8GETOBS into USERID.SOURCLIB and rename to VGETOBS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG
Version 26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For (Archaic) SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.3 & V9.4, on z/OS, on Windows
Seven (32-bit and 64-bit) and Eight (64-bit) on 64-bit hardware,
and on Centos 6.4, but MXG users execute MXG on MANY (ALL??) SAS
platforms, including AIX, Linux, and other 'nix' variants, on many
different hardware platforms, and since they all work we don't
need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 3.01 is required for AUTOEZOS.
WPS Version 3.01 is required for MOBILWRK, PICTURE fails in 2.5.
WPS Version 3.01 executed MXG 32.03 BUILDPDB with no errors.
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS hardware changes. However, MXG
Version 30.07+ was REQUIRED for z/EC12 (for SMF 113, for 95 engines)
and MXG 31.03+ is STRONGLY RECOMMENDED for the z/EC12 processor for
the new zEC12 RMF data metrics added for that new platform.
In August 2013, the MXG-L ListServer was abuzz with several postings
from MXG users and additional references to SHARE papers that all
reported that many z/EC12s are 30%-40% better than zPCR projected.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 - Most Records support Jul 23, 2013 30.05
z/OS 2.1 - ID=0 ERROR MESSAGE Jul 23, 2013 31.07
z/OS 2.1 - ID=85 INCOMPAT Jul 23, 2013 32.03
z/OS 2.1 - ID=70 SMF70CPA Jul 23, 2013 32.03
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 29.05*
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 30.01*
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 30.08*
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 30.30*
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 31.03*
CICS-TS/5.2 COMPATIBLE CICSTRAN Jun 13, 2014 31.03*
CICS-TS/5.2 INCOMPAT Statistics Jun 13, 2014 32.03*
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 28.07*
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 28.28*
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 29.07*
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 30.07*
DB2 10.1 DBID/OBID decode Jan 21, 2013 30.30*
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 31.04*
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
DB2 11.1 IRLM NEW SEGMENT Jun 21, 2013 32.10
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.1 Mar 06, 2007 26.01*
IMS log 11.1 Apr 1, 2010 28.02*
IMS log 12.1 Jan 23, 2012 29.29*
IMS log 13.1 (NOT 56FA) May 25, 2013 31.03
IMS log 13.1 (56FA RECORD) May 27, 2014 32.05
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
The Monitor for CICS TCE 3.4 (for CICS/TS 5.1) 30.30
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
The Monitor for MVS/ESA 3.0 - 19.19
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V6R3 SMF 102 30.037
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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 31.08*
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS 31.08*
IMF 5.1 a/k/a Mainview IMS 31.08
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
V. Incompatibilities and Installation of MXG 32.08.
1. Incompatibilities introduced in MXG 32.32:
a- Changes in MXG architecture made between 32.32 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 32.32 after MXG 31.31:
Dataset/
Member Change Description
ADOCRMFV 32.093 Major addition to RMF III documentation.
ANAL116 31.186 Now reports on dataset MQMACCT when it exists.
ANALBVIR 32.063 Hydra TS7700 IBM reports are replicated.
ANALDB2R 32.019 Extensive validation, ANALDBTR revisions.
ANALDB2R 32.080 Default Select "Starting With" can be changed.
ANALDBTR 32.019 STRING logic was protected for repeated execution
ANALDSCK 32.268 New "DSNAME Check" reads all SMF with a DSNAME.
ANALID 32.154 ID parameter with UTILBLDP must be first, for now.
ANALID 32.175 View used for READSMF=YES, documentation updated.
ANALID 32.203 Protection for 2nd execution of ANALID.
ANALID 32.257 ANALID reports 78.2.1 and 78.2.2 VSTORE enabled.
ANALRANK 32.165 New GROUPBY parameter allows variable selections.
ANALSET 32.187 OPENTM added for TYPE64, new RECFOUND variable.
ASMIMSL6 32.290 Larger DLREXTIM time now used for (archaic) IMSCPUTM.
ASMRMFV 32.009 RMF III Enhancements, Fixes, and Notes
ASMRMFV 32.037 RMF III Enhancements, filters, RED TABLE error fix.
ASMRMFV 32.055 New RMF III selection/filter options BASIC, MOST etc.
ASMRMFV 32.250 Further ASMRMFV parsing/command/filtering updates.
ASMTAPEE 32.010 IBM APAR OA43921/OA44049 cause MXGTMNT ABEND 0E0 RC28
Those z/OS 1.13 APARs changed AR15 on return from IBM
console services. Assemble ASMTAPEE to create the
MXGTMNT monitor now so it doesn't ABEND after those
APARs are installed.
ASMTAPEE 32.160 ML-53 MXGTMNT Monitor protects for IODF Activate OC4.
ASMTAPEE 32.212 MXGTMNT Monitors ASM SLOTs + IWMWSYSQ MSU/IMPORTANCE.
ASUM70PR 32.166 31.09-3205. Default CECINTRV=HOUR was not in effect.
ASUMCICX 32.156 New RESPAVG variable contains average response time.
ASUMDB2A 32.293 Warning when "Rollups" are detected, summarized data.
ASUMUOWT 32.011 ASUMUOWT (TMON/CICS) USER ABEND 1950 no CICSTRAN DD.
AUTOEXEC 32.292 Old MXG SORTSIZE=400M removed, default SORTSIZE used.
AUTOEZOS 32.090 AUTOEZOS/CONFIGEZ - new "EAZY" MXG JCL for z/OS.
BLDSMPDB 32.248 WPS, z/OS, BLDSMPDB, RECFM=S370VBS not supported.
BLDSMPDB 32.262 WTD with WEEKKEEP, or WTD with AUTOALOC, failed.
BLDSMPDB 32.299 %PDBAUDIT invocation can capture ALL "PDBs".
BLDSMPDB 32.306 RUNDAY=NO incorrectly executed the PDBAUDIT report.
BUILDPDB 32.192 BUILDPDB/3/001 now use a VIEW for WORK.ID.
DOCVER 32.124 DOCVER member enhanced to list SORTED BY variables.
FORMATS 32.005 ALL MXG FORMAT's VALUES ARE NOW COMMA-FREE, for csv.
FORMATS 32.005 Format $MGSMFID 38, 85, 90, 118 IDs decoded.
GRAFCEC 32.157 New WIDTRH HEIGHT FOOTNOTE parameters for tailoring.
GRAFCIPM 32.061 Graphs from SHARE 2014 presentations (SinRam/Enrico)
IHDRBVIR 32.270 The IHDRBVIR "BVIR Header" exit was overlooked.
IMACICMR 32.106 Optional CMRDETL CICS Segment INCOMPATIBLE 384 bytes.
IMACICSD 32.120 Support for optional CICS user SDA fields.
IMACICVG 32.107 Support for optional CICS segment ESIUSER.
IMACICVH 32.153 Support for optional CICS User ADP fields.
IMACUOW 32.185 MXG 32.07 only, 180 syntax with default IMACUOW.
JMP 32.147 JMP doesn't support variables with TRANSCODE ATTRIB.
MOBILWRK 32.125 Preliminary MOBILWRK program to identify Mobile Work.
MOBILWRK 32.168 Support for MOBILE WORK CSV File to submit to IBM.
MOBILWRK 32.279 MOBWRK02,MOBWRK05 enhanced, STARTHR in all merges.
MOBWRK73 32.244 MOBWRK73 in 32.10 incorrectly required //PDB DD.
MONTHxxx 32.253 BLDSMPDB,MONTHBLD, z/OS, out of order daily GDGs.
Many 32.263 MXG PROC COPY have MEMTYPE=DATA, ITEMSTORE fails.
NEARTIME 32.099 NEARTIME updates a daily PDB library each SMF dump.
ODS 32.147 ODS doesn't support character variables with $HEX.
ODS 32.269 Documentation of two common ODS errors on z/OS.
ONLYJOBS 32.203 ONLY create PDB.JOBS/etc example, 2nd ANALID removed.
PDBAUDIT 32.183 %PDBAUDIT compares today's and yesterday's PDBs.
PDBAUDIT 32.206 WARNING: Multiple lengths for MEMLABEL CC=4, removed.
PDBAUDIT 32.274 Report enhanced, SORTEDBYSIZE, commas in numbers.
PDBAUDIT 32.297 %PDBAUDIT can be bypassed with PRINTAUDIT=NO.
READDB2 32.018 READDB2 didn't always honor LDB2xxx destination
READDB2 32.019 READDB2 did not always use LDB2ddd overrides, plus.
READDB2 32.114 READDB2 with PDBOUT="not //PDB" corrections.
READDB2 32.131 %READDB2(IFCIDS=BMC) for APPTUNE failed, _S102BMC.
READDB2 32.142 Failed if user set FIRSTOBS or OBS insufficiently.
READDB2 32.148 IFCIDS=BMC worked on ASCII, failed on z/OS.
SMFINTRV 32.271 New SMFINTRV member creates PDB.SMFINTRV from SMF.
TYPCTCP 32.178 Support for AES CleverView USER SMF subtypes 30-40.
TYPE102 32.074 IFCID 402 dataset T102S402 now outputs all segs.
TYPE102 32.085 Many QWP1/4/5/9 T102S106 dataset vars overlooked.
TYPE102 32.101 Duplicate DB2 SMF ID=102 Trace records removed.
TYPE102 32.141 Support for IFCID=376.
TYPE102 32.202 DB2 102 IFCID 196 "MORE HOLDERS", only 3 now printed.
TYPE102 32.259 IFCID=220: Invalid Argument corrected.
TYPE103 32.209 Support for SMF 103 HTTP Apache Subtypes 13 and 14.
TYPE105 32.291 Support for GDPS SMF 105 2-byte fields APAR PI26702.
TYPE110 32.077 Support CICS/TS 5.2: CICSTRAN COMPAT, STATs NOT.
TYPE110 32.144 Invalid STID=60 CICS TS/2.3 (YES, 2.3!!!).
TYPE111 32.007 MXG 31.31. SMF ID=111 INPUT STATEMENT EXCEEDED ERROR.
TYPE112 32.052 Support for Tivoli Enterprise Mon Server SMF 112-35.
TYPE113 32.126 Support for new Subtype 1 HIS SMF TYPE 113 INTERVAL.
TYPE113 32.130 *PUTLOG caused error, /* PUTLOG didn't, with BUILDPDB
TYPE115 32.172 Support for Websphere MQ Version 8.1 115 Subtype 231
TYPE116 32.172 Support for Websphere MQ Version 8.1 116 Subtype 10
TYPE119 32.110 Variables FSCIPHER/FCCFIPS140/FCCIPHER4 added.
TYPE119 32.204 SMF 119 St 52 fields misaligned after JESDPERC.
TYPE119 32.278 TYP11902 TTTTLSxx variables misaligned.
TYPE120 32.035 Sort order NODUP support for TYP1209C/E/S/U.
TYPE120 32.087 Support for SMF 120 Subtype 100 ODM (Oper Decision).
TYPE120 32.171 Support for Websphere Liberty z/CONNECT 120 Subty 11.
TYPE120 32.239 WebSphere SMF 120 ST 9 TYP1209E DELTA120TM negative.
TYPE1415 32.230 TYPE 14 SMF14STY=01 with LEN 81 caused skipped segs
TYPE21 32.006 PDB.TYPE21/ASUMTAPE BYTEWRIT for 3590s may be too low
TYPE21 32.053 SMF21CRR/CRW compress ratio populated for non-3590s.
TYPE22 32.288 MXG 32.03-MXG 32.11 Type 22 UNKNOWN SECID=40 error.
TYPE30 32.089 CPUASRTM subtracted from CPUTCBTM added to CPUSRBTM.
TYPE30 32.104 CPUUNITS/SRBUNITS corrected by moving ASRUNITS to SRB
TYPE30 32.251 Variables EXCP/IOTM-NODD/TODD/TOTL inconsistent.
TYPE38 32.233 Netview SMF 38 Subtype 3 INPUT EXCEEDED error.
TYPE42 32.113 Support for APAR OA44319/OA44322 SMF 42 ST 5/6.
TYPE50 32.210 Support for SMF 50 z/OS 2.1 INCOMPATIBLE + REDESIGN.
TYPE50 32.307 TYPE50 LENGTH=254, INPUT STATEMENT EXCEEDED.
TYPE6 32.240 Corrected z/OS 2.1 ACCOUNTn in TYPE6 records.
TYPE7072 32.054 z/OS 2.1 SMF70CPA created with RATIO=SCALING/ACTUAL.
TYPE7072 32.103 Support for OS/390 RMF data!!! Zero obs after 30.30.
TYPE7072 32.246 TYPE72GO's PERFINDX can be missing when it's large.
TYPE7072 32.267 TYPE70X2 variables CRYAC1U/CRAM3U need mult 100.
TYPE7072 32.277 R7023MEG/R7023CRT were not multiplied by R7024SF.
TYPE74 32.031 TYPE74 ESS Subtype 8 TYPE748x datasets restructured.
TYPE74 32.151 BY lists for some TYPE74xx did not remove duplicates.
TYPE79 32.062 Variables R791PHTA/PHTI/FLG3 and R792PHTA/PHTI kept.
TYPE80A 32.076 INPUT STATEMENT EXCEEDED, TODANAM UID, FTEL/MTEL.
TYPE80A 32.140 RACF SMF 80 EXCEEDED for STATE='DISTRICT OF COLUMBIA'
TYPE87 32.043 Support for SMF ID=87, GRS Component Information.
TYPE90A 32.005 Support for SMF ID=90 Subtype 35 TYPE9035 dataset.
TYPE92 32.094 Support for SMF ID=92 Subtypes 16 and 17.
TYPEBBMQ 32.223 Support for MainView for MQ Version 5.2 (COMPAT).
TYPEBETA 32.028 Protection for BETA93 truncated subtype 51 record.
TYPEBVIR 32.039 MAJOR restructure of BVIR/TS7700 datasets created.
TYPEBVIR 32.218 BVIRVERS=04, dataset BVIR301, values were wrong.
TYPEBVIR 32.249 Support for BVIR Version 2 short '32'x Record.
TYPECLAR 32.247 Support for EMC's Clarion Flare Firmware V26-V33.
TYPEDB2 32.002 DB2 V10 new var QWHCAACE, QWHCEUTX/EUWN now $128.
TYPEDB2 32.032 DB2STATS variable QISTWMQM zero, QW0371CL/DA fixed.
TYPEDB2 32.072 IDAA/NETEZZA variables added to DB2ACCT/DB2STATS.
TYPEDB2 32.082 Some NETEZZA/IDAA Q8ST vars incorrectly DIF()'d.
TYPEDB2 32.169 Some DB2STATS QDSTxxxx variables were wrong.
TYPEDB2 32.174 DB2 V11 new QX variables not in DB2STATS.
TYPEDB2 32.214 DB2 V10 var QW0225DMH and V11 var QW0225AR now INPUT.
TYPEDB2 32.231 Support for DB2 V11 IFCID 225 IRLM STORAGE Info.
TYPEDB2H 32.027 MXG 32.01 only. INVALID DB2 10.1 HEADER DELETED.
TYPEDCOL 32.103 DCOLMIGS variable UMLRECL always zero correction.
TYPEEJES 32.047 Support for (E)JES Version 05.30 SMF record changes.
TYPEEZSM 32.252 Support for EzSM 4.2.0 creates new datasets.
TYPEIDMS 32.111 Support/corrections for IDMS Version 18.
TYPEIMS 32.228 IMS Log 01 MSGTEXT INPUT expanded for MOBILE WORK.
TYPEIMS7 32.290 Larger DLREXTIM time now used for (archaic) IMSCPUTM.
TYPEIMST 32.038 IMS56FA dataset could have IMSSTCK incorrect.
TYPEIMST 32.119 Support for IMS56FA for IMS 13.1 (INCOMPATIBLE).
TYPEIMST 32.222 IMS56FA obs not OUTPUT if NMSGPROC is missing.
TYPENDM 32.071 Connect-Direct NDMCPU and other variables added.
TYPENDM 32.161 Support for NDM-CDI M2 record, output in NDMMC.
TYPENDM 32.229 All NDM datasets are now PROC SORTed by TYPSNDM.
TYPENDM 32.275 Variable NDMRTCPU in NDMRT was incorrectly INPUT.
TYPENDM 32.284 NDM 'PT' INVALID SUBSTR, A#/C#/D#/S$/U#/UK supported.
TYPENEM 32.168 Truncated CT records INPUT STATEMENT circumvention.
TYPENMON 32.088 Support for NMON BBBPMOUNT and BBBPNETSTAT records.
TYPENTSM 32.001 TCP/TCPV4/TCPV6 and WEBSRVCA, ASPNETAP new variables.
TYPEOMSM 32.184 Support for Omegamon for SMS Version 510 (INCOMPAT)
TYPEPCF 32.045 Support for MQ PCF Files.
TYPEPOEX 32.150 Revised support for Informatica POWER EXCHANGE SMF.
TYPERACF 32.273 ASCII only. Variable LIOBTIME in RACF0200 wrong.
TYPERMFV 32.108 RMF III Fixes, Enhancements, Documentation upgrade.
TYPERMFV 32.130 Support for APAR OA35811, GEIRPOOL/GEIRSTRF.
TYPERMFV 32.130 Support for APAR OA35811, GEIRSTRF replaced GEIRPOOL.
TYPERSDA 32.123 Support for EOS RSD USER SMF AUDIT Version 2.1.
TYPERSDS 32.123 Support for EOS RSD USER SMF ACCOUNTING Version 2.1.
TYPESTC 32.155 Support for Oracle ELS/VTCS 7.2 HSC SMF changes.
TYPESYNC 32.143 CPUZIPTM for SYNCSORT COPY was a missing value.
TYPETAND 32.238 Support for all Tandem records in a single file.
TYPETMD2 32.176 TMON/DB2 compressed records not decoded on ASCII.
TYPETMO2 32.070 Support for ASG-TMON CICS TS 3.4 (NO UPDATE NEEDED).
TYPETMO2 32.309 Support for ASG TMON/CICS Version 4 INCOMPATIBLE.
TYPETMVS 32.092 Initial support for TMON/MVS Version 4.4 (INCOMPAT)
TYPETMVT 32.040 TMON/VTAM vendor maintenance now populates fields.
TYPETPMX 32.058 INVALID ARG TPMPI - previous $EBCDIC1 is now PIB1.
TYPEVMXA 32.106A z/VM MONWRITE divide by zero protection HFCOUNT=0.
TYPEVMXA 32.243 Each START MONITOR message is a LOST interval.
TYPEVMXA 32.243 z/VM Interval ENDTIME wrong if first 0.1 not CPU 0.
TYPEVMXA 32.254 Support for z/VM concatenated MONWRITE mult systems.
TYPEWECR 32.173 Support for Websphere MQ for z/OS Crypto Audit SMF.
TYPEXAM 32.057 Doc: FTP: Use TYPE E and MODE BLOCK for z/VM to z/ZOS
TYPEXAM 32.116 XAM CRITICAL ERROR SEGLEN=84 is a false error.
TYPEXAM 32.272 ERROR IN XAMSYS, SEGNAME=CMS, MXG coding error.
TYPEXCOM 32.022 Support for CA XCOM VERSION 1.16: INCOMPATIBLE.
TYPEXCOM 32.046 Support for XCOM R32 - 11.5 (INCOMPATIBLE).
TYPEXPTR 32.033 Support for XPTR 5.2 creates 23 new datasets.
TYPEZOSA 32.059 Support for ZEN 2280 new CSM records (INCOMPAT).
TYPEZOSA 32.215 Zero observations in TYPEZOSA, incorrect MXG test.
UTILBLDP 32.226 SPINCNT/SPINUOW/TIMEDIF not correctly created.
UTILEXCL 32.265 Support for 2nd CMODNAME='USER',CMODHEAD='USER'.
UTILVREF 32.295 QA UTILVREF now detects long BY lists for HOST SORT.
VGETJESN 32.296 &MACJESN can delete records by TYPETASK (e.g. OMVS).
VGETOBS 32.012 MANY spurious MXGWARN: DATASET PDB.CICxx DOES NOT msg
VGETOBS 32.056 CANNOT CLONE BUFFSIZE during PROC COPY could be bad.
VGETOBS 32.091 MXG 32.03: VGETOBS on z/OS increased EXCPs, Elapsed.
VGETOBS 32.100 Correction to VGETOBS in First 32.04.
VMAC112 32.295 Long BY list, HOST SORT CAN NOT BE USED, MXG error.
VMACBETA 32.028 Protection for BETA93 truncated SUBTYPE=41 record.
VMACBVIR 32.134 Some POOLs were not output in BVIR322/323/324.
VMACDB2H 32.027 32.01 INVALID DB2 V10 HEADER RECORDS DELETED.
VMACDB2H 32.148 DB2 Headers in any order are now processed correctly.
VMACDB2H 32.261 DB2 variable JOB could be incorrect LENGTH $12.
VMACNDM 32.208 Support for New NDM-CDI CPU CP/zIIP/QUAL times.
VMACSMF 32.073 New MXGREADSMF=SMF/LOGGER/BOTH option to read SMF.
VMACSMF 32.136 CICS Version SMFPSRVR formatted prints TS5.1 vs 68.
VMACSMF 32.191 Using _INFILE_=SMFINFILE allows VIEW with MXGDECOM.
VMACSMF 32.300 WPS ONLY. CANNOT READ SMF ON ASCII, MXG ERROR.
VMACWECR 32.301 WPS ONLY. DATA SET "WORK.WEBSCRAU" NOT FOUND.
VMACaaaa 32.234 The _IDaaaa=512 detection was removed.
VMXGDEL0 32.127 New %VMXGDEL0 utility deletes all zero-obs datasets.
VMXGDSNL 32.260 MXG on Linux to process AS400 data, slash issue.
VMXGINIT 32.021 Change 31.285 removed (INSTREAM enhancement didn't).
VMXGODSO 32.217 Support for ODS TYPEs CSV CSVALL EXCEL and TAGSETS.
VMXGPLCH 32.013 Create $PLOTCHAR to map one character from SYSTEM.
VMXGPRAL 32.029 ERROR 72-322 or COMPBL HAS TOO MANY ARGUMENTS.
VMXGPRNT 32.017 Fails with 180 pointing to LABEL, mis-located RUN.
VMXGSUM 32.026 Macro variables compressed with COMPBL and %STR.
VMXGSUM 32.133 Support for "concatenated" PDBs as INPUT.
VMXGSUM 32.164 FREQ option created lower case variable names.
WEEKBLxx 32.264 WPS ONLY. Test for &SYSVER GE 6 s/b &SASVER GE.
See member CHANGESS for all changes ever made to MXG Software, or
the CHANGES frames at http://www.mxg.com
Inverse chronological list of all Changes:
NEXTCHANGE: Version 32.
====== Changes thru 32.309 were in MXG 32.32 dated Jan 6, 2015=========
Change 32.309 Support for ASG TMON/CICS Version 4.0 INCOMPATIBLE due to
EXMONEXT inserted fields.
EXMONPSB -New variables in MONITASK 'TA' record dataset.
IMACTMO2 TACNTGLN='CONTAINER*ACCUM*GET/GET64*LENGTH'
VMACTMO2 TACNTHWM='CONTAINER*LENGTH*HWM'
VMXGINIT TACNTPLN='CONTAINER*ACCUM*PUT/PUT64*LENGTH'
Jan 1, 2015 TACNTRCT='CONTAINER REQUEST COUNT'
Jan 6, 2015 TACNTRTM='CONTAINER REQUEST ACCUMULATED TIME'
TACNTWCT='CONTAINER REQUEST WAIT COUNT'
TACNTWTM='CONTAINER REQ ACCUMULATED WAIT TIME'
TAHWMRUL='RULE RECORD'
TAIPCNRL='TOTAL IPIC NETWORK BYTES INBOUND'
TAIPCNSL='TOTAL IPIC NETWORK BYTES OUTBOUND'
TASTCODE='TRANSACTION START CODE'
-New dataset MONIEXT from 'TA' EXT SEGMENTs.
TAONETWK='ORIGIN*NETWORK ID*FROM*WORK REQUEST'
TAOAPPL ='ORIGIN*APPLID*FROM*WORK REQUEST'
WKOSTART='ORIGIN*TASK*START TIME'
TAOTRNUM='ORIGIN*TASK*TRANSACTION*NUMBER'
TAOTRID ='ORIGIN*TASK*TRANSACTION*ID'
TAOUSRID='ORIGIN*TASK*USERID'
TAOTCPSV='ORIGIN*TCPIPSERV*NAME'
TAOPORTN='ORIGIN*TCPIPSERV*PORT NR'
TAOCLIPA='ORIGIN*CLIENT/TELNET*IP*ADDRESS'
TAOCLIPP='ORIGIN*CLIENT/TELNET*PORT NR'
TAOFCTNM='ORIGIN*TRANSACTION*FACILITY*NAME'
TAOTRFL1='ORIGIN*TRANSFLAG*FACILITY*IDENT'
TAOTRFL2='ORIGIN*TRANSFLAG*IDENTITY*INFO'
TAOTRFL3='ORIGIN*TRANSFLAG*RESERVED'
TAOTRFL4='ORIGIN*TRANSFLAG*DEFINITION*INFO'
TAOTRFL5='ORIGIN*TRANSFLAG*TYPE'
TAOTRFL6='ORIGIN*TRANSFLAG*RESERVED'
TAOTRFL7='ORIGIN*TRANSFLAG*RESERVED'
TAOTRFL8='ORIGIN*TRANSFLAG*RECOVERY*MANAGER'
TAOUSRCO='ORIGIN*USER*CORRELATOR'
TAOADAT1='ORIGIN*DATA*ADDED*DATA1'
TAOADID ='ORIGIN*DATA*ADAPTER*ID'
TAOADAT2='ORIGIN*DATA*ADDED*DATA2'
TAOADAT3='ORIGIN*DATA*ADDED*DATA3'
TAPHNTWK='PREV HOP*DATA CICS*REMOTE TASK'
TAPHAPPL='PREV HOP*DATA*APPLID'
WKPHSTRT='PREV HOP*DATA*START TIME'
TAPHTRNO='PREV HOP*DATA REMOTE*TASK NUM'
TAPHTRAN='PREV HOP*DATA REMOTE*TASK TRAN'
TAPHCNT ='PREV HOP*DATA NUM OF*CICS REMOTE'
TAABPANM='APPLICATION*BASE*PROGRAM*APPLNAME'
TAABPPNM='APPLICATION*BASE*PROGRAM*PLATFORM'
TAABPONM='APPLICATION*BASE*PROGRAM*OPERATION*NAME'
TAABPMAJ='APPLICATION*BASE*PROGRAM*MAJOR*VER NR'
TAABPMIN='APPLICATION*BASE*PROGRAM*MINOR*VER NR'
TAABPMIC='APPLICATION*BASE*PROGRAM*MICRO*VER NR'
TAITKANM='INITIAL TASK*APPL CNTX*APPLICATION*NAME'
TAITKPNM='INITIAL TASK*APPL CNTX*PLATFORM*NAME'
TAITKONM='INITIAL TASK*APPL CNTX*OPERATION*NAME'
TAITKMAJ='INITIAL TASK*APPL CNTX*MAJOR VER NR'
TAITKMIN='INITIAL TASK*APPL CNTX*MINOR VER NR'
TAITKMIC='INITIAL TASK*APPL CNTX*MICRO VER NR'
TACTKANM='CURRENT TASK*APPL CNTX*APPLICATION*NAME'
TACTKPNM='CURRENT TASK*APPL CNTX*PLATFORM*NAME'
TACTKONM='CURRENT TASK*APPL CNTX*OPERATION*NAME'
TACTKMAJ='CURRENT TASK*APPL CNTX*MAJOR VER NR'
TACTKMIN='CURRENT TASK*APPL CNTX*MINOR VER NR'
TACTKMIC='CURRENT TASK*APPL CNTX*MICRO VER NR'
-New dataset MONIPSB from 'TA' PSB SEGMENTs.
TADDBCCT='TOTAL*DL/I*DATA BASE*CALLS'
TADDLETC='DATA BASE*DLET CALLS*ISSUED'
TADEBCT ='DEDB*CALLS'
TADEDBRC='DEDB*READ*OPERATIONS'
TADEDQCT='EXCLUSIVE*DEQUEUES'
TADENQCT='EXCLUSIVE*ENQUEUES'
TADGHNCT='DATA BASE*GHN CALLS*ISSUED'
TADGHNPC='DATA BASE*GHNP CALLS*ISSUED'
TADGHUCT='DATA BASE*GHU CALLS*ISSUED'
TADGNPCT='DATA BASE*GNP CALLS*ISSUED'
TADISRTC='DATA BASE*ISRT CALLS*ISSUED'
TADLDBIO='DATABASE*I/O'
TADLGNCT='DATA BASE*GN CALLS*ISSUED'
TADLGUCT='DATA BASE*GU CALLS*ISSUED'
TADLIPSB='PSB*NAME'
TADLUSSN='USSN*NUMBER'
TADOBUCT='OVERFLOW*BUFFERS*USED'
TADREPLC='DATA BASE*REPL CALLS*ISSUED'
TADTDQCT='TEST*DEQUEUES'
TADTNQCT='TEST*ENQUEUES'
TADUDQCT='UPDATE*DEQUEUES'
TADUNQCT='UPDATE*ENQUEUES'
TADUOWCC='UOW*CONTENTIONS'
TADWEDBC='WAITS FOR*DEDB*BUFFER'
TADWENQC='WAITS ON*EXCLUSIVE*ENQUEU'
TADWTNQC='WAITS ON*TEST*ENQUEUES'
TADWUNQC='WAITS ON*UPDATE*AND ENQUE'
TAPSBICT='TAPSB*SEGMENT*COUNT'
WKDLDBTM='ELAPSED*TIME FOR*DATABASE I/O'
WKDLICTM='THREAD*TCB*CPUTIME'
WKDLINWT='ELAPSED*WAIT TIME*INTENT*CONFLICT'
WKDLLKTM='ELAPSED*TIME FOR*PI LOCKING'
WKDLPLWT='ELAPSED*WAIT TIME*POOL*SPACE'
WKDSCETM='SCHEDULE*COMPLETED'
WKDSCSTM='SCHEDULE*STARTED'
WKSCHDTM='ELAPSED*TIME FOR*SCHEDULE PROCESS'
-New variables in MONITR 'TR' record dataset.
TRASACTV='CURRENT*ADDRESS*SPACE*ADDRESS'
TRASHWM ='ADDRESS*SPACE*HWM'
TRASPMHW='HWM*AUX*SLOTS*PMO'
TRASPMO ='AUX SLOTS*TO BACK*64 BIT PMO'
TRBAPMO ='BYTES*ALLOCATED TO*PRIVATE MEMORY'
TRBHPMO ='BYTES*HIDDEN IN*PRIVATE MEMORY'
TRBPMOHW='HWM BYTES*USABLE IN*PRIVATE MEM'
TRCDSAL ='CURRENT*DSA*LIMIT'
TRCDSAT ='CURRENT*DSA*TOTAL'
TRCEDSAL='CURRENT*EDSA*LIMIT'
TRCEDSAT='CURRENT*EDSA*TOTAL'
TRCMCSU ='CUMULATIVE*COMMON*SUBSPACE*USER'
TRCMSUHW='HWM*COMMON*SUBSPACE*USERS'
TRCMUSU ='CUMULATIVE*UNIQUE*SUBSPACE*USER'
TRCRCSU ='CURRENT*COMMON*SUBSPACE*USERS'
TRCRUSU ='CURRENT*UNIQUE*SUBSPACE*USERS'
TRDSAHWM='HWM*DSA*TOTAL'
TREDSAHW='HWM*EDSA*TOTAL'
TRFGFAIL='NO FROM*GUARD*FAILURES'
TRFGFSZ ='FROMGUARD*FAILURE*SIZE'
TRGDSAAC='CURRENT*GDSA*ACTIVE'
TRGDSAAL='CURRENT*GDSA*ALLOCATED'
TRGDSAHA='HWM*GDSA*ACTIVE'
TRGDSAHW='HWM*GDSA*ALLOCATED'
TRGETSSZ='GETSTOR*REQUEST*SIZE'
TRMEMLMT='MEMLIMIT*SIZE'
TRMLIMTS='MEMLIMIT*SOURCE'
TRNOLMO ='LARGE*MEMORY*OBJECTS'
TRNOSHMO='SHARED*MEMORY*OBJECTS'
TRNUMPMO='PRIVATE*MEMORY*OBJECTS'
TRPGPOOL='PAGEPOOLS'
TRRFPMHW='HWM*REAL*FRAMES*PMO'
TRRFPMO ='REAL*FRAMES*64-B*PMO'
TRRNTPGM='STATE*OF*RENTPGM'
TRSBFLMO='SHARED*BYTES*FROM*LARGE MEMORY'
TRSBLMHW='HWM*SHARED BYTES*IN LARGE MEMOR'
TRSTGPRO='STATE OF*STORAGE*PROTECT'
TRTRNISO='STATE OF*TRANISO'
TRUSUHWM='HWM*UNIQUE*SUBSPACE*USERS'
Jan 6: DEBUG 8 _N_= messages eliminated.
-Divide by 4096 for all durations was added.
Change 32.308 These new-in-XCOM-11.6 variables are now INPUT and some
FORMATS are decoded by new $MGXCMxx formats:
VMACXCOM XCORELEASE XCONXFER_AK XCOPDSMN_AK1 XCODATE_AK1
Dec 30, 2014 XCOTIME_AK1 XCONAME_AK XCOPDSMN_AK2 XCODATE_AK2
XCOTIME_AK2 XCOLUSER_AK XCOPDSMN_AK3 XCODATE_AK3
XCOTIME_AK3 XCOID_AK XCOPDSMN_AK4 XCODATE_AK4 XCOTIME_A
XCOTNAME_AK XCOPDSMN_AK5 XCODATE_AK5 XCOTIME_AK5 XCOPDS
XCOTOTCPU XCOTCBCPU XCOSRBCPU XCOZIIPZCPU XCOZIIPCCPU
XCOZIIPELIG XCONRECS2 XCONSEND2 XCONRECV2 XCONPUT2
XCONGET2 XCOALPRI2 XCOALSEC2 XCOALDIR2 XCOALRUNIT
XCOEATTR XCOLCIPH_LIST XCOCIPHER XCOPROTOCOL XCOLCHAR
XCORCHAR XCOLCCSID XCORCCSID XCOSCCSID XCOTCCSID XCOLTN
XCORTNQ XCOMIERR XCOMCERR XCOLDELIM_ENCODE
XCORDELIM_ENCODE XCOMIREPL XCOMCREPL XCOLDELIMITERS
XCORDELIMITERS XCOMIREPL_CNT XCOMCREPL_CNT XCOXMITF
Change 32.307 TYPE50 with VERSN50=2 ATTCHTYP=4 and LENGTH=254 caused an
VMAC50 INPUT STATEMENT EXCEEDED error because MXG expected 262
Dec 29, 2014 bytes. Now the 8-byte TY50RDQN Read-Queue-Name is INPUT
only when there are 8-bytes left. I presume that field
was added by an APAR.
Thanks to Steven Womer, OCLC, USA.
Change 32.306 If BLDSMPDB was used with RUNDAY=NO, the PDBAUDIT report
BLDSMPDB was incorrectly invoked, causing DDNAME NOT FOUND error.
Dec 29, 2014 Now, PDBAUDIT is not run when RUNDAY=NO is specified.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 32.305 DOCUMENTATION.
FORMATS -Format $MGPROD maps every member in MXG to a product.
Dec 27, 2014 This is work in progress for Spring, 2015.
====== Changes thru 32.304 were in MXG 32.12 dated Dec 23, 2014=========
Change 32.304 Support for RMF APAR OA45421 adds new function to the SMF
VMAC74 74 subtype 4 record, new variables in TYPE74ST dataset:
Dec 19, 2014 R744SISC='INDEX TO*SCM*DATA*SECTION'
R744SNSC='STORAGE*CLASS*MEMORY*DATA*SECTIONS'
R744SSAC='SCM AR*CONDITION*REQUIRED*RESTART'
R744SOSA='SCM AR*CONDITION*SUCCESSFUL*OP'
Change 32.303 Support for APAR OA44798, which adds two variables to the
VMAC22 TYPE22 Subtype 10 record, in dataset TYPE22_A:
Dec 19, 2014 SMF22SMT='MULTI-TARGET*PPRC*STATUS'
SMF22PMT='PREVIOUIS*MULTI-TARGET*PPRC*STATUS'
Change 32.302 MXG 32.06-32.11. The QAWPS program %INCLUDE of BUIL3005
QAWPS text was incorrectly changed to BUIL3206 in 32.06 and
Dec 19, 2014 then was BUILVVNN for each version instead of BUIL3005.
Thanks to Declan Vibert, World Programming, ENGLAND.
Change 32.301 MXG 32.11, WPS ONLY. A letter F left in macro _VARWECR
VMACWECR caused ERROR: DATA SET "WORK.WEBSCRAU" NOT FOUND".
Dec 22, 2014 SAS did not fail; it added the F to the dataset LABEL.
Thanks to Declan Vibert, World Programming, ENGLAND.
Change 32.300 MXG 32.11, WPS on ASCII ONLY, INVALID SMF RECFM. A test
VMACSMF left from Change 32.258 ("OR %SYSPROD(WPS EQ 1") caused
Dec 19, 2014 ERROR: UNRECOGNIZED RECORD FORMAT VBS on ASCII (because
WPS requires RECFM=S370VBS on ASCII). Test is removed.
Thanks to Declan Vibert, World Programming, ENGLAND.
Change 32.299 The default invocation of PDBAUDIT (contents of today's
BLDSMPDB "PDB's", comparison with yesterdays) is at the end of the
Dec 18, 2014 default BUILDPDB (PDB.SPUNJOBS), but that is prior to any
ASUMxxxx or other members that you added, so those other
PDB datasets would not be reported.
-This change adds the PRINTAUDIT parameter to BLDSMPDB
PRINTAUDIT=&MXGPRINTAUDIT
to automatically defer the %PDBAUDIT invocation until
after all of the INCLAFTR programs have executed.
-If you use BUILDPDB and your own includes, you can use
%LET MXGPRINTAUDIT=NO; /* temp replace default */
%INCLUDE SOURCLIB(BUILDPDB);
%INCLUDE - all of your stuff - ;
%PDBAUDIT(PRINTAUDIT=YES);
Change 32.298 Multiple UTILBLDP executions in a single job could get
UTILBLDP errors with missing parens and other nastiness if any
Dec 18, 2014 of the EXPDB*** parameters were used. EPDBINC EPDBCDE
EPDBVAR EPDBOUT are now all nulled at the end.
Change 32.297 New argument LIBNAMES to select which LIBNAMEs are used,
PDBAUDIT and new options added to PRINTAUDIT= argument:
Dec 18, 2014 LIBNAME=_ALL_ Default, search all open LIBNAMES:
A LIBNAME is open if:
-zOS it has been touched by a DATA or PROC step
or there was a LIBNAME statement used
-ASCII there MUST have been a LIBNAME statement
PRINTAUDIT=
YES - default - datasets and reports generated
NO - PDBBAUDIT becomes a null statement
DATAONLY - only builds datasets and does not print
any reports
PRINTONLYCHANGE - builds datasets and prints only
the report of differences
PRINTONLYCONTENTS - prints only the CONTENTS report
Change 32.296 New macro variable &MACJESN is added in VGETJESN so you
VGETJESN can delete records by their TYPETASK values. For example,
VMXGINIT the large number of SMF 30s written for OMVS tasks can be
Dec 18, 2014 can be deleted from your BUILDPDB datasets, using
//SYSIN DD *
%LET MACJESN=
%QUOTE( IF TYPETASK EQ 'OMVS' THEN DELETE; ) ;
%INCLUDE SOURCLIB(BUILDPDB);
Note that using MACJESN "instream" in your //SYSIN only
impacts this job, so you could separately run TYPE30
program and see all those OMVS task records.
Thanks to Richard Stuchell, Visa, USA.
Change 32.295 Variables XMLSYSTEM/TEMSSEQ in T112TEMS dataset created
UTILEXCL by SUBSTR(XMLRECORD) with INPUT XMLRECORD $VARYING32000,
VMAC112 so SAS defaults their length to 32000, when there is no
Dec 17, 2014 LENGTH statement. That is a problem ONLY because both
are in the BY list for PROC SORT, which then caused
ERROR: HOST SORT CAN NOT BE USED (SORTPGM=HOST/SORT)
WARNING: HOST SORT CAN NOT BE USED (SORTPGM=BEST)
because DFSORT/SYNCSORT don't allow a BY list over 32760
bytes long. Both are now shortened in a LENGTH statement.
-An ERROR occurs with the site option SORTPGM=HOST/SORT.
Instead, if SORTPGM=BEST is used, SAS issues the WARNING
and proceeds to use its internal sort. Knowing this now,
I recommend SORTPGM=BEST in your site's CONFIG.
-The UTILEXCL program has a long BY list and has noted in
comments that you must use OPTIONS SORTPGM=SAS.
-But how did this slip thru my QA? Well, it turns out that
SAS does NOT validate the BY list length if the dataset
has zero observations; I don't always have obs for every
MXG dataset. I think that lack of validation is a defect,
but now that I'm aware SAS may not find these errors for
me, I've revised the UTILVREF QA program to now calculate
the length of the BY list for every dataset and report
any new exposures so they can be corrected/documented.
-Note: There are other HOST SORT CAN NOT BE USED causes.
Thanks to Gaetan Martel, Intact Corportation Financiere, CANADA.
Change 32.294 This analysis example to compare two WEEK's TYPE72GO data
ANALCPU for each Service Class, matching intervals from midnight
Dec 17, 2014 had &PDBMXG..TYPE72GO instead of WEEK.TYPE72GO and so it
failed with LIBREF PDB IS NOT ASSIGNED.
Thanks to Jerry Schmidt, Northeast Utilities, USA.
Change 32.293 Warning added to ASUMDB2A when "Rollups" are detected.
ASUMDB2A Created when ACCUMACC is specified, rollups summarize
Dec 17, 2014 DB2 events, leaving no "detail" event data in DB2ACCT, so
you need to be aware Rollups impact ANALDB2R reports and
makes any summarization of the already summarized data of
questionable utility. The new log messages print:
MXGWARN: DB2 ROLLUPS DETECTED. SUMMARIZED VALUES CANNOT
MXGWARN: BE USED FOR DETAIL ANALYSIS. TOTAL AND MAX
MXGWARN: VALUES WILL BE CORRECT BUT AVERAGE VALUES WILL
MXGWARN: BE INCORRECT. USE WITH CAUTION.
Note that %ANALID reports tabulate which DB2 Subsystems
have enabled ACCUMACC; %ANALID reports are automatically
created by BUILDPDB to tabulate your input SMF data, or
it can be directly executed to read/report on your SMF.
using %ANALID(READSMF=YES,PRINT=YES,PDBOUT=WORK);
Change 32.292 -ASCII only. The MXG default SORTSIZE=400M is removed so
AUTOEXEC the default SORTSIZE is chosen. No problem was reported,
AUTOEXEU but this archaic value could negatively impact sorts.
AUTOEXEW -Optional ODS and DM commands are now enclosed in comment
Dec 16, 2014 blocks, rather than enabling by default.
Change 32.291 Support for GDPS SMF 105 Record APAR PI26702 (replaced
VMAC105 PI16853) INPUTS eight new two-byte fields into existing
Dec 16, 2014 variables SM105LTV/LOV/LPV/LSV/LUV/LCV/LJV/SN195LFV that
were previously only one-byte fields. When the APAR is
installed, it's flag bit detects its presence and inputs
the new fields transparently. One byte was too small if
a client had an LSS with a full 256 devices defined.
Thanks to Dave Clitherow, IBM GDPS Development, UK.
Change 32.290 "Archaic" IMS log processing programs, TYPEIMS7 to create
TYPEIMS7 IMS07 IMS07D IMA0A7 IMS0708 IMSUMRY datasets or JCLIMSL6
VMACIMS and ASMIMSL6 to create IMSTRAN.IMSTRAN, both now use the
VMACIMSA newer and larger (by about 5%) DLREXTIM for the IMSCPUTM
Dec 12, 2014 value instead of the original CP CPU time field, DLRTIME.
DLREXTIM was added in IMS 10.1 and recommended by IBM IMS
support. DLRTIME is also now kept in those datasets.
NOTE: THE RECOMMENDED, NON-ARCHAIC MXG IMS LOG PROCESSING
in JCLIMSTT that creates the IMS56FA IMS Transaction Data
Set was not changed: IMSCPUTM correctly used TPEXTIME.
-IMSCPUTM/DLRTIME/DLREXTIM contain ONLY the CP CPU time
and DLRAZAAP/TPEZAAP contain ONLY zIIP/zAAP CPU time.
Thanks to David Christianson, State of Wisconsin, USA.
Change 32.289 -RMF III processing performance enhancements, message
ADOCRMFV improvements, fixes, and documentation upgrades.
ASMRMFV -Improved ASMRMFV handling of all Return Codes, Reason
CLRMFV Codes, and Info Codes into messages eliminating some
JCLRMFV instructions.
JCLCRMFV -Severe error messages RMFV003S and RMFV007S will now
JCLDRMFV provide the failing subroutine name for better diagnosis.
Dec 20, 2014 In prior ASMRMFV versions only the general name of the
failing service (OPEN, CLOSE, etc.) was shown.
-Messages RMFV024I, RMFV025I, RMFV028I, RMFV029*,
RMFV031I, RMFV037I, and RMFV999I are modified for better
alignments and legibility.
-Message RMFV028I for Indexes is now a multi-line message.
-Messages RMFV012I with Sample Begin/End Date/Time stamps
always be issued even if NODETAIL is in effect.
-When the NODUPDSN option is in effect message RMFV101I
will include the number of DSNAME COMPARES in both Detail
and Summary Reports as an indicator of the overhead
incurred detecting duplicate data set names.
-Message RMFV105I will now show the table name for the RMF
III Data Set Header as DSI instead of DSH. This was the
only report table id not conforming to the actual RMF III
internal id which is ERBDSIG3.
-Using the RMF III internal table identifications
consistently allows for more efficient table validation.
ASMRMFV documentation and source code will still refer to
this table as the DSH or Data Set Header.
-When the POLICY option was specified with the SIZE option
no Service Policy information was produced. The SIZE
option provides a quick inventory of the space usage,
index usage, and attributes of all allocated RMF III data
sets with no RMFBSAM output.
-When the SIZE option is used now any RMF III data set
filters such as NODUPDSN, SYSPLEX=, SYSTEM=, Date/Time,
and DOW= (and their aliases) will be honored to provide
Index and Space usage for only selected data sets. In
prior ASMRMFV versions all data set filters were ignored
when SIZE was specified.
-The SIZE option will now bypass opens and closes for
unneeded non-VSAM data sets RMFBSAM, RMFFILT, and RMFSKIP
for better performance.
-Summary messages RMFV100I, RMFV012I, and RMFV014I will
now also be issued when SIZE is in effect.
-SZ is no longer an alias for the SIZE option, it is now
an alias for SHOWZERO. Please use SI as a SIZE alias
instead.
-New parameters SHOWZERO (alias SZ) and NOSHOWZERO (alias
NOSZ) control display of RMF III table statistics in
message RMFV105I when there are zero occurrences of a
particular table. The default is SHOWZERO providing the
same behavior as prior ASMRMFV versions.
-These parameters replace the ZEROPRT/NOZEROPRT options
and respective aliases since the purpose was unclear from
the names. However, the old parameters are still
accepted without error.
-SHOWZERO/NOSHOWZERO parameter documentation is added to
Section 6 "Report Control Parameters" in ASMRMFV and
ADOCRMFV members. The SIZE option is also updated.
-Updates for revised messages are made to Section 12
"Messages" in ASMRMFV and ADOCRMFV members.
-Section 25 "Summary" is updated to add new parameters.
-REQUIREMENT: In order to implement these features the
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Change 32.288 SMF Type 22 log message UNKNOWN SECID=40 printed because
VMAC22 the CPU segment is only 6 bytes, MXG read 7. Obviously,
Dec 6, 2014 this is NOT a frequently used SMF record! Error was
introduced by Change 32.064 in MXG 32.03.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Change 32.287 VMXGGETM was checking the length of NRECORDS when it
VMXGGETM should have been checking for a value of MAX, when the
Dec 6, 2014 NRECORD=MAX option was chose, causing log message
NOTE: Variable MAX is uninitialized.
Change 32.286 A second execution of %VMXGSRCH might do nothing; both
VMXGSRCH generated WARNING: MULTIPLE LENGTHS FOR BY VAR MEMNAME
Dec 3, 2014 but only the first execution executed your search.
Thanks to Rodger Foreman, Trans Union, USA
Change 32.285 A RNAME (Minor Queue Name) can contain hex characters
VMACRMFV so new variable ENTMINNAHEX with $HEX72 format provides
Dec 3, 2014 the hex values when ENTMINNA contains non-printables.
These additional variables will also be updated and this
change text will be revised when completed.
Dataset Variable
CMFVEN ENRERNM
CMFRV RVRERNM
TYPEMIM MIMCMRNM
TYPEPDL RTYPEU
TMVSNQ NQMINOR
TYPE87 SMF87QSCAN_RNAME
TYPE796 TYPE796MIN
TYPE797 TYPE797MIN
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 32.284 -INVALID THIRD ARGUMENT TO FUNCTION SUBSTR in NDM 'PT' SMF
VMACNDM record when LOCNULL=1 is corrected by removal of SUBSTR.
Dec 3, 2014 -Additional NDMRTYPE values of A# C# D# S$ U# UK are now
also output in dataset NDMAE.
-Protection for ancient short records added so that now
every single NDM record I've ever received is tested.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Thanks to Michael Oujesky, DTCC, USA.
====== Changes thru 32.283 were in MXG 32.11 dated Dec 2, 2014=========
Change 32.283 Debugging PUTLOG removed, printed multi-million lines,
VMACRMFV causing a refresh and re-date of 32.11.
Dec 2, 2014
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 32.282 ASCII only. If the dataset for which you are searching
VGETOBS was a VIEW, it was found, but the DSNAME returned was a
Dec 2, 2014 period and the member type was blank. The period should
have been in the VGETOBS variable and the member type
should have been set to VIEW. The VGETDSN variable was
also incorrectly set to period on z/OS, all fixed now.
Thanks to Karl Olafsson, Advania, ICELAND.
Thanks to Hreinn C. Hreinsson, Advania, ICELAND.
====== Changes thru 32.281 were in MXG 32.11 dated Dec 1, 2014=========
Change 32.281 MXG 32.02-32.10. BUILDPDB fails if //PDB is on tape after
VMAC74 Change 32.031 added code to VMAC74 that caused SAS to try
Nov 28, 2014 to open PDB.TYPE748A and PDB.TYPE748R simultaneously, and
that can't be done when //PDB is a sequential library.
Code revised to create a temporary copy first. BUT:
WE RECOMMEND YOU NEVER USE //PDB ON TAPE for the BUILDPDB
job, not only because you can't have two datasets open,
but because BUILDPDB first writes many datasets to the
PDB, but then has to read them back in (e.g.,RMFINTRV has
to read ALL of the TYPE7xxx RMF datasets to create that
summary PDB.RMFINTRV dataset), and since there is no
dictionary on sequential libraries, SAS has to read every
record to find the first dataset, then rewind back to the
start, read to find the second dataset, etc., causing
massive increase in elapsed time. And consider what
happens when it's a five volume tape dataset that has to
have each volume mounted, read, dismounted, etc., etc.
Instead, make your //PDB DD a temporary DASD file for
the building of the PDB data library, but then add
a //REALPDB DD UNIT=TAPE,DSN=YOUR.REAL.PDB,. . . and a
PROC COPY IN=PDB OUT=REALPDB MEMTYPE=DATA;
to archive the PDB to tape efficiently.
-TYPS74 fails the same way/same reason if PDB is on TAPE.
Thanks to Jerry Schmidt, Northeast Utilities, USA.
Change 32.280 UNUSED Change Number.
Nov 22, 2014
Change 32.279 Mobile Workload support was enhanced by adding variables
MOBWRK02 SMF89IST SMF89EST SMF89ST SMF89UST in MOBWRK02, needed to
MOBWRK05 determine which of the SMF89 starting timestamps should
Nov 26, 2014 be used to set the STARTHR, and MOBWRK05 was updated to
use the STARTHR in all the merges, which is needed for
hours when an LPAR was moved to a different CEC.
Thanks to Graham Harris, RBS, ENGLAND.
Change 32.278 TYP11902 dataset variables TTTTLSSP/NC/ST/FP/UI wrong
VMAC119 when IBM inserted 16 bytes after TTDUAKRC and before the
Nov 26, 2014 relocatable OFF11903 segment, but MXG overlooked using
OFF11903 in the INPUT (probably because prior iterations
of this SMF 119 type record happened to have OFF11903 at
the COL after TTDUAKRC.) Both the OFF11903 and OFF11904
segments are now corrected and protected for inserts.
-New variable added to TYP11902 dataset, discovered in the
z/OS 2.1 IP Programmers guide, 2014 edition, which does
not show those 16 bytes after TTDUAKRC.
TTTTLSNC4='ATTLS*NEGOTIAGED*4-BYTE*CIPHER'
Thanks to Michael Creech, Black Knight Financial Services, USA.
Change 32.277 Crypto variable execution times R7023MET and R7023CRT are
VMAC7072 now correctly multiplied by the R7024SF Scaling Factor;
Nov 25, 2014 that needed multiply was overlooked when they were added.
Thanks to Michael Creech, Black Knight Financial Services, USA.
Change 32.276 Variables XCODSN2='REMOTE*DSN*WITH*G000V00' is now KEPT
VMACXCOM in TYPEXCOM; the adjacent XCODSN1 was also overlooked and
Nov 21, 2014 is now kept, but that Local DSNAME value was also in the
Dec 16, 2014 variables LCLDSN, XCOLDSN1, and in the FILE= argument in
Dec 22, 2014 the LASTMSG variable.
-Dec 16: This support extended back to version 11.5.
-Dec 22: Lines longer than 72 characters reduced.
Thanks to Rosa Maria Martinez Alonso, Bustia, SPAIN.
Change 32.275 Variable NDMRTCPU in NDMRT dataset was incorrectly INPUT.
VMACNDM The +2 after NDMGPE1D no longer exists.
Nov 20, 2014
Thanks to Michael Oujesky, DTCC, USA.
Change 32.274 -The PDBAUDIT report of sizes of datasets in your PDB's is
PDBAUDIT enhanced with SORTEDBY option so that you can choose
Nov 27, 2014 the printed report order as deeded. The default order is
SORTBY=LIBNAME DESCENDING FILESIZE MEMNAME
but you can alter the order any way you wish as:
SORTBY=DESCENDING FILESIZE MEMNAME
-Numeric values are now formatted with commas and a new
column is added with FILESIZE in MGBYTES, and labels
rather than variable names are printed.
Change 32.273 ASCII execution only. Variable LIOBTIME in RACF0200
VMACRACF dataset was incorrect for times from midnight to 1 am.
Nov 20, 2014 The EBCDIC logic was copied to the ASCII code area.
Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
Change 32.272 ERROR FOUND IN XAMSYS FILE. RECORD WAS NOT OUTPUT.
VMACXAM _N_=1 COL=8987 SEGNAME=CMS SEGSTART=8979 SEGLEN=16448
Nov 18, 2014 A second INPUT +SKIP in the STOSHR record misaligned.
Thanks to Randall Springs, BB&T, USA.
Change 32.271 The "true" PDB.SMFINTRV dataset built by BUILDPDB, with
SMFINTRV consolidated MULTIDD='Y' observations, ACCOUNTn's added,
VMAC30 and with the true count of tape devices allocated for
Nov 19, 2014 each interval, can now be built directly from SMF data,
or from these datasets in //WORK and/or //PDB:
TYPE30TD TYPE30_1 TYPE30_5 and TYPE30_V=SMFINTRV.
Use %INCLUDE SOURCLIB(TYPE30,SMFINTRV); to build ONLY the
PDB.SMFINTRV dataset from SMF; use TYPS30 to also create
all TYPE30xx datasets. This %UTILBLDP example shows how
other SMF records can be added to the processing in one
pass of the SMF file, with USERADD= adding SMF type 42,
and INCLAFTR=SMFINTRV adding creation of PDB.SMFINTRV:
%UTILBLDP(BUILDPDB=NO,
USERADD=30 42,
INCLAFTR=SMFINTRV,
OUTFILE=INSTREAM);
%INCLUDE INSTREAM;
(The _STY30UV Data Set Sort macro in TYPS30 to sort the
WORK.TYPE30_V dataset to the PDB does not name the sort
output to PDB.TYPE30_V, but instead, it simply sorts the
unconsolidated TYPE30_V dataset, naming it PDB.SMFINTRV.
Fortunately, by design, the %VMXGWORL invocation looks
first for the _WTY30UV token, which is WORK.TYPE30_V, but
if that does not exist, then then the _LTY30UV token,
which is PDB.SMFINTRV is used, so SMFINTRV can be used
with either TYPE30 or TYPS30 programs transparently.)
To identify the source of your PDB.SMFINTRV dataset,
the PROC CONTENTS DATA=PDB.SMFINTRV; will show
Built By Data Set Label text
TYPS30(_STY30UV) TY30UV: TYPE 30 INTERVAL EVENT
SMFINTRV DB30UV: SMFINTRV FROM SMFINTRV
BUILDPDB/3 DB30UV: BUILDPDB - SMFINTRV
-"Missing value" messages during _STY30U6 execution were
observed and eliminated with VMAC30 "cosmetic" changes.
Thanks to Cesar V. Cocco, Verisk, USA.
Change 32.270 The IHDRBVIR "BVIR Header" exit member was overlooked but
IHDRBVIR it now exists, and is taken after these header variables
VMACBVIR BVIRHIST BVIRLEN BVIRTYPE BVIRVERS CLUSTER DLIBSEHX
VMXGINIT DLIBSEQN DURATM ENDTIME GLIBSEHX GLIBSEQN GMTOFFBV
Nov 19, 2014 MACHMODL MACHSERL MACHTYPE NODEID SMFTIME STARTIME
TMZOFF VECDLEVL VECDLEVL
have been input and can be used to select which BVIR data
records are processed. As with all IHDRxxxx exits, when
EDITed with your criteria, that will apply to ALL jobs
that process the BVIR data, but each IHDRxxxx member also
also defines a unique macro variable, here MACBVIRH, that
can be used in the //SYSIN text to tailor a specific job.
See comments in the IHDRBVIR and IMACFILE exit examples.
Thanks to Ravi Kumar, Bank of America, USA.
Change 32.269 Documentation of two common ODS errors on z/OS:
ADOCODSO -NOTE: IMAGE NAME PREFIX WILL BE TRUNCATED TO 5
Nov 19, 2014 CHARACTERS TO COMPLY WITH Z/OS FILENAME RULES.
ERROR: CANNOT WRITE IMAGE TO UXMCBH.CPUS0.GIF. PLEASE
ENSURE THAT PROPER DISK PERMISSIONS ARE SET.
No output destination was defined so ODS is trying to
create datasets with userid.SGPLO.PNG and will almost
always fail, or ODS LISTING CLOSE; was not used.
-ERROR: THE JAVA PROXY IS NOT RESPONDING.
ERROR: THE JAVA PROXY'S JNI CALL TO START THE VM FAILED.
ERROR: UNABLE TO LOAD THE JAVA VIRTUAL MACHINE.
PLEASE SEE THE INSTALLATION INSTRUCTIONS OR
SYSTEM ADMINISTRATOR.
Region size too small
Change 32.268 The new ANALDSCK ("DSNAME Check") reads all SMF records
ANALDSCK (SMF 6 14,15,17,18,42.6,60,61,65,66,62,64) that contain
Nov 19, 2014 a DSNAME or ENTRNAME and selects the observations that
contain the full DSNAME, or the High-Level-Index, or any
text you choose, since the INDEX(DSNAME,'text') function
is used for the selection criteria. %VMXGPRAL is invoked
in this example to print all of the found observations.
Thanks to Jack Newburn, Los Angeles County Education, USA.
Change 32.267 Variables CRYAC1U and CRAM3U (1024/4096 utilizations) in
VMAC7072 the TYPE70X2 (PCI CRYPTO ACCELERATOR PCICA) need to be
Nov 19, 2014 multiplied by 100, like the other percentages.
Thanks to Michael Creech, Black Knight Financial Services, Inc., USA
Change 32.266 For CICS, DB2 variable QWHCCV is an alternate source for
VMXGUOW the CICS transaction name, so it is now added to the list
Nov 19, 2014 of transaction names in PDB.ASUMUOW dataset.
Change 32.265 Support for a second CMODNAME='USER' CMODHEAD='USER' CICS
IMACICDV optional segments for dataset CICSTRAN. The first segment
IMACICVS will be tailored in the IMACICUS member and the second
UTILEXCL segment' CMODNAME/HEAD values are set to CMODNAME='USER2'
Nov 18, 2014 and the new IMACICVS member is listed to be tailored for
the second segment.
Thanks to Tom MacCabe, Dominion Resource Services, USA.
Change 32.264 WPS ONLY. The ancient test for &SYSVER GE 6 (to ensure
WEEKBLDD the "new in V6" CLEAR function was available, to then
WEEKBLDT CLEAR the LIBNAME) failed under WPS, with a spurious
WEEKBL3D error message about BLKSIZE mismatch with LRECL=133!
WEEKBL3T The test needs to use &SASVER which is 8 or greater for
Nov 18, 2014 both SAS and WPS; SYSVER returns the current SAS version
which is also 8 or greater, but WPS returns a 3.
Thanks to Simone Niemczura, Sungard, USA.
Change 32.263 SAS fails to PROC COPY a DATA library with an ITEMSTORE,
DOC to a tape or sequential format library on disk, with:
ERROR: An item store cannot be created in a sequential library.
ERROR: File PDBINTRV.REGSTRY.ITEMSTOR has not been saved
Nov 14, 2014 because copy could not be completed.
All PROC COPY statements now include the MEMTYPE=DATA
option to prevent the error; most COPY's did have either
MT=DATA or MEMTYPE specified.
Thanks to Cesar V Cocco, Verisk, USA.
Change 32.262 -If you are running BLDSMPDB with Week-To-Date WTD, the
BLDSMPDB WEEKKEEP logic in BLDSMPDB failed if you used a wild card
VMXGALOC syntax (ASUM: for example).
Nov 12, 2014 -If you used WTD logic with AUTOALOC on ASCII and used
Dec 15, 2014 FORCEDAY to do a rerun the data went into the WEEK-1
dataset rather than the correct week. Dec 12: Typo fixed.
Change 32.261 If a tailored program compiled _CDE102 first, variable
VMACDB2H JOB could be length $12, because there was no LENGTH
Nov 11, 2014 statement, causing JOB=(SUBSTR(QWHCCV,1,8) to set the
length from the length of QWHCCV. A LENGTH statement is
added in VMACDB2H to protect the expected length $8.
Thanks to Paul Volpi, UHC, USA.
Change 32.260 Executing MXG on Linux to process AS400 data, a forward
VMXGDSNL slash in the path name was fine on windows but was taken
Nov 12, 2014 to be a divide symbol under linux, causing a numeric
operator to be looked for and not found. The use of the
%QUOTE() was required to resolve the intended meaning of
the slash, but the code used ONLY for TYPEQACS processing
has been rewritten to be sensitive to the execution
platform.
FOR ZOS IT WILL USE THE PENULTIMATE NODE OF THE DSNAME
Thanks to H. Sterling James, DST Systems Inc.
Change 32.259 DB2 IFCID=220: "NOTE: Invalid Argument to function INPUT"
VMAC102 prints a hex dump of the first two instances. MXG's INPUT
Nov 10, 2014 statement had not been validated with IFCID=220s and its
misalignment had not been previously observed.
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 32.258 Variable SHIFT (the shift of INTBTIME) is now added to
ASUMSMFI the PDB.ASUMSMFI dataset which summarizes PDB.SMFINTRV.
Nov 10, 2014
Thanks to Frank Lund, EVRY, NORWAY.
Change 32.257 RMF Type 78 Subtype 2 record always contain the Virtual
FORMATS Storage Section, and can optionally contain Private Area
VMACID and Subpool Statistics (enabled by listing JOB names to
VMACSMF be monitored in the VSTORE options in your ERBRMFxx).
VMAC78 The %ANALID report now recognizes and reports the records
NOV 7, 2014 78.2.1:VIRTUAL STORAGE ACTIVITY
78.2.2:VIRT+PRIVATE AREA/SUBPOOL
so you can tell if there were any of those JOBS that were
initiated during this interval.
Thanks to Ray Dunn, CIGNA, USA.
Thanks to Keith C. Shaffer, CIGNA, USA.
Change 32.256 These duration variables in dataset TYPEMVAO
VMACMVAO ACTIVETM CPUTOTAL CPUMAX ELAPSTOT ELAPSMAX TAKETIME
Nov 7, 2014 SUCCTIME SUCRETTM FAILTIME FAIRETTM
were all incorrectly multiplied by 60; I think the first
data in 2010 was in minutes, but now is in seconds, so
that multiply is now removed.
Thanks to Christa Neven, KBC Group, BELGIUM.
Change 32.255 The HIGHCONTRAST style that was used as the parent for
MXGSTYL1 MXGSTYLE1 was changed (unexpectedly, unclear when) to
Nov 6, 2014 have a black background and all of the colors were also
modified. Changing the parent to PRINTER resolved the
problem.
Thanks to Richard Way, Office Depot, USA.
Change 32.254 z/VM Variable INTERVAL and HFRATE can be wrong if there
FORMATS is no SAMPLE PROFILE (1.09) MONWRITE record written at
VMACVMXA startup. They are missing values if there is only one
Nov 4, 2014 system's MONWRITE data being read, but if MONWRITE data
from multiple systems is concatenated, the variables will
be non-missing and wrong values, as they were retained
from the prior systems 1.09 record. Now, both variables
are set to a missing value in the 1.04 (Monitor Start) to
clear the retained values. Fortunately, neither variable
is used in any MXG processing.
-Cosmetic, in FORMATS, the RECTYPE format MGVXATY had not
been updated for recently added MONWRITE records.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.253 zOS only and only if daily datasets are GDGs, MONTHBLD:
BLDSMPDB It is possible that unless the GDGs are in precisely the
MONTHASC right order (today is 0, yesterday -1, etc,) that the
MONTHBL3 MONTHBLD logic could cause you to have duplicate and/or
MONTHBLD missing data in your MONTHLY datasets. All of these
MONTHDSK members now look for daily data that is in the current
VSETMNTH week - that is the last week that started before
Nov 1, 2014 month-end and if the ZDATE is in that week will continue
Nov 6, 2014 to process that record. On zOS, all 7 days are always
set by VSETMNTH to ensure we get all of the data from the
current week into the process.
Change 32.252 Support for EzSM 4.2.0 creates two new datasets, one each
EXEZSMT2 from splitting subtype 2 and 3, and subtypes 1, 2, 3, 7
EXEZSMV3 are all now decoded and variables created. Only header
IMACEZSM variables are output for subtypes 4, 5, and 6, pending
VMACEZSM test data for those subtypes.
VMXGINIT dddddd dataset description
Oct 31, 2014 EZSM02 EZSM02 EZSM02: USER START OR END OR END
EZSMT2 EZSM02T EZSMT2: TRANSACTION START OR END
EZSM03 EZSM03 EZSM03: MVS CONSOLE COMMAND
EZSMV3 EZSMV3 EZSMV3: MVS VARY COMMAND
Thanks to Perry Lim, Union Bank, USA.
Change 32.251 TYPE30 variables EXCPNODD/TODD/TOTL,IOTMNODD/TODD/TOTL
VMAC30 were inconsistent when NUMDD=0. MXG set EXCPNODD=0 if
Oct 30, 2014 it was missing, to prevent MISSING VALUE messages, but
when NUMDD=0, there ARE no DD segments, so leaving
EXCPNODD=. when NUMDD=0 makes better sense. And while
NUMDD=0 did set IOTMTODD=., that caused the calculated
IOTMTOTL to be missing when IOTMTOTL=IOTMTOTL-IOTMTODD
was executed. All are now correct and consistent; when
NUMDD=0 the two NODDs will be missing and TOTL correct
in both TYPE30_V and PDB.SMFINTRV datasets. While MULTIDD
observations (30's with ONLY DD segments) don't have a
Unit Record segment (so IOTMTOTL in TYPE30_V will be a
missing value), the BUILDPDB/ONLYINTV consolidation of
all of those MULTIDD='Y' observations from TYPE30_V into
the PDB.SMFINTRV observation sums those variables.
Thanks to David Campbell, SunTrust, USA.
Change 32.250 -RMF III Data Set selection enhancements, fixes, and
ADOCRMFV documentation upgrades.
ASMRMFV -New parameter SYSPLEX= (alias PLEX=) provides for the
CLRMFV selection of RMF Monitor III data sets based on the
JCLRMFV originating Sysplex Name and is explained more below.
JCLCRMFV -New parameter SYSTEM= (aliases SYSID=, SID=) provides for
JCLDRMFV the selection of RMF Monitor III data sets based on the
Nov 29, 2014 originating System Id and is explained more below.
-New parameters SHOWMATCH (alias SM) and NOSHOWMATCH
(alias NOSM) control display results of SYSPLEX= and
SYSTEM= value matching. The default is NOSHOWMATCH.
-New parameters NODUPDSN (alias NODUP) and DUPDSN (alias
DUP) control detection of duplicate RMF Monitor III data
set names as input.
-The default for NODUPDSN/DUPDSN is DUPDSN that provides
the previous ASMRMFV behavior of no duplicate detection.
-New parameter DUPERR=ABEND/WARN/IGNORE controls what
happens when NODUPDSN is in effect and an RMF III data
set name duplicate is detected. The default is
DUPERR=WARN. DUPERR is ignored with DUPDSN in effect.
-SYSPLEX= and SYSTEM= do NOT allocate any RMF Monitor III
data sets, but just filter those already allocated
whether by JCL or INDSNAME= patterns.
-The SYSPLEX= and SYSTEM= parameters may be useful for
large sites with many Sysplexes and/or System Ids that
have an established comprehensive set of RMF III data
sets used for MXG PDB builds. But a complete set may not
be needed for all uses such as for certain ad hoc
studies.
-Use of SYSPLEX= and/or SYSTEM= avoids having to set up
special groups of RMF III data sets in JCL or as
INDSNAME= patterns just for special needs. The standard
configuration set of RMF III data sets can always be
used, but filtered as needed with SYSPLEX= and/or
SYSTEM=.
-Note that SYSPLEX= and SYSTEM= when specified do add some
overhead because every data set has to be opened to
examine the originating Sysplex Name and System Id
whether it will be filtered or not.
-However, that drawback is possibly offset with the
avoidance of inconvenience and errors associated with
tailoring of JCL or INDSNAME= patterns for special PDB
builds.
-Defaults are SYSPLEX=ALL and SYSTEM=ALL meaning that no
RMF Monitor III data set filtering occurs based on
Sysplex or Sysid origin as in prior ASMRMFV versions.
-SYSPLEX= and SYSTEM= support any of the following formats
for values:
SYSPLEX=Range1 SYSTEM=Range1
SYSPLEX=Range1:Range2 SYSTEM=Range1:Range2
SYSPLEX=Pattern1 SYSTEM=Pattern1
SYSPLEX=Pattern1:Pattern2 SYSTEM=Pattern1:Pattern2
SYSPLEX=Pattern1:Range1 SYSTEM=Pattern1:Range1
SYSPLEX=Range1:Pattern1 SYSTEM=Range1:Pattern1
-A Range is one or more alphanumeric (A-Z,0-9) or national
(@,#,$) characters allowed in a Sysplex Name or System
Id.
-Range1:Range2 specifies a low/high Range Pair of values
where the source Sysplex or Sysid string must be equal or
greater than Range1 and also equal to or less than Range2
for the data set to be selected.
-Patterns provide generic matching with the Sysplex and
System fields in the Data Set Header (DSH) table for
flexibility.
-A Pattern can include any of the characters in a Range
and MUST also include at least 1 special pattern
character to be recognized as a Pattern. Otherwise it is
handled as a Range.
-Supported pattern characters are:
Pattern Character Matches In Source String
----------------- ------------------------------
'*' (Asterisk) 0 or more characters
'%' (Percent sign) 1 Non-blank character
'+' (Plus sign) 1 Numeric character (0-9)
'_' (Underscore) 1 Alphabetic character (A-Z)
'.' (Period) 1 National character (@,#,$)
-The colon ':' character is a required delimiter when two
values are provided for SYSPLEX= or SYSTEM=.
-Either or both SYSPLEX= and SYSTEM= parameters may be
coded and each repeated as needed (subject to internal
table size limits).
-New severe error message RMFV034S is displayed when a
Range or Pattern filter table is exhausted. The limit
for SYSPLEX= Ranges or Patterns is 16 each. The limit
for SYSTEM= Ranges or Patterns is 64 each. If higher
limits are needed please contact MXG Technical Support.
-When both SYSPLEX= and SYSTEM= are specified the match
results are logically ANDed so that matches must occur
for BOTH Sysplex Name and System Id for the data set to
be selected.
-For more details and examples on Range and Pattern usage
with SYSPLEX= and SYSTEM= for RMF Monitor III data set
selection see the ASMRMFV, ADOCRMFV, JCLRMFV, JCLCRMFV,
and JCLDRMFV Sourclib members.
-New information message RMFV034I is displayed when
SHOWMATCH is in effect. If a match occurs for SYSPLEX=
and/or SYSTEM= the original source string as well as the
Range Pair or Pattern that matched are displayed.
-When no matches occur for all Ranges and/or all Patterns
this condition is also shown.
-SHOWMATCH can be useful for testing the new SYSPLEX= and
SYSTEM= parameters. SHOWMATCH has very low overhead and
can be used freely without concern for a performance
impact.
-Add new variable severity message RMFV036* (*=I,W,E) when
a duplicate data set is found and NODUPDSN is in effect.
-NODUPDSN adds some CPU overhead because the current RMF
III data set name being opened is compared with all the
previous data set names already processed.
-Although duplicate data set name detection is a simple
compare with a basic counter loop, the number of
comparisons rises rapidly with the number of RMF III DD
allocations:
Maximum
Number RMF III Duplicate
Data Sets Input Comparisons
--------------- -----------
2 1
3 3
4 6
5 10
10 45
50 1,225
100 4,950
500 124,750
1,000 499,500
1,500 1,124,250
1,635 1,335,795 Default 32K TIOT size
2,000 1,999,000
2,500 3,123,750
3,000 4,498,500
3,273 5,354,628 Maximum 64K TIOT size
-Users who are confident they do not have any duplicate
RMF III data sets being input to ASMRMFV do not need to
code the NODUPDSN option.
-However, new ASMRMFV users may want to use NODUPDSN at
least once to insure their ASMRMFV run does not contain
duplicate data sets.
-Duplicates are also more likely using the Dynamic Method
with the INDSNAME= parameter due to possible overlapping
of data set name patterns.
-With the addition of the NODUPDSN, SYSPLEX=, and SYSTEM=
parameters RMF III data set filters are applied in the
following order (if coded):
1) NODUPDSN Prevent duplicate dsname input
2) SYSPLEX= Select Sysplex dsname origin(s)
3) SYSTEM= Select LPAR dsname origin(s)
4) Date/Time FROMDATE=,TODATE=,FROMTIME=,TOTIME=,WINDOW
5) DOW= Day of the Week
-Filter messages RMFV006I have been reordered in the log
to correspond with the general order that filters are
applied during an ASMRMFV run.
-A new summary RMFV014I message is added with RMF III data
set filter (bypass) counts for Total, Duplicates, Sysplex
Name, System Id, Date/Time, and Day of the Week filters.
-Options message RMFV036I showing RMF III table selections
is now an RMFV006I filter message and is now part of that
multi-line message group. These are properly filters not
just options.
-Several filters in an RMFV037I option message are moved
to an RMFV006I message as these are also properly filters
not just options.
-Add new Abend Reason code 84 when DUPERR=ABEND and a
duplicate data set name is found with NODUPDSN in effect.
-Message RMFV050S for the internal Dsname Table full
condition is now message RMFV079S.
-DDNAMEs dynamically allocated by the TSO Clist CLRMFV
will now have a RMFC DDNAME prefix that is also supported
by ASMRMFV instead of an RMFV DDNAME prefix as before.
-Thus the DDNAME prefix in messages now indicates:
Prefix Allocation Method
------ -------------------------------
RMFC CLRMFV Clist Dynamic Allocation
RMFD INDSNAME= Dynamic Allocation
RMFV Static JCL DD statement
-Split message RMFV049* into RMFV049* for CSI Catalog
errors only and RMFV050* for CSI Dsname entry errors
only. Before both errors used the same message skeleton.
-All variable severity messages with ids RMFVnnn* (*=
I,W,E,S) are now initialized only once during ASMRMFV
startup according to the settings of the various
*ERR=ABEND/WARN/IGNORE options.
-This improves performance because in prior ASMRMFV
versions some messages were reused and were reset
according to severity multiple times during execution.
-There is a new variable severity message RMFV056*
(*=I,W,E) issued just for pattern errors. Before these
were part of RMFV004* messages.
-CSI severe error message RMFV043S was not being built
with variable error text correctly when the condition
occurred.
-Issue Index messages RMFV028I and RMFV029* only if the
RMF Monitor III Data Set is selected to reduce overhead.
-Issue Space messages RMFV030I and RMFV031I only if the
RMF Monitor III Data Set is selected to reduce overhead.
-When ASMRMFV execution methods were mixed in a single run
(this is supported) the summary message RMFV101I was not
reporting statistics by DDNAME prefix correctly.
-For example, using a static JCL DD statement for an RMF
data set while also using the CLRMFV Clist or using the
INDSNAME= parameter would be a mixing of methods. Now
multiple RMFV101I messages will be issued for RMFC*,
RMFD*, and RMFV* DDNAME prefixes as required.
-Last Open message RMFV017I is now an RMFV008I message and
is now part of that multi-line display group produced as
each RMF III data set is opened.
-Origin message RMFV009I is split into two parts so that
the Sysplex and System Id information appears near the
point in the ASMRMFV log where SYSPLEX= and SYSTEM=
matching occur.
-The second part of the original RMFV009I message is now
message RMFV017I showing RMF and Z/OS versions and the
timestamp value when these were first in effect.
-The MAXFINDS= parameter limit is lowered to a more
reasonable 99,999 maximum down from a 99,999,999,999
value.
-Error messages that display an invalid character both in
EBCDIC and in hex are now improved for better visibility.
-Explicit coding of DOW=ALL, SYSPLEX=ALL, or SYSTEM=ALL is
documented to explain that this resets the corresponding
internal table(s) to empty. Any prior specifications for
the corresponding table(s) in the current ASMRMFV run are
lost. Any subsequent specifications will be added to the
respective table(s) during the run.
-Definitions for the terms "Keyword", "Range", and
"Pattern" are added to Section 2 "Terminology" in ASMRMFV
and ADOCRMFV member documentation.
-NODUPDSN/DUPDSN, SYSPLEX= and, SYSTEM= parameter
documentation is added to Section 5 "Input Data Selection
Parameters" in ASMRMFV and ADOCRMFV members.
-SHOWMATCH/NOSHOWMATCH parameter documentation is added to
Section 6 "Report Control Parameters" in ASMRMFV and
ADOCRMFV members.
-DUPERR=ABEND/IGNORE/WARN parameter documentation is added
to Section 8 "Error Handling Parameters" in ASMRMFV and
ADOCRMFV members.
-Updates for new and revised messages are made to Section
12 "Messages" in ASMRMFV and ADOCRMFV members.
-A new Filter Scope Table is added to Section 13 "Filtered
Records" in ASMRMFV and ADOCRMFV members. This shows the
data filters available in ASMRMFV, to which RMF III
tables they are applied, the order of application, and
the level of data affected.
-Section 25 "Summary" is updated to add new parameters and
improve text alignments in ASMRMFV and ADOCRMFV member
documentation.
-Three new examples showing use of SYSPLEX= and SYSTEM=
parameters are added to the sample documentation members
JCLRMFV, JCLCRMFV, and JCLDRMFV.
-At the ASMRMFV 32.225 level only FROMDATE=TODAY or
TODATE=TODAY settings and all related variants and
equivalents were creating an invalid date of 01JAN1900
for date selection because the current date was not being
loaded in SETDATE processing for these settings.
-REQUIREMENT: In order to implement these features the
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Thanks to Rodger Foreman, Trans Union, USA
Change 32.249 Support for BVIR Version 2 short 32X History Records that
VMACBVIR had only 31 Pool Segments, when all 32 pool segments are
Oct 30, 2014 normally always present. These records had BVIRLEN=8256,
but 8545 bytes (32*256+353) are needed for 32 pools.
The existing BVIRLEN GE 8512 test was reduced to 3256 as
record does contain the LIBxxxxx descriptor variables.
-The first three instances of these short records will
print a log message.
-A debugging PUT with _N_= GCNRCLUS= LENLEFT= was removed.
Thanks to Olivier Bigeon, SOC GEN, FRANCE.
Thanks to Pierre-Pascal Joulin, SOC GEN, FRANCE.
Thanks to Samsla Assanaly, SOC GEN, FRANCE.
Change 32.248 Under WPS, BLDSMPDB failed on z/OS because it generated
BLDSMPDB RECFM=S370VBS instead of RECFM=VBS because it incorrectly
Oct 28, 2014 changed OPSYS to 'os' with a %LET OPSYS=%LOWCASE(OPSYS).
The same code was generated under SAS, but there was no
error because SAS has supported both S370VBS and VBS
since SAS Version 8, although that was never documented.
The low case value was not visible in SYMBOLGEN messages,
because OPTIONS CAPSOUT is specified in MXG CONFIGxx.
Thanks to Scottie Mills, TI, USA.
Change 32.247 Support for EMC's Clarion Arrays data for Flare Firmware
VMACCLAR Version 26 thru 33. Most of the changes are new counters.
Oct 24, 2014 The "clarsan" object is really a special case of clarsnap
so clarsan was repurposed as clarpool.
Instrumentation was added to help build keep lists for
the various object's new counters.
Thanks to James Quigley, CONED, USA.
Change 32.246 TYPE72GO's PERFINDX can be a missing value when it should
VMAC7072 be large, for Service Classes with Percentage Goal and
Oct 24, 2014 a small number of transactions with a high goal objective
that was NOT met (so PERFINDX must be greater than one).
A Service Class with 19 transactions had 18 complete in
the first response bucket (.5) but one longer transaction
was not counted in the thirteenth response bucket (4).
So, while 94% of the transactions met their goal, the 97%
objective goal objective was NOT MET (.97*19=18.43 trans)
and due to an MXG logic error, PERFINDX was not set.
Now, when TRANS GT 0, PERFINDX is set to RTSMAP(13),
which for this case was 4.0. Note that PERFINDX will
always be a missing value when TRANS=0, or for R723CRGF=
'S' (SYSTEM) or 'D' (DISCRETIONARY) goals.
Thanks to Tom Kelman, Xerox, USA.
Change 32.245 Reserved Change Number.
Change 32.244 The MOBILE program MOBWRK73 (to read existing TYPE70s)
MOBWRK73 incorrectly required //TYPE70 DD statement. Eliminated,
Oct 21, 2014 but //TYPE70 DD UNIT=SYSDA,SPACE=(CYL,(50)) circumvents.
Thanks to Scottie Long, Navy Federal Credit Union, USA.
Change 32.243 If you use INITIT=Mx where X was the day of the month on
VMXG2DTE which you wanted to INIT the output, the first day's data
Oct 21, 2014 would have been missing. For example, if you specified
INITIT=M2 so that all the observations based on ZDATE
would be in each month's dataset, the data for the first
of each month would be missing because of an incorrect
calculation: when Wx is being used, 1 is added to the
date since the days of the week start with 0, but using
Mx, that +1 caused the data to be missing.
Thanks to Tom MacCabe, Dominion Resource Services, USA.
Change 32.242 z/VM Interval ENDTIME is set from first 0.1 (CPU) record,
VMACVMXA selecting CPUADDR='0000'x. But the first 0.1 record is
Oct 20, 2014 not always CPUADDR zero! CPUADDR=0001/0002/0003/0000x
Oct 28, 2014 data records had the MRHDRTOD in the fourth record SEVEN
MICROSECONDS later than the time in the first three. This
caused those first three observations to be output with
the (incorrect) prior ENDTIME value, which then caused
spurious observations with many missing values in dataset
VMXAINTV. Because the z/VM MONWRITE data file is weird,
consisting of 4K block containing variable records that
span blocks, and because four 0.1 records fill a block,
finding that first record requires comparing the stored
FOUNDINTBLOCK block number (_N_) with the _N_ of this new
0.1 and only updating ENDTIME if this block is more than
100 blocks later (256 CPUs would need 32 blocks).
-Lost Interval Data in VMXAINTV dataset will ALWAYS occur
for the first interval (START MONITOR message on the log)
because the data values are accumulated but there is no
prior record for the DIF() function; so if you have many
START MONITOR messages, each one is a lost interval.
MONWRITE really needs to run for 23.99 hours, STOP and
then START (and look at the REXX code in Change 29.101
that will synchronize your MONWRITE data to the hour.)
and thus lose only that one midnight interval.
Thanks to Kim Morrell, Royal Canadian Mounted Police, CANADA
Change 32.241 Back-Level EXITCICS V1 caused ERROR: DB2 INPUT STATEMENT
VMACDB2H EXCEEDED error (LENLEFT=4,QWHSTYP=8) and QWHUCPU/QWHUCNT
Oct 20, 2014 fields contain text: QWHUCPU='000000'X!!'BCDIC', and the
incorrect decompression in V1 also caused INVALID DISTRIB
HEADER messages (but DB2 APAR PM32425 was installed).
All errors were eliminated using the current EXITCICS V3.
However, protection is added for the EXCEEDED error.
On z/OS, EXITCICS decompresses the record before the SAS
INPUT statement, so a hex dump of the input record will
be the uncompressed record, but on ASCII, where MXGDECOM
must be used, after the record has been INPUT, a hex dump
will be of the compressed records. See comments in both
VMAC110 and VMACDB2 to get an uncompressed hex dump.
Thanks to Paul Maradin, HP, USA.
====== Changes thru 32.240 were in MXG 32.10 dated Oct 16, 2014=========
Change 32.240 First 32.10. INPUT EXCEEDED z/OS 2.1 SMF 6 Printway with
VMAC6 URI but no Accounting fields was not expected, but now is
Oct 16, 2014 protected.
Thanks to Jennifer D. Ayers, West Virginia State Government, USA.
Change 32.239 WebSphere SMF 120 Dataset TYP1209E had observations with
VMAC120 a negative DELTA120TM that should not have been output.
Oct 15, 2014 They are first instances of a by group, so no deaccum is
possible, but the test "IF DELTA120TM GT ." was true for
a negative. "IF DELTA120TM GT 0" is the required test.
Thanks to Wayne Bell, UniGroup, USA.
Change 32.238 Support "ALL" Tandem Measure records in a single file.
IHDRTAND This new support reads the //TANDALL DD, which can be
TYPETAND the ALL record file using this JCL:
TYPETANX // EXEC MXGSAS
TYPSTAND //PDB DD DSN=YOUR.OUTPUT.TANDEM.PDB,DISP=. . . .
TYPSTANX //TANDALL DD DSN=YOUR.TANDEM.ALL.INPUT,DISP=SHR
VMACTAND //SYSIN DD *
VMACTANX %INCLUDE SOURCLIB(TYPSTAND);
VMXGINIT or can be the individual "TYPE" files, concatenated:
Oct 12, 2014 //TANDALL DD DSN=YOUR.TANDEM.CPU.FILE,DISP=SHR
Oct 16, 2014 // DD DSN=YOUR.TANDEM.DISC.FILE,DISP=SHR
// DD DSN=YOUR.TANDEM.PROC.FILE,DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(TYPSTAND);
The CPU, DISC and PROC types (LOADID) have been tested.
-The "TAND" Header Exit IHDRTAND invokes &MACTANH which
can be used to select which record types are output:
%LET MACTANH= %QUOTE( IF LOADID='CPU'; );
%INCLUDE SOURCLIB(TYPSTAND);
(If the original multiple-file-name program is still
needed, use TYPETANX or TYPSTANX.)
Thanks to Paul Bennett, Euroclear, BELGIUM
====== Changes thru 32.237 were in MXG 32.10 dated Oct 10, 2014=========
Change 32.237 New variables added to ASUMDBSS for DBAT analysis:
VMXGDBSS ID= qdstnads qdstnard qdstqcit
Oct 10, 2014 MIN=qdstnqmn
MAX=qdstnccw qdstnqmx qdstnqav qdstmard
SUM=qdstnqsc
Thanks to Wayne Bell, UniGroup, USA.
Change 32.236 -InfoPrint/Printway SMF 6 SUBSYS='TCPE' Extended Mode File
IMAC6ESS Transfer INDC=7 variables PAGECNT/NRLINES/OUTDEVCE are
VMAC6 zero/zero/blank as noted in the SMF Manual.
Oct 9, 2014 -Variable SMF6URI (VMAC6) was increased from $64 to $128.
Oct 16, 2014 -Variable ESSFSSDT (IMAC6ESS) increased from $67 to $128.
-New in z/OS 2.1, the JOB Accounting fields in SMF6ACCT
are now decoded and NRACCTFL, ACCOUNTn, and LENACCTn
variables are created in TYPE6 dataset. Both BUILD005 and
BUIL3005 are also updated to use those values to populate
the existing account variables in PDB.PRINT when no 30-1,
30-5, and no type 26 records were found.
SEE CHANGE 32.240, in MXG 32.10 re-dated Oct 16, 2014.
Thanks to Teuvo Virsu, TIETO, FINLAND.
Change 32.235 Variable QWOBJNAM is now kept in MQMACCTQ dataset.
VMAC116
Oct 7, 2014
Change 32.234 The _IDaaaa=512 detection did not work correctly; all of
VMACXXXX Changes 32.224, 32.221, 32.198, 32.180 and 32.149 that
Oct 7, 2014 attempted to detect the un-changed default are removed.
Processing a USER SMF with the default MACRO _IDaaaa will
create zero obs in those datasets, as was always the case
previously. This attempt to alert the user why they had
zero obs could cause ALL of the USER SMF datasets to have
zero observations, so it has been removed.
The primary culprit was my choice to include the TMNT
USER SMF record in the default BUILDPDB/UTILBLDP, even
when you had not asked for it. And the circumvention
if you get the _IDTMNT unchanged log message, is to
request the VMACTMNT from MXG 32.10 to circumvent,
or to install MXG 32.10.
Change 32.233 Netview INPUT STATEMENT EXCEEDED for SUBTYPE=3 because I
VMAC38 thought S38DSOSN, active spans, described the length of
Oct 7, 2014 S38DSOSP, but it does not; code was revised.
Thanks to Coen Wessels, IBM, Switzerland.
Thanks to Pierre Beda, IBM, Switzerland.
Change 32.232 Variables SMF92MSZ and SMF92USZ are MGBYTES formatted.
VMAC92
Oct 2, 2014
Change 32.231 Support for DB2 V11 IFCID 225 IRLM STORAGE INFORMATION in
VMACDB2 new section 6 adds these variables to DB2STATS dataset:
Sep 30, 2014 QW0225I_ABCSA /*CURRENT*USED 64-BIT*COMMON*/
QW0225I_ABCSH /*HWM*FOR 64-BIT COMMON*/
QW0225I_BBPVT /*CURRENT*USED 31-BIT*IRLM*PRIVATE*
QW0225I_BBPVH /*HWM FOR*31-BIT IRLM*PRIVATE*/
QW0225I_ABPVT /*CURRENT*USED 64-BIT*IRLM*PRIVATE*
QW0225I_ABPVH /*HWM FOR*64-BIT IRLM*PRIVATE*/
QW0225I_BBECSA /*CURRENT*USED*ECSA IRLM*POOLS*/
QW0225I_BBECSAH /*ECSA*HWM*IRLM*POOLS*/
QW0225I_BPMAX /*THRESHOLD*31-BIT*IRLM*NORMAL*/
QW0225I_APMAX /*THRESHOLD*64-BIT*IRLM*NORMAL*/
and QW0225DMH is now correctly INPUT for DB2 V11 when it
exists.
Thanks to Ralph C. Baechle, Deere & Company, USA.
Thanks to Kerry Sommers, Deere & Company, USA.
Change 32.230 Undocumented 81-byte SMF14STY=01 segment caused remaining
VMAC1415 segments to be skipped. SMF Manual only documents 80.
Sep 29, 2014 Extra byte now input into SMF14UNK while IBM queried, and
all SMF14STY segments are now protected using SMF30ESL to
skip future new bytes, documented or undocumented.
Thanks to Carl D. Ellis, Wells Fargo, USA.
Change 32.229 -Only these NDM _SNDMxxx are PROC SORTs with NODUP to PDB:
VMACNDM CS/CF/EI/FA/JX/DS/MF/PE/PK/QE/RE/RO/S2/SC/SD/SH/SY/TR/TX
Sep 29, 2014 and CT. All other _SNDMxxx had a DATA step that copied
Oct 5, 2014 to //PDB, but that doesn't propagate the Dataset Label,
Oct 7, 2014 nor remove duplicates. (I use a DATA step instead of SORT
Oct 9, 2014 in an _Sdddddd sort macro when I don't have any data, so
I can't validate the BY list for the NODUP removal. When
a customer provides data, I validate the BY list and use
the PROC SORT NODUP in place of the DATA step.) But, the
BY list CAN be built from MXG code, so this was done and
all NDM _Sdddddd sort macros now use PROC SORT.
-The table in comments in VMACNDM was updated to identify
the datasets that have been populated with observations.
-These datasets _SNDMxxx were updated, but they all still
have zero observations, so their new BY list has not been
data-validated for NODUP:
CS CX GF HW HW2 CS EI JX LS MF PE PX RE RO S2 SC SH
ST TP TR TX
(If you have obs in these datasets, you can use the
UTILNODU program to confirm my BY list is sufficient,
or send your SMF data to support for examination.)
-Variables added to the NDMCT dataset:
NDMZFBA1='ZFBA*DEVICE*RANGE*ONE'
NDMZFBA2='ZFBA*DEVICE*RANGE*TWO'
NDMZFBA1='SEND*ZLIB*VERSION'
NDMZFBA2='RECV*ZLIB*VERSION'
-Dataset NDMPT variables NDMSUBJOB/NDMSUBJID were always
blank because the MXG logic for the Extension segment
was not correct. But there are new PT fields that are
NOT documented in the DSECT, in particular, PTDSNAME and
several character and numeric fields now INPUT in new
PTUNCHx and PTUNNRy character and numeric variables until
updated documentation is available.
Thanks to Randy Hewitt, HP, CANADA.
Change 32.228 Only 240 characters of IMS Log Input Message, MSGTEXT,
VMACIMS were kept, but that text can be much longer and may be
Sep 27, 2014 needed to identify your IMS Mobile Workload transactions.
So INPUT MSGTEXT $VARYING32000 MSGLEN @; is now used, but
with LENGTH MSGTEXT $240 added to keep the same length.
So if YOU do need to access data in MSGTEXT, you would
tailor the EXIMS01/EXIMS01M dataset exit members to test
the text and could use existing SMSGTEXT variable ($40)
for your flag, perhaps with logic like this:
IF INDEX(MSGTEXT,'MOBILE') GT 0 THEN SMSGTEXT='MOB';
before the OUTPUT statement in those EXdddddd members.
Or, you could create your own variable in those exits:
LABEL MYTEXT='ALL*32000*BYTES OF*MSGTEXT';
MYTEXT=SUBSTR(MSGTEXT,1,32000);
and then use
%LET MACKEEP= MACRO _KIMS01 MYTEXT %
MACRO _KIMS01M MYTEXT % ;
to add variable MYTEXT to each of those datasets.
Variable MSGSZIN is the actual MSGLEN of MSGTEXT.
Change 32.227 The ENDTIME in the last obs in NMONINTV can had a value
VMACNMON 12 hours later than actual, when there were BBBP records
Sep 26, 2014 after the last ZZZZ, because MXG code incorrectly updated
ENDTIME when it should have updated variable BBBPEND049.
Thanks to Xiaobo Zhang, FIServ, USA.
Change 32.226 SPINCNT SPINUOW and TIMEDIF were not correctly created
UTILBLDP when BUILDPDB=YES was used; if they existed in your MXG
Sep 19, 2014 USERID.SOURCLIB, then they were correctly included, but
if they were only specified in your UTILBLDP text, the
default members in the SOURCLIB were used.
Thanks to Doug Medland, IBM Global Services, USA.
Change 32.225 -RMF III Date/Time selection enhancements, fixes,
ADOCRMFV and documentation upgrades.
ASMRMFV -New parameter WINDOW (alias WIN) allows selection of
JCLRMFV non-contiguous data by time range for multiple days
JCLCRMFV and is explained below.
JCLDRMFV -New parameter NOWINDOW (alias NOWIN) provides the
Sep 18, 2014 behavior of prior ASMRMFV versions in most cases and is
Sep 22, 2014 the default.
Nov 25, 2014 -New parameter DOW= allows RMF III data selection by day
of the week and is also explained below.
-The FROMTIME= value may now exceed TOTIME= value even for
a single day selection. This condition was previously
flagged as an error, but will now be handled as an
implicit WINDOW request.
-WINDOW/NOWINDOW processing and interaction with the
FROMDATE=, TODATE=, FROMTIME=, and TOTIME= parameters is
best explained with the following examples.
NOTE: ASMRMFV has always added 59.999999 seconds to all
TOTIMEs so that RMF Monitor III Sample Sets that begin in
any part of a final minute of a time range are selected.
For example, TOTIME=1559 becomes 15:59:59.999999 for data
selection purposes.
Case 1: FROMTIME= LE TOTIME= for a SINGLE day
and WINDOW or NOWINDOW (default) in effect
FROMDATE=01OCT2014 TODATE=01OCT2014
FROMTIME=0800 TOTIME=1559
| 01 OCT 2014 |
| Select |
+-------<======>-------+
0 0 1 0
0 8 5 0
: : : :
0 0 5 0
0 0 9 0
Case 2: FROMTIME= GT TOTIME= for a SINGLE day
and WINDOW or NOWINDOW (default) in effect
This is a NEW behavior previously an error.
FROMDATE=01OCT2014 TODATE=01OCT2014
FROMTIME=1600 TOTIME=0759
| 01 OCT 2014 |
|Select Select|
<======>--------<======>
0 0 1 2
0 7 6 3
: : : :
0 5 0 5
0 9 0 9
Case 3: FROMTIME= LE TOTIME= for MULTIPLE days and
NOWINDOW (default) in effect
FROMDATE=01OCT2014 TODATE=03OCT2014 NOWINDOW
FROMTIME=0800 TOTIME=1559
| 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 |
| Select | Select | Select |
+-----<===========|=================|===========>-----+
0 0 1 0 0 1 0 0 1 0
0 8 5 0 8 5 0 8 5 0
: : : : : : : : : :
0 0 5 0 0 5 0 0 5 0
0 0 9 0 0 9 0 0 9 0
Case 4: FROMTIME= LE TOTIME= for MULTIPLE days and
WINDOW in effect. This is a NEW behavior.
FROMDATE=01OCT2014 TODATE=03OCT2014 WINDOW
FROMTIME=0800 TOTIME=1559
| 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 |
| Select | Select | Select |
+-----<=====>-----|-----<=====>-----|-----<=====>-----|
0 0 1 0 0 1 0 0 1 0
0 8 5 0 8 5 0 8 5 0
: : : : : : : : : :
0 0 5 0 0 5 0 0 5 0
0 0 9 0 0 9 0 0 9 0
Case 5: FROMTIME= GT TOTIME= for MULTIPLE days and
NOWINDOW (default) in effect
FROMDATE=01OCT2014 TODATE=03OCT2014 NOWINDOW
FROMTIME=1600 TOTIME=0759
| 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 |
| Select| Select | Select |
+-----+----<======|=================|=====>-----+-----+
0 0 1 0 0 1 0 0 1 0
0 8 6 0 8 6 0 7 6 0
: : : : : : : : : :
0 0 0 0 0 0 0 5 0 0
0 0 0 0 0 0 0 9 0 0
Case 6: FROMTIME= GT TOTIME= for MULTIPLE days and
WINDOW in effect. This is a NEW behavior.
FROMDATE=01OCT2014 TODATE=03OCT2014 WINDOW
FROMTIME=1600 TOTIME=0759
| 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 |
|Select Select Select Select|
<=====>-----<=====|=====>-----<=====|=====>-----<=====>
0 0 1 0 0 1 0 0 1 2
0 7 6 0 7 6 0 7 6 3
: : : : : : : : : :
0 5 0 0 5 0 0 5 0 5
0 9 0 0 9 0 0 9 0 9
-See the documentation in ASMRMFV or ADOCRMFV members for
more details on WINDOW/NOWINDOW.
-Five more examples have been added to each of the
JCLRMFV, JCLCRMFV, and JCLDRMFV sample JCL members
showing use of the new WINDOW parameter.
-Filter messages RMFV006I can now appear as multiple pairs
showing begin and end time stamps with one set for each
day when WINDOW is in effect. Prior to this change only
one pair was possible per RMF III data set processed.
-However, if the number of days between FROMDATE= and
TODATE= exceeds 15 only one RMFV006I pair will be shown
to avoid CPU overhead and excessive log message volume.
Actual filtering will still occur as requested.
-Filter message RMFV006I will now show the number of days
as DAYS= between the FROMDATE= and TODATE= values and
also the setting of the WINDOW/NOWINDOW option.
-ASMRMFV now uses 64-bit Grande z/Architecture
instructions in all 64 bit binary TOD date and time
calculations for better performance. Prior versions used
an older method with two 32 bit registers and
carry/borrow logic that was cumbersome with longer
instruction paths.
-Filter message RMFV006* (* = I or E) is now
multi-severity. When the FROMDATE= value exceeds the
TODATE= value then message RMFV006E will be issued. A
U0998 abend will then occur as in prior versions.
-The FINDGREG subroutine that determines the day of the
week (dow) for TOD values will retain the results of the
prior dow calculation and as a performance improvement
not repeat it if the date has not changed between
consecutive calls.
-Relative date selection will now allow up to
FROMDATE=*-999 or TODATE=*-999 for date backup values.
Previously 99 was the limit. However, the need for this
larger limit should be extremely rare as 999 days is
about 2.7 years.
-New option SHOWSAMP (alias SS) will display the begin and
end timestamps for each RMF Monitor III Sample Set
selected. SHOWSAMP is intended for diagnostic use and
possible user testing with the new WINDOW or DOW=
parameters to verify date and time selection is as
desired.
NOTE: SHOWSAMP is not appropriate for routine production
use due to TOD conversion overhead for each Sample Set
and ASMRMFV log output volume.
-When SHOWSAMP is in effect a pair of new messages
RMFV039I are issued showing Sample Set begin and end
timestamps and the Sample Set number (1-1110).
-New option NOSHOWSAMP (alias NOSS) is the default and
provides the same ASMRMFV behavior as before with no
RMFV039I messages issued. Normally there should be no
need to code this option.
-Options display message RMFV037I will show the setting of
SHOWSAMP/NOSHOWSAMP.
-Documentation in ASMRMFV and ADOCRMFV members has been
updated to include details on WINDOW/NOWINDOW,
SHOWSAMP/NOSHOWSAMP parameters as well as for messages
RMFV006*, RMFV037I, and RMFV039I.
-A new DOW= parameter allows optional RMF III data
selection based on the day of the week. DOW= will be
mainly useful for ad hoc studies where only activity on a
certain set of days is of interest.
-DOW= is coded as DOW=value where value uses one of these
formats:
dow dow:dow WEEKDAYS WEEKENDS ALL
dow is a 3 character day of the week:
SUN MON TUE WED THU FRI SAT
: is a range operator indicating selection of a group of
consecutive days including the first and last dow in the
range and all days in between.
The range will automatically wrap as needed to the start
of a week on Sunday so that DOW=FRI:MON is perfectly
valid selecting FRI, SAT, SUN, and MON.
Coding DOW=WEEKDAYS (or a value alias) is equivalent to
coding DOW=MON:FRI . Value Alias(es) for WEEKDAYS are:
WD, WEEKD, WEEKDA, WEEKDAY
Coding DOW=WEEKENDS (or a value alias) is equivalent to
coding DOW=SAT:SUN . Value Alias(es) for WEEKENDS are:
WE, WEEKE, WEEKEN, WEEKEND
Coding DOW=ALL is equivalent to coding DOW=SUN:SAT and no
filtering occurs. DOW=ALL is the default and so should
not needed to be coded.
-NOTE: DOW= filtering slightly increases CPU overhead as
conversion of the 64 bit binary TOD microseconds value to
a day of the week occurs for both the RMF III Data Set
Header (DSH) and Sample Set Header (SSH) tables.
-However, dow determination is not repeated for
consecutive table TOD values for the same date.
-DOW filtering is applied AFTER all FROMDATE=, TODATE=,
FROMTIME=, TOTIME=, and WINDOW data/time filters are
applied.
-DOW= may be combined with one or more of the
these existing date/time selection parameters or may be
used exclusively by itself.
-DOW= usage examples:
Parameter Selects RMF III Sample Sets for
--------- -------------------------------
DOW=MON:FRI MON, TUE, WED, THU, FRI
DOW=WD MON, TUE, WED, THU, FRI
DOW=SAT:SUN SAT, SUN
DOW=WE SAT, SUN
DOW=ALL SUN, MON, TUE, WED, THU, FRI, SAT
DOW=SUN:SAT SUN, MON, TUE, WED, THU, FRI, SAT
DOW=FRI:MON FRI, SAT, SUN, MON (dow wraps)
DOW=WED WED only
DOW=MON DOW=WED DOW=FRI MON, WED, FRI only
DOW=MON:TUE DOW=THU:FRI MON, TUE, THU, FRI only
-Filter display message RMFV006I will show the setting of
the DOW= filter.
-Six more examples have been added to each of the
JCLRMFV, JCLCRMFV, and JCLDRMFV sample JCL members
showing use of the new DOW= parameter.
-Documentation in ASMRMFV and ADOCRMFV members has been
added to discuss the DOW= parameter in detail.
-Null (blank) values for keyword=value type ASMRMFV
parameters are now allowed. The parameter is ignored.
For example, FROMDATE= is accepted with no change in the
FROMDATE occurring. Previously zero length keyword
values were flagged as an error.
-This feature allows users to provide these keywords in
templates for a possible future addition of an actual
value. Also existing keywords can now be nullified by
just setting the value to blanks rather than removing
the entire keyword.
-Multi-severity messages RMFV051* through RMFV055* (* = I,
W, or E) have been updated for consistency and alignment
with message RMFV008I for the DSN value.
-A new subroutine WRITESEP will now handle the generation
of separator lines used to delineate sections of the
ASMRMFV log for visibility. Prior to this every message
id was checked in the WRITEPRT subroutine for separator
eligibility before the message was issued. Now WRITESEP
will be called only as needed for specific messages.
-A separator line will now be written prior to the final
RMFV999I message for better visibility of important
ASMRMFV final results.
-Entries in Section 2 "Terminology" in ASMRMFV
documentation have been alphabetized and a few new
entries added.
-All examples in the JCLRMFV, JCLCRMFV, and JCLDRMFV
sample JCL members that use date/time parameters now
include a small diagram that visually shows what time
frames are selected.
-The RMFV014I RMF III data set bypass message has been
reformatted for better clarity and will now indicate
whether the data set is excluded due to date/time or DOW=
filters.
-A new RMFV014W warning message is issued at the end of
processing if ALL RMF III data sets have been bypassed
due to date/time and/or DOW= filtering.
-An invalid value for the DEVTYPE= or any *ERR= parameter
could allow ASMRMFV processing to continue instead of
abending as intended because the parameter error counter
was not being updated for these keywords.
-When multiple RMFV004E messages were issued due to
parameter errors it was possible some of the descriptive
problem text could be garbled.
-Julian years before 2000 in FROMDATE= or TODATE= were
not flagged as errors when they should have been.
-Message RMFV008I Descriptor Code overlaid when issued
as a WTO by the WTO option.
-Messages RMFV017I and RMFV038I should not be issued as
WTOs when the WTO option is in effect.
-DOW table entries were not blanked if DOW=ALL coded.
-NOTE: When the WTO option is coded it should be the
FIRST parameter in the JCL PARM= field or in SYSIN (if
no JCL PARM= field). Otherwise any errors for other
parameters will not be shown in JESMSGLG and JESYSMSG
until the WTO option is encountered.
-Documentation in ASMRMFV and ADOCRMFV members has been
updated as appropriate for the above changes.
-REQUIREMENT: In order to implement these features the
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
-Nov 25: Discovered the TODAY selection did not work
correctly, made the correction, and redated ASMRMFV.
This error was ONLY in the original 32.225 dated 9/22.
Change 32.224 The _IDaaaa=512 protection added in Change 32.198/180/149
VMACXXXX costs 10 CPU secs per 20,000,000 records, caused by the
Sep 16, 2014 statement ELSE IF LENGTH(COMPRESS(_IDaaaa)) that tests
Sep 29, 2014 the value of the old-style macro _IDaaaa for 512 and also
supports the "512 OR ID=513" multi-IDs syntax. That
statement causes a NUMERIC to CHARACTER conversion, for
each record, EVEN for the EXPECTED case where _IDaaaa has
been defined (when the ELSE clause is NOT even executed).
Since the "512" test only benefits "newbies" who didn't
find the doc to define their _IDaaaa macro, it certainly
should NOT cost "oldbies" who knew what to do. That 512
default value is only defined internally in MXG VMACaaaa
members, so by changing the MXG default ID value for all
USER SMF records from 512 to a MISSING VALUE, i.e., using
MACRO _IDaaaa . % as the internal default definition, the
test now uses the MISSING(_IDaaaa) function to detect and
tell this new user why all the datasets have zero obs,
and how to correct. And since no conversion is involved,
old users see no increase: the MISSING function cost 0.08
CPU secs per 20,000,000 records.
SEE CHANGE 32.234.
Thanks to MP Welch, Bank of America, USA.
Change 32.223 Update for MainView for MQ Version 5.2.
VMACBBMQ Changes are COMPATIBLE, MANY new variables.
Sep 16, 2014 -New variables added to BBMQQMGR (RTIN='E1'x) dataset:
Dec 11, 2014 PARM1 PARM2 QMCERTLBL QMCHLAUTH QMCONNAUTH
Dec 18, 2014 QMCRTVALPOL QMDEFCLXQ QMGRPUR QMICBC QMICBR
Jan 2, 2014 QMICTLC QMICTLR QMIPUBSC QMIPUBSR QMISTUSC
QMISTUSR QMISUBC QMISUBR QMISUBRC QMISUBRR
QMMAXUMSG QMPSCLUS QMQSGCRTLBL QMRCBC QMRCBR
QMRCTLC QMRCTLR QMREVDNS QMRPUBSC QMRPUBSR
QMRSTUSC QMRSTUSR QMRSUBC QMRSUBR QMRSUBRC
QMRSUBRR QMSCBC QMSCBR QMSCTLC QMSCTLR
QMSPLCAP QMSPUBSC QMSPUBSR QMSSTUSC QMSSTUSR
QMSSUBC QMSSUBR QMSSUBRC QMSSUBRR QMSTRDATE
QMSTRTIME QMSUITEB
-New variables added to BBMQBUFF (RTIN='E2'x) dataset:
SBPLOC SBPPGCLS
-New variables added to BBMQPAGE (RTIN='E3'x) dataset:
SPSEXPNDT SPSPADC1 SPSBPID SPSPSIDX SPSRBAV8 SPSRBA2V8
-New variables added to BBMQLMGR (RTIN='E4'x) dataset:
LMDATASETNM1 LMDATASETNM2 LMFULLLOGS LMICMPB LMICMPBR
LMICMPF LMICMPFR LMICMPR LMICMPRR LMIDCMP LMIDCMPR
LMIDECF LMIDECFR LMIDECR LMIDECRR LMIDUCMP LMIDUCMPR
LMIUCMP LMIUCMPR LMLGSUSPND LMLOGCOPYNM1 LMLOGCOPYNM2
LMMRCRBA LMOFLOSTA LMQMSRBA LMRCMPB LMRCMPBR LMRCMPF
LMRCMPFR LMRCMPR LMRCMPRR LMRDCMP LMRDCMPR LMRDECF
LMRDECFR LMRDECR LMRDECRR LMRDUCMP LMRDUCMPR LMRUCMP
LMRUCMPR LMSCMPB LMSCMPBR LMSCMPF LMSCMPFR LMSCMPR
LMSCMPRR LMSDCMP LMSDCMPR LMSDECF LMSDECFR LMSDECR
LMSDECRR LMSDUCMP LMSDUCMPR LMSUCMP LMSUCMPR
LMTOTALLOGS
-New variables added to BBMQCHAN (RTIN='E5'x) dataset:
CHLRVER CHLCRTLBL
-New variables added to BBMQQUES (RTIN='E6'x) dataset:
QSBACKD QSBACKT QSCBD QSCBT QSCMITD QSCMITT
QSCTLD QSCTLT QSFBACKD QSFBACKT QSFCBD QSFCBT
QSFCMITD QSFCMITT QSFCTLD QSFCTLT QSFINQD QSFINQT
QSFPUT1D QSFPUT1T QSFSETD QSFSETT QSFSTATD QSFSTATT
QSFSUBD QSFSUBT QSIBOCPU QSIBOELA QSICCPU QSICELA
QSICMCPU QSICMELA QSIGCPU QSIGELA QSIICPU QSIIELA
QSIMAXOI QSIMAXOO QSIMAXOT QSINQD QSINQT QSIOCPU
QSIOELA QSIP1CPU QSIP1ELA QSIPCPU QSIPELA QSISBACK
QSISBCKR QSISBCPU QSISBELA QSISCB QSISCMIT QSISCMTR
QSISCPU QSISCTL QSISELA QSISINQ QSISSET QSISSTAT
QSISSUB QSITFGET QSIUBACK QSIUBCKR QSIUCB QSIUCMIT
QSIUCMTR QSIUCTL QSIUINQ QSIUSET QSIUSTAT QSIUSUB
QSPUT1D QSPUT1T QSRBOCPU QSRBOELA QSRCCPU QSRCELA
QSRCMCPU QSRCMELA QSRGCPU QSRGELA QSRICPU QSRIELA
QSROCPU QSROELA QSRP1CPU QSRP1ELA QSRPCPU QSRPELA
QSRSBACK QSRSBCPU QSRSBELA QSRSCB QSRSCMIT QSRSCPU
QSRSCTL QSRSELA QSRSINQ QSRSSET QSRSSTAT QSRSSUB
QSRSTCKG QSRSTCKP QSRTFGET QSRUBACK QSRUCB QSRUCMIT
QSRUCTL QSRUINQ QSRUSET QSRUSTAT QSRUSUB QSSBOCPU
QSSBOELA QSSCCPU QSSCELA QSSCMCPU QSSCMELA QSSETD
QSSETT QSSGCPU QSSGELA QSSICPU QSSIELA QSSMAXOI
QSSMAXOO QSSMAXOT QSSOCPU QSSOELA QSSP1CPU QSSP1ELA
QSSPCPU QSSPELA QSSSBACK QSSSBCKR QSSSBCPU QSSSBELA
QSSSCB QSSSCMIT QSSSCMTR QSSSCPU QSSSCTL QSSSELA
QSSSINQ QSSSSET QSSSSTAT QSSSSUB QSSTATD QSSTATT
QSSTFGET QSSUBACK QSSUBCKR QSSUBD QSSUBT QSSUCB
QSSUCMIT QSSUCMTR QSSUCTL QSSUINQ QSSUSET QSSUSTAT
QSSUSUB
-New variables added to BBMQCFAC (RTIN='E8'x) dataset:
CFBERBA2 CFBSRBA2 CFCONLOS CFDSBLK CFDSBUFS CFDSEXPN
CFDSGRP CFLOGS CFOFFLDU CFOFL1S CFOFL1T CFOFL2S CFOFL2T
CFOFL3S CFOFL3T CFOFLD CFPARM CFQSYN CFRECAUT
-New variables added to BBMQAPPL (RTIN='E9'x) dataset:
APSSTCKB
-Occasional compressed records were found in uncompressed
data files, so the previous STOP on compressed record is
replaced by a RETURN so the non-compressed records after
a compressed record will be processed.
-All records have VERSREL=6.1, but their VERSION IS 5.2.
-Dec 10 Revisions: Records E1x/E5x/E6x don't have all of
the fields in the DSECT, causing INPUT STATEMENT EXCEED;
logic was inserted to read only what's there, but record
E4x's eyecatcher is @89 while all other record's is found
@85, and E4x record has ENTL=1192 but data visibly shows
the repeated segment length is only 1136. Hardcoded
circumvention for these two inconsistencies.
Interspersed Compressed records in an uncompressed file
are still skipped, but new message prints the first 25
so you can see the pattern of these records.
-BMC found that PTF BPL2290 caused problems with history
record decompression; BPL 2430 fixes for MVMQ 5.1 and
BPL2429 fixes for MVMQ 5.2
-Jan 2, 2015: After Installing BMC Mainview PTF's BPL2427
and BPL2430, 753 (out of 1003) 'E6' records were missing
the last four bytes of the last segment, with 2596 vice
2600 bytes visible in that last segment. These short
records are now detected and reported but that last
segment will be lost until a subsequent PTF corrects.
Thanks to James S. Swinarski, Credit Suisse, USA.
Change 32.222 IMS56FA log record is not output if NMSGPROC is missing,
TYPEIMST but that MXG decision is now rescinded, and all IMS 56FA
Sep 15,2014 records are output, having found pairs of records for
some transactions, with the second record having a small
amount of CPU time (1st 1265 microsec, 2nd 238 microsec)
and elapsed/service time, but CALLMSGU=0 so NMSGPROC=.
All of these second records have TCPCFLGS='01'x which is
a "TERM THREAD SYNCPOINT" reason for the record, so I
presume the second record is the CPU time associated with
the SYNCPOINT and is output so that time is not lost.
Now, you must use NMSGPROC to count transactions, as the
second syncpoint records are not a new transaction.
Note: the test for NMSGPROC GT 0 is in the MACRO _EIMS56G
overridden in comments in TYPEIMST, so you will need to
delete that macro in the SYSIN in your TYPE56FA job.
Change 32.221 Erroneous "_IDSYNC not set" message for SYNCSORT User SMF
VMACSYNC record processing when MACRO _SYNCID nnn % was specified.
Sep 14, 2014 That new message only tested _IDSYNC, but the original
_ID macro for SYNCSORT was _SYNCID, which is still valid.
Some early USER SMF _IDaaaa macros syntax was _aaaaID
but the "standard" is now _IDaaaa so those with the old
_aaaaID were enhanced to support either _ID macro name,
but the new "_ID=512" protection didn't support both of
the SYNCSort macro names. Now supports either syntax.
SEE CHANGE 32.234.
Thanks to Betty Wong, Bank of America, USA.
Change 32.220 -Documentation revised for TRENDing. MONTHLY was never a
BLDSMPDB valid interval value and has been removed from comments.
VMXGALOC -You can now suppress the creation of the DB2 and CICS
Sep 10, 2014 directories by specifying DB2KEEP=0 and/or CICSKEEP=0.
Sep 25, 2014 -New parameters BASECICS and BASEDB2 will allow you to
route DB2 and/or CICS datasets to a different drive.
Change 32.219 TMON/CICS variables TAUSRWCT and TAUSRWTM were reversed.
VMACTMO2
Sep 9, 2014
Thanks to Michael Oujesky, DTCC, USA.
====== Changes thru 32.218 were in MXG 32.09 dated Sep 9, 2014=========
Change 32.218 -BVIRVERS=04, dataset BVIR301 values were wrong due to two
VMACBVIR fields not INPUT for that Hydra version.
Sep 9, 2014 -DO Loop variable _I_ is replaced by kept variables
Sep 25, 2014 CACHEPARTNR created in BVIR301
TDUCONTNR created in BVIR321
CSPNR created in BVIR322
to identify the segment number
-DVAVDTMB/WRMB/RDMB now multiplied by 1048576 vs 1058576.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.217 Support added for ODS TYPEs CSV CSVALL EXCEL and TAGSETS.
VMXGODSO Some thoughts on ODS: Initially, VMXGODSO was thought
Sep 7, 2014 to be a tool to make use of ODS features easy, but you
may do better learning the ODS command set. VMXGODSO
does work, but it does not touch all of the ODS issues
and features, and many ODS statements are not supported.
But it can be used for simple cases, like wrapping around
a PROC to send its output to a CSV or EXCEL file, or if
you want to send many reports to a single output, a PDF
for example.
So you could use VMXGODSO, externally, to run GRAFWRKX
and GRAFCEC and send both ODS plots to a single PDF:
%VMXGODSO(ODSTYPE=PDF,FILE=c:\mxg\daily.pdf);
%GRAFWRKX:
%GRAFCEC;
RUN;
%VMXGODSC;
RUN;
and not use the parameters for ODS built into those
GRAFXXXX macros.
Change 32.216 Cosmetic. Some unneeded MXGNOTES are suppressed, unless
VMXGOPTR %LET MXGEXIMSG=YES; enables them for diagnostics.
Sep 7, 2014
Change 32.215 Zero observations in TYPEZOSA dataset because the test
VMACZOSA for ZOSATYPE=32 should have been ZOSATYPE=50.
Sep 6, 2014 The test for invalid ZOSAXDLN is again bypassed.
Thanks to Jerome Vitner, EXPERIAN, ENGLAND.
Change 32.214 DB2 V10 variable QW0225DMH is now INPUT and QW0225AR is
VMACDB2 now INPUT for DB2 V11. See Change 32.231.
Sep 3, 2014
Thanks to Kerry Sommers, Deere & Company, USA.
Change 32.213 -WARNING: MULTIPLE LENGTHS FOR VARIABLE X1 in ANALDB2R
ANALDB2R is not new; the X1 that shouldn't have been there isn't.
Sep 1, 2014
Change 32.212 MXGTMNT ML-54 monitor expands: a new subtask that COPIES
ASMTAPEE System-level information each SMF interval, writing new
EXTMNAS1 subtypes of the existing TMNT SMF record, synchronized.
EXTMNAS2 The subtask does not "monitor" the system, but sleeps
EXTMNSYQ until awoken at each interval end, reads EXISTING data
IMACTMNT fields and writes them to SMF, and goes back to sleep.
VMACTMNT This FIRST use of the ML-54 "SYSTEM" subtask captures two
VMXGINIT sets of data:
Sep 9, 2014 - ASM Page Data Set SLOT usage, with total, and by ASID
- MSU used by each IMPORTANCE level, IWMWSYSQ data.
Two new subtypes create these three new datasets:
DDDDDD MXG MXG
DATASET DATASET DATASET
SUFFIX NAME LABEL SUBTYPE
TMNAS1 TYPEASMT MXG SYSTEM ASM PAGE DATA SET SLOTS TOT 10
High Virtual counts: Frames in Use, Shared AUX
for Non-VIO, for AUX, and for AUX for SCM,
Common Aux, Common AUX SCM, Common in USE.
Shared Non-VIO, Shared AUX, SHARED AUX SCM,
Frames in use, Shared Non-VIO/High Virt Shared
High Virt AUX SCM, Shared Non-VIO/High Virtual
Aux, HV AUX SDM
TMNAS2 TYPEASMA MXG SYSTEM ASM PAGE DATA SET SLOT ASID 10
Frames in Use, VIO/non-VIO slots, High
Virtual AUX Slots for each ASID.
TMNSYQ TYPESYSQ MXG SYSTEM WLM PERF/CAPACITY IWMWSYSQ 11
MSU consumed last 60, 180, 600 seconds
by each Importance Level and Unused MSU,
Free CSA & free ECSA, and SU_SEC value.
-ASM subtask is a per-system monitor and must be enabled
on ALL systems, creating records on all systems.
-SYSQ subtask is a sysplex-wide monitor, so it should only
be enabled on one SYSTEM in each SYSPLEX; duplicate data
would be created if enabled on multiple systems within a
SYSPLEX. However, the number of SYSQ SMF records is very
small, one per system per SMF interval, so you may want
to enable SYSQ to write records on each system, so that
you have the identical ASMTAPEE/MXGTMNT on each SYSTEM,
and remove the duplicate SYSQ using EXTYSYSQ exit member
when you read the SYSQ SMF records.
-The ASM and SYSQ subtasks are enabled by default in ML-54
ASMTAPEE, by adding them to OPTIONS2, but they can be
disabled by removing them from OPTIONS2, or thru PARMs
on the // EXEC PGM=MXGTMNT statement, or thru MODIFY
commands issued from the console.
Full documentation is in the comments in ASMTAPEE.
Change 32.211 Cosmetic. Variable PAGETYPE='SCM' is set when SCMPGTYP
VMAC75 is true, replacing a blank value in PAGETYPE.
Aug 28, 2014
Thanks to Douglas C. Walter, CitiCorp, USA.
Change 32.210 -Support for SMF 50 INCOMPATIBLE change in z/OS 2.1 that
EXTY501 inserted four bytes that corrupted all values after that
EXTY50R insertion in the TYPE50 dataset.
EXTY50W -Redesign of TYPE 50 support to create separate datasets
EXTY50I with only the relevant variables for that event, now that
EXTY50O I realize it is no longer a single purpose VTAM record!
EXTY503 These seven new datasets are created:
EXTY504 DDDDDD DATASET Description
IMAC50 TY501 TYPE501 01 CHANNEL TO CHANNEL
Table 52 Subtype 1
VMAC50 TY50R TYPE502R 02-02 READ MPCNAME
Table 53 Subtype 2
VMXGINIT TY50W TYPE502W 02-02 WRITE MPCNAME
Table 53 Subtype 2
AUG 28, 2014 TY50I TYPE504R 02-04 READ MPCNAME
Table 54 Subtype 2
TY50O TYPE504W 02-04 WRITE MPCNAME
Table 54 Subtype 2
TY503 TYPE503 03 TCP CONNECTION
Table 55 Subtype 3
TY504 TYPE504 04 SNA CONTROLLER
Table 51 Subtype 4
-Dataset TYPE50 will continue to be created for backwards
compatibility, but it is very messy with all possible
variables in every observation, so there are always lots
of variables with missing value; using these new datasets
will provide much simpler analysis.
Thanks to Jim Sherpey, Bank of America, USA.
Change 32.209 -Support for SMF 103 HTTP Apache Server 8.5.5.0 Subtype 13
EXTY103D and 14 create new datasets:
EXTY103D DDDDDD DATASET Description
IMAC103 TY130D TYPE130D HTTP PROCESS Thread Statistics
VMAC103 TY130E TYPE130E HTTP LOGGING REQUEST/RESPONSE
VMXGINIT The T103ELAP elapsed time units are not documented.
Aug 27, 2014 -APAR PI24782 reports subtype 14s are only written when
SMFLogDebug ON has been specified.
Thanks to Dave Moreau, Royal Bank of Canada, CANADA.
Change 32.208 New NDM-CDI CPU TIME variables added to NDMRT dataset:
VMACNDM NDMRTSID='SUBMITTER*JCTJOBID'
Aug 27, 2014 NDMRTSUB='SUBMITTER*JOB*NAME'
NDMRTCP0='RUN-TASK*CPU TIME*ON CP'
NDMRTCP1='RUN-TASK*CPU TIME*ON ZIIP'
NDMRTCP2='ZIIP*QUALIFIED*PART OF*NDMRTCP0'
Dataset NDMDT variables were removed that shouldn't have
been kept in that dataset, listed in comments in KEEP.
Thanks to Michael Oujesky, DTCC, USA.
Change 32.207 "WARNING: Value of QWHCXTYP WILL BE TRUNCATED" in ANAL116
FORMATS in PROC CHART is harmless and does NOT set a return code.
Aug 26, 2014 Format MG116TY for QWHCXTYP had one 18-character value,
but this PROC CHART decided it needed some of that space
for other things. But that format value was reduced to
16 characters so this error should not reoccur.
Change 32.206 PDBAUDIT code can set Return Code 4 due to this message:
PDBAUDIT "WARNING: Multiple lengths specified for the variable
Aug 26, 2014 MEMLABEL by input data set(s). This can cause
truncation of data."
but the message makes no sense; it is in a single data
step: DATA PDBAUDIT; LENGTH MEMLABEL $64; SET CONTENTS;
where CONTENTS was created from DICTIONARY.TABLES.
Removing that LENGTH statement from this step and adding
it in a subsequent new step to reset the MEMLABEL length
eliminates the warning and creates expected lengths.
Thanks to Robert B. Richards, OPM, USA.
Change 32.205 Preliminary update, revised by CHANGE 32.212.
VMAC50 SMF 50 VERSN50 04 new variables kept in TYPE50:
Aug 25, 2014 INBDNLPS='INBOUND*NLPS*INLP'
OUBDNLPS='OUTBOUND*NLPS*ONLP'
BYINNLPS='BYTES READ*FROM*INBOUND*NLPS*BFNLP'
SMF 50 VERSN50 02 new variables kept in TYPE50:
TY50SBCO='OSA-EXPRESS*SBAL*COUNT*OVERFLOW*READ Q'
TY50SBCT='OSA-EXPRESS*SBAL*COUNT*READ Q'
TY50EICO='OSA-EXPRESS*EARLY*INTER*OFLOW*COUNT READ Q'
TY50EICT='OSA-EXPRESS*EARLY*INTERRUPT*COUNT READ Q'
TY50E2CO='OSA-EXPRESS*EARLY*II INT OFLO*COUNT READ Q'
TY50E2CT='OSA-EXPRESS*EARLY*II INTERRUP*COUNT READ Q'
TY50PKCO='OSA-EXPRESS*PACKET*COUNT*OVERFLOW READ Q'
TY50PKCT='OSA-EXPRESS*PACKET*COUNT*READ Q'
TY50ACCO='OSA-EXPRESS*ACCEL*PKTCNT*OVERFLO*READ Q'
TY50ACCT='OSA-EXPRESS*ACCEL*PACKETCOUNT*READ Q'
TY50ACBO='OSA-EXPRESS*ACCEL*BYTE*OVERFLOW*READ Q'
TY50ACBT='OSA-EXPRESS*ACCEL*BYTE READ Q'
TY50NVCO='OSA-EXPRESS*INVALID*FRAME*OFLOW*READ Q'
TY50NVCT='OSA-EXPRESS*INVALID*FRAME*READ Q'
TY50RDQN='OSA-EXPRESS*READ*QUEUE*NAME'
-The record LENGTH is stored into LENTYP50 to identify
the old 262 byte or new 274 byte record.
Change 32.204 SMF 119 St 52 dataset TYP11952 variable JESDPERC field
VMAC119 length in the IP Programmers Guide and Reference was 8
Aug 24, 2014 which MXG used, but the offset of the next field was only
4 bytes, and SYS1.MACLIB(EZASMF77) had length 4, which
was confirmed by IBM Support, so these fields are now
correctly all input as length 4:
SMF119ML_HC_JESDPERC &PIB.4. /*PCT JES DEST TASKS BUSY*/
SMF119ML_HC_JESWUSED &PIB.4. /*JES WRITER TASKS BUSY*/
SMF119ML_HC_JESWPERC &PIB.4. /*PCT JES WRITER TASKS BUSY*/
SMF119ML_HC_MDIRPFREE &PIB.4./*PCT FS SPACE FREE SYSWIDE EXTRTY*/
SMF119ML_HC_MDIRPUSED &PIB.4./*PCT FS SPACE USED SYSWIDE*/
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Change 32.203 32.08 Only: two errors related to %ANALID / BUILDPDB:
ANALID ERROR: DATASET NOPRINT NOT FOUND
ONLYJOBS ERROR: THE REQUESTED TYPE OF VIEW (INPUT OR OUTPUT)
Aug 26, 2014 were corrected by this change in MXG 32.09, or they can
be circumvented with 32.08 by inserting in your //SYSIN:
%LET VMVMACID=;
-UTILBLDP with USERADD=ID that also had %ANALID statement
got ERROR: DATASET NOPRINT NOT FOUND because a second
execution of ANALID was not expected. The ONLYJOBS
invokes UTILBLDP, but it already had a %ANALID statement,
but Change 32.192 to UTILBLDP inserted a %ANALID
execution when USERADD=ID was specified, causing the
second execution. The %ANALID; statement is removed from
ONLYJOBS, and ANALID now bypasses the second or more
executions in the same data step/session by default to
avoid the error with an accidental second execution, by
setting a value of YES for the new macro variable
DONEANALID.
-It's unlikely you will need ANALID twice in the same
job-step, but if you do, you can bypass the MXG bypass
with %LET DONEANALID=; to set a blank value, before each
of your %ANALID executions.
-If you have a locally-tailored BUILDPDB SYSIN code that
invokes _RPDBID, and 32.08, its removal would avoid the
need for the circumvention to suppress the VIEW.
Thanks to Paul Maradin, HP, USA.
Thanks to MP Welch, Bank of America, USA.
Change 32.202 DB2 Trace SMF 102 IFCID 196 "MORE THAN 9 HOLDER/WAITER"
VMAC102 MXG WARNING log messages will only be printed for the
Aug 23, 2014 first three instances.
====== Changes thru 32.201 were in MXG 32.08 dated Aug 21, 2014=========
Change 32.201 -New parameter VARSINCL= lets you add non-ranked variables
ANALRANK to the report that is created. So (for example) if you
Aug 21, 2014 were ranking, JOBS based on CPUTM you could also see the
Sep 4, 2014 total EXCP and IOTM counts by specifying:
VARSINCL=EXCPTOTL IOTMTOTL
In addition, if there is only a single variable being
ranked, the report is in RANK order rather and alpha.
-New parameters:
VARSINCL= a list of variables to include in the report
that are not being ranked
PAGEBY=Y/N YES/NO if YES or Y then the report is broken
into pages using the GROUPBY variable.
Thanks to Tom MacCabe, Dominion Resource Services, USA.
====== Changes thru 32.200 were in MXG 32.08 dated Aug 19, 2014=========
Change 32.200 Example reports for (archaic) SMF 118/TCP and SMF 119 are
ANAL119 corrected; the average bytes were a rolling average and
ANAlTCP did not match the values in the detail records.
Aug 19, 2014
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Change 32.199 The WLM dialog changed how it puts data in its table,
REXXWLM with a missing trailing quote on new Application
Aug 19, 2014 Environments in the generated code for some AESP values.
The padding on new AEs on the parms was changed from null
to blanks; the Rexx code was revised.
Thanks to Michael Oujesky, DTCC, USA.
Change 32.198 MXG 32.06-32.07. Protection for _IDxxxx EQ 512 failed
Many VMACaaaa if your _IDxxxx had multiple SMF record types, e.g.:
Aug 19, 2014 MACRO _IDNDM 132 OR ID=133 %
Aug 30, 2014 Zero observations were created for that product AND the
message was printed that the _IDxxxx macro wasn't set.
The 512-detection code was revised to support the two-id
syntax by testing both the length and the value, with
IF LENGTH(_IDNDM) EQ 3 AND _IDNDM EQ 512 THEN DO;
and this worked for the two-id syntax. However, only
accidentally. The LENGTH(_IDNDM) was 12 which is what
prevented the false positive 512 message. And, even
with MACRO _IDNDM 123 %, the LENGTH(_IDNDM) is still 12!
To circumvent this defect, the logic was revised again:
IF LENGTH(COMPRESS(_IDNDM)) EQ 3 AND _IDNDM EQ 512 ...
which uncovered yet another defect; the length of the
compressed two-id text is ONE, but the length of the
compressed one-id text is THREE, so the LENGTH of the
COMPRESSED macro text is used to only detect 512 with
three characters. Any other text in _IDxxxx will not
have length 3 so those records will be processed.
These XXXX product's VMACs were updated:
ACF2 BE91 BE97 BETA BVIR CTCP EDGS EJES ENDV FTP
HSM HURN IDMS M204 MIM NDM NETM NTCP PROS RSDA
RSDF SHDW STC SYNC TMNT TPMX X37 ZCOS
(There are MANY other user SMF records that have NOT yet
had the protection code added; deferred until an actual
need/request is received.)
-Notes: "Numeric values have been converted to character
string" will be printed, underscoring the "132" value in
the _IDxxxx macro; they are unavoidable but are compile
time conversion with no cost.
SEE CHANGE 32.234.
Thanks to Richard Wendland, U.S. Bank, USA.
Change 32.197 ANALZIPC (Analysis of CPU times for Ziip Engines) failed
ANALZIPC with ERROR: PDB.TYPE70PR NOT FOUND when _SMFZIPC was used
Aug 18, 2014 to read SMF. _SMFZIPC still used _STY70PR, which was
replaced by _STY70 (Change 23.321, SPLIT 70 processing).
Clearly, ANALZIPC users have NOT read SMF data but have
instead used the PDB.SMFINTRV and PDB.TYPE70PR datasets
from their already-created PDB data library!
Thanks to Ian Porter, Nissan-NEDC CO, ENGLAND.
Change 32.196 Preliminary summarization of PDB.DB2STATS from its fixed
ASUMDB2S one-minute interval to a larger interval of your choice,
Aug 18, 2014 defaults to 15 minute in this iteration, but this member
may be changed into a %macro to externalize options.
Thanks to Glenn Bowman, Wakefern, USA.
Change 32.195 New program to extract the workloads from your TRNDRMFI
GRAFWRKT dataset and linear regresses by SHIFT WORKLOAD SYSTEM,
Aug 17, 2014 then summarizes by SHIFT and WORKLOAD and uses SGPLOT
to display which workloads are growing over time.
Change 32.194 Support for NDM-CDI 5.2 HW2 subtype creates new dataset.
EXNDMHW2 DDDDDD DATASET DESCRIPTION
IMACNDM NDMHW2 NDMHW2 hw2 highwater mark record
VMACNDM This record is not a standard NDM-CDI record as it has
VMXGINIT 'CDHW' where the record length and record type normally
Aug 17, 2014 are located.
Thanks to Rich Wendland, U.S. Bank, USA.
Change 32.193 -These ASIxxxxx variables are now divided by ASISMPCT:
VMACRMFV ASILMEMO ASMLPGSZ ASILVNMO ASIHVCOM ASILVSHR
Aug 15, 2014 ASILVABY ASIHVCBY ASILVSBY ASIHVVBY ASILVMEM
ASI1MBFF ASI1MBPF
-Cosmetic. Debugging PUTLOG statement in line 5565
PUTLOG _N_= SSHRMFVN= SSHSMPNR= GEIRSTRF= GEIRPOOL=;
is now removed.
Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA.
Change 32.192 BUILDPDB/BUILDPD3/BUILD001 now use a VIEW for WORK.ID,
ANALID which eliminates completely the (potentially large) disk
BUILD606 space previously required to produce the SMF AUDIT REPORT
BUIL3606 (created by %ANALID, added to PDB in MXG Version 30.02.).
VMXGINIT -You can suppress the %ANALID invocation and the creation
UTILBLDP of the PDB.SMFRECNT dataset with %LET MXGSMFAUDIT=NO in
Aug 15, 2014 your SYSIN. (Previously, MACRO _RPDBID % bypassed the
report, but that is no longer used; if it exists in
your SYSIN it will just be ignored.)
(Only SAS supports Data Step Views.)
-UTILBLDP constraint that ID had to be first with USERADD=
(Change 32.154) is removed.
-Views are not executed when OPTIONS OBS=0 is in effect,
which is sometimes used in QA syntax tests, but since no
data will be read with OBS=0, &VWVMACID is nulled when
OBS=0 value is detected.
Change 32.191 Adding a View to BUILDPDB processing for the ID dataset
ANALDUPE exposed a SAS error (since 9.1) that corrupts the value
ANALDUPE of the internal _INFILE_ variable when a View is used.
ASCISMFC The error was detected when the MXG decompression logic
VMAC102 (MXGDECOM/DB2DECOM, for CICS/DB2) incorrectly expanded
VMAC110 the _INFILE_ internal variable. SAS confirmed the error,
VMAC112 recommending that the _INFILE_= argument instead of the
VMACDB2 _INFILE_ internal variable be used to circumvent, which
VMACSMF was verified in MXG QA tests. However, then the WPS QA
Aug 16, 2014 test failed because WPS doesn't support the _INFILE_=
argument, but their _INFILE_ variable is valid with or
without a View, so this change splits the logic to use
the _INFILE_=SMFINFILE argument for SAS but for WPS uses
the SMFINFILE=_INFILE_ statement, so SMFINFILE can then
be used in MXGDECOM/DB2DECOM macros in all of the listed
members that invoke the internal SAS code algorithms.
-MXGDECOM/DB2DECOM are always used on ASCII, and are used
on z/OS ONLY if the (recommended) EXITCICS/CICSIFUE exit
is not installed.
-Change 32.192 implemented the use of the VIEW for ID.
Change 32.190 BVIR variable VECDLEVL='VIRTUALIZATION*ENGINE*CODE LEVEL'
VMACBVIR is now converted to node notation, so the hex value
Aug 13, 2014 '0008 001F 0000 0059'X will now contain and print as
8.31.0.89 in character/decimal node notation.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 32.189 Cosmetic. Labels were corrected from CORRECTION to:
VMACDB2 FSPSCCPL - CONTROL*CONNECTION*PROTECTION*LEVEL
Aug 13, 2014 FSPSDCPL - DATA*CONNECTION*PROTECTION*LEVEL
Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
Change 32.188 DB2STATS variable QISEKLRU is not accumulated but was not
VMACDB2 detected as such in Change 30.113 because my test data
Aug 11, 2014 values were all zero. It is no longer deaccumulated.
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 32.187 -Missing value message for IOTMNOCA when SMF30AIC=. (which
ANALDSET occurs in MULTIDD='Y' obs), in VMAC30, is now avoided.
VMAC30 -ANALDSET enhanced with OPENTM calculated for TYPE64 since
Aug 11, 2014 OPENTIME was added after this was originally written.
Variables are now ordered for default PROC PRINT, grouped
with common first, then 1415, 64, and steps variables.
New RECFOUND variable identifies which records were found
for each observation. JESNR kept in both output datasets.
Thanks to Douglas C. Walter, Citigroup, USA.
Change 32.186 The ANAL116 example reports did not report on MQMACCT;
ANAL116 the new report was contributed by Scott and its absence
Aug 8, 2014 was noted by David.
Thanks to Scott Barry, SBBWorks Inc., USA.
Thanks to David Carr, Blue Cross Blue Shield of Kansas, USA.
Change 32.185 MXG 32.07 only. 180 Syntax error when ASUMUOW is tested
IMACUOW IF (TRANNAME=:'CSM' OR TRANNAME=:' ' OR TRANNAME=:'CPM'
Aug 7, 2014 180
is due to IMACUOW line 226: /* CASE ONE LOGIC BEGIN */ ,
added by Change 32.178 for the new CASE FIVE example,
which was a comment within a comment and must be deleted.
But MY real error was that I failed to QA test the new
IMACUOW. The default IMACUOW doesn't create observations,
so I have a tailored copy in my QA.PRODTEST library, but
as only a new commented block was added (I thought!), I
didn't update the new member into QA.prodtest. Mea Culpa.
Worse, the QA report that compares QA.PRODTEST members
flagged IMACUOW as changed, but I also failed to take
heed of that notification. Mea Mea Culpa.
Thanks to Jack Basile, PCH, USA.
Change 32.184 Support for Omegamon for SMS Version 510 USER SMF RECORD
EXOMSMTD (INCOMPATIBLE, INPUT EXCEEDED because the offset to the
EXOMSMTG next JOB segment is 112 bytes, but only 96 bytes are
FORMATS documented in each segment, requiring MXG protection.)
IMACOMSM -Two variables added to OMSMSJOB dataset:
VMACOMSM OMFS2DAO='DEVICE*ACTIVE*ONLY*TIME'
VMXGINIT OMFS2IOQ='IOQ*TIME'
Aug 6, 2014 -BY List macros for OMSMSDEV and OMSMSJOB datasets to
remove duplicates.
-New datasets created from subtype 4 records:
DDDDDD DATASET DESCRIPTION
OMSMTG OMSMSTPG TAPE GROUP
OMSMTD OMSMSTPD TAPE DEVICE
-Invalid Subtype 4 records are created with offset greater
that the record length; the first three instances are
printed on the log for pursuit with the vendor.
-Several fields with -1 value are now properly decoded.
-Some TAPE datasets have lots of blank character variables
that should be populated.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 32.183 New %PDBAUDIT audits all DATASETS in all LIBNAMES created
BUILDPDB by today's "BUILDPDB" in the "AUDIT" report, and compares
BUILDPD3 today's "PDBs" with yesterday's "PDBs", reporting any
PDBAUDIT changes in observation length, number of variables, or
VMXGINIT any datasets with zero obs in one PDB and non-zero obs
Aug 4, 2014 in the other PDB, in the "COMPARE" report.
Aug 15, 2014 -%PDBAUDIT is automatically called in BUILDPDB/BUILDPD3.
-You can use %LET MXGPDBAUDIT=BYPASS; in your SYSIN to
bypass that default execution of %PDBAUDIT.
-%PDBAUDIT creates the PDB.PDBAUDIT dataset with today's
statistics and copies that dataset into SPIN.SPINPDBAUDIT
which will be used for tomorrow's compare, and then backs
ups the dataset into PDB.SPINPDBAUDIT.
-If your "Build PDB" creates additional datasets after the
%INCLUDE SOURCLIB(BUILDPDB), for example, when ASUMs are
%INCLUDEd, you would bypass the default execution by
adding %LET MXGPDBAUDIT=BYPASS; in your //SYSIN and then
by adding the statement %PDBAUDIT; at the end of your
"BUILD PDB" step.
-All of the LIBNAMEs that have been opened/referenced in
this SAS step when %PDBAUDIT is invoked will be reported
and written to today's PDB.PDBAUDIT dataset.
-You can suppress the report printing but still build
the PDB.PDBAUDIT and SPIN.PDBAUDIT datasets by using
%LET MXGPRINTAUDIT=NO;
-Macro variables &PDBMXG, &SPININ and &SPINOUT are used
to set the output and SPIN input/output, with the normal
defaults of PDB/SPIN/SPIN, but can be changed if needed.
-It is possible to run %PDBAUDIT in a separate step, but
then you must use a LIBNAME statement for each library
you want to be audited, so the LIBNAME is referenced.
Having just a //DDNAME DD does NOT reference the LIBNAME.
You must have "PDB" and "SPIN" LIBNAMEs with DISP=OLD for
the complete COMPARE and AUDIT reports, but those could
separate dsnames just for audit:
// EXEC MXGSAS
//PDBAUDIT DD DSN=YOUR.PDBAUDIT.PDB,DISP=OLD
//SPNAUDIT DD DSN=YOUR.PDBAUDIT.SPIN,DISP=OLD
//PDB DD DSN=YOUR.REAL.PDB,DISP=SHR
//SPIN DD DSN=YOUR.REAL.SPIN,DISP=SHR
//CICSTRAN DD DSN=YOUR.CICSTRAN.DISK.PDB,DISP=SHR
//IMSTRAN DD DSN=YOUR.IMSTRAN.DISK.PDB,DISP=SHR
//SYSIN DD *
LIBNAME PDBAUDIT 'YOUR.PDBAUDIT.PDB';
LIBNAME SPNAUDIT 'YOUR.PDBAUDIT.SPIN';
LIBNAME PDB 'YOUR.REAL.PDB';
LIBNAME SPIN 'YOUR.REAL.SPIN';
LIBNAME CICSTRAN 'YOUR.CICSTRAN.PDB';
LIBNAME IMSTRAN 'YOUR.IMSTRAN.PDB';
%LET PDBMXG=PDBAUDIT;
%LET SPININ=SPNAUDIT;
%LET SPINOUT=SPNAUDIT;
%PDBAUDIT;
RUN;
-The default MXGEXCLUDESEQ=YES prevents expensive reading
of LIBNAMES that are Sequential Format SAS Data Libraries
to save resources, since DICTIONARY.TABLES cause the full
dataset to be read (even then, SAS does not report the
number of observations!). The cost can be significant:
processing a day's PDB with a 6,000,000 obs SEQ DB2ACCT:
EXCLUDESEQ NO (reads) YES (doesn't read)
CPU 4.8 seconds 1.2 seconds
Elapsed 5.5 minutes 58 seconds
EXCP Count 255,000 3,313
If you still want to read sequential libraries, you can
use %LET MXGEXCLUDESEQ=NO;
-ITRM sites can produce the report simply by adding
%PDBAUDIT; at the bottom of the SAS SYSIN stream.
-These five variables that are not created by WPS
FILESIZE NPAGE NUM_CHARACTER NUM_NUMERIC PCOMPRESS
will be missing values in reports and PDBAUDIT datasets.
Change 32.182 MXG QA test step TESSIBM2 MULTIPLE LENGTHS FOR STARTIME
ASUM113 caused Return Code 4, but had no other impact. A length
Aug 4, 2014 statement was added when TYPE70PR does not exist.
Thanks to Jim S. Horne, Lowe's Companies, USA.
====== Changes thru 32.181 were in MXG 32.07 dated Aug 3, 2014=========
Change 32.181 -New MOBWRKX3 member for Mobile Workload Processing uses
MOBWRK01 the CICDS Dispatcher Interval CPUTCBTM with selection by
MOBWRKX3 APPLID in MOBWRK01 instead of using CICSTRAN.
MOBWRK06 -Documentation in MOBWRK06 and MOBILWRK was updated.
MOBILWRK
Aug 3, 2014
Thanks to Michael Marcus, UPS, USA.
Change 32.180 MXG 32.06 ONLY. Zero OBS in user-added SMF type datasets.
VMACTMNT plus The delete statement discussed below was removed from
Aug 2, 2014 the new code added by Change 32.149 in these members:
ACF2 BE91 BE97 BETA BVIR EDGS EJES ENDV FTP HSM
HURN IDMS M204 MIM NDM NETM NTCP PROS RSDA RSDF
SHDW STC SYNC TMNT TPMX X37 ZCOS
ERROR: 32.06: ZERO OBS IN ALL USER-ADDED BUILDPDB/UTILBLDP DATASETS:
If you use UTILBLDP(BUILDPDB=YES,USERADD=...) or EXPDBVAR/CDE/OUT
members in your USERID.SOURCLIB to add other SMF record types to
your BUILDPDB/BUILDPD3, AND YOU DO NOT PROCESS MXGTMNT/TYPETMNT
SMF records (i.e., you do NOT set MACRO _IDTMNT 238 %), then ALL
of the datasets built AFTER TYPETMNT will have zero observations.
This error was introduced in Change 32.149, which incorrectly had
added a DELETE statement that should not be there.
CIRCUMVENTIONs for this 32.06-Only ERROR: (INSTALL 32.07!!)
-Remove the DELETE; statement in line 265 of VMACTMNT, OR
-Add this statement in your //SYSIN at the top:
%LET MACKEEP= MACRO _IDTMNT 999 % ;
-Or: with USERADD= in UTILBLDP, add TMNT/999
Change 32.149 added protection for each User SMF record
to detect when the IF ID= _IDxxxx THEN DO code block had
the default _IDxxxx value of 512, which would cause those
datasets to have zero observations, printing an MXGNOTE
to alert you to the needed correction to create obs.
But these code block for IF _IDxxxx=512 (STUPIDLY) had a
DELETE statement, and because the TYPETMNT processing of
that user record is inside the "standard" BUILDPDB, if
you had not set MACRO _IDTMNT 238 % to tell MXG to read
that type in the TMNT code block, then any record type
that was not processed in the preceding IBM type blocks
was deleted, and never examined by the subsequent code
blocks you had added with USERADD= or EXPDBetc.
SEE CHANGE 32.234.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 32.179 Cosmetic, confusing. These variables now have VIRT in
VMAC71 their label, for VIRTUAL, instead of VERT, which could
Jul 31, 2014 make you think of VERTICAL Polarized Processors:
SMF71SRA='AVG*HI VIRT*SHARED*FRAMES BACKED*RSTORE'
SMF71SRM='MIN*HI VIRT*SHARED*FRAMES BACKED*RSTORE'
SMF71SRX='MAX*HI VIRT*SHARED*FRAMES BACKED*RSTORE'
Thanks to Graham Harris, Royal Bank of Scotland, UK.
Change 32.178 Support for AES CleverView USER SMF subtypes 30-40, which
EXCTCP30 are added to the existing CleverTCP User SMF record code:
EXCTCP31 DDDDDD MXG MXG
EXCTCP32 DATASET DATASET DATASET
EXCTCP33 SUFFIX NAME LABEL
EXCTCP34
EXCTCP35 CTCP30 CTCP30 CTCP CRITICAL RESOURCE
EXCTCP36 CTCP31 CTCP31 CTCP PORT MONITOR
EXCTCP37 CTCP32 CTCP32 CTCP LINK VIEW
EXCTCP38 CTCP33 CTCP33 CTCP PROCESS VIEW
EXCTCP39 CTCP34 CTCP34 CTCP ICMP STATISTICS
EXCTCP40 CTCP35 CTCP35 CTCP IP STATISTICS
FORMATS CTCP36 CTCP36 CTCP TCP STATISTICS
IMACCTCP CTCP37 CTCP37 CTCP UDP STATISTICS
VMACCTCP CTCP38 CTCP38 CTCP OSA CHANNEL
VMXGINIT CTCP39 CTCP39 CTCP OSA ETHERNET
Jul 31, 2014 CTCP40 CTCP40 CTCP OSA LPAR
Change 32.178A Added as a new example, Case 5, for UOW definitions.
IMACUOW When there are no CSMI transactions, there is no EXECAPPL
Jul 27, 2014 that IMACUOW expected, so it is located by using byte 3
of the PATH(x) variable: If it is T or R, and not DB2,
then that CICSTRAN instance is used for EXECAPPL, and for
TRANNAME.
Thanks to Tom MacCabe, Dominion Resource Services, USA.
Change 32.177 Cosmetic. A NULLFILE/DD DUMMY caused a message that
VMXGDSNL VMXGDSNL could not resolve the lower level; the message
Jul 27, 2014 now simply says a NULLFILE DUMMY was found.
Change 32.176 Member VMACTMD2 did not process nor detect compressed
VMACTMD2 records when executed on ASCII, or on z/OS without the
Jul 25, 2014 EXITMON6 z/OS-only INFILE exit. Now, the internal SAS
algorithm is invoked, but that is VERY CPU intensive and
should NOT be used on z/OS.
-Change 31.133 added the second iteration support for V5
but it did not note that the 'DB' Thread Detail dataset
and dddddd token names were changed from TMDBDB2/TMDDB2
to TMD2DB/TMD2DB.
Thanks to Ernest E. Amador, UC Davis, USA.
Thanks to Mark A. Turner, UC Davis, USA.
Change 32.175 Enhancement and documentation for the ANALID reports:
ANALID -A Data Step VIEW is used for the (potentially large) ID
FORMATS dataset when %ANALID with READSMF=YES specified, or when
TYPEID %INCLUDE SOURCLIB(TYPEID); is used, or when BUILD001 or
TYPEID or BUILDPDB or BUILDPD3 is executed, saving LOTS of disk
TYPSID space. (Only SAS supports Data Step Views.)
VMACID -The DB2 Subsystem is now ALWAYS captured for 100-102s.
VMACSMF Originally, the DB2 Subsystem field was read from the
VMXGINIT (compressed) Product Section, but all DB2 records have
Jul 29, 2014 Subsystem in the uncompressed header, which is now used.
BUILDPDB -The COMPRESS and ACCUMAC flags now print 'C' and 'A'.
BUILDPD3 -On z/OS, when SMFEXIT=CICS is used (for compressed DB2 or
BUILD001 CICS SMF records), records have been uncompressed by that
INFILE exit, before the INPUT, so the COMPRESS=Y flag
can't be set, but the DB2 IFCID value is INPUT from the
product section, so reports show type 102 IFCIDs.
-
-Instead, when the internal decompression code is used
(i.e., either on z/OS without SMFEXIT=CICS, or on ASCII),
the DB2 IFCID is not available, because IBM does not
populate the 102 subtype field in the SMF header, and the
decompress occurs after SMF header processing; while the
COMPRESS=Y flag is set, all 102s will be reported as type
"102.000: UNKNOWN IFCID COMPRESSED".
REVISED JUL 5, 2015: SEE CHANGE 33.159, MXGDECOMP=DB2
will now decompress in the SMF header processing.
-Note that if you use IMACFILE/MACFILE (or it is used FOR
you, like with READDB2) to select which SMF records are
to be processed, those skipped records will NOT be
counted in the ANALID reports.
-BMC APPTUNE 102 records printed as 134.772-134.780 but
this change revises to print 102.8004-102.800B.
Thanks to Wayne Montefiore, CSC, AUSTRALIA.
Thanks to MP Welch, Bank of America, USA.
Change 32.174 DB2 V11 added new QX variables, but MXG only added them
VMACDB2 to DB2ACCT. These variables are now added to DB2STATS:
Jul 25, 2014 QXALTMP QXCREMP QXCRTSV QXDEGAT QXDRPMP QXDRPSV QXHJINCS
QXHJINCT QXMAXESTIDG QXMAXPLANDG QXN1093A QXN1093B
QXPAROPT QXPFMAXUG QXPFMAXUM QXPFSENUM QXPFSENUMG
QXPFSLNUM QXRSMIAP QXSISTOR QXSIWF QXSTARRAY_EXPANSIONS
QXSTODGNGRP QXSTOREDGRP QXWFRIDS QXWFRIDT
Thanks to Steve R. Wood, DST Systems, USA.
Thanks to Ramu Nalluri, DST Systems, USA.
Change 32.173 Support for Websphere MQ for z/OS Crypto Audit User SMF
EXWECRAU record (default 180) creates new dataset:
IMACWECR DDDDDD DATASET DESCRIPTION
VMACWECR WECRAU WEBSCRAU WEBSPHERE MQ CRYPTO AUDIT
VMXGINIT This code has NEVER been tested with actual SMF records;
Jul 25, 2014 please send records if they exist at your site.
Change 32.172 Support for Websphere MQ Version 8.0 CHANNEL/CHANNEL INIT
EXTY115E new subtypes of the 115 (subtype 231) and 116 (subty 10).
EXTY116A create these new datasets:
FORMATS DDDDDD DATASET DESCRIPTION
IMAC115 TY115E MQCHIN MQM CHAN/CHANINIT STATISTICS
IMAC116 TY116A MQCHININ MQM CHAN/CHANNEL INIT ACCOUNTING
VMAC115 These new subtype have NOT been tested with data. Please
VMAC116 send SMF data if you have these new SMF subtypes.
VMXGINIT Jun 24, 2015: See Change 33.151, MXG 33.07, which updated
Jul 24, 2014 VMAC115 and VMAC116 and tested with data.
Change 32.171 Support for Websphere Liberty z/CONNECT SMF 120 subtype
EXT12011 11 creates new dataset TYP12011.
IMAC120 DDDDDD DATASET DESCRIPTION
VMAC120 T12011 TYP10211 WEBSPHERE 11 LIBERTY z/CONNECT
VMXGINIT
Jul 22, 2014
====== Changes thru 32.170 were in MXG 32.06 dated Jul 21, 2014=========
Change 32.170 Support for CA SYSVIEW 14.0 IMS Records updates (COMPAT).
VMACSVIE -New variables added to SV34TRAN dataset:
Jul 19, 2014 IMTR_TRN_FPFLAG IMTR_TRN_FPFLAG2 IMTR_TRN_ENQPCB
IMTR_TRN_CPUTIME IMTR_TRN_TPTDBIO IMTR_TRN_TPTDBPL
IMTR_TRN_SYNCFAIL IMTR_TRN_FLIMRTCD IMTR_TRN_FLIMBQCT
IMTR_TRN_FLIMIQTM IMTR_CLK_CNT_ENQ IMTR_CLK_MXG_END
IMTR_CLK_CNT_GU IMTR_CLK_UOW_START IMTR_CLK_UOW_END
IMTR_CLK_FLIMIQTM IMTR_CLK_FLOMPRTM IMTR_CLK_SYNCPRTM
IMTR_CLK_FLDQOTIM IMTR_CLK_SYNCDATE IMTR_CLK_SYNCTIME
IMTR_CLK_SAVE IMTR_CLK_IFP5901L IMTR_CLK_IFPMSGWAIT
However, no V14 records have yet been available, and
there may be other changes in the TIMER records that are
under investigation. This text will be revised.
Change 32.169 -DB2STATS variables QDSTNQMN,QDSTNQMX,QDSTNQAV,QDSTNCCW
VMACDB2 were wrong with DB2 V10. Added by DB2 V11, the input test
Jul 19, 2014 was for QDSTLEN GE 96 instead of GE 114, so they were
input when they should have been missing values.
-DB2STATS variables QDSTMARD and QDSTNARD were wrongly
deaccumulated, causing very large, or zero, values.
Thanks to Wayne Bell, UNIGROUP, USA.
Change 32.168 NDM CT truncated record caused INPUT STATEMENT EXCEEDED.
VMACNDM The invalid record has NDMRECLN=1014, which should then
Jul 18, 2014 have LENGTH=1028, but the record LENGTH is only 1020.
Jul 23, 2014 The NDMLENPA length of NDMPACCT field in bytes 1017-1018
contains 10, but there are only 2 bytes left in the SMF
record. Tests added to detect the truncated record and
to print a message on the log for each defective record,
and to only input as many bytes as exist.
-IBM APAR PM77776/PTF UK83894 for Direct Connect V 5.x
corrects the truncated record.
Thanks to Norbert Wagner, Deutsche-Boerse, GERMANY.
Change 32.167 ANALDUPE algorithm to remove duplicate records in z/OS
ANALDUPE file had typos in S02OF02. The DSN syntax should be
Jul 18, 2014 //FMTDAT DSN=&&KEEPFMT,DISP=(OLD,PASS)
and the correct syntax is OPTIONS FMTSEARCH=(FMTDAT);
Thanks to Richard Schwartz, IBM Global Services, USA.
Change 32.166 MXG 31.09-32.05. The default CECINTRV=HOUR in ASUM70PR
ASUM70PR was incorrectly/unintentionally changed to QTRHOUR back
SAGANAL in MXG 31.09, but the HOUR default is now (AGAIN!) set.
Jul 18, 2014 %VMXG70PR (PDB=PDB,INTERVAL=QTRHOUR,CECINTRV=HOUR);
Jul 23, 2014 The INTERVAL parameter controls the summarization of the
two per-SYSTEM datasets, ASUM70PR and ASUM70LP, and the
INTERVAL=QTRHOUR works for data at 5, 10, or 15 min for
each individual SYSTEM.
The CECINTRV parameter controls the summarization of the
two per-CEC datasets, ASUMCEC and ASUMCELP, and the HOUR
default is used because it is safer: only if ALL systems
in the CEC have 15 minute interval data can QTRHOUR be
used for CECINTRV, and so using HOUR protects sites with
multiple/different intervals, and my intention was to
always create these CEC-level datasets hourly.
And, most sites have copied ASUM70PR into their tailoring
library, to set their own values for INTERVAL/CECINTRV,
so this incorrect change in default was not observed.
-However, SAGANAL did require the CECINTRV=HOUR and that
was not previously noted in its comments, hence this
discovery. Now, instead of INCLUDEing ASUM70PR, the
_READ70 macro uses %VMXG70PR with CECINTRV=HOUR.
-Jul 23: ERROR PDB.TYPE70PR not found was corrected.
Thanks to Ian Porter, Nissan, ENGLAND.
Change 32.165 New parameter GROUPBY added to let you find the rankings
ANALRANK by some variable. So for example, you wanted to find the
Jul 17, 2014 top 20 JOBS by SYSTEM for CPUTM and EXCPTOTL, you would
code:
%ANALRANK(DATASET=PDB.JOBS,GROUPBY=SYSTEM,IDBY=JOB,
VARS=CPUTM EXCPTOTL,HOWMANY=20);
Along the way logic was cleaned up and simplified
Thanks to Tom MacCabe, Dominion Resource Services, USA.
Change 32.164 FREQ created variables with lower case names. Later code
VMXGSUM that went looking for the variable could fail if it
Jul 17, 2014 looked for an upper case name. FREQ is now upcased as
are all the other variable names.
Change 32.163 Unused Change Number.
Change 32.162 See Change 33.014. Required for z13.
Change 32.161 Support for NDM-CDI M2 record, which is output in NDMMC
VMACNDM dataset. These M2-only variables are added to NDMMC:
Jul 17, 2014 NDMCFFLB NDMCRTYP NDMCSRVR NDMCTSLB NDMCTTYP NDMMCDSN
NDMMCSEQ NDMNBLKS NDMNBYTS NDMNRECS
Thanks to Michael Oujesky, DTCC, USA.
Change 32.160 ML-53 of MXG Tape Mount/Allocation/SYSLOG Monitor adds a
ASMTAPEE check for an I/O configuration change during the device
Jul 17, 2014 scan loop, which should reduce the chances of logrec
entries, which occurred at one site when a new IODF was
activated during MXGTMNT's device scan. Other than the
2,000 logrec entries for recovered 0C4 ABENDS for the
load module MXGTMNT, and the loss of data for that one
interval, MXGTMNT did not fail, and the MXGTMNT job log
did report the event was detected:
TMNT060I I/O configuration change detected,
MXGTMNT suspended pending restart
TMNT061I I/O configuration restart complete,
MXGTMNT processing resumed
Thanks to Ed Brociek, FMR, USA.
Change 32.159 -A possible error in ANALCAPD caused it to ignore the PDB=
ANALCAPD parameter, so &PDBMXG was always used. Since &PDBMXG
Jul 17, 2014 defaults to PDB, an error was unlikely, but the exposure
is removed, and a changed PDB= argument will now be used.
-Added SGPLOT invocation if you are on SAS 9.3 or higher.
Otherwise, if you have SAS/GRAPH, it is used.
Otherwise, the ancient PROC PLOT is used, and comments
were added to document the meaning of the characters
printed when PROC PLOT is used.
Thanks to Andrew Woods, Interactive Data, ENGLAND.
Change 32.158 Updates for Mobile Work including CSV-generating program.
MOBMWRT -%MOBMWRT creates the CSV file for submission to IBM.
MOBWRK05 -Changes to MOBWRKnn members now consistently have unique
MOBWRK06 &MOBxxx LIBNAMEs, and both SMF and PDB processing has
MOBILWRK been revised and tested.
VMXGINIT -MOBWRK05 and MOBWRK06 process all five products data if
Jul 18, 2014 they exist, so they can be used for one or all products.
Change 32.157 New parameters WIDTH HEIGHT FOOTNOTE added to let you
GRAFCEC tailor the appearance of graphs. Most of these look
GRAFWRKX better as landscape so the defaults are WIDTH=10in and
Jul 13, 2014 HEIGHT=8in. The 'in' is required. The footnote
parameter will let you add a footnote to the graphs
produced that you could use to add the job name that
created the graph. For example - to add a left justified
footnote with a height of .5 and in red you would
specify:
FOOTNOTE=JUSTIFY=L COLOR=RED 'Job name'
Thanks to Tom MacCabe, Dominion Resource Services, USA.
Change 32.156 Variable IRESPTM in the CICS dataset is the SUM of the
ASUMCICX response time in all transactions in the BY group. It
TRNDCICX probably should have always been the average value but it
Jul 11, 2014 is left as the sum and a new variable RESPAVG is created
which is the average value.
Change 32.155 Support for Oracle ELS/VTCS 7.2 HSC changes to user SMF
EXSTCV31 records.
IMACSTC -New dataset STCVSM31 created from subtype 31
VMACSTC -New variables added to datasets created from Subtypes
VMXGINIT STCnnTPX added to 13,14,15,16,17,18,19,20,25,26,27,28
Jul 8, 2014 29,30
Jul 16, 2014 STCnnTYP added to 16,17,18,19
Subtype 16: STC16LOC STC16MVC
Subtype 17: STC17LOC
Subtype 18: STC18LOC STC18VPT STC18TND STC18ND
Subtype 19: STC19LOC STC19VPT STC189ND STC19ND
subtype 26: STC26VPT
-All but subtypes 27,and 31 have been data tested.
-These (archaic) variables are always missing values:
STC13FLG STC13HID STC13SEQ STC13VTI
STC14FLG STC14HID STC14SEQ STC14VTI
STC18FLG STC18HID STC18SEQ STC18VTI
STC19FLG STC19HID STC19SEQ STC19VTI
-One question is open: STC14DSN contains a TODSTAMP and
not a 44-character DSNAME.
Thanks to Richard Stuchell, VISA, USA.
Thanks to Bruce MacKay, Oracle, USA.
Thanks to Merle Sadler, Oracle, USA.
Change 32.154 -This part of the original change:
ANALID "If you want to produce the ANALID report using UTILBLDP,
UTILBLDP with BUILDPDB=NO specified, then the ID token must be the
Jul 8, 2014 FIRST token in the USERADD= parameter:"
Aug 15, 2014 is no longer true; Change 32.192 removed that restriction
and ID can be anywhere in the USERADD= list.
-While only the SELECTED SMF record's datasets will be
created, ALL SMF records in the INFILE will be reported
by ANALID, UNLESS you also used MACFILE/IMACFILE to
delete SMF records; those deleted records will NOT be
counted/reported by ANALID.
-If you want to see the code that was created by UTILBLDP,
it can be printed on the LOG by specifying either the new
ECHO=YES (or ECHO=Y) argument, or with MXGEXIMSG=YES.
-Cosmetic change in ANALID to print 0 for small percentage
values to eliminate "Note: At least one W.D format was
too small for the number to be printed...."
Thanks to MP Welch, Bank of America, USA.
Change 32.153 Support for Optional CICS User ADP fields in IMACICVH.
EXUTILEX The EXUTILEX member is listed here ONLY to note that it
IMACICVH is not the correct way to add USER CICS fields to MXG.
VMAC110 Instead, send your CICS Dictionary SMF records to support
UTILEXCL and MXG will be enhanced to support your optional data,
Jul 5, 2014 with a new IMACICxx member just for you!
Thanks to Patricia Hansen, ADP, USA.
Change 32.152 Datetimes in TYPECTLT - CONTROL/T are GMT and there is no
VMACCTLT way to know what was the GMT Offset when those data were
Jul 5, 2014 created.
Change 32.151 BY lists for TYPE74PA/TYPE74ST/TYPE74DU/TYPE74HO/TYPE74TD
VMAC74 and TYPE747C were insufficient to remove duplicates.
Jul 5, 2014 All of those _BTY74xx macros are extended for removal.
-Variable R742PLIN='LIST*NUMBER*WITHIN*STRUCTURE' is now
INPUT; it was added to _BTY74PA. However, there are
duplicate observations in TYPE74PA.
-Variable R744FNAM was added to _BTY74ST for NODUP sort.
-Variable R744FNAM was added to _BTY74DU for NODUP sort.
-Variable R744HPCP was added to _BTY74HO for NODUP sort.
There are duplicate observations created in TYPE74HO.
-Dataset TYPE74ID will always have many more duplicates
removed than output observations, by design.
-If you use TYPE74PA or TYPE74HO, or TYPE74TD, and want
to open a PMR with IBM Support to examine why there are
duplicates, please send your data to support@mxg.com to
verify and to document for your PMR submission.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.150 Revised support for Informatica's POWER EXCHANGE SMF
VMACPOEX records, updated after the original preliminary support
Jul 3, 2014 in Change 29.134. These issues will be reported and this
text updated when resolved:
CHANGES REQUIRED:
1. In POEXDB2, POEXROWS are accumulated, but POEXSTMT=1
POEXSQLC=0 POEXUPDT=0 POEXDELT=0 POEXINSR=0 in all
fifteen DB2 segments so it is unclear if they too are
accumulated. BUT: ANY ACCUMULATED FIELDS means that
data is lost; the first instance for EVERY JOB must be
deleted since it is impossible to know which is the
FIRST interval record. Interval records MUST contain
interval values.
2. POEXUNDO (28-byte field before POEXCPUG CPU Time in
General Section: Undocumented field contains IP
address for IPV4 addresses:
(161.236.233.152)
but IPV6 addresses are truncated at 15 bytes
(::ffff:165.37.5)
3. CRITICAL: Subtype 3 Interval records POEXENDT is
always unpopulated (missing value) so the actual
interval duration can never be known.
4. CRITICAL: Subtype 3 Interval records POEXSTRT is
always the START TIME OF THE JOB and is NOT the START
TIME OF THE INTERVAL. SO: the interval duration can
NOT be known except in the first interval.
5. POEXSECN - Count of sections is ALWAYS ONE in all
records, even though there ARE multiple sections in
many records.
OTHER ISSUES:
6. Issues with UNDOCUMENTED DSN1 & DSN2 in File Segments:
a. Length 46 rather than 44 in DSN2, both set to 64 to
be safe for open system path names.
b. Contains single quotes around DSN in SOME
POEXACME=NRDB2 records:
'EDWT.ISG.COMBINED.MO.PRTY.INF' )
c. Contains DSN2=BLANK, DSN1=CONNECTION
d. Contains DSN2=BLANK, DSN1=TS01295.SHR.S9S.D140626
e. Contains double quotes at start and interval in
some records, i.e., "ZA1P".za1racf1_RACF_RECORD
7. Variables ADDL CIPC NODE REAS RTRN SESS SSI are always
blank.
8. Bytes Send and Received Count in CLIENT segment is
ALWAYS 256 bytes.
9. POEXCLIE (Client):
A JOB is identified by SYSTEM POEXJOB POEXTPID, but
POEXSTRT is CONSTANT for each interval. In each
INTERVAL record, POEXCPUG (General) is Accumulated,
while POEXCPUC (Client) is the interval CPU Time.
But in each END record, POEXCPUG and POEXCPUC are
EQUAL and are the TOTAL for that JOB. And POEXCPUG
(General) is ACCUMULATED while the POEXCPUC (Client)
is the DELTA
UNLESS: In POEXCLIE jobs where there is a DB2 Section:
a. The POEXTPID is always zero, so it is NOT possible
to group interval/end records for each job.
b. The CPUG and CPUC are accumulated and interval as
for POEXCLIE jobs that have FILE sections, but the
CPUD from the DB2 section is ALSO ACCUMULATED in
the interval records, and is the TOTAL in END
record.
10. There are four CPU metrics in four segments: CPUG -
General, CPUD - DB2, CPUL - Listener and CPUC -
Client, but no documentation of what is or is not
included in those fields.
Observing values, it appears:
POEXLIST - LISTENER - POEXCPUG (General) equal to
POEXCPUL (Listener)
POEXCLIE - CLIENT - See Preceding Item 19.
11. In the FILE segment, field POEXAMTY is not documented.
The values of 01, 0Ax and 19x in POEXAMTY have
POEXACME, Access Method, with , DB2, SEQ, and NRDB2,
respectively.
12. POEXSTRC - Character datetime value does not contain
fractions of a second, while POEXSTRT
TODSTAMP does have full resolution.
13. POEXENDC - Character datetime value does not contain
fractions of a second, while POEXENDT
TODSTAMP does have full resolution.
14. Client Segment TODSTAMPS ENDX STRX are always missing
values, but start/end from General Section are valid
and kept.
15. No GMT OFFSET value in any record, but the character
start time in POEXSTRC is on local while POEXSTRT is
on GMT so the offset value GMTOFFPOEX is calculated
and used to convert GMT datetimes to local.
16. Records with lots of nulls (SMF record 43, LENGTH=4928
(RDW=4932), but data ends in byte 847, 4181 bytes of
nulls).
Thanks to Eileen F. Van Etten, Bank of America, USA.
Thanks to Christopher D. Carnes, Bank of America, USA.
Change 32.149 SMF record TYPE can be 0-127 for IBM records or 128-255
VMACXXXX for USER SMF records. Because the TYPE number of a USER
Jun 26, 2014 record is set by the site's product installer, you must
Sep 28, 2014 tell MXG the record number that was chosen for USER SMF
processing for SMF TYPES 128-255. MXG sets the default
TYPE number to a missing value, a period, in MXG 32.10.
Previously, a value of 512 was the MACRO _IDxxxx default.
The recommended way to specify a User SMF type is to put
the defining MACRO in the IMACKEEP member in your USERID
Tailoring Library/Directory:
MACRO _IDxxxx nnn %
where the xxxx is the VMACxxxx suffix for the product,
(documented in member IMACAAAA), and nnn is the site's
chosen record number. This way, any processing of xxxx
will use that definition for that product's SMF record.
If you are using %UTILBLDP to create your SYSIN program,
the RECOMMENDED tool to process multiple SMF records, and
especially to add other SMF records, either IBM or USER,
with or without executing BUILDPDB, you supply the SMF
Record TYPE number in the syntax:
%UTILBLDP(USERADD=xxxx/nnn yyyy/mmm . . . .);
Alternatively, you can supply the _IDxxxx value in the
input in the job that processes the USER SMF record:
//SYSIN DD *
%LET MACKEEP= MACRO _IDxxxx nnn % ;
%INCLUDE SOURCLIB(TYPSxxxx);
Change text revised.
SEE CHANGE 32.234.
Thanks to MP Welch, Bank of America, USA.
Change 32.148 Support BMC DB2 Data Sharing Header, QWHSTYP=32 segment,
READDB2 which is inserted between the QWHSTYP=1 & 2 segments in
VMACDB2H BMC records, but is after the other segments in IBM data.
Jun 20, 2014 MXG logic had assumed the segments were in order, the BMC
Jul 9, 2014 insertion of their 32 segment caused the QWAC fields to
to be blank/missing, as the insert prevented segment 2
being input. Logic is now independent of the order.
-Using %READDB2(IFCIDS=BMC); worked fine on ASCII but did
not work on z/OS, because the test "IF &IFC GT 3" is true
on ASCII when &IFC is BMC, but the collating sequence on
z/OS causes BMC to be LESS than 3, so BMC subtypes were
not read. The test now explicitly tests for 'BMC'.
-Observed: TITLE CREATED BY _T102BMC; created an error;
the title must be in quotes to prevent macro _T102BMC
from being resolved as code!
Thanks to Janet Smith, BMC, USA.
Thanks to Tony Curry, BMC, USA.
Change 32.147 -ODS doesn't support character variables with $HEX format:
DOC SAS development investigated this issue with their XML
Jun 26, 2014 parser and the problem is caused because the values have
to be converted to XML, and Unicode values in
user-defined formats are not supported by the ODS
Graphics procedures.
Furthermore, ODS does not use the FORMATTED value of a
variable that contains hex values:
%INCLUDE SOURCLIB(TEST73);
PROC SGPLOT DATA=TYPE73;;
SCATTER X=STARTIME Y=PCHANBY/GROUP=SMF73CPD;
FORMAT SMF73CPD $HEXCHAR.;
RUN;
So it is necessary to create a new variable with the
format and use it:
DATA PLOT/VIEW=PLOT;
SET PDB.TYPE73;
CHANTYPE=PUT(SMF73CPD,$MG073CD.);
PROC SGPLOT DATA=PLOT;
SCATTER X=STARTIME Y=PCHANBY/GROUP=CHANTYPE;
-JMP doesn't support variables with ATTRIB TRANSCODE=NO.
The TRANSCODE= attribute can be changed with a DATA step
DATA NEW; ATTRIB variable TRANSCODE=YES; SET OLD;
Or with a PROC DATASETS
proc datasets lib=work memtype=data;
modify type73;
attrib _all_ TRANSCODE=YES;
run;
fails with errors:
attrib _ALL_ TRANSCODE=YES;
-
22
76
ERROR 22-322: Syntax error, expecting one of the
following:
a name, -, :, FORMAT, INFORMAT, LABEL, LENGTH, _ALL_,
_CHARACTER_, _CHAR_, _NUMERIC_.
ERROR 76-322: Syntax error, statement will be ignored.
Thanks to MP Welch, Bank of America, USA.
Change 32.146 Cosmetic, line "@; PUTLOG _N_= COL= DCVSGLNG=...; INPUT"
VMACDCOL left from testing Change 32.103 is now deleted.
Jun 23, 2014
Thanks to Clayton Buck, UNIGROUP, USA.
Change 32.145 Cosmetic. MXGNOTEs that VMXGSUM is bypassing a step or a
VMXGSUM sort that is not needed, are suppressed, unless you have
Jun 23, 2014 set %LET MXGEXIMSG=YES to print those suppressed notes.
Change 32.144 MXG 32.03-32.05 INVALID STID=60 CICS/TS 2.3 Statistics
VMAC110 error was not protected by Change 32.077, which had only
Jun 23, 2013 protected CICS/TS 3.2-5.1. The IBM error being protected
is that DSGLLEN=128, the correct length of the header, is
not the 136 byte length of each TCB segment. Previously,
all 136 bytes were always INPUT without a length test.
But CICS/TS 5.2 increased the length to 160, so 32.077
reset DSGLLEN to 136, but with data only back to 3.2 for
validation, the test was (65 LE SMFPSRVR LE 67). Now
(63 LE SMFPSRVR LE 67) is used to protect both CICS/TS
2.3 and 3.1 by resetting DSGLLEN to 136.
Thanks to Craig North, FHG, ENGLAND.
Change 32.143 The CPUZIPTM for SYNCSORT was a missing value for COPY or
VMACSYNC SORTs that did not use Sort Works DDs. MXG code was
Jun 22, 2013 revised, after discovering that the DS H'0' field in the
DSECT after then SMFWKEXL DS H'0' field does NOT exist
when NRSORTWK=0.
Thanks to Richard Krueger, Sentry Insurance, USA.
Change 32.142 READDB2 failed if FIRSTOBS NE 1 or OBS NE "enough" for
READDB2 the internal DATA steps needed to build the code, if you
Jun 22, 2014 asked for individual IFCIDS. Now, the original values for
FIRSTOBS/OBS are stored, the text for the code and sorts
are generated, and then they are restored to control the
SMF records read. Note, however, that you will then need
to reset FIRSTOBS=1 and OBS=MAX after READDB2 to process
the output datasets. For example, to read a single SMF
record for a single IFCID:
OPTIONS FIRSTOBS=123456 OBS=123456;
%READDB2(IFCIDS=376);
RUN;
OPTIONS FIRSTOBS=1 OBS=MAX;
PROC PRINT . . .
Change 32.141 Support for IFCID=376, but the DB2 V11 DSECT shows that
VMAC102 the last field is QW0376PN, which ends in byte 165 of the
Jun 21, 2014 record which has LENGTH=662, so a PMR is to be opened
with IBM DB2 support to determine if those extra bytes
are real or trash. In addition, the QW0376TS value, a
timestamp, contains '19871FAF182106A5'x, which I do not
recognize as a valid datetimestamp.
Thanks to Paul Walters, Navy Federal Credit Union, USA.
Change 32.140 -RACF SMF 80 INPUT EXCEEDED error because STATE field for
VMAC80A DISTRICT OF COLUMBIA DC exceeded the $VARYING16 LENVAR,
Jun 21, 2014 and SAS only INPUTs 16 bytes even when LENVAR is 24.
Informat changed to $VARYING32.
-Variable TOKMCARRIER now decoded into TYPE80TK dataset.
Thanks to David W. Chambers, Norfolk Southern, USA.
Change 32.139 -MXG 32.05 only, ONLY if BUILD606/BUILD3606 logic (or user
VMAC113 program with ELSE _CDE113). MXG 32.05 had this commented
Jun 20, 2014 debug statement *PUTLOG // _N_= ID= SUBTYPE= //; after
the MACRO _CDE113 statement, which caused a 180 syntax
error when preceded by the ELSE statement.
BUT: had I used /* PUTLOG . . . */ syntax, there was
NO ERROR!
The commented debug statement is now removed.
-If the EXPDBCDE member was used to add SMF 113 to your
BUILDPDB or if you used UTILBLDP, there was no error.
-But this goes all the way back to Change 15.354, (1998)
which was supposed to ensure that all SMF processing
members had syntax of IF ID= . . . immediately following
their MACRO _CDExxxx statement, so they could be used in
BUILD606/BUILD3606. I now find these other members also
didn't comply with 15.345; they all had a semicolon ahead
of their IF statement, which is now removed:
VMAC110 VMAC111 VMACBVIR VMACCDC VMACCMHM VMACCTCD
VMACGUTS VMACID VMACIPAC VMACMVTP VMACSHDE VMACZCOS
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
====== Changes thru 32.138 were in MXG 32.05 re-dated Jun 18, 2014======
Change 32.138 First MXG 32.05. VMACRMFV had a syntax error due to last
VMACRMFV minute untested update I rushed in at the last minute.
Jun 18, 2014 Update was an attempt to match Delay Percents in MXG to
IBM RMF III reports, but research is still in progress.
Four lines with WHEN ( ) AND syntax were incorrect but
are now removed.
Thanks to Robert B. Richards, OPM, USA.
Thanks to Matthew Brooks, OPM, USA.
Change 32.137 -All JCLTESxx members now all test with TESSxxxx members,
JCLTES91 which invoke all of the PROC SORTs so that the existence
JCLTES92 of BY variables is validated in testing. Previously, the
JCLTEST9 TESTxxxx members were used, which did not test SORTs.
JCLTESS9 -Members JCLTESS9, JCLTEST9, and JCLTES92 are identical;
TESTOTHR the multiple names are kept because of prior references.
Jun 18, 2014 -TESTOTHR had a mislocated %END; statement that is fixed,
but any of your code that %INCLUDES SOURCLIB(TESTxxxx)
should be changed to use TESSxxxx instead per preceding,
but the TESTxxxx members will remain in MXG forever.
Thanks to Jim S. Horne, Lowe's Companies, USA.
====== Changes thru 32.136 were in MXG 32.05 dated Jun 16, 2014=========
Change 32.136 VMACSMF: CICS version variable SMFPSRVR is formatted
VMACSMF with existing MGVERCIC so the version (e.g. TS5.1) is
UTILEXCL printed instead of its internal value (e.g. 68).
Jun 16, 2014 Since SMFPSRVR is not formatted in the other members,
Jun 19, 2014 the VMACSMF format will apply to all datasets read from
infile SMF with a CICS Version value in SMFPSRVR.
-UTILEXCL: Options NOCENTER improves report formatting.
-IMACICEZ: Comments revised: this member always inputs
five fields so it is removed from REPORT THREE-A as only
its comment block needs to be removed.
-IMACICE1 and IMACICE2: Comments revised to direct you to
use REPORT THREE-A to EDIT to find your number of fields.
Change 32.135 Labels for NDM datasets from a single subtype are now
VMACNDM explanatory. Multi-subtype datasets are still labeled
Jun 14, 2014 with the list of subtypes, but comments were updated to
list all of the subtypes that are documented.
Thanks to MP Welch, Bank of America, USA.
Change 32.134 Datasets BVIR322/BVIR323/BVIR324 for some POOLs were NOT
VMACBVIR output. The test for ATLGVOLS=0 that terminated the scan
Jun 14, 2014 on the first instance was invalid as there are many pools
AFTER that test. Now, all 32 possible pools are scanned
and only those with ATLGVOLS GT 0 are output, so all of
the active POOLs are output.
Thanks to Doug Medland, IBM Global Services, USA.
Change 32.133 -VMXGSUM is enhanced to support "concatenation" of "PDBs".
VMXGSUM Existing VGETDDS logic is implemented in VMXGSUM. The new
Jun 14, 2014 syntax %VMXGSUM(INDATA=CICSTRAN,USEVGETDDS=CICTRN:); will
input all DDNAMES/LIBNAMES from CICTRN1 up to CICTRN99.
INDATA must be set to a SINGLE dataset without a LIBNAME
reference, but it may include a (KEEP=VARA VARB ...)
modifier. The DATA step is passed as a view to the SORT.
-To fully support concatenated PDBs on tape, OPEN=DEFER is
forced when USEVGETDDS is specified.
Change 32.132 CALLEDBY= parameter added for internal use by MXG.
VGETDDS NOTES telling you what was allocated are suppressed
Jun 14, 2014 unless MXGEXIMSG=YES.
Change 32.131 -%READDB2(IFCIDS=BMC) created the 11 BMC APPTUNE datasets
READDB2 but then failed because _S102BMC macro does not exist.
Jun 13, 2014 Using IFCIDS=ALL does circumvent this error, but now the
individual _Sdddddd macros for the 11 BMC datasets are
invoked when IFCIDS=BMC is specified.
-Redundant code block for BMC removed in READDB2.
Thanks to Tony Cury, BMC, USA.
Change 32.130 Support for doc APAR OA35811 (replaced, FIN) by OA54385,
VMACRMFV for RMF III GEIG3 corrects the length of GEIRSTRF in z/OS
Jun 8, 2014 2.1 to 8 bytes, but actual data records show GEIRSTRF was
also 8 bytes in 1.13. But the code changes caused by the
doc APAR is that GEIRPOOL, the Average Online Real
Storage, is no longer used in z/OS 2.1 and GEIRSTRF is
the replacement. So this MXG change stores GEIRSTRF back
into GEIRPOOL in z/OS 2.1 so your existing reports using
GEIRPOOL will be correct without change.
But there appears to be an undocumented change in 2.1, as
I THINK (TO BE VALIDATED) that the order of subsequent
GEILF4K and GEILP4K in 1.13 were reversed in 2.1. When
input as originally documented, these are the values:
GEILF4K GEILP4K
(Fixed) (Pageable)
1.13 60 316,680
2.1 108,180 0
which seems to be wrong for 2.1.
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Steven Yucha, Aetna, USA.
Thanks to Miguel Mercado, Aetna, USA.
Thanks to Micheline Bissell, Aetna, USA.
Change 32.129 Protection for zero length data that printed this message
VMAC80A SMF 80 SEGMENT 301 HAS UNDECODED TOKDANAM=
Jun 6, 2014
Thanks to David Kaplan, DTCC, USA.
Change 32.128 Variable QBGLNW='PAGE-IN*WRITE*AROUND' now INPUT and kept
VMACDB2 in dataset DB2GBPST. Field was added in DB2 V11.
Jun 6, 2014
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.127 New %VMXGDEL0 utility can delete all datasets with zero
VMXGDEL0 observations, with or without a report of members and
Jun 11, 2014 their count of obs, or only a report can be generated.
While zero-obs datasets take essentially no disk space,
some SAS procedures open all datasets in a data library,
creating unnecessarily long menu lists. But, use this
tool with care, since if you delete zero observation
datasets from a "daily PDB" library, you could easily
cause other jobs (that still reference old datasets that
are no longer populated) to fail when you delete members.
This was handy to use after %READDB2(IFCIDS=ALL) so only
the populated T102Snnn datasets remained
Thanks to MP Welch, Bank of America, USA.
Change 32.126 Support for new Subtype 1 of HIS SMF ID=113 creates new
VMAC113 DDDDDD DATASET DESCRIPTION
ASUM113 TY1131 TYPE1131 HIS HARDWARE MONITOR DETAIL
Jun 2, 2014 IBM will not enhance the original Subtype 2 (accumulated
values), and the Subtype 1 contains interval delta values
so the first observation(s) are not lost in TYPE1131. The
ASUM113 program creates both ASUM113 (ST=2) and ASUM1131
(ST=1), but ASUM1131 should be used if it is populated,
as it will have more observations than ASUM113.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 32.125 New MGIBMxx formats created to support MOBILE WORK.
FORMATS Preliminary MOBILWRK program to identify Mobile Work.
MOBILWRK See the MOBILWRK member in MXG 32.05 for documentation.
MOBWRK00
MOBWRK01
MOBWRK02
MOBWRK03
MOBWRK04
MOBWRK05
MOBWRK73
MOBWRKS3
MOBWRK83
MOBWRKC3
MOBWRKD3
MOBWRKI3
MOBWRKM3
MOBWRKW3
TESTMOBQ
TESTMOBP
JUN 16, 2014
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 32.124 The DOCVER member, which documents all variables in all
UTILVREF MXG datasets, is enhanced by the addition of the BYLIST
May 31, 2014 for all datasets that are sorted. Most "important" MXG
datasets are sorted when the TYPSxxxx member is used to
SORT from WORK to PDB, but some datasets still have only
a DATA step to COPY from WORK to PDB. Contact support if
you use a dataset that is not sorted and be prepared to
send data, since actual data records are required to find
the BY list that removes duplicated.
Thanks to MP Welch, Bank of America, USA.
Change 32.123 Support for RSD USER SMF ACCOUNTING record Version 2.1
EXRSDSDS creates four new datasets:
EXRSDSES dddddd dataset description
EXRSDSEP RSDSDS RSDSDSET RSD SMF ACCOUNTING DATASET
EXRSDSNL RSDSES RSDSAESR RSD SMF SLR ACCOUNTING
FORMATS RSDSEP RSDSAEPR RSD SMF EPR ACCOUNTING
IMACRSDS RSDSNL RSDSANLR RSD SMF NLR ACCOUNTING
VMACRSDA Support for RSD USER SMF AUDIT record Version 2.1 is a
VMACRSDS complete rewrite with replaced variable names in the
VMXGINIT RSDAUDIT dataset.
Jun 8, 2014 Aug 11: Action Codes 36 and 84 are now recognized and
Aug 11, 2014 processed. FORMATS were updated for action codes.
Dec 10, 2014 Dec 10: Test for UNKNOWN AUDIT ACTION is removed, so now
Dec 22, 2014 all action codes are output. New AUDACT records all have
the same physical structure, the full record has been
read, and AUDOBJI is populated so you can split/store it
if needed, as done now for some AUDOBJT values.
Dec 22: Lines over 72 shortened.
Thanks to Rosa Maria Martinez Alonso, Bustia, SPAIN.
Thanks to Raul Juan Rincon, Bustia, SPAIN.
Change 32.122 VMXGPARS did not correctly parse quoted strings if there
VMXGPARS was a blank embedded in the quoted string, which caused
May 29, 2014 UTILBLDP to generate invalid syntax errors.
Change 32.121 UTILBLDP new option SORTOUT=NEVER prevents output SORT of
UTILBLDP all datasets, intended for MXG internal use. SORTOUT=NO
May 29, 2014 suppressed SORTs of most data, but still sorted these:
7072 DB2 HSM NTCP ROSC TMDB TPX 103 28
because they contain accumulated values that require the
sort to deaccumulate. NEVER prevents even those sorts,
but leaves invalid values for those datasets, so use of
SORTOUT=NEVER prints a warning message when used.
Change 32.120 Support for optional CICS user SDA fields.
IMACICSD
UTILEXCL
VMAC110
May 27, 2014
Thanks to Trevor Holland, ANZ, AUSTRALIA.
Change 32.119 Support for IMS56FA records from IMS 13.1 (INCOMPATIBLE,
VMACIMS due to inserted fields).
May 27, 2014
Thanks to Rudolf Sauer, T-Systems, GERMANY.*
Change 32.118 ANALID= parameter added to READDB2 to create SMF Audit
READDB2 report when set to YES. Only the SMF records that are
May 25, 2014 required for the READDB2 request are reported.
Change 32.117 Incorrect ID Test for ID=140 corrected to ID=104.
VMAC104
May 23, 2014
Thanks to Robert A. Obee, IMS Health, USA.
Change 32.116 XAM CRITICAL ERROR with SEGLEN=84 was a false error; that
VMACXAM is a valid length for the SYTSYP segment in zVPS 5.4 so
May 21, 2014 the MXG "protection" for invalid FTP transfer added in
Change 32.057, which tested only for the known mangled
100 value now accepts 84 as valid, suppressing the error.
Thanks to Robert K. Hare, Comerica Bank, USA.
Change 32.115 VMXGSRCH failed if there were no datasets in the LIBNAME
VMXGSRCH pointed to by the LIBNAME= parameter.
May 17, 2014
Change 32.114 READDB2 with PDBOUT="non-PDB" still wrote to PDB.DB2ACCT
READDB2 and if there was no //PDB in JCL or no LIBNAME PDB, the
May 17, 2014 job abended. Additionally, if STATISTICS was specified
(instead of the RECOMMENDED STATS argument), errors in
PROC SORTs for STAT0/1/2/4/225 would also fail. Missed
because a LIBNAME PDB always existed in the QA tests.
Unrelated, with recommended STATS specified, datasets
DB2STAT0 1 2 4 DB2ST225 and T102S225 were left in WORK,
but they are now deleted.
Thanks to Frank Bereznay, IBM Global Services, USA.
Change 32.113 Support for APAR OA44319/OA44322 for SMF ID=42 ST 5 and 6
VMAC42 statistics to TYPE42SR, TYPE42VT, and TYPE42DS datasets.
May 17, 2014 TYPE42SR TYPE42VT TYPE42DS Description
S42SCA1U S42VDA1U S42DSA1U AVG*DEVICE*ACTIV ONLY*TIME
S42SCB1U S42VDB1U S42DSB1U AVG*DEVICE*BUSY*TIME
S42SCC1U S42VDC1U S42DSC1U AVG*I/O*CONNECT*TIME
S42SCD1U S42VDD1U S42DSD1U AVG*I/O*DISCONNECT*TIME
S42SCHRD S42VDHRD S42DSHRD ZHPF*READ*COUNT
S42SCHWR S42VDHWR S42DSHWR ZHPF*WRITE*COUNT
S42SCM1U S42VDM1U S42DSM1U AVG*COMMAND*RESPONSE*TIME
S42SCP1U S42VDP1U S42DSP1U AVG*I/O*PENDING*TIME
S42SCQ1U S42VDQ1U S42DSQ1U AVG*CONTROLUNIT*QUEUE TIME
S42SCR1U S42VDR1U S42DSR1U RESPONSE*TIME
S42SCT1U S42VDT1U S42DST1U AVG*TOTAL*READ*DISCONNECT
Change 32.112 Documentation. TYPE113 variable SM1132SP is labelled as
VMAC113 the processor speed in cycles per microsec, so it has a
May 15, 2014 value of 5504, while MXG-created variable EFFGHX is the
processor speed in GHZ, a value of 5.504. While SM1132SP
could be changed, it is pervasively used in many of the
calculated ratios, and changing its value now would not
only require those calculations to be changed, they would
then not match the equations in John Burg's many papers.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 32.111 Support/corrections/enhancements for IDMS Version 18.
VMACIDMJ -PMRHTYPE=4 PMHSEQN=2 record +4 needed for doubleword
VMACIDMS alignment; variable INSTTTI created and kept in the
TYPEIDMJ IDMSINS dataset.
May 12, 2014 -Variable DBKOWNER no longer kept in IDMSTAS dataset;
it exists only in IDMSDBK dataset.
-Variable TASTITI is incorrectly spelled, but so as to
prevent current programs from failing, the correctly
spelled variable TASTTTI is equated and kept in the
IDMSTAS dataset.
-Members TYPEIDMJ and VMACIDMJ, which reads the INFILE
//DCLOG rather than SMF format data, were revised so
that they now use the VMACIDMS member, eliminating need
for dual maintenance.
Thanks to Mark S. Miller, APL, USA.*
Change 32.110 Variables FSCIPHER FCCFIPS140 FCCIPHER4 are added to both
FORMATS TYP11903 and TYPE11970 datasets. Variable FCCFIPS140 and
VMAC119 existing SMF119ML_CN_TTLSFP TTTTLSFP variables are
May 12, 2014 decoded with $MG119FP format.
Thanks to Jerome Vitner, Experian, ENGLAND.
Change 32.109 Variable STATCTM1, when non-zero, was incorrect; the TU4.
IMACICDB INFORMAT was replaced by &PIB.8.6/4096 to properly input
May 11, 2014 the duration value.
Thanks to Raymond Dunn, CIGNA, USA.
Change 32.108 -RMF III Fixes, Enhancements, Documentation upgrades.
ADOCRMFV -Fix for possible S0C4 Abend when processing an ASI table
ASMRMFV in the first MINTIME interval after a Service Policy
Jun 12, 2014 activation.
-Possible incorrect data for Service Class, Report Class,
Workload, or Resource Group extensions in the ASI output
record for the MINTIME interval immediately after a
Service Policy activation.
-Investigation found that RMF III copies all ASI entries
from the prior MINTIME interval to the new MINTIME
interval after a Service Policy activation.
-If the number of Service Classes, Report Classes,
Workloads, or Resource Groups in the Service Policy has
changed after Service Policy activation, the indexes for
some of those copied ASI entries will not match the
corresponding sections in the active Service Policy.
This causes the Abend or incorrect extension data
conditions.
-ASMRMFV will now use the prior Service Policy to resolve
indexes in the copied ASI entries for this particular
MINTIME interval. Once all of the ASI copied entries are
processed, normal use of the active Service Policy will
resume for the remaining entries and for all other
MINTIME intervals.
-New message RMFV078I will indicate when the new ASI index
FIND logic is in use after a Service Policy activation
and for how many copied entries it was used.
-Four new FIND error handling parameters are added:
SCERR=, RCERR=, WLERR=, and RGERR=. These are
respectively for Service Class, Report Class, Workload,
and Resource Group indexes.
-An ASMRMFV FIND error occurs when the index value for one
of the above 4 data categories exceeds the number of
actual entries for that category in the active Service
Policy.
-Possible setting values for SCERR=, RCERR=, WLERR, and
RGERR= are IGNORE, WARN, and ABEND. Each may be
shortened to as few letters as desired down to a single
character I, W, or A respectively.
When a setting is IGNORE:
SCERR= RCERR= WLERR= RGERR=
------ ------ ------ ------
Message(s) None None None None
Return Code Unchanged Unchanged Unchanged Unchanged
When a setting is WARN (default):
SCERR= RCERR= WLERR= RGERR=
------ ------ ------ ------
Message(s) RMFV070W RMFV071W RMFV072W RMFV073W
Return Code 0004 0004 0004 0004
When a setting is ABEND (for diagnostic use):
SCERR= RCERR= WLERR= RGERR=
------ ------ ------ ------
Message(s) RMFV070E RMFV071E RMFV072E RMFV073E
Abend Code U0998 U0998 U0998 U0998
Reason Code 70 71 72 73
-An extra RMFV037I message displays the values assigned to
these FIND error settings at ASMRMFV startup as I, W, or
A.
-When an SCERR=, RCERR=, WLERR=, or RGERR= setting is WARN
and a FIND error occurs ASMRMFV updates the usual 32 byte
Description field for the Service Policy category in ASI,
ENC, RCD output records as follows:
Category Description Field Contents
-------------- ---------------------------
Service Class SC: I=nnnnnnn E=eeeee L=lll
Report Class RC: I=nnnnnnn E=eeeee L=lll
Workload WL: I=nnnnnnn E=eeeee L=lll
Resource Group RG: I=nnnnnnn E=eeeee L=lll
where:
nnnnnnn is the invalid index value up to 7 decimal digits
eeeee is the actual number of entries in the Service
Policy for this category up to 5 decimal digits
lll is the length of one entry in the Service Policy
for this category up to 3 decimal digits
These Descriptions eventually become part of the MXG PDB.
When a Service Class, Report Class, Workload, or Resource
Group name variable in an MXG PDB is blank the
Description field in this case helps to explain why.
-When a setting is WARN AND an index value is ZERO the
respective Description field is also updated.
In this case NO messages are issued. An index may
validly be zero.
As examples, in a given Service Policy not all Service
Classes belong to a Resource Group nor do they
necessarily have a Report Class. The index for the
Resource Group and/or Report Class in these cases would
be validly zero.
-When a SCERR=, RCERR=, WLERR=, or RGERR= setting is
IGNORE and the respective index value is either invalid
or zero, the corresponding Description field is instead
left as blanks.
This was the behavior of prior ASMRMFV versions for zero
index values. Users who prefer to have the Description
field remain blank in the PDB in these cases should use
the IGNORE setting for all 4 error parameters (or set
MAXFINDS=0 as noted below).
-NOTE: The respective 8 byte Service Class, Report Class,
Workload, or Resource Group name variable itself in the
PDB remains as blanks for invalid or zero indexes
regardless of IGNORE or WARN settings.
-A new parameter MAXFINDS= (aliases MAXFIND=, MAXFI=,
MAXF=) specifies the number of FIND warning messages
RMFV070W, RMFV071W, RMFV072W, and RMFV073W to be shown
for each RMF III data set processed when the WARN setting
is in effect. The default is MAXFINDS=10.
-With the MAXFINDS= default up to 10 each of RMFV070W,
RMFV071W, RMFV072W, and RMFV073W warning messages could
be shown for each RMF III data set processed. The
counter is reset for each new RMF III data set.
-An extra RMFV037I message displays the numeric value
assigned to MAXFINDS= at ASMRMFV startup.
-MAXFINDS=0 EXCLUDES all FIND warning messages and has the
same effect as coding SCERR=IGNORE, RCERR=IGNORE,
WLERR=IGNORE, and RGERR=IGNORE.
-MAXFINDS=MAX allows virtually unlimited FIND warning
messages to be shown per RMF III data set.
-Documentation Section 2 "Terminology" has been expanded.
-Documentation Section 6 "Report Control Parameters" is
updated for the new MAXFINDS= parameter.
-Documentation Section 8 "Error Handling Parameters" is
updated for the new SCERR=, RCERR=, WLERR=, and RGERR=
parameters.
-Documentation Section 9 "JCL and SYSIN Parameter Usage"
has been updated.
-Documentation Section 12 is now called "Messages" and now
includes ALL possible messages that can be produced by
ASMRMFV. For each message there is a discussion of
purpose, whether the message is Multi-Line and/or
Multi-Severity, possible action(s) to be taken, and an
explanation of all variable fields in the message.
-Documentation Section 17 "Abend Reason Codes" is updated.
-Documentation Section 21 is now called "Extended
ASI/ENC/RCD/UWD Record Support" and has been updated.
-Documentation Section 24 "Sysplex Master Gatherer" is
updated for the new MASTER RMF III option in z/OS 2.1.
-Message RMFV032E was missing trailing +++ characters.
-Message RMFV034I is now message RMFV017I and message
RMFV034I is no longer in use.
-Error message RMFV043E is now a severe error message
RMFV043S.
-Message RMFV052* (* = I,W,A) had an invalid value for
CISIZE.
-Message RMFV106W was missing trailing * character.
-Two new diagnostic only messages for the ASI table
RMFV076I and RMFV077I have been added but do not
normally appear without a special procedure.
-Data ORIGIN message RMFV009I now includes the RMF Version
Number, z/OS Version and Release Number, and the MINTIME
sample time stamp to better identify the source of data
being processed for each RMF III data set.
-In the event multiple RMF versions have created data in
an RMF III data set message RMFV009I will be repeated as
needed for each new version detected.
-REQUIREMENT: In order to implement these features the
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Thanks to Warren Cravey, Fidelity Institutional, USA.
Change 32.107 Support for optional CICS segment ESIUSER.
IMACICVG
UTILEXCL
May 8, 2014
Thanks to Alfred Holz, Express-Scripts, USA.
Change 32.106 Optional CMRDETL CICS segment is now 384 bytes long with
IMACICMX unpopulated/useless 128 bytes added to each CICS 110-1,
UTILEXCL so UTILEXCL is updated to detect the new length and tell
May 4, 2014 you to tailor the new IMACICMX member. The previous 256
length is still detected and IMACICMR identified for you
to tailor. IF BOTH IMACICMR and IMACICMX are identified
in your data, please send the UTILEXCL output using the
first example to support@mxg.com and we will return a
tailored member that will support both lengths.
Change 32.106A Protection for divide by zero in VXPRCPRP when HFCOUNT is
VMACVMXA zero, VMDUSER is removed from VXPRCMFC BY list as it is
May 4, 2014 not always populated.
Change 32.105 Variable NDMNODET is now labeled DIRECTION*OF*DATA and is
VMACNDM formatted with $MGNDMNT.
May 1, 2014
Change 32.104 Change 32.089 subtracted CPUASRTM from CPUTCBTM and added
VMAC30 CPUASRTM to CPUSRBTM. Now, the CPUUNITS and SRBUNITS are
May 8, 2014 also corrected by moving ASRUNITS from CPU to SRB, since
CPUASRTM is SRB, and not TCB, time.
Thanks to Julian Smailes, Experian, ENGLAND.
Change 32.103 DCOLMIGS dataset variable UMLRECL was always zero because
VMACDCOL the DSECT in Access Method Services has the wrong offset
May 1, 2014 for the 10 reserved bytes, which misled me to incorrectly
input UMLRECL.
Thanks to Steve Gormley, UNUM, ENGLAND.
Change 32.102 Support for OS/390 RMF data. MXG changes after MXG 30.30
VMAC7072 caused zero observations in PDB.TYPE70 for records from
Apr 28, 2014 OS/390. Now, IF VERSNRMF LE 607 THEN OS390='Y' is set and
used to force output when TYPE70EN has no observations.
Thanks to Jeff Fracas, WIPRO, USA.
====== Changes thru 32.101 were in MXG 32.04 dated Apr 27, 2014=========
Change 32.101 -Duplicate DB2 SMF ID=102 Trace records are removed in the
ADOC102 revised _S102nnn dataset sort macros that now correctly
VMAC102 PROC SORT NODUP DATA=_Wdddddd OUT=_Ldddddd, WORK to PDB.
Apr 26, 2014 (Previously, a DATA _Ldddddd; SET _Wdddddd; was used in
the "sort" macro to copy from WORK to PDB data library).
-The BY list _V102SRT _B102nnn, where V102SRT is this list
of common variables used for all T102Snnn sorts
SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN QWHCCV
QWHCCN QWHSSTCK QWHSWSEQ
and _B102nnn is the IFCID-specific variables that are
also needed for NODUP to work.
-But: NODUP can ONLY be verified with actual data records:
These IFCIDs had 50% removal with _ALL_ BY List:
004 005 006 007 022 027 053 058 059 060 061 062
063 064 064 066 072 703 074 075 080 081 082 086
090 091 095 096 107 108 109 112 142 173 177 191
199 208 225 247 250 254 261 262 263 267 268 340
342 343 350 359 361 362 366 370 371 377
This 1 IFCID needed it's _B102199 BY List Populated:
199
These 24 IFCIDs did not remove 50% with _ALL_:
023 024 025 055 083 087 106 140 141 143 144 145
169 172 192 196 219 220 258 313 319 337 402 SSS
All other IFCIDs had zero observations so it is not
known if the default _V102SRT BY list is sufficient, but
you can easily verify, by reading the same SMF input
twice with %READB2(IFCID=nnn,PDBOUT=PDB) and observing
if the PROC SORT duplicate observation count is equal to
to the output observations, i.e., 50% of the input.
-Obscure: Previously, variable T102RECN was accidentally
output with the physical record number in the SMF input
file, when it should have been a missing value, as it was
intended for internal debugging or support diagnostics.
But that non-missing value prevents NODUP removal of any
duplicate records, since duplicates would have different
values in T102RECN. It can't be dropped without possibly
causing someone's "perfectly good programs" to fail, so
it is now set to a missing value, as intended.
If you needed to know which SMF record created an obs,
you can populate T102RECN by inserting this statement
%LET MXGDEBUG=T102RECN;
in your //SYSIN input.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 32.100 VGETOBS First 32.04: A RUN; statement is REQUIRED, and,
VGETOBS only under SAS V9.2, the newly-used-in-32.04 FEXIST()
Apr 27, 2014 function didn't recognize a valid //PDB DISP=NEW DDNAME
that had already been written to; the BUILDPDB failed
with CRITICAL ERROR PDB DDNAME NOT FOUND when VMXGCICI
made the first VGETOBS call to create PDB.CICINTRV.
-The RUN; statement is required to be inserted inside the
%MACRO VGETOBS definition to force resolution of input
%macro variables before their reference, discovered when
%ANALZPCR failed to create any output.
-The FEXIST(DDNAME) function replaced a PROC SQL in 32.04
(to determine if the DDNAME existed when DDNAME.DATASET
didn't exist) because it looked simpler and faster with
a large VTABLE, but the measured difference was small and
large VTABLEs are very uncommon, so the initial test for
DDNAME existence is changed to %SYSFUNC(LIBREF(&DDNAME)),
with code reordered to expect existence, the normal case.
The fall thru to find if the DDNAME exists but has not
been opened/assigned, reverts to use the PROC SQL on
DICTIONARY.EXTFILES to avoid 9.2 FEXIST problem.
-Why is VGETOBS so pervasively used in MXG? First, to
verify that the DDNAME.DATASET of interest exists. Often
in MXG internal code, like VMXGWORL, so MXG can find and
copy/delete the WORK/PDB copy transparently, and often in
ANALxxxx report members that require your names as input,
VGETOBS is used to verify your request does exist. By
finding the non-existence before the reference, the user
can be alerted with explanatory MXGNOTES. Otherwise, not
only does the job eventually fail, but the failure error
messages can be quite confusing (BY VARIABLE NOT FOUND)
as they are not the actual cause of the failure. Second,
MXG can significantly reduce tape mounts and EXCPs using
VGETOBS to detect that tape or sequential format library
is in use; since SEQ doesn't have a directory of datasets
on tape, MXG can bypass the read of each tape volser to
find that this DATASET exists. And third, many of the
ANALxxxx/ASUMxxxx members use VGETOBS to bypass execution
of DATA and PROC steps where there is no data to report
or summarize.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Robert B. Richards, OPM, USA.
====== Changes thru 32.099 were in MXG 32.04 dated Apr 23, 2014=========
Change 32.099 NEARTIME updates a daily PDB library with every SMF dump,
NEARTIME to provide nearly current time reports throughout a day.
Apr 21, 2014 You can build a complete PDB each time, or only process a
few records that you may want to have available during
each day. It can create all of the PDB datasets in the
LIBNAME of NEARTIME, and after all datasets are created
and sorted, it can either APPEND or COPY those datasets
from the NEARTIME data library to the PDB data library.
It keeps track of its last run in SPIN.LASTRUN and for
the first run on a new day, it PROC COPYs to initialize,
or PROC APPENDs all datasets found in NEARTIME to PDB.
If you choose to run a full BUILDPDB, the standard
invocations of RMFINTRV CICINTRV ASUM70PR and ASUM113
are suppressed until after the copy process is complete,
so that the summarizations include all the data to that
point in time and they are redriven with every execution.
The JOBS/STEPS/PRINT datasets are built by the normal
BUILDPDB process, where SPINCNT is incremented for each
execution, so you may need to increase the SPINCNT value
in your IMACSPIN tailoring to account for the increased
number of executions per day. You could even add an MXG
step to your SMFDUMP routine to cause the daily PDB to
be as current as the last SMF dump. This has been tested
by two sites, so please use with caution and report any
problems, and any enhancement suggestions.
Change 32.098 Variable PCTMVSBY is added to PDB.ASUM70LP dataset.
VMXG70PR
Apr 21, 2014
Change 32.097 The pairing-macros sorts for the TRANSIT report wrote to
ANALDBTR T102Snnn dataset names that overlaid the originals and
Apr 21, 2014 caused SORTED BY errors. Now, P102Snnn names are used.
Change 32.096 Change 32.091 corrected VGETOBS performance, but that new
ANALID design removed a PROC SQL that had (accidentally) caused
VGETOBS instantiation of a macro variables, exposing an error in
Apr 20, 2014 ANALID where a RUN statement should have been used. The
missing RUN; statement is added in ANALID, but a second
RUN; statement is added at the top of VGETOBS in case any
other members needed that accidental protection.
Change 32.095 UNINITIALIZED variable DB2PARTY message eliminated.
TRNDDB2A
Apr 20, 2014
Change 32.094 Support for SMF ID=92 Subtypes 16 and 17 create:
EXTY9216 dddddd dataset description
EXTY9217 TY9216 TYPE9216 SOCKET/CHARSPEC FILE CLOSE
IMAC92 TY9217 TYPE9217 FILE ACCESSES WHILE OPEN
VMAC92 But, the subtype 16 is NOT documented in the z/OS 2.1 SMF
VMXGINIT SMF Manual nor in SYS1.MACLIB ember BPXYSMFR, so none of
Apr 20, 2014 the subtype 16 specific variables are created, pending
response from IBM with the documentation.
-Reading a subtype 17 record with earlier VMAC92 will
print a harmless INVALID READTIME message.
Change 32.093 -RMF III Documentation Upgrade
ADOCRMFV -There are now 25 sections in the ASMRMFV source
ASMRMFV prologue documentation and in the corresponding
Apr 20, 2014 ADOCRMFV member as follows:
Section Contents
------- --------
0 Contents
1 Installation
2 Terminology
3 Execution JCL
4 RMF III Table Input Selection Parameters
5 Input Data Selection Parameters
6 Report Control Parameters
7 Output Data Control Parameters
8 Error Handling Parameters
9 JCL and SYSIN Parameter Usage
10 Parameter Syntax Rules
11 Parameter Coding Examples
12 Common Report Messages
13 Filtered Records
14 Skipped Records
15 Program Limitations
16 Return Codes
17 Abend Reason Codes
18 REGION Size and Memory Usage
19 Output LRECL
20 FREE=CLOSE
21 Extended ASI/ENC/UWD Record Support
22 RMF III Data Set Index Usage and Sizing
23 RMF III MONITOR III Options and Effect on
Data
24 RMF III MONITOR III Sysplex Master
Gatherer & CFDETAIL
25 Summary
-Section 1. New. "Installation" has been added.
-Section 2 "Terminology" has been expanded.
-Section 12 "Common Report Messages" is greatly expanded
to include most information-only messages in the ASMRMFV
log.
-Section 17. New. "Abend Reason Codes" added. Each Abend
Reason Code that can be issued is now unique with no
repeat usage.
-REQUIREMENT: In order to implement the unique Abend
Reason Code feature the ASMRMFV utility program from this
MXG change must be installed. See MXG SOURCLIB member
JCLASM3 for sample JCL for the assembly and link-edit
install steps.
Change 32.092 Initial support for TMON/MVS Version 4.4 (INCOMPATIBLE).
VMACTMVS This change updated the TMVSSYS dataset. Contact support
Apr 17, 2014 at MXG to request the next dataset(s) you need updated.
Change 32.091 MXG 32.03: VGETOBS on z/OS could elongate elapsed time
VGETOBS and increase EXCP counts; both effects are now corrected:
Apr 17, 2014 -If there are tape DDs in the step, a loop inside the
Jul 11, 2014 macro did not use the correct index in VGETTAPES string
(contains all detected TAPE data library DDNAMES). Only
the first was found so other tape DDs could be read to
look for the needed dataset, causing an increase in EXCPs
and elapsed times. VGETOBS now uses the %SYSFUNC for the
EXIST function that checks for the existence of a SAS
dataset, and for the FEIXST function that validates the
EXTFILE name, and uses OPEN/CLOSE to get the number of
OBS in the dataset, instead of using the (expensive)
dictionary tables, unless DATASET=_ALL_ was specified to
build the MXGTABLES dataset.
-On zOS, VGETOBS can optionally build a dataset to keep
track of all tables it finds. Then, when done, it deletes
that table, but that destroyed the SYSLAST/_LAST_ value,
so a subsequent PROC step without a DATA= argument failed
with a dataset not found error. Now, VGETOBS preserves
SYSLAST in VGETLAST and resets SYSLAST to VGETLAST.
-Jul 11: THIS ERROR CAN ALSO SIGNIFICANTLY INCREASE THE
CPU TIME of any job with LOTS of VGETOBS executions.
In one case, 29.06 took 20 seconds, while 32.01 took 192.
Thanks to Betty Wong, Bank of America, USA.
Change 32.090 AUTOEZOS/CONFIGEZ provide new "EAZY" methods to execute
AUTOEZOS MXG on z/OS with SAS 9.2 and above, using your site's SAS
CONFIGEZ JCL procedure and your site's default SAS options.
JCLEZCFG Jul 19: WPS 3.1.1 is required for AUTOEZOS.
JCLEZSAS -The JCLEZSAS example %INCLUDEs the new AUTOEZOS member,
Apr 17, 2014 which uses the SAS APPEND= option to set the //LIBRARY
Jul 19, 2014 DDNAME for the MXG Formats, uses the SAS INSERT= option
to add SOURCLIB to SASAUTOS, and then invokes %VMXGINIT
to set the other options required for MXG execution.
This is the simplest way to set up the MXG environment,
but it does require that your site's SAS options do not
conflict with those needed by MXG's environment.
(It is unlikely you would need to tailor AUTOEZOS.)
-The JCLEZCFG example would be used if your default SAS
options conflict with those required by MXG, where simple
JCLEZSAS cannot be used. JCLEZCFG adds a CONFIG= option
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIGEZ)' as CONFIGEZ
sets ALL MXG-required options; the JCLEZCFG example also
then %INCLUDES AUTOEZOS, as above, to set the LIBRARY and
SOURCLIB DDNAMEs and to invoke %VMXGINIT. Since all MXG
required options are in CONFIGEZ member, it is unlikely
that you would need to tailor it, although those SAS
options that must be set at SAS Initialization can only
be set in that CONFIGEZ member.
Thanks to MP Welch, Bank of America, USA.
Change 32.089 IBM TYPE30 field SMF30CPT (CPUTCBTM) has always included
VMAC30 CPUASRTM (SMF30ASR), but ASR is time under an SRB, so ASR
Apr 17, 2014 is now subtracted from CPUTCBTM and added to CPUSRBTM so
Aug 7, 2014 those variables match reality; this has no impact on the
total CPUTM variable (which IMO should be used, always).
MXG also had subtracted CPUASRTM from CPUTCBTM to create
TASKGCPTM, but that subtraction is redundant and removed.
- I am asking IBM SMF if the new ASR Instruction Counts
are also included in the CPT Instruction Counts.
Apr 23: IBM RMF support replied that the WLMGL Report in
the RMF Report Analysis Book shows under SERVICE, that
CPU service includes the task and preemptible-class SRB
processor service, and the SRB units contain only the
non-preemtible SRB service units. Unfortunately, in the
RMF 72 records, there is no "ASR" field with either the
service or CPU time of the preemptible-class SRB metric.
Aug 7: This reduction in CPUTCBTM increased the value
of variable AVGWKSET in TYPE30 datasets, calculated as
AVGWKSET=4*PAGESECS/CPUTCBTM;
starting with MXG 32.04.
Thanks to Julian Smailes, Experian, ENGLAND.
Thanks to Brent Turner, Citigroup, USA.
Change 32.088 Support for NMON BBBPMOUNT and BBBPNETSTAT records create
EXNMONMT new datasets:
EXNMONNS DDDDDD DATASET DESCRIPTION
IMACNMON NMONMT NMONBBBPMOUNT NMON BBBP MOUNT
VMACNMON NMONNS NMONBBBPNETSTAT NMON BBBP NETSTA
VMXGINIT The mount record contains only the month and day without
Apr 17, 2014 a year; if the current month is larger than the mount
month, the mount date uses last year's year value.
-An INVALID ARGUMENT to FUNCTION INPUT when BBBPEND051 had
a one-digit hour value was corrected.
-Jul 17: Cosmetic. _WNMONFR, _WNMONFW and _WNMONFO in the
MACRO _NNMON were removed; they never existed.
Thanks to Len Marchant, Coke-Cola, USA.
Change 32.087 Support for SMF 120 Subtype 100 ODM (Operational Decision
VMAC120 Manager record creates new dataset:
VMXGINIT dddddd dataset Description
IMAC120 T1201C TY120100 ODM OPERATIONAL DECISION MANAGER
EXT1201C Jun 3 update, in MXG 32.05:
Apr 18, 2014 -Only Subtype 100 with non-zero EXN are output; st-100's
Jun 3, 2014 are written every interval (30 minute default), one for
each CICS APPLID in test data, but most have no segment;
some records do have multiple EXN segments so each one is
now output in dataset TY120100.
-IBM offset EXO is strange, required +5 to locate the data
segment. (-3 is normal, rarely +1, but never +5 before!),
but it is now used to correctly align each input.
-IBM length EXL is also "wrong", as it is the TOTAL length
rather than the expected length of one segment, so it is
now divided by EXN to get the per-segment length for each
segment's input.
-GMT Offset is now kept in existing SM1209CD variable.
-SM120STM/SM120ETM are now correctly labeled.
Thanks to Paul Volpi, UHC, USA.
Thanks to Scott Barry, SBBWorks Inc., USA.
Change 32.086 Execution with SAS 9.3 TS1M0 now raises an MXGWARN note:
VMXGINIT MXGWARN: SAS 9.3 TS1M0 DETECTED. SAS HOT FIX (SN43828)
Apr 14, 2014 MXGWARN: REQUIRED TO PREVENT LET-STATEMENT ERRORS.
MXGWARN: BETTER STILL:: 9.3 TS1M1 CONTAINS THE FIX.
(This need was documented in CHANGE 29.159 in 2011.)
Change 32.085 These QWP1/4/5/9 variables were overlooked, but are now
VMAC102 INPUT and kept in T102S106 dataset:
Apr 15, 2014 QWP1DATH QWP1DPSS QWP1DSGN QWP1DSSZ QWP1DXAC
QWP1LBIL QWP1LOGM QWP1LOGR QWP1ZPNM
QWP4AECR QWP4APCO_VAR QWP4ATRC QWP4CDDC QWP4CDMC
QWP4CDSC QWP4CDTSL QWP4CXDC QWP4CXMC QWP4CXSC
QWP4DEGD QWP4DLRU QWP4FCPY QWP4HASH QWP4IAST
QWP4IMWF QWP4IXCU QWP4KLRU QWP4MIMTS QWP4MIS7
QWP4MIS8 QWP4MIS9 QWP4MISA QWP4MISB QWP4MS4F
QWP4MUSE QWP4N0193A QWP4N0193B QWP4PELM QWP4PFLG
QWP4PFUP QWP4PLMR QWP4PLSF QWP4PMSC QWP4QRWD
QWP4RACK QWP4RDVPR QWP4RMDB QWP4RSLV QWP4S1IL
QWP4SFBS QWP4SLRU QWP4WFSAT QWP4WFSST QWP4SEPSD
QWP4SECA1_E QWP4SECA1_TYPE QWP4SECADM1
QWP4SECA2_E QWP4SECA2_TYPE QWP4SECADM2
QWP5BPM QWP5APM
QWP9TCPVX QWP9MCONQN QWP9MCONQW QWP9DDFC QWP9TCPA
Thanks to Wolfgang von Schumann, Finanz Informatik Tech, GERMANY.
Thanks to Norbert Philips, Finanz Informatik Technologie, GERMANY
Change 32.084 Typo. If you modified macro _GRAPALNM, an MXGNOTE was
ASUMTALO printed that it had been added to the BY LIES instead of
Apr 9, 2014 BY LIST.
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 32.083 ANALID did not follow MXG conventions with an &Pxxxxxx or
ANALID a _L/_Wdddddd tokens. Revised to use the &PDBMXG macro
Apr 5, 2014 variable so that if the output destination was overridden
by VMXGINIT SMFRECNT will end up in the right place.
Change 32.082 These NETEZZA/IDAA PDB.DB2STATS Q8STxxxx variables should
VMACDB2 not have been deaccumulated:
Apr 5, 2014 Q8STACTV_64 Q8STCCPU_64 Q8STCORS Q8STCPMU Q8STCQL
Q8STDSA Q8STDSKA Q8STDSKB Q8STDSKU Q8STMAXA_64
Q8STMAXQ Q8STMNQS Q8STNMDS Q8STNQCS Q8STTATE
Q8STWCPU_64 Q8STWNOD_64
IBM doesn't always identify which fields are accumulated,
so the DIF() code is put in place, and then data is read
to detect negative values (proof of not accumulated so
those variables are removed) but I failed to run the test
for negative values in Change 32.072.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.081 A minor exposure in UTILBLDP. If IMACKEEP= was not used
UTILBLDP (blank) AND BUILDPDB was YES then the substitution macros
Apr 4, 2014 for SPINCNT SPINUOW and TIMEDIF were defined twice which
could result in MACRO 0 0 % which is not a valid syntax
and produced an error message but did not stop execution.
Now only generated if BUILDPDB EQ YES. MACKEEP and
MACFILE are now nulled out after execution.
Change 32.080 ANALDB2R selection parameters use the =: colon modifier
ANALDB2R to select "Starting With". If you used DB2=DSN to select
Apr 3, 2013 only the DSN subsystem, but have subsystems DSN DSNT and
Apr 15, 2014 DSNP, all three will be selected.
New parameters INCODEACCT and INCODESTAT let you define
your own selection criteria.
INCODEACCT= applies to the accounting reports and many
trace reports, while
INCODESTAT= applies to the stats reports. For the
For the above single-subsystem selection, you would use:
INCODEACCT=IF QWHSSSID='DSN';
-MXGACC03 could fail on zOS with dataset not found error
because SYSLAST was overwritten by VGETOBS but the last
dataset created by VGETOBS no longer existed, because the
TABULATE did not contain a DATA= argument.
Change 32.079 The _V and _K tokens for TYPE9035 were incorrectly set to
VMAC90A 9036 instead of 9035.
Apr 3, 2014
Thanks to Chris Weston, SAS ITRM, USA.
====== Changes thru 32.078 were in MXG 32.03 dated Apr 3, 2014=========
Change 32.078 Support for OAM SMF 85 record for z/OS 2.1 (INCOMPAT).
VMAC85 The record VERSION test required an explicit '2010' value
Apr 3, 2014 to prevent INPUT STATEMENT EXCEEDED RECORD error.
Thanks to Joachim Sarkoschitz, DATEV, GERMANY.
Change 32.077 Support CICS/TS 5.2 OPEN BETA: CICSTRAN COMPAT, Stat NOT:
VMAC110 -5.2 CICSTRAN has been SUPPORTED since MXG 31.03 (3/2013),
Mar 31, 2014 as NO NEW FIELDS WERE ADDED TO CICSTRAN IN CICS/TS 5.2,
Apr 1, 2014 at least not in the OPEN BETA (so GA could be changed!).
(MXG 31.03 or later is required for CICS/TS 5.1.)
-5.2 STID=62 CICDS Dispatcher CPU Statistics (per-TCB CPU)
records read with MXG 32.02 or earlier are wrong/missing
values, due to fields inserted in STID=62 segments. MXG
does detect and report that STID=62 was CHANGED, but only
in obscure ***MXG WARNING.TYPE110 messages that don't
tell you the output was trashed. MXG did continue to
read the rest of your SMF data after those warnings.
WITH THIS CHANGE: CPU times are correct.
-STID=62 CICDS dataset has these variables read from the
header and kept
DSGLXSCN='LAST EXCESS*TCB SCAN'
DSGLXSND='LAST EXCESS*TCB SCAN*NO TCB*DETECTED'
and 18 sets of these three variables are added, one per
TCB, with "DSG" replaced by each TCB's prefix:
DSGTMCDQ='QR TCB*CURR TASKS*DISPATCH*QUEUE'
DSGTMCDQ='QR TCB*PEAK TASKS*DISPATCH*QUEUE'
DSGTMCDQ='QR AVG*PEAK TASKS*DISPATCH*QUEUE'
-STID=62 CICSPOOL Pool dataset has these five new varS;
DSGLTCB='OPEN POOL*DATETIME*WHEN*POOL LIMIT*REACHED*/
DS2LTCB='JVM POOL *DATETIME*WHEN*POOL LIMIT*REACHED*/
DS3LTCB='XPT POOL *DATETIME*WHEN*POOL LIMIT*REACHED*/
DS4LTCB='SSLD POOL*DATETIME*WHEN*POOL LIMIT*REACHED*/
DS5LTCB='THRD POOL*DATETIME*WHEN*POOL LIMIT*REACHED*/
-5.2 also changed STID 10, 81 and 105, but COMPATIBLY with
new data appended rather than inserted, so prior versions
MXGWARNed there was new data and skipped with no impact.
-5.2 new STIDs 36 and 147 were also safely skipped.
-STID=10, CICXMG dataset, XMG DSECT, new variables:
XMGATMXT='80X*IF*CURRENTLY*AT MXT'
XMGGAMXT='GMTTIME*WHEN*MXT*REACHED'
XMGGSMXT='GMT*WHEN*MXT*SET'
XMGGTAT ='GMT*WHEN*LAST*ATTACHED'
XMGLAMXT='DATETIME*WHEN*MXT*REACHED'
XMGLSMXT='DATETIME*WHEN*MXT WAS*SET'
XMGLTAT ='DATETIME*WHEN*LAST*ATTACHED'
-STID=81, CICM dataset, MNG DSECT, new variables:
MNGAUTRT='AVG*USER*RESPONSE*TIME'
MNGCAUTA='CURR TASKS*AT LAST*ATTACH'
MNGLUCTL='DATETIME*WHEN*LAST*ATTACH'
MNGLUCTL='DATETIME*WHEN*LAST*TRANS*ENDED'
MNGLUTRT='DATETIME*WHEN*PEAK*RESPONSE'
MNGMXUTA='MXT VALUE*AT LAST*ATTACH'
MNGPUTRT='PEAK*USER*RESPONSE*TIME'
MNGSTNUM='SYSTEM*TRANSACTIONS*ENDED'
MNGUTNUM='USER*TRANSACTIONS*ENDED'
-STID=105, CICPIR dataset, PIR DSECT, new variables:
PIRMSGFO='MSGFORMAT'
-New STIDs 36 and 147 are listed as STILDP and STIPGE and
listed as PRIVATE LODER and PRIVATE PROGRAMDEF, but the
OPEN BETA DATA AREAS does not have LDP nor PGE, yet.
Change 32.076 -INPUT STATEMENTs EXCEEDED, one due to invalid TOKDANAM
VMAC80A 'UID' segment with 6 bytes of data but TOK80LN2 only 3;
Mar 31, 2014 this is detected, an MXG error message printed of the
first two instances, and two due to the increased lengths
of TOKQUEST2 and TOKANS2 fields (where MXG has to pick a
max length, but I guessed wrong).
-Variable RACF31DS, RVARY DSN added to TYPE8025 dataset.
-TOKDANAM values 'FTEL' 'MTEL' 'EMAIL' are decoded into
new TOKFTEK/TOKMTEL/TOKEMAIL variables and 'ADDRESS1' and
'ADDRESS2' values are output in existing TOKAD1/TOKAD2
variables in TYPE80TK dataset.
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 32.075 Retrieves current ODS destination into a global variable
VGETDEST VGETDEST. If no ODS destination has been set it will get
Mar 31, 2014 the ODSDEST option value (normally AUTO), which on zOS is
LISTING and on ASCII is HTML. Used internally in MXG in
new SGPLOT reports.
Change 32.074 -DB2 IFCID 402 dataset T102S402 now outputs all segments;
VMAC102 previously only the first segment was output. But obs
Mar 27, 2014 are only output after deaccumulation if QW0402ACTIVE,
Mar 31, 2014 QW0402ACTIVE=SUM(QW0402TE,QW0402TQ,QW0402TF,QW0402TW,
QW0402CE,QW0402CW,QW0402OE,QW0402OW);
shows there was activity during this 1-minute interval.
-The BY list _B102402 now includes QW0402PI, Profile ID,
which is the unique token in each segment.
Thanks to Paul Walters, Navy Federal Credit Union, USA.
Change 32.073 The _SMF processing macro is enhanced to read either the
VMACSMF //SMF DD to read dumped SMF VBS data, or the //LOGGER DD
VMXGINIT to directly read current SMF logstream data, or to
Mar 27, 2014 first read //SMF DD (which can be a concatenation of SMF
VBS data, and then read the //LOGGER DD. The default of
SMF is unchanged, to read the //SMF DD, but you can use
%LET MXGREADSMF=LOGGER;
to ONLY read the LOGGER file, or you can use
%LET MXGREADSMF=BOTH;
to read both.
-For LOGGER read, OFFSMF=0 is now set in VMACSMF, so the
macro variable READLSMF (Change 31.235) was removed from
VMACSMF as no longer used by this change, which also
removed READLSMF from VMXGINIT (in MXG 32.03).
Apr 22: I had to send this 32.03 VMXGINIT to a site with
the INSTREAM error; using the new VMXGINIT with the old
VMACSMF did NOT work, and generated spurious errors of
INVALID SMFTIME; removing READLSMF from VMXGINIT caused
UNRESOLVED MACRO READLSMF condition, which caused MXG's
test for &READLSMF EQ 0 to fail, so VMACSMF fell thru and
attempted to read the VBS //SMF file with the (correct
for Logger) attributes of RECFM=VB,LRECL=32756, which
broke logical records and caused INVALID SMFTIME errors.
This won't likely occur again, but I put READLSMF back in
VMXGINIT's %GLOBAL statement.
-Variable READSMF contains 'SMF' or 'LOGGER' to identify
the source of each record during processing, variables
NDUMPREC and NLOGREC count the records read from //SMF
and //LOGGER respectively. You could hex-dump the first
record from each infile with
%LET MACFILE= %QUOTE(
IF NDUMPREC=1 THEN LIST;
IF NLOGREC=1 THEN LIST; );
Thanks to Jim S. Horne, LOWE's Companies, USA.
Change 32.072 -DB2ACCT variables QWACAACC and QWACAACW (IDAA statistics)
VMACDB2 are now INPUT and kept.
Mar 28, 2014 -These DB2STATS IDAA/NETEZZA variables added in DB2 V11
are now INPUT and kept:
Q8STACTV_64 Q8STCQL Q8STCRL Q8STCSS
Q8STDSA Q8STMAXA_64 Q8STMAXQ_64 Q8STMNQS Q8STNDS
Q8STNBA Q8STNBS Q8STNDA Q8STNIA Q8STNIS
Q8STNLRA Q8STNLRS Q8STNLTA Q8STNLTS Q8STNQCS
Q8STNQFA Q8STNQSA Q8STNUA Q8STNUS Q8STTART
Q8STTATC Q8STTCCA Q8STTCCS Q8STTCMA Q8STTCMS
Q8STTCQA Q8STTCQS Q8STTLSC Q8STWCPU_64
Q8STWNOD_64
PROBLEMS:
-The data needs validation; many values are zero making
determination difficult; most values do look reasonable,
but there are 8 extra bytes not in the DSECT that are
skipped at the top of the segment, which might be the
wrong place, but there is consistency with the "ALL DB2"
variables with "S" suffix that all have values of -1
(INPUT as IB8) while their "THIS DB2" variables with "A"
suffix are populated.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.071 Connect-Direct NDMCPU='CPU TIME*OF STEP' is now added to
VMACNDM the NDMPT dataset, along with these new variables:
Mar 26, 2014 NDMECP0 ='CPU TIME*ON CP'
NDMECP1 ='CPU TIME*ON ZIIP'
NDMECP2 ='ZIIP*QUALIFIED*PART OF*NDMECP0'
NDMHQSTA ='QUEUE*STATUS*IF*PTQHOLD'
NDMSUBJID='SUBMITTING*JCTJOBID'
NDMSUBJOB='SUBMITTING*JOB'
And these variables are added to NDMCT dataset:
NDMECP0S='SEND*CPU TIME*ON CP'
NDMECP1S='SEND*CPU TIME*ON ZIIP'
NDMECP2S='SEND*ZIIP*QUALIFIED*PART OF*NDMECP0S'
NDMECP0R='RECV*CPU time*on CP'
NDMECP1R='RECV*CPU time*on ZIIP'
NDMECP2R='RECV*ZIIP*QUALIFIED*PART OF*NDMECP0R'
Thanks to Michael Oujesky, DTCC, USA.
Change 32.070 Support for ASG-TMON CICS TS V3.4 (NO MXG UPDATE NEEDED).
TYPETMO2 TMON CICS v3.4 is the toleration support for CICS/TS 5.2,
Mar 24, 2014 which is now in Open Beta, but there were NO changes to
their data records so there is no associated update.
Change 32.069 When trying to reduce the line size of the code being
VMXGPARS generated by UTILBLDP to 65 bytes to fit on neat and
Mar 24, 2014 pretty lines in INSTREAM, VMXGPARS parsing went backwards
from BYTE 65 to 50 looking for a blank but if it did not
find one it arbitrarily stopped, which could be in the
middle of a quoted string causing broken syntax and many
strange errors. Now, the search continues until a blank
is found. This error was NOT reported. It was exposed
when testing UTILBLDP with new syntax in MACFILEX=.
Change 32.068 New DB2 Buffer Pool analysis report, based on SHARE
ANALDB2R Anaheim Session 14610, Robert F. Catterall, IBM, "Key
Mar 23, 2014 Metrics for DB2 for z/OS Subsystem and Application
Performance Monitoring", using the DB2STATB dataset.
Based on the total read I/O rate, it can suggest if the
Buffer Pool is too small, or if perhaps it is too large.
With SAS 9.3+, charts are produced, followed by a report
identifying BPs these problem criteria:
Avg read IO rate GE 1000/sec
Max read IO rate GE 5000/sec
Total BP size exceeds 50% of available CSTORE
Max used buffers LT 25% of BP
If no BPs fit the exception criteria a message is
produced telling you that.
This is report MXGDB2B1 in ANALDB2R.
Change 32.067 Cosmetic. Missing values for OPENTM occur when OPENTIME
VMAC64 variable is not populated; TYPE64 observations with
Mar 21, 2014 SITUATN='NO SPACE AVAILABLE' or 'CATALOG UPDATE' do not
populate OPENTIME; OPENTM calculation is now protected.
Some of these obs have large negative value in UNUSEDCI.
Change 32.066 Support for selection by DSNAME for all MXG datasets that
IMACDSCK contain a "DSNAME" value with the new &MACDSCK facility.
Mar 21, 2014 See the documentation examples in IMACDSCK, but this will
find all observations in SMF record with DSNAME that
starts with SYS1."
%LET MACDSCK=
%QUOTE (
LENGTH DSNAME ENTRNAME $44;
IF INDEX(DSNAME,'SYS1.') OR
INDEX(ENTRNAME,'SYS1.') THEN
);
%UTILBLDP(BUILDPDB=NO,OUTFILE=INSTREAM,
USERADD=1415 1718 42 60 6156 62 6
%INCLUDE INSTREAM;
RUN;
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 32.065 Support for APAR OA44798 enhancement to SMF ID=22 record,
VMAC22 added the new Subtype 12 Storage Element Extension, adds
Mar 21, 2014 two variables to the existing TYPE22_3 dataset:
SMF22XGL='BLOCK*NUMBER OF*FIRST*FRAME'
SMF22XPG='ONLINE*FRAMES'
Change 32.064 Line 77 had an unwanted close-paren and semicolon that
ANALID prevented ODS output and are now removed.
Mar 20, 2014
Thanks to Sabrina Mandelatz, Provincial, GERMANY.
Change 32.063 Hydra TS7700 IBM reports are replicated in ANALBVIR.
ANALBVIR These reports are completed:
JCLBVIR REPORT DESCRIPTION
Mar 18, 2014 H20VIRT VNODE VIRTUAL DEVICE HISTORICAL RECORDS
Apr 6, 2014 H21ADP00 VNODE VIRTUAL DEVICE HISTORICAL RECORDS
H21ADPXX VNODE VIRTUAL DEVICE HISTORICAL COMBINDED
H21ADPSU VNODE ADAPTOR HISTORICAL ACTIVITY COMBINDED
H21ADPTP VNODE ADAPTOR THROUGHPUT DISTRIBUTION
H30TVC1 HNODE HSM HISTORICAL CACHE PARTITION
H30TVC2 HNODE HSM HISTORICAL CACHE PARTITION (1)
H32TDU12 HNODE LIBRARY HISTORICAL DRIVE ACTIVITY
H32CSP HNODE LIBRARY HIST SCRTCH POOL ACTIVITY
H32GUP&NUM HNODE LIBRARY HIST GUP/POOLING ACTIVITY
Thanks to Joe Babcock, JPMorgan Chase, USA.
Change 32.062 Variables R791PHTA/PHTI/FLG3/FLG3A/R791FLG3S & similarly
VMAC79 variables R792PHTA/PHTI/FLG3/FLG3A/R792FLG3S are kept in
Mar 17, 2014 datasets TYPE791 and TYPE792 respectively. Added in z/OS
2.1, but the 2.1 SMF manual had no vertical bars to mark
the new fields. (IBM acknowledges the error and will fix
for the 2.2 SMF manual.)
Change 32.061 Graphs from two SHARE 2014 Anaheim presentations, Session
GRAFCIMP 15214, "WLM Update for z/OS 2.1 and 1.13" by IBM's Horst
Mar 16, 2014 Sinram, and Session 14745, "WLM - Performing a Quick WLM
Performance Checkup", by Peter Enrico are replicated with
with graphs of CPU resource by importance level and
service class level, and then at the service class level
within importance, plus a scatter graph of performance
index at the importance level with additional scatter
graphs at the service class level within importance. As
a side benefit you can also see how many service class
periods are active at each importance level. The graphs
are produced by PROC SGPLOT; SAS/GRAPH is NOT used.
Example report output can be at viewed at:
Http://www.mxg.com/download/Change 32.061
Change 32.060 %INCLUDE of VMXGUOW was needed in these examples to get
JCLUOW _SUOW and _BSUOW values, but that could cause errors due
JCLUOWP to a conflict executing VMXGUOWC. This change inserts the
JCLUOWV _SUOWxxx and _BSUUOW macro definitions in these members
Mar 16, 2014 to eliminate the %INCLUDE and associated exposure.
Change 32.059 Support for ZEN 2280 product's new CSM records (INCOMPAT,
EXZOSAJB because existing subtype 32 header had inserts).
EXZOSAPO Three new datasets are created:
EXZOSASU dddddd Dataset Description
IMACZOSA ZOSASU ZOSASUMM CSM Summary
VMACZOSA ZOSAPO ZOSAPOOL CSM Per Pool
VMXGINIT ZOSAJB ZOSAJOB CSM per JOB
Mar 14, 2014 -Outstanding issues with first iteration:
SYSTEM variable is blank.
Intervals drift 2 seconds per hour, and are not SYNC
with SMF.
JOB dataset does not have READTIME nor JESNR.
Change 32.058 Thruput Manager INVALID ARGUMENT- TPMPI=INPUT(TPMPICH,1.)
VMACTPMX because the previously expected $EBCDIC1 numeric value of
Mar 13, 2014 importance is now a binary ('03'x) requiring a new test
and conditional input of TPMPI, in dataset TPM16J.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 32.057 z/VM data files for Velocity zXPS, MONWRITE, etc, MUST be
VMACXAM FTP'd with TYPE E specified, which is NOT the default.
Mar 13, 2014 Worse, when the default IS used its value is NOT shown
on the ftp log. The ftp default is TYPE A, ASCII text,
and I was unaware that when TYPE A FTP transfer goes from
one EBCDIC system to another EBCDIC system (e.g. z/VM to
z/OS), it changes from EBCDIC to ASCII and back to
EBCDIC, which leaves the UPPERCASE TEXT unchanged, but
the binary data is mangled. One specific mangle: '64'x
original value becomes '3F'x, so the 100 byte length of
SYTSYP became 63 which caused MXG ERROR messages. This
change tests for a length of not-100 and issues a USER
ABEND 666 to report the wrong FTP TYPE was used.
Using MODE BLOCK is also recommended for these ftp's.
Thanks to Wang Zahn, AIG, USA.
Thanks to Rob van der Heij, Velocity Software, EUROPE.
Change 32.056 CANNOT CLONE BUFFSIZE warnings during PROC COPY might be
VGETOBS bad for execution EXCPs and run time, and this could have
Mar 13, 2014 been caused by VGETOBS, under unusual circumstances, when
it made a bad decision and issued a LIBNAME statement for
a sequential-format-on-disk instead of normal disk. This
could happen on z/OS only, only if the dataset had never
been opened for output, and VGETOBS was issued against
the DDNAME, AND, there are tape datasets allocated to the
job, and this can only happen on the very first invoke of
VGETOBS when it reads all LIBNAMEs to identify those on
tape/sequential format. Now, VGETOBS recognizes that the
DDNAME is not SAS or at least has not been opened and it
does NOT issue a LIBNAME statement.
Note: A SAS data library in sequential format on disk
does not have a directory, so SAS must read all
records from the start to find a dataset.
Thanks to Paul Volpi, UHC, USA.
Change 32.055 -RMF III Enhancements, Fixes, and Notes
ADOCRMFV -A new generic RMF Monitor III table selection parameter
ASMRMFV BASIC is supported. This is a convenient shorthand
Mar 12, 2014 method to select RMF III tables of most common general
Mar 14, 2014 interest and usage. There is no alias for BASIC.
Mar 30, 2014 BASIC selects these RMF III tables:
ASI CAT CPC CPU DVT ENC GEI OPD RCD
-A new generic RMF Monitor III table selection parameter
MOST is supported. This is a convenient shorthand method
to select all possible tables of any practical value.
There is no alias for MOST.
MOST includes all the tables selected by BASIC and in
addition selects these RMF III tables:
CFI CPD CSR ENT SPG SVP.
-NOTE: All other RMF III tables may still be selected or
filtered even when BASIC or MOST is specified to achieve
other useful table selection combinations.
For example, these PARM values in JCL (or alternatively
in the SYSIN DD file) are all valid:
PARM='BASIC,CPD,CSR' Add CPD and CSR to BASIC set
PARM='BASIC,NODVT' Exclude DVT from BASIC set
PARM='MOST,NOSPG' Exclude SPG from MOST set
-Recent information obtained indicates that the Invalid
Resource bit may be set for Processor entries in the RED
table in a MINTIME interval due to normal processor
change events. So these are not true RED table errors.
Operation is changed for RED Processor entries only so
that when the RED table is selected and the Invalid
Resource bit is on, then the entry is still skipped, but
no error messages are now issued, and the Return Code is
left unchanged. Prior to this change error messages were
generated and Return Code 0016 would be set. Error
handling for other types of RED entries is unchanged.
-The behavior for the 'ALL' table selection parameter was
changed in Change 32.037 so that it overrode any NOxxx
table filter options regardless of input order. However,
this was inconsistent with the operation when 'ALL' was
default because only NOxxx filters were coded. Those in
effect did override 'ALL', but this change restores the
earlier behavior so that any NOxxx filter parameters will
be honored even when 'ALL' is coded. No further behavior
changes are planned for this condition.
-Change 32.037 also altered the behavior when both NOxxx
table filter and table xxx selection parameters were used
for the same table. The xxx table selection parameter
always overrode the NOxxx table filter parameter
regardless of input order. This change reverses that
behavior so the NOxxx filter parameter always overrides
the xxx selection parameter for the same table. No
further behavior changes are planned for this condition.
-NOTE: Please do not select AND filter on the same RMF
Monitor III table in the same ASMRMFV run to avoid
unintended results.
-Documentation in the ASMRMFV source prologue and in the
ADOCRMFV member has been updated appropriately.
-When validating a large RMF III CFI table and a section
offset exceeded X'FFFF', the calculation for the output
CFI record length was incorrect. The entire CFI table was
then skipped because the result record length was over
32K. Message RMFV035S was issued followed by Return Code
0016. The register used in the length calculation is now
cleared prior to inserting each half word section length
for validation so that the CFI table is not skipped.
-Updated documentation content, and mixed casing as well!
-REQUIREMENT: In order to implement this fix the current
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Thanks to Warren Cravey, Fidelity Institutional, USA.
Change 32.054 Variables SMF70CPA_SCALING,SMF70CPA_ACTUAL were input two
VMAC7072 bytes to the right, producing very large numeric values,
Mar 10, 2014 but the SCALING/ACTUAL ratio, now SMF70CPA_RATIO was the
same! The new z/OS 2.1 RATIO is used instead of raw-CPA
to calculate the SMF70CPA Service Unit Per Second value:
New: SMF70CPA=16000000*SMF70CPA_RATIO
Old: SMF70CPA=16000000/SMF70CPA-in-Record
So the new ratio is the inverse of the RMCTADJC, almost:
Raw CPA=423 1/423=.002364066 ==> SMF70CPA= 37825.059
SMF70CPA_RATIO =.002364590. 37833.440
The raw-CPA is an integer, which limits the granularity
of SMF70CPA value. Integer 424 sets SMF70CPA=37914.692
so the exact 37833 value cannot be set with raw-CPA. Now,
since RATIO is a fraction, any numeric value can be set
for SMF70CPA in future engines. The numeric difference
is small, but with this change, for z/OS 2.1, SMF70CPA
is now calculated using the SMF70CPA_RATIO value.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 32.053 Compression ratios SMF21CRR/SMF21CRW are now calculated
VMAC21 for non-3590 devices, using these existing variables:
VMAC21 SMF21CRR=BYTEREAD/SMF21MDR;
VMAC21 SMF21CRW=BYTEWRIT/SMF21MDW;
VMAC21 For 3590s, note that:
Mar 10, 2014 -Bit SMF21NCT is on ONLY for 3590s and inputs the channel
and device bytes read/written SMF21BRN/BWN/DBR/SMF21DBR
variables, now used for the compression ratio.
-Bit SMF21MFV is NOT on for 3590s, so the previous counts
of bytes read/written/compressed will always be missing
for 3590s in variables SMF21MCR/MDR/CRR/MCW/MDW/DRW.
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 32.052 Support for SMF 112-35 Tivoli Enterprise Monitor Server
EX112TEM record creates new dataset
IMAC112 dddddd dataset description
VMAC112 112TEM T112TEMS Tivoli Enterprise Monitor Server
VMXGINIT There are also subtypes 32 thru 37 that may be supported
Mar 10, 2014 in a later update to this change.
Thanks to Michael Oujesky, DTCC, USA.
Change 32.051 Test added to SUOWMQ macro to check for MQMADD value of
VMXGUOW NO to bypass reading the CICUOW dataset. This will let
VMXGINIT you set _UOWCIC to _NULL_ and save a lot of WORK space by
Mar 9, 2014 eliminating the creation of a dataset that is ONLY used
if you also have MQ data and have specified MQMADD=YES.
Change 32.050 RMF III datasets ZRBRCDS (Service Class) and ZRBRCDR
VMACRMFV (Report Class) did not contain the five CPUxxxTM values
Mar 8, 2014 (TCB/SRB/RCT/HPT/IIP), suggesting these RMF III datasets
were seldom used, because the same data exists in RMF I
TYPE72GO dataset. They are now created so that I could
compare the CPU times captured by RMF I, RMF III and SMF.
See MXG Technical Newsletter 64 MVS Technical Note 1.
Change 32.049 Added a WHERE= parameter for the PRINT, MEANS, FREQ, and
VMXGPRAL COMPARE procedure executions so you can insert the SAS
VMXGPRA1 code in a WHERE clause to select what will be analyzed or
VMXGPRNT printed.
Mar 5, 2014
Change 32.048 Protection for invalid SMF 6 record (JCTJOBID vice JOB)
VMAC6 that printed INVALID PRINTIME messages, while the source
Mar 4, 2014 of the invalid records is investigated.
Change 32.047 Support for (E)JES Version 05.40 SMF Record, restructured
VMACEJES to match the standard SMF record structure with triplets
Mar 4, 2014 (Offset/Length/Number) for the three segments of data.
Apr 17, 2014 New variables ESMFCNSR ESMFCNCO ESMF5NSF ESMF5NCF added.
MXGEJES Member MXGEJES is a standalone MXG code execution that is
Jun 16, 2014 provided to Phoenix International (to encourage their
users to consider MXG Software).
Thanks to Ed Jaffe, Phoenix Software International, Inc., USA.
Change 32.046 Support for XCOM 11.5 AND 11.6 (INCOMPATABLE). Records
FORMATS were restructured and MXG code revised to match. Formats
VMACXCOM $MGXCMST and $MGXCMFO now decode STATFLGX and FILEOPT.
Mar 3, 2014 A new segment contains the SMS DATA/MGMT/STORE classes.
Mar 25, 2014 Mar 25: Code corrected, revised for new variables.
Thanks to Rosa Maria Martinez Alonso, Bustia, SPAIN.
Change 32.045 Support for MQ PCF Files creates new dataset:
EXPCFMD
IMACPCF dddddd dataset description
TYPEPCF PCFMD PCFMD PCF MD Record
TYPSPCF
VMACPCF
VMXGINIT
Feb 28, 2014
Thanks to Peter Farrell, Commerce Bank, USA.
Change 32.044 Unused Change Number.
Change 32.043 Support for SMF Record ID=87, GRS Component information
EXTY87 creates new dataset:
IMAC87 dddddd dataset description
TYPE87 TY87 TYPE87 GRS Component
TYPS87
VMAC87
VMXGINIT
Feb 27, 2014
Thanks to Graham Harris, Royal Bank of Scotland, ENGLAND.
====== Changes thru 32.042 were in MXG 32.02 dated Feb 26, 2014=========
Change 32.042 New summary report created if requested. New parameter
ANALID PRINTWHAT= added with default of BOTH. Other possible
Jan 24, 2014 values are DETAIL for the detail report or SUMMARY to get
only the SUMMARY report. For the summary report the data
is summarized to the SMFIDSUB level.
Change 32.041 The OUTPUT MCD; statement was missing; it is now inserted
VMXGHSM in line 1797.
Feb 26, 2014
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 32.040 TMON/VTAM vendor maintenance now populates fields so they
VMACTMVT can be properly decoded/documented. Variables SXORTTD and
Feb 25, 2014 SXORTT are now decoded and formatted as TIME13.3, and the
Feb 27, 2014 SXHRT1D/2D/3D/4D/5D are now labeled INTERVAL vs TIME.
Thanks to Paul Volpi, UHC, USA.
Change 32.039 A MAJOR restructure of BVIR/TS7700/HYDRA support and new
ANALBVIR IBM-reports in ANALBVIR/JCLBVIR will likely require you
EXBVR011 to revise your reporting, but you will no longer have the
EXBVR101 thousands of previous variable names, as the restructure
EXBVR111 creates the "subtype" dataset (EG: BVIR30) with only the
EXBVR301 header variables for that subtype, and repeated segments
EXBVR321 are output in a new dataset (EG: BVIR301), with only ONE
EXBVR322 set of variable names. A few variables names were changed
EXBVR324 and the new reports have been validated against IBM's.
EXBVR331 -In an emergency for an old report, member ZMACBVIR is the
IMACBVIR prior BVIR support structure that can still be used for
JCLBVIR now, but it will NOT be updated nor supported for future
VMACBVIR changes to the BVIR data records. REMOVED JAN 2015.
VMXGINIT -This was a MAJOR update, contributed by Joe; the other
cites are for the Early Adopters who helped in testing.
Feb 25, 2014 -These are now the datasets created from BVIR data:
Feb 28, 2014
Mar 2, 2014 DDDDDD MXG MXG
Mar 8, 2014 DATASET DATASET DATASET
Mar 11, 2014 SUFFIX NAME LABEL DESCRIPTION
Mar 14, 2014 BVIR01 BVIR01 VNODE VIRTUAL DEVICE PIT
Mar 17, 2014 BVR011 BVIR011 HNODE GRID (PIT) CLUSTER
Mar 25, 2014 BVIR02 BVIR02 VNODE ADAPTER POINT IN TIME
BVIR10 BVIR10 HNODE HSM POINT IN TIME
DDDDDD MXG MXG
DATASET DATASET DATASET
SUFFIX NAME LABEL DESCRIPTION
BVIR01 BVIR01 VNODE VIRTUAL DEVICE PIT
BVR011 BVIR011 HNODE GRID (PIT) CLUSTER
BVIR02 BVIR02 VNODE ADAPTER POINT IN TIME
BVR101 BVIR101 HNODE HSM PIT PHYSICAL DEVICE
BVIR11 BVIR11 HNODE GRID POINT IN TIME
BVR111 BVIR111 HNODE GRID (PIT) CLUSTER
BVIR20 BVIR20 VNODE VIRTUAL DEVICE HISTORY
BVIR21 BVIR21 VNODE ADAPTER HISTORY
BVIR30 BVIR30 HNODE HSM HISTORY
BVR301 BVIR301 HNODE CACHE CONTAINER/PARTITION
BVIR31 BVIR31 HNODE RESERVED
BVIR32 BVIR32 HNODE LIBRARY HISTORY
BVR321 BVIR321 HNODE LIBRARY DEVICE TYPE
BVR322 BVIR322 HNODE LIBRARY POOLING CSP MEDIA
BVR323 BVIR323 HNODE LIBRARY POOLING GUP
BVR324 BVIR324 HNODE LIBRARY POOLING GP MEDIA
BVIR33 BVIR33 HNODE GRID HISTORY
BVR331 BVIR331 HNODE GRID CLUSTER
Updates made after MXG 32.02:
Feb 26:
-The variable DEVCLASS was renamed DEVCLSID due to
conflict with existing 30 and 74 name DEVCLASS, and the
variable DVCLASID was renamed to DEVCLSID as only one
name is needed. Format $MGB32DC was merged into and
replaced by $MGB10DC.
-Some formats for BVIR bit map ranges were corrected.
-SCRVOLCT added to _BBVR324 BY list.
-ADOCBVIR updated with why NODUP won't 50% remove.
-Feb 28:
Dateparts in BVIR21 and BVIR31 were two years
wrong - I had moved their calculation to the header,
but had left the recalcs in those two subtypes.
-Mar 2:
The loop counter to read the GUP Container Segments only
read the first four of the thirty-one segments, so obs
were not created in BVIR323 and BVIR324.
-But dataset BVIR323 was output twice incorrectly!
-Lengths of FORMATTED character variables are now set.
-Mar 8:
Variable POOL was added back into BVIR323 and to its BY
list. I revised Joe's code and used _I_ for loop where
the loop variable is not kept, but I messed up this one.
-Mar 11:
Corrections to examine all 32 entries in the POOL loop.
Two new fields, POOL to the GUP and POOL and MEDIA to
BVIR323 and BVIR324 datasets respectively.
A lost pad to the container to bring it to 16 bytes.
With this change, all prior problems are resolved!!!
-Mar 14:
Type 30 code needed to skip some bytes for BVIRVERS=3.
-Mar 17:
Type 20 records BVIRVERS=5 with only 192 bytes caused
INPUT EXCEEDED. Rest revised to verify data exists
for V5 and remainder of skip bytes were removed as there
is only one 20 record.
-Mar 25: There are lots of "null" segments ('00'X for the
ID and/or sum of metrics zero) in BVIR records that not
only wasted space but also were the NODUP culprits. Now
only segments with activity or valid IDs are output,
massively reducing the number of observations. Selection
code added to EXBVR321-322-324-331 exit members, except
that the test for POOLACTV GT 0 is internal to VMACBVIR
because it is also used to terminate the pool loop.
-POOLACTV is tested for these datasets, plus
BVIR321 when DEVCLSID GT '00'X
BVIR322 when MEDATYPE GT '00'X
BVIR324 when PYMDID GT '00'X
BVIR323 when POOLACTV (SUM of Metrics) GT 0
-BVIR331 output when BVIR331ACTV GT 0 (Sum of Metrics)
-Resulting dataset observation counts:
BVIR20,30,31,32,33,301,321 8826 obs
BVIR322 44130 obs
BVIR323,324 26478 obs
BVIR331 7614 obs
Thanks to Joe Babcock, JPMorganChase, USA.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Dan Case, Mayo, USA.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.038 The IMS56FA dataset can have IMSSTCK incorrect when there
VMACIMS was no GMTOFFTM in a prior record; the LINK IMSSTCK in
Feb 24, 2014 56FA logic was prior to the input of the first 12-byte
Mar 17, 2014 character timestamp, from which DEC and then GMTOFFTM can
Mar 23, 2014 be decoded. The LINK for 56FA was located to after that
first DEC value is known; once GMTOFFTM has been created,
its value will be retained.
Mar 17: IMSSTCK links for log records 01x,03x,06x were
mis-located prior to the creation of GMTOFFTM; only if
those records were prior to other GMT-Offset-containing
records, the GMTOFFTM was missing and IMSSTCK was then
not corrected to local time zone.
Mar 23: END; relocated from IMSSTCK: to before LCODE=55.
Thanks to Rosa Maria Martinez Alonso, Bustia, SPAIN.
Change 32.037 -RMF III Enhancements, Fixes, and Notes
ADOCRMFV -A second RMFV008I message is added for non-VSAM data sets
ASMRMFV such as the RMFBSAM and SYSIN DD files that will show DCB
CLRMFV attributes DSORG, RECFM, LRECL, BLKSIZE, BUFNO, and
DOCLRMFV BUFSP.
JCLRMFV -A second RMFV008I message is added for RMF Monitor III
JCLCRMFV VSAM data sets that will show ACB attributes DSORG,
JCLDRMFV LRECL, CISIZE, BUFNO, BUFSP, and Record Count.
Feb 23, 2014 -NOTE: The number of VSAM records read for any one
Feb 24, 2014 particular RMF Monitor III data set will usually exceed
Feb 26, 2014 the number of records in the file. This is because a
physical record may contain data from more than one
MINTIME interval and data is processed one MINTIME
interval at a time.
-NOTE: The BUFNO and BUFSP values for all RMF Monitor III
data sets will be the same because they share a common
VSAM LSR buffer pool.
-Data set and DCB information will now also be shown for
the non-VSAM SYSPRINT DD file.
-BUFNO=20 was always assigned for the SYSIN DD file.
However, when the SYSIN DD file is blocked this wastes
memory because usually this file has few records. When a
blocked SYSIN file is detected a value of BUFNO=2 will be
assigned.
-When NOxxx table filtering options were mixed with xxx
table selection options, ASMRMFV incorrectly turned on
selection for all tables when the first xxx table option
was encountered.
-The NONE option to suppress all output is now obsolete.
This option was inflexible; it did not allow RMF Monitor
III table selection and/or filtering. Results were also
incomplete as no output statistics were shown. So it
was not very useful nor was its usage easily understood.
If NONE (or any of its aliases) is coded it is ignored
with no action taken and no error messages issued.
-The alternative to the defunct NONE option to preview
what might be output by ASMRMFV with user specified
selections and/or filters in effect is to simply code
in JCL:
//RMFBSAM DD DUMMY
or
//RMFBSAM DD DSN=NULLFILE
Either tells the access method to suppress the RMFBSAM
output. In either case RMFBSAM will be empty and cannot
be used for a PDB build.
-The CLRMFV Clist used in the TSO Clist Method for
running ASMRMFV has been upgraded to accept NULLFILE
as a value for the OUTHLQ Clist parameter.
When OUTHLQ('NULLFILE') is coded the RMFBSAM file will be
allocated as DSN=NULLFILE thus also providing an
alternative to the obsolete ASMRMFV NONE option.
OUTHLQ('DUMMY') can also be used.
In this case the SPACE Clist parameter is forced
to zero and the OUTMLQ and OUTLLQ Clist parameter
settings are irrelevant.
-With RMFBSAM output suppression the result is useful
to determine how many bytes of output will be generated
with the selection and/or filter options used. Also
decisions can be made as to which tables should be
selected for a future PDB build based on data volume.
Then the actual RMFBSAM file can be realistically sized
later for allocation. Be sure to review ASMRMFV messages
RMFV105I to study the output data statistics including
bytes output.
-JCLRMFV, JCLDRMFV, and JCLCRMFV example members are
each updated to include an example with RMFBSAM output
suppression.
-The DOCLRMFV documentation for CLRMFV Clist usage has
been updated with current information.
-Documentation in the ASMRMFV source prologue and in
the ADOCRMFV member has been updated to note that
the NONE parameter is obsolete and to explain the
alternative use of DSN=NULLFILE for RMFBSAM.
-Removed residual extraneous characters in the first
RMFV002I message when no PARM= field existed in JCL.
-NOTE: The ASMRMFV SIZE parameter is still supported and
also produces no RMFBSAM output regardless of JCL for
that file. When SIZE is coded all selection and/or
filtering parameters are ignored. SIZE shows a
snapshot of RMF Monitor III VSAM file allocations as
well as space and index usage.
-NOTE: If the ALL table select ASMRMFV option is coded it
overrides any other table select or table filter options
that may be present regardless of input order.
This is a new behavior with this change. Prior to this
change NOxxx table filter options would override the
coded 'ALL' value. This is no longer the case.
Please do not code 'ALL' when using NOxxx table filter
options to avoid unintended results.
-NOTE: If an xxx table select and an NOxxx table filter
are coded for the same RMF III table the table select
option for this table now always overrides the filter
option regardless of input order.
This is a new behavior with this change. Prior to this
change the last option encountered for the same table
would be effective. This is no longer the case.
Please do not select and filter on the same RMF Monitor
III table in the same ASMRMFV run to avoid unintended
results.
-REQUIREMENT: In order to implement this fix the current
ASMRMFV utility program from this MXG change must be
installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Thanks to H. Sterling James, DST Systems Inc.
Change 32.036 MXG developer utility used when creating a new dataset to
UTILNODU determine the sufficient list of variables needed in the
Feb 21, 2014 new _Bdddddd By List macro that will remove duplicate
observations with the PROC SORT NODUP option (invoked in
BUILDPDB, or the TYPSxxxx "sorting" types, or by the use
of the _Sdddddd dataset sort macro.)
The initial "logical" _Bdddddd is created based on what
seems to be useful order (e.g. READTIME JOB JESNR for a
job related dataset). Then, the input data file is read
twice, the dataset is created and sorted by _Bdddddd, and
then the count of observations deleted as duplicate in
the PROC SORT log messages must be exactly one-half of
the observations read by the sort. If that is not true,
an ad hoc approach was used to find the additional vars
needed. This utility sorts the dataset twice, once with
the original _Bdddddd and a second time with BY _ALL_,
and the unmatched observations, those NOT deleted, are
printed for easy identification of needed variables.
Unlikely an MXG user will ever need this, but someday
someone will be happy to find it if that is their task.
Change 32.035 Websphere ID=120 Subtype=9 datasets TYP1209C, TYP1209E
VMAC120 TYP1209S and TYP1209U had incorrect BY variable that
Feb 18, 2014 did not remove duplicates and caused DELTA120TM to be
always missing. Variables SM1209CR SM1209CS and SM1209CM
are added to those datasets, and the new sort order are:
MACRO _BT1209C
SYSTEM SMFTIME SM1209CR SM1209CS SM1209CY
SM1209EM SM1209CM %
MACRO _BT1209E
SYSTEM SM1209CR SM1209CS SM1209CH SM1209CM %
MACRO _BT1209S
SYSTEM SMFTIME SM1209CR SM1209CS SM1209CY
SM1209EQ SM1209CM %
MACRO _BT1209U
SYSTEM SMFTIME SM1209CR SM1209CS SM1209EY
SM1209FA SM1209CM %
Thanks to Wayne Bell, UNIGROUP, USA.
Change 32.034 These examples could have failed with SYSTEM 413-18 ABEND
JCLUOWP because the CICSTRAN DD was being opened for read by
JCLUOWV VMXGUOWC before the CICSTRAN had been written. Relocated
Feb 17, 2014 the %INCLUDE of VMXGUOW to correct.
Change 32.033 Support for XPTR 5.2 creates these 23 new datasets:
EXXPTR23 dddddd dataset description
EXXPTR24 XPTR23 XPTR23 X/TND USER DISCONNECT
EXXPTR25 XPTR24 XPTR24 X/NET COMMAND PROCESSED
EXXPTR26 XPTR25 XPTR25 API TRANSACTION
EXXPTR33 XPTR26 XPTR26 API SUMMARY
EXXPTR34 XPTR33 XPTR33 MIGRATION DETAIL
EXXPTR52 XPTR34 XPTR34 STORAGE POLICY TARGETS
EXXPT104 XPTR52 XPTR52 USER REQUEST TRACKING
EXXPT106 XPT104 XPTR104 JOB ACCUMULATION
EXXPT107 XPT106 XPTR106 JOB ACCUMULATION WITH RENAME
EXXPT109 XPT107 XPTR107 ARCHIVE CREATED
EXXPT112 XPT109 XPTR109 REPORT ACCUMULATION
EXXPT113 XPT112 XPTR112 REPORT BROWSE
EXXPT118 XPT113 XPTR113 USER COMMAND
EXXPT120 XPT118 XPTR118 X/PTR DETAIL OUTPUT RECORD
EXXPT124 XPT120 XPTR120 NEW REPORT
EXXPT130 XPT124 XPTR124 XNET COMMAND PROCESSED
EXXPT131 XPT130 XPTR130 ARCHIVAL RETRIEVAL COMPLETED
EXXPT132 XPT131 XPTR131 ARCHICE DETAIL
EXXPT133 XPT132 XPTR132 TEST FILE SPACE RELEASE
EXXPT140 XPT133 XPTR133 MIGRATION DETAIL
EXXPT152 XPT140 XPTR140 VSAM BUFFER STATISTICS
EXXPT153 XPT152 XPTR152 USER REQUEST TRACKING
IMACXPTR XPT153 XPTR153 REPORT VERSION DELETE
VMACXPTR -Some minor issues: there are duplicate records
VMXGINIT written for subtype 41 and 50, and the date of the
Feb 21, 2014 SUBMTIME in subtype 130 is 2005.
-BY lists for earlier datasets have been updated and
all datasets with data have been "NODUP" validated.
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 32.032 -DB2STATS variable QISTWMQM was always zero because it was
VMACDB2 incorrectly deaccumulated when it's a static ZPARM value.
VMAC102 -T102S371 variables QW0371CL and QW0371DA were 1000000 too
Feb 18, 2014 large, as the input was &PIB.8. instead of &PIB.8.6.
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 32.031 RMF TYPE748 ESS Subtype 8 datasets completely revised.
EXTY748I -The existing TYPE748 dataset had an observation for every
EXTY748L LINK, instead of just one observation per CUSERIAL. R748L
EXTY748P variables are moved to the new TYPE748L Link dataset.
IMAC74 IBM print 12 digits for CUSERIAL on RMF reports, but that
VMAC74 field is only 10 characters in the subtype 8 record, so
VMXGINIT match on CUSERIAL failed. Extra 00 characters added.
Feb 14, 2014 -The new TYPE748L Link dataset is created with one obs per
Feb 17, 2014 CUSERIAL and R748LAID Link Adapter ID.
-The TYPE748R RANK dataset and TYPE74A RANK ARRAY dataset
are now merged by CUSERIAL R748RRID (Rank Raid ID) to
create the new PDB.TYPE748I "ID" dataset with R748rXID
(Extent Pool) for the detail ESS RANK STATISTICS report.
Unfortunately, the Raid Rank Level can NOT be mapped back
to the logical VOLSER of the I/O.
-In addition, _STY748I also sums the TYPE748I dataset by
CUSERIAL R748XPID to create the Extent Pool Sums in the
new PDB.TYPE748P "EXTENT POOL" dataset.
-Dataset TYPE748X is unchanged.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 32.030 -ASMRMFV execution could fail with RMFV035S >>>>SEVERE
ASMRMFV 1 RED TABLES SKIPPED DUE TO INVALID ID OR FLAG error
Feb 13, 2014 and the program could loop due to an outdated branch in
the DETAIL subroutine when one or more RMF III table
errors were found. The errors detection was valid but
the recover and notification looped.
-REQUIREMENT: In order to implement this fix the
current ASMRMFV utility program from this MXG change
must be installed. See MXG SOURCLIB member JCLASM3 for
sample JCL for the assembly and link-edit install steps.
Thanks to Andre Gustavo Moretto, IBM Global Services, BRAZIL.
Change 32.029 -VMXGPRAL print utility ERROR 72-322: Expecting a ). after
VMXGPRAL a DATA _NULL_ step highlighting this statement:
Feb 12, 2014 SYMPUT("OBS&I",PUT(NOBS,12.); that's missing the paren.
-COMPBL HAS TOO MANY ARGUMENTS if the DATASET LABEL that
is now printed with the DATASET name has a comma. The
commas are removed in VMXGPRAL to circumvent, but See
Change 32.005 - commas to be removed with DATASET LABELs
added to that planned list.
Thanks to Paul Volpi, UHC, USA.
Change 32.028 Protection for BETA93 truncated SUBTYPE=51 record that
VMACBETA caused INPUT STATEMENT EXCEEDED because LOCFIELD+BETAFLEN
Feb 10, 2014 (offset plus length) exceeded the record length. In this
specific record, there were two valid segments that were
output but the third segment was truncated so only the
first two segments were output.
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 32.027 MXG 32.01. INVALID DB2 10.1 HEADER RECORDS, DELETED,
VMACDB2H if the DB2 APAR PM62481, a 2012 APAR that added the
Feb 11, 2014 QWHSAACE field to the QWHSTYP=2 Header Segment, is NOT
installed, because when Change 32.002 INPUT that field,
it was not from the APAR, but last month when I saw that
it was in DSNDQWAC for DB2 V10 and had been overlooked,
and I assumed it was always present by testing for the
QWHSRELN GE 10.2, and ran the MXG DB2 QA with 15 site's
data and no errors. Today, two sites, Australian and
USA, reported the error message and sent data with
QWHSLEN=156, instead of the 164 byte expected with the
field present.
-May 2014: This MXG 30.01 ERROR MESSAGE (yes 30.01!!):
**VMACDB2.ERROR. INVALID IBM TYPE 101 RECORD DETECTED.
YOU MUST INSTALL IBM APARS PN56441 AND PN63234....
was also corrected with this updated VMACDB2H.
(Those APARs were from 1994!).
-MXG input logic was revised to use actual segment lengths
and not the version number to detect the existence, which
then required the creation of QWHCEXTRA with the count of
bytes added for the "truncated" name fields, so it could
be subtracted from QWHSLEN to get the actual length of
the base segment to know for certain if QWHSAACE exists.
With this much time and effort to diagnose and resolve,
at least the new QWHCAACE field may be worth it:
QWHCAACE is zero if the IFCID is written outside of an
accounting interval. Otherwise it will contain a value
that can be correlated to QWHSACE in the IFCID3/DB2ACCT
accounting record. For DDF/RRSAF rollup accounting
records, QWHCAACE should be correlated to QWARACE as the
record will represent multiple transactions. For
parallel tasks, QWHCAACE will point to the ACE of the
parent task.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 32.026 TRNDRMFI could fail if all possible 114 workloads were
VGETWKLD defined in your RMFINTRV dataset, because the limit of
VMXGRMFI 64K bytes of text for a macro variable was exceeded.
VMXGSUM Each of these potentially-large macro variables are now
Feb 7, 2014 created by writing text to FILE INSTREAM as old-style
Feb 10, 2014 macros so the macro variable only contains the old-style
Feb 18, 2014 name; see Change 31.288. Additional macro logic also
reduced size of some other macro variables, and to also
circumvent the 262-byte limit between quotes.
-VMXGSUM was also revised to minimize the size of macro
variables it creates, by calling SYSFUNC to invoke COMPBL
to remove duplicate blanks, but because the argument can
be blank, causing a TOO FEW ARGUMENTS FOR COMPBL error,
%LET ALLVARS=%SYSFUNC(COMPBL(%STR(&ALLVARS &MIN)));
was needed to avoid that (harmless) error message.
-VGETWKLD: the lists in WORKLOAD, NEWLABL, STRING are now
TRIMed before APPEND to reduce text length, and protect
for blank labels added.
====== Changes thru 32.025 were in MXG 32.01 dated Feb 6, 2014=========
Change 32.025 CPUCRPTM, CPU TCB+SRB during CHRONIC CONTENTION was wrong
VMAC30 as the second multiply by 1024 was incorrect. Fortunately
Feb 6, 2014 this is a standalone CPU metric added in Version 26 that
has obviously not been examined previously!
Thanks to Leonard Jejer, MorganStanley, USA.
Change 32.024 RMFINTRV created with a large number of workloads could
VGETWKLD cause TRNDRMFI to fail because the wrong dataset was
Feb 6, 2014 SORTED. PROC SORT DATA=WORKLOADS corrected this error.
Thanks to Wayne Bell, UNIGROUP, USA.
Change 32.023 Support for IMS LOG Record 06 creates IMS06 dataset, to
ASMIMSL6 track IMS startup/shutdown/other conditions.
EXIMS06
FORMATS
IMACIMS
VMACIMS
VMACIMSA
VMXGINIT
Feb 5, 2014
Thanks to Rosa Maria Martinez Alonso, Bustia, SPAIN.
Change 32.022 Support for CA XCOM Version 11.6 INCOMPATIBLY changed the
VMACXCOM SMF record. This updated VMACXCOM supports both 11.6 and
Feb 5, 2014 11.1, transparently.
Thanks to Claudio Zanon, Phoenix, ITALY.
Change 32.021 Change 31.285 was removed. The FILENAME INSTREAM added
VMXGINIT in VMXGINIT, to eliminate the need for //INSTREAM, fails
Feb 4, 2014 if you used it, for example, to write date macros in one
job and then use %INCLUDE INSTREAM in all your report
jobs to instantiate that code, a quite reasonable thing
to do. Unfortunately, the FILENAME INSTREAM CATALOG fails
on the %INCLUDE because it was never opened for output so
it doesn't exist, and using FILENAME INSTREAM TEMP also
fails, but without error: the TEMP is included instead of
the //INSTREAM DD that you wanted to %INCLUDE.
Thus an INSTREAM DD/FILENAME is still be required by MXG.
Another symptom of the need for the new VMXGINIT are
these log messages:
ERROR: CATALOG WORK.MXGTEMP DOES NOT EXIST.
ERROR: CANNOT OPEN %INCLUDE FILE INSTREAM.
Thanks to Arylon Brooks, Verizon Wireless, USA.
Thanks to Nick Bubica, Verizon Wireless, USA.
Thanks to Stephen K. Simon, Verizon Wireless, USA.
Change 32.020 MIPFACTR set to a null string and logic was inserted to
GRAFWRKX base the MSU to MIPS factor on the CPCFNAME variable so
Feb 1, 2014 that GRAFWRKX will automatically reflect the MIPS on the
current machine. The MSU chart reflects MSU consumed
during the period and the MIP chart reflects the MIPS
of capacity consumed during the period. MIPFACTOR can
be overridden with a value of your choice. The values
used by default are:
2097 - 6.5 2098 - 6.5 2817 - 8
2818 - 8 2827 - 8 2828 - 8
Change 32.019 -READDB2 did not always use LDB2ddd override, and &PDBOUT
ANALDB2R option logic was restructured with better documented
ANALDBTR possible values: UNIQUE, YES, PDB/XXXX, NULL/WORK.
ANALTURN Now, WANTONLY will be honored when specified for ACCTs.
READDB2 -Fixing READDB2 uncovered an error in ANALDB2R where the
Feb 4, 2013 datasets were created in PDB, but report expected data
in WORK.
-ANALDBTR. Restructured and revised and corrected, mostly
preventing spurious "THE STRING" messages that only were
printed when there were multiple ANALDBTR invocations
(e.g., when ALL POSSIBLE reports are executed).
-ANALDB2R. Similar restructure and cleanup with heavy
testing with ALL reports and with DATA for all reports.
-ANALDB2R. Reports IOS SQL LOK TRN may not be correct with
PDB=SMF,PDBOUT=WORK (or no PDBOUT=) but they are fine if
PDB=SMF,PDBOUT=PDB (or any XXX DDNAME). I may choose to
leave it this way for these extremely detailed and seldom
used reports, since the repair would be VERY tedious and
there's no cost to using PDBOUT= PDB with PDB temporary.
-ANALDB2R. Requirement for PDBOUT=PDB to be specified for
PMTRC01 Trace Report was never documented but now is no
longer required with revision of the READDB2 logic to set
the output destination for the T102Snnn based on PDBOUT.
-UNRELATED, BUT: CAUTION FOR THE USE OF DATASET VIEWS:
Discovered in QA test when ANALTURN created WORK.STATS
that was left in WORK, and then 30 steps later, ANALDB2R
failed when it tried to create WORK.STATS/VIEW: you CAN
NOT create a dataset view named X if there already is a
dataset named X. This has NOT been an actual problem at
customer sites, but MXG View names are not documented and
you could create an accidental conflict in your programs
that only shows up when you subsequently execute MXG code
that happens to use that dataset name. Fortunately the
error message text makes it clear what dataset name YOU
have to change in YOUR code.
ANALTURN now deletes WORK.STATS.
Change 32.018 Unused Change Number.
Change 32.017 A mislocated RUN; statement cause VMXGPRNT and VMXGPRAL
VMXGPRNT to fail with a 180 syntax error pointing to LABEL.
Jan 29, 2014
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Change 32.016 DB2 Netezza variable Q8STNAME, Accelerator Server ID, was
VMACDB2 not kept in PDB.DB2STATS dataset; its offset was read in
Jan 29, 2014 but then the field was never input.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 32.015 Cosmetic. Variable ACTHNODE was set to blank or 'Y' but
VMACBVIR it incorrectly was formatted $HEX2. so the 'Y' printed as
Jan 29, 2014 'E8'X. Now the Y will be printed as a Y.
Thanks to Keith McWhorter, IBM Global Technology Services, USA.
Change 32.014 Variable CPUUOWTM incorrectly (now) included DB2TCBTM, as
VMXGUOW that WAS correct back when VMXGUOW was written, but that
Jan 29, 2014 changed in CICS/TS 3.2 with the OTE Environment when the
DB2TCBTM was added into the TASCPUTM in CICSTRAN, so the
equation is now CPUUOWTM=SUM(CPUTM,CPUMQMTM);
Thanks to Rick Southby, Insurance Australia Group, AUSTRALIA.
Change 32.013 Create $PLOTCHAR to map one character from SYSTEM name to
VMXGPLCH be used as the "Z-AXIS", the third position variable, in
Jan 28, 2014 PLOT statements so each point is identified to SYSTEM.
%VMXGPLCH(DATASET=PDB.YOURS,VARIABLE=SYSTEM,POSITION=4);
RUN;
PROC PLOT DATA=PDB.YOURS;
PLOT X*Y=SYSTEM;
FORMAT SYSTEM $PLOTCHAR.; <== add in your report code
RUN;
An example in comments shows how to store the formatted
value back into SYSTEM, so that your existing reports do
not need to have that FORMAT statement inserted.
Thanks to Sam Bass, McLane Co., USA.
Change 32.012 Many new spurious MXGWARN: DATASET xxx.yyy DOES NOT EXIST
VGETOBS messages (BUILDPDB for ALL of the PDB.CICxx statistics
Jan 28, 2014 datasets read to create CICINTRV, i.e. where VMXGWORL
calls VGETOBS first for PDB and then for WORK to find the
"_L" or "_W" location) are printed after Change 31.180,
because VGETOBS did not test for NOEXIMSG=YES in line 282
causing the unwanted warning to be printed. Now correct.
Thanks to Carol Arnold, Brown Brothers Harriman & Co, USA.
Change 32.011 MXG 31.31-31.06. USER ABEND 1950 CICSTRAN DOES NOT EXIST
ASUMUOWT because the ASUMUOWT (UOW TMON MONITASK vs CICSTRAN) did
Jan 28, 2014 not null the default _LCICTRN DDNAME value of CICSTRAN
before it called VMXGUOW. Previously, when VMXGUOW then
called VGETOBS to test for the existence of the CICSTRAN
libname, there was only a warning message, and as it was
never actually referenced, PDB.ASUMUOWT was created fine.
In Change 31.180, VGETOBS was changed to USER ABEND 1950
so that you cannot overlook it, when you ask MXG to use
a non-existent LIBNAME.
The correction in ASUMUOWT: add MACRO _LCICTRN _NULL_ ;
in the existing %LET MACKEEP= redefinitions, but you can
circumvent for ASUMUOWT just by adding a temp //CICSTRAN.
This was missed in my QA because all ASUMUOWT tests just
happened to also have a CICSTRAN LIBNAME allocated.
Thanks to Frank Lund, EVRY AS, NORWAY.
Change 32.010 IBM APAR OA43921/OA44049 cause MXGTMNT ABEND 0E0 RC28.
ASMTAPEE This is ML-52 level MXG Tape Mount Monitor. With those
Jan 28, 2014 APARs, on a z/OS 1.13 system, after return from MCSOPMSG,
Master Console Service, register AR15 returns non-zero,
not previously observed, nor expected, nor protected, but
because MXGTMNT is in AR mode, it fails with ABEND 0E0.
MXGTMNT Starts and Shutdown with these messages:
IEA630I OPERATOR MXGC0004 NOW ACTIVE, SYSTEM=SYSX,
LU=MXGTMNT
MXGC009E Unrecoverable error in Allocation Recovery
Monitor, function is terminated.
MXGC008E Recoverable abend limit reached, monitor
extension subtask is terminated.
IEA630I OPERATOR MXGC0004 NOW INACTIVE,SYSTEM=SYSX,
Register AR15 is now cleared in ML-52, now that we know
we need to!
Thanks to Warren Cravey, Fidelity Institutional, USA.
Thanks to Chuck Laurent, Fidelity Institutional, USA.
Change 32.009 -RMF III Enhancements, Fixes, and Notes
ASMRMFV -FROMDATE=/TODATE= and FROMTIME=/TOTIME= date and time
ADOCRMFV selection parameters now have better error detection
Feb 2,2014 and diagnostics. Error messages include more detail
about what the specific error was.
-FROMDATE=/TODATE= now support Gregorian style dates in
the format of FROMDATE= or TODATE= ddmmmyyyy where dd is
the day of the month, mmm is a 3 character month name,
and yyyy is a 4 digit year.
-Also supported are the following Gregorian style date
formats for usability and flexibility: ddmmmyyy, ddmmmyy,
ddmmmy, ddmmm, and mmm
-For yyy, yy, and y years 2000 is added to create the
year. When no year is present the current year is used.
When no day of the month is present the first day of the
month is used. mmm must always be present and cannot
further be shortened.
-Also supported are the following Gregorian style date
formats so that a leading dd day of month zero is not
required for days 1-9 of a month: dmmmyyyy, dmmmyyy,
dmmmyy, dmmmy, and dmmm.
-NOTE: Gregorian style dates are validated so that the dd
value does not exceed the number of possible days in the
month. 29FEB is only allowed for leap years.
-NOTE: Similar to Julian style dates, YYYY366 is also
only allowed for leap years.
-NOTE: ASMRMFV supports dates from 2000.001 January 1,
2000 through and including 2042.259 September 16, 2042.
Dates outside this range will be flagged as errors.
-NOTE: On 2042.260 September 17, 2042 the 8 byte TOD clock
will wrap just after 22:53:47.370495 as all bits will be
X'FF'. If RMF Monitor III still exists at that time, IBM
will need to use the Extended TOD clock or some other
mechanism for time stamps in this data.
-Generic values for FROMDATE= and TODATE= such as
YESTERDAY and TODAY may now be shortened to as few
characters as desired even down to the single characters
Y and T. Before the full length had to always be used
which was cumbersome.
-Processing routines for FROMDATE= and TODATE= are
combined into a single routine for better efficiency as
are the routines from FROMTIME= and TOTIME=.
-A second RMFV041I message is now displayed for each found
VSAM data set when using the Dynamic Method. It includes
the VSAM data set type, volume serial, average and
maximum LRECL, Control Interval size, and Creation Date.
This is intended to allow better identification that the
correct RMF Monitor III VSAM data sets have been pattern
selected by this method.
-When message RMFV002I is displayed showing the JCL PARM=
field contents, the length of the PARM field is now
displayed. There is a z/OS limit of 100 characters for
the PARM= field. If you are nearing this limit consider
using the SYSIN DD file instead of or in addition to the
PARM= field.
-When execution environment messages RMFV001I are
displayed, there is now an additional message showing the
last IPL date, time, and IPL volume serial.
-Parameter end processing was not validating that the
FROMDATE= value did not exceed the TODATE= value when
other errors had previously been detected.
-Parameter end processing was not validating that the
FROMTIME= value did not exceed the TOTIME= value when the
same day had been selected and other errors had
previously been detected.
-Documentation in the ASMRMFV source prologue and in the
ADOCRMFV member has been updated to discuss the new
Gregorian style formats for FROMDATE= and TODATE=. More
examples are added also.
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change must
be installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps
Change 32.008 Cosmetic. The text in the file created by UTILBLDP that
UTILBLDP identifies the last change still had Change 30.115 after
Jan 27, 2014 Change 31.276. A new QA test compares the text with the
LAST UPDATED information in line 2 to detect mismatch.
Thanks to Clayton Buck, UNIGROUP, USA.
Change 32.007 MXG 31.31. SMF ID=111 INPUT STATEMENT EXCEEDED LENGTH,
VMAC111 because line 659 should be SKIP=SKIP-16; instead of -8.
Jan 27, 2014
Thanks to Flemming Bramsen, SEMLER, DENMARK.
Change 32.006 -PDB.TAPES/PDB.ASUMTAPE variable BYTEWRIT for 3590 tapes
VMAC21 could still be too small, after Change 31.244, when more
Jan 26, 2014 than 64GB uncompressed bytes were written, i.e., when the
count of 4K blocks written exceeds the 3-byte 'FFFFFF'x
maximum in SMF21BW. When SMF21BW overflowed, MXG used
the compressed count in SMF21DBW when the uncompressed
count in SMF21DBW should have been stored instead.
The error can only impact DEVICE='3590'. So far, only
SMF21BW has exceeded 64GB, but the error would also be in
BYTEREAD if SMF21BR had overflowed.
-Variables SMF21BWN & SMF21BRN are now kept in PDB.TAPES.
Thanks to Yves Cinq-Mars, IBM Global Services, CANADA.
Change 32.005 -Support for ID=90 Subtype=35 SETLOAD XX IEASYM Command
FORMATS record, overlooked because it is not listed in subtypes
VMAC90A on page 734, and the documentation text was located after
EXTY9035 Subtype 33 instead of after Subtype 34 (and before 36).
VMXGINIT -Discovered when updating the ANALID $MGSMFID format to
Jan 25, 2013 describe SMF record IDs 38, 85, 90, and 118 for ANALID.
-All MXG FORMAT'S VALUES ARE NOW COMMA-FREE, for ease in
exporting SAS datasets with formatted variables to EXCEL,
since commas can't exist in CSV Comma Delimited files,
and blanks read just as well where there were commas.
-While far less likely to be exported, over time, I will
also replace all commas in the LABELs of MXG variables.
Change 32.004 Cosmetic. "Destructive" added to these variable's label:
VMAC116 WQGETA ='MQGET*DESTRUCTIVE*(ANY)
Jan 23, 2014 WQGETS ='MQGET*DESTRUCTIVE*(SPECIFIC)'
Thanks to Pietro Rosella, Canadian National, CANADA
Change 32.003 OUTDATA= parameter added should you wish to preserve the
ANALCOMP output dataset created by ANALCOMP.
Jan 22, 2014
Change 32.002 -Support DB2 QWHC Header variable QWHCAACE Initiator ACE,
VMACDB2H added in DB2 V10 is now INPUT but only right four bytes
Jan 22, 2014 are input, as all other ACE fields are 4-bytes and data
shows those are the populated bytes. Kept in all DB2 data
sets that currently have QWHSACE from the QWHS header.
Logic to detect that QWHCAACE is present require revision
because records with only QWHCAACE are created, although
the DB2 QWHC DSEC documents that both QWHCAACE and the
two 2-byte offsets for EUTX/EUWN were added.
-DB2 V10 increased QWHCEUTX Users Transaction Name length
from $32 to $128 and QWHCEUWN Users Workstation length
from $18 to $128, in two relocated "Truncated" segments.
Change 32.001 -NTSMF objects TCPV4 and TCPV6 were INCORRECTLY output in
VMACNTSM dataset TCP versus the correct TCPV4 and TCPV6 datasets,
Jan 21, 2014 causing apparent duplicate observations in TCP dataset,
Jan 25, 2014 because the OBJECT=:'TCP' test should have been changed
to be OBJECT=:'TCP ' when the new TCPV4 and TCPV5 objects
were supported (or the test for those longer object names
should have preceded the shorter name.)
-WEB SERVICE CACHE object, dataset WEBSRVCA new variables:
WBSCOUMU WBSCOUCF WBSCOUCH WBSCOUCI WBSCOUFI WBSCOUTF
WBSCOUTH WBSCOUTM
-ASP.NET APPLICATIONS object, dataset ASPNETAP, new vars:
ASPARQBI ASPARQBO ASPARQEX ASPARQFA ASPARQSU ASPARQTO
Thanks to Carl Levy, Boeing, USA.
Thanks to Kenneth R. Jallen, Boeing, USA.
LASTCHANGE: Version 32.
=========================member=CHANGE31================================
/* COPYRIGHT (C) 1984-2014 MERRILL CONSULTANTS DALLAS TEXAS USA */
ANNUAL MXG Version 31.31 is dated Jan 20, 2014, thru Change 31.296
MXG Version 31.09 was dated Dec 30, 2013, thru Change 31.278
MXG Version 31.08 was dated Nov 12, 2013, thru Change 31.244.
First MXG Version 31.08 was dated Nov 12, 2013, thru Change 31.240.
MXG Version 31.07 was dated Sep 20, 2013, thru Change 31.204.
MXG Version 31.06 was dated Sep 3, 2013, thru Change 31.187.
First MXG Version 31.06 was dated Sep 1, 2013, thru Change 31.184.
MXG Newsletter SIXTY-TWO was dated Sep 1, 2013.
MXG Version 31.05 was dated Jul 29, 2013, thru Change 31.156.
MXG Version 31.04 was dated Jun 26, 2013, thru Change 31.125.
MXG Version 31.03 was dated Jun 17, 2013, thru Change 31.114.
MXG Version 31.02 was dated May 5, 2013, thru Change 31.088.
First MXG Version 31.02 was dated Apr 29, 2013, thru Change 31.079.
MXG Version 31.01 was dated Mar 13, 2013, thru Change 31.044.
MXG Newsletter SIXTY-ONE was dated Jan 21, 2013.
Annual MXG Version 31.31 is dated Jan 20, 2014, thru Change 30.296.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 31.31 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 31.31.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
========================================================================
I. MXG Version 31.31 dated Jan 20, 2014, thru Change 31.296.
Major enhancement added in MXG 31.31, dated Jan 20, 2014:
TYPE111 31.283 Support for CICS Transaction Gateway V9R0 (COMPAT)
UTILEXCL 31.295 Negative values in variable TASELGTM with IMACEXCL.
VMAC73 31.291 SMF73SPD Channel Speed now always in MBits/sec.
TYPE30 31.280 IOTMNOCA=SMF30AIC-IOTMDASD corrected (was IOTMTOTL).
ASMRMFV 31.296 RMF III Enhancements including new TABERR parameter.
ASMRMFV 31.287 MXG 31.02-31.09. ASMRMFV could skip RCD tables.
MXGLABEL 31.288 New %MXGLABEL creates LABEL with NAME and LABEL.
VMXGINIT 31.285 JCL //INSTREAM DD is no longer required for z/OS MXG.
ANALDB2R 31.286 Selection by PLAN moved into READDB2, saves time.
TYPEDB2 31.282 DB2PM *ROLSUM*,*ROLLUP* both now set DB2PARTY='R'.
JCLUOTT2 31.293 Sample JCL to create PDB.ASUMUOW,CICS with TMON/CICS.
GRAFWRKX 31.294 New NEWMODEL parameter view workloads on new CPU.
FORMATS 31.291 MG073FR decodes SMF73CPP frame size 16/24/50/64KB.
IHDRTMO2 31.290 TMON/CICS TA header exit IHDRTMO2 now after offsets.
Major enhancement added in MXG 31.09, dated Dec 30, 2013:
FORMATS 31.251 WPS FAILS WITH 31.08 FORMATS, PICTURE NOT SUPPORTED.
TYPEBVIR 31.254 BVIR30 dataset was incorrect with VERSION 3 records.
TYPEDB2 31.245 Support for APAR PM90886 new IDAA/NETEZZA ELIGIBLEtm.
TYPE102 31.258 Support for IFCID 359, "DB2 Statement ID" decoded.
TYPE102 31.261 Support for DB2 IFCIDs 370 and 371 (OPEN/CLOSE TRACE)
TYPE102 31.278 Support for DB2 Trace IFCID=733 PSEUDO DELETE CLEANUP
UTILBLDP 31.276 Ad hoc read SMF UTILBLDP is enhanced WANTSMF= list.
TYPERMFV 31.273 Support for RMF III CATG3 Cache Data ERB74CA dataset.
ASMRMFV 31.273 Support for RMF III CATG3 Cache Data ERB74CA dataset.
TYPENMON 31.264 Support for Red Hat Linux Data Group,NFSCLIV4 metrics
TYPEDB2 31.272 Invalid SMF 101 subtype 1 from ASG TMON/DB2 DB2ACCTP.
TYPE30 31.277 TYPE30MU dataset now has zero obs by default: useless
VGETOBS 31.250 A better way to identify TAPE data libraries.
READDB2 31.269 "Too few" IFCIDs listed caused no sort to PDBOUT.
TYPE110 31.253 SMSGDHWM/SMSGCCUR correction for CICS/TS 4.2 or later
TYPEDB2 31.259 Variable QWHSNIDIP=IP*ADDR*FROM*QWHSNID QWHCATYP=8
TYPETPMX 31.263 ERROR.VMACTPMX. VARNAME=$INCLAI or $DBS_SD NOT FOUND.
TYPE7072 31.274 System with only CPs + ICFs, LPAR SHARE weight wrong.
TYPE7072 31.266 MSU Units (Hardware vs Software) in TYPE70/TYPE72GO.
GRAFCEC 31.246 NOT SORTED error with multiple CEC's data.
ANALDB2R 31.262 Some AVG Buff stats wrong, possible dataset not found
ANALHSM 31.260 Variable HSMPLEX added to all HSM reports.
TYPE80A 31.257 TOKDANAM='UTYPE' ERROR if last, new TOK variables.
ANALGRID 31.248 DATES= any one of the "one word" tokens didn't work.
VGETOBS 31.247 ERROR: WORK.MXGTABLES NOT FOUND with earlier VGETOBS.
VMXGRMFI 31.268 Some RMFINTRV xxxxSWAP xxxxTRAN xxxxEXCP un-formatted
TYPEDB2 31.275 MXGWARN: T102S225 DOES NOT EXIST.
Many 31.270 Messages with 'ERROR:' starting in byte one shifted.
Major enhancement added in MXG 31.08, dated Nov 12, 2013:
TYPEDB2 31.240 Support for DB2 V11.1. (MXG 30.30+ TOLERATES with no
EXECUTION error, but the QLST variables in DB2STATS
require MXG 31.04 for both DB2 V10.1 and V11.1.)
ASMRMFV 31.230 RMF III Enhancements: BIG DISK SPACE SAVED in ZRBDVT.
ASMRMFV 31.230 RMF III Support for DSNTYPE=LARGE.
MANY 31.221 ODS Support for TYPE=PDF, MANY ANALxxxx updated
TYPECIMS 31.233 Correction for IMF 4.2 thru 5.1 (WRONG VALUES)
TYPECIMS 31.206 Support for IMF 5.1 (INCOMPAT, but only CIMSDBDS).
TYPEPDM 31.226 Support for Alebra Parallel Data Mover SMF record.
TYPEJESC 31.225 Support for Emtex JESCONNECT SMF Record.
EXCICJRN 31.217 Support for CICS "multi journal records".
TYPETLMS 31.215 Support for new TLMS variables, compression percent
TYPE7002 31.220 Enhancement to CRYPTOGRAPHIC PROCESSOR (70-2) support
VGETOBS 31.212 Final (?) revisions to VGETOBS to bypass tape mounts.
TYPE110 31.214 CICSJS variables SJSMAJCP/SJSMINCP are not CPU time.
TYPE113 31.208 ASUM113 LPARBUSY/MIPSEXEC wrong for zEC12 processor.
TYPE6 31.207 31.07 only. Debugging SMFLN3=162 LENLEFT=552 removed.
TYPE119 31.218 INVALID DATA FOR SCACTIME in ID=110 SUBTYPE=32.
TYPE42 31.216 INVALID DATA FOR S42CSYNC.
ANALATEN 31.205 Analysis of Latent Demand report.
VMXGSRCH 31.219 Search which character variables contain text string.
WPS 31.224 Current status of WPS circumventions and differences.
Major enhancement added in MXG 31.07, dated Sep 20, 2013:
TYPE0 31.193 z/OS 2.1 ID=0 "IPL" RECORD now 68 bytes, MXG DELETES.
(ONLY A PROBLEM IF YOU THINK ID=0 IS AN IPL WHICH IT
often is not - always use the PDB.IPLS BUILDPDB DATA
to report IPL events. See change text.)
The DB2 MXG 31.06 "VGETOBS" enhancements still had some glitches:
ANALDB2R 31.204 ANALDB2R (31.06) with PDB=PDB and PDB on tape fails.
READDB2 31.191 READDB2 PDBOUT=, or PDBOUT=XXX may not work right.
VGETOBS 31.200 Revisions in concert with VMXGWORL for READDB2.
VMXGWORL 31.200 Revisions in concert with VGETOBS for READDB2.
Those VGETOBS changes solved two very different problems:
1. WPS failed when there was no LIBNAME when there was a
WHERE clause on PROC SQL read of DICTIONARY.TABLES.
Solved by looking at DICTIONARY.FILENAMES without a
WHERE first to see if the DD even exists.
2. SAS mounting and rereading every tape with every
execution of VGETOBS reading DICTIONARY.TABLES, even
when there was NO where clause.
Solved by keeping track of tape DDs and excluding
them from DICTIONARY.TABLES searches with a WHERE
CLAUSE NE.
-Solving problem 2 cut tape mounts in daily CICS/DB2 job
at one site from over 90 to less than 20.
TYPEDB2 31.196 Support for DB2 APAR PM67806 adds QW0225DMH DMG GETMs
TYPE115 31.188 Support for MQ SMF 115 ST 2 SMDS/QESD, new TYPE115S.
FORMATS 31.189 Support for CEX41 Crypto Coprocessor type corrected.
JCLVSB2U 31.198 JCL example to change RECFM=VBS to RECFM=U w/o copy.
TYPEVMXA 31.194 MXG 31.02-31.06 BROKEN CONTROL, STOSHD MRHDRLEN=112.
TYPETMMQ 31.190 Many new variables added to TMMQQU MQ QUEUE dataset.
TYPE117 31.199 S17NNDM added to the BY list _B117NOD for NODUP.
TYPEIDMS 31.197 After MXG 30.30, only IDMS 17, zero obs in IDMSINS.
Major enhancement added in MXG 31.06, dated Sep 3, 2013:
TYPERMFV 31.181 RMF III Support for z/OS 2.1 plus Enhancements.
TYPE115 31.179 Support for MQ 7.1.0 SMF 115 subtypes 5, 6, and 7.
TYPE102 31.166 Support for IFCID=380 STORED PROCEDURE DETAILS
TYPEBVIR 31.168 Support of Hydra/BVIR Version 3 new data fields.
TYPEXAM 31.160 Support for Velocity Software new segments new data.
All SMF 31.182 New INPUT SMF FILE DID NOT END WITH ID=3 message.
TYPE113 31.169 SMF 113 vars DWINSORM and DWDASORM wrong for zEC12.
TYPE113 31.169 SMF 113 vars SM1132MT and SM1132MM were blank.
TYPE113 31.172 Macro to re-label SMF 113 counters for old machine
TYPE120 31.170 Variable SM1209BK (Short Server) added TYP1209C/S/U.
TYPESHDE 31.177 SHADOW variable SM01ADCT ADABAS COMMAND COUNT wrong.
TYPEZPRO 31.167A VOLTAGE Release 4.2 segment count circumvention.
READDB2 31.167 DB2 V8 ONLY. V8-only IFCID=225 were not read.
READDB2 31.165 PDB.DB2STAT1 not created with READDB2 STATISTICS.
TYPEBETA 31.162 Variable JOB and BETAJOBN are now consistent.
TYPE7072 31.174 WARNING: MULTIPLE LENGTHS FOR IFAUPTM and Tutorial
TYPENMON 31.164 Protection for invalid NMON DISKxxxx records.
VMXGSRCH 31.171 UNABLE TO CREATE WORK.TABLES.DATA circumvented.
VGETOBS 31.180 Circumvent WPS 3 ABEND with unopened LIBNAME on tape.
READDB2 31.163 WPS 3 ONLY. WPS 3 Compiler macro resolution error.
Major enhancement added in MXG 31.05, dated Jul 23, 2013:
MANY 31.153 Support for z/OS 2.1: COMPATIBLE, VALIDATED WITH DATA
TYPEVMXA 31.151 Support for zVM 6.3 MONWRITE, INCOMPAT due to MXG.
TYPETMD2 31.133 Support for TMON for DB2 Version 5 second iteration.
ASMRMFV 31.150 MAJOR RMF III enhancement - dynamic VSAM allocation.
TYPE70PR 31.140 SMF70GNM, Group Name, blank in MXG 31.03-31.04.
TYPE70 31.130 SHARE Weights for zIIP/zAAPs corrected.
TYPE78CU 31.127 Vars R783DCTM/DDTM (CU Connect/Disconnect) added.
ASUMTAPE 31.149 _GRPMNNM/_GRPMNCD failed after Change 30.203.
TYPERACF 31.146 INPUT STATEMENT ERROR RACF UNLOAD, invalid data too.
TYPE120 31.143 TYP1209E variables SM1209DA-DF are accumulated.
UTILEXCL 31.147 Support for CANPROD4, CANPROD5 and CANPROD6 fields
VMAC80A 31.139 Support for RACF TOKDANAM='UNAME'.
RMFINTRV 31.138 Multi-period RSP/TRN/SWP mislabeled BAT1 vs BATHI.
TYPECIMS 31.137 IMF TRXZxxxx variables incorrectly input.
TYPEWWW 31.137 IIS Log with ' ... ' COOKIE value caused MXG loop.
READDB2 31.128 LDB2*** parameters were not honored.
EXUTILEX 31.131 EXUTILEX is NO LONGER SUPPORTED for UTILEXCL tailor.
Major enhancement added in MXG 31.04, dated Jun 26, 2013:
TYPENMON 31.119 Variables IPCSTIME and TIMEZONE added to NMONBBBP.
TYPEEDGR 31.118 Support for EDGRXEXT variables added in z/OS 1.13
TYPEDB2 31.117 DB2 V10. All QLSTxxxx numerics WRONG (DBSTATR/STATS).
TYPETPMX 31.116 TYPETPMX variable JOBNUM truncated if 6 digits long
READDB2 31.115 READDB2 with COMPRESSED/Internal, NO OBS created.
Major enhancement added in MXG 31.03, dated Jun 17, 2013:
SAS Version 9.4 is COMPLETLY COMPATIBLE with MXG QA tests; no changes
to MXG are required, no errors nor new warnings were observed.
See SAS Technical Note in Newsletter SIXTY-TWO for comparison metrics.
TYPEDB2 31.117 ALL QLSTxxxx VALUES IN DB2 V10 ARE WRONG.
TYPEIMS 31.102 Support for IMS 13, INCOMPATIBLE, DLRAZAAP inserted.
TYPEIMSA 31.102 Support for IMS 13, INCOMPATIBLE, DLRAZAAP inserted.
TYPE110 31.110 CICS/TS 5.1 MNSEGCL=5 file resource INCOMPATIBLE.
ASMTAPEE 31.105 ML-51 corrects MXGC010E error when STKX=NO used.
TYPEDB2 31.093 New "INVALID" DB2 ID=100 ST=5 Startup now Supported.
(and more accurately, "UNDOCUMENTED/UNEXPECTED").
Prior MXG 31.02's could ABEND without this change.
MXG 31.01 and earlier will NOT fail, but will print
1,440 "CALL HOME" messages per subsystem per day.
EXPDBACC 31.094 BUILDPDB enhancement: create your own acct variables.
IMACICUS 31.090 MXG 31.02. LENUSRCH=32 should be LENUSRCH=0 default.
ANALID 31.086 SMF Audit Reports DB2 ACCUMAC ZPARM enabled status.
ASMRMFV 31.111 Further internal enhancements to RMF III support.
Major enhancement added in re-dated MXG 31.02, dated May 5, 2013:
TYPEDB2 31.088 Protection for INVALID ID=100 SUBTYPE=5 DB2 record.
TYPEDB2 31.081 Support for DB2 V10 ID=100 ST=5 IFCID=369 CPU by CONN
New DB2 Statistics record with CPU and Wait Times and
all QBACxxxx variables by Connection Type.
Major enhancements/corrections added in MXG 31.02, dated Apr 29, 2013:
TYPEXDFG 31.049 Support for WAS XD (WebSphere Extended Deployment).
ASMIDMP 31.068 Pace-contributed IDMS exit code for Change 31.018.
JCLSQLID 31.067 Point-in-time mapping DBID/OBID hex to their names.
ANALDB2R 31.067 Point-in-time mapping DBID/OBID hex to their names.
ANALDB2R 31.061 New MXGACC03 report counts concurrent DBATs.
ASMRMFV 31.062 RMF III Enhancements - blocking CPU and CPCDB.
TYPERMRV 31.062 RMF III Enhancements - blocking CPU and CPCDB.
TYPERMFV 31.074 RMF III dataset ZRBLCP var LCPUPOLR/CHIN/CHIX wrong.
TYPE74 31.072 Format MG0748L new value for 16 GB/s Link Type
IMACICUX 31.051 Support for user field CHARGE creates USCHARGE Var.
UTILEXCL 31.051 ***UNKNOWN FIELD*** protection still didn't protect.
IMACCADI 31.060 CA-Dispatch CADIxxxx values corrected.
TYPENMON 31.058 NMON records SEA, SEAPACKET, DONATE are supported.
TYPEDB2 31.056 Variable THREADS now correctly set for ROLLUPs.
TYPEPRPR 31.054 Corrections to '1031' and '1061' records.
TYPEWWW 31.052 IIS Weblog URIQUERY with &=1 and no name supported.
TYPE110 31.048 MXG 31.01 only, STID=29, CICSMDSA dataset wrong.
IMAC6ESS 31.047 ESS GEPARMKY=0039 creates new ESSOPTNS in TYPE6.
TYPE90A 31.045 ID=90.6,7 EVENTIME is IPLTIME of the system.
Major enhancements/corrections added in MXG 31.01, dated Mar 13, 2013:
TYPEVFTP 31.023 Support for Software Diversified Services VFTP SMF.
TYPEVIP 31.022 Support for Software Diversified Services VIP SMF.
TYPESHDW 31.022 Support for Shadow user SMF subtype 21 record.
TYPEBVIR 31.016 Support for BVIR Version 2.0/2.0a/2.1.
TYPETMMQ 31.020 Support for TMON/MQ Version 2.15 new data.
TYPE85 31.006 Support for OAM SMF ID=85 STs 90,91,92 and 93.
TYPEIDMP 31.018 Support for PACE's IDMS 17 KOMAND/IDCS SMF record.
TYPE102 31.001 Support for variable QW0141OT in T102S141 dataset.
TYPENTSM 31.030 Major update for NTSMF adds datasets and variables.
TYPERMFV 31.021 RMF III Enhancements including ASI/ENC blocking.
TYPERMFV 31.004 RMF III, z/OS 1.13 APAR OA38660 ASI data wrong.
VGETWKLD 31.028 Hardcoded VIEWs removed.
TYPE102 31.027 Variable QWHCEUWN added to T102Snnn DB2 datasets.
PREINIT 31.026 Pre-MXG-Initialization exit for SASHELP.VEXTFL.
TYPEDB2 31.015 "Truncated" QPACLOCN/COLN/PKID/ASHC/AANM maybe wrong.
VMACSMF 31.014 New %LET SMFPUTHD=NO; suppresses header messages.
TYPE110 31.012 CICLDR output tests LDRTU instead of LDRFC.
TYPETMNT 31.010 MSGID NOT FOUND for MXGTMNT SYSLOG SUBTYPE 8 record.
ANAL120 31.008 Example WebSphere SMF 120 reports revised.
TYPE113 31.003 Message UNINIT VARIABLE SM1132MM minimal impact.
CICINTRV 31.002 CICTSQ new A12xxxx variables now kept in CICINTRV.
TYPEBVIR 31.039 Option to add SYSTEM value to IBM TS7700 BVIR data.
TYPEBETA 31.036 BETA93 had invalid data in BETA1 for 4.2.0 and 4.3.0.
ANALDB2R 31.034 MXG 30.10-30.30. PMAUD02 caused ERROR keyword parm.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Version 9.4 and SAS 9.4.1 were both tested with NO CHANGES.
JCL in MXGSAS94 or MXGSAS93 can be used, or MXGNAMES can be used
with your existing, installed SAS JCL procedure - see below.
SAS Version 9.3 TS1M1 is RECOMMENDED for all PLATFORMS, because
SAS Version 9.3 TS1M0 REQUIRES THE HOT FIX in SAS NOTE SN43828
(for all platforms), and TS1M1 contains that Hot Fix.
Note: SAS 9.2 is reduced to SAS Level B support Sep 30, 2013.
Note: SAS 9.1.3 is reduced to SAS Level c support Sep 30, 2013.
***************************************************************
As documented in Change 27.356, for SAS V9.2 or later):
The standard SAS JCL Procedure can be used for MXG with SAS V9.2+
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS93 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 31.31 will execute under SAS Version 9.3, on
all supported platforms, but as noted above, you need TS1M1. With
TS1M0, then the Hot Fix in SAS Problem Note SN43828 is REQUIRED to
correct an error in the %MACRO compiler, which is SAS portable
code, so that Hot Fix is required for ALL platforms.
The %MACRO compiler error is in processing %LET statements. While
only two MXG members failed repeatedly in MXG QA tests on z/OS,
there were random %LET errors in ASCII QA tests, so ANY use of
%LET statement on ANY platform are vulnerable to this error, as
the %MACRO compiler is SAS portable code, used on all platforms.
So this is NOT just an MXG error, but impacts ALL SAS programs.
With the Hot Fix on TS1M0, the full MXG QA test stream executed,
and there were no new warnings on z/OS.
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
MXG 26.03 thru MXG 31.31 will execute under SAS V9.4, V9.3, V9.2
or SAS V9.1.3 with Service Pack 4, on all supported SAS platforms.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS/DB2 Decompression Infile Exit.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN platform,
but SAS V9.2 does execute on that platform.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I can not guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3/V9.4, TO AVOID FIXED PROBLEMS!
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG
Version 26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2, V9.3 and
SAS V9.4 are interchangeable and can be read/written by any of
those versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.4 did change some V9.3 ODS processing defaults and syntax
that might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support ODS, and MXG 29.06 is STRONGLY recommended for ODS with
SAS V9.3 or SAS V9.4.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, V9.2, V9.3,
and V9.4. "PDBs" can be read/written interchangeably between
these SAS versions.
MXG Versions 26.03+ do execute with SAS V9.2 with NO WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
GENERAL STATEMENT FOR MXG QA TESTS AND SAS VERSIONS:
MXG QA tests are executed with V9.3 & V9.4, on z/OS, on Windows
Seven (32-bit and 64-bit) and Eight (64-bit) on 64-bit hardware,
and on Centos 6.4, but MXG users execute MXG on MANY (ALL??) SAS
platforms, including AIX, Linux, and other 'nix' variants, on many
different hardware platforms, and since they all work we don't
need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under ALL SUPPORTED SAS VERSIONS on EVERY SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 3.0 requires MXG 31.09 (see Change 31.251).
WPS Version 2.4 required MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for WPS Support Statement.
WPS prints this message ERROR: COULD NOT CREATE DATA SET "PDB.ID"
when the LIBNAME PDB does not exist; there would also have been a
prior log message NOTE: Library PDB does not exist as the clue.
IV. MXG Version Required for Hardware, Operating System Release, etc.
MXG is usually NOT sensitive to z/OS hardware changes. However, MXG
Version 30.07+ was REQUIRED for z/EC12 (for SMF 113, for 95 engines)
and MXG 31.03+ is STRONGLY RECOMMENDED for the z/EC12 processor for
the new zEC12 RMF data metrics added for that new platform.
In August 2013, the MXG-L ListServer was abuzz with several postings
from MXG users and additional references to SHARE papers that all
reported that many z/EC12s are 30%-40% better than zPCR projected.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z/OS 2.1 COMPATIBLE Jul 23, 2013 31.05
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
CICS/CTG V9 Transaction Gateway ?? ?? 2013 31.31
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
CICS-TS V2R1 CICS/TS 2.1 Mar 15, 2001 18.11
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS V2R3 CICS?TS 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 29.05*
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 30.01*
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 30.08*
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 30.30*
CICS-TS/5.1 MNSEGCL=5 INCOMPAT Jun 17, 2013 31.03*
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 New vars + Compressed Nov 1, 2010 28.07*
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 28.28*
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 29.07*
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 30.07*
DB2 10.1 DBID/OBID decode Jan 21, 2013 30.30*
DB2 10.1 QLSTxxxx vars corrected Jun 21, 2013 31.04*
(ONLY IMPACTS DB2STATS)
DB2 11.1 TOLERATE DB2 V11.1 Jun 21, 2013 30.30
DB2 11.1 DB2STATS QLST CORRECT Jun 21, 2013 31.04
DB2 11.1 SUPPORT NEW VARIABLES Jun 21, 2013 31.08
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Websphere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
z/VM 6.3 INCOMPATIBLE Jul 23, 2013 31.05
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
IMS log 11.0 Apr 1, 2010 28.02*
IMS log 12.0 Jan 23, 2012 29.29*
IMS log 13.0 Oct 25, 2013 31.03
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
The Monitor for CICS TCE 3.4 (for CICS/TS 5.1) 30.30
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
The Monitor for MVS/ESA 3.0 - 19.19
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V6R3 SMF 102 30.037
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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 31.08*
IMF 4.5 (for IMS 11.1) (No change since 4.4) 31.08
IMF 4.6 a/k/a Mainview IMS 31.08*
IMF 5.1 a/k/a Mainview IMS 31.08
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
V. Incompatibilities and Installation of MXG 31.31.
1. Incompatibilities introduced in MXG 31.31:
a- Changes in MXG architecture made between 31.31 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
An MXG Version never "expires" nor "goes out of Support". When
you put in a new product/subsystem/Release/APAR that incompatibly
changed its records then you must install the current MXG Version
or at least be using the minimum level of MXG that is currently
documented in the preceding list in section IV.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 31.31 after MXG 30.30:
Dataset/
Member Change Description
ANAL120 31.008 Example reports revised.
ANALATEN 31.205 Analysis of Latent Demand report.
ANALDB2R 31.034 MXG 30.10-30.30. PMAUD02 caused ERROR keyword parm.
ANALDB2R 31.061 New MXGACC03 report counts concurrent DBATs.
ANALDB2R 31.067 Point-in-time mapping DBID/OBID hex to their names.
ANALDB2R 31.262 Some AVG Buff stats wrong, possible dataset not found
ANALDB2R 31.286 Selection by PLAN moved into READDB2, saves time.
ANALGRID 31.248 DATES= any one of the "one word" tokens didn't work.
ANALHSM 31.260 Variable HSMPLEX added to all HSM reports.
ANALID 31.086 SMF Audit Reports DB2 ACCUMAC ZPARM enabled status.
ASMIDMP 31.068 Pace-contributed IDMS exit code for Change 31.018.
ASMRMFV 31.062 RMF III Enhancements - blocking CPU and CPCDB.
ASMRMFV 31.111 Blocking SVP tables over 32K length enhancement.
ASMRMFV 31.150 MAJOR RMF III enhancement - dynamic VSAM allocation.
ASMRMFV 31.230 RMF III Enhancements: BIG DISK SPACE SAVED in ZRBDVT.
ASMRMFV 31.273 Support for RMF III CATG3 Cache Data ERB74CA dataset.
ASMRMFV 31.287 MXG 31.02-31.09. ASMRMFV could skip RCD tables.
ASMRMFV 31.296 RMF III Enhancements including new TABERR parameter.
ASMTAPEE 31.105 ML-51 corrects MXGC010E error when STKX=NO used.
ASUMSMFI 31.073 Variable TYPETASK added to ASUMSMFI summary dataset.
ASUMTAPE 31.149 _GRPMNNM/_GRPMNCD failed after Change 30.203.
CICINTRV 31.002 CICTSQ new A12xxxx variables now kept in CICINTRV.
EXCICJRN 31.217 Support for CICS "multi journal records".
EXPDBACC 31.094 BUILDPDB enhancement: create your own acct variables.
EXUTILEX 31.131 EXUTILEX is NO LONGER SUPPORTED for UTILEXCL tailor.
FORMATS 31.189 Support for CEX41 Crypto Coprocessor type corrected.
FORMATS 31.251 WPS FAILS WITH 31.08 FORMATS, PICTURE NOT SUPPORTED.
FORMATS 31.291 MG073FR decodes SMF73CPP frame size 16/24/50/64KB.
GRAFCEC 31.246 NOT SORTED error with multiple CEC's data.
GRAFWRKX 31.294 New NEWMODEL parameter view workloads on new CPU.
IHDRTMO2 31.290 TMON/CICS TA records IHDRTMO2 now after the offsets.
IMAC6ESS 31.047 ESS GEPARMKY=0039 creates new ESSOPTNS in TYPE6.
IMACCADI 31.060 CA-Dispatch CADIxxxx values corrected.
IMACICUS 31.090 MXG 31.02. LENUSRCH=32 should be LENUSRCH=0 default.
IMACICUX 31.051 Support for user field CHARGE creates USCHARGE Var.
JCLSQLID 31.067 Point-in-time mapping DBID/OBID hex to their names.
JCLUOTT2 31.293 Sample JCL to create PDB.ASUMUOW,CICS with TMON/CICS.
JCLVSB2U 31.198 JCL example to change RECFM=VBS to RECFM=U w/o copy.
MANY 31.221 ODS Support for TYPE=PDF, MANY ANALxxxx updated
MXGLABEL 31.288 New %MXGLABEL creates LABEL with NAME and LABEL.
Many 31.270 Messages with 'ERROR:' starting in byte one shifted.
PREINIT 31.026 Pre-MXG-Initialization exit for SASHELP.VEXTFL.
READDB2 31.115 READDB2 with COMPRESSED/Internal, NO OBS created.
READDB2 31.128 LDB2*** parameters were not honored.
READDB2 31.163 WPS ONLY. WPS Compiler macro resolution error.
READDB2 31.165 PDB.DB2STAT1 not created with READDB2 STATISTICS.
READDB2 31.167 DB2 V8 ONLY. V8-only IFCID=225 were not read.
READDB2 31.191 READDB2 PDBOUT=, or PDBOUT=XXX may not work right.
READDB2 31.191 READDB2 revision for PDBOUT=WORK or PDBOUT=XXX.
READDB2 31.269 "Too few" IFCIDs listed caused no sort to PDBOUT.
RMFINTRV 31.138 Multi-period RSP/TRN/SWP mislabeled BAT1 vs BATHI.
TYPE0 31.193 TYPE 0 IPL RECORD now 68 bytes in z/OS 2.1, DELETED.
TYPE0 31.193 z/OS 2.1 SMF ID=0 Length changed, record DELETED.
TYPE102 31.001 Support for variable QW0141OT in T102S141 dataset.
TYPE102 31.027 Variable QWHCEUWN added to T102Snnn DB2 datasets.
TYPE102 31.166 Support for IFCID=380 STORED PROCEDURE DETAILS
TYPE102 31.258 Support for IFCID 359, "DB2 Statement ID" decoded.
TYPE102 31.261 Support for DB2 IFCIDs 370 and 371 (OPEN/CLOSE TRACE)
TYPE102 31.278 Support for DB2 Trace IFCID=733 PSEUDO DELETE CLEANUP
TYPE110 31.012 CICLDR output tests LDRTU instead of LDRFC.
TYPE110 31.048 MXG 31.01 only, STID=29, CICSMDSA dataset wrong.
TYPE110 31.075 ASCII execution, RTYPE/RRTYPE may be incorrect.
TYPE110 31.110 CICS/TS 5.1 MNSEGCL=5 file resource INCOMPATIBLE.
TYPE110 31.214 CICSJS variables SJSMAJCP/SJSMINCP are not CPU time.
TYPE110 31.253 SMSGDHWM/SMSGCCUR correction for CICS/TS 4.2 or later
TYPE111 31.283 Support for CICS Transaction Gateway V9R0 (COMPAT)
TYPE113 31.003 Message UNINIT VARIABLE SM1132MM minimal impact.
TYPE113 31.169 SMF 113 vars DWINSORM and DWDASORM wrong for zEC12.
TYPE113 31.169 SMF 113 vars SM1132MT and SM1132MM were blank.
TYPE113 31.172 Macro to re-label SMF 113 counters for old machine
TYPE113 31.208 ASUM113 LPARBUSY/MIPSEXEC wrong for zEC12 processor.
TYPE115 31.179 Support for MQ 7.1.0 SMF 115 subtypes 5, 6, and 7.
TYPE115 31.188 New TYPE115S dataset for SMDS/QEST data.
TYPE115 31.188 Support for MQ SMF 115 ST 2 SMDS/QESD, new TYPE115S.
TYPE117 31.199 S17NNDM added to the BY list _B117NOD for NODUP.
TYPE119 31.218 INVALID DATA FOR SCACTIME in ID=110 SUBTYPE=32.
TYPE120 31.143 TYP1209E variables SM1209DA-DF are accumulated.
TYPE120 31.170 Variable SM1209BK (Short Server) added TYP1209C/S/U.
TYPE30 31.277 TYPE30MU dataset now has zero obs by default: useless
TYPE30 31.280 IOTMNOCA=SMF30AIC-IOTMDASD corrected (was IOTMTOTL).
TYPE42 31.216 INVALID DATA FOR S42CSYNC.
TYPE6 31.106 PRINTWAY and PSF TYPE6 TASKTIME TCP/PSF/TCPE values.
TYPE6 31.207 31.07 only. Debugging SMFLN3=162 LENLEFT=552 removed.
TYPE70 31.130 SHARE Weights for zIIP/zAAPs corrected.
TYPE7002 31.220 Enhancement to CRYPTOGRAPHIC PROCESSOR (70-2) support
TYPE7072 31.174 WARNING: MULTIPLE LENGTHS FOR IFAUPTM and Tutorial
TYPE7072 31.266 MSU Units (Hardware vs Software) in TYPE70/TYPE72GO.
TYPE7072 31.274 System with only CPs + ICFs, LPAR SHARE weight wrong.
TYPE70PR 31.140 SMF70GNM, Group Name, blank in 31.03-31.04.
TYPE74 31.072 Format MG0748L new value for 16 GB/s Link Type
TYPE78CU 31.127 Vars R783DCTM/DDTM (CU Connect/Disconnect) added.
TYPE80A 31.257 TOKDANAM='UTYPE' ERROR if last, new TOK variables.
TYPE85 31.006 Support for OAM SMF ID=85 STs 90,91,92 and 93.
TYPE90A 31.045 ID=90.6,7 EVENTIME is IPLTIME of the system.
TYPEBETA 31.036 BETA93 had invalid data in BETA1 for 4.2.0 and 4.3.0.
TYPEBETA 31.162 Variable JOB and BETAJOBN are now consistent.
TYPEBVIR 31.016 Support for BVIR Version 2.0/2.0a/2.1.
TYPEBVIR 31.039 Option to add SYSTEM value to IBM TS7700 BVIR data.
TYPEBVIR 31.168 Support of Hydra/BVIR Version 3 new data fields.
TYPEBVIR 31.254 BVIR30 dataset was incorrect with VERSION 3 records.
TYPECIMS 31.137 IMF TRXZxxxx variables incorrectly input.
TYPECIMS 31.206 Support for IMF 5.1 (INCOMPAT, but only CIMSDBDS).
TYPECIMS 31.233 Correction for IMF 4.2 thru 5.1 (WRONG VALUES)
TYPEDB2 31.015 "Truncated" QPACLOCN/COLN/PKID/ASHC/AANM maybe wrong.
TYPEDB2 31.056 Variable THREADS now correctly set for ROLLUPs.
TYPEDB2 31.081 Support for DB2 V10 ID=100 Subtype 5 DB2STAT5 dataset
TYPEDB2 31.093 DB2STAT5 "INVALID" record supported, STARTUP event.
TYPEDB2 31.108 DB2STATS vars QXSTCWLP+ and QISTWMXU incorrect.
TYPEDB2 31.117 DB2 V10. All QLSTxxxx numerics WRONG (DBSTATR/STATS).
TYPEDB2 31.196 Support for APAR PM67806 adds QW0225DMH DMH GETM.
TYPEDB2 31.196 Support for DB2 APAR PM67806 adds QW0225DMH DMG GETMs
TYPEDB2 31.240 Support for DB2 V11.1. MXG 30.30 TOLERATES, see text.
TYPEDB2 31.245 Support for APAR PM90886 new IDAA/NETEZZA ELIGIBLEtm.
TYPEDB2 31.259 Variable QWHSNIDIP=IP*ADDR*FROM*QWHSNID QWHCATYP=8
TYPEDB2 31.272 Invalid SMF 101 subtype 1 from ASG TMON/DB2 DB2ACCTP.
TYPEDB2 31.275 MXGWARN: T102S225 DOES NOT EXIST.
TYPEDB2 31.282 DB2PM *ROLSUM*,*ROLLUP* both now set DB2PARTY='R'.
TYPEEDGR 31.118 Support for EDGRXEXT variables added in z/OS 1.13
TYPEIDMP 31.018 Support for PACE's IDMS 17 KOMAND/IDCS SMF record.
TYPEIDMS 31.197 After MXG 30.30, only IDMS 17, zero obs in IDMSINS.
TYPEIMS 31.102 IMS 13 inserted field in 07 Log record INCOMPAT
TYPEJESC 31.225 Support for Emtex JESCONNECT SMF Record.
TYPENMON 31.058 NMON records SEA, SEAPACKET, DONATE are supported.
TYPENMON 31.119 Variables IPCSTIME and TIMEZONE added to NMONBBBP.
TYPENMON 31.164 Protection for invalid NMON DISKxxxx records.
TYPENMON 31.264 Support for Red Hat Linux Data Group,NFSCLIV4 metrics
TYPENTSM 31.030 Major update for NTSMF adds datasets and variables.
TYPEPDM 31.226 Support for Alebra Parallel Data Mover SMF record.
TYPEPRPR 31.054 Corrections to '1031' and '1061' records.
TYPERACF 31.146 INPUT STATEMENT ERROR RACF UNLOAD, invalid data too.
TYPERMFV 31.004 RMF III, z/OS 1.13 APAR OA38660 ASI data wrong.
TYPERMFV 31.021 RMF III Enhancements
TYPERMFV 31.074 RMF III dataset ZRBLCP var LCPUPOLR/CHIN/CHIX wrong.
TYPERMFV 31.273 Support for RMF III CATG3 Cache Data ERB74CA dataset.
TYPERMRV 31.062 RMF III Enhancements - blocking CPU and CPCDB.
TYPESHDE 31.177 SHADOW variable SM01ADCT ADABAS COMMAND COUNT wrong.
TYPETLMS 31.215 Support for new TLMS variables, compression percent
TYPETMD2 31.133 Support for TMON for DB2 Version 5 second iteration.
TYPETMMQ 31.020 Support for TMON/MQ Version 2.15 new data.
TYPETMMQ 31.190 Many new variables added to TMMQQU MQ QUEUE dataset.
TYPETMMQ 31.190 New variables added to TMMQQU.
TYPETMNT 31.010 MSGID NOT FOUND for MXGTMNT SYSLOG SUBTYPE 8 record.
TYPETPMX 31.116 TYPETPMX variable JOBNUM truncated if 6 digits long
TYPETPMX 31.263 ERROR.VMACTPMX. VARNAME=$INCLAI or $DBS_SD NOT FOUND.
TYPEVFTP 31.023 Support for Software Diversified Services VFTP SMF.
TYPEVIP 31.022 Support for Software Diversified Services VIP SMF.
TYPEVMXA 31.151 Support for zVM 6.3 MONWRITE, INCOMPAT due to MXG.
TYPEVMXA 31.194 31.02-31.06, z/VM 6.2.12, STOSHG BROKEN CONTROL REC.
TYPEVMXA 31.194 MXG 31.02-31.06 BROKEN CONTROL, STOSHD MRHDRLEN=112.
TYPEWWW 31.052 IIS Weblog URIQUERY with &=1 and no name supported.
TYPEWWW 31.137 IIS Log with ' ... ' COOKIE value caused MXG loop.
TYPEXAM 31.160 Support for Velocity Software new segments new data.
TYPEXDFG 31.049 Support for WAS XD (WebSphere Extended Deployment).
TYPEZPRO 31.167A VOLTAGE Release 4.2 segment count circumvention.
UTILBLDP 31.276 Tool to ad hoc read SMF is enhanced WANTSMF= list.
UTILEXCL 31.051 ***UNKNOWN FIELD*** protection still didn't protect.
UTILEXCL 31.147 Support for CANPROD4, CANPROD5 and CANPROD6 fields.
UTILEXCL 31.295 Negative values in variable TASELGTM with IMACEXCL.
VGETOBS 31.180 Circumvent WPS ABEND with unopened LIBNAME on tape.
VGETOBS 31.200 Revisions in concert with VMXGWORL for READDB2.
VGETOBS 31.212 Final (?) revisions to VGETOBS to bypass tape mounts.
VGETOBS 31.247 ERROR: WORK.MXGTABLES NOT FOUND with earlier VGETOBS.
VGETOBS 31.250 A better way to identify TAPE data libraries.
VGETWKLD 31.028 Hardcoded VIEWs removed.
VMAC73 31.291 SMF73SPD Channel Speed now always in MBits/sec.
VMAC80A 31.139 Support for RACF TOKDANAM='UNAME'.
VMACSMF 31.014 New %LET SMFPUTHD=NO; suppresses header messages.
VMXGINIT 31.285 JCL //INSTREAM DD is no longer required for z/OS MXG.
VMXGRMFI 31.268 Some RMFINTRV xxxxSWAP xxxxTRAN xxxxEXCP un-formatted
VMXGSRCH 31.171 UNABLE TO CREATE WORK.TABLES.DATA BECAUSE ..VIEW....
VMXGSRCH 31.219 Search which character variables contain text string.
VMXGWORL 31.200 Revisions in concert with VGETOBS for READDB2.
WPS 31.224 Current status of WPS circumventions and differences.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 31.
====== Changes thru 31.296 were in MXG 31.31 dated Jan 20, 2014=========
Change 31.296 -RMF III Enhancements and Fixes
ASMRMFV -New parameter TABERR=ABEND/IGNORE/WARN directs ASMRMFV
ADOCRMFV when one or more RMF Monitor III table validation
ZASMRMFV errors have occurred (default WARN). Table validation
Jan 18,2014 has been part of ASMRMFV since Change 31.080 in MXG
V31.02.
-Validating RMF III tables prevents incorrect and/or
conflicting data from being absorbed into an MXG PDB that
could be difficult to detect, diagnose, and resolve.
-A validation error occurs when an offset or length within
a table is not as expected or is logically inconsistent.
For example, the length of the table header is greater
than the total table length. This should be a VERY RARE
event.
-However, in past versions ASMRMFV could issue Return Code
0000 when such errors occurred thus making it appear that
there were not any problems in the ASMRMFV run.
-With this change ASMRMFV will issue Return Code 0016 when
one or more table validation errors occur. This is the
only condition for which this Return Code is issued.
-When a table validation error occurs the entire table is
skipped and thus the data will not appear in the result
PDB.
-These errors are thus a significant event and should be
reported to MXG Technical Support as soon as possible.
Use TABERR=IGNORE to bypass these errors and not set
Return Code 0016 until the issue can be resolved.
-Such tables are skipped and written to the optional
RMFSKIP DD if present in JCL. They will not be included
in the result PDB so all data in the table is lost.
These are not reliable data sources and could result in
more serious problems if they were input to a PDB build.
-RMFV035* (*=I,S) is now a variable severity message that
reports table validation errors both in ASMRMFV detail
and summary reports. In some cases RMFV035* will report
more details on the specific error.
-Prologue documentation in ASMRMFV source code and in the
ADOCRMFV member has been updated with a discussion of the
TABERR= parameter.
-Performance for the output of some RMF III tables to the
RMFBSAM file is improved by using block data moves to the
output buffer when moving contiguous entries within a
table. In the past ASMRMFV moved single entries at a
time. This applies to the CPD, CSR, ENT, OPD, and SPG
tables only.
-RCD processing did not include the RCDRD section when
validating this table and this is corrected.
-ASMRMFV was initializing variable mode messages before
PARM processing was complete so that *ERR= PARM overrides
were not affecting the corresponding message format. The
overrides were functional but the corresponding message
format could be incorrect.
-The patch for Change 31.287 only is included in the
archival ZASMRMFV member intended only for use with
non-z/Architecture hardware. No other changes after
Change 31.181 are included as this member is stabilized.
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change must
be installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Change 31.295 Negative values in variable TASELGTM, zIIP Eligible time,
UTILEXCL in dataset CICSTRAN, when UTILEXCL was used to create the
Jan 18, 2014 tailored IMACEXCL member (support for EXCLUDEd fields in
your CICS SMF 110 records). The generated IMACEXCL code
incorrectly subtracted TASZIPTM from OFFLCPTM.
-UTILEXCL logic to KEEP TASELGTM,TASZIPTM was added.
Thanks to Paul Volpi, UHC, USA.
Change 31.294 NEWMODEL parameter added to GRAFWRKX to allow you to
GRAFWRKX see what your workloads would look like on a different
Jan 18, 2014 CPU model. Formats TMPSUSEC and TMPNRCPU are defined
in member GRAFWRKX to map NEWMODEL to Hardware SU_SEC
and NRCPU Engine count for MSU Capacity for the new
processor, to recalculate CPU time and percent busy.
Change 31.293 Sample JCL to create PDB.ASUMUOW, PDB.CICS for TMON/CICS.
JCLUOTT2 The MONICICS file is read with tailored "TYPETMO2" logic
Jan 16, 2012 to create MONITASK dataset, but KEEPs only the variables
that are needed, to save disk space, CPU, and I/O. Then,
MONITASK dataset is summarized by ASUMUOW and ASUMCICX
to create the PDB.ASUMUOW and PDB.CICS summary datasets.
No DB2 nor MQ data is processed in this example.
Change 31.292 The DATASET name requested is now printed in the default
VMXGPRNT TITLE1 by VMXGPRNT. However, see also MXGLABEL that is
Jan 15, 2014 added by Change 31.288 which may be simpler to learn!
-MXGWARN that WORK.SP_L does not exist is suppressed.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.291 Variable SMF73SPD was in MBits/sec if SMF73MSC=0 or was
FORMATS in Bits/sec otherwise with Bits/sec in the label, but it
VMAC73 makes more sense to label and store MBits/sec for this
VMAC79 new Channel Speed metric added by APAR OA22918 for z196
Jan 16, 2014 (High Performance FICON support). SMF73SPD is zero for
FICON Express 4 channels; the enhanced metrics are only
generated by FE-8 and FE-8S or later channels.
-Variable SMF73CPP in TYPE73 and R79CCPP in TYPE79 are
decoded by MG073FR format to display the channel path
frame size (16/24/40/64KB).
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Thanks to Brian Currah, Independent Consultant, CANADA.
Change 31.290 For TMON/CICS Transaction Records, 'TA', the IHDRTMO2
IHDRTMO2 exit is now taken AFTER the offsets to the 22 subsections
VMACTMO2 have been INPUT so you can know what data is present and
Jan 15, 2014 so you could reset the NUMBER to zero to suppress their
processing; IHDRTMO2 comments identify entry variables.
Change 31.289 Cosmetic. VGETOBS could be called with DATASET=_NULL_,
VGETOBS notably in VMXGUOW if MQ/DB2/CICS is suppressed.
Jan 12, 2014 This change detects the _NULL_ and returns eliminating
warning messages.
Change 31.288 New MXGLABEL macro reads the contents of a SAS dataset to
MXGLABEL create a LABEL statement with the VARIABLE NAME and LABEL
Jan 16, 2014 as the label's value for each variable in that dataset.
These labels are the same as VMXGPRNT/VMXGPRA1/VMXGPRAL
print, but if you know how to use PROC PRINT, you can use
MXGLABEL and not have to learn those program's arguments:
%MXGLABEL(DATASET=PDB.JOBS,NAMEPOSITION=BOTTOM);
PROC PRINT DATA=PDB.JOBS SPLIT='*';
&MXGLABEL;
TITLE PRINT WITH NAME AND LABEL OF DATASET &MXGDATASET;
The VARIABLE NAME can be at the TOP or BOTTOM of the new
label when split-printed, and you can choose the bookend
character (around the variable name) and even change the
asterisk SPLIT CHARACTER.
-%MXGLABEL also creates a macro variable &MXGDATASET with
the name of the dataset dataset name (like for TITLEs).
-The LABEL statement is returned in both the old-style
macro token _MXGLABL and in the macro variable &MXGLABEL.
-Macro variables are limited to 64K characters, and with
a 32-character name and 40-character label, only 858 vars
labels would fit in 64K text, but this implementation has
no such limit, by storing only the NAME of the old-style
macro (%LET MXGLABEL= _MXGLABL;) for the macro variable's
value, so only your disk space limits amount of code.
THIS ONLY WORKS IF &MXGLABEL IS EQUATED TO _MXGLABL TEXT
BEFORE MACRO _MXGLABL IS INSTANTIATED. Equating after
instantiation will fail if the expanded text exceeds 64K.
-The USEFILE argument defaults to MXGLABEL and writes to
the WORK file as a CATALOG so it can be any 8-character
file name for the write and read. See Change 31.285.
-A LABEL statement AFTER the &MXGLABEL statement will
override the stored label; SAS uses the last statement.
Change 31.287 MXG 31.02-31.09. ASMRMFV could skip RCD tables during
ASMRMFV validation added in Change 31.080 (MXG 31.02) of the
Jan 12, 2014 RCDSD/RCDPD section entry lengths. There were no error
nor warning messages, but an uncleared register could
cause the calculated length to exceed 32K which caused
the entire RCD record to be not be written to RMFBSAM,
causing RCD datasets to have zero observations.
(The ASMRMFV report of record types read/written did
show there were RCD records read but now all written.)
The register is now cleared in the two overlooked places.
-This change to ASMRMFV also requires MXG at 31.09 to read
the new RMFBSAM 31.287 records, due to new source members
added to support the CAT records. Specify NOCAT instead.
-However, if you update your current ASMRMFV with these
two one-line-inserts in ASMRMFV, the RCD records won't
be skipped, and your current MXG VMACRMFV processing will
correctly populate the RCD datasets.
Find these two ICM statements in your ASMRMFV and insert
the SR statement between the JL and ICM like this:
JL SKIPRCD YES, ERROR
SR R0,R0 SET REG0=0 <===ADD THIS LINE
ICM R0,3,RCDPDAL(R9) GET LENGTH OF ONE RCDRD ENTRY
JL SKIPRCD YES, ERROR
SR R0,R0 SET REG0=0 <===ADD THIS LINE
ICM R0,3,RCDSDAL(R9) GET LENGTH OF ONE RCDRD ENTRY
Member JCLASM3 is the sample JCL for the assembly and
link-edit installation of the EDITed ASMRMFV.
Thanks to LaRae Balthazor, Charles Schwab, USA
Thanks to Anh Ngo, Charles Schwab, USA
Change 31.286 If you specified MXGxxxxx=NO, to skip that report, errors
ANALDB2R resulted: ANALDB2R syntax error caused that parameter to
Jan 11, 2014 be compiled as a DATA step statement, but there was no
semi-colon to end the statement, causing various errors.
NO or blanks are now taken as NO.
If you specified PLAN= with PDB=SMF, the PLAN name was
not passed to READDB2 so ALL records were read and then
selection was done by ANALDB2R after READDB2, where it
should have been done to minimize disk,I/O,CPU,etc.
PLAN is now included in this list of parameters that can
be passed from ANALDB2R to READDB2 for READDB2 selection.
AUTHID BEGTIME CONNID CONNTYPE DB2 ENDTIME PLAN
Thanks to Stephen Hughes, Excellus, USA.
Change 31.285 SEE CHANGE 32.022 WHICH REMOVED THIS CHANGE FROM MXG.
VMXGINIT INSTREAM FILEREF OR DDNAME IS STILL REQUIRED IN MXG.
Jan 13, 2014 ORIGINAL CHANGE TEXT:
Feb 4, 2014 The //INSTREAM DD is no longer required for MXG on z/OS.
Now, VMXGINIT, at MXG Initialization, executes
FILENAME INSTREAM CATALOG 'WORK.MXGTEMP.INSTREAM';
which allows INSTREAM to be used as an external I/O file.
On z/OS, the CATALOG will be used when there is no DD.
On ASCII, the VMXGINIT FILENAME INSTREAM is always used,
since it will be after any FILENAME in AUTOEXEC and will
replace an existing INSTREAM fileref if one exists.
MXG has always required an INSTREAM fileref, either as
//INSTREAM DD in the JCL, or FILENAME INSTREAM, because
MXG writes text (SAS statements) to it "on the fly" and
a %INCLUDE INSTREAM; executes the created program code.
-The CATALOG syntax has a three or four part name
FILENAME INSTREAM CATALOG 'lib.catalog.entry.entrytype'
where entrytype can be anything for READ, but only LOG,
OUTPUT, SOURCE, or CATAMS (the default 4th) for WRITE.
-In testing this transparent enhancement, I re-discovered
.On z/OS or ASCII, FILENAMEs allocated with a FILENAME
can be CLEARed, and the MXGNAMES/VMXGCNFG JCL for z/OS
uses FILENAME INSTREAM, so INSTREAM it could be cleared.
.On z/OS, FILENAMEs allocated in JCL cannot be CLEARED.
.But you should never need to CLEAR the JCL INSTREAM DD:
There's nothing that precious about FILENAME INSTREAM
except that it is guaranteed to be there when needed.
Especially since you can't clear the JCL DD anyhow!
You can always use a different NAME in your FILENAME
statement, with either CATALOG or TEMP to create an
external file for your "instream" code creation. I did
consider using TEMP instead of CATALOG for INSTREAM
default in VMXGINIT, but on z/OS the CATALOG syntax is
simpler, while the more complex (but more powerful)
TEMP option requires device and size and JCL DD stuff.
.ERROR: Catalog WORK.MXGTEMP DOES NOT EXIST if you try to
read INSTREAM (INCLUDE/INFILE) before it was written.
Change 31.284 If you specified MXGMQADD=NO and executed _SUOWMQ you got
VMXGUOW a SAS message that a data step was being stopped because
Jan 9, 2014 it was looping. This was caused by the absence of a SET
statement that is conditionally executed if MXGMQADD=YES.
An ELSE STOP; was added to prevent the message (which
did not cause an ABEND or failure.)
Change 31.283 Support for CICS Transaction Gateway CTG V9R0 (COMPAT).
VMAC111 -Variable CTGSTART, DAEMON*START*DATETIMESTAMP is INPUT
Jan 9, 2014 and kept in all TY111xx datasets.
-New variables added to TY111GD Daemon dataset:
CTGIRESP='INTRV*DAEMON*AVG RESP*WITH I/O'
CTGLRESP='LIFE*DAEMON*AVG RESP*WITH I/O'
CTGIXNHI='INTRV*PEAK*INFLIGHT*XA TRANS'
CTGIXNHI='LIFE*PEAK*INFIGHT*XA TRANS'
See correction in Change 32.007.
Change 31.282 APAR PI06009 to TDS DB2PM reports notes their report will
VMACDB2 display '*ROLSUM*' for DB2 V10 Packages with QPACRUSM='Y'
Jan 8, 2014 for the new Rollup Summary record flag, while '*ROLLUP*'
is unchanged in V9 if QPACROLL='Y'. With this alert, MXG
variable DB2PARTY='R' is now set if QPACRUSM='Y' so both
Rollup and Rollup Summary records are identified in the
DB2ACCTP dataset.
Change 31.281 DB2 dataset T102S377 variable QW0377PT was incorrectly
VMAC102 input as 4 bytes when it is a 2 byte field, which caused
Jan 8, 2014 wrong values in QW0377FL/QW0377PG/QW0377NU.
(This was my bad for missing my own coding error, that
wasted the customer and IBM DB2 Support's time.)
Thanks to Bart Steegmans, IBM DB2 Support, USA.
Change 31.280 MXG variable IOTMNOCA=SMF30AIC-IOTMDASD now correctly
VMAC30 compares the DASD connect time captured in SMF30AIS with
Jan 1, 2014 the sum of IOTM from the DASD DD segments; previously it
incorrectly used IOTMTOTL in the equation.
Values from minus 20 seconds to plus 20 seconds are found
occasionally, where minus 20 means that the DD segment
IOTM was greater than the SMF30AIC DASD connect time.
====== Changes thru 31.278 were in MXG 31.09 dated Dec 30, 2013=========
Change 31.278 -Support for DB2 Trace IFCID=377 (PSEUDO DELETE CLEANUP).
EX102367 creates T102S377 dataset.
EX102374 -Support for (HEADER ONLY) all of these new ID=102 IFCIDs
EX102375 that are documented in DB2 V11;
EX102376 367 374 375 376 378 379 382 383 384 385 386 397
EX102377 398 399 499
EX102378 Actual data records are required to decode new IFCIDs,
EX102379 but by adding the structure for all of these possible 102
EX102382 subtypes, only VMAC102 itself will need to be updated to
EX102383 decode the IFCID-unique variables in these records.
EX102384
EX102385
EX102386
EX102397
EX102398
EX102399
EX102499
IMAC102
VMAC102
VMXGINIT
Dec 28, 2013
Thanks to Paul Walters, Navy Federal Credit Union, USA.
Change 31.277 TYPE30MU dataset now has zero obs by default. It is not
EXTY30MU actually used by IBM SCRT nor MXG for analysis, it can be
Dec 26, 2013 very large, because it replicates product segments in the
same interval, and because if you really need it, it can
be easily enabled, by removing the comment block in the
EXTY30MU exit member in your "USERID.SOURCLIB" tailoring.
Change 31.276 UTILBLDP is the RECOMMENDED ad hoc tool to read SMF data.
UTILBLDP New WANTSMF="list of ID.SUBTYPE" provides easier syntax
Dec 26, 2013 for selection of ID/SUBTYPES you want to be read. You
select the PRODUCTS with BUILDPDB=YES or USERADD=n m z.
You then use either WANTSMF= to select the ones you want,
or you use the existing ZEROOBS= to alternatively force
the unwanted subtypes to have zero observations.
%UTILBLDP(BUILDPDB=NO,
USERADD=42 7072 71 73 74 CMF,
WANTSMF=42.6 70.1 73 74.1 74.5 74.6 240);
%INCLUDE BUILDMXG;
Generally, you can use the argument with fewer arguments,
but to use ZEROOBS correctly you must know all subtypes
in advance, while using WANTSMF= you only need to list
the ID.SUBTYPEs you know about and want.
Thanks to Pat Artis, Performance Associates, Inc., USA.
Change 31.275 Spurious DATASET T102S225 DOES NOT EXIST messages are
READDB2 corrected for that archaic dataset, populated only with
VMACDB2 DB2 V8, where it is written as ID=102 SUBTYPE=IFCID=225,
Dec 25, 2013 and thus read with %READDB2. Instead, in DB2 V9 plus,
Dec 26, 2013 IFCID=255 is written as ID=100 records and read with
TYPEDB2/BUILDPDB. In all versions, however, all QW0225xx
variables are output in the PDB.DB2STATS dataset, which
contains all interval statistics
-MXGNOTEs listing the Subtypes/IFCIDS wanted are revised.
Change 31.274 On a system with only CPs and ICFs, the LPAR SHARE weight
VMAC7072 calculations were wrong, with values like weights instead
Dec 21, 2013 of the expected percentages. The test that deletes 'IFL'
now also delete 'ICF's from weight calculations.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 31.273 Support for RMF III CATG3 Cache Data which writes SMF 74
ADOCRMFV subtype 5 records to the RMF III VSAM file with the same
ASMRMFV metrics as RMF I SMF records, but with more granularity
ASUMCACH (typical 1 minute RMF III INTERVAL and yet take less DASD
EXZRB74C space (only active devices are written in the one-minute
EXZRB74I III records, while all devices are written to RMF I SMF).
EXZRBCAT (Note: MXG outputs ONLY active devices so the output size
IMACZRB per interval will be the same.) This support creates the
VMACRMFV new ZRB74CA dataset, instead of naming it TYPE74CA, since
VMXGINIT archaic variables from segments that no longer exist are
Dec 23, 2013 not kept, but all other variable names are the same.
Dec 28, 2013 -ASUMCACH will now read either SMF TYPE74CA or RMF ZRB74CA
to create PDB.ASUMCACH, looking for ZRB74CA first.
-Notes for collection and use of RMF III Cache Data:
-The RMF Monitor I parameters CACHE and ESS must also be
in effect on the same system with the RMF Monitor III
CACHE parameter. The RMF Monitor I defaults are CACHE
and NOESS.
-If ESS is not in effect for RMF Monitor I on the cache
collection system the related PDB variables will be
missing values (in both TYPE74CA and ZRB74CA).
-From Newsletter FIFTY:
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.
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.
-With this change all RMF Monitor III documented tables of
practical use are now supported by MXG.
-Creating readable 74.5 records from the RMF III VSAM was
non-trivial in ASMRMFV, because those records can be more
than 32K bytes in the VSAM file, so longer records needed
to be broken into shorter, but complete, records.
-New ASMRMFV parameters CAT (alias H) and NOCAT (aliases
-CAT, -H) are provided to select or filter CATG3 table
data respectively.
-ASMRMFV messages RMFV036I and RMFV105I are updated to
show CAT table information.
-ASMRMFV validates the CAT header and each SMF Type 74.5
record contained in the CAT table.
-Initial ASMRMFV assembly environment message RMFV000I is
revised to show the assembly date as a Julian date, as a
date in ddmmmYYYY format, and as the 3 character day of
the week.
-The ASMRMFV source code prologue as well as the ADOCRMFV
documentation member are updated appropriately.
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change
must be installed. See MXG SOURCLIB member JCLASM3 for
sample JCL for the assembly and link-edit install steps.
-Only data for active devices is collected which means
that for some Subsystem IDs (SSIDs) all device data
variables in the PDB could be missing for some RMF III
MINTIME intervals.
-Cache Controller data is gathered by individual device
address. There is no indication of which system in the
sysplex initiates a recorded event. Therefore, the data
can be gathered on any system sharing the cached devices.
-Avoid unnecessary high CPU utilization and duplicated
data by gathering cache activity data on only ONE system
per IBM documentation for either RMF Monitor I or RMF
Monitor III.
-Use the RMF Monitor I and RMF Monitor III parameter
NOCACHE to suppress cache data collection on all other
systems.
-Use CACHE(ssid1,ssid2,..,ssidn) in RMF Monitor III to
collect data for only those Subsystems needed. RMF
Monitor I does not support selection by SSID.
-Selection by Subsystem ID may also be needed if not all
subsystems are shared. In this case cache data
collection will be needed on more than one system.
-Consult the section "Generalizing Parmlib Members" in the
IBM RMF User's Guide for your z/OS level for a method to
control selection of which system records cache data.
Other approaches are certainly possible with system
automation tools.
-The best choice for a cache data collection system is one
with high uptime that is not already CPU stressed. z/OS
systems operating as z/VM guests will not record cache
data even if requested.
-All ASMRMFV messages that display a Julian date in the
format of YYYY.DDD are enhanced to show the date as
DDMMMYYYY and a 3 character day of the week.
-11 messages are updated to have the improved date
display:
RMFV000I, RMFV001I, RMFV006I, RMFV008I, RMFV012I,
RMFV013I, RMFV023W, RMFV025I, RMFV026I, RMFV032E, and
RMFV034I.
-Message RMFV008I showed an incorrect creation date when
a non-VSAM data set was supplied in error for a RMF III
VSAM data set. The creation date in this case will
not be shown.
-DSNAME= in the RMFV008I message is now abbreviated to
DSN= to conserve line space.
-1ST VOL= in the RMFV008I message is now abbreviated to
VOL= to conserve line space. It continues to show the
first volume for a multi-volume file.
Change 31.272 Invalid SMF 101 Subtype 1 created from ASG TMON/DB2 had
VMACDB2 INPUT EXCEEDED RECORD error that this change circumvents
Dec 19, 2013 while the problem is investigated. The triplets for the
QBAC and QTXK segments are reversed, and their count does
not always match the count of QPAC segments.
Change 31.271 Support for APAR OA43380 which adds CA*SPLITS and
VMAC42 CI*SPLITS in TYPE42S1-S4 and TYPE42D1-D datasets:
Dec 19, 2013 S1: SMF42FSA SMF42FSB
S2: SMF42FTA SMF42FTB
S3: SMFA2FSA SMFA2FSA
S4: SMFA2FTA SMFA2FTB
D1: SMF42GTA SMF42GTB
D2: SMF42GSA SMF42GSB
D3: SMFA2GTA SMFA2GTB
D4: SMFA2TSA SMFA2GSB
Change 31.270 Cosmetic. MXG Error Messages with 'ERROR:' starting in
VMAC28 byte one of the output are counted by SAS and flagged as
Dec 19, 2013 an ERROR on that page, and text printed in RED on the SAS
log, but that was not my intention, and these members are
corrected so that 'ERROR:' does NOT start in column one:
VMAC28 VMAC102 VMAC110 VMAC113 VMACDB2
VMACHURN VMACNMON VMACVMXA VMACXAM
Most of the "actual" error conditions detected by MXG are
printed 'MXGERROR: ' but there is a lack of consistency.
Thanks to MP Welch, Bank of America, USA.
Change 31.269 -If you specified "a small number" of IFCIDS, they weren't
READDB2 sorted into the output PDBOUT libname because of an
Dec 19, 2013 incorrect compare for GT 1 that should have been GT 0.
Dec 23, 2013 Probably caused by Change 31.128 (MXG 31.05).
Dec 25, 2013 -If you ran ANALDB2R with PDB=SMF and PDBOUT= was NOT set
to PDB, a U1950 ABEND was generated by VGETOBS if the PDB
libname did not exist in your SAS session. Caused
by the PDB2225 macro variable default of PDB and ANALDB2R
did not reset the value to the value of PDBOUT argument.
-Messages about datasets not being deleted were deleted.
Thanks to Paul Walters, Navy Federal Credit Union, USA.
Change 31.268 These RMFINTRV variables should not have been formatted
VMXGRMFI as TIME12.2 since none are durations:
Dec 18, 2013 OTHRSWAP OTHRTRAN OTHREXCP OTHRWKST OTHRSERV OTHRPGIN
TSO2SWAP TSO2TRAN TWO3SWAP TSO3TRAN TSO4SWAP TSO4TRAN
TRIVTRAN TRIVSWAP
Those variables have been buried in &R72VAR for a long
time and it was in the TIME12.2 format statement.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 31.267 Messages that there are 0 OBS or dataset was not found
VGETOBS are suppressed when dataset=_ALL_ is specified.
Dec 18, 2013
Change 31.266 Documentation of MSU/SERVICE variables. To be expanded.
VMAC7072 -In TYPE72GO dataset, MSU and Service units are the old
Dec 18, 2013 and original "Hardware MSU based on SU_SEC/R723MADJ.
Feb 3, 2016 -Variable SERVICE in TYPE72GO dataset is the sum of
these FIVE components
CPUUNITS SRBUNITS MSOUNITS IOUNITS ZIPUNITS.
(some old MXG notes have only the first four listed but
ZIPUNITS have always been included in SERVICE).
-Variable MSU72 is CPUTM*SU_SEC/1E6, "Hardware MSU", which
includes ALL of the recorded CPU times in the Service
Class 72s. This is the amount of MSU that were consumed
by this Service Class/Reporting Class during this
interval, based on SU_SEC.
-The MSU units in the TYPE70 MSU variables are "Software"
MSU based on the (smaller value) in CECSUSEC/SMF70CPA.
(because they are now used for "SOFTWARE PRICING").
-Current SMF70CPA=13,000 and SU_SEC=26,000 is an example.
-Text revised, Feb 3 2016: TYPE72GO variable MSUSOFT was
wrong, but was revised in Change 34.010 and does now
contain the Software MSU CECSUSEC/SMF70CPA based.
Change 31.265 Variable STC13MRC='Y' was incorrect when STC13MNR='Y'
VMACSTC should have been have been set, and STC13MNR='Y' never
Dec 17, 2013 was set; MXG tested 00/01 instead of 01/02 STC13RCI.
Thanks to Mike Jacques, BBand T, USA.
Change 31.264 -NMON data for Red Hat Linux has new Data Group metrics
EXNMONDG that create the new dataset
VMACNMON DDDDDD DATASET DESCRIPTION
VMXGINIT NMONDG NMONDG LINUX DATA GROUP METRICS
Dec 17, 2013 -The BBBP Configuration Records have no text in common
with the BBBP records previously supported so the
NMONBBBPxxx datasets will not be populated at this time.
If you can identify which BBBP data is important, I will
update the MXG Support for those data.
-Support for NFSCLIV4 record is supported with these new
variables created in NMONNFS dataset:
OPEN OPEN_CONF OPEN_NOAT OPEN_DGRD CLOSE SETATTR
RENEW SETCLTID CONFIRM LOCK LOCKT LOCKU
LOOKUP_ROOT RENAME
LINK SYMLINK CREATE PATHCONF STATFS READLINK
READDIR SERVER_CAPS DELEGRETURN GETACL SETACL
FS_LOCATIONS
Thanks to Florent Boulesteix, INOVANS partenaire CAAGIS, FRANCE.
Change 31.263 -ERROR.VMACTPMX. VARNAME=$INCLAI NOT FOUND because the MXG
VMACTPMX code for tokenid=51467 was $INCLA, which is now corrected
Dec 17, 2013 to $INCLAI for the test; the variable INCLA is unchanged,
Dec 18, 2013 but now will be populated.
-ERROR.VMACTPMX. VARNAME=$DBS_SD-bar NOT FOUND creates new
variable DBS_SDBA in TYPETPMX dataset.
Thanks to Paul Volpi, UHC, USA.
Change 31.262 -ANALDB2R Account Detail report had some incorrect average
ANALDB2R buffer calculations that could be repeated values. Values
Dec 16, 2013 impacted were Seq prefetch, list prefetch, dyn orefetch,
Dec 18, 2013 asycnh reads, hpool writes, hpool reads, hpool reads
failed.
-If you separated the larger datasets like DB2ACCT or
DB2ACCTP into separate DDNAMES and used the DB2ACCT*
parameters to point to those LIBNAMES, ANALDB2R did not
find the datasets since it only looked in the LIBNAME
pointed to by the PDB= parameter.
Thanks to Jim Lazowski, Northern Trust, USA.
Change 31.261 Support for DB2 IFCIDs 370 (OPEN TRACE DATASET) and 371
EX102370 (CLOSE TRACE DATASET) creates T102S370 and T102S371 data
EX102371 sets.
FORMATS
IMAC102
VMAC102
VMXGINIT
Dec 13, 2013
Thanks to Lori Masulis, Fidelity Systems, USA.
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 31.260 Variable HSMPLEX added to all reports and graphs and if
ANALHSM you are on SAS 9.3 or greater ODS GRAPHICS are used for
Dec 8, 2013 the graphs. A line plot was substituted for the bar chart
where AVG/MAX values by function are being graphed and
VMXGODSO/VMXGODSC were inserted to allow you to send the
output to HTML or PDF.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.259 Variable QWHSNIDIP='IP ADDRESS*FROM*QWHSNID' is added to
VMACDB2 DB2ACCT, DB2ACCTB, DB2ACCTP, DB2ACCTG, DB2ACCTR datasets
VMACDB2H and is populated only for QWHCATYP=8 (DDF Connections).
Dec 5, 2013 When the eight-byte text QWHSNID contains an IP address,
Dec 15, 2013 eight EBCDIC text characters represent the four hex bytes
('A971896F' is 169.113.137.111)), but the VTAM NID must
start with an alphabetic character, so those IP addresses
that start with digits 0 thru 9 for the first nybble, the
value in QWHSNID starts with 'G' thru 'P'. This encoding
was found in a note about message DSNL030I.
Thanks to Alyona Bertneski, JPMorgan, USA.
Change 31.258 -Support for IFCID 359 INDEX PAGE SPLIT record populates
VMAC102 the QW0359xx variables in existing T102S359 dataset.
Dec 3, 2013 QW0359DB='DATA*BASE*ID'
Dec 12, 2013 QW0359FL='FLAGS'
QW0359OB='INDEX*PAGE*SET*ID'
QW0359PG='SPLITTING*PAGE*NUMBER'
QW0359PT='PARTITION*NUMBER'
QW0359TE='TIMESTAMP*AT ENDING OF*SPLIT'
QW0359TS='TIMESTAMP*AT BEGINNING*OF SPLIT'
-The new DB2 Statement ID variable is written to SMF as
either a 4-byte binary or an 8-byte character field that
are now formatted HEX8. for the numeric variables or are
now INPUT as $CHAR8. and formatted $HEX16. for character
QW0172TZ QW0172H9 QW0172W9
QW0196W9 QW0196H9 QW1196H9 QW2196H9 .. QW8196W9.
QW0173CS QW0317ID
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Lori Masulis, Fidelity Systems, USA.
Thanks to Paul Volpi, UHC, USA.
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.257 -INPUT STATEMENT EXCEEDED if TOKDANAM='UTYPE' was the last
VMAC80A segment because MXG expected a 4-byte binary number but
Dec 3, 2013 the field is a 1-byte EBCDIC &NUM1. field.
-New variables decoded and labeled with variable name:
TOKQUEST1 TOKQUEST2 TOKANS1 TOKANS2 TOKAD1 TOKAD2
TOKCOMPANY TOKCOUNTRY TOKFNAME TOKMNAME TOKLNAME
TOKSTATE TOKWTEL TOKZIPCODE
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 31.256 Cosmetic. INPUT for QPACLENX GE 428 actually read in 452
VMACDB2 so the INPUT is split to read thru 428 and then thru 452.
Dec 2, 2013
Change 31.255 Variable R744MCPI in dataset TYPE74MO for SCM does not
VMAC74 exist and was a "copy down" typo when that code block was
Dec 2, 2013 created; it is now deleted completely.
See Change 33.155. SCM data is now in TYPE74ST dataset.
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.254 BVIR30 dataset was incorrect with VERSION 3 records.
VMACBVIR
Nov 28, 2013
Change 31.253 -Change 30.078 corrected SMSGDHWM/SMSGCCUR for CICS/TS 4.1
VMAC110 and earlier but the change of multiplicand was still
Nov 28, 2013 wrong for CICS/TS 4.2 and later.
Thanks to Paul Volpi, UHC, USA.
Change 31.252 -VMXGSUM. If a variable was missing in a NORMx parameter,
VMXGSUM a warning was issued pointing to a variable name but not
ASUM72GO to the specific NORMx parameter that was in error. The
Nov 25, 2013 warning message is now enhanced to contain the full text
of the NORMx parameter.
-ASUM72GO. The DURATM variable was not in the SUM= list
which raised a warning about a missing variable in NORM3.
Change 31.251 MXG 31.08-9 FORMATS fails with BACKLEVEL WPS VERSION 2
FORMATS in statement in line 22864:
Nov 22, 2013 PICTURE MGXLDATE OTHER='%0m/%0d/%0Y %0H:%0M:%0S'
Oct 10, 2014 (DATATYPE=DATETIME);
with "ERROR: Found "DATATYPE" when expecting )
because DATATYPE was not supported by WPS until their
Version 3.1 And MWRTDT format added in MXG 32.09 also
failed with WPS 2.05. MGXLDATE was never used and so
it was removed. MWRTDT is required by MOBWRK06 MOBILE
WORK Discount analysis to meet IBM's CSV file format.
Thanks to Ken Drody, State of Delaware, USA.
Thanks to Kre Martin Torsvik, EVRY AS, NORWAY.
Change 31.250 A spurious MXGWARN when a libname had not been referenced
VGETOBS led to a better way to identify TAPE data libraries and
Nov 22, 2013 to enhance the elimination of tape mounts:
If the LIBNAME has never been referenced:
First record is read as an INFILE and engine type is
identified so the LIBNAME can be issued with the
appropriate engine. If this is a disk library it is
NOT added to the list of DDs found on tape/sequential.
If the DDNAME is on tape and SPINTAPE NE YES and DATASET
NE _ALL_, OBS count is set to one and no further
processing is needed.
If SPINTAPE=YES or DATASET=_ALL_:
All tape volumes are read to find all datasets and
captured in MXGTABLES which is NOT deleted.
If DATASET NE _ALL_, then also looks for this
specific dataset in MXGTABLES, and will verify the
dataset exists and determine an OBS count.
Else if SPINTAPE NE YES and DATASET NE _ALL_ and
the dataset is on disk, looks for the specific
dataset without using MXGTABLES. This is also the
behavior on ASCII as LIBNAMEs must have been
identified to SAS with a LIBNAME statement.
If a dataset does not exist or has 0 OBS the calling
program may give you a message indicating the issue
and then will die gracefully. The results are in
global macro variables VGETDSN and VGETOBS. If
VGETDSN is empty, the dataset did not exist.
Thanks to MP Welch, Bank of America, USA.
Change 31.249 These datetime variables were INPUT but not formatted or
VMAC110 not LENGTH'd or were not kept, but no one had noticed,
Nov 18, 2013 except for the MXG QA tests, so this is cosmetic.
VMAC110 : DS7LSTRT DS7START
VMAC74 : SMF74GIE
VMAC75 : SMF75GIE
VMAC76 : SMF76GIE
VMAC77 : SMF77GIE
VMACBBMQ: CHLTOD0
VMACCIMS: IMSSTCK
VMACIMS : SYNCSTCK
VMACIMSA: STSTARTTOD SYNCSTCK TPCPCLCK
VMACOMCI: ESFTIME
VMACOPC : MT0OCCTOK
VMACROSC: TIME ==> Renamed to TEMPCKTI not KEPT
VMACSMF : TESTTIME ==> Renamed to SMFTIME
VMACSYSV: RTCLOCK RTCSTART SDCRETOD SCDRSTOD
VMACTMMQ: LMRKTOD2
VMACTMNT: REND ==> Renamed to RENDTIME
VMACTMO2: T2INEDTS T2INSDTS TMMDXSTK TXINEDTS TXINSDTS
VMACTMV2: IPLTIME
VMACVMXA: PLSFOB1T PLSFOBTM
VMACXPSM: OUTGTIME
Change 31.248 If you specified DATES= any of the "one word" tokens like
ANALGRID LASTWEEK, etc., a logic error occurred because &TO was a
Nov 17, 2013 null value. Now, FROM=INPUT("&FROM",?? DATE.) is used so
a missing value results instead of the error.
Thanks to Andrew Woods, Interactive Data, ENGLAND.
Change 31.247 ERROR: WORK.MXGTABLES NOT FOUND occurs if PROC ANYTHING
VGETOBS without a DATA= argument was executed after %VGETOBS was
Nov 15, 2013 executed, because in the absence of a DATA= argument, SAS
uses the &SYSLAST macro variable, and VGETOBS created and
then deleted the WORK.MXGTABLES dataset, but &SYSLAST is
not changed when that last-created dataset is deleted!
(But even if SAS had set &SYSLAST to a _NULL_ value, the
PROC ANYTHING would still fail with a NO DATASET FOUND.)
The MXGTABLES dataset, added in 31.06, is created and is
normally deleted by %VGETOBS, an internal utility used in
many (52) MXG members, primarily to determine if a SAS
dataset has any obs (but also used to avoid tape mounts
as documented in Change 31.212, and it is NOT deleted if
SPINTAPE=YES it set). Now that this exposure has been
understood, VGETOBS is revised to store &SYSLAST at entry
and that dataset is restored in &SYSLAST at exit. Had we
been slightly smarter, this change should have been made
to VGETOBS instead of changing ANALHSM in Change 31.211,
which also failed due to the absence of a DATA= argument
after VGETOBS had been executed there! Note that there
is NOTHING wrong in a PROC without a DATA= argument, as
long as the &SYSLAST dataset actually exists!
-Although undocumented, setting automatic macro variable
&SYSLAST also sets the automatic macro variable &SYSDSN
and the system option _LAST_.
Thanks to Otto Burgess, ATPCO, USA.
Change 31.246 The data used for testing had only a single CEC so the by
GRAFCEC statement that included CECSER had no problem. But when
Nov 13, 2013 data from multiple CECs was included a not sorted error
occurred because CECSER was not in the sort BY list.
Change 31.245 Support for APAR PM90886 adds these DB2ACCT variables for
VMACDB2 IBM DB2 Analytics Accelerator (IDAA)/NETEZZA modelling:
VMAC102 QWAC_ACCEL_ELIG_ELA='ACCEL*ELIGIBLE*ELAPSED*TIME'
Nov 13, 2013 QWAC_ACCEL_ELIG_CP ='ACCEL*ELIGIBLE*CP CPU*TIME'
Dec 13, 2013 QWAC_ACCEL_ELIG_SE ='ACCEL*ELIGIBLE*ZIIP CPU*TIME'
Dec 16, 2013 -IBM did confirm that the new fields are only in IFCID=3
Dec 18, 2013 (ID 101 Subtype 0) are not in IFCID=369 (ID 100 SUBTYPE
5) DB2STAT5 data which also contains the QWAC DSECT.
-Variable QWP4ACMO='ACCELMODEL*PARAMETER*VALUE' is
added to T102S106 dataset.
-Dec 13: The QWAC DSECT was received and code revised but
no data available for validation.
-Dec 13: The Q8ST DSECT was revisited and Q8STQUEW was not
input causing many of the Q8STxxxx variables in DB2STATS
to be incorrect.
-Dec 16: IBM Support confirmed the values in variables
Q8STCCPU and Q8STWCPU are percentages times 100 so they
are now correctly input with two decimal places.
-Dec 18: The new fields in DB2ACCT were validated.
Thanks to Tim King, Blue Cross Blue Shield of South Carolina, USA.
Thanks to Scott Chapman, AEP, USA.
Thanks to Clinton Moore, Verizon, USA.
====== Changes thru 31.244 were in MXG 31.08 dated Nov 12, 2013=========
Change 31.244 TYPE21 (a/k/a PDB.TAPES) variables BYTEREAD and BYTEWRIT
VMAC21 were wrong or missing for DEVICE=3590 when SMF21MFV was
Nov 12, 2013 NOT on (i.e, when SMF21MCR/MCW/MDR/MDW were NOT valid),
due to incorrect logic that did not use SMF21BRN/SMF21BWN
(SMF21NCT was ON, which applies ONLY to 3590 devices).
Thanks to Yves Cinq-Mars, IBM Global Services, CANADA.
Change 31.243 Change 31.186 (MXG 31.07) inserted LENGTH DEFAULT=&MXGLEN
ASUM113 but the 113 variables must be stored in LENGTH DEFAULT=8
Nov 12, 2013 because they are large numerics that are then DELTA'ed;
those defaults are now 8.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.242 Reserved Change Number
Nov 12, 2013
Change 31.241 Support for CICS User field CMODNAME,CMODHEAD=USTHRD00.
IMACICVF
UTILEXCL
VMAC110
Nov 12, 2013
=====Changes thru 31.240 were in FIRST MXG 31.08 dated Nov 12, 2013=====
Change 31.240 Support for DB2 V11.1 (COMPATIBLE). MXG 30.30+ TOLERATES
VMACDB2 V11 with no EXECUTION error, but MXG 31.04 is REQUIRED to
VMAC102 correct QLSTxxxx variables in DB2STATS for V10 and V11.
Nov 11, 2013 -All new V11 fields were added AT THE END OF SEGMENTS so
MXG Version 30.30+ tolerates V11.1, but new variables are
not output.
-Dataset PDB.DB2STATS now correctly contains all of the
IFCID=225 variables, and (as previously documented but
not actually implemented) dataset DB2ST225 will always
have zero observations, when TYPEDB2/BUILDPDB is used.
Unintentionally, DB2 V10 IFCID=225 data was output in
DB2ST225 dataset, and DB2 V9 IFCID=225 data output in
DB2STAT4 dataset. Fortunately, DB2ST225 and DB2STAT4
were then combined into PDB.DB2STATS, so there was no
actual error, as long as you use PDB.DB2STATS dataset.
Now, V9-V11 IFCID=225 are output in DB2STAT4 and the
DB2STAT4 KEEP= list contains all QW0225xx variables.
-If you still have archaic DB2 V8 with IFCID=225 records,
you will need to use %READDB2(IFCIDS=STATS) to create the
WORK.T102S225 dataset for V8 and DB2STAT4 for V9-V11 so
all 225s from all versions are output into PDB.DB2STATS.
-Dataset DB2ACCT new variables in DB2 V11.1:
QWACATCT='ACCUMULATED*AUTONOMOUS*WAIT*COUNT'
QWACATRY='AUTONOMOUT*ROLLUPS*IN THIS*RECORD?'
QWACATWT='ACCUMULATED*AUTONOMOUS*WAIT*TIME*/
QWACPQCT='WAITS*FOR*PARALLEL*SYNCH'
QWACPQRY='RECORD*CONTAINS*PARALLEL*QUERY*ROLLUP?'
QWACPQWT='WAIT TIME*FOR PARALLEL*SYNCH*/
QXALTMP ='ALTER*MASK*OR*PERMISSION'
QXCREMP ='CREATE*MASKS*OR*PERMISSION'
QXCRTSV ='CREATE VARIABLE'
QXDEGAT ='PARALLEL*FALLBACKS*SEQ MODE*AUTONOMOUS'
QXDRPMP ='DROP*MASK*OR*PERMISSION'
QXDRPSV ='DROP VARIABLE'
QXHJINCS ='RID APPEND*HYBRID*JOIN*NO RIDPOOL'
QXHJINCT ='RID APPEND*HYBRID*JOIN*RIDS EXCEEDED'
QXMAXESTIDG='MAX PARALLEL*GROUP*ESTIMATED*DEGREE'
QXMAXPLANDG='MAX PARALLEL*GROUP*PLANNED*DEGREE'
QXN1093A ='SERVICEABILITY*QXN1093A'
QXN1093B ='SERVICEABILITY*QXN1093B'
QXPAROPT ='PARALLEL*DEGENERATED*OPTIMIZATION'
QXPFMAXUG ='SERVICEABILITY*QXPFMAXUG'
QXPFMAXUM ='SERVICEABILITY*QXPFMAXUM'
QXPFSENUM ='SERVICEABILITY*QXPFSENUM'
QXPFSENUMG='SERVICEABILITY*QXPFSLNUMG'
QXPFSLNUM ='SERVICEABILITY*QXPFSLNUM'
QXRSMIAP ='RID LIST*RETRIEVAL*SKIPPED'
QXSISTOR ='SPARSE*INDEX*DISABLES*INSUFF STORAGE'
QXSIWF ='SPARSE*INDEX BUILDS*PHYS WORK FILE'
QXSTARRAY_EXPANSIONS='ARRAY*VARIABLE*EXPANDS*GT 32K'
QXSTODGNGRP='PARALLEL*DEGENERATE*TO SEQ*SYSTEM STRESS'
QXSTOREDGRP='PARALLEL*REDUCED*SYSTEM*STRESS'
QXWFRIDS ='RID OVFLO*NO RIDPOOL*STORAGE'
QXWFRIDT ='RID OVFLO*RIDS EXCEED*INTERNAL LIMIT'
QTGAFCNT ='FALSE*LOCK*UNLOCK*CONTENTIONS'
-Dataset DB2ACCTP new variables in DB2 V11.1:
QPACAACW='WAIT*DURATION*ACCELERATOR'
QPAC_PQS_WAIT='WAIT*DURATION*PAR QUERY*SYNC'
QPACAACC='WAIT*TRACES*ACCELERATOR'
QPAC_PQS_COUNT='WAIT*DURATION*PAR QUERY*SYNC'
-Dataset DB2ACCTW now outputs all segments in each record;
previously, only the first segment was output; there were
no new variables added by V11; this was discovered when
examining possible new variables!
-Dataset DB2STATS (from Subtype 0) new variables:
QWSDLRG ='HIGH USED*RBA ADDRESS*OF LOG'
QSST_RSMAX_WARN='TIMES*REALSTORAGE_MAX*WARNING*REACHED'
QSST_P64DISNUM='64-BIT*POOL*CONTRACTS'
QSST_P64DISBLK='64-BIT POOL BLOCKS*REQUIRED*DISCARD
QSST_P64DISPGS='64-BIT POOL PAGES DISCARDED'
QSST_CONTSTOR_NUM=31-BIT*POOLS*CONTRACTED*CONTSTOR'
QDSTNQMN='MIN QUEUED*DURATION*THIS PERIOD'
QDSTNQMX='MAX QUEUED*DURATION*THIS PERIOD'
QDSTNQAV='AVG QUEUED*DURATION*THIS PERIOD'
QDSTNCCW='QUEUED*CONNS*SOCKETS*CLIOSED*MAX WAIT'
-Dataset DB2STATB (from Subtype 1) new variables:
(where n=1,2,3,4 for the four groups of buffer vars)
QBnTSMIN='MIN*BUFFERS*ON SLRU'
QBnTSMAX='MAX*BUFFERS*ON SLRU'
QBnTHST ='TIMES WHEN*LEN OF*SLRU=VPSEQT'
QBnTRHS ='TIMES*RANDOM*GETPAGE*BUFFER HIT'
-Dataset DB2STATS (from Subtype 0) INPUT but NOT KEPT
QJSTSPNN &PIB.4.
QJSTSPNI &PIB.8.
QJSTCLID &PIB.4.
QJSTCL2 $EBCDIC2.
QJSTCLSN $EBCDIC10.
QJSTAVAL $EBCDIC128.
because all are documented as Serviceability without
any labels. They could be output using _KDB2ST0 macro.
-Dataset DB2STATS (from Subtype 1) new variables:
QISTI2AC='NON-SORT*DM*IN MEM*WKFILE*ACTIVE'
QISTI2AH='NON-SORT*DM*IN MEM*WKFILE*MAXIMUM'
QISTI2OF='TYPE-2*INMEM WFS*OVERFLOWS'
QISTIMNC='WF NOT*CREATED*DUE TO*CRITICAL*STORAGE'
QISTASTH='WFDB*AGENT USAGE*ALERT*THRESHOLD'
QISTSSTH='WFDB*SPACE USAGE*ALERT*THRESHOLD'
QISTAMXU='WFDB*MAX STORAGE*USED BY*ANY THREAD'
QISTWSTG='CURR WFDB*STORAGE*CONFIG*ALL TBLSP'
QISTDGTTSTG='WFDB*DGTT*PREFERRED*STORAGE'
QISTDGTTCTO='CURR*ALL AGENT*TOT STORAGE'
QISTDGTTMXU='MAX*ALL AGENT*TOT STORAGE'
QISTWFSTG='TOT*PREFER*STORAGE*CONFIG*IN WFDB'
QISTWFCTO='CURR*TOT*STORAGE*ALL WF*ALL AGENTS'
QISTWFMXU='MAX TOT*STORAGE*ALL WF*ALL AGENTS'
QISEKSPA8='STORAGE*ALLOCATED*SHAREABLE*SQL'
-Dataset DB2STATS (from Subtype 4) new variables:
QW0225_LMWRITE_REAL='LM*WRITE*BUFFER*BYTES*REAL'
QW0225_LMWRITE_AUX ='LM*WRITE*AUX?*RESERVED'
QW0225_LMCTRL_REAL ='LM*WRITE*CONTROL*BYTES*REAL'
QW0225_LMCTRL_AUX ='LM*WRITE*CONTROL*BYTES*AUX'
QW0225SC8='ALLOC*SHAREABLE*STORAGE*DYNAMIC SQL'
QW0225LS8='REQ*SHAREABLE*STORAGE*DYNAMIC SQL'
QW0225SX8='ALLOC*SHAREABLER*STORAGE*STATIC SQL'
QW0225HS8='HWM*REQ*SHAREABLE*STORAGE*DYNAMIC SQL'
-Dataset T102S106 new variable, added back in DB2 V10:
QWPBIMTZ='IMPLICIT*TIME*ZONE'
9999999=CURRENT
-9999999=SESSION
Other values, -779 to +840 represent -12:59 to +14:00
-Only these other ID=102 IFCIDs have been data-verified;
none were changed: 105, 199, 254, 261. Other IFCIDs for
V11 will need actual SMF data for update/validation.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 31.239 Values for MG073FE format values 07x,08x,11x,12x and 13x
FORMATS were corrected:
Nov 7, 2013 07X='07X:FEX8 AUTO@2GBPS'
08X='08X:FEX8 AUTO@4GBPS'
11X='11X:FE8XS AUTO@2GBPS'
12X='12X:FEX8S AUTO@4GBPS'
13X='13X:FEX8S OP@8GBPS'
Thanks to Pat Sheehan, FIS Technology.
Thanks to Kenneth Thornbrough, FIS Technology, USA
Change 31.238 Variable QAPLTFM (PLATFORM) added to TMMQQAA dataset.
VMACTMMQ
Nov 7, 2013
Change 31.237 The PCTIFLBY in datasets ASUMCELP and ASUMCEC incorrectly
VMXG70PR used the sum of IFLs allocated to all LPARS, which makes
Nov 6, 2013 no sense for these CEC-level datasets. It is corrected
to use the number of installed IFLs, NRIFLCPU, which is
also now stored in the count variables IFLCPUS/LPARCPUS.
Thanks to Julian Smailes, Experian, ENGLAND.
Change 31.236 DB2 Trace IFCID=196 now outputs sets of variables for up
VMAC102 to nine lock holders/waiters.
Nov 6, 2013
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 31.235 REPLACED MAR 27, 2014: See Change 32.073 which supports
VMACSMF reading from //SMF for VBS dumped data and/or //LOGGER.
VMXGINIT Original change text:
Nov 12, 2013 SMF Logstream DATA MIGHT be readable directly by MXG with
%LET READLSMF=0; in your //SYSIN.
which:
Changes the DCB for INFILE SMF to VB,32756,32760 inside
the _SMF macro that is defined in VMACSMF.
(Reading with VBS caused an IEC141I 013-A8 ABEND),
and the value in READLSMF is used for OFFSMF.
(This was coded when I thought perhaps OFFSMF=4 would
be required for the LOGGER, which is required to read
VSAM, but OFFSMF=0 with VB appear so far to work fine.)
-The SMF DD needs SUBSYS=(LOGR,IFASEXIT). The DCB on the
SMF DD is unimportant since what is set in _SMF is used.
Unfortunately, unlike VSAM that can be detected so the
normal MXG program reads either VSAM or BSAM dumped SMF
data, there is no way to detect the input is Logstream
Data, so you must use %LET READLSMF=0; to try to read!
-If you test this technique, please protect your job with
a TIME= parameter to ABEND if a CPU Loop occurs. An early
test did appear to CPU loop, but that case has NOT been
repeated in any subsequent tests.
-Reading the LOGGER file with either RECFM=VB or RECFM=U
and using INPUT;LIST; produces a SAS hex dump that does
NOT show a BDW nor RDW and it is possible that using
U or VB might be equally functional. Please report any
success OR FAILUREs to support at mxg.com and this change
text will be updated if more is discovered.
-A note posted to IBM-MAIN after MXG 31.08 was GA states:
We do not ship an official mapping macro for the SMF
buffers returned by a log stream browse. The intended
interface to get SMF records in log streams is IFASMFDL.
You can however IXGBRWSE the log stream and see the
buffers are returned in a consistent format, but this is
of course not supported by IBM.
In some cases the data returned by the log stream browse
has to be manipulated by SMF before the user sees it,
such as if zEDC compression is turned on in z/OS 2.1.
Thanks to Seighart Seith, FICUCIA, GERMANY.
Change 31.234 Final semicolon for one of the several LIBNAMEs was not
VGETDDS generated, but only if GDGs were involved. &EXOUT was
Nov 4, 2013 not always initialized; it is used to keep track of DDs
that were found in EXTFILES that may or may not be SAS
data libraries; if at the end it is non-zero length a
warning is produced showing the DDs that were found that
way. &INCR, used only for GDG, was not used in two %DOs.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.233 Correction for IMF 4.2 thru 5.1 WRONG VALUES IN CIMSTRAN.
VMACCIMS MXG code was misaligned, impacting these newer variables:
Nov 4, 2013 TRNEWLMC TRNOTCON TRNOTSTC TRNOTSOC TRNOTPRT TRNOTIP
TRNOTCLN TRNOTUSR TRNOTSTF TRNOTSYF TRNOTSLF TRNOTCLF
TRNOTSCF TRNOTCOR TRNOTCLP TRNMQMID
Also TRNOTCON is now formatted DATETIME21.2 and variables
TRNOTUSR, TRNOTSTC, TRNOTCLN, and TRNOTMAM are EBCDIC and
not $HEX formatted.
-This update also required VMXGINIT from 31.08 to support
&IMFMQ that was added by Change 31.206.
Thanks to Jan Tielemans, KBC, BELGIUM.
Change 31.232 ZRBDVT observations with DVTSAMPA=0 but non-zero ACTIVITY
EXZRBDVT in EXZRBDVT's definition were not output; these variables
VMACRMFV CONNTM PENDTM DISCTM DVBUSYTM CUBUSYTM SWPODLTM were set
Nov 3, 2013 to a missing value when DVTSAMPA=0, but some, plus CMRTM
were found to be non-zero even with DVTSAMPA=0. Now they
are always calculated, and all are included in ACTIVITY
so observations are output when ANY are non-zero. So, how
can there be activity with DVTSAMPA=0? All cases observed
were for TAPE devices and all were the last observation
for a VOLSER; some variables (CONNTM, DISCTM) were almost
equal to the DURATM. Presumably, this is activity for
the dismount of a VOLSER. This condition was discovered
when the new ASMRMFV DVTNOZEROIO option (Change 31.230)
wrote 607 records (of 1,932,611) that were not output by
the ACTIVITY test in EXZRBDVT.
-A cosmetic change was made in VMACRMFV so the ZRBxxxx
datasets are created in alphabetical order to make it
is easier to find how many obs were created in each.
Change 31.231 $MGSMFID format now decodes SMF ID=28 & ID=119 subtypes.
FORMATS
Nov 2, 2013
Thanks to MP Welch, Bank of America, USA.
Change 31.230 -RMF III Enhancements: BIG DISK SPACE SAVED in ZRBDVT.
ADOCRMFV -Enhanced DVT table filtering added as discussed below.
ASMRMFV -New parameters ZEROIO/NOZEROIO are added and are only
Nov 3, 2013 applicable to RMF Monitor III DVT processing by ASMRMFV.
Nov 7, 2013 -Alias for ZEROIO is ZIO and the aliases for NOZEROIO are
NOZIO or NZIO. The default is NOZEROIO.
-ZEROIO specifies output of all volume entries from the
DVT table to the RMFBSAM file regardless of I/O activity.
This was the ASMRMFV behavior in prior versions.
-NOZEROIO specifies output of only volume entries from the
DVT table to the RMFBSAM file that have I/O activity.
This is new default ASMRMFV behavior with this version.
THIS CHANGED THE ZRBDVT SIZE FROM over 66,666 cyl to less
than 14,000. Note that we also recommend that ASMRMFV use
PARM='NOSHD,NORED' to reduce the output size, and if you
are not planning on detail analysis of wait types, NOUWD
can be added for further space reduction.
-DSNTYPE=LARGE is now supported for the required RMFBSAM
output file as well as the optional RMFFILT and RMFSKIP
files
-A DVT volume entry in a MINTIME interval is considered to
HAVE I/O activity if ANY of the following I/O measures
are NON-ZERO using the DVT fields and calculations shown:
* Connect Time (DVTCOTIL-DVTCOTIF)
* Pend Time (DVTPETIL-DVTPETIF)
* Disconnect Time (DVTDISIL-DVTDISIF)
* I/O Queue Length (DVTIOQLC)
* Accumulated I/O Instruction Count (DVTSAMPA)
* Initial Command Response Time (DVTCMRIL-DVTCMRIF)
-Stated another way, if all of these I/O measures are zero
for a DVT volume entry and NOZEROIO is in effect the
entry is NOT output to the RMFBSAM file.
-During testing there was about a 93% reduction in DVT
output record volume with NOZEROIO in effect which also
improves performance during the PDB build. This may not
be typical and your results may vary.
-A second new filtering parameter only applicable to RMF
Monitor III DVT table processing is
DEVTYPE=ALL/DASD/TAPE.
-Aliases are DEVT= and DT=. The default is DEVTYPE=ALL
which provides the same behavior as earlier ASMRMFV
versions.
-DEVTYPE=ALL specifies that all DVT volume entries
regardless of device type are output to the RMFBSAM file.
-DEVTYPE=DASD specifies that only DVT volume entries for
disk devices are output to the RMFBSAM file. This
setting may be relevant for users only interested in disk
analysis from their PDB. Abbreviations for the DASD
value are DAS, DA, or D.
-DEVTYPE=TAPE specifies that only DVT volume entries for
tape devices are output to the RMFBSAM file.
Abbreviations for the TAPE value are TAP, TA, or T.
-DEVTYPE=DASD or DEVTYPE=TAPE may be used together with
NOZEROIO. In this case device type filtering occurs
before any zero I/O filtering.
-If both DEVTYPE=DASD and DEVTYPE=TAPE are specified only
the last occurrence takes effect.
-Enhancement for the Direct Method of running ASMRMFV is
discussed below.
-A new keyword MAXDSNAMES= is provided to allow user
specification of the number of entries in the dsname
table to contain INDSNAME= patterns when the Direct
Method is used with ASMRMFV. Aliases for MAXDSNAME= are
MAXDSNAME=, MAXDSN=, or MAXDS=.
-Prior to the addition of MAXDSNAMES= the only way to
change dsname table size was by a source change to
ASMRMFV followed by a re-assembly and re-link. The
dsname table was integrated as part of the program but
now resides in a separate memory area.
-MAXDSNAMES=nnnn specifies the number of entries to be
allocated in the dsname table. nnnn is an integer
ranging from 1 to 9999. The default is MAXDSNAMES=256.
Each dsname entry requires 44 bytes.
-While MAXDSNAMES=9999 is the maximum value supported by
ASMRMFV, in reality a realistic value is the maximum
number of TIOT entries supported by z/OS for single unit
DD statements.
-Initial ASMRMFV RMFV001I messages that show the current
execution environment are enhanced to show the TIOT SIZE
as defined in the ALLOCxx member in PARMLIB (shown as
TIOT SIZE=nnK), the maximum number of single unit DD
statements possible with that TIOT size (shown as
MAXDD=nnnn), and the number of DD statements used at the
start of ASMRMFV execution (shown as USEDD=nnnn).
-The actual maximum number of entries allowed for
MAXDSNAMES=nnnn is the value for MAXDD= less the value
for USEDD=. If MAXDSNAMES=nnnn exceeds this value it is
set instead to the result of MAXDD - USEDD.
-MAXDSNAMES=MAX may be specified instead and the result is
the number of dsname entries calculated as just described
above.
-NOTE: If MAXDSNAMES=nnnn or MAXDSNAMES=MAX is specified,
it MUST appear before ANY INDSNAME= parameters appear.
The first INDSNAME= option triggers the allocation of the
dsname table and the number of entries cannot then be set
later.
-New message RMFV038I appears when a dsname table is
allocated showing the number of dsname entries and size
in bytes.
-New second message RMFV038I appears when a dsname table
is freed or exhausted showing the number of entries
available/used and the percentage used.
-A second 32K output buffer used for filtering only has
been added. Any tables written to the optional RMFFILT
DD will be blocked just as if they were written to
RMFBSAM.
-NOZEROASI and NOZERODVT options were not always properly
shown in the RMFV037I options list message.
-Messages RMFV006I for filters and RMFV037I for options
are updated to show the new NOZEROIO and DEVTYPE=
parameters.
-Message RMFV007S had an incorrect value for Reason Code
when a GETMAIN, FREEMAIN, or DLVRP service error
occurred. These services do not issue a Reason Code
(only a Return Code) so this field is set to blanks in
these cases.
-Fixed a S0C4 Abend when the FROMDATE= value exceeded the
TODATE= value. ASMRMFV was attempting to read past the
SYSIN end of file when it should have terminated parm
processing. The same issue could occur if FROMTIME=
exceeded TOTIME= where FROMDATE= and TODATE= were the
same date.
-ASMRMFV now supports keywords up to 11 characters in
length for future development.
-NOTE: The prior suggestion for initial setting of ASMRMFV
parameters for new users was PARM='NODVT'. However, now
that a large percentage of DVT volume entries with zero
I/O activity can be filtered out with NOZEROIO by
default, that suggestion is changing.
-Instead use PARM='NOSHD,NORED' in JCL (or NOSHD NORED in
SYSIN). The MXG distributed EXZRBSHD and EXZRBRED output
exits for VMACRMFV suppress the respective SAS data sets
from being created later in the PDB build because they
contain only control data not useful for analysis.
Excluding these tables in ASMRMFV processing will reduce
PDB build overhead by not creating SHD and RED table
output in the RMFBSAM file in the first place.
-NOTE: If you do not plan to develop your own USE/WAIT
analysis by type of WAIT, you can also use add NOUWD to
the PARM= or SYSIN file to further reduce PDB build
overhead.
-The ASMRMFV source prologue as well as the ADOCRMFV
documentation member are updated appropriately.
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change must
be installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Thanks to Peter Gray, HP Australia, for the DSNTYPE=LARGE suggestion.
Change 31.229 -Documentation. Regarding the inconsistent interval data
VMACXAM DURATION (seconds) mentioned, contact VELOCITY SOFTWARE
Oct 25, 2013 for a band-aid "fix" with your zWRITE data-collection
script. Explain that you want to see consistent
15-minute interval data for the entire 24-hour period.
This would be akin to the IBM RMF SYNC(59M|00M) option.
-Also, you want to be up-to-date on VELOCITY zWRITE/zVPS
maintenance, that being at least PROD4142 to address some
instances when not all data was being flushed from the
in-memory buffers at zWRITE data-close (typically
end-of-day) time.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.228 IMS zIIP CPU time is created in IMF CIMSTRAN dataset as
VMACCIMS CPUZIPTM=TRXZTCPU-TRXZONCP;
Oct 25, 2013
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.227 These report members failed after the default argument
ANALAVAI PDB= was changed to &PDBMXG, which fails due to timing of
ANALBLSR macro variable resolution. This example shows the problem
ANAL72GO and that a direct circumvention requires THREE periods to
Oct 23, 2013 properly resolve to PDB.TYPE72GO:
Nov 12, 2013 %MACRO TESTIT(PDB=&PDBMXG);
%LET A=&PDB..TYPE72go;
%LET B=&PDB...TYPE72go;
%PUT A=&A;
%PUT B=&B;
%MEND TESTIT;
%TESTIT;RUN;
Why only these three, when MANY of the %MACRO members in
MXG have the same syntax? Because all of the others have
a %LET PDB=%UPCASE(&PDB); statement after the %MACRO, and
that (accidentally?) circumvents the macro timing, so if
these three had been properly created with the %UPCASE,
this peculiarity would not have been observed.
-ODS Graphics likes to override time formats with DATETIME
formats. YAXIS statement inserted to force it to use
the format as specified in the data. Nov 12 update.
Change 31.226 Support for Alebra Parallel Data Mover USER SMF record
EXTYPDM Performance Record creates TYPEPDM dataset:
IMACPDM dddddd Dataset Description
TYPEPDM TYPDM TYPEPDM Alebra PARALLEL DATA MOVER
TYPSPDM
TESSUSR1
VMACPDM
VMXGINIT
Oct 23, 2013
Change 31.225 Support for Emtex JESConnect product's SMF Performance
EXTYJESC Record creates TYPEJESC dataset:
IMACJESC dddddd Dataset Description
TYPEJESC TYJESC TYPEJESC JES2 CONNECT
TYPSJESC -VMXGIPV4 is created to convert IPV4 $CHAR4 fields into
TESSUSR1 dotted IPV4 text IP Address, similar to VMXGIPV6.
VMACJESC
VMXGIPV4
VMXGINIT
Oct 23, 2013
Thanks to Larry Stahl, IBM Global Services, USA.
Change 31.224 WPS Version 3.0 QA tests found these incompatibilities:
ANAL80A -INFILE operand TERMSTR, set in macro variable &MXGCRLF to
ANALAVAL CR/CRLF/LF for ASCII in VMXGINIT, to define the end of
ANALPATH line delimiter for input data files that can be either
ANALTAPE PC or Unix format, is not supported in WPS, so it is now
TYPESVC set only for execution under SAS. Currently, it is used
UTILEXCL only in TYPERACF, TYPETAPR and TYPEWWW.
VMXGINIT -In WPS, PROC APPEND BASE=PDB.CICSDICT NEW=CICSDICT; does
Oct 22, 2013 not propagate the Data Set Label from CICSDICT when the
BASE does not exist, while SAS does propagate that Label.
Using BASE=PDB.CICSDICT (LABEL='CICDIC: CICS DICTIONARY')
NEW=CICSDICT; also does not work with WPS while it does
work under SAS. So, an extra DATA step was needed after
the PROC APPEND to label the dataset.
(The absence of the Data Set Label caused the MXG QA job
to complain in DOCVER when the label was not found.)
-TYPESVC/TYPSSVC - WPS does not support NAMED INPUT.
-ANAL80A - WPS does not support PROC REPORT.
-ANALAVAL- WPS does not support PROC CALENDAR.
-ANALMPL,ANALTAPE - WPS does not support VREVERSE in PLOT.
-ANALPATH- WPS doesn't support OVERPRINT in PUT statement.
Change 31.223 CICS variable WMQASRTM is added into the CPUTM variable
VMAC110 in CICSTRAN datasets; back in CICS/TS 4.1 IBM added the
Oct 20, 2013 field (WMQASRBT, clock and count) and documented it:
The WebSphereMQ SRB time this transaction spent
processing MQ API requests. This field is zero for
point-to-point messaging activity, but is non-zero if
MQ API requests result in publish and subscribe type
messaging. Note: WebSphere MQ only returns this value
to CICS when MQ Class 3 accounting information is being
collected in WebSphere MQ. To collect the MQ Class 3
accounting info, START TRACE(ACCTG) DEST(SMF) CLASS(3)
must be issued in WebSphere MQ.
This SRB CPU time is already included in the CPUTCBTM in
the SMF 30s for the CICS region.
Note: VMAC110/UTILEXCL/DOCVER have these MQ variables
MQGETWTM MQGETWCN MQREQS MQWTCBUS MQQONTCPU MQREQUS
that were originally decoded in 2003 in Change 21.212,
from CMODNAME='MQSERIES' and CMODHEAD='MQGETW/MQREQS/
MQWTCBUS/MQONTCPU/MQREQUS' but I can not find any of
those names in CICS Data Areas, nor have those names
appeared in any CICS Dictionaries in recent versions so
I presume they are no longer created, and the newer
WMQGETTM WMQGETTM WQMREQCT WMQASRTM WMQASRCN variables
have replaced the 2003 variables. They exist in DOCVER
only because I force them to be part of the MXG QA, and
since they are ONLY created by UTILEXCL and ONLY IF the
CMODHEAD/CMODNAME are found, it is unlikely they will
even exist in your CICSTRAN dataset.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.222 INPUT STATEMENT EXCEEDED RECORD for RMF III SPG record if
VMACRMFV the system had more than 1361 devices; NRVOLSTV=1674 was
Oct 19, 2013 used for the VOL count, but that is the total number of
VOLs in ALL SPG records. Instead, SPGVOLNR is the count
of vols in this record, and is now used for the loop.
Thanks to MP Welch, Bank of America, USA.
Change 31.221 Revisions to ODS support. Revised VMXGODSO/ODSC members
ANAL72GO and to the programs that use them.
ANALACTM -VMXGODSO (Open ODS destination) now supports TYPE=PDF
ANALAVAI and passes the ODSTYPE to VMXGODSC.
ANALDB2B -VMXGODSC now actually correctly closes the current ODS
ANALGRID destination and restores the original ODS settings using
ANALHTML two new user-supplied parameters:
ANALID ODSORIGTYPE= the type of ODS output you want set after
ANALIDMS close. If you leave it blank, it will
ANALINIT revert to HTML on ASCII and to LISTING
ANALNAT in all other cases.
ANALNATR ODSORIGFILE= if you want to direct the output after
ANALPKGS close to a specific destination; can be
ANALRAID blank
ANALRANK -ANAL72GO adds the ODSORIGTYPE and ODSORIGFILE parameters
ANALS225 for VMXGODSC and also adds ODS GRAPHICS if you are on SAS
ASUMRAID 9.3 or greater and only uses SAS/GRAPHS for earlier SAS
GRAFCEC versions (if SAS/GRAPH is detected) and WPS.
GRAFRAID -ANALACTM. Added ODSORIGTYPE and ODSORIGFILE parameters
GRAFRMFI for VMXGODSC. The report of the WLM configuration needs
GRAFWRKX landscape orientation; to make that happen with TYPE=PDF
VGETWKLD the OPTIONS ORIENTATION=LANDSCAPE; statement is added
VMXG2DTE before the ODS PDF statement. Since ORIENTATION is an
VMXGODSC option in the format NAME=VALUE, which was not previously
VMXGODSO used in VMXGOPTR, it was also revised to support it.
VMXGOPTR -ANALAVAI. Adds the ODSORIGTYPE and ODSORIGFILE parameters
VMXGRMFI for VMXGODSC and corrects a macro variable resolution
Nov 2, 2013 problem discovered in testing.
Dec 8, 2013 -ANALDB2B. Adds the ODSORIGTYPE and ODSORIGFILE parameters
for VMXGODSC.
-ANALGRID. VMXGODSO/VMXGODSC execution is now conditional
so you can combine the output of ANALGRID in a single
file with other reports and graphs, such as:
%VMXGODS(TYPE=PDF,FILE=MYREPORT.PDF);
%ANALGRID(ODSTYPE=NO,other parameters);
PROC SGPLOT;
etc...
%VMXGODSC;
-ANALHTML. Adds the ODSORIGTYPE and ODSORIGFILE parameters
for VMXGODSC.
-ANALID. If you invoked ANALID without running TYPEID,
it would fail without really telling you why because it
could not find the _WTYID _LTYID datasets. Now if it
detects that TYPEID has not been run it automatically
includes VMACID to create those macros.
-ANALIDMS. Adds the ODSORIGTYPE and ODSORIGFILE parameters
for VMXGODSC.
-ANALINIT. Adds the ODSORIGTYPE and ODSORIGFILE parameters
for VMXGODSC, and some reformatting for PDF output.
-ANALNAT and ANALNATR. PLOTs changed to SGPLOT. Comments
added to show how to create PDF output as well as HTML.
-ANALPKGS. PDF comments added and HTML commented so that
you can choose which you prefer
-ANALRAID. Added ODSORIGTYPE and ODSORIGFILE parameters
for VMXGODSC. Modified for PDF output.
-ANALRANK. Adds the ODSORIGTYPE and ODSORIGFILE parameters
for VMXGODSC. Reduce to a single report.
-ASUMRAID modified for use with VMXGODSO and VMXGODSC. Now
makes GRAFRAID obsolete since it creates the same output
using HTML or PDF, but does it without SAS/GRAPH.
-ANALS225. Uses DB2STATS as input since the IFCID=225 data
in completely contained in PDB.DB2STATS datasets and the
T102S225 is not created. DB2 interval records are now
created every minute (cannot be changed) so the revised
report provides for summarization to any chosen interval.
ODSORIGTYPE and ODSORIGFILE parameters added.
-GRAFCEC modified to use VMXGODSO and VMXGODSC for HTML
or PDF and to use SGPLOT when on SAS 9.3 or higher.
-GRAFRAID - marked as obsolete. ASUMRAID creates the same
output more cleanly and without requiring SAS/GRAPH if
you use PDF or HTML.
-GRAFRMFI modified to use VMXGODSO and VMXGODSC for HTML
or PDF and to use SGPLOT when on SAS 9.3 or higher.
-GRAFTAPE. Adds the ODORIGTYPE and ODSORIGFILE parameters
for VMXGODSC and adds ODS GRAPHICS if you are on SAS 9.3
or later, and uses SAS/GRAPH for earlier SAS and WPS.
-GRAFWRKX (hourly bar chart of each workload in RMFINTRV)
now uses and describes each of the SGPLOTs; ODSORIGTYPE
and ODSORIGFILE added to parameters for VMXGODSC.
Dec 8: ODS statement parameter ODSSTYLE added pointing at
STYLES.MXGSTYLE1.
-VMXG2DTE. Option added to CYCLE parameter to enable tests
at any time. CYCLE=FORCE will override the input DD in
the MTD database.
-VMXGOPTR. Enhanced to handle options where the format is
OPTION optionname=value (LINESIZE PAGESIZE VMXGOPTR),
needed for ODS TYPE=PDF when landscape is desired.
-VGETWKLD modified to end if no workloads are found and
fill in all macro variables expected downstream.
-VMXGRMFI trend logic modified to stop if no workloads are
found.
-VMXGODSO Dec 8, 2013: Cleanup and realignment of code and
added new ODSSTYLE= argument (especially for PDF output).
Change 31.220 Enhancement to CRYPTOGRAPHIC PROCESSOR support.
VMAC7072 -TYPE7002 dataset variables R702ASDC R702ASDB R702ASDI
Oct 16, 2013 were misspelled (R702AEDC,R702AEDB,R702AEDI).
-IBM RMF Report tokens for the OVERVIEW/EXCEPTION reports
are now added as variables to the crypto datasets:
TYPE7002 - PCCIC
CRYCKR='COPROCESSOR*KEY-GEN*RATE'
CRYCTE='COPROCESSOR*TOTAL*AVG EXECUTE*TIME'
CRYCTR='COPROCESSOR*TOTAL*RATE'
CRYCTU='COPROCESSOR*TOTAL*PCT UTILIZATION'
TYPE70X2 - PCICA
CRYAC1E='ACCELERATOR*1024BIT-CRT*AVG EXECUTE*TIME'
CRYAC1R='ACCELERATOR*1024BIT-CRT*RATE'
CRYAC1U='ACCELERATOR*1024BIT-CRT*PCT UTILIZATION'
CRYAC2E='ACCELERATOR*2048BIT-CRT*AVG EXECUTE*TIME'
CRYAC2R='ACCELERATOR*2048BIT-CRT*RATE'
CRYAC2U='ACCELERATOR*2048BIT-CRT*PCT UTILIZATION'
CRYAC3E='ACCELERATOR*4096BIT-CRT*AVG EXECUTE*TIME'
CRYAC3R='ACCELERATOR*4096BIT-CRT*RATE'
CRYAC3U='ACCELERATOR*4096BIT-CRT*PCT UTILIZATION'
CRYAM1E='ACCELERATOR*1024BIT-ME*AVG EXECUTE*TIME'
CRYAM1R='ACCELERATOR*1024BIT-ME*RATE'
CRYAM1U='ACCELERATOR*1024BIT-ME*PCT UTILIZATION'
CRYAM2E='ACCELERATOR*2048BIT-ME*AVG EXECUTE*TIME'
CRYAM2R='ACCELERATOR*2048BIT-ME*RATE'
CRYAM2U='ACCELERATOR*2048BIT-ME*PCT UTILIZATION'
CRYAM3E='ACCELERATOR*4096BIT-ME*AVG EXECUTE*TIME'
CRYAM3R='ACCELERATOR*4096BIT-ME*RATE'
CRYAM3U='ACCELERATOR*4096BIT-ME*PCT UTILIZATION'
TYPE70Y2 - CPACF
CRYIADO='AVG TIME*COPROCESSOR*CALLS*AES*DECRYPT'
CRYIADR='RATE*OF*AES*DECRYPT*SERVICE*CALLS*SENT'
CRYIADS='AVG BYTES*PER*AES*DECRYPT*SERVICE*CALL'
CRYIAEO='AVG TIME*COPROCESSOR*CALLS*AES*ENCRYPT'
CRYIAER='RATE*OF*AES*ENCRYPT*SERVICE*CALLS*SENT'
CRYIAES='AVG BYTES*PER*AES*ENCRYPT*SERVICE*CALL'
CRYIH2I='INSTR*TO*HASH*DATA*SHA-224*SHA-256*ALGO'
CRYIH2R='HASHING RATE*SHA-224*SHA-256*ALGORITHM'
CRYIH2S='HASHING SIZE*SHA-224*SHA-256*ALGORITHM'
CRYIH5R='HASHING RATE*SHA-384*SHA-512*ALGORITHM'
CRYIH5S='HASHING SIZE*SHA-384*SHA-512*ALGORITHM'
CRYIHAI='INSTR*TO*HASH*DATA*SHA-1*ALGORITHM'
CRYIHAR='HASHING RATE*SHA-1*ALGORITHM'
CRYIHAS='HASHING SIZE*SHA-1*ALGORITHM'
CRYIMGI='INSTR*TO MAC*GENERATE'
CRYIMGR='MAC*GENERATION*RATE'
CRYIMGS='MAC*GENERATION*SIZE'
CRYIMVI='INSTR*TO MAC*VERIFY'
CRYIMVR='MAC*VERIFY*RATE'
CRYIMVS='MAC*VERIFY*SIZE'
CRYIPTR='PIN*TRANSLATION*RATE'
CRYIPVR='PIN*VERIFY*RATE'
CRYISDDI='SINGLE*DES*INSTR*DECIPHER*THE*DATA'
CRYISDDR='SINGLE*DES*DECRYPT*RATE'
CRYISDDS='SINGLE*DES*DECRYPT*SIZE'
CRYISDEI='SINGLE*DES*INSTR*ENCIPHER*THE*DATA'
CRYISDER='SINGLE*DES*ENCRYPT*RATE'
CRYISDES='SINGLE*DES*ENCRYPT*SIZE'
CRYITDDI='TRIPLE*DES*INSTR*TO*DECIPHER*THE*DATA'
CRYITDDR='TRIPLE*DES*DECRYPT*RATE'
CRYITDDS='TRIPLE*DES*DECRYPT*SIZE'
CRYITDEI='TRIPLE*DES*INSTR*TO*ENCIPHER*THE*DATA'
CRYITDER='TRIPLE*DES*ENCRYPT*RATE'
CRYITDES='TRIPLE*DES*ENCRYPT*SIZE'
TYPE70Y3 - CE4XP
CRYPAGE='GENERATION*ASYMMETRIC-KEY*AVG EXEC TIME'
CRYPAGR='GENERATION*ASYMMETRIC-KEY*RATE'
CRYPAGU='GENERATION*ASYMMETRIC-KEY*PCT UTILIZATION'
CRYPFAE='FAST*ASYMMETRIC-KEY*AVG EXEC TIME'
CRYPFAR='FAST*ASYMMETRIC-KEY*RATE'
CRYPFAU='FAST*ASYMMETRIC-KEY*PCT UTILIZATION'
CRYPSAE='SLOW*ASYMMETRIC-KEY*AVG EXEC TIME'
CRYPSAR='SLOW*ASYMMETRIC-KEY*RATE'
CRYPSAU='SLOW*ASYMMETRIC-KEY*PCT UTILIZATION'
CRYPSCE='COMPLETE*SYMMETRIC-KEY*AVG EXEC TIME'
CRYPSCR='COMPLETE*SYMMETRIC-KEY*RATE'
CRYPSCU='COMPLETE*SYMMETRIC-KEY*PCT UTILIZATION'
CRYPSPE='PARTIAL*SYMMMETRIC-KEY*AVG EXEC TIME'
CRYPSPR='PARTIAL*SYMMETRIC*RATE'
CRYPSPU='PARTIAL*SYMMMETRIC-KEY*PCT UTILIZATION'
CRYPTE='PKCS11*COPROCESSOR*AVG EXEC TIME'
CRYPTR='PKCS11*COPROCESSOR*TOTAL*RATE'
CRYPTU='PKCS11*COPROCESSOR*TOTAL*PCT UTILIZATION'
Thanks to David Wilbur, State of Washington CTS, USA.
Thanks to Steve Majerick, State of Washington CTS, USA.
Change 31.219 -If you only want to know which character variable(s) in
VMXGSRCH which dataset(s) contains a text string, RESULTS=COUNT
Oct 15, 2013 produces the simple report of names and counts.
-Specifying RESULTS=PRINT prints all variables in those
found observations (printing the first NOBS observations
with both variable name and label as heading) and now
also produces the COUNT report after the prints.
-A log message is printed when observations are found.
-The VALUE= argument does not need to be the exact value
of a variable. VALUE=XYZ will find XYZ123 or ABCXYZ or
any variable that has XYZ anywhere in its value.
Change 31.218 INVALID DATA FOR SCACTIME in ID=119 SUBTYPE=32 because
VMAC119 variable SCORIGIN was overlooked and not INPUT causing
Oct 10, 2013 the misalignment by one byte.
Thanks to Thomas Heitlinger, Fiducia IT AG, GERMANY.
Thanks to Sieghart Seith, Fiducia IT AG, GERMANY.
Thanks to Dennis Gaertner, Fiducia IT AG, GERMANY.
Change 31.217 Support for CICS "multi journal records" adds examples in
EXCICJRN the EXCICJRN member to decode multiple journals to create
Oct 10, 2013 multiple datasets from different journal records. You
would copy the example EXCICJRN member into your "USERID"
MXG tailoring library, then comment out its default code
block, un-comment and modify its "multi" example code to
create and output your variables into CICSJOUR, then copy
the MACRO _SCICJRN and MACRO _KCICJRN definitions into
IMACKEEP in your tailoring library, to define which of
the WORK.CICSJOUR variables are output into which of your
new datasets. Then your SYSIN program would be:
%LET MACFILE=
%QUOTE( IF ID=110 AND SUBTYPE=0; );
%INCLUDE SOURCLIB(TYPE110);
_SCICTRN
RUN;
if you ONLY want to process the Journal Records.
Thanks to Paul Bennett, Euroclear, BELGIUM.
Change 31.216 INVALID DATA FOR S42CSYNC because it is not an SMFSTAMP8
VMAC42 value, instead containing a nonstandard 2013281F0916483F
Oct 10, 2013 format that is now "hand" decoded to 08OCT2013:9:16:48.3.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 31.215 New variables added to TYPETLMS are now supported:
VMACTLMS BACODLVL='ENHANCED*CODE*LEVEL*03X'
Oct 7, 2013 BAKEYIDX='ENCRYPTION*KEY*INDEX'
BAPCTCMP='PCT*OF COMPACT*FOR FILE'
BAPCTFIL='PCT*VOLUME*USED*BY FILE'
BAUSQFIL='USAGE*SEQUENCE*FOR FILE'
Thanks to Scott Barry, SBBWorks Inc, USA.
Thanks to Yves Cinq-Mars, IBM Global Services, CANADA.
Change 31.214 CICS dataset CICSJS variables SJSMAJCP and SJSMINCP in
VMAC110 statistics dataset CICSJS were incorrectly documented and
Oct 3, 2013 labeled as CPU time so MXG input them as such, but IBM
now confirms that they are elapsed time in milliseconds
in the record, so both are now correctly input, labeled
(TOTAL*ELAPSED*TIME IN MAJOR/MINOR GARBAGE COLLECTION)
and formatted TIME13.3 to display the millisecond as the
final digit in the decimal place.
Thanks to Mark Wittie, Fidelity Institutional, USA.
Thanks to Warren Cravey, Fidelity Institutional, USA.
Thanks to Paul Albrecht, Fidelity Institutional, USA.
Change 31.213 MXG 31.06-31.07 only, and only if syntax of 102.xxx was
UTILBLDP used to select ID=102 records by IFCID/SUBTYPE. Errors
Oct 4, 2013 for old-style MACRO _V102xxx were printed on the log.
Introduced in Change 31.184.
Change 31.212 New (internal) parameters SPINTAPE and NOEXIMSG added.
ANALDB2R -SPINTAPE=YES will cause VGETOBS to read an input SAS data
VGETOBS library when it is on tape/sequential format, building
Oct 18, 2013 the MXGTABLES dataset that list all SAS datasets on the
tape. Used now in ANALDB2R but available to other MXG
utilities. Normally, the MXGTABLES is used and then
discarded by VGETOBS, but with this parameter it is kept.
Default for SPINTAPE is NO in VGETOBS, set by caller.
-Option DATASET=_ALL_ will also cause MXGTABLES to be kept
for use in subsequent internal utilities.
-NOEXIMSG=NO (default) added to suppress messages when the
input datasets are on tape, after the first time that DD
is encountered.
-ANALDB2R exploits this new VGETOBS to snapshot a list of
all of the datasets found in the first libname in PDB=,
whether it is on tape or disk, and then builds a MACRO
variable with that list of available datasets, avoiding
the earlier design that required many executions of the
VGETOBS macro, potentially eliminating many tape mounts.
Change 31.211 ANALHSM exploited the fact that SAS will always look for
ANALHSM the last dataset created when doing a SORT or PRINT. But
Sep 26, 2013 the latest changes to VGETOBS now create a temporary
dataset that intervenes and disappears so the explicit
dataset to be sorted/printed had to be specified.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 31.210 Variables R744SATM,R744SDTM,R744SQTM,R744SSTM are in
VMAC74 seconds per event, but that was not obvious. Their label
Sep 25, 2013 now contain *SECONDS*PER....' and are formatted 8.6.
So a value of 0.000094 is 94 microseconds per ....
Thanks to Cesar V Cocco, CitiCorp, USA.
Change 31.209 -If you specified PDB=YES and used the LDB2xxxx parameters
READDB2 to reroute the output datasets, there was a failure when
CLEARDB2 looking for the YES DDNAME in VGETOBS. Should have been
Sep 27, 2013 pointing to the PDB2xxxx specific MACRO VARIABLE rather
than PDBOUT.
-Specifying STATS/STATISTICS but then Suppressing one of
the statistics datasets caused DATASET NOT FOUND errors;
now if a required dataset is not present, DB2STATS won't
be created but the READDB2 won't terminate with an error.
Not all old style macros defined in VMACDB2 were cleared.
This could cause many strange errors, but ONLY if there
were multiple executions of READDB2 in the same session,
e.g., the MXG QA Test stream. This change was found when
many additional %READDB2 QA tests of previously reported
errors were added to the QA stream.
-%TRIM and %QCMPRES %MACRO functions were replaced by
these %SYSFUNC calls to use COMPBL as those %MACRO
functions did not always work correctly and caused
errors where macro variables exceeded the 64K limit.
In addition, elimination of %TRIM and %QCMPRES removes
the past issues with incorrect SASAUTOS allocations.
%LET IDREADS=%SYSFUNC(COMPBL(&IDREADS 102));
%LET IDREADS=%QCMPRES(&IDREADS 102);
%LET IDREADS=%SYSFUNC(COMPBL(&IDREADS 102));
%LET IDREADS=%QCMPRES(&IDREADS 102);
Change 31.208 -ASUM113 variables LPARBUSY and MIPSEXEC were wrong for
ASUM113 the zEC12 processor; they should be divided by DELTASUM
Sep 24, 2013 and not DELTATM in those equations for the processor
Thanks to Andrew Hebden, Barclays, ENGLAND.
Change 31.207 -MXG 31.07. Debugging PUT statement in VMAC6 printed
VMAC6 SMF6LN3=162 LENLEFT=552 for every SMF 6 record.
Sep 24, 2013
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 31.206 -Support for IMF 5.1 (INCOMPATABLE, but only impacting the
VMACCIMS CIMSDBDS dataset; other existing datasets are unchanged.)
EXIMFMQ -New variables added to CIMSDBDS dataset:
IMACCIMS DBTDBVER='DB*VERSION'
VMXGINIT DBTFLOVF='FALSE*OVERFLOW*OCCURRED?'
FORMATS -New CIMSMQ dataset contains these MQ variables:
Sep 23, 2013 MQSSID ='MQSSID' MQGET ='MQGET*CALLS'
MQBACK ='MQBACK' MQINQ ='MQINQ '
MQCLOSE ='MQCLOSE' MQOPEN ='MQOPEN'
MQCMT ='MQCMT' MQPUT ='MQPUT*CALLS'
MQCOMM ='MQCONN' MQPUT1 ='MQPUT1*CALLS'
MQDISC ='MQDISC' MQSET ='MQSET*CALLS'
MQFLG1 ='MQFLAG1' MQUNKN ='MQUNKN'
Change 31.205 A graphical analysis of Latent Demand, based on Tivoli's
ANALATEN discussion found at:
Sep 21, 2013 HTTP://PUBLIB.BOULDER.IBM.COM/TIVIDD/TD/TDS390/
SH19-6818-08/EN_US/HTML/DRLM9MST50.HTM
Mar 22, 2014: Check for postings in archives and try:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/
/BOOKS/DRL5FS09/3.3.3?DT=20100105101315
====== Changes thru 31.204 were in MXG 31.07 dated Sep 20, 2013=========
Change 31.204 Change 31.200 (VGETOBS enhancement) stumbles with PDB=PDB
ANALDB2R if the data library that contains all of the DB2 datasets
Sep 19, 2013 is on tape. While that is, in general, bad practice, as
a mount and read is required for EVERY dataset needed by
your ANALDB2R request, it previously worked and will in
the near future, but for now, if your PDB is on tape and
you used ANALDB2R(PDB=PDB), this circumvention will avoid
the error (UNINIT variables messages, then other errors).
%ANALDB2R(PDB=WORK,DB2ACCT=PDB,USEACCT=YES,PMSTA02=NO,
PMSPR01=NO);
%ANALDB2R(PDB=PDB,STATSUSE=DETAIL,PMACC01=NO,
PMACC02=NO);
Please contact support@mxg.com to request CHANGE 31.204
when it is available.
This change is only documentation as of this date.
Thanks to John Schoenbeck, IBM Global Services, USA.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 31.203 -TYPE70 calculations of SHARE values were wrong if there
VMAC7072 were IFL engines in the CEC, because MXG output those IFL
VMXG70PR engines in TYPE70EN/EC/FORRMFI datasets and those SHAREs
Sep 23, 2013 values for the IFLs were incorrectly included in the z/OS
SHARE calculations. Only if IFLs are shared are there
non-zero SHARE values.
-ASUM70PR count of LPARIFLS in PDB.ASUM70LP/PDB.ASUMCELP
was wrong (larger than NRIFLCPU) if there were multiple
RMF intervals for the same summary INTERVAL, as when RMF
was stopped/started/changed.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 31.202 -Variable SM120AD4 was a missing value because AD3 and AD4
VMAC120 are 16-byte fields with 8-low order bytes of nulls and
Sep 18, 2013 MXG did not skip the AD3 low order bytes.
-But my data does not match the documentation. Following
SM120AD4 there is an 8-byte undocumented field containing
'FFFFB62000000000'X (-19830.66931 decimal) that looked to
be a GMT OFFset, but SM120ACD 'FFFFBCF10CC00000'X has the
correct value of -18000.85 for the -5 hour timezone so I
have no idea what that value actual is; it is input into
SM120TZX but not kept nor used. After that field there
are 24 reserved bytes.
Thanks to Mark Wittie, Fidelity Institutional, USA.
Change 31.201 Support for APAR OA40376 for z/OS 1.3 adds variables to
VMAC74 SMF 74 Subtype 5 RAID Rank/Extent Pool data; these vars
Sep 18, 2013 were added in z/OS 2.1 but overlooked previously:
R7451ZHL='ZHPF*LIST PREFETCH I/O REQUESTS'
R7451ZHH='ZHPF*LIST PREFETCH I/O HITS'
R7451GSF='GLOBAL*MIRROR*COLLISIONS*SIDEFILE'
R7451GSS='GLOBAL*MIRROR*COLLISIONS*SYNCHRONOUS'
APAR OA42682 adds BIT 4 value to R744FFLG.
Thanks to Lou Horton, NYS Office of Info Technology, USA.
Change 31.200 MXG 31.06 READDB2 could still fail on z/OS only, mostly
VGETOBS due to the IFCID=225 which has a unique requirement to
VMXGWORL use VMXGWORL, but recent changes to VGETOBS, which now
Sep 18, 2013 always returns the DSN of all sequential format datasets,
confused VMXGWORL which incorrectly used the _L102225
token instead of _W102225. Now, VGETOBS passes SEQ back
in the VGETMTYP macro variable, which, when detected,
redirects VMXGWORL to use the _W rather than the _L, that
might not exist. If the _W doesn't exist, then the _L
will be used, but if it does not exist, then there will
be a dataset not found failure.
-The incorrect note in comments in 31.06 READDB2 that the
PDB=XXX option of READDB2 required DISK was incorrect
and has been removed.
-Perhaps in our defense of this error:
The 31.06 VGETOBS solved two very different problems:
1. WPS failed when there was no LIBNAME when there was a
WHERE clause on PROC SQL read of DICTIONARY.TABLES.
Solved by looking at DICTIONARY.FILENAMES without a
WHERE first to see if the DD even exists.
2. SAS mounting and rereading every tape with every
execution of VGETOBS reading DICTIONARY.TABLES, even
when there was NO where clause.
Solved by keeping track of tape DDs and excluding
them from DICTIONARY.TABLES searches with a WHERE
CLAUSE NE.
-Solving problem 2 cut tape mounts in daily CICS/DB2 job
at one site from over 90 to less than 20.
Thanks to John Schoenbeck, IBM Global Services, USA.
Change 31.199 Variable S17NNDM was added to the BY list _B117NOD macro
VMAC117 to order by NODE name and to fully remove duplicates.
Sep 17, 2013 I missed this because my test data had only one value.
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.198 -This JCL example changes the DSCB of a z/OS dataset from
JCLVBS2U RECFM=VBS to RECFM=U, WITHOUT copying the data, saving
Sep 17, 2013 the CPU and I/O and time for the copy. The changed file
can then be downloaded with ftp (the RECFM=U preserves
BDWs and RDWs) for sites that want to archive AND process
the file on the download platform (using RECFM=S370VBS &
LRECL=32760 on the FILENAME statement to read).
//JCLVBS2U EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSUT2 DD DSN=ZOS.VBS.FILE.TO.CHANGE,
// DISP=MOD,DCB=RECFM=U
//SYSUT1 DD DSN=NULLFILE,DCB=*.SYSUT2
The key is to use DISP=MOD and to copy NULLFILE which
ONLY changes the DSCB attributes and does NOT touch
the actual data in the original file.
-Note: if you ONLY want to READ the data and do not need
to archive, you would use the SAS ftp Access method that
is documented in the INSTALL member to directly read the
z/OS data over ftp without prior download, only writing
the SAS datasets on the download platform.
-While the technique can also change RECFM=U to VBS, and
while you can create a RECFM=VBS file on ASCII and upload
to z/OS, you cannot simply upload that file into RECFM=U
and then change the RECFM; you must upload the VBS data
into a RECFM=U,BLKSIZE=32760 file on z/OS, and then use
either the SAS UDEBLOCK or the ASM ASMDBLKU program to
reconstruct legitimate VBS data to read on z/OS.
Thanks to Dan Kaberon, EMC, USA.
Change 31.197 After MXG 30.30, for IDMS 17, dataset IDMSINS had zero
VMACIDMS obs because only SEQN=1 exists in version 17, but MXG
Sep 12, 2013 update expected SEQN=2 and did not output.
Thanks to Gitta Janssens, ColruytGroup, BELGIUM
Change 31.196 Support for APAR PM67806 adds new QW0225DMH with total
VMACDB2 DMH GETM storage, for both DB2 V9 and DB2 V10.
Sep 11, 2013 Today's change only supports V9 pending V10 APAR doc.
Thanks to Kerry J. Sommers, John Deere, USA.
Change 31.195A Cosmetic. DEBUGGING PUT statement TY50xxxx= in line 306
VMAC50 is now commented out.
Sep 10, 2013
Thanks to Dan Case, Mayo Clinic, USA.
Change 31.195 Cosmetic. Missing values messages for TASSYTI-TASENTI
VMACIDMS division by 4096 are eliminated by making the INPUT and
Sep 9, 2013 calculation inside a conditional DO group.
Change 31.194 31.02-31.06, z/VM 6.2.12 BROKEN CONTROL RECORD error. The
VMACVMXA MXG input INCORRECTLY expected 120 bytes in STOSHD (3.16)
Sep 9, 2013 record, but this record had only 112 so the INPUT of
ASCCTRSV and ASCDSRSV are now conditional and corrected.
Thanks to David Campbell, SunTrust, USA.
Change 31.193 -An undocumented change in z/OS 2.1 increased the length
VMAC0 of ID=0 records to 68 bytes, which caused the MXG ERROR
Sep 9, 2013 message that the ID=0 record was invalid and was deleted.
Sep 19, 2013 MXG 31.06 eliminated that ERROR message and the DELETE;
31.07 creates these two new variables in TYPE0 dataset:
SMF0MSWT='SWT STC*WAIT TIME*LIMIT*MINUTES'
SMF0MTWT='TWT TSO*WAIT TIME*LIMIT*MINUTES'
These fields are non-zero only if the corresponding new
SWT or TWT keywords are specified in your SMFPRMxx.
-That length test for the TYPE 0 record is ancient, from
the days when a TYPE 0 WAS an IPL event; many times when
a SYSPROG attempted to create a USER SMF record they had
accidentally created a record with ID=0, which then was
reported as an IPL, when there had been no IPL. Now, as
BUILDPDB creates the PDB.IPLS dataset from ID=90 that
DOES report an IPL event, the erroneous deletion of these
valid ID=0 records should not impact your IPL reporting.
But, because some sites still treat a zero as an IPL,
I chose to leave the length check in place for future
a SYSPROG to trigger!
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 31.192 Cosmetic. Comments for IMACICE1/E2/EZ tailoring now cite
UTILEXCL REPORT THREEA to find the counts of fields in those
Sep 9, 2013 optional members.
Change 31.191 READDB2 did not handle PDBOUT=WORK nor PDBOUT=XXX as
READDB2 documented, and could need an unneeded //PDB DD.
Sep 11, 2013 -PDBOUT=WORK, or PDBOUT=, was unintentionally changed by
Change 31.128 (MXG 31.05), writing DB2ACCT to the //PDB
LIBNAME instead of to //WORK, which caused an ABEND if
there was no //PDB DD in the JOB (and one is not needed
with PDBOUT=WORK). Circumvention: add a temporary DD;
//PDB DD UNIT=SYSDA,SPACE=(CYL,(500,500))
-PDBOUT=XXXXX (for some time) only wrote the T102Sxxx data
to the XXXXX LIBNAME; all DB2xxxxx Account and Statistics
datasets were instead written to their default (PDB).
-Now, PDBOUT= null, WORK, or XXXXX will create all output
only in the expected LIBNAMEs; as has been documented in
READDB2, with those PDBOUT vaLUES, you can not change the
output libnames, neither with a %LET Pdddddd=DDNAME nor
nor by using READDB2's LDB2ddd=DDNAME option.
-ACCIDENTALLY, if your PDBOUT=XXX was PDBOUT=PDB, almost
everything DID work as you expected.
Thanks to Otto Burgess, ATPCO, USA.
Change 31.190 -New variables are now INPUT and kept in TMMQQU dataset:
VMACTMMQ QUACCT QUAPPLNM QUAPPLTY QUASID QUBROWSE QUCCONNM
Sep 6, 2013 QUCFSTR QUCHNL QUCLWPRI QUCLWRNK QUCLWUSQ QUHSTAT
Oct 14, 2013 QUINPUT QUINQUR QULGD QULGT QULPD QULPT
QUMEDLGE QUMSGAGE QUMSGQTL QUMSGQTS QUNPMCLS QUOPENOP
QUOUTPUT QUPID QUPSBN QUPSID QUPSTID QUQMON
QUQMONST QUQMURID QUQSGD QUSET QUSTATQ QUTASKNO
QUTID QUTPIPE QUTRANID QUUNCOM QUURID QUURTYPE
QUUSERID QUALTDTE
-A new message reports record counts and bytes of both
compressed and uncompressed input.
-BY List macros have been revised to remove duplicates.
Change 31.189 Format $MGRMFCX for Crypto Coprocessor type expected
FORMATS '10'X for CEX41, but the value in the RMF record is an
Sep 6, 2013 '0A'x, so that value is now used for R7023CT/R7024CT.
Thanks to Michael Creech, Lender Processing Services, Inc., USA
Change 31.188 Change 31.120 added support for MQ SMF 115 ST2 SMDS/QESD
EXTY115S data new in MQ 7.1.0, but output only the first segment
IMAC115 and output it in incorrectly in MQMMSGDM, an interval
VMAC115 dataset. Since there are many structures, now, the SMDS
VMXGINIT data is output in new TYPE115S dataset with one obs for
Sep 4, 2013 for each application structure.
The IBM doc in CSQDQESD is incorrect, showing a length
of 328, but that includes the 8-bytes of the ID/EYEC,
and so only 320 bytes of data is documented. However,
the LQ length is 328, and IBM has added 8 bytes at the
end of each segment. but then, that first entry is 332!
MXG recognizes the IBM error and circumvents in code.
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
====== Changes thru 31.187 were in MXG 31.06 dated Sep 3, 2013=========
Change 31.187 MXG 31.05. After Change 31.156, z/OS under VM only, zero
VMAC7072 obs in PDB.TYPE70. Variable VMSYSTEM is now set from the
Sep 2, 2013 NRCPUID if that APAR is not installed and then used to
force the output.
Thanks to Frank Lund, Evry AS, NORWAY.
Change 31.186 -Variable LSPRWKLD was incorrectly set to 'HIGH' instead
ASUM113 of 'LOW' when 3 LE L1MP LE 6 AND RNI LT 0.6.
Sep 2, 2013 -Cosmetic. LENGTH DEFAULT=&MXGLEN added Sep 17.
Thanks to Wayne Montefiore, CSC, AUSTRALIA.
Change 31.185 Original 31.06 VGETOBS member was not the final update.
VGETOBS See Change 31.180 for the final documentation.
Sep 3, 2013
====== Changes thru 31.184 were in MXG 31.06 dated Sep 1, 2013=========
Change 31.184 -Multiple executions of BLDSMPDB after UTILBLDP now works.
BLDSMPDB Old-style macros _SPINCNT _SPINUOW and _TIMEDIF, (and,
UTILBLDP with USERADD=, _VARUSER and _CDEUSER and any generated
Aug 31, 2013 _CDE _VAR macros are now cleared when BUILDPDB=YES is
Sep 17, 2013 specified, AFTER any generated code has been executed,
with MACRO _xxxxxx _xxxxxx % syntax to redefine an
old-style macro for reuse. This part of this change is
really likely needed only for the MXG QA job since it
is unlikely actual use would need multiple executions
of BLDSMPDB in the same SAS session, but now can be done.
-BLDSMPDB is now protected and will fail if the option to
use the "INSTREAM" SAS code created by UTILBLDP does not
exist, i.e., if that INSTREAM file has zero records.
-Other errors were found in testing on zOS with RUNDAY=PDB
which suppressed running weeklies. The logic looking for
the WEEK FILENAME failed with missing SUBSTR values.
-On zOS BUILDPDB may now point at a dataset name rather
than a DDNAME/FILENAME as it always could on ASCII.
Change 31.183 TYPE50 OSA-EXPRESS READ variables were incorrectly INPUT
VMAC50 TY50REDE /*OSA-EXP*REPLN*DEFR*FOR RD*/
Aug 30, 2013 TY50RDEX /*OSA-EXPREADS*EXH*FOR RD*/
TY50SBRD /*OSA-EXP*SBAL*COUNT*FOR RD*/
TY50PKCN /*OSA-EXP*PACKET*COUNT*/
and these Write variables are now created
TY50PKAC='OSA-EXPRESS*ACCELERATED*PACKET*COUNT'
TY50BYAC='OSA-EXPRESS*ACCELERATED*BYTE*COUNT'
Thanks to John M. McLaughlin, Bank of America, USA.
Change 31.182 -The MXG message SUCCESSFULLY COMPLETED READING SMF now
VMACSMF has new text that reports (mostly for MXG diagnostics) if
Aug 28, 2013 *** THE INPUT SMF FILE DID NOT END WITH ID=3, BUT
*** THIS CAN BE NORMAL - SEE CHANGE 31.182 TEXT.
which MIGHT be an indication that SMF data was lost.
Each SMF file created OR copied by IFASMFDP/IFASMFDL ends
with an SMF ID=3 record, and so even concatenations of
SMF dumps will end with an ID=3 (in fact, each copy with
or subset adds yet another ID=3 at the end of output).
So if the last record is not ID=3, it could be a problem.
For example, a disconnect using the ftp access method, or
during download, or an overlooked out-of-disk-space issue
could be detected by its absence.
-BUT THIS CAN BE NORMAL: If your data has been sorted, or
if you used a utility program that removes type 2 and 3
SMF records (e.g., SMFUTIL, but it could be any program
that processes the SMF data before you read it), or if
you used SAS (AND NOT IFASMFDP, which writes a 2 and 3
when used to copy SMF) and either selected records or
used OPTIONS OBS=nnn; to limit the number of SMF records
read when testing: THESE ARE NOT ERRORS AND THE MESSATE
HAS NO IMPACT.
-If the last record is the ID=3, that text then reads
*** AND THE INPUT SMF FILE ENDED WITH EXPECTED ID=3.***
If absence of that ID=3 would be an error in your SMF
processing, where you ALWAYS expect complete dumped data,
variable ENDISID3 can be used in your IMACFILE/&MACFILE
tailoring to take more aggressive action.
Change 31.181 -RMF III Support for z/OS 2.1 plus Enhancements and Fixes.
ADOCRMFV -Support for z/OS 2.1 changes to the ASI, CFI, CPDCB, and
ASMRMFV GEI RMF III tables.
EXZRBCHP -Two new CFI table sections CFICHPAS (Channel Path) and
EXZRBSCM CFISSCMS (Storage Class Memory) added with z/OS 2.1 are
JCLCRMFV now created by ASMRMFV, and VMACRMFV creates datasets:
JCLDRMFV dddddd dataset description
JCLRMFV ZRBCHP ZRBCHP CFICHPAS CHANNEL PATH
VMACRMFV ZRBSCM ZRBSCM CFISSCMS STORAGE CLASS MEMORY
VMXGINIT -New ZRBCHP dataset variables (20):
ZASMRMFV ZDATE ='ZEE DATE*ZEE OBS*WAS CREATED'
Aug 30, 2013 CFICHAID='HOST CHANNEL ADAPTER ID'
CFICHAPN='HOST CHANNEL ADAPTER PORT NUMBER'
CFICHEIN='INDEX OF CFI TABLE ENTRY'
CFICHFLAGS1='1ST*CHANNEL PATH VALIDITY FLAG'
CFICHLAT='CHANNEL PATH LATENCY TIME'
CFICHOPM='CHANNEL PATH OPERATION MODE'
CFICHPCP='PHYSICAL*CHANNEL*PATH*ID'
CFICHPID='CHANNEL*PATH*ID'
CFICHSAP='SAP-S TO WHICH CHP IS ACCESSIABLE'
CFICHSTA='CHANNEL PATH STATUS FLAGS'
CFICHTYPE='CHANNEL PATH TYPE'
CFIENNAM='NAME OF*COUPLING*FACILITY'
CFIENSYS='NAME OF*SYSTEM'
SSHGOMNT='GATHERER*MINTIME*OPTION'
SSHRMFVN='RMF*VERSION*NUMBER'
SSHSMPNR='NUMBER*OF VALID*MINTIME*SAMPLES'
SSHTIBEG='BEGIN TIME*FOR THIS*SET OF SAMPLES'
SSHTIEND='END TIME*FOR THIS*SET OF SAMPLES'
SYSPLEX ='SYSPLEX*NAME*FROM*COUPLEXX'
SYSTEM ='SYSTEM*ID'
SHIFT ='SHIFT*OF*START'
-New ZRBSCM dataset variables (21):
ZDATE ='ZEE DATE*ZEE OBS*WAS CREATED'
CFISCALG='SCM*ALGORITHM*TYPE'
CFISCEMA='EST MAX*AUSMENTED*SPACE*4K BLOCKS'
CFISCEME='EST MAX*LIST ELEMENTS*RESIDE*IN SCM'
CFISCEML='EST MAX*LIST ENTRIES*RESIDE*IN SCM'
CFISCENE='EXIST STRUCT*LIST ELEMENTS*RESIDE*SCM'
CFISCENL='EXIST STRUCT*LIST ENTRIES*RESIDE*IN SCM'
CFISCFAU='FIXED*AUGMENTED*SPACE*4K BLOCKS'
CFISCIUA='AUGMENTED*SPACE IN USE*4K BLOCKS'
CFISCIUS='SCM MEMORY*IN USE*4K BLOCKS'
CFISCMAX='MAX*SCM*STRUCTURE*CAN USE*4K BLOCKS'
CFISCNAM='NAME OF CONNECTED STRUCTURE'
CFISCVER='STRUCTURE*VERSION*NUMBER'
CFIENNAM='NAME OF*COUPLING*FACILITY'
CFIENSYS='NAME OF*SYSTEM'
SSHGOMNT='GATHERER*MINTIME*OPTION'
SSHRMFVN='RMF*VERSION*NUMBER'
SSHSMPNR='NUMBER*OF VALID*MINTIME*SAMPLES'
SSHTIBEG='BEGIN TIME*FOR THIS*SET OF SAMPLES'
SSHTIEND='END TIME*FOR THIS*SET OF SAMPLES'
SYSPLEX ='SYSPLEX*NAME*FROM*COUPLEXX'
SYSTEM ='SYSTEM*ID'
SHIFT ='SHIFT*OF*START'
-ASMRMFV now exploits z/Architecture (zSeries)
instructions to relieve 4K base register addressing
constraints and improve performance. ASMRMFV should run
without error on this hardware. zSeries machines have
been available since 2000.
-MXG users with only pre-z/Architecture machines available
can install the legacy version of ASMRMFV called
ZASMRMFV. Contact MXG Technical Support for details.
-ZASMRMFV includes all Change 31.181 features for z/OS 2.1
support, but is functionally stabilized and will not be
further enhanced.
-ASMRMFV WTO messages RMFV099S and Abend U0998 will be
issued if execution is attempted on a non-zSeries
processor. This prevents an abrupt and unexplained S0C1
Abend that would otherwise occur. If this occurs either
run ASMRMFV on a zSeries machine or use ZASMRMFV instead.
-Initial message RMFV000I will indicate whether the
current ASMRMFV or legacy version ZASMRMFV is being used.
-Four internal ASMRMFV subroutines have been migrated into
mainline code to eliminate the entry/exit linkage CPU
overhead required for each call.
-ASMRMFV now supports keywords up to 10 characters in
length.
-ASI table bit string field ASIMSTS (Miscellaneous States)
is now decoded into 8 new Y/N valued variables in the
ZRBASI data set.
-New ZRBASI dataset variables (10):
ASI1MBFF='1MB*FIXED FRAMES*PAGEABLE*DREF-MEM OBJS'
ASI1MBPF='PAGEABLE*PAGEABLE*DREF-MEM OBJS'
ASICICST='CICS TOR*MANAGED TO*REGION GOALS?'
ASICPUPR='CPU*PROTECTION*ASSIGNED?'
ASIIOPGH='I/O PRIORITY*GROUP HIGH*ASSIGNED?'
ASIMAOSC='MANAGE AS*TO GOALS*OTH SERV CLASSES?'
ASIOMVS ='ADDRESS*SPACE*IS OMVS*RELATED?'
ASIPRMRT='PREVENT*REGN MGT*BY RESPTIME*GOALS?'
ASISDCAS='SERVICE TRANS*IN DIFF CLASS*THAN AS?'
ASISTGPR='STORAGE*PROTECTION*ASSIGNED?'
-CPC table bit string field LCPUCHIN (Processor Status
Indicators) is now decoded into 7 new Y/N valued
variables in the ZRBLCP data set.
-New ZRBLCP dataset variables (21):
CPCCAPG ='LPAR*BELONGS TO*CAPACITY GROUP?'
CPCHOME ='THIS IS*THE HOME*PARTITION?'
CPCLPARI='LPAR DATA*INVALID?'
CPCLPMAX='LPAR PROCESSORS*DEFINED*EXCEED*LIMIT?'
CPCUPIDV='USER*PARTITION ID*IS VALID?'
CPCUSEIW='USE INIT WEIGHT*FOR CAP GROUP*PROJECT?'
CPCWMGT ='WLM WEIGHT*MANAGEMENT*ENABLED?'
LCPUABSL='ABSOLUTE LIMIT*ON LPAR USAGE*CHANGED?'
LCPUDED ='PROCESSOR DEDICATED?'
LCPUHIPD='HIPERDISPATCH*MODE IS ACTIVE?'
LCPUHWCL='ABS LIMIT*LPAR USAGE*THIS TYPE'
LCPUICAP='INITIAL*CAPPING*ON?'
LCPUICST='INITIAL CAPPING*STATUS CHANGED?'
LCPUMAWC='MAXIMUM*WEIGHT*CHANGED?'
LCPUONL ='PROCESSOR*ONLINE?'
LCPUONOF='PROC*ONLINE TO*OFFLINE OR*VICE-VERSA?'
LCPUPRNA='PROCESSOR*NOT AVAILABLE*IN MINTIME?'
LCPUSD ='PROC*SHARED TO*DEDICATED OR*VICE-VERSA?'
LCPUWCCH='WAIT*COMPLETION*CHANGED?'
LCPUWCN ='WAIT*COMPLETION*NO?'
LCPUWCY ='WAIT*COMPLETION*YES?'
-CPC table bit string field LCPUSTIN (Processor Status
Change Indicators) is now decoded into 6 new Y/N valued
variables in the ZRBLCP data set.
-Part of the GEI table was not being processed by VMACRMFV
and new fields added by z/OS 2.1 are now also supported
in the ZRBGEI dataset.
-The PDB build for the ZRBGEI dataset variable
GEICPUOL='AVERAGE*OF ONLINE*PROCESSORS' was inputting
from a GEI table field that has been reserved since z/OS
1.1 and was always zero. GEICPUOL and derived variable
PCTCPUBY will now both always be set to missing for
compatibility with any existing user reports. Use the
ZRBCPU and/or ZRBLCP datasets for equivalent data.
-New ZRBGEI dataset variables (36):
GEICASL ='64-BIT*COMMON*AUX STORAGE*SLOTS'
GEICFFR ='64-BIT*COMMON*FRAMES*FIXED IN REAL'
GEICFR ='64-BIT*COMMON*FRAMES*BACKED IN REAL'
GEICMO ='64-BIT*COMMON*OBJECTS*ALLOCATED'
GEICSIZ ='HIGH*COMMON*AREA*SIZE'
GEICUSE ='HIGH*VIRTUAL*COMMON PAGES*IN-USE'
GEIEHIAL='LSQA/SWA/229/230*ALLOCATED*ABOVE 16M'
GEIELOAL='USER REGION*ALLOCATED*ABOVE 16M'
GEIHIAL ='LSQA/SWA/229/230*ALLOCATED*BELOW 16M'
GEILCMO ='FIXED*MEMOBJECTS*ALLOC IN*COMMON*STORAGE'
GEILCMU ='1MB HIGHVIRT*COMMON OBJECTS*OWNER GONE'
GEILCPR ='1MB HIGHVIRT*COMMON PAGES*BACKED*IN REAL'
GEILCPU ='1MB HIGHVIRT*COMMON PAGES*OWNER GONE'
GEILF4K ='1MB FIXED*FRAMES USED*BY 4K*PAGE REQS'
GEILFPF ='1MB FRAMES*IN LFAREA*SATISFY*1MB REQS'
GEILFUSE='1MB FRAMES*USED BY*FIXED*MEMORY OBJECTS'
GEILOAL ='REGION*ALLOCATED*BELOW 16M'
GEILP4K ='1MB PAGEABLE*PAGES USED*BY 4K*PAGE REQS'
GEILPAG ='1MB FRAMES*USABLE*PAGEABLE*DREF'
GEILPFCI='DEMOTED 1MB*PAGEABLE PAGES*CVRT TO 4K'
GEILPFRI='FAILED 1MB*PAGEABLE PAGES*REQUESTED'
GEILPUSE='1MB FRAMES*USED BY PAGE/DREF MEMOBJECTS'
GEILSIZ ='MAXIMUM*LARGE*FRAME*SIZE'
GEIRBFIX='FIXED*FRAMES*BELOW 16 MB*IN REAL'
GEIRLMO ='LARGE*MEMORY*OBJECTS*ALLOCATED'
GEIRLPR ='1 MB FRAMES*BACKED IN*REAL STORAGE'
GEIRSTRF='HIGH VIRT*COMMON*PAGES*IN-USE'
GEIRTFIX='TOTAL*FIXED FRAMES'
GEISASL ='HIGH VIRT*SHARED MEMORY*AUXSTORAGE*SLOTS'
GEISEQ ='CPC*SEQUENCE*NUMBER'
GEISFR ='HIGHVIRT*SHAREDMEM*FRAMES*BACKED IN REAL'
GEISLTA ='CURRENTLY*AVAILABLE*SLOTS'
GEISMO ='HIGHVIRT*SHAREDMEM*OBJECTS*ALLOCATED'
GEISSIZ ='SHARED*AREA*SIZE'
GEISUSE ='HIGH*VIRTUAL*SHARED PAGES*IN-USE'
GEITOTPI='TOTAL*NUMBER OF*PAGED-IN PAGES'
-The ASMRMFV Dynamic Method will now detect empty RMF
Monitor III VSAM data sets and NOT dynamically allocate
them. Prior to this change the condition was not
detected until the file was opened, but the dynamic
allocation and subsequent open overhead was unnecessary.
-ASMRMFV CSI search summary message RMFV065I now includes
the count of empty data sets found.
-New ASMRMFV message RMFV054* will be issued for any empty
data sets found during CSI scan or VSAM open. (*=I,A,W).
-New ASMRMFV message RMFV055* will be issued for
"imposter" VSAM data sets that have the correct RMF
Monitor III CISIZE and RECSIZE, but do not have a valid
DSH table id of 'DSIG3'. (*=I,A,W).
-New ASMRMFV message RMFV051* is issued for all data set
type errors (not a VSAM RRDS) during a CSI scan or VSAM
open and always includes the DDNAME. (*=I,A,W).
-New ASMRMFV message RMFV067* now directs users to IBM
message IDC3009I for non-zero Catalog Management Return
and Reason Codes produced during a CSI search.
(*=I,A,W).
-Show ASMRMFV error message RMFV066E during Dynamic
Allocation abend.
-Show ASMRMFV message RMFV067E during Catalog/Dsname CSI
search error abend.
-ASMRMFV message RMFV007S could have incorrect Return
and/or Reason Codes shown.
-ASMRMFV message RMFV038* is now message RMFV052*
(*=I,A,W).
-ASMRMFV message RMFV039* is now message RMFV053*
(*=I,A,W).
-ASMRMFV message RMFV037I REPORT= and OUTPUT= settings are
now aligned in output for better readability.
-Multi-severity ASMRMFV error messages controlled by *ERR=
parameter settings and used for a single purpose are now
tailored only once during initialization instead of every
time issued.
-Assemblies of ASMRMFV will no longer print the source
code documentation as this is available to browse in the
ASMRMFV member as well as in ADOCRMFV.
-The ASMRMFV/ZASMRMFV source prologues as well as
ADOCRMFV, JCLRMFV, JCLCRMFV, and JCLDRMFV documentation
members are updated appropriately.
-New variables added to RMF III dataset ZRBLCP:
CPCHOME CPCLPARI CPCLPMAX CPCUPIDV CPCCAPG CPCWMGT
CPCUSEIW LCPUPRNA LCPUONL LCPUDED LCPUWCY LCPUWCN
LCPUICAP LCPUHIPD LCPUONOF LCPUSD LCPUDED LCPUICST
LCPUWCCH LCPUMAXW LCPUABSL LCPUHWCL
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change must
be installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Change 31.180 Detection that a LIBNAME points to a SAS z/OS TAPE-FORMAT
VGETOBS or sequential-format-on-DASD dataset is NOW done by macro
Aug 26, 2013 VGETOBS, so that we can bypass a performance issue, but
Aug 31, 2013 WPS ABENDed with the original VGETOBS because WPS did not
exactly clone the SAS behavior:
When there is a WHERE clause with PROC SQL's search of
DICTIONARY.TABLES, SAS opens the LIBNAME and scans it,
but WPS ABENDED if the LIBNAME was tape/sequential.
The exposure to this ABEND under WPS occurs when an
input tape/sequential LIBNAME not been OPENed and
VGETOBS's PROC SQL is invoked, for example, when
ASUMUOW is executed standalone. If ASUMUOW instead is
%INCLUDEd as part of the BUILDPDB step, where the input
LIBNAMES to be opened by ASUMUOW are already OPEN,
there is no ABEND.
- History:
When a PROC SQL is issued against DICTIONARY.TABLES that
uses a WHERE clause referencing a LIBNAME that has not
yet been opened or scanned, SAS reads that LIBNAME to
find all SAS Datasets (MEMNAME) in that data library, to
populate that table. But, if the LIBNAME is on tape,
then every tape volume must be mounted and read, since
there is no directory of MEMNAMEs on tape data libraries.
To eliminate that waste of CPU and I/O and the elongated
elapsed time, VGETOBS was enhanced to detect that the
LIBNAME is on tape so it can bypass the multi-vol read.
So while the ABEND is a WPS issue, but because we can, to
help MXG users to keep their jobs (and to keep their JOBS
running without ABENDs), the algorithm was revised to get
around the WPS issue and eliminate the multi-tape read.
FOR MXG EXECUTION ON Z/OS ONLY:
VGETOBS now reads the DICTIONARY.TABLES and writes all
of those names to a temporary table, MXGTABLES, which is
then searched for the LIBNAME & MEMNAME (DDNAME & SAS
dataset). Removing the WHERE clause from the first PROC
SQL prevents that first complete READ of the tape.
If BOTH the LIBNAME and MEMNAME are found in MXGTABLES,
then the LIBNAME was already open and VGETOBS passes back
to its caller the MEMNAME, number of OBS, the create date
and the member type, which is the normal information that
is returned by VGETOBS, and VGETOBS was successful.
If the LIBNAME/MEMNAME is NOT found in MXGTABLES, then
DICTIONARY.LIBNAMES is searched, again without a WHERE
clause creating MXGLIBNAMES, which is then searched for
the LIBNAME. If the LIBNAME is NOW found, and if that
libname is NOT tape format, then that LIBNAME does NOT
contain the MEMNAME we are seeking, and MXG will politely
terminate with an explanatory message on the SAS log.
However, if we determine the LIBNAME is a tape-format
library, we assume you know what you are doing and that
the dataset does exists in that LIBNAME and continue.
If the LIBNAME is not found in MXGLIBNAMES or MXGTABLES
then EXTFILES table is searched for the FILEREF=DDNAME,
and if that DDNAME is found to exist, then it has been
allocated in this step, so we execute a DATA _NULL_ step
that reads the first block in that DDNAME, and examine
the text in that first block for the "SAS" or "WPS" text
that uniquely identifies if this is a SAS or WPS dataset
and whether it is disk or tape format.
If we search EXTFILES and do NOT find the DDNAME or we
find that it is NOT a SAS or WPS sequential dataset, then
WE FORCE YOUR JOB TO ABEND WITH A U1950 ABEND:
IEF450I JOBNAME MXGSAS STEP - ABEND=S000 U1950 REASON=00000000
==> NOTE, PREVIOUSLY WE ONLY PRINTED A WARNING MESSAGE.
If it is a disk dataset, then a LIBNAME command is
issued with either the V9 or WPD engine as appropriate
and then we reinvoke VGETOBS, since executing the LIBNAME
statement populates DICTIONARY.TABLES.
But if instead it is a SEQUENTIAL tape-format library (on
tape OR on disk) we look for that MEMNAME in that first
block, and if found, then the LIBNAME/MEMNAME are valid;
normally, VGETOBS is called by VMXGSUM (or a similar MXG
program) so the next SET statement or reference will open
the LIBNAME without spinning the entire tape. A global
MACRO variable VGETTAPES is populated with the now known
tape DDNAME so that for subsequent VGETOBS executions we
will ALWAYs assume the existence of the dataset rather
than looking for it and possibly causing an unneeded spin
of the tape dataset.
But, if the dataset name is NOT on that first record
then, we gamble that you know what you are doing by
telling us to use that LIBNAME and MEMNAME, so we assume
it must exist further into that tape, so we allow the
processing of the dataset to continue, but we print
MXGWARN messages so you'll know why the job took so long.
Of course, if you lied and the dataset does NOT exist in
that DDNAME, then the job will ABEND ungracefully.
-There are two situations that will cause VGETOBS to issue
a USER ABEND 1950 when executing on z/OS:
- DDNAME is NOT in the EXTFILES list of allocated DDs
- DDNAME exists but the first record does not identify
it as a SAS or WPS data library.
FOR MXG EXECUTION ON ASCII ONLY:
For ASCII, a LIBNAME statement must have been issued for
any LIBNAME, since there's no "JCL", and as there are no
tape-format libraries on ASCII, the WHERE clause is used.
If the search in DICTIONARY.TABLES is unsuccessful, then
it doesn't exist, and with no other place to look,
VGETOBS prints an MXGERROR: message that the dataset does
not exist.
FOR THE HISTORICAL RECORD:
The first implementation of the new algorithm removed the
WHERE clause in the first search. After the functional
tests on both ASCII and z/OS were successful, the primary
QA test step run time jumped from 8 to 155 minutes, due
to that removal of the WHERE clause, but also due to the
unique QA environment that allocates every MXG LIBNAME
and every INFILE that has ever been used in MXG, and
creates every MXG dataset that has ever been created from
every input data source MXG has ever supported, so there
are hundreds of LIBNAMEs and thousands of DATASETs, and
with thousands of VGETOBS calls, that small increase in
the search time of a few LIBNAMEs is magnified. In any
real job there will only be a few of LIBNAMEs, and only
those that are already open are searched without the
WHERE, and typically there is only one VGETOBS call per
JCL step, so there is no issue. But, since the only need
for the removal of the WHERE clause is for the z/OS
environment, the final implementation reinstates the use
of the WHERE clause when executing under ASCII.
Change 31.179 Support for Websphere MQ 7.1.0 new subtype 5, 6, and 7:
EXTY1155 DDDDDD DATASET DESCRIPTION SUBTYPE
EXTY1156 TY1155 TYPE1155 SMC POOL HEADER STATISTICS 5
EXTY1157 TY1156 TYPE1156 SMC GETMAIN MANAGER STATISTICS 6
IMAC115 TY1157 TYPE1157 SMC REGION SUMMARY STATISTICS 7
VMAC115
VMXGINIT
AUG 26, 2013
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.178 WARNING: MULTIPLE LENGTH CAPIFART and more variables when
VMXGRMFI TRNDRMFI was executed the second time because first TRND
AUG 22, 2013 had length 8 but the WEEK.RMFINTRV still had length 5/6.
Now, the variables in RMFINTRV and TRNDRMFI are expanded
to 8 bytes by relocating the LENGTH statement to prevent
that warning (when VARLENCHK=WARN is specified in 9.3).
See Change 31.174.
Change 31.177 SHADOW variable SM01ADCT='ADABAS*COMMAND*COUNT' was INPUT
VMACSHDW incorrectly as an 8-byte duration, but it is 4-byte count.
AUG 27, 2013 -SQL text variable increased to 32000.
SEP 4, 2013
Thanks to Stuart Wildey, MorganStanley, ENGLAND.
Change 31.176 Unused Change Number.
Change 31.175 WARNING: MULTIPLE LENGTHS for PACKNAME corrected, was due
ANALDB2R to a mismatch in compiler faker variable's lengths.
Aug 22, 2013 See Change 31.174.
Change 31.174 WARNING: MULTIPLE LENGTHS for IFAUPTM and ZIPUPTM, with
VMAC7072 RETURN CODE 4 set, can occur with MXG 31.05 because the
Aug 21, 2013 option / INHERIT was not specified when a new PROC MEANS
was used to create the new SUMSTYPE70EN dataset.
Tutorial: WARNING: MULTIPLE LENGTHS message:
This warning message that sets CC=4 was introduced in the
first SAS 9.2 (TS1M0), but there were so many complaints
that a Hot Fix for TS1M0 was created to reverted to SAS
9.1.3 no-warn behavior, and then in SAS 9.2 (TS1M0) the
new VARLENCHK=NOWARN/WARM option, with NOWARN default was
added. So you should not normally see these warnings.
But since there is an underlying issue, VARLENCHK=WARN is
now enabled for the MXG QA stream, and the existing cases
are fixed in the several preceding changes, and will be
caught and corrected in future releases.
Thanks to Don Shelton, Time Customer Service, Inc., USA.
Change 31.173 New variables added to TYPETPMX dataset:
VMACTPMX DBS_I214='DBS_STK*AUTOMATED*3490_SD3'
Aug 20, 2013 DBS_I215='DBS_STK*AUTOMATED*3490_9840'
INCLA ='INCLA*CLASS'
JCL_D ='JCL_D'
OUTCL ='OUTPUT*CLASS'
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.172 The SMF 113 counters have different metrics for each CPU
VMAC113 type (z/10, z/196-z/114, and zEC12), but MXG's labels were
Aug 19, 2013 those of the newest processor type. That is unchanged by
default, still, but this change allows you to change those
counter labels if you don't have the zEC12. You only need
to change the old-style macro _XLA113 to the desired token
for the labels, _XLA113A (z/10), _XLA113B (z/196-z/114)
or _XLA113C (zEC12), using this syntax for a z/114:
%LET MACKEEP= MACRO _XLA113 _XLA113B %
Thanks to Perry Lim, Union Bank, USA.
Change 31.171 The use of VIEWs in SMFSRCH, with this straight-forward
VMXGSRCH invocation:
Aug 18, 2013 %SMFSRCH(LOOKFOR=BWM.ABC.LOADLIB,SMFOUT=SMFOUT);
Aug 30, 2013 resulted in this message on the log:
ERROR:UNABLE TO CREATE WORK.TABLES.DATA BECAUSE
WORK.TABLES.VIEW ALREADY EXISTS.
which terminated the search of SMF data in SAS 9.3 & 9.4.
The error is circumvented by changing the temporary table
name to TABLE1 and by removal of all VIEWs, since they are
not needed for this ad hoc, occasionally run program. The
actual SQL Table Cleanup issue will be addressed later.
Thanks to Dan Case, Mayo Clinic, USA.
Change 31.170 Variable SM1209BK (Short Server Name) is added to subtype
VMAC120 9 datasets TYP1209C, TYP1209S and TYPE1209U to permit the
Aug 17, 2013 selection of those records to limit volume when merging.
Change 31.169 -New variables SM1132MT and SM1132MM, machine type and the
ASUM113 model were not input because line 919 should be SM113DLN
VMAC113 instead of SM113DON.
Aug 15, 2013 -For the zEC12, MXG's equations for DWINSORM and DWDASORM
were not updated from the z196/z114 equations causing
large negative values. The equations were updated and
now only a few obs with small negative values are seen.
Thanks to Rudolf Sauer, T-SYSTEMS, GERMANY.
Thanks to Don Deese, Computer Management Sciences, USA.
Change 31.168 -New variables added by Version 3 to the BVIR02 dataset:
VMACBVIR HOSTHROT='HOST*THROTTLE'
Aug 14, 2013 (no 02 records with which to validate).
Aug 25, 2013 -New variables added by Version 3 to the BVIR10 dataset:
AVGCPUSE 'CPU*USAGE*PERCENT*AT END OF*INTERVAL'
MAXDCUPC 'MAX*DISK CACHE*USAGE*PERCENT'
REAHOSTH 'HOST*WRITE*THROTTLE*REASON'
REACPYTH 'COPY*THROTTLE*REASON'
READEFTH 'DEFERRED*COPY*THROTTLE*REASON'
(no 10 records with which to validate).
-New variable2 added by Version 3 to the BVIR20 dataset:
DEVMAXDL='MAXIMUM*DELAY'
DEVAVGDL='AVERAGE*DELAY'
DEVINTDL='DELAY*INTERVAL*PERCENTAGE'
-New variables added by Version 3 to the BVIR30 dataset:
MAXCPUSE 'MAX*CPU*USAGE*PERCENT'
AVGCPMAX 'AVG*MAX*DISK*USAGE*PERCENT'
MAXDSKPC 'MAX*DISK*USAGE*PERCENT'
REAHOSTH 'HOST*WRITE*THROTTLE*REASON'
REACPYTH 'COPY*THROTTLE*REASON'
READEFTH 'DEFERRED*COPY*THROTTLE*REASON'
Aug 25: +64 corrected to +54 for misalignment in styp 7.
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.167A VOLTAGE Release 4.2 subtype 5 records with their triplet
VMACZPRO claiming more segments than can fit in the record have
Aug 13, 2013 only a few unreadable segments at the end of each record,
so this circumvention reads those segments that can be
read based on record length and warns that segments were
skipped. Release 4.3.0 corrects this error, and with
that version installed, this MXG change is NOT required.
(Yes, this is the 2nd Change 31.167, too late to change.)
Thanks to Gennady Katsnelson, IBM Global Technology Services, USA.
Change 31.167 DB2 V8 ONLY. %READDB2(IFCIDS=STATS 225) did not read the
READDB2 V8-only ID=102 Subtype=225 records, causing all QW0225xx
Aug 13, 2013 variables in PDB.DB2STATS for DB2 V8 records observations
to be missing values. Several old tests for NE 225 were
removed to allow T102S225 to be populated.
-DB2 V8 ONLY. Missing value messages from VMACDB2H for V8
records which don't contain QWHCLOTC/QWHCLORO/QWHCLOAU
are eliminated. Important only because they had to be
identified to eliminate them as the cause of zero obs.
Thanks to John Leyland, HP Enterprise Services UK Ltd, ENGLAND.
Change 31.166 Support for IFCID=380 STORED PROCEDURE DETAIL RECORD
EX102380 creates new T102S380 dataset.
IMAC102 -Typo PIB.2 corrected to &PIB.2. for syntax consistency in
VMAC102 IFCID=358, but fortunately had no actual impact on value.
VMXGINIT -Typos QWT02R2-zero instead of -OH in IFCID=196 caused
Aug 12, 2013 second and subsequent segments, if they existed, to be
Sep 12, 2013 re-inputs of the first segment impacting T102S106 data.
Thanks to Rudolf Sauer, T-SYSTEMS, GERMANY.
Change 31.165 MXG 31.05, PDB.DB2STAT1 not created if READDB2 STATISTICS
READDB2 option was used, because a typo in Change 31.128 had only
Aug 11, 2013 one period in line 3112, where two were required:
MACRO _LDB2ST1 &PDB2ST1..DB2STAT1 %
With only one period, SAS did what it was told and wrote
the data to the dataset named WORK.PDBDB2STAT1.
Note that the %READDB2 STATISTICS option is archaic and
the STATS option instead has been strongly recommended,
at least in the comments in READDB2:
STATS READ ID=100 SMF RECORD TO CREATE
DB2STATS, DB2STATR DB2GBPST AND
DB2STATB, DB2STAT5
STATISTICS ARCHAIC. READ ID=100 TO CREATE
DB2STATS, DB2STATR AND DB2GBPST,
BUT ALSO WRITES THE REDUNDANT STATS
DATASETS (DB2STAT0/1/2/4/225/B)
THAT ARE ALREADY IN DB2STATS.
Since IBM has created additional DB2 stats IFCIDS over
time, any new interval statistics subtypes will be added
only into the PDB.DB2STATS dataset.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 31.164 Error messages DISKxxxx HAS X NRCOUNTERS BUT DSKSEQ HAS Y
VMACNMON followed by INVALID DO CONTROL error ABEND was caused by
Aug 12, 2013 truly invalid NMON data. The DISKxxxx descriptor records
defined 66 disks, but interval T0166 created a pair of
DISKBUSY/DISKBUSY1 with 185 device's data, but without a
clue that the hardware configuration changed. The DO
Control ERROR is now eliminated, but the bad data can't
be validly processed. Up to 20 messages per HOST will be
printed when DSKSEQNR NE NRDSKSEQ. This text will be
revised if/when a correction from IBM has been tested.
Thanks to Xiaobo Zhang, Fiserv, USA.
Change 31.163 WPS ONLY. The WPS Compiler failed to correctly resolve
ANALDB2R an old-style macro _S102&IFC deep inside READDB2 when it
READDB2 was invoked by ANALDB2R that should have generated the
Aug 8, 2013 _S102023 token for IFCID=023 but instead created _S102004
which is NOT a dataset created by this %ANALDB2R, which
caused ERROR: DATASET WORK.T102S004. We have provided
a detail trace to our customer to open a problem with WPS
support, which appeared to be an incorrect order of macro
resolution between old-style and new-style %macros, but
but we found that by replacing the _S102&IFC token that
was not correctly resolved, with this alternative syntax
%LET IFCSTRING=S102&IFC;
_&IFCSTRING
the WPS error appears to be circumvented.
This is the %ANALDB2R invocation that failed, even with
//SMF DD DUMMY because it's a compiler issue and not data
driven:
%ANALDB2R(DB2=ADSN DSN,
PDB=SMF,PMACC01=NO,PMACC02=NO,PMAUD01=NO,SORTBY=DB2,
PMAUD02=YES,PMAUD03=NO,
AUDIT=AUTHFAIL AUTHCNTL DDL DML BIND AUTHCHG UTILITY,
PMSTA02=NO);
Change 31.162 -Variables JOB, the job creating the list, and BETAJOBN,
VMACBETA the job name of the BETA task, were inconsistent/wrong as
Aug 5, 2013 both variables do not always exist, although both were
kept in all datasets. This table identifies which will
exist in each subtype (?? - not yet validated with data):
Subtype BETAJOBN JOB
0 yes yes
1 no yes
2 ?? ??
3 ?? ??
4 ?? ??
5 yes NO
6 ?? ??
7 ?? ??
8 ?? ??
20 yes yes
21 yes yes
22 ?? ??
25 yes yes
40 ?? yes
41 ?? yes
42 ?? yes
49 no yes
50 yes no
51 no yes
-Variable BETAJOB was only kept in BETA20 and should not
have been created, since JOB is the normal variable, but
it is kept to prevent variable not found errors.
-Variable BETALJOB was kept in BETA21/25/40/41/42 but as
it contains the JOB value, those datasets variable JOB
is now correctly populated from BETALJOB variable, which
is also still kept to prevent variable not found errors.
-This change now correctly inputs BETAJOBI for BETAJOBN or
inputs JCTJOBID for JOB in the header, based on subtype,
but only the records above with yes or no are validated.
If you create obs in those other datasets, please send
your SMF data so I can validate and update with data.
Thanks to Rudolf Sauer, T-SYSTEMS, GERMANY.
Change 31.161 Cosmetic. Three UNINITIALIZED variable messages removed
VMACRMFV and debugging PUTLOG COL= N statement removed.
Aug 1, 2013
Change 31.160 Support for Velocity Software new segments that create
EXXAMCSH these new datasets (This MAY have been zVPS 4.2.)
EXXAMCTY
EXXAMHPP DDDDDD DATASET DESCRIPTION INFILE
EXXAMSPT
EXXMUDIO XAMCSH XMCPSHAR CPSHAR XAMSYS
EXXMVCPU XAMCTY XMCPTYPE CPTYPE XAMSYS
IMACXAM XAMHPP XMIODHPP IODHPP XAMDEV
VMACXAM XMUDIO XMUCDDIO UCDDIO XAMTCP
VMXGINIT XMVCPU XMVSICPU VSICPU XAMTCP
Aug 20, 2013 XAMSPT XMSYTSPT SYTSPT XAMSYS
Aug 21, 2013 and add new variables to many existing XAM datasets.
-All datasets are created and all tokens defined.
-Large VM systems can create multiple XAMSYS records for
each interval, but since only that first record contains
all of the 'single-instance-per-interval' segments that
are all output into dataset XAMSYS, those additional
records created an observation in XAMSYS with all values
a missing value. Now, only that first record is output
in XAMSYS (and, of course, those other multiple-instance
segments are output to their unique MXG dataset.
-VSICPU: There is one set of counters per Virtual CPU, and
SEGLEN is used to calculate the number of segments.
-SYTCPM: Rather than creating one obs for each channel in
the XMSYTCPM dataset, the 256 channel busy variables
PCTCHPBUSY00-PCTCHPBUSYFF are now output in XAMSYS and
dataset XMSYTCPM is no longer created, and references to
to dddddd token SYTCPM are removed from VMACXAM and the
EXSYTCPM member is deleted.
-The SYTCPM segment NCHAN field does not count the number
of channel busy metrics in the record; instead, it is the
the highest channel number. And while SEGLEN does count
the actual number of metrics in the record, it is wrong
in current XAM records with an extra four bytes:
a. NCHANS='FF'x (255), SEGLEN=1140 => 257 actual metrics
b. NCHANS='FB'x (251), SEGLEN=1124 => 253 actual metrics
and that 257 value raised an ARRAY SUBSCRIPT error with
only 256 possible metrics expected. While Barton will
fix SYTCPM so the SEGLEN is correct, this
change/circumvention simply increases the array size to
257 but only the first 256 variables are kept, so you
won't have to change MXG when Barton makes his change.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Douglas C. Walter, Citigroup, USA.
Change 31.159 Mostly cosmetic; HOLDxxxx variables are DROPped and the
ANAL42DS TASKTYPE typo was corrected to TYPETASK.
Jul 30, 2013
Change 31.158 Circumvention for added fields in TMQQAA that caused the
VMACTMMQ 2nd and subsequent observations from the same record to
Jul 30, 2013 be misaligned.
Change 31.157 Examples in JCLUOW, JCLMQMCI & ASUMUOW were inconsistent
JCLUOW and in some cases incorrect, and created unneeded data.
JCLMQMCI JCLUOW - Creates CICSTRAN,DB2ACCT, then PDB.ASUMUOW
ASUMUOW JCLMQMCI - Adds MQMACCT,MQMACCTQ, creates PDB.ASUMUOW.
Jul 29, 2013
Thanks to Thomas Kelman, Xerox, USA.
====== Changes thru 31.156 were in MXG 31.05 dated Jul 29, 2013=========
Change 31.156 -MACROs _N70, _N72, _S70, and S72 are created so that you
VMAC7072 can create only datasets from ID=70 or ID=72 RMF records.
Jul 25, 2013 (Members TYPE7072/TYPS7072 process both records because
early RMF required passing CPUTYPE from the 70 to the 72
so that CPU could be calculated from service units with a
table lookup to get SU_SEC. Yep, I said EARLY!)
While most will always create both suites of datasets,
you can use these new macro tokens to process only one of
the two record; for example:
//SYSIN DD *
%LET MACKEEP=
_N72
MACRO _S72 %
;
%INCLUDE SOURCLIB(TYPS7072);
will only create the PDB.TYPE70xx datasets:
_N72 Nulls the creation and OUTPUT of TYPE72xx datasets
_S72 Blanks/Nulls the SORTs of TYPE72xx datasets.
-MACRO _DROP70 lists the TYPE70 per-engine variables
so you can ignore them using
%INCLUDE SOURCLIB(VMAC7072);
PROC PRINT DATA=PDB.TYPE70 (DROP- _DROP70);
or drop them from a new dataset using:
%INCLUDE SOURCLIB(VMAC7072);
DATA WANT;SET PDB.TYPE70; DROP _DROP70;
-TYPE70 only keeps the first 102 per-engine variables.
Dataset TYPE70EN has all 255 possible per-engines.
Change 31.155 -Protection for INVALID DATA FOR RVPERCEN when IBM stored
VMACEDGR '***' EBCDIC for the numeric VOLUME*PERCENTAGE*FULL.
Jul 25, 2013 The double question-mark-modifier was added to RVPERCEN
INPUT to suppress the ERROR message and the hex dump.
With or without this protection, the value in RVPERCEN
is a missing value. If I can find out what those three
asterisks mean, I'll update this note.
-Change 31.118 failed to input RVMEDTY causing subsequent
RVxxxxx variables to be trashed in EDGRXEXT dataset.
Thanks to Paul Volpi, UHC, USA.
Change 31.154 By default, ASUMHSM summarizes all HSM systems, but you
ANALHSM can use MACRO _HSMPLEX HSMPLEX=SYSTEM; % in a
ASUMHSM %LET MACKEEP= in your SYSIN to create a separate summary
TRNDHSM for each system, ANALHSM was updated to allow HSMPLEX to
Jul 25, 2013 be used to report each SYSTEM/LPAR, and variable HSMPLEX
(default is blank) is added to the SUMBY= in TRNDHSM.
Thanks to Rick Ralston, Humana, USA.
Change 31.153 Support for z/OS 2.1: COMPATIBLE, VALIDATED WITH IBM DATA
BUIL3005 -z/OS 2.1 Compressed Log Stream can only be read with
BUILD005 IFASMFDL running on a z/OS 2.1 system with zEnterprise
EXT11941 Data Compress (zEDC) Express. Otherwise, IFASMFDL will
EXT11942 fail with Return Code 4, unless you have enabled
EXT11943 SOFTINFLATE option of IFASMFDL, which will decompress,
EXT11944 but at higher CPU cost than zEDC Express.
EXT1194L -"You can specify LRECL=32760 instead of 32767" (default)
EXT11971 is finally now stated in the SMF manual, but 32767 should
EXTY42VC NEVER have been used for the LRECL. It can never be
EXTY9036 greater than 32760 and 32767 has caused many programs to
FORMATS fail (BUT NOT SAS!!). And, of course, IBM is reluctant
VMAC104 to change ANY default, even those they recommend that you
VMAC113 should change!
VMAC119 -New SMFPRMxx PERMFIX parameter sets minimum (1MB) to
VMAC1415 maximum (2GB) page fixed real storage that is set aside
VMAC23 for zEDC Express decompression services for compressed
VMAC26J2 SMF data. NOPERMFIX default, but up to 2MB pages can be
VMAC30 fixed for zEDC Express.
VMAC30 -New SMF30 Instruction Counters variables are added to ALL
VMAC42 MXG datasets derived from SMF 30s that contain CPUTCBTM:
VMAC6 TYPE30_V,SMFINTRV,TYPE30_4,TYPE30_5,PDB.STEPS,PDB.JOBS;
VMAC60 -IBM now recommends these 30 hardware instruction counters
VMAC7072 should be used for chargeback instead of processor time:
VMAC71 SMF30_INST_CP_TASK =SMF30*INST*CP*TASK
VMAC73 SMF30_INST_CP_NONPREEMPTSRB =SMF30*INST*CP*NONPREEMPTSRB
VMAC74 SMF30_INST_CP_PREEMPTSRB =SMF30*INST*CP*PREEMPTSRB
VMAC90 SMF30_INST_OFFLOAD =SMF30*INST*OFFLOAD
VMACDCOL SMF30_INST_OFFLOADONCP =SMF30*INST*OFFLOADONCP
VMXGINIT SMF30_INST_CP_ENCLAVE =SMF30*INST*CP*ENCLAVE
EXTY749 SMF30_INST_OFFLOAD_ENCLAVE =SMF30*INST*OFFLOAD*ENCLAVE
SMF30_INST_OFFLOADONCP_ENCLAVE=SMF30*INST*OFFLOADONCP*ENCLAVE
SMF30_INST_CP_DEPENC =SMF30*INST*CP*DEPENC
SMF30_INST_OFFLOAD_DEPENC =SMF30*INST*OFFLOAD*DEPENC
SMF30_INST_OFFLOADONCP_DEPENC =SMF30*INST*OFFLOADONCP*DEPENC
Jul 23, 2013 -Sums of subsets of these counts create new variables that
correspond to the existing CPU time variables:
CPU_INST = Total ALL ENGINES INSTRUCTION COUNT
CPUTCBTM_INST= SMF30_INST_CP_TASK+ /*CPT_INST*/
SMF30_INST_CP_PREEMPTSRB+
SMF30_INST_OFFLOADONCP+
SMF30_INST_CP_ENCLAVE+
SMF30_INST_OFFLOADONCP_ENCLAVE+
SMF30_INST_CP_DEPENC+
SMF30_INST_OFFLOADONCP_DEPENC;
CPUSRBTM_INST= SMF30_INST_CP_NONPREEMPTSRB; /*CPS_INST*/
CPUASRTM_INST= SMF30_INST_CP_PREEMPTSRB; /*ASR_INST*/
CPUENCTM_INST= SMF30_INST_CP_ENCLAVE+ /*ENC_INST*/
SMF30_INST_OFFLOADONCP_ENCLAVE;
CPUDETTM_INST= SMF30_INST_CP_DEPENC+ /*DET_INST*/
SMF30_INST_OFFLOADONCP_DEPENC;
-IBM notes originally had ONLY the _OFFLOAD counter for
the zIIP+zAAP counts, but data with _OFFLOAD zero and
non-zero _OFFLOAD_DEPENC confirmed the note was wrong,
and IBM has confirmed these calculations are correct:
CPUZIPTM_CPUIFATM_INST=SMF30_INST_OFFLOAD-
SMF30_INST_OFFLOAD_DEPENC-
SMF30_INST_OFFLOAD_ENCLAVE;
(i.e. total instructions on zIIP/zAAP)
CPUTM_INST =CPU_INST -
CPUZIPTM_CPUIFATM_INST;
(i.e. total instructions on CP engines).
-TYPE30_V,_4,_5,_6 new variable:
SMF30_RCMTADJN='NOMINAL*CPU*RATE*ADJUSTMENT'
These new INSTRUCTION COUNTs require SMF30COUNT be
specified in SMFPRMxx, and HIS (SMF 113) must have
enabled ehe Basic Counter Set.
-SMF 6 Printway record adds new JOB ACCOUNTing fields in
extended mode (INDC=7) records. See Change 32.236.
-TYPE1415 new SM14DSTYPE identifies Extended Format
Type 0/1, or Version 2 decoded by $MG014EF format.
-TYPE23, new variables:
SMF23CWN='COMPRESSED*LOG*BLOCKS*WRITTEN'
SMF23NCN='NON-COMPRESSED*LOG BLOCKS*WRITTEN'
SMF23PFH='PERMFIX*HWM USED*BY SMF'
SMF23PFM='PERMFIX*MAXIMUM*ALLOWED'
SMF23PFT='PERMFIX*STORAGE*USED*BY*SMF'
-TYPE26J2, New Sub-subtype, not documented in SMF manual
yet, will update this note when the new manual is out.
-TYPE42 VCC Virtual Concurrent Copy segment (previously
existed, but overlooked) creates new TYPE42VC dataset:
S42VCCTK='TRACKS*USING*CONCURRENT*COPY'
S42VCDSP='TRACKS*USING*VIRTUAL*CCOPY'
S42VCEIT='INITIALIZATION*END*TODSTAMP'
S42VCID ='VCC*LOGICAL*SESSION*ID'
S42VCRQS='REQUEST*TYPE VCC*=VIRT CONCUR COPY'
S42VCSET='SESSION*END*TODSTAMP'
S42VCSSL='LENGTH*OF*SSIDS*FOR SESSION'
S42VCSSN='NUMBER*OF*SSIDS*FOR SESSION'
S42VCSSO='OFFSET*TO FIRST*SSID'
S42VCSST='SESSION*START*TODSTAMP'
S42VCTS ='TERMINATION*STATUS*N=NORMAL*A=ABNORM'
-TYPE60 new SMF60ELP elapsed duration which can be
subtracted from SMFTIME to get the START time.
-TYPE70, new variables:
SMF70MCP =MAXIMUM*CPU*ADDRESS*AVAILABLE
SMF70ICP =HIGHEST*CPUID*INSTALLED*AT IPL
SMF70CCP =HIGHEST*CPUID*CURRENTLY*INSTALLED
SMF70CPA_ACTUAL =PHYSICAL*CPU*ADJUSTMENT*FACTOR
SMF70CPA_SCALING_FACTOR =SMF70CPA_ACTUAL*SCALING*FACTOR
SMF70UIW='SHOULD*USE*INITIAL*WEIGHT?'
SMF70HW_CAP_LIMIT=ABS LIMIT*PARTITION*USAGE*IN NR ENGINES
Note: field contains hundredths of "CPUs", but MXG
converts to count "CPUs", so 1.5 would be one
and one half engines of type SMF70CIX.
Note: APAR OA40539 added this field to z/OS 1.13.
-TYPE71, new variables:
SMF71S7M='MIN SHARED*PAGE GROUPS*ON SCM'
SMF71S7X='MAX SHARED*PAGE GROUPS*ON SCM'
SMF71S7A='AVG SHARED*PAGE GROUPS*ON SCM'
-TYPE72, new dataset TYPE725N='GRS QSCAN STATISTICS':
R725QSAS='ADDRESS SPACE ID'
R725QSJN='NAME OF THE JOB'
R725QSRC='START*RESUME*REQUESTS'
R725QSRQ='SUM OF SQUARES*RESOURCES*RETURNED'
R725QSRR='RESOURCES*RETURNED*FOR THESE*REQUESTS'
R725QSSC='GQSCAN*ISGQUERY*SPECIFIC*REQUESTS'
R725QSSN='SERVICE CLASS NAME'
R725QSSP='SERVICE CLASS PERIOD'
R725QSST='ADDRESS SPACE STOKEN'
R725QSTI='EXECUTION*TIME IN*GRS*THESE*REQUESTS'
R725QSTQ='SUM OF SQUARES*EXECUTION*TIME'
-TYPE73, new variables:
SMF73MSC='CHANNEL*PATH*POWER'
SMF73SPD='CHANNEL*SPEED*BITS PER*SECOND'
-TYPE74, new variables:
FICONDEV='FICON*DEVICE?'
AVG74CUQ='AVERAGE*CU*QUEUE*PER IO'
SMF74CUQ='CONTROL*UNIT*QUEING*TIME'
SMF74NM2='DEVICE*NUMBER'
SMF74SCS='SUBCHANNEL*SET*ID'
-TYPE74CF, new variables:
R744GTSC='CF*SCM*MAY BE USED*EXTENSIONS'
R744GFSC='FREE*CF*SCM*MEMORY'
R744GISC='SCM*INCREMENT'
-TYPE74MO, new dataset: STORAGE CLASS MEMORY
See Change 33.155. SCM data is now in TYPE74ST dataset.
R744MAEC='SCM*AUXILIARY*ENABLED*COMMANDS'
R744MALG='SCM*ALGORITHM*TYPE'
R744MCPI='CHANNEL*PATH*IDENTIFIER'
R744MEMA='EST MAX*ASSIGNED*AUGMENTM SPACE'
R744MEME='EST MAX*LIST*ELEMENTS*IN SCM'
R744MEML='EST MAX*LIST*ENTRIES*IN SCM'
R744MENE='EXISTING*LIST*ELEMENTS*IN SCM'
R744MENL='EXISTING*LIST*ENTRIES*IN SCM'
R744MFAU='FIXED*AUGMENTED*SPACE'
R744MIUA='AUGMENTED*SPACE*IN USE*BY THIS STRUCTURE'
R744MIUS='SCM*IN USE*BY THIS*STRUCTURE'
R744MMBE='MAX*LIST ELEMENTS*PER SCM*BUFFER'
R744MMBL='MAX*LIST ENTRIES*PER SCM*BUFFER'
R744MRBT='SCM*READ*BYTES*TRANSFERRED'
R744MRFC='SCM*READ OPS*LIST*REFERENCE'
R744MRPC='SCM*READ OPS*PREFETCH OP'
R744MRSQ='SQUARES OF*R744MRST'
R744MRST='SCM*READ OPS*SERVICE*TIME'
R744MSLR='PCT*LIST COUNTS*LOWER*REGULATOR'
R744MSLT='PCT*LIST COUNTS*LOWER*THRESHOLD'
R744MSMA='MAX*SCM*STRUCTURE*CAN USE'
R744MSRL='SCM*REFERENCES*LIST*STRUCTURE'
R744MSRM='SCM*REFERENCES*MIGRATION'
R744MSRR='SCM*REFERENCES*LIST*HASHING'
R744MSUR='PCT*LIST COUNTS*UPPER*REGULATOR'
R744MSUT='PCT*LIST COUNTS*UPPER*THRESHOLD'
R744MSWC='SCM LIST WRITES'
R744MWBT='SCM*WRITE*BYTES*TRANSFERRED'
R744MWSQ='SQUARES OF*R744MWST'
R744MWST='SCM*WRITE OPS*SERVICE*TIME'
-TYPE749, new dataset: RMF III PCIE STATISTICS, but zero
observations are created, awaiting test data; it's very
possible multiple new dataset may ultimately be created.
All variables are created for QA comparisons.
-TYPE90. New subtype 36 creates new dataset
dddddd dataset Description ST
TY9036 TYPE9036 SET CON COMMAND 36
Subtype 35 was not documented.
-TYPE99EH. New variables:
S99EEHMAXAFF='MAXIMUM*AFFINITY*INDEX'
S99EEHMAXCPU='MAXIMUM*CPU*ID'
-New SMF104 record captures CIM data for AIX, LINUX, and
WINDOWS, creating 37 new TYP104nn datasets with nn the
record subtype. Some of the memory metrics in the raw
record are in bytes, or KiloBytes, or MegaBytes: ALL are
converted in MXG variables to bytes and then formatted
MGBYTES to document they contain memory metrics and to
display in B/KB/MB/GB/TB etc. Some "accumulated" fields
are documented, but until data is available, I can't tell
if they really need deaccumulation or not, which would be
an update to their _ST104xx dataset sort macro.
dddddd dataset Description ST
T10401 TYP10401 AIX_ACTIVE MEMORY EXPANONMETRICS 01
T10402 TYP10402 AIX_PROCESSOR METRICS 02
T10403 TYP10403 AIX_COMPUTER SYSTEM METRICS 03
T10404 TYP10404 AIX_DISK METRICS 04
T10405 TYP10405 AIX_NETWORK PORT METRICS 05
T10406 TYP10406 AIX_FILE SYSTEM METRICS 06
T10407 TYP10407 AIX_MEMORY METRICS 07
T10408 TYP10408 AIX_OPERATING SYSTEM METRICS 08
T10409 TYP10409 AIX PROCESS METRICS 09
T10410 TYP10410 AIX_SHARED ETHERNET ADAERMETRICS 10
T10411 TYP10411 AIX_ACTIVE MEMORY SHARIMETRICS 11
T10412 TYP10412 AIX_VIRTUAL TARGET DEVICEMETRICS 12
T10420 TYP10420 LINUX_IP PROTOCO LENDPOT METRICS 20
T10421 TYP10421 LINUX_LOCAL FILE SYSTE METRICS 21
T10422 TYP10422 LINUX_NETWORK PORT METRICS 22
T10423 TYP10423 LINUX_OPERATING SYSTE METRICS 23
T10424 TYP10424 LINUX_PROCESSOR METRICS 24
T10425 TYP10425 LINUX_UNIX PROCESS METRICS 25
T10426 TYP10426 LINUX_STORAGE METRICS 26
T10430 TYP10430 LINUX_KVM METRICS 30
T10431 TYP10431 LINUX_XEN METRICS 31
T10440 TYP10440 LINUX_IP PROTOCOL ENDPOT METRICS 40
T10441 TYP10441 LINUX_LOCAL FILE SYSTE METRICS 41
T10442 TYP10442 LINUX_NETWORK PORT METRICS 42
T10443 TYP10443 LINUX_OPERATING SYSTEM METRICS 43
T10444 TYP10444 LINUX_PROCESSOR METRICS 44
T10445 TYP10445 LINUX_UNIX PROCESS METRICS 45
T10446 TYP10446 LINUX_STORAGE METRICS 46
T10450 TYP10450 LINUX_ZCEC METRICS 50
T10451 TYP10451 LINUX_ZLPAR METRICS 51
T10452 TYP10452 LINUX_ZCHANNEL METRICS 52
T10453 TYP10453 LINUX_ZECKD METRICS 53
T10460 TYP10460 WINDOWS_LOCAL FILESYSTEM METRICS 60
T10461 TYP10461 WINDOWS_NETWORK PORT METRICS 61
T10462 TYP10462 WINDOWS_OPERATING SYSTEM METRICS 62
T10463 TYP10463 WINDOWS_PROCESSOR METRICS 63
T10464 TYP10464 WINDOWS_STORAGE METRICS 64
-TYPE113 Subtype 1 is documented and variables defined,
but will not be read until data records exist for the
validation.
-TYPE119. Six new datasets, with all variables defined,
but no observations will be created; INPUT is bypassed
until test records are available for validation.
dddddd Dataset Description
T11941 TYP11941 SMC-R LINK GROUP STATISTICS
T1194L TYP1194L SMC-R LINK SPECIFIC STATISTICS
T11942 TYP11942 SMC-R LINK STATE START
T11943 TYP11943 SMC-R LINK STATE END
T11944 TYP11944 RDMA RNIC INTERFACE STATISTICS
T11971 TYP11971 FTP DAEMON CONFIGURATION
-TYPEDCOL.
New variable in DCOLDSET:
DCDXPSEV='PS*EXTND*FORMAT*VERSION'
New variable in DCOLDC:
DDCRMODE='VSAM*SMB*RMODE31*VALUE'
New variable in DCOLDC:
DBSEPNM ='SEPARATION*NAME'
THIS CHANGE WAS IN MXG 31.04 BUT WAS NOT DOCUMENTED.
Change 31.152 TYPE70 corrections/enhancements to zIIP and zAAP metrics.
VMAC7072 Variables ZIPUPTM/IFAUPTM, Up-Time, now excludes parked
Jul 24, 2013 time (like CP engines in PDB.TYPE70 and like ALL engines
in ASUM70PR-created datasets - it was only the specialty
engines in PDB.TYPE70 that still included parked time.).
so variables PCTZIPBY and PCTIFABY will be larger.
New counts of the Online-but-not-Parked zIIP/zAAP engines
and clarification of the variables with INSTALLED counts
are added, as are online and parked durations for the
zIIPs and zAAPs:
Engine INSTALLED AVAILABLE UP-TIME ONLINE PARKED
IFA NRIFAS IFACPUS IFAUPTM IFAONTTM IFAPATTM
SMF70IFA
PARTNIFA
ZIP NRZIPCPU ZIPCPUS ZIPUPTM ZIPONTTM ZIPPATTM
SMF70SUP
PARTNZIP
CP NRCPCPU NRCPUS CPUUPTM SMF70ONT SMF70PAT
PARTNCPU
New and revised labels:
PARTNICF='INSTALLED*NUMBER OF*ICF*ENGINES'
PARTNIFA='INSTALLED*NUMBER OF*ZAAP*ENGINES'
PARTNIFL='INSTALLED*NUMBER OF*IFL*ENGINES'
PARTNZIP='INSTALLED*NUMBER OF*ZIIP*ENGINES'
NRCPUS ='ONLINE*NON-PARKED*CP ENGINES'
IFACPUS ='ONLINE*NON-PARKED*IFA ENGINES'
ZIPCPUS ='ONLINE*NON-PARKED*ZIP ENGINES'
CPUUPTM ='CP ENGINE*AVAILABLE*(UP) TIME'
IFAUPTM ='IFA ENGINE*AVAILABLE*(UP) TIME'
ZIPUPTM ='ZIP ENGINE*AVAILABLE*(UP) TIME'
SMF70PAT='CP*SMF70PAT*PARKED*TIME'
IFAPATTM='IFA*SMF70PAT*PARKED*TIME'
ZIPPATTM='ZIP*SMF70PAT*PARKED*TIME'
SMF70ONT='CP*SMF70ONT*ONLINE*TIME'
IFAONTTM='IFA*SMF70ONT*ONLINE*TIME'
ZIPONTTM='ZIP*SMF70ONT*ONLINE*TIME'
zIIP Example: PARTNZIP=12 ZIPCPUS=8.01 DURATM=15:00
|--------------------ZIPONTTM 2:59:59.74---------------------------|
| |
|-----------ZIPUPTM 2:00:09.21------------|---ZIPPATTM 59:50.53---|
| |
|-ZIPACTTM 1:16:48.85-|-ZIPWAITM 42:33.59-|
Change 31.151 -Support for zVM 6.3 MONWRITE. INCOMPAT DUE TO MXG CODE,
VMACVMXA which didn't SKIP new data compatibly added to SYTCUP and
Feb 20, 2013 and didn't correctly detect the extra 32 bytes in PRCAPM
Mar 26, 2013 subtype 8, and printed ERROR PROBABLE DATA LOSS DUE TO...
Apr 16, 2013 and BROKEN CONTROL RECORD: NO 8709X, with large _N_=.
VMXGINIT This change was made in VMACVMXA at 30.30.
Apr 24, 2013 -Before _ESYTCUP statement near line 11567, insert:
Jul 23, 2013 SKIP=CALCPULN-40;IF SKIP GT 0 THEN INPUT +SKIP @;
This change was made in VMACVMXA at 31.02.
-Replace (For 5.10 Record showstopper):
IF PRCAPMCT IN (4,8) THEN DO; line 19028 with
IF SUBSTR(PRCAPMV,1,1) NE 'F0'X THEN DO;
-Two instances of ENDTIME=.; lines 8633,8907 are now
comments, just in case, as they are archaic and not
needed (to force detection of a new interval) but in
some cases caused ENDTIME to be missing in startup
records.
-With those changes, records were read with no execution
errors with MXG 31.02; support was NOT announced.
-These new variables and/or datasets are now created:
SKIP LEN _N_ RECSTART
-Dataset VXSYTPRP (0.02) new variables: 12 152 101 373
CALENTMT='SCALED*PORTION*VERTICAL*ENTITLED'
PFXPRKWT='PARKED*WAIT*TIME'
-Dataset VXSYTASG (0.06) new variables: 8 92 106 493
CALENTMT='SCALED*PORTION*VERTICAL*ENTITLED'
PFXPRKWT='PARKED*WAIT*TIME'
-Dataset VXSYTUSR (0.08) new variables: 8 108 106 657
RLOIB ='INBOUND*LIVE*GUEST*RELOCATIONS'
RLOOB ='OUTBOUND*LIVE*GUEST*RELOCATIONS'
-Dataset VXSYTCUP (0.16) new variables: 8 1216 107 1605
LCXCCWT ='CURRENT*LPAR*WEIGHT'
LCXCTYCP='CPU*TYPE*CAP'
CALCAPV ='MAX*PHYSICAL*CPS*THIS TYPE'
-Dataset VXSYTSYG (0.19) new variables: +12 132 110 2413
NCPCAPAB='NOMINAL*CAPABILITY*OF A*CPU'
FXRDONE ='ZHPF DCW*TRANSLATE*SUCCESSFUL'
FXRWRITE='WRITE CHAN*PRESENTED*TO ZHPF DSW'
-Dataset VXSYTSPT (0.24) new variables: 308 364 106 2169
-PROTECTED: MRHDRLEN=364 ONLY 56 DOCUMENTED.
-Dataset VXMTRPRP (1.05) new variables: 12 56 4 433
CALENTMT='VERTICAL*CPU*ENTITLEMENT='
OFFTOPDS='OFFSET TO RCCTOPDS ARRAY='
PFXPOLAR='CURRENT*POLARIZATION='
RCCTOPDI='DISPATCH*VECTOR*BLOCK='
RCCTOPDS='TOPOLOGY*DESCRIPTOR*IDS='
SIZTOPDS='SIZE OF*RCCTOPDS*FIELD='
-Dataset VXMTRMEM (1.07) new variables: 8 168 84 2497
RSACKMB2G='FRAMES*LT 2G*FOR SAD*CRASHKERNEL'
RSACKMA2G='FRAMES*GT 2G*FOR SAD*CRASHKERNEL'
-Dataset VXMTRSCH (1.16) new DATA UNKEPT. 40 132 94 1345
SRXCPPAD and SRXEXUSE decoded but not kept.
-PROTECTED: SRXEXUSE is 8 bytes when PUMAX is 6.
-Dataset VXMTRSSI (1.25) only read SYSPLXNR, in use slots,
but there are SYSPLXNS, configured slots, segments in the
record. All are now input; not-in-use have blank name.
-Dataset VXSCLSTP (2.08) new variables: 4 84 98 3133
SYSFPGRAT='SYSTEM*PAGE*READ IN*RATE*PERSEC'
-Dataset VXSTORSG (3.01) new variables: 300 764 114 121
RSAAGEPC ='TGT SIZE*GLOBAL*AGING LIST*PCT DPA'
RSAAGEFL ='FLAG*BYTE'
RSARSDMX ='SET RESERVED SYSMAX VALUE FRAMES'
RSAAGESZ ='TGT SIZE OF GLOBAL AGING LIST*FRAMES'
RSAAGINC ='FRAMES*ON THE*GLOBAL*AGING*LIST'
RSAEWNDD ='GAL*CHANGED PAGES*MUST BE*WRITTEN'
RSAEWRFO ='GAL*REF ONLY*NOT HAVE*BE WRITTEN'
RSAEWCIF ='GAL*CHANGED*PAGES*BEING*PROCESSED'
RSAEWRIF ='GAL*REF ONLY*PAGES*BEING*PROCESSED'
RSAAGRDY ='GAL*FRAMES*READY FOR*RECLAIM'
RSAAGRDYREFWRT ='GAL*REF ONLY*READY FOR*RECLAIM*YES AUX'
RSAAGRDYREFNW ='GAL*REF ONLY*READY FOR*RECLAIM*NO AUX'
RSADSTMACT ='DEMAND*SCAN*WAS*RUNNING'
RSACHGWRTOLD ='CHANGED*PAGES*WRITTEN TO*OLD AUX SLOT'
RSAREFWRTBYPASS='REF ONLY*PAGES*NOT REWRITTEN*TO AUX'
RSACHGWRTNEW ='CHANGED*PAGES*WRITTEN TO*NEW AUX SLOT'
RSAREFWRTNEW ='REF ONLY*PAGES*WRITTEN TO*NEW AUX SLOT'
RSAAGRECLM ='PAGES*RECLAIMED*FROM GLOBAL*AGING LIST'
RSAEXMET ='DEMAND SCAN*STOPS*WHEN NEED*WAS MET'
RSAEXTIM ='DEMAND SCAN*STOPS*MAX*ALLOWABLE*TIME'
RSAEXCPU ='DEMAND SCAN*STOPS*CPU*SUBOPTIMAL'
RSAINVUFO ='PRIVATE*PAGES*INVALIDATED'
RSAINVVUFO ='PRIVATE*VDISK*PAGES*INVALIDATED'
RSAINVSUFO ='SHARED*PAGES*INVALIDATED'
RSARVLUFO ='PRIVATE*PAGES*REVALIDATED'
RSARVLVUFO ='PRIVATE*VDISK*PAGES*REVALIDATED'
RSARVLSUFO ='SHARED*PAGES*REVALIDATED'
RSARVLAGL ='GAL*PAGES*REVALIDATED'
RSAWRTONDMD ='DEMAND SCAN*WRITE-ON-DEMAND*FRAMES'
RSADSCYCLE ='ITERATIONS*DEMAND SCAN*MADE'
RSAUSRVISIT ='USERS*VISITED*PAGES WERE*MADE IBR'
RSAUSRSKIP ='USERS*SKIPPED*SERIAL/NET*SETTINGS'
RSAALSKL ='GAL FRAMES*NOT RECLAIMED*PINNED'
RSAALSKF ='GAL FRAMES*NOT RECLAIMED*FRAME*SERIAL'
RSAALSKP ='GAL FRAMES*NOT RECLAIMED*PAGE*SERIAL'
RSAALSKR ='GAL FRAMES*REQUEUED*NOT*RECLAIMED'
RSAAGRVLREFNW ='GAL REF ONLY*REVALIDATIONS*NO AUX'
RSAAGRVLREFWRT ='GAL REF ONLY*REVALIDATIONS*YES AUX'
RSAAGRVLCHGNW ='GAL CHG PAGES*REVALIDATIONS*NO AUX'
RSAAGRVLCHGWRT ='GAL CHG PAGES*REVALIDATIONS*YES AUX'
RSAAVAILCNTB2GS='FRAMES ON*LT 2G*SINGLES*AVAILABLE*LIST
RSAAVAILCNTB2GC='FRAMES ON*LT 2G*CONTIG*AVAILABLE*LIST'
RSAAVAILCNTA2GS='FRAMES ON*GT 2G SINGLES*AVAILABLE*LIST
RSAAVAILCNTA2GC='FRAMES ON*GT 2G*CONTIG*AVAILABLE*LIST'
RSAAVAILREQB2GS='REQUESTS*LT 2G*SINGLE*FRAMES'
RSAAVAILREQA2GS='REQUESTS*GT 2G*SINGLE*FRAMES'
RSAAVAILREQB2GC='REQUESTS*LT 2G*CONTIGUOUS*FRAMES'
RSAAVAILREQA2GC='REQUESTS*GT 2G*CONTIGUOUS*FRAMES'
RSAAVAILRETB2GS='RETURNS*LT 2G*SINGLE*FRAMES'
RSAAVAILRETA2GS='RETURNS*GT 2G*SINGLE*FRAMES'
RSAAVAILRETB2GC='RETURNS*LT 2G*CONTIGUOUS*FRAMES'
RSAAVAILRETA2GC='RETURNS*GT 2G*CONTIGUOUS*FRAMES'
RSAAVAILPTB2GC ='PROTECT*THRESH*CONTIG*LT 2G'
RSAAVAILPTA2GC ='PROTECT THRESH*CONTIG*GT 2G'
RSAAVAILPTB2GS ='PROTECT THRESH*SINGLES*LT 2G'
-Dataset VXSTORSP (3.02) new variables: 76 440 114 973
PFXAFOBC='LOCAL LIST*(LL)*FOBS'
PLSFOBLO='LL*LOW*THRESHOLD'
PLSFOBHI='LL*HIGH*THRESHOLD'
PLSFOB1E='LL*FOUND*EMPTY'
PLSFOB1T='TOD 1ST*TRIM REQUEST*FOR LL'
PLSFOBTM='TOD*MOST RECENT*TRIM REQ*FOR LL'
PLSSTPAG='IBR PAGES FOUND*CMM*ZERO STATE'
-Dataset VXSTOSHR (3.03) new variables: 8 120 114 1
ASCCTRSV='FRAMES*RESERVED*VIA*SET RESERVED'
ASCDSRSV='DEMAND*SCAN*NO MOVE*SET RSVD*PER SEC'
-Dataset VXSTOASI (3.14) new variables: 60 196 120 1809
ASCCTINS ='SHARED*INSTANTIATED*PAGES'
ASCCTIBRB2G ='SHARED*IBR PAGES*ON UFO*BACKED LT 2G'
ASCCTIBRA2G ='SHARED*IBR PAGES*ON UFO*BACKED GT 2G'
ASCCTAGLB2G ='SHARED*IBR PAGES*GAL*BACKED LT 2G'
ASCCTAGLA2G ='SHARED*IBR PAGES*GAL*BACKED GT 2G'
ASCCTRABISB2G='SHARED*NON-FAULT*IBR UFO*BACKED LT 2G'
ASCCTRABISA2G='SHARED*NON-FAULT*IBR UFO*BACKED GT 2G'
ASCCSINT ='SHARED*INSTANTIATED*PAGES'
ASCCSREL ='SHARED*RECLAIMED*GUEST*PAGE*STATE'
ASCCSINV ='SHARED*PAGES*MADE*IBR'
ASCCSPFI ='SHARE*IBR PAGES*REVALIDATED*ON UFO'
ASCCSPFA ='SHARED*IBR PAGES*REVALIDATED*ON GAL'
ASCCSFRY ='SHARED*IBR PAGES*ON GAL*BACK*RECLAIM'
ASCCSFNR ='SHARED*IBR PAGES*ON UFO*WRIT TO AUX'
ASCCSXRL ='XSTORE*BLOCKS*RELEASED*MIGRATION'
-Dataset VXSTOSHD (3.16) new variables: 20 120 164 1
ASCCTPRG='RESIDENT*PAGES GT 2G*THIS*SAVEDSEG'
ASCHLLC ='PAGES*LOCKED*HOST LOGICAL'
ASCHLRC ='HOST*LOGICAL*RESIDENT*COUNT'
ASCCTRSV='FRAMES*RESERVED*VIA SET*RESERVED'
ASCDSRSV='TIMES*DS NO MOVE*FRAMES*TO GLL'
-Dataset VXUSELON (4.01) new variables: 4 180 386 2889
VMDLOGFG='FLAG*BITS*SET AT*LOGON'
LCLFLAG3='GENERAL*FLAGS'
-Dataset VXUSELOF (4.02) new variables: 404 844 121 61
CALCPFNR ='UFO IBR*PAGES*WRITTEN*TO XSTORE'
CALCPFRY ='GAL IBR*PAGES*ALREADY*BACKED'
CALCPINT ='PRIVATE*INSTANTIATED*PAGES'
CALCPINV ='PRIVATE*PAGES*MADE*IBR'
CALCPPFA ='PRIVATE*IBR GAL*PAGES*REVALIDATED'
CALCPPFI ='PRIVATE*IBR UFO*PAGES*REVALIDATED'
CALCPREL ='PRIVATE*RECLAIMED*GUEST PAGE'
CALCPXRL ='XSTORE*BLOCKS*RELEASED*MIGRATION'
CALCTAGLA2G ='GAL IBR*PAGES*BACKED*GT 2G'
CALCTAGLB2G ='GAL IBR*PAGES*BACKED*LE 2G'
CALCTIBRA2G ='PRIVAGE*IBR PAGES*ON UFO*GT 2G'
CALCTIBRB2G ='PRIVAGE*IBR PAGES*ON UFO*LT 2G'
CALCTINS ='PRIVATE*INSTANTIATED*PAGES'
CALCTRABISA2G ='UFO/GAL*NONFAULT*IBR*GT 2G'
CALCTRABISB2G ='UFO/GAL*NONFAULT*IBR*LT 2G'
CALCTXBK ='EXPANDED*STORAGE*PAGING*BLOCKS'
LCLFLAGS='GENERAL*FLAGS'
MAXTOPO ='MAX*TOPOLOGY*LEVELS*ARCHITECTED'
OFFPLTL ='OFFSET TO THE VMUPLTL ARRAY'
OFFSTLTL='OFFSET TO THE VMUSTLTL ARRAY'
OFFTOPDA='OFFSET TO THE VMUTOPDA ARRAY'
OFFVMTL ='OFFSET TO THE VMUVMTL ARRAY'
VMDDSRSV ='DEMAND*SCAN*NOT MOVE*SET RESERVED'
VMDDTPLX='-USER ISSUED*DETACH COMMAND*CONSULTED SSI'
VMDDTTOD='TTIME*DETACH COMMANDS*CONSULTING SSI'
VMDDTTOT='-USER ISSUED*DETACH*COMMAND'
VMDLKPLX='-USER ISSUED*LINK COMMAND*CONSULTED SSI'
VMDLKTOD='TTIME*LINK COMMANDS*CONSULTING SSI'
VMDLKTOT='-USER ISSUED*LINK COMMAND'
VMDSTFHW ='HWM*STEAL*WEIGHT*FACTOR'
VMDSTLFC ='STEAL*WEIGHT*FACTOR'
VMDUFACTC ='UFO*ACTIVE*SECTION*FRAMES'
VMDUFIBRC ='IBR*SECTION*FRAMES'
VMDWASTE ='GAL*PRIVATE*PAGE FAULTS*IN AUX'
VMDWKPLX='-USER USED*WRKALLEG*CONSULTED SSI'
VMDWKTOD='TTIME*WRKALLEG*CONSULTING SSI'
VMDWKTOT='-USER USED*WRKALLEG'
VMUNRBAL='-CONFIGURATION*REBALANCES'
VMUREBAL ='RCCREBAL*COUNT*LAST*REBALANCE'
VMUTOPDX='INDEX*INTO*VMUTOPDA*ARRAY'
VMUTOPNE='ELEMENTS*THAT FIT IN*VMUTOPDA*ARRAY'
VMUTOPNS='SIZE *ONE ELEMENT*VMUTOPDA ARRAY'
-Dataset VXUSEACT (4.03) new variables: 404 844 121 61
CALCPFNR ='UFO IBR*PAGES*WRITTEN*TO XSTORE'
CALCPFRY ='GAL IBR*PAGES*ALREADY*BACKED'
CALCPINT ='PRIVATE*INSTANTIATED*PAGES'
CALCPINV ='PRIVATE*PAGES*MADE*IBR'
CALCPPFA ='PRIVATE*IBR GAL*PAGES*REVALIDATED'
CALCPPFI ='PRIVATE*IBR UFO*PAGES*REVALIDATED'
CALCPREL ='PRIVATE*RECLAIMED*GUEST PAGE'
CALCPXRL ='XSTORE*BLOCKS*RELEASED*MIGRATION'
CALCTAGLA2G ='GAL IBR*PAGES*BACKED*GT 2G'
CALCTAGLB2G ='GAL IBR*PAGES*BACKED*LE 2G'
CALCTIBRA2G ='PRIVAGE*IBR PAGES*ON UFO*GT 2G'
CALCTIBRB2G ='PRIVAGE*IBR PAGES*ON UFO*LT 2G'
CALCTINS ='PRIVATE*INSTANTIATED*PAGES'
CALCTRABISA2G ='UFO/GAL*NONFAULT*IBR*GT 2G'
CALCTRABISB2G ='UFO/GAL*NONFAULT*IBR*LT 2G'
CALCTXBK ='EXPANDED*STORAGE*PAGING*BLOCKS'
MAXTOPO ='TOPOLOGY*LEVELS*CURRENTLY*ARCHITECTED'
RDMMMASK='RELOCATION DOMAIN*MEMBER*MASK'
RDMNAME ='GUESTS*RELOCATION*DOMAIN*NAME'
VMDCTSTA='CPU*STARTS'
VMDCTSTO='CPU*STOPS'
VMDDSRSV ='DEMAND*SCAN*NOT MOVE*SET RESERVED'
VMDDTPLX='DETACH*COMMAND*SSI*CONSULTED'
VMDDTTOD='VIRTUAL TIME*DETACT*COMMANDS*SSI'
VMDDTTOT='DETACH*COMMANDS*ISSUED'
VMDLKPLX='LINK*COMMANDS*SSI*CONSULTED'
VMDLKTOD='VIRTUAL TIME FOR LINK*COMMANDS*SSI'
VMDLKTOT='LINK*COMMANDS*ISSUED'
VMDRLLST='LAST*RELOCATION*THIS*USER'
VMDSTFHW ='HWM*STEAL*WEIGHT*FACTOR'
VMDSTLFC ='STEAL*WEIGHT*FACTOR'
VMDUFACTC ='UFO*ACTIVE*SECTION*FRAMES'
VMDUFIBRC ='IBR*SECTION*FRAMES'
VMDWASTE ='GAL*PRIVATE*PAGE FAULTS*IN AUX'
VMDWKPLX='WRKALLEG*COMMANDS*SSI*CONSULTED'
VMDWKTOD='VIRTUAL*TIME*WRKALLED*COMMANDS*SSI'
VMDWKTOT='WRKALLEG*COMMANDS*USED'
VMUNRBAL='CONFIGURATION*REBALANCES'
VMUPLTL0='REBALANCES*EQUIVALENT*NL1'
VMUPLTL1='REBALANCES*DIFF NL1*SAME NL2'
VMUPLTL2='REBALANCES*DIFF NL2*SAME NL3'
VMUPLTL3='REBALANCES*DIFF NL3*SAME NL4'
VMUPLTL4='REBALANCES*DIFF NL4*SAME NL5'
VMUPLTL5='REBALANCES*DIFF NL5'
VMUREBAL ='RCCREBAL*COUNT*LAST*REBALANCE'
VMUSTLT0='STEALS*EQUIVALENT*NL1'
VMUSTLT1='STEALS*DIFF NL1*SAME NL2'
VMUSTLT2='STEALS*DIFF NL2*SAME NL3'
VMUSTLT3='STEALS*DIFF NL3*SAME NL4'
VMUSTLT4='STEALS*DIFF NL4*SAME NL5'
VMUSTLT5='STEALS*DIFF NL5'
VMUTOPDD='TOPOLOGY*DESCRIPTOR'
VMUTOPDI='DISPATCH*VECTOR*ID'
VMUTOPDX='ZERO-BASED*INDEX INTO*VMUTOPDA'
VMUTOPLU='PCT CPU*FOR HOME*DSVBK*ASSIGNMENT'
VMUTOPNE='ELEMENTS*THAT FIT IN*VMUTOPDA*ARRAY'
VMUTOPNS='ELEMENT*SIZE*VMUTOPDA*ARRAY'
VMUVMTL0='MOVES*EQUIVALENT*NL1'
VMUVMTL1='MOVES*DIFF NL1*SAME NL2'
VMUVMTL2='MOVES*DIFF NL2*SAME NL3'
VMUVMTL3='MOVES*DIFF NL3*SAME NL4'
VMUVMTL4='MOVES*DIFF NL4*SAME NL5'
VMUVMTL5='MOVES*DIFF NL5'
-Dataset VXUSEINT (4.04) new variables: 8 248 121 905
VMDRLLST='LAST*RELOCATION*OF THIS*USER'
-Dataset VXUSERLE (4.12) new variables: 8 248 121 905
LCLFLAGS ='LOCAL*RELOCATION*INFO*FLAGS'
RLOAIOCT ='ACTIVE*I/OS*ENCOUNTERED'
RLOCLNTM ='COMPLETION*DATETIME*FINAL*CLEAN UP'
RLOCONTM ='COMPLETION*DATETIME*INITIAL*ISFC CONNECT'
RLOCPCNT ='GUEST*PAGES*XFERED*FINAL PASS'
RLOCRETM ='COMPLETION*DATETIME*CREATION*SKELETON VMDBK'
RLOCRYTM ='COMPLETION*DATETIME*ENQUEUED*CRYPTO'
RLODSTRSV='RESERVED FRAME COUNT DESTINATION'
RLODSTSYS='DESTINATION*SYSTEM'
RLOELGTM ='COMPLETION*DATETIME*INITIAL*ELIG CHECKS'
RLOFCPTM ='COMPLETION*DATETIME*FCP I/O*DELAY'
RLOFINCD ='RELOCATION*ENDED*REASON*CODE'
RLOIOCTM ='COMPLETION*DATETIME*I/O CONFIG*RELOCATION'
RLOIOETM ='COMPLETION*DATETIME*FINAL I/O*ELIG CHECKS'
RLOISSUER='VMRELOCATE*CMD*ISSUER'
RLOLSTTM ='COMPLETION*DATETIME*LAST*MEMORY'
RLOMAXQ ='MAXQUIESCE*TIME'
RLOMAXT ='MAXTOTAL*TIME'
RLOMEMPS ='MEMORY*PASSES*DURING*RELOCATION'
RLOMEMTM ='COMPLETION*DATETIME*MEMORY*TRANSFER-2'
RLOMVOPT ='FLAG BYTE*FOR CMD*OPTIONS'
RLONQDCT ='NON-QDIO*TYPE*I/OS*CLEARED'
RLOPASSA ='GUEST*PAGES*XFERED*FIRST PASS'
RLOPASSY ='GUEST*PAGES*XFERED*PENULTIMATE*PASS'
RLOPENTM ='COMPLETION*DATETIME*PENULTIMATE*MEMORY'
RLOPSAVG ='AVERAGE*GUEST*PAGES*XFERED*2 THRU N-2'
RLOQDCT ='QDIO*TYPE*I/OS*CLEARED'
RLOQUITM ='COMPLETION*DATETIME*GUEST*QUIECE'
RLORESTM ='COMPLETION*DATETIME*RESUMPTION*GUEST'
RLOSETTM ='COMPLETION*DATETIME*STMGT*SET UP'
RLOSMETM ='COMPLETION*DATETIME*STMGT*ELIG CHECKS'
RLOSRCRSV='RESERVED*FRAME*COUNT*SOURCE'
RLOSRCSYS='SOURCE*SYSTEM'
RLOSTARTM='DATETIME*START OF*RELOCATION'
RLOSTATM ='COMPLETION*DATETIME*VIRT STATE*RELOCATION'
RLOUSER ='USERID OF*RELOCATION*TARGET'
RLOVDXCT ='VIRTUAL*DEVICES*TRANSFERRED'
RLOVSETM ='COMPLETION*DATETIME*VSIM*ELIG CHECKS'
VMDSTRLO ='SET*VMRELOCATE*FLAGS'
-Dataset VXIODDEV (6.03) new variables: 200 180 76 1
RDEVSKSM64='CUM*DASD*ACCESS*MOVEMENT'
RDEVFCXM ='MASK OF*PATHS*SUPPORT*ZHPF'
CUIFCXP ='ZHPF*FEATURES*SUPPORTED'
RDEVMAXD ='SMALLEST*ZHPF*MAX*DATA COUNT'
RDEVWXCT ='TM(ZHPF)*WRITE*CHAN*PROGRAMS'
RDEVRXCT ='TM(ZHPF)*READ*CHAN*PROGRAMS'
SCMIDTIM ='SCM*INTERRUPT*DELAY*TIME'
SCMPDTIM ='SCM*I/O*PRIORITY*DELAY*TIME'
PAVIDTIM ='ACCUMULATED*INTERRUPT*DELAY*TIME'
PAVPDTIM ='I/O*PRIORITY*DELAY*TIME'
-Dataset VXIODCAD (6.04) new variables: 52 312 190 2665
Short length record doesn't input CALPSF due to this
PROTECTED: Segment Length is 312.
Fixed 68 bytes, 192 CALDATA 4 CALSSS2 leave only
48 bytes but CALPSF is documented as 192 bytes,
so Segment Length should be 576 vs 312.
-Dataset VXIODVSW (6.21) new variables: 212 344 185 1185
LANTRID ='ACTIVE TRACE IDS'
LANSUSR ='USERS IN LINUX*SNIFFER*MODE'
LANMGIPA ='LAN MANAGEMENT IP ADDRESS'
MGSWIEUSER='LAN MANAGEMENT USER ID'
MGNICMAC ='VSWITCH MAC ADDRESS'
OSAMAC ='OSA DEVICE MAC ADDR'
NICTRANP ='SESSION LAYER(2 OR 3)'
LANID ='LAN*OWNER*NAME'
LOCKREQS ='LOCK REQUESTS*FOR LANLKWRD*NETWORKLOCK'
LANDEFER ='WAITS FOR*NETWORK*LANLKWRD*LOCK'
TXDEFERS ='WAITS FOR*LOCK WHEN*SENDING FROM*THIS PORT'
RXDEFERS ='WAITS FOR*LOCK WHEN*RECEIVING*ON THIS PORT'
NICTXPKT64='PACKETS*SENT*REAL DEVICE*VIRTUAL SWITCH'
NICTXDSC64='VALID*OUTBOUND*PACKETS*DISCARDED'
NICTXERR64='INVALID*OUTBOUND*PACKETS*DISCARDED'
NICRXPKT64='PACKETS*RECEIVED*REALDEVICE*VIRTUAL SWITCH'
NICRXDSC64='VALID*RECEIVED*PACKETS*DISCARDED'
NICRXERR64='RECEIVED*PACKETS*DISCARDED*INVALID*FORMAT'
SWPGROUP ='LINK AGG*PORT GROUP*IN USE*VIRT SWITCH'
VQSOMLVL ='OSA*DEVICE*MICROCODE*LEVEL'
SWPINTSC ='SECONDS*BETWEEN*LOAD*BALANCING*OPERATIONS'
VQSDVMAC ='OSA DEVICE*VIRTUAL*MAC ADDRESS'
VQSMRKCT ='MARKER*PDUS*SENT TO*THIS PORT'
VQSMRPCT ='MARKER*RESPONSES*RECEIVED'
VQSMRRCT ='MARKER*RESPONSES*PDUS SENT TO'
VQSMTOCT ='TIME OUTS*FOR MARKER*RESPONSE*WAITS'
VQSLCSCT ='LACP PDUS*SENT ON*THIS PORT'
VQSLCRCT ='LACP PDUS*RECEIVED ON*THIS PORT'
TXREQS ='LOCK REQUESTS*MADE WHEN*SENDING'
RXREQS ='LOCK REQUESTS*MADE WHEN*RECEIVING'
STKREQS ='REQUESTS*TO STACK OR*TO UNSTACK*WORK'
STKDEFERS='TIMES*MULTIPLE*ATTEMPTES*TO STACK'
VQSPATTR1='PARTNER*SWITCH*BYTE 1'
VQSPATTR2='PARTNER*SWITCH*BYTE 2'
VQSPATTR3='PARTNER*SWITCH*BYTE 3'
VQSPATTR4='PARTNER*SWITCH*BYTE 4'
-Dataset VXIODMDE (6.31) new variables: 4 84 2048 1385
RDE RDEVDEV ='REAL*DEVICE*NUMBER'
-Dataset VXVNDSES (8.01) new variables: 12 304 289 889
VMDRLLST='LAST*RELOCATION*THIS*USER'
NICMGPOR='PORT*VALUE*FOR GUEST*CONNECTION'
-Dataset VXISFNOD (9.04) new variables: 4 304 897 156
LNKCAPCT='NOT-FULL*PACKAGES*CLOSED*TIMEOUT'
-Dataset VXAPLTC0(10.02) new variables: 28 636 301 1
Corrections made:
APLSDT segments with undocumented new fields:
for MDGPROD='5735FALST'-'00'x-'054000' +28 636
for MDGPROD='5735FALST'-'00'x-'061000' +4 612
The documentation for APPLDATA is here:
http://www.vm.ibm.com/perf/docs/appldata.html
-New Datasets Created:
-Dataset VXPRCPUP (5.16) new dataset: 520 500 386 625
CALFCONF='CONFIDENCE*PERCENTAGE*FLOOR*PROJECTION'
CALFLAG ='FLAG*BYTE'
CALFLALG='ALGORITHM*USED*FLOOR*PROJECTION'
CALUCALG='ALGORITHM*USED FOR*CEILING*PROJECTION'
CPUTYPE ='CPU*TYPE'
MAXRPROC='VALID*BITS*IN*MASKS'
OFSLCPUA='OFFSET TO*SRXLCPUA FIELD'
OFSONLIN='OFFSET TO*CALONLIN FIELD'
OFSUPKMK='OFFSET TO*RCCUPKMK FIELD'
RCCNUPK ='CPUS*REQUESTED*TO BE IN*UNPARKED*STATE'
RCCSIGCT='-SUCCESSFUL*SIGP*RESTARTS'
RCCSIGTD='-TIME SPENT*IN*SIGP*RESTARTS'
SCOUNT ='STANZAS*IN THIS*RECORD'
SOFFSET ='OFFSET TO FIRST STANZA'
SRXCPPAD='CPU*CAPACITY*ADDED*TO CEILING'
SRXNOTVH='CAPACITY*ASSIGNED*CPUS NOT*VERTICAL HIGH'
SRXPMAX ='MAX NUMBER*CPUS THAT*CAN BE*PARKED'
SRXWRKCI='CONFIDENCE*PERCENTAGE*CEILING*PREDICTION'
SSIZE ='STANZA*SIZE'
WHIOCECE='EXCESS*PROCESSOR*CAPACITY*AVAILABLE'
WHIOCUTI='NUMBER OF*PHYSICAL*CPUS*CONSUMED'
WHIOCXC ='SHARE OF*EXTRA*CAPACITY'
WHIOENT ='CPU*RESOURCE*ENTITLEMENT'
WHIOFLG ='FLAGS FOR THIS PARTITION'
WHIOPUTI='CEILING*PREDICTION*OF CPU*UTILIZATION'
WHIOPXC ='UNENTITLED*CAPACITY*FLOOR*PROJECTION'
WHIOUCT ='VALID*SAMPLES FOR*CEILING*PREDICTION'
WHIOXCT ='VALID*SAMPLES FOR*FLOOR*PROJECTION'
WHIUCT ='VALID*SAMPLES*CEILING*PREDICTION'
WHIXCT ='VALID*SAMPLES*FLOOR*PROJECTION'
Corrections made:
a. Undocumented 8 bytes after RCCSIGTD.
b. SSIZE is 92 bytes but only 52 bytes are
documented for CPUTYPE-SRXNOTVH fields.
c. OFFSET SOFFSET is 60 from start of record
for 92 bytes, but these other offset values
OFSUPKMK=68, OFSONLIN=76, OFSLCPUA=84, all
point inside those 92 bytes.
d. And, RCCUPKMK, CALONLIN, and SRXLCPU are all
shown as one byte fields, but those offsets
indicate they are all 8 bytes separated.
the fields are 8 bytes but only first used
and the remaining 7 should have been rsvd.
-Dataset VXPRCRCD (5.17) new dataset: 88 68 74 3601
CALENTMT='VERTICAL*CPU*ENTITLEMENT'
CALMNEST='CONFIG*TOPOLOGY*FACILITY*SELECTOR'
MAXTOPO ='MAX*TOPOLOGY*LEVELS*ARCHITECTED'
OFFSTLTL='OFFSET TO*PLSSTLTL*ARRAY'
OFFTOPDS='OFFSET TO*RCCTOPDS*FIELD'
PFXCPUAD='PROCESSOR ADDRESS'
PFXPOLAR=' CURRENT*POLARIZATION'
RCCTOPDI='DSVBK*INDEX*FOR CPU'
RCCTOPDS='TOPOLOGY*DESCRIPTOR*CONTAINER*IDS'
SIZTOPDS='SIZE*OF*RCCTOPDS*FIELD'
Corrections made:
a. MRHCRLEN=88 but DOC shows 60 bytes fixed and doc
RCCTOPDS Length is 32, but only 28 bytes are left
in the record.
b. Offset OFFTOPDS=60, but OFFSTLTL=64 which would
be four bytes into the RCCTOPDS field.
-Dataset VXPRCDHF (5.18) new dataset: 88 68 74 3601
CALDSVID='DSVBK*ID'
CPUTYPE ='CPU*TYPE'
HFCOUNT ='HIGH*FREQUENCY*SAMPLES*THIS DSVBK
HFUSERC ='-VMDBKS*IN DSVBK*WHEN NOT*EMPTY'
HFUSERZ ='TIMES WHEN*DSVBK*HAD NO*VMDBKS'
MAXRPROC='VALID*BITS*IN*MASKS'
OFSASSOC='OFFSET TO*DSVASSOC*FIELD'
OFSUNPRK='OFFSET TO*DSVUNPRK*FIELD'
RCCDSVCH='CPU-TO-DSVBK*ASSIGNMENT*CHANGES'
SCOUNT ='STANZAS*IN THIS*RECORD'
SOFFSET ='OFFSET TO FIRST STANZA'
SSIZE ='STANZA*SIZE'
SYSDVENT='MAX USERS*ALLOWED IN*A DSVBK'
Corrections made:
a. PRCHDF_STANZA is documented with 16 bytes
but SSIZE=32.
b. Similar to preceding, the SOFFSET=40 but
OFSASSOC=16 and OFSUNPRK=24 which I don't
understand, since they would precede the
STANZA data.
Change 31.150 RMF III Enhancements, Fixes, new DYNAMIC METHOD.
ADOCRMFV -A new procedure for executing ASMRMFV is now available
ASMRMFV called the Dynamic Method. This approach combines the
JCLCRMFV simplicity of the current Direct JCL method with the
JCLDRMFV convenience of catalog lookup and dynamic allocation
JCLRMFV provided by the current TSO Clist method. See JCLDRMFV.
VMACRMFV -A new INDSNAME= keyword parameter (aliases INDSN=, INDS=,
Jul 23, 2013 IDS=, I=) is now supported that allows the specification
Jul 26, 2013 of 1 to 256 data set name patterns. The patterns are
used to retrieve matching VSAM cluster entries by the
Catalog Search Interface (CSI), an IBM supported and
documented program service.
NOTE: The CSI call is set to only retrieve VSAM
Clusters (and related Data and Index components).
Non-VSAM data sets and other VSAM entry types are not
returned. Only a very small fraction of the data in a
Cluster entry is returned (Type, CISIZE, RECSIZE).
-Each returned data set name entry is validated as being
a VSAM RRDS data set with the correct CISIZE and RECSIZE
for an RMF Monitor III data set. Then each in turn is
dynamically allocated to an RMFD* DDNAME beginning with
RMFD0000. Later each is opened in turn for further
processing by ASMRMFV. But the TESTCSI parameter (see
below) can modify this behavior.
NOTE: Static RMFV* style DD statements may still be
hard coded in JCL even when the Dynamic Method is used
and will be processed as usual. However, this tends
to defeat the intent and value of the Dynamic Method.
-INDSNAME= pattern masking characters include the use of
** and * as multiple character substitutes and % (percent
sign) as a single character placeholder.
-Pattern coding rules and examples are fully provided in
both the ASMRMFV source code prologue and in the updated
ADOCRMFV member. They are also documented in the IBM
DFSMS Managing Catalogs manual for your z/OS release, in
the section Catalog Search Interface User's Guide.
NOTE: Be careful to avoid overlapping data set patterns
using INDSNAME= which could cause duplicate data to be
processed into ASMRMFV. The TESTCSI parameter (see
below) can help check for this in advance. ASMRMFV
does NOT check for or exclude duplicate data. The same
issue could exist using static JCL DD allocation as
well and is NOT exclusive to the Dynamic Method.
-A new parameter TESTCSI/NOTESTCSI (default NOTESTCSI)
controls pattern testing that is especially useful when
setting up the Dynamic Method for the first time.
-TESTCSI (alias TESTC) only retrieves data from catalogs
using CSI and the INDSNAME= patterns. No dynamic
allocation or file processing occurs. TESTCSI thus
provides a preview of search results with the user
pattern settings. This can prevent the retrieval of
large numbers of unneeded data sets that are not RMF
Monitor III files.
-NOTESTCSI (alias NOTESTC) retrieves data from catalogs
using CSI and the INDSNAME= patterns, dynamically
allocates valid found files, and allows full normal
processing by ASMRMFV.
-WARNING: Users are strongly recommended NOT to use the
all inclusive search pattern INDSNAME=** as that will
retrieve all VSAM Clusters in their catalogs. This will
likely return thousands of entries and can result in a
possible performance impact on the catalog management
function while in progress that could affect other work.
-The ADOCRMFV member which contained mostly development
notes from 2008 and earlier has been completely replaced
with the ASMRMFV source documentation. This was made
much more readable by the removal of many embedded
assembler language statements. The ASMRMFV prologue
documentation in source remains available as before.
-A new documentation member JCLDRMFV contains ASMRMFV
execution examples using the new Dynamic Method.
-JCLRMFV, JCLCRMFV, and JCLDRMFV documentation members now
all contain a table that compares and contrasts the 3
available methods to execute ASMRMFV.
-The MXG00 table version is raised from X'02' to X'03 and
adds the maximum number of entries supported in the new
DSN Pattern Table (currently 256).
-When an invalid parameter length is detected message
RMFV004E will now also display the invalid length.
-When a date or time parameter related error is detected
ASMRMFV will no longer abend immediately but instead
postpone the abend until all parameters are processed.
This will permit all parameter errors to be found in a
single run.
-When the RCD table is selected the unnecessary selection
of the SVP table will no longer be automatically forced.
ASMRMFV will still read the SVP to obtain required data,
but will not output the SVP unless specifically selected.
-Ten new ASMRMFV parameters are added for consistent user
directed control of error conditions (see more below).
-Each has 3 possible values of ABEND (alias A), IGNORE
(alias I), or WARN (alias W). Before control of these
conditions was inconsistent, difficult to alter, or
simply not available.
-ASMRMFV messages RMFV004*, RMFV016*, RMFV017*, RMFV029*,
RMFV033*, RMFV048*, and RMFV049* (*=I,W,E,S) are now
multi-severity based on the settings of these error
control parameters.
-ABEND causes ASMRMFV to issue an error message RMFV***E
and immediately terminate with a U0998 Abend.
-WARN results in an RMFV***W warning message then sets a
return code of 4 and execution continues.
-IGNORE issues an informational message RMFV***I, leaves
the return code unchanged and execution also continues.
-ALLOCERR=ABEND/IGNORE/WARN directs ASMRMFV when a dynamic
allocation of an RMF Monitor III data set fails (default
WARN).
NOTE: Look for messages on the Job JESLOG for more
details on dynamic allocation errors.
-ATTRERR=ABEND/IGNORE/WARN directs ASMRMFV when a VSAM
RRDS found during a CSI search has an attribute error for
an RMF Monitor III data set either an invalid CISIZE not
32768 or an invalid LRECL not 32752 (default WARN).
-CATERR=ABEND/IGNORE/WARN directs ASMRMFV when a catalog
entry retrieval error occurs during a CSI search (default
WARN). Catalog damage is possible.
NOTE: For Return and Reason Code details on a catalog
retrieval error consult the IBM documentation for
message IDC3009I for the same respective codes.
-DEADERR=ABEND/IGNORE/WARN directs ASMRMFV when an RMF III
data set has probable dead space due to high usage of
indexes (default WARN). Reallocation to a smaller size
may be appropriate.
-DSIGERR=ABEND/IGNORE/WARN directs ASMRMFV when the table
ID for an RMF III data set header/index record is not
'DSIG3' as expected (default WARN). This can be due to
an "imposter" data set, a VSAM RRDS with correct CISIZE
and RECSIZE for an RMF III file but does in fact NOT
contain valid RMF III data.
-DSNERR=ABEND/IGNORE/WARN directs ASMRMFV when a data set
entry retrieval error occurs during a CSI search (default
WARN). Data set damage is possible.
NOTE: For Return and Reason Code details on a data set
retrieval error consult the IBM documentation for
message IDC3009I for the same respective codes.
-EMPTYERR=ABEND/IGNORE/WARN directs ASMRMFV when an RMF
Monitor III data set opened during processing contains no
data (default IGNORE). This can validly occur for
several reasons. See documentation for this parm.
-PATTERR=ABEND/IGNORE/WARN directs ASMRMFV when a data set
name pattern error is detected for the INDSNAME=
parameter (default WARN). This is usually a user error.
-READERR=ABEND/IGNORE/WARN directs ASMRMFV when a read I/O
error occurs processing an RMF III Monitor data set
(default ABEND). Can be due to a truncated file.
-TYPEERR=ABEND/IGNORE/WARN directs ASMRMFV when a VSAM
data set type other than a RRDS is found during a CSI
search (default WARN). The INDSNAME= pattern may be too
general causing retrieval of many non-RMF III files.
-The old ASMRMFV parameter ABREAD is now equivalent to
READERR=ABEND and is still supported.
-The old ASMRMFV parameter NOABREAD is now equivalent to
READERR=WARN and is still supported.
-12 new messages RMFV040I to RMFV051I are added to support
Catalog Search Interface usage and results.
-7 new messages RMFV060I to RMFV066W are added to support
dynamic allocation usage and results.
-New message RMFV036I shows selection settings for all RMF
III tables at ASMRMFV initialization.
-New message RMFV037I shows selection settings for all
other ASMRMFV parameters at initialization including the
new error condition keywords.
-CSI work area buffer statistics are shown when the
BUFFERS parameter is used.
-A new parameter CSISTAT/NOCSISTAT controls statistics
information about the CSI user work area buffer (default
NOCSISTAT). CSISTAT (alias CSIS) shows the total size
and size used of the buffer for each CSI call in message
RMFV047I. NOCSISTAT (alias NOCSIS) suppresses the
message.
NOTE: Starting with an initial CSI workarea size of 64K
ASMRMFV will dynamically increase the size of the CSI
work area up to a maximum of 1 MB when a RESUME CSI
call is needed because the buffer was too small for the
number of entries retrieved.
-When a GETMAIN/FREEMAIN storage error occurs severe
message RMFV007S now includes the number of bytes and
subpool involved. This should be a rare event but always
results in an abend.
-When the BUFFERS parameter was active the Summary report
did not include the final program FREEMAINs at program
termination.
-ASMRMFV will no longer attempt to process RMF Monitor III
data sets that are not CISIZE 32768 or RECSIZE (LRECL)
32752. IBM messages ERB824I and ERB825I document that
only the CISIZE and RECSIZE values used in ERBVSDEF Clist
to DEFINE RMF III data sets are correct.
-Performance: ASMRMFV was incorrectly freeing and
allocating a new buffer for every MINTIME sample.
-Performance: Sample buffer adjustment factor of 1 in
&MULTS symbolic parameter was ineffective in reducing
additional GETMAINs, so has been lowered to 0 to avoid
wasting unused buffer space.
-Performance: Policy buffer adjustment factor of 1 in
&MULTP symbolic parameter was ineffective in reducing
additional GETMAINs, so has been lowered to 0 to avoid
wasting unused buffer space.
-Four internal ASMRMFV message tables have been
consolidated into a single table to relieve message
addition restrictions.
-Message RMFV016* generated when an expected versus actual
RMF III table id mismatch occurs now includes the actual
found table id in both character and hexadecimal.
-ASMRMFV prologue documentation has been updated for all
new parameters, for details on pattern match usage, and
expanded for return code 4.
NOTE: The TSO Clist method is not planned for any
further enhancement and may become archaic. TSO Clist
Method users are encouraged to trial and migrate to the
Dynamic Method which should be vastly superior in ease
of use and likely in performance as well.
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change must
be installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
Change 31.149 Change 30.203 broke the ability to use _GRPMNNM/_GRPMNCD
ASUMTAPE to define an additional variable (e.g., LOCATION) causing
Jul 22, 2013 ERROR: VARIABLE LOCATION NOT FOUND.
The KEEPs= for JES3MNT, JES510, and JES5918 needed macro
_GRPMNNM added, and _GRPMNCD was needed in the logic for
JES3MNT, even though this was a JES2 site.
Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
Change 31.148 Documentation. The denominator D1 in NORM1=A B / D1 in
VMXGSUM your VMXGSUM invocation must be a variable, and can not
Jul 22, 2013 be an expression. Unfortunately, while some earlier
VMXGSUM releases did permit NORM1=A B /(C+D) syntax, that
was NEVER intended and is NOT supported; it's just too
deep in working logic to risk the exposure, when you can
use this logic in your VMXGSUM to create a variable with
an expression: INCODE=E=C+D; and then NORM1=A B/E.
Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
Change 31.147 Support for CANPROD4, CANPROD5, and CANPROD6 optional
IMACICVC CICS segments creates same-named variables:
IMACICVD CMODHEAD
IMACICVE and Tailor
IMACAAAA Variable: Member
UTILEXCL CANPROD4 IMACICVC
VMAC110 CANPROD5 IMACICVD
Jul 19, 2013 CANPROD6 IMACICVE
Jul 29, 2013 -UTILEXCL wasn't updated until Jul 29, after 31.05 was GA.
Change 31.146 -INPUT STATEMENT EXCEEDED RACF UNLOAD 0506 short record.
EXRAC206 The documented length is 534 bytes, including two "user"
IMACRACF fields documented in fixed locations (bytes 270-525 and
VMACRACF 527-534) but this record was only 285 bytes. The first
VMXGINIT 269 bytes contained valid/expected data, but the two user
Jul 22, 2013 fields did not exist as documented. However, the record
does contain three fields of 3,8,4 bytes, so this change
detects the short record and only inputs what's left in
the record into variable USERDATA.
-INPUT STATEMENT EXCEEDED RACF UNLOAD 0510 short record.
Unlike the above short 0506, this one instance was only
262 bytes long, ending after CLASS with no user segment.
-Support for RACF UNLOAD 0206 RSAF DATA record creates new
RACF0206 dataset.
-Missing value messages were eliminated by improved logic.
Thanks to Florent Boulesteix, INOVANS partenaire CAAGIS, FRANCE.
Change 31.145 INPUT STATEMENT EXCEEDED for QAPMHDWR infile because the
VMACQACS two fields SWTMOD and DORESR do not exist in V5.4.0 data
Jul 18, 2013 records. Their INPUT is now conditional on being there.
Thanks to Clayton Buck, UNIGROUP, USA.
Change 31.144 Updates for SMF 83 Subtypes 2 thru 6.
VMAC83 Incomplete, await data records.
Jul 20, 2013
Change 31.143 -ID=120 ST=9 WebSphere TYP1209E variables are accumulated
VMAC120 if there is more than one observation per enclave token,
Jul 19, 2013 a not-documented-feature observed in the data. TYP1209E
Jul 26, 2013 is now sorted by SYSTEM,SM1209CR,CY,CV,CH,SM1209CM and
variables SM1209DA/DB/DC/DD/DE/SM1209DF are deaccumulated
if the obs is NOT (FIRST.SM1209CH AND LAST.SM1209CH), as
those are single-instance-per-enclave-token observations
whose CPU time is not accumulated. Use TYPS120 instead
of TYPE120 so that TYP1209E data is deaccumulated, or
%INCLUDE SOURCLIB(TYPE120); _ST1209E ; RUN; to invoke
the dataset sort macro, where MXG does deaccumulation.
-ID=120 ST=9 WebSphere variable SM1209DI, zAAP CPU time,
is now normalized by SM1209DG/256. While the zIIP time
in SM1209DF returned by WLM is normalized, and the part
of SM1209DH from zIIP and zAAP is normalized, SM1209DI
is returned by WLM in raw time units.
-ID=120 ST=9 WebSphere variable SM1209CI is now labeled
SM1209CI=TOTAL*CP+ZIIP+ZAAP*TCB CPU*TIME as it contains
TOTAL CPU time on all engines. Variable SM1209CX is the
portion of SM1209CI that was executed on the zIIP or zAAP
Specialty engine. If your CP engines are knee-capped,
i.e., slower than the zIIP speed, then the CPU time in
SM1209CX for the zIIP time (which is also included in
SM1290CI) will be the normalized (LARGER) CPU time value,
since that's what applications return for CPU time on
specialty engines. (E.g., documented that the CPUTM in
CICSTRAN can be greater than ELAPSTM for transactions
using zIIP/zAAP with slow CP engines.)
See this white paper, by David Follis, looking at WAS 120-9 analysis:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102311
Thanks to Joe Faska, Depository Trust, USA.
Change 31.142 Support for User CICS Fields listed below.
IMACICV6 New Variable CMODHEAD CMODNAME
IMACICV7 IMACICV6 MSG@ MSG/APPL
IMACICV8 IMACICV7 EGTBS EGTBS
IMACICV9 IMACICV8 FROMCORR FROMCORR
IMACICVA IMACICV9 TOCORR TOCORR
IMACICVB IMACICVA EGMSGID EGMSGID
UTILEXCL IMACICVB PROGNAME PROGNAME
VMAC110
Jul 18, 2013
Change 31.141 DIVISION BY ZERO in ANALPRTR. One of the two calculations
ANALPRTR of printer THRUPUT didn't test THRUTM, the denominator,
Jul 17, 2013 for a non-zero value before a divide. Since a zero is a
valid value, there was no actual error; variable THRUPUT
is a missing value, with or without the test added by
this change before the divide that prevents that message.
Thanks to Jessie Gonzales, California State Controller's Office, USA.
Change 31.140 MXG 31.03-31.04, SMF70GNM, Group Name variable was always
VMAC7072 blank in PDB.TYPE70PR dataset, causing Group Capacity
Jul 17, 2013 datasets ASUM70GC/ASUM70GO to have zero observations.
MXG's bit 1 test in SMF70PFL was incorrectly changed in
31.03 causing group name to be replaced with blanks.
Thanks to Don Shelton, Time Customer Service, Inc., USA.
Change 31.139 Support for RACF TOKDANAM='UNAME' creates new variable
VMAC80A TOKUNAME in dataset TYPE80TK.
Jul 17, 2013
Thanks to Clayton Buck, UNIGROUP, USA.
Change 31.138 If you have multi-period workloads defined in RMFINTRV,
VMXGRMFI the period 1 RSP TRN SWP variables were mislabeled with
Jul 16, 2013 the workload name (BAT1) rather than the label (BATHI).
Thanks to Patricia J. Jones, DST Systems, USA.
Change 31.137 IMF TRANSACTION EXTENSION variables TRXZxxxx were wrongly
VMACCIMS INPUT @TRXPTIMO but are now INPUT @TRNEXTEN+TRXPTIMO, and
Jul 16, 2013 TRX1FL1,TRX1FL2, and TRX1_LDS variables are now correctly
input and kept in CICSTRAN data.se.
Thanks to Sieghart Seith, Fiducia IT AG, GERMANY.
Change 31.136 -IIS Log with unexpected ' ... ' COOKIE value caused CPU
VMACWWW loop; MXG expected an equal sign in COOKIE text, now
Jul 16, 2013 protects for no equal sign. Browser was Mozilla/5.0.
Jul 26, 2013 -Mozilla browser created unexpected URIQUERY value,
with a leading equal sign and without a URIQNAME that
also caused MXG to loop.
Thanks to Xiaobo Zhang, Fiserv, USA.
Change 31.135 If you used the _GRPALNM macro to subset ASUMTALO, the
ASUMTALO time range of the data could be limited to the time range
Jul 15, 2013 of a single system (if SYSTEM is what was added). Now,
if we detect that you have used _GRPALNM, then all data
will be input to ASUMTALO.
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 31.134 The TIMESTAMP, BEGINTIME, ENDTIME values were wrong for
VMACXDFG HH of 12 with PM suffix (only PM hours 1-11 need +12),
VMACXDNS or for HH 12 with AM suffix (must reset HH=00).
VMACXDSP
Jul 16, 2013
Change 31.133 Support for TMON for DB2 Version 5 second iteration.
VMACTMD2 -DA and DB records were INCOMPATIBLY changed with removal
Jul 16, 2013 of 11660 and 5680 uncompressed reserved bytes, but there
was no change in the variables created in TMD2DA/TMD2DB
datasets. Fields DALHRECC/DBLHRECC are used to identify
and transparently process both record formats.
Note: Jul 2014, dataset TMD2DB replaced TMDBDB2 dataset.
-IG record was COMPATIBLY changed creating 2 new variables
IGGBGR1C='CURRENT*DIRECTORY*ENTRY'
IGGBGR2C='PENDING*DIRECTORY*ENTRY'
in TMD2IG dataset from previously reserved areas.
-Three TMON PTFs: TE03897, TEO3904, and TE03910 make these
changes in the TMON for DB2 records.
Change 31.132 Change 31.077 (PRCMFC 5.13 z/VM 6.2) was tested, sent,
VMACVMXA and validated, but that VMACVMXA was NOT moved into the
Jul 10, 2013 master MXG source, causing BROKEN CONTROL RECORD ERROR.
CFVN=1 CSVN=3 SKIP= still had 1708 instead of 1664.
Thanks to David J. Schumann, BCBS of Minnesota, USA.
Change 31.131 Using EXUTILEX to create a tailored IMACEXCL no longer
UTILEXCL works with recent UTILEXCL (31.02 for example) when there
EXUTILEX are two triplets with that CMODHEAD name, and it's not
IMACICUS yet clear why nor when it stopped working. If you have
Jul 9, 2013 an EXUTILEX member and its associated IMACICUS member,
please send them to support@mxg.com so they can be added
with a new IMACICxx member, which is now the correct way
to support user segments in CICSTRAN records.
-I will try to resolve and reinstate EXUTILEX support
and will update this note if/when that is accomplished.
At present, however, the second instance causes a SYNTAX
error citing the first variable in the EXUTILEX INPUT.
Thanks to Kim Nguyen-Thi, IBM, AUSTRALIA.
Thanks to Paul Gillis, IBM, AUSTRALIA.
Change 31.130 Corrections to zIIP/zAAP SHARE WEIGHTS in RMF 70 data.
VMAC7072 Change 30.106 did not correctly calculate the initial and
VMXG70PR current SHAREs for the zIIP engines, didn't create SHAREd
Jul 20, 2013 variables for the zAAP engines, and revisions to labels
now identify CP, ZAAP, or ZIP metrics.
TYPE70 dataset: the "LPAR" values are for this zOS system
while the "TOTAL" values are for the entire CEC.
TYPE70 SHARE WEIGHT variables in TYPE70:
TOTSHARC='TOTAL*CURRENT*CP SHARE*WEIGHT'
TOTSHARE='TOTAL*INITIAL*CP SHARE*WEIGHT'
ZIPSHARC='TOTAL*CURRENT*ZIIP SHARE*WEIGHT'
ZIPSHARE='TOTAL*INITIAL*ZIIP SHARE*WEIGHT'
IFASHARC='TOTAL*CURRENT*ZAAP SHARE*WEIGHT'
IFASHARE='TOTAL*INITIAL*ZAAP SHARE*WEIGHT'
LPARSHAC='LPAR*CURRENT*CP SHARE*WEIGHT'
LPARSHAR='LPAR*INITIAL*CP SHARE*WEIGHT'
LZIPSHAC='LPAR*ZIIP SHARE*CURRENT*WEIGHT*PCT'
LZIPSHAR='LPAR*ZIIP SHARE*INITIAL*WEIGHT*PCT'
LIFASHAC='LPAR*ZAAP SHARE*CURRENT*WEIGHT*PCT'
LIFASHAR='LPAR*ZAAP SHARE*INITIAL*WEIGHT*PCT'
ASUM70PR and ASUMCEC variables exist per LPAR:
LPnSHARC='LPAR n*SHARE*CURRENT*CP WEIGHT*PCT'
LPnSHARE='LPAR n*SHARE*INITIAL*CP WEIGHT*PCT'
LPnZIPSC='LPAR n*ZIIP SHARE*CURRENT*WEIGHT*PCT'
LPnZIPSH='LPAR n*ZIIP SHARE*INITIAL*WEIGHT*PCT'
LPnIFASC='LPAR n*ZAAP SHARE*CURRENT*WEIGHT*PCT'
LPnIFASH='LPAR n*ZAAP SHARE*INITIAL*WEIGHT*PCT'
Thanks to Lindholm Orjan, VOLVO, SWEDEN.
Change 31.129 Support for CICS User CIFAUDIT field.
IMACICV5
UTILEXCL
VMAC110
Jul 8, 2013
Change 31.128 If you tried to use the LDB2*** parameters to reroute a
READDB2 dataset to a different DDNAME/LIBNAME, it was not honored
Jul 4, 2013 and fails when trying to write to the PDBOUT destination.
READDB2 was using PDBOUT when it should have been using
the PDB2*** macro variables to change output DDNAMEs.
Thanks to David Bernhardt, Verizon, USA.
Change 31.127 Variables R783DCTM and R783DDTM (Control Unit Connect and
VMAC78 Disconnect Times) were added by z/OS 1.10 but were not
Jul 2, 2013 flagged with the expected vertical bar for new fields so
they were overlooked. They are added to Dataset TYPE78CU.
Thanks to Erling Andersen, SMTDATA, DENMARK.
Change 31.126 Variable XPTRVERS is now kept in all XPTR dataset.
VMACXPTR
Jul 1, 2013
Thanks to Robert Corballo, Xerox, USA.
====== Changes thru 31.125 were in MXG 31.04 dated Jun 26, 2013=========
Change 31.125 If you correctly asked for only DB2ST225 using syntax of
READDB2 %READDB2(IFCIDS=STATISTICS,WANTONLY=DB2ST25);
Jun 25, 2013 DIFFDB2 failed on the DB2STAT4 dataset due to a missing
ELSE clause, causing 0 observations to be created.
Thanks to Neil Ervin, Wells Fargo, USA
Change 31.124 MXG 31.03 only, INVALID DO LOOP CONTROL ERROR for ID=72
VMAC7072 SUBTYPE=5 record because MXG did not test SMF72QSN for a
Jun 25, 2013 missing value. Fortunately, since it was missing, there
Jun 27, 2013 was no impact, except for the error message and hex dump!
Aug 22, 2013 Correction was made in the undocumented refresh in 31.04
that was made on Jun 27. Check the 2nd line of VMAC7072
for Jun 27 to verify you have the final 31.04.
Thanks to Cletus McGee, ALFA Insurance, USA.
Change 31.123 Using the archaic EXITCICS version 1 for DB2 compressed
Jun 26, 2013 records caused INPUT STATEMENT EXCEEDED RECORD LENGTH due
VMACDB2H to a truncated DB2 Data Sharing Header, with only four
bytes and an invalid QWHSLEN (1439 decimal), printing an
incorrect message that APAR PM32425 was needed. Using
the current EXITCICS solved the truncation, but MXG now
detects this truncation with a revised error message and
prevents the STOPOVER ABEND.
Thanks to Michael Toole, AAA Michigan, USA.
Change 31.122 Long variable names caused 49, 388, and "quoted string"
VMXGSRCH errors. The string length was insufficient but now is
Jun 23, 2013 increased to 72 which will support names up to 50 bytes
(although SAS variable names have a 32 byte maximum).
Change 31.121 MXG Logic did not "unhex" CONDCODE for ABEND='COND=J' as
VMAC30 it does for USER and RETURN codes, causing the value to
Jun 23, 2013 be CONDCODE='000C', when it should be CONDOCD='0012'.
Thanks to Robert Bardos, Next Stride AG, SWITZERLAND.
Change 31.120 Support for QESD segment added in MQ Series 7.1 adds
VMAC115 variables to MQMMSGS dataset:
Jun 22, 2013
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.119 -Variables IPCSTIME and character TIMEZONE (CDT/EDT/etc.)
VMACNMON are added to NMONBBBP dataset.
Jun 23, 2013 -New RECTYPE='DISKWAIT1' now supported correctly; this
Jul 1, 2013 update was NOT in MXG 31.04, but is in 31.05.
-In adding support for DISKWAIT1 it was discovered that
the PDB.NMONDISK dataset could be missing observations
if there were more than 150 disk volumes on the system;
NMON writes 150 disks per record, and spills more disks
into the DISKxxxx1 tag, but MXG logic incorrectly used
the count in the LAST tag, so in this case, there were
150 disks in the first record, then 53 in the second, but
MXG used that count of 53 and output only the FIRST 53.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 31.118 Support for new EDGR variables added to EDGRXEXT dataset
VMACEDGR (COMPATIBLY) by z/OS 1.13:
Jun 22, 2013 RDCOMPRAT ='FILE*COMPRESSION*RATIO'
Jul 15, 2013 RDESB ='EXPDT*SET BY*DATASET'
RDPHYSIZE ='ACTUAL*DATA ON*TAPE*AFTER'
RDUCDATE ='DATASET*LAST*USER*CHANGE*DATE'
RDUCTIME ='DATASET*LAST*USER*CHANGE*TIME'
RDVEX ='VRSEL*EXCLUDE?'
RVCOMPRAT ='VOLUME*COMPRESSION*RATIO'
RVESB ='EXPDT*SET BY*VOLUME'
RVHOLD ='VOLUME*HOLD?'
RVPHYSUSED='ACTUAL*SPACE*AFTER*COMPACTION'
RVRETMET ='RETENTION*METHOD'
RVRMSB ='RETENTION*METHOD*SET BY'
RVUCDATE ='VOLUME*LAST*USER*CHANGE*DATE'
RVUCTIME ='VOLUME*LAST*USER*CHANGE*TIME'
Thanks to Clayton Buck, UNIGROUP, USA.
Change 31.117 DB2 V10. All QLSTxxxx numerics (in DB2STATR,DB2STATS)
VMACDB2 are wrong. IBM inserted QLSTPRID in the second iteration
Jun 20, 2013 of DB2 V10 right after QLSTLOCN, but I missed that change
so all subsequent variables were misaligned by 8 bytes.
My thanks to DB2 Support at Computer Associates whose
reports were correct and were used to correct my error.
Thanks to Paul Walters, Navy Federal Credit Union, USA.
Change 31.116 TYPETPMX variable JOBNUM was truncated from the left when
VMACTPMX it was 6 digits long; an INPUT JOBNUM $VARYING7. is
Jun 20, 2013 (pretty obviously) needed for seven digits.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 31.115 -Reading COMPRESSED DB2 SMF 102 records using the internal
READDB2 SAS-code decompression algorithm set SUBTYPE=0 instead of
VMACSMF storing the IFCID in SUBTYPE. If you used %READDB2 and
Jun 19, 2013 listed any numerics in IFCIDS= argument, NO OBSERVATIONS
were created in those T102Snnn datasets, because READDB2
incorrectly tested SUBTYPE instead of QWHSIID.
Note: If you use the EXITCICS SAS INFILE EXIT on z/OS
to decompress DB2 records as they are read, or if you
use IBM PGM=DSNTSMFD on z/OS to decompress before you
read them, the SUBTYPE value is correctly set to the
IFCID, which is why the SUBTYPE test usually worked!
Now, QWHSIID is tested in READDB2 to correct this error.
-Because IBM DB2 does not populate the IFCID value into
the SMF Header SUBTYPE Field, MXG logic in VMACSMF gets
IFCID from the DB2 Product Segment to put into SUBTYPE,
when the data is uncompressed or the CICSIFUE is used,
but with the internal MXGDECOM, the record has not yet
been decompressed when the SMF header is processed, so
the offset to the Product Segment is wrong and the IFCID
cannot be INPUT, and SUBTYPE is zero (except for IFCIDs
105,106,196,258 and maybe others that aren't compressed).
and so ANALID reports 102.000 for those IFCIDs that can't
be known due to comressed records with MXGDECOM.
-After Change 32.175, the DB2 Subsystem is ALWAYS decoded
in the SMF Header Processing; the SMF SUBSYS field is the
DB2 Subsystem, but that was not realized in 31.115.
This Change Text was revised AFTER CHANGE 32.175.
-However, with compressed records and the internal decomp,
the DB2 version will be blank, since that, like IFCID, is
only in the product segment.
-The UTILGETM/VMXGGETM utility to extracts records of each
ID and Subtype to create the SMFSMALL dataset or report
on SMF record counts will also lump all those ID=102
IFCIDs as SUBTYPE=0 with compressed/internal.
-EXITCICS and DSNTSMFD are members in MXG Source Library.
-VMACSMF was revised to bypass reading the Product Segment
with compressed data and the internal code is used.
Thanks to Paul Walters, Navy Federal Credit Union, USA.
====== Changes thru 31.114 were in MXG 31.03 dated Jun 17, 2013=========
Change 31.114 SMF70NCA, PERCENT*WHEN*CAPPING*DELAYED*WORK is added to
VMXG70PR ASUM70PR ASUM70LP ASUMCEC ASUMCELP datasets, and the
Jun 17, 2013 maximum Group MAX70NCA is added to ASUM70GL.
Thanks to Helene BARDON, Silica Production Information, FRANCE.
Change 31.113 Discovered during QA. TRNDing RMFINTRV created workload
VMXGRMFI variables in TRNDRMFI/MNTHRMFI datasets with suffixes TRN
Jun 17, 2013 RSP SWP for TSO1/TSO2/TSO3 that should not have been
created nor kept, as the actual TSOn TRAN RESP SWAP were
created. Because of the original 8-byte variable name
restriction, and because you can specify Workload prefix
with five characters, the OTHER multi-period workload
variable names ARE suffixed with TRN RSP and SWP, which
is a regrettable inconsistency in MXG names that we'll
have to live with. Also, workload variables that are
used only for normalizing (suffix CNT) are not kept.
Change 31.112 MXG support for ODS graphics executes PROC TEMPLATE when
FORMATS FORMATS is run (during install of a new MXG Version) and
GRAFWRKX the MXGSTYL1 style is stored in the //LIBRARY DD/LIBNAME
MXGSTYL1 and VMXGINIT adds LIBRARY to the ODS Path so that style,
VMXGINIT used initially in GRAFWRKX, can be retrieved and used.
Jun 16, 2013 GRAFWRKX comments show how to use the ODS graphics code.
Change 31.111 -RMF III Enhancements and Notes
ASMRMFV -RMF III SVP (Service Policy) tables over 32K in length
SENDVSAM are now supported. Prior versions of ASMRMFV would skip
VMACRMFV the entire SVP table if it exceeded 32K because that was
Jun 15, 2013 beyond the maximum output LRECL possible. Now when
needed this table is segmented and output to RMFBSAM as
several records. This was a long standing documented
ASMRMFV program restriction that is now lifted. This is
the last RMF Monitor III table that had a size support
restriction. Users with Service Policies less than or
equal to 32K in size will have a single SVP record
output to RMFBSAM as before.
-VMACRMFV has been upgraded to accept segmented SVP table
records when present as input in the RMFBSAM file; these
variables are now RETAINed from the header and are kept
in ZRBSVPC ZRBSVPG ZRBSVPR ZRBSVPW ZRBSVPZ datasets:
SVPDSP SVPIDD SVPIDN SVPIDU SVPIPU
SVPNSP SVPSNA SVPTDI SVPTIB SVPTPA
-Note: Users most likely to be affected by this change
are those with large number of Service Classes and/or
Report Classes in their WLM Service Policy. Their
ZRBSVPP, ZRBSVPW, ZRBSVPC, ZRBSVPZ, ZRBSVPR, and ZRBSVPG
data sets will now be populated in the RMF III PDB if
the SVP table is selected in ASMRMFV processing.
-When the POLICY parameter is in effect (NOPOLICY is the
default), a second RMFV024I message will now appear in
ASMRMFV SYSPRINT showing the Name and Description of the
Service Definition. This is in addition to the Name and
Description of the Service Policy already displayed.
-Also when the POLICY parameter is in effect, the
RMFV027I message in ASMRMFV SYSPRINT will now display
the total length of the SVP table. When this value
exceeds 32760 then the RMFBSAM output will be segmented
into several records instead of a single record to avoid
skipping the table. The segmentation behavior occurs
regardless of whether POLICY or NOPOLICY is in effect.
-The Service Policy itself is now counted as an entry in
the ENTRIES COUNT column for SVP tables. This is added
to the total number of Workloads, Service Classes,
Service Class Periods, Report Classes, and Resource
Groups defined in the Service Policy already included in
that value.
-ASMRMFV prologue source documentation has been updated
to remove documentation on the skipping of the SVP table
if greater than 32K in size.
-Minor corrections made to SENDVSAM sample JCL member
used to send RMF III VSAM file to MXG support.
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change
must be installed. See MXG SOURCLIB member JCLASM3 for
sample JCL for the assembly and link-edit install steps.
Thanks to Warren Cravey, FMR Corporation, USA
Change 31.110 CICS/TS 5.1 only, MNSEGCL=5 (RESOURCE class FILE segment)
VMAC110 ID=110 Subtype 1 INPUT STATEMENT EXCEEDED RECORD LENGTH
Jun 13, 2013 because 16 bytes were inserted but not protected in MXG.
New variables
FCFIXCTM='FILE*EXCLUSIVE WAIT*DURATION'
FCFIXCCN='FILE*EXCLUSIVE WAIT*COUNT'
FCFIVSTM='FILE*VSAM STRING*WAIT*DURATION'
FCFIVSCN='FILE*VSAM STRING*WAIT*COUNT'
are now created in CICSRDFI. Fortunately (for ME!), only
leading edge CICS sites have enabled the RESOURCE class
segments, so the exposure is (hopefully) small for most.
Thanks to Tom Buie, Southern California Edison, USA.
Change 31.109 Documentation only, to create an uncompressed record for
VMAC110 technical support. The comment block is revised to show
Jun 11, 2013 how to print a hex dump of a single uncompressed record.
Change 31.108 DB2STAT1 variables QXSTCWLP/QXSTCW?R/QXSTCWLM/QXSTCWLD
VMACDB2 were not deaccumulated, were incorrectly kept in DB2STAT0
Jun 7, 2013 and QISTWMXU should not have been deaccumulated. Real
data with non-zero variables is required to validate if
fields are accumulated or not; the DSECTS are frequently
insufficient to clearly identify field contents.
Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
Change 31.107 These TYPE120 variables are now correctly labeled:
VMAC120 SM1209DD='ENCLAVE*ZIIP*ELIGIBLE*ON CP*CPU TIME'
Jun 7, 2013 SM1209DE='ENCLAVE*ZIIP*ELIGIBLE*CPU TIME'
SM1209DF='ENCLAVE*ZIIP*TIME*ON ZIIP'
Thanks to Mark Wittie, Fidelity Investments, USA.,
Change 31.106 -Variable TYPETASK in dataset TYPE6 was inconsistent for
VGETJESN PSF and Printway records, and did not identify Printway
VMAC6 Basic from Extended mode. Now, TYPETASK and SUBSYS6 will
BUILD005 contain 'PSF ' for PSF, and 'TCP ' for Printway Basic or
BUIL3005 'TCPE' for Printway Extended format records.
Jun 4, 2013 -BUILDPDB logic revised so these TYPE6 TYPETASK values are
May 14, 2014 NOT accidentally used for PDB.JOBS. HOWEVER: this can
cause TYPETASK to be blank in PDB.JOBS for any job for
which ONLY the PRINT record was found. And that will not
likely happen in full BUILDPDB production with the SPIN
library populated. It is when you have not populated the
SPIN library, and read "today's" SMF, it will have those
type 6 record for jobs that executed prior to today, and
that is the primary source of jobs with only TYPE6 obs.
Once you've populated the SPIN library, there should be
very few cases of only a type 6 record so TYPETASK should
normally be populated in production BUILDPDBs
This paragraph revised May 14, 2014.
-IP PrintWay fills in the page count (variable PAGECNT,
SMF6PGE) when it uses the direct sockets protocol to send
data to the printer and ONLY IF "Record pages printed for
accounting" option is selected in the Printer Inventory.
Thanks to Jennifer D. Ayers, West Virginia State Government, USA.
Thanks to Jeff Fracas, WIPRO, USA.
Change 31.105 ASMTAPEE ML-51 update corrects MXGC010E error message.
ASMTAPEE Note that if the HSC exit is not installed, STKX=NO must
Jun 1, 2013 be specified as a PARM when ASMTAPEE is executed.
//MXGTMNT EXEC PGM=MXGTMNT,PARM='STKX=NO'
Thanks to Scott Barry, SBBworks, Inc., USA.
Change 31.104 Change 30.250 was incorrectly made in ANALCAPD. The code
ANALCAPD should have had PDB=&PDBMXG, in the Macro Definition, but
ANAL72GO this discovery caused examination and correction of these
ANALAVAI other members. Many cases of lower case variable names
ANALBLSR were upper cased for consistency.
ANALCISH
ANALDB2R
ANALDBTR
ANALDMON
ANALNPMR
ANALRAID
ANALWHO
May 31, 2013
Thanks to Randy Shumate, Reed-Elsevier, USA.
Change 31.103 Variable QACCN is now kept in TMMQQAA dataset.
VMACTMMQ
May 30, 2013
Thanks to Homayoun Riazi, UHC, USA.
Change 31.102 IMS 13 inserted new DLRAZAAP field in the 07 Log Record
VMACIMS nearly at the front, that was overlooked, and caused all
VMACIMSA subsequent variables to be invalid, but error messages of
May 28, 2013 invalid data were only rarely printed.
Thanks to Daniel Erikols, Handelsbanken, SWEDEN.
Change 31.101 PDB.JOBS new variables HICPUPGM and HICPUPCT were wrong,
BUILD005 as the job-level values were taken incorrectly from the
BUIL3005 last step. They are now populated from the TYPE30_5 job
May 23, 2013 record, (using SPIN30_5 names HICPUPG5/HICPUPC5 because
they come from multiple records). With this change,
HICPUPCT is the maximum value of any step or interval
record, and HICPUPGM is the corresponding program that
recorded that HICPUPCT.
Note: These variables were one of the last of the late
Bernie Pierce's implementations, and they exist so that
IBM might be able identify single threaded programs.
With all processor vendors acknowledging that processor
speed is now limited by physics, and unlikely to be
increased significantly, applications that are single
threaded need to be identified for possible revision so
they don't become bottlenecks in the future, and these
variables provide a POSSIBLE candidate identification.
addition. Many IBM customers provided data, and I was
contacted because the MXG program, ASMRMFV, was flagged
as likely single-threaded, and it is! That program
decompresses the RMF III monitor data, and we had
previously examined with STROBE, which reported that
96% of the CPU time was inside the IBM-provided code
ERB3RDEC that does the decompression, which kicked this
ball back in to IBM field of play!
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 31.100 Member ASUMUOW executed twice because lines 214 following
ASUMUOW were duplicates of the first 214 lines, in MXG 30.06 thru
May 23, 2013 MXG 31.02.
Thanks to Mike George, Northern Territory Government, AUSTRALIA.
Change 31.099 Unused Change Number
Change 31.098 Support for local CICS variables TUXTRAP and UMBPROG.
IMACICV3
IMACICV4
UTILEXCL
VMAC110
May 22, 2013
Thanks to Jim Polleti, Edward Jones, USA.
Change 31.097 -CICS Statistics SMF ID=110 subtypes 2-5 contain multiple
VMAC110 segments per record, each identified by its "STID" value,
May 14, 2013 which controls which dataset is output, but MXG didn't
identify which SUBTYPEs had which STIDS to create which
datasets. These comments in VMAC110 are updated to list
CICS Statistics Subtypes 3-5 that contain STIDs 121-129:
CICS RECORD SUBTYPES AND CORRESPONDING MXG DATASETS CREATED:
0=JOURNAL SEGMENT
CICSJOUR (DEFAULT IF UNKNOWN JOURNAL).
CICSSAP (IF IMACICSA ENABLED FOR SAP).
CICSSMED (IF IMACICSM ENABLED FOR SHAREDMED).
1=MONITOR/TRANSACTION
MNSEGCL=1 DICTIONARY RECORD: CICSDICT ONLY IN UTILEXCL
MNSEGCL=2 CICSACCT (ZERO OBS ALWAYS, WAS PRE ESA)
MNSEGCL=3 PERFORMANCE CLASS: CICSBAD, CICSTRAN
MNSEGCL=4 EXCEPTION: CICSEXCE
MNSEGCL=5 RESOURCE: CICSRDS,CICSRDFI,CICSRDQU
MNSEGCL=6 IDENTITY: CICSIDNT,CICSIDND
2=STATISTICS: ALL OTHER STIDS, ALL OTHER CICXXXXX DATASETS
3=TS DATA SHARING STATS: CICXQ1,CICXQ2,CICXQ3
STID: 121 122 123
4=CF DATA TABLE STATS: CICFS6D,CICSF7D,CICFS8D,CICFS9D
STID: 126 127 128 129
5=NAMED COUNTER STATS: CICNS4D,CICNS5D
STID: 124 125
-TYPE110 processing always examines subtypes 2-5 for all
possible STIDs, which control which dataset is output,
but the example in comments in CICINTRV to build from raw
SMF selected only subtype 2 in its IMACFILE tailoring, so
that example would not populate those nine datasets. That
example now selects SUBTYPE GE 2.
Thanks to Richard Schwartz, IBM Global Services, USA.
Change 31.096 Example summarizes ENTIREX data to 15 minute intervals.
ASUMENTX
May 11, 2013
Change 31.095 Variable CA_XIIS /* GET CACHE DATA ACCESS XI'S */ now
ANALRMFR includes R744CXFW /* XI WRITE */ to match IBM RMF report.
May 11, 2013
Thanks to Marvin Silverman, ???, USA.
Change 31.094 BUILDPDB/BUILDPD3 enhancement: create your own accounting
BUILD005 variables for PDB.JOBS/PDB.STEPS/PDB.SMFINTRV, especially
BUIL3005 useful when converting from MICS to MXG. While IMACACCT
EXPDBACC allows you to create account variables, and the _KTY30Ux
VMXGINIT tailoring macros, placed in member IMACKEEP, will add
May 11, 2013 them to the TYPE30xx datasets, this new EXPDBACC exit
lets you create additional account variables for BUILDPDB
and, similar to other PDB "ADDxxxx" macro variables, use
%LET ADDACCT= ACCTBITS ACCTNo1-ACCTNo5;
and your new variables will be kept in the PDB datasets.
Thanks to Randall Schlueter, First Data, USA.
Change 31.093 -The DB2 "INVALID" IFCID=369 ID=100 SUBTYPE=5 DB2STAT5 SMF
CLEARDB2 record, cited and purportedly protected by Change 31.088,
READDB2 is more accurately described (in fairness to IBM DB2) as
VMACDB2 "UNDOCUMENTED" or "UNEXPECTED", but not INVALID, although
May 14, 2013 it caused MXG to take a floating point exception or INPUT
STATEMENT EXCEEDED error that ABENDED the JOB. (Older MXG
Versions print the 'CALL HOME" message 1440 times per DB2
Subsystem, but fortunately, with no actual impact on the
other existing DB2 datasets).
The UNEXPECTED subtype 5 record is now diagnosed as a
startup record, written when IFCID 0369 is enabled, and
it contains only two segments (PROD and OFF3691), with
only QW0369ST (enabled datetimestamp) populated, so MXG
sets QW0369CN='ENABLED' (or, for a record with QW0369SP
populated, MXG sets QW0369CN='DISABLED'). Since DB2STAT5
is a per-connection-type statistics, I presumed all five
segments would be present, but now test for QWHSNSDA=2 to
identify this record.
There was one record written with impossible DB2TCBTM of
152 minutes for a 1 minute interval for BATCH connection,
not possible, but the peak sum of DB2TCBTM recorded 38
minutes on a machine with XX CP engines.
Support for Subtype 5 was not in the original 31.02; it
was at least 5 minutes after I posted the GA announcement
before Joe Babcock sent me the CALL HOME message about
the new DB2 subtype, and Change 31.081 updated VMACDB2 to
create DB2STAT5, since it tested fine with a day's data
(other than the separate internal invalid data issue)
and because, without that updated VMACDB2, there would be
1440 "CALL HOME" log messages per DB2 subsystem printed
each day While in no way impacting the actual execution,
those messages can ONLY waste user's time in asking about
them, so the updated VMACDB2 at 31.081 was moved into the
redated MXG 31.02 on May 5. Unfortunately, by then, the
short record had been found, Change 31.088 detected and
protected, but the VMACDB2 in 31.02 of May 5 was still at
Change 31.081. This change, now does recognize and read
and output these records to DB2STAT5 without error.
-READDB2 is updated to create DB2STAT5 when STATISTICS or
IFCID=369 is requested. DB2STAT5 is NOT combined into
DB2STATS because STAT5 is per connection-type metrics.
-CLEARDB2 is updated to add DB2ST5 tokens to be redefined.
Change 31.092 Reserved Change Number.
May 8, 2013
Change 31.091 Instructions for updating IMACSMFF to add the description
FORMATS for user SMF records for the ANALID report and SMFRECNT
May 7, 2013 dataset didn't state that the syntax that is required is
'III.SSS' (III=ID with SSS=SUBTYPE) if the record has the
a subtype in the SMF header, or 'III.000' if not.
Change 31.090 Default LENUSRCH=32 was left behind from debugging that
IMACICUS should be LENUSRCH=0; this could cause EXCLUDED field
May 7, 2013 error messages even though you had tailored IMACEXCL.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 31.089 Installation JCL example had inconsistent DSNAMEs for the
JCLINSTT TERSED dataset.
May 7, 2013
Thanks to Donald Williams, UNC Health Care, USA.
====== Changes thru 31.088 were in MXG 31.02 dated May 5, 2013=========
Change 31.088 New DB2 V10 ID=100 SUBTYPE=5 DB2STAT5 INPUT EXCEEDED
VMACDB2 error because of an UNDOCUMENTED short record with only
May 4, 2013 two segments. See Change 31.093 for the correction.
The original May 4 change to VMACDB2 detected and deleted
records with large OFF3692 offset values. The DB2STAT5
data is the DB2 IFCID=0369 and must be enabled to create
the exposure. See Change 31.093.
Change 31.087 MXG 31.02. Debugging PROC PRINT of DATA=MGTMSVL was left
TYPETMS5 after it helped diagnose Change 31.078. Now removed, but
May 4, 2013 it could create a massive print output dataset.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 31.086 -SMF Audit Report Enhanced for DB2 SMF to report if the
ANALID ACCUMAC ZPARM option was enabled (NON-ZERO VALUE combines
VMACID multiple 101-1 records into one Rollup record with all
VMACSMF detail summarized). Variable DB2PARTY='R' in DB2ACCT
May 4, 2013 flags the summary records, which can be confusing if you
Jun 26, 2013 do not know what to look for, and ACCUMAC=10 is default.
A column is added and new FOOTNOTE2 explains. Note that
if ACCUMAC is on and off, statistics for both conditions
are reported.
-CICS 110.2 records are never compressed but MXG didn't
select only subtype 1 records, so the report could have
incorrectly indicated compressed for subtype 2 records.
-Jun 26, 2013: Comments revised in IMACSMFF.
Change 31.085 Format $MGCICDS for SMF/SMT/SMS CICS Statistics values
FORMATS 11/12/13x are now replaced in CICS/TS 5.1:
May 3, 2013 '11'X='11X:GCDSA' /* WAS ESDSA PRE 5.1.0 */
'12'X='12X:GUDSA' /* WAS ERDSA PRE 5.1.0 */
'13'X='13X:GSDSA' /* WAS ETDSA PRE 5.1.0 */
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 31.084 MXG 31.02, RMF III INPUT STATEMENT EXCEEDED if an LPAR
VMACRMFV had no engines; the SKIP logic to skip the nonexistent
May 3, 2013 segments was incorrect with unexpected zero engines.
Thanks to James Sterling, DST Systems, USA.
Change 31.083 Reserved Change Number.
May 10, 2013
Change 31.082 -ASCII only. Character variable SMFDSAIN with $HEX format
VMAC110 must be input as $CHAR instead of $EBCDIC when MXG runs
Apr 30, 2013 on ASCII. Two of three incorrect instances corrected.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Glen Bowman, Wakefern Food Corp.
Change 31.081 Support for DB2 V10 ID=100 SUBTYPE 5 Statistics Record,
EXDB2ST5 IFCID=369, created when you enable that trace record, now
IMACDB2 creates new DB2STAT5 dataset with LOTS of CPU and WAIT
VMACDB2 times (ALL QBAC and QWAX variables) by connection type,
VMXGINIT with these connection types defined:
Apr 30, 2013 MASS - IMS attach
SASS - CICS attach
RRSAF - RRSAF attach
UTILITY - Utility
BATCH - Batch
DIST - DDF connection
From IBM:
1.Statistics collection will become enabled when both
IFCID 369 and IFCID 3 is enabled on the system.
2.All counters will be reset to zeroes when DB2 is
restarted
3.Statistics are aggregated by connection type. If no
agents for that connection type have executed since
the 369 collection in enabled, no data will be
externalized for that connection type.
4.QWACPCNT indicates the number of transactions
aggregated for a given connection type.
The MXG - ERROR: UNEXPECTED DB2 SUBTYPE. CALL HOME.
shows how long ago this code to detect new subtypes was
added to MXG: BEFORE THERE WAS AN INTERNET! The message
now references SUPPORT@MXG.COM.
There is no direct impact on ITRM by the creation of the
new DB2STAT5 dataset. When DB2STAT4/DB2ST225 datasets
were created MXG did impact ITRM, with NOT SORTED errors
(that were immediately corrected with a one line insert),
but that was because those datasets were merged into the
PDB.DB2STATS where sorts had to match; this new DB2STAT5
dataset is NOT combined into the interval PDB.DB2STATS,
at least not yet and not until it's errors are fixed,
because it is a per-connection-type-per interval dataset.
See Change 31.093.
Sep 2014 Note: If you have tailored TYPEDB2/TYPSDB2 code,
you will have to modify your code to create the DB2STAT5
dataset. If you uses _NDB2 to null all datasets, then
you will need to add MACRO _WDB2ST5 DB2STAT5 % so that
that dataset is created. Otherwise, you will get
ERROR: No data set open to look up variables
printed before
"The data set WORK.ZZDB2ST5 may be incomplete/"
Thanks to Joe Babcock, JPM Chase, USA.
Thanks to John Hornor, JPM Chase, USA.
Change 31.080 -RMF III Enhancements, Fixes, and Notes
ASMRMFV -Change 31.021 increased the number of ENC table triplets
May 28, 2013 processed from 1 up to 6. However, later analysis of
data from several installations confirmed that triplets
2-6 all have zero token values for every enclave and no
identification information. Therefore, processing is
reverting back to only processing the first triplet as
before.
-Note: Users who have implemented change 31.021 or 31.062
will see the number of observations in the ZRBENC dataset
significantly reduced with this change.
-Validity checking for most RMF Monitor III tables has
improved. This is intended to detect malformed RMF III
tables that could cause abends or bad data in the PDB
build later. For example, table headers cannot have a
zero or excessive length. However, users should not see
a general increase in skipped records. Table skipping
should be a rare event.
-ASMRMFV was inconsistent in handling tables with entry
counts of zero. Most tables with this condition were
already ignored with no output to any file. However, for
some tables the header only was output. Now all such
tables are ignored by default.
-Note: RMF Monitor III table headers only contain control
information such as header length, total record length,
and the number of entries, entry length, and table offset
for triplet groups. So there is no loss of useful
analysis data by excluding headers only from the RMFBSAM
file. It is the entries themselves that contain relevant
information for reporting.
-Because headers only for tables with zero entries are no
longer output, the ZEROENC/NOZEROENC parameters (and
their aliases) for ENC table processing are now OBSOLETE.
If coded they will be accepted without error, but will be
ignored.
-ZEROENC/NOZEROENC will no longer be displayed in filters
message RMFV006I.
-New parameters SKIPTAB/NOSKIPTAB are now supported.
NOSKIPTAB is the default and says to ignore any tables
with zero entries. This is the behavior of prior ASMRMFV
versions. SKIPTAB says to output these as skipped
records. SKIPTAB is intended for possible diagnostic use
only and the default NOSKIPTAB should be adequate for all
users.
-Note: SKIPTAB/NOSKIPTAB applies only to the following RMF
Monitor III tables: ASI, CFI, CPD, CSR, DVT, ENC, ENT,
OPD, SPG.
-When the POLICY option (alias POL) is in effect a second
RMFV027I message will now be produced showing the SRM
coefficients for CPU, IOC, MSO, and SRB for that Service
Policy.
-Error message RMFV007S had incorrect values for DDNAME
and Reason Code when a BLDVRP failure occurred.
-ASMRMFV prologue source documentation has been updated
for the new SKIPTAB/NOSKIPTAB parameters, the obsolete
ZEROENC/NOZEROENC parameters, and has more information on
the checks used to determine skipped records.
-REQUIREMENT: In order to receive these improvements the
current ASMRMFV utility program from this MXG change must
be installed. See MXG SOURCLIB member JCLASM3 for sample
JCL for the assembly and link-edit install steps.
There are NO CHANGES to VMACRMFV for this enhancement.
Thanks to Rodger Foreman, Trans Union, USA
====== Changes thru 31.079 were in MXG 31.02 dated Apr 29, 2013=========
Change 31.079 Dataset TYPE42 variables S42CCSST S42CCEIT S42CCSET
VMAC42 were on GMT rather than local, and there is no GMT offset
Apr 26, 2013 in that subtype, but SMFTIME was used to derive and use
the offset to convert those datetimes to local zone.
This caused me to examine and find that all of the TYPE42
datasets with STARTIME and ENDTIME also had GMT values,
but these datasets were corrected in this change:
42D1 42D2 42D3 42D4 42EX 42L1 42L2 42S1 42S2 42S3
42S4 42SR 42VT 42X1 42X2 42X3 42X4.
Either no one uses these datasets, or they recognized the
SMFTIME was local and could visually convert!
Thanks to Paul Naddeo, Fiserv, USA.
Thanks to Edward Petka, Fiserv, USA.
Change 31.078 PROC FORMAT failed with "FORMAT NAME $MGTMSVL" IS INVALID
VMACTMS5 that was NOT repeatable here with either z/OS or Windows,
ANAL30 because this was an NLSCOMPATMODE issue for non-US site.
ANALCPUV The $ is a variant character and was the culprit, but it
ANALDB2P turns out that the $ is NOT required in the FORMAT NAME,
ANALZPCR since the PROC FORMAT sets the CHAR/NUM nature, so all of
GRAFLPAR the PROC FORMATS that create 'on the fly' formats were
TIMEBILD revised to remove the $ character from variable FMTNAME.
TRNDTALO NOTE: ALL NLS ISSUES ARE ELIMINATED IF YOU USE THE NEW
VFMT102 // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
VFMT102 documented in Change 27.356 and recommended in INSTALL,
Apr 26, 2013 or if CONFIGN9 (instead of CONFIGV9) is used in your site
MXGSASV9 JCL, as CONFIGN9 does NOT change the site's
NLSCOMPATMODE option value.
Thanks to Frank Lund, Evry AS, NORWAY.
Thanks to Rich Anderson, SAS Technical Support, USA.
Change 31.077 z/VM 6.2 PRCMFC 5.13 (SMF 113-like) record has 384 extra
VMACVMXA bytes added that exposed BROKEN CONTROL RECORD ERROR, due
Apr 27, 2013 to MXG code (1664 bytes read for the 208 counters, but
1728 subtracted). No new counters exist (yet?) in z/OS
SMF 113 so these new bytes are (presumably) for the
future, but I will confirm with IBM VM support and update
this note if there is another explanation.
Thanks to David J. Schumann, BCBS of Minnesota, USA.
Change 31.076 Support for USER CICS fields INFRASTR CSGNTAIP FDRTRRCP
IMACICUY and FDRICPTI.
IMACICUZ
IMACICV1
IMACICV2
UTILEXCL
VMAC110
Apr 25, 2013
Thanks to Mayer Rosenthal, WIPRO, USA.
Thanks to Jeff Fracas, WIPRO, USA.
Change 31.075 ASCII execution only. Variables RTYPE and RRTYPE were
VMAC110 incorrectly input as $CHAR instead of $EBCDIC in current
Apr 23, 2013 CICS versions' code. Older versions were correct.
And there was NO error if you used UTILEXCL to create a
tailored IMACEXCL; that code did use $EBCDIC.
Thanks to Erling Andersen, SMTDATA, DENMARK.
Change 31.074 Dataset ZRBLCP had incorrect values for these variables
VMACRMFV LCPUPOLR LCPUCHIN LCPUCHIX due to misaligned INPUT.
Apr 23, 2013
Thanks to Sterling James, DST Systems, USA.
Change 31.073 Variable TYPETASK added to ASUMSMFI and TRNDSMFI
ASUMSMFI datasets.
TRNDSMFI
Apr 28, 2013
Thanks to Frank Lund, Evry AS, NORWAY.
Change 31.072 Format MG0748L decodes variable R748LTYP; new value for
FORMATS 16 GB/S Link Type is now decoded.
Apr 23, 2013
Thanks to "Bustia REPORTING", La CAIXA, SPAIN.
Change 31.071 Cosmetic. PAGEBY SYSTEM added so each system starts on a
ANALID new page.
Apr 23, 2013
Thanks to Jennifer D. Ayers, West Virginia State Government, USA.
Change 31.070 PMSTA01 Report. Cosmetic. If DB2STATS had only one obs,
ANALDB2R and always for the last observation, page headers for
Apr 19, 2013 the report were suppressed.
Change 31.069 Reserved Change Number.
Apr 28, 2013
Change 31.068 See Change 31.018. This is IDMS EXIT code, contributed by
ADOCIDMP Blake Leggett, Pace Applied Technology, that creates the
ASMIDMPA SMF records with IDMS resources that are processed with
ASMIDMPJ TYPEIDMP/TYPSIDMP MXG programs.
ASMIDMPS -See ADOCIDMP for details for installing the exit.
ASMIDMPU -The assembly source members for the Account Information
JCLIDMPA exit, Journal Exit, Task Statistics Exit, and User Exit
JCLIDMPJ for IDMS are now included.
JCLIDMPS -Sample JCL members for these exits are provided with
JCLIDMPU documentation on what each exit does and how to install
Apr 13, 2013 them.
-NOTE: Some tailoring of the sample JCL is required for
data set names particular to the user installation.
-NOTE: These exits are intended for use with IDMS V12.0
and up.
Thanks to Blake Leggett, PACE Applied Technology, Inc., USA.
Change 31.067 A new way to map DBID/OBID to their database and object
ANALDB2R names by first using JCLSQLID to extract those names at
JCLSQLID a point-in-time, from SYSIBM.SYSTABLESPACE which has the
VFMT102 complete mappings, rather than reading 105/107 IFCIDS
Apr 13, 2013 that has been problematic, and then the POINTIME= option
added in ANALDB2R POINTINTIME= can be used to read that
dataset created by JCLSQLID:
-POINTINTIME=YES reads JCLSQLID output from a static
//OBID DD DSNAME= you provide.
-POINTINTIME=DSNAME allocates DSNAME to FILENAME OBID
and reads that file of JCLSQLID output.
-POINTINTIME=NO reverts to the prior technique using the
IFCID 105/107 records, but neither technique is 100%
perfect as mappings can be changed after the snapshot
was taken. This method has been more complete in
mapping.
Change 31.066 Support for z/OS 2.1.
VMAC7072 -Up to 256 engines are supported, but no new variables are
Apr 12, 2013 kept in TYPE70. Individual engine data for all engines
are output in TYPE70EN dataset.
Change 31.065 If there was no PDB in PDB= argument, ANALDBTR failed:
ANALDBTR ERROR: NO BY STATEMENT USED OR NO BY VARIABLES EXISTED.
Apr 11, 2013 The substitution style macros all specify &PDBMXG as the
input DD to be used in the sorts (that is the MXG default
value) but ANALDBTR and ANALDB2R could be pointing at
other DDNAMEs including WORK. This change sets the value
of &PDBMXG to the PDB= parameter that was specified when
ANALDBTR is called, after storing the original value so
it can be restored at the end of ANALDBTR.
Change 31.064 DSGI Data Set Graphics is not officially supported by SAS
ANALACTM after SAS 9.3, but it does work in SAS 9.4, and it will
Apr 11, 2013 likely continue to execute in future releases, as it is
Jun 15, 2013 not actually being removed, but is no longer documented
and is no longer supported if errors occur. With SAS 9.4
this note is printed on the SAS log, but it still works:
NOTE: DSGI will no longer be supported after SAS 9.3.
Also, option CHART=NONE will suppress the DSGI code.
And, the Graphic portion of the report does require that
you have SAS/GRAPH - that code automatically skipped if
we see that you do NOT have SAS/GRAPH, but the formatted
hierarchical report of your WLM policy is still created.
Change 31.063 Cosmetic. Page spacing for Header 2 was different than
ANALRMFR Header 1; the extra // in Header 2 was removed.
Apr 10, 2013
Thanks to Jennifer D. Ayers, West Virginia State Government, USA.
Change 31.062 -RMF III Enhancements and Notes
ASMRMFV -The RMF Monitor III Processor Data Control Block (CPU)
VMACRMFV and CPC Data Control Block (CPCDB) tables are now handled
Apr 11, 2013 as two distinct tables just as they are documented in the
RMF Programmer's Guide. Before they were logically
handled as one table (CPU).
-The CPCDB table will appear as a new table entry CPC in
ASMRMFV RMFV105I messages. Each LPAR entry is counted as
an entry in the output.
-Note: The CPU table generally contains physical processor
data while the CPC table contains LPAR and logical
processor data. CPU table data is output to the ZRBCPU
dataset while CPC table data is output to the ZRBLCP
dataset by VMACRMFV. The number and content of variables
in those datasets is unchanged from prior releases with
the exception of 2 minor variables CPUCPOFF and CPUTOTLN
in the ZRBCPU file.
-The CPU and new CPC table selection parameters in ASMRMFV
are co-dependent because the tables are so closely
related. When one is selected, so is the other. For
example, the CPU parameter when coded also selects The
CPC table. Conversely, when one is deselected, so is the
other. For example, NOCPU when coded will also result in
NOCPC. Thus you do not need to alter any existing
CPU/NOCPU parameter settings you may currently have to
include or exclude the CPC. The ALL parameter (default)
also selects both tables.
-When the CPC table is selected in ASMRMFV the LPAR and
Logical Processor entries are now blocked up to use as
much as possible of a 32K logical record. The much
shorter CPU table is unblocked.
-ASMRMFV/VMACRMFV will now support up to 680 Logical
Processors per LPAR (based on current section data
lengths) before the entire CPC table is skipped.
-VMACRMFV is updated to support the CPCDB table and
blocking of its LPAR/Logical Processor sections.
-ASMRMFV will now show the Average LRECL output for each
RMF Monitor III table in detail and summary RMFV105I
messages as a potential aid to sizing the RMFBSAM file.
-Redundant code in ASMRMFV to skip various tables when
invalid lengths or errors are encountered has been
consolidated into a single internal subroutine.
-ASMRMFV prologue source documentation has been updated on
CPC/NOCPC parameters, the co-dependency with CPU/NOCPU
parameters, and other items related to this change.
-REQUIREMENT: In order to receive the performance benefits
from CPC entry blocking the current ASMRMFV utility
program from this MXG change must be installed. See MXG
SOURCLIB member JCLASM3 for sample JCL for the assembly
and link-edit install steps.
-Tutorial: This item has been mentioned before, but with
the CPC table blocking the use of the EXZRBLCP exit is
affected. Your tailoring logic in EXdddddd dataset exits
to control output of an MXG dataset needs this structure
to always be safe:
IF something THEN DO;
OUTPUT _Wdddddd;
END;
and can't use a DELETE, RETURN, nor "IF something;" logic
because when "something" is true, they stop the read of
this current record, skipping any un-read segments from
being tested for "something".
This consideration applies in particular to the
following RMF III tables that have blocked input data to
a PDB build and to their respective output exits:
RMF III Table Output Exit
------------- -----------
ASI EXZRBASI
CPC EXZRBLCP
CPD EXZRBCPD
CSR EXZRBCSR
DVT EXZRBDVT
ENC EXZRBENC
ENT EXZRBENT
OPD EXZRBOPD
RED EXZRBRED
SHD EXZRBSHD
SPG EXZRBSPG
UWD EXZRBUWD
Change 31.061 New MXGACC03 report uses ANALCNCR to create average and
ANALDB2R maximum concurrent threads/DBATs for each chosen INTERVAL
Apr 4, 2013 for each Subsystem and AUTHID, tabulated by QWHCATYP, the
Attachment Type (TSO,CICS,DDR...), with a tabular report.
You can tailor using existing ANALDB2R report parameters
to select data, or all DB2ACCT data will be reported.
BUT IT IS NOT POSSIBLE TO COUNT THREADS/DBATS WITH ROLLUP
DB2PARTY='R' ACCUMAC DB2 Accounting Records. If five
one-second transactions ran sequentially from minute 1 to
minute 6, their rollup record would report five minutes
with QLACRLNU=5 concurrently active when there was one.
We could calculate an average of 1 in this case, but if
the first minute was a peak of 50 and there were then
four minutes of 1, we would calculate an average of 11.
Thanks to Paul Walters, Navy Federal Credit Union, USA.
Change 31.060 These CA-Dispatch variables that can be added to TYPE6
IMACCADI and PDB.PRINT, CADIDPLX CADIJDEI CADIJDLI CADIATYP, were
VMAC6 all wrong and equal to CADIXFRM, variable CADIACCT now
Apr 4, 2013 has nulls converted to blanks, and new variable CADIJBID
contains the JCTJOBID from the CADI segment in SMF 6.
Thanks to Randy Schlueter, First Data Corporation, USA.
Change 31.059 -The System Parameter Report produced many pages, six
ANALDB2R pages per subsystem per interval generated. The report
Apr 3, 2013 did not anticipate an IFCID=106 record written every 15
minutes. Now, only the first observation for each
subsystem, or the first record after a restart will be
printed by PMSPR01=YES.
-Cosmetic. Page Number printing in DB2PM-like reports did
not align when there were five digits of page number.
Thanks to Jennifer D. Ayers, West Virginia State Government, USA.
Change 31.058 -The last NMON record, 'BBBP ENDING UPTIME' was not read
VMACNMON but now it is read into variables BBBP0049-BBBP0056.
Mar 29, 2013 -Records SEA, SEAPACKET, DONATE are supported.
Thanks to Lennon L. Merchant, Coca-Cola, USA.
Change 31.057 -When variable STARTIME was in SORTBY= argument, some of
ASUM4HRS the xxxx_4HRS_AVG variables were zero or missing for the
ANAL4HRS first four hours of each subsequent day. Comments that
VGETFMT tried to communicate "don't use STARTIME in SUMBY="
Mar 27, 2013 SORTBY- VARIABLES BY WHICH THE DATASET IS SORTED NOT
INCLUDING THE STARTIME (ASSUMED TO BE THE LAST
VARIABLE IN THE SORT)
were revised to be clearer.
-The prior requirement for the input data to be pre-sorted
is removed; ASUM4HRS will do the sort in its processing.
-ANAL4HRS was an accident from an early ASUM4HRS iteration
that shouldn't have been kept; now it is only comments to
use ASUM4HRS.
-Argument NONOTES was not UPCASED and was not recognized
when the argument was typed in low case, now corrected.
Thanks to Michael Marcus, FUJITSU, USA.
Change 31.056 Variable THREADS was created only in ASUMDB2A and used in
ASUMDB2A ANALDB2R, by setting THREADS=1 for each DB2ACCT obs, but
VMACDB2 for RollUp DB2PARTY='R' records, THREADS=QLACRLNU; is now
Mar 26, 2013 used to count the number of threads in each rollup.
And variable THREADS is now similarly created in DB2ACCT.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 31.055 Cosmetic. Variable CIFROM is formatted $MGNDMNT and
VMACNDM variable NDMNODET='FLAG1*FIELD' is formatted $HEX2. and
Mar 29, 2013 re-labeled correctly.
-Variable NDMRTYPE now kept in NDMGO as multiple subtypes
are output into that dataset.
Thanks to Michael Oujesky, Bank of America, USA.
Change 31.054 Corrections for '1031' record to populate JOBNAME and
VMACPRPR FIELDNAME.
Mar 24, 2013 Corrections for '1061' record, to use the original INPUT.
Apr 11, 2013 CUST_ACC changed to character variable as it must be.
Thanks to Geert Debatselier, KBC, BELGIUM
Change 31.053 MXGWARN: QWACBSC IS NOT A VALID SORTBY VARIABLE is fixed.
ANALDB2R
Mar 24, 2013
Change 31.052 IIS Weblog decoding URIQUERY than ended with &=1 with no
VMACWWW URIQNAME before the equal sign caused INVALID SUBSTR note
Mar 22, 2013 that is now eliminated.
Thanks to Dennis Longnecker, State of Washington Courts, USA.
Change 31.051 -Support for user field CHARGE creates variable USCHARGE
IMACICUX in CICSTRAN when comment block in IMACICUX is removed.
UTILEXCL -Change 30.283 (30.30/30.01) "***UNKNOWN FIELD" protection
VMAC110 was still insufficient, and the IMACEXCL created failed
VMACSMF with a 180 syntax error due to missing @;. Circumvention
Mar 22, 2013 logic updated yet again, hopefully, but sending the full
UTILEXCL log is all that is needed for MXG to add UNKNOWN
fields optionally to your CICSTRAN dataset.
Thanks to Mayer Rosenthal, WIPRO, USA.
Thanks to Denise Willers, WIPRO, USA.
Thanks to Jeff Fracas, WIPRO, USA.
Change 31.050 STOPOVER abend with ancient CICS Version '03' ID=110 in
VMACSMF new-in-30.30 VMACSMF code to get ID and SUBSYSTEM during
Mar 19, 2013 header processing was complicated by a subtype 0 record
that was actually a subtype 1, so the correction code in
VMAC110 was used in the VMACSMF processing logic.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 31.049 Support for WAS XD (WebSphere Extended Deployment) under
EXXDFGLG z/linux under z/VM reads 6 virtualization log files - see
EXXDNSLG IBM 2007 "Best Practices" Red Bok SG24-7343 - to create:
EXXDSPLG
EXXDSSLG DDDDDD DATASET Description
EXXDTILG
EXXDTSLG XDNSLG WASXDNS Node Statistics Historic Cache
IMACXDFG XDSPLG WASXDSP Server Power Consumption Stats Cache
IMACXDNS XDSSLG WASXDSS Server Stats Cache
IMACXDSP XDTILG WASXDTI TC Module Instance Stats Cache
IMACXDSS XDTSLG WASXDTS TC Module Stats Cache
IMACXDTI
IMACXDTS and this dataset which IBM recommends for Chargeback
TYPEXDFG
TYPEXDNS XDFGLG WASXDFG Fine Grained Power Consumption Stats
TYPEXDSP
TYPEXDSS These MXG variables are created in "Fine Grained" data:
TYPEXDTI
TYPEXDTS APPNAME APPLICATION*NAME
TYPSXDFG BEGINTIME INTERVAL*BEGIN*DATETIME
TYPSXDNS CELL CELL*NAME
TYPSXDSP CELLPOWER TOTAL*CELL*POWER*PER SECOND
TYPSXDSS CELLWORKPOTENTIAL MAXIMUM*CELLPOWER*PER*INTERVAL
TYPSXDTI CLUSTER CLUSTER*NAME
TYPSXDTS ENDTIME INTERVAL*END*DATETIME
VMACXDFG GWID GATEWAY*ID
VMACXDNS INTRVLTM INTERVAL*DURATION
VMACXDSP MODULENAME J2EE*MODULE*NAME
VMACXDSS NODE NODE*NAME
VMACXDTI NODEGROUP NODE*GROUP*NAME
VMACXDTS NODEPOWER TOTAL*NODE*POWER*PER SECOND
VMXGINIT NODEWORKPOTENTIAL MAXIMUM*NODEPOWER*PER*INTERVAL
Mar 31, 2013 NUMSERVICED REQUESTS*SERVICED*OF THIS*TYPE
ODR ON*DEMAND*ROUTER*NAME
POWERCONSUMED POWER*CONSUMPTION*RATE*PER SECOND
SERVER SERVER*NAME
SERVICEPOLICY SERVICE*POLICY*NAME
TCMODNAME TRAN CLASS*APPLICATION*MODULE*NAME
TCNAME TRANSACTION*CLASS*NAME
TIMESTAMP WAS XD FG*DATETIME*STAMP
WORKCOMPLETED WORK*COMPLETED
WORKFACTOR ESTIMATED*WORK*FACTOR
ZDATE ZEE DATE*ZEE OBS*WAS CREATED
Note: This new code will not execute under SAS 9.1.3; the
'M' operand to the SCAN function required when there are
duplicated delimiters, did not exist back then.
Thanks to Sally Jordan, Insurance Services Office, Inc., USA.
Change 31.048 MXG 31.01 only. CICS STID=29 (CICSMDSA dataset) was wrong
VMAC110 because I inserted a "cosmetic" comment documenting the
Mar 16, 2013 IBM field name in an INPUT statement, but its end-comment
was missing, causing MXG to be mis-aligned, so CICSMDSA
was "trashed" - easy to see since DSANAME was blank - and
printed WARNING CICS STID=0 STILEN=0 message on the log.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 31.047 New ESS GEPARMKY=0039 value for PRTOPTNS creates new
IMAC6ESS ESSOPTNS variable in TYPE6 dataset if you edit IMAC6ESS
VMAC6 to cause it to not be DROPed. See IMAC6ESS comments.
Mar 15, 2013
Thanks to Jessie Gonzales, California State Controller's Office, USA.
Change 31.046 New format $MG120HX was missing quotes on the right side;
FORMATS but SAS didn't detect the syntax error in member FORMATS,
Mar 15, 2013 until FORMATS was accidentally run without a //LIBRARY,
and only then did SAS flag the invalid syntax.
Change 31.045 ID=90 records subtype 6 and 7 "EVENTIME" is not the time
VMAC90 of the SWITCH/HALT but is the IPLTIME of this SYSTEM. So
VMAC90A variable IPLTIME is now kept in the TYPE9006 dataset and
Mar 14, 2013 both the archaic TYPE90 and recommended TYPE90A members
store EVENTIME into IPLTIME, but I kept EVENTIME since it
might already be in use in your reports.
Thanks to Perry Lim, Union Bank, USA.
====== Changes thru 31.044 were in MXG 31.01 dated Mar 13, 2013=========
Change 31.044 NMON (AIX/LINUX) dataset NMONBBBP variables BBBP028/029
VMACNMON were wrong because the INDEX test was underspecified and
Mar 13, 2013 satisfied multiple times, so the last match was used.
Mar 14, 2013 -Mar 14: BBBP029 still wrong, new "POWER SAVINGS MODE"
Mar 15, 2013 for MODE. Realized all groups of IF INDEX tests could be
replaced with ELSE IF INDEX tests for ordered testing and
to improve performance. Added BBBP147-BBBP149 variables.
-Mar 15: BBBP029 still wrong, new "MEMORY MODE" used, so
new BBBP150-BBBP158 are created for all new entries and
the test for 'MODE ' is ELSE IF after the above tests.
Thanks to Steve Dyck, CDS, CANADA.
Thanks to G. Delvecchio, Canadian Depository for Securities, CANADA
Change 31.043 -The example in comments in UTILEXCL that reads CICS SMF
IMACEXCL with UTILEXCL to create your tailored IMACEXCL, and then
UCICSCNT uses TYPE110 to re-read the CICS SMF data using that new
UTILEXCL IMACEXCL code, works on z/OS because the example's JCL
Mar 12, 2013 //IMACEXCL DD DSN=MXG.USERID.USERID(IMACEXCL),DISP=SHR
writes the IMACEXCL code to your "USERID" tailoring PDS
that is in your //SOURCLIB concatenation, so the %INCLUDE
of IMACEXCL in TYPE110 finds and uses the new IMACEXCL.
However, on ASCII, the FILENAME IMACEXCL must be written
to a file named imacexcl.sas (suffixed with .sas) and on
unix, in lower case, and, similarly, the file must be
written to a "tailoring" directory that is in the
FILENAME SOURCLIB concatenation on ASCII.
When FILENAME IMACEXCL 'c:\wherever\IMACEXCL' was used
with no suffix, UTILEXCL wrote to that filename, but when
TYPE110 was included, there were the same errors and no
observations, because the new IMACEXCL was not %INCLUDEd,
because it did not have the ASCII-required .sas suffix.
So, how could I tell the new IMACEXCL was not read? :
In MXG 30.30 (Change 30.283) UTILEXCL was enhanced for
diagnostics: when an IMACEXCL (created by new UTILEXCL)
is %INCLUDEd, a new MXGNOTE is printed on the SAS log:
177043 %INCLUDE SOURCLIB(TYPE110);
MXGNOTE: SITE IMACEXCL CREATED AT 11MAR2013:21:07:59.09
207431 RUN;
It was the absence of that MXGNOTE when I ran the user's
program to diagnose why no observations were created that
reminded me of the ASCII syntax requirement. Adding .sas
to the filename caused the new IMACEXCL to be error-free.
Examples in UTILEXCL were updated with ASCII syntax.
-The UCICSCNT program that reads SMF to count CICS record
types (transaction, statistics, dictionary), from each
APPLID and VERSION, is enhanced to count dictionary by
"triplet" values MCTSSDCN and MCTSSDRL, which matches the
existing transaction count details. This can be very
useful when MXG doesn't find the records your CICS guru
told you were enabled, by showing him/her what records
are ACTUALLY being created. So useful, that I added a
%INCLUDE SOURCLIB(UCICSCNT); statement to each example in
UTILEXCL that reads SMF data, since it would be useful to
support@mxg.com if there is a perceived UTILEXCL problem.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 31.042 Change 30.275 added support for a USER FORMAT library but
MXGNAMES the last line added in MXGNAMES was typo'd; it should be
VMXGCNFG LET MXGFORMU=YOUR.HLQ.MXG.USER.FORMATS; /*OPTIONAL*/
Jan 22, 2013 instead of MXGFORMT, and MXGNAMES wasn't listed.
Change 31.041 -Support for SHADOW USER SMF subtype 21 record creates new
EXSHDW21 DDDDDD DATASET DESCRIPTION
IMACSHDW
VMACSHDW SHDW21 SHADOW21 SHADOW MAPS
VMXGINIT -Mar 19: added support for subtype 4 record.
Mar 11, 2013 -Mar 23: corrected _BSHDW04 and _BSHDW21.
Mar 23, 2013
Thanks to Stuard Wildey, MorganStanley, ENGLAND.
Change 31.040 -Cosmetic. These harmless messages, from MXG housekeeping
READDB2 to minimize the //WORK library disk space requirement
Mar 9, 2013 NOTE: THE FILE WORK.DB2STATB (MEMTYPE=DATA) WAS NOT FOUND
BUT APPEARS ON A DELETE STATEMENT.
WARNING: NO MATCHING MEMBERS IN DIRECTORY.
are no longer printed.
-Also cosmetic: Change 30.257 didn't note that the use of
each _S102nnn sort macro creates 23 lines of messages on
the SAS log, or 9,320 more SYSOUT lines for IFCIDS=ALL.
Thanks to Jerry Massey, Compuware, USA.
Change 31.039 -The IBM TS7700 BVIR data does not contain a SYSTEM name;
VMACBVIR variable SYSTEM is now created and populated using
Mar 8, 2013 // EXEC MXGSAS,
// OPTIONS='SYSPARM="ASYS"'
with one, then eight, then five single quotes on z/OS,
or you can set SYSPARM in your SYSIN stream with:
OPTIONS SYSPARM='ASYS';
-Discovered subtype 32x caused INPUT STATEMENT EXCEEDED
with BVIRLEN=8256; tests added in Change 31.016 for the
LENGTH 8256 should have tested BVIRLEN instead.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 31.038 Cosmetic. Variable NAME should not have been kept in the
VMACRACF RACF0120 dataset.
Mar 8, 2013
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Change 31.037 Documentation enhancements for installing MXG on unix,
AUTOEXEU AIX, Linux, etc.
INSTALL
Mar 7, 2013
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Change 31.036 BETA93 Version 4.2.0 and 4.3.0 had invalid data values in
VMACBETA dataset BETA1 and 4.2.0 had invalid large NRACCTFL value
Mar 8, 2012 that also caused "DATA ERROR. CODE IN IMACACCT ....".
Variables INPUT after the accounting fields were invalid.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 31.035 The _STY74ID macro incorrectly specified TYPE74ID as the
VMAC74 input dataset rather than the correct _WTY74ID macro
Mar 7, 2013 name so if you modified the destination of the dataset
using the WTY74ID macro variable, the sort failed.
Thanks to Mike Georte, Northern Territory Government, AUSTRALIA.
Change 31.034 MXG 30.10 thru MXG 30.30. Change 30.279 reverted VFMT102
ANALDB2R to the PROC SORT NODUP removal algorithm, but ANALDB2R
Mar 7, 2013 wasn't tested with PMAUD02, which was not reverted:
ERROR: The keyword parameter SYSTEM DBNAME OBNAME
was not defined with the macro.
Change 31.033 COMPANY= added to allow the insertion of a company
ANALCOMP name in titles.
Mar 7, 2013
Change 31.032 Large page frame variables added to TRND71 dataset:
TRND71
Mar 7, 2013 Min Max Avg
Frames in Pool SMF71L1M SMF71L1X SMF71L1A
Frames Not Used SMF71L2M SMF71L2X SMF71L2A
Frames In Use SMF71L3M SMF71L3X SMF71L3A
Objects Alloc SMF71LOM SMF71LOX SMF71LOA
Thanks to Wayne Bell, UniGroup, USA.
Change 31.031 Cosmetic. Label for SMF64RLM is corrected from ESDS to
VMAC64 SMF64RLM='CA-S*RECLAIMED*IN KSDS*SINCE CLOSE/EOV'.
Mar 6, 2013
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 31.030 Support for 12 new NTSMF objects and MANY new variables
EXNTD064 added for existing objects. Find "ADDED BY CHANGE 31.030"
EXNTD065 in VMACNTSM to identify the new variables. There are now
EXNTD066 513 MXG datasets created from Windows NTSMF data.
EXNTD067
EXNTD068 -New Objects now supported:
EXNTD069
EXNTD070 DDDDDD Dataset/Object
EXNTD071 NTD064 HYPER-V_VIRTUAL_SWITCH_PROCESSOR
EXNTD072 NTD065 MSRS_2011_WINDOWS_SERVICE
EXNTD073 NTD066 MSSQL_BATCH_RESP_STATISTICS
EXNTD074 NTD067 MSSQL_FILETABLE
EXNTSQSV NTD068 MSSQL_MEMORY_BROKER_CLERKS
IMACNTSM NTD069 MSSQL_MEMORY_NODE
VMACNTSM NTD070 MSSQL_QUERY_EXECUTION
VMXGINIT NTD071 NUMA_NODE_MEMORY
Feb 26, 2013 NTD072 NETWORK_ADAPTER
NTD073 PHYSICAL_NETWORK_INTERFACE_CARD
NTD074 SMB_SERVER_SHARES
-These objects were updated with new variables:
NTACSR ACTVSRVR NT ACTIVE SERVER PAGES
NTASPN ASPNET ASP.NET
NTNETI NETWINTR NT NETWORK INTERFACE
NTPPAC PPNETACC PER PROCESSOR NETWORK ACTIVITY
NTPRIN PROCINFO PROCESSOR INFORMATION
NTQLAM MSQACCES NT MSSQL:ACCESS METHODS
NTQLBM MSQBUFMG NT MSSQL:BUFFER MANAGER
NTQLBN MSQBUFND MSSQL:BUFFER NODE
NTQLDA MSQDATAB NT MSSQL:DATABASES
NTQLMM MSQMEMMG NT MSSQL:MEMORY MANAGER
NTSERV SERVER NT SERVER
NTSQSV SQLSSISV SQLSERVER:SSIS SERVICE 11.0
NTD011 CLUSTER_RESOURCE_CONTROL_MANAGER
NTD015 HYPER_V_DYNAMIC_MEMORY_BALANCER
NTD016 HYPER_V_DYNAMIC_MEMORY_VM
NTD018 HYPER_V_HYPERVISOR_LOGICAL_PROCE
NTD019 HYPER_V_HYPERVISOR_PARTITION
NTD020 HYPER_V_HYPERVISOR_ROOT_PARTITIO
NTD021 HYPER_V_HYPERVISOR_ROOT_VIRTUAL
NTD030 HYPER_V_VM_VID_PARTITION
NTD035 HYPER_V_VIRTUAL_NETWORK_ADAPTER
NTD037 HYPER_V_VIRTUAL_SWITCH
NTD038 HYPER_V_VIRTUAL_SWITCH_PORT
-Corrections diagnosed and corrected by Phil:
QLGS - NRDATA=24 supported
QLAM - MSEXCART removed from INPUT, not kept, not there
ASPA - ASPARWTB removed from NRDATA=85 INPUT, not there
-Additional records changed:
QLDA - NRDATA=26 supported.
Thanks to Phil Henninge, Demand Technology, USA.
Change 31.029 Test added to ensure GDGLEN GT 9 before SUBSTR function,
VMAC6156 to protect for INVALID SECOND ARGUMENT when the SMF 66
Feb 26, 2013 record for a RENAME of DSN=X.Y to DSN=A.B.G0002V00 had
an entry name too short to be tested for a GOOVO.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 31.028 -All of these members used VIEWs which are not supported
ANALCOMP by WPS. Code was added to the macros to make the use of
VGETLIBS views conditional depending on the value of MXGVIEW that
VGETWKLD is set by VMXGINIT based on the version of SAS or WPS
VMXGFIND being run.
VMXGSRCH -In the case of VGETWKLD, it was not correctly gathering
Feb 24, 2013 the number of periods for TSO workloads because there
are differences in the names of the response time vars
between the older TSO workload and any new workloads you
may have created with RMFINTRV. For these newer
workloads, at the time VMXGRMFI was written the limit on
variable names was 8 characters so a name like DB2P1RESP
would not have been possible so RSP was used rather than
RESP to keep the variable names down to 8 bytes. That
limit no longer applies but changing old variable names
would be a bad thing to do to you so VGETWKLD now checks
correctly for the old TSO variable names.
Change 31.027 Variable QWHCEUWN has been added to the all T102Sxxx DB2
VMAC102 trace datasets.
Feb 22, 2013
Thanks to Tony Anderson, Blue Cross Blue Shield of Alabama, USA.
Change 31.026 SAS 9.1.4 SP4 ONLY: Note 33063 states that SASHELP.VEXTFL
PREINIT dataset only has the FIRST external file reference, if an
VMXGINIT AUTOCALL is issued, which happens by design in VMXGINIT,
Feb 22, 2013 so any subsequent reference to SASHELP.VEXTFL has only
that first DDNAME/LIBREF. There is NO FIX for 9.1.3:
"The only known solution is to process the dictionary
table SASHELP.VEXTFL prior to any system AUTOCALL."
You can use DATA WORK.VEXTFL; SET SASHELP.VEXTFL; in
PREINIT to save the VEXTFL table into //WORK.
Change 31.025 See Change 31.151.
Feb 20, 2013
Change 31.024 Format $MGSMFID had "DEFINE" rather than "DEVICE" in the
FORMATS description of the ID=11 SMF record.
Feb 20, 2013
Thanks to Mike Mayne, HHSYS, USA.
Change 31.023 Support for Software Diversified Services VFTP product
EXVFTP01 user SMF record creates these four new datasets:
EXVFTP02
EXVFTP03 DDDDDD MXG MXG
EXVFTP04 DATASET DATASET DATASET RECORD
IMACVFTP SUFFIX NAME LABEL SUBTYPE
TYPEVFTP
TYPSVFTP VFTP01 VFTPST01 VFTP01:SESSION AND TRANSFER 01
VMACVFTP VFTP02 VFTPST02 VFTP02:LOGIN FAILURE 02
VMXGINIT VFTP03 VFTPST03 VFTP03:SERVER REJECTED 03
Feb 18, 2013 VFTP04 VFTPST04 VFTP04:SUMMARY ACTIVITY 04
The start and end times in VFTPST01 dataset are on GMT
but there is no GMT Offset in the record, and the delta
between the End time and the SMF time is as much as 2100
seconds which I believe is in error, and that prevents me
from using that delta to heuristically create the offset.
This is being discussed with the vendor, but you can use
%LET MXGGMTOFF=-6*3600;
%INCLUDE SOURCLIB(....);
to circumvent and set your GMT Offset (remembering to
change each Spring Forward and Fall Backward).
Change 31.022 -Support for Software Diversified Services VIP Product SMF
EXVIPAPL USER record creates these datasets:
EXVIPDLR
EXVIPDLW SDS DDDDDD MXG MXG
EXVIPEEC DATASET DATASET DATASET DATASET RECORD
EXVIPEEX NAME SUFFIX NAME LABEL SUBTYPE
EXVIPFRM
EXVIPHPR DLC1R VIPDLR VIPDLR VIPDLR:DLC READ QUEUE 222
EXVIPHPX DLC1W VIPDLW VIPDLW VIPDLW:DLC WRITE QUEUE 222
EXVIPIFC HPR1 VIPHPR VIPHPR VIPHPR:HPR 228
EXVIPLUG HPR1 VIPHPX VIPHPX VIPHPR:HPR EXTENSION 228
EXVIPOSA RTM1 VIPRTM VIPRTM VIPRTM:TCP TAPM OR TN3270 229,231
EXVIPOSX FRM1 VIPFRM VIPFRM VIPFRM:FRAG MONITOR 230
EXVIPRTM LUG1 VIPLUG VIPLUG VIPLUG:LU GROUP 232
EXVIPSTK OSA1 VIPOSA VIPOSA VIPOSA:OSA 239
FORMATS OSA1 VIPOSX VIPOSX VIPOSA:OSA EXTENSION 239
IMACVIP APL1 VIPAPL VIPAPL VIPAPL:APPLICATION 242
TYPEVIP IFC1 VIPIFC VIPIFC VIPIFC:INTERFACE 243
TYPSVIP STK1 VIPSTK VIPSTK VIPSTK:STACK 244
VMACVIP EEC1 VIPEEC VIPEEC VIPEEC:ENTERPRISE EXTENDER 245
VMXGINIT EEC1 VIPEEX VIPEEX VIPEEC:EE ROUTES 245
Feb 22, 2013 -The variable names in these datasets are the same as the
names in the SDS-provided example SAS programs and the MXG
dataset names are similar so the SDS-provided SAS reports
should be easily adapted to use the MXG datasets. The MXG
code is structured so all records can be processed in one
pass (the SDS example program processed one subtype per
program) and the MXG "dddddd" tokens are created to permit
standard MXG tailoring of datasets and contents.
-The SDS-example variable names are long with underscores
embedded; the MXG label replaced the underscore with the
normal asterisk character so you will almost always want
to use PROC PRINT SPLIT='*' with VIP datasets to get nice
column headings and alignment.
Change 31.021 -RMF III Enhancements and Notes
ASMRMFV -NOTE: Since MXG V30.03 it is required that SYS1.MODGEN
JCLASM3 also appear in the SYSLIB DD concatenation for the
JCLRMFV ASMRMFV assemble step as follows (use JCLASM3 example):
JCLCRMFV
VMACRMFV //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR
Feb 15, 2013 // DD DSN=SYS1.MODGEN,DISP=SHR
Feb 26, 2013
Mar 10, 2013 ASMRMFV displays execution environment data that needs
the macros in SYS1.MODGEN to map certain z/OS control
blocks. Omission of SYS1.MODGEN in the assembly step
will result in ASMA prefixed error messages and the
assembly will fail.
-ASMRMFV and VMACRMFV must be at the same level; do not
expect the old VMACRMFV to read RMFBSAM files created
by the new ASMRMFV, and vice versa.
-When the ASI table is selected in ASMRMFV the entries
are now blocked up to use as much as possible of a 32K
logical record. The number of ASI records output was
reduced by up to 96% during testing.
-The example members JCLRMFV and JCLCRMFV for building an
RMF III PDB have been improved by adding a new example of
using the SIZE parameter to examine RMF III VSAM data set
disk space and index usage. Additional information about
use of ASMRMFV parameter aliases is also now included.
-VMACRMFV is upgraded to support blocked ASI entry input.
-VMACRMFV now displays a message about ASMRMFV level and
execution environment that created the RMFBSAM file.
-MISSING VALUES message on SASLOG for CPUDTIME variable
is removed in VMACRMFV. Input logic for CPUDTIME is
improved.
-NOTE: The use of archival RMFBSAM files as input to
TYPSRMFV or TYPERMFV is NOT recommended as many missing
values and other undesirable results can occur in the PDB
since VMACRMFV is expecting data in the current input
format. The RMFBSAM file is intended only as temporary
work file for the PDB build process and should not be
retained for future use. A better alternative is to
instead restore the archived RMF III VSAM file and read
it with the current ASM/VMAC RMFV program pair.
-NOTE: If intending to include the UWD table datasets in
the RMF III PDB %INCLUDE SOURCLIB(TYPSRMFV) not TYPERMFV
should be used in PDB build step. There are naturally
occurring duplicates in the UWD table that need to be
removed by the sorting process.
-When the ENC table is selected in ASMRMFV the entries are
now blocked up to use as much as possible of a 32K
logical output record.
-VMACRMFV is upgraded to support blocked ENC entry input.
-ASMRMFV now inputs all 6 ENC table entry triplets instead
of only the first one. Each offset/length/count triplet
points to a separate group of ENC table enclave entries.
Users including the ENC table in their RMF III PDB can
expect 5 times as many observations in ZRBENC dataset;
documentation on the number of ENC triplets was unclear
until actual data provided the actual documentation that
that there were 6 triplets and not just 1.
-Note: The total number of ENC table records output will
now be at least 6 times the number of tables input since
each of the 6 triplets causes a new record to be output.
-REQUIREMENT: In order to receive the performance benefits
from ASI and ENC entry blocking, the current ASMRMFV
utility program with this MXG change must be installed.
See MXG SOURCLIB member JCLASM3 for sample JCL for the
assembly and link-edit install steps.
-Tutorial: This item has been mentioned before, but with
the ASI and ENC blocking and increase in observations,
you may need to use the EXdddddd dataset exit to filter
which observations are created, and your logic in those
exits should always use this code structure:
IF something THEN DO;
OUTPUT _Wdddddd;
END;
and can't use a DELETE, RETURN, nor "IF something;" logic
because when "something" is true, they stop the read of
this current record, skipping any un-read segments from
being tested for "something".
This consideration applies in particular to the following
RMF III tables that have blocked input data to a PDB
build and to their respective output exits:
RMF III Table Output Exit
------------- -----------
ASI EXZRBASI
CPD EXZRBCPD
CSR EXZRBCSR
DVT EXZRBDVT
ENC EXZRBENC
ENT EXZRBENT
OPD EXZRBOPD
RED EXZRBRED
SHD EXZRBSHD
SPG EXZRBSPG
UWD EXZRBUWD
Thanks to Perry Lim, Union Bank, USA
Thanks to Betty Wong, Bank of America, USA
Change 31.020 Support for TMON/MQ Version 2.5 which added a number of
VMACTMMQ new variables to the TMMQQA dataset.
Feb 15, 2013
Thanks to Paul Volpi, UHC, USA.
Thanks to Homayoun Riazi, UHC, USA.
Change 31.019 Option PDBOUT= lets you output the PLOT and MSU datasets
ANALCAPD to your PDB library. By default they were temporary and
Feb 13, 2013 are deleted by ANALCAPD. This change deletes the delete
but this text will be updated when the PDBOUT= option is.
Thanks to Ralph Belamy, ???, ???
Change 31.018 Support for PACE's IDMS 17.0 User Exit SMF Record.
ASMIDMPA DDDDDD DATASET DESCRIPTION
EXIDMPAC IDMPAC PACEIDMS PACE IDMS USER SMF RECORD
IMACIDMP The SMF record is created in an IDMS Exit by ASM code
TYPEIDMP contributed by Blake Leggett, PACE Applied Technology,
TYPSIDMP their product KOMAND IDMS Charging System, KOMAND/IDMS.
VMACIDMP See the ASMIDMPx members documented in Change 31.068.
VMXGINIT However, neither PACE nor MERRILL will guarantee ASMIDMP
Feb 20, 2013 exit code will always work with future IDMS changes; this
Mar 9, 2013 now works fine, but your IDMS staff must be prepared to
ASMIDMPJ investigate and repair any exit problems in the future.
ASMIDMPS If your guru can fix the exit, I can update the SAS code!
ASMIDMPU
Thanks to Blake Leggett, PACE Applied Technology, Inc., USA.
Thanks to Trevor Rowe, Bell Alliant, CANADA.
Change 31.017 Change 29.167 enhanced VXMGRMFI by creating the VGETWKLD
ANALCOMP member used when TRNDRMFI is invoked; VGETWKLD extracts
VGETLIBS your workload names by reading DICTIONARY.TABLES to get
VGETWKLD your variable names from PDB.RMFINTRV by using
VMXGFIND PROC SQL;
VMXGSRCH CREATE VIEW VGETWKLD AS SELECT NAME,LABEL
Feb 12, 2013 FROM DICTIONARY.COLUMNS. . . .
and then reading dataset VGETWKLD with this logic
POINT=LENGTH(NAME)-2;
IF SUBSTR(NAME,POINT,3)='ZIP';
but that logic failed with WPS, perhaps due to the VIEW,
as views are not yet supported in WPS, or perhaps because
WPS created a different LENGTH value, but in either case
POINT1=INDEX(NAME,'FRTM');
IF POINT1;
now circumvents the error, even with "VIEW" in the code.
The FRTM suffix test was used in place of ZIP as not all
sites create a xxxxZIP workload variable. And just to
be safe, the "VIEW" text was removed from VGETWKLD and
the other four members.
Change 31.016 -Support for BVIR Version 2.0, 2.0a, and 2.1.
VMACBVIR -BVIR30 adds two new variables:
Feb 11, 2013 SYLVMT00='00*SYNC*LEVEL*MOUNTS'
AVLVMT00='00*AVERAGE*SYNC*LEVEL*MOUNT*TIME'
-BVIR32 documentation: IBM change how they count bytes:
"TVCSIZE: increments of 1000MB (1024*1024*1000). A TVC
that is 1.7TB in size will be reported as x000006A4
which is 1700 decimal."
MXG did not format TVCSIZE with MGBYTES but 6A4 is the
decimal TVCSIZE=1700 with the label "TVCSIZE IN GB".
-IBM confirmed that variable LIBSEQNR is now always
blank or nulls - see ADOCBVIR.
-Variable DLIBDEQN can contain hex rather than EBCDIC,
or it can be blank.
-BVIR32 variable AVGCPUSE is labeled as
AVGCPUSE 'CPU*USAGE*PERCENT*AT END OF*INTERVAL'
but it contains the AVERAGE CPU PER TAPE VOLUME CACHE
and its documentation clarified by IBM in the manual:
This 1 byte field indicates the larger of CPU usage
percentage OR Tape Volume (TVC) usage percentage at
the end of the interval. The TVC busy value is based
on IO activity where 100% is when the disks are being
accessed 100% of the time. This value can be used to
indicate how busy the system was during the interval.
It is updated every 30 seconds. The TVC percentage is
an average of 30 one second intervals.
-BVIR31 new variables are documented and created:
BYTESEXP='AMOUNT*OF DATA*EXPORTED'
BYTESIMP='AMOUNT*OF DATA*IMPORTED'
LOGVOLEX='LOGICAL*VOLUMES*EXPORTED'
LOGVOLIM='LOGICAL*VOLUMES*IMPORTED'
PHYVOLEX='PHYSICAL*VOLUMES*EXPORTED'
PHYVOLIM='PHYSICAL*VOLUMES*IMPORTED'
-BVIR33 has eight sets of new variables G1 thru G8 with
G1DEFRBY='1ST DATA*FROM*DEFERRED*COPY'
G1DEFRCY='1ST DATA*FROM*DEFERRED*COPIES'
G1IMEDBY='1ST DATA*FROM*IMMEDIATE*COPY'
G1IMEDBY='1ST DATA*FROM*SYNC MODE*COPY'
G1IMEDCY='1ST DATA*FROM*IMMEDIATE*COPIES'
G1IMEDCY='1ST DATA*FROM*SYNC MODE*COPIES'
Change 31.015 -These five DB2 V10 SMF 101 Subtype 1 DB2ACCTP variables
VMACDB2 QPACLOCN,QPACCOLN,QPACPKID,QPACASHC,QPACAANM, can be
Feb 10, 2013 wrong, but only when they are "truncated":
"IBM-truncated" fields previously had a fixed length
(QPACLOCN was 16 bytes) but now can be variable length
for data like URLs and IPV6 addresses from our open
systems gurus. Each field has an offset to a one-byte
length field followed by that many bytes of the field.
These offsets are NOT populated when the value fits in
the original fixed length field that was already INPUT.
There are two independent errors, one mine, one not mine.
-The MXG code for the offsets to LOCN COLN PKID and AANM
used OFFQPAC+offset, but LOCQPAC should have been used as
it is incremented for each QPAC segment; OFFQPAC isn't.
So those four variable's values were only valid for the
first DB2ACCTP observation in each SMF 101 record.
-One site sent SMF data with invalid values for the offset
to those "truncated" fields. The offset values for each
field is 10 more than it should be. Decimal values:
Segment 5 out of 7 in record 3222:
OFFQPAC LENQPACX Len of PACX Next QPAC
@1777 451 +2 2228
@2228 451 +2
But the two-byte OFFSET to QPACAANM is @2169 with a
'01B8'x or 440 decimal. Adding 1777+440 is 2217, but
the field's length and text are visible in 2207, and
the static portion of this segment ended in 2206.
This change compares the location of the first offset to
the end of the static fields and corrects the offset by
subtraction when they are different.
-Variable QPACRUSM was not reset to blank after it was
set to 'Y' in an SMF record because it was coded as RUSN.
Change 31.014 One user claims MXG's SMF HEADER/TRAILER messages printed
VMACSMF on the SASLOG have caused LINES EXCEEDED messages that he
VMXGINIT doesn't like. I disagree COMPLETELY, and would NEVER turn
Feb 8, 2013 them off, since they can be EXTREMELY useful (albeit in
only rare cases) in problem determination: they print the
begin and end time of each "data chunk" in each SMF Dump.
But it is trivial to create a macro variable SMFPUTHD
that will suppress their printing, using:
//SYSIN DD *
%LET SMFPUTHD=NO;
%INCLUDE ....
And, if after turning them off you realize you need them,
you can read the same SMF file and print them, using:
//SYSIN DD *
%LET SMFPUTHD=YES;
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_; _SMF; RUN;
Clearly, my MXG default is %LET SMFPUTHD=YES;
Change 31.013 Variables NDMCNF1, NDMCNF2, & NDMCPEA were set to '00'x
VMACNDM when they should not have been (and I have no notes as to
Feb 7, 2013 why I set them to null).
Thanks to Randy Schlueter, First Data, USA.
Change 31.012 Change 30.170 output CICLDR observations only when LDRFC,
EXCICLDR Fetch count, is non-zero, but with interval statistics,
Feb 6, 2013 a program can be fetched after the region starts up and
then be continually used afterwards, with LDRFC=0, so
those observations were not output. The CICLDR dataset
exit member EXCICLDR is changed to output when LDRTU, the
Times used Since Last Reset, is non-zero, as that is a
better indicator that the program was used.
Thanks to Tony Hirst, Wells Fargo, USA.
Change 31.011 If you specified WEEKKEEP=TYPE42: that colon caused the
BLDSMPDB the length of the compare to detect what data sets should
Feb 5, 2013 be kept to be incorrectly set to &complen, which was the
length of the input name, but instead is now set to &dlen
which is the correct length for comparison with or
without the colon modifier.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 31.010 MXG 30.08-MXG 30.30. If you selected SYSLOG MSGIDs to be
VMACTMNT written as SMF Subtype=9 by MXGTMNT (Tape Mount Monitor),
Feb 2, 2013 reading them caused zero obs in TYPESYSL and log messages
MSGID NOT FOUND IN RECORD N= . . . .
Change 30.230 enhanced ASMTAPE to write some JES3 event
SYSLOG messages as Subtype=8 so they would be output to
TYPESYMT, but for testing they were created as subtype 9
with the old ASMTAPE, and my test in VMACTMNT to output
them to TYPESYMT was temporarily changed to read them
with ELSE IF TMNTTYPE=8 OR TMNTTYPE=9, but that should
have been changed back to just ESLE IF TMNTTYPE=8.
Thanks to Paul Naddeo, Fiserv, USA.
Change 31.009 The _STYBETF dataset sort macro was not in the _SBETA
VMACBETA product sort macro, so dataset BETA25 was not copied into
Jan 31, 2013 the PDB data library when TYPSBETA was used.
Change 31.008 -Change 30.250 replaced hardcoded "PDB." with "&PDBMXG.."
ANAL120 (so MXG default DDNAME is used by also easily changed,)
Jan 30, 2013 but ANAL120 was wrong before and after, as some of its
datasets were expected to be in //PDB while others were
read from //WORK. This change expects ALL of the TYPE120
datasets will be in the //PDB DD data library before the
%INCLUDE SOURCLIB(ANAL120);
is executed, but new examples in comments show how to
read SMF data to create just reports or to create both a
WebSphere PDB and these example reports. But these are
all simple PROC PRINTs and PROC MEANS and the primary
value is the suggested variables that might be useful as
a STARTING POINT for your own reports
(which I'd be happy to add to the ANAL120 member if
you have a contribution to share with other MXGers).
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 31.007 -VMACVMXA and VMAC113. The HIS CPU Counter variables in
VMAC113 z/VM dataset VXPRCMFC should match those variables in the
VMACVMXA z/OS HIS TYPE113/ASUM113 dataset, but new counters
Jan 28, 2013 EXTND157-EXTND207 in VMACVMXA were not labeled, weren't
deaccumulated with DIF() function, and weren't tested for
RESETCTR+1, and the INPUT thru 255 was changed to the
known maximum counter EXTND207. But then in VMAC113, I
discovered that variables EXTND183-EXTND207 were not
tested for RESETCTR+1. So the MXG QA now ensures counters
match in TYPE113, ASUM113 and VXPRCMFC datasets.
Change 31.006 Support for OAM SMF ID=85 Subtypes 90,91,92 and 93 create
EXTY8590 DDDDDD DATASET DESCRIPTION
FORMATS TY8590 TYPE8590 LCS FILE SYSTEM ACTION
IMAC85 Variable R859SUB contains the subtype and is formatted to
VMAC85 identify 90:WRITE, 91:READ, 92:DELETE, 93:CLEANUP events.
VMXGINIT
Jan 28, 2013
Thanks to Neil Ervin, Wells Fargo, USA
Change 31.005 -Cosmetic. These percentage variables in TYPE72GO
VMAC7072 PCTDLACO PCTDLAPR PCTDLAXM PCTDLCCA PCTDLCDE PCTDLCHS
Jan 26, 2013 PCTDLHSP PCTDLIDL PCTDLIOD PCTDLMPL PCTDLNDI PCTDLPDE
PCTDLPQU PCTDLQ PCTDLSHS PCTDLSMP PCTDLSPV PCTDLSSW
PCTDLSVI PCTDLSWI PCTDLTDQ PCTDLTOT
are now formatted 5.1 to print pretty.
Change 31.004 -RMF III, z/OS 1.13, but only with APAR OA38660, all ASI
ASMRMFV extensions (Service Class, Report Class, Resource Group
VMACRMFV and Workload) are incorrect, because that APAR inserted
Jan 28, 2013 72 at the end of the base segment; record version is now
'16'x, but only '12'x is in RMF Programmers Guide, so it
took SYS1.EYEBALL of a hex record dump to determine what
had been added. Adding data at the end of a segment is
INCOMPAT in this case in MXG because ASMRMFV appends the
extensions to its record, and those new bytes moved the
offset to the extensions. This circumvention corrects:
IF ASIVERG3='16'x THEN INPUT +72 @;
but it requires a code change and a new member.
-But, we see a better way: ASMRMFV will put ASIBASNL, the
base segment length, into the top two bytes of ASIENTMX,
with ASIENTMX in the low two bytes, so that VMACRMFV can
use ASIBASLN to locate the extensions and a future insert
won't require an updated MXG code member nor a new value
for the record version test. Using the length fields are
almost always more robust than using product or record
version values in tests for existence.
-NOTE: It is still possible to have missing values for
variables from one or more of these extensions for
some address spaces. For example, address spaces with
no Reporting Class defined will have variable ASIRNM
missing and those with no Resource Group defined will
have variable ASIGNM missing (blank).
Thanks to Warren Cravey, FMR Corporation, USA
Change 31.003 Message UNINITIALIZED VARIABLE SM1132MM: minimal impact.
ASUM113 A test for SM1132MM was added by Change 30.274 to detect
VMAC113 single book machines so negative values could be zeroed,
Jan 25, 2013 IF SM1132MM='M10' OR L4RP LE 0 THEN DO; /*SINGLE BOOK*/
but SM1132MM was only added to ID= in VMAC113, it was not
added in ASUM113 so it was uninitialized when referenced.
But, as I just discovered in assessing the actual impact
of my error, even when SM1132MM is uninitialized, that OR
in that IF statement causes the expression to be TRUE if
L4RP is zero or a missing value, which is actually a
stronger test for single book than the "Machine Model."
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 31.002 The CICTSQ dataset is merged into PDB.CICINTRV dataset
VMXGCICI but these "newish" variables in CICTSQ were not included:
Jan 24, 2013 A12SHPDF A12SHPCN A12SHRDS A12SHWTS
A12TSLHT A12TSMLM A12TSMUS A12TSMAX
A12TSQDL A12TSCTR
Thanks to Doug Medland, IBM Global Services, CANADA.
Change 31.001 Variable QW0141OT='AUTHORIZATION*ID*TYPE', L for ROLE or
FORMATS blank for User ID or Secondary Authorization ID is INPUT
VMAC102 and kept in T102S141 Audit dataset and formatted.
Jan 23, 2013 Formats $MGD140O now has all $MGD361O entries and formats
MGD140P and MGD361P have the union of separate values.
Thanks to Tommy Grace, Nationwide Insurance, USA.
LASTCHANGE: Version 31.
=========================member=CHANGE30================================
/* COPYRIGHT (C) 1984-2013 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 30.30 was dated Jan 21, 2013, thru Change 30.292.
MXG Newsletter SIXTY-ONE was dated Jan 21, 2013.
MXG Version 30.10 was dated Jan 3, 2013, thru Change 30.274.
MXG Version 30.09 was dated Dec 4, 2012, thru Change 30.253.
First MXG Version 30.09 was dated Dec 3, 2012, thru Change 30.252.
MXG Version 30.08 was dated Nov 7, 2012, thru Change 30.235.
First MXG Version 30.08 was dated Nov 5, 2012, thru Change 30.230.
MXG Version 30.07 was dated Oct 3, 2012, thru Change 30.200.
Second MXG Version 30.07 was dated Oct 2, 2012, thru Change 30.199.
DONTUSE MXG Version 30.07 dated Oct 1, 2012, thru Change 30.198.
MXG Version 30.06 was dated Sep 1, 2012, thru Change 30.177.
Second MXG Version 30.05 was dated Aug 8, 2012, thru Change 30.153.
First MXG Version 30.05 was dated Aug 6, 2012, thru Change 30.151.
MXG Newsletter SIXTY is dated Aug 6, 2012.
MXG Version 30.04 was dated Jul 4, 2012, thru Change 30.124.
First MXG Version 30.04 was dated Jul 2, 2012, thru Change 30.122.
MXG Version 30.03 was dated May 30, 2012, thru Change 30.096.
MXG Version 30.02 was dated Apr 15, 2012, thru Change 30.062.
MXG Version 30.01 was dated Feb 13, 2012, thru Change 30.021.
Annual MXG Version 29.29 was dated Jan 23, 2012, thru Change 29.307.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 30.30 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 30.30.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================
I. MXG Version 30.30 dated Jan 21, 2013, thru Change 30.292.
Major enhancements/corrections added in MXG 30.30, dated Jan 21, 2013:
ANALCOMP 30.286 Graphic comparison of values over time.
TYPE110 30.278 TASZIPTM and TASELGTM documented, TASELGTM corrected.
TYPETMO2 30.277 Support for TMON CICS 3.4 for CICS/TS 5.1 INCOMPAT.
TYPEMVCI 30.276 Support for Mainview CICS 6.5 for TS 5.1 COMPATIBLE.
TYPEBETA 30.285 Support for BETA93 subtype 51.
TYPETAPR 30.284 Support for additional PHYSVOL/VOLUME file fields.
UTILEXCL 30.278 MXGNOTE on log identifies create date of IMACEXCL.
JCLSPLIT 30.287 Examples DECOMPRESS CICS/DB2 on z/OS for ASCII MXG.
UTILEXCL 30.283 Better support for UNKNOWN FIELDS to prevent 180.
READDB2 30.280 MXG 30.10 IFCID=STATS could still fail.
VFMT102 30.279 VFMT102 mapping DBID/OBID/PSID safer algorithm.
MXGNAMES 30.275 MXGNAMES/CONFIMXG supports a USER FORMAT library.
Major enhancements/corrections added in MXG 30.10, dated Jan 3, 2013:
VMXGALOC 30.273 SERIOUS ERROR if MONTH is used with VMXGALOC/UTILBLDP
TYPE7072 30.264 Support for APAR OA39562 new TYPE70Y3 PKCS11 CEX4P.
TYPE99 30.259 Support for SMF 99 Subtype 12 and 14 HiperDispatch.
TYPEVMXA 30.254 Support for zVM new CRYPTO TYPE PRCAPMCT=10.
TYPEVMXA 30.254 Support for zVM new HIS (SMF113) counters, zEC12.
TYPE102 30.265 Support for DB2 Trace IFCIDs 361 and 362 populated.
TYPEIDMS 30.270 Support for IDMS PERFMON Version 17 and 18.
READDB2 30.257 IFCIDS=STATS fixed, use instead of IFCIDS=STATISTICS.
BUILDPDB 30.260 PDB.JOBS variable ABENDS count included some RETURNs.
BLDSMPDB 30.255 WEEKKEEP, WEEKDROP now work as documented.
ASUM70PR 30.266 Variable LFARIFLS added to ASUM70PR datasets.
TYPE113 30.274 Correction to DWINSORM/DWDASORM for one book CEC.
SMFSRCH 30.269 Incorrectly tried to write to USERID.SMFOUT.DATA.
TYPE80A 30.268 RACF317 detect BPX.DEFAULT.USER, invalid in z/OS 2.1.
Major enhancements/corrections added in MXG 30.09, dated Dec 3, 2012:
TYPE120 30.244 Support for WebSphere Version 8 ID=120 Subtype 10.
TYPECIMS 30.245 Support for BMC Mainview IMS 4.6 a/k/a IMF, CIMS.
TYPEEJES 30.238 Support for Phoenix Software (E)JES SMF record.
TYPEBETA 30.237 Support for BETA93/97 Version 4.3.0 (INCOMPATIBLE).
TYPE119 30.249 SMF ID-119 SUBTYPE=51 INPUT STATEMENT EXCEEDED.
TYPEDB2 30.246 DB2STATS QWOSxxxx wrong if ZOSMETRICS=YES not set.
VMXG2DTE 30.242 New CRITERIA= parameter inserts selection SAS code.
ANALDB2R 30.241 Revised mapping of DBID and OBID objects to names.
VFMT102 30.241 Revised mapping of DBID and OBID objects to names.
GRAFDB2B 30.240 Graphic/tabular DB2 Buffer Size reports, ODS or GRAPH
VMXGCOPY 30.243 VMXGCOPY copies SAS datasets from multiple LIBNAMEs.
TYPE113 30.236 Spurious DEACCUMULATION RESET message not printed.
Major enhancements/corrections added in MXG 30.08, dated Nov 7, 2012:
If you downloaded MXG 30.08 dated Nov 5, please refresh with Nov 7:
Change 30.234 is REQUIRED with APAR OA37826 (z/EC12 TYPE74); it was
NOT in MXG 30.08 dated Nov 5. Use only the Nov 7 Version 30.08 if
you have installed that APAR:
TYPE74 30.234 ERROR: INVALID DATA FOR CHAR4, STOPOVER, APAR OA37826
TYPE110 30.228 Support for CICS/TS 5.1 INCOMPATIBLE - 30.08 REQUIRED
TYPEDB2 30.229 Support for DB2 NETEZZA optional data corrections.
TYPE113 30.201 Support for HIS zEC12 new Extended Counters, calcs.
TYPE7072 30.212 Support for zEC12 CRYPTO EXPRESS4S APAR OA37016.
TYPE74 30.209 Support for APAR OA37826 Channel Path Types CIB, CFP.
TYPE70 30.208 Support for APAR OA37803 Warning Track Interrupt.
TYPE74 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE79 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE71 30.206 Support for APAR OA38660 eC12 SCM and Pgbl Large.
TYPE78 30.206 Support for APAR OA38660 TYPE78PA additions.
TYPEDCOL 30.204 Support for APAR OA38980 ZFS dataset flag, FREEs.
ASUMTAPE 30.203 Support for JES3 Main Device Scheduler IAT5210/5918.
ASUMTAPE 30.203 INCOMPATIBLE: PDB.ASUMTAPE SORT ORDER CHANGED.
TYPENMON 30.226 Support for MEMAMS Memory Object, French text.
TYPENDM 30.220 Support for NDM-CD Subtype CX creates NDMCX dataset.
TYPE110 30.213 MXG 30.07 only. CICS STID=30 WARNING message fixed.
TYPEDB2 30.210 DB2 V10 APAR PN29124 detects IBM BIF INCOMPATIBLE.
TYPETPMX 30.216 MVS Solutions Thruput Manager SMF subtype 5 updates.
ASMRMFV 30.202 RMF III Enhancements and Fixes.
TYPERMFV 30.217 Reading RMF III data on ASCII - INVALID date message.
TYPEVMXA 30.215 z/VM BROKE CONTROL record when MONWRITE concatenated.
TYPEDB2 30.211 QISTCOLS now deaccumulated again.
TYPEDB2 30.222 IFCID=239 DB2ACCTP sets DB2PARTY, QPACROLL, QPACRUSM.
VFMT102 30.219 NODUPKEY temp circumvention for overlapped range.
TYPE70 30.233 TYPE70 CPUWAITM incorrect, greater than CPUUPTM
TYPETMS5 30.205 Variable ACTVOL added to TMS.TMS dataset.
ANALDB2R 30.219 Mapping of dBID/OBID values to names revised.
ANALDB2R 30.218 INTERVAL=xxxx wasn't supported, VMXGUM MXGERROR.
VMXGFIND 30.214 VMXGFIND to print all datasets had wrong title.
Many 30.225 New MXGEXIMSG macro variable for diagnostics.
Major enhancements/corrections added in MXG 30.07, dated Oct 3, 2012:
TYPE7072 30.182 Support for zNEXT EC12 processors with 101 engines.
ASMTAPEE 30.193 MXGTMNT Tape Mount Monitor no longer PINs UCBs.
TYPEVMXA 30.192 z/VM Linux Processor VXAPLSL0 dataset wrong values.
TYPEVMXA 30.190 z/VM 6.1 BROKEN CONTROL RECORD if STSI is 152 bytes.
TYPEDB2 30.194 QMDAACCT field LENACCT=246 caused INVALID 3rd SUBSTR.
TYPE119 30.188 Support for SMF 119 subtype 48 thru 52 (SMTP).
ANALDB2R 30.185 Redesign to execute VFMT102 only once per ANALDB2R.
ANALDB2R 30.186 New "MXG" DB2 reports MXGACC01 and MXGACC02.
VFMT102 30.183 30.05/30.06 VFMT102 could have overlapped range.
VMAC113 30.179 Formula changes from John Burg's SHARE presentation.
BLDFORMT 30.191 JCL Example using CONFIMXG to create FORMAT library.
VMXGSUM 30.189 Use of %CMPRES replaced by %SYSFUNC which is in base.
Major enhancements/corrections added in MXG 30.06, dated Sep 1, 2012:
TYPE120 30.155 Support WebSphere Asynchronous Section 120 Subtype 9.
TYPETAPR 30.164 Support for Tandem Prognosis data files.
TYPEZVPS 30.154 Support XAM/ZVPS VCPU Virtual CPU segment XMUSVCPU
TYPE102 30.175 Support for IFCID=271 DB2 AUDIT PERMISSIONS trace.
TYPE102 30.169 Invalid IFCID=145 QWT02R1L=0 caused ABEND & LOOP.
TYPENTSM 30.159 Support MicroSoft Exchange 2010 incompat changes.
TYPENMON 30.137 Updates to NMON/TOPAS Monitor for AIX and LINUX.
UTILEXCL 30.157 New REPORT THREE-A IMACICEZ, IMACICE1, and IMACICE2.
TYPERACF 30.162 RACF AUDITFID is RACF264 (TYPE80A) or AUDITID (RACF)
TYPE120 30.155 Variable SM1209CX incorrect in TYP1209E.
ASUMUOW 30.166 Optional add PROGRAM and PROG1-PROGnn to PDB.ASUMUOW.
TYPEWWW 30.163 Windows IIS Server Log, strange URIQUERY, looped.
TYPENTSM 30.156 Terminal Service object fields reversed, 2003vs2008R.
ASMRMFV 30.161 RMF III protection/messages for VSAM read I/O error.
TYPERMFV 30.172 RMF III Enhancements.
TYPEDB2 30.173 Spurious INVALID QMDA SEGMENT message eliminated.
VMXGINIT 30.171 Macro variables &PCICMNR and &WCICMNR reinstated.
TYPE110 30.170 Obs count in CICLDR reduced from 1.7M to 70,000.
VGETOBS 30.177 SAS 9.2 z/OS ONLY VGETOBS didn't recognize tape dset.
Major enhancements/corrections added in MXG 30.05, dated Aug 8, 2012:
EXITCICS 30.130 DB2 V10 compressed records "enhanced": NOW WORKS!
(And this VERSION 3 DOES NOT NEED CICS MACRO LIBRARY).
ANALDB2R 30.147 DB2 AUDIT reports updated for DB2PM Version 4.2
TYPE102 30.140 Support for IFCID 269,270 Audit, decodes uniques.
TYPEDB2 30.133 Support for (optional) DB2 Netezza Accelerator data.
TYPEDB2 30.138 ASG TMON/DB2 PTF TE03737 corrects INVALID DB2 RECORD.
VGETALOC 30.135 Dynamic allocation of AUTOALOC=YES LIBNAMEs.
VMXGALOC 30.131 New READONLY and CLEARLL parameters.
TYPE21 30.132 Corrections to SMF 21 calculations of compression.
ANALGRID 30.126 Date range selection did not work.
TYPERMFV 30.151 Additional Enhancements for RMF III processing.
Major enhancements/corrections added in MXG 30.04, dated Jul 4, 2012:
UTILEXCL 30.100 DO NOT USE UTILEXCL in MXG 30.03, "NON-FIRST" error.
TYPE30 30.119 Support for APAR OA39629 HICPUPCT/HICPUPGM TYPE30.
TYPEMVCI 30.109 Support for Mainview CICS v64 CICS/TS 4.2 (COMPAT).
TYPETMD2 30.107 Support for ASG/Landmark TMON DB2 PTFs TE03699/03718.
ASMRMFV 30.105 Support for RMF III ASIG3 segments '13'x and '14'x.
TYPE119 30.099 Support for CO:Z SMF 119 Subtypes 192 and 193.
TYPE1415 30.103 Support for z/OS 1.13-added RAS segment (COMPATIBLE).
TYPERACF 30.120 Support for RACF database Record 02G1.
TYPEDB2 30.113 Support for DB2 V10 restructured QIST statistics.
TYPEZPRO 30.116 Support for Voltage SecureData for z/OS z/Protect.
ASUM70PR 30.106 zIIP SHARE WEIGHTS calculated for each LPAR.
TYPEDCOL 30.098 DCOLLECT BKUP fields added by z/OS 1.11 supported.
TYPE70EN 30.104 Variable SMF70CIN in TYPE70EN was 'ZIP', now 'IIP'.
TYPE119 30.121 Additional formats to decode TYPE119 SSH fields.
TRNDRMFI 30.115 Revisions for TRNDRMFI using VGETWKLD.
TYPESASU 30.114 SAS User Records with SASPROC='SQL (63)' protected.
TYPEPMX 30.112 Variables TPMAJCT/TPMSCT too large by 100.
TYPE80A 30.111 Debugging PUT 'DEBUG 1' is now disabled.
TYPEWPMO 30.110 Windows PERFMON data now supports any delimiter.
Major enhancements/corrections added in MXG 30.03, dated May 30, 2012:
ASMRMFV 30.095 Major RMF Enhancements.
ANALID 30.042 SMF AUDIT REPORT - MAJOR ENHANCEMENT - IN BUILDPDB.
TYPEDB2 30.089 Support for DB2 V10 APAR PM24723 adds data IFCID=225.
TYPE105 30.080 Support for GDPS SMF 105 now validated with SMF data.
TYPESAMS 30.073 Support for CA Vantage Stor Resc MGR 12.6.00 INCOMAT.
TYPE74 30.072 Support for RMF 74 APAR OA36831 (COMPAT) SMF74NSS.
TYPECMA 30.070 Support for CA-Spool Subtype 12 (partial).
TYPEFERT 30.066 Support for new subtype 1 and 4 FERRET SMF records.
TYPE115 30.064 Support for MQ QJST 7.01B Statistics Block.
TYPE117 30.063 SMF 117 IMFL subtype SM17ACCT kept in WS 7.0.0.3 SMF.
UTILEXCL 30.092 WMQGETTM, others, incorrectly multiplied by 16.
TYPE60 30.082 INPUT EXCEEDED for ID=60 with no VVR segment.
BLDSMPDB 30.081 Enhancement adds rundays=mon tue ... to list days.
TYPE110 30.078 SMSxxxxx variables were 1024 times large.
READDB2 30.077 Cleanup of WANTONLY, IFCID=STATS, 106, etc.
TYPETPMX 30.075 READTIME kept in all, JOB/JESNR/JBL24 in TPMJBL24
TYPE7072 30.069 New 1.13 CPUPDPTM/R723RTDM/RTDC/RTDT now populated.
DAILYDSN 30.068 DAILYDSN now uses EDGRXEXT instead of EDGRDEXT.
TYPE71 30.083 ERROR: DOMAIN ERROR, SAS 9.1.3 SP4 Only.
Major enhancements/corrections added in MXG 30.02, dated Apr 15, 2012:
BUILDPDB 30.042 SMF AUDIT REPORT
Many 30.012 RUN STATEMENT HAS NO EFFECT message is removed.
READDB2 30.031 Requesting IFCIDS=ACCOUNT with IFCIDS from SMF 102
TYPE0 30.040 Variable DOWNTM was a missing value in PDB.IPLS.
TYPE102 30.037 Support for BMC APPTUNE V6R3 SMF 102 records INCOMPAT
TYPE102 30.038 Support for DB2 IFCIDs 357 and 358.
TYPE102 30.055 Support for DB2 APAR PM37956 to SMF 102 IFCID 25
TYPE110 30.008 CICS/TS 4.2 INVALID STILEN STID=116, zero obs STISJS
TYPE119 30.009 Support for SMF 119 ST 6 z/OS 1.13 (INCOMPAT).
TYPE21 30.014 Support for APAR OA33947 for TS1140 Tape Drive
TYPE71 30.058 New vars added to RMF TYPE71 dataset by z/OS 1.13
TYPE73 30.004 Some FICON-related variables were wrong values.
TYPE73 30.054 ERROR: Zero divide in SMF 73 records, new FICON data.
TYPE85 30.050 Support for SMF 85 records from z/OS 1.13 (INCOMPAT,
TYPEBBMQ 30.047 Support for BMC Mainview for MQ Version 5.1 (INCOMPAT
TYPEBVIR 30.057 Support for TS7700 Version 2.0a (INCOMPATIBLE)
TYPEDB2 30.032 DB2 variable QWHDRQNM can contain an ipv6 address.
TYPEEZSM 30.041 Support for EMC EzSM z/OS Storage Manager SMF record
TYPEHSM 30.006 Support for HSM SMF z/OS 1.12 changes (COMPATIBLE)
TYPEM204 30.002 MODEL 204 records could be output to wrong dataset.
TYPENDM 30.039 NDM-CDI record 'XO' caused "UNKNOWN SUBTYPE" message.
TYPENTSM 30.044 Updates to D062, D063, D060, VWRP, D059, D057, VWVS.
TYPERMFV 30.043 Updates for RMF III RCD records without....
TYPERSDA 30.035 RSD/FOLDERS name fields were increased to $250.
TYPESVIE 30.051 Support for SYSVIEW PTF Test APAR TSD0145, for IMS.
TYPETMD2 30.060 Support for TMON/DB2 V5, INCOMPATIBLE, for DB2 V10.
TYPETMMQ 30.025 Support for TMON for MQ Version 2.2/2.3/2.4 INCOMPAT
TYPEXAM 30.003 Spurious XAM INVALID CPU RECORD messages.
UTILCPLG 30.026 %UTILCPLG will copy your .LOG and .LST files.
VMACSMF 30.023 A third-party product creates invalid DB2 ID=101
VMXGGETM 30.034 VMXGGETM only supported 512 subtypes.
Major enhancements/corrections added in MXG 30.01, dated Feb 13, 2012:
BUIL3005 30.011 MXG 29.29 BUILDPD3 for JES3 CRITICAL ERROR, REQUIRED.
PDB.JOBS incorrectly built with 29.29. JES 3 ONLY.
This change motivated the release of MXG 30.01.
TYPE119 30.009 Support for SMF 119 ST 6 z/OS 1.13 (INCOMPAT).
No execution error, but data in TYP11906 is wrong.
TYPE110 30.008 CICS/TS 4.2 INVALID STILEN STID=116, zero obs STISJS
Possible loss of subsequent statistics subtypes.
TYPE21 30.014 Support for APAR OA33947 for TS1140 Tape Drive
TYPE73 30.004 Some FICON-related variables were wrong values.
TYPE102 30.001 QW0319FL, Encryption Type, format AES/DES reversed.
ANALDB2R 30.007 PMSTA01/PMSTA02 DB2 Statistics, INTERVAL=DATE fixed.
TYPEM204 30.002 MODEL 204 records could be output to wrong dataset.
TYPEHSM 30.006 Support for HSM SMF z/OS 1.12 changes (COMPATIBLE)
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Version 9.3 TS1M1 is RECOMMENDED for all PLATFORMS, because
SAS Version 9.3 TS1M0 REQUIRES THE HOT FIX in SAS NOTE SN43828
(for all platforms), and TS1M1 contains that Hot Fix.
***************************************************************
As documented in Change 27.356, with SAS V9.3):
The standard SAS JCL Procedure can be used for MXG:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS93 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 30.30 will execute under SAS Version 9.3, on
all supported platforms, but as noted above, you need TS1M1. With
TS1M0, then the Hot Fix in SAS Problem Note SN43828 is REQUIRED to
correct an error in the %MACRO compiler, which is SAS portable
code, so that Hot Fix is required for ALL platforms.
The %MACRO compiler error is in processing %LET statements. While
only two MXG members failed repeatedly in MXG QA tests on z/OS,
there were random %LET errors in ASCII QA tests, so ANY use of
%LET statement on ANY platform are vulnerable to this error, as
the %MACRO compiler is SAS portable code, used on all platforms.
So this is NOT just an MXG error, but impacts ALL SAS programs.
With the Hot Fix on TS1M0, the full MXG QA test stream executed,
and there were no new warnings on z/OS.
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
MXG 26.03 thru MXG 30.30 will execute under SAS V9.2, or with
SAS V9.1.3 with Service Pack 4, on all supported SAS platform.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS/DB2 Decompression Infile Exit.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN platform,
but SAS V9.2 does execute on that platform.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I can not guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3, FOR BOTH OF US, TO AVOID FIXED PROBLEMS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG
Version 26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2 and V9.3
are interchangeable and can be read/written by any of those
versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.3 did change ODS processing defaults and syntax that
might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support V9.3 ODS, and MXG 29.06 is STRONGLY recommended for ODS
with SAS V9.3.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, and V9.2.
V9.2-created "PDBs" can be read/written by SAS V8.2 or V9.1.3,
and vice versa.
MXG Versions 26.03+ execute with SAS V9.2 with NO (new) WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG QA tests are executed on z/OS with SAS V9.1.3 and V9.2 and
on Windows XP with 32-bit INTEL, and on Windows Seven Ultimate
32-bit and 64-bit OS on 64-bit hardware, but MXG is installed
on many more hardware and software platforms: since they all work,
we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.4 requires MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for "MXG Support for WPS Software"
IV. MXG Version Required for Hardware, Operating System Release, etc.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.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 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
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 29.05*
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 30.01*
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 30.30
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 Full plus Compressed. Nov 1, 2010 28.07*
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 28.28*
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 29.07*
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 30.07*
DB2 10.1 DBID/OBID decode Jan 21, 2013 30.30*
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Webshpere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
IMS log 11.0 Apr 1, 2010 28.02*
IMS log 12.0 Jan 23, 2012 29.29*
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for DB2 Version 5.0 30.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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
The Monitor for CICS TCE 3.4 (for CICS/TS 5.1) 30.30
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
The Monitor for MVS/ESA 3.0 - 19.19
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
APPTUNE V6R3 SMF 102 30.037
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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
IMF 4.5 (for IMS 11.1) (No change since 4.4) 27.07
IMF 4.6 a/k/a Mainview IMS 30.09
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
V. Incompatibilities and Installation of MXG 30.30.
1. Incompatibilities introduced in MXG 30.30:
a- Changes in MXG architecture made between 30.30 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 30.30 after MXG 29.29:
Dataset/
Member Change Description
ANALCOMP 30.286 Graphic comparison of values over time.
ANALDB2R 30.007 PMSTA01/PMSTA02 DB2 Statistics, INTERVAL=DATE fixed.
ANALDB2R 30.147 DB2 AUDIT reports updated for DB2PM Version 4.2
ANALDB2R 30.176 New AUDIT= parms, PMACC02 standalone error fixed.
ANALDB2R 30.185 Redesign to execute VFMT102 only once per ANALDB2R.
ANALDB2R 30.186 New "MXG" DB2 reports MXGACC01 and MXGACC02.
ANALDB2R 30.218 INTERVAL=xxxx wasn't supported, VMXGUM MXGERROR.
ANALDB2R 30.219 Mapping of dBID/OBID values to names revised.
ANALDB2R 30.241 Revised mapping of DBID and OBID objects to names.
ANALGRID 30.126 Date range selection did not work.
ANALID 30.042 SMF AUDIT REPORT - MAJOR ENHANCEMENT - IN BUILDPDB.
ASMDBLKU 30.168 Enhancement to ASM program that recreates VB & VBS.
ASMRMFV 30.105 Support for RMF III ASIG3 segments '13'x and '14'x.
ASMRMFV 30.161 RMF III protection/messages for VSAM read I/O error.
ASMRMFV 30.202 RMF III Enhancements and Fixes.
ASMTAPEE 30.193 MXGTMNT Tape Mount Monitor no longer PINs UCBs.
ASUM70PR 30.106 zIIP SHARE WEIGHTS calculated for each LPAR.
ASUM70PR 30.266 LPARIFLS variable counts IFL engines in each LPAR.
ASUM70PR 30.266 Variable LFARIFLS added to ASUM70PR datasets.
ASUMDBSS 30.282 Revised comments and examples.
ASUMTAPE 30.203 Support for JES3 Main Device Scheduler IAT5210/5918.
ASUMUOW 30.166 Optional add PROGRAM and PROG1-PROGnn to PDB.ASUMUOW.
BLDFORMT 30.191 JCL Example using CONFIMXG to create FORMAT library.
BLDSMPDB 30.005 Using MXGINCL parameter was ignored.
BLDSMPDB 30.081 Enhancement adds rundays=mon tue ... to list days.
BLDSMPDB 30.255 WEEKKEEP, WEEKDROP now work as documented.
BUIL3005 30.011 MXG 29.29 BUILDPD3 for JES3 CRITICAL ERROR, REQUIRED.
BUILDPDB 30.042 SMF AUDIT REPORT
BUILDPDB 30.260 PDB.JOBS variable ABENDS included some RETURNs.
DAILYDSN 30.068 DAILYDSN now uses EDGRXEXT instead of EDGRDEXT.
EXITCICS 30.130 DB2 V10 compressed record SUPPORT - "enhanced"-works!
FORMATS 30.024 New format MG073FE decodes SMF73GEN and R79CGEN FICON
GRAFDB2B 30.240 Graphic/tabular DB2 Buffer Size reports, ODS or GRAPH
JCLSPLIT 30.287 Examples DECOMPRESS CICS/DB2 on z/OS for ASCII MXG.
MXGNAMES 30.275 MXGNAMES/CONFIMXG supports a USER FORMAT library.
Many 30.012 RUN STATEMENT HAS NO EFFECT message is removed.
Many 30.225 New MXGEXIMSG macro variable for diagnostics.
READDB2 30.031 Requesting IFCIDS=ACCOUNT with IFCIDS from SMF 102.
READDB2 30.077 Cleanup of WANTONLY, IFCID=STATS, 106, etc.
READDB2 30.144 PDBOUT with specific IFCIDS did not copy T102Sxxx.
READDB2 30.257 IFCIDS=STATS fixed, use instead of IFCIDS=STATISTICS.
READDB2 30.280 MXG 30.10 IFCID=STATS could still fail.
SMFSRCH 30.269 Incorrectly tried to write to USERID.SMFOUT.DATA.
TRNDRMFI 30.115 Revisions for TRNDRMFI using VGETWKLD.
TYPE0 30.040 -Variable DOWNTM was a missing value in PDB.IPLS.
TYPE102 30.001 QW0319FL, Encryption Type, format AES/DES reversed.
TYPE102 30.037 Support for BMC APPTUNE V6R3 SMF 102 records INCOMPAT
TYPE102 30.038 Support for DB2 IFCIDs 357 and 358.
TYPE102 30.055 -Support for DB2 APAR PM37956 to SMF 102 IFCID 25.
TYPE102 30.140 Support for IFCID 269,270 Audit, decodes uniques.
TYPE102 30.169 Invalid IFCID=145 QWT02R1L=0 caused ABEND & LOOP.
TYPE102 30.175 Support for IFCID=271 DB2 AUDIT PERMISSIONS trace.
TYPE102 30.265 Support for DB2 Trace IFCIDs 361 and 362 populated.
TYPE105 30.080 Support for GDPS SMF 105 now validated with SMF data.
TYPE110 30.008 CICS/TS 4.2 INVALID STILEN STID=116, zero obs STISJS.
TYPE110 30.078 SMSxxxxx variables were 1024 times large.
TYPE110 30.170 Obs count in CICLDR reduced from 1.7M to 70,000.
TYPE110 30.213 MXG 30.07 only. CICS STID=30 WARNING message.
TYPE110 30.278 TASZIPTM and TASELGTM documented, TASELGTM corrected.
TYPE113 30.179 Formula changes from John Burg's SHARE presentation.
TYPE113 30.201 Support for HIS zEC12 new Extended Counters, calcs.
TYPE113 30.236 Spurious DEACCUMULATION RESET message not printed.
TYPE113 30.274 Correction to DWINSORM/DWDASORM for one book CEC.
TYPE115 30.064 Support for MQ QJST 7.01B Statistics Block.
TYPE117 30.063 SMF 117 IMFL subtype SM17ACCT kept in WS 7.0.0.3 SMF.
TYPE119 30.009 Support for SMF 119 ST 6 z/OS 1.13 (INCOMPAT).
TYPE119 30.099 Support for CO:Z SMF 119 Subtypes 192 and 193.
TYPE119 30.121 Additional formats to decode TYPE119 SSH fields.
TYPE119 30.188 Support for SMF 119 subtype 48 thru 52 (SMTP).
TYPE119 30.249 SMF ID-119 SUBTYPE=51 INPUT STATEMENT EXCEEDED.
TYPE120 30.155 Support WebSphere Asynchronous Section 120 Subtype 9.
TYPE120 30.155 Variable SM1209CX incorrect in TYP1209E.
TYPE120 30.244 Support for WebSphere Version 8 ID=120 Subtype 10.
TYPE1415 30.103 Support for z/OS 1.13-added RAS segment (COMPATIBLE).
TYPE21 30.014 Support for APAR OA33947 for TS1140 Tape Drive.
TYPE21 30.132 Corrections to SMF 21 calculations of compression.
TYPE30 30.045 Debugging PUT _N_= CPUUNITS= CPUTCBTM= removed.
TYPE30 30.119 Support for APAR OA39629 HICPUPCT/HICPUPGM TYPE30.
TYPE60 30.082 INPUT EXCEEDED for ID=60 with no VVR segment.
TYPE70 30.208 Support for APAR OA37803 Warning Track Interrupt.
TYPE7072 30.069 New 1.13 CPUPDPTM/R723RTDM/RTDC/RTDT now populated.
TYPE7072 30.182 Support for zNEXT EC12 processors with 101 engines.
TYPE7072 30.212 Support for eC12 CRYPTO EXPRESS4S APAR OA37016.
TYPE7072 30.264 Support for APAR OA39562 new TYPE70Y3 PKCS11 CEX4P.
TYPE70EN 30.104 Variable SMF70CIN in TYPE70EN was 'ZIP', now 'IIP'.
TYPE71 30.058 -New variables added to RMF TYPE71 dataset by z/OS 1.1
TYPE71 30.083 ERROR: DOMAIN ERROR, SAS 9.1.3 SP4 Only.
TYPE71 30.206 Support for APAR OA38660 eC12 SCM and Pgbl Large.
TYPE73 30.004 Some FICON-related variables were wrong values.
TYPE73 30.054 -ERROR: Divide by zero in SMF 73 records, new FICON
TYPE74 30.072 Support for RMF 74 APAR OA36831 (COMPAT) SMF74NSS.
TYPE74 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE74 30.209 Support for APAR OA37826 Channel Path Types CIB, CFP.
TYPE79 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE80A 30.111 Debugging PUT 'DEBUG 1' is now disabled.
TYPE80A 30.268 RACF317 detect BPX.DEFAULT.USER, invalid in z/OS 2.1.
TYPE85 30.050 Support for SMF 85 records from z/OS 1.13 (INCOMPAT)
TYPE99 30.259 Support for SMF 99 Subtype 12 and 14 HiperDispatch.
TYPEBBMQ 30.047 Support for BMC Mainview for MQ Version 5.1 INCOMPAT
TYPEBETA 30.237 Support for BETA93/97 Version 4.3.0 (INCOMPATIBLE).
TYPEBETA 30.285 Support for BETA93 subtype 51.
TYPEBVIR 30.057 Support for TS7700 Version 2.0a (INCOMPATIBLE).
TYPECIMS 30.245 Support for BMC Mainview IMS 4.6 a/k/a IMF, CIMS.
TYPECMA 30.070 Support for CA-Spool Subtype 12 (partial).
TYPEDB2 30.032 DB2 variable QWHDRQNM can now contain an ipv6 address
TYPEDB2 30.089 Support for DB2 V10 APAR PM24723 adds data IFCID=225.
TYPEDB2 30.113 Support for DB2 V10 restructured QIST statistics.
TYPEDB2 30.128 DB2 v10 QPACFLGS bit map revisions.
TYPEDB2 30.133 Support for (optional) DB2 Netezza Accelerator data.
TYPEDB2 30.138 ASG TMON/DB2 PTF TE03737 corrects INVALID DB2 RECORD.
TYPEDB2 30.145 Variables CORRNAME/CORRNUM incorrect for QWHCATYP=4.
TYPEDB2 30.173 Spurious INVALID QMDA SEGMENT message eliminated.
TYPEDB2 30.194 QMDAACCT field LENACCT=246 caused INVALID 3rd SUBSTR.
TYPEDB2 30.210 DB2 V10 APAR PN29124 detects IBM BIF INCOMPATIBLE.
TYPEDB2 30.211 QISTCOLS now deaccumulated again.
TYPEDB2 30.222 IFCID=239 DB2ACCTP sets DB2PARTY, QPACROLL, QPACRUSM.
TYPEDB2 30.246 DB2STATS QWOSxxxx wrong if ZOSMETRICS=YES not set.
TYPEDCOL 30.098 DCOLLECT BKUP fields added by z/OS 1.11 supported.
TYPEDCOL 30.204 Support for APAR OA38980 ZFS dataset flag, FREEs.
TYPEEJES 30.238 Support for Phoenix Software (E)JES SMF record.
TYPEEZSM 30.041 Support for EMC EzSM z/OS Storage Manager SMF record.
TYPEFERT 30.066 Support for new subtype 1 and 4 FERRET SMF records.
TYPEHSM 30.006 Support for HSM SMF z/OS 1.12 changes (COMPATIBLE)
TYPEIDMS 30.270 Corrections for IDMS PERFMON Version 17 and 18.
TYPEM204 30.002 MODEL 204 records could be output to wrong dataset.
TYPEMVCI 30.109 Support for Mainview CICS v64 CICS/TS 4.2 (COMPAT).
TYPEMVCI 30.276 Support for Mainview CICS 6.5 for TS 5.1 COMPATIBLE.
TYPENDM 30.039 NDM-CDI record 'XO' caused "UNKNOWN SUBTYPE" message.
TYPENDM 30.220 Support for NDM-CD Subtype CX creates NDMCX dataset.
TYPENMON 30.137 Updates to NMON/TOPAS Monitor for AIX and LINUX.
TYPENMON 30.226 Support for MEMAMS Memory Object, French text.
TYPENTSM 30.044 -Updates to D062, D063, D060, VWRP, D059, D057, VWVS.
TYPENTSM 30.156 Terminal Service object fields reversed, 2003vs2008R.
TYPENTSM 30.159 Support MicroSoft Exchange 2010 incompat changes.
TYPEPMX 30.112 Variables TPMAJCT/TPMSCT too large by 100.
TYPERACF 30.120 Support for RACF database Record 02G1.
TYPERACF 30.162 RACF AUDITFID is RACF264 (TYPE80A) or AUDITID (RACF)
TYPERMFV 30.043 Updates for RMF III RCD records.
TYPERMFV 30.151 Additional Enhancements for RMF III processing.
TYPERMFV 30.172 RMF III Enhancements.
TYPERMFV 30.217 Reading RMF III data on ASCII - INVALID date message.
TYPERSDA 30.035 RSD/FOLDERS name fields were increased to $250.
TYPESAMS 30.073 Support for CA Vantage Stor Resc MGR 12.6.00 INCOMAT.
TYPESASU 30.114 SAS User Records with SASPROC='SQL (63)' protected.
TYPESVIE 30.051 Support for SYSVIEW PTF Test APAR TSD0145, for IMS.
TYPETAPR 30.164 Support for six Tandem Prognosis data files.
TYPETAPR 30.284 Support for additional PHYSVOL/VOLUME file fields.
TYPETMD2 30.060 Support for TMON/DB2 V5, INCOMPATIBLE, for DB2 V10/
TYPETMD2 30.107 Support for ASG/Landmark TMON DB2 PTFs TE03699/03718.
TYPETMMQ 30.025 Support for TMON for MQ Version 2.2/2.3/2.4 INCOMPAT
TYPETMO2 30.277 Support for TMON CICS 3.4 for CICS/TS 5.1 INCOMPAT.
TYPETMS5 30.205 Variable ACTVOL added to TMS.TMS dataset.
TYPETPMX 30.075 READTIME kept in all, JOB/JESNR/JBL24 in TPMJBL24
TYPETPMX 30.216 MVS Solutions Thruput Manager SMF subtype 5 updates.
TYPEVMXA 30.190 z/VM 6.1 BROKEN CONTROL RECORD if STSI is 152 bytes.
TYPEVMXA 30.192 z/VM Linux Processor VXAPLSL0 dataset wrong values.
TYPEVMXA 30.215 z/VM BROKE CONTROL record when MONWRITE concatenated.
TYPEVMXA 30.254 Support for zVM new CRYPTO TYPE PRCAPMCT=10.
TYPEVMXA 30.254 Support for zVM new HIS (SMF113) counters, zEC12.
TYPEWPMO 30.110 Windows PERFMON data now supports any delimiter.
TYPEWWW 30.163 Windows IIS Server Log, strange URIQUERY, looped.
TYPEXAM 30.003 Spurious XAM INVALID CPU RECORD messages.
TYPEZPRO 30.116 Support for Voltage SecureData for z/OS z/Protect.
TYPEZVPS 30.154 Support XAM/ZVPS VCPU Virtual CPU segment XMUSVCPU
VMXGCOPY 30.243 VMXGCOPY copies SAS datasets from multiple LIBNAMEs.
UTILCPLG 30.026 %UTILCPLG will copy your .LOG and .LST files.
UTILEXCL 30.092 WMQGETTM, others, incorrectly multiplied by 16.
UTILEXCL 30.100 DO NOT USE UTILEXCL in MXG 30.03, "NON-FIRST" error.
UTILEXCL 30.157 REPORT THREE-A IMACICEZ, IMACICE1, and IMACICE2.
UTILEXCL 30.278 MXGNOTE on log identifies create date of IMACEXCL.
UTILEXCL 30.283 Better support for UNKNOWN FIELDS to prevent 180.
VFMT102 30.183 30.05/30.06 VFMT102 could have overlapped range.
VFMT102 30.241 Revised mapping of DBID and OBID objects to names.
VFMT102 30.279 VFMT102 mapping DBID/OBID/PSID safer algorithm.
VGETALOC 30.135 Dynamic allocation of AUTOALOC=YES LIBNAMEs.
VGETOBS 30.177 SAS 9.2 z/OS ONLY VGETOBS didn't recognize tape dset.
VMACSMF 30.023 A third-party product creates invalid DB2 ID=101.
VMXG2DTE 30.242 New CRITERIA= parameter inserts selection SAS code.
VMXGALOC 30.131 New READONLY and CLEARLL parameters.
VMXGALOC 30.273 SERIOUS ERROR if MONTH is used with VMXGALOC/UTILBLDP
VMXGFIND 30.214 VMXGFIND to print all datasets had wrong title.
VMXGGETM 30.034 VMXGGETM only supported 512 subtypes.
VMXGINIT 30.148 FIXORDER dataset only created for dynamic allocate.
VMXGINIT 30.171 Macro variables &PCICMNR and &WCICMNR reinstated.
VMXGSUM 30.189 Use of %CMPRES replaced by %SYSFUNC which is in base.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 30.
====== Changes thru 30.292 were in MXG 30.30 dated Jan 21, 2013=========
Change 30.292 -JCL Proc Examples and Config members were added/aligned.
CONFIGN9 JCL Proc Examples MXGSAS92 and MXGSAS93 invoke CONFIGV9,
CONFIG9N which has set option NLSCOMPATMODE for many years, but
CONFIGV9 now, SAS prints a warning when that option is enabled:
Jan 19, 2013 WARNING: SAS HAS BEEN STARTED IN NLS COMPATIBILITY MODE
Feb 18, 2013 NLSCOMPATMODE OPTION MAY BE DEPRECATED. ETC.
CONTACT YOUR SAS ADMMINISTRATOR. ETC.
-Instead of MXGSASxx JCL PROC, using MXGNAMES/CONFIMXG in
Change 27.356 has been the MXG JCL recommendation since
that change, as it executes the site's SAS JCL procedure
and uses the site's default options, and it does not
print that warning message. But MXGNAMES/CONFIG text
must be used around // EXEC SAS in every MXG Job's JCL.
-So you may still have to EDIT the MXGSAS92/MXGSAS93 JCL
Proclib members to use the desired CONFIGxx member:
CONFIGV9 which sets NLSCOMPATMODE, unchanged.
CONFIGN9 which doesn't set that option, new in 30.30.
CONFIG9N which sets NONLSCOMPATMODE, new in 31.01.
-So why set NONLSCOMPATMODE? Because SAS V9.2 ABENDED
underscoring CALL SYMPUT$ text that is CALL SYMPUT( in
code (deep inside VMXGSUM deep inside VMXGRMFI) and SAS
Technical Support identified the error as documented in
SAS Note 37974 (for SAS V9.2 only) which documents:
"NLSCOMPATMODE causes some CALL routines to generate
errors on MVS in some non-English environments. To
reproduce the error invoke SAS using the command below
and submit the statements that follow it.
===> THE EXAMPLE IS A CALL SYMPUT <===
Currently the only fix for this is to issue the option
NONLSCOMPATMODE"
So the new CONFIG9N member exists to set that option if
you encounter this error. The failure occurred at a site
which had specified default values of:
NLSCOMPATMODE
LOCALE=EN_GB
and all NLS issues to date impacted only sites outside
the US that do not have LOCALE=EN_US.
Change 30.291 VPS Subsystem SMF ID=6 NOTE: INVALID ARGUMENT INPUT FUNCT
VMAC6 because SMF6RST/SMF6RSD contain 'C540404000000000'x which
Jan 18, 2013 isn't a valid SMFSTAMP8 value (time and julian date).
The error message and the hex dump of the SMF record is
now prevented by adding the double question mark to the
informat side of the INPUT function in VMAC6. The value
in variable READTIME in TYPE6 and PDB.PRINT datasets will
be a missing value until a fix is available from VPS.
This text will be update when that happens. Discovered
late on Friday, too late for VPS response for MXG 30.30.
Thanks to William M. Orrach, LMCo, USA.
Change 30.290A Variable LSPRWKLD='LSPR*WORKLOAD*MATCH' created and kept
ASUM113 in ASUM113 dataset.
Jan 16, 2013
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 30.290 Corrections after ITRM review for MXG 30.30:
VMAC90 -VMAC90 variable DOWNTM and IPLTIME labeled and formatted.
VMAC119 -VMAC119 TYP11997 variable SSH_FCRIPV6 kept in place of
VMACVMXA incorrectly spelled/kept SSH_FSRIPV6.
VMACBETA -VMACVMXA STOLMODE is labeled.
ASUMTAPE -VMACBETA Dataset Labels clarified for BETA7, BETA8 and
ASUM113 BETA22. Variable BETARTIME is now the datetime value with
Jan 16, 2013 BETARDATE no longer kept in BETA51 dataset.
-ASUMTAPE Temporary dataset JES3MNTS is now deleted.
-VMAC99 Variable S99CCCCECUTIL label, asterisk removed.
-ASUM113 Variables SMF70CIN/CIX/CPA/HDM/ONT/PAT/CECSER
CPUTYPE LPARWLMG are labeld, PAT and ONT formatted.
Thanks to Chris Weston, SAS ITRM, USA.
Change 30.289 -RMF III Performance Enhancements, blocking, and Fixes
ASMRMFV -INCOMPATIBLE. ASMRMFV & VMACRMFV should always be used
EXZRBUWX from the same MXG Version. Using a new VMACRMFV to read
IMACRMFV data created by an old ASMRMFV may not work. Specifically
JCLCRMFV with this change, to populate the new variables in the
JCLRMFV UWD files, you must use ASMRMFV and VMACRMFV with 30.289.
VMACRMFV See MXG SOURCLIB member JCLASM3 for the example JCL to
VMXGINIT assemble and link-edit the ASMRMFV program. Skipping this
Jan 20, 2013 action will result in many missing UWD file variables and
is not recommended.
-The SHD (Sample Header), RED (Resource Data), and UWD
(USE/WAIT) RMF III tables are now blocked in the RMFBSAM
output file by ASMRMFV for improved I/O performance.
-UWD records are now extended with related data based on
type to make them useful. In the past these records had
no identification of the address space, device, nor the
enqueue that related to the USE/WAIT counts. The table
name now displays as UWDX in ASMRMFV output.
-VMACRMFV has been changed to support these new blocked
tables and the new UWD extended data.
-NOTE: VMACRMFV will no longer accept old unblocked UWD
records. If found, these are deleted and an MXGERROR
message issued once. Processing continues. The old
records had no information to show which address space
the USE/WAIT record was for and so had no practical
value.
-There is a new ZRBUWXCF dataset for UWD type X'0A' XCF
Message entries that includes new variables:
UWDXCDEV='DEV NUM*OF PATH*W MSG PENDING'
UWDXCMAS='ASID OF*MEMBER*SENDING*MSG'
UWDXCHAS='ASID THAT*INITIATED*MSG OUT'
-Validation of UWD entry flags and entry types is
improved. The UWD entry will be skipped for invalid data
and no Abend will occur.
-All ZRBUW* files include the following new variables:
UWDDELAY='DELAY*SAMPLES'
UWDREDID='PARENT*RED ID'
UWDSSN ='UWD*SAMPLE*SEQUENCE*NUMBER'
UWDUSING='USING*SAMPLES'
UWDUWDLE='UWD*BASE*LENGTH'
UWDUWDLX='UWD*EXTENDED*LENGTH'
UWDVERG3='UWD*VERSION*NUMBER'
-All ZRBUW* files now have the following address space
variables from the related ASI table entry added:
ASIENIDX ASIJOBNA ASIASINR ASIFLAG1 ASIJCLAS ASIJOBS
ASIJESID ASIMSTS TYPETASK
-ZRBUWDEV, ZRBUWSTO, and ZRBUWMNT files now have the
following variables from the related DVT table entry
added:
DVTVOLI DVTENIDX DVTDEVNR DVTFLAG1 DVTFLAG2 DVTMEXN
DVTTYP DVTIDEN DVTCUID DVTLCUNR DVTFLAG3 DVTHPCO
DEVTYPE DEVPLPA DEVCOMM DEVLOCL DEVSWAP DVTHPAV
-The ZRBUWENQ file now has the following variables from
the related ENT table entry added:
ENTENIDX ENTMAJNA ENTMINNA ENTSCOPE ENTFLAGS
-The ZRBASI file has two new variables for Memory Object
analysis:
ASITMO ='TOTAL*MEMORY*OBJECTS'
ASITMOBY='TOTAL*MEMORY*OBJECT*BYTES'
-The ZRBASM file has four new variables added in support
of UWD extensions:
ASMUWDHL='UWD*HEADER*LENGTH'
ASMUWDAL='UWD ASI*EXTENSION*LENGTH'
ASMUWDDL='UWD DEV*EXTENSION*LENGTH'
ASMUWDEL='UWD ENQ*EXTENSION*LENGTH'
-The RMFBASM file version is raised to X'02' from X'01';
-A new final message RMFV999I is now issued at the end of
ASMRMFV processsing. The message shows the total number
of WARNINGS, ERRORS, SEVERES (severe errors), and the
final Return Code. In the case of an abend the Abend
Code and Reason Code are also shown. The message appears
in both SYSPRINT and in the JES JOB log. This provides
one message to check to get the final status of ASMRMFV.
-A BYTES WRITTEN column is added to all ASMRMFV RMFV105I
messages for each combination of DATA ACTION and RMF III
table. The column is displayed regardless of the
BYTES/NOBYTES parameter setting. This shows what tables
are contributing most to the RMFBSAM output file size.
The byte count doesn't include the 4 bytes for each BDW
(block descriptor word).
-Support for the RMF III ARCHAIC PGP table is suppressed,
but could be enabled if needed. The PGP does NOT appear
in ASMRMFV detail and summary reports when disabled. The
PGP is only generated and available in z/OS Compatibility
Mode. IBM support for Compatibility Mode ended in March
2002 with the release of z/OS 1.3 as Goal Mode became
required. But it was safer to just suppress than to
remove code that will never be executed.
-ASMRMFV no longer abends when an invalid RED entry is
found. Instead the record is skipped.
-ASMRMFV message RMFV014I is now always issued regardless
of the DETAIL/NODETAIL setting.
-New ASMRMFV message RMFV035E is now issued when errors
are detected processing the SPG, RED, UWD, DSH, or SSH
tables. These are intended to attract the attention of
the support person who might otherwise overlook the less
obvious record SKIP counts.
-NOTE: Message RMFV035E can occur when the ERBRMFxx
PARMLIB member for RMF Monitor specifies a non-existent
Storage Group in the SGSPACE ADD parameter. RMF Monitor
III message ERB329I indicates this condition: ERB329I
III: ONE OR MORE STORAGE GROUP NAMES ARE NOT DEFINED IN
SMS. In this case the entire SPG table is skipped as the
integrity of the entries cannot be trusted as confirmed
by RMF Support. Correct the ERBRMFxx start up member for
RMF III as soon as possible and modify or restart RMF III
to restore SPG table processing. Corrupted SPG tables
cannot be processed by TYPERMFV.
-ASMRMFV message RMFV033E is now RMFV033S to indicate a
severe error when an I/O error occurs.
-The handling of unsigned halfword binary integers in RMF
III table fields by ASMRMFV is corrected when the high
order bit is on.
-Prologue documentation in the ASMRMFV source has been
updated to provide detail on BYTES WRITTEN column and the
skipping of UWD records.
-Member JCLRMFV in MXG SOURCLIB now shows examples of
building an RMF Monitor III PDB by the Direct JCL method.
-Member JCLCRMFV in MXG SOURCLIB now shows examples of
building an RMF Monitor III PDB by the Batch TSO CLIST
method.
Thanks to Steve Dyck, The Canadian Depository for Securities, Canada
Thanks to Neil Ervin, Wells Fargo, USA
Change 30.288 Velocity Software zVPS (a/k/a XAM) records are Variable
UXAMNRDW Length CMS files but when first copied to their ftp site
Jan 15, 2013 so I could ftp to ASCII to test new data, the two-byte
CMS record length field had been stripped, so I wrote
this heuristic that uses the structure of the first 16
bytes of each XAM logical record to create a readable
"z/OS" VB file. However, here is the correct way to
create a "RECFMU" file from a CMS variable file. This
note has been added to the MXG member FTPING:
23. Syntax to copy the XAM z/VM CMS Variable File to
RECFMU on z/VM:
z/VM exec to pipe the XAM CMS Variable data file (which
contains a two-byte record length) thru the BLOCK command
to create a file with the two four-byte z/OS BDW and RDW
fields; that output file can then be downloaded by ftp as
BINARY to an ASCII system where the file can be read with
SAS INFILE with RECFM=S370VBS and LRECL=32760. The
output filetype "RECFMU" is used as this data is the same
date with preserved BDW/RDW on z/OS created with
DCB=RECFM=U.
parse arg fn ft fm
'ACC FTPPOOL:MXG.XAMDATA x (FORCERW'
'pipe < 'fn ft fm,
' | block 32760 V',
' | >' fn 'RECFMU X'
1) The Parse arg fn ft fm is actual code.
It assumes you would start executing the EXEC with:
inputfilename inputfiletype inputfilemode
Parse arg pulls in the filename/type/mode that you
specified when you started the EXEC.
2) Looking at FTPPOOL:MXG.XAMDATA,
FTPPOOL is the SFS filepool name.
MXG is the filespace name (USERID)
XAMDATA is the subdirectory under the FTPPOOL root
Maybe a good PC analogy would be
filepool name = drive letter (such as C:);
USERID = a directory under C:(such as MXG)
subdirectory something under MXG (C:\MXG\XAMDATA)
Thanks to Dewayne Thomas, Velocity Software, USA.
Change 30.287 Executing MXG on ASCII to read compressed CICS/DB2 SMF is
JCLSPLIT generally much faster if you FIRST decompress SMF records
JCLSPLT1 on z/OS (using IBM ASM PGM=DFH$MOLS, PGM=DSNTSMFD, or SAS
JCLSPLT2 and EXITCICS - all call IBM's CSRCESRV ASM service to do
DFH$MOLS the decompression) and then SECOND, you run MXG on ASCII
DSNTSMFD to read that uncompressed SMF file. The simpler process
Jan 19, 2013 of running MXG on ASCII to directly both read compressed
SMF data AND to uncompress it is MUCH slower because the
CSRCESRV doesn't exist on ASCII and the ASCII alternative
byte-by-byte SAS code decompress algorithm is functional
but it is VERY CPU intensive (by a factor of MANY times).
Newsletter SIXTY-ONE had execution comparison results.
Only if you have network contention when MXG reads the
uncompressed data might your results be different; you
should at least test this alternative.
These members provide examples of how to parallelize
the MXG "BUILDPDB" process and first decompress on z/OS.
JCLSPLIT - changes are primarily comments but the split
of IO and MQ data is commented out as well as
the SYSIN for those datasets
JCLSPLT1 - the same as JCLSPLIT but also contains steps
for DFH$MOLS and DSNTSMFD
JCLSPLT2 - the same as JCLSPLT1 but uses temp dataset
names for the outputs, runs DFH$MOLS, DSNTSMFD
and then combines all the temp datasets with
IFASMFDP to be fed to MXG
DFH$MOLS - JCL to run DFH$MOLS
DSNTSMFD - JCL to run DSNTSMFD
Change 30.286 A new program that graphically compares values over time.
ANALCOMP Any number of variables from any number of SAS datasets
Jan 14, 2013 are aligned for starting days, weeks, months, or years,
with ODS Graphic's PROC SGPLOT (included in Base V9.3).
V9.2 SGPLOT does require SAS/GRAPH. One of many examples:
Compare hourly CPU time for each Service and Reporting
Class, for two weeks in November, from MONTH.TYPE72GO:
%ANALCOMP(INDATA=MONTH.TYPE72GO,
VARS=CPUTM,
COMPINTV=WEEK,
COMPARE=11NOV12 18NOV12,
SUMMARY=YES,
XAXIS=HOUR,
DATETIME=STARTIME,
SORTBY=SYSTEM RPRTCLAS SRVCLASS);
Change 30.285 Support for BETA93 subtype 51 which had been overlooked.
EXTYBETJ This record has 10 possible field formats, so there are
IMACBETA ten variables BETAFIELDC/H/I/V/D/T/S/B/F/P created for
VMACBETA Character/Hex/Integer/Variable/Date/Time/Small/Byte/Flag/
VMACBETA Pool which are populated based on BETAFTYPE value. But,
Jan 14, 2013 the Character type has both EBCDIC and HEX values so it
must be displayed as a hex string, since the vendor does
not identify which Field Names are text versus hex.
Change 30.284 Support for additional fields in PHYSVOL and VOLUME file.
VMACTAPR Now, PHYSVOL has 67 variables and VOLUME has 71.
Jan 11, 2013
Thanks to Xiaobo Zhang, Fiserv, USA.
Change 30.283 When UTILEXCL found an UNKNOWN FIELD, the circumvention
UTILEXCL to skip over that field could generate 180 syntax errors,
Jan 11, 2013 depending on the syntax generated for the prior and/or
the subsequent field. This update revises the logic to
provide a more reliable circumvention. UNKNOWN FIELD
message can occur when a back-level of UTILEXCL is used
to process a new CICS version's dictionary, or when there
are "user" fields created by the site with names other
than "USER". Sending the UTILEXCL log executed with
_BLDDICT; _BLDEXCL; _RPTEXCL ; to support@mxg.com
is the correct "circumvention", as that allows MXG to
add support for a user field or detect back-level.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.282 Comments updated to document all parameters. The default
ASUMDBSS SUMBY list includes SHIFT, so if you change the interval
VMXGDBSS value to DATE, wanting one observation per day, you get
Jan 10, 2013 multiple observations for each SHIFT value. You need to
remove SHIFT from the SUMBY list to get daily output:
%VMXGDBSS(
D2STATIN=&PDBMXG..DB2STATS,
D2STATOT=&PDBMXG..ASUMDBSS,
D2GBPSIN=&PDBMXG..DB2GBPST,
D2GBPSOT=&PDBMXG..ASUMDBSG,
D2BPSIN =&PDBMXG..DB2STATB,
D2BPSOT =&PDBMXG..ASUMDBSB,
ASUMINTV=DATE,
SUMBY=QWHSSSID BEGTIME,
INVKBY=DAILYDBSS
);
Thanks to Stu Samuels, Blue Cross Blue Shield of Illinois, USA.
Change 30.281 -BUILD005/BUIL3005 used in ONLYJOBS (create only PDB.JOBS)
BUILD005 set a return/condition code four for a PROC COPY message
BUIL3005 "WARNING: IN= and OUT= are the same" that is eliminated
ONLYJOBS by this change that creates an internal %SPINCOPY macro
ONLYJOBZ that conditionally issues the PROC COPY only when they
Jan 19, 2013 are different (as they are in all other uses of BUILD005)
For ONLYJOBS, they are correctly the same and the COPY
is not needed nor wanted.
-The original ONLYJOBS is now stored as ONLYJOBZ as a fine
example of how to tailor BUILDPDB using the old-style
macros, because the new ONLYJOBS now uses the newer and
more powerful %UTILBLDP macro (but still needing some of
those old-style macros) to create ONLY the datasets that
are actually needed by BUILD005.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 30.280 -MXG 30.10 iteration, IFCIDS=STATS still failed even after
READDB2 Change 30.257, generating DB2STAT4 NOT SORTED ERROR, due
Jan 9, 2013 to my insufficient testing with only OBS=0. You can use
IFCIDS=STATISTICS with 30.10 to circumvent this error.
-And the intended change to NOT create T102S106 unless it
was requested went too far, since it was NOT created when
106 was in the list of requested IFCIDS. (30.01 can be
circumvented by adding T102106=YES as an argument).
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 30.279 The VFMT102 mapping of DBID/OBID/PSID value to the DB2
VFMT102 name has been reset to the safer algorithm that uses
Jan 8, 2013 PROC SORT to remove duplicate values; recent attempts to
construct the format and/or to use a MERGE have never
completely removed the overlap in values; that code is
kept in ZFMT102 from the last try until time and more
guidance from IBM DB2 support is available.
Change 30.278 -The MXG-created TASZIPTM/TASELGTM variables in CICSTRAN,
VMAC110 CICS/TS 5.1, were only populated when UTILEXCL was used
UTILEXCL to create an IMACEXCL, but are now populated in default
VMXGUOW 5.1 VMAC110 code, from IBM CPUTONCP/OFFLCPUT fields also
Jan 7, 2013 used to create CPUTONTM/CPUTONCN/OFFLCPUTM/OFFLCPCN in
Jan 13, 2013 Change 30.228 (CICS/TS 5.1 and APAR OA38409 is required).
Labels are corrected to provide clearer documentation:
CPUTONTM='TASK TOTAL*CPU TCB TIME*ON CP ONLY'
CPUTONCN='TASK TOTAL*DISPATCHES*ON CP ONLY'
TASCPUTM='TASK TOTAL*CPU TCB TIME*ON BOTH*CP+ZIIP'
(This is NOT NEW - has always been the sum of
CP and (normalized) zIIP CPU time).
TASDSPCN='TASK TOTAL*DISPATCHES*ON BOTH*CP+ZIIP'
TASZIPTM='TASK*ZIIP ONLY*CPU TCB*TIME'
TASELGTM='TASK*ZIIP-ELIGIBLE*RAN ON CP*CPU TCB TIME'
OFFLCPTM='TASK*ZIIP-ELIGIBLE*RAN ON CP*CPU TCB TIME'
OFFLCPCN='TASK*ZIP-ELIGIBLE*RAN ON CP*DISPATCHES'
-The calculation of TASZIPTM and TASELGTM were not shown,
and TASELGTM WAS WRONGLY CALCULATED prior to this change;
TASELGTM is equal to OFFLCPTM, but having created it, I'm
now compelled to keep the two identical variables:
TASELGTM=OFFLCPTM;
TASZIPTM=TASCPUTM-CPUTONTM;
-UTILEXCL now creates a new MXGNOTE in the IMACEXCL that
identifies the creation date of that IMACEXCL on the SAS
log when it is included, to confirm there is a tailored
IMACEXCL in use.
-ASUMUOW now keeps TASZIPTM TASELGTM and CPUTONTM.
Change 30.277 Support for TMON for CICS Release 3.4 for CICS/TS 5.1
EXMONTV INCOMPATIBLY adds variables to existing datasets and
IMACTMO2 creates one new dataset:
VMACTMO2 DDDDDD DATASET DESCRIPTION
VMXGINIT MONTV MONITV JVM SERVER STATISTICS
Jan 6, 2013 -Dataset MONITASK new variables:
TAU64HWM='USER 64 POOL HWM'
TAC64HWM='CICS 64 POOL HWM'
TASTCPUT='STANDARD*CP*CPU*TIME'
TASTCPUC='STANDARD*CP*COUNT'
TASTCPOT='OFFLOAD*ON*STD*CPU'
TASTCPOC='OFFLOAD*ON*STD*COUNT'
-Dataset MONISYST new variables:
TIENCCTM TIHU64ID TIU64HWM TIHC64ID TIC64HWM TISTCPUT
TISTCPUC TISTCPOT TISTCPOC
-Dataset MONIPA new variables:
PAACAPPL PAACMAJV PAACMICV PAACMINV PAACOPER PAACPLAT
PACECMCH PACECMDL PACLIPPO PACURTAS PAISIPNM PAMAXTAS
PAOADAT1 PAOADAT2 PAOADAT3 PAOADID PAOAPPL PAOASTRT
PAOCLIPA PAOCLIPP PAOFCTNM PAONETWK PAOPORTN PAOTCPSV
PAOTRAN PAOTRNUM PAOUSER PAOUSRCO PAPHAPPL PAPHCNT
PAPHNTWK PAPHSTRT PAPHTRAN PAPHTRNO PASOCIPH PAWBATNM
PAWBPINM PAWBPRON PAWBSVCN PAWBSVON PAWBURNM PASC64CC
PASC64CH PASC64FS PASC64GS PASC64SC PASC64UC PASC64UH
PADHDLC PAWMQREC PACPUTOC PACPUTOT PAOFFLCC PAOFFLCT
PAMQGETC PAMQGETT PAMQGETC PAMQGETT PACLIPAD PAFCVSWC
PAFCVSWT PAFCXCWC PAFCXCWT PAISALWC PAISALWT PAISIOWC
PAISIOWT PAJVMTHC PAJVMTHT PAMQSRBC PAMQSRBT PAMXDLYC
PAMXDLYT PAROMODC PAROMODT PASOMODC PASOMODT PAT8CPUC
PAT8CPUT PATCALWC PATCALWT PATDELWC PATDELWT PATDILWC
PATDILWT PABFDGSC PABFTOTC PAECEFOC PAECEVNC PAECSEVC
PAECSIGC PAEICTOC PAISALOC PAMLXMLC PAMLXSSL PAPGCSTH
PATIASKC PATITOTC PAWBISSC PAWBSFCC PAWBSFTC PAWBSREL
PAWBSRSL PAWSACBC PAWSACGC PAWSAEPC PAWSATOC
-Dataset MONIPI new variables:
PIPCDLL PIPCDRL PIPCLCC PIPCXCC PIPCDCC PIPCRCC
PIPCRCL PIICSCC PIICSCD PIICSRC PIICSRD PIWBROC
PIWBWOC PIWBIRC PIWBI1C PIWBOSC PIWBO1C PIWBPRC
PIWBBOC PIWBIWC PIWBRDL PIWBWDL PIPGCTC PIPGBCC
PIPGGCC PIPGPCC PIPGMCC PIPGGCL PIPGPCL PIPGCCC
PIISALOC PIEICTOC PIECSIGC PIECEFOC PIECEVNC PIECSEVC
PITIASKC PITITOTC PIBFDGSC PIBFTOTC PIMLXMLC PIWSACBC
PIWSACGC PIWSAEPC PIWSATOC PIWBSFCC PIWBSFTC PIWBISSC
PIPRTXCD PIL9CPUC PIL9CPUT PIX8CPUT PIX8CPUC PIX9CPUT
PIX9CPUC PIT8CPUC PIT8CPUT PIXTDLYT PIXTDLYC PISTDLYT
PISTDLYC PIMXDLYC PIMXDLYT PICMDLYC PICMDLYT PIFCXCWC
PIFCXCWT PIFCVSWC PIFCVSWT PIISIOWC PIISIOWT PIJVMTHC
PIJVMTHT PIMQSRBC PIMQSRBT PITDILWC PITDILWT PITDELWC
PITDELWT PIROMODC PIROMODT PISOMODC PISOMODT PIMQGETC
PIMQGETT PIISALWC PIISALWT PITCALWC PITCALWT PICPUTOC
PICPUTOT PIOFFLCC PIOFFLCT PIPHCNT PISC64CC PISC64FS
PISC64GS PISC64SC PISC64UC PIWMQREC
-The SMF format SMF 110 "CICSTRAN" records that can be
created by TMON don't contain the eight DFHRMI S001-S008
fields, previously optional, now created by default in
the IBM CICS/TS 5.1 SMF 110 records and thus expected in
the default MXG VMAC110 code for 5.1, so you will need to
use the UTILEXCL program to create a tailored IMACEXCL to
process these SMF records from TMON Version 3.4.
Change 30.276 Support for Mainview for CICS Release 6.5 for CICS/TS 5.1
EXMVCITD COMPATIBLY adds variables to CMRDETL and creates these
EXMVCITS two new datasets:
IMACMVCI DDDDDD DATASET DESCRIPTION
VMACMVCI MVCITD MVCITDQU TD QUEUE
VMXGINIT MVCITS MVCITSQU TS QUEUE
Jan 6, 2013 -New variables in CMRDETL for CICS/TS 3.2 and later:
T6EXCFLC='CFDT*LOCK*WAIT*COUNT'
T6EXCFLT='CFDT*LOCK*WAIT*TIME'
T6EXCFNC='CFDT*NONLOCK*WAIT*COUNT'
T6EXCFNT='CFDT*NONLOCK*WAIT*TIME'
T6EXLBC ='LSR*BUFFER*WAIT*COUNT'
T6EXLBT ='LSR*BUFFER*WAIT*TIME'
T6EXLSC ='LSR*STRING*WAIT*COUNT'
T6EXLST ='LSR*STRING*WAIT*TIME'
T6EXSTGC='STORAGE*WAIT*COUNT'
T6EXSTGT='STORAGE*WAIT*TIME'
T6EXTBC ='TS*BUFFER*WAIT*COUNT'
T6EXTBT ='TS*BUFFER*WAIT*TIME'
T6EXTMPC='TEMP*STG*WAIT*COUNT'
T6EXTMPT='TEMP*STG*WAIT*TIME'
and new CMRDETL variables populated only in CICS/TS 5.1:
T6E68XCT='68*EXTENSIONS'
T6EAPPLN='APPLICATION*NAME'
T6ECECID='CEC*MODEL*ID'
T6ECECTP='CEC*MACHINE*TYPE'
T6ECHWMG='GCDSA*HWM'
T6ECTSKS='CURRENT*TASKS AT*TRAN*ATTACH'
T6EFCSWC='FC VSAM*STRING*WAIT*COUNT'
T6EFCSWF='FC VSAM*STRING*WAIT*FLAG'
T6EFCSWT='FC VSAM*STRING*WAIT*TIME'
T6EFCXWC='FC*EXCLUSIVE*WAIT*COUNT'
T6EFCXWF='FC*EXCLUSIVE*WAIT*FLAG'
T6EFCXWT='FC*EXCLUSIVE*WAIT*TIME'
T6EISAWC='IS*ALLOCATE*WAIT*COUNT'
T6EISAWF='IS*ALLOCATE*WAIT*FLAG'
T6EISAWT='IS*ALLOCATE*WAIT*TIME'
T6EMAJVR='APPL*MAJOR*VERSION*NUMBER'
T6EMICVR='APPL*MICRO*VERSION*NUMBER'
T6EMINVR='APPL*MINOR*VERSION*NUMBER'
T6EMPPTX='POLICY*THRESHOLDS*EXCEEDED'
T6EMTSKS='MXT*AT*TRAN*ATTACH'
T6EOFCPC='ELIGIBLE*CPU TIME*COUNT'
T6EOFCPF='ELIGIBLE*CPU TIME*FLAG'
T6EOFCPT='ELIGIBLE*CPU TIME'
T6EONCPC='STD*PROC*CPU TIME*COUNT'
T6EONCPF='STD*PROC*CPU TIME*FLAG'
T6EONCPT='STD*PROC*CPU*TIME'
T6EOPERN='OPERATION*NAME'
T6EPLATN='PLATFORM*NAME'
T6ERODLC='RO*TCB*DELAY*COUNT'
T6ERODLF='RO*TCB*DELAY*FLAG'
T6ERODLT='RO*TCB*DELAY*TIME'
T6ESC64F='TOTAL*BYTES*FREED'
T6ESC64G='TOTAL*BYTES*OBTAINED'
T6ESC64S='SHARED*STORAGE*GET MAINS'
T6ESCCGG='GCDSA*GET*MAINS'
T6ESCUGG='GUDSA*GET*MAINS'
T6ESOCPH='CIPHER*SELECTED'
T6ESODLC='SO*TCB*DELAY*COUNT'
T6ESODLF='SO*TCB*DELAY*FLAG'
T6ESODLT='SO*TCB*DELAY*TIME'
T6ETCAWC='TC*ALLOCATE*WAIT*COUNT'
T6ETCAWF='TC*ALLOCATE*WAIT*FLAG'
T6ETCAWT='TC*ALLOCATE*WAIT*TIME'
T6ETDELC='TD*EXTRA*LOCK*COUNT'
T6ETDELF='TD*EXTRA*LOCK*FLAG'
T6ETDELT='TD*EXTRA*LOCK*TIME'
T6ETDILC='TD*INTRA*LOCK*COUNT'
T6ETDILF='TD*INTRA*LOCK*FLAG'
T6ETDILT='TD*INTRA*LOCK*TIME'
T6EUHWMG='GUDSA*HWM'
-An existing INVALID DATA error for T6ECNCNT, was found in
MXG code and corrected; it did not affect anything else.
Change 30.275 MXGNAMES/CONFIMXG adds support for a USER FORMAT library.
VMXGCNFG %LET MXGFMTU=DSNAME; dynamically allocates //USRFORMAT
Jan 5, 2013 and sets OPTIONS FMTSEARCH=(USRFORMAT LIBRARY) to search
the user formats first, before the MXG format library.
If you use CONFIMXG and you have an MXGNAMES DD in a PROC
pointed pointed at a dataset AND you override the
MXGNAMES DD with //MXGNAMES DD * the following message
will be in the JOBLOG - but it is not a failure
IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED
====== Changes thru 30.274 were in MXG 30.10 dated Jan 3, 2013=========
Change 30.274 Variables DWINSORM & DWDASORM are set to zero in TYPE113
ASUM113 if this is a one book machine, if L4RP LE 0 (one book) or
VMAC113 SM1132MM='M10' (2818 - z114).
Jan 2, 2013
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.273 MXG 30.05-30.09. VMXGALOC with MONTH argument did not
VMXGALOC correctly calculate the preceding month; when run with
Jan 2, 2013 normal _TODAY, on Jan 1, 2013, the monthly data was
written to November instead of December. Using FORCEDAY
of 1JAN2013 with MONTH did copy correctly.
Thanks to Richard Krueger, Sentry Insurance, USA.
Change 30.272 MXG 30.09 only. ERROR 48-59 FORMAT EBCDIC WAS NOT FOUND,
VMAC102 flagging the input of QWHSSSID. This occurred only in a
VMACDB2 user-constructed program that %INCLUDEd VMAC102 alone, or
Jan 2, 2013 before VMACDB2 (but that SHOULD have worked correctly!).
QWHSSSID and QWHSRELN were added to a PUT in DB2DECOM
to identify the system/release, but they had not been
input until after DB2DECOM. In VMACDB2 there happened to
be a LENGTH QWHSSSID $4 statement that avoided the error
when it was %INCLUDEd first. But now, both variables are
removed from that diagnostic PUT statement.
Thanks to Paul Volpi, UHC, USA.
Change 30.271 -Most of the _S102nnn dataset sort macros didn't delete
VMAC102 the _Wdddddd dataset after _Ldddddd dataset was built;
Jan 2, 2013 the %VMXGDEL(DDDDDD=102nnn) invocation was added to each
of the _S102nnn macros. Note that most of these "sort"
macros for ID=102 DB2 Trace don't actually sort the data;
most only copy the dataset with a DATA step, because the
NODUP duplicate-removal that is normal in _Sdddddd macros
requires data and time to validate the completeness of
the BY list, but over time, all _S102nnn dataset sort
macros will be changed to use PROC SORT NODUP.
Change 30.270 IDMS PERFMON Version 18 has a second segment subtype=4
VMACIDMS record which was previously unknown and was creating an
Dec 27, 2012 additional observation in IDMSINS that had all of the
Jan 2, 2013 variable names from the first segment. Second segment
is now decoded and new variables kept in IDMSIMS dataset:
INSSYTI ='CPU*TIME'
INSCPTI ='SRB*TIME*ON CP'
INSZPTI ='SRB*TIME*ON ZIP'
INSUSTI ='USER*MODE*CPU*TIME'
INSENTI ='TOTAL*ENCLAVE*SRB*CPU*TIME'
-Short third segment (PMHRLEN=68) from IDMS Version 17 is
now protected.
Thanks to Kim Westcott, NYS Office of Technology, USA.
Change 30.269 -SMFSRCH failed, writing to USERID.SMFOUT.DATA due to an
SMFSRCH error in VMXGGETM introduced in Change 30.224 which lost
VMXGGETM lost the & ahead of &SMFOUT, and testing of that change
VMXGSRCH overrode SMFOUT= so the missing & was not detected.
Dec 27, 2012 -Then, an extraneous PUT statement in VMXGSRCH caused a
22-322 syntax error (but the program continued to run).
The PRINTIT parameter was not correctly implemented, with
both a PROC PRINT and VMXGPRAL of the data found being
printed. Now only VMXGPRAL is printed if PRINTIT=YES.
Thanks to Dan Case, Mayo Clinic, USA.
Change 30.268 RACF317='BPX*DEFAULT*USER*USED?' is added to TYPE8028
VMAC80A thru TYPE8065 to identify if the FACILITY class profile
Dec 25, 2012 BPX.DEFAULT.USER is being used; that facility will NOT
exist in z/OS 2.1 (because it allowed many users of UNIX
system services to share a UID and GID, no longer a good
idea and FACILITY class profile BPX.UNIQUE.USER or other
alternatives are REQUIRED with z/OS 2.1). RACF317 will be
Y/N if a SMF80DTP=317 segment exists, otherwise, blank.
Note that APAR OA37164 added detection in the Health and
Migration Checks, for an alternative to determine if the
profile is being used.
Thanks to Randy Shumate, Reed Elsevier Technology Services, USA.
Change 30.267 -New IFCID 361 Audit Admin Authority (new with DB2 V10)
ANALDB2R added to Audit reports with new AUDIT= parameter value
Dec 24, 2012 of ADMIN.
-A fault in the logic for the multiple possible database
and object names in the IFCID 145 records was fixed.
Change 30.266 -New variable LPARIFLS in PDB.ASUM70LP and PDB.ASUMCELP
VMXG70PR and variables LPnIFLS in PDB.ASUM70PR and PDB.ASUMCEC now
Dec 23, 2012 counts the number of IFL engines allocated to each LPAR.
Dec 28, 2012 The existing NRIFLCPU variable is the number of IFLs
in the CEC.
DEDICATED IFL, OR SHARED IFL WITH WAIT COMPLETE=YES ARE
ALWAYS 100% BUSY IN RMF TYPE 70 (TYPE70PR/ASUM70PR) DATA.
For those environmens, z/VM MONWRITE (MXG TYPEVMXA) must
be used to measure IFL utilization.
For SHARED IFL with WAITCOMPLETE=NO, RMF 70 does capture
actual utilization of IFL engines.
See Newsletter FIFTY-EIGHT "1. MONWRITE" for comparison.
The Wait Complete=YES is set when the box "Do not end
time slice if a partition enters a wait state" was
checked.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 30.265 Support for DB2 Trace IFCIDs 361 and 362 populates the
FORMATS existing T102S361 and T102362 datasets.
VMAC102
Dec 22, 2012
Change 30.264 Support for APAR OA39562 creates new TYPE70Y3 dataset for
EXTY70Y3 zEC12 processors new PKCS11 Crypto Co-Processor providing
VMAC7072 CEX4P measurements. (Input statement corrected Jan 3
VMXGINIT after IBM support finally clarified the 10 was 10'x.)
Jan 3, 2013
Change 30.263 For CICS records with multiple USER segments that are no
IMACICUS longer populated nor needed, you can cause them to be
UTILEXCL skipped (so variable USERCHAR will be blank) simply by
Dec 21, 2012 creating an IMACICUS member in your "USERID.SOURCLIB"
that has only a comment to document that you are skipping
over the USER segments. This is only documentation.
Thanks to James Olson, Dominion Resource Services, Inc, USA.
Change 30.262 TYPE1052 variable SM105LID is now converted to a one-byte
VMAC105 numeric hex value; IBM documented the two bytes as binary
Dec 19, 2012 but the actual field contains two EBCDIC characters for
a one byte hex value (e.g., 'F1C1'x for 1Ax; the original
MXG input as PIB2 created SMF105LID=61889 from 'F1C1'x.
Thanks to Jeffrey A. Johns, UHC, USA.
Change 30.261 TMON/MQ latency variables QAMINLAT/MAXLAT/TOTLAT are now
VMACTMMQ correctly input as STCK time values, and formatted with
Dec 19, 2012 TIME13.3, now that TMON support informed me they are STCK
Jan 17, 2013 units (so the values input with PIB8.6 informat are now
divided to 4096 to convert from STCK).
Thanks to Homayoun Riaza, United Health Group, USA.
Change 30.260 The count in variable ABENDS in PDB.JOBS was incorrect as
BUILD005 it could include jobs that ended with ABEND='RETURN'. It
BUIL3005 now contains the correct count of STEPS that had either
Dec 13, 2012 a 'SYSTEM' or a 'USER' ABEND code, plus a count of one is
added for jobs that had a PRE-EXECUTION error in a step
(i.e., the step initiated but either was not allocated or
was not program-loaded, ALOCTIME or LOADTIME are missing)
and for this instance, variable ABEND='PREEXEC' is set.
Thanks to Louis Deledalle, BNP Paribas, FRANCE.
Change 30.259A Formats $MG119ME and $MG119PM did not decode the
FORMATS FCMechanism value A='A:AT_TLS' and $MG119ME value of 'T'
Dec 13, 2012 is corrected to T:TLS.
Thanks to Richard Wendland, USBank, USA.
Change 30.259 Support for SMF 99 Subtype 12 and 14 HiperDispatch data.
EXTY99CC New datasets created:
EXTY99CI Subtype DDDDDD DATASET DESCRIPTION
EXTY99CP 12 TY99CI TYPE99CI HD INTERVAL
EXTY99EH 12 TY99CC TYPE99CC HD CAPACITY
EXTY99EM 12 TY99CP TYPE99CP HD PROCESSOR
EXTY99EN 14 TY99EH TYPE99EH HD HEADER
EXTY99EP 14 TY99EP TYPE99EP HD PROCESSOR
EXTY99EQ 14 TY99EN TYPE99EN HD NODES
IMAC99 14 TY99EM TYPE99EM HD MQWP
VMAC99 14 TY99EQ TYPE99EQ HD MPWQ HNODE
VMXGINIT These datasets have been tested with z/OS 1.12 data.
Dec 12, 2012 Every 10 seconds, five subtype 12 records are written
Jan 2, 2013 with the same SMFTIME but each is a 2 second duration
with S99CCITOD containing the start of each interval.
-Initially, a pair of subtype 14 records are written every
five minutes, but APAR OA39058 changes that architecture
to write only one record each interval. Until I have
test data with that APAR, the duplicate removal for
TYPE99EH/EM/EQ in their _Sdddddd macro is not validated.
-The IBM labels for S99EEPNL1/NL2 are reversed, so the MXG
labels are now corrected to match data vs documentation:
S99EEPNL1 ='TOPOLOGY*NESTING*LEVEL 1*BOOK'
S99EEPNL2 ='TOPOLOGY*NESTING*LEVEL 2*CHIP'
Thanks to Dave Cogar, Wells Fargo, USA.
Change 30.258 Duplicate obs were not removed from BVIR21 dataset by the
VMACBVIR NODUP option in the PROC SORT in macro _SBVIR21 because
Dec 11, 2012 the BY list did not include ADHBAD and ADHSLOT.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY
Change 30.257 -If you specified IFCIDS=STATS, the sorts of the datasets
READDB2 input to the DB2STATS dataset were suppressed and steps
Dec 11, 2012 failed with variables not in order. You SHOULD use the
Jan 1, 2013 IFCIDS=STATS instead of IFCID=STATISTICS because STATS
creates ONLY DB2STATS/DB2STATR/DB2STATB/DB2GBPST whereas
IFCID=STATISTICS also writes these redundant datasets
DB2STAT0/DB2STAT1/DB2STAT4/DB2ST225/DB2STATB) that are
completely contained in PDB.DB2STATS; IFCIDS=STATS is now
set as default instead of IFCID=STATISTICS.
-READDB2 now invokes the _S102nnn sort macros so that the
work copy is deleted after copy to minimize disk space.
But this creates 23 lines of log messages for each data
set instead of proc copy's two lines per data set.
See Change 30.271.
-Comments document where data is written for combinations
of PDBOUT= and ACCTSORT= and IFCIDS=.
-If you asked for IFCIDS=261, sorts on statistics caused
errors when those dataset did not exist. The test on the
macro variable was checking the length and should have
been checking the value.
Thanks to Alyona Bertneski, JPM Chase, USA.
Change 30.256 Briefly, this change created variable MSUHARD, but that
VMAC30 was removed as a bad idea.
Dec 10, 2012
Dec 16, 2012
====== Changes thru 30.256 were in MXG 30.09 dated Dec 8, 2012=========
Change 30.255 If you used WEEKKEEP or WEEKDROP parameters and the
BLDSMPDB length of the dataset name(s) specified was longer than
Dec 7, 2012 the current dataset name being checked (for example you
said TYPE64: and the current dataset was IPLS) then the
length of the first was greater than the second and an
invalid substr length message was created. Everything
still ran correctly since it created a FALSE on the
condition being tested but it did generate a bad return
code when run in the background. A check on the length is
now used in addition to comparing the values.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 30.254 -Support for new CRYPTO TYPE PRCAPMCT=10 in VXPRCAPM. The
VMACVMXA UNDECODED message was printed, but then MXG failed with
Dec 5, 2012 INVALID BLOCK messages because the undecoded detection
Dec 19, 2012 didn't properly set the SKIP value, so subsequent INPUTs
Dec 20, 2012 were misaligned. There are three sub-subtype values in
PRCAPMMT of 8, 9, and 10, but only 10 has new variables
now kept in VXPRCAPM dataset, and only sub-subtype 9 has
been "data-tested".
Previous Crypto cards have names for values in PRCAPMCT:
PCICC PCICA PCIXCC CEX2A CEX2C CEX3A CEX3C
3 4 5 6 7 8 9
but no names are identified for the new Crypto Type 10
nor its three sub-subtypes in PRCAPMMT.
The new PRCAPMCT=10 was observed on zEC12 processors and
is thought to be a Crypto Express 4S.
-Dec 20: PRCAPM support for PRCAPML4=0 records corrected a
program loop.
-Support for new HIS (SMF113) counters in zEC12 processor,
eliminates "ERROR. PRCMFC HARDWARE COUNTER UNEXPECTED",
message with CFVN=1 and CXVN=3, which fortunately was
harmless to the rest of zVM processing.
Thanks to Kim Morrell, Royal Canadian Mounted Police, CANADA.
Thanks to Jim Dammeyer, State Farm Mutual Auto Insurance, USA.
====== Changes thru 30.253 were in MXG 30.09 dated Dec 4, 2012=========
Change 30.253 ONLY Dec 3 ASCII MXG 30.09, ONLY if MXG runs on AIX/unix.
dir3009.zip That DIR3009.ZIP distribution file dated Dec 3 has files
Dec 4, 2012 that end with a single X'1A (EOF) character. While that
character is ignored on Windows, when that unzipped 30.09
directory's files were copied from Windows to unix, those
X'1A' characters were preserved, and when read on unix by
SAS %INCLUDE, they caused SAS 180 SYNTAX errors (and may
have printed a left-arrow for that character). All X'1A'
characters were removed from this Dec 4 DIR3009.ZIP file.
Those X'1A characters are ERRORS in MY EDITing and should
NOT exist (created when I mix up LF and CRLF profiles),
and since I have done this before, the PROCSRCE program
that creates the other MXG distribution files has a test
for X'1A' characters, so those files are not exposed, but
that dir3009.zip file is a direct zip of the .sas files
in the MXG Sourclib directory.
But, how did they slip thru?
X'1A' are usually created AND detected when I email ASCII
new/updated code to a z/OS test site, and that test fails
when the translated X'1A' on EBCDIC is read by %INCLUDE.
I correct these updated files, and then search all of MXG
files for any others overlooked since the last search.
But why didn't PROCSRCE's test find them in 30.09 QA?
Because I've just discovered that X'1A' is IGNORED by
SAS V9 on Windows, whether read by %INCLUDE or an INFILE.
(And, since they ARE End Of File Markers, on Windows,
when found at the END of the file, they should be.)
I cannot prove that PROCSRCE ever found a match; perhaps
that test was added for safety, not realizing it wouldn't
ever be true on Windows SAS.
So I now searched all 30.09 files using SPF/PRO, and it
DID find 5 files, but did NOT find EXTY74HO that caused
the error! BUT: EDITing EXTY74HO in that same session
showed there WAS an X'1A' at the end of that file. Now,
it was clear that SPF/PRO can not be trusted to find all
instances of '1A'x in a large directory. But SPF/PRO is
ancient, so I searched with nearly-as-old SPF/SE and it
found these files in dir3009.zip that all ended with
an X'1A' character, and which were all removed Dec 4:
aaaaaaaa achap32 achap99 asmrmfv asmtapee copyrite
copywrit docver docver30 doqa9364 ex102366 exty74ho
imac102 jcltes92 jcltess8 jcltess9 jcltest6 jcltest8
jcltest9 qa9364 qa93641 qa93642 qa93643 qa93644
qa93645 qa93646 qa93647 qa93648 qa93649 qadoc
qawps qawps1 qawps2 qawps3 qawps4 qawps5
qawps6 qawps7 qawps8 tessothr tessusr1 testothr
testusr1 typetmo2 typetms5 vmac79 vmacbbmq vmacdb2
vmacdcol vmacommq vmactmnt vmactms5 vmacvmxa
Thanks to Sterling James, DST Systems, USA.
====== Changes thru 30.252 were in MXG 30.09 dated Dec 3, 2012=========
Change 30.252 Variable R748AAS0 was created from R748AAST but was not
VMAC74 formatted with $MG0748C, nor was it LENGTH $1 nor was it
Dec 03, 2012 in the &MXGNOTRA list of character hex variables.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 30.251 ANALCPU compares two different week's TYPE72GO CPU time,
ANALCPU creating one plot for each Service and Reporting Class,
Dec 03, 2012 with one line for each week, showing CPUTM vs STARTIME,
which is aligned to midnight Sunday of each week. These
plots could show which service class CPU time increased
or decreased, and show if he shape of the daily profile
had changed between the two weeks.
SAS/GRAPH is not used, but SAS Version 9 is because the \
plots are created with PROC SGPLOT in Base SAS V9.
Change 30.250 Hardcoded PDB. in ANALZIPC caused ITSV with %CPSTART to
ANALZIPC fail. Change 15.320 stated all hardcoded "PDB." LIBNAMEs
Nov 30, 2012 were to be replaced with "&PDBMXG.." to interface with
ITSV, but these members have been overlooked and are now
revised with no hardcoded PDB libnames:
ANAL113 ANAL120 ANAL307X ANAL4HRS ANAL72GO ANAL80A
ANAL91 ANALAAAA ANALABND ANALACF2 ANALALOC ANALAVAI
ANALAVAL ANALBLSR ANALBNC1 ANALBNCH ANALCACH ANALCAPD
ANALCISH ANALCPUV ANALDATE ANALDB2R ANALDB2T ANALDB2V
ANALDBJO ANALDBJS ANALDBTR ANALDMON ANALEAS ANALFIOE
ANALGRID ANALHPCS ANALHTML ANALNAT ANALNPMR ANALNSPY
ANALPGM ANALRACF ANALRAID ANALRMFR ANALS225 ANALSRVC
ANALTMVT ANALUAFF ANALUOW ANALUSAG ANALWHO ANALXAMR
ANALZIPC ANALZIPU ASUM4HRS ASUM72GO ASUM78CF ASUM94
ASUMCICR ASUMCLDR ASUMRAID ASUMSMFI ASUMSTC ASUMSTGP
ASUMSYTA ASUMTAPE ASUMTCPT ASUMV11 ASUMV14 ASUMVMNT
ASUMVTVM CHANGES CICSSTAT COMPINTV COMPIPLS DB2PDB
MRGDB2 NEWSLTRS VMXGINIT
Thanks to Christelle Abily, Groupe Informatique Credit Mutuel, FRANCE
Change 30.249 SMF ID=119 Subtype=51 INPUT STATEMENT EXCEEDED RECORD due
VMAC119 to 80 byte fifth segment when MXG expected 88 bytes. The
Nov 28, 2012 last two fields are now conditionally input.
Thanks to Robert B. Richards, US Office of Personal Management, USA.
Change 30.248 Cosmetic. SMF Header Messages didn't clearly identify
VMACSMF back-to-back header/trailer nor header-to-trailer with no
Nov 27, 2012 intervening SMF record; text in messages was clarified.
Change 30.247 -Variable SMF70NRM (zIIP Normalization Factor) is now kept
VMAC7072 in TYPE70PR dataset.
VMAC78 -Variables R783PB, R783CUB, R783zzz in TYPE78CF are kept
Nov 22, 2012 so those raw values are available.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 30.246 -DB2STATS QWOSxxxx variables have value 4294967295 decimal
VMACDB2 ('FFFFFFFF'x) and variable QWOSFLG='F2'x, but IBM did not
Nov 22, 2012 document those bit values nor document the FFFFx values.
Nov 28, 2012 Change 26.201 has IBM notes about the proper APAR install
to capture this RMF data, but it didn't note that you
must set the DB2 option ZOSMETRICS=YES to populate them.
-This change tests the first variables for the large value
and if both are found, all 14 QWOSxxxx are set missing.
-The four utilization values have values greater than 100
as input, and there is no IBM documentation that the must
be divided by ten, but now they are.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 30.245 -Support for BMC Mainview IMS 4.6, a/k/a IMF, a/k/a CIMS,
VMACCIMS adds new zIIP and zAAP metrics to the CIMSTRAN dataset:
VMACIMS TRXZTCPU='TOTAL*DEP RGN*APPL CPU'
Nov 21, 2012 TRXZONCP='TOTAL*DEP RGN*APPL CPU*ON CP'
TRXZAOCP='DEP RGN*ZAAP ELIGIBLE*RAN ON CP'
TRXZIOCP='DEP RGN*ZIIP ELIGIBLE*RAN ON CP'
TRXZFL1 ='TRXZFL1*FLAG'
TRXZTCPU='TOTAL*DEP RGN*APPL CPU'
TRXZONCP='TOTAL*DEP RGN*APPL CPU*ON CP'
TRXZAOCP='DEP RGN*ZAAP ELIGIBLE*RAN ON CP '
TRXZIOCP='DEP RGN*ZIIP ELIGIBLE*RAN ON CP'
-The zIIP/zAAP values are NORMALIZED to the speed of the
CP engines if your CPs are slower than Specialty Engines.
-Note that ZTIME=YES must be specified in BBPARM IMFECP00
member to populate zIIP/zAAP fields in the IMF records;
the default value is NO.
-Some missing value calculations observed in testing that
could be protected in VMACCIMS and VMACIMS now are.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 30.244 Support for WebSphere Version 8 ID=120 Subtype 10 record
EXT12010 creates new TYP12010 dataset.
FORMATS
IMAC120
VMAC120
VMXGINIT
Nov 20, 2012
Thanks to Mark Wittie, Fidelity Systems, USA.
Change 30.243 VMXGCOPY copies SAS datasets from MULTIPLE input LIBNAMES
VMXGCOPY whereas PROC COPY only allows from a single input ddname.
Nov 20, 2012 Parameters:
LIBNAMES= One or more SAS data libraries to be read.
Each value is a "starting with" string, so PDB
reads ALL LIBNAMEs starting with PDB.
On zOS each libname must have been opened with
either a LIBNAME statement or a data step, or
it will not be found.
OUTDD= The output LIBNAME where output is written.
Default is WORK.
DATASETS= One or more SAS dataset names to be copied.
Each value is a "starting with" string, so the
string TYPE will select ALL datasets starting
with TYPE. If a dataset is in multiple inputs
the output will contain ALL observations from
ALL of those datasets.
NOBS= the number of OBS to copy
ZEROOBS YES, all datasets are copied. NO, datasets
with zero observations are NOT copied and
won't exist in the output LIBNAME.
INCODE= Optional argument with your SAS code to select
which observations to copy, PROVIDED THAT THE
variable(s) you use exist in ALL datasets.
For example,
INCODE= IF SYSTEM=:'ABCD';
Change 30.242 New parameter CRITERIA= inserts SAS code for selection.
VMXG2DTE For example, if you want to keep SMFINTRV data ONLY for
Nov 15, 2012 your started tasks, at a weekly or monthly level, and you
want APPEND the new data, you would use:
%VMXG2DTE(DDIN=WEEK,DDOUT=WEEK,PDB=PDB,
DATASET=SMFINTRV,CRITERIA=TYPETASK=:'STC',APPEND=YES);
or, if you want to use GDGs and a DATA step, use:
%VMXG2DTE(DDIN=WEEKIN,DDOUT=WEEK,PDB=PDB,
DATASET=SMFINTRV,CRITERIA=TYPETASK=:'STC');
In either case, you don't supply the IF or the ending
semi-colon; the text of CRITERIA= just needs to be a SAS
expression that is TRUE for observations you want kept.
Change 30.241 There are cases where the object name can change within
ANALDB2R a database ID and object ID and possibly cases where
VFMT102 the database name might change so timestamps are needed
Nov 21, 2012 to correctly build the formats to extract the correct
database name and object name from the IFCID 105 and 107
records. This can create a massive format that requires
a large amount of memory. In one case on zOS with 16M
input records it required 862MB to create the format
and nearly as much to load it. But, the only time you
might need all of the records is when you are running
an IO trace. In the case of an Audit trace, you have
to build an Audit table to tell DB2 which things you
want to audit. So, selection criteria for DBNAME and
OBNAME are added to ANALDB2R to reduce the volume of
records input to VFMT102. You can select based on:
SYSTEM DB2 DBNAME and OBNAME
By selecting only the needed DBNAMEs, the virtual storage
needed for the format was less than 50 MB, so selection
is ALWAYS wise to do.
In addition, SYSTEM (z/OS execution system) is added as a
criteria for ALL ANALDB2R reports (DBNAME and OBNAME are
only available to VFMT102 datasets with DBID or OBID).
Don't know what DBNAME/OBNAME(s) you have? New report
MXGDBIDS=ONLY provides the list of all combinations
of SYSTEM QWHSSSID (DB2 SUBSYSTEM)DBNAME OBNAME using:
%ANALDB2R(PDB=SMF,MXGDBIDS=ONLY);
RUN;
-Unrelated, new parameter MXGACC01OUT creates an output
dataset that you name in that parameter from the MXGACC01
PROC TABULATE.
Change 30.240 Graphic and tabular reports of DB2 buffer size and max
GRAFDB2B usage, by DB2 Subsystem and Buffer Pool. Will use either
NOV 10, 2012 SAS/GRAPH or ODS GRAPHICS for graphs and PROC TABULATE to
create a tabular report.
Documentation of parameters:
PDB=PDB One or more PDB DD NAMES (LIBNAMEs)
SASGRAPH=NO Create bar charts with SAS/GRAPH
ODSGRAPH=YES Create bar charts with ODS Graphics
TABULATE=NO Create a tabular report
INTERVAL=QTRHOUR Any valid interval value
SAS versions 9.2 and earlier will not work for ODS; 9.3
is required for ODS graphics. If you are at 9.2 and don't
specify SASGRAPH=YES, the tabulate report will be created
instead. If you specify SASGRAPH=YES but it is not
installed, on SAS 9.3 or above, ODS GRAPHICS are used.
Otherwise, only the PROC TABULATE report is created.
Change 30.239 -VMACIMS IMS Eyecatcher variables STREQxxxx had $HEX40.
VMACIMS format but were correctly input as $EBCDIC4; the format
VMACRMFV and listing in NOTRAN were removed. Purely cosmetic.
VMAC120 -VMACRMFV variable ASMVER00 is now correctly INPUT $CHAR1
Nov 10, 2012 instead of $EBCDIC1 as it contains HEX text characters.
-VMAC120 variable SM1209GS is now correctly INPUT $CHAR8
instead of $EBCDIC1 as it contains HEX text characters.
(Note: $CHARn is REQUIRED only for MXG execution on ASCII
platforms - on z/OS $CHAR and $EBCDIC are identical.)
Change 30.238 Support for Phoenix Software International (E)JES SMF
EXTYEJES Accounting Record creates new EJESSMF dataset. MXG reads
IMACEJES either the unique date format for ESMFTBGN or, after
TYPEEJES EJES/14242 update, in (E)JES V5R3, the SMFSTAMP format,
TYPSEJES transparently.
VMACEJES New dataset:
VMXGINIT dddddd dataset description
Nov 11, 2012 TYEJES EJESSMF (E)JES SMF ACCOUNTING
Thanks to Mike Moyne, HHSYS, USA.
Change 30.237 Support for Version 4.3.0 BETA93/BETA97 (INCOMPATIBLE).
EXTYB97M -BETA93: New variables added to BETA1 dataset:
EXTYB97N BETAATYP='SEND*AS'
EXTYB97O BETABODY='BODY*TEMPLATE*MEMBER'
EXTYB97P BETABTYP='OUTPUT*TYPE'
EXTYBET7 BETABUFS='MAXIMUM*BUFFER*SIZE'
EXTYBET8 BETADCR ='DCR*NAME'
EXTYBETH BETAFILE='MAIL*FILE*NAME'
EXTYBETI BETAFROM='MAIL*FROM'
FORMATS BETAIPAD='IP*ADDRESS'
IMACBE97 BETALINK='LINK*TEMPLATE*MEMBER'
IMACBETA BETALTKN='LTOKEN*LIST*TOKEN'
VMACBE97 BETAMAXA='MAXIMUM*MAIL*ADDRESSES'
VMACBETA BETAPORT='PORT*NUMBER'
VMXGINIT BETARPLY='MAIL*REPLYTO'
Nov 13, 2012 BETASEXT='SOURCE*EXTENSION*NAME'
BETASFRM='SOURCE*FORM*NAME'
BETASUBJ='MAIL*SUBJECT'
BETATRMD='TRANSLATION*MODULE'
BETATRTB='TRANSLATION*TABLE'
-BETA93: New $MGBETPT format maps these values of BETAPTYP
in BETA1 dataset, which describes which of the sets of
variables exist in this record:
'80'X='80X:DCR OF TYPE SYSOUT'
'40'X='40X:DCR OF TYPE MAIL'
'20'X='20X:DCR OF TYPE CLIST'
'10'X='10X:PRE-ALLOCATED DD NAME'
'08'X='08X:DCR OF TYPE VTAM/APPC'
'04'X='04X:DCR OF TYPE SUBSYS'
'02'X='02X:DCR OF TYPE TCP/IP'
-BETA93: New Subtypes 7, 8, and 22 are documented but only
the header variables exist in the new BETA7 BETA9 BETA22
datasets until actual records are available.
-BETA93: New Subtype 49 creates BETA49 dataset for Batch.
-BETA97: New Subtype 25 creates BETA9725 dataset.
-BETA97: New Subtype 50 creates BETA9750 dataset.
-BETA97: New Subtypes 49 and 51 create BETA0751 but only
header variables are created, awaiting test records.
Thanks to Mrs. Karen Sendelback, Finanz Informatik, GERMANY.
Change 30.236 Cosmetic, spurious messages. TYPE113 processing printed
VMAC113 messages ERROR: DEACCUMULATION DETECTED RESET when HIS
Nov 8, 2012 sampling was enabled for one minute every five minutes,
because MXG did not use the SM113CF1 Start of Interval
flag to bypass the test for negative deltas that printed
these messages. However, both TYPE113 and ASUM113 were
correctly created because MXG's test for the output did
work as designed. Now, SM1113CF1 flag is used to bypass
the creation of these messages.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
====== Changes thru 30.235 were in MXG 30.08 dated Nov 7, 2012=========
Change 30.235 Variable CFWAITTO='TOTAL CF*CPU*WAIT TIME' is created in
VMAC74 dataset TYPE74CF as the SUM OF(CFWAIT01-CFWAIT15) to
Nov 7, 2012 match existing CFBUSYTO total CPU busy time.
Thanks to Joe Faska, Depository Trust, USA.
Change 30.234 First MXG 30.08, zEC12 ONLY, and ONLY with APAR OA37826,
VMAC74 which added the HO segment to the RMF 74 subtype 4 record
Nov 7, 2012 ERROR: INVALID DATA FOR CHAR4
INPUT STATEMENT EXCEEDED RECORD LENGTH.
because that code was only syntax checked, awaiting data
with that APAR installed, and CHAR4/ passed syntax but
failed when data was read, as it should have been CHAR4.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 30.233 -TYPE70 variable CPUWAITM was wrong and was larger than
ADOC7072 CPUUPTM when HiperDispatch was active (SMF70PAT GT 0) but
VMAC7072 IRD was not active (SMF70ONT=DURATM for all engines).
Nov 7, 2012 MXG did not subtract parked time from CPUWAITM, BUT ONLY
Apr 1, 2013 CPUWAITM was wrong, and since CPUWAITM is NOT used in any
other metrics, they WERE correct. Only if you compared
CPUUPTM with CPUWAITM would the error have been observed.
This error was only significant at low utilizations when
CP engines were parked; during peak intervals when all CP
engines were NOT parked, the CPUWAITM value was correct.
-But in examining the 70 records, observations in TYPE70PR
have been found with SMF70PAT greater than SMF70ONT and
DURATM by over 5 seconds; new code detects and resets
SMF70PAT to SMF70ONT and zeros CPUWAITM when a small
negative value (less than 0.10 seconds) is calculated.
So both NEWWAIT and SMF70PAT in TYPE70PR are different.
RMF development has confirmed that because ONT and PAT
are retrieved independently with DIAGNOSE instructions,
the can have different values, and RMF Reports use the
same heuristic I implemented, to store ONT in PAT when
PAT is greater than ONT.
-Inserted Apr 2013: A "WARNING. SMF70PAT GT ONT" message
was previously printed, but since there is nothing that
you can do with that information, as of MXG 31.02, it is
no longer printed.
-Variable CPUUPTM is now documented in ADOC7072:
"Originally the CPU "UP" duration for calculation of
available capacity of all CP engines, and was the
product of NRCPUS*DURATM, but that was back when the
number of CP engines were static, at least between
IPLs. Now, with IRD and HiperDispatch "varying" or
"parking" engines, NRCPUS is the AVERAGE (and
fractional) number of CP engines that were ONLINE
during this interval, i.e., that that were made
available to this z/OS system during this interval, so
the CPUUPTM=NRCPUS*DURATM now will vary and it is no
longer the "available for static capacity" up time."
Thanks to Mark Cohen, EPVTECH, ITALY
Change 30.232 Hiperdispatch introduces some vagaries into percent CPU
GRAFWRKX measurements. PCTCPUBY in RMFINTRV is calculated based
Nov 6, 2012 on the average number of CPUs online but that may be
something less than the actual number of CPs assigned
to the LPAR. GRAFWRKX now produces 3 different CPU busy
by workload charts.
% of the average number of CPUs online
% of the CPUs assigned to the LPAR
% of the LPAR SHARE (this can exceed 100% if an LPAR
is 'stealing' from other LPARs.)
Thanks to Mark WIlliams, Marks and Spencer
Change 30.231 -Support for IFCID 219 populates existing T102S219 dataset
VMAC102 with new QW0219xx IFCID-specific variables.
Nov 5, 2012 -Support for IFCID 220 populates existing T102S220 dataset
Nov 8, 2012 with new QW0220xx IFCID-specific variables, but there are
discrepancies between the IBM DSECT and the actual DATA
and a PMR is opened with IBM to resolve. See Ch 33.064.
-Support for IFCID 402 populates existing T102S402 dataset
with new QW0402xx IFCID-specific variables, but IFCID 402
is a statistics interval record with accumulated values,
so you MUST invoke TYPS102 or use %READDB2 with PDBOUT=,
or invoke _S102402 after dataset T102S402 is created, to
do the deaccumulation. And unlike the other DB2 V10
interval statistics records, IFCID=402 is written at 15
minute instead of 1 minute intervals.
-Support for 4TH Waiter in T102S196 dataset added Nov 8.
====== Changes thru 30.230 were in MXG 30.08 dated Nov 5, 2012=========
Change 30.230 Variables LPnPAT were missing in PDB.ASUM70PR,PDB.ASUMCEC
VMXG70PR (but SMF70PAT parked time was valid in PDB.ASUM70LP and
Nov 3, 2012 PDB.ASUMCELP datasets). The LPnPAT variables were not in
the RETAIN statements for the two datasets, so they have
always been missing; this is not a new error!
Thanks to Wayne Bell, UniGroup, USA.
Change 30.229 Support for DB2 NETEZZA Optional data has been read and
IMACDBNZ some corrections were made in the DB2STATS/DB2NETZA.
VMACDB2 -These DB2STATS variables
Nov 2, 2012 Q8STSCPU Q8STSELA Q8STTCPU Q8STTELA Q8STACPU Q8STAELA
were not divided by 4096.
-These DB2STATS variables
Q8STACTV Q8STCCPU Q8STWCPU Q8STQUEM
were incorrectly de-accumulated.
-The Q8AC triplet was incorrectly input, causing all of
the Q8ACxxxx variables in DB2ACCT (when enabled by the
removal of the comment block in IMACDBNZ) to be wrong.
And, the Q8ACNAME field is now INPUT and populated.
IBM DB2 Analytics Accelerator IDAA uses Netezza.
Thanks to Victoria Lepak, Aetna, USA.
Thanks to William E. Howard, Aetna, USA.
Change 30.228 Support for CICS/TS 5.1, INCOMPATIBLE CHANGES, INSERTS.
UTILEXCL -CICSTRAN has new fields inserted at the end of each
VMAC110 segment. The RMI fields that were formerly optional
Dec 30, 2011 are now created by default. CMODIDNT
Apr 25, 2012 TDILWTTM='TDILWTT*DURATION' 403
May 28, 2012 TDILWTCN='TDILWTT*COUNT' 403
Sep 25, 2012 TDELWTTM='TDELWTT*DURATION' 404
Oct 15, 2012 TDELWTCN='TDELWTT*COUNT' 404
Nov 1, 2012 ROMODDTM='ROMODDLY*DURATION' 348
ROMODDCN='ROMODDLY*COUNT' 348
SOMODDTM='SOMODDLY*DURATION' 349
SOMODDCN='SOMODDLY*COUNT' 349
ISALWTTM='ISALWTT*DURATION' 319
ISALWTCN='ISALWTT*COUNT' 319
TCALWTTM='TCALWTT*DURATION' 343
TCALWTCN='TCALWTT*COUNT' 343
SOCIPHER='SOCIPHER*COUNT' 320
CECMCHTP='CECMCHTP*NAME' 430
CECMDLID='CECMDLID*NAME' 431
MAXTASKS='MAXTASKS*COUNT' 433
CURTASKS='CURTASKS*COUNT' 434
SC64CGCT='64-BIT*C*GETMAINS' 441
SC64CHWM='64-BIT*C*STORAGE*HWM' 442
SC64UGCT='64-BIT*USER*STORAGE*GETMAINS' 443
SC64UHWM='64-BIT*USER*STORAGE*HWM' 444
SC64SGCT='64-BIT*SHARED*GETMAINS' 445
SC64GSHR='64-BIT*SHARED*BYTES*GETMAINED' 446
SC64FSHR='64-BIT*SHARED*BYTES*FREEMAINED' 447
TASZIPTM='TASK*ZIP*CPU*TIME' MXG-Created
TASELGTM='TASK*ZIP*ELIGIBLE*CPU TIME' MXG-Created
CPUTONTM='TASK*TOTAL*CPU TIME*ON ZIP' 436
CPUTONCN='TASK*TOTAL*DISPATCHES*ON ZIP' 436
OFFLCPTM='TASK*ZIP*ELIGIBLE*RAN ON ZIP*CPU TIME' 437
OFFLCPCN='TASK*ZIP*ELIGIBLE*RAN ON ZIP*DISPATCHES' 437
ACAPPLNM='APPLICATION IN*APPLICATION*CONTEXT*DATA' 451
ACPLATNM='PLATFORM IN*APPLICATION*CONTEXT*DATA' 452
ACMAJVER='MAJOR VERSION IN*APPLICATION*CONTEXT*DATA'453
ACMINVER='MINOR VERSION IN*APPLICATION*CONTEXT*DATA'454
ACMICVER='MICRO VERSION IN*APPLICATION*CONTEXT*DATA'455
ACOPERNM='OPERATION IN*APPLICATION*CONTEXT*DATA' 456
MPPRTXCD='MPPRTXDC' 449
FCXCWTTM='WAIT TIME*FOR EXCLUSIVE*VSAM CI' 426
FCXCWTCN='WAIT COUNT*FOR EXCLUSIVE*VSAM CI' 426
FCVSWTTM='WAIT TIME*FOR*VSAM*STRING' 427
FCVSWTCN='WAIT COUNT*FOR VSAM*STRING' 427
-TASCPUTM has always included the CPU time on zIIP/zAAPs,
and thus can EXCEED the elapsed time when the specialty
engine is faster than the CP engines, as documented in
Change 29.076, and because previously the TASZIPTM was
not separately recorded in CICSTRAN. Even though 5.1 DOES
have the separate field, I chose to NOT change TASCPUTM,
even though that is inconsistent with the "normal" MXG
implementation of keeping the CP and zIIP/zAAP times in
separate variables, because it seemed changing the value
in TASCPUTM would have caused more impact to you.
-CICSTRAN fields not created in 5.1 (are missing values)
DB2WAITM/DB2WAICN 189
J8CPUTM/J8CPUCN 260
J9CPUTM/J9CPUCN 267
MAXJTDTM/MAXJTDCN 277
CBSRVRNM 311
EJBSACCT 312
EJBSPACT 313
EJBCRECT 314
EJBREMCT 315
EJBMTHCT 316
EJBTOTCT 317
MLXSSCTM/MLXSSCCN 411 (not documented as gone by IBM)
-CICSTRAN fields in 5.1 that have altered meaning:
These fields now include the new GET64 CONTAINER and the
PUT64 CONTAINER data values:
PGGETCCT 323
PGPUTCCT 324
PGGETCDL 326
PGPUTCDL 327
PGCRECCT 328
-CICSEXCE dataset has two new values of EXCMNRIX of
GUDSA - Wait for GUDSA Storage
GSDSA - Wait for GSDSA Storage
-CICS Statistics Interval now defaults to 1 hour versus 3.
-CICLDG variables added:
LDGLLRRO='LIBRARY*LOAD*REQUESTS*RO TCB'
LDGLLTRO='TOTAL*LOADING*TIME*RO TCB'
-CICM variables added:
MNGCECTP='CEC*MACHINE*TYPE'
MNGCECID='CEC*MODEL*NUMBER'
-New STID=62, same as STID=60, outputs CICDS dataset.
Eighteen TCBs exist in TS/5.1, but none are new. The MXG
TCB variables in CICDS dataset all have the two-character
"TCB Name" text in their labels, and the MXG variable's
suffixes (DSG, DS1, DS2 ... for QR, RO, CO ...) are
listed in this table mapping the IBM 5.1 TCB Numbers:
TCB Name: QR RO CO SZ RP FO SL SO SP EP TP D2 S8 L8 L9 X8 X9 T8
IBM TCB NR: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
MXG Suffix: G 2 3 4 5 6 7 8 H M N D B A I J K L
-STID=101 adds two new variables to dataset CICWBG:
WBGATOMS='ATOMSERVICE*REQUESTS'
WBGJVMSV='JVMSERVER*REQUESTS'
Change 30.227 Documentation updates, to give better examples of how to
ADOCRMFI define workloads in RMFINTRV.
UTILWORK
Oct 31, 2012
Change 30.226 -Support for AIX/LINUX NMON data with FRENCH language text
VMACNMON and with fractional numbers with commas instead of the
Nov 1, 2012 expected period, found (so far ONLY) in "BBBP" records.
-Support for MEMAMS Memory Object adds MSxxxxxx variables
to the NMONINTV dataset.
Thanks to Atsou Toulabo, GMF, FRANCE.
Thanks to Giles Fontanini, GMF, FRANCE.
Thanks to Olivier Fy, GMF, FRANCE.
Change 30.225 With more than about 40 workloads defined in RMFINTRV,
ANAL72GO VMXGRMFI could fail due to macro variable string length
ANALDB2R limits on list of variables. And, if you workload prefix
ANALID was too long, VMXGSUM (called by VMXGRMFI) could fail on
ASUM113 truncated variable names, causing variable not FOUND.
MULTIPDB New MXGEXIMSG macro variable replaces all hardcoded
READDB2 arguments so that, when directed by support@mxg.com, you
SMFSRCH can use this syntax
UTILNPRT %LET MXGEXIMSG=YES;
VGETENG to enable (logs) of print lines for diagnostics.
VGETLIBS
VGETOBS
VGETSORT
VGETWKLD
VMACID
VMXGFIND
VMXGINIT
VMXGOPTR
VMXGPRA1
VMXGPRNT
VMXGRMFI
VMXGSRCH
VMXGSUM
VMXGSUM
VMXGUOW
VMXGWORL
Oct 30, 2012
Change 30.224 -Documentation note on SMF backup when execution on ASCII.
ChangeS Change 23.090 provided this technique to back up the SMF
VMXGGETM file when executing MXG on ASCII (and note the file name
Nov 1, 2012 of the backup has the date/time):
DATA _NULL_;
DATE=TODAY();
TIME=TIME();
DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!
PUT(HOUR(TIME),Z2.)!!'-'!!
PUT(MINUTE(TIME),Z2.);
CALL SYMPUT('DATETXT',DATETXT);
RUN;
FILENAME SMF FTP ("'SYS4.SMF.YOUR.DAILY(0)'")
USER='xxxxxx'
HOST='xxxxxxxx'
DEBUG
S370VS
RCMD='SITE RDW READTAPEFORMAT=S BUFNO=35' /*for tape*/
LRECL=32760
PASS='xxxxxxxx';
FILENAME SMFBKUP
"D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&DATETXT";
%LET MACFILE=
%QUOTE(
RDW=LENGTH+4;
BDW=RDW+4;
FILE SMFBKUP RECFM=N LRECL=32760;
PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X
SMFINFILE @;
);
RUN;
%INCLUDE SOURCLIB(BUILDPDB);
RUN;
That is STILL the correct (and only SAFE way) to back up
the file being read, in spite of a post to MXG-L that
reported this error message using that technique:
"ERROR: The '/' INPUT/PUT statement option is
inconsistent with binary mode I/O. The execution of
the DATA STEP is being terminated".
And, that text was found in SAS Note 3404, an ancient
note that was fixed in SAS Version 8.2.
That error message was NOT due to the backup technique;
there was a prior and unrelated syntax error that was the
true cause of that binary mode I/O error message.
But, a subsequent post suggested that RECFM=S370VBS could
be used to create the ASCII backup file, BUT:
YOU CAN NOT USE RECFM=S370VBS on ASCII for OUTPUT.
While you can write with that RECFM with no errors on the
log, THE OUTPUT FILE CANNOT RELIABLY BE READ. Sometimes
it is valid, sometimes it is not, and there is no clue,
until you try to read the backup file.
-VMXGGETM is revised to support RECFM=N write of VBS data
when it is executed on ASCII, so you could use
FILENAME SMFBKUP
"D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&DATETXT";
%VMXGGETM(SMFOUT=SMFBKUP,NRECORD=MAX);
as a standalone program to create a backup of your SMF.
Thanks to Michael Mayne, HHSYS, USA.
Change 30.223 Support for user-created CICS variables TRANSU, PGMU,
UTILEXCL USERU and USERDATU. UTILEXCL must be executed to create
VMAC110 the IMACEXCL to input those fields, and the four IMACICxx
IMACICUW members must be copied into your "USERID.SOURLIB" and the
Oct 26, 2012
Thanks to Randall R. Schlueter, FirstData, USA.
Thanks to Joan E. Nielsen, FirstData, USA.
Change 30.222 IFCID=239 DB2ACCTP observations did not set DB2PARTY nor
VMACDB2 QPACROLL nor QPACRUSM for the ID=101 SUBTYPE=1 records.
Oct 26, 2012
Change 30.221 Example HSM reports 3 and 4, Concurrent HSM Activity and
ANALHSM Concurrent HSM Queued, are now sorted by datetime within
Oct 25, 2012 each HSM Function.
Thanks to Rick Ralston, Humana, USA.
Change 30.220 Support for NDM-CD Subtype CX Certificate Expire subtype
EXNDMCX creates new NDMCX dataset.
IMACNDM
VMACNDM
VMXGINIT
Oct 24, 2012
Thanks to Douglas C. Walter, CitiBank, USA.
Thanks to Brent Turner, CitiBank, USA.
Change 30.219 The mapping of DBID/OBID hex values to the actual name of
ANALDB2R the database or table were not always decoded correctly
VFMT102 by the format created by VFMT102. In some cases IFCID 105
Oct 21, 2012 was written up to 30 seconds AFTER the trace record that
Nov 5, 2012 needed the 105 values, so a format based on timestamps
cannot be used. This iteration creates the format based
on variables SYSTEM DB2SSSID QWHSACE DBID (or DBID OBID).
NOTE: REGION=200M or larger may be required because this
format is MUCH larger; the size is related to the number
of observations in T102S105 and T102S107 datasets.
Nov 4: The Oct 21 iteration could cause duplicate values
error when building the format; NODUPKEY replaced NODUP
to circumvent the error, but this could cause some DBID
and OBID values to remain HEX (i.e., unmapped). We are
still redesigning the entire mapping algorithm but not
in time for today's MXG 30.08. Contact support@mxg.com if
you want the redesigned mapping when it's ready.
Thanks to Alyona Bertneski, JPM Chase, USA.
Change 30.218 In ANALDB2R, INTERVAL=xxxx wasn't supported, causing
ANALDB2R MXGERROR: YOU SPECIFIED INTERVAL=HOUR
Oct 19, 2012 MXGERROR: AND DATETIME=QWACBSC BUT THAT
MXGERROR: DATETIME VARIABLE IS NOT IN THE SUMBY LIST
MXGERROR: VMXGSUM TERMINATED EXECUTION
if you were using MXG 30.05 or earlier. With later MXG
versions INTERVAL= was ignored for the Accounting reports
with no error message. Now, if INTERVAL= is specified,
but the correct datetime variable is not in your SORTBY=
parameter, the datetime variable is added to SORTBY list.
-But for DB2ACCTP, intervals are still calculated based on
QWHSSTCK (the end of the interval), because QPACSCB did
not exist originally. While it could be now used, that
would require significant updates to the ASUM and TRND
members, and it is still possible for the PLAN/PACKAGE
to fall into different intervals.
-Statistic data is always summed using QWHSSTCK; since the
interval duration for statistics in DB2 V10 is now fixed
at one minute, changing to start versus end would not
make much difference.
Thanks to Ron Wells, Springleaf Financial Services, USA.
Change 30.217 -Reading RMF III data on ASCII platform generated INVALID
VMACRMFV data messages when the (new) MXG00 record (created by the
Oct 18, 2012 new ASMRMFV to document its version) was read, but there
were no errors in the other MXG-build RMF III datasets.
-Unrelated, new variable INFILENX contains the DSNAME or
ASCII filename of the input RMFBSAM file being read.
-Macro variable &VMXGJFCB is created to extract the JFCB
when TYPERMFV is executed on z/OS and to specify the
RECFM=S370VBS and LRECL=3270 when executed on ASCII so
those DCB attributes are not required on the FILENAME.
Thanks to James Sterling, DST Systems, USA.
Change 30.216 Updates to MXG code for MVS Solutions Thruput Manager SMF
VMACTPMX subtype 5 record added new fields to the SLMSLPER dataset
Oct 16, 2012 with SLM Job statistics, and corrected the input and the
format for some duration variables that were resolved to
seconds (TIME8. instead of my TIME12.2).
Thanks to Ken Deering, MVS Solutions, Inc, USA.
Change 30.215 z/VM BROKEN CONTROL record error only when MONWRITE input
VMACVMXA files were concatenated (but not always!) due to logic
Oct 16, 2012 error in MTREPR record's SKIP bytes handling.
Thanks to David Campbell, SunTrust, USA.
Thanks to Shannon Collinson, SunTrust, USA.
Change 30.214 Using VXMGFIND to print all datasets obs with found value
VMXGFIND (e.g., all observations with JESNR=12345) selected all of
Oct 11, 2012 the desired observations, but the name of the dataset in
title of each output were off by one dataset - the first
didn't have a dataset name, and the name in the second
title was the name of the first dataset, etc., due to a
mislocated RUN; statement.
Change 30.213 MXG 30.07 only. CICS STID=30 WARNING messages were caused
VMAC110 by incorrectly inserted code, which also corrupted the
Oct 10, 2012 CICLDG statistics dataset.
Thanks to Leonard DiCristofano, Anixter Inc, USA
Change 30.212 Support for APAR OA37016 for zEC12 CRYPTO EXPRESS4S adds
FORMATS a new value 10 for Crypto Processor Type CEX4C, which is
VMAC7072 added to be decoded by the existing $MGRMFCX format, and,
Oct 11, 2012 unrelated, two instances of 'F5'x were changed to dashes.
-New variable R7023MSK='VALIDITY*BIT*MASK' is created in
dataset TYPE7002.
Change 30.211 Change 30.113 accidentally removed the de-accumulation of
VMACDB2 DB2STATS variable QISTCOLS in MXG 30.04, when three other
Oct 9, 2012 QISTxxxx variables were correctly removed. QISTCOLS is
now again de-accumulated.
Thanks to Glenn Bowman, Wakefern, USA.
Change 30.210 Support for APAR PN29124 adds IFCID=366 BIF INCOMPATIBLE.
EX102366 The CHAR(decimal) function in DB2 V10 returns different
FORMATS data than the same function in DB2 V9, and the IFCID=366
IMAC102 records identify SQL source code that MUST be changed to
VMAC102 support the new format. The BIF INCOMPATIBLE option will
VMXGINIT restore the CHAR function to its V9 behavior while your
READDB2 SQL guru's change their code for DB2 V10.
Oct 10, 2012 -READDB2's previous max IFCID of 350 raised now to 450.
Thanks to Tony Anderson, Blue Cross Blue Shield of Alabama, USA.
Thanks to David McGrady, Blue Cross Blue Shield of Alabama, USA.
Change 30.209 Support for APAR OA37826 adds Channel Path Types CIB and
EXTY74HO CFP Coupling Facility data in new TYPE74HO dataset with
FORMATS both Local and Remote Channel Path Data for CIB & CFP.
VMAC74 -New Data Set TYPE74HO:
VMXGINIT R744HAID='HOST*CHANNEL*ADAPTER*ID'
Oct 7, 2012 R744HAPN='HOST*CHANNEL*ADAPTER*PORT'
R744HCHF='R744HCHF*STATUS*FLAGS'
R744HCPI='CHANNEL*PATH*IDENTIFIER'
R744HFLA='R744HFLA*VALIDITY*BIT*MASK'
R744HLAT='CHANNEL*PATH*LATENCY*TIME'
R744HOPM='CHANNEL*PATH*OPERATION*MODE'
R744HPCP='PHYSICAL*CHANNEL*ID*PCHID'
R744HSAP='FOUR*I/O PROCESSOR*ACCESSIBLE'
R744HTAP='CHANNEL*PATH*TYPE*ACRONYM'
Change 30.208 Support for APAR OA37803 which adds Warning Track
VMAC7072 Interrupt Facility.
Oct 6, 2012 -TYPE70EC and TYPE70PR new variables:
SMF70WTI='DURATION*LP WAS YIELDED*DUE TO WTI'
SMF70WTS='WTI-S*RETURNED*WITHIN*GRACE*PERIOD'
SMF70WTU='WTI-S*UNABLE*TO RETURN*IN GRACE'
Change 30.207 Support for APAR OA39993 which adds Interrupt Delay Time
VMAC74 Facility duration.
VMAC79 -TYPE74 new variable:
Oct 6, 2012 SMF74IDT='INTERRUPT*DELAY*TIME*DURATION'
Jan 3, 2012 AVG74IDT='AVERAGE*INTERRUPT*DELAY*TIME*MILLISEC'
-TYPE79 new variable:
SMF79IDT='Interrupt*Delay*Time*Duration'
Change 30.206 Support for APAR OA38660 which adds Storage Class Memory
VMAC71 (SCM) and Pageable Large Pages on EC12 (zEC12) Server,
VMAC75 which are also called "FLASH MEMORY".
VMAC78 -TYPE71 new variables:
Oct 6, 2012 SMF71ASM='MIN*AVAILABLE*NOT USED*SCM BLOCKS'
Nov 13, 2012 SMF71ASV='AVG*AVAILABLE*NOT USED*SCM BLOCKS'
Dec 25, 2012 SMF71ASX='MAX*AVAILABLE*NOT USED*SCM BLOCKS'
SMF71BSA='AVG*BAD*SCM BLOCKS'
SMF71BSM='MIN*BAD*SCM BLOCKS'
SMF71BSX='MAX*BAD*SCM BLOCKS'
SMF71C1A='AVG*HIGH VIRTUAL*COMMON*MEM PAGES'
SMF71C1M='MIN*HIGH VIRTUAL*COMMON*MEM PAGES'
SMF71C1X='MAX*HIGH VIRTUAL*COMMON*MEM PAGES'
SMF71C4A='AVG*HIGH VIRTUAL*COMMON*ON SCM'
SMF71C4M='MIN*HIGH VIRTUAL*COMMON*ON SCM'
SMF71C4X='MAX*HIGH VIRTUAL*COMMON*ON SCM'
SMF71L1A='AVG*1MB FRAMES*CANBE*USED*FIXED MEMOBJ'
SMF71L1M='MIN*1MB FRAMES*CANBE*USED*FIXED MEMOBJ'
SMF71L1X='MAX*1MB FRAMES*CANBE*USED*FIXED MEMOBJ'
SMF71L2A='AVG*1MB FRAMES*NOT USED*IN LFAREA'
SMF71L2M='MIN*1MB FRAMES*NOT USED*IN LFAREA'
SMF71L2X='MAX*1MB FRAMES*NOT USED*IN LFAREA'
SMF71L3A='AVG*1MB FRAMES*IN USE*IN LFAREA*BY FMEMOBJ'
SMF71L3M='MIN*1MB FRAMES*IN USE*IN LFAREA*BY FMEMOBJ'
SMF71L3X='MAX*1MB FRAMES*IN USE*IN LFAREA*BY FMEMOBJ'
SMF71L4A='AVG*1MB FRAMES*CANBE*USED*PAGEABLE/DREF'
SMF71L4M='MIN*1MB FRAMES*CANBE*USED*PAGEABLE/DREF'
SMF71L4X='MAX*1MB FRAMES*CANBE*USED*PAGEABLE/DREF'
SMF71L5A='AVG*1MB FRAMES*NOT USED*PAGEABLE/DREF'
SMF71L5M='MIN*1MB FRAMES*NOT USED*PAGEABLE/DREF'
SMF71L5X='MAX*1MB FRAMES*NOT USED*PAGEABLE/DREF'
SMF71L6A='AVG*1MB FRAMES*USED BY*PAGEABLE/DREF'
SMF71L6M='MIN*1MB FRAMES*USED BY*PAGEABLE/DREF'
SMF71L6X='MAX*1MB FRAMES*USED BY*PAGEABLE/DREF'
SMF71S1A='AVG*HIGH VIRTUAL*SHARED*MEM PAGES'
SMF71S1M='MIN*HIGH VIRTUAL*SHARED*MEM PAGES'
SMF71S1X='MAX*HIGH VIRTUAL*SHARED*MEM PAGES'
SMF71S5A='AVG*AUX SLOTS*HIGH*SHARED MEM ON DASD'
SMF71S5M='MIN*AUX SLOTS*HIGH*SHARED MEM ON DASD'
SMF71S5X='MAX*AUX SLOTS*HIGH*SHARED MEM ON DASD'
SMF71S6A='AVG*HIGH VIRTUAL*SHARED MEM*ON SCM'
SMF71S6M='MIN*HIGH VIRTUAL*SHARED MEM*ON SCM'
SMF71S6X='MAX*HIGH VIRTUAL*SHARED MEM*ON SCM'
SMF71TSA='AVG*4K SCM*BLOCKS AVAIL*TO ASM'
SMF71TSM='MIN*4K SCM*BLOCKS AVAIL*TO ASM'
SMF71TSX='MAX*4K SCM*BLOCKS AVAIL*TO ASM'
SMF71USA='AVG*SCM BLOCKS*IN USE'
SMF71USM='MIN*SCM BLOCKS*IN USE'
SMF71USX='MAX*SCM BLOCKS*IN USE'
-TYPE75 new flag variables are created for bits, but only
SCMPGTYP was added by this APAR - the other bits had not
been previously decoded into flag variables:
MULTEXPO='MULTIPLE*EXPOSURE*DEVICE?'
DEVALTCU='DEVICE HAS*ALTERNATE*CONTROL*UNIT'
DEVVALID='DEVMODEL*IS VALID?'
SCMPGTYP='PAGE*SPACE*TYPE IS*SCM?'
Nov 13: The four variables were added to the KEEP list.
-TYPE78PA dataset, new variables added Dec 25:
R782FIFRMIN ='MIN FRAMES*CAN BE USED*FIXED*MEMOBJ'
R782FIFRNTME='TIME STAMP*OF MIN*FIXED*MEMOBJ'
R782FIFRMAX ='MAX FRAMES*CAN BE USED*FIXED*MEMOBJ'
R782FIFRXTME='TIME STAMP*OF MAX*FIXED*MEMOBJ'
R782FIFRAVG ='AVG FRAMES*CAN BE USED*FIXED*MEMOBJ'
R782PAFRMIN ='MIN FRAMES*ARE USED*PAXED*MEMOBJ'
R782PAFRNTME='TIME STAMP*OF MIN*PGBL/DREF*MEMOBJ'
R782PAFRMAX ='MAX FRAMES*ARE USED*PGBL/DREF*MEMOBJ'
R782PAFRXTME='TIME STAMP*OF MAX*PGBL/DREF*MEMOBJ'
R782PAFRAVG ='AVG FRAMES*ARE USED*PGBL/DREF*MEMOBJ'
-TYPE78PA dataset, these new AVG value variables should
have been created, instead of their TOTL value variables,
but their TOTL variables are still kept, to be safe.
SHBYAVG ='AVG*SHARED*ABOVE 2GB'
TOBYAVG ='AVG*ABOVE 2GB'
COBYAVG ='AVG*64BIT COMMON 2GB'
COMOAVG ='AVG*64BIT*COMMON'
LGMOAVG ='AVG*LARGE*MEMOBJ'
SHBYAVG ='AVG*SHARED*ABOVE 2GB'
SHMOAVG ='AVG*SHARED*ABOVE 2GB'
TOBYAVG ='AVG*ABOVE 2GB'
TOFRAVG ='AVG*1MB*FRAMES'
TOMOAVG ='AVG*64 BIT PRIVATE'
-The APAR lists 79.11 as changed, but the APAR did not
provide any details at that time. This text will be
revised when the APAR text has been updated by IBM.
Change 30.205 Variable ACTVOL is added to TMS.TMS dataset:
TYPETMS5 ACTVOL ='ACTUAL*PHYSICAL*WHERE*VIRTUAL*OFFLOADED'
VMACTMS5 The '20'x bit in FLAG5 is also set when ACTVOL is
Oct 6, 2012 populated, but as that is redundant I did not create a
new variable for that bit.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 30.204 Support for APAR OA38980 adds new variable to DCOLCLUS:
VMACDCOL DCAZFS ='ZFS*DATA*SET?'
Oct 6, 2012 and two new variables to DCOLVOLS dataset:
DCVFCYLS='FREE*CYLINDERS*ON VOLUME'
DCVFTRKS='FREE*TRACKS*ON*VOLUME'
Thanks to Michael R. Mayne, Huntsville Hospital System, USA.
Change 30.203 Support for JES3 Main Device Scheduler IAT5210 & IAT5918
ASMTAPEE mount messages adds these new variables to PDB.ASUMTAPE
ASUMTAPE FIRST5210='FIRST*JES3*IAT5210*DATETIME'
VMACTMNT LAST5210='LAST*JES3*IAT5210*RECORD'
Oct 8, 2012 NR5210 ='NUMBER*OF JES3*IAT5210*MESSAGES'
Nov 30, 2012 VOLF5210='FIRST*JES3*IAT5210*VOLSER'
Apr 10, 2013 VOLL5210='LAST*JES3*IAT5210*VOLSER'
FIRST5918='FIRST*JES3*IAT5918*DATETIME'
LAST5918='LAST*JES3*IAT5918*RECORD'
NR5918 ='NUMBER*OF JES3*IAT5918*MESSAGES'
to measure the delay from JES3 MDS Mount/Allocate and the
dismount event for those pre-execution JES3 tape mounts.
The MXGTMNT monitor itself never sees those mounts, which
occur prior to the job's execution on z/OS, but the above
SYSLOG messages, plus the TYPE21 dismount records provide
improved tracking of JES3 mount events.
-ASMTAPEE was updated to create SMF subtype 8 records for
these messages in this enhancement, which is ML-50.
-Only data from the first and last of these JES3 messages
are kept in PDB.ASUMTAPE, but you can create subtype 9
records for each of these records if you need to see all
of them, using the //MXGMSGID DD documented in ASMTAPEE.
-Debugging PROC PRINTs in ASUMTAPE were removed Nov 30.
-Added April 2013:
INCOMPATIBLE: SORT ORDER OF PDB.ASUMTAPE was changed
from BY DEVNR EVENTIME to BY JESNR DEVNR EVENTIME which
could cause WEEKBLD/MONTHBLD to NOTSORTED fail, but only
if your WEEKBLD/MONTHBLD is prior to Change 29.008, 20.01
which made the NOBY option the default to eliminate all
BY statements in those programs). Just remove the
BY statement in your tailored WEEKBLD/MONTHBLD.
Thanks to Jim Dammeyer, State Farm Mutual Auto Insurance, USA.
Thanks to Doug Medland, IBM Canada, CANADA.
Thanks to Paul Williams, The Capital Group, USA.
Change 30.202 -RMF III Enhancements and Fixes
ASMRMFV -Fix for invalid I/O error with messages RMFV033E and
Oct 3, 2012 RMFV007S and subsequent U0998 Abend. There is a time
Oct 6, 2012 window where RMF III has opened a VSAM data set but not
yet written the first sample set. In this situation the
number of sample sets is zero, but ASMRMFV did not
correctly handle the condition and attempted to read a
non-existent sample set causing the error. In this
condition the first and last sample timestamps are zero
indicating a date of 1900.001. ASMRMFV will now
correctly issue message RMFV014I as it does for all
date/time selection mismatch conditions and proceed
without error to the next RMF III data set.
-A new parameter SIZE (alias SZ) is added. This option
provides all the features of the existing NONE option
that suppresses all output but in addition avoids reading
any RMF III tables as input (except the DSH table). The
purpose of SIZE is to provide both RMF III index and disk
space usage to allow optimum sizing of RMF III VSAM data
sets. Options INDEXES and SPACE are forced when SIZE is
coded. The I/O activity and reporting with SIZE is much
less compared to use of NONE. NONE was intended to also
provide a table contents inventory and so may still be
useful in some scenarios.
-The entire DSH table of 32756 bytes is now output not
just the 256 byte header. There is just one DSH record
for each RMF III VSAM data set.
-The Create Date is now added to message RMFV008I for
non-VSAM data sets. The JFCB (Job File Control Block)
that is the source of this data always has the current
date for all VSAM files and so Create Date is suppressed
for them.
-A new message RMFV034I will be produced to show the date
and time of the LAST CLOSE for each RMF III VSAM file.
Although the source field DSIGTODC in the DSH table is
documented as "Time data set was created", it is clear
from the begin and end sample time stamps that this date
stamp is always later than end sample time stamp and so
is consistent with a file being closed, not one that was
just created.
-The SAMPLES FILTERED count in message RMFV103I could be
incorrect when an entire data set was filtered by date
and time selection.
-Prologue documentation in the ASMRMFV source has been
updated to provide detail on the NONE and SIZE
parameters.
-Oct 6: Cosmetic: Message RMFV034I shows OPEN timestamp in
the local time zone, and imbedded blanks in 9 other date
and time fields.
Thanks to Rodger Foreman, Trans Union, USA
Thanks to Susan Graham, CapGemini, USA
Change 30.201 Variables SM1132MT and SM1132MM were blank because a test
VMAC113 for debugging (IF SYSTEM='MVSA' ...) was not removed, but
Oct 4, 2012 they were also not kept until now!
Oct 9. 2012 -Oct 9: Change 30.129 text is now available.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY
====== Changes thru 30.200 were in MXG 30.07 dated Oct 3, 2012=========
Change 30.200 DB2 V10 variable QWHCCV was incorrectly replaced by the
VMACDB2 value in new variable QWHCCTKN when the CTKN offset was
VMACDB2H non-zero. QWHCCTKN is an IP address in this format with
Oct 2, 2012 an IP address, Port Number, and a timestamp:
162.123.25.218.44485.120605112901
-------------- ----- ------------
| | |
| | |-- Unique field ( timestamp real
| |
| |-- Port address
|
|- Requester IP Address
-Only QWHCATYP=8 (REMOTE UOW) obs have QWHCCTKN in several
test SMF files, and many of those =8 observations do not
have a value, so MXG's incorrect value in QWHCCV does not
appear to have been pervasive.
-Previously, there was no "truncated offset" field for
QWHCCV, the Correlation ID, and when IBM added the
truncated offset field for QWHCCTKN, I misread the DSECT
and thought that offset was for the Correlation ID so I
INPUTed the new field at that offset into QWHCCV. I now
realize that that INPUT was for the new Correlation TOKEN
field, QWHCCTKN, which is now correctly INPUTed and KEPT.
-Now that QWHCCV has no truncated offset, it's length is
restored to $12 instead of $128.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
====== Changes thru 30.199 were in MXG 30.07 dated Oct 2, 2012=========
Change 30.199 DO NOT USE MXG 30.07 DATED OCT 1 OR EARLIER. THOSE WERE
EXTY70PR TEST ITERATIONS THAT UNFORTUNATELY HAD A SERIOUS ERROR
Oct 2, 2012 AND CREATED ZERO OBSERVATIONS IN TYPE70PR DATASET AND
WAY TOO MANY OBS IN TYPE70SP, DUE TO MY ERROR IN MY QA.
The EXTY70PR member OUTPUT to _WTY70SP incorrectly; that
should have been (AND IS NOW) OUTPUT to _WTY70PR.
====== Changes thru 30.198 were in MXG 30.07 dated Oct 1, 2012=========
Change 30.198 These labels for these variable in VMACNMON are
VMACNMON misleading and incorrect: they indicate "percentages"
Oct 1, 2012 APCPUUSER='PCPU_ALL*USER*PERCENT'
APCPUSYS ='PCPU_ALL*SYSTEM*PERCENT'
APCPUWAIT='PCPU_ALL*WAIT*PERCENT'
APCPUIDLE='PCPU_ALL*IDLE*PERCENT'
APCPUBUSY='PCPU_ALL*BUSY'
but they are PHYSICAL CP counts: Their labels are now
corrected to:
APCPUUSER='PHYSICAL*CP*USER'
APCPUSYS ='PHYSICAL*CP*SYSTEM'
APCPUWAIT='PHYSICAL*CP*WAIT'
APCPUIDLE='PHYSICAL*CP*IDLE'
APCPUBUSY='PHYSICAL*CP*ENTITLED'
Thanks to Lennon L. Marchang, Coca-Cola Company, USA
Change 30.197 Support for user-created CICS variables TRANSU, PGMU,
UTILEXCL USERU and USERDATU. UTILEXCL must be executed to create
VMAC110 the IMACEXCL to input those fields, and the four IMACICxx
IMACICUR members must be copied into your "USERID.SOURLIB" and the
IMACICUT comment block therein removed.
IMACICUU
IMACICUV
Sep 25, 2012
Thanks to Alex B. Nielsen, KMD, DENMARK.
Thanks to Noach Holger, KMD, DENMARK.
Change 30.196 Variable QW0247DA was truncated to 8 bytes because it was
VMAC102 assigned $HEX16. format and only the first 200 bytes were
Sep 24, 2012 input with $VARYING200., but actual data length can be up
to 4096, so the INPUT and FORMAT were revised.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, Australia
Change 30.195 Optional DB2 variable CORRNAME is created in the _DB2CORR
VMACDB2 macro defined in VMACDB2, with CORRNAME=SUBSTR(QHWCCV) so
Sep 24, 2012 its length was $12 when QWHCCV is $12. But Change 30.032
(incorrectly!) increased QWHCCV to $128, causing CORRNAME
to increase, which then could print warning messages
about MULTIPLE LENGTHs. Adding a LENGTH CORRNAME $8;
statement to the MACRO _DB2CORR definition in VMACDB2
corrected. However, you should copy that definition into
your IMACKEEP member so the same definition is always
used at your site, and because some sites have needed to
tailor the actual substringing.
-Change 30.200 restored QWHCCV to the correct $12 length.
Thanks to Alyona Bertneski, JP Morgan, USA.
Change 30.194 DB2 QMDAACCT field LENACCT1=246 caused the error message:
VMACDB2 INVALID THIRD ARGUMENT for SUBSTR(QMDAACCT,BEG,LENACCT1)
Sep 21, 2012 because the QMDAACCT INPUT was $VARYING200. LENACCT1 so
the length of QMDAACCT was restricted by the $VARYING200.
Thanks to Stephen Donahue, Fidelity Investments, USA.
Change 30.193 The MXGTMNT (ASMTAPEE) Tape Mount and Tape Allocation
ASMTAPEE and SYSLOG monitor program has been enhanced. The ML-49
Sep 20, 2012 level removes the requirement of having the tape UCBs
PINNed. This eliminates the previous requirement that
your operators had to stop and restart the monitor when
your tape drive configuration changed, and it eliminates
the need for documenting that procedure for operators.
The new monitor will now detect that a configuration
change has been successfully completed and determine
whether or not a tape device was involved. If so, the
monitor will automatically suspend processing, rescan the
tape device's UCBs, and restart monitoring without user
intervention. Old and new levels of MXGTMNT can exist on
multiple z/OS systems that share tape devices. Systems
with ML-49 will automatically detect the change, systems
with prior versions will still need operator intervention
when the tape device configuration is changed.
Change 30.192 zVM MONWRITE dataset VXAPLSL0 Linux Processor Utilization
VMACVMXA variables PCTSYST PCTIDLE PCTINTR PCTSOFT PCTIOWT were
Sep 19, 2012 all incorrect, because the right-hand variable for each
Sep 20, 2012 of those percent calculations was NICEMODE instead of the
individual xxxxMODE variable.
-Variables PCTUSER/PCTNICE/USERMODE/NICEMODE were reversed
in the INPUT statement so they too were wrong.
-New PCTSTOL/STOLEMODE is created with the time when the
z/VM Hypervisor had stolen the clock ticks.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.191 JOB to create/update the MXG FORMAT library when you use
BLDFORMT CONFIMXG configuration with // EXEC SAS93, needed because
Sep 18, 2012 CONFIMXG sets DISP=SHR for LIBNAME LIBRARY:
//S1 EXEC SAS93,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
//SYSIN DD *
LIBNAME LIBRARY CLEAR;
LIBNAME LIBRARY "&MXGFORMT" DISP=OLD;
%INCLUDE SOURCLIB(FORMATS);
Change 30.190 z/VM 6.1 data caused BROKEN CONTROL RECORD error because
VMACVMXA the length of STSI in VXMTRTOP was increased from 40 to
Sep 17, 2012 at least 152 and MXG had $VARYING40., now $VARYING255.
Change 30.189 Use of %CMPRES in VMXGSUM was removed by Change 29.154 to
VMXGSUM avoid APPARENT INVOCATION OF CMPRES MACRO messages (z/OS)
Sep 17, 2012 but unfortunately Change 30.158 (MXG 30.06) slipped its
use back in VMXGSUM, so this change was going to just
remove it and live with lots of blank in the error text
we were compressing. However, we have discovered that
the %CMPRES macro can be replaced using %SYSFUNC:
%LET MESSAGE=%SYSFUNC(COMPBL(&MESSAGE));
which eliminated the reference to SASAUTOS.
However, the actual cause of this error is that your MXG
was incorrectly installed; either your JCL or your CONFIG
options are preventing MXG from accessing that macro from
the SAS-provided SASAUTOS library. Change 28.128 lists
the many ways to correct this install error, but you MUST
correct your JCL/CONFIG, as many other MXG programs
depend on SASAUTOS. VMXGSUM is protected ONLY because
%CMPRES again was not required and could be removed, and
because VMXGSUM is used in BUILDPDB and ASUMxxxx members
that build PDBs.
Change 30.188 Support for SMF 119 Subtypes 48 thru 52 populate the SMTP
FORMATS variables in those existing datasets.
VMAC119 -Oct 1: some datetime variables were not length 8.
Sep 16, 2012
Oct 1, 2012
Thanks to Randy Shumate, Reed Elsevier Technical Services, USA.
Thanks to Tom Erwin, Reed Elsevier Technical Services, USA.
Change 30.187 Variables CMF06SPL & CMF06SPH are input &PIB.2.1 because
VMACCMF they were ten times too large in CMF06GDA dataset.
Sep 15, 2012
Thanks to Alfred Sau, TJX, USA.
Thanks to Kevin Luey, TJX, USA.
Change 30.186 Two "MXG" DB2 reports are added that are not in DB2PM.
ANALDB2R -MXGACC01 is an interval summary report with your choice
Sep 15, 2012 of selection criteria that provides total and average
Sep 17, 2012 values for the important CPU and suspend and get-page
variables for the buffer pools with average and max
elapsed times. MXGACC01=YES creates a summary by
QWHSSTCK QWHSSSID QWHCATYP and QWHCAID. The datetime
value will reflect the value in the interval parameter.
If you use an interval of DATE/WEEK/MONTH the format of
QWHSSTCK is adjusted to DATETIME7. and any other interval
value it is adjusted to DATETIME13. If no interval is
specified it is adjusted to datetime16.
Example 1:
%ANALDB2R(MXGACC01=YES,INTERVAL=DATE,
PMACC01=NO,PMACC02=NO,PMSTA02=NO);
creates a summary of all DB2ACCT records in the input
PDB.DB2ACCT dataset, at date interval.
Example 2:
%ANALDB2R(MXGACC01= IF QWHCATYP=4; ,INTERVAL=DATE,
PMACC01=NO,PMACC02=NO,PMSTA02=NO);
creates a summary of all CICS DB2 account records with
an interval of date.
-MXGACC02=YES creates an unsorted detail report for every
record in DB2ACCT. Given the volume this is most likely
NOT what you want to do, without some selection criteria.
Example 1:
%ANALDB2R(MXGACC02=IF ELAPSTM GT 60 AND QWHCATYP=4;,
PMACC01=NO,PMACC02=NO,PMSTA02=NO);
creates the detail report, but only for CICS DB2 that
executed for over 60 seconds.
Thanks to Ron Wells, Springleaf Financial Services, USA.
Thanks to Richard Brooks, Springleaf Financial Services, USA.
Change 30.185 -VFMT102 is invoked by READDB2/ANALDB2R to build formats
ANALDB2R to decode the hex DBID and OBID values in the DB2 IFCID
READDB2 105/107 records, but it could be executed many times if
VFMT102 multiple IFCIDS or multiple reports were requested. This
VMXGINIT change prevents multiple executions within a single pass
Sep 15, 2012 of data by setting the global macro variable VFMT102 when
it is run the first time, and testing it to prevent the
re-execution. If ANALDB2R/READDB2 is restarted in the
same SAS session (possibly pointing to different data),
VFMT102 will be re-executed.
-Variable QW0145LN is printed instead of QW0145LO and $4.
format is added for QW0145SC in ANALDB2R audit reports.
Change 30.184 New INCODE= parameter added to permit input selection.
ANALINIT For example:
Sep 12, 2012 %ANALINIT(INCODE=IF DATEPART(READTIME) GE TODAY()-1;);
would report on only jobs submitted since yesterday.
Change 30.183 MXG 30.05/30.06. PROC FORMAT overlapping range error can
DOC occur with READDB2/ANALDB2R. Change 30.140 removed the
Sep 15, 2012 datetime from the format, but duplicates can exist if the
input spans a very large time frame. VFMT102 in 30.04 or
earlier can be used, so it is stored in the new VFMT102X,
created ONLY so that support@mxg.com can send that one
(renamed) member if you encounter the error. The VFMT102
was altered in Change 30.185 so it cannot be sent without
sending additional members to circumvent this error.
But: VFMT102X was removed in MXG 30.30.
Change 30.182 Support for zNEXT EC12 processors with 101 engines.
VMAC7072 There are no new variables kept in TYPE70 since all of
Sep 8, 2012 the CPU-specific variables for CPU 64 or higher have been
output in TYPE70EN dataset since Change 28.175.
Change 30.181 The "Split 70" logic did not provide exits for four data
EXTY70EC sets TYPE70EC, TYPE70EL, TYPE70EN, and TYPE70SP because
EXTY70EL they were thought to be internal and temporary, but they
EXTY70EN now have exits implemented so that users can make changes
EXTY70SP to those four datasets if needed.
VMAC7072
Sep 7, 2012
Thanks to Ruth Leonhardt, Xerox, USA.
Change 30.180 -Two problems both found in testing that does not impact
VMXGSUM the output but can improve efficiency of execution.
Sep 7, 2012 Case 1:
%VMXGSUM(INDATA=PDB.DB2ACCT,
OUTDATA=DB2SUM,
SUMBY=QWHSSSID,
SUM=DB2TCBTM,
MAX=MAXCPU,
INCODE=MAXCPU=DB2TCBTM;
);
In this case, the MXGSUM1 dataset contained all 500+
variables from DB2ACCT when only 3 were needed, because
the KEEP= list was not being applied to the output
dataset. Now, all variables in the parameter lists is
added as a KEEP statement to reduce DASD space required.
Case 2:
%VMXGSUM(INDATA=PDB.DB2ACCT,
OUTDATA=DB2SUM,
SUM=DB2TCBTM,
MAX=MAXCPU
);
In this case, the MXGSUM2 dataset was created by the
SORT and since there was no INCODE, the MAXCPU variable
did not exist so the PROC MEANS failed with a variable
not found error. Now, the KEEP logic after the SORT is
NOT suppressed when there is no first DATA step.
-Cosmetic. Deletion of temporary datasets used during the
course of VMXGSUM moved from the end to the points in the
code where they are no longer needed avoiding confusion
of the programmer on when/where they should be deleted.
Change 30.179 Formula changes from John Burg's SHARE presentation. For
ASUM113 the z196 (VN=2) 0.59 replaced 0.57, 1.67 replaced 1.6, &
VMAC113 0.61 replaced 1.00; the z10 (VN=1) 0.31 replaced 1.00.
Sep 3, 2012
Sep 17, 2012
Change 30.178 -Using a numeric variable in your SORTBY= tailoring option
ANALDB2R caused ERROR 48-59 citing PUT @1 &SORT $CHAR16 text. That
Sep 2, 2012 $CHAR format is not only NOT needed here (prints SORTBY=
Sep 4, 2012 variable's value, format not needed because all possible
variables here are MXG-formatted), it is THE PRESENCE of
the $CHAR format that causes this error, so its REMOVAL
eliminates this unintended consequence and oversight, and
now numeric variables like CONNTYPE and QWHCATYP that
exposed the error can be used in your SORTEDBY list, and
they will be added in a new QA test of ANALDB2R.
-In testing this change it was discovered that if you
ran PMACC03 without all of the input datasets (DB2ACCTP,
DB2ACCTB, DB2ACCTG) it would fail calling ASUMDB2p/b/g
members for those datasets. If the datasets do not exist
now, there will be an MXGNOTE printed on the log telling
you what was found, with processing to continue without
the missing datasets.
Thanks to Howard L. Curtis, Duke Energy, USA.
====== Changes thru 30.177 were in MXG 30.06 dated Sep 1, 2012=========
Change 30.177 SAS 9.2 z/OS ONLY VGETOBS didn't recognize tape datasets.
VGETOBS On z/OS, SAS 9.2 returns a blank in DICTIONARY.TABLES for
Aug 30, 2012 the number of OBS in a tape dataset, which caused VGETOBS
to return a blank value, but both SAS 9.1.3 and SAS 9.3
returned a bogus set of non-blank characters that proved
there was a tape dataset, so VGETOBS returned a one value
(it found a tape dataset), and VGETOBS could print a log
message that it had detected non-blank non-numeric text,
(but only if the NOEXIMSG internal option was enabled to
print suppressed log notes). Now, a blank value invokes a
new test (VGETDSN length GT 0) for the dataset name that
is used to return a value of one for a tape dataset.
Thanks to Robert Stoffregen, Great Lakes Educational Loan Svcs, USA.
Change 30.176 -Some cosmetic changes to better document the records that
ANALDB2R are being reported, and new options for the AUDIT= parm:
Aug 28, 2012 AUDIT=DML < runs as it currently does uses 143 and 144
Aug 31, 2012 AUDIT=DMLREAD - processes only IFCID 144 for DML
AUDIT=DMLWRIT - processes only IFCID 143 for DML
and a missing semicolon was found.
-Requesting PMACC02=YES by itself, after reading SMF plus
executing the ASUMDB2x members, resulted in overlaying
many old-style macros that caused error messages. Those
old-style substitution macros are now cleared in PMACC02.
Change 30.175 Support for IFCID=271 DB2 AUDIT PERMISSIONS trace record.
VMAC102 Dataset existed but none of the IFCID-specific fields
Aug 28, 2012 were input.
Change 30.174 -Allocation utilities VMXGALOC & VGETALOC permitted 8-byte
VGETALOC dates formats for mmddyy, ddmmyy, and yymmdd, but mmddyy
VMXGALOC and ddmmyy generate slashes in the constructed directory
Aug 28, 2012 names; this change allows 6 8 and 10 byte formats for the
Sep 16, 2012 mmddyy and ddmmyy but will replace them with the formats
mmddyyd and ddmmyyd that use a - rather than a /, like
the yymmdd format that already uses a - as documented.
-VGETALOC uses %LEFT %macro supplied by SAS in SASAUTOS
directory and MXG options in AUTOEXEU.SAS or AUTOEXEC.SAS
include SASAUTOS and MAUTOSOURCE to "autocall" it, but
%LEFT was not actually required in VGETALOC, so it was
removed so VGETALOC would not fail even if the site did
not have their SASAUTOS correctly allocated in AUTOEXEU.
-GETDATERANGE= parameter will now accept a number of days
relative to today to search. For example:
%VGETALOC(GETDATERANGE=-5 -9,BASEDIR=C:\MXG,
DATEFMT=YYMMDD.);
will look for directories in C:\MXG with dates of
12-09-06 thru 12-09-02 inclusive.
There is now also an MXGNOTE if any directories are not
found.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 30.173 WARNING: "INVALID QMDA SEGMENT ACCOUNT values are blank"
VMACDB2 for records with QMDALEN=258, but QMDAASLN=110 (so there
Aug 27, 2012 really were only 110-56=54 possible data bytes remaining)
were printed because MXG incorrectly used QMDASFLN=247 as
the length of accounting data. But these records don't
contain JOB accounting data: text after QMDASFLN is an
exact repeat of the first 28 bytes of the QMDA segment,
QMDAPTYP,QMDAPVER,QMDAPREL,QMDAPMOD, and QMDAPLAT.
Now, MXG uses QMDAASLN instead of QMDASFLN to print any
warnings (so these false positives won't print), and the
text that follows QMDASFLN is INPUT into QMDAACCT based
on QMDAASLN. But, since QMDAACCT has never been KEPT in
PDB.DB2ACCT this change was really just cosmetic so the
false warning won't be printed on the log.
Thanks to Paul Billick, QVC, USA.
Change 30.172 -RMF III Enhancements, more:
VMACRMFV -New variables are added to the ZRBCPU file:
Aug 28, 2012 CPUCAPAD CAPACITY*ADJUSTMENT*INDICATION
CPUCAPRS CAPACITY*CHANGE*REASON
CPUDTIME TIME*DELTA*BETWEEN 2*DIAG CALLS
CPUIMMSU IMAGE*CAPACITY*MSU*LIMIT
NOTE: CPUDTIME will be missing for LPARs running as VM
Guests.
-New variables are added to the ZRBLCP file:
LPARCLUS LPAR*CLUSTER*NAME
LPARGRPM GROUP*MAXIMUM*LICENSE*UNITS
LPARGRPN CAPACITY*GROUP*NAME*FOR*LPAR
LPARONCS CENTRAL*STORAGE*ONLINE*IN MB
LPAROSNA OS*INSTANCE*NAME
LPARUPID USER*PARTITION*ID
NOTE: Variables LPARCLUS, LPARGRPN, LPARGRPM, LPARONCS
require RMF Monitor III data at the z/OS 1.12 Level to
be populated.
-Change 29.013 for CPCGRPLM, text and the INPUT statement,
were both reversed; the four byte variable is input first
and then the reserved four bytes are skipped.
Change 30.171 I had removed references to CICS stats dataset CICMNR, as
VMXGINIT IBM had never externalized that DSECT, so MXG had never
Aug 27, 2012 created any observations, and because it kept showing up
as an exception on QA reports. However, I also removed
the dataset token macro variables &PCICMNR and &WCICMNR
from VMXGINIT, which cause UNRESOLVED MACRO ERROR when
the new VMXGINIT was used with MXG 30.02 or earlier.
I should never have removed those macro variables and so
they are restored to be defined in VMXGINIT.
Thanks to Pat Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
Change 30.170 Large increase in CICLDR observations count, 1,700,000,
EXCICLDR with only 70,000 CICSTRAN observations; there is one obs
Aug 27, 2012 for each program that has been active, but almost all of
the observations have zero Fetch Count (LDRFC) so this
change now output CICLDR observations ONLY if LDRFC is
no zero; that test is located in the EXCICLDR exit member
in case you ever want to change and output them all.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 30.169 -Dataset T102S083, IFCID=83, always had zero observations
FORMATS due to an LE test for QWHSRELN that should have been GE.
VMAC102 -IFCID=145 record with unexpected QWT02R1L=0 ABENDed with
Aug 25, 2012 invalid DO loop value. The records are continuations for
Oct 12, 2012 an SQL command with a total of 98,567 characters, so that
multiple SMF record are written, and the continuation SMF
records do not contain the expected R2O segment, so MXG's
logic was revised. However, a problem has been opened
with DB2 Support because the QW0145LE length-field is not
correct, and there is no explicit offset field to the SQL
text in both the initial and continuation records, so the
MXG input is heuristic based on the available records and
the actual SQL text length in each observation is in the
MXG-calculated QW0145LNTXT variable.
-Oct 12: IBM APAR PM74186 corrects the SQL length error.
-These new-in-DB2-V10 QW0145 fields are INPUT and kept:
QW0145IS QW0145SI QW0145OBNUM QW0145ACNUM
QW0145LL QW0145LNTXT
and format $MGD145I decodes the Isolation Level QW0145IS.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 30.168 Enhancement to ASM program that recreates RECFM=VB or VBS
ASMDBLKU data from downloaded ASCII "RECFM=U" that is now reloaded
Aug 24, 2012 back to z/OS into 32760 byte chunks that ASMDBLKU reads
Aug 29, 2012 to reconstruct the original VB/VBS file (perhaps so you
can terse it and send it on to a vendor), for sites that
don't have SAS on z/OS (when you would instead use the
MXG UDEBLOCK program to recreate valid VB/VBS files).
-JCL PARM field values of PARM=VB or PARM=VBS are now
supported. The default is VBS if no PARM field is coded.
PARM=VB creates RECFM=VB,LRECL=32756,BLKSIZE=0, while
PARM=VBS creates RECFM=VBS,LRECL=32760,BLKSIZE=0 as in
prior versions of ASMDBLKU. Any other PARM field values
will result in error message DBLKU29S and termination
with Return Code 16.
-New message DBLKU29I shows PARM field value if present.
-Message DBLKU25I now also shows the average LRECL of the
input SMFIN file.
-Message DBLKU26I now also shows the average LRECL of the
output SMFOUT file.
-New message DBLKU27I shows the number of input SMFIN file
records that were read at the minimum and maximum LRECL
values. This provides an idea if the record lengths on
input were biased toward these values.
-New message DBLKU28I shows the number of output SMFOUT
file records that were written at the minimum and maximum
LRECL values. This provides an idea if the record
lengths on output were biased toward these values.
-Maximum LRECL value for the output SMFOUT file was
incorrect in message DBLKU26I.
Change 30.167 MXG 30.04-30.05. The Debugging PUT _N_= YYYYDDD= at line
VMACIMS 3826 is deleted, to eliminate the unwanted log messages.
Aug 24, 2012
Thanks to David J. Schumann, Blue Cross of Minnesota, USA.
Change 30.166 Change 30.153 supported keeping PROGRAM and PROG1-PROGnn
ASUMCICX variables in PDB.ASUMUOW, but its tailoring instructions
ASUMUOW were incomplete, and you may need this updated IMACUOW.
IMACUOW To add PROGRAM (and optional PROG1-PROGnn variables):
VMXGUOW - you must update ASUMUOW to add (only) variable PROGRAM
Aug 24, 2012 to the MACRO _KUOWIDC definition,
- you must update ASUMUOW to add PROGRAM, plus any of the
PROG1-PROGnn variables that you want kept, into your
MACRO _KUOWPTH definition,
- if the PROGRAM name you want/need isn't the PROGRAM in
that last CICSTRAN in this UOW, then you will need to
use this new IMACUOW tailoring and start with Case 5 as
your MACRO _TRANUOW selection, but be aware there still
could be additional site-dependent mods required.
This example adds PROGRAM and PROG1-PROG3:
%LET MACKEEP=%QUOTE(
MACRO _YESOBS %
MACRO _NOOBS %
MACRO _KUOWPTH
EXECAPPL PROGRAM PROG1-PROG3 %
MACRO _KUOWIDC
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
PROGRAM
%
);
%INCLUDE SOURCLIB(VMXGUOW);
_NOOBS
OPTIONS NODSNFERR NOVNFERR;
_SUOWCIC /*SORT CICSTRAN DATA */
_SUOWDB2 /*SORT DB2 DATA */
_SUOWMQ /*SORT MQ SERIES DATA */
_SUOWSPN /* CREATE ASUMUOW DATASET */
%VMXGUOW;
_YESOBS
OPTIONS DSNFERR VNFERR;
If you use ASUMCICX to summarize the PDB.ASUMUOW CICS in
PDB.CICS output dataset, you may need to add PROGRAM to
the _BSUxxxx macro, as also now documented in comments.
The only code changed in this change was in IMACUOW, but
that is only the addition of the new Case 5 example.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 30.165 Cosmetic. Existing $MGTMDAC format assigned to QW0142AC,
VMAC102 to decode A/C/D to ALTER/CREATE/DROP. Note that when an
Aug 23, 2012 MXG $MGxxxxx character format is assigned to a variable,
that variable must be in a LENGTH statement with the
input length; in the absence of a LENGTH statement, the
old $1 character variable is changed to the length of the
longest text in the $VALUE statement for that format.
Change 30.164 Support for six Tandem Prognosis data files creates these
EXTAPCPU six datasets;
EXTAPIPU
EXTAPJOB DDDDDD MXG MXG CREATED
EXTAPOBJ DATASET DATASET DATASET FROM
EXTAPPHY SUFFIX NAME LABEL INFILE
EXTAPVOL
IMACTAPR TAPCPU TAPRCPU TANDEM PROGNOSIS CPU TAPRCPU
TYPETAPR TAPIPU TAPRIPU TANDEM PROGNOSIS IPU TAPRIPU
TYPSTAPR TAPJOB TAPRJOBS TANDEM PROGNOSIS JOBS TAPRJOB
VMACTAPR TAPOBJ TAPROBJECT TANDEM PROGNOSIS OBJECT TAPROBJ
VMXGINIT TAPPHY TAPRPHYSVOL TANDEM PROGNOSIS PHYSVOL TAPRPHY
Aug 24, 2012 TAPVOL TAPRVOLUME TANDEM PROGNOSIS VOLUME TAPRVOL
JCLTEST9
Aug 26, 2012 The TYPETAPR or TYPSTAPR members will create all six MXG
Aug 31, 2012 datasets, reading each of the six input files, but the
Sep 25, 2012 individual datasets can be created with the _Tdddddd
to create and the _Sdddddd token to sort each one. See
examples in comments in VMACTAPR.
-Sep 25: DD MON YYYY HH:MM:SS format for CPU001 supported.
-These problems need to be resolved by Prognosis vendor:
JOBS fields: 014,034,040-044,082,083:
a. Invalid values in 014 - IR_ELAPTIME_STRING
1:29
109-05:50:31
48
b. Invalid values in 034 - IR_STARTTIM_STRING
Values of 19 AUG 2012 and 02 MAY 2012 but the
IR_STARTTIM_TIMESTAMP is the same these records.
c. What are the units, where's the decimal, one obs has:
040 IR_SENDRESP value 0.0185
042 IR_PERFORM value 0.0104
043 IR_RESPTIME value 0.0185
044 IR_CPUSECS value 133877 - if in microseconds,
then 0.133877 is larger than response.
d. Range of values are strange:
082 IR_SEQNUM - 1617862657, 8, and 1628929
083 IR_ANCSEQNO - 1617861633, 0, and 1895169
VOL fields: 061,062,063
e. 061 IR_FULLTIME_STRING 21 OCT 2605: 20:52:57
062 IR_FULLTIME_TIMESTAMP 0
063 IR_FULLTIME_GMT_OFFSET 0
CPU fields 001/002 string and timestamp inconsistency:
f. CPU has IR Time String format 8/20/12 with the time
0:00 (no seconds), but format 20 Aug 2012 0:00:00 is
used in the other records.
g. CPU has IR Timestamp value 2.12212E+17, which doesn't
have enough digits to decode correctly; other records
have 212212195260000000 microseconds, which does have
enough digits and after adding the Tandem constant to
convert from proleptic time, is a valid GMT datetime.
-Notes on data structure issues that are circumvented:
-The record delimiter in the tandem file is the unix "LF"
but that is changed to "CRLF" if the file is copied to a
Windows platform. Macro variable MXGCRLF transparently
sets the TERMSTR option of the INFILE statement to use
the correct delimiter. It is set to TERMSTR=CRLF on WIN
platforms, to TERMSTR=LF on all other ASCII platforms,
and it is blank on z/OS. It can be changed with %LET.
-The clue you have the wrong record delimiter is an error
"ARRAY EXCEEDED" that prints the first two records where
you can see the text date field after the last IR header
name is listed as another field in that first record.
-The JOBS "comma-delimited" file has double quotes around
all character fields, and some contain embedded commas,
which required special handling due to MXG's use of SCAN
function which has no DSD option. A vendor option to
to change the delimiter to a tab would have been nice.
Double quotes were removed, and the commas restored.
-GMT Offset is not provided in the IPU record.
-All fields with "PERC" are labeled (MXG-style) "PCT".
Change 30.163 Windows IIS Server Log record with strange URIQUERY value
VMACWWW C63BCB3DB05CA94A1ECF2B1C13C048097E3456C966691FE6EEB4168
Aug 21, 2012 D55EB32905A6221CB8CA5C525
Sep 28, 2012 that did not contain the expected equal sign caused MXG
to loop; that unexpected text value is now protected.
-Data records with ^M (CR) were created when IIS file was
moved to AIX could be stripped using DOS2UNIX command,
but can also be read with MXG using
%LET MXGCRLF = TERMSTR= CRLF ;
before the %INCLUDE of TYPEWWW, because this change added
&MXGCRLF in the INFILE statement in VMACWWW.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 30.162 Documentation. The RACF field AUDITFID is MXG variable
VMAC80A RACF264 in RACF event datasets TYPE8028/29/30/44/45/8055,
VMACRACF created from SMF 80 records, a 16-byte $HEX32 formatted
Aug 21, 2012 variable because it contains both hex and text:
e.g.: 'C8C6E2F0F0F93D0B00000000004D385B'X.
and the RACF field AUDITFID is MXG variable AUDITID in
dataset RACF0900 from IRRDBU00 RACF UNLOAD UTILITY data,
a $32 character variable with the above hex as text.
Both variables have been in MXG for years, but I have
added "AUDITFID" text to both variable's label.
Thanks to Mark Jacobs, Time Customer Service, USA.
Change 30.161 -RMF III Further Enhancements:
ASMRMFV -A new message RMFV033E is issued when a VSAM Read Error
Aug 19, 2012 occurs to show the current and maximum Relative Record
Number, RRN, of the RMF III record being read, and the
return/reason codes from the failed read operation. This
message will aid in the investigation of sporadic VSAM
read I/O errors that go away when ASMRMFV is rerun. We
will use these messages to circumvent the error.
-NOTE: We have never had a VSAM Read error repeat with a
rerun; if you error with ABREAD please add a //SYSUDUMP,
and send the dump to support@mxg.com so we can resolve.
-The SHOWCB macro calls that collect RMF III VSAM file
attributes have been consolidated to a single call to
reduce code path length.
-New parameter ABREAD/NOABREAD lets you control ASMRMFV's
action when a VSAM read I/O error does occur:
-ABREAD is the default and duplicates the current ASMRMFV
behavior: a USER 0998 abend occurs on the first instance
of a VSAM read I/O error and no further data is written
to the RMFBSAM output file by ASMRMFV. Alias is ABR.
-NOABREAD suppresses the above abend and the action taken
depends on the data being read. Alias is NOABR. On the
first read of an RMF III VSAM data set the action is to
close this VSAM dataset and then open the next RMF VSAM
file (if any). Otherwise, if the error occurs on a
subsequent read for sample set data, the problem sample
set is skipped and ASMRMFV attempts to read the next
sample set from the same data set (if any).
-ASMRMFV ends with Return Code=12 if NOABREAD is in
effect and a read I/O error has occurred.
-Program prologue documentation is updated to discuss
ABREAD and NOABREAD and new Return Code 12.
-With either ABREAD or NOABREAD, the output RMFBSAM file
is likely to be missing data after a read I/O error.
-NOTE: When ASMRMFV is being executed under the CLRMFV
CLIST, the abend (if ABREAD in effect) is trapped, and
with either ABREAD or NOABREAD, CLRMFV will eventually
end with Return Code=12 after a VSAM read I/O error.
You could use the JCL COND parm to test for RC=12 in the
subsequent PDB build, if you want to also terminate the
creation of the RMF III PDB datasets after a VSAM error.
Thanks to Rodger Foreman, TransUnion, USA
Thanks to Betty Wong, Bank of America, USA
Change 30.160 -ASMIMSL7: ASMIMSL6, to bypass 0C7 ABEND due to ARRVDATE
ASMIMSL7 containing invalid Packed Decimal data, by skipping the
ASMIMSL8 0C7'ing-records so the rest of the log can be read. If
Aug 18, 2012 invalid ARRVDATE is found, a new error "NOPD" message
Aug 30, 2012 will be written to the job log with the first 25 bytes of
the record in hex. Since we have added this diagnostic,
no reports of NOPD messages have been reported.
-ASMIMSL8: ASMIMSL7 ABEND 0C4 occurred when an INQUEUE
record had zero record length in the first four bytes, in
a record that was to be discarded due to other errors
(dupe key). This iteration deletes the defective record
without the 0C4 ABEND.
-We have been unable to replicate either the 0C4 or 0C7
condition with files from three runs, so it appears the
source is a corrupted INQUEUE file, and since a VERY
small number of records are being recycled, the safest
solution now would be to eliminate the use of INQUEUE
for a few cycles to confirm that was the culprit, and
then it can be reintroduced while watching the job logs
for MXG error messages, in case the corruption reoccurs.
Change 30.159 Support for Microsoft Exchange 2010 incompatible changes
VMACNTSM to MSEXCHANGEIS and MSEXCHANGEIS MAILBOX objects. Creates
Aug 18, 2012 variables MSIS0001-MSIS0051 MSISCQTH in MSEXCHIS dataset,
and in dataset MSEXCHPU variables MSPU0001-MSPU0074 and
new per-second rate variables MSGDLVPS MSGRECPS MSGSNTPS
MSGSUBPS (whose new per-sec values are also converted to
per-minute and stored in the existing per-minute
variables MSGDLVPM MSGRECPM MSGSNTPM MSGSUBPM).
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 30.158 -VMXGSUM in 30.05 could leave temporary datasets KEEPDATA
VMXGSUM KEEPERS VAR1 VARS or VAR2 in the //WORK library, which
Aug 15, 2012 had no impact on your MXG programs, but as they were also
Sep 4, 2012 left behind in the MXG QA job, they were seen as "real"
MXG datasets and created DOCVER entries.
-New handling of error conditions when interactive: rather
than terminating the SAS Session, global macro MXGOPTKILL
that is set in VMXGOPTK (the macro that drives the keep
logic and is part of VMXGSUM) gracefully shuts down the
VMXGSUM execution but preserves the interactive session.
-Messages about too-long-text were revised.
Change 30.157 New REPORT THREE-A for IMACICEZ, IMACICE1, and IMACICE2
UTILEXCL tailoring members now identifies the number of fields and
Aug 13, 2012 the lengths that must be updated in those three members.
It may be necessary to use the MCTSSDRL field in the DO
groups for these three optional segments.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.156 -Variables TOTLSESS ACTVSESS INACSESS in TERMSERV dataset
EXNTICAS for the Terminal Services object were input in that order
IMACNTSM in Windows Server 2003 (NTVERSN='5.2'). In Windows Server
VMACNTSM 2008-R2 (NTVERSN='6.1') the order was changed to ACTVSESS
VMXGINIT INACSESS TOTLSESS, so now, one of two INPUT statements is
Aug 10, 2012 executed, based on NTVERSN.
-Support for ICA Session object creates ICASESSN dataset.
dddddd dataset description
NTICAS ICASESSN ICA Session
Thanks to ???, ???, ???
Thanks to Mark Friedman, Demand Technology, USA.
Change 30.155 -Support for the WebSphere Asynchronous Section in subtype
EXT1209A nine records creates new TYP1209A dataset
IMAC120 dddddd dataset description
VMAC120 T1209A TYP1209A WebSphere Subtype 9 ASYNC
VMXGINIT These variables in TYP1209A and TYP1209E correspond and
Aug 9, 2012 can be used to compare observations in those datasets:
Oct 16, 2012 TYP1209A TYP1209E
SM1209GP SM1209CG
SM1209GQ SM1209CR
SM1209GR SM1209CS
SM1209GT SM1209CU
SM1209GV SM1209CV
-Unrelated, variable SM1209CX was found to have been
incorrectly divided by 4096, in TYP1209E dataset.
-Oct 16: The August change also corrected variables
SM1209DL, SM1209DM, and SM1209DN service units.
Thanks to Joseph L. Babcock, JPM Chase, USA.
Thanks to Tom Bubnash, SSA, USA.
Thanks to Babatunde Ashiru, SSA, USA.
Thanks to Jim Hare, Shared Services, CANADA.
Change 30.154 Velocity Software ZVPS (a/k/a XAM) new User Record with
EXXAMUSV with USERTYPE='VCPU' creates new dataset:
FORMATS dddddd dataset description
IMACXAM XAMUSV XMUSVCPU Virtual CPU per User Statistics
VMACXAM Dataset XMUSVCPU contains the USEACT and USEINT variables
VMXGINIT plus Virtual CPU Address (VMDCPUAD) and Engine Type in
Aug 9, 2012 VMDPUTYP, decoded by new MGXAMTY format (CP, ZIIP, etc),
so there is one observation for each USERID and VMDCPUAD
for each MONWRITE interval.
Thanks to Patricia Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
====== Changes thru 30.153 were in MXG 30.05 dated Aug 8, 2012=========
Change 30.153 -See Change 30.166. Documentation updated.
VMXGUOW -PROGRAM names PROG1-PROGnn are created (TRAN1-TRANnn),
Aug 8, 2012 with the HOWDEEP= argument (default 10) setting the "nn"
to be created, but you must also use KUOWIDC to list the
variables you want to be kept. You can put the statement
MACRO _KUOWIDC PROG1=PROG9 % in IMACKEEP tailoring, or
use %LET MACKEEP= MACRO _KUOWIDC PROG1-PROG9 %; in SYSIN.
-Documentation of CICS transaction counts:
An observation in CICSTRAN cay be only one of many CICS
"segments" that make up a "unit of work", UOW, a "real"
transaction. Counting the number of observations in the
CICSTRAN dataset does NOT tell you how many actual CICS
Thanks to Charles Savikas, DCF, State of Florida, USA.
"transactions", or "units-of-work" were executed.
MRO trans typically have at least two observations in
the CICSTRAN dataset for a unit of work: one is from
the TOR region/applid and one is from the AOR region.
In ASUMCICS dataset (summarized CICSTRAN), the variable
NUMTRANS is the number of CICSTRAN observations, i.e.,
the inflated count of MRO CICS segments.
In ASUMCICX dataset (summarized ASUMUOW), the variable
NUMTRANS is the number of ASUMUOW observations, i.e.,
the "correct" count of transactions/units-of-work).
In ASUMUOW dataset, (created from CICSTRAN/DB2ACCT/MQ):
MROTRAN - Count of CICSTRAN observations in this UOW,
inflated segment count.
DB2TRAN - Count of DB2ACCT observations in this UOW.
MQTRAN - Count of MQMACCT/MQMACCTQ obs in this UOW.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.152 A strange SAS compiler error, if you used the _KDCODSN
VMACDCOL "KEEP= exit" for dataset DCOLDSET, intending to add some
Aug 6, 2012 new variables and to DROP= some existing variables:
MACRO _KDCODSN NEWVAR1 NEWVAR2 DROP= OLDVAR1 OLDVAR2 %
This compiler error is unique to the VMACDCOL structure,
and is circumvented by relocating the &MXGFILNM macro
variable to a different place in the source code.
-The SAS compiler erroneously expanded that _KDCODSN macro
token TWICE, causing the first instance of DROP= to apply
to all of the NEW variables in the second instance of the
expansion, so NONE of the new variables were kept. This
error was precipitated by Change 29.296, which added a
new-style macro variable token, &MXGFILNM, at the end of
each KEEP= list (so you could add variable INFILENM to
all DCOLLECT datasets). Apparently, even when &MXGFILNM
is blank, when it is the last token before the _KDCODSN
token, then if _KDCODSN is not blank, the SAS old-style
macro compiler expanded that macro token TWICE. But, by
relocating that &MXGFILNM text to a separate line, before
the last variable line in the MACRO _VDCODSN KEEP= list,
so it is no longer immediately prior to _KDCODSN token,
that second unwanted expansion is avoided and your normal
_Kdddddd tailoring works as expected. The error was in
both SAS 9.2 and 9.3 on Windows and z/OS SAS 9.1.3 SP4.
Thanks to Paul Maradin, HP, USA.
====== Changes thru 30.151 were in MXG 30.05 dated Aug 6, 2012=========
Change 30.151 Additional Enhancements for RMF III processing.
VMACRMFV -ZRBASM file was not output to the PDB when TYPSRMFV
Aug 4, 2012 member was used to build an RMF Monitor III PDB.
-Macro call to _SZRBASM was missing from _SRMFV macro.
-_BZRBASM macro for ZRBASM file misspelled ASMJESID
variable as ASIJESID causing SAS error during PDB build.
-Change 27.100 altered the EXZRBLCP macro to conserve disk
space for inactive logical processors by suppressing
output to the ZRBLCP file when LCPUPDTM was zero (which
includes LPARs that are categorized as PHYSICAL).
However, all processor entries for PHYSICAL LPARs are
required to determine the number of physical engines on a
CEC for an engine type such as a ZAAP or ZIIP. One or
more of these can legitimately be inactive during an RMF
III MINTIME interval. The number of physical engines for
each engine type is required to compute Physical % UTIL
as in the RMF III CPC panel. Entries for PHYSICAL
LPARs are now always output regardless of activity.
-Variable SSHRMFVN (RMF version number) added to these MXG
created RMF III "PDB" SAS datasets:
ZRBSVPP, ZRBSVPW, ZRBSVPC, ZRBSVPZ, ZRBSVPR, ZRBSVPG.
-Variable SSHSMPNR (number of valid MINTIME samples) added
to these RMF III PDB datasets:
ZRBGEI, ZRBCFC, ZRBCFI, ZRBCPD, ZRBCPU,
ZRBLCP, ZRBCSR, ZRBDVT, ZRBENC, ZRBENT,
ZRBSHD, ZRBPGP, ZRBRED, ZRBRCDB, ZRBRCDS,
ZRBRCDR, ZRBOPD, ZRBSPG, ZRBSVPP, ZRBSVPW,
ZRBSVPC, ZRBSVPZ, ZRBSVPR, ZRBSVPG, ZRBUWDEV,
ZRBUWSTO, ZRBUWJES, ZRBUWHSM, ZRBUWENQ, ZRBUWMNT,
ZRBUWMSG.
-Variable SSHGOMNT (Gatherer MINTIME option) added to
these RMF III PDB files:
ZRBGEI, ZRBASI, ZRBCFC, ZRBCFI, ZRBCPD,
ZRBCPU, ZRBLCP, ZRBCSR, ZRBDVT, ZRBENC,
ZRBENT, ZRBSHD, ZRBPGP, ZRBRED, ZRBRCDB,
ZRBRCDS, ZRBRCDR, ZRBRCDT, ZRBRCDX, ZRBRCDD,
ZRBOPD, ZRBSPG, ZRBSVPP, ZRBSVPW, ZRBSVPC,
ZRBSVPZ, ZRBSVPR, ZRBSVPG, ZRBUWDEV, ZRBUWSTO,
ZRBUWJES, ZRBUWHSM, ZRBUWENQ, ZRBUWMNT, ZRBUWMSG.
Thanks to Randy Hewitt, HP Canada, Canada
Change 30.150 NDM-CDI record 'EX' caused "UNKNOWN SUBTYPE" log messages
VMACNDM and no DSECT is yet received to decode the 40 bytes of
Aug 3, 2012 hex zeros at the end of the record, but the front end has
the same fields as the NDMDT record so the 'EX' record is
output in NDMDT, pending receipt of documentation.
Thanks to Paul Volpi, UHC, USA.
Change 30.149 The KEEPALL=YES default is used in most MXG code because
VMXGSUM it is usually safer, as it protects if there is an INCODE=
Aug 3, 2012 argument that can reference a variable that is not in one
Aug 7, 2012 of the parameter lists. However, in some invocations of
VMXGSUM, it caused a VARIABLE NOT FOUND error that caused
PROC MEANS to fail, when a variable did not exist, due to
an error in the VMXGSUM logic that only rebuilt the KEEP
list after the first data step when KEEPALL=NO. Now, that
rebuild is always executed with either NO or YES.
-VMXGSUM was redated Aug 7; the above logic was revised.
Thanks to Robert Kirkland, MedMutual, USA.
Change 30.148 The %SYMEXIST() function now detects that macro variable
VMXGINIT MXGSOURC exists ("MXGNAMES" dynamic allocation was used,
Aug 1, 2012 which requires FIXORDER dataset to be created to print
the //SOURCLIB DSNAMEs messages at MXG startup), so the
FIXORDER creation can be bypassed for static allocation.
And FIXORDER is not compressed when it is created, to
suppress a cosmetic warning messages about size increase.
Change 30.147 The DB2 AUDIT reports were reformatted to match reports
ANALDB2R in OMEGAMON XE for DB2 Performance Monitor Version 4.2.
VFMT102 Since the detail and trace formats are essentially the
Jul 31, 2012 same, PMAUD03 now simply invokes PMAUD02.
AUDIT= parameter is expanded to support these options:
DDFTRAN - DDF TRANSLATION .
ESTTRST - Establish Trusted Context
CRTTRST - Create Trusted Context
KERBERO - KERBEROS/ENCRYPTED Connection
Change 30.140 revised VFMT102 to eliminate time; this
change removes the timestamp when VFMT102 is called.
The LINESIZE option is now set to 200 at the beginning
and then reset to the original value at the end of
ANALDB2R, as some of the reports can get very wide.
Thanks to Alyona Bertneski, JPMorgan, USA.
Change 30.146 Cosmetic/maybe. The %DO loop variable &I was changed to
VMXGDSNL the more "unique" &DSNL to possibly avoid conflict with
Jul 31, 2012 user code that was wrapped around VMXGDSNL in TYPEQACS.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 30.145 Variable CORRNAME and CORRNUM were incorrectly decoded
VMACDB2 for QWACATYP=4 (CICS) connections.
Jul 31, 2012
Change 30.144 -If you specified PDBOUT=PDB and asked for specific IFCIDS
READDB2 e.g. IFCIDS=ACCOUNT 105 107 269, the T102Sxxx datasets
Jul 31, 2012 were not copied to the PDBOUT= destination.
-If you used the LDB2xxx parameters to limit the variables
kept or dropped and used the syntax:
LDB2ACC=PDB//KEEP/varlist
the // did not work as documented; a space was required,
but this change now properly supports // or / / as the
null argument.
Change 30.143 -These variables, which should have been a MAX value, were
VMXGDBSS incorrectly summed:
Jul 31, 2012 ASUMDBSS - QB1TVPL QB2TVPL QB3TVPL QB4TVPL QB1TCBA
QB2TCBA QB3TCBA QB4TCBA
ASUMDBSB - QBSTVPL QBSTCBA
They now contain the MAX value of the end-of-interval
values, across each summary interval.
-In addition, because DB2 V10 writes fixed one-minute data
and so those variables are end-of-interval values, these
average value variables are now created:
ASUMDBSS - AVG1VPL AVG2VPL AVGTVPL AVGTVPL AVG1CBA
AVG2CBA AVGTCBA AVGTCBA
ASUMDBSB - AVGTVPL AVGTCBA
-Labels were created for these four variables:
ASUMDBSS - THRDFTPT THRDUSE TOTTHRD
ASUMDBSB - READS
Change 30.142 %VMXGPRNT, which "PROC PRINTs" with both the LABEL and
VMXGPRNT VARIABLE as heading, is enhanced to allow FMTLST= option
Jul 31, 2012 to specify the printed format. See ANAL113 for example.
Change 30.141 -XAM/ZVPS XAMTCP record contains 0.0.0.0 for IPADDR in all
VMACXAM observations as that is what is in the record.
Jul 31, 2012 -Values in AVERAGTM='TOTALTIME/TOTALACKED IN FAL' and the
values in TOTALTIM='TOT ROUND TRIP TIME(MS)' in XMTCPAPP
dataset are large negative values in many records.
-Both problems will be forwarded to the vendor.
-Variable NAMENODE is now kept in XMTCPAPP dataset.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 30.140 -Support for IFCID 269 and 270 populates existing T102S269
FORMATS and T102S270 datasets with QW0269xx/QW0270xx variables.
VFMT102 -Formats created for some QW0269xx/QW0270xx variables.
VMAC102 -VFMT102 revised to eliminate the time values.
Jul 31, 2012 -SQL Text long-variables have multiple blanks removed with
COMPBL function.
Thanks to Alyona Bertneski, JPMorgan, USA.
Change 30.139 The label for PIRSHELF is corrected to "SHELF", which I
VMAC110 now know is a z/OS Unix name for a directory, primarily
Jul 30, 2012 used for Web service binding files.
Thanks to Dale Slaughter, Transamerica, USA.
Change 30.138 ASG TMON/DB2 creates invalid DB2 101 records that causes
VMACDB2H MXG to print ERROR: INVALID DB2 101 RECORD messages, but
Jul 27, 2012 since the ASG records have their header segment at the
Aug 3, 2012 start of the record, whereas IBM's header segment is at
the end of the record, I've updated these error messages
to identify "ASG-CREATED" and to identify the ASG fix of
TE03737 in the error messages. These records are DELETED.
Change 30.023 detected these errors, but printed ALL of
the defective records; this change limits printing to 3.
Thanks to Marty Pruden, Purina Nestle, USA.
Change 30.137 Updates to NMON/TOPAS Monitor for AIX and LINUX.
EXNMONDF -All BBBP single-value-per-line configuration entries for
EXNMONEN the lsconf, lparstat, lsattr EL, vmstat V, and vmstat S
EXNMONLP subtypes are now output in NMONBBBP dataset. All labels
EXNMONMP now contain the subtype name. Variables from each subtype
EXNMONVM are grouped in the LABEL statement so they are adjacent
IMACNMON when printed. Variables BBBP001-BBBP0146 now exist.
VMACNMON -These "BBBP,ending" multi-value-per-line entries are
VMXGINIT output in these new datasets:
Jul 28, 2012 DDDDDD DATASET DESCRIPTION
Aug 17, 2012 NMONDF NMONBBBPENDDF BBBP,ending df m
Sep 13, 2012 NMONLP NMONBBBPENDLP BBBP,ending lparstat h
NMONMP NMONBBBPENDMP BBBP,ending mpstat d
NMONVM NMONBBBPENDVM BBBP,ending vmstat i
-The "BBBP,ending" single-value-per-line entries from the
"ending vmstat v" and "ending vmstat s" subtypes are
output in this new dataset:
DDDDDD DATASET DESCRIPTION
NMONDF NMONBBBPENDING BBBP,ending vmstat v and s
-Entries PCPUnn and SCPUnn create TEMPCPUNP and TEMPCPUNS
that are merged into existing NMONCPUD, detail CPU
metrics by CPUNR.
-Entries PCPU_ALL and SCPU_ALL_ are input and variables
retained and added to NMONINTV.
-Entries DISKRIO, DISKWIO, DISKAVGRIO, DISKAVGWIO are now
supported, and variables of the same name are added to
the NMONDISK dataset.
-The internal logic for the DISKxxxxN "suffixed" records,
written when there are more disk devices than will fit on
a single record, is restructured to use a 2-elment array
instead of a separate explicit DO group for each suffix.
These arrays support 50 suffixed records with 512 devices
per record, versus the original fixed 21 suffixes.
-ERROR: ARRAY Subscript Out Of Range - DISKSERV DISKSVCTM
DISKWAIT DISKWAITTM objects corrected, and protection for
"NANQ" text for "not a number" for BBBPENDLP04, Aug 17.
-Sep 13: BBBPENDVM05 increased to 64 bytes.
Change 30.136 These TYPE50 OSA/Express READ variables (ATTCHTYP=4 only)
VMAC50 TY50PCIR TY50PCIV TY50PCIT TY50PCIU TY50PDFR
Jul 25, 2012 are missing if SUBCHPOL is not 'READ'; IBM had changed
the value to "RD/n" without documentation. The MXG test
is now revised to detect READ if SUBCHPOL starts with RD.
Thanks to John McLaughlin, Bank of America, USA.
Change 30.135 %VGETALOC is a new macro for use with AUTOALOC=YES (that
VGETALOC VMXGALOC option creates directory names containing date)
Jul 24, 2012 that lets you select (getdaterange=,typeofdata=) a group
of "PDBs"/directories that are to be read, constructing
a "SET" statement in a DATA-step using VMXGSET.
For example:
%vgetaloc(getdaterange=01jul12 24jul12,
typeofdata=daily,
basedir=c:\mxg,
datefmt=date7.
);
data jobs;
%vmxgset(dataset=jobs);
will search the c:\mxg directory for all directories with
a name that contains a date in ddmmmyy format, selects
those with date between 01Jul12 and 24Jul12 inclusive,
and allocates them as PDB1- PDB24 as there are 24 dates
in your selection criteria. These libnames are passed to
VMXGSET which build the logical SET statement to read all
24 LIBNAMEs for the JOBS dataset you requested in VMXGSET
set pdb1.jobs pdb2.jobs pdb3.jobs ... pdb24.jobs;
(i.e., the number of libnames found by vgetaloc).
Change 30.134 Cosmetic/Spurious. ANALDB2R printed note from VMXGVERS
ANALDB2R that you were using a backlevel ANALDB2R, because that
Jul 24, 2012 statement at the bottom of ANALDB2R still had 30.02 in
both 30.03 and 30.04. While the MXG QA stream has a test
for VMXGVERS value, the line was in lower case and the QA
test expected upper case. Now, the QA test looks first
for lower case and then for version number.
Since there is a %PUT with the ANALDB2R last update date,
the currency of this ANALDB2R member was confirmed on the
SAS log, so this was only a cosmetic error. But it gets
this change text because the user had to waste his time
to report the potential problem due to my error!
Thanks to R. van der Zande, KLM, THE NETHERLANDS.
Change 30.133 Support for (optional) DB2 Netezza for Accelerator data.
IMACDBNZ IBM DB2 Analytics Accelerator IDAA product uses Netezza.
VMACDB2 -Similar to MXG support for optional CICS data segments,
Jul 23, 2012 support for optional Q8AC DB2 Accounting variables is in
a comment block in the new IMACDBNZ member that contains
the code, labels, and formats, so none of the Netezza
variables will exist in DB2ACCT, until you copy IMACDBNZ
into your "USERID.SOURCLIB tailoring library and then
remove that comment block.
-Because the volume of DB2 statistics records is small,
the Netezza Q8ST DB2 Statistics variables are created in
the DB2STATS dataset (so you can tell if the Netezza APAR
PM50434 has been installed!) as well as in DB2NETZA.
-See Change 30.229.
Thanks to Jan Tielmans, KBC, BELGIUM.
Thanks to Christa Neven, KBC, BELGIUM.
Change 30.132 Corrections to SMF 21 calculations for compression ratios
VMAC21 and circumvention for records with byte count fields that
Jul 22, 2012 unexpectedly contain zeros. When the compressed bytes in
Aug 7, 2012 SMF21MDR or SMF21MDW are zero, the compression ratio can
not be calculated. In some records, uncompressed bytes in
SMF21BR/DBR/MCR and SMF21BW/DBW/MCW are zero, which also
caused confusion as to which variable should be used.
This was circumvented by calculating the uncompressed
byte counts as:
BYTEREAD=MAX(BYTEREAD,SMF21DBR,SMF21MCR,0);
BYTEWRIT=MAX(BYTEWRIT,SMF21DBW,SMF21MCW,0);
and using those values as the numerator of SMF21CRR/CRW,
when SMF21MDR/SMF21MDW are nonzero.
A problem is opened with IBM to understand the zeroes.
-Aug 7: Variable OPEN is always blank may not be new.
Sites have DCBOFLG='00'X in ID=21 SMF records, but the
ID=14/15 DCBOFLGS field is valid. The 14/15 is written
at z/OS CLOSE, but your CA-1/RMM/TLMS tape management
product still owns the DCB, so they may be clearing the
DCB byte before the type 21 record is written (which can
be HOURS later than the CLOSE event). The type 21 write
only copies control block values with no logic/changes.
In TYPE21 DCBOFLG is only used to populate variable OPEN
with INPUT or OUTPUT, so now, the BYTEWRIT and BYTEREAD
counts are compared and OPEN is populated based on the
larger of the two values. Zero or equal will blank OPEN.
Thanks to Scott Barry, SBBWorks Inc, USA.
Thanks to Michael Creech, Lender Processing Services, USA.
Change 30.131 Two new parameters are added to enhance VMXGALOC:
VMXGALOC READONLY - if set to YES the code that deletes old
BLDSMPDB directories is suppressed.
IMACINIT CLEARALL - if set to YES, ALL previously allocated
Jul 22, 2012 LIBNAMEs are cleared. YES is the default.
Sep 16, 2012
With these changes, you can do reporting for multiple
days/weeks in a single SAS session.
Examples:
-To run reports based on today's runs:
%VMXGALOC(BASEDIR=xxx,READONLY=YES,CLEARALL=YES,
TRENDING=DAILY);
which allocates all of the current LIBNAMES that were
created with today's run, then you can run your reports.
-To go back to an earlier date, like June 11, 2012:
%VMXGALOC(BASEDIR=xxx,READONLY=YES,CLEARALL=YES,
TRENDING=DAILY,FORCEDAY=11JUN12);
which clears all of "todays" allocation and the correct
LIBNAMEs for June 11, are then allocated.
FORCEDAY will now accept a relative number of days as
TODAY()-NN where NN is the number of days to go back.
BLDSMPDB - z/OS only, if you asked to WTD or MTD and also
asked to use WEEKTAPE or MNTHTAPE, an ABEND will now be
generated since this structure is not supported by the
sequential engine on z/OS. Also, if you were running WTD,
BLDSMPDB incorrectly tried to start the week one day too
early; that has been corrected. No data was lost but the
data may not have been in the week where you expected to
find it for the first day of the week.
IMACINIT - applies only if you are running BLDSMPDB with
AUTOALOC=YES. A new example VMXGALOC invocation is in
comments in the IMACINIT member. Copy IMACINIT into your
"USERID.SOURCLIB" tailoring library, REMOVE the comments
around that VMXGALOC invocation, EDIT it to match your
BLDSMPDB arguments, and then, since IMACINIT is always
invoked at MXG startup, all of these "PDB" LIBNAMEs
PDB MON TUE WED THU FRI SAT SUN SPIN
WEEK1-WEEK5 MONTH TREND SPIN CICSTRAN DB2ACCT
will always be allocated.
-Sep 16: Comments updated, no code was changed.
Thanks to Mynard Holloway, Spectrum Health, USA.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 30.130 -EXITCICS Version 3 correctly decompresses DB2 compressed
EXITCICS SMF records (which version 1 didn't always do), continues
Jul 19, 2012 to also decompress CICS SMF records, and this version no
Aug 4, 2012 longer needs the IBM CICS macro library for the assembly.
-EXITCICS is the z/OS ASM source code and ASM/LKED steps
that create the CICSIFUE "Infile Exit" load module that
decompresses DB2 V10 and/or CICS/TS 3.2+ compressed SMF
records. It has never failed for CICS records, and while
many DB2 sites have used it successfully, a small number
of DB2 sites had errors reading compressed records; those
errors are corrected in this updated EXITCICS member. The
complete instructions for creating and installing the
exit are in the comments in the EXITCICS member.
-Version 2 briefly existed and it corrected the DB2 errors
but it still needed the DFHSMFDS macro.
Thanks to Richard Anderson, SAS z/OS Technical Support CARY, USA.
Change 30.129 Support for new zNEXT CPU MF counters EXTEND157-EXTND207
ASUM113 and revised calculations for all of the formulas.
VMAC113 There were 48 EXTEND counters initially and now there are
Jul 20, 2012 80 EXTEND counters, thru EXTND207.
Aug 31, 2012 -Calculations updated from JP Burg's August 29 2012 text.
Sep 17, 2012 -Corrections made Sep 17:
Oct 9, 2012 1. Line 271 in VMAC113 was missing the 0.65.
2. Labels in VMAC113 for EXTND159-162 are now L4 vs L$.
3. The 151- and 148= typos in both ASUM113 and VMAC113
for the MEMP calculation are corrected.
4. The LPBUSY in ASUM113 was changed to LPARBUSY; LPBUSY
is the variable in VMAC113 but it's LPARBUSY in
ASUM113 as documented in Change 28.226.
Oct 9 update:
-Labels for the EXTNDnnn counters were revised based on
SA23-2261-02. Note that there are three sets of labels
for the z/10, z/196 and z/114, and the zEC12, but SAS can
only use the last label for a variable, the active labels
are now for the zEC12, but the other labels can be seen
in the VMAC113 LABEL statement.
-z/EC12 only defines counters thru counter 179, but MXG
was misled to create counters up to 207, but since they
will likely exist sometime, variables thru EXTND207 are
created by this change, IN 30.05 AND REQUIRED FOR z/EC12
processors - an "ARRAY SUBSCRIPT OUT OF RANGE" error will
occur without this change.
Change 30.128 -DB2 V10 changed the QPACFLGS bit map; variables QPACDBRM
VMACDB2 and QPACPACK no longer exist (so they are always blank in
Jul 16, 2012 QWHSRELN GE 10 observations), and new flag variable, only
in Version 10 and later are created and populated:
Variable Label from QPACFLGS
QPACROLL='THIS IS A*ROLLUP*QPAC?' 01X bit
QPACRUSM='THIS IS A*SUMMARY*ROLLUP*QPAC?' 02X bit
-Documented in DB2 Macro Library member DSNDQWAS:
If QPACROLL is on, the Package Record contains ONLY
the QPKG and QPAC segments, but the QXPK, QBAX and QTXA
segments do not exist, so a ROLLUP record will always
have missing values for these SQL/DML QXPK variables
QPSELECT QPINSRT QPUPDTE QPDELET QPDESC QPPREP
QPOPEN QPCLOSE QPFETCH QPLOCK QPCALL
and QBAC and QTXA fields will also be missing values in
the DB2ACCTP dataset.
-Documented in DB2 Macro Library member DSNDQPAC:
If QPACRUSM = ON, the following fields are invalid:
QPACCRNT QPACINSP QPACPAC QPACPKNM QPACCOLN QPACPKID
QPACCONT QPACSCB QPACSCE QPACBJST QPACEJST QPACASCH
QPACAANM QPACAAFG
IF QPACRUSM = OFF, the following fields are invalid:
QPACCRNT QPACPAC QPACSCB QPACSCE QPACBJST QPACEJST
IF QPACRUSM = OFF, the following fields are the last
non-zero value for a thread rolling data into this QPAC
QPACASCH QPACAANM QPACAAFG
Thanks to Jane Stock, USPS, USA.
Change 30.127 Variable BLKSIZE was missing when SMF21LB bit was not on.
VMAC21
Jul 13, 2012
Change 30.126 Selection of data by a range of explicit DATE values did
ANALGRID not work, but all of the keywords for date selection were
Jul 12, 2012 correct.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 30.125 Variable UMLRECL in dataset DCOLMIGS, LRECL of the
VMACDCOL migrated dataset, is now INPUT and kept. It was
Jul 10, 2012 added by z/OS 1.12 but overlooked.
Thanks to Brian Harvey, HCL America, USA.
====== Changes thru 30.124 were in MXG 30.04 dated Jul 4, 2012=========
Change 30.124 z/VM variable VMDFLREO should not have been divided by
VMACVMXA DELTATM (which is normally 60 seconds, so the values in
Jul 3, 2012 VMDFLREO were 1/60th, or 1/DELTATM too small).
Thanks to Sam Bass, McLane Company, USA.
Change 30.123 -Change 28.226 noted that TYPE113 variable SM113CPT is
VMAC113 only populated if SM113VN2 GE 2 (i.e., z196 or later) but
VMAC7072 that change did not note that as a result, SMF70CIN is
Jul 3, 2012 also blank when SM113VN2 is not 2. However, if both 113
and RMF 70 records are processed together, (or as long as
PDB.TYPE70PR exists when ASUM113 is executed), then the
merge of the 70 data with the 113 data will populate both
SMF70CIN and SM113VN2.
-In investigating the above, TYPE113 variable DELTATM was
found to sometimes be too small; MXG must calculate the
interval duration from adjacent records because IBM does
not create it, and the incorrect use of FLOOR(DIF(x)) was
found to be the culprit; DELTATM is now correct but is no
longer "made pretty" with an integer value. The small
value for DELTATM caused both the count in LPARCPUS to be
grossly wrong in some cases (12 vs 2!) and LPBUSY could
also be incorrect.
-But, "valid" small values of DELTATM have been observed
in some as-yet-not-fully-understood cases where SMF 113
records are written extremely close in time. While the
deaccumulated counters look to be correct in these cases,
as they are not full intervals, I recommend that all of
your observations in PDB.ASUM113 that have DELTATM less
than the expected interval duration (e.g., DELTATM LT 890
if the expected data is 15 minute interval) be deleted
before you analyze the HIS data. USE TYPS113E vs TYPS113.
-VMAC7072: Cosmetic. Change 30.106 typo in the LABEL for
ZIPSHARE caused UNINIT VARIABLE ZPTSHARE that is fixed.
Thanks to Roger Lowe, Northern Territory Government, AUSTRALIA
====== Changes thru 30.122 were in MXG 30.04 dated Jul 4, 2012=========
Change 30.122 NRECORD=MAX generated an error; the code was looking for
VMXGGETM a null value but now accepts MAX and either null or MAX
Jul 2, 2012 will set the counter to the value of MXGOBS.
Change 30.121 Enhancements/Additions to $MG119xx FORMATS for TYPE119.
FORMATS New formats $MG119CI $MG119CO $MG119MA $MG119MO $MG119TY
VMAC119 are created and assigned to appropriate variables. Some
Jun 29, 2012 old formats $MG119AM $MG119CC $MG119PL $MG119ST $MG119RF
were defined, but not assigned to all variables. Formats
$MG119CC and $MG119PL are identical, but as they were
assigned separately to different variables, they have to
be kept in FORMATS. $MG119FA and $MG119RF were also
identical, but neither was assigned so $MG119FA has been
removed from FORMATS.
Thanks to Martyn Jones, Deutsch Bank, GERMANY.
Change 30.120 Support for RACF Database Record 02G1 creates RACF02G1
EXRAC2G1 dataset with Custom User Data.
IMACRACF
VMACRACF
VMXGINIT
Jun 28, 2012
Thanks to Steve Carlson, Univ of California Office of President, USA.
Change 30.119 Support for APAR OA39629 adds two variables to SMF 30
BUILD005 subtypes 2,3,4,5 (kept in TYPE30_V/TYPE30_4/TYE30_5 and
BUIL3005 in PDB.SMFINTRV, PDB.STEPS and PDB.JOBS datasets):
VMAC30 HICPUPCT='HIGH*TASK*CPU*PECENT'
Jun 28, 2012 -For interval records, the largest percentage of CPU
time used by any task in this address space, rounded
to the nearest integer. A value of 25 indicates that
the most CPU intensive task in this address space was
dispatched on a physical processor for 25% of the SMF
interval time.
-For step-end, the value is the largest reported
interval if the step crosses an interval boundary.
-For job-end, the value is the largest reported
interval value for any step.
-The percentage value in the record is calculates as:
TCB time * 100/ interval time.
HICPUPGM='HIGH*TASK*PROGRAM*NAME'
-Program name running in the task that used the largest
percentage of CPU time in this address space. This
field corresponds to HICPUPCT.
-A value of blanks indicates that no task reported any
CPU time in the address space, or that the CPU time
could not be obtained.
-A value of '????????' indicates that the program name
could not be obtained for the task that reported the
highest percentage of CPU time.
-Additional information from IBM in the APAR text:
-These new fields are intended to identify the
largest consuming task when multiple tasks are
active in an address space. One may compute the
address space task percentage from existing fields
in the SMF 30 record but one has no insight
currently into usage within the address space. If
the total CPU percentage is on the order of 50%, the
task may struggle to be served well particularly if
it has a mediocre dispatching priority or the system
is running in horizontal mode (HiperDispatch not
enabled). If the address space percentage is 50% and
the largest task percentage is 15%, there is little
concern that the task will be unable to progress as
long as it is properly classified in WLM.
-IBM will provide guidance to our customers that
establishing a list of candidates to monitor and
determining any increase in percent dispatched for
the evolving list over time (perhaps every six to
twelve months) should be part of the capacity
planning process. Our current recommendation is to
take note of address spaces with programs that are
dispatched at least 25% of an interval for intervals
of at least 5 minutes.
Change 30.118 Unused Change Number.
Change 30.117 Documentation of MXG internal syntax. The example code
UDDDDDD in VMACXXXX shows this syntax for the dataset label
UTILVREF (LABEL='dddddd: description of dataset'
VMACXXXX but it was never documented that the "dddddd" token in
Jun 25, 2012 the label can NOT contain a blank (a blank causes the
UDDDDDD program to fail building $MGDDDDD and $MGDDDSN
formats). A comment was added in the VMACXXXX example,
test for a blank was added to both UDDDDDD and UTILVREF,
but as these programs are ONLY used internally during the
MXG QA process to create documentation, these errors
won't be observed by MXG users.
Change 30.116 Support for Voltage SecureData for z/OS z/Protect SMF.
EXZPR01 These new datasets are created:
EXZPR02
EXZPR03 DDDDDD MXG MXG
EXZPR04 DATASET DATASET DATASET
EXZPR05 SUFFIX NAME LABEL
EXZPR16
FORMATS ZPR01 ZPRO01 ZPR01: Z/PROTECT DISPATCHER STARTUP
IMACZPRO ZPR02 ZPRO02 ZPR03: Z/PROTECT SHUTDOWN EVENT
TYPEZPRO ZPR03 ZPRO03 ZPR03: Z/PROTECT OPERATOR COMMAND EVENT
TYPSZPRO ZPR04 ZPRO04 ZPR04: Z/PROTECT ABEND EVENT
VMACZPRO ZPR05 ZPRO05 ZPR05: Z/PROTECT RAW OPERATION DATA
VMXGINIT ZPR16 ZPRO16 ZPR16: Z/PROTECT INTERVAL AGGREGATIONS
Jun 30, 2012 In dataset ZPRO16, variable ZPRTTYPE identifies which of
the seven possible aggregates is reported:
1='1:OVERALL TOTALS'
2='2:TOTALS BY USER'
3='3:TOTALS BY CRYPTID'
4='4:TOTALS BY JOBNAME'
5='5:TOTALS BY USERID AND CRYPTID'
6='6:TOTALS BY JOBNAME AND CRYPTID'
7='7:TOTALS BY USERID AND JOBNAME'
Change 30.115 -VMXGRMFI - The TRENDING section of VMXGRMFI now uses
ADOCTRND VGETWKLD to ensure that all workloads, old and new, are
GRAFTRND preserved. This allows you to add new workloads but then
GRAFWRKX remove or rename old workloads, while preserving your
MNTHRMFI historical data for the old workloads that may no longer
TRNDRMFI exist in RMFINTRV, but will still exist in TRNDRMFI.
UTILBLDP -VGETWKLD - Now will get the workload names, labels and
UTILCPLG periods for use in VMXGRMFI from multiple sources. New
VGETWKLD parameter datasets lets you specify as many datasets for
VMXGALOC input as may be needed, but the purpose is to allow the
VMXGRMFI specification of DATASETS=WORK.RMFINTRV TREND.TRNDRMFI so
Jun 21, 2012 that if you have added or deleted or renamed workloads,
Jun 26, 2012 the old ones in TREND will be carried forward, rather
Jul 2, 2012 than being dropped. New design is also used in GRAFWRKX,
but this is intended for internal MXG usage.
-ADOCTRND - New documentation section 4 showing how to
backload past RMFINTRV data into TRNDRMFI.
-GRAFTRND now is only an invocation of GRAFWRKX with
appropriate arguments.
-GRAFWRKX - sort order for TRNDRMFI was incompatible with
the SORT order for GRAFWRKX so a PROC SORT was added.
-MNTHRMFI now is only an invocation of VMXGRMFI with
appropriate arguments.
-TRNDRMFI now is only an invocation of VMXGRMFI with
appropriate arguments.
-TRNDRMFN now is only an invocation of VMXGRMFI with
appropriate arguments.
-UTILBLDP - COSMETIC ONLY - realign code to make it easier
to understand
-UTILCPLG - did not correctly parse out the LOG/LIST names
and if not preceded by a RUN; statement it could execute
at unexpected times because of timing issues in the macro
language.
If the directory pointed to did not contain a \ or a /
(os dependent) it was not added and could result in an
error during the copy process.
-VMXGALOC - If you specified FIRSTRUN=YES and also were
trying to run with WTD processing, the allocation of the
WEEK libname for the current week did not happen.
Thanks to Mynard Holloway, Spectrum Health
Change 30.114 SAS User SMF Records with SASPROC='SQL (63)', 'APPEND ('
VMACSASU values were unexpected (and unknown to SAS Support) and
Jun 19, 2011 caused SASPROD='UNKNOWN'. Now, the paren is detected and
only the SAS Procedure text name is stored in SASPROC, so
the SASPROD will be "known".
Thanks to Erling Andersen, SMT, DENMARK.
Change 30.113 -DB2 V10 restructured the DB2STATS (100-1) QIST segment,
VMACDB2 but this was overlooked (perhaps because there are no
Jun 19, 2011 vertical change bars in IBM DB2 DSECTS!) causing invalid
values for QIST variables. The restructure removed these
QIST variables so they will have missing value in V10:
QISTWFMU QISTWFCU QISTWFCK QISTWFMX QISTWF04 QISTW04K
QISTWF32 QISTW32T
and V10 created these new variables in PDB.DB2STATS:
QISTIMAC QISTIMSC QISTIMAH QISTIMSH QISTSIAC QISTSISC
QISTSIAH QISTSISH QISTWFRHIG QISTWFRCUR
-In validating this change, these QIST and QISE variables
should not have been deaccumulated:
QISTWCTO QISTW32K QISTW4K
QISEDLRU QISESQCA QISESQKB QISESQKA QISESQCB QISEKSPG
QISEKSPA
The IBM DB2 DSECTs don't always identify which fields are
accumulated; only actual data driven thru the DIF() logic
will prove or disprove field contents (a negative value
or 4x10**9 value prove the field is NOT accumulated), so
data with non-zero values are required to validate MXG.
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Valerie J. Chisholm, Aetna, USA.
Change 30.112 -Thruput Manager datasets TPM16S and TPM16J, variables
VMACTPMX TPMAJCT and TPMSCT were too large by 100; they were INPUT
Jun 19, 2012 as PIB4. but are now input as PIB4.2.
-In addition, TPMAJCT in TYPE16S is an accumulated value,
but the value in TPMSCT will be the step value (with PTF
TMT6218) so there is no real need to deaccumulatate
TPMAJCT to get the individual step CPU time in TPMSCT.
However, now realizing TPMAJCT is accumulated, if you use
TYPSTPMX or _STPM16S to sort dataset TPM16S, this change
will deaccumulate TPMAJCT, and the TPM16S label will
indicate that its value is deaccumulated.
Change 30.111 RACF TYPE801 debugging PUT 'DEBUG 1' was not disabled.
VMAC80A
Jun 19, 2012
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Thanks to Jens Mohring, Huk-Coburg, GERMANY.
Change 30.110 Only Windows PERFMON data that was comma-delimited was
VMACWPMO correctly decoded; a hard-coded ',' is now &DLMWPMO so
Jun 17, 2012 that your delimiter is always used in parsing text.
Thanks to Florent Boulesteix Inovans, Ca-Caagis, FRANCE.
Change 30.109 Support for Mainview CICS v64 CICS/TS 4.2 (COMPATIBLE).
EXMVCICP -New variables added to dataset CMRDETL dataset:
IMACMVCI T6ERSFLG1 T6ERSFLG2 T6ERSFNCNT T6E67ID T6E67XCT
VMACMVCI T6EECSEC T6EPHNWD T6EPHAPL T6EPHATT T6EPHTSN T6EPHTID
VMXGINIT T6EPHCNT T6EADPID T6EADPD1 T6EADPD2 T6EADPD3
Jun 16, 2012 -New dataset decoded for File Segment for PROGRAM:
dddddd dataset description
MVCICP CMRFPROG MAINVIEW CICS FILE PROGRAM
Change 30.108 Reading RMM EDGS records on ASCII caused INPUT STATEMENT
VMACEDGS EXCEEDED RECORD LENGTH error if MORTYPE='FFFFFFFFFF'X.
Jun 15, 2012 The $EBCDIC8 input set the value '000000000000'X, so now
a separate input with $CHAR8 is used for those tests.
Thanks to Rick Raiton, US Airways, USA.
Change 30.107 Support for ASG/Landmark TMON DB2 PTFs TE03699/TE03718
EXTMD2XB which add segments to the PK, TB, and TG records creating
EXTMD2XG these three new datasets:
EXTMD2XK DDDDDD Dataset Description
IMACTMD2 TMD2XK TMD2PKS Thread Package Accounting Segments
VMACTMD2 TMD2XB TMD2TBS Thread BP Accounting Segments
VMXGINIT TMD2XG TMD2TGS Thread GBP Accounting Segments
Jun 10, 2012
Change 30.106 zIIP SHARE WEIGHTS are now calculated for each LPAR in
VMAC7072 all four datasets created by ASUM70PR.
VMXG70PR -For the ASUM70PR and ASUMCEC datasets, with different
Jun 9, 2012 variable names for each LPAR, the variable names are
LPnZHARC ='LPAR n*ZIP SHARE*CURRENT*WEIGHT*PCT'
LPnZHARE ='LPAR n*ZIP SHARE*INITIAL*WEIGHT*PCT'
-For the ASUM70LP and ASUMCELP datasets, with only one
set of variables, the names are:
ZIPSHARE='ZIP*INITIAL*SHARE*WEIGHT'
ZIPSHARC='ZIP*CURRENT*SHARE*WEIGHT'
Since SMF70ACS is currently always zero for zIIPs, the
two variables have the same value, but logic is in place
that will use SMF70ACS if it is non-zero.
Thanks to Rodger Foreman, TransUnion Corp, USA.
Thanks to Lindholm Orjan, VOLVO, SWEDEN.
Change 30.105 Support for RMF III ASIG3 segments with '13'x and '14'x
ASMRMFV segment level that is undocumented and added 376 bytes.
VMACRMFV This caused MXG variables for Service Class, Report
Jun 8, 2012 Class, Workload, and Resource Group data extensions to be
invalid.
-ASMRMFV space message RMFV030I could have invalid values
for HARBA, HURBA, and AVAIL fields when the input RMF
Monitor III VSAM data set was non-EF and exceeded 2 GB in
size. Subsequent message RMFV031I would have invalid
percentages for USED and AVAIL fields possibly exceeding
100 percent. NOTE: Assembly and link-edit of ASMRMFV is
optional for MXG users with only EF RMF III VSAM data
sets or only non-EF data sets not exceeding 2 GB in size.
Otherwise, reinstall of ASMRMFV is strongly recommended
to resolve this issue. o Warren Cravey, Fidelity
Thanks to Warren Cravey, Fidelity, USA.
Change 30.104 -Variable SMF70CIN in TYPE70EN was incorrectly set to the
VMAC7072 value 'ZIP', but that is now SMF70CIN='IIP', consistent
Jun 8, 2012 with SMF70CIN in other MXG datasets.
-For zIIP engines, in dataset PDB.TYPE70PR, the variable
NEWWAIT contains the CPUWAITM for SMF70CIN='IIP'.
-In PDB.TYPE70EN, variable CPUWAITM is valid for CP and
IIP engine's wait time.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 30.103 -Support for z/OS 1.13-added (COMPAT) RAS (Reliability,
VMAC1415 Availability, Serviceability) segment adds flag variables
Jun 5, 2012 that are $HEX2. formatted. Because I don't expect these
new variables to be of great import, separate bit-level
variables aren't created, but these are the values:
SMF14RFG0
'1.......'B='DCBE reject flags present'
'.1......'B='PARTREL flags present'
SMF14RASDATA0
'1.......'B='DCBE invalidated because EXCP and no
foundation extension present.
'.1......'B='DCBE invalidated because DSORG is not PS,
PO OR DA.
'..1.....'B='DCBE invalidated because storage is not
addressable.
'...1....'B='DCBE invalidated because DCBE storage is
not in key of caller.
'....1...'B='DCBE invalidated because the DCBEID is not
'DCBE'.
'.....1..'B='DCBE invalidated because it is not at least
the minimum length required (56 bytes)
'......1.'B='DCBEHIARC flags set but DCBDCBE is zeros.
SMF14RASDATA1
'1.......'0=Partial release not called by CLOSE because
VIO data set
'.1......'1=Partial release not called by CLOSE because
task is abending.
'..1.....'2=Partial release not called by CLOSE because
not opened for output
'...1....'3=Partial release not called by CLOSE because
EXCP DCB but no direct access device section
present.
'....1...'4=Partial release not called by CLOSE because
even though opened for output, last I/O was
not output
'.....1..'5=Partial release had an I/O error
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.102 These DB2xxxxx variables were not MGBYTES formatted, and
VMACDB2 had incorrect labels.
Jun 5, 2012 NDB2STOR ALLOWSTR THRDUSE QWOSDRSU QWOSDVSU
Thanks to Robert M. Dahlia, SunTrust, USA.
Change 30.101 The TITLE7 statement was repeated, so the title line that
ANALDDCN should have reported duplicate bytes DUPBYTES was not
Jun 4, 2012 printed.
Thanks to Tom White, Dell, USA.
Change 30.100 UTILEXCL in MXG 30.03 was defective and the IMACEXCL that
UTILEXCL it created did not input JMVTIMCN which caused errors,
Jun 4, 2012 usually the "NON-FIRST-TRANSACTION RECORD NUMBER" error.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.099 Support for CO:Z SMF 119 Subtypes 192 and 193 records.
EXT119X2 Four new datasets are created:
EXT119X3 DDDDDD DATASET DESCRIPTION
EXT119M2 T119X2 TY119192 CO:Z SFTP SERVER LOG
EXT119M3 T119M2 TY119M92 CO:Z SFTP SERVER LOG MESSAGES
IMAC119 T119X3 TY119193 CO:Z SFTP CLIENT LOG
VMAC119 T119M3 TY119M93 CO:Z SFTP CLIENT LOG MESSAGES
VMXGINIT Jun 18: RACFUSER added to KEEP for T119M2/T119M3 as it is
Jun 3, 2012 in the BY list for both datasets.
Jun 18, 2012
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 30.098 New fields added to DCOLLECT BKUP records (COMPATIBLY) by
VMACDCOL z/OS 1.11 are now created in DCOLBKUP dataset:
Jun 2, 2012 UBLFS ='LARGE*FORMAT*SEQ*DATASET?'
UBNEWNM='NEWNAME*SPECIFIED?'
UBF_RETAIN_SPCD='RETAIN*SPECIFIED?'
UBF_NEVER_EXP='NEVER*EXPIRE?'
UB_RETAINDAYS='SPECIFIED*RETAINDAYS*VALUE'
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.097 Velocity Software XAMCPUTO dataset contains totals, but
VMACXAM did not contain a count of CPUS. Variable NRCPUS is now
Jun 2, 2012 created, and forced to be an integer using
NRCPUS=FLOOR(0.1+(DURATM/(STOPTIME-STARTIME)));
Thanks to Andrew Petersen, CSC, AUSTRALIA.
====== Changes thru 30.096 were in MXG 30.03 dated May 30, 2012=========
Change 30.096 Support for ZEN OSA MONITOR PTF ZOM1322 that INCOMPATIBLY
VMACZOSA increased the length of ZOSALINK from 13 to 17 bytes.
May 29, 2012
Jun 1, 2012
Change 30.095 RMF III Enhancements.
ASMRMFV -A new table called MXG is now created which contains
VMACRMFV ASMRMFV assembly and execution data. The MXG table is
EXZRBASM created internally by ASMRMFV and is not a true RMF
VMXGINIT Monitor III table. The MXG table contains 49 variables
May 29, 2012 that describe both the assembly and the execution
environment of ASMRMFV. This data can be used either as
an audit trail or as a problem diagnostic aid. VMACRMFV
can also use this data for conditional logic decisions.
Only 1 MXG table observation will appear in the new
ZRBASM file for each run of ASMRMFV, so there is minimal
overhead.
-Two new extensions are added by ASMRMFV to the ASI
(address space) and ENC (enclave) table records with
WORKLOAD and RESOURCE GROUP information. These are in
addition to existing extensions for SERVICE CLASS and
REPORT CLASS data. VMACRMFV adds a total of 14
variables for this new information to the ZRBASI and
ZRBENC files.
-New ZRBASI variables are: ASIWNM ASIWDE ASIGNM ASIGDE
ASIGMN ASIGMX ASIGLT.
-New ZRBENC variables are: ENCWNM ENCWDE ENCGNM ENCGDE
ENCGMN ENCGMX ENCGLT.
-All ASMRMFV added data extensions now only include the
part of the information that is actually documented. In
some cases internal control block values specified a much
greater length and caused problems in VMACRMFV.
-ASMRMFV message RMFV000I now contains information on the
environment at the time of assembly.
-ASMRMFV message RMFV001I now contains information on the
environment at the time of execution.
-Corrected ASMRMFV comments to note that the optional
RMFFILT output data set can NOT be used as input to a MXG
PDB build. RMFFILT does not contain any DSH or SSH
records that would be needed.
-ASI table data extensions for very old releases of RMF
Monitor III V4.3.0 or below (pre 1994) will no longer be
attempted by ASMRMFV. ASI table data will still be
output but without the extensions in this case. The
header structure of these ancient records is not
compatible with the data extension process.
-Corrected a problem where SERVICE CLASS or REPORT CLASS
extensions for ASI or ENC table were incorrect when the
respective data indexes were zero. These values should
have been missing, but instead were populated with data
from the prior ASI entry. This was a limited condition.
-Code path length reductions were made to two subroutines
for ASI and ENC table processing in ASMRMFV by using
existing FINDxx subroutines.
-The ASIENTMX and ASIENTLN fields are now corrected in
ASMRMFV to show the true count and length in an ASI table
record.
-The ENCG3TLN field is now corrected in ASMRMFV to show
the true total length in an ENC table record.
-ASMRMFV now validates that input data sets are VSAM RRDS
with warning message RMFV017W issued if a data set is
non-VSAM or is VSAM but a non-RRDS type. In this case no
abend occurs, but final return code CC=4 is set, and
processing of the next input data set continues.
-ASMRMFV now issues warning message RMFV017W if an input
VSAM data set has a non-standard CISIZE or RECSIZE. IBM
intends that RMF Monitor III data sets be allocated with
the ERBVSDEF Clist which specifies the correct CISIZE and
RECSIZE values of 32768 and 32752 respectively. Use of
other values can result in a file that is unusable by RMF
Monitor III.
-A S0C4 Abend in ASMRMFV CPU table processing is corrected
that occurred when no other LPAR data was present. This
was most likely when a z/OS guest was running under z/VM.
-VMACRMFV did not correctly input the OSDKASID and
OSDPLIST fields from Summary Information section in the
OPD table.
-The following RMF Monitor III table records are now
blocked for efficiency in ASMRMFV output: CPD, CSR, ENT,
OPD, and SPG. This improvement results in up to 90%
reduction or more in output record count. However, this
means there are multiple data segments in each record
which can affect existing logic in any user modified
EXZRBxxx exit routines for the respective table.
VMACRMFV is upgraded to handle the additional data
entries in the blocked tables.
-Tutorial: Your tailoring logic in EXdddddd dataset exits
to control output of an MXG dataset needs this structure
to always be safe:
IF something THEN DO;
OUTPUT _Wdddddd;
END;
and can't use a DELETE, RETURN, nor "IF something;" logic
because when "something" is true, they stop the read of
this current record, skipping any un-read segments from
being tested for "something".
-Validity checking for the CPD, CSR, DVT, ENT, OPD, and
SPG tables in ASMRMFV for excessive or invalid header and
entry length is improved. When anomalies are detected
the entire table will be skipped. This should be a very
rare event.
-Prologue documentation in ASMRMFV source code has been
updated as needed including more discussion on skipped
records and entry blocking.
-NOTE: An assembly and link of each new ASMRMFV member is
ALWAYS STRONGLY recommended, keeping ASMRMFV and VMACRMFV
in sync, to create AND populate the new variables, enable
table record entry blocking, and implement other related
fixes/enhancements in this change.
-HOWEVER: Using the new VMACRMFV to process RMFBSAM data
created with the prior ASMRMFV program should not fail
unless invalid records are found, but all new variables
will have missing values.
Change 30.094 -SMF 113 counters were stored in the MXG DEFAULT=5 length,
ASUM113 but the four sets of counters can contain very large data
VMAC113 values, so variables BASICnn,PROBSTnn,CRYPTOnn,EXTNDnnne
May 28, 2012 are now stored in LENGTH 8, and the PROC MEANs in both
VMAC113 and ASUM113 now specify /INHERIT so the longer
length attribute will be preserved; comparison of short
and long length showed the longer length was needed as
there were some (smaller) values with shorter length.
-Variable SM113CST is removed from BY macro _BTY113 and
that macro matches the final sort order of PDB.TYPE113.
SM113CST was needed in the BY list for the intermediate
sorts but did not exist in the final PDB.TYPE113.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.093 If production jobs create reports that are sent to a data
ANALDB2R set or a report archive facility, but there was no data
May 28, 2012 matching your selections, the result is an empty file or
a nonexistent report. While MXG's SASLOG tells you that
happened (obscurely?), now, a message that no report was
produced is written to the output destination for these
reports: PMACC01 PMACC02 PMSTA02 PMAUD01 PMAUD02 PMAUD03
Change 30.092 If you have IMACEXCL in your "USERID.SOURCLIB", these new
UTILEXCL CICSTRAN duration variables were 16 times too large:
May 24, 2012 ISIOWTTM WMQGETTM MAXTTDTM T8CPUTTM MLXSSCTM JVMTHDTM
WMQASRTM RMITOTTM RMIOTHTM RMIDB2TM RMIDBCTM RMIEXDTM
RMIMQMTM RMICPSTM RMITCPTM
because UTILEXCL had generated incorrect code to convert.
Durations input as &PIB.4.6 use X=16*X;
Durations input as &PIB.8.6 use X=X/4096;
The incorrect syntax was X=16*X/4096; for 8.6.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.091 Typoed character P in column one caused INPUT EXCEEDED in
VMACSVIE SVSUBTYP=27 records that had segment 21 data.
May 24, 2012
Jun 5, 2012
Thanks to Sam Knutson, GEICO, USA.
Change 30.090 Variable FERTREMI incorrectly contained the Local instead
VMACFERT of the Remote IP Address.
May 22, 2012
Thanks to Terry Back, Experian, USA.
Thanks to Jerome Vitner, Experian, USA.
Change 30.089 Support for DB2 V10 APAR PM24723 for IFCID=225 SMF ID=100
VMACDB2 Subtype=4, which COMPATIBLY adds new storage metrics that
May 22, 2012 are output in both DB2ST225 and DB2STATS datasets.
Thanks to Kerry J. Sommers, John Deere, USA.
Thanks to Ralph Baechle, John Deere, USA.
Change 30.088 MQMLOG datetime variables were on GMT clock; there is no
VMAC115 offset field, but these maximum values must be less than
May 17, 2012 the SMFTIME, so the variable GMT115TM is calculated from
SMFTIME-QJSTIOMAXIOT1 and used to adjust datetimestamps
to the local time zone.
Thanks to Joe Faska, Depository Trust, USA.
Change 30.087 Variable TOTDEVHR in TYPE74CA had non-missing values that
VMAC74 were wrong when CACHIOTT was zero or missing; an MXG typo
May 14, 2012 set non-existent variable name TOTDEVNR to missing when
variable TOTDEVHR should have been set to missing value.
Thanks to Sharon Moir, JP Morgan Chase Bank, USA.
Change 30.086 Change 28.276 added BEGTIME= ENDTIME= parameters to
ANALHSM ANALHSM but, in the first step, the BEGTIME and ENDTIME
May 12, 2012 MACRO variables were set to the beginning of the data
and the end of the data so that those values could be
placed in the title lines of the reports. So all
subsequent use of those macro variables and checks for
their existence would be based on the timespan of the
actual data. To make matters worse, in REPORT 5 and
REPORT 6, the BEGTIME and ENDTIME datetime values were
being compared to TIME values for FSRTIMR and FSRTIME
so no data could ever be selected for those reports.
With this change the date/times for the report headings
are changed to BEGREPT and ENDREPT avoiding the
conflict with BEGTIME and ENDTIME selection and in
reports 5 and 6 datetime values are constructed as
they are in ASUMHSM so that the correct data can be
selected for the reports. There are also now MXGNOTEs
that will tell you when you have started processing the
data for each report and another if no data was found
for the report.
Thanks to Paul Volpi, UHC, USA.
Change 30.085 Cosmetic. UNMODSMF time is now aligned under SMFTIME to
VMACSMF make comparisons easier, and the _N_ value of LAST RECORD
May 9, 2012 IN GROUP message is no longer a missing value.
Change 30.084 ODS operator RS=NONE added to prevent wrapping of HTML
VMXGODSO statements (specific to z/OS but causes no problem for
May 9, 2012 ASCII ODS operations; only set for HTML output).
Change 30.083 -MXG 30.02, z/OS Only, SAS 9.1.3 SP4 Only:
VMAC71 ERROR: DOMAIN ERROR.
May 9, 2012 ERROR: TERMINATION DUE TO FLOATING POINT EXCEPTION
occurred in a PROC MEANS of DATA=TYPE71 in JCLTEST9.
This error did NOT occur with SAS 9.3 nor on ASCII SAS.
The Floating Point Exception resulted from MXG INPUTing
SMF71TLS field as RB4 when the field is binary (PIB4),
and a value of '00000AD1'x read as RB4 produced a value
that was a negative with E75 exponent, but it was only
when that value was subsequently read by PROC MEANS that
the error surfaced.
Thanks to John Loch, HP, USA.
Change 30.082 Type 60 record with no VVR segment (for a VVDS) caused an
VMAC60 INPUT EXCEEDED RECORD LENGTH error on 3 days, and then
May 7, 2012 didn't. MXG now tests to verify a VVR segment exists (and
VVRLEN will be a missing value in these observations) but
why these records were created is unknown.
Thanks to Peter Krijger, ANZ National, NEW ZEALAND.
Change 30.081 Enhancement adds rundays=mon tue wed ... to list the days
BLDSMPDB of the week when BLDSMPDB is to actually be executed; on
May 7, 2012 any other day, the program will terminate with MXGNOTEs.
The default, daily, is unchanged.
Thanks to Mynard Holloway, Spectrum Health, USA.
Change 30.080 Actual GDPS records exposed wrong guesses I made when I
VMAC105 wrote code from the documentation: GDPS datetimestamps in
May 4, 2012 SM105STM/DTM/SST/SCT are reversed-SMFSTAMP8 with DATE
Jun 4, 2012 first, so simple SMFSTAMP8 format can't be used; DURATM
field is packed decimal not binary and needs divide by an
undocumented 10; the two RPO duration variables SM105SAR
and SM105SIR also needed an undocumented divide by ten;
the Product section's two variables are input and kept.
-Jun 4: IBM stored blanks for SM105SCD and SM105SCT which
caused INVALID data error. Test for blanks circumvents,
while a PMR is opened for the invalid data.
Thanks to Jeffrey A. Johns, UHC, USA.
Thanks to Paul Volpi, UHC, USA.
Change 30.079 Cosmetic. Using EXEC SAS,CONFIG=CONFIMXG and MXGNAMES,
VMXGINIT DSNAMES in the //SOURCLIB concatenation are dynamically
May 4, 2012 allocated in reverse order to their concatenated order,
and dataset SASHELP.VEXTFL, which MXG reads to print the
DSNAMES on the log at initialization, is also reversed.
A PROC SORT of VEXTFL by DESCENDING LEVEL was inserted to
get the MXG list in correct order when CONFIMXG was used.
When MXGSAS93 and "static" allocation is done in JCL, the
value of LEVEL is zero and the DSNAMES are in the right
order; the sort doesn't alter that correct listing order.
Change 30.078 CICS Statistics storage variables in Change 29.221 were
VMAC110 thought to be in GB, and were multiplied by 1073741824,
May 28, 2012 but they are in MB, so they were 1024 times too large.
These variables are now multiplied by only 1048576 to
convert MB to bytes for the MGBYTES format:
SMSDSASZ SMSHWMDS SMSCSIZE SMSFSTG SMSHWMFS SMSLWMFS
SMSLFA SMSGDCUL SMSGDHWL SMSGDCUR SMSGDHWM SMTHWMPS
Thanks to Homayoun Riaza, United Health Group, USA.
Change 30.077 -READDB2 internal parsing was revised to correctly process
READDB2 %LET MACKEEP=
May 3, 2012 MACRO _WDB2ACP DB2ACCTP.DB2ACCTP %
MACRO _SDB2ACP %
;
%READDB2(IFCIDS=ACCOUNT STATS,
WANTONLY=DB2ACCT DB2ACCTP DB2STATS DB2STATB,
PDBOUT=YES,LDB2ACC=DB2ACCT,LDB2STB=PDB);
to create only DB2ACCT.DB2ACCT, DB2ACCTP.DB2ACCTP,
PDB.DB2STATS and PDB.DB2STATB datasets in those LIBNAMEs.
-IFCID=STATS creates only/both PDB.DB2STATS & PDB.DB2STATB
but Change 27.322 incorrectly listed only DB2STATS so the
comments in READDB2 were clarified.
-Minor logic changes: DB2STATB routing was suppressed with
STATS, and SMF IDs to be read message only showed 101.
-Cleanup 106 message, detritus in WORK when IFCID=STATS is
used (newish STATS creates ONLY the PDB.DB2STATS dataset)
with PDBOUT=YES.
Change 30.076 If USERADD= specified 102.xxx, but the length of xxx was
UTILBLDP less than 3 (e.g. 102.23 instead of 102.023), incorrect
May 2, 2012 macro token _C10223 instead of _C102023 was created which
caused unreferenced macro error. Not reported by a user.
Correction was when &LENGTH(&STRING2) was 1 or 2.
Change 30.075 -Variables JOB JESNR JBL24 are now kept in TPMJBL24.
VMACTPMX -Variable READTIME is now kept in all TPMJBLxx datasets,
May 2, 2012 since READTIME as well as JOB and JESNR are required to
uniquely identify a "JOB".
-Variable TPMPCSDIFFER is now input as IB because it can
contain negative values.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.074 Cosmetic. WARNING: MULTIPLE LENGTHS FOR BY VARIABLE LCU
ANALFIOE is removed with LENGTH DEFAULT=&MXGLEN added in the DATA
Apr 28, 2012 step that creates LCU from LCUID in TYPE78CF. There was
no error because the two lengths were 5 and 8 and LCU is
only a 2-byte binary number.
Thanks to Dan Case, Mayo Clinic, USA.
Change 30.073 Support for CA Vantage Storage Resource Manager 12.6.00,
VMACSAMS INCOMPAT: SAMSLGVR='X' in new records; MXG tested GE '6'
May 29, 2012 when SAMS code was last updated. SAMSPOOL fields were
restructured, from 4 to 8 bytes, some from PD to PIB.
New variables created in SAMSPOOL dataset:
SAMSSYSP='SYSPLEX*WHERE*VANTAGE*RUNS'
SAMSLPAR='LPAR NAME*WHERE*VANTAGE*RUNS'
SAMSSUBS='SUBSYSTEM*WHERE*VANTAGE*RUNS'
SAMSHASL='LOCAL*HASH*VALUE'
SAMSHASG='GLOBAL*HASH*VALUE'
Thanks to Robert Brosnan, Goldman Sachs & Co., USA.
Change 30.072 Support for RMF 74 APAR OA36831 which COMPATIBLY adds new
VMAC74 SMF74NSS='SKIPPED*SAMPS*INVALID*DELTA VALUE'
Apr 21, 2012 to TYPE74 dataset.
Change 30.071 VMACTPX, written before _Vdddddd old-style macro were
VMACTPX designed, is updated to define and use those alternative
Apr 21, 2012 tokens to control what's kept in MXG datasets.
Thanks to Erling Andersen, SMT Data, DENMARK.
Change 30.070 Support for CA-Spool Subtype 12 creates CNA9CX dataset,
EXCMA0CX but only creates the seven variables that were recognized
IMACCMA by format and content with the subtype 11. Additional
VMACCMA data fields will be decoded when documentation received.
VMXGINIT
Apr 21, 2012
Thanks to Orjan Lindholm, Volvo, SWEDEN.
Change 30.069 These new in z/OS 1.13 TYPE72GO vars were not populated
VMAC7072 CPUPDPTM R723RTDM R723RTDC R723RTDT
Apr 20, 2012 because the test was 32 when only 24 bytes were added.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 30.068 RMM dataset EDGRDEXT was expected, but the "D" and "V"
VMXGDSN records were combined into the "X" record, so DAILYDSN
Apr 20, 2012 was revised to use EDGRXEXT instead of EDGRDEXT.
Thanks to Jeff Dyke, USDA, USA.
Change 30.067 LUNAME added where possible to SMF ID=119 example report.
ANAL119
Apr 19, 2012
Change 30.066 New version of Ferret record is supported for subtype 1
VMACFERT and 4, based on test data without the vendor's DSECT.
Apr 20, 2012 -FERRET subtype 1 record with length of third triplet 80
caused INPUT STATEMENT EXCEEDED because that segment was
82 bytes in prior records. A LENLEFT test to protect was
added, but removing the +2 appears to realign subtype 1.
-FERRET subtype 4 record removed the +6 bytes at start.
Thanks to Bruce Sloss, PNC Bank, USA.
Change 30.065 Vendor segment for ETFR ID=80 SMF record caused MXG to
VMAC80A have INPUT STATEMENT EXCEEDED RECORD. Previous FRI=02
Apr 18, 2012 had an extra byte (in 2004 when ETFR segment was last
updated!) that is not there now, DO Group bypassed.
Thanks to J. Grasing, Metropolitan Life, USA.
Change 30.064 Support for new MQ QJST 7.01B Stats Block adds 4 sets of
VMAC115 ten variables with log statistics for each of up to four
Apr 18, 2012 logs in the MQLOG dataset.
Thanks to Joe Faska, Depository Trust, USA.
Change 30.063 The SMF 117 subtype 'IMFL' new variable SM17ACCT with the
VMAC117 'ACCOUNT*ORIGIN' is input and kept when it exists in the
Apr 17, 2012 WebSphere 7.0.0.3 SMF record.
Thanks to Fabio Ottaviani, EPVTECH, ITALY.
====== Changes thru 30.062 were in MXG 30.02 dated Apr 15, 2012=========
Change 30.062 TYPE70 variable ENHDATAR='ENHANCED*DAT*ARCHITECTURE?" is
VMAC7072 now created from Bit 7 of SMF70PRF.
Apr 12, 2012
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 30.061 BETA93 subtype 25 records support is revised to match the
VMACBETA data records. The documentation for 4.1 release is wrong,
Apr 12, 2012 as there are not 256 reserved bytes at the end, which
caused INVALID DATA FOR BETASTRT messages, and support
for the 4.2 was wrong, causing INPUT STATEMENT EXCEEDED
RECORD LENGTH errors.
Change 30.060 Support for TMON/DB2 V5, INCOMPATIBLE, only for DB2 V10.
EXTMD2BA Completely restructured records with new dataset names
EXTMD2BB and new variable names, so your reports will have to be
EXTMD2BC revised to use new MXG dataset names and variable names.
EXTMD2BD The new product suffix is TMD2, replacing TMDB, so you
EXTMD2BE will need to change your input DDname to //TMD2IN and
EXTMD2BF your MXG %INCLUDEd program to TYPETMD2 or TYPSTMD2.
EXTMD2BG
EXTMD2BH DDDDDD MXG MXG SIMILAR TO
EXTMD2BJ DATASET DATASET DATASET OLD TMDB
EXTMD2BK SUFFIX NAME LABEL DATASET
EXTMD2BL
EXTMD2DA TMD2BA TMD2BA SET CURRENT SQLID
EXTMD2DB TMD2BB TMD2BB End of Identify
EXTMD2DC TMD2BC TMD2BC End of Signon
EXTMD2DE TMD2BD TMD2BD Authorization Failure
EXTMD2DW TMD2BE TMD2BE Explicit GRANT/REVOKE
EXTMD2IB TMD2BF TMD2BF DDL on Audited Object
EXTMD2ID TMD2BG TMD2BG Write on Audited Object
EXTMD2IG TMD2BH TMD2BH Read on Audited Object
EXTMD2II TMD2BJ TMD2BJ Utility started
EXTMD2IP TMD2BK TMD2BK Utility Change
EXTMD2IT TMD2BL TMD2BL Utility End
EXTMD2PK TMD2DA TMD2DA INTERVAL SYSTEM STATISTICS TMDBDA
EXTMD2QS TMD2DB TMD2DB Thread Accounting Data TMDBDB
EXTMD2SD TMD2DC TMD2DC DB2 Command Activity
EXTMD2SL TMD2DE TMD2DE Exception Definition/Event
EXTMD2ST TMD2DW TMD2DW DB2/IRLM Messages
EXTMD2TB TMD2IB TMD2IB Interval BP Statistics TMDBDAB
EXTMD2TD TMD2ID TMD2ID Interval DDF Statistics TMDBDAF
EXTMD2TG TMD2IG TMD2IG Interval GBP Statistics
IMACTMD2 TMD2II TMD2II Interval IFCID Statistics
TYPETMD2 TMD2IP TMD2IP Interval Data Set Statistics
TYPSTMD2 TMD2IT TMD2IT Interval IFI Trace Dest
VMACTMD2 TMD2PK TMD2PK Thread Package Accounting TMDBDBK
VMXGINIT TMD2QS TMD2QS SQL Analyzer Statistics
Apr 10, 2012 TMD2SD TMD2SD System Deadlock Detail
TMD2SL TMD2SL System Deadlock/Timeout Victim
TMD2ST TMD2ST System Timeout Detail
TMD2TB TMD2TB Thread BP Accounting TMDBDBB
TMD2TD TMD2TD Thread DDF Accounting TMDBDBF
TMD2TG TMD2TG Thread GBP Accounting
All datasets have been extensively validated with test
data records, but with 10,000 new lines of source code,
there is some possibility of overlooked items.
The original VM/XA MONWRITE support was also 10K lines
and took 150 hours across 10 days. This project took
only 5 days and about 50 hours, in part because you
can teach an old dog new tricks, but also because the
vendor "$$" aggregation file was used to generate each
INPUT line for each variable, with its INFORMAT and
LABEL; most of the rest of the time was spent
comparing each line with the DSECTS to find the
reserved fields that were not in the $$ file and to
find the undocumented bytes added for fullword
alignment.
MXG previous support for pre-V5 TMON/DB2 did not support
any of the 'Bx' records (because no one sent sample data
records indicating they wanted those records supported!),
but since ASG Technical Support provided samples of EVERY
record type, ALL records, including the records that are
new in V5 (DB2 Command, Deadlock/Timeout, DataSet Status,
and the new Interval and Thread data) are supported and
ALL have been data-tested (so hex-containing strings, the
times and datetimes should be correctly formatted).
Check with ASG Customer Support that you have all PTF's
installed; not all datetimestamps were converted to the
local time zone, and some alignment corrections in new
records.
Change 30.059 -BLDSMPDB uses an execution of VGETSORT to build a list of
BLDSMPDB the datasets for weekly and monthly processing. In the
Apr 9, 2011 case of monthly it was looking at the WEEK LIBNAME rather
than the WEEK1 LIBNAME. On ASCII this was not a problem
since both WEEK and WEEK1 existed albeit pointing at the
same directory, but on zOS that was not necessarily the
case. VGETSORT was changed to point at WEEK1.
-When monthly/weekly was not being run and AUTOALOC was
set to NO, BLDSMPDB displayed a message that WEEK and
month LIBNAMES contained a date range that could have
been in error or not even existence. Message is now
suppressed when AUTOALOC=NO.
-Value of SORTEDBY is forced to NO when the length of
MXGNOBY is greater than 0 to suppress the BY statements
in WEEKLY/MONTHLY processing to optimize performance.
Change 29.008 removed BY processing for WEEK/MONTH in
old WEEKBLD/MONTHBLD logic, so BLDSMPDB is consistent.
Change 30.058 -New variables added to RMF TYPE71 dataset by z/OS 1.13
VMAC71 that were overlooked:
Apr 2, 2012 SMF71L7M='MIN 1MB*FIXED*FRAMES*NOT IN USE'
SMF71L7X='MAX 1MB*FIXED*FRAMES*NOT IN USE'
SMF71L7A='AVG 1MB*FIXED*FRAMES*NOT IN USE'
SMF71TLS='TOTAL*NUMBER OF*LOGICAL*SWAPS'
-SMF71LFA, added in MXG 30.01 was incorrectly aligned.
-And, starting with z/OS 1.13 the Swap Placement Section
does not exist, so the below 66 variables won't exist, so
you could DROP them all from your TYPE71 dataset when all
your systems are at that level, with this statement in
the //SYSIN stream that builds your TYPE71 dataset:
%LET MACKEEP= MACRO _KTY71 DROP=
SWAPTO PHYAUXTO LOGEXTTO LOGAUXTO PHYEXTTO EXTAUXTO
SWAPTI PHYAUXTI LOGEXTTI LOGAUXTI PHYEXTTI EXTAUXTI
SWAPWT PHYAUXWT LOGEXTWT LOGAUXWT PHYEXTWT EXTAUXWT
SWAPAS PHYAUXAS LOGEXTAS LOGAUXAS PHYEXTAS EXTAUXAS
SWAPRS PHYAUXRS LOGEXTRS LOGAUXRS PHYEXTRS EXTAUXRS
SWAPDW PHYAUXDW LOGEXTDW LOGAUXDW PHYEXTDW EXTAUXDW
SWAPVR PHYAUXVR LOGEXTVR LOGAUXVR PHYEXTVR EXTAUXVR
SWAPNQ PHYAUXNQ LOGEXTNQ LOGAUXNQ PHYEXTNQ EXTAUXNQ
SWAPEX PHYAUXEX LOGEXTEX LOGAUXEX PHYEXTEX EXTAUXEX
SWAPUS PHYAUXUS LOGEXTUS LOGAUXUS PHYEXTUS EXTAUXUS
SWAPNS PHYAUXNS LOGEXTNS LOGAUXNS PHYEXTNS EXTAUXNS
% ;
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 30.057 Support for TS7700 Version 2.0a (INCOMPATIBLE, due to
FORMATS insertion of new fields and increases in lengths of some
VMACBVIR existing fields, impacting BVIR30 and BVIR32 datasets).
Apr 1, 2012 -New variable in dataset BVIR30:
AVGCPUSE='CPU*USAGE*PERCENT*AT END OF*INTERVAL'
-New variables in dataset BVIR33:
DVMECC00='00*MEDIA*TYPE*CONTAINER*COUNT'
5 more new variables
DVMECC07='07*MEDIA*TYPE*CONTAINER*COUNT'
DVMTC010='POOL 01 MEDIA 0*MEDIA*TYPE*CONTAINER*COUNT'
254 more new variables
DVMTC327='POOL 32 MEDIA 7*MEDIA*TYPE*CONTAINER*COUNT'
-FORMATS was updated for new media types JC, JY and JK.
Thanks to Louis Deledalle, BNPPARIABAS, FRANCE
Thanks to Perry Lim, Union Bank, USA.
Change 30.056 -The DSNBRECD observation for a VOLSER created from the
TYPETMS5 first DSNB record could have wrong values for variables
VMACTMS5 DSNBUSRU DSNBTMSI DSNBECAT DSNBABND DSNBISCA DSNBDFXU
Apr 4, 2012 DSNBWSCA DSNBDFLT
because those variables had values from the TMSREC-DSNB.
Now, the DSNB values are temporarily stored, the DSNB for
the TMSREC DSN is created with those variables populated
from the corresponding TMSREC variables, and then the
DSNB variables are restored from temp storage.
-The values for DSNBECAT and DSNBWSCA in the DSNB created
from the TMSREC were reversed.
-Value for TRTCH 'D0'x set DEVTYPE of 3590 but it's 9840,
and some additional DEVTYPE values were enhanced to show
the EF3/EF3M/EF3X/EE3/EE3M/etc descriptor text.
-In diagnosing the error, I also observed an inconsistency
in MXG logic for TMSREC observations that have SCR='Y',
i.e., Scratch List VOLSERs: MXG did not create the pseudo
DSNB observation for the TMSREC DSN for scratched volumes
but all of the real DSNB observations are output, with no
flag they are on a Scratch Volume, as that is a TMSREC
and not a DSNBREC attribute. Now, that pseudo DSNB obs
is created for SCR='Y' volumes, and new variable SCRFLAG
is created in DSNBRECD so DSNBs on Scratch volumes can
be identified.
Thanks to Scott Rowe, Social Security Administration, USA.
Change 30.055 -Support for DB2 APAR PM37956 to SMF 102 IFCID 25 added
FORMATS several new variables, two of which are decoded by new
VMAC102 formats.
VMACDB2H -Cosmetic: VMACDB2H updated to prevent two "MISSING" value
Mar 28, 2012 calculation messages.
Thanks to Paul J. Larsson, Aetna, USA.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.054 -ERROR: Divide by zero in SMF 73 records occurred in the
VMAC73 new FICON Extended Data segment when SMF73PTI=0, which
Mar 29, 2012 occurs for CHPIDs that are not ONLINE. The new MXG code
failed to test SMF73PTI before the division (even though
all other divides where!). Because TYPE73 observations
WERE only output if ONLINE='Y' and VALIDPTH='Y', these
segments that caused the divide by zero were not output,
so there was no impact on the contents of TYPE73 dataset.
All SMF73PTI divides are now protected.
-HOWEVER: The IBM Channel Path report does list CHPIDs
that are OFFLINE but have VALIDPTH='Y', so the logic in
VMAC73 is changed so that observations with EITHER the
ONLINE='Y' OR the VALIDPTH='Y' are output, in case you
actually need to see that a CHPID is offline. This will
cause a small increase in the number of observations that
are output in TYPE73 (256 CHPIDs are possible; in this
site's data, 59 were online and valid path, and 7 more
were valid path only that are now also output).
Thanks to Christine Ya DeClercq, DEXIA, BELGIUM.
Change 30.053 -Two variables were named CALTYPE, one in dataset VXSYTSPT
VMACVMXA that is a one-byte flag, and one in VXMTRPAG & VXSTOATC
Mar 21, 2012 which is a four byte field containing PAGE or SPOL, but
Apr 2, 2012 the second was truncated to one byte by the first. Since
CALTYPE in VXSYTSPT is a flag that is unlikely to be used
I have renamed it to CALTYPEP to eliminate truncation.
-Variable HFQUCT in VXBYUSR wasn't properly deaccumulated.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 30.052 Some packed decimal variables notably TPTDBIO were not
VMACIMS protected for a full hex-zero field value; the needed
VMACIMSA "double question mark" has been inserted in each INPUT.
Mar 21, 2012 Where the value is hex zero (because IBM did NOT prime
the field as a valid PD field) there is no impact on the
value of those variables as they will be a missing value
with or without the ??, but this change will eliminate
the INVALID DATA message and associated hex record dump.
Thanks to Paul Volpi, UHC, USA.
Change 30.051 Support for SYSVIEW PTF Test APAR TSD0144, for IMS data.
EXSV34ES Only SYSVIEW IMS records with that APAR can be read with
EXSV34SU this update; revisions to subtypes 34 and 35 were made.
IMACSVIE -New SV34ESS and SV34SUMM datasets are created.
VMACSVIE -Change 29.273 found LTERM names 'FDFFFFFF'x, which is the
VMXGINIT indicator the transaction originated in MQ and entered
Mar 30, 2012 IMS via OTMA: in this case, there isn't an LTERM, but the
Apr 2, 2012 next 8 bytes is the TPIPE name (e.g. CSQ800B9, which is
Apr 26, 2012 in LUNAME field), so that TPIPE name is now used for the
Jun 4, 2012 LTERM name. Some records for OTMA transactions have the
LTERM name for TCP/IP port number. MXG keeps the hex
value in IMTR_TRN_LTERM_HEX and stores LUNAME into LTERM.
-In IMS V9, DBIOTIME and LOCKTIME fields are only valid in
records from DBCTL subsystems, so those fields are set to
a missing value when they are not valid.
-Jun 4: two variables are no longer divided by /4096 :
IMTR_CLK_MPP_CPU
MQRR_OBJ_INTERVAL
Thanks to Martin Trinkler, CSC, ENGLAND
Thanks to Arthur G. Hurlston, CSC, ENGLAND
Change 30.050 Support for SMF 85 records from z/OS 1.13 (INCOMPAT, due
VMAC85 to new value of R85PVRM='1130'.
Mar 20, 2012
Thanks to Joachim Sarkoschits, DATAEV eg, GERMANY.
Change 30.049 An extra semi-colon in the non-graphics PROC PLOT caused
ANALCNCR an error and was removed.
Mar 19, 2012
Thanks to Steve Dyck, Canadian Depository, CANADA.
Change 30.048 If you specified a 9-character SAS date literal value, eg
VGETDDS 12MAR2012, only the first 7 characters were used, causing
Mar 19, 2012 the constructed Julian Date to be incorrect as 2020072.
Thanks to Brian Harvey, HCL America, USA.
Change 30.047 Support for BMC Mainview for MQ Version 5.1 (INCOMPAT).
EXBBMQAL MXG did not protect for changed segment lengths so this
IMACBBMQ update is required to read 5.1 data records. The new
VMACBBMQ RTIN='EA'x record has not been tested, but it will create
VMXGINIT observations in new dataset BBMQALTS; some variables will
Mar 18, 2012 be changed to datetime variables instead of character
when test data is available.
Change 30.046 -If you specified SUPPRESS=110, that did not suppress the
UTILBLDP creation of CICSTRAN, which requires //CICSTRAN to exist.
Mar 18, 2012 -If CICSTRAN was suppressed, ASUMUOW/ASUMCICX were still
invoked, causing errors.
-New values for suppress of DB2STAT CICSSTAT were added so
you can separately suppress the statistical datasets.
Thanks to Chip Parsons Ingram Books, USA.
Thanks to Paul Volpi, UHC, USA.
Change 30.045 Debugging PUT _N_= CPUUNITS= CPUTCBTM= removed; added for
VMAC30 testing of Change 29.025.
Mar 14, 2011
Thanks to Murali K. Inuguru, CSC, India.
Change 30.044 -Updates to D062, D063, D060, VWRP, D059, D057, VWVS.
VMACNTSM -VMware.Guest.CPU
EXNTDTAL VWGCUSPC doesn't exist, removed.
EXNTDIRS VWGCSWTM /*SWAP*WAIT*(MILLISECONDS) */ added.
EXNTSRMD -VMware.Host.CPU - the two Core utilization fields
IMACNTSM VWHCCORA and VWHCCORB were mislabeled as CPU utilization
VMACNTSM Pending newdata/newnames updates to QLSS QLSE
VMXGINIT QLSS: MSSQL:SQL STATISTICS
Mar 11, 2012 QLSE: MSSQL:USER SETTABLE
Apr 15, 2012 New objects are now supported in Apr 15 iteration:
NTDTAL DTS.ALERTEVENT - 4 DTAL.... vars
NTDIRS DIRECTORYSERVICES - 164 DIRS.... vars
NTSRMD SERVICEMODELSERVICE 3.0.0.0 - 33 SRMD.... vars
User-found corrections after Mar 11 iteration:
vmware_guest_virtualdisk - keep D0590007-13.
vmware_host_storagepath - length of D0630009
changed to $128. This is actually the concatenation of
three 32+ byte worldwide names (WWN). In my data they
are delimited by periods but I'm not sure that will
always be the case so let the user parse.
VMware.Host.Aggregate - Add VWGCVMGU to keep list
VMWARE.GUEST.RESCPU - ELSE removed, dropped host/guest.
VMware.Host.CPU - Changed VWHCCPU to integer
VMWARE.HOST.MEMORY - vwhmtotc was too large
Thanks to Jim Quigley, ConEd, USA.
Change 30.043 RMF III dataset ZRBASI Report Class Name/Description vars
VMACRMFV ASIRNM and ASIRDE can have hex zero values, because IBM
Apr 13, 2012 relocated the fields; SVPDCL is now 144 vs the documented
and expected length of 76. Now, ASIRNM is tested for hex
zero and the INPUT moved when found true.
-Same change made for ZRBENC for ENCRNM and ENCRDE.
-Compatibility fix for RCDSDI field in RCD table record.
In older versions of ASMRMFV the offset to the RCDSD
(Subsystem Delay) section of the RCD record can be
incorrect causing an INPUT LENGTH EXCEEDED error and
VMACRMFV termination. This fix recalculates the value of
RCDSDI using other known valid fields.
-RCD table flag variable RCDEFLAG is input as character,
but is actually a hexadecimal value. Format $HEX2. is
added for this variable for a correct display. NOTE:
Variable RCDSDPH contains the decoded value of RCDEFLAG
for ease of use.
-Compatibility fix for ASIRNM/ASIRDE variables in ZRBASI
file and ENCRNM/ENCRDE variables in the ZRBENC file. The
Service Class data extension used to build these files
can have a length of 144 bytes instead of the documented
length of 76 bytes. This caused VMACRMFV to input the
following Report Class data extension incorrectly so that
these fields had bad values. This fix accommodates a
length of 144 or 76 for the Service Class extension.
-The indexing variable to input the RCDSD array entries
was _I_ when it should have been _J_. The _I_ subscript
was already being actively used.
-Length checks used to validate input for the Service
Class and Report Class data extensions in the RCD table
were too short.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, Australia
Change 30.042 -SMF AUDIT REPORT. The existing _RPTID report in BUILDPDB
ANALID is significantly enhanced, and new variables are created
FORMATS in the PDB.SMFRECNT to provide more detail of counts and
IMACSMFF percentages of records and bytes in your SMF data. Each
VMACID obs summarizes an ID.SUBTYPE (described by new $MGSMFID
VMACSMF format), but records with Subsystem or Product Version
VMXGINIT (DB2A V10, CICSPROD TS4.2, RMF 1.12) are reported at that
Apr 14, 2012 level of detail. Plus, all obs have the min/max SMF time,
May 12, 2012 and any compressed records (DB2,CICS) are flagged!
May 28, 2012 -The temporary WORK.ID dataset is created and summarized
Jul 4, 2012 to create the PDB.SMFRECNT used for the report, and the
May 6, 2013 new variables increase its size, but it is temporary, so
only //WORK space is used. For BUILDPDB, the INCREASE in
work space required is 25 CYL per Million SMF records.
When %ANALID(PDB=SMF) is executed standalone, 60 CYL of
//WORK space is needed per Million SMF records.
That small increase in BUILDPDB is because the old ID
dataset was compressed by default when it should not
have been; compression doubled its size (due to the small
number of variables), but even the new ID is 9% larger if
compressed, so the COMPRESS=NO Dataset Option is used for
the WORK.ID dataset to minimize its space requirement.
-If work space is an issue, you can disable creation of
the WORK.ID dataset with %LET SMFAUDIT=ZEROID in //SYSIN.
-If you want the original ID dataset without new variables
and you are not changing the MACRO _KTYID, then you would
use %LET SMFAUDIT=NO; in //SYSIN.
-If you want to add new or drop existing variables in the
ID dataset, or you want to change the MACRO _KTYID, you
MUST use the SMFAUDIT=YES default, and use MACRO _KTYID
to KEEP new or DROP old variables, and you must add the
COMPRESS=NO option in your replacement MACRO _KTYID as
shown below. To create new variables, your SAS code to
create them would be in MACRO _ETYID, as shown in this
syntax example (and as documented in member DOCMXG):
%LET MACID=
%QUOTE(MACRO _KTYID
DATE TIME
DROP=SMFTIME
COMPRESS=NO
%
MACRO _ETYID
DATE=DATEPART(SMFTIME);
TIME=TIMEPART(SMFTIME);
FORMAT DATE DATE9. TIME TIME12.2;
OUTPUT _WTYID;
%
);
%INCLUDE SOURCLIB(TYPEID);
RUN;
Note that %QUOTE() must be used; %STR() fails.
-The new Audit Report goes to PRINT by default, but it can
be redirected to ODS, on ASCII with this //SYSIN syntax:
%LET MACKEEP=%QUOTE(
MACRO _RPDBID
%ANALID(ODSTYPE=HTML,ODSPATH=E:,ODSFILE=ANALID.HTML);
%
);
%INCLUDE SOURCLIB(BUILDPDB);
or on z/OS, you would use this syntax:
%LET MACKEEP=%QUOTE(
MACRO _RPDBID
%ANALID(ODSTYPE=HTML,ODSPATH=MY.PDSE,ODSFILE=ANALID);
%
);
%INCLUDE SOURCLIB(BUILDPDB);
-You can also produce the SMF AUDIT REPORT directly from
an SMF file using:
%ANALID(READSMF=YES,PRINT=YES,PERCENTS=YES,PDBOUT=PDB)
to create all reports and the PDB.SMFRECNT dataset, and
additional arguments ODSTYPE=,ODSPATH=,ODSFILE= can be
specified on the %ANALID invocation for ODS/HTML output.
-VMACSMF was revised to create variable SUBSYSTEM for DB2,
CICS, MQ records (100-102,110,115-116), for 26's (JES2/3)
for 30s (JES3,TSO,STC,OMVS,etc.), for 6's (JES2/JES3/EXTW
PSF/PRINTWAY/CADI/BUNDLE/SAR/EXD), and PRODVERSION for
DB2 (V10), CICS (TS/4.2), RMF (ZV011300), and MQ (7.10).
This means that those variables are populated when the
IMACFILE/&IMACFILE exit is taken, so you can use them to
select those records by SUBSYSTEM/PRODVERSION either for
MXG processing, or if you want to write SMF records out
to a separate SMF file; see comments in IMACFILE.
Note May 6 2013: other attributes, such as COMPRESSED and
DB2 ACCUMAC status have been added to the report but this
text may not always be timely.
-Format $MGSMFID maps IBM SMF TYPE numbers and Subtype to
describe each record/subtype. User SMF records will be
counted by ID and subtype (if the subtype bit is on in
the USER record's SMF header), but with no explanation,
or counted just by ID if the subtype bit is NOT on in the
USER SMF record, but you can create your own description
of USER SMF record that will be added to $MGSMFID format
by using the IMACSMFF member in your tailoring library,
following it's comments for syntax of your USER records.
After you SAVE your IMACSMFF member into your tailoring
library, you then need to update the MXG format library
by running
//LIBRARY DD DISP=OLD
%INCLUDE SOURCLIB(FORMATS);
which will update the MXG Format Library.
If you can not update the site's format library, you
can create this new format in a separate dataset and
use OPTIONS FMTSEARCH=(MYLIB LIBRARY); in the ANALID job.
-Macro variable SMFAUDIT is defined in VMXGINIT.
-To summarize the overall options:
READSMF=YES read SMF, create WORK.ID or PDB.ID, create
PDB.SMFRECNT, delete WORK.ID or keep
PDB.ID.
READSMF=NO read WORK.ID/PDB.ID, create PDB.SMFRECNT,
delete WORK.ID or keep PDB.ID.
PRINT=ONLY read only PDB.SMFRECNT to print report.
-This rewrite of the _RPTID report was precipitated by:
The previously posted error that caused LARGE INCREASE
in elapsed run time when BUILDPDB had any output "PDB"
data libraries (//PDB, //CICSTRAN, //DB2ACCT, etc.) on
on tape or in sequential format.
That error is corrected in this change.
But, to document the error and a circumvention:
VERY long elapsed times in BUILDPDB if output PDB data
libraries (//PDB, //CICSTRAN, //DB2ACCT) are on TAPE:
PROC SQL reads the DICTIONARY.COLUMNS internal dataset,
but if any LIBNAME is on tape, the ENTIRE tape is read.
Site with 35 million CICSTRAN observations on tape took
3.5 hours to read SMF and then spend 3.1 hours in this
PROC SQL, just to create the report of ID counts; this
problem was introduced in MXG 29.03, Change 28.089.
If you do not have MXG 30.02 with this Change 30.042,
this Circumvention eliminates long elapsed times:
Insert this statement
%LET MACKEEP= MACRO _RPDBID _RPDBIDO % ;
in your //SYSIN DD input, or this macro definition
MACRO _RPDBID _RPDBIDO %
in your IMACKEEP tailoring member. This will revert
the SMF TYPE report to only count records.
-This change replaced PROC SQL with %VMXGOBS to correct
the elapsed run time error, and all other uses of PROC
SQL with DICTIONARY.COLUMNS have a specific LIBNAME, so
they had no exposure.
Thanks to Jim Hayes, Huntington National Bank, USA.
Thanks to Marty Pruden, Purina Nestle, USA.
Thanks to Michael Rhoades, Purina Nestle, USA.
Thanks to Michael Oujesky, Bank of America, USA.
Thanks to MP Welch, SAS Institute, USA.
Change 30.041 Support for EMC EzSM (z/OS Storage Manager) SMF record.
EXEZSM01 Preliminary support - problems in record have opened a
EXEZSM02 discussion with the vendor, but still no response when
EXEZSM03 MXG 30.02 was created.
EXEZSM04
EXEZSM05
EXEZSM06
EXEZSM07
IMACEZSM
TYPEEZSM
TYPSEZSM
VMACEZSM
VMXGINIT
Mar 7, 2012
Change 30.040 -Variable DOWNTM was a missing value in PDB.IPLS dataset
VMAC0 after Change 29.032 used only ID=90 ST=8/10 to identify
VMAC90A a true system IPL; the DOWNTM=IPLTIME-PREVTIME was not
VMACSMF calculated for subtype 10 and the operator entered DTIME
Mar 9, 2012 value was incorrectly used for the subtype 8 IPL PROMPT.
-Examination of events at a true IPL show that SMF records
0 8 22 90 are written prior to the IPL event, and ID 2,3
can be written on other systems at other times, so these
records are all NOT used to set PREVSYS/PREVTIME.
-VMAC90A was updated to contain DOWNTM and IPLTIME in the
TYPE9008 and TYPE9010 datasets, for consistency.
-Dataset PDB.IPLS was revised to contain the old variables
from the ID=0, even though it is created from ID=90/8-10.
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 30.039 NDM-CDI record 'XO' caused "UNKNOWN SUBTYPE" log messages
VMACNDM because 'XO' was not in the test for supported subtypes,
Mar 6, 2012 but code was in place to output them in NDMDT dataset, as
it is the same record structure. Now, they are output.
Thanks to Betty Wong, Bank of America, USA.
Change 30.038 Support for DB2 IFCIDs 357 and 358; those datasets are
VMAC102 now populated with the IFCID-specific variables.
Mar 6, 2012
Thanks to Terry L. Berman, DST Systems, USA.
Change 30.037 Support for BMC APPTUNE V6R3 SMF 102 records (INCOMPAT).
VMAC102 These numeric variables were increased from 2 to 4 bytes
Mar 6, 2012 causing mis-alignment of all subsequent variables:
QBMCSCTN QBMCSTMT QBMCSOPN QBMCOPNN
and these two new variables are inserted and now input:
QBMCTXTH='SQL*TEXT*HASH'
QBMCIMPK='IMPLICIT*QUALIFIER*KEY'
and QBMCSQID QBMCIMPQ contain ASCII rather than EBCDIC.
BMC APPTUNE ID=102 IFCIDS are 8004x-800Bx & 8133x-8136x.
Only the 8133x record has been validated.
Thanks to Christa Neven, KBC, BELGIUM.
Change 30.036 On the first day of the month, the MTD value was
VMXGALOC calculated correctly but the MONTH value was the prior
Mar 2, 2012 month.
Thanks to Ruth Larsen, Computer Associates, USA.
Change 30.035 RSD/FOLDERS name fields were increased to $250, causing
VMACRSDA the AUDDNAME and other AUDDxxxx fields to be missing as
Mar 2, 2012 those fields were located after the AUDFxxxx variables.
Thanks to Christa Neven, KBC, BELGIUM.
Thanks to Marc Heremans, KBC, BELGIUM.
Change 30.034 VMXGGETM is used to select SMF records by ID and SUBTYPE,
VMXGGETM but only supported 512 subtypes; BMC's APPTUNE product
Mar 2, 2012 creates SMF 102 records with IFCIDS 8000x to 8136x which
caused VMXGGETM to fail with ARRAY ERROR. This change
increases the array to support 33078 (8136x) to protect
the BMC records, keeping the REGION size to about 84MB.
(VMXGGETM is also used in JCLTESTx to create SMFSMALL, so
I don't want new users to die with insufficient REGION in
their first MXG test job. Setting the array size to the
max possible 65536 for the two-byte field needed 150MB.)
Thanks to Christa Neven, KBC, BELGIUM.
Thanks to Wim Hermans, KBC, BELGIUM.
Change 30.033 Cosmetic. Missing value calculation for PHSTARTM when it
VMAC110 was missing is protected for ID=110 MNSEGCL=5 Resource
Mar 1, 2012 Record (dataset CICSRDS).
Thanks to Tom Buie, Southern California Edison, USA.
Change 30.032 -Stored LENGTH of QWHxxxxx variables now $128 in DB2ACCT.
VMACDB2 This text was re-written Mar 27, but no code was changed.
VMACDB2H These DB2 Variables are all now stored as LENGTH $128:
Feb 29, 2012 QLACLOCN QLSTLOCN QMDALOCN QPACAANM QPACASCH QPACCOLN
Mar 4, 2012 QPACLOCN QPACPKID QWHCAID QWHCCTKN QWHCEUID QWHCOAUD
Jun 8, 2012 QWHCOPID QWHCROLE QWHCTCXT QWHDRQNM QWHDSVNM QWHSLOCN
Oct 3, 2012 because IBM has increased those lengths (history below)
Mar 28, 2013 and now many of these variables do contain more than
eight bytes, especially if you have distributed systems
with those long open-system name fields.
But with the (MXG DEFAULT) COMPRESS=YES option enabled,
these stored lengths can be increased, so no data values
are truncated, without significant DASD space increase,
since most of those nine-plus bytes are still blank.
-However, you can change those lengths if, for example,
the CPU cost of compress is more expensive than the DASD
disk space cost. See NEWSLETTER SIXTY, Section VI.7,
in member NEWSLTRS for the complete documentation in
"Changing the length of MXG variables", which shows
this syntax can be used (only) for character variables.
//SYSIN DD *
%LET MACFILE=
%QUOTE( LENGTH
VAR1 VAR2 VAR3
$8 ;
);
%INCLUDE SOURCLIB(whatever);
Some History:
In 2004, IBM increased the length of several fields and
MXG Change 22.196 in 2004 increased INPUT to $128 for
QWHSLOCN QWHCAID QWHCOPID QWHCEUID QWHDRQNM QWHDSVNM
but that change noted that they were not stored as $128,
because in 2004 some MXG sites still had SAS V6 that did
not support COMPRESS=YES, which is required to increase
stored length without DASD increases (as most bytes are
still blanks).
Sometime after 2004, IBM increased header variables
QWHSLOCN and QWHDSVNM and MXG increased INPUT length.
MXG Change 24.136 in 2006 increased these INPUTs to $128
QWHCAID QWHCOPID QPACCOLN QPACLOCN QPACPKID
QLACLOCN QLSTLOCN QMDALOCN QWACNID
This change, 30.032 increased these INPUTs to $128
QWHCEUID QWHCTCXT QWHCROLE QWHCOAUD QWHDRQNM
QPACASCH QPACAANM
This change, 30.032 increased the stored lengths of all
of the DB2 variables listed above that were not already
kept as $128.
-Note added Jun 8: Some DB2 fields can contain an IP
address, Port Number, and a timestamp in this format:
162.123.25.218.44485.120605112901
-------------- ----- ------------
| | |
| | |-- Unique field ( timestamp real
| |
| |-- Port address
|
|- Requester IP Address
One example is QWHCCTKN the new Correlation Token in V10.
-Note added Oct 3, 2012: QWHCCV was restored to $12 by
Change 30.200.
-DB2 variable QWHDRQNM can now contain an ipv6 address,
which is longer than the default kept $16 length, causing
right-most characters to be truncated. Change 22.196 in
Thanks to Fred Wondra, Balboa Insurance, USA.
Thanks to Mark Nakatani, WiPRO, USA.
Thanks to Jim Meurer, Transamerica, USA.
Change 30.031 Requesting IFCIDS=ACCOUNT with IFCIDS from SMF 102 could
READDB2 cause zero observations in some or all of the T102Snnn
VMXGDEL datasets that were requested. This error was in 29.29
Feb 24, 2012 and probably earlier MXG READDB2s.
Mar 4, 2012 -Cosmetic. READDB2 accepts IFCIDS=1 or 2 for STATISTICS
and 3 for ACCOUNT and prints all selected IFCIDS in its
feedback list of what will be selected by READDB2.
Requesting ACCOUNT processes IFCIDs 3 and 239.
Requesting Statistics processes IFCIDs 1 2 202 225 230.
-A strange compiler error, only in SAS V9.2, inserted a
blank when MACRO _LDB2PAT &PDBOUT..DB2GBPAT % was at the
bottom of that list of macro definitions, causing compare
of WORK .DB2GBPAT with WORK.DB2GBPAT to be different, so
VMXGDEL incorrectly deleted that dataset. Relocating that
one line to the top of the list of MACROs happened to
circumvent the error, but that was far too fragile, since
another line relocation could reinstate the error, and as
VMXGDEL is the only part of MXG that does exact compares
of dataset macro tokens that could be impacted by a blank
after the DDNAME/LIBNAME, it now removes the blank.
Thanks to Christopher Bray, Experian Information Solutions, USA.
Change 30.030 Variable VMDSTATE is now decoded by $MGVXADS format.
FORMATS VALUE $MGVXADS
VMACVMXA '00'X='00X:IDLE'
Feb 23, 2012 '08'X='08X:SUSPENDED'
'2C'X='2CX:UNKNOWN'
'37'X='37X:TEST IDLE'
'42'X='42X:READY FOR SELECTION'
'4D'X='4DX:SELECTED FOR PROCESSING'
'58'X='58X:REVIEW IDLE'
'63'X='63X:REVIEW SUSPENDED'
OTHER=?< $HEX2. ?>
;
Thanks to Joe Faska, Depository Trust, USA.
Change 30.029 ODS macro enhanced with USERTEXT= argument so you can add
VMXGODSO options to the generated ODS statement.
Feb 23, 2012
Change 30.028 RMF III dataset ZRBASI Report Class Name/Description vars
VMACRMFV ASIRNM and ASIRDE can have hex zero values, because IBM
Feb 23, 2012 relocated the fields; SVPDCL is now 144 vs the documented
and expected length of 76. Now, ASIRNM is tested for hex
zero and the INPUT moved when found true.
-Same change made for ZRBENC for ENCRNM and ENCRDE.
Change 30.027 Variable SM1209BM, WebSphere Version Number, defaulted to
VMAC120 length $7 from the original equation, but as it can now
Feb 22, 2012 have a value of '7.0.0.15', its length is now set to $8.
Thanks to Rudolf Sauer, T-Systems International GmbH, GERMANY
Change 30.026 %UTILCPLG will copy your .LOG and .LST files, adding the
UTILCPLG date-time into the new file name, when you run MXG on
Feb 17, 2012 Windows or Unix platforms in BATCH execution, so you can
archive and identify each MXG job's log/list files.
The %UTILCPLG; statement must be the last statement in
your xxxxxxxx.sas batch program; the log filename will be
xxxxxxxx-16FEB12-19-51.LOG. The new named files are kept
in the execution directory by default, but arguments let
you store them in other destinations.
Thanks to Chip Parsons, Ingram Books, USA.
Change 30.025 Support for TMON for MQ Version 2.2/2.3/2.4 INCOMPATIBLE.
VMACTMMQ All three version's LMRKVRSN field changed from binary to
Feb 16, 2012 EBCDIC. Version 2.4 changed the fixed offset of @37 to
Feb 24, 2012 @81 but that was NOT documented. The actual data segments
Mar 1, 2012 content was not changed in these three iterations, and
Mar 5, 2012 only Version 2.2 and 2.4 have been validated with data.
-ASG TMON for MQ variables REGNTIME,QAINTS,QAINTE,QAOPENTM
and QACLOSTM were all on the GMT clock, while all other
datetimestamps are on the LOCAL clock. This change uses
the ENDTIME (LOCAL) and the REGNTIME (GMT) to calculate
the GMT offset (REGNTIME can be scores of milliseconds
later than ENDTIME due to differing resolutions):
GMTOFFTM=100*FLOOR((REGNTIME-ENDTIME+10)/100);
and then the GMT datetimes are converted to LOCAL using
REGNTIME=REGNTIME-GMTOFFTM;
-The label for REGNTIME was wrong; it is corrected to be:
REGNTIME='DACLK*WHEN RECORD*WAS WRITTEN'
Thanks to Homayoun Riazi, UHC, USA.
Thanks to Paul Volpi, UHC, USA.
Thanks to Michael Ellingson, UHC, USA.
Thanks to James D. Lieser, UHC, USA.
Change 30.024 New format MG073FE decodes SMF73GEN and R79CGEN FICON
FORMATS Express "Generation", precipitated by Martin's MXG-L post
VMAC73 and Pat's update request and Brian's reminder to include
VMAC79 79's, with some values below provided by Cathy.
Feb 17, 2012 Dec 2: IBM confirmed reports print the hex value, so MXG
Nov 5, 2012 now formats SMF73GEN as hex to be consistent with that
Dec 2, 2012 undocumented-by-IBM design, but RMF Level 2 has NOT been
able to document if any of the unknown values below exist
01X='01X:FEX OP@1GBPS'
02X='02X:FEX OP@2GBPS'
03X='03X:FEX2/FEX4 AUTO@1GBPS'
04X='04X:FEX2/FEX4 AUTO@2GBPS'
05X='05X:FEX4 OP@4GBPS'
06X='06X:????'
07X='07X:FEX8 AUTO@2GBPS'
08X='08X:FEX8 AUTO@4GBPS'
09X='09X:FEX8 OP@8GBPS'
0AX='0AX:????'
0BX='0BX:????'
0CX='0CX:????'
0DX='0DX:????'
0EX='0EX:????'
0FX='0FX:????'
10X='10X:????'
11X='11X:FC_S'
12X='12X:????'
13X='13X:FC_S*FICON EXPRESS8S'
Nov 5: Decimal value 17 and 19 were found by IBM's Martin
Packer although others in IBM support are apparently not
aware of those undocumented values.
Dec 2: APAR OA40204 reports 'FC_?' or blank value may be
printed for channels dynamically added; restart of the
RMF address space will correct to FC_S.
Dec 11: IBM RMF Level 2 confirmed that RMF reports show
value '13' unexplained for FICON Express 8S so the MXG
format was expanded to include that descriptions in the
FORMATS member and above.
Thanks to Dr. H. Pat Artis, Performance Associated, USA.
Thanks to Brian Currah, Independent Consultant, CANADA.
Thanks to Martin Packer, IBM, ENGLAND.
Thanks to Cathy Cronin, IBM, USA.
Thanks to Linda Berkeley, DISA, USA
Change 30.023 A third-party product creates invalid DB2 ID=101 records.
VMACDB2 MXG's error message cites 1994's Change 12.220 and APARs,
VMACSMF because IBM made the same error (IFCID=239 as subtype 0
Feb 14, 2012 versus correct subtype=1) back then. This change reads
the DB2 Header and uses the IFCID to set the SUBTYPE for
ID=101 to circumvent the product's error, so the customer
won't have to wait for their vendor to fix their record.
The error occurs in both DB2 V9.1 and DB2 V10.1 records;
in V10.1, IBM (finally!) populates the first byte of the
SMF header for ID=100/101 with the "record has subtypes"
bit, but that enhancement was not made in this product.
The MXG customer chose to not identify the third-party.
March 7: MXG customer reports vendor corrected the error.
But this change is robust and will be left in place.
July 27: See Change 30.137. This change was NOT robust!
Change 30.022 Cosmetic. Format $MGDB2PK was associated with variable
VMACDB2 QPACAAFG but was lost in 29.29 and 30.01. It is restored
Feb 14, 2012 now but FORMAT QPACAAFG $MGDB2PK.; can be used in your
DB2 reports to "print pretty".
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
====== Changes thru 30.021 were in MXG 30.01 dated Feb 13, 2012=========
Change 30.021 -Numerous updates for processing RACF Unload under ASCII.
EXRAC130 Variables input as $EBCDIC should have been $CHAR in 0500
EXRAC207 and later records; double-question-mark protection for
EXRAC208 missing values has been added.
EXRAC280 -New ACCOUNT variable is created in RACF0220 and RACF0260
EXRAC2B0 as length $40 containing both ACCOUNT1 and ACCOUNT2.
EXRAC508 -Structural support for new RECTYPE values defines all the
EXRAC5B0 macros and creates/updates the members to create datasets
IMACRACF for 0130,0207,0208,0280,02B0,0508 and 05B0, but in this
VMACRACF iteration, none of those records are yet decoded; only
VMXGINIT variable ZDATE is kept in those new datasets.
Feb 12, 2012
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 30.020 Support for MacKinney Systems VTAM SWITCH USER SMF RECORD
EXVTSW01 creates these four datasets:
EXVTSW02 DDDDDD DATASET DESCRIPTION
EXVTSW03
EXVTSW04 VTSW01 VTAMSW01 USER SIGNON EVENT
IMACVTSW VTSW02 VTAMSW02 USER SIGNOFF EVENT
TYPEVTSW VTSW03 VTAMSW03 SESSION START EVENT
TYPSVTSW VTSW04 VTAMSW04 SESSION STOP EVENT
VMACVTSW This support has not yet been data-validated.
VMXGINIT
Feb 10, 2012
Thanks to Eric R. Carlson, Kroger
Change 30.019 Cosmetic. Both members incorrectly had RACFIN as the DD
TYPERACF name, but the correct DDNAME was always IRDBU00 to read
TYPSRACF the unloaded RACF Database, as that is also the program
Feb 10, 2012 name used to create the unloaded file.
Thanks to Donald Williams, UNC Health Care System, USA.
Change 30.018 -Cosmetic, but confusing. The label for TYPE4224 variable
VMAC42 AORMEMNM contained "RENAMED" but the corrected label and
Feb 9, 2012 events are AORMEMNM='ADDED OR*REPLACED*MEMBER*NAME'.
-New variable ADDREPLA contains A or R for ADD/REPLACED.
-Dataset TYPE4225 is created for RENAMEs.
Thanks to Joe Kimberly, Yellow Freight, USA.
Change 30.017 MXG 29.29 ITRM. ERROR: DATASET DB2ST225 IS NOT SORTED.
DOC ITRM SAS Note 45583 documents the error and ultimate fix,
Feb 9, 2012 but it is circumvented, simply, by inserting
%LET EPDBOUT=_SDB2225;
as the first statement in your //SYSIN DD.
Change 30.016 RMF III dataset ZRBLCP did not remove duplicates when it
VMACRMFV was sorted; variables LPARNAME LPARNUM LCPUADDR were
Feb 8, 2012 added at the end of MACRO _BZRBLCP to correct.
Thanks to Wayne Bell, UniGroup, USA.
Change 30.015 MXG 29.29. JCL Proc examples had a trailing comma on the
MXGSAS new (unused, for the future) //MXGTEMP DD statement that
Jan 24, 2012 needed to be removed.
Change 30.014 -Support for APAR OA33947/OA339448 which adds four fields
ASUMTAPE to the TYPE21/PDB.TAPES (tape dismount) dataset:
VMAC21 SMF21MCR='BYTES*READ*BY*CHANNEL'
Feb 8, 2012 SMF21MCW='BYTES*WRITTEN*BY*CHANNEL'
SMF21MDR='BYTES*READ*BY*DEVICE'
SMF21MDW='BYTES*WRITTEN*BY*DEVICE'
-ASUMTAPE was enhanced to also add these four variables,
plus SMF21CRR and SMF21CRW to PDB.ASUMTAPE.
-These fields exist with the APAR (record is longer), but
they are only populated for IBM System Storage TS1140
Tape Drive, device type 3592 Model E07, which has three
new 3592 media types (MEDIA11/12/13) and two new
recording formats EFMT4 (enterprise format 4) and EEFMT4
(enterprise encrypted format 4). MEDIA11/MEDIA12 have a
non-compressed capacity of 4000 GB and MEDIA13 500 GB.
Thanks to Scott S. Throckmorton, SPRINT, USA.
Thanks to John A. Napuarno, SPRINT, USA.
Change 30.013 If you specified RUNWEEK=YES on zOS you may have gotten
BLDSMPDB an MXGWARN message about overlaying weekly datasets. If
Feb 8, 2012 you are using fixed allocations for your weekly datasets
this is normal and can be ignore but, if you are using
GDGs (recommended) and/or putting the weekly to tape it
is not needed. BLDSMPDB now looks (on zOS) to see if
you specified WEEKTAPE=YES or are writing to a GDG and
then suppresses the copying of the weekly PDBs.
Thanks to Peter Farrell, Commerce Bank of Kansas, USA.
Change 30.012 Cosmetic. Removal of the annoying and useless SAS note
VGETOBS RUN STATEMENT HAS NO EFFECT ON PROC SQL, by the insertion
Feb 8, 2012 of a QUIT statement after each PROC SQL. Members touched:
VGETFMT VGETLABL VGETLEN VGETLIBS VGETOBS VGETVAR
VMXGCNFG VMXGDSNL VMXGENG VMXGLBIN VMXGOPTR VMXGPPDS
VMXGUOW ANALID
Thanks to Nick Johns, Sainsbury's Supermarkets Ltd, ENGLAND.
Change 30.011 CRITICAL ERRROR FOR JES3 BUILDPD3 users with MXG 29.29:
BUIL3005 Line 483 in BUIL3005 MUST BE CHANGED TO (MULTIDD=' ').
Feb 8, 2012 That line in 29.29 had MULTIDD='Y' which caused the PDB
library datasets PDB.JOBS/PDB.STEPS/PDB.PRINT to all be
COMPLETELY WRONG. Change 29.263 correctly made the change
to the BUILD005 member for JES2 but was reversed in the
JES3 BUIL3005 member.
Thanks to Rob Hermes, Sentry Insurance, USA.
Change 30.010 Variable STFBIT06 was incorrectly set equal to STFBIT05.
VMAC7072 Variable STFBIT07='SMF70GAU*VALID?' is created and kept.
Feb 8, 2012
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.009 -Support for SMF 119 Subtype 6 z/OS 1.13 INCOMPAT. Doesn't
VMAC119 cause an error, but values in 2nd and subsequent segments
VMXGIPV6 are trashed because MXG did not protect for a change in
Jan 31, 2012 length of the subtype 6 record.
Feb 7, 2012 -Subtype 2 TTAPLDAT variable supported.
Jul 12, 2012 -Support for all IPV6 addresses in TYPE119 datasets, using
the VMXGIPV6 %macro to convert the $CHAR16 hex field into
the 39-character format. Some IPV6 addresses did exist in
variables with names ending in 6, but this new suite of
variable's names end with IPV6.
-Only these SMF 119 subtypes have been validated with data
1,2,3,5,6,7,10,20,21,70 and 72.
-The subtype 2 record has an old note suggesting that
Because this information duplicates all information
contained in the TCP connection initiation (subtype 1)
record, only collect the TCP connection termination
record (subtype 2).
-Jul 13: Variable UCLIPV6 was not kept until now; it was
incorrectly spelled UCLIPB6 but could be added using
_KT11910.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Robert Hamilton, Chemical Abstracts Service, USA.
Thanks to Jose Neto, Public Authority Civil Info, KUWAIT.
Thanks to Arylon Brooks, Verizon Wireless, USA.
Thanks to Scott S. Throckmorton, SPRINT, USA.
Change 30.008 CICS/TS 4.2 ERROR INVALID STILEN for STID=116 Statistics
VMAC110 record was an MXG coding error exposed by the 156 bytes
Jan 31, 2012 of new data that MXG had overlooked, causing the CICSJS
dataset to have no observations created, and possible MXG
skipping subsequent statistics segments in that record.
New variables added to CICSJS dataset are:
SJSGCPOL='GC*POLICY'
SJSHEAPC='CURRENT*HEAP'
SJSHEAPI='INITIAL*HEAP'
SJSHEAPM='MAXIMUM*HEAP'
SJSHEAPO='HEAP*OCCUPANCY'
SJSHEAPP='PEAK*HEAP'
SJSHVMCL='JVM*CREATION*DATETIME*LOCAL'
SJSJVMCG='JVM*CREATION*DATETIME*GMT'
SJSMAJCP='TOTAL*CPU IN*MAJOR*GC'
SJSMAJFR='STORAGE*FREED*BY*MAJOR GC'
SJSMAJGC='MAJOR*GC*COLLECTIONS'
SJSMINCP='TOTAL*CPU IN*MINOR*GC'
SJSMINFR='STORAGE*FREED*BY*MINOR GC'
SJSMINGC='MINOR*GC*COLLECTIONS'
SJSSYTHN='NR WAITING*ON*SYS*THREAD'
SJSSYTHP='PEAK*WAITING*ON SYS*THREAD'
SJSSYTHU='SYSTEM*THREAD*USE*COUNT'
SJSSYTTM='TOTAL*WAIT*SYSTEM*THREAD'
SJSSYTCN='WAITS ON*SYSTEM*THREAD'
Thanks to Thomas H. Puddicombe, CSC, USA.
Change 30.007 PMSTA01/PMSTA02 DB2 Statistics reports with INTERVAL=DATE
ANALDB2R created multiple observations for each date because SHIFT
VMXGDBSS was in the SUMBY= list in VMXGDBSS. That SUMBY argument
Jan 29, 2012 is now a parameter with the current default values and
uses the new parameter in ANALDB2R when required by the
requested INTERVAL value. Also, errors in page numbering
were cosmetic - no data was skipped - just page numbers
were, due to an extra LINK in the heading routine.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 30.006 Support HSM USER SMF changes (COMPATIBLE) in z/OS 1.12.
VMACHSM -Dataset HSMDSRST:
Jan 29, 2012 DSRFRBKT DSRFRBKF DSRFRRCT DSRFRRCF
-Dataset HSMFSRBO:
FSRF9ATT FSRSRCDV FSRRETDY FSRDLMD FSRDLUD FSRBDATE
FSRDATRD FSRDLMD DSRDATED
-Dataset HSMFSRST:
FSRF9ATT FSRSRCDV FSRRETDY
FSRDLMD FSRDLUD FSRBDATD FSRDATRD FSRDLMD
-Dataset HSMVSRST:
VSRFRBKT VSRFRBKF VSRFRRCT VSRFRRCF VSRDATED
-Dataset HSMWWFSR:
WFSRCONT WFSRDATR WFSRRMTS WFSRDATE WFSRDATS WFSRRSTS
WFSRRETS WFSRXMNT WFSRHOST WFSRF9AT
-These existing variables still contain julian date values
DSRDATE FSRDLM FSRDLU FSRBDATE FSRDATR VSRDATE
but new corresponding SAS DATE variables are now created
with DATE9. format (prints 29JAN2012) for prettiness and
so they can be directly subtracted for delta-days:
DSRDATED FSRDLMD FSRDLUD FSRBDATD FSRDATRD VSRDATED
These date variables were never kept; they are now kept
and are now SAS Date Variables with DATE9. format.
WFSRDATR WFSRDATS WFSRDATE
Variable FSRDATE is always missing; it was sometimes
missing and sometimes 0 (which printed 01JAN1960).
-Datasets HSMFSRTP and HSMWWVOL had no observations so
they have not been validated.
Thanks to Randall R. Schlueter, First Data Corporation, USA.
Change 30.005 If you used UTILBLDP to create your BUILDPDB code and
UTILBLDP you used the MXGINCL parameter to include members that
BLDSMPDB were not in the default list, they were ignored. Now
Jan 29, 2012 they will not be ignored. They can alternatively be in
the INCLAFTR= parameter (where they wouldn't have been
ignored). When BLDSMPDB used the output of UTILBLDP as
as the source of the BUILDPDB code, it didn't use the
AUTOINC= parameter, but now it does. With this change
members can be included after the BUILDPDB step from one
one of these three parameters:
UTILBLDP - MXGINCL or INCLAFTR
BLDSMPDB - AUTOINC
But, if the same member appears in more than one it will
be executed more than once.
-MXGINCL should primarily be used to remove these members
that are automatically included:
ASUMUOW ASUMCICX ASUM70PR ASUMCACH ASUMTAPE
ASUMTMNT ASUMTALO ASUMDBAA ASUMDBSS
One or more can be removed if you choose. The same is
true of the AUTOINC parameter in BLDSMPDB, but when you
build the BUILDPDB code with UTILBLDP, that parameter is
not used.
Thanks to Peter Farrell, Commerce Bank of Kansas, USA.
Change 30.004 Some FICON-related variables values were wrong in TYPE73.
VMAC73 RMF documentation implied that DURATM should be used for
Jan 27, 2012 the interval duration, but the Channel Path Measurement
Interval SMF73PTI should have been used, and subtraction
from EOC and ETC were also wrong. Fortunately, the input
variables to these calculated variables are in dataset
TYPE73 so they can be recalculated with this SAS code:
CHFRATE=SMF73EOC/SMF73PTI;
IF SMF73EOC GT 0 THEN CHFACTV=SMF73EOS/SMF73EOC;
ELSE SMF73EOC=.;
CHFDFER=SMF73EOD/SMF73PTI;
CHFXRATE=SMF73ETC/DURATM;
IF SMF73ETC GT 0 THEN CHFXACTV=SMF73ETS/SMF73ETC;
ELSE SMF73ETC=.;
CHFXDFER=SMF73ETD/SMF73PTI;
without rebuilding the TYPE73 dataset from SMF records.
And the RMF documentation will (hopefully) be revised.
Thanks to Steve Olenik, IBM System z Processor Performance, USA.
Change 30.003 Spurious XAM INVALID CPU RECORD messages were due to a
VMACXAM mislocated SKIP=0; statement if SEGLEN=100. This MXG
Jan 27, 2012 error caused XAMCPUBY to have only one observation.
Thanks to Robert Obee, IMSHealth, USA.
Change 30.002 Change 29.238 typo in line 250:
VMACM204 IF ID= _M204LOG OR _IDM204L THEN DO;
Jan 27, 2012 was corrected to
IF ID= _M204LOG OR ID= _IDM204L THEN DO;
So that the correct Model 204 dataset was output.
Thanks to Steve Bagshaw, Marks & Spencer, ENGLAND.
Change 30.001 MXG Format MGD319F had reversed decoding the Encryption
FORMATS type. The correct values are: '00'X:DES, '40'X:AES.
VMAC102 -Variable QW0319UR is created from first bit of QW0319FL,
Jan 25, 2012 QW0319FLL is now used for the input of QW0319FL (so that
any new bits are available), and QW0319FL will be either
'00'X or '40'X (unless IBM changes its definition).
Thanks to Jason Bierman, Great Lakes Educational Loan Services, USA.
LASTCHANGE: Version 30.
=========================member=CHANGE29================================
/* COPYRIGHT (C) 1984-2012 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 29.29 is dated Jan 23, 2012, thru Change 29.307.
Second MXG Version 29.29 is dated Jan 18, 2012, thru Change 29.301.
First MXG Version 29.29 was dated Jan 17, 2012, thru Change 29.298.
MXG Version 29.09 was dated Jan 4, 2012, thru Change 29.291.
MXG Version 29.08 was dated Dec 20, 2011, thru Change 29.284.
MXG Version 29.07 was dated Nov 24, 2011, thru Change 29.262.
Second MXG Version 29.07 was dated Nov 21, 2011, thru Change 29.259.
First MXG Version 29.07 was dated Nov 14, 2011, thru Change 29.253.
MXG Version 29.06 was dated Sep 8, 2011, thru Change 29.204.
First MXG Version 29.06 was dated Sep 1, 2011, thru Change 29.198.
MXG Version 29.05 was dated Jul 11, 2011, thru Change 29.151.
MXG Version 29.04 was dated May 17, 2011, thru Change 29.116.
Final MXG Version 29.03 was dated Apr 19, 2011, thru Change 29.094.
First MXG Version 29.03 was dated Apr 11, 2011, thru Change 29.086.
Early MXG Version 29.03 was dated Apr 4, 2011, thru Change 29.077.
MXG Version 29.02 was dated Mar 1, 2011, thru Change 29.050.
MXG Version 29.01 was dated Feb 4, 2011, thru Change 29.022.
First MXG Version 29.01 was dated Feb 3, 2011, thru Change 29.020.
Annual MXG Version 28.28 was dated Jan 18, 2011, thru Change 28.331.
MXG Newsletter FIFTY-SEVEN is dated Jan 18, 2011.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 29.29 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 29.29.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================
I. MXG Version 29.29 dated Jan 23, 2012, thru Change 29.307.
Major enhancements added in MXG 29.29, dated Jan 23, 2012
TYPEIMS 29.307 Support for IMS Version 12: Adds ZIIP/ZAAP CPU times.
RMFINTRV 29.305 INTERVAL=SHIFT generated warnings & incorrect output.
TYPETMS5 29.304 USER ABEND 1234 can be bypassed for TMSCLEAN input.
IMACICRD 29.302 Comment within comment block if default used.
Major enhancements added in MXG 29.29, dated Jan 18, 2012
TYPENDM 29.301 Old Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
TYPERMFV 29.300 Wrong ASMRMFV in first 29.29, VMACRMFV updated.
Major enhancements added in MXG 29.29, dated Jan 17, 2012
VMACSMF 29.290 USER ABEND 69 due to invalid SMFTIME now bypassed.
TYPENDM 29.295 NDM/Connect-Direct V5.0 added jobname/jctjobid.
TYPEXAM 29.294 Support for VNDNIC, LPARNW, USVCPU segments.
TYPE110 29.293 Support for CICS Statistics STID=143 and 144.
ASMDBLKU 29.289 ASMDBLKU, ASM version of UDEBLOCK, revised.
ASMRMFV 29.297 Continued RMF III enhancements.
TYPERMFV 29.297 Continued RMF III enhancements.
TYPEDCOL 29.296 DCOLLECT support updated to execute on ASCII.
BLDSMPDB 29.292 Support for execution under unix.
VMXGALOC 29.292 Support for execution under unix.
VMXGPPDS 29.298 Compare contents of multiple PDS/PDSE libraries.
Major enhancements added in MXG 29.08, dated Dec 22, 2011
ANALGRID 29.284 Color-intense grid of "hot spots" of any variable.
(Examples http://www.mxg.com/downloads, ANALGRID.)
ASUM4HRS 29.268 %MACRO calculates "Four Hour" running average values
(or running average for any number of hours).
VMAC30 29.281 CPUTASKALLTM and PCTTASKTIME added SMFINTRV/TYPE30_V.
("Task Time" is recommended by IBM for analysis).
ASMTAPEE 29.280 "YOU SPECIFIED ASCENV" Assembly error with z/OS 1.13.
(MXGTMNT does NOT need to be reassembled on 1.13)
TYPE16 29.264 Support for DFSORT z/OS 1.13 COMPAT new variables.
TYPESVIE 29.273 Support for SYSVIEW subtypes 34 and 35.
TYPETLMS 29.269 Support for CA TLMS tape library 2003 record changes.
TYPETMS5 29.274 CA-1 TMS Extended Format TMC records have no impact.
TYPE120 29.272 SM1209CI and SM1209CX can be negative.
MXGSASxx 29.265 MXGTEMP temporary DDNAME/FILENAME added to MXG JCL.
ASMRMFV 29.279 RMF III RCD INPUT STATEMENT EXCEEDED error.
Major enhancements added in MXG 29.07, dated Nov 24, 2011
TYPEIMST 29.230 Further updates to IMS56FA transaction processing.
SMFSRCH 29.236 SMFSRCH, search SMF records for text, print all obs.
TYPE7072 29.220 Support for z/OS 1.13 (WAS IN MXG 29.03 or later).
TYPETMO2 29.244 Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE.
TYPEQACS 29.208 Support for IBM i-series (AS400), more than 32 CPUs.
TYPEDB2 29.213 Support for DB2 V10 IFCID 225 Subtype4 INCOMPATIBLE.
TYPETPMX 29.211 Support for Throughput Manager APAR TMT6214, st=16.
TYPEBETA 29.233 Support for BETA93 Version 4.1.0 subtype 25 changes.
TYPEAXWY 29.231 Support for Axway CFT/ESA (Cross File Transfer) SMF.
TYPEPOC 29.219 Support for Tivoli Workload Schedulr Ver 8.3 INCOMPAT
TYPEFERT 29.247 Support for ZEN FERRET V2.3 (INCOMPATIBLE).
TYPEMPLX 29.247 Support for ZEN IMPLEX V5.1 (COMPATIBLE)
TYPEZOSA 29.247 Support for new ZEN OSA MONITOR V1.3 SMF records.
TYPEITRV 29.223 Support for APAR OA37114, ITRF (OMEGAMON IMS V420)
TYPE70x 29.239 Variable SHIFT (used as "ZONE") added to all RMF.
TYPEDB2 29.209 DB2 V10 ID=100 ST=1 INVALID HEADER.
TYPEVMXA 29.207 z/VM MONWRITE Broken Control Rec if 2.14 (SCALL) rec.
TYPE102 29.235 IFCID=22 in Change 28.234 wrong in DB2 V9.
TYPSXAM 29.249 TYPSXAM didn't sort all XMdddddd datasets to the PDB.
ASUM113 29.243 Calculation of ESTSCP1M incorrectly had small values.
ASMRMFV 29.217 Enhanced RMF III RCDSD section support, CHAR->NUM fix
TYPE120 29.240 Length of Character Variable SMF1209FH can't change.
TYPEaaaa 29.238 All USER SMF have MACRO _IDaaaa nnn as SMF record id.
TYPE16 29.232 DFSORT variables ICEMNVLX, ICEMNVLY, ICEMNVLZ wrong?
TYPETPMX 29.229 TPMCA7JN, TPMPI, and TPMDUEOT may be wrong.
TYPE1415 29.226 False ERROR.TYPE1415.DEFECTIVE.EXTENDED... log msg.
TYPEDB2 29.225 INVALID DB2 V10 QMDA segment for QMDAPTYP='JCC'.
TYPE80A 29.223 New TOKENIDs starting with NOxxxx (NOCPUTIMEMAX, etc)
TYPE110 29.221 CICS Statistics datasets CICDB2GL,CICSMDSA, corrected
TYPE119 29.215 Variables T119STCK/TISSTCK/TIESTCH were still GMT.
TYPE78PA 29.214 Values in TYPE78PA ending with TOTL could be wrong.
TYPE845 29.212 Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records.
Major enhancements added in MXG 29.06, dated Sep 8, 2011
SAS V9.3 29.159 Support for SAS Version 9.3 - SAS Hot Fix E80004:
SAS V9.3 Hot Fix E80004 (for SAS Problem Note SN43828) is REQUIRED
to correct an error in the %MACRO compiler, which is SAS portable
code, so the Hot Fix is required for ALL platforms for SAS V9.3.
The %MACRO compiler error is in processing %LET statements.
While only two MXG members actually failed in MXG QA tests, ANY
use of %LETs can fail in MXG (or in your own %MACRO code).
MANY 29.169 MXG ODS HTML ASCII examples failed if no PATH=.
Seen first with SAS V9.3; complete revision of MXG ODS HTML examples
with new %macros with consistent arguments, etc, for all platforms.
TYPEVMXA 29.172 Support for APAR VM64961, SMF 113 in z/VM MONWRITE!!
TYPE113 29.176 Support for APAR OA36816, SMF 113 HIS DATALOSS parm.
IBM now recommends SMF 113 always be created.
TYPEIMST 29.162 Validation of TYPEIMST, many changes for IMS56FA.
Finally: IMS Transaction CPU/Response from ONE IBM IMS LOG RECORD.
TYPEADAB 29.189 Support for Software AG's ADABAS SMF user record.
TYPECFS 29.186 Support for InfoSphere Classic Federation Server SMF.
TYPE23 29.177 Support for APAR OA35175, logstream stats in SMF 23.
TYPE30 29.175 Support for APAR OA35617, SMF30CRM VELOCITY MNGED?
TYPE30 29.174 Support for APAR OA34895, EXCP/IOTM Missed, SMF Lock.
TYPE57 29.173 Support for APAR OA36966, JES3 expanded NJEJOBNO.
TYPEIDMS 29.156 Support for IDMS/R Performance Monitor Version 18.
TYPEVMXA 29.163 z/VM Crypto Record (5,10) with PRCAPMCT=6 error.
TYPE115 29.161 MXG 29.03-MXG 29.05 dataset MQMCFMGR was wrong.
TYPEDM 29.158 NDM-CDI Version 5 new fields supported.
TYPE110 29.155 CICS/TS 4.2 Statistics variables overlooked, added.
VMXGSUM 29.154 AUTOCALL %macro's %CMPRES/%QCMPRES removed.
TYPE111 29.153 UNDECODED CTGRECID message, possible CPU loop.
TYPE7072 29.152 VMSYSTEM='Y' RMF records validated, and revised.
RMFINTRV 29.194 Stats on Page Dataset Slot Usage added to RMFINTRV.
ASUM113 29.193 zVM MONWRITE VXPRCMFC (SMF 113 for z/VM) included.
ASUMUOW 29.188 Case 4 example prevents blank TRANNAME in ASUMUOW.
ASMRMFV 29.187 Do not use ASMRMFV in MXG29.05, fails with 0C4 ABEND.
GRAFWRKX 29.185 Workload RMFINTRV graph's update uses new workloads.
Major enhancements added in MXG 29.05, dated Jul 11, 2011
TYPE110 29.135 Support for CICS/TS 4.2. CICSTRAN supported in 29.03.
TYPE110 29.149 Support for CICS/TS 4.2. MNSEGCL=5 requires 29.05.
TYPE120 29.136 Support for WebSphere WAS 8.0 (COMPATIBLE).
TYPE70 29.127 Support for z/OS 1.12 VMGUEST option, CPU Time in 70.
TYPEIMST 29.144 IMS Transactions in IMS56FA, replaces JCLIMSL6!!!
TYPETIMS 29.123 Support for TMON/IMS Version 3.0 (INCOMPATIBLE).
TYPEPOEX 29.134 Support for Informatica's POWER EXCHANGE SMF record.
TYPEDB2 29.140 New LUUVTIME instead of QWACBSC for start time.
TYPE90A 29.142 Enclave variables decoded in TYPE9030 dataset.
TYPEVMXA 29.133 z/VM LPARNAME, LPNUMBER kept in PDB.VMXAINTV.
UTILARCH 29.137 New UTILARCH archives data (like Outlook archive).
TYPEDB2 29.131 DB2PARTY added to DB2ACCTP, Rollup impact documented.
TYPEDB2 29.128 DB2 INVALID DISTRIUTED HEADER message corrected.
TYPEDB2 29.121 QWHADSGN/QWHAHAMN were sometimes blank.
TYPE102 29.125 DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED error.
TYPEVMXA 29.129 MXGERROR DM 5 RC 10 UNDECODED PRCAPMCT due to IBM.
TYPEXAM 29.126 XAM variables in VXSYTEP2 were not all input/kept.
TYPE111 29.124 Variables CTGIAREQ/CTGLALRQ revised keeps.
ANALDB2R 29.145 Performance and Reporting Enhancements
Major enhancements added in MXG 29.04, dated May 17, 2011
TYPE105 29.100 Support for GDPS Global Mirror V3R8 SMF 105 record.
DB2ACCT 29.111 DB2 CICS TRAN name could be wrong, now from QWHCCV.
TYPEIMSA 29.110 the exit _IMSTRN invocation was accidentally removed.
BUIL3005 29.106 JES3 PDB.JOBS variable JOBCLAS8 has after change.
VMXGSRCH 29.103 RESULTS=FINDVAR finds all datasets with a variable.
TYPE70PR 29.098 Counts ICFCPUS/IFLCPUS/IFACPUS/ZIPCPUS too high.
TYPE110 29.097 INPUT EXCEEDED 110-2 MNSEGLC=5 with DPL segment
Major enhancements added in MXG 29.03, dated Apr 19, 2011
TYPE110 29.094 1st MXG 29.03 ONLY. CICSTRAN CPUTM plus fields WRONG.
TYPE116 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPE115 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPEBBMQ 29.056 Support for MainView MQ (MVMQ) Version 4.4.
TYPEQACS 29.078 Support for OS/400, AS/400 Version 7.1 (INCOMPATIBLE)
TYPE110 29.076 CICS CPUTM exceeds ELAPSTM, zAAP/zIIP Equivalent time
TYPE120 29.081 Support for User Field in SMF 120 Subtype 9 record.
TYPETPMX 29.071 Support for Throughput Manager subtype 10 and 16.
TYPENTSM 29.075 Support for 62 new objects and 1425 new NT metrics.
UTILVREF 29.075 MXG now creates DATASET names up to 32 characters.
BUILDPDB 29.068 MXG 28.28-29.02. ABEND=JCL obs missing in PDB.JOBS.
TYPERACF 29.067 RACF UNLOAD dataset RACF0270 UID limit variables.
TYPEBETA 29.059 Support for Beta 93 Version 4.2 subtypes 25/50.
TYPE30 29.058 Variable CPUCEPTM always now set to a missing value.
MONTHxxx 29.052 SAS 9.1.3 Only. %QCMPRES needed versus %CMPRES.
TYPE85 29.093 INPUT STATEMENT EXCEEDED st 79, z/OS 1.12.
ASUM70PR 29.092 ZIPCPUS/IFACPUS included parked time.
TYPEVMXA 29.092 z/VM new PDB.VXINTUSR sums all engines for each VM.
Major enhancements added in MXG 29.02, dated Mar 1, 2011
VSETMNTH 29.041 POSSIBLE LOSS OF MONday DATA IN FEBRUARY MONTHLY PDB.
(Unfortunately, EVEN with the newest MXG 29.01).
The MXG2828 or MXG2901 ftp credentials are still valid;
you can download 29.02 and copy the two members you need
(VSETMNTH, and BUILDxxx or BLDSMPDB), or you can ftp
only those specific files to correct the error, for this
month and for future months, or you can install 29.02.
Without these updated members/29.02, future MONTHly's can
also be missing one or more day's PDBs in your MONTH PDB.
The complete details are in Change 28.041, below.
TYPENDM 29.042 Support for NDM-CDI Version 5 records (COMPATIBLE).
VMACDB2H 29.037 DB2 V9.1 false "INVALID DISTRIBUTED HEADER" message.
TYPE30 29.034 Invalid data for SMF30RGT is true, circumvented.
TYPECIMS 29.033 Support for IMF Version 4.5 is in place.
TYPE0 29.032 PDB.IPLS, now, DOES always report a SYSTEM IPL.
TYPEDB2 29.031 DB2 V9.2 only, most QBGxxx variables DB2GBPST wrong.
TYPEVMXA 29.026 Support for zVM APAR VM64794 (COMPATIBLE).
TYPE30 29.025 Small negative CPUUNITS now set to zero.
TYPE26J2 29.024 Cosmetic: INREASON NOT DECODED messages corrected.
Major enhancements added in MXG 29.01, dated Feb 4, 2011
These two impacted MONTHLY build:
MONTHBLD 29.017 SERIOUS ERROR CORRECTED: last day's PDB skipped.
BLDSMPDB 29.017 LIBNAME WEEK1 not found corrected.
These two eliminate possibility of NOTSORTED errors:
BLDSMPDB 29.008 SORTEDBY=NO default to eliminate NOTSORTED exposure.
WEEKBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
MONTHBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
TYPEENDV 29.012 Support for Endeavor Version 14 (INCOMPATIBLE).
TYPE111 29.001 Support for IPIC creates obs in TY111CXI.
TYPE115 29.015 Support for MQ Version 7 compression statistics.
TYPE89 29.002 Support for APAR OA31615, zIIP/zAAP times added,
and false error messages are eliminated.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
MXG 26.03 thru MXG 29.09 will execute under SAS Version 9.3, on
all supported platforms, but SAS V9.3 Hot Fix E80004 is REQUIRED
(for SAS Problem Note SN43828) to correct an error in the %MACRO
compiler, which is SAS portable code, so the Hot Fix is required
for ALL platforms for SAS V9.3.
The %MACRO compiler error is in processing %LET statements. While
only two MXG members failed repeatedly in MXG QA tests on z/OS,
there were random %LET errors in ASCII QA tests, so ANY use of
%LET statement on ANY platform are vulnerable to this error, as
the %MACRO compiler is SAS portable code, used on all platforms.
With Hot Fix E80004, the full MXG QA test stream executed with no
errors, and there were no new warnings on z/OS. Users of ODS will
want MXG 29.06, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, now corrected in MXG Version 29.06.
See Changes 29.159 and 29.169.
To find the Hot Fix for all platforms, open http://www.sas.com,
and then search SAS Notes for 43828 (NOT SN-43828, NOT E80004),
and then Pull Down the Hot Fix tab.
MXG 26.03 thru MXG 29.29 will execute under SAS V9.2, or with
SAS V9.1.3 with Service Pack 4, on all supported SAS platform.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS/DB2 Decompression Infile Exit.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN platform.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level B" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I can not guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3, FOR BOTH OF US, TO AVOID FIXED PROBLEMS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS Hot Fix SN43828 is required; see text of Change 29.159.
With that hot Fix, MXG Versions 26.03 or later should execute
under SAS V9.3 on all platforms without error.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2 and V9.3
are interchangeable and can be read/written by any of those
versions, provided they are on the same platform. (On ASCII,
the 32-bit and 64-bit SAS versions are NOT the same "platform".)
SAS V9.3 did change ODS processing defaults and syntax that
might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support V9.3 ODS, and MXG 29.06 is STRONGLY recommended for ODS
with SAS V9.3.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, and V9.2.
V9.2-created "PDBs" can be read/written by SAS V8.2 or V9.1.3,
and vice versa.
MXG Versions 26.03+ execute with SAS V9.2 with NO (new) WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG QA tests are executed on z/OS with SAS V9.1.3 and V9.2 and
on Windows XP with 32-bit INTEL, and on Windows Seven Ultimate
32-bit and 64-bit OS on 64-bit hardware, but MXG is installed
on many more hardware and software platforms: since they all work,
we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.4 requires MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for "MXG Support for WPS Software"
IV. MXG Version Required for Hardware, Operating System Release, etc.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2010 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2010 29.08
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.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 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
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 29.05
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 Full plus Compressed. Nov 1, 2010 28.07*
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 28.28*
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 29.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
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Webshpere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.04
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
IMS log 11.0 Apr 1, 2010 28.02*
IMS log 12.0 Jan 23, 2012 29.29*
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 20.04
The Monitor for DB2 Version 4.0 22.10
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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
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
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
IMF 4.5 (for IMS 11.1) (No change since 4.4) 27.07
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 29.07
V. Incompatibilities and Installation of MXG 29.29.
1. Incompatibilities introduced in MXG 29.29:
a- Changes in MXG architecture made between 29.29 and prior versions
that can introduce known 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 JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 29.29 after MXG 28.28:
Dataset/
Member Change Description
Many 29.169 MXG ODS HTML ASCII examples failed if no PATH=.
ANALDB2R 29.145 Performance and Reporting Enhancements
ASMDBLKU 29.289 ASMDBLKU, ASM version of UDEBLOCK, revised.
ASMRMFV 29.187 Do not use ASMRMFV in MXG29.05, fails with 0C4 ABEND.
ASMRMFV 29.217 Enhanced RMF III RCDSD section support.
ASMRMFV 29.279 RMF III RCD INPUT STATEMENT EXCEEDED error.
ASMTAPEE 29.280 "YOU SPECIFIED ASCENV" Assembly error with z/OS 1.13.
ASUM113 29.193 zVM MONWRITE VXPRCMFC (SMF 113 for z/VM) included.
ASUM113 29.243 Calculation of ESTSCP1M incorrectly had small values.
ASUM4HRS 29.268 %MACRO calculates "Four Hour" running average values
ASUM70PR 29.092 ZIPCPUS/IFACPUS included parked time.
ASUMMIPS 29.237 Calculation of ZIPUSED and ZIEUSED incorrect.
ASUMUOW 29.007 Doc: variables required for ASUMUOW/ASUMCICX.
ASUMUOW 29.009 ASUMUOW fails is //CICSTRN,//DB2ACCT on tape.
ASUMUOW 29.188 Case 4 example prevents blank TRANNAME in ASUMUOW.
BLDSMPDB 29.008 SORTEDBY=NO default to eliminate NOTSORTED exposure.
BLDSMPDB 29.017 LIBNAME WEEK1 not found corrected.
BLDSMPDB 29.246 A dash in filename text tripped up %UPCASE().
BLDSMPDB 29.292 Support for execution under unix.
BUIL3005 29.106 JES3 PDB.JOBS variable JOBCLAS8 has after change.
BUILDPDB 29.068 MXG 28.28-29.02. ABEND=JCL obs missing in PDB.JOBS.
DB2ACCT 29.111 DB2 CICS TRAN name could be wrong, now from QWHCCV.
DB2ACCTP 29.053 Doc. QWACxxxx variables in DB2ACCTP always missing.
EXITCICS 29.064 Rare (one-site) error in INFILE exit corrected.
GRAFWRKX 29.185 Workload RMFINTRV graph's update uses new workloads.
IMACICRD 29.302 Comment within comment block if default used.
JCLSPLIT 29.241 Example to split SMF had 102 records copied twice.
MONTHBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
MONTHBLD 29.017 SERIOUS ERROR CORRECTED: last day's PDB skipped.
MONTHxxx 29.052 SAS 9.1.3 Only. %QCMPRES needed versus %CMPRES.
MXGSASxx 29.265 MXGTEMP temporary DDNAME/FILENAME added to MXG JCL.
RMFINTRV 29.005 Doc: INTERVAL=QTRHOUR became default in 28.01.
RMFINTRV 29.194 Stats on Page Dataset Slot Usage added to RMFINTRV.
RMFINTRV 29.305 INTERVAL=SHIFT generated warnings & incorrect output.
SAS V9.3 29.159 Support for SAS Version 9.3 - SAS Hot Fix SN43828.
SMFSRCH 29.236 SMFSRCH, search SMF records for text, print all obs.
TYPE0 29.032 PDB.IPLS, now, DOES always report a SYSTEM IPL.
TYPE102 29.125 DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED error.
TYPE102 29.235 IFCID=22 in Change 28.234 wrong in DB2 V9.
TYPE105 29.100 Support for GDPS Global Mirror V3R8 SMF 105 record.
TYPE110 29.076 CICS CPUTM exceeds ELAPSTM, zAAP/zIIP Equivalent time
TYPE110 29.094 1st MXG 29.03 ONLY. CICSTRAN CPUTM plus fields WRONG.
TYPE110 29.097 INPUT EXCEEDED 110-2 MNSEGLC=5 with DPL segment
TYPE110 29.135 Support for CICS/TS 4.2 was in 29.03.
TYPE110 29.155 CICS/TS 4.2 Statistics variables overlooked, added.
TYPE110 29.221 CICS Statistics datasets CICDB2GL,CICSMDSA, corrected
TYPE110 29.293 Support for CICS Statistics STID=143 and 144.
TYPE111 29.001 Support for IPIC creates obs in TY111CXI.
TYPE111 29.124 Variables CTGIAREQ/CTGLALRQ revised keeps.
TYPE111 29.153 UNDECODED CTGRECID message, possible CPU loop.
TYPE113 29.060 z196 Est Finite CPI, Est SCPL1m calcs revised.
TYPE113 29.080 New variables and label revisions.
TYPE113 29.176 Support for APAR OA36816, SMF 113 HIS DATALOSS parm.
TYPE115 29.015 Support for MQ Version 7 compression statistics.
TYPE115 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPE115 29.161 MXG 29.03-MXG 29.05 dataset MQMCFMGR was wrong.
TYPE116 29.057 Support for Websphere for z/OS MQ Version 7.0.1.
TYPE119 29.215 Variables T119STCK/TISSTCK/TIESTCH were still GMT.
TYPE120 29.081 Support for User Field in SMF 120 Subtype 9 record.
TYPE120 29.136 Support for WebSphere WAS 8.0 (COMPATIBLE).
TYPE120 29.240 Length of Character Variable SMF1209FH can't change.
TYPE120 29.272 SM1209CI and SM1209CX can be negative.
TYPE1415 29.226 False ERROR.TYPE1415.DEFECTIVE.EXTENDED... log msg.
TYPE16 29.232 DFSORT variables ICEMNVLX, ICEMNVLY, ICEMNVLZ wrong?
TYPE16 29.264 Support for DFSORT z/OS 1.13 COMPAT new variables.
TYPE19 29.183 Variables SMF19TRK and SMF19TRM were wrong.
TYPE23 29.177 Support for APAR OA35175, logstream stats in SMF 23.
TYPE26J2 29.024 Cosmetic: INREASON NOT DECODED messages corrected.
TYPE30 29.025 Small negative CPUUNITS now set to zero.
TYPE30 29.034 Invalid data for SMF30RGT is true, circumvented.
TYPE30 29.058 Variable CPUCEPTM always now set to a missing value.
TYPE30 29.174 Support for APAR OA34895, EXCP/IOTM Missed, SMF Lock.
TYPE30 29.175 Support for APAR OA35617, SMF30CRM VELOCITY MNGED?
TYPE57 29.173 Support for APAR OA36966, JES3 expanded NJEJOBNO.
TYPE70 29.127 Support for z/OS 1.12 VMGUEST option, CPU Time in 70.
TYPE7072 29.077 z/OS under z/VM: MXG messages, nonexistent RMF data.
TYPE7072 29.152 VMSYSTEM='Y' RMF records validated, and revised.
TYPE7072 29.220 Support for z/OS 1.13 (REQUIRES MXG 29.03 or later).
TYPE70PR 29.098 Counts ICFCPUS/IFLCPUS/IFACPUS/ZIPCPUS too high.
TYPE70x 29.239 Variable SHIFT (used as "ZONE") added to all RMF.
TYPE78PA 29.214 Values in TYPE78PA ending with TOTL could be wrong.
TYPE80A 29.223 New TOKENIDs starting with NOxxxx (NOCPUTIMEMAX, etc)
TYPE845 29.212 Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records.
TYPE85 29.093 INPUT STATEMENT EXCEEDED st 79, z/OS 1.12.
TYPE89 29.002 Support for APAR OA31615, zIIP/zAAP times added.
TYPE89 29.178 Variable CECSER in 89 now contains only 4 positions.
TYPE90A 29.142 Enclave variables decoded in TYPE9030 dataset.
TYPEADAB 29.189 Support for Software AG's ADABAS SMF user record.
TYPEAXWY 29.231 Support for Axway CFT/ESA (Cross File Transfer) SMF.
TYPEBBMQ 29.056 Support for MainView MQ (MVMQ) Version 4.4.
TYPEBETA 29.059 Support for Beta 93 Version 4.2 subtypes 25/50.
TYPEBETA 29.233 Support for BETA93 Version 4.1.0 subtype 25 changes.
TYPEBVIR 29.006 Variables DVRTBV01-32 incorrectly formatted.
TYPECFS 29.186 Support for InfoSphere Classic Federation Server SMF.
TYPECIMS 29.033 Support for IMF Version 4.5 is in place.
TYPEDB2 29.031 DB2 V9.2 only, most QBGxxx variables DB2GBPST wrong.
TYPEDB2 29.121 QWHADSGN/QWHAHAMN were sometimes blank.
TYPEDB2 29.128 DB2 INVALID DISTRIUTED HEADER message corrected.
TYPEDB2 29.131 DB2PARTY added to DB2ACCTP, Rollup impact documented.
TYPEDB2 29.140 New LUUVTIME instead of QWACBSC for start time.
TYPEDB2 29.209 DB2 V10 ID=100 ST=1 INVALID HEADER.
TYPEDB2 29.213 Support for DB2 V10 IFCID 225 Subtype4 INCOMPATIBLE.
TYPEDB2 29.225 INVALID DB2 V10 QMDA segment for QMDAPTYP='JCC'.
TYPEDCOL 29.296 DCOLLECT support updated to execute on ASCII.
TYPEDM 29.158 NDM-CDI Version 5 new fields supported.
TYPEENDV 29.012 Support for Endeavor Version 14 (INCOMPATIBLE).
TYPEFERT 29.247 Support for ZEN FERRET V2.3 (INCOMPATIBLE).
TYPEIDMS 29.156 Support for IDMS/R Performance Monitor Version 18.
TYPEIMS 29.307 Support for IMS Version 12: Adds ZIIP/ZAAP CPU times.
TYPEIMSA 29.110 the exit _IMSTRN invocation was accidentally removed.
TYPEIMST 29.144 IMS Transaction Detail in new IMS56FA dataset!!
TYPEIMST 29.162 Validation of TYPEIMST, many changes for IMS56FA.
TYPEIMST 29.230 Further updates to IMS56FA transaction processing.
TYPEITRV 29.223 Support for APAR OA37114, ITRF (OMEGAMON IMS V420)
TYPEMPLX 29.247 Support for ZEN IMPLEX V5.1 (COMPATIBLE)
TYPENDM 29.010 NDMPRCNM/NDMPRCNO/NDMSTEP now kept where they exist
TYPENDM 29.042 Support for NDM-CDI Version 5 records (COMPATIBLE).
TYPENDM 29.295 NDM/Connect-Direct V5.0 added jobname/jctjobid.
TYPENDM 29.301 Old Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
TYPENTSM 29.075 Support for 62 new objects and 1425 new NT metrics.
TYPEPOC 29.219 Support for Tivoli Workload Schedulr Ver 8.3 INCOMPAT
TYPEPOEX 29.134 Support for Informatica's POWER EXCHANGE SMF record.
TYPEQACS 29.078 Support for OS/400, AS/400 Version 7.1 (INCOMPATIBLE)
TYPEQACS 29.208 Support for IBM i-series (AS400), more than 32 CPUs.
TYPERACF 29.067 RACF UNLOAD dataset RACF0270 UID limit variables.
TYPERMFV 29.013 CPCGRPLM and LCPUPOLR variables were wrong.
TYPERMFV 29.297 Continued RMF III enhancements.
TYPERMFV 29.300 Wrong ASMRMFV in first 29.29, VMACRMFV updated.
TYPESVIE 29.273 Support for SYSVIEW subtypes 34 and 35.
TYPETIMS 29.123 Support for TMON/IMS Version 3.0 (INCOMPATIBLE).
TYPETLMS 29.269 Support for CA TLMS tape library 2003 record changes.
TYPETMNT 29.248 INVALID ARGUMENT TO SUBSTR IN SYSLOG IEC205I message
TYPETMO2 29.244 Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE.
TYPETMS5 29.274 CA-1 TMS Extended Format TMC records have no impact.
TYPETMS5 29.304 USER ABEND 1234 can be bypassed for TMSCLEAN input.
TYPETPMX 29.071 Support for Throughput Manager subtype 10 and 16.
TYPETPMX 29.211 Support for Throughput Manager APAR TMT6214, st=16.
TYPETPMX 29.229 TPMCA7JN, TPMPI, and TPMDUEOT may be wrong.
TYPEVMXA 29.014 z/VM MONWRITE "exit" at EOF to detect ftp failure.
TYPEVMXA 29.026 Support for zVM APAR VM64794 (COMPATIBLE).
TYPEVMXA 29.092 z/VM new PDB.VXINTUSR sums all engines for each VM.
TYPEVMXA 29.129 MXGERROR DM 5 RC 10 UNDECODED PRCAPMCT due to IBM.
TYPEVMXA 29.133 z/VM LPARNAME, LPNUMBER kept in PDB.VMXAINTV.
TYPEVMXA 29.163 z/VM Crypto Record (5,10) with PRCAPMCT=6 error.
TYPEVMXA 29.172 Support for APAR VM64961, SMF 113 in z/VM MONWRITE!!
TYPEVMXA 29.207 z/VM MONWRITE Broken Control Rec if 2.14 (SCALL) rec.
TYPEXAM 29.126 XAM variables in VXSYTEP2 were not all input/kept.
TYPEXAM 29.294 Support for VNDNIC, LPARNW, USVCPU segments.
TYPEZOSA 29.247 Support for new ZEN OSA MONITOR V1.3 SMF records.
TYPEaaaa 29.238 All USER SMF have MACRO _IDaaaa nnn as SMF record id.
TYPSXAM 29.249 TYPSXAM didn't sort all XMdddddd datasets to the PDB.
UTILARCH 29.137 New UTILARCH archives data (like Outlook archive).
UTILVREF 29.075 MXG now creates DATASET names up to 32 characters.
VMAC102 29.242 On ASCII COMPRESS turned off, QW0145TX maybe trashed.
VMAC30 29.281 CPUTASKALLTM and PCTTASKTIME added SMFINTRV/TYPE30_V.
VMACDB2H 29.037 DB2 V9.1 false "INVALID DISTRIBUTED HEADER" message.
VMACSMF 29.079 MXG will ABEND if SMFTIME is invalid.
VMACSMF 29.290 USER ABEND 69 due to invalid SMFTIME now bypassed.
VMXGGETM 29.224 Enhancements to select records with LOOKFOR=text.
VMXGMPDB 29.292 Support for execution under unix.
VMXGPPDS 29.298 Compare contents of multiple PDS/PDSE libraries.
VMXGPRNT 29.250 INSTREAM replaces TMPPRNT.SAS for ASCII restrictions.
VMXGSRCH 29.103 RESULTS=FINDVAR finds all datasets with a variable.
VMXGSUM 29.054 Macro variable DSETEXST redefined.
VMXGSUM 29.154 AUTOCALL %macro's %CMPRES/%QCMPRES removed.
VSETMNTH 29.041 POSSIBLE LOSS OF MONday DATA in FEBRUARY MONTHLY PDB.
WEEKBLD 29.008 MXGNOBY default to eliminate NOTSORTED exposure.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 29.
====== Changes thru 29.307 were in MXG 29.29 dated Jan 23, 2012=========
Change 29.307 Support for IMS 12: ADDS ZIIP/ZAAP TIME TO IMS LOG DATA!
VMACIMS IBM changes were COMPATIBLY made, used RESERVED fields,
Jan 21, 2012 and those CPU times were added by APAR PM36273.
These new variables are now created in IMS01/IMS01M:
MSGOD62I='APPC*DEST*TYPE'
MSGOD62A='APPC*DETT*ADDR'
MSGIHSQN='SUBPOOL*HSQN*NM'
MSGFMTNM='MFSMODNAME'
MSGEWTKN='WLM*TOKEN TO*C2*CORRELATOR'
These new variables are now created in IMS07 and IMS0708:
DLRXICAL='ICAL*CALLS'
DLRXDGUR='DATABASE*GUR*CALLS'
DLRFLAG4='DLRFLAG4'
DLRAZAAP='ZAAP*ZIIP*CPU*TIME'
This new variable is now created in IMS07 and IMS0708:
LINTSUB2='IMS08*SUBTYPE*ADDITIONAL'
These two variables are now created in IMS56FA:
DLRGUR ='DL/I*GUR*CALLS'
TPEZAAP ='ZAAP*ZIIP*CPU*TIME'
Thanks to Paul Volpi, UHC, USA.
Thanks to Jerome Bachmeier,, UHC, USA.
Change 29.306 DEBUG=1 was on in several XAM file processing sections,
VMACXAM causing log messages but no actual errors in processing.
Jan 20, 2012
Thanks to Clayton Buck, UniGroup, USA.
Change 29.305 Using INTERVAL=SHIFT for RMFINTRV generated MXG WARNINGS
VMXGDUR and produced incorrect output, because TYPE75 addition in
VMXGINIT Change 29.194 didn't test that INTERVAL value. But after
VMXGRMFI the VMXGRMFI fix for SHIFT, and because VMXG70PR uses the
VMXGSUM same macros, both summary programs were tested with all
Jan 22, 2012 -For RMFINTRV, all "Normally used" INTERVAL= values from
SECOND thru FOURHOUR were correct, but for long-duration
values of EIGHTHOUR thru ANNUAL, variable STARTIME was a
missing value, and an "invalid" string did not circumvent
by setting INTERVAL=DETAIL as documented. Changes had to
be made to VMXGRMFI where END versus START had been used.
-For ASUM70PR and ASUM70LP datasets, there were no errors,
but both ASUMCEC and ASUMCELP had populated-but-wrong
STARTIME values (close, but wrong) for long-durations.
-VMXGDUR was the culprit with inconsistent ENDTIME values
returned when FLORCEIL was CEIL for long duration values.
(No one reported errors, other than SHIFT, "NEVER USED?")
-VMXGINIT added new &MXGDURTM a global macro.
-Other members that invoked VMXGDUR were verified to only
expect START values, so they didn't need revision here.
-VMXGSUM cosmetic: INTERVAL=NONE is no longer printed when
no INTERVAL= was specified, as NONE could be confusing.
Thanks to Scott Wiig, US Bank, USA.
Change 29.304 Change 29.195 sets USER ABEND 1234 if TYPETMS5 reads data
VMACTMS5 that is not a TMC (because the results are wrong when the
Jan 20, 2012 file was created by TMSGRW.) But TYPETMS is also used to
read the output of the TMSCLEAN program, to list scratch
volumes, so this change allows you to disable that ABEND
when you know the file is not a TMC, with this syntax:
//SYSIN DD *
%LET MXGABND=1;
%INCLUDE SOURLIB(TYPETMS5);
You will still get the ERROR message on the log that the
file was not a TMC as an alert, without the ABEND.
Thanks to Robert Carballo, ACS, USA.
Change 29.303 Since MXG 27.06, DB2PM-like Statistics Short Report has
ANALDB2R had wrong Total GETS and Buffer Totals Hit Ratios values.
Jan 19, 2012 The SUM statement in line 18777 repeated QB1
GETS =SUM(QB1TGET,QB1TGET,QB1TGET,QB1TGET,0);
but should have summed all four buffer counts:
GETS =SUM(QB1TGET,QB2TGET,QB3TGET,QB4TGET,0);
Thanks to Paul Billick, QVC, Inc, USA.
Change 29.302 CICSTRAN: If your old IMACEXCL member included IMACICRD,
IMACICRD but you didn't have an IMACICRD in 'USERID.SOURCLIB',
Jan 19, 2012 (listed as required in the UTILEXCL job's report), then
the new default IMACICRD in MXG 29.29 was %INCLUDEd, but
it had a comment within the commment block (that I had
missed in my QA tests) that caused a 180 SYNTAX ERROR.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
====== Changes thru 29.301 were in MXG 29.29 dated Jan 18, 2012=========
Change 29.301 NDM-CDI Version 4.7 "PS" record INPUT STATEMENT EXCEEDED.
VMACNDM Change 29.295 input PSSGPE1D offset, added in V5.0, from
Jan 18, 2012 two reserved bytes, but (old) 4.7 PS records have '4040'x
in those two bytes, and the NEXT two bytes are zero.
Since NDM-CDI records don't contain a version number, the
the logic was revised to test the value of the offset vs.
the record length to circumvent the error.
Thanks to Raff Rushton, IBM Global Services, USA.
Change 29.300 First 29.29 ONLY: RMF III PROCESSING WAS BROKEN.
ASMRMFV Fixed in 29.29 dated Jan 18:
VMACRMFV so that version contains these two corrected members.
Jan 18, 2012 -The VMACRMFV member in MXG 29.29 failed when reading DVT
EXZRBDVT data with ERROR: INPUT STATEMENT EXCEEDED RECORD LENGTH,
Jan 22, 2012 because updates made to VMACRMFV for the new ASMRMFV did
not work with RMFBSAM files created with the old ASMRMFV.
This change to VMACRMFV revised the DVT logic so that
records created by the old or the new ASMRMFV program are
correctly processed.
-The ASMRMFV member in MXG 29.29 was NOT the updated code,
even though it had "Jan 14, 2012, Change 29.297" in the
comments and log messages; it was the ASMRMFV from 29.05
that had none of the last six month's enhancements, and
it had an R in column 1 of the fourth line which caused
the assembly to fail with errors, in the first iteration.
-This change MAY be INCOMPATIBLE - the new VMACRMFV might
ABEND with RCD data in RMFBSAM files created by earlier
ASMRMFV versions, so the ONLY safe implementation is to
assemble the Jan 18 ASMRMFV and use that new program to
read the VSAM RMF file to create the RMFBSAM output file,
and then use the new VMACRMFV to read that RMFBSAM file.
(If your existing ASMRMFV load module was created from
an MXG version earlier than MXG 29.05, the new VMACRMFV
should execute without an ABEND, but no guarantee.)
Added Jan 22:
-ZRBDVT now only outputs DEVICES WITH ACTIVITY, where the
activity is calculated/tested in EXZRBDVT exit member:
ACTIVITY=SUM(DEVACTTM,IORATE,DEVIOQTM,
DVBUSYTM,CUBUSYTM,SWPODLTM);
IF ACTIVITY GT 0 THEN DO;
OUTPUT _WZRBDVT;
END;
Tutorial: Your tailoring logic in EXdddddd dataset exits
to control output of an MXG dataset needs this structure:
IF something THEN DO;
OUTPUT _dddddd;
END;
and can't use a DELETE, nor "IF something;" statements,
because they stop the read-current-record, and cause SAS
to read the next record, so any remaining segments in a
record with more than one observation per record would be
skipped and the output observation count could be small.
-By only outputing active devices in ZRBDVT with detail
device-level-per-minute data, it's more practical to use
the RMF III detail DVT dataset for DETAIL I/O STATISTICS.
Thanks to Jack Schudel, University of Florida, USA.
Thanks to Rodger Foreman, TransUnion Corp, USA.
Change 29.299 Cosmetic installation issues with first MXG 29.29.
FTP -The file size of ter2929.ter was incorrect in the emailed
SENDDATA instructions sent on the 17th. 27,319,296 was correct for
Jan 18, 2012 that iteration.
-Appendix A in the download instructions failed on JES3:
IAT4401 LOCATE FOR STEP=STEP2OF2 DD=INFILE
DSN=MERRILL.V2929.TERSED
IAT4404 DATASET NOT FOUND ON MAIN PROCESSOR A
because that DSN was dynamically allocated in the PGM=FTP
step, but JES3 doesn't know that. The example is changed
to define the DSN in a DD statement, so the new example
now works on both JES2 and JES3. This is not a new issue,
but had not been previously reported, probably because
JES3 techies knew how to resolve this JES3 "feature"!
Thanks to Harald Haug, OBERFINANZDIREKTION KARLSRUHE, GERMANY.
Thanks to James E. Lund, Texas A&M University, USA.
====== Changes thru 29.298 were in MXG 29.29 dated Jan 17, 2012=========
Change 29.298 VMXGPPDS utility reads PDS and PDSE datasets, originally
VMXGPPDS to print text in two-column format. It is now enhanced
Jan 15, 2012 to output the Index entry for each PDS member, keeping
these variables in a dataset for each PDS/PDSE library:
MEMBER='MEMBER*NAME'
DSNAME='DATASET*NAME'
CDATE='CREATE*DATE'
MDATE='MODIFIED*DATE'
TIME='MODIFIED*TIME'
USERID='USER*ID'
INITLINE='INITIAL*LINES'
NOWLINE='CURRENT*LINES'
with an example showing how it can be used to compare the
members (i.e., which is most recent?) in different PDS or
PDSE libraries. Both text and load libraries can be read,
but index information is only usable for text PDS/PDSEs.
Change 29.297 Detail and Summary reports from ASMRMFV have been
ASMRMFV reformatted for improved legibility, content, and
VMACRMFV clarity. Message RMFV105I is updated by the changes.
Jan 12, 2012 -When the DVT is selected in ASMRMFV the entries are now
blocked up to use as much as possible of a 32K logical
record. The number of DVT records output was reduced by
99.5% during testing. The actual data volume is
unchanged. This was to reduce I/Os for performance.
-A new ASMRMFV report column DATA ACTION shows the data
destination for each table as: OUTPUT, FILTER, or SKIP.
-A new ASMRMFV report column ENTRIES COUNT shows the
number of logical table entries processed. The meaning
of an entry varies with the RMF III table type. See
source code documentation for more details.
-The minimum and maximum LRECL output are now shown for
filtered and skipped records if the optional RMFFILT
and/or RMFSKIP DD statements are provided.
-Input table counts are supported up to 999,999,999.
-Output record and entry counts are supported up to
99,999,999,999.
-A new message RMFV032E is added to show the error code
from the IBM decompression routine ERB3RDEC should a
failure occur. In this case the start and end time of
the problem RMF III sample set is also shown. This
should be a rare event.
-The discussion on final ASMRMFV return codes is expanded.
-A discussion is added on how RMF Monitor III options
affect the data contents in tables.
-Prologue documentation in source is updated to include
discussion on new ASMRMFV column headings.
-VMACRMFV is changed to support blocked DVT entries in
input records.
-In VMACRMFV the DEVTYPE variable length has been
corrected to 12 bytes.
-In VMACRMFV the calculation of the DEVACTTM variable has
been changed to avoid excessive Missing Value counts from
SAS.
These are available only with RMF z/OS 1.9 and up. They
will be missing values for older releases.
-Nine new data variables are added to the ZRBDVT file:
DVTFLAG3 - Flag Byte
DVTHPAVB - Device Is HyperPAV Base Device (Y/N/?)
DVTHPCON - Number Configured HyperPAV Aliases for LSS
DVTHPSM - Number of Successful PAV Samples
DVTHPNUM - Accumulated Number of HyperPAV Aliases
DEVALCH - Number of Alias Exposures Has Changed (Y/N)
DEVLCUOK - LCU Number Is Valid (Y/N)
DEVPAV - Multiple Exposure Device(Y/N)
DEVVDASD - Virtual DASD (Y/N)
The first 5 variables are available only with RMF z/OS
1.9 and up. They will be missing values for older
releases. The last 4 variables are available to all MXG
users with RMF Monitor III.
-A new option ZERODVT/NOZERODVT has been added to ASMRMFV.
The default is NOZERODVT and will filter out the initial
DVT entry for each MINTIME interval. This entry is all
binary zeros and has no value in a PDB.
-VMACRMFV will also check for a zero initial DVT entry and
skip processing for it if detected.
-These are companion programs and the same maintenance
level of each must be used for successful results, i.e.,
you MUST assemble the ASMRMFV program to use the VMACRMFV
in 29.29.
Change 29.296 -DCOLLECT support updated to execute on ASCII platforms,
VMACDCOL by conditionally specifying RECFM=S370VBS when MXG is
VMXGINIT executed under ASCII. (On z/OS that DCB parm is set by
Jan 14, 2012 the DSCB at OPEN; S370VBS reads V/VB/or VBS RECFMs.)
-Variable ZTIME added to all keep lists (zEE time when zEE
dataset was created) so that multiple executions of the
IDCAMS DCOLLECT process can be differentiated by time.
-The alternative to differentiate multiple executions of
DCOLLECT is to use the variable INFILENM, which contains
the "dsname/file-name" of the input data, but INFILENM
is only "input" and is not kept in any DCOL dataset. You
could add INFILENM to any DCOL dataset(s) with syntax
%LET MACKEEP= MACRO _KDCOLxx INFILENM % ;
(and repeat the MACRO _KDCOLxx for each dataset) in your
//SYSIN, but this new alternative is now created:
-New macro variable &MXGINFIL is created with null value
in VMXGINIT, and is added to the KEEP= list for all DCOL
datasets. So you could then insert this statement
%LET MXGINFIL=INFILENM;
in your SYSIN stream, and variable INFILENM will be kept
in all of the DCOLLECT datasets
Thanks to Nick Johns, Sainsbury's Supermarkets Ltd, ENGLAND.
Change 29.295 Version 5.0 of NDM/Connect-Direct added jobname and the
VMACNDM JES JCTJOBID to the PS and RJ records.
Jan 14, 2012
Thanks to Peter L., whose company won't allow him to be cited.
Change 29.294 -Support for Velocity Software segments VNDNIC, LPARNW,
EXXMLPAR and protection for USVCPU segment (no data of interest):
EXXMDNIC dddddd dataset
VMACXAM XMDNIC XMVNDNIC
VMXGINIT XMLPAR XMLPARNW
Jan 11, 2012 -Some values in XMLPARNW look wrong, and test data doesn't
contain fields PCTMGTM nor PCTLOGICAL.
Thanks to Robert Obee, IMSHealth, USA.
Change 29.293 -Support for CICS Statistics STID=144 adds new dataset
VMAC110 CICEPR.
Jan 10, 2012 -STID=143 message SKIP=4 with STILEN=156 was eliminated.
There was no new data in the record.
Thanks to Joachim Sarkoschitz, DATAEV, GERMANY.
Change 29.292 Execution under unix is now supported, having found and
BLDSMPDB protected for these variants between WIN and UNIX:
VMXGALOC -The XWAIT option is only supported on WIN, causing error
Jan 14, 2012 conditions on UNIX and zOS but is now protected.
-If NOT EXIST does not work on UNIX, so the logic now used
is %SYSFUNC(FILEEXIST(FILENAME)) which returns a zero if
the file does not exist, or a 1 when the file exists.
Using SYSFUNC also allows the MXGNOTES to only appear
when we actually create or delete a directory.
-md (or MD) is not recognized on UNIX as make directory so
the full mkdir command name (in lower case) is now used.
-rmdir (rd) is used to remove directories under Windows,
but the UNIX command is rm with different subparameters:
on Windows the command is rd /q /s
on UNIX the equivalent is rm -r
-These changes do not impact z/OS execution of BLDSMPDB.
They have been tested under AIX 5.3, RedHat LINUX, and
should work on all xNIX platforms.
Thanks to Ruth Larsen, CA Technologies, USA.
====== Changes thru 29.291 were in MXG 29.09 dated Jan 4, 2011=========
Change 29.291 Lines 541 & 542 were missing a second close-parenthesis,
ANALGRID some arguments were not UPCASE'd, and some selection
Jan 14, 2012 arguments were not printed on the log when used.
Examples added and footnotes formats match grid formats.
Thanks to David Bixler, FISERV, USA.
Change 29.290 -Invalid SMFTIME (Julian date 366 in 2011) in IBM BVIR SMF
VMACSMF record (HISTORY FILE FOR TS7700 VTS TAPE SYSTEM) caused
Jan 2, 2012 a USER ABEND 69, because MXG logic for a bad SMFTIME was
VMACBVIR intended to catch the reading of a non-SMF file. This is
VMACNAF the FIRST time an actual customer has ever ABENDed due to
my choice, which I now realize is too harsh, so now, only
the ERROR message is printed by default. You can enable
the ABEND with %LET MXGABND=1; in your SYSIN.
(BVIR records are supported in MXG's TYPEBVIR code.)
-A second SMF record type, from VTAM SuperSession product,
also caused the USER ABEND 69 because its Julian date had
an invalid Julian date of 637 in 2012! Two in two days!!
MXG's TYPENAF supports those SMF records, but the last
update was in 2005, and they have been incompatibly
changed, with new subtypes and inserted data fields;
MXG will be updated when doc is available.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 29.289 The ASMDBLKU program is an ASM version of UDEBLOCK, that
ASMDBLKU constructs a valid VBS file on z/OS from a V/VB/VBS file
Dec 30, 2011 that was previously downloaded to an ASCII platform, as
that file is just a serial stream of bytes that cannot
be "back-loaded" and read on z/OS. You upload the file
from your ASCII platform back to z/OS, and then UDEBLOCK
or ASMDBLKU will read those chunks and reconstruct those
records into a valid VBS file on z/OS. This would likely
be needed only if IBM or another vendor needs for you to
send the VBS file for a problem, and you only have the
downloaded file. UDEBLOCK required SAS on z/OS while
ASMDBLKU doesn't. Additionally, UDEBLOCK was functional
but VERY expensive for DASD space, since it created a
single block for each record and wrote one record per
track. ASMDBLKU is smarter and wastes no DASD space.
Multiple enhancements were made to the original ASMDBLKU:
-The SMFOUT file is now generated as a true RECFM=VBS file
so no DCB overrides in JCL are required to process it
subsequently into a PDB build.
-QSAM blocking is now used so that SMFOUT disk space
requirements are significantly less than before when only
one record per 32K block was output.
-The PGSER macro system service SVC call to zero the
output buffer after each I/O was replaced with MVCL logic
thus providing up to a 64% CPU time reduction seen in
testing.
-The SMFOUT file now has DCB BLKSIZE=0 to use System
Determined BLKSIZE. Up to a 41% further reduction in
disk space usage was determined in testing.
-SMFIN and SMFOUT files now use DCB BUFNO=20 to reduce
elapsed time with up to a 33% time reduction seen in
testing. There was some corresponding increase in below
the line storage, but the program ran successfully with
REGION=2M.
-Most ASMDBLKU messages are reformatted for improved
clarity, legibility, and content.
-There are now separate and distinct messages for length
errors for the SMFIN physical block, BDW, and RDW values
respectively. Previously, these types of error were not
disclosed.
-Length error messages now show the invalid length value
and the related record number.
-The SMFIN file is now checked for RECFM=U and DSORG=PS
prior to any processing.
-SMFIN and SMFOUT byte counts are now accumulated and
reported. SMFOUT byte counts do NOT include the BDW
fields added by QSAM. Up to 19 decimal digit totals are
supported (9,999,999,999,999,999,999).
-Minimum and maximum LRECL values read from the SMFIN file
are now reported as message DBLKU25I.
-Minimum and maximum LRECL values written to the SMFOUT
file are now reported as message DBLKU26I.
-A missing DD statement for SMFIN or SMFOUT now generates
Return Code 16 as a severe error.
-Two character Return Codes are now displayed. Before
Return Codes higher than 8 were not supported.
-Record counts for SMFIN and SMFOUT files are now scaled
up to 9 decimal digits (999,999,999).
-Message DBLKU30I indicating final utility status is now
the last message displayed.
-Message DBLKU30I ended message is consistent in
appearance and format with DBLKU00I started message.
-PRINT OFF/PRINT ON added to suppress printing of the
change log during assembly.
-Prologue comments outside of the assembler source have
been updated.
Change 29.288 Reserved Change.
Dec 30, 2011
Change 29.287 Many VMWARE objects were revised to contain xxxxVMHO and
EXNTDTSC xxxxVMGU (Host and Guest names), changing NRNAMES, which
IMACNTSM caused MXG NRNAMES Messages. New DTS.ALERTCONFIG object
TYPENTSM is supported.
VMACNTSM
VMXGINIT
Dec 31, 2011
Change 29.286 Variable LPARCPUS was incorrectly typo'd as LPARCPU. Been
ANAL113 this way since 2010, so I assume either no use, or users
Dec 22, 2011 recognized and fixed the typo without report to support,
so Thomas gets this citation for finding the old error.
Thanks to Thomas Puddicombe, CSC, USA.
Change 29.285 Presumed error in back level SAS 9.2 TS0202M2 on z/OS, as
FORMATS NO error with 9.3 TS0202M3 nor 9.1.3/SP4 nor 9.3 on z/OS.
CREATEBC A split line in EBCDIC text for $MGZOSVT caused no error
PROCSRCE when PROC FORMATS created $MGZOSST/$MGZOSVT, but the two
Dec 22, 2011 formats could not be loaded when TYPEZOSA was executed by
TESTUSR1. The original ASCII text had a unexpected '0A'x
character (Line Feed) in that line, but that only caused
the EBCDIC text to be split there; no unprintable text
character was created in EBCDIC, and the longer right
hand value was still valid syntax, and was handled fine
on all other z/OS SAS versions.
-However, the unexpected '0A'x in ASCII text reminded me
to look for other unprintables in the EBCDIC text, and
three values ('01'x,'1C'x,'1D'x) are now detected in the
PROCSRCE/CREATEBC QA members, and corrected before EBCDIC
members are created for distribution. Fortunately, none
of these characters cause execution errors.
Thanks to Scott Wiig, US Bank, USA.
====== Changes thru 29.284 were in MXG 29.08 dated Dec 20, 2011=========
Change 29.284 ANALGRID creates a color-intense grid report of the value
ANALGRID of any variable, with time intervals as columns and date
Dec 20, 2011 as the row, to visually identify "hot spots". This is
based on the original design that was contributed by Bob.
See http://www.mxg.com/downloads, ANALGRID for examples.
Thanks to Robert A. Obee, IMS Health, USA.
Change 29.283 MXG 29.06-29.07. RMFINTRV with INTERVAL less than QTRHOUR
VMXGRMFI created an invalid PDB.RMFINTRV dataset with too many obs
Dec 20, 2011 but with ERROR: INCONSISTENT RMF DATA printed on the log.
Change 29.194 added TYPE75 summary data to RMFINTRV, but
had INTERVAL=QTRHOUR instead of INTERVAL=&INTERVAL.
Thanks to Yves Terweduwe, CIPAL, BELGIUM.
Change 29.282 The example summary of TYPE72GO to create ASUM72GO was
ASUM72GO updated to support "SYNC59" data written at :59 or :00
Dec 20, 2011 intervals.
Thanks to Brian Carter, HP Enterprise Services, ENGLAND.
Change 29.281 New CPUTASKTIMETM=ADDRESS*SPACE*DISPATCHED*TASK CPU TIME
VMAC30 and PCTTASKTIME=PCT WHEN*TASK WAS*DISPATCHED*ON PHYSICAL
BUILD005 variables are created in TYPE30_V and PDB.SMFINTRV data
BUIL3005 sets, to report the interval percentage of time when an
Dec 18, 2011 address space was dispatched on a physical processor.
PCTTASKTIME can exceed 100% when multiple tasks are
used for parallelism; values more than 25% are probably
of most interest. You can create the variables from your
PDB.SMFINTRV (or TYPE30_V) dataset, using:
CPUTASKGCPTM=CPUTCBTM-CPUASRTM-CPUENCTM-CPUDETTM;
CPUTASKZAPTM=(CPUIFATM-CPUEFATM-CPUDFATM)*256/SMF30ZNF;
CPUTASKZIPTM=(CPUZIPTM-CPUEZITM-CPUDZITM)*256/SMF30SNF;
CPUTASKTIMETM=CPUTASKGCPTM+CPUTASKZAPTM+CPUTASKZIPTM;
IF INTRVLTM GT 0 THEN
PCTTASKTIME=100*CPUTASKTIMETM/INTRVLTM;
Thanks to Bernie Pierce, IBM, USA.
Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT:
ASMTAPEE "YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO.
Dec 20, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P."
But there is NO NEED to ASM a new load module under 1.13;
your currently executing MXGTMNT module works just fine!
-This IBM note (migration guide) is the ONLY clue of the
incompatible change, which impacts OPEN/CLOSE macros, but
doesn't mention any by name:
DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement
in DFSMS macros; required if you have code that invokes
DFSMS macros (but not all!). Before z/OS V1R13, many
DFSMS macros that did not support 64-bit or AR mode did
not react to being invoked in 64-bit or AR mode, and
generated code that might have been invalid in 64-bit or
AR mode. Starting with z/OS V1R13, these macros are
changed to issue an assembly-time message and suppress
expansion if they are invoked in 64-bit or AR mode."
-But as noted above, you didn't really need to ASM. Now,
from MXG's "asmguy", his comments on this change:
Nothing is going to happen to an existing site using
MXGTMNT and in fact the modification I have to make for
this does not result in any change to the executable
code.
The SYSSTATE macro is an assembler directive - it sets
a flag that tells any macros that support AR mode
(Access Register, used for cross memory access) to use
their AR mode compatible expansion. Macros that don't
have an AR mode expansion used to ignore this because
they had nothing to do, and it's always the coder's
responsibility to make sure that when those non-AR
compatible macros are executed, that the system is not
in AR mode. This is similar to switching back and forth
from 24-bit to 31-bit mode: some macros can't tolerate
31-bit mode. Nothing has really changed though; it is
still the coders responsibility to make sure the system
is not in AR mode and macros that can't tolerate AR mode
still can't, except now IBM is requiring the coder to
explicitly set SYSSTATE to indicate to the assembler
that the system is not in AR mode.
Of course this is all very silly because the assembler
can't know ahead of time that the system is or isn't in
AR mode. So regardless of whether or not SYSSTATE is
coded this way the system still could be in AR mode,
OPEN/CLOSE will still expand the same way, and if the
system really is in AR mode OPEN/CLOSE will abend when
executed.
So the bottom line is that nothing has changed except
our need to do something for no reason at all.
-This ASMTAPEE is now ML-48 in the MXGTMNT startup msg.
Thanks to Thomas Maguire, CitiGroup, USA.
Change 29.279 -ASMRMFV incorrectly calculated the RCDSDI offset, causing
ASMRMFV an INPUT STATEMENT EXCEEDED RECORD LENGTH error, when an
Dec 13, 2011 RCD Table Record had an RCDSD Subsystem Delay array, but
the record didn't have an RCDRD Response Time array.
-Also a formatting error in message RMFV102I was corrected
*** END OF DATA *** showing record input count.
Thanks to Scott Chapman, American Electric Power, USA.
Change 29.277 NPM VCS segment with an invalid fifth ECSA segment (with
VMAC28 buffer size of 180 Kbytes), and without the DATA segment
Dec 8, 2011 for buffer size 64Kbytes. The segment length is the 176
expected length, so this circumvention skips the invalid
segment if size is 180 and doesn't input the last data
segment; when IBM fixes the record, the circumvention
does not need to be removed.
APAR OA38371 will correct the error, ETA Feb, 2012.
Thanks to Karen Florup, Bank of America, USA.
Change 29.276 RMF III dataset ZRBASI variable ASIPER, PERIOD, is input
VMACRMFV where ASIDMN, DOMAIN, was previously located. ASIDMN is
Dec 8, 2011 set to zero, its value ever since domains departed z/OS.
Change 29.275 The CLRMFV Clist will now check for non-zero Return Codes
CLRMFV from the TSO LISTCAT LEVEL command.
Dec 8, 2011 -3 messages indicating the error, the data set name level,
and the Return Code are now issued.
-In addition, the first 4 lines of LISTCAT output for the
error condition are displayed.
-Prior to this change CLRMFV could issue a non-zero MAXCC
message at completion and the reason was difficult to
determine when LISTCAT was involved.
-A non-zero LISTCAT Return Code is most commonly caused by
a data set name level that does not exist.
Thanks to Rodger Foreman, Acxiom CDC, USA.
Change 29.274 CA-1 TMS "Extended Format TMC Catalog" records are COMPAT
VMACTMS5 with ALL versions of MXG, as there was NO change in the
Dec 7, 2011 TMC's 340 byte record's length. The text of Change 28.040
that thought there were new length(s) was wrong and gone.
Change 29.273 -Support for subtypes 34 and 35 of SYSVIEW for IMS creates
EXSV34DA dddddd dataset description
EXSV34TR SV34TR SV34TRAN Subtype 34 Transaction
EXSV35EV SV34DA SV34DAC Subtype 34 DAC Segment
EXSV35TR SV35TR SV35TRAN Subtype 35 Transaction
IMACSVIE SV35EV SV35EVNT Subtype 35 Event Segment
VMACSVIE -There are errors in the subtype 34 and 35 that I have
VMXGINIT circumvented in this iteration, and SYSVIEW support has
Dec 7, 2011 confirmed the errors in the 34 and are looking at similar
errors in the 35 record; both will likely be corrected in
a future PTF from CA. The value in IMRA_DBIOTIME is
appears to be defective, also.
Thanks to Anthony G. Hurlston, CSC, USA.
Change 29.272 -Variable SM1209CI and SM1209CX can be negative, but they
VMAC120 were INPUT as PIB, so a negative field becomes a large
Dec 7, 2011 positive value in MXG. They are now input as IB.
IBM Support reports than when work does not complete,
ENDTIME isn't populated, and since CI is calculated as
END-START, you get a negative value. But you can also get
a negative value of -1 if WebSphere was unable to reach
its internal service that supplies the END time: for
example, an in-flight transaction when the server was
configured to "Drain" work during termination, but that
transaction still could have completed normally, so all
of the other fields could be completely valid.
IBM chose to NOT suppress these records even when they
might contain incomplete values, because many other data
values could be useful in diagnosing problems, and there
should be relatively few of these records. You probably
should filter these records from your daily reporting
totals, but rather than testing for a negative value in
CI/CX, which have valid transaction data, IBM Support
suggests to exclude transactions that have any value in
the minor code, SM1209CJ, and perhaps to simply count the
number that were excluded.
-Variable SM1209BM now has value '7.0.0.15' instead of the
value '7.0.0.*' when the fourth byte was GT 9.
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 29.271 Variable R799CNF bit 3 now creates R799CPD='Y' if the
VMAC79 connect/pending/disconnected time is not valid. All
Dec 6, 2011 other bits were already decoded into unique variables.
Thanks to Heimir Hauksson, Barclays, ENGLAND
Change 29.270 Variable POUNAL was incorrectly multiplied by 4096 when
VMACQACS it should have been multiplied by 1024 to convert KB to
Dec 6, 2011 bytes.
Thanks to Thierry Wehrle, BNP Paribas, FRANCE
Change 29.269 CA TLMS tape library records were changed sometime since
VMACTLMS 2003 when the MXG TYPETLMS was last updated, causing the
Dec 5, 2011 TYPETLMS dataset to contain mostly trashed field as MXG
INPUT BAUNIQUE and BAVOL1ST as PIB4 but they appear to
be only 2-byte fields.
Thanks to Gene Palmer, CitiGroup, USA
Change 29.268 The new ASUM4HRS %macro calculates "Four Hour" running
ASUM4HRS Average Values of the variable(s) you chose, but any
VGETFMT integer number of hours can be used instead of "Four".
VGETLABL -New VGETFMT/VGETLABL/VGETLEN internal macros retrieve the
VGETLEN FORMAT, LABEL, and LENGTH of a variable so that the new
VMXGDUR Average Value variable will have the same attributes as
VMXGSUM the inputted variable.
VMXGPARS -VMXGDUR,VMXGSUM adds duration tokens for EIGHTHR and
Dec 13, 2011 TWELVEHR. These duration tokens now can be used:
ANNUAL, SEMIANN, QUARTER, MONTH, WEEK, DATE, SHIFT,
TWELVEHR, EIGHTHR, FOURHOUR, THREEHR, TWOHOUR, HOUR,
HALFHOUR, TWENTYMIN, QTRHOUR, TENMIN, FIVEMIN,
THREEMIN, TWOMIN, MINUTE OR SECOND, or DETAIL.
-VMXGPARS now parses at two blanks to create a new line.
Change 29.267 Variable MPL72, the average number of concurrent resident
VMXGRMFI ASIDs, is now created in PDB.RMFINTRV dataset. Variables
Nov 29, 2011 APPCAVG and APPCMAX to count those ASIDs are also added.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.266 In TYPE70PR dataset, variables SMF70MSU and SMF70LAC are
VMAC7072 output in each TYPE70PR obs, but from the one TYPE70 obs
Nov 29, 2011 for "THIS" LPAR, so they are repeated for all LCPUADDRs
in this LPARNAME (being kept here only so they can be in
ASUM70PR). Since they are z/OS-only relevant, they are
now only populated in the SMF70CIN='CP' observations as
their non-missing value in obs for VM, ZIIPs, etc, was
unexpected and unwanted.
Thanks to Lars Fleischer, SMT Data, DENMARK.
Change 29.265A MXG 29.07 corrections found during ITRM validation.
VMAC42 -Macro token PSUVMXA added in Change 29.120 was misspelled
VMACCIMS as PSUMVXA in the GLOBAL statement in VMXGINIT.
VMACNTSM Also, the hardcoded PDB. in MACRO _LTYVMXA PDB.VMXAINTV
VMACTPMX in the (optional) ASUMVMXA member was corrected to the
VMXGINIT default &PVMAINT macro destination DD for VMXAINTV.
Nov 29, 2011 -TYPECIMS variables TRNSTRTA/TRNSTARTU/TRNSTOPA/TRNSTOPU
are no longer kept in CIMSTRAN as they are GMT offsets
that are already used to convert times to local zone.
-Variable VWGMACBY was accidentally removed from the NTSMF
dataset VMWGUMEM.
-TYPETPMX variables JBL54051,JBL55044-JBL55051 were always
missing values, DKROCOND=WARN printed warnings due to
typos in the variable name in the assignment statements.
All of the JBL54xxx and JBL55xxx are also now labeled.
-TYPE42 variables SMF42PTE and SMF42PTS are now labeled.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 29.265 Temporary DDNAME/FILENAME MXGTEMP is added to the MXG JCL
VMXGCNFG for z/OS for future cases when more than one temporary DD
MXGSAS is required. Currently, only SMFSRCH uses that DDNAME.
Nov 25, 2011
Change 29.264 Support for DFSORT for z/OS 1.13 adds COMPATIBLY two new
VMAC16 variables to TYPE16 dataset:
Nov 25, 2011 ICEMCPUZE='ZIIP*ELIGIBLE*CPU*TIME'
ICEMCPUZP='ZIIP*ACTUAL*CPU*TIME'
Change 29.263 Variables SMF30JQT/SMF30RQT/SMF30HQT/SMF30SQT are missing
BUILD005 values in PDB.SPUNJOBS for jobs that had TYPE30_5 job
BUIL3005 term obs with MULTIDD='Y' (which have only EXCP counts.)
Nov 25, 2011 And those TYPE30_5 with MULTIDD='Y' shouldn't ever have
been used in BUILDPDB logic; MXG uses the step records
for EXCP counts and only wanted the TYPE30_5 values from
the "real" TYPE30_5 that has MULTIDD=' '. So this change
deletes MULTIDD='Y' observations during processing of the
TYPE30_5 records in BUILDPDB and BUILDPD3.
Thanks to Esther Remiro, La Caixa, SPAIN.
====== Changes thru 29.262 were in MXG 29.07 dated Nov 24, 2011=========
Change 29.262 First MXG 29.07 Only, and only if IMACEXCL is tailored to
VMAC110 read exclude fields. WARNING: UNBALANCED QUOTES message
Nov 23, 2011 was printed, BUT ALL DATASETS WERE CREATED CORRECTLY.
There were no unbalanced quotes, but 29.07 had introduced
new " &CICXLTR " syntax into the existing PUT '***ERROR'
statement printed when MXG detects there are excluded
fields that are not supported in your IMACEXCL tailoring;
the enhancement prints your selection statements from the
current IMACEXCL member in use to help error resolution.
And for reasons I know not now, that macro reference was
the cause of the spurious warning. Now SYMGET('CICXLTR')
is used to retrieve the text for the PUT statement.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Change 29.261 -An incomplete comment in Change 29.147 caused the new and
VMAC0 "true" IPLs datasets WORK.TYPE0 and PDB.IPLS to have ZERO
Nov 23, 2011 observations since that change in MXG 29.06. That this
error was accidentally discovered when trying to diagnose
the unbalance quote warning in Change 29.262, by counting
the two comment tokens ( /* */ ) separately to see if the
counts are equal (because often unbalanced quote errors
result from unbalanced comments, or new comments wrapping
around commented text) suggests that few sites have IPLs
that needed to be reported!
-An incorrect pair of single quotes was changed to single
quote in optional IMACICBB code, discovered the same way
when counting quotes. The pair was inside the comment
block, and it's been there a long time; either tailoring
users caught it and fixed it when enabling that optional
CICS segment, or nobody uses this optional segment.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Change 29.260 At only one site, the EXITCICS decompression of DB2 V10
VMACDB2H records created records with INVALID HEADER values that
EXITCICS caused STOPOVER ABEND. This change thought the SMF data
Nov 23, 2011 was valid and added protection for the "truncated" data
Dec 18, 2011 segments, but that protection, while safe, was not needed
and the problem in the SAS INFILE exit code in EXITCICS
is being investigated by SAS Technical Support. The DB2
V10 compressed records can be uncompressed using the IBM
utility program xxxxxxx until the problem is resolved,
but this is most strange as MANY sites are successfully
reading compressed DB2 (and CICS!) records with EXITCICS.
This is the text of the original change:
DB2 V10 record with INVALID HEADER caused STOPOVER ABEND.
The ID=101 SUBTYPE=1 record had invalid offsets that are
now protected. The starting INPUT location was compared
with the LENGTH of the record, but in this case, while
the start offset happened to be less than the LENGTH,
the length of data to be input was beyond the LENGTH,
causing the STOPOVER ABEND. Now both the start and end
of each of these truncated name fields is validated and
an error message "INVALID DB2 RECORD QWHC=...." printed.
This text will be updated when an APAR/PTF is known.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
====== Changes thru 29.259 were in MXG 29.07 dated Nov 21, 2011=========
Change 29.259 Cosmetic. Diagnostic PUTLOG statement in IFCID=140 code
VMAC102 was left and printed A_N_= nnn .... on the SAS log for
Nov 18, 2011 each IFCID=140 record, but no other impact.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 29.258 Comparison of I/O Connect Times in RMF 74 and SMF 30 show
BUILD005 DEVCONTM SMF74CNN - DEVICE CONNECT TIME 2,058,143 sec
BUIL3005 SMF30AIC - DASD CONNECT 2,150,200 sec
IMAC30IO IOTMTOTL SMF30TCN - ASID IO all ASIDs 1,482,821 sec
VMAC30 IOTMTODD SMF30DCT - DD IO all ASIDS 1,253,434 sec
Nov 18, 2011 IOTMNODD MXGcalc - TOTL not in DDs 229,387 sec
RMF DEVCONTM and RMF SMF30AIC match quite closely, but
that "hardware" IOTM captured in RMF and in SMF30AIC is
much larger (2150200-1482821= 677,379 sec) than the IOTM
that is captured in SMF30TCN, Address Space IOTM Total.
To investigate, variable in TYPE30/JOBS/STEPS/SMFINTRV
IOTMNOCA='CONNECT*TIME*NOT CAPTURED*IN IOTMTOTL'
is created to see if the cause of this uncaptured IOTM
can be identified/correlated. This text will be updated
when more is known (including my asking IBM).
Some initial investigation with different data shows
-Of 9881 records with non-zero SMF30AIC, 1867 had a
negative IOTMNOCA, but only 40 were more than -10 sec
and the max negative was 2 jobs at -3 minutes.
MOST OF THESE WERE PROGRAM=DSNYASCP although our old
friend IFASMFDP had instances of -37, -17 and -12 sec.
-Of the other 7119 with positive IOTMNOCA, 592 were
greater than 3 seconds, AND ALL WERE PROGRAM=BPXPRFC.
which is the first step of an OMVS Spawned Address
Space Substep. This suggests that the use of I/O by
USS-OMVS is ONE source of NOT-Captured IOTM in 30s.
There are many OMVS I/O counters in the OMVS segment
in SMF 30s, but none have the I/O Connect Time.
-But, a third sites data looking at DB2 and ADABAS jobs
shows large positive uncaptured values for ADABAS but
for DB2 jobs, large negative uncaptured, i.e., time in
SMF30TCN is LARGER than the time in SMF30AIC.
-This issue is under discussion with IBM z/OS folks;
I think that IOTM for USS is captured in AIC but not
in IOTM, and there are errors in which address space
records IOTM when there are "partner" database ASIDs,
but the total IOTM are correct. We'll see!!
JOB INTBTIME IOTMTOTL SMF30AIC IOTMNOCA
DB2JOB01 13:14:00.15 0:10:23.25 0:00:42.06 -581.19
DB2JOB01 13:29:00.16 0:09:08.14 0:02:49.97 -378.16
DB2JOB01 13:44:00.16 0:07:51.57 0:01:34.28 -377.29
DB2JOB01 14:14:00.17 0:10:44.91 0:00:23.18 -621.73
DB2JOB01 14:29:00.21 0:10:22.25 0:00:55.89 -566.35
ADABAS72 13:14:00.05 0:02:46.90 0:12:50.75 603.85
ADABAS71 13:29:00.09 0:01:40.57 0:08:55.19 434.61
ADABAS72 13:29:00.09 0:03:54.11 0:16:02.57 728.45
ADABAS72 13:44:00.04 0:03:32.12 0:16:39.49 787.37
ADABAS72 13:59:00.02 0:03:05.23 0:16:01.69 776.46
ADABSD72 14:14:00.07 0:02:48.06 0:15:40.71 772.64
ADABSD72 14:29:00.05 0:02:05.13 0:11:20.71 555.58
Thanks to Meral Temel, Garanti Teknoloji, TURKEY.
Change 29.257 WMQGETTM was not divided by the 4096 factor needed for
VMAC110 CICS 8-byte time durations, so it was a little too large!
Nov 17, 2011
Thanks to Robert C. Crawford, USAA, USA.
Change 29.256 Change 29.120 revisions to ASUMVMXA were not included in
ASUMVMXA that change until today.
Nov 17, 2011
Change 29.255 z/VM datasets VXSUMIOD and VXDEVTOT created by _SIODDEV
VMACVMXA were left in //WORK, and dataset macros _LSUMIOD/_LDEVTOT
VMXGINIT were not defined nor were &PSUMIOD nor &PDEVTOT; all are
Nov 16, 2011 now defined and used so they now default to //PDB.
_RPT36 was revised to use _LDEVTOT as its input dataset.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.254 IMF variable ARRVTIME has resolution to only one decimal
VMACCIMS place, but "newer" variable TRNARVTH time has two decimal
Nov 19, 2011 places, so ARRVTIME is now revised to use the DATE part
of original ARRVTIME but with TRNARVTH's value for TIME.
Thanks to Ken Jones, Xwave, CANADA.
====== Changes thru 29.253 were in MXG 29.07 dated Nov 14, 2011=========
Change 29.253 Preliminary support for Velocity Software Version 4.1 has
VMACXAM eliminated warning messages about new segments, and most
Nov 14, 2011 new data fields are decoded, and this level set has been
validated with data records thru MXG's QA job stream.
Thanks to Douglas C. Walter, Citigroup, USA.
Change 29.252 The new SM120XP/SM120XZ times are in microseconds rather
VMAC120 than the (strange) duration units that MXG decoded. Also,
Nov 14, 2011 the MXG code caused INVALID ARGUMENT messages if executed
on ASCII; those fields had not been translated to EBCDIC
before they were used in the INPUT function.
-The undocumented SM120XZ field is the CPU time that has
been offloaded by WebSphere to zIIP engines, and it is so
labeled now.
Thanks to Millard Stephens, FMR, USA.
Thanks to Warren Cravey, FMR, USA.
Thanks to Raj Ramachandran, IBM, USA.
Change 29.251 Support for Demand Technology Performance Sentry NTSMF V4
EXNTDTSA adds three new objects that create three new datasets:
EXNTVMWA dddddd dataset description
EXNTVWVS NTDTSA DTSALRTR DTS.AlertRecipient
IMACNTSM NTVMWA VMWAREh VMWARE
VMACNTSM NTVWVS VMWHVSPH VMWARE.HOST.VSPHEREREPLICATION
VMXGINIT -Existing VMWARE objects were INCOMPATIBLY changed by the
Nov 12, 2011 insertion of a separate field for the 2nd instance field.
Previously a single field contained both instance values,
separated by a '::', that MXG parsed in the two instance
variables. MXG now detects NRNAMES=2 and uses separate
fields when they exist, but that new NRNAMES value causes
error messages (and no observations output), if you read
NTSMF V4 (new) records with MXG prior to 29.07.
These segments have two fields stored for xxxxINST/INS2
VWGC VWHC VWGD VWHD VWGN VWHN VWHS
These segments have one field that is still parsed to
populate the two xxxxINST and xxxxINS2 instances:
VWGA VWHA VWGM VWHM VWGS
-New variables xxxxVMHO (VM*HOST), xxxxCPU (CPU*NUMBER),
xxxxVMGU (VM*GUEST) are created from new fields added at
the end of many existing VMWARE records.
-Many new variables were added to existing VMWARE datasets
in Version 4, too many to list here, but you can find all
in VMACNTSM after the text "ADDED BY CHANGE 29.251" in
the KEEP= list for all datasets.
Change 29.250 Windows SEVEN restricts writes to the root, program file,
VMXGPRNT and other directories. VMXGPRNT writes text/code to file
Nov 10, 2011 TMPPRNT and then %INCLUDEd TMPPRNT, but the MXG default
file C:\MXGTEMP.SAS was in the root directory, so it was
restricted from access. The circumvention was to change
filename TMPPRNT to INSTREAM, which is the MXG ddname
specifically designed (and used internally by MXG) to
dynamically create SAS code and/or MXG macro definitions
"instream" and then %INCLUDE them. TMPPRNT was never
needed, but the original contribution was left asis.
FWIW: Even with the error, all datasets were printed;
The error prevented the printing of the variable name
along with its label, which is the ONLY reason you want
to use VMXGPRNT/VMXGPRAL, and why I saw the error, as
I use VMXGPRAL all the time, especially to understand
all of the variables in a new dataset I've just built.
Change 29.249 TYPSXAM example to create and sort all datasets to PDB
TYPSXAM did not sort all fifty-six datasets. The structure of
Nov 10, 2011 MXG support for XAM is different because XAM has five
INFILEs that create fifty-six datasets. Each infile has
a macro pair _TXAMfff and _SXAMfff where _TXAMfff reads
infile fff to create all fff datasets and _SXAMfff sorts
the fff datasets to the PDB. But, the _SXAMfff macros
have not been updated in a long time so the newer XAM
datasets were not in the XAM PDB data library.
The simple resolution is to replace the five _SXAMfff
macro invocations in TYPSXAM with the _SXAM product sort
macro that sorts ALL of the XAM product's datasets (and
all of the _Sxxxx product sort macros are validated to
sort all datasets as part of MXG's robust QA jobstream).
An additional problem is avoided: the _SXAMDEV token
name is used for both the data set sort token and for
the _SXAMfff "infile fff" token. Using _SXAM and not
using the _SXAMfff tokens avoids a major redesign and
new (INCOMPATIBLE) naming conventions.
Thanks to Debbie Mattos, Lockheed Martin, USA.
Change 29.248 INVALID ARGUMENT TO SUBSTR in SYSLOG IEC205I message text
VMACTMNT in ASMTAPEE/MXGTMNT tape mount/syslog monitor SMF record.
Nov 9, 2011 Parsing to INPUT the mmm after TOTALBLOCKS=mmm into the
SYSLBLKS variable in TYPESYMT dataset expected 16 bytes
and failed when there were fewer characters for mmm. Now
the parse stops at the first blank character.
This change in format of the IEC205I message occurred
after PTF UA90604, in APAR OA90604, which included
IFG0194J, which contains message IEC205I.
The prior PTF level was UA60149.
APAR OA38051 now documents:
Unnecessary information on the third line of IEC205I
Characters *HAS will appear after spaces
and it was these unexpected characters instead of
blanks that led to this MXG circumvention change.
Thanks to Clayton Buck, UniGroup, USA.
Change 29.247 Support for ZEN FERRET, ZEN IMPLEX and ZEN OSA user SMF
EXFERSAW records from William Data Systems GmbH products.
EXZOSAEV -VMACMPLX - ZEN IMPLEX V5.1 adds two new variables
FORMATS ESMFHCMN (CPC*NAME) and ESMFHLNM (LPAR*NAME) to its
IMACFERT header (COMPATIBLY) and those variables are kept in all
IMACZOSA ZEN IMPLEX datasets.
VMACFERT -VMACZOSA. Support for ZEN OSA MONITOR V1.3 SMF record,
VMACMPLX creates TYPEZOSA dataset with separate observations for
VMACZOSA each value segment in each SMF record. All four subtypes
VMXGINIT (CHAN,LPAR,I/O,QUEUE) have the same record structure with
Nov 10, 2011 a fixed suite of OSA descriptors and one or more value
Dec 16, 2011 segments; MXG creates a separate observation for each of
the value segments in each SMF record. Variable ZOSARESC,
the resource name is EBCDIC text in the I/O and QUEUE
record, but because it is a hex string in the CHAN record
it's value is instead kept in variable ZOSARESH.
-VMACFERT. Support for ZEN FERRET V2.3. INCOMPATIBLE.
-Datasets FERRETCP, FERETEE, FERETRT datetime field was
1 changed from mm/dd/yy to ddMONyy, so prior MXG versions
will fail due to this INCOMPATIBLE change.
-Two new fields have been added to the RTP and CP data
section, a flag byte which indicates the type of history
and a field showing the transmission priority.
-Support for new Session Awareness Section creates new
FERRTSAW dataset, although some minor issues have just
been opened.
-The key section for SAW has PLU and SLU, but those
fields are also in the data segment
-Offset value to SAW is 106, but segment starts in byte
109; the offset value should be 112, and three less to
get to the SAS byte location of that offset.
Thanks to Bruce Sloss, PNC Bank, USA.
Thanks to Ronald Delp, PNC Bank, USA.
Change 29.246 If a filename in macro variable &PDB had a DASH, this
BLDSMPDB compiler error was caused when %UPCASE(&PDB) was used:
Nov 8, 2011 "ERROR: A character operand was found in the %EVAL
function or %IF condition where a numeric operand is
required. The condition was: %upcase(&runday) eq
%upcase(&pdb) and %length(&rerun) ne 0 "
because that DASH was not "masked" and was thus seen as
a mathematical minus and not a part of the filename.
This is obscure, to say the least, but SAS documents that
neither %UPCASE() nor %STR() macro functions mask special
characters, and that %QUPCASE() should be used instead.
But in this specific test, the UPCASE() was never needed
as both arguments were previously LOWCASED() which DOES
mask special characters. But the &RUNDAY EQ &PDB test
cannot be used because that dash will still look like a
minus sign, so the circumvention/re-design now uses
IF %QUOTE(&RUNDAY) EQ %QUOTE(&PDB) to mask the DASH and
successfully compile.
Thanks to Mitchell Loren, Los Angeles County Education, USA.
Change 29.245 Change 29.195 added a test TMSCTL=:'TMSCTL#' to protect
VMACTMS5 when a non-TMC file is read, but that PoundSign was not
Nov 8, 2011 recognized with some character sets, so the test is now
shortened to TMSCTL='TMSCTL' to avoid a false positive.
Thanks to Akre Trond Maurita, EDB, NORWAY.
Change 29.244 Support for TMON/CICS V3.3 (mostly COMPATIBLE) TCE data.
VMACTMO2 -TMON/CICS V3.3 increased MRO's TAMRSYID field from 4 to 8
Nov 10, 2011 bytes, to hold the IPIC CONNID. Unfortunately, while MXG
does use segment length to keep aligned with each of the
repeated MRO segments, inserting 4 bytes (instead of new
8 bytes at the end) shifts/trashes the TAMRxxxx variables
in the MONIMRO dataset due to this INCOMPATIBLE change,
but there are no error messages nor condition code set,
so V3.3 is INCOMPATIBLE ONLY IF YOU USE MONIMRO dataset;
MXG Version 29.07 is required for V3.3 only for MONIMRO.
And, fortunately, MONIMRO is very rarely used in reports.
TMON records with earlier MXG versions will not cause
errors nor ABENDS, just bad data in one seldom used
-TAMRFLG1 and TAMRFLG2 fields are listed in V3.3 as new
but were previously input and kept in MONIMRO dataset.
-The DSECT for the header showed an optional, inserted
40-byte extended-common-header segment, that would have
made all V3.3 records incompatible, but, fortunately,
that segment will NOT exist in V3.3 records. And, more
fortunately, MXG is updated to support its existence, so
if/when it appears in a future record, it won't be an
incompatible change.
Change 29.243 Calculation of ESTSCP1M had (0.57*(0.1*RNI)) but that was
ASUM113 a typo, now corrected to (0.57+(0.1*RNI)). MXG's error
VMAC113 caused very small values in ESTSCP1M.
Nov 2, 2011
Thanks to Dave Cogar, Wells Fargo Bank, USA.
Change 29.242 ONLY if executing MXG on ASCII, and ONLY if MXG default
VMAC102 option COMPRESS=YES was changed to COMPRESS=NO (which
Nov 1, 2011 causes SQL text to be broken into 100 byte chunks that
Nov 3, 2011 are output in dataset T102T14x instead of T102S14x), the
DB2 Audit variables QW0140TX,QW0141TX,QW0142TX,QW0145TX
were only readable text in the last segment or if there
were less than 100 bytes of SQL text, because MXG's logic
for this "chunking" algorithm was written long ago and it
was only validated back then on z/OS. MXG INPUT those
fields with $EBCDIC100, but that INPUT should have been
with $CHAR100, and then the INPUT function with $EBCDIC
informat does that translation to readable text.
And variable QW0124T's INPUT was also corrected.
Thanks to Lars Fleischer, SMT Data, DENMARK.
Thanks to Jorgen Lund, SMT Data, DENMARK.
Change 29.241 The example to split SMF records into 5 groups output DB2
JCLSPLIT ID=102 records in "B" DB2 output file, and then failed to
Oct 28, 2011 add 102 to the NOTYPE list in the "E" group (ALL OTHER),
so all 102s were output in both "B" and "E" output files.
The 102 is now added to the NOTYPE list in "E".
Thanks to Jennifer D. Ayers, WVOT Data Center, USA.
Change 29.240 The length of new variable SM1209FH could not be changed
VMAC120 as described in Change 29.081. That text was rewritten.
Nov 8, 2011
Change 29.239 Variable SHIFT (also used as "ZONE") is now created in
VMAC7072 all of the RMF datasets, from STARTIME.
VMAC71
VMAC73
VMAC74
VMAC75
VMAC76
VMAC77
VMAC78
VMAC79
Oct 27, 2011
Thanks to Frank Lund, EDB ErgoGroup, NORWAY.
Change 29.238 Change 25.142 and Change 28.211 identified USER SMF
VMACARB VMAC's using "MACRO _xxxxID nnn%" instead of "MACRO
VMACDLMN _IDxxxx nnn%" but those changes did not revise those
VMACDMON members to use the more-recent-and-preferred _IDxxxx
VMACHURN syntax. All VMAC's are now updated to support both forms
VMACM204 of the _ID macro to tell MXG what SMF record number to
VMACNSPY process as product xxxx, but only to be consistent, just
VMACPDSM in case we needed to generate them internally in MXG.
VMACRMDS Note that using UTILBLDP is recommended to read multiple
VMACROSC SMF records, and by using it's USERADD=xxxx/nnn argument
VMACRTE set the SMF IDs, you do not need the _ID definitions in
VMACTSOM your IMACKEEP tailoring.
VMACVVDS -But some inconsistencies in _IDxxxx macron names exist:
VMACWYLA Arbiter can write each of its subtypes with a separate
VMACWYLB SMF record ID (_IDARB00-IDARB0C).
VMACX37 VMACM204 has _IDM204L and _IDM204S for Log/Since-Last.
Oct 26, 2011 VMACTSOM has _IDTSOMC and _IDTSOMS for Command/System.
VMACHSM has _IDHSMDS and _IDHSMD1 for Daily/FSR Stats.
VMACHBUF was in 25.142 but had been updated to _IDHBUF.
VMACWYLB was in 25.142 but had been updated to _IDWYLB.
Change 29.237 The calculation of ZIPUSED and ZIEUSED did not include
ASUMMIPS the divide by CAPZIPRT*100.
Oct 24, 2011
Thanks to Bernhard Bablok, Allianz Managed Operations, GERMANY.
Change 29.236 SMFSRCH is a VERY slick new tool to print all SMF records
COMPALL that contain a specific "LOOKFOR" character text string.
COMPALLN All SMF records are scanned for the "LOOKFOR" text
SMFSRCH - using IF INDEX(_INFILE_,"LOOKFOR") syntax -
TYPESMF and selected SMF records are written to the temporary
VMXGGETM DDNAME/filename of MXGTEMP, from where TYPESMF program
VMXGPRAL reads them to create every possible MXG dataset that can
VMXGSRCH be built from SMF records, including "USER" SMF records.
Nov 11, 2011 Then, ONLY the observations in those datasets that have
a variable containing the "LOOKFOR" text are printed.
(This extra filtering is needed because some datasets
created from the selected records won't contain that
"LOOKFOR" text. Consider if LOOKFOR=USERID, TYPE 30-4
records with that USERID will be selected and TYPE30_D
dataset will have many observations, one per DD name,
but the USERID field is not kept in dataset TYPE30_D,
so this final filtering prevents those unwanted "false
positive" observations from being printed.)
The selected SMF records can be kept by making //MXGTEMP
a permanent dataset, and the selected MXG-created SAS
datasets can also be kept.
-The //MXGTEMP DD may need to be added to your JCL.
-SMFSRCH creates all possible datasets that can be created
from IBM or USER SMF records. IBM fixed-numbered records
are automatically output, but only the USER SMF records
that have a "MACRO _IDxxxx nnn % definition in IMACKEEP
or in IMACxxxx will create observations (BUT: you can use
the USERADD=xxxx/nnn argument to tell MXG the nnn you use
for product xxxx and those datasets can be populated).
-SMFSRCH reports the counts/sizes of SMF records input and
selected, and maps USER SMF records to their product if
the_IDxxxx macro was found.
-New parameters added to VMXGGETM, used in new SMFSRCH:
BEGTIME= earliest datetime to be selected
ENDTIME= latest datetime to be selected
INCODE= A stub of code executed after the header
is read
LOOKFOR= text string to be searched in each SMF record
-TYPESMF executes all TYPExxxx member that read any SMF
records, reading SMF once for each TYPExxxx member, so
it is only used in SMFSRCH to read the selected records.
-VMXGPRAL's TITLE "PRINT OF FIRST MAX OBS.." corrected.
Thanks to Jeffrey Dyke, USDA, USA.
Change 29.235 Change 29.125 (MXG 29.05-29.06) corrected DB2 IFCID=22
VMAC102 error with DB2 V10, but did not work for DB2 V9. And, in
Oct 19, 2011 testing this update the T102I022 dataset was found to be
in serious need of realignment.
Thanks to Tom Buie, Southern California Edison, USA.
Change 29.234 Cosmetic. Messages that EXCLUDED FIELDS are revised to
VMAC110 print the value of the triplets (dictionary records) that
Oct 19, 2011 are defined in your IMACEXCL tailoring, to make it easier
to see that your UTILEXCL missed a dictionary record.
Change 29.233 Support for BETA93 Version 4.1.0: Subtype 25 was changed,
VMACBETA with fields removed, causing wrong or missing values in
Oct 18, 2011 dataset BETA25, plus INVALID DATA FOR BETASTRT messages.
These variables are now missing/blank with 4.1.0:
BETACPU BETAELAP BETAEND BETAETKN BETALTKN
BETAOWNR BETARTKN BETASTRT BETAVIOR BETAVIOW
Additionally, missing value messages for some datetimes
are circumvented by testing DATE GT 0 before calcs.
Thanks to Michael Brenning, Finanz Informatik, GERMANY.
Change 29.232 DFSORT variables ICEMNVLX,ICEMNVLY, and ICEMNVLZ are not
VMAC16 documented as to their units, but data shows they are in
Oct 15, 2011 KB and not Bytes, so they are now multiplied by 1024 to
Oct 25, 2011 convert to bytes, and then so MGBYTES format will print
16M rather than 16K previously printed. IBM has privately
verified that the units are 16M and plan to update their
DFSORT documentation to show the units attribute.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Change 29.231 Support for Axway CFT/ESA (Cross File Transfer) two SMF
EXAXWAY record formats ("2.3" and "2.4" but "2.3" format records
FORMATS (8-byte vs 32-byte fields) are created/creatable with the
IMACAXWY current CFTMON 2.6.4. As there is no version number and
TYPEAXWY the two records have same length, three one-byte fields
TYPSAXWY that must be blank in 2.4 are used to identify version of
VMACAXWY the record. The 2.4 code with 32-byte fields is INPUT
VMXGINIT first so the kept variables will be the longer length.
Oct 15, 2011
Nov 17, 2011
Thanks to Richard Wendland, US Bank, USA.
Thanks to Claude Breault, Centre de Services Partages Quebec, CANADA.
Change 29.230 Comparison of BMC IMF FA and IBM 56FA IMS Log records.
ASUM56FA -Variable IMSRECCH added to CIMSTRAN to capture that IMS
EXIMS56C log sequence number at the end of each IMS log record; it
FORMATS was already in IMF56FA. In TYPECIMS variable IMSRECNR is
IMACIMS the _N_ sequence number and is NOT input from the record.
TYPEIMST -IMS56FA records are written as pairs for a single IMF FAx
VMACCIMS log record. The pair have the same ARRV and STRT times,
VMACIMS and are written 5 milliseconds apart at transaction end.
VMXGINIT -See the new IMS Technical Note in NEWSLETTER FIFTY-NINE
Oct 11, 2011 for a detail explanation of what is captured in IMS56FA
Oct 21, 2011 transaction event records, and a comparison with IMF.
Oct 27, 2011 -ASUM56FA program (still in testing) is added to MXG.
Change 29.229 -Variable TPMCA7JN is now input &PIB.2. + 2 versus &PIB.4.
VMACTPMX -Variable TPMPI was decimal 243 for 'F3'x which is EBCDIC
Oct 11, 2011 numeric/character three. INPUTing TPMPI as $EBCDIC1 would
Oct 15, 2011 create a character variable with value '3', but TPMPI is
a numeric variable, so the field into TPMPICH $EBCDIC1.,
but then TPMPI=INPUT(TPMPICH,1.); will preserve TPMPI to
remain a numeric variable, but with value 3 versus 243.
-Datetime variable TPMDUEOT is now correctly populated but
that variable can have a missing value.
Thanks to Tren Csuy, Humana, USA.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.228 Variables SMF30SNF and SMF30ZNF, the zAAP and zIIP
BUILD005 factors that were used to normalize those Engine's CPU
BUIL3005 time are now kept in PDB.JOBS. This updates Change
Oct 11, 2011 28.139.
Nov 17, 2011 Nov 17: (DROP=_26NJE) was added to DATA TYPE26J2 to
ensure dropping of those NJE variables from PDB.JOBS,
if those variables were still somehow in SPIN26.
Thanks to Jim S. Horne, Lowe's Companies, USA
Change 29.227 -Revised code to read HP MeasureWare NT records with new
VMACMWNT fields added in GLOG record:
Oct 8, 2011 PKDSKPCT='PEAK*DISK*PERCENT'
PKDSKTIM='PEAK*DISK*TIME'
and with the MXG code restructured to match the changed
fields in the REPORT command used to extract the data.
-DDMMYY8 format revised to DDMMYY10 for those dates.
Thanks to Frank Tonneau, KBC Global Services NV, BELGIUM.
Thanks to Geert Debatselier, KBC Global Services NV, BELGIUM.
Change 29.226 False ERROR.TYPE1415.DEFECTIVE EXTENDED INFO SEGMENT
VMAC1415 could print for a record without an Extended Segment. MXG
Oct 7, 2011 code now tests SMF14XSG first to validate existence.
Thanks to Herbert Sweeney, Verizon Data Services, USA.
Change 29.225 INVALID THIRD ARGUMENT OF SUBSTR message and hex dump of
VMACDB2 the record was caused by DB2 V10 record with INVALID QMDA
Oct 7, 2011 segment for QMDAPTYP='JCC' - invalid because it does not
match the DSNDQMDA DSECT in the DB2 Macro Library. Now,
the first three records are detected and MXGWARN messages
are printed on the log, while a PMR will be opened.
Thanks to Kim Morrell, RCMP, CANADA.
Change 29.224 -Utility VMXGGETM selects SMF records for counts or to be
VMXGGETM written, and is enhanced with new arguments SYSTEM=,
Oct 3, 2011 BEGTIME=, and ENDTIME=, to select SMF records by SYSTEM
Oct 24, 2011 and/or ranges of SMFTIME values. This could alternately
be done with the powerful but obscure %LET MACFILE= logic
(the "instream" equivalent of IMACFILE EDIT tailoring).
-LOOKFOR=text, added: selects SMF records with that text.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.223 Support for APAR OA37114, ITRF (OMEGAMON IMS V420 TRF)
VMACITRF TRFOUT record adds five new variables (COMPATIBLY) that
Oct 2, 2011 are output in MXG dataset ITRFMSG.
MI ='SPA*INDICATOR*PSTMI'
MSRC ='MESSAGE*SOURCE*FLAG*PSTFLAG1'
SCHF1 ='QUICK*SCHEDULED*PSTSCHF1'
SPAL ='CURRENT*SPA*SIZE'
VSFLG ='PRIMED*MSG*INDICATOR*PSTVSFLG'
Change 29.222 New tokenid values are now decoded in TYPE80A:
VMAC80A TOKMEMLI='MEMLIMIT'
Oct 2, 2011 TOKSHMEM='SHMEMMAX'
These "NO" value tokens have no data values so they are
output in TYPE80TK with their TOKDANAM to record that the
option was in effect, suppressing a NOT DECODED message:
NOCPUTIMEMAX NOFILEPROCMAX NOPROCUSERMAX NOTHREADSMAX
NOMMAPAREAMAX NOASSIZEMAX
Thanks to Angelito Lontoc, Northern Territory Government, AUSTRALIA.
Change 29.221 -CICS Statistics dataset CICDB2GL fields that were not
FORMATS identified as new were overlooked, but are now added:
VMAC110 D2GPSIGN='PARTIAL*SIGNONS'
Oct 3, 2011 D2GCTHCR='COMD*THREAD*CREATES'
Oct 16, 2011 D2GPTHCR='POOL*THREAD*CREATES'
D2GREHIT='REUSELIMIT*HIT*COUNT'
-Statistics Dataset CICSMDSA variable SMSDSAIN indexes the
type of DSA, but values of '00'x have been found for RDSA
EUDSA, and ERDSA, so the SMSDSANM (DSA Name) is used to
set their value in SMSDSAIN to '04'x, '86'x, and '08'x
when '00'x is found, and the FORMAT $MGCICDS (which maps
SMFDSAIN to the name of the DSA) is updated with values
'09'x (ECDSA), '8D'x (GCDSA) and '7F'x (ESDSA) that were
undocumented in the CICS Data Areas. Variable SMSDSAIN
existed before variable SMSDSANM, the actual DSA Name, so
with these undocumented and '00'x values in SMSDSAIN, the
variable SMSDSANM should be used instead of SMSDSAIN to
identify which DSA name is being reported in CICSMDSA.
-The CICSMDSA variables for "ABOVE THE BAR" storage were
wrong; they are in (undocumented, but now obvious) units
of 1 GB, so they are now converted to bytes and formatted
with MGBYTES to print the correct storage values:
NOTE: ABOVE WRONG, THEY ARE IN MB NOT GB. CHANGE 30.094.
These variables are DSA-specific and corrected:
SMSDSASZ SMSHWMDS SMSCSIZE SMSFSTG SMSHWMFS SMSLWMFS
SMSLFA
These variables are in the header of the CICSMDSA record
and thus repeated in each observation for the interval,
but are also corrected:
SMSGDCUL SMSGDHWL SMSGDCUR SMSGDHWM
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.220 Support for z/OS 1.13. REQUIRES MXG 29.03 or later.
VMAC7072 -VMAC7072. IBM now stores 'FF' character ('C6C6'x !) for
VMAC71 the CPUID (SMF70CID) for engines that don't exist in the
Mar 24, 2011 CPU Data Section, which MXG saw as 50886 decimal, which
VMAC23 caused ARRAY SUBSCRIPT OUT OF RANGE error. MXG logic
Apr 2, 2011 relocated the initialization of the two arrays that used
VMAC113 CPUID as the subscript, and created a DO group to only
VMAC6 process the CPU Data Sections with valid CPUID number.
VMAC42 -VMAC71. TEST for OFFSWAP GE 0 AND NRSWAP GE 0 caused
VMAC64 INPUT STATEMENT EXCEEDED. That test should have been GT
Sep 30, 2011 for a long time (since SWAP datasets went away!!).
Accidentally didn't fail with prior z/OS but was wrong.
Cosmetic: SWAPAUX calculation was moved back inside the
DO group for (now non-existent) SWAP counts so that it
doesn't cause a Missing Values message.
-VMAC23. Two new triplets are decoded, for the new Spin
Lock and Bind Breakdown Instrumentation sections, but
both are currently "For Internal Use Only".
-VMAC6. The Reserved 16-bytes in SMF6INDC=7 Extended Mode
segment contains SMF6IPV6, currently just input and not
kept nor decoded. SMF6URIL, added by OS25152 is not in
the Pre-GA SMF Manual.
-VMAC42. New variables added to several datasets:
SMF42GRU='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMF42GRJ='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMFA2GRJ='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMFA2GRU='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMF42JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK'
SMF42JRC='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
SMFA2JQ2='READ REQS*RETRIED FOR*CASTOUT*LOCK'
SMFA2JRC='READ REQS*RETRIED FOR*CASTOUT*LOCKS'
These fields were added by APAR OA30300.
-VMAC64. New variable added to TYPE64:
SMF64RLM='CA-S*RECLAIMED*IN ESDS*SINCE CLOSE/EOV'
-VMAC7072. New ID=72 Subtype 5 adds 13 new datasets:
dddddd Dataset Description
TY725A TYPE725A RMF III SERIALIZATION DELAY
TY725B TYPE725B RMF III CMS LOCK DELAY
TY725C TYPE725C RMF III CMS ENQUEUE DEQUE LOCK DELAY
TY725D TYPE725D RMF III CMS LATCH LOCK DELAY
TY725E TYPE725E RMF III CMS SMF LOCK DELAY
TY725F TYPE725F RMF III LOCAL LOCK DELAY
TY725G TYPE725G RMF III CML LOCK OWNER DELAY
TY725H TYPE725H RMF III CML LOCK REQUESTOR DELAY
TY725I TYPE725I RMF III GRS LATCH SET CREATOR DELAY
TY725J TYPE725J RMF III GRS LATCH REQUESTOR DELAY
TY725K TYPE725K RMF III GRS ENQUEUE STEP DELAY
TY725L TYPE725L RMF III GRS ENQUEUE SYSTEM DELAY
TY725M TYPE725M RMF III GRS ENQUEUE SYSTEMS DELAY
-VMAC7072. New variables added to TYPE70XT dataset:
R7023CRT='EXEC TIME*ALL OPS*4096-BIT*CRT-FMT'
R7023CRC='NUMBER OF*ALL OPS*4096-BIT*CRT-FMT'
-VMAC71. New variable added to TYPE71:
SMF71LFA='LARGE*FRAME*AREA*SIZE'
All Logical Swap and ESTORE variables are now reserved.
-VMAC113. New variables added to TYPE113
SM1132MM='MACHINE*MODEL'
SM1132MT='MACHINE*TYPE'
Change 29.219 Support for Tivoli Workload Scheduler For z/OS Ver 8.3 is
FORMATS completely incompatible with numerous changes to many of
IMACOPC the tracklog file's records.
VMACOPC -The _OPCVER macro is no longer used, since this update
Sep 24, 2011 supports the current version. However, it may have to
Sep 27, 2011 be reinstated in the future since IBM still does not
Nov 14, 2011 provide the version number in each record.
-There are numerous instances in different MT0TYPE records
that end with a 4-byte field of hex zeros where the next
MTDTYPE/MTDOPER pair were expected. Probably APAR-able,
but it was more expeditious to detect and delete them in
MXG than to take the time to document them for a PMR.
-Invalid TRL 29 record caused INVALID ARGUMENT messages;
the internal %DT macro now tests the incoming arguments
and if the date or time is missing, RETURNs, preventing
those cosmetic messages. With or without those messages
the date values returned were and are missing values.
-Nov 14:
This is not a used record type so the error will not
be pursued until a customer who actually needs this
record type raises the issue.
-There are one new MTD segment, MTDTYPE=16 that is not
not documented in SC32-1261-03.
-MTD17 segment is decoded.
Thanks to Louis Deledalle, BNP Paribas, FRANCE
Change 29.218 Variable CNT30REC is added to PDB.STEPS dataset to count
BUILD005 the number of physical SMF 30 records created for this
BUIL3005 step (which were all consolidated into this observation).
Sep 22, 2011
Change 29.217 Corrected and improved support for the RCDSD section in
ASMRMFV RMF III RCD data is provided.
VMACRMFV -ASMRMFV now correctly calculates the length of the RCDSD
Sep 20, 2011 array that before could cause a SAS INPUT LENGTH ERROR in
Sep 27, 2011 VMACRMFV processing.
Nov 2, 2011 -ASMRMFV now correctly handles an RCDSD when a Class with
Nov 20, 2011 zero periods is detected. An RCDSD cannot exist in this
EXZRBRCP case because the RCDSD pointer is part of the period data
NOV 13, 2013 -VMACRMFV formats for the variables RCDRGCAP and RCDRCGD
were reversed.
-New variables RCDBPMI and RCDSDPH are added to the
ZRBRCDD file by VMACRMFV.
-VMACRMFV now reads both the Begin-To-End and Execution
Phase data for each RCDSD entry. Current documentation
for RMF III did not clarify that each RCDSD entry is
actually a pair of arrays for these two Phases.
-ASMRMFV when processing a CFI Table with the RMF III
CFDETAIL option in effect, did not correctly handle the
condition where no connections exist for a CF Structure.
This resulted in a corrupted CFI Table record and an SAS
INVALID DATA message during VMACRMFV processing.
-When the number of records output for a RMF III table
exceeded 16,277,215 the output record counter in ASMRMFV
would wrap to zero resulting in a very low incorrect
count for that table type. The total record count output
by ASMRMFV would then not match the input record count
from VMACRMFV.
-VMACRMFV did not count the 4 byte RDW (Record Descriptor
Word) in its report of bytes read but ASMRMFV did. Now,
the RDW length is added so that the VMACRMFV byte count
matches the ASMRMFV byte count. However, as neither
ASMRMFV nor VMACRMFV knows how many blocks were written,
both byte counts will not include the 4-byte BDWs (Block
Descriptor Word) for each block.
-The RMF Monitor III version id variable names are now
more consistent with the naming pattern of xxxVERG3.
RCDVERS is now RCDVERG3 (RCD version id). OPDVER is now
OPDVERG3 (OPD version id). SPGVER is now SPGVERG3 (SPG
version id).
-A new variable SVPRTC (Response Time Unit Code) is added
to files with Service Policy data. It is the decoded
value of SVPRTU. This indicates the response time units
for a goal. Values are I=Milliseconds, S=seconds
M for Minutes, H for Hours, and ? for Unknown.
-Added SPACE/NOSPACE parameter option:
-SPACE displays two new messages RMFV030I and RMFV031I
for each RMF Monitor III VSAM data set processed.
-Message RMFV030I shows HARBA (High Allocated Relative
Byte Address), HURBA (High Used Relative Byte Address),
and AVAIL (Available Free Space in Bytes).
-Message RMFV031I shows percent of Allocated Space Used
and percent of Allocated Space Available (Free).
-Both standard & extended format (EF) VSAM data sets are
supported, but RMFV030I message format varies slightly
to accommodate the much larger data sets possible in EF
mode.
-Assembler symbolic variable &SPACE can be changed by
users prior to assembly from the distributed default of
'Y' (SPACE in effect) to 'N' (NOSPACE in effect).
-In conjunction with the existing INDEXES parameter SPACE
is intended to assist MXG users in properly sizing their
RMF Monitor III data sets.
-Program prologue comments documentation was updated.
-Nov 20, 2011:
Change 29.204 (29.05) changed these version variables
PGPVERG3 CPDVERG3 CPUVERG3 CSRVERG3 CFIVERG3 ENCG3VER
OPDVERG3 SPGVERG3 CPUVERNU SVPDVN SVPRTU
from NUM to CHAR, which would create errors combining
PDBs built with different MXG Versions, so they are now
changed back to their original numeric nature. This code
change was NOT in MXG 29.07 dated Nov 14.
-Nov 13, 2013: Exit member EXZRBRCP is no longer called
as ZRBRCP dataset is no longer output, because ZRBRCS and
ZRBRCR now include ZRBRCP variables.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Thanks to Dan Case, Mayo Clinic, USA.
Change 29.216 Cosmetic. The comment in JCLIMSL6 that two %LETs are
JCLIMSL6 needed to set MACKEEP with _IMSVERS was wrong, as it is
TYPEIMSB only in the STEP04 step that the _IMSVERS must be set.
Sep 19, 2011 In TYPEIMSB, the %INCLUDE of VMACIMS and IMACKEEP and
the comment "to get _IMSVERS" was removed because that
program has no dependency on any of the IMS macros.
Thanks to Trevor Ede, HP, NEW ZEALAND.
Change 29.215 Variables T119STCK, TISSTCK and TIESTCK weren't converted
VMAC119 from GMT to LOCAL, but now are.
Sep 19, 2011
Thanks to Robert Stoffregen, Great Lakes Higher Education Corp., USA.
Change 29.214 Almost cosmetic. In subtype 2 (TYPE78PA dataset) eight
VMAC78 variables ending with TOTL were mislabeled as samples but
Sep 19, 2011 they are the total memory for all samples, so they are
now correctly labeled and added to MGBYTES format to show
they contain memory values. Variables LGMOMIN/TOFRMIN are
RB8 floating point fields, but they can contain hex value
7FFFFFFFFFFFFFFFx (presumably on systems that don't have
large memory frames), so they are now set missing (rather
than decimal values 7.237E75!). Some datetimestamps are
no populated (hex zeros for TODSTAMP8), so they are set
to a missing value (automatically, by SAS).
Thanks to Tony P. Steward, CSC, ENGLAND.
Change 29.213 Support for DB2 V10 IFCID 225 (Subtype=4) INCOMPATIBLE.
CLEARDB2 The IFCID 225 record contains important storage metrics,
EXDB2225 and is written each statistics interval. In DB2 V8, it
READDB2 was a trace record (ID=102,IFCID=225), creating T102S225
VMACDB2 dataset. In V9, it became a statistics interval record
VMXGINIT (ID=100,SUBTYPE=4) creating DB2STAT4 dataset, but with
Sep 20, 2011 the same suite of 8-byte field/MXG-variable names, and
Sep 23, 2011 because it was then recognized as useful, those QW0225xx
variables were added transparently into PDB.DB2STATS from
either DB2 V8 T102S225 or DB2 V9 DB2STAT4 datasets.
But now, DB2 V10 completely and incompatibly restructured
(but also significantly enhanced the storage metrics) in
the IFCID=225 record, still writing it as SUBTYPE=4, with
some fields preserved, but with many new fields with long
names, that I now use for MXG variable names, rather than
struggling to create unique two-character suffixes and
8-byte names (but two new prefixes are needed for the new
separate storage used by DBM1 & DIST address spaces, so
those sets of variable's names are QWA225xx/QAB225xx.
-For DB2 V10, IFCID=225 records are output in PDB.DB2ST225
dataset, and all variables in DB2ST225 are automagically
merged into PDB.DB2STATS dataset with all these programs:
TYPEDB2/TYPSDB2/BUILDPDB/READDB2(IFCIDS=STATISTICS).
-With DB2 V10, the PDB.DB2STAT4 dataset will have zero
observations from DB2 V10 data, since it is populated
only from DB2 V9 IFCID=225 records.
-Test data from the same DB2 Subsystem (QWHSSSID), when
the release changed from V8 to V10, had negative CPUTM in
that statistics interval, because there is no field in a
DB2 Header that clearly identifies when a DB2 subsystem
is started (i.e., unlike CICS records, that have the JOB
and READTIME). Normally, a restart resets QWHSISEQ to a
smaller value, but in this case, that sequence number was
larger in the V10 record than the prior V8 record! So,
MXG now tests both QWHSISEQ and SEQCHECK to circumvented
the IBM omission. That SEQCHECK test in the "bad" data
interval did identify the problem, so the previous test
of SEQCHECK GT 0 was enhanced to 0 LT SEQCHECK LE 5 to
confirm the inteval is valid with no restart.
Thanks to Betty Wong, Bank of America, UDS.
Change 29.212 Invalid JES3 JMF SMF 84 Subtype 1 Segmented Records.
VMAC84 After long discussions with JES3 SMF 84 Support Folks, I
Sep 16, 2011 understand how JMF creates multiple, segmented records
Oct 11, 2011 when there are more entries (FCTs) that will fit in one
SMF record. I can probably circumvent the absence of the
JMF PROD section (source of start/end times!) that is NOT
written in the 2nd and subsequent segments, but ONLY if I
add post-processing steps to sort and to populate those
missing values, and ONLY if there are no missing segments
in the SMF file.
-BUT, there is NO WAY that I can directly process each of
these segmented records, because sections (FCT ENTRY) are
truncated and split (a/k/a "spanned" in JES3 circles) and
written in two separate physical SMF records, but there
are no length fields to identify how many bytes were in
which record.
-Processing these JMF segmented records will require a new
MXG design, to first reconstruct legitimate VB records
without truncated sections, and then process those SMF
records in a separate process. I get to do this because
IBM regards this as "working as documented".
-But, fortunately, JMF records are not typically created
every day; they tend to be turned on and then off for a
study, so we can live with waiting a day to process all
of the JMF records from a study. And, this one very
small glitch in just one part of one subtype of the VERY
comprehensive JES 3 Monitoring Facility is now bypassed,
so all the rest of the JMF datasets are fully usable,
all of the other segments of this subtype 1 record, and
even those first 78 FCT entries are output; MXGWARN notes
on the SAS log alert you there were FCT segments missed.
-The specific case investigated: There were more FCT than
would fit in one SMF record. FCT entries are variable
length sections with many optional subsections. JMF
created 4 physical SMF records, segment numbers 1-4:
-The First segment has JMF PROD, JMF GENE, R84JES3O and
R84IRBSC offsets populated and has no FCT entries.
-The Second segment doesn't have JMF PROD nor JMF GENE
(needed for Interval Start and End times), and has only
R84FCTO, which points to a valid FCT "Header" section
(but R84FAWLN is the TOTAL length of all FCTs, and in
R84FCTN=250 is the total count of all FCTs in all segs;
what's needed here is how many FCTs are in THIS record!
This second segment then contains 78 complete FCT entry
sections, with R84FSEQN 1 thru 78, but then, only the
first part of FCT number 79 was written in this SEGNR=2
SMF record: the last 72 bytes were truncated.
-The Third segment also has no JMF PROD nor GENE sections
and does NOT contain an FCT Header section; it contains
only FCT entries, but it's data area STARTS with those
last 72 bytes of FCT entry number 79, and then FCT entry
number 80 thru 187 are contained in this SEGNR=3 record.
-Finally, the Fourth Segmented Record is like the third,
no PROD/GENE/FCT Header, only FCT entries, but its data
area (happens?) to start with FCT Entry R84FSEQN=188's
byte one, and then FCTs 189 thru 250 are complete in the
SEGNR=4 JMF record.
-Unrelated to the above issues, truncated subtype 2
records were discovered; IBM APAR OA37982 is now open to
correct that error.
Thanks to Lucy F. Trabulus, Bank of America, USA.
Change 29.211 Support for Throughput Manager APAR TMT6214, corrects the
VMACTPMX invalid subtype 16 triplets when there were more than 76
Sep 21, 2011 steps in a job. Those invalid triplets caused the ERROR:
INPUT STATEMENT EXCEEDED RECORD. The APAR corrects the
error by creating multiple "continuation" records when
when there are more than 76 steps, and installing their
APAR eliminates the INPUT STATEMENT EXCEEDED ERROR.
A new version of MXG is NOT required to support the APAR.
But, to create observations in TPM16J dataset, you need
Change 29.200, in MXG 29.06, to correct an unrelated MXG
coding error that caused zero observations to be created.
And, job-info variables were only added to the TPM16J
dataset by THIS change, which will be in MXG 29.07, or
can be requested now via email from support@mxg.com).
-Support for Subtype 5 PCS segment is added, with those
variables added to the existing TPMSLM dataset when the
PCS segment is present. The variable names are taken
verbatim from the DSECT, so most are longer than the old
8-byte ASM DSECT field names.
Change 29.210 The spelling of most variables available in this header
IHDRTMVS exit for selection were wrong. And, variable LMRKJOBC is
VMACTMVS NOT the JOB name of the Landmark Monitor for z/OS, but is
Sep 14, 2011 the SYSTEM ID of that system, so it's label is corrected,
and it can be used to select by SYSTEM.
Thanks to Sam Bass, McLane Co., USA.
Change 29.209 DB2 V10 ID=100 SUBTYPE=1 with INVALID HEADER caused INPUT
VMACDB2H EXCEEDED RECORD LENGTH error. The defective record had
Sep 14, 2011 0122x (290 decimal) for the offset to the un-truncated
QWHSOPID field, with that QWHSTYP=2 starting in byte 5375
but 5375+290=5665, while the LENGTH of the data portion
was only 5534 bytes. Protection for this invalid header
field has been added for all of the "untruncated" fields
in the QWHSTYP=2 Header segment. IBM might be contacted.
Thanks to Tom Pierce, LabCorp, USA.
Change 29.208 IBM i-Series (AS400) with more than 32 CPUs create two
VMACQACS records in QAPMSYSC dataset (IBM "QAPMSYSCPU") for each
Sep 14, 2011 interval, with the first 32 engines in the first record
and the second 32 engines in the second record. You must
now invoke the _SQAPSYC macro after your _TQAPSYC macro
when you read the QAPMSYSC infile:
%INCLUDE SOURCLIB(VMACQACS);
_TQAPCON
_TQAPSYC
_SQAPSYC
as the _SQAPSYC macro now sums those two records to
create a single observation per interval, with the
(corrected) PCTCPUBY percentage, and the new variable
SCPUSUM with the total CPU time for all online engines.
Thanks to Karen Florup, Bank of America, USA.
Change 29.207 MONWRITE Broken Control Record error due to incomplete
VMACVMXA decoding of the 2.14 (SCLALL) Schedule Domain record.
Sep 13, 2011 The error message gives no clue the cause is the 2.14.
This is the first MONWRITE file in a long time that had
SCL (Schedule) domain records enabled; they are rarely
turned on due to large volume, and provide low-level
trace-like event data that requires pretty deep knowledge
of z/VM internals to be useful, but now they too are
supported.
Thanks to David J. Schumann, Blue Cross of Minnesota, USA.
Change 29.206 Cosmetic. VMXGSUM now dies gracefully with an MXGERROR:
FORMATS message if there is no input dataset to process.
VMACEDGR
Sep 13, 2011
Thanks to
Change 29.205 Cosmetic. New format MGEDGCF decodes variable COMEFROM
FORMATS to identify which variable will be missing when invalid
VMACEDGR dates (e.g., 2000/000) are found in RMM records.
Sep 13, 2011
Thanks to
====== Changes thru 29.204 were in MXG 29.06 dated Sep 8, 2011========
Change 29.204 -Support for RMF III RCD data, promised in Change 29.187,
EXZRBRCX is now completed. The new ZRBRCDX dataset contains the
IMACRMFV Response Times for Reporting Classes and the existing
VMACRMFV ZRBRCDT datasets is updated with Response Times for the
VMXGINIT Service Classes.
Sep 7, 2011 -BY lists BZRTRCS/RCR/RCP/RCD were revised.
Sep 13, 2011 -Cosmetic changes, PCT, Version, etc.
Change 29.203 The labels for variables PC24RHWM and PC24SHWM for the
VMAC110 "Below 16MB" areas had ERDSA and ESDSA but those labels
Sep 7, 2011 should have been RDSA and SDSA.
Thanks to Steven Kimball, Aetna, USA.
Thanks to Victoria Lepak, Aetna, USA.
Change 29.202 The _IDEDGSA macro default value should be 512 but it was
VMACEDGS left with 8Ax (138) after a test with user's data, and if
Sep 7, 2011 you have an ID=138 record in your SMF file, JCLTEXTx will
fail (INPUT STATEMENT EXCEEDED).
Thanks to Walter Noniewicz, State of Connecticut, USA.
Change 29.201 -Support for DB2 V10 restructured IFCID=217 record, which
VMAC102 caused T102T217 and T102U217 to have zero observations,
Sep 7, 2011 but (fortunately) the incompatible record format did NOT
cause an execution error. Dataset T102S217 now has only
one unique variable, and new QW0217AL and QW0217AS ASIDs
were added to T102T217 & T102U217 datasets respectively.
Dataset T102V217 always has zero observations (after V8).
-Unrelated, many offseg+lenseg LE LENGTH segment tests are
corrected to offseg+lenseg-1; the incorrect test could
have prevented reading legitimate segments.
Thanks to Betty Wong, Bank of America, UDS.
Change 29.200 No observations were created in TPM16J dataset because
VMACTPMX the MXG test comparing segment offset+length with the
Sep 7, 2011 record length was off by one, preventing input/output.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.199 The %SYSPROD(GRAPH) function doesn't validate that the
GOPTIONS product is installed; it only confirms that the SETINIT
DOC licenses SAS/GRAPH. The MXG test in VMXGINIT to set
VMXGINIT GOPTIONS for SAS/GRAPH examples in MXG GRAFxxxx members
Sep 4, 2011 (that was added without a change number in MXG 28.05)
is true when the SETINIT said yes, but GOPTIONS/PATTERNn
statements fail when SAS/GRAPH isn't actually present,
with a 180 syntax error on the GOPTIONS statement, since
those procedure-specific statements can't compiled if the
product isn't installed. The new PROC PRODUCT_STATUS will
list all products that are installed, but its use would
require a PROC PRINTTO to trap its output to a file, a
DATA step to read that file, and new %macro variable and
logic, just to set these (optional!) SAS/GRAPH options.
So, to prevent a 180 error in VMXGINIT, these statements
GOPTIONS COLORS=(R B G CYAN MAGENTA ORANGE GREY BROWN BLACK);
PATTERN1 V=S; PATTERN2 V=L1; PATTERN3 V=R1; PATTERN4 V=X1;
PATTERN5 V=L2; PATTERN6 V=R2; PATTERN7 V=X2; PATTERN8 V=L3;
PATTERN9 V=R3; PATTERN10 V=X3;
are no longer set in VMXGINIT, but are moved into the new
GOPTIONS member, and all GRAFxxxx members were updated to
set them with %INCLUDE SOURCLIB(GOPTIONS);
-Also, MXG macro variables SASGRAF and SASSTAT are removed
from VMXGINIT; they were never referenced in any MXG code
and were set by %SYSPROD(), so they too could be wrong.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
====== Changes thru 29.198 were in MXG 29.06 dated Sep 1, 2011========
Change 29.198 iSERIES variable GDES21 was multiplied by 4096, but it
VMACQACS should have been multiplied by 1024; when GDES11 is all
Aug 31, 2011 nines, GDES21 contains the storage assigned to the LPAR.
Thanks to David Bixler, FISERV, USA.
Change 29.197 Two new segments in Velocity Software XAM Version 4.1 CPU
VMACXAM record are decoded (PRCINS,PRCDIA) but not output as they
Aug 31, 2011 are repeated and hence need new datasets created, and the
new STOASC (DEV) and new SYTLCK (SYS) weren't documented;
these four segments were protected for the NEW SEGMENT
messages but were not decoded. See Change 29.253.
Change 29.196 MXG calculation of GMTOFF30 in SMF 30 records could be
VMAC30 off by 0.01 second, only for positive GMT Offsets, but
Aug 31, 2011 that impacted the BUILDPDB logic that combines MULTIDD=Y
records for a step, when there were intervening SMF 30s
from a different job in between the MULTIDD=Y records.
The MULTIDD=Y records don't contain SMF30IST, so GMTOFF30
must be retained from the prior non-MULTIDD record, but
in this case, SMF30IST was 0.07 with SMF30ISS 0.073983 in
the non-MULTIDD, but an intervening step's non-record had
SMF30ISS of 0.075983 with SMF30IST of 0.08, causing MXG's
(failing) fuzzy logic use GMTOFF30 of .01 in MULTIDD=Ys
from the first step. This caused BUILDPDB to not include
the EXCP/IOTM counts in PDB.SMFINTRV for the MULTIDD's,
so while TYPE30_V had 26 million EXCPs, only 24 million
were in PDB.SMFINTRV for that day's DB2 intervals.
The real culprits, aside from MXG's failing fuzzy logic,
is the absence of GMTOFF in SMF 30 records, the absence
of SMF30IST in the MULTIDD=Y records, and SMF30ISS being
an 8-byte (LOCAL) TODSTAMP with microsecond resolution,
while SMF30IST (GMT) is an 8-byte SMFSTAMP with only 10
millisecond resolution. The correction for MXG's logic
error is to first use ROUND(SMF30ISS,.01) before its
comparison with SMF30IST so both have 10 millisecond,
rounded, values, so GMTOFF30 is correctly calculated for
both positive and negative GMT offsets.
A formal request to IBM SMF30 development to add the long
overdue GMT Offsset has again been made so that MXG logic
is not needed to compensate for its absence.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 29.195 MXG now terminates reading TMS data with USER ABEND 1234
VMACTMS5 and an ERROR message if the input file is not the TMC.
Aug 30, 2011 The TMSGRW TMS utility program creates 340 byte records
that MXG read, but they produced incorrect results.
MXG support requires the TMC data as its input file.
Thanks to Srini Anne, State of California, USA.
Change 29.194 Statistics on Page Datasets are added to RMFINTRV (so if
VMXGRMFI your DB2 DBAs add massive buffers and eat up all of your
Aug 27, 2011 page datasets, you'll at least be able to prove why the
system died for lack of paging space!). New variables:
MAXCOMN ='MAXIMUM*COMMON*SLOTS USED'
MAXLOCL ='MAXIMUM*LOCAL*SLOTS USED'
MAXPLPA ='MAXIMUM*PLPA*SLOTS USED'
NRDSLOCL='ACTIVE*LOCAL*DATASETS'
PCTLOCL ='AVERAGE*PERCENT*SLOTS USED*ALL LOCALS'
PCTMAXLO='MAXIMUM*PERCENT*SLOTS USED*ANY LOCAL'
PCTCOMN ='PERCENT*COMMON*SLOTS USED'
PCTPLPA ='PERCENT*PLPA*SLOTS USED'
SIO75CNT='PAGING*SIO*COUNT'
SLOTCOMN='COMMON*SLOTS*DEFINED'
SLOTLOCL='LOCAL*SLOTS*DEFINED'
SLOTPLPA='PLPA*SLOTS*DEFINED'
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.193 -ANALZPCR with PDB=SMF reads 113s as well as the others
ANALZPCR and invokes ASUM113.
UTILBLDP -UTILBLDP adds SMF 113 processing, conditionally:
Aug 27, 2011 If BUILDPDB EQ YES and USERADD does not contain 113 it is
added to USERADD, and if INCLAFTR doesn't contain ASUM113
it is added there.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.192 If the length of text in the list of DDNAMEs passed into
UTILCONT UTILCONT exceeded 256 bytes, the list was truncated and
Aug 26, 2011 remaining datasets were not read. Increased to 32000.
Thanks to David Bixler, FISERV, USA.
Change 29.191 Windows 7 may error when attempting to write files to the
DOC root directory (e.g., C:\ if that is your boot directory)
Aug 24, 2011 or to the c:\windows or the c:\program files directories,
with a message about "Insufficient authorization to use".
The error may be circumvented if the program is "run as
authorized", but some MXG examples of ASCII syntax had
"c:\filename.xxx" that could cause the error, so all
instances of that syntax were revised to explicitly
have a directory name (e.g. "c:\mxg\filename.xxx').
In addition, some ASCII LIBNAME examples (which always
point to a directory rather than a file) did not have
a final slash character (LIBNAME PDB 'C:\PDB';) and thus
were unclear that the syntax requires a directory name.
Those examples are now changed to include a final slash
(LIBNAME PDB 'c:\pdb\';) to reinforce that the object is
a directory and not a filename.
Change 29.190 In this "JCLSPLIT" example, CICSTRAN was incorrectly sent
BLDSPSMA to //WORK DD instead of the correct //CICSTRAN DDname.
JCLSPSMA
Aug 23, 2011
Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA.
Change 29.189 Support for Software AG's ADABAS SMF User record creates
EXADUSER sixteen new datasets:
EXADPARM
EXADSTG DDDDDD MXG MXG
EXADIODD DATASET DATASET DATASET
EXADTHRD SUFFIX NAME LABEL
EXADFILE
EXADCMD ADUSER ADABUSER ADABAS USER RECORD
EXADCSP ADPARM ADABPARM ADABAS PARM RECORD
EXADCSG ADSTG ADABSTG ADABAS STG RECORD
EXADCSB ADIODD ADABIODD ADABAS IODD RECORD
EXADCSF ADTHRD ADABTHRD ADABAS THRD RECORD
EXADLOK ADFILE ADABFILE ADABAS FILE RECORD
EXADMSGB ADCMD ADABCMD ADABAS CMD RECORD
EXADMSGC ADCSP ADABCSP ADABAS CSP RECORD
EXADMSGH ADCSG ADABCSG ADABAS CSG RECORD
EXADREV ADCSB ADABCSB ADABAS CSB RECORD
IMACADAB ADCSF ADABCSF ADABAS CSF RECORD
TYPEADAB ADLOK ADABLOK ADABAS LOK RECORD
TYPSADAB ADMSGB ADABMSGB ADABAS MSGB RECORD
VMACADAB ADMSGC ADABMSGC ADABAS MSGC RECORD
VMXGINIT ADMSGH ADABMSGH ADABAS MSGH RECORD
Aug 24, 2011 ADREV ADABREV ADABAS REV RECORD
-Datasets ADPARM, ADSTG, ADTHRD, ADFILE, and ADCMD are now
decoded and validated with SMF records; the others have
been coded but are untested with actual data records.
-Datasets ADABTHRD and ADABFILE do not have fields that
identify the Thread/File; counters ADTHRDNR and ADFILENR
are created as the sequence number in each record, but in
the test data, only the first instance in each record has
a non-zero count (but there are many instances in each
record with zero counts that perhaps should be deleted).
Thanks to Wayne Campos, Corelogic, USA.
Change 29.188 -Blank TRANNAME in ASUMUOW occurred with MXG 28.05 that
IMACUOW were not present with MXG 28.04, so new Case 4 example is
VMXGUOW created to handle this sequence of DB2/CICS/MQ records.
Aug 23, 2011 Precipitated possibly by our changes to VMXGUOW, as the
only site difference is that remote program definitions
with a remote tranid on them are used.
-New debugging TRACEUOW=TRAN option was added/needed to
diagnose this problem: at the endpoint, it tells you
everything there is to know about that particular UOW
when the TRANNAME comes up blank.
-All of the macros that are typically tailored are now
defined in the IMACUOW member, and you should EDIT that
member into your "USERID.SOURCLIB(IMACUOW) and make your
tailoring there, and should NOT now ever have VMXGUOW in
your "USERID.SOURCLIB" tailoring library.
Thanks to Dave Campbell, SunTrust, USA.
Change 29.187 -MXG 29.05 only. ASMRMFV could fail with 0C4 ABEND. Under
ASMRMFV some conditions, IBM did not create a Period Data
VMACRMFV Extension for a Report Class in the RCD record. The count
Aug 23, 2011 field was unexpectedly zero, causing a loop counter to
Sep 1, 2011 become negative, and the 0C4 during an MVCL command.
This condition was never observed during testing.
-This ASMRMFV properly outputs the RCD records, but the
MXG code in VMACRMFV has not yet been updated to read
those records, and prior VMACRMFV could fail trying to
read the new RCD output, so this VMACRMFV skips over any
RCDG3 records. If you want those data, contact support
since the VMACRMFV updates should be done by the time you
read this text.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Thanks to Jason, Bierman, Great Lakes Higher Education Corp., USA.
Change 29.186 Support for InfoSphere Classic Federation Server Account
EXCFSACC user SMF record creates two new datasets:
EXCFSACV
IMACCFS
FORMATS DDDDDD MXG MXG
TYPECFS DATASET DATASET DATASET
TYPSCFS SUFFIX NAME LABEL
VMACCFS
VMXGINIT CFSACC CFSACCT INFOSPHERE CLASSIC FEDSRVR CPU
Aug 15, 2011 CFSACV CFSVIOL INFOSPHERE CLASSIC FEDSRVR VIOLATE
These possible violations are formatted in MGCFSTY:
101:NOT AUTH TO ISSUE A DROP TABLE FOR TABLE
102:NOT AUTH TO ISSUE A DROP INDEX FOR TABLE
103:NOT AUTH TO ISSUE A DROP VIEW FOR VIEW
104:NOT AUTH TO ISSUE A DROP PROCEDURE FOR STORED PROC
200:NOT AUTH TO CREATE TABLE
201:NOT AUTH TO CREATE INDEX
202:NOT AUTH TO ISSUE THE CREATE VIEW STATEMENT
203:NOT AUTH TO ISSUE THE CREATE PROCEDURE STATEMENT
300:NOT AUTH TO ISSUE A SELECT STATEMENT FOR TABLE/VIEW
301:NOT AUTH TO ISSUE AN UPDATE STATEMENT FOR TABLE
302:NOT AUTH TO ISSUE AN INSERT STATEMENT FOR TABLE
303:NOT AUTH TO CALL STORED PROCEDURE
403:NOT AUTH TO ISSUE A DELETE STATEMENT AGAINST TABLE
500:NOT AUTH TO ISSUE GRANT STATEMENT
501:NOT AUTH TO ISSUE REVOKE STATEMENT
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Thanks to Jim Poletti, Edward D. Jones, USA.
Change 29.185 GRAFWRKX used the old IMACWORK workloads to graph the
GRAFWRKX workload variables and had work1-work99 parameters
Aug 13, 2011 for the new. This change removes the need to specify
workload parameters unless you want to alter the order
in which the bars are stacked. Support for the old
IMACWORK workloads is removed but VGETWKLD is used to
capture all of the workloads unless you specify WORK1-
WORK99 values. If you do not specify WORKx values the
workloads are stacked alphabetically from bottom of the
bar to the top. Except that uncaptured will ALWAYS be
at the bottom. If you specify WORK1-x workloads then
the bars are stacked bottom to top starting with WORK1
and going up numerically. You can still use the old
IMACWORK definitions but the parameters are dead and
do not function.
Change 29.184 GRAFRMFI used the old IMACWORK workloads to graph the
GRAFRMFI workload variables and had no provision for the new
VGETWKLD VMXGRMFI sets of workload variables. It now uses
Aug 13, 2011 VGETWKLD to find the workloads that are defined in
your RMFINTRV dataset (whichever method is used) and
uses those workloads and labels to graph the workload
variables.
This is part of the ODS change 29.169, but the change in
the member are so extensive that it warranted a separate
change.
Numerous issues corrected in this change/circumvention:
-TIME VALUE NOT VALID FOR TIME FORMAT. SAS V9.3 only.
if all obs had a missing value for a TIME variable, that
WARNING was printed; circumvented with WHERE clause, but
that raised another WARNING about WHERE CLAUSE changing.
The more insidious problem was the structure:
PROC GPLOT;
PLOT A
PLOT B
PLOT C
PLOT D
PLOT E ....
Which worked fine unless all the obs had missing values
for one of the variables. For example, if A has all
missing values, then, instead of skipping over B, it
made a copy of A. Even worse, IF B C D E all had
missing values, then you got 5 copies of A instead of
the 1 you really wanted.
The solution was to change the structure to:
PROC GPLOT;
PLOT A
PROC GPLOT;
PLOT B
PROC GPLOT;
PLOT C
PROC GPLOT;
PLOT D
PROC GPLOT;
PLOT E ....
It runs a little slower but it eliminated that problem
as well as the warning about the where clause changing.
WARNING: This routine can produce hundreds of graphs;
the number is a function of the number of system, days,
and workloads.
-Code to execute from any populated RMFINTRV dataset:
%GRAFRMFI(PDB=WORK,
ODSTYPE=HTML,
ODSPATH=c:\HTMLTEST,
ODSFILE=GRAFRMFIBODY.HTML);
Change 29.183 Variable SMF19VLI never existed and is no longer created.
VMAC19 This is an overlay for SMF19TRK and SMF19TRM which were
Aug 13, 2011 invalid prior to this correction.
Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 29.182 -Invalid ASP.NET Applications record caused ERROR: INPUT
EXNTNEDP STATEMENT EXCEEDED RECORD LENGTH (record had NRDATA=40
IMACNTSM but header said 75 should exist, which is what MXG
VMACNTSM expected). Circumvention detects number of words in the
VMXGINIT NT SMF record and deletes with an MXGERROR: message.
Aug 11, 2011 -New Object .NET DATA PROVIDER FOR SQLSERVER supported
-Segments ACSR,SQGS,SQDA,SQSS,QLSS and SQBS have IDPROCES
and SQLVERSN variables added.
-After circumvention code was implemented, user found out
the data file had been truncated during ftp transfer, but
I left the update in place since it was tested and safe.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 29.181 %ANALDB2R argument PMIOS05 was not %UPCASED by MXG, so no
ANALDB2R IO SUMMARY REPORT was produced if PMIOS05=yes was used.
Aug 11, 2011
Thanks to Howard L. Curtis, Progress Energy, LLC, USA.
Change 29.180 Harmless MXGWARN: DURATM=INTERVAL WAS SPECIFIED message
ASUMMIPS is eliminated; DURATM was in the SUM= list when it should
Aug 10, 2011 not have been.
Thanks to Bernhard Bablok, Allianz, GERMANY.
Change 29.179 Undefined TOKEN= $ZEKE_Z with TOKENID=59674 now skipped,
VMACTPMX as are all of the defined-but-not-used ZEKE fields.
Aug 10, 2011
Thanks to Scott Wiig, U.S. Bank, USA.
Change 29.178 Variable CECSER, a 6-byte text variable with only the
VMAC89 left four positions populated, with two blanks at the
Aug 9, 2011 right end, is now created in TYPE89 and TYPE892 datasets
to match CECSER in the RMF TYPE70xx data. SMF89SER is a
three-byte character variable containing text in hex with
format $HEX6., so it printed '0178E0', including the 01x
CPUID value. But CECSER in RMF records is only the text
'78E0 ' value, and that is now the value in CECSER in
the TYPE89 and TYPE892 datasets.
Thanks to Warren Cravey, FMR, USA.
Change 29.177 Support for APAR OA35175, logstream statistics in SMF 23,
EXTY23LS creates new TYPE23LS dataset with these new data:
IMAC23 SMF23LFA='AMOUNT*OF EACH*BUFFER*ALLOCATION'
VMAC23 SMF23LFG='VARIOUS*FLAGS'
VMXGINIT SMF23LFH='HWM*BUFFER*ALLOCATION'
Aug 9, 2011 SMF23LFL='CURRENT*BUFUSEWARN*IN EFFECT'
SMF23LFM='CURRENT*DSPSIZMAX*IN EFFECT'
SMF23LFT='TOTAL*BUFFER*STORAGE*CURRENTLY*USED'
SMF23LSL='LENGTH*OF LOGSTREAM*NAME'
SMF23LSN='LOGSTREAM*NAME'
SMF23LF1='BUFUSEQARN*FROM THE*GLOBAL*OPTION?'
SMF23LF2='DSPSIZMAX*FROM THE*GLOBAL*OPTION?'
APAR OA37002 (see NEWSLTRS) adds new DSPSIZMAX argument
for SMFPRMxx to set logstream buffer size(s).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.176 -APAR OA36816 adds bit to SM113CF1 in SMF 113 HIS record
FORMATS that is now decoded by $MG113FL format to display:
Aug 9, 2011 '08X:LOST COUNTER DATA' when SM113CF1 is printed.
-And it adds new option of interest to HIS SMF 113 users:
The DATALOSS parameter for the F HIS command has been
enhanced to control what action is taken by HIS when
any type of instrumentation data is lost. Prior to this
enhancement, the DATALOSS parameter only reacted to
sampling data lost due to a buffer overflow. The
DATALOSS parameter now reacts to instrumentation data
lost due to a Loss Of Sample Data Measurement Alert and
a Loss Of Counter Data Measurement Alert. By
specifying DATALOSS=IGNORE these types of
instrumentation data loss can now be ignored, and the
instrumentation run may continue.
Change 29.175 Support for APAR OA35617 documents two new SMF30PF2 bits
VMAC30 creating SMF30CRM (ASID IS VELOCITY GOAL MANAGED) and
Aug 9, 2011 SMF30PIN (INCOMPLETE WLM DATA?), one-byte flag variables.
SMF30PIN was just observed (overlooked) and now created.
The APAR documents SMF30CRM with this note:
the address space matched a classification rule which
specified "manage region using goals of both", which
means it is managed towards the velocity goal of the
region. But, transaction completions are reported
and used for management of the transaction service
classes with response time goals. This option should
only be used with CICS TORs, the associated AORs
should remain at the default "manage region using
goals of transaction".
Change 29.174 Support for APAR OA34895 adds new EXCP/IOTM SMF 30 fields
IMAC30IO (transparently) with step/interval total I/O Count and
VMAC30 I/O Connect times (new MXG variables EXCPMISS/IOTMMISS)
Aug 9, 2011 with counts that would have also been in a DD segment(s),
Aug 27, 2011 but weren't, because an SMF Lock (to update the TIOT for
VMAC434 serialization) could not be obtained. The xxxxMISS counts
VMAC40 ARE included in the asid/step totals, EXCPTOTL/IOTMTOTL,
read directly from the SMF record, but were not counted
in any of its DD segments, so they are ALSO already in
EXCPNODD/IOTMNODD, the "NOT COUNTED IN DD SEGMENT" vars
MXG creates with EXCPNODD=EXCPTOTl-EXCPTODD.
All of the above is true, WITH OR WITHOUT this change.
This change only creates the new variables and keeps them
in datasets in TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6 and
PDB.SMFINTRV, and in BUILDPDB's PDB.STEPS/PDB.JOBS (where
member IMAC30IO controls which SMF 30 I/O variables are
kept in the those BUILDPDB/BUILDPD3 datasets. These new
"missed" variables would be useful to at least partially
explain steps with large values in NODD and TOTL fields,
if the xxxxMISS values are non-zero. See NODD in ADOC30.
-Compiler faker added in VMAC434/VMAC40.
-Transparently added, but if you (incorrectly) have an old
VMAC30 in your tailoring library, that will cause
ERROR: EXCPMISS NOT FOUND in BUILDPDB at MXGSUM3.
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 29.173 Support for APAR OA36966 for JES3 expands NJEJOBNO to
VMAC57 four bytes in SMF 57 record.
Aug 9, 2011
Change 29.172 APAR VM64961 adds SMF 113 Hardware Monitor counters to
EXPRCMFC the z/VM MONWRITE data on z/10 and later processors. PTFs
VMACVMXA will be available for z/VM 5.4 and z/VM 6.1 and 6.2.
Aug 8, 2011 Dataset VXPRCMFC contains the same variable names as
TYPE113, but there is no SYSTEM variable in z/VM so it
wasn't added into ASUM113. This support was in MXG
29.04, but undocumented.
Change 29.171 The example WEEKBLDT had four instances of _WKBLD that
WEEKBLDT should have been spelled _WEEKBLD; they caused a SAS
Aug 7, 2011 180 syntax error, after creating WEEK.TYPE72 dataset.
Thanks to Ron Wells, American General Finance, USA.
Change 29.170 The insertion of the _TODAY old style macro caused
BLDSMPDB the forceday option to fail.
Aug 7, 2011
Thanks to Cletus McGee, ALFA Insurance, USA.
Change 29.169 MXG examples that use ODS HTML on ASCII that did not have
ANAL72GO a PATH= statement failed with
ANALACTM ERROR: a COMPONENT C:\.... IS NOT A DIRECTORY."
ANALAVAI but only in QA Tests with SAS V9.3; no user had reported
ANALDB2B this error, which can occur with SAS V9.1,V9.2, or V9.3,
ANALHTML nor had we seen the error with earlier SAS Versions.
ANALIDMS SAS Note SN15046 says to eliminate the error you should
ANALINIT use this recommended syntax on ASCII platforms:
ANALPKGS ODS HTML PATH="C:\mxg\"(URL=NONE) body="temp.html";
ANALRAID Previously, MXG had inconsistent ODS examples; this
ANALRANK change formalizes MXG support to create HTML output.
ANALS225 -We use two new %macros VMXGODSO/VMXGODSC to OPEN/CLOSE
GRAFCEC ODS output in our examples, and they can be used in your
GRAFRAID report programs, to create HTML output. The macros can be
GRAFRMFI invoked on z/OS to send html output to either a PDSE or
GRAFTAPE to a ZFS filesystem, or on ASCII to .html files.
GRAFWLM -A consistent set of macro variables are used in arguments
GRAFWRKX so %LET's can be used to change ODS argument's values.
VMXGODSO change revised all of the MXG members with ODS examples.
VMXGODSC -SAS ODS inconsistencies we discovered and handle:
Aug 14, 2011 the URL= must be either a quoted string or unquoted NONE,
and the STYLE= and TRANTAB= arguments are unquoted.
-SAS HTMLBLUE default does not break PROC PRINT output
lines, requiring scrolling across to see all variables.
ODS LISTING; will change the default back to what you
were used to for all interactive output.
Change 29.168 Velocity Software XAM variable PERFCPU is now in seconds
VMACXAM and formatted TIME12.2 in datasets XMHSTAPP and XMHSTSFT.
Aug 1, 2011 Those datasets contain HSTAPP resource usage of a group
of processes that form an application (in snmpd.conf or
ESATCP 'guessing'). If you want to look at individual
processes, you would use dataset VXVSISFT instead.
Thanks to Joe Faska, Depository Trust, USA.
Change 29.167 MXG example reports using PDB.RMFINTRV only recognized
VGETWKLD workload names created with (now archaic) IMACWORK logic.
Aug 1, 2011 The VGETWKLD internal macro will parse the workload names
created by the (now-recommended) WORKnn= arguments that
should be used to define workload names in RMFINTRV.
Change 29.166 For DB2 Version 8.1, dataset DB2GBPST was mostly wrong as
VMACDB2 two 4-byte reserved fields (after QBGLXR and QBGLMR) were
Aug 1, 2011 not input, causing all subsequent variables to be wrong.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 29.165 -Variable POSIT was incorrectly zero, as only the first 8
VMACRACF bytes of the 10-byte POSITCH field were INPUT as numeric.
Jul 31, 2011 -Vars OTHRSPEC/OTHRSPE1 are renamed to FRSTSPEC/OTHRSPEC
and re-labeled.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Christopher Roberts, Euroclear, BELGIUM.
Change 29.164 Variables S17FBKNM S17SEXNM S17FMFNM are now kept in the
VMAC117 S117THRD dataset.
Jul 31, 2011
Thanks to Fabio Massimo Ottaviani, EPVTECH, ITALY.
Change 29.163 MXG 29.05, Change 29.129 for z/VM Crypto Record (5,10),
VMACVMXA from z/VM 5.4, if PRCAPMCT=6, because that subtype does
Jul 29, 2011 NOT have the undocumented 32 bytes found in 4 and 8, and
this was the first instance of that subtype. Since MXG
can so readily circumvent the IBM error (see 29.129), and
since this is an (ancient?) z/VM 5.4 record, fixing the
doc does not have (appropriately, IMO) high priority, as
this is a fairly obscure event - how many do use crypto
on z/VM systems, especially z/VM 5.4 systems.
Thanks to Tom Draeger, Aurora Health Care, USA.
Change 29.162 -Corrections/enhancements to TYPEIMST (IMS56FA TRANSACTs):
VMACIMS -STRTTIME and ARRVTIME were reversed in MXG logic.
Aug 2, 2011 -But, after fixing, ARRVTIME can be greater than STRTTIME:
- Case 1: WFI and PWFI, because the UOR Start Time begins
when the previous transaction completes, then the
program waits for the next message to appear, so the
STRTTIME=ARRVTIME is the wait time of the program.
- Case 2: Message Switch; the first transaction's
STRTTIME should be greater than the ARRVTIME unless
it is a WFI; see case 1, but the Message Switch
transaction afterward will have the UOR STRTTIME of
the first transaction, therefore the ARRVTIME of the
message will be greater than the STRTTIME.
In both cases, IF ARRVTIME GT STRTTIME then QUEUETM=0
and SERVICETM=RESPTM and STRTTIME=ARRVTIME to match IMF.
-Comparison of QUEUETM/INPQUETM between IMS56FA and IMS
has differences of up to 0.1 seconds, because ARRVTIME in
IMF has only to 0.1 second resolution while in IMS56FA it
has TODSTAMP resolution; this also caused similar small
differences between RESPTM/RESPNSTM variable's values.
-PROGTYPE in prior data was a one-byte text character, but
in IMS56FA it is a more robust bit map, so the data value
in the 56FA record is now input into PROGTYHX with $HEX2.
format, then PROGTYPE is constructed as a test character.
One-byte flag variables are created from PROGTYHX bits:
BMP='BMP?'
DBCTL='DBCTL?'
IFP='IFP?'
JAVA='JAVA?'
MODE='MODE*MULTI*OR*SINGLE?'
MPP='MPP?'
REMOTE='REMOTE?'
WFI='WFI?'
-These variables are now not kept in IMS56FA dataset:
TPCPTICH TPCPSOXN
and removed from the BY list for that dataset, as they
do not exist in that record.
-NMSGPROC=1 is set ONLY if CALLMSGU is GT 0 because 56FA
records are also written for a Message GU-CALL that did
not get a message from the IMS Message QUEUE; for MPPs
these show only a small CPU time, TPLTERM is blank, and
no calls are counted at all.
-TPLTERM was renamed LTERM in IMS56FA dataset.
-IMSVERSN is set to 10.1 instead of 10.10.
-Either SYSABEND or USRABEND, but not both, are populated;
COMPCODE='00000C4000'X correctly set SYSABEND='0C4';
but also incorrectly set USRABEND='U16E3' (i.e. 16,000+).
-If there are no GU calls to the message queue, then there
is no ARRVTIME, so neither QUEUETM nor RESPTM exist; they
are both set to missing values when CALLMSGU LE 0.
-IBM APAR PK773284 TPEXTIME IN X'56FA' TRANSACTION LEVEL
STATISTICS RECORD IS INVALID WHEN THE UNIT OF WORK ABENDS
exists to correct this intermittent problem:
TPEXTIME is IMSCPUTM in MXG IMS56FA dataset; values
'FFFFFFFBAFBA5708'x &'FFFFFFFCC4B4F0C8'x occurred in
two transactions with SYSABEND='0C4' (but the other
0C4's had zero values. MXG prints an error message
for the first five instances, and sets IMSCPUTM to a
missing value when an invalid CPU time value is found.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Change 29.161 MXG 29.03-MXG 29.05, dataset MQMCFMGR was wrong, with 64
VMAC115 identical outputs of only the first segment for each SMF
Jul 29, 2011 ID=115 record, if QESTSTR was non-blank in that segment,
so there were MANY more obs created than should have been
and many valid segments were not output.
Thanks to Paul Volpi, UHC, USA.
Change 29.160 VMXGFIND failed when dataset names created by SAS were
VMXGFIND 32-characters, because VMXGFIND added a prefix of text
Jul 28, 2011 "LIBNAME_" to that SAS-created dataset name. Now, if
only a single input LIBNAME is found, that prefix is
omitted and when there is more than one libname, if the
result exceeds 32 characters, only the first 32 are used.
Change 29.159 -Support for SAS Version 9.3 requires SAS Hot Fix SN43828.
FORMATS This error in SAS Portable Code, in compiling the %macro
Jul 26, 2011 %LET statement, and the %SYSRPUT and %SYSLPUT statements,
could impact SAS V9.3 on ALL platforms, although it was
only detected in MXG QA tests on z/OS, in the members
ANALCNCR and VMXGRMFI, both of which invoke %VMXGSUM.
The compiler error caused misalignment between the left
half (variable name) and the right half (value) of the
%LET statement.
-On ASCII, 32-bit and 64-bit SAS versions are different
operating systems, even on the same platform; so separate
"bit-specific" FORMAT directories are required, but the
same FORMATs can be used for V9.2 or V9.3 for the same
"bit" version. Member FORMATS errored when I tried to run
it under 32-bit V9.3, writing to a V9.2 64-bit directory.
-On both ASCII and z/OS, SAS Data Libraries can be read or
written by either V9.2 or by V9.3, and on ASCII, under
either 32-bit or 64-bit environments.
Change 29.158 NDM-Connect Direct CT Version 5 record has 4 new fields.
VMACNDM There is no version value in the record, but there is a
Jul 26, 2011 new offset to 2 of the 4 new fields, so that offset is
used to conditionally assume all four are present.
NDMJOBID='JCTJOBID'
NDMJOBNM='JCTJBNAM'
NDMRIP6 ='IPV6*ADDRESS'
NDMTYPFK='TYPE*FILE*KEY'
Thanks to Eric R. Carlson, Kroger, USA.
Change 29.157 MXG 29.06 QA tests clean ups:
VMAC7072 -VMAC7072: These variables removed from DROP statement
Jul 24, 2011 LCPUDEXD-LCPUDEXZ LCPUDEVA-LCPUDEUI
LCPUWAXD-LCPUWAXZ LCPUWAVA-LCPUWAUI
because they never existed; QA test enabled DKROCOND=WARN
which caused spurious warning messages.
Change 29.156 IDMS/R Performance Monitor for Version 18 adds variables:
VMACIDMS -Dataset IDMSTAS:
Jul 24, 2011 TASCPTI ='SRB*TIME*ON*CP'
TASENTI ='ENCLAVE*SRB*CPU*TIME'
TASSYTI ='CPU*TIME*ON*CP'
TASTITI ='TCP*CPU*TIME'
TASUSTI ='USER*MODE*CPU*TIME'
TASZPTI ='SRB*TIME*ON*ZIP'
Initial observations were that
TASSYTI (.920) = TASTITI (.777) + TASENTI (.143)
CPU = TCB ENCL SRB
TASCPTI (.016)
TASZPTI (.127)
TASENTI (.0007)
-Added to all datasets, and inserted into the header, so
it caused INVALID DATA FOR PMHSDATE messages:
SMFHJOB ='PM*JOB*NAME'
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.155 CICS/TS 4.2 Statistics variables now input:
VMAC110 Dataset CICISR:
Jul 24, 2011 ISRTDBYR='IPCONN*PS*TD*REQS*BYTES*RECEIVED'
ISRTDBYS='IPCONN*PS*TD*REQS*BYTES*SENT'
ISRTDREQ='IPCONN*PS*TRANSIENT*DATA*REQUESTS'
ISRTSBYR='IPCONN*PS*TS*REQS*BYTES*RECEIVED'
ISRTSBYS='IPCONN*PS*TS*REQS*BYTES*SENT'
ISRTSREQ='IPCONN*PS*TEMP*STORAGE*REQUESTS'
ISRUNSUP='ISR*UNSUPPORTED*REQUESTS'
Dataset CICWBR:
WBRATOMS='URIMAP*ATOMSERVICE*NAME'
WBRAUTHE='URIMAP*AUTHENTICATE*USE'
WBRREDIR='URIMAP*REDIRECTION*TYPE*USE'
WBRSOCPK='URIMAP*SOCPOOL*PEAK*IN*POOL'
WBRSOCRC='URIMAP*SOCKETS*RECLAIMED*FROM POOL'
WBRSOCTO='URIMAP*SOCKETS*TIMEDOUT*WHILE INPOOL'
WBRSOCTV='URIMAP*SOCLOSE*TIMEOUT*VALUE'
WBRSOCUR='URIMAP*SOCPOOL*CURRENT*IN*POOL'
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.154 Circumventions for a macro errors ONLY in archaic SAS V8,
VMXGSUM that were also perfectly cloned into WPS V8 architecture.
Jul 24, 2011 While SAS V8 is no longer supported by SAS Institute and
while MXG officially does not always work under V8, these
errors encountered in VMXGSUM from VMXGRMFI in BUILDPD3
with both SAS V8 and WPS were circumvented in MXG, and
could be useful in avoiding AUTOCALL issues in SAS V9s:
-%IF %LENGTH(&A &B) GT 0 THEN %DO incorrectly returned 1
when &A and &B were both null with V8/WPS but returned 0
with all SAS V9s. The error was circumvented by replacing
the test string of multiple macro variables with single
ORed tests of each macro variable, to avoid the exposure.
-The SAS provided-in-SASMACRO-library AUTOCALLed %macro
functions %CMPRES/%QCMPRES (which call %QLEFT, %VERIFY,
%QTRIM, %LEFT, %QLEFT, %VERIFY and %TRIM) were removed
from VMXGSUM, as they were never actually needed, and
their removal circumvented V8 and WPS macro errors.
I had thought they were needed to compress blanks from
the %macro arguments, which are limited to 65584 bytes,
and long ago longer argument errors had occurred, but
that error occurs when the %macro is invoked, prior
to these functions execution. Hindsight is beautiful.
Thanks to Scotie Mills, TI, USA.
Change 29.153 UNDECODED CTGRECID and CPU loop caused by Change 29.001,
VMAC111 which incorrectly calculated the SKIP value of bytes to
Jul 19, 2011 be skipped in the SMF ID=111, CTGRECID=7 record.
Thanks to Victoria Lepak, Aetna, USA.
Change 29.152 VMSYSTEM='Y' (Change 29.127) support was revised when RMF
VMAC7072 70 records were read. A divide by zero (creating TYPE70
Jul 19, 2011 from WORK.SORT70SP, because ONTM(LCPUADDR+1) was zero,
because the VMSYSTEM='Y' records do NOT populate the
"on time" in SMF70ONT (which populates ONTM array, and I
believe this is a defect that IBM needs to correct, and
a PMR has been opened to address this and other issues).
However, knowing SMF70ONT is NOT populated, MXG code was
revised and SMF70ONT=DURATM when VMSYSTEM='Y', which then
corrected calculations of PCTCPUBY for these new records,
and logic was revised to correctly capture the actual
LPARNAME of the z/OS system that was running under z/VM.
====== Changes thru 29.151 were in MXG 29.05 dated Jul 11, 2011========
Change 29.151 Support for RCD record in ASMRMFV is completed in time to
ASMRMFV be included in MXG 29.05, but I procrastinated and did
Jul 10, 2011 not complete the updates in VMACRMFV to actually process
and create the new variables. You can safely install the
new ASMRMFV program to create the RMFBSAM file with RCD
data, so that it could be examined when the VMACRMFV has
been updated. Contact support@mxg.com if you want the
updated VMACRMFV when it's ready. This change will be
revised when RCD support is completed.
Jan 18, 2012: MXG 29.29 DATED JAN 18, 2012 IS REQUIRED
TO PROCESS RCD RECORDS. YOU MUST USE THE NEW ASMRMFV
AND THE UPDATED VMACRMFV TO READ RCD DATA.
Change 29.150 New ONLYJOBS program creates 'only' the PDB.JOBS dataset
ONLYJOBS (but also creates PDB.STEPS, PDB.PRINT, which are needed
Jul 9, 2011 to create PDB.JOBS, and creates PDB.SMFINTRV, which may
be useful for long running jobs, from SMF 6/30/26, with
selection for only some JOB names in the example.
Thanks to Jerry Ellis, Liberty Mutual, USA.
Change 29.149 CICS/TS 4.2 (SMFPSRVN=67), INVALID VALUE FOR PHTRANNO,
VMAC110 in MNSEGCL=5 record; eight bytes were inserted by 4.2.
Jul 7, 2011 See Change 29.135, which added Support for CICSTRAN and
CICS Statistics records (which was in MXG 29.03 but was
not announced). This change is required for CICS/TS 4.2
if your site creates MNSEGCL=5 (dataset CICSRDS) records,
but luckily it only causes messages and hex record dumps;
it does NOT cause an ABEND.
Thanks to Tom Buie, Southern California Edison, USA.
Change 29.148 DATEFMT= parameter added to both BLDSMPDB and VMXGALOC to
BLDSMPDB control the format of the date in the directories created
VMXGALOC by VMXGLOC. The default of DATE7 does not allow you to
Jul 7, 2011 sort the directories into an order that puts the
directories in calendar order. The only formats that
would do that are JULIAN and YYMMDD but the code will
accept: DATE MMDDYY DDMMYY YYMMDD and JULIAN with
whatever length you specify. If you use one of the
MMDDYY etc formats and you specify MMDDYY8. you will get
07-05-11 but if you use MMDDYYN8. you will get 07052011.
Change 29.147 Change 29.032 revised dataset PDB.IPLS to only report a
VMAC0 true SYSTEM IPL, but the IPLTIME from SMF 90 is on GMT,
Jul 5, 2011 so this change uses the SMFTIME of the SMF 90 record for
IPLTIME so it is always on the Local time zone.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 29.146 Support for RCD record.
ASMRMFV
Jul 5, 2011
Change 29.145 Revisions (again!) to enhance DB2 processing, especially
ANALDB2R with large volumes of DB2 SMF data.
ASUMDB2A -Macro variable DB2RSELA added in VMXGINIT.
ASUMDB2B -New parameters in ANALDB2R:
ASUMDB2G BUFFDETL=NO - suppresses reading the DB2ACCTB/DB2ACCTG
ASUMDB2P JOB= - select only records with JOB=xxxxxxx
TRNDDB2A -Values for Class 3 Suspension in ANALDB2R reports were
TRNDDB2B corrected. Values for Global Contention are still being
TRNDDB2G reviewed.
TRNDDB2P -If selection criteria are specified in ANALDB2R:
VMXGINIT With PDB=SMF they are passed to READDB2
Jul 5, 2011 With PDB=PDB they are passed to ASUMDB2x members in the
READDB2 DB2RSELA macro variable so that only records that meet
the criteria are summarized.
Performance improvement in ANALDB2R:
IF PMACC01=YES and PMACC02 NE YES
Suppresses buffer data and ASUMs of buffer data
If DB2ACCTP has 0 OBS suppress ASUMDB2P
-New parameter in READDB2
JOB= - select only records with JOB=xxxxxxx
-Some changes in ASUMDB2x/TRNDDB2x members are cosmetic to
eliminate UNINIT messages; others are to pick up the time
ranges of the records for heading and sorting and adding
of a thread count for calculating averages. KEEPALL=YES
reinstated in ASUMDB2P,ASUMDB2G,ASUMDB2B, and ASUMDB2A so
that ANALDB2R can be used with user-tailored ASUMDB2x
datasets (i.e., with dropped variables) without messages
about UNINIT variables.
-In TRNDxxxx, variable THREADs added to SUM list so that
ANALDB2R could be executed against Trend datasets.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Change 29.144 -IBM IMS Log 56FAx records ARE INDIVIDUAL TRANSACTIONS!
IMACIMST Finally, you can track individual IMS transaction CPU and
TYPEIMST Response times, without using the MXG circumventions
VMACIMS (JCLIMSL6/ASMIMSL6/TYPEIMSA/TYPEIMSB, or IMS0708 data),
Jul 2, 2011 and without ANY sorting/merging/etc. And, the IMF56FA
dataset contains the ARRVTIME of the transaction, which
is NOT contained in IMS0708 dataset, although it is
contained in the IMSTRAN from JCLIMSL6.
-The TYPEIMST member builds only the IMS56FA.IMS56FA
dataset.
-MOST variable names are changed from the prior IMS56FA
dataset, so its variables are now identical to those in
the "circumvention" datasets IMS0708/IMSTRAN so that your
existing reports should work without error or with minor
revisions.
-Most of the DLRxxxxx variables in dataset IMS0708 do not
exist in the IMS56FA dataset, and variables DTOKEN
IMSACCQ6 IMSSQ6TM LINTPSB LINEPGM LINTSY2 LINTSUM are
also missing/blank in IMS56FA, but all of the really
important variables are present.
-References to IMS Version 11.0 were corrected to 11.1.
-References to IMS Version 10.0 were corrected to 10.1.
-Numerous duration variables in the LCODE=45x statistics
records are now correctly divided by 4096.
Thanks to Raymond J. Smith, UHC, USA.
Change 29.143 Extremely strange: INVALID ARGUMENT FOR MOD function and
VMACEXC1 ERROR.VMACEXC2.2 INVALID DEVCLASS/DEVTYPE IN 30 DD, but
Jul 1, 2011 the DEVCLASS and ARGUMENT were both valid, and this was
deep in the middle of a BUILDDB run. Fortunately, the
search for the INVALID ARGUMENT message found this note:
SAS Problem Note 13269: Various numeric functions may
return incorrect results.
The result returned by some numeric functions may be
incorrect. This problem can occur if the result of
the function is assigned to a variable that is also
used as an argument to the function. The functions
affected are:
BETA, COALESCE, COMB, CONVX, CONVXP, DATDIF, DUR,
DURP, GEOMEAN, GEOMEANZ, HARMEAN, HARMEANZ, IQR,
LARGEST, LOGBETA, MAD, MEDIAN, MOD, ORDINAL, PCTL1,
PCTL2, PCTL3, PCTL4, PCTL5, PERM, PROBDF, PVP,
RXMATCH, SMALLEST, YRDIF and YIELDP.
The function may also incorrectly return a missing
value and issue a NOTE to the SAS log reporting that
one of the arguments to the function is invalid.
The SAS Note states:
THIS PROBLEM IS FIXED IN SAS 9.1.3 SERVICE PACK 2
AND SAS 9.2.
BUT THE ERROR WAS UNDER SAS V9.1.3 WITH SP 4!!!
However, the text in the SAS Note and the MOD statement
identified in the error message agreed; the same named
variable was the input and the output
BLKSIZE=MOD(BLKSIZE,32768);
so the code now uses a different variable name, and the
error was eliminated!!!
Thanks to Jean-Denis Lacourse, CGI, CANADA.
Change 29.142 -Additional bits in SMF 90 Subtype 30 are now decoded:
VMAC90A SMF9030C='ENCLAVE*SERVICE*CLASS*RESET'
Jul 1, 2011 SMF9030D='ENCLAVE*QUIESCED'
SMF9030E='ENCLAVE*RESUMED'
SMF9030H='ORIGINAL*INDEPENDENT*ENCLAVE'
SMF9030K='ENCLAVE*OWNER'
-Variable PRODUCT is added to all TYPE90nn datasets.
Thanks to Siegfried Trantes, Gothaer-Systems, GERMANY.
Thanks to Willi Weinberger, Gothaer-Systems, GERMANY.
Thanks to Sabine Richard, Gothaer-Systems, GERMANY.
Change 29.141 Skipped Change Number.
Change 29.140 Some DB2 Trace Records IFCID 6/7 have QWHSSTCK events
VMACDB2 before the QWACBSC start time in their DB2ACCT and
VMACDB2H DB2ACCP observations. IBM DB2 support answer:
Jun 29, 2011 "The logic in DB2 does full thread allocation and then
clocks the begin time for the transaction. If an I/O
is required during allocation, you may see a 6/7 pair
outside the transaction bounds. So in the end, this
appears to be working without error."
But the time value in QWHSLUUV in these transaction DOES
precede the first IFCID 6, showing that the actual start
time WAS captured when the LUUV was created, and that
the LUUV creation event should be used for QWACBSC time.
That suggestion is under discussion with IBM.
While waiting, new variable LUUVTIME is created in both
DB2ACCT and DB2ACCTP to be used in place of QWACBSC when
analyzing DB2 trace records. For QWHCATYP=8 REMOTE UOW
transactions, LUUV is not a valid time value, but for
those records, LUUVTIME is set equal to QWACBSC so that
all observations have a usable LUUVTIME for match up
with other records.
Note that for DB2PARTY='R' or ='P' (Rollup, Parallel),
LUUVTIME can be MUCH earlier than QWACBSC, because in
those records QWACBSC NOT the transaction start time, as
is documented in Change 29.131.
Note also that variable ACE rather than QWHSACE should
be used to match up transactions; for DB2PARTY='P' obs,
ACE is set to QWACPACE, which is constant for all of
the records for that transaction (while QWHSACE in the
parallel records is not consistent).
Change 29.139 RACF variables RES25TEA-RES25TEF, RES25MEA-RES25MEF in
VMAC80A dataset TYPE8020 and CLASNAME-CLASNAM5 in TYPE8024 from
Jun 29, 2011 DTP=43 segments were wrong because the segment count
variables NR25SEGS and NR43SEGS were never reset to 0
for a new record.
Thanks to Lars Fleischer, SMT Data, DENMARK.
Change 29.138 If you use a LIBNAME statement to allocate a tape SAS
zOS Only data library and VGETENG is invoked before any datasets
Jun 25, 2011 are written to the tape, you may get a 413-18 error from
zOS indicating a failure to correctly open the dataset.
Your job will still get a CC=0 so it is not a serious
error, but it is an annoying warning message.
LIBNAME TEST V9SEQ;
%VGETENG(DDNAME=PDB);
Will cause:
ERROR: OPEN FAILED. ABEND CODE 413. RETURN CODE 18.
This can be suppressed by writing a 0 OBS 0 VARS dataset
to the tape immediately after the LIBNAME, using
LIBNAME TEST V9SEQ;
DATA TEST.A;RUN;
%VGETENG(DDNAME=PDB);
to suppress the message (although it will also put a
very small additional dataset on the tape).
Change 29.137 UTILARCH - Archival of SAS datasets from a data library,
UTILARCH similar to the way OUTLOOK archives its EMAIL store.
Jun 25, 2011 All observations for chosen datasets dated earlier than
the chosen archive date are written to the archive data
library (which could be new, or archived observations
can be appended to an existing archived dataset), and
the observations that were archived are then removed
from the original input dataset (which can be rewritten
or could be written to a new "unarchived" data library).
You can specify:
INDD= LIBNAME of the input data library.
OUTDD= LIBNAME of the output un-archived, reduced
dataset. If OUTDD is NOT specified, the
unarchived observations replace the dataset
in the INDD library. OUTDD is required if
INDD is on TAPE or DASD sequential format.
INARCHIVE= LIBNAME of the current archive data library.
If the dataset(s) selected exist in OUTDD,
newly archived observations are APPENDed.
ARCHIVE= The new archive data library. This could
be the same as INARCHIVE, as long as they
are not tape nor sequential format on DASD.
DATEVAR= The name of the date variable to be tested.
KEEPDAYS= The number of days of detail data to keep
unarchived. Obs more days old are archived.
KEEPDATE= The date literal (01JAN2011) to keep; obs
earlier than this date are archived.
Either KEEPDAYS or KEEPDATE but not both
must be specified.
ARCHDAYS= The number of days of data to keep in the
archive. If not specified, the archive
will continue to grow in size.
ARCHDATE= The date literal (01JAN2010) of the oldest
date to be kept in the archive.
Either ARCHDAYS or ARCHDATE or NEITHER, but
not both, must be specified.
DATASETS= one or more SAS datasets to be archived
If the datevar is gt TODAY()-KEEPDAYS, the OBS is
written back to the detail. If it is lt that value
but GT today()-sum(keepdays,archdays) it is written
to the archive (if archdays is specified - if it is
not specified the archive grows to infinity.)
Thanks to Brian A. Harvey, HCL America, USA.
Change 29.136 Support for WebSphere WAS 8.0 (COMPATIBLE). These new
VMAC120 variables are added to dataset TYP1209E:
Jun 25, 2011 SM1209FK='CLASSIFICATION*ONLY*TRACE?'
Jul 17, 2011 SM1209FM='SMF*REQUEST*ACTIVITY*ENABLED?'
SM1209FN='SMF*REQUEST*ACTIVITY*TIMESTAMP?'
SM1209FO='SMF*REQUEST*ACTIVITY*SECURITY?'
SM1209FP='SMF*REQUEST*ACTIVITY*CPU DETAIL?'
SM1209FQ='PROPAGATE*TRANSACTION*NAME?'
SM1209FR='STALLED*THREAD*DUMP*ACTION'
SM1209FS='CPUTIMEUSED*DUMP*ACTION'
SM1209FT='DPM*DUMP*ACTIO'
SM1209FU='TIMEOUT*RECOVERY'
SM1209FV='DISPATCH*TIMEOUT*VALUE'
SM1209FW='QUEUE*TIMEOUT*VALUE'
SM1209FX='REQUEST*TIMEOUT*VALUE'
SM1209FY='CPUTIMEUSED*LIMIT*VALUE'
SM1209FZ='DPM*INTERVAL*VALUE'
SM1209GA='MESSAGE*TAG*VALUE'
SM1209GF='CPU*USAGE*OVERFLOW?'
SM1209GG='CEEGMTO*UNAVAILABLE?'
SM1209GH='LENGTH*OBTAINED*AFFINITY*RNAME'
SM1209GI='OBTAINED*AFFINITY*RNAME'
SM1209GJ='LENGTH*ROUTING*AFFINITY*RNAME'
SM1209GK='ROUTING*AFFINITY*RNAME'
-Variable SM1209CE is expanded to 16 bytes.
-Variables SM1209DX and SM1209DZ are deprecated; they are
still set, but use SM1209GF and SM1209GG because DX/DZ
may not exist, since the z/OS Request Info Section
(and the Platform Neutral Request Info Section) might not
be present if this is Async Work.
-New values added to format MG1209T for SM1209CK and to
format MG1209C for SM1209EM.
-Jul 17: Updated VMAC120 was moved into SOURCLIB. This
Change was NOT included in MXG 29.05 dated Jul 11, 2011.
Thanks to David Follis, IBM, USA.
Change 29.135 Support for CICS/TS 4.2 was available in MXG 29.03 but
VMAC110 not announced until today when it became GA. See Change
Jun 24, 2011 29.063 for details.
Change 29.134 Support for Informatica's POWER EXCHANGE SMF record adds
EXPOEXCL five new datasets:
EXPOEXDB
EXPOEXEX DDDDDD MXG MXG
EXPOEXFI DATASET DATASET DATASET
EXPOEXLI SUFFIX NAME LABEL
FORMATS
IMACPOEX POEXLI POEXLIST POWER EXCHANGE LISTENER
TYPEPOEX POEXEX POEXEXPT POWER EXCHANGE EXCEPTION
TYPSPOEX POEXFI POEXFILE POWER EXCHANGE FILE ACCESS
VMACPOEX POEXDB POEXDB2 POWER EXCHANGE DB2
VMXGINIT POEXCL POEXCLIE POWER EXCHANGE CLIENT
Jun 24, 2011 Only POEXLIST and POEXCLIE datasets have been validated
with data records, and these problems have been reported
to the vendor's support team:
a. The STCK fields are in GMT but there is no GMT Offset;
it is possible to use Fuzzy Logic to compare END time
when it is populated (see below) to calculate a GMT
Offset, but well-written SMF records always contain
the GMT Offset that is in effect when the event
records are created, when they contain time/date-times
on the GMT clock.
b. The records contain Subtypes but BIT 1 in SMFxFLG is
not set; the SMF Manual Table 13-2 documents that bit
that should be set for records containing Subtype.
c. The Reserved Field at offset 290 in the General
section is only 28 bytes, but was documented as 32
bytes.
d. For the Client Records:
1. In the General section, the Character START/END are
LOCAL zone, but they are identical to each other
and are the same as SMF time (except that SMFTIME
has higher resolution). The STCK START/END are GMT
zone, and are also identical to each other.
2. In the Extended section, the STCK START/END times
are not populated.
3. The Reserved Field in the General Section contains
an IP address in character format.
4. The Client IP Address is not populated.
5. The Client User ID contains hex rather than EBCDIC
text; I don't know if that is correct or not, but
if it contains HEX it needs to be documented.
e. For the Listener Records:
1. The START fields are many days/hours prior to the
SMF TIME, and are constant for each JOB. The CHAR
field is Local Time Zone, the STCK field is GMT
Time Zone.
2. The SMF times are at 5 minute intervals, but are
not synchronized with TIME OF DAY, as all interval
records should be.
3. The END TIME fields (both CHAR and STCK) are not
populated, so it is NOT possible to use Fuzzy Logic
to reset the Start Time to the local clock.
Thanks to Bobbie Justice, Kohl's, USA.
Change 29.133 -Variables LPARNAME and LPNUMBER are added and are kept in
ASUMVMXA PDB.VMXAINTV and PDB.ASUMVMXA. But the LPNUMBER in z/VM
VMACVMXA data is NOT the "LPARNUM" variable in TYPE70PR from RMF.
Jul 5, 2011 In TYPE70PR, variable LPARNUM is a z/OS assigned sequence
number that has no connection with the actual Partition
number of each LPAR, which is precisely what is stored by
MONWRITE in its LPNUMBER variable. In TYPE70PR, there is
a variable PARTISHN, but that is the actual Partition
that wrote that SMF 70 record, and since the IFL LPARs do
not write SMF records, there is no possible way to match
the z/VM MONWRITE LPNUMBER to the IFL LPAR data.
However, merging the TYPE70PR IFL observations with the
MONWRITE data does not need the LPNUMBER/LPARNUM; the
data can be merged by matching the LPARNAME and ENDTIME.
Jul 26: See MXG Newsletter FIFTY-EIGHT VM Technical Notes
for comparison of synchronized MONWRITE and RMF data.
And, only SHARED IFLs have actual utilization; DEDICATED
IFLs always report 100% utilization in TYPE70PR/ASUM70PR.
Change 29.132 -When sending the output to HTML, PROC GCHART creates
GRAFCEC files with the name GCHART GCHART1 GCHART2 etc. If you
GRAFWRKX send the output of both routines to the same place, the
UTILWORK second one overwrites the output of the first. Added a
Jun 22, 2011 NAME= to all the GCHARTS so the charts created by
Jul 5, 2011 GRAFWRKX will be GRFWRK GRFWRK1 etc and the ones from
GRAFCEC will be GRFCEC GRFCEC1 etc.
-If COMPAT=YES was incorrectly specified (COMPAT went away
years ago), UTILWORK generated an RMFINTRV member with
USEREPRT and USECNTRL set to COMPAT=YES, causing VMXGRMFI
to look for performance groups. Now, COMPAT=GOAL is set.
-If run on ASCII in the background, your session will stop
to display every graph being produced - a real pain in
the butt. This can be suppressed using the GOPTIONS
NODISPLAY; option and a graphics catalog will still be
created. So you may want something like:
GOPTIONS NODISPLAY;
PROC GCHART GOUT=MYGRAPHS DATA=whatever;
VBAR whatever;
Run;
GOPTIONS DISPLAY;
FILENAME HTML 'C:\MXG\';
ODS HTML PATH=HTML BODY='BODY.HTML' FRAME='FRAME.HTML'
CONTENTS='CONTENTS.HTML';
PROC GREPLAY IGOUT=MYGRAPHS NOFS;REPLAY _ALL_;
RUN;
ODS HTML CLOSE:
RUN;
The graphs will be constructed and HTML put in C:\MXG\.
Clicking on FRAME.HTML will display the graphs after the
background task is complete.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.131 When DB2 ROLLUP is specified, DB2ACCT and DB2ACCTP will
VMACDB2 have two observations, the Originating and the Rollup,
Jun 21, 2011 but only DB2ACCT created DB2PARTY to identify which.
This changes creates DB2PARTY in DB2ACCTP dataset.
In DB2ACCT, with Parallelized DB2 and ROLLUP specified:
-In the DB2PARTY='O' observation, QWACBSC/QWACESC are the
start and end times, but in DB2PARTY='R' record, both
BSC and ESC are set to the END time of the transaction.
In DB2ACCTP, with Parallelized DB2 and ROLLUP specified:
-In the DB2PARTY='O' observation, QPACSCB/QPACSCE both
are missing values, and in DB2PARTY='R' record, both
are set to the END time of the transaction.
-Parallelization is only recognizable because the value
in QPACSCT (and in QPACZITM if zIIPs exist) are much
larger than the ELAPSTM in the DB2ACCT 'O' observation.
In both DB2ACCT and DB2ACCTP, population of variables is
inconsistent between the 'O' and 'R' record; in ACCTP the
QPACPKID is blank in the 'O' but populated in the 'R',
while most other QPACxxxx variables have values in both.
In ACCT, the QBnxxxx and QXxxxxx variables are missing in
the 'R', but most other variables are populated in both.
Thanks to Glen Bowman, Wakefern, USA.
Change 29.130 -Cosmetic - if you were running with AUTOALOC=YES, a SAS
BLDSMPDB warning was generated when a PROC COPY was used to copy
Jun 21, 2011 the contents of PDB to the day of the week. That is now
suppressed unless AUTOALOC=NO.
-New parameter AUTOTRND= added to allow you to add or
subtract the TRNDxxxx members that are invoked when
trending is being done. Default TRNDxxxx members are:
TRNDCEC TRNDCELP TRNDCICX TRNDDB2A TRNDDB2P TRNDDBSS
TRNDRMFI TRND72GO TRNDTMNT TRNDTALO
Change 29.129 z/VM 5.4 Crypto Record (5.10) with PRCAPMCT=8 printed
VMACVMXA ***MXGERROR DM 5 RC 10 UNDECODED PRCAPMCT=8 WAS SKIPPED
Jun 15, 2011 *ERROR* PROBABLE DATA LOSS DUE TO MONWRITE FAILURE.
and subsequent misalignment, due to 32 undocumented bytes
for that crypto subtype. Investigating further.
IBM has confirmed the documentation of this record is in
error; the MXG code and this change will be updated when
the IBM correction is available.
Thanks to Victoria Lepak, Aetna, USA.
Change 29.128 NOTE: DB2 INVALID DISTRIBUTED HEADER DELETED message if
VMACDB2H QWHDSVNM length (QWHDLOSL) was greater than 16 bytes even
Jun 15, 2011 after Change 29.036 due to error calculating LENLEFT.
Thanks to Lorena Ortenzi, UniCredit Group, ITALY.
Thanks to Paolo Uguccioni, UniCredit Group, ITALY.
Change 29.127 Support for z/OS 1.12 VMGUEST option to add CPU time to
VMAC7072 the RMF 70 records for z/OS systems running under z/VM.
Jun 14, 2011 New variable VMGUEST='Y' is added to PDB.TYPE70PR dataset
if this z/OS is run under z/VM with the VMGUEST option
specified in Monitor I options (in your ERBRMFxx member).
Two observations in PDB.TYPE70PR exist with the option;
one with LPARNAME='PHYSICAL' that contains the Dispatch
CPU Time of z/VM itself for this z/OS system, and one
with the LPARNAME='VMSystem' for the z/OS CPU TIME.
In the RMF Reports:
The header of the Partition Data section provides data
about the z/VM partition running the z/OS guest, with
'VMSystem' reported as the MVS PARTITION NAME field.
The IMAGE CAPACITY field displays the CPU capacity
available to the z/VM partition; NUMBER OF VMSystem
PROCESSORS presents the number of processors that are
assigned to the z/VM partition. All other header fields
in the RMF report will be N/A. The partition data
reports data of the z/OS system running as z/VM guest.
The CPU time used by z/VM itself is reported as
partition name '*VMSystem*'. In the reported partition
data, the physical processor utilization represents the
logical processor utilization of the z/VM partition.
Change 29.126 Data set VXSYTEP2 variables kept that were not input:
VMACXAM SYTEP1FL ECMCPBT ECMCPBTB
Jun 13, 2011 and variables input that were not kept:
Jun 15, 2011 SYTEP2FL $CHAR1. /*SYTEP1*FLAGS*/
CSCCMCMB &RB.4. /*MAXIMUM*INTERNAL*BUS*CYCLES*PERSEC*/
CSCCMCMC &RB.4. /*MAXIMUM*CHANNEL*WORK*UNITS*PERSEC*/
CSCCMCMM &RB.4. /*MAXIMUM*WRITES*PERSEC*/
CSCCMCMR &RB.4. /*MAXIMUM*READS*PERSEC*/
CSCCMCMU &RB.4. /*BYTES*PER*DATA*UNIT*/
ECMBCBCC &RB.4. /*BUSY*CYCLES*USED FOR*I/O*/
ECMCCWUC &RB.4. /*CHPATH*DATA*UNITS*TOTAL*/
ECMCCWU &RB.4. /*CHPATH*DATA*UNITS*LPAR*/
ECMCDWUC &RB.4. /*CHPATH*WRITE*DATA*UNITS*TOTAL*/
ECMCDWU &RB.4. /*CHPATH*WRITE*DATA*UNITS*LPAR*/
ECMCDURC &RB.4. /*CHPATH*READ*DATA*UNITS*TOTAL*/
ECMCDUR &RB.4. /*CHPATH*READ*DATA*UNITS*LPAR*/
SYTEP2FL is now kept in place of SYTEP1FL, ECMCPBT/B are
no longer kept and the other twelve are now kept.
Jun 15: All references to WORKUNITS and WORK*UNITS in the
variable labels was changed to DATA*UNITS; while Barton
documented them as WORKUNITS in the PL/1 descriptors that
are the only XAM documentation, apparently later in the
Velocity reports/documentation they are now called DATA
UNITS so I've changed the labels as requested.
Thanks to Patricia Hansen, ADP, USA.
Change 29.125 DB2 SMF 102 IFCID 22 INPUT STATEMENT EXCEEDED if length
VMAC102 of QW0022AN,'ACCESS INDEX NAME' was greater than 18, due
Jun 10, 2011 to error in MXG logic in handling truncated name fields.
Also, for DB2 V10, QW0022PA was incorrectly read as PIB2
which caused the new CY/NP/F2/TT variables to be wrong.
Thanks to Joe Babcock, Bank of America, USA.
Change 29.124 Variables CTGIAREQ and CTGLALRQ were incorrectly kept in
VMAC111 dataset TY111CXI, but those fields do not exist in the
May 28, 2011 subtype 07 record, so they have been removed from that
dataset's KEEP list. They do exist in subtypes 01/02/03
so they were sometimes populated and sometimes missing in
TY111CXI dataset, depending on the order of subtypes in
the SMF record. These three different subtype sequences
have been observed in SMF 111 records, for no apparent
reason, but as each subtype is independent, with this
MXG correction, there is no impact on different orders:
00 01 05 04 06 07 03
07 00 01 05 04 06 03
00 07 01 05 04 06 03
Thanks to Gordon E. Griffith, Edward Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Change 29.123 Support for TMON/IMS Version 3.0 (INCOMPATIBLE). New
EXTIMCM1 variables added to TIMSCM, TIMSCP, and TIMSCT datasets.
EXTIMCM2 Six new datasets, one for each of the three segments in
EXTIMCM3 the CM and CP records are created. The datasets TIMSCM,
EXTIMCP1 TIMSCM1, TIMSCM2, TIMSCM3, TIMSCO, TIMSCP, TIMSCP1,
EXTIMCP2 TIMSCP2, TIMSCP3, and TIMSCT were validated with data;
EXTIMCP3 no other subtypes were examined for changes.
IMACTIMS
VMACTIMS
VMXGINIT
May 28, 2011
Thanks to Santosh Kandi, J.C. Penney, USA.
Change 29.122 Lengths of variables CUVENDOR $3 and CUSERIAL $12 are now
VMAC74 set in a length statement. Because they were created by
May 27, 2011 a SUBSTR function, their default length was set from the
length of the input variable, which was $28.
Change 25.155 noted that the SUBSTR function sets length
from the input variable, while SCAN and other functions
default to $200. The length for these SUBSTR could be
set at compile time, because the third argument is fixed,
but it isn't, so the LENGTH statement sets the length.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Change 29.121 MXG 28.28-29.04. DB2 Data Sharing Variables QWHADSGN and
VMACDB2H QWHAMAMN were blank if there was a Distributed Header for
May 27, 2011 DB2ACCT or DB2ACCTP datasets. All DDF records have a
QWHSTYP=16 segment, but they can exist in other records.
Thanks to Paul Volpi, UHC, USA.
Change 29.120 Updates discovered during ITRM Dictionary Build:
ASUMVMXA -VMACTPMX. By list _BTMP10 variable TPMCMLNN (MSU) should
VMAC82 have been TPMCMLNM (LPAR NAME).
VMACTPMX -VMAC82. Labels 21th/22th/23th/31th/32th/33th corrected.
VMACVMXA -VMACVMXA
VMXGINIT Macro _SUSELOF had disappeared from the _DELTALL macro,
May 26, 2011 now reinstated.
Jun 22, 2011 Variable SCKRZWCT was a typo and does not exist.
Nov 17, 2011 Variables NBAD113 and RESETCTR are DROPped.
Variable CURALLOC does not exist and reference removed.
Variable PLXCPUCN was a typo and does not exist.
Variable VL3CAF label is now CAPABILITY vs CAPACILITY.
Nov 27, 2011: These updates were not made until today:
-ASUMVMXA. Macro variable PSUVMXA now defined in VMXGINIT
rather than in ASUMVMXA, and existing macro _LVMAINT is
for the location of VMXAINTV and the old _LTYVMXA token
is removed.
Thanks to Chris Weston, ITRM Development, USA.
Change 29.119 -The below segment of an INPUT statement was accidentally
QASAS left in the middle of a LABEL statement:
VMACQACS DSSRLN ='DISK*UNIT*SERIAL*NUMBER'
May 23, 2011 DSPTROP &PIB.8. /*TOTAL*PATH*READ*OPERATIONS*/
Jul 6, 2011 DSPTWOO &PIB.8. /*TOTAL*PATH*WRITE*OPERATIONS*/
DSWWWNN $CHAR8. /*WORLD*WIDE*NODE*NAME*/
DSSRVT ='DISK*SERVICE*TIME'
but it did NOT generate a compiler error, because the SAS
delimiter for label text is the equal sign. It did cause
variables DSPTROP DSPTWOO & DSWWWNN to have blank labels,
and it created a very long label for variable DSSRLN that
SHOULD have been detected in the QA LONG LABEL tests, but
wasn't, because the QASAS still had the archaic TYPEQAPM
executed AFTER the current TYPEQACS, so the old QAPMDISK
(with only 74 variables and none of the above new ones)
overwrote the new (103 variables) QAPMDISK dataset in QA.
-Removing the ancient TYPEQAPM member from the QA stream
caused these datasets to no longer be created/documented
in the DOCVER member (but this is only cosmetic); those
datasets have not been actually available in years).
QAPMASYN QAPMBSC QAPMDDI QAPMECL QAPMFRLY QAPMIDLC
QAPMJOBS QAPMLAPD QAPMPOOL QAPMRWS QAPMSTND
QAPMSTNL QAPMSTNY QAPMX25
Thanks to Richard Schwartz, State Street Bank, USA.
Change 29.118 Change 29.084 deleted temporary MXGENG dataset because
UTILCONT %VGETENG was thought to only create two macro variables,
VGETENG but UTILCONT/VMXGSIZE had undocumented invocations of
VMXGSIZE %VGETENG that required that dataset to exist. The new
May 18, 2011 CLEANUP=YES/NO is added to all three members to allow
the dataset to be kept and deleted later when needed.
Thanks to Paul Naddeo, FISERV, USA.
Change 29.117 -ASCII only, CICSTRAN variables RTYPE/RRTYPE should have
UTILEXCL been input with $EBCDIC informat in VMAC110/UTILEXCL.
VMAC110 -VMACSVIE, variable CNTL_TIME in SV03THRE dataset is now
VMACSVIE converted back from GMT to local time zone.
May 18, 2011 -VMACSVIE, variable DB2_PROGRAM in SV27DB2 is $ASCII.
-VMACSVIE, variable SCUCRSTG is no longer formatted.
-VMACSVIE stores CICS task number as PIB4 and not PD4 so
these variables inputs were changed:
CNTL_TASKNUMBER LASTTRANNUM TRANNUM OTRANNUM EXS_MNTNO
-VMACSVIE, variable THRS_GROUP and THRS_CLASS corrected.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
====== Changes thru 29.116 were in MXG 29.04 dated May 17, 2011========
Change 29.116 The SQL Statement Number in all of the original SQL Trace
FORMATS IFCIDS 53,58,59,60,61,64,65,66 plus 125,183, and 247 have
VMAC102 been wrong (fixed value of 16448 usually) ever since they
May 14, 2011 were relocated and increased from 2 to 4 bytes in DB2 V8.
In making this update, several overlooked variables are
also now output in these T102Snnn DB2 trace datasets, and
several new formats were created to decode them.
Thanks to Joachim Sarkoschitz, DATEV, GERMANY.
Change 29.115 Arguments PDB= and PDBOUT= were not UPCASED, causing the
GRAFWRKX PDB=trend to not be recognized. Now they are.
May 10, 2011
Change 29.114 -Testing JCLSIMPL default example exposed macro language
BLDSMPDB syntax errors corrected in this BLDSMPDB:
VMXGDBSS
May 10, 2011 NOTE: Line generated by the macro variable "RERUN".
May 15, 2011 20 "
-
77
ERRROR 77-185: Invalid number conversion on ""d.
-Tests also exposed errors in VMXGDBSS where SHIFT was not
being created in ASUMDBSx datasets, causing a later
failure when the ASUMs were executed.
-New PDB=NONSMF argument added to BLDSMPDB to support the
new JCLSMOTH non-SMF processing in Change 29.105.
Thanks to Vinnie Falzone, The Prudential, USA.
Change 29.113 Variables CTGLALRQ (Lifetime) and CTGIAREQ (Interval) in
VMAC111 TY111CXI dataset were reversed.
May 10, 2011
Thanks to Gordon E. Griffith, Edward Jones, USA.
Change 29.112 Documentation only. This paragraph was added:
IMACACCT If you have created a SPIN data library and then decide
May 5, 2011 to DROP ACCOUNTn and LENACCTn variables that were kept
originally, you will need to copy and DROP the unwanted
ACCOUNTn and LENACCTn variables from the three datasets
SPIN30_1, SPIN30_5, and SPIN26, and copy & DROP the
unwanted SACCTn variables from SPIN30_4, and then copy
the revised datasets back into your SPIN data library.
Otherwise, the unwanted will still be in both the SPIN
and the PDB JOBS/STEPS/PRINT datasets.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANDADA
Change 29.111 For CICS Attach, the CICS TRAN name is extracted from the
VMACDB2 QMDACORR field, but that value is sometimes wrong and the
May 4, 2011 correct CICS TRAN name exists instead in QWHCCV field, so
MXG now uses QWHCCV as the source of CICS TRAN.
A PMR will be opened with IBM to determine if this is an
IBM error, since DSNWMSGS states that QWHCCV/QMDACORR are
supposed to be the same.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 29.110 The invocation of the dataset exit token _EIMSTRN was
TYPEIMSA accidentally removed from TYPEIMSA in MXG 28.28, but is
May 4, 2011 in now reinstated.
Thanks to Craig Collins, State of Wisconsin DOA, DET, USA.
Change 29.109 PDB.DB2STATS vars QXRWSDEL/QXRWSFET/QXRWSINS/QXRWSUPD
VMACDB2 were incorrectly kept in both DB2STAT0 and DB2STAT1 and
May 4, 2011 were not deaccumulated in _SDB2ST0.
Thanks to Jane S. Stock, USPS, USA.
Change 29.108 -Invalid UARG record was not true; the MXG test for NWORDS
VMACNMON LE 5 should have been LE 4. Additionally, the UARGTYPE=2
May 4, 2011 UARG record now sets THCOUNT=1 so that observations will
be created in the PDB.NMONUARG dataset.
-INVALID ARGUMENT error messages are caused by invalid VM
record that has the second word T0001, an interval marker
which should contain data values, but the invalid record
instead contains the field descriptions. MXG now detects
and prints a clear error message referencing this change.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 29.107 Format MG099TC is updated to decode 70+ new trace codes
FORMATS added by z/OS 1.12 for the SMF 99 variable S99TCOD.
May 4, 2011
Thanks to Michael Oujesky, Bank of America, USA.
Change 29.106 JES3 PDB.JOBS variable CLASS is the 8-byte JOBCLASS when
BUIL3005 the job was read-in, from the TYPE26J3 purge record, IBM
May 3, 2011 field SMF26CLN. CLASS is stored into JOBCLASS when CLASS
is non-blank (i.e., when a Purge Record exists). But the
job class can be changed in exits, in particular, in the
IATUX29 exit; that new JOBCLAS8 value is in the SMF 30
records, so this change now keeps JOBCLASS8 in the JES3
PDB.JOBS dataset, where it's label will be
JOBCLAS8='JES3*8-BYTE*JOBCLASS*AFTER*IATUX29'
If no purge record was found by BUIL3005, the value in
JOBCLAS8 from the 30 record is stored into JOBCLASS.
Thanks to Jeff Ramsay, ArcelorMittal, USA.
Change 29.105 JCLSIMPL and JCLSPxxx examples use UTILBLDP/BLDSMPDB and
BLDSIMPL are THE now-recommended z/OS jobs for a "SIMPLE" BUILDPDB
BLDSPMTH or the "SPLIT SMF" family of "BUILDPDB" jobs.
BLDSPOTH
BLDSPSMA JCLSIMPL creates a "simple", PDB library, with one job
BLDSPSMB that reads the SMF file, showing how to add an SMF record
BLDSPSMC and invoking all of the default ASUMxxxx members to build
BLDSPSMD a "single", default PDB data library from raw SMF data.
BLDSPSME You could do the same with BUILDPDB and the EXPDBxxx exit
BLDSPUOW members, but these more recent utility macros are now the
BLDSPWEK recommended way to build/tailor a simple BUILDPDB:
JCLSIMPL UTILBLDP - defines what data is to be created in a PDB.
JCLSPCPY You can add, subtract, or change what's kept
JCLSPGDG by each of these jobs use UTILBLDP to create
JCLSPLIT a specific suit of MXG datasets in a PDB
JCLSPMTH built from SMF data records.
JCLSPOTH BLDSMPDB - flexible job manager creates day/week/etc
JCLSPSMA PDBs using the UTILBLDP execution preceding
JCLSPSMB its invocation to define the PDB contents.
JCLSPSMC Processes SMF and non-SMF data records.
JCLSPSMD
JCLSPSME JCLSPxxx is a family of jobs to read "split" subsets of
JCLSPUOW SMF and other data records to parallelize the BUILDPDB,
JCLSPWEK using the above+ UTILBLDP and BLDSMPDB members:
VMXGALOC JCLSPGDG - run once to create GDGs, and then never again
VMXGPARS unless there is a need to alter a GDG base or
May 16, 2011 to change dataset names.
Nov 9, 2011 JCLSPLIT - first job in daily stream - standalone -
splits the daily SMF into pieces for
subsequent processing
SMF.ALL - All SMF for archive
SMF.CICS - SMF 110.1
SMF.DB2 - SMF 101/102
SMF.IO - SMF 14/15/42/61/65/66/74/240/241
SMF.MQ - SMF 115/116
SMF.SPLITPDB - All other SMF records
JCLSPSMA/JCLSPSMB/JCLSPSMC/JCLSPSMD/JCLSPSME can be run
concurrently to process the split SMF files:
JCLSPSMA - Read only CICS SMF 110, create:
CICSTRAN.CICSTRAN CICSBAD.CICSBAD.
JCLSPSMB - Read only DB2 SMF 101/102, create:
PDB: DB2ACCT DB2ACCTB DB2ACCTG DB2ACCTP DB2ACCTR
ASUMDB2A ASUMDB2B ASUMDB2G ASUMDB2P ASUMDB2R
JCLSPSMC - Read only I/O records, create:
PDB: TYPE1415 TYPE42AD TYPE42AU TYPE42CC TYPE42CU
TYPE42CV TYPE42DS TYPE42EX TYPE42NF TYPE42NU
TYPE42SC TYPE42SR TYPE42TO TYPE42VL TYPE42VS
TYPE42VT TYPE42XR TYPE42XV TYPE42S1 TYPE42S2
TYPE42S3 TYPE42S4 TYPE42D1 TYPE42D2 TYPE42D3
TYPE42D4 TYPE42L1 TYPE42L2 TYPE42P1 TYPE42P2
TYPE42P3 TYPE42X1 TYPE42X2 TYPE42X3 TYPE42X4
TYPE4220 TYPE4221 TYPE422A TYPE4222 TYPE4223
TYPE4224 TYPE424A TYPE4225 TYPE4226 TYPE4237
TYPE6156 TYPE64 TYPE64X TYPE74 TYPE74CA
TYPE74ID TYPE74CF TYPE74CO TYPE74LK TYPE74ME
TYPE74OM TYPE74PA TYPE74ST TYPE74DU TYPE74SY
TYPE74TD TYPE746B TYPE746F TYPE746G TYPE747P
TYPE747C TYPE748 TYPE748A TYPE748R TYPE748X
HSMDSRST HSMFSRBO HSMFSRST HSMFSRTP HSMDSRFU
HSMVSRFU HSMVSRST HSMWWFSR HSMWWVOL
JCLSPSMD - Read only MQ records, create:
PDB: MQCFSTAT MQMACCT MQMACCTQ MQMBUFER MQMCFMGR
MQMLOG MQMMSGDM MQMQUEUE
JCLSPSME - Read all remaining SMF, create:
ASUM70GC ASUM70GL ASUM70LP ASUM70PR ASUMCEC
ASUMCELP ASUMTALO ASUMTAPE CICEODRV CICINTRV
CICREQRV CICRRTRV CICSEXCE CICSYSTM CICUSSRV
DB2GBPAT DB2GBPST DB2STAT0 DB2STAT1 DB2STAT2
DB2STAT4 DB2STATB DB2STATR DB2STATS DDSTATS
IPLS IPLSMF JOBS NJEPURGE PRINT
RMFINTRV RMFWKLRV SMFINTRV SMFRECNT SPIN26
SPIN30TD SPIN30_1 SPIN30_4 SPIN30_5 SPIN6
SPINRMFI SPINTALO SPUNJOBS STEPS TAPEMNTS
TAPES TYPE0203 TYPE23 TYPE30MR TYPE30MU
TYPE30OM TYPE30_6 TYPE7 TYPE70 TYPE7002
TYPE70EN TYPE70PR TYPE70X2 TYPE70Y2 TYPE71
TYPE72 TYPE7204 TYPE725A TYPE725B TYPE725C
TYPE725D TYPE725E TYPE725F TYPE725G TYPE725H
TYPE725I TYPE725J TYPE725K TYPE725L TYPE725M
TYPE72DL TYPE72GO TYPE72MN TYPE72SC TYPE73
TYPE73L TYPE73P TYPE75 TYPE77 TYPE78
TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP
TYPE78VS TYPE89 TYPE892 TYPE89I TYPESTAT
TYPESYMT TYPESYSL TYPETALO TYPETARC TYPETMNT
TYPETSWP
JCLSPOTH - DCOLLECT, TMC.
JCLSPUOW - after JCLSPLTA and JCLSPLTB have run,
build PDB.ASUMUOW from CICSTRAN and DB2ACCT,
build PDB.CICS from PDB.ASUMUOW.
Nov 9: (+1) instead of (0) for PDB and SPIN
DDnames, and DISP/SPACE parameters added
JCLSPCPY - Copies these datasets into PDB library:
ASUMCACH CICS ASUMUOW ASUMDB:
JCLSPWEK - weekly job using BLDSMPDB to drive the bus
JCLSPMTH - monthly job using BLDSMPDB to drive the bus
BLDSPxxx members are for ASCII execution to create the
same suite of PDB datasets. except that there is no
GDG nor SPLIT members.
BLDSPSMA - Read only CICS SMF 110, create:
CICSTRAN.CICSTRAN CICSBAD.CICSBAD.
BLDSPSMB - Read only DB2 SMF 101/102, create:
PDB: DB2ACCT DB2ACCTB DB2ACCTG DB2ACCTP DB2ACCTR
ASUMDB2A ASUMDB2B ASUMDB2G ASUMDB2P ASUMDB2R
BLDSPSMC - Read only I/O records, create:
PDB: TYPE1415 TYPE42AD TYPE42AU TYPE42CC TYPE42CU
TYPE42CV TYPE42DS TYPE42EX TYPE42NF TYPE42NU
TYPE42SC TYPE42SR TYPE42TO TYPE42VL TYPE42VS
TYPE42VT TYPE42XR TYPE42XV TYPE42S1 TYPE42S2
TYPE42S3 TYPE42S4 TYPE42D1 TYPE42D2 TYPE42D3
TYPE42D4 TYPE42L1 TYPE42L2 TYPE42P1 TYPE42P2
TYPE42P3 TYPE42X1 TYPE42X2 TYPE42X3 TYPE42X4
TYPE4220 TYPE4221 TYPE422A TYPE4222 TYPE4223
TYPE4224 TYPE424A TYPE4225 TYPE4226 TYPE4237
TYPE6156 TYPE64 TYPE64X TYPE74 TYPE74CA
TYPE74ID TYPE74CF TYPE74CO TYPE74LK TYPE74ME
TYPE74OM TYPE74PA TYPE74ST TYPE74DU TYPE74SY
TYPE74TD TYPE746B TYPE746F TYPE746G TYPE747P
TYPE747C TYPE748 TYPE748A TYPE748R TYPE748X
HSMDSRST HSMFSRBO HSMFSRST HSMFSRTP HSMDSRFU
HSMVSRFU HSMVSRST HSMWWFSR HSMWWVOL
BLDSPSMD - Read only MQ records, create:
PDB: MQCFSTAT MQMACCT MQMACCTQ MQMBUFER MQMCFMGR
MQMLOG MQMMSGDM MQMQUEUE
BLDSPSME - Read all remaining SMF, create:
ASUM70GC ASUM70GL ASUM70LP ASUM70PR ASUMCEC
ASUMCELP ASUMTALO ASUMTAPE CICEODRV CICINTRV
CICREQRV CICRRTRV CICSEXCE CICSYSTM CICUSSRV
DB2GBPAT DB2GBPST DB2STAT0 DB2STAT1 DB2STAT2
DB2STAT4 DB2STATB DB2STATR DB2STATS DDSTATS
IPLS IPLSMF JOBS NJEPURGE PRINT
RMFINTRV RMFWKLRV SMFINTRV SMFRECNT SPIN26
SPIN30TD SPIN30_1 SPIN30_4 SPIN30_5 SPIN6
SPINRMFI SPINTALO SPUNJOBS STEPS TAPEMNTS
TAPES TYPE0203 TYPE23 TYPE30MR TYPE30MU
TYPE30OM TYPE30_6 TYPE7 TYPE70 TYPE7002
TYPE70EN TYPE70PR TYPE70X2 TYPE70Y2 TYPE71
TYPE72 TYPE7204 TYPE725A TYPE725B TYPE725C
TYPE725D TYPE725E TYPE725F TYPE725G TYPE725H
TYPE725I TYPE725J TYPE725K TYPE725L TYPE725M
TYPE72DL TYPE72GO TYPE72MN TYPE72SC TYPE73
TYPE73L TYPE73P TYPE75 TYPE77 TYPE78
TYPE78CF TYPE78CU TYPE78IO TYPE78PA TYPE78SP
TYPE78VS TYPE89 TYPE892 TYPE89I TYPESTAT
TYPESYMT TYPESYSL TYPETALO TYPETARC TYPETMNT
TYPETSWP
BLDSPOTH - DCOLLECT, TMC.
BLDSPUOW - after JCLSPLTA and JCLSPLTB have run,
build PDB.ASUMUOW from CICSTRAN and DB2ACCT,
build PDB.CICS from PDB.ASUMUOW.
BLDSPWEK - weekly job using BLDSMPDB to drive the bus
BLDSPMTH - monthly job using BLDSMPDB to drive the bus
Change 29.104 -Interval summarization of CICS Statistics CICLDR dataset
ASUMCLDR in PDB.ASUMCLDR and Trending in TREND.TRNDCLDR is useful
TRNDCLDR to track CICS Program Loader activity.
TRNDCELP -Trending for ASUMCELP and ASUM70LP per-LPAR datasets,
TRND70LP adds zIIP, zAAP, and IFL statistics.
May 1, 2011
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.103 New option RESULTS=FINDVAR will find every dataset in
VMXGSRCH every allocated LIBNAME, or in specific LIBNAMES, that
May 1, 2011 contains any of the variables listed in VARS= argument.
Jul 8, 2011 With FINDVAR option, the VALUE= argument is ignored.
Jul 2011: COUNT option was restored in code, was lost.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.102 Change 29.052 documented this MONTHxxx error 180-322:
ANALDB2R
MONTHASC NOTE: Line generated by the macro function "SUBSTR".
MONTHBL3 18 ;SET MON.XXXXXX TUE.XXXXXX WED.XXXXXX THU.XXXXXX
MONTHBLD ---
MONTHDSK 180
READDB2 ERROR 180-322: Statement is not valid or it is used out
UTILBLDP of proper order.
VMXGSUM
May 2, 2011 was caused by the %CMPRES macro (in SASAUTOS) generating
a line of code when it should have stored that text in a
macro variable, and that this "SAS V9.1.3 ONLY" error was
circumvented by replacing %CMPRES with %QCMPRES. But this
error is also in SAS V9.2, both ASCII and z/OS platforms,
on May 1, but not on May 2. On May 1, a Sunday, with the
default STARTDAY of MON, the to-be-generated SET statement
has the (maximum) of six daily and five weekly elements,
which tripped up %CMPRES, while %QCMPRES worked fine.
But on May 2, with only five week tokens to be generated,
both %CMPRES and %QCMPRES worked fine.
-Detailed traces with all possible %MACRO debugging options
failed to reveal the actual cause of the error.
-But, the SAS documentation for %CMPRES and %QCMPRES states
"The %CMPRES and %QCMPRES macros compress multiple blanks
and remove leading and trailing blanks. If the argument
might contain a special character or mnemonic operator:
& % ' " ( ) + - * / < > = ¬ ^ ~ ; , # blank
AND OR NOT EQ NE LE LT GE GT IN
use %QCMPRES.
%CMPRES returns an unquoted result, even if the argument
is quoted.
%QCMPRES produces a result with the special characters
and mnemonic operators masked, so the macro processor
interprets them as text instead of as elements of the
macro language."
Since all MXG uses of %CMPRES are objects of a %LETs for a
text string, and since some of those text strings can have
those special characters, all %CMPRES are now %QCMPRES.
Thanks to Rodger Foreman, Acxiom, USA.
Change 29.101 Support for z/VM 6.2, COMPATIBLE RECORD CHANGES BY IBM.
EXIODMDE IBM's MONWRITE/MONDATA file changes WERE COMPATIBLE, but
EXISFILC MXG code might fail if you create SYTLCK (0.23) records;
EXISFISA See note at bottom to read 6.2 data with prior MXG code.
EXISFISC z/VM 6.2 MONWRITE is a MAJOR enhancement, with these 19
EXISFNOD new records (VXPRCMFC has the z/OS SMF 113 Counters!):
EXMTRILC DMN REC DDDDDD DATASET DESCRIPTION
EXMTRISC 1 23 MTRISC VXMTRISC ISFC End Point Configuration
EXMTRSSI 1 24 MTRILC VXMTRILC ISFC Logical Link Configuration
EXMTRTOP 1 25 MTRSSI VXMTRSSI SSI Configuration Information
EXPRCMFC 1 26 MTRTOP VXMTRTOP System Topology
EXPRCTOP 4 11 USERLS VXUSERLS Guest Relocation Started
EXSSISCH 4 12 USERLS VXUSERLS Guest Relocation Ended
EXSSISLT 5 13 PRCMFC VXPRCMFC CPU-Measurement Facility
EXSSISMI
EXSSISCS 5 14 PRCTOP VXPRCTOP System Topology
EXSSIXDI 6 31 IODMDE VXIODMDE Minidisk Activity
EXSSIXLK 9 1 ISFISC VXISFISC ISFC End Point Status Change
EXUSERLS 9 2 ISFISA VXISFISA ISFC End Point Activity
EXUSERLS 9 3 ISFILC VXISFILC ISFC Logical Link Def Change
FORMATS 9 4 ISFNOD VXISFNOD ISFC Logical Link Activity
IMACVMXA 11 1 SSISSC VXSSISSC State Change Synch Activity
VMACVMXA 11 2 SSISMI VXSSISMI State/Mode Information
VMXGINIT 11 3 SSISCH VXSSISCH State Change/Event
May 6, 2011 11 4 SSISLT VXSSISLT Slot Definition
Oct 22, 2011 11 6 SSIXLK VXSSIXLK XDISK Serialization Sample
Nov 2, 2011 11 7 SSIXDI VXSSIXDI XDISK Activity
and with changes to these 36 existing datasets:
0 VXSYTPRP (0.02) VXSYTRSG (0.03) VXSYTSHS (0.07)
VXSYTUSR (0.08) VXSYTUWT (0.12) VXSYTSCP (0.13)
VXSYTXSG (0.14) VXSYTCUM (0.17) VXSYTLCK (0.23)
1 VXMTREPR (1.01) VXMTRSYS (1.04) VXMTRPRP (1.05)
VXMTRDEV (1.06) VXMTRMEM (1.07) VXMTRSPR (1.09)
VXMTRDDR (1.14) VXMTRUSR (1.15) VXMTRCCC (1.18)
2 VXSCLSHR (2.09) VXSCLIOP (2.11)
3 VXSTORSG (3.01) VXSTORSP (3.02) VXSTOASP (3.04)
VXSTOADD (3.21)
4 VXUSELON (4.01) VXUSELOF (4.02) VXUSEACT (4.03)
VXUSEINT (4.04) VXUSEATE (4.09)
5 VXPRCCFN (5.06) VXPRCCFF (5.07) VXPRCAPC (5.09)
6 VXIODVON (6.01) VXIODVSW (6.21)
8 VXVNDSES (8.01)
10 VXAPLSDT (10.02)
-Dataset VXPRCMFC is created with TYPE113 variable names,
including all of the metrics from John Burg's papers, so
the existing ASUM113 dataset can be used to summarize the
new hardware counters from either z/VM or z/OS records.
-The sort order was changed on some existing datasets that
had not previously been validated for the NODUP option.
The _Bdddrrr "BY LIST" macro for each dataset has been
validated to ensure that PROC SORT NODUP; BY _Bdddrrr;
removes duplicates; some existing dataset's _Bdddrrr list
was insufficient and had to be extended to ensure the
physical adjacency of duplicate records.
The validation reads the same MONWRITE file twice and
the _SVMXA macro sorts all datasets. The SAS log
message for each sort is examined to ensure that
exactly one half of the input observations were
reported as duplicates.
-The validation of the BY LIST with NODUP is NOT because
MONWRITE has a duplicate record problem; it is required
for the DIF() validation of the MXG deaccumulation logic.
Because MONWRITE records contain accumulated values, the
deaccumulation logic (a DATA step in the _Sdddrrr macro)
uses the same "BY LIST" _Bdddrrr macro as the NODUP did.
The deaccumulated datasets are then examined with PROC
MEANS for MIN. If a non-accumulated field (cardinal,
min, max, end point) is deaccumulated, or if its sort
order is not correct, its minimum value will be negative.
-This change was a significant project; there were 3417
source lines inserted, and 730 lines deleted in the main
VMACVMXA code member, which now has 24,653 lines. The
update took from Monday thru Saturday, 40-50 hours.
I documented the original VM/XA MONWRITE development in
1988, 150 hours across 10 days for 75 datasets and 15,000
lines, I think, but I can't find that note right now!
-Not new in z/VM 6.2, but it has always been the case that
when the same MONWRITE data file was read twice, two MXG
created datasets had an odd number of observations, where
an even number should have been created. The two datasets
VXMTREPR (1.01) and VXMTRDDR (1.14) records are written
at MONITOR START, but prior to the MTRSYS (1.04), which
contains the GMT Offset (SYSZONE) value. MXG deletes
records with SYSZONE missing, because the MRHDRTOD can't
be converted to local time and thus is unknown.
But because SYSZONE is retained so it can be used for all
other records in this collect, if data from a different
system is concatenated, the new system's 1.01 record will
use the non-missing SYSZONE from the prior system and was
output with the wrong MRHDRTOD value. Fortunately, IBM
has added SYSZONE field to 1.01 MONITOR START record so
the MXG logic now exploit that addition and will use the
1.01 for MONITOR START when it contains SYSZONE.
-Also not new in z/VM 6.2, there is no SYNC option to make
MONWRITE interval records synchronized with TIME of DAY;
the intervals when the MONITOR SAMPLE INTERVAL or the
MONITOR START command is issued. A formal requirement
has just been submitted, and this text will be updated if
IBM accepts that request. In the interim, this example
from IBM can be used to STOP and reSTART the monitor with
TOD synchronization to second zero of the next minute:
/* Make the monitor intervals start on second zero */
'CP MONITOR STOP'
Parse value time('N') with hh ':' mm ':' ss .
mm=mm+1 /* Wait for the next minute*/
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
'WAKEUP' hh':'right(mm,2,0)':00' /*Wait*/
'CP MONITOR START' /*Start the monitor*/
Exit
Note: changing the mm=mm+1 to hh=hh+1
and changing to 'WAKEUP' hh':00:00'
will cause MONWRITE data to be on an hourly boundary.
-CIRCUMVENTION TO SKIP MONWRITE 0.23 SYTLCK RECORD:
To process z/VM 6.2 records with MXG 29.03 or earlier,
this code will skip all 0.23 records:
//SYSIN DD *
%LET MACVMXX=
%QUOTE(
IF MRHDRDM=0 AND MRHDRRC=23 THEN DO;
INPUT +SKIP @;
SKIP=0;
MRHDRDM=-99;
MRHDRRC=-99;
GOTO MWENDIT;
END;
);
%INCLUDE SOURCLIB(....);
Change 29.100 Support for GDPS Global Mirror V3R8 SMF ID=105 record,
EXTY1051 which creates these two new datasets:
EXTY1052 dddddd Dataset Description
IMAC105 TY1051 TYPE1051 GDPS SESSION DATA
VMAC105 TY1052 TYPE1052 GDPS LOGICAL SUBSYSTEM DATA
VMXGINIT
Apr 28, 2011
Thanks to Paul Volpi, UHC, USA.
Change 29.099 Omegamon User SMF "OMCI" record tested for versions before
VMACOMCI testing for SUBTYPE and RECSUBTY, and records from the old
Apr 27, 2011 version 420 printed error messages that that version was
unknown. But these were ID=112 records with SUBTYPE=203
and RECSUBTY=0, which are "112s" and not "OMCI", so the
code now accepts '420' for version but also deletes these
non-OMCI records ahead of the version test.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 29.098 Variables ICFCPUS, IFLCPUS, IFACPUS, ZIPCPUS, only in the
VMXG70PR PDB.ASUMCEC dataset, were wrong (too high, they were the
Apr 27, 2011 SUM across all LPARs with those specialty engines).
Thanks to Otto Burgess, OPM, USA.
Change 29.097 INPUT STATEMENT EXCEEDED (on z/OS), INVALID FLOATING POINT
EXCICRDD (on ASCII) SMF 110 subtype 1 MNSEGCL=5 records, if any DPL
IMAC110 DPL Resource Segments exist (i.e., MNR5NUMX GT 0).
VMAC110 DPL segments, new in CICS/TS 4.1, were not input, causing
VMXGINIT mis-alignment, but they now create new CICSRDPL dataset.
Apr 26, 2011 Also, new variables added by CICS/TS 4.1 are now output
in the existing CICSRDS dataset that were overlooked.
Thanks to Paul Volpi, UHC, USA.
Change 29.096 Documentation only. APAR PK99058 corrects Tivoli Storage
VMAC42 Manager z/OS Server Accounting Record CPU usage field,
Apr 25, 2011 (variable CLICPUTM in TYPE42AD), in TSM Version 5.5 only,
which had failed to populate that field.
Thanks to Jacob Nudel, Thomson Reuters, USA.
Change 29.095 Parameter DALYKEEP= added to bldsmpdb to control which
BLDSMPDB dataset are selected by the PROC COPY from the PDB into
Apr 22, 2011 the Day-Of-Weed dataset, and can be a SELECT statement or
====== Changes thru 29.094 were in MXG 29.03 dated Apr 19, 2011========
Change 29.094 MXG 29.03 Dated APR 11: ALL CICSTRAN TIME VARIABLES WRONG
VMAC110 (if you did NOT use UTILEXCL to create IMACEXCL). A mass
Apr 19, 2011 change command went awry and inserted 16* in all of the
time duration variables in blocks of "fall thru" code for
CICS/TS 3.2 or later. This SHOULD have printed the MXG
***ERROR VMAC110: CPU 10X LARGER THAN ELAPSED.
See Change 29.076 for the CPU 10X LARGER enhancement.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 29.093 INPUT STATEMENT EXCEEDED for subtype 79; value '1120' was
VMAC85 added to the two tests for variable R85PVRM in the block
Apr 18, 2011 that reads subtype=79, support z/OS 1.12 INCOMPAT change.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 29.092 Variables ZIPCPUS and IFACPUS in PDB.ASUMCEC/PDB.ASUM70PR
VMXG70PR were the average number online, but that included parked
Apr 13, 2011 time. They are now corrected to count the number of
AVERAGE*ONLINE*NOTPARKED specialty engines. Variables
NRZIPCPU and NRIFACPU are the number installed.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 29.091 If MXG's default COMPRESS=YES is changed to COMPRESS=NO,
VMAC102 all SQL Text variables are broken into 100 byte chunks
Apr 13, 2011 and multiple observations are created in the T102Tnnn
datasets, but the last two characters of each chunk have
been missing since DB2 V8.1 changed the structure of
the length fields; MXG still subtracted 2 bytes which it
should not have. DB2 SQL text is created in these IFCIDS:
63 124 140 141 142 145 168 which are now all corrected.
Thanks to Mark Tomlinson, Lloyds Banking, ENGLAND.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 29.090 Typo for the IMS08D and IMS0A08 datasets _Wdddddd entries
VMACIMS had _VIMS08 _KIMS08 which are now _VIMS08D _KIMS08D and
Apr 13, 2011 _VIMS0A8 and _KIMS0A8 respectively. Since the _VIMS08
and _VIMS08D keep the same variables, the IMS0708 dataset
was not impacted, and, fortunately, no one uses IMS0A78.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Change 29.089 -The z/VM MONWRITE dataset PDB.VXBYUSR has one observation
VMACVMXA for every VMDCPUAD (CPU ADDRESS) configured for each VM,
VMXGINIT so it doesn't have the interval total for each machine.
Apr 13, 2011 The new PDB.VXINTUSR sums PDB.VXBYUSR to create one obs
for each interval for each machine, counting configured
(ENGCONFG) and online (ENGONLIN) engines.
-Variables VMDVTMP VMDTTMP VMDVTMS VMDTTMS are correctly
deaccumulated with this change.
Thanks to Ron Lewis, State Street Bank, USA.
Change 29.088 These "user id" variables are added to TMDBDB2 dataset
VMACTMDB DBHCEUID DBHCEUTX DBHCEUWN
Apr 12, 2011 (and should have been added a long time ago!).
Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA.
Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA.
Change 29.087 Comments in IMACIMS7 and IMACIMS7 for _IMSVERS values are
IMACIMS inconsistent; 10.1 or 11.1 were listed, but the values
Apr 12, 2011 needed are only 10.0 and 11.0 (so the misleading values
worked fine!).
And Change 28.311 did not change the datasets created;
that change only restructured the internal IMS processing
code to separate and then recombine the TM and DBCTLs.
Thanks to Daniel Strgarsek, SAS Institute, GERMANY.
====== Changes thru 29.086 were in MXG 29.03 dated Apr 11, 2011========
Change 29.086 The QA conflict report from DOCVER showed SYSTEM was $8
ANALID in PDB.SMFRECNT, but SYSTEM is always $4. After 2 hours
Apr 10, 2011 of tests with inserted PROC CONTENTS, I found it only
occurred when there were no observations in TYPEID, which
is normal for the QASAS job that creates DOCVER, and then
remembered that when the old PROC FREQ was replaced with
the enhanced ANALID (with PROC TABULATE to capture both
counts and bytes), an extra step was needed to create the
PDB.SMFRECNT (because PROC TABULATE didn't, with no obs),
and finally found the statement SYSTEM=' '; that
should have been SYSTEM=' '; to set its length to $4.
Change 29.085 -Revision to limit search to the LIBNAME requested and a
VMXGSRCH missing semicolon was inserted, although no syntax error
Apr 10, 2011 was reported.
-If VARS= is specified without VALUE=, the results are the
list of datasets that contain that variable.
Change 29.084 -Temporary dataset MXGENG is now deleted by VGETENG.
VGETENG -Variables QWHSACE QWHSMTN QWACACE ACE are now consistent
VMACDB2 LENGTH 5 and FORMAT HEX8 addresses, QWARACE is LENGTH 8
VMAC102 and FORMAT HEX16 in VMACDB2/VMACDB2H/VMAC102.
VMACDB2H -Variables TOKLEN and TOKVERS in VMAC80A are labeled.
VMAC80A -Variable CTGAPPLQ is labeled, comments for CTGAPLID now
VMAC111 match in VMAC111.
Apr 10, 2011
Thanks to Chris Weston, SAS/ITRM Development, USA.
Change 29.083 -Variable QWAXOTSE was added twice in three places; it was
ANALDB2R not detected because it was zero in the test SMF data.
Apr 9, 2011 -May 1: The formula for calculating the average time (per
May 1, 2011 thread) that was "not accounted for" was revised, thanks
to this equation provided by IBM DB2 Support in response
to a customer PMR, i.e., the Class 2 Elapsed times minus
the sum of Class 2 CPU and Class 3 Suspension durations:
AVG=(
/*** CLASS 2 ELAPSED ***/
SUM(QWACASC+QWACSPEB+QWACUDEB+QWACTRET+QWACTREE,0)
/**** CLASS 2 CPU ****/
-SUM(QWACAJST,QWACSPTT,QWACUDTT,QWACTRTT,QWACTRTE,0)
/**** CLASS 3 SUSPENSIONS ****/
-SUM(QWACAWTL,QWACAWTI,QWACAWTR,QWACAWTW,QWACAWTE,
QWACALOG,QWACAWAR,QWACAWDR,QWACAWCL,QWACAWTP,
QWACCAST,QWACAWTG,QWACAWTJ,0))/THREADS;
-The Accounting Trace Reports had many fields missing in
the headers because they had not been listed in the
SORTBY= arguments.
-For the ACCOUNTING reports, selection was not being done.
If you specified DB2=DB20 you still got all of the data
for all of the subsystems.
Thanks to Neil Ervin, Wells Fargo Bank, USA.
Change 29.082A Using PDB.ASUMCEC/PDB.ASUMCELP is STRONGLY RECOMMENDED
ASUM70PR because PDB.ASUM70PR/ASUM70LP CAN BE TERRIBLY WRONG for
Apr 9, 2011 many of the LPAR-Specific Variables, when IRD is active
and/or Hiperdispatch is enabled. In those environments,
only the "LPn" variables for the "THIS LPAR" observation
(i.e., "THIS SYSTEM") in "SYSTEM-LEVEL" ASUM70PR/ASUM70LP
datasets are always valid. These LPAR-Specific variables:
LPnNRPRC LPnDUR LPnLAC LPnONT LPnPAT LPnWST
LPCTnBY LPCTnOV
LPnZIUTM LPnZIKTM LPnIFUTM LPnIFKTM
will be WRONG in the ASUM70PR/ASUM70LP observations from
the "OTHER LPARs", because those LPAR-Specific variables
are based on SMF70ONT/SMF70PAT, which are ONLY valid in
the "THIS LPAR" observation.
This PROC PRINT shows the six ASUM70PR observations from
each of six SYSTEMs, with the set of LPAR-Specific fields
for LPAR 2 (SYSA). You can see that ONLY the observation
in ASUM70PR for SYSTEM=SYSA, the "THIS LPAR, THIS SYSTEM"
observation, are valid and match the ASUMCEC observation:
(Note that not ALL of the variables are WRONG!).
SYSTEM LP2NAME LP2DUR LP2UPDTM LP2UEDTM LP2MGTTM
******
SYSK SYSA 6:00:00.01 1:21:32.11 1:21:00.97 0:00:31.14
SYSA SYSA 2:33:48.28 1:21:31.41 1:21:00.27 0:00:31.14
SYSC SYSA 6:00:00.43 1:21:32.38 1:21:01.24 0:00:31.14
SYSD SYSA 6:00:00.30 1:21:32.50 1:21:01.36 0:00:31.14
SYSG SYSA 6:00:01.16 1:21:32.21 1:21:01.07 0:00:31.14
SYST SYSA 6:00:00.09 1:21:32.20 1:21:01.07 0:00:31.14
ASUMCEC: SYSA 2:33:48.28 1:21:31.41 1:21:00.27 0:00:31.14
SYSTEM LPCT2BY LPCT2OV PCTL2BY PCTL2OV LP2NRPRC LP2BDA
******* ******* ********
SYSK 22.64 0.14416 22.6486 0.14416 6.0 8
SYSA 53.00 0.33744 22.6521 0.14421 2.6 8
SYSC 22.64 0.14416 22.6495 0.14416 6.0 8
SYSD 22.65 0.14417 22.6502 0.14417 6.0 8
SYSG 22.64 0.14416 22.6479 0.14416 6.0 8
SYST 22.64 0.14416 22.6490 0.14416 6.0 8
ASUMCEC: 53.00 0.33744 22.6454 0.14416 2.6 8
SYSTEM LP2SHARC LP2SHARE LP2LAC LP2MSU LP2MSUHR
******
SYSK 16.2389 13 . 129.378 129.378
SYSA 16.2420 13 29.2360 129.360 129.398
SYSC 16.2389 13 . 129.385 129.383
SYSD 16.2389 13 . 129.388 129.387
SYSG 16.2389 13 . 129.381 129.374
SYST 16.2389 13 . 129.381 129.380
ASUMCEC: 16.2420 13 29.2360 129.360 129.360
SYSTEM LP2CSF LP2ONT LP2WST LP2ZIPTM
****** ******
SYSK 10G 6:00:00.01 3:59:14.35 0.00:18.94
SYSA 10G 2:33:47.23 0:33:06.46 0.00:18.94
SYSC 10G 6:00:00.43 3:59:15.35 0.00:18.94
SYSD 10G 6:00:00.30 3:59:15.46 0.00:18.94
SYSG 10G 6:00:01.16 3:59:15.21 0.00:18.94
SYST 10G 6:00:00.09 3:59:14.81 0.00:18.94
ASUMCEC: 10G 2:33:47.23 0:33:06.46 0.00:18.94
SYSTEM LP2ZIUTM LP2ZIKTM LP2ZIWTM
******** ******** ********
SYSK 2:00:00.00 . 1:59:41.11
SYSA 1:59:57.87 0:00:00.00 1:59:38.98
SYSC 2:00:00.14 . 1:59:41.25
SYSD 2:00:00.10 . 1:59:41.20
SYSG 2:00:00.39 . 1:59:41.49
SYST 2:00:00.03 . 1:59:41.13
ASUMCEC: 1:59:57.87 0:00:00.00 1:59:38.98
The non-LPAR-Specific variables ARE VALID; it's ONLY the
variables identified above that can be WRONG.
-And, for ASUMCEC to ALWAYS BE RIGHT, you MUST have READ
the PDB.TYPE70PR observations FOR ALL LPARS (ALL SYSTEMS)
as input to ASUM70PR when you create PDB.ASUMCEC/CELP.
-This change was ONLY documentation; no code was changed.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 29.082 The default ASUM70GC/ASUM70GL interval was hard coded at
VMXG70PR HOUR, which matched the default for ASUMCEC/ASUMCELP, but
Apr 9, 2011 now INTERVAL=&CECINTRV is used so the group data interval
matches the CEC interval data, if you change CECINTRV.
With hindsight, these two datasets should have been named
ASUMCEGC and ASUMCEGL because both are summarized at the
CEC level (e.g., by CECSER, and NOT by SYSPLEX SYSTEM),
but it's too late to change dataset names now.
-New variable MAX70NSW, the maximum percent of time when
the LPAR was soft-capped, is now created in PDB.ASUM70GL,
as the hourly average in SMF70NSW could mask intervals
that were capped.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 29.081 -Support for SMF 120 Subtype 9 User Field SM1209FH creates
VMAC120 that variable in dataset TYP1209E. While up to 5 user
VMXGINIT segments of 2048 bytes each per record can be created,
Apr 8, 2011 this change keeps only the first segment, and only the
Nov 8, 2011 first 12 bytes of the optional field are kept in SM1209FH
although temporary variable SM1209F input all 2048 and is
to be used as the source of SM1209FH, which can contain
HEX, EBCDIC or ASCII text. The MXG default is ASCII, to
match the original test data that was received, but that
can be tailored if you have EBCDIC or HEX data values.
-Variable SM1209FB is the data length in SM1209FH, and the
variable SM1209FF contains the user-chosen datatype, and
temporary variable SM1209F was input with $VARYING2048.,
so if your 12-bytes were EBCDIC instead of MXG's ASCII
default, then you would insert this statement
SM1209FH=INPUT(SM1209F,$EBCDIC12.);
in your EXT1209E to input the text as EBCDIC, and/or
you could use your installer's chosen SM1209FF datatype
value to conditionally input as ASCII/EBCDIC/SUBSTR/etc.
-The length of a character variable can NOT be changed in
a dataset exit member EXddddd. Only numeric variables
can have their length changed in a dataset exit member,
as SAS uses the first instance for character length and
the last LENGTH statement for numeric variables.
-The existing IMACFILE/MACFILE exit is taken before the
LENGTH statements in all VMACs are compiled, so it could
be used to change length of SM1209FH with this syntax:
//SYSIN DD *
%LET MACFILE= %QUOTE( LENGTH SM1209FH $40; );
%INCLUDE SOURCLIB(BUILDPDB);
in the job that reads the SMF 120 records. However that
is not the real purpose of the IMACFILE exit, and it may
already exist for record selection, and the insertion of
the LENGTH statement could cause non-fatal messages with
UNINITIALIZED VARIABLE SM1209FH if the program that is
%INCLUDEd doesn't process SMF 120 records. Using MACFILE
is totally slick but not righteous; there's a better way.
-Nov 8: This change creates macro variable &VARSM1209FHLN
in VMXGINIT and uses it LENGTH SM1209FH $&VARSM1209LN;
in VMAC120, so that the default of 8 can be more easily
changed (for example, to $40) and converted to EBCDIC:
//SYSIN DD *
%LET MACKEEP=
%QUOTE (
MACRO _ET1209E
SM1209FH=INPUT(SM1209F,$EBCDIC12.);
%%
);
%LET VARSM1209FHLN=12;
%INCLUDE SOURCLIB(BUILDPDB);
-Nov 8: Change text was completely rewritten.
Thanks to Larry Gray, Lowe's Companies, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 29.080 -New variables from Meral's excellent SHARE paper at
VMAC113 http://share.confex.com/share/116/webprogram/authort.html
Apr 7, 2011 are created in TYPE113 and ASUM113 datasets:
Apr 19, 2011 DWINSORM='DIR WRITES*L1 INST CACHE*FROM REMOTE'
DWDASORM='DIR WRITES*L1 DATA CACHE*FROM REMOTE'
with different equations for z10 vs z196 calculation.
-These original z10 counters were defined as:
EXTND128='DIRWRIT*TO L1-I*RETURNED*FROM L2'
EXTND129='DIRWRIT*TO L1-D*INSTLD*FROM L2'
but the z196 reversed contents so the labels are changed
EXTND128='DIRWRIT*TO L1-D*RETURNED*FROM L2'
EXTND129='DIRWRIT*TO L1-I*INSTLD*FROM L2'
with the Data count in 128 and the Instructions in 129.
Since there is no way to have two different labels for
the same SAS variable, I chose to use the z196 choice,
hoping z10 users will find this note. Fortunately, all
calculations use the sum of this pair of counters, so the
impact is minor unless you are looking in great detail
level for the old z10 processor.
Apr 19: SM113DOL corrected to SM113DON.
Thanks to Meral Temel, Garanti Teknoloji, TURKEY.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 29.079 MXG will now ABEND if SMFTIME is invalid. Occasionally,
VMACSMF using the SAS ftp access method, SAS would stop after
Apr 7, 2011 writing a horrendous SAS log (6 MILLION PAGES, not lines)
of MXG messages "FIRST RECORD IN GROUP SYSTEM= SMFTIME=".
The rerun was always successful, suggesting the error is
in the ftp Server, but this enhancement will stop the MXG
job by detecting that missing value in SMFTIME.
SAS was executing under Windows/XP with Service Pack 3.
Thanks to Bruce Orr, U.S. Customs and Border Protection, USA.
Change 29.078 Support for OS/400, AS/400, Version 7.1 INCOMPAT (due to
FORMATS IBM change in the LRECL for QAPMDISK file to 539).
VMACQACS Only the QAPMCONF/QAPMDISK/QAPMJOBL/QAPMPOLL/QAPMSYSL
Apr 7, 2011 files have been validated with 7.1 records, so it is
possible other files may also be INCOMPATIBLE. There
are also a number of new files that are not supported,
until a user needs those data and provides test files.
-Dataset QAPMCONF, new variables:
GDESF1T GDESF1S GDESFT GDESG1- GDESG9 GDESGA
GDESHT GDESMT GDESPF
and new formats are created in FORMATS member, so that
you must update your format library.
-Dataset QAPMCONF, new variables
DSPTROP DSPTWOO DSWWWNN
In addition, variable DSIOARN was documented and INPUT as
$EBCDIC15., but data in the records show only 10 bytes so
the INPUT was reduced and PMR was opened with IBM Support
to determine the true length of the field.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to David Bixler, FISERV, USA.
Change 29.077 -Executing z/OS under z/VM caused MXG to print 3 messages:
VMAC7072 MXGNOTE:CPUID SECTION ERROR. INVALID RECORD ... DELETED.
Apr 2, 2011 but the TYPE70 observation had already been output in the
TYPE70SP dataset (thanks to the "Split 70s" redesign, so
nothing was lost). Under z/VM, the CPUID segment of the
RMF 70 record does not exist. The revised message reads:
MXGNOTE: RMF70 CPUID SECTION DOES NOT EXIST
THIS IS NORMAL IF z/OS IS EXECUTING UNDER Z/VM.
OTHERWISE THIS IS AN INVALID RMF 70 RECORD.
-Prior to z/OS 1.12, the PRCS/PRDS segments of the RMF
70 record did not exist when z/OS was run under z/VM.
But in z/OS 1.12, APAR OA35675 captures the CPU dispatch
time of both the z/OS partition and the z/VM "overhead".
See Change 29.127 which added support for that APAR.
-On the topic of z/OS under z/VM, past Newsletters noted:
- To construct the configuration and recording of TYPE78
data, RMF must read the IOCDS data set, but under z/VM,
the IOCDS is not available to z/OS, so some type RMF 78
records will not exist.
- Under z/VM, the RMF I/O Queueing Activity Report shows
only the static configuration data.
-And IBM's Running Guest Operating Systems documents that:
-When you analyze the z/OS environment, remember that
you have two operating systems running in a single
processor. Both z/VM and z/OS are vying for the basic
system resources, such as processor, I/O, storage, and
paging. Each is generating its own accounting
information, and each is supplying its own performance
information.
-Remember that z/OS is unaware that it is running as a
guest under z/VM. What the z/OS guest thinks is
real-time is actually the time-of-day clock and
processor timer facility. Elapsed time as measured by
the time-of-day clock is accurate. The guest's virtual
processor timer (VPT) runs whenever the guest is
dispatched or is in a voluntary wait state. It does not
run if the guest is in a CP wait state. Thus, when z/VM
dispatches another virtual machine and later dispatches
the z/OS guest, z/OS does not realize it had stopped
running.
-Information about guest system performance is
frequently published in Washington System Center
flashes. Contact your marketing team for obtaining
flashes that pertain to your particular installation.
-And IBM's RMF Programmer's Guide documents for z/VM:
-Partition Defined Capacity Used Percent is zero.
-And IBM's RMF Reports Manual documents for z/VM:
-When Channel Path Measurement Facility (CPMF) is not
available, for example, on z/OS systems running as z/VM
guests, RMF uses sampled data from SRM so that the
reported channel utilization is only an approximate
value. With increasing channel speed, the channel
utilization value becomes more and more inaccurate.
Therefore, in such cases, RMF does not provide accurate
values of FICON channel utilization. Beginning with
z990 processors, the channel data from SRM is no longer
available. As a result, the channel utilization data on
a z/OS system running as z/VM guest, is not reported.
-In the DEV and DEVV reports, LCU will be blank if this
is a non-dedicated device in a z/VM guest system
environment.
-Running in a z/VM guest environment, these RMF reports:
Partition Data Report
LPAR Cluster Report
Group Capacity Report
do not exist (because TYPE70PR has zero observations).
Dataset TYPE70 variable VMSYSTEM='Y' for z/OS under VM.
-For the CPU Activity Report:
If RMF is running as a guest under z/VM, it only reports
the z/OS busy time percentage. If you want to measure
partition utilization (as well as the individual CPU
utilization of the single guests, namely LPAR busy time
percentage), you need to use a z/VM monitor.
Thanks to MP Welch, Aprize, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 29.076 CICS CPUTM can significantly exceed ELAPSTM if you have
VMAC110 "knee-capped, i.e. slow" CP engines with zIIP/zAAPS.
Apr 1, 2011 The specific case had CPUTM=25 and ELAPSTM=5 on a CP with
a zAAP that was 10 times faster (or that CP was 10 times
slower!). CICS Support responded to the PMR documenting
that CICS uses the TIMEUSED macro to capture CPU time:
"Note: TIMEUSED returns normalized CPU time. Some
servers are configured with System z(TM) Application
Assist Processors (zAAPs) or IBM System z9® Integrated
Information Processor and IBM System z10(TM) Integrated
Information Processors (zIIPs), which run at a faster
speed than the normal CP processors. In this case,
zAAP time and zIIP time is normalized to the equivalent
time it would take to run on a normal CP when
accumulated into total CPU time. "
The specific case had CPUTM=25 and ELAPSTM=5 on a machine
with a zAAP that was 10 times faster (or a CP that was 10
times slower!), which printed a recently added MXG ERROR
message "CPUTM MUCH LARGER THAN ELAPSED". This message
was added to enhance MXG's detection of mis-aligned SMF
records when CICS fields were excluded or optional fields
were added. Previously, the only way for MXG to catch
mis-alignment was to test that TASKNR was a valid packed
decimal or that STRTTIME was a missing value, but both of
those fields are at the beginning of the segment, and
some combinations of EXCLUDEd fields with optional data
segments passed those tests as the record was read, but
the CICSTRAN dataset contained invalid values for fields
later in the record, but that was only after the MXG job
had completed and the user analyzed the data. This test
was added for more robust detection, but the original was
only for CPUTM GT 2*ELAPSTM, which in this specific case
was a spurious ERROR message. I have changed the test to
CPUTM GT 10*ELAPSTM and added a note in the message that
this could be normal if you have knee-capped CP engines.
-These CPU time variables in CICSTRAN recorded those 25
Normalized CPU seconds: TASDSPTM (USRCPUT), KY8CPUTM,
L8CPUTTM, and the total CPUTM, for this transaction that
obviously spent some serious time on the zAAP engine.
Thanks to Hugo L. Michel, Prince Georges County, MD, USA.
Thanks to Dan Zachary, IBM CICS Support, USA.
Change 29.075 -Support for NTSMF's 62 new objects and 1425 new metrics.
EXNTD001 And, a MAJOR redesign in MXG architecture, isolated now
EXNTD062 to the NTSMF product support, but a possible harbinger
IMACNTSM of future MXG support: DATASET NAMES UP TO 32 CHARACTERS,
VMACNTSM with that dataset name being the OBJECT name (with blanks
VMXGINIT and periods changed to underscores). The "dddddd" dataset
Mar 31, 2011 tokens for the new datasets are "NTD001-NTD062", and the
VMXGINV variable/metric names use the D001 part of the dddddd
UTILVREF token as their prefix, and are sequentially numbered,
e.g. D0010001-D00010008 are the 8 variable names for the
dataset with NTD001:_NET_CLR_NETWORKING, and the labels
for the metrics are the metric name, shortened to forty
characters with asterisks inserted for the SPLIT='*' SAS
operand (to split labels when printing).
Previously, I created unique dataset names and variable
names that were arbitrarily limited to 8 characters, but
this design was implemented by the MAKENTSM code member
that programmatically generates all of the structural
code that is then cut/pasted to add the new datasets and
their exit members. The _UNTDISC utility provides the
cut and paste text for the metric names, that become the
labels for each variable; that is (and will always be) a
manual process, as that's how I discover what new metrics
are created, and get an understanding of each new object.
It is also where the conversion of values to be
consistent (like converting KB fields to bytes) and
assignment of MXG formats (like MGBYTES to those
converted fields, both for the "print pretty" aspect, but
more importantly, to document (in PROC CONTENTS) the
variables that contains storage units) that requires
human knowledge is done. The new objects are listed in
IMACNTSM rather than here!
-The increase of DATASET name required revisions to the
internal programs VMXGINV and UTILVREF that create the
DOCVER members; for datasets with names longer than 9,
DOCVER now has two lines, one for the DATASET name and
a second line for the DATASET label. Additional updates
were needed in a number of the internal QA programs to
support the longer dataset names.
Change 29.074 MXGWARM: MORE THAN 20 DUPLICATE LABELS, for TYPE8224 with
VMAC82 SMF82DCN, MORE THAN 20 UNAUTH DUPE for TYPE8225 are notes
Mar 30, 2011 that you had more than the 20 I thought was enough. With
a max of 36 now observed, I've increased to 40 the number
of these variables that are kept in the two datasets.
But, with MXG's default of COMPRESS=YES, why have any
limit at all: there really isn't any real cost of DASD
space, if the extra variables are all blanks.
If this is really a normal need, to know each of the
instances of the duplicate KEY, when there might be more
than 40, then MXG would create a new dataset with one
observation per instance, and free itself from any
array-size constraints!
Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.
Thanks to Alan Yang, Citibank N.A., SINGPORE
Change 29.073 Documentation comments (ONLY) were updated to show how
READDB2 to create ONLY the PDB.DB2STATS dataset, with no other
Mar 28, 2011 datasets written to the PDB library. It should also be
noted that, to create observations in PDB.DB2STATS, both
DB2STAT0 and DB2STAT1 must have observations; DB2STAT4
can have zero observations.
Thanks to Jane S. Stock, USPS, USA.
Change 29.072 -Documentation comments (ONLY) were updated to show how
UTILBLDP the MACFILEX argument can be used to skip unwanted SMF
Mar 28, 2011 records and subtypes.
Apr 7, 2011 -Some MXGWARN were changed to MXGNOTE and text revised.
Thanks to Nicholas Ward, CentreLink, AUSTRALIA.
Change 29.071 Support for Throughput Manager subtypes 10 and 16 records
EXTPM10 creates new datasets:
EXTPM16S dddddd Dataset Description
EXTPM16J TPM10 TPM10 Description
IMACTPMX TPM16S TPM16S Step Termination
VMACTPMX TPM16J TMP16J Job Termination
VMXGINIT
Mar 28, 2011
Change 29.070 Replaced by Change 29.220.
Mar 24, 2011
Change 29.069 The DB2 Report of TOP users of resources was revised to
ANALDB2T report separately for each DB2 SubSystem.
Mar 24, 2011
Thanks to Ron Wells, American General, USA.
Thanks to Rick Brooks, American General, USA.
Change 29.068 MXG 28.28-29.02. Many ABEND='JCL' jobs had ABEND=' '
BUILD005 and all variables from TYPE26J2 were blank or missing in
Mar 24, 2011 the PDB.JOBS dataset. Change 28.304 unintentionally
output all TYPE26J2 obs with SYSEXEC LE ' ' to the
PDB.NJEPURGE dataset, so they were not used to build the
PDB.JOBS obs. Instead, only the Purge records that have
INREASON IN ('JR','JT','SR') AND SYSEXEC LE ' '
are (now, correctly) output in PDB.NJEPURGE. Fortunately
since purge records with SYSEXEC LE ' ' did NOT execute,
there was no actual loss of resources, except for the
counting JCL errors.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Change 29.067 RACF UNLOAD utility dataset RACF0270 (OMVS) decodes these
VMACRACF ten variables for UID limits:
Mar 28, 2011 ASSIZEMAX ='MAXIMUM*ASID SIZE FOR UID'
CPUTIMEMAX ='MAXIMUM*CPU TIME*FOR UID'
FILEPROCMAX='MAXIMUM*CTIVE/OPEN FILES*FOR UID'
MEMLIMIT ='MAXIMUM*SIZE OF*NON-SHARED*MEMORY'
MMAPAREAMAX='MAXIMUM*MAPPABLE STORAGE*FOR UID'
PROCUSERMAX='MAXIMUM*PROCESSES*FOR UID'
SHMEMAX ='MAXIMUM*SIZE OF*SHARED*MEMORY'
THREADSMAX ='MAXIMUM*THREADS*FOR UID'
Thanks to Ed Webb, SAS Institute, USA.
Change 29.066 Duplicate formats $MG119SU were sourced in FORMATS; the
FORMATS last read was used correctly. The first is now $MG119ST
VMAC119 and is used to decode SSH_FSCMD, SSH FTP Subcommand.
Mar 16, 2011
Thanks to MP Welch, Aprize, USA.
Change 29.065 SMF 111 CTG variable CTGAPLID is conditionally INPUT for
VMAC111 dataset TY111CXI, but always INPUT for TY111GD dataset;
Mar 16, 2011 when it existed in GD but not in CXI, but only when the
GD segment preceded the CXI segment in a physical record,
the value from the GD segment was carried forward into
the CXI dataset. Now, the value is blanked after output
in the GD segment to prevent being carried forward.
Thanks to Gordon E. Griffith, Edward D. Jones, USA.
Thanks to Jim Poletti, Edward D. Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Change 29.064 The INFILE Exit for Compressed CICS and DB2 records did
EXITCICS not always work, sometimes causing an I/O Error message.
Mar 16, 2011 Code that had been moved in testing was restored.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 29.063 Support for CICS/TS 4.2 was available in MXG 29.03, but
UTILEXCL was announced in Change 29.135. This change was Reserved
VMAC110 until the product became GA on June 24.
Mar 15, 2011 These new variables are added to the CICSTRAN dataset:
Apr 2, 2011 ECSEVCCT='SYNCHRONOUS*EMISSION*EVENTS'
Jun 24, 2011 OADID ='ORIGINATING*ADAPTER*ID'
OADATA1 ='ORIGINATING*ADAPTER*ID*DATA 1'
OADATA2 ='ORIGINATING*ADAPTER*ID*DATA 2'
OADATA3 ='ORIGINATING*ADAPTER*ID*DATA 3'
PHNTWKID='PREVIOUS*HOP*DATA*NETWORKID'
PHAPPLID='PREVIOUS*HOP*DATA*APPLID'
PHSTARTM='PREVIOUS*HOP*TASK*STARTIME'
PHSTARCN='PREVIOUS*HOP*TASK*STARTS'
PHTRANNO='PREVIOUS*HOP*DATA TRANS*SEQ NR'
PHTRAN ='PREVIOUS*HOP*DATA*TRANSACTION*ID'
PHCOUNT ='PREVIOUS*HOP*DATA*COUNT'
-UTILEXCL needed revisions because new fields inserted in
the middle of the record that were unknown to UTILEXCL
were not correctly handled in the prior UTILEXCL, which
created an IMACEXCL that had syntax errors that could be
visibly seen (the IBM field after the (last) new field
was NOT preceded by an INPUT statement.) This was NOT
an incompatibility with CICS/TS 4.2, but using the prior
UTILEXCL with CICS/TS 4.2 dictionary records did cause
the syntax error when that new IMACEXCL was used.
-New Statistics STID=19, Dataset CICSMD, exactly the same
fields as STID=6 in this iteration.
-New Statistics STID=20, Dataset CICSMT, exactly the same
fields as STID=5.
-New Statistics STID=29, existing Dataset CICSMDSA
SMSVABYT='ALLOCATED TO*PRIVATE*MEMORY*OBJECTS'
SMSVHBYT='HIDDEN IN*PRIVATE MEMORY*OBJECTS'
SMSVGBYT='HWM USABLE*IN*PRIVTE MEMORY*OBJECTS'
SMSPMOBJ='PRIVATE*MEMORY*OBJECTS'
SMSFGFAI='FROMGUARD*FAILURES'
SMSFGBYT='FROMGUARD*FAILURE*SIZE'
SMSSHBYT='SHARED*FROM*LARGE MEMORY*OBJECTS'
SMSHSBYT='HWM SHARED*IN*LARGE MEMORY*OBJECTS'
SMSSHOBJ='SHARED*MEMORY*OBJECTS'
SMSASPMO='AUX*SLOTS*BACK*64-BIT*PRIVATE*MEMORY'
SMSHSPMO='HWM AUX*SLOTS*BACK*PRIVATE*MEMORY'
SMSRFPMO='REAL FRAMES*BACK*64-BIT*PRIVATE*MEMORY'
SMSHRPMO='HWM REAL FRAMES*BACK*PRIVATE*MEMORY'
SMSLMOBJ='LARGE*MEMORY*OBJECTS'
SMSLPINR='LARGE PAGES*BACKED IN*REAL STORAGE'
-New fields in STID=48, Dataset CICTSQ:
A12TSQDL='QUEUES*AUTO*DELETED'
A12TSCTR='CLEANUP*TASK*RUNS'
-New fields in STID=142, Dataset CICEPG:
EPGEVLNO='EVENT*LOST*NO*ADAPTER'
Change 29.062 -UNKNOWN OPTION VNVERR should have been spelled VNFERR in
ASUMUOWT VMXGUOW. The error only occurs when ASUMUOWT is used for
VMXGUOW TMON CICS input. ASUMUOWT was not called in MXG QA job
Mar 15, 2011 or I would have caught this typo; that will be corrected.
Mar 18, 2011 -Debugging option TRACEUOW(YES) was left on in ASUMUOWT,
causing many thousands of lines FIRST.UOWICCHR= ...
to be printed on the log.
Thanks to Frank Lund, EDB ErgoGroup, NORWAY.
Change 29.061 Variables PCTZAPBY, PCTZALBY, PCTZIPBY, PCTZILBY are
VMACRMFV added to dataset ZRBCPU. These represent the Physical
Mar 13, 2011 and Logical Busy Percentage for ZAAP and ZIIP engines
respectively.
Thanks to Rodger Foreman, Acxiom, USA.
Change 29.060 Two calculations for z196 Est Finite CPI and Est SCPL1M
ASUM113 were revised by John Burg in his March SHARE session:
VMAC113 IF BASIC01 GT 0 THEN DO;
Mar 13, 2011 ESTFINCP=((BASIC03+BASIC05)/BASIC01)*(.57+(0.1*RNI));
END;
IF SUM(BASIC02,BASIC04,0) GT 0 THEN DO;
ESTSCP1M=((BASIC03+BASIC05)/(BASIC02+BASIC04))*
(0.57*(0.1*RNI));
END;
Change 29.059 Support for Beta 93 Version 4.2 new subtypes 25 and 50
EXTYBETF creates two new datasets:
EXTYBETG dddddd Dataset Description
IMACBETA TYBETF BETA25 93 SPOOL ACCESS
VMACBETA TYBETG BETA50 93 WEB BROWSER LOGON/LOGOFF
VMXGINIT
Mar 13, 2011
Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 29.058 Variable CPUCEPTM is now set to a missing value in all of
VMAC30 the datasets that contain it (TYPE30_4,TYPE30_V,TYPE30_5,
Mar 11, 2011 PDB.STEPS,PDB.JOBS, where it was flat out WRONG, and in
PDB.SMFINTRV, where it was validly deaccumulated, but is
not needed). The error, starting in Change 22.326, was
that CPUCEPTM was an ACCUMULATED CPU time and was NOT the
CPU time of the interval, step, or job. In Change 22.326
MXG did deaccumulate it, but only in PDB.SMFINTRV, and in
that process, lost the value of the first interval. IBM
corrected their error, creating a new deaccumulated field
MXG variable CPUCIPTM, added in Change 23.329, which was
kept in all of the above datasets since that 2006 change.
But then in 2007, forgetting that it was completely wrong
I carelessly kept it in PDB.STEPS and PDB.JOBS. While it
might be better to just remove the variable, it is safer
to now set CPUCEPTM to a missing value, and hope/presume
that if/when you notice it is missing, that you will have
first searched CHANGESS and will have found this text to
tell you to use CPUCIPTM instead. Note that CPUCIPTM is
already contained in CPUTCBTM so you would only even want
to use it when examining the components of CPUTCBTM.
An obscure comment in VMAC30 notes that the variables
CPUASRTM CPUENCTM CPUDETTM CPUIFETM CPUEFETM CPUDFETM
and CPUCIPTM are all included in CPUTCBTM.
Thanks to Alfred Holtz, Medco, USA.
Thanks to Charles D'Angelo, Medco, USA.
Thanks to Alex Pasterick, Medco, USA.
Change 29.057 Support for Websphere for z/OS MQ Version 7.0.1 (COMPAT).
EXTY116C -SMF 115 record, dataset MQMMSGDM, new variables:
IMAC116 QMSTPUBS QMSTSTUS QMSTSUB QMSTSUBR QMSTTCB QMSTTCTL
VMAC115 QTSTETHW QTSTETTO QTSTPHIG QTSTPLOW QTSTPNOS QTSTPTO1
VMAC116 QTSTPTO2 QTSTPTO3 QTSTSDUR QTSTSEXP QTSTSHI1 QTSTSHI2
VMXGINIT QTSTSHI3 QTSTSLO1 QTSTSLO2 QTSTSLO3 QTSTSPHW QTSTSTOT
Mar 12, 2011 QTSTTMSG
Apr 19, 2011 -SMF 116 record, datasets MQMACCT1 and MQMQUEUE:
New variables added from both WQ and WTAS segments:
WTASCTCT WTASCTET WTASCTN WTASCTSR WTASSQCT WTASSQET
WTASSQN WTASSTCT WTASSTET WTASSTN WTASSUCT WTASSUET
WTASSUN WTASSUSC WTASSUSL
WQCBCT WQCBET WQCBN WQCLCFD WQCLSUET WQCLSUN
WQCLTOSR WQOPCFD WQOPSUET WQOPSUN WQOPTOSR WQP1TOSR
WQPUBCN WQPUTOSR WQSELCOU WQSELMXL
New MQCFSTAT dataset has one obs with these 5 variables
WQCFCOUN &PIB.4. /**TIMES*IN THE*ROUTINE*/
WQCFSYCN &PIB.4. /**SYNC*REQUESTS*/
WQCFSYET &PIB.4.6 /**SYNC*ELAPSED*TIME*/
WQCFASCN &PIB.4. /**ASYNC*REQUESTS*/
WQCFASET &PIB.4.6 /**ASYNC*ELAPSED*TIME*/
with those statistics for the Coupling Facility, if used,
for each of the five MQ Verbs (variable WQVERB);
OPEN CLOSE GET PUT PUT1
and for each of the thirteen MQ requests (WQREQSTY):
LOCK UNLOCK WRITELC SIGXCF SIGCF READ
WRITE STARTMON STOPMON NEW MOVE MOVEENT
DELETE
but observations are ONLY created in MQCFSTAT if there
are non-zero counts in one of the statistics variables.
Apr 19: VMAC110 QJSTDRE1/3 corrected to QJSTDRQ1/3
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 29.056 Support for MainView MQ (MVMQ) Version 4.4 (INCOMPAT);
VMACBBMQ MXG code had not been updated since 2007 and many new
Mar 13, 2011 fields were inserted in 'E6'x (dataset BBMQQUES) record,
the 'E5'x (dataset BBMQCHAN) record was completely
revised with several new fields, and the 'E1'x (dataset
BBMQQMGR) had new fields added at the end. The VERSREL
value in the 4.4 records contains 4.2, so the logic to
detect MVMQ Version was change to use the Length ENTL
field. This iteration suppresses checking for compress
bit while EXITMNVW is examined for possible error.
Thanks to James Swwinarski, Credit-Suisse, SWITZERLAND.
Change 29.055 JCLUOWV, an example to read DB2 & CICS data that creates
JCLUOWV PDB.ASUMUOW using SAS Views was altered by Change 28.220
Mar 9, 2011 but undocumented; the default ASUMDB2x members that were
%INCLUDed were changed, creating different PDB.ASUMDB2x
datasets. While any or all of the ASUMs are optional, it
was not my intent to create different datasets, so the
default original ASUMs are restored, with this note:
/*ANY OR ALL OF THE BELOW SUMMARIZING ASUMDB2X ARE OPTIONAL. */
/*THE PAIR INCLUDED BY DEFAULT ARE THE ORIGINAL PAIR, KEPT FOR */
/*CONSISTENCY, BUT AS ASUMDB2P CAN BE VERY EXPENSIVE, YOU MIGHT*/
/*NOT WANT TO EXPEND THOSE RESOURCES TO SUMMARIZE PACKAGES, AND*/
/*YOU MIGHT FIND SUMMARIZING DB2STATS WITH ASUMDBSS TO BE BOTH */
/*USEFUL AND CHEAP (SINCE THOSE ARE INTERVAL DATASETS). */
%INCLUDE SOURCLIB(ASUMDB2A); /*BUILD PDB.ASUMDB2A FROM DB2ACCT*/
%INCLUDE SOURCLIB(ASUMDB2P); /*BUILD PDB.ASUMDB2P FROM DB2ACCTP*/
/*%INCLUDE SOURCLIB(ASUMDB2B); BUILD PDB.ASUMDB2B FROM DB2ACCTB*/
/*%INCLUDE SOURCLIB(ASUMDB2G); BUILD PDB.ASUMDB2G FROM DB2ACCTG*/
/*%INCLUDE SOURCLIB(ASUMDBSS); BUILD PDB.ASUMDBSS FROM DB2STATS*/
Thanks to Carolyn Saul, West Virginia Office of Technology, USA.
Change 29.054 -STRING variable length was increased to 1000 to support
ASUMDB2A potentially longer arguments.
ASUMDB2B -Macro variable DSETEXST=NO, defined/set in VMXGINIT, was
ASUMDB2G incorrectly re-defined in VMXGSUM, ASUMDB2A, ASUMDB2B,
ASUMDB2P ASUMDB2G and ASUMDB2P, preventing it from being changed
VMXGSUM to YES by ANALDB2R, the only place it is currently used.
Mar 13, 2011 Re-definitions are now removed from those five members.
With DSETEXST=NO, VMXGSUM calls VGETOBS to determine if
the input dataset exists, gracefully failing was an MXG
message if it doesn't. With DSETEXST=YES, when the
existence is already known, VGETOBS is bypassed, saving
a read of the full input dataset if it happens to be
on tape or in sequential format on disk.
Because the redefinition text was DSETEXST=&DSETEXST,
SAS errors about RECURSIVE REFERENCE to DSETEXST could
have occurred, although (fortunately) none were reported.
Change 29.053 Documentation. Since DB2 Version 7.1, when DB2ACCTP data
TYPEDB2 was moved to SMF 101 Subtype 1, there has been no QWAC
Mar 4, 2011 segment for Packages. The KEEP list for DB2ACCTP still
had variables QWACBSC QWACESC and QWACWLME, which have
been missing values in DB2ACCTP since then. I could drop
them, but if I do, someone out there with an old report
program that referenced them, would then fail, so they
will still be kept (but if you are real picky, you can
easily drop them by putting this macro definition
MACRO _KDB2ACP DROP=QWACBSC QWACESC QWACWLME %
in your IMACKEEP member in your "USERID.SOURLIB").
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 29.052 The newest MONTHxxx fails, z/OS ONLY, SAS 9.1.3 only.
MONTHBLD %CMPRES must be changed to %QCMPRES. As often is the
Mar 3, 2011 case with %MACRO errors, the error message gives no clue:
NOTE: LINE GENERATED BY THE MACRO FUNCTION "SUBSTR".
;SET MON.XXXXXX WEEK1.XXXXXX WEEK2.XXXXXX WEEK3.XXXXXX
___
___
___
180
180
180
ERROR 180-322: STATEMENT IS NOT VALID OR IT IS USED OUT
OF ORDER.
The %CMPRES function was added to print the generated SET
statement, for diagnostics, to verify the results of the
7x7 tests (7 Startdays, 7 Rundays), but was added after
the z/OS MONTHxxx logic verification, and while it works
just fine on SAS 9.2, the 9.1.3 %CMPRES function fails,
inserting a semicolon that terminated the %LET statement.
The stronger %QCMPRES function works on SAS 9.1.3.
May 1: See CHANGE 29.102. Error occurred on SAS V9.2.
Thanks to Kim Tyson, Toyota, USA.
Change 29.051 Variable STORCLAS can be uninitialized, with hex zeroes
VMAC42 for some system datasets (SYS1.MANX,SYS1.PROCLIB); now,
Mar 2, 2011 hex zeros are translated to blanks.
Thanks to John R. Paul, Highmark, USA.
====== Changes thru 29.050 were in MXG 29.02 dated Mar 1, 2011=========
Change 29.050 DB2 IFCID 319, ACCESS CONTROL AUTH EXIT PARMS, specific
FORMATS to IFCID=319 fields, are now decoded and output; three
VMAC102 formats are created to decode three variables.
Change 29.049 The interval DELTATM was not summed when there was more
ASUM113 than one engine for a type of engine causing LPARBUSY
Feb 25, 2011 to exceed 100%. The sum of the DELTATM across engine type
Feb 28, 2011 is now stored in DELTASUM and used for LPARBUSY, while
DELTATM has the interval duration and is used for the
(now corrected) calculation of LPARCPUS.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 29.048 Macro variable MXGCIXT is created and inserted after all
VMXGCICI of the CICS Statistics WORK.INTxxxx datasets have been
VMXGINIT created (summarized), so they could be copied to a
Feb 25, 2011 permanent data library.
Change 29.047 DB2 variables QWACZIS1 QWACZIS2 QWACZIEL QWACZITR are now
VMXGUOW added to PDB.ASUMUOW when DB2ACCT data is found.
Feb 25, 2011
Change 29.046 On z/OS only (a LIBNAME is always needed on ASCII):
DOC if your program starts with an ASUM/TRND member, or it
Feb 25, 2011 invokes VMXGSUM, and the internal macro VGETOBS is used
(to detect the presence or absence of input datasets,
intended to conserve resources and avoid strange errors),
there are two potential exposures:
SAS - if the LIBNAME is on tape, we cannot detect that,
and the PROC SQL will read the entire tape volume(s) to
populate the DICTIONARY.TABLES internal table we use.
WPS - WPS does not populate dictionary.tables until the
LIBNAME(s) are opened, which causes these error messages:
NOTE: No rows were selected
NOTE: RUN has no effect in proc sql ... immediately.
MXGERROR: WEEK.JOBSKED DOES NOT EXIST. VMXGSUM WILL
MXGERROR: BE STOPPED.
NOTE: Procedure SQL step took :
In this case, you must have a LIBNAME statement for each
data library to cause that table to be populated.
Alternatively, you could also use PROC DATASETS
DDNAME=xxxxx; to populate the table.
In both cases, inserting %LET DATAEXST=YES; as the first
SYSIN statement eliminates VMXGSUM's call to VGETOBS to
verify the dataset exists. However, if they don't exist,
that will cause VMXGSUM to then fail for that reason.
Thanks to Kare Martin Torsvik, Ergogroup, NORWAY.
Thanks to Atle Mjelde, Ergogroup, NORWAY.
Change 29.045 TRNDRMFI example TRENDINT should have been INTERVAL.
TRNDRMFI UTILRMFI %IF J LT 5 should have been %IF &J LT 5.
UTILRMFI
Feb 27, 2011
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 29.044 ASM utility to convert a PC "RECFM=U" V/VB/VBS file that
ASMDBLKU was uploaded to z/OS into a readable "RECFM=V/VB/VBS"
Feb 25, 2011 dataset. This is the ASM equivalent of the SAS UDEBLOCK
for sites that don't have a z/OS SAS license.
Change 29.043 -If you needed to rerun a specific day, and you use the
BLDSMPDB AUTOALOC=YES option, the FORCEDAY parameter was not found
Feb 24, 2011 in the macro; it is now properly defined. To rerun with
AUTOALOC=YES, the syntax is forceday=ddmmmyy, where the
ddmmyy is the date to be rerun (e.g., 21feb11).
-If you need to rerun a day and AUTOALOC=YES is NOT used,
specify rerun= the day of the week to be rerun, MON, etc.
Thanks to Cletus McGee, ALFA Insurance, USA.
Change 29.042 NDM-CDI Version 5 records are read without actual errors,
VMACNDM but the test file contained 'XO' records, which printed
Feb 24, 2011 "NDM. HEADER ONLY" messages because no records had been
available for validation. These records are now decoded
and are output in NDMDT dataset.
Change 29.041 Your FEB MONTHly PDB could be missing MON data, if your
VSETMNTH MONTHBLD/MONTHBL3/MONTHASC/MONTHDSK has a %%VSETMNTH(),
MONTHBLD i.e., if the Last Change is 28.125 thru 29.017, i.e.,
MONTHBL3 if it was copied from MXG 28.04 thru 29.01 (yes, that
MONTHDSK new version that was supposed to have fixed the MONTHs).
MONTHASC YOUR MONTHXXX IS SAFE IF IT DOES NOT CONTAIN %%VSETMNTH.
MONTHWEK It depends on the MONTHxxx member, the version it came
Feb 27, 2011 from, and the STARTDAY of your week (MXG default is MON):
NOTE: THERE IS NO ERROR MESSAGE; THE JOB DOES NOT FAIL.
1. IF YOU USE MONTHBLD/MONTHBLD/MONTHASC/MONTHDSK:
The possible combinations that are good or bad:
Using MONTHBLD or MONTHBL3:
From version: MXG 29.01 MXG 28.04-MXG 28.28
(Last Change) Change 29.017 Change 28.125-28.324.
STARTDAY SUN MON SUN MON
VSETMNTH OLD NEW OLD NEW OLD NEW OLD NEW
X ok ok ok ok X X X
Using MONTHASC or MONTHDSK:
From version: MXG 28.04-MXG 29.01
(Last Change) Change 28.125-28.324.
STARTDAY SUN MON
VSETMNTH OLD NEW OLD NEW
ok X X X
X: MON's PDB data will be missing.
The safe correction, of course, is to "drop in" MXG 29.02
before Tuesday's MONTHxxx, but I realize that's unlikely!
To correct, you MUST download the new VSETMNTH file
- VSETMNTH.SAS (ASCII) or VSETMNTH.EBC (z/OS) - and copy
into your tailoring library.
With MONTHBLD/MONTHBL3 from MXG 29.01, the new VSETMNTH
is all that is required.
If your MONTHBLD/MONTHBL3 was from 28.04-28.28, then
you can download the new member and cut your list of
the datasets you create (i.e., from 1st MACRO _DSET to
the end of your MONTHBLx) and replace the default list
in the new MONTHBLx), or you can EDIT your MONTHxxx
(see below) to change the CALL SYMPUT.
With MONTHASC/MONTHDSK from 28.04 including 29.01,
you can download the new member and cut/paste your list
of datasets (see preceding note), or you can EDIT your
MONTHxxx (see below) to change the CALL SYMPUT.
To EDIT/fix MXG's error in MONTHBLD/MONTHBL3 pre 29.01
or the MXG error in MONTHASC/MONTHDSK from 28.04-2901:
Change the one line:
CALL SYMPUT('LASTDAY',PUT(TODAY,WEEKDATE3.));
to
CALL SYMPUT('WEEKDATR',PUT(TODAY,WEEKDATE3.));
The ftp credentials you already have for 28.28 or 29.01
are still valid, so you can either download MXG 29.02 and
copy those new members to your Tailoring Library from it,
or you can download only the specific files you need:
The files with .sas are ASCII for MXG ASCII execution.
The files with .ebc are EBCDIC (to avoid any code page
translation issues), but they must be moved as binary
to a PDS with DCB attributes of RECFM=FB and LRECL=80.
And, what do you do when it after March 1st when you find
this needed correction? Download/EDIT as described in
the preceding paragraphs for your BUILDxxx programs and:
-If the rerun is during the same processing week, then
simply EDIT your MONTHxxx and change the statement
TODAY=TODAY();
to
TODAY='01MAR2011'D;
(as is documented in the ADOCMNTH member).
-If the rerun is not until the NEXT week, then you would
use the MONTHWEK member (z/OS) or the MONTHASW (ASCII)
member (from your current MXG version - it doesn't use
the defective VGETMNTH that created all this flail),
cut/paste your list of datasets to be created, and then
read the last 5 WEEKly PDBs to rebuild your MONTHly.
2. IF YOU USE BLDMSPDB:
You must have the new BLDSMPDB and VSETMNTH, then:
To rebuild the past month's PDB on z/OS or on ASCII
with AUTOALOC=NO (default), but ONLY if you are in the
first week of the new month:
%BLDSMPDB(RUNDAY=NO,RUNWEEK=NO,RUNMNTH=FORCE,
FORCEDAY=01MAR11);
To rebuild the past month's PDB on ASCII with
AUTOALOC=YES (ASCII ONLY), but ONLY if you are in the
first week of the new month:
%BLDSMPDB(AUTOALOC=YES,RUNDAY=NO,RUNWEEK=NO,
RUNMNTH=FORCE,FORCEDAY=01MAR11);
To rebuild the past month when it is beyond the first
week of the month:
With AUTOALOC=NO:
LIBNAME WEEK6 'your sixth week';
%LET USEWEEKS=YES;
%BLDSMPDB(RUNDAY=NO,RUNWEEK=NO,RUNMNTH=FORCE,
FORCEDAY=01MAR11);
With AUTOALOC=YES:
%LET USEWEEKS=YES;
%BLDSMPDB(ALOCWEEK=YES,RUNDAY=NO,RUNWEEK=NO,
RUNMNTH=FORCE,FORCEDAY=01MAR11);
3. IF YOU USE BLDNTPDB:
To rerun the current month, whether during the week with
the first of the month, or a following week, use:
%BLDNTPDB(RUNDAY=NO,RUNNTINT=NO,RUNWEEK=NO,RUNMNTH=FORCE);
To rerun a prior month, you must ensure the correct week
pdbs are allocated to week1 thru week5, and then us:
%BLDNTPDB(RUNDAY=NO,RUNNTINT=NO,RUNWEEK=NO,RUNMNTH=FORCE,
FORCEDAY=01MAR11);
Additional changes were made by this enhancement.
-New macro variable (if you set it to) USEWEEKS=YES:
-drives logic in VSETMNTH to use only the WEEKly PDBs
when the rerun is in the week after the week with the
first of the month.
-allocates LIBNAME WEEK6 because some months need
to read six months of weeklies when a MONTH PDB is
created only from the past weekly pdbs.
-Documentation in BLDSMPDB for RUNMNTH=FORCE, RERUN=YES,
and FORCEDAY='date' are corrected and updated.
-The default WEEKs kept is now 12 in both BLDSMPDB and
VMXGALOC, but I recommend a MUCH LARGER number of WEEK
PDBs be kept for historic reasons, with all of the PDB
datasets (and only a few, if any, kept in MONTHly PDBs).
-I believe only SUN and MON are commonly used for the
Startday, but the below table shows all of the possible
datasets that could have been missing prior to this
change:
Table of which PDB's are missing with bad VSETMNTH:
Eg.: On Feb 1 and Mar 1, which are RUNDAY=TUE, the
table shows that "mon" PDB will be missing from your
MONTH PDB if your week starts on SUNDAY, or that the
"tue" PDB will be missing if MONDAY is STARTDAY, but
in the worst case, it shows six dailies could have
been skipped in building the monthly.
Your RUNDAY = DAY OF 1st of MONTH
Week MON TUE WED THU FRI SAT SUN
Start:
SUN mon tue wed thu fri su-fr ok
MON ok tue wed thu fri sat mo-sa
TUE tu-su ok wed thu fri sat sun
WED mon we-mo ok thu fri sat sun
THU mon tue th-tu ok fri sat sun
FRI mon tue wed fr-we ok sat sun
SAT mon tue wed thu sa-th ok sun
Thanks to Michael Creech, Lender Processing Services, USA.
Change 29.040 Variables MAXVMSIZ and VMDSSIZE in dataset XAMUSR were
VMACXAM incorrectly input as PIB.4. instead of RB.4. so the
Feb 23, 2011 formatted value printed as 1164M instead of 3071M.
While XAM apparently prints 3072M, the actual RB value
in the record, '48BFFFFF'x is only 3221225216 while the
actual bytes in 3072M (megabyte) is 3221225472.
Thanks to Craig Collins, State of Wisconsin DOA, DET, WISCONSIN.
Change 29.039 Format MGRMFCX, dataset TYPE7002 variable R7023CT and
FORMATS dataset TYPE70X2 variable R7024CT, Crypto Processor Type,
Feb 23, 2011 was incorrect, expecting 'F5'x EBCDIC numbers in hex, but
the actual values are hex (e.g.,'05'x); the hex value was
printed; now the decoded '05X:PCIXCC' will be printed.
Thanks to Giuseppe Giacomodonato, EPV Tech, ITALY.
Change 29.038 Variable ASISDCCP in dataset ZRBASI is now a percentage,
VMACRMFV as labeled; and divided by total samples. Previously, it
Feb 22, 2011 was the (numerator) sample count.
Thanks to Scott Wiig, USBank, USA.
Change 29.037 DB2 V9.1, MXG 28.28-29.01, may print false messages about
VMACDB2H INVALID DISTRIBUTED HEADER DELETED. The header is valid,
Feb 21, 2011 but the test added in Change 28.326 (to detect a truly
invalid header that ONLY exists in DB2 V10.1 and that is
to be corrected by APAR PM32425) was off by one byte for
DB2 V9.1 records. For either release, nothing is really
"deleted"; the only impact is that the INPUT of variable
QWHDRQNM, the Requestor Location Name, is skipped, so the
"DELETED" in the message is changed to "QWHDRQNM SKIPPED"
and the V10 APAR is printed in the message text.
Thanks to Lorena Ortenzi, UniCredit Group, ITALY.
Change 29.036 Julian dates of 1999/000 with COMEFROM=7 printed harmless
VMACEDGR messages that the date was invalid, but should have NOT
Feb 18, 2011 printed the message; instead the invalid date is stored
Mar 13, 2011 into RDEXPDCH as character, and RDEXPDTO is set missing,
Mar 20, 2011 and the test covers COMEFROM=7/48/53 now.
Mar 13: DATEDATE=1999/366 now also protected.
Thanks to Douglas C. Walter, Citigroup, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 29.035 SAS compiler error when _NNTSM was invoked to substitute
COMPALLN _NULL_ replacement tokens, and a _NULL_ definition had
VMACNTSM only one space between the macro name and "_NULL_" text:
Feb 17, 2011 MACRO _WNTWFP _NULL_ %%
Inserting an extra blank so that the definition now reads
MACRO _WNTWFP _NULL_ %%
eliminated this error (with full diagnostic options on,
the generated code could be seen to be in error, with the
next line in the source being 'swallowed' into _WNTWFP.)
The error was replicated with other _NULL_'s in VMACNTSM.
All of the VMACxxxx that define _NULL_'s with similar
syntax were revised to eliminate the exposure, and some
members either did not define _Nxxxx or did not have
correct syntax (e.g., the MACRO keyword was missing).
to have two blanks. And, in the process, I discovered
several members did not have correct syntax for their
_NULL_ definitions( the MACRO keyword was missing).
these VMACxxxx members were corrected:
16 DECS 113 HURN SUIN OMVT
WPMO TMVS SVIE AIM3 19 NTSM ZTPM FITA VIOP UNIC ULTM
TPF SUNS SRMH SARR RSDF RSDA PMTR MVCI MRKV MPLX MOUN
MBO INMV IISL GUTS FDR AIXT 97 42 109 CISM
The error occurred with both PC SAS V9.2 and V9.1.3,
but only on Windows (both XP and Seven, 32 and 64 bit).
Thanks to Lars Fleischer, SMT Data, DENMARK.
Change 29.034 Invalid data for datetime variable SMF30RGT caused error
VMAC30 message and hex dump, and left SMF30RGT a missing value.
Feb 17, 2011 Datetime variable SMF30RGT (IXCARM REGISTER event) is
input from two IBM fields, SMF30RGT (the time part) and
SMF30RGD (the julian date part), but while SMF30RGT had
a valid time value, SMF30RGD was null (i.e., hex zeros).
The error is circumvented by inserting double question
marks for the INPUT of SMF30RGT, while IBM will be
contacted to correct their invalid data value in the
Automatic Restart Management (ARM) segment of SMF 30-5.
Change 29.033 Support for IMF Version 4.5 is in place; there were no
VMACCIMS changes in the IMS F9/FA records between 4.4 and 4.5.
Feb 14, 2011
Change 29.032 -Dataset PDB.IPLS now DOES always report a SYSTEM IPL, but
FORMATS previously that was not true. PDB.IPLS is created from
VMAC0 SMF type zero records, but ID=0 are written both when SMF
VMAC90A is started (at SYSTEM IPL), and when SMF is RESTARTED
VMACSMF (after an SMF address space ABEND, I/O error, etc). This
Feb 13, 2011 is NOT new; at least since 1992, member ADOC0 has noted
(albeit obscurely) that the ID=0 doesn't always report a
system was IPL'd.
-A true System IPL writes either an ID=90 subtype 8 (IPL
PROMPT) or ID=90 subtype 10 (IPL SRM). Now, VMAC0 reads
ID=0, ID=90.8 and ID=90.10 records, initially outputting
all in dataset TYPE0, but when TYPE0 is sorted by _S0
(the product sort macro, invoked by BUILDPDB/PD3/TYPS0),
now these two datasets are created:
PDB.IPLS - actual system IPLS - ID=90.8 or 90.10 obs
PDB.IPLSMF - all SMF ID=0 observations.
-But, note that when SMF has to be restarted, there were
SMF records that could not be written and were lost, and
no ID=7 record would have been written.
-VMACSMF required update because SMF ID=90 records do not
have their subtype in the standard SMF header.
-Cosmetic. TYPE90nn datasets now have variable CMDMVS to
identify which command created the record, and CMDMVS is
formatted with MG090CM to describe the command.
-Format MG090CM was updated for new commands.
-These "bogus IPL" events were overlooked because IBM has
done such a fine job in those 19 years to eliminate
unscheduled IPLs, that tracking them became unimportant!
It was only after SMF ABENDs due to a non-IBM product
required restarting the SMF address space that this need
to redesign MXG's PDB.IPLS dataset surfaced.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 29.031 DB2 V9.1 only; most QGBxxx variables in DB2GBPST were not
VMACDB2 correct; MXG had correct INPUT for V8.1 and V10.2 but did
Feb 9, 2011 not have a separate INPUT segment for 9.1, and MXG missed
the restructure in DB2 V9.1.
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 29.030 -For DB2 connections (DBMDPTYP='DSN', variable DBMDACCT is
VMACTMDB input and kept in TMDBDB2 dataset; for Client connections
Feb 9, 2011 these variables are now kept in TMDBDB2 dataset:
Feb 18, 2011 DBMDPLAT $EBCDIC18. /*CLIENT*PLATFORM*/
DBMDAPPL $EBCDIC20. /*CLIENT*APPLICATION*NAME*/
DBMDATID $EBCDIC8. /*CLIENT*AUTH*ID*/
DBMDSFLN &PIB.1. /*DDCS*ACCOUNT*SUFFIX*LENGTH*/
DBMDSUFX $EBCDIC200. /*DDCS*ACCOUNT*SUFFIX*/
-TMDB Version 4.1 BF/BG/BH/BI/BJ/BK/BL/BM records were off
by 2 bytes, causing DATABASE NAME and other fields to be
misaligned.
-Feb 18. Revisions to BI record's restructure.
Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA.
Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA.
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 29.029 Variable KW18SP03 was input but not kept nor labeled.
VMAC80A
Feb 9, 2011
Thanks to Kim Westcott, NYS Office of Technology, USA.
Change 29.028 Yet another NDM 'RT' subtype INPUT EXCEEDED error because
VMACNDM the records do not match the documentation, offsets are
Feb 8, 2011 inconsistent (PACCT/SACCT sometimes -3, sometimes +1),
ACCT values that are not EBCDIC, two segments after ACCT
that are undocumented, with wide variances in the data
from sites running the same CDI versions, so this change
stops reading at the end of the fixed portion of the data
record, and only looks for the CPUTIME= text string at
that point in the record. If you REALLY, REALLY, need
the NDMRT variable data, or the undocumented fields to be
decoded, be prepared to open a support issue with the CDI
vendor and have them contact me with their DSECT/data.
Change 29.027 Cosmetic. Several variables were incorrectly spelled in
ADOC110 the documentation of CICS variables.
Feb 7, 2011
Thanks to Clayton Buck, UniGroup, USA.
Change 29.026 Support for zVM APAR VM64794 adds variables to dataset
VMACVMXA VXMTRSYS, and new format $MGVXENS to decode new variable
Feb 11, 2011 SYSESTAT (Ensemble Status).
Thanks to Al Holtz, MEDCO, USA.
Thanks to Frank Bright, MEDCO, USA.
Change 29.025 Small negative values for CPUUNITS in type 30 subtype 4
VMAC30 records have been observed in steps with CPUTCBTM=0, when
Feb 7, 2011 the calculated ZIPUNITS (using normalized CPUZIPTM) is
Nov 3, 2011 greater than the SM30CSUL (original CPU+zIIP+zAAP units).
While not significant, MXG now forces CPUUNITS=0 when
CPUTCBTM=0. The maximum negative CPUUNITS value was -169,
but with LOSU_SEC=30018, that is only 0.009 CPU seconds.
Nov 3: Original text corrected; negative CPUUNITS weren't
set to zero, but CPUUNITS was set to zero if CPUTCBTM was
zero. So small negative values (-1.59 in one record in 8
million type 30s) could still occur if CPUTCBTM non-zero.
And, they printed a debugging message with _N_= CPUUNITS=
that should have been and is now disabled.
Change 29.024 MXG-created variables INREASON and SOURCE were blank when
VMAC26J2 INDEVICE=Nnnn.RDm and INTRDR=' ', printing messages that
Feb 5, 2011 INREASON NOT DECODED. INREASON='RD' and SOURCE=INDEVICE
Mar 24, 2011 is now set. INREASON and SOURCE are "my" variables that
were only used in understanding NJE Purge Records and are
not actually used for anything.
Mar 24: SOURCE=INDEVICE wasn't set for INTRDR='Y'.
Thanks to Jack Schudel, University of Florida, USA.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Change 29.023 Using GTF input, IFCID 3 (DB2ACCT) observations were not
VMACDB2 output, and a (spurious) INVALID PROD section message was
Feb 5, 2011 printed. The OFFSMF value has to be changed when GTF is
input, but the logic for ID=101 SUBTYPE=0 was incorrect.
Thanks to Tony Curry, BMC, USA.
====== Changes thru 29.022 were in MXG 29.01 dated Feb 4, 2011=========
Change 29.022 After Change 28.146 (MXG 28.04+), Buffer Hit Ratio on the
VMXGDBSS %ANALDB2R(PDB=SMF,...) statistics reports were 100 times
Feb 4, 2011 too large. In MXG-built datasets BPHITRAT is a fraction
(e.g., .952), but in DB2PM reports IBM prints 95.2. But
Change 28.146 incorrectly multiplied by 100 when creating
the PDB.ASUMDBSS dataset, and then ANALDB2R multiplied.
This change restores the correct fractional value in the
ASUMDBSS dataset and lets ANALDB2R still do the multiply.
Thanks to Ron Wells, American General, USA.
Thanks to Rick Brooks, American General, USA.
Change 29.021 Variables SMF89DTO and SMF89HOF were accidentally removed
VMAC89 from dataset TYPE892, and should not have been. Since
Feb 4, 2011 they are needed by Al's LCS Product, MXG 29.01 refreshed.
Mar 12, 2011 Mar 12: Variables SMF89SIF,SMF89LPV,SMF89LCR are kept.
====== Changes thru 29.020 were in MXG 29.01 dated Feb 3, 2011=========
Change 29.020 The definition of MACRO _NEDA, to null all datasets, was
VMACEDA missing the MACRO preceding the _WEDAxxx token.
Feb 3, 2011
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 29.019 Sample ACF2 reports looked for PDB.ACF2ARR when the real
ANALACF2 dataset created by TYPSACF2 is named PDB.ACF2AR.
Feb 3, 2011
Thanks to Vitullo Carmen, State of Delaware, USA.
Change 29.018 Calculation of MEMP for z196 now subtracts the two
ASUM113 counters EXTND152 and EXTND155, per John Burg's SHARE
VMAC113 paper, which I had overlooked since last August.
Feb 3, 2011 BUT: FEB 18: The revised calculation was ONLY in the
Feb 18, 2011 VMAC113 in 29.01; I forgot the calculation is repeated
for the z196 code in ASUM113 until today when it was
discovered, because, without the correction, the RNI
values for z196 were larger than for the same workload
on the z10 when they should be about the same.
Thanks to Meral Temel, Garanti Teknoloji, TURKEY.
Thanks to Adnam Can, Garanti Teknoloji, TURKEY.
Change 29.017 -SERIOUS: MONTHBLD/MONTHBL3/MONTHASC in 28.28 will skip
MONTHBLD reading the last day's PDB library (the JAN 2011 MONTH
MONTHBL3 will be MISSING the MON PDB's observations).
MONTHASC This new statement added by Change 28.324
ADOCMNTH CALL SYMPUT('WEEKDATR',(PUT(LASTDAY,WEEKDATE3.)));
BLDSMPDB MUST be corrected to:
Feb 3, 2011 CALL SYMPUT('WEEKDATR',(PUT(TODAY,WEEKDATE3.)));
That is the permanent correction.
-BUT, to RERUN JAN 2011 NOW, since it is already Feb 2,
you must ALSO replace the existing statement
TODAY=TODAY(); with
TODAY='01FEB2011'D.
just for the JAN REBUILD (and then restore that statement
before you run the next month's build).
MONTHBLx normally must execute on the 1st day of the
next month; but comments in MONTHBLx point to ADOCMNTH,
for instructions on how to rerun on a different day of
the month; as long as you rebuild during this week,
there is no change needed to the JCL for the JOB.
If you don't see this until NEXT week, then you need
to read the instructions for the required JCL change
when you need to rebuild a MONTHly in a later week
than the normal week with the 1st day of the month.
-BLDSMPDB: LIBNAME WEEK1 NOT FOUND when runmnth=yes. Can
be circumvented by adding LIBNAME WEEK1 statement with
this syntax to rebuild JAN 2001:
libname week1 'c:\mxg\week1\';
%bldsmpdb(runday=no,runweek=no,runmnth=force);
An undocumented requirement of VSETMNTH needs WEEK1,
which is now LIBNAME'd to the same directory as WEEK.
-I personally apologize for my failure to validate these
changes made by MXG Change 28.324.
-Cosmetic, but possibly confusing. The %PUT statement
that prints the date selections printed "LT", but the
actual and correct test is for "LE".
Thanks to Robb Hermes, Sentry Insurance, USA.
Thanks to Wanda Prather, FRTIB, USA.
Change 29.016 When the _SMF macro was redesigned to store DB2 IFCID in
VMACSMF SUBTYPE, and READDB2 was revised to generate tests using
Feb 2, 2011 the SUBTYPE instead of IFCID, the _DB2GTF macro was not
updated, so %READDB2(INFILE=GTF,IFCIDS=xxx) failed to
output any observations. Macro _DB2GTF is now revised.
Thanks to Tony Curry, BMC, USA.
Change 29.015 Support for Version 7, which (COMPATIBLY) added three
VMAC115 sets of eight variables providing compression statistics,
Feb 1, 2011 one set for each of the three algorithms, although only
the first algorithm's variables are currently populated.
Thanks to Martyn Jones, Euroclear, BELGIUM.
Change 29.014 A new "exit", macro variable &EOFVMXA, for MWINPUT file,
VMACVMXA it inserted at the EOF of reading that MONWRITE data so
VMXGINIT users can take action if the input file is empty or has
Jan 29, 2011 invalid (no Control Record) contents. MONWRITE data is
ftp'd to the MXG platform, but an ftp failure causes an
empty file, which MXG processes without error, but that
has not observations created; that is reported in MXG's
"SUCCESSFULLY READ" message as having zero records.
This exit allows you to insert your own code to detect
there was a failure and you create your own log message
and then ABORTing the MXG job to externalize the error.
For example, the exit could be used with this syntax:
%LET EOFVMXA=
%QUOTE(
IF NRDRRECS LE 0 OR NRCRTOTL LE 0 OR
NRBYTOTL LE 0 THEN DO;
PUT ' ';
PUT '#####################################';
PUT 'ERROR: Z/VM MONWRITE FILE IS INVALID.';
PUT '#####################################';
PUT '>>>> CONTACT z/VM Support ON-CALL <<<< ';
PUT '#######################################';
PUT '# DETAILS:';
PUT '#######################################';
PUT //" MXG &MXGVERS FOUND THESE COUNTS:"
//+5 'THERE WERE ' NRDRRECS ' MONITOR RECORDS '
//+5 'FROM ' NRCRTOTL ' CONTROL RECORDS WHICH '
//+5 'CONTAINED ' NRBYTOTL COMMA15. ' BYTES, ( '
NRBYTOTL MGBYTES. 'B)';
PUT '#######################################';
PUT '#######################################';
ABORT ABEND 16;
END;
ELSE
);
%INCLUDE SOURCLIB(TYPEVMXA);
-Note that after your DO/END group, the "ELSE" is required
because the exit is inserted ahead of an existing PUT.
-Also note that the first line of the sample PUT statement
has double quotes around the text; this is required so
that the &MXGVERS macro variable's value is printed. With
single quotes only the text MXGVERS would be printed.
Thanks to Frank Bright, MEDCO, USA.
Thanks to Frank Bright, MEDCO, USA.
Change 29.013 -Variable CPCGRPLM in ZRBCPU is only four bytes but MXG
VMACRMFV input as 8 bytes; the commented +4 is moved ahead of the
Jan 30, 2011 input and the informat changed to PIB4.
-Variable LCPUPOLR was incorrectly input from two bits in
the first byte of LCPUCHIN; it is the last bit of first
byte and first byte of second byte (which is now input
and kept as LCPUCHI2).
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 29.012 Support for Endeavor Version 14 (INCOMPATIBLE because MXG
VMACENDV did not test the segment length and 20 bytes were added),
Jan 31, 2011 causing many missing variables in ENDVERAC dataset. The
fields added are now decoded and seven variables created.
Thanks to Rob D'Andrea, CIS, ENGLAND.
Change 29.011 Cosmetic. Variables with DATETIME value were stored as
VMACIMS length 5 instead of length 8, which can truncate times
ASUMSYTA up to 4 seconds.
VMACBE91 DATASET MEMBER VARIABLE
VMACCYFU ASUMTAPE ASUMSYTA REALMSMF
VMAC28 BETA91C VMACBE91 BE91CSST
VMACPMTR PERFMETR VMACPMTR STARTIME
VMACPW PWPDPD VMACPW ENDTIME
VMACSHDW PWPDPDI VMACPW ENDTIME
VMACTMVS SHADOW05 VMACSHDW SM05LGTM
VMAC90A TMVSCO VMACTMVS IPLTIME
VMACVMXA TYPE9033 VMAC90A SMF9033T
VMACXAM TYPE9034 VMAC90A SMF9034T
Jan 28, 2011 VXSYTSPT VMACVMXA SRXATOD
XAMSYVSW VMACXAM VQSCTTOD
Change 29.010 Variables NDMPRCNM, NDMPRCNO, and NDMSTEP were not kept
VMACNDM in all datasets where they exist in the "NDMPRC" header
Jan 25, 2011 or in the "Record" data segment; the table in comments at
the top of VMACNDM has been updated with a new column to
identify the datasets that have those variables, and all
datasets that are decoded now contain these variables.
Thanks to Michael Oujesky, Bank of America, USA.
Change 29.009 VMXGUOW fails if //CICSTRAN or //DB2ACCT is on tape, with
VMXGUOW MXG 28.06 thru MXG 28.28, but the error is circumvented
Jan 24, 2011 if you add LIBNAME statements to tell MXG it's on tape:
Jan 31, 2011 //SYSIN DD *
LIBNAME CICSTRAN V9SEQ;
LIBNAME DB2ACCT V9SEQ;
%LET PCICTRN=CICSTRAN;
%LET PDB2ACC=DB2ACCT;
%LET MACKEEP= MACRO _NOOBS % MACRO _YESOBS %
%INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);
-Prior to Change 28.204, VMXGUOW only tested existence of
the _Ldddddd dataset token, but in 28.204, a test for the
existence of that LIBNAME was added (so we could tell you
what you did wrong when you didn't have one). But under
z/OS, if the LIBNAME had not been referenced in this SAS
session, it is not in DICTIONARY, and MXG fell thru to
use WORK for the LIBNAME, but as WORK.CICSTRAN did not
exist (your data was in CICSTRAN.CICSTRAN on tape), MXG
failed with NOT FOUND BY VARIABLES and MXGWARNS.
-In this revision, the EXTFILES table is scanned and if
the &PCICTRN "ddname" is found, _LCICTRN is set to
CICSTRAN. Likewise, _LDB2ACC and _LMONTSK are set to the
normal defaults if not found.
-In all cases, if the LIBNAME pointed to does not exist,
VMXGUOW will still fail.
Thanks to Hugo L. Michel, Prince Georges County, MD, USA.
Change 29.008 -WEEKBLD/MONTHBLD: to eliminate NOTSORTED errors, MXGNOBY
VMXGINIT is now specified in VMXGINIT so there will be no testing
BLDSMPDB of the sort order of the input, and no NOTSORTED error.
Feb 3, 2011 -BLDSMPDB: SORTEDBY=NO is now specified as the default.
(Also, LIBNAME=WEEK1 was in error and changed to WEEK.)
-Previously, you had to define MXGNOBY with this statement
%LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;
in your //SYSIN DD, to disable the sort testing and the
interleave of input observation in sort order. That will
still work fine, but no longer needed with this change.
Although I can't see a reason why you would want to go
back to the NOTSORTED exposure, you can redefine macro
MXGNOBY as null with this syntax to reinstate sorting:
%LET MXGNOBY= ;
-The exposure occurs when MXG has to change the sort order
of a dataset when it is built, and that dataset with new
sort order is combined in WEEKBLD/MONTHBLD with datasets
that were created with the previous sort order.
-The only reason MXG ever changes the sort order is when
the initial order was insufficient to remove duplicates
with the NODUP option of PROC SORT. Errors can occur if
your old WEEKBLD has the old sort order (TYPE72DL in MXG
28.28), or if MXG failed to update the new order in its
WEEKBLD/MONTHBLD member (DB2STATS in MXG 28.28)
-MXG does not require the WEEKLY and MONTHLY datasets to
be sorted; no report programs should ever expect ordered
data as there is no way to guarantee someone else didn't
sort the dataset after it was first created.
-Building sorted output is only a possible performance
benefit: if subsequent programs happen to use the same
order in their PROC SORT, SAS is smart enough to bypass
the unneeded sort, and that was the original purpose for
creating WEEKBLD/MONTHBLD in sort order. And, because
the "daily" datasets were already sorted, the WEEKBLD and
MONTHBLD programs preserved that sort order with a BY
statement, without re-sorting.
-However, it turns out that disabling the sort order test
and building the output as the concatenation of the input
datasets instead of interleaving observations to preserve
the sort order is a REAL performance benefit: benchmarks
show a reduction of about 12% of the CPU time with the
MXGNOBY enabled.
Change 29.007 Documentation if CICSTRAN variables are EXCLUDEd/DROPPED.
ASUMUOW This isn't new behavior, and has been in place long time.
ASUMCICX For ASUMUOW to execute, these BY-VARIABLES are REQUIRED:
Jan 21, 2011 TRANNAME STRTTIME ENDTIME NETSNAME
UOWID UOWIDCHR UOWTIME
There is no circumvention; ASUMUOW fails without them.
These KEPT variables from CICSTRAN aren't required for
execution, but MXGWARN messages will be printed if
these variables do not exist in your CICSTRAN:
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
This list is defined in MACRO _KUOWIDC, which you can
redefine to keep only your variables to eliminate the
MXGWARN messages.
For ASUMCICX to execute, these BY-VARIABLES are REQUIRED:
APPLID OPERATOR USER TERMINAL STRTTIME TRANNAME
SYSTEM SHIFT
If any do not exist, ASUMCICX fails.
This list is defined in MACRO _BSUCICS and some can be
removed, but you could end up with useless output if,
for example, you didn't keep STRTTIME.
If some of these variables are not kept, you can redefine
_KUOWIDC and _BSUCICS to list only those that exist.
For example, these variables are removed from CICSTRAN:
USER OPERATOR TERMINAL USERCHAR
Then you would add the MACRO _KUOWIDC and _BSUCICS into
the %LET MACKEEP= in your current JOB:
//UOWCICX EXEC MXGSAS92
//CICSTRAN DD DSN=YOUR.CICSTRAN,DISP=SHR
//DB2ACCT DD DSN=YOUR.DB2ACCT,DISP=SHR
//PDB DD DSN=NEW.ASUMUOW,DISP=(,CATLG),...
//SYSIN DD *
%LET PCICTRN=CICSTRAN;
%LET PDB2ACC=DB2ACCT;
%LET MACKEEP=
MACRO _KUOWIDC APPLID LUNAME SYSTEM %
MACRO _BSUCICS APPLID STRTTIME TRANNAME SHIFT %
MACRO _NOOBS % MACRO _YESOBS %
;
%INCLUDE SOURCLIB(ASUMUOW);
%INCLUDE SOURCLIB(ASUMCICX);
Thanks to Hugo L. Michel, Prince Georges County, MD, USA.
Change 29.006 Variables DVRTBV01-DVRTBV32, Returned Borrowed Volumes,
VMACBVIR were incorrectly formatted $MGBVIPT but $MGBVIPO is the
Jan 21, 2011 correct format to decode when printed.
Thanks to Doug Boettcher, Atco I-Tek, CANADA.
Change 29.005 Documentation of INTERVAL= change in default RMFINTRV.
RMFINTRV INTERVAL=DETAIL in MXG 27.27 became INTERVAL=QTRHOUR in
Jan 19, 2011 MXG 28.01, Change 28.046, in MXG default RMFINTRV member,
but that was not documented, carelessly, but also because
I didn't think anyone used MXG's default RMFINTRV member.
I expected each site to have their own tailored RMFINTRV
with both INTERVAL= and WORKnn= (maps Service Classes to
WORKLOADs) definitions, and thus my default would only be
used by new sites, and only before they read the INSTALL
instructions to tailor those RMFINTRV definitions, so I
could change the interval with impunity. Well, almost!
I replaced DETAIL with QTRHOUR because DETAIL creates an
observation for every RMF start, including those short
interval at each IPL that have VERY high CPU Busy and are
outliers on normal interval graphs and reports, whereas
INTERVAL=QTRHOUR creates equal intervals and smooth data.
But, with DETAIL, you get an observation with the exact
STARTIME of each interval, and if SYNC59 is in use, those
startimes were of 59:00 14:00 29:00 44:00. But SYNC59=YES
is the default for Real Intervals, so changing from the
INTERVAL=DETAIL to INTERVAL=QTRHOUR, for SYNC59 sites,
changed their STARTIMEs to 00: 15: 30: & 45: when they
"dropped-in" MXG 28.28 after MXG 27.27. Tailoring their
RMFINTRV with INTERVAL=DETAIL restored original values.
Change 29.004 ISO format dates with 19990000 for "never expire" are now
VMACEDGR detected and the DATE variable is set missing.
Jan 20, 2011
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 29.003 If you have ancient JCL with //SASAUTOS DD DSN=&&NULLPDS,
VMXGGETM MXG 28.28 UTILGETM ran much longer (10x) because it did
Jan 19, 2011 not read the (new in 28.28) %DATATYP macro function from
the SAS-provided AUTOCALL PDS. The ERROR message didn't
stop the read of the large SMF file, but the message
wasn't the expected APPARENT MACRO %DATATYPE NOT FOUND.
Because of the way %DATATYP was used, the error was:
ERROR: Character operand was found in the %EVAL function
... where %DATATYP(&NRECORD) NE NUMERIC ....
The JCL &&NULLPDS token was removed many MXG versions ago
for unrelated problems and lack of need, but I was not
aware that the &NULLPDS stopped the AUTOCALL search, but
only recent MXG versions actually use macros (%TRIM) from
that library. But the %DATATYP was added ONLY to detect
that you had mistyped an alphabetic text for NRECORD=,
and only in your own %VMXGGETM invocation (UTILGETM has
NRECORD=50), so we shot ourselves in the foot adding it.
And ONLY to prevent a less-than-clear warning message.
DATATYP is no longer used; the logic is in a data step.
Change 29.002 -APAR OA31615 was NOT supported by MXG 28.28 as claimed.
VMAC89 That APAR will cause many INVALID SMF89CTZ log messages,
Jan 20, 2011 but the job does NOT ABEND (unless the log fills!).
Jan 21, 2011 -MXG detection of records with Invalid Intersect Segments
Feb 3, 2011 had no limit on the number of Invalid Record messages,
but also falsely detected some valid records as invalid.
The MXG test was corrected so only true Invalid segments
are detected, and only the first 3 are printed on log.
-But, feedback from IBM has clarified the new intersect
data in new TYPE89I dataset, and MXG was wrong to carry
the PRODxxxx variables from the Usage Data Section; those
variables were removed from the KEEP= list, and from the
Sort Order in MACRO _BTY89I, which now uses the CPO-CPI
and IPO-IPI variables to order and remove duplicates, and
is sequenced SMF89UST SMF89IST within those variables.
-Unrelated to the APAR, these variables in subtype 2 have
never been populated and are no longer kept in TYPE892:
MACHTIME SMF89UET SMF89UST
Thanks to Jim Poletti, Edward D. Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Thanks to Scott Barry, SBBWorks Inc, USA.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 29.001 Support for SMF 111 IPIC now creates obs in TY111CXI.
VMAC111 No observations were created because MXG incorrectly had
Jan 19, 2011 them to be in CTGRECID=2 when they are CTGRECID=7, so the
Jan 24, 2011 code for IPIC was relocated to that correct subtype, and
obs are now created.
-Warning added when a new subtype is detected.
-Change 28.329 for SMF 111 was NOT included in 28.28 as
originally claimed.
Thanks to Jim Poletti, Edward D. Jones, USA.
Thanks to Jeana M. Bechtel, Edward D. Jones, USA.
Thanks to Gordon E. Griffith, Edward D. Jones, USA.
LASTCHANGE: Version 29.
=========================member=CHANGE28================================
/* COPYRIGHT (C) 1984-2011 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 28.28 is dated Jan 18, 2011, thru Change 28.331.
MXG Newsletter FIFTY-SEVEN is dated Jan 18, 2011.
Prelim MXG Version 28.28 was dated Jan 12, 2011, thru Change 28.326.
Interim MXG Version 28.09 was dated Jan 11, 2011, thru Change 28.325.
MXG Version 28.08 was dated Dec 13, 2010, thru Change 28.297.
MXG Version 28.07 was dated Nov 5, 2010, thru Change 28.265.
MXG Version 28.06 was dated Oct 7, 2010, thru Change 28.239.
MXG Version 28.05 was dated Aug 18, 2010, thru Change 28.187.
MXG Newsletter FIFTY-SIX was dated Aug 18, 2010.
First MXG Version 28.05 was dated Aug 17, 2010, thru Change 28.186.
MXG Version 28.04 was dated Jul 5, 2010, thru Change 28.152.
MXG Version 28.03 was dated May 25, 2010, thru Change 28.114.
MXG Version 28.02 was dated Apr 14, 2010, thru Change 28.081.
MXG Version 28.01 was dated Mar 9, 2010, thru Change 28.047.
MXG Version 27.27 was dated Jan 20, 2010, thru Change 27.361.
MXG Version 27.27 was the 2010 "Annual Version".
MXG Newsletter FIFTY-FIVE was dated Jan 20, 2010.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 28.28 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 28.28.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================
I. MXG Version 28.28 dated Jan 18, 2011, thru Change 28.331.
Major enhancements added in MXG 28.28, dated Jan 18, 2011
TYPEDB2 28.326 Invalid DB2 V10 Distributed Header protected in MXG.
There will be an IBM APAR, but this change is needed
to avoid the ABEND with earlier MXG versions, so, now
MXG 28.28 IS NOW REQUIRED FOR DB2 V10.1
to ensure your daily jobs doesn't ABEND.
APAR PM32425 has been opened, no PTF as of Feb 21.
WEEKBLD 28.324 Weekly exposure to DATASET TYPE72DL NOT SORTED.
MONTHBLD 28.324 Monthly exposure to DATASET TYPE72DL NOT SORTED.
BLDSMPDB 28.324 BLDSMPDB exposure to DATASET TYPE72DL NOT SORTED.
-If you have tailored those members and TYPE72DL is
built, you need to EDIT those members per the text
in that Change to avoid the possible ABEND of your
weekly or monthly build jobs.
EXITCICS 28.298 EXITCICS decompresses SMF 100,101,102,110 and 112.
MXG enhanced INFILE exit for CICS now supports DB2.
TYPE89 28.331 INVALID DATA FOR SMF89CZT if APAR OA31615 installed.
TYPE111 28.329 CTG records had zero observations in TY111CXI "IPIC".
JCLINSTT 28.328 Complete JCL example to ftp/unterse/install on z/OS.
TYPENDM 28.327 Connect Direct/NDM 'RT' record INCOMPATIBLY changed.
TYPE102 28.325 DB2 SQL-text variables only 100 bytes if COMPRESS=NO.
TYPEIMSA 28.311 Support for IMS/DBCTL transactions in IMSTRAN.
TYPEIMS7 28.310 Support for IMS/DBCTL transactions in IMS0708.
TYPE0 28.313 Variable CVTTZ in TYPE0 could be one second wrong.
BUILDPDB 28.305 PDB.NJEPURGE did not contain all NJE-variables.
ANALDUPE 28.308 Removal of Duplicate SMF (or any) records.
TYPEVMXA 28.315 PFXCPUAD in VXSYTCUM is the LCPUADDR, no CPUID.
TYPEVMXA 28.307 Short LINUXKRNL MONWRITE record caused errors.
UTILGETM 28.312 No Reporting Class data in SMFSMALL with NRECORD=10.
TYPE89 28.304 SMF 89 with no usage segment INPUT EXCEEDED error.
TYPE30 28.302 TYPE30MU duplicate records exist, non-dupes removed.
TYPETCP 28.300 TYPETCP (SMF 118) Port Numbers (Dec) wrong on ASCII.
TYPE70EN 28.299 Wrong values for CPUID=0 in PDB.TYPE70EN.
Major enhancements added in MXG 28.08, dated Dec 13, 2010
TYPE119 28.293 Support for OpenSSH SMF 119 subtypes 96-98.
TYPE113 28.279 "Near duplicate" ASUM113 intervals are corrected.
TYPE89 28,282 Support for APAR OA31615, adds zIIP/zAAP CPU times.
TYPENMON 28.275 Support for NMON FCREAD/FCWRITE/XFERIN/XFEROUT record
TYPETNG 28.273 Support for more than 9999 instances in CA NSM/TNG.
TYPETMVT 28.287 Support for ASG-TMON for VTAM subtype 'SX' record.
TYPE110 28.285 CICS Statistics Subtype 2 STID=143 corrected.
ASUMUOWT 28.284 ASUMUOWT (for ASG-TMON MRO) revised to use VMXGUOW.
ASUMCICR 28.281 Count/average response time by DATE for each APPLID.
DB2ACCT 28.277 NETSNAME/UOWTIME only created for QWHCATYP=4 (CICS).
TYPE89 28.272 SMF89HOF/SMF89DTO for SCRT don't use last 3 nybbles.
WEEKBLD 28.269 TYPE72DL NOT SORTED after Clock Set Back.
ANALDBJS 28.290 DB2 analysis adds JESNR and REAdTIME to DB2ACCT.
TYPE6156 28.289 Variables GATLIMIT and GATCNT added to TYPE6156.
UTILNPRT 28.268 Identify non-print chars, for SAS Enterprise Guide.
Major enhancements added in MXG 28.07, dated Nov 5, 2010
TYPEDB2 28.264 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE:
MXG 28.06 was required to process the V10 data, but
now, MXG 28.07 has full support plus the below
documentation.
TYPEOMMQ 28.263 Support for IBM/OMEGAMON XW MQ flat file (INCOMPAT)
TYPEMIM 28.262 Support for CA MIM RESOURCE SHARING R11.7 (COMPAT)
GRAFCEC 28.261 SAS/GRAPH example charts CEC Utilization by engine
TYPETPX 28.260 IP address and Port Number now decoded in TPX SMF.
UTILEXCL 28.259 Spurious "WRONG LENGTH OF 200 FOR CMRDATA"
TYPE120 28.258 Support for WebSphere ID=120 SUBTYPE=20 records
ANALID 28.257 ERROR: VARIABLE IDANDSUM ... with PDB,DISP=OLD
EXITCICS 28.251 ASMA144E Begin-to-continue due to char in col 72.
READDB2 28.250 COPYONLY logic now works.
VMXGSUM 28.249 VMXGSUM enhanced with MODE and MEDIAN statistics
TYPE110 28.247A Example using _Kdddddd to create new datasets revised
TYPE30 28.246 New CPITCxTM/CPISRxTM wrong in MXG 28.06.
TYPE7072 28.246 CP eng 64-95 vars shouldn't have been kept in TYPE70.
TYPESTC 28.244 STC/STK/Oracle VSM user SMF records support revised.
TYPE7072 28.242 In-Ready Work Unit SMF70U00-U15, etc were all wrong.
Major enhancements added in MXG 28.06, dated Oct 7, 2010
TYPEWSMQ 28.233 Support for WebSphere MQ Version 7 Accounting Data
TYPEDB2 28.222 ITRM only, DB2STAT4 NOT SORTED ERROR.
ASUMDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
TRNDDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
EXITCICS 28.223 Support for DB2 V10 Compressed SMF records.
DFH$MOLS 28.223 JCL example to use IBM CICS decompression utility.
TYPEITRF 28.227 INPUT STATEMENT EXCEEDED RECORD LENGTH type=17x.
TYPEIMFS 28.193 Full support for IMF records in SMF format.
TYPE113 28.226 Variable LPBUSY,LPARBUSY replaced LPARCPU.
TYPE74 28.212 TYPE74ID (small) created, saves pass of TYPE74CA.
Major enhancements added in MXG 28.05, dated Aug 18, 2010
The z196 processor with more than 64 engines REQUIRES MXG 28.05.
A z196 with LESS THAN 64 engines DOES NOT require MXG 28.05, as
long as the operating system is z/OS 1.11 or earlier.
z/OS 1.12 REQUIRES MXG 28.05.
DO NOT USE MXG 28.04 WITH z/OS 1.12 RMF data records.
IBM Maintenance APARs OA30563,OA33976 REQUIRES MXG 28.05.
Many 28.175 Support for z/OS 1.12 (REQUIRES MXG 28.05).
DO NOT USE MXG 28.04 WITH z/OS 1.12 DATA - INCOMPAT.
TYPE70 28.175 Support for z196: REQUIRED ONLY WITH GT 64 ENGINES.
(Lots of new data added compatibly.)
TYPE113 28.166 Major revision - TYPE113 - John Burg's SHARE 2010.
(Calculation of RNI, new z196 fields, new metrics).
TYPE119 28.175 Support for SMF 119 new subtypes 32-37 and 48-52.
TYPEITRF 28.162 Support for ITRF V420 IF2 (COMPATIBLE).
TYPECTCP 28.160 Support for CleverView GMT offset, CTCPIPAD fixed.
TYPE42 28.158 Support for APAR OA31648 TYPE42D1/D3 buff get retries
TYPEVM 28.157 Support for VM ACCOUNT ID='09' ISFC record.
TYPE102 28.156 Support for IFCID=27 specific variables.
TYPENMON 28.176 Support for SARMON - Solaris SAR in NMON format.
IMACCADI 28.172 Support for CA-Dispatch V11 SMF 6 INCOMPATIBLE.
TYPETPFC 28.152 Support for zTPFC TPF Continuous Monitoring updates.
TYPEZCOS 28.151 Support for zCost AutoSoftcapping V 1.5.00 SMF.
UTILPDSL 28.179 Utility to read PDS/PDSE directories of a concat.
BLDSMPDB 28.177 Continued minor enhancements.
IMACZDAT 28.174 Example to set ZDATE when you rebuild a past PDB.
ANALCAPD 28.169 Estimate the impact of a Defined Capacity Limit.
MULTIPDB 28.168 Create a PDB library with all datasets from many PDBs
TYPEIMS 28.165 LCODE=56x TPCPSSTY09x INPUT STATEMENT EXCEEDED.
TYPE110 28.154 Improved detection of EXCLUDED CICS fields.
TYPEXAM 28.153 XAM TCP dataset's TOTCPU incorrectly divided by 100.
TYPE42 28.150 Type 42 subtype 15 correction for TYPE42S1 dataset.
Major enhancements added in MXG 28.04, dated Jul 5, 2010
TYPE113 28.140 Major revision to SMF 113 support, TYPE70PR vars add.
ANALDB2R 28.146 Major enhancement to DB2PM-like reporting.
TYPESVIE 28.138 Support for SysView Subtype 3 records.
TYPEIMFS 28.137 Support for BMC IMF records written in SMF format.
TYPE120 28.133 Support for WebSphere SMF 120 Subtype 20, untested.
TYPESAVR 28.127 Support for revised CA $AVERS SMF record (INCOMPAT).
TYPEMXI 28.126 Support for Rocket Software MXG User SMF record.
TYPENTSM 28.119 Support for Performance Sentry NTSMF Version 3.1.4.4.
TYPEMVAO 28.118 Support for BMC Mainview Auto Operator data file.
TYPE102 28.116 Support for SMF 102 IFCID 263 decodes unique fields.
BLDSMPDB 28.125 Support for Week/Month if first-day-of-week NOT MON.
CONFIGVx 28.128 ERROR APPARENT MACRO TRIM NOT RESOVED: DOCUMENTATION.
VMXGSRCH 28.147 Kewl Tool. Find all instances of VARIABLE='VALUE'.
BUILDPDB 28.139 Recently added SMF30xxx variables kept in PDB.STEPS.
UTILWORK 28.123 Utility for TYPE72GO to assist workload definitions.
Major enhancements added in MXG 28.03, dated May 25, 2010
TYPEWPMO 28.086 Support for Windows Performance Monitor PERFMON file.
TYPECTCP 28.108 Support for CleverView for TCP/IP TN3270 SMF subtype.
TYPE80A 28.107 TOKDANAM LDAPHOST,BINDDN,BINDPW,APPLNAM,UTYPE,JPNUM.
TYPE92 28.106 SMF92PPN, Path Name, was blank.
VMXGSUM 28.105 Optional KEEPWEEK/MNTH/YEAR/DAYS/AFTER keeps TRENDs.
TYPE7072 28.099 Variable CPULHKTM, CPU TIME Lock Promoted, TYPE72GO.
VMXGSET 28.098 DSETOPT= optional argument for data set options.
SMFRECNT 28.089 BUILDPDBs PDB.SMFRECNT now has bytes and counts.
TYPE110 28.087 Internal Decompression Algorithm use now ERROR:'d.
TYPECIMS 28.084 BMC IMF INPUTCLS and LASTCLAS variables restored.
READDB2 28.083 READDB2/ANALDB2R did not honor MACDB2H/MACKEEP.
FORMATS 28.082 UDDDDDD, all and $MGDDDSN updated.
Major enhancements added in MXG 28.02, dated Apr 14, 2010
TYPE113 28.075 John Burg formulas for TYPE113 HIS data are added.
VMXGINIT 28.079A Test for NOWORKINIT and USER ABEND 990 were REMOVED.
VMXGINIT 28.081 OPTIONS VARLENCHK=NOWARN eliminates SAS V9.2 WARNINGS
VMXGINIT 28.057 ERROR MACRO %ABORT IS NOT IMPLEMENTD, SAS 8.2 ONLY.
TYPE84 28.077 Support for all JES3 JMF TYPE84 subtypes.
ASMIMSL6 28.066 Support for IMS Version 11 (INCOMPATIBLE).
TYPEIMS7 28.066 Support for IMS Version 11 (INCOMPATIBLE).
TYPEMVCI 28.065 Support for BMC CICS CMRDETL C660 for CICS/TS 4.1
TYPEDB2 28.051 Support for DB2 APAR PK62161 new SQL Counters.
TYPETMNT 28.079 WARNING: TOTAL LENGTH OF VARIABLES MUST BE LT 32760.
TYPEDB2 28.073 DB2STATS had missing values for QW0225 variables.
TYPE42 28.072 TYPE42X4 Above the BAR LRU dataset variables wrong.
BUILDPDB 28.071 PDB.STEPS/PDB.JOBS duplicates if FLUSHED steps.
MXGSAS92 28.070 SAS 9.2 TS2M2 DSNAMES may have changed
TYPERMVV 28.048 RMFV CPUG3 was misaligned in z/OS 1.11
Major enhancements added in MXG 28.01, dated Mar 9, 2010
Error circumvention:
EXIT112 28.027* Do NOT assemble EXIT112 for SMF 110/112, use EXITCICS
Errors fixed:
ASMTAPEE 28.041 Do NOT use ASMTAPEE ML-45/46, CPU SPIKE: ML-47 fixed.
TYPEVMXA 28.025 MXG CPU Loop in TYPEVMXA, new CEX3C PRCAPMCT=9 crypto
TYPECIMS 28.028 BMC IMF INPUT STATEMENT EXCEEDED, short record.
TYPEEDGR 28.029 RMM datetime vars have always been wrong time zone.
TYPE120 28.038 SMF 120 SUBTYPE 9 INPUT STATEMENT EXCEEDED RECORD
ANALZPCR 28.021 Major fixes/enhancements for complex zPCR models.
TYPE0 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 fixed.
ASUMTAPE 28.008 SPIN.SPINSYSL dataset could grow forever.
New stuff:
VMXGFIND 28.012 Kewl tool, find all obs in all datasets meeting test,
(like all obs with JOB='CICS' in all PDB datasets).
TYPESTC 28.005 Support for Sun StorageTek VSM Version 6.2 and 7.0.
TYPE89 28.015 Support for z/TPM SMF 89 record, subtype wrong byte.
TYPENTSM 28.042 New Sentry VM 3.1.4.3 adds VMWARE objects/metrics.
TYPE30 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71.
VMXGINIT 28.023 New MXGERROR/USER ABEND 990 if NOWORKINIT is enabled.
TYPEZTPF 28.043* zTPF has major revisions in Performance Data
TYPETMS 28.040 CA-1 Retention and VMRECORD extensions, need data.
Changes:
TYPE74 28.039 R7451RID now one byte, R7451FLG/TYPE74CA overlays.
BUILDPDB 28.037 PDB.SMFINTRV will have EXCP/IOTM counts for FLUSHED.
TYPE103 28.036 TYPE1032 deaccum needed PORTNR, label changed.
VGETOBS 28.034 %TRIM() references here removed, still in VMXGSUM.
IMACICMR 28.032 Protect 200-byte CMRDATA on CICS/TS 3.2 (s/b 256).
VGETDDS 28.014 Colon in DDNAMES= worked only with DDNAMES=PDB:)
TYPEDB2 28.010 Variable SHIFT (from QWHSSTCK, END) kept in datasets.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
MXG 28.28 executes best with SAS V9.2, or with SAS V9.1.3 with
Service Pack 4, on any supported SAS platform.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS/DB2 Decompression Infile Exit.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level B" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I can not guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2 ASAP, FOR BOTH OF US, TO AVOID FIXED PROBLEMS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2:
The 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.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, and V9.2.
V9.2-created "PDBs" can be read/written by SAS V8.2 or V9.1.3,
and vice versa.
MXG Versions 26.03+ execute with SAS V9.2 with NO (new) WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as a absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG QA tests are executed on z/OS with SAS V9.1.3 and V9.2 and
on Windows XP with 32-bit INTEL, and on Windows Seven Ultimate
both 32-bit and 64-bit OS on 64-bit hardware, but MXG is installed
on many more hardware and software platforms: since they all work,
we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.4 requires MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for "MXG Support for WPS Software"
IV. MXG Version Required for Hardware, Operating System Release, etc.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.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 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
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 Full plus Compressed. Nov 1, 2010 28.07*
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 28.28
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
MQ Series 7.0 ??? ??, 2009 *28.06
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
IMS log 11.0 Apr 1, 2010 28.02*
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
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 20.04
The Monitor for DB2 Version 4.0 22.10
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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
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
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
V. Incompatibilities and Installation of MXG 28.28.
1. Incompatibilities introduced in MXG 28.28:
a- Changes in MXG architecture made between 28.28 and prior versions
that can introduce known incompatibilities.
1. -The WEEKBLD/MONTHBLD may fail with TYPE72DL NOT SORTED if you
have a tailored WEEKBLD/MONTHBLD that references TYPE72DL. The
only prevention is to change the sort order in WEEKBLD/MONTHBLD
BEFORE you create your weekly with 28.28 to this order:
MACRO _DSET TYPE72DL %
MACRO _BYLIST SYSPLEX SYSTEM SYSNAME STARTIME %
to eliminate the exposure to this rare possible error.
-Or, the WEEKBLD/MONTHBLD sort order testing can be disabled
(as documented in comments) using:
//SYSIN DD *
%LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;
%INCLUDE SOURCLIB(MONTHBLD);
-Or with BLDSMPDB, specify SORTEDBY=NO to disable the sort test.
See Change 28.324.
2. -If you use ASUMDB2x or ASUMDBSx datasets, see Change 28.220.
3. -If you have tailored MXG DB2 Processing using _NDB2 and then
invoke _SDB2STS (to create PDB.DB2STATS), you must also have
MACRO _WDB2ST4 DB2STAT4 % inserted AFTER the _NDB2 so that
the PDB.DB2STAT4 dataset exists when PDB.DB2STATS is created.
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 Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 28.28 after MXG 27.27:
Dataset/
Member Change Description
Many 28.175 Support for z/OS 1.12 (COMPATIBLE)
ANALCAPD 28.169 Estimate the impact of a Defined Capacity Limit.
ANALDB2R 28.004 Extreme Detail DB2 Trace Report PMTRC01 revised.
ANALDB2R 28.146 Major enhancement to DB2PM-like reporting.
ANALDB2R 28.214 ANALDB2R report select did not honor BEGTIME/ENDTIME.
ANALDBJS 28.290 DB2 analysis adds JESNR and REAdTIME to DB2ACCT.
ANALDUPE 28.308 Removal of Duplicate SMF (or any) records.
ANALID 28.257 ERROR: VARIABLE IDANDSUM ... with PDB,DISP=OLD
ANALZPCR 28.021 Major fixes/enhancements for complex zPCR models.
ASMIMSL6 28.066 Support for IMS Version 11 (INCOMPATIBLE).
ASMTAPEE 28.041 Do NOT use ASMTAPEE ML-45/46, CPU SPIKE: ML-47 fixed.
ASUMCICR 28.281 Count/average response time by DATE for each APPLID.
ASUMDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
ASUMTAPE 28.008 Large size SPIN.SPINMOUN,SPIN.SPINSYSL found, shrunk.
ASUMTAPE 28.008 SPIN.SPINSYSL dataset could grow forever.
ASUMUOW 28.124 WTIRIOTM in PDB.ASUMUOW could be larger than IRESPTM.
ASUMUOWT 28.284 ASUMUOWT (for ASG-TMON MRO) revised to use VMXGUOW.
BLDSMPDB 28.125 Support for Week/Month if first-day-of-week NOT MON.
BLDSMPDB 28.177 Continued minor enhancements.
BLDSMPDB 28.218 Includes ASUMDBAA/TRNDDBAA caused errors, replaced.
BUILDPDB 28.037 PDB.SMFINTRV will have EXCP/IOTM counts for FLUSHED.
BUILDPDB 28.071 PDB.STEPS/PDB.JOBS duplicates if FLUSHED steps.
BUILDPDB 28.139 Recently added SMF30xxx variables kept in PDB.STEPS.
BUILDPDB 28.305 PDB.NJEPURGE did not contain all NJE-variables.
CONFIGVx 28.128 ERROR APPARENT MACRO TRIM NOT RESOVED: DOCUMENTATION.
DB2ACCT 28.277 NETSNAME/UOWTIME only created for QWHCATYP=4 (CICS).
DFH$MOLS 28.223 JCL example to use IBM CICS decompression utility.
EXIT112 28.027* Do NOT assemble EXIT112 for SMF 110/112, use EXITCICS
EXITCICS 28.223 Support for DB2 V10 Compressed SMF records.
EXITCICS 28.251 ASMA144E Begin-to-continue due to char in col 72.
EXITCICS 28.298 EXITCICS decompresses SMF 100,101,102,110 and 112.
FIXTRNCD 28.049 TRANSCODE attribute can be added to old PDBs
FORMATS 28.082 UDDDDDD, $MGDDDDD and $MGDDDSN updated.
GRAFCEC 28.261 SAS/GRAPH example charts CEC Utilization by engine
IMACCADI 28.172 Support for CA-Dispatch V11 SMF 6 INCOMPATIBLE.
IMACICMR 28.032 Protect 200-byte CMRDATA on CICS/TS 3.2 (s/b 256).
IMACZDAT 28.174 Example to set ZDATE when you rebuild a past PDB.
JCLINSTT 28.328 Complete JCL example to ftp/unterse/install on z/OS.
JCLTEST9 28.330 Prelim 28.28 only, default ASUMUOW could fail.
MULTIPDB 28.168 Create a PDB library with all datasets from many PDBs
MXGSAS92 28.070 SAS 9.2 TS2M2 DSNAMES may have changed
READDB2 28.083 READDB2/ANALDB2R did not honor MACDB2H/MACKEEP.
READDB2 28.211 COPYONLY argument wrote ALL SMF records.
READDB2 28.250 COPYONLY logic now works.
SASAUTOS 28.194 Invalid 'BA'x in TRIM member on z/OS ERROR 22.
SMFRECNT 28.089 BUILDPDBs PDB.SMFRECNT now has bytes and counts.
TRNDDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
TYPE0 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 fixed.
TYPE0 28.313 Variable CVTTZ in TYPE0 could be one second wrong.
TYPE102 28,206 APPTUNE SMF 102 IFCID 8133 invalid offset ERROR.
TYPE102 28.116 Support for SMF 102 IFCID 263 decodes unique fields.
TYPE102 28.156 Support for IFCID=27 specific variables.
TYPE102 28.325 DB2 SQL-text variables only 100 bytes if COMPRESS=NO.
TYPE103 28.036 TYPE1032 deaccum needed PORTNR, label changed.
TYPE110 28.087 Internal Decompression Algorithm use now ERROR:'d.
TYPE110 28.134 INVALID STIDLEN=0 after STID=116 was harmless, fixed.
TYPE110 28.154 Improved detection of EXCLUDED CICS fields.
TYPE110 28.247A Example using _Kdddddd to create new datasets revised
TYPE110 28.285 CICS Statistics Subtype 2 STID=143 corrected.
TYPE111 28.329 CTG records had zero observations in TY111CXI "IPIC".
TYPE113 28.075 John Burg formulas for TYPE113 HIS data are added.
TYPE113 28.140 Major revision to SMF 113 support, TYPE70PR vars add.
TYPE113 28.166 Major revision - TYPE113 - John Burg's SHARE 2010.
TYPE113 28.226 Variable LPBUSY,LPARBUSY replaced LPARCPU.
TYPE113 28.279 "Near duplicate" ASUM113 intervals are corrected.
TYPE116 28.221 WebSphere MQ 7.01 INVALID WQ SEGMENT error messages.
TYPE119 28.175 Support for SMF 119 new subtypes 32-37 and 48-52.
TYPE119 28.293 Support for OpenSSH SMF 119 subtypes 96-98.
TYPE120 28.038 SMF 120 SUBTYPE 9 INPUT STATEMENT EXCEEDED RECORD
TYPE120 28.133 Support for WebSphere SMF 120 Subtype 20, untested.
TYPE120 28.258 Support for WebSphere ID=120 SUBTYPE=20 records
TYPE30 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71.
TYPE30 28.246 New CPITCxTM/CPISRxTM wrong in MXG 28.06.
TYPE30 28.302 TYPE30MU duplicate records exist, non-dupes removed.
TYPE42 28.072 TYPE42X4 Above the BAR LRU dataset variables wrong.
TYPE42 28.150 Type 42 subtype 15 correction for TYPE42S1 dataset.
TYPE42 28.158 Support for APAR OA31648 TYPE42D1/D3 buff get retries
TYPE6156 28.289 Variables GATLIMIT and GATCNT added to TYPE6156.
TYPE70 28.175 Support for z196: INCOMPAT ONLY WITH GT 64 ENGINES.
TYPE7072 28.099 Variable CPULHKTM, CPU TIME Lock Promoted, TYPE72GO.
TYPE7072 28.242 In-Ready Work Unit SMF70U00-U15, etc were all wrong.
TYPE7072 28.246 CP eng 64-95 vars shouldn't have been kept in TYPE70.
TYPE70EN 28.224 TYPE70EN PCTCPUBY was 100% for a parked CP engine.
TYPE70EN 28.299 Wrong values for CPUID=0 in PDB.TYPE70EN.
TYPE74 28.039 R7451RID now one byte, R7451FLG/TYPE74CA overlays.
TYPE74 28.208 R7451TIM wrong, R7451CT3/CT4/PRT/PWT also wrong.
TYPE74 28.212 TYPE74ID (small) created, saves pass of TYPE74CA.
TYPE80A 28.107 TOKDANAM LDAPHOST,BINDDN,BINDPW,APPLNAM,UTYPE,JPNUM.
TYPE84 28.077 Support for all JES3 JMF TYPE84 subtypes.
TYPE89 28,282 Support for APAR OA31615, adds zIIP/zAAP CPU times.
TYPE89 28.015 Support for z/TPM SMF 89 record, subtype wrong byte.
TYPE89 28.272 SMF89HOF/SMF89DTO for SCRT don't use last 3 nybbles.
TYPE89 28.304 SMF 89 with no usage segment INPUT EXCEEDED error.
TYPE89 28.331 INVALID DATA FOR SMF89CZT if APAR OA31615 installed.
TYPE92 28.106 SMF92PPN, Path Name, was blank.
TYPECIMS 28.028 BMC IMF INPUT STATEMENT EXCEEDED, short record.
TYPECIMS 28.084 BMC IMF INPUTCLS and LASTCLAS variables restored.
TYPECTCP 28.108 Support for CleverView for TCP/IP TN3270 SMF subtype.
TYPECTCP 28.160 Support for CleverView GMT offset, CTCPIPAD fixed.
TYPEDB2 28.010 Variable SHIFT (from QWHSSTCK, END) kept in datasets.
TYPEDB2 28.051 Support for DB2 APAR PK62161 new SQL Counters.
TYPEDB2 28.073 DB2STATS had missing values for QW0225 variables.
TYPEDB2 28.222 ITRM only, DB2STAT4 NOT SORTED ERROR.
TYPEDB2 28.264 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE.
TYPEDB2 28.326 Invalid DB2 V10 Distributed Header protected in MXG.
TYPEEDGR 28.029 RMM datetime vars have always been wrong time zone.
TYPEIMFS 28.137 Support for BMC IMF records written in SMF format.
TYPEIMFS 28.193 Full support for IMF records in SMF format.
TYPEIMS 28.131 IMS Log 56X record subtype 15x INVALID DATA/STOPOVER.
TYPEIMS 28.165 LCODE=56x TPCPSSTY09x INPUT STATEMENT EXCEEDED.
TYPEIMS7 28.066 Support for IMS Version 11 (INCOMPATIBLE).
TYPEIMS7 28.310 Support for IMS/DBCTL transactions in IMS0708.
TYPEIMSA 28.311 Support for IMS/DBCTL transactions in IMSTRAN.
TYPEITRF 28.162 Support for ITRF V420 IF2 (COMPATIBLE).
TYPEITRF 28.227 INPUT STATEMENT EXCEEDED RECORD LENGTH type=17x.
TYPEMIM 28.262 Support for CA MIM RESOURCE SHARING R11.7 (COMPAT)
TYPEMVAO 28.118 Support for BMC Mainview Auto Operator data file.
TYPEMVCI 28.065 Support for BMC CICS CMRDETL C660 for CICS/TS 4.1
TYPEMXI 28.126 Support for Rocket Software MXG User SMF record.
TYPENDM 28.327 Connect Direct/NDM 'RT' record INCOMPATIBLY changed.
TYPENMON 28.176 Support for SARMON - Solaris SAR in NMON format.
TYPENMON 28.275 Support for NMON FCREAD/FCWRITE/XFERIN/XFEROUT record
TYPENTSM 28.042 New Sentry VM 3.1.4.3 adds VMWARE objects/metrics.
TYPENTSM 28.119 Support for Performance Sentry NTSMF Version 3.1.4.4.
TYPEOMMQ 28.263 Support for IBM/OMEGAMON XW MQ flat file (INCOMPAT)
TYPERMVV 28.048 RMFV CPUG3 was misaligned in z/OS 1.11
TYPESAVR 28.127 Support for revised CA $AVERS SMF record (INCOMPAT).
TYPESTC 28.005 Support for Sun StorageTek VSM Version 6.2 and 7.0.
TYPESTC 28.005 Support for Sun StorageTek Version 6.2 and 7.0
TYPESTC 28.244 STC/STK/Oracle VSM user SMF records support revised.
TYPESVIE 28.138 Support for SysView Subtype 3 records.
TYPETCP 28.300 TYPETCP (SMF 118) Port Numbers (Dec) wrong on ASCII.
TYPETMNT 28.079 WARNING: TOTAL LENGTH OF VARIABLES MUST BE LT 32760.
TYPETMS 28.040 CA-1 Retention and VMRECORD extensions, need data.
TYPETMS5 28.148 TMS DEVTYPE was blank for TRTCH 'F0'x thru 'FF'x.
TYPETMVT 28.287 Support for ASG-TMON for VTAM subtype 'SX' record.
TYPETNG 28.216 NSM RH018 defective records with zero values.
TYPETNG 28.273 Support for more than 9999 instances in CA NSM/TNG.
TYPETPFC 28.152 Support for zTPFC TPF Continuous Monitoring updates.
TYPETPX 28.260 IP address and Port Number now decoded in TPX SMF.
TYPEVM 28.157 Support for VM ACCOUNT ID='09' ISFC record.
TYPEVMXA 28.025 MXG CPU Loop in TYPEVMXA, new CEX3C PRCAPMCT=9 crypto
TYPEVMXA 28.307 Short LINUXKRNL MONWRITE record caused errors.
TYPEVMXA 28.315 PFXCPUAD in VXSYTCUM is the LCPUADDR, no CPUID.
TYPEWPMO 28.086 Support for Windows Performance Monitor PERFMON file.
TYPEXAM 28.153 XAM TCP dataset's TOTCPU incorrectly divided by 100.
TYPEZCOS 28.151 Support for zCost AutoSoftcapping V 1.5.00 SMF.
TYPEZTPF 28.043* zTPF has major revisions in Performance Data
UTILBLDP 28.209 INCLAFTR=BUILD005,BUILDPDB=NO failed.
UTILEXCL 28.259 Spurious "WRONG LENGTH OF 200 FOR CMRDATA"
UTILGETM 28.312 No Reporting Class data in SMFSMALL with NRECORD=10.
UTILNPRT 28.268 Identify non-print chars, for SAS Enterprise Guide.
UTILPDSL 28.179 Utility to read PDS/PDSE directories of a concat.
UTILWORK 28.123 Utility for TYPE72GO to assist workload definitions.
VGETDDS 28.014 Colon in DDNAMES= worked only with DDNAMES=PDB:)
VGETOBS 28.034 %TRIM() references here removed, still in VMXGSUM.
VMXGFIND 28.012 Kewl tool, find all obs in all datasets meeting test.
VMXGINIT 28.023 MXGERROR/USER ABEND 990 if NOWORKINIT is enabled.
VMXGINIT 28.057 ERROR MACRO %ABORT IS NOT IMPLEMENTD, SAS 8.2 ONLY.
VMXGINIT 28.081 OPTIONS VARLENCHK=NOWARN eliminates SAS V9.2 WARNINGS
VMXGSET 28.098 DSETOPT= optional argument for data set options.
VMXGSRCH 28.147 Kewl Tool. Find all instances of VARIABLE='VALUE'.
VMXGSUM 28.105 Optional KEEPWEEK/MNTH/YEAR/DAYS/AFTER keeps TRENDs.
VMXGSUM 28.249 VMXGSUM enhanced with MODE and MEDIAN statistics
WEEKBLD 28.324 WEEKBLD/MONTHBLD/BLDSMPDB dataset TYPE72DL NOT SORTED
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 28.
====== Changes thru 28.331 were in MXG 28.28 dated Jan 18, 2011=========
Change 28.331 INVALID DATA FOR SMF89CZT if APAR OA31615 is installed.
VMAC89 Change 28.282 claimed support, but without test data, and
Jan 15, 2011 the error was because MXG input SMF89CNO as two bytes but
it is a four byte field, causing the misalignment.
Jan 19: I didn't get records in time for 28.28 and this
change did NOT correct this error, but Change 29.002 did.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.330 Prelim 28.28 default ASUMUOW in JCLTEST9 (does NOT read
VMXGUOW ANY input) failed, on all platforms with SAS V9.1.3 or on
Jan 15, 2011 SAS V9.2 on z/OS. There is NO error if you have IMACUOW
tailored to create observations in PDB.ASUMUOW. The
error message is a NO BY VARIABLES ERROR, but the actual
error was a DATA SET NOT FOUND error that was masked by
the OPTIONS NODSNFERR in VMXGUOW. Changes 28.316/28.284
added logic to print an MXGWARN when there was no input,
by creating a second dataset in an existing DATA step,
but that second dataset is NOT created when OPTIONS OBS=0
is set and the first dataset is a /VIEW, unless SAS V9.2
on Windows/Unix is used. The SAS defect was fixed only
for ASCII V9.2, but is now reopened by SAS Tech Support.
But MXG code was revised to eliminate the second dataset,
and tests now are for dataset existence rather than for
non-zero observations.
And why didn't MXG QA catch the error? Because we tailor
IMACUOW to create observations, which didn't fail.
Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA
Change 28.329 CTG records had zero observations in TY111CXI "IPIC"
VMAC111 because MXG's length test was incorrect. The Version 8
Jan 14, 2011 documentation has several new fields that are now input
Jan 19, 2011 if the record length test is satisfied.
Jan 19: The VMAC111 was NOT updated in time for MXG 28.28
because I had no test data for validation; this update is
now made, but there are still no observations in either
TY111CXI or TY111CXE datasets because there are no SMF
data with values CTGRECID=2 being created.
Thanks to Jim Poletti, Edward Jones, USA.
Change 28.328 New JCLINSTT member is the recommended z/OS install JCL
JCLINSTT with these four steps to "drop-in" the new version
INSTALL FTPMXG
Jan 13, 2011 FTP DOWNLOAD TER2828.TER FILE FROM THE MXG FTP SITE.
UNTERSE
UNTERSE THE DOWNLOADED TER2828.TER FILE.
ALOCUSID
ALLOCATE THE MXG.V2828.USERID.SOURCLIB PDS LIBRARY.
FORMATS
ALLOCATE AND CREATE MXG.V2828.MXG.FORMATS LIBRARY.
Change 28.327 -Connect Direct 'RT' record's format was changed; while
VMACNDM offsets for the PACCT and SACCT exist and are populated,
Jan 12, 2011 the ACCT fields do NOT exist, and instead a text string
Jan 13, 2011 inside double quotes ('7F'x) is at the end of the record.
This change detects the quote pair and stores that text
in new NDMRTDAT text variable. However, some 'RT' don't
have the quote pair, so a length test will skip over the
data at the end but will still output the RT record.
-And short RT records, less than the 216 bytes have been
found and are printed on the log and skipped.
-The 'AE' family of records UID and XUSER fields are now
input $EBCDIC64 as they were expanded.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Thanks to G. Bosker, Rabobank Nederland, THE NETHERLANDS.
====== Changes thru 28.326 were in Prelim MXG 28.28 dated Jan 12, 2011==
Change 28.326 Invalid DB2 Distributed Header has QWHDPRID shifted right
VMACDB2H by two bytes, causing INPUT EXCEEDED error when QWHDPRID
Jan 12, 2011 had non-null value in the last two bytes, as those bytes
were expected to contain the OFFSET to QWHDRQNM when they
are non-zero. The defective records are now detected by
'0000'X value in the first two bytes of QWHDPRID, the
header is skipped, new variable QWHDBAD is set to one,
and an error message is printed for the first three.
IBM has accepted a PMR and will have an APAR to correct.
This change protects the Invalid Header so the APAR is
NOT required for MXG.
APAR PM32425 corrected the problem.
Thanks to Joe Babcock, JPMC, USA.
Change 28.325 Since Change 22.108, DB2 SQL-text variables are only 100
VMAC102 bytes if COMPRESS=NO is specified. The normal length of
Jan 11, 2011 32000 with YES must be reduced with NO because massive
disk space could be required.
But you can change this behavior by using
//SYSIN DD *
%LET SASCHRLN=32000;
even if you have specified COMPRESS=NO.
-Two variables had default lengths of 4000 and 5000 set by
&SASC4000 and &SASC5000, but they now use &SASCHRLN to be
consistent.
-The list of variables was updated in the text of 22.108.
Thanks to Joachim Sarkoschits, DATAEV eG, GERMANY.
Change 28.324 -WEEKBLD/MONTHBLD dataset TYPE72DL NOT SORTED ERROR, if a
MONTHASC WEEKBLD/MONTHBLD member is in your "USERID.SOURCLIB".
-Inserted Jan 24, 2011, after MXG 28.28 was created:
Similar DB2STATS NOT-SORTED ERROR in Change 29.008, but
you can Circumvent/eliminate sorting as shown below.
MONTHASW The TYPE72DL wasn't reported by a user, but was found in
MONTHBL3 in QA tests when PDBs built by old and new versions were
MONTHBLD combined, because the sort order in WEEKBLD/MONTHBLD for
MONTHBLS TYPE72DL was erroneously different in VMAC7072/BUILDPDB.
MONTHDSK The only prevention, if WEEKBLD/MONTHBLD exists in your
MONTHWEK USERID.SOURCLIB, is to change the _BYLIST, before you run
WEEKBL3 WEEKBLD or MONTHBLD with MXG 28.28, to this order
WEEKBL3D MACRO _DSET TYPE72DL %
WEEKBL3T MACRO _BYLIST SYSPLEX SYSTEM SYSNAME STARTIME %
WEEKBLD which is the new default in MXG's WEEKBLD/MONTHBLDs.
WEEKBLDD -Alternatively, you can disable sort order and tests in
WEEKBLDT WEEKBLD/MONTHBLD using this example (from comments):
Jan 10, 2011 //SYSIN DD *
Jan 15, 2011 %LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;
Jan 16, 2011 %INCLUDE SOURCLIB(WEEKBLD);
-With BLDSMPDB, add SORTEDBY=NO, to bypass sort test.
-MONTHWEK was updated Jan 15 with a RUN; added.
Change 28.323 -New SX record support caused DIVISION BY ZERO because of
VMACTMVT a typo that caused SXHRTA to be a missing value.
Jan 10, 2011 -SXBV1/BV2/BV3/BV4/HRTD/NRTTD/HRT/SXNRTT variable were
incorrectly input as PIB4 vs PIB4.6 and were incorrectly
converted (i.e., the 1024 multiplier to convert those
durations into seconds/fractions was nonexistent for SX,
but was in place for the existing SI variables.)
Thanks to Paul Volpi, UHC, USA.
Change 28.322 z/TPF records SB, DB, and DE had incorrect length for
VMACZTPF reserved fields that are now corrected and validated
Jan 10, 2011 with data records.
Thanks to Bob Wilcox, HP, USA.
Change 28.321 Harmless DIVIDE BY ZERO in a 7-second-long RMF interval
VMAC7072 when there was a WLM Policy switch that causes SMF70DSA
Jan 9, 2011 sample count to be zero; all divides are now protected.
Harmless because the created variable was not used in a
subsequent calculation, and is missing either way.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 28.320 -LPARBUSY calculation in PDB.ASUM113 was wrong if the CPs
ASUM113 are slower than your zAAPs/zIIPs, because the SM1132CP
Jan 7, 2011 (speed) of the last engine (the zIIP or zAAP) was used.
And with multiple engine types, even at same speed, it
makes more sense to create separate observations for
each SMF70CIN/SM113CPT engine type for each interval.
But SM113CPT is only populated in 113s from z196, and
SMF70CIN is only populated if there's PDB.TYPE70PR data,
so the actual separation is by SM113CPT and SM1132SP to
ensure the correct speed is used to calculate LPARBUSY.
-For z10, SMF70CIN in PDB.ASUM113 is populated from the
TYPE70PR data, but the logic was not always correct. Now
SYSTEM=SMF70STN is used to select the correct LCPUADDR,
the sort order was changed to match correctly, and then
the SMF70CIN value is used to populate SM113CPT for the
z10 processors. (For z196 SM113CPT is already there.)
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 28.319 Support for IODQDS segment in Velocity Software XAM data
EXXAMQDS creates new XMIODQDS dataset.
IMACXAM
VMACXAM
VMXGINIT
Jan 6, 2011
Thanks to Francois VanCoppenolle, PVGROUP, BELGIUM
Change 28.318 MXGs test for EXCLUDEd fields in CICS/TS 4.1 tested for
VMAC110 LT 330 fields OR LT 2640 bytes, but since the default
Jan 5, 2011 record has 337 fields and 2668 bytes, a false detection
of EXCLUDED fields was not possible. Additionally, the
primary flag of EXCLUDEd fields is an invalid TASKNR, as
it is a packed decimal field whose shift is detectable.
But, the MXG test and comments were corrected.
Thanks to Patricia Hansen, ADP, USA.
Change 28.317 In analysis of the impact of possible capping values, if
ANALCAPD the desired CAP was exceeded, those excess MSU had to go
Jan 5, 2011 somewhere: this modification keeps track of the excess
MSU and spreads them out across the following intervals
up to the level of the desired CAP until they are all
used up.
Thanks to Dick Arnold, Commerce Bank of Kansas, USA.
Change 28.316 If you fail to reset the _NOOBS and _YESOBS tokens before
VMXGUOW you run ASUMUOW, no observations were processed, but with
Jan 5, 2011 no explanation. Now, when zero observations are detected
an MXGWARN message is printed to explain why there was no
output observations created in ASUMUOW.
Change 28.315 -The "CPU ADDRESS" PFXCPUAD in dataset VXSYTCUM is not the
VMACVMXA "VM" CP address of 00-0Fx, but is the LCPUADDR in the CEC
Jan 5, 2011 causing VXSUMCPU to contain many spurious observations.
This correction for the unexpected PFXCPUAD values is to
deaccumulate by PFXCPUAD, but then sum by ENDTIME for the
merge to create VMXAINTV. Fortunately, the only variable
in VXSYTCUM is the LPAR Management Time LCUMGTM, and in
spite of the spurious observations, the value in VMXAINTV
was correct before and after this change; the increase in
observations during summarization just looked wrong!
-Division by zero in creating VXAPLTCB was because the BY
list did not include SUBTASKN.
Thanks to Frank Bright, MEDCO, USA.
Thanks to Nick Said, MEDCO, USA.
Change 28.314 -%UTILBLDP(SUPPRESS= 6 26 30 110 DB2,BUILDPDB=YES) caused
UTILBLDP ERROR: FILE WORK.TYPE30MR DOES NOT EXIST. TYPE30MR is
Jan 4, 2011 now protected when SUPPRESS 30 is requested.
-If SMF 6 26J2/26J3 AND 30 are suppressed, BUILD005 is not
executed.
-If 26 (instead of 26J2/26J3) is specified, 26J2 is used,
with a note.
-A new QA report now compares the suppressed records list
of dddddd tokens with the list of datasets created by the
SMF record to ensure UTILBLDP is updated when needed.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 28.313 -Variable CVTTZ in TYPE0 could be one second wrong, for
TYPE0 some time zones, because the CEIL/FLOOR functions that
TYPE28 are needed in MXG to create integer Time Zone deltas were
TYPEEPIL omitted when CVTTZ was added to the record. The CVTTZ
TYPEHPDM field is documented in the CVT as if it is the actual GMT
TYPEMVCI offset, but its value of 1.048576 seconds per binary bit
TYPENTCP is not an integer value; IBM actually uses the 8-bytes in
TYPEOMCI CVTLDTO with 1 microsecond resolution for the GMT offset.
TYPETIMS -The CVTTZ field is the first 4 bytes of CVTLDTO, so those
TYPETMDB CEIL/FLOOR functions are used to create exact GMT Offset;
TYPETPX their absence in TYPE0 caused a search for all MXG code
Jan 3, 2011 with CVTTZ-based GMT offset, which found some members
needed corrections. Luckily, some of the vendor records
store an integer value, so MXG's use of CEIL/FLOOR is not
always required, but MXG now uses them consistently.
Fortunately, in most cases below, the GMT Offset was not
used to convert (when all timestamps are already LOCAL),
so only the GMT Offset variable might have been wrong.
And by only one second:
-VMAC0: CVTTZ had no CEIL/FLOOR.
-VMAC28: NPMGMTTZ had only (wrong) PIB.4., no floor.
-VMACEPIL OMGMTOFF CEIL/FLOOR functions reversed.
-VMACHPDM SOVHTZOS no 1.048576 multiply, no CEIL/FLOOR
-VMACMVCI T6ECVTTZ CEIL/FLOOR functions reversed.
-VMACNTCP MONCVTTZ only PIB.4, no multiply, no CEIL.
-VMACOMCI SMCVTTZ CEIL/FLOOR functions reversed.
-VMACTIMS CHGMTA no CEIL/FLOOR
-VMACTMDB GMTOFFTM no CEIL/FLOOR
-VMACTPS TPXCVTTZ CEIL/FLOOR functions reversed.
Note: CVTLDTO is not externalized; APAR OA23267 listed a
value of FFFE6053 1927B4DE for a 31 hour offset, but that
value is 30.99500413 hours, .005 hours or 0.35 seconds
instead of the one microsecond resolution expected. But,
the error in that APAR apparently impacted both the hour
and the seconds; examination of current CVTLDTO values
FFFFAF88 -6 hours FFFFAF88 A2800000 -21600.000000
FFFFBCF1 -5 hours FFFFBCF1 DCC00000 -18000.000000
FFFFCA5B -4 hours
show full microsecond resolution produces exact integers.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 28.312 The default "SMFSMALL" file for testing SMF processing
UTILGETM created by UTILGETM writes only 10 records for each SMF
Dec 31, 2010 ID and SUBYTPE, so the TYPE72GO dataset had only the
first 10 service classes and NO reporting classes. The
default NRECORD=50 is now set so there should be at least
some Reporting Class observations in SMFSMALL (which was
increased from 4 to only 19 cyl, so it's still SMALL).
Thanks to Ken Jones, Xwave, CANADA.
Change 28.311 Support for IMS/DBCTL transactions made in Change 28.310
TYPEIMSA are implemented in the JCLIMSL6/ASMIMSL6 IMS processing.
TYPEIMSB -TYPEIMSA was revised to split and separately process the
VMACIMSA IMS/TM from the IMS/DBCTL transactions.
Dec 31, 2010 -TYPEIMSB was corrected to correctly work on ASCII SAS,
and ancient code blocks were removed for IMS Version 5!
-VMACIMSA revised to create IMS07D/IMS08D for DBCTL.
-Some code blocks for _IMSVERS LE 6.1 were removed.
Thanks to Ojnan Lindholm, Volvo, SWEDEN.
Change 28.310 Support for IMS/DBCTL transactions created by TYPEIMS7 in
EXIMS07D IMSTRAN.IMS0708 is revised. While IMS/DBCTL transactions
EXIMS08D were correct, identifiable by PROGTYPE='D', DBCTL records
FORMATS also created thousands of spurious observations that had
TYPEIMS7 PROGTYPE=' ', but, fortunately, had no resources, so they
TYPEIMSD only wasted disk space! Now, VMACIMS splits the 07/08
VMACIMS records (DLRUSSN GT 0 for DBCTL) to create separate pairs
VMXGINIT in IMS07/IMS08 and IMS07D/IMS08D datasets that are then
Dec 31, 2010 separately sorted and combined by different algorithms to
eliminate the spurious observations. TYPEIMS7 can create
datasets for all IMS log records, or you can select which
records are read to populate only desired IMS datasets.
These tailoring macros allow you to define the LIBNAMEs
that will be used; all default to WORK. See examples in
the comments in TYPEIMS7 member.
DDNAME DDNAME.DATASET DATASET DESCRIPTION
TOKEN
&WIMS78 IMS0708.IMS0708 IMS/TM,IMS/DBCTL TRANS
&WIMSBMP IMSBMPS.IMSBMPS BMP EXECUTIONS
&WIMSA78 IMS0A78.IMS0A78 IMS/TM CPIC TRANSACTIONS
&WIMSOTH IMSOTHER.IMSOTHER ALL OTHER IMS LOG RECORD
-VMACIMS creates the new IMS07D and IMS08D datasets from
which the IMSDBCTL dataset is created by TYPEIMSD.
-FORMAT $MGIMFPT adds ' '='BLANK:UNMATCHED', because the
mismatched 08/07s can exist and now will be output and
can be seen with that value if you print PROGTYPE.
However, if you want to tabulate PROGTYPE, because it
is a character variable, you must add the /MISSING
option to see the formatted value tabulated:
PROC FREQ DATA=IMSTRAN.IMS0708;TABLES PROGTYPE/MISSING;
-Some code blocks for _IMSVERS LE 6.1 were removed.
-Member TYPEIMSD is replaced by TYPEIMS7 and contains only
comments. The original TYPEIMSD had the IMS/DBCTL logic
for the 07/08, but it did not handle IMS/TM transactions.
Thanks to Ojnan Lindholm, Volvo, SWEDEN.
Change 28.309 The Raid Rank ID variables R745RRID and R748RRID are now
VMAC74 formatted with HEX4. as both RMF and HDS internals show
Dec 27, 2010 the hex value in printed reports.
Thanks to Ron Hawkins, HDS, USA.
Change 28.308 Removal of duplicate SMF records (now, ANY non-VSAM z/OS
ANALDUPE data file). See MXG Newsletter FIFTY-SEVEN, MXG TECH NOTE
UNDUPSMF TWO for benchmarks of the four alternatives, and read the
Dec 23, 2010 ANALDUPE discussion of why MP's discovery that the SAS
MD5 Hash Function is an elegant and efficient solution to
remove duplicates from ANY z/OS file, not just SMF data.
For comparison, see the timings in UNDUPSMF, the original
de-dupe program.
Thanks to MP Welch, Aprize, Inc, USA.
Change 28.307 A short LINUXKRNL'02'x20101 MONWRITE segment caused error
VMACVMXA messages on the log of broken data, but MXG recovery was
Dec 23, 2010 successful. The invalid segment had MRHDRLEN=140 with
NRCPUS=2, so it had only 44 bytes for the two sets of 9
4-byte per-CPU counters. The short record is detected and
the second CPU observation is not output, but there are
no MXG messages on the log; if/when a user notices the
same problem we'll then pursue a problem report with IBM.
Thanks to MP Welch, Aprize, Inc, USA.
Change 28.306 Change 28.277 corrected NETSNAME from QWHCTOKN when there
VMAC116 was no period in QWHCTOKN; that same correction is now
Dec 21, 2010 made in SMF 116 when there is no period in QWHCNID.
Thanks to Nick Varvarigos, IBM Global Services, CANADA.
Change 28.305 -PDB.NJEPURGE did not contain all NJE-related SMF 26 Purge
BUILD005 records; MXG only output INREASON=JR or JT records into
VMAC26J2 that dataset, so INREASON=SR records were not output.
Dec 21, 2010 Now, all TYPE26J2 with SYSEXEC blank and any JES2 Offload
Jan 3, 2010 Purge Records are output in PDB.NJEPURGE.
-All TYPE26J2 variables are now kept in PDB.NJEPURGE.
-Variable INREASON='RD' is now set for purge records that
have INDEVICE of INTRDR, STCIRDR and TSOINRDR; previously
INREASON was blank.
-Blank INREASON will now print the first three instances.
-Jan 3: BUILD005 revised; it had added all of the _NJE26
variables to the PDB.JOBS dataset, wasting space, and the
dataset SPIN26 had also kept RDRTM SUBSYS.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.304 SMF 89 subtype 1 with no usage segment had INPUT EXCEEDED
VMAC89 RECORD LENGTH error, because Change 28.282 added test for
Dec 20, 2010 new data in line 390, but the test was GE 195 but should
have been GE 205. Only one record with no usage occurred
in 160,000+ records, but MXG now detects and output these
records in TYPE89. They can be identified because both
PRODTCB and PRODSRB are missing values. If a problem is
opened with IBM and a response is received, this note
will be updated.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 28.303 Printed output location was shifted to accommodate longer
ANAL119 host names and URLs, and to avoid print overlay of the
Dec 17, 2010 remote IP address on detail reports when reading IPHOSTS.
Thanks to Dave Ireland, USDA National IT Center, USA.
Change 28.302 The BY list for dataset TYPE30MU was insufficient and it
VMAC30 removed some non-duplicated observations. Adding vars
Dec 17, 2010 STEPNR STEPNAME PRODTCB PRODSRB SMFRECNR MULCEGNR to the
BY list eliminates the false duplicate removal, and by
adding after SMFTIME, they won't cause NOTSORTED errors.
However, there ARE duplicate TYPE30MU segments from the
same SMF record that are now kept only because MULCEGNR,
(segment position in each record) are different. You can
examine these duplicated segments with this example:
%INCLUDE SOURCLIB(TYPE30);
PROC SORT DATA=TYPE30MU OUT=SORT30MU;
BY READTIME JOB JESNR INITTIME SUBTYPE
PRODOWNR PRODNAME PRODQUAL PRODID
SMFTIME STEPNR STEPNAME PRODTCB PRODSRB;
DATA DUPES;
SET SORT30MU;
BY READTIME JOB JESNR INITTIME SUBTYPE
PRODOWNR PRODNAME PRODQUAL PRODID
SMFTIME STEPNR STEPNAME PRODTCB PRODSRB;
IF FIRST.PRODSRB AND LAST.PRODSRB THEN DELETE;
PROC PRINT;
TITLE DUPLICATE SEGMENTS IN TYPE30MU;
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.301 WPS does not provide the %DATATYP %macro, added in 28.06
VMXGGETM to detect non-numeric typed values for NRECORD argument
Dec 20, 2010 in %VMXGGETM call. VMXGGETM is used only to create the
SMFSMALL file or to count records/bytes in an SMF file.
That change was only to replace an obscure failure with
a successful run by forcing NRECORD to the OBS value.
That enhancement is now bypassed when executed under WPS.
Thanks to Matt Henson, McMaster-Carr Supply Co., USA.
Change 28.300 TYPETCP (SMF 118) Port Numbers (IN DECIMAL) were wrong if
VMACTCP MXG was executed on ASCII because the input was PIB2. but
Dec 14, 2010 must be the &PIB.2. macro variable to resolve correctly.
Having found this one exposure precipitated a search of
all MXG members and these members also had to be fixed;
fortunately, almost all of these members are ancient and
no longer used so there was no impact except consistency:
TTXPDS XIBMFDP XGTFANAL TYPSIMS1 TYPEIMS1 VMACZTPF
VMACTPF VMACTMVS VMACSMSX TYPESRLI PRODTESW PRODTEST
IDMSLOG IDMSLO57 IDMSJRLN ANALCM29 ANALCM27
Thanks to Cristian Molero, MConsulting Bvba, BELGIUM
Change 28.299 Wrong values (neg PCTCPUBY +) in PDB.TYPE70EN for CPUID=0
VMAC7072 if SMF70PAT was non-zero in any engine, because SMF70PAT
Dec 14, 2010 was kept in both TYPE70EC and TYPE70EL, which are MERGEd
to create PDB.TYPE70EL, but it only should have been kept
in TYPE70EC. Having the same named variables in datasets
that are merged can have unintended consequences if they
are not in the BY list for the merge.
Fortunately, the PDB.TYPE70EN (one obs per engine) is not
(yet) used to create the per-engine values in PDB.TYPE70.
And, only software developers like Don are even likely to
ever need the level of detail from RMF 70s in TYPE70EN.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.298 -EXITCICS decompresses SMF 100,101,102,110 & 112 records,
EXITCICS The previously reported errors with SMF 112s and EXIT112
EXIT112 were not in the CICSIFUE exit code, but in VMAC112 due to
VMAC112 IBM's change of FOCVER='V560' backwards to FOCVER='V420'
Dec 18, 2010 (with NO change in the record itself), which caused MXG's
tests for GE 'V560' to fail and misalign the decompressed
record. With the exit, the ABEND was incorrectly blamed
on the Exit, or, processing uncompressed records caused
zero observations in the T112xxxx datasets.
Member EXITCICS invokes the CSRCESRV function; this note
here so a search for it will find this change text.
-VMAC112 was revised for FOCVER='V420'.
-The EXIT112 member is now only comments to use EXITCICS.
-EXITCICS added DB2 100,101,102s support in MXG 28.06.
Thanks to Dick Arnold, Commerce Bank of Kansas City, USA
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA
====== Changes thru 28.297 were in MXG 28.08 dated Dec 13, 2010=========
Change 28.297 WANTONLY=DB2ACCT, now works; it worked fine if there was
READDB2 a blank before the comma. Now in QA TESTREAL. Found this
TESTREAL when I tried to use it in ANALDBUT, so Tom gets 2nd cite!
Dec 12, 2010
Thanks to Tom Glaser, MasterCard, USA.
Change 28.296 Analysis of DB2 DSNUTIL executions, by combining DB2ACCT
ANALDBUT observations with QWHSPLAN='DSNUTIL' with DB2 Trace data
Dec 12, 2010 IFCIDs 23,24,25 to add UTILNAME, UTILPHAS, and UTILID
variables to the DB2ACCT observation for each DSNUTIL
execution. The output WORK.DSNUTIL dataset is created.
Thanks to Tom Glaser, MasterCard, USA.
Change 28.295 Analysis of WHO deleted your DB2 data, combining TYPE6156
ANALWHO and DB2ACCT. If you have the DDL Audit Trace its easy:
Dec 10, 2010 %ANALDB2R(PMACC01=NO,PMACC02=NO,
PMSTA02=NO,PMAUD02=YES,AUDIT=DDL);
and this program would not be needed.
However, ANALWHO selects the z/OS Dataset name from
the TYPE6156 datasets, from which you can find the time
when the z/OS dataset was deleted, but those records will
have only the job name of the DB2 DBM1 address space.
By adding DB2ACCT you can narrow in on who did it to the
DB2 table in that time period, with QXDRPDB or QXDRPTA or
QXDRPIC GT 0.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.294 Variables CPUZIETM and CPUIFETM added to summarization
ASUMSMFI of PDB.SMFINTRV to create PDB.ASUMSMFI.
Dec 10, 2010
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.293 -Support for OPENSSH SMF 119 subtypes 96-98 creates new
VMAC119 dataset ddddd description
VMACSMF TYP11996 T11996 OpenSSH Server Transfer Complete
Dec 9, 2010 TYP11997 T11997 OpenSSH Client Transfer Complete
TYP11998 T11998 OpenSSH Login Failure
-Technically, these new subtypes are INVALID SMF records
because BIT 1 in SMFxFLG, which is the IBM indicator that
the record contains subtypes, is not ON, causing VMACSMF
to see these as SUBTYPE=0. Now, VMACSMF forces the input
of SUBTYPE for ALL SMF ID=119 records.
Thanks to John McKown, Health Markets, USA.
Change 28.292 New MODATE option PROC PRINTs the found datasets in order
VMXGSRCH of the Modify date, so the search results are printed in
Dec 8, 2010 the same order they appear on the SAS log. The MODATE=NO
default prints the datasets alphabetically, as before.
MODATE=YES was used to debug the multi-step TYPETMS5 code
by selecting a VOLSER to follow, especially since the
variable name that contains "volser" is different in
different temporary WORK datasets.
Additional parameters were also added to allow you to
limit which datasets and which variables to be searched
and printed, if you don't want to see all of them.
New parameters:
MODATE=NO Change to YES to sort on modify datetime
DATASET= A list of full or partial datasets to be
searched for the string
VARS= A list of full or partial variable names
to be searched/printed
Change 28.291 -Cosmetic. SUBTYPE for DB2 ID=102 can be greater than 255,
VMACSMF but previously they were set to missing value so UTILGETM
Dec 8, 2010 did not report them. For actual ID=102 processing, MXG
uses the IFCID value so this had no real impact.
-Cosmetic. Back-to-back ID=2 did not print the LAST RECORD
IN GROUP message. SMFHDRCN now keeps track.
-Reminder for reading only part of an SMF file:
While using OPTIONS FIRSTOBS=100 OBS=500; can sometimes
used, to read only those input records, if there is any
post-processing (deaccumulate, sort, etc.) it won't work!
Instead, use %LET SMFEXIT= FIRSTOBS=100 OBS=500; which
will used those on the INFILE and thus only impact which
records are read, not touching the global options.
Change 28.290 New DB2 analysis adds JESNR and READTIME to DB2ACCT by
ANALDBJS reading PDB.JOBS and PDB.JESNR and sequencing DB2ACCT
Dec 8, 2010 by JOB and SMFTIME to propagate those variables.
Thanks to Jane Stock, USPS, USA.
Change 28.289 Variables GATLIMIT and GATCNT are now KEPT in TYPE6156 so
VMAC6156 that changes in GDG limits can be observed.
Dec 8, 2010
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 28.288 Cosmetic. If no observations are found with the searched
VMXGSRCH values, now, a note that no observations were found is
Dec 7, 2010 printed on the log.
Change 28.287 Support for ASG-TMON for VTAM subtype 'SX' creates new
ANALTMVT TMVTSX dataset with the "Session Extended Information".
EXTMVTSX New member ANALTMVT replicates for ASG-TMON VTAM reports.
IMACTMVT
VMACTMVT
VMXGINIT
Dec 6, 2010
Change 28.286 Variables QAINTS and QAINTE, interval start/end datetimes
VMACTMMQ should have been kept in TMMQQAA dataset, and now are.
Dec 6, 2010
Thanks to Homayoun Riazi, United Health Group, USA.
Change 28.285 CICS STID=143 sub-subtype printed message that six bytes
VMAC110 of new data was skipped, but there was no new data; MXG
Dec 3, 2010 incorrectly input ECCEVCAP as only 4 bytes, when it is 8,
so ECCEVCAP/ECCCAPFA/ECCEMIFA in CICECC Statistics Data
set were wrong, and the subtract of 146 is now 152 after
that correction.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.284 -VMXGUOW was enhanced to detect that all input tokens
ASUMUOWT (_LCICTRN _LMONTSK _LDB2ACC) do not exist, or it will
VMXGUOW construct the macros based on the presence or absence
VGETENG of the corresponding &P****** macro. If for example
Dec 3, 2010 &PCICTRN is empty or the DDNAME is not found, the
_LCICTRN macro is set to CICSTRAN. If it is found,
the macro is set to &PCICTRN..CICSTRAN. If neither
CICSTRAN nor MONITASK exist, a warning is printed,
but the output ASUMUOW dataset is created with OBS=0.
-ASUMUOWT (for TMON instead of CICSTRAN input) will now
call VMXGUOW, so there is only one macro to maintain;
this obsoletes VMXGUOWT as no longer required.
-VGETENG NOEXIMSG=YES added as a default. NOEXIMSG=NO
suppresses the MXGNOTE on the log as it does in the
other %VGET macros.
Thanks to Ken Goodis, Emblem Health, USA.
Change 28.283 Many RACF segments have a variable containing CLASS*NAME
VMAC80A for that specific RACFTYPE/SMF80DTP, but some had only
Dec 2, 2010 "CLASS*NAME" for their label value. Now, the RACFTYPE
value is included to make the LABEL value unique.
Thanks to John Matson, EPSON, USA.
Change 28.282 -Support for APAR OA31615 which adds zIIP & zAAP CPU TIME
EXTY89I to dataset TYPE89, and which adds new Intersect Data that
IMAC89 creates new TYPE89I dataset for Measured Usage reporting.
VMAC89 -Variable SMF89SYN is added to each of the BY lists as the
VMXGINIT last variable; if you have duplicate SYSTEM names in your
Dec 2, 2010 SYSPLEX, then SMF89SYN will be different than SYSTEM.
Change 28.281 PDB.ASUMCICR dataset contains the count/average response
ASUMCICR time by DATE for each REGION/APPLID, and can be created
Dec 1, 2010 from transaction detail MONITASK or CICSTRAN or ASUMUOW
datasets, or the summary PDB.CICS dataset (built by
ASUMCICS/ASUMCICX), or, if the input is WEEK.ASUMCICR or
if INDATA= MON.ASUMCICR ... SUN.ASUMCICR, the prior sums
will be re-summed to include partial days for each DATE.
And, if NODATE=YES, is specified, whatever input is in
the INDATA= argument will be summarized only by APPLID,
(in case your manager thinks a weekly average of all of
the week's transactions in a region is a useful metric!).
The PDB.ASUMCICR dataset also summarizes TASCPUTM.
Note: These values may be of little use, if your site
uses Multi-Region-Option MRO and you read transaction
detail datasets (MONITASK/CICSTRAN), where the counts
will be inflated and false, since each one of the
multiple observations of an MRO transaction (one TOR,
one-to-many AOR, one-to-many DOR/FOR obs) will each be
counted as a separate "transaction", which they aren't!
On the other hand, if there are very few MRO trans, and
your APPLIDs are stable, these counts/averages might be
useful for tracking quantity and response.
Thanks to Ken Goodis, Emblem Health, USA.
Change 28.280 The XCF Path report added the TRANSFER TIME column, and
ANALRMFR some BY lists with repeats of SYSNAME were corrected.
Nov 30, 2010
Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.
Change 28.279 ASUM113 used SMFTIME to define each interval, but SMFTIME
VMAC113 can have multiple values in the records for an interval;
Nov 29, 2010 it can take a second to write all of the records for one
interval. If SMFTIME had different .01 second values,
ASUM113 incorrectly created "near duplicate" observations
with wrong values. As no "start of interval" flag exists
in SMF 113 records, this revision uses the time value in
the SM113CPU=0 and SM113CST=1 and SM113CPT=0 observation
to populate SM113STM, the Interval Start Time, for each
interval. An additional error when the GMT OFFSET was
was positive that could cause a one-second error in the
converted timestamps was corrected.
Thanks to Adnan Can, Garanti Teknoloji, TURKEY.
Change 28.278 Cosmetic. Variable CPGRPJOI is FORMATed DATETIME21.2.
VMACRMFV
Nov 28, 2010
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 28.277 Variables NETSNAME and UOWTIME are created in DB2ACCT so
VMACDB2H that DB2 observations with QWHCATYP=4, i.e., CICS, can be
Nov 25, 2010 merged with CICSTRAN to create PDB.ASUMUOW. Those vars
Nov 29, 2010 are now populated ONLY for DB2ACCT observations from CICS
(i.e. QWHCATYP=4). Changes to NETSNAME creation in DB2
in MXG 28.05 caused non-CICS DB2ACCT obs to have changed
values in last 4 characters that caused no harm except
to show up as differences in PROC COMPARE, but as there
is no value in creating NETSNAME for these observations,
to avoid confusion, they are no longer populated.
-However, some values of NETSNAME were not correctly
created, if the last four characters happened to contain
a period in those hex values. The logic was revised to
only scan the first 16 bytes of QWHCTOKN for the period.
-Also, if there WAS a period in the first 16 bytes, then
the resultant NETSNAME value was non-blank in the last
four bytes; now it is populated with only the first 16
bytes of QWHCTOKN in that instance.
-These MXG errors could cause PDB.ASUMUOW to have fewer
observations than it should.
Thanks to Paul Volpi, UHC, USA.
Thanks to Matthew Chappell, Queensland Dept of Transport, AUSTRALIA.
Change 28.276 ASUMHSM enhanced with optional macro to select HSM data
ANALHSM to be summarized, and ANALHSM also enhanced to support
ASUMHSM selection with BEGTIME/ENDTIME.
Nov 18, 2010
Dec 11, 2010
Thanks to Doug Medland, IBM Global Services, USA.
Change 28.275 -Support for NMON FCREAD/FCWRITE/XFERIN/XFEROUT records
EXNMONFC creates new dataset PDB.NMONFC for the Fibre Channel data
VMACNMON for AIX and Linux.
VMXGINIT -Support for NMON DISKXRFER (disk transfer reads per sec)
Nov 17, 2010 creates new variable DISKXRFR in PDB.NMONDISK.
Dec 2, 2010 -Support for DISKBUSY/READ/WRITE/XFER/BSIZE/SERV/WAIT with
Dec 9, 2010 suffixes thru 21.
-Invalid UARG record with only four fields and the fourth
containing text of PPID COMMAND THCNT USER GROUP COMMAND
is detected and printed on the log and deleted.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.274 NMON variables COMMMAND and FULLCOMD lengths increased to
VMACNMON 512 bytes to capture the full text of commands, and the
Nov 17, 2010 elements of the WORDS array are also increased to $512.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.273 MXG support for CA NSM/TNG only output 4-digit values in
VMACTNG the generated %LET statements with number of Instances,
Nov 13, 2010 creating %LET xxxxxx=12E3; which is not valid syntax for
the macro language. The %LET counters now put 6 digits.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.272 SMF fields SMF70HOF/SMF89HOF/SMF89DTO for SCRT are NOT
VMAC7072 documented that the last 3 nybbles of those 8-byte TOD
VMAC89 Clock fields can be non-zero but are NOT used by SCRT.
Nov 13, 2010 MXG input those fields, which caused fractional seconds
that did not exactly match SCRT reports. Now knowing the
idiosyncrasy of these fields, MXG now zeros those last
three nybbles prior to their input to match SCRT.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Charles E. Hackett, SCRT-IBM, USA.
Change 28.271 Site tailoring created temporary variable named COUNTER
VMAC113 in CICS exit years ago, but when they added SMF 113 to
Nov 11, 2010 their daily BUILDPDB, it died because that name was used
as an ARRAY name in VMAC113, an unacceptable use.
While the site easily renamed their temporary variable to
avoid the conflict, I changed COUNTER to CNTR113.
Change 28.270 Documentation. The successful JCLTEST9 execution prints
JCLTEST9 UNINITIALIZED variable messages in two places. There are
Nov 11, 2010 335, mostly with variable names AD0nnxxx immediately
prior to NOTE: Dataset WORK.SV01EV01 has 0 observations.
There are 120 more with various names before the
NOTE: Dataset WORK.AIXPTXIN has 0 observations.
Thanks to Andrew Woods, Interactive Data, ENGLAND.
Change 28.269 TYPE72DL NOT SORTED error after setting the Clock Back
WEEKBL3 for DST, combining daily PDBs all created by the same MXG
WEEKBL3D Version! Discovered GMTOFF72 was in BY list in VMAC7072
WEEKBLDD for TYPE72DL/TYPE72GO/TYPE72MN/TYPE72SC datasets, but not
WEEKBLDT in the WEEKBLDs. Have now added GMTOFF72 after STARTIME
WEEKBLD in all WEEKBLDs.
Nov 8, 2010 Jan 16,2011: Now, see Change 28.324.
Change 28.268 Utility program identifies all non-printable characters
UTILNPRT in the formatted value of all character variables in all
Nov 8, 2010 SAS datasets in a SAS data library. SAS Enterprise Guide
before 4.22 failed on non-printable DB2 data, so this was
written to examine what variables could cause problems.
Most variables that contain hex data in characters
are formatted with $HEX precisely to eliminate the
non-printables, or $EBCDIC field's '00'x are changed
by MXG to blanks. But some variables have mixtures of
EBCDIC and HEX; while these could be formatted $HEX,
sometimes that EBCDIC text is useful in PROC PRINTs,
and it would be lost in hex characters with $HEX, so
I leave the variable unformatted, leading to this kind
of exposure, hence the utility.
If you have a problem, just add a FORMAT vvvvvvvv $HEXnn.
statement in the EXdddddd exit for the dataset, where nn
is twice the length of the character variable.
Thanks to Stephen Hughes, Excellus, USA.
Change 28.267 Optional argument NOEXIMSG=YES added so that messages
VGETENG could be suppressed when not wanted, used internally by
Nov 5, 2010 other MXG programs that use VGETENG.
Change 28.266 MXG's IEBUPDTE-for-ASCII SAS program to create a source
IEBUPDTE directory of files from an IEBUPDTE-format input file now
Nov 4, 2010 looks for either './ ' or '.XY' in columns 1-3 to flag a
new "member", so the PRODTEST member can be read directly
without EDITing those '.XY' into the './ ' that is needed
by the z/OS PGM=IEBUPDTE.
The MXG source library has to have '.XY' inside these
members that contain a PDS in IEBUPDTE-format, because
there might still be someone actually using
PGM=IEBUPDTE on z/OS to create their MXG.SOURCLIB PDS,
if they chose to download the (ARCHAIC) ebcvvnn.ebc
EBCDIC MXG install file to z/OS, as those './ ' would
create unwanted new PDS members on z/OS.
On z/OS the tervvnn.ter tersed-PDS MXG Install File
should be downloaded instead.
-The SHAREBUFFERS options caused no harm but no value as
it's for performance when writing in-place, so it was
removed.
-The INFILE option TERMSTR=CRLF is now in comments, as it
doesn't exist in SAS V9.1.3 nor WPS, and it is only
needed if this IEBUPDTE program is executed on unix to
read a windows-created CRLF-terminated text file.
On unix, TERMSTR=LF is the default text line terminator.
Thanks to MP Welch, Aprize, Inc, USA.
====== Changes thru 28.265 were in MXG 28.07 dated Nov 5, 2010=========
Change 28.265 ASUMCACH failed INVALID ARGUMENT TO FUNCTION INPUT with
ASUMCACH DEVMODEL='3380K' (i.e., with alpha character) when the
Nov 4, 2010 new statement MODEL=INPUT(DEVMODEL,HEX8.) was executed.
Now, that statement is protected if DEVMODEL is not a hex
value (e.g., MODEL=3380x for DEVMODEL='3380K'.
Thanks to Tom Heller, CINCOM, USA.
Change 28.264 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE:
EXDB2ACR MXG 28.06 was required to process the V10 data, but now,
EXDB2ACW MXG 28.07 has full support plus the below documentation.
FORMATS
IMACDB2 -DB2 V10 Records can be compressed. Member EXITCICS is
VMACDB2 updated to decompress SMF 110-1 and SMF 100,101,102s.
VMACDB2H
VMACSMF -INVALID DATA FOR QWHSRELN is proof you have DB2 V10 SMF;
VMXGINIT QWHSRELN is not a valid "PK" value; it now has 'A1'x, so
VMXGWORL VMACDB2H was revised. The value is 10.1, not 10.0.
Jun 16, 2010 -And INPUT STATEMENT EXCEEDS RECORD error ABENDs may occur
Jun 19, 2010 because fields were inserted rather than added at the end
Jun 21, 2010 where MXG would have automatically skipped them.
Nov 4, 2010
-Subtype in SMF Header INCOMPATIBLY increased from one to
two bytes (because that's what it should have been all
along. However, only SMF 100 and 101 records populate
the subtype in the SMF Header. VMACSMF was updated to get
the DB2 version and then input the subtype correctly.
(MXG has always stored the IFCID value in SUBTYPE for the
DB2 102 trace records, since they don't have a subtype.)
-New DB2ACCGW dataset is created for each QWAR segment,
which can be used to correlate rollup records.
-Multiple SMF 100 Subtype 1 (DB2STAT1) IFCID=2 records are
now supported. These records contain only QBST or QBGL
segments and are written when more than 25 buffer pools
are used in an interval.
-Macro _SDB2STS was redesigned to correct DUPLICATE MERGE
VALUES errors that occurred only if DB2 was restarted, by
removing QWHSACE QWHSMTN from the _BDB2STS "BY list", by
interleaving the four input datasets to create STATSGROUP
to use as merge variable (QWHSSTCK cannot be used as it
not exact in all four records for each interval), and by
conditionally merging T102S225 (DB2 V8) if it exists.
The _SDB2STY macro is now a null macro and no longer
used. The new sort order for the PDB.DB2STATS dataset is
now SYSTEM QWHSSSID QWHSSTCK. A cosmetic enhancement to
VMXGWORL, NOWARN=YES, is used to suppress the MXGNOTEs
when a tested dataset is known to not always exist (used
for T102S225 in this change).
-Many new variables added to DB2ACCTx/DB2STATx by V10:
DB2ACCT:
QLACRLNU QWACPCTT
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPQRY QWACAWLH QWACARLH
DB2ACCTB:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTG:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2STAT0:
Q9STCDMD QDSTNQWC QDSTNARD QDSTMARD
D64POST A64POST A64WAIT M64DISNU M64DISPG SGETR64
SGETEXT6 SGETDEXT SFREER64 SFREEDEX DISCARDM
QWS1MCPU QWS2MCPU QWS3MCPU QWS4MCPU
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STAT1:
QISEKSPG QISEKSPA QISEKLRU QISEDLRU QISESQCB QISESQKB
QISESQCA QISESQKA
QISTRCCI QISTRCCD QISTRCCU QISTWMXA QISTWMXU QISTWCTO
QISTW4K QISTW32K
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STATB:
QBSTFLG
DB2GBPST:
QBSTFLG
-SMF 102 IFCIDs 172 and 196 were compatibly updated.
-SMF 102 IFCIDs 267, 268, 317, and 337 are now decoded.
New formats are created by the updated FORMATS member.
-These other IFCIDs in user-sent SMF files are presumably
the trace records that are normally written or needed.
They have been examined and none were change in V10:
4,5,55,87,105,140,141,173,196,199,250,254,258,261,262
-See the text of Change 28.146, which made changes to DB2
processing that were independent of the Beta.
Thanks to IBM DB2 V10 Beta for both EARLY DATA AND DOCUMENTATION!!
Change 28.263 Support for IBM/OMEGAMON XW MQ flat file (INCOMPAT) adds
VMACOMMQ new formats for UTF-8 data, and MXG only tested for up to
Nov 2, 2010 20 datasets, but there can be 26 in total.
Thanks to Michael Reffler, Credit-Suisse, USA
Change 28.262 Support for CA MIM RESOURCE SHARING R11.7 (COMPAT) adds
VMACMIM new variables to several datasets, and many variables
Nov 2, 2010 are now correctly input and formatted, especially times
in MIMCF dataset. Subtypes 0/1/2/4/5/7/8/9/256 and 256
have been tested.
Thanks to Tony Curry, BMC, USA.
Change 28.261 SAS/GRAPH example that uses PDB.ASUMCELP (LPAR-CEC level)
GRAFCEC (built by ASUM70PR) to create charts of CEC Utilization
Nov 1, 2010 for each of the engine types (CP,IFA,ZIP,IFL).
Change 28.260 IP address (45 character text) and IP Port Number were in
VMACTPX TPX Version 4.0 but were overlooked; now they are input
Oct 29, 2010 in 05/06/07/08 subtypes, when possible:
-Invalid subtype 7 records, LENGTH=101, LRECL=104, with
LEN07=93 in bytes 58-59 of the data portion indicating
the record should contain IP Address and Port, but the
record has only 44 bytes remaining in the record, i.e.
the IP Address/Port field are not present.
-Subtype 8 record with a IP Port field that is not a valid
EBCDIC numeric (>?01) with an IP Address with manually
typed all text characters (ABCDEFGHI...) caused hex dump
and error message, now both suppressed with ?? modifier.
-These records were supposedly created by TPX 5.3, but the
Version value in the records is 4.0.
Thanks to Dennis Longnecker, State of Washington Courts, USA.
Change 28.259 Pairs of spurious "WRONG LENGTH OF 200 FOR CMRDATA" log
UTILEXCL messages were printed by _BLDEXCL because only the first
Oct 29, 2010 to the three repeated (for emphasis) PUT statements was
conditional; the 2nd-3rd PUTs always printed a pair of
this warning message. Only if there are THREE adjacent
warning messages (then and now) does the warning apply.
The three PUTs are now inside a conditional DO-Group.
Thanks to Mrs. Brigitte Wallbaum, FINANZ INFORMATIK GMBH, GERMANY.
Thanks to Mr. Dieter Haak of FINANZ INFORMATIK GMBH, GERMANY.
Change 28.258 -Support for WebSphere ID=120 SUBTYPE=20 records has now
VMAC120 been validated (and rewritten) with actual data records.
VMACSMF -ID=120 SUBTYPE=20 records are INVALID because they do NOT
Nov 1, 2010 set the "RECORD CONTAINS SUBTYPES" bit in Byte One of the
SMF header (all other 120 subtypes DO set that bit), so
VMACSMF had a missing value for SUBTYPE for ID=120-20s.
Now, VMACSMF always reads the 2-byte subtype for 120s,
whether or not the bit is enabled.
-Dataset TY12020 is now populated, and the Start and Last
Datetimes are converted from GMT to Local Time Zone.
-There is an undocumented duration field SM120XZ at the
end of the subtype 20 record, following SM120XP; its has
a value about a third of the CPU duration in SM120XP.
-The offset values in the documentation are bogus; they
implied the character variables were fixed length, but in
fact, the data shows the fields are only as long as the
value in their preceding length field
-There are pairs of duplicate Subtype 20 records with all
fields except SMFTIME identical. They are not adjacent,
with 8 subtype 9 records and 3.34 seconds between them.
-Variable SM120SMF is the delay from XL Last Referenced
datetime to SMFTIME, and is as much as 10 seconds, which
is a VERY significant and unexplained delay.
The problem with a big delta is that SMFTIME must be
compared with XL to calculate the GMT Offset, because
there is no GMT Offset value in WebSphere SMF 120s.
Thanks to Paul Gordon, Bank of America, USA.
Change 28.257 ERROR: VARIABLE IDANDSUB ... with BUILDPDB will occur if
ANALID you reuse the same DSNAME with DISP=OLD for your //PDB,
Oct 28, 2010 and your old PDB library was created before MXG 27.27,
and there is a dataset PDB.ID in your old PDB library.
You need to delete that old PDB.ID dataset, e.g.:
// EXEC MXGSASV9
//PDB DD DSN=YOUR.PDB,DISP=OLD
//SYSIN DD *
PROC DELETE DATA=PDB.ID;RUN;
Prior to MXG 27.01, BUILDPDB created the PDB.ID dataset
to count SMF records, but Change 27.005 instead created
the new PDB.SMFRECNT (smaller but more information), and
left the ID dataset (which now had new variables) in the
WORK file by default. But Change 28.148 created ANALID
member to externalize the creation of PDB.SMFRECNT, which
uses %VMXGWORL to locate the ID dataset, since you could
could have tailored MXG to still keep the new ID dataset
in your PDB library. Unfortunately, if the old PDB.ID
dataset exists, the above error occurs.
-Initially, I said:
While it would be possible to detect and delete the
old PDB.ID dataset, that would require you to install
at one new MXG code member, so the simple delete above
is far simpler and safer. That the error has only
occurred once suggests that most MXG sites create a
new DSNAME (GDG or date-in-name) for each daily PDB
library (required for some job sked pkgs), or that
sites that do use DISP=OLD on their //PDB also use
PROC DELETE DATA=PDB._ALL_; before each BUILDPDB.
-However, this Change looks first for WORK.ID and variable
IDANDSUB or second for PDB.ID with that variable to build
PDB.SMFRECNT; otherwise a zero obs PDB.SMFRECNT is built.
P.S. Change 28.148 for ANALID/BUILD001/BUIL3001 was never
written up in CHANGES; a separate change got that number.
Thanks to Alan Gray, CareFirst, USA.
Change 28.256 You should not use a variable named "DATETIME" in MXG
ASUMDB2A reports, because there is always a named variable, like
ASUMDB2B QWACBSC, that is self-documenting and code-clarifying.
ASUMDB2G Variable DATETIME was intended to be a temporary token
ASUMDB2P and shouldn't have been kept, but where it slipped thru
Oct 27, 2010 and ended up being kept in MXG-built datasets, it now has
to be kept and populated. The quick fix, added in
MXG 28.06, to insert a "compiler faker" to suppress an
uninit warning, caused DATETIME to be a missing value.
The first three member's faker was replaced by code to
create/populate DATETIME, and the faker was removed from
ASUMDB2P where it was never kept.
Feb 4: Cosmetic. Variable DATETIME is now length 8.
Thanks to Jim Kovarik, AEGON USA, USA.
Change 28.255 Variable SMF30DAS='EXCP*SEGMENTS*THAT WERE*SUPPRESSED'
VMAC30 was INPUT but not kept. EXCP segments can be suppressed
Oct 27, 2010 with EMPTYEXCPSEC(SUPPRESS) option in SYS1.PARMLIB, or
by DB2 V10 APAR PM17542 which enables S99DASUP.
Change 28.254 The protection for OFF42S3 NE 108 added in Change 28.093
VMAC42 was no protection as it caused misalignment and is now
Oct 26, 2010 removed. With that protection removed, reading the old
data, I now detect, legitimately, an invalid S4 record
with 21 segments totaling 27888 starting at 4053 for an
expected 31944 bytes but the record LENGTH is only 31832.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 28.253 Variables R85STOUT, R85OLRD and R85NLRD are created in
VMAC85 TYPE85AC dataset.
Oct 26, 2010
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Thanks to Jens Mohring, Huk-Coburg, GERMANY.
Change 28.252 Missing semicolon after PROC DATASETS caused Accounting
ANALDB2R reports fields AUTHID DB2 CONNID CORRED to not be
Oct 26, 2010 correctly translated and propagated, and caused attempt
to delete dataset named RUN;
ACCTSORT option added.
Change 28.251 -Assembly of MXG 28.06 EXITCICS fails with this message:
EXITCICS 346 * DC XL2'0000' For Debug purposes RHA
Oct 26, 2010 JZ OPENX no...
** ASMA144E Begin-to-continue columns not blank - JZ
because I had accidentally moved that RHA text in source
line 361 in EXITCICS into column 72, making the statement
a continuation.
code and the decompression exit, when storing into the
MXG Source Library.
-SYSLIB DD needed a third concatenation for the site's
CICS Macro Library.
Thanks to Ken Goodis, Emblem Health, USA.
Change 28.250 -COPYONLY= logic was still dysfunctional. Change 28.211
READDB2 did not proper locate the selection by IFCID, and now the
Oct 26, 2010 SUBTYPE, decoded by VMACSMF, is used for COPYONLY.
-NOTE: VARIABLE QWHCCCN UNINITIALIZED because it should
have been spelled QWHCCN. If CONNID=xxxxxxx selection
was requested in ANALDB2R, this error caused zero obs
to be selected.
-Option UNIQUE will write each DB2 dataset to its unique
DDNAME (e.g., DB2ACCTP to DB2ACCTP.DB2ACCTP) for all of
the datasets that would likely be kept.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 28.249 VMXGSUM is enhanced with MODE= and MEDIAN= added so those
VMXGSUM statistics can be created. The complete list of all of
OCT 20, 2010 the statistics that VMXGSUM can be created:
MEAN MEAN (AVG) P1 PERCENTILE 1%
MIN MINIMUM P5 PERCENTILE 5%
MINLONG MINIMUM 8 BYTE P10 PERCENTILE 10%
MAX MAXIMUM P25 PERCENTILE 25%
MAXLONG MAXIMUM 8 BYTE P50 PERCENTILE 50%
SUM SUM 4 BYTES P75 PERCENTILE 75%
SUMLONG SUM 8 BYTES P90 PERCENTILE 90%
FREQ NUMBER OBS P95 PERCENTILE 95%
STD STANDARD DEVIATION P99 PERCENTILE 99%
VAR variance T Students T
CV coeff of Variation STDERR Standard Error
MEDIAN median KURTOSIS Kurtosis
MODE= mode
With AUTONAME=YES the variables will be named
variable-name_statistic-name e.g., XXXXXXXX_SUM
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.247A The DOCMXG example using _Kdddddd to create a new dataset
VMAC110 is revised so it works, and its exceptions documented:
Oct 20, 2010 1. The %QUOTE(text) function is needed around text that
contains semicolons (which would otherwise end the
%LET statement).
2. But %QUOTE(text) cannot be used if a close paren is in
the text.
3. So the macros with no semicolons are first, followed
by those that contain semicolons in the %QUOTE(text).
4. When redefining MACRO _Edddddd you can use syntax of
a. %%%INCLUDE of the EXdddddd member, and whatever
logic is in that Exit member will then determine
which obs are output. I can't explain why THREE
percent signs are required here, but they are.
b. OUTPUT ddname.dataset syntax to output all obs
to both datasets, or you can use the IF condition
DO group to select which obs to output.
c. NEVER use a DELETE; statement in _Edddddd exits.
Always use a positive IF condition THEN DO; group.
The DELETE statement terminates reading of the SMF
record, which would prevent the reading of any of
the additional repeated segments.
5. You can also specify COMPRESS=NO in the _Kdddddd to
override the MXG COMPRESS=YES default, by putting
COMPRESS=NO before the close paren for that dataset.
6. The example uses _N110 to null all of the 110 datasets
so that ONLY the datasets "reinstated" by defining
their _Wdddddd macro will be created.
%LET MACKEEP=
_N110
MACRO _KCICTRN COMPRESS=NO)
&PDB..NEWDS (KEEP=ABCODE APPLID ENDTIME
FCTOTCN PROGRAM SYSTEM
STRTTIME TASCPUTM TDTOTCN
TRANNAME TSTOTCN
%
MACRO _WCICTRN CICSTRAN.CICSTRAN %
%QUOTE(
MACRO _ECICTRN
%%%INCLUDE SOURCLIB(EXCICTRN);
IF CONDITION THEN DO;
OUTPUT &PDB..NEWDS;
END;
%
);
%INCLUDE SOURCLIB(TYPE110);
-The _N110 macro in VMAC110 was updated in this change to
also null the CICSBAD dataset, which had been overlooked.
Thanks to Brian A. Harvey, HCL America, USA.
Change 28.247 GRAPHICS=NO/YES added as an option. If you do not have
ANALCAPD SAS/GRAPH it will automatically be set to NO, but if we
OCT 19, 2010 detect SAS/GRAPH but you only want a printer plot, you
Oct 26, 2010 can specify GRAPHICS=NO. For readable non-graphics plots
the values being generated by the PROC FORMAT for TYPE
now use the first character.
-Oct 26: Uninitialized LQxLAC, LQxMSU & LQxMSU70 variables
were harmless variables that didn't exist in ASUMCEC.
Thanks to Michael Marcus, ATOS Origin, USA.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 28.246 -ITRM Validation of MXG 28.06 for their next dictionary
VMAC30 precipitated these discoveries and corrections:
VMAC7072 -VMAC30: New Initiator CPU time at INIT and TERM variables
VMACDB2 CPITCTTM CPITCITM CPISRTTM CPISRITM
VMACIMSA were wrong in 28.06; they were INFORMATed and FORMATed
VMACNTSM incorrectly with PIB4.6 instead of PIB4.2 and TIME12.2.
Oct 22, 2010 The wrong FORMAT caused their values to print as trash,
ASUMMIPS the wrong INFORMAT caused their value to be wrong, too
Oct 28, 2010 small by a factor of 10**4.
Nov 14, 2010 These four new CPI CPU times are important and discussed
in Change 28.175.
-VMAC7072: Counter NBKDUPE should not have been kept in
dataset TYPE70EN, and now isn't.
And all of these variables for Engines 64-95 should never
have been kept in PDB.TYPE70 and are now DROPped:
CAIVA -CAIVI CAIYD -CAIYZ
CPUEDTVA CPUEDTVI CPUEDTYD-CPUEDTYZ
CPUPATVA-CPUPATVI CPUPATYD-CPUPATYZ
CPUPDTVA-CPUPDTVI CPUPDTYD-CPUPDTYZ
CPUWAIVA-CPUWAIVI CPUWAIYD-CPUWAIYZ
IFATYPVA-IFATYPVI IFATYPYD-IFATYPYZ
IFAWAIVA-IFAWAIVI IFAWAIYD-IFAWAIYZ
IORATEVA-IORATEVI IORATEYD-IORATEYZ
MVSWAIVA-MVSWAIVI MVSWAIYD-MVSWAIYZ
PCTCIBXD-PCTCIBxz PCTCIBUa-PCTCIBUi
LCPUDEXD-LCPUDExz LCPUDEUa-LCPUDEUi
LCPUWAXD-LCPUWAxz LCPUWAUa-LCPUWAUi
PCTCPBXD-PCTCPBxz PCTCPBUa-PCTCPBUi
PCTONLVA-PCTONLVI PCTONLYD-PCTONLYZ
ZIPWAIVA-ZIPWAIVI ZIPWAIYD-ZIPWAIYZ
If OPTIONS DKROCOND=WARN is used, there will be
messages on the log:
WARNING: variable LCPUDExx in the DROP KEEP...
WARNING: variable LCPUWAxx in the DROP KEEP...
that are not errors and are normal.
-VMACDB2: Variables QWARACE/QWARBSC/QWARESC are Labeled in
new in Version 10 dataset DB2ACCTW. Variable DB2START is
now labeled, and STA0DUR and STA1DUR are formatted.
-SAPIMSBA, SAPIMSON, SAPIMSSP datasets created by TYPEIMSA
processing in JCLIMSLx/ASMIMSLx IMS Log Processing kept
ALL-POSSIBLE 937 variables instead of 31/33/30 kept; MXG
Change 28.066 updated VMACIMSA to use the three _VSAPxxx
macro tokens for their KEEP=list, but then failed to fill
them with the KEEP= syntax and the list of variables to
be kept. Now, only the intended SAP variables are kept
in the three (optional) datasets. And variable IMSRECCH
is now labeled IMS*RECORD*NUMBER*AS HEX CHAR.
-VMACNTSM: Variable VWGRACQP was corrected to VWGRAC1P.
-ASUMMIPS: Datasets/variables were labeled/formatted.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 28.245 MXG 28.06 added ASUMDB2G/ASUMDB2P/ASUMDBSB/ASUMDBSS to
WEEKBLD WEEKBLD, but are now removed. None of those optional data
BLDSMPDB sets should have been added, since neither was previously
Oct 19, 2010 created by prior JCLPDB6 examples. If your BUILDPDB JOB
didn't create them, then WEEKBLD in 28.06 failed with
ERROR: VARIABLE SYSTEM NOT FOUND ON MON.ASUMDB2G
-I had presumed you would EDIT your WEEKBLD to remove
datasets you don't want weekly, and would use EXPDBWEK
exit to add any new datasets to your WEEKBLD output.
-But henceforth, I will NOT add any new optional datasets
to the defaults in WEEKBLD and MONTHBLD examples.
-There is an alternative to WEEKBLD and MONTHBLD to use:
The BLDSMPDB example can EASILY be set up to run daily
to create your daily PDB, and it dynamically creates your
weekly PDB from whatever datasets exist in your daily PDB
libraries, and similarly creates your monthly PDB from
whatever datasets are found in its weekly/daily PDBs.
And you can drop unwanted datasets easily as well.
Thanks to William Edwards, Blue Cross and Blue Shield of Florida, USA
Change 28.244 STC/STK/Oracle VSM "user" SMF records support revised.
VMACSTC -Most datetime variables are changed from GMT to LOCAL.
Oct 19, 2010 These were overlooked. MXG always converts datetimes on
GMT to LOCAL zone, when the GMT offset is known or can be
determined (i.e., when the records have a GMT END time to
match with the always-LOCAL-zone SMFTIME).
Dataset Variables now on LOCAL
STCVSM13 STC13MET STC13MST STC13TIM
STCVSM14 STC14TIM STC14RUN
STCVSM16 STC16MET STC13MST
STCVSM18 STC18MET STC13MST
STCVSM19 STC19TIM STC19RET STC19RST
STCVSM20 STC20MET STC20MST
These variables are now in %VMXGTIME with GMT=YES.
But these datetimes are for events that can be days or
weeks earlier, and the GMT Offset can't be known from the
SMF record, so they are left on GMT, but their LABEL now
contains "ON GMT" to flag them as still on GMT:
Dataset Variables
STCVSM15 STC15LTR STC15TIM
STCVSM25 STC25LUT STC25LWT
STCVSM27 STC27LUS STC27TIM
These variables are now in %VMXGTIME with GMT=YES.
Yes, this is INCOMPATIBLE, if your reporting code changes
the time zone for those former GMT-containing variables.
-STC/STK/Oracle VSM SMF records' _SSTCvvv macros are now
correctly implemented with PROC SORT NODUP and with BY
lists that remove duplicates (and datasets STCVSM25 and
STCVSM27 appear to have occasional fully duplicated SMF
records that are detected and deleted).
-Datasets STCVSM10, STCVSM11, and STCVSM20 are interval
datasets, and their _S Sort Macros create new variables
STCSTRTM='INTERVAL*STARTIME' DELTATM='INTERVAL*DURATION'.
-But Dataset STCVSM20, the Interval RTD utilization data,
which was the actual purpose of this examination of STC
data, has serious holes. The STC20ATM Device Available
time is frequently zero for several 15-minute intervals
but then the next interval record has what appears to be
the total Available Time since the last interval record
with a non-zero value. This means that individual hour
intervals can't be safely analyzed, but by summing the
interval data to the SHIFT or DATE level should provide
reasonable valid data. A problem report will be opened
with Oracle technical support.
Change 28.243 Cosmetic. The MXGNOTE that a SEQUENTIAL or EXPORT format
VGETOBS dataset was found by VGETOBS was revised; that note is
VMXGSUM harmless and is only printed to be in the log in case of
Oct 15, 2010 a subsequent error; in some reports with multiple inputs,
"TAPE" data libraries cannot be used, and this message is
useful to diagnose those (rare) problems. But also, the
call to VGETOBS in VMXGSUM suppresses the message for the
many cases where we know it doesn't matter.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 28.242 The New-in-z/OS 1.12 "In-Ready Work Unit" SMF70U00-U15
VMAC7072 distribution variables (which include ALL engine types)
VMXGRMFI and the three average variables for each engine type
Oct 26,2010 SMF70CTT='AVG*WORK UNITS*FOR CP-S'
SMF70DTT='AVG*WORK UNITS*FOR ZAAPS'
SMF70ETT='AVG*WORK UNITS*FOR ZIIPS'
were not divided by SMF70SRM (sample count) in TYPE70.
These should replace the old READYAVG metrics, per Don:
Be aware that READYAVG deals only with ready address
spaces. The number of ready address spaces can present
a seriously misleading impression of the work on the
system and work being delayed, because READYAVG does
not measure total dispatachable work units. Both the
ready address spaces and the ready enclaves must be
included to count the total dispatachable work units,
and new-in-z/OS-1.12, the above variables provide the
min/max/avg number of work units for CP-s,zAAPs/ZIIPS
and the new PCTWUQWT and SMF70U00-SMF70U15 metrics for
dispatchable work units, quite similar to the original
measures for ready ASIDs.
In addition to correcting the values, this change adds
those min/max/avg Work Unit variables to RMFINTRV, and
three percentage waiting variables are now created from
the three distributions (READYxx, SMF70Qxx, SMF70Uxx)
and are kept in both TYPE70 and RMFINTRV datasets.
PCTRDYWT='PERCENT WHEN*READY TASKS*ARE WAITING'
PCTRDQWT='PERCENT WHEN*IN READY TASKS*ARE WAITING'
PCTWUQWT='PERCENT WHEN*WORK UNITS*ARE WAITING'
These new work unit distributions are only kept in TYPE70
and they include the waiting and active work units for
all engine types, so my labels are revised. The N value
is the count of ALL online engines, except that when
HyperDispatch is active, only the non-parked engines of
ALLl types are included in the N being compared.
SMF70U00='PCT WHEN*WORK UNITS*WAS LE N ONLINE'
SMF70U01='PCT WHEN*WORK UNITS*WAS N+1 ONLINE'
SMF70U02='PCT WHEN*WORK UNITS*WAS N+2 ONLINE'
SMF70U03='PCT WHEN*WORK UNITS*WAS N+3 ONLINE'
SMF70U04='PCT WHEN*WORK UNITS*WAS N+4-5 ONLINE'
SMF70U05='PCT WHEN*WORK UNITS*WAS N+6-10 ONLINE'
SMF70U06='PCT WHEN*WORK UNITS*WAS N+11-15 ONLINE'
SMF70U07='PCT WHEN*WORK UNITS*WAS N+16-20 ONLINE'
SMF70U08='PCT WHEN*WORK UNITS*WAS N+21-30 ONLINE'
SMF70U09='PCT WHEN*WORK UNITS*WAS N+31-40 ONLINE'
SMF70U10='PCT WHEN*WORK UNITS*WAS N+41-60 ONLINE'
SMF70U11='PCT WHEN*WORK UNITS*WAS N+61-80 ONLINE'
SMF70U12='PCT WHEN*WORK UNITS*WAS N+81-100 ONLINE'
SMF70U13='PCT WHEN*WORK UNITS*WAS N+101-120 ONLINE'
SMF70U14='PCT WHEN*WORK UNITS*WAS N+121-150 ONLINE'
SMF70U15='PCT WHEN*WORK UNITS*WAS GT N+150 ONLINE'
They can be compared with the existing distributions in
READY00-READY15,SMF70Q00-SMF70Q12 in TYPE70 dataset.
-VMXGRMFI was also corrected to support R70MIN, which has
been defined, but as it had a null value, the absence of
its invocation was never noticed until now.
-In testing this change, Jim noticed SMF70NCA needed to be
multiplied by 100 as it is 'PCT WHEN*CAPPING*LIMITED...'.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.241 -Variable CPUWAIYA (CPU WAIT*DURATION*CPU 61) was wrong.
VMAC7072 The typo'd CPUWAIYA=MVSWAITA is now CPUWAIYA=MVSWAIYA.
Oct 14, 2010
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 28.240 -UTILEXCL could create wrong values in PDB.CICSDICT if
IMACICUN CICS dictionary entries with the same "triplet" values
IMACICUO RVR/DCN/DRL have the same CMODIDNT (field number) in
IMACICUP different orders (could be in different or same APPLID).
UTILEXCL These wrong values were then used to create the IMACEXCL
VMAC110 tailoring member, but that caused no execution error.
Oct 13, 2010 But the wrong variable(s) in CICSTRAN were populated or
IMACICUQ had missing values when they should have been populated.
Oct 14, 2010
Dec 22, 2010 But even after installing this change, and rerunning the
new UTILEXCL's _BLDDICT to build the correct PDB.CICSDICT
observations, your IMACEXCL could still be wrong, because
_BLDDICT appends the new dictionary records to the old in
its replacement of PDB.CICSDICT, so both good and bad
records were still being used, causing that same error.
If you have the SMF records for all your current CICSs,
then you can simply use PROC DELETE DATA=PDB.CICSDICT;
to delete that dataset, and then rerun _BLDDICT, etc.
PROC DELETE DATA=PDB.CICSDICT;
and then _BLDDICT _BLDEXCL _RPTEXCL
to use only the fixed PDB.CICSDICT records to build your
tailored IMACEXCL.
Dec 22: Above paragraph was added, no code was changed.
-Dictionary records with duplicate RVR/DCN/DRL. but with
different field order are now detected and printed by the
macro _BLDEXCL when it creates the IMACEXCL, but UTILEXCL
cannot support two different records differently; as only
the RVR/DCN/DRL exist in the CICSTRAN records. UTILEXCL
can only create one "do group" from the first dictionary
record and that IMACEXCL will create CICSTRAN for all SMF
records that RVR/DCN/DRL, with no execution errors, but
all variables from the fields/segments that are different
in the second dictionary record will be wrong. MXG can't
fix this error because only the RVR/DCN/DRL exist in the
CICSTRAN records. Your CICS guru will have to correct the
DFHMCT text so all structures with the same number and
length of fields have their fields in the same order.
-Support for more Optional CICS fields, UTILEXCL Error.
Member Variable Label
IMACICUN SCBKPOUN Application*USER*AREA*ONE
IMACICUO SCBKNUMB Application*USER*AREA*TWO
IMACICUP CIBIZID Application*USER*AREA*THREE
-Support for another optional CICS field
Member Variable Label
IMACICUQ CANUE1 CANUE1
Thanks to Tony Hirst, Wells Fargo, USA.
Thanks to Henry Steinhauer, Northwestern Mutual, USA.
Thanks to James Hein, Erie Indemnity Company, USA.
====== Changes thru 28.239 were in MXG 28.06 dated Oct 7, 2010=========
Change 28.239 Documentation Notes only. Using the _N7072 "null" macro
VMAC7072 to create ONLY the PDB.TYPE70 dataset caused errors
Oct 7, 2010 NO DATA SET OPEN TO LOOK UP VARIABLES
when PROC SORT DATA=_NULL_ (were _NULL_ replace TYPE70EC)
caused SAS to error (in spite of _NULL_, PROC SORT still
looked for BY variables). Recent changes in SMF 70s now
requires datasets TYPE70SP/EC/EL to be created when the
SMF data is processed, the TYPE70PR data values are used
to create TYPE70, and the new TYPE70EN dataset must be
created from the (temporary) TYPE70EN/EL data if you have
more than 64 engines, since only the first 64 engine's
per-engine-detail is kept in TYPE70.
But the below tailoring example shows how these old-style
substitution macros are used to create only the datasets
PDB.TYPE70 and PDB.TYPE70EN, by reinstating the _Wdddddd
dataset tokens to be created when SMF is read, and the
two _Ldddddd output dataset tokens for clarity.
%LET MACKEEP=%QUOTE(
_N7072
MACRO _WTY70 TYPE70 %
MACRO _WTY70PR TYPE70PR %
MACRO _WTY70SP TYPE70SP %
MACRO _WTY70EC TYPE70EC %
MACRO _WTY70EL TYPE70EL %
MACRO _LTY70 PDB.TYPE70 %
MACRO _LTY70EN PDB.TYPE70EN%
);
%INCLUDE SOURCLIB(VMACSMF,VMAC7072,IMACKEEP);
DATA
_VAR7072
_SMF
_CDE7072
_STY70
Or, you could use the %UTILBLDP macro to generate and
execute the code to create only those two datasets:
%LET PTY70PR =WORK; %LET PTY7002 =WORK;
%LET PTY70X2 =WORK; %LET PTY70Y2 =WORK;
%LET PTY72 =WORK; %LET PTY72DL =WORK;
%LET PTY72GO =WORK; %LET PTY7204 =WORK;
%LET PTY72MN =WORK; %LET PTY72SC =WORK;
%UTILBLDP(BUILDPDB=NO,USERADD=7072,OUTFILE=INSTREAM);
The %UTILBLDP macro is STRONGLY recommended for any SMF
processing that needs tailoring.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.238 MXG 28.03-28.05. THE SMF FILE CONTAINED xxx BYTES note on
VMACSMF the SAS log was wrong if BUILDPDB was used; Change 28.089
Oct 7, 2010 modified VMACID to output SMFBYTES, but that variable was
used internally in VMACSMF to total the byte count for
that log message. The byte counter in VMACSMF is changed
to SMFBYTOT to correct the message and not impact ID.
When wrong, xxx had the record length of the LAST record.
Thanks to Rudol Sauer, T-Systems International GmbH, GERMANY.
Change 28.237 Variable R792PRFX was labeled FRAMES (MB) but was not
VMAC79 converted from frames. While the (MB) in the LABEL should
Oct 7, 2010 document when frame counts are converted to bytes, those
variables must also have MGBYTES. format to confirm that
the contents of the variable is bytes and "prints pretty"
with K/M/G/T suffix with that format.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 28.236 With some of the features of Thruput Manager, some shops
ANALINIT run all jobs in the same job class. That makes ANALINIT
Oct 5, 2010 by jobclass mostly meaningless since TPM will prioritize
work based on service class and other criteria given it
via parameter. This change allows you to choose the
variable to use for breaking the report down. The default
value for SORTBY is JOBCLASS but you might find in these
cases that SRVCLASS or RPTCLASS have more meaning.
-HTMLDEST is also added as a parameter to send the output
to HTML and the MEAN/MAX input queue delays are added to
the final report.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.235 Using %VGETDDS(GOOVOO=gdgbase) caused ERROR: LIBRARY DOES
VGETDDS NOT EXIST. The wrong macro variable &GDGBASE was used
Oct 4, 2010 where &GOOVOO was required.
Thanks to Brian A. Harvey, HCL America, USA.
Thanks to Rhonda Martin, USAA, USA.
Change 28.234 Variables input with $EBCDIC informat that contain $HEX
VMAC102 data are corrected to $CHAR informat, but that is only
VMACCIMS impacting if MXG is executed on ASCII platforms to read
VMACORAC SMF data. Detected in Freddie's final QA tests.
Oct 4, 2010 -VMAC102: QW0022LM QW0022PA QBMCRLIR
-VMACCIMS: RECSTAT
-VMACORAC: ORALOGON
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 28.233 Support for WebSphere MQ Version 7 Accounting Records.
EXWSMQMQ Two datasets are created:
EXWSMQQ dddddd Dataset Description
IMACWSMQ WSMQMQ WSMQMQI Accounting MQI
TYPEWSMQ WSMQQ WSMQQ Accounting Q
TYPSWSMQ See Monitoring WebSphere MQ Version 7, SC34-6937, for the
VMACWSMQ documentation on these data, which are written to the
VMXGINIT SYSTEM.ADMIN.ACCOUNTING.QUEUE.
Oct 2, 2010
Change 28.232 -ANALRMFR failed when PDB=SMF was use with some reports;
ANALRMFR Change 28.155 revised token names for TYPE70EN, and some
Oct 6, 2010 resets of _WTY70PR were missing.
-While PDBOUT=PDB worked, PDBOUT=XXXX failed because the
new TYPE70EN dataset was written to PDB instead of XXXX.
Thanks to Russ Alexander, OIT Service Delivery, USA.
Change 28.231 NDM-CDI NDRMTYPE='RT' record INPUT STATEMENT EXCEEDED
VMACNDM error when NDMOFFPA was non-zero, a condition not seen
Oct 1, 2010 before, and my guess about the order of the optional
segments was wrong.
Thanks to Douglas C. Walter, Citigroup, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 28.230 FORMAT MG070CR decodes SMF70CCR to identify the Capacity
FORMATS Change Reason:
VMAC7072 SMF70CCR Formatted Value
Oct 1, 2010 0 0:NO CHANGE
1 1:POWERSAVE
2 2:CYCLE STEERING
3 3:EXTERNAL
4 4:EXTERNAL
Change 28.229 MXG Search tool did not select CHAR variables because the
VMXGSRCH TYPE field was not UPCASED, and if the last variable in a
Sep 30, 2010 dataset is numeric, the generated code did not wrap to
close the continuation correctly; these are now fixed.
Also, MXG 28.05 updates added the capability to search
for text in Labels and for format names.
On a positive note, Scott commented:
I really do get a lot of benefit using VMXGSRCH when
looking for evidence of a dataset or USERID or a CICS
terminal-name. It's a great tool, particularly where I
needed to find evidence of a CICS terminal in some CICS
PA report, but looking in MXG for it CICS STATS.
And VMXGSRCH is not only for MXG built datasets. VMXGSRCH
will search ALL of the SAS datasets in ANY data library,
searching ALL variables in those datasets for ANY value,
printing the found observations. See Change 28.147.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.228 Variable NRCPUS wrong in PDB.RMFINTRV with HiperDispatch.
VMXGRMFI It had the number of installed processors because parked
Sep 29, 2010 time, CPUPATTM, was not kept nor subtracted from SMF70ONT
when NRCPUS, the average number of ONLINE CP engines was
calculated.
Thanks to Richard Schwartz, State Street Bank, USA.
Thanks to Brian Kruse, State Street Bank, USA.
Change 28.227 TYPEITRF INPUT STATEMENT EXCEEDED RECORD LENGTH type=17x.
VMACITRF because Change 28.197 didn't correctly INPUT these fields
Sep 27, 2010 CORDBI CORDBP CORDBT that were added.
Thanks to Lindholm Orjan, Volvo, SWEDEN.
Change 28.226 -TYPE113 variable LPBUSY replaces wrong-named LPARCPU, as
ASUM113 percent busy in TYPE113 is for each Logical Processor.
VMAC113 -ASUM113 variable LPARBUSY replaces LPARCPU since there,
Sep 23, 2010 the percent busy is for the LPAR. New variable LPARCPUS
Oct 4, 2010 counts the number of LPs active in this LPAR.
Normally, I'm reluctant to change variable names, but
the SMF 113 is new so only a few "early adopters" will
be effected, and the old names were deceptively wrong.
-LPARCPUS is the true Average Number of ONLINE Engines, as
it is calculated as SMF70ONT/DELTATM.
-Variables from TYPE70PR that were added to the dataset
PDB.TYPE113 are also now added to PDB.ASUM113.
-ASUM113 corrected to not fail when PDB.TYPE70PR doesn't
exist, but all variables that are merged in from 70PR
will always exist in PDB.ASUM113, with missing values if
there was not 70PR dataset.
-SM113CPT is only populated if SM113VN2 GE 2, i.e., z196.
(See Change 30.123 for revision).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.225 Macro variable VGETCRDT is created, contains the datetime
VGETOBS in character when the SAS dataset was created, and macro
Sep 23, 2010 variable VGETMTYP is the type of dataset (data/view/etc).
Oct 5, 2010 VGETCRDT is only populated under SAS; it is not in WPS.
Thanks to MP Welch, Aprize, Inc, USA.
Change 28.224 New TYPE70EN dataset (per-Engine TYPE70 detail) had 100%
VMAC7072 PCTCPUBY for Parked Engines; PCTCPUBY is now recalculated
Sep 23, 2010 using SMF70PAT. Also, SMF70CIN was blank, now is not.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.223 Support for DB2 V10 Compressed SMF records has been added
DFH$MOLS inside the existing EXITCICS member, which is the ASM
EXITCICS source that creates a SAS INFILE EXIT named CICSIFUE.
Sep 23, 2010 Once assembled into a load module placed in //STEPLIB,
and enabled with %LET SMFEXIT=CICS; in your //SYSIN,
the exit will be used for either CICS or DB2 records,
processing either compressed or uncompressed SMF records.
Full documentation is in the comments in EXITCICS member.
While IBM CICS provides their DFH$MOLS program that will
decompress CICS records (JCL example in that MXG member),
IBM initially chose NOT to provide a DB2 decompression
utility, but in Feb, 2011, APAR PM27872 announced that
the DSNTSMFD sample program was available to decompress.
Note: IF THE EXIT DOES NOT EXIST, INTERNAL SAS CODE IN
MXG WILL BE USED TO DECOMPRESS EITHER CICS OR DB2
DATA, BUT THAT CODE IS EXTREMELY CPU EXPENSIVE.
MXG messages warn you to instead use EXITCICS.
Note: See MXG Newsletter FIFTY-SEVEN for comparisons
processing compressed and uncompressed CICS data
with DFH$MOLS versus EXITCICS versus SAS code.
Thanks to Rich Anderson, SAS Institute, USA.
Change 28.222 ITRM only, MXG 28.04-later, DB2STAT4 NOT SORTED ERROR.
VMACDB2 The circumvention is to insert this statement in SYSIN:
Sep 22, 2010 %LET EPDBOUT= _SDB2ST4 ;
so that the DB2STAT4 dataset is sorted before _SDB2STS
is executed. _SDB2STS creates DB2STATS from STAT0/1/4;
The MXG logic in _SDB2STS was revised in 28.04, and the
PROC SORT DATA=_LDB2ST4 that had been in _SDB2STS was
removed, because MXG executes _SDB2ST4 before _SDB2STS,
so that sort was no longer needed. But ITRM did not
execute the _SDB2ST4 macro. In ITRM, the dataset tokens
_WDB2ST4 and _LDB2ST4 are the same dataset when _SDB2STS
is executed, so that old PROC SORT DATA=_LDB2ST4 had put
DB2STAT4 in the right order, so there was no error, but
without MY sort, the unsorted DB2STAT4 exposed my error.
-ITRM Support will have a Hot Fix to insert the _SDB2ST4
sort prior to the _SDB2STS execution; fortunately, this
circumvention AND that hot fix insertion can coexist.
Change 28.221 MXG 28.05-minus, an INCORRECT note "INVALID WQ SEGMENT"
VMAC116 is harmless and there is no loss of data when the records
Oct 7, 2010 originally described below are found. IBM MQ Support has
confirmed Qsegment records with no WQ Segments can
happen in V6 and V7 if a thread has exactly 9 queues.
The next overflow SMF record/segment is allocated in
anticipation of the transaction a 10th queue. With
exactly 9, a 10th wasn't opened, so the second segment
was left empty.
Oct 20, IBM APAR PM24302 confirms that statement, quoting
from my original change text in the problem description.
Below is the Sep 22 original change text on this message:
WebSphere MQ 7.01 INVALID WQ SEGMENT error messages were
due to SMF 116 subtype 2 records that contained only the
WTID (thread identification) segment and did NOT contain
any WQ (queue-level accounting) segments. The ONLY
purpose of subtype 2 records is for additional WQ
segments that wouldn't fit in previous subtype 1 record.
In addition, the QWHCXTYP field contained a zero, which
is not a documented connecting system type code. But,
MXG printed that message because it expected the WQ
triplet in the subtype 2 and unconditionally input it.
The code was restructured to input the common header and
use QWHSNSDA, the number of triplets, to conditionally
now input the triplets. Subtype 2 records with no WQ
segment can be detected because all WQxxxxxx variables in
dataset MQMACCTQ will be blank or missing values, but the
"INVALID" "INVALID WQ SEGMENT" message is gone.
Thanks to Victoria Lepak, Aetna, USA.
Change 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx members are
ANALDB2R revised to create consistent names, as well as adding
ASUMDB2A new DB2 V9 and DB2 V10 variables and externalizing the
ASUMDB2B interval value:
ASUMDB2G -Default interval for both statistics and accounting is
ASUMDB2P now set by macroUvariable &INTASUM (default=HOUR), so
ASUMDB2R youTcanDchangeTthatBdefaultSinterval externally, without
ASUMDB2S EDITing the ASUMxxxxSinto yourDUSERID.SOURCLIB, using
ASUMDBAA %LET INTASUM=yourchoice;SUtoBset your chosen interval.
ASUMDBSB -Statistic dataset changes:
ASUMDBSS -Datasets ASUMDBBS/TRNDDBBS renamed to ASUMDBSB/TRNDDBSB.
TRNDDB2A -Datasets ASUMDB2S/ASUMDB2G/ASUMDB2B/ASUMDBSB that were
TRNDDB2A created by members ASUMDB2S/ASUMDB2G/ASUMDB2B/ASUMDBSB
TRNDDB2B no longer exist; datasets TRNDDB2X/TRDDDBBS/TRNDDB2S
TRNDDB2G no longer exist.
TRNDDB2P -Members ASUMDBSS/TRNDDBSS create these sets of the three
TRNDDB2R statistics summary datasets:
TRNDDB2S Member Dataset Created from
TRNDDBAA ASUMDBSS ASUMDBSS DB2STATS
TRNDDBSS " ASUMDBSB DB2STATB
Oct 3, 2010 " ASUMDBSG DB2GBPST
Dec 28, 2010 TRNDDBSS TRNDDBSS ASUMDBSS
" TRNDDBSB ASUMDBSB
" TRNDDBSG ASUMDBSG
-Accounting dataset changes:
-Members ASUMDB2S/ASUMDBSB contain only comments that the
member ASUMDBSS should be used in place of both members.
-Members ASUMDB2G/ASUMDB2B were a mess. Previously they
summed DB2GBPST/DB2STATB into ASUMDB2G/ASUMDB2B datasets
but those names were also used for DB2ACCTG/DB2ACCTB
summarization. Now they process only Account datasets.
-WEEKBLD's BY list for these three DB2 Stat ASUMs have
SHIFT removed; those datasets are summarized by HOUR so
SHIFT was not used, but was inconsistently kept, so its
removal prevents NOT SORTED errors.
-Accounting dataset changes:
-Member VMXGDBAA, previously used in ASUMDBAA/ANALDB2R
no longer is used and is archaic. Member ASUMDBAA can
still be used, if you want ALL of the DB2ACCTx datasets
summarized, but it now is only a series of individual
%INCLUDEs of these members:
Member Dataset Created from
ASUMDB2A ASUMDB2A DB2ACCT
ASUMDB2B ASUMDB2B DB2ACCTB
ASUMDB2G ASUMDB2G DB2GBPST
ASUMDB2P ASUMDB2P DB2ACCTP
ASUMDB2R ASUMDB2R DB2ACCTR
-Trending of individual ASUMDB2x Account datasets:
Member Dataset Created from or
TRNDDB2A TRNDDB2A ASUMDB2A DB2ACCT
TRNDDB2B TRNDDB2B ASUMDB2B DB2ACCTB
TRNDDB2G TRNDDB2G ASUMDB2G DB2GBPST
TRNDDB2P TRNDDB2P ASUMDB2P DB2ACCTP
TRNDDB2R TRNDDB2R ASUMDB2R DB2ACCTR
-Additional corrections:
-ASUMDB2A. Two variables QTXANPL and QXCASCDP were in the
SUM list are moved to the MAX list. They were incorrect
in datasets built by the old ASUM/TRND members.
-TRNDDB2A. Looked for DB2ACCT first, but now it uses
ASUMDB2A first if it exists.
-VMACDB2 common variables added to new DB2ACCTR "Remote".
-Dec 28: ASUMDB2R INTERVAL now set by &INTASUM.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.219 Cosmetic. If DATETIME argument was missing, the ABORT
VMXGDUR statement blew away a Windows session so you never saw
VMXGSUM the error message. Now, the error is printed and the
Sep 22, 2010 invocation is ended without the ABORT. This error can
Oct 7, 2010 only occur when testing a new VMXGSUM invocation; that
DATETIME argument is always required, except when the
INTERVAL=NONE argument is specified.
-VMXGDUR, Oct 7:
WARNING message for invalid interval= values updated
To include all possible valid values.
Change 28.218 Includes of ASUMDBAA/TRNDDBAA added in MXG 28.05 caused
BLDSMPDB errors and were replaced by includes of ASUMDB2A/TRNDDB2A
Sep 21, 2010 and ASUMDB2B/TRNDDB2B.
Oct 5, 2010 -Oct 5: If AUTOALOC EQ NO and FIRSTRUN EQ YES then all of
the directories needed are tested and created if the do
not already exist.
Thanks to Cletus McGee, ALFA Insurance, USA.
Thanks to Mary Kay Pettengill, MSI, USA.
Change 28.217 The CPUID section is now protected for a truncated ID=70
VMAC7072 subtype 1 record (created by B37 ABEND in SMF dumping).
Sep 21, 2010 Other sections were already protected.
Change 28.216 Invalid raw data for RH018 with zero values caused very
VMACTNG large positive or negative values. While the error is in
Sep 16, 2010 the NSM cube itself, a possible circumvention is to us
IF RH018001 GT 0 AND RH018002 GT 0 THEN DO;
OUTPUT _WTRH018; /* RH018 , DEFINED IN VMACTNG*/
END;
in the EXTRH018 exit member; this will cause the DELTATM
between intervals calculated by MXG to be twice DURATM,
so these intervals can be identified.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.215 NOTES: FIRST/LAST UNINITIALIZED with BAR=TIME had no
GRAFLPAR impact as they are not used with that option, but they
Sep 15, 2010 are no longer printed. Arguments DEVICE/DISPLAY were
removed, as your current site defaults will be used.
Thanks to Cletus McGee, ALFA Insurance, USA.
Change 28.214 ANALDB2R report selection didn't honor BEGTIME/ENDTIME.
ANALDB2R Starting with MXG 28.05, ANALDB2R passed those selection
Sep 14, 2010 criteria to READDB2 so that if PDB=SMF was used (so that
READDB2 was called) BEGTIME/ENDTIME were used for select.
Now, PDB=PDB or PDB=SMF honors BEGTIME/ENDTIME selection.
Thanks to Betty Wong, Bank of America, USA.
Change 28.213 This Change was replaced by 28.220.
Change 28.212 -New (very small) TYPE74ID dataset is now created when the
ANALRAID TYPE74 or TYPE74CA are output, so the mapping format that
ASUMCACH ASUMCACH requires can be automagically built in ASUMCACH,
EXTY74ID eliminating a full pass of TYPE74CA dataset.
VMAC74 -PDB.ASUMCACH now contains variables character DEVMODEL
VMXGINIT and its numeric version in variable MODEL.
VMXGSUM -ANALRAID now uses 8-character DEVMODEL, instead of MODEL
Sep 13, 2010 with 3-byte numeric in HEX6 formatted value, to support
Oct 29, 2010 newer, longer (3390A) control unit model names.
-If TYPE74ID is does not exist, ASUMCACH uses TYPE74CA, as
before, but DEVMODEL will contain 3390??.
-In testing this change, numerous Missing Value messages
were printed on the SAS log, all from VMXGSUM NORMn=
arguments that had valid missing values. VMXGSUM was
revised to test and suppress those cosmetic messages.
-In testing this VMXGSUM revision for the NORMn arguments:
-It was discovered that NORMn=A/B syntax, with only one
variable A that had only one character name, was never
being normalized. Fortunately, there was no instance
of this syntax in MXG code, but it is now corrected.
-Also, if B was missing or zero (with any length "A"),
so the division was never executed, the value output for
"A" output was SUM(A). Now, A is a missing value.
-Oct 29: %VMXGOPTR relocated to prevent warning message.
Change 28.211 Using COPYONLY argument wrote ALL SMF records; the
READDB2 selection criteria were not used for the COPYONLY writes.
Sep 11, 2010
Thanks to Larry Stahl, IBM Global Services, USA.
Change 28.210 DB2 V8.1-DB2 V9, MXG 28.02-28.05, DB2ACCT and DB2ACCTP,
VMACDB2 these variables added by APAR PK62161, MXG Change 28.051:
Sep 10, 2010 QXRWSFET QXRWSINS QXRWSUPD QXRWSDEL
were wrong because the prior field, QXSTXMLV, was
increased to 8 bytes but that increase was overlooked,
causing the subsequent fields to be misaligned/trashed.
Thanks to Betty Wong, Bank of America, USA.
Change 28.209 If INCLAFTR=BUILD005,BUILDPDB=NO is used to build only
UTILBLDP the PDB.JOBS/STEPS/PRINT/NJEPURGE/SPUNJOBS datasets,
Sep 9, 2010 the TYPE30xx,TYPE6,TYPE26J2 inputs for BUILD005 were
Jul 7, 2011 sorted into the PDB library, which caused BUILD005 to
fail, as it expected inputs to be in WORK library.
But since the purpose of INCLAFTR=BUILD005 should be to
create the above PDB datasets, this change removes the
sort of those input datasets into the PDB data library.
Jul 2011: If you really do want any or all of those raw
TYPE30xx, TYPE6, and/or TYPE26J2 to be kept in the PDB,
you can add these PROC SORTs to the EXPDBOUT= argument:
PROC SORT NODUP DATA= _WTY30U1 OUT= _LTY30U1 ;
BY _BTY30U1 ;
PROC SORT NODUP DATA= _WTY30U4 OUT= _LTY30U4 ;
BY _BTY30U4 ;
PROC SORT NODUP DATA= _WTY30U5 OUT= _LTY30U5 ;
BY _BTY30U5 ;
PROC SORT NODUP DATA=_WTY6 OUT=_LTY6 ;
BY _BTY6 ;
PROC SORT NODUP DATA= _WTY26J2 OUT= _LTY26J2 ;
BY _BTY26J2 ;
Or, if INCLAFTR=BUIL3005, for TYPE26J3, use:
PROC SORT NODUP DATA=_WTY25 OUT=_LTY25 ;
BY _BTY25 ;
PROC SORT NODUP DATA= _WTY26J3 OUT= _LTY26J3 ;
BY _BTY26J3 ;
Change 28.208 MXG incorrectly set R7451TIM to 16 microseconds when
VMAC74 it should have been 16 milliseconds; the variables
Sep 9, 2010 R7451CT3, R7451CT4, R7452PRT, R7452PWT are divided by
R7451TIM, and thus were wrong.
Thanks to Rick Southby, Insurance Australia Group, AUSTRALIA.
Change 28.207 Unused Change.
Change 28.206 Invalid APPTUNE SMF 102 IFCID 8133 record had invalid
VMAC102 offset of '7532'x for QBMCRQLO in APPTUNE Segment 9 for
Sep 7, 2010 Long Names, causing INPUT STATEMENT EXCEEDED ERROR.
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.205 Julian Date variables with FORMAT 6. were increased to 7.
VMACACF2 so the full seven digits can be seen (e.g. 2010099):
VMACEPIL -VMACEPIL - OMJULDAT
VMAC6367 -VMACACF2 - LIDCDATE LIDIPDAT LIDADATE LIDDXPDT
VMACHSM - LIDATIME is now a datetime variable when both
Sep 6, 2010 LIDADATE and LIDATIME are GT 0.
Sep 18, 2010 -VMACHSM - MCDJDATE
-VMAC6367 - DSCRDT DSEXTD
Change 28.204 Support for local installation optional USERSTR field in
IMACICUM CICSTRAN dataset from SMF 110 subtype 1 modified records.
IMACEXCL
VMAC110
Sep 3, 2010
Change 28.203 Variable LIDATIME was not formatted, but now contains
VMACACF2 the datetimestamp value (DATETIME21.2) of last access.
Sep 1, 2010 Date variables LIDCDATE LIDIPDAT LIDADATE LIDDXPDT all
contain Julian Dates YYYYDDD and are cannot be formatted
as a SAS Date variable.
Change 28.202 Support for RACF EVENT 82 (PTCREATE) creates TYPE8082
EXTY8082 dataset.
IMAC80A
VMAC80A
VMXGINIT
Sep 1, 2010
Thanks to Bill Arrowsmith, EuroClear, BELGIUM.
Change 28.201 MXG 28.05 only. GOPTIONS DEVICE=GIF was added in VMXGINIT
VMXGINIT but could change the size of your graphs. Now, GOPTIONS
Aug 31, 2010 only sets default COLORs and PATTERNs.
Change 28.200 z/OS utility to construct VBS blocks in RECFM=U format
UDEBLOCK from a PC/ASCII VBS file failed when only one byte was
Aug 31, 2010 left at the end of a block, since that would be the first
byte of the two-byte length field. MXG logic worked with
zero or two-or-more, but not one; an extensive rewrite of
the program was required. This uploaded file had a series
of 32760 byte blocks, but then one block of 32759 bytes
that contained parts of three blocks, with only one byte
of the next block at the end, which exposed the error.
Thanks to Carl Sommer, SAS Institute, USA.
Change 28.199 -Variables added from PDB.TYPE70PR are now populated ONLY
ASUM113 when the SM113CTM end time is within one hour of STARTIME
VMAC113 of the RMF data; previously, any 70 from the same SYSTEM
Sep 2, 2010 was used. APAR OA30486 will synchronize 113 intervals
with SMF, so eventually an exact merge can be used.
-LPARNAME is added to PDB.TYPE113, but will be populated
only if matching PDB.TYPE70PR observations exist.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.198 -CA-NSM/TNG datasets RH021 thru RH030 had only variables
VMACTNG from the header and RH020xxx, because of incorrect KEEP=
Aug 26, 2010 arguments.
Sep 1, 2010 -Variable INSTANCE was not kept nor in BY list for AI010.
-Packet counters in AI010 and RH018 are accumulated, so
the SORT macros _STAI010 and _STRH018 are rewritten to
deaccumulate those four variables. You will need to use
%INCLUDE SOURCLIB(TYPSTNG); to create PDB.AI010/RH018 to
contain the interval (deaccumulated) values, or use
%LET PTAI010=WORK;
%LET PTRH018=WORK;
%INC SOURCLIB(TYPESTNG);
_STAI010;
_STRH018;
if you want the interval datasets in the //WORK library.
Thanks to Xiabo Zhang, FISERV, USA.
Change 28.197 INVALID DATA FOR CHAR1 caused INPUT STATEMENT EXCEEDED.
VMACITRF The INPUT of VER with $CHAR1 was corrected to $CHAR1.
Aug 26, 2010 (i.e., missing period was added to the informat) in two
places. But Change 28.227 is also needed for VER='01'x.
Thanks to David J. Schumann, Blue Cross of Minnesota, USA.
Change 28.196 If you asked for IFCIDS=STATISTICS and WANTONLY a list of
READDB2 DB2STA* datasets, macro variable KILLSORT showed up as
Aug 25, 2010 unreferenced in DB2PST where it did not belong.
Thanks to Dan Case, Mayo Foundation, USA.
Change 28.195 If NRECORD was a null value or an alpha string, VMXGGETM
VMXGGETM failed with an invalid numeric value. Now, if an invalid
Aug 24, 2010 string is detected, NRECORD is set to the then current
value of the OBS option. This change uses the %DATATYP
macro provided by SAS, in their autocall library.
Change 28.194 Using ONLY the MXG-supplied CONFIGV9 and NOT having the
CONFIGV9 SAS-supplied DSNAME=SASHLQ..CNTL(BAT&YY) in //CONFIG DD
SASAUTOS caused the SAS default LOCALE=ENGLISH_UNITEDSTATES to be
TRIM used, instead of the LOCALE=ENGLISH_UNITEDKINGDOM that
Aug 2, 2010 was required for this English Site. The result was that
Sep 24, 2010 MXG saw an invalid 'BA'x character (for NOT symbol) in
Sep 30, 2010 the TRIM member of the SAS-supplied SASAUTOS PDS, that
had been built with the UNITEDKINGDOM LOCALE, instead of
the expected '5F'x with LOCALE=ENGLISH_UNITEDSTATES.
MXG's CONFIGV9 intentionally does NOT specify LOCALE, as
that should be picked up from the site's BAT&YY member.
The error was in the %TRIM macro (now used in VMXGSUM),
but it caused this completely-off-the-wall error:
NOTE: LINE GENERATED BY THE INVOKED MACRO "VMXGEXP".
&WORD = &WORD * &BY ;
_
22
(Long ago, problems with character conversion of the
NOT symbol caused me to NEVER use that symbol, and
instead MXG uses NE or NOT character text.)
-SAS did detect the incorrect LOCALE setting, printing
WARNING: There is an incompatibility between session
encoding and the SASHELP encoding. When such a
mismatch occurs, some features may not behave as
expected. For additional information, contact your Site
Administrator
-The original text of this change INCORRECTLY blamed the
error on the DSN=*.NULLPDS syntax in their //SASAUTOS DD
//SASAUTOS DD DSN=*.NULLPDS,DISP=SHR
// DD DSN=SAS.yadayada.SASAUTOS
which was INCORRECTLY thought to have prevented the %TRIM
macro from being resolved. While *.NULLPDS in MXGSASxx
JCL examples was removed in Change 27.108 in MXG 27.05,
because it was no longer needed and MIGHT cause errors,
in fact its removal, while recommended, is not required.
Thanks to George Canning, Produban UK, ENGLAND.
Thanks to Mark Dawson, SAS Institute, ENGLAND.
Change 28.193 -Full support for IMF records in SMF format, so IMF SMF
VMACCIMS records can be processed with BUILDPDB. Change 28.137
TYPEIMFS created TYPEIMFS to process IMF-SMF data, but was only
Aug 23, 2010 for "stand-alone" execution. This update to VMACCIMS
moved the "IMF-SMF-unique" logic inside the _CDECIMS code
and (transparently) recognizes the input file is SMF or
IMSLOG. Member TYPEIMFS was then updated/simplified.
-To add IMF processing to your BUILDPDB, you use the four
EXPDBxxx exit members, with this syntax:
EXPDBINC: %INCLUDE SOURCLIB(VMACCIMS);
EXPDBVAR: MACRO _VARUSER _VARCIMS ... %
EXPDBCDE: MACRO _CDEUSER _CDECIMS ... %
EXPDBOUT: _CHAIN
_SIMFDBD
_SIMFDB2
_SIMFPGM
and you must define the output DDNAME/DDNAMES for the
one or four data libraries where you want your output
datasets written, before the include of BUILDPDB?
- If you output to Disk, the same DDNAME can be used
for all four datasets, but,
- if you want to write your IMF data to tape, you must
have a separate DDNAME and DSNAME for each dataset
(because, internally, for performance run times, MXG
must open two of those datasets simultaneously, and
z/OS does not allow more than one dataset opened on
tape media).
%LET PIMFDBD=CIMSDBDS; /*DEFINE OUTPUT DDNAMES */
%LET PIMFDB2=CIMSDB2;
%LET PIMFPGM=CIMSPROG;
%LET PIMFTRN=CIMSTRAN;
Thanks to Denise Willers, Infocrossing, USA.
Thanks to Ken Steiner, Infocrossing, USA.
Change 28.191 Cosmetic cleanup when ITRM validated MXG 28.05:
ASUM113 -VMAC84 variables R84FN, R84DMA and R84GMSMIN are now
CREATEBC spelled R84FNFW, R84DMAV and R84_GMSMIN in the KEEP=. Two
PROCSRCE instances of '97'x (ASCII) or '00'x (EBCDIC) are removed.
VMAC7072 -Detection of ASCII '97'x (long dash) added in PROCSRCE.
VMAC84 -And, detection of '00'x in the EBCDIC output created by
Aug 23, 2010 CREATEBC converts it to blank (in case the PROCSRCE error
messages added above were overlooked!).
-Temporary datasets ZxTYxxx created by TYPE113/ASUM113 are
deleted. Temporary dataset BADINTRV is left intentionally
in case you need to see which intervals were dropped.
-Temporary TYPE70EC/TYPE70EL datasets are deleted; they
are used to create the new PDB.TYPE70EN.
-TYPE80A variable RACF329 is now spelled RACF320.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 28.190 MXG 28.05, QLACLOCN wrong if it is longer than 16 bytes.
VMACDB2 There is a fixed 16-byte field for QLACLOCN, but if that
Aug 20, 2010 remote location address is longer, it is "truncated", and
a non-zero offset to the full "un-truncated" field exists
but 28.05 incorrectly INPUT that longer field. This has
ONLY been seen with DB2 V9 with IPV6 IP addresses, which
are usually 17-20 bytes long, but can be up to 39 bytes.
2012: Not noted in 2010, QLACLOCN/QWHDSVNM were increased
to $128.
Change 28.189 The COMPALL program requires REGION=1700MB to compile all
COMPALL MXG members that process SMF records (to verify that they
VMACCMHM can all be combined without conflicts for any temporary
Aug 20, 2010 variables). The program contained 407,097 source lines.
It also exposed an error in VMACCMHM that did not have an
IF ID=_IDCMHM THEN DO; code block.
Change 28.188 RMM INVALID NUMERIC DATA NE notes are produced when the
VMACEDGR expiration date is "PERMANENT". The DATE fields will be
Aug 19, 2010 missing values, like other non-date-expiration-dates, but
the variables RDEXPDCH,RVEXPDTO, the "ORIGINAL*CHARACTER"
expiration dates will contain PERMANENT, with no NOTES.
Thanks to Sam Bass, McLane Co., USA.
====== Changes thru 28.187 were in MXG 28.05 dated Aug 18, 2010=========
Change 28.187 -First 28.05, JCLTESTx jobs only, VARIABLES NOT FOUND in
ASUM113 ASUM113 which is included automatically by TYPE113.
Aug 18, 2010 The ASUM113 member adds data from TYPE70PR when it is
found, but incorrect logic in the new ASUM113 failed when
there was no TYPE70PR dataset found. ASUM113 was revised.
SMF records. The error was missed because JCLQASAS is the
primary z/OS QA job now, and it (accidentally) always had
a PDB.TYPE70PR created when the ASUM113 was executed.
I'll now ensure JCLTESTx is also tested for z/OS QA.
-NEWSLETTER FIFTY-SIX is now dated August 18, 2010, as it
should have been.
====== Changes thru 28.186 were in MXG 28.05 dated Aug 17, 2010=========
Change 28.186 Support for ThruPut Manager V6.2(PTF 6209) adds these
VMACTPMX variables to dataset TYPETPMX:
Aug 17, 2010 DBS_SDBL DBS_SDPA DBS_SDPL PCS_EP PCS_MP PCS_PPSQ
Other new fields could be created, but I can only
update MXG for the data fields that exist in sample
SMF records.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to Rick Ralston, Humana, USA.
Change 28.185 Cosmetic. TYPETMNT records with unexpected MSGID printed
VMACTMNT log messages for every instance; now, only the first 10
Aug 17, 2010 instances will be printed.
Thanks to Linda S. Berkley, DISA, USA.
Change 28.184 The syntax LIBNAME TYPE30 'D:\MXG\ANALDSET\TYPE30 \'; is
ANALDSET not valid on PC SAS; the blanks before the back-slash
Aug 17, 2010 must be removed.
Thanks to Sarel Swanepoel, South African Revenue, South Africa
Change 28.183 Documentation and cosmetic changes to DB2 102 data.
VMAC102 -QWP1IXPX contains the name of the default Buffer Pool; it
Aug 16, 2010 is $EBCDIC6 and replaced QWP1IXPL which was only $EBCDIC4
Aug 24, 2010 -QWP9MISC is now formatted $HEX2.
-QWP1SCER, QWP4STHT, QWP4STRL, QWPBDB2S are now $EBCDIC1.
instead of $CHAR1. and no longer formatted $HEX2., and
their labels now contain ? to indicate they are Y/Ns.
-QWP1BDUR/QWP1URCK/QWPBDLEN/QWPBTLEN/QWP1FLBX are CHAR
variables with $HEX format, but they contain numbers.
Rather than create a conflict of CHAR vs NUM variables,
they are expanded to 3 bytes and the numeric value is now
carried in the character variable.
-QWP4ESC now formatted $HEX2. instead of $HEX4.
-QWP4RMAX is the maximum number of RID blocks, for example
147. TMON reported QWP4RMAX=4,816,896, which (I think)
is the number of bytes, because 147*32768=4,816,896.
-IFCID=106 fields that are now input:
QWP4MIS5 QWP4MS4B QWP4MS4D QWP4MS4E QWP4METR QWP4CHEC
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 28.182 MXG 28.05 is REQUIRED for APAR OA30563 and APAR OA33976,
VMAC30 which increased Service Unit fields in SMF 30 records to
Aug 16, 2010 8-bytes, but MXG 27.10 thru MXG 28.04 were in error and
Sep 9, 2010 caused VERY LARGE SERVUNIT values and in these variables
SERVUNIT CPUUNITS SRBUNITS IOUNITS MSOUNITS ENCLCPSU
IFEUNITS IFAUNITS ZIPUNITS ZIEUNITS
and the CPU times that are calculated from Service Units
CPUTOTTM/SRVTCBTM/SRVSRBTM
to all be extremely wrong when those APARs are installed.
The variables are in TYPE30_4/TYPE30_5/TYPE30_V/TYPE30_6
and PDB.JOBS/PDB.STEPS/PDB.SMFINTRV datasets.
MXG 28.05 is required to support OA30563 and OA33976.
FORTUNATELY: the SRVTCBTM/SRVSRBTM/CPUTOTTM time that are
calculated from Service Units were created in MXG only
for comparison with the real CPUTM/CPUTCBTM/CPUSRBTM time
and are not used in any MXG reporting
-because long ago it was claimed that using service units
to calculate CPU times (TCB and SRB and TOTAL) was more
accurate than the CPUTCBTM/CPUSRBTM/CPUTM variables that
are in the SMF 30 record, a claim I have never been able
to verify, as I have only seen VERY small differences
between CPUTM and CPUTOTTM.
Only these three calculated CPU times are wrong:
CPUTOTTM/SRVTCBTM/SRVSRBTM
ALL other CPU time variables are correct and are NOT
impacted by this error in service units in TYPE30.
Originally, APAR OA26832 added 8-byte service unit fields
to the PERF segment, increasing LENPERF to 192, but MXG
Change 27.122 was wrong, testing for LENPERF GE 196, so
that new code block was never being executed, and the
new, longer service unit fields were never being input.
But when OA30563/OA33976 added more fields that increased
LENPERF to 211, so the code block was now executed, that
exposed a second error in Change 27.122, where a +3 was
coded instead of +6 to skip reserved field SMF30RS6,
causing all variables after that +3 to be misaligned,
with VERY large values in those service unit fields,
which are used to calculate the service-unit-based CPU
time variables CPUTOTTM, SRVTCBTM, and SRVSRBTM.
The original change text cited RSU1006 as the cause, but
that is not true; the two APARs happened to be installed
along with RSU1006, causing the incorrect citation.
Thanks to Jerry Urbaniak, Acxiom, USA.
Thanks to Cheryl Watson, Watson and Walker, USA.
Change 28.181 Updates made as a result of MXG 28.05 QA jobstream:
ANALCAPD -CLEARDB2 updated for new datasets created from DB2 SMF.
ANALRAID -READDB2 suppresses sorts when PDBOUT=WORK, suppressed
ASUMCACH sort of DB2GBPST, and some of the variables needed by the
ASUMDBAA ANALDB2R program are created in the _S macros.
CLEARDB2 -ASUMCACH did not support DEVMODEL='3390A'; to avoid full
EXZCO02 sort of both TYPE74 and TYPE74CA, variable MODEL was
READDB2 created as a numeric, MAXed to carry thru in lieu of ID.
TRNDDBAA But '3390A' caused INVALID ARGUMENT as it's not numeric.
VMAC42 Conflict resolved internally by making MODEL a HEX value
VMAC7072 and that will work until '3390G' DEVMODEL shows up.
VMAC74 -ANALRAID had site-specific ODS token
VMACDB2 -Cosmetic updates to ANALCAPD/ASUMDBAA/TRNDDBAA/VMXGDBAA
VMXGSRCH VMXGSRCH/VMAC42/EXZCO02 and updates to VMAC7072/VMAC74.
Aug 15, 2010
Change 28.180 -Support for user-created MQNAME segment that creates the
IMACICUL optional MQNAMECI variable in CICSTRAN dataset.
UTILEXCL
VMAC110
Aug 13, 2010
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 28.179 Utility to read PDS/PDSE directories of a concatenation,
UTILPDSL assigning the level from 1 to X (x being the number of
Aug 11, 2010 libraries in the concatenation) to each member of each
library, so a pair (for example, two JES2 PROCLIBs or
two STEPLIBs, etc.) can be compared for member matches.
Place your concatenation in the JCL (in the example it
is a PROCLIB concatenation copied from SYS1.PROCLIB
member JES2) and point the PDS= parameter at that DD.
If you want the second report to contain ONLY those
cases where a member first appears in a specific PDS,
count down from the top of the concatenation to that
PDS and use that as the LEVEL= parameter. If that
LEVEL= is empty, all members will be listed in the
second of the two reports. This could be used to
determine if a PROCLIB (for example) has members that
are being used. If you specify LEVEL= and the second
report is not there, then no members in that PDS are
being referenced in this particular concatenation.
Reports:
1) The datasets in the concatenation
2) The PDS members, the dataset, and the level in
concatenation from whence they came.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.178 Comments had the correct output FILENAME UOUT but the
UDEBLOCK actual code had the FILENAME misspelled as UOW. ALL of
Aug 9, 2010 the references are now corrected to UOUT.
Thanks to Carl Sommer, SAS Institute, USA.
Change 28.177 -Modified to carry the SORTEDBY values into the output
BLDSMPDB datasets. In addition, now uses the datasets in the
VMXGALOC MON LIBNAME to determine which datasets will be kept
Aug 9, 2010 and the sort orders, and uses the WEEK1 LIBNAME for
ASUMDBSS monthly processing.
ASUMDBAA -If you need to build old data, you can use BLDSMPDB
Sep 9, 2010 but you need to specify RUNDAY=PDB,RERUN=ddmmmyy
where ddmmmyy is the SAS date value you want to have
in ZDATE. ZTIME will be set to midnight of that day.
-ASUMDB2A and ASUMDB2B members have ASUMDBAA and
ASUMDBSS alternates.
-VMXGALOC did not allocate CICSTRAN and DB2ACCT libs
as the doc said they did. Now it does. They are
allocated as:
CICSTRAN is allocated as basedir\cicsddmmmyy
DB2ACCT as basedir\db2ddmmmyy
both are retained based on the number of days specified
by DB2KEEP and CICSKEEP, with defaults of 14.
Change 28.176 Support for SARMON, a free tool that converts SOLARIS SAR
EXNMONIS data into the NMON format. The home page of the tool is:
VMACNMON http://www.geckotechnology.com/sarmon
VMXGINIT Some changes were required to MXG to support SARMON data:
Aug 8, 2010 -TOP record with 'NaN' (a UNIX unique "NOT A NUMBER")
which required protection with double question marks.
-Array size of WORDS increased from 255 to 1024 because
the SARMON 'IOSTATxxxx' records all contained 340 words.
-NMON or SARMON data could be incorrectly processed if
"descriptor records" were longer than 2048 bytes; the
NMONTEXT INPUT was increased to $VARYING32000.
-DISNAME was increased from $20 to $64 because SARMON
DATA had longer "disk" names for the IOSTAT data.
-SARMON RECTYPE=DISKSVCTM and DISKWAITTM are the same as
NMON DISKSERV and DISKWAIT, with different WORD2 names.
-Other SARMON DISKxxxx RECTYPEs have same spelling for
both RECTYPE and WORD2 so they were automatically output
and combined to create PDB.NMONDISK dataset.
-Seven IOSTAT (BUSY/READ/WRITE/XFER/BSIZ/SERV/WAIT) data
are supported and create new PDB.NMONIOST dataset with
I/O statistics for the non-disk I/O.
-SARMON objects WLMPROJECTCPU,WLMPROJECTMEM,WLMZONECPU,
WLMZONEMEM, and PROCSOL are supported and those variables
are output in the PDB.NMONINTV dataset.
Thanks to Marc-Antoine Gouillart, AMF, FRANCE.
Change 28.175 -Support of z196 WITH MORE THAN 64 ENGINES REQUIRES 28.05.
EXT11904 (Earlier MXGs will NOT contain any CPU data for engines
EXT11932 64-95 in TYPE70 and RMFINTRV datasets.
EXT11933 -A z196 with LESS THAN 64 engines with z/OS 1.11-1.09 does
EXT11934 NOT require MXG 28.05.
EXT11935 -Support of z/OS 1.12 enhancements requires MXG 28.05.
EXT11935 -DO NOT USE MXG 28.04 to read z/OS 1.12 RMF data, due to
EXT11936 errors (including ARRAY SUBSCRIPT OUT OF RANGE in ID=70),
EXT11937 and other errors in VMAC74 processing with MXG 28.04.
EXT11948 -MXG 28.03 and earlier MXG Versions that support 1.11 data
EXT11949 TOLERATE z/OS 1.12 records, but with no new data fields.
EXT11950
EXT11951 -The TYPE70 architecture is revised for z196s with 64 plus
EXT11952 engines. Sixty-four sets of variables for CPUs 0-63 are
EXT11973 still in TYPE70, but no new variables for CPUs 64+ were
EXT11974 created in this change. Instead, the new PDB. YPE70EN
EXT11975 "CPU Engine" dataset is created with one set of names and
EXT11976 with one observation for EACH engine, with no limit to
EXT11977 the number of engines, ever, should you actually need to
EXT11978 know the metrics for a specific MVS TYPE70 CPUID.
EXT11979 -The PDB.TYPE70PR dataset will also contain an observation
EXT11980 for every LCPUADDR.
EXTY4226
EXTY9033 All of the z/OS 1.12 changes are COMPATIBLY made.
EXTY9034
FORMATS -TYPE7 New variables:
VMAC113 SMF7DTYP SMF7LSD SMF7DRP SMF7LSN
VMAC30 -TYPE30 New variables:
VMAC42 The CPITCBTM and CPISRBTM "Initiator" CPI CPU times
VMAC64 are split into their "INIT" versus "TERM" events in
VMAC7 four new CPI variables in TYPE30_4/STEPS data:
VMAC7072 CPISRITM='CPI*SRB*STEP*INIT'
VMAC74 CPISRTTM='CPI*SRB*STEP*TERM' (Sum is CPISRBTM)
VMAC89 CPITCITM='CPI*TCB*STEP*INIT'
VMAC90A CPITCTTM='CPI*TCB*STEP*TERM' (Sum is CPITCBTM)
VMACDCOL SMF30CAI='CAPACITY*ADJUSTMENT*IND'
VMXGINIT SMF30CCR='CAPACITY*CHANGE*REASON'
Aug 8, 2010 SMF30CHC='CAPACITY*CHANGE*CNT'
Aug 15, 2010 SMF30ACR='RCTPCPUA*ACTUAL'
SMF30NCR='RCTPCPUA*NOMINAL'
SMF30SCF='RCTPCPUA*SCALING*FACTOR'
SMF30PCF='CAPACITY*FLAGS'
Note that these CPI times are NOT captured in RMF 72s,
and previously the INIT/TERM CPU times were lumped into
one bucked. Now, you can assign the "INIT" CPU time
to the INITTIME interval and the "TERM" CPU time to the
TERMTIME interval and improve the capture ratio.
-TYPE42 New Dataset: TYPE4226 NFS CREATE/DELETE/RENAME
The documentation of the subtype 7 and 8 and the new 26
are in the Network File System Guide and Reference.
-TYPE42 New variables:
Dataset: TYPE42VS:
SMF42VNL='VOLUME NAME LIST'
Dataset: TYPE42NF and TYPE42NU:
SMF42CI6='IPV6*ADDRESS*OF CLIENT HOST'
-TYPE64 New variables:
SMF64FD1 SMF64FD2 SMF64DAU
-TYPE70 New variables:
SMF70CR SMF70ZEI
SMF70NCR SMF70NPR SMF70NTR SMF70CAI SMF70CCR
SMF70SRM SMF70CMN SMF70CMM SMF70CTT SMF70DMN SMF70DMM
SMF70DTT SMF70EMN SMF70EMM SMF70ETT SMF70U00-SMF70U15
-TYPE70PR New variables:
SMF70TCB SMF70SRB SMF70NIO SMF70SIG SMF70WTD
APAR OA29820 also added SMF70WTD "LPAR Overhead"
-TYPE70X2 New variables:
R7024MSK R7023MET R7023MEC
-TYPE72GO New variables:
R723NADJ R723CECA
-TYPE74CA New variables:
R7451CT5 R7451CT6
-TYPE747P New variables:
R747PAND
-TYPE748 New variables:
R748LFLF R748LFLY R748LFLS R748LFPQ R748LFIT R748LFCR
R748LFR1 R748LFR2 R748LFIF R748LFOD R748LFOA R748LFDF
R748LFIO R748LFTC R748LFBC
-TYPE748A New variables:
R748AAS0 R748AAS2 R748AAS3 R748AAS4
-TYPE748R New variables:
R748RTQ
-TYPE748X New variables:
R748XPTQ
-TYPE89 New variables:
SMF89CHC SMF89ACR SMF89NCR SMF89SCF SMF89CAI
SMF89CCR SMF89PCF
-TYPE9033 New dataset with variables
SMF9033T SMF9033N SMF9033S
-TYPE9034 New dataset with variables
SMF9034T SMF9034F SMF9034A SMF9034N SMF9034S SMF9034I
SMF9034R SMF9034F
-TYPE113 New variables, but see also Change 28.166.
SM113CPT
-TYPE119 New Datasets:
T11904 TYP11904 TCP PROFILE INFORMATION FOR STACK
T11932 TYP11932 DVIPA STATUS CHANGE
T11933 TYP11933 DVIPA REMOVED
T11934 TYP11934 DVIPA TARGET ADDED
T11935 TYP11935 DVIPA TARGET REMOVED
T11936 TYP11936 DVIPA TARGET SERVER STARTED
T11937 TYP11937 DVIPA TARGET SERVER ENDED
T11948 TYP11948 CSSMTP CONFIGURATION DATA
T11949 TYP11949 CSSMTP TARGET SERVER CONNECTION
T11950 TYP11950 CSSMTP MAIL
T11951 TYP11951 CSSMTP SPOOL
T11952 TYP11952 CSSMTP STATISTICS
T11973 TYP11973 IPSEC IKE TUNNEL ACTIVATE
T11974 TYP11974 IPSEC IKE TUNNEL DEACTIVATE
T11975 TYP11975 IPSEC DYNAMIC TUNNEL ACTIVATE
T11976 TYP11976 IPSEC DYNAMIC TUNNEL DEACTIVATE
T11977 TYP11977 IPSEC DYNAMIC TUNNEL ADDED
T11978 TYP11978 IPSEC DYNAMIC TUNNEL REMOVED
T11979 TYP11979 IPSEC MANUAL TUNNEL ACTIVATE
T11980 TYP11980 IPSEC MANUAL TUNNEL DEACTIVATE
-TYP11904 dataset is NOT decoded, it has 21 sections
and I hope NO ONE EVERY wants it decoded, but if you
REALLY do, then please send an example SMF record.
-TYP11948-TYP11952 CSSMTP common segments are decoded
but not all subtype-specific segments are, since I
have no data records.
-TYP11948-TYP11952 IPSEC common segments are decoded
but not all subtype-specific segments are, since I
have no data records.
-Many of the new 119 datasets contain IPV6 IP addresses,
which are a $CHAR16. field with hexadecimal values that
are expanded to a 39-byte text field with colons.
This 16-byte hex value in the SMF record
'0123456789ABCDEF0123456789abcdef'X
'7CC3C1E2000000050000000000003000'X
is printed in ftp connection messages as
0123 4567 89ABCDEF cdef
7CC3:c1e2:00000005::3000
is expanded to this 39-character text field in MXG:
0123:4567:89AB:CDEF:0123:4567:89AB:CDEF
This code creates the 39-byte recognizable text value:
INPUT CHAR16IP $CHAR16. @;
IPADR6=PUT(INPUT(SUBSTR(CHAR16IP,1,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,3,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,5,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,7,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,9,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,11,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,13,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,15,2),$CHAR2.),$HEX4.);
-TYPE119 New Variables:
TYP11902: TTTTLSFP
TYP11903: FCCCONID FCDCONID
-DCOLLECT: Added to DCOLDSET:
DCDDS9F1 DCDJBNMC DSCSTNMC DCDTIMEC
-DCOLLECT: Added to DCOLDC:
DDCFCT DDCBLMT DDCCFS DDCDVCS DDCFSCAL
DDCFRLOG DDCFRLGS DDCFEXTC DDCFA2GB DDCFPSEG
DDCFKYL1 DDCFKYC1 DDCFKYL2 DDCFKYC2 DDCFVSP DDCFSDB
DDCFVORD DDCFCAR
DDCCT DDCDSCF DDCRBYTE DDCBLKLM DDCBSZLM DDCTAPE1
DDCPSCA DDCPSEG DDCVSP DDCVSPV DDCKLBL1 DDCKLBN1
DDCKYCD1 DDCKLBL2 DDCKLBN2 DDCKYCD2
-Internally, in VMAC7072, thirty-two sets of variables ARE
created for engines 64-95 and used to create the TYPE70
measurements, with these variable name suffixes:
Variables CPUID SUFFIX CPUID SUFFIX CPUID SUFFIX
(All other) 00-09 D0-D9 10-21 DA-DL 22-34 DN-DZ
35-60 ZA-ZZ 61-86 YA-YZ 87-95 VA-VI
Variables
PCTxxxBss 00-09 Y0-Y9 10-21 YA-YL 22-34 YN-YZ
where xxx= CPB CIB IFB ZIB (all other PCT are above).
And four new formats are created that map these pairs of
suffix and CPU numbers (but probably will never be used):
$MG070SC maps suffix to "all other" variable CPU Number
$MG070CS maps CPU number to "all other" suffix
$MG070SP maps suffix to "four PCT" variable CPU Number
$MG070PS maps CPU Number to "four PCT variable suffix
Change 28.174 The variable ZDATE in all MXG datasets is "ZEE DATE WHEN
IMACZDAT ZEE OBS WAS CREATED" and it is used as both an audit date
Aug 6, 2010 and for selection of which observations are kept in MONTH
PDB's in MONTHBLD and BLDSMPDB. If you have to rebuild
a PDB library, you must change the ZDATE to have the
correct date, or data can be lost when in the MONTH PDB.
Previously, you had to EDIT the IMACZDAT member, but you
can instead use this DATA step to set the ZDATE value:
DATA _NULL_;
DATE='01JUL2010'D;
TIME=PUT(DHMS(DATE,0,0,0),32.);
DATEC=PUT(DATE,16.);
CALL SYMPUT('ZDATE',DATEC);
CALL SYMPUT('ZTIME',TIME);
RUN;
%LET MXGZDATE=%QUOTE(
ZDATE=&ZDATE;
ZTIME=&ZTIME'
);
%INCLUDE SOURCLIB(BUILDPDB);
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.173 Variable ZIPTM was used in GRAFWRKX to carry the zIIP
GRAFWRKX time, but it already existed in RMFINTRV as the total of
Aug 5, 2010 the TYPE72GO zIIP time, it was included as uncaptured
zIIP time on the bar charts. Now the uncaptured zIIP and
IFA/zAAP times are correctly calculated for the charts.
Change 28.172 CA-Dispatch Version 11 type SMF 6 INCOMPATIBLY CHANGED by
IMACCADI the insertion of fields, causing INVALID JESNR messages.
VMAC6 There is no "version" field in CA's record, so a test for
Aug 5, 2010 LENGTH=347 AND SMF6LN1=287 is used to identify V11 data.
These new variables are created:
CADIATYP CADIDJDC CADIDPLX CADIEFRM CADIJDEI
CADIJDLI CADIOLVR CADIPASS CADIPCR CADIPRTR CADIXFRM
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.171 IFLs only, MXG 28.01+, STARTIME was a missing value in
VMXG70PR the PDB.ASUM70LP dataset.
Aug 3, 2010
Thanks to William Edwards, Blue Cross Blue Shield of Florida, USA.
Thanks to Bob Maple, Blue Cross Blue Shield of Florida, USA.
Change 28.170 Cosmetic. LOG=NO and NOEXIMSG=NO added to VGETOBS to
VMXGFIND suppress unneeded/unwanted log messages, and MXGNOTE
Jul 29, 2010 added at the end to report how many datasets were found
with matching values.
Change 28.169 -New ANALCAPD analysis will estimate the impact of setting
ANALCAPD a Defined Capacity limit, at the CEC level, with both a
Jul 29, 2010 text report and a graph (if SAS/GRAPH is found) or plot
Aug 14, 2010 (if no SAS/GRAPH) of the intervals which might be limited
by a cap, i.e., intervals where the rolling four hour
average exceeded the Cap value that you specified.
Arguments:
PDB=PDB Libname where the ASUMCEC dataset is found
DEFCAP=130 MSU Value of the CAP you want to examine
INTERVAL=HOUR Must match the ASUMCEC interval
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.168 -New MULTIPDB utility will creates a new SAS DATA library
MULTIPDB with ALL of the datasets that exist in the list of input
VGETSORT data libraries to be read. If a dataset is sorted in all
VGETLIBS of the input data libraries, the output dataset will also
Jul 27, 2010 be sorted. Options for KEEPing or DROPing datasets by
Aug 9, 2010 name is supported, and the input list can use a colon as
a wildcard to read all DDs starting with that string.
// EXEC MXGSAS
//PDB1 DD DSN=PDB(0),DISP=SHR
//PDB2 DD DSN=PDB(-1),DISP=SHR
//PDB3 DD DSN=PDB(-2),DISP=SHR
//PDB4 DD DSN=PDB(-3),DISP=SHR
//MON DD DSN=PDB.MON,DISP=SHR
//TUE DD DSN=PDB.TUE,DISP=SHR
//NEW DD DSN=PDB.COMBINED,DISP=(,CATLG)......
%MULTIPDB(INLIBS=PDB: MON TUE,OUTLIB=NEW);
will create all datasets found in all of the INLIBS= into
the //NEW data library.
-VGETSORT added parameters for efficiency and to reduce
the number of messages written to the SAS log.
-New VGETLIBS %MACRO will take a list of LIBNAMEs and see
if they exist and what engine they were created by.
The list of libnames and engines are returned, and used
by MULTIPDB to determine if the INLIBS= libnames exist.
If none of the LIBNAMES in INLIBS= are found, MULTIPDB
terminates.
Change 28.167 Variables NDMCERT and NDMCERI are added to NDMCT dataset.
VMACNDM
Jul 27, 2010
Change 28.166 Revised, enhanced support for TYPE113 SMF records, based
ASUM113 on John Burg's SHARE Boston 2010 Presentation.
FORMATS -PDB.TYPE113 dataset contains the complete detail level,
VMAC113 with an observation for each CPU Address, while the new
TYPS113 PDB.ASUM113 dataset, created by revised ASUM113, has all
TYPS113E of the counters summed for each LPAR for each interval;
Jul 27, 2010 This PDB.ASUM113-level is used to calculate the RNI for
Aug 12, 2010 each LPAR for zPCR; while all the new variables are also
created in TYPE113 dataset, IBM recommends that the LPAR
summary PDB.ASUM113 data be normally used.
-The ASUM113 program will look for PDB.TYPE70PR dataset in
the same PDB library as TYPE113, and if found, it is used
to add variables CPUTYPE CECSER LPARWLMG and SMF70HDM in
both PDB.TYPE113 and PDB.ASUM113.
-The TYPS113E "Enhanced" standalone program reads 70 & 113
SMF to create both PDB.TYPE113 and PDB.ASUM113 with the
TYPE70PR variables added.
- New RNI metric is created in TYPE 113, additional metrics
are calculated, and SM113VN2 is formatted to identify if
the processor type is z10 or a new z196.
-SM113VN2=1 for z10, SM113VN2=2 for z196; new MG113VN
format will print z10 or z196.
-Relative Nest Intensity calculations for the z10 and z196
are added to dataset TYPE113 using these two algorithms,
but only the new variable RNI is actually created:
Z10RNI =(1.0*L2LP+2.4*L2RP+7.5*MEMP)/100.
Z196RNI=1.6*(0.4*L3P+1.0*L4LP+2.4*L4RP+7.5*MEMP)/100
-Users will need to know the RNI to determine the correct
LSPR workload for the latest LSPRs, which is documented
in the new LSPR Manual on ResourceLink:
https://www-304.ibm.com/servers/resourcelink/lib03060.nsf
/pages/lsprindexpdf/$file/SC28118714_20100714.pdf
-New variables are created in TYPE113:
z196 only:
L2P ='PERCENT*SOURCED*FROM*L2*CACHE'
L3P ='PERCENT*SOURCED*FROM*L3*CACHE'
L4LP='PERCENT*SOURCED*FROM*L4*SAME BOOK'
L4RP='PERCENT*SOURCED*FROM*L4*DIFFERENT*BOOK'
z10 and z196, but different equations for each CEC:
ESTICCPI='ESTIMATED*INSTRUCTION*COMPLEXITY*CPI'
ESTFINCP='ESTIMATED*CPI FROM*FINITE*CACHE/MEM'
ESTSCP1M='ESTIMATED*SOURCING*CYCLES*PER L1 MISS'
RNI ='RELATIVE*NEST*INTENSITY'
EFFGHZ ='EFFECTIVE*GIGAHERTZ*CYCLES*PER NANO'
TLB1MISS='TLB*CPU MISS*PERCENT OF*TOTAL CPU'
TLB1CYCL='CYCLES*PER*TLB*MISS'
PTEPCTMI='PAGETABLE*ENTRY*PCT OF TLB*MISSES'
-These z10-only variables have missing values (i.e., not
calculated for z196): L15P L2LP L2RP. (Added 26Aug2011).
-SM113CPT was not kept in the TYPE113 dataset.
-If a counter reset is found in one counter, that entire
interval from that SYSTEM/LPAR is deleted.
-The original logic attempted to correct when counters
wrapped, by creating the value of a full 8-bytes 'FF'x,
to add when wrap was detected:
IF EIGHTFFF=. THEN DO;
CHAR8FFF='FFFFFFFFFFFFFFFF'X;
EIGHTFFF=INPUT(CHAR8FFF,&PIB.8.);
RETAIN EIGHTFFF;
DROP CHAR8FFF;
END;
and that worked fine on PC SAS. But on z/OS, the value of
EIGHTFFF is ZERO, instead of the expected 1.8E+19 value.
SAS Support has recognized this as a defect (that has
been that way since SAS V6 on z/OS), so this iteration
will just delete intervals if the counter wrapped.
-John's SHARE paper had some missing counters for the z196
equations that are included in this MXG update and will
be in his final version of that paper:
L4LP adds EXTND152 and EXTND155
L4RP adds EXTND134 and EXTND143
MEMP subtracts EXTND134 and EXTND143
-The ANAL113 program print's the report on page 26 of his
paper, and also prints the counters that are used to
create that report for each LPAR for each interval, using
the PDB.ASUM113 dataset as input.
-I will update MXG ANALZPCR to use RNI in a later change.
-APAR OA30486 became available in Oct, 2010, back to z/OS
1.10, adding SMFINTVAL=SYNC so that SMF 113 records can
be synchronized with your SMF and RMF interval data.
Thanks to Cheryl Watson, Watson & Walker, USA.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to John Burg, IBM, USA.
Thanks to Tony Hirst, Wells Fargo, USA.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 28.165 IMS Statistics Log Record LCODE=56x TPCPSSTY='09'X record
VMACIMS caused INPUT STATEMENT EXCEEDED RECORD LENGTH. The DO
Jul 26, 2010 group for the '09'x subtype was incorrectly located.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Change 28.164 Support for SMF 119 new subtypes 32-37 and 48-52.
EXT11932 Nineteen new datasets are created (but not yet data'd).
EXT11933
EXT11934 dddddd Dataset Description
EXT11935 T11932 TYP11932 DVIPA STATUS CHANGE
EXT11936 T11933 TYP11933 DVIPA REMOVED
EXT11937 T11934 TYP11934 DVIPA TARGET ADDED
EXT11948 T11935 TYP11935 DVIPA TARGET REMOVED
EXT11949 T11936 TYP11936 DVIPA TARGET SERVER STARTED
EXT11950 T11937 TYP11937 DVIPA TARGET SERVER ENDED
EXT11951 T11948 TYP11948 CSSMTP CONFIGURATION DATA
EXT11952 T11949 TYP11949 CSSMTP TARGET SERVER CONNECTION
EXT11973 T11950 TYP11950 CSSMTP MAIL
EXT11974 T11951 TYP11951 CSSMTP SPOOL
EXT11975 T11952 TYP11952 CSSMTP STATISTICS
EXT11976 T11973 TYP11973 IPSEC IKE TUNNEL ACTIVATE
EXT11977 T11974 TYP11974 IPSEC IKE TUNNEL DEACTIVATE
EXT11978 T11975 TYP11975 IPSEC DYNAMIC TUNNEL ACTIVATE
EXT11979 T11976 TYP11976 IPSEC DYNAMIC TUNNEL DEACTIVATE
EXT11980 T11977 TYP11977 IPSEC DYNAMIC TUNNEL ADDED
VMAC119 T11978 TYP11978 IPSEC DYNAMIC TUNNEL REMOVED
VMXGINIT T11979 TYP11979 IPSEC MANUAL TUNNEL ACTIVATE
Jul 25, 2010 T11980 TYP11980 IPSEC MANUAL TUNNEL DEACTIVATE
Change 28.163 The code for TMON/DB2 has been updated to "standard" MXG
VMACTMDB structure; the original code did not define the _Vdddddd
Jul 23, 2010 macros, and the _Sdddddd dataset sort macros were DATA
steps rather than PROC SORTS.
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 28.162 Support for ITRF adds variables to ITRFDATA and ITRFSUM
VMACITRF datasets to support ITRF V420 IF2.
Jul 22, 2010
Change 28.161 Example 3 was missing the second close-paren in both of
TIMEBILD the %TIMEBILD invocations. The execution just hung with
Jul 21, 2010 no error message nor clue, except for an astute user.
Thanks to Graham Cornwall, Donovan Data Systems, ENGLAND.
Change 28.160 -CleverView for TCP/IP TN3270 variable CTCPIPAD was wrong,
VMACCTCP with constant value of 64.64.64.64, now corrected.
Jul 21, 2010 -The CVTTZ GMT Offset field was added to the SMF record,
and when it exists is used to correct the CTCPTIME STCK
value to the local clock. CTCPTIME is the Start Time of
the session and will be constant for all intervals for
that session.
-The interval records cannot be SYNC'd with SMF intervals.
-The CTCPHOST (HOST APPLICATION NAME) can be blank, when
the user has not yet logged on.
Thanks to John Howard, Florida Northwood Shared Center, USA.
Change 28.159 This example to use BLDSMPDB to write daily PDBs to a GDG
GDGDAILY did not pick up yesterday's SPIN data library.
Jul 20, 2010
Change 28.158 Support for APAR OA31648 adds new counters to show how
VMAC42 many retries were performed to obtain buffer latches to
Jul 19, 2010 satisfy record management requests. From APAR text:
-If a client has a serious application contention issue
while accessing buffers to read data, there is no
external indication or measurement data to show this
reason for delay.
-While primary serialization in RLS is at the record
level, there is still a need for SMSVSAM to perform
very short term serialization of the local buffer
containing the CI in order to maintain integrity of the
local buffer pool.
-When contention is excessive, a single record
management request may need to retry an obtain for the
buffer latch many times. A small amount of contention
is normal, so displaying latches at a given point in
time does not give an indicator of how long a request
may have been delayed.
Variables SMF42GRW and SMFA2GRW are added to datasets
TYPE42D1 and TYPE42D3 respectively.
Change 28.157 Support for VM ACCOUNT ID='09' for ISFC (Inter-System
EXVMISFA For Communications) record creates five datasets:
EXVMISFE
EXVMISFI dddddd Dataset Description
EXVMISFL VMISFA VMISFA ISFC ACTIVE CONVERSATION
EXVMISFS VMISFE VMISFE ISFC END CONVERSATION
FORMATS VMISFI VMISFI ISFC INITIATE CONVERSATION
VMXGINIT VMISFL VMISFL ISFC LINK STATISTICS
TYPEVM VMISFS VMISFS ISFC START CONVERSATION
Jul 19, 2010
Thanks to Greg Reed, Travelport GDS, USA.
Thanks to Rick Stuchell, Travelport GDS, USA.
Change 28.156 Support for IFCID=27 decodes QW0027SP and QW0027NR and
FORMATS decodes and formats QW0027OZ.
VMAC102
Jul 18, 2010
Thanks to Victoria Lepak, Aetna, USA.
Change 28.155 MXG 28.04, only if _N7072 is used. The output of the new
VMAC7072 temporary TYPE70EC and TYPE70EL datasets now names their
Jul 17, 2010 _WTY70EC and _WTY70EL tokens so that _N7072 can be used.
Thanks to Kim Westcott, State of New York, USA.
Change 28.154 -MXG detection of inserted or excluded fields in CICS 110
VMAC110 is enhanced by test for CPUTM GT 2*ELAPSTM that prints
Jul 18, 2010 error messages if true. Previous IF TASKNR=. tested the
Jul 21, 2010 only Packed Decimal field, which is a missing value if
MXG was out of alignment, but that could overlook new
inserted fields after the location of Task Number.
-Spurious message that STID=110 had skipped data removed;
the SKIP=SKIP-604 should have been SKIP=SKIP-652, but the
CICW2R dataset was correct in spite of that message.
-Variable PGDPGM, Program Name, was not kept in dataset
CICPGD, nor was it labeled, a major oversight as all of
the information in CICPGD Statistics are for the program!
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.153 XAM TCP datasets TOTCPU were incorrectly divided by 100.
VMACXAM
Aug 15, 2010
====== Changes thru 28.152 were in MXG 28.04 dated Jul 5, 2010========
Change 28.152 Support for zTPFC, TPF Continuous Monitoring has a few
EXTPFC92 fields added to existing datasets and two new datasets
EXTPFC98 added by this change
IMACTPFC
VMACTPFC DDDDDD DATASET Description
Jul 2, 2010
Jul 21, 2010 TPFC92 TPFC92 LPAR UTILIZATION
TPFC98 TPFC98 DASD SERVICE TIME
Thanks to Bob Wilcox, HP, USA.
Change 28.151 Support for zCost AutoSoftCapping V 1.5.00 user SMF
EXZCO01 record, which replaces the TDSL product with these three
EXZCO02 new datasets:
EXZCO03
IMACZCOS dddddd dataset description
TYPEZCOS
TYPSZCOS ZCO01 ZCOS01 ZCOST CPC
VMACZCOS ZCO02 ZCOS02 ZCOST LPAR
VMXGINIT ZCO03 ZCOS03 ZCOST SYSPLEX/CPC
Jul 2, 2010
Thanks to Alan Delaroche, zCostServices, FRANCE.
Change 28.150 Type 42 subtype 15 did not protect for new data, and the
VMAC42 addition of variables SMF42FAI and SMF42FAJ caused the
Jul 1, 2010 second and subsequent segments to be misaligned with bad
data values resulting in TYPE42S1 dataset.
Thanks to Michael Friske, FMR, USA.
Change 28.149 Sample reports had typos, corrected.
ANAL119
Jun 30, 2010
Change 28.148 TMS DEVTYPE was blank for TRTCH 'F0'X thru 'FF'x, which
VMACTMS5 are now decoded as 3592 or Titanium devices.
Jun 28, 2010
Thanks to Scott Barry, SBBWorks, USA.
Change 28.147 Another kewl tool. Will search data libraries for all
VMXGSRCH variables that match a specific character string.
Jul 4, 2010 You can:
-PRINT X OBS of every dataset where any variable has
a match
-PRINT X OBS of every dataset where any variable has
a match and copy all of the OBS to some other DD
-or just get a count of the number of variables and
datasets and obs that have a match.
Example 1: PRINT ALL OBS IN ALL DATASETS WHERE
the value of any variable is CHUCK.
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=PRINT,VALUE=CHUCK);
Example 2: PRINT/copy ALL OBS IN ALL DATASETS WHERE
the value of any variable is CHUCK.
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=PRINT,VALUE=CHUCK,
COPYTO=WORK);
Example 3: PRINT/copy ALL OBS IN ALL DATASETS WHERE
the value of any variable is CHUCK, but suppress
the NOTES on the log (and there are LOTS of them).
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=PRINT,VALUE=CHUCK,
COPYTO=WORK,LOG=NO);
Example 4: COUNT just tell me how many variables
in how many datasets and obs have a match.
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=COUNT,VALUE=CHUCK,
LOG=NO);
Thanks to Chuck Hopf, Independent Consultant, USA.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.146 -Major enhancement to DB2PM-like reporting in ANALDB2R
ANALDB2R which has been upgraded to support DB2 V9 data, and is
ASUMDBAA internally completely revised to make maintenance simple
EXDB2ACR in the future.
FIXDB2A -And, a MAJOR change in PDB.DB2ACCT Buffer Pool data:
TRNDDBAA Four sets of DB2 Buffer Pool variables QBnCxxx in DB2ACCT
VGETOBS DB2ACCTP and DB2STATS are redefined and contents changed.
VMACDB2 QB1Cxxx variables contain the 4K Buffer Size counters,
VMACDB2H QB2Cxxx variables contain the 8K Buffer Size counters,
VMXGDBAA QB3Cxxx variables contain the 16K Buffer Size counters
VMXGDBSS and QB4Cxxx variables now contain 32K Buffer counters.
Jul 4, 2010 Originally, the four sets of counters were for BP0, BP1,
Aug 14, 2010 all 4K, and all 32K, but then 8K and 16K counters were
added into the QB4Cxxx variables, making a real mess.
Individual Buffer Pool Statistics for EACH Buffer Pool
are available in the DB2ACCTB and DB2STATB datasets.
-New DB2ACCTR dataset is created with an observation for
each QLAC segment (for each Remote Location) in the
Accounting Records. The QLACxxxx variables in DB2ACCT
were previously from the first QLAC segment, but with
this change, those variables will be from the last one.
With hindsight, had I known there could be multiple QLACs
in an accounting record, I would have created ONLY this
DB2ACCTR dataset and would have not kept any QLACxxxx
variables in DB2ACCT. If there was only one Remote QLAC
segment, then there is no change in DB2ACCT.
*-All summarization of DB2ACCTx datasets now performed by
new VMXGDBAA internal macro, called by ANALDB2R and
ASUMDBxx and TRNDDBxx, replacing ASUMDB2A and ASUMDB2B.
*-All summarization of DB2STATx datasets now performed by
new VMXGDBSS internal macro, called by ANALDB2R and
ASUMDBSS and TRNDDBSS.
*-If you use the new ANALDB2R against old PDBs that do not
contain ASUMDBAA or ASUMDBSS datasets, the FIXDB2A can
be used to report from old ASUMDB2A/TRNDDB2A datasets, as
close as possible to the new architecture, but many new
report fields will be missing.
-Correction to PDB.DB2STATS interval logic.
-Number of SORTBY= variables for PMACC02 increased to 12.
-Reports now as close to current as V7 DB2PM documents.
-Future maintenance greatly simplified.
-In prior releases if you asked for both PMACC01 and
PMACC02 the input data was summarized twice. Now only
one summarization is needed.
-PMACC01/PMACC02 will look for the ASUMDBAA or ASUMDBSS
datasets and use them instead of the detail DB2ACCTx or
DB2STATS dataset if they exist.
-The original version of the accounting long report was
written to output a full line at a time with a _NULL_
data step. But, DB2PM was written in sections and IBM
could insert lines in different sections with each new
release making maintenance a real nightmare. Inserting a
line in one section could result in touching hundreds of
lines of the code. PMACC02 is completely rewritten using
the same structure - in sections - and outputs a page at
a time rather than a line, which should make future
enhancements much simpler. Code comments indicate what
section is being invoked.
-And PMACC01 was rewritten, although it remains a line
mode coding and report. All four Accounting reports
PMACC01/PMACC02/PMACC03/PMACC04 use the same inputs, and
new VMXGDBAA summarizes all accounting data with datasets
held in work to avoid an unneeded, now, resummarization.
-Numerous glitches were found in the logic to create the
PDB.DB2STATS dataset (from DB2STAT0/1/4/T102S225) that
have been corrected.
- GMTOFFDB calculation occasionally returned -14399.99
instead of -14400 due to the different resolutions of
QWHSSTCK (microseconds) and SMFTIME (10 milliseconds)
and truncation in the floating point representation.
GMTOFFDB algorithm enhanced to force exact hour.
This error caused the Local Time QWHSSTCK in DB2STAT0
to be later than the Local Time QWHSSTCK in DB2STAT1,
which caused me to believe that was an IBM error,
until I was corrected by DB2 Support that the subtype 0
is ALWAYS written first in each interval (when QWSDRINV
is '10'x, timer caused record to be written).
- Logic in VMACDB2H to force QWHSSTCK to be the same for
each interval as SMF records were read was invalid when
multiple subsystems records were simultaneously written
with all the subtype 0's in a group, then their 1's.
Logic was removed, so the PDB.DB2STAT0/1/4 QWHSSTCK are
now the actual value in those datasets. In PDB.DB2STATS
the value from DB2STAT0 is propagated, and DB2START is
created with the "start time" of each stat interval.
-NETSNAME construction was revised to test for FIRST8 to
also test LOCPERIO EQ 0 to populate NETSNAME correctly
when there was no period in the QWHCTOKN.
-VMACDB2 corrected: DB2 V9.1 data with more than one QLAC
segment caused "BAD TMON SUBTYPE 101 RECORD" message but
the record was IBMs and the error was mine. Length when
there length in header was zero was not handled correctly
for the second and subsequent QLAC sections.
Change 28.145 Cosmetic. Enabling SAS Option MSGLEVEL=I printed four
VMAC7072 INFO: messages that are now eliminated just to avoid
VMXG70PR confusion, as, (fortunately) there was no actual problem.
Jun 28, 2010 I have also added MSGLEVEL=I to the QASAS job.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 28.144 The VMXGPRNT utility that prints a single dataset with
VMXGPRNT variable name and variable label as headers is enhanced
Jul 4, 2010 to allow you to select which variables are printed.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.143 Support for z196 processor. This Change is REQUIRED FOR
VMAC7072 more than 64 engines, and the support was in MXG 28.04.
Jul 4, 2010 See Change 28.175 for full documentation, and more.
Change 28.142 Variable
VMAC7072 SMF70NCA='PCT WHEN*CAPPING*LIMITED*THIS ENGINE'
Jun 23, 2010 is now kept in TYPE70 dataset.
Thanks to Deb Soricelli, CIGNA, USA.
Change 28.141 Cosmetic. The Last Updated Date/Change of UTILEXCL will
UTILEXCL now be in a comment in the IMACEXCL member it creates.
Jun 23, 2010
Change 28.140 Major revision to SMF 113 support.
ASUM113 -TYPE113 now creates one obs per interval, with all four
VMAC113 sets of counters in one observation (instead of four obs,
Jun 23, 2010 each with one set of BASIC/PROGST/CRYPTO/EXTND counters).
Jun 28, 2010 -With all four counter sets in one obs, missing values in
variables added in Change 28.075 are eliminated.
-New variable SM113STM, Interval Start Time is created.
-New variable MIPSEXEC, Executed Million Instructions/sec
is created (but don't expect it to match published MIPS
"speed" values). (Thanks: Peter Enrico).
-The _STY113 dataset sort macro now tests //WORK and //PDB
and if TYPE70PR exists, adds variables CPUTYPE (2098),
SMF70CIN (Engine Type), CECSER, LPARWLMG (IRD FLAG),
SMF70CPA (SU_SEC), SMF70HDM (HiperDispatch Active?), and
SMF70CIX (Pool Number) to enhance PDB.TYPE113 dataset.
-New ASUM113 accomplishes the same enhancement as _STY113,
enhancing PDB.TYPE113 with those variables from TYPE70PR,
if you have old TYPE113 and TYPE70PR in the same PDB.
-The TYPE113 records are not synchronized with RMF/SMF so
the Polarity value of each engine is not yet added, nor
NRCPUS nor other non-static variables (i.e. can vary with
time), but IBM plans an APAR that will sync the 113's
with RMF/SMF, and MXG will add other TYPE70 variables and
new TYPE73 variable to TYPE 113 when that APAR is GA.
-The sort order of the PDB.TYPE113 dataset is now BY
SYSTEM READTIME JOB SM113STM.
-Occasional counter reset without a new interval flag have
been observed and are now protected (by deletion of that
interval) and detected (by printing an error message).
This error can be the result of two known causes:
1) Down level on the z10 micro-code.
The z10 needs to be at Driver 76 (GA2) and at least
at Bundle 20, as documented in John Burg's SHARE
paper. Bundle 20 also fixed some counter errors.
2) When IRD gets involved and varies off a CPU. Varying
off by IRD does NOT cut a final record; instead, when
it is finally varied back on you get an Intermediate
record for that interval, and over an hour elapsed
has been observed before that intermediate record was
written when the CP came back online.
(Thanks: John Burg).
-If you want create the enhanced PDB.TYPE113 dataset, and
only create that one output dataset in the //PDB library:
// EXEC MXGSASV9
//SMF DD DSN=YOUR.SMF,DISP=SHR
//PDB DD DSN=YOUR.TYPE113.PDB,DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(25,25))
//SYSIN DD *
%LET PTY70=WORK; %LET PTY70PR=WORK;
%LET PTY7002=WORK; %LET PTY70X2=WORK;
%LET PTY70Y2=WORK; %LET PTY72=WORK;
%LET PTY72DL=WORK; %LET PTY72GO=WORK;
%LET PTY7204=WORK; %LET PTY72MN=WORK;
%LET PTY72SC=WORK;
%UTILBLDP(BUILDPDB=NO,
USERADD=7072 113,
ZEROOBS=70.2 72,
OUTFILE=INSTREAM);
%INCLUDE INSTREAM; RUN;
PROC DATSETS DDNAME=WORK MT=DATA NOLIST;
DELETE TYPE7:;RUN;
Thanks to Richard Schwartz, State Street Bank, USA.
Change 28.139 These "recently" added SMF30xxx variables are now kept in
BUILD005 the PDB.STEPS dataset (but are not carried forward into
BUIL3005 the PDB.JOBS dataset, but might be in the future, based
Jun 23, 2010 on feedback from this change).
SMF30AIC='DASD CONNECT*ASID PLUS*DEPENDENT'
SMF30AID='DASD DISCONNECT*ASID PLUS*DEPENDENT'
SMF30AIS='DASD SSCH*ASID PLUS*DEPENDENT'
SMF30AIW='DASD PEND+CU*ASID PLUS*DEPENDENT'
SMF30ASP='ASID*DESIGNATED*STORAGE-CRITICAL?'
SMF30CCP='SRVCLASS*DESIGNATED*CPU-CRITICAL?'
SMF30CPR='ASID*CURRENTLY*CPU-PROTECTED?'
SMF30CSP='SRVCLASS*DESIGNATED*STOR-CRITICAL?'
SMF30EIC='DASD CONNECT*INDEPENDENT*ENCLAVES'
SMF30EID='DASD DISCONNECT*INDEPENDENT*ENCLAVES'
SMF30EIS='DASD SSCH*INDEPENDENT*ENCLAVES'
SMF30EIW='DASD PEND+CU*INDEPENDENT*ENCLAVES'
SMF30HSH='HWM*USABLE BYTES*IN 64-BIT*SHARED'
SMF30HSO='BYTES IN*64-BIT*SHARED*STORAGE'
SMF30HVA='HWM*AUX*SLOTS*BACK*64-BIT'
SMF30HVH='HWM*USABLE BYTES*IN 64-BIT*OBTAINED'
SMF30HVO='BYTES IN*64-BIT*STORAGE*OBTAINED'
SMF30HVR='HWM*REAL*FRAMES*BACK*64-BIT'
SMF30JPN='SUBCOLN*FROM*IWMCLSFY'
SMF30MRA='CPU*RATE*SU_SEC*FACTOR'
SMF30MRD='DEPENDENT*ENCLAVES*CPU*TIME'
SMF30MRI='INDEPENDENT*ENCLAVES*CPU*TIME'
SMF30MRS='SYSTEM*NAME*WHERE*ENCLAVES*RAN'
SMF30MSI='REMOTE*SYSTEM*DATA*INCOMPLETE?'
SMF30PFR='SRVCLASS*WAS MODIFIED*DURING*EXECUTION?'
SMF30SNF='ZIIP NORMALIZATION FACTOR'
SMF30SPR='ASID*CURRENTLY*STORAGE-PROTECTED?'
SMF30WMI='EXECUTING*IN*WLM*INITIATOR?'
SMF30ZNF='ZAAP NORMALIZATION FACTOR'
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 28.138 Support for SysView Subtype 3 record creates new dataset
EXSVTH03 SV03THRE='SYSVIEW THRESHOLD EXCEPTION 03'.
FORMATS
IMACSVIE
VMACSVIE
VMXGINIT
Jun 21, 2010
Thanks to Mike Paladino, Progressive Insurance, USA.
Change 28.137 Support for BMC IMF records written in SMF Format in new
TYPEIMFS member TYPEIMFS, which handles the SMF header, and sets
VMACCIMS OFFIMS, and in updates to VMACCIMS, as not all of its
Jun 20, 2010 INPUTs and LENGTH tests included OFFIMS. This iteration
will ONLY process IMF 'FA'x and 'F9'x SMF record IDs in
the infile SMF dataset. TYPEIMFS creates the same MXG
datasets in the same default LIBNAMEs as member TYPECIMS.
Thanks to Denise Willers, Infocrossing, USA.
Thanks to Ken Steiner, Infocrossing, USA.
Change 28.136 Variable R748CSER, the Controller Serial Number is now
VMAC74 kept in TYPE74A, TYPE748R and TYPE74X datasets.
Jun 24, 2010
Thanks to Pat Jones, DST, Inc, USA.
Change 28.135 Cosmetic. MXG Error messages when bad EXCP segments are
VMAC30 found now print the ABEND, CONDCODE, and ABNDRSNC values.
VMACEXC2 Precipitated by a series of error messages with bad EXCP
Jun 17, 2010 and MULC segments for jobs with SYSTEM 0D5 ABENDS.
Jun 24, 2010 The PUT of ABNDRSNC caused it to be defined as numeric
when ANALALL was executed, because the VMACEXC2 was used
first in SMF 4 record code, before ABNDRSNC was INPUT.
Using PUT ... ABNDRSNC= $8; resolved that weird error.
Thanks to Trevor Ede, HP, NEW ZEALAND.
Change 28.134 CICS Statistics Record INVALID STILEN=0 fortunately was
VMAC110 harmless, as it occurred after the STID=116 segment had
Jun 16, 2010 been output CICSJS. MXG had read only 156 bytes of the
164 bytes of STID=116, causing the error, now fixed.
Thanks to Tom Buie, Southern California Edison, USA.
Change 28.133 Support for WebSphere SMF 120 Subtype 20 Job Usage data.
EXT12020 Has only been coded, records skipped until test data
VMAC120 exists for validation.
Jun 16, 2010 See Change 28.258.
Change 28.132 Replaced by Change 28.146.
Change 28.131 IMS Log 56x record subtype 15x caused INVALID DATA or
VMACIMS INPUT STATEMENT EXCEEDED RECORD LENGTH errors. code was
VMACIMSA relocated. Only the 15x variables are now kept in IMS56F
Jun 14, 2010 dataset. STIMSID removed from all IMS56x datasets.
Thanks to Lindholm Orjan, Volvo, SWEDEN.
Change 28.130 Correction to calculation of index space; value in the
ASMRMFV RMFV018I message was slightly low, as 1111 was used in
Jun 10, 2010 the denominator instead the correct value of 1110.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 28.129 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE:
EXDB2ACR -All three DB2 records (100,101,102) can be compressed;
EXDB2ACW For z/OS execution, the EXITCICS member's INFILE exit
FORMATS now decompresses both DB2 and the original CICS records.
IMACDB2 For ASCII SAS, where there are no INFILE exits, or for
VMACDB2 z/OS without the exit installed, records are decompressed
VMACDB2H with internal SAS code, but that is EXTREMELY EXPENSIVE
VMACSMF on z/OS compared with using the INFILE exit, so MXG warns
VMXGINIT that you should install the exit to save CPU time.
VMXGWORL
Jun 16, 2010
Jun 19, 2010
Jun 21, 2010
-INVALID DATA FOR QWHSRELN is proof you have DB2 V10 SMF;
QWHSRELN is not a valid "PK" value; it now has 'A1'x, so
VMACDB2H was revised. The value is 10.1, not 10.0.
-And INPUT STATEMENT EXCEEDS RECORD error ABENDs may occur
because fields were inserted rather than added at the end
where MXG would have automatically skipped them.
-Subtype in SMF Header INCOMPATIBLY increased from one to
two bytes (because that's what it should have been all
along. However, only SMF 100 and 101 records populate
the subtype in the SMF Header. VMACSMF was updated to get
the DB2 version and then input the subtype correctly.
(MXG has always stored the IFCID value in SUBTYPE for the
DB2 102 trace records, since they don't have a subtype.)
-New DB2ACCGW dataset is created for each QWAR segment,
which can be used to correlate rollup records.
-Multiple SMF 100 Subtype 1 (DB2STAT1) IFCID=2 records are
now supported (Jun 21 2010). These records contain only
QBST or QBGL segments and are written when more than 25
buffer pools are used in an interval.
-Macro _SDB2STS was redesigned to correct DUPLICATE MERGE
VALUES errors that occur only if DB2 was restarted, by
removing QWHSACE QWHSMTN from the _BDB2STS "BY list", by
interleaving the four input datasets to create STATSGROUP
to use as merge variable (QWHSSTCK cannot be used as it
not exact in all four records for each interval), and by
conditionally merging T102S225 (DB2 V8) if it exists.
The _SDB2STY macro is now a null macro and no longer
used. The new sort order for the PDB.DB2STATS dataset is
now SYSTEM QWHSSSID QWHSSTCK. A cosmetic enhancement to
VMXGWORL, NOWARN=YES, is used to suppress the MXGNOTEs
when a tested dataset is known to not always exist (used
for T102S225 in this change).
-Many new variables added to DB2ACCTx/DB2STATx by V10:
DB2ACCT:
QLACRLNU
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTB:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTG:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2STAT0:
Q9STCDMD QDSTNQWC QDSTNARD QDSTMARD
D64POST A64POST A64WAIT M64DISNU M64DISPG SGETR64
SGETEXT6 SGETDEXT SFREER64 SFREEDEX DISCARDM
QWS1MCPU QWS2MCPU QWS3MCPU QWS4MCPU
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STAT1:
QISEKSPG QISEKSPA QISEKLRU QISEDLRU QISESQCB QISESQKB
QISESQCA QISESQKA
QISTRCCI QISTRCCD QISTRCCU QISTWMXA QISTWMXU QISTWCTO
QISTW4K QISTW32K
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STATB:
QBSTFLG
DB2GBPST:
QBSTFLG
-SMF 102 IFCIDs 172 and 196 were compatibly updated.
-SMF 102 IFCIDs 267, 268, 317, and 337 are now decoded.
New formats are created by the updated FORMATS member.
-These other IFCIDs in user-sent SMF files are presumably
the trace records that are normally written or needed.
They have been examined and none were change in V10:
4,5,55,87,105,140,141,173,196,199,250,254,258,261,262
-See the text of Change 28.146, which made changes to DB2
processing that were independent of the Beta, including
fixing the PDB.DB2STATS interval issue that was first
discussed in this change text, but was not V10 related.
Change 28.128 WARNING: APPARENT INVOCATION OF MACRO TRIM NOT RESOLVED
CONFIGV8 WARNING: APPARENT INVOCATION OF MACRO CMPRES NOT RESOLVED
CONFIGV9 Other: References to MACRO DATATYP in an EVAL statement
Jun 9, 2010 which may be followed by
ERROR: A character operand was found in %EVAL function
or %IF where a numeric operand is required ....
There are several "opportunities" for this error:
-These options must be in effect to resolve %TRIM:
OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS);
They are normally set in MXG CONFIGVn, but we have seen
instances in which (typically very old) user code has
changed those options, causing the error.
-The //SASAUTOS DD must point to the "AUTOCALL" dataset
(SAS-provided PDS) that contains the TRIM member.
-Ancient MXGSASxx JCL procs defined &SASAUTOS which was
&NULLPDS, and also had //SASAUTOS DD &SASAUTOS
// DD DSN=....
but that was replaced years ago; look at MXGSAS92 for
SAS V9.2 or MXGSASV9 for SAS V9.1.3 for correct JCL.
-OPTIONS S2=0 must be specified; it is set in CONFIGV9,
but I just discovered that CONFIGV8 still had S2=72;
that was corrected to S2=0 by this change.
-Additionally, the incorrect LOCALE can cause failures
with entirely different error messages when %TRIM is
used, due to the NOT symbol's mis-translation with the
wrong LOCALE. See Change 28.194 documentation.
-To diagnose, use // EXEC MXGSASV9,OPTIONS='VERBOSE'
and OPTIONS SOURCE SOURCE2 MACROGEN MPRINT SYMBOLGEN;
as the first //SYSIN DD statement, and send the FULL
job log.
Change 28.127 Support for revised CA $AVERS SMF record (INCOMPATIBLE)
VMACSAVR increased field lengths, and added new data. Dataset
Jun 8, 2010 contains new variables JCTJOBID, TYPETASK, SAVRACCT.
Thanks to Clement Turner, DC Government, USA.
Thanks to Edouard A. Myers, DC Government, USA.
Thanks to Roger B. Legerwood, DC Government, USA.
Change 28.126 Support for Rocket Software MXI User SMF record creates
EXMXIST1 three datasets:
EXMXIST2
EXMXIST3 dddddd Dataset Description
IMACMXI
TYPEMXI MXIST1 MXIONE MXIST1: INITIALIZED
TYPSMXI MXIST2 MXITWO MXIST2: TERMINATED
VMACMXI MXIST3 MXITHREE MXIST3: COMMAND AUDITED
VMXGINIT
Jun 8, 2010
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 28.125 Enhancement to support building weekly and monthly PDBs
BLDNTPDB when your first-day-of-week is not the MXG "MON" default.
BLDSMPDB -VSETMNTH utility correctly determines which daily PDBs
MONTHASC are to be read in building week/month; the decision is
MONTHBL3 based on TODAY() and the "STARTDAY" of your week.
MONTHBLD
MONTHDSK -New macro variable STARTDAY sets the "first day of week"
VMXG2DTE default to MON (no change), and is now used internally in
VMXGDUR all MXG programs, so that you can externally change that
VMXGLBIN first day of week if you do not build your WEEKLY/MONTLY
VMXGSUM with MONDAY as the first day.
VSETMNTH
Jun 17, 2010 -However, the %BLDSMPDB can be used as your "MONTHBLD" or
Jun 28, 2010 WEEKBLD program, and its WEEKSTRT argument can specify
the different start day of week if desired:
Weekly job:
%BLDSMPDB(WEEKSTRT=SUN,RUNDAY=NO,RUNWEEK=YES,RUNMNTH=NO,
WEEKKEEP=list of datasets);
add WEEKTAPE=YES, if WEEK PDB is to be written to tape.
Monthly job:
%BLDSMPDB(WEEKSTRT=SUN,RUNDAY=NO,RUNweek=no,RUNMNTH=YES,
MNTHKEEP=list of datasets);
add MNTHTAPE=YES, if MONTH PDB is to be written to tape.
WEEKKEEP/MNTHKEEP are only necessary if you wish to
keep only specific datasets in the WEEK/MONTH PDB (the
default is _ALL_.) There is also WEEKDROP/MNTHDROP to
drop specific datasets (and it defaults to dropping any
SPIN* SPUN* datasets). BLDSMPDB will use the SORTEDBY
option in the dataset directory to construct a BY list
if present but can also parametrically be told to
ignore the SORTEDBY.
Thanks to Jim Agrippe, Cleveland Clinic, USA.
Thanks to Ron Wells, American General Finance, USA.
Change 28.124 The WTIRIOTM in PDB.ASUMUOW could be larger than IRESPTM.
VMXGUOW Change 17.324 corrected the problem (WTIRIOTM was the sum
VMXGUOWT of WTIRIOTM's from ALL of the CICSTRAN obs in the UOW),
VMXGUOTT but a subsequent update in Change 18.204 lost that fix.
Jun 4, 2010 It is now the MAXIMUM value from all of the CICSTRAN obs.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.123 Utility program to examine TYPE72GO dataset to assist in
UTILWORK creating or investigating workload definitions for the
Jun 7, 2010 RMFINTRV.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.122 Logic revised to use DATEJUL to parse the date, but if
ASUMHSM the FSRDATR field is not a valid Julian Date, it is left
Jun 7, 2010 as a missing value.
Thanks to Tobias Cafiero, DTCC, USA.
Change 28.121 -ANALRANK is enhanced to add an output dataset option. By
ANALRANK using this you can get the top 10 each day, by appending
VGETLABL daily data you can quickly get the top 10 for the month
VGETFMT by pushing the daily top 10 back thru ANALRANK. Using
Jun 4, 2010 VGETLABL, the labels in ANALRANK are enhanced so that the
label of RANKxx variable contains the original variable's
label plus the word rank. So the label for CPUTM would
become 'TOTAL*CPU TIME*CAPTURED*RANK'.
-VGETLABL - New utility to GET the LABEL of a variable.
-VGETFMT - New utility to GET the FORMAT of a variable.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.120 -Variable QBACPID, Buffer Pool ID, is removed from dataset
VMACDB2 DB2ACCTP where it never belonged; packages can use many
Jun 3, 2010 buffer pools. The other QBACxxxx variables exist, but are
only non-missing (i.e., populated) if DB2 Accounting
Class 10 is enabled.
-DB2ACCTB - QLACCNVR didn't belong in KEEP list.
-DB2ACCTG - QLACCNVR didn't belong in KEEP list.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.119 Support for Performance Sentry NTSMF Version 3.1.4.4.
EXNTGENE -Existing objects were modified:
EXNTIPA4 Dataset - Object Name
EXNTIPA6 IPSECDRI - IPsec Driver - fields removed
EXNTIPK4 VMGUESTA - VMWARE.Guest.Aggregate - fields added
EXNTIPK6 VMGUUCPU - VMWARE.Guest.CPU - field added
IMACNTSM VMGUUMEM - VMWARE.Guest.Memory - fields added
VMACNTSM VMHOSTAG - VMWARE.Host.Aggregate - fields added
VMXGINIT VMWHOCPU - VMWARE.Host.CPU fields added
JUN 7, 2010 VMWHOMEM - VMWARE.Host.Memory fields added
VMWHONET - VMWARE.Host.Net fields added
VMWHOSYS - VMWARE.Host.SYS fields added
-New objects supported:
dddddd Dataset Object Name
NTGENE GENERIKE GENERIC IKE AND AUTHIP
NTIPA4 IPAUTHV4 IPSEC AUTHIPV4
NTIPA6 IPAUTHV6 IPSEC AUTHIPV6
NTIPK4 IPSECIK4 IPSEC IKEV4
NTIPK6 IPSECIK6 IPSEC IKEV6
-These xxxxINST variables were increased to $64:
MLLOINST QLWGINST SAALINST VWHCINST VWHDINST
Change 28.118 Support for BMC Mainview Auto Operator data creates nine
EXMVAOAC datasets:
EXMVAOAL
EXMVAOEV dddddd Dataset Description
EXMVAOEX MVAOAC MVAOACTN MV AUTO OPERATOR ACTN
EXMVAORE MVAOAL MVAOALRT MV AUTO OPERATOR ALRT
EXMVAORU MVAOEV MVAOEVNT MV AUTO OPERATOR EVNT
EXMVAORA MVAOEX MVAOEXEC MV AUTO OPERATOR EXEC
EXMVAORS MVAORE MVAORES MV AUTO OPERATOR RES
EXMVAOTA MVAORU MVAORULE MV AUTO OPERATOR RULE
IMACMVAO MVAORA MVAORUAU MV AUTO OPERATOR RULESET AUTO
TYPEMVAO MVAORS MVAORUSE MV AUTO OPERATOR RULESET SET
TYPSMVAO MVAOTA MVAOTAPE MV AUTO OPERATOR TAPE
VMACMVAO Aug 5: TAKETOTL removed from KEEP=, second "HANDLED" was
VMXGINIT removed from LABEL, and all %VMXGDEL(DDDDDD= corrected.
May 31, 2010
Aug 5, 2010
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.117 Change 28.039 changed R7451RID to be the first byte due
VMAC74 to values observed in SMF 74 Subtype 5 records from IBM
Jun 1, 2010 sites, but those observed values are not consistent in
other records from other sites, which have the RID in the
second byte and a zero in the first byte so this change
sets R7451RID to the second byte of that 2-byte field, if
if the first byte is zero. Additionally, fields listed in
notes 2 and 3 of the SMF manual are set missing based on
the value in R7451FLG.
Thanks to Melanie Hitchings, BT, ENGLAND.
Change 28.116 Support for SMF 102 IFCID 263 now decodes the unique data
VMAC102 fields; previously, only Header variables were output
May 27, 2010
Jun 11, 2010
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.115 ANAL42DS failed with Data Set _NULL_ Not Found, because
ANAL42DS an _NULL_ is needed after the DATA statement.
May 26, 2010
Thanks to Sam Bass, McLane Co., USA.
====== Changes thru 28.114 were in MXG 28.03 dated May 25, 2010========
Change 28.114 Additional diagnostics to show which service classes and
UTILRMFI which reporting classes have missing data using SMFINTRV
May 25, 2010 dataset.
Change 28.113 New analysis of each DB2 Buffer Pool in DB2ACCTB dataset
ANALDB2B including a buffer hit ratio calculation.
May 25, 2010
Thanks to Santosh Kandi, JC Penney, USA.
Change 28.112 UTILRMFI failed because macro variable VWDUPES has been
VMXGINIT truncated to WDUPES in the %GLOBAL statement in VMXGINIT.
May 25, 2010
Thanks to David Young, University of California Office of Pres, USA.
Change 28.111 ThruPut Manager field REGIONSZ and $JXDBSPR/WW/UU fields
VMACTPMX were reported as UNKNOWN due to typo's in text tests,
May 24, 2010 and $JXDBSUN is now created.
Thanks to Paul Volpi, UHC, USA.
Change 28.110 The last "response" bucket created by VMXGRESP utility
ASUMDB2 (number specified plus 1) was never right, because every
VMXGRESP count that was GT was already put in the last bucket.
May 22, 2010 -Enhancement to include bucket values in labels, and a new
UNITS parameter describes the units (seconds/jobs/mounts)
that are being measured.
-ASUMDB2 implements the new UNITS= parameter.
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 28.109 -WPS %MACRO Language Compiler Error in READDB2, the error
ANALINIT cites a problem with %INCLUDE, but the statement that is
EMAIL flagged is the percent sign in %STR(MACRO _Edddddd ....
READDB2 (The _Edddddd generates %%INCLUDE SOURCLIB(EXDDDDDD);.)
UTILCONT A guess, to replace %STR() with %QUOTE() in statements
VFMT102 with that syntax DID circumvent the WPS compiler error!
May 21, 2010 -This same error can occur with ANALDB2R if (PDB=SMF,...)
is used, since ANALDB2R calls READDB2 to "READ" DB2 SMF.
-But, since READDB2 generates MACRO _Edddddd references
only when one of the optional/rare dataset sub-tokens is
used to select the observations, for example /DB2ACCT in
%READDB2(IFCIDS=ACCOUNT,DB2ACCT=YES/IF QWHSSSID='XYZ';);
so it was safer to replace %%INCLUDE SOURCLIB(EXDDDDDD);
statements with OUTPUT _WDDDDDD; to both circumvent
the Compiler error, and because the EXDDDDDD should not
have been created in READDB2 in the first place.
-An unrelated error when the dataset sub-token was used is
also corrected.
-The WANTONLY subarguments were further validated.
-In validating this READDB2 change, additional exposures
were corrected:
-VFMT102: If T102S105 and T102S107 did not exist, logic
to build OBIDS/DBIDS dataset failed: the &VGETOBS NE 0
test was changed to VGETDSN=datasetname, as it is the
existence of, and not the number of observations in,
that is the needed conditional test.
But this caused investigation of other &VGETOBS NE 0:
-ANALINIT: VGETOBS test changed to VGETDSN.
-EMAIL: VGETOBS NE 0 changed to GE 0.
-UTILCONT: VGETOBS NE 0 change to GT 0
Change 28.108 Support for CleverView for TCP/IP TN3270 Performance Data
EXCTCPTN in new SUBTYPE=21 SMF User Record, creates new CTCPTN32
IMACCTCP dataset with the existing TYPECTCP/TYPSCTCP programs.
VMACCTCP
VMXGINIT
May 20, 2010
Thanks to John Howard, Florida Northwood Shared Center, USA.
Change 28.107 -RACF INPUT STATEMENT EXCEEDED with RACFEVNT=21 LDAPHOST
VMAC80A in TOKDANAM; MXG coded for only a 32-byte LDAP Host Name,
May 19, 2010 but length was 35. Now protected for any length.
-In records with LDAPHOST, new TOKDANAM BINDDN and BINDPW
were found and decoded into variables TOKBINDD TOKBINPW.
Yes, "PW" is a Password, but, no, it doesn't appear to be
an exposure, as the value is populated with asterisks.
-TOKDANAM='APPLNAM ' text is now decoded into TOKAPLNM.
-TOKDANAM='UTYPE', 'JPNUM', numerics in TOKUTYPE/TOKJPNUM.
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 28.106 The offset SMF92MPF to the Path name length SMF92PPL was
VMAC92 incorrect, causing SMF92PPN, Path Name to be blank and
May 19, 2010 SMF92PPL contained a large and wrong value.
Thanks to David Young, University of California Office of Pres, USA.
Change 28.105 -Optional TRENDing enhancement lets you tell VMXGSUM how
VMXGSUM many KEEPWEEK=/KEEPMNTH=/KEEPYEAR=/KEEPDAYS='s you want
May 19, 2010 kept in TREND output, or KEEPAFTR=01JAN2010 can be used
to output only observations GE that DATE.
-The KEEPxxxx options are only valid when DATETIME= is
used, and the value of the DATETIME= variable is tested
for each observation if it is to be output.
-A KEEPxxxx argument forces an INCODE= to be created if
one was not present; all MXG TRNDxxxx members already
have an INCODE= argument, and INCODE normally VIEWs, so
this should have minimal impact.
-Messages are not written that obs were not output.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 28.104 Support for field inserted at start of NDM-CD record.
VMACNDM New MACRO _NDMADD defaults to 0, but you can use MACKEEP
May 17, 2010 to change _NDMADD to 8 to skip 8 bytes after SYSTEM (and
to set the SMF TYPE of your NDM-CD record in _NDMID):
%LET MACKEEP=
MACRO _NDMADD 8 %
MACRO _NDMID 0FAX %
;
%INCLUDE SOURCLIB(TYPSNDM/BUILDPDB);
Eight bytes can't just be added to OFFSMF in MACFILE for
NDM-CD SMF because VMACSMF RETAINs OFFSMF, so new OFFNDM
replaced OFFSMF in VMACSMF after the first INPUT.
Thanks to Fred Buerger, Visa, Inc, USA.
Change 28.103 Support for TOKDANAM='SHARED' token, output in TYPE80TK.
VMAC80A
May 12, 2010
Thanks to Jacky Kwoka, SNCF, FRANCE.
Change 28.102 Support for user-created ECPAUDIT optional CICS variable.
IMACAAAA
IMACICUK
UTILEXCL
VMAC110
May 12, 2010
Thanks to Matt Feeney, DoD, AUSTRALIA.
Change 28.101 -IMS56xx datasets were not output because the variable for
VMACIMS subtype test should have been TPCPSSTY, and not TPCPSBCD,
VMACIMSA and the subtype test is for only one byte.
May 11, 2010 -Subtype 56x SSTY 11x INPUT STATEMENT EXCEEDED exposed MXG
May 18, 2010 mis-alignment; the +(-16) before TPIMSID does not exist,
and the +36 segment after the "NID" is conditionally read
as it doesn't exist in SSTY=0FAx records.
-In validating the printed output, the SYNCTIME in TYPE59x
datasets was not converted to local time.
-Multiple separate code stubs to calculate IMSSTCK were
replaced with LINK IMSSTCK; statements.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Change 28.100 MXG 27.07 removed 13 duplicates in TYPE30_1 for an STC
BUILDPDB that were (correctly!) NOT removed by MXG 28.02. Variable
May 10, 2010 ASID has been added to TYPE30_1, and 'pseudo' duplicates
had different ASIDs and thus were not duplicates.
Oct 2010: See MXG Newsletter 57, DUPLICATE JESNR.
Thanks to Paul Volpi, UHC, USA.
Change 28.099 Variable CPULHKTM, CPU Time When Promoted due to Lock
VMAC7072 HOLD, is now INPUT and kept in TYPE72GO; it was added by
May 10, 2010 z/OS 1.11 as IBM field R723LPDP.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 28.098 The %VMXGSET macro is enhanced with DSETOPT= argument so
VMXGSET SAS Data Set Options (DROP/KEEP/RENAME/etc) can be added
May 4, 2010 to each data set that will be "SET". This example syntax
%VMXGSET(DATASET=JOBS,DSETOPT=KEEP=JOB READTIME JESNR CPUTM);
will keep only those four variables when xxx.JOBS dataset
is read. Surprisingly, using a KEEP= on a SET statement
has minimal impact on CPU time, saving 7 out of 86 secs.
But using DSETOPT to RENAME variables could be useful.
Thanks to George Pandzik, USAA, USA.
Thanks to Brian A. Harvey, HCL America, USA.
Change 28.097 Type 74 subtype 8 R748LERT,R748LEWT,R748LPST variables
VMAC74 are correct in MXG; they are documented as accumulated
May 4, 2010 values in the SMF manual, but actual data values are not.
Variable R748LAID, the Interface ID is added at the end
of the _BTY748 BY list to ensure NODUP works when sorted.
To verify non-accumulation, it was necessary to insert
R748LAID before STARTIME, to group the observations to
see if the values were always-increasing, and that is
where it really belongs in the BY list, but inserting a
variable in an existing BY list is LETHAL for someone,
somewhere, who's already (accidentally?) combining days
and weeks PDBs, so it is added at the end for NODUP, as
that doesn't create a not-sorted exposure.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.096 When the LIB is in sequential or xport format, that type
VGETOBS was identified, but only now is the dataset name printed.
Apr 30, 2010
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.095 Elegant logic using the FINDW() function to parse the
VMACAIX AIX record's changed format for the HOSTNAME field
May 21, 2010 UPCRECRD=UPCASE(RECORD);
LOCHOST=FINDW(UPCRECRD,'HOSTNAME:',' ','E') +1 ;
HOSTNAME=SCAN(RECORD,LOCHOST,' ');
HOSTNAME=TRANSLATE(HOSTNAME,' ','"');
cannot be used with SAS 9.1.3 nor with WPS 2.4.0.1,
because the FINDW() function only exists in SAS V9.2.
The old SCAN() function was used with less elegance.
Change 28.094 XAMSYS variables CALAVGM1 CALTOTM1 CALAVGM2 CALTOTM2
VMACXAM record units are 16 microseconds, so they are now INPUT
Apr 29, 2010 by &RB4.6 and multiplied by 16, so they are seconds and
fractions of a second, and are FORMATed with TIME16.6, an
MXG convention so you know these are duration variables,
and so full resolution is printed, so 416 microseconds is
printed as 0:00:00.000416.
Variable SRMTSLIC is in TOD duration record units, so it
is now INPUT by &PIB.8.6 and divided by 4096 into seconds
and fractions and also FORMATed with TIME16.6.
Variable SRBABSDL is a percentage, but scaled by 65536,
so it is now divided by 65535.
Thanks to Dave Sadler, United Health Group, USA.
Thanks to Rob van der Heij, Velocity Software, THE NETHERLANDS.
Change 28.093 Circumvention for SMF 42 Subtype 15 INVALID OFFSETS. The
VMAC42 record has OFF42S3=216 and OFF42S4=4056, but the data are
Apr 28, 2010 at 108 and 3948. MXG forces S3=108 and calculates S4.
Thanks to Michael Friske, FMR, USA.
Change 28.092 This ancient program to create a z/OS PDS from the MXG
IEBUPDTE IEBUPDTE-format source file had defined values for the
Apr 28, 2010 input and output, which required you to EDIT and SAVE
and then %INCLUDE SOURCLIB(IEBUDTE); to execute, but
those three macro variables are no longer set to any
value, so you can set them to your choice and then run.
Thanks to Bernhard Babblok, Allianz ASIC SE, GERMANY.
Change 28.091 -MXG 28.02. IMS record 55x subtype 01x from IMS 9.1 caused
VMACIMS INPUT STATEMENT EXCEEDED RECORD LENGTH; support for 55x
Apr 26, 2010 was added, but only tested with IMS 10 and 11. The 55x
record is for External Subsystems. The 01x record isn't
described in the DSECT, so it is now deleted.
-The 35X record with ENQFLAG=2F and FLAG2=00X or 08X is
now output in IMS35P dataset.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Change 28.090 Variable FIXEDSTO was incorrectly input as &RB.4. It is
VMACXAM a &PIB.4. INFORMAT now. Variable MONEVNTS is an address
Apr 25, 2010 so it is now formatted HEX8.
Thanks to Paul Volpi, UHC, USA.
Change 28.089 The PDB.SMFRECNT dataset and its report only counted SMF
BUIL3001 records; this enhancement provides both the record count
BUILD001 and the byte count for each SMF record and Subtype for
BUILDPD3 each SYSTEM, in both PDB.SMFRECNT and the report.
BUILDPDB If you want to revert to the count-only report, use
TYPSID %LET MACKEEP= MACRO _RPDBID _RPDBIDO % ;
VMACID Variable SMFBYTES was added to the TYPEID dataset and is
Apr 24, 2010 the bytes variable in PDB.SMFRECNT summary dataset.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 28.088 MXG 28.01-28.02, z/OS 1.9 and 1.10, INPUT EXCEEDED ERROR.
VMACRMFV Change 28.048 inserted temp skip of +192 for z/OS 1.11 to
Apr 25, 2010 align, but should have been skipped only if CPUHOLEN=672;
earlier z/OS have CPUHOLEN=480. Now, SKIP=CPUHOLEN-480.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 28.087 -Cosmetic. Spurious message for STID=110 "SKIPPED FIELDS"
VMAC110 because SKIP=SKIP-580 should have been SKIP=SKIP-612. No
Apr 23, 2010 fields were skipped and dataset CICRLR was just fine.
-Use of internal SAS decompression code on z/OS instead of
the ASM code in the INFILE exit in member EXITCICS caused
CPU time to increase from .5 to 6 HOURS with 45 GB of SMF
records, so the "MXGNOTE" that the SAS code was used is
now elevated to a repeated "ERROR:" message under z/OS.
Under ASCII, a single note that compressed data was found
is printed. Change 27.260 documented a smaller increase!
Thanks to Joachim Sarkoschits, DATAEV eG, GERMANY.
Change 28.086 Support for Windows Performance Monitor PERFMON csv/tab
ADOCWPMO log file creates 123 new datasets, each named WPMOddd, to
EXWPMddd correspond with the DDDDDD=WPMddd token for each dataset.
IMACWPMO The DataSet Label is the Object Name, and member IMACWPMO
MAKEWPMO has the full list of DDDDDD, DATASET, and Object Name and
TYPEWPMO will be updated as new Objects are supported.
TYPSWPMO The PERFMON data files can be concatenated, and can have
VMACWPMO different sets of fields. The ADOCWPMO member documents
VMXGINIT how Glenn has set up his PERFMON data management.
May 22, 2010
With all possible objects were enabled, with all threads
and instances captured, on a Small Business Server, the
PERFMON descriptor record was 861,481 bytes long, way too
long to be read on z/OS with its 32760 maximum LRECL, so
MXG PERFMON support may require execution on ASCII, where
SAS V9.1.3 allows LRECL=1024000, and SAS V9.2, LRECL=4GB.
This design is also another significant MXG enhancement:
The new MXG code that you execute to process PERFMON data
was generated by MXG's MAKEWPMO program, which reads the
header record field descriptions, parses/translates them
to create open-systems-friendly, 32-byte variable names,
with underscore-connectors, builds variable labels from
those variable names, changing underscores to asterisks,
uses the Object Name for the Dataset Label, and writes
out the dozen text files that are then manually cut/paste
into VMACWPMO or the other MXG code members.
While still a two-step process, this automation makes it
easy for MXG to support new objects. MAKExxxx programs
have been used for some time to create chunks of MXG code
for product XXXX, but only for the static statements that
defined or referenced the XXXX product suffix, the DDDDDD
dataset suffix token, or that contained the DATASET name.
Programmatically creating variable names, labels, and the
INPUT code is a BIG step forward in minimizing MY effort
to support future "open systems" data or sources that
have similar data structures. Since these data don't
have a construct of a short field name, but only the long
description, using the descriptions as variable name does
make sense for this audience, and REALLY saves me TIME!!
Each "item" in the header description has this format:
"\\SERVER\OBJECT(INSTANCE)\METRIC"
and there can be tens of thousands of items. SERVER is
variable SERVER, the server name, OBJECT maps to the MXG
dataset, and the Object Name (PROCESS) is the Label of
the MXG Dataset Name (WPMOPRO), INSTANCE is the instance
(e.g., process EXPLORER.EXE), and each separate METRIC
item (e.g. HANDLE_COUNT) is a variable in the WPMOOBJ
dataset.
While ASCII's max LRECL is 4GB, records cannot be stored
in a character variable, with SAS's 32K limit, so the
record is brute-force read, byte-by-byte, and parsed for
the delimiters to create each "item".
Microsoft claims to create comma-delimited data, but a
single comma cannot be safely used to parse because
the "items" can contain embedded commas!
And, while each item is bounded by double quotes, the
double quote also cannot be used as a delimiter, as
"items" can also contain embedded double quotes!
So the MXG default "comma-separated-value" delimiter is
the three-character-string "," set in VMXGINIT with
%LET DLMWPMO='","';
If you have "tab-delimited" PERFMON files, then you
need to use %LET DLMWPMO='09'x; before your %INCLUDE.
Once an "item" is parsed, normal SAS character functions
are used to create the SERVER, OBJECT, INSTANCE and the
METRIC values, and output the WINPERFMON dataset that is
subsequently read to output all of the WPMOddd datasets.
If there are obs in OBJUNKNOWN or METUNKNOWN datasets,
please send the PERFMON file to support@mxg.com,
so MXG can be updated to support the new data.
Some characters in the descriptions have to be converted
because blanks, back-slashes, dashes, parens, periods,
pound-signs, etc., can't be used in SAS variable names;
underscores are used in the variable name to connect the
pieces.
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.085 Obscure. VMXGSUM is protected if you had parenthesis in
VMXGSUM the OUTDATA= argument (for a LABEL= or SORTEDBY=). If a
Apr 20, 2010 last data step wasn't needed, parens caused an even more
obscure ABEND. While now protected, using the DSNLABEL=
or SORTEDBY= argument in the VMXGSUM invocation is safer.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.084 BMC IMF product's INPUTCLS and LASTCLAS variables are now
VMACCIMS restored to one-byte length with $HEX2. format, and new
Apr 20, 2010 variables INPUTCL2 and LASTCLA2 are two-bytes with $HEX4.
While IMS 9.1 and later define Input Class as two bytes,
it appears that no one is using that length, and MXG's
changes (27.230,26.058) that expanded the length of those
original INPUTCLS/LASTCLAS variables caused existing
reports to be incorrect.
Thanks to Jim Dammeyer, State Farm Mutual Insurance, USA.
Thanks to Mike Stogsdill, State Farm Mutual Insurance, USA.
Change 28.083 MXG 28.02-03. READB2/ANALDB2R didn't honor %LET MACDB2H
ANALDB2R nor %LET MACKEEP tailoring: Change 28.055 added %CLEARDB2
READDB2 (to reset old-style macros for multiple executions, used
Apr 17, 2010 previously only in the MXG QA), but CLEARDB2 also clears
Apr 21, 2010 both MACDB2H and MACKEEP. The %CLEARDB2; statement was
Apr 22, 2010 removed from both members by this change.
Apr 24, 2010 Circumvention with 28.02: Create a member named CLEARDB2
Apr 25, 2010 in your "USERID.SOURCLIB" with a blank line.
Apr 26, 2010 No one has asked to execute READDB2/ANALDB2R twice,
Jun 17, 2010 but it can still be done, by invoking %CLEARDB2;
externally, between the multiple executions:
%READDB2 ( WHATEVER );
%LET MYKEEP=%BQUOTE(&MACKEEP);
%LET MYDB2H=%BQUOTE(&MACDB2H);
%CLEARDB2;
%LET MACKEEP=%BQUOTE(&MYKEEP);
%LET MACDB2H=%BQUOTE(&MACDB2H);
%READDB2 (WHATEVER DIFF);
-MXG 28.01-28.02 only. Short Trace report failed with
BY VARIABLES NOT SORTED ON DATASET WORK.REPORT; example
in Change 28.004 that revised that report DOES NOT FAIL,
but removing the CONNTYPE=4 selection exposes the missing
BY statement that was added by this change.
-Audit report corrections, all prior versions:
-The BIND code was inside the loop for DML (should not
have been).
-PMAUD02/PMAUD03 reports did not agree with doc; they
were only produced when you used the AUDIT= subparm,
but now, as documented, ALL possible Audit classes
will be reported with the default AUDIT=, value.
-SQL Text printed for 141 and 145x Audit records.
-Divide by ZERO when GETS=0 is now protected.
-Cosmetic: SUDIT now correctly spelled AUDIT.
MXGWARN that PDB.ASUMDB2x NOT FOUND have been removed.
ANALDB2R first looks for the ASUMDB2x dataset for a
report request, as that saves I/O and CPU time, but
warning that it wasn't found was confusing, especially
when you knew nothing about that internal design.
-Jun 17: MACDB2H was not honored until this date.
Thanks to Jim Kovarik, AEGON USA, USA.
Thanks to Stephen Root, Harry and David, USA.
Change 28.082 MXG Formats $MGDDDDD and $MGDDDSN map the "dddddd" token
FORMATS to each "dataset" and vice versa, but the UDDDDDD program
UDDDDDD missed some of the "dddddd" values, in particular, CICTRN
Apr 18, 2010 and DB2ACC, and not all datasets were identified, as that
old logic read selected source members for the _Wdddddd,
which doesn't exist for all datasets. Now, UDDDDDD reads
DOCVER to capture ALL dataset names, and labels for all
datasets now contain "DDDDDD:" in their dataset label.
UDDDDDD is also added to QASAS so those formats will be
updated with each new version; DOCVER is already heavily
validated in post-QA reports. These members were updated
to revise/add unique DDDDDD: to their dataset labels:
ANALVM ASUM94 ASUMCIMS ASUMDB2P ASUMDB2S ASUMMWUX
ASUMSTC ASUMTALO BUIL3001 BUILD001 BUILDPD3 BUILDPDB
DIFFROSC MNTHDB2S TRNDDB2A TRNDDB2B TRNDDB2G TRNDDB2P
TRNDDB2S TRNDDB2X TRNDSTC TYPEPDL TYPEVLFC TYPEZARA
VMAC0 VMAC110 VMAC21 VMAC30 VMAC84 VMACCIMS
VMACCRAy VMACMWUX VMACNMON VMACVMON VMACVMXA VMXGCICI
VMXGDBSS VMXGHSM VMXGRMFI
Thanks to Francine Gheyle, Dexia Bank, BELGIUM.
====== Changes thru 28.081 were in MXG 28.02 dated Apr 14, 2010========
Change 28.081B PRO/SMF dataset PRORECOV was misaligned after the INPUT
VMXGINIT of variable GWMSGED.
Apr 14, 2010
Change 28.081A PRO/SMF dataset PRORECOV was misaligned after the INPUT
VMACPROS of variable GWMSGED.
Apr 14, 2010
Thanks to Perry Lim, Union Bank, USA.
Change 28.081 OPTIONS VARLENCHK=NOWARN is reinstated in VMXGINIT if the
VMXGINIT SAS Version is 9.2 TS2M0 or later to eliminate the new
Apr 12, 2010 WARNING: MULTIPLE LENGTHS WERE SPECIFIED FOR THE VARIABLE
that is discussed MANY times in several NEWSLTRS. While
MXG 26.03 eliminated the warning in internal code,
user code is now protected, and future changes in lengths
of IBM fields (e.g., CLIPADDR increased from 16 to 40 to
support IPV6) will not produce that WARNING, nor a Return
Condition Code of 4. (One cause of the warning is the
use of PROC MEANS to create an output dataset without the
option /INHERIT at the end of its OUTPUT statement.)
Thanks to John Kim, ATCO I-tek, CANADA.
Change 28.080 z/OS 1.11 adds new variable to TYPE70 dataset
VMAC7072 SMF70GAU='CAPACITY GROUP AVAILABLE MSU
Apr 12, 2010 which is documented as
-Long-term average of CPU service in millions of
service units which would be allowed by the limit of
the capacity group but is not used by its members.
-If the value is negative, the group is capped.
So, this variable is input with &IB.4. since in this rare
case, a negative value is not only possible, it is now
very useful as an indication that the Capacity Group is
Capped.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.079A This change WAS included in MXG 28.02, but this text was
VMXGINIT not: the test for NOWORKINIT was removed in MXG 28.02.
Apr 14, 2010 Change 28.023 added that test and a USER ABEND 990 if
OPTION NOWORKINIT was enabled, but my cure was worse
than the disease. There IS a serious exposure in MXG
if NOWORKINIT is enabled, but I know now it is ONLY in
a second MXG step, and only after a first-step error,
and the real exposure is only MY time in diagnosing!.
Some SAS sites have now ABENDed (unnecessarily) because
that option is enabled in their SAS tailoring, and WPS
set NOWORKINIT as default (when WORK was temporary and
did not need to be INIT, and their INIT process was
inefficient, but their INIT is improved and WORKINIT is
to be the default in their next GA), and now that I
know that NOWORKINIT, of itself, does not create a
problem for MXG code, my test and USER ABEND 990 were
removed in MXG 28.02.
Change 28.079 MXG 27.11-28.01, ONLY with the MXGTMNT Tape Monitor data:
VMACTMNT SAS has had a limit on the length of an observation of
Apr 12, 2010 32760 bytes, which prevents the Host Sort from being used
if exceeded, with this SAS Warning printed on the log:
The total length of all variables must be less than or
equal to 32760 bytes. The host sort cannot be used.
The internal SAS sort will be used; this may impact
performance. Adjacent to TYPESYSL dataset references.
(An increase in CPU time of about 37% was observed.)
Change 27.336 increased the length of variable SYSLTEXT,
the SYSLOG Message Text, from 1024 to 32384, but that was
needed/intended ONLY for the TYPESYSL dataset (which can
OPTIONALLY capture any SYSLOG message); that length is
for the largest possible multi-line SYSLOG message. BUT:
variable SYSLTEXT was also accidentally increased in the
TYPESYMT dataset, used ONLY for Tape-Mount-Event-Related
SYSLOG messages, needing a SYSLTEXT length of only $256.
Even worse, new variable SYSLENCR, to identify Encrypted
Tapes, was created as SYSLENCR=SUBSTR(SYSLTEXT,x,16), but
because I failed to put the new variable in a LENGTH $16
statement, it got the 32384 byte length of SYSLTEXT. So
with SYSLTEXT and SYSLENCR, TYPESYMT had an observation
length of 65183, causing the preceding WARNING message.
This change restores the length of SYSLTEXT to $256, and
the TYPESYSL dataset's variable is now named SYSLLONG.
Note that the SPINSYSL dataset created with 27.11-28.01
by the %INCLUDE SOURCLIB(ASUMTAPE); that should always be
used to create the PDB.ASUMTAPE Tape Mount Event dataset
also exceeded 32760, with observation length 65198, but
it is not sorted, and its observation length is corrected
when this change is implemented.
Thanks to Siegfried Trantes, Gothaer-Systems, GERMANY.
Thanks to Richard Sabine, Gothaer-Systems, GERMANY.
Thanks to Willi Weinberger, Gothaer-Systems, GERMANY.
Change 28.078 VMXGGETM reports SMF record counts and bytes by SUBTYPE
VMXGGETM and ID, but DB2 100 and 101 records subtypes were changed
VMACSMF to their IFCID; now their actual SMF SUBTYPE is printed.
Apr 11, 2010 (For the DB2 102 record, which does NOT have a SUBTYPE in
the SMF Header, the IFCID is still used for SUBTYPE.)
-The setting of SUBTYPE logic was removed to VMACSMF.
Thanks to Tom White, Dell, USA.
Change 28.077 Support for JES 3 JMF TYPE84 records; previously only the
VMAC84 header was supported for subtype 5; this update supports
Apr 10, 2010 all ten subtypes.
Change 28.076 Variable CECSER is now added to PDB.RMFINTRV, but this
VMXGRMFI change was NOT moved into MXG 28.02.
Apr 18, 2010
Change 28.075 IBM's John Burg presentation at 2010 Seattle SHARE in
VMAC113 session 2113 provided insight into the new TYPE113 HIS
Apr 9, 2010 monitor data, and these new variables are created:
CPI='CYCLES*PER*INSTRUCTION'
PRBSTATE='PERCENT*PROBLEM*STATE'
L1MP='LEVEL*1*MISS*PERCENT'
L15P='PERCENT*SOURCED*FROM*L1.5*CACHE'
L2LP='PERCENT*SOURCED*FROM*L2*SAME BOOK'
L2RP='PERCENT*SOURCED*FROM*L2*DIFFEERNT*BOOK'
MEMP='PERCENT*SOURCED*FROM*MEMORY'
LPARCPU='APPL*PERCENT*CAPTURED AND*UNCAPTURED'
-John's presentation is also available at Techdocs:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TC000041
-Using %INCLUDE SOURCLIB(TYPE113); _RPT113 ; RUN;
will replicate his example report.
-Variable SM1132CP, CPU Speed, was INPUT but not carried
into the TYPE113 dataset.
-A subsequent update will look for PDB.TYPE70 dataset, and
will use it to identify the type of each CPU in TYPE113.
Thanks to John Burg, IBM, USA.
Thanks to Graham Harris, Royal Bank of Scotland, SCOTLAND.
Change 28.074 Support for CA-Dispatch Audit User SMF record creates:
EXCADISP dddddd dataset description
IMACCADS CADISP CADISPCH CA Dispatch User SMF Record.
TYPECADS Note this is NOT the modified type 6 that can be created
TYPSCADS with the IMACCADI optional member enabled.
VMACCADS
VMXGINIT
Apr 14, 2010
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.073 In new DB2 V9.1 data records, QWHSISEQ in SMF 100 Subtype
VMACDB2 0 and 1 records no longer matches QWHSISEQ in Subtype 4
Apr 8, 2010 records, causing all of the QW0225xx variables to have a
missing value in PDB.DB2STATS when DB2STAT4 is merged.
The use of QWHSISEQ was previously "safe", but must have
been a fortunate accident, since IBM documentation for
ISEQ implies it is a sequence number for the IFCID, and
not, as I had assumed, the interval's sequence number.
This change creates TEMPISEQ dataset with QWHSISEQ taken
from the DB2STAT0/DB2STAT1/DB2STATB merge, renames the
ENDTIME to QWHSSTCK, so that TEMPISEQ is then interleaved
with DB2STAT4 to store that "interval" QWHSISEQ, which
is then used in the original merge using _BDB2STS.
(Since the problem has only occurred with DB2STAT4 and
not with the T102S225 that was created in DB2 V8., that
logic was not revised).
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 28.072 Dataset TYPE42X4 (Above the Bar LRU Statistics) variables
VMAC42 SMFA2JQG-SMFA2JQN (Buffer Size Goal and Buffer Sizes) are
Apr 8, 2010 now correctly INPUT as &PIB.8., instead of &PIB.4. This
caused variables SMFJQO01-SMFJQO16, SMFA2JSA-SMFA2JSP to
also be mis-aligned and wrong, and the IF test for 864 is
corrected to test for GE 896 due to the misalignment.
-In addition, new variables SMF42JP6 and SMFA2JP6 (Write
Requests) are INPUT and kept in datasets TYPE42X2 (Below)
and TYPE42X4 (Above) as they too had been overlooked.
-Note that MXG variable names SMFA2xxx correspond to IBM
field names of SMF2Axxx.
Thanks to Ambat Ravi Nair, CitiGroup, SINGAPORE.
Change 28.071 PDB.STEPS could contain duplicate observations, and the
BUILD005 resources in those duplicates were summed into PDB.JOBS,
BUIL3005 if two steps had the same TERMTIME (because the first was
ANAL30DD a FLUSHED step). Change 18.344 corrected this error in
Apr 7, 2010 TYPS30, by adding INITTIME to the _BTY30U4 BY list, but
that change was also needed in BUILD001/BUILD001, which
have their own BY list in the NODUP step.
All other programs that SORT the TYPE30_4 data were now
examined; ANAL30DD's BY list was updated, but it was the
only one that sorts all variables; these other programs
currently do NOT protect for duplicate SMF records
ANAL30 ANALDDCN ANALDSET ANALJOBE ANALMULT ANALVTS
TAPEVENT UTILRMFI
because they do not keep all of the variables that are
required for duplicate removal, and adding that logic
would be very expensive: unneeded variables and an extra
PROC SORT would be required and the report program would
have to be restructured. Since the TYPS30 program WILL
remove ANY duplicates, the solution would be to use it to
create the TYPE30xx datasets first, and then those report
programs will not need revisions.
Thanks to Michael Oujesky, Bank of America, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 28.070 SAS Version 9.2 TS2M2 may have changed DSNAMEs/MEMBERs in
MXGSAS92 their //CONFIG DD. As always, you MUST look at the SAS
Apr 2, 2010 JCL procedure example that was created by your SAS
Installer to know what DSNAME/MEMBERs were created; those
DDs must be the first in the //CONFIG DD, then the MXG
CONFIG member must be the last "real" DD, followed by the
// DD DSN=&CONFIG as the final DD in the //CONFIG concat.
These two variants are listed in the MXGSAS92 example.
//CONFIG DD DISP=SHR,DSN=&SASHLQ..V92DYJJJ.CNTL(BATCH)
// DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9)
// DD DISP=SHR,DSN=&CONFIG
//CONFIG DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(BATCH)
// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(COMMON)
// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(&XX.&YY.)
// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(SITE)
// DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9)
// DD DISP=SHR,DSN=&CONFIG
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 28.069 Two instances of -60 were changed to -56 for the SMF 112,
EXIT112 but the exit to decompress SMF 112s does not work and can
Apr 1, 2010 not be used. IBM does not provide a utility program that
May 17, 2010 will decompress the SMF 112s (DFH$MOLS only reads 110s),
so I have no way to correct and validate the MXG Exit.
DO NOT USE EXIT112.
Change 28.068 Change 27.111 added support for multiple CA-1/TMS catalog
TYPETMS5 inputs, but inadvertently changed the length of VOLSER to
Apr 1, 2010 $20, whereas it should have been $6. There was no error
in the contents of variable VOLSER, but if you tried to
combine new and old datasets, you receive a SAS WARNING
of the dissimilar lengths. This change restores VOLSER
to the original $6 length.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 28.067 The final example invocation of %VMXGRMFI(....) failed
RMFINTRV because there was a comma prior to the close-paren. All
Apr 1, 2010 %MACRO invocations have commas separating arguments,
but there can not be a comma after the last argument.
Thanks to Carolyn E. Saul, West Virginia Office of Technology, USA.
Change 28.066 Support for IMS Version 11 (INCOMPATIBLE), support for
ASMIMSL6 55x/56x Statistics Log Records, validation of 45x log
TYPEIMS7 records, and TYPSIMS7 removes duplicate log records.
TYPSIMS7 -Insertion of 16-byte LINTUTKN field in 08x log record
VMACIMS in IMS 11 makes this change required to eliminate error
VMACIMSA that YYYY has invalid value, in VMACIMS and VMACIMSA.
VMXGINIT -ASMIMSL6 is updated to pass the 55x and 56x log records.
Apr 4, 2010 -45x Statistics records have been validated with data,
except for IMS4513 which had zero observations.
-55x and 56x records are now supported and validated; the
"56" names contain "55x" and "56x" records:
DDDDDD DATASET CREATED FROM SUB-SUBTYPE
IMS560 IMS5600 00x-08x,10x,12x-14x,37x-38x
IMS569 IMS5609 09x
IMS56B IMS5611 11x,16x
IMS56F IMS5615 15x
IMS56G IMS56FA FAx
-The 45x and 55/56x datasets are left in //WORK so you can
decide to copy them, or not.
-TYPSIMS7 now uses PROC SORT NODUP to remove duplicates,
and outputs ALL datasets to the //IMSTRAN DD name.
This required creation of variable IMSRECCH $CHAR8. to
contain the IMS Logical Sequence Number as character to
use in NODUP sorts. IMSRECNO was input with PIB8., but
it failed in NODUP sorts, because values were truncated
if the first byte was non-zero. IBM stores a value of
'F1'x in the 1st byte for the 1st merged file, a 'F2'x
for the 2nd merged file, etc., but when a numeric field
is INPUT with PIB8, if the field contains a non-zero
first byte, the result is truncated because SAS needs
one byte for exponent, leaving only 7 bytes for
mantissa, which caused duplicate values for IMSRECNO,
which caused the NODUP to fail to recognize true
duplicates. Now, the 8-byte Character variable
IMSRECCH is used in all BY-lists to successfully remove
duplicates and the numeric IMSRECNO is now input from
only the last seven bytes, with PIB7.
-35x record has undocumented bits in QLNQFLGS/ENQFLAG.
IMS 11 DSECT only document '10'x,'02'x,' 01'x bits,
but data contains '80'x,'40'x,'08'x,and '04'x bits on.
QLNQFLGS values '0C'x,'4C'x,'8C'x,'8E'x, and '9C'x bits.
-01x record now conditionally inputs Extended Segment,
eliminating missing value messages.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Thanks to Lars Fleischer, SMT Data A/S, DENMARK.
Change 28.065 Support for BMC CICS CMRDETL C660 for CICS/TS 4.1 adds
VMACMVCI these new variables COMPATIBLY:
Mar 30, 2010 T6E66XCT T6EATMSN T6EBFDGC T6EBFTC T6EECEVC T6EECFOC
T6EECSGE T6EEICTC T6EIPA T6EJSTWC T6EJSTWT T6EMLCTC
T6EMLCTT T6EMLTDL T6EMLXTC T6EMQASC T6EMQAST T6EOIPA
T6EPIPLN T6ET8PTC T6ET8PTT T6ETIATC T6ETITC T6ETTDLC
T6ETTDLT T6EURIMN T6EWPBNM T6EWSATC T6EWSCBC T6EWSCGC
T6EWSEPC T6EWSFCC T6EWSFTC T6EWSOPN T6EWSQBL T6EWSRBL
T6EWSSFC T6EWSVCN TESTC660 UDAT2
Change 28.064 A semicolon was missing at the end of the statement
JCLIMSL6 %LET MACKEEP= MACRO _IMSVERS 10 % ;
Mar 26, 2010 causing the job to stop after MXG initialization.
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND
Thanks to Brian Sanger, Zurich Insurance Company, SWITZERLAND
Change 28.063 ASUM70LP and ASUMCELP had IFLACTTM,PCTIFLBY missing if
VMXG70PR the IFL was Dedicated, LCPUDED='Y' because ORIGWAIT was
Mar 25, 2010 subtracted from LCPUPDTM even when ORIGWAIT was missing.
Now, MAX(ORIGWAIT,0) is subtracted.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.062 NetSPY percentage calculations use TOTRSPNO or NETSRPNO
VMACNSPY in the denominator, based on the '.1.....'B XDOMAIN value
Mar 25, 2010 for Host-Only or Not, respectively. New TARGRESP variable
is now set by that XDOMAIN value to make it clearer which
denominator was used for the TnRSPPC calculations.
Thanks to Charles Savikas, DFS State of Florida, USA.
Change 28.061 MXG changes the TMS variable BLKCNT to a missing value,
VMACTMS5 when it detects an invalid BLKCNT value. Previously, the
Mar 25, 2010 BLKCNT value was output as 4,294,967,xxx decimal, because
the value in the TMS record was 'FFFFFFFC'x, which MXG
INPUT with PIB4. INFORMAT, because Block Count must be a
positive value, and I feel leaving that large value means
it can't be easily overlooked as an error. For a field
that can be positive or negative, then the first bit is
a sign bit, and the above, when INPUT with IB instead PIB
is a decimal -4, still a clearly wrong negative value.
The TMS Report prints a +4 for BLKCNT for that value!
And, from TMS Support, they confirm that:
- There is no logic in TMS-Reporting, but if the
high-orderbit is on, they interpret the negative
value as a positive number in their print routine.
- The record seems to be wrong, they had some few
similar cases in the past
In fairness to TMS, I don't think these large BLKCNT
values are their fault; I think they just pick up that
counter and output it. Occasionally, fields with values
'FFFF...'X have shown up in SMF I/O fields like EXCP
BLOCK, SIO, etc. whose counters are in the address space.
They result from the subtraction of a counter with a
larger value from a counter with a smaller value, and
thus ultimately are the result of a programming error
deep in whatever system-level code used the wrong
internal counters. Some of these errors have been
tracked down, and fixed, but it can take significant
effort, multiple vendors, and even SLIP traps.
And many of these "bad" values can be traced back to an
ABEND in the address space that overwrote one or both of
the subtraction input counters!
-So I've changed the input for BLKCNT so the value is set
to a missing value instead of that large value when the
first byte is an 'FF'x. This way, you can use
PROC MEANS N NMISS DATA=TMS.DSNBRECD;
to count the number of DSNs with invalid BLKCNT values.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 28.060 Change 27.289 added CPUZIPTM for SYNCSORT that was added
VMACSYNC in an existing reserved area, but SYNCSORT 1.2 did not
Mar 24, 2010 have that expected reserved area, causing MXG to ERROR:
INPUT EXCEEDED RECORD LENGTH. CPUZIPTM is now INPUT
conditionally when the reserved area exists. Note that
the current SYNCSORT version is 1.3; they renumbered.
Thanks to David Bixler, FISERV, USA.
Change 28.059 -RMF III variable ASIASSTA (ADDITIONAL*SRB*TIME) is now
VMACRMFV correctly divided by 1000 in its INFORMAT.
Mar 24, 2010
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 28.058 AS400 Version 5.4.0 creates invalid records that do not
VMACQACS contain the "Century" value and a 2-byte POOL Number that
Mar 24, 2010 caused MXG to be misaligned, and all values were wrong!
The missing Century value is now forced for 5.4.0 records
so that dates and values are correct in QAPMPOLB dataset.
Thanks to Karen Florup, Bank of America, USA.
Change 28.057 MXG 28.01, SAS V8.2 ONLY: ERROR: MACRO KEYWORD ABORT IS
VMXGINIT NOT YET IMPLEMENTED. Change 28.023 added %ABORT statement
Mar 22, 2010 for obscure NOWORKINIT detection, but we no longer QA MXG
under SAS V8.2 so the omission was missed. This change
replaced %ABORT with a DATA STEP for sites still stuck in
that ancient and archaic version of SAS.
See Change 28.079A, which removed NOWORKINIT detection.
Note: This MACRO KEYWORD error also caused FORMATS to
error with ' 22 ' under the OTHER= argument, but the
VMXGINIT correction eliminated that spurious error.
Note: As a reminder, MXG does not fully support V8;
there are other errors that require SAS V9, but this
is not one of them.
Thanks to Teuvo Virsu, Tieto, FINLAND.
Change 28.056 Format MG099TC for variable S99TCOD had spelling errors:
FORMATS Action Code 3560: Change REV to REC.
Mar 22, 2010 Action Code 8975: Change NO to NA.
Thanks to Dick Arnold, Commerce Bank, USA.
Change 28.055 Using PDB=GTF to read DB2 GTF data did not always work.
ANALDB2R Multiple includes of VMACDB2 and VMAC102 could occur,
READDB2 the logic of which records were to be read was not always
Mar 22, 2010 correct, an unneeded data step was eliminated, and the
old-style macros are cleared with %CLEARDB2 so that you
can execute ANALDB2R multiple times (which also protects
PDB=SMF and PDB=PDB).
Apr 17: See Change 28.083. CLEARDB2 REMOVED.
Thanks to Tony Curry, BMC, USA.
Change 28.054 Variables TSQIOSTM and TSQIOWTM in CICSRDQU dataset from
VMAC110 Resource Class SMF 110 SUBTYPE=1 MNSEGCL=5 records were
Mar 20, 2010 wrong, and the count portion of those two "clocks" is now
input into new variables TSQIOSCN and TSQIOWCN.
Thanks to Danny Sun, IBM Global Services, AUSTRALIA.
Thanks to Tony Delmenico, IBM Global Services, AUSTRALIA.
Change 28.053 Executing TYPEQACS on ASCII caused OPTION JFCB UNKNOWN.
VMXGDSNL The VMXGDSNL macro is revised so that
Mar 19, 2010 - It works without referencing a JFCB
- Works on ASCII to find the part of the dataset between
the . and the / or the \.
- Continues to function as before to capture the
penultimate token of a GDG DSNAME.
Thanks to Paul Naddeo, FISERV, USA.
Change 28.052 Cosmetic. Fourteen misspellings of CONTENTION corrected.
VMAC42
Mar 16, 2010
Thanks to Miguel A. Fernandez, CitiGroup, USA.
Change 28.051 DB2 APAR PK62161 adds four important SQL counters that
VMACDB2 are output in DB2ACCT, DB2ACCTP, and DB2STATS:
Mar 16, 2010 QXRWSFET='ROWS*FETCHED'
QXRWSINS='ROWS*INSERTED'
QXRWSUPD='ROWS*UPDATED'
QXRWSDEL='ROWS*DELETED'
The APAR adds the fields to both DB2 V8 and DB2 V9.
Thanks to Terry L. Berman, DST Systems, USA.
Change 28.050 Documentation. If you want to reset the value of the
VMXGINIT OPTIONS USER=xxx;, then you MUST reinvoke VMXGINIT after
Mar 16, 2010 setting your desired LIBNAME:
OPTIONS USER=MYPDB;
%VMXGINIT;
%INCLUDE SOURCLIB(TYPEDB2,ASUMDB2A);
Thanks to Lars Fleischer, SMT Data, SWEDEN.
Change 28.049 -If you APPEND PDB datasets, you may receive warnings that
FIXTRNCD the old dataset did not have TRANSCODE attribute set.
Mar 16, 2010 These warnings are only cosmetic, and will go away when
Apr 29, 2010 you reset the MTD or WTD dataset with only the new MXG.
But, those warnings can be eliminated with the attached
FIXTRNCD program which adds the TRANSCODE=NO attribute to
all $HEX-formatted CHAR variables in the OLD MDT/WTD.
-MXG 28.01/28.02. Original FIXTRNCD program did not work.
Revised and tested Apr 29, 2010.
Thanks to Jan Hess, USAirways, USA.
Thanks to Doug Medland, IBM Global Services, USA.
Change 28.048 RMFV CPUG3 record has +192 bytes in z/OS 1.11.
VMACRMFV Temporary skip realigns data.
Mar 15, 2010
Thanks to Miguel Barrios, SSA, USA.
====== Changes thru 28.047 were in MXG 28.01 dated Mar 9, 2010========
Change Numbers with an asterisk are still OPEN, their text may change,
and the listed members might not have been updated yet in this release.
Contact support@mxg.com for current status of those changes.
Change 28.047 User defined CICS segment supported. Names similar to
IMACICUJ the expected names for IMACICDL caused this particular
UTILEXCL user segment to not be recognized, causing ERRORs when
Mar 9, 2010 SMF data was processed.
Thanks to Paul Baquet, Duke University, USA.
Change 28.046 Documentation. The summarization INTERVAL= request must
ASUM70PR be GREATER THAN OR EQUAL TO the RMF interval duration.
Mar 9, 2010 The default ASUM70PR has INTERVAL=QTRHOUR, but if that is
used with data that was created HOURLY, the output
ASUM70PR dataset(s) can have PCTCPUBY,PCTLnBY, etc.
percentages greater than 100, and there's nothing I can
do to correct those values with the incorrect INTERVAL=.
Change 28.045 The TIMEBILD table was arbitrarily limited to 99 entries;
TIMEBILD keeping ancient systems in the table caused an error when
Mar 8, 2010 the limit was exceeded; the limit is increased to 999.
Thanks to Betty Wong, Bank of America, USA.
Thanks to Michael Oujesky, Bank of America, USA.
Change 28.044 WPS failed with a compiler error in VGETOBS, reported as
VGETOBS UNRESOLVED MACRO %TRIM, but the error, documented in WPS
Mar 6, 2010 item 8385, was not in %TRIM, but was in the parsing of a
Mar 8, 2010 %VGETOBS value that had a plus sign (e.g. 1234e+56). WPS
maintenance 14690 corrected the compiler error, but now
we understand the code syntax that exposes the problem,
by adding %QUOTE() function around the %VGETOBS text, the
exposure is circumvented, without installing WPS 14690.
(First attempt using %STR() around %VGETOBS failed;
%STR is evaluated at compile time, %QUOTE is evaluated
at execute time, which is required here. Two other
%STR were changed to %QUOTE just for consistency.)
(Second attempt did not correctly parse a period that
was returned when the SAS Data Library was in XPORT
format.)
(Third attempt used %INDEX to solve the problem.)
Thanks to Atle Mjelde, ErgoGroup, NORWAY.
Change 28.043 zTPF has major revisions in Performance Data, with many
EXTPFCC old variables removed and new record types; while the new
EXTPFCF support is in new members TYPEZTPF/TYPSZTPF/VMACZTPF and
EXTPFCL not an updated TYPETPF, old DATASET and VARIABLE names
EXTPFCW that exist are unchanged, and TPF is still the prefix for
EXTPFCY the new dataset names.
EXTPFCZ Status
EXTPFGL TPFID DSECT DATA RECORD DATA IN DATA RECORD
EXTPFHP CC NO YES NO
EXTPFMT CF YES YES NO
EXTPFMT CL YES YES NO
EXTPFSF CW COMPLETED
EXTPFSI CY NO YES NO
EXTPFTH CZ NO YES NO
EXTPFUC GL YES YES NO
EXTPFVC HP YES YES NO
EXTPFVF MT COMPLETED
TYPEZTPF MU NO NO NO
VMACZTPF SF NO YES YES
VMXGZTPF SI COMPLETED
Mar 5, 2010 TH NO YES NO
Mar 30, 2010 UC YES YES NO
Apr 5, 2010 VC NO NO NO
VF NO YES YES
Thanks to Bob Wilcox, HP, USA.
Change 28.042 New Sentry VM 3.1.4.3 adds new objects and metrics:
EXNTAPOW dddddd Dataset Name Object
EXNTEVFS
EXNTEVFW NTAPOW APOOLWAS APP_POOL_WAS
EXNTHSRQ NTEVFS EVTRACWS EVENT TRACING FOR WINDOWS SESS
EXNTHSUG NTEVFW EVTRACWI EVENT TRACING FOR WINDOWS
EXNTIPDP NTHSRQ HTTPSRQU HTTP SERVICE REQUEST QUEUES
EXNTIPDR NTHSUG HTTPSUGR HTTP SERVICE URL GROUPS
EXNTIPGL NTIPDP IPSECDOS IPSEC DOS PROTECTION
EXNTPPAC NTIPDR IPSECDRI IPSEC DRIVER
EXNTPPIC NTIPGL IPHTTPSG IPHTTPS GLOBAL
EXNTPRIN NTPPAC PPNETACC PER PROCESSOR NETWORK ACTIVITY
EXNTSYNC NTPPIC PPNETINC PER PROCESSOR NETWORK INTERFAC
EXNTTECL NTPRIN PROCINFO PROCESSOR INFORMATION
EXNTTECL NTSYNC SYNCHRON SYNCHRONIZATION
EXNTTESE NTTECL TERECLIE TEREDO CLIENT
EXNTVWGA NTTECL TERERELY TEREDO RELAY
EXNTVWHA NTTESE TERESERV TEREDO SERVER
EXNTWFP NTVWGA VMGUESTA VMWARE.GUEST.AGGREGATE
EXNTWFPV6 NTVWHA VMHOSTAG VMWARE.HOST.AGGREGATE
EXNTWPFV4 NTWFP WFP WFP
EXNTWSMAN NTWFPV6 WFPTV6 WFPV6
IMACNTSM NTWPFV4 WFPV4 WFPV4
VMACNTSM NTWSMAN WSMANQUS WSMAN QUOTA STATISTICS
Mar 7, 2010
Change 28.041 Do NOT use ASMTAPEE ML-45/46; it caused CPU spikes in the
ASMTAPEE in the MXGTMNT address space (minutes vs fractions of a
Mar 9, 2010 second) that are now corrected by this new ML-47 release.
ML-45 was in MXG 27.10, ML-46 was in MXG 27.11/MXG 27.27.
Just in case, member ASMTAP44 contains ML-44.
Change 28.040 This original change text was wrong and replaced in 2011.
VMACTMS5 The new TMS Extended Format TMC did NOT change ANY size
Mar 5, 2010 of the TMC 340 byte records. The new Extended Format is
Dec 7, 2011 COMPLETELY COMPATIBLE WITH ALL VERSIONS OF MXG SOFTWARE.
See Change 29.274.
Change 28.039 -Dataset TYPE74CA variable R7451RID, the Rank ID, is input
VMAC74 from two bytes, but that produced values in the thousands
Mar 5, 2010 while the values in R748ARID and R748RRID in TYPE748A and
TYPE748R have values up to only 15. The observed values
in the first byte of R7451RID are between 1 and 15, and
and the second byte is 1 or 2, so (guessing), R7451RID is
now input from only the first byte and new R7451RI2 has
the value in the second byte, perhaps the Rank Group.
IBM RMF support observed the same values, but they only
get the two bytes from the interface.
-The Raid Rank segment has fields overlaid that populated
multiple variables, but variable R7451FLG is now used to
set missing values for the variables that don't exist.
This table identifies which R7451xxx variables have value
for each value of R7451FLG, which should be used to group
these three different sets of metrics in TYPE74CA.
R7451FLG
0=No Information, 1=Raid Rank Data, 2=Extent Pool Data
0 1 2
RID XID
HDD HDD XTY
RTY XFL
HSS
RRQ RRQ PRO
WRQ WRQ PWO
SR SR PBR
SW SW PBW
RRT RRT PRT
WRT WRT PWT
-Documentation. The three type 74 subtype 5 LSA Segments
(LO,RO,VO) added in OS/390 Release 2.10 in Change 18.134
were removed by IBM in z/OS 1.1, so these variables will
always be a missing value:
R745DCIR R745LFRE R745LKBF R745LKBR R745RBYF R745RBYS
R745RRID R745VBYW R745VFLG R745VNTR R745VNUM R745VSER
Thanks to Deb Soricelli, CIGNA, USA.
Change 28.038 SMF 120 SUBTYPE 9 caused INPUT STATEMENT EXCEEDED RECORD
VMAC120 because MXG thought variable SM1209ES was 128 bytes long,
Mar 3, 2010 when it should have been INPUT as 64 bytes long.
Thanks to Clayton Buck, UniGroup, USA.
Change 28.037 PDB.SMFINTRV will have EXCP/IOTM counts for FLUSHED steps
BUILD005 that have ZERO elapsed time (for example, steps bypassed
BUIL3005 execution due to JCL Condition Code Tests) if this causes
BUIL3005 the flushed step and the NEXT step to have identical time
Mar 3, 2010 in INITTIME and INTBTIME (step init, interval begin, to
.01 second resolution). Those NEXT step EXCPs/IOTMs were
incorrectly output in that FLUSHED step observation, and
the NEXT step observation had zero EXCP/IOTM counts.
The PDB.STEPS and PDB.JOBS datasets were correct, because
they don't use interval data.
And, in PDB.SMFINTRV, since those EXCPs were valid, but
just in the wrong step, both the JOB and INTERVAL totals
were always just fine.
-Adding INTETIME, the interval end time, in the BY lists
in SORTS and MERGES and KEEP= and in FIRST. and LAST. in
the MULTIDD algorithm corrects the error; it's now clear
they were always required for uniqueness.
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 28.036 -TYPE1032 from SMF 103 subtype 2 did not deaccumulate
VMAC103 correctly if PORTNR was not unique; variable JOB was
Mar 2, 2010 added to the BY list for uniqueness to correct.
-"SINCE*STARTUP" removed from label of variable TIMEOUTS,
as it is now the interval value, after deaccumulation.
Thanks to Matthew Chappell, Queensland Dept of Transport, AUSTRALIA.
Change 28.035 Cosmetic, a numeric to character conversion note was
VMXG2DTE eliminated.
Feb 28, 2010
Change 28.034 The references to %TRIM() function are not required, and
VGETOBS their removal may avoid UNRESOLVED MACRO TRIM errors.
Feb 28, 2010
Change 28.033 Incorrect MXG test for SEGLEN=220 for XAMSYS records in
VMACXAM the SUBSUM segment caused alignment ERRORS on the log.
Feb 28, 2010 Correct tests are for 224 and 228.
Thanks to Frank Bereznay, IBM Global Services, USA.
Thanks to Raff Rushton, IBM Global Services, USA.
Change 28.032 -IBM/CANDLE/OMEGAMON optional CMRDATA segment (IMACICMR)
IMACICMR was increased to 256 bytes in CICS/TS 3.2 (SMFPSRVR=65),
UTILEXCL and MXG tests that CICS version in IMACICMR, but records
Feb 27, 2010 from CICS/TS 3.2 with the old 200-byte length are still
created (presumably, the OMEGAMON exit for that segment
was not reassembled with CICS/TS 3.2 macros). While the
segment length of an optional CICS segment is not in the
CICSTRAN SMF record, if the MR segment happens to be the
LAST segment, this change invokes the old short-record
INPUT when less than 256 bytes are left and it's 3.2.
If the CMRDATA segment is not the last segment, the short
segment ultimately (hopefully) causes some sort of ERROR
(in this case, INVALID TASKNR DETECTED with a VERY large
value, due to the misalignment of the short record).
-While I can't tell segment length when creating CICSTRAN,
UTILEXCL will now detect the short CMRDATA segment under
CICS/TS 3.2 and print error messages on its log.
Thanks to Atle Mjelde, ERGO Group, NORWAY.
Change 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71, but I
VMAC30 had not re-examined the final SMF manual. Now added:
VMAC71 Dataset TYPE71:
Feb 25, 2010 SMF711RN='FIRST*REFERENCE*FAULTS'
SMF71FBN='FRAMES*BACKED*DURING*GETMAINS'
SMF71FFN='FRAMES*REQUESTED*TO BE FIXED*BELOW 2GB'
SMF71FRN='FIX*REQUESTS*BELOW*2GB'
SMF71GRN='GETMAIN*REQUESTS*ISSUED'
SMF71NRN='NON-FIRST*REFERENCE*FAULTS'
Datasets TYPE30_4,TYPE30_5,SMFINTRV,TYPE30_6:
SMF30HSH='HWM*USABLE BYTES*IN 64-BIT*SHARED'
SMF30HSO='BYTES IN*64-BIT*SHARED*STORAGE'
SMF30HVA='HWM*AUX*SLOTS*BACK*64-BIT'
SMF30HVH='HWM*USABLE BYTES*IN 64-BIT*OBTAINED'
SMF30HVO='BYTES IN*64-BIT*STORAGE*OBTAINED'
SMF30HVR='HWM*REAL*FRAMES*BACK*64-BIT'
Thanks to Don Deese, CPExpert, Computer Management Sciences, USA.
Change 28.030 Support for IMS Log 55x Statistics records, may not
VMACIMS have been tested with actual records.
Feb 24, 2010
Change 28.029 RMM datetime vars have always been wrong time zone. MXG
VMACEDGR assumed that the existence of a GMTOFF value in a Header
Feb 24, 2010 record extracted by EDGHSKP meant that the values in the
Mar 5, 2010 records were on GMT, so MXG added the GMTOFF, intending
Mar 8, 2010 to convert to local, but that incorrectly converted times
back to GMT time zone values. IBM rmm support confirms
that, since z/OS 1.8, extract records ALMOST ALWAYS have
the local time zone, even if the new Common Time UTC(YES)
option is enabled. However, if the RHTZNAME field in the
header record is non-blank, then the user specified the
TZ operand of the RPTEXT command, and times IN the record
were created on that time zone; in this case, MXG does
use the GMTOFF to convert record times to local time zone
and MXG prints a message when this is detected.
-The MXG support for all possible data formats added in
Change yy.xxx requires a Header Record to define the date
formats (Julian, American, European, etc.), but if there
was no Header record, all of the date/times were missing.
This change prints an error message if no "H" Header was
found as the first record in the file, and sets the date
format to the Julian (arbitrary, but most common), with
no guarantee that valid times will be created.
Thanks to Jorge Fong, NYC Information Technology, USA.
Thanks to Phillip Moore, UHC, USA.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 28.028 BMC IMF INPUT STATEMENT EXCEEDED RECORD LENGTH when a
VMACCIMS shorter than expected TRNEXTEN segment of only 16 bytes
Feb 24, 2010 was found; MXG expected 52 bytes. What's sad is that
I only input that segment, and didn't keep it, so it is
not even important, but now, the length remaining is
validated prior to the INPUT of that segment. BMC support
has acknowledge the error: "MVIMS should clear TRNEXTEN
and TRNEXTLN when it strips off the extension. A PTF will
be created to correct the problem.
Thanks to Lorena Ortenzi, UniCredit Global Info Services, ITALY.
Thanks to Paolo Uguccioni, UniCredit Global Info Services, ITALY.
Change 28.027 Do not use the EXIT112 ASM program to decompress CICS SMF
EXIT112 110 records: instead, use the EXITCICS ASM program to
Feb 23, 2010 create the CICSIFUE infile exit to process CICS/TS 3.2
VMAC110 compressed SMF records. As noted in the original change
text, EXIT112 was supposed to handle both 110 and 112
compressed records, and it was tested in 2007, but it now
fails with either 110 or 112 compressed records.
I thought you could use the IBM DFH$MOLS program to
decompress the 112 Omegamon records, but you can't.
-MXG VMAC110 was updated to print a message when the
internal SAS decompression code was executed because the
CICSIFUE exit was not installed.
Change 28.026 Only for consistency, SUMBY= argument changed to STARTIME
TRND71 in place of the now-archaic DATETIME symbol.
Feb 23, 2010
Change 28.025 New Crypto Type CEX3C PRCAPMCT=9 caused MXG to CPU LOOP
FORMATS on the DM=5 RC=10 PRCAPM segment, with no clue unless you
VMACVMXA enabled DEBUG=2 to see the last record before the loop.
Feb 22, 2010 -MXG now protects any unknown PRCAPMCT value with MXGERROR
messages for the first 3 records, and no CPU loop!
-PRCAPMCT values 3,5,7,9 have one structure, and 4,6,8
have a second structure (and 4 has 5 engines, while 6,8
have only one engine). All seven values are now decoded.
-Variable PRCAPMCT is now formatted with new MGVXACX
to map the value to the Crypto Type processor:
3='3:PCICC'
4='4:PCICA'
5='5:PCIXCC'
6='6:CEX2A'
7='7:CEX2C'
8='8:CEX3A'
9='9:CEX3C'
Thanks to Jim Kovarik, AEGON USA, USA.
Change 28.024 Variable BYTESIN is now MGBYTES formatted, rather than
VMACAIX MGBYTRT formatted, as it contains bytes, not a rate.
Feb 18, 2010
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.023 -New MXGERROR and USER ABEND 990 if NOWORKINIT is enabled.
VMXGINIT Unlikely/obscure, but if //WORK is a Permanent DSNAME and
Feb 18, 2010 has DISP=OLD, that NOWORKINIT option skips initialization
of the (normally temporary) //WORK library, so whatever
temporary stuff (macros, catalogs, tables, datasets) was
left from the last SAS step will be used for this step.
While there may be some applications that can use this
"feature", MXG is NOT one of them. When an ITRM site
with that environment upgraded to 27.27, the SAS Compiler
initially had UNRESOLVED MACRO VARIABLE TEMP1ENG errors
in the first execution of VMXGSUM in BUILDPDB, but a job
to enable diagnostics had a typo that caused an error,
but when fixed and diagnostics were enabled, yet another
compiler error was encountered, and three subsequent runs
all failed with different errors. It was only when one
error reported CORRUPTED MACROs that we spotted the reuse
of the //WORK DD in the JCL, and only because diagnostic
option VERBOSE had been turned on that we saw the CONFIG
in use had specified the NOWORKINIT option.
That original unresolved macro error was false; there was
no error in MXG code, but was the result of a conflict
between the old, compiled, %VMXGSUM macro in //WORK that
was compiled from the old MXG, with the invocation in the
new MXG that expected the new definition. Changes were
made to VMXGSUM between the two versions.
This change causes a USER ABEND 990 and MXGERROR messages
if the NOWORKINIT is enabled at MXG Initialization.
-All VMXGxxxx members that define volatile %MACROs print a
single MXGNOTE: VMXGxxxx LAST UPDATED...., when the macro
is compiled; this will avoid a rerun just to determine if
an old macro is in use when there are errors.
-But, see Change 28.079A
Change 28.022 -ML-47 of ASMTAPEE/MXGTMNT protects for diagnostic ABEND.
ASMTAPEE If diagnostic trap IEAINITREGSTASK is enabled, it causes
Feb 13, 2010 a recoverable ABEND 0E0-28 for each XMEM Cross-Memory
call, with a loss of data fields in some MXGTMNT records,
and the unwanted overhead of triggering that trap.
Diagnostic traps like this are enabled, usually only on
test systems, but especially on new z/OS system tests,
to expose existing or potential coding errors. The fact
that this trap caused an abend doesn't necessarily mean
there is an error.
The idea behind this one is that if a program does not
properly set a register, then any use of that register
could potentially lead to a storage overlay. Storage
overlays are some of the most difficult problems to
diagnose because you don't get an abend when the storage
is overlaid: the abend only comes later when subsequent
code attempts to use that storage and comes across that
now-corrupted area. The abend could happen immediately,
or hours later.
This trap places x'FF' in all registers, including access
registers, at task initialization, with the expectation
that the task will clear all access registers before it
goes into AR cross memory mode. The 'FF'x will cause the
code that is using the register without clearing it to
immediately abend, making this storage overlay error much
easier to find. There are several IBM APARs for various
products that had identical S0E0 ABENDS.
Newer sections of MXGTMNT do clear all ARs, but the older
code, pre ML-29, only cleared the ARs that were actually
used, leaving the unused ARs with the x'FF' value.
What is the exposure for MXGTMNT? There isn't any. This
trap exposes, at most, a bad programming practice, maybe!
The trap ABEND is caused by the access registers being
set to x'FF's. Access registers are used for access via
cross memory, and the trap sets them when the task is
first created and entered.
Since MXGTMNT is the first task there is no chance that a
previous task left any unwanted data in the access
registers. But even though there is no exposure, we have
no choice but to add code to clear all ARs; otherwise
anyone who runs MXGTMNT with that diagnostic trap enabled
will encounter these abends.
See Change 28.041 text for ML-47 status.
Thanks to Ginny Nugent, SAS Institute, USA.
Thanks to Ed Webb, SAS Institute, USA
and to my "asmguy", who provided the explanations and the update.
Change 28.021 The zPCR program works fine for simple configurations,
ANALZPCR but with missing data, or multiple, complex, sysplexes
Feb 13, 2010 the ANALZPCR program could fail, the MXG-created .zpcr
Feb 16, 2010 file load could fail, or a model that would load without
Feb 25, 2010 an error could have SYSTEMs in the wrong SYSPLEX.
Feb 28, 2010 -The SYSPLEX value in PDB.TYPE70PR is NOT the SYSPLEX of
Mar 4, 2010 the LPARNAME, but, rather, is the SYSPLEX on which that
Mar 5, 2010 SMF record was written, a fact overlooked in ANALZPCR,
which needs to correctly associate LPARNAME to SYSPLEX.
Depending on the alphabetical ordering of your SYSTEM and
SYSPLEX names, ANALZPCR sometimes accidentally had the
right SYSTEM in the right SYSPLEX, but not always.
Now, PDB.TYPE70, whose SYSTEM-SYSPLEX pairing is always
right, is read to create a format mapping SYSTEM to its
SYSPLEX (in addition to the existing format that maps the
SYSTEM to MVSLEVEL). Then, PDB.TYPE70PR is read, values
of MVSLEVEL/SYSPLEX are set from SMF70STN format lookups,
and the WORK.TYPE70PR dataset has correct SYSPLEX and
MVSLEVEL for LPARNAME, so ANALZPCR now always is right.
-zPCR load fails with MXG-created .zpcr file if incomplete
SMF/PDB data input was read and SCP created.
The input SMF or PDB must have TYPE70 observations for
every SYSTEM to get the MVSLEVEL, which is used to set
the SCP tag from SMF70STN in TYPE70PR. If a system's
data doesn't have TYPE70 data and is only in the TYPE70PR
LPAR data, the SCP tag value 'z/OS-MXG**' has always been
created in the .zpcr file, but not documented, and that
tag value must be changed for zPCR to load the text file.
Now, there are ERROR messages when you have missing data
telling you MUST change those SCP tag values before using
the .zpcr file. Output reports also are enhanced to show
the MVSLEVEL and SMF70STN for each LPAR.
-ANALZPCR program fails with overlapping FORMAT values if
the SMF/PDB input has data with multiple MVSLEVELS from
the same SYSTEM. ANALZPCR will now detect and continue
to execute, and will use the LAST MVSLEVEL for SCP tag,
but will also print ERROR messages when this is detected.
ANALZPCR can't easily be redesigned to support this
multiplicity, but you can split your input and run the
ANALZPCR twice to create each of the two .zpcr files.
-When ANALZPCR is run on ASCII, to read a PDB.TYPE70 that
was CIMPORTed from z/OS and that had been created on z/OS
"before" the TRANSCODE attribute was added by MXG 27.01
(Change 27.014) to all HEX-containing-$CHAR-variables,
variable CPUTYPE will have been converted to '886D'x for
a true CPUTYPE='2094'x. ANALZPCR now tests CPUTYPE for
these "wrong" values: 886D/886F/8870/8871x in CPUTYPE
and corrects them to: 2094/2096/2097/2098x so that the
NAME tag that zpcr expects is created in the .zpcr file.
-When PDB=SMF was used, DASDIORT counted only DASD I/O by
selecting only DEVCLASS=20X when SMF was read. But when
PDB=PDB was used, but only if your PDB.TYPE74 dataset had
other DEVCLASS's captured, DASDIORT was the total I/O.
Now, the PDB=PDB logic selects only DEVCLASS=20X counts.
-MXG uses LCPUSHAR, the Initial Shared LPAR Weight, but if
IRD is active (LPARWLMG='Y'), zPCR expects SMF70ACS, the
Current Shared Weight.
-The message for Linux LPARs that you have to manually put
the SCP type printed the SYSTEM instead of the LPARNAME.
-When PDB=CECTIME was used, specialty engine and ICF's
could have been miscounted.
-SELECT PEAKTIME or PEAKPCT only summarize zOS SYSTEMs,
and they do NOT contain IFLs, nor ICF partitions, and
thus are unlikely to be used. CECTIME is DEFAULT.
-Mar 4, 2010. zPCR Release 6.3a failed to load a model
with CPUTYPE 2094-722; IBM zPCR support
created an updated zPCR program with same-day-service!
With that new release, the Book Configuration, which is
now VERY important, can be specified in the pull-down.
Thanks to Frank Bereznay, IBM Global Services, USA.
Thanks to Raff Rushton, IBM Global Services, USA.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 28.020 Variable QAQSGDSP, Sharing Group Dispositions, in dataset
FORMATS TMMQQAA is now decoded by new FORMAT $MGTMQDI.
VMACTMMQ
Feb 12, 2010
Thanks to Paul Volpi, UHC, USA.
Change 28.019 INVALID DATA FOR RVTRERR in EDGHSKP records is caused by
VMACEDGR IBM writing a question-mark character instead of a count
Feb 10, 2010 of errors as an &NUM4. field. This change eliminates
that NOTE and the HEX record dump for all four xxxxERR
variables (by changing the INPUT to use ?? &NUM.4.), but
IBM will be contacted for an explanation; perhaps they
store a question mark when the error count is larger than
the maximum of 99999 that fits in that 4-byte field.
These instance of invalid data values can be identified
because RVTRERR will be a missing value in the EDGRXEXT
or EDGRVEXT dataset.
Thanks to Paul Volpi, UHC, USA.
Change 28.018 All of the duration/clock values are in 1024 microsecond
VMACTMVT units and not the 64 microsecond units MXG had coded; the
Feb 10, 2010 correct 1024 multiplier is now used. The FORMAT TIME13.3
will still display decimals the maximum resolution of one
millisecond (0.001 seconds), since 1024 microseconds is
just at teeny bit more than one millisecond.
Thanks to Paul Volpi, UHC, USA.
Change 28.017 CICS Optional 'PSB SCHL', a mis-spelling of the expected
UTILEXCL 'PSB SCHD' field name, is now recognized and supported.
Feb 8, 2010
Thanks to Thomas E. Porta, TYCO Electronics, USA.
Change 28.016 SAS Version 9.2 changed the PROC GCHART's PATTERN default
DOC to a terrible choice that produces unreadable patterns.
Feb 6, 2010 Feb: Investigating alternatives.
Aug 9, 2010 Aug: Better definition of color/patterns now defined as
default in VMXGINIT, but if you choose your own,
yours will instead be used.
Change 28.015 Support for z/TPF SMF 89 record; z/TPF put the subtype in
VMAC89 byte 19 rather than bytes 19-20 as documented for z/OS.
Feb 3, 2010 MXG protects either z/OS or z/TPF SMF ID=89 records now.
Thanks to Paul J. Westerhout, KLM, THE NETHERLANDS.
Change 28.014 MXG 27.10-MXG 27.27. The wildcard colon-suffix in the
VGETDDS DDNAMES= argument, to allocate all DDNAMEs starting with
Feb 3, 2010 those characters (%VGETDDS,DDNAMES=PDB:); worked ONLY for
DDNAMES=PDB:). Any OTHER prefix characters ahead of that
colon caused syntax errors. And, DDNAMES=ALLDAYS or even
a list of specific DDNAMES=MON TUE WED names also failed,
with LIBNAME PDBx NOT ASSIGNED because a separate error
sent VMXGDDS to try to allocate LIBNAMES starting with
PDBn, no matter what names you used in your DDNAMES=.
Note: If the DATASET you will look for in VMXGSET might
not exist in all of the LIBNAMES you specify, you
can use OPTIONS NODSNFERR; and only the found
datasets will be read by VMXGSET, and the SAS log
will indicate which DDnames had the DATASET.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.013 Variables QW0127FG/QW0127PG/QW0128FG/QW0128PG are INPUT
FORMATS and kept in T102S127 and T102S128 datasets. The "PG"
VMAC102 variables are four-byte replacements for the three-byte
Jan 30, 2010 existing "PN" page number variables.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.012 Very kewl tool, %VMXGFIND searches a SAS data library to
VMXGFIND FIND all observations in all datasets that meet your test
VGETVAR criteria, outputs those selected obs into a separate SAS
VMXGPRNT data library, and prints all selected obs (all variables,
Jan 31, 2010 with the variable's name AND label as heading).
For example:
%VMXGFIND(
PDB=PDB,
PDBOUT=PDBOUT,
KEEPIN=JOB,
FIND= IF JOB='MXGBUILD'; ,
PRINT=YES);
finds all obs with JOB='MXGBUILD' in all of the datasets
in the PDB input library, and outputs those obs into
their datasets in the PDBOUT data library, and prints.
In your KEEPIN= argument, you list all of the variables
that will be used in the SAS code in your FIND= argument.
Only the datasets with one or more of those variables are
read, and the FIND= logic is used to output the selected.
You can test with complex logic with multiple variables
that don't exist in all of the dataset. For example:
%VMXGFIND(
PDB=PDB,
PDBOUT=PDBOUT,
KEEPIN=STARTIME STRTTIME INTBTIME,
FIND= IF ('31JAN2010:15:00:00'DT LE STARTIME LT
'31JAN2010:16:00:00'DT )
OR ('31JAN2010:15:00:00'DT LE STRTTIME LT
'31JAN2010:16:00:00'DT )
OR ('31JAN2010:15:00:00'DT LE INTBTIME LT
'31JAN2010:16:00:00'DT ) ;,
PRINT=100);
selects all interval observations that started in the 3PM
hour, from RMFINTRV plus all detail RMF datasets, from
CICINTRV and any other CICxxxxx interval datasets, from
DB2STATx interval datasets, from the SMFINTRV dataset,
and from ANY other PDB dataset with ANY of those three
variables meeting the test. There will be log messages
UNINITIALIZED VARIABLE printed when a dataset being read
doesn't contain all KEEPIN= variables, but they are
harmless and unavoidable.
Or, this example
%VMXGFIND(PDB=PDB,PDBOUT=PDBOUT,
KEEPIN=RACFUSER QWHCAID FSRUID,
FIND=IF RACFUSER=::'JOE" OR
QWHCAID=:'JOE' OR
FSRUID=:'JOE';,
PRINT=YES );
will find all observations from user "JOE".
New %VGETVAR(DDNAME=,DATASET=,VARNAME=), used in VMXGFIND
determines if variable VARNAME exists in DDNAME.DATASET.
VMXGPRNT now deletes WORK.TMPPRNT (previously WORK.SP_L).
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.011 Reading VSAM SMF for type 119 records failed; the OFFSMF
VMAC119 was not added to all of the offsets.
Jan 29, 2010
Thanks to Kim Westcott, State of New York, USA.
Change 28.010 Variable SHIFT is created from the QWHSSTCK (END TIME) in
VMACDB2H the DB2 Header for all DB2 records, and SHIFT is now kept
VMACDB2 in all of the datasets created from SMF 100 and 101 data.
Jan 28, 2010
Thanks to Atle Mjelde, ErgoGroup, NORWAY
Change 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 record is due
VMAC0 to absence of &IB.4. in its INPUT statement, but as this
Jan 28, 2010 new variable is not used elsewhere, this had no impact,
except the waste of your time chasing this message down.
I missed this because there were no IPL records in any of
my z/OS 1.11 test SMF data, and because the absence of an
INFORMAT in an INPUT statement is not a syntax error.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.008 The SPIN.SPINMOUN and SPIN.SPINSYSL dataset could grow to
ASUMTAPE massive size (1.8 million obs in SPINSYSL) because there
Jan 26, 2010 was no test to stop their spinning after some number of
days. Now, IMACSPIN is read and its value of _SPINCNT is
used to determine when a still-unmatched syslog message
should be "spun" again. When observations are deleted
due to their age, the count is printed on the SAS log.
The default IMACSPIN has _SPINCNT of zero, because if
you failed to read INSTALL's instructions on how to
EDIT your IMACSPIN member, at least then when you run
your first BUILDPDB, all of the jobs in SMF are output
to the PDB library, with none output to SPIN, so you
will find all your jobs, complete and incomplete, in
that first PDB. Then, when you ask about all those
incomplete jobs, tech support will point you back to
read INSTALL and IMACSPIN to set _SPINCNT.
But for ASUMTAPE, I will always spin the incomplete
mount events at least one day, using _SPINCNT+1, which
should allow most incomplete mounts today to match up
tomorrow, even if you haven't changed IMACSPIN.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 28.006 An example Ranking analysis, a PROC RANK on steroids.
ANALRANK
Jan 25, 2010
Change 28.005 -Support for Sun StorageTek Enterprise Library Software
VMACSTC Version 6.2 and Version 7.0. Version 6.2 adds new field
Jan 25, 2010 STC14N4K, the number of 4K blocks, used to re-calculate
Feb 2, 2010 STC14VSZ, which was previously limited to a max of 4GB.
Sep 16, 2010 Variables marked with * below, are only in Version 7.
-New variables added to STCVSM13 dataset;
*STC13PLX='TAPEPLEX*FROM WHICH*VTV RECEIVED'
-New variables added to STCVSM14 dataset;
STC14SRS='SYNCHRONOUS*REPLICATION*STATUS'
STC14RUN='REWIND*UNLOAD*RECEIVED*DATETIME'
*STC14PLX='TAPEPLEX*FROM WHICH*VTV RECEIVED'
-New variables added to STCVSM16 dataset;
STC16INF='RTD*CHANNEL*INTERFACE*ID'
STC16ADR='MVS*ADDRESS*OF*RTD'
-New variables added to STCVSM17 dataset;
STC17INF='RTD*CHANNEL*INTERFACE*ID'
STC17ADR='MVS*ADDRESS*OF*RTD'
*STC17DFL='DISMOUNT*FLAG'
-New variables added to STCVSM18 dataset;
STC18INF='RTD*CHANNEL*INTERFACE*ID'
STC18ADR='MVS*ADDRESS*OF*RTD'
-New variables added to STCVSM19 dataset;
STC19INF='RTD*CHANNEL*INTERFACE*ID'
STC19ADR='MVS*ADDRESS*OF*RTD'
-New variables added to STCVSM25 dataset;
STC25SCL='MVS*STORAGE*CLASS'
STC25TUS='SPACE*USED BY*CURRENT*VTVS'
STC25NDV='NUMBER*OF HOLES*DELETED*VTVS'
STC25LUT='MVC*LAST*USED*DATETIME'
STC25LWT='MVC*LAST*UPDATED*DATETIME'
-New variables added to STCVSM26 dataset;
STC26MGT='VTV*MANAGEMENT*CLASS'
-New variables added to STCVSM27 dataset;
STC27CTP='CARTRIDGE*TYPE'
STC27MV3='VOLSER OF*MVC3*CONTAINING*THE VTV'
STC27MV4='VOLSER OF*MVC4*CONTAINING*THE VTV'
-New variables added to STCVSM28 dataset;
STC28RUN='REWIND*UNLOAD*RECEIVED*DATETIME'
*STC28PLX='TARGET*TAPEPLEX*FOR*EXPORT'
-Sep 16: No code change, but with this change there were
obs created from subtype 7 records in STCHSC dataset
with the Oracle SL8500 hardware, whereas MXG 27.05
created zero observations in STCHSC.
Thanks to Davide Marone, SGS S.p.a. ITALY
Thanks to Carlo Gavinelli, SGS S.p.a. ITALY
Thanks to Gianvittorio Negri, SAS Institute, ITALY.
Change 28.004 The EXTREMELY DETAIL DB2 Trace Report PMTRC01 is revised
ANALDB2R for efficiency, keeping track of which of 350 possible
Jan 25, 2010 trace datasets are actually populated, and only using
Feb 22, 2010 their variables. Some uninitialized variables messages
and character to numeric conversions were eliminated.
Note that your DBA needs to enable all of these IFCIDs to
cover all I/O and SQL calls:
IO 6 7 8 9 10 29 30 34 35 36 37 38 39 40 41 105 107
114 115 116 119 120
SQL 6 7 8 9 10 11 12 15 16 17 18 19 20 22 44 45 53 55
58 59 60 61 62 63 64 65 66 68 69 70 71 73 74 75 76
77 78 79 86 87 88 89 95 96 105 107 125 157 158 159
160 163 174 175 177 183 ACCOUNT
With CONNTYPE=4 in the argument list, only records from
CICS Connection will be reported, so if both I/O and SQL
traces are enabled, you can see what DB2 Tables/DBIDs are
touched for each transaction, and can what types of SQL
calls were made for each transaction. Unfortunately, you
can NOT map SQL calls to each DB2 Table that was used.
%ANALDB2R(PDB=SMF,PMACC01=NO,PMACC02=NO,
PMSTA02=NO,PMSPR01=NO,
PMTRC01=YES,CONNTYPE=4);
See correction in Change 28.083.
Thanks to Paul Volpi, UHC, USA.
Change 28.003 Summary of (archaic) SMF 118 records in ANALTCP and of
ANALTCP current SMF 119 records failed if PDB was on TAPE.
ANAL119
Jan 21, 2010
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.002 Variables CPUZIPTM and CPUIFATM added to this example
ASUMSMFI summarization of PDB.SMFINTRV.
Jan 21, 2010
Thanks to Frank Lund, EDB Business Partner Norge AS, NORWAY
Change 28.001 Unused Change.
LASTCHANGE: Version 28.
=========================member=CHANGE27================================
/* COPYRIGHT (C) 1984-2010 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 27.27 is dated Jan 20, 2010, thru Change 27.361
MXG Version 27.27 is the 2010 "Annual Version".
MXG Newsletter FIFTY-FIVE is dated Jan 20, 2010
MXG Version 27.11 is dated Dec 31, 2009, thru Change 27.337
MXG Version 27.10 is dated Dec 6, 2009, thru Change 27.325
MXG Version 27.09 was dated Oct 14, 2009, thru Change 27.283
MXG Version 27.08 was dated Sep 1, 2009, thru Change 27.229
MXG Version 27.07 was dated Aug 11, 2009, thru Change 27.195
MXG Newsletter FIFTY-FOUR is dated Aug 10, 2009
MXG Version 27.06 was dated Jul 20, 2009, thru Change 27.167
MXG Version 27.05 was dated Jun 29, 2009, thru Change 27.145
MXG Version 27.04 was dated May 27, 2009, thru Change 27.107
MXG Version 27.03 was dated May 4, 2009, thru Change 27.083
MXG Version 27.02 was dated Apr 13, 2009, thru Change 27.066
MXG Version 27.01 was dated Mar 17, 2009, thru Change 27.042
MXG Version 26.26 was dated Feb 12, 2009, thru Change 26.326
MXG Version 26.26 was the 2009 "Annual Version".
MXG Newsletter FIFTY-THREE was dated Feb 3, 2009
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/ship_current_version
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 27.27 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 27.27.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================
I. MXG Version 27.27 dated Jan 20, 2010, thru Change 27.361.
MXG Version 27.27 is the "Annual Version" for 2010.
Major enhancements added in MXG 27.27, dated Jan 20, 2010
VMXGCNFG 27.356 The standard SAS JCL Proc can be used for MXG.
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
TYPE112 27.358 Support for OMEGAMON ONDV SMF 112 SUBTYPE 0100X
TYPEEDGR 27.349 Support for RMM APAR OA28930, RDBLKCNT/RDTOTAL.
TYPEEDGR 27.349 Support for RMM APAR OA24025 RDDESKEY.
TYPEEDGR 27.339 RVTxERR RVPxERR variables now numeric, incompatible.
TYPE1415 27.361 MXG 27.06-27.11. BUFNO always zero due to typo.
TYPESRMH 27.340 SRM Thales Security PTF SL24010 INCOMPATIBLE support.
VGETDDS 27.359 WAIT=N option protects for DSNAME already in use.
VGETDDS 27.330 New DATEJUL= correctly generates julian dsnames.
VMXGALOC 27.355 NOWAIT added, create/allocates are now conditional.
READDB2 27.351 READDB2 didn't always invoke its EXdddddd members.
TYPE80A 27.357 TYPE8066 dataset enhanced.
TYPETMVT 27.347 TMON/VTAM "SI" record Interval variables now INPUT.
ANAL307X 27.346 Analysis compares Hourly CPU in 70, 72, 30 interval.
JCLCIDB2 27.345 UTILBLDP JCL example for CICS, DB2, and ASUMUOW+.
ASUM70PR 27.344 Variables LPCTBY/PCTLPBY missing for PHYSICAL LPAR.
VMXGSET 27.343 VMXGSET permits multiple datasets with APPEND=YES.
VMACSMF 27.341 WARNING: SUBTYPE GT 255 message now not defaulted.
TYPEIMSA 27.354 MXGNOTE now prints the value of _IMSVERS on the log.
Major enhancements added in MXG 27.11, dated Dec 31, 2009
EXPDBINC 27.334 MXG 27.10 ONLY. %UTILBLDP option USERADD= fails.
(Must remove &EPDBINC from EXPDBINC if you used the
%UTILBLDP to create your BUILDPDB source SYSIN code.)
TYPETMNT 27.336 SYSLOG message text size increased to 32384 bytes.
ANALRMFR 27.333 RMF Summary Report (REPORT=SMRY) was incorrect.
ANALJOBE 27.332 Analysis of Job Events revised, JESNR test removed.
TYPE80A 27.331 Protection for unknown TOKDANAM eliminates STOPOVER.
TYPE82 27.330 SMF82PDK, SMF82RKN, SMF82PTA increased, corrected.
TYPE110 27.329 MXG 27.10, CICIDNNR NOT FOUND, only if _S110ST used.
ASUMMIPS 27.327 DUR70 created with actual vs expected DURATM.
TYPEDB2 27.326 Variable QDSTQCIT now not deaccumulated.
Major enhancements added in MXG 27.10, dated Dec 6, 2009
TYPE0 27.325 Updated Support for z/OS 1.11, ID=0 now supported.
TYPECDC 27.324 Support for IBM's InfoSphere Change Data Capture CDC
TYPEDB2 27.319 Support for QMDAPTYP='JCC' (Type 4 JDBC Driver).
TYPE7072 27.317 Support for APAR OA28670 RMF 70 Crypto Express3
VMACORAL 27.306 Support for restructured ORACLE SMF records.
TYPESYNC 27.289 Support for CPUZIPTM added in SYNCSORT SMF records.
READDB2 27.322 IFCIDS= features (STATS, DB2ACCT, Dataset Name, etc)
MRGDB2 27.321 MERGE of PDB.DB2ACCT and PDB.DB2ACCTP for DB2PARTY
JCL40GIG 27.316 JCL example to split/parallelize BUILDPDB job.
VGETDDS 27.310 New DATEJUL= created DSNAMES with Julian YYYDDD.
VMXGDUR 23.308 SYNC59-NO/VMXGDUR/VMXGSUM (final?) enhancements.
ASUMMIPS 27.305 ASUMMIPS now inflates MSU by system CAPTURE RATIO.
TYPE110 27.303 CICS Total I/O and Total Other Wait updates.
ALOCGOVO 27.299 Allocate GDG's with GOOVOO to minimize DSENQUEUE.
TYPETIMS 27.298 Expensive algorithm to uncompress ASG/Landmark data.
TYPENTSM 27.312 MXG 27.09 only. NTSMF Processing failed, RECFM.
DAILYDSx 27.287 MXG 27.09 only. TMC= should have been TAPEDATA=.
TYPE74 27.287 MXG 27.09 only. DEBUGGING PUT statement removed.
CONFIGxx 27.294 MXG 27.08-27.09 only. Option MAUTOLOCDISPLAY removed.
TYPEPROS 27.295 PRO/SMS SMF record misalignment corrected.
ASUM70PR 27.294 IFL obs in ASUM70LP/ASUMCELP missing STARTIME fixed.
ASUM70PR 27.292 First LPAR had missing values in LPSHAR/TOTSHARE.
TYPE42 27.291 Variable S42DSRDD incorrect by factor of 10**6.
ASMTAPEE 27.300 ASMTAPE ML-45 enhancements to TMNTnnnn messages.
Major enhancements added in MXG 27.09, dated Oct 14, 2009
TYPE110 27.260 TRANSPARENT UNCOMPRESS OF CICS/TS 3.2 RECORDS!!!
This means you do NOT have to assemble and install
the EXITCICS "infile" exit.
HOWEVER: VERY EXPENSIVE COMPARED TO EXITCICS.
SEE THE TEXT OF THE UPDATED CHANGE.
MANY 27.277 Support for USER=DDNAME, "WORK" now "&MXGWORK".
TYPE110 27.274 SORT Order for CICFCR changed, A17DSIXP/DTRDS fixed.
CICINTRV 27.274 CICS DISPATCH INTERVAL LARGER THAN INTERVAL fixed.
READDB2 27.272 READDB2 support for WANTONLY now works.
TYPE110 27.270 CICS STID=115 should not exist.
ASUM70GO 27.268 Example summarizes PDB.TYPE72GO, changing interval.
TYPEVMXA 27.264 z/VM MONWRITE example processes only USER domain.
TYPE74 27.263 R744FNAM not in TYPE74DU, ITRM sites need update.
ASUMMIPS 27.262 MSU/MIPS for zIIPs and zAAPs added to CPs summary.
TYPE120 27.255 WAS SMF1209FI/EV (CPU/Elapsed Times) corrected.
RMFINTRV 27.252 Format missing for many duration variables, fixed.
TYPEEDGR 27.251 RMM Dates - American/Euro/ISO/Julian - all supported.
TYPETMDB 27.259 Support for TMON for DB2 BA/BJ/BK/BL/BM subtypes.
TYPEACF2 27.258 Support for Subtype 'O' OPENEDITION record.
TYPEQACS 27.256 Support for QACSLPAR dataset.
TYPE120 27.255 SM1209 RETAINED, SM1209FI/EV corrected.
RMFINTRV 27.252 Formats for durations added.
TYPEEDGR 27.251 Support for all four RMM Date Formats
TYPE80A 27.250 Protection for UNKNOWN TOKDANAM and RDEFINE CFIELD.
TYPE74 27.249 R747PAVG AVERGAGE FRAME PACING matches RMF report.
VGETDDS 27.248 Logic revised when DDNAMES= syntax is used.
TYPEHBUF 27.247 FLAG1 tests for HyperBuf optional segments revised.
DAILYDSN 27.246 Variables DSN DSNBACTV STPNAME had UNINIT messages.
GRAFWRKX 27.245 zIIPs and zAAPs added to SAS/GRAPH hourly workloads.
TYPE110 27.245 OTRANNUM right with IMACEXCL, wrong in VMAC110.
FORMATS 27.243 OPTIONS NOCHARCODE reset at end of FORMATS.
TYPE80A 27.241 RACFEVNT=79 EXTLNTYP=379 INPUT EXCEEDED error.
WPS 27.239 WPS 2.4 GA has been tested, requires MXG 27.09.
ANALDB2R 27.238 AUDIT report revisions, reduced processing time.
VGETOBS 27.237 Enhancement if no DDNAME argument.
TYPE116 27.235 Six datetimes are now converted to LOCAL, were GMT.
VMXGSUM 27.234 Revision to eliminate OUTCODE= argument sometimes.
TYPEDB2 27.232 TMON/DB2 created SMF 101 St 0 OFFQLAC invalid.
TYPECIMS 27.230 Variable LASTCLAS in IMF CIMSPROG incorrectly INPUT.
Major enhancements added in MXG 27.08, dated Sep 1, 2009
Several 27.229 Support for z/OS 1.11, COMPATIBLE, except for ID=0.
TYPE110 27.200 Support for CICS/TS 4.1 GA additions, new stats.
BUILDPDB 27.213 HFS/zFS EXCPS are in EXCPTOTL, new USSEXCPS count.
TYPENDM 27.222 Support for NDM-CDI NDMRTYPE 'SC' and 'S2' subtype.
TYPEOSEM 27.221 Support for zOSEM Operating System Environment Mgr.
TYPE16 27.211 Support for new z/OS 1.10 DFSORT variables.
ANALDB2T 27.223 New "Top" DB2 Report ranks resource for corr,auth id.
ANALCNCR 27.220 MXG 27.06-27.07. Failed if multiple INDATA= datasets.
ANALCNCR 27.203 PDB.ASUMTALO had too few obs due to ANALCNCR error.
ASUMTALO 27.203 PDB.ASUMTALO had too few obs due to ANALCNCR error.
RMFINTRV 27.218 SMF70LAC was maximum value rather than average.
RMFINTRV 27.214 RMFINTRV STARTIME could be early by an interval unit.
ASUM70PR 27.214 ASUM70PR STARTIME could be early by an interval unit.
TYPE7072 27.217 Blank SMF70CIN in PDB.TYPE70PR if last LPAR offline.
TYPEXAM 27.216 Variable SYTLPNAM restored kept in XAMSYT dataset.
TYPETMO2 27.215 TMON/CICS Version 3.1 INPUT EXCEEDED on 'TI' record.
TYPEDCOL 27.212 Support for APAR OA30006, 8-byte DCOLDSET fields.
TYPETMDB 27.209 TMON/DB2 BF record SQL text BF0142RL corrected.
TYPEDB2 27.207 MXG 27.07. QSSTCONT,QSSTCRIT re-de-accumulated.
TYPE92 27.204 Change 27.154 did not correct missing path section.
ANALRMFR 27.198 ANALRMFR wrote TYPE7xxx to //PDB with PDBOUT= null.
TYPE85 27.196 Heuristic in Change 27.138 did not correct EXCEEDED.
VMXGDUR 27.214 New FLORCEIL=FLOOR/CEIL argument for begin/end calc.
VMXGDUR 27.214 SYNC59=YES default with FLOOR, always safe.
BUILDPDB 27.220 MSOUNITS,SERVICE corrected to always be LENGTH 8.
Major enhancements added in MXG 27.07, dated Aug 11, 2009
TYPEIOO 27.189 Support for Serena's StarTool IOO Product SMF.
TYPENTSM 27.184 Support for 13 VMWARE objects captured by NTSMF.
READDB2 27.169 MXG 27.04-27.06. T102Snnn datasets had zero obs.
ASUMTAPE 27.181 Support for VOLSER='SCRTCH' from MXGTMNT monitor.
TYPENMON 27.180 Support for CPU_PHYSICAL,CPU_ENTITLED TOPAS objects.
TYPEITRF 27.177 Variable RECTOK was truncated to 12 bytes.
TYPECIMS 27.176 Support for IMF 4.4 was incorrect for TRNxxxxx vars.
TYPECIMS 27.176 BMC PTF BQI0695 corrects overlaid DBD segments.
TYPEDB2 27.17x Corrected, misspelled DB2 variables.
ANALDB2R 27.172 Many tests IF x NE 0 replaced with IF x GT 0.
ASUM70PR 27.178 Summary STARTIME now exact, based on SMF70GIE-DURATM.
RMFINTRV 27.178 Summary STARTIME now exact, based on SMF70GIE-DURATM.
Major enhancements added in MXG 27.06, dated Jul 20, 2009
TYPE102 27.162 Support BMC APPTUNE SQL SMF 102 IFCIDs 8004x-8136x
TYPEDB2 27.158 Support for UIFCIDS=YES, all "%U" DB2 fields revised.
TYPEVMXA 27.156 Support for z/VM 6.1.0 in MXG 27.01+; no new data.
TYPE1415 27.148 Support for APAR OA29428, identifies who closed file.
TYPE7072 27.149 Labels for Counts of ZIP, IFA, CPs, clarified.
TYPE42 27.155 Type 42-16 STOPOVER, 42-21/24 ICHRUTKN protect, APAR.
TYPE92 27.154 Variable SMF92PPN blank in TYPE9201, was not INPUT.
TYPE119 27.153 Variable NTBTRNBE input now as count and not a time.
ANALZPCR 27.147 SCP too short for z/OS 1.10, wrong if multiple SCPs.
TYPEDCOL 27.152 MXG 27.01-27.05. DCOLLECT UBALLSP is missing value.
TYPEXAM 27.151 XAM TCP record INPUT STATEMENT EXCEEDED error.
Major enhancements added in MXG 27.05, dated Jun 29, 2009
TYPE30 27.122 Support for APAR OA26832 expands Service Unit fields.
TYPERMVF 27.120 RMF III z/OS 1.10 new ASI fields (INCOMPATIBLE).
MXGSASxx 27.108 &NULLPDS &LOAD &SASAUTOS symbolics REMOVED from JCL.
ANALDB2R 27.131 DB2PM-like STATISTICS LONG report MAJOR updates.
ANALZIPU 27.137 Analysis of zIIP used by JOB/PROGRAM/SRVCLASS etc.
TYPETMMQ 27.145 Support for TMON for MQ record 'QA' (APPLICATION).
TYPEQACS 27.134 More updates for IBM i, i5/OS, iSeries a/k/a AS400.
TYPECTLL 27.129 Updates for CONTROL-D TYPE C User SMF record.
JCLDAYDS 27.127 Support for CONTROL-T for "daily dataset billing".
VMXGOPTR 27.124 Macro %TRIM() function removed from VMXGOPTR.
ASUM70PR 27.132 Revisions for missing values if IFL is last LPARNUM.
TYPE1415 27.116 Non-zero JFCB BLKSIZE set to zero if SMF14LBS=0.
TYPETMS5 27.111 New TMSLIB variable, support for multiple TMS cats.
MXGWPSV2 27.110 Circumventions support MXG execution under WPS 2.3.5.
COMPALL 27.109 Comparison of COMPALL under SAS and WPS.
Major enhancements added in MXG 27.04, dated May 27, 2009
This Version updates lots of DB2 stuff; the IFCID=225 variables are
now added to PDB.DB2STATS, so that one dataset now has all of the
DB2 Statistics variables from DB2STAT0, DB2STAT1, and DB2STAT4, and
for DB2 V8 sites, you can also tell MXG to add the T102S225 variables
to the PDB.DB2STATS dataset. See Change 27.097 text.
And READDB2 was revised to match its documentation, and to read only
the records that are needed for the IFCIDS= selection.
READDB2 27.097 Redesign IFCID=225 (DB2STAT4,T102S225) processing
TYPEDB2 27.097 Redesign IFCID=225 (DB2STAT4,T102S225) processing
TYPEDB2 27.086 Some DB2STATS QISE variables incorrectly deaccum'd.
IMACICOB 27.099 Optional Omegamon DB2 CICS/TS 3.2 times were wrong.
TYPE119 27.106 Support for z/OS 1.10 storage metrics in SMF 119.
TYPECIMS 27.107 Support for BMC'S IMF 4.4 (COMPATIBLE).
TYPEACF2 27.105 ACF2VR dataset enhanced, DB2 activity identification.
TYPE7072 27.089 Support for TYPE 72 Resource Delay Type Names R723RNx
TYPEBVIR 27.088 Support for TS7700/BVIR Microcode 1.5.
TYPEBVIR 27.104 BVIR TS7700 GMT times can be user-changed to LOCAL.
VMXGDUR 27.103 New INTERVAL=THREEMIN or TWOMIN are supported.
TYPE70PR 27.102 27.02-27.03. PARTNCPU missing, if last LPAR not z/OS.
TYPERMFV 27.100 RMF III ZRBLCP dataset "trashed" with z/OS 1.10 data.
TYPENMON 27.096 Nigel's Monitor MEM Object supported.
TYPETPMX 27.093 TYPETPMX variable JESNR now 7-digits, was 5 digits.
VMXGOPTR 27.092 SAS V8-ONLY: OVERFLOW HAS OCCURRED after SUMSTATB
VMXGOPTR 27.092 SAS V9.2-ONLY: NO MATCHING %IF FOR %THEN.
TYPETMO2 27.091 ASG TMON/CICS variables WTSCWTTM,WTSCWTCN reversed.
TYPENMON 27.087 NMONBBBP blank values and wrong labels corrected.
TYPEOMCI 27.085 ONDV datasets from subtype 203 had blanks for xTRAN.
VGETDDS 27.083 Concatenate PDB libs, dynamically allocate them.
Major enhancements added in MXG 27.03, dated May 4, 2009
ASUM70PR 27.076 ASUM70PR enhancement adds zIIP, zAAP, and IFLs plus.
ASUM70PR 27.074 Group Capacity ASUM70GC/GL wrong if multiple SYSTEMS.
TYPE83 27.067 Support for LDAP Auditing ID=83 Subtype=3 SMF record.
TYPEIMS7 27.078 Support for IMS Log 45X Interval Statistics record.
TYPEIMSA 27.078 Support for IMS Log 45X Interval Statistics record.
TYPEIMFL 27.078 Support for IMF+IMS 45X Interval Statistics record.
TYPEDCOL 27.082 Support for z/OS 1.10 DCDOVERA 32-bit already in MXG.
TYPE113 27.081 Support for APAR OA27623, CPU Speed, SM1132SP, added.
TYPENMON 27.080 Protection for inconsistent NMON data counters.
TYPEBVIR 27.077 BVIR variable GLIBSEQN can be ASCII or EBCDIC.
TYPESTC 27.072 VTCS subtypes of STC/STK USER SMF record updated.
VMXGSUM 27.071 VMXGSUM-using programs support DROPed variables.
TYPEXAM 27.070 Variable DESCR truncated in XMHSTMEM, changed.
TYPEULTM 27.069 Serena's Ultimizer user MV moved subtype location.
IMACICDU 27.068 Optional USERCHAR in CICSTRAN was limited to 200.
TYPE77 27.066 "Owner" variables incorrectly labeled as "Current".
Major enhancements added in MXG 27.02, dated Apr 13, 2009
Errors (Only in MXG 27.01) corrected in 27.02:
TYPEDCOL 27.057 MXG 27.01 ONLY. DCOLVOLS sizes WRONG by 1024 factor.
TYPE42 27.054 MXG 27.01 ONLY. STARTIME/ENDTIME/etc missing value.
Enhancements:
TYPE42 27.062 VSAM RLS "ABOVE THE BAR" statistics, & APAR OA25559.
TYPEEDGR 27.046 Major updates for RMM/EDGHSKP D,V,X records.
TYPEDCOL 27.047 Support for EAV (large volumes) final correction.
TYPECTCD 27.056 Support for Control-D "Decollating" SMF record.
TYPE102 27.059 Some SMF 102 IFCID=108 variables were not INPUT.
VMACSMF 27.058 SMF SUBTYPE GT 255 for BMC CICS subtype 2818/47874.
TYPEHURN 27.055 OBJECTSTAR Subtype 13 INPUT STATEMENT EXCEEDED error.
TYPE110 27.053 CICS SMF 110 Statistics STID=108 skipped data.
ANALDB2R 27.052 PMACC01 had blank values; time formats match DB2PM.
VMXGOPTR 27.051 %VMXGOPTR changed, CURRENT vs ORIGINAL value is used.
VGETSYSI 27.049 New %VGETSYSI gets (z/OS only) SYSTEM, SU_SEC values.
VMACDB2 27.045 DB2STATS QISTWFxx variables were incorrectly deaccum.
TYPEMWAI 27.043 HP OpenView on AIX RELEASE/SOFTWARE/SYSID wrong.
Major enhancements added in MXG 27.01, dated Mar 17, 2009
These two changes were delivered in re-dated MXG 26.26 of Feb 12:
READDB2 27.002 READDB2 might not create all datasets, in Feb refresh
RMFINTRV 27.001 Negative PCTCPUBY, corrected in Feb 12 refresh.
TYPE110 27.032 Support for CICS/TS 4.1.0 OPEN BETA (INCOMPATIBLE).
TYPE111 27.011 Support for CTG V7.2 (INCOMPAT, new RECID=7 error).
TYPE113 27.004 Support for SMF 113 Hardware Instrumentation Svc HIS.
TYPEDCOL 27.034 Support for EAV, Extended Address Volume devices.
TYPENTSM 27.038 Support for NTSMF/Performance Sentry 3.1.4 (MAJOR!).
TYPE114 27.003 Support for Tivoli Automation SMF 114 record.
TYPEULOP 27.029 Support for BMC's Ultra Op Product's User SMF record.
TYPETMO2 27.042 Support for ASG TMON for CICS V3.2 native records.
ANAL119 27.031 Sample TCP/IP analysis from IBM SMF ID=119 records.
TYPEVMXA 27.008 z/VM 5.2 RECORD ERROR SYTSYP/STORSP/STOSXP/PRCPRP.
BUILDPDB 27.005 PDB.SMFRECNT created to audit SMF record counts.
WEEKxxxx 27.005 Weekly logic enhanced to support nonexistent dataset.
MONTHxxx 27.005 Month logic enhanced to support nonexistent dataset.
ANALDB2R 27.012 DB2PM-like report selection by DATABASE enhancement.
UDB2GTF 27.015 Revised Support for processing DB2 GTF records.
TYPEDB2 27.018 DB2 V9 variables added by IBM or overlooked, added.
ANALDB2R 27.024 NOT SORTED ERROR if only PMACC04 was requested.
TYPE42 27.016 Subtype 25 OLDMEMNM/NEWMEMNM were misaligned.
TYPE42 27.027 TYPE42DS RESPTIME,MAXRSPTM,MAXSRVTM formats all same.
TYPENMON 27.028 NMON record 'VM' support for both z/VM, and Intel.
TYPENMON 27.028 IHDRNMON exit permits NMON record selection.
TYPE88 27.026 SMF88LTD timestamp wrong as GMT offset misapplied.
MANY 27.014 SAS option TRANSCODE=NO, &MXGNOTRA/&MXGNOTRB added.
JCLIMSL6 27.033 Setting MACRO _IMSVERS externalized to JCL example.
TYPEXAM 27.030 Only the last MDISK was kept in XAMDEV.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
MXG 27.27 executes best with SAS V9.2, or with SAS V9.1.3 with
Service Pack 4, on any supported SAS platform.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS Decompression Infile Exit.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2 nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level B" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. PLEASE INSTALL V9.2 ASAP,
FOR BOTH OF US, TO AVOID FIXED PROBLEMS. MXG Software has not
executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
one of those listed SAS versions, but any of those data libraries
can be read or updated by any of those versions.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG.
SAS Data Libraries are compatible for V8.2, V9.1.3, and V9.2.
V9.2-created "PDBs" can be read/written by SAS V8.2 or V9.1.3,
and vice versa.
MXG Versions 26.03+ execute with SAS V9.2 with NO (new) WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) is required
to be completely safe. No earlier Version 8's were supported.
BUT, PLEASE INSTALL V9.x ASAP, FOR BOTH OF US. V8.2 IS ARCHAIC.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG QA tests have executed on z/OS with SAS V9.1.3 and V9.2 and
also both V9.1.3 and V9.2 on Windows XP.
(I can no longer run QA tests with "archaic" SAS Version 8.2.)
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.4 requires MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for "MXG Support for WPS Software"
IV. MXG Version Required for Hardware, Operating System Release, etc.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 TYPE 0 Correction Dec 3, 2009 *27.10
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
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
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
MQ Series 7.0 (No Changes) ??? ??, 2009 23.23
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
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 20.04
The Monitor for DB2 Version 4.0 22.10
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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
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
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
V. Incompatibilities and Installation of MXG 27.27.
1. Incompatibilities introduced in MXG 27.27:
a- Changes in MXG architecture made between 27.27 and prior versions
that can introduce known 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 JCLINST9 for
SAS Version 9.1.3 (JCLINST8 for now-archaic SAS Version 8.2).
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 27.27 after MXG 26.26:
Dataset/
Member Change Description
ALOCGOVO 27.299 Allocate GDG's with GOOVOO to minimize DSENQUEUE.
ANAL119 27.031 Sample TCP/IP analysis from IBM SMF ID=119 records.
ANAL307X 27.346 Analysis compares Hourly CPU in 70, 72, 30 interval.
ANALCNCR 27.203 PDB.ASUMTALO had too few obs due to ANALCNCR error.
ANALCNCR 27.220 MXG 27.06-27.07. Failed if multiple INDATA= datasets.
ANALDB2R 27.012 DB2PM-like report selection by DATABASE enhancement.
ANALDB2R 27.023 One of several updates to ANALDB2R since 26.26.
ANALDB2R 27.024 NOT SORTED ERROR if only PMACC04 was requested.
ANALDB2R 27.052 PMACC01 had blank values; time formats match DB2PM.
ANALDB2R 27.131 DB2PM-like STATISTICS LONG report updated.
ANALDB2R 27.172 Many tests IF x NE 0 replaced with IF x GT 0.
ANALDB2R 27.238 AUDIT report revisions, reduced processing time.
ANALDB2T 27.223 "Top" DB2 Report ranks resource for corr,auth ids.
ANALJOBE 27.332 Analysis of Job Events revised, JESNR test removed.
ANALRMFR 27.198 ANALRMFR wrote TYPE7xxx to //PDB with PDBOUT= null.
ANALRMFR 27.333 RMF Summary Report (REPORT=SMRY) was incorrect.
ANALZIPU 27.137 Analysis of zIIP used by JOB/PROGRAM/SRVCLASS etc.
ANALZPCR 27.147 SCP too short for z/OS 1.10, wrong if multiple SCPs.
ASMIMSL6 27.121 Assembly error USING introduced in Change 27.078.
ASMTAPEE 27.348 ASMTAPE ML-46 enhancements to optional SYSLOG data.
ASMTAPEE 27.300 ASMTAPE ML-45 enhancements to TMNTnnnn messages.
ASUM70GO 27.268 Example summarizes PDB.TYPE72GO, changing interval.
ASUM70PR 27.074 Group Capacity ASUM70GC/GL wrong if multiple SYSTEMS.
ASUM70PR 27.076 ASUM70PR enhancement adds zIIP, zAAP, and IFLs plus.
ASUM70PR 27.132 Revisions for missing values if IFL is last LPARNUM.
ASUM70PR 27.214 ASUM70PR STARTIME could be early by an interval unit.
ASUM70PR 27.292 First LPAR had missing values in LPSHAR/TOTSHARE.
ASUM70PR 27.294 IFL obs in ASUM70LP/ASUMCELP missing STARTIME fixed.
ASUM70PR 27.344 Variables LPCTBY/PCTLPBY missing for PHYSICAL LPAR.
ASUMMIPS 27.262 MSU/MIPS for zIIPs and zAAPs added to CPs summary.
ASUMMIPS 27.305 ASUMMIPS now inflates MSU by system CAPTURE RATIO.
ASUMMIPS 27.327 DUR70 created with actual vs expected DURATM.
ASUMTALO 27.203 PDB.ASUMTALO had too few obs due to ANALCNCR error.
ASUMTAPE 27.160 EVENTIME dropped from PDB.ASUMTAPE MXG 26.03, fixed.
ASUMTAPE 27.181 Support for VOLSER='SCRTCH' from MXGTMNT monitor.
BLDSMPDB 27.112 SUBSTR() Function Error, allocation revisions.
BUILDPDB 27.001 New PDB.SMFRECNT dataset summarizes WORK.ID.
BUILDPDB 27.005 PDB.SMFRECNT created to audit SMF record counts.
BUILDPDB 27.213 HFS/zFS EXCPS are in EXCPTOTL, new USSEXCPS count.
BUILDPDB 27.220 MSOUNITS,SERVICE corrected to always be LENGTH 8.
CICINTRV 27.274 CICS DISPATCH INTERVAL LARGER THAN INTERVAL fixed.
COMPALL 27.109 Comparison of COMPALL under SAS and WPS.
CONFIGxx 27.294 MXG 27.08-27.09 only. Option MAUTOLOCDISPLAY removed.
DAILYDSN 27.246 Variables DSN DSNBACTV STPNAME had UNINIT messages.
DAILYDSx 27.287 MXG 27.09 only. TMC= should have been TAPEDATA=.
DB2 27.158 Support for UIFCIDS=YES, all "%U" DB2 fields revised.
EXPDBINC 27.334 MXG 27.10 ONLY. %UTILBLDP option USERADD= fails.
FORMATS 27.243 OPTIONS NOCHARCODE reset at end of FORMATS.
GRAFWRKX 27.245 zIIPs and zAAPs added to SAS/GRAPH hourly workloads.
IMACICDU 27.068 Optional USERCHAR in CICSTRAN was limited to 200.
IMACICOB 27.099 Optional Omegamon DB2 CICS/TS 3.2 times were wrong.
IMACICUA 26.019 CICS User fields supported in IMACICUA/UB/UC/UD
JCL40GIG 27.316 JCL example to split/parallelize BUILDPDB job.
JCLCIDB2 27.345 UTILBLDP JCL example for CICS, DB2, and ASUMUOW+.
JCLDAYDS 27.127 Support for CONTROLT for "daily dataset billing".
JCLIMSL6 27.033 Setting MACRO _IMSVERS externalized to JCL example.
MANY 27.014 SAS option TRANSCODE=NO, &MXGNOTRA/&MXGNOTRB added.
MANY 27.277 Support for USER=DDNAME, "WORK" now "&MXGWORK".
MONTHxxx 27.005 Month logic enhanced to support nonexistent dataset.
MRGDB2 27.321 MERGE of PDB.DB2ACCT and PDB.DB2ACCTP for DB2PARTY
MXGSASxx 27.108 &NULLPDS &LOAD &SASAUTOS symbolics REMOVED from JCL.
MXGWPSV2 27.110 Status of testing MXG 27.04 with WPS 2.3.5.
READDB2 27.002 READDB2 might not create all datasets, in Feb refresh
READDB2 27.002 READDB2 might not create all datasets, in Feb refresh
READDB2 27.097 Redesign IFCID=225 (DB2STAT4,T102S225) processing
READDB2 27.150 MXG 27.05. COPYONLY option didn't include 102s.
READDB2 27.169 27.04-27.06, zero obs in all T102Snnn datasets.
READDB2 27.169 MXG 27.04-27.06. T102Snnn datasets not populated.
READDB2 27.272 READDB2 support for WANTONLY now works.
READDB2 27.322 IFCIDS= features (STATS, DB2ACCT, Dataset Name, etc)
READDB2 27.351 READDB2 didn't always invoke its EXdddddd members.
RMFINTRV 27.001 Negative PCTCPUBY, corrected in Feb 12 refresh.
RMFINTRV 27.178 Summary STARTIME now exact, based on SMF70GIE-DURATM.
RMFINTRV 27.214 RMFINTRV STARTIME could be early by an interval unit.
RMFINTRV 27.218 SMF70LAC was maximum value rather than average.
RMFINTRV 27.252 Format missing for many duration variables, fixed.
RMFINTRV 27.252 Formats for durations added.
SPIN 27.119 Doc. Sort Order to import EBCDIC sorted SPIN library.
TIMETABL 27.115 %LET MXGTIM59=YES is no longer required for SYNC59.
TYPE0 27.325 z/OS 1.11 Update: TYPE 0 Corrected.
TYPE102 27.059 Some SMF 102 IFCID=108 variables were not INPUT.
TYPE102 27.131 DB2 T102S106 dataset updates.
TYPE102 27.132 IFCID=22 with truncated names INPUT STATEMENT EXCEED.
TYPE102 27.162 Support BMC APPTUNE SQL SMF 102 IFCIDs 8004x-8136x
TYPE110 27.032 Support for CICS/TS 4.1.0 OPEN BETA (INCOMPATIBLE).
TYPE110 27.053 CICS SMF 110 Statistics STID=108 skipped data.
TYPE110 27.200 Support for CICS/TS 4.1 GA updates/documentation.
TYPE110 27.245 OTRANNUM right with IMACEXCL, wrong in VMAC110.
TYPE110 27.260 TRANSPARENT UNCOMPRESS OF CICS/TS 3.2 RECORDS!!!
TYPE110 27.270 CICS STID=115 should not exist.
TYPE110 27.274 SORT Order for CICFCR changed, A17DSIXP/DTRDS fixed.
TYPE110 27.303 CICS Total I/O and Total Other Wait updates.
TYPE110 27.329 MXG 27.10, CICIDNNR NOT FOUND, only if _S110ST used.
TYPE111 27.011 Support for CTG V7.2 (INCOMPAT, new RECID=7 error).
TYPE112 27.358 Support for OMEGAMON ONDV SMF 112 SUBTYPE 0100X
TYPE113 27.004 Support for SMF 113 Hardware Instrumentation Svc HIS.
TYPE113 27.081 Support for APAR OA27623, CPU Speed, SM1132SP, added.
TYPE114 27.003 Support for Tivoli Automation SMF 114 record.
TYPE116 27.157 WQGETJCE/WQPUTJCE/etc variables not divided by 4096.
TYPE116 27.235 Six datetimes are now converted to LOCAL, were GMT.
TYPE117 27.022 Variables added to S117NODE to match up to S117FLOW.
TYPE119 27.106 Support for z/OS 1.10 storage metrics in SMF 119.
TYPE119 27.153 Variable NTBTRNBE input now as count and not a time.
TYPE120 27.255 SM1209 RETAINED, SM1209FI/EV corrected.
TYPE120 27.255 WAS SMF1209FI/EV (CPU/Elapsed Times) corrected.
TYPE1415 27.116 Non-zero JFCB BLKSIZE set to zero if SMF14LBS=0.
TYPE1415 27.148 Support for APAR OA29428, identifies who closed file.
TYPE1415 27.361 MXG 27.06-27.11. BUFNO always zero due to typo.
TYPE16 27.211 Support for new z/OS 1.10 DFSORT variables.
TYPE30 27.122 Support for APAR OA26832 expands Service Unit fields.
TYPE42 27.016 Subtype 25 OLDMEMNM/NEWMEMNM were misaligned.
TYPE42 27.027 TYPE42DS RESPTIME,MAXRSPTM,MAXSRVTM formats all same.
TYPE42 27.054 MXG 27.01 ONLY. STARTIME/ENDTIME/etc missing value.
TYPE42 27.062 VSAM RLS "ABOVE THE BAR" statistics, & APAR OA25559.
TYPE42 27.155 Type 42-16 STOPOVER, 42-21/24 ICHRUTKN protect, APAR.
TYPE42 27.291 Variable S42DSRDD incorrect by factor of 10**6.
TYPE7072 27.010 SMF70CIX, CPU Pool Number, output in PDB.TYPE70PR.
TYPE7072 27.089 Support for TYPE 72 Resource Delay Type Names R723RNx
TYPE7072 27.149 Labels for Counts of ZIP, IFA, CPs, clarified.
TYPE7072 27.205 Doc only. PDB.TYPE70PR LCPUPDTM GT SMF70ONT happens.
TYPE7072 27.217 Blank SMF70CIN in PDB.TYPE70PR if last LPAR offline.
TYPE7072 27.317 Support for APAR OA28670 RMF 70 Crypto Express3
TYPE70PR 27.102 27.02-27.03. PARTNCPU missing, if last LPAR not z/OS.
TYPE70PR 27.178 Summary STARTIME now exact, based on SMF70GIE-DURATM.
TYPE74 27.249 R747PAVG AVERGAGE FRAME PACING matches RMF report.
TYPE74 27.263 R744FNAM not in TYPE74DU, ITRM sites need update.
TYPE74 27.287 MXG 27.09 only. DEBUGGING PUT statement removed.
TYPE77 27.066 "Owner" variables incorrectly labeled as "Current".
TYPE80A 27.017 Undecoded NOHOME/NOPROGRAM in TOKDANAM supported.
TYPE80A 27.241 RACFEVNT=79 EXTLNTYP=379 INPUT EXCEEDED error.
TYPE80A 27.250 Protection for UNKNOWN TOKDANAM and RDEFINE CFIELD.
TYPE80A 27.331 Protection for unknown TOKDANAM eliminates STOPOVER.
TYPE80A 27.357 TYPE8066 dataset enhanced.
TYPE82 27.330 SMF82PDK, SMF82RKN, SMF82PTA increased, corrected.
TYPE83 27.067 Support for LDAP Auditing ID=83 Subtype=3 SMF record.
TYPE85 27.138 z/OS 1.10 OAM record INPUT EXCEEDED RECORD LENGTH.
TYPE85 27.196 Heuristic in Change 27.138 did not correct EXCEEDED.
TYPE88 27.026 SMF88LTD timestamp wrong as GMT offset misapplied.
TYPE92 27.154 Variable SMF92PPN blank in TYPE9201, was not INPUT.
TYPE92 27.204 Change 27.154 did not correct missing path section.
TYPEACF2 27.105 ACF2VR dataset enhanced, DB2 activity identification.
TYPEACF2 27.258 Support for Subtype 'O' OPENEDITION record.
TYPEBVIR 27.077 BVIR variable GLIBSEQN can be ASCII or EBCDIC.
TYPEBVIR 27.088 Support for TS7700/BVIR Microcode 1.5.
TYPEBVIR 27.104 BVIR TS7700 GMT times can be user-changed to LOCAL.
TYPEBVIR 27.163 BVIR PnCHRD/VDRD/CHRD converted to bytes, MGBYTES.
TYPECDC 27.324 Support for IBM's InfoSphere Change Data Capture CDC
TYPECIMS 27.107 Support for BMC'S IMF 4.4 (COMPATIBLE).
TYPECIMS 27.176 BMC PTF BQI0695 corrects overlaid DBD segments.
TYPECIMS 27.176 Support for IMF 4.4 was incorrect for TRNxxxxx vars.
TYPECIMS 27.230 Variable LASTCLAS in IMF CIMSPROG incorrectly INPUT.
TYPECTCD 27.056 Support for Control-D "Decollating" SMF record.
TYPECTLL 27.129 Updates for CONTROL-D TYPE C User SMF record.
TYPEDB2 27.018 DB2 V9 variables added by IBM or overlooked, added.
TYPEDB2 27.021 QPAC flag variables were not reset.
TYPEDB2 27.045 DB2STATS QISTWFxx variables were incorrectly deaccum.
TYPEDB2 27.086 Some DB2STATS QISE variables incorrectly deaccum'd.
TYPEDB2 27.097 Redesign IFCID=225 (DB2STAT4,T102S225) processing
TYPEDB2 27.161 Incorrect QXPK values in DB2ACCTP, DB2 V9 only.
TYPEDB2 27.17x Corrected, misspelled DB2 variables.
TYPEDB2 27.188 MXG 27.04-27.06 NOT SORTED DB2STAT0/DB2STAT1.
TYPEDB2 27.207 MXG 27.07. QSSTCONT,QSSTCRIT re-de-accumulated.
TYPEDB2 27.232 TMON/DB2 created SMF 101 St 0 OFFQLAC invalid.
TYPEDB2 27.319 Support for QMDAPTYP='JCC' (Type 4 JDBC Driver).
TYPEDB2 27.326 Variable QDSTQCIT now not deaccumulated.
TYPEDCOL 27.034 Support for EAV, Extended Address Volume devices.
TYPEDCOL 27.047 Support for EAV (large volumes) final correction.
TYPEDCOL 27.057 MXG 27.01 ONLY. DCOLVOLS sizes WRONG by 1024 factor.
TYPEDCOL 27.082 Support for z/OS 1.10 DCDOVERA 32-bit already in MXG.
TYPEDCOL 27.152 MXG 27.01-27.05. DCOLLECT UBALLSP is missing value.
TYPEDCOL 27.212 Support for APAR OA30006, 8-byte DCOLDSET fields.
TYPEEDGR 27.046 Major updates for RMM/EDGHSKP D,V,X records.
TYPEEDGR 27.251 RMM Dates - American/Euro/ISO/Julian - all supported.
TYPEEDGR 27.251 Support for all four RMM Date Formats
TYPEEDGR 27.339 RVTxERR RVPxERR variables now numeric, incompatible.
TYPEEDGR 27.349 Support for RMM APAR OA24025 RDDESKEY.
TYPEEDGR 27.349 Support for RMM APAR OA28930, RDBLKCNT/RDTOTAL.
TYPEEREP 27.006 Truncated variables increased, SDWA fully decoded.
TYPEHBUF 27.247 FLAG1 tests for HyperBuf optional segments revised.
TYPEHURN 27.055 OBJECTSTAR Subtype 13 INPUT STATEMENT EXCEEDED error.
TYPEIMFL 27.078 Support for IMF+Log 45X Interval Statistics record.
TYPEIMS7 27.078 Support for IMS Log 45X Interval Statistics record.
TYPEIMSA 27.078 Support for IMS Log 45X Interval Statistics record.
TYPEIMSA 27.354 MXGNOTE now prints the value of _IMSVERS on the log.
TYPEIOO 27.189 Support for Serena's StarTool IOO Product SMF.
TYPEITRF 27.177 Variable RECTOK was truncated to 12 bytes.
TYPEMWAI 27.043 HP OpenView on AIX RELEASE/SOFTWARE/SYSID wrong.
TYPENDM 27.022 NDMRTYPE='IK' record is now output in NDMDT dataset.
TYPENDM 27.222 Support for NDM-CDI NDMRTYPE 'SC' and 'S2' subtype.
TYPENMON 27.028 IHDRNMON exit permits NMON record selection.
TYPENMON 27.028 NMON record 'VM' support for both z/VM, and Intel.
TYPENMON 27.080 Protection for inconsistent NMON data counters.
TYPENMON 27.087 NMONBBBP blank values and wrong labels corrected.
TYPENMON 27.096 Nigel's Monitor MEM Object supported.
TYPENMON 27.110 COUNTW() now used only with SAS V9, DO Loop for V8.
TYPENMON 27.180 Support for CPU_PHYSICAL,CPU_ENTITLED TOPAS objects.
TYPENTSM 27.038 Support for NTSMF/Performance Sentry 3.1.4 (MAJOR!).
TYPENTSM 27.184 Support for 13 VMWARE objects captured by NTSMF.
TYPENTSM 27.312 MXG 27.09 only. NTSMF Processing failed, RECFM.
TYPEOMCI 27.085 ONDV datasets from subtype 203 had blanks for xTRAN.
TYPEOMCI 27.113 OMCI INTR Subtype 200 RECSUBTYP 4 INPUT EXCEEDED.
TYPEOSEM 27.221 Support for zOSEM Operating System Environment Mgr.
TYPEPROS 27.295 PRO/SMS SMF record misalignment corrected.
TYPEQACS 27.134 More updates for IBM i, i5/OS, iSeries a/k/a AS400.
TYPEQACS 27.256 Support for QACSLPAR dataset.
TYPERMFV 27.100 RMF III ZRBLCP dataset "trashed" with z/OS 1.10 data.
TYPERMVF 27.120 RMF III z/OS 1.10 new ASI fields (INCOMPATIBLE).
TYPESRMH 27.340 SRM Thales Security PTF SL24010 INCOMPATIBLE support.
TYPESTC 27.072 VTCS subtypes of STC/STK record updated.
TYPESYNC 27.289 Support for CPUZIPTM added in SYNCSORT SMF records.
TYPETIMS 27.298 Expensive algorithm to uncompress ASG/Landmark data.
TYPETMDB 27.209 TMON/DB2 BF record SQL text BF0142RL corrected.
TYPETMDB 27.259 Support for TMON for DB2 BA/BJ/BK/BL/BM subtypes.
TYPETMMQ 27.145 Support for TMON for MQ record 'QA' (APPLICATION).
TYPETMNT 27.009 MSGID IEF233D supported, no DSNAME in SYSLOG doc'd.
TYPETMNT 27.336 SYSLOG message text size increased to 32384 bytes.
TYPETMO2 27.042 Support for ASG TMON for CICS V3.2.
TYPETMO2 27.091 ASG TMON/CICS variables WTSCWTTM,WTSCWTCN reversed.
TYPETMO2 27.215 TMON/CICS Version 3.1 INPUT EXCEEDED on 'TI' record.
TYPETMS5 27.111 New TMSLIB variable, support for multiple TMS cats.
TYPETMS5 27.168 MXG 27.05-27.06. _KTMSTMS dropped, impacts ITRM.
TYPETMS5 27.190 TMS.TMS DEVTYPE blank for 3590 and 3592 devices.
TYPETMVT 27.347 TMON/VTAM "SI" record Interval variables now INPUT.
TYPETPMX 27.093 TYPETPMX variable JESNR now 7-digits, was 5 digits.
TYPEULOP 27.029 Support for BMC's Ultra Op Product's User SMF record.
TYPEULTM 27.069 Serena's Ultimizer user MV moved subtype location.
TYPEVMXA 27.008 z/VM 5.2 RECORD ERROR SYTSYP/STORSP/STOSXP/PRCPRP.
TYPEVMXA 27.156 Support for z/VM 6.1.0 in MXG 27.01+; no new data.
TYPEVMXA 27.156 z/VM 6.1 support is in MXG 27.01 or later.
TYPEVMXA 27.264 z/VM MONWRITE example processes only USER domain.
TYPEXAM 27.030 Only the last MDISK was kept in XAMDEV.
TYPEXAM 27.070 Variable DESCR truncated in XMHSTMEM, changed.
TYPEXAM 27.151 XAM TCP record INPUT STATEMENT EXCEEDED error.
TYPEXAM 27.216 Variable SYTLPNAM restored kept in XAMSYT dataset.
TYPEXAM 27.281 Updates/corrections/ for XAM Version 3.7.
UDB2GTF 27.015 Revised Support for processing DB2 GTF records.
VGETDDS 27.083 Concatenate PDB libs, dynamically allocate them.
VGETDDS 27.248 Logic revised when DDNAMES= syntax is used.
VGETDDS 27.310 New DATEJUL= created DSNAMES with Julian YYYDDD.
VGETDDS 27.330 New DATEJUL= correctly generates julian dsnames.
VGETDDS 27.359 WAIT=N option protects for DSNAME already in use.
VGETOBS 27.237 Enhancement if no DDNAME argument.
VGETSYSI 27.049 New %VGETSYSI gets (z/OS only) SYSTEM, SU_SEC values.
VMACDB2 27.131 DB2STATS DIF() or no-DIF() corrections.
VMACEDGR 27.128 Syntax error after Change 27.046 (GT. GT.).
VMACORAL 27.306 Support for restructured ORACLE SMF records.
VMACSMF 27.058 SMF SUBTYPE GT 255 for BMC CICS subtype 2818/47874.
VMACSMF 27.341 WARNING: SUBTYPE GT 255 message now not defaulted.
VMXGALOC 27.355 NOWAIT added, create/allocates are now conditional.
VMXGCNFG 27.356 The standard SAS JCL Proc can be used for MXG.
VMXGDUR 27.214 New FLORCEIL=FLOOR/CEIL argument for begin/end calc.
VMXGDUR 27.214 SYNC59=YES now default with FLOOR, always safe.
VMXGDUR 27.308 SYNC59-NO/VMXGDUR/VMXGSUM (final?) enhancements.
VMXGOPTR 27.051 %VMXGOPTR changed, CURRENT vs ORIGINAL value is used.
VMXGOPTR 27.092 SAS V8-ONLY: OVERFLOW HAS OCCURRED after SUMSTATB
VMXGOPTR 27.092 SAS V9.2-ONLY: NO MATCHING %IF FOR %THEN.
VMXGOPTR 27.124 Macro %TRIM() function removed from VMXGOPTR.
VMXGSET 27.343 VMXGSET permits multiple datasets with APPEND=YES.
VMXGSUM 27.071 VMXGSUM-using programs support DROPed variables.
VMXGSUM 27.234 Revision to eliminate OUTCODE= argument sometimes.
VMXGTAPE 27.114 "Tape-aware" programs now support LIBNAME allocation.
WEEKxxxx 27.005 Weekly logic enhanced to support nonexistent dataset.
WPS 27.239 WPS 2.4 GA has been tested, requires MXG 27.09.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 27.
====== Changes thru 27.361 were in MXG 27.27 dated Jan 20, 2010========
Change 27.361 MXG 27.06-27.11. Variable BUFNO in TYPE1415 was always
VMAC1415 zero; the label in the comment for SMF14ABD, added by
Jan 19, 2009 Change 27.148, had a / instead of */ at the end of that
line, which swallowed (without error) the IF BUFNO test.
Note that even when fixed, BUFNO=0 occurs frequently for
non QSAM files; for example, TYPE1415 records for SAS
data libraries always have BUFNO=0 (because the access
method for SAS Data Libraries is EXCP Access Method).
Thanks to Tom Parquette, AXA Technology Services, USA.
Thanks to ???, ???, CANADA.
Change 27.360 Fixed in MXG 27.10, but in MXG 27.09, PDB.ASUM70PR could
VMXG70PR have PCTCPUBY much greater than 100%, for systems with
Jan 19, 2009 IFL engines, if the IFL also has the highest LPARNUM.
Similar to Change 27.123, fixed by Change 27.294/325,
but invalid values in PCTCPUBY were not mentioned in
the text of those changes.
This is only change text; no code was changed.
Thanks to Tee Brown, Blue Shield Blue Cross of South Carolina, USA.
Change 27.359 The new WAIT=N argument in %VGETDDS causes allocations to
VGETDDS be WAITed for N minutes if the DSNAME is already in use.
Jan 19, 2009 SAS tests every 15 seconds and if the DSNAME is freed in
those N minutes, the allocation proceeds as normal.
Thanks to George Pandzik, USAA, USA.
Change 27.358 Support for OMEGAMON ONDV SMF 112 SUB-SUBTYPE '0100'X,
EX112USD optional USREVNT1 or User Function clock/count section.
EX112UST dddddd Dataset Description
IMAC112 112USD T112USRD USREVNT1 Detail
VMAC112 112UST T112USRT USREVNT1 Totals
VMXGINIT In Omegamon/CICS modules KC2GLB or KC2GLBOL, in the
Jan 19, 2010 RKANPARU or RKANPARM library, you can define up to 10
Jan 29, 2010 "User Functions" that can populate the 10 clock/counter
pairs in this new segment. You define the Function Names
you plan to use, and CLOCK START MISC and CLOCK STOP MISC
will accumulate the MISC duration and count of starts in
the first pair. Names MISC, Sybase, Tablebase are used
in this first example, so those names are used to label
the first three sets of detail/total count/clocks, and
only the first three sets are kept by default. If you
create more User Function data, you can use the _K112UST
and K112USD macros to keep more than three, and you can
use the EX112UST exit to change the existing three or to
add new labels for the other counters.
Thanks to Henry Steinhauer, Northwestern Mutual, USA.
Change 27.357 -Some (new) TRANSLATE() functions had '00' or '80' where
VMAC80A '00'x or '80'x should have been specified.
Jan 17, 2010 -TYPE8066 dataset is enhanced with variables from RACFTYPE
6, 318, 319, and 320.
Thanks to Matthew T. Chappell, Queensland Dept. Transport, AUSTRALIA.
Change 27.356 -The standard SAS JCL procedure can now be used for MXG on
VMXGCNFG z/OS. You do not need a separate MXGSASVn JCL procedure;
MXGNAMES instead, use this JCL example (in member JCLMXG), after
JCLMXG you EDIT the DSNAMES of your MXG Source, MXG "USERID" and
CONFIMXG MXG Formats datasets into your MXGNAMES member in your
Jan 17, 2010 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.
There can NOT be a LIBRARY DD in JCL with CONFIMXG, but
you can have a USER FORMAT library. The CONFIMXG member
%INCLUDEs MXGNAMES and then %INCLUDEs VMXGCNFG from the
&MXGSOURC path and then runs the %VMXGCNFG %macro.
The MXGNAMES member defines MXGFORMT and MXGFORMU and
VMXGCNFG LIBNAME-allocates MXGFORMT to LIBRARY LIBREF and
LIBNAME-allocates MXGFORMU to the USRFORMT LIBREF/DDNAME.
If both MXGFORMT and MXGFORMU are specified in the
MXGNAMES then the SAS system option FMTSEARCH is set:
OPTIONS FMTSEARCH=(USRFORMT LIBRARY)
so the user's format library is searched first.
Member JCLINSTL has the example JCL for ALOCUSID and FORMATS.
Both of those examples use MXGSAS94 JCL Procedure to create FORMATS,
but sites with National Language Support, should consider CONFIMXG
which protects for a future SAS version in which the NLSCOMPATMODE
option will be removed. CONFIMXG uses your standard site's SAS JCL
procedure and options:
// EXEC SAS94,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
But to create or update your FORMATS library with CONFIMXG:
a. The DSNAME of that format library must be named in MXGNAMES
b. There must be no //LIBRARY DD in the JCL of this job step.
c. You must use this syntax in the SYSIN for a new FORMATS:
// EXEC SAS94,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
//SYSIN DD *
LIBNAME LIBRARY CLEAR;
LIBNAME LIBRARY 'MXGV3603.FORMATS'
DISP=(NEW,CATLG)
SPACE=(CYL(10,3))
UNIT=SYSDA;
or use DISP=OLD to replace your existing formats library.
Thanks to Rich Anderson, SAS Institute Technical Support, USA.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 27.355 For execution under Windows, the unconditional create of
VMXGALOC existing directories or the delete of non-existent ones
Jan 17, 2010 caused popups that delay jobs until the popup is cleared.
An OPTIONS NOXWAIT was relocated around the TREND dataset
allocations, which will eliminate the popup messages, but
the creations/deletions are also now done in conditional
tests, now that we know these Windows commands exist:
This command tests if a folder exists before trying to
delete its files
If exist "m:\asdf\fdsa" del /q "m:\asdf\fdsa\*.*"
and this command makes sure a folder doesn't exist
before trying to create it:
If not exist "m:\asdf\asdf" md "m:\asdf\asdf"
Thanks to Jim Quigley, ConEd, USA.
Change 27.354 An MXGNOTE now prints the value of _IMSVERS on the log of
IMACIMSA the TYPEIMSA and TYPEIMSB steps of the JCLIMSL6 job. If
JCLIMSL6 IMS V9 records are read with _IMSVERS set to 10, an 08x
TYPEIMSA record is dumped with INVALID YYYY error; in V9, the YYYY
TYPEIMSB is located byte 81, but with _IMSVERS of 10, MXG tries to
Jan 15, 2010 to read the YYYY starting in byte 101. Before MXG 27.01
and Change 27.033, _IMSVERS was set either in IMACIMSA or
in your IMACKEEP, but now its value is set with statement
%LET MACKEEP= MACRO _IMSVERS 10.0 % ;
in the //SYSIN test in JCLIMSL6 (twice), so that you do
NOT have to EDIT IMACIMSA/IMACKEEP to define _IMSVERS.
This change just adds that diagnostic MXGNOTE so you can
see the actual value, if you should also see a hex dump!
Comments were revised to document this change.
Thanks to Douglas G. Wells, First National Bank of Omaha, USA.
Change 27.353 While I expected RMFINTRV would be used to create a small
VMXGRMFI number of "WORKnn" workloads, like 20 or so, for ease in
Jan 15, 2010 consolidation of scores of Service/Reporting Class into
logical workloads, RMFINTRV can now be created with up to
999 sets of "WORKnnn" variables, and also supports up to
9999 Service and Reporting Classes per Workload.
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 27.352 Variable SMF42JOQ was incorrectly "spelled" with a zero
VMAC42 instead of an "oh".
Jan 12, 2010
Thanks to Ambat Ravi Nair, CitiGroup, SINGAPORE.
Change 27.351 -READDB2 didn't invoke the EXdddddd member when selection
READDB2 generated an _Edddddd macro with only OUTPUT _Wdddddd,
Jan 12, 2010 causing any new variables you created in your tailored
EXdddddd to be not created. READDB2 now always %INCLUDEs
the EXdddddd member in its generated MACRO _Edddddd text.
EXCEPT: The EXPDBACB exit is NEVER called when READDB2
was asked to create DB2ACCTB, because the MXG EXDB2ACB
does NOT output DB2ACCTB (because of potential size), and
if READDB2 calls your tailored EXDB2ACB that did output,
then we would output DB2ACCTB twice.
-Logic for selection with DB2xxxx=AAAA/BBBB/CCCC/DDDDD
was corrected and simplified so it always works as doc'd.
-PROC COPY when PDBOUT= is specified only copies DB2 data
(and not any other datasets that happened to be in WORK).
Thanks to Raff Rushton, IBM Global Services, USA.
Change 27.350 This 1994 example analysis of "bands" of Usage is updated
ANALUSAG to use TYPE72GO instead of TYPE72 and an example JCL was
Jan 12, 2010 added in the comments.
Thanks to R. Wells, American General Finance, USA.
Change 27.349 Support for RMM APAR OA28930 which relocates the fields
VMACEDGR RDBLKCNT and RDTOTAL and expands them to 20 (EBDCIC) NUM
Jan 12, 2010 charaters in the DEXT and XEXT records.
-Support for RMM APAR OA24025 which adds fields RDBESKEY
(DEXT) and XDBESKEY (XEXT) with the CA Tape Encryption
Key value.
Thanks to John Grasing, MetLife, USA.
Change 27.348 The Optional SYSLOG Message Capture in MXGTMNT Tape Mount
ASMTAPEE Monitor program expected a maximum of 255 lines in a
Jan 12, 2010 multi-line Console Message (see Change 27.336 text), but
HASP636 message caused an SVC DUMP "MXG Monitor Extension
Subtask Abend" with its 1541 lines! This update, ML-46,
avoids the SVC Dump by skipping messages with over 255
lines, but is only a circumvention; once we can create a
similar large message on our test system, so we can see
the control block structure, we will create an ML-47
update that will support any multi-line console message.
Thanks to Beau Chavis, Bank of America, USA.
Thanks to Skip Abadie, Bank of America, USA.
Change 27.347 TMON/VTAM "SI" record Interval variables were not all
VMACTMVT input; I apparently had an incorrect DSECT or misread it.
Jan 8, 2010
Thanks to Paul Volpi, UHC, USA.
Change 27.346 Analysis of Hourly CPU Times in MXG TYPE70, TYPE72GO, and
ANAL307X SMFINTRV datasets (or in ITRM XTY70, XTY72GO, & XSMFINT)
Jan 14, 2009 to compare times captured in LPAR Dispatch and Effective,
Feb 22, 2010 captured in Service Classes, and captured in SMF Interval
Address Space records. Two reports, one BY SYSTEM and
one with detail BY SYSTEM SRVCLASS are produced.
The identification of the "Hour" of RMF and SMF Interval
observations is not straightforward; you must start with
the "projected interval end time" SYNCTIME/SMF70GIE and
then subtract from it to get the STARTHOUR, and the value
to subtract is different if you have SYNC(59) specified
in SMFPRMxx instead of the recommended SYNC(0) option.
Note: MXG has ALWAYS recommended SYNC(0) so that RMF
and SMF interval records are written at 00/15/30/45 to
create clean, comparable intervals. But if you still
have MICS, then you are unfortunately stuck with using
SYNC(59) to write at 14/29/44/59 minutes, because MICS
still uses SMFTIME to define its intervals, a (poor)
design that requires records be written early.
Feb 22, 2010: The output datasets created by ANAL307X
now include TYPE30_6 (deaccumulated) interval data and
SMFINTRV, so the subtypes 2/3/6 data is included in
this comparison of 30, 70, and 72 interval CPU times.
Thanks to Dick Cook, North Carolina Dept of Info Technology, USA.
Thanks to Francisco Ojeda, SAS Institute, USA.
Thanks to Joe Piechota, SAS Institute, USA.
Change 27.345 This JCL example uses UTILBLDP to process CICS and DB2
JCLCIDB2 SMF records to create PDB.ASUMUOW and PDB.CICS for
Jan 7, 2010 complete analysis. The output datasets are COMPRESSED
but COMPRESS=NO is used for the intermediate datasets,
to save CPU time (at the cost of doubling WORK space).
Change 27.344 Variables LPCTBY and PCTLPBY were missing in dataset
VMXG70PR PDB.ASUMCELP for the LPARNAME='PHYSICAL'.
Jan 7, 2010
Thanks to Karl Lasecki, Chemical Abstracts, USA.
Change 27.343 %VMXGSET is enhanced to permit multiple datasets to be
VMXGSET read from each data library, and new option APPEND=YES
Jan 6, 2010 removes the semi-colon from the constructed SET statement
so that you can add other dataset(s). This syntax:
%VGETDDS(DDNAMES=PDB);
DATA COMBINE.JOBS;
%VMXGSET(DATASET=JOBS,APPEND=YES) DAY.SPUNJOBS;
will read all of the JOBS datasets in the PDBx DDNAMEs
and the DAY.SPUNJOBS dataset.
Thanks to George Pandzik, USAA, USA.
Change 27.342 XAMSYS records from XAM Release 3.4 had SEGLEN=168, but
VMACXAM MXG code for Release 3.7 expected SEGLEN=220, causing
Jan 5, 2010 an MXG ERROR message for each record. Now, the XAMSYS
record's length is tested and only the old variables are
input for SEGLEN=168.
Thanks to Rodger Foreman, Acxiom, USA.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 27.341 Change 27.257 added a warning and correction if SUBTYPE
VMACSMF in an SMF record exceeded 255 (because the SMF record
Jan 5, 2010 creator incorrectly stored their subtype in the left byte
instead of the correct location in the right byte).
The correction is ONLY needed when just the SMF header
logic is used (only in MACRO _SMF, or UTILGETM), so
that the real SUBTYPE value is available for reporting
or selection.
Now, the WARNING is NOT printed by default; you can print
the warning with %LET MXGDEBUG=VMACSMF;
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 27.340 SRM Thales Security PTF SL24010 INCOMPATIBLY changed the
VMACSRMH Summary Record, which caused zero observations to be
Jan 5, 2010 created in datasets SRMHSMAP and SRMHSMDE. New variables
S04DBUSY S04DOVER S04DINTV S04DNCNT S04DUFLG
are now added to SRMHSMDE and the PTF is now supported.
Thanks to Kim Nguyen, National Australia Bank, AUSTRALIA.
Thanks to Shu chun Lai, National Australia Bank, AUSTRALIA
Thanks to Anne Chung, National Australia Bank, AUSTRALIA.
Change 27.339 Change 27.046 (MXG 27.02) changed four error variables
VMACEDGR RVTRERR RVTWERR RVPRERR RVPWERR
Jan 4, 2010 from character to numeric when IBM changed their lengths
from four to five bytes, but that was not documented.
If datasets built with MXG 27.01 or earlier are combined
with datasets built with MXG 27.02 or later, then this
ERROR: VARIABLE RVPERR DEFINED AS BOTH CHAR AND NUMERIC
will result. The only solution is to convert those old
character variables to numeric variables prior to merge
with the new datasets. This can be done with
DATA PDB.EDGRVEXT;
SET PDB.EDGRVEXT
(RENAME=(RVTRERR=XRVTRERR
RVTWERR=XRVTWERR
RVPRERR=XRVPRERR
RVPWERR=XRVPWERR));
RVTRERR=INPUT(XRVTRERR,5.);
RVTWERR=INPUT(XRVTWERR,5.);
RVPRERR=INPUT(XRVPRERR,5.);
RVPWERR=INPUT(XRVPWERR,5.);
DROP XRVTRERR XRVTWERR XRVPRERR XRVPWERR;
LENGTH DEFAULT=4;
DATA PDB.EDGRXEXT;
SET PDB.EDGRXEXT
(RENAME=(RVTRERR=XRVTRERR
RVTWERR=XRVTWERR
RVPRERR=XRVPRERR
RVPWERR=XRVPWERR));
RVTRERR=INPUT(XRVTRERR,5.);
RVTWERR=INPUT(XRVTWERR,5.);
RVPRERR=INPUT(XRVPRERR,5.);
RVPWERR=INPUT(XRVPWERR,5.);
DROP XRVTRERR XRVTWERR XRVPRERR XRVPWERR;
LENGTH DEFAULT=4;
Thanks to Steve Sombke, American Century, USA.
Change 27.338 -The new DATEJUL= argument to generate dataset\directory
VGETDDS names that contain the Julian Date didn't stop at 2009365
Jan 3, 2010 but tried to create 2009366, 2009367, etc. The arguments
are now validated and if both start and end are Julian,
then the names are built with Julian dates. Otherwise,
if the arguments are numeric, then the names contain just
numeric sequences. When Julian dates are detected, then
SAS Date functions are used, so the names will correctly
roll forward or backward and both year-end AND leap-year
dates are correctly generated as the names.
-The length of the Julian Date argument can be either five
(09360) or seven (2009360) digits, but the directory or
z/OS dataset name must have the same number of digits.
So you can use
%VGETDDS(DATEJUL=h:\mxg\d,start=09360,end=10010);
for directory names h:\mxg\d09365 thru h:\mxg\d10010
or you can use
%VGETDDS(DATEJUL=h:\mxg\d,start=2009360,end=2010010);
for directory names h:\mxg\d2009365 thru h:\mxg\d2010010
Thanks to George Pandzik, USAA, USA.
====== Changes thru 27.337 were in MXG 27.11 dated Dec 31, 2009========
Change 27.337 The sort order for TYPE70PR was wrong in 27.10 MONTHBLD;
MONTHBLD a second MACRO _BYLIST and _MNTHBLD should have been
Dec 30, 2009 removed. The correct sort order is reduced to now be
SYSPLEX SYSTEM SYSNAME STARTIME
to avoid NOT SORTED conditions.
Thanks to Winnie Pang, Hawaii Medical Services Association, USA.
Change 27.336 Variable SYSLTEXT was arbitrarily INPUT as length $1024,
VMACTMNT sufficient for all tape-mount-related SYSLOG text,
Dec 24, 2009 but other SYSLOG records that can be written by MXGTMNT
can be 32384 bytes long; that is the maximum number of
lines in a multi-line WTO SYSLOG message (255) times the
maximum length of each message (126) plus one byte we add
between each message (254). MXGTMNT processes the
segmented records, which is the way the system presents
multi-line WTOs via the console interface. MXGTMNT
concatenates the messages into one block in one subtype 9
as opposed to creating multiple subtype 9s. So MXGTMNT
is covered unless IBM increases the number of lines or
message length which is not very likely but easily
addressed if they do. SYSLTEXT is now 32384.
Thanks to Beau Chavis, Bank of America, USA.
Thanks to Skip Abadie, Bank of America, USA.
Change 27.335 A stray */ at the end of ANALFIOE prevented any other
ANALFIOE subsequent %INCLUDEs to be bypassed. Unmatched comment
Dec 22, 2009 pairs often cause strange/unpredictable results.
Thanks to Brian Harvey, HCL America, USA.
Change 27.334 MXG 27.10 only. Macro variable &EPDBINC was accidentally
EXPDBINC left in the EXPDBINC member, but it is already correctly
Dec 21, 2009 located in BUILPDx, causing a second unwanted invocation
if %LET EPDBINC= was used to tailor BUILDPDB. However,
it should be noted that there is an inconsistency between
the syntax of the EPDBINC macro variable and the EXPDBINC
member, to include VMACxxxx's for BUILDPDB tailoring:
%LET EPDBINC= MEMBER1 MEMBER2 ;
EXPDBINC code: %INCLUDE SOURCLIB(MEMBER1 MEMBER2);
The value of %LET EPDBINC= is one or more MEMBER names to
be %INCLUDEd, while the code to use in the alternative
EXPDBINC member is one or more %INCLUDE statements.
-UTILBLDP sets &EPDBINC if USERADD=xxxx was specified when
it created its output SYSIN file, so this error could
cause a perfectly-running "BUILDPDB" that was built by
%UTILBLDP to fail when 27.10 is 'dropped in'. Copy the
EXPDBINC member into your tailoring library and remove
the &EPDBINC at the bottom, and your job will then run.
(Fortunately, the error is a syntax error at the start of
the BUILDPDB run, so it is fully restartable.)
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 27.333 The RMF Summary Report (REPORT=SMRY) was incorrect for
ANALRMFR most fields; averages of averages were printed, and the
Dec 20, 2009 CPU Busy included Specialty Engines when it shouldn't.
Dec 31, 2009
Thanks to Lisa L. Lawver, Land's End, USA.
Change 27.332 The Analysis of Job Events selects all SMF records for
ANALJOBE chosen jobs and prints the sequence of events in the life
Dec 18, 2009 of a job. The MACJBCK selection example tested JESNR,
but JESNR doesn't exist in many job-related records that
are read. Comments were revised for selection choices.
-The logic was restructured to eliminate uninitialized and
missing values, and durations of DSENQTM, LOADTM, and the
SELAPSTM are correctly printed with associated events.
Thanks to Douglas C. Walter, Citigroup, USA.
Change 27.331 -Support for TOKDANAM='AUTOUID' in dataset TYPE80TK, and
VMAC80A protection for unknown TOKDANAM revised to prevent the
Dec 16, 2009 STOPOVER ABEND.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Change 27.330 -Variable SMF82PDK now input as VARYING4096, vice 256 and
VMAC82 longer length is protected if SMF82PLL is GT 4096.
Dec 16, 2009 -SMF82PTA is input as $EBCDIC8. vice $CHAR8. and no longer
VMAC80A formatted $HEX.
Jan 17, 2009 -SMF82RKN is input as $CHAR64. vice $CHAR16 and format is
updated.
Thanks to Matthew T. Chappell, Queensland Dept. Transport, AUSTRALIA.
Change 27.329 MXG 27.10 only, and ONLY if _S110ST is used to only sort
VMAC110 the statistics dataset. ERROR: CICIDNNR NOT FOUND because
Dec 15, 2009 that variable was not kept in the new CICSIDND data set.
But the two new Identity datasets, CICSIDND and CICSIDNT
should not have been in the _S110ST "sort statistics"
macro; they are from subtype 1, not subtype 2, records,
and they are NOT sorted in _S110, as they can be large
volume datasets. Four other non-statistics dataset from
subtype 1 were also removed from _S110ST sort macro.
These subtype 1 datasets are not sorted by MXG:
/*_SCICRDS - CICSRDS IS NOT SORTED, CAN BE HIGH VOLUME*/
/*_SCICRDS - CICSRDS IS NOT SORTED, CAN BE HIGH VOLUME*/
/*_SCICRDF - CICSRDFI IS NOT SORTED, CAN BE HIGH VOLUME*/
/*_SCICRDQ - CICSRDQU IS NOT SORTED, CAN BE HIGH VOLUME*/
/*_SCICIDN - CICIDNTY IS NOT SORTED, CAN BE HIGH VOLUME*/
/*_SCICIDD - CICIDNDD IS NOT SORTED, CAN BE HIGH VOLUME*/
unless you choose to add their _Sdddddd invocation in the
EXPDBOUT (for BUILDPDB), or after your TYPE110 include.
The Pdddddd/Wdddddd resets were also removed from the
_CICSTAT and _CICSTAS macro definitions for consistency.
Thanks to Glenn Bowman, Wakefern, USA.
====== Changes thru 27.327 were in MXG 27.10 dated Dec 6, 2009========
Change 27.327 -The DURATM variable in PDB.ASUMMIPS is the "expected"
ASUMMIPS interval of your summarization, e.g. 1 Hour, so it does
Dec 6, 2009 not report if there were less than a full hour input
(i.e., the last interval). New variable DUR70 created in
PDB.RMFMSUSE contain the actual duration of the TYPE70
records that were summarized, so you can delete those
short intervals with DUR70 LT DURATM, or use DUR70 to
identify incomplete (or possibly outage) intervals.
-ASUMMIPS now works with &KEEPALL=NO; it created output
obs only if the MXG default &KEEPALL=YES was in effect,
but that was an MXG oversight/error now corrected.
Thanks to Willy Iven, BNP Paribas Fortis, BELGIUM.
Change 27.326 Variable QDSTQCIT should not have been deaccumulated in
VMACDB2 PDB.DB2STATS.
Dec 5, 2009
Thanks to Terry L. Berman, DST Systems, USA.
Change 27.325 z/OS 1.11 ONLY: INVALID TYPE 0 RECORD DETECTED, DELETED
VMAC0 with LENGTH=60 is an MXG error; that new record length is
Dec 3, 2009 correct, and should have been output to TYPE0/IPLS. MXG
Change 27.229 decoded the new z/OS 1.11 field, but I had
forgotten about this (VERY OLD) test for invalid length.
This test exists because it is easy for a SYSPROG to
accidentally create an ID=0 SMF record when trying to
write a "user" SMF record, and there is a very high
cost (or embarrassment) if MXG reports that there was
an IPL when one had not happened!
Thanks to Douglas C. Walter, Citigroup, USA.
Change 27.324 Support for IBM's InfoSphere Change Data Capture (CDC)
EXCDCLOG product's user SMF record creates these new datasets:
EXCDCSRC dddddd Dataset Description Contains Segments
EXCDCSYS CDCLOG CDCLOGCA LOG CACHE DLR DCW
EXCDCTGT CDCSRC CDCSOURC SOURCE SCT SDT DSL CDI CDO
FORMATS CDCTGT CDCTARGT TARGET TCT DTC CDI CDO
IMACCDC CDCSYS CDCSYSTM SYSTEM OSC CIT PAL MAA CMO
TYPECDC CLS CVF DSC DCM DLP
TYPSCDC DAL PAA CCI CCO
VMACCDC
VMXGINIT
Dec 3, 2009
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 27.323 Harmless VARIABLE DURATM UNINITIALIZED note for CPS70PR7
VMXG70PR is eliminated.
Dec 2, 2009
Thanks to Kenneth D. Jones, Bell Aliant, CANADA.
Change 27.322 -New "STATS" value for IFCIDS= in READDB2 creates only the
READDB2 PDB.DB2STATS Interval Statistics Dataset in PDBOUT=PDB,
Dec 3, 2009 an alternative to the value "STATISTICS" that creates ALL
DB2 Statistics Datasets in the PDBOUT. PDB.DB2STATS is
is created from DB2STAT0/DB2STAT1/DB2STAT4 and summarized
DB2STATB, all of which are left in //WORK with "STATS".
The PDB.DB2STATS contains all of DB2STAT0/STAT1/DB2STAT4.
-NOTE APR 2012: SEE CHANGE 30.077, IFCIDS=STATS CHANGED
to create PDB.DB2STATS and PDB.DB2STATB.
-The "ACCOUNT" value creates all DB2ACCTx datasets, but
you can select a subset using the WANTONLY= argument.
You can now just name the wanted DB2ACCTx dataset in your
IFCIDS= argument, in place of ACCOUNT, and only those are
created. Both IFCIDS= and WANTONLY= values can now be an
MXG dataset name (e.g., DB2ACCTP, DB2ACCT), although the
original unique-to-READDB2-token-names (DB2ACTP,DB2ACCT)
that are listed in READDB2 comments are still valid.
So if you only want the three common datasets created,
%READDB2(IFCIDS=DB2ACCT DB2ACCTP STATS,PDBOUT=PDB) will
create PDB.DB2ACCT, PDB.DB2ACCTP, and PDB.DB2STATS from
SMF 100 and 101 records.
-DB2 V8 only: The "DB2STAT4" is an SMF 102 IFCID=225 trace
record; if you have those data, this syntax
%READDB2(IFCIDS=DB2ACCT DB2ACCTP STATS 225,PDBOUT=PDB);
creates T102S225 and use it also to create PDB.DB2STATS.
Change 27.321 -DB2 variable QPACAAFG in DB2ACCTP identifies the type of
FORMATS Package that was executed and decoded by $MGDB2PK format
MRGDB2 with new-in-DB2-V9.1 value of '04:NATIVE SQL' added.
Dec 2, 2009 VALUE $MGDB2PK
' '='BLANK:NOT DEFINED'
'01'='01:STORED PROCEDURE'
'02'='02:USER DEFINED FUNCTION'
'03'='03:TRIGGER EXECUTING'
'04'='04:NATIVE SQL'
-New MRGDB2 member will be renamed or become an example.
-It merges variables from PDB.DB2ACCT with PDB.DB2ACCTP
to create PDB.ENHACCTP for Enhanced Package Accounting.
In this example, variable DB2PARTY is added, so ACCUMACC
Package ROLLUP RECORDS (QWACRINV=1,2,3 DB2PARTY='R') obs
can be identified; ROLLUPs don't have valid values in
these Package (DB2ACCTP) variables, so this example sets
all these variables in PDB.ENHACCTP to blank/missing for
the ROLLUP Package records:
IF DB2PARTY='R' THEN DO;
/* DOCUMENTED INVALID IN PK67870: */
QPACLOCN=' ';
QPACCOLN=' ';
QPACPKID=' ';
/* DOCUMENTED INVALID IN DSNWMSGS: */
QPACAANM=' ';
QPACARNA=.;
QPACASCH=' ';
QPACCANM=.;
QPACCAST=.;
QPACCONT=' ';
QPACEJST=.;
QPACLOCN=' '; /*YES, IN BOTH*/
QPACSCB=.;
QPACSCE=.;
QPACSPNS=.;
QPACSQLC=.;
QPACUDNU=.;
QPACUDST=.;
END;
-The sort order of the new example PDB.ENHACCTP dataset is
BY QWHSSSID QWHCAID QWHCOPID QWHCPLAN QWHSACE
QWHSLUUV DESCENDING QWHSSTCK;
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 27.320 CICS User fields SRCE,SRCETYPE,SRCEPROG,MSGLEN are
IMACAAAA supported in listed new IMACICxx CICS exit members.
IMACICUF IMACICUF - SRCE
IMACICUG IMACICUG - SRCETYPE
IMACICUH IMACICUH - SRCEPROG
IMACICUI IMACICUI - MSGLEN
UTILEXCL
VMAC110
Nov 26, 2009
Change 27.319 -DB2ACCT obs for Java Universal Type 4 JDBC Driver (JCC)
FORMATS (QMDAPTYP='JCC') did not populate these QMDASQLI fields:
VMACDB2 QMDAPLAT QMDAAPPL QMDAATID QMDASFLN ACCOUNTn
Nov 25, 2009 -Cosmetic: Format $MGDB2PN added JCC for QMDAPTYP.
'ARI'='ARI:DB2 FOR VM,VSE'
'DSN'='DSN:DB2 FOR Z/OS'
'JCC'='JCC:UNIVERSAL JDBC DRIVER'
'QSQ'='QSQ:DB2 FOR I/SERIES'
'SQL'='SQL:DB2 FOR LINUX/UNIX/WIN'
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
Change 27.318 Cosmetic; no change if COMPRESS=YES default is unchanged.
VMAC102 Several DB2 text-containing variables were $32000 LENGTH
Nov 24, 2009 because old DSECTS had no clue of their maximum lengths,
but some of these SMF 102 fields are shortened to their
(newly documented, probably unchanged) stored lengths:
QW0059CN $128 QW0061CN $128 QW0063ST $5000
QW0145TX $4000 QW0203PA $128 QW0206MS $256
QW0206MR $256 QW0206HR $64 QW0208MS $256
QW0208MR $256 QW0236MS $256 QW0236MR $256
These text fields are still $32000 stored length:
QW0004MS QW0005MS QW0062ON QW0064CN QW0065CN QW0066CN
QW0090CT QW0092P1 QW0097P1 QW01242T QW0140TX QW0141TX
QW0142TX QW0168ST QW0180DS QW0194DS QW0204TH QW0350SP
Change 27.317 Support for APAR OA28670 RMF 70 Crypto Express3 Feature.
FORMATS -Variables R7023CT and R7024CT, Crypto Processor Type, are
VMAC7072 now decoded by $MGRMFCX format.
Nov 20, 2009 -Dataset TYPE70Y2 new variables created by the APAR:
R702CDLV='ICSF*DATA*LEVEL'
R702AESC='AES*ENCIPHER*CALLS*SENT'
R702AESB='AES*ENCIPHER*BYTES*PROCESSED'
R702AESI='AES*ENCIPHER*OPERATIONS'
R702AEDC='AES*DECIPHER*CALLS*SENT'
R702AEDB='AES*DECIPHER*BYTES*PROCESSED'
R702AEDI='AES*DECIPHER*OPERATIONS'
Change 27.316 This JCL example shows how to split MXG into parallel job
JCL40GIG streams, to reduce run times, or to run parts of MXG more
Nov 19, 2009 than once per day (like multiple CICSTRANs), etc, and is
the example for the DOC40GIG parallelization document.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 27.315 New HSMMH and SAFUSER variables are created in TYPETPMX.
VMACTPMX from $HSM_MH and $SAF_US field names in the ThruPut Mgr's
Nov 18, 2009 user SMF record.
-Doc: ThruPut Manager delays:
DCS - Dataset Contention Delays; when TPM detects that a
job needs a dataset that is being held, it holds
the new job.
DBS - Device Busy Delays.
Thanks to Betty Wong, BOA, USA.
Change 27.314 -SMF 82 Crypto dataset TYPE8219 datetime variables were on
VMAC82 GMT, but now SMF82XTD/XTN/XTW are shifted by GMTOFF82 to
Nov 17, 2009 local time.
-New variable SMF82ELP, Elapsed Duration, is now created
in TYPE8219 and TYPE8220 datasets.
-Label for SMF82SSI corrected.
Thanks to Cesar Cocco, Citigroup, USA.
Change 27.313 Analysis of Job Initiator Queue now uses PDB.SPUNJOBS
ANALINIT dataset only if it exists, eliminating NOT FOUND error.
Nov 15, 2009
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 27.312 MXG 27.09 only. Change 27.254 was incorrect for NTSMF
VMACNTSM processing on ASCII; that change was intended only for
Nov 15, 2009 VBS format data. The RECFM=V is restored for ASCII.
Thanks to Jim Quigley, ConEd, USA.
Change 27.311 Support for CTG 8.0 (COMPATIBLE) fields added to SMF 111
VMAC111 record for TY111GD dataset:
Nov 14, 2009 CTGIXACO='INTERVAL*XA*TRANS*COMPLETED*HA GROUP'
CTGLXACO='LIFETIME*XA*TRANS*COMPLETED*HA GROUP'
Change 27.310 New parameter DATEJUL= creates DSNAMEs with the date in
VGETDDS Julian format, YYYYDDD, as an alternative to DATEBASE=
Nov 17, 2009 which creates the DATE in the DSNAME in DDMONYY format.
The START and END values can be specified with MDY values
or JULIAN values, or even a numeric string.
Thanks to Brian Harvey, HCL America, USA.
Change 27.309 -z/VM dataset VXSYTEPM variable's values were carried from
FORMATS from prior CMG segments (so ESCON variables could be
VMACVMXA populated in FICON observations). Now, the "other" CMG's
Nov 11, 2009 variables are set to missing values.
-New variable CHPIDTYP identifies the type of channel and
is formatted by new $MGVXACH format, which identifies the
type of OSA adapter, and it should be used in your sorts.
-New variables PCTCPCBY and PCTLPABY are calculated from
Work Units (like TYPE73) for CMG=2 (FICON) records.
Thanks to Melanie Hitchings, BT, ENGLAND.
Change 27.308 MXG 27.08-27.09. SYNC59=NO again default VMXGDUR,VMXGSUM.
VMXGDUR
VMXGSUM Caused minor differences in hourly counts in PDB.CICS
Nov 10, 2009 when minute 59 count/resources were shifted to next hour.
ASUMCICX Change 27.214 changed the internal default to SYNC59=YES,
ASUMCICS in these two internal members that summarize everything,
ASUMCICS its text claiming "ALWAYS SAFE"! But that is ONLY true if
ASUMCICT the input data being summarized is "interval" data, i.e.,
ASUMCIMS it already contains the Interval Start/End times, like
ASUMDB2A RMF,SMFINTRV,DB2STATS, or if SYNC59=YES was specified in
ASUMDB2B the ASUM/TRND/etc that invoked %VMXGSUM.
ASUMDB2G
ASUMDB2P Instead, when the input data being summarized is "events"
ASUMDBDS or "transactions", like CICSTRAN,DB2ACCT,ASUMUOW, wherein
ASUMDBSB VMXGSUM creates the Interval Start/End times, my change
ASUMHSM from NO to YES caused differences in hourly counts in the
ASUMIDMS PDB.CICS dataset (created from CICSTRAN by ASUMCICX) as
ASUMJOBS those minute 59 data were being counted in the next hour.
ASUMSTC (There's nothing wrong in using SYNC59=YES in ASUMCICX
ASUMVTVM to shift those minute 59 transactions, if that's what
you know you want because you have SYNC(59) data, but
I should not have changed that global default!).
While not required with the restored default value, the
listed ASUMxxxx members use input event data and create
interval start/end times, so they now all contain the
SYNC59=NO option, mostly for documentation.
Thanks to Paul Naddeo, FISERV, USA.
Change 27.307 Ancient DB2 Version 7.1 records have non-zero offset and
VMACDB2 length for the "truncated" QMDALOCN field, so MXG read in
Nov 6, 2009 that longer text into QMDALOCN, but examination of those
longer text values show they are not valid, and since the
DB2 V7.1 DSNDQMDA doesn't show the "truncated" offsets,
which appear to have been added in DB2 V8.1, the input of
the truncated field is now bypassed for QWHSRELN LE 7.1.
Change 27.306 Oracle SMF records are restructured, which surfaces as
VMACORAC ERROR: ILLEGAL VALUE FOR STARTS messages. This change
Nov 6, 2009 recovers all original values, and creates seven ORACUNNn
numeric unknown variables and two ORACUNCn character
variables observed in the SMF records. These variables
will be named when a DSECT is available.
Change 27.305 The MSU and MIPS calculations in ASUMMIPS for workloads
ASUMMIPS (i.e., the Service Class MSU from TYPE72GO and Address
Nov 6, 2009 Space MSU from SMFINTRV) did NOT take into account the
Capture Ratio. of each of the engine types; only the
Captured CPUTM was used. This change keeps the RMFINTRV
Capture Ratio variables (CAPTURAT CAPIFART CAPZIPRT) for
each Engine type, and the MSUUSED is divided by
(CAPxxxxx/100) to take into account the Interval Capture
Ratio for that SYSTEM for that engine type. This will
cause the xxxUSED values to be estimates of the hardware
utilization, and they will be slightly larger now. If
intervals are summarized, the Interval Capture Ratio is
the weighted average of the input data. The use of
Capture Ratio can be turned off by specifying a 0 instead
of 1 for the _USECAPT macro.
Thanks to Brian Harvey, HCL America, USA.
Change 27.304 The IFA/zAAP and zIIP Capture Ratios are wrong if those
VMXGRMFI Specialty Engines are faster than the CP engines, because
Nov 6, 2009 the IFATM/ZIPTM are normalized values. Now, the factors
Dec 3, 2009 R723NFFI and R723NFFS, respectively, are used in the MXG
calculation of CAPIFART and CAPZIPRT Capture Ratios. The
CPU times are NOT changed back to raw values.
Change 27.303 CICS Total I/O Wait WTTOIOTM & Total Other Wait WTOTIOTM
ADOC110 variables now include all 45 WAIT durations included in
VMAC110 Suspend Time that are in IBM's CICS Performance Guide for
Nov 5, 2009 CICS/TS 4.1; these six wait durations are not separately
Nov 10, 2009 in WTOTIOTM because they are included in RMISIOTM:
IMSWAITM DB2RDYTM DB2CONTM DB2WAITM DSCHMDTM WMQGETTM
-Member ADOC110 is updated with the complete list of which
waits are I/O and which are Other waits, and a schematic
of how these waits are related. The new equations are:
WTTOIOTM=SUM( /*TOTAL I/O WAIT DURATION*/
WTTCIOTM,WTTSIOTM,WTSHIOTM,WTTDIOTM,WTJCIOTM,
WTFCIOTM,WTRLIOTM,CFDTWATM,SOIOWTTM,ISIOWTTM,
SOOIOWTM,WTIRIOTM,LU61IOTM,LU62IOTM,SZWAIOTM);
WTOTIOTM=SUM( /*TOTAL OTHER WAIT DURATION*/
DSPDIOTM,ENQDIOTM,GNQDELTM,WTICIOTM,WTLMIOTM,
WTWEIOTM,WTWCIOTM,RUNTRWTM,SRVSYWTM,RQRWAITM,
RQPWAITM,SYNCDLTM,MAXOTDTM,MAXJTDTM,MAXSTDTM,
MAXXTDTM,RRMSWATM,PTPWAITM,RMISIOTM,JVMSUSTM,
DSTCBMTM,DSMMSCTM,WTDWIOTM);
WTUNIOTM=MAX( /*UNCAPTURED WAIT DURATIOM(/
0,(SUSPNDTM-(WTTOIOTM+WTOTIOTM)));
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Thanks to Dick Arnold, Commerce Bank of Kansas City, USA.
Change 27.302 Variable FTPMEMBR is now kept in TYPETCPC dataset, and
VMACTCP variable FTPUSRMT is now correctly labeled "REMOTE" and
Nov 4, 2009 not "LOCAL".
Thanks to Marybeth Delphia, Texas Comptroller of Public Accounts, USA
Change 27.301 Unused Change Number.
Change 27.300 ASMTAPEE ML-45 provides several enhancements.
ASMTAPEE -Addition of assembly time stamp to initialization message
Nov 1, 2009 TMNT016I. This will help to confirm that the version of
TMNT that is active matches the expected assembly.
TMNT016I MXG Tape Monitor maintenance level 45
initialization complete (2009/10/31-13.15)
-Modification of the TMNT018I initialization message to
include the SMF record number being used:
TMNT018I MXG Tape Monitor interval set to 0.50 seconds
using SMF record number 238
-Added message TMNT011E (in addition to existing TMNT010E)
to more clearly identify, in human terms, the reason why
SMF recording has failed:
TMNT010E SMF write failed - SMFEWTM return code is
00000028
TMNT011E SMF write failed because a buffer shortage
caused the data to be lost
-Added support for BAM (basic access method) use of XTIOTs
(TIOTs resident above the 16mb line). This is only
relevant when the XMEM=YES option is specified.
-Each ML has small performance enhancements to decrease
MXGTMNT overhead; generally this involves taking
advantage of macro options that improve performance
and/or eliminating unnecessary instructions from
performance sensitive code paths. The benefits are small
from ML to ML but the difference between ML45 and ML26,
for instance, is fairly significant.
Change 27.299 %MACRO to minimize GDG Base Enqueue when reading SMF(0),
ALOCGOVO by only opening the GDG Base Name with relative reference
Oct 31, 2009 to get the full "goovoo" dsname, freeing the Base Name,
and then allocating the FILENAME SMF with the "goovoo"
name for the actual SMF processing, so the duration of
the DSNENQUE for the GDB Base Name is very short.
Normally, if you use JCL to allocate SMF(0), your job
will prevent an SMF Dump from running to create (+1),
until your job ends (or, at least until SMF reading is
completed, if you use FREE=CLOSE on your //SMF DD).
The WAIT=20 option is used to open the relative reference
FILENAME SMF "YOUR.SMF(0)" DISP=SHR WAIT=20;
so that if the GDG Base is already in use, SAS will enter
a Detected Wait state for up to 20 minutes, waking every
15 seconds to see if the enqueue has cleared; without the
filename option WAIT=20, SAS would have terminated with
ERROR: FILE IS IN USE, YOUR.SMF(0) message).
The examples show DDNAME=SMF, but that and the options on
the generated FILENAME statement can be changed.
-This ALOCGOVO only works if your REMOVE the static DD
statements from the JCL; otherwise they will still
control the allocation.
Thanks to Christian Hodel, Swisscom IT Services, SWITZERLAND.
Thanks to MP Welch, SPRINT, USA.
Change 27.298 Another Elegant algorithm uncompresses ASG/Landmark data
VMACTIMS records in SAS code, so it works on ASCII systems (which
VMACTMDB do not support INFILE exits). However, it is EXPENSIVE,
VMACTMDC requiring SIX TIMES THE CPU THAT THE EXITMON6 INFILE EXIT
VMACTMMQ REQUIRES: USE EXITMON6 ON z/OS. See Change 27.260.
VMACTMO2 ASG's compression technique is different than IBM's, but
VMACTMTC a similar increase in CPU Time was observed. However,
VMACTMVS since ASCII systems do not support INFILE exits, this SAS
VMACTMVT code algorithm does support processing of compressed data
Nov 5, 2009 on ASCII or with WPS, which might be worth the CPU cost.
Thanks to Ian Gibson, CPT Global Ltd @ Bendigo & Adelaid Bank, OZ.
Thanks to Peter Turner, CPT Global Ltd @ Bendigo & Adelaid Bank, OZ.
Change 27.297 -ANALDB2R - MERGE STATEMENT HAS REPEATED BY VALUES, and
ANALDB2R SUBSTR errors in AUDIT reports were corrected.
READDB2 -ANALDB2R corrected logic to populate the IFCIDs being
Nov 4, 2009 requested with READDB2 is used with PDB=SMF.
Nov 15, 2009 -READDB2 corrected logic that was suppressing the T102S106
Nov 24, 2009 dataset when WANTONLY was not used, even when requested.
-READDB2 ACCOUNT and STATISTICS now work as expected, to
create only those subsets of datasets; examples revised
to show the use of optional DB2ACTB=NO, etc.
Thanks to Jim Kovarik, AEGONUSA, USA.
Change 27.296 Variable CECSER added to datasets RMFMSUSE and SMFMSUSE.
ASUMMIPS
Oct 28, 2009
Thanks to Nicholas Ward, Centrelink, AUSTRALIA
Change 27.295 PRO/SMS SMF records were misaligned after the MSGED text
VMACPROS which was increased from 256 to 292 bytes; the first 42
Oct 27, 2009 are now GWMSGECH $CHAR42 with $HEX84 format, while the
actual text is GWMSGED input now as $EBCDIC250.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 27.294 IFL observations in ASUM70LP and ASUMCELP had STARTIME
VMXG70PR and DURATM were missing values, and IFLCPUS was wrong if
Oct 26, 2009 the summary interval was larger than original DURATM.
Thanks to Kenneth D. Jones, Bell Aliant, CANADA.
Thanks to Bruce Perry, Bell Aliant, CANADA.
Change 27.293 Support for CICS Identity Propagation, new with z/OS 1.11
EXCICIDD CICS/TS 4.1 & APARs PK95579,PK83741,PK98426, creates new
EXCICIDN SMF 110 Subtype 1 MNSEGCL=6 record (if MNIDN=ON in SIT),
FORMATS from which MXG creates two new datasets:
IMAC110 dddddd Dataset Description
VMAC110 CICIDN CICSIDNT IDENTITY Transaction Information
VMXGINIT CICIDD CICSIDND Identity Realm/Distinguished Name
Oct 26, 2009 This new Identity Propagation facility sends a user's
Nov 16, 2009 security identity information (the distributed identity)
from a client system across a network, preserving the
distributed identity for use during CICS authorization
and for subsequent auditing purposes.
Following text was revised Feb 1, 2010:
-The new MNSEGCL=5 record was "supported" by MXG 20.20 but
no records were ever read; this SMF file contained those
records and exposed errors in that MXG code, including a
possible INPUT STATEMENT EXCEEDED RECORD LENGTH error.
-The MNSEGCL=5 subtype record can be compressed by CICS,
but the new MNSEGCL=6 record can not.
Change 27.292 Dataset ASUM70LP had missing values for LPSHARC,LPSHARE
VMXG70PR TOTSHARC and TOTSHARE in the observations for the first
Oct 26, 2009 LPAR (only in the first interval). Setting LPARNUM=. was
changed to LPARNUM=9999 so the descending sort corrected
the missing values.
Thanks to Horst Noerenberg, GaVI Gesellshaft .. Informatik, GERMANY.
Change 27.291 Variable S42DSRDD was incorrect by a factor of 10**6; the
VMAC42 calculation should have multiplied by 1000 to convert to
Oct 23, 2009 milliseconds, but it instead divided by 1000. The right
statement for all three instances now is
S42DSRDD=128*S42DSRDD*1000;
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Sridher Nelliyappan Manivel, Lowe's Companies, USA.
Change 27.290 ASUMUOWT (ASUMUOW with ASG TMON MONITASK vice CICSTRAN)
VMXGUOWT had not been updated in four years, suggesting not much
Oct 23, 2009 usage, but now it is updated to match ASUMUOW.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 27.289 Support for CPUZIPTM in SYNCSORT records; additionally,
VMACSYNC the new 4-byte fields in the SORTWORK extension are used
Oct 22, 2009 for the primary and secondary track allocations and the
Nov 18, 2009 primary tracks released.
Syncsort acknowledges that not all sorts can use a zIIP:
-Eligible sorts (not Merge or copies) are seeing 50 to 60
percent use of the zIIP eligible algorithms which result
in a 4 to 10 percent improvement in CPU time.
-Sorting jobs which employ the following features are
currently not eligible for zIIP processing:
SUM
Exit routines other than E15 or E35
Using SORTIN with an E15 exit
OUTREC with CONVERT
Relative length greater than 32756
VBS truncation
TSO invoked sorts
SVC=0
VB INCLUDE/OMIT
OUTFIL INCLUDE
TRUNCATION OF KEYS
SYNCSORT TPF SY66820 enables use of:
INCLUDE/OMIT with STOPAFT
-Although these limitations are being reviewed by SYNCSORT
development staff, there is no schedule nor time frame
if or when any of these will become eligible for zIIP
processing.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 27.288 New format $MGCICCN is created for variable CMQCNSTA in
FORMATS CICS Statistics dataset CICIMQ dataset to identify if the
VMAC110 Queue is connected or not.
Oct 22, 2009
Thanks to Dale Slaughter, Aegonusa, USA.
Change 27.287 MXG 27.09 errors corrected:
DAILYDSC -ERROR: New DAILYDSC, DAILYDSN, and DAILYDSR.
DAILYDSN The new VMXGDSN's argument was changed to TAPEDATA= from
DAILYDSR TMC= during testing, but the three DAILYDSx members still
VMAC74 had the original TMC= argument in their VMXGDSN calls.
CONFIGV9 If you have an old, tailored DAILYDSx member, it is NOT
Oct 21, 2009 impacted by this new design that uses VMXGDSN.
VMXGDSN -COSMETIC: VMAC74.
Nov 13, 2009 DEBUGGING PUT statement was not removed.
-COSMETIC: CONFIGV9
Option NOMAUTOSOURCEDISPLAY replaces MAUTOSOURCEDISPLAY.
Many lines printed on log, no impact. See Change 27.284.
Option was changed in 27.08.
-Nov 13: VMXGDSN typo PDN corrected to PDB.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to Robert Hamilton, Fifth Third Bank, USA.
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 27.286 PRISMA dataset PRPR1620, variable "UNKNOWN" is now INPUT
VMACPRPR as OFFSETS, and new variable INTERPOS is INPUT and KEPT.
Oct 18, 2009
Thanks to Nik Marien, KBC Global Services NV, BELGIUM.
Change 27.285 Label, formats, and spelling corrections:
TYPEIMSA TYPEIMSA:
VMACNTSM variable ELAPSTM formatted TIME12.2
VMACQACS VMACNTSM:
VMACVMXA labels added
Oct 17, 2009 MLMDINST='MLMD*INSTANCE*NAME'
VMAC71 MLLOINST='MLLO*INSTANCE*NAME'
VMACTMNT QLBLINST='QLBL*INSTANCE*NAME'
Oct 20, 2009 labels changed
SQBTATWB='AVG*TIME TO*WRITE*BATCH'
QLBLATWB='AVG*TIME TO*WRITE*BATCH'
QLBLTBBA='AVG*TIME*BETWEEN*BATCHES'
SQBTTBBA='AVG*TIME*BETWEEN*BATCHES'
formatted
QLBLTBBA QLBLATWB TIME13.3
by list changes
VMWGURES dataset, VWGRINST inserted
VMWHODIS dataset, VMWHINST inserted
MLCONS dataset, MLCOINST inserted
VMACVMXA:
label corrected
VIMXCD20='DEVTYPE 20*MAXIMUM*VIRTUAL*CPU TIME*ACB'
variable name spelling corrections in DIF() logic:
ASCHLRC ASCHLLC spelling was wrong: ASCCHLRC/ASCCHLLC
VMACQACS:
labels added
SYSIUL='USER*AUTHORIZATIONS*AVAILABLE'
SYSCIU='USER*AUTHORIZATIONS*NEEDED'
VMAC71: Dataset TYPE71.
Variable SMF71GIE was added to the keep list for TYPE71
by Change 27.178 but the change was not documented. Now
it is labeled and formatted.
VMACTMNT: Dataset TYPESYMT.
Variables SYSLENCR, SYSLBLKS labeled.
VMXGRMFI: Dataset RMFINTRV.
Variable NRINTRV now labeled.
Variables IFATM, ZIPTM are now TIME12.2 formatted.
VMXG70PR:
Variables IFAACTTM, ZIPACTTM labeled and TIME12.2'd.
All LnnPAT variables are formatted TIME12.2
All LnnIFKTM and LPnILWTM in ASUM70PR TIME12.2'd.
VMAC30: Variable ASID label corrected.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 27.284 The SAS Option MAUTOLOCDISPLAY was added to the CONFIGV9
CONFIGxx member in MXG 27.08, but not documented. That option
Oct 16, 2009 prints a message when an autocall %MACRO is invoked, to
identifies the source member that was autocalled. That
option is very useful for MXG Technical Support: having
a back-level member in your tailoring library causes most
errors, and so we can diagnose directly from your log,
without requesting a second run to enable diagnostics.
However, the message is NOT printed for each compile of
an autocalled %MACRO, but instead is printed for each
invocation of an autocall, which causes lots of messages,
so I have now changed CONFIGV9 to NOT set that option.
You can reset the option with an OPTIONS= parameter:
// EXEC MXGSAS,OPTIONS='NOMAUTOLOCDISPLAY'
====== Changes thru 27.283 were in MXG 27.09 dated Oct 14, 2009========
Change 27.283 CPU Activity Report updates.
ANALRMFR
Oct 14, 2009
Thanks to Kim Westcott, New York State Office of Technology, USA.
Change 27.282 -TMON for VTAM 'SE' record average values are no longer
VMACTMVT contained in the record, causing an INPUT EXCEEDED error.
Oct 12, 2009 These variables are now calculated rather than INPUT:
SEHRTA SENRTA SEINA SEOTA.
-Some 'SE' records are compressed, while most are not, in
the test file, so MXG now skips the compressed records,
printing a message for the first five, but outputting the
non compressed records.
Thanks to Paul Volpi, UHC, USA.
Change 27.281 -New XAM datasets are created for PRCAPM, PRCIOP, IODVSW,
EXXAMAPM and STOASI. Those segments can be repeated in XAMSYS
EXXAMASI records, and thus must be output in separate datasets.
EXXAMIOP -New XMMTRPAG dataset created from MTRPAG segment in the
EXXAMPAG XAMDEV file, which is quite different than the MTRPAG
EXXAMVSW segment in the XAMSYS file. Variables PGS1-PGS3,CALCYLPA,
IMACXAM CALCYLPR and CALCYLSP that were previously kept in XAMDEV
VMACXAM are no longer kept in that dataset as they exist only in
VMXGINIT the MTRPAG segment in XAMSYS.
Oct 13, 2009 -IMACXAM is updated with the new datasets.
EXXAMSEK -MANY new variables in release 3.7 that were previously
Oct 17, 2009 overlooked are now output; the KEEP= list for each of
Oct 20, 2009 those datasets lists this Change Number before the list
of new variables.
-Additional MXG corrections for alignment corrected these
dataset's variables:
XAMSYS SYSBUSY
XAMUSR IDLETIME; variable VMTRUSR was removed.
XMFALACB INDEX
-Variable LASTCHNG (a TODSTAMP) is sometimes populated
with 8-bytes of blanks, which cause a datetime value of
'27OCT1935:08:26:40.59'. Now, blanks set it to missing.
-Additional problems with data values that are observed:
-Variable SMOOTHTM in XMSUBNET, XMTCPAPP, XMTCPCON has
many (not all) instances of negative values.
-Variables PVMAJTFA in datasets XMVSISFT and XMVSINAP
and variable PVMINTFA in dataset XMVSISFT are sometimes
negative values.
-Variable RSASXRPM in XAMSYS dataset can be negative.
-Variable PTYPE in XMVSISFT is numeric, usually 0 or 4,
but it contains blanks; four blank ('40'x) input as
PIB4 is the decimal value 1077952576.
-Variable PPATH in XMVSISFT should contain path name in
EBCDIC, but values starting with 'init ' have hex value
'BAF3BB'x in the last three bytes.
-Variable PERFNICE in XMVSISFT can be negative.
-Oct 17 updates after Barton updated his PL/1 Declares:
-XAMDEV dataset
variables PAGUSED SCMWORK SPLUSED no longer exist.
variables CALSPOOL CALPAGE RDEVDRAN are added.
MDISK segment, length 92, 8+4+16+16+8+16=68 documented
CONFIG - corrected
USEACT - corrected
-XAMSYS dataset
RLEASE - corrected
SUBSUM - corrected
MONITR - corrected
MTRMEM - corrected
MTRSYS - corrected
-XAM TCP record
FALCPU - updated.
TCP - updated.
HSTSFT - updated.
VSINAP - updated.
VSIUSR - updated.
-Oct 20 status: updates pending documentation
DEV - IODQDS - Segment not documented.
DEV - MDISK - Extra data not documented.
DEV - SEKSEK - Decoded, but disagrees with Declare.
USR - SERVRS - Segment not documented.
Thanks to Chris Morgan, CITIBANK, ENGLAND.
Change 27.280 New DCOLLECT variables added by z/OS 1.11 dataset DCOLDC:
VMACDCOL DDCSPECC='DDCSPECC*ADDITIONAL*SPECIFICATION*FLAGS'
Oct 9, 2009 DDCFATTR='EATTR*SPECIFIED?'
DDCSPECD='DDCSPECD*ADDITIONAL*SPECIFICATION*FLAGS'
DDCVBYT1='VSAM*EXTENSION'
DDCEX255='OVER 255*EXTENTS*ALLOWED?'
DDCEATTR='EXTENDED*ATTRIBUTE'
Variable DDCSFLG was incorrectly located in z/OS 1.10 IBM
documentation in Access Method Services for Catalogs; the
+3 preceding it was really only +2. These new variables
are decoded from DDCSFLG:
DDCOVRD ='BWO*SPECIFIED?'
DDCSDB ='SPHERE*RECOVERABILITY*SPECIFIED?'
Thanks to Mike Blocker, Fidelity Investments, USA.
Change 27.279 IBM has documented when Subtype 24 and 25 records are
VMAC42 created in APAR OA30503:
Oct 8, 2009 Only those applications which issue STOW and DESERV
calls for PDS or PDSE directory processing will
generate Subtype25 records. Some applications, such as
IEBCOPY, do not issue a STOW or DESERV issue STOW when
updating the directory.
Change 27.278 Errors that %TRIM macro was not resolved are discussed in
CONFIGxx Change 27.124, but that error can also occur if you have
Oct 8, 2009 changed the S2=0 option in MXG's CONFIGV9 to S2=72.
Change 27.277 -Support for USER=DDNAME was erratic because WORK text was
VMAC42 used in many places, where &MXGWORK macro variable should
VMAC80A have been the text.
Oct 8, 2009 -Variables W2RCHGAG and W2RINSAG in dataset CICW2R are now
Oct 9, 2009 formatted MG110AG.
-Variable SMFA2GZ2 label corrected to "SMS" versus "SMF"
in dataset TYPE42D3.
-Variable SMFA2NRS label in TYPE42X3/X4 to match SMF42NRS.
-Variables TOKCHARV, TOKLDAP, TOKNUMRV, TOK80FLG, TOK80LN2
in dataset TYPE80TK are now labeled.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 27.276 Support for z/VM support of 3390-A a/k/a EAV volumes with
VMACVMXA more than 65K tracks; four larger fields are added at the
Oct 7, 2009 end of the SEKSEK record, and are input by this change
into the four existing MXG variables.
Change 27.275 Variable PCTIOPBY='IOP/SAP*PERCENT*BUSY' is created and
VMAC78 kept in TYPE78IO.
Oct 6, 2009
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.274 -ERROR: CICDS DISPATCH INTERVAL LARGER THAN INTERVAL can
VMXGCICI occur when creating PDB.CICINTRV Statistics Summary if
VMAC110 a region was Shutdown (creating an EOD record) and then
Oct 7, 2009 restarted, and the first INT record is created such that
Oct 21, 2009 both the EOD and INT records have the same Summary
(recalculated) COLLTIME. For example, with an requested
INTERVAL=THREEHR summary:
INTERVAL START ACTUAL SUMMARY
EVENT CICSSTCK COLLTIME COLLTIME
EOD 00:00 01:26 03:00
INT 02:00 03:00 03:00
the two events with the same Summary COLLTIME were NOT
combined, because variables CICSSTCK and COLLTIME were
both in the BY list for summarization. CICSSTCK has been
removed from both BY and KEEPs; only COLLTIME is correct.
-Variables A17DSIXP/A17DTRDS were incorrectly deaccumed,
causing negative values for them in PDB.CICINTRV.
-The SORT order for CICFCR (A17 variables) was corrected
to insert A17FNAM ahead of A17DSNAM in both VMAC110 and
in VMXGCICI. While I hate changing the SORT ORDER, this
change is required for duplicate removal.
-Oct 21: CICSSTCK added in KEEPIN= for all steps that have
CICSSTCH in the BY statement in their INCODE=, so that
KEEPALL=NO can be used if needed.
Thanks to Lynn Hong, UCLA, USA.
Change 27.273 -Cleaned up the WTD logic and modified so that if you are
BLDSMPDB using AUTOALOC (which create output directory names that
DAILYDSC contain todays date), it ignores ROLLWEEK (copying of the
DAILYDSN week4-week5 etc) since AUTALOC takes care of that.
DAILYDSR -New REROUTE= argument let's you change the destination
IMACZDAT directories of individual PDB datasets.
VMXGALOC -New macro variable &MXGZDATE created in IMACZDAT so that
VMXGDSN ZDATE can be set for rerun without hard EDIT of IMACZDAT.
VMXGDSN -New macro VMXGDSN reads DCOLLECT, TMC, RMM and CONTROLT
VMXGINIT data files for "Daily Dataset Billing", but separates
Oct 14, 2009 reading of the raw data files from the creation of the
Oct 21, 2009 "DATASETS" dataset, so those phases can be separately
Nov 19, 2009 executed by BLDSMPDB. Members DAILYDSN, DAILYDSC,
DAILYDSR members now invoke VMXGDSN.
-Some confusing WTD/WEEK & MTD/MONTH messages eliminated.
Thanks to Cletus McGee, Alfa Mutual Insurance Company, USA.
Change 27.272 READDB2 support for WANTONLY is enhanced (i.e., now it
READDB2 works, and with new options!).
Sep 28, 2009 When WANTONLY is used, the datasets that are NOT listed
in the WANTONLY= argument that would be created by other
arguments (e.g., ACCOUNT) will be created with zero obs.
Example 1:
IFCIDS=ACCOUNT,WANTONLY=DB2ACCT
IFCIDS=ACCOUNT,DB2ACCT=YES//keep/x y z
Only the DB2ACCT dataset will be populated; all other
DB2ACCTx datasets will be created, but with zero obs,
and no other datasets are created.
Example 2:
%READDB2(PDBOUT=PDBOUT,DB2ACTB=NO);
If you do NOT want a dataset to be created, then you
can use NO as the value of the Dataset Name Argument
and the dataset will NOT exist. For example, will
suppress the creation of DB2ACCTB.
Thanks to Alyona Bertneski, JPMorgan, USA.
Change 27.271 DB2 IFCID=173 support is updated to detect "truncated"
VMAC102 names, and supports UNICODE text data.
Sep 28, 2009
Thanks to Ervin Claxon, IBM Global Services, USA.
Change 27.270 CICS Statistics STID=115 record is not supposed to exist,
VMAC110 so when it did, MXG didn't handle it's non-non-existence
Sep 28, 2009 correctly.
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 27.269 Change 27.158 still caused QWHDRQNM and QWHDSVNM to be
VMACDB2H incorrect, if SMF data was read on ASCII platforms, due
Sep 25, 2009 to spelling QWHDxxxx as QWHSxxxx.
Thanks to Bill McDonald, Kimberly-Clark, USA.
Change 27.268 Example to summarize PDB.TYPE72GO Service/Report dataset,
ASUM72GO creating 10 minute output intervals in PDB.ASUM72GO from
Sep 25, 2009 5 minute input intervals. Using DURATM=INTERVAL forces
the output DURATM value to be the INTERVAL=TENMIN value,
even if the Service Class was only active during one of
the two 5-minute original intervals.
-Originally, the DURATM from the first "period" was kept
in this INCODE logic:
INCODE =
PROC SORT DATA=MXGSUM1 OUT=MXGSUM1A;
BY SYSTEM STARTIME SRVCLASS RPRTCLAS;
DATA MXGSUM1; SET MXGSUM1A;
BY SYSTEM STARTIME SRVCLASS RPRTCLAS;
IF NOT FIRST.RPRTCLAS THEN DURATM=.; ,
but that not only cost the sort and extra data pass,
it also removed the /VIEW. And, perhaps worst, the value
of DURATM in the output dataset was not always the 10 min
desired - if a Service Class was only used for one 5 min
period that interval had DURATM of 5 minutes with INCODE.
-Originally, originally, the INCODE kept PERIOD=1 obs, but
there are PDB.TYPE72GO observations with only PERIOD=2;
MXG only creates observations if the service class was in
active use during an interval.
Thanks to Scott Weiner, Wisconsin Physicians Service, USA.
Change 27.267 -These variables in TYPE42X1 and TYPE42X2 are now MGBYTES.
VMAC42 formatted:
Sep 23, 2009 SMF42JON SMF42JOO SMF42JOP SMF42JOR SMF42JOS SMF42JOT
SMF42JOV SMF42JOW SMF42JOX SMF42JOY SMF42JOZ SMF42JQG
SMF42JQH SMF42JQI SMF42JQJ SMF42JQK SMF42JQL SMF42JQM
SMF42JQN SMF42JRA SMF42JRB SMF42NSZ SMF42SAP SMF42SPR
Dataset Labels for TYPE42Xn now match Change 27.062.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.266 VMXGALOC did not create a new weekly directory when it
VMXGALOC should have, and it did not create the WTD (week to date)
Sep 24, 2009 folder at the beginning of the week, nor did it create
Oct 2, 2009 the MTD (month to date) folder at the beginning of the
month, but now it does.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANDADA
Change 27.265 -ASMRMFV incorrectly issued RMFV005E ERROR INVALID PARM=0
ASMRMFV when sequence numbers were in columns 73-90 of SYSIN.
Sep 22, 2009 -Notes that PARM values are needed only once were added.
Thanks to Doug Medland, IBM Global Services, USA.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 27.264 -z/VM MONWRITE example to process only the USER Domain
VMACVMXA data, and to create only PDB.VXBYUSR and PDB.VXSUMUSR
VMXGINIT output datasets required updates to VMACVMXA because the
Sep 21, 2009 VXSUMUSR's output MACRO _SVMSUMU wasn't undefined.
-This example can then be used to read only Domain 4 and
create only PDB.VXBYUSR and PDB.VXSUMUSR in //PDB:
//MWINPUT DD DSN=YOUR.MONWRITE.DATA.FILE,DISP=SHR
//PDB DD DSN=YOUR.ZVM.OUTPUT.PDB,DISP=OLD
//SYSIN DD *
%VMXGINIT(DEFAULT=WORK);
%LET PVMBYUS=PDB;
%LET PVMSUMU=PDB;
%LET MACKEEP= MACRO _VMRPT % ;
%LET MACVMXH=
%QUOTE(
IF MRHDRDM NE 4 THEN DO;
INPUT +SKIP @;
SKIP=0;
MRHDRDM=-99;
MRHDRRC=-99;
GOTO MWENDIT;
END;
);
%INCLUDE SOURCLIB(VMACVMXA,IMACKEEP);
_TESTMW;
RUN;
Thanks to Doug Wells, First National Bank of Omaha, USA.
Change 27.263 Variable R744FNAM, the Coupling Facility Name, was not
VMAC74 kept in TYPE74DU (Duplex Coupling Facility). Any ITRM
DOC sites using dataset XTY74DU created by MXG macros need to
Sep 21, 2009 update their ITRM dictionary. Fortunately, MXG's R744FNAM
already exists as ITRM name R744FNA (in XTY74CF,XTY74ST),
and it will be added in ITRM's next dictionary update,
but it can easily be added (with help from ITRM techie!):
Run the below example to execute the ITRM CPDDUTL %macro
(the data dictionary utility) to add the variable to the
table. The example uses the CPCAT macro twice to create
the catalog entry with the necessary control statements
that are input to the cpddutl macro:
%cpcat;
cards4;
SET TABLE NAME=XTY74DU ;
CREATE VARIABLE NAME=R744FNA
EXTNAME=R744FNAM
LABEL='Name of Coupling Facility'
DESCRIPTION='Name of Coupling Facility'
TYPE=CHARACTER
LENGTH=8
INTERPRET=STRING
KEPT=YES ;
;;;;
%cpcat(cat=WORK.ddutl.ddutl.source);
%cpddutl(entrynam=work.ddutl.ddutl.source);
Run the above in a regular ITRM batch job that uses
CPSTART to point to your PDB with DISP=OLD, but do not
include other CMPROCES, CPPROCES or CPREDUCE macros.
Thanks to Yacine Amraoui, Banque Postale, FRANCE.
Change 27.262 ASUMMIPS is enhanced to add MSU and MIPS for zIIPs, zAAPs
ASUMMIPS to the existing CP variables.
Sep 18, 2009
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 27.261 -Variable QBMCTEXT in T1028005 dataset from TMON/DB2 is in
VMAC102 ASCII text, so the INPUT statement was revised.
Sep 18, 2009 -QW0343xx variables are now INPUT and KEEP in T102S343.
-Additional info on the IFCID 005 (T1028005) - SQL text
and IFCID 307 (T1028133) - SQL Stmt Sum (All Qualifiers).
There is no 1-1 relationship between those two files,
especially for dynamic SQL. All SQL text collected is
found in T1028005. When the same SQL statement is
executed more than once, only one observation is created
in T1028005. In T1028133, for each unique collection key,
there is a separate observation. So when user A, B and C
execute the same SQL-stmt (plan/package/stmt), there will
be 3 T1028133 observations (one for each user), but there
will only be one observation in T1028005
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Thanks to Paul Volpi, UHC, USA.
Thanks to James J. Burnes, UHC, USA.
Change 27.260 This elegant contributed algorithm uncompresses CICS/TS
VMAC110 SMF records using SAS statements in VMAC110 that expands
Sep 21, 2009 the SAS _INFILE_ Buffer, using _INFILE_ Special Variable,
Oct 4, 2009 so this algorithm works on z/OS or on any ASCII Platform,
Nov 4, 2009 since it's just SAS code!
********WARNING INSERTED NOV 5, 2009*******************
Unfortunately, this elegance comes at great CPU expense:
While the original change text did warn that:
But the "instream" algorithm may be more CPU intensive
than EXITCICS, so, if you are processing on z/OS, you
may find the EXITCICS algorithm preferable.
only now, with files of 100% compressed records, has the
cost been measured: TWELVE TIMES MORE CPU TIME than
using the (written in ASM code) EXITCICS Infile Exit.
With the INFILE exit, it has already uncompressed the
record, so the SAS decompression code is not executed.
********WARNING INSERTED NOV 5, 2009*******************
Previously, to read compressed CICS/TS 3.2+ SMF records,
you had to assemble MXG's EXITCICS member to create the
CICS "Infile Exit", which can ONLY execute on z/OS.
This algorithm is both automatic and transparent, and, if
the EXITCICS Infile Exit is installed, it will have
already expanded the record, so this "instream" algorithm
won't be executed.
But the "instream" algorithm may be more CPU intensive
than EXITCICS, so, if you are processing on z/OS, you may
find the EXITCICS algorithm preferable. SEE BELOW.
-The Maximum Record Length printed on the SAS log shows
the uncompressed length with EXITCICS, but shows the
maximum compressed length with this expansion algorithm.
-Compressed 110 SMF records can be processed by WPS 2.04,
which added the _INFILE_ Special Variable.
The authors describe their work:
-The compression algorithm used is a simple RLE (Run
Length Encoding) as follows:-
-All compressed data consists of an INDICATOR/LENGTH byte
that is followed by data byte(s). This combination of
indicator/length byte and data byte(s) is repeated until
the end of the compressed data.
-The INDICATOR byte/bit flags the presence of compressed
data by having the TOP Order bit set on. The remainder
of the byte will indicate the length of the uncompressed
data.
-An indicator byte of '80'x (always the first byte of the
compressed field) indicates Compressed data of length
ZERO. There is NO following data byte!
-An indicator bit of '1nnnnnnn'B is followed by a single
data byte that is to be repeated '0nnnnnnn'B times into
the output buffer.
-An indicator bit of '0nnnnnnn'B indicates that the
following '0nnnnnnn'B bytes are simply copied from the
compressed record to the uncompressed buffer.
-This compression algorithm was determined by a few Google
searches and observations of the compressed data and did
not involve any non public knowledge of IBM's processing.
Thanks to Ian Gibson, CPT Global Ltd @ Bendigo & Adelaid Bank, OZ.
Thanks to Peter Turner, CPT Global Ltd @ Bendigo & Adelaid Bank, OZ.
the authors, and, for the CPU measurements on z/OS,
Thanks to Scott Chapman, American Electric Power, USA.
Change 27.259 Support for TMON FOR DB2 Records 'BA','BJ','BK','BL','BM'
VMACTMDB now decode the record-specific fields; previously, only
Sep 17, 2009 the headers were decoded for these subtypes.
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 27.258 Support for ACF2 SUBTYPE='O' OPENEDITION record creates
EXACFOR new ACFOR dataset.
IMACACF2
VMACACF2
VMXGINIT
Sep 16, 2009
Oct 8, 2009
Thanks to Steven Nelson, IBM Global Services, USA.
Change 27.257 Cosmetic. MXG added ***ERROR. SMF RECORD SUBTYPE GT 255
VMACSMF messages when an impossible value for one-byte SUBTYPE is
VMACMIM found when VMACSMF processes an SMF record with the flag
Sep 16, 2009 that the subtype field is populated, but it is at best
only a WARNING message that MXG has corrected the SUBTYPE
variable to the one-byte in byte 19 instead of byte 20.
This is important if you use IMACFILE or %LET MACFILE=
to select/skip SMF records based on SUBTYPE, or if the
SMF record with invalid subtype actually tests SUBTYPE.
-One WARNING ID=189 was flagged with the message, used
for the MIM SMF record; VMACMIM was examined and since
MXG variable SUBTYPE was not tested in that member, there
was no problem. However, the MIMSUTYP was incorrectly
as a two-byte value, so even though it was also not also,
VMACMIM was corrected, in case it's ever needed.
-I haven't (yet) figured out how to turn the warning off,
or maybe decide I should just remove it.
- it needs to precede IMACFILE, so the true subtype will
be populated in SUBTYPE for testing in that exit.
- some IBM records with fixed ID are already corrected
prior to the IMACFILE exit.
- IMACFILE is where you would expect to turn it off.
Thanks to Robert Blackburn, Dominion Resources Services, Inc, USA.
Change 27.256 The QACSLPAR file has 20 undocumented bytes after LPVRM;
VMACQACS the first eight are the SYSTEM ID, new variable LPSYSTEM,
Sep 14, 2009 and the next 12 bytes are skipped, for iSeries V5.4.0.
Thanks to David Bixler, FISERV, USA.
Change 27.255 -Variable SM1209CY is now RETAINed and KEEP= in all four
VMAC120 TYP1209x datasets, as that Enclave Token is needed to
Sep 14, 2009 combine records.
-Variable SM1209FI is now correctly input as &PIB.8.3 and
the divide by 4096 for SMF1209EV and SMF1209FI were
incorrect and are removed.
Thanks to Steiner Amot, VPS ASA, NORWAY.
Thanks to Bjorn Helgestad, VPS ASA, NORWAY.
Change 27.254 Members that read files with an INFILE statement that had
VMACMRKV only LRECL and BLKSIZE now use a Platform-Specific %MACRO
VMACPRPR to set RECFM=VBS on z/OS and RECFM=S370VBS on ASCII.
VMACTSMA See Change 27.311, which removed this change for NTSMF.
VMACNTSM
Sep 14, 2009
Change 27.253 SMF74NID (a/k/a SMF74DCT) is a 28-character field with
VMAC74 26 $EBCDIC text bytes, and two $HEX bytes at the end.
Sep 13, 2009 The final byte appears to always be '00'x, which doesn't
translate, but the penultimate byte has many different
hex values, which may or may not be changed when INPUT
as $EBCDIC, depending on the hex value of that byte.
This change inputs the first 26 as $EBCDIC26., but the
last two bytes are INPUT as $CHAR2. and then SUBSTRinged
back into SMF74NID, to prevent accidental translation.
Of course, those last two hex values may be unprintable
and could cause other problems if they are imported into
other programs; using FORMAT SMF74NID $HEX56.; would
prevent the unprintables, but the text would not be
readable to the human eye.
Thanks to Peter Enrico, Enterprise Performance Strategies, Inc, USA.
Change 27.252 Formats for many duration variables were not TIMEyy.x;
VMXGRMFI all of the duration variables are how TIME12.2 except for
Sep 13, 2009 BATRESP and TSORESP that are TIME13.3.
Change 27.251 -RMM processing now supports all possible date formats:
IMACEDGR RHDTFORM DESCRIPTION EXAMPLES
VMACEDGR A AMERICAN 12/31/1999 MM/DD/YYYY
Sep 11, 2009 E EUROPEAN 31/12/1999 DD/MM/YYYY
Sep 15, 2009 I ISO 1999/12/31 YYYY/MM/DD
Sep 17, 2009 J JULIAN 1999/365 YYYY/DDD
The original _EDGRDTE macro is no longer used.
-The Retention field RDRETCHR or RVRETCHR can contain text
non-date values of CATRETPD or CYCL/99999 or WHILECATLG.
RDWILCAT/RVWILCAT='Y' already existed for WHILECATLG; new
variables RDCYC999/RVCYC999/RDCATRET/RVCATRET are created
and the DATE variables RDRETDAT/RVRETDAT will be missing
values, if xxRETCHR has any of those 3 text values.
-An Original Expiration Date with 00/00/1999 (or any other
non-date value) is stored in new character variable
RDEXPDCH, and the DATE conversion is protected for '00'.
The value of RDEXPDTO will be a missing numeric date
value if RDEXPDCH contains a non-date value.
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 27.250 Protection for UNKNOWN TOKDANAM printed a message, but it
VMAC80A failed to prevent INPUT STATEMENT EXCEEDED RECORD LENGTH.
Sep 11, 2009 Protection now works.
The RDEFINE CFIELD statement can be used to define custom
fields and their attributes, with locally chosen names;
these new variables in TYPE80TK are populated if found
TOKTYPE ='TYPE'
TOKMAXLE='MAXLENGTH'
TOKFIRST='FIRST'
TOKOTHER='OTHER'
TOKHELP ='HELP'
TOKMIXED='MIXED'
TOKLISTH='LISTHEAD'
TOKURTLA='URTLABEL'
and these observations have TOKSUSBY='CFDEF' to identify
they are locally defined fields.
Thanks to Coen Wessels, IBM SWITZERLAND.
Thanks to Pierra Beda, IBM SWITZERLAND.
Change 27.249 Variable R747PAVG='RMF REPORT*AVERAGE*FRAME*PACING' is
VMAC74 created as R747PAVG=10**6*(R747PFPT/R747PNFT); to match
Sep 10, 2009 the value printed on RMF Reports.
Thanks to Robert Brosnan, Goldman Sachs & Company, USA.
Change 27.248 Change 27.165's insertion of VMXGOPTR cause the I/J vars
VGETDDS that were local to VGETDDs to be overridden by the I/J
VMXGOPTR vars used in VMXGOPTR causing looping and unexpected
Sep 10, 2009 results. Variable names in VMXGOPTR/VGETDDS were changed.
Sep 11, 2009 -Before, if you asked for GOOVOO, or DATEBASE, or GDGs, it
allocated all of them (ensuring they were there) and then
went thru the DDNAMES logic to ensure they were there.
Sort of silly really. Now if you ask for GOOVOO, DATES,
etc., it allocates the datasets and keeps track of them,
so now, the only time it goes thru the DDNAMES logic is
when that argument is used.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 27.247 FLAG1 tests for HyperBuf optional segments overlapped,
FORMATS causing some optional variable to be populated when they
VMACHBUF should have been missing; DATALAS-ESTDBUFS if FLAG1='1.'
Sep 9, 2009 and EXCPIPTH-INDXCISZ if FLAG1='.1'. The three tests are
now '10', '11', and '01' to only appropriately input.
-New $MGHBUFT format decodes FLAG1 to identify the type of
optional segment, if any, in this record.
Thanks to MP Welch, SPRINT, USA.
Change 27.246 Change 27.127 added KEEP= to TAPES, but variables DSN
DAILYDSN DSNBACTV and STPNAME were not kept, causing UNINITIALIZED
Sep 9, 2009 VARIABLE messages.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 27.245 zIIP and zAAPs are added to SAS/GRAPH hourly workload
GRAFWRKX reports, using PDB.RMFINTRV.
Sep 8, 2009
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 27.244 Variable OTRANNUM in VMAC110 was correctly input &PD.4 if
VMAC110 IMACEXCL was used, but the default INPUT without IMACEXCL
Sep 8, 2009 was incorrectly input as &PIB.4.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 27.243 Cosmetic, and only for MXG QA. SAS Option CHARCODE is
FORMATS enabled in FORMATS (Change 13.319) so that two-character
Sep 7, 2009 operators ?< and ?> can be used on both EBCDIC and ASCII
in place of Left Squiggly and Right Squiggly Brackets,
where they are needed for valid syntax for OTHER operand.
This change reinstates the default Option NOCHARCODE at
the end of FORMATS. The observed problem was seen only
in the single-step QA job (which begins with FORMATS);
with CHARCODE left enabled, the label of two variables
(TDSL12TY and QW0350SL), that happened to contain ?) text
were changed by CHARCODE to a right squiggly bracket, so
QA labels in DOCVER were NOT the actual variable labels.
These two-character operators are CHARCODE-translated:
Symbol Two-Character Operators
backquote (`) ?:
backslash (\) ?,
left brace ({) ?(
right brace (}) ?)
logical not sign (¬ or ^) ?=
left square bracket ([) ?<
right square bracket (]) ?>
underscore (_) ?-
vertical bar (|) ?/
Change 27.242 -Elimination of Numeric to Character Conversions in tests
ASUMCICS for VGETOBS.
ASUMCICX -If MXGMQADD=NO was specified but the _INMQ macro was not
VMXGUOW nulled, UNINITIALIZED VARIABLE messages were printed for
Sep 8, 2009 all of the MQ variables.
Sep 28, 2009 -If CICSTRAN has zero observations, PDB.ASUMUOW cannot be
populated, but it will be created with zero observations,
and MXGERROR message is printed on the log, and reading
of DB2ACCT/MQ data will not be done.
-Variable MQTRAN created in PDB.ASUMUOW to count MQs.
-Variable CPUMQMTM created in PDB.ASUMUOW as the sum of
QMACCPUT (now zero) WTASOTCT, WTASCMCT, and WTASBACT.
-Variable CPUUOWTM created in PDB.ASUMUOW as the sum of
CPUTM (CICS), DB2TCBTM (DB2) and CPUMQMTM (MQ-Series).
-Variable CPUTM (TASCPUTM+CPURLSTM) is created in PDB.CICS
by either ASUMCICS or ASUMCICX.
-VMXGOPTR stashing/revisions for OBS=0.
Change 27.241 SMF 80 record for RACFEVNT=79 with EXTLNTYP=379 segment
VMAC80A with EXTLNLEN=130 caused INPUT STATEMENT EXCEEDED RECORD
Sep 7, 2009 LENGTH ERROR because MXG only INPUT RACF379 $VARYING128.
The INFORMAT in that INPUT is now $VARYING255.
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 27.240 Cosmetic. Five R745Vxxx variables were added in 2000 to
VMAC74 TYPE74CA dataset, but the "DEVICE LSA SECTION" doesn't
Sep 7, 2009 exist and those variables are always missing or blank.
Their labels were changed, especially R745VSER, to avoid
confusion, and now are:
R745VBYW='R745VBYW*ALWAYS MISSING*DOES NOT EXIST
R745VFLG='R745VFLG*ALWAYS BLANK*DOES NOT EXIST
R745VNTR='R745VNTR*ALWAYS MISSING*DOES NOT EXIST
R745VNUM='R745VNUM*ALWAYS MISSING*DOES NOT EXIST
R745VSER='R745VSER*ALWAYS BLANK*DOES NOT EXIST
Thanks to Ray Dunn, CIGNA, USA.
Thanks to Deborah L. Soricelli, CIGNA, USA.
Change 27.239 MXG's full QA stream executes successfully with WPS 2.4
AUTOEXEW under both z/OS 1.9 and Windows/XP; essentially all MXG
MXGWPSV2 programs are now executable under WPS 2.4.
UTILSPAC
VMACEREP These changes are made in WPS 2.4:
VMACSMF -The runtime performance problem with PROC SQL has been
VMXGVTOC corrected, so the testing of the ANALCISH member with
Sep 6, 2009 REPORT=ALL is reinstated in the WPS QA job stream.
Oct 8, 2009 -The PROC PLOT option VPOS is now recognized.
Oct 13, 2009 -The option MAUTOLOCDISPLAY is now recognized.
-The INFILE option CCHHR is supported; circumvention code
that bypassed for QA execution is now revised to test
for &WPSVER GE 2.04 so these programs can now be used on
z/OS: TYPEEREP, VMXGVTOC, and UTILSPAC.
-The _INFILE_ Special Variable is now supported.
-Change 27.110 lists the other MXG programs that cannot
be run as-is with WPS; WPS replicates SAS V8.2, so the
new-in-SAS V9 features are, in general, not supported.
-For z/OS, the MXG JCL procedure MXGWPSV2, the DSNAME for
the WORKMDL='HLP.WPS.SASHELP' replaces WPSDATA because
Model datasets are no longer specified during install.
-The member AUTOEXEW is the example "autoexec" for WPS;
the members AUTOWPS and AUTOEXWP were only for testing
and have been deleted.
-The comments were revised in AUTOEXEW to identify options
that WPS does not currently support; none are required:
WPS 2.4 added supports these OPTIONS
OPTIONS MAUTOLOCDISPLAY;
OPTIONS SORTSEQ=ASCII;
OPTIONS VALIDVARNAME=V7;
-On z/OS, WPS requires a larger REGION size than SAS, with
BUILDPDB needing REGION=230M while SAS used REGION=125MB.
For the full QA job, however, WPS needed a REGION=1200MB,
while SAS V9.2 needed REGION=165MB. WPC will investigate
why that large region was required, but it appears to be
unique to the MXG QA job, which executes over 20,800 DATA
and PROC steps. A large region requirement has not been
reported as an issue by any site running MXG under WPS.
WPS QA took 120 CPU minutes, SAS QA took 53 minutes, on
a z/OS machine with SU_SEC=10000.
-Oct 30: WPS 2.4 supports the FILENAME=variable option on
the INFILE statement, so VMACSMF was revised.
Change 27.238 ERROR: SRCE1 HAS ALREADY BEEN DEFINED AS NUMERIC if some,
ANALDB2R but not all of the AUDIT sub-reports were requested.
VGETOBS The repair led to a MAJOR cleanup of ANALDB2R that also
VMXGSUM significantly reduced the run time (from 5 minutes to
VFMT102 a few seconds for the AUDIT reports).
Sep 6, 2009 Originally:
-Data step creates DB2WORK as union of all input datasets
-Data step creates DB2WORK1 TIMES from DB2WORK
-SORT DB2WORK1 (with MANY variables, long times possible)
-SORT TIMES
-MEAN TIMES into TIMERNGE
-Data step creates PREPRINT merging DB2WORK1 TIMERNGE
-DATA _NULL_ data step does printing
Now
-For each audit type if the data is present and non-zero
OBS View into SORT
-TIME view using datasets created into SORT
-MEANS of TIME into TIMERNGE
-Data step creates view PREPRINT using only the datasets
created in first section and TIMERNGE
-DATA _NULL_ step does printing code for datasets that
does not exist is never generated
-The DATABASE= argument did not select for AUDIT reports.
Note that if the SMF data does NOT include the open event
record (opened before the beginning of this SMF data),
the printed database will be the undecoded hex value,
and won't be the decoded database name in text.
-The VGETOBS, VMXGSUM, VMFT102 members were NOT altered in
this change, but their new updates (Changes 27.237,
27.234, 27.236) are required to support this change to
ANALDB2R.
Thanks to Sam Knutson, GEICO, USA.
Thanks to Henry Boone, GEICO, USA.
Change 27.237 Enhancement. If no DDNAME argument (zero length) then
VGETOBS the DATASET argument is examined and if is x.y, it will
Sep 5, 2009 be split into DDNAME and DATASET so the PROC SQL can be
Sep 28, 2009 invoked. If DATASET contains x.y syntax AND there is a
DDNAME argument present, VGETOBS will fail with message
that that is not allowed.
Change 27.236 Cosmetic corrections to eliminate character to numeric
VFMT102 conversion messages; VFMT102 in ANALDB2R, and ANAL30DD.
ANAL30DD
Sep 5, 2009
Change 27.235 These six variables in MQMQUEUE are now converted to the
VMAC116 local time zone; previously, they were on GMT:
Sep 4, 2009 WQOPENTI WQCLOSTI WQTTTIME WTASSTRT WTASINTS WTASINTE
Oct 12, 2009 The algorithm used to calculate the GMTOFF in the absence
of the actual value in the record now used is:
GMTOFF=3600*FLOOR(100*(FLOOR(SMFTIME/100)
-FLOOR(WTASINTE/100))/3600);
and the correction would then be:
WTASINTE=WTASINTE+GMTOFF; .
Change 27.234 VMXGSUM is revised so an OUTCODE= argument is not needed
VMXGSUM in many cases where it was previously required, so those
Sep 5, 2009 VMXGSUM callers that could be revised to remove OUTCODE=
are changed, thereby eliminating the second DATA step,
and, a full pass of the output dataset.
Previously OUTCODE= arguments were needed to set LENGTH
and FORMATs, but the SAS V8 INHERIT option made the extra
step unnecessary.
-The second data step can be skipped if INTERVAL= NE NONE
and the DATETIME= argument's variable is in the BY list.
-Conditions that will force the second data step:
%IF &NUMNORM NE 0
OR &ERASEOUT NE NO
OR %LENGTH(&OUTCODE) NE 0
OR %LENGTH(&OUTCODE1) NE 0
OR %LENGTH(&OUTCODE2) NE 0
OR %LENGTH(&FREQ) NE 0
OR %LENGTH(&DURATM) NE 0
OR &INTERVAL NE NONE
OR &NEWSHIFT EQ Y
OR &SASVER LT 7
Change 27.233 Debugging PUT statement now commented out.
VMAC117
Sep 4, 2009
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 27.232 TMON/DB2-created SMF 101 Subtype 0 record has an invalid
VMACDB2 OFFQLAC value, @1875 vs the real @1879 location, and the
Sep 3, 2009 extra 4 bytes were added to make QLACLEN=232 when only
228 bytes are actually present. Unfortunately, QLACLEN
of 232 says the QLACOFF1 offset to a "truncated QLACLOCN
field" exists in two of those last 4 bytes, so MXG INPUT
the QLACOFF1 offset and attempted to INPUT, causing an
INPUT STATEMENT EXCEEDED RECORD LENGTH ERROR. This
(possibly temporary) change detects the record is NOT an
IBM record (because OFFQLAC is GT OFFPROD), adds 4 to
OFFQLAC and subtracts 4 from LENQLAC so MXG can input the
mis-aligned record, and sets TMDBQLAC='Y' flag that this
was done.
-QLACMDWT is a binary value in the TMON/DB2 record, but it
is a floating point value in IBM records, so this change
uses TMDBQLAC if set to INPUT the incorrect informat.
-Support at TMON/DB2 will be contacted and this text will
be updated when they respond.
Thanks to Mary Vollmer, MGIC, USA.
Change 27.231 The four listed ASUMs did not create variable ZDATE/ZTIME
ASUMDB2P while the other thirty-seven ASUMs did.
ASUMDB2S
ASUMDB2G
ASUMDB2S
Sep 3, 2009
Thanks to Denise Willers, InfoCrossing, USA.
Change 27.230 Variable LASTCLAS in IMF dataset CIMSPROG (from 'F9'x)
VMACCIMS was incorrectly INPUT @77 as $CHAR1, but it is now INPUT
Sep 2, 2009 @76 as $CHAR2 and formatted $HEX4.
Thanks to Brian Cummings, Federal Reserve Information Technology USA
Thanks to Fritz Zeigler, Federal Reserve Information Technology, USA
====== Changes thru 27.229 were in MXG 27.08 dated Sep 1, 2009========
Change 27.229 Support for z/OS 1.11, COMPATIBLE.
EXTY8224 -TYPE 0. New variable:
EXTY8225 CVTTZ ='CVTTZ*TIME DIFFERENCE*LOCAL*TO GMT'
EXTY8226 -TYPE1415. NO NEW DATA, but lots of text inserts about
IMAC82 assembling the IFGSMF14 Macro with DSECT=YES, which is
VMAC0 why it is flagged in the SMF Manual as changed.
VMAC82 -TYPE30. NO NEW DATA, only one line of text updated.
VMXGINIT -TYPE82. New subtypes 24, 25, and 26.
May 2, 2009 -TYPE92. Subtype 15 now documented, but MXG supported
Sep 2, 2009 was added in Change 26.277 for APAR OA24208.
-TYPE1415 New variables DCBEEX31 XTIOTYES created from
SMF14FLGS.
-Dec 3, 2009: CHANGE 27.325 is required for z/OS 1.11.
Change 27.228 Support for APAR OA30197, adds SMF30ASI, new MXG variable
VMAC30 ASID in ID Segment of all SMF 30 records. Kept in the
Sep 1, 2009 TYPE30 ASID-level datasets (_1,_4,_5,_V,_6).
Change 27.227 Observations were not output because DO loop logic was
VMACINSY incorrect for the INSYAUID='D' records. Variable INSYATA
Sep 1, 2009 is now converted to EBCDIC text.
Thanks to Mark Cohen, DTS, ITALY.
Change 27.226 Dataset T112DTCO, DATACOM DETAIL, variables were invalid
VMAC112. due to misalignment. Dataset T112MQCT variable MATTACH
Aug 31, 2009 and dataset T112DTCT variable DATTACH were INPUT $CHAR8,
but they are now seen to be TODSTAMP values, so they are
changed from CHAR to NUM and formatted DATETIME25.6, and
are observed to be slightly prior to the UOWTIME.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 27.225 Cosmetic. Long messages (listing all requested reports)
ANALRMFR are split and shifted left for readability, and the list
Aug 31, 2009 of valid INTERVAL= values was updated.
Change 27.224 Eight new IBM fields starting with R7452xxx were named in
VMAC74 MXG as R7451xxx, accidentally, as all of the other fields
Aug 31, 2009 in that segment are IBM-named R7451xxx. But these eight
R7452XTY R7452XFL R7452PRO R7452PWO R7452PBR
R7452PBW R7452PRT R7452PWT
are all a second field name for the same field location,
and apparently IBM decided to note that difference by
naming them with a 2 vs a 1. In any event, to match the
SMF Manual field names in the MXG Variable names, those
eight are now named with a 2 instead of a 1.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 27.223 New "TOP" DB2 Report ranks resource usage by correlation
ANALDB2T id and authid, for these resource metrics:
Aug 30, 2009 CLASS*1 CPU*RANK
CLASS*2 CPU*RANK
ELAPSED*RANK
GET*PAGE*RANK
TOTAL*GET*PAGES
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 27.222 Support for NDM-CDI NDMRTYPE 'SC' and 'S2' records. The
FORMATS two datasets NDMSC and NDMS2 were already created, but
VMACNDM they only contained the header variables until now.
Aug 30, 2009
Thanks to Robert S. Zimmerman, HMS, USA.
Change 27.221 Support for zOSEM Operating System Environment Manager
EXOSEMCM from Trident Services user SMF record creates 3 datasets:
EXOSEMRE
EXOSEMWT DATASET DATASET DATASET RECORD
FORMATS SUFFIX NAME LABEL SUBTYPE
IMACOSEM
TYPEOSEM OSEMCM OSEMCMD OSEM FEMCNTL CMD 1
TYPSOSEM OSEMWT OSEMWTO OSEM FEMWTO CMD 2
VMACOSEM OSEMRE OSEMRES OSEM JES2 EXIT44 3
VMXGINIT
Aug 30, 2009
Thanks to Larry Stahl, IBM Global Services, USA.
Change 27.220 MXG 27.06-27.07. %ANALCNCR failed if INDATA= specified
ANALCNCR more than one dataset. "Cosmetic" protection was added
BUIL3005 by Change 27.165 to verify that the input dataset exists,
BUILD005 to avoid DATASET NOT FOUND errors, but it only parsed the
MNTH72 1st INDATA (to get DDNAME and DATASET to pass to VGETOBS,
TRND72 as PROC SQL which requires separate arguments). Now,
Aug 29, 2009 each token in the INDATA= argument is parsed & verified.
If all datasets have zero observations, an MXGWARN is
produced at the beginning and if there are zero obs in
the output dataset another MXGWARN will appear.
If all datasets in the INDATA= do not exist, %ANALCNCR
will stop processing, but if one or more do exist, the
output dataset will be created and populated if possible,
but MXGWARN messages will identify which INDATA= datasets
did not exist. Prior to Change 27.165, multiple datasets
were supported because the only INDATA reference was the
SET &INDATA; statement which read all of the input, but
that statement failed if any input dataset did not exist.
-The only MXG member that invokes %ANALCNCR with multiple
INDATA= datasets is ANALHTML, which exposed this error,
with its INDATA=PDB.STEPS SPIN.SPIN30_4, statement.
-In testing the new %ANALCNCR with ANALHTML, SAS printed
warnings that MSOUNITS had different lengths in those two
datasets. Investigation found MSOUNITS & SERVICE weren't
always stored in 8 bytes, so updates were made to members
BUILD005 BUIL3005 MNTH72 and TRND72 so that all instances
of variables MSOUNITS and SERVICE are now LENGTH 8.
-All INTERVAL= arguments that specify an interval token
with a fixed-length interval duration are supported.
TIMER is set to the interval and SYNCINTV=YES is used
(but that could be overridden in your %ANALCNCR).
Thanks to Tony Curry, BMC, USA.
Change 27.219 TYPE11GD dataset variables CTGIAVRS and CTILAVRS were
VMAC111 reversed in their INPUT locations.
Aug 28, 2009
Thanks to Jim Poletti, Edward Jones, USA.
Thanks to Gordon E. Griffith, Edward Jones, USA.
Change 27.218 Variable SMF70LAC in PDB.RMFINTRV was the maximum value
VMXGRMFI during the sub-intervals that were summarized; it is now
Aug 28, 2009 the average value, so it matches PDB.ASUMCELP values.
However, the RMF reports may print that Maximum value of
any inputted sub-interval.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.217 PDB.TYPE70PR with SMF70CIN blank but SMF70ONT nonzero was
VMAC7072 created if the last LPAR was offline (LPARCPUX=0). That
Aug 28, 2009 caused NRCIXGT0 to be a missing value, so the second test
IF NRCIXGT0 GT 0 THEN ... was not executed. That second
test is now redundant, as SMF70CIX always exists now, so
that IF ... END was removed. Error was introduced in
MXG 27.03 by Change 27.075.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 27.216 Change 27.126 accidentally removed SYTLPNAM from the KEEP
VMACXAM list for XAMSYT dataset, and left it in the KEEP list for
Aug 28, 2009 the XAMSYU dataset.
Thanks to Douglas C. Walter, Citigroup, USA.
Thanks to Tony Curry, BMC, USA.
Change 27.215 TMON/CICS Version 3.1 INPUT STATEMENT EXCEEDED RECORD
VMACTMO2 error with 'TI' (Statistics Interval) record; the segment
Aug 26, 2009 of data starting with TIMQSOPC exist in 3.1, but MXG only
input those fields for TMMDVREL GE 3.2; the test before
that INPUT statement was changed from 3.2 to 3.1.
Thanks to Dianne Dunklau, Kohls, USA.
Change 27.214 Summarized RMFINTRV/ASUM70PR output datasets could have
VMXGDUR the STARTIME/SMF70GIE values early by one INTERVAL unit
VMXGRMFI (e.g., data STARTIME midnight, INTERVAL=HALFHOUR caused
VMXG70PR output STARTIME of 23:30) after Change 27.178 used the
Aug 28, 2009 SMF70GIE vice STARTIME (because of unstable STARTIMEs).
Note Jan 21, 2010: "Unstable as in exactly one second
Nov 10, 2009 later than the expected Start of Interval."
ASUM70PR -A new argument FLORCEIL=FLOOR/CEIL is added to VMXGDUR
ASUMCAPT with FLOOR (unchanged) as the default, and the %VMXGDUR
ASUMMIPS calls in VMXGRMFI and VMXG70PR that interval the
ASUMSMFI SMF70GIE/SYNCTIME end times now specify FLORCEIL=CEIL.
No user had reported/noticed this error (yet!).
The rest of this text was REVISED when CHANGE 27.308
reset the SYNC59=NO default back in place in MXG 27.10:
-For summarizing INTERVAL data ONLY (RMFINTRV, SMFINTRV,
CICINTRV, etc datasets with existing interval start/end):
If you still specify SYNC(59) to write Interval data in
minutes 59,14,29,44, the SYNC59=YES parameter can be used
to change the DATETIME to "pretty" 00,15,30,45 startimes.
This is needed when SYNC(59) is in SYS1.PARMLIB members
SMFPRMxx or ERBRMFxx in SYS1.PARMLIB.
Using the FLORCEIL=FLOOR to calculate the interval start,
with SYNC(59) data and INTERVAL=HOUR, for time 19:59:
SYNC59=YES adds one minute to DATETIME, so 19:59 becomes
20:00, and the FLOOR(DATETIME) sets 20:00 as the Start.
This is correct, hour 20 for the 19:59-20:58 interval.
SYNC59=NO leaves the DATETIME as is, so FLOOR(DATETIME)
is 19:00 for the Start, WHICH IS THE WRONG HOUR!!!
SYNC(59) data REQUIRED SYNC59=YES for correct output.
Using the FLORCEIL=FLOOR to calculate the interval start,
consider SYNC(00) data and INTERVAL=HOUR, for time 20:00:
SYNC59=YES adds one minute to DATETIME, so 20:00 becomes
20:01, but the FLOOR(DATETIME) sets 20:00 as the Start,
which is what you wanted, even though the data is (00).
SYNC59=NO leaves the DATETIME as is, so FLOOR(DATETIME)
sets 20:00 as the Start, WHICH IS ALSO WHAT YOU WANTED.
But, using the FLORCEIL=CEIL to calculate interval end,
SYNC59 must NOT be used. With datetime 19:59 or 20:00,
the CEIL(DATETIME) returns 20:00 with SYNC59=NO. But if
SYNC59=YES added a minute here, then 20:00 would be 20:01
and CEIL(DATETIME) would then (INCORRECTLY) be 21:00.
Therefore, when using FLORCEIL=CEIL, VMXGDUR does NOT
change the value in DATETIME before the CEIL(DATETIME),
even if SYNC59=YES was specified.
Only ASUM70PR/VMXG70PR and RMFINTRV/VMXGRMFI currently
use the FLORCEIL=CEIL option to group by End Interval,
but only internally; the final sorts are BY STARTIME.
-These members were changed from SYNC59=NO to SYNC59=YES:
ASUM70PR ASUMCAPT ASUMMIPS ASUMSMFI VMXG70PR VMXGRMFI
-THE PRECEDING IS ONLY FOR SUMMARIZING INTERVAL DATA.
-FOR DETAIL TRANSACTIONS, SYNC59=NO MUST ALWAYS BE USED.
MXG 27.08 CHANGED TO SYNC59=YES IN VMXGDUR.
(This caused PDB.CICS transaction's HOUR to change.)
MXG 27.10 RESTORED THE SYNC59=NO DEFAULT IN VMXGDUR.
Change 27.213 HFS and zFS EXCPs are counted in EXCPTOTL and EXCPNODD
BUILD005 (see MXG Newsletter FIFTY-FIVE, MVS Technical Note 1)
BUIL3005 but there are no DD Segment EXCP counts for HFS/zFS, so
VMAC30 you don't know how much of EXCPNODD is due to HFS/ZFS, so
Aug 21, 2009 you can't subtract the HFS/ZFS EXCPS from EXCPTOTL.
Sep 1, 2009 This change creates four new variables in TYPE30_V and
TYPE30_4 datasets:
USSEXCPS='USS-OMVS*TOTAL*EXCPS'
USSBYTES='USS-OMVS*TOTAL*BYTES'
USSCALLS='USS-OMVS*TOTAL*CALLS'
USSCPUTM='USS-OMVS*SYSCALLS*CPU*TIME'
with the sum of those counts from all OMVS segments in
the interval and step termination SMF 30 records.
Those variables are also now summed in PDB.STEPS and
PDB.JOBS when BUILDPDB is used to process SMF 30s.
-In testing this change, subtype 5 records for BPXAS STC
have all resource variables with zero value, even STEPNR,
and some zeros cause missing value calculations. Logic
was revised to prevent those harmless but confusing notes
on the SAS log for those records.
See MXG Newsletter FIFTY-FIVE, MXG Technical Note titled
1. Summary: "EXCP" counts recorded for access to HFS ....
Change 27.212 Support for APAR OA30006 for DCOLLECT, adds 8-byte fields
VMACDCOL at the end of the record for the dataset storage sizes in
Aug 21, 2009 DCOLDSET dataset. The new fields replace the value in
existing variables DCDALLSP DCDUSESP DCDSCALL DCDNMBLK
when the new fields are populated.
Change 27.211 Support for new-in-z/OS 1.10 DFSORT variables added to
VMAC16 existing TYPE16 dataset:
Aug 21, 2009 ICEINMRG='INTERMEDIATE*MERGES*PERFORMED'
ICEMNFLG='SIZE=MAX*IN*EFFECT?'
ICEMNVLX='SPECIFIED*OR DEFAULT*STORAGE'
ICEMNVLY='THEORETICAL*STORAGE*AVAILABLE'
ICEMNVLZ='AVAILABLE*STORAGE'
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 27.210 A harmless Division By Zero when creating PDB.DB2STATS
VMACDB2 occurred in calculating variable THRDFTPT (to mimic the
Aug 20, 2009 IBM MENU2 report), added by Change 27.097, if variables
QW0225AT and QDSTCNAT were both zero. Divide protected.
Thanks to Cletus McGee, Alfa Mutual Insurance Company, USA.
Change 27.209 TMON/DB2 BF record's SQL text is not quite as documented.
VMACTMDB BF0142LL, the "length" is 52, indicating there should be
AUG 19, 2009 50 bytes of text, but the next two bytes are INPUT in
new MXG variable BF0142RL, which is the original (real)
length of the original SQL text, and then, instead of the
documented 50 bytes of sql text, the record contains only
the first 48 bytes of text, kept in BF0142TT. BF0142LL
is then reduced by 2 to a value of 50 in TMDBBF dataset.
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 27.208 Cosmetic. Calculation of AVGWKSET caused notes on the log
VMAC30 "Missing Values were generated" if MULTIDD='Y', because
AUG 19, 2009 those records contain ONLY DD segments. Those notes are
now eliminated by only calculating for "real" records.
Change 27.207 MXG 27.07. Change 27.174 stopped deaccumulation of the
VMACDB2 PDB.DB2STATS vars QSSTCONT and QSSTCRIT, incorrectly, as
Aug 18, 2009 both are accumulated and must be deaccumulated.
Thanks to Bill McDonald, Kimberly-Clark, USA.
Change 27.206 The LABEL for variables STEPNAME and PROCSTEP in VMAC42
VMAC42 were the variable name, unlike all of the other labels
Aug 18, 2009 for those common variables; if you added processing of 42
records as the last physical VMAC in your BUILDPDB, those
STEPNAME='STEPNAME' and PROCSTEP='PROCSTEP' labels were
used for all BUILDPDB-created datasets. VMAC42 now has
STEPNAME='STEP*NAME' & PROCSTEP='PROCEDURE*STEP*NAME'
Thanks to Bret Hoesly, Telephone & Data Systems, Inc, USA.
Change 27.205 Documentation. PDB.TYPE70PR observations for ICF engines
VMAC7072 with the LCPUPDTM (CPU Dispatch Duration) slightly larger
Aug 18, 2009 than the SMF70ONT (Online Duration) have been observed.
The maximum difference in an LPAR engine was 52 millisec,
0.052 seconds, but in that same interval, the PHYSICAL
ICF engine recorded 0.026 seconds, so the total ICFACTTM
for that interval was 78 milliseconds larger than the
online duration of exactly 900 seconds for that interval.
But some intervals do not always have exactly 900 seconds
online; in 26 intervals, 13 were exactly 900 seconds, 6
were shorter, by as much as 0.018 seconds, and 7 were
longer, by as much as 0.018 seconds. This was z/OS 1.9
on a 2094-720 with 1 ICF, 2 IFLs, and 17 CPs. The ICF
Percent Busy was 100.00008 with that largest difference;
the only circumvention is to test the PCT value and reset
it to 100% if greater than 100 (but, if greater than 101%
print a warning message and investigate further).
Thanks to Nicholas Ward, Centrelink, AUSTRALIA
Change 27.204 Change 27.154 did not protect when the offset to the Path
VMAC92 Section was non-zero but there was no Path Section; it
Aug 17, 2009 caused an INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Change 27.203 MXG 27.06-MXG 27.07, PDB.ASUMTALO had too few obs created
ANALCNCR due to an error introduced in ANALCNCR in Change 27.165.
Aug 17, 2009 The ANALCNCR error ONLY occurs if the TIMERNGE= argument
ASUMTALO was used; ASUMTALO is the only MXG member that invokes
%ANALCNCR with a TIMERNGE= argument. Change 27.165 added
elimination of character-to-numeric conversion messages,
but four typo's in new code stored &LOTIME into &HITIME.
Only ANALCNCR was changed in this change; ASUMTALO is
listed only to document it is impacted by this error.
-You should check your tailoring/report source libraries
to see if %ANALCNCR is used with the TIMERNGE= argument.
This ANALCNCR "utility" is inconsistently named, since it
creates an output dataset, rather than an analysis; it
is used to count the number of concurrent events across
time (like tape drives allocated each hour in ASUMTALO).
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Change 27.202 MXG 27.07. Debugging PUT statement at line 757 was
VMAC116 removed.
Aug 14, 2009
Thanks to Alfred Holtz, Medco Health Solutions, USA.
Change 27.201 More DB2 Updates.
ANALDB2R
READDB2
Aug 12, 2009
Change 27.200 Support for CICS/TS 4.1 GA updates/documentation notes:
EXCICMLR -Format MG110MP updated for new TCB Pool values of XPLINK,
EXCICRLR SSL, and THRD, new formats MGCICAT, MGCICRT created.
EXCICSJS -Dataset CICECC new variables:
EXCICW2R ECCCANAM ECCCAPOI ECCCAPTY ECCEBNAM ECCEVCAP ECCEVNAM
FORMATS -Dataset CICECG new variables:
IMAC110 ECGFLFAI ECGCAPFA ECGEVLCO ECGEVLOT
VMAC110 -Dataset CICECR new variables:
VMXGINIT ECRCHGAG ECRCHGDT ECRCHGUS ECREBNAM ECRGRFRM ECRINSAG
Aug 16, 2009 ECRINSDT ECRINSUS
-Dataset CICEPR new variables:
EPGSYNBK EPGEVLCO EPGEVLOT
-New Statistics Datasets created:
dddddd dataset description stid
CICRLR CICRLR CICS BUNDLE 100
CICW2R CICW2R CICS ATOMSERVICE 110
CICMLR CICMLR CICS XMLTRANSFORM 113
CICSJS CICSJS CICS JVMSERVER STATISTICS (RESID 116
Note: STID=79, STIMNR is not a Statistics DSECT, but is
a SUBTYPE=1,MNSEGCL=5 Transaction Record; support
for which was added in MXG 20.20, Change 20.200.
STID=84, STIMNT is never created in SMF records;
it is an online interface only.
-Change 27.032 noted there are 3 new TCBs in CICS/TS 4.1,
T8, EP, and TP, but only T8CPUT is recorded in CICSTRAN.
The EP TCB for Event Processing is explicitly NOT in the
CICSTRAN data, because IBM states that processing of the
new Business Event is NOT to be chargeable to users.
A TP TCB is created for every JVMSERVER resource def that
is installed and enabled, but I have not found a reason
why they are not captured in CICSTRAN.
-DOCUMENTATION. CICS Statistics datasets CICDS, CICDSPOO
have many variables starting with DSG,DS1-DS9,DSA-DSN,
and their labels were not consistent. This list is now
added at the bottom of VMAC110, and the labels revised:
DOCUMENTATION OF THE VARIABLES STARTING WITH DS.
TWO DATASETS CONTAIN VARIABLES THAT START WITH DS:
DATASET CICDS - DISPATCHER STATISTICS:
- "INTERVAL" VARIABLES STARTING WITH DSGXXXXX
- "PER TCB" VARIABLES STARTING WITH DSG DS1-DS9 DSA-DSN
DATASET CICDSPOO - TCB POOL STATISTICS:
- "PER POOL" VARIABLES STARTING WITH DSG DS1-DS5
DATASET CICDS - DISPATCHER STATISTICS:
- "INTERVAL" VARIABLES STARTING WITH DSG:
DSGNTCB DSGCNT DSGEJST DSGICVRT DSGICVSD DSGICVT
DSGMBTCH DSGPNT DSGPRIAG DSGPTCB DSGSRBT DSGSTART
DSGLSTRT DSGSTSKS DSGXSCNN DSGXSCNS DSGXTCBD
- "INTERVAL" VARIABLES ALWAYS MISSING VALUES:
DSGAMXTC DSGAMXTL DSGAMXTP DSGLRT DSGMAXOP DSGTAMXT
DSGTL DSGTOTWT
DATASET CICDS - DISPATCHER STATISTICS:
- "PER TCB" VARIABLES STARTING WITH DSG DS1-DS9 DSA-DSN
(The TCB NUMBER HAS CHANGED BETWEEN CICS RELEASES)
3.2 4.1 TCB MXG VAR
NUM NUM NAME PREFIX DESCRIPTION
-- H8 DSC H8 - NOT IN CICS/TS 3.1+
1 QR DSG* QUASI REENTRANT MODE
2 RO DS2* RESOURCE OWNING MODE
3 CO DS3* CONCURRENT MODE
4 SZ DS4* SECONDARY LU MODE
5 RP DS5* ONC/RPC MODE
6 FO DS6 FILE OWNING MODE
7 SL DS7 SOCKETS OWNING MODE (SL)
8 SO DS8 SOCKETS OWNING MODE (SO)
9 SP DSH SOCKETS PTHREAD OWNING MODE (SP)
10 EP DSM EVENT PROCESSING MODE
10 12 D2 DSD D2 - DB2 MODE
11 13 JM DSE JM - JVM CLASS CACHE MODE
11 TP DSN TP - THREADED TCB OWNING MODE
12 14 S8 DSB S8 - SOCKETS (SSL) MODE
13 15 L8 DSA L8 - OPEN MODE CICS
14 16 L9 DSI L9 - OPEN MODE USER
15 17 J8 DS9 J8 - OPEN MODE CICS
16 18 J9 DSF J9 - OPEN MODE USER
17 19 X8 DSJ X8 - OPEN MODE CICS
18 20 X9 DSK X9 - OPEN MODE USER
19 21 T8 DSL T8 - JVM MULTITHREADED
THE ABOVE TABLE MAPS EACH TCB NAME TO ITS VARIABLE PREFIX.
THESE "PER TCB" VARIABLES ARE POPULATED:
DS.ACT DS.NTCBA DS.PERCT DS.START DS.SYSW DS.TCBAF
DS.TCBAL DS.TCBCA DS.TCBCU DS.TCBDO DS.TCBDS DS.TCBDU
DS.TCBDX DS.TCBMD DS.TCBMM DS.TCBMP DS.TCBNM DS.TCBPA
DS.TCBPU DS.TCBST DS.TCT DS.TDT DS.TWT
THESE "PER TCB" VARIABLES ALWAYS HAVE MISSING VALUES:
DS.PERCT DS.TCBF1 DS.TCBF2 DS.TCBF3
DS.TCBF4 DS.SCT DS.SWT
DATASET CICDSPOO - TCB POOL STATISTICS:
- "PER POOL" VARIABLES STARTING WITH DSG DS1-DS5
DSG OPEN POOL (CONSISTING OF L8 AND L9 TCBS)
DS2 JVM POOL (CONSISTING OF J8 AND J9 TCBS)
DS3 XP POOL (CONSISTING OF X8 AND X9 TCBS)
DS4 SSL POOL (CONSISTING OF S8 TCBS)
DS5 THRD POOL (CONSISTING OF T8 TCBS)
J8 L8 S8 T8 AND X8 TCBS ARE CICS TCBS.
J9 L9 AND X9 TCBS ARE USER TCBS.
"TCB POOL" VARIABLES HAVE DSG,DS1,DS2,DS3,DS4,DS5 PREFIX:
DS.CMMWS DS.CMMWT DS.CNUAT DS.CNUUS DS.CURNW DS.CURWT
DS.MMWTM DS.MMWTS DS.MXTCB DS.NTCBL DS.PEANW DS.PMWWS
DS.PNUAT DS.PNUUS DS.TCBPN DS.TOTMT DS.TOTMW DS.TOTNW
DS.TOTWL
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 27.199 Documentation of this error message:
JCLTEST9 ERROR: PHYSICAL FILE DOES NOT EXIST, ATP1DKP.ADM.DATA.
Aug 12, 2009 occurs when a FILE ADM statement was found, but there was
no //ADM DD in the job. SAS then looks for a file named
JOBNAME.FILENAME.DATA, and fails.
Change 27.198 Even when PDBOUT= was not specified, so the null default
ANALRMFR (write to //WORK) was desired, ANALRMFR still wrote the
Aug 12, 2009 TYPE7xxx datasets to //PDB instead of //WORK. %LETs were
added to protect the SPLIT70 logic.
Thanks to Kim Westcott, New York State Office of Technology, USA.
Change 27.197 Change 27.175 added DB2STATB/DB2STATS/DB2GBPST but failed
ANALDB2R (VARIABLE SYSTEM NOT FOUND) if DB2STATB was redirected to
Aug 12, 2009 a separate input DDNAME.
Thanks to Scott Wiig, USBank, USA.
Change 27.196 Change 27.138 heuristic test for LENGTH=412 for subtypes
VMAC85 78,79,88 did not generalize and still failed with record
Aug 12, 2009 from z/OS 1.10 subtype 78 record. The test was revised
to test R85PVRM IN (1030 1090 1100 1110) to hopefully
protect 1.9, 1.10 and 1.11 records, but only 1.10 and
ancient 1.30/1.40 records are validated with SMF data.
Thanks to Brian Felix, Wachovia Bank, USA.
Thanks to Mike Spires, Wachovia Bank, USA.
====== Changes thru 27.195 were in MXG 27.07 dated Aug 11, 2009========
Change 27.195 Documentation only. When IFCIDS=ACCOUNT is specified,
READDB2 READDB2 automatically creates the DB2ACCTB dataset, but
Aug 11, 2009 when BUILDPDB/TYPEDB2 is used, the EXDB2ACB exit is used.
So if you (incorrectly) had a DELETE statement in your
tailored EXDB2ACB member, the number of observations that
were created in DB2ACCT/DB2ACCTB/DB2ACCTG were much less
with BUILDPDB/TYPEDB2 than with READDB2. The EXDB2ACB
exit is the ONLY DB2 exit that is overridden in READDB2.
Change 27.194 These variables from the LPAR Object in NMON/TAPAS record
VMACNMON are now input and kept:
Aug 11, 2009 CAPPED EC_USER EC_SYS EC_WAIT EC_IDLE VP_USER
VP_SYS VP_WAIT VP_IDLE FOLDED POOL_ID
Thanks to Steve Dyck, Canadian Depository for Securities, CANADA.
Change 27.193 READDB2 with Change 27.169 did not copy all ACCOUNT data
READDB2 sets to the PDBOUT= parameter, when it was used.
Aug 11, 2009
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 27.192 Incorrect READTIME (date in 2010) because CA=7 overlaid
VMAC110 the first byte of the time part with 'EE'x, but CA is
Aug 11, 2009 then supposed to correct that overlay in the SMF write
exit, which requires specific code for each record type.
Apparently, CA-7 has failed to protect the SMF 110s,
but MXG detects now and corrects READTIME in SMF 110.
Search CHANGESS for "UCC7" LAST for further info.
Thanks to Marnel Groebner, State of Washingon, USA.
Change 27.191 Variable ACTVWSS, working set size, in dataset XAMUSR,
VMACXAM was incorrectly multiplied by 4096; it is already in
Aug 11, 2009 bytes, not KB, so the multiply was removed.
Thanks to Chris Morgan, CitiCorp, ENGLAND.
Change 27.190 Dataset TMS.TMS observations with DEVTYPE blank were
VMACTMS5 found with TRTCH='D0'x and 'EE'x, and TMS shows those
Aug 10, 2009 as DEN 3590 and 3592, so those hex values are now mapped
to the DEN values in DEVTYPE.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 27.189 Support for Serena's StarTool IOO Product's USER SMF
EXIOOVBU creates 10 datasets:
EXIOOQBU
EXIOORBL DATASET DATASET DATASET
EXIOOVUS SUFFIX NAME LABEL
EXIOOVRP
EXIOOVX1 IOOVBU IOOVBUF VSAM BUFFER OPTIMIZATION
EXIOOVX2 IOOQBU IOOQBUF QSAM BUFFER OPTIMIZATION
EXIOOVX3 IOORBL IOORBLK QSAM BLKSIZE OPTIMIZATION
EXIOOVX4 IOOVUS IOOVUSR USER BLDVRP
EXIOOVX5 IOOVRP IOOVRPB BLDVRP OVERRIDE
FORMATS IOOVX1 IOOVEX1 OPT BYPASS AS PER RULES TABLE
IMACIOO IOOVX2 IOOVEX2 OPT BYPASS NO RULES TABLE MATCH
TYPEIOO IOOVX3 IOOVEX3 OPT BYPASS BUFFER CHANGE NOTAUTH
TYPSIOO IOOVX4 IOOVEX4 OPT BYPASS JCL PARMS PRESENT
VMACIOO IOOVX5 IOOVEX5 OPT BYPASS CSR FAILURE
VMXGINIT
Aug 10, 2009
Change 27.188 MXG 27.04-27.06. When DB2STATS was enhanced to include
VMACDB2 the IFCID=225 DB2STAT4 dataset, the BY list for the sort
Aug 10, 2009 order for DB2STAT0 and DB2STAT1 was incorrectly changed,
which could cause a NOT SORTED error in WEEKBLD/MONTHBLD.
This change resets the sort order for DB2STAT0/DB2STAT1
to the expected SYSTEM QWHSSSID QWHSSTCK.
The same order can NOT be used to create DB2STATS because
the QWHSSTCK timestamp is not consistent in an interval;
instead, SYSTEM QWHSSSID QWHSACE QWHSMTN QWHSISEQ must be
used to create DB2STATS.
If you encounter the NOT SORTED error, you can remove the
BY statement in your WEEKBLD/MONTHBLD to circumvent.
BUT: the better solution is to REMOVE DB2STAT0, DB2STAT1
and DB2STAT4 from your WEEKBLD and MONTHBLD, because they
are completely contained in the DB2STATS dataset!
Unfortunately, I have to leave them in WEEKBLD/MONTHBLD
because they are already there, and removing them would
create a bigger exposure to DATA SET NOT FOUND errors!
Thanks to Wayne Bell, UniGroup, USA.
Change 27.187 In spite of my note in IMACICDL "beginning with IMS 5.1
IMACICDL CICS/TS 1.1+ do NOT support DL/1 calls from CICS" SMF 110
UTILEXCL records with the optional IMACICDL data segment can still
VMAC110 be created, and with CICS/TS 3.2, it is INCOMPATIBLE due
Aug 8, 2009 to the increase to 12 byte clock/counters. IMACICDL was
revised to support both lengths, even though ALL of the
fields in the IMACICDL segment are now ALWAYS zeroes.
-UTILEXCL's generated KEEP= statement was updated to KEEP
these variables, but ONLY so I could confirm the zeroes.
-A DROP statement was added in IMACICDL so these variables
will be dropped if you do have to tailor IMACICDL.
Change 27.186 WSF record with ACCSTAT='.1......'B flag, which says that
VMACWSF the ACCKTN Extension added in WSF 3.3.6 exists, caused an
Aug 7, 2009 INPUT STATEMENT EXCEEDED RECORD LENGTH when it did not
have the minimum-length-20-byte segment present; MXG now
tests that both that bit is on, AND that 20 bytes of data
actually exists before inputting the extension fields.
Thanks to Norm Folkers, CGI, CANADA.
Change 27.185 Variable R744RSST='TOTAL*SIGNAL*SERVICE*TIME' in dataset
VMAC74 TYPE74DU/XTY74DU was incorrectly divided by 10**(-6); it
Aug 7, 2009 was already converted to microseconds in the INPUT and
should not have also been divided.
Thanks to Yacine Amraoui, La Banque Postale, FRANCE.
Change 27.184 Support for VMWARE objects in NTSMF adds new datasets:
VMACNTSM dddddd Dataset Description/Object Name
Aug 7, 2009 NTVWGC VMWGUCPU VMWARE.GUEST.CPU
NTVWGD VMWGUDIS VMWARE.GUEST.DISK
NTVWGM VMWGUMEM VMWARE.GUEST.MEMORY
NTVWGN VMWGUNET VMWARE.GUEST.NET
NTVWGR VMWGURES VMWARE.GUEST.RESCPU
NTVWGS VMWGUSYS VMWARE.GUEST.SYS
NTVWHC VMWHOCPU VMWARE.HOST.CPU
NTVWHD VMWHODIS VMWARE.HOST.DISK
NTVWHM VMWHOMEM VMWARE.HOST.MEMORY
NTVWHN VMWHONET VMWARE.HOST.NET
NTVWHR VMWHORES VMWARE.HOST.RESCPU
NTVWHS VMWHOSYS VMWARE.HOST.SYS
NTVWRP VMWREPOL VMWARE.RESOURCEPOOL
and support for new objects ASP.NET V2.0.50727 and
ASP.NET APPS V2.0.50727 which are output in existing
ASPNET and ASPNETAP datasets.
Change 27.183 The Diagnose Instruction variables added by Change 26.203
VMACVMXA were only INPUT and not kept in z/VM dataset VXPRCDIA.
Aug 6, 2009
Thanks to Jim Dammeyer, State Farm Auto, USA.
Change 27.182 Support for optional, user-created, CICS REQCNT1 field.
IMACICUE
VMAC110
UTILEXCL
Aug 6, 2009
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 27.181 Support for VOLSER='SCRTCH', a previously unseen (or not
ASUMTAPE noticed value for VOLSER), which has to be added to the
Aug 5, 2009 existing exceptions for VOLSER='PRIVAT'. Mounts with the
VOLSER='SCRTCH', either in the TYPETMNT Mount dataset or
the TYPESYMT SYSLOG dataset, were not matched with their
TYPE21 (because it always has the resultant VOLSER).
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 27.180 -Support for new CPU_PHYSICAL and CPU_ENTITLED objects in
VMACNMON TOPAS (originally NMON, Nigel's Monitor for AIX/LINUX)
Aug 5, 2009 adds six variables from each into NMONINTV dataset:
Aug 7, 2009 PPHYBUSY PPHYIDLE PPHYSYS PPHYUSER PPHYWAIT NRPHYS
PNTIBUSY PNTIIDLE PNTISYS PNTIUSER PNTIWAIT NRNTIS
-MEMUSE record with invalid numeric value 0.275.9 in the
last field causes two harmless messages to be printed:
INVALID ARGUMENT TO FUNCTION INPUT.
and variable MUMAXCLI will have a missing value.
-INVALID ARGUMENT messages for RECTYPE='RAWCPUTOTAL' were
corrected; right hand argument of WORD2 test needed to be
in all upper case.
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 27.179 -MXG 27.05-27.06. WORK datasets were not PROC DELETEd due
TYPETMS5 to debugging comments that should have been removed. The
Aug 5, 2009 14 datasets required over 6400MB with a 700MB TMS input.
Thanks to Jim Kovarik, AEGON, USA.
Change 27.178 ASUM70PR with STARTIME=16:29:59 (instead of 16:30:00) was
VMXG70PR incorrectly reset to 16:15 when INTERVAL=QTRHOUR was used
VMXGRMFI and this created an obs with DURATM=30 minutes instead of
Aug 5, 2009 the requested 15 minute summarization (fortunately, all
data values in that observation ARE correct!). STARTIME
has always been used for MXG RMF summarization, because
the only other original choice, SMFTIME, was inexact, as
write delays could cause it to be in the next hour, etc.
But now, SMF70GIE, the expected, exact, end of interval,
always exists in current RMF/CMF records, so it is used
to define the interval when INTERVAL="value" is specified
so STARTIME can then be exactly reset SMF70GIE-MXGDURTM.
SMF70GIE is already used elsewhere in VMXG70PR, but not
in the STARTIME reset algorithm.
If SYNC59=YES was accidentally specified (not needed
here because the RMF data was written with SYNC=0),
STARTIME was set to 16:30 instead of 16:15, and the 30
minute obs was accidentally NOT created.
Why the STARTIME is one full second earlier instead of
exact is not known, but this system was a 2094-709 with
VERSNRMF 750, and IRD was not active.
-RMFINTRV was revised to also set STARTIME from SMF70GIE,
so there should always be a perfect match between the
PDB.RMFINTRV and PDB.ASUM70PR values.
But NOT with INTERVAL=DETAIL or INTERVAL=DURSET:
MXG Only Resets the STARTIME to "clean" values when
you specify an INTERVAL= "duration" (QTRHOUR,HOUR,etc).
Thanks to Douglas C. Walter, Citigroup, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 27.177 Variable RECTOK was truncated to 12 bytes because it was
VMACITRF incorrectly formatted $HEX24; it is now correctly format
Aug 4, 2009 with $HEX32 to set its stored length as 16 bytes.
Thanks to Shantha Hallett, Capgemini UK, WALES.
Change 27.176 -MXG support for IMF 4.4 was incorrect for these variables
VMACCIMS that were previously binary with varying resolutions but
Aug 5, 2009 were changed in 4.4 to floating point microseconds:
TRNW1OTH TRNW2OTH TRNW2LCH TRNW2IOV TRNW2IOO TRNW3OTH
TRNW3LCH TRNW4OTH TRNW4DBR TRNW4IO TRNW5OTH TRNW5LCH
TRNW5LCK TRNW5IOV TRNW5IOO TRNW5IOD TRNEAPPL TRNEDLTM
TRNEDLDB TRNEDB2 TRNEMQS TRNEOESS TRNEOPCL TRNESYNC
-Records with LTERM values that are neither EBCDIC nor
ASCII ('EE4A80B18DDDDEEA'x) print funny-looking text.
Using FORMAT LTERM $HEX16.; will show that hex value,
but that makes the true printable text unreadable.
Not really a problem, mostly an observation.
-BMC PTF BQI0695 corrects an error in which a DBD segment
could be overlaid with zeros. This was detected because
SQLCALL='Y' (the transaction called DB2), but SQLCALLS
(the sum of calls in all DBD segments with DBORG='80'x)
was a missing value. Any transaction with SQLCALL='Y'
must have at least one DBORG='80'x DB2 DBD segment.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 27.175 -ANALDB2R detected but did not tolerate the absence of the
ANALDB2R DB2STATB dataset.
Jul 31, 2009 -Aug 9: ANALDB2R now honors DB2STATB/DB2STATS parameters
Aug 9, 2009 and new DB2GBPST parameter is added.
Thanks to Scott Wiig, USBank, USA.
Change 27.174 Variable QSSTCONT and QSSTCRIT were deaccumulated, but
VMACDB2 they should not have been, as they are end point values.
Jul 30, 2009 CHANGE REVERSED: SEE CHANGE 27.207.
Thanks to Ray Dunn, CIGNA, USA.
Thanks to Deborah L. Soricelli, CIGNA, USA.
Change 27.173 Misspelled variables cause confusion, but cannot simply
VMACDB2 be replaced by the correct spelling, as other programs in
Aug 5, 2009 MXG and in user programs may use the incorrect spelling,
so these new (correctly spelled) variables are created:
QBGLWM QXXCBPNX QXXCSKIP QXCRINX
with the same contents and labels as the incorrect ones:
QBGLMW QZZCBPNX QZZCSKIP QXCRINDX
Thanks to Tony Curry, BMC, USA.
Change 27.172 Most tests for IF xxxxxxxx NE 0 THEN were revised to test
ANALDB2R IF xxxxxxxx GT 0 THEN because missing-value variables are
Jul 29, 2009 true with NE 0 but in most cases that is not wanted. Each
test must be examined to see if xxxxxxxx can be missing,
and to confirm that the true value wanted was only GT 0.
This prevented divide-by-zero error messages.
Change 27.171 MXGTMNT records INPUT is now protected if the same SMF
VMACTMNT record number is also used by another product's record,
Jul 28, 2009 by verifying that TMNTSYS='TMNT'; when duplicate use of
the TMNT record ID is detected, two instances are now
printed on the log with a hex dump so you can identify
the other product "sharing" the TMNT record ID.
Thanks to Linda Pitcher, Progressive, USA.
Change 27.170 MXG QA Test Stream step TESTREAL was revised to validate
CLEARDB2 both the existence of datasets and expected observations
TESTREAL with the known SMF input file of DB2 data. READDB2 is
Jul 25, 2009 re-executed multiple times, so resetting of all of the
old-style macros for DB2 is required prior to each; the
static reset was stored in new member CLEARDB2 for reuse.
Change 27.169 MXG 27.04-27.06. READDB2 did not output to any T102Snnn.
READDB2 The error was introduced in MXG 27.04, and while READDB2
Jul 25, 2009 is tested in the QA stream, the tests were for existence,
and did not verify actual observations were created.
Thanks to Alex Macfarlane, BNY Mellon, USA.
Change 27.168 -MXG 27.05-27.06. Change 27.108 accidentally deleted the
TYPETMS5 _KTMSTMS token that should have been after line 188; the
Jul 24, 2009 token is used by ITRM to add variables for TMS.
Thanks to Rob D'Andrea, CIS, ENGLAND.
====== Changes thru 27.167 were in MXG 27.06 dated Jul 20, 2009========
Change 27.167 Minor. %READDB2... did not honor OPTIONS OBS=5000 because
READDB2 a RUN; statement was required to separate the execution
Jul 21, 2009 of the DATA step from subsequent %VGETOBS existence tests
VMXGOPTR (for IFCIDs 105/107). In %VGETOBS execution, the first
Jul 22, 2009 %VMXGOPTR with "OPTION=OBS,NEWVALUE=MAX", (needed so the
PROC SQL can function even if the user has set the option
OBS), was being executed before the DATA step that reads
the SMF data. The RUN; in READDB2 cured its problem, but
a more generic solution was to insert a RUN; statement at
the top of VMXGOPTR to protect it for all calls.
Change 27.166 CA-VIEW SARSRQUX exit SMF record was completely changed.
VMACSARX The new layout of the fixed portion is now supported, but
Jul 21, 2009 the Fixed JCL Attribute segment does not exist in my two
Oct 4, 2009 test records, and the Variable JCL Attribute segment is
not populated, so those segments are not yet INPUT, which
causes many, but harmless, UNINITIALIZED VARIABLE notes
on the log. Oct 4: UNINIT messages removed.
Thanks to Bob DeBartolo, Conseco, USA.
====== Changes thru 27.165 were in MXG 27.06 dated Jul 20, 2009========
Change 27.165 -VMXGSUM now dies gracefully with an MXGERROR message when
ANALACTM the input dataset does not exist; before, it still died,
ANALCNCR but the cause of death was unknown to the user. This can
ANALINIT happen if you include an ASUMxxxx or TRNDxxxx but you had
BLDNTPDB not created the expected input datasets. VMXGSUM works
UTILCONT fine if the dataset exists and has zero observations.
UTILVREF -ANALCNCR modified to fail before calling VMXGSUM if the
UTILXRF1 input dataset does not exist.
VGETDDS -VGETOBS was revised to protect when OPTIONS OBS=0 is in
VGETDSN effect; the PROC SQL used to determine if the dataset has
VGETENG observations did not execute, so VGETOBS falsely reported
VGETOBS the tested dataset did not exist, when in fact it did.
VMXGENG Calls to VMXGOPTR were inserted to store the current OBS
VMXGOPTR option in effect, set OBS=MAX for the PROC SQL, and then
VMXGSIZE restore the original option with a second VMXGOPTR call.
VMXGSUM But this instance of this exposure caused examination of
VMXGUOW all MXG code that uses PROC SQL, so these members have
Jul 17, 2009 also been protected to execute properly with OBS=0 set:
ASUMCACH ASUMCACH BLDNTPDB UTILCONT UTILVREF UTILXRF1 VGETDDS
VGETDSN VGETENG VMXGENG VMXGSIZE VMXGUOW
Setting OPTIONS OBS=0; is a quick way to test SAS code
for any SAS syntax errors, and as all datasets are also
created, subsequent references to datasets or variables
are validated, but no records are read and no disk space
is used since all datasets have zero observations.
An alternative technique is to use a DUMMY input file.
-VMXGUOW %VMXGOPTR calls balanced for default NOOBS zero.
-VMXGOPTR modified to UPCASE the parameters.
-ANALINIT protected with NODSNFERR/NOVNFERR, and is now
a self-executing %MACRO.
-ANALACTM. Some headings ran together & the response time
goals went into exponential notation. ANALACTM gives you
a visual picture of your WLM definitions.
-Aug 12, 2009: VGETOBS defined a new argument, NOEXIMSG.
Change 27.164 NOTE: NUMERIC VARIABLE CONVERTED TO CHARACTER in TIMEBILD
TIMEBILD happens to be harmless, but because it raised questions
Jul 15, 2009 (Why? Impact?), it is now eliminated. The culprit was
the CALL SYMPUT("MXGTIMES",SYS); where SYS was a numeric
count, and %MACRO variables must be character. Inserting
SYST=PUT(SYS,2.); to create character variable SYST, and
using SYST in place of SYS eliminated the message.
Thanks to Paul Volpi, UHC, USA.
Change 27.163 Eight BVIR variables are converted to bytes and FORMATed
VMACBVIR MGBYTES, and *KB in their label is replaced by BYTES to
Jul 15, 2009 be consistent with the other byte-containing variables:
P0CHRD ='HBA*PORT 0*CHAN*READ*BYTES'
P0CHWR ='HBA*PORT 0*CHAN*WRITE*BYTES'
P0VDRD ='HBA*PORT 0*VDEV*READ*BYTES'
P0VDWR ='HBA*PORT 0*VDEV*WRITE*BYTES'
P1CHRD ='HBA*PORT 1*CHAN*READ*BYTES'
P1CHWR ='HBA*PORT 1*CHAN*WRITE*BYTES'
P1VDRD ='HBA*PORT 1*VDEV*READ*BYTES'
P1VDWR ='HBA*PORT 1*VDEV*WRITE*BYTES'
Thanks to Perry Lim, Union Bank, USA.
Change 27.162 Support for BMC APPTUNE SQL IFCIDS=8004x-8136x as SMF 102
EX102S04 records create these eleven new datasets:
EX102S05
EX102S07 DDDDDD DATASET DESCRIPTION/IFCID
EX102S08 102S04 T1028004 102S04: BMC SQL APPTUNE 8004
EX102S09 102S05 T1028005 102S05: BMC SQL APPTUNE 8005
EX102S0A 102S07 T1028007 102S07: BMC SQL APPTUNE 8007
EX102S0B 102S08 T1028008 102S08: BMC SQL APPTUNE 8008
EX102S33 102S09 T1028009 102S09: BMC SQL APPTUNE 8009
EX102S34 102S0A T102800A 102S0A: BMC SQL APPTUNE 800A
EX102S35 102S0B T102800B 102S0B: BMC SQL APPTUNE 800B
EX102S36 102S33 T1028133 102S33: BMC SQL APPTUNE 8133
IMAC102 102S34 T1028134 102S34: BMC SQL APPTUNE 8134
READDB2 102S35 T1028135 102S35: BMC SQL APPTUNE 8135
VMAC102 102S36 T1028136 102S36: BMC SQL APPTUNE 8136
VMACDB2H
VMXGINIT 102BMC Creates all of the above
Jul 15, 2009
All eleven BMC T1028xxx datasets are created together,
with a single macro token dddddd=102BMC. Separate
dddddd tokens for each IFCID/dataset are not defined, as
I decided you'd want all eleven or none. You can create
only those eleven BMC T1028xxx datasets using %READDB2
%READDB2(IFCIDS=BMC);
Or, if you create all possible T102 datasets using either
%INCLUDE SOURCLIB(TYPE102); or %READDB2(IFCIDS=ALL);, all
350 IBM T102Snnn and the 11 BMC datasets will be created.
-While many of the fields are from standard IBM DB2 DSECTS
QWAC, QBAC, QTXA, QXST, and QWAX, all variable names in
the BMC T1028nnn datasets start with QBMCxxxx, so there
is no collision/conflict with the existing MXG names.
-Note that variables QBMCEJST and QBMCESC are different
from the IBM QWACEJST/QWACESC fields; BMC stores the
accumulated total measured time for the statement rather
than the end time for one execution in both.
Change 27.161 Incorrect QXPK values in DB2ACCTP, DB2 V9 only, only if
VMACDB2 NRQPAC GT 1, only in 2nd and subsequent obs per record.
Jul 13, 2009 The DB2ACCTP Package obs contain either both QBAC & QXPK
segments (when Class 10 is enabled) or neither (if not);
if on, there is one QBAC and one QXPK segment per QPAC,
MXG outputs the first set in the first obs, the second
set in the second obs, etc. However, DB2 V9 IFCID=239
(ID=101,Subtype=1) records with more than one NRQPAC had
incorrect QXPK variable's values in 2nd-plus obs, due to
MXG incorrect logic test for =0 instead of LE 0 (and a
typo) in its handling of the new DB2 V9 lengths:
In DB2, IBM stores a zero in the length field in the
"triplet", and the triplet's offset now points to the
two-byte location with the actual field length, at the
start of that segment's data. But only sometimes!
Change 27.160 Var EVENTIME was inadvertently DROPed from PDB.ASUMTAPE
ASUMTAPE by Change 26.038 (MXG 26.03), but was expected in ITRM.
Jul 10, 2009 It is now kept again with the beginning datetimestamp of
the mount event.
Thanks to Don Bernard, North Carolina State Government, USA.
Change 27.159 The test for OSI to input SMF62MGT/SMF62STR/SMF62DAT
VMAC62 unintentionally prevented OPENTIME and ACBMACR1-ACBMACR4
Jul 9, 2009 from being input. The OSI test is no longer needed as
space for all three fields are always present, so it was
removed. And because the MGT/STR/DAT can contain '00'x,
those values were translated to blanks.
Thanks to Sam Bass, McLane Co., USA.
Change 27.158 This change is in progress, requiring many updates before
VMACDB2 it is fully implemented. Progress is documented below.
VMACDB2H If DB2 zparm UIFCIDS=YES is set, many DB2 character vars
VMAC102 will contain ASCII instead of EBCDIC text. These fields
Jul 8, 2009 are identified as "%U" in the IBM DSECTs; technically the
fields contain UNICODE, UTF-8, which is simple ASCII.
Each of these "%U" fields has its original fixed-length
location (that MXG continues to INPUT, but conditionally
INPUTs ASCII or EBCDIC), but if the text length is longer
("truncated" to that fixed-length), a new offset points
to the length and location of the "un-truncated" text,
which is then conditionally input with the longer length.
Change 24.136 created DB2UNICD='Y' when UIFCIDS=YES, and
DB2UNICD was used to conditionally INPUT these variables
QLACLOCN QLSTLOCN QMDALOCN QPACCOLN QPACLOCN QPACPKID
QWHCAID QWHCOAUD QWHCOPID QWHCROLE QWHCTCXT QWHSLOCN
(because only these fields were ASCII in test data).
However, when the below circumvention for an IBM ABEND
required UIFCIDS=YES to be set, these header variables
QWHDRQNM QWHDSVNM
were seen to be in ASCII, and VMACDB2H was updated.
There are at least 224 %U fields in DB2 V9 DSECTS that
need update or at least verification, and they will all
(EVENTUALLY!!) be updated/supported.
As of Jul 13, these variables are now "%U" Supported:
Still to be done:
These are the only "ACCOUNT" IFCIDS that need updating:
QPACASCH QPACAANM
and these are all of the SMF 102 IFCIDs that need update:
QW0022CI QW0022CN QW0022CR QW0022PG QW0022QO QW0022TN
QW0029CI QW0029LN QW0029PI
QW0030CI QW0030LN QW0030PI
QW0031CI QW0031LN QW0031PI
QW0053LN QW0053PC QW0053PN
QW0055NI QW0055OI
QW0058LN QW0058PC QW0058PN
QW0059CN QW0059LN QW0059PC QW0059PN
QW0060LN QW0060PC QW0060PN
QW0061CN QW0061LN QW0061PC QW0061PN
QW0064CI QW0064CN QW0064LN QW0064PN
QW0065CN QW0065LN QW0065PC QW0065PN
QW0066CN QW0066LN QW0066PC QW0066PN
QW0083SA
QW0087SA
QW0096PC QW0096PN
QW0108NC QW0108NI QW0108NL QW0108OH QW0108OW QW0108QL
QW0110PC QW0110PI QW0110PL
QW0112OH
QW0113OH
QW01247S QW0124CI QW0124LN QW0124PN QW0124SP
QW0125PC QW0125PN
QW0140SC QW0140SN QW0140TC QW0140TN QW0140UR
QW0141OR
QW0142CR QW0142OW QW0142TN
QW0145LN QW0145PC QW0145PN
QW01488L QW01489L QW0148CI QW0148LN QW0148PN QW0148SP
QW0157LN QW0157PN
QW0158PN
QW0159LN
QW0162LN
QW0169AL QW0169AU QW0169LO QW0169NE
QW0173CN*QW0173ID*QW0173PC QW0173PK
QW0177CO QW0177LO QW0177OH QW0177PI
QW0183CO QW0183LN QW0183PN
QW0185CN QW0185CR QW0185TB
QW0191LN
QW0192LN [192cs 192ec]
QW0193LN
QW0194LN
QW0195LN
[195hb]
QW0203CO QW0203LO QW0203PA
QW0204LO
QW0205LO
QW0206LO
QW0207HN QW0207TN QW0207UN
QW0208LO
QW0209LO
QW0210LO
QW0221LN
QW0221PC QW0221PN
QW0222LN QW0222PC QW0222PN
QW0224CI QW0224PN
QW0233LN QW0233PC QW0233PN QW0233PR QW0233SC
QW0235LO
QW0236LO
QW0247LN QW0247PC QW0247PN
QW0248LN QW0248PC QW0248PN
QW0269PR QW0269RA QW0269RC QW0269RU QW0269SA QW0269TC
QW0272LN QW0272LP QW0272PC QW0272PG QW0272PN QW0272QN
QW0273CN QW0273LN QW0273LP QW0273PC QW0273PG QW0273PN
QW0305CN
QW0311CN QW0311LN QW0311PC QW0311PN QW0311QN QW0311TN
QW0313AI
QW03141N QW03142N QW0314BN QW0314LN QW0314MN QW0314NN
QW0316QD QW0316SC QW0316T1 QW0316T3 QW0316TD QW0316X4
QW0324CI QW0324CV QW0324FI QW0324FN QW0324FS QW0324NV
QW0325CO QW0325NM QW0325PR QW0325SC QW0325TX
QW0334LN
QW0341LN QW0341PC QW0341PN
QW0343ID QW0343PC QW0343PK QW0343PL
QW148SCH
QWP1RLFA
QWP4ADM2 QWP4DFID QWP4OPR1 QWP4OPR2 QWP4OZUS QWP4REGA
An ABEND 0C4 in DB4PMSTR (takes down DB2 Subsystem) can
occur if zparm UIFCIDS is set to "NO", and IFCIDs 316,317
are written. IBM suggested PTF UX37196, but that is PE.
Setting zparm UIFCIDS to "YES" bypassed the conversion.
ERROR DESCRIPTION:
Rapid stack storage increase about 200M per day was
observed by customer. This occurs when IFCID 316, 317
were in effect and the zparm UIFCIDS was set to no. The
stack storage was used for conversion from UNICODE to
EBCDIC.
LOCAL FIX:
Set zparm UIFCIDS to yes to bypass conversion or turn
off IFCID 316 and 317.
Thanks to Barry Pieper, Blue Cross of Minnesota, USA.
Change 27.157 SMF 116 variables WQGETJCE/WQPUTJCE/WQPUT1JE/WQSET1JE in
VMAC116 the MQMQUEUE dataset were not divided by 4096, so their
Jul 7, 2009 values were incorrectly large without that divide.
Version 7.0 SMF 116 records have been read without error;
there are no new fields in the SMF 116 (nor 115) records.
in Version 7.0, so the MXG support was already in place.
Thanks to Frank Debree, Dexia, BELGIUM.
Change 27.156 Support for z/VM 6.1.0 is already in place in MXG 27.01+,
TYPEVMXA as there were no changes to the MONWRITE data records,
Jul 7, 2009 except for the new version number.
Change 27.155 -Type 42 Subtype 16 RLS Record INPUT STATEMENT EXCEEDED
VGETUTKN because the two length tests LEN42D2 and LEN42D4 should
VMAC42 have been 1652 instead of 1504.
Jul 6, 2009 -Type 42 Subtype 21 and 24 with invalid ICHRUTKN segment
Jul 8, 2009 had all of UTKNxxxx variables wrong or truncated. This
Jul 13, 2009 change detects the mis-located segment (starts in 187 vs
185) and correctly populates the UTKNxxxx variables,
except that the last variable in the record, UTKNGRUP,
is only 6-bytes long when the segment in invalid.
-IBM APAR OA27563 corrects the errors; search NEWSLTRS for
the details.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.154 USS dataset TYPE9201 variable SMF92PPN (pathname to the
VMAC92 filesystem) was not input because SMF92PPL, its length
Jul 6, 2009 field was INPUT from the wrong offset in line 640,
which now contains
If SMF92MPF GT 0 THEN INPUT @SMF92MPF+1
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 27.153 Dataset TYP11921 variable NTBTRNBE should have been INPUT
VMAC119 as &PIB.4. instead of &PIB.4.3 since it is a count and is
Jul 5, 2009 note a duration.
Thanks to Paul Volpi, UHC, USA.
Change 27.152 MXG 27.01-MXG 27.05. DCOLLECT variable UBALLSP is missing
VMACDCOL always; its INPUT statement was lost when Change 27.034
Jul 2, 2009 updates were made.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Thanks to Isabelle Diagremont, FIDUCIA IT AG, GERMANY.
Change 27.151 XAM TCP record caused INPUT EXCEEDED RECORD LENGTH ERROR.
VMACXAM A TCPAPP segment with only Segment Name and SEGLEN=8 with
Jul 2, 2009 no data can be created for internal XAM purposes. Only
the TCPAPP segment can have these "null segments", so the
SEGLEN is now tested after the header is INPUT, and the
segment is NOT output if there is no data.
Thanks to Chris Morgan, CitiCorp, ENGLAND.
Change 27.150 -MXG 27.05. COPYONLY option of READDB2 didn't work for the
READDB2 ID=102 IFCIDs selection.
Jul 2, 2009
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Change 27.149 Labels for Counts of ZIP, IFA, CPs, etc are clarified:
VMAC7072 In ASUM70PR ASUM70LP TYPE70PR - PER SYSTEM-CEC DATASETs
Jul 1, 2009 and ASUMCEC ASUMCELP - PER CEC DATASETS:
NRICFCPU='ICF CPUS*AVAILABLE*IN THIS CEC'
NRIFACPU='IFA CPUS*AVAILABLE*IN THIS CEC'
NRIFLCPU='IFL CPUS*INSTALLED*IN THIS CEC'
NRZIPCPU='ZIIP CPUS*AVAILABLE*IN THIS CEC'
because RMF can see everything in the CEC in the 70PR SMF
data.
But the TYPE70 and RMFINTRV DATASETS - PER SYSTEM DATA:
NRIFAS ='IFA CPUS*AVAIL TO*THIS ZOS'
NRZIPCPU='ZIIP CPUS*AVAIL TO*THIS ZOS'
NRIFACPU='IFA CPUS*AVAIL TO*THIS ZOS'
NRIFLCPU='IFL CPUS*INSTALLED*IN THIS CEC'
NRCPUS ='AVERAGE*ONLINE*NON-PARKED*CP ENGINES'
are not the "hardware" counts, but only the count of the
engines that this z/OS system can use and knows about.
Thanks to Scott Wigg, USBank, USA.
Change 27.148 Support for APAR OA29428 adds diagnostic bits that create
VMAC1415 these new MXG variables and labels:
Jun 30, 2009 SMF14TCL='TASK*TERMINATION*CLOSED*THE DCB?'
SMF14ABD='TASK IS*TERMINATIONG*TCBFA*IS ON?'
MXG Variables whose label ends with a question mark are
one byte character variables whose value will be 'Y' if
true, and should be blank if not true (although some old
variables might contain 'N' for false).
The APAR text states:
For debugging purposes, customers need to know if a
dataset has either been closed by a program or RTM
cleanup processing. The SMF records (types 14 or 15)
do not currently provide a way to identify this
information. The addition of flag(s) are required to
indicate normal versus abnormal CLOSE. One methodology
that can add this information is to add a bit to
indicate that task termination closed the dcb and add
a second bit to indicate whether or not the task is
abending.
Change 27.147 -MXG ANALZPCR didn't expand variable SCP to 10 bytes so
ANALZPCR z/OS 1.10 was not correctly set in the external study
Jun 30, 2009 file.
-MXG incorrectly set SCP from MVSLEVEL to be the same as
the MVSLEVEL of the TYPE70 that wrote the record, instead
instead of using the SMF70STN from each LPAR to define
that system's SCP. Now, TYPE70 is read to create the new
$TEMPSTN format, mapping SYSTEM to MVSLEVEL, and then
SMF70STN value in TYPE70PR is looked up to set MVSLEVEL.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.146 These OMCI datasets built by TYPE112
VMAC112 T112ADA T112ADAT T112DLI T112DLIT T112IDMT T112IDMS
Jun 30, 2009 T112VSAM T112VSAT T112SUPR T112SUPT T112DTCO T112DTCT
did not keep variables OMCIJOB OMGAPPL OMSAPPL.
Thanks to Richard Schwartz, State Street Bank, USA.
====== Changes thru 27.145 were in MXG 27.05 dated JUN 29, 2009========
Change 27.145 Support for TMON for MQ record "QA" (APPLICATION STATS)
EXTMQQA creates two new datasets, TMMQQA and TMMQQAA. All of the
EXTMQQAA QAxxxxx variables with TIME12.2 format are guesses as to
IMACTMMQ their internal format, and TMON reports for validation
VMACTMMQ weren't available when MXG 27.05 was ready; please check
VMXGINIT with support@mxg.com for any updates prior to using those
Jun 26, 2009 variables in these two new datasets.
Jul 1, 2009 Jul 1: QA record's 32 Latch Class times/counts created.
Thanks to Paul Volpi, UHC, USA.
Change 27.144 New documentation member ADOCRMFR tabulates the name of
ADOCRMFR each MXG variable that is printed in IBM RMF reports.
Jun 26, 2009
Thanks to George Canning, Produban, ENGLAND.
Change 27.143 Variable REDIRECT in PRPR1010 dataset contains text, in
VMACPRPR spite of the documentation that it is a numeric field.
Jun 26, 2009 Previous test data had blanks. Now INFORMAT $16.
Thanks to Siegfried Trantes, Gothaer Systems GmbH, GERMANY.
Change 27.142 Using the %VMXGPRAL utility to print SUSE datasets caused
VMXGPRNT errors because of the long-length-variable-names in SUSE,
Jun 26, 2009 and the need for LRECL=255 on the temporary FILENAME.
Thanks to James J. Flanagan, ISO, USA.
Change 27.141 Variables R792FLG and R792FLG2 are now kept in TYPE792.
VMAC79
Jun 25, 2009
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 27.140 Change 27.062 incorrectly input S42DSRDD/S42DSRDT as &RB
VMAC42 but the fields are &PIB format.
Jun 25, 2009
Thanks to Siegfried Trantes, Gothaer Systems GmbH, GERMANY.
Change 27.139 Line 1024 should be BO SCANLOOP Y. TRY ANOTHER VOLUME
ASMVTOC instead of BZ. This caused no volumes to be returned when
Jun 22, 2009 SELECT vol1 vol2 .. was used.
Thanks to Paul Gillis, Pacific Systems Management Pty Ltd, AUSTRALIA.
Change 27.138 -z/OS 1.10 SMF 85 OAM record INPUT EXCEEDED RECORD ERROR.
VMAC85 MXG Version/Release/ModLevel variable R85PRVM='1*0' was
Jun 18, 2009 created as it didn't expect a 2-digit Release Number.
Jul 17, 2009 Fortunately, R85PRVM is not kept so it was expanded to
now supports 2 digit Version so '1100' is GT '1 30'.
-TYPE85AC dataset. New variables
R85STY='RECORD SUBTYPE'.
R85STOK ='OSREQ*STOKEN'
R85RC2 ='OSREQ*RETURN*CODE*TWO'
-Subtypes 8 thru 10 now are also output to TYPE85AC.
-But the R85PRVM value is not consistent. These values
are found in my past test data files:
1999 1. 4.0
2003 1. 3.0
2003 2.10.0
2007 1. 8.0
2009 1.10.0
-Jul 17: New variables added to TYPE85ST dataset:
R85PUDK ='BYTES*DELETED*TAPE*SUBLEVEL 2*/
R85PUDO ='PRIMARY*OBJECTS*DELETED*TAPE*SUBLEVEL 2'
R85PURK ='BYTES*READ*TAPE*SUBLEVEL 2'
R85PURO ='PRIMARY*OBJECTS*READ*TAPE*SUBLEVEL 2'
R85PUWK ='BYTES*WRITTEN*TAPE*SUBLEVEL 2'
R85PUWO ='PRIMARY*OBJECTS*WRITTEN*TAPE*SUBLEVEL 2'
-Corrections to handling of subtype 78,79,and 88 for
test data from versions 1100, 1 30, and 1 40.
Thanks to Joachim Sarkoschitz, DATEV eG, GERMANY.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 27.137 Analysis of interval zIIP usage by JOB/PROGRAM/etc using
ANALZIPU PDB.SMFINTRV. You define the ZIPGROUP variable to group
Jun 18, 2009 that is then summed for each interval, and the percentage
of total zip usage by that ZIPGROUP for that interval is
calculated. The analysis does demand that your SMF 30
data is synchronized.
Thanks to David Carr, Blue Cross Blue Shield of Kansas, USA.
Change 27.136 Unused Change.
Change 27.135 The (VERY OLD) ANALRMFI example's selection criteria had
ANALRMFI test for a series of variables ANDed to be GE 0, but some
Jun 17, 2009 of the variables are, now, always missing (logical swaps)
causing nothing to be selected. The WHERE clause tests
now are ORed, and always-missing variables were removed.
However, like all ANALxxxx report examples, this is only
an example, as a starting report to be tailored into your
very own report, if the report is of interest.
Thanks to Cletus McGee, Alfa Mutual Insurance Company, USA.
Change 27.134 Further support for IBM i, i5/OS, iSeries, or AS400 V6R1
EXQAPHDW (to include all old and new names of these products).
IMACQACS New dataset created:
VMACQACS -QAPMHDWR Hardware Configuration
VMXGINIT Existing datasets updated:
Jun 17, 2009 -QAPMBUS - BUIOPB increased from 2 to 3 bytes.
Jun 18, 2009 -QAPMJOBM- New variables added:
JBJTHDT ='JVM*THREAD*TYPE'
JBJVMF ='JVM*STARTED'
JBJVMT ='JVM*TYPE'
JBMDYR ='FILE*SYSTEM*DIRECTORY*READS'
JBMLCH ='FILE*SYSTEM*LOOKUP*CACHE HITS'
JBMLCM ='FILE*SYSTEM*LOOKUP*CACHE MISSES'
JBMNDC ='FILE*SYSTEM*NON-DIR*CREATE*OPS'
JBMNDD ='FILE*SYSTEM*NON-DIR*DELETE*OPS'
JBMOPN ='FILE*SYSTEM*OPEN*OPERATIONS'
JBMSLR ='FILE*SYSTEM*SYMBOLIC*LINK READS'
JBPASE ='I5/OS*PASE*RUNTIME*ACTIVE'
JBPGRL ='PAGE*FRAMES*RELEASED'
JBPGRQ ='PAGE*FRAMES*REQUESTED'
JBSCPU ='SCALED*CPU*MICROSECONDS'
JBSTCPU ='TOTAL*SCALED*JOB*CPU'
There were also a number of fields labeled RESERVED that
are INPUT and kept, in case they become populated.
-QAPMSYST New variables added:
SYSIUL ='USER*AUTHORIZATIONS*AVAILABLE'
SYSCIU ='USER*AUTHORIZATIONS*NEEDED'
Thanks to Clayton Buck, UniGroup, USA.
Change 27.133 Variable CFBUSYTO is created in TYPE74CF as the sum of
VMAC74 all CF engine busy time (CFBUSY01-CFBUSY16).
Jun 16, 2009
Change 27.132 DB2 V8 IFCID=22 Record with truncated name fields caused
VMAC102 INPUT STATEMENT EXCEEDED RECORD LENGTH some of the time.
Jun 16, 2009 -MXG 27.05 was still wrong for some cases; Jul 2 revision
Jul 2, 2009 with tested with both V8 and V9, but the V8 records do
not exactly agree with the V8.1 DSECTS, so counters were
added to ensure alignment (I hope!).
Thanks to Tom Buie, Southern California Edison, USA.
Change 27.131 Enhancements to DB2PM-like STATISTICS LONG report have
ANALDB2R caused updates to create/correct needed DB2 variables:
ASUMDBSS -Variables QWHADSGN,QWHAMEMN kept in all DB2ACCTx/DB2STATx
READDB2 datasets, as they are in the header of all DB2PM reports.
TRNDDBSS -Variables QDSTQMIT QTMAXPB QDSTQIN2 QBSTXIS QTGSPEMX
VMAC102 QXMAXDEG QXSTXMLV QXSTLOBV
VMACDB2 were DIF()'d but they do not contain accumulated values.
Jun 26, 2009 -Variables QDSTQIN2 QTPACOW1 QTPACOW2
were NOT DIF()'d, now are, contain accumulated values.
-Variables QTGACSLM QTGALSLM QTGAUSLM QTGSCSLM QTGSLSLM
and QTGSUSLM are actually spelled QTG..LSM in DB2 DSECT,
but once named in MXG there only pain and anguish if I
rename a variable, and these aren't important enough to
have me create correctly spelled duplicate variables.
-T102S106 System Parameters dataset was updated with these
new variables added for V8 and V9:
QWP1ACCU QWP1ACID QWP1CDB QWP1IDBP QWP1IXPX QWP1IXQT
QWP1LVA QWP1LVS QWP1LWCK QWP1MOFR QWP1RLFA QWP1SYFL
QWP1SYMV QWP1TP16 QWP1TP32 QWP1TP8 QWP1TPLB QWP1TPXM
QWP1TSQT QWP1WLME QWP1XVA QWP1XVS
QWP4APS QWP4FRLC QWP4IAST QWP4MIS6 QWP4MS4C QWP4MXAB
QWP4MXDC QWP4NUPT QWP4PMGT QWP4RSDC QWP4RSMT QWP4SKLC
QWP4SRTN QWP4WFAL
QWP5DCYC QWP5DLOK QWP5FLG QWP5HASH QWP5MCSA QWP5PHSH
QWP5RLE QWP5TVAL
QWP9TCKA QWP9INAC
QWPBAPSC QWPBDB2S QWPBDDRM QWPBLCTP QWPBLNM QWPBNUFN
QWPBPADN QWPBUGID QWPBUMID QWPBUSID
-New ASUMDBSS Statistics Summarization summarizes:
Default INPUT dataset Default OUTPUT dataset
PDB.DB2STATS PDB.ASUMDBSS
PDB.DB2STATB PDB.ASUMDBBS
PDB.DB2GBPST PDB.ASUMDBSG
The new ASUMDBSS eliminates the need for old ASUMDBSB as
only ASUMDBSS is needed to create all three stat ASUMs.
-New TRNDDBSS Statistics Summarization summarizes:
Default INPUT dataset Default OUTPUT dataset
WEEK.ASUMDBSS TREND.TRNDDBSS
WEEK.ASUMDBBS TREND.TRNDDBBS
WEEK.ASUMDBSG TREND.TRNDDBSG
The new TRNDDBSS eliminates the need for old TRNDDB2S and
TRNDDB2X, as TRNDDBSS creates all three stat TRNDs.
If you are currently using TRNDDB2S or TRNDDB2X, read the
comments in TRNDDBSS with the one-time migration example.
-Statistics reports can be selected by DB2 subsystem
(QWHSSSID), local location (QWHSLOCN), BEGIN and END time
using the DB2 DB2LOCAL BEGTIME and ENDTIME parameters.
-READDB2 revised with new parameter RUNASUMS, default NO.
Set RUNASUMS= interval desired (HOUR/DATE/WEEK/etc.) and
the ASUMDB2S will create the statistics summary datasets
in PDBOUT library.
-ANALDB2R these reports have been brought up to date with
DB2 Performance Expert/Performance Monitor documentation:
PMACC01/PMACC03=Accounting short report
PMSTA01/PMSTA03=Statistics long reports
PMSTA02/PMSTA04=Statistics short reports
PMSPR01=System Parameter Report
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 27.130 These variables for dataset QAPLPAR
VMACQACS LPCAP LPAVL LPBSY LPRSP LPRDS LPWRTS
Jun 15, 2009 LPDISK LPMEM
were INPUT but not kept.
Thanks to David Bixler, FISERV, USA.
Change 27.129 Support for changes to CONTROL-D TYPE C User SMF record.
VMACCTLL Eight LOGCODE values have existing JOBNAME RECIPIENT and
Jun 15, 2009 REPORT variables in different locations, plus two new
ACTIONCT and VALUESCT variables.
Thanks to Josep Miquel, La Caixa, SPAIN.
Change 27.128 Change 27.046 made major update to EDGHSKP type D,V,X but
VMACEDGR invalid syntax of 'GT . GT . ' was not detected, causing
Jun 12, 2009 MANY datetime variables to have missing values.
Thanks to Rudolf Sauer, T-Systems, GERMANY.
Change 27.127 Support for CONTROLT for "daily dataset" billing, and
DAILYDSC other "DAILYDSN" job enhancements:
DAILYDSN -New DAILYDSC created for CONTROLT.
DAILYDSR -DAILYDSR modified to handle SPACE6 DAYS6 (bytes on
IMACVTS virtual and days)
JCLDAYDS -DAILYDSN modified to handle SPACE6 DAYS6 and to use the
Jun 11, 2009 same constructs as DAILYDSC overriding the _L for the
output TMS datasets to send them to the DATASETS LIB.
-IMACVTS used by all of the above to set a variable
VIRTREAL to REAL or VIRT. Comments on usage in member.
Default is REAL.
-JCLDAYDS modified to add a CTLT step
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 27.126 zVM Velocity Software variable SYTLPNAM/LCPUNAME is no
VMACXAM longer kept in dataset XAMSYU, which has an observation
Jun 11, 2009 with the LPAR management time for each hardware Engine,
and is not a per-LPAR dataset. MXG had incorrectly kept
SYTLPNAM from the last SYTCUP segment.
Thanks to Douglas C. Walter, Citigroup, USA.
Change 27.125 -DB2 V8 Only, DB2STATS variables QISESKCT, QISESKPT were
VMACDB2 zero in SMF 100 subtype 1 records with LENQISE=148 bytes.
Jun 10, 2009 The QISE V8 DSECT was 96 bytes, ending at QISECFRE. In V9
QISE increased to 148 bytes. MXG tested length to input
new fields, so when a DB2 V8 record LEN=148 was read, the
new fields were input. However, in V9 IBM relocated the
two SKCT/SKPT fields into the first 8 bytes of the new
data, but this V8 record has zeros there, and the two
original field locations contain the number of SKCT and
SKPT pages. The MXG Logic continues to read new fields
QISEKFAL QISEKPGE QISEKFRE QISECTA QISEKTA
QISESFAL QISESPGE QISESFRE QISEKNFM QISEKNFA
QISEKNFR
with LEN=148 records, but no longer replaces the already
QISESKCT or QISESKPT values if the record is from V8.
-The MERGE of TEMPSTAT (ST0+ST1) and DB2STAT4/T102S225
now outputs PDB.DB2STATS if TEMPSTAT obs exist; Change
27.097 incorrectly also output unmatched 225s, including
the initial IFCID=225 for each subsystem, which has no
no matching ST0+ST1 observation. If only 225's exist,
then PDB.DB2STATS will have no observations, but the 225s
data will still be found in DB2STAT4 and T102S225.
-Change 27.097 incorrectly kept QWHSSTCK in PDB.DB2STATS;
BEGTIME ENDTIME are the datetime variables.
Thanks to John Shuck, SunTrust, USA.
Thanks to Chuck Hopf, Independent Consultant, USA
Change 27.124 "WARNING: Apparent invocation of macro TRIM not resolved"
VMXGOPTR is serious, but ONLY happens if your //SASAUTOS does not
Jun 9, 2009 include the SAS-supplied AUTOCALL library, or if your
CONFIGVx in use doesn't have this required statement
OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS);
because %TRIM() is delivered by SAS as a %MACRO in their
AUTOCALL library. Previously, only a few ANALxxxx used
%TRIM(), but in MXG 27.04, it was added to %VMXGOPTR by
Change 27.092, and %VMXGOPTR is used throughout MXG, so
several sites with defective SASAUTO allocations failed
when they installed MXG 27.04 (but they would have failed
earlier if they had used any of those ANALxxxx's!). But
with closer examination, we have eliminated the need for
the %TRIM() use in %VMXGOPTR, as the string is already
aligned, so I've removed the recently-added %TRIM() from
VMXGOPTR in this change.
Note: Change 27.278 also documents that %TRIM macro will
not be found if you have chanced MXG's S2=0 option to any
other non-zero value.
Change 27.123 -ASUMCEC dataset with an IFL still had missing values in
VMXG70PR CPCFNAME CPCMSU NRPHYCPS PARTNCPU PCTCPUBY PCTOVHD PCTPOV
Jun 7, 2009 variables, and wrong values in these variables:
Jun 9, 2009 IFACPUS IFAUPTM ZIPCPUS ZIPUPTM
even after Change 27.102 claimed to correct that error.
The problem only occurs if you have an IFL LPARs that is
also the highest numbered LPARNUM.
Change 27.076 added the support for IFL LPARs to ASUM70PR
output datasets; new observations are created for each
IFL LPARNAME in the two LPAR-specific datasets ASUM70LP
and ASUMCELP, but these new obs only populate only these
IFL resource variables
IFLACTTM IFLCPUS IFLUPTM IFLWSTTM PCTIFLBY
populated. All of the resource variables for the other
engine types (CP,ICF,ZIP,IFA) will have missing values in
the IFL observations. Those missing values were then
inadvertently propagated into the CEC-interval ASUMCEC
dataset. Several data step's sort order and logic were
revised to correct the error.
Thanks to Clayton Buck, UniGroup, USA.
Change 27.122 -Support for APAR OA26832 (increased Service Units field
VMAC30 from 4 to 8 bytes), is needed now, thanks to IBM, because
Jun 7, 2009 z/OS SYSTEMS NEVER FAIL: we now have long-running-tasks
Text revised where long is measured in months, and whose 4-byte fields
Jun 30, 2009 can fill and wrap, truncating those service unit values.
But Service Units are NOT used to calculate any normal
MXG CPU Time variables in TYPE30 data; those CPU times
are read directly from the SMF 30 record, except for the
MXG-only variable SRVTCBTM, the TCB CPU time calculated
from CPUUNITS, added so CPUTCBTM and SRVTCBTM could be
compared to see if using Service-Unit-Based CPU time had
more resolution than the recorded CPU time. Except for
wrapping, I saw VERY little difference between the
CPUTCBTM and the SRVTCBTM when SRVTCBTM was added in MXG.
-Variable SMF30INV has bits for each of the six fields set
if the 4-byte service unit field had wrapped.
-These IBM named fields are cited in the APAR:
SMF30SRV SMF30CSU SMF30SRB SMF30IO SMF30MSO SMF30ESU
and their corresponding MXG variables are these:
SERVUNIT CPUUNITS SRBUNITS IOUNITS MSOUNITS ENCLCPSU
in all of the TYPE30 datasets.
Change 27.121 In Change 27.078 I caused assembly errors
ASMIMSL6 ASMA034E Operand WTOAREA beyond active USING by 61 bytes
Jun 6, 2009 when I added messages for the new log record, proving I
am NOT an ASM programmer; shortening the message text did
circumvent the error, but this correction has been made
by "asmguy@mxg.com" who speaks that language for me.
Thanks to Mark Van Der Eynden, HP, AUSTRALIA.
Change 27.120 Support for RMF III z/OS 1.10 new ASI fields (INCOMPAT).
VMACRMFV These variables are now INPUT/KEPT, but as they were
Jun 5, 2009 inserted (rather than appended) to the ASI record, other
ASI variables will be trashed without this change.
ASILVNMO='PRIVATE*MEMOBJ*ALLOCATED'
ASIHVCOM='64-BIT*COMMON*MEMOBJ*ALLOCATED'
ASILVSHR='SHARED*MEMOBJ*ALLOCATED'
ASILVABY='PRIVATE*MEMOBJ*BYTES*ALLOCATED'
ASIHVCBY='COMMON*STORAGE*BYTES*ALLOCATED'
ASILVSBY='SHARED*MEMOBJ*BYTES*ALLOCATED'
ASIHVVBY='HWM*64-BIT*COMMON*BYTES*ALLOCATED'
ASILVMEM='ADDRESS*SPACE*LIMIT*IN MB'
Thanks to Rodger Foreman, Acxiom, USA.
Change 27.119 Documentation. A BUILDPDB SPIN library created on z/OS
BUILDPDB can be PROC CIMPORT copied to an ASCII system, but you
SPIN then must sort SPIN datasets (to change the z/OS EBCDIC
Jun 4, 2009 sort order to match the ASCII sort order) before you can
use that SPIN library with BUILDPDB.
The required SORT statements are:
PROC SORT DATA=SPIN.SPIN30_1;
BY READTIME JOB JESNR JINTIME;
PROC SORT DATA=SPIN.SPIN30_4;
BY READTIME JOB JESNR TERMTIME;
PROC SORT DATA=SPIN.SPIN30_5;
BY READTIME JOB JESNR DESCENDING JTRMTIME;
PROC SORT DATA=SPIN.SPIN26;
BY READTIME JOB JESNR JPURTIME;
Change 27.118 -Cosmetic. DDs with DEVCLASS='00'x now have DEVICE='00X'
VMACUCB instead of DEVICE='OTHER'. These values occur for SYSIN,
VMAC30 SYSOUT and other JES-owned DDs that don't have actual
Jun 3, 2009 allocations. Now, 'OTHER' really is "other".
-Dataset TYPE30_D now has DEVCLASS and DEVTYPE kept, just
in case you get "other" values and need to know them.
Thanks to Kim Westcott, New York State OFT, USA.
Change 27.117 MXG 27.03-27.04. Change 27.071 introduced an extraneous
TRNDDB2A %; in line 44 that is now removed.
Jun 3, 2009
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 27.116 Type 14/15 records with a non-zero BLKSIZE (from JFCB, in
VMAC1415 record bytes 167-168), but with a Subtype=5 "Additional
Jun 3, 2009 Data Set Characteristics Section" with SMF14BFG='C0'X,
(indicates that the SMF14LBS blocksize field is valid),
have SMF14LBS=0, and MXG logic replaced BLKSIZE with the
newer SMF14LBS with SMF14BFG='1.......'B. The MXG logic
is revised to use MAX(BLKSIZE,SMF14LBS) if the SMF14BFG
bit is on, but this seems to be an APARable IBM problem.
Originally, 23173 obs had BLKSIZE=0, but after the change
there were only 1186 TYPE1415 obs with BLKSIZE=0.
Thanks to David Shaw, M&T Bank, USA.
Change 27.115 Using TIMETABL to SYNC59 individual systems with a value
VMXGTIME in column 71 also required you to %LET MXGTIM59=YES, but
Jun 3, 2009 that is redundant and is now removed; the value found in
71-72 is always used (0, blank, 1, or other minutes).
====== Changes thru 27.114 were in MXG 27.04A dated Jun 2, 2009========
Change 27.114 MXG programs that are "TAPE-aware" test the "PDB" DD for
ANALDB2R its device type of tape to avoid multiple mount/rewinds,
VMXGTAPE but they only were tested with JCL allocation. If the
Jun 5, 2009 the tape "PDB" is allocated by a LIBNAME statement it may
fail with "ERROR: NO LOGICAL ASSIGN FOR filename ddname".
MXG's algorithm to identify a LIBNAME as a tape device
CLEARs the LIBNAME and re-opens it as a FILENAME; a CLEAR
is required to change libref from a LIBNAME to FILENAME,
but a CLEAR unallocates the libref from the library, and
a subsequent reference (to read it) caused the ERROR.
But by moving %VGETENG to first test the "ddname" for its
device type, if we get the device type back, then that
ddname was OPENed, either by a prior use, or because it
was allocated by a LIBNAME statement, and we're done,
since we have the device type. But if %VGETENG returns
"UNKNOWN" for device type, then we know that library was
JCL-allocated and was not OPEN, so we could safely CLEAR
the LIBNAME and open as FILENAME open with a FILENAME and
still get back to the LIBNAME. But, because the LIBNAME
has NOT been OPENed, we really don't need to CLEAR it
before opening it as a FILENAME, so FILENAME ... CLEAR is
now removed from these members.
The CLEAR is still required to switch the other way, from
a FILENAME to a LIBNAME, so a DD name allocation rather
than a LIBNAME allocation may be required. For example,
this ERROR will also occur with the WEEK/MONTH builds if
you use the TAPETEMP option, and if you try to allocate
TAPETEMP with a LIBNAME statement. There is no possible
circumvention, as we must, by design, issue the CLEAR, so
you must use a DD statement rather than a LIBNAME.
Thanks to Brian A. Harvey, HCL America, USA.
Change 27.113 OMCI INTR Subtype 200 RECSUBTY 4 segments are 58 bytes in
VMACOMCI length; MXG code guessed 53 bytes (and noted "UNTESTED").
Jun 1, 2009 The guess caused INPUT STATEMENT EXCEEDED error.
Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA.
Change 27.112 VMXGALOC only correctly allocated weekly PDBs datasets if
VMXGALOC you were using Week-To-Date logic, and if FIRSTRUN=YES,
BLDSMPDB the TREND datasets were not correctly allocated.
May 31, 2009
Jun 11, 2009 BLDSMPDB did not protect for no datasets in the PDB for
WEEKLY processing, and did not end a loop after all of
the datasets were processed, causing in a failed SUBSTR
function ERROR. The loop logic now runs only if datasets
exist in the input, and then only for the number of them.
Thanks to Gary Havlatka, Creative Automation, USA.
Change 27.111 Support for multiple TMS/CA-1 catalogs creates IHDRTMS5
IHDRTMS5 exit, adds &TMSJFCB FILENAME=INFILENM &TMSEOV options to
TYPETMS5 the INFILE TMC statement, creates new TMSLIB and TMSDATE
TYPSTMS5 variables, now inserted into the sort BY list used:
VMACTMS5 BY ZDATE TMSLIB TMSDATE VOLSER ....
VMXGINIT and, in the example code in IHDRTMS5, show how you can
May 31, 2009 populate TMSLIB by parsing the DSNAME of each TMC infile,
and how to populate TMSDATE with the Create Date from the
JFCB of each infile.
-The location of the INFILE, IMACZDAT, and IHDRTMS5 was
moved into the MACRO _CDETMS macro definition in VMACTMS,
to match the expected sequence of those exits.
-New macro variable MACTMSH is created for "instream" code
alternative for the IHDRTMS5 header exit.
-New macro variable TMSJFCB=JFCB=TMSJFCB ; is set ONLY if
if MXG is executing under z/OS, where JFCB= exists.
-New macro variable TMSEOV=EOV=TMSEOV ; is now set ONLY
if MXG is executing under SAS, as WPS JFCB= exists.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 27.110 -I. MXG 27.05 execution tests with WPS 2.3.5 under ASCII:
DOC Summary: Most MXG programs execute under WPS error-free.
Jun 5, 2009
AUTOEXEW This program that creates MXG datasets cannot be used:
MXGWPSV2 TYPESVC - DS8000 Disk SAN Volume Controller XML record;
READDB2 WPS does not support NAMED INPUT.
UTILXRF1
TYPELSAR This program that creates MXG datasets bypasses a new MXG
VMACNMON feature when executed under WPS:
VMXGINIT TYPETMS5 - CA-1/TMS Catalog support for multiple TMC's:
Jul 4, 2009 Added in Change 27.111, the INFILE EOV option
(that allowed concatenation recognition so
multiple catalogs could be concatenated) is
not supported, so &MXGEOV is blank with WPS.
These report example programs use features not in WPS:
ANALCISH - ALL report - PROC SQL run time.
ANAL80A - PROC REPORT.
ANALAVAL - PROC CALENDAR.
ANALPATH - OVERPRINT option PUT statement.
UTILXRF1 - TRANSCODE attribute in DICTIONARY.COLUMNS
UTILXRF1 - VALIDVARNAME=UPCASE.
-The below were previously listed here as not usable, but
the inhibiting feature is now supported:
ANALMPL - PROC PLOT VREVERSE,VPOS options not there.
ANALTAPE - PROC PLOT VREVERSE,VPOS options not there.
SASAUTOS - Warning not assigned, macros empty
-The HBAR option of PROC CHART is now supported, so these
members are now reinstated in the WPS QA tests:
ANALCICS ANALMONI ANALPRNT ANALSMF
-WPS 2.3.5 does not support SAS "NAMED INPUT" syntax, used
in TYPESVC Open Systems DS8000 Disk SAN Volume Controller
support. The NAMED INPUT syntax has always been in SAS:
INPUT FIELD1= FIELD2= ;
and is used to read data records that have
field1=value1 field2=value2
but it wasn't needed in MXG until this pseudo-XML data
file was supported last November.
-WPS 2.3.5 does not support the EOV= option on the INFILE
statement, newly needed for Change 27.111 to support read
of multiple TMC libraries in TYPETMS5.
-WPS 2.3.5, like 2.2, doesn't support OPTION VALIDVARNAME.
Change 25.025 removed VALIDVARNAME=V7 from WPS CONFIGW2,
because the V7 function, to permit long variable names,
was the default in WPS. But now, in MXG's UTILXRF1, used
to create the DOCVER documentation, I needed to set SAS
option VALIDVARNAME=UPCASE so the variable names out of
the PROC CONTENTS were upper case, which causes WPS 2.3.5
to fail with
ERROR: System option "VALIDVARNAME" is not known.
-WPS 2.3.5 doesn't support TRANSCODE attribute in the
DICTIONARY.COLUMNS dataset, used only in UTILXRF1 to
create the DOCVER documentation. The TRANSCODE attribute
is new in MXG and only exists in SAS v9, so MXG did not
execute the &MXGNOTRA when under WPS due to the SASVER=8
that is set when MXG executes under WPS, but this usage
is now also circumvented so the rest of the UTILXRF1 can
be tested under WPS.
-WPS 2.3.5 SASAUTOS library has no members, which caused a
minor WARNING: SASAUTOS IS NOT ASSIGNED. VMXGINIT issues
LIBNAME SASAUTOS LIST; to list the concatenates, but that
statement is now conditionally not-executed with WPS to
eliminate that harmless WARNING message on the log.
With SAS, the SASAUTOS library is required because %TRIM
is delivered as a source-code %MACRO in the SASAUTOS PDS,
but WPS implemented %TRIM internally, so MXG doesn't need
to point to SASAUTOS FILENAME under WPS.
NOTE: While FILENAME SASAUTOS is NOT required with WPS,
MXG under WPS still requires the
OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB;
executed in VMXGINIT, so that WPS will look in
//SOURCLIB to resolve all %MACRO references.
So all references to SASAUTOS FILENAME in the MXGWPSV2
JCL Procedure example and in the AUTOEXEW ASCII autoexec
file were removed. Just for documentation, the WPS .CFG
file has the default -SASAUTOS \&wpsroot\macros.
-The COUNTW() function, added to TYPENMON in Change 27.080
only exists with SAS V9, so TYPENMON failed with either
SAS V8.2 or WPS 2.3.5. NMON code was modified to only
use COUNTW() if under V9; a DO LOOP to count the commas
is used when not under SAS V9; same change in TYPELSAR.
-New dataset names "WORK._temp1559410888854220" structure
are created internally by PROC TRANSPOSE.
-Circumvented in READDB2. WPS %Macro Compiler does not
resolve triple-percent-signs the same way that SAS does,
which caused WPS to die with a compiler error in READDB2.
but, all READDB2 %%% and %% tokens are end-delimiters for
old-style-macro-definitions, and, most fortunately, they
are no longer required (the problem they circumvented was
fixed in SAS long ago), so they could be replaced with a
single percent sign in READDB2. (There are still cases
when %%% is required in other MXG members, often before
an embedded %INCLUDE statement, but WPS handles those
without error.)
-Fixed in WPS Build 12169:
WPS 2.3.5 failed when a FILENAME with concatenated input
files was read; the RECFM/LRECL on the FILENAME statement
was not honored and a STOPOVER resulted when the system
default of V/256 was used for F/340 data. This WPS error
when files are concatenated is fixed in WPS Build 12169.
-Run Time Comparisons on Windows, zero observations input:
MXG QA's first 36 "steps" create all 4700 MXG datasets in
the LIBNAME VERSvvrr, and run times were comparable, with
SAS V9.2 taking 10 min and WPS 2.3.5 taking 13 minutes.
But Step 47 TESTANAL, took over 80 Minutes (vs 2 for SAS)
due to a WPS error in its PROC SQL, BUT, an error that is
ONLY likely to occur in MXG's QA tests. MXG's %VGETOBS is
invoked frequently in ANALxxxx examples, to test if a
dataset exists and if it has observations, and it uses
PROC SQL: SELECT FROM DICTIONARY.TABLES
WHERE LIBNAME= MEMNAME=;
The (internal) DICTIONARY.TABLES dataset has one obs for
each dataset in each LIBNAME. The MXG QA TESTANAL step
allocates the 37 different LIBNAMES (PDB, WEEK1-WEEK5,
MONTH1-MONTH5, etc) that may needed by ANALxxxx programs
to that VERSvvrr directory with its 4700 datasets. So,
there are 37*4,700=173,900 datasets in DICTIONARY.TABLES,
which overwhelms the defective WPS PROC SQL; each execute
takes over 90 SECONDS of CPU and Elapsed time. WPS has
identified their PROC SQL error and it will eventually be
fixed.
In addition to the long run time of the QA job due to the
PROC SQL error, the QAWPSXX job has never completed. It
gets to the TESTANAL code, and then in ANAL115 it just
hangs, continuing to execute, using CPU time, but with no
further log messages, and the last message was a %VGETOBS
PROC SQL execution. Skipping ANAL115 allowed the TESTANAL
to get to ANALDB2R before it again hung, and again that
last message was a PROC SQL execution. But since each of
the ANALxxxx programs execute standalone, this too is an
error unlikely to occur outside the MXG QA test runs.
II. Z/OS Specific Tests, unresolved as of July 4, 2009:
-The Large ARRAY(256,512) problem in VMXGGETM that was
fixed in WPS 2.3.4 (WPS Error #6276, Change 26.258)
has shown up again in WPS 2.3.5. UTILGETM is only used
in the MXG Test Jobs, to create a small SMF file with
a few records of each type and subtype, so this is not a
fatal error for normal execution.
-In the QA job only, after many data steps were run and
many datasteps had been written to the PDB library, the
BUILDPD3 step job failed with "PDB LIBRARY CORRUPTED"
error message. However, since the BUILDPD3 program runs
fine when outside of the QA job, this is most likely an
issue with WPS "PROC SQL".
III. Miscellaneous
-The //LOGCFG DD is no longer used by WPS, so it is now
removed from MXGWPSV2 JCL Procedure example.
Change 27.109 QA COMPALL program found character to numeric conversion
VMACLDMS for not-kept-variable SEGMENT in VMACICE and VMACXPTR and
VMACXPTR for not-kept-variable LDMSTYPE in VMACLDMS, both fixed.
May 29, 2009 The COMPALL program compiles ALL of the MXG code members
that read SMF records, in a single (MASSIVE) DATA step to
create 1907 datasets, all with zero observations because
the INFILE SMF is a zero-length or DD DUMMY file.
So COMPALL is also a good SAS compiler stress test.
Last year, Change 26.217 compared COMPALL with SAS 9.1.3
and WPS 2.2, but the z/OS comparison was wrong.
Now with MXG 27.04, which creates 1907 datasets and more
variables, and now using WPS 2.3.5, SAS 9.2 and SAS 9.1.3
these comparisons are observed:
Compiler Platform Run Time Memory Required
SAS 9.2 Win/XP 96 seconds 1185 MB
SAS 9.1.3 Win/XP 86 seconds 1158 MB
WPS 2.3.5 Win/XP 101 seconds not reported
SAS 9.2 z/OS 7 minutes 1210 MB
SAS 9.1.3 z/OS 12 minutes 1194 MB
WPS 2.3.5 z/OS 17 minutes 1037 MB
Enabling the full diagnostic options to print all source
only increased the SAS V9.2 WIN/XP run time by 6 seconds.
Change 27.108 &NULLPDS, &LOAD, &SASAUTOS JCL Symbolics in MXG JCL Proc
MXGSAS examples are removed. They were never required, rarely
MXGSAS92 used, and then, only in ancient releases of SAS. And now
MXGSASV9 have caused JCL errors when very old and more recent JCL
MXGSASV8 procs are used in the same job. such as this error:
May 27, 2009 IEC143I 213-04,IFG0194D,M577FPA1,SASMXG,STEPLIB
MXGWPSV2 Their only purpose was to override the //STEPLIB or the
JCLQAWPS //SASAUTOS DD statements, which can easily be done in the
Jun 1, 2009 JOB's JCL, with no exposure to the &NULLPDS DISP issues.
(See CHANGESS for the many NULLPDS historical hits!)
-JCLQAWPS moved LIBRARY to be before SOURCLIB so its JCL
overrides matched the order in MXGWPSV2.
Thanks to Stuart Wildey, Morgan Stanley, USA.
Thanks to MP Welch, SPRINT, USA.
====== Changes thru 27.107 were in MXG 27.04 dated May 27, 2009========
Change 27.107 Support for BMC's IMF 4.4 (COMPATIBLE) added some new
VMACCIMS variables and some variables MXG had overlooked.
May 26, 2009 These new variables are now created in IMFTRAN:
Jun 2, 2009 CPUTRNX ='CPU AFTER*TRN STOP SET'
TRNOTCLP='IMS*CONNECT*CLIEN*PORT NUMBER'
TRNMQMID='MQS*MESSAGE*ID'
TRNCVTTZ='TRNCVTTZ*GMT*TIME ZONE*OFFSET'
TRNCAPPL='CICS*APPLID'
TRNFALSC='FALSE*SCHEDULES'
TRNTFLAG='COPY OF*RATTFLAG*DET TRACE'
TRNFALST='FALSE*SCHEDULE*ELAPSED*TIME'
This change has only been tested with 4.3 records.
Jun 2: TRNxxxxx fields wrong; Trace Table +80 vs +72
BMC APAR BAI9444 documents that the IMF Transaction CPU
time can exceed the transaction elapsed time, because the
APAR BAI9312 excluded the "stopped term thread activity"
time from being included in transaction elapsed time, by
setting the transaction stop time upon completion of the
Get Unique, regardless of whether it returned another
message. When it doesn't return another message, the
region goes through term thread, and the CPU used by the
terminate thread can cause the total transaction cpu to
exceed transaction elapsed time, since the transaction
stop time is set before term thread. BAI9444 modified the
IMEUTMR7 timing routine to separately record any CPU time
calculated after transaction stop time, in a new fields
named TRNXCPU, which MXG outputs in new variable CPUTRNX,
so you can identify that is the cause of CPU time greater
than elapsed time in IMS.
Change 27.106 Support for z/OS 1.10 storage metrics in SMF 119 create
VMAC119 these four new subtype=5 variables in TY11905 dataset:
May 25, 2009 TS6CEALO='CURRENT*ECSA*STORAGE*ALLOCATED'
May 28, 2009 TS6CENIU='CURRENT*ECSA*ALOC BUT*NOT INUSE'
TS6CPALO='CURRENT*AUTH PRIVATE*ALLOCATED'
TS6CPNIU='CURRENT*AUTH PRIVATE*NOT IN USE'
May 28: The four INPUT statements are &PIB.8., not 4.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANDADA
Thanks to Aylin Kavas, Royal Bank of Canada, CANDADA
Change 27.105A-PDB.TYP70 variables with "CPU" in their name or label are
DOC supposed to contain only metrics for the "CP" engines.
May 24, 2009 Separate variables, with "ZIP" or "IFA" in their name or
their label, contain the metrics for zIIPs and zAAP/IFAs.
Those three types of engines require separate capacity
analysis (and even have different capture ratios in MXG's
RMFINTRV dataset).
And PDB.TYPE70 variable CPUPATTM contains the Parked Time
for (only) the "CP" engines.
However, the 64 individual-engine Parked Time is stored
in 64 variables named CPUPATM0-9,A,B.... So you could
have zero CPUPATTM in this MVS System, but CPUPATM4 could
be non-zero, if your 4th engine is a zIIP, for example.
-PDB.TYPE70 variable CPUWAInn for nnth engine's LPAR Wait
is variable NEWWAIT in PDB.TYPE70PR for that engine, and
the variable MVSWAInn for the nnth engine's MVS Wait is
variable ORIGWAIT in PDB.TYPE70PR; variable ORIGWAIT and
SMF70WST are very close in PDB.TYPE70PR, but SMF70WST is
smaller by as much as a half second in 15 minutes.
Change 27.105 The ACF2VR dataset is enhanced with new ACFMTYPE variable
FORMATS that is formatted by new $MGACFTY format to decode the
VMACACF2 combination of the 2nd-4th bytes of ACVMFRES and the HEX
May 21, 2009 value of ACVMFLGS NI (LOGICAL AND'ed) with '3E'x. These
new values are primarily for DB2 activity identification.
Thanks to Jake Phillips, Lowe's Companies, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to David Pflum, CA, USA.
Change 27.104 The BVIR TS7700 HYDRA data contains GMT values for all of
VMACBVIR its timestamps, SMFTIME, STARTIME, ENDTIME, and VERTIME,
May 24, 2009 whether the data is in History File or SMF File format,
Jun 1, 2009 but there is no field with the GMT Offset time, so you
must tell MXG your GMT Offset value, with this syntax
%LET MACKEEP= MACRO _BVIRGMT -18000 % ;
if you want those datetimes on your local time zone.
For USA sites, the value is negative, -18000 for EST at
5 hours, -14400 for EDT at 4 hours behind GMT, etc.
You set that GMT offset value using:
- SMF-FORMAT BVIR DATA:
// EXEC MXGSASV9
//SMF DD DSN=BVIR.SMF.FORMAT,DISP=SHR
//PDB DD DSN=BVIR.PDB.LIBRARY,DISP=(,CATLG),....
%LET MACKEEP= MACRO _BVIRGMT -18000 % ;
%INCLUDE SOURCLIB(TYPSBVIR);
or
- HISTORY-FORMAT BVIR DATA:
// EXEC MXGSASV9
//BVIRHIST DD DSN=BVIR.HISTORY.FORMAT,DISP=SHR
//PDB DD DSN=BVIR.PDB.LIBRARY,DISP=(,CATLG),....
%LET MACKEEP= MACRO _BVIRGMT -18000 % ;
%INCLUDE SOURCLIB(TYPSBVIH);
Labels were revised Jun 1.
Thanks to Perry Lim, Union Bank, USA.
Change 27.103 New INTERVAL values of THREEMIN and TWOMIN are created,
VMXGDUR and they can be used in any MXG INTERVAL= parameter in
May 21, 2009 ALL ANALxxxx/ASUMxxxx/TRNDxxxx/RMFINTRV invocations.
Thanks to Jacob Nudel, Thomson Reuters, USA.
Change 27.102 PARTNCPU and other variables in PDB.ASUM70PR could be
VMXG70PR missing values if the last LPARNAME in this sort order
May 20, 2009 BY CECSER SYSPLEX SYSTEM SYSNAME SMF70GIE GMTOFFTM
LPARNUM LPARNAME;
was for a non-z/OS LPAR, as the "CP-engine" variables
are missing values in non-CP-engine LPARS. This could
only occur with recent ASUM70PR enhancements in 27.02+
that added non-CP-engine LPARS to PDB.ASUM70PR dataset.
This case had a z/VM LPAR with only IFLs as last LPAR.
By changing sort order to GMTOFFTM DESCENDING LPARNUM,
the LAST LPAR for every interval will be LPARNUM=0,
LPARNAME='PHYSICAL' LPAR, which always has the variables.
Thanks to Paul Naddeo, FISERV, USA.
Change 27.101 -PRISMA log record could have colon or period delimiters
VMACPRPR in DATE or TIME character fields, so MXG had two separate
May 20, 2009 links for conversion, but four combinations could exist,
Jun 2, 2009 causing missing values in STARTIME and ENDTIME. But only
Jun 22, 2009 one conversion is needed, by using '.:' in the SCAN() to
decode with whichever delimiter is present.
-Variable COPY was not kept in PRPR1620 dataset.
-Jun 19: JOBNAME increased to $128 as it can contain more
text. Fortunately, since PRISMA code is executed
standalone, with only the PRISMA log file read, this ONLY
impacts the length of JOBNAME in the PRISMA datasets.
-Variables COPY, UNKNOWN, PRINTCNT, MEDIANUM, OFFSETS in
PRPR1620 are read in that order to correct values.
Thanks to Nik Marien, KBC Global Services NV, BELGIUM.
Change 27.100 -MXG "trashed" dataset ZRBLCP in RMF III from z/OS 1.10
VMACRMFV because MXG (in a rare case) didn't use the triplet for
May 20, 2009 offset/length for the INPUT of the CPC Logical Processor
May 25, 2009 Section (DSECT ERBCPCDB). 24 bytes inserted after the NR
of LCPUs, and 8 bytes added to each LCPUADDR segment with
CPUG3 Version=5 and CPCDB Version=4 are now properly read
using the triplet, which will also protect for future IBM
changes, transparently, without trashed output data.
-IBM RMF III Support provided doc of the new LCPUADDR data
fields, in those extra bytes, now these new variables
LCPUPRMN='PROC*MIN*WEIGHT'
LCPUPRMX='PROC*INI*WEIGHT'
LCPUPOLW='POLAR*WEIGHT'
in the ZRBLCP dataset.
-But in validating this correction, I saw that there were
observations for each LCPUADDR, including offline engines
and LCPUADDR that were NEVER dispatched during each one
minute interval, a waste of disk space, so the logic now
only outputs ZRBLCP observations if LCPUPDTM dispatch is
non-zero (but that could be overridden in MACRO _EZRBLCP
if you really want all the zero dispatch intervals to be
created).
Thanks to David Lo, Bank of America, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 27.099 -The optional Omegamon DB2 segment for CICS/TS 3.2 or 4.1
IMACICOB had correct counts but the durations were way too small.
May 20, 2009 They were divided by 4096 instead of multiplied by 16 in
Change 25.238, when a new block of code for CICS/TS 3.2+,
for SMFPSRVR GE 65.0 used the /4096 conversion, expecting
a TODSTAMP value, instead of the old *16 conversion for
16 microsecond values. I must have misread the DSECT.
The new block with /4096, and the tests for SMFPSRVR are
now all removed, and there is a single code block for all
CICS versions.
-The 100-byte segment always exists when enabled, but its
internal length is zero if the transaction did not call
DB2, so the MXG logic now only INPUTs those 24 fields if
that length is non-zero (so those variables will have a
missing value in non-DB2 transactions, instead of all
having values of zero).
Thanks to Jim Polenti, Edward Jones, USA.
Thanks to Jeana M. Bechtel, Edward Jones, USA.
Change 27.098 -Typos in BLDSMPDB for WAS were corrected in BLDSMPDB
BLDSMPDB the statement weekkeep=&wek2kep.
VMXGALOC was changed to weekkeep=&wek2keep,
May 19, 2009 and after line 437, this statement was inserted
dayskeep=&day2keep,
-In VMXGALOC, the %GLOBAL was removed as superfluous;
the variables are being set by a SYMPUT which is an
implicit GLOBAL. This removed spurious messages on the
SAS log, messages that were different when MXG was run
in a Window versus run in Batch.
Thanks to Gary Havlatka, Creative Automation, USA.
Change 27.097 -PDB.DB2STATS now has ALL DB2 STATISTICS interval data.
READDB2 DB2 V9 DB2STAT0, DB2STAT1, DB2GBPST, DB2STAT4 (IFCID 225)
VGETOBS are merged to create PDB.DB2STATS, and for DB2 V8, the
VMACDB2 DB2STAT0, DB2STAT1, T102S225 are merged in PDB.DB2STATS.
May 24, 2009 -All variables (QW0225xx) from DB2STATS4 (DB2 V9+) are
Jun 25, 2009 automatically merged into the PDB.DB2STATS dataset.
-All variables (QW0225xx) from T102S225 (DB2 V8) can be
merged into the PDB.DB2STATS dataset, but you may have to
make some updates, if you don't use %READDB2, below.
-READDB2 always creates DB2STAT4 with IFCIDS=STATISTICS.
-READDB2 only creates T102S225 if IFCIDS=225 .... is used.
-READDB2 updates PDB.DB2STATS with DB2STAT4 if STATISTICS
is specified. If IFCID 225 is also specified, then the
T102S225 is also updated into PDB.DB2STATS.
-If you use BUILDPDB, TYPEDB2, TYPSDB2 instead of READDB2:
-All variables (QW0225xx) from DB2STATS4 (DB2 V9+) are
automatically merged into the PDB.DB2STATS dataset.
-All variables (QW0225xx) from T102S225 (DB2 V8) can be
merged into the PDB.DB2STATS dataset, but you have to
tell MXG you have V8 data to be added; see below.
-You should use PDB.DB2STATS for all statistics reports,
replacing use of DB2STAT0, DB2STAT1, DB2STAT4, DB2GBPST,
and T102S225 in your DB2 reports.
More details:
-DB2 V9 DB2STAT4 (optional IFCID=225, ID=100, subtype=2)
and DB2 V9 DB2GBPST (100 subtype 1 QBGL) variables are
now merged to expand existing PDB.DB2STATS dataset to
contain all variables for each interval for each DB2
Subsystem, i.e., all possible variables from the DB2
ID=100 Subtype 0, 1, or 4 SMF records. DB2STAT4 vars are
added by %INCLUDEs of TYPEDB2, TYPSDB2, or BUILDPDB, or
by using %READDB2(IFCIDS=STATISTICS) program for V9.
-DB2 V8 writes IFCID=225 as an SMF 102 subtype 225 Trace
record, and MXG creates the T102S225 dataset for V8, but
it has the same variables as the V9 DB2STAT4, so DB2 V8
IFCID=225 variables can also be added into PDB.DB2STATS:
-%READDB2(IFCIDS=STATISTICS 225,PDBOUT=PDB) will create
both T102S225 and DB2STAT4 and merge each to expand
and populate the PDB.DB2STATS dataset with both V8 and
V9 IFCID=225 variables.
-To add V8 IFCID=225 processing to BUILDPDB, and to add
those variables to PDB.DB2STATS, you need to EDIT
these statements into these MXG exit members into your
"USERID.SOURCLIB" tailoring PDS library/directory:
EXPDBINC:
%INCLUDE SOURCLIB(VMAC102);
EXPDBVAR:
MACRO _VARUSER _V102225 %
EXPDBCDE:
MACRO _CDEUSER _HDR102 _C102225 _END102 %
EXPDBOUT:
_SDB2STY
-If you instead use these other ways to create T102S225
dataset for DB2 V8, depending on how you created it:
if created by old-style macro macro variable
TYPE102 _W102225 &W102225
TYPS102 _L102225 &P102225
%READDB2 _W102225 &W102225
%READDB2(PDBOUT) n/a &PDBOUT
EXPDBOUT PDB PDB
then you have to use %LET to set the DDNAME of your
T102S225 dataset's library, and then insert the new
_SDB2STY macro token in your source program, after you
have created PDB.DB2STATS and PDB.T102S225, e.g.:
%LET PDB2STY=PDB;
_SDB2STY;
RUN;
-READDB2 in MXG 27.02-27.03, when ONLY the IFCIDS=225 was
requested, caused a 10-fold increase in CPU time if there
were lots of other DB2 records, because READDB2 in those
versions (incorrectly) created all of the other DB2ACCTx
and DB2STATx datasets when only T102S225 was desired.
lots of unwanted ID=101 records. Now, only T102S225 is
created if only IFCIDS=225 is specified.
-All executions of READDB2 should be faster; all non-DB2
SMF records are immediately skipped as soon as the SMF ID
is read; previously, all DB2 Product Headers were read
before record selection/skipping was done.
-PROC COPY IN=WORK OUT=&PDBOUT was incorrectly run (copy
each DATASET to the &PDBOUT libname) when &PBOUT=YES,
was specified, causing LIBNAME YES NOT FOUND. Now, the
PROC COPY is bypassed if PDBOUT=YES.
-VGETOBS was enhanced with new NOEXIMSG=NO argument that
bypasses printing of the DATASET DOES NOT EXIST message
and the DATASET HAS nnn OBSERVATIONS message, useful when
VGETOBS is used only to detect that a dataset exists.
-These new variables, based on IBM MEMU2 report example:
are created in PDB.DB2STATS from the DB2STAT4/T102S225:
CUSHION = QW0225SO+QW0225MV+QW0225CR;
NDB2STOR= QW0225EH-QW0225GM-QW0225GS-QW0225FX-QW0225VR
ALLOWSTR= QW0225RG-CUSHION-NDB2STOR;
THRDUSE = QW0225RG-CUSHION-NDB2STOR-QW0225GM
-QW0225AS-QW0225FX-QW0225EL;
THRDFTPT= (QW0225VR-QW0225AS+QW0225GS) /
(QW0225AT+QDSTCNAT);
MAXTHRDS= THRDUSE / THRDFTPT;
TOTTHRDS= QW0225AT+QDSTCNAT;
OVERALLO= MAXTHRDS - TOTTHRDS;
CUSHION ='CUSHION*WARNING'
NDB2STOR='TOTAL*DBM1*STORAGE'
ALLOWSTR='ALLOWABLE*STORAGE'
THRDUSE ='THREAD*STORAGE*USED'
THRDFTPT='THREAD*STORAGE*PER THREAD'
MAXTHRDS='MAXIMUM*THREADS'
TOTTHRDS='TOTAL*THREADS'
OVERALLO='OVER*ALLOCATED*THREADS'
Thanks to Ray Dunn, CIGNA, USA.
Thanks to Deborah L. Soricelli, CIGNA, USA.
Change 27.096 There is a new "MEM" object with 15 new variables:
VMACNMON MEMTOTAL HIGHTOTAL LOWTOTAL SWAPTOTAL MEMFREE
May 18, 2009 HIGHFREE LOWFREE SWAPFREE MEMSHARED CACHED
BIGFREE BUFFERS SWAPCACHED INACTIVE ACTIVE
instead of the non-overlapping 5 memory variables that
were in previous NMON MEM Object records.
The order of the two LOW/HIGH sets in these new fields
is clearly mis-documented in the "MEM" Header record;
the LOW value precedes the HIGH value, so MXG's code now
matches the actual data rather than the documentation.
-Labels for variables REALFREE & VIRTFREE didn't include
"PERCENT". Those memory percentages are calculated as
REALFREE=100*REMBFREE/REMBTOTL;
VIRTFREE=100*VIMBFREE/VIMBTOTL;
-Both sets of memory variables are kept in NMONINTV.
-"NMON", "Nigel's Monitor", is now delivered as part of
TOPAS in AIX 5.3/6.1 or VIRTUAL I/O SERVER VIOS 2.1.
Thanks to Tom Draeger, Aurora Health Care, USA.
Change 27.095 The TRND23 member had not been updated to use the macro
TRND23 variables TRENDOLD TRENDNEW TRENDINP, which optionally
May 17, 2009 set the libnames for new, old and input trend libraries,
and old macro names expected the week input in the "PDB"
libname, when it should have used "WEEK" to match the
other TRND Trending members.
Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd, AUSTRALIA
Change 27.094 A REALLY invalid SMF 30 Subtype 1 INPUT EXCEEDED RECORD
IMACACCT error had NRACCT=127 and LENACCT=400, impossible values,
May 14, 2009 and there was only trash at the OFFACCT location. MXG
only decodes 9 ACCOUNTn fields, printing a message for
the 10th, but IMACACCT did not protect for this much
of invalidity. Now, it stops reading the ACCT fields
when the 10th is encountered, with enhanced diagnostics.
Thanks to Barbara Nitz, Deutsche-Boerse, GERMANY.
Change 27.093 Variable JESNR in TYPETPMX datasets was only 5-digits but
VMACTPMX JESNR can now be up to seven digits. The VMXGJESN member
May 13, 2009 is now %INCLUDEd after JCTJOBID has been input, and the
Mar 20, 2012 JESNR is now created from JCTJOBID rather than just input
of the last five digits.
Mar 2012: Maximum JESNR is 999,999 because the first of
seven digits is always a zero.
Thanks to Paul Volpi, UHC, USA.
Thanks to James D. Lieser, UHC, USA.
Change 27.092 -VMXGOPTR errored with SAS V8.2 or V9.2 in different ways:
VMXGOPTR -ONLY under SAS V8.2, MXG 27.03 caused BUILDPDB errors in
VMXGSUM the VMXGSUM invocation for SUMSTATB with error messages
May 14, 2009 MXGNOTE: VMXGSUM FROM MXG 27.03 INVOKED BY SUMSTATB
May 18, 2009 ERROR: OVERFLOW HAS OCCURRED; EVALUATION IS TERMINATED.
May 22, 2009 ERROR: THE MACRO VMXGOPTR WILL STOP EXECUTING.
This error is ONLY in the SAS V8 %Macro compiler, and is
circumventable; the problem is that V8 %Macro compiler
is not terminating strings at the equal sign as expected,
but by wrapping the strings in double-quotes, to make it
a character compare rather than an evaluated comparison
circumvented the compiler error.
There is also an associated change between V8 and
V9 in the limit to the value of a numeric compare in the
macro language from 2**32 in V8 to 2**64 in V9, causing
the compare to work accidentally in V9 but not in V8.
The one statement in VMXGOPTR that caused SAS V8 to fail
IF "&STRING"="123456789123456789" %THEN ....
was corrected, so this part of MXG continues to execute
with SAS V8.2, BUT USING V9 IS MUCH BETTER AND SAFER!
-Enroute to isolating the actual error, we investigated
VMXGSUM for long-length-macro-text, a known past problem
with the SAS Macro Language, and did reduce the length of
some macro variables in the updated VMXGSUM, but it was
not the cause of the OVERFLOW.
This simple test isolated the V8-only compiler error:
%MACRO TESTCASE;
%LET STRING=12345678912345689;
%IF &STRING=12345678912345689 %THEN %PUT TEST FAILED;
%MEND TESTCASE;
%TESTCASE;
When executed on SAS V9, "TEST FAILED" was printed. when
run under SAS V8.2, the OVERFLOW occurred.
-Since V8.2 is ancient, I won't ask SAS Institute to spend
their time fixing the %Macro compiler error, with what
appears to be a complete circumvention. Chuck and I spent
a great deal of time chasing this V8-ONLY error, just so
those of you that are still limping along on ancient V8,
and knowing that you do need V9 (but just can't find time
to install it) can still get the full benefits of all of
the new features and enhancements in the current MXG.
-ONLY user SAS V9.2, just to get even, its macro compiler
found invalid syntax of %THEN %THEN in VMXGOPTR, when it
was called from deep within READDB2, causing V9.2 error
message NO MATCHING %IF FOR %THEN.
SAS V9.1.3 didn't burp with that same invalid syntax!
Thanks to Francois Chable, DTF/DESI, FRANCE.
Thanks to Hai Dang, DTF/DESI, FRANCE.
Thanks to Winnie Peng, Hawaii Medical Service Association, USA.
Change 27.091 ASG TMON/CICS variables WTSCWTTM and WTSCWTCN were input
VMACTMO2 reversed, with the counts in the time field (but divided
May 13, 2009 by 1 million!) and the time in the count filed (and NOT
divided as it should be), in three separate INPUTs.
Thanks to Shantha Hallett, Capgemini UK, ENGLAND
Change 27.090 Became Change 27.097.
Change 27.089 -The dataset TYPE72DL delay counters R723RW01-R723RW15 are
VMAC7072 now described by new variables R723RN01-R723RN15, from
May 11, 2009 the Resource Delay Type Names Section added in z/OS 1.10
to the SMF 72 Subtype 3 record. There is a separate Name
Section for each of subsystems (DB2,CICS,IMS,SMS,etc.)
that capture delay samples, so each can have a different
description of each of its fifteen delay counters.
-The _BTY72DL "BY list" sort order that removes dupes was
revised by adding RPRTCLAS as the penultimate variable, a
protection required ONLY if you have (unwisely) used the
same name for a Service Class and for a Reporting Class.
The R723RN01 Name fields have not been tested with data;
thus far, all test files have R723RDNN=0.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 27.088 Support for TS7700/BVIR Microcode 1.5.
FORMATS -Format $MGBVIDC added x23 3592 Model E05 x24 Model E06.
VMACBVIR x23='x23:3592 Model E05 (Encrypted)
May 6, 2009 x24='x24:3592 Model E06.
-New DLIBSEQN, Distributed Library Sequence Number is
added to all datasets; while documented as EBCDIC, the
same protective algorithm for GLIBSEQN in Change 27.077
is used for DLIBSEQN in case it really is also ASCII.
-BVIR10 new variable DEFTHRTL
-BVIR30 new variables:
PCTWDFTH AVGDEFTH BASEDFTH PRMIGTTH UNMIGD00
AWAITR00 UNMIGD01 AWAITR01
-BVIR33 new variables:
G1MLCTA1-G1MLCTA4 G1ALCTA1-G1ALCTA4 G2MLCTA1-G2MLCTA4
G2ALCTA1-G2ALCTA4 G3MLCTA1-G3MLCTA4 G3ALCTA1-G3ALCTA4
G4MLCTA1-G4MLCTA4 G4ALCTA1-G4ALCTA4 G5MLCTA1-G5MLCTA4
G5ALCTA1-G5ALCTA4 G6MLCTA1-G6MLCTA4 G6ALCTA1-G6ALCTA4
G7MLCTA1-G7MLCTA4 G7ALCTA1-G7ALCTA4 G8MLCTA1-G8MLCTA4
G8ALCTA1-G8ALCTA4
Thanks to Jens Mohring, HUK-COBURG, GERMANY.
Thanks to Markus Bansemir, HUK-COBURG, GERMANY.
Change 27.087 -NMONBBBP dataset contained blank values for many BBBPnnn
VMACNMON variables; the OUTPUT logic was relocated and revised.
May 5, 2009 -Variable BBBP029='ENTITLED*CAPACITY' instead had value of
BBBP050='ENTITLED CAPACITY OF POOL'. The values are
corrected, and several BBBPnnn labels were revised.
Thanks to Silvio Ferrari, Banca Carige S.p.a., ITALY.
Thanks to Franco Tonelli, Banca Carige S.p.a., ITALY.
Thanks to Gianvittorio Negri, SAS Institute, ITALY.
Change 27.086 -DB2STATS variables QISEKPGE, QISESPGE, QISESFRE, QISESKCT
VMACDB2 QISESKPT and QISEKFRE aren't accumulated fields, but they
May 5, 2009 were deaccumulated; variables QISEKTA and QISECTA were
also deaccumulated, and probably also shouldn't have been
but all test values are zeros for those two variables, so
they have not been validated. All eight variables are no
longer deaccumulated.
-Variable QISESPGE has a default value of 524287 pages
(2GB) that is set by a "hidden" zparm value of "SPRMABVC"
in DSN6SPRC, but IBM STRONGLY RECOMMENDS THAT YOU DO NOT
CHANGE THAT DEFAULT VALUE UNTIL/UNLESS DB2 L2 determines
there is a storage problem.
Thanks to John Shuck, Suntrust, USA.
Change 27.085 Omegamon ONDV datasets created from subtype 203 had blank
VMACOMCI values for the "xTRAN" variable because MXG did not INPUT
May 8, 2009 these three variables from the header: OMCIJOB, OMGAPPL,
and OMSAPPL. Now, all are kept in the OMCI-203 datasets:
OMCIADA OMCIADAT OMCIDLI OMCIDLIT OMCIDTCO
OMCIDTCT OMCIIDMS OMCIIDMT OMCISUPR OMCISUPT
OMCIVSAM OMCIVSAT
Thanks to Richard Schwartz, State Street Bank, USA.
Change 27.084 First MXG 27.03 had two members revised:
VGETDDS -The enhanced VGETDDS wasn't, having not been tested with
VMACIMSA all options; a missing %END and non-defined GOOVOO were
May 5, 2009 added (but that's why I didn't list VGETDDs in the list
May 12, 2009 of Major Enhancements, since it was still in testing, and
May 20, 2009 is not exactly mainstream!).
Additional cleanup of MXGWARN versus MXGERROR, protection
for START END, etc., were added.
-VMACIMSA addition of the new IMS45x statistics records
didn't have the new ST* variables in a FORMAT statement;
this was missed in QA because the same variables were in
a FORMAT statement in VMACIMS.
====== Changes thru 27.083 were in MXG 27.03 dated May 4, 2009========
Change 27.083 -VGETDDS reads "logically concatenated" PDB libraries with
VGETDDS DDnames "starting with", e.g. (PDB1 PDB2 PDB3....) to
May 2, 2009 select a SAS dataset (e.g. JOBS) from all of those PDBs.
You control which data libraries are read in your JCL,
without modifying your program, using VGETDDS & VMXGSET.
-This change enhances VGETDDS to allow dynamic allocation
of DSNAMEs that are GDGs, or of DSNAMES with embedded
DATEs.
-Extensive comments and examples describe how to read a
SAS dataset from multiple data libraries in a single
"SET" statement that doesn't require separate DDs in your
JCL.
Thanks to Brian A. Harvey, HCL America, USA.
Change 27.082 Support for DCOLLECT's z/OS 1.10 change to DCDOVERA, now
VMACDCOL defined as a 32-bit unsigned number, previously defined
Apr 30, 2009 as a 31-bit signed number, requires NO CHANGE to MXG, as
that variable has always (since 1994!) been INPUT with a
INFORMAT of PIB4, which reads all 32 bits. MXG always has
used PIB4 for any variable for which a negative value is
impossible, even when IBM called it a signed value.
(For the miniscule number of variables that actually can
have a negative value, MXG uses IB4 INFORMAT.)
Thanks to Brian A. Harvey, HCL America, USA.
Thanks to Paul Ashford, USAA, USA.
Change 27.081 Support for APAR OA27623 that adds CPU Speed, SM1132SP,
VMAC113 speed in cycles per microsecond, to TYPE113 dataset.
Apr 30, 2009
Change 27.080 -Improved protection for inconsistent NMON data that has
VMACNMON fewer counters in the data records than the number of
Apr 30, 2009 field names in the header record, primarily observed in
May 2, 2009 the DISKxxxx and JFSxxxxx records. The short records were
erratic; most data records had the correct number of data
values, but, interspersed, there were the short records.
-The INPUT statements for each record type are replaced by
an initial INPUT and then the SCAN() function is used to
populate the new WORDS array, so that the NRWORDSIN can
be initially counted, but then the WORDS array is read to
find the last field that is non-blank, and its position
is then NRVALUES, which is used in all comparisons with
the expected number of fields from the header record.
This was because (for example, DISKBUSY) records with 19
header fields, but with only the first 3 populated, were
found, and subsequent data records had 19 fields usually,
but some had only 15 fields, but all of the data records
had only 3 fields populated. The old algorithm deleted
those short data records, but now, if the last non-blank
field locations match, the data record can be decoded and
is now output eliminating COUNTERS ARE DIFFERENT messages
(unless the counts really are different).
-The BBBP record still has to be INPUT rather than scanned
because I couldn't find how to SCAN a comma-delimited
field with double-quotes around embedded comma(s)!
-The COUNTW(FIELD,','); function does NOT correctly count
fields with repeated commas, and it took two invocations
of TRANWRD(WORD,',,',',') to separate all of the commas
to get the correct count of fields.
-The AAA Record DATE value was expected to be a 4-digit
YYYY value, so records with only YY (non-Y2K compliant!)
caused INVALID ARGUMENT TO FUNCTON error message. MXG
now protects NMON for YY in the date field, and the
MONTH argument was protected with an UPCASE() function.
Thanks to Arthur Sy, Depository Trust, USA.
Change 27.079 The Elapsed Time variable in the ORACLE dataset was still
VMACORAC missing; Change 26.099 was apparently lost. Now,
Apr 27, 2009 ELAPSTM=SMFTIME-STARTTS;
Thanks to Bret Hoesly, Telephone and Data Systems, USA.
Change 27.078 Support for IMS Log Record 45X IMS Interval Statistics
ASMIMSL6 creates 24 new datasets from its 22 subtypes:
TYPEIMSA dddddd Dataset Description
TYPSIMFL IMS450 IMS4500 IMS 4500 BEGIN STATISTICS'
TYPSIMS7 IMS452 IMS4502 IMS 4502 QUEUE POOL STATISTIC'
VMACIMS IMS453 IMS4503 IMS 4503 FORMAT BUFFER POOL S'
VMACIMSA IMS454 IMS4504 IMS 4504 DATABASE BUFFER POOL'
VMXGINIT IMS455 IMS4505 IMS 4505 VARIABLE POOL STATIS'
May 4, 2009 IMS456 IMS4506 IMS 4506 SCHEDULING STATISTIC'
IMS457 IMS4507 IMS 4507 LOGGER STATISTICS'
IMS458 IMS4508 IMS 4508 VSAM SUBPOOL STATIST'
IMS459 IMS4509 IMS 4509 PI STATISTICS'
IMS45A IMS450A IMS 450A LATCH STATISTICS'
IMS45C IMS450C IMS 450C CBT STATISTICS'
IMS45D IMS450D IMS 450D RECEIVE ANY BUFFER P'
IMS45E IMS450E IMS 450F FIXED POOL STATISTIC'
IMS45F IMS450F IMS 450F DISPATCHER STATISTIC'
IMS45O IMS450O IMS 450F DISPATCHER TCB STATISTIC'
IMS45P IMS450P IMS 450F DISPATCHER SAP STATISTIC'
IMS45G IMS4510 IMS 4510 RCFT STATISTICS'
IMS45H IMS4511 IMS 4511 STORAGE STATISTICS'
IMS45I IMS4512 IMS 4512 IMODULE STATISTICS'
IMS45J IMS4513 IMS 4513 MSC STATISTICS'
IMS45K IMS4514 IMS 4514 EWLM STATISTICS'
IMS45L IMS4521 IMS 4521 IRLM USERT STATISTIC'
IMS45M IMS4522 IMS 4522 IRLM SYSTEM STATISTI'
IMS45N IMS45FF IMS 45FF END STATISTICS'
The IMS Interval Statistics contain many accumulated
variables, which are deaccululated in the _SIMS45X macro,
which has been added to TYPSIMS7 ("old" log records only)
and to TYPSIMFL (processes IMF/CIMS and the IMS records),
and to TYPEIMSA (part of JCLIMSL6 IMS Log Processing),
but only those variables that were non-zero in my small
test file have been validated. You can use _MEANDBG
after your include of either TYPSxxxx member to run a
PROC MEANS against all of the statistics datasets, and
look for a negative MINIMUM value to identify fields that
are being deaccumulated that should not be.
-TYPSIMFL has been updated with comments and sample JCL to
select only the 0F9x, 0FAx, and 45x log records and to
write the four IMF datasets to separate DDs, writing all
of the new statistics data to the default //PDB DDname.
-ASMIMSL6 (for the JCLIMSL6 MXG IMS Log Processing, used
only if you do NOT have IMF or another IMS monitor) is
updated to also select the 45x records; since they are
interval records, their volume should always be small.
-Note that the default output destination of these new
IMS45xx datasets is the //WORK ddname, just like the
Fastpath and CPIC datasets. You can use
%INCLUDE SOURCLIB(TYPEIMSx);
PROC COPY IN=WORK OUT=whatever MT=DATA;
SELECT IMS45: ;
to copy these new (low volume) datasets to whatever
DD/LIBNAME you want, or you can override individual
datasets with %LET PIMS45z=whatever; before the %INCLUDE.
Note the Pdddddd macro token must be used because of the
de-accumulation that is required.
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 27.077 BVIR variable GLIBSEQN was documented as EBCDIC and early
VMACBVIR test data had '00'X values, but new data with ASCII data
Apr 27, 2009 is found, so MXG logic now tests for '00'x, or for EBCDIC
hex values ('81'x-'A9'x,'C1'x-'E9'x,'F0'x-'F1'x) or falls
thru for ASCII to input GLIBSEQN in the correct format.
Thanks to Rob D'Andrea, Royal Bank of Scotland, SCOTLAND.
Thanks to Penny Dudgeon, Royal Bank of Scotland, SCOTLAND.
Change 27.076 Significant enhancements to ASUM70PR summarization of
VMAC7072 TYPE70PR adds support for HiperDispatch by subtracting
VMXG70PR Parked Time SMF70PAT from both Online Time SMF70ONT and
Apr 30, 2009 from Wait Time SMF70WST, AND adds new IFA, IFL, and ZIP
variables to each LPAR to fully support those Specialty
engines (especially IFLs which were not captured in the
previous ASUM70PR implementation), captures the PHYSICAL
LPAR time for each type of Specialty Engine, and adds it
into the CPUIFATM, CPUIFLTM, CPUZIPTM totals in Interval
datasets, calculates the Average Number of Online Engines
for CPs, IFAs, IFLs, and ZIPs, provides counts of the
number of Installed Engines of each type, cleaned up the
inconsistencies in the variable's names and contents,
and documents what variables contain what, below!
It has always been my recommendation that the datasets
created by ASUM70PR should be used for LPAR analysis,
since it avoids you having to understand the complexity
of the raw TYPE70PR dataset; with this enhancement, all
of the information is summarized, and you have four ways
of analysis with the four output datasets created.
-ASUM70PR is enhanced with new variables for IFL LPARs and
consistent contents in the CPUxxxTM total variables, and
the HiperDispatch Parked Time SMF70PAT and Wait SMF70WST
are kept for each LPAR in all four datasets. If SMF70PAT
is non-zero, i.e., engines were parked, the SMF70ONT LPAR
Online Up Time, and the LPAR Wait Time SMF70WST are each
reduced by the Parked Time.
-The datasets ASUM70LP and ASUMCELP contain an observation
for each LPARNAME, with a single set of variable names
for each INTERVAL (that you set in your ASUM70PR member).
-ASUM70LP is created per SYSTEM, with each system's view
of the resources consumed by ALL of the LPARs seen by
that SYSTEM, so there will be replicated/repeated data
for each LPARNAME when you process SMF/RMF data from
multiple systems.
-ASUMCELP is created per CECSER with a single observation
for each LPARNAME for each INTERVAL.
In both of the per-LPARNAME datasets, ASUM70LP/ASUMCELP,
IFL LPARs are measured in these new variable names:
NRIFLCPU='INSTALLED*IFL*ENGINES'
IFLACTTM='IFL*PROCESSORS*CPU*ACTIVE*TIME'
PCTIFLBY='IFL*PERCENT*CPU*BUSY'
IFLCPUS ='IFL*AVERAGE*ONLINE*CPU COUNT'
IFLUPTM ='IFL*PROCESSORS*UP*TIME'
IFLPATTM='IFL*PARKED*PAT*TIME'
IFLWSTTM='IFL*PROCESSORS*WST*TIME'
As these datasets are per-LPARNAME their CPU active time
in variables IFAACTTM, IFLACTTM, and ZIPACTTM, do not
contain the Physical Engine CPU times.
-The datasets ASUM70PR and ASUMCEC contain an observation
for each interval, with a set of variables for the totals
and 60 separate sets of LPnAAAAA variables with resource
usage for each LPARNAME.
-ASUM70PR is created per SYSTEM, with each system's view
of the resources consumed by ALL of the LPARs seen by
that SYSTEM, so it, too, will have replicated/repeated
data when you process data from multiple systems.
-ASUMCEC is created per CECSER with a single observation
for each INTERVAL.
Since ASUM70PR/ASUMCEC are interval summaries across ALL
LPARs, the total-CPU-time variables now consistently
include the Physical LPAR CPU time; previously, only the
CPUACTTM for CP engines included the Physical time.
And the Physical CPU time for each engine type are now
available in ICFPHYTM, IFAPHYTM, IFLPHYTM, and ZIPPHYTM.
Those 60 sets of per-LPAR LPnAAAAA variables have these
new variables for each LPAR's IFA, IFL and ZIP usage:
LPnIFATM='LPAR n*IFA*DISPATCH*TIME'
LPnIFUTM='LPAR n*IFA*UP*TIME'
LPnIFKTM='LPAR n*IFA*PARKED*TIME'
LPnIFWTM='LPAR n*IFA*WST*TIME'
LPnILATM='LPAR n*IFL*DISPATCH*TIME'
LPnILUTM='LPAR n*IFL*UP*TIME'
LPnILKTM='LPAR n*IFL*PARKED*TIME'
LPnILWTM='LPAR n*IFL*WST*TIME'
LP1ZIPTM='LPAR n*ZIP*DISPATCH*TIME'
LP1ZIUTM='LPAR n*ZIP*UP*TIME'
LP1ZIKTM='LPAR n*ZIP*PARKED*TIME'
LP1ZIWTM='LPAR n*ZIP*WST*TIME'
-If you have IFLs, many "Missing Values" messages will be
printed on the SAS log, but they are harmless; IFL LPARs
have missing values for all of the old CP variables.
ASUM70LP/ASUMCELP - Per-LPARNAME Variables
============ Engine Type =============
CP IFA IFL ZIP ICF
Metric:
Installed Engines PARTNCPU NRIFACPU NRIFLCPU NRZIPCPU NRICFCPU
Avg Online Engines LPARCPUS IFACPUS IFLCPUS ZIPCPUS
CPU Busy Time LCPUPDTM IFAACTTM IFLACTTM ZIPACTTM
Percent CPU Busy PCTLPBY PCTIFABY PCTIFLBY PCTZIPBY
Online Total Time LPARDUR IFAUPTM IFLUPTM ZIPUPTM
Parked Time SMF70PAT IFAPATTM IFLPATTM ZIKPATTM
Wait State Time SMF70WST IFAWSTTM IFLWSTTM ZIPWSTTM
ASUM70LP Sorted BY list:
SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER LPARNAME LPARNUM
ASUMCELP Sorted BY list:
CECSER STARTIME SHIFT LPARNAME LPARNUM
ASUM70PR/ASUMCEC - Per-Interval Variables
============ Engine Type =============
CP IFA IFL ZIP ICF
Metric:
Installed Engines PARTNCPU NRIFACPU NRIFLCPU NRZIPCPU NRICFCPU
Avg Online Engines LPARCPUS IFACPUS IFLCPUS ZIPCPUS
CPU Busy Time CPUACTTM CPUIFATM CPUIFLTM CPUZIPTM
Percent CPU Busy PCTLPBY PCTIFABY PCTIFLBY PCTZIPBY
Online Total Time LPARDUR IFAUPTM IFLUPTM ZIPUPTM
Parked Time SMF70PAT IFAPATTM IFLPATTM ZIKPATTM
Wait State Time SMF70WST IFAWSTTM IFLWSTTM ZIPWSTTM
ASUM70PR Sorted BY list:
SYSPLEX SYSTEM &MXGSYSN STARTIME SHIFT CECSER;
ASUMCEC Sorted BY list:
CECSER STARTIME SHIFT;
-PDB.TYPE70PR dataset was also enhanced with the counts
and CPU Active time for all four specialty engines for
each LCPUADDR, with these new or updated variables:
NRICFCPU NRIFACPU NRIFLCPU NRZIPCPU total engines
ICFACTTM IFAACTTM IFLACTTM ZIPACTTM CPU this LCPUADDR
-Validation notes. Using PROC COMPARE can often identify
differences, but comparing across this change can cause
lots of "false positives", especially in the count of the
Specialty Engine NRIFACPU,NRZIPCPU,NRICFCPU,NRIFLCPU as
they sometimes wrong or always missing in prior PDBs.
Small changes are expected in the CPUxxxTM for Specialty
Engines because their PHYxxxTM is now included.
And the xxxUPTM "Uptime" variables are now differently
calculated, as the actual Online Time, rather than the
old values of NRxxxCPU*DURATM.
Thanks to Robert Hamilton, Fifth Third Bank, USA.
Thanks to Zhan Wang, AIG, USA.
Change 27.075 Cosmetic. For Offline LPARS (LPARCPUX=0) these variables
VMAC7072 in PDB.TYPE70PR: LCPUADDR SMF70CIX SMF70ONT NRCIXGT0
Apr 23, 2009 could have non-missing values. Now, all are set missing.
Unchanged, but noted: SMF70CIN is blank when LPARCPUX=0.
Change 27.074 Group Capacity datasets ASUM70GC & ASUM70GL were wrong if
VMXG70PR multiple SYSTEMs data was in TYPE70PR; each SYSTEM has an
Apr 23, 2009 observation with repeated data for each LPARNAME that was
being summed for each Group Name. This change selects a
single system per interval for the revised summation.
It has been observed in the data and in IBM RMF reports
that actual Group MSU used, LPARMSU, can exceed SMF70GMU,
the Maximum License Units of the Group, causing PCTGCUSE,
the Percent of Group Capacity Used, to exceed 100%.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.073 Variable EVENTIME in data set TSMACCT was wrong; the YYYY
VMACTSMA INPUT function was revised to use informat 4.
Apr 22, 2009 YYYY=INPUT(SUBSTR(DATECH,7,4),4.);
Thanks to Craig Collins, State of Wisconsin DOA, DET, USA.
Change 27.072 Updates for VTCS subtypes of the STC/STK User SMF record.
FORMATS -Format $MGSTCCT adds 2000MB and 4000MB values.
VMACSTC -Format $MGSTCMN adds MOUNT ANSI SCRATCH VTV value.
Apr 22, 2009 -Dataset STCVSM18 variables STC18CTP and STC18MT were not
input for the longer length segment, STC18CTP was not
kept, and all three CTP variables are now length $2 and
correctly formatted.
-Formats $MGSTCMN and $MGSTCCT were updated with new
values for 2000MB and 4000MB cartridges, and for
ANSI Label Mounts, respectively.
Thanks to Davide Marone, SGS S.p.a. ITALY
Thanks to Carlo Gavinelli, SGS S.p.a. ITALY
Thanks to Gianvittorio Negri, SAS Institute, ITALY.
Change 27.071 -Major enhancement: all MXG-provided VMXGSUM-using summary
ANAL88 programs (e.g. ASUMs, ANALs, TRNDs) will NOT fail if your
ANALAVAI input data has DROPed variables, if you simply specify
ANALCACH %LET KEEPALL=NO;
ANALCISH in your //SYSIN. KEEPALL=NO causes VMXGSUM to determine
ANALCNCR what output variables are needed, and thereby prevents
ANALHTML the VARIABLE NOT FOUND condition when you have DROPed
ANALPKGS variables to reduce the size of your PDB dataset, which
ANALPROG is what happens with the default of KEEPALL=YES.
ANALSTC
ANALUSS The default is KEEPALL=YES, because the KEEPALL=NO logic
ASUM23 would be expensive if applied to the hundreds of VMXGSUM
ASUM42DS invocations that are internal to MXG processing, but its
ASUM94 cost is insignificant for a single execution, and it is
ASUMCACH ONLY needed when you know you have DROPed variables.
ASUMCICS
ASUMCICT -All of the summary programs listed in this change now
ASUMCICX specify KEEPALL=&KEEPALL, in their %VMXGSUM invocation.
ASUMCIMS -And where needed, a KEEPIN= was added, but KEEPIN does
ASUMDB2A not get used unless KEEPALL=NO is in effect, so there is
ASUMDB2B no adverse effect of the KEEPIN= protection.
ASUMDB2G -VMXGINIT sets KEEPALL=YES as the GLOBALed default value.
ASUMDB2P The old default NO was used only in TRNDRMFI, which now
ASUMFRYE has KEEPALL=NO explicitly in its %VMXSGUM statement.
ASUMJOBS -VMXGSUM now has KEEPALL=&MXGKEEP in its definition, in
ASUMMIPS place of a hard-coded KEEPALL=YES, and MXGKEEP=YES is set
ASUMNTIN in VMXGINIT. This value is only used when the %VMXGSUM
ASUMSMFI invocation did not specify a KEEPALL value, and this is a
ASUMTMNT "just in case" option, to use MXGKEEP, that I doubt will
ASUMV11 be needed, but is nice to have for testing.
ASUMV14
ASUMVMON So, how expensive is KEEPALL=NO for my QA stream?
ASUMVTVM
ASUMVMNT The QA tests with all INFILEs reading zero length files
BLDNTPDB invokes VMXGSUM 442 times with these comparisons
BUIL3005
BUILD005 KEEPALL YES NO
BUILD006 DATA Steps 3567 4924
CICSSTAT PROC Steps 11564 13454
DAILYDSR Elapsed mmss 11:44 30:14
DALYTAPE CPU mmss 6:28 20:31
GRAFWLM
MNTHDB2S However, the CPU increase of 900 seconds with KEEPALL=NO,
SPUNJOBS for a total of 442 invocations, is only 2 seconds for a
TRNDDB2P single execution, well worth that cost to permit you to
TRND23 use the summary program with reduced input.
TRND70
TRND70SH
TRND94
TRNDCACH
TRNDCEC
TRNDDB2A
TRNDDB2B
TRNDDB2G
TRNDDB2S
TRNDDB2X
TRNDNTIN
TRNDNTLD
TRNDRMFI
TRNDTALO
USMFRATE
UTILCONT
UTILRMFI
VMXGCAPT
VMXGCICI
VMXGINIT
VMXGRESP
VMXGRMFI
VMXGSUM
VMXGTPFI
WEEKCEC
Apr 20, 2009
Change 27.070 Variable DESCR existed in 4 different XAM datasets, with
VMACXAM 3 different lengths, with only the first 12 bytes in
Apr 16, 2009 XMHSTMEM dataset, where the field is split into 2 pieces.
Variable DESCR is now $16 in both XMTIFTB and XMHSTMEM
datasets, the extra four bytes are appended in XMHSTMEM,
it is renamed DESCRDSK with length $40 in XMHSTDSK, and
it is renamed DESCRTCP with length $128 in XMTCPSYS.
Thanks to Roger Stock, Boston University, USA.
Change 27.069 Serena's Ultimizer user SMF record moved subtype 2 and 3
VMACULTM into the left byte of the two-byte subtype field, and in
Apr 15, 2009 the right byte for subtype 1 records, which was not the
expected location of subtype, but now is supported. The
DSECT for R310 does not document this design. And the
READTIME field is always missing (hex zeros) in the 2/3
records but is populated in the subtype 1 VSAM record.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 27.068 Optional CICSTRAN USERCHAR field was limited to 200 bytes
IMACICDU due to that ancient SAS V6 limit on character variables.
Apr 15, 2009 That field can now be up to 32000 bytes. The IMACICDU
member is an internal member that would not normally have
been tailored by users.
Thanks to Henrik Lange, Nordic Processor, NORWAY.
Change 27.067 Support for LDAP Auditing ID=83 Subtype=3 SMF record.:
EXTY83LD New dataset created:
FORMATS
IMAC83 dddddd Dataset Description
VMAC83 TY83LD TYPE83LD TY83LD: LDAP AUDITING
VMXGINIT
Apr 13, 2009
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
====== Changes thru 27.066 were in MXG 27.02 dated Apr 13, 2009=========
Change 27.066 The "owner" variables in TYPE77 were labeled as "CURRENT"
VMAC77 but they are actually the owners/system/etc at the time
Apr 13, 2009 of maximum contention. The revised labels now are:
CURROWN ='NUMBER OF*OWNERS*WHEN AT*MAX CONTENTION'
CURRWAIT='NUMBER OF*WAITERS*WHEN AT*MAX CONTENTION'
JOBOWN1 ='NAME OF*OWNER#1*WHEN AT*MAX CONTENTION'
JOBOWN2 ='NAME OF*OWNER#2*WHEN AT*MAX CONTENTION'
JOBWANT1='NAME OF*WANTER#1*WHEN AT*MAX CONTENTION'
JOBWANT2='NAME OF*WANTER#2*WHEN AT*MAX CONTENTION'
SYSOWN1 ='SYSTEM OF*OWNER#1*WHEN AT*MAX CONTENTION'
SYSOWN2 ='SYSTEM OF*OWNER#2*WHEN AT*MAX CONTENTION'
SYSWANT1='SYSTEM OF*WANTER#1*WHEN*MAX CONTENTION'
SYSWANT2='SYSTEM OF*WANTER#2*WHEN*MAX CONTENTION'
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 27.065 Cosmetic, to eliminate MXGWARN messages from VMXGOPTR.
BUILD001 Change 27.051 corrected VMXGOPTR so the current value of
BUILD005 an option would be used, but invocations of VMXGSUM could
BUIL3001 unexpectedly modify the option; this change pairs each of
BUIL3005 the VMXGOPTR to reset (VALUE=ORIGINAL) prior to VMXGSUMs.
SPUNJOBS Without this change, the (usually) harmless message
Apr 12, 2009 MXGWARN: STORED VALUE OF DKROCOND IS MXG;
could have been printed on the SAS log.
Change 27.064 SYSLDSN from the IEC501I message could be a number rather
VMACTMNT than a DSNAME; the WORDS array did not parse correctly if
Apr 11, 2009 there were adjacent commas for un-populated fields in the
SYSLOG message text. The TRANWRD(x,',,',', ,') function
was used to insert a blank between adjacent commas, once
I found that TRANWRD and TRANSLATE functions are quite
inconsistent, with their syntax reversed:
TRANSLATE(argument,to,from);
TRANWRD (argument,from,to);
Thanks to MP Welch, SPRINT, USA.
Change 27.063 Decoding SYSLOG MSGID=IEC205I in TMNT Subtype 8 record
VMACTMNT adds variables STEPNAME SYSLBLKS SYSLENCR to TYPESYMT
Apr 11, 2009 dataset to identify Encrypted Tapes; SYSENCR will have
the text KL1CD:L,LK2CD:L for encrypted tapes (where
H:='HASH' or L:LABEL'). The ASMTAPEE monitor program
will be updated later to write IEC205I in TMNT Subtype 8
record, and a later update to ASUMTAPE will be needed to
complete this enhancement.
Thanks to Bruce Gillespie, First American Reinsurance, USA.
Change 27.062 -TYPE42 Updates for VSAM RLS "ABOVE THE BAR" statistics,
EXTY42D3 added by IBM long ago but overlooked by MXG, adds six new
EXTY42D4 datasets and re-labels the six existing "BELOW THE BAR":
EXTY42S3 TY42S1 TYPE42S1 VSAMRLS SPLEX SC BELOW THE BAR
EXTY42S4 TY42S2 TYPE42S2 VSAMRLS SC CF SYS BELOW THE BAR
EXTY42X3 TY42S3 TYPE42S3 VSAMRLS SPLEX SC ABOVE THE BAR
EXTY42X4 TY42S4 TYPE42S4 VSAMRLS SC CF SYS ABOVE THE BAR
IMAC42 TY42D1 TYPE42D1 VSAMRLS SPLEX DATASET BELOW BAR
VMAC42 TY42D2 TYPE42D2 VSAMRLS DATASET CF SYS BELOW BAR
VMXGINIT TY42D3 TYPE42D3 VSAMRLS SPLEX DATASET ABOVE BAR
Apr 9, 2009 TY42D4 TYPE42D4 VSAMRLS DATASET CF SYS ABOVE BAR
TY42X1 TYPE42X1 VSAMRLS BUFF MGR TOTALS BELOW BAR
TY42X2 TYPE42X2 VSAMRLS BUFF MGR DETAILS BELOW BAR
TY42X3 TYPE42X3 VSAMRLS BUFF MGR TOTALS ABOVE BAR
TY42X4 TYPE42X4 VSAMRLS BUFF MGR DETAILS ABOVE BAR
-APAR OA25559 adds two new variables S42DSRDD,S42DSRDT to
subtype 5 and subtype 6 records, and these variables are
are kept in TYPE42DS, TYPE42SR, and TYPE42VT datasets:
S42DSRDD='AVERAGE*READ MS*DISCONNECT*TIME'
S42DSRDT='READ*OPERATIONS*TO*DATASET'
Change 27.061 MXG 27.01 only. A DEBUGging PUT statement at line 235
VMAC88 PUT _N_= SUBTYPE= SMFTIME= SMF88LTD= SMF88LIT= GMT88OFF=;
Apr 8, 2009 is now deleted by this change.
Thanks to Michael Creech, Lender Processing Services, Inc, USA.
Change 27.060 Cosmetic. Labels for TYPE23 BUFSZMAX and WRNSZMAX said
VMAC23 "PERCENT", but BUFSZMAX has always been the MAX VALUE.
Apr 8, 2009 WRNSZMAX was the Warning PERCENT thru z/OS 1.5, but in
z/OS 1.6 the description was changed to "VALUE", but it
was NOT documented in the changes in the 1.6 SMF Manual.
Now, both labels say VALUE rather than PERCENT.
Thanks to Chuck Hopf, Bank of America, USA.
Change 27.059 SMF 102 IFCID=108 variables starting at QW0108PR were not
VMAC102 input because QWT02R1N, instead of QWT02R1L (length) was
Apr 6, 2009 tested for GE 160. Additionally, these new variables are
now input and kept in T102S018 dataset:
QW0108DY QW0108DP QW0108RO QW0108KD QW0108OH QW0108IW
QW0108SC QW0108CC
Thanks to Tony Anderson, Blue Cross Blue Shield of Alabama, USA.
Change 27.058 Change 27.015 enhanced VMACSMF to test IF SUBTYPE GT 255
VMACSMF because some user SMF records store their subtype in the
Apr 6, 2009 left byte of the two byte field. MXG printed an ERROR
message, and used the left byte as the subtype number,
but this ERROR message was not documented in that text.
I also failed to protect the optional BMC CICS Statistics
SMF 110 records that are written as subtype=2818 or 47874
('BB02'x,'0B02'x) are really subtype=2 STID=200 to 205.
IF you had enabled the optional IMACICBB member to decode
these optional STID's, then their CICSBBxx datasets would
have had no observations, plus the new MXG ERROR message.
Thanks to Lorena Ortenzi, UniCredit Global Info Services, ITALY.
Change 27.057 MXG 27.01. DCOLLECT DCOLVOLS the volume size variables
VMACDCOL DCVALLOC DCVFRESP DCVLGEXT DCVVLCAP are small by 1024.
Apr 3, 2009 Change 27.034 for EAV support mislocated the code that
multiplies the KB value by 1024 so it was ONLY executed
if the record is the longer, EAV-updated, volume record.
Thanks to Frank Lund, EDB, NORWAY.
Thanks to Chris A. Hughes, University of Georgia, USA.
Change 27.056 Support for Control-D "Decollating" SMF record, which is
EXTYCTCD a new, different SMF record than the Control-D TYPECTLD
IMACCTCD support. This new record creates dataset CONTROCD.
TYPECTCD
TYPSCTCD
VMACCTCD
VMXGINIT
Apr 2, 2009
Thanks to Davide Marone, SGS S.p.a. ITALY
Thanks to Carlo Gavinelli, SGS S.p.a. ITALY
Thanks to Gianvittorio Negri, SAS Institute, ITALY.
Change 27.055 OBJECTSTAR (a/k/a HURON) INPUT STATEMENT EXCEEDED RECORD
VMACHURN ERROR for short Subtype 13 record; record should have
Apr 2, 2009 3123 bytes for 26 segments, but LENGTH is only 3110.
MXG prints message and hex dump of first 3 instances.
Thanks to David Stone, TESCO, ENGLAND.
Change 27.054 MXG 27.01 ONLY, CRITICAL ERROR FOR SMF 42 SubTypes 1-20.
VMAC42 I really botched this one. A partial statement was left
Mar 31, 2009 (IF SUBTYPE GT 20 THEN) ahead of IF OFFPROD GT 0 THEN DO,
preventing INPUT of STARTIME, ENDTIME & DURATM variables
for these datasets that are created from subtypes 1-20:
TYPE4220 TYPE4237 TYPE42AD TYPE42AU TYPE42CC TYPE42CU
TYPE42CV TYPE42D1 TYPE42D2 TYPE42DS TYPE42EX TYPE42L1
TYPE42L2 TYPE42NF TYPE42NU TYPE42P1 TYPE42P2 TYPE42P3
TYPE42S1 TYPE42S2 TYPE42SC TYPE42SR TYPE42TO TYPE42VL
TYPE42VS TYPE42VT TYPE42X1 TYPE42X2 TYPE42XR TYPE42XV
Not only are STARTIME, ENDTIME, and DURATM missing values
but also variables that are calculated from DURATM, such
as, in TYPE42DS, CACHRATE, DASDMPL, and DASDRATE also are
missing values.
Thanks to Paul Volpi, UHC, USA.
Change 27.053 -CICS Statistics STID=108 in CICS/TS 3.2 added 48 bytes as
FORMATS part of the 284 bytes INPUT in MXG 27.01 for CICS/TS 4.1.
UTILEXCL Now, the first 48 are INPUT then the other 236 are INPUT.
VMAC110 STID=108 DFHSORTS data is output in dataset CICTCPIP.
Mar 31, 2009 -CICS Statistics STID=31 inconsistent length/LDBNRDSN was
Apr 1, 2009 only partially circumvented in Change 26.052, as it used
Apr 2, 2009 re-calculated LDRNSKIP=(STILEN-104)/44 for segment count
APR 4, 2009 only if LDRNSKIP was GT LDBNRDSN, causing the prior count
to be used when LDRNSKIP=LDBNRDSN. Since it is now clear
that LDBNRDSN is the number of POPULATED segments, but is
NOT the number of segments, LDRNSKIP=(STILEN-104)/44 is
always used to control the number of segments read in.
Existing test for LDBDSNAM GT ' ' causes only populated
segments to be output in the CICLDBDS statists dataset.
-In CICSTRAN dataset, back in 1994, Change 12.166 noted
that TASKNR (IBM TRANNUM) is not always a packed decimal,
and can contain four-character-in-EBCDIC values:
bytes old TASKNR description
1st 2-4 (decimal)
'00'X,'III' 13,224,393 SYSTEM INITIALIZATION TASK
'00'X,'J00' 13,758,704 JOUR CONTROL, JOURNAL=00
'00'X,'J99' 13,761,017 JOUR CONTROL, JOURNAL=99
'00'X,'JBS' 13,746,914 JOURNAL CONTROL
'40'X,'TCP' 14,926,807 TERMINAL CONTROL
but that change only stored the right 3-bytes as a large
decimal value when a character value was found, without
decoding or mapping that strange TASKNR value. And, that
change was not implemented in UTILEXCL logic, causing the
TASKNR to be a missing value for these character values
when IMACEXCL built by UTILEXCL was used. Now, if TASKNR
is not a valid packed decimal value, the full four-byte
field is input as binary, and TASKNR is FORMATed with new
MG110TN format that decodes those binary values to print
the actual 'III', 'Jnn', 'JBX', or 'TCP' text value,
right justified to align with numeric values of TASKNR.
And UTILEXCL was updated with this revised logic.
Because TASKNR is the only packed decimal field in the
CICSTRAN segment the "vanilla" VMAC110 tested IF TASKNR=.
to detect misalignment (that is how MXG finds EXCLUDEd
fields or optional data segments), but with this change,
TASKNR can never be a missing value, so the new test is
IF TASKNR EQ 0 OR
(TASKNR GT 99999 AND COMPRESS(PUT(TASKNR,MG110TN.))
NOT IN : ('III','TCP','JBS','J') ) THEN DO;
The original test for TASKNR=. could not be used when the
IMACEXCL was in use, since the site might have EXCLUDEd
the TASKNR field, but since this test is now valid even
if TASKNR is excluded, this misalignment test was moved
so it is always applied, even when IMACEXCL is used.
Thanks to Paul Volpi, UHC, USA.
Thanks to Jon Keister, Caremark, USA.
Change 27.052 Updates to PMACC01 DB2PM-like report had a number of
ANALDB2R blank values introduced in MXG 26.26, which also changed
Mar 28, 2009 the format of some durations (Class 7 for example) to
match the DB2PM printed time format.
Thanks to Paul Billick, QVC Inc, USA.
Change 27.051 -%VMXGOPTR is used internally in MXG to alter the user's
VMXGOPTR options, which are then reset to their original value.
VMXGSUM For example, in VMXGSUM, we must have OBS=MAX for the
Mar 27, 2009 internal parsing DATA steps, so we store your OBS value,
Apr 2, 2009 change it to OBS=MAX for our purpose, and then restore
Apr 13, 2009 your ORIGINAL option value. But if %VMXGOPTR was then
Apr 29, 2009 invoked a second time for that same option, we used your
ORIGINAL value instead of your CURRENT value. Now, each
time %VMXGOPTR is invoked with NEWVALUE not ORIGINAL, we
store the current value of that option, so that when the
resetting %VMXGOPTR invocation with ORIGINAL, we then can
reset that option to the LAST stored value.
-After ORIGINAL has been reset, the text "MXG" is stored.
If a subsequent ORIGINAL invocation finds that "MXG", a
"MXGWARN STORED VALUE FOR xxxxxx IS MXG" prints to alert
you that you have un-paired %VMXGOPTR invocations. This
might not be a problem, depending on your intended use of
%VMXGOPTR.
-VMXGSUM required change because it did not have matched
pairs of %VMXGOPTR invocations.
-It is VERY unlikely any MXG users have actually used the
%VMXGOPTR macro, and even less likely that anyone used
that retained value of the original %VMXGOPTR design,
but, technically, this is an UNCOMPATIBLE change.
-Note that if you should use %VMXGOPTR, that you need to
use it exclusively to change options; if you interleave
%VMXGOPTR and OPTIONS statements, your results might be
unexpected.
This change was precipitated by a simple user program:
OPTIONS OBS=0;
%INCLUDE SOURCLIB(TYPEDB2);
RUN;
OPTIONS OBS=MAX;
%INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);
that causes ASUMCICX to fail, because the internal
%VMXGOPTR in VMXGSUM reset the option OBS=0, which was
the last value it stored, and so PDB.CICS built by the
ASUMCICX had 0 OBS.
Thanks to Paul Volpi, UHC, USA.
Change 27.050 Support for LPAR NMON data for RAWLPAR and RAWCPUTOTAL
EXNMONRC objects create two new datasets:
EXNMONRL DDDDDD DATASET DESCRIPTION
IMACNMON NMONRC NMONRAWC NMON RAW CPU
VMACNMON NMONRL NMONRAWL NMON RAW LPAR
VMXGINIT
Apr 13, 2009
Thanks to Peter Turner, Saint George Bank, AUSTRALIA.
Change 27.049 %VGETSYSI for z/OS only, returns global macro variables
VGETSYSI MXGSYSID and MXGSUSEC which contain the SYSTEM on which
Mar 26, 2009 SAS is executing, and the SU_SEC value for that system.
Thanks to Chuck Hopf, Bank of America, USA.
Change 27.048 Variable TAPEDRVS in PDB.ASUMTALO is the cross product of
ASUMTALO allocated tape drives times their duration, so it can be
TRNDTALO a large and confusing number. New variable AVGDRIVE is
Mar 26, 2009 now added to PDB.ASUMTALO with the average number of tape
drives that are allocated. TRNDTALO was also updated with
the new variable.
Thanks to Graham Cornwell, DDS, UK.
Thanks to Craig Heron, DDS, UK.
Change 27.047 -MXG 27.01 only. The EAV support added in Change 27.034
VMACDCOL was misaligned, i.e., it was incorrect. This change has
Mar 25, 2009 now been validated with an EAV volume's DCOLLECT record.
-The above error also mis-located the previous tests for
DCVFLAG1 and DCVERROR, causing all of the flag variables
created from them to be blank.
Only the DCOLVOLS dataset was in error in 27.01.
But see also Change 27.057.
Thanks to Dr. H. Pat Artis, Performance Associated, USA.
Thanks to Brian Currah, Independent Consultant, CANADA.
Thanks to Dan Case, Mayo Clinic, USA.
Change 27.046 Major updates to D,V,X records created by EDGHSKP utility
VMACEDGR add new variables to EDGRDEXT, EDGRVEXT, and EDGRXEXT
Mar 25, 2009 dataset. These extensive changes have been validated
Apr 2, 2009 with z/OS 1.7, 1.8, 1.9, and 1.10 RMM records.
Apr 4, 2009 -The RMM EDGRDEXT final segment test for GE 95 should have
been GE 31. RVMVDSN1,RVDSTBIN,RVDSTMED,RVVVOL1 do not
exist in the DEXT record; these fields were added in 2003
in Change 21.158, but I must have misread the doc!
Also, the RDEXPDT and RDEXPDTO date fields were not
converted to SAS date values.
-Support for APAR OA22132 adds variables to D/V/X records:
RDFACTOR='SPACE/SIZE*FACTOR' (MB in EBCDIC)
RDSIZE ='RDSIZE'
Variable RDSIZE is converted by RDFACTOR and formatted
with MGBYTES to show size in KB/MB/GB/ etc Note that
RDSIZE will be a missing value when that 10-byte field
is blanks, which does occur in many (old?) records.
Thanks to Paul Volpi, UHC, USA.
Change 27.045 -These QISTWFxx variables in DB2STATS were wrong because
VMACDB2 MXG de-accumulated them, but are not accumulated values:
Mar 20, 2009 QISTW04K QISTW32K QISTWF04 QISTWF32 QISTWFCK QISTWFCU
Mar 24, 2009 QISTWFMU QISTWFMX
Apr 11, 2009 -Variables QWACIXLT and QWAXIXLT were incorrectly divided
Apr 19, 2009 by 4096; they are in microseconds, not TOD clock units.
-Variables QSSTGETR, QWSDARIR, Q9STCTX1 were deaccumulated
twice, QSSTGETE was not deaccumulated.
-Dataset DB2STATS variables for Star Joins are marked in
the DSECT as "SERVICEABILITY", but are added
-Star Join statistics variables are added to DB2STATS:
QISJTRY ='ALLOCATION*REQUESTS IN*STAR JOIN*POOL'
QISJFAIL='FAILURES*CAUSED BY*FULL*STAR JOIN*POOL'
QISJSIZE='CURRENT*SIZE OF*STAR JOIN*POOL (MB)'
QISJMAX ='MAXIMUM*SIZE OF*STAR JOIN*POOL (MB)'
They are marked "SERVICEABILITY" in the current DSECT.
Thanks to Lori Masulis, Fidelity Systems, USA.
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Terry L. Berman, DST Systems, USA.
Thanks to Steve Wood, DST Systems, USA.
Change 27.044 Variable CPCFNAME was defined as $10 in VMXG70PR but it
VMXG70PR contains only $8, and its length in RMFINTRV is also $8.
Mar 20, 2009 Since RMFINTRV is created by default in BUILDPDB, I chose
to change the length in the ASUM70PR datasets to avoid
conflicts.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 27.043 -HP OpenView on AIX variables RELEASE, SOFTWARE, SYSID
ADOCMWAI were wrong or had no values with the current REPORT macro
ADOCMWSU (which is now in ADOCMWAI, so you can use that command to
VMACMWAI extract the data in the format expected by the revised
VMACMWSU VMACMWAI, and similarly, VMACMWSU/ADOCMWSU members are
Mar 18, 2009 updated for HP OpenView on Sun, with ADOCMWSU containing
Apr 10, 2009 the REPORT macro to match the VMACMWSU code.
Thanks to Albert Jacobs, KBC ICT Services NV, BELGIUM.
====== Changes thru 27.042 were in MXG 27.01 dated Mar 17, 2009=========
Change 27.042 Support for ASG TMON for CICS V3.2 was in MXG since 25.11
VMACTMO2 for important MONITASK dataset, and most other datasets,
Mar 17, 2009 although MONIIWT & MONITDQ datasets require this change,
as their offsets were relocated by insertion of the new
fields for the MONISYST and MONITDQ datasets.
-Dataset MONITASK, new variables:
TADFHAP1 TADFHAP2
-Dataset MONIPA, new variables:
PACMDLYC PACMDLYT PADFHAP1 PADFHAP2 PAICSCC
PAICSCD PAICSRC PAICSRD PAL9CPUC PAL9CPUT
PAPCDCC PAPCDLL PAPCDRL PAPCLCC PAPCRCC
PAPCRCL PAPCXCC PAPGBCC PAPGCCC PAPGCTC
PAPGGCC PAPGGCL PAPGMCC PAPGPCC PAPGPCL
PASTDLYC PASTDLYT PAWBBOC PAWBI1C PAWBIRC
PAWBIWC PAWBO1C PAWBOSC PAWBPRC PAWBRDL
PAWBROC PAWBWDL PAWBWOC PAX8CPUC PAX8CPUT
PAX9CPUC PAX9CPUT PAXTDLYC PAXTDLYT
-Dataset MONISYST, new variables:
TIMQSCLC TIMQSCLT TIMQSGTC TIMQSGTT TIMQSIQC
TIMQSIQT TIMQSOPC TIMQSOPT TIMQSP1C TIMQSP1T
TIMQSPTC TIMQSPTT TIMQSSTC TIMQSSTT TIRECICT
-Dataset MONITDQ, new variables:
TDRECICT
Change 27.041 The example to summarize PDB.SMFINTRV into PDB.ASUMSMFI
ASUMSMFI was enhanced to specify the SYNC59 argument, with the
Mar 17, 2009 default SYNC59=NO, so there would be no change to the
summarized output (until you change NO to YES!).
Thanks to Larry Stahl, IBM Global Services, USA.
Change 27.040 Dataset TYPE78PA (Private Area for Monitored Jobs) ID=78
VMAC78 Subtype 2 INPUT STATEMENT EXCEEDED RECORD LENGTH ERROR
Mar 17, 2009 was due to MXG miscoding the new-in-z/OS 1.10 Memory
Objects. COMOHWM,LGMOHWM,SHMOHWM,TOFRHWM,TOMOHWM vars
were INPUT but never existed and are removed. Labels for
their MIN and MAX values are changed to FRAMES instead of
BYTES, and their MGBYTES formats are removed.
Thanks to Scott Chapman, American Electric Power, USA.
Change 27.039 Change 26.183 is wrong; it removed the QBAC and QTXA vars
ASUMDB2P from the summary in ASUMDB2P and TRNDDB2 code, claiming
TRNDDB2P those variables were not in the IFCID=239 (101 subtype 1)
VMACDB2 Package Data records starting in V7.1. But they all DO
Mar 16, 2009 exist in DB2ACCTP dataset in DB2 V8.1 or later, so they
are now restored in ASUMDB2P and TRNDDB2P summary code.
The QBAC and QTXA fields are only populated in DB2ACCTP
dataset if DB2 Accounting Trace Class 10 is enabled.
Those variables have ALWAYS been kept in the DB2ACCTP
dataset, so this only impacts users of MXG's summaries.
Thanks to Giuseppe Giacomodonato, E.P.V. Technologies, ITALY.
Change 27.038 Change 26.183 SMF/Performance Sentry Release 3.1.4.
VMACNTSM A major enhancement in NTSMF adds IDPROCES and SQLVERSN
Mar 15, 2009 to 72 SQLSERVER/MSSQL dataset, so that the individual
SQL Server Process can be identified. There were also
37 new objects that are now supported by these new exit
members:
exntdtos exntm8ca exntm8co exntm8dm exntm8dp exntm8lo
exntm8md exntm8me exntm8pa exntm8pc exntm8pi exntm8pr
exntm8se exntm8th exntmlca exntmlco exntmldm exntmldp
exntmllo exntmlmd exntmlme exntmlpa exntmlpc exntmlpi
exntmlpr exntmlse exntmlth exntqlbl exntqldf exntqlrp
exntqlwg exntrpsv exntsqbt exntsqdf exntsqpl exntsqrp
exntsqwg
Change 27.037 The example in the comments to execute did not have the
ADOC70PR //SPIN DD UNIT=SYSDA,SPACE=CYL(1,1)
Mar 15, 2009 that is required by that example program. It can be
a temporary dataset, because this example builds a
single output PDB library for analysis. The SPIN DD
is only used in the RMFINTRV program to create SPINRMFI,
used to keep the last four hours of CPU busy for the old
MXG MSU4HRAV variable when RMFINTRV is created on a daily
basis. MSU4HRAV is actually archaic, predating the IBM
addition of their SMF70LAC, which should be used in place
of MXG's MSU4HRAV.
Thanks to MP Welch, SPRINT, USA.
Change 27.036 -Fields DBHCEUID, DBHCEUTX, DBHCEUWN are now kept in the
VMACTMDB TMON for DB2 TMDBBF,TMDBBG,TMDBBH, and TMDBBI datasets,
Mar 14, 2009 and all three have any '00'X translated to blanks.
-Variable HSIID now formatted with MGDB2II.
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 27.035 Previously, you could not leave SYSTEM blank in TIMETABL,
VMXGTIME but with this revision, if ALL of your SYSTEMS are to be
Mar 11, 2009 changed the same way, you do NOT need to fill in SYSTEM,
and the same for SYSPLEX. If you have systems on
different time zones, then each SYSTEM or SYSPLEX must be
in the TIMETABLE (but only those that differ from base).
So if you have 3 systems, 2 on local, and one on local+2,
to convert all systems to local, only the local+2 system
needs to be listed in TIMETABL.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 27.034 Support for EAV, Extended Address Volume, devices with
VMACDCOL more than 65520 cylinders, introduced in z/OS 1.10, with
Mar 11, 2009 HUGE volume sizes, 236GB (256K Cylinders) first release.
EAV devices are formally documented as 3390-A devices.
Dataset DCOLVOLS: new variables:
DCVCYLMG='EAV*INDICATOR*FLAG'
DCVDPTYP='PHYSICAL*DEVICE*TYPE'
DCVEAVOL='EAV*INDICATOR*FLAG'
DCVTRALC='ALLOCATED*TRACK*MANAGED'
DCVTRFRG='FRAGMENTATION*INDEX*TRACK*MANAGED'
DCVTRFRX='FREE*EXTENTS*TRACK*MANAGED'
DCVTRFSP='FREESPACE*TRACK*MANAGED'
DCVTRLGE='LARGEST*EXTENT*TRACK*MANAGED'
DCVTRPCT='PCT FREESPACE*TRACK*MANAGED'
DCVTRVLC='TOTAL CAPACITY*TRACK*MANAGED'
The new Track-Managed Space or Base Addressing Space
is the first 65520 cylinders (54GB), and space above
that is the Extended Addressing Space.
Disk allocation in the EAS is in units of 21 cylinders.
Initial implementation is VSAM only, KSDS,RRDS,ESDS and
linear, so DB2 and zFS can use EAV volumes.
Dataset DCOLSC: new variables:
DSCBAKUP='ACC*BACKUP*PARM*VALUE'
DSCBUSP ='ACC*BACKUP*PARM*SPECIFIED'
DSCDSSEP='DATASET*SEPARATE*PROFILE'
DSCFLAG3='DSC*FLAG*BYTE*3'
DSCFOSL ='OAM*SUBLEVEL*1'
DSCTIER ='MULTI-TIER*SG*VALUE'
DSCTIERS='MULTI-TIER*SG*SPECIFIED'
DSCVERSN='ACC*VERSION*PARM*VALUE'
DSCVERSP='ACC*VERSIONING*PARM*SPECIFIED'
Dataset DCOLDC new variables:
DDCFSDB ='SDB*IS*SPECIFIED?'
DDCFVORD='OVERRIDE*JCL*SPECIFIED?'
Dataset DCOLBKUP new variables:
UBFLAG3='INFORMATION*FLAG*3'
UBNOSPH='SPHERE(NO)*PROCESSED?'
UBGVCN ='GENVSAMCOMPNAMES*PROCESSED?'
-Variable UMNMIG, number of times migrated, is reserved in
dataset DCOLMIGS.
-Doc notes:
Length of VOLUME RECORD structure still 112.
-Type 1415 enhancement:
-MXG Change 25.071 added variable EADSCBOK was decoded
from SMF14EADSCB, in the type 5 extended information
segment of the SMF type 14 and 15 records. It means
that the user program provided a valid DCBE that has
EADSCB=OK. It does NOT mean that OPEN needed this
option.
If this bit is zero, then the program did not specify
EADSCB=OK on the DCBE macro. IBM suggests upgrading
the program to handle 28-bit cylinders and coding
EADSCB=OK. This is to help plan for when EAV might
support more types of data sets.
-MXG Change 25.071 also decoded variable SMF14EAV from
SMF14EXCPBAM. This is 'Y' if the user program issued
one or more instances of the EXCP or XDAP macro since
the BSAM, BPAM or QSAM DCB was opened.
-SMF19 enhancements added by Change 26.071, documentation:
These existing two-byte counters describe free space for
the entire volume. If the value exceeds the capacity of
the counter, it will be set to the maximum of 65535. The
correct values will always be in SMF19EVF and SMF19TMF.
MXG var IBM name
NRDSCBS SMF19NDS Number of DSCBs in VTOC
NRDSCB0 SMF19DSR Number of format 0 (unused) DSCBs
in VTOC
NRALTRKS SMF19NAT Number of unused alternate tracks
CYLAVAIL SMF19SPC Numbers of free complete cylinders
TRKAVAIL SMF19??? Number of free tracks
MAXCYLS SMF19LEX Numbers of complete cylinders in
largest free extent
MAXTRKS SMF19??? Numbers of complete tracks in
largest free extent
NRUNEXTS SMF19NUE Number of free extents
New SMF19CYM variable will mean that the volume has
cylinder-managed space.
The following will be new four-byte unsigned counters at
the end of the record:
SMF19SDS Number of DSCBs in VTOC
SMF19SL0 Number of format 0 (unused) DSCBs in VTOC
The following 5 new counters apply to the whole volume.
SMF19SUC Number of free complete cylinders
SMF19SUT Number of additional free tracks
SMF19SNC Number of complete cylinders in largest free
extent
SMF19SNT Number of additional free tracks in largest
free extent
SMF19SNE Number of free extents
The following five new counters apply only to the
track-managed space on the volume. For volumes with no
cylinder-managed space (SMF19CYM is off) these counters
are the same as the previous five counters for the whole
volume.
SMF19BUC Number of free complete cylinders
SMF19BUT Number of additional free tracks
SMF19BNC Number of complete cylinders in largest free
extent
SMF19BNT Number of additional free tracks in largest
free extent
SMF19BNE Number of free extents
The following new fields provide volume size information
SMF19TRK Total number of tracks on the volume
SMF19TRM Total number of tracks in track-managed space
when SMF19CYM = '1' to the value of SMF19TRK
otherwise. When SMF19CYM ='1' this value is
also the address where cylinder-managed space
begins.
Change 27.033 IMS logs from different IMS Versions cannot be processed
JCLIMSL6 in a single job with JCLIMSL6 or using TYPEIMS7, because
Mar 11, 2009 the IMS version is not provided in the log records. You
must EDIT the MACRO _IMSVERS nn % to tell MXG what IMS
version's records are to be read. The original way was
to define _IMSVERS in your IMACKEEP member, but if you
have two different versions, you needed to create two
special tailoring PDS libraries, each with only the that
IMACKEEP member, and then override the //SOURCLIB DD to
place this tailoring library ahead of the "USERID" and
"MXG" source libraries; do-able, but messy at the least.
To eliminate all that stuff, the JCLIMSL6 example now
has added, in //SYSIN stream for the TESTIMSB/TESTIMSA:
%LET MACKEEP= MACRO _IMSVER 10.0 % ;
which overrides the IMSVER definition in either your
IMACKEEP member or in your IMACIMSA, so that you do NOT
have to EDIT either of those members into your USERID
to define the IMS Version.
Note that this issue only applies to MXG JCLIMSL6 job
that read the native IMS log records, TYPEIMSx. It
does not apply to these vendor products that create their
own IMS data which contain the IMS version number and
which can be concatenated or have multiple versions input
in one job: TYPECIMS/TYPESVIE/TYPEITRF/TYPETIMS.
Thanks to Herbert Sweeney, Verizon, USA.
Change 27.032 Support for CICS/TS 4.1.0 OPEN BETA. INCOMPATIBLE as new
VMAC110 fields in CICSTRAN were INSERTed rather than APPENDed to
Nov 20, 2008 the SMF 110 Subtype 1 records:
Dec 17, 2008 BFDGSTCT='EXEC*CICS*BIF*DIGEST*COMMANDS'
Jan 12, 2009 BFTOTCT ='EXEC*CICS*BIF DEEDIT*BIF DIGEST*COMMANDS'
Mar 10, 2009 ECEFOPCT='EVENT*FILTER*OPERATIONS'
EXCICECC ECEVNTCT='EVENTS*CAPTURED'
EXCICPGD ECSIGECT='SIGNAL*EVENTS*CAPTURED'
EXCICEPG EICTOTCT='EXEC*CICS*REQUESTS'
EXCICECG MAXTTDCN='MAXTTDLY*WAIT FOR*T8 TCB*COUNT'
EXCICECR MAXTTDTM='MAXTTDLY*WAIT FOR*T8 TCB*DURATION'
VMXGINIT MLXSSCCN='XML*SYSTEM*SERVICES*CPU*DISPATCHES'
UTILEXCL MLXSSCTM='XML*SYSTEM*SERVICES*CPU*DURATION'
IMACCICS MLXSSTDL='TOTAL*DOCUMENT*LENGTH'
Mar 14, 2009 T8CPUTCN='T8CPUT*JVM*MULTITHREADED*COUNT'
T8CPUTTM='T8CPUT*JVM*MULTITHREAD*DURATION'
TIASKTCT='EXEC*CICS*ASKTIME*COMMANDS'
TITOTCT ='EXEC*CICS*ASK/CONVERT/FORMAT*TIME*CMDS'
WBATMSNM='ATOMSERVICE*RES DEF*NAME*USED'
WBPIPLNM='PIPELINE*RES DEF*NAME*USED'
WBPROGNM='PROGRAM NAME*FROM URIMAP*RES DEF'
WBSVCENM='WEBSERVICE*RES DEF*NAME*USED'
WBURIMNM='URIMAP*RES DEF*NAME*MAPPED'
WBSVOPNM='WEBSERVICE*OPERATION*NAME'
MLXMLTCT='EXEC*CICS*TRANSFORM*REQUESTS'
WSACBLCT='WSACONTEXT*BUILD*REQUESTS'
WSACGTCT='WSACONTEXT*GET*REQUESTS'
WSAEPCCT='WESAEPR*CREATE*REQUESTS'
WSATOTCT='TOTAL*WS-ADDRESSING*REQUESTS'
WBSFCRCT='SOAPFAULT*CREATE*REQUESTS'
WBSFTOCT='TOTAL*SOAPFAULT*REQUESTS'
WBISSFCT='INVOKE*XXXSERVICE*SOAP*FAULTS'
WBSREQBL='SOAP*REQUEST*BODY*LENGTH'
WBSRSPBL='SOAP*RESPONSE*BODY*LENGTH'
JVMTHDTM='JVMSERVER*THREAD*WAIT*DURATION'
JVMTHDCN='JVMSERVER*THREAD*WAIT*COUNT'
WMQASRTM='WEBSPHERE*MQ*API*CPU SRB*DURATION'
WMQASRCN='WEBSPHERE*MQ*API*CPU SRB*COUNT'
-Three new TCBs are added to the CICDS Dispatch Statistics
and CICINTRV datasets, T8, EP, and TP, but only T8CPUT is
contained in the CICSTRAN data at present. And the TCB
Numbers have changed, as shown in this table, but since
the TCB 2-character name is used to identify the TCB,
this (fortunately) caused no incompatibility in CICDS:
See Change 27.200 for updated table.
-New Pool added to STID=60, CICDSPOO for MAXTHRDS TCBs.
-CICS Statistics STID=11, dataset CICXMR has new variables
XMRCHGAG XMRCHGDT XMRCHGUS XMRGRFRM XMRINSAG XMRINSDT
XMRINSUS
-CICS Statistics STID=12, dataset CICXMC has new variables
XMCCHAGT XMCCHGTM XMCCHUSR XMCDEFSR XMCINAGT XMCINSTM
XMCINUSR
-CICS Statistics STID=21, dataset CICVT, has new variables
A03LUHWM A03LUNUM A03PSEC A03PSIC A03PSNC
A03PSOC A03PSUC A03PSTYP A03PSDIN
-CICS Statistics STID=42, dataset CICTQR new variables
TQRCHGDT TQRGRFRM TQRCHGAG TQRCHGUS TQRINSAG TQRINSDT
TQRINSUS
-CICS Statistics STID=52, dataset CICCONSR new variables
A14CHGDT A14GRFRM A14CHGAG A14CHGUS A14INSAG A14INSDT
A14INSUS
-CICS Statistics STID=67, dataset CICFCR new variables
A17CHGAG A17CHGDT A17CHGUS A17GRFRM A17INSAG A17INSDT
A17INSUS
-CICS Statistics STID=74, dataset CICIMQ new variables
CMQBUFMH CMQCB CMQCHGAG CMQCHGDT CMQCHGUS CMQCRTMH
CMQCRTNE CMQCTL CMQDLTMH CMQDLTMP CMQGRFRM CMQINQMP
CMQINSAG CMQINSDT CMQINSUS CMQMHBUF CMQRESYN CMQSETMP
CMQSTAT CMQSUB CMQSUBRQ
-CICS Statistics STID=102, dataset CICDB2RE new variables
D2RCHGAG D2RCHGDT D2RCHGUS D2RGRFRM D2RINSAG D2RINSDT
D2RINSUS
-CICS Statistics STID=104, dataset CICWBR new variables
WBRCHGAG WBRCHGDT WBRCHGUS WBRGRFRM WBRINSAG WBRINSDT
WBRINSUS WBRNAME WBRUSAGE
-CICS Statistics STID=105, dataset CICPIR new variables
PIRCHGAG PIRCHGDT PIRCHGUS PIRGRFRM PIRINSAG PIRINSDT
PIRINSUS
-CICS Statistics STID=106, dataset CICPIW new variables
PIWCHGAG PIWCHGDT PIWCHGUS PIWGRFRM PIWINSAG PIWINSDT
PIWINSUS
-CICS Statistics STID=108, dataset CICTCPIP new variables
SORCHGAG SORCHGDT SORCHGUS SORGRFRM SORHOST SORINSAG
SORINSDT SORINSUS SORIPADR SORIPFAM SORMXDAT SORTRNID
SORURM
-CICS Statistics STID=109, dataset CICISR new variables
ISRCHGAG ISRCHGDT ISRCHGUS ISRFSICQ ISRFSICR ISRFSICS
ISRGRFRM ISRINSAG ISRINSDT ISRINSUS ISRIPADR ISRIPFAM
ISRLAUTH ISRRMTST ISRTRBYR ISRTRBYS ISRTRREQ
-CICS Statistics STID=111, dataset CICTCPIP new variables
IIRCHGAG IIRCHGDT IIRCHGUS IIRGRFRM IIRINSAG IIRINSDT
IIRINSUS
-CICS Statistics STID=112, dataset CICDHD new variables
DHDCHGAG DHDCHGDT DHDCHGUS DHDGRFRM DHDINSAG DHDINSDT
DHDINSUS
-CICS Statistics STID=114, dataset CICTCPEJ new variables
EJRASSRT EJRCHGAG EJRCHGDT EJRCHGUS EJRGRFRM EJRINSAG
EJRINSDT EJRINSUS EJRIPADR EJRIPFAM
-New CICS stats STID=120, new dataset
CICPGD='PROGRAM DEF (RESOURCE) ID'
new variables:
PGDAPI PGDCHGAG PGDCHGDT PGDCHGUS PGDCONCU PGDDATLO
PGDDYNAM PGDEXECK PGDEXEKY PGDGRFRM PGDINSAG PGDINSDT
PGDINSUS PGDJVM PGDJVMPR PGDLANG PGDLANGD PGDPGMTY
PGDREMOT PGDRMTPG PGDRMTSY PGDRMTTR PGDRUNEN
-New CICS stats STID=140, new dataset
CICECG='EVENTBINDINGS (GLOBAL) ID'
new variables:
ECGFLTOP ECGCAPTU ECGDISAB
-New CICS stats STID=142, new dataset
CICEPG='EVENTPROCESS (GLOBAL) ID'
new variables:
EPGCUEVQ EPGCUTRQ EPGDSPAT EPGDSPCU EPGDSPPK EPGEVTCU
EPGEVTTR EPGEVTTS EPGEVTWM EPGNOREV EPGPKEVQ EPGPKTRQ
EPGPRIEV EPGPUTEV EPGSYNEV EPGTRDEV EPGTRNEV
-New STIDs 141 and 143 are structurally supported, but
only the _CICCMN variables are output, awaiting test
data records to validate.
STID DATASET DESCRIPTION
141 CICECR EVENTBINDINGS (RESOURCE) ID
143 CICECC CAPTURESPEC RESOURCE ID
-See Change 27.200: MXG 27.08 now supports STID 141,143.
-CICS/TS 4.1 is still a BETA release, so IBM may choose to
add, or remove, any of these fields in their GA release.
-See Change 27.200 for Support for CICS/TS 4.1.0 GA.
-Old notes "ADDED IN CICS 4.1.0" were not CICS/TS 4.1, but
are now "ADDED IN CICS/ESA 4.1.0", from 1994!
Change 27.031 A set of sample reports for some basic TCP/IP analysis
ANAL119 from IBM type 119 records (MXG Member TYPE119) for the
May 7, 2009 analysis of FTP and Telnet usage, very similar to the
ANALTCP reports from SMF 118 records (which was also
contributed by Steve, by Change 18.091 in April, 2000!
Excellent comments in the ANAL119 member document these
sample reports, but don't contact Steve for help; any
problems should be directed to support@mxg.com.
Thanks to Steve Clark, DHL, USA.
Thanks to R. Wells, American General Finance, USA.
Change 27.030 -Only the last MDISK segment in XAMDEV records was output
EXXAMDEM in the XAMDEV dataset, but there can be many MDISKs, so
IMACXAM the new XAMDMINI dataset is created, outputting all MDISK
VMACXAM segments, containing these MDISK-specific variables:
VMXGINIT DNMDISKS MDSKADDR MDSKDIST MDSKECYL MDSKOWNR MDSKSAMP
Mar 6, 2009 MDSKSCYL MDSKWRIT MDSKZERO UDSKDIST UDSKSAMP UDSKUSER
Mar 17, 2009 UDSKZERO USSKWRIT
and ALL those variables were removed from XAMDEV dataset.
-The IODCAD logic had a typo, testing for 3390 instead of
for 3990, so the 3990 variables in XAMDEV dataset were
always missing values.
-These MTRPAG variables were kept in XAMSYS but not in the
dataset XAMDEV:
PGS1 PGS2 PGS3 CALCYLPA CALCYLSP CALCYLPR
CALEXTPG CALEXTPS CALEXTPP
Thanks to Douglas C. Walter, Citigroup, USA.
Change 27.029 Support for BMC's Ultra Op Product's User SMF record
EXULOPIN creates new dataset ULTRAOP.
FORMATS
IMACULOP
TYPEULOP
TYPSULOP
VMACULOP
VMXGINIT
Mar 4, 2009
Thanks to Tony Curry, BMC, USA.
Change 27.028 -Support for NMON Nigel's Monitor for AIX/Linux under zVM,
EXNMONPO record type 'VM' adds 37 new variables to the NMONINTV
IHDRNMON Interval dataset. The descriptor record for 'VM' is not
IMACNMON consistent; sometimes its second word is the expected
VMACNMON Tnnnn snapshot value, sometimes that value is missing.
VMXGINIT DIRTY='NR*DIRTY'
Mar 13, 2009 WRITEBACK='NR*WRITEBACK'
UNSTABLE='NR*UNSTABLE'
PAGETABLEPAGES='NR*PAGE*TABLE*PAGES'
MAPPED='NR*MAPPED'
SLAB='NR*SLAB'
PGPGIN='PGPGIN'
PSPGOUT='PGPGOUT'
PSWPIN='PSWPIN'
PSWPOUT='PSWPOUT'
PGFREE='PGFREE'
PGACTIVATE='PGACTIVATE'
PGDEACTIVATE='PGDEACTIVATE'
PGFAULT='PGFAULT'
PGMAJFAULT='PJMAJFAULT'
PGINODESTEAL='PGINODESTEAL'
SLABSCANNED='SLABS*SCANNED'
KSWAPDSTEAL='KSWAPD*STEAL'
KSWAPINODESTEAL='KSWAPD*INODESTEAL'
PAGEOUTRUN='PAGEOUTRUN'
ALLOCSTALL='ALLOCSTALL'
PGROTATED='PGROTATED'
PGALLOCHIGH='PGALLOC*HIGH'
PGALLOCNORM='PGALLOC*NORMAL'
PGALOCDMA='PGALLOC*DMA'
PGREFILLHIGH='PGSTEAL*HIGH'
PGREFILLNORM='PGSTEAL*NORMAL'
PGREFILLDMA='PGREFILL*DMA'
PGSTEALHIGH='PGSTEAL*HIGH'
PGSTEALNORM='PGSTEAL*NORMAL'
PGSTEALDMA='PGSTEAL*DMA'
PGSCANKSWAPDHIGH='PGSCAN*KSWAPD*HIGH'
PGSCANKSWAPDNORM='PGSCAN*KSWAPD*NORMAL'
PGSCANKSWPADDMA='PGSCAN*KSWAPD*DMA'
PGSCANDIRECTHIGH='PGSCAN*DIRECT*HIGH'
PGSCANDIRECTNORM='PGSCAN*DIRECT*NORMAL'
PGSCANDIRECTDMA='PGSCAN*DIRECT*DMA'
-Support for record type 'POOLS' creates new NMONPOOL
dataset with these variables:
ENTITLED='ENTITLED'
ENTITLED_POOL_CAPACITY='ENTITLED*POOL*CAPACITY'
MAX_POOL_CAPACITY='MAX*POOL*CAPACITY'
POOL_BUSY_TIME='POOL*BUSY*TIME'
POOL_ID='POOL*ID'
POOL_MAX_TIME='POOL*MAX*TIME'
SHCPUS_IN_SYS='SHCPUS*IN*SYS'
SHCPU_BUSY_TIME='SHCPU*BUSY*TIME'
SHCPU_TOT_TIME='SHCPU*TOT*TIME'
-New IHDRNMON "NMON infile" exit is taken after RECTYPE
has been INPUT so that unwanted record types can be
deleted prior to processing. But use carefully; if you
delete the wrong records, you could end up with nothing
output to the NMON datasets. And the &IHDRNMOH macro
variable is also defined so the exit can be defined in
your //SYSIN with %LET IHDRNMOH= %quote ( your code ) ;
-Erratic JFSFILE records with 38 instead of 36 fields have
been observed, but that is a problem with NMON, not MXG.
Thanks to Long Nguyen, DHS, USA.
Thanks to Marvin Einarson, DHS, USA.
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 27.027 TYPE42DS variables RESPTIME, MAXRSPTM and MAXSRVTM are in
VMAC42 milliseconds, but MAXRSPTM incorrectly had TIME12.2. Now
Mar 2, 2009 all have 6.3 format and milliseconds in their label.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 27.026 Variable SMF88LTD='TIMESTAMP WHEN*SMF INTERVAL*EXPIRED'
VMAC88 was usually wrong, as the GMT Offset was repetitively
Mar 2, 2009 applied. Also, the GMT offset was never applied if the
GMT Offset was positive.
Change 27.025 Support for z/OS 1.11.
EXTY8224 -TYPE 0. New variable:
EXTY8225 CVTTZ ='CVTTZ*TIME DIFFERENCE*LOCAL*TO GMT'
EXTY8226 -TYPE1415. NO NEW DATA, but lots of text inserts about
IMAC82 assembling the IFGSMF14 Macro with DSECT=YES, which is
VMAC0 why it is flagged in the SMF Manual as changed.
VMAC82 -TYPE30. NO NEW DATA, only one line of text updated.
VMXGINIT -TYPE82. New subtypes 24, 25, and 26.
May 2, 2009 -TYPE92. Subtype 15 now documented, but MXG supported
was added in Change 26.277 for APAR OA24208.
-TYPE1415 New variables DCBEEX31 XTIOTYES created from
SMF14FLGS.
Change 27.024 If only PMACC04 was requested, a NOT SORTED ERROR for the
ANALDB2R DB2SUMRY dataset occurred. Some additional corrections to
Feb 28, 2009 PMACC01/PMACC02 (short reports had LOCK suspends reported
under the PREFETCH column, and WRITE IMMEDIATES under the
LOCKS column, and time formats match DB2PM (TIME12.6).
Thanks to Paul Volpi, UHC, USA.
Change 27.023 Variables S17FBKNM S17FEXNM and S17FMFNM are now KEPT in
VMAC117 dataset S117NODE so that it can be combined with S117FLOW
Feb 27, 2009 dataset so the Execution Group and Flowname to which the
Node belongs can be known. Those variables are also
added to the _B117NOD and _B117FLO By List macros.
Thanks to Trevor Holland, ANZ, AUSTRALIA
Change 27.022 NDM Record 'IK' is now supported, output in NDMDT dataset
VMACNDM not because I have a DSECT for that NDM subtype, but
Feb 26, 2009 because it appears to have the same structure.
Thanks to Herbert Sweeney, Verizon, USA.
Change 27.021 QPACxxxx flag variables set from QPACFLGS were not reset,
VMACDB2 so if there was more than one NRQPAC segment in a record,
Feb 25, 2009 the values could have been wrong. These eight variables
QPACDBRM QPACPACK QPACCLS8 QPACCRNT QPACINSP QPACCLS7
QPACPAC
could have been carried forward.
Thanks to Giuseppe Giacomodonato, E.P.V. Technologies, ITALY.
Change 27.020 WEEK70PR failed with VARIABLE INTERVAL NOT FOUND because
WEEK70PR - that variable has not existed in ASUM70PR in years, and
Feb 25, 2009 - WEEK70PR was way out of date, only supporting 16 LPARs.
This change recreates the old INTERVAL (interval count)
and was enhanced to support all 60 possible LPARS.
Thanks to Atle Mjelde, Ergo Group, NORWAY.
Change 27.019 CICS User fields USECOPID/USECUSER/USECBRAN/APPCEMP1
IMACAAAA are supported in listed new IMACICxx CICS exit members.
IMACICUA IMACICUA - USECOPID
IMACICUB IMACICUB - USECUSER
IMACICUC IMACICUC - USECBRAN
IMACICUD IMACICUD - APPCEMP1
UTILEXCL
VMAC110
Feb 24, 2009
Change 27.018 DB2 V9 variables added by IBM or overlooked now input.
VMACDB2 New variables in DB2STAT0/DB2STATS from QWSD segment:
Feb 23, 2009 QWSDARTH='ROLLUPS*DUE TO*ROLLUP*THRESH*EXCEEDED'
QWSDARSG='ROLLUPS*DUE TO*STORAGE*THRESH*EXCEEDED'
QWSDARST='ROLLUPS*DUE TO*STALENESS*THRESH*EXCEDED'
QWSDCDTB='NOT ROLLUP*DUE TO*KEY FIELDS*NULL'
New variable in DB2STAT0/DB2STATS from QVLS segment:
QVLSL254='CONTENTIONS*LATCH CLASS*254'
New variables in DB2STAT0/DB2STATS from QVAS segment:
QVASCBOS='SUCCEED*SYSEVENT*BOOSTS*THREAD-WAIT'
QVASCBOF='FAILED*SYSEVENT*BOOSTS*THREAD-WAIT'
QVASMBOS='SUCCEED*SYSEVENT*BOOSTS*THREAD-STORE'
QVASMBOF='FAILED*SYSEVENT*BOOSTS*THREAD-STORE'
New variables in DB2STAT0/DB2STATS from QSST segment:
QSSTGETS='QSST_SGETM*STACK*REQUEST*GETMAINS'
QSSTGETR='QSST_SGETR*GET*REQUESTS'
QSSTGETE='QSST_SGETEXT*STACK*EXTENSIONS'
QSSTFRES='QSST_SFREEM*SEGMENT*FREEMAIN*REQUESTS'
QSSTFRER='QSST_SFREER*REQUESTS*TO FREE A*SEGMENT'
New variables in DB2STAT0/DB2STATS from QWOS segment:
QWOSLUIC='UNREFERNCED*INVERVAL*COUNT'
QWOSFLG ='STATUS*FLAG FOR*RMF-API (S)'
QWOSRCDE='RETURN*CODE FROM*RMF-API (S)'
QWOSRSNC='REASON*CODE FROM*RMF-API (S)'
NOTE: DB2 Parameter ZOSMETRICS=YES must be specified to
populate these variables. APAR PK62116 applies.
With the default NO value, fields contain 'FFFFFFFF'x.
New variables in DB2STAT1/DB2STATS from QXST segment:
QXCRESEQ QXALTSEQ QXDROSEQ QXPRRESI QXALTVW
QXALTCTX QXALTJR QXCRCTX QXCRROL QXDRPCTX QXDRPROL
QXMERGE QXRNIX QXSTXMLV QXTRTBL
These variables were not INPUT in the DB2STAT1 record,
but were deaccumulated; all were labeled and did not
raise an uninit warning because they were INPUT in the
DB2ACCT record.
New variables in DB2ACCT from QXST segment:
QXALTCTX QXALTJR QXCRCTX QXCRROL QXDRPCTX QXDRPROL
QXMERGE QXRNIX QXSTXMLV QXTRTBL
These variables were INPUT but not kept.
Variable QBSTLPL in DB2ACCT was not input because its
conditional INPUT should have been at 276 vice 280.
Thanks to Steve Wood, DST Systems, USA.
Thanks to Terry L. Berman, DST Systems, USA.
Change 27.017 Undecoded TOKDANAM non-tokens NOHOME/NOPROGRAM now set
EXTY80TK their segment-specific variables TOKHOME/TOKPROG to value
IMAC80A 'NOHOME' or 'NOPROGRAM', and logic was added to print
VMAC80A the first ten instances of undecoded TOKDANAM values with
VMXGINIT ***MXGNEWDATA: messages and a hex dump on the SAS log.
Feb 20, 2009 -NOTHREADMAX and NOSHMMEMAX non-tokens create new variable
Mar 13, 2009 TOKNOTHR and TOKNOSHM with those text values, and real
token LDAPHOST decodes and populates new var TOKLDHST.
-However, it was discovered that there can be multiple
instances of the (301) segment, with different TOKSUBSY
values, so these "TOKDANAM-specific" variables
TOKASIZM TOKDCE TOKGID TOKHOME TOKLDAP
TOKLDHST TOKNOSHM TOKNOTHR TOKPROG TOKUID
cannot be kept in the TYPE80nn event datasets, since only
the last value would be output. Instead, new TYPE80TK
dataset is now created, with both the TOKDANAM-specific
variables, and TOKSUBSY, TOKDANAM, TOKCHARV and TOKNUMRV
replications to give you easier reporting choices.
Thanks to Bill Arrowsmith, EuroClear, BELGIUM.
Thanks to Maurice Peek, EuroClear, BELGIUM.
Change 27.016 -SMF 42 Subtype 25 (Rename Member), NEWMEMNM/OLDMEMNM were
VMAC42 misaligned, because SMF42PF1 plus 3 reserved bytes only
Feb 20, 2009 exist in the subtype 24 record.
-The three member name fields NEWMEMNM/OLDMEMNM/AORMEMNM
in subtypes 24 and 25 are theoretically variable length
fields, so they were INPUT x $VARYING8. SMF42PML/QOL, but
those lengths are always 8 bytes, so now $EBCDIC8. is
used, which also makes them correct under ASCII SAS.
-The subtype 25 record has a minor error: SMF42NT/NRTRIPLT
the number of triplets, is 3, but 4 triplets are present.
The fourth points to ICHRUTKN, so MXG tests the offsets
rather than trusting the NRTRIPLT.
Thanks to David Kaplan, DTCC, USA.
Change 27.015 Support for processing DB2 GTF records was revised.
UDB2GTF -The SORT FIELDS= statement in UDB2GTF must be changed to
VMACSMF only sort on the first field; without this change, there
Feb 20, 2009 was no error, but the output records were incorrect.
-The _GTFDB2 macro now sets ID=101 if IFCID=239 is found.
-The massive number of DEBUG statements are no longer
printed on the log, unless you choose to enable debugging
in the UDB2GTF program.
Thanks to Tony Curry, BMC, USA.
Thanks to Steve Wood, DST Systems, Inc, USA.
Change 27.014 -SAS option TRANSCODE=NO is now set for all $HEX variables
DOC so they are NOT translated from EBCDIC to ASCII or vice
FORMATS versa. Normally when a SAS dataset is moved between
UTILCVRT different platforms (XPORT,CIMPORT,etc.), all character
UTILXRF1 variables are translated, but this is most unwelcome for
VMXGINIT MXG variables that contain $HEX values (CPUTYPE changed
VMXGSUM from '2086'x to '8786'x). The TRANSCODE attribute is set
Mar 8, 2009 in SAS V9 with syntax "ATTRIB var1 var2 TRANSCODE=NO;"
May 4, 2009 but since it does not exist under SAS V8, and there still
are MXG sites limping along on archaic SAS V8, two new
GLOBALed macro variables, &MXGNOTRA and &MXGNOTRB, are
defined in VMXGINIT by this macro logic:
%IF &SASVER GE 9 %THEN %DO;
%LET MXGNOTRA= ATTRIB ;
%LET MXGNOTRB= TRANSCODE=NO;
%END;
%ELSE %DO;
%LET MXGNOTRA= * ;
%LET MXGNOTRB= ;
%END;
and then this statement was added in each of the 300+
members that create $HEX variables
&MXGNOTRA var1 var2 var3 &MXGNOTRB ;
so the TRANSCODE=NO attribute will be set under SAS V9,
but under SAS V8, that statement becomes only a comment.
-In addition to variables formatted with the $HEX format,
there are character variables that contain hex values but
they are formatted with MXG-created $MGxxxxx formats. The
FORMATS member was read to select those format names, and
lookup format $MGNOTRA was created to validate that these
"$MG-HEX" variables also have the TRANSCODE=NO specified.
New QA tests read FORMATS to discover any new "$MG-HEX"
formats, and update the $MXNOTRA table when new formats
are found (if I forget when creating a new one!).
-In March, 2009, SAS V9 did not pass the ATTRIB TRANSCODE
into a dataset created by a SAS VIEW, but in May, 2009,
that was corrected by HotFix E9BC81 SAS Note SN-035112,
and this change text was revised.
-However, it was also discovered that the dataset created
by the PROC CONTENTS OUT= operand does NOT contain the
TRANSCODE attribute; that OUT= dataset is a major input
for MXG's QA testing of variables. While the printed
output of PROC CONTENTS does show the TRANSCODE
attribute, it is ONLY printed for datasets that have a
variable with TRANSCODE=NO specified. Fortunately, the
SASHELP.VCOLUMN dataset does contain the TRANSCODE
attribute for every variable, so UTILXRF1 was revised to
use that dataset to add TRANSCODE to the OUT= XREFDATA
dataset used for QA analysis. SAS Development has
indicated their intention to correct the omission in PROC
CONTENTS OUT= in a future release.
-UTILCVRT can be used if the dataset was already moved to
the new platform, to "un-translate" the $HEX variables;
it's comments were updated.
-And, for WPS, the VMXGINIT default sets MXGVIEW=NO.
-New $MGNOTRA is created in FORMATS by reading the FORMATS
member to identify MXG-created formats that have HEX data
values, and then it is used in the QA tests to ensure all
of those variables do indeed have TRANSCODE=NO specified.
-Because this change can be recognized by the existence of
&MXGNOTRA in each updated member, I did NOT change the
"LAST UPDATED:" text at the top of the 300+ members that
created a total of 9831 $HEX-containing variables.
I also did not add the TRANSCODE attribute to the DOCVER
nor to the ADOCxxxx descriptions, as there's no room for
a new attribute, and because a PROC CONTENTS will show it
if you really need to confirm its value for a dataset.
Change 27.013 TMON for MQ Series INPUT STATEMENT EXCEEDED RECORD for QM
VMACTMMQ subtype; MXG expected 18 reserved bytes that don't exist.
Feb 18, 2009
Thanks to Paul Volpi, UHC, USA.
Change 27.012 This enhancement to select DB2 reports by DATABASE set a
ANALDB2R new MXG world record, with fifteen iterations needed to
VFMT102 resolve all possible permutations discovered in testing!
Feb 17, 2009 Selection by DATABASE uses the HEX values of OBID/DBID to
Feb 21, 2009 select the desired observations from DB2 datasets, but
if IFCID=105 and 107 were traced, they are used to map
hex values to text names. If you did not trace 105/107s,
or no 105/107 for the OBID/DBID being reported was found,
the reports will print the HEX value instead of the name.
New documentation in comments for the AUDIT= subparameter
list the IFCIDs needed for full AUDIT report generation,
as well as those that do contain the Database ID field.
-If only PMACC02 was specified, and if both ASUMDB2A and
DB2ACCCT datasets exist in the DDNAME/LIBREF pointed to
by the PDB=xxx operand of %ANALDB2R, and if USEACCT=YES
was specified, ASUMDB2A was always used when DB2ACCT
should have been used.
Thanks to Scott Swindling, Nordstrom, USA, who tested each iteration!
Change 27.011 Support for CTG V7.2 (INCOMPATIBLE, new CTG_RECID=7 made
VMAC111 INPUT STATEMENT EXCEEDED RECORD LENGTH error). That new
Feb 19, 2009 subtype is not documented in SC34-6961-00, but protection
for any new subtype was added, with a NOTE that new data
exists in the future.
-CTG_RECID=3 for GD (Gateway Daemon) added new variables:
CTGDFSRV='DEFAULT*SERVER*FOR*GATEWAY'
CTGHOSNM='HOSTNAME*OF GATEWAY*COMPUTER'
CTGIHAEX='CICS*REQUEST*EXIT*CALLS'
CTGISYNC='SYNCONRETURN*FAILS'
CTGLHAEX='CICS*REQUEST*EXIT*CALLS'
CTGLSYNC='SYNCONRETURN*FAILS'
Thanks to Renato Guerra, SGS Banco Popolare di Verona, ITALY.
Thanks to Davide Marone, SGS Banco Popolare di Verona, ITALY.
Change 27.010 Variable SMF70CIX is now output in PDB.TYPE70PR dataset,
VMAC7072 as it is the CPU Pool Number. While it has been INPUT
Feb 16, 2009 for years, it was only used as an index to find out the
engine type of each LCPUADDR, to store into SMF70CIN; it
was Martin's SlideShow that educated me to the fact that
it is also the CPU pool number, and hence worth keeping.
http://www.slideshare.net/MartinPacker/much-ado-about-cpu
Thanks to Martin Packer, IBM, EUROPE.
Change 27.009 -SYSLOG MSGID IEF233D was captured by ASMTAPEE in ML-43,
VMACTMNT last summer, but VMACTMNT was not updated to decode it,
Feb 13, 2009 causing "UNEXPECTED" messages to be printed on the log.
That MSGID is now output by VMACTMNT in TYPESYMT dataset.
Support for IEF233D in ASUMTAPE was already in place.
-SYSLOG messages that do NOT contain DSNAME are created if
your site has NOT specified COM='MONITOR DSNAME' in your
SYS1.PARMLIB(COMMNDxx). This causes either blank DSNAMEs
in PDB.TYPESYMT and PDB.ASUMTAPE, or, it caused DSNAME to
have "MEDIAn", because the SYSLOG MSGID IEC705I was
incorrectly parsed when DSNAME was not populated. The
location of the DSNAME in IEC705I is variable, so MXG's
parsing was revised to only INPUT the SYSLDSN if the text
ends in 'MEDIAx'. A new warning message is printed if the
last field is not MEDIAx, and a warning if the sss field
is blank, so I can validate my parsing of that instance.
Thanks to Yves Cinq-Mars, IBM Global Services, CANADA.
Change 27.008 z/VM 5.2 MONWRITE BROKEN CONTROL RECORD ERROR, because
VMACVMXA MXG unconditionally INPUT variable PFXCPUTY in 4 subtypes
Feb 13, 2009 but the other 8 subtypes input that field conditionally.
These four subtypes are now also conditionally INPUT
(0.1 SYTSYP, 3.2 STORSP, 3.20 STOSXP, 5.3 PRCPRP) based
on the length of the segment.
Thanks to Tom Draeger, Aurora, USA.
Change 27.007 Support for IBM's ENQ/DEQ Monitor was initially added in
FORMATS Change 26.323, but several fields were not documented by
VMACENQM IBM in the DSECT; the ENQFLAG1/ENQFLAG2 are now decoded,
Feb 11, 2009 and the description of ATTR1 bit settings were deduced.
Change 27.006 Several logrec character variables were length $200 due
VMACEREP to that pre-SAS-V8-length-limit, or were input $CHAR200
Feb 14, 2009 but then reduced because of shorter $HEX format length.
These revisions were made:
New SDWA $400. $HEX800. Removed: SDWA1, SDWA1A.
New SDWARC1 $456. $HEX912. Removed: SDWARC1A,1B
New SDWARC2 $16. $HEX32.
New SDWARC3 $32. $HEX64.
New SDWARC4 $360. $HEX720.
New SDWAVRA $255 $HEX510. Removed: SDWAVRA1.
New LXC2SNI $228. $HEX456. Removed: LXC2SNI1,2
Old SLHIRB increased to $HEX128.
Thanks to Ken W. Kasten, Embarq, USA.
Change 27.005 -The _RPDBID macro previously printed PROC FREQ tabulation
BUIL3001 of SMF Record IDs that were read by BUILDPDB (by SYSTEM).
BUILD001 Now, it prints ID+SUBTYPE with the new IDANDSUB variable,
BUILDPD3 e.g., IDANDSUB=110.002 for the ID=110 SUBTYPE=2 records.
BUILDPDB Additionally, the output of the PROC FREQ is now created
MONTHASC in the new PDB.SMFRECNT dataset.
MONTHBL3 -The WEEKly and MONTHly PDB build programs were updated to
MONTHBLD create the SMFRECNT there as well, sorted BY ZDATE.
MONTHBLS -All of the WEEK/MONTH programs are enhanced so that they
MONTHDSK will NOT fail when an expected dataset does NOT exist.
MONTHWEK This means you can implement a new BUILDPDB on any day of
WEEKBL3 the week (previously, the only safe day was to implement
WEEKBL3D on the first day of your week, so all seven day-of-week
WEEKBL3T PDBs had the new dataset for the new WEEKly job.), and on
WEEKBLD any day of the month for the MONTHly job. Now, by using
VMACID SAS OPTIONS NODSNFERR NOVNFERR instead of just NODSNFERR,
Feb 12, 2009 the DATASET-NOT-FOUND is protected by NODSNFERR, and the
BY-VARIABLE-NOT-FOUND is protected by NOVNFERR.
Well, almost: A WARNING: BY VARIABLE NOT FOUND will be
printed on the SAS log, but that warning does not set
_ERROR_, so there is NO return/condition code created,
which is exactly what is desired for this condition.
However, it is inconsistent for a WARNING message to
not set a condition code, but since we do NOT want that
here, SAS Technical Support has said the "WARNING" text
will be changed to "NOTE" in the future.
Thanks to Diane Farias, IBM Global Services, CANADA
Change 27.004 Support for SMF 113 Hardware Instrumentation Services HIS
EXTY113 record, documented in SA23-2260,SA23-2261 and added by
FORMATS APAR OA25755 (and possibly other APARs), creates TYPE113
IMAC113 dataset with six Basic, six Program State, sixteen Crypto
TYPE113 and twenty-four Extended counters of Level One, Two and
TYPS113 Three Data and Instruction Cache activity counts for each
VMAC113 CPU engine. The counts are accumulated, so the TYPS113
VMXGINIT member, which does the de-accumulation in the _S113 SORT
Feb 8, 2009 macro, must be used, or with BUILDPDB, you must add the
_S113 product sort macro in your EXPDBOUT member.
Thanks to IBM z/OS Developer Support Program for providing SMF data!!
Change 27.003 Support for Tivoli Automation SMF 114 record.
EXTY114 Creates new TYPE114 dataset from subtype 1 record.
FORMATS This was originally completed on Jan 11, 2009, as Change
IMAC114 26.298, but I accidentally re-used/overwrote that change
TYPE114 text. The was no change to the code delivered in 26.26.
TYPS114
VMAC114
VMXGINIT
Jan 11, 2009
Feb 9, 2009
Thanks to Siegfried Trantes, Gothaer Systems GmbH, GERMANY.
Change 27.002 -Original MXG 26.26 ONLY. Corrected in Feb 12 Version.
READDB2 -READDB2 in MXG 26.26: might not create all datasets that
Feb 11, 2009 you requested, and could impact ANALDB2R(PDB=SMF,...) as
Feb 16, 2009 the READDB2 member is invoked by ANALDB2R to read SMF.
Feb 17, 2009 Last minute changes for IFCID=255 and DB2STAT4 were made
Feb 20, 2009 but validation focused only on that correction.
-If VMXGTIME was being used, when READDB2 tried to resolve
a local macro variable it got a bad value placed in a
local macro variable by VMXGTIME. This generated a
WARNING: MACRO VARIABLE NOT RESOLVED. The macro variable
name was changed in READDB2 to prevent the conflict.
-The Second READDB2 in the re-dated MXG 26.26 could fail
if the DB2= operand was used to select DB2 SubSystems.
Fortunately (for me!), this caused an actual 180 ERROR
condition before any data was read, so it was NOT like
the first (insidious) error that you could overlook until
you tried to read a non-created DB2 dataset, thus this
error did not require another refresh! But the revision
revealed an unrelated/unreported inconsistency with the
documentation, if you had multiple selection criteria,
like %READDB2(DB2=DB2X DB2Y, PLAN=PLANA PLANB). Those
criteria were ORed, so all PLANs from DB2X or DB2Y were
selected, plus all subsystems with PLANA or PLANB were
also selected. The logic is now revised to AND all of
the selection criteria, so now only PLANA or PLANB from
only either DB2X or DB2Y would be selected.
And, a cosmetic change was made so that the selection
criteria are printed on the SAS log, so you can see what
was requested.
-A pair of additional errors were also corrected. Only
DB2ACCTP was created from ACCOUNT if IFCIDS=ALL was used,
and calling READDB2 from ANALDB2R could cause this error:
DATA=ZZDB2PST; %
ERROR: OLD-STYLE MACRO NAME % MUST CONTAIN ONLY
LETTERS, DIGITS, AND UNDERSCORES.
-May 20: Writing SMFOUT on PC's &RECFM corrected.
-May 24: The T102S225, DB2STAT4, IFCID=225 building was
significantly redesigned in Change 27.097.
Thanks to Raff Rushton, Kaiser Foundation Hospitals, USA.
Thanks to Scott Chapman, American Electric Power, USA.
Thanks to Tony Curry, BMC, USA.
Change 27.001 MXG 26.26 ONLY: PDB.RMFINTRV negative PCTCPUBY: HiperDisp
VMXGRMFI But ONLY if HiperDispatch is active, plus negative values
Feb 11, 2009 in variables PCTOVHTD CPUACTTM CPUOVHTM MSUINTRV MSUPERHR
MSU4HRAV and PCTOFHDW. A recalculation of CPUACTTM was
not tested with RMF data with HiperDispatch active (i.e.,
when SMF70PAT/CPUPATTM were GT zero). That recalculation
was removed by this change.
Thanks to Chuck Hopf, Bank of America, USA.
LASTCHANGE: Version 27.
=========================member=CHANGE26================================
/* COPYRIGHT (C) 1984-2009 MERRILL CONSULTANTS DALLAS TEXAS USA */
Final MXG Version 26.26 was dated Feb 12, 2009, thru Change 26.326
First MXG Version 26.26 was dated Feb 3, 2009, thru Change 26.325
MXG Version 26.26 is the 2009 "Annual Version".
MXG Newsletter FIFTY-THREE is dated Feb 3, 2009
MXG Version 26.12 was dated Jan 20, 2009, thru Change 26.308
MXG Version 26.11 was dated Jan 5, 2009, thru Change 26.296
MXG Version 26.10 was dated Dec 1, 2008, thru Change 26.271
MXG Version 26.09 was dated Oct 20, 2008, thru Change 26.240
MXG Version 26.08 was dated Sep 12, 2008, thru Change 26.209
MXG Newsletter FIFTY-TWO was dated Aug 24, 2008
MXG Version 26.07 was dated Aug 24, 2008, thru Change 26.197
MXG Version 26.06 was dated Aug 6, 2008, thru Change 26.176
Third MXG Version 26.06 was dated Aug 5, 2008, thru Change 26.175
Second MXG Version 26.06 was dated Aug 4, 2008, thru Change 26.173
First MXG Version 26.06 was dated Aug 1, 2008, thru Change 26.172
MXG Version 26.05 was dated Jun 18, 2008, thru Change 26.140
MXG Version 26.04 was dated Jun 4, 2008, thru Change 26.120
MXG Version 26.03 was dated May 11, 2008, thru Change 26.095
First MXG Version 26.03 was dated May 8, 2008, thru Change 26.093
MXG Version 26.02 was dated Apr 22, 2008, thru Change 26.075
MXG Version 26.01 was dated Mar 11, 2008, thru Change 26.037
First MXG 26.01 was dated Mar 10, 2008, thru Change 26.036
MXG Version 25.25 was dated Jan 28, 2008, thru Change 25.309
MXG 25.25 was last year's 2008 "Annual Version", dated January 28, 2008.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/ship_current_version
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 26.26 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 26.26.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================
I. MXG Version 26.26, dated Feb 3, 2009, the 2009 Annual Version.
Major enhancements added in MXG 26.26, dated Feb 3, 2009
TYPEDB2 26.311 DB2STATS4-IFCID=225 in DB2 V9 correction/additions.
TYPE23 26.312 Support for APAR OA27163, new interval variables.
TYPEOMMQ 26.319 Support for Omegamon XE MQ Export File
TYPEENQM 26.323 Support for IBM's ENQ/DEQ Monitor flat file.
ASMTAPEE 26.317 Enhanced SYSLOG message capture, MSGIDs read from DD.
TYPETMDB 26.313 New subtypes for TMON for DB2 V4 and V4.1.
READDB2 26.311 TEXT EXPRESSION LENGTH (65545) EXCEEDS corrected.
VMXGINIT 26.310 The MXGWORK= argument of VMXGINIT is removed.
TYPE70 26.308 TYPE70 PARTNICF/IFA/IFL/ZIP variables added.
TYPEACF2 26.324 Enhancement for ACF2 support to add IHDRACF2 exit.
UTILCVRT 26.322 UTILCVRT utility for z/OS to ASCII conversion revised
Major enhancements added in MXG 26.12, dated Jan 20, 2009
Many 26.300 Conflict Resolution, variables RE-NAMed,RE-LENGTHed
ANALZPCR 26.297 Execution errors in mismatched Tags corrected.
TYPE72GO 26.299 MXG 26.10-26.11. PERFINDX missing for R723TYPE=2.
RMFINTRV 26.303 Capture Ratios for zAAPs,zIIPs added to PDB.RMFINTRV
TYPE102 26.298 DB2 IFCID=22 INPUT STATEMENT EXCEEDED error fixed.
FORMATS 26.304 Internal format $MGUTILD for DOCVER created.
Major enhancements added in MXG 26.11, dated Jan 5, 2009
Many 26.289 QA Cleanup, variable LENGTHs changed, zdate added.
VMXGPRAL 26.293 Print all datasets with variable name + label heading
TYPERMFV 26.287 Support for RMF III CPUG3 z/OS 1.9 (INCOMPAT).
TYPE92 26.277 Support for APAR OA24208 new subtype 15 for ID=92.
TYPEOPCN 26.280 Support for Open Connect user SMF record.
ANALZPCR 26.283 zPCR failed with z/OS V1R9. SELECT=CECTIME supported.
IMACICMD 26.284 BMC Optional CMRDB2 segment increased to 256 INCOMPAT
TYPENMON 26.279 DISKSERV,DISKWAIT,MEMPAGESxxx supported, some fixes.
TYPE78 26.288 TYPE78CU variables for Aliases could be wrong.
ASUMUOW 26.282 APPLID could be blank in PDB.ASUMUOW.
BUILDPDB 26.281 IFAUNITS,IFEUNITS added to PDB.STEPS and PDB.JOBS.
ANALDBJO 26.278 Example analysis JOins DB2ACCT + DB2ACCTP, expensive.
TYPE72GO 26.276 Negative one value for CPUUNITS due to resolution.
BLDSMPDB 26.275 New WEK2KEEP=,MTH2KEEP= controls for keeping PDBs.
TYPEDB2 26.274 Some DB2 V9-only QWACxxxx vars were INPUT with V8.
TYPEXAM 26.272 Variable SIZE in HSTMEM incorrectly INPUT, is RB4.
Major enhancements added in MXG 26.10, dated Dec 1, 2008
ANALZPCR 26.264 Support for IBM zPCR model input from MXG PDB data.
PDB TYPE70,TYPE70PR,TYPE74 are read to create "External Study" files
for input to IBM's capacity modeling tool; by default, MXG selects
the RMF interval from each system with peak CPU usage to be modeled.
This should make your use of IBM's excellent zPCR tool even easier!
TYPE70 26.270 NRCPUS redefined, online-non-parked, value changed.
TYPE70PR 26.243 Support for OA21140 RMF HiperDispatch enhancements.
Because of these changes MXG 26.10 is now required for HiperDispatch
TYPE73 26.243 Support for OA21140 zHPF High Performance FICON.
TYPE120 26.262 Support for WebSphere Version 7, new subtype 9 data.
TYPEMVCI 26.254 Support for MAINVIEW for CICS 6.1 CMRDETL (INCOMPAT).
TYPEBVIR 26.250 Support for eight clusters in BVIR33 dataset.
TYPEHSM 26.249 Sorting HSM ABARS datasets caused NOT SORTED errors.
TYPE113 26.247 SMF 113 data records needed to finish support.
TYPE70 26.269 CPUWAIxx/MVSWAIxx for CP Engines 33-63 were missing.
TYEPRMFV 26.246 RMF III ASIPHTxx SRB CPU times wrong by x1000.
TYPETPMX 26.245 ERROR VARNAME=$JXSLMJ_ in Thruput Mgr SMF corrected.
GRAFWRKX 26.244 MIPS was not calculated for WORKLOAD=0, uncaptured.
ANALDB2R 26.256 %ANALDB2R(PDB=SMF); failed with error.
VMXGOPTR 26.242 Internal utility enhanced for multiple options.
TYPEVMXA 26.241 LINUXKRNL '02'x caused BROKEN CONTROL RECORD error.
TYPE112 26.257 TYPE112 now reads both V550 & V560 subtype 203 data.
TYPEOMCI 26.257 TYPEOMCI supports subtype 200,201,203, but only V550.
VMXGINIT 26.252 Forward Slash in a unix libref for WORK supported.
TYPECTLG 26.255 Enhancements to processing Catalog records.
Many 26.252 %QUPCASE(xxx) vs %UPCASE for forward slash protect.
Many 26.259 QA Stream revised to eliminate return code & warnings
WPS 26.258 WPS 2.3.4 now required for MXG, ARRAY(256,512) error.
Major enhancements added in MXG 26.09, dated Oct 20, 2008
TYPE70 26.236 HiperDispatch CPUPATTM, PCTMVSBY can be wrong TYPE70.
TYPE7072 26.222 Large CPUIFATM IFAUNITS when op varied CP on/offline.
ASUMMIPS 26.216 ZIPUSED MSU was incorrect, ZIP/ZAP metrics fixed.
TYPENMON 26.224 NMON variables without decimal point may be wrong.
TYPESVC 26.221 Support for IBM DS8000 2107 SAN Disk SVCPerfStats.
TYPENTSM 26.213 Support for new data in NTDS and ASP.NET App objects.
TYPETMDB 26.210 Support for ASG/Landmark DB2 Monitor V4.1 raw data.
TYPETNG 26.223 Support for NSM VMWARE ESX 2.5.5 new objects.
FORMATS 26.231 MEMLIMIT '00000FFFFFFFF000'x value is NOLIMIT.
READDB2 26.233 Dataset DB2STAT4 and T102S225 created for IFCID=225.
ASUMSTGP 26.228 Example to report DASD storage by Storage Group.
TYPERMFV 26.218 RMF III ASIRNM,ASIRDE (reporting class) names blank.
TYPENDM 26.215 NDM-CDI subtype 'UC' is now output in NDMAE.
TYPE1415 26.214 Invalid extended segment protection enhanced.
UPRINDOC 26.238 Utility to PROC PRINT the LABEL and VARIABLE NAME.
Major enhancements added in MXG 26.08, dated Sep 12, 2008
TYPEVMXA 26.203 Support for z/VM 5.4 (COMPATIBLE with MXG 25.04+).
TYPEDB2 26.201 Support for DB2 V9.1 SMF 100,101 (COMPAT MXG 25.25+)
TYPE1415 26.199 INVALID SMF1415 RECORD, even with Change 25.228, fix.
TYPEBVIR 26.198 All BVIR32 Pool 00-31 are now Pool 01-32 variables.
TYPETPMX 26.207 Support for Thruput Manager Subtype 7, new fields.
IMACICMR 26.206 Optional BMC CMRDATA increased in CICS/TS 3.2.
WEEKBLDT 26.205 SYSNAME incorrectly added to BY List for TYPE892.
TYPESHDW 26.204 Support for new subtypes, fields Shadow USER SMF.
BUILDPDB 26.208 Variables SMF30MLS, MEMLIMIT now kept in PDB.STEPS.
Major enhancements added in MXG 26.07, dated Aug 24, 2008
TYPE7072 26.071 Support for z/OS 1.10 (INCOMPAT, due to MXG code).
MXG code that protected an earlier IBM error in the number of
triplets caused z/OS 1.10 TYPE72GO to have zero observations,
so MXG 26.07 is REQUIRED to support z/OS 1.10 records. Sorry!
MXGSAS92 26.191 New JCL proc for SAS V9.2 with new z/OS DSNAMES.
VMXGINIT 26.189 SAS V9.2 Hot Fix F9BA07 eliminates new WARNINGs
MXG Version 26.03+ provided circumvention for new WARNING messages
that set condition Code 4 with SAS V9.2, but SAS Hot Fix F9BA07
now eliminates the need for that MXG circumvention.
TYPE42 26.187 Support for APAR OA25205 adds SMF 42 subtypes, data.
TYPEINSY 26.182 Support for MACRO4 INSYNC SMF user record.
ASMIMSL6 26.190 Support for IMS Log record 0A (CPI-CI Drive PGM).
TYPEIMS7 26.190 Support for IMS Log record 0A (CPI-CI Drive PGM).
ASUMCEC 26.188 HiperDispatch subtracts SMF70PAT from SMF70ONT
ASUMDB2P 26.183 Revised summary/trending of DB2ACCTP example.
TYPERMFV 26.178 RMF III z/OS 1.9 changed length of ASI segment.
Major enhancements added in MXG 26.06, dated Aug 6, 2008
ASMTAPEE 26.148 MXGTMNT ML-43 captures IEF233D mount event, improved.
UNDUPSMF 26.152 Utility removes duplicate SMF records, output is VBS.
RMFINTRV 26.165 New RMFWKLRV: RMFINTRV Workload-only dataset created.
TYPEQACS 26.166 Support for AS/400 Version 6.1.0 (COMPATIBLE).
TYPETPF 26.163 Support for TPF PUT22 changes, and corrections.
TYPEOMCI 26.160 Support for Omegamon CICS User records in SMF 112.
TYPE99 26.155 Support for SMF 99 Subtype 11 Group Capacity Limits.
TYPE28 26.151 Support for APAR OA24416, 'D6'x NPM record.
TYPEMVCI 26.145 Support for BMC Mainview CICS CMRTYPE=109 (ABENDS).
TYPETNG 26.172 Support for NSM VMware Virtual Center 2.5 Servers.
TYPEDCOL 26.142 DCOLDSET identifies 'HFS' and 'PDSE' datasets.
TYPETMS5 26.161 New BESKEY variable identifies encrypted CA-1 tapes.
TYPERMFV 26.150 SPG variables too small due to typo.
TYPEBVIR 26.143 TS7700 Statistical dataset BVIR32 was trashed.
TYPE110 26.141 CICS STID=74 dataset CICIMQ ERROR message removed.
BUILDPD3 26.164 JES3 BUILDPD3 variable JOBCLASS could be blank.
WEEKxxxx 26.157 NOTSORTED condition due to inconsistent BY lists.
TYPE77 26.139 TYPE77 QUEUE1-QUEUE4 were wrong, over 100%.
TYPE70PR 26.154 SMF70LAC missing in PDB.TYPE70PR after offline LPAR.
Major enhancements added in MXG 26.05, dated Jun 18, 2008
TYPESVIE 26.133 Support for CA SYSVIEW, CICS, IMS, MVS in one member.
replaces partial support (2005) TYPESYSV, TYPESYSI.
ASMTAPEE 26.135 ML-42 of MXGTMNT, backs out JOB error in ML-41.
ASUMTAPE 26.122 SYSLOG JOB parse failed with 3 commas in TRANWRD.
TYPETMNT 26.128A Correction for DEFECT in ASMTAPEE ML-41, CRITICAL.
users of MXGTMNT need all three changes above.
ASUMMIPS 26.131 MIPS/MSU analysis adds IFAs/zAAPs and zIIPs MIPS.
TYPEPRPR 26.128 Prisma SMF record change in April was not documented.
TYPENTSM 26.125 Support for BITS NET UTIL, PACER PIPE, USB objects.
TYPENTSM 26.123 Support for new fields in MEMORY, PROCESS objects.
TYPEOMAU 26.121 Support for OMEGAMON Audit Records in CICS record.
TYPE120 26.126 WebSphere allocfails wrong, invalid triplets, st 3.
UTILEXCL 26.130 Documentation for IMACICEZ/E1/E2 tailoring enhanced.
VMACDB2 26.136 Corrections to IFCID 119 and IFCID 225 variables.
Major enhancements added in MXG 26.04, dated Jun 4, 2008
TYPE70 26.112 26.03: TYPE70 CPUMVSTM/PCTMVSBY/SHORTCPS missing.
TYPE74 26.117 TYPE747C was missing most observations, now enhanced.
TYPE42 26.103 INPUT EXCEEDED ID=42 SUBTYPE=15 if more than one S2.
TYPE23 26.116 Support for APAR OA22414 new variables.
TYPETMVS 26.111 Full support for TMVS Release 4.1, INCOMPATIBLE.
TYPEINFO 26.098 Support for Informatics STAT user SMF record.
TYPE80A 26.107 INPUT EXCEEDED due to new ASSIZMAX in TOKDANAM.
TYPE7xxx 26.115 Inconsistent BY list for RMF data are now consistent.
TYPETMNT 26.103 TYPETASK='J ' in TYPETMNT corrected in VGETJEXN.
TYPEVMXA 26.114 MONWRITE BAD CONTORL RECORD, with 6.24 record
MONTHxxx 26.115 Inconsistent BY list for RMF data are now consistent.
WEEKxxxx 26.115 Inconsistent BY list for RMF data are now consistent.
Major enhancements added in MXG 26.03, dated May 11, 2008
==Support for SAS Version 9.2: COMPATIBLE, no ERRORS, new WARNings==
See revised note for Hot Fix F9BA07 in MXG 26.07 Major Enhancements
All recent MXG Versions execute WITHOUT error with SAS Version V9.2.
V9.2 libraries are read/written by SAS V8.2 or V9.1.3, & vice versa.
SAS V9.2 Phase I Foundation Level on z/OS and ASCII SAS was tested.
These MXG Versions WILL print a new SAS V9.2 WARNING, that sets CC=4
(condition/return code), but that warning is harmless (to MXG code),
so all MXG output SAS datasets are correct, even with that warning.
So the ONLY exposure with prior MXG Versions under V9.2 is on z/OS,
and ONLY if condition code tests are used in your MXG jobstreams.
This new-in-SAS V9 "MULTIPLE LENGTHS OF A VARIABLE" warning message
surfaced in MXG delivered code primarily in these two cases:
a.The intended shortening of the LENGTH of a numeric variable, but
only when the LENGTH statement precedes the SET/MERGE/UPDATE.
This occurs in VMXGSUM where the fixed-length-8 variables output
by PROC MEANS were reduced to 4-bytes, prior to option KEEPLEN.
The VMXGSUM utility is invoked in all MXG summarization, like
ASUMxxxx and TRNDxxxx, many ANALxxxx members, and in summarizing
RMFINTRV and CICINTRV programs included in BUILDPDB.
It is pervasive in MXG.
MXG Version 26.03 relocated its LENGTH statement to eliminate.
b.A JOIN of multiple datasets (SET MON.JOBS TUE.JOBS ...) where
a variable has different lengths in different datasets.
This also occurs in VMXGSUM, when multiple input datasets are to
be combined, like TRENDing, where TREND had shortened LENGTHs
but the "NEWTREND" internally has fixed, pre-KEEPLEN LENGTHs.
MXG 26.03 adds KEEPLEN option to PROC MEANS to eliminate.
MXG Version 26.03 eliminated the new SAS V9.2 WARNING internally,
in all MXG code members that generated that message.
In member VMXGINIT:
Change 26.065 (MXG 26.03) added OPTION VARLENCHK=NOWARN.
Change 26.189 (MXG 26.07) removed that option.
Without VARLENCHK=NOWARN, EVEN at 26.03+V9.2 the WARNING can OCCUR:
a. If you have tailoring members in "USERID.SOURCLIB" from old MXG
versions, that need the same code revisions to eliminate.
b. In user-written SAS programs, this could actually be a valid
warning that a variable was truncated.
or, at any time in the future, the WARNING can still occur:
c. When an MXG Version that changed variable LENGTHs is installed,
subsequent WEEKLY or MONTHLY jobs create the WARNING because
some PDB's have the old length and some have the new length,
when those multiple datasets are joined. Previous to V9.2,
length were changed with no WARNING nor CC. Between MXG 24.24
and 25.25 1206 variable's lengths were changed.
The Hot Fix is F9BA07.
Changes 26.191,26.189,26.090,26.078,26.065,26.060 have V9.2 details.
Note: Originally, MXG 26.02 claimed it supported V9.2, but changes
26.078 and 26.090 are required to eliminate the new WARNING
in MXG-delivered code, but there were no errors in 26.02/9.2.
VMXGSUM 26.090 Support for SAS V9.2 - See 26.078, 26.065, 26.060.
VMXGSUM 26.078 26.02 ONLY - VARIABLE NOT FOUND corrected.
ASUMTAPE 26.083 MAJOR rewrite of ASUMTAPE matches more, adds SPIN.
ASMTAPEE 26.095 ML-41 of MXGTMNT, TYPEARCV Allocation Recovery event
TYPEAFOP 26.086 Support for AF/Operator SMF record.
TYPECTMU 26.089 Support for Control-M log records on unix/open sys.
TYPECTMZ 26.089 Support for Control-M log records on z/OS.
TYPE112 26.088 Support for SMF 112 MQ segment (subtype 0200x).
ANALHSM 26.084 New MIGRATE/RECALL/BACKUP HSM report example added.
TYPE30 26.077 Negative CPUUNITS from zAAPs calculations eliminated.
Major enhancements added in MXG 26.02, dated Apr 22, 2008
Doc 26.060 Cosmetic SAS V9.2 differences with SAS V9.1.3.
TYPE7072 26.039 Support for APAR OA24074, corrected Parked Time.
ANALACTM 26.064 Implementation of Rich Olcott's The ACTuals Map.
TYPEACF2 26.051 Support for ACF2 Release 6.2.
TYPEMGCR 26.047 Support for Version 6 of MegaCryption SMF record.
IMAC6ESS 26.046 Support for GPARMKY=0050x ESSPRTA variable.
TYPEIMS7 26.045 Support for IMS Version 10 '08'x Log Record.
TYPECIMS 26.058 IMF dataset TYPECIMS variable INPUTCLS corrected.
Major enhancements added in MXG 26.01, dated Mar 11, 2008
TYPE7072 26.025 Support for APAR OA12774 new z10 RMF data (COMPAT).
MXG 25.25 supports the z10 hardware platform, but
did not know about this new APAR with TYPE70 data.
TYPE7072 26.031 Support/Correction Dedicated zAAPs/Dedicated zIIPs.
TYPE7072 26.006 Support for 64 CP Engines.
TYPE78CU 26.023 MXG 25.07-25.25. Last LCUID not output in TYPE78CU.
TYPE79 26.036 R723RCUT was .062 when it should have been 62.
TYPEIMSA 26.026 Support for new variables in IMS Version 9 and 10.
TYPEHSM 26.028A HSM FSR updated for z/OS 1.8 and 1.8 new variables.
TYPE102 26.011 Support for IFCID 22 APAR PK38803.
TYPEMPLX 26.014 IMPLX Version 4.1 is now supported.
VMXGINIT 26.012 SOURCLIB,SASAUTOS dsnames now printed at MXG INIT.
TYPE110 26.007 CICDS Dispatcher Statistics and PCTREGBY created.
ASUM70PR 26.003 LPARCPUS in ASUM70PR summary is not always integer.
TYPERMFV 26.032 Debugging PUT statement removed.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
MXG 26.26 executes with SAS V8.2 or SAS V9.1.3 or SAS V9.2, on any
supported platform. It has not executed under SAS V6 in years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
one of those listed SAS versions, but any of those data libraries
can be read or updated by any of those versions.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, new DSNAMES for SAS libraries are in the new MXGSAS92
JCL procedure example.
All recent MXG Versions execute WITHOUT error with SAS Version
V9.2. V9.2 libraries are read/written by SAS V8.2 or V9.1.3, &
vice versa.
Without SAS Hot Fix F9BA07, MXG versions prior to 26.03 will
print a new SAS V9.2 WARNING, that sets CC=4 (condition/return
code), but that warning is harmless (to MXG code) so all MXG
output SAS datasets are correct, even with that warning. So the
ONLY exposure with prior MXG Versions is only on z/OS, only if
condition code tests are used in your MXG jobstreams.
For SAS V9.1.3 on z/OS with Service Pack 4:
There are no reported errors, and MXG's CONFIGV9 now specifies
V9SEQ instead of V6SEQ. As V6SEQ does not support long length
character variables, it should not be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) is required
to be completely safe. No earlier Version 8's were supported.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG 26.09 QA tests were executed on z/OS with SAS V9.1.3 and V9.2
and also both V9.1.3 and V9.2 on Windows XP.
(I can no longer run QA tests with "archaic" SAS Version 8.2.)
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.3.4 is required for MXG. See Change 26.258.
See NEWSLETTERS for "MXG Support for WPS Software"
IV. MXG Version Required for Hardware, Operating System Release, etc.
Availability dates for the IBM products and MXG version required for
the processing of that product's data records:
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
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
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 26.08
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
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 20.04
The Monitor for DB2 Version 4.0 22.10
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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including cics/ts 3.1 22.08
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
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 25.04
V. Incompatibilities and Installation of MXG 26.26.
1. Incompatibilities introduced in MXG 26.26:
a- Changes in MXG architecture made between 26.26 and prior versions
that can introduce known incompatibilities.
ASUMTAPE: You must delete SPIN.SPINMOUN before using the revised
ASUMTAPE program. See change 26.083.
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 Version 9.1.3 (JCLINST8 for now-archaic SAS Version 8.2).
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT 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.
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.
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.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. 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 in MXG 26.26 after MXG 25.25:
Dataset/
Member Change Description
ANALACTM 26.064 Implementation of Rich Olcott's The ACTuals Map.
ANALDB2R 26.256 %ANALDB2R(PDB=SMF); failed with error.
ANALDBJO 26.278 Example analysis JOins DB2ACCT + DB2ACCTP, expensive.
ANALHSM 26.084 New MIGRATE/RECALL/BACKUP HSM report example added.
ANALZPCR 26.283 zPCR failed with z/OS V1R9. SELECT=CECTIME supported.
ANALZPCR 26.297 Execution errors in mismatched Tags corrected.
ASMIMSL6 26.190 Support for IMS Log record 0A (CPI-CI Drive PGM).
ASMTAPEE 26.095 ML-41 of MXGTMNT, TYPEARCV Allocation Recovery event
ASMTAPEE 26.095 ML-41 of MXGTMNT, TYPEARCV Allocation Recovery event
ASMTAPEE 26.135 ML-42 of MXGTMNT, backs out JOB error in ML-41.
ASMTAPEE 26.148 MXGTMNT ML-43 captures IEF233D mount event, improved.
ASMTAPEE 26.317 Enhanced SYSLOG message capture, no reassembly.
ASUM70PR 26.003 LPARCPUS in ASUM70PR summary is not always integer.
ASUM70PR 26.031 Support/Correction Dedicated zAAPs/Dedicated zIIPs.
ASUM70PR 26.041 Default INTERVAL in ASUM70PR restored to QTRHOUR.
ASUMCEC 26.188 HiperDispatch subtracts SMF70PAT from SMF70ONT
ASUMDB2P 26.183 Revised summary/trending of DB2ACCTP example.
ASUMMIPS 26.131 MIPS/MSU analysis adds IFAs/zAAPs and zIIPs MIPS.
ASUMMIPS 26.216 ZIPUSED MSU was incorrect, ZIP/ZAP metrics fixed.
ASUMSTGP 26.228 Example to report DASD storage by Storage Group.
ASUMTAPE 26.083 MAJOR rewrite of ASUMTAPE corrects errors, adds SPIN.
ASUMTAPE 26.122 SYSLOG JOB parse failed with 3 commas in TRANWRD.
ASUMUOW 26.282 APPLID could be blank in PDB.ASUMUOW.
BLDSMPDB 26.275 New WEK2KEEP=,MTH2KEEP= controls for keeping PDBs.
BUILDPD3 26.164 JES3 BUILDPD3 variable JOBCLASS could be blank.
BUILDPDB 26.208 Variables SMF30MLS, MEMLIMIT now kept in PDB.STEPS.
BUILDPDB 26.281 IFAUNITS,IFEUNITS added to PDB.STEPS and PDB.JOBS.
Doc 26.060 Cosmetic SAS V9.2 differences with SAS V9.1.3.
FORMATS 26.231 MEMLIMIT '00000FFFFFFFF000'x value is NOLIMIT.
FORMATS 26.304 Internal format $MGUTILD for DOCVER created.
GRAFWRKX 26.244 MIPS was not calculated for WORKLOAD=0, uncaptured.
IEBUPDTE 26.235 INFILE option TERMSTR=CRLF reads unix LF-only files.
IMAC6ESS 26.046 Support for GPARMKY=0050x, new ESSPRTAT variable.
IMACICMD 26.284 BMC Optional CMRDB2 segment increased to 256 INCOMPAT
IMACICMR 26.206 Optional BMC CMRDATA increased in CICS/TS 3.2.
MONTHBL3 26.293 NOT SORTED for JES3 MONTHBL3.
MONTHxxx 26.115 Inconsistent BY list for RMF data are now consistent.
MXGSAS92 26.191 New JCL Proc for SAS V9.2, new z/OS DSNAMES.
Many 26.065 Support for no-WARNING execution under SAS V9.2.
Many 26.252 %QUPCASE(xxx) vs %UPCASE for forward slash protect.
Many 26.259 QA Stream revised to eliminate return code & warnings
Many 26.289 QA Cleanup, variable LENGTHs changed, zdate added.
Many 26.300 Conflict Resolution, variables RE-NAMed,RE-LENGTHed
READDB2 26.233 Dataset DB2STAT4 and T102S225 created for IFCID=225.
READDB2 26.311 TEXT EXPRESSION LENGTH (65545) EXCEEDS corrected.
RMFINTRV 26.165 New RMFWKLRV: RMFINTRV Workload-only dataset created.
RMFINTRV 26.295 New WKLDIOCN and WKLDIORT variables added to RMFWKLRV
RMFINTRV 26.303 Capture Ratios for zAAPs,zIIPs added to PDB.RMFINTRV
TYEPRMFV 26.246 RMF III ASIPHTxx SRB CPU times wrong by x1000.
TYPE102 26.011 Support for IFCID 22 APAR PK38803.
TYPE102 26.096 Variables QW0227FG/PG were always missing.
TYPE102 26.298 DB2 IFCID=22 INPUT STATEMENT EXCEEDED error fixed.
TYPE110 26.007 CICDS Dispatcher Statistics and PCTREGBY created.
TYPE110 26.052 Protection for SMF 110 St 2 STID 31 short segments.
TYPE110 26.141 CICS STID=74 dataset CICIMQ ERROR message removed.
TYPE112 26.088 Support for SMF 112 MQ segment (subtype 0200x).
TYPE112 26.257 TYPE112 now reads both V550 & V560 subtype 203 data.
TYPE113 26.247 SMF 113 data records needed to finish support.
TYPE119 26.067 ID=119 ST=21 INPUT STATEMENT EXCEEDED, NTHOSTTN short
TYPE120 26.126 WebSphere allocfails wrong, invalid triplets, st 3.
TYPE120 26.262 Support for WebSphere Version 7, new subtype 9 data.
TYPE1415 26.199 INVALID SMF1415 RECORD, even with Change 25.228, fix.
TYPE1415 26.214 Invalid extended segment protection enhanced.
TYPE23 26.116 Support for APAR OA22414 new variables.
TYPE23 26.312 Support for APAR OA27163, new interval variables.
TYPE28 26.151 Support for APAR OA24416, 'D6'x NPM record.
TYPE30 26.077 Negative CPUUNITS from zAAPs calculations eliminated.
TYPE42 26.103 INPUT EXCEEDED ID=42 SUBTYPE=15 if more than one S2.
TYPE42 26.187 Support for APAR OA25205 adds SMF 42 subtypes, data.
TYPE70 26.112 26.03: TYPE70 CPUMVSTM/PCTMVSBY/SHORTCPS missing.
TYPE70 26.236 HiperDispatch CPUPATTM, PCTMVSBY can be wrong TYPE70.
TYPE70 26.269 CPUWAIxx/MVSWAIxx for CP Engines 33-63 were missing.
TYPE70 26.270 NRCPUS redefined, online-non-parked, value changed.
TYPE70 26.308 TYPE70 PARTNICF/IFA/IFL/ZIP variables added.
TYPE7072 26.025 Support for APAR OA12774 new z10 variables (COMPAT).
TYPE7072 26.031 Support/Correction Dedicated zAAPs/Dedicated zIIPs.
TYPE7072 26.039 Support for APAR OA24074, corrected Parked Time.
TYPE7072 26.0781 Support for z/OS 1.10 (INCOMPAT, due to MXG code).
TYPE7072 26.222 Large CPUIFATM IFAUNITS when op varied CP on/offline.
TYPE70PR 26.154 SMF70LAC missing in PDB.TYPE70PR after offline LPAR.
TYPE70PR 26.243 Support for OA21140 RMF HiperDispatch enhancements.
TYPE71 26.069 TYPE71 HIUICMN,HIUICMX had wrong UIC values.
TYPE72GO 26.276 Negative one value for CPUUNITS due to resolution.
TYPE72GO 26.299 MXG 26.10-26.11. PERFINDX missing for R723TYPE=2.
TYPE73 26.243 Support for OA21140 zHPF High Performance FICON.
TYPE74 26.115 RMF BYLIST is SYSPLEX SYSTEM SYSNAME STARTIME.
TYPE74 26.117 TYPE747C was missing most observations, now enhanced.
TYPE77 26.139 TYPE77 QUEUE1-QUEUE4 were wrong, over 100%.
TYPE77 26.271 INVALID THIRD ARGUMENT TO FUNCTION SUBSTR in RMF 77.
TYPE78 26.288 TYPE78CU variables for Aliases could be wrong.
TYPE78CU 26.023 MXG 25.07-25.25. Last LCUID not output in TYPE78CU.
TYPE79 26.036 Variable R793CUT was 0.062, should have been 62.
TYPE80A 26.107 INPUT EXCEEDED due to new ASSIZMAX in TOKDANAM.
TYPE92 26.277 Support for APAR OA24208 new subtype 15 for ID=92.
TYPE99 26.155 Support for SMF 99 Subtype 11 Group Capacity Limits.
TYPEACF2 26.051 Support for ACF2 Release 6.2.
TYPEACF2 26.324 Enhancement for ACF2 support adds IHDRACF2 exit.
TYPEAFOP 26.086 Support for AF/Operator SMF record.
TYPEBVIR 26.018 BVIR30 now contains both PG0 and Preference Grp 1.
TYPEBVIR 26.143 TS7700 Statistical dataset BVIR32 was trashed.
TYPEBVIR 26.198 All BVIR32 Pool 00-31 are now Pool 01-32 variables.
TYPEBVIR 26.250 Support for eight clusters in BVIR33 dataset.
TYPECIMS 26.058 IMF dataset TYPECIMS variable INPUTCLS corrected.
TYPECTLG 26.255 Enhancements to processing Catalog records.
TYPECTMU 26.089 Support for Control-M log records on unix/open sys.
TYPECTMZ 26.089 Support for Control-M log records on z/OS.
TYPEDB2 26.201 Support for DB2 V9.1 SMF 100,101 (COMPAT MXG 25.25+)
TYPEDB2 26.274 Some DB2 V9-only QWACxxxx vars were INPUT with V8.
TYPEDB2 26.311 DB2STATS4 for IFCID=225 in DB2 V9 corrections.
TYPEDCOL 26.142 DCOLDSET identifies 'HFS' and 'PDSE' datasets.
TYPEENQM 26.323 Support for IBM's ENQ/DEQ Monitor flat file.
TYPEHSM 26.028A HSM FSR updated for z/OS 1.8 and 1.8 new variables.
TYPEHSM 26.249 Sorting HSM ABARS datasets caused NOT SORTED errors.
TYPEIMS7 26.026 Support for new variables in IMS Version 9 and 10.
TYPEIMS7 26.045 Support for IMS Version 10 '08'x Log Record.
TYPEIMS7 26.190 Support for IMS Log record 0A (CPI-CI Drive PGM).
TYPEIMSA 26.026 Support for new variables in IMS Version 9 and 10.
TYPEINFO 26.098 Support for Informatics STAT user SMF record.
TYPEINSY 26.182 Support for MACRO4 INSYNC SMF user record.
TYPEIPAC 26.290 View Direct subtype 3 record error, needs ptf?
TYPEITRF 26.034 ITRF x'10' INPUT STATEMENT EXCEEDED with LENGTH=251.
TYPEMGCR 26.047 Support for Version 6 of MegaCryption SMF record.
TYPEMPLX 26.014 IMPLX Version 4.1 is now supported.
TYPEMVCI 26.145 Support for BMC Mainview CICS CMRTYPE=109 (ABENDS).
TYPEMVCI 26.254 Support for MAINVIEW for CICS 6.1 CMRDETL (INCOMPAT).
TYPENDM 26.215 NDM-CDI subtype 'UC' is now output in NDMAE.
TYPENMON 26.100 Invalid MEM header record protected.
TYPENMON 26.224 NMON variables without decimal point may be wrong.
TYPENMON 26.279 DISKSERV,DISKWAIT,MEMPAGESxxx supported, some fixes.
TYPENTSM 26.123 Support for new fields in MEMORY, PROCESS objects.
TYPENTSM 26.125 Support for BITS NET UTIL, PACER PIPE, USB objects.
TYPENTSM 26.213 Support for new data in NTDS and ASP.NET App objects.
TYPEOMAU 26.121 Support for OMEGAMON Audit Records in CICS record.
TYPEOMCI 26.160 Support for Omegamon CICS User records in SMF 112.
TYPEOMCI 26.257 TYPEOMCI supports subtype 200,201,203, but only V550.
TYPEOMMQ 26.319 Support for Omegamon XE MQ Export File
TYPEOPCN 26.280 Support for Open Connect user SMF record.
TYPEPRPR 26.128 Prisma SMF record change in April was not documented.
TYPEQACS 26.166 Support for AS/400 Version 6.1.0 (COMPATIBLE).
TYPERACF 26.022 TYPERACF supports ASCII execution with EBCDIC ftp.
TYPERMFV 26.032 Debugging PUT statement removed.
TYPERMFV 26.053 Calculations of ASIxxxxx variables to match RMF.
TYPERMFV 26.150 SPG variables too small due to typo.
TYPERMFV 26.178 RMF III z/OS 1.9 changed length of ASI segment.
TYPERMFV 26.218 RMF III ASIRNM,ASIRDE (reporting class) names blank.
TYPERMFV 26.287 Support for RMF III CPUG3 z/OS 1.9 (INCOMPAT).
TYPESHDW 26.204 Support for new subtypes, fields Shadow USER SMF.
TYPESRDF 26.059 SPDMXUSE is character, SRDMXUPS is new numeric pct.
TYPESVC 26.221 Support for IBM DS8000 2107 SAN Disk SVCPerfStats.
TYPESVIE 26.133 Support for CA SYSVIEW, CICS, IMS, MVS in one member.
TYPETMDB 26.210 Support for ASG/Landmark DB2 Monitor V4.1 raw data.
TYPETMDB 26.313 New subtypes for TMON for DB2 V4 and V4.1.
TYPETMNT 26.103 TYPETASK='J ' in TYPETMNT corrected in VGETJEXN.
TYPETMNT 26.128A Correction for DEFECT in ASMTAPEE ML-41, CRITICAL.
TYPETMS5 26.161 New BESKEY variable identifies encrypted CA-1 tapes.
TYPETMVS 26.111 Full support for TMVS Release 4.1, INCOMPATIBLE.
TYPETNG 26.033 Support for more new VMware Objects in CA NSM.
TYPETNG 26.172 Support for VMware Virtual Center Servers in NSM.
TYPETNG 26.223 NSM VMWARE ESX 2.5.5 new objects supported.
TYPETPF 26.163 Support for TPF PUT22 changes, and corrections.
TYPETPMX 26.207 Support for Thruput Manager Subtype 7, new fields.
TYPETPMX 26.245 ERROR VARNAME=$JXSLMJ_ in Thruput Mgr SMF corrected.
TYPEVMXA 26.114 MONWRITE BAD CONTORL RECORD, with 6.24 record
TYPEVMXA 26.203 Support for z/VM 5.4 (COMPATIBLE with MXG 25.04+).
TYPEVMXA 26.241 LINUXKRNL '02'x caused BROKEN CONTROL RECORD error.
TYPEXAM 26.272 Variable SIZE in HSTMEM incorrectly INPUT, is RB4.
UNDUPSMF 26.152 Utility removes duplicate SMF records, output is VBS.
UPRINDOC 26.238 Utility to PROC PRINT the LABEL and VARIABLE NAME.
UTILBLDP 26.212 SAS V9.2 only, %ELSE %THEN %DO correction overlooked.
UTILBLDP 26.294 SUPPRESS=CICSTRAN or DB2ACCT options added.
UTILCVRT 26.322 UTILCVRT utility for z/OS to ASCII conversion revised
UTILEXCL 26.130 Documentation for IMACICEZ/E1/E2 tailoring enhanced.
VMACDB2 26.136 Corrections to IFCID 119 and IFCID 225 variables.
VMXGCAPT 26.001 Typo VMUM corrected to VWUM.
VMXGINIT 26.012 SOURCLIB,SASAUTOS dsnames now printed at MXG INIT.
VMXGINIT 26.189 SAS V9.2 Hot Fix F9BA07 eliminates new WARNINGs
VMXGINIT 26.252 Forward Slash in a unix libref for WORK supported.
VMXGINIT 26.310 The MXGWORK= argument of VMXGINIT is removed.
VMXGOPTR 26.242 Internal utility enhanced for multiple options.
VMXGPRAL 26.293 Print all datasets with variable name + label heading
VMXGSUM 26.078 26.02 ONLY - possible VARIABLE NOT FOUND internally.
VMXGSUME 26.227 Now invokes normal VMXGSUM, no longer needed.
WEEKBLDT 26.205 SYSNAME incorrectly added to BY List for TYPE892.
WEEKxxxx 26.115 Inconsistent BY list for RMF data are now consistent.
WEEKxxxx 26.157 NOTSORTED condition due to inconsistent BY lists.
WPS 26.258 WPS 2.3.4 now required for MXG, ARRAY(256,512) error.
WPS 26.291 Circumvention for CCHHR, not supported in WPS.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 26.
====== Changes thru 26.326 were in MXG 26.26 dated Feb 12, 2009=========
Change 26.326 Two Errors in the First MXG 26.26 dated Feb 3 were fixed
READDB2 by replacement of READDB2 and VMXGRMFI:
VMXGRMFI -READDB2 in MXG 26.26: might not create all datasets that
Feb 12, 2009 you requested, and could impact ANALDB2R(PDB=SMF,...) as
the READDB2 member is invoked by ANALDB2R to read SMF.
Last minute changes for IFCID=255 and DB2STAT4 were made
but validation focused only on that correction.
-If VMXGTIME was being used, when READDB2 tried to resolve
a local macro variable it got a bad value placed in a
local macro variable by VMXGTIME. This generated a
WARNING: MACRO VARIABLE NOT RESOLVED. The macro variable
name was changed in READDB2 to prevent the conflict.
Thanks to Raff Rushton, Kaiser Foundation Hospitals, USA.
MXG 26.26 ONLY: PDB.RMFINTRV negative PCTCPUBY, HiperDsp.
But ONLY if HiperDispatch is active, plus negative values
in variables PCTOVHTD CPUACTTM CPUOVHTM MSUINTRV MSUPERHR
MSU4HRAV and PCTOFHDW. A recalculation of CPUACTTM was
not tested with RMF data with HiperDispatch active (i.e.,
when SMF70PAT/CPUPATTM were GT zero). That recalculation
was removed by this change.
Thanks to Chuck Hopf, Bank of America, USA.
====== Changes thru 26.325 were in MXG 26.26 dated Feb 3, 2009=========
Change 26.325 The calculation of RDHITPCT in TYPE42SR was corrected by
VMAC42 Change 19.006, but other instances (TYPE42VT,TYPE42DS)
Feb 3, 2009 were still divided by CACHCAND vs (CACHCAND-WRITCAND),
so the read hit percentage was wrong in those datasets.
Thanks to Scott Chapman, American Electric Power, USA.
Change 26.324 Enhancement for ACF2 support creates IHDRACF2 Header exit
IHDRACF2 taken after the header variables for ACF2 have been INPUT
VMACACF2 so record selection based on existing ACF2 variables can
VMXGINIT be used. The "instream" &MACACFH can be used to access
Feb 2, 2009 the same exit point. IHDRACF2 lists all vars that exist.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 26.323 Support for IBM's ENQ/DEQ monitor, described in IBM
EXENQMON Publication SA22-7600-07, "z/OS MVS Planning: Global
IMACENQM Resource Serialization", Chapter 3, creates a flat
TYPEENQM file that is read by this support from //ENQM DDname,
TYPSENQM creating dataset ENQMONIT.
VMACENQM The IBM ISGAJE1A report can be printed using the
VMXGINIT example PROC PRINT in the VMACENQM comments.
Jan 30, 2009
FORMATS
Feb 24, 2009
Thanks to Debby Blackey, HCH Healthcare, USA.
Change 26.322 The UTILCVRT utility is used if you transfer SAS datasets
FORMATS from z/OS to an ASCII platform (XPORT,CPORT), if a data
Jan 30, 2009 set contains CHAR variables that are FORMATted $HEX. In
Feb 13, 2010 transferring the values, SAS unilaterally converts all
CHAR variables from EBCDIC to ASCII, so a CPUTYPE='2086'x
gets translated to '8766'x in the ASCII SAS dataset. The
format used by UTILCVRT was completely wrong, because it
was based on the IND$FILE programs EBCDIC to ASCII table.
The $MGAS2EB format used in UTILCVRT is now based on the
TRANTAB SAS V9.1.3 CPORT mapping on z/OS at a USA site.
Feb 13, 2010: UTILCVRT is no longer needed. The new
TRANSCODE attribute, added by MXG Change 27.014 to all
$CHAR variables containing $HEX values, eliminates the
unwanted translation so downloaded values are valid.
Thanks to Roman Gudz, Penske, USA.
Change 26.321 Corrections to IBM RMF-like reports for zIIPs, zAAPs and
ANALRMFR IFLs, and revised sort order to match IBM's reports.
Jan 28, 2009
Thanks to Kim Westcott, OFT State of New York, USA.
Change 26.320 Variable EZA01A13 for the optional EZA01-A CICS segment
UTILEXCL was not in the generated KEEP statement.
Jan 28, 2009
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.319 Support for Exported Data from Omegamon XE MQ records.
EXOMAA10 This is non-standard, since an export file can contain a
EXOMDD10 number of datasets to be recreated. The MXG logic reads
EXOMDD20 the initial control records (AA10,DD10,DD20,DD30) and
EXOMDD30 writes the needed old-style macros to //INSTREAM which
IMACOMMQ is then processed by the second pass in _2NDOMMQ macro,
TYPEOMMQ to read the ROW1 records and create all datasets. This
TYPSOMMQ iteration doesn't label the variables nor datasets.
VMACOMMQ The EXPORT files cannot be concatenated, since they
VMXGINIT may have different tables/datasets to be created. The
Jan 29, 2009 JCL to process these export files is
// EXEC MXGSASV9
//OMMQ DD DSN=YOUR.EXPORT.FILE,DISP=SHR
//PDB DD DSN=THE.OUTPUT.sASDATA.LIBRARY,DISP=OLD
//SYSIN DD *
%INCLUDE SOURCLIB(TYPSOMMQ);
These eleven datasets have been created:
QMCHANIN QMCH_LH QMEVENTH QMLHBM QMLHLM QMLHMM
QMPS_LH QMQ_LH QM_APAL QM_APQL QM_APTL
This implementation automatically creates a dataset for
every table in the DD20/DD30 records, and will convert
the known 16-character datetime fields into datetime
variables, and formats known duration and hex-containing
fields, but new variables in new datasets will require
updates to MXG code to properly convert or format them,
because the AA10/DD10/DD20/DD30 control records do not
contain any intelligence describing contents of fields.
Thanks to Frank Cortell, Credit-Suisse, USA.
Thanks to Michael Reffler, Credit-Suisse, USA.
Change 26.318 Message "ARRAY SIZE TOO SMALL" added by Change 25.177 is
VMXGRMFI now only printed three times.
Jan 26, 2009
Thanks to Ed Long, FMR, USA.
Change 26.317 Enhanced SYSLOG message capture in SMF record subtype 9,
ASMTAPEE no longer requires a re-assembly to add or change the
Jan 25, 2009 MSGIDs to be written to SMF. Now, the list of MSGIDs is
read at MXGTMNT Start Up from the text file of messages
pointed to by the //MXGMSGID DD name in the MXGTMNT JCL.
See comments in the ASMTAPEE member for details.
This is now ML-44 maintenance level of the monitor.
(Previously, you had to list the MSGIDs in the ASMTAPEE
assembly source code; that table no longer exists, as it
is replaced by the external file of MSGIDs.)
Change 26.316 Variable RNAMEHEX contained the "hex of the hex" instead
VMAC77 of the hex value of the RNAME, for those cases in which
Jan 25, 2009 the RNAME/MINORQCB contains non-printable characters.
Thanks to Joe Kimberly, Kansas City Southern Railway Co., USA.
Change 26.315 Using MACDB2H= or MAC110H tailoring and UTILBLDP was not
UTILBLDP correctly coded, causing execution messages
Jan 23, 2009 *ERROR: OPEN CODE STATEMENT RECURSION DETECTED.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.314 Enhancement for CMRDETL records from BMC TMON for CICS.
IHDRMVCI -The INFILE "Header" EXIT IHDRMVCI is created, so records
VMACMVCI can be selected after the header has been read. The full
VMXGINIT list of variables that exist are listed in comments.
Jan 23, 2009 -The IHDRMVCI exit can be invoked with %LET MACMVCH=.
-The option JFCB=MVCIJFCB is added to INFILE CMRDETL so
that the JFCB is stored in variable MVCIJFCB, from which
the z/OS DSNAME can be retrieved. This is similar to the
existing SMFJFCB variable created with INFILE SMF.
For example, adding this code
//SYSIN DD *
%LET MACMVCH=
%QUOTE(
IF MVCIDSN=' ' THEN DO;
MVCIDSN=STRIP(SCAN(MVCIJFCB,1,' ');
MVCIGDG=SCAN(MVCIDSN,-1);
RETAIN MVCIDSN MVCIGDG;
END;
CALL SYMPUT('MVCIDSN',MVCIDSN);
);
%INCLUDE SOURCLIB(TYPEMVCI);
%PUT INPUT DSNAME WAS: &MVCIDSN;
would create variables MVCIDSN,MVCIGDG, and would create
a macro variable &MVCIDSN with the DSNAME that was read.
Thanks to Henk van der Veur, Fortis, THE NETHERLANDS.
Change 26.313 Revisions to support for TMON for DB2 V4 and V4.1.
VMACTMDB -Dataset TMDBDB2 had misalignments corrected.
Jan 23, 2009 -Support for BF variables in dataset TMDBBF.
-Support for BG variables in dataset TMDBBG.
-Support for BH variables in dataset TMDBBH.
-Support for BI variables in dataset TMDBBI.
Thanks to Ernie Amador, University of California Davis Health, USA.
Change 26.312 Support for APAR OA27161 which adds interval variables
VMAC23 to the SMF 23 record. Change 26.116 supported OA22414,
Jan 22, 2009 which added cumulative variables for the same metrics.
Change 26.311 -In DB2 V9, IFCID=225 creates the DB2STAT4 dataset and
READDB2 DB2 V8 creates the T102S255 dataset, but DB2STAT4 had
VMACDB2 all missing values for the QW0225xx variables in the
Jan 22, 2009 DB2STAT4 dataset because QWS02R1O was spelled with a
Jan 28, 2009 zero instead of an oh in VMACDB2.
Feb 2, 2009 -READDB2 could cause error messages
THE TEXT EXPRESSION LENGTH (65545)
EXCEEDS MAXIMUM LENGTH (65534).
-READDB2 did not create both T102S225 and DB2STAT4 when
IFCIDS=225 was specified, in spite of the claim made in
Change 26.233. Now, both datasets are created.
-Because T102S225 is created from SMF ID=102 but the
DB2STAT4 is created from SMF ID=100 subtype 4, there
are still some limitations in READDB2 using WANTONLY.
-New-in-DB2-V9 variables added and kept in DB2STAT4:
QW0225SF='FIXED*VIRTUAL*64BIT*SHARED'
QW0225SG='GETMAINED*VIRTUAL*64BIT*SHARED'
QW0225SV='VARIABLE*VIRTUAL*64BIT*SHARED'
QW0225SU='STACK*STORAGE*IN USE'
QW0225L2='ALLOC STORAGE*CACHED*THREADCPYS*ABOVE POOLS'
QW0225H2='HWMALLOCSTORE*CACHED*THREADCPYS*ABOVE POOLS'
QW0225F1='SERVICEABILITY*QW0225F1'
QW0225F2='SERVICEABILITY*QW0225F2'
QW0225S2='STATEMENT*CACHE*BLOCK*STORAGE*GT 2GB'
-This example shows how you can use MXG macros instead
of using READDB2 if you only wanted the DB2 Statistics
datasets (DB2STATS/DB2STATB/DB2STATR/DB2STAT4/DB2GBPAT
DB2GBPST) and T102S225 (i.e., you have both V8 and V9
IFCID=225 records in your SMF); the example reads only
the SMF 100 and 102 records and does not create any of
the DB2ACCTx datasets.
%LET MACFILE=
%QUOTE( IF ID=100 OR ID=102; );
%LET MACKEEP=
_N102
MACRO _W102225 PDB.T102S225 %
MACRO _EDB2ACC %
MACRO _EDB2ACB %
MACRO _EDB2ACP %
MACRO _EDB2ACG %
MACRO _WDB2ACC _NULL_ %
MACRO _WDB2ACB _NULL_ %
MACRO _WDB2ACP _NULL_ %
MACRO _WDB2ACG _NULL_ %
;
%LET PDB2ST0=WORK;
%LET PDB2ST1=WORK;
%LET WDB2PAT=PDB;
%LET WDB2PST=PDB;
%LET WDB2STR=PDB;
%LET WDB2ST2=PDB;
%LET WDB2ST4=PDB;
%INCLUDE SOURCLIB(VMACDB2,VMAC102,IMACKEEP);
DATA _VARDB2 _V102225;
_SMF
_CDEDB2
_HDR102 _C102225 _END102;
_SDB2STB
_SDB2STS;
RUN;
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Dan Case, Mayo Clinic, USA.
Change 26.310 The MXGWORK= argument of VMXGINIT hasn't worked for many
VMXGDEL years (Change 18.148, Jun 2000, Change 17.060, 1999) as
VMXGINIT a way to change the //WORK destination, and it was the
Jan 21, 2009 cause of errors reported in Change 26.252, so it has
been removed as an argument and is now a GLOBALed macro
variable name in VMXGINIT, and the now-redundant GLOBAL
statement in VMXGDEL is removed.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 26.309 Variable TMNTJOBC='JOB*CANCELLED*BY*OPERATOR' was wrong
VMACTMNT and always was the same as TMNTJOBI, because TMNTJOBC
Jan 21, 2009 was set 'Y' from the x'02' bit instead of the x'01' bit.
Thanks to Michael Creech, Lender Processing Services, USA.
====== Changes thru 26.308 were in MXG 26.12 dated Jan 20, 2009=========
Change 26.308 The TYPE70 dataset is enhanced with these counts of the
VMAC7072 specialty engines:
Jan 17, 2009 PARTNICF='PARTITION*NUMBER OF*ICF*ENGINES'
PARTNIFA='PARTITION*NUMBER OF*ZAAP*ENGINES'
PARTNIFL='PARTITION*NUMBER OF*IFL*ENGINES'
PARTNZIP='PARTITION*NUMBER OF*ZIIP*ENGINES'
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 26.307 The CLIST to process RMF III files had an incorrect GOTO
CLRMFV in line 943 that should be GOTO DONE. Fortunately, this
Jan 16, 2009 path thru the CLIST is seldom-to-never used.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 26.306 -If the new operand COPYONLY=YES was specified, READDB2
READDB2 tried to read the header using VMACDB2H, but that read
Jan 15, 2009 required prerequisites. Code now uses _CDEDB2 which
then calls VMACDB2H with all datasets to _NULL_ via the
_NDB2 to read only the headers if COPYONLY=YES.
-READDB2 was enhanced to allow selection by QWHCEUTX,
the End User Transaction Name, which might be useful
in the classification of DDF work in WLM, but only
if it is filled in by the calling application with
something other than a default value. It must also be
the first piece of the unit of work that is seen by WLM.
Thanks to Becky Clark, Bank of America, USA.
Change 26.305 CICSTRAN variables RTYPE and RRTYPE contain $EBCDIC text
VMAC110 but some of the INPUT statements in VMAC110, and in code
UTILEXCL built by UTILEXCL, incorrectly had $CHAR inputs. As long
Jan 15, 2009 as MXG is executed on z/OS, there was no difference, but
for ASCII execution, the INPUTs must be $EBCDIC.
Thanks to Glenn Bowman, Wakefern, USA.
Change 26.304 Internal changes for DOCVER enhancements and CONFLICTs.
FORMATS New $MGUTILD format maps each MXG-built DATASET name in
UTILVREF member DOCVER to both the INFILE that was read, and the
Jan 14, 2009 MXG member name that created that dataset, and a flag
for "second-level" datasets that are not created from an
infile but are created from SAS datasets. The format is
now used to add that information in the DOCVER member.
Also, the format is used in the new QA CONFLICTs report
to cluster datasets by INFILE to eliminate conflicts in
variable's type, length, format, or maybe even labels.
-So, if FORMAT $MGUTIL has been updated, but the QA Job
has NOT been rerun, the new datasets in DOCVER will NOT
have their INFILE identified; that line will be blank.
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 26.303 Capture Ratios for zAAPs and zIIPs are now calculated in
VMXGRMFI PDB.RMFINTRV and TREND.TRNDRMFI datasets, and the total
Jan 13, 2009 Service Class zAAP and zIIP CPU times are creates:
CPUIFATM - IFA (zAAP) CPU TIME in Service Classes
CPUZIPTM - ZIP (zIIP) CPU TIME in Service Classes
IFAACTTM - IFA (zAAP) CPU TIME in TYPE70 (Hardware)
ZIPACTTM - ZIP (zIIP) CPU TIME in TYPE79 (Hardware)
CAPIFART - CAPTURE RATIO FOR ZAAP ENGINES
100*CPUIFATM/IFAACTTM
CAPZIPRT - CAPTURE RATIO FOR ZIIP ENGINES
100*CPUZIPTM/ZIPACTTM
Thanks to Brian Harvey, HCL America, USA.
Change 26.302 INPUT STATEMENT EXCEEDED for unexpected AAA record with
VMACNMON AAA,LPARNumberName,none
Jan 13, 2009 MXG expected LPARNumberName to be followed by the LPAR
number and the LPAR name. Why the LPARNumberName tag
exists when its value is "none" is unknown, but now, the
LPARNAME='none' will be output.
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 26.301 Debugging PUT statements were always printed, because
UDB2GTF the IF DEBUG GE 2 THEN statement did not precede PUT.
Jan 13, 2009
Thanks to Steve Wood, DST Systems Inc, USA.
Change 26.300 Conflict Resolution of variable's TYPE/LENGTH/FORMAT.
VMAC94 -In MXG 26.11, I made changes to eliminate exposures to
VMAC89 possible conflicts (none had actually occurred), but
VMACTPMX did not document all of the changes in Change 26.289.
DOC One impacting change is now reversed: variable PRODREL
Jan 18, 2009 in TYPE892 has been restored (it was renamed PRODRL89 in
MXG 26.11, but that impacted the LCS product); it length
is now $6 to match other PRODREL variables, eliminating
any exposure.
-In MXG 26.11, TYPETPMX variable ACCT was renamed ACCTJOB
to avoid conflict with the older TYPE26J2 ACCT variable,
but incorrectly, causing an VARNAME ACCTJOB NOT FOUND.
Since ACCTJOB is then stored into the actual ACCOUNTn,
it should probably not have been kept, and is unlikely
that the change from ACCT to ACCTJOB has any impact.
But the new ACCTJOB variable is length $16 and all 16
converted into $EBCDIC, so individual ACCOUNTn fields of
16 are now supported; actual length is set in IMACACCT.
-In TYPE94, an actual conflict was reported by Ken and is
now fixed: the format of variables STARTIME and DURATM
was DATETIME18.0 and TIME8., because the SMF 94 records
only have seconds resolution; however, adding type 94 to
your BUILDPDB caused all of the RMF datasets to have the
shorter format for their STARTIME and DURATM variables,
as SAS uses the last instance of a FORMAT statement. By
changing the FORMAT in VMAC94 to match the "standard"
DATETIME21.2 and TIME12.2 formats the full RMF precision
is printed.
However, this is truly ONLY cosmetic; the FORMAT is
only used when values are printed, and they do NOT
change the stored data values; you can ALWAYS use a
FORMAT statement in your PROC PRINT, etc., to show
as many or as few decimals as you want displayed.
-The below variables were renamed to eliminate conflicts.
Many of these datasets are no longer even creatable, and
none are created from common IBM SMF records - most are
created from optional user SMF records and none of these
renamed variables are likely to be used in your reports.
Dataset Variable Name Dataset Variable Name
AIM098_R was FILENAME SAMONASR was APPLNAME
now FILENAAI now APPLNASA
CCCDAT was ACCOUNT SAMONAUR was APPLNAME
now ACCTCCC now APPLNASA
CMHMEVNT was EXPDT SAMONTSR was APPLNAME
now EXPDTDAT now APPLNASA
FILTEKID was GROUP SAMONUSR was APPLNAME
now GROUPSM1 now APPLNASA
ICEBRGDE was RELEASID SUPERIND was TERMINAL
now RELEASIC now TERMSUIN
ICEBRGUT was VDEVTYPE was USERNAME
now VDEVTYIC now USNASUIN
ILKVCONN was USERDATA SV08THRE was ABEND
now USDAILKV now ABENDTSK
ILKVDISC was USERDATA was CLASS
now USDAILKV now CLASSVIE
LDMSBASE was FUNCTION now GROUPTH3
now FUNCLDMS was GROUP
LDMSDIST was FUNCTION was STATUS
now FUNCLDMS now STATSVIE
LDMSPC was SERVER SV25TSUM was RESPTIME
now SERVLDMS now RESPSVIE
MEMOACCT was ACCTCODE SV27TRAN was NETNAME
now ACCTCOME now NTNMSVIE
was SESSION was OFCTYNME
now MEMOSESS now OFCTYTCP
was USERNAME was RTYPE
now USNAMEMO now RTYPSVIE
MVTPN was MTU was TRANPRI
now MAXMTU now TRANPRIS
MVTPS was LOCATION was TERMINFO
now LOCNMVTP now TERMINFS
was NAME T112MQCO was MQTRAN
now NAMEADMN now MQTRANID
NAFENTVA was TERMINAL T112MQCT was MQTRAN
now NAFTERM now MQTRANID
NAFGPSTO was VLU TYPE1031 was SUBSYS
now VLUNAF now SUBSY103
NAFGPSTR was VLU TYPE1032 was SUBSYS
now VLUNAF now SUBSY103
OMCIADA was AFNAME TYPE6367 was ACTION
now AFNAMECI now ACTIONRQ
OMCIBOTL was ESTTIME TYPEACC was MESSAGE
now ESTDTIME now MESSGACC
OMCIFIXD was ESTTIME TYPEDLMN was NEWNAME
now ESTDTIME now NWNMDLMN
OMCIRTA was ESTTIME was USERNAME
now ESTDTIME now USNADLMN
OMCITITL was ESTTIME TYPESTRS was VERSION
now ESTDTIME now VERSSTRS
OMCITRAL was ESTTIME TYPETPMX was ACCT
now ESTDTIME now ACCTJOB
OMCITRAN was ESTTIME TYPEX37 was ACCTNO
now ESTDTIME now ACCTNO37
OMCIVDCT was ESTTIME was MESSAGE
now ESTDTIME now MESSGX37
OMCIVENQ was ESTTIME was PRODREL
now ESTDTIME now PRODRL37
OMCIVFCT was ESTTIME XCOMDATA was USERID
now ESTDTIME now USERXCOM
OMCIVIO was ESTTIME XPTR10 was ACCOUNT
now ESTDTIME now ACCTXPTR
OMCIVJCT was ESTTIME XPTR21 was ACCOUNT
now ESTDTIME now ACCTXPTR
OMCIVPCP was ESTTIME was LOCATION
now ESTDTIME now LOCNXPTR
OMCIVVSA was ESTTIME XPTR45 was ACTION
now ESTDTIME now ACTNXPTR
PRORECOV was PRODREL ZARAERRV was VOLPOOL
now PRODRLPR now VOLPOOLZ
ROSCOAUD was USERID ZARAVOL was VOLPOOL
now USERROSC now VOLPOOLZ
ROSCOE was USERID
now USERROSC
was TERM
now TERMIOS
ROSCORPS was USERID
now USERROSC
ROSCOSTA was USERID
now USERROSC
ROSCOVPE was USERID
now USERROSC
Thanks to Al Sherkow, I/S Management Strategies, Ltd.
Thanks to Scott Wigg, U.S. Bank, USA.
Thanks to Kenneth D. Jones, Bell Aliant, CANADA.
Change 26.299 MXG 26.10-26.11. PERFINDX=. for all service classes with
VMAC7072 R723TYPE=2:ADDRESS SPACE WITH NO TIME GOAL. A "cosmetic"
Jan 12, 2009 Change 26.269, eliminated "missing value" value messages
but accidentally setting PERFINDX to a missing value for
those service classes.
Thanks to Dan Melton, Lowe's Companies, USA.
Change 26.298 DB2 ID=102 IFCID=22 INPUT STATEMENT EXCEEDED RECORD
VMAC102 error when length in the header field was zero; the
Jan 11, 2009 actual length is 2 bytes longer than stored in the
start of each segment. MXG logic revised to support.
Thanks to Tom Buie, Southern California Electric, USA.
Change 26.297 -Case in zPCR and ExternalSource tags were inconsistent
ANALZPCR and caused configuration errors.
Jan 13, 2009 -SELECT=CECTIME created multiple HOST tags.
-Printed ONLPCPUS in reports was correct, but the LCPs
tag value could be one higher than true number of CPs
in the LPAR, if ONLPCPUS was an integer. MXG algorithm
ONLPCPUS=CEIL(ONLPCPUS) now ONLPCPUS=CEIL(ONLPCPUS-.01)
to protect for both 3.0 and 2.999 values, and relocated
so the printed and tag values are the same.
-An "External Study File" can ONLY be LOADed from zPCR's
FUNCTION SELECTION window, using its FILE pulldown LOAD
option to browse/select the MXG-built xxxx.zpcr file.
Thanks to David Bixler, FISERV, USA.
====== Changes thru 26.296 were in MXG 26.11 dated Jan 5, 2009=========
Change 26.296 The BLSR option for IMS VSAM files is not supported; the
ANALBLSR ANALBLSR analysis created pages of reports for IMS VSAM
Jan 5, 2009 files, with PROGRAM='DFSRRC00', so this change deletes
all files that were accessed with that program name.
Thanks to Stephen Hughes, Excellus, USA.
Change 26.295 The RMFWKLRV interval workload dataset build by RMFINTR
VMXGRMFI creates two new variables WKLDIOCN and WKLDIORT, the
Jan 2, 2009 I/O count and I/O rate from R723CIRC.
Thanks to Don Goulden, SAS ITRM Development, USA.
Change 26.294 Two new arguments, CICSTRAN & DB2ACCT can be specified
UTILBLDP in the SUPPRESS= argument if you do not want the detail
Jan 2, 2009 CICSTRAN or any of the DB2ACCTx datasets to be created.
With SUPPRESS=CICSTRAN, SMF 110 subtype 1 records are
skipped, with SUPPRESS=DB2ACCT, SMF 101 records are.
Change 26.293 %VMXGPRAL(DDNAME=PDB,NOBS=20) prints ALL datasets in a
VMXGPRAL SAS data library, but now, it uses new VMXGPRNT to print
VMXGPRNT both the variable's LABEL and the variable's NAME in the
Jan 2, 2009 heading. The new VMXGPRNT macro can also be used alone
to print a single SAS dataset, or it can be used to
create a Comma-Separated-Variable file from a single SAS
dataset. I find VMXGPRAL very useful to print a few obs
with all of the variables to validate a new MXG-built
dataset. The logic for VMXGPRNT was originally posted
to MXG-L by John, and Mike recently reminded me of it.
The old UPRINDOC member did print the label and name,
and is used to create the ADOCxxxx prints/means, but
the new VMXGPRAL and VMXGPRNT is much nicer syntax.
Thanks to Mike O'Brien, Bank of America, USA.
Thanks to John Parkes, Experian, USA.
Change 26.292 MONTHBL3 was overlooked when Change 24.064 added simpler
MONTHBL3 override for NOT SORTED errors in creating MONTH PDB.
Jan 1, 2009 It is now updated to match MONTHBLD logic.
Thanks to Douglas G. Wells, First National Bank of Omaha, USA.
Change 26.291 WPS does not support the INFILE CCHHR nor CCHHR= options
VMACEREP which is required to read LOGREQ with TYPEEREP, and was
VMXGVTOC used in VMXGVTOC (now archaic, replaced by DCOLLECT), and
UTILSPAC also used in the UTILSPACE reporting utility. This
Jan 1, 2009 change removes the CCHHR options when MXG is executed
under WPS, so that the QAWPS QA test stream can run, to
test the compiler using only DUMMY INFILES. This change
will be revised if/when CCHHR support is in WPS.
See Change 27.239.
Change 26.290 The View Direct, Mobius, Infopac-RSD, etc., product's
VMACIPAC user SMF record, subtype 3 was INCOMPATIBLY restructured
Dec 30, 2008 with R3CALLER field relocated, the LUNAME field removed,
and seven extra bytes inserted. MXG was recoded to read
the new format with a heuristic test of the old location
of R3CALLER, pending response from support@asg.com, who
now owns this product.
Jan 5: A PTF has been provided, but not yet installed,
but even if it does correct the invalid SMF record, I
will leave the circumvention in place, since it will
protect sites without the correcting ptf.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 26.289 -Cleanup of inconsistent LENGTHs and CHAR/NUM conflicts
ANALCISH for variables created from the same INFILE. CHAR/NUM
VMAC112 conflicts were resolved by renaming the variable from
VMACFTEK the more obscure product. Lengths were mostly increased
VMACQACS with &MXGLEN replacing 4s, but some 8s are now &MXGBYLN.
DIFFROSC These LENGTH changes may cause WARNINGs with SAS V9.2,
VMACSVIE when creating WEEK or MONTH PDBs with PDBs built by MXG
VMXG70PR versions before/after this change, but by installing now
VMACSVIE if still under SAS V9.1.3, then your migration to V9.2
VMAC7072 could be warning-free.
No CHAR/NUM conflicts had been reported, so changes were
Jan 5, 2009 made to prevent future errors.
-Data Set Labels were added where they were blank.
-Variable ZDATE was added where it was not being created.
-Member DOCVER26 lists all of the changed variable names:
Variables TERMINFO TRANPRI were Numeric in SV27TRAN data
set built by TYPESVIE from SMF, which conflicted with
IBM SMF 110 records, so TYPESVIE was changed to create
them as character to avoid conflict if 110s and SVIE
were ever (unlikely) combined in a single DATA step.
ANALCISH, typo, CICSCONSR changed to CICCONSR.
VMACFTEX, variable GROUP renamed to GROUPSM1.
VMAC112, variable MQTRAN renamed to MQTRANID.
DIFFROSC, variable TERM renamed to TERMIOS.
VMACQAPM, variable XIDTYP changed to CHAR.
VMXG70PR, variable IFAUPTM LPARNUM SMF70CSF PCTIFABY
PCTZIPBY changed from length 8.
VMAC7072, variables NRPRCS, NRPHYCPS changed from len 8.
Change 26.288 TYPE78CU variables for Aliases could be wrong, as they
VMAC78 were retained but not initialized, so devices without an
Dec 29, 2008 alias could incorrectly have values in these variables:
R783HCNT R783HIX R783HLCU R783HCU R783HNAI R783HTIO
R783HAIU R783HCAD R783HIOQ
Thanks to Peter Schubert, CITEC, AUSTRALIA.
Change 26.287 Support for RMF III CPUG3 z/OS 1.9 (INCOMPATIBLE - zero
VMACRMFV observations in ZRBLCP without this change).
Dec 28, 2008 New variable in ZRBLCP: LCPUCURW - Current SHARE weight.
LCPUCURW='CURRENT*SHARE*WEIGHT'
New variables in ZRBCPU:
CPCGRPNM='CAPACITY*GROUP*NAME'
CPCGRPLM='CAPACITY*GROUP*MSU*LIMIT'
CPGRPJOI='DATETIME WHEN*LPAR JOINED*GROUP'
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 26.286 Very strange error messages in 26.08 and 26.10, where
VMXGRMFI the "x" is a non-printable character:
Dec 23, 2008 ERROR: LIBNAMES ARE RESTRICTED TO EIGHT CHARACTERS.
x HAS BEEN TRUNCATED.
Removal of an unneeded %VGETENG call in VMXGRMFI has
eliminated the strange errors, but still researching.
Thanks to Dan Case, Mayo Clinic, USA.
Change 26.285 Enhanced to do the dynamic allocation of DAYS based on
VMXGALOC the DAYSKEEP= value. On ASCII this creates a pseudo-GDG
Dec 23, 2008 architecture were days a DddMMMyy, weeks are Wddmmyy and
Jan 3, 2009 months are Mddmmmyy, and a variable number of each can
be kept, with old ones being deleted and new ones being
created over time.
So, if today is 22DEC08, the directory names would be
PDB - c:\MXG\D21DEC08
MON - c:\MXG\D15DEC08
TUE - c:\MXG\D16DEC08 ....
WEEK - c:\MXG\W15DEC08
WEEK1 - c:\MXG\W15DEC08
WEEK2 - c:\MXG\W08DEC08
WEEK3 - c:\MXG\W01DEC08 ....
MONTH - c:\M01DEC08
In addition, TREND databases can be allocated based on
doing TRENDing on a daily or weekly basis.
TRENDING=DAILY creates
TRENDIN - c:\MXG\T20DEC08
TREND - c:\MXG\T21DEC08
TRENDING=WEEKLY creates
TRENDIN - c:\MXG\T08DEC08
TREND - c:\MXG\T15DEC08
TRENDING=WTD creates
TRENDIN - c:\MXG\T15DEC08
TREND - c:\MXG\T22DEC08
The SPIN and TREND directory management follows the
pattern specified in DAYSKEEP WEEKKEEP. Older
directories will be erased/deleted based on the
numbers in those two arguments.
For those times when you may need to go back and rerun a
day's processing, FORCEDAY=22DEC08 will set the correct
directories for that day's processing to be allocated.
The basedir= argument defaults to c:\mxg\ but can be any
disk device and directory available to your system.
Change 26.284 The BMC Optional CMRDB2 segment was increased from 172
IMACICMD to 256 bytes in CICS/TS 3.2. The IMACICMD code is now
Dec 22, 2008 updates to support both lengths, based on SMFPSRVR.
Thanks to Jane Dickenson, Produban, ENGLAND.
Change 26.283 -zPCR failed with PDB=SMF, or SCP not 'z/OS V1R10', the
ANALZPCR SELECT=CECTIME option is now implemented, and new notes
Dec 21, 2008 have been added:
Dec 31, 2008 -PDB=SMF option had not been fully tested and caused a
180 underscoring a percent sign; the UTILBLDP logic is
revised to read only required SMF records and subtypes.
-zPCR support worked fine when SCP='z/OS V1R10' was set,
but I discovered XML doesn't tolerate extra blanks, so
SCP='z/OS V1R9 ' created an XML file that caused zPCR
configuration errors "UNKNOWN SCP". Now, trailing
blanks in the generated XML text are removed.
-The XML text is very case sensitive, so the ANALZPCR
member is also, and it must NOT be case-changed.
-Support for SELECT=CECTIME is now implemented. To be
valid, all SYSTEMs in each CEC must have the same RMF
Interval Duration, and must all have the same SYNC(0)
or the same SYNC(59) value. The CPU Dispatch Time for
all CP engines in the CECSER is summed and the interval
with the largest total is created for each CECSER as
the input. The file name has the CECSER value instead
of the SYSTEM name.
-MXG will create the external study file for any CPU type
but the zPCR tool will only accept data from a z9 or
above (CPUTYPE 2094, 2096, 2097, 2098). If you attempt
to load a file with an earlier CPU model, zPCR will not
accept it, and a zPCR warning box will display
Host LPAR Definition errors exist, please refer to
file "configuration errors" and correct the errors.
That configuration.errors file is in the \CPSTOOLS\ZPCR\
directory, and for this error condition will state
The following errors were found in the study file:
C:\CPSTOOLS\zPCR\s1942.d17dec08.t0130.zpcr
Unsupported Host processor specified;
It must be a z9 or above (2094, 2096, 2097, 2098)
Report any other error messages to support@mxg.com.
-The zPCR tool uses the TYPE70 CPU Utilization and the
TYPE74 DASDIOrate to select "workload" type for the
model. If there is no TYPE74 data, then zPCR will set
the workload type to "unknown" and you will have to then
manually change the workload type after you load the
MXG-created external study file.
Thanks to Warren Hayward, TJX, USA.
Thanks to David J. Schumann, Blue Cross Blue Shield of Minnesota, USA
Change 26.282 APPLID could be blank in PDB.ASUMUOW if the first part
VMXGUOW of a Unit of Work came from MQ rather than CICS. This
Dec 19, 2008 could also cause blank APPLID in PDB.CICS when ASUMCICX
Dec 23, 2008 is used.
Thanks to Douglas G. Wells, First National Bank of Omaha, USA.
Change 26.281 Variables IFAUNITS and IFEUNITS are now added to both
BUILD005 the PDB.STEPS and PDB.JOBS datasets from the SMF 30s.
BUIL3005 They should have been added with ZIP units were added.
Dec 19, 2008
Thanks to Jansson Ingegerd, Volvo IT, SWEDEN.
Change 26.280 Support for Open Connect user SMF record. New dataset
EXOPCNCL OPENCONN is created, but with these problems:
FORMATS - Records with DISP=00 have completely different format
IMACOPCN that the other records.
TYPEOPCN - Records with DISP GT 0 have hex text where JOB should
TYPSOPCN be, and JCTJOBID is not populated.
VMACOPCN - Value of DISP=4 occurs, but is not documented; guess
VMXGINIT is that it is NEW.
Dec 19, 2008
Thanks to Robert Brosnam, Goldman Sachs & Co., USA.
Change 26.279 Enhancement/correction to support for Nigel's Monitor.
VMACNMON -DISKSERV and DISKWAIT records supported and same named
Dec 18, 2008 variables are added to NMONDISK dataset:
DISKSERV='DISK*SERVICE*TIME*MSEC/XFER'
DISKWAIT='DISK*WAIT*QUEUE*TIME*MSEC/XFER'
-MEMPAGES4KB,MEMPAGES64KB,MEMPAGES16MB and MEMPAGES16GB
records are now supported, adding four sets of those
variables to NMONINTV dataset.
-Short AAA record protected.
-Invalid JFSFILE and JFSINODE records that have fewer
counters that described are detected and diagnostics
and print of the defective record is printed on the
log so you can send to and resolve with Nigel.
Change 26.278 Example analysis program joins DB2ACCT and DB2ACCTP, but
ANALDBJO must be used with extreme caution, as the resources to
Dec 18, 2008 sort both datasets first for the merge, can be extreme.
Change 26.277 Support for APAR OA24208 adds new subtype 15 to ID=92
EXTY9215 SMF record. The new subtype audits changes to USS file
IMAC92 security attributes for APF Authorized, Program Control,
VMAC92 and Shared Library that are maintained by USS and thus
VMXGINIT were not audited by RACF.
Dec 18, 2008
Change 26.276 CPUUNITS value of minus one in TYPE72GO has resulted in
VMAC7072 type 72 subtype 3 records for service classes that used
Dec 16, 2008 only a zIIP engine. The raw CPUUNITS field contains the
sum of CP, zIIP, and zAAP units, but MXG calculates the
ZIPUNITS and subtracts it from the raw CPUUNITS to store
only the CP engine units in CPUUNITS variable that is
output. These cases have a calculated ZIPUNITS that is
exactly one unit larger than the raw CPUUNITS, causing
the negative value. This is clearly not a real error,
and may be related to Change 26.222 in which IBM noted
small problems with IFAUNITS. So, to avoid confusing
negative values for CPUUNITS (and CPUTM and CPUTCBTM
for these cases) I have reset CPUUNITS to zero if the
value after removal of zAAP and zIIP units is -3 to 0.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 26.275 There was a conflict in parameters between VMXGALOC and
BLDSMPDB BLDSMPDB. BLDSMPDB uses WEEKKEEP MNTHKEEP to specify the
Dec 16, 2008 datasets to be kept in the WEEK/MONTH PDB library, but
VMXGALOC uses those parameters to specify how many weeks
or months to keep. BLDSMPDB is modified with two new
parameters to resolve the conflict:
WEK2KEEP=12 KEEP 12 WEEKS
MTH2KEEP=100 KEEP 100 MONTHS
Additionally, BLDSMPDB now supports concatenated SMF
INPUT files on an ASCII platform, internally. Now, they
can be specified as
SMFIN=FULLYQUALIFIEDDSN1 FULLYQUALIFIEDDSN2 ...
Up to 99 SMF datasets can be named to be read in.
Thanks to Lisa Lawver, Land's End, USA.
Change 26.274 DB2 V9-only variables added by Change 26.210 were INPUT
VMACDB2 when they should not have been, causing very large and
Dec 16, 2008 very wrong values for these 11 variables:
QWACSPZI QWACUDZI QWACSPZE QWACSPZC QWACUDZE
QWACUDZC QWACSPC1 QWACSPC2 QWACUDC1 QWACUDC2
QWACTRSE
These variables should have had a missing value with V8.
Thanks to Roger A. Webster, State of Oregon, USA.
Change 26.273 Statement ELSE IF MRHDRDM=8 and MRHDRRC=1 was relocated
VMACVMXA to preceed the LABEL statement; WPS got confuses, but the
Dec 15, 2008 location was inconsistent with the normal ELSE location.
Change 26.272 Variable SIZE in XAM dataset HSTMEM was incorrectly INPUT
VMACXAM as PIB4., but it is a floating point (RB4.) value.
Dec 15, 2008
Thanks to Roger Stock, Boston University, USA.
====== Changes thru 26.271 were in MXG 26.10 dated Dec 21, 2008=========
Change 26.271 INVALID THIRD ARGUMENT TO FUNCTION SUBSTR in RMF 77 is
VMAC77 harmless, but resulted when there was no RNAME value.
Nov 27, 2008 Change 26.159 (MXG 26.06) decoded RNAME into RNAMHX but
didn't test for a non-zero length in MINORQCB (SMF77RLN).
Thanks to Barbara Nitz, Deutsche-Boerse, GERMANY.
Change 26.270 NRCPUS in PDB.TYPE70 is redefined for HiperDispatch/IRD
VMAC7072 as the AVERAGE NUMBER OF ONLINE, NON-PARKED CP ENGINES
Nov 27, 2008 during the interval. For IRD, it was redefined as the
average number of online engines, but now, any CP parked
time CPUPATTM/SMF70PAT is subtracted from the online time
SMF70ONT, so the NRCPUS will be smaller if any CP engines
were parked during the interval, i.e., if HiperDispatch
is active. These variables are recalculated/impacted
NRCPUS PCTCPUBY PCTCPUEF CPUUPTM
but ONLY IF HIPERDISPATCH IS ACTIVE.
-SHORTCPS in PDB.TYPE70PR was protected for erratic large
value when online and parked times were almost identical,
by requiring 10 seconds of CPUACTTM to be calculated.
Change 26.269 -Missing value messages for CPUWAITY-CPUWAIYC and for
VMAC7072 MVSWAITY-MVSWAIYC, wait times for CPUID/LPARADDR 33-63
Nov 26, 2008 WERE true errors, as those variables were not properly
set when support for more than 32 engines was added; for
systems with more than 33 engines, the MVSWAITM, CPUWAITM
could have been understated causing PCTMVSBY to be higher
that was correct.
-Missing value messages for OMVSWAIT were only cosmetic,
but are eliminated by test prior to calculation.
-Missing value messages for PERFINDX were also only
cosmetic, occurring when ACTELPTM was missing, as for
R723TYPE=2 or when TRAN=0, and are eliminated.
Jan 12 2009: This last part of this change was wrong;
see Change 26.299.
Change 26.268 Circumvention for defective NDM-CD CT user SMF record.
VMACNDM The Accounting Data length (bytes 969-970) is '00B9'x,
Nov 25, 2008 decimal 185, but the record is only 1020 bytes long.
This circumvention uses the MIN of NDMLENSA,LENLEFT
to only input what's left in the record while the
vendor is contacted to resolve their error.
Thanks to Arthur Sy, Depository Trust, USA.
Change 26.267 Hardcoded "PDB" DDNAME/LIBREF in the old-style macro refs
ASUMMIPS were changed to the dataset's Pdddddd macro variable, and
Nov 21, 2008 the reads changed to use the old-style macro reference:
MACRO _RMFIN &PDBRMFI..RMFINTRV %
MACRO _RMF72GO &PTY72GO..TYPE72GO %
MACRO _SMFIN &PDB30UV..SMFINTRV %
MACRO _RMFOUT &PDBRMFI..RMFMSUSE %
MACRO _SMFOUT &PDBRMFI..SMFMSUSE %
for easier building of RMFMSUSE/SMFMSUSE under ITRM.
But since the MSU-to-MIPS factors are also hardcoded,
MACRO _MIPSMSU MIPSFACT=5.8; %
MACRO _MIPSIFA IFAFACT=5.8; %
MACRO _MIPSZIP ZIPFACT=5.8; %
sites using different factors (for different hardware)
can override them "instream", using MACKEEP:
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _MIPSMSU MIPSFACT=5.8; %
MACRO _MIPSIFA IFAFACT=5.8; %
MACRO _MIPSZIP ZIPFACT=5.8; %
)
;
%INCLUDE SOURCLIB(ASUMMIPS);
_RMFMIPS
_SMFMIPS
to create both RMFMSUSE and SMFMSUSE in the same data
library where RMFINTRV lives.
Minor note: since the MACKEEP text contains semicolons,
the %LET MACKEEP= %QUOTE ( text ) ; syntax is required.
Thanks to Nicholas Ward, Centrelink, AUSTRALIA.
Change 26.266 Reserved Change Number.
Change 26.265 Change 20.112 corrected instances of '1A'x in ASCII MXG
PROCSRCE source, which are translated to '3F'x in EBCDIC source.
Nov 20, 2008 That hex character shows up as non-printable text, and in
some cases, caused a SAS syntax error. But eight more
have slipped in over time, all now manually removed.
This change to he PROCSRCE program used to build the MXG
master source adds detection of '1A'x characters, along
with other invalid data and long line tests, to eliminate
future re-occurrences of these invalid text.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 26.264 Support for IBM zPCR capacity tool to use MXG PDB data.
ANALZPCR MXG creates an "External Study File", a new zPCR feature
Nov 25, 2008 that can be used as input in zPCR Version C5.2b or later.
Implemented as %MACRO, %ANALZPCR reads MXG RMF datasets
PDB.TYPE70 and PDB.TYPE70PR and PDB.TYPE74 (or optionally
will read SMF data to create only those datasets) and
creates one ".zpcr" output text file of XML tags/values
for each SYSTEM and STARTIME interval that you select.
The default selection, SELECT=PEAK, will select the
interval with the highest PCTCPUBY for each SYSTEM.
The name of the .zpcr file identifies each SYSTEM and its
STARTIME, and contains the LPAR Configuration for all of
the LPARs in the same SYSPLEX, including engine counts,
z/OS SCP, utilizations and z/OS DASDIOrates.
The .zpcr files can be created on Windows or on z/OS and
copied to your zPCR Windows system, since they are simple
text files. You start zPCR, select LOAD option from the
FILE pulldown and you will be presented with each of the
file names, so you can select the specific system and
interval to be modeled.
You can then examine the configuration, by opening the
Configure LPAR option from the Function Selection page,
and then opening Detail under Reports. For all LPARs for
which utilization and DASDIOrate were found, you will see
their WORKload column will be populated; you will have to
enter your workload choice for those with "unknown".
The %ANALZPCR program has these execution parameters:
PARAMETER DESCRIPTION/SYNTAX
PDB=PDB USE PDB.TYPE70 AND PDB.TYPE70PR for INPUT.
PDB=SMF UTILBLDP READ SMF TO CREATE TYPE70,TYPE70PR.
SELECT=PEAKTIME
CREATE a .zpcr file for each STARTIME for each
SYSPLEX-SYSTEM with the highest total CPU
Dispatch Time for CP engines in a full interval.
THIS IS THE DEFAULT.
SELECT=PEAKPCT
CREATE a .zpcr file for each STARTIME for each
SYSPLEX-SYSTEM with the highest percent CPU busy,
based on the average number of online, non-parked
CP engines in a full duration interval.
SELECT=CECTIME
Select the STARTIME for each LPAR in a CECSER with
the highest total CPU Dispatch Time across all
LPARs and all engines. Not yet implemented.
SELECT=PEAK Create a .zpcr file for each system for the
interval with peak PCTCPUBY in PDB.TYPE70.
SELECT=PEAK is the default.
SELECT=ALL CREATE a .zpcr file for each RMF interval
for each SYSTEM in PDB.TYPE70.
SELECT= If non-blank and NOT PEAK nor ALL, text is
use as SAS CODE FOR SELECTION. For example:
IF (SYSTEM='9K01' AND
'01APR2008:07:44:00.00'DT LE STARTIME
'01APR2008:07:44:00.00'DT );
OR (SYSTEM='DL08' AND
'02APR2008:12:59:00.00'DT LE STARTIME
'02APR2008:12:59:00.00'DT );
PCDIRNAM For ASCII execution of %ANALZPCR, the name
of the directory to which the .zcpr files
will be written.
Default=C:\CPSTOOLS\ZPCR\
The dsnames/filenames of MXG's .zpcr files
are structured to display the variables:
SYSTEM.DDMONYY.HHMM.zpcr
sprd1.d02apr08.t0959.zpcr
ssysa.d02apr08.t2359.zpcr
so that the zPCR "LOAD" pulldown presents
the list of configuration's descriptive name
for this zPCR model's configuration.
ZOSDSN For Z/OS, the high-level qualifier of the
DSNAME to be created.
Each (very small) .zpcr file is created as a
sequential file, so that the full name with
system and date/time can be seen when these
MXG-created .zpcr files are ftp/downloaded
and then viewed in the zPCR "LOAD" Window.
DSN=MXG.Ssyst.Dddmonyy.Ttime.zpcr
DSN=MXG.SPRD1.D02APR08.T0959.zpcr
DSN=MXG.SSYSA.D02APR08.T2359.zpcr
-Additional note:
Sorting TYPE70 by SYSTEM STARTIME DESCENDING PCTCPUBY to
select the maximum CPU Busy percent interval sometimes
found max in an interval with short (2-3 min) duration,
which were the initial interval of an IPL, not the real
workload peak interval, so the SELECT=PEAK algorithm now
finds the MAX(DURATM) for each system, and then selects
only the peak PCTCPUBY with DURATM GE 95% of MAXDUR
( 95% = 14:15 for 15:00 interval) to be modeled.
For each z/OS LPAR, the Number of Logical CPs is the
average number of online-not-parked engines:
ONLCPUS=(SMF70ONT-SMF70PAT)/DURATM;
and Utilization also accounts for IRD and HiperDispatch:
ZPCRCPBY=100*LCPUPDTM/(SMF70ONT-SMF70PAT);
The MXG variable LPARCPUS, the count of engines that
were online for any part of an interval, is used for non
z/OS LPARs. %ANALZPCR prints reports with these details
from TYPE70/TYPE70PR/TYPE74 so you can see what values
were found in your data.
The IFL engines require the SCP (Linux or z/VM) to be
input, but there is no indication in the TYPE70PR data
as to which SCP is in use. I considered trying to parse
the LPARNAME for "V" or "L" but neither is safe, so I've
set the SCP to z/VM
Since ANALZPCR builds a model file for each z/OS SYSTEM,
there will be multiple files created for a CEC that has
multiple z/OS systems. Using SELECT=PEAK could create
different STARTIMEs, since SYSA's peak might not be at
the same time when SYSB peak utilization occurred.
Change 26.263 Thales e-Security's Security Resource Manager for IBM
VMACSRMH MVS RG1100, HSM Device Name field S04HSM is decoded into
EXSRMHCD four new variables depending on the device type:
EXSRMHDE S04HSMCH='HSM*CHANNEL*DEVICE*NAME'
EXSRMHHS S04HSMIP='HSM*IP*ADDRESS'
EXSRMHSN S04HSMAX='HSM*IP*AUXILLARY*PORT'
EXSRMHSV S04HSMVT='HSM*VTAM*DEVICE*NAME'
IMACSRMH -Additional subtypes are now supported, with five SMF
VMACSRMH record ID's possible.
VMXGINIT RECORD ID MACRO FOR EACH OF THE FIVE POSSIBLE RECORDS:
Nov 19, 2008 MACRO _IDSRM1 237 % /*CDS PARAMETER*/
Dec 20, 2008 MACRO _IDSRM2 238 % /*DETAIL EXCEPTION*/
MACRO _IDSRM3 236 % /*SECURITY VIOLATION*/
MACRO _IDSRM4 240 % /*SUMMARY*/
MACRO _IDSRM5 239 % /*SRM SNAPSHOT*/
DDDDDD MXG MXG
DATASET DATASET DATASET
SUFFIX NAME LABEL
SRMHAP SRMHSMAP SRM HOST SECURITY MODULE APPL
SRMHCD SRMHCDSP CDS PARAMETER
SRMHDE SRMHSMDE SRM HOST DETAIL EXCEPTION
SRMHDV SRMHSMDV SRM HOST SECURITY MODULE DEVICE
SRMHHS SRMHHSMD CDS HSMD SEGMENT
SRMHNU SRMHSMNU SRM HOST SECURITY NULL RECORD
SRMHSN SRMHSMSN SRM SNAPSHOT
SRMHSV SRMHSEVI SECURITY VIOLATION
Thanks to Yves Cinq-Mars, CIE IBM Canada Ltee, CANADA.
Change 26.262 Support for WebSphere Version 7, new subtype 9 event.
FORMATS The new subtype 9 and its usage is discussed in this
IMAC120 IBM TecDocs paper
VMAC120 HTTP://WWW-03.IBM.COM/SUPPORT/TECHDOCS/
VMXGINIT ATSMASTR.NSF/WEBINDEX/WP101342
Nov 20, 2008 and its internal format is documented at
HTTP://PUBLIB.BOULDER.IBM.COM/INFOCENTER/WASINFO/
V7R0/TOPIC/COM.IBM.WEBSPHERE.ZSERIES.DOC/INFO/
ZSERIES/AE/RTRB_SMFSUBTYPE9.HTML
MXG creates four new datasets from the subtype 9 record:
dddddd dataset description
T1209E TYP1209E WEBSPHERE SUBTYPE 9 EVENT
T1209C TYP1209C WEBSPHERE SUBTYPE 9 CLASSIFICATION
T1209S TYP1209S WEBSPHERE SUBTYPE 9 SECURITY
T1209U TYP1209U WEBSPHERE SUBTYPE 9 CPU USAGE
There is one subtype 9 record for each request event, so
dataset TYP1209E contains all data from these sections
Platform Neutral Server Information Section
Platform Neutra Server Request Section
z/OS Server Information Section
z/OS Server Request Section
Network Information Section
which only exist once per SMF record. The other three
datasets can all have one or more observations for each
subtype 9 record. The "TIMESTAMPS" section is decoded
but it's variables are duplicates of the datetimestamps
in the z/OS section, so they are not kept in TYP1209E.
-Several new MG1209x formats were created in FORMATS to
decode new subtype 9 variables.
-Variables added to existing TYP120SI dataset:
SM120NPA='SIP*SESSIONS*ATTACHED AND*ACTIVE'
SM120BPT='BYTES*XFER*TO SERVER*FROM SIP'
SM120BFP='BYTES*XFER*FROM SERVER*TO SIP'
Change 26.261 Variables MSGSW, ='Y' or 'N', 'INPUT BY*MESSAGE*SWITCH'
TYPECIMS is now created in the _CHAIN macro to flag IMSTRAN obs.
Nov 17, 2008
Thanks to Shantha Hallett, CapGemini, ENGLAND.
Change 26.260 Variables CMF27CCU & CMF27CHN added to CMF27C93 dataset.
VMACCMF The were previously only output in dataset CMF27CAR.
Nov 17, 2008
Thanks to Shantha Hallett, CapGemini, ENGLAND.
Change 26.259 QA Stream revisions and some corrections to eliminate
ANALDB2R return codes and other issues unique to QA testing.
ANALDBTR -WARNING: VARIABLE IN DROP KEEP RENAME WAS NOT REFERENCED
ANALDMON was eliminated. Some were spelling errors for variables
ANALNPMR that should have been, and now are, kept. Some were just
ASUMAPAF spurious messages, for example, when a variable in the
JCLPDB92 KEEP= list was also (intentionally) in a DROP statement.
JCLTES92 In SPUNJOBS, a DKROCOND=NOWARN was inserted where the I/O
JCLTEST8 variables for archaic devices needed protection.
JCLTEST9 Interestingly, in the case of VMAC7072, where KEEP= list
MXGSAS92 had PCTCIBY0-PCTCIBY9 PCTCIBYA PCTCIBYB ... for variables
MXGSASV9 that were not created until the subsequent SORT/MERGE for
SPUNJOBS the SPLIT70 logic, the hyphenated variable's message was
TYPEIMSA WARNING: Not all variables in the list
TYPETNG PCTCIBY0-PCTCIBY9 were found.
TYPSTNG while the message for the individual variables was.
UNIXSAR1 WARNING: The variable PCTCIBYA in the DROP, KEEP,
UTILBLDP or RENAME list has never been referenced.
UTILXRF1 -z/OS QA job's JCL uses referbacks to eliminate PROC COPYs
VMAC112 that took time and CPU, but an error in SAS V9.2 (that
VMAC7072 is to be corrected) caused the referback to fail when a
VMAC92 LIBNAME xxx CLEAR was used (only to determine if xxx was
VMAC99 on a tape device, for performance), so the cases where
VMACBBMQ CLEAR is used in the QA stream, ANALDB2R, and VMXGTAPE
VMACBVIR (invoked by ANALDB2R and TYPECIMS) are now bypassed, but
VMACEVTA only under SAS V9.2, temporarily.
VMACIMS -Most "MXG" warnings printed MXGWARN: but now all MXG
VMACSFTA warnings print MXGWARN: instead of WARNING:.
VMACSVC -Dec 20: //TEMPSVC DD replaced //SVCTEMP DD in JCLTESxx.
VMACSVIE
VMACSYNC
VMACTMVS
VMACTNG
VMACTPF
VMACTPMX
VMACXAM
VMXGRMFI
VMXGTAPE
Nov 18, 2008
Dec 20, 2008
Change 26.258 WPS 2.3.3 failed in UTILGETM due to a WPS Error (#6276)
JCLQASAS in an ARRAY (256,512) statement; that error is corrected
JCLQAWPS in WPS 2.3.4, now the required release of WPS for MXG.
QASAS UTILGETM was originally used only in the JCLTESTx job, to
UTILGETM create the SMFSMALL file of 10 records per ID, but it was
VMXGGETM not included in the MXG QA tests until now. UTILGETM
Nov 15, 2008 invokes %VMXGGETM with JCLTEXTx defaults, but VMXGGETM
Nov 18, 2008 was previously enhanced (with no Change) to also print an
QAWPS excellent report of the SMF record ID and Subtypes found,
with both record count AND record BYTES. You can use:
// EXEC MXGSASV9
//SMF DD DSN=YOUR.SMF,DISP=SHR
%VMXGGETM(SMFOUT=,FREQ=YES);
to produce only the report.
-PROC TABULATE generated an innocuous, yet annoying
WARNING: Dimension crossing has multiple format modifiers.
message that was eliminated by the addition of a separate
FORMAT statement for ID and SUBTYPE variables, thanks to
SAS Technical Support.
Thanks to Alf-Terje Thomassen, Ergo Group, NORWAY.
Change 26.257 Corrections/enhancements for Omegamon CICS user SMF data.
VMAC112 Previously, three subtypes, 200 (INTR), 201 (SYSR) and
VMACOMCI 203 (ONDV) were written as user SMF records, supported
Nov 16, 2008 by MXG TYPEOMCI code, in Versions V550 and earlier, but
now, in Version V560, only subtype 203 is created, and it
is written as SMF ID=112 (now that Candle was absorbed
into IBM, they can use "IBM" SMF record numbers!).
MXG has supported the SMF 112 for some time, but in this
revisions, errors in the DataCom and MQ count/clocks were
found and corrected, so this change is now required.
-Only TYPEOMCI supports all three (200,201,203) subtypes,
but only for Version V550 and earlier.
-TYPE112 supports only subtype 203, because V560 only
creates that subtype, and only as SMF ID=112 records.
However, with this change, the TYPE112 code reads both
the new V560 and old V550 format subtype 203 records.
This change in VMAC112 tests ID=112 OR ID=_IDOMCI, so if
you have defined MACRO _IDOMCI nnn % in IMACKEEP for
your current OMCI User SMF record number, those records
and new SMF 112s will be read automatically.
-Or, you can set _IDOMCI "instream" using:
//SYSIN DD *
%LET MACKEEP= MACRO _IDMOCI nnn % ;
%INCLUDE SOURCLIB(TYPE112);
-The dataset names created for TYPE112 Subtype 203 are
different in TYPE112, starting with T112xxxx, instead
of the old OMCIxxxx dataset names, but all old variable
names are still created in the new-named datasets.
This text replaces Change 26.160, as it is/was incorrect.
-The Datacom counts/clocks were wrong in TYPEOMCI support
but were correct in TYPE112; four pairs of variables,
DTCNT/DTCLK/DTFCNT/DTFCLK 02,07,09,14 did not exist in
the records, but the old OMCI code input them, causing
other variables to have incorrect values.
-The 24 MQ counts did not exist; there are 8 pairs of MQ
clocks and counters now correctly input, and the MQ
filename was truncated.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 26.256 MXG 26.09 only. %ANALDB2R(PDB=SMF); i.e., reading SMF to
ANALDB2R create DB2 reports, caused many errors, starting with
TESTANAL ERROR: OLD-STYLE MACRO NAME % MUST CONTAIN ONLY LETTERS,
Nov 13, 2008 DIGITS, AND UNDERSCORES.
The error has existed for some time, caused by recursive,
mis-located include of VMACDB2 when SMF is read, and it
can be circumvented by using %READDB2 to read SMF, and
then use %ANALDBR only to create reports. The default
reports with %ANALDB2R(PDB=SMF); can be created using
%READDB2(PDB=SMF,PDBOUT=WORK,IFCIDS=ACCOUNT 106);
%ANALDB2R(PDB=WORK);
RUN;
until you install this corrected ANALDB2R. The MXG QA
stream tested only %ANALDB2R(PDB=PDB,...), but now a
new test of %ANALDB2R(PDB=SMF,...) is added.
Thanks to Dan Almagro, Automobile Club of South California, USA.
Change 26.255 -ASMVTOC updated to prevent ABEND when it scanned a device
ASMVTOC that was pending offline.
VMACCTLG -VMACCTLG syntax error for missing "B" in two bit tests
VMXGINIT for IF GDGATTR='1.......'.
EXCTLGE4 -User coded enhancements to Catalog Processing:
Nov 11, 2008 (a) Write observation to CTLGDSN for each Generation
Dec 23, 2008 Dataset (GDS) so this dataset includes an observation
for each non-vsam dataset.
(b) Write observation to CTLGVSAM for each AIX dataset.
Since AIX datasets exist in a Cluster Sphere, the
cluster gets written to the CTLGVSAM with the last
AIX data and index component names.
(c) When writing out the observation for CTLGVSAM, write
out the volumes used for the index separate from
the volumes used for the data component.
(d) Added support for Connector Records (a user catalog
connected to the master catalog). A Connector Record
is composed of a Name Cell c'U', an Owner Cell x'01',
0 or more Association Cells x'03', and a Volume Cell
x'04'.
(e) Use of the CATRECNR to merge the observations
together in the different datasets is problematic
when AIX datasets are involved. This change tracks
the sphere cluster name, the aix cluster name, and
the component name; these are output into the Vsam,
Association, and Volume datasets. Also, the
Generation Dataset (GDS) Name is output when writing
the Volume dataset, updating the tracking of volumes,
so that the volumes are associated with the specific
Generation Dataset.
-Additional protection/corrections made Dec 23, 2008.
Thanks to Ken Sharpe, Oklahoma Dept of Human Services, USA.
Change 26.254 Support for MAINVIEW for CICS 6.1 CMRDETL (INCOMPATIBLE).
EXMVCIC1 and support for 6.2 new data.
EXMVCIC2 The new 'F7'x records contain expanded 12-byte time data,
EXMVCICC so this change is required to process the new release.
EXMVCICE The support for the File segments is enhanced, with new
EXMVCICO datasets for CONNECT/SESSION, DB2, DBCTL, MQ and OTHER,
EXMVCICQ with their unique variables, so the existing CMRFILE
IMACMVCI dataset now contains only the CICS FILE segment data.
VMACMVCI The complete set of datasets now created are:
VMXGINIT dddddd Dataset Description
Nov 9, 2008 MVCICS CMRCICS MAINVIEW CICS CMRDETL DATA
Nov 10, 2008 MVCICC CMRFCON MAINVIEW CICS CMRDETL FILE CONNECT
MVCICE CMRFSES MAINVIEW CICS CMRDETL FILE SESSION
MVCICF CMRFILE MAINVIEW CICS CMRDETL FILE CICS
MVCICO CMRFCON MAINVIEW CICS CMRDETL FILE OTHER
MVCICQ CMRFCON MAINVIEW CICS CMRDETL FILE MQ
MVCIC1 CMRFCON MAINVIEW CICS CMRDETL FILE DBCTL
MVCIC2 CMRFCON MAINVIEW CICS CMRDETL FILE DB2
Thanks to Henk van der Veur, Fortis, THE NETHERLANDS.
Change 26.253 VM/ESA 2.5 1.22 record caused BROKEN CONTROL RECORD error
VMACVMXA as the support for that record was added for z/VM 5.3
Nov 7, 2008 and expected an 88-byte, versus 84 byte, record segment.
Note that this was VERY archaic VM/ESA data being tested
as part of a QA job, and is NOT a current z/VM error.
Change 26.252 In VMXGDEL, IF %UPCASE(&USERWORK) function caused ERROR:
ANALACTM A character operand was found in the %EVAL function
GRAFWORK or %IF condition where a numeric operand is required.
GRAFWRKX when the SAS WORK option was WORK=HFS:/usr/lpp/.../work.
GRAFWORX Those forward slashes were seen as divide-by operations
READDB2 by the macro compiler. By replacing IF %UPCASE(&xxx)
VMXGDEL syntax with %IF %QUPCASE(&xxx) function, that %QUPCASE
VMXGGETM function "quotes" the text strings, preventing the macro
Nov 7, 2008 compiler from seeing the slashes as an operator. Only
VMXGINIT VMXGDEL caused an error, but all IF %UPCASE(&xxx)
Nov 10, 2008 statements, where &xxx could contain a libref text, were
identified and corrected in the other listed members.
However, in addition, VMXGINIT was revised, to add a test
for a forward slash for unix (like the existing test for
a back slash for NT) when it sets the "WORK" librefs.
Thanks to Brian Watts, Dept of Education, Employment, AUSTRALIA.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 26.251 Cosmetic, but wrong. The $MG110TT format for TRANTYPE
FORMATS had 'E2C4'X='SD:BY ADI WITH DATA' but that is changed to
Oct 31, 2008 have 'E2C4'X='SD:BY ATI WITH DATA'.
Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 26.250 -The four variable sets G1vvvvvv-G4vvvvvv in BVIR33 have
VMACBVIR the data for the first four clusters, but documentation
Oct 31, 2008 of this Hnode Grid Historical Record says there can be a
Nov 13, 2008 maximum of eight clusters, so new sets G5vvvvvv-G8vvvvvv
are now created, labeled, and kept.
-Variable DVMXMT00 was not kept due a typo in the KEEP=.
Thanks to Harald Seifert, HUK-COPBURG, GERMANY.
Thanks to Jens Mohring, HUK-COPBURG, GERMANY.
Thanks to Francois Vancoppenolle, Rainbow ICT, BELGIUM.
Change 26.249 The Two _Sdddddd Data Set SORT macros for ABARS HSM data,
VMACHSM _SHSMWWF and _SHSMWWV still contained DATA steps rather
Oct 30, 2008 than PROC SORTs, which could cause NOT SORTED errors.
The DATA step is coded when new datasets are created, as
the PROC SORT NODUP can't be added until I have test data
to know what BY variables are required for duplicate
removal. I assume I just forgot to go back when I finally
got ABARS test data to validate their _Bdddddd macros.
Thanks to Christine Wong, MMSA, USA.
Change 26.248 Member IMACKEEP is now included by ANALSMF after the
ANALSMF MACRO _MYCISIZ is defined, so &MACKEEP can be used to
Oct 29, 2008 change that definition. Last update to ANALSMF was 1996!
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 26.247 Support for SMF 113. Incomplete, do not use.
VMAC113 Test SMF data is needed to finish writing the support
Oct 29, 2008 for this new monitor record. See Change 27.002.
Change 26.246 Three RMF III pre-emptable SRB CPU time variables were
VMACRMFV wrong, by a factor of 1000, because their informat was
Oct 28, 2008 incorrect. Now, all three are correctly input as
ASIPHTMA &PIB.4.3 /*PREEMTEABLE*CLASS*SRB*TIME*/
ASIPHTZA &PIB.4.3 /*PREEMPTABLE*SRB*FOR ZAAPS*/
ASIPHTZI &PIB.4.3 /*PREEMPTABLE*SRB*FOR ZIIPS*/
ASIPHTMA was informat PIB4., and is now TIME12.2 format,
ASIPHTZA and ASIPHTZI were informat PIB4.6.
Thanks to Graham Harris, Royal Bank of Scotland, ENGLAND.
Thanks to Matt Ellis, Royal Bank of Scotland, ENGLAND.
Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.
Change 26.245 Change 26.207 (MXG 26.08) added variables JXSLMJ1 JXSLMJ2
VMACTPMX in dataset TYPETPMX, but labeled them as UNKNOWN. They
Oct 27, 2008 now renamed and correctly labeled:
JXSLMNGD='JXSLM*MANAGED'
JXSLSRVC='JXSLM*SERVICE'
Using an old MXG Version (prior to 26.08) to read SMF
records with either field caused this MXG message:
***ERROR.VMACTPMX. VARNAME=$JXSLMJ_ NOT FOUND,
TOKFIELD=$JXSLMJ_ WAS NOT INPUT.
TOKENID=53613 TOKENID=D16D TOKNAME=$JXSLM FLENGTH=1
Thanks to ???, BOA, USA.
Thanks to Nancy DiFilippo, MVS Solutions Inc, USA.
Change 26.244 Variable MIPS was not being calculated for WORKLOAD=0,
GRAFWRKX the uncaptured work, causing confusing graphs when the
Oct 27, 2008 MSU and MIPS were compared.
Thanks to Jorge Fong, DOITT NYC, USA.
Change 26.243 Support for OA21140 - High Performance FICON (zHPF) and
FORMATS RMF HiperDispatch enhancements.
VMAC7072 -TYPE70 existing SMF70Q00-SMF70Q12 counts of IN AND READY
VMAC73 users previously were based on the number of processors
VMAC74 that were online; now, with this APAR installed and with
VMAC79 HiperDispatch Active, the count is based on the number of
Oct 27, 2008 processors being ONLINE AND NOT PARKED when the sample
Nov 2, 2008 was taken.
Nov 10, 2008 -TYPE70 new variable SMF70NRM='zIIP*NORMALIZATION*FACTOR*/
-TYPE70PR field SMF70POF creates two new variables:
POLARITY='POLARIZATION'
0='0:Horizontally Polarized or not indicated'
1='1:Vertically Polarized Low Entitlement'
2='2:Vertically Polarized Medium Entitlement'
3='3:Vertically Polarized High Entitlement'
Variable POLARITY is decoded by new MG070PO format.
POLARCHG='POLARITY*CHANGED?'
value of Y if polarization was changed during interval.
-TYPE73 dataset has these new zHPF variables:
CHFACTV ='FICON*OPERATIONS*CONCURRENTLY*ACTIVE'
CHFDFER ='FICON*OPERATIONS*DEFERRED*PER SEC'
CHFRATE ='FICON*OPERATIONS*PER SEC'
CHFXACTV='ZHPF*OPERATIONS*CONCURRENTLY*ACTIVE'
CHFXDFER='ZHPF*OPERATIONS*DEFERRED*PER SEC'
CHFXRATE='ZHPF*OPERATIONS*PER SEC'
SMF73ECP='CHANNEL*PATH*IDENTIFICATION'
SMF73EIX='INDEX TO*EXTENDED*CHANNEL*MEASUREMENTS'
SMF73EOC='FICON*COMMAND MODE*OPERATIONS*ATTEMPTS'
SMF73EOD='FICON*COMMAND MODE*OPERATIONS*NOT INIT'
SMF73EOS='SUM COUNT OF*COMMAND MODE*OPERATIONS'
SMF73ETC='FICON*TRANSPORT MODE*OPERATIONS*ATTEMPTS'
SMF73ETD='FICON*TRANSPORT MODE*OPERATIONS*NOT INIT'
SMF73ETS='SUM COUNT OF*TRANSPORT MODE*OPERATIONS'
-TYPE74 dataset has this new variable:
R744FLPN='PARTITION*IDENTIFIER*OF CF'
-TYPE79C dataset for subtype 12 has the same new zHPF
fields as those added to TYPE73, above, but the SMF73
is changed to R79 to be consistent with existing TYPE79s.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Thanks to Brian Currah, Independent Consultant, CANADA.
Change 26.242 Enhancements to internal utility functions/programs.
ANAL115 -VMXGOPTR is used to store, set, and restore SAS options,
ANALCISH but only supported one option. Now, multiple options can
ANALRMFR be handled, but multiple new values must be separated by
ANALTCP exclamation points, because values can contain blanks:
VGETOBS %VMXGOPTR(OPTNAME=OP1 OP2 OP3,NEWVALUE=V1!V2!V3);
VMXGOPTR -VGETOBS could fail if no DDNAME was specified.
Oct 27, 2008 -ANALCISH, ANALRMFR, ANALTCP, and ANAL115 all now use the
VGETOBS macro instead of the archaic internal OBSCHEK.
Change 26.241 Extra data in LINUXKRNL '02'x Processor Record caused the
VMACVMXA BROKEN CONTROL RECORD error message. The CONTROL RECORD
Oct 23, 2008 was fine: any MXG out-of-alignment in z/VM MONWRITE data
Oct 30, 2008 surfaces with that error. The MXG circumvention to skip
the hundreds of extra bytes in the record based on NRCPUS
was defective and those extra bytes are now unilaterally
skipped, to eliminate the circumvention and exposure.
This problem was only observed in Release 3.5 data; the
data from z/VM 5.4 does not have any extra bytes.
-Divide by zero in daccumulation of VXAPLTCP dataset due
to insufficient BY list - variable CLUSNAME must be used.
Thanks to Nick Altieri, Wachovia Bank, USA.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
====== Changes thru 26.240 were in MXG 26.09 dated Oct 20, 2008=========
Change 26.240 Variable TRNOTCON is a time of day, and not a datetime
VMACCIMS value, even though it's input as TODSTAMP8, so it is now
Oct 20, 2008 TIMEPARTed and formatted TIME12.2.
Thanks to Kenneth D. Jones, Bell Aliant, CANADA
Thanks to Bruce Perry, Bell Aliant, CANADA
Change 26.239 Cosmetic. The CASE THREE example, in comments only in
IMACUOW VMXGUOW, is now in comments in IMACUOW, and all three of
Oct 17, 2008 the examples are documented completely in both members.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 26.238 Utility to PROC PRINT with the LABEL and VARIABLE NAME as
UPRINDOC the header is enhanced so you can select how many obs are
Oct 17, 2008 printed and change the Line Size if desired. This is NOT
an elegant implementation, but it works, and is very good
for investigation of new data sources so you can see both
the name and the label. Every dataset in the PDB library
is PRINTed, and a PROC MEANS N MEAN MIN MAX; is run with
all observations in each dataset, to show the statistics
of each numeric variable.
Previously, it was hard-coded to print only the first 9
obs, (for the ADOC members) with fixed line size.
Change 26.237 Support for MACRO _GRPNAME was incomplete in ASUMTAPE but
ASUMTAPE is now corrected, and the ASUMTAPE dataset now is output
Oct 17, 2008 with the _LSUTAPE macro, defined as &PSUTAPE..ASUMTAPE,
to be more consistent with MXG naming conventions. The
previous output was just to &PDBMXG..ASUMTAPE, but as the
default for PDBMXG and PSUTAPE are both //PDB, and it is
unlikely that you would have changed, this change SHOULD
be transparent.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.236 Sites with HiperDispatch enabled, only. The Parked Time,
VMAC7072 CPUPATTM could be missing in PDB.TYPE70, causing PCTMVSBY
Oct 17, 2008 to be too large and CPUMVSTM to be too SMALL, with wrong
values also in variables SHORTCPS & PLCPRDYQ, if a system
had offline CP engines (see Changes 26.197 and 26.192).
Those engines have IFARRAY=CP, but their parked time is a
missing value. The real culprit was this add statement:
IF IFARRAY(LCPUADDR+1)=0 THEN
CPUPATTM=CPUPATTM+PATWAIT(LCPUADDR+1);
which sets CPUPATTM to missing when PATWAIT is missing.
I should have added a test for PATWAIT non-missing, but I
instead now use the SUM() function in this revision:
IF IFARRAY(LCPUADDR+1)=0 THEN
CPUPATTM=SUM(CPUPATTM,PATWAIT(LCPUADDR+1));
to preserves the CPUPATTM value when PATWAIT is missing.
Your existing PDB.TYPE70 data can be corrected without
re-reading the SMF data, using this program:
DATA NEW.TYPE70;
SET OLD.TYPE70;
IF CPUPATTM=. THEN DO;
CPUPATTM=SUM(OF
CPUPATM0-CPUPATM9 CPUPATMA CPUPATMB CPUPATMC CPUPATMD
CPUPATME CPUPATMF CPUPATMG CPUPATMH CPUPATMI CPUPATMJ
CPUPATMK CPUPATML CPUPATMN CPUPATMO CPUPATMP CPUPATMQ
CPUPATMR CPUPATMS CPUPATMT CPUPATMU CPUPATMV CPUPATMW
CPUPATMX CPUPATMY CPUPATMZ CPUPATZA CPUPATZB CPUPATZC
CPUPATZD CPUPATZE CPUPATZF CPUPATZG CPUPATZH CPUPATZI
CPUPATZJ CPUPATZK CPUPATZL CPUPATZM CPUPATZN CPUPATZO
CPUPATZP CPUPATZQ CPUPATZR CPUPATZS CPUPATZT CPUPATZU
CPUPATZV CPUPATZW CPUPATZX CPUPATZY CPUPATZZ CPUPATYA
CPUPATYB CPUPATYC );
IF CPUPATTM GT 0 THEN
CPUMVSTM=CPUUPTM-MVSWAITM-CPUPATTM;/*-SMF70PAT*/
ELSE CPUMVSTM=CPUUPTM-MVSWAITM;
IF CPUUPTM GT 0 THEN DO;
PCTCPUBY=100*CPUACTTM/CPUUPTM;
PCTCPUEF=100*CPUEFFTM/CPUUPTM;
IF CPUPATTM GT 0 THEN /*PER OA24074*/
PCTMVSBY=100*CPUMVSTM/(CPUUPTM-CPUPATTM);
ELSE PCTMVSBY=100*CPUMVSTM/CPUUPTM;
END;
IF CPUACTTM=. AND CPUPDTTM=. AND PCTCPUBY=. AND
PCTMVSBY GT 0 AND CPUMVSTM GT 0 THEN DO;
PCTCPUBY=PCTMVSBY;
CPUACTTM=CPUMVSTM;
END;
IF PCTMVSBY GT 0 AND PCTCPUBY GT 0 THEN DO;
SHORTCPS=PCTMVSBY/PCTCPUBY;
PLCPRDYQ=100*(PCTMVSBY-PCTCPUBY)/PCTMVSBY;
IF . LT PLCPRDYQ LT 0 THEN DO;
SHORTCPS=1;
PLCPRDYQ=0;
END;
END;
ELSE DO;
SHORTCPS=.;
PLCPRDYQ=.;
END;
END;
RUN;
Thanks to Frank De Bree, DEXIA, BELGIUM.
Thanks to Christine De Clercq, DEXIA, BELGIUM.
Change 26.235 Running the IEBUDPTE.SAS program on Linux to read a file
IEBUPDTE that was created on Windows caused characters '0D'x (CR
Oct 15, 2008 or Carriage Return) to be treated as a data byte. This
is because when unix files are written, only a '0D'x CR
is written to terminate each line, while Windows files
are terminated with a '0D0A'x CRLF (CR plus Line Feed).
So SAS under unix only looks for an LF line terminator.
To get SAS under unix/linux to read a Windows file and
not store the '0D'x as data, the TERMSTR=CRLF option
must be specified on the INFILE statement. This id
documented in the SAS Companion for unix INFILE note at:
http://support.sas.com/documentation/cdl/en/
hostunx/59542/HTML/default/chifoptfmain.htm
Fortunately, TERMSTR=CRLF works under Windows, so it can
be added unconditionally to the INFILE statement and now
that program will run on all ascii platforms.
Thanks to Steve Clark, DHL IT Services Americas, USA.
Thanks to Jan Squillace, SAS Technical Support, USA.
Change 26.234 Strange ORACLE SMF records, with none of the offsets that
VMACORAC are expected, but with an offset in a formerly reserved
Oct 15, 2008 field, followed by variable length text data, are now
detected and the first 500 instance printed for tests.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 26.233 Dataset DB2STAT4 contains IFCID=225 in DB2 V9 as noted in
READDB2 the text of Change 25.090; now, READDB2 is enhanced to
Oct 14, 2008 create both datasets T102S225 and DB2STAT4 when IFCID=225
has been requested; observations from DB2 V8 or V7 will
be in T102S225 and from V9 or later in DB2STAT4, but the
variable names are the same. Jan 2009: See Change 26.311
which actually made the change correctly in READDB2.
Change 26.232 Reserved Change Number
Change 26.231 Variable MEMLIMIT printed ERROR for '00000FFFFFFFF000'x,
FORMATS but the Installation Exits manual discussion of MEMLIMIT
VMAC30 under IEFUSI (how's that for obscure SMF documentation)
Oct 10, 2008 notes that that value is set when MEMLIMIT is NOLIMIT.
Unfortunately, there's no easy way out, to print NOLIM
for that value, because MEMLIMIT is FORMATted with the
standard MGBYTES decoding format, used for all byte vars.
So, new MG030ME format is created MEMLIMIT, and the above
hex value sets MEMLIMIT=. so NOLIM is printed.
Thanks to Dan Case, Mayo Clinic, USA.
Change 26.230 Variable QPACPAC was incorrectly set in DB2ACCTP whenever
VMACDB2 variable QPACCLS7='Y'. QPACPAC was set from the same bit
Oct 7, 2008 in QPACFLGS after QPACCLS7 had been set.
Thanks to Don Cleveland, Wellpoint, USA.
Change 26.229 MQ variables QWHCPST and QWHCPSB for IMS access were
VMAC116 only correct for WTIDATYP=3; the MXG test for IMS should
Oct 4, 2008 have input those fields for 3 or 4, but code had 2 and 3.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.228 Example to report DASD Storage Group summarization using
ASUMSTGP MXG's DCOLLECT data.
GRAFSTGP - ASUMSTGP creates PDB.ASUMSTGP summary by storage group
TRNDSTGP and DSNAME.
Oct 3, 2008 - TRNDSTGP creates PDB.TRNDSTGP trending summary
- GRAFSTGP produces graph of allocated and used space
from the TREND data.
Larry Douty, ExxonMobile, USA.
Change 26.227 Previously, VMXGSUME protected for variables that did not
VMXGSUME exist in the incoming datasets, but changes to VMXGSUM
Oct 3, 2008 now provide that same protection, so there is no need for
a separate VMXGSUME member. So now, VMXGSUME will just
bring in the standard VMXGSUM member, and any references
in your code to use %VMXGSUME can be changed to %VMXGSUM,
or any %INCLUDE SOURCLIB(VMXGSUME); can be removed, but
those statements do not HAVE to be changed, as long as
you do NOT have your own VMXGSUME member in tailoring
libraries.
Change 26.226 Reserved Change Number.
Oct 2, 2008
Change 26.225 Variable QPACAAFG was still wrong after Change 26.080, as
VMACDB2 it is INPUT in two places, but only the first was fixed.
Oct 2, 2008
Thanks to Glenn Bowman, Wakefern, USA.
Change 26.224 NMON variables that did not have a decimal point in the
VMACNMON data were incorrectly input by MXG's 6.1 format, so they
Oct 2, 2008 were small by a factor of 10, and fields with more than
6 digits were truncated; both errors were due to the use
of INPUT(field,6.1) syntax, which divides by 10 when the
field does not contain a decimal point, and only reads in
the first six digits. Each variable in each MXG dataset
has now been validated against the NMON xls file after
this (embarrassing!) correction, and all are created with
INPUT(field,16.0) syntax.
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 26.223 Support for NSM VMWARE ESX 2.5.5 formerly a/k/a TNG has
EXTVW020 ten new datasets for these new objects:
EXTVW021
EXTVW022 dddddd dataset description
EXTVW023
EXTVW024 VW020 VW020 VMWARE ENGINE CPU
EXTVW025 VW021 VW021 VMWARE ENGINE DISK
EXTVW026 VW022 VW022 VMWARE ENGINE MEMORY
EXTVW027 VW023 VW023 VMWARE ENGINE NETWOR
EXTVW028 VW024 VW024 VMWARE ENGINE SYSTEM
EXTVW029 VW025 VW025 VMWARE VM CPU
FORMATS VW026 VW026 VMWARE VM DISK
IMACTNG VW027 VW027 VMWARE VM MEMORY
VMACTNG VW028 VW028 VMWARE VM NETWORK
VMXGINIT VW029 VW029 VMWARE VM SYSTEM
Oct 3, 2008
Thanks to Michael Kynch, International Paper, USA.
Change 26.222 Extremely large values in CPUIFATM, CPUIFETM, IFAUNITS in
VMAC7072 TYPE72GO observations in an interval in which an operator
Sep 30, 2008 varies a CP engine on or offline were caused by invalid
values in R723IFAT and R723IFCT. IBM determined that the
CONFIG command invokes IRAEVCFG to recalculate RMCTADJC,
and when IWMRCOLL is invoked, IRAWRARC converts these
service units into microseconds using RMCTADJC (SU_SEC).
In the specific case, RMCADJC was x'194' prior to vary
and was x'166' after, which caused IFAT and IFCT to be
lower in the second IWMRCOLL, creating a "negative" value
i.e., first bit on, which MXG sees as a large positive.
IBM said it is not possible to fix because the microsecs
are correct based on the current RMCTADJC value; however
IBM support noted that the service unit values in fields
R723CIFA and R723CIFC were correct because they are not
adjusted by RMCTADJC, so IBM's permanent solution is for
MXG to recalculate CPUIFATM and CPUIFETM from service
units and to no longer use R723IFAT and R723IFCT values.
The defective fields, R723IFAT and R723IFCT were the
original IFA times, from which MXG IFAUNITS/IFEUNITS
were originally created. The recommended fields now
used, R723CIFA and R723CIFC were added by the APAR
that also added the zIIP service unit values that MXG
has always used to create the zip CPU times, so it is
consistent now to use all those service unit fields for
both zAAP and zIIP CPU times and service units.
This change implements that IBM solution.
Jul 29, 2010: Variables R723IFAT and R723IFCT are set to
a missing value to avoid confusion. The
APAR mentioned was OA13499, Change 24.046!
Thanks to Dianne Gamarra, IBM Level 2 Support, USA.
Thanks to Frank De Bree, DEXIA, BELGIUM.
Thanks to Christine De Clercq, DEXIA, BELGIUM.
Thanks to Eugent Van Ossalaer, DEXIA, BELGIUM.
Change 26.221 Support for IBM DS8000 2107 SAN Disk Controller stats in
EXSVCCP SVCPerfStats xml files, creates five statistics datasets:
EXSVCMD MACRO INFILE DDDDDD DATASET
EXSVCNO
EXSVCPO _TSVCMD SVCMDISK SVCMD SVCMDISK
EXSVCVD
IMACSVC _TSVCNOD SVCNODE SVCCP SVCCPBSY
TYPESVC SVCNO SVCNODE
TYPSSVC SVCPO SVCPORT
VMACSVC
VMXGINIT _TSVCVD SVCVDISK SVCVD SVCVDISK
Sep 28, 2008
Oct 20, 2008 The support for this data source requires an extra file,
named TEMPSVC, which is written to and read from, to
prevent thousands of lines to be written on the SAS log.
For ASCII execution,
FILENAME TEMPSVC 'C:\tempsvc' LRECL=52;
For z/OS execution,
//TEMPSVC DD UNIT=SYSDA,SPACE=(CYL,(100,100)),
// RECFM=VB,LRECL=512,BLKSIZE=0
Both SVC 4.1 and SVC 4.2 data has been tested.
The order of the SVCMDISK, SVCNODE, or SVCVDISK DD is
not important; use DD DUMMY if you don't want to read
an XML file. Example JCL to process SVC data:
// EXEC MXGSASV9
//PDB DD DSN=YOUR.SVC.OUTPUT.PDB,DISP=(NEW .....
//TEMPSVC DD UNIT=SYSDA,SPACE=(CYL,(100,100)),
// RECFM=VB,LRECL=512,BLKSIZE=0
//SVCMDISK DD DSN=YOUR.MDISK.FILE01.DATA,DISP=SHR
// DD DSN=YOUR.MDISK.FILE02.DATA,DISP=SHR
// DD DSN=YOUR.MDISK.FILENN.DATA,DISP=SHR
//SVCNODE DD DSN=YOUR.MDISK.FILE01.DATA,DISP=SHR
// DD DSN=YOUR.MDISK.FILE02.DATA,DISP=SHR
// DD DSN=YOUR.MDISK.FILENN.DATA,DISP=SHR
//SVCVDISK DD DSN=YOUR.MDISK.FILE01.DATA,DISP=SHR
// DD DSN=YOUR.MDISK.FILE02.DATA,DISP=SHR
// DD DSN=YOUR.MDISK.FILENN.DATA,DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(TYPSSVC);
This was my first venture into reading XML files; these
are directly created by the disk controller monitor, and
no predecessor "flat file" exists. Unfortunately, these
XML documents are not "well-formed" which could have been
directly read with the SAS XML engine; a well-formed XML
document has a matching end-tag for each start-tag, but
these documents often have only the start-tag. SAS does
provide a separate facility for these "non-generic" XML
documents, but it involves writing a tag-specific XML map
document that tells SAS how to read the XML document, but
that would require a significant redesign of MXG to have
a matching pair of "documents", a program and an XML map,
for each of the XML files to be read, with new naming .
conventions, etc. Instead, I wrote this support in SAS
data steps, using SAS NAMED INPUT (well suited to the XML
data format of tag1="value1" tag2=="value2"). Also, as
the monitor data is accumulated, additional DATA steps
would be required after the initial input.
One real negative of having to read XML documents instead
of a simple binary file is the massive increase in data
volume. For example, the VDISK file contained 1,143,405
physical records, but there were only 70,160 observations
created from that XML file.
Part of that volume is due to the monitor's design: it
creates a separate document for each interval, but all of
the documents must be read and sorted so the values can
be deaccumulated. There were 400 mdisk documents daily,
which were concatenated and read in a single data step,
but that generated 160,000 lines of the SAS log, because
each of those 400 input events not only print the file
name being read, but repeats the full "file list" of all
400 files! As a result, that first data step is wrapped
in an OPTIONS NONOTES to suppress that unwanted printing.
Users HAVE experienced problems attempting to ftp the xml
files to z/OS, because the files are "unix-format" files
that are created on Windows, and they are terminated ONLY
with LF (0Ax) and not the normal-for-windows-files CRLF
(0D0Ax).
One user was able to ftp the xml files to z/OS using:
ascii
quote site recfm=fb lrecl=2000 blksize=2000
put stats.xml 'uuuuuuuu.stats.xml' lf
where the z/OS ftp server was IBM FTP CS V1R8.
However, another user's ftp failed with IBM FTP CS V1R7.
(The ftp executed, but created a single record with the
'0A'x treated as data, and that record was truncated at
the LRECL length. That user found this IBM documentation
note in the IP User's Guide and Commands manual:
"The z/OS FTP server supports only the CRLF value for
incoming data."
After using a hex editor to change '0A'x to '0D0A'x they
were able to ftp the IBM xml file to the IBM ftp server.
This Windows command will change the '0A'x to '0D0A'x:
TYPE unix_file | FIND "" /V > dos_file
so the file can be ftp'd to an IBM ftp server on z/OS.
And for completeness, if the LF-only file is on a unix
system, you can use this Unix command to convert to CRLF:
unix2dos old.xml new.xml
prior to the ftp-ing.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Thanks to Steve Foskett, Lloyds TSB, ENGLAND.
Thanks to MP Welch, SPRINT, USA.
Change 26.220 Example report for Service Class percent CPU busy revised
ANALSRVC to show how to change the interval of the report, and the
Sep 27, 2008 default now produces hourly percent busy, and EXCSP are
added to the totals for each interval.
Thanks to Lisa Lawver, Land's End, USA.
Change 26.219 Change 26.101 was not implemented; the semicolon at the
VMXGFOR end of %VMXGFOR was still present. However, only very
Sep 26, 2008 old user code in tailoring library are exposed, since
all %VMXGFOR calls were removed in all MXG code in 2003
by Change 20.327. Note that Change 23.127 also claimed
of have removed this semicolon, but it didn't!
Thanks to Pius Nwaobasi, IBM Global Services, USA.
Change 26.218 RMF III variables ASIRNM, Reporting Class Name and ASIRDE
VMACRMFV Reporting Class Description were blank due to a misplaced
Sep 24, 2008 IF statement.
Thanks to Betty Wong, Bank of America, USA.
Change 26.217 Revised QA JOB stream example, and cosmetic cleanups.
ANALCNCR The old multi-step JCL used for MXG QA tests were needed
BATDOIT back in SAS V6 because it couldn't handle a single step,
JCLQASAS but for some time the PC QA stream has run only a single
JCLQAWPS SAS datastep. First one-step z/OS runs failed with JCL
PRODSRCE issues, because the QA "PDB" data library is used with
PRODTEST multiple LIBREFs (PDB,MON,TUE..,WEEK1..,MONTH...) but on
QASAS z/OS you couldn't use the same temporary DSN. Finally,
TESTANAL Chuck figured out what JCL referbacks were needed, so the
TRNDCICX PROC COPYs (a holdover from when the multi-step required
UTILVREF them) could be eliminated, and they were really a killer;
VMXGCICI PC run time of the QA dropped from over an hour to only
Oct 21, 2008 10 minutes; z/OS run time dropped from xx to yy.
Nov 15, 2008 QASAS now documents the MXG QA job stream in comments.
BATDOIT is the batch file I use to run QASAS.
PRODTEST is the IEBUPDTE-format directory used in QA job.
PRODSRCE creates PRODTEST from c:\QA\prodtest directory.
-Many members still had SASAUTOS=SOURCLIB in OPTIONS or in
JCL examples, but MXG's CONFIGV9 or AUTOEXEC now set all
options, including SASAUTOS=(SASAUTOS SOURCLIB) so these
old examples were actually wrong. Their existence in the
ANALxxxx member actually caused errors when they reset
SASAUTOS to only SOURCLIB, preventing %TRIM and other SAS
%MACROs that are provided in their SASAUTOS to be found.
-JCL with // EXEC SAS and // EXEC SAS,OPTIONS= ... were
replaced, where appropriate, with // EXEC MXGSASV9.
Many of these old examples also had //SOURCLIB or even
//SASLIB (archaic since SAS V5); all of those DDs were
deleted from examples as they are contained in MXGSASV9
JCL procedure example.
These members were cosmetically revised:
achap21 achap31 achap32 adoctrnd aixpds analbnc1
analbnch analcm29 analnpmr analnspy analpdsm analrrtm
analturn analvary analvm analvmdy analvmos asummips
docgraf doctrend exitmon6 grafhsm grafregr graftalo
graftmnt graftrnd grafwork grafworx jclpdb multivol
newsltrs rexxtes6 rexxwlm sas5fix1 senddata trndtmnt
typedms typeslri typsims1 utildocv utilspac utilvone
vmacndm vmxguse vmxgvtoc vmxgvtof xcompall xibmfdp
xjclcomp xmacsar xnpmsess xsyslog zrbbuild zrbjcl
zrbrpt1 zrbrpt2 analsupr
-VMXGCICI caused WARNING on COLLTIME when VMXGSUME used;
COLLTIME should be only in SUMBY and DATATIME= so it was
removed from ID statement.
-ANALCNCR caused WARNING on TIMESTMP when VMXGSUME used;
old logic similar to VMXGCICI was revised.
-COMPALL was tested, creating 1871 datasets in a single
DATA step compiling all MXG datasets created from SMF:
Compiler Platform Run Time Memory Required
SAS 9.1.3 Win/XP 75 seconds 1100 MB
WPS 2.2 Win/XP 120 seconds same box
SAS 9.1.3 z/OS 93 seconds 1145 MB
WPS 2.2 z/OS 32 minutes 1024 MB
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to MP Welch, SPRINT, USA.
Thanks to Rich Anderson, SAS Technical Support, USA.
Change 26.216 -The ZIPUSED MSU was incorrect; obviously, CPUZIPTM should
ASUMMIPS have been used instead of CPUIFATM.
Sep 23, 2008 -If the same name was used for both a Service Class and a
Sep 28, 2008 Reporting Class, the PDB.RMFMSUSE dataset had incorrect
values in RPRTCLAS, CPUTM, and the MSU and MIPS used.
-Change 26.131 added ZIP/ZAP metrics, but only to _RMFMIPS
causing UNINITIALIZED VARIABLE messages when _SMFMIPS was
executed. Now, both _RMFMIPS and _SMFMIPS report on all
three engine types.
Thanks to Don Goulden, SAS Institute, USA.
Thanks to Robert Kuhne, Excelon Corp, USA.
Change 26.215 NDM-CDI subtype 'UC' was not output, because it was not
VMACNDM in the initial test for known subtypes, but it was in the
Sep 23, 2008 test and is now output in the NDMAE dataset.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 26.214 Protection for invalid extended segment did not cover
VMAC1415 all cases; protection and error message revised, could
Sep 17, 2008 still cause INPUT STATEMENT EXCEEDED RECORD error.
Thanks to Mayer Rosenthal, Infocrossing, USA.
Change 26.213 Support for new data in NTDS and ASP.NET Applications
VMACNTSM objects in NTSM adds these new variables:
Sep 16, 2008 -Dataset ASPNETAP new variables:
Sep 17, 2008 ASPARWTB ASPACMLU ASPACMLB ASPACPLU
ASPACPLB ASPACTTR ASPACATR ASPAOCTR
-Dataset NTDS new variables:
NTDSLNCS NTDSLCCS NTDSLNSC NTDSDPRO NTDSTGNC NTDSTGHS
NTDSLVUR NTDSTURP NTDSDWFN NTDSDSFN NTDSDRFN NTDSSAEL
NTDSSREL
Also, the XDS and LDAP Binds variables no longer exist.
-Dataset MEMORY had all variables missing when NRDATA=40,
due to my careless testing.
Thanks to Lisa E. Van Allen, Boeing, USA.
Thanks to James A. Young, Boeing, USA.
Change 26.212 Change 25.308 for SAS V9.2 corrected three instances of
VMXGSUME %ELSE %THEN %DO statements to %ELSE %DO, but two members
UTILBLDP were overlooked, VMXGSUME and UTILBLDP.
Sep 16, 2008 The symptoms of the V9.2-only error is this message
Sep 18, 2008 ERROR: THERE IS NO MATCHING %IF STATEMENT FOR THE %THEN.
A DUMMY MACRO WILL BE COMPILED.
Thanks to Kim Westcott, OFT, State of New York, USA.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 26.211 Cosmetic. Labels for G3DTIN01-07, G4DTIN01-07 were blank
VMACBVIR (they were caught in QA reports, but I overlooked them!).
Sep 16, 2008 Some duplicate labels were also removed.
Thanks to Markus Bansemir, HUK-Coburg, GERMANY.
Change 26.210 Support for Landmark The Monitor for DB2 V 4.1 raw data.
VMACTMDB -Dataset TMDBD7P adds new variables:
Sep 18, 2008 D7QAASC D7QAAWLG D7QAAWTI D7QAAWTJ D7QAAWTL D7QABPID
D7QADBID D7QAOBID D7QAOCUR D7QAOTSN D7QAOTTY D7QASDB2
D7QASDYN D7QASFL1 D7QASFL2 D7QASTAB D7QASTET D7QATRET
D7QAUDEA
-Dataset TMDBDB adds new variables:
DBACTRTE DBACTREE DBACSVPT DBACRLSV DBACRBSV DBACAWTK
DBACAWTM DBACAWTN DBACAWTO DBACAWTQ DBACARNK DBACARNM
DBACARNN DBACARNO DBACARNQ DB1ZIIP DB2ZIIP DBTZIIP
DBEZIIP DBFIL71 DBFIL72 DBFIL73 DBFIL74 DBAXAWFC
DBAXFCCT DBAXIXLE DBAXIXLT DBSETCPR DBDCLGTT DBDEGDTT
DBCRESEQ DBALTSEQ DBDROSEQ DBPRRESI DBALTVW DB0112IW
DB0112SC DB0112CC DB0112OF DB0112LN DB0112OH DBASHSQL
DBASLSQL SQLIDLEN SQLIDNAM
-Dataset TMDBDA2 adds new variables:
DAMSPSRB DAMSZSRB DADSPSRB DADSZSRB DAISPSRB DAISZSRB
DXSPSRB DAXSZSRB DASSPSRB DASSZSRB DAXSETCP DAXDCLGT
DAXDEGDT DAXCRESQ DAXALTSQ DAXDROSQ DAXPRESI DAXALTVW
DASEDFAL DASEDPGE DASEDFRE DASEDYNP DASECFAL DASECPGE
DASECFRE DAISTCOL DADNDBA DADPOOL DAGSFLMG DABSTLPL
DABPFIX DABVDQB DABSLA DABPGST DABGLGG DABGLHS
DABGL2H DABGLP1 DABGLP2 DABGLP3 DABGLU1 DABGLS1
DABGLS2 DABGLS3 DABGLN1 DABGLN2 DABGLN3 DA3STHWB
DA3STHWF DA3STHWC DA9STCX4 DAJSLSUS DAJSLOGW DAJSCIWR
DAJSSERW DAJSTHRW DAJSBPAG
Thanks to Martin Legendre, Regie des rentes du Quebec, CANADA.
====== Changes thru 26.209 were in MXG 26.08 dated Sep 12, 2008=========
Change 26.209 Enhancement for reading DB2 SMF records adds new parms:
READDB2 SMFOUT= DDNAME to which SMF records that met selection
Sep 12, 2008 criteria will be written
Change 26.208 Variables SMF30MLS and MEMLIMIT are now kept in BUILDPDBs
BUILD005 PDB.STEPS dataset. Previously, they were kept only in
BUIL3005 PDB.SMFINTRV and PDB.TYPE30U6.
Sep 11, 2008
Thanks to Paul Naddeo, FISERV, USA.
Change 26.207 Support for Thruput Manager Subtype 7, and new fields:
EXTPM701 -Dataset TPMXSLM new variables
EXTPM702 TPMSLXGN='EXECUTION*START*TIME'
EXTPM703 TPMSLXGF='EXECUTION*END*TIME'
EXTPM704 While the DSECT used LXTN,LXTF, those datetime fields do
EXTPM705 already exist, and these new fields, while DSECT'd as
EXTPM706 TODSTAMP, in fact, contain only TIME12.2 time-of-day.
IMACTPMX -Support for subtype 7 creates six new datasets:
VMACTPMX dddddd Dataset Description:
VMXGINIT TPM701 TPM0701 SERVER ENVIRONMENT
Sep 12, 2008 TPM702 TPM0702 GENERAL SERVICES QUEUE
TPM703 TPM0703 1ST DISCRETIONARY QUEUE
TPM704 TPM0704 SERVICES GROUP QUEUE
TPM705 TPM0705 JESPLEX MEMBER STATUS
TPM706 TPM0706 INTERVAL DATA
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.206 CICS/TS 3.2 BMC optional CMRDATA increased to 256 bytes
IMACICMR as CPU time fields were increased from 4 to 8 bytes, but
Sep 5, 2008 MXG's IMACICMR had not been updated for 3.2, causing
ERROR: INVALID STRTTIME when IMACICMR was tailored and
read 3.2 data. Turns out IMACICMR never decoded times
correctly, even with earlier CICS releases, but now both
old and new records are correctly decoded. There are 16
undocumented bytes at the end of the CMRDATA segment that
will be decoded if they are ever populated by BMC.
Thanks to Barry T. Mueller, RiteAid, USA.
Change 26.205 Change 26.115 erroneously added SYSNAME to the BY list
WEEKBLDT for TYPE892 dataset, causing WEEKBLDT to fail with
Sep 4, 2008 ERROR: VARIABLE SYSNAME NOT FOUND.
Thanks to Mark W. Brown, CapGemini, ENGLAND.
Change 26.204 New fields and new subtypes for Shadow USER SMF records:
EXSHDW05 -New variables in SHADOW01 dataset:
EXSHDW18 SM01ADCT=*ADABAS*COMMAND*COUNT'
IMACSHDW SM01CLRC=*CLIENT*READ*DATA*COUNT'
VMACSHDW SM01CLWT=*CLIENT*WAIT*TIME'
VMXGINIT SM01HONA=*HOST*NAME*CLMI'
Sep 3, 2008 SM01LNID=*CLIENT*LAN*NETWORK*USERID'
SM01SRCP=*SRB*CPU*TIME'
-New variables in SHADOW02 dataset:
SM02CLRC='CLIENT*READ*DATA*COUNT'
SM02CLWT='CLIENT*WAIT*TIME'
SM02ENZC='ENCLAVE*ZIIP*TIME*ON CP'
SM02ENZI='ENCLAVE*ZIP*CPU*TIME'
SM02ENZQ='ENCLAVE*ZIP*QUALIFIED*CPU TIME'
SM02MXUS='MAX*INTERVAL*CONCURRENT*USERS'
SM02RPCU='CURRENT*NUMBER*EXECUTING*RPCS'
SM02RPHW='RPC*HIGH*WATER*MARK'
SM02SLCP='SSL*CPU*TIME'
SM02SRCP='SRB*CPU*TIME'
-New SHADOW05 dataset for SHADOW NON SOAP REQUEST:
SM0501CR='WWW RULE*CRITERION*MATCH*STRING'
SM0501EU='RUNTIME*MVS*USERID*IN EFFECT'
SM0501RL='WWW RULE*EVENT*PROCEDURE*MEMBER NAME'
SM0501RS='WWW*RULE EVENT*PROCEDURE*SET NAME'
SM05ABCD='TRANSACTION*ABEND*CODE'
SM05ABRS='TRANSACTION*REASON*CODE'
SM05ADLT='TRANSACTION*CONNECT*TIME*LOCAL'
SM05AUTH='CLIENT*AUTHORIZATION*STATUS'
SM05CLIP='CLIENT*IP*ADDRESS'
SM05CLIP='CLIENT*IP*ADDRESS'
SM05CLUS='CLIENT*USER*ID'
SM05CNID='CONNECTION ID'
SM05DBCP='DB2*CPU*TIME'
SM05ELTM='TRANSACTION*ELAPSED*TIME'
SM05ENCP='ENCLAVE*CPU*TIME'
SM05INUR='ORIGINAL*INBOUND*URL*VALUE'
SM05IPAC='IPADDRESS*OF*CLIENT*HEX'
SM05IPAD='IP*ADDRESS'
SM05LGTM='TRANSCTION*CONNECT*TIME*GMT'
SM05LSCR='WWW RULE*CRITERION*MATCH*STRING'
SM05LSEU='RUNTIME*MVS*USERID*IN EFFECT'
SM05LSRL='WWW RULE*EVENT*PROCEDURE*MEMBER NAME'
SM05LSRS='WWW*RULE EVENT*PROCEDURE*SET NAME'
SM05MTCT='COUNT OF*URL*MATCHES*PROCESSED'
SM05NTCP='NETWORK*CPU*TIME'
SM05OHCP='OTHER*CPU*TIME'
SM05PDSS='PRODUCT*SUBSYSTEM*NAME'
SM05RDTO='TOTAL*BYTES*SENT*INBOUND'
SM05RESC='COUNT OF*URL*RE-SCANS'
SM05RPCP='USER*PROGRAM*CPU*TIME'
SM05RXCP='SHADOW/REXX*CPU*TIME'
SM05SLCP='SSL*PROCESSING*CPU*TIME'
SM05SMID='HOST*SYSTEM*SMFID'
SM05SRCP='SRB*CPU*TIME'
SM05TRRC='OVERALL*RETURN*CODE'
SM05TRRS='REASON*CODE'
SM05TRST='HTML*STATUS*CODE'
SM05USR1='USER*DATA*AREA*1'
SM05USR2='USER*DATA*AREA*2'
SM05WRTO='TOTAL*BYTES*WRITTEN'
-New SHADOW05 dataset for SHADOW Z/SERVICES:
SM18ABCD='TRANSACTION*ABEND*CODE'
SM18ABRS='TRANSACTION*REASON*CODE'
SM18ADLT='TRANSACTION*CONNECT*TIME*LOCAL'
SM18AUTH='CLIENT*AUTHORIZATION*STATUS'
SM18CLIP='CLIENT*IP*ADDRESS'
SM18CLUS='CLIENT*USER*ID'
SM18CNID='CONNECTION ID'
SM18DBCP='DB2*CPU*TIME'
SM18ELTM='TRANSACTION*ELAPSED*TIME'
SM18ENCP='ENCLAVE*CPU*TIME'
SM18ENZC='ENCLAVE*ZIIP*TIME*ON CP'
SM18ENZI='ENCLAVE*ZIIP*CPU TIME'
SM18ENZQ='ENCLAVE*ZIIP*QUALIFIED*CPU TIME'
SM18INUR='ORIGINAL*INBOUND*URL*VALUE'
SM18IPAC='IPADDRESS*OF*CLIENT*HEX'
SM18IPAD='IP*ADDRESS'
SM18LGTM='TRANSCTION*CONNECT*TIME*GMT'
SM18MTCT='COUNT OF*URL*MATCHES*PROCESSED'
SM18NASP='WEB*SERVICE*NAME*SPACE'
SM18NTCP='NETWORK*CPU*TIME'
SM18OHCP='OTHER*CPU*TIME'
SM18PDSS='PRODUCT*SUBSYSTEM*NAME'
SM18PORT='CLIENT*AUTHORIZATION*STATUS'
SM18RCCT='TRANSACTION*COUNT*FOR*SUMMARY*RECORD'
SM18RCTY='CLIENT*AUTHORIZATION*STATUS'
SM18RDTO='TOTAL*BYTES*SENT*INBOUND'
SM18RPCP='USER*PROGRAM*CPU*TIME'
SM18RXCP='SHADOW/REXX*CPU*TIME'
SM18SLCP='SSL*PROCESSING*CPU*TIME'
SM18SMID='HOST*SYSTEM*SMFID'
SM18SRBT='SRB*CPU*TIME'
SM18SRCP='SRB*CPU*TIME'
SM18TRFX='SOAP*FAULT*TEXT'
SM18TRRC='OVERALL*RETURN*CODE'
SM18TRRS='REASON*CODE'
SM18TRSE='SOAP*FAULT*LENGTH'
SM18TRST='HTML*STATUS*CODE'
SM18TYPE='CLIENT*AUTHORIZATION*STATUS'
SM18VDIR='VIRTUAL*DIRECTORY'
SM18WRTO='TOTAL*BYTES*WRITTEN'
SM18WSNA='WEB*SERVICE'
SM18WSOP='OPERATION*NAME'
SM18WSTG='TARGET*SYSTEM*NAME'
Thanks to Scott Chapman, American Electric Power,USA.
Change 26.203 Support for z/VM 5.4 (COMPATIBLE back to MXG 25.05) adds
EXMTRMCC new 5.4 variables and two new datasets, but there are
EXSTOADD 600 variables added by z/VM 5.3, now supported by MXG in
FORMATS this change.
IMACVMXA NEW MONWRITE DATASETS CREATED BY z/VM 5.4:
VMACVMXA
VMXGINIT -Dataset VXMTRMCC (1.21) MEMORY CONFIGURATION CHANGE:
Sep 1, 2008 SYSGSTBY='STANDBY*CENTRAL*STORAGE*SIZE'
SYSGSTRS='RESERVED*CENTRAL*STORAGE*SIZE'
-Dataset VXMTRMCC (1.21) MEMORY CONFIGURATION CHANGE:
CALMEMAD='ADDITIONAL*CENTRAL*STORAGE'
CALSXSAD='ADDITIONAL*SXS*STORAGE'
UPDATES TO EXISTING MONWRITE DATASETS FOR 5.3 and 5.4:
-Dataset VXSYTPRP (0.2) new variables in 5.4:
PFXFST44='FASTPATH*SIMULATIONS*OF DIAGNOSE*X44'
PFXFSTPX='FASTPATH*PARTIAL*EXECUTE*INTERRUPTS'
PFXFSTSG='FASTPATH*SIMULATIONS*SIGP EXT CALL*INTS'
PFXFSTXC='FASTPATH*REFLECTIONS*GUEST EXT CALL*INTS'
-Dataset VXSYTRSG (0.3) new variables (added in 5.3):
RSADRMA1='STOLEN*GT 2G*DORMANT*PASS 1='
RSADRMA2='STOLEN*GT 2G*DORMANT*PASS 2='
RSADRMAE='STOLEN*GT 2G*DORMANT EMERG*PASS='
RSADRMB1='STOLEN*LT 2G*DORMANT*PASS 1='
RSADRMB2='STOLEN*LT 2G*DORMANT*PASS 2='
RSADRMBE='STOLEN*LT 2G*DORMANT EMERG*PASS='
RSADRMC1='STOLEN*CONTIG GT 2G*DORMANT*PASS 1='
RSADRMC2='STOLEN*CONTIG GT 2G*DORMANT*PASS 2='
RSADRMCE='STOLEN*CONTIG GT 2G*DORM EMERG*PASS='
RSADRMD1='STOLEN*CONTIG LT 2G*DORMANT*PASS 1='
RSADRMD2='STOLEN*CONTIG LT 2G*DORMANT*PASS 2='
RSADRMDE='STOLEN*CONTIG LT 2G*DORM EMERG*PASS='
RSADSPA1='STOLEN*GT 2G*DISPATCH*PASS 1='
RSADSPA2='STOLEN*GT 2G*DISPATCH*PASS 2='
RSADSPAE='STOLEN*GT 2G*DISPATCH EMERG*PASS='
RSADSPB1='STOLEN*LT 2G*DISPATCH*PASS 1='
RSADSPB2='STOLEN*LT 2G*DISPATCH*PASS 2='
RSADSPBE='STOLEN*LT 2G*DISPATCH EMERG*PASS='
RSADSPC1='STOLEN*CONTIG GT 2G*DISPATCH*PASS 1='
RSADSPC2='STOLEN*CONTIG GT 2G*DISPATCH*PASS 2='
RSADSPCE='STOLEN*CONTIG GT 2G*DISPATCH EMERG*PASS='
RSADSPD1='STOLEN*CONTIG LT 2G*DISPATCH*PASS 1='
RSADSPD2='STOLEN*CONTIG LT 2G*DISPATCH*PASS 2='
RSADSPDE='STOLEN*CONTIG LT 2G*DISPATCH EMERG*PASS='
RSAELGA1='STOLEN*GT 2G*ELIGIBLE*PASS 1='
RSAELGA2='STOLEN*GT 2G*ELIGIBLE*PASS 2='
RSAELGAE='STOLEN*GT 2G*ELIGIBLE EMERG*PASS='
RSAELGB1='STOLEN*LT 2G*ELIGIBLE*PASS 1='
RSAELGB2='STOLEN*LT 2G*ELIGIBLE*PASS 2='
RSAELGBE='STOLEN*LT 2G*ELIGIBLE EMERG*PASS='
RSAELGC1='STOLEN*CONTIG GT 2G*ELIGIBLE*PASS 1='
RSAELGC2='STOLEN*CONTIG GT 2G*ELIGIBLE*PASS 2='
RSAELGCE='STOLEN*CONTIG GT 2G*ELIGIBLE EMERG*PASS='
RSAELGD1='STOLEN*CONTIG LT 2G*ELIGIBLE*PASS 1='
RSAELGD2='STOLEN*CONTIG LT 2G*ELIGIBLE*PASS 2='
RSAELGDE='STOLEN*CONTIG LT 2G*ELIGIBLE EMERG*PASS='
RSALTDA1='STOLEN*GT 2G*LONG TERM*DORMANT*PASS 1='
RSALTDA2='STOLEN*GT 2G*LONG TERM*DORMANT*PASS 2='
RSALTDAE='STOLEN*GT 2G*LNGTRMDORM EMERG*PASS='
RSALTDB1='STOLEN*LT 2G*LONG TERM*DORMANT*PASS 1='
RSALTDB2='STOLEN*LT 2G*LONG TERM*DORMANT*PASS 2='
RSALTDBE='STOLEN*LT 2G*LNGTRMDORM EMERG*PASS='
RSALTDC1='STOLEN*CONTIG GT 2G*LNGTRMDORM*PASS 1='
RSALTDC2='STOLEN*CONTIG GT 2G*LNGTRMDORM*PASS 2='
RSALTDCE='STOLCONTIG GT 2G*LNGTRMDORM EMERG*PASS*
RSALTDD1='STOLEN*CONTIG LT 2G*LNGTRMDORM*PASS 1='
RSALTDD2='STOLEN*CONTIG LT 2G*LNGTRMDORM*PASS 2='
RSALTDDE='STOLCONTIG LT 2G*LNGTRMDORM EMERG*PASS='
RSARESAC='RESIDENT*PTRM PAGES GT 2G='
RSARESBC='RESIDENT*PTRM PAGES LT 2G='
RSASHRA1='STOLEN*GT 2G*SHARED*PASS 1=' ='
RSASHRA2='STOLEN*GT 2G*SHARED*PASS 2='
RSASHRAE='STOLEN*GT 2G*SHARED EMERG*PASS='
RSASHRB1='STOLEN*LT 2G*SHARED*PASS 1='
RSASHRB2='STOLEN*LT 2G*SHARED*PASS 2='
RSASHRBE='STOLEN*LT 2G*SHARED EMERG*PASS='
RSASHRC1='STOLEN*CONTIG GT 2G*SHARED*PASS 1*='/
RSASHRC2='STOLEN*CONTIG GT 2G*SHARED*PASS 2*='/
RSASHRCE='STOLEN*CONTIG GT 2G*SHARED EMERG*PASS='
RSASHRD1='STOLEN*CONTIG LT 2G*SHARED*PASS 1*='/
RSASHRD2='STOLEN*CONTIG LT 2G*SHARED*PASS 2*='/
RSASHRDE='STOLEN*CONTIG LT 2G*SHARED EMERG*PASS='
-Dataset VXSYTRSP (0.4) new variables (added in 5.3):
PLSALECG='TIMES WHEN*GT 2G*CONTIG LIST*EMPTY'
PLSALECL='TIMES WHEN*LT 2G*CONTIG LIST*EMPTY'
PLSALEMG='TIMES WHEN*AVAIL GT 2G*LIST EMPTY'
PLSGCLEM='TIMES WHEN*GLOBAL*CLEAR LIST*EMPTY'
PLSMVABV='TIMES WHEN*PAGE LT 2G*MOVED GT 2G'
PLSMVB2G='PAGE TRANS*MOVED GT 2G*TO LT 2G'
-Dataset VXSYTSCG (0.10) new variables (added by 5.3):
SRME0ETF='ELAPSED*TIME*SLICE*TIME FACTOR'
-Dataset VXSYTCOM (0.11) new variables (added by 5.3):
PLSISEAS='TIMES WHEN*XFER*FROM*ASYNCMD*TO A VM'
PLSISESC='TIMES WHEN*XFER*FROM*SCLP*TO A VM'
PLSISEVE='TIMES WHEN*XFER*FROM*VMEVENT*TO A VM'
PLSISEVS='TIMES WHEN*XFER*FROM*VSWITCH*TO A VM'
PLSISTAS='TIMES WHEN*TRANSFER*TO*ASYNCMD'
PLSISTSC='TIMES WHEN*TRANSFER*TO*SCLP'
PLSISTVE='TIMES WHEN*TRANSFER*TO*VMEVENT'
PLSISTVS='TIMES WHEN*TRANSFER*TO*VSWITCH'
PLSISUAS='TIMES WHEN*FROM ASYNCMD*NOT*XFERED'
PLSISUSC='TIMES WHEN*FROM SCLP*NOT*XFERED'
PLSISUVE='TIMES WHEN*FROM VMEVENT*NOT*XFERED'
PLSISUVS='TIMES WHEN*FROM VSWITCH*NOT XFERED'
-Dataset VXSYTUWT (0.12) new variables in 5.4:
CALCFICF='VMDBKS*DSP LIST*WAIT ICF*CONSOLE*FUNCTON*/
CALCRICF='VMDBKS*DSP LIST*RUNNING*ON REAL ICF*/
CALCWICF='VMDBKS*DSP LIST*WAIT ICF*CPU WAIT*/
CALLLICF='VMDBKS*DSP LIST*WAIT ICF*MAX SHARE DELAY*/
CALSWICF='VMDBKS*DSP LIST*WAIT ICF*SIMULATE*WAIT*/
-Dataset VXSYTSCP (0.13) new variables (added by 5.3):
PLXCPUTH='CPU*TYPE'
PLSDSPCN='TIME WHEN*DSP LOOPED*200 TIMES'
-Dataset VXSYTSCP (0.14) new variables in 5.4:
TCMPINVA='PAGE FAULTS*RESOLVED*NO-4K*CASE'
TCMSTKEX='CPEBK*DEFERRED*WRITES'
TCMSTKPF='CPEBK*DEFERRED*PAGE FAULT*PRIORITY'
-Dataset VXSYTSYG (0.19) new variables in 5.4:
MAIMISS ='MISSING*ADAPTER*INTERRUPTIONS'
MAIUREC ='UNRECOVERABLE*ADAPTER*INTERRUPTIONS'
-Dataset VXSYTSXG (0.21) new variables (added in 5.3):
RSARSVSY='TOTAL*RESERVED*PAGES'
RSASXACT='SYS EXEC SPACE*BACKED*GT 2G*AVAIL Q'
RSASXALI='SYS EXEC SPACE*ALIAS*FRMTES*PAGES'
RSASXAVL='SYS EXEC SPACE*AVAILABLE*PAGES'
RSASXBCT='SYS EXEC SPACE*BACKED*LT 2G*AVAIL Q'
RSASXBKA='SYS EXEC SPACE*BACKED*GT 2G*PAGES'
RSASXBKB='SYS EXEC SPACE*BACKED*LT 2G*PAGES'
RSASXCLA='SYS EXEC SPACE*ALIAS*LOCKED*PAGES'
RSASXNOP='SYS EXEC SPACE*ALIAS*NO-OWNED*PAGES'
RSASXQCT='SYS EXEC SPACE*UNBLOCKED*AVAIL*PAGES'
RSASXUCP='SYS EXEC SPACE*INUSE*AS CP*PAGES'
RSASXUFG='SYS EXEC SPACE*BACKING*GT 2G*PAGES'
RSASXUFS='SYS EXEC SPACE*LT 2G*PAGES'
RSASXUID='SYS EXEC SPACE*ID-MAPPED*PAGES'
RSASXUSD='SYS EXEC SPACE*INUSE*DEFERRED*PAGES'
SXSSIZE ='SYS EXEC SPACE*SIZE IN*PAGES'
-Dataset VXSYTSXP (0.22) now supported (added in 5.3):
PFXCPUAD='PROCESSOR*ADDRESS'
PFXCPUTY='CPU TYPE'
PLSSPFSC='HCPSXPFS*CALLS'
PLSSPGCC='CONTIG*SYS EXEC SPACE*GT 2*PAGE REQUESTS'
PLSSPGCT='CONTIG*SYS EXEC SPACE*GT 2*GIVEN OUT'
PLSSPGFC='FREE STORAGE*PAGES*GIVEN OUT'
PLSSPGPC='SINGLE*NON-CONTIGUOUS*PAGES*GIVEN OUT'
PLSSPRCC='CONTIG*SYS EXEC SPACE*GT 2*RETURNS'
PLSSPRCT='CONTIG*SYS EXEC SPACE*GT 2*RETURNED FOR'
PLSSPRFC='FREE STORAGE*PAGES*RETURNED'
PLSSPRPC='SINGLE*NON0CONTIG*PAGES*RETURNED'
PLSSPRQC='SYS EXEC SPACE*RETURNS*OF QUEUES'
PLSSPRQT='SYS EXEC SPACE*RETURNS*VIA QUEUES'
PLSSXACC='CREATE*ALIAS*REQUESTS'
PLSSXAQC='QUEUE*SXSTE*REQUESTS*TO REQUEUE'
PLSSXARC='REMOVE*ALIAS*REQUESTS'
PLSSXREP='AVAILABLE*REPLENISHMENTS*ATTEMPTED'
-Dataset VXSYTSLCK(0.23) now supported (added in 5.3):
CALLCKID='IDENTIFIER*FOR THIS*LOCK'
CALSSCNT='TIMES LOCK*SPUN FOR*SHARED*MODE'
CALSTIME='ELAPSED*SPIN TIME*FOR*SHARED*MODE'
CALXSCNT='TIMES LOCK*SPUN FOR*EXCLUSIVE MODE'
CALXTIME='ELAPSED*SPIN TIME*FOR*EXCLUSIVE'
-Dataset VXSYTSXP (0.24) now supported (added in 5.3):
CALTYPE ='PROCESSOR*TYPE'
SRXABSDL='ABSOLUTE*SHARES*DSPLIST*VMDBKS'
SRXATOD ='ARTIFICIAL*TOD*SYSTEM*RUNNING'
SRXATOD2='ARTIFICIAL*TOD2*USER TIME*AND CPU WAIT'
SRXCONLL='USERS*ACTUALLY*ON LIMIT*LIST'
SRXLLCNT='ADDS*TO THE*LIMIT*LIST'
SRXRELDL='TOTAL*RELATIVE*SHARES*DSPLIST*VMDBKS'
-Dataset VXMTRSYS (1.4) new variable in 5.4:
SYSCMODE='PROCESSOR*CONFIGURATION*MODE'
-Dataset VXMTRDEV (1.6) new variables (added by 5.3):
CDVFLAGS='CALDEVFLAGS'
DVPTHCN1='EDEVPATHCONN 1'
DVPTHCN2='EDEVPATHCONN 2'
DVPTHCN3='EDEVPATHCONN 3'
DVPTHCN4='EDEVPATHCONN 4'
DVPTHCN5='EDEVPATHCONN 5'
DVPTHCN6='EDEVPATHCONN 6'
DVPTHCN7='EDEVPATHCONN 7'
DVPTHCN8='EDEVPATHCONN 8'
EDEVATTR='EDEV ATTRIBUTES
EDEVTABL='SCSI*DISK*ATTRIB*TABLE NAME'
PREFPATH='PREFERRED PATH MASK
RDEVHPPL='HYPERPAV POOL NUMBER
-Dataset VXMTRMEM (1.7) new variables added (by 5.3):
PFXFTLEN='FRAME*TABLE*LENGTH'
PFXSTLEN='SYS EXEC SPACE*MGMT TABLE*LENGTH'
RSAFNOTI='NOT*INITIALIZED*FRAMES GT 2G'
RSAGOFFL='OFFLINE*FRAMES*GT 2G'
RSALGFRM='USEABLE*FRAMES*GT 2G'
SXSSIZE ='SYS EXEC SPACE*SIZE IN*PAGES'
-Dataset VXMTRMEM (1.7) new variables added by 5.4:
SYSGSTBY='STANDBY*REAL*STORAGE*SIZE'
SYSGSTRS='RESERVED*REAL*STORAGE*SIZE'
-Dataset VXMTRUSR (1.15) new variables in 5.4
CALCPCT ='GUEST*DEFINED*CP*CPUS'
CALICFCT='GUEST*DEFINED*ICF*CPUS'
CALIFLCT='GUEST*DEFINED*IFL*CPUS'
CALZAPCT='GUEST*DEFINED*ZAAP*CPUS'
CALZIPCT='GUEST*DEFINED*ZIIP*CPUS'
CPHABSSH='CP*ABSOLUTE*SHARE*SETTING'
CPHFLG1 ='CP*SHARE*FLAGS'
CPHMXSHR='CP*MAX*SHARE*SETTING'
CPHRELSH='CP*RELATIVE*SHARE*SETTING'
ICHABSSH='ICF*ABSOLUTE*SHARE*SETTING'
ICHFLG1 ='ICF*SHARE*FLAGS'
ICHMXSHR='ICF*MAX*SHARE*SETTING'
ICHRELSH='ICF*RELATIVE*SHARE*SETTING'
IFHABSSH='IFL*ABSOLUTE*SHARE*SETTING'
IFHFLG1 ='IFL*SHARE*FLAGS'
IFHMXSHR='IFL*MAX*SHARE*SETTING'
IFHRELSH='IFL*RELATIVE*SHARE*SETTING'
VMDCFGEM='VIRTUAL*CONFIGURATION*INDICATORS'
VMDPUST ='CPU*STATUS*FLAG'
ZAHABSSH='ZAAP*ABSOLUTE*SHARE*SETTING'
ZAHFLG1 ='ZAAP*SHARE*FLAGS'
ZAHMXSHR='ZAAP*MAX*SHARE*SETTING'
ZAHRELSH='ZAAP*RELATIVE*SHARE*SETTING'
ZIHABSSH='ZIIP*ABSOLUTE*SHARE*SETTING'
ZIHFLG1 ='ZIIP*SHARE*FLAGS'
ZIHMXSHR='ZIIP*MAX*SHARE*SETTING'
ZIHRELSH='ZIIP*RELATIVE*SHARE*SETTING'
-Dataset VXSCLADL (2.04) new variables added by 5.3:
SRXABSDL='ABSOLUTE*SHARES*DSPLIST*VMDBKS'
SRXATOD ='ARTIFICIAL*TOD*SYSTEM*RUNNING'
SRXATOD2='ARTIFICIAL*TOD2*USER TIME*AND CPU WAIT'
SRXCONLL='USERS*ACTUALLY*ON LIMIT*LIST'
SRXLLCNT='ADDS*TO THE*LIMIT*LIST'
SRXRELDL='TOTAL*RELATIVE*SHARES*DSPLIST*VMDBKS'
VMDCFGEM='VIRTUAL*CONFIGURATION*INDICATORS'
VMDPUST ='CPU*STATUS*FLAG'
VMDTTMP ='USER*VTIME AND*SIMTIME*ON PRIMARY'
VMDTTMS ='USER*VTIME AND*SIMTIME*ON SECONDARY'
VMDVTMP ='USER*VTIME ON*PRIMARY*PROCESSOR'
VMDVTMS ='USER*VTIME ON*SECONDARY*PROCESSOR'
-Dataset VXSCLDDL (2.05) new variables added by 5.3:
VMDCFGEM='VIRTUAL*CONFIGURATION*INDICATORS'
VMDPUST ='CPU*STATUS*FLAG'
VMDTTMP ='USER*VTIME AND*SIMTIME*ON PRIMARY'
VMDTTMS ='USER*VTIME AND*SIMTIME*ON SECONDARY'
VMDVTMP ='USER*VTIME ON*PRIMARY*PROCESSOR'
VMDVTMS ='USER*VTIME ON*SECONDARY*PROCESSOR'
-Dataset VXSCLAEL (2.06) new variables added by 5.3:
VMDCFGEM='VIRTUAL*CONFIGURATION*INDICATORS'
VMDPUST ='CPU*STATUS*FLAG'
-Dataset VXSTORSG (3.01) new variables added by 5.3:
CALSSUBG='GT 2G*BLOCKS*FREE STORAGE*SUBPOOL*LIST'
RSA2GDCT='REQUESTS*AWAIT*ANY AVAILABLE*FRAME'
RSAAFSDB='LT 2G*HOST LOGICAL*ALIGNED*FREE STORAGE'
RSAAFSDW='GT 2G*HOST LOGICAL*ALIGNED*FREE STORAGE'
RSAAFSIB='LT 2G*HOST LOGICAL*ALIGNED*IN USE*BACKED'
RSAAFSIU='GT 2G*HOST LOGICAL*ALIGNED*IN USE*BACKED'
RSAALFMF='HCPALFMF*FREXSCAN*FRAMES*SCANNED'
RSAAVCHG='GT 2G CONTIG AVAIL LIST HI THRESH'
RSAAVCHT='LT 2G CONTIG AVAIL LIST HI THRESH'
RSAAVCLG='GT 2G CONTIG AVAIL LIST LOW THRES'
RSAAVCLT='LT 2G CONTIG AVAIL LIST LOW THRES'
RSAAVLHG='GT 2G*SINGLE FRAME*AVAIL*HIGH*THRESHOLD'
RSAAVLLG='GT 2G*SINGLE FRAME*AVAIL*LOW*THRESHOLD'
RSABLKGC='TASKS REQUESTING*OR DEFERRED*RSABLKGF'
RSACALLT='LOW THRESH*NON-NEGATIVE*FRMTES*NOT FREQUENT'
RSACALMT='MID THRESH*NON-NEGATIVE*FRMTES'
RSACALUT='UP THRES: NON-NEGATIVE*TARGET*FRMTES'
RSACPLKG='GT 2G*LOCKED*FRAMES*BY CP LOCK'
RSAEMBLO='TIMES*POOL BELOW*RSAEMLO'
RSAEMCPC='PGMBKS IN*EMERGENCY*POOL'
RSAEMDFR='TIMES*GUEST*DEFERRED*FOR EMERGENCY'
RSAEMERG='TIMES REQUEST*FOR*EMERGENCY*POOL'
RSAEMHI ='HI THRESH*EMERGENCY*PGMBK POOL'
RSAEMLO ='LOW THRESH*EMERGENCY*PGMBK POOL'
RSAEMPTY='TIMES*POOL*WENT*EMPTY'
RSAFRQDF='DEFERRED MULTIPLE FRAME REQUESTS'
RSAFRQDL='DELAYED*MULTIPLE*FRAME*REQUESTS'
RSAFRQMW='TASKS*ATTEMPTING*MULTIPLE*FRAMES*PGMBKS'
RSAFRQWT='LT 2G DEFERRED REQUESTS*NONE AVAIL'
RSAFRRDA='LT 2G*ATTEMPTS*TO REDRIVE*TASKS'
RSAFRRDC='LT 2G*REDRIVED*PERFORMED'
RSAFVMUB='LT 2G*VMDBK FREE STORAGE*IN USE'
RSAFVMUD='GT 2G*VMDBK FREE STORAGE*IN USE'
RSANOLKA='NO-OWNED*LOCKED PAGES*ABSOLUTE*STORAGE'
RSANOLKL='NO-OWNED*LOCKED PAGES*HOST LOCAL*STORE'
RSANPGCT='CONSECUTIVE*SXPFS*FAILURES'
RSANPGHI='HWM*CONSECUTIVE*SXPFS*FAILURES'
RSAPLPCB='PROCESSORS*LOOPING*IN HCPFRFGP*LT 2G'
RSAPLPCT='PROCESSORS*LOOPING*IN HCPFRFGP*GT 2G'
RSAPPTCS='ALB/TLB PURGES USING CSP'
RSAPPTPF='ALB/TLB*PURGES*FINISHED PRIOR TO'
RSAPPTPS='ALB/TLB*PURGES*PRIOR TO*ENTERING WAIT
RSARSVSY='PAGES*RESERVED*PER*PROCESSOR'
RSASTLWT='LT 2G*AVAIL LIST*REPLENISH*STEAL WRITES'
RSASWG2G='GT 2G*AVAIL LIST*REPLENISH*STEAL WRITES'
RSASWP2G='GT 2G REPLENIS*PAGE WRITES*TO DASE'
RSASWPWT='LT 2G REPLENIS*PAGE WRITES*TO DASE'
RSASXCLA='LOCKED*SYSEXSP*ALIAS*LOGICAL*IN LOGICAL'
RSASXCPL='LOCKED*SYSEXSP*ALIAS*LOGICAL*VIA CP LOCK'
RSASXNOP='NO-OWNED*SYS EXEC SPACE*ALIASES'
RSASYSFB='LT 2G*PAGES*IN USE FOR*SYSTEM*FREE STORE'
RSASYSFR='GT 2G*PAGES*IN USE FOR*SYSTEM*FREE STORE'
RSASYSUB='LT 2G*IN USE*SYSTEM*FREE STORAGE'
RSASYSUD='GT 2G*IN USE*SYSTEM*FREE STORAGE'
RSAVCBDB='LT 2G*VERIFIABLE*FREE*STORAGE*BACKED'
RSAVCBDW='GT 2G*VERIFIABLE*FREE*STORAGE*BACKED'
RSAVCBIB='LT 2G*VERIFIABLE*IN USE*FREE STORAGE'
RSAVCBIU='GT 2G*VERIFIABLE*IN USE*FREE STORAGE'
RSAVFSDW='VIRTUAL*FREE*STORAGE'
RSAVFSIU='VIRTUAL*FREE*STORAGE*IN USE'
RSAVMXFB='LT 2G*PAGES*USER FREE*IN USE'
RSAVMXFR='GT 2G*VMDBK*USER FREE*PAGES*ALLOCATED'
RSAVMXUB='LT 2G*IN USE*USER FREE*STORAGE'
RSAVMXUD='GT 2G*IN USE*USER FREE*STORAGE'
-Dataset VXSTOSHR (3.03) new variables added by 5.3:
ASCCTPRG='GT 2G*RESIDENT*PAGES'
ASCHLLC ='PAGES LOCKED*HOST LOG STORE'
ASCHLRC ='HOST*LOGICAL*RESIDENT*COUNT'
-Dataset VXSTOXSG (3.09) new variables added by 5.4:
XSTCTPGM='PGMBKS*SELECTED*WHILE*MIGRATING'
XSTMAXCT='TIMES*TARGET TIME*IS LOWERED'
XSTRHICT='TIMES*MIGRATE*THRES*BUFFER*DECREASED'
XSTRLOCT='TIMES*MIGRATE*THRES*BUFFER*INCREASED'
XSTUSRCY='NON-DORM*GUEST OWNED*ASIDS*MIGR TARGETS'
XSTUSRDM='DORM*GUEST OWNED*ASIDS*MIGR*TARGETS'
-Dataset VXSTOASI (3.14) new variables added by 5.3:
ASCCTPLK='GT 2G*PAGES*LOCKED*BY THIS*ASID'
ASCCTPRG='GT 2G*RESIDENT*PAGES*FOR ASID'
ASCHLLC ='PAGES LOCKED*IN HOST*LOGICAL*STORAGE'
ASCHLRC ='HOST*LOGICAL*RESIDENT*COUNT'
-Dataset VXSTOSCS (3.18) new variables added by 5.3:
CURRENT ='CURRENTLY*ALLOCATED*SUBPOOL*SIZE'
FREEF ='FAILED*FREE()*CALLS TO*SUBPOOL'
FREES ='FREE()*CALLS TO*SUBPOOL'
FRXPLEN ='SCSI*SUBPOOL*SIZE'
FRXROOT ='SSSI*SUBPOOL*ADDRESS'
MALLOC ='MALLOC()*CALLS TO*SUBPOOL'
MALLOCF ='FAILED*MALLOC()*CALLS TO*SUBPOOL'
MAXALLOC='HIGH WATER MARK*BYTES*ALLOCATED'
POOLNAME='POOL*NAME'
-Dataset VXSTOSXG (3.19) new variables added by 5.3:
RSASXAMX='GT 2G*MAX PAGES*BACKED'
RSASXBMX='LT 2G*MAX PAGES*BACKED'
RSASXCPL='SYSEXECSP*LOCKED*ALIAS*CP LOCK'
RSASXCTG='SYSEXECSP*IN USE*PAGES*CONTIG*REQ'
RSASXDCA='SYSEXECSP*CREATE*ALIAS*NOW DEFERRED'
RSASXDCT='SYSEXECSP*PAGE REQUESTS*NOW DEFERRED'
RSASXDFA='SYSEXECSP*PAGE REQUESTS*DEFERRED*ANY'
RSASXDFB='SYSEXECSP*LT 2G*REQUESTS*DEFERRED NOW'
RSASXDPA='SYSEXECSP*WITH BACKING*NOW DEFERRED'
RSASXDPB='SYSEXECSP*LT 2G*CURRENTLY*DEFERRED'
RSASXPCT='SYSEXECSP*POTENTIAL*STEALABLE*QUEUE'
RSASXQMN='THRESH*TRIGGER*REPLACEMENT*UNBACKED'
RSASXQRA='ALIASES*STOLEN*DURING*SINGLE*REPLEN'
RSASXRDA='ATTEMPTS*TO REDRIVE*TASKS*WAITING'
RSASXRDC='INDIVIDUAL*TASK*REDRIVES'
RSASXRPM='MIN NUMBER*ON UNBACKED*SXS PAGE QUEUE'
RSASXUOT='OTHER*CP*TYPE*PAGES'
-Dataset VXSTOSXP (3.20) new variables added by 5.3:
PFXCPUAD='PROCESSOR*ADDRESS'
PFXCPUTY='CPU*TYPE'
PLSSAPUC='GT 2G*AVAIL BACKED*WAS PREFERRED*AND USED'
PLSSAQMT='GT 2G*AVAIL BACKED*WAS PREFERRED*BUT EMPTY'
PLSSARTC='GT 2G*PAGES RETURNED TO*BACKED*AVAIL QUEUE'
PLSSATKC='GT 2G*TAKEN FROM*BACKED*AVAIL QUEUE'
PLSSBPUC='LT 2G*AVAIL BACKED*WAS PREFERRED*AND USED'
PLSSBQMT='LT 2G*AVAIL BACKED*WAS PREFERRED*BUT EMPTY'
PLSSBRTC='LT 2G*PAGES RETURNED TO*BACKED*AVAIL QUEUE'
PLSSBTKC='LT 2G*TAKEN FROM*BACKED*AVAIL QUEUE'
PLSSPDQC='HCPFRFDQ*CALLS*TO RELEASE*A PAGE'
PLSSPGBD='LT 2G*PAGE REQUEST*DEFERRED*ON FRAME'
PLSSPGFD='PAGE REQUESTS*DEFERED*ANY FRAME'
PLSSPGPD='PAGE REQUESTS*DEFERRED*ON PAGE'
PLSSPNDF='NON-DEFERRABLE*REQUESTS*FAILED*FRAME LACK'
PLSSPNDP='NON-DEFERRABLE*REQUESTS*FAILED*PAGE LACK'
PLSSUPUC='TIMES*AVAIL UNBACKED*WAS PREFERRED*AND USED'
PLSSUQMT='TIMES*AVAIL UNBACKED*WAS PREFERRED*BUT EMPTY'
PLSSURTC='PAGES*RETURNED TO*UNBACKED*AVAIL QUEUE'
PLSSUTKC='PAGES*TAKEN FROM*UNBACKED*AVAIL QUEUE'
PLSSXADC='LOCKED*ALIASES*DEQUEUED'
PLSSXAFC='NON-DEFERABLE*ALIAS*REQUEST*NOT FULFILLED'
PLSSXALD='CREATE*ALIAS*REQUESTS*DEFERRED'
PLSSXALS='ALIAS*STEALS*FROM POTENTIAL*AVAIL WAS EMPTY'
PLSSXASC='ALIAS STOLEN'
PLSSXCSP='CSP INSTRUCTIOS*TO INVALIDATE'
PLSSXIPC='IPTE INSTRUCTIONS*TO INVALIDATE'
PLSSXNST='RSASXNST*FLAG*TURN ONS'
-Dataset VXUSELON (4.01) and dataset VXUSELOF new
variables added by 5.4:
CPHABSSH='CP*ABSOLUTE*SHARE*SETTING'
CPHFLG1 ='CP*SHARE*FLAGS'
CPHMXSHR='CP*MAX*SHARE*SETTING'
CPHRELSH='CP*RELATIVE*SHARE*SETTING'
ICHABSSH='ICF*ABSOLUTE*SHARE*SETTING'
ICHFLG1 ='ICF*SHARE*FLAGS'
ICHMXSHR='ICF*MAX*SHARE*SETTING'
ICHRELSH='ICF*RELATIVE*SHARE*SETTING'
IFHABSSH='IFL*ABSOLUTE*SHARE*SETTING'
IFHFLG1 ='IFL*SHARE*FLAGS'
IFHMXSHR='IFL*MAX*SHARE*SETTING'
IFHRELSH='IFL*RELATIVE*SHARE*SETTING'
ZAHABSSH='ZAAP*ABSOLUTE*SHARE*SETTING'
ZAHFLG1 ='ZAAP*SHARE*FLAGS'
ZAHMXSHR='ZAAP*MAX*SHARE*SETTING'
ZAHRELSH='ZAAP*RELATIVE*SHARE*SETTING'
ZIHABSSH='ZIIP*ABSOLUTE*SHARE*SETTING'
ZIHFLG1 ='ZIIP*SHARE*FLAGS'
ZIHMXSHR='ZIIP*MAX*SHARE*SETTING'
ZIHRELSH='ZIIP*RELATIVE*SHARE*SETTING'
-Dataset VXUSEACT (4.03) new variables added by 5.4:
VMDCACHN='MINIDISK*CACHE*INSERTS'
VMDCTSTA='TIMES*CPU START*BY SIGP'
VMDCTSTO='TIMES*CPU STOP*BY SIGP'
VMDCUPGM='UNREFERENCED*PGMBKS*AT REORDER'
-Dataset VXUSEINT (4.04) new variables added by 5.4:
VMDCTSTA='TIMES*STARTED*BY SIGP'
VMDCTSTO='TIMES*STOPPED*BY SIGP'
-Dataset VXPRCAPC (5.09) new variables added by 5.3:
CRYNOFDQ='REAL*DQ*REQUESTS'
CRYNOFNQ='REAL*NQ*REQUESTS'
CRYNORPR='REAL*DQ*COMPLETIONS' (guess, mis-documented)
CRYNOVNQ='VIRTUAL*NQ*REQUESTS'
CRYNOVPC='VIRTUAL*DQ*COMPLETIONS'
CRYNOVPR='VIRTUAL*DQ*REQUESTS'
CRYNOWNQ='MESSAGES*WAITING*FOR NQ'
CRYNOXRN='REJECTED*REAL*NQ*REQUESTS'
CRYNOXVN='REJECTED*VIRTUAL*NQ*REQUESTS'
CRYRSERV='TIME FROM*REAL*NQ TO DQ'
CRYVSERV='TIME FROM*GUEST*NQ TO DQ'
-Dataset VXPRCINS (5.11) new variables added by 5.3:
PFXCPUAD='PROCESSOR*ADDRESS'
PLS0EPSW='EPSW*(B98D)'
PLS0ESEA='ESEA*(B99D)'
PLS0STFL='STFL*(B2B1)'
PLSBISAS='STAP*(B212)'
PLSBISBT='TB*(B22C)'
PLSBISCP='STIDP*(B202)'
PLSBISIU='IUCV*(B2F0)'
PLSBISPB='PTLB*(B20D)'
PLSBISSI='SIE*(B214)'
PLSBISST='STSI*(B27D)'
PLSBISTE='SCK*(B204)'
PLSBISXE='SPX*(B210)'
PLSBISXS='STPX*(B211)'
PLSCTCS ='REAL*CSCHS*EXECUTED'
PLSCTHS ='REAL*HSCHS*EXECUTED'
PLSCTRS ='REAL*RSCHS*EXECUTED.'
PLSCTSS ='REAL*SSCHS*EXECUTED.'
PLSESSA ='ESSA*(B9AB)'
PLSKEYIE='ISKE*(B229)'
PLSKEYIK='ISK*(09)'
PLSKEYRE='RRBE*(B22A)'
PLSKEYRR='RRB*(B213)'
PLSKEYSE='SSKE*(B22B)'
PLSKEYSK='SSK*(08)'
PLSLPSWE='LPSWE*(B2B2)'
PLSPCVSC='SERVC*(B220)'
PLSPRVGP='SIGP*(AE)'
PLSPRVLC='LCTL*(B7)'
PLSPRVLG='LCTLG*(EB2F)'
PLSPRVLP='LPSW*(82)'
PLSPRVMN='STNSM*(AC)'
PLSPRVMO='STOSM*(AD)'
PLSPRVMS='SSM*(80)'
PLSPRVSG='STCTG*(EB25)'
PLSPRVSV='SVC*(0A)'
PLSPRVTC='STCTL*(B6)'
PLSPRVTP='TPROT*(E501)'
PLSPRVVN='GUEST*SVC*76-S*REFLECTED'
PLSPTFF ='PTFF*(0104)'
PLSRSCHC='VIRTUAL*RSCHS*EXECUTED'
PLSSCKPF='SCKPF*(0107)'
PLSSIOCT='VIRTUAL*SIOS*EXECUTED'
PLSSIOFC='VIRTUAL*SIOFS*EXECUTED'
PLSSSCHC='VIRTUAL*SSCHS*EXECUTED'
PLSSTFLE='STFLE*(B2B0)'
PLSTCCC ='VIRTUAL*TEST AND CLEAR*CHANNELS'
PLSVIDTE='IDTE*(B98E)'
PLSVIESB='IESBE*(B259)'
PLSVPTNV='IPTE*(B221)'
PLSXPG5A='BSA*(B25A)'
PLSXPGIN='PGIN*(B22E)'
PLSXPGOU='PGOUT*(B22F)'
-Dataset VXPRCDIA (5.12) new variables added by 5.3:
PFXCPUAD='PROCESSOR*ADDRESS'
PLSDG200='DIAGNOSE*X200'
PLSDG204='DIAGNOSE*X204'
PLSDG208='DIAGNOSE*X208'
PLSDG20C='DIAGNOSE*X20C'
PLSDG210='DIAGNOSE*X210'
PLSDG214='DIAGNOSE*X214'
PLSDG218='DIAGNOSE*X218'
PLSDG21C='DIAGNOSE*X21C'
PLSDG220='DIAGNOSE*X220'
PLSDG224='DIAGNOSE*X224'
PLSDG228='DIAGNOSE*X228'
PLSDG22C='DIAGNOSE*X22C'
PLSDG230='DIAGNOSE*X230'
PLSDG234='DIAGNOSE*X234'
PLSDG238='DIAGNOSE*X238'
PLSDG23C='DIAGNOSE*X23C'
PLSDG240='DIAGNOSE*X240'
PLSDG244='DIAGNOSE*X244'
PLSDG248='DIAGNOSE*X248'
PLSDG24C='DIAGNOSE*X24C'
PLSDG250='DIAGNOSE*X250'
PLSDG254='DIAGNOSE*X254'
PLSDG258='DIAGNOSE*X258'
PLSDG25C='DIAGNOSE*X25C'
PLSDG260='DIAGNOSE*X260'
PLSDG264='DIAGNOSE*X264'
PLSDG268='DIAGNOSE*X268'
PLSDG26C='DIAGNOSE*X26C'
PLSDG270='DIAGNOSE*X270'
PLSDG274='DIAGNOSE*X274'
PLSDG278='DIAGNOSE*X278'
PLSDG27C='DIAGNOSE*X27C'
PLSDG280='DIAGNOSE*X280'
PLSDG284='DIAGNOSE*X284'
PLSDG288='DIAGNOSE*X288'
PLSDG28C='DIAGNOSE*X28C'
PLSDG290='DIAGNOSE*X290'
PLSDG294='DIAGNOSE*X294'
PLSDG298='DIAGNOSE*X298'
PLSDG29C='DIAGNOSE*X29C'
PLSDG2A0='DIAGNOSE*X2A0'
PLSDG2A4='DIAGNOSE*X2A4'
PLSDG2A8='DIAGNOSE*X2A8'
PLSDG2AC='DIAGNOSE*X2AC'
PLSDG2B0='DIAGNOSE*X2B0'
PLSDG2B4='DIAGNOSE*X2B4'
PLSDG2B8='DIAGNOSE*X2B8'
PLSDG2BC='DIAGNOSE*X2BC'
PLSDG2C0='DIAGNOSE*X2C0'
PLSDG2C4='DIAGNOSE*X2C4'
PLSDG2C8='DIAGNOSE*X2C8'
PLSDG2CC='DIAGNOSE*X2CC'
PLSDG2D0='DIAGNOSE*X2D0'
PLSDG2D4='DIAGNOSE*X2D4'
PLSDG2D8='DIAGNOSE*X2D8'
PLSDG2DC='DIAGNOSE*X2DC'
PLSDG2E0='DIAGNOSE*X2E0'
PLSDG2E4='DIAGNOSE*X2E4'
PLSDG2E8='DIAGNOSE*X2E8'
PLSDG2EC='DIAGNOSE*X2EC'
PLSDG2F0='DIAGNOSE*X2F0'
PLSDG2F4='DIAGNOSE*X2F4'
PLSDG2F8='DIAGNOSE*X2F8'
PLSDG2FC='DIAGNOSE*X2FC'
PLSDG300='DIAGNOSE*X300'
PLSDG304='DIAGNOSE*X304'
PLSDG308='DIAGNOSE*X308'
PLSDG30C='DIAGNOSE*X30C'
PLSDG310='DIAGNOSE*X310'
PLSDG314='DIAGNOSE*X314'
PLSDG318='DIAGNOSE*X318'
PLSDG31C='DIAGNOSE*X31C'
PLSDG320='DIAGNOSE*X320'
PLSDG324='DIAGNOSE*X324'
PLSDG328='DIAGNOSE*X328'
PLSDG32C='DIAGNOSE*X32C'
PLSDG330='DIAGNOSE*X330'
PLSDG334='DIAGNOSE*X334'
PLSDG338='DIAGNOSE*X338'
PLSDG33C='DIAGNOSE*X33C'
PLSDG340='DIAGNOSE*X340'
PLSDG344='DIAGNOSE*X344'
PLSDG348='DIAGNOSE*X348'
PLSDG34C='DIAGNOSE*X34C'
PLSDG350='DIAGNOSE*X350'
PLSDG354='DIAGNOSE*X354'
PLSDG358='DIAGNOSE*X358'
PLSDG35C='DIAGNOSE*X35C'
PLSDG360='DIAGNOSE*X360'
PLSDG364='DIAGNOSE*X364'
PLSDG368='DIAGNOSE*X368'
PLSDG36C='DIAGNOSE*X36C'
PLSDG370='DIAGNOSE*X370'
PLSDG374='DIAGNOSE*X374'
PLSDG378='DIAGNOSE*X378'
PLSDG37C='DIAGNOSE*X37C'
PLSDG380='DIAGNOSE*X380'
PLSDG384='DIAGNOSE*X384'
PLSDG388='DIAGNOSE*X388'
PLSDG38C='DIAGNOSE*X38C'
PLSDG390='DIAGNOSE*X390'
PLSDG394='DIAGNOSE*X394'
PLSDG398='DIAGNOSE*X398'
PLSDG39C='DIAGNOSE*X39C'
PLSDG3A0='DIAGNOSE*X3A0'
PLSDG3A4='DIAGNOSE*X3A4'
PLSDG3A8='DIAGNOSE*X3A8'
PLSDG3AC='DIAGNOSE*X3AC'
PLSDG3B0='DIAGNOSE*X3B0'
PLSDG3B4='DIAGNOSE*X3B4'
PLSDG3B8='DIAGNOSE*X3B8'
PLSDG3BC='DIAGNOSE*X3BC'
PLSDG3C0='DIAGNOSE*X3C0'
PLSDG3C4='DIAGNOSE*X3C4'
PLSDG3C8='DIAGNOSE*X3C8'
PLSDG3CC='DIAGNOSE*X3CC'
PLSDG3D0='DIAGNOSE*X3D0'
PLSDG3D4='DIAGNOSE*X3D4'
PLSDG3D8='DIAGNOSE*X3D8'
PLSDG3DC='DIAGNOSE*X3DC'
PLSDG3E0='DIAGNOSE*X3E0'
PLSDG3E4='DIAGNOSE*X3E4'
PLSDG3E8='DIAGNOSE*X3E8'
PLSDG3EC='DIAGNOSE*X3EC'
PLSDG3F0='DIAGNOSE*X3F0'
PLSDG3F4='DIAGNOSE*X3F4'
PLSDG3F8='DIAGNOSE*X3F8'
PLSDG3FC='DIAGNOSE*X3FC'
PLSDGUCT='ALL*USER*DIAGNOSE*OPERATIONS*/
PLSDGX00='DIAGNOSE*X00'
PLSDGX04='DIAGNOSE*X04'
PLSDGX08='DIAGNOSE*X08'
PLSDGX0C='DIAGNOSE*X0C'
PLSDGX10='DIAGNOSE*X10'
PLSDGX14='DIAGNOSE*X14'
PLSDGX18='DIAGNOSE*X18'
PLSDGX1C='DIAGNOSE*X1C'
PLSDGX20='DIAGNOSE*X20'
PLSDGX24='DIAGNOSE*X24'
PLSDGX28='DIAGNOSE*X28'
PLSDGX2C='DIAGNOSE*X2C'
PLSDGX30='DIAGNOSE*X30'
PLSDGX34='DIAGNOSE*X34'
PLSDGX38='DIAGNOSE*X38'
PLSDGX3C='DIAGNOSE*X3C'
PLSDGX40='DIAGNOSE*X40'
PLSDGX44='DIAGNOSE*X44'
PLSDGX48='DIAGNOSE*X48'
PLSDGX4C='DIAGNOSE*X4C'
PLSDGX50='DIAGNOSE*X50'
PLSDGX54='DIAGNOSE*X54'
PLSDGX58='DIAGNOSE*X58'
PLSDGX5C='DIAGNOSE*X5C'
PLSDGX60='DIAGNOSE*X60'
PLSDGX64='DIAGNOSE*X64'
PLSDGX68='DIAGNOSE*X68'
PLSDGX6C='DIAGNOSE*X6C'
PLSDGX70='DIAGNOSE*X70'
PLSDGX74='DIAGNOSE*X74'
PLSDGX78='DIAGNOSE*X78'
PLSDGX7C='DIAGNOSE*X7C'
PLSDGX80='DIAGNOSE*X80'
PLSDGX84='DIAGNOSE*X84'
PLSDGX88='DIAGNOSE*X88'
PLSDGX8C='DIAGNOSE*X8C'
PLSDGX90='DIAGNOSE*X90'
PLSDGX94='DIAGNOSE*X94'
PLSDGX98='DIAGNOSE*X98'
PLSDGX9C='DIAGNOSE*X9C'
PLSDGXA0='DIAGNOSE*XA0'
PLSDGXA4='DIAGNOSE*XA4'
PLSDGXA8='DIAGNOSE*XA8'
PLSDGXAC='DIAGNOSE*XAC'
PLSDGXB0='DIAGNOSE*XB0'
PLSDGXB4='DIAGNOSE*XB4'
PLSDGXB8='DIAGNOSE*XB8'
PLSDGXBC='DIAGNOSE*XBC'
PLSDGXC0='DIAGNOSE*XC0'
PLSDGXC4='DIAGNOSE*XC4'
PLSDGXC8='DIAGNOSE*XC8'
PLSDGXCC='DIAGNOSE*XCC'
PLSDGXD0='DIAGNOSE*XD0'
PLSDGXD4='DIAGNOSE*XD4'
PLSDGXD8='DIAGNOSE*XD8'
PLSDGXDC='DIAGNOSE*XDC'
PLSDGXE0='DIAGNOSE*XE0'
PLSDGXE4='DIAGNOSE*XE4'
PLSDGXE8='DIAGNOSE*XE8'
PLSDGXEC='DIAGNOSE*XEC'
PLSDGXF0='DIAGNOSE*XF0'
PLSDGXF4='DIAGNOSE*XF4'
PLSDGXF8='DIAGNOSE*XF8'
PLSDGXFC='DIAGNOSE*XFC'
PLSTOTDI='ALL Z/VM*DEFINED*DIAGNOSE*OPERATIONS*/
-Dataset VXIODDEV (6.03) new variables added by 5.3:
PAVCC3S ='INITIAL*CMR*TIME'
-Dataset VXVNDSES (8.01) new variables added by 5.3:
MSVCMAC ='VDEV*MAC*ADDRESS'
-Dataset VXAPLTC1 (10.01) TCP/IP SUBTYPE '01' added:
FORNIPV6='FOREIGN*IP*ADDRESS*IPV6'
LOCLIPV6='LOCAL*IP*ADDRESS*IPV6'
-Dataset VXAPLTC4 (10.02) TCP/IP SUBTYPE '04' added:
FPSPAV2G='FPSP*AVAILABLE*LOCKED PAGES*GT 2G'
FPSPALUS='FPSP*ALLOCATED*LOCKED PAGES*GT 2G'
-Dataset VXAPLTC9 (10.02) TCP/IP SUBTYPE '09' added:
ACBSSC00='PROCESS 00*ACBS SCHEDULED'
ELAPSE00='PROCESS 00*ELAPSED TIME ACB'
VIRTCP00='PROCESS 00*VIRTUAL CPU TIME ACB'
ELAPSM00='PROCESS 00*MAXIMUM ELAPSED TIME ACB'
VIMXCP00='PROCESS 00*MAXIMUM VIRTUAL CPU TIME ACB'
thru
ACBSSC80='PROCESS 80*ACBS SCHEDULED'
ELAPSE80='PROCESS 80*ELAPSED TIME ACB'
VIRTCP80='PROCESS 80*VIRTUAL CPU TIME ACB'
ELAPSM80='PROCESS 80*MAXIMUM ELAPSED TIME ACB'
VIMXCP80='PROCESS 80*MAXIMUM VIRTUAL CPU TIME ACB'
for all 81 "Process Name Types".
UPDATES PENDED FOR ADDITIONAL IBM DOC/ASSISTANCE:
-Dataset VXPRCAPM (5.10) is skipped as the documentation
is insufficient. The PRCAPM segment does not contain
the CMB Entry Type, which sets the size of the CMB:
Entry type 3, 5, 6 are 64 bytes
Entry type 4 is 336 bytes
Entry type 6 is 80 bytes
plus
- the length of the variable data depends on the type
of AP (determined by the PRCAPM_CT field in the
CMB Header, and the number of APs installed,
But: neither that PRCAPM_CT fields, nor is the number
of APs in the PRCAPM segment in MONWRITE data.
Fortunately, the PRCAPM 5.10 segment only exists if
there are PCI Crypto Cards installed.
-Dataset VXAPLTC9 (10.02) SUBRECORD '09'X, TCP/IP ACB is
still not understood sufficiently for complete support.
All of the datasets listed above have been tested with
data from z/VM 5.4. There are a few other records that
have new data fields, but they did not exist in the test
files, so they won't be updated until a user request is
accompanied by test data with those segments.
Change 26.202 Creating RMFINTRV or BUILDPDB with //PDB DD on tape fails
VMXGRMFI because both PDB.TYPE78 and PDB.TYPE78IO were opened in a
Aug 30, 2008 VMXGSUM invocation, but PDB.TYPE78 has always had zero
Oct 15, 2008 observations (with 3090's or later), so it was removed
from that step. PDB.TYPE78 is still VMXGSUM'd separately
to create these PDB.RMFINTRV variables, always missing
values, but there so your old report programs won't fail:
NRATTMPS NRSAMPLE SIO78CNT PCTDEFCU PCTDEFDV
PCTSUCES PCTALLBY
Oct 15: Using PDB=SMF with %VMXGRMFI failed because the
_STY78 had been inadvertently removed.
Thanks to Jorge Fong, DOITT NYC, USA.
Thanks to Atle Mjelde, Ergo Group, NORWAY.
Change 26.201 Support for DB2 V9.1 (COMPAT) SMF 100/101 + new V8 data:
FORMATS
VMACDB2 WOW: New Z/OS metrics in PDB.DB2STATS are added to both
Aug 30, 2008 DB2 V8.1 (APAR PK47659) and DB2 V9.1 (APAR PK56356).
Sep 1, 2008 Both DB2 APARs also need RMF APAR PK62116 (which has
prereq APARs PK66373 and OA24404), and PK62116 has
these installation notes from IBM:
Please be aware that there can be situations when
the z/OS metrics don't get provided at all or only
partially in the DB2 trace. The reason for this
is that there are setup problems related to RMF.
Please verify that actions 1 to 4 were completed
after installation of the PTF for PK62116:
1. Make sure that the PTF for the prereq APAR
PK66373 has been applied.
2. Verify that the fix for Resource Measurement
Facility (RMF), PTF for APAR OA24404 has been
installed. If this step is omitted, an abend
will occur in RMF.
3. Set DB2 subsystem parameter ZOSMETRICS to YES.
4. Start Resource Measurement Facility and RMF
Monitor 3 sysplex data retrieval service.
-Dataset DB2STATS new variables from DB2STAT0 in V8 & V9:
New z/OS variables in PDB.DB2STATS with above APARs:
QWOSDB2U='DB2*SUBSYSTEM*CPU*UTILIZATION'
QWOSDBMU='DB2*DBM1*CPU*UTILIZATION'
QWOSDPIR='DB2 SUBSYS*PAGE-IN*RATE'
QWOSDRSU='DB2 SUBSYS*USED REAL STORAGE*IN MB'
QWOSDVSU='DB2 SUBSYS*USED VIRTUAL*STORAGE*IN MB'
QWOSLNCP='CPS*IN*LPAR'
QWOSLPIR='LPAR*PAGE-IN*RATE'
QWOSLPRU='LPAR*CPU*UTILIZATION'
QWOSLRSF='LPAR*FREE REAL*STORAGE*IN MB'
QWOSLRST='LPAR*REAL STORAGE*IN MB'
QWOSLVSF='LPAR*FREE*VIRTUAL*STORAGE*IN MB'
QWOSLVST='LPAR*VIRTUAL*STORAGE*IN MB'
QWOSMSTU='DB2*MSTR*CPU*UTILIZATION'
NOTE: DB2 Parameter ZOSMETRICS=YES must be specified to
populate these variables. APAR PK62116 applies.
With the default NO value, fields contain 'FFFFFFFF'x.
-Dataset DB2ACCT new variables added by V9:
QWACALBW='WAIT TIME*TCP/IP LOB*MATERIALIZATION'
QWACALBC='WAITS FOR*TCP/IP LOB*MATERIALIZATIONS'
QWACSPC1='SP_CLS1SE*STORED PROC*CLASS 1*ON ZIIP'
QWACSPC2='SP_CLS2SE*STORED PROC*CLASS 2*ON ZIIP'
QWACSPZC='SPNF_CP*STORED PROC*CPU TIME*ON CP'
QWACSPZE='SPNF_ELAP*STORED PROC*ELAPSED*TIME'
QWACSPZI='SPNF_ZIIP*STORED PROC*CPU TIME*ON ZIIP'
QWACTRSE='TRTE_SE*NESTED*TRIGGER*CPU ON ZIIP'
QWACUDC1='UDF_CLS1SE*UDF STORED PROC*CLS 1*ZIIP'
QWACUDC2='UDF_CLS2SE*UDF STORED PROC*CLS 2*ZIIP'
QWACUDZC='UDFNF_CP*FUTURE*FUNCTION'
QWACUDZE='UDFNF_ELAP*FUTURE*FUNCTION'
QWACUDZI='UDFNF_ZIIP*FUTURE*FUNCTION'
-Dataset DB2ACCTP new variables added by V9:
QPACALBC='TCP/IP LOB*WAIT*TRACE*EVENTS'
QPACALBW='CPU TIME*ON ZIIP'
QPACSWIT='TIMES*PACKAGE WAS*SWITCHED TO'
-Datasets DB2ACCT, DB2ACCTP, DB2ACCTB, DB2ACCTG
new QWHC (Header) variables added:
QWHCOAUD='ORIGINAL*APPLICATION*USERID'
QWHCROLE='ROLE*NAME'
QWHCTCXT='TRUSTED*CONTEXT*NAME'
-Dataset DB2STATS new variables from DB2STAT0 in V9:
Q9STCTX5='DISPLAY*DDF*COMMANDS'
Q9STCTAD='ACCESS*DATABASE*COMMANDS'
Q9STCTSS='START*PROFILE*COMMANDS'
Q9STCTST='STOP*PROFILE*COMMANDS'
Q9STCTSD='DISPLAY*PROFILE*COMMANDS'
-Dataset DB2STATB and DB2STATS changes:
These DB2STATB variables are (or have been) reserved
QBSTALX QBSTARA QBSTARF QBSTAWA QBSTAWF QBSTDWC
QBSTDWX QBSTHBE QBSTHPA QBSTHPL QBSTHRA QBSTHRE
QBSTHRF QBSTHWA QBSTHWF QBSTHWR QBSTWEE
and all are now set to a missing value in DB2STATB.
Additionally, their QB1xxxx-QB4xxxx counterpart
variables in DB2STATS are now also missing values.
New variables in DB2STATB:
QBSTCIO ='PAGES*OF I/O*ON CASTOUT'
QBSTPCO ='PAGES*ON*UNLOCK*CASTOUT'
New variables in DB2STATS:
QB1TCIO ='1ST PAGES*OF I/O*ON CASTOUT'
QB1TPCO ='1ST PAGES*ON*UNLOCK*CASTOUT'
QB2TCIO ='2nd PAGES*OF I/O*ON CASTOUT'
QB2TPCO ='2nd PAGES*ON*UNLOCK*CASTOUT'
QB3TCIO ='3rd PAGES*OF I/O*ON CASTOUT'
QB3TPCO ='3rd PAGES*ON*UNLOCK*CASTOUT'
QB4TCIO ='4th PAGES*OF I/O*ON CASTOUT'
QB4TPCO ='4th PAGES*ON*UNLOCK*CASTOUT'
-Dataset DB2STATB new variable in V9:
QDBPASIZ='AUTOSIZE*ATTRIBUTE'
-Dataset DB2STATS new variables from DB2STAT1:
QISECTA ='PAGES*USED IN CT*ABOVE BAR'
QISEKFAL='FAIL*DUE TO*STMT SKEL*POOL FULL'
QISEKFRE='FREE PG*IN SKEL*EDM POOL*FRE CH'
QISEKNFA='NOT-FOUND*RECORD*ADDED*TO CACHE'
QISEKNFM='CACHED*NOT-FOUND*RECORD*LOCATED'
QISEKNFR='NOT-FOUND*RCRD*REMOVED*FRM CACHE'
QISEKPGE='PAGES*IN SKEL*EDM POOL'
QISEKTA ='PAGES*USED IN PT*ABOVE BAR'
QISESFAL='FAIL*DUE TO*STMT ABV*POOL FULL'
QISESFRE='FREE PG*IN STMT*ABV EDM*POL FRE'
QISESKCT='PAGES*USED*FOR SKCT'
QISESKPT='PAGES*USED*FOR SKPT'
QISESPGE='PAGES*IN STMT*ABV EDM*POOL'
-Dataset DB2STATS new variables from DB2STAT1:
QISTW04K='TOT 4KB*TABLESPACE*USED*FRACT MB'
QISTW32K='TOT 32KB*TABLESPACE*USED*FRACT MB'
QISTWF04='TOT 4KB*TABLESPACE*USED*WHOLE MB'
QISTWF32='TOT 32KB*TABLESPACE*USED*WHOLE MB'
QISTWFCK='CUR TOTAL*FRACT MB*USED IN*WF IN KB'
QISTWFCU='CUR TOTAL*WHOLE MB*USED IN*WF DB'
QISTWFMU='MAX TOT*USED IN*WF DB (MB)'
QISTWFMX='MAX*ALLOWABLE*USE LIMIT*P/AG MB'
QISTWFNE='TIMES MAX*ALLOWABLE*LIMIT*EXCEEDED'
QISTWFP1='TIMES 32KB*PAGE TS*USED WHEN*4KB SHOULD'
QISTWFP2='TIMES 4KB*PAGE TS*USED WHEN*32K SHOULD'
-Dataset DB2STATS new variables from DB2STAT1:
QXALTCTX='ALTER*TRUSTED*CONTEXT'
QXALTJR ='ALTER*JAR'
QXCRCTX ='CREATE*TRUSTED*CONTEXT'
QXCRROL ='CREATE*ROLE'
QXDRPCTX='DROP*TRUSTED*CONTEXT'
QXDRPROL='DROP*ROLE'
QXMERGE ='TIMES*MERGE*STATEMENT*WAS EXECUTED'
QXRNIX ='RENAME*INDEX'
QXSTXMLV='MAX STORAGE*USED FOR*XML VALUES'
QXTRTBL ='TIMES*TRUNCATE*TABLE*WAS EXECUTED'
-Dataset DB2ACCTP documentation.
Variables QPACCAST, QPACCANM, QPACUDST are always
missing in both V8 and V9, as they are Account level,
not package, metrics.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.200 NO CHANGE. Only documentation of the cause of message:
BUILDPDB ERROR:Variable SYSPLEX defined as both char and numeric.
Aug 28, 2008 ERROR:Variable SYSTEM defined as both char and numeric.
ERROR:Variable SYSNAME defined as both char and numeric.
followed by
WARNING: The data set WORK.MSU4HRAV may be incomplete.
The error is a broken SPIN.SPINRMFI, from an earlier test
job that failed; PROC CONTENTS DATA=SPIN.SPINRMFI will
show the three variables as NUMERIC instead of CHARACTER.
PROC DELETE DATA=SPIN.SPINRMFI and a rerun resolved.
Change 26.199 Change 25.228 added protection for invalid 14, 15 records
VMAC1415 that had only one NUCB while NUCB=2 in the record, but
Aug 28, 2008 the protection failed when the NUCB segment was the last
in the record. The protection itself CAUSED message:
ERROR: INVALID SMF1415 RECORD. INVALID UCB SEGMENT ERROR
which prevented those records from being output, so it
really is an ERROR, albeit caused by MXG and not a bad
record. Most 14/15s have the extended segments, and the
protection worked fine for those records.
Thanks to Herbert Sweeney, Verizon Data Services, USA
Change 26.198 All Pool 00 variables in BVIR32 are changed to Pool 32,
VMACBVIR as all IBM Virtualization Engine TS7700 reporting now
Aug 25, 2008 reports pools 1 thru 32 instead of the pool 0 thru 31 in
the DSECTS from which I wrote the original MXG code.
Variable names and labels are changed.
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
====== Changes thru 26.197 were in MXG 26.07 dated Aug 24, 2008=========
Change 26.197 PCTMVSBY in PDB.TYPE70PR is now calculated for all engine
VMAC7072 types (CPs,zIIPs,zAAPs), because SMF70PAT parked time is
Aug 24, 2008 now recorded for the specialty engines. The existence of
SMF70PAT field required heuristic circumvention code when
it was discovered that a fully parked engine did not have
the SMF70PAT exactly equal to the SMF70ONT Online Time;
my first test for ONT-PAT GT .02 seconds was not enough
and caused PCTMVSBY greater than 100% when data with ONT
of ONT 15.00.01 and PAT of 14:59:97 was found, so that
heuristic was raised to 0.10 seconds. CPUWAITM greater
than DURATM by 0.01 seconds with SMF70PAT nearly DURATM
also required heuristic protection to prevent negative
PCTCPU calculations for individual engines in TYPE70PR.
Change 26.196 Variable DVRCP032 was removed from the KEEP list; there
VMACBVIR are only 31 pools. But now see Change 25.198.
Aug 24, 2008
Thanks to Jens Mohring, HUK-COBURG, GERMANY.
Change 26.195 The Multi-System Enclave Remote System dataset TYPE30MR
VMAC30 always had zero observations, because MXG's test for the
Aug 22, 2008 13 bytes remaining should have been 12, so the offset was
always missing and the segment was never read. This also
caused variables CPUMRDTM/CPUMRITM in TYPE30xx, PDB.JOBS,
PDB.STEPS, and PDB.SMFINTRV to always be zero. However,
fortunately, even IBM doesn't expect many (or any?) sites
to actually have these segments, so no one had noticed
their absence.
Thanks to Stephen Hughes, Excellus, USA.
Change 26.194 The MXGWPSV2 JCL procedure example was inconsistent in
MXGWPSV2 the example DSNAMEs, and the JCLINSTW example notes were
JCLINSTW clarified on the JCL Procedure Name to be used.
Aug 24, 2008
Change 26.193 Lots of cosmetic cleanup. Labels added, variables that
DOC should not have been kept aren't, formats added, etc.,
Aug 21, 2008 as a result of SAS ITRM Dictionary Build, MXG QA runs,
and user detected inconsistencies. Members touched:
IMACCICS IMAC110 VMAC110 VMAC6156 VMACTPMX VMAC116
VMACSMF VMACHSM VMACCMF VMXGCICI VMAC30 VMXGRMFI
JCLROCS ASUMTAPE CHANGESS VMACSUSE VMXGINIT IMACQAPM
VMAC7072 VMACNTSM VMACTPF
Thanks to Nick Johns, Sainsbury Supermarkets Ltd., ENGLAND.
Thanks to Chris Weston, SAS ITRM Development, USA.
Thanks to Freddie Arie, Merrill Consultants QA Guy, USA.
Change 26.192 Support for APAR OA24074. IBM recalculates PCTMVSBY when
VMAC7072 HIPERDISPATCH has parked an engine(s), by subtracting the
Aug 21, 2008 Parked Time (SMF70PAT) from both the numerator and the
denominator:
Online Time - (Wait + Parked Time)
MVS UTIL(%)=---------------------------------- * 100
Online Time - Parked Time
so MXG's calculation of PCTMVSBY is revised to match IBM.
This was noted in the MXG Newsletter discussion of Parked
time, but was not implemented in code until now.
Thanks to Brian Currah, Independent Consultant, CANADA.
(In 1972, the first person I ever called with a question about an
SMF record's contents was Brian; the late Steve Cullen knew him
to be an SMF guru at GUIDE! And, he knew the answer, then and now!)
Change 26.191 A new MXGSAS92 JCL Procedure for MXG under z/OS SAS V9.2
MXGSAS92 is provided because SAS changed their DSNAMES for CNTL
Aug 22, 2008 and SASMSG datasets:
-If you use the SAS Deployment Wizard (SDW) to install the
SAS V9.2 for z/OS release, the DSNAME of their CNTL
dataset is changed by the addition of a new qualifier
with the SAS Version, year, and julian date of install,
with this syntax
DSN=&SASHLQ..V92DYJJJ.CNTL(BAT&YY.)
or a specific DSNAME, for example, of
DSN=&SASHLQ..V92D8208.CNTL(BATW0)
for an install in 2008 on julian date 208, in the USA.
The MXGSAS92 JCL procedure now has
//CONFIG DD DISP=SHR,DSN=&SASHLQ..V92DYJJJ.CNTL(BAT&YY.)
// DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9)
Get that exact YJJJ value from your SAS Installer.
-Also the SASMSG DSNAME with .SL. no longer exists, so the
SASMSG DD only has these two DDs:
//SASMSG DD DISP=SHR,DSN=&SASHLQ..&XX.&YY..SASMSG
// DD DISP=SHR,DSN=&SASHLQ..EN&YY..SASMSG
Thanks to Tom C. Frohnapfel, AAFES, USA.
Thanks to MP Welch, SPRINT, USA.
Change 26.190 -Support for IMS Log record 0A (CPI-CI Driven Program)
ASMIMSL6 records 0A07x (Terminate) & 0A08x (Start) creates IMS0A78
EXIMS0A7 dataset in both ASMIMSL6/TYPEIMSA and TYPEIMS7 programs.
EXIMS0A8 -For ASMIMSL6/TYPEIMSA log processing:
EXIMSA78 _IMSVERS defined in IMACIMSA now default is IMS 10.0.
IMACIMS Comments in IMACIMSA document how to change DDNAMES and
IMACIMS7 which %LET Wdddddd= or %LET Pdddddd you use for
IMACIMSA each of the six output IMS datasets.
TYPEIMS7 ASMIMSL6 was modified to pass the 0A records and report
TYPEIMSA the total count of those records written.
VMACIMS -For TYPEIMS7 processing:
Aug 23, 2008 _IMSVERS defined in IMACIMS7 now default is IMS 10.0.
Member IMACIMS is NO LONGER USED.
In _IMSUMRY macro CTR array was increased from 55 to 67.
These DDname Macros were previously defined in IMACIMS7:
_IMSTRAN, _IMSBMP, and _IMSWORK
but they are no longer used in IMS processing, as the
simpler Pdddddd and Wdddddd macro variables are now
fully implemented in the MXG IMS processing. They are
still defined, in case they exist in your user code.
All TYPEIMS7 output datasets are written to //WORK, but
comments in TYPEIMS7 show how to send its output to
other DDNAMES.
Thanks to Cornelia Dorr, Lufthansa Systems Infratec GmbH, GERMANY.
Thanks to Gero Wohlsperger, Lufthansa Systems, Infratec GmbH, GERMANY
Change 26.189 SAS V9.2 with Hot Fix F9BA07 removed the need for MXG to
VMXGINIT enable the (non-existent, as of now) VARLENCHK option, so
Aug 20, 2008 it was removed. See MXG Newsletter FIFTY-TWO, SAS Note 7
which discusses the Hot Fix for SAS V9.2.
Thanks to MP Welch, SPRINT, USA.
Change 26.188 The datasets ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP built by
DOC the ASUM70PR member currently do NOT subtract SMF70PAT,
Aug 19, 2008 Parked Time, from the SMF70ONT, Online Time, so the count
of LPnNRPRC (CP Engines) is not the average online count.
It might not be possible, easily, to modify ASUM70PR to
account for Parked Time in the two System-Level datasets
ASUM70PR and ASUM70LP, because the SMF70PAT only exists
in the per-MVS-system observations in TYPE70PR from the
parked MVS system records.
However, the two CEC-Level datasets, ASUMCEC and ASUMCELP
already use only the per-MVS-system observations, so it
appears that you could use the below example to create
two new PARKCEC and PARKCELP datasets in your PDB library
with the SMF70PAT parked time removed from SMF70ONT time,
which then causes the calculation of LPnNRPRC and related
related variables to account for the parked time of each
LPAR:
//REALPDB DD DSN=YOUR.REAL.PDB.DATASET,DISP=SHR
//PDB DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//SYSIN DD *
DATA PDB.TYPE70PR; SET REALPDB.TYPE70PR;
IF SMF70PAT GT 0 THEN SMF70ONT=SMF70ONT-SMF70PAT;
%INCLUDE SOURCLIB(ASUM70PR);
DATA REALPDB.PARKCEC; SET PDB.ASUMCEC;
DATA REALPDB.PARKCELP; SET PDB.ASUMCELP;
Change 26.187 Support for APAR OA25205 for SMF 42 record, adds subtypes
EXTY4224 24 and 25, and to subtypes 20, 21, 24 and 25, the fields
EXTY4225 defined by IBM's ICHRUTKN DSECT are added to the record.
EXTY422A These new datasets are created:
EXTY424A DDDDDD DATASET DESCRIPTION
FORMATS TY422A TYPE422A SUBTYPE 21 DELETE MEMBER ALIAS
IMAC42 TY4224 TYPE4224 DFSMS MEMBER ADD/REPLACE ST24
VMAC42 TY42A4 TYPE42A4 DFSMS SUBTYPE 24 DELETE ALIAS
VGETUTKN TY4225 TYPE4225 DFSMS MEMBER RENAME ST25
VMXGINIT These MXG variables are created by VGETUTKN:
Aug 19, 2008 UTKNFLG1='UTKNFLG1*MISCELLANEOUS FLAGS'
Bit values, not (yet?) decoded by MXG:
TOKENCR X'80' TOKEN IS ENCRYPTED
TOKLT19 X'20' TOKEN CREATED BY PRE RACF 1.9 CALL
TOKVXPRP X'10' VERIFYX PROPAGATION OCCURRED
TOKUNUSR X'08' NJE UNKNOWN USER
TOKLOGU X'04' LOG USER INDICATOR
TOKRSPEC X'02' RACF SPECIAL INDICATOR
UTKNFLG2='UTKNFLG2*MISCELLANEOUS*FLAGS'
Bit values, not (yet?) decoded by MXG:
TOKDFLT X'80' DEFAULT TOKEN
TOKUDUS X'40' UNDEFINED USER
TOKERR X'10' TOKEN IN ERROR
TOKTRST X'08' PART OF TRUSTED COMPUTER BASE
TOKSUS X'04' SURROGATE USERID
TOKREMOT X'02' REMOTE JOB INDICATOR
TOKPRIV X'01' PRIVILEDGED USER INDICATOR
UTKNFLG3='UTKNFLG3*MISCELLANEOUS*FLAGS'
TOKDGRP X'80' DEFAULT GROUP ASSIGNED
TOKDSEC X'40' DEFAULT SECLABEL ASSIGNED
TOKNETF X'20' NETWORK NAME SPECIFIED
TOKIPV X'10' IP VALUE FOR SERVAUTH POE
TOKWDWN X'08' WRITE-DOWN IS ALLOWED
UTKNGRUP='SESSION*OWNER*GROUPID'
UTKNLEN ='UTOKEN*RTOKEN*LENGTH'
UTKNNETW='REMOTE*NETWORK*NAME'
UTKNPOE ='PORT*OF*ENTRY'
UTKNPOEX='PORT OF ENTRY*CLASS*INDEX'
Decimal values not (yet?) decoded by MXG:
TOKTERM EQU 1 TERMINAL CLASS
TOKCON EQU 2 CONSOLE CLASS
TOKJESI EQU 3 JESINPUT CLASS
TOKAPORT EQU 4 APPCPORT CLASS
TOKSERV EQU 5 SERVAUTH CLASS
UTKNSCL ='SECLABL'
UTKNSGRP='SUBMITTING*GROUPID'
UTKNSNOD='SUBMITTER*NODE'
UTKNSTYP='SESSION*TYPE'
Decimal values decoded by MGUTKNT format:
1=' 1:SYSTEM ADDRESS SPACE'
2=' 2:COMMAND'
3=' 3:CONSOLE OPERATOR'
4=' 4:STARTED PROCEDURE'
5=' 5:MOUNT'
6=' 6:TSO LOGON'
7=' 7:INTERNAL READER BATCH JOB'
8=' 8:EXECUTION BATCH MONITOR'
9=' 9:RJE OPERATOR'
10='10:NJE OPERATOR'
11='11:VERIFYX UNKNOWN USER TOKEN'
12='12:EXTERNAL READER BATCH JOB'
13='13:RJE BATCH JOB'
14='14:NJE BATCH JOB'
15='15:NJE SYSOUT'
16='16:EXTERNAL XBM'
17='17:RJE XBM'
18='18:NJE XBM'
19='19:APPCTP'
20='20:OMVSSRV'
21='21:IPLOOKUP VALUE'
UTKNSUSR='SUBMITTING*USERID'
UTKNUSER='SESSION*OWNER*USERID'
UTKNVERS='UTOKEN*RTOKEN*VERSION*NUMBER'
UTKNXNOD='EXECUTION*NODE'
APAR OA25068 is the Parent APAR for APAR OA25205, and
this change supports both APAR numbers.
Change 26.186 WPS did not tolerate a FORMAT statement between an END
VMACVMXA and an ELSE IF statement. The FORMAT statement should
Aug 18, 2008 normally have been prior to that END statement in MXG, so
it was relocated to eliminate the WPS-only error.
Change 26.185 Mostly zero observations in TMDBDB2 dataset, because no
EXTMDDB2 one had use the TYPETMDB code to read the native Landmark
IMACTMDB for DB2 records with TYPETMDB code since 2004. Change
VMACTMDB 22.121 corrected MXG handling of DB2 Rollup records for
Aug 16, 2008 IBM DB2 SMF records, but that change had not been applied
to the Landmark DB2 records. This change removed the DO
group in EXTMDDB2 that deleted most observations, added
the logic that creates DB2PARTY='R' for rollups, and also
removed the _TMDBVER macro that is no longer required, as
only Version 4+ records now exist.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 26.184 Circumvention for defective SMF 101 subtype 0 record from
VMACDB2 Landmark reconstructed SMF records. Their error is in
Aug 13, 2008 the QPAC segment, which caused INPUT STATEMENT EXCEEDED
error because the offsets to the "truncated" name fields
are less than the QPACLEN value, and the offset should
not have been populated, since the name fields are not
"truncated". In addition, these fields prior to those
offsets are trashed, as the record contains character
text where these numbers are input (but since any text
is a valid PIB value, there was no error, only bad data
values in the DB2ACCP dataset):
QPACAWTK QPACAWTM QPACAWTN QPACAWTO QPACAWTQ
QPACARNK QPACARNM QPACARNN QPACARNO QPACARNQ
The MXG circumvention detects the record is created by
Landmark rather than IBM (by the location of the Product
segment, which Landmark puts at the beginning of the
SMF record, while IBM puts it at the end), and the
data starting at QPACAWTK is not input, so the variables
listed above will be missing, rather than wrong, until
a correction is available from Landmark.
Thanks to Howard Curtis, Progress Energy, USA.
Change 26.183 This change was rescinded by Change 27.039 as wrong.
Aug 13, 2008 The QBAC and QTXA variables have always existed in the
Mar 16, 2009 DB2ACCTP dataset in DB2 V8.1 or later. Change 27.039
restored those variables to the ASUMDB2P and TRNDDB2P
programs. Mar 16, 2009.
Below is the original (AND INCORRECT) change text:
Summary and trending of DB2ACCTP Package Dataset revised.
ASUMDB2P The QBACxxxx and QTXAxxxx variables are always missing in
TRNDDB2P DB2ACCTP (ever since DB2 V7.1, which moved Package Data
Aug 12, 2008 to IFCID 239 (SMF 101 Subtype 1) records, so they have
been removed from both ASUMDB2P and TRNDDB2P summaries.
They can be removed from your DB2ACCTP dataset, but I
can not remove them without risk of causing a failure
if any of your reports reference them in DB2ACCTP.
You can copy this macro definition into your IMACKEEP
member and they will no longer exist in your DB2ACCTP.
MACRO _KDB2ACP
QBACGET QBACSWS QBACRIO QBACSEQ QBACIMW QBACLPF
QBACDPF QBACNGT QBACSIO
QTXACHG QTXACHUS QTXACLMT QTXACLNO QTXACLUN QTXADEA
QTXADRNO QTXADRUN QTXAFLG1 QTXAILMT QTXAIRLM QTXALES
QTXALEX QTXALOCK QTXANPL QTXANRUN QTXAPREC QTXAQRY
QTXARLID QTXASLAT QTXASLMT QTXASLOC QTXASOTH QTXATIM
QTXAUNLK
%
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.182 Support for MACRO4 INSYNC SMF user record creates new
EXINSYDB datasets:
EXINSYDI DATASET DDDDDD DESCRIPTION
EXINSYDS
EXINSYDU INSYDB2 INSYNC DB2
EXINSYZO INSYDBDI INSYNC DB2 - D OR I
EXINSYZC INSYDBDS INSYNC DB2 - SQL TEXT
EXINSYZF INSYDBDU INSYNC DB2 - U
FORMATS INSYZOS INSYNC ZOS
IMACINSY INSYZOSC INSYNC ZOS FORMAT
TYPEINSY INSYZOSF INSYNC ZOS SELECTION CRITERIA
TYPSINSY This is the first iteration and further investigation is
VMACINSY needed with the vendor, as there are invalid SMF records
VMXGINIT (the number of segments exceeds the physical record size)
Aug 13, 2008 and there are unexpected numerous duplicate records that
need to be investigated).
Thanks to Josep Miquel Oliver, La Caixa, SPAIN.
Change 26.181 Accidentally skipped change number
Thanks to Brent Turner, CitiGroup, USA.
Change 26.180 -The circumvention for invalid UWD record to avoid a USER
ASMRMFV ABEND, by skipping over it, is now permanent.
Aug 8, 2008 -Warning RMFV106W was incorrectly issued, and CPD table
entries could be not-processed, but only if GEI records
were selected. The SSH register pointer was not reloaded
but now are.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 26.179 The typo in VMAC7072 that had a nine-character variable
VMAC7072 ELSE IFAHONRPR=' ';
Aug 8, 2008 is corrected to
ELSE IFAHONPR=' ';
This does not cause an error with MXG's CONFIGV9, which
sets SAS option VALIDVARNAME=V7 to permit long names, but
if the SAS option VALIDVARNAME=V6 is used, error message
VARIABLE NAMED IFAHONRPR CONTAINS MORE THAN 8 CHARACTERS
is printed. The typo was introduced in MXG 26.03.
Thanks to Brian Cummings, Federal Reserve Information Technology USA
Change 26.178 z/OS 1.9 changed length of RMF III ASI segment, adding
VMACRMFV eight bytes, which caused ASICNM (Service Class Name)
Aug 8, 2008 and subsequent ASI variables to be wrong. The added
eight bytes are now decoded and kept in ZRBSI as
ASILMEMO='MEMORY*OBJECTS*ALLOCATED'
ASILPGSZ='LARGE PAGE*BYTES BACKED*IN REAL*STORE'
While ASILPGSZ is in pages in the raw record, MXG has
converted it to bytes and formatted it with MGBYTES to
display that size in KB/MB/etc.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 26.177 Cleanup of MXG as a result of ITRM Dictionary build:
ASUMTAPE -ASUMTAPE: Dataset HELDMOUN was not deleted from //WORK.
VMXGRMFI -RMFINTRV: New RMFWKLRV dataset had these variables
VMAC85 WKLDCPU WKLDHPT WKLDIFA WKLDIFE WKLDIIP WKLDRCT
VMAC99 WKLDSRB WKLDTCB WKLDZIE WKLDZIP.
Aug 7, 2008 that are now FORMATed TIME12.2;
-TYPE85RE: Variables R85BT R85MT R85RCDY R85TKN R85VT
were unlabeled.
R85BT ='BACKUP*TYPE'
R85MT ='VOLUME*MEDIA*TYPE*OF FROM'
R85RCDY ='DAYS*SPECIFIED*FOR OBJECT*RECALL'
R85TKN ='VOLUME*LOCATION*TOKEN OF*FROM'
R85VT ='VOLUME*TYPE'
-TYPE99: Variable S99BPDTM is FORMATted TIME12.3.
Thanks to Chris Weston, SAS ITRM Development, USA.
====== Changes thru 26.176 were in MXG 26.06 dated Aug 8, 2008=========
Change 26.176 First MXG 26.06 of Aug 6 worked fine on PCSAS but FORMATS
FORMATS failed on z/OS with one specific line in MGTNGVN that is
Aug 6, 2008 to be investigated with SAS Technical Support, but this
iteration split the line and the FORMATS member now does
successfully execute on z/OS and PC SAS.
Thanks to Jerry Urbaniak, Acxiom, USA.
Thanks to Christian Hodel, SWISScom, SWITZERLAND.
Change 26.175 Support for NMON BBBP configuration records creates new
EXNMONBP NMONBBBP dataset. The LSCONF and LPARSTAT-I entries are
IMACNMON stored in variables BBBP001-BBBP047, with their labels
VMACNMON as the identifier of the item.
VMXGINIT
Aug 22, 2008
Thanks to John Keenam, Boeing, USA.
Change 26.174 First MXG 26.06's only. TYPE99_1 DATASET NOT FOUND in
TESTIBM2 JCLTEST8/JCLTEST9 because the TYPE99 code now writes to
VMACNMON //PDB (because the data must be deaccumulated) but the
Aug 5, 2008 TESTIBM2 member had PROC PRINT/PROC MEANS that expected
Aug 6, 2008 those data to be in the //WORK file.
-NMONBBBP By list had ENDTIME, now has STARTIME.
Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA.
====== Changes thru 26.173 were in MXG 26.06 dated Aug 4, 2008=========
Change 26.173 Support for Omegamon Tivoli Data Warehouse (TDW) data for
EXSUSELC z/Linux (SUSE 9.3) creates seven new datasets:
EXSUSELE DDDDDD DATASET Description Filename
EXSUSELI SUSELC SUSELCPU SUSE LINUX CPU SUSELCPU
EXSUSELN SUSELE SUSELNET SUSE LINUX NETWORK SUSELNET
EXSUSELP SUSELI SUSELIOE SUSE LINUX IO EXTERNAL SUSELIOE
EXSUSELS SUSELN SUSELNFS SUSE LINUX NFS STATISTICS SUSELNFS
EXSUSELV SUSELP SUSELPRO SUSE LINUX PROCESS SUSELPRO
IMACSUSE SUSELS SUSELSWA SUSE LINUX SWAP RATE SUSELSWA
TYPESUSE SUSELV SUSELVMS SUSE LINUX VM STATS SUSELVMS
TYPSSUSE Comments in member VMACSUSE show how to set up the
VMACSUSE FILENAME statements and then %INCLUDE SOURCLIB(TYPSSUSE);
VMXGINIT
Aug 4, 2008
Thanks to Jim Flanagan, ISO, USA.
====== Changes thru 26.172 were in MXG 26.06 dated Aug 1, 2008=========
Change 26.172 -Support for new NSM data fields NTCACHE, NTLOGICALDISK,
FORMATS NTMEMORY, NTPAGING FILE, NTPHYSICAL DISK, NTPROCESS and
VMACTNG NTSYSTEM datasets.
EXTNT133 -Support for new VMwares objects by Active Dictionary and
EXTNT134 VMware Virtual Center 2.5 Servers, VMware ESX 3.5.5 host
EXTNT135 servers and VM guest servers creates new datasets:
EXTNT136 TNT133 NT133 NSM CA INTERFACE GROUP
EXTNT137 TNT134 NT134 NSM VMWARE VC CLUSTER
EXTNT138 TNT135 NT135 NSM VMWARE VC DATASTORE
EXTNT139 TNT136 NT136 NSM VMWARE VC ESX HOST
EXTNT139 TNT137 NT137 NSM VMWARE VC ESX HOST C
EXTNT140 TNT138 NT138 NSM VMWARE VC ESX HOST D
EXTNT141 TNT139 NT139 NSM VMWARE VC ESX HOST M
EXTNT142 TNT140 NT140 NSM VMWARE VC ESX HOST N
EXTNT143 TNT141 NT141 NSM VMWARE VC EXX HOST P
EXTNT144 TNT142 NT142 NSM VMWARE VC RESOURCE P
EXTNT145 TNT143 NT143 NSM VMWARE VC SERVER
EXTNT146 TNT144 NT144 NSM VMWARE VC VM
EXTNT147 TNT145 NT145 NSM VMWARE VC VM CPU
EXTNT148 TNT146 NT146 NSM VMWARE VC VM DISK
Aug 2, 2008 TNT147 NT147 NSM VMWARE VC VM MEMORY
Aug 4, 2008 TNT148 NT148 NSM VMWARE VC VM NETWORK
Aug 6, 2008 TNT149 NT149 NSM AD EVENTS
Aug 24, 2008 TNT150 NT150 NSM AD PERFORMANCE
TNT151 NT151 NSM AD UTILIZATION
TNT152 NT152 NSM DNS
TNT153 NT153 NSM FILEREPLICACONN
TNT154 NT154 NSM FILEREPLICASET
TNT155 NT155 NSM NTDS
Added Aug 24 in 26.07:
TNT156 NT156 NSM VMWARE VC COMPUTE RE
Thanks to Michael Kynch, International Paper, USA.
Change 26.171 Protection so that ANALDB2R doesn't fail with USER=PDB.
ANALDB2R While USER=PDB is dis-recommended for BUILDPDB, and has
VMXGINIT caused errors with other programs, this change protects
Aug 2, 2008 but ONLY for ANALDB2R. DO NOT USE OPTIONS USER=PDB.
Thanks to Herbert Sweeney, Verizon Data Services Inc, USA.
Change 26.170 Circumvention for zero length VBS record in OPC Log file.
VMACOPC
Jul 31, 2008
Thanks to Andrew Davis, Produban, ENGLAND.
Change 26.169 Circumvention for 24 byte PRCAPM segment.
VMACXAM
Jul 29, 2008
Thanks to Tony Curry, BMC, USA.
Change 26.168 Support for DB2 SMF 102 IFCID=342 adds these variables:
VMAC102 QW0342TY ='DATABASE TYPE'
Jul 29, 2008 QW0342AT='AGENT TOKEN'
QW0342CI='CURRENT*INDEX*SPACE*USAGE'
QW0342CT='CURRENT*TABLES*SPACE*USAGE'
QW0342DB='DATABASE*DBID'
QW0342MI='MAXIMUM*INDEX*SPACE*USAGE'
QW0342MT='MAXIMUM*TABLES*SPACE*USAGE'
QW0342PS='TABLE/INDEX*SPACE*PSID'
QW0342PT='PARENT TOKEN'
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 26.167 Debugging version for invalid UWD record segments will
ASMRMFV avoid the USER ABEND and write defective records to the
Jul 29, 2008 //RMFSKIP DD (which needs to be added). ASMRMFVX, delete.
Thanks to Robert Carballo, Office Depot, USA.
Change 26.166 Support for AS/400 Version 6 Release 1 adds 3 variables
VMACQACS to the QAPMDISK dataset:
Jul 29, 2008 DSSECT ='DISK*UNIT*SECTOR*SIZE'
DSIOARN ='STORAGE*ADAPTER*RESOURCE*NAME'
DSSRLN ='DISK*UNIT*SERIAL*NUMBER'
and new variable to QAPMCONF dataset:
GDESXP ='PM*AGENT*DATA*OBTAINED?'
Thanks to David Bixler, FISERV, USA.
Change 26.165 A new "RMF Interval - WORKLOAD " dataset RMFWLKRV is now
EXRMFWKL also created when RMFINTRV is created; the new dataset
VMXGRMFI contains only the workload variables from RMF72, but
Jul 26, 2008 with one observation per workload, and only one set of
variables created, making workload analysis much easier.
The RMFWKLRV dataset has the same interval duration that
you chose for your RMFINTRV dataset; these are the
variables and labels in the new PDB.RMFWKLRV dataset:
DURATM DURATION*OF*INTERVAL
STARTIME START OF*INTERVAL
SYSNAME SYSNAME*FROM*IEASYSXX
SYSPLEX SYSPLEX*FROM*IEASYSXX
SYSTEM SYSTEM*ID
WKLDACTV WORKLOAD*ACTIVE*TIME
WKLDCPU WORKLOAD*CPU*TIME
WKLDDESC WORKLOAD*DESCRIPTION
WKLDEXCP WORKLOAD*EXCP*RATE
WKLDFRTM WORKLOAD*FRAME*TIME
WKLDHPT WORKLOAD*HPT*TIME
WKLDID WORKLOAD*ID
WKLDIFA WORKLOAD*IFA*PROCESSOR*TIME
WKLDIFE WORKLOAD*IFA*ELIGIBLE*PROCESSOR*TIME
WKLDIIP WORKLOAD*IIP*TIME
WKLDIOTM WORKLOAD*IO*CONNECT*TIME
WKLDMEMR WORKLOAD*MEMORY*USAGE
WKLDPGIN WORKLOAD*PAGEIN*RATE
WKLDRCT WORKLOAD*RCT*TIME
WKLDRESD WORKLOAD*RESIDENT*TIME
WKLDRESP WORKLOAD*AVG*RESPONSE
WKLDSERV WORKLOAD*SERVICE*UNITS
WKLDSRB WORKLOAD*SRB*TIME
WKLDSVRT WORKLOAD*SERVICE*RATE
WKLDSWAP WORKLOAD*SWAP*RATE
WKLDTCB WORKLOAD*TCB*TIME
WKLDTRAN WORKLOAD*TRANSACTIONS
WKLDTRRT WORKLOAD*TRANSACTION*RATE
WKLDWKST WORKLOAD*WORKING*SET
WKLDZIE WORKLOAD*ZIP*ELIGIBLE*PROCESSOR*TIME
WKLDZIP WORKLOAD*ZIP*PROCESSOR*TIME
Thanks to Don Goulden, SAS ITRM Development, USA.
Change 26.164 For the JES3 PDB, i.e., BUILDPD3, variable JOBCLASS was
BUIL3005 not kept from the SMF 30 subtype 1 and subtype 5, causing
Jul 26, 2008 it to be blank in some cases. It is now kept in both.
Aug 12, 2008 Additionally, it is now correctly kept as 8-bytes in the
PDB.SMFINTRV dataset, as well as being non-blank.
Thanks to Keving McCandlish, IBM Global Services, USA.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.163 Support for TPF PUT22 changes, and corrections to current
VMACTPF code.
Jul 21, 2008 New variables added by PUT22:
Dataset TPFDX:
DXNSDIN DXLMTRKS DXLMRSTT DXTSWB DXMODL DXCRYP
Dataset TPFSX:
SX4KFRMS
Corrections:
-The first SLOTNR was always re-read for all eight slots,
so dataset TPFMG never had data from the 2nd-8th slots.
-STARTIME was not populated for TPFMG dataset.
-The INPUT of SPXDISA1-4 and SPXRTRA1-4 were relocated to
the end of the SPX record; those variables were always
wrong until now.
Thanks to Bob Wilcos, EDS, USA.
Change 26.162 Reserved Change Number.
Jul 21, 2008
Change 26.161 New variable BESKEY='TAPE*ENCRYPTION*KEY*INDEX' is added
TYPETMS5 to dataset TMS to identify CA-1 encrypted tapes. This is
VMACTMS5 a reference/index into the CA Tape Encryption Data base
Jul 21, 2008 where the actual keys are stored, and it allows TMS to
determine when a key is no longer needed and can be
retired; TMS scans for non-scratch tapes that reference
a key, and if none are found for a specific index, that
key can then be safely retired.
Thanks to Jeff Harder, Indiana Farm Bureau, USA.
Change 26.160 Support for Omegamon User SMF records in SMF 112.
VMAC112 See Change 25.257, which replaced this text.
VMACOMCI
Jul 20, 2008
Thanks to Art Cuneo, Blue Cross Blue Shield of Illinois, USA.
Change 26.159 TYPE77 QUEUE1 thru QUEUE4 were wrong and could be GT 100.
VMAC77 The correct denominator TOT77QUE=SUM OF (QUEUE1-QUEUE4)
Aug 13, 2008 is now used to calculate those percentages, and is kept.
The calculation of Average Queue Length now matches IBMs
reports, using AVG77QUE=WAITS/TOT77QUE, where WAITS is
SMF77AQL, the total waiting requests, and new TOT77QUE
is the total number of waiters.
New variable RNAMEHEX is the printable hex value of the
first MINORQCB bytes of RNAME, so those RNAMEs that have
hex values can be seen when printed as plain text.
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.158 Cosmetic, but confusing. PDB.TYPE70 offline zip/zap
VMAC7072 engines had CAIxx='20'x instead of '00'X, had PCTIFBYx
Jul 17, 2008 and PCTZIPBx both 100%, had IFAWAITx and ZIPWAITx both 0,
and IFAWAITM and ZIPWAITM were also both zeros if all of
the zIIP and zAAP engines were offline during interval.
The IFAUPTM and ZIPUPTM were both correct (missing) when
all of these engines were offline. the NRIFAS and
NRZIPCPU variables still count the number of engines
available to this MVS system, even when all are offline.
Thanks to Christine DeClercq, Dexia, BELGIUM.
Change 26.157 Change 26.115 made consistent the BY lists for RMF sorts,
MONTHASC but only for the first three common variables. The
MONTHBL3 TYPE70 sort order was still inconsistent between BUILDPDB
MONTHBLD and WEEKBLD/MONTHBLD. Now, those combining jobs all have
MONTHBLS been updated to match the BUILDPDB order, which is:
MONTHDSK SYSPLEX SYSTEM SYSNAME SMF70GIE GMTOFFTM STARTIME
MONTHWEK
WEEKBL3D
WEEKBL3T
WEEKBLD
WEEKBLDD
WEEKBLDT
Jul 15, 2008
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 26.156 Hex variable FSRDORG is decoded in new character variable
VMACHSM FSRDSORG using the same logic used for DCOLLECT, except
Jul 15, 2008 that DCOLLECT provides bits to identify PDSE vs PDS.
Thanks to James J. Byrnes, ???, ???
Change 26.155 Support for SMF 99 Subtype 11 (Group Capacity Limits)
EXTY99BG creates two new datasets:
EXTY99BS DDDDDD DATASET SUBTYPE DESCRIPTION
IMAC99 TY99BG TYPE99BG 99-11 CAPACITY GROUP
VMAC99 TY99BS TYPE99BS 99-11 SERVICE DATA
VMXGINIT
Jul 23, 2008
Thanks to Scott Chapman, American Electric Power,USA.
Change 26.154 If an offline LPARNUM preceded this PARTISHN, SMF70LAC
VMAC7072 was missing in PDB.TYPE70PR and PDB.ASUM70LP/PDB.ASUMCELP
Jul 10, 2008 and the corresponding LPnLAC in PDB.ASUM70PR/PDB.ASUMCEC.
Thanks to Barry T. Mueller, RiteAid, USA.
Change 26.153 -Using ANALRMFR from MXG 26.01+ with PDB=PDB where that
ANALRMFR input PDB was created with an earlier MXG version caused
Jul 18, 2008 a series of error messages that variables suffixed Y, Z,
ZA ... are missing; those new variables for CPs up to 64
were expected by ANALRMFR; rerun with PDB=SMF to correct.
-ERROR: NO DATA SET OPEN TO LOOK UP VARIABLES corrected;
caused by hardcoded TYPE70SP instead of _WTY70SP.
-Updated to support 64 CP engines.
Thanks to Bill Cheng, Toyota, USA.
Change 26.152 New utility to remove duplicate SMF records from VBS data
UNDUPSMF file.
Jul 9, 2008
Thanks to Larry Stahl, IBM Global Services, USA.
Change 26.151 Support for APAR OA24416, which corrects overflow in
VMAC28 GBLCRPSA by adding a four byte "high part" at the end of
Jul 8, 2008 the 'D6'x NPM record.
Change 26.150 A typo caused the values of three SPG variables to be
VMACRMFV one tenth of their true value; the three variables
Jul 6, 2008 SPGTOTSP SPGFRESP SPGLGBLK are now multiplied by the
correct value of 1048576 instead of 104856.
Thanks to Roger Rush, Navistar, USA.
Change 26.149 Protection so that if SMF 21s and TYPETMNT were not added
UTILBLDP ASUMTAPE, ASUMTMNT and ASUMTALO are NOT included, but if
Jul 6, 2008 TYPETMNT is created, the ASUMTMNT and ASUMTALO are.
Thanks to Charles Savikas, State of Florida, USA.
Change 26.148 Enhancement to ASMTAPEE/MXGTMNT's capture of SYSLOG info,
ASMTAPEE now at ML-43 with this change, some revisions to ASUMTAPE
ASUMTAPE processing logic that improves the accuracy of several
VMACTMNT SYSLOG timestamps, and the creation of new SYLVTIME,
Jul 6, 2008 which is then used to improve the accuracy of variables
BEGTMNT, ENDTMNT, TOTMNTTM and TAPMTDTM values, some
variable labels were revised, and a new MXG Technical
Note to document what can still be missed by MXGTMNT.
-ML-43 of ASMTAPEE/MXGTMNT now captures the IEF233D mount
message in its subtype 8 records (output in TYPESYMT).
The IEF233D message is issued for non-ATL, non-VTS first
volume mounts from dynamic allocations that don't specify
the DEFER option. This message should have been in the
initial list (IEF233A, IEC501A, IEC501E) of mount events,
but was never observed until now, perhaps because it is
relatively infrequent.
-ASUMTAPE's logic revises how SYLMTIME, the SYSLOG Mount
time is populated; previously, if there was no SYSLOG
mount event, the time of a SYSLOG verify message was used
to populate SYLMTIME, but now, only mount event messages,
IEF233A, IEF233D, IEC501A, or IEC501E, are used.
-New logic in ASUMTAPE instead creates variable SYLVTIME,
SYSLOG Verify time, using the maximum time value of he
IECTMS6, IECTMS9, or IEC7095I SYSLOG messages.
-And SYLVTIME is now used in the creation of the ENDTMNT
mount event time variable in ASUMTAPE.
-The logic for BEGTMNT, ENDTMNT, TOTMNTTM and TAPMNDTM are
corrected, revised, and re-labeled:
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.
-VMACTMNT: New variables, decoded bits from TMNTFLAG,
were added to make debugging a little easier:
TMNTMSGI='MOUNT MESSAGE ISSUED'
TMNTJOBI='JOB*ENDED*EVENT'
TMNTJOBC='JOB*CANCELLED*BY*OPERATOR'
Thanks to Yves Cinq-Mars, IBM Global Services, CANADA.
Change 26.147 Cosmetic. The LPnNRPRC variables that count the number
VMXG70PR of CP engines in the ASUM70PR and ASUMCEC datasets are
Jul 2, 2008 now FORMATted 6.1 to match the LPARCPUS format that was
made in Change 26.003.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA
Change 26.146 Support for VXVNDSES dataset for zVM Domain 8 record 1.
FORMATS
VMACVMXA
Jul 2, 2008
Thanks to Sharon Moir, JPMorgan Chase Bank, USA.
Change 26.145 Support for BMC Mainview for CICS CMR record CMRTYPE=109.
VMACMVCI The CMRTYPE=109 records are written for ABENDs; only the
Jul 2, 2008 CMRTYPE=110 records were previously processed by MXG.
Variable CMRTYPE was added to both datasets as well.
Thanks to David Edge, Thompson Reuters, USA.
Change 26.144 The example ftp instructions for sending data files were
FTPSMF all corrected; the syntax /yourname.xxx are all now
FTPVB changed to the syntax of just yourname.xxx; that leading
JCLFTP slash tried to write to the root directory, which was not
NEWSLTRS the desired target destination.
SENDDATA
Jul 1, 2008
Thanks to Trevor Ede, EDS, NEW ZEALAND.
Change 26.143 The Virtualization Engine TS7700 Statistical data in the
VMACBVIR MXG BVIR32 dataset was trashed; these 4 one-byte fields
Jun 30, 2008 were not INPUT, causing subsequent variables to be out
of alignment:
DVAVAD00='00*AVAILABLE*PHYSICAL*DEVICES'
DVAVAD01='01*AVAILABLE*PHYSICAL*DEVICES'
DVAVAD02='02*AVAILABLE*PHYSICAL*DEVICES'
DVAVAD03='03*AVAILABLE*PHYSICAL*DEVICES'
Thanks to Josep Miquel Oliver, La Caixa, SPAIN.
Change 26.142 New variables added to DCOLLECT dataset DCOLDSET:
VMACDCOL DCDCKDSI='CHECKPOINT*DS*INDICATED?'
Jun 30, 2008 DCDCPOIT='CHECKPOINTED*DATASET?'
DCDGT64K='GT 64K*TRACK*DATASET?'
and new values created for DCDDSORG for HFS and PDSE;
unfortunately, DCEDSORT is only three bytes, so the text
value for PDSE is set to PDS"
DCDDSORG='HFS' for HFS dataset
DCDDSORG='PDS' for PDSE dataset
These two values are set based on IBM support's reply, as
only the bits are documented in the IDCDOUT DSECT, but not
the logic:
IF DCDPDSE='Y' AND DCDPDSEX=' ' THEN DCDDSORG='PDS'; /*PDSE*/
IF DCDPDSE='Y' AND DCDPDSEX='Y' THEN DCDDSORG='HFS'; /*HFS*/
However, there are several hundred DCOLDSET observations
that have DCDDSORG blank, because the three flag bytes
whose bits are used to define DCDDSORG, MXG variables
DCDSORG1, DCDSORG2 and DCDFLAG3, all contain hex zeroes;
a new query back to DCOLLECT technical support is raised.
These blank values are believed to be from datasets
that were allocated but never opened.
Thanks to Trevor Ede, EDS, NEW ZEALAND.
Change 26.141 CICS STID=74 (SMF 110 Subtype 2 Statistics) length of 228
VMAC110 was incorrectly documented in DFHMQGDS, causing MXG to
Jun 30, 2008 print ERROR (NEW DATA) SKIPPED message on the log. But,
MXG's INPUT was off by 4 bytes (Queue Manager is only 4),
The INPUT is corrected, the extra reserved bytes are now
skipped, that ERROR message is now a WARNING message, and
dataset CICIMQ (CICS MQ STATISTICS) is now corrected.
Thanks to Ray Dunn, CIGNA, USA.
Thanks to Murray Town, Suncorp, AUSTRALIA.
Thanks to MP Welch, SPRINT, USA.
Thanks to David J Schumann, Blue Cross of Minnesota, USA.
====== Changes thru 26.140 were in MXG 26.05 dated Jun 18, 2008=========
Change 26.140 Example analysis of DB2 Package resources from DB2ACCTP.
ANALPKGS
Jun 17, 2008
Thanks to Myles M. Reed, NS Corp, USA.
Change 26.139 MXG's DOCVER and DOCVERnn members are limited to 72 bytes
UTILXRF1 per line, which permitted only 8-byte variable names; MXG
UTILVREF now creates some datasets with variable names longer than
Jun 17, 2008 8-bytes, so the DOCVER and DOCVERnn members are revised;
if the length of the variable is more than 8 bytes, the
variable name is printed on a separate line. SAS itself
limits variable names to 32 characters.
Change 26.138 EKC's EFT/R FIRECALL SMF 80 record was changed, causing
VMAC80A INPUT STATEMENT EXCEEDED RECORD length, because MXG
Jun 17, 2008 didn't expect the changed record.
Thanks to Yaohua Hu, ISO, USA.
Change 26.137 For QA testing; setting TAPENGN to V9SEQ/V8SEQ is now
VMXGINIT only done for MXG under z/OS; MONTHBLD died in QA tests
Jun 17, 2008. because V9SEQ does not exist in ASCII versions of SAS.
Change 26.136 -Variable QW0119GP, CURRENT GET PAGES, added to T102S199.
VMACDB2 -Variable QW0225BB was mis-located in the MXG Input, and
VMAC102 should not have been converted to bytes, it is blocks.
Jun 17, 2008 Both VMACDB2 and VMAC102 process the IFCID=225 segment.
Thanks to Steve Wood, DST Systems Inc, USA.
Change 26.135 ASMTAPEE ML-42 backs out the incorrect JOBname that was
ASMTAPEE added in ML-41. Change 26.128 revised MXG TYPETMNT code
Jun 16, 2008 to use JOB from the SYSLOG message text, while we still
try to find the location of that second JOB name.
Change 26.134 Cosmetic change; test for length remaining for optional
IMACICRD DFHRMI segment for CICS/TS 3.2 added for length 96.
Jun 16, 2008
Thanks to Paul C. Gordon, Bank of America, USA.
Change 26.133 Complete rewrite of MXG support for CA SYSVIEW, replacing
EXSVEV01 the partial support (2005) in TYPESYSV and TYPESYSI.
EXSVEV02 The new support now creates seventy-four datasets:
EXSVEV03
EXSVEV04 DDDDDD Dataset Description
EXSVEV05 token Name
EXSVEV06
EXSVEV07 SVEV01 SV01EV01 SVEV01: SYSVIEW AUDIT 01 NOOP
EXSVEV08 SVEV02 SV01EV02 SVEV02: SYSVIEW AUDIT 02 START
EXSVEV09 SVEV03 SV01EV03 SVEV03: SYSVIEW AUDIT 03 SHUTDOWN
EXSVEV10 SVEV04 SV01EV04 SVEV04: SYSVIEW AUDIT 04 SESSION
EXSVEV11 SVEV05 SV01EV05 SVEV05: SYSVIEW AUDIT 05 SESSION
EXSVEV12 SVEV06 SV01EV06 SVEV06: SYSVIEW AUDIT 06 COMMAND
EXSVEV13 SVEV07 SV01EV07 SVEV07: SYSVIEW AUDIT 07 COMMAND
EXSVEV14 SVEV08 SV01EV08 SVEV08: SYSVIEW AUDIT 08 THRESHOL
EXSVEV15 SVEV09 SV01EV09 SVEV09: SYSVIEW AUDIT 09 STATE MO
EXSVEV16 SVEV10 SV01EV10 SVEV10: SYSVIEW AUDIT 10 MONITOR
EXSVEV17 SVEV11 SV01EV11 SVEV11: SYSVIEW AUDIT 11 ASID ACT
EXSVEV18 SVEV12 SV01EV12 SVEV12: SYSVIEW AUDIT 12 CONSOLE
EXSVEV19 SVEV13 SV01EV13 SVEV13: SYSVIEW AUDIT 13 WEB MQ C
EXSVEV20 SVEV14 SV01EV14 SVEV14: SYSVIEW AUDIT 14 IMS COMM
EXSVEV21 SVEV15 SV01EV15 SVEV15: SYSVIEW AUDIT 15 CICS CEM
EXSVEV22 SVEV16 SV01EV16 SVEV16: SYSVIEW AUDIT 16 DSN SERV
EXSVEV23 SVEV17 SV01EV17 SVEV17: SYSVIEW AUDIT 17 LPA MODI
EXSVEV24 SVEV18 SV01EV18 SVEV18: SYSVIEW AUDIT 18 SVCTABLE
EXSVEV25 SVEV19 SV01EV19 SVEV19: SYSVIEW AUDIT 19 SUBSYS M
EXSVEV26 SVEV20 SV01EV20 SVEV20: SYSVIEW AUDIT 20 PPT MODI
EXSVEV27 SVEV21 SV01EV21 SVEV21: SYSVIEW AUDIT 21 WTOR REP
EXSVEV28 SVEV22 SV01EV22 SVEV22: SYSVIEW AUDIT 22 LOGSTREA
EXSVEV29 SVEV23 SV01EV23 SVEV23: SYSVIEW AUDIT 23 LOGSTREA
EXSVEV30 SVEV24 SV01EV24 SVEV24: SYSVIEW AUDIT 24 PRODUCT
EXSVEV31 SVEV25 SV01EV25 SVEV25: SYSVIEW AUDIT 25 LINKSET
EXSVEV32 SVEV26 SV01EV26 SVEV26: SYSVIEW AUDIT 26 LINKLIST
EXSVEV33 SVEV27 SV01EV27 SVEV27: SYSVIEW AUDIT 27 STORAGE
EXSVEV34 SVEV28 SV01EV28 SVEV28: SYSVIEW AUDIT 28 AMRF ACT
EXSVEV35 SVEV29 SV01EV29 SVEV29: SYSVIEW AUDIT 29 ESRTABLE
EXSVEV36 SVEV30 SV01EV30 SVEV30: SYSVIEW AUDIT 30 TSOTABLE
EXSVEV37 SVEV31 SV01EV31 SVEV31: SYSVIEW AUDIT 31 REGPROD
EXSVEV38 SVEV32 SV01EV32 SVEV32: SYSVIEW AUDIT 32 DUMPDS M
EXSVEV39 SVEV33 SV01EV33 SVEV33: SYSVIEW AUDIT 33 CICSTRAN
EXSVEV40 SVEV34 SV01EV34 SVEV34: SYSVIEW AUDIT 34 CICS THR
EXSVEV41 SVEV35 SV01EV35 SVEV35: SYSVIEW AUDIT 35 CICS STA
EXSVEV42 SVEV36 SV01EV36 SVEV36: SYSVIEW AUDIT 36 MQ QUEUE
EXSVEV43 SVEV37 SV01EV37 SVEV37: SYSVIEW AUDIT 37 USER EVE
EXSVEV44 SVEV38 SV01EV38 SVEV38: SYSVIEW AUDIT 38 MQ CHAN
EXSVEV45 SVEV39 SV01EV39 SVEV39: SYSVIEW AUDIT 39 CICS TS
EXSVEV46 SVEV40 SV01EV40 SVEV40: SYSVIEW AUDIT 40 SET EXTN
EXSVEV47 SVEV41 SV01EV41 SVEV41: SYSVIEW AUDIT 41 SET GRAN
EXSVEV48 SVEV42 SV01EV42 SVEV42: SYSVIEW AUDIT 42 CICS STA
EXSVEV49 SVEV43 SV01EV43 SVEV43: SYSVIEW AUDIT 43 CICS SHU
EXSVPLOT SVEV44 SV01EV44 SVEV44: SYSVIEW AUDIT 44 DATA SET
EXSVTHRE SVEV45 SV01EV45 SVEV45: SYSVIEW AUDIT 45 TASK STA
EXSVSTAT SVEV46 SV01EV46 SVEV46: SYSVIEW AUDIT 46 TASK STO
EXSVCEXC SVEV47 SV01EV47 SVEV47: SYSVIEW AUDIT 47 JES2 JOB
EXSVTSUM SVEV48 SV01EV48 SVEV48: SYSVIEW AUDIT 48 JES2 OUT
EXSVTRAN SVEV49 SV01EV49 SVEV49: SYSVIEW AUDIT 49 JES2 OUT
EXSVPROG SVPLOT SV02PLOT SVPLOT: SYSVIEW PLOT
EXSVFILE SVTHRE SV08THRE SVTHRE: SYSVIEW THRESHOLD EXCEPTI
EXSVTMPS SVSTAT SV09STAT SVSTAT: SYSVIEW STATE EXCEPTION
EXSVTDTA SVCEXC SV24CEXC SVCEXC: SYSVIEW EXCEPTION
EXSVABND SVTSUM SV25TSUM SVTSUM: SYSVIEW CICS TRANS SUMMAR
EXSVEXCE SVTRAN SV27TRAN SVTRAN: SYSVIEW CICS TRANSACTION
EXSVMEMP SVPROG SV27PROG SVPROG: SYSVIEW CICS PROGRAMS
EXSVDLI SVFILE SV27FILE SVFILE: SYSVIEW CICS FILES
EXSVTHRS SVTMPS SV27TMPS SVTMPS: SYSVIEW CICS TEMPORARY ST
EXSVRESM SVTDTA SV27TDTA SVTDTA: SYSVIEW CICS TRANSIENT DA
EXSVDCOM SVABND SV27ABND SVABND: SYSVIEW CICS ABENDS
EXSVEXIN SVEXCE SV27EXCE SVEXCE: SYSVIEW CICS EXCEPTIONS
EXSVWBMQ SVMEMP SV27MEMP SVMEMP: SYSVIEW CICS MONITOR EMPS
EXSVDB2 SVDLI SV27DLI SVDLI: SYSVIEW CICS DL/I
EXSVMEIE SVTHRS SV27THRS SVTHRS: SYSVIEW CICS THRESHOLDS
EXSVINTV SVRESM SV27RESM SVRESM: SYSVIEW CICS RESOURCE MAN
EXSVIMST SVDCOM SV27DCOM SVDCOM: SYSVIEW CICS DATACOM CSF
EXSVIMSP SVEXIN SV27EXIN SVEXIN: SYSVIEW CICS EXEC INTERFA
EXSVMQRR SVWBMQ SV27WBMQ SVWBMQ: SYSVIEW CICS WEBSPHERE MQ
IMACSVIE SVDB2 SV27DB2 SVDB2: SYSVIEW CICS DB2
TYPESVIE SVMEIE SV27MEIE SVMEIE: SYSVIEW CICS MEI EVENT
TYPSSVIE SVINTV SV28INTV SVINTV: SYSVIEW CICS INTERVAL SUM
VMACSVIE SVIMST SV32IMST SVIMST: SYSVIEW IMS TRANSACTION
VMXGINIT SVIMSP SV33IMSP SVIMSP: SYSVIEW IMS PROGRAM SUMMA
Jun 17, 2008 SVMQRR SV48MQRR SVMQRR: SYSVIEW MQ APP REGIONS
Change 26.132 Minor correction; if optional RMFFILT DD was missing but
ASMRMFV RMFSKIP DD was present, ASMRMFV could fail with USER 998
Jun 14, 2008 when attempting to close the nonexistent RMFFILT DDname.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 26.131 The reports on MIPS/MSU usage for CP engine is enhanced
ASUMMIPS to also report on zIIPs and zAAPs, by adding variables
Jul 18, 2008 CPUIFATM CPUZIPTM NRIFAS NRZIPCPU IFAUSED ZIPUSED MIPSIFA
MIPSZIP with _MIPSIFA and _MIPAZIP macros that define the
factors in the same way as base CP conversion factors.
Thanks to Robert Kuhne, Exelon Corporation, USA.
Change 26.130 Notes for CICS IMACICEZ, IMACICE1, IMACICE2 tailoring.
IMACICEZ These notes originated in Change 24.033, then 25.xxx and
IMACICE1 are repeated here, as well as in comments in UTILEXCL
IMACICE2 These members are required to be tailored if your CICS
UTILEXCL records contain 'EZA01' or 'EZA01' optional segments:
Jun 14, 2008
-IMACICEZ always has these 5 fields, identified by their
CMODNAME='EZA01' and CMODTYPE='S':
EZA01 S 001 12 ooo INIT
EZA01 S 002 12 ooo READ
EZA01 S 003 12 ooo WRITE
EZA01 S 004 12 ooo SELECT
EZA01 S 005 12 ooo OTHER
The CMODLENG=12 is from CICS/3.2; earlier CICS had only
CMODLENG=8, but IMACICEZ supports both lengths, so you
just remove the comment block to tailor IMACICEZ and it
will process data with either or both lengths.
-IMACICE1 can have up to 13 fields, identified by their
CMODNAME='EZA01' and CMODTYPE='A' (yes, CMODNAME is the
same 'EZA01' as IMACICEZ, but the CMODTYPE is different):
EZA01 A 001 4 ooo TINIT
EZA01 A 002 4 ooo TREAD
EZA01 A 003 4 ooo TWRITE
EZA01 A 004 4 ooo TSELECT
EZA01 A 005 4 ooo TOTHER
EZA01 A 006 4 ooo REUSABLE
EZA01 A 007 4 ooo ATTACHED
EZA01 A 008 4 ooo OPENAPI
EZA01 A 009 4 ooo TCBLIM
EZA01 A 010 4 ooo TREUSABL
EZA01 A 011 4 ooo TATTACHE
EZA01 A 012 4 ooo TOPENAPI
EZA01 A 013 4 ooo TTCBLIM
You will have to examine REPORT THREE (which may have the
last CMODHEAD field 'EZA01' instead of the names shown)
to know how many fields are in your data. If you have the
expected 13 fields, then you just remove the one comment
block. If you have fewer fields, then:
- Change the IF xxxx GE 52 THEN DO; statement so its
test value is 4 times the number of fields, e.g.
with seven fields change the "52" to "28".
- Change the INPUT statement's suffix from EZA01A13 to
the number of fields you have; if there are seven:
INPUT (EZA01A01-EZA01A07) (&PIB.4.) @;
- Delete the LABELs for variables that don't exist.
-IMACICE2 has 22 fields with z/OS 1.7 TCP/IP data, but had
only 11 fields with z/OS 1.4, which are identified by the
CMODNAME='EZA02' and CMODTYPE='A:
EZA02 A 001 4 330 CONN
EZA02 A 002 4 331 STARTED
EZA02 A 003 4 332 INVALID
EZA02 A 004 4 333 DISTRAN
EZA02 A 005 4 334 DISPROG
EZA02 A 006 4 335 GIVESOKT
EZA02 A 007 4 336 SECEXIT
EZA02 A 008 4 337 NOTAUTH
EZA02 A 009 4 338 IOERR
EZA02 A 010 4 339 NOSPACE
EZA02 A 011 4 340 LENERR
EZA02 A 012 4 341 TCONN
EZA02 A 013 4 342 TSTARTED
EZA02 A 014 4 343 TINVALID
EZA02 A 015 4 344 TDISTRAN
EZA02 A 016 4 345 TDISPROG
EZA02 A 017 4 346 TGIVESOK
EZA02 A 018 4 347 TSECEXIT
EZA02 A 019 4 348 TNOTAUTH
EZA02 A 020 4 349 TIOERR
EZA02 A 021 4 350 TNOSPACE
EZA02 A 022 4 351 TLENERR
You will HAVE to look at UTILEXCL REPORT THREE to confirm
if you have 22 or 11 fields, and remove only one of the
two comment blocks in IMACICE2 to tailor it.
-You create REPORT THREE with the _RPTEXCL macro run
with or after your UTILEXCL execution:
//SYSIN DD *
%INCLUDE SOURCLIB(UTILEXCL);
_BLDDICT;
_BLDEXCL;
_RPTEXCL;
Change 26.129 Format TAOTRMCD existed in FORMATS (but did not have the
FORMATS OTHER='UNKNOWN' value statement), and it was not applied
VMACTAO to variable TAOTRMCD in VMACTAO until now.
Jun 12, 2008
Thanks to Steve Clark, DHL IT Services Americas, USA.
Change 26.128A ASMTAPEE ML-41 (MXG 26.03-26.04) IS DEFECTIVE.
VMACTMNT But you do NOT need to replace the MXGTMNT monitor task
Jun 12, 2008 if it is already installed, as this circumvention will
correct the error. You will need to reprocess the SMF
records created with ML-41 with the new VMACTMNT from
this change.
The error impacts the PDB.ASUMTAPE dataset; the TYPETMNT
data is correct with ML-41 monitor. However, to capture
ALL tape mount events, you must use the ASUMTAPE program
and then use PDB.ASUMTAPE dataset (and not PDB.TYPETMNT)
to capture the DFHSM mounts, 2nd mounts and other mounts
that do not go thru the IBM/STC exits; those events are
depend on the subtype 8 SYSLOG records in PDB.TYPESYMT
that ASUMTAPE combines with TYPETMNT and TYPE21 datasets
to capture EVERY mount in PDB.ASUMTAPE.
The error is only in the PDB.TYPESYMT SYSLOG dataset; the
JOB field in the subtype 8 record with ML-41 is in error
as it contains the JCTJOBID value, rather than JOB name,
which causes JESNR to be a missing value in PDB.TYPESYMT,
which then causes ASUMTAPE to fail to match up the SYSLOG
event data with the TYPETMNT and TYPE21 records.
This revision to VMACTMNT captures the JOB name from the
SYSLOG message text, rather than the JOB field, and the
VGETJESN was relocated to use the correct JOB name to
decode the JESNR from JCTJOBID.
Not an error, but it was observed that the PROGRAM name
in the TYPETMNT dataset is always blank; that field was
only capturable when the (now archaic) cross-memory
XMEM=YES option was used, prior to the exit-driven
redesign. Since TYPETMNT has JOB READTIME and JESNR,
the PROGRAM can be acquired from the PDB.STEPS dataset.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.128 Prisma SMF record was changed by the vendor, by insertion
VMACPRPR of a text field, subsequently identified as the PRINTER
Apr 11, 2008 between ACCOUNT and SHEETS. The change was made in April
Jun 12, 2008 as Change 26.067, but never made it into CHANGES, and the
change number was reused.
Thanks to Carl Sablon, KBC Bankverzekerinngsholding, BELGIUM.
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 26.126 Support for WebSphere incorrect triplets in subtype 3.
VMAC120 Instead of properly using the triplet SM120SRN field to
Jun 11, 2008 count the number of Server Region Sections, IBM chose to
implement an aberrant design by instead creating 0-n new
triplets (offset, length, count) in the record header!
This "feature" caused MXG to only output the first data
section in dataset TYP120SR. Circumvention code now uses
SM120TRN-2 (number of triplets minus two) to loop across
the Server Regions. This error was detected because the
total number of allocation failures, SM120HIC, was much
smaller than expected, and a detail trace identified that
only one Server Region was being output.
Thanks to Lisa Oulette, Wachovia Information Technology, USA.
Change 26.125 Support for NTSMF new Objects:
EXNTBITS DDDDDD DATASET DESCRIPTION/OBJECT NAME
EXNTPACE NTBITS BITSNET BITS NET UTILIZATION
EXNTUSB NTPACE PACEPIPE PACER PIPE
IMACNTSM NTUSB USB USB
VMACNTSM -Jun 17, 2008: Variable PACEINST was misspelled
VMXGINIT as PACEPIPE in the _BNTPACE macro definition, causing
Jun 17, 2008 the PROC SORT of dataset PACEPIPE to fail.
Jun 11, 2008
Thanks to Lisa E. Van Allen, Boeing, USA.
Change 26.124 INPUT STATEMENT EXCEEDED for short (possibly defective)
VMACITRF type '11'x ITRF record of only 176 bytes; current ITRF
Jun 10, 2008 record should be 304 bytes long. The record contains
only the Input Terminal and Date and Time and the 4-byte
"UNIQUE" hex field; all other fields are nulls or blanks.
The observation is still output in ITRFMSGO dataset, and
short records can be identified/counted by the variables
COT, LOQT, OQT (and others) having missing values.
Thanks to Prashant Joshi, Perot Systems, USA.
Change 26.123 -Support for new fields added to NTSMF MEMORY object:
VMACNTSM FRZRPLBY='FREE AND ZERO*PAGE LIST*BYTES'
Jun 9, 2008 MODFPLBY='MODIFIED*PAGE LIST*BYTES'
Jun 17, 2008 SBCACOBY='STANDBY*CACHE*CORE*BYTES'
SBCANPBY='STANDBY*CACHE*NORMAL*PRIORITY*BYTES'
SBCARSBY='STANDBY*CACHE*RESERVE*BYTES'
-Support for new field added to NTSMF PROCESS object:
WKSETPRV='WORKING*SET*PRIVATE'
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 26.122 Incorrect JOB name was parsed from SYSLOG text that had
ASUMTAPE three comma delimiters. The SAS SCAN function treats all
Jun 5, 2008 repeated delimiters as a single delimiter (why, no one at
SAS can explain, but that 'feature' is documented!), so
the use of TRANWRD(text,',,',', ,') ahead of the SCAN()
was suggested, which worked fine with two delimiters.
However, IEF234E messages with 'D 0F80,,,ZY11110,STEP099'
(unexpected, a dismount with no volser nor PVT/PUB/STR on
a 3590 device) were only expanded to 0F80, ,,ZY1110 so
the subsequent SCANs returned wrong values in WORD2-5.
Now, five TRANWRDs are executed to ensure the SCAN parse
properly decodes the JOB and STEP.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to David Bixler, FISERV, USA.
Change 26.121 IBM/Candle/OMEGAMON Audit Records can be buried inside
VMACOMAU CICS records; this change protects so only Audit records
Jun 4, 2008 are processed by TYPEOMAU. Several variables that do not
exist in the Audit records were removed.
Thanks to Joe Faska, Depository Trust, USA.
====== Changes thru 26.120 were in MXG 26.04 dated Jun 4, 2008=========
Change 26.120 The CICSEXCE Exception Report examples have been useless
ANALCICS for years, as the individual wait/counts have not been
Jun 4, 2008 been populated. Only these variables are populated in
the CICSEXCE dataset:
ENDTIME EXCMNBTR EXCMNCPN EXCMNFCN EXCMNNID EXCMNNPX
EXCMNNSX EXCMNRIL EXCMNRIL EXCMNRIX EXCMNRLU EXCMNRPT
EXCMNRTY EXCMNSRV EXCMNTCN EXCMNTRF EXCMNTYP EXCMNURI
EXCMNURI EXWAITTM LUNAME OPERATOR STRTTIME TASEXCNR
TASKNR TCLASS TERMINAL TRANNAME TRANPRI TRANTYPE
USER
A new report totals EXWAITCN and EXWAITM and calculates
the AVGWAITM for each APPLID EXCMNTYP EXCMNRTY EXCMNRIX
has been added to the examples in ANALCICS.
Thanks to Robert Carter, PNC Bank, USA.
Change 26.119 Variable LCU is added to TYPE74CA, by converting CSSSID
VMAC74 from character to numeric, and variables CUSERIAL and
Jun 4, 2008 CUVENDOR are created by substring from R745CCMT.
On IBM RMF reports, they print "CUID"-"CSDEVN" value and
"SSID"-"CSSSID" value (now, "SSID"-"LCU" value).
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 26.118 Almost cosmetic; the TEST parameter (which writes MXGTMNT
ASMTAPEE data to a flat file, instead of to SMF) did not work.
Jun 4, 2008 This first ML-42 was never distributed see Change 26.136.
Thanks to Alexander Raeder, ATOSORIGIN, GERMANY.
Change 26.117 Dataset TYPE747C was missing almost all observations; the
VMAC74 output statement was outside the DO loop over CUs. And,
Jun 4, 2008 variable R747SDEV is now KEPT in TYPE747C so it can be
matched up with TYPE747P observations.
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 26.116 Support for APAR OA22414 adds new variables to TYPE23
VMAC23 SMF Statistics Records:
Jun 4, 2008 SMF231RF='FIRST*REFERENCE*FAULTS'
SMF23NFR='FIX*REQUESTS*BELOW*2GM'
SMF23NGR='GETMAIN*REQUESTS*ISSUED'
SMF23NIO='TOTAL*I/O*OPERATIONS'
SMF23NRF='NON-FIRST*REFERENCE*FAULTS'
SMF23PBG='PAGES*BACKED*DURING*GETMAINS'
SMF23PFX='FRAMES*FIXED*BELOW*2GB'
SMF23SRB='SRB*DISPATCHES'
SMF23TCB='UNLOCKED*TCB*DISPATCHES'
SMF23SFG='STATISTICS*SECTION*FLAG'
The SMF23SFG bits 0 thru 8, if on, indicate that the
value in the corresponding nine variables were limited
to four bytes internally and could have wrapped if the
value was more than 4x10**9; MXG inputs all nine fields
as eight bytes.
Change 26.115 Inconsistent BY list for RMF data are now consistent.
VMAC7072 The correct sequence is SYSPLEX SYSTEM SYSNAME ... but
WEEKBLD SYSNAME was not always present, and in some cases it was
MONTHBLD SYSNAME, in others it was the &MXGSYSN macro variable
Jun 3, 2008 name (needed only way back in Version 23 to protect for
earlier MXG versions).
Unless you have duplicate SYSTEM names in a SYSPLEX, the
SYSNAME is identical to SYSTEM, so its insertion will not
have any impact on the actual sorted order.
(Of course, if you have multiple SYSTEMs with the same
SYSTEM name, then the SYSNAMEs will be different, so
there is a SMALL chance this could cause a NOT SORTED
condition when you combine dailies into weekly/monthly
PDB libraries).
Thanks to Brian Crow, BT, ENGLAND.
Change 26.114 z/VM MONWRITE BAD CONTROL RECORD error because MXG didn't
VMACVMXA protect the 6.24 correctly.
May 30, 2008
Thanks to Sharon Moir, JPMorgan Chase Bank, USA.
Change 26.113 Variable IORATE=DVTSAMPA/DURATM is now created in the
VMACRMFV ZRBDVT dataset.
May 30, 2008
Thanks to Rodger Foreman, Acxiom, USA.
Change 26.112 MXG 26.03: TYPE70 variables CPUMVSTM, PCTMVSBY, SHORTCPS
VMAC7072 and PLCPRDYQ are missing if not on a z10 processor; the
May 30, 2008 support added for SMF70PAT (CPUPATTM, parked time) failed
to protect those calculations when CPUPATTM was a missing
value. Fortunately, you can recalculate from PDB.TYPE70:
CPUMVSTM=CPUUPTM-MVSWAITM;
IF CPUUPTM GT 0 THEN PCTMVSBY=100*CPUMVSTM/CPUUPTM;
IF PCTMVSBY GT 0 AND PCTCPUBY GT 0 THEN DO;
SHORTCPS=PCTMVSBY/PCTCPUBY;
PLCPRDYQ=100*(PCTMVSBY-PCTCPUBY)/PCTMVSBY;
IF . LT PLCPRDYQ LT 0 THEN DO;
SHORTCPS=1;
PLCPRDYQ=0;
END;
END;
Thanks to Charles Savikas, DCF State of Florida, USA.
Change 26.111 -Support for TMVS Release 4.1, INCOMPATIBLE due to fields
EXTMVCN inserted in the "JD" records. Many new variables for the
EXTMVCNM zIIP and zAAP engines are created in the Job records.
EXTMVCNP -The code is enhanced to full "standard" structure, with
EXTMVCNS the _Vdddddd macros created, and the _Sdddddd sort macros
EXTMVCO now invoking PROC SORT NODUP to remove duplicates instead
EXTMVCOF of being simple DATA steps.
EXTMVCOH -Redundant variables with STARTIME, ENDTIME and DURATM are
EXTMVCOP removed.
EXTMVCOS -Thirty new datasets are created, for all of the possible
EXTMVCY record types, and all datasets for which I have data
EXTMVCYD records are populated and duplicate-removal-validated.
EXTMVEC -New IHDRTMVS exist allows deletion of unwanted record
EXTMVES types.
EXTMVHC
EXTMVHM
EXTMVHS
EXTMVMC
EXTMVMCL
EXTMVMCV
EXTMVRG
EXTMVX1
EXTMVX3
EXTMVX4
EXTMVXC
EXTMVXD
EXTMVXN
EXTMVXO
EXTMVXP
EXTMVXS
EXTMVXW
IHDRTMVS
IMACTMVS
VMACTMVS
VMXGINIT
Jun 2, 2008
Thanks to Sam Bass, McLane Co., USA.
Change 26.110 A new MXG ERROR message is printed for PDB.RMFINTRV if
VMXGRMFI there are no TYPE72GO observations that match the TYPE70
May 28, 2008 observations. The resultant PDB.RMFINTRV observation has
PCTOVHD and CPUOVHTM and CPUTM missing values.
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.109 Cosmetic. New values for QWACRINV were not formatted by
ADOCDB2 the MGDB2RC format, and value 40 should have been ABNORM.
FORMATS
May 22, 2008
Thanks to Christa Neven, KBC Bankverzekerinngsholding, BELGIUM.
Change 26.108 CICS optional IMS data segment with CMODNAME='USER' and
UTILEXCL CMODHEAD='SCHDPDS' or 'SCHDTIME' or 'CALLDLI' is now
May 22, 2008 recognized and is supported by the existing IMACICDL
member. Previously, all IMS segments had the values of
'PSB WAIT', 'PSB SCHD', 'DB CALL', and 'DB IO' for those
fields, and these unexpected text fields cause MXG to
NOT identify IMACICDL as needed when UTILEXCL ran.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 26.107 INPUT STATEMENT EXCEEDED with SMF 80 with new ASSIZMAX
VMAC80A value in TOKDANAM; that field is not INPUT as TOKASIZM
May 21, 2008 and kept in all TYPE80xx datasets with extended data.
Thanks to Clayton Buck, UniGroup, USA.
Change 26.106 Enhancement for AF/OPER SMF record support.
VMACAFOP These variables are now INPUT and KEPT in all datasets:
May 19, 2008 AFOMATNR AFOMATTY AFOTRNAM AFOCPUTM AFOEXECN AFOCONSN
The AFOCPUTM is now input as &PIB.4.3.
Thanks to Joe Faska, Depository Trust, USA.
Change 26.105 The label for variable R723CSUP is clarified to read
VMAC7072 R723CSUP='UN-NORMALIZED*ZIP*SERVICE*UNITS'
May 19, 2008 because it contains the zip service units before their
normalization back to the same scale as the CPUUNITS.
The variable ZIPUNITS contains the normalized service
units. ZIPUNITS and R723CSUP are different ONLY if the
CP engine speed is less than the ZIP engine speed.
Thanks to Bret Hoesly, Telephone & Data Systems, Inc, USA.
Change 26.104 Variable SMF70PMU was not divided by NRSAMPLE and its
VMAC7072 label was incorrect. It now is
May 19, 2008 SMF70PMU='AVG BLKED*DISPATCH*UNITS*PROMOTED'
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 26.103 INPUT STATEMENT EXCEEDED ID=42 SUBTYPE=15 when there were
VMAC42 more than one S2 segment. MXG logic for LENGTH test was
May 19, 2008 corrected.
Thanks to Dan Case, Mayo Clinic, USA.
Change 26.102 TYPETASK='J ' occurred in TYPETMNT/TYPESYMT because the
VGETJESN VGETJESN logic when there is no SUBSYS, and the JCTJOBID
May 19, 2008 contains 7 digits did not set TYPETASK='JOB'.
Thanks to Brian Felix, Wachovia Corporation, USA.
Change 26.101 The ending semicolon in the %VMXGVERS(VMXGFOR,xx.yy);
VMXGFOR statement caused a syntax error; that ending semicolon
May 17, 2008 is not only not required, in this instance it was wrong:
In the VMXGFOR macro, the last line calls %VMXGVERS with
a semi-colon at the end. These types of semi colons are
never required, since the macro processor knows to
execute the macro when the tokenization sees the right
parenthesis. In this particular scenario, what happens
is that that trailing semi colon gets returned to the
input stream to the datastep - in the middle of the proc
sort statement, which is why is complains at DATA= being
a Statement that is not valid or out of order.
Thanks to James Hein, Erie Insurance, USA.
Thanks to Chris Weston, SAS ITRM, USA.
Change 26.100 Invalid MEM header record with a missing comma caused
VMACNMON INPUT STATEMENT EXCEEDED RECORD LENGTH error. The header
May 16, 2008 had only 7 fields, causing the error, but the actual MEM
data records are valid, so the handling of the header is
revised to protect for the invalid record.
Thanks to Angelo Pezzella, SAS Italy, ITALY.
Change 26.099 Variable ELAPSTM is now calculated instead of missing.
VMACORAC
May 16, 2008
Thanks to Bret Hoesly, Telephone and Data Systems, USA.
Change 26.098 Support for Informatics STAT user SMF record.
EXIFOCLI Five datasets are created from the user SMF record:
EXIFODB2 IFOLIS INFOLISN INFORMATICS LISTENER
EXIFOEXC IFOEXC INFOEXCP INFORMATICS EXCEPTION
EXIFOFIL IFOFIL INFOFILE INFORMATICS FILE
EXIFOLIS IFODB2 INFODB2 INFORMATICS DB2
IMACINFO IFOCLI INFOCLIE INFORMATICS CLIENT
TESSUSR1 The datetimestamps of the INFO variables are still on the
TYPEINFO GMT clock, because there is no GMT offset in the records.
TYPSINFO The delta between the END (GMT) and SMFTIME (Local) can
VMACINFO not be used, because END is missing in many records. The
VMXGINIT vendor has been requested to add a GMT offset field so
May 21, 2008 the GMT datetimestamps can be converted to local zone.
Thanks to Elizabeth Griesse, Securian Financial Group, USA.
Change 26.097 Divide-by-zero for denominator CPUCPLEN is now protected.
VMACRMFV
May 13, 2008
Thanks to Betty Wong, Bank of America, USA.
Change 26.096 -Variables QW0227FG and QW0227PG were always missing; the
VMAC102 test for QWT02R1L should have been 17 and not 21.
May 13, 2008 -Variables QW0226DB and QW0026OB are now $HEX4. format.
Thanks to Karthik Vinayagam, Morgan Stanley, USA.
====== Changes thru 26.095 were in MXG 26.03 dated May 11, 2008=========
Change 26.095 -ML-41 of ASMTAPEE the MXG Tape Mount Monitor corrects the
ASMTAPEE JOB Name to use MDBGJBNM in the SMF records it writes for
May 10, 2008 WTO SYSLOG events; some records had HSM instead of VTCSS.
The new ASUMTAPE logic in Change 26.083 corrects the JOB
when it is not the same as SYSLJOB, but this corrects the
SMF records created by MXGTMNT monitor.
-The Allocation Recovery Event subtype created by MXGTMNT
was not correct for the (typical, usually automated) WAIT
event. ML-41 corrects the logic for that subtype, so the
observations in TYPEARCV contains job info and the delay
to that job due to insufficient tape devices, which is
what an Allocation Recovery Event describes.
-Some general performance enhancements were also made.
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.094 ERROR: LIBRARY PDB IS NOT IN A VALID FORMAT FOR ACCESS
CONFIGV9 METHOD SASV6SEQ.
May 9, 2008 occurs if OPTIONS SEQENGINE=V6SEQ or TAPENGN=V6SEQ are
in effect; you can use PROC OPTIONS to display the value
of those options. SEQENGINE is defined in CONFIGV9, and
TAPENGN is defined in VMXGINIT; both default to V9SEQ
(or V8SEQ if still using SASV8), but either option can
be changed with a %LET XXXX=VnSEQ, so searching your MXG
tailoring libraries for V6SEQ should locate that text.
The MXGSASV9 JCL procedure puts the MXG CONFIGV9 member
as the last datasets in the //CONFIG DD, so that any SAS
option I specify in CONFIGV9 will override the default
SAS options specified in its .CFG file. However, there
are only these options that are in both the SAS BATW0 and
the current MXG CONFIGV9 members:
Option SAS Value MXG Value
BUFNO 3 2
BLKSIZE 6144
MEMLEAVE 512K 10M
SEQENGINE TAPE V9SEQ
NLSCOMPATMODE NONNLSCOMPATMODE NLSCOMPATMODE
THREADS THREADS NOTHREADS
====== Changes thru 26.093 were in MXG 26.03 dated May 8, 2008=========
Change 26.093 TESTOTHR step failed because DDNAMES CTMUUNIX, CTMZZOS
JCLTESS9 were not added to support CONTROL-M support.
JCLTEST9
JCLTEST8
JCLTESS8
May 9, 2008
Thanks to Bernd Klawa, Stadwerke-Bielefeld, GERMANY.
Change 26.092 Divide By Zero warning in HyperPav SMF 74 when SMF74PSM
VMAC74 was zero in an interval when the device was Varied. The
May 9, 2008 divide is now protected.
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 26.091 Mis-alignment of the CS Server by four bytes caused very
VMAC111 large values in some variables in CTG SMF 111 CS Server
May 7, 2008 records. The VMAC111 in 26.03 did not contain this
Jun 3, 2008 change.
Thanks to Ray Dunn, CIGNA, USA.
Change 26.090 Support for SAS Version V9.2: WARNING could still occur
VMXGSUM if OUTCODE= was specified; Change 26.065 COPYed, rather
May 7, 2008 than MOVEd the LENGTH statement to after the SET, so the
WARNING was still printed. As a result, MXG 26.03 is
now the required MXG Version to eliminate the WARNING in
MXG delivered code.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 26.089 Support for CONTROL-M logs from both Unix and z/OS.
EXCTM065 Separate programs, TYPECTMU for Unix, TYPECTMZ for ZOS
EXCTM100 read the "flat" log files to create new datasets.
EXCTM101 From Unix data, TYPECTMU/TYPSCTMU reads CTMLUNIX to
EXCTM133 create these datasets:
EXCTM134
EXCTM203 DDDDDD DATASET DESCRIPTION
EXCTM206
EXCTM207 CTM065 CTMU5065 CTL-M UNIX MESSAGE ID 5065'
EXCTM208 CTM100 CTMU5100 CTL-M UNIX MESSAGE ID 5100'
EXCTM209 CTM101 CTMU5101 CTL-M UNIX MESSAGE ID 5101'
EXCTM210 CTM133 CTMU5133 CTL-M UNIX MESSAGE ID 5133'
EXCTM211 CTM134 CTMU5134 CTL-M UNIX MESSAGE ID 5134'
EXCTM212 CTMUOT CTMUOTHR CTL-M UNIX OTHER MESSAGE ID'
EXCTM213 From ZOS data, TYPECTMZ/TYPSCTMX reads CTMLZOS to
EXCTM216 create these datasets:
EXCTM217
EXCTM219 DDDDDD DATASET DESCRIPTION
EXCTM281
EXCTM511 CTM203 SEL203I CTL-M ZOS MESSAGE ID SEL203I,220I,221I
EXCTM65A CTM206 SEL206W CTL-M ZOS MESSAGE ID 206W
FORMATS CTM207 SEL207E CTL-M ZOS MESSAGE ID 207E
IMACCTMU CTM208 SEL208I CTL-M ZOS MESSAGE ID 208I
IMACCTMZ CTM209 SEL209I CTL-M ZOS MESSAGE ID 209I
TYPECTMU CTM210 SEL210E CTL-M ZOS MESSAGE ID 210E
TYPECTMZ CTM211 SEL211W CTL-M ZOS MESSAGE ID 211W
TYPSCTMU CTM212 SEL212W CTL-M ZOS MESSAGE ID 212W
TYPSCTMZ CTM213 SEL213W CTL-M ZOS MESSAGE ID 213W
VMACCTMU CTM216 SEL216W CTL-M ZOS MESSAGE ID 216W
VMACCTMZ CTM217 SEL217W CTL-M ZOS MESSAGE ID 217W
VMXGINIT CTM219 SEL219I CTL-M ZOS MESSAGE ID 219I
May 6, 2008 CTM281 SEL281I CTL-M ZOS MESSAGE ID 281I
CTM511 JOB511I CTL-M ZOS MESSAGE ID 511I
CTM65A CTM64AI CTL-M ZOS MESSAGE ID 65AI
CTMZOT CTMZOTHR CTL-M ZOS OTHER MESSAGE IDS
Thanks to John Toohey, IBM, AUSTRALIA.
Change 26.088 Support for sub-subtype '0200' MQ segment creates two new
EX112MQC datasets from SMF 112 records:
EX112MQT DDDDDD DATASET DESCRIPTION
IMAC112 112MQC T112MQCO OMEGAMON CICS MQ DETAIL
VMAC112 112MQT T112MQCT OMEGAMON CICS MQ TOTALS
VMXGINIT There are also '0001' MQ Segments for which I do not yet
May 5, 2008 have a DSECT, to be added when documentation received.
May 9, 2008 May 9: Still no documentation for 0001 record, and the
0200 documentation is wrong; there are 25 4-byte
counters in the segment, but the DSECT from 2007
documented only 8 pair of 4-byte clock/counters.
For now, first 8 counters have the 8 labels from
the 2007 documentation, the rest a counter number.
Thanks to Ray Dunn, CIGNA, USA.
Change 26.087 Flag variable UBFLAG1 in DCOLBKUP was decoded into these
VMACDCOL variables, but they were not kept until now:
May 5, 2008 UBINCAT UBNOENQ UBBWO UBNQN1 UBNQN2
Thanks to Michael Friske, Fidelity Systems, USA.
Change 26.086 Support for AF/Operator SMF Record creates four datasets:
EXAFOPEX DDDDDD MXG MXG
EXAFOPFI DATASET DATASET DATASET
EXAFOPIM SUFFIX NAME LABEL
EXAFOPMA
IMACAFOP AFOPEX AFOPEXEC AFOP EXEC
TYPEAFOP AFOPFI AFOPFILE AFOP FILE
TYPSAFOP AFOPIM AFOPIMMED AFOP IMMED
VMACAFOP AFOPMA AFOPMATCH AFOP MATCH
VMXGINIT
May 5, 2008
Thanks to David Kaplan, DTCC, USA.
Change 26.085 Variable SMFTIME was not in the BY list for TYPE70PR and
WEEKBLD TYPE72MN in WEEKBLD, but was in the BY list for MONTHBLD.
May 5, 2008 The BY list in WEEKBLD was updated. The absence of the
SMFTIME variable caused a NOT SORTED condition when the
clocks were set back one hour on April 6.
Thanks to Peter Krijger, ANZ National, NEW ZEALAND.
Change 26.084 Enhancements to HSM sample reports adds a new REPORT6, a
ANALHSM time-interval summary of MIGRATE/RECALL/BACKUP activity.
May 2, 2008 about every tape mount event.
Additionally, new filtering parameters are created in the
RPTFILT1-RPTFILT6 macros.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.083 Major rewrite of ASUMTAPE corrects errors and supports
ASUMTAPE SPIN logic to create PDB.ASUMTAPE with EVERYTHING
May 2, 2008 possible about every tape mount event.
May 8, 2008
May 10, 2008 THIS IS AN INCOMPATIBLE CHANGE:
You MUST delete your old SPIN.SPINMOUN dataset before you
implement this revised ASUMTAPE algorithm.
The previous ASUMTAPE logic always correctly assembled
"complete" tape mount events, and most "incomplete"
mounts but there were cases with only a single SYSLOG
event (notable, from our friends HSM and DMS that do
their own unique thing!) in which the output was not
always correct or complete.
In addition, as documented, ASUMTAPE never implemented
the full "SPIN" logic to hold incomplete events for the
next execution of ASUMTAPE.
The TYPESYMT processing of SYSLOG records was reinvented,
using the SYSTEM JOB JESNR DEVNR sequence, rather than
the insufficient DEVNR DESCENDING EVENTIME sequence that
was incapable of full protection for these end cases.
-May 10: Final logic errors due to LASTDEVN being kept in
SPINSYSL cleaned up match up of "full" vs "SPLIT SPIN" so
observation counts again matched before and after tests.
-The unique DSNAMEs in the input TYPESYMT and TYPETMNT
were compared with the output DSNAMEs in PDB.ASUMTAPE and
many were blank, and some were wrong, as SYSLDSN is only
populated in IEC233A,IEC705I, and IEC501A/IEC501E SYSLOG
messages; the blank values in the other records overlaid
DSNAME. Now, all observations that had DSNAME in TMNT or
SYSLOG have non-blank DSNAME. Some events can never have
a DSNAME (e.g., HSM only-234E KEEP); variable MNTHAVE
identifies which SYSLOG records were found for this mount
event, and can be used to identify those cases where the
DSNAME is always blank.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Pat Jones, DST, USA.
Change 26.082 The old IEFU84 sample SMF exit failed with z/OS 1.7 and
IEFU84 z/OS 1.9; the addition of $CADDR after $HCCT in the ASM
May 1, 2008 code eliminated the ASMA044E UNDEFINED SYMBOL messages
for symbols C@XMXSRB, and CADDR, thanks to excellent ASM
sleuthing by Dean.
Thanks to Dean Gambill, Lowe's Companies, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 26.081 -The JCLDAYDS had a //PDB DD, but it is never used in the
DAILYDSR DAILYDSN or DAILYDSR programs, so it was removed from
JCLDAYDS that JCL example.
Apr 30, 2008 -The DAILYDSR example for using DFSMS/RMM instead of TMS
did not create the DCOLCLUS dataset from DCOLLECT data.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 26.080 MXG 26.01 wrongly changed QPACAAFG INPUT to $CHAR2. as I
FORMATS thought it contained hex text. The $EBCDIC2 input is now
VMACDB2 restored, a hex zero value is converted to blanks, and
Apr 29, 2008 its $MGDB2PK format enhanced to decode that blank value:
VALUE $MGDB2PK
' '='BLANK:NOT DEFINED'
'01'='01:STORED PROCEDURE'
'02'='02:USER DEFINED FUNCTION'
'03'='03:TRIGGER EXECUTING'
;
Thanks to Glenn Bowman, Wakefern, USA.
Change 26.079 Variable IFAHONOR could be blank when it should have
VMAC7072 been 'Y'; typo in logic was corrected.
Apr 25, 2008
Thanks to William Wailun Wong, HSBC, HONG KONG
Change 26.078 MXG 26.02 VMXGSUM caused VARIABLE NOT FOUND if variables
VMXGSUM that do not exist in the input dataset were named in one
Apr 24, 2008 of the output lists (eg., in SUM= ). This support was
accidentally deleted. This would happen if you used an
unmodified MXG ASUMxxxx member that listed all variables
to be summed, but you had dropped variables from the
input dataset. (Think ASUMDB2A which sums all DB2ACCT
variables).
Thanks to Jim Kovarik, Aegon, USA.
Change 26.077 MXG printed a WARNING: NEGATIVE CPUUNITS when a type 30
VMAC30 record had IFAUNITS greater than CPUUNITS, citing APAR
Apr 29, 2008 OA24836 as the IBM correction. But even with that APAR,
imprecision in zAAP and CP Service Units caused small
negative deltas equivalent to a few hundredths's of a CPU
second, as confirmed by IBM Support, who pointed to new
SMF updates documenting these service unit issues, and
recommended the CPUUNITS and IFAUNITS be recalculated
based on the proportions of the CPUTCBTM and CPUIFATM,
when the subtraction returned a negative value. In so
doing, I discovered that all test cases with negative
deltas actually had CPUTCBTM=0, i.e., they were tasks
that only used zAAPs, so the resultant CPUUNITS=0 after
recalculation is correct and not an approximation!
But, if the delta is greater than one CPU second, a
revised warning is printed with the before and after
service unit and cpu time values.
Thanks to Janet Harris, Navistar, USA.
Thanks to Roger Rush, Navistar, USA.
Change 26.076 This JCL example had an extra space on the // EXEC
JCLMQMCI statement and the symbolic WORKNUM instead of WORKVOL.
Apr 23, 2008
Thanks to Gary Green, Dow Jones, USA.
====== Changes thru 26.075 were in MXG 26.02 dated Apr 22, 2008=========
Change 26.075 -MXG logic incorrectly handled back-to-back TYPE21 from
ASUMTAPE different systems in the interleave with TYPETMNT; this
Apr 22, 2008 ultimately caused variable SYSTEM in PDB.ASUMTAPE to have
the wrong system's name for these mount events.
Thanks to Paul Naddeo, FiServ, USA.
Change 26.074 MXG 25.07-MXG 26.01 only. Fewer obs created in TYPE78CU,
VMAC78 even with Change 26.023, which only partially solved the
Apr 22, 2008 MXG error. The test for 58 should have been 56.
Thanks to Shantha Hallett, Capgemini, WALES.
Change 26.073 The SORTEDBY= attribute of DB2 datasets that are created
VMACDB2 by a DATA step (instead of a PROC SORT, which sets the
Apr 20, 2008 SORTEDBY list of BY variables automatically) is added to
DATA steps for DB2STATS, DB2GBPST, and DB2STATB, and for
DB2STAT0 and DB2STAT1, but they are already in DB2STATS.
SAS will bypass a subsequent PROC SORT of a dataset when
its SORTEDBY list matched the requested sort's BY list.
Change 26.072 Example ANALTCP reports adds API (Socket) data report,
ANALTCP corrects the date selection code (it didn't work when
Apr 20, 2008 both BEGTIME and ENDTIME were requested), and the SYSTEM
May 6, 2008 selection is revised for a list of SYSTEMs and to allow
a prefix. Option 'ALL' was added for the DATA selection.
Additional enhancements made on May 6.
Thanks to Steve Clark, DHL IT Services Americas, USA.
Change 26.071 Support for z/OS 10.0 (INCOMPATIBLE due to MXG coding):
VMAC1415 -New triplet in TYPE72GO - INCOMPATIBLE due to MXG test of
VMAC18 NRTRIPLT=7 (protected previous short-record IBM error)
VMAC19 causes zero observations in TYPE72GO without this change.
VMAC30 The new Resource Delay segment is not yet coded, awaiting
VMAC42 test data records; R723RDNX, R723RDNN index/number added.
VMAC7072 -TYPE72GO new CPU times (subset in existing CPUTCBTM):
VMAC71 CPUCRPTM='CPU TIME*AT CHRONIC*CONTENTION' (R723CPDP)
VMAC74 CPUPRMTM='CPU TIME*AT PROMOTED*DISPATCH*PRTY'(R723TPDP)
VMAC78 R723CPDP in TYPE72GO.
VMXGINIT -TYPE74. New variable:
Apr 18, 2008 SMF74CAP - AVAILABLE*VOLUME*CAPACITY*IN CYLINDERS.
Jul 21, 2008 -TYPE1415. New variables:
Aug 22, 2008 SMF14EAV='EAV BAM*DETECTED*EXCP OR*XDAP?'
DEB2XUPF='BSAM*PGFIX*OPTION*SPECIFIED?'
EADSCBOK='DCBEADSCBOK*FLAG*OK*ON?'
-TYPE1718. New variable:
SMF18CON='CONTINUATION*RECORD*INDICATOR*MULT-VOL'
-TYPE19. New variables (actually added in z/OS 1.9):
SMF19CYM='VOLUME*HAS*CYL-MANAGED*SPACE?'
SMF19TRK='TOTAL*TRACKS ON*VOLUME'
SMF19TRM=*TOTAL*TRACKS IN*TRACK-MANAGED*SPACE'
SMF19VLI='VOLUME*SIZE*INFORMATION'
-TYPE30. New variable added (by z/OS 1.9):
SMF30SNF='ZIIP NORMALIZATION FACTOR'
-TYPE42D2. New variable added:
SMF42GBQ='LOCK*STRUCTURE*NAME'
-TYPE4222. New subtype 22 creates new TYPE4222 datset
for DFSMS Audit Record:
JOB ='JOB NAME'
RACFUSER='RACF*USER*ID'
READTIME='READTIME'
S42CNABL='CONTROL*RECORD*ENABLE*FLAG'
S42CSYNC='CATSYNCH*DATETIME*STAMP'
S42GMTOF='LOCAL TIME/DATE OFFSE'
S42JNEXT='NEXT*JOURNAL*RECORD*NUMBER'
S42JRECN='JOURNAL*RECORD*NUMBER'
S42MACTY='ACTIVITY*TYPE'
S42MCUPD='VSI*WHEN*MCUPDACT*SET ON'
S42MFG1 ='SMF42MFG1*FLAG*ONE'
S42MJRN ='JOURNAL*RECORD*AVAIL?'
S42MLIS ='LAST*IN*SET?'
S42VRLTK='VSREL*LAST*CHANGE*TOKEN'
S42VRSCN='CURRENT*VRS*CHANGE*COUNTER'
S42VRSUN='LAST*HSKP*VRS*CHANGE*COUNTER'
S42VSICN='VSI*CONTROL*COUNT'
S42VTSFL='VIRTUAL*TAPE*SERVER*FLAG'
-TYPE4223. New subtype 23 creates new TYPE4223 datset
for DFSMS Security Record:
DSNAME ='DATA*SET*NAME'
DSSNO ='DATASET*SEQUENCE*NUMBER'
JOB ='JOB NAME'
LOCLINFO='LOCAL*INFO'
RACFGRUP='RACF*GROUP'
RACFUSER='RACF*USER*ID'
READTIME='READ*TIME'
S42DEVT ='DEVICE*TYPE'
S42GMTOF='LOCAL*TIME*OFFSET'
S42NACTY='ACTIVITY*TYPE'
S42NSTP ='SECURITY*TYPE'
S42NVER ='RECORD*VERSION*IDENTIFIER'
VOLSEQ ='VOLUME*SEQUENCE*NUMBER'
VOLSER ='VOLUME*SERIAL*NUMBER'
Note: Change 26.187 supports APAR OA25205 which adds
subtype 24 and 25 and adds data to subtypes 20 and 21.
-TYPE71. New variables added:
SMF71CFA='AVG*64BIT*COMMON MEM*OBJS*FIXED RSTORE'
SMF71CFM='MIN*64BIT*COMMON MEM*OBJS*FIXED RSTORE'
SMF71CFX='MAX*64BIT*COMMON MEM*OBJS*FIXED RSTORE'
SMF71COA='AVG*64BIT*COMMON MEM*OBJS*ALLOCATED'
SMF71COM='MIN*64BIT*COMMON MEM*OBJS*ALLOCATED'
SMF71COX='MAX*64BIT*COMMON MEM*OBJS*ALLOCATED'
SMF71CRA='AVG*64BIT*COMMON MEM*OBJS*BACKED RSTORE'
SMF71CRM='MIN*64BIT*COMMON MEM*OBJS*BACKED RSTORE'
SMF71CRX='MAX*64BIT*COMMON MEM*OBJS*BACKED RSTORE'
SMF71CSA='AVG*64BIT*COMMON MEM*AUXSTOR*SLOTS'
SMF71CSM='MIN*64BIT*COMMON MEM*AUXSTOR*SLOTS'
SMF71CSX='MAX*64BIT*COMMON MEM*AUXSTOR*SLOTS'
SMF71SOA='AVG*SHARED*MEM OBJ*ALLOCATED'
SMF71SOM='MIN*SHARED*MEM OBJ*ALLOCATED'
SMF71SOX='MAX*SHARED*MEM OBJ*ALLOCATED'
SMF71SRA='AVG*HI VERT*SHARED*FRAMES BACKED*RSTORE'
SMF71SRM='MIN*HI VERT*SHARED*FRAMES BACKED*RSTORE'
SMF71SRX='MAX*HI VERT*SHARED*FRAMES BACKED*RSTORE'
-TYPE78PA (Private Area for jobs) new variables added:
COBYHWM ='HWM*BYTES 64BIT COMMON 2GB'
COBYMAX ='MAX BYTES*64BIT COMMON*ABOVE 2GB'
COBYMIN ='MIN BYTES*64BIT COMMON*ABOVE 2GB'
COBYNTME='TIME STAMP*OF MIN*64BIT COMMON'
COBYTOTL='TOTAL*SAMPLES*64BIT COMMON 2GB'
COBYXTME='TIME STAMP*OF MAX*64BIT COMMON'
COMOHWM ='HWM*BYTES 64BIT*COMMON'
COMOMAX ='MAX BYTES*64BIT*COMMON'
COMOMIN ='MIN BYTES*64BIT*COMMON'
COMONTME='TIME STAMP*OF MIN*64BIT COMMON'
COMOTOTL='TOTAL*SAMPLES*64BIT*COMMON'
COMOXTME='TIME STAMP*OF MAX*64BIT COMMON'
LGMOHWM ='HWM*BYTES LARGE*MEMOBJ'
LGMOMAX ='MAX BYTES*LARGE*MEMOBJ'
LGMOMIN ='MIN BYTES*LARGE*MEMOBJ'
LGMONTME='TIME STAMP*OF MIN*LARGE*MEMOBJ'
LGMOTOTL='TOTAL*SAMPLES*LARGE*MEMOBJ'
LGMOXTME='TIME STAMP*OF MAX*LARGE*MEMOBJ'
R782MEML='ADDRESS*SPACE*MEMLIMIT*MB'
Change 26.070 Support for SMF 102 IFCID 217 Storage Pool Stats changes.
VMAC102 -Dataset T102S217 new variables (GM existed, relabeled):
Apr 16, 2008 QW0217GA='TOTAL*GETMAINED*STORAGE*ABOVE*THE BAR'
QW0217GM='TOTAL*GETMAINED*STORAGE*BELOW*THE BAR'
QW0217HF='FLAG*BITS*IN THE*HEADER'
QW021764='THE*ABOVE THE*BAR DATA*IS INCOMPLETE'
-The original IFICD=217 record was in error, with triplet
3's data in triplet 2, which MXG protected by hardcoded
tests for the segment length to figure out where is that
data? IBM has increased the 02 segment with +24 blank
bytes, but that caused zero observations in T102U217.
The new 152 Length is now supported, even though no new
data was decoded!
Thanks to Matt Clarke, Charles Schwab & Co., Inc, USA.
Change 26.069 Change 25.109 stored the new (0-65535) UIC values in the
VMAC71 old a (0-2054) variables HIUICAV/HIUICMN/HIUICMX, but
Apr 16, 2008 only HIUICAV=SMF71UAC matched the RMF Paging Report
HIGH UIC (AVG). HIUICMN (MIN) was UAM instead of ULC,
HIUICMX (MAX) was UAX when it should have been UHC.
Thanks to Ray Dunn, CIGNA, USA.
Change 26.068 This MXG utility to "PRINT/CONTENTS/MEANS" all datasets
VMXGPRAL in a SAS Data Library failed with NOCONT=PRINT because
Apr 16, 2008 while PROC CONTENTS NOPRINT is valid, its counterpart
syntax PROC CONTENTS PRINT is NOT valid, and MXG had used
macro variable &NOCONT to set CONTENT's PRINT/NOPRINT.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Change 26.067 MXG assumed NTHOSTTN in ID=119 ST=21 to be 8-bytes, but
VMAC119 this field at the end of the record is shortened to the
Apr 14, 2008 host name length, and I now see that LEN11903=6, so it is
now used in INPUT NTHOSTTN $VARYING8. LEN11903 @; code.
ERROR: INPUT STATEMENT EXCEEDED RECORD LENGTH occurred.
Thanks to Richard J. Schwartz, State Street Corporation, USA.
Thanks to Kathleen M. Hall, State Street Corporation, USA.
Change 26.066 This MXG SAS utility gets z/OS PDS directory block counts
UTILLPDS one dataset at a time. Added by Change 25.136 with typos
Apr 14, 2008 in comments, its documentation and code matches examples.
The one created dataset is now named UTILLPDS.
Thanks to Jeffrey A. Harder, Indiana Farm Bureau Insurance, USA.
Change 26.065 Support for SAS Version 9.2: Revised August 20.
ANALCNCR The WARNING code issues originally discussed below are
VMXGSUM corrected by SAS Hot Fix F9BA07. See Change 26.189 and
ANALDOS MXG Newsletter FIFTY-TWO, SAS Technical Note 7.
ASUMDOS
ASUMHSM Except for RETURN/CONDITION CODE 4 for SAS V9.2 WARNINGs,
EXTYTPMX (which ONLY impacts z/OS job processing, and ONLY if JCL
TYPEZARA or a scheduling package checks step condition codes):
UTILXRF1
VMACVMXA MXG Software runs without error with SAS Version 9.2.
VMXGUOW and
VMXGINIT MXG Software Version 26.03 eliminates the new WARNING.
Apr 20, 2008 (or Hot Fix F9BA07).
Apr 22, 2008
Aug 20, 2008 SAS V9.2 created a new WARNING message and sets CC=4 for
changes in variable LENGTHs, but the WARNINGs in MXG code
were NOT in error, the length changes were intended, the
output dataset was valid, so these warnings harmless:
"WARNING: Multiple lengths specified for variable XXXXXX"
EXCEPT FOR: a non-zero condition code/return code can
make your z/OS job stream that test condition codes to
ABEND.
MXG has enabled the new-in-SAS-V9.2 VARLENCHK option to
completely eliminate the existence of this WARNING.
(Removed by Change 26.189, Aug 20, 2008).
These warnings (all for numeric variables) primarily
occurred inside VMXGSUM in two different cases:
a. Inside VMXGSUM where PROC MEANS is used to create an
output (summary) dataset. The original MEANS created
8-byte variables with no option to change them, so MXG
shortened numeric variable's stored lengths in a DATA
step after the PROC MEANS (to save disk space).
Now, SAS V9.2 detects that (intentional) decrease in
variable length, and prints the above WARNING.
But ONLY if the LENGTH statement precedes the SET!
If the LENGTH statement is AFTER the SET statement,
the warning is NOT printed, but either before or
after, the numeric variable's LENGTH is changed!
These LENGTH statements were located before the
SET statement, because that is the only location
where the length of a character variable can be
changed; character variable's length are set by
the first assignment or attribute statement.
Since the before-the-SET-location also worked for
numeric variable, all LENGTH change statements
were located there.
But all numeric variables are 8-bytes in memory
and the LENGTH (from the last LENGTH statement)
is only used when the observation is written, and
so relocating the numeric LENGTH changes to be
after the SET statement eliminates the WARNING
and still changes the variable's LENGTH.
b. A JOIN of multiple datasets (SET MON.JOBS TUE.JOBS...)
where a variable has different lengths in different
datasets.
But only if the variable length in the first dataset
is shorter than other lengths. There is NO WARNING
if the largest length is in that first dataset!
This also occurred inside VMXGSUM, when multiple input
datasets are combined in a SET/MERGE/UPDATE/etc., like
TRENDing, where TREND has shortened LENGTHs but the
"NEWTREND" internally had fixed, pre-KEEPLEN LENGTHs.
MXG 26.03 added the KEEPLEN option to PROC MEANS to
eliminate these inside-VMXGSUM-cases.
HOWEVER: EVEN WITH MXG 26.03 AND SAS V9.2 THE WARNING CAN
OCCUR NOW:
a. If you have tailoring members in "USERID.SOURCLIB"
from old MXG versions, that need the same code
revisions to eliminate.
b. In user-written SAS programs, this could actually be a
valid warning that a variable was truncated.
OR AT ANY TIME IN THE FUTURE THE WARNING CAN STILL OCCUR:
c. When an MXG Version that changed variable LENGTHs is
installed, subsequent WEEKLY or MONTHLY jobs create
the WARNING because some PDB's have the old length and
some have the new length, when those multiple datasets
are joined. Previous to V9.2, length were changed
with no WARNING nor CC. Between MXG 24.24 and 25.25
1206 variable's lengths were changed.
Note: installing a new MXG version on the first day of
the week is always safest, i.e., make Tuesday morning
BUILPDB with the new MXG Version, so MON-SUN datasets
are all the same; this will eliminate WEEKLY exposure,
but next MONTHLY is still exposed.
THEREFORE: The only way to prevent job failure due to
the WARNING is that SAS Institute may provide a new
option for SAS V9.2 on z/OS to turn off the setting of
the condition code for this WARNING. When this happens,
MXG will enable that new OPTION by default so that the
length of variables can be changed by MXG without this
failure.
-Discovery of how SAS sets stored LENGTH of a variable.
A DATA step uses the last LENGTH statement to set length
of numeric variables, if there are multiple statements.
An existing numeric's variable's length can be changed in
with a LENGTH statement; that statement can be put BEFORE
or AFTER the SET statement, and can request the length be
be SMALLER or LARGER in size. A 7-byte numeric variable
was increased/decreased before/after with these results:
LENGTH NEW RESULT OUTPUT WARNING
STATEMENT WANTED OUTPUT REQUESTED MESSAGE
LOCATION LENGTH LENGTH LENGTH PRINTED
NUMERIC VARIABLES:
BEFORE SET SMALLER 6 YES,TRUNCATED YES-1
AFTER SET SMALLER 6 YES,TRUNCATED NO
BEFORE SET LARGER 8 YES NO
AFTER SET LARGER 8 YES NO
CHARACTER VARIABLES:
BEFORE SET SMALLER 6 YES,TRUNCATED YES-1
AFTER SET SMALLER 7 NOT CHANGED YES-2
BEFORE SET LARGER 8 YES,INCREASED NO
AFTER SET LARGER 7 NOT CHANGES YES-2
The output lengths are identical between V9.2 and V9.1.3,
so this is not new behavior. But further tests with both
NUMERIC and CHARACTER variables discovered that:
NUMERIC: BEFORE SET SMALLER caused WARNING message and
the length was truncated (as requested).
NUMERIC: AFTER SET SMALLER does NOT print WARNING, but
the variable was truncated (as requested).
NUMERIC: BEFORE or AFTER SET LARGER worked, no WARNING.
CHAR: BEFORE SET SMALLER caused WARNING message but
the length was truncated (as requested).
CHAR: AFTER SET SMALLER does NOT change the LENGTH,
and it prints a different WARNING:
"LENGTH OF CHAR VAR C HAS ALREADY BEEN SET."
i.e., it does not work, yet it still WARNs you.
Interestingly, this WARNING, if length is to be
shortened, does NOT set a condition code, with
either V9.2 or with SAS 9.1.3.
CHAR: AFTER SET LARGER also does NOT change LENGTH,
and it prints that second WARNING,
"LENGTH OF CHAR VAR C HAS ALREADY BEEN SET.",
also not working and yet WARNING you.
Very interesting, this WARNING, if length is to
be increased, DOES set a condition code, with
both SAS 9.1.3 or SAS 9.2.
CHAR: BEFORE SET LARGER worked, no WARNING.
For NUMERICs, the requested LENGTH is always created, so
moving the LENGTH statement to be AFTER the SET statement
will eliminate the V9.2 WARNINGs and create same output.
For CHARs, only BEFORE changes LENGTHs, but BEFORE SMALL
prints the new-in-V9.2 WARNING that sets Condition Code:
There is NO way to shorten a CHARACTER VARIABLE's LENGTH
with V9.2 on z/OS without that warning and setting CC=4.
Neither AFTER SMALL nor AFTER LARGE change LENGTH, and
both print the WARNING: CHAR VAR ALREADY SET, which may
or may not set condition code, but it's a moot point,
since they don't change the variable lengths.
Details of the log messages and condition codes with
test with SAS V9.1.3 and SAS V9.2 on z/OS and Windows:
NUM CHR
1 CC DATA BEFORE76SMALLER; NEW LEN: YES,YES
PC 9.1 NO WARNING
PC 9.2 MULTIPLE LENGTHS SPECIFIED FOR VAR N,C
ZOS 9.1 00 NO WARNING
ZOS 9.2 04 MULTIPLE LENGTHS SPECIFIED FOR VAR N,C
2 DATA AFTER76SMALLER; NEW LEN: YES,NO
PC 9.1 LENGTH OF CHAR VAR C ALREADY BEEN SET.
PC 9.2 LENGTH OF CHAR VAR C ALREADY BEEN SET.
ZOS 9.1 00 LENGTH OF CHAR VAR C ALREADY BEEN SET.
ZOS 9.2 00 LENGTH OF CHAR VAR C ALREADY BEEN SET.
3 DATA BEFORE78LARGER; NEW LEN: YES,YES
PC 9.1 NO WARNING
PC 9.2 NO WARNING
ZOS 9.1 00 NO WARNING
ZOS 9.2 00 NO WARNING
4 DATA AFTER78LARGER; NEW LEN: YES,NO
PC 9.1 LENGTH OF CHAR VAR C ALREADY BEEN SET.
PC 9.2 LENGTH OF CHAR VAR C ALREADY BEEN SET.
ZOS 9.1 04 LENGTH OF CHAR VAR C ALREADY BEEN SET.
ZOS 9.2 04 LENGTH OF CHAR VAR C ALREADY BEEN SET.
VMXGSUM is extensively used in MXG summarization programs
(ASUMxxxx,TRNDxxxx,RMFINTRV,CICINTRV) and in many ANALxxx
report examples. If you have local reports that invoke
VMXGSUM/ANALCNCR, that have LENGTH statements in INCODE=
or OUTCODE= parms, you could generate the WARNINGS. So
TEST your REPORTS!!
This change also eliminated the LNSUMOUT macro variable
in Change 25.248 that was thought needed to eliminate the
warnings. It only worked in simple cases and ended up
with the output variable lengths different than input.
Changes made to MXG members to eliminate this WARNING:
-VMXGSUM was revised internally, adding the KEEPLEN option
in PROC MEANS, to propagate the input length to output.
That option was added back in SAS Version 7, but only now
is it needed to eliminate the WARNINGs inside VMXGSUM in
the MXGSUM1/MXGSUM2/MXGSUM3 temporary datasets.
-VMXGSUM LENGTH statements for NUMERIC variables was moved
after SET statement to eliminate those WARNING messages.
-Other MXG programs listed had PROC MEANS/PROC SUMMARY and
warning messages that are similarly eliminated now.
-ANALCNCR. LENGTH &DEFAULT added to CONCURR2 step.
Specific MXG summary programs that required modifications:
-VMXGUOW Variable TRANNAME was incorrectly set to $8 in
several LENGTH statements, but CICS TRANNAME is
only four bytes long. The output PDB.ASUMUOW
dataset did have TRANNAME $4, but the $8 caused
WARNING messages.
-ASUMDOS LENGTH DEFAULT=&MXGLEN; needed in INCODE= for
variable DATE.
-TYPEZARA Invoked PROC MEANS, rather than VMXGSUM, so the
INHERIT option and &KEEPLEN were added.
Fixed so QA would run; dunno if product exists!
-VMACVMXA PROC MEANS were updated with /INHERIT &KEEPLEN,
and LENGTH statements moved to after SETs.
-UTILXRF1 SAS V9.2 PROC CONTENTS changed the length of
variables LABEL and MEMLABEL to $256, and
MEMNAME/DATASET from $8 to $32, causing this
MXG QA utility to generate WARNINGs due to hard
coded LENGTH statements. The PROC CONTENTS
output variable's length change also causes the
DOCVER step of QA job to print the WARNING,
when creating DOCVERnn by comparing OLD and NEW
version's QA data libraries that have intended
length changes. This is unavoidable, but not
an error, and only occurs in my QA job.
-ANALDOS Last updated 18 years ago. PROC MEANS and PROC
SUMMARY (same code as MEANS) needed INHERIT and
KEEPLEN options added.
-ASUMHSM Variable REQUEST needed LENGTH 8 when created
in a DATA step; it is a datetimestamp.
-EXTYTPMX The 99 optional TPMX User Character variables
are each INPUT with a $VARYING50 statement, but
all are then listed in a default DROP statement
(that you would tailor in this exit member if
you wanted one or more to be kept). But there
was a LENGTH TPMUC1-TPMUC99 $1.; statement, to
minimize disk space if all variables were kept
that generated the WARNING message. That LENGTH
statement is now inside comments.
The following note was superceded by Change 26.189:
-VMXGINIT Enables OPTION VARLENCHK=NOWARN; for SAS V9.2.
This requires a Hot Fix for Phase I Foundation
but the new option will be in Phase II V9.2
The OPTION VARLENCHK was added to Phase I by Hot Fix.
If that OPTION VARLENCHK does not yet exist, on your
SAS V9.2 platform, this note will be printed
NOTE: ARGUMENT 1 TO FUNCTION GETOPTION INVALID,
on the SAS log, but it has no impact, except to tell
you to install that Hot Fix to eliminate that note,
but more importantly to suppress the warning.
Thanks to MP Welch, SPRINT, USA.
Change 26.064 Implementation of Rich Olcott's "The Actuals Map" and the
ANALACTM "WLM Service Goal Summary", as described in his paper,
Apr 12, 2008 "Dimensions of Service - Exploring WLM's Solution Space".
The Actuals Map uses SAS/GRAPH to display a daily graph
of interval service units consumed by each Service Class,
color modulated by quality of service delivered (based on
PERFINDX value: Green LT 0.6, Blue 0.6-1.4, Red GT 1.4).
with the graph arranged top to bottom by the Importance
of that Service Class. The PowerPoint paper is available
at http://regions.cmg.org/regions/mcmg/
Rich%20Olcott%20-%20Dimensions%20of%20Service%20
-%20MCMG%20.ppt
The MXG implementation provides additional features and
creates html output for these reports, and will create a
report for each system, or report each sysplex, etc.
Reese is cited simply because he asked for the report!
Thanks to Rich Olcott, (now) IBM Global Services, USA.
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to Reese Bailey, Progress Energy, USA.
Change 26.063 Only DB2ACCT observations with QWACATYP=4, CICS Attach,
VMXGUOW will be considered for merge with CICSTRAN, and only if
Apr 12, 2008 the UOWTIME is non-missing in the DB2ACCT dataset. Some
DB2ACCT observations that exceeded SPINCNT, because they
had a missing UOWTIME value, were inadvertently output.
Now, they are not output, but are counted and a note is
printed on the log with the number of these DB2ACCT obs
with QWACATYP=4 and UOWTIME=. were discarded by ASUMUOW.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 26.062 In some cases (from %UTILBLDP), where there were a lot of
VMXGPARS special characters like ( ) ; ' % in the text, the parser
Apr 12, 2008 got sick on macro quoting function idiosyncrasies. Using
the %SUPERQ macro function appears to solve the parsing.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA
Change 26.061 Internal dataset TYPE70SP, added for the "SPLIT70" logic,
VMAC7072 was explicitly named and was not in _N7072, so it could
VMXGINIT not be "_NULL_"ed. MACRO _WTY70SP &WTY70SP..TYPE70SP %
Apr 12, 2008 is now defined and VMXGINIT updated and _N7072 updated.
Since it uses _VTY70 and _KTY70 definitions for content
tailoring, no other _xTY70SP macros are not defined.
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.060 COSMETIC SAS V9.2 differences with SAS V9.1.3.
ANALRMFR SAS V9.2 changed some text in SASLOG NOTES, but none have
Apr 12, 2008 any impact on MXG execution. They do make comparison of
SAS logs of MXG QA runs from both versions a bit messy,
but these were noted in validating MXG execution .
-The FULLSTATS statistics at the end of each PROC/DATA
step is enhanced with new resource information:
NOTE: The SAS System used:
real time 28:46.70
user cpu time 3:26.99
system cpu time 3:55.99
Memory 89953k
OS Memory 101216k
Timestamp 4/11/2008 6:39:31 PM
The FULLSTIMER Statistics documentation states:
Real Time - amount of time spent to process the SAS
job, also referred to as elapsed time.
User CPU - CPU time spent to execute SAS code
System CPU - CPU time spent to perform operating
system tasks (system overhead tasks)
that support the execution of SAS code.
Memory - the amount of memory required to run a
step.
OS Memory - the maximum amount of memory that a
step requested from the System.
Timestamp - the end date/time of the step. Useful
in diagnosis of SAS run time issues,
and to correlate log events to time of
day. Better than the OPTIONS DTRESET;
that prints time to the minute at each
new page, but I would have preferred to
also see time to the milliseconds; a
simple data step with no variables runs
in about 5 milliseconds.
-A new LIBREF, MAPS, exists with SAS V9.2 on Windows; this
caused WORK.LIBNAMES and WORK.MXGENG datasets to have
observation count differences when %VGETENG was used to
get the engine type of a libname and saw the new libname.
This has zero actual other impact.
-The PROC CONTENTS output under SAS V9.1.3 printed only 42
lines per page, while SAS V9.2 prints 54 lines when both
had the OPTIONS PS=54 default. This caused the location
"printed pages 1-105" with 9.1.3 to be "pages 1-79" with
SAS V9.2, which, of course, then impacted the location in
all subsequent "printed pages n-m" log messages.
-Inconsistencies in character text in these NOTEs:
NOTE: The DATA step printed page 269.
NOTE: The DATASTEP printed page 325.
NOTE: No observations in input data set.
NOTE: No observations in input dataset.
-The SPF compare showed four cases of '0c'x before MXGNOTE
with SAS V9.2, and five different instances with V9.1.3.
The MXGNOTE text is a %PUT MXGNOTE statement, so having
any difference was quite confusing, until I realized that
the '0c'x in column 1 of the SAS log file when written to
a disk file under Windows, is the top-of-page control,
and these MXGNOTEs with '0c'x just happen to start a new
page, and with the PROC CONTENTS changing pages, there
were different lines at the top of each page, but nothing
more nefarious.
-COMPRESSION DISABLED for RDHITSP RDHITSNP datasets in 9.2
that was compressed in 9.1 suggest a minor change in the
internal when-to-compress algorithm.
-ANALRMFR: Harmless note new in V9.2 printed on SAS log:
"NOTE: The array IN has the same name as a SAS-supplied
or user-defined function. Parentheses following
this name are treated as array references and not
function references."
The array name was changed to ININ to eliminate printing
of this new harmless (and useless?) NOTE on the SAS log.
I also made all FILE statements parameters consistent,
left to right, for ease in reading, before I had realized
that '0c'x issue was NOT due to differences in the FILE
parameters in the ANALRMFR program itself!
-An additional NOTE: WORK.CICSUOW HAS 0 OBSERVATIONS when
datasets for ASUMUOW all has zero observations, possibly
due to use of VIEWs.
Change 26.059 Variable SRDMXUSE was input $1 Format $HEX2., but it is
VMACSRDF the numeric Max Percent Cache. New variable SRDMXUSP is
Apr 10, 2008 created to avoid an ABEND due to CHAR and NUM conflict if
May 5, 2008 the name were reused and you combined differently built
PDB datasets. The old variable is left unchanged, and
you can create the new numeric variable in old PDB's with
SRDMXUSP=INPUT(SRDMXUSE,&PIB.1.)/256;
May 5: Flags 3 and 4 decoded into individual variables.
Change 26.058 IMF dataset TYPECIMS variable INPUTCLS was increased to
VMACCIMS 2 bytes, but the FORMAT INPUTCLS $HEX2. statement seen
Apr 10, 2008 before INPUT defined the variable's length to one byte.
The $HEX2. was changed to $HEX4. But the INPUT was also
now incorrect, as the two-byte value starts @76, instead
of @77 for the one-byte value. An input class of ' T'
that would have been stored as INPUTCLS='T' in one byte
will now be stored as INPUTCLS=' T' in two bytes, so you
need to examine any tests for INPUTCLS in your reporting
programs.
Thanks to Geert De Batselier, KBC, BELGIUM.
Change 26.057 Change 25.090 added QW0225BB to the old T102S225 dataset,
VMACDB2 but it falsely said it was also added to DB2STAT4. Now,
Apr 8, 2008 it is kept in DB2STAT4.
Thanks to Kerry Sommers, Deere & Co., USA.
Change 26.056 Replaced by Change 26.264.
Change 26.055 SAS V8 only: ERROR: REQVECTOR DATAREP IN DROP, KEEP ....
UTILCONT because those two variables only exist with SAS V9. As
Apr 4, 2008 they were only referenced in a DROP statement for a temp
dataset, they are removed with no other impact.
Thanks to George Ellard, Fedex, USA.
Change 26.054 Cosmetic. Format MGBYTES added to the byte-containing
VMAC16 variables (BYTESORT ICEMOSIZ ICEFILSZ), and the format
Apr 4, 2008 MGKILO is added to these count variables, which can have
large values, so they will "print pretty".
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.053 The ASIxxxxx percentages calculated by MXG in ZRBASI use
VMACRMFV ASISMPCT='NUMBER OF*VALID*SAMPLES*THIS ASID', but RMF III
Apr 2, 2008 reports use SSHSMPNR='NUMBER*OF VALID*MINTIME*SAMPLES'.
So if there are 2 samples for the job in question, in a
100 sample MINTIME interval, and one delay sample, MXG
calculated 1/2 = 50% while RMF reports 1/100 = 1%.
I could create 50 additional ASIxxxxx variables with the
RMF III percentage values, but I personally think the way
MXG calculates is more useful, since it reflects delay or
using only when the job is actually active. However, if
you wish to match the IBM RMF III display, you can use
IBMPCT=MXGPCT*ASISMPCT/SSHSMPNR;
because I have added SSHSMPNR to the variables kept in
ZRBASI dataset.
Thanks to Susan Kent, Charles Schwab, USA.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 26.052 IBM SMF 110 Subtype 2 Statistics STID=31 segments are not
VMAC110 always valid; the segment length of 808 indicates there
Mar 31, 2008 are 16 segments, but many segments have a value of one in
LDBNRDSN, so MXG now loops to MAX(LDRNRDSN,SKIP/44).
Impacts only the CICSDBDS dataset.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 26.051 ACF2 changed the format of ACSMFREL from a packed numeric
VMACACF2 value ('62'x for Release 6.2) to a hex character ('C0'x
Mar 28, 2008 for release 12), causing INVALID DATA FOR ACSMFREL, which
cause ACSMFREL to be a missing value, causing additional
potential errors. The INPUT was revised and 'C0'x will
now be converted to ACSMFREL=12.0;
Thanks to Patrick Holloman, Zions Bank Corp, USA.
Change 26.050 Cosmetic. Variables VOLSER and STORGRUP can be hex zeros
VMAC74 for tape devices (no volume mounted at end of interval);
Mar 28, 2008 MXG now translates to blanks to avoid non-printables.
Change 26.049 Transparent restructure of the _C102sss macros relocated
VMAC102 IF QWHSIID= nnn THEN DO; statements to be the first in
Mar 27, 2008 each definition, ahead of the LABEL, FORMAT, LENGTH, etc.
This permits the use of the _CDExxxx syntax to construct
MXG programs for multiple SMF record processing, using:
%INCLUDE SOURCLIB(VMACSMF,VMACID,VMAC110,VMAC26J2,
VMAC30,VMAC74,VMACDB2,VMAC102,IMACKEEP);
DATA
_VARID _VAR110 _VAR26J2 _VAR30
_VAR74 _VARDB2 _V102022 _V102044
_V102063
_SMF
_CDEID
ELSE _CDE26J2
ELSE _CDE30
ELSE _CDE74
ELSE _CDEDB2
ELSE _HDR102
ELSE _C102022
ELSE _C102044
ELSE _C102063
_END102
RUN;
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 26.048 If there was no SUM MIN MAX MINTIME MAXTIME or SUMLONG,
VMXGSUM VMXGSUM aborted, saying it had nothing to do, even if
Mar 27, 2008 you had asked for other statistics. Now corrected.
Change 26.047 Support for Version 6 of MegaCryption SMF records added
VMACMGCR two new variables (INCOMPATIBLY, as they were inserted):
Mar 27, 2008 MGCRCOMP='COMPRESS=*PARAMETER*IN MGCPARMS'
MGCRTSKI='TCB*ADDRESS'
and increased the length of two character fields,
MGCRIV from $8 to $16, and MGCRKS from $40 to $64.
Thanks to Denise Willers, InfoCrossing, USA.
Change 26.046 Support for GPARMKY=0050x ESS data creates new variable
IMAC6ESS ESSPRTAT='ESSPRTAT*PRINT*ATTRIBUTE*IN ESS'
VMAC6 Sample record has a value of "document-codepage=IBM-273".
Mar 28, 2008
Thanks to Peter MacCarthy-Morrogh, ATOSORIGIN, GERMANY.
Thanks to Alexander Raeder, ATOSORIGIN, GERMANY.
Change 26.045 VMACIMS support for '08'x log record for IMS Version 10
VMACIMS was incorrect even after Changes 26.026 and 26.045; the
Mar 27, 2008 logic was revised, and enhanced to use the LINTSUB bits
to store TRANSACT in LINTPSB (a new field added in V10)
and to store LINTSY2 into TRANSACT when appropriate.
Labels were added for many variables for IMS08 dataset.
Thanks to Rudolf Sauer, T-SYSTEMS, GERMANY.
Change 26.044 Change 26.026 misspelled TRANCLAS as TRABCLAS in its new
VMACIMSA in IMS 9.0+ two-byte INPUT, so TRANCLAS was still wrong.
Mar 26, 2008
Thanks to Steve Hudson, AVNET, USA.
Change 26.043 Initial header INPUT of SYSTEM in 1.4 to get SYSZONE was
VMACVMXA off by 4 bytes, but actual 1.4 INPUT was correct and the
Mar 26, 2008 value is retained from that INPUT.
Change 26.042 Support for new UARG record with PROGNAME added, but only
VMACNMON PID and FULLCOMD populated (and the short record caused
Mar 25, 2008 INPUT STATEMENT EXCEEDED error).
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 26.041 The default INTERVAL in ASUM70PR in MXG 26.01 was changed
ASUM70PR accidentally to INTERVAL=HOUR, but the intended default
Mar 21, 2008 of INTERVAL=QTRHOUR,CECINTRV=HOUR are reinstated.
Thanks to Jorge Fong, New York City DOITT, USA.
Change 26.040 Variables for zIIP engines are added to TREND.TRND72GO:
TRND72GO ZIPUNITS ZIEUNITS CPUZIPTM CPUZIETM
Mar 21, 2008
Thanks to Ingegerd Jansson, Volvo, SWEDEN.
Change 26.039 -Support for APAR OA24074 adds variable SMF70HHF to TYPE70
VMAC7072 (COMPATIBLY), with more complete HiperDispatch Status
Mar 17, 2008 than in the original HiperDispatch Status in SMF70HDM.
Mar 28, 2008 The new SMF70HHF is formatted HEX2 with these bit values:
Apr 5, 2008 SAS bit IBM Bit Meaning
'1.......' 0 HiperDispatch supported
'.1......' 1 HiperDispatch is active
'..1.....' 2 HiperDispatch status changed
-MXG 26.01 SMF70PAT/CPUPATxx, new parked time, was wrong;
my guessed INPUT of SMF70PAT/CPUPATxx Parked Time with no
test records was incorrect, needing a divide by 4096.
So MXG 26.02 is needed for HiperDispatch and Parked time.
-See Newsletter FIFTY-TWO for description and schematics
of this new "Parked Time" durations in TYPE70/TYPE70PR.
-The PCTMVSBY calculation now subtracts SMF70PAT (parked)
from SMF70ONT (online) for the denominator. Those three
elapsed time durations in SMF70PAT, SMF70ONT and DURATM
are gathered separately and small deviations are expected
and observed: SMF70PAT was 0.015 seconds (15 millisecs)
larger than SMF70ONT, which would have created a negative
PCTMVSBY, so MXG's heuristic now calculates the PCTMVSBY
only if the ONT-PAT delta is at least +.02 seconds.
-SMF70HDM was not initialized to blank and was incorrectly
kept in TYPE70 instead of TYPE70PR.
-This APAR and Change applies only to z10 and later CPUs.
Change 26.038 Datasets VXPRCIOP and VXAPLSL0 were not _NULL_'ed in the
VMACVMXA MACRO _NVMXA.
Mar 17, 2008
====== Changes thru 26.037 were in MXG 26.01 dated Mar 11, 2008=========
Change 26.037 The FORMATS step in the first MXG 26.01 fails on z/OS due
FORMATS to a syntax difference between Windows and z/OS SAS that
Mar 11, 2008 I added after the last QA test on z/OS.
Thanks to Nathan Loewenthal, CITI, USA.
====== Changes thru 26.036 were in MXG 26.01 dated Mar 10, 2008=========
Change 26.036 Variable R793CUT was 0.062 when it should have been 62,
VMAC79 the Percent MVS Utilization. Variable R793CUU, Percent
Mar 10, 2008 LPAR Utilization was correct. The 4.3 input is now 4.
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Change 26.035 Dataset TYPE74SY variable R742SDIR is FORMATed with the
FORMATS existing $MG074PD format, and that format is updated with
VMAC74 new value '20'x:'20X:LOCAL' so it can be used for both
Mar 10, 2008 R742SDIR and R742PDIR variables
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 26.034 ITRF TYPE='10'x INPUT STATEMENT LENGTH error because the
VMACITRF record with LENGTH=251 was not expected; now the code
Mar 8, 2008 tests each INPUT statement to verify data is present.
Comments added to indicate that MXG has been tested with
records from OMEGAMON XE FOR IMS 4.1 with DCR 77/78.
Change 26.033 Support for new VMWare Objects, CA NSM Performance cubes
EXTVW011 creates these new datasets with TYPETNG (NSM was TNG):
EXTVW012 DATASET DDDDDD DESCRIPTION
EXTVW013 VW011 VW011 NSM CA CPU INTERRUPT GRO
EXTVW014 VW012 VW012 NSM CA CUBE STORE GROUP
EXTVW015 VW013 VW013 NSM CA DISK GROUP
EXTVW016 VW014 VW014 NSM CA PROCESS GROUP (PI
EXTVW017 VW015 VW015 NSM FILESYSTEM
EXTVW018 VW016 VW016 NSM NETWORK
EXTVW019 VW017 VW017 NSM PRINTER QUEUE
FORMATS VW018 VW018 NSM PROCESS
IMACTNG VW019 VW019 NSM USERS
VMACTNG and new metrics were added to several existing VMWare
VMXGINIT datasets.
Mar 8, 2008
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 26.032 Debugging PUT _N_= _I_= _J_= LOCCONN=; statement printed
VMACRMFV lots of messages on the log if you enable CF data, but
Mar 7, 2008 had no other adverse impact, and is now removed.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 26.031 -Support for Dedicated zAAPs and fix for Dedicated zIIPs.
VMAC7072 Change 25.211 only worked for one Dedicated zIIP engine,
VMXG70PR because it used total ZIPWAITM vs the ZIPWAIT(LCPUADDR+1)
Mar 7, 2008 wait time for each engine, impacting TYPE70 variables
ZIPACTTM, PCTZIPBY, and PCTCIBYn. That logic is fixed,
and new logic for Dedicated zAAPS is added, impacting the
IFAACTTM, PCTIFABY, and PCTCIBYn variables. For Shared
zIIPs or zAAPs, the LPAR Dispatch time was always valid,
but for Dedicated zAAPs or zIIPS, the dispatch time was
always reported as 100% busy.
I recommend that you do not use the PDB.TYPE70PR dataset,
as it has too much detail and requires lots of logic in
your programs to sort out what's what; instead, use the
ASUM70PR-created PDB.ASUMCEC and PDB.ASUMCELP CEC-level
summary datasets or PDB.ASUM70PR and PDB.ASUM70LP, which
already have separate variables for the "CPU" times for
your CPs, ZIPs and ZAPs. But, if you still use TYPE70PR:
For Dedicated zIIPs and zAAPs, in the PDB.TYPE70PR
dataset, the LCPUPDTM and LCPUEDTM dispatch values are
not changed, and will still be the "100%" value. But
MXG now creates IFAACTTM and ZIPACTTM variables from
the ORIGWAIT field for each LCPUADDR that is an IFA or
a ZIP engine.
-Support for Dedicated zIIPs and zAAPs in ASUM70PR-created
summary datasets was also added by this change, so the
PDB.ASUM70PR, PDB.ASUM70LP, PDB.ASUMCEC and PDB.ASUMCELP
datasets have correct values.
Thanks to Mark Cohen, DTS, ITALY.
Change 26.030 -Two extraneous debugging PUT statements were removed from
VMACNTSM the SQL record processing.
Mar 6, 2008 -Datasets SQLDATAB and MSQDATAB have new variable
INSTANCE ('SQL' in SQLDATAB, MSQSRVDB in MSQDATAB),
and DATABASE is populated, for ease in combining them.
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 26.029 Cosmetic. A slash was missing in the SUCCESSFULLY READ
VMACSMF SMF message, causing a linewrap on the SAS log.
Mar 6, 2008
Thanks to Peter Krijger, ANZ National, NEW ZEALAND.
Change 26.028A Fields added COMPATIBLY to HSM FSR SMF record in z/OS 1.8
FORMATS and z/OS 1.9 are now created in HSMFSRST dataset, and all
VMACHSM bit flags are decoded.
Mar 6, 2008 New variables added in z/OS 1.8 SMF records:
FSRCPYME='REQUESTED*FAST REPLICATION*METHOD'
FSRFDASD='DASD*COPY*DELETED?'
FSRFDCPY='DUMP CLASS*COPY POOL*DELETED?'
FSRFDVER='ENTIRE*DUMP*VERSION*DELETED?'
FSRFPIGB='USED*TAPE*ALREADY*MOUNTED?'
FSRFRDMP='FAST*REPLICATION*DUMP OR*RESORE?'
FSRFREMO='COMPLETED*ON*REMOTE*SYSTEM?'
FSRFRHOS='MWE*PROCESSED*BY REMOTE*HOST?'
FSRFRTRY='BACKUP*DURING*RETRY*INUSE?'
FSRFBKTP='BACKUP*VERSION*DELETED*IS ON TAPE?'
FSRFEXBV='BACKUP*VERSION*DELETED BY*EXPIREBV?'
FSRFEXDT='DATASET*DELETED BY*EXPDT OR*MGMTCLASS?'
FSRFVINI='RECOVERY*SCHEDULED*FROM VOLUME*REQUEST?'
FSRFXPL1='DATASET*BEING*EXPIRED*IS FROM ML1?'
FSRFXPL2='DATASET*BEING*EXPIRED*IS FROM ML2?'
FSRRECON='RECONNECTION*MIGRATION?'
FSRFLG4 ='FSRFLG4*FLAGS'
FSRFG480='FSRF*FRRECOV*DSNAME*COMMAND?'
FSRFG440='FSRF*FRRECOV*FROMDISK*ONLY?'
FSRFG420='FSRF*MULTIPLE*DSNAMES*SPECIFIED?'
FSRFG410='FSRF*MULTIVOLUME*FRRRECOV*REQUEST?'
FSRFG408='FSRF*ALTERPRI*COMMAND?'
FSRFG404='FSRF*ALTERPRI*HIGH*KEYWORD?
FSRFG402='FSRF*INC*COPY POOL*INCREMENTAL?'
FSRORGID='HOST*ID THAT*GENERATED*REQUEST'
FSRFREAS='FSR*FR*REAS*RETURN*CODE'
FSRCLIP ='TARGET*VOL+FROM MWE*VOL RESTORE'
FSRCPNAM='COPY*POOL*NAME'
New variables added in z/OS 1.9:
FSRECYSO='SOURCE*FOR*RECYCLE*OPERATION'
FSRECYCN='RECYCLE*COUNTER'
FSRCALTW='RECALL*CAUSED*TAPE*TAKEAWAY?'
FSRPSQTY='TRACKS*NEEDED*WHEN ML1*OUT OF SPACE'
Bit variables now decoded that should have been decoded:
FSRFFSTR='FROM*STRIPED?'
FSRFFSTR='TO*STRIPED?'
FSRFNONQ='NOT*SERIALIZED*ENQUEU?'
FSRFNQN1='ENQUE*FAILED*ONCE?'
FSRFNQN2='ENQUE*FAILED*AGAIN?'
FSRFVER ='FSRGEN*CONTAINS*VERSON?'
FSRFVSDS='VSAM*DATASET?'
FSRFT0 ='CONCURRENT*COPY*FUNCTION*USED?'
Variables DSRTYPE,VSRTYPE,FSRTYPE,WFSRTYPE are decoded by
MGHSMFU format, which is updated with new values of:
21='21:FAST REPLICATION BACKUP FUNCTION'
22='22:FAST REPLICATION RECOVER FUNCTION'
23='23:FAST REPLICATION DELETE FUNCTION'
Thanks to Michael Friske, Fidelity Systems, USA.
Change 26.028 Protection for a divide by zero when SMF70GMU was zero,
VMXG70PR in the new Group Capacity PCTGCUSE creation in ASUM70GC
Mar 6, 2008 dataset.
Thanks to Alexander Raeder, ATOSORIGIN, GERMANY.
Change 26.027 Nigel's Monitor, NMON, writes RECTYPE='ERROR' records,
VMACNMON with a text message (ERRORMSG=), and MXG printed the text
Mar 6, 2008 on the SAS log, but ERRORMSG= made it look like it was an
MXG error. Now, when these records are read, the text on
the log is printed with this header information
NMON RECTYPE=ERROR: _N_=13720 SNAPSHOT=T0144
ENDTIME=25FEB2008:02:37:52.00
MESSAGE: ERROR,T0144,Disk statistics reset detected.
This time Read=0 Write=0 and Total So far=0
You'll have to contact your NMON guru over in AIX/LINUX
land, to find out if that message is expected or not.
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 26.026 IMS Log updates for IMS Version 9 or IMS Version 10.
IMACIMS -TYPEIMS7 and TYPEIMSA (used in ASMIMSL6/JCLIMSL6) now
IMACIMSA both keep these new variables from 07 and 08 log records
VMACIMS in their IMS0708 and IMSTRAN and BMPS datasets:
VMACIMSA From IBM IMS 07 log record:
TYPEIMS7 DLRABRSN='ABEND*REASON*CODE'
TYPEIMSA DLRCPUID='CPU ID*PLACE*HOLDER'
Mar 6, 2008 DLRESAF ='ESAF*CALLS'
DLRFLD ='FASTPATH*FLD*CALLS'
DLRNPGM ='DLRNPGM '
DLRNWID ='NETWORK*IDETIFIER*OF LAST*MESSAGE'
DLROSAMR='OSAM*IO*READS'
DLROSAMW='OSAM*IO*WRITES'
DLRPOS ='FASTPATHP*POS*CALLS'
DLRRLSE ='RLSE*CALLS'
DLRTOTIO='TOTAL*DL/I*OSAM+VSAM*CALLS'
DLRVSAMR='VSAM*IO*READS'
DLRVSAMW='VSAM*IO*WRITES'
DLRXCOPY='COPY*CALLS*(XQUERY)'
DLRXRSTR='RSTR*CALLS*(XQUERY)'
DLRXSAVE='SAVE*CALLS*(XQUERY)'
From IBM IMS 08 log record:
LINTFLG1='FLAG*1'
LINTPGM ='PROGRAM*NAME'
LINTPSB ='PSB*NAME'
LINTSUB ='IMS08*SUBTYPE'
LINTSY2 ='TRANCODE OR DBNAME'
-The default in _IMSVERS value is now consistently 8.1.
Member IMACIMS is used only in archaic TYPEIMS member.
Member IMACIMS7 sets _IMSVERS for TYPEIMS7 member.
Member IMACIMSD sets _IMSVERS for TYPEIMSD (DBCTL).
Member IMACIMSA sets _IMSVERS for TYPEIMSA (ASMIMSL6).
Member IMACIMSA sets _IMSVERS for TYPEIMSB (ASMIMSL6).
-You can always use the &MACKEEP macro variable to set the
value of _IMSVERS instream, with this syntax:
%LET MACKEEP= MACRO _IMSVERS 10.0 % ;
%INCLUDE SOURLIB(TYPEIMS7);
-All datetime stamps are now converted to local time zone
when INPUT in the VMACIMS and VMACIMSA members, now that
GMTOFFTM exists in all active IMS Versions; this makes
the detail IMSxx datasets consistent with the final
IMS0708 and IMSTRAN output datasets. The GMTOFFTM logic
in the TYPEIMSA member was removed.
-These five variables are now correctly input as Packed:
DLRMINT /* WAIT TIME*FOR*INTENT*CONFLICT*/
DLRMPOL /* WAIT TIME*FOR*POOL*SPACE*/
DLRMSCH /* ELAPSED TIME*FOR*SCHED PROCESS*/
DLRTMEIO /* DBCTL*DB I/O*ELAPSED*TIME*/
DLRTMEPL /* DBCTL*LOCKING*ELAPSED*TIME*/
-Additional cleanup and validation with V8, V9, and V10
log records, and detection of incorrect _IMSVERS setting
in many cases will stop processing with log messages.
Thanks to Steve Hudson, AVNET, USA.
Change 26.025 Support for APAR OA12774 new z10 variables (COMPAT).
VMAC7072 MXG 25.25 supports (TOLERATE) the new z10 processor, and
VMAC71 it won't fail if you install this APAR, but you will need
Mar 2, 2008 MXG 26.01 if you want to use any of these new variables:
Mar 6, 2008 New variables in TYPE70 dataset:
SMF70HDM='HIPERDISPATCH*IS*ACTIVE?'
SMF70MCR='MODEL*CAPACITY*RATING OF*SMF70MDL'
SMF70MPC='MODEL*PERMANENT*CAPACITY*IDENT'
SMF70MPR='MODEL*PERMANENT*CAPACITY*RATING'
SMF70MTC='MODEL*TEMPORARY*CAPACITY*IDENT'
SMF70MTR='MODEL*TEMPORARY*CAPACITY*RATING'
CPUPATm0='CPU 0*PARKED*DURATION'
CPUPATm1='CPU 1*PARKED*DURATION'
CPUPAT.. ...
CPUPATYb='CPU 62*PARKED*DURATION'
CPUPATYC='CPU 63*PARKED*DURATION'
CPUPATTM='TOTAL*PARKED*DURATION*ALL CPUS'
New variables in TYPE70PR dataset:
SMF70CAN='AVERAGE*THIS SMF70CIN*ENGINES*IN CEC'
SMF70POW='AVERAGE*HIPERDISPATCH*WEIGHT'
SMF70PAT='LCPUADDR*PARKED*DURATION'
New variables in TYPE70Y2 Crypto dataset:
R702NH5C='SHA-384/512:CALLS*TO*HASH'
R702NH5B='SHA-384/512:DATA*BYTES*HASH'
R702NH5I='SHA-384/512:PCMF INSTR*USED TO*HASH'
CRYIH5R ='SHA-384/512*HASHING*RATE'
CRYIH5S ='SHA-384/512*HASHING*SIZE'
New variables in TYPE71 dataset:
SMF71LOA='AVG*LARGE MEMORY*OBJECTS*ALLOCATED'
SMF71LOM='MIN*LARGE MEMORY*OBJECTS*ALLOCATED'
SMF71LOX='MAX*LARGE MEMORY*OBJECTS*ALLOCATED'
SMF71LRA='AVG NR*1 MB FRAMES*BACKED*REAL STORE'
SMF71LRM='MIN NR*1 MB FRAMES*BACKED*REAL STORE'
SMF71LRX='MAX NR*1 MB FRAMES*BACKED*REAL STORE'
-Discovered: these 12 percentage vars for CPUIDs 10,11,12
PCTCPBYA-YC, PCTIFBYA-YC, PCTZIBYA-YC, PCTCIBYA-YC
were overlaid by values from CPUIDs 61,62,63 if they
existed, because those names were reused.
New variable names for these metrics are now:
PCTCPBXA-XC, PCTIFBXA-XC, PCTZIBXA-XC, PCTCIBXA-XC
-Discovered: these variables summed across all CPUIDs
did not include CPUIDs 54 thru 63 (suffix ZT-ZZ,YA-YC):
CPUWAITM MVSWAITM CPUPDTTM CPUPATTM CPUEFFTM
Change 26.024 DB2STATS variables QTPACAUT, QTPACNOT and QTPACPUB were
VMACDB2 not de-accumulated.
Mar 1, 2008
Change 26.023 MXG 25.07-MXG 25.25 only. Fewer obs created in TYPE78CU
VMAC78 and in TYPE72IO datasets. The last LCUID was never output
Feb 27, 2008 in TYPE78CU because MXG's test for 60 bytes remaining
Apr 11, 2008 should have been for 58 bytes after the pointer was at
the end of the 2-byte field.
Thanks to Steve Lottich, The University of Iowa Hospitals, USA.
Change 26.022 The RACF Unload utility IRRDBU00 was revised to support
VMACRACF reading the EBCDIC text file while MXG executes on ASCII.
Feb 26, 2008 The output file is all text/ZD fields and MXG assumed
that under ASCII the data would have been downloaded and
translated from EBCDIC, but using ftp access to read the
file from ASCII did not work without revisions.
-Also, there were '92'x ASCII text (instead of '27'x for
single quotes) that when uploaded to z/OS became '00'x,
a non-printable, fortunately inside comments in VMACRACF
so they had no impact. But then a search of all members
found those text were also in the VMAC122, NEWSLTRS, and
DOCVER members, which were also corrected to '27'x text.
Thanks to Paul Gillis, Pacific Systems Management Pty., AUSTRALIA
Change 26.021 Specifying OUTDATA=CICSVIEW and OUTVIEW=YES with VMXGSUM
VMXGSUM caused errors because there was an extraneous &VWUTDATA
Feb 26, 2008 reference outside the DO group in line 1874. Deleting
the line corrects the MXG error.
Thanks to Nigel Greenwood, EDS, UK.
Change 26.020 Support for optional user-created CICS fields:
IMACICU6 CMODHEAD CMODNAME Variables Created
IMACICU7 VZSOAP SOAPOUT SOAPOUCN, SOAPOUTM
UTILEXCL VXAOAP SOAPABCT SOAPABCT
VMAC110
Feb 24, 2008
Thanks to Herbert Sweeney, Verizon Data Services Inc, USA.
Thanks to Vernon W. Gordon - Verizon Data Services Inc, USA.
Thanks to Marshall S. Hellmann - Verizon Data Services Inc, USA.
Thanks to Michael F. Root - Verizon Data Services Inc, USA.
Change 26.019 The DURATM values in IMACSHFT are used only for _DURSET,
IMACSHFT but the values in the examples were wrong. For those
Feb 20, 2008 three example shift definitions, the DURATM values should
have been 9*3600, 15*3600, and 48*3600
Thanks to Jeffrey A. Harder, Indiana Farm Bureau Insurance, USA.
Change 26.018 Dataset BVIR30 contained only data for Preference Group
VMACBVIR Zero, PG0. These PG1 variables are now INPUT and KEPT:
Feb 20, 2008 VIRVOL01 DATRES01 AV4HAG01 VL4MIG01 AV48AG01 VL48IG01
AV35AG01 VL35IG01
Thanks to Stan Adriaensen, AXA, BELGIUM.
Change 26.017 The COMPBYTE and UNCOMBYT byte counts were increased to 8
VMACXCOM bytes with two overflow fields that are input and added.
Feb 19, 2008 One new field overlaid TCPIPPNR, so it's a missing value.
Thanks to Peter J. Gray, EDS, AUSTRALIA.
Change 26.016 BLDSMPDB options WEEKKEEP WEEKDROP MNTHKEEP MNTHSROP did
BLDSMPDB not protect for lower case in the user input text.
Feb 18, 2008
Thanks to Loren Mitchell, Los Angeles County Office of Education,USA.
Change 26.015 Variable R783HLCU was not kept nor labeled, even though
VMAC78 I used it to confirm SMF78HIX was wrong, which led to
Feb 18, 2008 IBM APAR OA21799 (see Change 25.141)!
Thanks to Christa Neven, KBC Bankverzekerinngsholding, BELGIUM.
Change 26.014 IMPLX Version 4.1 support was incorrect; six fields that
VMACMPLX were input as PIB4. are actually PIB8., causing trashed
Feb 15, 2008 values in many variables.
Thanks to David Bixler, FISERV, USA.
Change 26.013 -With PARM='NONE', ASMRMFV still attempted to open the
ASMRMFV DDNAMES RMFBSAM, RMFFILT, and RMFSKIP. NONE was intended
Feb 10, 2008 to product no output, but omitting //RMFBSAM resulted in
a spurious USER ABEND, now eliminated. The //RMFBSAM DD
is still required for all other RMF table based selection
-Comments documenting RMFBSAM and "NONE" were enhanced.
-PARM='NONE' caused unnecessary ASMRMFV processing: the
output records were completely built before the test for
NONE, which prevented the write of the record. The test
was relocated to bypass that unwanted processing.
Thanks to Jack Schudel, University of Florida, USA.
Change 26.012 Cosmetic, used by MXG technical support. VMXGINIT prints
VMXGINIT the z/OS full dataset name or the ascii full path name
Feb 8, 2008 of each of the SOURCLIB and SASAUTOS concatenations.
On ASCII, a FILENAME statement with the LIST; operand is
used, but that does not work on z/OS, so a DATA step that
reads VEXTFL is used:
DATA; SET SASHELP.VEXTFL (UPCASE(FILEREF)='SOURCLIB'));
Change 26.011 Change 25.306 did NOT support IFCID 22 APAR PK38803; that
EX102I22 change text claimed SMF records with the APAR were wrong,
IMAC102 but that was my error; the SMF records with the APAR do
VMAC102 match IBM's DSECT, which I misread. The T102S022 dataset
VMXGINIT created by Change 25.306 will only have valid data in the
Feb 8, 2008 first obs output from each record; subsequent segments
were mis-aligned and had trashed values.
Moreover, MXG output T102S022 for each INDEX in each plan
keeping repeated values for the plan fields and wasting
disk space. This change creates new T102I022 Index
dataset with an obs for each index, keeping only the
index and sort variables, and creates the existing
T102022 dataset with one obs for each plan segment,
keeping only the plan related variables.
These index variables were removed from T102S022 dataset
QW0022MS QW0022NM QW0022AC QW0022AN
QW0022MO QW0022XF QW0022FF QWOL22AC
QW0022AC QWOL22AN QW0022AN
as they are now only kept in the T102I022 index dataset.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 26.010 New utility %MACRO VMXGPARS parses macro variables, like
UTILBLDP MACKEEP=, INCODE=, etc., that are a long string of text,
VMXGPARS into "chunks" that fit in 72 bytes and that are chunked
Feb 8, 2008 into reasonably humanly readable pieces of code. Used
now in UTILBLDP, it's use will like be extended to other
%MACRO defining members in the future.
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.009 NOTE: INVALID DATA FOR TRNSTTRA and TRNSTOPA is cosmetic
VMACCIMS only, and occurs when either field is not populated. MXG
Feb 6, 2008 now protects the PD input with double question marks.
The output datasets were correctly created.
Thanks to Ermanno Bertolotti, Intesa SanPaolo, ITALY.
Change 26.008 New MYDATA parameter is added, and a new CASE 3 example
VMXGUOW of how you might use it to insert new dataset name(s) and
Feb 5, 2008 a keep list, so that you can create a subset of ASUMUOW
(eg, based on Transaction name), without having to repass
millions of records in ASUMUOW to create it.
Thanks to Chuck Hopf, Bank of America, USA.
Change 26.007 The CICS Dispatcher Statistics CICDS dataset created from
VMAC110 SMF 110 Subtype STID=60 statistics segments, and the MXG
VMXGCICI PDB.CICINTRV interval summary dataset have new variables
Feb 5, 2008 CICTCTTM='TOTAL*DSGTCT*DURATION*TIME'
CICTDTTM='TOTAL*DSGTDT*DISPATCHED*TIME'
CICTWTTM='TOTAL*DSGTWT*IN OS WAIT*TIME'
and the existing
CICTCBTM='TOTAL*DSGACT*CPU TCB*TIME'
summed across all 19 CICS TCB names for the interval.
These data were added primarily so an IBM "Rule of Thumb"
could be tested; new variable
PCTREGBY='PCT*TCB/(TDT+TCW)*BUSY;
calculates the percent of Dispatch+OS Wait time that was
executing CPU TCB time, and IBM's recommends that if the
PCTREGBY formula calculates to more than about 70 percent
busy, they suggest that you need additional CICS Regions.
Thanks to Jacob Nudel, Thompson BETA Systems, USA.
Change 26.006 Support for 64 CP Engines adds sets of variables for CPs
VMAC7072 54 thru 63 with suffixes ZS-ZZ and YA-YC for TYPE70 data.
Feb 1, 2008 No such systems yet exist, but are expected so the code
Mar 8, 2008 is now in place to create those per-CPU variables.
Change 26.005 In all XAM VM datasets, variable ZDATE was LENGTH 5,
VMACXAM because it was created by code in VMACXAM instead of the
Jan 31, 2008 %%INCLUDE SOURCLIB(IMACZDAT);
which sets ZDATE's length to 4, which is always used to
create ZDATE, not only for length consistency, but the
IMACZDAT member is the tailoring member you would use for
a rerun of a prior daily build PDB job, to set the value
of ZDATE to that prior date. Having LENGTH 5 is not an
error, even though only 4 bytes are used elsewhere in MXG
but it's inconsistency uncovered this inconsistency.
Thanks to Theo Peelen, Fortis Bank, BELGIUM.
Change 26.004 -MXG expected NMON's "AAA,time" record ahead of "AAA,date"
VMACNMON but this site's data had "AAA,date", several lines, then
Jan 31, 2008 "AAA,time", which caused STARTIME to always be a missing
value. Presuming a local specification changed the order
I protected STARTIME for either order, found STARTIME was
now always populated in NMONINTV, but was still always
missing in NMONCPUD and all of the other datasets. After
much debugging, I discovered the original NMON data file
had been SORTED, which not only put date ahead of time,
but had lumped all of the end of interval 'ZZZZ' records
at the bottom, so none of the ENDTIME-only records, like
the CPUnn records, had either ENDTIME or STARTIME.
The moral: DO NOT SORT NMON DATA;
-Support added for new record types: ESSREAD and ESSWRITE
with seven VPATHn KB/sec, and ESSXFER with seven transfer
rates per second for each vpath.
Thanks to Massimo Pugliese, ELSAG Spa, ITALY.
Change 26.003 LPARCPUS is not integer in PDB.ASUM70LP & PDB.ASUMCELP
VMXG70PR MXG summary datasets, and LPARCPUS=0 could have been a
Feb 5, 2008 value between 0 and 1, because MXG erroneously FLOOR'd
LPARCPUS to force an integer value. While LPARCPUS in
PDB.TYPE70PR observations at the LCPUADDR detail is an
integer number of CP engines, in summarizing counts of
LCPUADDRs in each LPAR, and/or multiple intervals, MXG
sums SMF70ONT (the Online Time) and divides by DURATM,
the interval duration to create LPARCPUS. But the IPL
interval for a 3-CP engine with DURATM 5 minutes had only
3 minutes of uptime, SMF70ONT, causing LPARCPUS=0, when
the true LPARCPUS=0.7 value should have been calculated.
Now, that FLOOR is removed, LPARCPUS is FORMATed 6.1,
(so the printed value will be rounded and hence those old
2.9999 values will print as 3.0), and is now labeled:
LPARCPUS='LPAR*AVERAGE*NUMBER OF*CP*PROCESSORS'
in the datasets built by ASUM70PR summarization program.
Thanks to William Wai Lun WONG, HSBC, HONG KONG.
Change 26.002 Cosmetic, but still wrong and possibly confusing: a dozen
FORMATS value statements in FORMATS had incorrect right-hand hex
Jan 31, 2008 for the left-hand value (like '04'X='40X: explanation').
A new QA job will catch this type of error in the future.
Thanks to Danny Ball, Con-way Enterprise Services, USA.
Change 26.001 Typo VMUM introduced in Change 25.252 corrected to VWUM.
VMXGCAPT
Jan 30, 2008
Thanks to Brian Carter, EDS, UK.
LASTCHANGE: Version 26.
=========================member=CHANGE25================================
/* COPYRIGHT (C) 1984-2008 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 25.25 is dated Jan 28, 2008, thru Change 25.309
First MXG Version 25.25 was dated Jan 21, 2008, thru Change 25.302
MXG Version 25.12 was dated Jan 21, 2008, thru Change 25.294
MXG Version 25.11 was dated Dec 7, 2007, thru Change 25.268
First MXG Version 25.11 was dated Nov 22, 2007, thru Change 25.256
MXG Version 25.10 was dated Oct 7, 2007, thru Change 25.215
MXG Version 25.09 was dated Sep 17, 2007, thru Change 25.199
MXG Version 25.08 was dated Sep 5, 2007, thru Change 25.187
First MXG Version 25.08 was dated Sep 4, 2007, thru Change 25.182
MXG Version 25.07 was dated Aug 10, 2007, thru Change 25.161
MXG Version 25.06 was dated Jul 4, 2007, thru Change 25.134
MXG Version 25.05 was dated Jun 7, 2007, thru Change 25.107
MXG Version 25.04 was dated May 7, 2007, thru Change 25.086
Second MXG Version 25.03 was dated Apr 12, 2007, thru Change 25.058
First MXG Version 25.03 was dated Apr 10, 2007, thru Change 25.057
MXG Version 25.02 was dated Mar 10, 2007, thru Change 25.033
MXG Version 25.01 was dated Mar 5, 2007, thru Change 25.025
MXG Version 24.24 was dated Feb 5, 2007, thru Change 24.306
MXG Newsletter FORTY-NINE was dated Feb 5, 2007
MXG 25.25 is the 2008 "Annual Version", dated January 28, 2008.
Instructions for ftp download of MXG 25.25 were mailed to all licensees,
but you can always request ftp download instructions using the form at
http://www.mxg.com/ship_current_version
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. Current MXG Software Version 25.25 is available upon request.
II. Incompatibilities and Installation of MXG 25.25.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Version 25.25, now re-dated Jan 28, 2008.
Minor cosmetic corrections in MXG 25.25, re-dated Jan 28, 2008
TYPEXAM 25.307 Extraneous PUT from testing removed.
ASUM70PR 25.303 Extraneous PROC PRINT from testing was removed.
Minor enhancements in MXG 25.25, re-dated Jan 28, 2008
TYPERMFV 25.309 Support for RMF III CPD, Channel Path Data Table.
TYPE102 25.306 IBM SMF 102 IFCID 22 APAR PK38803 wrong, supported.
TYPE30 25.304 Support for APAR OA23679, BLKSIZE might be wrong.
COMPINTV 25.302 Capture/Compare ALL CPU times in 30/70/72/100/101/110
Major enhancements added in MXG 25.25, dated Jan 21, 2008
ADOCs 25.296 All ADOCxxxx member's CONTENTS were updated.
Major enhancements added in MXG 25.12, dated Jan 21, 2008
TYPEDB2 25.265 DB2TCBTM Correction for DB2 V9.1, REQUIRED.
TYPEDB2 25.291 DB2ACCT variable QWACUDCP CPU time added in DB2TCBTM.
TYPE122 25.287 Support for SMF 122, Tivoli Tape Allocation Manager
TYPEITRF 25.286 Support for ITRF DCR77/DCR78 additions.
TYPENTSM 25.282 Support for new NTSMF Objects, Database Mirroring.
TYPEMQLG 25.280 Support for MQ V6 System Admin Accounting Queue Log.
TYPE85 25.279 Support for subtypes 38, 39 and 40 for ID=85 OAM.
TYPEPSYC 25.277 Support for PSYNCH/390 SMF record.
TYPE22 25.276 Support for APAR OA20043 Dynamic Volume Expansion
TYPE102 25.306 Support for APAR PK38803 INCOMPAT SMF 102 IFCID 22.
TYPE50 25.269 Support for OSA-MPC VTAM SMF 50 subtype 4 record.
TYPETIMS 25.271 Revisions for TMON/IMS support
ASUM70PR 25.270 INTERVAL=DURSET cannot be used.
CONFIGV9 25.267 VALIDVARNAME=V7 added to SAS CONFIGs.
ITRMTNG 25.262 233 DDU files to create ITRM definitions for TYPETNG.
Major enhancements added in MXG 25.11 dated Dec 7, 2007.
TYPE111 25.241 Support for CICS CTG 7.1.0 new SMF 111 record.
TYPE110 25.240 Full Support for CICS/TS 3.2 Compressed Data
EXITCICS 25.240 New "CICS" INFILE EXIT for CICS compressed SMF data.
TYPE7072 25.224 CPUTYPE tests are replaced with ZARCHMDE tests.
This means that with MXG 25.11 or later, a new IBM
CPUTYPE will NOT require a new MXG Version.
TYPETPMX 25.239 Support for Thruput Manager SLM and DB2 data.
TYPE82 25.257 Support for ISCF HCR7750 TKE Logging update.
TYPEEVTA 25.255 Support for Action Software's EventAction user SMF.
TYPE85 25.234 New variables in OAM subtype 32-35 records.
TYPE78 25.236 Zero obs in TYPE78IO with Change 24.171 if z/OS 1.7.
TYPEEVTA 25.255 Support for Action Sofware's EventAction SMF record.
TYPERMFV 25.246 Updates for CPU Segmentation changes.
TYPENTSM 25.253 Support for new NTSMF objects for MSSQL.
TYPETNG 25.221 Support for VM Ware VSX Systems in CA NSM records.
TYPETNG 25.235 New Solaris, AIX, and many RedHat objects added.
VMXGSUM 25.248 New &LNSUMOUT=8 will make all output to length 8.
UTILEXCL 25.256 Macro variable &MXGDEBUG revised for IMACEXCL plus!
EXITCICS 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
TYPE110 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
UPRINDOC 25.226 Utility prints NAME and LABEL of all variables.
TYPE30 25.260 MXG 25.10, INTRVLTM missing for TYPETASK='OMVS'
ANALACTP 25.254 Sample report summarizes DB2 Package data to UOW.
CONFIGW2 25.252 MXG updates for testing MXG Execution under WPS.
Major enhancements added in MXG 25.10.
TYPE7072 25.205 Support for z/OS 1.9, up to 54 CPUs per MVS, INCOMPAT
TYPERMFV 25.204 CFI Segmentation eliminates RMF III skipped CF data.
ANALDB2R 25.202 VARIABLE QBnTDPIO NOT FOUND error corrected.
TYPE70 25.211 ZIPACTTM, PCTZIPBY corrected for Dedicated zIIPs.
ASUMCELP 25.209 Duplicate observations in PDB.ASUMCELP eliminated.
TIMEBILD 25.209 Optional SYNC59 timeshifting using TIMETABL.
Major enhancements added in MXG 25.09.
IMPORTANT CHANGES:
Almost none! Only UTILEXCL in 25.08 had an error, but these other
fixes/enhancements are now ready for prime time:
UTILEXCL 25.193 MXG 25.08 ONLY: LABEL IMACICU3 NOT FOUND.
TYPERMFV 25.191 Support for RMF Monitor III CFI table enhancements.
TYPESRDF 25.195 Support for EMC's SRDF/A user SMF record.
READDB2 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
ANALDB2R 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
RMFINTRV 25.199 SMF70GIE now reset to 00/15 if SYNC59=YES is used.
TYPE89 25.198 SMF89HOF,SMF89DTO were incorrect due to typo.
UTILCSV 25.197 %UTILCSV creates a CSV (or TAB) Delimited flat file.
UTILBLDP 25.196 Large &MACKEEP string caused strange results.
TYPE92 25.192 New ID=92 ST=14 INPUT EXCEEDED if not a RENAME.
Major enhancements added in MXG 25.08.
IMPORTANT CHANGES:
TYPETNG 25.181 Support for CA NSM RedHat 4.01 Linux perf cube.
TYPE7072 25.176 Support for APAR OA18244, Blocked Workload z/OS 1.9.
TYPE7072 25.163 Support for Capacity Groups variables in TYPE70.
ASUM70PR 25.163 Capacity Group summarization, PDB.ASUM70GC/ASUM70GL.
TYPEQACS 25.178 AS400 APAR QAPMDISK with LRECL=456 added new data.
ADOCDB2 25.172 Example to process DB2 datasets to separate DDNAMES.
TYPEDB2 25.169 _RDB2ACC DB2 Parallel event "analysis" example.
Many 25.179 %UPCASE,%LOWCASE,%STR,%BQUOTE,%QUOTE, etc.
Doc 25.179 Use %LET MACxxxx= %STR( text ) ; to pass text.
Major enhancements added in MXG 25.07.
CRITICAL CHANGE:
TYPE78 25.141 APAR OA21799 for HiperPAV, ABEND, SMF78HIX invalid.
Installing HyperPAV can create invalid RMF 78-3's
that cause BUILDPDB to ABEND as it reads RMF 78's.
Change 25.141 will detect bad records and avoid the
ABEND, but you will need to install the IBM PTF for
the APAR to correct the invalid data values.
IMPORTANT CHANGES/ENHANCEMENTS:
Many 25.140 Prelim z/OS 1.9 (fails if 54-CPs, See Ch 25.205)
TYPECIMS 25.139 Support for IMF Version 4.3 (INCOMPATIBLE).
TYPE74 25.140 APAR OA17070 supports CF Level 15 measurements.
TYPE89 25.138 Support for APAR OA20314 new SMF89LPN/SMF89ZNA.
TYPE80A 25.137 Support for unknown TOKDANAMs, prevents ABEND.
UTILLPDS 25.136 Utility to count used/defined PDS Directory Blocks.
TYPE7072 25.135A LCPUCAP/LCPUCAPC Labels include "Hard CAP".
TYPE42 25.153 MXG 25.06 only, false INVALID TYPE42 SUBTYPE 5 error.
TYPEVMXA 25.151 180 Error _MPRCAPC not found, DEBUG prints removed.
ASUM70PR 25.150 ASUM70PR created PCTCPUBY GT 100%, final fix?
ASUM70PR 25.150 ASUM70PR now supports INTERVAL/CECINTRV=SHIFT.
ADOCITRM 25.149 Doc. Maps ITRM dataset names to MXG name.
ADOCDB2 25.148 Doc. How to create DB2ACCTB/DB2ACCTP in separate DDs.
ANALRMFR 25.146 ERROR: NO DATASETS TO LOOKUP correction.
TYPERMFV 25.145 RMF III dataset ZRBLCP missing obs for many LPARs.
UPCMEMDZ 25.144 ASCII utility to determine memory available to MXG.
TYPE71 25.143 SWAPrates were set missing if zero, now can be zero.
VMXGINIT 25.143 New MXGMISS macro variable changes TYPE71 SWAPrates.
Major enhancements added in MXG 25.06.
TYPE30 25.116 MXG 25.05, negative EXECTM, INTRVLTM, GMTOFF30 wrong.
TYPE110 25.041 Support for CICS/TS 3.2 (INCOMPATIBLE), Uncompressed.
TYPEBTE 25.107 Support for CA Brightstor Tape Encryption SMF.
TYPE80A 25.131 Support for CRL PUBLISH and SET UID RACFEVNT 52, 79.
TYPEFERT 25.133 Support for Williams Data FERRET product user SMF.
TYPECLAR 25.130 Support for Clarion Disk Array flat files.
TYPE119 25.119 SMF 119 from z/OS 1.8 caused INVALID DATA messages.
TYPESYNC 25.117 INVALID ARGUMENT due to incorrect HEX4/HEX3 formats.
ASUMUOW 25.121 Enhanced to keep each CICS segment response time.
ASUMHSM 25.113 HSM Summary enhanced with "HSM COMPLEX" HSMPLEX.
IHDRIDMS 25.112 CA IDMS PerfMon support enhanced with "IHDR" exit.
TYPENMON 25.110 Support for DISKBUSYn for all NMON Disk Monitoring.
TYPERACF 25.134 Support for IRRDBU00 record types 0560,0561,0562.
TYPE80A 25.131 Support for TOP SECRET (INCOMPAT) '90'x,'00'x VRSN.
MXG Version 25.05, dated Jun 7, 2007.
Major enhancements added in MXG 25.05.
TYPEITRF 25.103 Support for IBM OMEGAMON TRF ITRF V550 and V560.
TYPENMON 25.104 Full support for NMON, Nigel's Monitor for AIX/unix.
TYPEDB2 25.090 Support for PK37354 SMF 101 Subtype 4 in DB2 9.
TYPEDB2 25.097 Variable THREADTY blank if non-DDF transaction.
TYPE30 25.089 GMTOFF30 calculation corrections and problems.
CONFIGV9 25.101 MEMLEAVE=10M SORTBLOCKMODE now set in CONFIGV9
UTILBLDP 25.098 %UTILBLDP(BUILDPDB=JES3 ... enhancement.
Major enhancements added in MXG 25.04.
TYPE21 25.083 Fix for support for APAR OA20077 Device Bytes TYPE21.
TYPEXAM 25.082 Support for XAM Release 3.6, many new data.
TYPENMON 25.073 Support for LPAR and IOADAPTR Nigel's NMON data.
SYSLOG 25.070 Support for SYSLOG file enhanced, all records output.
TYPENDM 25.081 Support for NDM-CD type 'NM' records creates NDMNM.
DALYTAPE 25.072 Sample tape reports from STC VTS SMF + MXGTMNT.
TYPERMFV 25.079 ZRBLCP dataset had only first LPARs observations.
TYPEDB2 25.064 Several QISE variables were wrong.
TYPEDB2 25.075 QBGL variables in DB2 V8.1 now supported, were wrong.
TYPETMS5 25.084 FILSEQ in TMS.DSNBRECD could be wrong, mult-vol-file.
ANALDB2R 25.068 SQL Text QW0141TX was not printed, coding error.
UTILBLDP 25.071 Products that need deaccumulation now protected.
UTILBLDP 25.065 Default list of ASUMxxx to be included, MXGINCL=.
VMXGRMFI 25.069 Service Class Names can be "wild-carded"
VMXGUSE 25.067 Revised to invoke _STY70; UTILBLDP recommended.
FORMATS 25.063 Additional SWAP reason codes added to $MG079SR.
Doc 25.078 List of MXG-issued USER ABEND values & source member.
Major enhancements added in MXG 25.03.
CONFIGV8 25.037 SORTEQUALS should NOT have been in CONFIGV8, V9 only.
TYPE119 25.035 Support for SMF 119 for z/OS 1.8 (INCOMPATIBLE).
TYPE1415 25.047 Support for APAR OA19502, SMF14KET Key Exchange Time
TYPE21 25.040 Support for APAR OA20077, uncompress read/write bytes
TYPEAIXT 25.039 Support for AIX Tapas-C performance data files.
TYPESAMS 25.055 Support for SAMS objects 2151,2226,2229 and 2231.
TYPETDS 25.052 Support for TDSLink Version 630 ZCOST datasets.
TYPECSM 25.050 Support for CrossSysplexManager user SMF record.
TYPSCOCR 25.034 Support for CopyCross (now VTF Mainframe 2.1.0) SMF.
VMXGDUR 25.044 Interval= QUARTER, SEMIANN, ANNUAL now supported.
TYPEHSM 25.042 Process HSM with different SMF IDs/different SYSTEMs.
ASUMTAPE 25.040 Uncompress read/write SMF21DBR/DBW kept in ASUMTAPE.
ASUMUOW 25.054 QWACSPCP,QWACTRET added to PDB.ASUMUOW for OTE.
ASUMCEC 25.053 PDB.ASUMCEC, PCTCPUBY GT 100%, DURATM LT CECINTRV.
BLDSMPDB 25.048 Corrections to BLDSMPDB, new SORTEDBY= option.
Major enhancements added in MXG 25.02.
MXG 25.02 was created to protect sites who set the NOSORTEQUALS
option (i.e., changed the SORTEQUALS default). NOSORTEQUALS causes
invalid data in ASUM70PR-built datasets.
CONFIGV9 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
VMXG70PR 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
Other New Support and corrections added in MXG 25.02:
ASMTAPEE 25.033 Support for ASMTAPEE ML-40 assembly under z/OS 1.8.
ANALRMFR 25.032 IRD corrections to RMF reports.
TYPE42DS 25.030 TYPE42DS had carried-forward IOCOUNT and other vars.
TYPE70 25.028 IORATEn per-engine I/Os corrected for IRD.
VMXGPRAL 25.028 Print All utility now compares all datasets in LIBs.
UCOMPSOE 25.028 Utility to compare SORTEQUALS and NOSORTEQUALS output
ANALFIOE 25.026 Divide by zero message protected.
Major enhancements added in MXG 25.01.
The MXG 24.24 Annual Version is VERY solid, with only these three
relatively minor corrections:
TYPENTSM 25.015 INCOMPAT MXG CHANGE for NTSM WEEKly requires action.
TYPE7072 25.013 PCTMVSBY in PDB.TYPE70PR was wrong if IRD was active.
ASUM70PR 25.001 NRICFCPU,NRIFLCPU were wrong if you have more than 1.
Other New Support and corrections added in MXG 25.01:
TYPEIMS7 25.006 Support for IMS Version 10 (INCOMPATIBLE) IMS log.
TYPEBVIR 25.011A Support for TS7700 SMF records.
TYPE7 25.025 Support for APAR OA19453 for 4-byte LOSTRECS count.
TYPE74 25.003 NREXPOSR was wrong for HyperPAV devices.
IMACICMR 25.007 Optional CICS CMRDATA, CMDUDATA/CMDDBCCP reversed.
IMACICOB 25.008 Optional CICS OMDBDB2LN now spelled as OMBDB2LN.
IMACICOM 25.008 Optional CICS OMMLN now spelled as OMMQLN.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements in MXG 22.08" in CHANGES, above, for the major
items, then search Newsletters for V9 for all of the minor items.
MXG executes under SAS V8.2 and SAS V9.1.3, but MXG is no longer
supported under SAS V6. The "PDB" libraries written to by MXG
must have been created by V8/V9 (i.e, if ENGINE=V6 is shown in the
PROC CONTENTS output, you must convert that data library to the
current ENGINE=BASE by PROC COPYing it under SAS V8 or V9.
For SAS V9.1.3 on z/OS with Service Pack 4:
There are no reported errors, and MXG's CONFIGV9 now specifies
V9SEQ instead of V6SEQ. As V6SEQ does not support long length
character variables, it should not be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) is required
to be completely safe. No earlier Version 8's were supported.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it is now the default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG New-Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on Windows XP with SAS V9.1.3. But previous QA tests
have been run with all SAS releases on z/OS, SAS V8.2 and V9.1 on
Linux RH8 on Intel, with V9.1 on Solaris v2.8 on Model V880, and
V9.1 on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V8.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
Availability dates for the IBM products and MXG version required for
the processing of that product's data records:
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Oct 5, 2007 25.10
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
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
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 Jan 22, 2007 25.04
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Dec ??, 2004 22.08
IMS log 10.0 Feb 27, 2007 25.01
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
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 20.04
The Monitor for DB2 Version 4.0 22.10
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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including cics/ts 3.1 22.08
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
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
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 CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 22.08
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 25.04
II. Incompatibilities and Installation of MXG 25.11.
1. Incompatibilities introduced in MXG 25.11:
a- Changes in MXG architecture made between 25.11 and prior versions
that can introduce known incompatibilities.
NTSMF Weekly/Monthly processing will fail on BLKBERRY dataset due
to new variable in the BY list. See Change 25.015 for required
actions you must take prior to running the Weekly/Monthly. The
incompatibility was introduced by Change 24.162 in MXG 24.06.
Change 25.189 revised %READDB2/%ANALDB2R when PDBOUT=, is null.
Now, ALL output datasets are written to //WORK, which was intended
when PDBOUT=null, but that did not always happen.
The error corrected was that a simple report with %ANALDB2R
failed if there was no //PDB DD name, because MXG tried used the
default DDnames, and did not force them to //WORK as desired.
That correction created a new exposure if you actually did have
a //PDB DD name, if you had changed DDNAME defaults with
%LET PDB2ACC or MACRO _LDB2ACC or _WDB2ACC,
and if you did not specify PDBOUT=PDB; Change 25.189 now caused
zero observations in PDB.DB2ACCT.
So if you want output datasets created by %READDB2/%ANALDB2R, you
must specify
PDBOUT=PDB (which works as documented, output all to //PDB), or
PDBOUT=YES (which outputs to the (tailored) default DDNames, or
PDBOUT=ZZZ (which outputs everything to ZZZ DDname).
Change 25.284, in MXG 25.25, corrected the original Change 25.189.
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 Version 9.1.3 (JCLINST8 for SAS Version 8.2).
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. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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 in MXG 25.06 after MXG 24.24:
Dataset/
Member Change Description
Many 25.140 Support for z/OS 1.9 (COMPAT, minor SMF additions).
Many 25.179 %UPCASE,%LOWCASE,%STR,%BQUOTE,%QUOTE, etc.
ADOCDB2 25.172 Example to process DB2 datasets to separate DDNAMES.
ADOCDB2 25.148 Doc. How to create DB2ACCTB/DB2ACCTP in separate DDs.
ADOCITRM 25.149 Doc. Maps ITRM dataset names to MXG name.
ANALACTP 25.254 Sample report summarizes DB2 Package data to UOW.
ANALDB2R 25.202 VARIABLE QBnTDPIO NOT FOUND error corrected.
ANALDB2R 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
ANALDB2R 25.068 SQL Text QW0141TX was not printed, coding error.
ANALFIOE 25.026 Divide by zero message protected.
ANALRMFR 25.146 ERROR: NO DATASETS TO LOOKUP correction.
ANALRMFR 25.032 IRD corrections to RMF reports.
ASMTAPEE 25.033 Support for ASMTAPEE ML-40 assembly under z/OS 1.8.
ASUM70PR 25.303 Extraneous PROC PRINT from testing was removed.
ASUM70PR 25.270 INTERVAL=DURSET cannot be used.
ASUM70PR 25.163 Capacity Group summarization, PDB.ASUM70GC/ASUM70GL.
ASUM70PR 25.150 ASUM70PR created PCTCPUBY GT 100%, final fix?
ASUM70PR 25.150 ASUM70PR now supports INTERVAL/CECINTRV=SHIFT.
ASUM70PR 25.001 NRICFCPU,NRIFLCPU were wrong if there was more than 1
ASUMCEC 25.053 PDB.ASUMCEC, PCTCPUBY GT 100%, DURATM LT CECINTRV.
ASUMCELP 25.209 Duplicate observations in PDB.ASUMCELP eliminated.
ASUMHSM 25.113 HSM Summary enhanced with "HSM COMPLEX" HSMPLEX.
ASUMTAPE 25.300 Blank SYSTEM, missing DEVNR in PDB.ASUMTAPE fixed.
ASUMTAPE 25.040 Uncompress read/write SMF21DBR/DBW kept in ASUMTAPE.
ASUMUOW 25.121 Enhanced to keep each CICS segment response time.
ASUMUOW 25.054 QWACSPCP,QWACTRET added to PDB.ASUMUOW for OTE.
BLDSMPDB 25.048 Corrections to BLDSMPDB, new SORTEDBY= option.
COMPINTV 25.302 Capture/Compare ALL CPU times in 30/70/72/100/101/110
CONFIGV8 25.037 SORTEQUALS should NOT have been in CONFIGV8, V9 only.
CONFIGV9 25.267 VALIDVARNAME=V7 added to SAS CONFIGs.
CONFIGV9 25.101 MEMLEAVE=10M SORTBLOCKMODE now set in CONFIGV9
CONFIGV9 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
CONFIGW2 25.252 MXG updates for testing MXG Execution under WPS.
DALYTAPE 25.072 Sample tape reports from STC VTS SMF + MXGTMNT.
Doc 25.179 Use %LET MACxxxx= %STR( text ) ; to pass text.
Doc 25.078 List of MXG-issued USER ABEND values & source member.
EXITCICS 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
EXITCICS 25.017 SAS INFILE EXIT for compressed CICS SMF 110-1 data.
FORMATS 25.063 Additional SWAP reason codes added to $MG079SR.
IHDRIDMS 25.112 CA IDMS PerfMon support enhanced with "IHDR" exit.
IMACICMR 25.007 CMRDATA, CMDUDATA/CMDDBCCP reversed.
IMACICOB 25.238 OMEGAMON did NOT increase time-duration to 12 bytes.
IMACICOB 25.008 OMDBDB2LN now spelled as OMBDB2LN.
IMACICOM 25.008 OMMLN now spelled as OMMQLN.
ITRMTNG 25.262 233 DDU files to create ITRM definitions for TYPETNG.
MXGWPSV2 25.252 Revised JCL Procedure for MXG Execution under WPS.
READDB2 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
RMFINTRV 25.199 SMF70GIE now reset to 00/15 if SYNC59=YES is used.
RMFINTRV 25.177 ARRAY SUBSCRIPT OUT OF RANGE, 9999 LIMIT externalized
SYSLOG 25.070 Major revisions to SYSLOG program, will be renamed.
TIMEBILD 25.209 Optional SYNC59 timeshifting using TIMETABL.
TYPE102 25.306 Support for APAR PK38803 INCOMPAT SMF 102 IFCID 22.
TYPE102 25.306 IBM SMF 102 IFCID 22 APAR PK38803 wrong, supported.
TYPE102 25.129 IFCID=224 updated with QW0224PN and QW0224CI.
TYPE110 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
TYPE119 25.119 SMF 119 from z/OS 1.8 caused INVALID DATA messages.
TYPE119 25.119 Support for SMF 119 for z/OS 1.8 (INCOMPATIBLE).
TYPE120 25.247 SM120SNT=2 (two heap ids) caused INPUT EXCEEDED.
TYPE122 25.287 Support for SMF 122, Tivoli Tape Allocation Manager
TYPE1415 25.047 Support for APAR OA19502, SMF14KET Key Exchange Time
TYPE21 25.083 Actual support for APAR OA20077 Device Bytes TYPE21.
TYPE21 25.040 Support for APAR OA20077, uncompress read/write byte
TYPE22 25.276 Support for APAR OA20043 Dynamic Volume Expansion
TYPE30 25.304 Support for APAR OA23679, BLKSIZE might be wrong.
TYPE30 25.260 MXG 25.10, INTRVLTM missing for TYPETASK='OMVS'
TYPE30 25.116 MXG 25.05, negative EXECTM, INTRVLTM, GMTOFF30 wrong.
TYPE30 25.089 GMTOFF30 calculation corrections and problems.
TYPE42 25.153 MXG 25.06 only, false INVALID TYPE42 SUBTYPE 5 error.
TYPE42DS 25.030 TYPE42DS had carried-forward IOCOUNT and other vars.
TYPE50 25.269 Support for OSA-MPC VTAM SMF 50 subtype 4 record.
TYPE70 25.211 ZIPACTTM, PCTZIPBY corrected for Dedicated zIIPs.
TYPE70 25.028 IORATEn per-engine I/Os corrected for IRD.
TYPE7072 25.237 LCPUWAIT was accidentally not kept in TYPE70.
TYPE7072 25.227 Variable RPRTCLAS now kept in TYPE72DL dataset.
TYPE7072 25.224 CPUTYPE tests are replaced with ZARCHMDE tests.
TYPE7072 25.205 Support for z/OS 1.9 54 CP engines per MVS, INCOMPAT
TYPE7072 25.176 Support for APAR OA18244, Blocked Workload z/OS 1.9.
TYPE7072 25.163 Support for Capacity Groups variables in TYPE70.
TYPE7072 25.135A LCPUCAP/LCPUCAPC Labels include "Hard CAP".
TYPE7072 25.013 PCTMVSBY in PDB.TYPE70PR was wrong if IRD was active.
TYPE70PR 25.051 NRIFACPU now populated for z990/2084 CPUTYPE.
TYPE71 25.143 SWAPrates were set missing if zero, now can be zero.
TYPE71 25.109 UIC variables changed meaning in z/OS 1.8.
TYPE74 25.140 APAR OA17070 supports CF Level 15 measurements.
TYPE74 25.140 Support for APAR OA17070 RMF 74-4 Coupling Facility
TYPE74 25.108 R748CSER/CTYP/CDML now kept in TYPE748 dataset.
TYPE74 25.003 NREXPOSR was wrong for HyperPAV devices.
TYPE78 25.236 Zero obs in TYPE78IO with Change 24.171 if z/OS 1.7.
TYPE78 25.141 APAR OA21799 prevents ABEND, SMF78HIX invalid.
TYPE80A 25.137 Support for unknown TOKDANAMs, prevents ABEND.
TYPE80A 25.131 Support for CRL PUBLISH and SET UID RACFEVNT 52, 79.
TYPE80A 25.131 Support for TOP SECRET (INCOMPAT) '90'x,'00'x VRSN.
TYPE80A 25.111 TYPE80xx variable TYPSTRNG wrong after Change 25.024.
TYPE82 25.257 Support for ISCF HCR7750 TKE Logging update.
TYPE85 25.279 Support for subtypes 38, 39 and 40 for ID=85 OAM.
TYPE85 25.234 New variables in OAM subtype 32-35 records.
TYPE89 25.198 SMF89HOF,SMF89DTO were incorrect due to typo.
TYPE89 25.138 Support for APAR OA20314 new SMF89LPN/SMF89ZNA.
TYPE92 25.192 New ID=92 ST=14 INPUT EXCEEDED if not a RENAME.
TYPE99 25.012 SMF 99 with only Trace, INPUT STATEMENT EXCEEDED.
TYPEAIXT 25.039 Support for AIX Tapas-C performance data files.
TYPEBTE 25.107 Support for CA Brightstor Tape Encryption SMF.
TYPEBVIR 25.011A Support for TS7700 SMF records.
TYPECIMS 25.230 IMF 4.2 PTF BQI0129 caused INPUT EXCEEDED error.
TYPECIMS 25.139 Support for IMF Version 4.3 (INCOMPATIBLE).
TYPECLAR 25.130 Support for Clarion Disk Array flat files.
TYPECSM 25.050 Support for CrossSysplexManager user SMF record.
TYPEDB2 25.291 DB2ACCT variable QWACUDCP CPU time added in DB2TCBTM.
TYPEDB2 25.265 DB2TCBTM Correction for DB2 V9.1, REQUIRED.
TYPEDB2 25.169 _RDB2ACC DB2 Parallel event "analysis" example.
TYPEDB2 25.097 Variable THREADTY blank if non-DDF transaction.
TYPEDB2 25.090 Support for PK37354 SMF 101 Subtype 4 in DB2 9.
TYPEDB2 25.064 Several QISE variables were wrong.
TYPEDB2 25.020 DB2STATS, QWS3, QWS4 may have reversed contents.
TYPEEVTA 25.255 Support for Action Software's EventAction user SMF.
TYPEEVTA 25.255 Support for Action Sofware's EventAction SMF record.
TYPEFERT 25.133 Support for Williams Data FERRET product user SMF.
TYPEHSM 25.042 Process HSM with different SMF IDs/different SYSTEMs.
TYPEIMS7 25.006 Support for IMS Version 10 (INCOMPATIBLE) IMS log.
TYPEITRF 25.286 Support for ITRF DCR77/DCR78 additions.
TYPEITRF 25.103 Support for IBM OMEGAMON TRF ITRF V550 and V560.
TYPEMQLG 25.280 Support for MQ V6 System Admin Accounting Queue Log.
TYPENDM 25.242 NDM record 'UC' is now output in NDMAE dataset.
TYPENDM 25.081 NDM-CD type 'NM' records now decided into NDMNM.
TYPENDM 25.014 No observations in NDMRT due to incomplete comment.
TYPENMON 25.229 NMON for AIX CPUnn records vary in number.
TYPENMON 25.110 Support for DISKBUSYn for all NMON Disk Monitoring.
TYPENMON 25.104 Full support for NMON, Nigel's Monitor for AIX/unix.
TYPENMON 25.073 Support for LPAR and IOADAPTR Nigel's NMON data.
TYPENTSM 25.282 Support for new NTSMF Objects, Database Mirroring.
TYPENTSM 25.253 Support for new NTSMF objects for MSSQL.
TYPENTSM 25.015 INCOMPATIBLE MXG CHANGE for NTSM WEEK/MONTH BUILDs.
TYPEORAC 25.127 No change in Oracle Version 10, but data is trash.
TYPEPDSM 25.245 CA PDSMAN diagnostic trace records filled //WORK.
TYPEPSYC 25.277 Support for PSYNCH/390 SMF record.
TYPEQACS 25.178 AS400 APAR QAPMDISK with LRECL=456 added new data.
TYPEQACS 25.132 Revisions to AS400 TYPECONF GDES variables.
TYPERACF 25.244 IRRDBU00 Unload '0200' record has two lengths.
TYPERACF 25.134 Support for IRRDBU00 record types 0560,0561,0562.
TYPERMFV 25.309 Support for RMF III CPD, Channel Path Data Table.
TYPERMFV 25.246 Updates for CPU Segmentation changes.
TYPERMFV 25.225 Variable ENCCPUT corrected with zIIP time removed.
TYPERMFV 25.204 CFI Segmentation eliminates RMF III skipped CF data.
TYPERMFV 25.191 Support for RMF Monitor III CFI table enhancements.
TYPERMFV 25.145 RMF III dataset ZRBLCP missing obs for many LPARs.
TYPERMFV 25.079 ZRBLCP dataset had only first LPARs observations.
TYPESAMS 25.055 Support for SAMS objects 2151,2226,2229 and 2231.
TYPESRDF 25.195 Support for EMC's SRDF/A user SMF record.
TYPESYNC 25.117 INVALID ARGUMENT due to incorrect HEX4/HEX3 formats.
TYPETDS 25.052 Support for TDSLink Version 630 ZCOST datasets.
TYPETIMS 25.271 Revisions for TMON/IMS support
TYPETMS5 25.126 Circumvention skip new TMC 'FF20'x Vol Def record.
TYPETMS5 25.084 FILSEQ in TMS.DSNBRECD could be wrong, mult-vol-file.
TYPETNG 25.243 Automatic PROC DELETE of UNKNOWN dataset removed.
TYPETNG 25.235 New Solaris, AIX, and many RedHat objects added.
TYPETNG 25.221 Support for VM Ware VSX Systems in CA NSM records.
TYPETNG 25.181 Support for CA NSM RedHat 4.01 Linux perf cube.
TYPETNG 25.181 Support for CA Unicenter NSM is in MXG "TNG" product.
TYPETPMX 25.239 Support for Thruput Manager SLM and DB2 data.
TYPEVMXA 25.151 180 Error _MPRCAPC not found, DEBUG prints removed.
TYPEVMXA 25.043 Reserved Change Number.
TYPEXAM 25.307 Extraneous PUT from testing removed.
TYPEXAM 25.115 Incorrect memory variables in XMUCDSYS in MXG code.
TYPEXAM 25.082 Support for XAM Release 3.6, many new data.
TYPSCOCR 25.034 Support for CopyCross (now VTF Mainframe 2.1.0) SMF.
UCICSCNT 25.120 CICS record counting separates Resource segments.
UCOMPSOE 25.028 Utility to compare SORTEQUALS and NOSORTEQUALS output
UPCMEMDZ 25.144 ASCII utility to determine memory available to MXG.
UPRINDOC 25.226 Utility prints NAME and LABEL of all variables.
UTILBLDP 25.196 Large &MACKEEP string caused strange results.
UTILBLDP 25.098 %UTILBLDP(BUILDPDB=JES3 ... enhancement.
UTILBLDP 25.071 Products that need deaccumulation now protected.
UTILBLDP 25.065 Default list of ASUMxxx to be included, MXGINCL=.
UTILCSV 25.197 %UTILCSV creates a CSV (or TAB) Delimited flat file.
UTILEXCL 25.256 Macro variable &MXGDEBUG revised for IMACEXCL plus!
UTILEXCL 25.193 MXG 25.08 ONLY: LABEL IMACICU3 NOT FOUND.
UTILLPDS 25.136 Utility to count used/defined PDS Directory Blocks.
VMAC110 25.041 Reserved Change Number.
VMACDB2 25.075 QBGL variables in DB2 V8.1 supported, were wrong.
VMXG70PR 25.293 SMF70GIE is now set from STARTIME=DURATM after shifts
VMXG70PR 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
VMXGDUR 25.044 Interval= QUARTER, SEMIANN, ANNUAL now supported.
VMXGINIT 25.231 Unresolved &ARRAYRMF is SAS V8.1 or WPS was used.
VMXGINIT 25.143 New MXGMISS macro variable changes TYPE71 SWAPrates.
VMXGPRAL 25.028 Print All utility now compares all datasets in LIBs.
VMXGRMFI 25.069 Service Class Names can be "wild-carded"
VMXGSUM 25.248 New &LNSUMOUT=8 will make all output to length 8.
VMXGUSE 25.067 Revised to invoke _STY70; UTILBLDP recommended.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 25.
====== Changes thru 25.309 were in MXG 25.25 dated Jan 28, 2008=========
Change 25.309 Support for RMF III CPD, Channel Path Data Table, creates
ASMRMFV new ZRBCPD dataset.
CLRMFV
ADOCRMFV The RMFV documentation in DOCRMFV and the documentation
EXZRBCPD in the CLRMFV CLIST (without any code changes in CLIST)
IMACRMFV have been updated to match ASMRMFV's updated.
VMACRMFV
VMXGINIT
Jan 28, 2008
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.308 SAS V8.2-V9.1 %MACRO compiler accepts %ELSE %THEN %DO;
ANALDB2R syntax, but the documented syntax is only %ELSE %DO;
VMACMVCI The SAS Language compiler never accepted ELSE THEN DO;
VMXGSUM In early tests of SAS V9.2, its %MACRO compiler rejected
Jan 28, 2008 the extra %THEN, so all three accidental, unintended MXG
Sep 16, 2008 %ELSE %THEN %DO statements have been corrected.
If you have an old member in your "USERID.SOURCLIB", the
error message you will get with SAS V9.2 will be:
ERROR: THERE IS NO MATCHING %IF STATEMENT FOR THE %THEN.
A DUMMY MACRO WILL BE COMPILED.
Thanks to MP Welch, SPRINT, USA.
Change 25.307 Debugging PUT printed _N_= COL=nnnn PRCAPM for every one
VMACXAM of those segments, but had no impact on output data.
Jan 25, 2008 Remove the PUT statement after WHERE ('PRCAPM').
Thanks to Rodger Foreman, TransUnion, USA.
Change 25.306 Change was in error, did not support PK38033, and was
VMAC102 replaced by Change 26.011 which does support the APAR.
Jan 23, 2008 And the original change text was WRONG, as there was
Feb 8, 2008 NOTHING wrong with IBM SMF 102 IFCID 22 with PK38803
records; the records matched the DSECT which I misread.
Change 25.305 Error in %UTILBLDP with USERADD=TMNT/nnn + BUILDPDB=YES.
UTILBLDP Because TMNT processing is already in BUILDPDB, there was
Jan 23, 2008 special handling in the USERADD= logic, but in this case
Jan 27, 2008 it incorrectly didn't create the MACRO _IDTMNT nnn % that
it should have, so, while all TMNT datasets were created,
they all had zero observations, unless you had defined
your TMNT Record ID _IDTMNT in IMACKEEP/IMACTMNT.
The logic in UTILBLDP is corrected for all USERADDs,
whether or not they are already in BUILDPDB:
USERADD=TMNT/nnn, creates MACRO _IDTMNT nnn %
which will override any IMAC tailoring.
USERADD=TMNT, does not create _IDTMNT, but ensures
TMNT records are processed.
-Jan 27: Added support for USERADD=100 101 alias for DB2.
-In testing the UTILBLDP invocation in the new COMPINTV, I
had %MACRO errors about non-numeric in a %EVAL, (whose
clarity may be a separate SAS issue!), but which were the
result of incorrect code ordering in my COMPINTV program.
When %UTILBLDP has MACKEEPX= argument text with old-style
macros that you want to redefine AND execute in this one
step, then your MACRO _XXXXXXX ... % statements must
be located after the %UTILBLDP(); statement and before
the %INCLUDE statement that executes the UTILBLDP output:
statement that executes the UTILBLDP output:
%UTILBLDP(MACKEEPX= MACRO _ETY70 _SETTIME %, .... );
RUN:
MACRO _SETTIME STARTIME=FLOOR(STARTIME/900); %
RUN;
%INCLUDE INSTREAM;
If the old style macros are defined before %UTILBLDP is
executed, then they are expanded inside the macro
language when the %MACRO UTILBLDP is being compiled,
which can result in unexpected failures. If you move the
definition to after %UTILBLDP, only the name of the macro
is passed to the UTILBLDP output which works as expected.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 25.304 APAR OA23679 documents possible errors in BLKSIZE in SMF
VMACEXC1 30 records when DDCONS=YES is specified. Since MXG has
Jan 23, 2008 ALWAYS recommended DDCONS=NO and NEVER to use DDCONS=YES,
this shouldn't have impact. But when YES is specified,
IBM now says the consolidated SMF 30 record contains the
first non-zero BLKSIZE value from those DDs in SMF30BSZ,
the original 4-byte blocksize field, but the newer 7-byte
SMF30BXS blocksize field, contains the BLKSIZE value from
the last DD in the consolidation, which could be valid or
zero. MXG stored SMF30BSZ into BLKSIZE, but then INPUT
BLKSIZE from SMF30BXS when it existed, even when zero.
Now, BLKSIZE is set to SMF30BXS ONLY when it is larger
than SMF30BSZ.
Change 25.303 -Extraneous PROC PRINT from testing was removed.
VMXG70PR -Calculation of LPARCPUS could be non-integer value, for
Jan 22, 2008 example, 11.99995682 instead of 12. Algorithm refined.
Jan 28, 2008
Thanks to Clayton Buck, UniGroup, USA.
Thanks to William Wai Lun WONG, HSBC, HONG KONG.
====== Changes thru 25.302 were in MXG 25.25 dated Jan 21, 2008=========
Change 25.302 Compare all CPU variables from SMF 30,70,72,100,101,110s.
COMPINTV Single pass of SMF creates only the needed datasets with
UTILEXCL a "fast read" of SMF records keeping only the CPU and key
Jan 21, 2008 variables to minimize the run with a tailored %UTILBLDP
Jan 27, 2008 and MACKEEPX overrides to create two summary datasets:
Jan 30, 2008 PDB.INTVSRVC by SYSTEM STARTIME SRVCLASS 30+72
PDB.IN307072 by SYSTEM STARTIME 30+70+72
PDB.INALLCPU by SYSTEM STARTIME 30+70+72+100+101+110
Fast read: 6 GB SMF data, 2 Minutes CPU, 10 Min Elapsed
The type 30 SMF interval and type 72 RMF service class
create the PDB.INTVSRVC with CPU times by service class.
Those data and the CPUACVTM from TYPE70 are combined into
the PDB.IN307072 SMF+RMF CPU time for each interval. Then
the CICSTRAN and DB2ACCT transaction CPU times plus the
interval CICDS dispatcher and DB2STATS statistics CPU
times are added from the 100, 101, and 110 records to
create the PDB.INALLCPU with ALL possible CPU variables,
summed for each SYSTEM for each STARTIME.
Several PROC MEANS summary output reports are printed.
The SRVCLASS-level SMF30 and RMF72 summary CPU times
should match closely for most service classes, but there
can be significant differences in which "SRVCLASS" CPU
time is recorded. For example Enclave CPU time in SMF
may be in the SRVCLASS of the address space that started
the enclave, but in RMF that same enclave CPU time gets
put in the SRVCLASS where that enclave was classified.
And we've seen enclaves in two SRVCLASS in SMF30 while
spread across three SRVCLASS in RMF72. It can get messy!
The STARTIME-level interval summary should match RMF and
SMF totals, for the CPU fields that we expect to match,
and will show how much of that CPU time is captured in
the DB2 and CICS interval data as well, but its accuracy,
and the accuracy of the SRVCLASS-level data is dependent
on the synchronization of your SMF and RMF data.
The MACRO _SETTIME default expects 15 minute intervals
and SYNC(0), but can be tailored to your intervals.
You can get the totals of all CPU times for all of SMF
records in a single output observation per SYSTEM by
setting STARTIME to a single value for all records.
But the summary of the CICSTRAN and DB2ACCT times
can always be skewed by a long-running transaction,
or if SYNC59 is in the data (because not all CPU
records obey SYNC - RMF/SMF 30 does, CICS doesn't.
Jan 30: If you use COMPINTV and have an IMACEXCL member,
COMPINTV fails when it sees the second _VCICTRN
definition in your IMACEXCL. If you will insert
MACRO _VCICTRN _VCICTRN %
immediately before the existing MACRO _VCICTRN,
then COMPINTV will not fail. And, fortunately,
by accident, the MACRO _VCICTRN defined in the
MACKEEPX in UTILBLDP will be used for CICSTRAN,
(and it's required for the rename of STRTTIME to
STARTIME and to minimize disk space), because
MACKEEPX is instanced after IMACEXCL was read.
Syntax corrected in Change 26.020.
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.301 Due to typos that had DB where OB should have been, all
VMAC102 of the QW1145OB-QWF145OB variables were wrong (they had
Jan 21, 2008 the DB database value instead of the OB Object value).
Thanks to Giuseppe Giacomodonato, E.P.V. Technologies, ITALY.
Change 25.300 PDB.ASUMTAPE could have blank SYSTEM and VOLSER, DEVNR
ASUMTAPE missing when the SYSLOG Mount and Keep messages had the
Jan 21, 2008 same timestamp, and the Keep was seen first. Adding the
variables SMFTIME SYSLTEXT forces the KEEP to be first
to complete the prior event, but adding .001 seconds to
IF SYSLTMNT GT . THEN EVENTIME=SYSLTMNG+.001;
was also needed to force the correct sequence.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.299 Type 42 Subtype 18 CF Cache Partition Summary Section for
EXTY42P3 Directory/Element Ratio Data now creates new dataset:
IMAC42 DDDDDD DATASET Description
VMAC42 TY42P3 TYPE42P3 RLS CF DIRECTORY/ELEMENT RATIO
VMXGINIT which had been added in z/OS 1.8 but overlooked.
Jan 21, 2008
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.298 ADOCxxxx members that existed have been updated with new
ADOCs variables. New ADOCS member lists the VMACxxxx products
Jan 20, 2008 for which an ADOC member does not exist.
Change 25.297 Change 25.196 caused ERROR: CHAR OPERAND IN THE %EVAL ...
UTILBLDP when either or both MACFILE and MACKEEP were used and had
Jan 19, 2008 more than 65 characters of text.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.296 All ADOCxxxx members were updated with current CONTENTS.
ADOCs
Jan 19, 2008
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 25.295 The COMPALL program compiles all of the VMACs for all SMF
COMPALL records in a single data step, and is back in MXG's QA
VMACIPAC tests, now that it can be compiled! It was used in early
VMACOMCI MXG Versions, testing only the IBM SMF records, by about
VMACSAMS Version 3 (1987!), it needed more virtual storage than I
Jan 19, 2008 could get back then, and it was set aside. It now brings
in all of the VMACs for all IBM and USER SMF records, and
it detected numeric-character variable conflicts in one
temp variable that was renamed in VMACIPAC, and two kept
variables were renamed to avoid the exposure to error,
if you were to add these and certain other SMF records to
your BUILDPDB job:
-VMACSAMS. Variable CLUSTR replaces numeric CLUSTER.
-VMACOMCI. Variable DIFTYPEF replaces char DIFTYPE.
The current COMPALL requires an 1150 MB Region on z/OS.
====== Changes thru 25.294 were in MXG 25.12 dated Jan 17, 2008=========
Change 25.294 Label PARTNCPU='TOTAL*NUMBER OF*CPUS*IN THE CEC' replaces
VMAC7072 the previous confusing "CPUS IN THE PARTITION" text that
VMXG70PR goes back to the days when we "physically partitioned" a
Jan 17, 2008 "hardware platform". The variables PARTNCPU PLATCPUS,
NUCPSCPU and temp variable NRCPSCPU have always counted
the CP/CPU engines in this CEC/CPC/platform/box/etc.
If there are no LPARNAME='PHYSICAL' records in TYPE70PR
(because your outsourcer turned them off?), the variables
PARTNCPU, PLATCPUS, NUCPSCPU and CPCNRCPU will be zero.
And the specialty engine counters NRIFACPU, NRZIPCPU, etc
will also always be zero. And, in the ASUM70PR/ASUMCEC
datasets, only your own LPARn variables are populated.
Finally (?), CPCMSU in PDB.RMFINTRV is also zero.
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 25.293 SMF70GIE is now set from STARTIME+DURATM after SYNC59 to
VMXG70PR provide a more stable and consistent value for the
Jan 17, 2008 expected end of the interval. See Change 25.270.
Change 25.292 Internal logic was revised so when INTERVAL= is used, the
ANALRMFR variables LRDY00-LRDY11 are added to the MEAN= parm for
Jan 17, 2008 Cpu Reports.
Dollarsigns were needed in the below array definitions.
-ARRAY INICT05 $ STFBIT05(' ') ;
-ARRAY INICT05 $ STFBIT06(' ') ;
-Also, updated for 54 engines z/OS 1.9.
Thanks to Clay Duncan, Toyota, USA.
Thanks to Jerry Cobb, American Century, USA.
Change 25.291 DB2ACCT variable QWACUDCP, CPU time in DB2 User Functions
VMACDB2 is now included in MXG variable DB2TCBTM, as documented
Jan 17, 2008 in DB2 Technical Note 4 (PAR.TASKS) in Newsletter FIFTY.
Change 25.290 Variable JOBCLASS is $8 in JES3 and $1 in JES2, but MXG
BUIL3005 had INPUTs with both lengths, and that caused SAS WARNING
VMAC26J2 messages that the variable's length was CHANGED; these
VMAC26J3 warnings will set Return Code 4 in SAS Version 9.2, so
VMAC30 this change revised how MXG handles JOBCLASS for JES3
Jan 17, 2008 to keep the full 8-byte length. The contents of the
Jan 20, 2008 SPIN library are also changed; JOBCLASS is no longer kept
in SPIN26, and JOBCLAS8 is kept instead of JOBCLASS in
SPIN30_1, SPIN30_4, and SPIN30_5.
Note: This change was revised in MXG 25.25.
Do NOT use MXG 25.12 with JES3 BUILDPD3.
Thanks to MP Welch, SPRINT, USA.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.289 -Nigel's Monitor for AIX/LINUX variable NRCPUS in NMONINTV
VMACNMON dataset was one-tenth correct; the INFORMAT 6.1 should be
Jan 17, 2008 6.0. The AAACPU2 count was correct in NMONAAA dataset.
-Support for ERROR: records, sort of: they are printed on
the log in full when read.
Thanks to Michael W. Wolke, Boeing, USA.
Thanks to Steve Olmstead, Northwestern Mutual Trust, USA.
Change 25.288 Variable SMF70GJT is already on Local zone, so the adding
VMAC7072 of the GMT offset in MXG created incorrect datetimes.
Jan 16, 2008 Jan 26: a second instance was removed.
Jan 26, 2008
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.287 Support for SMF 122, Tivioli Allocation Record creates
EXT122IT six new datasets:
EXT122AL DDDDDD DATASET DESCRIPTION SUBTYPE
EXT122WA
EXT122FA T122IT T122INIT ATAM ASID INIT/TERM 0,4
EXT122DY T122AL T122ALOC ATAM SUCCESSFUL ALLOCATE 1
EXT122ON T122WA T122WAIT ATAM WAIT/NOHOLD/ALOCFAIL 2,3,5
IMAC122 T122FA T122FAIL ATAM VARY ONLINE FAILURE 6
TYPE122 T122DY T122DYNA ATAM UNSUPPORTED DYNALLOC 7
TYPS122 T122ON T122VONL ATAM VARY ONLINE TO WAIT 8
VMAC122
VMXGINIT
Jan 16, 2008
Change 25.286 Support for new ITRF variables in subtype '10'x and '18'x
EXITRCRG records and new subtype '20'x created by ITRF DCR77/DCR78
EXITRCRG (PTFs UA36089,UA37073). New variables added:
IMACITRF Dataset New Variables
VMACITRF ITRFMSG
VMXGINIT RECTOK ='FULL*RECOVERY*TOKEN'
Jan 16, 2008 IMSID ='IMS*ID'
COMN ='COMMITS*DURING*THIS*SCHEDULE'
OASN ='ORIGIN*APPLICATION*SEQUENCE*NUMBER'
SUSEC ='SERVICE*UNITS*PER*SECOND'
ITRFDB2
CPUDB2TM='IN DB2*CPU*TIME'
New dataset ITRFCRGN, 'CONTROL REGION CPU TIME', which is
created once each 24 hours with the daily total CPU Time
in the IMS Control Region:
Dataset New Variables
ITRFCRGN
CPUCRGTM='CONTROL*REGION*DAILY*CPU TIME'
IMSNAME ='IMSID*FOR THE*IMS SYSTEM'
INTBTIME='INTERVAL*START*DATETIME'
INTENDTM='INTERVAL*END*TIME'
The IMSNAME is retained from the prior ITRF record, as
the '20'x record contains only the time fields.
Change 25.285 The VALIDVARNAME=V7 option added by Change 25.267 to WPS
CONFIGW2 CONFIGW2 file caused ERROR: OPTION VALIDVARNAME NOT KNOWN
Jan 15, 2008 so it has been removed from CONFIGW2 member. That option
is the internal WPS default, but the option name is not
supported by WPS.
Change 25.284 Change 25.189 was not completely implemented.
ANALDB2R -Using %ANALDB2R with new PDBOUT=YES printed COPIED TO YES
READDB2 and did not perform as documented; an additional test for
VFMT102 AND &PDBOUT NE YES was required to support the new YES.
Jan 16, 2008 But then using PDBOUT=YES caused messages:
ERROR: Libname PDB is not assigned.
ERROR: Libname _VDB2A is not assigned.
when no //PDB DD or LIBNAME PDB was allocated.
That is an error. When PDBOUT=YES is specified, it
writes all DB2 output datasets to their default (or the
tailored) DDname, and PDB is the default for sorted DB2
datasets.
-But then using no PDBOUT operand, which should write
all DB2 output to //WORK, still caused
ERROR: Libname PDB is not assigned.
because READDB2 had an old segment of code that should
have been removed by Change 25.189, now corrected, so
that PDBOUT= null does NOW write only to //WORK.
-Warnings about T102S017 DOES NOT EXIST are removed with
enhancements made in VFMT102.
Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA.
Thanks to Robert Carballo, Office Depot, USA.
Change 25.283 An extraneous ); was inserted in %UTILBLDP output (on a
UTILBLDP separate line several lines after %LET EPDBOUT= text) if
Jan 15, 2008 both EXPDBOUT= and INCLAFTR= were specified.
Thanks to Robert Carballo, Office Depot, USA.
Change 25.282 Support for seven new NTSMF Objects:
EXNTCICP DDDDDD DATASET DESCRIPTION
EXNTCILI NTCICP CITRIXCP CITRIX CPU UTILIZATION MGMT USER
EXNTHSMG NTCILI CITRIXLI CITRIX LICENSING
EXNTHSRV NTHSMG HEALMGMT HEALTH SERVICE MANAGEMENT GROUPS
EXNTOPSM NTHSRV HEALSERV HEALTH SERVICE
EXNTSECT NTOPSM OPSMGRCN OPSMGR CONNECTOR
EXNTSQDM NTSECT SECTIKAU SECURE TICKET AUTHORITY
IMACNTSM NTSQDM SQLDATMI SQLSERVER:DATABASE MIRRORING
VMACNTSM or MSSQL:DATABASE MIRRORING
VMXGINIT The SQLSERVER and MSSQL Database Mirroring records are
Jan 15, 2008 both output in SQLDATMI dataset. The MSSQL records will
populate variable SQLDBNAM='SQL*SERVER*DATABASE*NAME'
while SQLDBNAM will be blank in the SQLSERVER records.
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 25.281 Cosmetic. If RMFINTRV definitions fall thru to create any
VMXGRMFI work in "OTHER", a new MXG NOTE alerts you to the SYSTEM
Jan 15, 2008 and SRVCLASS that fell thru your workload definitions.
Jan 28, 2008 This is not an error, but it is recommended that all of
your work be mapped to a unique workload variable in the
RMFINTRV dataset. The first ten workload names that fell
thru are printed on the SAS log.
-Cosmetic. Some ERROR:NEGATIVE CPU OVERHEAD for RMF 70-72s
were in intervals in which a Policy Activation occurred,
and data for those intervals are always wise to ignore.
There is no flag bit that activation occurred during this
interval, but the time of policy activation, R723MTPA, is
now printed along with STARTIME and DURATM of the raw RMF
record, so you can see if there was a policy activation
to blame. Variable CPUOVHTM in PDB.RMFINTRV will be
negative, non-missing value. to identify the intervals
that printed that log message.
This message may also be seen in intervals in which the
number of hardware CPUs was altered.
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.280 Support for Websphere MQ V6 System Admin Account Queue
EXMQLGMD MQMD Structure in MQ Accounting Log non-SMF file creates
IMACMQLG the new MQLGMQMD Dataset with the Descriptor fields for
TYPEMQLG each event. This structure is documented on page 51 in
TYPSMQLG Chapter 7.
VMACMQLG
VMXGINIT
Jan 11, 2008
Change 25.279 SMF 85 subtypes 38, 39, and 40 now create three datasets
EXTY85RE TYPE85RE, TYPE85IB, and TYPE85TR. Archaic test records
EXTY85IB from year 2000 with shorter records were protected.
EXTY85TR
VMAC85
VMXGINIT
Jan 10, 2008
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.278 PDB.TYPE70 variables PCTZIBYx were created in MXG 24.02
VMAC7072 but were accidentally not kept after MXG 24.06; they are
Jan 10, 2008 now reinstated. PCTZIBYx/PCTIFBYx are the "MVS" values,
variables PCTCIBYx/IFATYPE are "LPAR" values for zIIP and
zAAP usage as noted in Change 24.184.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.277 Support for PSYNCH/390 SMF Record from M-Tech product
EXPSYC39 creates PSYNC390 dataset.
FORMATS Only one of the four flag variables will have a value in
IMACPSYC one record, but it's now too late to change the MXG code.
TYPEPSYC May 5: Formats were updated.
TYPSPSYC
VMACPSYC
VMXGINIT
Jan 10, 2008
May 5, 2008
Thanks to Joe Faska, Depository Trust, USA.
Change 25.276 Support for APAR OA20043 DFSMS DYNAMIC VOLUME EXPANSION
VMAC22 adds these two variables:
Jan 9, 2008 SMF22CYL='DEVICE*HIGH*CYLINDER'
SMF22PCP='DEVICE*HIGH*CYLINDER*PREVIOUS'
to the TYPE22_A dataset.
Change 25.275 -Strange error messages can occur if you did not update
VMACTPMX your IMACTPMX member with your SYSPLEX and SYSTEM names
Jan 4, 2008 and mapping tables; messages like these:
Jan 9, 2008 >>ERROR>> MXG/SAS VARIABLE TPMXPLEX NOT ASSIGNED
CORRECTLY USING LOCAL PROC FORMAT $MXTPMPX IN
>>ERROR>> EXIT MEMBER MXG.PROD.USERID.SOURCLIB(IMACTPMX).
>>ERROR>> RUN ABORTED. CORRECT THE FORMAT AND RESTART.
resulted when data from SYSTEMs not in IMACTPMX was read.
Adding an entry for each SYSPLEX and for its SYSTEMs in
IMACTPMX solved those errors.
-Variable JXJBSJ4 was incorrectly input as $EBCDIC, but it
is a hex flag field, now input and formatted $HEX8.
Jan 9: A debugging PUT was removed, VGETJESN %INCLUDEd to
create variable JESNR from JCTJOBID for subtype=5.
The current level: TM V6R1.2 at PTF TMT6116; the
fix for the truncated records is APAR TR61390, but
you are at PTF TMT6118, the APAR is TR61391.
Thanks to James D. Lieser, UHC, USA.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.274 A GDG member that had DSNAME .VnnnnGOO' (alpha oh) caused
VMAC6156 INVALID DATA warning message when MXG INPUT the oh's as a
Jan 2, 2008 numeric. Adding the double question mark modifier to the
INPUT function eliminates the warning and causes GENNO to
be a missing value:
IF ENTTYPID='H' THEN DO; /*GDG, GET GOOVO GEN/VER NUM*/
GDGLEN=LENGTH(ENTRNAME);
VCK =SUBSTR(ENTRNAME,GDGLEN-2,1);
DOTGCK=SUBSTR(ENTRNAME,GDGLEN-8,2);
IF DOTGCK='.G' AND VCK='V' THEN DO;
GENNO=INPUT(SUBSTR(ENTRNAME,GDGLEN-6,4),?? 4.);
VERNO=INPUT(SUBSTR(ENTRNAME,GDGLEN-1,2),?? 2.);
END;
END;
Scott had provided this elegant alternative that uses the
TRANSLATE and SCAN functions, worthy of sharing:
IF ENTTYPID='H' THEN DO; /*GDG, GET GOOVO GEN/VER NUM*/
LASTNODE = SCAN(ENTRNAME,-1,'.');
IF TRANSLATE(LASTNODE,'%%%%%%%%%%','0123456789') =
'G%%%%V%%' THEN DO;
GENNO=INPUT(SUBSTR(LASTNODE,2,4),4.);
VERNO=INPUT(SUBSTR(LASTNODE,7,2),2.);
END;
END;
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.273 APAR PK38803 incompatibly alters SMF 102 IFCID 22 Record.
VMAC102 -These variables were INPUT as fixed length text, but they
Jan 2, 2008 can be longer, and can be relocated in the SMF record.
MXG now detects the new OFFSETs and INPUTs $VARYING32:
Variable Fixed Length Label
QW0022CN $EBCDIC18. /*TABLE*CORRELATION*NAME*/
QW0022CR $EBCDIC8. /*TABLE*CREATOR*/
QW0022TN $EBCDIC18. /*TABLE*NAME*/
QW0022AC $EBCDIC8. /*QW0022XC:ACC INDEX CREATOR*/
QW0022AN $EBCDIC18. /*qw0022XN:INDEX NAME*/
(Note: 22AC and 22AN were original DSECT names)
Debugging is enabled for the first 10 instances that have
varying length fields on the MXG log, so I can validate.
-Records with QW0022PL=. have many missing values, and the
$CHAR vars formatted with $HEX have '20'x vice '00'x. The
obs was created from a second record, after a legitimate
instance with 6 observations, and has only R1O segment.
-_S102022 SORT MACRO revised and tested for dupe removal.
Jan 23, 2008: Change 25.306 is now required for PK38803.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.272 The Group Capacity Name SMF70GNM is now populated only if
VMAC7072 bit 1 of SMF70PFL is ONE, as that bit indicates this LPAR
Dec 21, 2007 is part of a capacity group of that name. If bit 1 is
zero, SMF70GNM is blanked, because some z/OS 1.8 data had
non-blank SMF70GNM when bit 1 was zero. While I could
have created a separate variable for bit 1 to identify
this LPAR is in a capacity group, with this change there
is no need for a second variable; now, IF SMF70GNM GT ' '
then this LPAR is in that Capacity Group, otherwise not.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.271 Corrections for TMON/IMS support.
VMACTIMS -CM5612TM is a datetime variable, now format DATETIME21.2.
Dec 21, 2007 -CMCOMP, CPCOMP are formatted HEX8.
-XXTOKN Token variables are LENGTH 5 and HEX8 format.
-CMGMTA value's second division by 4096 was removed.
-ENDTIME is already on Local time, its GMT correction was
removed.
-These variables were incorrectly input as &PIB.8.6 vice
&PD.8.6, causing too-large values when non-zero:
TIMSCH: CMTMEIO CMTMEPL CMMINT CMMPOL CMMSCH
TIMSCM: CMTMEIO CMTMEPL CMMINT CMMPOL CMMSCH
TIMSCN: CNTMEIO CNTMEPL CNMINT CNMPOL CNMSCH
TIMSCP: CPTMEIO CPTMEPL CPMINT CPMPOL CPMSCH
TIMSCT: CTTMEIO CTTMEPL CTMINT CTMPOL CTMSCH
These fields were correctly documented as Packed in the
DSECT, but overlooked originally as they all were zero.
-Variables input &PIB.8.6 that are NOT GMT offsets are NOT
then divided by 4096: e.g., CTRSPTME when CTSDATE and
CTSPDATE are both non-missing matches their delta.
However, when CTSDATE is missing, CTRSPTME contains
the value of CTSPDATE shifted right by three nybbles,
i.e. a very large and very invalid data.
This problem will be passed to Landmark for correction,
but is circumvented by MXG setting CTRSPTME to missing.
-Five CPU variables are documented on the DSECT as (MILS)
for milliseconds and have always been input as &PIB.4.3:
CHCUMCPU CMCUMCPU CNCUMCPU CPCUMCPU CTCUMCPU
-But eleven REGION*CPU*TIME variables have no clue as to
their decimal place location:
CHCTCPUT CHDBCPUT CHDLCPUT CHIRCPUT CHCQCPUT
CJTXNCPU
CNCTCPUT CNDBCPUT CNDLCPUT CNIRCPUT CNCQCPUT
I have arbitrarily input them as &PIB.4.3 (MIL) but this
must be validated.
-These variables are assumed input of &PIB.4.6 to be like
their xxDUR counterparts, but this must be validated:
CMSQ6GM CMACCQ6 CNSQ6TM CNACCQ6 CPSQ6GM CPACCQ6
CUSQ6GM CUACCQ6
Thanks to Warren Waid, JC Penny, USA.
Change 25.270 For ASUM70PR, IMACRMFI tailoring with INTERVAL=DURSET
ASUM70PR can NOT be used, and output datasets created with that
VMXG70PR tailoring will be invalid if STARTIME is changed in your
Dec 19, 2007 IMACRMFI member and you used the default ASUM70PR, which
specified INTERVAL=DURSET as its default prior to this
change. You must use INTERVAL=HOUR, QTRHOUR, etc. in
in your %VMXG70PR invocation in your ASUM70PR member to
specify the desired interval.
For RMFINTRV, you can still use IMACRMFI/DURSET, because
it is a per-SYSTEM dataset, but I still recommend you use
INTERVAL=xxxx and not use IMACRMFI, for clarity.
Here's the problem with DURSET/IMACRMFI for ASUM70PR:
Because ASUM70PR summarization combines SYSTEMs that
can have different STARTIME, it uses and resets the
value in SMF70GIE. When I detect INTERVAL=DURSET, I
have to detect if STARTIME was changed in IMACRMFI, and
if so, then MXGDURTM (that you added in your IMACRMFI
per Change 25.150) must be added to STARTIME to create
SMF70GIE. I though I could use this code:
OLDSTART=STARTIME;
_DURSET;
IF STARTIME NE OLDSTART THEN DO;
and that worked with the first test case.
However, I now discover that the test will always fail
if STARTIME is already exactly on the interval, i.e.
STARTIME=DHMS(DATE,HOUR,0,0); for HOURly intervals will
equal OLDSTART when OLDSTART is exactly on the hour.
Since I can only detect some, but not all, changed obs,
I cannot support IMACRMFI and DURSET in ASUM70PR.
This is a rare problem; using INTERVAL=value in the
ASUM70PR invocations of %VMXG70PR and RMFINTRV invokes
of %VMXGRMFI is self-documenting and works safely,
so this change is mostly this change text and updates
to the INTERVAL= documentation comments in the cited
members.
Change 25.269 Support for SMF 50 subtype 4 OSA-MPC VTAM record adds new
EXTY50 observations with ATTCHTYP=4 to TYPE50 dataset, but only
FORMATS if this DEV had activity during this interval; the logic
VMAC50 that deletes zero-activity intervals is in the EXTY50
Dec 22, 2007 if you should want to output all of those observations.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
====== Changes thru 25.268 were in MXG 25.11 dated Dec 7, 2007=========
Change 25.268 The date in MXG 25.11 was typo'ed as year 2006 in several
AAAAAAAA members, but the member CHANGES was correct with 2007.
COPYRITE The dates were corrected and the ftp site was refreshed
Dec 7, 2007 on Tuesday with the Dec 7, 2007 date.
Thanks to Mike Ryan, Acxiom, USA.
Change 25.267 If the option VALIDVARNAME=V6 is set in your site's SAS
AUTOEXEC options, a temporary variable in VMAC78 caused
AUTOEXEU ERROR: The variable named N78HCNTCN contains more than
AUTOEXEW 8 characters
CONFIGV8 because the V6 value restricts the length of variable's
CONFIGV9 names to be 8 bytes or less.
VMAC78 MXG tests with the default VALIDVARNAME=V7, which allows
Dec 7, 2007 variable names to be up to 32 characters.
But almost all MXG variables will always be 8-bytes or
less, because I think shorter, encoded, albeit cryptic,
variable names are easier for PROGRAMMERs to work with.
But because some new open systems code was written with
their long names, and because change the default in the
MXG members can do no harm but can avoid future errors,
VALIDVARNAME=V7 has been added to MXG CONFIGVx and the
AUTOEXEx members.
Thanks to Andreas von Imhof, Rabobank Nederland, THE NETHERLANDS.
Change 25.266 The MXG ERROR.VMAC110... messages are updated to print
VMAC110 the CICS/TS 3.2 expected values.
Dec 6, 2007
Thanks to MP Welch, SPRINT, USA.
Change 25.265 Required for DB2 Version 9.1, DB2TCBTM correction.
VMACDB2 DB2TCBTM could be significantly less than it should be in
Dec 7, 2007 non-rollup observations in DB2ACCT. The CPU time delta
QWACEJST-QWACBJST was NOT included in DB2TCBTM when
QWACBJST was zero (and DB2PARTY NE 'R') in DB2ACCT.
And the loss has only been reported at sites with zIIP
engines for their DB2 systems.
Prior to DB2 V1.9, IBM DSNWMSGS documentation noted that
QWACBJST=0 meant that CPU timing was in error, and so MXG
had always NOT included that QWACEJST-QWACBJST delta in
MXG's DB2TCBTM variable. Accidentally, DB2TCBTM for the
Rollup Records (i.e., DB2PARTY='R") has always included
the QWACEJST when QWACBJST=0.
Note that
DB2TCBTM=SUM(DB2TCBTM,QWACSPCP,QWACTRTE);
is the final value output in DB2ACCT dataset.
Now, IBM DB2 Level 2 Support has confirmed in a reply to
an MXG site that QWACBJST=0 is valid and the QWACEJST in
those records should be included in DB2TCBTM, adding that
"If we have an agent running 100% on a zIIP, QWACBJST
will be zero." It was only after that reply from IBM DB2
Support that I looked to see the CPU timing not is not in
DSNWMSGS in the DB2 V 1.9 Macro Library.
To see if this change impacts your DB2ACCT dataset, you
can measure how much DB2TCBTM was lost with
PROC MEANS SUM DATA=PDB.DB2ACCT
(WHERE= (DB2PARTY NE 'R' AND QWACBJST=0));
VARIABLES QWACEJST;
TITLE TOTAL QWACEJST NOT INCLUDED IN DB2TCBTM;
If no observations are selected, no CPU time was lost.
Several folks at DB2 Support were ultimately involved in
the problem, providing this information about PK46171:
- Class 1 CP, zIIP, and elapsed times could be incorrect.
Because we don't get a 'start accounting' call:
1. QWACBSC would be from the last transaction to see a
start
2. QWACBJST would be the CP time from the last
transaction to see a start -- this can result in
this number being unrelated to QWACEJST
3. QWACCLSL_ZIIP would be effected similarly to
(QWACEJST - QWACBJST) since it is internally
calculated from a start ziip time that can be
unrelated to the end time
4. QWACAJST and QWACCLS2_ZIIP are probably not
noticeably effected although there could be an
extremely small amount of time that is not counted.
Above symptoms only occur in DRDA work when
connection-reuse is in effect. I can't see any
record said lacking of PK46171 will directly make
qwacbjst to zero.
- And this note on why QWACBJST can validly be zero.
From dump, we can see CPUTIME is 0 but zIIP time is >0
and this is a zIIP eligible distributed SRB. Thus
this is working as expected. The CP time can be 0
since all time might be on a zIIP at the time of the
first clocking. As long as either the CP or the zIIP
time > 0, that is normal.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY
Thanks to Derrick Haugan, MetLife, USA.
Thanks to Lisa Ouellette, Wachovia, USA.
Thanks to Jim Lazowski, NAV-INTERNATIONAL, USA.
Thanks to Uncha, DB2 Level 2 Support, GERMANY.
Thanks to Ronald Lobodzinski, DB2 Level 2 Support, USA.
Change 25.264 For consistency with MXG tailoring macro variables, new
IMACSPCK &MACSPCK is defined in VMXGINIT and referenced in the
VMXGINIT IMACSPCK tailoring member, though unlikely to be used.
Dec 5, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.263 Some DD DUMMY statements for INFILEs for new products
JCLTEST8 were missing in the TESTOTHR/TESSOTHR steps, and there
JCLTESS8 were inconsistencies in the TEST vs TESS members that
JCLTEST9 were corrected in these four test members. The main
JCLTESS9 purpose of these TEST/TESS jobs is to confirm that your
Dec 4, 2007 "USERID.SOURCLIB" tailoring did not cause any errors in
the TESTIBMx steps, so a failure in a subsequent step due
to a missing DD statement should not prevent you from
moving to JCLPDB8/JCLPDB9 testing.
Thanks to Eric Barnes, Scottish and Southern Energy, SCOTLAND.
Change 25.262 The 233 DDU files needed for ITRM sites to create ITRM
TYPETNG table definitions for each of the 233 datasets built
Dec 4, 2007 by MXG's TYPETNG (for CA's NSM product, formerly TNG).
There is also the cpddudef.sas program that is used
to generate all table definitions,. You will need to
replace &YOUR_PDB_PATH & Your_DDU_PATH in cpududef.sas
with your paths. The creation was run under a SAS ITRM
interactive session.
The itrmtng.sas file contains all 234 files in IEBUPDTE
format; the individual files can be created by using the
IEBUPDTE.SAS program in the MXG Source Library with the
itrmtng.sas file as it's input.
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.261 Variable LGGLGDEF in CICS dataset CICLGG is the Log Write
VMAC110 Defer Interval, the value specified in the site's LGDFINT
Nov 29, 2007 parameter, but the MXG format only printed 2 decimals;
the value is normally in milliseconds, so the format
TIME13.3 is now used so a value of 5 ms will print as
00:00:00.005.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.260 ITRTVLTM in TYPE30_V or PDB.SMFINTRV could be missing
VMAC30 for TYPETASK='OMVS' record; it is now protected twice,
Dec 1, 2007 in the SUBSTEP loop, and at the OUTPUT statement.
Thanks to Carl Sablon, KBC, BELGIUM.
Change 25.259 VMXGALOC bumped to the next week's PDB one day early, and
VMXGALOC could do even worse if the week-start-day was not Monday.
Nov 29, 2007 The logic was revised for both errors by this CodeShark.
Thanks to Patrick Holloman, Zions Bank Corporation, USA.
Change 25.258 Intentionally Blank Change (a/k/a skipped).
Change 25.257 Support for ICSF HCR7750 SMF Logging Update for TKE adds
FORMATS these new variables to SMF type 82 subtype 16 TYPE8216:
VMAC82 SMF82PAL='LENGTH OF*FIXED*AUDIT*DATA*'
Nov 29, 2007 SMF82PDE='DESCRIPTION'
SMF82PFI='FUNCTION*ID'
SMF82PFR='FUNCTION*RETURN*CODE'
SMF82PTA='TKE*AUTHORITY'
SMF82PUS='USER ID*NONCE*TSN'
and incorrectly spelled SMF82PDK is now SMF82PBK.
New MG082RC format decodes SMF82PFR.
Thanks to Greg Burt, Fifth Third Bank, USA.
====== Changes thru 25.256 were in MXG 25.11 dated Nov 22, 2007=========
Change 25.256 Macro variable &MXGDEBUG is revised for internal debugs.
TIMEBILD It's value is now the name of the member, suffixed with a
UTILRMFI numeric value when multiple values are needed. Previously
VMXGRMFI tests were for a simple numeric value, which triggered
VMXGSUM unwanted debugging diagnostics from other code members.
VMXGSUME And, UTILEXCL now exploits &MXGDEBUG with BEFORE/AFTER
UTILEXCL location for each of the optional CICS data segments, so
Nov 21, 2007 diagnosis of user tailoring errors will be faster!
For example, you could use:
OPTIONS FIRSTOBS=3800 OBS=3800;
%LET MXGDEBUG=IMACEXCL;
%INCLUDE SOURCLIB(TYPE110);
if you had an error after IMACEXCL/IMACICxx members
were tailored, and the error was in _N_=3800th record.
Change 25.255 Support for Action Software's EventAction SMF User Record
EXEVTA00 creates new datasets:
EXEVTA01 DDDDDD DATASET DESCRIPTION
EXEVTA02
EXEVTA03 EVTA00 EVTA00 DATASET CHANGE OR REFERENCE
EXEVTA04 EVTA01 EVTA01 CHANGESMXSMF)
EXEVTA05 EVTA02 EVTA02 REFERENCES MZSMF)
EXEVTA06 EVTA03 EVTA03 CHANGE ACTION CONTROLS
EXEVTA07 EVTA04 EVTA04 TEST ACTION C506)
EXEVTA08 EVTA05 EVTA05 COMMAND CONTROL C507)
EXEVTA09 EVTA06 EVTA06 CHG.DISTRIB TRANSMITS MZSMF)
EXEVTA0A EVTA07 EVTA07 REF.TRACKING BY MEMBERS CS501)
EXEVTA0B EVTA08 EVTA08 UPDATE TO EXCLUDES TABLE C41E)
EXEVTA0C EVTA09 EVTA09 UPDATE TO BLACKOUT TABLE C427)
EXEVTA0D EVTA0A EVTA0A UPDATE TO DATASET OPTIONS C404)
EXEVTA0E EVTA0B EVTA0B UPDATE TO MEMBER OVERRIDE C405)
EXEVTA0F EVTA0C EVTA0C OPTIONS AT OID LEVEL C40F)
EXEVTA10 EVTA0D EVTA0D GLOBAL PARMS C401)
EXEVTA11 EVTA0E EVTA0E DATA SET GLOBAL OPTIONS C401)
EXEVTA12 EVTA0F EVTA0F PXC
EXEVTA40 EVTA10 EVTA10 UPDATE TO USER GROUP
EXEVTA50 EVTA11 EVTA11 EXCLUDES NOT REF.TRK)
EXEVTA51 EVTA12 EVTA12 UPDATE TO CMD>TRACK OPTIONS
EXEVTAF0 EVTA40 EVTA40 CHANGE REQUEST DELETE
EXEVTAF1 EVTA50 EVTA50 USS CONTROLS
IMACEVTA EVTA51 EVTA51 USS EXCLUDES
TYPEEVTA EVTAF0 EVTAF0 ACCOUNTING RECORDS C50C)
TYPSEVTA EVTAF1 EVTAF1 USS CHANGS AND REFERENCES
VMACEVTA
VMXGINIT
FORMATS
Nov 18, 2007
Thanks to Craig Collins, State of Wisconsin DOA DET, USA.
Change 25.254 New sample report summarizes the DB2 Package data to the
ANALACTP UOW level keeping track of total response and CPU,
Nov 18, 2007 the longest package, the first 10 packages.
Jan 8, 2008 Jan 8: Typos in the untested code were discovered/fixed.
Example expected UOWIDCHR variable had been added
to your DB2ACCTP dataset, but didn't show how to,
or note it could be removed from ANALACTP example.
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Change 25.253 Support for new NTSMF MSSQL Objects.
EXNTQLBA DDDDDD DATASET DESCRIPTION
EXNTQLBN
EXNTQLBS NTQLBA MSQBROAC MSSQL:BROKER ACTIVATION
EXNTQLBT NTQLBN MSQBUFND MSSQL:BUFFER NODE
EXNTQLCA NTQLBS MSQBROST MSSQL:BROKER STATISTICS
EXNTQLCL NTQLBT MSQBRODT MSSQL:BROKER/DBM TRANSPORT
EXNTQLCT NTQLCL MSQCLR MSSQL:CLR
EXNTQLCU NTQLCA MSQCATME MSSQL:CATALOG METADATA
EXNTQLES NTQLCU MSQCURMG MSSQL:CURSOR MANAGER TOTAL
EXNTQLPC NTQLCT MSQCURTY MSSQL:CURSOR MANAGER BY TYPE
EXNTQLSR NTQLES MSQEXECS MSSQL:EXEC STATISTICS
EXNTQLTR NTQLPC MSQPLANC MSSQL:PLAN CACHE
EXNTQLWS NTQLSR MSQSQLER MSSQL:SQL ERRORS
IMACNTSM NTQLTR MSQTRANS MSSQL:TRANSACTIONS
VMACNTSM NTQLWS MSQWAITS MSSQL:WAIT STATISTICS
VMXGINIT
Nov 18, 2007
Thanks to Bob Gauthier, Albertsons, USA.
Change 25.252 Changes for testing MXG execution under WPS:
CONFIGW2 -MXGWPSV2. JCL procedure updated for WPS under z/OS
MXGWPSV2 -VMXGINIT. Test for identification of WPS revised, code
VMXGINIT was relocated to after TAPENGN was set for SAS:
VMXGPRAL %IF %SYSPROD(WPS) EQ 1 %THEN %DO;
ANALDB2K %LET WPSVER=&SYSVER;
ANALHTML %LET SASVER=8;
ANALMQMC %LET TAPENGN=WPDSEQ;
ASUM42DS %END;
ASUMCACH -CONFIGW2. CONFIG options now specify SEQENGINE=WPDSEQ.
ASUMHSM -VMXGPRAL. Tests for ENGINE adds WPDSEQ to list of seqs.
ASUMTALO Unrelated, SUM was added to PROC MEANS output.
CICSTRAN -VMXGINIT. WPS does not yet support VIEWS; all members
DB2PDB with /VIEW=XXXXXX were replaced with &VWxxxxxx
GRAFRAID macro variables that are %LET to the correct
JCLUOWP View-NAME under SAS but blanked under WPS.
JCLUOWV This change will be reversed when WPS has
UTILRMFI added support for Views.
UTILUOW -ANALDB2K thru VMXGUOWT listed at left were "View-Revixed".
VMXGCAPT WPS Level Tested successfully was Build (8460).
VMXGSUM
VMXGSUME MXG Newsletter FIFTY-ONE, VI.A WPS Technical Note reports
VMXGUOTT 1. Current status of MXG Testing under WPS Betas Nov 2007.
1.j. MXG Support Position for testing of WPS Release.
VMXGUOW 2. Run time comparisons.
VMXGUOWT 3. Revision to SAS Clones article in MXG Newsletter FIFTY.
Nov 19, 2007 4. Summary and statistics
Jan 30, 2008 Jan 30: typo VMUM corrected to VWUM.
Thanks to Brian Carter, EDS, UK.
Change 25.251 Several variables starting with R7021xxx had '2048-BIT'
VMAC7072 in their labels, but those are all '1024-BIT' counts and
Nov 17, 2007 durations; their labels are now corrected.
Thanks to Miguel F. Monferrer Carvajal, SPAIN.
Change 25.250 Variable TARCELAP is now FORMATed TIME12.2.
VMACTMNT
Nov 17, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.249 Variable TAUSRDAT was INPUT as $EBCDIC32. but can have up
VMACTMO2 to 240 bytes of data; INPUT statement was revised to use
Nov 17, 2007 TAUSRLEN to determine the length of user data input.
Thanks to Rodger Foreman, Acxiom, USA.
Change 25.248 The current VMXGSUM creates output variables with stored
VMXGINIT LENGTH of 5 (z/OS) or 6 (ASCII), based on the value of
VMXGSUM &MXGLEN (set in VMXGINIT), unless they are used in the
Nov 18, 2007 SUMLONG=, MAXTIME=, OR MINTIME= arguments, which always
create LENGTH 8 variables. You could change those lengths
with an explicit LENGTH statement in OUTCODE=, or you
could change the &MXGLEN value, but that would also
change subsequent LENGTHs of all defaulting variables in
subsequent steps in the same SAS session/step.
The SUMBY= and ID variables are output in the same length
they were in the input dataset, or in the INCODE= code if
that is where they were created. They could be changes
in the ORDER= argument.
This change creates macro variable &LNSUMOUT which will
only apply to VMXGSUM and makes all variables on which we
do mathematical operations to be LENGTH 8.
The default value of LNSUMOUT is blank, so the variables
will have the original (shorter) length unless you set
%LET LNSUMOUT=8; in your //SYSIN stream.
Apr 2008: DO NOT USE LNSUMOUT. See Change 26.065.
Thanks to MP Welch, SPRINT, USA.
Change 25.247 WebSphere SMF 120 Subtype 3 with two heap ids SM120SNT=2
VMAC120 caused INPUT STATEMENT EXCEEDED RECORD or INVALID DO LOOP
Nov 13, 2007 CONTROL error; only SM120SNT=1 records had been read and
this condition exposed an MXG logic error, now corrected.
Thanks to Bjorn Helgestad, VPS ASA, NORWAY.
Change 25.246 A CFI record with only a header segment caused ASMRMFV
ASMRMFV to burp and die with an 0C4; this revision protects.
Nov 13, 2007 Additional enhancements are noted in the changes in the
Nov 17, 2007 ASM source comments.
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.245 CA PDSMAN product's SMF record created megabytes of data
VMACPDSM when diagnostic trace records (LGRTYPE='D') were enabled,
Nov 12, 2007 and CA's recommendation was to suppress them and also the
Resource Monitoring (LGRTYPE='M') record processing.
Thanks to Sudie Wulfert-Shcickendanz, Anheuser-Busch, USA.
Change 25.244 The IRRDBU00 RACF DATABASE UNLOAD record '0200' comes in
VMACRACF two different lengths, 540 and 549, but MXG expected the
Nov 12, 2007 549 length record, which caused INPUT RECORD EXCEEDED
error when the shorter record was read. Both lengths are
now supported.
Thanks to Sean Angley, IBM, CANADA
Change 25.243 The automatic PROC DELETE of the WORK.UNKNOWN dataset is
TYPETNG removed, so that that dataset will exist after TYPETNG or
TYPSTNG TYPSTNG program is used to process CA NSM (old TNG) data.
Nov 6, 2007 If there are non-zero observations in WORK.UNKNOWN, it is
very possible that some or all data will not have been
output by MXG logic, so leaving WORK.UKNOWN will allow
it to be tested for possible unknown data records.
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.242 NDM record 'UC' is now output in NDMAE dataset.
VMACNDM
Nov 5, 2007
Change 25.241 Support for CICS Transaction Gateway 7.1.0 new SMF 111
EX111CM statistics record:
EX111CM datasets:
EX111CS DDDDDD MXG MXG
EX111CXE DATASET DATASET DATASET
EX111CXI SUFFIX NAME LABEL
EX111GD
EX111PH 111CM T111CM CICS CTG COMMUNICATIONS MANAGER
EX111SE 111CS T111CX CICS CTG CICS SERVER
EX111WT 111CXE T111CXE CICS CTG EXCI SERVER INSTANCE
IMAC111 111CXI T111CXI CICS CTG IPIC SERVER INSTANCE
VMAC111 111GD T111GD CICS CTG GATEWAY DAEMON
VMXGINIT 111PH T111PH CICS CTG PROTOCOL HANDLER
Nov 5, 2007 111SE T111SE CICS CTG SYSTEM ENVIRONMENT
Nov 21, 2007 111WT T111WT CICS CTG WORKER THREADS
Change 25.240 Full Support for CICS/TS 3.2 Compressed Data.
EXITCICS MXG incorrectly believed that '20'x bit in MCTMNOPN was
VMAC110 true when CICS/TS 3.2 SMF 110-1 records are internally
VMAC112 compressed, but that bit only indicates that the compress
Nov 3, 2007 option was enabled for this CICS region. This caused MXG
Nov 13, 2007 to falsely report the EXITCICS decompression exit was not
correctly installed, when Dictionary Records (MNSEGCL=1),
which are never compressed, were read. MXG now tests for
non-zero MCTSSCRL, which is the documented condition for
a compressed CICS SMF 110 or 112 record.
-VMAC112 was similarly changed to test for non-zero OMSPCL
to detect compressed SMF 112 records.
-This incorrect assumption had also been passed in my spec
for the EXITCICS logic, which had just turned off that
'20'x bit in its decompressed output. Now, EXITCICS sets
MCTSSCRL or OMSPCL to zero after decompression.
-If you previously assembled EXITCICS prior to this change
you must reassemble with this revised EXITCICS member AND
use the revised MXG's VMAC to read compressed records.
Change 25.239 -Support for new THRUPUT MANAGER variables in TYPETPMX:
EXTPMALG JXSLMCC ='JXSLM*CONTROL*CENTER'
EXTPMDBS JXSLMCC ='JXSLM*CONTROL*CENTER'
EXTPMSLM -New SLM JOB Statistics subtype 5 creates TPMSLM dataset.
FORMATS -New DBS POOL subtype 240 creates two new datasets:
IMACTPMX TPMALG - Algorithm data
VMACTPMX TPMDBS - DBS Pool data
VMXGINIT -Jan 4: Variables JESNR JCTJOBID added to TPMSLM dataset.
Nov 3, 2007 -Jan 9: GA records have corrected ETP truncation that was
Jan 4, 2008 originally reported here.
Jan 9, 2008
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.238 Optional OMEGAMON BSC segment for CICS/TS 3.2 did NOT
IMACICOB increase time-duration/count fields to the full 12-byte
IMACICOC resolution that I had ASS-U-Med, which caused MXG ERROR
IMACICO2 message INVALID STRTTIME. I made the same assumption for
Nov 2, 2007 all three Omegamon segments with time/count fields, so I
now assumed that the other two segments also have 8-byte
fields (IMACICOB for OMEGDB2, IMACICO2 for OMEGAMON), so
those two members also are reverted. And, of course, if
Omegamon does increase their fields to full 12-bytes,
yet another MXG change will be required.
Thanks to Ray Dunn, CIGNA, USA.
Change 25.237 Variable LCPUWAIT='LCPU 28*WAIT*COMPLETE?' in PDB.TYPE70
VMAC7072 was not kept after MXG 23.09, but the same named variable
Nov 1, 2007 LCPUWAIT='LPAR*WAIT*COMPLETION?' in PDB.TYPE70PR was, and
that was the source of the problem. Now, a rename fixes
this error, which was introduced in the infamous SPLIT70
rewrite.
Thanks to Enzo Rossi, Demand Technology Software, ITALY.
Change 25.236 Change 24.141 with z/OS at 1.7 or earlier caused TYPE78IO
VMAC78 dataset to have zero observations; MXG tested SMF78RSQ
Oct 31, 2007 for zero or one, but SMF78RSQ does not exist when the
Nov 1, 2007 RMF product segment is only 104 bytes. The test was
revised to output TYPE78 for missing value, zero or one.
But then, the duplicate observations created were NOT
removed by the NODUP option, because the SMFTIME in the
second or third replicates was not exactly the same value
as the first, so the _STY78IO sort macro was rewritten to
remove those with identical SMFTIMEs, and an extra DATA
step is used to keep only the FIRST.SMFTIME instance.
(The additional logic is invoked, but not needed, when
the SPLIT 78 records have a valid SMF78RSQ value.)
Thanks to Peter B. Hopper, CSC, AUSTRALIA.
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 25.235 -Support for new Solaris CA CUBE STORE GROUP object and
EXTSO030 new variables in existing Solaris MIB-2.
EXTAI027 -Support for two new AIX Objects.
EXTAI028 -Support for 10 new RedHeat Objects, many new Metrics
EXTRH020 for existing RedHat Objects.
EXTRH021
EXTRH022
EXTRH023
EXTRH024
EXTRH025
EXTRH026
EXTRH027
EXTRH028
EXTRH029
FORMATS
VMACTNG
VMXGINIT
Oct 31, 2007
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.234 New variables added to OAM SMF 85 subtype 32-35 record
VMAC85 by z/OS 1.7 are now input and kept in TYPE85ST dataset:
Oct 28, 2007 R85B2ODK='BACKUP2*BYTES*DELETED FROF*OPTICAL'
Nov 1, 2007 R85B2ODO='BACKUP2*OBJECTS*DELETED FROM*OPTICAL'
R85B2ORK='BACKUP2*BYTES*READ FROM*OPTICAL'
R85B2ORO='BACKUP2*OBJECTS*READ FROM*OPTICAL'
R85B2OWK='BACKUP2*BYTES*WRITTEN TO*OPTICAL'
R85B2OWO='BACKUP2*OBJECTS*WRITTEN TO*OPTICAL'
R85B2TDK='BACKUP2*BYTES*DELETED FROF*TAPE'
R85B2TDO='BACKUP2*OBJECTS*DELETED FROM*TAPE'
R85B2TRK='BACKUP2*BYTES*READ FROM*TAPE'
R85B2TRO='BACKUP2*OBJECTS*READ FROM*TAPE'
R85B2TWK='BACKUP2*BYTES*WRITTEN TO*TAPE'
R85B2TWO='BACKUP2*OBJECTS*WRITTEN TO*TAPE'
R85NTE ='TAPE*VOLUMES*EXPIRED'
R85RCLD ='RECALLED*OBJECTS*PROCESSED*THIS CYCLE'
R85RCLK ='BYTES OF*RECALLED*OBJECTES*THIS CYCLE'
and these variables added by z/OS 1.8 are input/kept:
R85LOBD ='ROWS*DELETED*FROM LOB*STRUCTURE'
R85LOBI ='ROWS*INSERTED*INTO LOB*STRUCTURE'
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.233 The COMPRESSED RECORD FOUND error was printed for a CICS
VMAC110 dictionary record, but the MNSEGCL flag that identifies
Oct 27, 2007 the record IS a dictionary record was not printed.
Change 25.232 Change 25.124 added preliminary support for WPS execution
VMXGINIT but it forced WPSVER=2; now, the actual WPSVER is stored
Oct 26, 2007 in &WPSVER.
Change 25.231 Change 25.177 created new macro variable &ARRAYRMF, but
VMXGINIT the location in VMXGINIT was inside a DO GROUP that was
Oct 26, 2007 only executed for SAS V8.2, causing UNRESOLVED MACRO when
MXG executed under SAS Version 8.1. The statement was
relocated so it is always executed, no matter what SAS
version is used.
Thanks to John Compton, ACS, USA.
Change 25.230 MXG support for IMF 4.3 used the new offset field to the
VMACCIMS DBD segments when it was non-zero, but PTF BQI0129 for
Oct 23, 2007 IMF 4.2 populated that previously reserved field, which
caused INPUT EXCEEDED error and this error message:
INVALID IMS TRANSACTION RECORD LENGTH=836 WITH xxx
48-BYTE DBDS EXPECTED AFTER COL=32765 _N_=1
Now, MXG only uses the 4.3 offset to DBDs when the IMF
version is 4.3 or greater.
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 25.229 -NMON data for AIX for PDB.NMONCPUD records can have the
VMACNMON number of CPUnn records increase and decrease as AIX adds
Oct 23, 2007 or subtracts "virtual" CPUs, and when a CPUnn goes away,
Nov 2, 2007 NMON wrote a short record, which caused INPUT EXCEEDED
error. Now, MXG detects and deletes these short records.
Note that the PDB.NMONINTV dataset, in NRCPUS variable,
has the number of "real" CPUs. However, in this case,
the value of NRCPUS was always 6, even though there were
CPUnn segments with CPU14 (i.e., there should have been
NRCPUS=7, as there are 2 "virtual" CPUs for each "real".
-Temporary variables WORD11-WORD24 were not set to LENGTH
$128, so they took the SAS default of 8-bytes for CHARs,
causing character variables stored from them to also have
a stored length of 8 bytes. Now, all WORDnn are $128,
and specific LENGTHs for kept variables are used where
needed.
-Variables NRCPU, PID, and PPID are now numerics.
-NMON data value 'nan' is 'Not a Number' and is stored in
the data records, causing INVALID DATA messages until
each instance is protected with double question marks!!
Sometimes spelled NaN.
Thanks to Mike Woelke, Boeing, USA.
Change 25.228 Protection for invalid SMF 14 record that had NUCB=2 but
VMAC1415 only one actual UCB segment. This record caused ERROR:
Oct 17, 2007 INPUT STATEMENT EXCEEDED RECORD LENGTH. Protection will
print error message for first three bad instances.
Thanks to William Carrol, Grange Insurance, USA.
Change 25.227 Variable RPRTCLAS is now kept in TYPE72DL dataset to flag
VMAC7072 a Service Class versus a Reporting Class observation. It
Oct 16, 2007 was not kept previously because the SMF manual mentioned
only service classes, but actual data shows TYPE72DL can
contain both Service and Reporting Class observations.
Thanks to Harald Seifert, HUK-COBURG, GERMANY
Change 25.226 UPRINDOC will PROC PRINT the NAME and LABEL of variables
UPRINDOC and is used to create the example output in the ADOCxxxx
Oct 16, 2007 members, and it also PROC MEANS all numeric variables.
It's been in MXG for years, but never documented.
Change 25.225 RMF III variable ENCCPUT is labeled 'CP*ENGINE*CPU TIME'
VMACRMFV now, because it is recalculated to remove zIIP CPU time:
Oct 16, 2007 ENCCPUT=ENCCPUT-ENCSUPT;
Oct 31, 2007 when it was found (and confirmed by RMF support) that it
contained both CP and zIIP Engine CPU time, but MXG will
always preserve the CP-Engine CPU times separately from
the zIIP and/or zAAP engine CPU times.
Thanks to Rodger Foreman, Acxiom, USA.
Change 25.224 The tests for CPUTYPE IN ('2064'X ...) are revised to now
VMAC7072 alternatively test for ZARCHMDE='Y', so that a new value
VMXGRMFI for CPUTYPE does NOT have to be added to MXG's table.
Oct 16, 2007 Previously, an unknown CPUTYPE was INCOMPATIBLE until
Oct 27, 2007 it was added to the tables in these two members.
The tests for CPUTYPE were needed to identify which data
exists in some of the early CPU types, but now that IBM
has added the bit for ZARCHMDE, it eliminates the need
for a new MXG version when IBM has a new CPUTYPE.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.223 The variable HOST is increased to 32 bytes; the original
VMACNMON length of 8 is insufficient for unix/AIX/linux host name.
Oct 15, 2007
Thanks to Michael W. Wolke, Boeing, USA.
Change 25.222 EXIT112 is the enhanced CICS INFILE EXIT for z/OS MXG
EXIT112 that reads compressed SMF 110 and SMF 112 records, but it
Oct 13, 2007 is temporary, as it will replace EXITCICS when a site
reports successful production sites with both records.
EXITCICS is running in production at several sites.
EXIT112 is an extension to EXITCICS, and EXIT112 has been
tested, but only with a small SMF file. I recommend that
EXIT112 be installed instead of EXITICS, and ask that you
confirm successful processing compressed 110 and 112 data
so that I can remove EXIT112 and rewrite this change.
Change 25.221 Support for CA NSM data from VM Ware VSX Systems creates
EXTVW001- ten new datasets. Many VMW metrics are the same as their
EXTVW010 Solaris and RedHat Linux counterparts, but with different
FORMATS variable names because not all exist and they are created
IMACTNG in different orders. While "TNG" still must be the suffix
VMACTNG for the MXG code members, the dataset labels of all "TNG"
VMXGINIT datasets are now changed to "NSM". New VM Ware datasets:
Oct 13, 2007 DATASET DDDDDD DESCRIPTION
VW001 VW001 NSM CA CPU GROUP
VW002 VW002 NSM CA FILE SYSTEM
VW003 VW003 NSM CA INTERFACE GROUP
VW004 VW004 NSM CA KERNEL CONFIG GROUP
VW005 VW005 NSM CA MEMORY GROUP
VW005 VW005 NSM CA NETWORK GROUP
VW007 VW007 NSM CA PER CPU GROUP
VW008 VW008 NSM CA SWAP GROUP
VW009 VW009 NSM CA PROCESS GROUP
VW010 VW010 NSM VIRTUALIZED ENVIRONMENT
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.220 The LABEL for SMF91OW was correct in TYPE91 datasets, but
ANAL91 it was changed in ANAL91, incorrectly, in an unneeded and
Oct 11, 2007 redundant and now removed LABEL statement.
Thanks to Dave Krouse, IBM, USA.
Change 25.219 TYPE74CA variable FWDC was replaced some time ago, but
VMAC74 the label was not corrected; the variable is labeled now:
Oct 11, 2007 FWDC ='DASD F/W*BYPASS*COUNT*R745DFWB'
Thanks to Ed Woodward, UPS, USA.
Change 25.218 Support for local CICS USER field CMODHEAD,CMODNAME=TRADE
IMACICU5 creates variable TRADEU5 in CICSTRAN, when enabled.
VMAC110 Jul 3, 2008: Field was increased to 80 bytes; the test
UTILEXCL and INPUT were also increased to 80.
Oct 11, 2007
Jul 3, 2008
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 25.217 VMACPRPR was revised, in June, but the Change text was
VMACPRPR lost. Originally support for the '1620' record was added
Oct 10, 2007 June 12, and test records had different delimiters in
date/time fields, so INPUTs were changed in MXG, but now
I see that no other record's date/times were changed.
This change, which was included in MXG 25.10, reverted
date/times for all other records to the original format,
but created a separate path to decode 1620 subtypes.
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 25.216 The MXG support for optional CICS EZA01/EZA02 fields has
IMACICEZ been enhanced and documentation revised for clarity:
IMACICE1
IMACICE2 -IMACICEZ always has these 5 fields, identified by their
VMAC110 CMODNAME='EZA01' and CMODTYPE='S':
Oct 11, 2007
Jun 13, 2008 EZA01 S 001 12 ooo INIT
EZA01 S 002 12 ooo READ
EZA01 S 003 12 ooo WRITE
EZA01 S 004 12 ooo SELECT
EZA01 S 005 12 ooo OTHER
The CMODLENG=12 is from CICS/3.2; earlier CICS had only
CMODLENG=8, but IMACICEZ supports both lengths, so you
just remove the comment block to tailor IMACICEZ and it
will process data with either or both lengths.
-IMACICE1 can have up to 13 fields, identified by their
CMODNAME='EZA01' and CMODTYPE='A' (yes, CMODNAME is the
same 'EZA01' as IMACICEZ, but the CMODTYPE is different):
EZA01 A 001 4 ooo TINIT
EZA01 A 002 4 ooo TREAD
EZA01 A 003 4 ooo TWRITE
EZA01 A 004 4 ooo TSELECT
EZA01 A 005 4 ooo TOTHER
EZA01 A 006 4 ooo REUSABLE
EZA01 A 007 4 ooo ATTACHED
EZA01 A 008 4 ooo OPENAPI
EZA01 A 009 4 ooo TCBLIM
EZA01 A 010 4 ooo TREUSABL
EZA01 A 011 4 ooo TATTACHE
EZA01 A 012 4 ooo TOPENAPI
EZA01 A 013 4 ooo TTCBLIM
You will have to examine REPORT THREE (which may have the
last CMODHEAD field 'EZA01' instead of the names shown)
to know how many fields are in your data. If you have the
expected 13 fields, then you just remove the one comment
block. If you have fewer fields, then:
- Change the IF xxxx GE 52 THEN DO; statement so its
test value is 4 times the number of fields, e.g.
with seven fields change the "52" to "28".
- Change the INPUT statement's suffix from EZA01A13 to
the number of fields you have; if there are seven:
INPUT (EZA01A01-EZA01A07) (&PIB.4.) @;
- Delete the LABELs for variables that don't exist.
-IMACICE2 has 22 fields with z/OS 1.7 TCP/IP data, but had
only 11 fields with z/OS 1.4, which are identified by the
CMODNAME='EZA02' and CMODTYPE='A:
EZA02 A 001 4 330 CONN
EZA02 A 002 4 331 STARTED
EZA02 A 003 4 332 INVALID
EZA02 A 004 4 333 DISTRAN
EZA02 A 005 4 334 DISPROG
EZA02 A 006 4 335 GIVESOKT
EZA02 A 007 4 336 SECEXIT
EZA02 A 008 4 337 NOTAUTH
EZA02 A 009 4 338 IOERR
EZA02 A 010 4 339 NOSPACE
EZA02 A 011 4 340 LENERR
EZA02 A 012 4 341 TCONN
EZA02 A 013 4 342 TSTARTED
EZA02 A 014 4 343 TINVALID
EZA02 A 015 4 344 TDISTRAN
EZA02 A 016 4 345 TDISPROG
EZA02 A 017 4 346 TGIVESOK
EZA02 A 018 4 347 TSECEXIT
EZA02 A 019 4 348 TNOTAUTH
EZA02 A 020 4 349 TIOERR
EZA02 A 021 4 350 TNOSPACE
EZA02 A 022 4 351 TLENERR
You will HAVE to look at UTILEXCL REPORT THREE to confirm
if you have 22 or 11 fields, and remove only one of the
two comment blocks in IMACICE2 to tailor it.
-You create REPORT THREE with the _RPTEXCL macro run
with or after your UTILEXCL execution:
//SYSIN DD *
%INCLUDE SOURCLIB(UTILEXCL);
_BLDDICT;
_BLDEXCL;
_RPTEXCL;
-The only actual change made was to update VMAC110 to keep
the EXA01A13 13th variable.
-The text of this change was revised in June, 2008.
Thanks to Jane Dickerson, PRODUBAN, ENGLAND.
====== Changes thru 25.215 were in MXG 25.10 dated Oct 7, 2007=========
Change 25.215 Change 25.179 broke VMXGUOW, some overrides of _LDB2ACC
VMXGUOW caused CHARACTER OPERAND IN %EVAL FUNCTION errors.
Oct 7, 2007 Also, parameter HOWDEEP added to set kept array sizes.
Change 25.214 An example that finds all TSO and IDMS USERID that logged
TSOIDMS on,using IBM SMF 30 and IDMS PERFMON USER SMF records.
Oct 6, 2007
Thanks to Pat Curren, Supervalu, USA.
Change 25.213 Documentation only. DB2 variable THREADTY shouldn't have
VMACDB2 been added to DB2ACCTP dataset (Change 25.097), because
Oct 7, 2007 DB2 V8.1 writes all Package data in IFCID=239 (ID=101.1)
records, which do not contain a QLAC segment, and IBM's
THREADTY definition (in comments for QWHDRQNM field in
their DSNWMSGS member of the DB2 Macro Library) compares
QWHDRQNM with QLACLOCN. Since I can never safely remove
a variable, it will still exist in DB2ACCTP, but it will
always be blank in that dataset. No code was changed.
Change 25.212 -SYNCSORT variable SYNCUSET is now documented to be the
VMACSYNC sum of VSCORET plus the GDSM Adjustment, so its label
Oct 6, 2007 is revised to be:
Nov 17, 2007 SYNCUSET='CORE USED*TOTAL*VSCORET*PLUS GDSM ADJ'
-SYNCSORT added a new field, which MXG decodes as:
SYNHWMPF='HIGHWATERMARK*PAGEFIXED*STORAGE*USED'
where the old HPALLOC/HPUSED ESTORE BLOCKS was located.
-All reserved and unknown fields in SYNCSORT SMF record
are decoded, but none of these variables are kept:
/* SYNRSV41-SYNRSV45 SYNUNK01-SYNUNK15 */
/* SYNCHFUT SYNCBFUT SYNXXXX1 SYNSPARE */
Change 25.211 PDB.TYPE70 variables ZIPACTTM, PCTZIPBY, PCTCIBYn are now
VMAC7072 corrected for Dedicated zIIP Engines. For Shared zIIPs,
Oct 5, 2007 the LPAR Dispatch time is valid, but Dedicated engines
report 100% dispatch. For TYPE70, the ZIPWAITM is used
to correct ZIPACTTM, which corrects the other variables.
Thanks to Jerry Cobb, American Century, USA.
Change 25.210 -WARNING: LENGTH OF CHARACTER VARIABLE ACCOUNT1 HAS BEEN
VMACSFTA SET under SAS V9 is issued ONLY when a LENGTH statement
VMACDB2 changes the length of a character variable, and, like all
VMACOPC WARNING: messages in SAS V9, z/OS sets Condition Code 4.
VMACBE97 (Under V8, this specific WARNING did NOT set CC=4,
VMAC7072 but V9 has tightened specs so WARNINGS always CC=4.)
TRNDDB2S But it should never occur in MXG code: although there are
ANALCISH multiple LENGTH statements, they should always set the
Oct 4, 2007 same value.
But it did occur when VMACSFTA was executed standalone,
because the statement ACCOUNT1=XPUPNOAC; was located
prior to the %INCLUDE of IMACACCT, which is where the
LENGTH of ACCOUNT1 should always be defined. Relocating
that ACCOUNT1=XPUPNOAC; statement eliminated the WARNING.
-When WARNING for numeric vars (eg. QB1TALX) were printed,
I discovered there were six members that had hard-coded
values for LENGTH DEFAULT=4 that should have been changed
to LENGTH DEFAULT= &MXGLEN; the were overlooked or added
after Change 19.272, but now all are consistent so that
numeric variables are stored 5 on z/OS and 6 on ASCII,
except for the specific cases where length 8 is required.
Thanks to Ron van der Zande, KLM Info Services, THE NETHERLANDS.
Thanks to MP Welch, SPRINT, USA.
Change 25.209 -TIMEBILD/TIMETABL is enhanced to support the selective
TIMEBILD application by SYSTEM of "SYNC59" timeshifting logic:
TIMETABL - TIMEBILD now reads columns 71-72 of TIMETABL to INPUT
VMXGTIME the (+ or -) number of minutes to be added for SYNC59.
VMXGINIT That value is a part of the format built by TIMEBILD.
VMXG70PR - %TIMEBILD must be executed first to create the table.
Oct 5, 2007 - To enable the addition of SYNC59 offset, you must set
%LET MXGTIM59=YES;
and then you would run the program whose datetimes
are to be shifted by both TIMEBILD zones and SYNC59.
- The "SYNC59" option is intended to be used ONLY with
RMF/CMF data, and in particular, for data from a CEC
that has some systems SYNC59 and some SYNC00. It may
not work with other programs, including BUILDPDB, as
you may not want all records SYNC59'ed. And, if you
now use the SYNC59 option in TIMEBILD, you must also
change your ASUMxxx, TRNDxxxx, VMXGxxxx tailored code
to now specify SYNC59=NO to prevent a double shift.
- To process only the RMF data with a TIMETABL that has
been updated to include the SYNC59 flag, you could use
%LET MXGTIM59=YES;
%TIMEBILD;
%UTILBLDP ( BUILDPDB=NO,
USERADD=70 71 72 73 74 75 76 77 78,
ZEROOBS=74.1 74.5,
INCLAFTR=RMFINTRV ASUM70PR,
OUTFILE=INSTREAM);
%INCLUDE INSTREAM;
to build you RMF-only PDB Library (which will be small,
as that example does NOT create observations in the two
big TYPE74 and TYPE74CA datasets due to that ZEROOBS=).
- TIMEBILD will PROC PRINT the input TIMETABL and the
output TIMEBILD datasets by enabling MXGDEBUG:
//SYSIN DD *
%LET MXGDEBUG=1;
%LET MXGTIM59=YES;
%TIMEBILD;
RUN;
%LET MXGDEBUG=0;
- You can conditionally reset MXGTIME59 for some SMF data
and not for others; for example, to enable for59 add,
and you do NOT have to rerun TIMEBILD.
%TIMEBILD(TIMEBILD=YES);
%LET MACFILE=%QUOTE(
IF ID=30 THEN CALL SYMPUT('MXGTIM59','NO');
ELSE CALL SYMPUT('MXGTIM59','YES');
);
%UTILBLDP(USERADD=7072 30,BUILDPDB=NO);
%INCLUDE INSTREAM;
-Once TIMEBILD worked to selectively SYNC59, the original
problem, duplicate observations in PDB.ASUMCELP, could be
diagnosed: while BY variable GMTOFFTM is correctly used
to creating the "per-SYSTEM" datasets, it can never be
used in the "per-CEC" datasets, because they are built
from multiple SYSTEM's data, which can have multiple
values in GMTOFFTM. Removing GMTOFFTM from the creation
of PDB.ASUMCELP has eliminated the duplicates; I should
remove GMTOFFTM where it makes no sense, but instead, I
have set GMTOFFTM=. in ASUMCEC and ASUMCELP, so it will
not create a VARIABLE NOT FOUND ERROR.
Thanks to Ingegerd Jannson, Volvo, SWEDEN
Change 25.208 CICS local user field CMONDNAME DAT008 CMODHEAD ENTRADA
IMACICU4 creates new variable ENTRADA.
VMAC110
UTILEXCL
Oct 1, 2007
Thanks to Jane Dickenson, Santander Produban UK, ENGLAND.
Change 25.207 The NTSMF dataset LOGLDISK had the variables FREESPAC
VMACNTSM (FREE MEGABYTES and PCTFRESP (PCT Free space) but the
Sep 27, 2007 size of the volume did not exist until now, with the
new DISKSIZE variable.
Thanks to Michael Ryan, Acxiom, USA.
Change 25.206 MXG 25.09 only. If the SAS-provided default CONFIG member
FORMATS was not in your //CONFIG DD statement in your MXGSASV9
CONFIGV8 JCL procedure, the PROC FORMAT failed to build MXGTNGON,
CONFIGV9 because lines 12092 thru 12099 in FORMATS were low-case
Oct 3, 2007 duplicates of preceding lines, that should not have been
have been there, but they caused no error when the CONFIG
member was present. Since they also caused the error if
they were UPPERCASED, I assume the absence of the SAS
CONFIG member caused them to be treated as UPCASE. Also,
there were Macro Variable error messages because MERROR
is a required option that is normally set in SAS CONFIG.
To protect, MERROR is now added to CONFIGV9 and CONFIGV9.
Thanks to Jim Wertenberger, Antares Solutions, USA.
Change 25.205 Support for z/OS 1.9 54 CP engines - INCOMPATIBLE.
VMAC7072 Z/OS 1.9 allows up to 54 CP engines in a single image,
Sep 27, 2007 but SMF 70 records with CPUID=33 or higer caused ARRAY
Oct 4, 2007 SIZE EXCEEDED with MXG 25.09 or prior. Now, CPUs with
CPUID=33 thru CPUID=53 are supported in the PDB.TYPE70
dataset (the only MXG dataset altered due to 54-CPUs).
Each CPUID has a set of variables in PDB.TYPE70; existing
0-32 CPUIDs variable names were created with suffix 0-9
and A thru X. Now, Y and Z are used for 33-34, and ZA
thru ZS suffix are used for CPUIDs 35-53 variables.
Where the variable name is 8 characters, that "Za" had
to overlay the penultimate character in the name.
To operate on these CPU-specific variable names, they
are all defined in VMAC7072 with an ARRAY statement
that you can cut and paste into your program to avoid
spelling all those names.
-Unrelated, discovered in testing: APAR OA18244 documented
that the CPUC segment was increased to 116 bytes, but the
APAR actually increased its length to 160 bytes, causing
SMF70GJT and following variables to be missing value, as
the MXG test was for EQ 116 (without APAR is EQ 102).
Now, the test is for GE 160, as IBM RMF Development has
confirmed the correct length, to be documented, is 160,
adding 44 unused bytes of zeroes. This APAR applies to
both z/OS 1.8 and z/OS 1.9.
Thanks to Tony Curry, BMC, USA.
Change 25.204 CFI Segmentation feature added for RMF III VSAM support,
ASMRMFV which now eliminates the possibility of skipped CF data,
VMACRMFV new ASM symbolics for tailoring, and additional items.
Sep 25, 2007 Issues Resolved:
Oct 3, 2007 -PROCCFI is now a subroutine to conserve the mainline
Dec 4, 2007 base register.
-CFI Table output is now segmented in response to
reported problems by MXG users. This removes a long
standing restriction that the size of the CFI table
could not exceeding the 32K LRECL output maximum without
data loss.
-The RMFV005E error message could have overlaid text when
multiple ASMRMFV parameter errors were detected.
-Several problems with index data fields in the CFI table
output record either not being set or set incorrectly
that caused PDB build errors in VMACRMFV have been fixed
during alpha code testing.
Enhancements:
-There are a pair of new option keywords BYTES/NOBYTES.
These specify whether ASMRMFV should or should not
provide byte counts for 5 categories of data read,
decompressed, written, filtered, and skipped. The
counts are provided in each RMF data set detail report
and also as totals in the summary report. This feature
is intended to aid users to understand the volume of
data being processed by ASMRMFV, as a coarse comparison
tool when using different versions of (or sets of
keyword options with) ASMRMFV, and finally as a possible
diagnostic aid. The alias for BYTES is BY and the
aliases for NOBYTES is NOBY or -BY. The byte counts
now appear in message RMFV104I and the former RMFV104I
message is now RMFV105I. The distributed default is
BYTES Packed decimal arithmetic is used for these
counters to allow up to 15 decimal digits in magnitude
or up to a value of 999,999,999,999,999 bytes. The
assembler symbolic variable &BYTES is provided to allow
the user to change the default for BYTES/NOBYTES to
NOBYTES in the ASMRMFV source code. The distributed
default is 'Y' meaning that BYTES is the default. These
counters take little overhead to maintain and display.
So there is little benefit in suppressing them except to
reduce output report volume by 2 lines per data set.
But that choice is certainly available.
-A pair of new option keywords CFALL/CFMASTER is added in
support of the CFI segmentation support. CFALL
specifies that CFI tables from all input RMF III LPARs
are to be output as in prior versions of ASMRMFV.
CFMASTER specifies that by testing a particular flag
that only data from the LPAR designated as RMF III
Master Gatherer is to be output. The distributed
default is CFALL. Effective use of CFMASTER requires
that the RMF III parameter CFDETAIL be in effect in all
LPARs in the Sysplex. Due to the IBM usage of this
flag, using the CFMASTER option when RMF III NOCFDETAIL
is in effect (IBM default) will cause all CFI records to
be filtered out by ASMRMFV. CFALL has no alias.
Aliases for CFMASTER are CFMAST and CFM. With CFDETAIL
in effect only the single LPAR determined by RMF III to
be the Master Gatherer collects all Coupling Facility
detail data. So including incomplete CF data from the
remaining LPARs may be an unnecessary and redundant
overhead. The intent of CFMASTER is to automatically
exclude this extra data. The &CFALL assembler symbolic
is also provided to change the CFALL default in ASMRMFV
source code if needed. The &CFALL symbolic can be
changed in the ASMRMFV source to 'N' prior to assembly
to permanently enable CFMASTER processing. The
distributed default is 'Y'. Do not make this change
unless using CFDETAIL on all LPARs being input to
ASMRMFV.
-When CFMASTER is in effect the CFI table id in
the RMFV105I message displays as CFIM instead of the
usual CFI to indicate this option is in effect.
-When the BUFFERS option is in effect the RMFV102I
message will now display a count of both buffers
available and used for each buffer pool type. This
feature was intended mainly to enable MXG users to
intelligently size the large VSAM LSR buffer pool used
to optimize random RMF III data set read access by
ASMRMFV. The distributed default is 5000.
Unfortunately, at this time the VSAM SHOWCB macro
seems to always return a 1 for actual buffers used in
the LSR pool. Given the number of random I/Os
typically issued this value seems suspect and
requires further investigation.
-Program logic for both buffer pool accounting and
normal/filtered/skipped record output has been improved.
-Documentation on the contents of fields for several
messages has been improved to provide more details on
their content and meaning.
-ASMRMFV program prologue documentation is upgraded to
document all related program changes.
-Oct 3: corrected INPUT STATEMENT EXCEEDED; 1.8 CFI data
ends with CFISCCOC in member VMACRMFV.
-Dec 4: VMACRMFV restructured to output only the first
CPUG3 segment to ZRBCPU; the ASMRMFV CPU segmentation
creates a CPUG3 segment for each LPARNAME, which caused
duplicate observations in WORK.ZRBCPU; using TYPSRMFV
to sort ZRBCPU did remove those duplicate obs, but this
change compares CPUHNAME with LPARNAME an outputs only
the first instance for each interval.
Thanks to Jerry Urbaniak, Acxiom, USA.
Thanks to Ben Romano, Hewitt Associates, USA.
Thanks to Lawrence Jermyn of Fidelity Investments, USA.
Change 25.203 OPTIONS COMPRESS=NO was inserted in ASUMTALO back in 1995
ASUMTALO by Change 12.273, because the first (temporary) DATA step
Sep 25, 2007 was extremely expensive, but then Change 12.273 was not
recalled when MXG set COMPRESS=YES as the default value,
so INCLUDEing ASUMTALO turned off compression for any
subsequent programs. Now, VMXGOPTR is invoked to store
your current value of the COMPRESS option, which is then
reset prior to the creation of PDB.ASUMTALO, so it will
be compress based on your choice of the COMPRSS option.
Thanks to Patrick Holloman, Zions Bank Corp, USA.
Change 25.202 ANALDB2R Statistics Reports VARIABLE QBnTDPIO NOT FOUND
ANALDB2R and VARIABLE QLSTCRSR NOT FOUND errors because those
Sep 22, 2007 variable names should never have been in the VMXGSUM
Oct 4, 2007 invocation for the statistics reports.
Thanks to Clayton Buck, UniGroup, USA.
Thanks to Yaohua Hu, ISO, USA.
Change 25.201 -Unexpected FILESYSTEM data with characers caused errors
EXTRH019 INVALID ARGUMENT FOR FUNCTION, temporarily circumvented,
FORMATS but the circumvention causes RH017001 to be a mising
IMACTNG value until further investigation of the strange data.
VMACTNG -Unrelated, Red Hat object USERS is supported in the new
VMXGINIT RH019 dataset created by this change.
Sep 24,2007
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.200 Use of %LET mackeep= whatever ; was not supported.
READDB2
Sep 18, 2007
Thanks to Gary Diehl, Sun MicroSystems/STK, USA.
====== Changes thru 25.199 were in MXG 25.09 dated Sep 17, 2007=========
Change 25.199 If SYNC59=YES was specified in your %VMXGRMFI invocation
VMXGRMFI to create PDB.RMFINTRV, the STARTIME was reset to 00/15
Sep 15, 2007 but SMF70GIE was not. Now it is, so PDB.RMFINTRV will be
consistent with PDB.ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP.
Thanks to Douglas C. Walter, Citicorp, USA.
Thanks to Brent Turner, Citicorp, USA.
Thanks to Tom Koelle, Citicorp, USA.
Change 25.198 TYPE89 variable SMF89HOF (HYPERVISOR DATATIME OFFSET) and
VMAC89 SMF89DTO were wrong because the comment for SMF89PFL was
Sep 15, 2007 not present.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.197 %UTILCSV creates a CSV (Comma Separated Values/Variables)
UTILCSV or TAB or ANY-character-DELIMITED "text file" from any
Sep 14, 2007 SAS dataset, with the ability to order left-to-right and
to use FORMAT statements to control the output text.
Change 25.196 If you set %LET MACKEEP= %STR( lots of lines of text );
UTILBLDP before invoking %UTILBLDP, some of your MACKEEP code may
Sep 14, 2007 not get executed, leading to strange errors or unexpected
results. We now parse the text inside the macro language
into line-sized chunks to eliminate the exposure.
And while we were at it, we've created new arguments that
you can use for tailoring, as an alternative to using
%LET's for these macro variables:
Macro Variable Name Macro Argument Name
macfile macfilex
mackeep mackeepx
ihdrdb2h macdb2hx
ihdr110 mac110hx
One reason to use the Macro Argument in your UTILBLDP
rather than a %LET statement is that macro argument are
significantly more robust in that they do not need to
be wrapped in %STR() and we have NOT been able to find
any text string the argument couldn't handle, vs the
many combinations that have broken %QUOTE, etc. in %LETs!
However, you can use both a %LET macxxxx= and macxxxxx=
argument; the text in your %LET will preceed any text you
passed in the corresponding argument.
And, just to be sure, we now "chunk" any EXPDBOUT text.
Thanks to Michael Creech, Fidelity National Information Svcs, USA.
Change 25.195 Support for EMC's SRDF/A user SMF record.
VMACSRDF
VMXGINIT
EXSRDFAA
TYPESRDF
TYPSSRDF
IMACSRDF
Sep 13, 2007
Change 25.194 Variable SJGRQRST='JVM*REQUESTS*WITH RESET' in CICTCPSJ
VMAC110 CICS Statistics dataset is now created; while it does not
Sep 13, 2007 exist in CICS/TS 3.2 (resettable JVMs were withdrawn in
3.2 because continuous use JVMs save lots of CPU), it is
useful for detecting these bad guys in 2.3 and 3.1.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.193 MXG 25.08 Change 25.182 was incomplete, which caused the
IMACEXCL ERROR: LABEL IMACICU3 NOT FOUND when UTILEXCL was run.
UTILEXCL
Sep 13, 2007
Thanks to Christelle Abily, Groupe Informatique Credit Mutuel, FRANCE
Change 25.192 INPUT STATEMENT EXCEEDED RECORD LENGTH SMF ID=92 ST=14
VMAC92 because the SMF92DNR/SMF92DRN Rename Length/Name fields
Sep 11, 2007 only exist when the file is RENAMEd, and because the SMF
manual did not document that feature. Now, MXG confirms
that data exists prior to its INPUT.
Thanks to John Schoenbeck, AT&T Services, Inc, USA
Change 25.191 Support for RMF Monitor III CFI table segmentation in the
ASMRMFV ASMRMFV, and their input in VMACRMFV. New datasets
EXZRBCFC ZRBCFC is created from the CFICONNUS Connection Table,
IMACRMFV and the new variables in the CFISTRES Table are created
VMACRMFV when they exist (i.e., when CFIDETAIL was specified in
VMXGINIT RMF III parameters).
Sep 10, 2007
Sep 14, 2007
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.190 Variable QDBPPFIX='PGFIX*ATTRIBUTE' is now kept in the
VMACDB2 DB2STAT2 dataset; it was added in DB2 V8.1, in the same
Sep 8, 2007 location as QDBPVTPT, which is now always blank.
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 25.189 Revision to PDBOUT= options, when PDB=SMF is specified,
READDB2 and possible INCOMPATIBILITY when PDBOUT was null. Now,
ANALDB2R these options for PDBOUT= control output destination:
Sep 11, 2007 PDBOUT=, All datasets written to //WORK, always.
Sep 17, 2007 PDBOUT=PDB All datasets written to //PDB.
Sep 24, 2007 PDBOUT=YES All datasets written to their default
destination, with user tailoring honored.
PDBOUT=XXX ALL datasets written to //XXX.
This change could cause perfectly running jobs to fail,
if PDBOUT=, was specified and you had tailoring that
redirected the output dataset destinations. Sorry for
that, but using PDBOUT=YES instead of PDBOUT=PDB is now
the DOCUMENTED and SUPPORTED option to create output.
This revision was precipitated when ANALDB2R had been
invoked with PDBOUT=, and it failed with DDNAME PDB NOT
FOUND and _VDB2A UNDEFINED errors when no //PDB DD
existed.
Note: Only READDB2's code was changed; ANALDB2R calls
READDB2 with the same possible PDBOUT= argument,
so it is listed here for documentation
(that you'll only find after the error?).
Text revised Sep 17 for PDBOUT=PDB description.
-MXG 25.08 only, bit test for SADUCL=6 was one bit short;
only the list of Audit Trace Classes might be incorrect.
This was accidentally corrected in this change. 24Sep07.
Thanks to R. Berry, Internal Revenue Service, USA.
Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 25.188 If RMFINTRV=NO and BUILDPDB=YES and ASUM70PR included,
UTILBLDP the invocation failed because the TYPE70xx datasets were
Sep 7, 2007 not sorted into the PDB due to the RMFINTRV=NO. Now, as
expected, BUILDPDB=YES sorts them into the PDB library.
Thanks to Trevor Holland, ANZ, AUSTRALIA
====== Changes thru 25.186 were in MXG 25.08 dated Sep 5, 2007=========
Change 25.187 IBM SMF Manual incorrectly documented SMF92RVN value of 3
VMAC92 but that was corrected in z/OS 1.9 manual to correct 2,
Sep 5, 2007 so two MXG tests for SMF92RVN GE 3 were change to GE 2.
This corrected the bit variables SMF92MFG and SMF92MF2.
Variable SMF9PPN is a path name so it was increased to
$VARYING1024. with input length set by SMF92PPL.
Thanks to Hyrum E. Smith, Charles Schwab & Co., USA
Change 25.186 Variable DB2PARTY not found when PMACC02 requested and
ANALDB2R PDB.ASUMDB2A existed was corrected with a compiler faker.
Sep 5, 2007
Change 25.185 New Capacity Group datasets created by Change 25.163 did
IMACSHFT not have a DURATM variable for the ASUM70GC and ASUM70GL
VMXGDUR datasets; the interval is forced to HOURLY, but interval
VMXG70PR datasets should always have a DURATM variable.
Sep 5, 2007 I tested this change with %VMXG70PR(INTERVAL=SHIFT,...)
and found it caused VARIABLE MXGDURTM UNINITIALIZED notes
because MXGDURTM was not defined in IMACSHFT example, and
MXGDURTM was not always protected in VMXGDUR.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 25.184 RMF Capacity Group reports added to ANALRMFR. Support for
ANALRMFR new data was added by MXG Change 25.163.
Sep 5, 2007
Change 25.183 These WORK library datasets are now deleted; several PROC
TYPETMS5 DELETEs commented out for testing are now uncommented.
Sep 5, 2007 CHANGED DSNBREC DSNBRECS DSNBRECT DSNBRECU
DSNBRECV DSNBRECW MGTMSVL TMSREC TMSRECS
Thanks to John Shuck, Sun Trust, USA.
Thanks to Stan Helms, Sun Trust, USA.
Thanks to Mike Duwve, Sun Trust, USA.
====== Changes thru 25.182 were in MXG 25.08 dated Sep 5, 2007=========
Change 25.182 Support for CICS User Field ARZAL (CMODNAME='ARZAL' and
IMACICU3 CMODHEAD='APPLINFO' is added.
UTILEXCL
Sep 2, 2007
Thanks to Peter Gschirr, ARZ, AUSTRIA.
Change 25.181 Support for CA Unicenter NSM has been in MXG under "TNG"
EXTAI026 for years, because TNG was NSM's original name, and the
EXTNT132 "performance cube" format was not changed at name change.
EXTRH001 Support for CA NSM PLATFORM='RHEL401', RedHat 4.01 Linux
EXTRH002 performance cube is added by this change, which initially
EXTRH003 populates the Solaris "SOnnn" datasets, as they exist and
EXTRH004 have the most objects/metrics in common with Linux, but
EXTRH005 there are Solaris-only variables that have missing values
EXTRH006 and there are RHEL objects/metrics not yet supported.
EXTRH007
EXTRH008 This change also externalizes the list of PLATFORM names
EXTRH009 that map to AIX or SOLARIS with new _AIPLAT and _SOPLAT
EXTRH010 macros (like the existing _NTPLAT macro). And, that test
EXTRH011 is now IF PLATFORM IN : ( _NTPLAT ) THEN DO; with the
EXTRH012 "colon modifier" inserted so the test matches only the
EXTRH013 starting characters of the platform names. I did this
EXTRH014 when I thought RHEL was a user-assigned name, which it
EXTRH015 isn't, but these macros are no-cost tokens that will make
EXTRH016 my testing easier for new PLATFORM names.
EXTRH017
EXTRH018 New variables were added to these existing datasets:
IMACTNG Dataset Description
VMACTNG AI019 AIX - CA MEMORY GROUP
VMXGINIT NT035 NT - PROCESS
Sep 2, 2007 New datasets are created from these new objects:
Dataset Object Name
AI026 AIX - PROCESS
NT132 NT - CA CUBE STORE GROUP
-New datasets are created from Red Hat Platform Objects:
Dataset Object Name
RH001 RH - CA CPU GROUP
RH002 RH - CA INTERRUPT
RH003 RH - CA CUBE STORE GROUP
RH004 RH - CA PER CPU GROUP
RH005 RH - CONTEXT SWITCHING
RH006 RH - INTERRUPTS
RH007 RH - PAGING
RH008 RH - PROCESS CREATION
RH009 RH - SWAPPING
RH010 RH - CA DISK GROUP
RH011 RH - CA FILE SYSTEM GROUP
RH012 RH - CA INTERFACE GROUP
RH013 RH - CA MEMORY GROUP
RH014 RH - CA PROCESS GROUP
RH015 RH - CA SWAP GROUP
RH016 RH - CPU
RH017 RH - FILESYSTEM
RH018 RH - NETWORK
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.180 The Omegamon OMCI subtype 203 is now written in SMF 112s,
VMACOMCI but can still be created in the old User SMF record; MXG
Aug 29, 2007 Change 25.099 moved the 203 code into VMAC112, but also
disabled subtype 203 in VMACOMCI. This corrects.
But now see Change 26.257, which revised support.
Thanks to Tom Kelman, Commerce Bank of Kansas, USA.
Change 25.179 Protection for %UPCASE() and %LOWCASE() for literals.
ANALDBTR Almost all of the SAS code in MXG is in UPPER CASE, but
BLDSMPDB some members are mixed case, with "case sensitive" noted
GRAFHSM in their comments, but that did not prevent accidental
GRAFLPAR low-case-ing some lines in BLDSMPDB that contained tests
GRAFTALO if %upcase(something) eq yes %then %do;
GRAFTMNT which failed because the yes value was now lower case.
GRAFTRND Macro variable tests are in many MXG members, especially
GRAFWORK those that define %MACROS where user-typed input text is
GRAFWORX shifted with %UPCASE() for consistent testing, but I had
GRAFWRKX never thought to protect the text being compared!
PRINTNL
READDB2 Now, all members were examined that used %UPCASE/%LOWCASE
UTILBLDP and those that tested for literal text values now use
UTILCONT
UTILDUMP if %upcase(something) eq %upcase(yes) %then %do;
VMACMWNT
VMXGALOC The DATA step UPCASE() function is also used in even more
VMXGDEL members, but as those values are not 'human-typed', I did
VMXGGETM not see the need for also wrapping those text values.
VMXGSUM
VMXGSUME New MXG Recommendation: Use %LET MACxxxx= %STR( text ) ;
VMXGUOW with blanks as shown, when storing any text string that
Aug 28, 2007 can contain semi-colons, into those MXG tailoring macro
variables, since those macro variables will be resolved
at "compile time", which is where %STR() is to be used.
Previously I suggested using %QUOTE() or %BQUOTE() to
pass text with semi-colons, but they are not resolved
until "execute time", and, while QUOTE/BQUOTE frequently
did work, the use of %STR, especially for MACKEEP/MACFILE
macros is the more appropriate among the many functions.
Thanks to Tom kelman, Commerce Bank of Kansas, USA.
Change 25.178 Support for V5R4MO QAPMDISK with LRECL=456 adds these 20
VMACQACS variables:
Aug 28, 2007 DSBKCT1='BUCKET*1*OPERATIONS'
DSBKCT2='BUCKET*2*OPERATIONS'
DSBKCT3='BUCKET*3*OPERATIONS'
DSBKCT4='BUCKET*4*OPERATIONS'
DSBKCT5='BUCKET*5*OPERATIONS'
DSBKCT6='BUCKET*6*OPERATIONS'
DSBKRT1='BUCKET*1*RESPONSE*TIME'
DSBKRT2='BUCKET*2*RESPONSE*TIME'
DSBKRT3='BUCKET*1*RESPONSE*TIME'
DSBKRT4='BUCKET*4*RESPONSE*TIME'
DSBKRT5='BUCKET*5*RESPONSE*TIME'
DSBKRT6='BUCKET*6*RESPONSE*TIME'
DSBKST1='BUCKET*1*SERVICE*TIME'
DSBKST2='BUCKET*2*SERVICE*TIME'
DSBKST3='BUCKET*3*SERVICE*TIME'
DSBKST4='BUCKET*4*SERVICE*TIME'
DSBKST5='BUCKET*5*SERVICE*TIME'
DSBKST6='BUCKET*6*SERVICE*TIME'
DSSRVT ='DISK*SERVICE*TIME'
DSWT ='DISK*WAIT*TIME'
Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 25.177 ERROR: ARRAY SUBSCRIPT OUT OF RANGE in BUILDPDB/RMFINTRV
VMXGINIT with a month's SMF data from scores of systems. The
VMXGRMFI culprit is the MXG algorithm to calculate MSU4HRAV, the
Aug 24, 2007 rolling hourly average MSU over the past four hours,
created in RMFINTRV before IBM added the SMF70LAC value
(and SMF70LAC is the variable to use, not my MSU4HRAV,
as SMF70LAC is IBM's calculation that is used in WLM
capping decisions, and it is slightly different than the
MSU4HRAV, where I used total CPU and IBM didn't, and
where I calculate true average even across an IPL and
they don't!).
When MSU4HRAV was created, the size was set for a daily
or weekly RMFINTRV creation, so an array size of 9999
elements would hold hourly data for:
over 100 system's daily data at 15 minute intervals
over 14 system's weekly data at 15 minute intervals
but
only 3 system's monthly data at 15 minute intervals!
(and this site had 5 minute intervals!).
This is one of the MANY reasons why I avoid ARRAYs; while
increasing the ARRAY size will hold more system's data,
that requires more virtual storage, and that will grow as
the number of systems increase, exchanging OUT-OF-MEMORY
errors for OUT OF RANGE.
The immediate user circumvention was to process the SMF
data one week at a time, which worked just fine.
Though hopefully unneeded, I have externalized the size
of the three temporary arrays with new macro variable
with default value of %LET ARRAYRMF=9999; unchanged.
I have also inserted a trap to detect the array size was
exceeded and inform you via an ERROR message on the log.
Change 25.176 Support for APAR OA18244, Blocked Workload metrics, adds
VMAC7072 -These variables to the TYPE70 dataset:
Aug 24, 2007 SMF70PMI='AVG*BLKED*DISPATCH*UNITS*MAY GET'
SMF70PML='OPT*PARAMETER*BLWLINTHD'
SMF70PMP='MAX*DISPATCH*UNITS*BEING*BLOCKED'
SMF70PMT='OPT*PARAMETER*BLWLTRPCT'
(Note: The default you type is "5", but that will be
a value of .005 in SMF70PMT, i.e. one-half of a
percent. RMF reports that a .5% but the variable
is NOT labelled Percent so you need to know that
.005 is one-half percent default.
SMF70PMU='BLKED*DISPATCH*UNITS*PROMOTED*PERSEC'
SMF70PMW='AVG*DISPATCH*UNITS*BEING*BLOCKED'
STFBIT05='OPT PARM*BLWLTRPCT*CHANGED?
STFBIT06='OPT PARM*BLWLINTHD*CHANGED?
-This variable, previously added to the TYPE72GO dataset
by Change 25.140 is populated by this APAR:
R723TPDP='CPU TIME*AT PROMOTED*DISPATCH*PRTY'
and this new flag variable is created by this APAR:
ZIPHONPR='ZIP*HONOR*PRIORITY?'
Change 25.175 Internal logic was revised so when INTERVAL= is used, the
ANALRMFR variables LPARCPUX and SMF70BDA are added to the ID= parm
Aug 24, 2007 for Cluster Reports.
-Also, MVSCHRLV and NCYCLE are added to report headings.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.174 Corrections discovered by SAS/ITRM validation during the
ASUMTAPE build of their dictionary.
VMAC7072 -Variable JBACPU dataset QAPMJOBL now FORMATed TIME13.3.
VMACQACS -Variable MAXVLSEQ is no longer created/kept in TYPETMS5.
VMACTMS5 -Variables for CP/ICF/IFL/IFA/ZIP counts/time are labeled
VMXG70PR in VMXG70PR & VMAC7072, PROC DELETEs uncommented to clean
VMAC110 up WORK file. Variables IFAWSTTM,ZIPWSTTM formatted.
VMACDB2 -ASUMTAPE variables BEGTMNT, ENDTMNT, TOTMNTTM labeled.
VMACSTC -CICSDS variables DSGEJST DSGSRBT labeled and formatted;
Sep 5, 2007 they are the total TCB for all CICS TCBs and total SRB
for all SRBs in the interval.
-DB2ACCT variable QWHUCPU formatted.
-TYPESTC variable STC15CTP label corrected.
Sep 6 changes, not in 25.08:
-TYPE7072 - variables NRPHYCPX, NRPRCX no longer kept.
- variable GMTOFF70 GMTOFF72 formatted.
-TYPE85 - variables R85ST74F, R85ST78F labeled.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 25.173 -Support for NMON "CPU_VP_USE" and "CPU_EC_USE" objects
VMACNMON (Virtual Processor and Entitled Capacity) adds these new
Sep 1, 2007 variables to NMONINTV dataset:
NRECUS='CPU_EC_USE*COUNT'
NRVPUS='CPU_VP_USE*COUNT'
PCPUUSER='CPU_ALL*USER*PERCENT'
PECTOTAL='CPU_EC_USE*TOTAL*PERCENT'
PECUBUSY='CPU_EC_USE*BUSY*PERCENT'
PECUIDLE='CPU_EC_USE*IDLE*PERCENT'
PECUSYS='CPU_EC_USE*SYSTEM*PERCENT'
PECUUSER='CPU_EC_USE*USER*PERCENT'
PECUWAIT='CPU_EC_USE*WAIT*PERCENT'
PVPUBUSY='CPU_VP_USE*BUSY*PERCENT'
PVPUIDLE='CPU_VP_USE*IDLE*PERCENT'
PVPUSYS='CPU_VP_USE*SYSTEM*PERCENT'
PVPUUSER='CPU_VP_USE*USER*PERCENT'
PVPUWAIT='CPU_VP_USE*WAIT*PERCENT'
-Support for NMON NETSIZE object adds thes new variables
to NMONNETW dataset:
NETSRDRT='NETSIZE*READS/S'
NETSWRRT='NETSIZE*WRITE/S'
-The count of JFSFILE fields drops to less than the count
in the header record, occasionally, causing MXG to have
to delete of that record with an MXG ERROR MESSAGE on the
log. Under investigation with NMON support.
-The "UNKNOWN RECTYPE=" message for Nigel's Monitor NMON
is clarified to indicate it's not an error, but a new
monitor record that is not yet supported by MXG, but
will be if you send the input data file to MXG support.
Thanks to Michael W. Woelke, Boeing, USA.
Thanks to John Keenan, Boeing, USA.
Change 25.172 Example to process DB2 datasets to separate DDNAMES:
ADOCDB2 libname db2acctp 'c:\mxg\db2acctp\';
Aug 20, 2007 libname db2acctb 'c:\mxg\db2acctg\';
libname db2acctg 'c:\mxg\db2acctb\';
libname db2acct 'c:\mxg\db2acct\';
libname db2gbpat 'c:\mxg\db2gbpat\';
libname db2gbpst 'c:\mxg\db2gbpst\';
/* unsorted, written directly to individual DDNAME for parallelism */
%LET WDB2ACP=DB2ACCTP;
%LET WDB2ACB=DB2ACCTB;
%LET WDB2ACG=DB2ACCTG;
%LET WDB2PAT=DB2GBPAT;
%LET WDB2PST=DB2GBPST;
%LET PDB2ACC=DB2ACCT;
/* deflected to work, as they are combined into db2stats */
%LET PDB2STO=WORK;
%LET PDB2ST1=WORK;
/* sent to pdb, stats, should be small in size */
%LET PDB2ST2=PDB;
%LET PDB2ST4=PDB;
%LET PDB2STS=PDB;
%LET PDB2STB=PDB;
%LET PDB2STR=PDB;
%LET MACKEEP=
%BQUOTE(
MACRO _SDB2ACp %
MACRO _SDB2ACb %
MACRO _SDB2ACg %
MACRO _SDB2pat %
MACRO _SDB2pst %
MACRO _SDB2ACc %
);
%INCLUDE SOURCLIB(TYPEDB2);
or could be
%INCLUDE SOURCLIB(BUILDPDB);
or could be
%ANALDB2R(PDB=SMF);
Change 25.171 Documentation. The DOCVER and DOCVERnn text printed only
UTILVREF 3 positions for LENGTHs, causing a 32000-byte variable to
Aug 20, 2007 be printed as 3E4 in exponential format. While I can't
expand LENGTH to print 5 digits without truncating LABEL,
I now detect the TYPE='NUM' and print four positions for
those variables to be more accurate where I can. You can
always use PROC CONTENTS DATA=whatever; to see the actual
stored LENGTH of each variable.
See MXG Technical Note 2 in Newsletter FIFTY for a list
of "Very Long Stored Length" variables created by MXG.
Change 25.170 If there no Mount-Related SYSLOG messages were captured
ASUMTAPE by ASMTAPEE/MXGTMNT, i.e. TYPESYMT has zero observations
Aug 20, 2007 then there were no observations created in PDB.ASUMTAPE,
even though the TYPETMNT and TYPE21 records matched.
The missing SYSLOG records was due to backlevel ASMTAPEE
at ML-38 that missed messages now captured in ML-39, but
this revision tests for zero obs in TYPESYMT dataset, and
forces the OUTPUT of PDB.ASUMTAPE in that case. Note
that this only works when all systems do not capture the
SYSLOG data; if some systems do and others don't, this
revision will NOT work, and only systems with obs in the
TYPESYMT dataset will have output in PDB.ASUMTAPE.
Thanks to John Doherty, Capita, SCOTLAND.
Change 25.169 New DB2 Parallel event "analysis" selects all DB2ACCT obs
VMACDB2 for each "ACE group" that had any parallel activity,
Aug 18, 2007 (i.e., had one or more DB2ACCT obs with DB2PARTY=O/P/R),
keeps a large but manageable set of important variables,
and then PRINTs the detail DB2ACCT observations for each
"ACE Group", in time sequence, where each unique set of
values of these BY variables defines an "ACE Group":
SYSTEM QWHSSSID QWHSLOCN QLACLOCN QWHCCV QWHCCN ACE
and where ACE is either QWHSACE (S/O) or QWACPACE (P/R).
BUILDPDB does not sort PDB.DB2ACCT automatically, due to
it's size, but that turns out fortunate, as the default
sort order defined in MACRO _BDB2ACC in VMACDB2:
SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN QWHCCV
QLACLOCN QWHCCN QWACBSC QWHSSTCK,
is just fine for duplicate removal, so it's not "wrong",
but it is NOT the correct order to group all DB2ACCT obs
into their "ACE Group". Instead, the new report uses
uses this sort order (MACRO _XDB2ACC):
SYSTEM QWHSSSID QWHSLOCN QLACLOCN QWHCCV QWHCCN ACE
QWACBSC QWHSSTCK QWHCPLAN QWHCAID
that does correctly sort DB2ACCT into each "ACE Group".
This iteration defines old-style MACROs _Q, _X, _Y, _X
which are used by the MACRO _RDB2ACC that you execute:
// EXEC MXGSASV9
//PDB DD DSN=YOUR.DB2ACCT.PDB,DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(VMACDB2);
_RDB2ACC
This report was used for diagnostic understanding of the
events in DB2 Parallel, and thus is not likely to be used
by many MXG users, but it's there if needed. Also, the
structure of selecting all of a group that has one of
something (DB2 Parallel Transaction, in this case) could
easily be extended to select by some other criteria.
Change 25.168 Using %ANALDB2R(PDB=PDB,PMSTA02=YES); caused VMXGSUM to
VMXGSUM fail with ERROR: VARIABLE STRTTIME NOT FOUND. In this
Aug 17, 2007 one place in ANALDB2R, VMXGSUM was invoked with variable
STRTTIME used in the INCODE's internal DATA/PROC steps,
and it was in the KEEPIN= list, but STRTTIME was NOT in
any of the VMXGSUM output parameters. Now, variables in
the KEEPIN= list are added to the generated KEEP list to
protect for this unique VMXGSUM invocation.
The problem was introduced in MXG 25.04 VMXGSUM changes.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
Change 25.167 Variable FCUSERID='LOGIN*USER ID*OR NAME' is INPUT and
VMAC119 kept in the TYP11903 dataset.
Aug 16, 2007
Thanks to Jim Kovarik, Aegon, USA.
Change 25.166 Trending example for DB2ACCTP dataset.
TRNDDB2P
Aug 16, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.165 The IMF FB Program Record is updated with new variables:
VMACCIMS PGMSAD56='SADFLAG5*AND*SADFLAG6'
Aug 14, 2007 FLGSPCHR='PROGRAM*SUBTYPE'
The $MGIMFCS format decodes FLGSPCHR, which is OUTPUT
in both CIMSTRAN and CIMSPROG, but only the first
three values of J, K, or O exist in CICSPROG:
VALUE $MGIMFCS
'O'='O:ODBA'
'J'='J:JMP'
'K'='K:JBP'
'Q'='Q:PSEUDO WFI'
'W'='W:WFI(WAIT FOR INPUT)'
;
SAPEXIT ='SAP*PGM*USING*SAPEXIT?'
OTMATRAN='OTMA*TRAN?'
The offset to SRVCLASS was also corrected.
Thanks to Doug Johnson, Blue Cross Blue Shield of Kansas, USA.
Change 25.164 The _VNDMRJ macro token was missing in the _WNDMRJ part
VMACNDM of the _VARNDM macro definition, so the NDMRJ datasets
Aug 14, 2007 kept ALL MXG VARIABLES IN THE DATA STEP, 7062 variables
to be exact, when NDM code was added to BUILDPDB in ITRM
tests!
Thanks to Chris Weston, SAS Institute, USA.
Change 25.163 Support for Capacity Group analysis. z/OS 1.8 added the
VMAC7072 SMF70GNM='CAPACITY GROUP NAME'
VMXG70PR SMF70GMU='MAXIMUM LICENSE UNITS OF GROUP;
VMXGINIT variables, but Change 24.092 output them in TYPE70, when
Aug 20, 2007 they should have been output in PDB.TYPE70PR dataset, as
they are LPAR-level capacity limits.
-ASUM70PR now creates two new Group Capacity datasets
PDB.ASUM70GC - CEC Totals for each Capacity Group
PDB.ASUM70GL - LPAR Detail within each Capacity Group
Dataset ASUM70GL matches the RMF Group Capacity Report,
while dataset SUM70GC provides the total MSU usage for
each Group, and the percent of Group capacity limit used.
Both new datasets are created with fixed INTERVAL=HOUR,
to match SMF70GMU capacity units of MSU per hour.
Thanks to Jim Dammeyer, State Farm Insurance, USA.
Change 25.162 The final example in comments was missing a close-paren.
UTILBLDP
Aug 12, 2007
Thanks to Trevor Holland, ANZ, AUSTRALIA
====== Changes thru 25.161 were in MXG 25.07 dated Aug 10, 2007=========
Change 25.161 Support for new z/OS 1.9 RMF III and APAR OA17070 fields.
VMACRMFV New variables INPUT from the CFIG3 Header Section are
Aug 9, 2007 added to the ZRBCFI dataset:
CFIRANGE='REPORTING*RANGE*SECONDS'
CFIPONAM='POLICY*NAME'
CFIPOACT='POLICY*ACTIVATION*TIME'
CFIPREQS='NOT ALL*STRUCTURES*CONTAINED'
CFIPREQC='NOT ALL*CONNECTIONS*CONTAINED'
New variables INPUT from the CFIG3 Entry Section are
added to the ZRBCFI dataset:
CFIENSCN='CONNECTED*MVS*SYSTEM*COUNT'
CFIENSTI='STRUCTURE*COUNT*IN*POLICY'
CFIENSTO='STRUCTURE*COUNT*OUT*POLICY'
CFIENTCS='TOTAL*CONTROL*SPACE'
CFIENFCS='FREE*CONTROL*SPACE'
CFIENTDS='TOTAL*DUMP*SPACE'
CFIENFDS='FREE*DUMP*SPACE'
CFIENSCT='SUM WAIT*FREE FOR*SYNCH IMMED'
CFIENFOC='COUNT*OF TIMES*FOR UNSUCCESSFUL'
CFIENFOT='SUM OF*SERVICE*FOR*UNSUCCESSFUL'
CFIENPDE='DEDICATED*PROCESSORS'
CFIENPSH='SHARED*PROCESSORS'
CFIENPWG='SHARED*PROCESSOR*AVERAGE*WEIGHT'
New variables INPUT from the CFIG3 Table Entry Section
are added to the ZRBCFI dataset:
CFISTCOM='MAX*CONNECTIONS*ALLOWED'
CFISTCOT='TOTAL*CONNECTIONS*TO*STRUCTURE*
CFISTCOP='CONNECTIONS*WITH*PROBLEMS'
CFISTQTM='SERVICETM*SUM FOR*QUEUED*REQUESTS.
CFISTFLE='STATUS*FLAGS*EXTENDED'
CFISTRBP='REBUILDPERCENT*IN ACTIVE*CFRM'
CFISTPL ='CF*PREFERENCE*LIST'
CFISTXL ='STRUCTURE*EXCLUSION*LIST'
CFISTETM='STRUCURE*EXECUTION*TIME*SUM'
Change 25.160 Sample reports for Velocity Software data.
ANALXAMR
Aug 9, 2007
Thanks to Robert Obee, IMS Health(R), USA.
Change 25.159 Support for APAR OA12865 for RMF 79 Subtype 9 Device
VMAC79 Activity added variable R799PSM='SUCCESSFUL*PAV*SAMPLES'
Aug 9, 2007 and relabeled variable R799PCT='UNSUCCESSFUL*PAV*SAMPLES'
and now INPUTs R799NDA as 4 bytes instead of 2, so that
variables R799NDA,R799DPB,R799CMR,R799PCT,R799PSM now are
correct, and variable R799CNX6='HYPERPAV*BASE*DEVICE?' is
created.
-RMF II 79 subtype 9 records written at 1 minute intervals
have the accumulated values reset when RMF Monitor I pops
its interval, which caused MXG to set the DIF()'d
values missing; now, only the first observation for each
device will have missing values for the deaccumlations,
since I don't know the prior value from yesterday!
-R799NUX required special handling as it is accumulated
if the device is HyperPav, and is not otherwise.
Thanks to Mike Romeo, Schwab, USA.
Change 25.158 The %QUOTE function had to be replaced with the %BQUOTE
UTILBLDP function, because %QUOTE does not "mask" percent signs,
Aug 8, 2007 and the user-provided text can contain percent signs
that needed to be masked. When a user sets the text
%LET MACKEEP= MACRO _S110 %; and executes %UTILBLDP(...)
this %LET MACBLDP= %QUOTE(&MACKEEP); created the MACBLDP
with MACRO _S110 ) instead of MACRO _S110 % because the
%QUOTE function saw the end of the text as %) and that
pair of adjacent characters are a "special character"
that is, by design, changed to a single paren by %QUOTE.
The %BQUOTE masks these characters that aren't by %QUOTE:
unmarked percent signs
unmatched, unmarked single and double quotation marks
unmatched, unmarked opening and closing parentheses
This issue comes up most often in the %LET MACKEEP= text,
as its usage can have a wide range of character text.
I have previously suggested that when setting MACKEEP to
text that can contain a semicolon, you must use %QUOTE(),
but for old-style macro redefinitions like _S110, there
was no need for the complexity of the %QUOTE() syntax.
And it appears if there happened to be blanks in the
right places, even percent signs could be passed without
either function. Now, if you have semicolons or percents
depending on the context and state of the macro language,
%BQUOTEs may be required in your %LET statements.
Specifically this is required:
%LET MACKEEP=%BQUOTE( MACRO _S110 %) ;
Thanks to Carmen Vitullo, Acxiom IT Outsourcing, USA.
Change 25.157 Change 24.064 added &MXGNOBY operand to circumvent errors
MONTHDSK NOT SORTED, but the invocation of &MXGNOBY was not added
MONTHWEK the WEEKBLDT and MONTHDSK members, where it didn't work!
WEEKBLDT
Aug 6, 2007
Thanks to Randy Parker, Trustmark National Bank, USA.
Change 25.156 The ARRAY LWAI(33) $ LCPUWAI0-9 + were one-byte lengths,
VMAC7072 but ARRAY LDED(33) $ LCPUDED0-9 + were eight bytes long,
Aug 6, 2007 and I cannot see why they are different, but as they are
one-byte variables, their ARRAY statement now explicitly
sets their length with ARRAY xxxx (33) $1;
Change 25.155 Variables created with the SCAN() function are set by SAS
VMACCLAR to character length of $200, even though the input length
VMACNMON is only $128. While I believe SAS should set the output
Aug 6, 2007 length to $128, as WPS does, adding LENGTH statements did
circumvent this SAS problem. Other character handling
functions, like SUBSTR() do set the new variable's length
from the input variable's length.
Change 25.154 PROC MEANS does not pass variable attributes (LENGTH etc)
VMXG70PR to the output dataset unless / INHERIT is added to the
Aug 6, 2007 OUTPUT statement; MXG normally uses %VMXGSUM, which does
specify INHERIT, but the two new PROC MEANS added for the
new IFA/ZIP variables did not specify INHERIT, causing
wrong or blank LENGTH/LABEL/FORMATs for those variables.
Change 25.153 False ERROR: INVALID TYPE42 SUBTYPE 5 RECORD DELETED
VMAC42 were printed because the tests revised by Change 25.095
Aug 3, 2007 should be OFF+LEN GT LENGTH+1 vice GT LENGTH. The
record was valid, but, as the message stated, it was
deleted.
Thanks to Joachim Mayr, Amadeus, GERMANY.
Change 25.152 The analysis of input queue time for Duplicate JOB HOLD
ANALINIT used LASTEND=LAG(JINTTIME) for the start of the input
Aug 3, 2007 queue delay of the next Duplicate JOB NAME, but JINTTIME
is the Start Time of the last job, and, as documented in
Change 12.274, that LAG() function statement
(which returns the value of that variable from the
prior observation)
should have been LASTEND=LAG(JTRMTIME), so that this
job's delay is calculated from the End of Execution of
the prior job.
Thanks to Larry Riggen, OneAmerica, USA.
Change 25.151 The example JCLVMXA invokes PROC MEANS for all datasets,
VMACVMXA that would not normally be executed except for the first
Aug 3, 2007 test, but it failed be cause _MPRCAPC and _MPRCAPM were
not defined (those macro names in lines 20396,20397 were
misspelled). The MONWRITE datasets were correctly built;
Also, MXG 25.06 had a DEBUG=1; statement left from tests
that printed a lot of messages on the SAS log, but with
no impact on the SAS datasets that MXG created.
Thanks to Yaohua Hu, ISO, USA.
Change 25.150 The ASUM70PR summarization could (still!) create PCTCPUBY
VMXG70PR over 100%, if adjacent intervals being summarized had the
Aug 3, 2007 exact same value of STARTIME SMF70GIE and DURATM after
the INTERVAL= operand had reset STARTIME and SMF70GIE.
These DURATM was also incorrect (too small) in these bad
observations, but ALL OTHER VARIABLES ARE CORRECT.
It was the heuristic use of DURATM that seemed to work,
but is now recognized as the culprit, as it failed when
two adjacent DURATMs were identical. Now, by instead
using the OLDSTART, the original unmodified interval
start, and inserting it in internal sorts in place of
DURATM, and testing IF FIRST.OLDSTART vice FIRST.DURATM
there's a clean algorithm for new intervals and this old
recurring problem should be fixed for good.
-Summarization with INTERVAL=SHIFT did not work, because
MXG can not know the duration of each of your shifts, and
message VARIABLE MXGDURTM UNINITIALIZED was printed.
However, if you will add a statement in your IMACSHFT
tailoring member for each shift, that sets then variable
MXGDURTM=nnnnn;, where nnnnn is the duration in seconds
(e.g., MXGDURTM=28800; for an 8-hour shift), then you can
INTERVAL=SHIFT to summarize PDB.ASUM70PR & PDB.ASUM70LP
to your shift definitions.
-Summarization with CECINTRV=SHIFT is also now supported,
proved you tailor IMACSHFT to set MXGDURTM, as above.
The MXG note that SHIFT could not be used is removed.
Thanks to Debby Blackey, HCA HealthCare, USA.
Change 25.149 The SAS/ITRM product (formerly SAS/ITSV) executes MXG to
ADOCITRM create its SAS datasets, but the MXG dataset names are
Aug 2, 2007 changed by ITRM. This member's table maps the ITRM names
to the original MXG dataset name.
Change 25.148 A tutorial on how MXG normally creates SORTed datasets,
ADOCDB2 two exceptions, and an MXG tailoring example that writes
Aug 1, 2007 the DB2ACCTB and DB2ACCTP datasets to separate DDNAMES,
also bypassing their SORTs.
MXG normally builds datasets that are PROC SORTed, and
the sort order can be exploited in subsequent programs
to avoid unneeded sorts. MXG's SORTs specify the NODUP
SAS option, which removes any duplicate SMF records.
However, two datasets, DB2ACCT and CICSTRAN have never
been SORTed by default, as they were always known to be
very large. So their "dataset sort _Sdddddd" tokens,
_SDB2ACC and _SCICTRN, were NOT in the default list of
datasets to be sorted in VMACDB2 and VMAC110 defaults.
With hindsight, I should also have NOT included SORTs of
the DB2 per-buffer (DB2ACCTB) and per-package (DB2ACCTP)
datasets, which now can be as large or larger than, their
DB2ACCT counterpart!
But now that MXG has sorted those datasets by default,
I can not safely remove those SORTs, without high risk
of causing a user program to unnecessarily fail. But,
you can use this MXG tailoring example to write them
to separate DDnames, and bypass their dataset sorts:
// EXEC MXGSASV9
//SMF DD DSN=YOUR.SMF,DISP=SHR
//DB2ACCT DD DSN=YOUR.DB2ACCT,DISP=(,CATLG),...
//DB2ACCTB DD DSN=YOUR.DB2ACCTB,DISP=(,CATLG),...
//DB2ACCTP DD DSN=YOUR.DB2ACCTP,DISP=(,CATLG),...
//PDB DD DSN=YOUR.OTHER.DB2.STUFF,DISP=(,CATLG),..
//SYSIN DD *
%LET WDB2ACC=DB2ACCT; /*DDNAME for DB2ACCT */
%LET WDB2ACB=DB2ACCTB; /*DDNAME for DB2ACCTB*/
%LET WDB2ACP=DB2ACCTP; /*DDNAME for DB2ACCTP*/
%LET MACKEEP=
MACRO _SDB2ACB % /*BYPASS DB2ACCTB SORT*/
MACRO _SDB2ACP % /*BYPASS DB2ACCTP SORT*/
;
%INCLUDE SOURCLIB(BUILDPDB);
RUN;
This same tailoring, using a %LET Wdddddd=DDNAME;
statement to name the output DDname for the "Work"
copy of a dataset, and using %LET MACKEEP= as shown to
define MACRO _Sdddddd % (i.e., to a blank value) can be
used for any other large dataset that you want written
to a separate DDNAME, unsorted, as your SMF data is read.
Change 25.147 Almost cosmetic. The IMACxxxx/MACxxxx tokens that were
VMACQACS defined for VMACQACS were the old IMACQAPM/MACQAPM tokens
VMXGINIT from when AS/400 support was in VMACQAPM, and I decided
Aug 1, 2007 to change the VMAC to QACS but still use the QAPM token
so existing AS/400 tailoring wouldn't need to be changed.
However, this is inconsistent for new users, so this
change adds the include of IMACQACS and created MACQACS,
so the expected token names are found, but the old tokens
are still invoked, so existing tailoring still works.
Thanks to Philip Downes, Fortis Bank, BELGIUM.
Change 25.146 Using PDB=SMF could cause ERROR: NO DATASETS TO LOOKUP
ANALRMFR because SPLIT70 changes were not fully implemented.
Aug 1, 2007 A circumvention was to use TYPS7072 first to create the
PDB datasets, and then use PDB=PDB in the %ANALRMFR,
but this change corrects the error.
Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA.
Change 25.145 RMF III dataset ZRBLCP might have no observations for
VMACRMFV many LPARs, due to an MXG error in its "SKIP" logic that
Aug 1, 2007 prematurely ended the scan over all LPARs.
The statement SKIP=CPUCPLEN-32-1280; was replaced with
the statement SKIP=CPUCPLEN-LPARPROF-LPARPRLN*LPARPRNR;
Thanks to Erik Torp, IMT Nordic IBM, DENMARK.
Change 25.144 For ASCII execution, the FULLSTIMER option (MXG default)
UPCMEMSZ will print the memory used by each DATA/PROC step. One
Jul 31, 2007 way to determine how much virtual memory is available to
your MXG programs is to execute this new utility
%INCLUDE SOURCLIB(UPCMEMSZ);
which iterates the number of variables allocated in a
temporary array of 32K-length-character-variables so the
array size varies from 150MB up to 3GB. You look on the
log for the last successful step prior to the ERRORs:
FATAL: Insufficient memory to execute data step
program. Aborted during the COMPILATION phase.
NOTE: The SAS System stopped processing this step
because of insufficient memory.
In my Windows/XP system with SAS 9.1.3, that last step
allocated ARRAY TESTMEMSIZE (30000) $32000 _TEMPORARY_;
and used 938,107 kbytes, or 916 MegaBytes
Change 25.143 MXG sets each of the 135 SWAP rate variables in TYPE71 to
VMAC71 a missing value if that field was zero and the field was
VMXGINIT INPUT, but that design is inconsistent with MXG's use of
Jul 29, 2007 missing values. Normally, an MXG variable has a missing
value, a value different from a "zero", when:
- the event didn't happen, like a datetimestamp JSTRTIME
for a JCL error - the job never "started".
- a new variable is not INPUT, because that new product
is not yet installed at your site.
- an old variable that no longer exists (like PERFGRP)
is no longer INPUT because the record segment is no
longer written.
This design is not perfect; if the new variable is INPUT
because it was added to an already-existing-segment, or
if the old variable is still INPUT because it's segment
exists, they will have a zero value instead of a missing
value, but examination of missing values with PROC MEANS
is used in MXG validation and technical support.
Back when these swap rates were added to the TYPE71,
most were zero, but I wanted blanks when PROC PRINTed,
so by setting their zero values to a missing value, and
using an OPTIONS MISSING=' '; statement, SAS printed
blanks instead of a sea of zeros or periods.
Since TYPE71 always been this way, I'm reluctant to make
changes to my default, but new &MXGMISS macro variable is
now defined in VMXGINIT:
%LET MXGMISS = GT 0 ;
and it referenced in VMAC71 for each swaprate with logic
IF variable &MXGMISS THEN variable=variable*INTTIME;
ELSE variable=.'
so you can put this statement in your IMACKEEP or SYSIN
%LET MXGMISS = GE 0 ;
and any zero values will no longer be missing values.
Advanced SAS notes:
a. I first defined MACRO _GT0 GT 0 % in VMAC71 member,
so it could be redefined with the MACKEEP, but its
re-execution caused unrelated code with ' GT 0 ' to
be seen as ' GT 0 0 ', causing compiler errors.
b. I tested IF X &MXGMISS THEN ... syntax for the case
when the variable MXGMISS was not defined, which
would happen if your site (unwisely) has a tailored
VMXGINIT member. Although there are UNRESOLVED
MACRO VARIABLE messages and one NOTE: VARIABLE
MXGMISS IS UNINITIALIZED, the end result
I also discovered that the value of &MXGMISS macro
variable, when it is undefined, is the MXGMISS text,
rather than the blank value I had assumed/presumed!
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.142 Change 18.211 identified most _xxxxID macro tokens that
IMACIPAC are "reversed" from the normal _IDxxxx syntax, but that
VMACIPAC change only updated member UTILBLDP so it would know of
Jul 29, 2007 those inconsistent _ID macro names. This change defines
new, "correct" _IDxxxx macro names for those products,
and modifies the SMF Record ID test syntax to
IF ID=_IDxxxx OR ID=_xxxxID THEN DO;
so that your old definition in your IMACKEEP tailoring
with MACRO _xxxxID nnn % does NOT need to be changed, but
more importantly, so that new users who use the expected
MACRO _IDxxxx nnn % will never find out about this MXG
inconsistency. These members were identified:
ARB, DLMN, DMON, HBUF, HURN, IPAC, M204, NSPY, PDSM,
RMDS, ROSC, RTE, SYNC, TSOM, VVDS, WYLA, WYLB, X37.
Thus far, this change has only been made to these xxxx:
IPAC
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 25.141 IBM APAR OA21799 corrects invalid values for SMF78HIX,
VMAC78 the offset to the new-with-HYPERPAV (SMF78HPS) segments
Jul 27, 2007 in RMF 78 Subtype 3 records. The value in SMF78HIX:
-sometimes exceeded the physical record length, causing
the MXG job to ABEND with this error message:
INPUT STATEMENT EXCEEDED RECORD LENGTH
-sometimes pointed to the wrong LCUID. MXG compares the
LCUID/R783ID2 from the old SMF78ASS segment with the
R783HLCU from the new SMF78HPS, and printed messages:
***ERROR.VMAC78 LCUID=002E DOES NOT MATCH R783HLCU=002F
HyperPAV support was shipped by IBM with APAR OA12865.
This change prevents the ABEND without the APAR installed
by validating SMF78HIX before the INPUT of the HYPERPAV
variables. Also, these new HyperPav variables:
R783HLCU R783HCU R783HNAI R783HTIO R783HAIU
R783HCAD R783HIOQ
are set missing when LCUID mismatch or beyond-record-HIX
is detected. Only 10 error messages will be printed.
-The actual records that contained invalid SMF78HIX values
happened to also be "SPLIT 78" records, i.e., multiple
records written for an interval when the data won't fit
in one 32K SMF record.
But split 78 records are not new; even before HyperPav,
records are split if there are more than 80 LCUIDs.
Fortunately, MXG has always created observations in the
TYPE78CF (Configuration, from the SMF78DCS segments, and
TYPE78CU (Control Unit, from the SMF78ASS and SMF78HPS
segments), since split records are fully self-contained
for each group of LCUIDs for those three segments that
create those two datasets.
But, UnFortunately, when 78 records are split, the 588
byte I/O Queue Global segment (pointed to SMF78QDS) is
repeated in each split record, causing duplicate,
triplicate, or more replicas of each interval's data to
be output in the TYPE78IO per-IOPIQID dataset. I think
the SMF78QDS data should have been written only in the
first split record, but now that I see what IBM does, the
change now only outputs TYPE78IO when SMF78RSQ is zero or
one; zero is the value in an un-split record, one is the
first record when records are split.
P.S. Because the split records have slightly different
values in SMFTIME, these duplicates cannot be
automatically recognized as dupes with the NODUP
option in PROC SORT after the fact; they must be
prevented up front.
-No one has noticed/reported the duplicate TYPE78IO data,
and only two sites encountered the ABEND in their daily
BUILDPDB due to the invalid SMF78HIX, but IBM immediately
accepted the problem and created the APAR to correct the
error. But RMF 78s are automatically processed by MXG's
BUILDPDB job, so the behind-the-scene installation of
HyperPAV might cause a fine-running-daily-accounting-JOB
to ABEND, so do not overlook this Change and/or APAR.
Thanks to Sam Knutson, Geico, USA.
Thanks to Mike Lewellen, Charles Schwab & Co., USA.
Change 25.140 Support for z/OS 1.9 (very minor additions, COMPATIBLE).
ADOC6 - Variables SMF22ETY and SMF22FNC values are formatted
EXTY8223 and decoded by existing MG022FN, MG022ET formats.
EXTY9214 - Variable R723TPDP='CPU TIME AT*PROMOTED*DISPATCH*PRTY'
IMAC82 is added to TYPE72GO dataset.
IMAC92 - Variables
VMAC1718 R742PSTM='MORE*PATH*STATUS*FLAGS'
VMAC22 R742PRCT='PATH*RETRY*COUNT'
VMAC30 R742PPND='CURR*PENDING*SIGNALS*OUTBOUND'
VMAC7072 R742PUSE='CURRENT*BLOCKS OF*BUFF SPACE*USED'
VMAC71 are added to the TYPE74PA dataset.
VMAC74 - Variables
VMAC79 R742MST1='EXTENDED*MEMBER*STATE*ONE'
VMAC82 R742MST2='EXTENDED*MEMBER*STATE*TWO'
VMAC92 R742MINT='STATUS*CHECKING*INTERVAL'
VMXGINIT R742MJOB='JOB THAT*JOINED*MEMBER'
Jul 26, 2007 are added to the TYPE74ME dataset.
- Variables
R744FPSN='NUMBER OF*SHARED*CF*PROCESSORS'
R744FPDN='NUMBER OF*DEDICATED*CF*PROCESSORS'
CFPTYP01='1ST CF*CPU*PROCESSOR*TYPE' thru
CFPTYP16='16TH CF*CPU*PROCESSOR*TYPE'
CFPWGT01='1ST CF*SHARED*PROCESSOR*WEIGHT' thru
CFPWGT16='16TH CF*SHARED*PROCESSOR*WEIGHT'
are added to the TYPE74CF dataset.
- Variable
R744SETM='STRUCTURE*EXECUTION*TIME'
are added to the TYPE74ST dataset.
- Variable
R791EXCW='EXCP*COUNT'
are added to the TYPE791 dataset.
- Variable
R792EXCW='EXCP*COUNT'
are added to the TYPE792 dataset.
- Variable
SMF82TKS='TKDS NAME'
are added to the TYPE8201 dataset.
- New dataset TYPE8223 dataset contains
SMF82TKF='TKDS*BITS'
SMF82TKH='TKDS*HANDLE*BEING*PROCESSED'
SMF82TKN='TKDS*NAME'
- New dataset TYPE9214 dataset contains
SMF92DDN='UNIQUE*DEVICE*NUMBER*FOR FILE'
SMF92DFG='FLAGS*80X=*RENAME'
SMF92DFN='NAME OF FILE*DELETED OR*RENAMED'
SMF92DFS='FILE*SYSTEM*NAME/
SMF92DFT='DATETIME OF*DELETE'
SMF92DIN='FILE*SERIAL*NUMBER'
SMF92DIP='FILE*SERIAL*NUMBER*OF PARENT'
SMF92DNL='LENGTH OF*FILE NAME*FOR DELETE'
SMF92DNR='LENGTH OF*FILE NAME*FOR RENAME'
SMF92DRN='NEW NAME*THAT WAS*RENAMED'
SMF92DTY='FILE TYPE*AS DEFINED IN*BPXYFTYP'
new variables.
-APAR OA17070 Additions to RMF 74-4 Coupling Facility CF
records provides the RMF support for accounting and the
measurement extensions of CF level 15. The COMPATIBLE
record change to RMF 74 records added these new data:
- Variables
R744FPSN='NUMBER OF*SHARED*CF*PROCESSORS'
R744FPDN='NUMBER OF*DEDICATED*CF*PROCESSORS'
CFPTYP01='1ST CF*CPU*PROCESSOR*TYPE'
thru
CFPTYP16='16TH CF*CPU*PROCESSOR*TYPE'
CFPWGT01='1ST CF*SHARED*PROCESSOR*WEIGHT'
thru
CFPWGT16='16TH CF*SHARED*PROCESSOR*WEIGHT'
are added to the TYPE74CF dataset.
- Variable
R744SETM='STRUCTURE*EXECUTION*TIME'
are added to the TYPE74ST dataset.
Change 25.139 Support for IMF Version 4.3 (INCOMPATIBLE). Part of that
VMACCIMS incompatibility was because MXG tested IMSVERS LT '13'
Jul 14, 2007 (because CIMS/Boole made major record format changes when
IMS 1.3 replaced IMS 1.2 years ago), but now, IMSVERS has
'1010' for IMS Version 10, causing MXG to try to read the
current records with ancient 1.2 code. However, many new
new fields were inserted by IMF 4.3, which relocated the
DBD segments incompatibly; this won't happen again, as
one of the new fields added is the OFFDBTRL, the offset
to the DBD segments. These new variables are created
in the CIMSTRAN dataset:
TRNARVTH TRNARVTJ TRNE1STD TRNEAPPL TRNEAPPU TRNEDB2
TRNEDB2U TRNEDLDB TRNEDLTM TRNEF2 TRNELDLI TRNEMQS
TRNEMQSU TRNEOESS TRNEOESU TRNEOPCL TRNESYNC TRNETFLG
TRNETIME TRNEWLMC TRNMODET TRNMSCTH TRNMSCTJ TRNMSCUT
TRNNUOWP TRNOTCLF TRNOTCLN TRNOTCON TRNOTCOR TRNOTIP
TRNOTMAM TRNOTMAP TRNOTPRT TRNOTSCF TRNOTSLF TRNOTSOC
TRNOTSTC TRNOTSTF TRNOTSYF TRNOTUSR TRNRSENM TRNSMQGN
TRNSTCKE TRNSTOPA TRNSTOPU TRNSTRTA TRNSTRTU TRNTCPU
TRNUOW TRNW1OTH TRNW2IOO TRNW2IOV TRNW2LCH TRNW2OTH
TRNW3LCH TRNW3OTH TRNW4DBR TRNW4IO TRNW4OTH TRNW5IOD
TRNW5IOO TRNW5IOV TRNW5LCH TRNW5LCK TRNW5OTH TRNWLMRE
TRNWLMRT TRNWLMSC TRNWLMZR TRNXCKPC TRNXCKPM TRNXCKPT
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 25.138 Support for APAR OA20314 which adds two variables
VMAC89 SMF89LPN='LPAR*NAME'
Jul 14, 2007 SMF89ZNA='LICENSE*ZNALC*IN*EFFECT?'
to both TYPE89 and TYPE892 datasets.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.137 INPUT STATEMENT EXCEEDED RECORD LENGTH error with SMF 80
VMAC80A record that contained new TOKDANAMs CPUTIMEMAX,
Jul 13, 2007 ASSIZEMAX and FILEPROCMAX segments, because MXG did not
protect for unknown tokens. This fix protects so the
record will be read and the new tokens will be skipped.
This change and text will be revised to support those
three new tokens.
Thanks to Gerald Nagao, University of California, USA.
Change 25.136 Two utility programs to count PDS Directory Blocks used
TYPELPDS and defined.
UTILLPDS The first example, in TYPELPDS, uses IBM LISTVTOC and
Jul 4, 2007 LISTPDS programs to create flatfiles that are then read
Aug 7, 2007 in a second SAS step (so this could be used by sites with
SAS only on ASCII), and it captures all PDS on a volume,
with no prior knowledge of their DSNAMES.
The second example, in UTILLPDS, is a SAS example that
gets the blocks for a single dataset.
Christa requested the facility. Chuck wrote TYPELPDS.
Geert contributed UTILLPDS. I wrote the change/comments.
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to Christa Neven, KBC Bankverzekerinngsholding, BELGIUM.
Thanks to Geert De Batselier KBC Bankverzekerinngsholding, BELGIUM.
Change 25.135A The label for TYPE70PR variables LCPUCAP and LCPUCAPC now
TYPE7072 include "Hard CAP" because those flag variables are set
Jul 4, 2007 'Y' when Hard Capping was specified when the LPAR was
defined (LCPUCAP) or if the Hard Capping status of the
LPAR was changed during this interval (LCPUCAPC). Hard
Capping tells PR/SM to cap resources delivered to that
LPAR at that LPAR's Designated Share (which is derived
from the weight given to this LPAR versus the total of
the weights you gave all of the other LPARs in the CEC).
Once an LPAR specified as hard capped reaches its
designated share, that LPAR is then "hard capped" and
normally does not receive more than its share of total
CEC resources.
Soft capping of an LPAR is done by WLM in response to
license manager determining that the LPAR's rolling
4-hour average MSU has exceeded the MSU specified for the
LPAR. A Soft Capped LPAR will have PDB.TYPE70PR variable
LPARNSW='PERCENT*LPAR SOFT*CAPPED' nonzero in soft capped
intervals (and LPnNSW variables nonzero in PDB.ASUM70xx
ASUMCExx summary datasets).
To further confuse the issue, there can be resource group
capping of service classes based on Resource Group
specifications.
Even more confusing is that Discretionary Management
algorithms can cap a service class period that is a
candidate for Discretionary Mangement if it significantly
exceeds its performance goal (PI LT 0.71), and this
Discretionary Management cap will show up even though the
service class is not assigned a Resource Group cap.
Thanks to ???, ???, FRANCE, for asking why LCPUCAP was never 'Y'.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
the above answers.
Change 25.135 %ANALRMFR(PDB=PDB,REPORT=DEVC,DEVICEC=20) caused several
ANALRMFR errors (variables CPUTYPE CPUVERSN, variable CAIM NOT
Jul 4, 2007 FOUND). A list with dashed names CPUSER0-CPUSER9 was
enumerated and CAIM was removed (no such variable), and
UNINITIALIZED VARIABLES SMF70CPA and SMF70WLA were fixed
by their addition to ID statements where needed. But the
removal of CPUTYPE and CPUVERSN from the TEMP74 ID list
was the correct revision, because the don't exist when
a report for only RMF 74 records is requested.
Thanks to Esti Sas, Bank Lemui, ISRAEL.
====== Changes thru 25.134 were in MXG 25.06 dated Jul 4, 2007=========
Change 25.134 Support for IRRDBU00 record types 0560, 0561, 0562 and
EXRAC560 05C0 create four new datasets (all of which, unlike prior
EXRAC561 IRRDBU00 records, contain multiple segments per record).
EXRAC562 dddddd Dataset Description
IMACRACF RAC560 RACF0560 GEN RES CERTIFICATE DATA
VMACRACF RAC561 RACF0561 GEN RES CERTIFICATE REFERENCE
VMXGINIT RAC562 RACF0562 GEN RES KEY RING DATA
Jul 3, 2007 RAC5C0 RACF05C0 GEN RES CDTINFO DATA
Thanks to Aimee Steele, Euroclear, BELGIUM.
Change 25.133 Support for Williams Data Systems FERRET product user SMF
EXFERTCP creates three new datasets:
EXFERTEE
EXFERTRT DDDDDD MXG MXG
IMACFERT DATASET DATASET DATASET
TYPEFERT SUFFIX NAME LABEL
TYPSFERT
VMACFERT FERTCP FERRETCP FERRET CP SUBTYPE 1
VMXGINIT FERTEE FERRETEE FERRET EE SUBTYPE 2
Jun 30, 2007 FERTRT FERRETRT FERRET RTP SUBTYPE 3
Change 25.132 AS400 TYPECONF variables GDESCL,GDESCN,GDESED,GDESET, and
VMACQACS GDES91 are now kept, GDES2 is formatted TIME8, and GDES3
Jun 30, 2007 is now INPUT as $7 (Model+System-TYPE - e.g., 8709406).
Date/Time variables GDESED, GDESET are character text, so
they cannot be formatted, but new GDESEDD and GDESETT are
numeric variables with DATE9 and TIME8 formats.
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND.
Change 25.131 -Support for RACFEVNTs 52 (SET UID) and 79 (CRL PUBLISH)
EXTY8052 creates two new datasets from SMF 80 records:
EXTY8079 DDDDDD MXG MXG
IMAC80A DATASET DATASET DATASET
VMAC80A TY8052 TYPE8052 RACF EVT 52 SET UID
VMXGINIT TY8079 TYPE8079 RACF EVT 79 CRL PUBLISH
Jun 30, 2007 -Support for TOP SECRET records with RACFVRSN '90'x.
Jul 2, 2007 The '90'x records contain ONLY the "standard" relocate
sections (they have SMF80DTP=RACFTYPE values 1-255, there
are NRSET sections, and they are located at OFFSET), and
the header ends at SMF80VER/RACFVRSN, the "short" CA SMF
80 header, which is different than the "standard" IBM 80
record header; MXG has always detected IBM vs TOP SECRET
format based on RACFVRSN and found the short header.
-Support for TOP SECRET records with RACFVRSN '00'x is an
INCOMPATIBLE change that required new logic to detect the
new and different format. The '00'x records contain ONLY
the "extended" relocate sections (they have segment type
SMF80TP2=EXTLNTYP values of 256-65535, there are SMF80OC2
sections, and they are located at SMF80OC2), but the '00'
records now have the "full" IBM header (thru SMF80RSV).
And, of course, CA changed the SMF80OC2 offset value in
the '00'x, but not in the '90'x, to match the way IBM
has always (incorrectly!) set OFFSET and SMF80OC2:
In all other IBM SMF records, offsets are from the RDW
and the INPUT is @OFFSET-3, but the IBM SMF 80s have
always required @OFFSET+1. The original and '90'x Top
Secret records require -3, the new ones require +1.
-The MXG code that formerly created TYPE80A and TYPE80CM
datasets has been changed, and there now should never be
any observations written to those datasets. Previously,
TYPE80A was OUTPUT if NRSET=0 (e.g., RACFEVNT=79 that
has only extended relocate segments), and TYPE80CM was
OUTPUT when an unknown SMF80DTP segment type was found.
TYPE80A now will contain obs only if the SMF 80 records
has no segments: OUTPUT only if NRSET=0 AND SMF80OC2=0.
TYPE80CM will contain obs only if SMF 80 records contain
relocate sections (standard or extended) that MXG does
not (yet) decode, but if you send your SMF records to
support@mxg.com, those segments will be decoded and those
observations will go away.
-Top Secret Documentation: MXG decodes the Top-Secret-Only
SMF80DTP segment values of 103, 104, 105, 109, and 114,
and outputs one observation in the TYPE80TS for each
segment (i.e., multiple observations from one SMF 80
record). MXG also outputs one observation per record to
the appropriate TYPE80xx dataset for that RACFEVNT=xx,
with all the "IBM" variables from the relocatable DTP/DT2
segments.
-New Top Secret DTP=115 and DTP=116 segments will be
decoded and output to TYPE80TS when documentation is
received; this text will be updated when completed.
Thanks to Greg Burt, Fifth Third Bank, USA.
Change 25.130 Support for Clarion Disk Array flat files creates new
EXCLARDI datasets:
EXCLARLU DDDDDD MXG MXG
EXCLARPO DATASET DATASET DATASET
EXCLARRA SUFFIX NAME LABEL
EXCLARSA
EXCLARSN CLARDI CLARDISK CLARION ARRAY DISK DATA
EXCLARSP CLARLU CLARLUN CLARION ARRAY LUN DATA
IMACCLAR CLARPO CLARPORT CLARION ARRAY PORT DATA
TYPECLAR CLARRA CLARRAID CLARION ARRAY RAID DATA
TYPSCLAR CLARSA CLARSAN CLARION ARRAY SAN DATA
VMACCLAR CLARSN CLARSNAP CLARION ARRAY SNAP DATA
VMXGINIT CLARSP CLARSP CLARION ARRAY SP DATA
Jun 29, 2007 Jul 5: Variable OBJECT removed from BY lists as it is
Jul 5, 2007 subordinate to their OWNERNAM, and it's parsed pieces
are already available in the other BY variables.
Thanks to Jim Quigley, ConEd, USA.
Change 25.129 Variable QW0224PN and QW0224CI are now created in the
VMAC102 T102S224 DB2 Trace IFCID=224 dataset.
Jun 29, 2007
Thanks to Christa Neven, KBC Bankverzekerinngsholding, BELGIUM.
Change 25.128 Variable UBRECRD is now formatted with $MGDCORF, and is
VMACDCOL INPUT as $CHAR1 instead of $EBCDIC1 so it is valid on the
Jun 27, 2007 ASCII platform as well as on EBDIC, and it is set to
LENGTH $1 (without the LENGTH set to $1, the length of
the format item, $MGDCORF, is used by SAS for the length
of the variable, wasting space).
Thanks to Trevor Ede, EDS New Zealand Limited, NEW ZEALAND.
Change 25.127 Support for Oracle Version 10 has been in place since MXG
VMACORAC Version 24.06, as there were no changes in the physical
Jun 27, 2007 contents of their user SMF record. However, V10 data for
Oct 16, 2008 the Kernel fields (MXG variables LOGREADS PHYREADS
LOGWRTS DMLCOMIT DMLROLLS DEADLOCK) is trashed with very
large values in the initial test records; a problem has
been opened with Oracle Technical Support and this note
will be updated when a fix is available from Oracle.
Oct 2008 update:
The incorrect I/O counts appear to have been fixed in
Oracle 10.2.0.3. The SMF fix 6725982 also requires fix
6138068 and 6646861.
Thanks to Sudie Wulfert-Shcickendanz, Anheuser-Busch, USA.
Change 25.126 Circumvention to skip new TMC 'FF20'x Volume Definition
VMACTMS5 record, awaiting doc and data to decode.
Aug 7, 2007
Change 25.125 VGETOBS added conditional use a DATA step for testing,
VGETOBS but that revision was removed and would not be executed.
Aug 7, 2007
Change 25.124 Preliminary changes to support testing of MXG under WPS.
AUTOEXEW -Member CONFIGW2 defines the SAS options for WPS execution
CONFIGW2 on z/OS platforms. Some SAS options do not yet exist in
MXGWPSV2 WPS, and some are no longer needed or are not changeable.
VMXGINIT It must be the last dataset in the //CONFIG DD in your
Jun 25, 2007 MXGWPSV2 JCL procedure.
Aug 8, 2007 -Member AUTOEXEW defines the SAS options for WPS execution
Sep 25, 2007 on ASCII platforms.
VMACSMF -VMXGINIT set new GLOBALed macro variable &WPSVER=2 when
execution under WPS V2 is detected, and sets the existing
macro variable &SASVER=8, so that MXG will generate code
for the SAS V8 environment that WPS V2 replicates.
Sep 25: test for SASVER EQ 2.00 in VMXGINIT was changed
to LT 6 when WPS changed version to 2.01.
-VMACSMF updated to protect FILENAME= option not in WPS.
Change 25.123 An undetected DIVIDE BY ZERO in VMXGRMFI occurred in the
VMXGRMFI PGPERBLK=PGPERBLK/BLKSAUIN calculation, but I do not know
Jun 25, 2007 why SAS did not detect and report the error (which is
inside the OUTCODE= of a PROC MEANS inside VMXGSUM). The
division is now protected.
Change 25.122 If BUILDPDB=NO, USERADD didn't function correctly for the
UTILBLDP TMNT, 5, 26J2, or 30 "products".
Jun 25, 2007
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.121 PDB.ASUMUOW dataset is enhanced to keep the response time
VMXGUOW of each of the CICS segments in the Unit of Work.
Jun 22, 2007
Change 25.120 Utility for counting CICS record, bytes, transactions for
UCICSCNT each region and subtype now separates CICS Resource field
Jun 22, 2007 segments from CICS Transaction segments in counts, and
report titles and labels were clarified.
Change 25.119 SMF 119 with (new in z/OS 1.8) IPV6 ICMP segments caused
VMAC119 INVALID DATA error messages due to blanks where &PIB.4.
Jun 20, 2007 should have been for the INFORMAT of several variables
in the TYP11905 dataset (after @OFF11907).
Thanks to Marty Rhodes, Hertz Corporation, USA.
Change 25.118 DEVMODEL='3380K' caused INVALID ARGUMENT error as noted
ASUMCACH in Change 23.073; logic revised to set MODEL=3380 when
Jun 20, 2007 DEVMODEL=:'3380' to circumvent.
Thanks to Tom Heller, Cincom Systems, Inc, USA.
Change 25.117 INVALID ARGUMENT TO FUNCTION INPUT reading SYNCSORT SMF
VMACSYNC records were due to incorrect HEX4 and HEX3 informats
Jun 19, 2007 that should have been HEX8 and HEX6, and (on ASCII only)
SYNSRTOU was input as $CHAR instead of $EBCDIC. The
variables that were wrong were Device Addresses
SIDEVNR and SODEVNR.
Thanks to Patrick Holloman, Zions Management Services Co., USA.
Change 25.116 MXG 25.05 GMTOFF30 was still wrong because Change 25.089
VMAC30 for TYPE30U6 GMTOFF30/INTETIME/INTBTIME was still wrong
VMAC30 in some cases; those variables are now created in the
Jun 19, 2007 _STY30U6 logic based on SMFTIME and the EXECTM; variable
SYNCTIME sometimes exists, and if it does, it is reset
from GMT; otherwise, it is set to INTETIME. With 25.05
TYPE30_V/SMFINTRV has negative EXECTM and ITRVLTM values.
With MXG 25.05,
Thanks to Rudolf Sauer, T-Systems Enterprise Services, GERMANY.
Change 25.115 Incorrect values for memory variables in XMUCDSYS were
VMACXAM the result of my inability to recognize PL/1 source, so
Jun 15, 2007 I overlooked several fields in this Linux under VM data.
Thanks to Robert Obee, IMS Health, USA.
Change 25.114 -The XCOM support is revised to conform to Change 18.338
VMACNDM by defining the MACRO _VTYXCOM for this product. Over
VMACSOLV time, all members will be revised to provide this option,
VMACXCOM but I tend to get motivated only when someone asks.
Jun 14, 2007 -Jun 27: SOLV enhanced to define _VTYSOLV, _VTYSOL1 macros
Jun 27, 2007 -Jun 27: NDM now defines _VNDMxx macro for all datasets.
Thanks to Trevor Ede, EDS, New Zealand.
Change 25.113 The HSM support is enhanced to create an "HSM COMPLEX"
ASUMHSM variable, HSMPLEX, for the HSM Summarization logic to
Jun 14, 2007 support sites with multiple DFHSM-managed storage
environment. HSMPLEX is blank by default, but the new
MACRO _ESUHSM has a commented exmaple on how you might
create values in HSMPLEX for your DFHSM data.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.112 The CA IDMS Performance Monitor support is enhanced with
IHDRIDMS the insertion of an INCLUDE for IHDRIDMS member after the
VMACIDMS IDMS header variables have been input. New &MACIDMSH
VMXGINIT macro variable is defined so either the IHDRIDMS member
Jun 14, 2007 or it can be used to access the header variables.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.111 A misplaced end comment after PUT 'DEBUG TWO' statement
VMAC80A after Change 25.024 caused variable TYPSTRNG to be wrong.
Jun 13, 2007 TYPSTRNG is an MXG-created variable that identifies which
RACFTYPE subtypes were found for this RACF event.
Thanks to John Hammonds, Texas Comptroller of Public Accounts, USA.
Change 25.110 -When there are more than some number of disks, NMON will
VMACNMON create additional objects DISKBUSY1/DISKREADn etc; they
Jun 12, 2007 are now supported.
-Inconsistent sort order BY statement were revised.
-JFSFILE name was increased in size to $128 to prevent
false duplicates
Change 25.109 z/OS 1.8 changed the meaning of UIC values in SMF71Uxx
VMAC71 variables to now represent the time for one steal cycle
Jun 14, 2007 through the whole storage area, with a range of values
from 0 to 65535 (18 hours). As before, low UIC implies
higher storage contention. The new UIC metrics for
Current UIC are calculated every second, while Min and
Max are the lowest/highest UIC during the last walk thru
the storage area. IBM has kept the old form of UIC
(values 0-2054) in SMF71LIC/HIC/ACA, MXG variables
HIUICMN/MX/AV, but this change now stores the new
SMF71Uxx values in the three old UIC MXG variables
HIUICMN/HIUICMX/HIUICAV variables, as their value has no
meaning with z/OS 1.8.
See Change 26.069, which corrected HIUICMN and HIUICMX.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.108 Unused Change.
====== Changes thru 25.107 were in MXG 25.05 dated Jun 7, 2007=========
Change 25.107 Support for CA Brightstor Tape Encryption user SMF record
EXBTENCR creates two new datasets:
EXBTEN32 DDDDDD MXG MXG
IMACBTE DATASET DATASET DATASET REC
TYPEBTE SUFFIX NAME LABEL St
TYPSBTE BTENCR BTENCRYP BTENCR: BRIGHTSTOR TAPE ENCRYPTION all
VMACBTE BTEN32 BETNCR32 BTEN32: BRIGHTSTOR SUBTYPE 32
VMXGINIT but this change was not included in MXG 25.05; 25.06+ is
Jun 7, 2007 needed for these data. See also Change 25.143.
Jun 14, 2007
Thanks to Ray Dunn, CIGNA, USA.
Change 25.106 MXG 25.04 only. Zero obs in TMSTMS due to a debug test
TYPETMS5 IF DSN='DB2SPEC.DBBKUP.ONSITE.CSTDB21R.CSTTSP10' THEN
Jun 5, 2007 statement that should have been deleted.
Thanks to Jan Bigalke, AGIS Allianz Dresdner Infosys, GERMANY.
Change 25.105 -Variable PARTNCPU contains the number of CP Engines, but
VMAC7072 the "in what" is different in different MXG datasets:
VMXG70PR In ASUMCEC and ASUMCELP the label now reads:
Jun 5, 2007 PARTNCPU='NUMBER OF*CP ENGINES*IN CEC'
in TYPE70PR, ASUM70PR, and ASUM70LP, the label now reads:
PARTNCPU='NUMBER OF*CP ENGINES*IN PARTITION'
For example, you could see PDB.ASUMCEC with
NRPRCS=5 NRPHYCPS=4 NRICFCPU=2 PARTNCPU=2
and PARTNCPU is thus the correct number of CP engines for
any "CPU Busy" calculations.
-Variable MXGCIN was not always set correctly for 'ICF's;
fortunately, there was no impact on other variables.
-If you should accidentally/incorrectly run ASUM70PR with
incorrect CECINTRV=QTRHOUR reading DURATM=30 Minute data,
then, as should be expected, the ASUMCEC output dataset
is invalid, and had many PCTCPU's much greater than 100%.
Change 25.104 Full support for NMON, Nigel's Monitor for AIX/unix. All
EXNMONAA OBJECTs are now supported; an NMONxxxx dataset is created
EXNMONCD from each OBJECT that has multiple instances per interval
EXNMONDS (e.g. NMONDISK has an observation for each DISKNAME), and
EXNMONIN
EXNMONIO NMONINTV dataset has all metrics from all OBJECTs that
EXNMONJF have only one instance per interval.
EXNMONNT
EXNMONFS These datasets are now created from NMON records:
EXNMONTO DDDDDD MXG MXG
EXNMONUA DATASET DATASET DATASET
EXNMONVG SUFFIX NAME LABEL Instance
EXNMONWL
IMACNMON NMONAA NMONAAA NIGELS MONITOR AAA CONFIG none
VMACNMON NMONCD NMONCPUD NMON CPU DETAIL CPUNR
VMXGINIT NMONDS NMONDISK NMON DISK DISKNAME
Jun 5, 2007 NMONIN NMONINTV NIGELS MONITOR INTERVAL none
NMONIO NMONIOAD NMON IOADAPTER IOADAPTR
NMONJF NMONJFSF NMON JFSFILE JFSFIL
NMONNT NMONNETW NMON NETWORK NETNAME
NMONFS NMONNFS NMON NFS CLIENT AND SERVER NFSTYPE
NMONTO NMONTOP NMON TOP PROCESS PID
NMONUA NMONUARG NMON UARG PROCESS PID PPID
NMONVG NMONVG NMON VOLUME GROUP VOLGROUP
NMONWL NMONWLM NMON WLM WLMCLASS
This table maps the objects to each MXG dataset:
DDDDDD MXG MXG The OBJECTs that create
DATASET DATASET DATASET are listed.
SUFFIX NAME LABEL
NMONAA NMONAAA NIGELS MONITOR AAA CONFIGURATION
OBJECTS: AAA
NMONCD NMONCPUD NMON CPU DETAIL
OBJECTS: CPUnn
NMONDS NMONDISK NMON DISK
OBJECTS: DISKBUSY DISKREAD DISKWRITE
OBJECTS: DISKXFER DISKBSIZE
NMONIO NMONIOAD NMON IOADAPTER
OBJECTS: IOADAPT
NMONJF NMONJFSF NMON JFSFILE
OBJECTS: JFSFILE JFSINODE
NMONNT NMONNETW NMON NETWORK
OBJECTS: NET NETPACKET NETERROR
NMONFS NMONNFSS NMON NFS CLIENT AND SERVER
OBJECTS: NFSCLIV2 NFSCLIV3
OBJECTS: NFSSVRV2 NFSSVRV3
NMONTO NMONTOP NMON TOP PROCESS
OBJECTS: TOP
NMONUA NMONUARG NMON UARG PROCESS
OBJECTS: UARG
NMONVG NMONVG NMON VOLUME GROUP
OBJECTS: VGBUSY VGREAD VGWRITE
OBJECTS: VGXFER VGSIZE
NMONWL NMONWLM NMON WLM
OBJECTS: WLMCPU WLMBIO WLMMEM
NMONIN NMONINTV NIGELS MONITOR INTERVAL
OBJECTS: CPU_ALL
VARS: PCPUUSER PCPUSYS PCPUWAIT
VARS: PCPUIDLE PCPUBUSY NRCPUS
OBJECTS: MEM
VARS: REALFREE VIRTFREE REMBFREE
VARS: VIMBFREE REMBTOTL VIMBTOTL
OBJECTS: MEMNEW
VARS: MNPROCPC MNFSCAPC MNSYSTPC
VARS: MNFREEPC MNPINNPC MNUSERPC
OBJECTS: MEMUSE
VARS: MUNUMPPC MUMINPPC MUMAXPPC
VARS: MUMINFPC MUMAXFPC
OBJECTS: PAGE
VARS: PGFAULTS PGIN PGOUT PGSIN
VARS: PGSOUT RECLAIMS SCANS CYCLES
OBJECTS: PAGING
VARS: PGMBFREE
OBJECTS: LARGEPAGE
VARS: FREEPAGE USEDPAGE PAGES
VARS: HIGHPAGE SIZEMB
OBJECTS: PROC
VARS: RUNNABLE SWAPIN PSWITCH
VARS: READ WRITE FORK EXEC SEM MSG
VARS: SYSCALL
OBJECTS: PROCAIO
VARS: AIOPROCS AIORUNNG AIOCPU
OBJECTS: FILE
VARS: IGET NAMEI DIRBLK READCH
VARS: WRITECH
VARS: TTYRAWCH TTYCANCH TTYOUTCH
OBJECTS: LPAR
VARS: PHYSICPU VIRTCPUS LOGLCPUS
VARS: POOLCPUS ENTITLED WEIGHT
VARS: POOLIDLE USEDALL USEDPOOL
VARS: SHARECPU
The JFSFILE and JFSINODE objects have errors in one file
out of many; after many intervals, the number of data
fields in those object records is smaller than the number
of file names in the "dictionary" record. Logic in MXG
detects and reports these bad records on the log, and
deletes the defective records. If a fix from Nigel is
forthcoming, this note will be updated.
Thanks to Steve Olmstead, Northwestern Mutual Trust, USA.
Thanks to Henry Steinhauer, Northwestern Mutual Trust, USA.
Change 25.103 Support for IBM OMEGAMON TRF ITRF V550 and V560.
EXITRMST -Many new variables added to datasets ITRFMSG & ITRFMSGO.
IMACITRF -Variables LOCLTIME and PSTNR added to all ITRF datasets.
VMACITRF -New ITRFMSGT dataset is created from subtype 12 with the
VMXGINIT text of the DFS554A message.
Jun 4, 2007 -There is a known error now fixed in APAR CCnnnnn; a few
'10'x records (39 out of 10000) are misaligned, causing
very high CPU time (1E13) and missing value in LOCLTIME.
Use PROC MEANS N MIN MAX SUM DATA=ITRFMSG; to examine
the maximum value of ACCPU and SRBTIME and LOCLTIME to
see if it has any missing values.
Thanks to Guenter Rucks, FinanzIT GmbH, GERMANY.
Thanks to John Maher, IBM Tivoli, USA.
Thanks to Bert Winberg, IBM Nordic Processor, DENMARK.
Change 25.102 The erase of the old month directory syntax was wrong;
VMXGALOC statement %let killmo="&basedir.w%trim(&killmnth)\*.*";
Jun 2, 2007 is now %let killmo="&basedir.m%trim(&killmnth)\*.*";
Thanks to Patrick Holloman, Zions Management Service Company, USA.
Change 25.101 MXG 25.04 only. Back in Change 25.085, I added options
MEMLEAVE=25M NOSORTBLKMODE in CONFIGV9 because they did
CONFIGV9 correct an error, but those values were suggested for the
Jun 1, 2007 diagnostics; this change restores SORTBLOCKMODE because
it is used by DFSORT for significant improvement in sort
performance, and it is the SAS default, so it no longer
set in MXG's CONFIGV9.
MEMLEAVE protects a virtual storage area used only by SAS
(especially needed when SAS calls an external product,
like a host sort program), but MEMLEAVE is taken from the
REGION size of the JOB; if you had an old job with the
prior-recommended-by-MXG of REGION=64M, with MEMLEAVE=25M
you only had 39M for the MXG job. Additionally, the SAS
recommended value is 10% of the REGION size, and almost
all of MXG will execute in a REGION=100M, changing the
value to MEMLEAVE=10M is more correct.
But what about REGION=0M, didn't that solve the need to
periodically increase any static REGION=nnnM values in
your JCL? Yes, it did, prior to the new Threaded Kernel
Memory architecture in SAS V9, which operates independent
of the prior "SAS Proper" WM Memory architecture, but the
existence of two independent memory managers in one ASID
has uncovered memory exposures if and only if REGION=0M
is specified. While a future version of SAS may resolve,
the safest recommendation now is to set REGION=100M on
your job card, with this revised CONFIGV9 member in use.
(MXG also sets NOTHREADS because there are exposures to
the use of THREADS on z/OS at this time that need to be
understood, so I leave it to you to decide to THREADS,
but even with NOTHREADS, the REGION=0M exposure exists,
because SAS V9 itself is threaded.)
Thanks to Jim Hayes, Huntington, USA.
Change 25.100 Documentation. References to JCLINSTL were changed to
INSTALL JCLINST9 for SAS V9.1.3 or JCLINST8 for SAS V8.2; the
JCLINSTx JCLINSTL member no longer exists because it didn't work
Jun 1, 2007 for both SAS versions, but I failed to update the doc.
Thanks to Allan Hardman, Co-Operative Bank, ENGLAND.
Change 25.099 Sub-subtype '4000'x (DLI) caused INPUT STATEMENT EXCEEDED
VMAC112 ERROR and/or incorrect values in T112DLI and T112DLIT
VMACOMCI datasets; an 8-byte field was overlooked.
May 31, 2007 -Jun 28: Detection of unknown TTYPE added for safety.
Jun 28, 2007 -The SMF 112 record replaced the OMEGAMON for CICS user
Jun 30, 2007 SMF record, but only the SUBTYPE=203 "ONDV" record is
processed by TYPE112, because that is the useful data,
because only the subtype 203 can be compressed, and
because the existing TYPEOMCI/TYPSOMCI code will read the
other two subtypes:
200 - SYST
201 - INTR
in a standalone job from SMF with this example
// EXEC MXGSASV9
//SMF
//PDB
//SYSIN DD *
%LET MACKEEP= MACRO _IDOMCI 112 %
%INCLUDE SOURCLIB(TYPSOMCI);
so you can investigate if the other two subtypes contain
data of interest. You could easily add processing of the
SMF 112 and OMCI records to your BUILDPDB, using:
%LET MACFILE=
%QUOTE( IF ID=112 THEN DO;
INPUT @OFFSMF+19 SUBTYPE &PIB.2. @;
IF SUBTYPE IN (200,201) THEN ID=299;
END;
);
%LET MACKEEP= MACRO _IDOMCI 299 % ;
%UTILBLDP(BUILDPDB=YES,USERADD=112 OMCI);
%INCLUDE INSTREAM;
Because the TYPE112 code now processes the subtype 203,
VMACOMCI now only reads subtype 200 and 201 records, it
was updated to accept V560 version, and the four bytes
inserted for compression statistics are skipped.
But see Change 26.257, which revised OMCI and 112 code.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Thanks to Ray Dunn, CIGNA, USA.
Change 25.098 %UTILBLDP is enhanced with new option BUILDPDB=JES3 to
UTILBLDP generate an %INCLUDE for BUILDPD3 instead of BUILDPDB to
May 31, 2007 create a PDB library with JES3 instead of JES2 records.
Thanks to Julian Smailes, Experian, ENGLAND.
Change 25.097 MXG-created DB2-variable THREADTY was blank if there was
VMACDB2 no QLAC segment (i.e., non-DDF), because the MXG code to
May 28, 2007 create THREADTY was located inside the QLAC processing,
Jun 6, 2007 because the logic needs to test QLACLOCN. The code block
was relocated to after the QLAC processing, and THREADTY
should, now, always be populated.
-THREADTY added to DB2ACCTP dataset default KEEP list.
Thanks to Eileen F. Van Etten, Bank of America, USA.
Change 25.096 Using an IMAC7072 tailoring that had an old _STY70 caused
IMAC7072 ERROR: VARIABLE LPARNAME NOT FOUND. from within a VMXGSUM
May 28, 2007 that was "INVOKED BY VMXGRMFI TYPE70 - R70HOUR", although
the real error was back when PDB.TYPE70 was created, as
it had zero observations because the new "SPLIT70" _STY70
must be executed, now, to create observations in TYPE70.
Removing the IMAC7072 corrected the error; it has been
the MXG recommendation to remove all of the old IMACnnnn
"product tailoring" members, and use only IMACKEEP to
redefine macros you know you want to change.
Long ago, the IMACxxxx members actually defined the
_L, _K, _S, _B etc macros, but those definitions moved
into the VMACxxxx member precisely because of these
exposures when I have to make an incompatible change
in MXG architecture.
Thanks to Jim Hayes, Huntington, USA.
Change 25.095 Reading VSAM SMF with TYPE42 caused false MXG messages
VMAC42 **ERROR SHORT SMF 42 SUBTYPE 6 ACCESS METHOD SECTION
May 28, 2007 (OFFDSAM=1 confirms it's a false message) and
**ERROR INVALID TYPE42 SUBTYPE 5 RECORD
(COL=229,S42VTVDO=228 confirms false message).
and these records were incorrectly deleted, but only when
the (undumped) VSAM SMF file is read; when the (normal,
dumped) BSAM SMF file is read, there are no errors.
Logic to handle OFFSMF for subtype 5 and OFFDSAM revised.
Thanks to Jim Poletti, Edward Jones, USA.
Change 25.094 Harmless divide by zero when EXCPDASD was zero; the obs
ANALBLSR is now deleted since it can't be a BLSR candidate.
May 28, 2007
Thanks to Rodger Foreman, TransUnion, USA.
Change 25.093 With BUILDPDB=YES,SUPPRESS=DB2, an %INCLUDE for ASUMCICX
UTILBLDP was generated, but the prerequisite %INCLUDE for ASUMUOW
May 22, 2007 was not generated, causing ASUMCICX to fail in a SORT.
Thanks to Robert Sample, Atlanta Journal Constitution, USA.
Change 25.092 Doc only. The example in the comments to run ASUM70PR
ASUM70PR against SMF data was incorrect; the corrected example is:
VMXG70PR %INCLUDE SOURCLIB(TYPS7072,ASUM70PR);
May 21, 2007 Error Dataset PDB.TYPE70PR NOT FOUND resulted if you used
the example in the comments.
Thanks to Art Cuneo, Health Care Services, USA.
Change 25.091 After MXG 25.04 QA completed, but before it was packaged,
TESSOTHR a untested TESSOTHR member was copied into SOURCLIB; the
May 15, 2007 PROC COPY that causes the ERROR in JCLTEST9 is removed.
Thanks to Randy Parker, Trustmark National Bank, USA.
Change 25.090 -Support for PK37354 SMF 100 Subtype 4 in DB2 V1.9, which
EXDB2ST4 will contain the old IFCID=225 (ID=102 Subtype 225) data.
IMACDB2 This makes my head hurt, because I can't safely use the
VMACDB2 old T102S225 dataset name: combining 100 and 102 records
VMAC102 in the same DATA step would cause SAS to fail due to the
VMXGINIT duplicate output dataset names. So the old IFCID=225
May 15, 2007 data will be output in new DB2STAT4 dataset.
-NEW QW0225BB='STORAGE POOL*MANAGER*BLOCKS BELOW*THE LINE'
was also added by this APAR, for both DB2 V1.8 and 1.9,
and it is INPUT and kept in T102S225 and DB2STAT4.
Apr 8, 2008: QW0225BB was only added to T102S225 by this
change. Change 26.057 added it to DB2STAT4.
Change 25.089 GMTOFF30 must be calculated because IBM does not put it
VMAC30 in SMF 30 records; it can only be calculated from the
May 14, 2007 subtype 2 or 3 interval records, which contain interval
May 31, 2007 start on both local and GMT clocks (SMF30IST is local and
Jun 1, 2007 SMF3ISS is GMT), and then GMTOFF30 was used to create the
Jun 18, 2007 local zone INTBTIME & INTETIME interval start/end times.
It was also RETAINed to convert INTETIME in the subtype 6
record, which has no local counterpart, and from which
INTBTIME will be created when TYPE30_6 is deaccumulated.
These problems existed prior to this change:
- Subtype 6 logic caused GMTOFF30 to be zero, causing
INTBTIME/INTETIME in TYPE30_6 to be wrong. Worse,
if the next subtype 2/3 did not have a CPU segment,
(MULTIDD='Y' observations have no CPU segment and
thus SMF30IST is a missing value), that RETAINed zero
GMTOFF30 value was used, causing INTBTIME/INTETIME
in TYPE30_V and PDB.SMFINTRV datasets to be wrong.
- Subtype 2 and 3 records for OMVS tasks do NOT have the
interval start time in SMF30IST (they appear to have
the original substep initiate time, not the current
interval's start time; this undocumented feature
caused very large GMTOFF30 values (like -29 hours).
This change revised the subtype=6 logic so GMTOFF30=0 is
not created, and the OMVS records (SUBSTEP GT 0) are not
used to calculate GMTOFF30; instead, they use the RETAIN
value of GMTOFF30 to recalculate INTBTIME and INTETIME.
There can still be errors in the value of GMTOFF30, or
INTBTIME or INTETIME because of the need to RETAIN the
GMT offset from prior records, but many records do not
have the needed data. These design errors exist in 30s:
- SMF30IST is wrong in OMVS (SUBSTEP GT 0) records.
- SMF30IST is not populated in subtype 6 records.
- SMF30IST is not populated in records with no CPU
segment, notably MULTIDD='Y' records with only EXCPs,
or records with more MULC segments than fit in one
physical SMF 30 record.
The only solution for auditable SMF 30 data is for IBM to
add the GMT Offset value in EVERY type 30 record.
-May 31, 2007: Variable INTRVLTM was missing after May 14
change, only for SUBSTEP GT 0 (USS - OMVS) tasks, because
it wasn't calculated in that revised code block.
-Jun 1, 2007: Variables SMF30IET/INTETIME/SYNCTIME with a
fixed datetime value of '17SEP2042:23:53:47.37' in all
subtype 6 records was found at one site; the hex value of
the field showed it was actually a negative binary value
of -22 (the number of leap seconds of offset!) when it
was INPUT as &IB.8.6 and then divided by 4096, which is
the TODSTAMP algorithm for negative values.
IBM's SMF manual only documents SMF30IST/SMF30IET for the
subtype 2 and 3 records; in subtype 6, SMF30IST is always
missing, but previously SMF30IET was the valid end time.
Now, additional logic detects the duration rather than
datetime in SMF30IET, and sets SMF30IET from SMFTIME in
those cases in TYPE30_6 observations.
-Jun 18, 2007: IF TST30IET GT 0 THEN test was corrected
of IF TST30IET LT -30 THEN because valid TODSTAMP values
have first bit on, which causes TST30IET to be always be
negative, but the -30 test detects the invalid values of
IET that contained leap seconds and not a valid time.
Thanks to Douglas C. Walter, Citicorp, USA.
Thanks to Rudolf Sauer, T-Systems Enterprise Services, GERMANY.
Change 25.088 The &VMXGVERS as the last line should have been %VMXGVERS
VGETDDS
May 10, 2007
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 25.087 BROKEN CONTROL RECORD error caused by DMN=10 RC=2 record
VMACVMXA for MDGPROD=:'5739A03RM0000000' logic, now corrected.
May 10, 2007
Thanks to Tom Draeger, Aurora, USA.
====== Changes thru 25.086 were in MXG 25.04 dated May 7, 2007=========
Change 25.086 New Analysis of CEC-level z/OS Capture Ratio combines PDB
ASUMCAPT ASUMCEC and RMFINTRV datasets, summing workload CPU & TCB
VMXGCAPT time for all Service Classes in all z/OS LPARS in the CEC
May 6, 2007 to create new dataset PDB.ASUMCAPT with total CPUACTTM
from PDB.ASUMCEC and total CPU72TM from PDB.RMFINTRV for
new variable CECAPTRT='CEC*CAPTURE*RATIO' to be created
CECAPTRT=100*CPU72TM/CPUACTTM;
You can simply add %INCLUDE SOURCLIB(ASUMCAPT); after the
your %INCLUDE SOURCLIB(ASUM70PR); in your BUILDPDB job.
The default summarization is by HOUR.
This hour's data shows how 17532 CPU Seconds of CEC Busy
time ends up as only 16389 CPU seconds captured in RMF 72
Service Class records, for a CECAPTRT=93.48 for the CEC:
__________________________________________________________
| ASUMCEC | RMFINTRV | RMFINTRV | RMFINTRV | RMFINTRV |
| CPUACTTM | CPUMVSTM | RMFACTTM | CPUEFFTM | CPU72TM |
| 17532 | 17500 | 17448 | 17389 | 16389 |
| | | | | |
| | | | | __16389__ |
| | | | / |
| | | |__17389__/| |
| | | /| | |
| | |__17448__/ | | |
| | /| | | |
| |__17500__/ | | | UNCAPTURED|
| /| ??Phys?? | PHYSICAL | CPUOVHTM | |
|__17532__/ |__ 32__ | __ 84__ | __ 143__|__ 1143__ |
Of those 16389 CPUTM seconds, only 14086 was CPUTCBTM,
showing why you MUST use total CPUTM and not just TCB.
Change 25.085 Strange V9.1.3 z/OS memory failures in the SAS Internal
CONFIGV9 SORT (no error message on SAS log nor in JOBLOG, even no
May 4, 2007 end of step IEF374I message, but SYSLOG shows the job was
placed in HOLD by JES after a S0F9 ABEND; system couldn't
acquire storage for an SVRB. The error was in _BLDEXCL
of UTILEXCL's sort to create dataset UNIQUE, which must
use internal SAS sort because its BY list is way over the
4092 character limit of host sort packages. By using a
REGION=256M (not REGION=0M, NO LONGER SAS-RECOMMENDED)
and by using these replacement values in CONFIGV9 that
were recommended by SAS Technical Support:
MEMLEAVE=25M
NOSORTBLKMODE
the error was eliminated. So I have added those option
values to the CONFIGV9 member in this change.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Change 25.084 Variable FILSEQ was wrong in TMS.DSNBRECD observations
TYPETMS5 created from the VOL record, for multi-volume, multi-file
VMACTMS5 tapes. FILSEQ does not exist in the VOL record, but MXG
May 4, 2007 creates a pseudo-DSNBRECD obs with the DSNAME in the VOL
May 29, 2007 record; MXG logic did not handle these cases correctly.
VMACTMS5 changed only cosmetic DEBUG statements.
May 29: TYPETMS5 member in MXG 25.04 did NOT contain this
correction; the member copied into MXG 25.04 was not the
tested member that is now updated and redated May 29.
Thanks to Tim Hare, Florida Department of Transportation, USA.
Thanks to Paul Naddeo, FiServ, USA.
Change 25.083 MXG 25.03 only. APAR OA20077 SMF 21 new compressed bytes
VMAC21 SMF21DBR and SMF21DBW were still wrong after two tries.
May 3, 2007 I missed the 4096 multiplier, and I reversed the label
text COMPRESSED/UNCOMPRESSED in all four variables.
Worse, the customer actually had to go to IBM Support,
who quickly and politely diagnosed my coding errors.
These old variables always had correct value:
BYTEREAD='UNCOMPRESSED*CHANNEL*BYTES*READ'
BYTEWRIT='UNCOMPRESSED*CHANNEL*BYTES*WRITTEN'
These new variables were wrong prior to this change:
SMF21DBR='COMPRESSED*DEVICE*BYTES*READ'
SMF21DBW='COMPRESSED*DEVICE*BYTES*WRITTEN'
These two new compression ratio variables are created:
SMF21CRR='READ*COMPRESSION*RATIO'
SMF21CRW='WRITE*COMPRESSION*RATIO'
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Ken C. Jobbitt, IBM Support, USA.
Change 25.082 Support for new XAMAP segments HSTAPP,VSIAPP,VSINAP,
EXXMHAPP VSISFT,VSISYS,VSIUSR and STOSCS creates new VMXHSTAPP,
EXXMHAPP XMVSIAPP,XMVSINAP,XMVSISFT,XMVSISYS,XMVSIUSR, and
EXXMOSCS XMSTOSCS datasets. Variables fron new segments SYTSXP
EXXMVNAP and SYTSXP are added to XAMCPUBY/XAMCPUTO datasets, new
EXXMVSFT variables from old segments SUBSUM,SYTRSG,SYTXSG,MTRMEM,
EXXMVSYS STORSG and SYTCPU are added to XAMSYS dataset, variables
EXXMVUSR from new segments PRCAPC,PRCAPM,SYTSXG,STOSXG are added
IMACXAM to XAMSYS dataset, new vars from IODVSW,USRCON,USRACT
VMACXAM will be decoded.
VMXGINIT
May 1, 2007
Thanks to Robert Obee, IMS Health, USA.
Change 25.081 NDM 'NM' records are now decoded, and output in NDMNM
VMACNDM dataset (previously output, but with only the header
May 1, 2007 variables). Variable NDMTIME is kept but it is not
populated in the sample SMF record.
Thanks to Trevor Ede, EDS New Zealand, NEW ZEALAND.
Change 25.080 Cosmetic protection for a user syntax error if the user
VMXGDUR failed to specify a DATETIME= variable that cause strange
VMXGSUM syntax errors. Now, MXG issues USER ABEND 1916 when that
May 1, 2007 required operand is missing.
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.079 MXG RMF III code only output the first LPAR's data in the
VMACRMFV ZRBLCP dataset, which now has one observation for each
May 1, 2007 LCPUADDR for each LPARNAME that has engines assigned.
Thanks to Jerry Urbaniak, Acxiom, USA.
Thanks to Sam Knutson, Geico, USA.
Change 25.078 Documentation. These MXG members issue USER ABENDs with
INSTALL an ABORT ABEND nnnn; statement, so these programs could
May 1, 2007 ABEND with the listed User Abend Code:
Feb 1, 2015
USER Member USER Member
ABEND ABEND
1 VMACTMV2 1234 VMACTMS5
69 VMACSMF 1911 VMXGRMFI
69 VMACTMV2 1912 VMXGRMFI
69 VMACTMVS 1913 VMXGRMFI
99 VMACCADM 1914 VMACSET
99 VMXGVTOC 1914 VMXGSET
99 VMXGVTOF 1915 VMACSET
111 VMACTNG 1916 VMMXGDUR
666 UTILDUMP 1917 UTILBLDP
666 UTILDUMP 1918 UTILBLDP
666 VGETALOC 1919 UTILBLDP
666 VMACMVCI 1954 BLDSMPDB
666 VMACXAM 2098 VMACTMVT
666 VMXGALOC 2099 VMACTMD8
666 VMXGSUM 2099 VMACTMDB
666 VMXGSUME 2099 VMACTMDC
990 VMACRMFI 2099 VMACTMDQ
991 IHDRTMS5 2099 VMACTMTC
992 IHDRTMS5 8888 VGETOBS
0001 VMACTMV2 8888 VGETOBS
0010 VMACPKSZ MXGABND VMAC110
0069 VMACTMV2 MXGABND VMACSMF
0666 IMACNORM MXGABND VMACSMF
1099 TYPEMOND MXGABND VMACTMS5
1099 TYPETMON MXGABND VMXGRMFI
1099 VMACMON8
1099 VMACTIMS
1099 VMACTMO2
1111 MONTHASC
1111 MONTHBL3
1111 MONTHBLD
1111 MONTHBLS
1111 MONTHDSK
See text of Changes 23.184, 29.290, 29.304, 33.020 36.136
for syntax/usage of &MXGABND USER ABEND macro variable.
Change 25.075 DB2 V8.1 incompatibly changed the QBGL Group Buffer Stats
VMACDB2 segment, making these nine fields now reserved:
Apr 30, 2007 QBGLAD QBGLAN QBGLAR QBGLAZ QBGLMN QBGLRB QBGLRF
QBGLSU QBGLXN
and adding five new variables to PDB.DB2GBPST dataset:
QBGLCM QBGLCR QBGLMW QBGLWP QBGLWS
Thanks to Martin Packer, IBM, WORLDWIDE.
Change 25.074 Extraneous DATA; SET; BY ...; statements, left over from
VMAC7072 debugging the SPLIT70 logic, is removed.
Apr 30, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.073 Enhancement to "Nigel's Monitor for AIX and Linux' adds
EXNMONAA variables HOST and INTERVAL to NMONINTV dataset, decodes
IMACNMON the IOADAPTR and LPAR data types, and creates new NMONAAA
VMACNMON dataset with the "AAA" configuration records information.
VMXGINIT
Apr 29, 2007
Thanks to Massimo Pugliese, ELSAG Spa, ITALY.
Change 25.072 Sample tape statistics reports using STC VTS SMF records
DALYTAPE and the MXGTMNT tape mount and allocation records. Can
Apr 26, 2007 be used after a modified BUILDPDB, or with the %UTILBLDP
example in the comments, the reports can be created from
an SMF data file.
Change 25.071 MXG 25.03 only UTILBLDP: did not generate the _Sxxxx sort
UTILBLDP macros when BUILDPDB=NO was specified due to a typo; the
Apr 26, 2007 USERADD= datasets were not sorted into the PDB library.
May 7, 2007 Additionally, these products that need deaccumulation and
require their _Sxxxx product sort macros to be invoked:
7072 DB2 HSM NTCP ROSC TMDB TPX 103 28
will now have those macros invoked whenever USERADD= is
invoked for them.
-May 7: Support for SMF ID=102 record, which requires the
_HDR102, _END102 macros. With over 300 IFCID/subtypes,
you can select which T102Snnn datasets are created using
USERADD=102.63 102.106 102.141 102.142 syntax. The 102
tokens must be contiguous in your USERADD= parameter, but
do not need to be continuously numbered, nor do they need
to be in numeric order in your USERADD= in you %UTILBLDP.
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.070 -MXG's SYSLOG-reading program failed, INVALID ARGUMENT TO
SYSLOG FUNCTION INPUT, because the final tested changed member
Apr 25, 2007 was still in my "USERID.SOURCLIB" from Nov, 2005, when it
Apr 28, 2007 should have been moved into the MXG source library. The
Apr 29, 2007 output dataset TYPETMSG contains an observation for each
SYSLOG event (but not for each physical record in SYSLOG:
records starting with "S" are continuation records, and
their text is appended in the variable TMTGMTXT so that
only one output observation is created for these events.
-Variable TMTGMTXT was increased to $120 from $80, which
caused text for "S" records to be truncated.
-In addition to using thid code to read SYSLOG messages,
you can also write any SYSLOG message to SMF, using the
MXGTMNT Tape Mount Monitor program (in ASMTAPEE), which
with then be output in BUILDPDB's TYPESYSL dataset.
Thanks to MP Welch, SPRINT, USA.
Thanks to Stephen Van Scyoc, SPRINT, USA.
Change 25.069 Service Class names can be "wild-carded" using the colon
UTILRMFI symbol, if you have similarly named Service or Reporting
VMXGRMFI Class names to map to workloads in your WORKnn= argument.
Apr 24, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.068 The SQL text from QW0141TX was not printed if the length
ANALDB2R of text was less that 60 bytes, due to a typo; the line
Apr 23, 2007 ELSE TEXT=QW0141TX; is corrected to ELSE TEXT1=QW0141TX;
Thanks to Michael Gebbia, Eddie Bauer, USA.
Change 25.067 The VMXGUSE macro is updated to add the _STY70 macro if
VMXGUSE processing of the SMF 70 records was requested; VMXGUSE
UTILBLDP is still supported, but the newer UTILBLDP is recommended
Apr 20, 2007 as the better tool, as it offers many more options; it
was also updated to ensure _STY70 is invoked when needed.
-MXG25.03 also had double percent instead of %VMXGVERS.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.066 DB2 SMF 102 IFCID=225 record with invalid header offset
VMACDB2H of '0CB5'x, 3253 decimal, for QWHCEUID_Off, but with its
Apr 20, 2007 LRECL of only 486 bytes, caused INPUT STATEMENT EXCEEDED.
The input now validates that the offset is LE LENGTH.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 25.065 Enhancement to UTILBLDP to select the ASUMxxxx members to
UTILBLDP be executed when BUILDPDB=YES is specified. The default
Apr 18, 2007 list of members %INCLUDEd after BUILDPDB is not changed,
but they are now set in the new MXGINCL= argument:
MXGINCL=
ASUMUOW ASUMCICX ASUM70PR ASUMCACH ASUMTAPE
ASUMTMNT ASUMTALO ASUMDB2A ASUMDB2B,
so you can now remove any unwanted ASUMs.
Thanks to Tom Kelman, Commerce Bank of Kansas, USA.
Change 25.064 Several QISE variables should have been DIF()'ed as they
VMACDB2 contained accumulated values; now all QISE variables are
Apr 17, 2007 DIF()'d except for those that contain counts of pages or
statements, in creating the PDB.DB2STATS dataset from the
SMF 100 Subtype 1 DB2 Statistics records. Also, QISExxxx
labels with "Dataspace" were corrected to "DBD POOLS".
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 25.063 Additional SWAP resaons codes were added to $MGO79SR
ADOC71 format and in the ADOC71 member documentation.
FORMATS VALUE $MG079SR
Apr 17, 2007 '00'X='00X:UNKNOWN'
'AS ='AS:AUXSTOR SHORTAGE (VERY UNLIKELY)'
'AW'='AW:APPC WAIT'
'DW'='DW:DETECTED WAIT'
'EX'='EX:CAP EXCHANGE'
'IC'='IC:IMPROVE CSTORE'
'IP'='IP:IMPROVE PAGING'
'IW'='IW:OMVS INPUT'
'LW'='LW:LONG WAIT'
'MR'='MR:MAKE ROOM'
'NQ'='NQ:CAP ENQUEUE'
'NS'='NS:TRANSITION TO NON-SWAPPABLE'
'OW'='OW:OMVS OUTPUT'
'RQ'='RQ:REQUEST SWAP'
'RS'='RS:REAL STORAGE SHORTAGE'
'SR'='SR:IN-REAL'
'TI'='TI:TERMINAL INPUT'
'TO'='TO:TERMINAL OUTPUT'
'TS'='TS:TRANSITION'
'US'='US:CAP UNILATERAL'
'VR'='VR:VIRTUAL REAL REQUEST'
'WT'='LW:LONG WAIT'
'XS'='XS:AUX STORAGE SHORTAGE'
;
Thanks to Warren Hayward, TJX, USA.
Change 25.062 Protection for truncates RMF ID=72 SUBTYPE=7 LENGTH=78.
VMAC7072 while the site examines logs for x37 ABENDS and/or opens
Apr 16, 2007 a problem report with IBM.
Thanks to Ravi Kumar, CSC, USA.
Change 25.061 Variable SMF12WIC is padded with '00'x instead of blanks;
VMAC120 those '00'x are now translated to blanks.
Apr 15, 2007
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA
Change 25.060 Using TYPSTPF invoked very old PROC SORTs that still had
VMXGTPFI invocations of %VMXGFOR, long ago archaic and no longer
VMXGFOR needed, but they caused a 180 Syntax error for "FORCE".
Apr 12, 2007 The %VMXGFOR calls were removed from VMXGTPFI, and that
member was revised to "FORCE" is only created for SAS
V5 and V6 where it was originally required.
Change 20.327 in 2003 documented the removal of FORCE.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.059 All %VMXGVERS(25.03,MEMBER) invocations were typo'ed as
DOC %VMXGVERS(25.03MEMBER);. Wrong syntax, but, fortunately
Apr 12, 2007 there was no error; the old macros would still be noted
in the messages to the log, which still had the right
information, albeit slightly different than expected.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
====== Changes thru 25.058 were in MXG 25.03 dated Apr 12, 2007=========
Change 25.058 Variable NDMSNODE appeared twice in the _BNDMCT by list.
VMACNDM
Apr 12, 2007
Thanks to Trevor Ede, EDS New Zealand, NEW ZEALAND.
====== Changes thru 25.057 were in MXG 25.03 dated Apr 10, 2007=========
Change 25.057 The 9672x CPUTYPE without APAR OW37565 does not populate
VMAC7072 SMF70CIN, causing PARTNCPU to be zero. Now, MXG forces
Apr 10, 2007 SMF70CIN='CP' when CPUTYPE='9672'X and NRCIXGTO=0.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Change 25.056 DB2STATS SMF 100 Subtype 1 Language Environment QLExxxxx
VMACDB2 LE variables have always been wrong, partially due to MXG
Apr 10, 2007 code errors (I assumed the 8-byte fields contained both a
duration and a count, and deaccumulated some fields that
were not accumulated), and partially because IBM's record
is incorrectly written and does not agree with the DSECT.
The 8-byte header (normally has the 'QLES' eye catcher)
doesn't exist, but LENQLES=168, and visual examination of
hex dumps showed the extra 8 bytes are inserted between
QLELOWIM and QLESTG1M fields. DB2 Versions 1.6 thru 1.8
SMF records all have LENQLES=168 and the inserted field.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.055 Support for SAMS objects 2151,2226,2229 and 2231 has been
EXSAM151 validated and new datasets created.
EXSAM226 -Many variables in many of the existing SAMSnnnn datasets
EXSAM229 were renamed to avoid conflict with same-named variables
EXSAM231 created from other SMF records.
IMACSAMS
VMACSAMS
VMXGINIT
Apr 8, 2007
Change 25.054 DB2TCBTM in DB2ACCT/ASUMUOW includes QWACSPCP,QWACTRET
VMXGUOW CPU times, but with OTE, the DB2TCBTM includes some of
Apr 6, 2007 the CPU time already recorded in the CICSTRAN's TASCPUTM;
using PDB.ASUMUOW, the correct CPU metric would be the
sum of TASCPUTM from CICSTRAN and QWACSPCP and QWACTRET
from DB2ACCT. This change SUMs QWACSPCP and QWACTRET
into PDB.ASUMUOW so that you can add those DB2 CPU times
to the CICS CPU times with no overlap.
Change 25.053 Variable PCTCPUBY greater than 100% in PDB.ASUMCEC, but
VMXG70PR only in hour intervals when LPARs were started/stopped,
Apr 5, 2007 and only if the DURATM of the last LPAR (alphabetically)
was less than the full hour. DURATM was intended to be
set to CECINTRV, but MXG set it only for FIRST.SMF70GIE;
it was then being output from the DURATM of that last
LPARNAME. DURATM=CECINTRV is now set unconditionally.
Thanks to David Bixler, FISERV, USA.
Thanks to Randy Shumate, Lexus-Nexus, USA.
Change 25.052 Support for TDSLink Version 630 adds new ZCOST datasets
EXTDS16 from subtypes 16x, 17x, 18x and 19x:
EXTDS17 dddddd dataset description
EXTDS18 TDS16 TDSL16 ZCOST CPC
EXTDS19 TDS17 TDSL17 ZCOST LPAR
IMACTDSL TDS18 TDSL18 ZCOST SYSPLEX
VMACTDSL TDS19 TDSL19 ZCOST SYSPLEX/CPC
VMXGINIT
Apr 5, 2007
Change 25.051 Change 24.116 reported NRIFACPU for z990/2084 CPUTYPE was
VMAC7072 not countable - SMF70CIN='ICF' in LPARNAME='PHYSICAL' in
Apr 6, 2007 RMF 70 records instead of 'IFA' - and created the macro
variable CECIFANR so you could set NRIFACPU if needed.
Now, Al has found a way using the non-PHYSICAL-LPARNAME
segments (that do have SMF70CIN='IFA' for IFAs!) to count
and populate variable NRIFACPU for z990s with IFAs.
-New field SMF70CTN, the total count of engines of that
SMF70CIN type (CP,IFL,etc), in the CEC was incorrectly
INPUT, but it was not kept nor used. It still is not used
for NRxxxCPU in ASUM70PR, but now it is input correctly
and kept in PDB.TYPE70PR dataset. It will have the same
value in all obs of that engine type, so a 27-engine CEC
will have SMF70CTN=27 in all obs with SMF70CIN='CP', both
in both the LPARNAME='PHYSICAL' and LPARNAME='real' obs.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.050 Support for CrossSysplexManager user SMF record (Skill
EXCSMDDN Software) creates two new datasets:
EXCSMJOB CSMDDN CSMDDN CROSS SYSPLEX DDNAME
IMACCSM CSMJOB CSMJOB CROSS SYSPLEX JOB
TYPECSM
TYPSCSM
VMACCSM
VMXGINIT
Apr 4, 2007
Thanks to ???, ???, Italy.
Change 25.049 Format $MGSASPR, which maps SAS Procedure Name in the SAS
FORMATS "USER" SMF record, has new QUANTREG and ROBUSTRE values
Apr 2, 2007 added for SAS STAT product.
Thanks to Len Rugen, University of Missouri, USA.
Change 25.048 Corrections to MXG 25.02 included correction for the
BLDSMPDB libname=PDB operand, the CALL SYMPUT('SRTDSN',SORTDBY)
DOC spelling, and logic related to VGETSORT invocation.
Apr 1, 2007 References to WEEK1 were replaced with WEEK.
Apr 17, 2007 New SORTEDBY= option can be set to sortedby=no to bypass
the requirement for input weekly/daily datsets to be
sorted. 17Apr07: Null input library protected with msg.
Thanks to Loren Mitchell, Los Angeles Couty Office of Education,USA.
Change 25.047 -Support for APAR OA19502, adds SMF14KET, the Key Exchange
FORMATS Time (Encryption Overhead). This time is only recorded
VMAC1415 in SMF 15 output records and only for a CLOSE processing
Apr 1, 2007 after a non-parallel OPEN writing file sequence one from
the loadpoint. Otherwise, SMF14KET is zero. This is the
elapsed "wall clock" duration, and is NOT a CPU time
metric. A "non-parallel OPEN" is when the parameter list
passed to OPEN includes only 1 DCB or ACB.
-New $MG014CD format decodes the SMF14CD1 and SMF14CD2
Encoding Mechanisms:
L:LABEL - the key label itself is to be stored as part
of the EEDK structure on the tape cartridge.
H:HASH - "Public Key HASH" - a hash of the public key
referenced by the key label is to be stored
on the cartridge rather than the key label
itself. Storing the hash value rather than the
key label itself allows for greater flexibility
when tapes are exported to another location,
especially if that location may be using a
different key label (than the originating site)
to refer to the same key.
Thanks to Jack Muehl, CitiGroup, USA.
Change 25.046 Cosmetic. INVALID DATA FOR MDY message and hex dumps of
VMACSTC the first two instances are printed when the LSBTIME date
Mar 31, 2007 field contains zeros. Now, LSBTIME is only created when
the data exists. These records with no date also have
zeros in all other fields, and so the defective records
were not output into the STCLMU dataset, either before or
after this change.
Thanks to David Kaplan, Depository Trust, USA.
Change 25.045 Variable TTTOD was not kept in TPFDH, TPFKC, or TPFSB
VMACTPF datasets, but were referenced in BY statement in _STPFKC.
Mar 30, 2007 Now, that retained variable is kept in those datasets.
Thanks to Chris Weston, SAS Institute, USA.
Change 25.044 New intervals (obviously for TRENDing, and not tactical!)
VMXGDUR of QUARTER, SEMIANN, and ANNUAL will create summary data
VMXGSUM when those arguments are used. The code change was in
Mar 28, 2007 VMXGDUR; only comments were changed in VMXGSUM.
Thanks to Nalini Elkins, Inside Products, USA.
Change 25.043 Support for z/VM 5.3.
EXIODHPC (Apr 12 changes were moved Apr 17, were not in 25.03.)
EXIODHPP
EXIODLPT
EXMTRHPP
EXPRCAPC
EXPRCAPM
EXPRCDIA
EXPRCINS
EXSAMSDT
EXSCLSCA
EXSTOSCS
EXSTOSXG
EXSTOSXP
EXSYTLCK
EXSYTSPT
EXSYTSXG
EXSYTSXP
EXVNDLSD
EXVNDLSU
EXVNDSES
IMACVMXA
VMACVMXA
VMXGINIT
Mar 28, 2007
Apr 12, 2007
Change 25.042 Enhancement to support HSM records with different SMF IDs
VMACHSM perhaps from different systems. HSM writes 2 SMF records
Mar 28, 2007 with and ID and ID+1 architecture, and MXG defined two ID
macros that you tailored with your SMF TYPE numbers:
MACRO _IDHSMDS 224 %
MACRO _IDHSMDS1 225 %
But I have redefined the second ID macro to now be
MACRO _IDSHMDS1 _IDHSMDS+1 %
which has no impact on your existing IMACKEEP tailoring,
but now, you could use this logic to redefine them:
MACRO _IDHSMDS 512 OR (ID=224 AND SYSTEM='SYS1')
OR (ID=229 AND SYSTEM='SYS2') %
MACRO _IDHSMDS1 512 OR (ID=225 AND SYSTEM='SYS1')
OR (ID=230 AND SYSTEM='SYS2') %
and MXG will process both pairs of HSM records.
This works because the reference syntax in VMACHSM is
IF _IDHSMDS THEN DO; IF _IDHSMDS1 THEN DO;
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.041 Support for CICS/TS 3.2 (INCOMPATIBLE).
EXCICDHD -Major Change: All CICS CPU times are expanded to 8 bytes
EXCICISR with significant increase in captured TASCPUTM possible.
EXCICLDB -CICS Transaction Segments in SMF 110 subtype 1 can be
EXITCICS compressed; the new MXG member EXITCICS is the ASM code
IMAC110 to create a SAS Infile Exit (named "CICS") that will read
UTILEXCL the compressed (or uncompressed) records. To install,
VMAC110 you ASM and LinkEdit the EXITCICS code into a load module
VMXGINIT that you put in a load library you add to the //STEPLIB,
Apr 7, 2006 and tell MXG using %LET SMFEXIT=CICS; in your //SYSIN.
Sep 19, 2006 Test records were reduced from 32K to about 6K bytes, but
Oct 14, 2006 only the 110-1 records are compressible.
Mar 27, 2007 -UTILEXCL updated with new CICSTRAN fields added in 3.2.
Apr 12, 2007 -Updates for the changed Statistics Subtypes:
Jun 29, 2007 (INCOMPATIBLE except for DST, DSR, and MNG):
STID DSNAME New Variables added.
- 2 SMS
==> Nothing New in DSECT.
- 64 CICDST DSTCIUHI DSTCIULO DSTNIUHI
DSTNIULO
==> But 20 bytes added are not doc'd.
- 65 CICDSR DSRCIULO DSRCIUHI
==> But 20 bytes added are not doc'd.
- 67 CICFCR DFHA17DS DSECT.
==> Nothing New in DSECT
- 74 MQG MQ Connection Statistics Global
New
==> DFHMQGDS DSECT does not exist
- 81 MNG New Compression Variables
==> DFHMNGDS DSECT is not current.
-109 ISR IP Connection (Resource)
New
==> DFHUSRDS DSECT does not exist
-117 SJG
==> Nothing New in DSECT.
-117 SJR
==> Nothing New in DSECT.
MXG 25.03 contained the critical compatibility changes,
but MXG 25.07 contains the full support for compressed
ID=110 Subtype=1 CICS/TS 3.2 SMF records.
Change 25.040 Support for APAR OA20077, adds UNCOMPRESSED tape device
VMAC21 read/write bytes to TYPE21/PDB.TAPES, complementing the
ASUMTAPE existing COMPRESSED tape channel read/write bytes that
Mar 21, 2007 have always been in SMF type 21 records:
Apr 10, 2007 BYTEREAD='COMPRESSED*CHANNEL*BYTES*READ'
BYTEWRIT='COMPRESSED*CHANNEL*BYTES*WRITTEN'
SMF21DBR='UNCOMPRESSED*DEVICE*BYTES*READ'
SMF21DBW='UNCOMPRESSED*DEVICE*BYTES*WRITTEN'
-Apr 10: ASUMTAPE updated to keep SMF21DBR/SMF21DBW.
Change 25.039 Support for AIX Tapas-C performance data creates these
EXAXTCPS datasets:
EXAXTCPU dddddd DATASET Description
EXAXTDSK AXTCPS AIXTCPUS CPUS
EXAXTFS AXTCPU AIXTCPU CPU INTERVAL
EXAXTFSS AXTDSK AIXTDSK DISK
EXAXTIP AXTFS AIXTFS FS
EXAXTIPS AXTFSS AIXTFSS FS-S
EXAXTLAN AXTIP AIXTIP IP
EXAXTLPA AXTIPS AIXTIPS IPS
EXAXTMEM AXTLAN AIXTLAN LAN
EXAXTNFS AXTLPA AIXTLPA LPARS
EXAXTPGI AXTMEM AIXTMEM MEM
EXAXTPGS AXTNFS AIXTNFS NFS
EXAXTPRO AXTPGI AIXTPGI PAGSP-S
EXAXTSYC AXTPGS AIXTPGS PAGSP
EXAXTSYI AXTPRO AIXTPRO PROC
EXAXTTCP AXTSYC AIXTSYC SYSCALL
EXAXTUDP AXTSYI AIXTSYI SYSIO
EXAXTWLM AXTTCP AIXTTCP TCP
EXAXTWLS AXTUDP AIXTUDP UDP
VMACAIXT AXTWLM AIXTWLM WLM
IMACAIXT AXTWLS AIXTWLS WLMS
VMXGINIT
TYPEAIXT
TYPSAIXT
Mar 16, 2007
Change 25.038 TMON/DB2-created SMF 101 Subtype 1 caused INPUT STATEMENT
VMACDB2 ERROR because the record is defective; LENQPAC=390 but
Mar 16, 2007 there were only 358 bytes of data in the segment. This
INPUT EXCEEDED error is now protected, but the data in
second and subsequent observations in DB2ACCTP dataset
will be trashed.
Thanks to Robert McElhaney, Texas Workers Commission, USA.
Change 25.037 SORTEQUALS option should NOT have been added to CONFIGV8,
CONFIGV8 (MXG 25.02 only, Change 25.028) as that option was added
Mar 16, 2007 in SAS V9, and did not exist in SAS V8.
Thanks to Alan Gray, CareFirst, USA.
Change 25.036 INPUT EXCEEDED for SMF 1415 in MXG 24.24, when subtype=7
VMAC1415 encrypted tape segment exists; line 743 should have been
Mar 14, 2007 -130 and not -32. And now, with data, I can see that the
Encoding Mechanism Key 1 and 2 fields, SMF14CD1/SMF14CD2
actually contain EBCDIC characters (L, H), although IBM
still has not answered my queries as to how to decode the
field or what it contained. Also, the Key Label 1/2,
SMF14KL1/KL2 are now FORMATed $HEX128.
See Change 24.047 additions in MXG 25.03.
Thanks to Douglas C. Walter, Citicorp, USA.
Change 25.035 Support for SMF 119 for z/OS 1.8 (INCOMPATIBLE, because
VMAC119 MXG INPUT statements for subtype 70 were missing OFF119xx
Mar 14, 2007 to relocate the pointer). New fields were added to many
datasets by z/OS 1.8, as noted in the comments.
Thanks to Marty Rhodes, The Hertz Corporation, USA.
Change 25.034 Support for CopyCross SMF event record, with mounted and
EXCOPYCR unloaded datetimestamps, VOLSER, data volumes in and out,
IMACCOCR in the CPYCROSS dataset. CopyCross was formerly an EMC
VMACCOCR product, but now is a Diligent product which is named
TYPECOCR VTF Mainframe 2.1.0 (Virtual Tape Facility Mainframe
TYPSCOCR Systems.
VMXGINIT
Mar 14, 2007
Thanks to Brian Felix, Wachovia, USA.
Thanks to James Bentley, Wachovia, USA.
Thanks to Lana McCormick, Wachovia, USA.
====== Changes thru 25.033 were in MXG 25.02 dated Mar 10, 2007=========
Change 25.033 Support for ASMTAPEE assembly under z/OS 1.8. IBM has
ASMTAPEE deleted fields in internal macro definitions that caused
Mar 10, 2007 "NOT FOUND" errors when assembled under z/OS 1.8. This
revision only removed those references, but had no impact
on the actual execution of MXGTMNT.
Change 25.032 RMF-like "CPU Activity" report was incorrect when IRD was
ANALRMFR active (ONLINE TIME, MVS BUSY TIME, CPU NUM), in the
Mar 10, 2007 "Partition Data" report, WGT PROCESSOR NUM, LOGICAL
Apr 10, 2007 Processors effective were incorrect, and in the "LPAR
Cluster" report, LPARCPUS was incorrect.
-Missing comma in 25.02 after MAX=NRICFCPU ... , added.
Thanks to David Klein, DOITT City of New York, USA.
Change 25.031 Variable CA7INID was not kept, because it was misspelled
VMACTPMX as CAC7IDID in the KEEP list.
Mar 7, 2007
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.030 TYPE42DS variables from Data Set I/O Statistics Section,
VMAC42 input when OFFDSIO is non-zero for this observation:
Mar 7, 2007 AVGCONMS AVGCUQMS AVGDAOMS AVGDISMS AVGIOQMS AVGPNDMS
CACHCAND CACHHITS CACHRATE CHITPCT CIOPCT DASDMPL
DASDRATE DCMEPCT HITPCT ICLS IOCOUNT MAXRSPTM
MAXSRVTM RCIPCT RDHITPCT RESPTIME RLCS SEQIOS
WRITCAND WRITHITS
were incorrectly carried forward into the next physical
TYPE42DS observation, if it did not have a Data Set I/O
Statistics Section. Now, IF OFFDSIO=0, those variables
are set missing. Note that these variables TYPE42DS
S42AMSRB S42AMSRR S42AMSWB S42AMSWR S42AMDRB
S42AMDRR S42AMDWB S42AMDWR S42AMZRB S42AMZRR
S42AMZWB S42AMZWR
are only populated when the Access Method Statistics
Section exists, i.e., when OFFDSAM is non-zero.
I do not know why some DSNAME observations contain both
or only DSIO, or only DSAM data, but this sample had:
DSIO and DSAM 15808
DSAM only 914
DSIO only 6112
Thanks to Diane Eppestine, AT&T Services, Inc, USA
Change 25.029 The individual IORATEn per-engine I/O rates in PDB.TYPE70
VMAC7072 were divided by DURATM, but IBM Reports use the SMF70ONT
Mar 7, 2007 UpTime as the denominator, so the IORATEn variables are .
now changed to match the RMF Reports. The total IORATE
variable, however, is NOT changed, and is still divided
by the DURATM, to be consistent with total IORATE data
in TYPE74, TYPE78, and other data sources that don't have
and idea about individual CPU engine up times.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.028 Changing the SAS default option to NOSORTEQUALS created
AUTOEXEC incorrect values in PDB.ASUM70PR/PDB.ASUMCEC datasets for
CONFIGV9 DURATM,PCTCPUBY,plus, but there was no error message. A
VMXG70PR code change in MXG 24.07 in ASUM70PR is the real culprit,
VMXGPRAL but the code works perfectly with the default SORTEQUALS.
UCOMPSOE Please run PROC OPTIONS to confirm you have SORTEQUALS.
Mar 10, 2007 If not, then you should use this IMMEDIATE CIRCUMVENTION:
Mar 13, 2007 Change the option for the MXG job that runs ASUM70PR.
Mar 16, 2007 You can change the option:
- on the // EXEC statement:
//MXGSTEP EXEC MXGSASV9,OPTIONS='SORTEQUALS'
or you can change the option
- in your SYSIN stream, with an OPTIONS statement;
//SYSIN DD *
OPTIONS SORTEQUALS;
%INCLUDE SOURCLIB(....);
I didn't really know any of this stuff until this error:
When SORTEQUALS is specified, SAS ensures that the input
order is preserved when BY variables have equal values.
In the SPLIT70 redesign, I added logic that depended on
LCPUADDR to be ascending order, but I failed to made sure
it was; with SORTEQUALS, since the original PDB.TYPE70PR
was in LCPUADDR order, the new logic worked just fine.
However, when NOSORTEQUALS is specified, you have told
SAS to not spend any more resources to preserve the input
order, and, in this case, the output data was no longer
in LCPUADDR order when NOSORTEQUALS was specified.
The MXG coding error is now corrected, by adding LCPUADDR
to the BY LISTs for the CPS70PRn sorts, so the ASUM70PR
logic works with SORTEQUALS or NOSORTEQUALS.
-However, now that I have seen this error, and even though
it's extremely unlikely to occur elsewhere in MXG code,
since MXG has always used only the SORTEQUALS option, I
have added SORTEQUALS to CONFIGV9 and AUTOEXEC members,
to protect for any other exposures. At worst, changing
NOSORTEQUALS to SORTEQUALS might make the SORT use a few
more CPU cycles and do a few more I/O.
-Since the error results in very bad values, it looks like
most sites still have the SAS default of SORTEQUALS, or
this error would have surfaced during earlier testing.
-Summary of MXG setting of SAS options:
For z/OS execution of MXG, CONFIGV9 sets MXG SAS options:
MXG's CONFIGV9 member still specifies NOTHREADS due to
old SAS 9.1.2 errors; see Change 22.207. However,
THREADS is primarily useful in non-z/OS; running
multiple z/OS jobs in parallel on multi-engine boxes
is essentially what THREADS is all about!
MXG's CONFIGV9 member now specifies SORTEQUALS.
For ASCII execution, AUTOEXEC sets MXG SAS options:
MXG's AUTOEXEC member has never specified THREADS, so
you get your site's default.
MXG's AUOTEXEC now specifies SORTEQUALS;
-An unrelated, harmless DIVIDE BY ZERO message if PARTNCPU
was zero is now protected. Only occurred with old 1999
test data that was itself defective, but the exposure is
corrected.
-The VMXGPRAL ("Print ALL") utility was revised to invoke
PROC COMPARE on all datasets in two libraries.
-Why choose NOSORTEQUALS? It might save a few CPU cycles
and a few I/Os, since it just merges the final sort segs,
instead of sorting, but, according to informal feedback
from SAS folks, it's only really required if you are use
the THREADS option on ASCII platforms where you have more
than one CPU. So what to do if your SAS folks demand you
don't change NOSORTEQUALS? The new UCOMPSOE utility will
run two PDB-builds, with NOSORTEQUALS & SORTEQUALS, and
then uses the (enhanced) VMXGPRAL to PROC COMPARE each
datasets in the two PDB's for differences. Unfortunately,
PROC COMPARE will report all datasets with different sort
order, even though the two dataset's values are the same.
You use the PROC COMPARE output to identify differences,
and then use PROC MEANS N MIN MAX SUM DATA= OLD/ NEW to
verify that the numeric contents are the same.
For example, MXG 25.02 found these datasets were built
in different order with the two options in effect:
TYPE70 TYPE70PR TYPE74CO TYPE74DU TYPE74PA
TYPE74ST TYPE77
but the PROC MEANS showed no actual value differences.
Mar 16: Find four lines with BWM. Delete the line which
has PROC PRINT and printed lots of useless output.
Thanks to Salis Gross Curdin, Credit-Suisse, SWITZERLAND.
Thanks to MP Welch, SPRINT, USA.
Change 25.027 JCLTESTx only. INPUT DATASET PDBMONIDBDS DOES NOT EXIST
VMACMONI error in no-longer-used VMACMONI due to missing second
Mar 7, 2007 period; the correct syntax is
MACRO _LMONDBD &PMONDBD..MONIDBDS %
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND.
Change 25.026 Cosmetic. DIVISION BY ZERO message if IORATE was zero;
ANALFIOE now, that denominator is tested prior to the division.
Mar 6, 2007
Thanks to James Majeski, AT&T Services, Inc, USA
====== Changes thru 25.025 were in MXG 25.01 dated Mar 5, 2007=========
Change 25.025 Support for APAR OA19453, which adds a new 4-byte counter
VMAC7 (SMF7NROX) that is now used instead of the 2-byte SMF7NRO
Mar 6, 2007 count of lost SMF records when SMF 7 data lost record is
written. The MXG Variable LOSTRECS is populated from the
new SMF7NROX field if it is present and SMF7FL1 bit is
set that NROX is populated.
Change 25.024 INPUT STATEMENT EXCEEDED for RACF 80 WHEN (301) Extension
VMAC80A segment for OMVS and PROXY, but neither had any of the
Mar 2, 2007 expected data segments. Now, LENLEFT is calculated and
tested prior to the INPUT.
Thanks to Robert Sample, Atlanta Journal-Constitution, USA.
Change 25.023 The two examples that construct datetime ranges from one
ANAL16 dataset, to build a format for selection from a second
ANAL30 dataset used DATETIME21.2 characters in the format, but
Mar 2, 2007 that failed when months were crossed due to month names.
This redesign uses PUT(datetime,13.2) to create the text
(number of seconds since 1/1/1960) for the format item.
Less pretty when printed, but it will always work.
Thanks to Tom Elbert, Assurant, USA.
Change 25.022 The RMF III ENC extension was usually not INPUT because
VMACRMFV the ENCG3XEO offset does not point to the extension that
Mar 1, 2007 was added to the end of the record ASMRMFV creates. That
extension is located at ENCG3XEO=ENCG3DEO+ENCD3DEL which
is now used to INPUT Service and Reporting Class
information from the ENC Extension.
Thanks to Brenda Rabinowitz, Merrill Lynch, USA.
Change 25.021 UTILEXCL messages are enhanced if the IMACICEZ EZA fields
UTILEXCL are found, to point you to read the text of Change 24.033
Mar 1, 2007 because there are multiple EZA segments created, and that
Apr 17, 2007 change text has tailoring instructions. IMACICE2 message
for EZ2 fields now also point you to read Change 24.033.
Change 25.020 The QWS3xxxx and QWS4xxxx variables are labeled IRLM and
VMACDB2 DDF (DIST), but the data could be reversed, with the DIST
Feb 28, 2007 data values in the QWS3xxxx variables and IRLM in the 4th
set of variables, because IBM has changed which data is
in which segment. This change tests the QWSnPROC name to
determine which data is present, so that the QWS3xxxx are
now ALWAYS the IRLM and QWS4xxxx is now ALWAYS the DDF
data, so the data always matches the variable labels, no
matter which segment had that ASID's data. Variables
QWSnASCB,ASID,EJST,PROC,PSRB,SRBT,QWSnZSRB are created
in PDB.DB2STATS from QWSA segments in SMF 100 records.
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Lori A. Masulis, Fidelity Systems, USA.
Change 25.019 The RACF 0900-series IRRHFSU Unix System Services unload
VMACRACF fields all contain EBCDIC, rather than ASCII text. The
Feb 28, 2007 test data had been converted to ASCII when it was sent;
all of the $ASCII inputs are changed to $EBCDIC now.
Change 25.018 Support for eleven more optional CICS EZA02 fields with
IMACICE2 these similar names:
VMAC110 EZA0TCON EZA0TSTA EZA0TINV EZA0TDIT EZA0TDIP
Feb 28, 2007 EZA0TGIV EZA0TSEC EZA0TA08 EZA0TA09 EZA0TA10
Apr 16, 2007 EZA0TA11
because I assumed they were now the default set of fields
in that optional segment. However, as I have not seen
them at other sites, I suspect they were accidentally
created at this site, and thus not likely to exist in
your EZA02 fields. As documented in Change 24.033, you
must look at the output report from UTILEXCL to see what
EZAxxxxx fields exist in your data, and then EDIT the
IMACICE2 to only INPUT and LABEL those in your records.
Text was revised Apr 16, 2007. No code change.
Thanks to Paul C. Gordon, Bank of America, USA.
Thanks to Peter Krijger, ANZ National Bank, NEW ZEALAND.
Change 25.017 EXITCICS is the Assembly code for a SAS INFILE EXIT that
EXITCICS will read and uncompress SMF 110 subtype 1 records as
Feb 28, 2007 they are read. You assemble/link edit the ASM code in
Mar 7, 2007 the EXITCICS member to create a load module CICSIFUE in
MaR 10, 2007 a Load Library, concatenate that DSNAME to //STEPLIB DD
in your MXGSASV9 JCL procedure, and then tell MXG you
have the INFILE exit installed, using the (new in 24.24)
SMFEXIT macro variable:
//SYSIN DD *
%LET SMFEXIT=CICS;
%INCLUDE SOURCLIB(TYPE110);
and MXG will read compressed and/or uncompressed records
transparently. You can alternatively use ENGINE=CICS in
your FILENAME statement to invoke the INFILE exit.
- The LOAD MODULE must be named CICSIFUE.
- The INFILE EXIT/ENGINE name is CICS.
You need EXITCICS dated Mar 7. the Feb 28 didn't work.
Thanks especially:
Thanks to Rich Anderson, SAS Technical Support, USA, for
his extensive testing and investigation that made this work!
Change 25.016 Cosmetic. Variable SMFTIME was added to EXCLUDED FIELDS
VMAC110 FOUND error message to identify when the record was
Feb 27, 2007 written, so it could be compared with the time when the
CICS Dictionary Records had been written.
Thanks to Shirly Fung, HSBC, HONG KONG.
Change 25.015 ERROR: BY VARIABLE BLKBINST IS NOT ON INPUT WEEK.BLKBERRY
VMACNTSM is an INCOMPATIBILITY created by MXG Change 24.162, when
Feb 25, 2007 the new variable BLKBINST was added to the BY list for
the NTSM dataset BLKBERRY. The error only occurs in your
WEEKly or MONTHly PDB build, and only when you have one
or more PDBs that were created with the prior MXG version
(i.e., the variable does not exist in the old datasets).
Mini-tutorial on BY list variables in MXG:
Adding a new variable to the BY list for an existing MXG
dataset is done ONLY when it is absolutely needed. The
primary reason MXG has a BY list for each dataset is to
protect for duplicate records in the input file, When MXG
uses the NODUP option in PROC SORTing from the "WORK" to
the "PDB" library. The BY list must be complete so that
duplicate observations are adjacent. A secondary reason
is for retrieval performance; by creating datasets in
sorted order, an extra SORT can be avoided in your report
programs.
Error correction techniques:
-Fix it permanently now, by adding the new variable to all
of the old, existing DAYly and/or WEEKly PDBs that will
be needed to build the new WEEKly and/or MONTHly PDBs,
creating the variable with blanks for Character or a
missing value for Numeric variables. You will need to
look up the variable in the DOCVER member to find its
DATASET, then the variable name in the listing to find
the CHAR/NUM type and the LENGTH of the new variable,
and then add that variable to all of the prior-built PDBs
using this syntax:
For a character variable:
DATA OLDPDB.BLKBERRY;
SET OLDPDB.BLKBERRY;
LENGTH BLKBINST $32;
BLKBINST=' ';
or for a numeric variable:
DATA OLDPDB.BLKBERRY;
SET OLDPDB.BLKBERRY;
LENGTH BLKBNUMR 4;
BLKBNUMR=.;
You will need to point "OLDPDB" to one of the prior PDB
libraries that does not contain the new variable and
run the datastep, then change "OLDPDB" to the next PDB,
until all of the INPUT PDBs (dailies for WEEKBLD, or
weeklies and dailies for MONTHBLD).
And if the OLDPDB is a data library on TAPE media,
it gets more complicated; you cannot have a TAPE
PDB open for both INPUT and OUTPUT, and you cannot
replace-in-place a dataset in a Tape media library,
so you would need to use this syntax for each "PDB":
PROC DELETE DATA=WORK._ALL_;
PROC COPY IN=OLDTAPE OUT=WORK;
DATA WORK.BLKBERRY;
SET WORK.BLKBERRY;
LENGTH BLKBINST $32;
BLKBINST=' ';
PROC DELETE DATA=OLDTAPE._ALL_;
PROC COPY IN=WORK OUT=OLDTAPE;
Once you have added the new variable to all of the INPUT
PDB libraries, you can then rerun the WEEKBLD/MONTHBLD.
-Fix it temporarily by redefining the _Bdddddd macro so it
does not reference the variable for the WEEKBLD/MONTHBLD
job:
-Look in the IMACxxxx member to find the "dddddd" text
for the dataset with the error. In IMACNTSM, it lists
that dddddd=NTBLKB for BLKBERRY dataset.
-Then, look in he VMACxxxx member for _Bdddddd to find
the BY list variables. In VMACNTSM, _BNTBLKB has
MACRO _BNTBLKB DOMAIN SYSTEM BLKBINST STARTIME %
-Then, in the //SYSIN for the WEEKly/MONTHly job, you
would redefine the _Bdddddd macro with that variable
removed:
//SYSIN DD *
%LET MACKEEP=
MACRO _BNTBLKB DOMAIN SYSTEM STARTIME %
;
%BLDNTPDB(your arguments for WEEKly/MONTHly);
Since the new variable does exist in one of the INPUT
data sets, it will be propagated into the new WEEKly
PDB, so you would only need to use this circumvention for
a maximum of five weeks, and then all of your Weekly PDBs
will contain the new variable, and the redefintion of the
MACRO _Bdddddd can be removed from your Monthly Job.
However, this circumvention might fail due to NOTSORTED
condition, (only if the "PDB" dataset had more than one
value in BLKBINST variable); in that case, you would need
to re-SORT those datasets using the _Sdddddd dataset SORT
macro with the new _Bdddddd BY list definition:
//SYSIN DD *
%INCLUDE SOURCLIB(VMACNTSM);/*get _Sdddddd def*/
%LET MACKEEP=
MACRO _BNTBLKB DOMAIN SYSTEM STARTIME %
;
DATA WORK.BLKBERRY;
SET PDB.BLKBERRY;
_SNTBLKB
NOTE BENE: It is always STRONGLY recommended that you
install a new version of MXG on the first day of your
week, so that all of that week's daily PDBs are built
with the same MXG Version. It just works better!
Thanks to Terry Hein, ECOLAB, USA.
Change 25.014 No observations were output in NDMRT because of a missing
VMACNDM end of comment */ text.
Feb 23, 2007
Thanks to Michael Creech, Fidelity National Information Svcs, Ind.
Change 25.013 The PCTMVSBY in PDB.TYPE70PR when IRD was active and the
VMAC7072 engine was not online for the entire interval were wrong;
Feb 23, 2007 This also impacted the SHORTCPS value as well. Now, the
SMF70ONT is used instead of DURATM for PCTMVSBY.
Thanks to John A. Doan, T-SYS, USA.
Change 25.012 INPUT STATEMENT EXCEEDED RECORD for IBM ID=99 Subtype=1
VMAC99 because MXG thought there would always be a System State
Feb 21, 2007 Information Section, but this record had none. The offset
and segment length fields were populated, but the number
of segments contained zero. Now, MXG tests segment count
non-zero before reading that segment, and before OUTPUT
of the TYPE99_1 dataset. This record contained Trace
Table entries, so was thus a legitimate record.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Warren Cravey, Fidelity Systems, USA.
Change 25.011A IBM Virtualization Engine TS7700 Series Statistics data
TYPEBVIR can now be created as a RECFM=U or RECFM=VB History file,
TYPSBVIR or those data can be written to SMF; this change supports
VMACBVIR both the SMF and History file records. By default, MXG
Feb 19, 2007 reads SMF data, but you must add MACRO _IDBVIR nnn % in
Feb 26, 2007 IMACKEEP tailoring member to define your SMF record ID.
To process the History File, change _SMF to _HISTFI in
your TYPEBVIR or TYPSBVIR member. The Point in Time
subtypes (01,02,10,11) are not written to the SMF file.
Change 25.011 The preliminary ANALMQMC member should no longer be used;
ANALMQMC it was preliminary and was replaced by revisions to the
Feb 21, 2007 ASUMUOW program. The dataset MQMUOW is no longer created
by ANALMQMC, as that logic is in a comment block, and now
only ASUMUOW is executed with ANALMQMC is executed.
Comments in the member were revised.
Thanks to Harald Seifert, HUK-COBERG, GERMANY.
Change 25.010 Support for TELEVIEW Release 4.4 was already in place;
VMACTELE there were no changes to their SMF record.
Feb 21, 2007
Thanks to Lawrence Hogg, NYU, USA.
Change 25.009 The new ERASEPDB option was not set to a default; it is
BLDSMPDB now set to YES.
Feb 15, 2007
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 25.008 -In IMACICOB, OMDBDB2LN should have been spelled OMBDB2LN.
IMACICOB -In IMACICOM, QMMLN should have been spelled OMMQLN.
IMACICOM
Feb 15, 2007
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 25.007 The optional CICS BMC CMRDATA has variables CMDUDATA and
IMACICMR CMDDBCCP reversed; the correct order is CMDUDATA first.
Feb 15, 2007
Thanks to Bill Keezer, SAS Institute, USA.
Change 25.006 Support for MXG IMS Log processing for IMS Version 10:
VMACIMS -For users of TYPEIMS7, members VMACIMS and TYPEIMS7 with
TYPEIMS7 this Change 25.006 (in MXG 25.01) are required, and you
ASMIMSL6 must update the _IMSVERS to 10.0 in IMACIMS7 in your
JCLIMSL6 "USERID.IMSV10.SOURCLIB(IMACIMS7)" tailoring.
Feb 19, 2007 -For users of ASMIMSL6,TYPEIMSA,JCLIMSL6 job stream, you
Feb 27, 2007 reassemble ASMIMSL6 with the IBM IMS V10 macro library to
create the "USERID.IMSV10.LOADLIB(MXGIMSL6)" for the
PGM=MXGIMSL6 for your V10 jobstream.
-Because there is no Version number in IMS log records,
separate job streams for each IMS version's log file is
required, so creating V10-only "USERID" and "LOADLIB"
datasets is required, along with associated JCL DSNAME=
changes will, unfortunately, also be required.
Updates were required to support new fields INCOMPATIBLY
that were inserted in IMS log 07 and 08 records, and new
variables are created in IMS0708 and IMSSUMRY datasets.
There is a new CPU metric, DLREXETM, that is documented
as the total CPU time from 08 to 07, but in test data,
it was very close to IMSCPUTM in three BMP transactions
but on BMP that ABENDed had much smaller DLREXETM than
the IMSCPUTM value, so it is somewhat suspect.
Other IMS log records will be validated shortly.
Thanks to Curdin Salis Gross, Credit-Suisse, SWITZERLAND.
Change 25.005 SQLServer:Replication objects now have instance names, so
VMACNTSM KNOWN SORA OBJECT. UNEXPECTED NRDATA message is gone and
Feb 12, 2007 variables SQRSNAME SQRMNAME SQRLNAME SQRDNAME SQRANAME
Feb 19, 2007 are now created. Labels for four cachxxxx were added.
Thanks to Bob Gauthier, Albertsons, USA.
Change 25.004 Change 24.159 added TWOHOUR, FOURHOUR, EIGHTHR arguments
VMXGDUR to VMXGCICI for CICS summarization; those INTERVAL values
VMXGSUM are now also supported in VMXGSUM and VMXGDUR %macros.
Feb 11, 2007
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 25.003 Variable NREXPOSR is INCOMPATIBLY changed by IBM for HPAV
VMAC74 to contain the accumulated product of UCBs and samples in
Feb 8, 2007 SMF74PSM. Now, MXG recalculates for HyperPav using:
IF HYPERPAV='Y' THEN NREXPOSR=NREXPOSR/SMF74PSM;
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Gilles Lachassagne, CA, FRANCE.
Change 25.002 VMACMWUX in MXG 24.24 was restored from the last changed
VMACMWUX member from MXG 22.22; somehow, I replaced MWUX with an
Feb 8, 2007 older and archaic member.
Thanks to Roman Gudz, Penske, USA.
Change 25.001 Correction to NRICFCPU and NRIFLCPU in ASUM70PR/ASUMCEC
VMXG70PR datasets, if you had more than one. The MAX= statement
Feb 8, 2007 in line 295 should have been
SUM=X NRICFCPU NRIFACPU NRIFLCPU NRZIPCPU;
The counts in NRIFACPU and NRZIPCPU were correct because
they are recalculated to be the Average number based on
those engines UP-time, in case IRD takes control
LASTCHANGE: Version 25.
=========================member=CHANGE24================================
/* COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG 24.24 is the 2007 "Annual Version", dated February 5, 2007.
MXG Version 24.24 is dated Feb 5, 2007, thru Change 24.306
MXG Version 24.11 was dated Feb 3, 2007, thru Change 24.304
Fourth MXG Version 24.10 was dated Jan 31, 2007, thru Change 24.300
Third MXG Version 24.10 was dated Jan 28, 2007, thru Change 24.293
Second MXG Version 24.10 was dated Jan 22, 2007, thru Change 24.282
First MXG Version 24.10 was dated Jan 21, 2007, thru Change 24.279
MXG Version 24.09 was dated Dec 20, 2006, thru Change 24.251
MXG Version 24.08 was dated Oct 18, 2006, thru Change 24.216
First MXG Version 24.08 was dated Oct 17, 2006, thru Change 24.214
MXG Version 24.07 was dated Sep 22, 2006, thru Change 24.186
First MXG Version 24.07 was dated Sep 21, 2006, thru Change 24.185
MXG Version 24.06 was dated Aug 30, 2006, thru Change 24.165
MXG Version 24.05 was dated Jul 3, 2006, thru Change 24.120
MXG Version 24.04 was dated Jun 22, 2006, thru Change 24.109
MXG Version 24.03 was dated May 15, 2006, thru Change 24.075
First MXG Version 24.03 was dated May 13, 2006, thru Change 24.073
Second MXG Version 24.02 was dated Apr 26, 2006, thru Change 24.057
First MXG Version 24.02 was dated Apr 24, 2006, thru Change 24.050
MXG Version 24.01 was dated Mar 1, 2006, thru Change 24.012
MXG Newsletter FORTY-EIGHT was dated Feb 20, 20056
The instructions for ftp download of MXG 24.24 was mailed to all sites.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. 2007 Annual MXG Software Version 24.24 instructions were sent.
II. Incompatibilities and Installation of MXG 24.24.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Version 24.24, dated Feb 5, 2007 - the Annual Version for 2007.
Major enhancements added in MXG 24.24.
TYPENMON 24.296 Support for NMON (free from IBM) AIX/Linux Monitor.
TYPE1415 24.295 Support for APAR OA17569 Tape Encryption new fields
TYPE112 24.294 Support for SMF ID=112 CICS ONDV record.
TYPESFTA 24.304 Support for Tivoli License Compliance Manager 4.2
TYPERMFV 24.302 Support for additional zIIP data in RMF III ZRBENC.
TYPEEDGR 24.299 Support for z/OS (COMPATIBLE) changes to RMM data.
TYPE1415 24.295 Support for APAR OA17569, Encrypted Tape Keys/Mech.
TYPEWMQA 24.292 Support for WebSphere MQ V6.0 OPEN SYSTEMS acct/stats
TYPE119 24.289 Support for FTP Client Security fields in TYP11903.
IMACICO2 24.297 Support for CMODHEAD=OMEGAMON segment.
TYPEBBMQ 24.281 Support for BMC Mainview for MQ Series VSAM History.
TYPESAMS 24.279 Support for SAMS Vantage Version 6; new datasets.
TYPE116 24.293 Support for NETSNAME/UOWTIME from QWHCNID in SMF 116.
TYPETAND 24.286 Support for Tandem H06 release.
TYPETPF 24.283 Support for TPF thru PUT19.
ANALS225 24.282 New "DB2 Storage Analysis" uses IFCID 225+DB2STATS.
TYPE7072 24.290 Circumvention for invalid CPURCTTM in 72 and 30s.
IMACICOM 24.287 BMC CANMQ CICSTRAN MQTOTTM invalid due to MXG error.
TYPE102 24.291 Correction for SMF 102 IFCID 22.
TYPEBVIR 24.305 Support for IBM BVIR History for TS7700 VTS System.
BLDSMPDB 24.298 New BUILDPDB=COPYONLY option enhancement.
IMACICO2 24.297 Support for new CMODHEAD='OMEGAMON' CICS segment.
Major enhancements added in MXG 24.10.
ASUMTAPE 24.265 Critical correction for ASUMTAPE for IBM Volume Exit
UTILEXCL 24.254 Support for all Omegamon/Candle optional CICS data
TYPERMFV 24.272 Support for RMF III VSAM ENC Extension segment.
TYPEMVCI 24.264 Support for CMRDETL for Mainview for CICS V 5.9.00.
TYPEBETA 24.257 Support for Beta 93 Version 3.6.1
ADOC30 24.269 Schematic documentation of zIIP CPU variables.
VMXGSUM 24.267 New MINLONG=,MAXLONG= arguments created for 8-byters.
TYPEPROS 24.258 Product section character variables were wrong.
TYPE102 24.256 IFCID 226 and 227 new variables added.
TYPEIPAC 24.259 Mobius Subtype 8 INPUT STATEMENT EXCEEDED.
ASCISMFC 24.274 ASCII execution utility to create SMF subset from ftp
VMXG70PR 24.278 More ASUM70PR touch-up, dedicated CPUs, etc.
ANALCISH 24.277 Updated for dropped variableS MNGSYSER/MNGSYSEE.
Major enhancements added in MXG 24.09.
TYPE74 24.228 Support for HyperPAV APAR OA12865.
TYPE78 24.228 Support for HyperPAV APAR OA12865.
IMACEXD 24.221 Support for SAR/EXD SMF type 6 optional data.
TYPENTSM 24.218 Support for NTSM Beta Version 3.0.0.8 (COMPATIBLE).
TYPENSPY 24.212 Support for NetSpy Version 11 was added Aug, 2005.
TYPE99 24.210 Support for SMF 99 Resource Group, TYPE99RG dataset.
ASUMDB2G 24.244 New PDB.ASUMDB2G summary for DB2 Global Buffers.
VMXGINIT 24.242 Revisions for SAS V9 BI SAS/ITRM anticipated changes.
IMAC6ESS 24.227 Optional ESS GPARMKEY='4A'x caused INPUT error.
TYPE70 24.225 LPARs with no current weight has LPARSHAR=0.
TYPE7072 24.224 Fall Clock "Set Back" protection for dupe STARTIME.
TYPE78 24.223 Virtual Storage Above the Bar Shared not Input.
TYPE110 24.222 Stat vars DSGEJST,DSGSRBT now kept in CICDS.
TYPENTSM 24.220 NTSMF Object 'DATABASE ==> INSTANCES" new DATABASI.
TYPE119 24.215 Vars TSICDUTM thru TSICOUAR were incorrect in MXG.
ASMRMFV 24.214 Protection for z/OS 1.6 which had no SPG records.
TYPE7072 24.208 LPAR SHARE variables were wrong with Dedicated CPs.
MXGSASVn 24.246 REGION=0M added to MXG JCL procedure examples.
Major enhancements added in MXG 24.08.
CRITICAL: Final corrections to "SPLIT70" redesign in Change 24.207.
All SPLIT70 errors in MXG 23.23 thru MXG 24.07 have been corrected.
MXG 24.08 is required for z/OS 1.7 now because of these corrections.
MXG 23.23 thru MXG 24.07 should be replaced by MXG 24.08 or later.
TYPETPMX 24.199 Support for ThruPut Manager Version 6 new variables.
TYPENTSM 24.206 Support for NTSMF Version 3.0.0.7.
TYPEMPLX 24.204 Support for IMPLEX Version 4.10 (INCOMPATIBLE).
TYPEMWNT 24.191 Support for HP MeasureWare for Windows/NT.
TYPETNG 24.188 Support for new TNG object (NT and Solaris).
TYPETHAL 24.201 Support for E-Thales Security five user SMF records.
TYPE82 24.200 Support for SMF 82 subtype 22, correction to st 21.
VMACSMF 24.202 &SMFEXIT macro variable added to INFILE &SMF.
TYPE30 24.198 INTETIME in TYPE30_6 was wrong if GMT offset nonzero.
TYPE1415 24.196 TYPE1415 INPUT EXCEEDED with z/OS 1.7/1.8 PDSE data.
TYPEDB2 24.194 DB2STATS variables CPUTM, QWSnXXXX corrected.
Many 24.193 Support for 3592 Tapes, no change, they're 3590s.
ASUM70PR 24.187 INTERVAL=HOUR could create obs with smaller DURATM.
Major enhancements added in MXG 24.07.
ASMHSCEX 24.092 Support for z/OS 1.8 (COMPATIBLE).
ASMHSCEX 24.171 Support for CrossCopy in MXGTMNT HSC Exit.
TYPERMFV 24.181 Support for RMF III OPGG3, SPGG3, zips in CPUG3.
TYPE70 24.184 PCTIFBYn/PCTZIBYn are "MVS", new PCTCIBYn is "LPAR".
TYPERACF 24.178 Support for IRRHFSU (Unix z/OS file permissions).
VMACNDM 24.182 NDMCPUTM and NDMCPU now validated and correct.
TYPE1415 24.170 MXG 24.06 only. NO MATCHING IF error.
TYPEDB2 24.177 INPUT EXCEDED ID=100 SUBTYPE=0 more than 1 QLST.
TYPE110 24.166 Support for BMC Mainview/CICS optional DB2 and CMR.
VMAC110 24.185 Support for DMF Product's SMF 110 (CICS 4.1!) data.
Major enhancements added in MXG 24.06.
TYPENTSM 24.162 Support for NTSMF 3.0.0, also 35 new objects.
TYPEQACS 24.161 Support for i/Series QACS AS/400 Release 5.4.0.
TYPECMHM 24.153 Support for EMC's Centera Mainframe HSM Migrator SMF.
TYPEPRPR 24.145 Support for Oce's Prisma Print '9901' USER record.
TYPENDM 24.144 Support for NDM/Connect-Direct Release 4.3/4.5.
TYPE72GO 24.125 New ZIP variables were not kept in TYPE72GO.
BUILDPDB 24.128 New ZIP variables are now kept in PDB.STEPS/JOBS.
TYPE70 24.142 PCTRDYWT, new SMF70Qnn wrong, new PCTRDQWT created.
FORMATS 24.163 Support for z9EC on 32-bit; no change for 64-bit.
TYPEDB2 24.141 QLESxxxx DB2 statistics variables corrected.
ANALDEVN 24.157 Example to identify all devices allocated by a JOB.
CICSBAD 24.155 Not all PROGRAM='########' should be in CICSBAD?
TYPE80A 24.152 Protection for $VARYINGnn. mm input with nn GT mm.
VMXG70PR 24.124 Variables SHIFT, ZDATE, ZTIME in ASUM70LP fixed.
UTILEXCL 24.140 Support for ARZGEOS/FACHG, ARGZD/GSACCT optionals.
TYPEDB2 24.136 Support for DB2 V8 UIFCIDS=YES ASCII test.
ANALDB2R 24.138 Incorrect Plan counts, DB2PARTY='R" were summed.
TYPEXAM 24.135 MTRSYS variables were wrong after SYSTMID.
UTILEXCL 24.131 Candle short CICS dictionary record supported.
TYPEORAC 24.130 Oracle support is no longer subsystem dependent.
ASUMUOW 24.129 PDB.ASUMUOW support for 10 CICS ABCODE values.
IMAC6ESS 24.127 Support for GEPARMKY='4D'x and '4A'x
TYPE102 24.121 Support for IFCID=350, replaces IFCID=63, long SQL.
Major enhancements added in MXG 24.05.
ASUM70PR default restored to INTERVAL=DURSET
RMFINTRV enhanced to support SYNC59
WEEKBLD/WEEKBLDT typos (only in 24.04) corrected.
Major enhancements added in MXG 24.04.
TYPE7072 24.110 Support for z9BC Processor (COMPAT if 64-bit z/OS)
TYPE30 24.046 Support for zIIP-ZIP engines.
TYPE7072 24.046 Support for zIIP-ZIP engines.
TYPEDB2 24.046 Support for zIIP-ZIP engines.
TYPERMFV 24.046 Support for zIIP-ZIP engines.
ASUM70PR 24.105 Corrections, revisions, ASUM70PR, ZIP and IFAs.
ASUM70PR 24.105 INTERVAL=QTRHOUR is new default for ASUM70PR/70LP.
TYPE1415 24.094 Support for PDSE Caching statistics APAR OA12857
ASUMTAPE 24.102 PDB.ASUMTAPE will have zero obs if SYSLMNT has 0 obs.
ASUMTAPE 24.102 PDB.ASUMTAPE BEGTMNT, ENDTMNT, TOTMNTTM created.
ASMHSCEX 24.096 Revised STK Exit UX01 adds logic to save registers.
ASMRMFV 24.091 RMF III enhancement, ENC data, Index usage.
TYPERMFV 24.090 RMF III RESOURCE TYPE MISMATCH corrected for UWDG3.
RMFINTRV 24.079 New NOTYPE74= option will skip TYPE74 processing.
TYPEVMXA 24.078 All z/VM MONWRITE datasets have variable SYSTEM.
VMXGDUR 24.105 New MXGDURTM variable is created.
Major enhancements added in MXG 24.03.
ASUM70PR 24.064 Redesign of ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP code.
Corrects errors, supports different DURATMs in CEC.
Extensive discussion of CEC metrics in change text.
This change is required if you use these datasets.
TYPE89 24.063 TYPE89/TYPE892 MACHTIME calculation revised.
ANALRMFR 24.060 RMF CPU Activity Report updated for IFAs and IFLs.
WEEKBLxx 24.058 SORT order of PDB.ASUMTAPE was inconsistent.
WEEKBLxx 24.064 New &MXGNOBY to circumvent NOT SORTED in WEEKBLD.
MONTHxxx 24.064 New &MXGNOBY to circumvent NOT SORTED in MONTHLD.
ASMTAPEE 24.075 ML-39 of MXGTMNT, gets suppressed SYSLOG messages.
Major enhancements added in MXG 24.02.
Two more IMPORTANT/CRITICAL corrections to the "SPLIT70" redesign:
TYPE7072 24.032 PCTCPUBY/PCTMVSBY in TYPE70 wrong when IRD active.
TYPE7072 24.043 PCTCPUBY/CPUACTTM missing in non-LPAR'd system.
Other, less critical enhancements:
TYPERMFV 24.042 Support for CPC RMF III report data.
TYPETIAO 24.045 Support for APAR UK12301 (Tivoli Alloc Optimizer)
TYPEDB2 24.028 Support for APAR PK15468, adds QWSnPSRB.
TYPE16 24.013 Support for New Memory Object Data in DFSORT.
TYPE102 24.027 SQL Text missing in AUDIT trace 140-145 IFCIDs.
TYPESYNC 24.025 8-byte variables replaced 4-byte variables.
E2dddddd 24.024 New E2dddddd members for "2 Phase" tailoring.
VMXGINIT 24.023 MXG Default TAPENGN is now V9SEQ.
MONTHBLD 24.022 ASUMDB2B BY list did not match weekly BY list.
TYPE80 24.018 RACF Reloate 301 section INPUT STATEMENT EXCEEDED.
TYPEDB2 24.044 BEGTIME missing in DB2STATB dataset.
TYPE30 24.053 Negative CPUUNITS error suppressed if delta is small.
Major enhancements added in MXG 24.01 - 2006 Annual MXG Version
TYPEVMXA 24.003 Toleration Support for z/VM 5.2 (INCOMPATIBLE).
TYPE102 24.001 Support for truncated SQL Text in DB2 Audit Trace.
TYPE30 24.005 Support for APAR OA14340, adds 8-byte EXCPTOTL field.
TYPE70 24.010 Array subscript out of range with 60 LPARs.
TYPE30 24.011 Negative/missing values in PDB.TYPE30_6.
TYPE30 24.009 Variable AVGWKSET/PAGESECS accumed over TCB+IFA.
TYPE30 24.009 Variable CSTORE30 is now always missing.
TYPE102 24.001 INPUT EXCEEDED SMF 102 truncated SQL text fields.
TYPE70 24.010 Variable LPARNSW in RMFINTRV/TYPE70 could be zero.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements in MXG 22.08" in CHANGES, above, for the major
items, then search Newsletters for V9 for all of the minor items.
MXG executes under SAS V8.2 and SAS V9.1.3, but MXG is no longer
supported under SAS V6. The "PDB" libraries written to by MXG
must have been created by V8/V9 (i.e, if ENGINE=V6 is shown in the
PROC CONTENTS output, you must convert that data library to the
current ENGINE=BASE by PROC COPYing it under SAS V8 or V9.
For SAS V9.1.3 on z/OS with Service Pack 4:
There are no reported errors, and MXG's CONFIGV9 now specifies
V9SEQ instead of V6SEQ. As V6SEQ does not support long length
character variables, it should not be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are still SAS V9.1 or V9.1.2,
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) is required
to be completely safe. No earlier Version 8's were supported.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it is now the default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG New-Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on Windows XP with SAS V9.1.3. But previous QA tests
have been run with all SAS releases on z/OS, SAS V8.2 and V9.1 on
Linux RH8 on Intel, with V9.1 on Solaris v2.8 on Model V880, and
V9.1 on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V8.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
Availability dates for the IBM products and MXG version required for
the processing of that product's data records:
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 Sep 30, 2005 *24.24
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS ZIP Processor Support Jun 22, 2006 *24.24
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
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
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 ??? 15, 2006 24.??
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
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
DFSORT SMF V1R5 Mar 1, 2006 24.02
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Dec ??, 2004? 22.08
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
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 20.04
The Monitor for DB2 Version 4.0 22.10
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 CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including cics/ts 3.1 22.08
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
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
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 CICS V500 User SMF 18.01
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 22.08
Memorex/Telex
LMS 3.1 12.12A
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
II. Incompatibilities and Installation of MXG 24.10.
1. Incompatibilities introduced in MXG 24.24 (since Annual MXG 24.01):
a- Changes in MXG architecture made between 24.24 and prior versions
that can introduce known incompatibilities.
ITRM Sites MAY have to add _STY70 invocation in their EXPDBOUT
exit member, but only if they run BUILDPDB without RMFINTRV.
See Change 23.321. DATA SET PDB.TYPE70 NOT FOUND ERROR without.
If you use MXG _VAR7072 and _CDE7072 in your own program to read
RMF 70s, you MUST now invoke _STY70 after your data step due
to MXG support for split SMF 70 records. Change 23.321.
If you used EXTY70 or EXTY70PR to create new variables, you must
now use the E2TY70 or E2TY70PR "Second Phase" exit members.
See Change 24.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 JCLINST9.
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. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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.
_PAGE_ 8
Alphabetical list of important changes in MXG 24.10 after MXG 24.01:
Dataset/
Member Change Description
ANALDB2R 24.138 Incorrect Plan counts, DB2PARTY='R" were summed.
ANALDEVN 24.157 Example to identify all devices allocated by a JOB.
ANALRMFR 24.060 RMF CPU Activity Report updated for IFAs and IFLs.
ASMHSCEX 24.096 Revised STK Exit UX01 adds logic to save registers.
ASMHSCEX 24.171 Support for CrossCopy in MXGTMNT HSC Exit.
ASMRMFV 24.091 RMF III enhancement, ENC data, Index usage.
ASMRMFV 24.214 Protection for z/OS 1.6 which had no SPG records.
ASMTAPEE 24.075 ML-39 of MXGTMNT, gets suppressed SYSLOG messages.
ASUM70PR 24.064 Redesign of ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP code.
ASUM70PR 24.095 Variables LPCTBY LPCTOV PCTLPBY PCTLPOV missing.
ASUM70PR 24.105 INTERVAL=QTRHOUR is new default for ASUM70PR/70LP.
ASUM70PR 24.187 INTERVAL=HOUR could create obs with smaller DURATM.
ASUMDB2G 24.244 New PDB.ASUMDB2G summary for DB2 Global Buffers.
ASUMMIPS 24.080 _SYNC59 option added to MIPS/MSU analysis.
ASUMRAID 24.057 New RAID Analysis, all VOLSERs on each CSSSID.
ASUMTAPE 24.102 PDB.ASUMTAPE BEGTMNT, ENDTMNT, TOTMNTTM created.
ASUMTAPE 24.102 PDB.ASUMTAPE will have zero obs if SYSLMNT has 0 obs.
ASUMUOW 24.129 PDB.ASUMUOW support for 10 CICS ABCODE values.
BLDSMPDB 24.298 New BUILDPDB=COPYONLY option enhancement.
BUILDPDB 24.128 New ZIP variables are now kept in PDB.STEPS/JOBS.
CICSBAD 24.155 Not all PROGRAM='########' should be in CICSBAD?
CLRMFV 24.037 New version of CLRMFV TSO CLIST for RMF III.
Doc 24.015 Identifying CRYPTO users and usage.
Doc 24.034 Example to create numeric hex from character hex.
E2TY70 24.024 New E2TY70 member for tailoring PDB.TYPE70 dataset.
E2TY70PR 24.024 New E2TY70PR member for tailoring PDB.TYPE70PR.
E2dddddd 24.024 New E2dddddd members for "2 Phase" tailoring.
EXPDB30V 24.158 Doc: how to drop variables from PDB.SMFINTRV.
FORMATS 24.163 Support for z9EC on 32-bit; no change for 64-bit.
IMAC6ESS 24.127 Support for GEPARMKY='4D'x and '4A'x
IMAC6ESS 24.227 Optional ESS GPARMKEY='4A'x caused INPUT error.
IMACEXD 24.221 Support for SAR/EXD SMF type 6 optional data.
IMACICE2 24.033 Documentation of different EZA01 fields in CICS
IMACICO2 24.297 Support for CMODHEAD=OMEGAMON segment.
IMACICO2 24.297 Support for new CMODHEAD='OMEGAMON' CICS segment.
JCLMNTHW 24.039 Example creates MONTH PDB from last six WEEK PDBs.
MONTHBLD 24.022 ASUMDB2B BY list did not match weekly BY list.
MXGSASVn 24.246 REGION=0M added to MXG JCL procedure examples.
Many 24.193 Support for 3592 Tapes, no change, they're 3590s.
READDB2 24.006 APPARENT MACRO MAC102S error with ANALDB2R/READDB2.
RMFINTRV 24.079 New NOTYPE74= option will skip TYPE74 processing.
TYPE102 24.001 INPUT EXCEEDED SMF 102 truncated SQL text fields.
TYPE102 24.001 Support for truncated SQL Text in DB2 Audit Trace.
TYPE102 24.027 SQL Text missing in AUDIT trace 140-145 IFCIDs.
TYPE102 24.121 Support for IFCID=350, replaces IFCID=63, long SQL.
TYPE102 24.256 IFCID 226 and 227 new variables added.
TYPE110 24.166 Support for BMC Mainview/CICS optional DB2 and CMR.
TYPE110 24.222 Stat vars DSGEJST,DSGSRBT now kept in CICDS.
TYPE110J 24.104 BMC CMRDETL converted to SMF 110 DOS Journal Format.
TYPE112 24.294 Support for SMF ID=112 "ONDV" CICS record.
TYPE112 24.294 Support for SMF ID=112 CICS ONDV record.
TYPE116 24.293 Support for NETSNAME/UOWTIME from QWHCNID in SMF 116.
TYPE119 24.215 Vars TSICDUTM thru TSICOUAR were incorrect in MXG.
TYPE1415 24.094 Support for PDSE Caching statistics APAR OA12857
TYPE1415 24.170 MXG 24.06 only. NO MATCHING IF error.
TYPE1415 24.196 TYPE1415 INPUT EXCEEDED with z/OS 1.7/1.8 PDSE data.
TYPE1415 24.295 Support for APAR OA17569 Tape Encryption new fields
TYPE1415 24.295 Support for APAR OA17569, Encrypted Tape Keys/Mech.
TYPE16 24.013 Support for New Memory Object Data in DFSORT.
TYPE16 24.071 DFSORT MEMOBJUS variable corrected.
TYPE23 24.065 TYPE23 STARTIME/SYNCTIME were GMT, now LOCAL zone.
TYPE30 24.005 Support for APAR OA14340, adds 8-byte EXCPTOTL field.
TYPE30 24.009 Variable AVGWKSET/PAGESECS accumed over TCB+IFA.
TYPE30 24.009 Variable CSTORE30 is now always missing.
TYPE30 24.011 Negative/missing values in PDB.TYPE30_6.
TYPE30 24.046 Support for zIIP-ZIP engines.
TYPE30 24.053 Negative CPUUNITS error suppressed if delta is small.
TYPE30 24.198 INTETIME in TYPE30_6 was wrong if GMT offset nonzero.
TYPE70 24.010 Array subscript out of range with 60 LPARs.
TYPE70 24.010 Variable LPARNSW in RMFINTRV/TYPE70 could be zero.
TYPE70 24.142 PCTRDYWT, new SMF70Qnn wrong, new PCTRDQWT created.
TYPE70 24.184 PCTIFBYn/PCTZIBYn are "MVS", new PCTCIBYn is "LPAR".
TYPE70 24.225 LPARs with no current weight has LPARSHAR=0.
TYPE7072 24.032 PCTCPUBY/PCTMVSBY in TYPE70 wrong when IRD active.
TYPE7072 24.043 PCTCPUBY/CPUACTTM missing in non-LPAR'd system.
TYPE7072 24.046 Support for zIIP-ZIP engines.
TYPE7072 24.208 LPAR SHARE variables were wrong with Dedicated CPs.
TYPE7072 24.224 Fall Clock "Set Back" protection for dupe STARTIME.
TYPE72GO 24.125 New ZIP variables were not kept in TYPE72GO.
TYPE74 24.228 Support for HyperPAV APAR OA12865.
TYPE78 24.223 Virtual Storage Above the Bar Shared not Input.
TYPE78 24.228 Support for HyperPAV APAR OA12865.
TYPE80 24.018 RACF Reloate 301 section INPUT STATEMENT EXCEEDED.
TYPE80A 24.097 INPUT EXCEEDED if more than six RACFTYPE=42 segments.
TYPE80A 24.098 Support for RACF DCE segment from RACFTYPE 301 seg.
TYPE80A 24.152 Protection for $VARYINGnn. mm input with nn GT mm.
TYPE82 24.200 Support for SMF 82 subtype 22, correction to st 21.
TYPE89 24.063 TYPE89/TYPE892 MACHTIME calculation revised.
TYPE99 24.210 Support for SMF 99 Resource Group, TYPE99RG dataset.
TYPEBETA 24.257 Support for Beta 93 Version 3.6.1
TYPEBVIR 24.305 Support for IBM BVIR History for TS7700 VTS System.
TYPECMHM 24.153 Support for EMC's Centera Mainframe HSM Migrator SMF.
TYPEDB2 24.028 Support for APAR PK15468, adds QWSnPSRB.
TYPEDB2 24.044 BEGTIME missing in DB2STATB dataset.
TYPEDB2 24.046 Support for zIIP-ZIP engines.
TYPEDB2 24.051 QISEDBW, QISEDSC, QISESTMT corrected, other QISEs.
TYPEDB2 24.088 Vars QJSTCIWR QJSTLOGW QJSTLSUS QJSTSERW/THRW wrong.
TYPEDB2 24.136 Support for DB2 V8 UIFCIDS=YES ASCII test.
TYPEDB2 24.141 QLESxxxx DB2 statistics variables corrected.
TYPEDB2 24.177 INPUT EXCEDED ID=100 SUBTYPE=0 more than 1 QLST.
TYPEDB2 24.194 DB2STATS variables CPUTM, QWSnXXXX corrected.
TYPEEDGR 24.299 Support for z/OS (COMPATIBLE) changes to RMM data.
TYPEHURN 24.150 HURN49 variables HU49BJOB,HU49BSET not kept.
TYPEIPAC 24.259 Mobius Subtype 8 INPUT STATEMENT EXCEEDED.
TYPEMPLX 24.204 Support for IMPLEX Version 4.10 (INCOMPATIBLE).
TYPEMVCI 24.264 Support for CMRDETL for Mainview for CICS V 5.9.00.
TYPEMWNT 24.191 Support for HP MeasureWare for Windows/NT.
TYPENDM 24.144 Support for NDM/Connect-Direct Release 4.3/4.5.
TYPENDM 24.160 Corrections (again, final?) for NDMCPUTM/NDMCPU.
TYPENMON 24.296 Support for NMON (free from IBM) AIX/Linux Monitor.
TYPENSPY 24.212 Support for NetSpy Version 11 was added Aug, 2005.
TYPENTSM 24.162 Support for NTSMF 3.0.0, also 35 new objects.
TYPENTSM 24.206 Support for NTSMF Version 3.0.0.7.
TYPENTSM 24.218 Support for NTSM Beta Version 3.0.0.8 (COMPATIBLE).
TYPENTSM 24.220 NTSMF Object 'DATABASE ==> INSTANCES" new DATABASI.
TYPEORAC 24.130 Oracle support is no longer subsystem dependent.
TYPEPROS 24.258 Product section character variables were wrong.
TYPEPRPR 24.145 Support for Oce's Prisma Print '9901' USER record.
TYPEQACS 24.161 Support for i/Series QACS AS/400 Release 5.4.0.
TYPERACF 24.178 Support for IRRHFSU (Unix z/OS file permissions).
TYPERMFV 24.042 Support for CPC RMF III report data.
TYPERMFV 24.046 Support for ZIIP-ZIP engines.
TYPERMFV 24.090 RMF III RESOURCE TYPE MISMATCH corrected for UWDG3.
TYPERMFV 24.181 Support for RMF III OPGG3, SPGG3, zips in CPUG3.
TYPERMFV 24.302 Support for additional zIIP data in RMF III ZRBENC.
TYPESFTA 24.304 Support for Tivoli License Compliance Manager 4.2
TYPESYNC 24.025 8-byte variables replaced 4-byte variables.
TYPESYSI 24.240 All times were 1000 times too large.
TYPETHAL 24.201 Support for E-Thales Security five user SMF records.
TYPETIAO 24.045 Support for APAR UK12301 (Tivoli Alloc Optimizer)
TYPETMS5 24.418 DATECLN was not converted to yyyyddd format.
TYPETNG 24.188 Support for new TNG object (NT and Solaris).
TYPETPMX 24.199 Support for ThruPut Manager Version 6 new variables.
TYPEVMXA 24.003 Toleration Support for z/VM 5.2 (INCOMPATIBLE).
TYPEVMXA 24.078 All z/VM MONWRITE datasets have variable SYSTEM.
TYPEXAM 24.035 XAM SYS error INPUT STATEMENT EXCEEDED due to FFFFx.
TYPEXAM 24.068 SHORT SEGMENT MXG error corrected for SYTCPC/STOSHR.
TYPEXAM 24.072 INVALID DATA FOR SYTNLPMG/SYTACTM with XAMSYS.
TYPEXAM 24.135 MTRSYS variables were wrong after SYSTMID.
UTILEXCL 24.131 Candle short CICS dictionary record supported.
UTILEXCL 24.140 Support for ARZGEOS/FACHG, ARGZD/GSACCT optionals.
UTILEXCL 24.254 Support for all Omegamon/Candle optional CICS data
VMAC110 24.185 Support for DMF Product's SMF 110 (CICS 4.1!) data.
VMACNDM 24.182 NDMCPUTM and NDMCPU now validated and correct.
VMACSMF 24.202 &SMFEXIT macro variable added to INFILE &SMF.
VMXG70PR 24.105 Corrections, revisions, ASUM70PR, ZIP and IFAs.
VMXG70PR 24.124 Variables SHIFT, ZDATE, ZTIME in ASUM70LP fixed.
VMXGDUR 24.105 New MXGDURTM variable is created.
VMXGINIT 24.023 MXG Default TAPENGN is now V9SEQ.
VMXGINIT 24.242 Revisions for SAS V9 BI SAS/ITRM anticipated changes.
WEEKBLxx 24.058 SORT order of PDB.ASUMTAPE was inconsistent.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 24.
====== Changes thru 24.306 were in MXG 24.24 dated Feb 5, 2007=========
Change 24.306 Support for IMS Version 10 (INCOMPAT) IMS log records,
VMACIMS which has these new data inserted in the 07 and 07 log
Feb 5, 2007 log records:
Dataset IMS07
DLRABRSN='ABEND*REASON*CODE'
DLRCPUID='CPU ID*PLACE*HOLDER'
DLRESAF ='ESAF*CALLS'
DLRFLD ='FASTPATH*FLD*CALLS'
DLRNWID ='NETWORK*IDETIFIER*OF LAST*MESSAGE'
DLROSAMR='OSAM*IO*READS'
DLROSAMW='OSAM*IO*WRITES'
DLRPOS ='FASTPATHP*POS*CALLS'
DLRRLSE ='RLSE*CALLS'
DLRTOTIO='TOTAL*DL/I*OSAM+VSAM*CALLS'
DLRVSAMR='VSAM*IO*READS'
DLRVSAMW='VSAM*IO*WRITES'
DLRXCOPY='COPY*CALLS*(XQUERY)'
DLRXRSTR='RSTR*CALLS*(XQUERY)'
DLRXSAVE='SAVE*CALLS*(XQUERY)'
Dataset IMS08
LINTCLAS='TRAN*CLASS'
LINTSY2 ='TRANCODE OR DBNAME'
LINTPGM ='PROGRAM*NAME'
LINTPSB ='PSB*NAME'
LINTFLG1='FLAG*1'
This change had not been tested with actual V10 records,
and there is a new 09 statistics record that will be
supported in the future, but this change protects the
TYPEIMS7 member that used VMACIMS.
Users of the ASMIMSLx/JCLIMSLx architecture will hav to
reassemble with the IMS 10 Macro Library.
Change 24.305 Support for IBM's BVIR History for TS7700 VTS System.
EXBVIR01 DDDDDD MXG MXG
EXBVIR02 DATASET DATASET DATASET
EXBVIR10 SUFFIX NAME LABEL
EXBVIR11
EXBVIR20 BVIR01 BVIR01 BVIR01: VNODE VIRTUAL DEVICE PIT
EXBVIR21 BVIR02 BVIR01 BVIR02: VNODE ADAPTER POINT IN TI
EXBVIR30 BVIR20 BVIR20 BVIR20: VNODE VIRTUAL DEVICE HIST
EXBVIR31 BVIR21 BVIR21 BVIR21: VNODE ADAPTER HISTORY
EXBVIR32 BVIR10 BVIR10 BVIR10: HNODE HSM POINT IN TIME
EXBVIR33 BVIR11 BVIR11 BVIR11: HNODE GRID POINT IN TIME
IMACBVIR BVIR30 BVIR30 BVIR30: HNODE HSM HISTORY
TYPEBVIR BVIR31 BVIR31 BVIR31: HNODE RESERVED
TYPSBVIR BVIR32 BVIR32 BVIR32: HNODE LIBRARY HISTORY
VMACBVIR BVIR33 BVIR33 BVIR33: HNODE GRID HISTORY
VMXGINIT IBM creates the data file as RECFM=U, without BDW or RDW,
Feb 4, 2007 so processing this data on ASCII may require the data to
be converted to VB, before download, using SAS on z/OS:
DATA _NULL_;
INFILE BVIRDATA RECFM=U BLKSIZE=32760;
FILE BVIRHIST RECFM=VB LRECL=32756 BLKSIZE=32760;
INPUT ; PUT _INFILE_; RUN;
Change 24.304 Support for IBM's TLCM 4.2 (formerly ISOGON's SoftAudit)
VMACSFTA which is now Tivoli License Compliance Manager for z/OS,
Feb 3, 2007 eliminates old tests for record length, which caused zero
observations to be created in SOFTMODS dataset, and adds
new variables:
Dataset SOFTPROD - Installed Products:
XPUPDEPR='DELETED*PRODUCT*INDICATOR'
XPUPFEAT='IBM*FEATURE*NUMBER'
XPUPPEEF='PRODUCT*ENABLEMENT*ELIGIBILITY*FLAG'
XPUPPRRL='PRODUCT*RELEASE'
Dataset SOFTMODS - Installed Load Modules:
XPMDELLI='DELETED*LIBRARY*INDICATOR'
XPMDELLM='DELETED*LOAD*MODULE*INDICATOR'
XPMDELPR='DELETED*PRODUCT*INDICATOR'
XPMPTHLN='LENGTH*OF FULL*PATHNAME*FOLLOWING'
XPMRECFM='RECORD*FORMAT*CODE'
XPMPTHNM='FULL*PATHNAME'
Dataset SOFTAUDM - Load Module Usage
XPUDELLM='DELETE*MODULE*INDICATOR'
XPUDELPR='DELETE*PRODUCT*INDICATOR'
XPUMLDEL='LIBRARY*DELETED?'
Dataset SOFTAUDP - Product Usage
XPUDELPR='DELETED*PRODUCT*INDICATOR'
***ERROR.IMACACCT.ACCOUNT FIELD 1 LENGTH WRONG
messages were due to records with the accounting
field containing "* NOT AVAILABLE" instead of normal
job accounting information (which always starts with
a length field; these data do not). Now, MXG looks
for this text and avoids calling IMACACCT to eliminate
the essentially spurious message.
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND.
Change 24.303 -Where Clauses were added to PROC PLOTS to circumvent an
ANALRMFI error when variables are missing in ANALRMFI,ANALDALY.
ANALDALY -The CPU Report had extra PHYSICAL lines printed if there
ANALRMFR were ICF processors.
Feb 4, 2007
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 24.302 -RMF III dataset ZRBDVT is enhanced with new calculated
VMACRMFV variables that have been found to be useful in reporting;
Feb 3, 2007 their names, labels, and formats match their RMF I TYPE74
counterparts and are in the same units:
AVGCMRMS='AVERAGE*COMMAND*RESPONSE*MSEC PER SSCH'
AVGCONMS='AVERAGE*I/O CONNECT*MSEC PER SSCH '
AVGDISMS='AVERAGE*I/O DISCONNECT*MSEC PER SSCH'
AVGIOQMS='AVERAGE*IOS QUEUE*MSEC PER SSCH'
AVGPNCUB='AVG (MS)*PEND DUE TO*CU BUSY'
AVGPNDEV='AVG (MS)*PEND DUE TO*DEVICE BUSY'
AVGPNDMS='AVERAGE*I/O PENDING*MSEC PER SSCH'
AVGPNSWP='AVG (MS)*PEND DUE TO*SWITCH PORT BUSY'
DURATM ='DURATION*OF*INTERVAL'
-The ZRBENC dataset supports these new zIIP fields that
were added by APAR OA13499:
ENCDECP ='DELAY*COUNT*CP'
ENCDESUP='DELAY*COUNT*ZIIP'
ENCDMSUP='DELAY*COUNT*ZIIP*(MULTI)'
ENCSUCT ='ZIIP*ON*CP*TIME'
ENCSUPT ='ZIIP*TIME'
ENCTSUCT='ZIIP*TIME ON*CP*SINCE*CREATION'
ENCTSUPT='ZIIP*TIME*SINCE*ENCLAVE*CREATION'
ENCUMSUC='USING*COUNT*ZIIP*ON CP*(MULTI)'
ENCUMSUP='USING*COUNT*ZIIP*(MULTI)'
ENCUSCP ='USING*COUNT*CP'
ENCUSSUC='USING*COUNT*ZIIP*ON CP'
ENCUSSUP='USING*COUNT*ZIIP'
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.301 -Yet another "SPLIT70" correction; actual split records
VMAC7072 had incorrect NRPHYCPS values in PDB.TYPE70PR because the
Feb 2, 2007 PHYSICAL segments came in the second, not first, record.
An extra SORT and MEANS were required to correct these
values in TYPE70PR dataset.
-Variable PARTNCPU was incorrect as it could sometimes
still include counts for non-CP engines.
-This change also corrected CPU count variables in the
ASUM70PR output datasets (ASUM70PR/70LP/CEC/ASUMCELP).
-TYPE70PR observations with LPARCPUX=0, an offline LPAR,
had values in SMF70WST/LAC/MSU/NSW/PMA that were carried
forward because they were not reset. Now, the variables
are set to missing values.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Thanks to Martin Brauer, T-Systems, GERMANY.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
====== Changes thru 24.300 were in MXG 24.11 dated Feb 1, 2007=========
Change 24.300 Using the MXG "TAPETEMP" techinque to build PDBs on tape
WEEKBLDT without rewind/backspace has worked for years without any
WEEKBLDD glitches, but that's because no one had tried to stack
WEEKBL3D multiple "WEEK" PDBs in a separate LABEL=(SL,2) tape DSN.
WEEKBL3T That caused ABEND A13-10 when the Second Tape Label was
MONTHWEK opened. The circumvention required these code changes:
MONTHBLS - The MOD in the FILE WEEK MOD .. and FILE MONTH MOD..
MONTHBLD were replaced with new local macro variable &MXGMOD.
MONTHBL3 - A %LET MXGMOD=; is inserted BEFORE the first invoke
Feb 4, 2007 of either _WEEKBLD or _MNTHBLD, and
- After the FIRST invocation of _WEEKBLD or _MNTHBLD,
a %LET MXGMOD=MOD; is inserted.
The setting of MOD only after the first dataset has been
created has circumvented what appears to be a failure by
SAS to close the dataset; this logic eliminates the ABEND
when you stack multiple PDB libraries in separate tape
data sets on a single tape volume.
-An alternative circumvention was to create a dataset on
the output tape before the first invocation of the build,
and then to CLEAR the LIBNAME, as shown below, but the
MOD technique is more elegant and more robust.
DATA WEEK.MXGDUMMY; RUN;
LIBNAME WEEK CLEAR;
Thanks to Robbie A. McCoy, Salt River Project, USA.
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to Rich Anderson, SAS Institute Cary, USA.
Change 24.299 Support for z/OS 1.8 changed (COMPATIBLE) to RMM Extract
VMACEDGR data:
Jan 31, 2007 Dataset EDGGOEXT - New variable
ROOWNEML='OWNER*EMAIL*ADDRESS'
Dataset EDGGVEXT - New variables
RVCAPACI='VOLUME CAPACITY IN MBYTES'
RVDCRSID='FIRST FILE CREATION SYSTEM ID'
RVDESTBI='DESTINATION BIN NUMBER'
RVDESTBN='DESTINATION BIN MEDIA NAME'
RVDSNNO ='NUMBER OF DATASETS ON VOLUME'
RVEXPTOK='UNIQUE VALUE AT START'
RVLABNO1='LABEL NO OF FIRST FILE'
RVPERCEN='VOLUME PERCENTAGE FULL'
*RVPRERR ='PERMANENT READ ERRORS'
*RVPWERR ='PERMANENT WRITE ERRORS'
RVRBYSET='VOLUME RETAINED BY SET?'
RVSTACKE='COUNT OF VOLUMES STACKED'
RVSTACKV='STACKED VOLUME ENABLED?'
*RVTRERR ='TEMPORARY READ ERRORS'
*RVTWERR ='TEMPORARY WRITE ERRORS'
RVVENDOR='VENDOR INFORMATION'
RVVOL1 ='VOL1 LABEL VOLSER'
RVVWMC ='WRITE MOUNT COUNT'
RVWWID ='UNIQUE WORLD WIDE IDENTIFIER'
The four *ERRORS fields did previously exist in 4-bytes;
they are now 5-bytes, but since they were originally kept
as characters, they remain character variables; you can
easily convert to a number with NR=INPUT(XXXXERR,5.);
-Feb 2: Type H added flag to identify the Date Format
(JULIAN, EUROPEAN, AMERICAN), and the GMT Offset.
When present, the GMTOFF is used to change the XXXXDATE
and XXXXTIME variables to their local values.
Thanks to Reinhard Nitsche, GAVI, GERMANY.
Change 24.298 The BLDSMPDB utility new option BUILDPDB=COPYONLY can be
BLDSMPDB used to copy/manage the daily/weekly/wtd PDB libraries
Jan 31, 2007 for non-SMF data. For example you could build a PDB with
TMS and DCOLLECT data and manage it with COPYONLY:
%INCLUDE SOURCLIB(TYPSDCOL);
%INCLUDE SOURCLIB(TYPSTMS5);
%BLDSMPDB(BUILDPDB=COPYONLY);
In addition, new option ERASEPDB=NO prevents the deletion
of all of the pre-existing datasets in the PDB library,
so you could process TMC, DCOLLECT, and SMF data into the
day-of-week datasets using
%INCLUDE SOURCLIB(TYPSDCOL);
%INCLUDE SOURCLIB(TYPSTMS5);
%BLDSMPDB(BUILDPDB=buildpdb,erasepdb=no);
====== Changes thru 24.297 were in MXG 24.10 dated Jan 30, 2007=========
Change 24.297 Support for optional CMODHEAD='OMEGAMON' CICS segment,
IMACICO2 adds duration/counts for ADABAS, IDMS, SUPRA, DATACOM and
UTILEXCL a user defined vent. The duration fields are in the new
VMAC110 CICS/TS 3.2 format, with 8 bytes for duration.
Jan 30, 2007
Change 24.296 Support for NMON for AIX/Linux, "Nigel's Monitor", a free
EXNMONIN monitor from IBM. That product's home page is located at
IMACNMON http://www-941.haw.ibm.com/collaboration/wiki/display/
TYPENMON wikiptype/nmon
TYPSNMON This is the first iteration, and some of the static info
VMACNMON (count of disks, disk names, directory names, etc) was
VMXGINIT hand coded for this site's choices, and the startup data
Jan 30, 2007 is not decoded yet, so this support will evolve, There
is a massive amount of documentation about data values
at the NMON web site, so this looks to be a very good
data source for AIX and Linux.
Dataset NMONINTV contains interval observations with all
of the interval metrics that were in the test file.
Thanks to Steve Ko, Honda Canada, CANADA.
Change 24.295 Support for APAR OA17569, new SMF 14/15 subtype=7 adds
VMAC1415 four variables that describe the Key Labels and Encoding
Jan 29, 2007 Mechanism for Encrypted Tape Data Sets.
SMF14CD1='ENCODING*MECHANISM*KEY 1'
SMF14CD2='ENCODING*MECHANISM*KEY 2'
SMF14KL1='KEY*LABEL*1'
SMF14KL2='KEY*LABEL*2'
Change 24.294 Support for SMF ID=112 record, the "ONDV" data that was
VMAC112 in the Omegamon User SMF record supported in TYPEOMCI.
Jan 29, 2007 This new record is completely restructured, with changed
clocks and counters, but the same twelve datasets are
created with most of the same variable names unchanged:
DDDDDD MXG MXG
DATASET DATASET DATASET
SUFFIX NAME LABEL
OMCADA OMCIADA OMEGAMON CICS ADABAS DETAIL
OMCADT OMCIADAT OMEGAMON CICS ADABAS TOTALS
OMCDLI OMCIDLI OMEGAMON CICS DL/I DETAIL
OMCDLT OMCIDLIT OMEGAMON CICS DL/I TOTALS
OMCDTC OMCIDTCO OMEGAMON CICS DATACOM DETAIL
OMCDTT OMCIDTCT OMEGAMON CICS DATACOM TOTALS
omcidm OMCIIDMS OMEGAMON CICS IDMS DETAIL
omcidt OMCIIDMT OMEGAMON CICS IDMS TOTALS
OMCSUP OMCISUPR OMEGAMON CICS SUPRA DETAIL
OMCSUT OMCISUPT OMEGAMON CICS SUPRA TOTALS
OMCVSA OMCIVSAM OMEGAMON CICS VSAM FILE DETAIL
OMCVST OMCIVSAT OMEGAMON CICS VSAM TOTALS
====== Changes thru 24.293 were in MXG 24.10 dated Jan 28, 2007=========
Change 24.293 IBM note "Correlating MQSeries Accounting Data to CICS"
VMAC116 from 2004 documents that while QWHCTOKN is not populated
Jan 28, 2007 in SMF 116 records, MQSeries V5.R2 added QWHCNID which is
populated with the NETSNAME/UOWID/UOWTIME data that MXG
normally extracts from QWHCTOKN in CICS records. Now, MXG
creates NETSNAME, UOWID, and UOWIDCHR from QWHCNID when
it is populated.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 24.292 Support for IBM WebSphere MQ V6.0 Open Systems Accounting
EXWMQCHS and Statistics is preliminary; this iteration reads the
EXWMQMQA output file created by IBM's "amqsmon" program, but the
EXWMQMQS support will be changed to read the raw messages from the
EXWMQQUA open systems accounting and statistics queues. These
EXWMQQUS five data sets are created from either input:
IMACWMQA dddddd Dataset Description
TYPEWMQA WMQMQA MQIACTNG MQI ACCOUNTING
TYPSWMQA WMQQUA QUEACTNG QUEUE ACCOUNTING
VMACWMQA WMQMQS MQISTATS MQI STATISTICS
VMXGINIT WMQQUS QUESTATS QUEUE STATISTICS
Jan 26, 2007 WMQCHS CHNSTATS CHANNEL STATISTICS
Thanks to Milt Weinberger, Metropolitan Life, USA
Change 24.291 DB2 SMF 102 IFCID 22 dataset T102S022 variables were bad
VMAC102 after QW0022VN which was read with $VARYING64. QW0022VL;
Jan 25, 2007 IBM writes all 64 bytes, not just the expected QW0022VL
length-of-field bytes, so MXG was always misaligned, as
QW0022VN is always 26 characters. Now 64-22VN is SKIPed.
This was accidentally discovered in SMF data sent for an
unrelated question, so I suspect few have used T102S022.
Thanks to Rachel Holt, Fidelity, USA.
Change 24.290 APAR OA19257 caused invalid and large CPURCTTM values in
VMXGRMFI both RMF 72 and SMF 30, APAR OA19282 was a partial fix,
VMAC7072 but APAR OA19852 (Feb 7) fixes the error.
VMAC7072 The original error causes, among other things, ERROR:
VMAC30 NEGATIVE UNCAPTURED-CPU-TIME message when RMFINTRV
Jan 26, 2007 processes these data. But the error didn't print the
Feb 7, 2007 five components of the CPU72TM, and the message text
referenced ancient APARs. The revised message text gives
clearer instructions and prints the CPU components. If
you find these error conditions, prior to installing the
PTFs for the above APARs, you can:
a. Correct your PDB library data without rereading SMF
with these DATA steps:
DATA PDB.TYPE72GO; SET PDB.TYPE72GO;
CPUTM=CPUTM-CPURCTTM;
DATA PDB.STEPS; SET PDB.STEPS;
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
DATA PDB.JOBS; SET PDB.JOBS;
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
DATA PDB.SMFINTRV; SET PDB.SMFINTRV;
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
or
b. Correct when your MXG program reads SMF 30 or 70 data
records (whether by BUILDPDB, TYPS30, TYPS7072, etc):
Insert the below statements before the OUTPUT in the
MXG Exit Members (you copy the EXdddddd from the MXG
Source into your "USERID.SOURCLIB(EXdddddd)":
In member EXTY72GO:
CPUTM=CPUTM-CPURCTTM;
In members EXTY30U4, EXTY30U5, EXTY30U6, IMACINTV:
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
Thanks to Pat Curren, Supervalu, USA.
Change 24.289 FTP Client Security fields are now added to TYP11903:
FORMATS FCCIPHER='CIPHER*SPECIFICATION'
VMAC119 FCCPROTE='CONTROL*CONNECTION*PROTECTION*LEVEL'
Jan 25, 2007 FCDPROTE='DATA*CONNECTION*PROTECTION*LEVEL'
FCLOGINM='LOGIN*METHOD'
FCMECHAN=*PROTECTION*MECHANISM'
FCPROTBU='NEGOTIATED*PROTECTION*BUFFER*SIZE'
FCPROTOL='PROTOCOL*LEVEL'
FTP Server Security fields were added by Change 23.146.
Thanks to Debbie Shugerts, Verizon, USA.
Change 24.288 -Corrections to the sample VTS analyis report. The PUT
ANAL94 format for seven variables is $5 in place of 5 as they
VMAC94 are character variables. TOTPHYMT includes suffix 2s.
Jan 24, 2007 -SMF94VCA is zero after F/C 4001, so it is recalculated
Jan 31, 2007 as SMF94VCA=SUM(OF S94VCA41-S94VCA48)/8; when VCA=0.
Feb 2, 2007 -Feb 2: $5 changed to $13 to display full DEV name.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 24.287 Variable MQTOTTM in CICSTRAN from CANMQ segment was wrong
IMACICOM because it was missing the multiply-by-16 to convert the
Jan 25, 2007 inputted PIB4.6 value to the correct time units.
The missing MQTOTTM=16*MQTOTTM; statement was added; your
existing CICSTRAN data is valid if you multiply MQTOTTM
by 16.
In the process of finding this MXG error, I realized that
I could detect an error in your CICS tailoring, at least
if you had the optional CANNQ segment, by validating that
its expected length of 76 was in fact found as expecte.
If you have only optional CICS segments, but no EXCLUDEd
fields, and you didn't tailor all of the needed IMACICxx
members for all of your optional segments that exist, and
if you didn't use UTILEXCL to create an IMACEXCL for your
optional CICS segments, then you could have no errors on
the log (because MXG can only detect EXCLUDEd fields),
but your CANMQ data (in this case) would be trashed as it
was read from the wrong part of the SMF 110 record.
At least for the CANMQ segment, the length of the segment
is contained in the record, so the IMACICOM member that
you tailor (by removing the comment block) will detect if
it doesn't find the correct length of 76 at the start.
Unfortunately, I had to not-ERROR on zero length, as
all of the records from an APPLID will have the 76 byte
segment, but if the transaction was not involved in MQ,
those bytes are all hex zeroes.
Although UTILEXCL has always been required for EXCLUDEd
fields, it really is required, to be completely safe,
even if you ONLY have optional CICS segments, with no
excluded fields. If you just manually update all of the
IMACICxx members for all of your SEGMENTS, but do not
have a UTILEXCL-created IMACEXCL in effect, then the
optioal segments are input in the default static order in
the IMACICDA member, which applies to ALL of your
records, so you could have data out of order, if all
regions don't have the same group of optional segments.
By using UTILEXCL, its IMACEXCL only calls the right
segment for each record, and MXG cannot get out of
alignment.
In any case, this change will detect an out of order
condition, and let you know you need to run UTILEXCL.
P.S. Perry's tailoring was correct; in examining the
CANMQ data, which appears to be incorrect, I
realized the exposure and made this change.
Thanks to Perry Lim, Union Bank of California, USA.
Change 24.286 Support for Tandem H06 release added variables compatibly
VMACTAND to the TANDPROC, provided you still create the "old" data
Jan 24, 2007 record format.
Thanks to Harriet Sollod, Wells Fargo Bank, USA.
Change 24.285 Comments in JCLWEEK were correct that that example is for
JCLWEEK building a weekly PDB on DISK, with daily PDBs on DISK,
Jan 23, 2007 but the //WEEK DD erroneously had UNIT=TAPE. JCL Example
is corrected.
Thanks to Lisa L. Lawyer, Lands End, USA.
Change 24.284 My attempt to add REGION=0 to the // PROC JCL statement
MXGSASV9 in Change 24.246 was wrong, generating JCL errors that
MXGSASV8 EXEC STATEMENT KEYWORDS ARE RESERVED AND CANNOT BE USED.
Jan 23, 2007 That REGION=0M belongs on the // EXEC PGM= JCL statement
inside the JCL Procedure, and not on the PROC definition.
Thanks to MP Welch, SPRINT, USA.
Change 24.283 Support for TPF thru PUT19 adds two new datasets
VMXGINIT dddddd dataset description
EXTPFKC TPFKC
EXTPFSB TPFSB
VMACTPF and additions to existing datasets:
VMXGTPFI - TCPIP Message counters (SXTCPIN) added to SS/SR/ST
Jan 23, 2007 - Multiple Systems with Same CPUID supported
- Label and KEEP for PUT12 implementation corrected
- Update to FF processing for PUT19 (IBM vanilla)
- Update SPX PUT15 Dispensed & Returned Counters
and new fields added in PUT15.
- Added SPXSS for "PS" processing, due to multiple
datasets (SPXSS) on FCA.
Thanks to Bob Wilcox, EDS, USA.
====== Changes thru 24.282 were in MXG 24.10 dated Jan 22, 2007=========
Change 24.282 A new report, "DB2 Storage Analysis" uses IFCID 225 and
ANALS225 the DB2STATS dataset to report on storage used by each
Jan 22, 2007 DB2 subsystem, above and below the line and above the
bar. The report creates an HTML report; the destination
must be a PDSE with LRECL=8000, LKSIZE=8004, and required
MXG 24.08 or later for the enhanced T102S225
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.281 -Support for BMC Mainview for MQ Series V4.2 VSAM History
ASMMNVW file; record changes caused MXG to not output any obs
EXBBMQAS with the new BMC version. Many new variables are now
EXBBMQCF created by this change.
EXBBMQDB -BMC's BBMQVSAM record are compressed, and member ASMMNVW
EXBBMQQU has the "MNVW" Infile Exit that you install to read BMC
IMACBBMQ compressed data, but I did not test for compressed data;
VMACBBMQ now, if you try to read compressed records without having
VMXGINIT the MNVW exit installed, you'll get an MXG message that
Jan 24, 2007 tells you what to do.
-Support for 'E6'x QUEUE STATISTICS RECORD creates new
BBMQQUES dataset with 187 variables.
-Support for 'E7'x DB2 MANAGER RECORD creates new
BBMQDB2M dataset with 445 variables.
-Support for 'E8'x COUPLING FACILITY RECORD creates new
BBMQCFAC dataset with 81 variables.
-Support for 'E9'x APPLICATION STATISTICS RECORD creates
new BBMQAPPL dataset with 200 variables.
-Jan 27: corrected variables with 9-byte names.
Thanks to Stuart Wildey, Morgan Stanley, USA.
Thanks to Patrick E. Fortune, Morgan Stanley, USA.
Thanks to Jeff Sorokin, Morgan Stanley, USA.
Change 24.280 An undocumented change in MXG 24.02 corrected variable
VMACICE name VDEVNAME to VDEVFDID in dataset ICEBRGUT, and also
Jan 22, 2007 revised the text in several variable's labels.
This is an INCOMPATIBLE change, if your reports use the
old variable name. My apologies: first, for spelling it
wrong, and second for not documenting it last year!
Thanks to Yves Terweduwe, CIPAL, BELGIUM
====== Changes thru 24.279 were in MXG 24.10 dated Jan 21, 2007=========
Change 24.279 -Support for SAMS Vantage (INCOMPATIBLE) changes in their
EXSAM099 Version 6.x. The new "POOLVOLS" segment appears to have
EXSAM100 exactly the same data as the old "LSPACEPO" segment, so
EXSAM101 they are OUTPUT in the same SAMSLSPC dataset.
EXSAM102 -Support for new SAMS DTOC and eight OBJ02nnn subtypes:
EXSAM103 SAMSDT SAMSDTOC SAMS DTOC RECORD DTOC
EXSAM119 SAM099 SAMO2099 SAMS 2099 EMC SYSTEMS OBJ2099
EXSAM120 SAM100 SAMO2100 SAMS 2100 EMC CHANNEL DIRECTOR OBJ2100
EXSAM121 SAM101 SAMO2101 SAMS 2101 EMC DISK DIRECTORS OBJ2101
EXSAM122 SAM102 SAMO2102 SAMS 2102 EMC PHYSICAL DEVICES OBJ2102
EXSAM129 SAM103 SAMO2103 SAMS 2103 EMC LOGICAL VOLUMES OBJ2103
EXSAM150 SAM119 SAMO2119 SAMS 2119 IBM ESS SUBSYSTEM OBJ2225
EXSAM225 SAM120 SAMO2120 SAMS 2120 IBM ESS SSIDS OBJ2225
EXSAM227 SAM121 SAMO2121 SAMS 2121 IBM ESS LOGICAL PATHS OBJ2225
EXSAM230 SAM122 SAMO2122 SAMS 2122 IBM ESS VOLUMES OBJ2227
IMACSAMS SAM129 SAMO2129 SAMS 2129 IBM ESS RAID RANKS OBJ2227
VMACSAMS SAM150 SAMO2150 SAMS 2150 IBM ESS PPRC INFO OBJ2227
VMXGINIT SAM225 SAMO2225 SAMS 2225 EMC ALL DEVICES OBJ2227
Jan 19, 2007 SAM227 SAMO2227 SAMS 2227 EMC RDF DEVICES OBJ2227
Jan 28, 2007 SAM230 SAMO2230 SAMS 2230 EMC BCV DEVICES OBJ2230
Jan 31, 2007
Thanks to Mark Daly, CitiGroup, USA.
Change 24.278 Further ASUM70PR summarization corrections,redesign:
VMAC7072 -In PDB.ASUM70LP dataset, variables LPCTBY/LPCTOV were
VMXG70PR slightly wrong (13.087 vs 13.705) with IRD because the
Jan 22, 2007 old integer LPARCPUS value was used; now, the actual
Jan 26, 2007 average number of CPs online is calculated in the
Jan 30, 2007 LPnPREC variables from SMF70ONT/DURATM in PDB.ASUM70LP,
and LPARCPUS in PDB.TYPE70PR is unchanged, containing
the maximum number of CPs online during the interval.
It was only those variables in PDB.ASUM70LP that were
slightly wrong; their counterpart variables LPCTnBY and
LPCTnOV in the PDB.ASUM70PR dataset were just fine.
Note that you cannot use SMF70BDA as it includes the
count of CPs plus any IFAs plus ZIPs.
-Variable LPnCHG, (Nr CPUs Changed?) is now always blank.
The variable was always 'Y' for IRD, and always blank if
you didn't summarize in ASUM70PR, and with IRD there's no
need, since LPnNRPRC is the average count that interval
-CURSHARE and SYSSHARE were corrected for Dedicated CPs.
-If all your systems are on the same time zone, GMTOFFTM
is valid in the ASUM70PR-created summary datasets, and
Change 24.xxx's use of GMTOFFTM to protect setting of the
system clock ahead/behind on an active system was fine.
Even if you have systems with different GMTOFFTM values
(i.e., some systems local, some systems GMT), the system-
level PDB.ASUM70PR/PDB.ASUM70LP dataset are fine, but
that change was removed for the PDB.ASUMCEC/PDB.ASUMCELP
CEC-level summary datasets, where it created invalid and
extra observations where there were multiple values of
GMTOFFTM in a CEC. With its removal from the BY list,
those datasets are now valid; however, the actual value
in GMTOFFTM in those two datasets may or may not be the
actual GMTOFFTM of the datetimestamps, and there may not
be a way for MXG to actually know what that true GMTOFF
value is from those two datasets. If this is a problem,
please discuss with support@mxg.com, but it should be a
minor nit for only a small number of sites.
-Jan 30: CURRSHARE corrected for non-IRD managed LPArs.
Thanks to Bill McDonald, KCC, USA, for the original error, and,
for testing several iterations of this significant exposure:
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 24.277 The CICS Shutdown Report ANALCISH was revised to support
ANALCISH variables dropped by MXG (MNGSYSER and MNGSYSEE), and new
Jan 18, 2007 variables MNGRR and MNGRRS were added to the MONITOR
Feb 4, 2007 report. A04VADQK moved from SUM= to MAX= and AO4SKINS
was added to the ID= statement.
-New CICLGG Logstream Global Statistics added.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 24.276 Systems with Dedicated CP engines had variables PCTONLNx
ANALRMFR (Percent Online) always missing in PDB.TYPE70, which then
VMAC7072 caused ANALRMFR CPU Activity Report to have blank values.
Jan 19, 2007 Fortunately, the other variables in PDB.TYPE70 were okay;
this is NOW the final "SPLIT70" correction, and is needed
for z/OS 1.7 and later, if you have Dedicated z/OS CPUs.
-Unrelated, accidentally observed and corrected, the CPU
Number printed by ANALRMFR on the CPU Activity Report was
often incorrect.
Thanks to Bob Keller, Safeway, USA.
Change 24.275 ERROR.MORE THAN 255 STRUCTURES was due to an archaic test
VMAC74 for 255; the arrays had been increased to 1024, but the
Jan 18, 2007 test value and error message text were not revised.
Thanks to Bill McDonald, KCC, USA.
Change 24.274 Utility for ASCII execution to read SMF data via ftp and
ASCISMFC create a local disk file of only selected SMF records.
Jan 17, 2007
Thanks to Bill McDonald, KCC, USA.
Change 24.273 Extraneous '60'x character in column 1 of line 140 caused
WEEKBLDD a syntax error, now removed.
Jan 17, 2007
Thanks to Lisa Lawver, Land's End, USA.
Change 24.272 -Enhancement to ASMRMFV RMF III adds ENC Extension feature
ASMRMFV and ASM symbolics to let users tailor the ASMRMFV default
VMACRMFV parameters were added.
Jan 18, 2007 -Enhancement to VMACRMFV to decode the ENC Extension,
which adds these new variables to the ZRBENC dataset:
ENCCNM ='SERVICE*CLASS*NAME'
ENCCDE ='SERVICE*CLASS*DESCRIPTION'
ENCCWN ='ASSOCIATED*WORKLOAD*NAME'
ENCCRN ='ASSOCIATED*RESOURCE*GROUP'
ENCCPO ='OFFSET TO*SERVICE*CLASS*PERIOD ENTRY'
ENCCPN ='NUMBER OF*SERVICE*CLASS*PERIODS'
ENCCGI ='RESOURCE*GROUP*INDEX*IN ENCRG'
ENCCWI ='WORKLOAD*INDEX*IN ENCWD'
ENCCRC ='PERIODS*WITH*RESPONSE*TIME GOAL'
ENCRNM ='REPORT*CLASS*NAME'
ENCRDE ='REPORT*CLASS*DESCRIPTION'
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.271 -Variables AVGRSPMS, DEVACTTM, and DEVIOQTM are created in
VMACRMFV RMF III dataset ZRBDVT to match IBM response metrics, and
Jan 17, 2007 variable SWPODLTM is now kept.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.270 Variable GDESDP2 was incorrectly input @11 instead of @9,
VMACQACS causing a value of 16,448 for available processors.
Jan 16, 2007
Thanks to Robert Gilbert, Fortis Bank, BELGIUM.
Change 24.269 This is the schematic of zIIP CPU time variables in the
ADOC30 TYPE30xx, JOBS, STEPS datasets. zIIP CPU time is always
Jan 16, 2007 in separate variables that are never included in the old
"CPU" variables that, then and now, contain ONLY the time
spent on "CP Engines".
CPUZIPTM /*SMF30_TIME_ON_ZIIP*/
CPUDZITM /*SMF30_DEP_ENCLAVE_TIME_ON_ZIIP*/
CPUEZITM /*SMF30_IND_ENCLAVE_TIME_ON_ZIIP*/
CPUZIETM /*SMF30_ELIGIBLE*TIME_ZIIP_ON_CP*/
CPUDZETM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_ON_CP*/
CPUEZETM /*SMF30_IND_ENCLAVE_TIME_ZIIP_ON_CP*/
CPUEZQTM /*SMF30_IND_ENCLAVE_TIME_ZIIP_QUAL*/
CPUDZQTM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_QUAL*/
CPU TIME ON ZIIP ENGINES CPU TIME ON CP ENGINES
"Actual" "Eligible"
|--------CPUZIPTM---------| |--------CPUZIETM---------|
|--CPUDZITM--|--CPUEZITM--| |--CPUDZETM--|--CPUEZETM--|
(DEP) (IND) (DEP) (IND)
"Qualified - Dependent Enclave"
(Sum of DEP Actual and Eligible)
|-------CPUDZQTM----------|
|--CPUDZITM--|--CPUDZETM--|
"Qualified - Independent Enclave"
(Sum of IND Actual and Eligible)
|-------CPUEZQTM----------|
|--CPUEZITM--|--CPUEZETM--|
See also MXG Technical Note 31 in Newsletter FORTY-NINE,
"zIIP CPU Time Comparisons between TYPE72GO and TYPE30_V".
Thanks to Bob Keller, Safeway, USA.
Change 24.268 Variables SMF70GIE and STARTIME were not kept as 8-bytes
VMXG70PR in ASUMCEC and ASUM70LP datasets; now, using the new
Jan 15, 2007 MINLONG= argument added to VMXGSUM, they are.
Change 24.267 New MINLONG= and MAXLONG= arguments are added to create
VMXGSUM min/max output that are 8-bytes long, like the existing
Jan 15, 2007 SUMLONG= argument.
Change 24.266 If you change macro _IMSWORK in IMACIMS, TYPEIMS7 failed,
TYPEIMS7 dataset IMS07 NOT FOUND, because _IMSWORK was not used in
Jan 14, 2007 TYPEIMS7. Now, the syntax is consistent.
Thanks to Erling Andersen, SMT Data, DENMARK.
Change 24.265 MXG 24.04-24.09. PDB.ASUMTAPE lost many observations,
ASUMTAPE only for TMNTEXIT='IBM'. Change 24.109 added incorrect
Jan 14, 2007 logic to propagate READTIME into 2nd-vol (HAVEMNT=501A)
events that are always missed by TMNT. Propagation is
now corrected, but there can ALWAYS be missing values
in many of the variables in PDB.ASUMTAPE, depending on
which events were found for this mount (which combines
TMNT Mount, Syslog Mount or Keep, SMF21 dismount events.)
An output from PROC MEANS N DATA=PDB.ASUMTAPE shows:
Variable N Implication
ZDATE 4030 Total mount event obs created
READTIME 1675 Mounts for jobs with a TMNT record
TAPMNTTM 1328 Mounts with a TMNT record
BYTES 3866 Mounts with matching TYPE21
TAPMTDTM 3615 Mounts with BEGTMNT/ENDTMNT
-If TMS9 message was first, with no prior SYSLOG MOUNT,
the TOTMNDTM duration was negative, SYLMTIME was wrong,
and there were other defects. This happens when SYSLOG
mount event was in yesterday's event for a long running
task that's writing lots of datasets (TMS9 for each one).
-When SYLMTIME is missing, EVENTIME=SYLKTIME-5 is now set
with a 5 second adjustment; SYLKTIME can be fractions of
a second later than TY21TIME, and this ensures TMNT will
be seen before SYSL in the merge.
-When TMS9 message was first, retained times were not
clearedl
Thanks to Doug Medland, IBM Canada, CANADA.
Change 24.264 Support for CMRDETL (T6E) records for Mainview for CICS
VMACMVCI Version 5.9.00 adds (COMPATIBLY) 132 new variables to the
Jan 12, 2007 CMRDETL dataset.
Change 24.263 Comments only; if you want to use VMXGGETM's arguments to
UTILGETM select SMF data, you need to invoke %VMXGGETM (... ) ;
Jan 11, 2007 as UTILGETM will not accept arguments.
Thanks to Flavio Lima, Bank of America, USA.
Change 24.262 If you want to know how many bytes of SMF data is written
Example for each of your CICS regions, by subtype, this example:
Jan 11, 2007 //SMF DD
//SYSIN DD *
%LET MACKEEP=
MACRO _KCICTRN )
CICSHDR (KEEP=APPLID MEGABYTE SUBTYPE
%
_N110
;
%LET MAC110H=
%QUOTE(MEGABYTE=LENGTH/1048576; OUTPUT CICSHDR;)
;
%INCLUDE SOURCLIB(TYPE110);
PROC FREQ DATA=CICSHDR;
TABLES APPLID*SUBTYPE;
WEIGHT MEGABYTE;
TITLE SMF 110 MEGABYTES BY SUBTYPE FOR EACH APPLID;
Thanks to Bruce Sloss, PNC, USA.
Change 24.261 Analysis of CPU variability as a function of NRCPUS for
ANALCPUV investigation of IRD impact. Reads PDB.TYPE70 to create
Jan 9, 2007 a temporary format $MGNRCPU with NRCPUS for each STARTIME
interval, uses that format to add the variable NRCPUS to
to each PDB.SMFINTRV observation, also finds each JOB's
MINCPUTM and MAXCPUTM, used to calculate each interval's
PCTOVRMN (Percent CPU TCB was above minimum recorded) and
PCTBLOMX (Percent CPU TCB was below maximum recorded).
The intent is to analyze benchmark data in which the same
job is run multiple times on a system with wide range of
IRD-controlled NRCPUS, to see if there is a measurable
impact on recorded CPU TCB time due to IRD.
It is theorized that the recorded CPU seconds should
be smaller when NRCPUS is small, and larger when the
NRCPUS is large, because of the "MP effect", partly
because the SU_SEC used to calculate service units
is NOT adjusted when IRD changes NRCPUS.
This program is ready to test that theory, and will
quantify the observed variability in CPU times, if
any is observed.
Let's discuss, before you run your benchmark.
Change 24.260 Documentation. Variable SUBMUSER was not in Dataset JOBS
DOCVER in the DOCVER documentation, because JOBS/STEPS/PRINT in
QASAS DOCVER were all from the JES3 BUILDPD3, but SUBMUSER is a
Jan 8, 2007 JES2-only variable. While I figure out how to change the
descriptions in DOCVER, where same-named datasets with
different variables are created by MXG, moving the JES3
BUILDPD3 ahead of the JES2 BUILDPDB in the QASAS QA
job will cause DOCVER to contain the descriptions of the
datasets built by the JES2 BUILDPDB.
Change 24.259 Mobius Subtype 8 record caused INPUT STATEMENT EXCEEDED
VMACIPAC error, because the final field, IPPACCES was only 4 bytes
Jan 5, 2007 while MXG expected 8. Both lengths are now protected.
This change also added support for R6.3.
Thanks to Jolene Halibry, Nationwide, USA.
Change 24.258 Product section character variables after PROPMPRE (most
VMACPROS of them!) were wrong because MXG's INPUT statement was
Jan 5, 2007 off by one byte. Some character variables with hex data
were not formatted but now are.
Thanks to John Kim, ATCO I-Tek, USA.
Change 24.257 Support for Beta 93 (Report/Print) Version 3.6.1 SMF; new
VMACBETA variables were added compatibly for tested subtypes:
Jan 4, 2007 Subtype 0: BETA0 dataset:
BETACTYP='CLEANUP*TYPE'
BETARCME='ARCHIVE*MEDIA*TYPE'
BETARETA='ARCHIVE*RETENTION*PERIOD'
Subtype 1: BETA1 dataset: no changes.
New subtypes 10, 51, and 52 are documented but will only
be supported when they are available for validation.
Thanks to Engelbert Smets, Provinzial, GERMANY.
Change 24.256 New variables added to IFCID 226 and 227 are supported.
VMAC102 Variables QW0226PN/QW0227PN are now character zeros, as
FORMATS new QW0226PG/QW0227PG variables now contain page number,
Jan 3, 2007 new QW0226FG/QW0227FG contain table space type, which is
decoded by new MGD226S format.
Thanks to Bill Schray, IBM Global Services, USA.
Thanks to Ted Blank, IBM Global Services, USA.
Change 24.255 Cosmetic, but may be useful. The MXG Messages printed on
VMACSMF the log at the end of SMF input are enhanced with elapsed
Dec 29, 2006 duration and the read rate of the input data:
*******************************************************
*** MXG 24.09 SUCCESSFULLY COMPLETED READING SMF.***
26750 LOGICAL SMF RECORDS WERE READ.
THE SMF FILE CONTAINED 325,284,835 BYTES,
WHICH IS 310MB.
MINIMUM SMF RECORD TIMESTAMP WAS 02SEP2004:09:00:00.04.
MAXIMUM SMF RECORD TIMESTAMP WAS 02SEP2004:09:34:57.14.
MXG FINISHED READING SMF FILE AT 29DEC2006:15:54:40.06.
ELAPSED TIME TO READ SMF FILE 0:00:08.69.
SMF READ RATE PER ELAPSED TIME 35MB/SEC.
*******************************************************
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.254 -Support for the rest of the Candle/IBM optional CICS data
IMACICC5 segments are added to UTILEXCL:
IMACICC6 IMACICC5 CANSUPRN SUPRA*TOTAL*REQUESTS
IMACICC7 IMACICC6 CANSUPRT SUPRA*TOTAL*DURATION
IMACICC8 IMACICC7 CANDCOMN DATACOM*TOTAL*REQUESTS
IMACICC9 IMACICC8 CANDCOMT DATACOM*TOTAL*REQUESTS
IMACICE3 IMACICC9 CANRES01 VSAM*TOTAL*REQUESTS
IMACICE4 IMACICE3 CANIDMSN IDMS*TOTAL*REQUESTS
UTILEXCL IMACICE4 CANIDMSN IDMS*TOTAL*REQUESTS
VMAC110 -Validation discovered that the CANGMTOF GMT offset was
Dec 24, 2006 never correct, but IMACICC1 is now revised to correctly
IMACICC1 decode the partial TOD stamp into the offset duration.
Dec 28, 2006
Technical Note ons tailoring CICS IMACICxx members:
When you use UTILEXCL to create IMACEXCL (RECOMMENDED!!),
you can remove Comment Blocks in ALL of your IMACICxx
members, because IMACEXCL's code only %INCLUDEs the IMACs
needed for each "DO GROUP" found in your PDB.CICSDICT.
Each execution of _BLDDICT appends new CICS dictionary
records found in SMF to the old PDB.CICSDICT dataset,
which is then read by _BLDEXCL to create the IMACEXCL
code that will read your SMF 110 CICSTRAN records.
The KEEP= list in IMACEXCL has only those variables that
exist in your PDB.CICSDICT records. Or, the KEEP= list
could have ALL of the hundreds of optional variables and
now defunct variables, if you have a old CICS dictionary
record from a test system long ago in your PDB.CICSDICT.
You may PROC DELETE DATA=PDB.CICSDICT; and create a new
IMACEXCL based only on today's CICS dictionary records.
And/or you can delete unwanted APPLIDs from PDB.CICSDICT
before you run the _BLDEXCL.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 24.253 Internal macro variable WORD4 was never set to a value,
READDB2 due to a typo.
Dec 23, 2006
Thanks to R. Narruli, DST Systems, USA.
Change 24.252 The eight-byte EXCP count in SMF33EXX that replaces the
VMAC33 four-byte SMF33EXP count is now INPUT when it exists.
Dec 23, 2006
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
====== Changes thru 24.251 were in MXG 24.09 dated Dec 20, 2006=========
Change 24.251 Protection for Mainview MQ records RTIN='26'x that didn't
VMACBBMQ contain the ISHD header segment that MXG thought would
Dec 20, 2006 always be there. Variables DURATM ENTC and GMTOFF might
be missing when there is no ISHD header segment.
Thanks to Stuart Wildey, Morgan Stanley, ENGLAND.
Change 24.250 Protection for Export date format of DDMMYY instead of
VMACMWNT expected MMDDYY requires you to set new &DATEFMT macro
VMXGINIT %LET DATEFMT=DDMMYY;
Dec 19, 2006 %INCLUDE SOURCLIB(TYPSMWNT);
if the "MWA EXPORT DD/MM/YY" text in the first record has
that format.
-The INPUT of SOFTWARE and RELEASE was revised to protect
for a Logfile name that contains blanks.
Thanks to Dominik Covens, KBC, BELGIUM.
Change 24.249 The old MACRO _DIFFHSM definition did not add _Sdddddd
VMACHSM sort macros for HSMWWFSR and HSMWWVOL datasets, probably
Dec 18, 2006 because the _Sxxxx Product Sort macro had replaced the
early "DIFF" nomenclature, and _DIFFHSM was overlooked.
Now, those two datasets are included when _DIFFHSM is
invoked, but the preferred name to use in your EXPDBOUT
member is to have a _Sxxxx statement for each VMACxxxx
that you %INCLUDed in your EXPDBINC tailoring member.
Then, MXG is responsible for any deaccumulation as well
as adding any new datasets into your PDB library as part
of your BUILDPDB job.
Thanks to Dwain Majak, B, B, and T, USA.
Change 24.248 Enhancement to the "BUILD PDB EXAMPLE", BLDSMPDB, adds
BLDSMPDB optional processing of DCOLLECT and TMS/CA-1 records into
Dec 18, 2006 the daily PDB library, so they can also then be created
Dec 20, 2006 in your weekly and monthly PDB libraries.
New argments:
DCOLLECT=DCOLLECT - read INFILE DCOLLECT output PDB
=dsname - alloc FILENAME DCOLLECT to dsname
all output to PDB
TMC =TMC - read INFILE TMC output PDB
dsname - allocates FILENAME TMC to dsname
Additionally, SMF data weekly/monthly processing can be
weekly/wtd, and monthly/mtd. Weekly/Monthly will copy
all, or only selected, datasets. Exits were added for
flexibility during weekly/monthly/trend processing.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.247 Inconsistent macro definitions for _Vdddddd, _Wdddddd:
VMACCMA -VMACCMA User SMF record now have the standard, expected
VMACQACS macro token names and definitions for the syntax for
VMACTNG "Single Infile, Multiple Datasets Per Product" data:
VMACTMO2 For each output dataset:
VMACCIMS MACRO _Vdddddd
Dec 19, 2006 KEEP= list of variables
%
MACRO _Wdddddd &Wdddddd..DATASET %
MACRO _Kdddddd %
Output all datasets for the product:
MACRO _VARXXXX
_Wdddddd
(LABEL='dddddd: description'
_Vdddddd _Kdddddd
)
....
_Wdddddd repeat for each product dataset.
%
-VMACTMO2 User SMF record updated with standard, expected
macro token names, as above for "Single Infile, Multiple
Datasets Per Product" data.
-VMACCIMS User log record updated with standard, expected
macro token names, as above for "Single Infile, Multiple
Datasets Per Product" data.
-VMACTNG macro _NTNG had incorrect syntax, with the text
"MACRO" missing from each statement; it would have failed
if it had been used!
-But even though they are inconsistent naming conventions
now, the VMACQACS AS/400 macro names _VQAPxxx _CQAPxxx
cannot be changed without serious exposure to existing,
fine running jobs. For the record, for these datasets
from "MULTIPLE INFILES, ONE OUTPUT PER INFILE" data:
For each output dataset:
MACRO _TQAPxxx
DATA
_VQAPxxx
_CQAPxxx
%
MACRO _WQAPddd &Wdddddd..DATASET %
MACRO _Kdddddd %
Where the _VQAPxxx was already defined as:
MACRO _VQAPxxx
_Wdddddd
(LABEL='QAPxxx: description'
KEEP= list of variables
)
%
So your tailoring syntax is slightly different here, but
that's the lesser of causing production job failures!
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 24.246 REGION=0M added to MXGSASV9/MXGSASV8 JCL PROC examples to
MXGSASV8 protect sites that did not specify a REGION on their JOB
MXGSASV9 card. (The MXG JCL examples do show REGION=0M on JOB.)
Dec 15, 2006 -When REGION=0M is specified on the JOB JCL statement, the
job gets your installation default REGION=0M size, often
100MB-300MB, which is quite sufficient for most MXG jobs,
for every step in the job.
-With REGION=xxxM value specified on the JOB card, all of
the steps get that xxxM REGION size, even if there is a
larger or smaller REGION= value on a STEP card.
-If the JOB does not have a REGION= parameter, the job and
each step gets a different default region, of only about
40MB (9MB Private Area + 32MB Above the Line).
While much of MXG 24.08 does run in a 40MB REGION,
(including the JCLINSTL job that successfully created
the MXG Format Library), the BUILDPDB job failed when
run in only 40MB, with SAS FORMAT NOT FOUND errors
(but each individual formats was there and usable by
itself). The 40MB wasn't enough region for the
"BUILDPDB big DATA step", which allocates virtual
storage for all of the output buffers for all of the
datasets to be created, and then loads all referenced
formats into virtual storage.
-The default BUILDPDB needs a 64MB REGION, generally, but
may need 100MB+, if you have tailored your BUILDPDB to
process additional SMF records.
Thanks to Donald Likens, Combined Insurance, USA.
Change 24.245 DVTG3 table had new fields added in 1.7 and 1.8 that are
VMACRMFV now kept:
Dec 18, 2006 CMRTM Command*Response*TIME
DVTCUQTP Control Unit Queueing Time Previous
DVTCUQTN Accum CU Wait for non-FICON devices
DVTCUQTF Accum CU Wait for FICON devices.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.244 New PDB.ASUMDB2G summary dataset for DB2 Global Buffers
ASUMDB2G is created from PDB.DB2ACCTG dataset by ASUMDB2G member.
VMXGINIT
Dec 13, 2006
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Change 24.243 The test for which DB2ACCT observations are counted as
ASUMDB2A NORMAL was revised to include QWACRINV=4 thru 16 and 40
Dec 12, 2006 as NORMAL and all other QWACRINV values as ABNORMAL, to
be consistent with the formatted values of QWACRINV in
the MGDB2RC format.
Thanks to Nigel D. Greenwood, EDS, ENGLAND.
Change 24.242 Revisions to force TEMPxx macro variable explicitly to a
VMXGINIT value of WORK, and revised setting of SASSWORK, etc., for
VMXGSUM anticipated SAS/ITRM changes to support SAS V9 BI.
Dec 12, 2006
Change 24.241 Keyword parameter WORK73 was accidentally typo/deleted in
VMXGRMFI the macro definition, causing an error only if there were
Dec 11, 2006 73 or more workload's defined.
Thanks to Clayton Buck, UniGroup, USA.
Change 24.240 -All durations were 1000 times too large; I assumed the
VMACSYSI times were in 256*milliseconds, like most prior IMS data,
Dec 7, 2006 but data and documentation show they are 256*microsecs,
so all &PIB.4.3 informats were changed to &PIB.4.6.
Thanks to Betra Reeves, Infocrossing, USA.
Thanks to Joel Medberry, Infocrossing, USA.
Change 24.239 MACRO _ROSCDDN has not been used since the &Pdddddd and
VMACROSC &Wdddddd macro variables were defined, but comments in
Dec 6, 2006 IMACROSC and VMACROSC were still present/confusing.
To send all of the ROSCOE datasets to the //PDB DD, use
%INCLUDE SOURCLIB(TYPSROSC) which will sort, remove any
duplicates, and output them to //PDB.
Thanks to Lori Martin, Lockheed Martin, USA.
Change 24.238 RMF III variables ENCTCPUT and ENCCPUT are in millisecs
VMACRMFV in the RMF III record, but are not documented as such.
Dec 5, 2006 They are now corrected in their INPUT, and I have also
made the assumption that these IFA time variables in the
same segment are also in millisecs in the record, and are
also corrected in their INPUT informat.
ENCTIFAT ENCTIFCT ENCIFAT ENCIFCT
Thanks to Brenda Rabinowitz, Merrill Lynch, USA.
Change 24.237 Label for NRZIPCPU and NRIFAS in PDB.RMFINTRV had text of
VMXGRMFI "IN THE BOX", but as RMFINTRV is a PER-SYSTEM dataset,
Dec 1, 2006 the label is changed to "FOR THIS SYSTEM'.
Thanks to Douglas C. Walter, Citigroup, USA.
Change 24.236 Reserved Change.
EXITCICS
VMACSMF
Nov 30, 2006
Change 24.235 EJBCRECT was input twice, the second time where EJBREMCT
UTILEXCL was located, so EJBCRECT was wrong and EJBREMCT did not
Nov 30, 2006 exist when UTILEXCL was used to process CICS data.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 24.234 If you specified %LET MACKEEP ahead of UTILBLDP, it may
UTILBLDP be ignored if you are also adding records in a BUILDPDB
Nov 21, 2006 process. This change puts your MACKEEP values inside of
the MACKEEP being generated by UTILBLDP. Note however
the error message that your use of MACKEEP here may
defeat something UTILBLDP is trying to do so use it with
caution.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 24.233 MXGERROR: More than 70 200 Byte Strings is circumvented
VMXGSUM by increasing the MXG default to 99 200 byte strings for
Nov 21, 2006 the variable lists (SUM=, etc.) that VMXGSUM must parse.
Using the full line for your variables, up to 72 bytes,
will maximize the number of variables that will fit in
the 99*200=19800 bytes for each argument, enough for 2200
variables with 8-byte names.
Change 24.232 The last field in subtype 2, ACTRREPQ is only 45 bytes,
VMACENTX not the 48 bytes documented by the vendor.
Nov 20, 2006
Thanks to Chris Taylor, GMAC Insurance, USA.
Change 24.231 Label for variables SOV2WMNT was corrected to read:
VMACHPDM SOV2WMNT='ACCUM*DELAY*WAITING*FOR MOUNT'
Nov 18, 2006
Thanks to Tom Elbert, Assurant, USA.
Change 24.230 SAS procedures BLKCOPY & FCOPY (used during Installation
FORMATS and Service Pack Updates, and MIGRATE are now recognized
Nov 14, 2006 by the $MGSASPR format. Even though the official SAS doc
(only found deep in the SAS Support site) says you cannot
use PROC MIGRATE from SAS 6.09E to SAS 9, that particular
conversion IS supported, but only under SAS on z/OS.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 24.229 The program worked fine if output to //WORK was used, but
TYPEIMS7 if you used either of the examples in the comments, to
Nov 9, 2006 send either IMS0708 or IMSSUMRY to the //IMSTRAN ddname,
that failed with ERROR 455-185 DATA SET WAS NOT SPECIFIED
ON DATA STATEMENT.
Thanks to Denise L. Jeffers, CIGNA, USA.
Change 24.228 Support for HyperPAV APAR OA12865.
VMAC74 -TYPE74 dataset: New variables created:
VMAC78 HYPERPAV='HYPERPAV*BASE*DEVICE?'
Nov 11, 2006 SMF74HPC='HYPERPAV*ALIASES*CONFIGURED*THIS LSS'
SMF74PSM='SUCCESSFUL*PAV*SAMPLE*COUNTS'
Variable SMF74TMS is deleted, as it never existed and was
input by MXG in error.
-TYPE78CU dataset: New variables added for each LCUID:
R783HCU ='HYPERPAV CU IDENTIFIER'
R783HNAI='TIMES I/O NO START*NO HYPERPAV*AVAILABLE'
R783HTIO='HYPERPAV I/O*REQUESTS*FOR THE LSS'
R783HAIU='HWM*IN-USE*HYPERPAV*ALIASES'
R783HCAD='HWM*ALIASES*IN USE*ONE BASE'
R783HIOQ='HWM*OF IO-S QUEUED'
Variable PCTALLBY set missing, per Change 19.203, instead
of generating a missing value note for each TYPE78CU obs.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 24.227 Optional ESS GPARMKEY='4A'x caused INPUT STATEMENT
IMAC6ESS EXCEEDED LENGTH error if there were more than one
VMAC6 addressee. MXG now keeps four (ESSMACC1-ESSMACC4)
Nov 7, 2006 and alerts you if there were more, with a note.
Nov 8, 2006 -Support for ESS GPARMKEY='4C'x creates ESSMFROM variable
Nov 9, 2006 and for ESS GEPARMKY='42'x creates ESSOFSYF variable.
-Support for ESS GEPARMKY='2023'x creates ESSOUTBN.
-Length of DEPT, TITLE, BUILDING increased to $60.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Change 24.226 Variable QWACWLME, Service Class Name, is now kept in the
VMACDB2 PDB.DB2ACCTP dataset for analysis. Note that APAR PK37312
Nov 7, 2006 corrects blank value in QWACWLME after zIIP maintenance.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.225 LPARs with no current share (no current weight points)
VMAC7072 had LPARSHAR=0 in PDB.TYPE70. Those LPARs are treated
Nov 7, 2006 now as Current Share = Initial Share.
Thanks to Rudolf Sauer, T-Systems Enterprise Services GmbH, GERMANY.
Change 24.224 Setting the Clock Back an hour, without quiescing for an
VMAC7072 hour, produces duplicate values of STARTIME in all RMF
VMXG70PR datasets, plus negative execution/elapsed/durations/etc
Nov 7, 2006 in many other records, and in many cases it is impossible
Nov 17, 2006 to even recognize the duplication/overlap.
However, for the 70 and 72 records, adding GMTOFFTM to BY
lists, after SMF70GIE, and to the KEEP= lists, appears to
prevent the duplicate STARTIME values from being summed
(which caused doubling of the values of PARTNCPU and
CPCMUS, among other errors), although duplicates will
still exist in these datasets.
Nov 17: Typo, APPCLAX in KEEP= in VMAC7072 should have
been APPCMAX, which caused APPCMAX to be not kept.
Jan 21: See Change 24.
Thanks to Rudolf Sauer, T-Systems Enterprise Services GmbH, GERMANY.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 24.223 Total Virtual Storage Above the Bar was captured in the
VMAC78 VSDGxxxx variables in TYPE78VS dataset, but the Shared
Nov 7, 2006 bytes were not INPUT. And because IBM reused the VSDG
Dec 19, 2006 prefix for both sets of variables, this change changes
the variables VSDGxxxx to TOBYxxxx for the Total Byte
fields, and now creates SHBYxxxx variables for Shared
byte fields above the bar.
Dec 19: Corrected long line for R783HNAI input.
Thanks to Ralph C. Baechle, John Deere, USA.
Change 24.222 CICS Statistics variables DSGEJST and DSGSRBT were INPUT,
VMAC110 and correctly calculated/formatted, but were not KEPT in
Oct 24, 2006 the CICDS dataset.
Thanks to Helmut Rose, Com-Software, GERMANY.
Change 24.221 -Support for changed field lengths in SAR/EXD SMF type 6
IMACEXD optional data.
Oct 24, 2006
Thanks to Joe Kimberly, Kansas City Southern, USA.
Change 24.220 -Support for NTSMF OBJECT='DATABASE ==> INSTANCES creates
EXNTDATI new DATABASI dataset; previously, those objects were
IMACNTSM output into the DATABASE dataset, which caused nearly-
VMACNTSM duplicate observations.
VMXGINIT -Support for DATABASE object with NRDATA=191.
Oct 25, 2006
Thanks to Paul Billick, Harleysville Insurance, USA.
Change 24.219 The optional ARZGS GSACCT segment for CICS can have any
UTILEXCL length; MXG's INPUT statement expected 8, which caused
Oct 21, 2006 errors when the real length was 12. Now, UTILEXCL prints
the CMODLENG and a message to compare your actual length
with MXG's, and to change IMACICU2 if needed.
Thanks to Richard Hilber, Allgemeines Rechenzentrum GmbH, AUSTRIA.
Thanks to Peter Gschirr, Allgemeines Rechenzentrum GmbH, AUSTRIA.
Change 24.218 Support for NTSM Beta Version 3.0.0.8 (COMPATIBLE), adds
VMACNTSM SUMRYINT and ORGANIZN to NTCONFIG dataset.
Oct 18, 2006
Change 24.217 If you want to process on the CICSTRAN data to create the
ASUMUOW PDB.ASUMUOW dataset without reading DB2ACCT, when there
Oct 18, 2006 are observations in DB2ACCT, you can use
%INCLUDE SOURCLIB(BUILDPDB);RUN;
%LET MACKEEP=
MACRO _NOOBS % MACRO _YESOBS % ;
MACRO _LDB2ACC WORK.DB2ACCT %
;
%INCLUDE SOURCLIB(ASUMUOW);
and MXG will use only CICSTRAN as input to PDB.ASUMUOW.
Thank to Christian Hodel, SwissCom, SWITZERLAND.
====== Changes thru 24.216 were in MXG 24.08 dated Oct 18, 2006=========
Change 24.216 Using SUPPRESS with TYPETMNT failed; logic in UTILBLDP
UTILBLDP didn't protect non-standard-named-tokens, now corrected.
Oct 18, 2006
Thank to Robbie A. McCoy, Salt River Project, USA.
Change 24.215 Incorrect values for ICMP Statistics variables TSICDUTM
VMAC119 thru TSICOUAR, because -3 was incorrectly subtracted
Oct 18, 2006 twice from OFF11905 when subtype 6 logic was added.
Thank to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
====== Changes thru 24.214 were in MXG 24.08 dated Oct 17, 2006=========
Change 24.214 Processing z/OS 1.6 with SPG processing enabled failed
ASMRMFV with an 0C4, as there were no SPG records in z/OS 1.6.
Oct 16, 2006 Correction bypasses SPG for old versions.
Thank to Betty Wong, Bank of America, USA.
Change 24.213 Variable MCDFBID is now formatted HEX8. vice HEX4.; the
VMXGHSM field was INPUT as PIB4.
Oct 16, 2006
Thank to Sam Bass, McLane Company, USA.
Change 24.212 Support for NetSpy Version 11 was added in August, 2005,
VMACNSPY when test data validated that records were unchanged.
Oct 16, 2006
Thank to Brian Conway, IBM Global Services, CANADA.
Change 24.211 INVALID DATA messages for SCBGN, SYSIUL, SYSCIU because
VMACQACS MXG had &NUM vice &PD, and incorrect lengths for those
Oct 15, 2006 QAPMSYST variables.
Thanks to Jim Wertenberger, Antares Solutions, USA.
Change 24.210 Support for SMF 99 Resource Group section now creates new
EXTY99RG TYPE99RG dataset.
IMAC99
VMAC99
VMXGINIT
Oct 13, 2006
Thanks to Claude Breault, Centre de Services Partages Quebec, CANADA.
Change 24.209 Syntax error corrected; the previous circumvention to run
UTILBLDP as a two step process should no longer be required with
Oct 13, 2006 the Oct 17th edition.
Oct 17, 2006
Thanks to Ralph Gifford, AIG, USA.
Thanks to Bruce Whittington, TIAA-CREF,USA.
Change 24.208 LPAR share variables were destroyed by Dedicated CPUs;
VMAC7072 the test was expanded for their calculation to bypass:
Oct 13, 2006 IF SMF70CIN='CP' AND LCPUSHAR NE 0FFFFX THEN DO;
These variables were impacted if you have Dedicateds:
TOTSHARE TOTSHARC LPARNSW LPARSHAR LPARSHAC
Thanks to Rudolf Sauer, T-Systems Enterprise Services GmbH, GERMANY.
Change 24.207 TYPE72GO CPUTCBTM (and hence CPUTM) will incorrectly have
VMAC7072 included the zAAP CPU time, if zIIP APAR OA13499 was put
Oct 13, 2006 on, but you did not also install the z/OS web-deliverable
FMID JBB722S (or JBB66S9) for that zIIP APAR. The APAR
extended the segment to 576 bytes, adding zIIP fields,
but also two new IFA Service Units in R723CIFA,R723CIFC.
The two IFA fields are created by the APAR, but with only
the APAR installed, they are always zero. IBM says this
is working as designed, that I should only use the new
fields if they are non-zero. Unfortunately, IBM did not
document that "design" feature in the SMF manual!
Prior to the INPUT of R723CIFA/CIFC, MXG created IFAUNITS
from the CPUIFATM, but then the zero in R723CIFA was put
in IFAUNITS, so those service units were not subtracted
from the raw CPUUNITS, causing CPUTCBTM/CPUTM to include
CPUIFATM. This condition can be detected in your data,
and/or corrected in PDB.TYPE72GO with this test/logic:
DATA TYPE72GO;
SET PDB.TYPE72GO;
IF IFAUNITS=0 AND CPUIFATM GT 0 THEN DO;
NFOUND+1;
IF NFOUND=1 PUT 'INCLUDED ZAAP TIME WAS FOUND';
CPUTCBTM=CPUTCBTM-CPUIFATM;
CPUTM=CPUTM-CPUIFATM;
END;
Jan 18: This change in MXG 24.08 was a CRITICAL CHANGE,
and was the final change to the SPLIT70 redesign. For one
site, it corrected negative CPUOVHTM in PDB.RMFINTRV and
the associated error messages RMFINTRV was created that
could occur with MXG 23.23 thru MXG 24.07.
Thanks to Tom Draeger, Aurora, USA.
Thanks to Heimir Hauksson, Barclays Bank, UK.
Change 24.206 Support for NTSMF Version 3.0.0.7 adds two new objects:
EXNTDTBU NTDTBU DTSBUFFU NT DTS.BUFFER USAGE
EXNTDTPL NTDTPL DTSPERFL NT DTS.PERFORMANCE LIBRARY
IMACNTSM
VMACNTSM
VMXGINIT
Oct 11, 2006
Change 24.205 Support for DATABASE ==> INSTANCES object with NRDAT=152.
VMACNTSM Two new variables created in NTSMF dataset DATABASE:
Oct 11, 2006 LOGCKPDP='LOG*GENERATION*CHECKPOINT*DEPTH'
SBPRDRT ='STREAMING*BACKUP*PAGES*READ PERSEC'
Thanks to Paul Billick, Harleysville Insurance, USA.
Change 24.204 Support for IMPLEX Version 4.10 (INCOMPATIBLE, fields are
EXMPLXAR expanded and new ones were inserted), with new variables
IMACMPLX and new IMPLEXAR dataset for the subtype 8 Alert Record.
VMACMPLX Sorts were updated to ensure duplicates are removed.
VMXGINIT
Oct 11, 2006
Change 24.203 If the number of workloads requested to be graphed in the
GRAFWRKX sample program exceeded 20, the program failed, and the
Oct 9, 2006 values for 21,31,41,51,61,71,81, and 91 were not defined.
Change 24.202 -New macro variable &SMFEXIT is added in VMACSMF to each
VMXGINIT statement INFILE &SMF &SMFEXIT .... in preparation for
VMACSMF MXG support for compressed SMF records. Soon, &SMFEXIT
Oct 7, 2006 will name the to-be-provided "INFILE EXIT" that will
Jan 28, 2007 decompress SMF records "on the fly". &SMFEXIT defaults
to blank in VMXGINIT. Stay tuned for a later change.
Note, however, SAS Infile Exits only exist under z/OS.
-While intended for a different purpose, this new macro
variable, since it is inside the MXG INFILE statement,
can be used also to pass INFILE options. In particular,
you can limit the observations that will be READ from the
SMF file, using
%LET SMFEXIT FIRSTOBS=nnn OBS=mmm;
%INCLUDE SOURCLIB(....);
This is very useful for MXG members that have to invoke
PROC SORTs to deaccumulate (like TYPEDB2,TYPEVMXA, etc),
because you can NOT use an OPTIONS FIRSTOBS=mmm OBS=nnn
global statement with those code members; the global will
restrict the INFILE processing, but they then need to be
reset to FIRSTOBS=1 and OBS=MAX prior to the SORTs, and
there is not simple way to do that for these members.
But now, you can use the preceding example to restrict
the INFILE but not the subsequent PROC SORTs.
Change 24.201 Support for E-Thales Security product's five user SMF
EXTHALCD records (poor choice: they should have created a single
EXTHALEX SMF record and used five subtypes!) creates these seven
EXTHALHS datasets:
EXTHALSA DDDDDD MXG MXG
EXTHALSD DATASET DATASET DATASET
EXTHALSN SUFFIX NAME LABEL
EXTHALVI
IMACTHAL THALCD THALCDS CDS PARAMETER RECORD
TYPETHAL THALHS THALHSMD HSMD ENTRY IN CDS RECORD
TYPSTHAL THALEX THALEXCE DETAIL EXCEPTION RECORD
VMACTHAL THALVI THALVIOL SECURITY VIOLATION RECORD
VMXGINIT THALSA THALSUMA APPL IN SUMMARY RECORD
Oct 5, 2006 THALSD THALSUMD DEVICE IN SUMMARY RECORD
THALSN THALSNAP SRM SNAPSHOT RECORD
Thanks to ??? , Public Bank, MALAYASIA
Thanks to Patrick Yap Chee Keong, SAS Institute, MALAYASIA
Change 24.200 Support for SMF 82 Subtype 22 (TRUSTED BLOCK CREATE CALL)
EXTY8222 creates TYPE8222 dataset.
IMAC82 Variable SMF82SXT in Subtype 21 is now input as numeric
VMAC82 numeric variable, and FORMATed DATETIME21.2, as the
VMXGINIT time value is TODSTAMP and not the documented $CHAR8.
Oct 10, 2006
Thanks to Greg Burt, 5th3rd Bank, USA.
Change 24.199 -Support for ThruPut Manager Version 6 adds new variables
VMACTPMX for IBM/STK/VTAPE/COPYCROSS virtual tape usage, and new
Oct 5, 2006 "Drive Booking Services":
CAC7IDID CA7INALI JXDBSPR JXDBSUU JXDBSWG JXSERVIC
JXIMPORT VOLVIBM VOLVIBMR VOLVIBMN VOLVSTK VOLVSTKR
VOLVSTKN VOLVVTS VOLVVTSI VOLVVTSN VOLVCPC VOLVCPCO
VOLVCPCM
-Change 24.147 incorrectly inserted NOT in the test for
JBAFF; that NOT is removed, that change text updated.
If the two formats in your IMACTPMX do not correctly
map your SYSPLEX and SYSTEMs, that will cause JBAFF to
be blank, but the original MXG logic is correct.
Thanks to Scott Barry, SBBWorks, Inc.
Change 24.198 Variable INTETIME (Interval End) in TYPE30_6 was wrong
VMAC30 if GMT offset was non-zero; the subtype 6 doesn't contain
Oct 4, 2006 SMF30IST, which was used to calculate GMTOFF30. Now, that
is calculated as GMTOFF30=SMFTIME-INTETIME for subtype 6.
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Thanks to Michel Denervaud, UBS, SWITZERLAND.
Change 24.197 Variables DCVDVTYP DCVDPTYP from the VOLS record are now
VMACDCOL kept in both DCOLDSET and DCOLCLUS datasets, so the type
Oct 3, 2006 of device is known. For example,
DCVDVTYP='3390' DCVDPTYP='33909'
DCVDVTYP='3390' DCVDPTYP='2105'
Thanks to Brian Harvey, Blue Cross Blue Shield of Illinois, USA.
Change 24.196 TYPE1415 INPUT STATEMENT EXCEEDED RECORD with z/OS 1.7
VMAC1415 plus ptf's, or with z/OS 1.8 due to MXG coding error that
Oct 3, 2006 was introduced in Change 24.094 for new PDSE Cache Stats.
Dec 5, 2006 SKIP=SKIP-32; is required in place of the SKIP=SKIP-16
added by Change 24.094 (in MXG 24.04).
Thanks to Diane Eppestine, AT&T Services, Inc, USA
Thanks to Frank Debree, Dexia, BELGIUM.
Change 24.195 Variables QW0143UR and QW0144UR printed funny values.
VMAC102 They are now FORMATted $HEX12. and input as $CHAR6.
Oct 2, 2006 instead of $EBCDIC6. (required for ASCII execution, makes
no difference when executing MXG on z/OS), like the other
QW0nnnUR Unit Recovery Token variables.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 24.194 -CPUTM and QWSnXXXX variables in PDB.DB2STATS Statistics
VMACDB2 dataset was wrong, with large positive or negative values
Sep 29, 2006 due to incorrect login in MXG code.
Oct 10, 2006 -New QWSnZSRB variable, Preemptable SRB Time on zIIP is
now created and kept in the PDB.DB2STATS dataset.
-ADOCDB2 CPU variables were updated to indicate whether or
not they contained zIIP CPU time.
-Variable QWHUCPU is now kept in DB2ACCT.
-zIIP variables QW0231ZI and QW0231ZE for IFCID 231 are
now created and kept in T102S231.
Thanks to Jim Robson, HighMark, USA.
Thanks to John Paul, HighMark, USA.
Change 24.193 Support for 3592 Tape Devices (no change); they have the
VMAC30 same DEVTYPE as the 3590s, so usage will automatically
Sep 27, 2006 be stored in the xxxx3590 variables.
Change 24.192 Using %READDB2, you could not override the output DDNAME
READDB2 using %LET PDB2ACC=DB2ACCT; %READDB2(WANTONLY=ACCOUNT);
Sep 27, 2006 to create observations only in DB2ACCT.DB2ACCT. Now, if
PDBOUT= argument is null, the original _Ldddddd defs will
be used, so the %LETs can be used to changed output DD.
NOTE BENE: CHANGE 25.189 REVISED PDBOUT= options, and
THIS CHANGE IS NO LONGER CORRECT. SEE PDBOUT= option in
the READDB2 or ANALRMFR member for revised impacts.
NOW, if PDBOUT=, (the default) was specified, ALL output
datasets will be written to //WORK DD. PDBOUT=YES is now
required if you want your user tailoring honored.
Change 24.191 Support for HP MeasureWare for Windows/NT for Collector
EXMWNTAP Versions C.03.65.00 and C.04.50.00. C.04 has additional
EXMWNTCO variables that will be missing with C.03 data records.
EXMWNTDS These datasets are created:
EXMWNTGL DDDDDD DATASET DATASET
EXMWNTLA SUFFIX NAME LABEL
EXMWNTPR MWNTAP MWNTAPPL HPMWA MWNT APPL RESOURCES
EXMWNTTT MWNTCO MWNTCONF HPMWA MWNT CONFIGURATION
EXMWNTVL MWNTDS MWNTDSK HPMWA MWNT DSK ACTVTY FRM DIS
IMACMWNT MWNTGL MWNTGLOB HPMWA MWNT GLOBAL ACTIVITY
TYPEMWNT MWNTLA MWNTLANS HPMWA MWNT LANS
TYPSMWNT MWNTPR MWNTPROC HPMWA MWNT PROCESS RESOURCES
VMACMWNT MWNTTT MWNTTRAN HPMWA MWNT TRANSACTION TRACKER
VMXGINIT MWNTVL MWNTVOLS HPMWA MWNT VOLUME ACTIVITY
Oct 2, 2006
Thanks to Bobby Greer, Automobile Association of Michigan, USA.
Thanks to Dominik Covens, KBC Bankverzekeringsholding, BELGIUM
Change 24.190 Executing the output of %UTILBLDP as a separate step, if
UTILBLDP you specified both BUILDPDB=YES and EXPDBOUT= text that
Sep 25, 2006 had a %INCLUDE, caused an error deep inside SAS, either
a syntax error, or expression exceeded 64000 bytes error.
If you use %UTILBLDP this way in the two-step process,
then you must add this statement at the first //SYSIN
in the saved output that will be executed:
%LET BLDPOUT= xxxxxx ;
where xxxxx is the text in the EXPDBOUT= argument.
Thanks to Robert Carballo, Office Depot, USA.
Change 24.189 The options NOOPD and NOSPG did not suppress the OPD/SPG
ASMRMFV records, causing OPD or SPG records to be output when you
Sep 25, 2006 had intended to not write them. And, the NOCSR flag was
incorrectly set when NOSPG was specified.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.188 Support for new TNG object from NT and SOLARIS platforms:
EXTNT131 dddddd Dataset Description
EXTSO029 TNT131 NT131 SLM METRICS
IMACTNG TSO029 SO029 CA PROCESS GROUP
VMACTNG and additional variables in AI019, AI022, AI024, and the
VMXGINIT NT035 datasets, and labels were corrected.
Sep 26, 2006
Thanks to Michael Kynch, International Paper, USA.
Change 24.187 ASUM70PR with INTERVAL=HOUR (or any duration) can create
VMXG70PR observations with incorrect DURATM (50 vice 60 minutes,
Sep 23, 2006 which then caused PCTCPUBY and PCTOVHD to be too large),
Oct 8, 2006 because MXG's heuristic test IF FIRST.DURATM to recognize
a new group to store SYSDUR failed when adjacent DURATMs
happened to be identical. That test is enhanced to also
recognize a group when the new LCPUADDR is less than the
old LCPUADDR, a far more robust criteria. This error can
NOT occur with the defauit INTERVAL=DURSET in ASUM70PR,
which does not summarize by time, so this error can occur
only if you have a tailored ASUM70PR member. Five out of
twenty-four intervals were wrong in one day's data, but
only those three variables were wrong; all of the other
data were correct.
-Oct 8: Notes about uninit OLDSTART, OLD70GIE eliminated.
Thanks to Scott Weiner, WPS Insurance Corporation, USA.
====== Changes thru 24.186 were in MXG 24.07 dated Sep 22, 2006=========
Change 24.186 Support for zIIP variables in PDB.RMFINTRV dataset; I had
VMXGRMFI overlooked this addition. MXG 24.07 was redated with the
Sep 17, 2006 change so all of the "mainstream" MXG datasets now have
the additional sets of ZIP/ZIE variables.
Thanks to Jonathan M. Miller5, JohnDeere, USA.
====== Changes thru 24.185 were in MXG 24.07 dated Sep 21, 2006=========
Change 24.185 Support for DMF Product that creates SMF 110 records with
VMAC110 SMFPSRVR=41.1, i.e., CICS/ESA 4.1.1 (from 1994). While
Sep 17, 2006 MXG supported 4.1.0 and 5.1.0, there never was an MXG
site with 41.1, and it may be their creation, as it has a
seventh TCB, while 5.1.0 only had six.
Thanks to Vernon Stanton, Government of South Australia, AUSTRALIA.
Change 24.184 -Variables ORIGWAIT in PDB.TYPE70PR was not populated for
VMAC7072 IFAs and ZIPs, but it is needed so that both the "CPU"
Sep 17, 2006 busy (LCPUPDTM-based) and the "MVS" busy (ORIGWAIT-based)
can be calculated for analysis of logical ready queues.
Now, in the observations with PARTISHN=LPARNUM ("this"),
ORIGWAIT will be populated for SMF70CIN='IFA' or 'IIP'.
-PDB.TYPE70 existing variables PCTIFBYx and PCTZIBYx are
the "MVS" percentages, but MXG did not create the "CPU"
(LCPUPDTM-based) percentage for IFAs nor ZIPs. Now, new
PCTCIBYx variables are created with the "CPU"/"Logical"
percentages, for the IFA or ZIPs, and variable IFATYPx
identifies if the CPU is an IFA or a ZIP. This permits
the analysis of Logical Ready Queuing for IFAs and ZIPs,
as well as for CPs.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 24.183 Variables Q3STHWIB, Q3STHWIF, and Q3STHWCT are high water
VMACDB2 mark values and should not have been de-accumulated.
Sep 16, 2006 Oct 5: Also, variable QDSTMIN2.
Oct 5, 2006
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Ralph Baechle, John Deere, USA.
Change 24.182 -NDMCPUTM (created from the text string CPUTIME=) had a
VMACNDM few small negatives, because the BY list was insufficient
Sep 12, 2006 to force the correct order for de-accumulation.
Sep 13, 2006 The time sequence within NDMPRCNO was different when
Sep 14, 2006 sorted by NDMTIME vs SMFTIME; each created a different
group of observations with negative NDMCPUTM. Using
the raw NDMCPUTM value in place of time of day appears
of have corrected the negative values; but check your
own data to be sure.
-Change 24.144 created new variable NDMCPU when the DSECT
showed a four-byte "CPU TIMEUSED" field added in NDM 4.3,
but it took us several iterations to INPUT the field from
the right place with the (undocumented) correct decimal,
in part because with NDM 4.5, the first-bit of NZMZFMT is
off, indicating an 8-byte UID, but the record has the
64-byte Expanded UID. I assume it is always present in
the current versions, so MXG now always INPUTs 64-bytes.
And one site's network group validated the MXG NDMCPU
value, so the NDMCPU variable may be valid. Sterling
says the field was populated in Version 4.4.
Thanks to Rodger Foreman, Acxiom, USA.
Thanks to David Kaplan, Depository Trust & Clearing Corporation, USA.
Thanks to Rob Hollingum, HSBC, ENGLAND.
Change 24.181 -Support for OPDG3 and SPGG3 RMF III segments required
ASMRMFV updates to ASMRMFV and revision to MXG code to create:
EXZRBOPD ddddd Dataset Descriptino0
EXZRBSPG ZRBSPG ZRBSPG RMFIII STORAGE GROUP AND VOLUME DATA
IMACRMFV ZRBOPD ZRBOPD RMFIII OMVS PROCESS DATA TABLE
VMACRMFV -Support for zIIP data added to ASIG3 segment:
VMXGINIT ASIMCDLY='MULTI STATE*PROCESSOR*DELAY*PCT'
Sep 12, 2006 ASIMCUSE='MULTI STATE*PROCESSOR*USING*PCT'
Sep 16, 2006 ASIPHTZA='PREEMPTABLE*SRB*FOR ZAAPS'
Sep 19, 2006 ASIPHTZI='PREEMPTABLE*SRB*FOR ZIIPS'
ASISDCCP='PCT*DELAYED*BY CP*PROCESSOR'
ASISDCSP='PCT SINGLE STATE*SAMPLES*DELAYED*BY ZIIP'
ASISUCCP='PCT SINGLE STATE*SAMPLES*USING*CP'
ASISUCSC='PCT SINGLE STATE*SAMPLES*USING*ZIIP*ON CP'
ASISUCSP='PCT SINGLE STATE*SAMPLES*USING*ZIIP'
ASITIIP ='ACCUMULATED*ZIIP*TIME'
ASITIIPC='ACCUMULATED*ZIIP*ON CP*TIME'
-Support for new zIIP/zAAP data in RCDG3 segment:
RCDHST ='HIPERSPACE*CPU*TIME'
RCDIFACP='ZAAP*SERVICE*UNITS*ON CP'
RCDIFASU='ZAAP*SERVICE*UNITS'
RCDIFAT ='ZAAP*SERVICE*TIME'
RCDIFCT ='ZAAP*SERVICE*TIME*ON CP'
RCDIIT ='IO*INTERRUPT*CPU*TIME'
RCDRCT ='REGION*CONTRAL*TASK*CPU*TIME'
RCDSUPCP='ZIIP*SERVICE*UNITS*ON CP'
RCDSUPSU='ZIIP*SERVICE*UNITS'
-Support for new zIIP/zAAP data in CPUG3 segment:
CPUIFCOL='ACCUM*ONLINE*ZAAPS'
CPUIFCON='ZAAPS*ONLINE*AT END'
CPULOGIF='ZAAP*LOGICAL*CPU*TIME'
CPULOGZI='ZIIP*LOGICAL*CPU*TIME'
CPUONTIF='ACCUM*ZAAP*ONLINE*TIME'
CPUONTZI='ACCUM*ZIIP*ONLINE*TIME'
CPUPHYIF='ZAAP*PHYSICAL*CPU*TIME'
CPUPHYZI='ZIIP*PHYSICAL*CPU*TIME'
CPUZICOL='ACCUM*ONLINE*ZIIPS'
CPUZICON='ZIIPS*ONLINE*AT END'
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.180 Labels for IFATYPnn now contain IFA, ZIP, and CP text.
VMAC7072 Labels for SMF70Q01-Q11 were misleading, implying the.
Sep 11, 2006 values were cumulative, but they are discrete percents
when In-Ready WAS N+1, rather than In-Ready LE N+1.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 24.179 Cosmetic. Labels for HSM datasets HSMWWFSR and HSMWWVOL
VMACHSM were not propagated in their _Sdddddd dataset sort macro.
Sep 11, 2006
Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM.
Change 24.178 Support for IRRHFSU unload utility; Unix System Services
EXRAC900 for z/OS file-permissions are a "IRRDBU00-format" RACF
EXRAC901 0900-0903 records. While these new records contain only
EXRAC902 ASCII data, and the IRRDBU00 records contain only EBCDIC,
EXRAC903 this implementation supports either file or concatenation
IMACRACF of both record types, and can be executed under ASCII or
VMACRACF EBCDIC SAS systems. New datasets created are these:
VMXGINIT dddddd Dataset Description
Sep 10, 2006 RAC900 RACF0900 USS RACF BASIC RECORD
Sep 26, 2006 RAC901 RACF0901 USS RACF FILE ACCESS
RAC902 RACF0902 USS RACF DEFAULT ACCESS
RAC903 RACF0903 USS RACF DIRECTORY DEFAULT ACCESS
-Sep 26 Variables RECNR/RECTYPE added to RAC09xx datasets.
Variables GRNAME GRMEMBAL INTRNVOL input length expanded.
Variable ATTRIBS created for RACF0200
Variable TYPE0901 rename GRPORUSR.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Aimee Steel, Euroclear, BELGIUM.
Change 24.177 DB2 Statistics ID=100 SUBTYPE=0 caused INPUT EXCEEDED if
VMACDB2 there is more than one QLST segment, and LENQLST=0 in the
Sep 8, 2006 triplets, which is IBM's new way to read the length field
at the OFFQLST offset. But this record is in error; its
length field contains 176, when the actual segment length
is 178 bytes; this LENxxxx field does not contain itself,
but in all other LENxxxx=0 segments, the length at the
OFFxxxx contains the 2 byte of that field. Circumvention
code was added to protect the QLST segment for the
unexpected (incorrect?) length field value.
Thanks to Ray Dunn, CIGNA, USA.
Change 24.176 DB2 Statistics variable QISTRHIG was incorrectly DIF()'d;
VMACDB2 it is a maximum value, and is not accumulated, so that
Sep 8, 2006 variable is no longer deaccumulated.
Thanks to Steve Morris, State of Ohio BWC, USA.
Change 24.175 For PDB.ASUMTAPE with STATUS='TY21ONLY', the DSNAME field
ASUMTAPE should be blank, but it was populated with a DSNAME from
Sep 7, 2006 a prior job. Now, it will be blank as expected.
Thanks to Geoges Rondeau, Amicam, FRANCE.
Change 24.174 The new Release 4.3 fields, including NDMCPU and NDMRIP
VMACNDM were incorrectly INPUT due to undocumented alignment data
Sep 7, 2006 bytes in the record. See Change 24.182.
Thanks to Rob Hollingum, HSBC, ENGLAND.
Thanks to David Kaplan, Depository Trust & Clearing Corporation, USA.
Change 24.173 Documentation only. IBM VMA product incorrectly decoded
IMACACCT SMF ACCOUNTn fields that contained an underscore. APAR
Sep 6, 2006 OA17684 list the ACCOUNTn characters they consider valid:
Letters A thru Z, numbers 0 thru 9, space, period, dollar
sign, asterisk, dash, slash, comma, at-sign, pound-sign
(a/k/a hash mark), equal sign, and now, with that APAR,
an underscore.
Change 24.172 Using %UTILBLDP with EXPDBOUT= that has a %INCLUDE caused
UTILBLDP a syntax error if the output was directly executed; there
Sep 6, 2006 was no error with the output, so running it as a two-step
build-and-then-execute circumvented. See Change 24.190.
Thanks to Robert Carballo, Office Depot, USA.
Change 24.171 CopyCross+HSC caused MXGTMNT Tape Mount Monitor to stop
ASMHSCEX writing SMF records. Apparently, CopyCross alters the
Sep 4, 2006 JFCB, which we use to get the DSNAME of the tape mount,
and apparently the JFCB address in the TIOT is not valid;
MXGTMNT took five internal S0B0 ABENDS, the error from
the IBM service that reads data from SWA (IEFQMREQ) when
the data we've pointed to is not in SWA, and assumed we
had a real problem, and turned the monitor off.
We know that HSC mounts do not go thru the IBM Volume
Mount Exit; we assume in the HSC exit that if we didn't
see it in the IBM exit that it must be HSC controlled,
so we were seeing the CopyCross mounts in the HSC exit.
There doesn't seem to be a way to identify these mounts
as CopyCross, but "asmguy" as figured a way to obtain the
DSNAME so that the abend won't occur, and thus MXGTMNT
will now capture the CopyCross mounts thru HSC exit.
Thanks to Brian Felix, Wachovia Corporation, USA.
Change 24.170 A debugging PUT statement at line 664: IF SMF14TY NOT ...
VMAC1415 is deleted. It was also truncated and had no semi-colon,
Sep 1, 2006 which caused NO MATCHING IF error in TESTIBM in JCLTEST.
Thanks to Bernd Klawa, Stadtwerke Bielefeld, GERMANY.
Change 24.169 Format $MGTMDAC was not built, and $MGTIVSA was wrong;
FORMATS the semi-colon to end the $MGTIVSA format was missing.
Aug 31, 2006 Inserting the semicolon corrected both formats.
Thanks to Nick Johns, Sainsbury's Supermarkets LTD, ENGLAND.
Change 24.168 Variable CPUTYPE was blank in PDB.ASUMCEC (because the
VMXG70PR HOLD7CPT temp variable was not in the RETAIN statement).
Aug 31, 2006 Fortunately, variable CPFCNAME='2084-308' does have the
CPUTYPE in character, but CPUTYPE is now corrected.
Thanks to Curdin Salis Gross, Credit Suisse, SWITZERLAND.
Change 24.167 Support for MEMORY object with NRDATA=35 caused message
VMACNTSM KNOWN MEM OBJECT UNEXPECTED NRDATA/NRNAMES. DELETED
Aug 31, 2006 and MXG skipped the record. NRDATA=35 is now supported.
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 24.166 Support for BMC Mainview for CICS Optional DB2 and CMR.
IMACICDA -The existing IMACICMR for the CMRDATA segment was updated
IMACICMR with four new pairs of counts/times variables for ADABAS,
IMACICMD DATACOM, IDMS, and MQSeries.
UTILEXCL -The optional CMRDB2 data enabled by BMC BBSAMP CMR$2MCTs
VMAC110 is supported in IMACICMD optional member.
Aug 31, 2006 -UTILEXCL was updated to support the CMRDB2 segment and
Nov 7, 2006 the eight new variables in the CMRDATA segment.
-IMACICDA, used only for non-UTILEXCL segment processing
was updated to add the include for IMACICMD after the
existing IMACICMR, an assumed order that may need to be
reversed, if you don't use UTILEXCL.
-Unrelatedly, variables in Change 24.140 were still in the
FORMAT statement, causing UNITIALIZED VARIABLE ARZGEOS
(harmless), but they are now removed in VMAC110.
Thanks to Jane Dickenson, Santander Produban UK, ENGLAND.
====== Changes thru 24.165 were in MXG 24.06 dated Aug 30, 2006=========
Change 24.165 Variables CPUIFATM and CPUZIPTM are added to TRNDSMFI.
TRNDSMFI
Aug 29, 2006
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 24.164 IMACJBCK (the JOB-check exit for selection of SMF records
VMAC6 by JOB/READTIME/SYSTEM/etc.), for SMF 6 and 26 records,
VMAC26J2 was called before the JESNR had been INPUT. The %INCLUDE
VMAC26J3 was moved until after JESNR has been created, so it can
Aug 28, 2006 be used for selection, as documented in IMACJBCK.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 24.163 Support for z9EC processors. MXG 23.09+ supported 64-bit
FORMATS z/OS on z9 and z9EC; this change is required ONLY if you
Aug 27, 2006 are using a 32-bit z/OS (See Change 24.110 for impact).
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 24.162 Support for NTSMF Version 3.0.0, new objects & variables.
EXNTARMA -Dataset SYSTEM new variable:
EXNTARMP RDYTHPER='READY*THREADS*PER*PROCESSOR'
EXNTASPA -Dataset MEMORY new variables:
EXNTASPN PCTAVLBY='PCT*AVAILABLE*BYTES'
EXNTASPS VTORATIO='V TO R*RATIO'
EXNTCCMQ -Dataset NETWINTR new variable
EXNTCIPS PCTNETBY='PCT*NETWORK*UTILIZATION'
EXNTIPV6 -Dataset DTSCPU new variables
EXNTNECD DTCPNCOS='SUPPORTED*CORES'
EXNTNECE DTCPNCOA='ACTIVE*CORES'
EXNTNECI -Dataset BLKBERRY has new instance variable, if there is
EXNTNECJ more than one blackberry server:
EXNTNECL BLKBINST='INSTANCE*NAME*FOR*ANTIGEN SCAN'
NOTE: SEE CHANGE 24.015 for INCOMPATIBILITY note.
EXNTNECM -Datasets MSQBUFMG and SQLBUFMG no longer populate the
EXNTNECR variable CACHSIZE, although it will continue to exist
EXNTNECS in MXG with a missing value.
EXNTNECT -Dataset MSQGENST and SQLGENST new variables:
EXNTPSPI ACTMPTBL='ACTIVE TEMP TABLES'
EXNTSAAL TMTACRDT='TEMP TABLES CREATION RATE'
EXNTSAJO LOGLCONN='LOGICAL CONNECTIONS'
EXNTSAJS TRANSACT='TRANSACTIONS'
EXNTSAST NATOMYRT='NON-ATOMIC YIELD RATE'
EXNTSQBA MARSDEAD='MARS DEADLOCKS'
EXNTSQBN HTTPAURQ='HTTP AUTHENTICATED REQUESTS'
EXNTSQBR SOAPMTRQ='SOAP EMPTY REQUESTS'
EXNTSQBS SOAPSQRQ='SOAP SQL REQUESTS'
EXNTSQCA SOAPMEIN='SOAP METHOD INVOCATIONS'
EXNTSQCL SOAPWSRQ='SOAP WSDL REQUESTS'
EXNTSQCT SOAPSEIR='SOAP SESSION INITIATE REQUESTS'
EXNTSQCY SOAPSETR='SOAP SESSION TERMINATE REQUESTS'
EXNTSQES PROCBLKD='PROCESSES BLOCKED'
EXNTSQPC TMTADEST='TEMP TABLES FOR DESTRUCTION'
EXNTSQSP EVNODLDR='EVENT NOTIFICATIONS DELAYED DROP'
EXNTSQSR TREVBIQU='TRACE EVENT NOTIFICATION QUEUE'
EXNTSQST SQTRPRLW='SQL TRACE IO PROVIDER LOCK WAITS'
EXNTSQWS -Dataset MSQLOCKS and SQLLOCK new variable:
EXNTTCV6 LOKTIMEO='LOCK*TIMEOUTS'
EXNTUDV6 -Dataset MSQLATCH and SQLLATCH new variables
IMACNTSM SUPRLACN='NUMBER OF*SUPERLATCHES'
VMACNTSM SUPRPRRT='SUPERLATCH*PROMOTIONS*PER SEC'
VMXGINIT SUPRDERT='SUPERLATCH*DEMOTIONS*PER SEC'
Aug 26, 2006 -Dataset MSQACCES and SQLACCES new variables
DEDRROST='DEFERRED DROPPED ROWSETS'
DRROCLRT='DROPPED ROWSET CLEANUPS/SEC'
DRROSKRT='DROPPED ROWSETS SKIPPED/SEC'
DEDRAUS ='DEFERRED DROPPED AUS'
AUCLUPRT='AU CLEANUPS/SEC'
AUCLBART='AU CLEANUP BATCHES/SEC'
FACLBART='FAILED AU CLEANUP BATCHES/SEC'
USTRPACO='USED TREE PAGE COOKIE'
FATRPACO='FAILED TREE PAGE COOKIE'
USLEPACO='USED LEAF PAGE COOKIE'
FALEPACO='FAILED LEAF PAGE COOKIE'
LOPRCRCN='LOBSS PROVIDER CREATE COUNT'
LOPRDECN='LOBSS PROVIDER DESTROY COUNT'
LOPRTRCN='LOBSS PROVIDER TRUNCATION COUNT'
LOBHCRCN='LOBHANDLE CREATE COUNT'
LOBHDECN='LOBHANDLE DESTROY COUNT'
BYLOCRCN='BY-REFERENCE LOB CREATE COUNT'
BYLOUSCN='BY-REFERENCE LOB USE COUNT'
PUOFROCN='COUNT PUSH OFF ROW'
PUINROCN='COUNT PULL IN ROW'
LOREAHCN='COUNT LOB READAHEAD'
-Dataset MSQSTATS and SQLSTATS new variables:
FRCPRMRT='FORCED*PARAMETERIZATIONS*PER SEC'
SQLATTRT='SQL*ATTENTION*RATE'
-And support for these 37 new objects:
DDDDDD DATASET OBJECT
NTARMA ASPNET ARMTECH APPLICATION
NTARMP ASPNETAP ARMTECH PROCESS
NTASPN ASPNET ASP.NET
NTASPA ASPNETAP ASP.NET APPLICATIONS
NTASPS ASPNETSS ASP.NETSTATESERVICE
NTCCMQ CCMSGQUE CCM MESSAGE QUEUE
NTCIPS CITRIXPS CITRIX METAFRAME PRESENTATION SERVER
NTNECD NETCLRDT .NET CLR DATA
NTNECI NETCLRIN .NET CLR INTEROP
NTNECJ NETCLRJI .NET CLR JIT
NTNECL NETCLRLO .NET CLR LOADING
NTNECT NETCLRLK .NET CLR LOCKSANDTHREADS
NTNECM NETCLRME .NET CLR MEMORY
NTNECS NETCLRSE .NET CLR SECURITY
NTNECE NETCLREX .NETCLREXCEPTIONS
NTNECR NETCLRRE .NETCLRREMOTING
NTIPV6 IPV6 NT IPV6
NTSAAL SAALERTS SQLAGENT:ALERTS
NTSAJS SAJOBSTP SQLAGENT:JOBSTEPS
NTSAJO SAJOBS SQLAGENT:JOBS
NTSAST SASTATS SQLAGENT:STATISTICS
NTSQBA SQLBRKAC SQLSERVER:BROKER ACTIVATION
NTSQBN SQLBUFND SQLSERVER:BUFFER NODE
NTSQBR SQLBRDBM SQLSERVER:BROKER/DBM TRANSPORT
NTSQBS SQLBRSTA SQLSERVER:BROKER STATISTICS
NTSQCA SQLCATMD SQLSERVER:CATALOG METADATA
NTSQCL SQLCLR SQLSERVER:CLR
NTSQCT SQLCURTO SQLSERVER:CURSOR MANAGER TOTAL
NTSQCY SQLCURTY SQLSERVER:CURSOR MANAGER BY TYPE
NTSQES SQLEXECS SQLSERVER:EXEC STATISTICS
NTSQPC SQLPLNCA SQLSERVER:PLAN CACHE
NTSQSR SQLSQLER SQLSERVER:SQL ERRORS
NTSQSP SQLSPIPE SQLSERVER:SSIS PIPELINE
NTSQST SQLTRANS SQLSERVER:TRANSACTIONS
NTSQWS SQLWAITS SQLSERVER:WAIT STATISTICS
NTTCV6 TCPV6 NT TCPV6
NTUDV6 UDPV6 NT UDPV6
-The _UNTDISC logic to recognize new DISCOVERY record was
revised to protect multiple systems (data with very old
and new NTSMF interleaved caused variable DISCOVRY to not
always be incremented; now, it will always be, but it can
skip a value, which is ok, as it is only for grouping).
-NTCONFIG dataset variable SUMRYVER could be incorrectly
carried forward if you have new and then old NTSMF data.
Thanks to Jim Quigley, CONED, USA.
Change 24.161 Support for i/Series QACS/QAPM AS/400 Release 5.4.0, is
VMACQACS INCOMPATIBLE, because when new data is added, the LRECL
Aug 26, 2006 in your JCL/FILENAME must be changed to read the new data
records. The comments in VMACQACS list the new LRECLs:
File LRECL Change
QAPMDISK 376 +3
QAPMJOBL 1116 +31
QAPMJOBM 542 +31
QAPMLPAR 172 +92
QAPMPOLB 83 +5
QAPMSYSL 3367 +23
QAPMSYST 555 +20
-Dataset QAPMCONF supports GKEY='21' to create new vars:
GDES21 ='GDES21*ASP*CAPACITY*IN*BYTES'
New GDKEYs 'B1' thru 'B5' create GDESB1N-GDESB5N numeric
and GDESB1C-GDESB5C character variables, awaiting doc to
properly label them.
-Dataset QAPMDISK new variables:
DSRDT ='RAID TYPE?*0=RAID 5*1=RAID 6'
DSIOPF ='MANAGED*BY IOP?*0=NO*1=YES'
DSCAT ='DISK*UNIT*CATEGORY?*0=NO*1=EXTERNAL'
-Dataset QAPMJOBM and QAPMJOBL new variables:
JBACPU ='ACCUMULATED*JOB CPU*TIME'
JBIPAF ='IP TYPE*02X=IPV4*18X=IPV6'
JBIPAD ='IP ADDRESS BINARY'
JBIPPT ='IP PORT*NUMBER'
-Dataset QAPMSYS and QAPMSYSL and QAPMSYST new variables:
SYVCPU ='VIRTUAL*PROCESSOR*TIME*CONFIGURED'
SYDPCH ='TOTAL*DISPATCH*TIME'
SYSHRF ='SHARED*PROCESSOR*FLAG 0=NO*1=YES'
-Dataset QAPMPOLB new variables:
POUNAL ='UNALLOCATED*POOL*SPACE'
-Dataset QAPMSYSL variables previously overlooked:
SYNUAL SYIFTA SYSPTU SYCTA SYUTA SYNUTC SYNPLU SYNPLA
-Dataset QAPMLPAR new variables decoded, but not yet
tested with data.
LPDDTM ='DATETIME*WHEN DISK*DATA WAS*COLLECTED'
LPCAP ='TOTAL*DISK*CAPACITY'
LPAVL ='TOTAL*DISK*CAPACITY*AVAILABLE'
LPBSY ='DISK*BUSY*TIME'
LPRSP ='DISK*RESPONSE*TIME'
LPRDS ='DISK*READ*COMMANDS'
LPWRTS ='DISK*WRITE*COMMANDS'
LPDISK ='NUMBER OF*SELECTED*DISKS'
LPMEM ='TOTAL*MEMORY*IN SYSTEM'
Thanks to Jim Wertenberger, Antares Management Solutions, USA.
Thanks to Tim Follen, Antares Management Solutions, USA.
Change 24.160 -NDMCPUTM could still be wrong, if the NDMLENPA/NDMLENSA
VMACNDM field lengths were more than the arbitrary $VARYING48 I
Aug 25, 2006 chose, thinking ACCT data would be an MVS 44-byte account
field, but the "ACCT" data is text. With lengths of 89
I arbitrarily increased the length to 256 bytes, but,
more importantly, longer lengths are protected.
-The INPUT for NDMCPUTM itself was revised to validate
that CPUTIME= text exists immediately prior to the INPUT
location.
-Code was revised to be independent of the order of the
four optional segments (SVOL,PVOL,SACCT,PACCT).
-NDMOFF43 and NDMLEN43 logic was removed, as the segment
is always present in current NDM-Connect Direct records.
-Some CT records contain nonzero NDMCTDOF (*P.DTOTAL) that
is the offset to an 80-byte "TOTALS (IF RESTARTED)" area,
from which I create NDMTOT01-NDMTOT20 variables, pending
finding documentation of what these totals are.
-Invalid date/times in 'MC' record is under investigation.
Thanks to David Kaplan, Depository Trust & Clearing Corporation, USA.
Change 24.159 Support added for CICS Statistics Intervals option values
VMXGCICI of TWOHOUR, FOURHOUR, and EIGHTHR.
Aug 25, 2006
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.158 Attempting to use MACRO _VTY30UV to DROP variables caused
EXPDB30V ERROR: VARIABLE EXCP2305 NOT FOUND; you cannot use that
Aug 23, 2006 macro to drop variables from PDB.SMFINTRV. Furthermore,
you must use BUILDPDB, BUILDPD3, or ONLINTV to create the
PDB.SMFINTRV dataset, as only those programs have logic
that combines the MULTIDD='Y' observations into a single
PDB.SMFINTRV observation; while %INCLUDE of TYPS30 does
create a dataset named PDB.SMFINTRV, that dataset will
still have multiple MULTIDD='Y' observations.
But, you can instead use the EXPDB30V exit member and use
a DROP statement to drop variables from the summarized
PDB.SMFINTRV dataset.
Thanks to Colin Bowen, CSC, SOUTH AFRICA.
Change 24.157 Analysis example to identify all jobs/STCs that allocated
ANALDEVN a DEVNR range or a DEVICE types, by creating only the
Aug 23, 2006 TYPE30_D dataset for selected DEVNR/DEVICEes.
Thanks to Yaohua Hu, ISO, USA.
Change 24.156 Corrections to reported ANALDB2 errors/omissions:
ANALDB2R -"STMT #: 4040 was printed instead of the correct 16448
Aug 21, 2006 for the statement number.
Thanks to ???, ???, ???
Change 24.155 The CICSBAD dataset added by Change 23.312 could contain
EXCICBAD legitimate transactions; the test for PROGRAM='########'
Aug 21, 2006 previously identified invalid CICS transaction names that
Sep 27, 2007 did not have a program name (i.e., typo'd TRANNAME).
However, some sites have chosen to use ######## to make
their transaction routing easier, which caused millions
of transactions to be output to CICSBAD, when this site
wanted them output to CICSTRAN. MXG's test for EXCICBAD
IF PROGRAM='########' OR
SUBSTR(TRANFLAG,6,1)='......1.'B THEN DO;
will %INCLUDE the EXCICBAD exit, so you can tailor the
code in your EXCICBAD member to decide which, if any,
transactions are output to CICSBAD or to CICSTRAN.
In this particular case, the site observed that all of
their TOR regions' transactions had PROGRAM='########',
but they also all had RSYSID NE '00000000'X, so the site
could use this logic in their EXCICBAD tailoring member:
IF PROGRAM='########' AND RSYSID NE '00000000'X THEN DO;
OUTPUT _WCICTRN;
END;
ELSE DO;
OUTPUT _WCICBAD;
END;
to output real bad to CICSBAD and the rest to CICSTRAN.
Sep 27, 2007:
-And if you DON'T want CICSBAD to be created, but instead
want these "bad" transactions output in CICSTRAN, you can
copy EXCICBAD into your tailoring library and change
_WCICBAD to _WCICTRN.
-And what about that bit test that sends transactions to
CICSBAD instead of CICSTRAN, that test for:
SUBSTR(TRANFLAG,6,1)='......1.'B THEN DO;
It was obscurely documented back in Change xx.yyy:
"When a CICS task is executing on an OPEN TCB, and is
then purged, APAR PQ86971 documents that all of the
clocks are invalid when this happens, and that APAR
adds a new bit to the TRANFLAG field to identify these
tasks. Since the clock values are all wrong, these
transactions are now also output in CICSBAD instead of
CICSTRAN."
There are 3 normal ways to terminate a CICS task, all
using a CEMT SET TASK command or CEKL SET TASK command:
1) Purge this is what is normally called a cancel.
The task is terminated. Task termination occurs
only when system and data integrity can be
maintained.
2)Forcepurge this is what is normally called a purge.
The task is terminated immediately. System integrity
is not guaranteed.
3)Kill has more option then a Forcepurge but seems to
have the same effect.
Both Forcepurge and Kill may crash the CICS region.
Kill may free up a stall CICS region.
Change 24.154 -ERROR: VARIABLE THREADTY NOT FOUND if both DB2ACCT and
ANALDB2R ASUMDB2A existed in the "PDB" with PMACC03/PMACC04=YES.
Aug 18, 2006 The PMACC03 and PMACC04 reports require detail data, but
the logic incorrectly used ASUMDB2A.
-In addition, references to ASUMDB2P dataset are commented
out, as that dataset does not (yet?) exist.
Thanks to Steve Olmstead, Northwestern Mutual Company, USA.
Change 24.153 Support for EMC's Centera Mainframe HSM Migrator user SMF
EXCMHMEV records. New CMHMEVNT dataset for each recall or migrate
IMACAAAA with start, end, and elapsed duration, dataset size, and
IMACCMHM attributes of the dataset.
TYPECMHM This support is preliminary, as both the contents of the
VMACCMHM new SMF record, and how MXG handles the data, may be
VMXGINIT changed when user's get their hands on the new product
Aug 18, 2006 and its SMF data.
Change 24.152 SMF 80 INPUT STATEMENT EXCEEDED RECORD LENGTH because MXG
VMAC80A did not protect $VARYINGnn lenmm for the case when lenmm
Aug 18, 2006 was greater than nn. While many RACF fields have a true
Oct 13, 2006 maximum nn (like 44 for DSNAMEs), some fields were INPUT
with $VARYING200. because no max was known or documented.
And 200 was used because SAS V6 was limited to 200 bytes
for character variables. But MXG no longer executes with
SAS V6, so all of the $VARYING200. are now $VARYING255,
and they are all protected if the text exceeds 255, with
a message and hex dump on the log printed if the length
exceeds MXG's expectation. Fields protected: RACF263,
RACF295, RACF298, TOKDANAM TOKHOME, TOKPROG, and TOKLDAP.
This was tested in Aug, but VMAC80A was not updated until
October.
Thanks to Kim Nguyen, National Australia Bank, AUSTRALIA.
Change 24.151 The _VMINPUT macro, to read z/VM MONWRITE data converted
VMACVMXA from it's native RECFM=U to RECFM=VB, did not include the
Aug 18, 2006 IMACVMXA member nor execute the &MACVMXA macro variable.
Thanks to Steven Clark, DHL, USA.
Change 24.150 Typo in the KEEP= list for dataset HURN49, and the label
VMACHURN statement had HU47BJOB and HU47BSTP, instead of correct
Aug 17, 2006 names of HU49BJOB and HU49BSTP, added by Change 20.248.
Thanks to Colin Bowen, CSC Computer Sciences, SOUTH AFRICA.
Change 24.149 -New variables in VTCS Subtype 15 are now decoded:
VMACSTC STC15CTP='*S-CART*OR*E-CART?'
Aug 17, 2006 STC15LRI='HSTRESIDENCY*RECALL OR*CREATE?'
Aug 21, 2006 -The _VSTCV13 keep list now keeps STC13MRC instead
of STC15MRC.
Rudolf Sauer, T-Systems, GERMANY.
Change 24.148 Variable DATECLN was not converted from the raw record's
VMACTMS5 cyyddd format, so the julian date of 2004241 printed as
Aug 17, 2006 104241. Now, like other TMS dates, DATECLN is converted
to yyyyddd format.
And if you need to see that as a "real date", you can
use CLNDATE=DATEJUL(DATECLN);
FORMAT CLNDATE DATE9.;
and see that 2004241 julian was 28AUG2004.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 24.147 -Variable JBAFF in dataset TPMJBAFF was blank when it
VMACTPMX should have been populated, and populated when it should
Aug 16, 2006 not have been; the IF test missing the NOT now is coded:
IF SYSAFF NOT = : TPMXTEST THEN SYSAFF=' ';
NOTEBENE: THIS AUG CHANGE WAS WRONG, THE NOT DOES NOT
BELONG, AND THE CODE WAS CORRECTED IN CHANGE 24.199.
The two FORMATS in your IMACTPMX must match your SYSPLEX
and AFFINITY systems, for JBAFF to be correct. The MXG
logic was originally correct, and now is after Oct 5.
-Variables UMANUAL, UME, UMB now all contain "MANUAL" in
their labels.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 24.146 The TRANSLATE(TRANSACT,' ','00'x) statement was relocated
VMACTMO2 so both TRANNAME and TRANSACT have those nonprintable
Aug 15, 2006 characters changed to blanks. TRANSACT was named from
the Landmark DSECT when TYPEMONI was written, but now,
with hindsight, I should have use TRANNAME as the name
for all Transaction Names. TRANNAME was added to the
MONITASK dataset because CICSTRAN users expected it when
they switched to TMON for CICS.
Thanks to Salis Gross Kurdin, Credit-Suisse, SWITZERLAND.
Change 24.145 Support for optional PRPRTYPE='9901' User Log Record in
VMACPRPR Oce's Prisma Print product log records creates new
VMXGINIT dataset PR9901 with variable PRPR9901 containing all of
EXPR9901 the text after ACCOUNT, and variable LEN9901 has the
IMACPRPR length of that text.
Aug 15, 2006
Thanks to Engelbert Smets, Provinzial, GERMANY.
Change 24.144 Reading NDM Log records (instead of SMF format), record
VMACNDM NDMRTYPE='RJ' caused INPUT STATEMENT EXCEEDED record
VMACSMF error; the OFFTODSN,OFFPACCT,OFFRSACCT offsets did not
Aug 16, 2006 include +OFFSMF in their calculation (for normal dumped
SMF records, OFFSMF=0, so the logic error was missed,
until the log-format records were read.
-NDM Logs with a single 13-byte '***NO DATA***' record are
now detected and deleted in the _LOGSMF macro defined in
VMACSMF, but only used by TYPENDML to read //LOGSMF DD.
-NDMCPUTM could be wrong and very large, when the VLR data
section was after the VLS data section, because MXG code
expected VLR first; now, the INPUT is reset correctly no
matter which order the segments are found.
Note: Change 24.160 corrected NDMCPUTM.
-Support for new variables that were added by 4.3 to the
NDMCT dataset:
NDMCKPI ='CHECKPOINT*INTERVAL'
NDMCPU ='CPU TIME*OF STEP*VIA*TIMEUSED'
NDMDBPAD='DBCS*PAD*CHAR'
NDMDBSI ='DBCS*SHIFT-IN*CHAR'
NDMDBSO ='DBCS*SHIFT-OUT*CHAR'
NDMDBTAB='DBCS*TABLE*NAME'
NDMRIPCH='INBOUND*OUTBOUND*IP ADDRESS'
NDMRPOR ='OUTBOUND*PORT'
In my small number of test records, the new NDMCPU
CPU time was zero, and NDMCPUTM was always missing.
Further investigation is needed. See Change 24.182.
-Perhaps support for 4.5. There is a bit flag in the DMRCT
DSECT for new fields added in 4.5, but there are no new
data fields described in that DSECT, so I believe this is
all that is required to support NDM/Connect Direct 4.5.
Thanks to Rob Hollingum, HSBC, ENGLAND.
Change 24.143 Format MGPLOT is added to FORMATS; it is used in ANALDB2R
FORMATS to generate text lines for some reports.
Aug 11, 2006
Change 24.142 -PDB.TYPE70 variables SMF70Q00-SMF70Q12 values were wrong,
VMAC7072 because they were missing the factor of 100 to convert to
Aug 11, 2006 percentages, and their labels, starting with SMF70Q04 had
the wrong +n values in the N+n part of the label. Correct
labels are belos (e.g., SMF70Q08 is the percentage of
time when the number of IN-AND-READY ASIDs was between
21 and 30 larger than the number of CPUs that were online
to this z/OS system when this sample was taken):
SMF70Q00='PERCENT*WHEN*IN READY*LE N CP-S'
SMF70Q01='PERCENT*WHEN*IN READY*LE N+1 CP-S'
SMF70Q02='PERCENT*WHEN*IN READY*LE N+2 CP-S'
SMF70Q03='PERCENT*WHEN*IN READY*LE N+3 CP-S'
SMF70Q04='PERCENT*WHEN*IN READY*LE N+4-5 CP-S'
SMF70Q05='PERCENT*WHEN*IN READY*LE N+6-10 CP-S'
SMF70Q06='PERCENT*WHEN*IN READY*LE N+11-15 CP-S'
SMF70Q07='PERCENT*WHEN*IN READY*LE N+16-20 CP-S'
SMF70Q08='PERCENT*WHEN*IN READY*LE N+21-30 CP-S'
SMF70Q09='PERCENT*WHEN*IN READY*LE N+31-40 CP-S'
SMF70Q10='PERCENT*WHEN*IN READY*LE N+41-60 CP-S'
SMF70Q11='PERCENT*WHEN*IN READY*LE N+61-80 CP-S'
SMF70Q12='PERCENT*WHEN*IN READY*GT N+80 CP-S'
-PDB.TYPE70 PCTRDYWT, the percentage of time there were
more READY asids than NRCPUS (used to estimate latent
demand), is calculated from the READY00-READY15 variables
summing READYnn's for nn's GE NRCPU, but there are only
14 READYnn buckets, so PCTRDYWT will always be missing
when NRCPUS is more than 14 in your SYSTEM.
-New variable PCTRDQWT may be used in place of PCTRDYWT,
as it's upper bucket is 80 ASIDs more than your NRCPUS,
and is quite easily calculated directly using
PCTRDQWT=100-SMF70Q00;
but PCTRDQWT is counting the IN-and-READY users, whereas
the PCTRDYWT was counting the READY ASIDs.
-PDB.TYPE70 labels for all of the READYnn variables are
corrected to "READY" instead of "IN READY", and
READY15 ='PERCENT*WHEN 15*OR MORE*READY'
is now that label.
-Observations were output in PDB.TYPE70PR for spare IFAs,
but my intention was not to output any spare segments, so
the test "OR SMF70CIN NE 'CP'" was removed, and now,
only if SMF70ONT NE 0 OR LPARNAME='PHYSICAL' will the
segment be OUTPUT in PDB.TYPE70PR.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Andrew Hebden, Barclay's, ENGLAND.
Change 24.141 Processing of DB2 data written to GTF was inconsistent,
UDB2GTF sometimes failed completely, or sometimes skipped data.
UDB2GTFA -The MXG utility UDB2GTFA, for MXG execution under ASCII
VMACDB2 SAS to convert the 256-byte DB2 GTF records into
Aug 10, 2006 legitimate complete DB2 SMF records from those itty-bitty
pieces, only worked for the first record. Revisions
correct that problem, and added more debugging facilities
to ease validation.
-The UDB2GTF utility for EBCDIC SAS execution was fine;
the only change was to enhance its debugging messages.
-For GTF input, VMACDB2 was resetting OFFSMF back to zero
too early for the 100-1 and 101-1 records, causing the
triplets for QBGN, QTGS, and QLES (DB2STATS) and for
QXPK, QBAC, QTXA (DB2ACCTP only) to be incorrect, which
could cause those variables to either be missing or to
be horiffically wrong, but with no error in either case.
Those triplets are now correctly input with OFFSMF=12 for
GTF, and OFFSMF is now correctly reset only after all of
the triplets have been input.
-For SMF or GTF input, VMACDB2 INPUT the QLES triplet from
the wrong (preceding) location, causing those statistics
variables to be incorrect. The QLExxxxx variables are
now also labeled.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 24.140 Support for optional user-created CICS fields with
IMACICU1 CMODNAME='ARZGEOS',CMODHEAD='FACHG' (IMACICU1) and
IMACICU2 CMODNAME='ARZGS',CMODHEAD='GSACCT' (IMACICU2).
UTILEXCL The UTILEXCL member must be used to create IMACEXCL
VMAC110 and the comment block in each of the IMACICU1/IMACICU2
Aug 9, 2006 members must be EDITED for those variables to exist.
Aug 10, 2006 -On Aug 9, I noticed that these optional variables
MQGETWTM MQGETWCN MQREQS MQWTCBUS MQONTCBU MQREQUS
created by a user-created CMODNAME='MQSeries' segment,
could be kept in CICSTRAN, when they shouldn't have been
(they were in the "compiler faker" block, not used for
optionals). They were removed from the faker block
today, today when John saw them present and wanted to
know why they were all blank; quite timely!
Thanks to Richard Hilber, Allgemeines Rechenzentrum GmbH, AUSTRIA.
Thanks to John Ferguson, Washington Mutual, USA.
Change 24.139 If there were no observations in TYPETALO but SPINTALO
ASUMTALO had observations, a strange syntax error was generated
Aug 8, 2006 about (LOWTIME='141515...'DT) being invalid due to a
PUT statement without DATETIME21.2 format.
(The actual error occurred in ANALCNCR text, but the
call was from ASUMTALO, which needed the correction.)
Thanks to Edward M. Burns, Blue Cross Blue Shield of Nebraska, USA.
Change 24.138 Incorrect inclusion of DB2PARTY='R' Rollup observations
ANALDB2R in creating accounting summary report caused average
Aug 4, 2006 values to be wrong; the R record was counted as a PLAN
(doubling the denominator when there was one execution).
Also, the in-DB2 elapsed time could be larger than total
elapsed time: ELAPSTM is missing in the R record, so the
average elapsed was one half the base record's elapsed
duration eg: ( 4 + 0 )/2 = 2 hr. avg total elapsed.
But both had QWACASC in-DB2-elapsed time which were then
averaged eg: ( 3 + 2 )/2 = 2.5 hr avg in-DB2 elapsed!
Clearly, including the elapsed and in-DB2 time from the
Rollup record, and counting it as a plan, created invalid
average values in the summary reports; now, for Rollups,
the count of plans is not incremented, and QWACASC is set
to zero in the sum, so the average class 2 elapsed in-DB2
time reflects the base transaction(s).
Thanks to Yaohua Hu, Insurance Service Office, USA.
Thanks to Issac Lukach, Insurance Service Office, USA.
Change 24.137 MXG Variable PRODUCT in the PDB.TYPE70 dataset identifies
VMACSMF "RMF" or "CMF=." as the creator of the 70-79 SMF records.
Aug 3, 2006 To identify CMF from RMF records in case both are being
created, you could test PRODUCT=:'CMF' in each of the
EXTY7xxx exit members, but you can alternatively use this
logic to input the RMF Product Segment header and skip
the CMF records:
%LET MACFILE=
%QUOTE(
IF 70 LE ID LE 78 THEN DO;
INPUT @25+OFFSMF OFFRMFP &PIB.4. /*SMF70PRS*/
@29+OFFSMF LENRMFP &PIB.2. /*SMF70PRL*/
@31+OFFSMF NRRMFP &PIB.2. /*SMF70PRN*/
@;
OFFRMFP=OFFRMFP-3+OFFSMF;
INPUT @OFFRMFP+28 SMF70RV6 &PIB.2. @;
IF SMF70RV6='........1.......'B THEN
PRODUCT='CMF-CPM';
ELSE IF SMF70RV6='.........1......'B THEN
PRODUCT='CMF-IPM';
IF PRODUCT=:'CMF' THEN DELETE;
END;
);
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 24.136 When DB2 V8 option UIFCIDS=YES is used, many text fields
VMACDB2 in DB2 SMF records that used to contain EBCDIC characters
VMACDB2H will instead contain ASCII text, which, when INPUT by MXG
Aug 4, 2006 with $EBCDICnn INFORMAT, creates unprintable text data.
IBM puts %U in the DSECTS for these ASCII fields, and
in DSNDQWHS %U is described as UniCode UTF-8, but UTF-8
is just simple ASCII text. A few fields with ASCII text
were already supported in MXG, but with UIFCIDS=YES on,
all of these variables were found to contain ASCII text:
%U Header variables QWHCAID QWHCOPID
%U Package variables QPACCOLN QPACLOCN QPACPKID
%U Location variables QLACLOCN QLSTLOCN
%U in DSNDQMDA only QMDALOCN
%U nowhere, but ASCII: QWACNID
Except for QWACNID, all above have %U in their DSECT and
have offsets to their 128-byte extended area, so they now
must be increased to LENGTH $128. QWACNID was found with
ASCII text, but it is not listed as %U in DSNDQWAC nor
DSNDWMSG, and it has no extended area documented, so it
remains unchanged at LENGTH $16.
IBM sets QWHSFLAG='80'x if the %U fields contain Unicode,
and MXG sets variable DB2UNICD='Y' (now kept in DB2ACCT
and DB2ACCTP) to conditionally INPUT these fields as
EBCDIC or ASCII, so the resultant variable will always
contain printable characters.
While these %U variables must be LENGTH $128, MXG's sets
COMPRESS=YES to compress out those blanks, and so there
should not be any increase in disk space required.
This change supports all of the %U fields in the SMF 100
(Statistics) and SMF 101 (Accounting) records, and in the
DB2 Header for all DB2 SMF records, but there are many
other %U fields in the DB2 Trace IFCIDS that are written
in SMF 102 records; these will also eventually be fixed,
initially on an I-have-this-trash-in-this-IFCID basis.
Thanks to John Hammond, Texas State Comptroller of Public Accts, USA.
Change 24.135 XAM variables from the MTRSYS segment, starting with the
VMACXAM SYSTMID (system) variable were all incorrect; the +2 that
Jul 30, 2006 skip 2 bytes before SYSTMID was INPUT do not exist, and
that statement was removed by this change. These are the
variables that were wrong:
CPUCAPAB CPUCFGCT CPUCFGCX CPUCHAR CPUCOUNT
CPUCOUNX CPUDEDCT CPURESVD CPURESVX CPUSHARD
CPUSTNBX CPUSTNBY DEDCNT IOPCNT LPARCAF
LPARNAME LPNUMBER SCPCAPAB SYSCKVOL SYSMMODL
SYSMPOM SYSMSEQC SYSMTYPE SYSTMID SYSWMVOL
VL3CAF VL3CFGCT VL3COUNT VL3CPNAM VL3DBCT
VL3MNAME VL3RESVD VL3STNBY
Thanks to Mike Salyer, Citigroup Technology Infrastucture, USA.
Thanks to Bob Bates, Citigroup Technology Infrastucture, USA.
Change 24.134 If USEREPRT=COMPAT or USECNTRL=COMPAT was specified, no
VMXGRMFI values were created in any workloads. Change 24.079 had
Jul 30, 2006 removed that option, but a test for this option was left
that caused the deletion of all TYPE72GO obs. Only with
MPRINT turned on was it revealed that the statement
IF SYSTEM NE: 'COMPAT' THEN DELETE; was in the generated
code, so the code assumed that COMPAT was a system name.
Now if COMPAT is specified, and MXGWARN message will be
printed indicating that COMPAT is no longer supported,
and processing then continues.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.133 The IMACKEEP include was relocated so it is now after the
ASUMMIPS macro definitions, so they can be changed. And the MIPS
Jul 30, 2006 factor's comments are revised to now read:
THE MIPS CALCULATION DEFAULT IS A CONSTANT OF 5.8 TIMES MSU.
HOWEVER, THAT IS A SPECIFIC VALUE AT ONE POINT IN TIME FOR
ONE PROCESSOR, AND BY NO MEANS IS THAT A "RECOMMENDED" VALUE.
SINCE 'MIPS' ARE DEFINED BY YOU, AND NOT MXG, YOU CAN USE
WHATEVER VALUE YOU/YOUR-MANAGEMENT DECIDE IS THE APPROPRIATE
CONVERSION FACTOR TO GET MIPS FROM MSU.
THAT'S PRECISELY WHY THE FACTOR IS DEFINED IN THE _MIPSMSU
MACRO, SO YOU CAN CHANGE IT TO YOUR VALUE, AS SHOWN BELOW.
Thanks to Wayne Bell, UniGroup, USA.
Change 24.132 Analysis of DD segment counts was revised to use "new"
ANALDDCN MXG exit facility, instead of the old IEBUPDTE technique
Jul 30, 2006 to tailor the analysis program.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.131 INPUT STATEMENT EXCEEDED RECORD LENGTH error because the
UTILEXCL Omegamon/Candle type 110 dictionary entry is truncated if
Jul 30, 2006 the CMODHEAD field name of the last of their optional
fields is not 8 bytes. The dictionary entry is supposed
to always be fixed (MCTSSDRL=26), but in this case, the
last field name was OMEGDB2 and the last dictionary entry
was only 25 bytes. MXG now tests for the field length
and protects for the invalid dictionary record.
Thanks to Burt.Allen, Harris County ITC, USA.
Change 24.130 Support for Oracle was revised to support only current
VMACORAC versions, so I could eliminate the test for Subsystem.
Jul 22, 2006 Previously, if Subsystem ID changed but MXG's macro was
Dec 19, 2006 not updated, almost all variables were missing. These
ANALORAC pre-V9 variables have always been missing and are now
removed (not KEPT) from the ORACLE dataset:
CPUCICTM CPUSRBTM CPUTCBTM CPUTIMER DDLCOMIT DDLROLLS
ENDSRB ENDTCB ORACMSB PCCOUNT STRTSRB STRTTCB
SWTCHCNT TCBADDR
-Dec 19, 2006: ANALORAC updated to remove references to
the variables that were DROPed.
Thanks to Huug Tempelmans-Plat, CORUS Group, ENGLAND.
Change 24.129 Support for up to 10 CICS ABCODE values in PDB.ASUMUOW.
VMXGUOW The ASUMUOW program logic keeps three sets of ten arrays
Jul 19, 2006 one for transaction name, one for APPLID, one for ABCODE,
which can optionally be kept by adding a KEEP statement
in the TRANUOW macro in your tailored IMACUOW member.
The base variables are TRAN1-TRAN10, PATH1-PATH10, and
new ABEND1-ABEND10.
By default, the first blank ABENDn value is kept in the
ABCODE variable, but you can alter the logic in TRANUOW
as needed.
Thanks to Stan Adriaensen, Axa-Tech, BELGIUM.
Change 24.128 The new ZIP variables from SMF 30s were not kept in the
ASUMDB2A PDB.STEPS and PDB.JOBS variables, but are now added to
BUIL3005 both datasets. And, the DB2ACCT zip variables are now
BUILD005 summarized in ASUMDB2A.
Jul 22, 2006
Thanks to Jim Kovarik, AegonUSA, USA.
Change 24.127 Support for fourth GEPARMKY='4D'x and GEPARMKY='4A'x adds
IMAC6ESS optional variables ESSMAIL5 and ESSMACC1 respectively to
VMAC6 both TYPE6 and TYPE57 datasets. Also, the KEEP= list for
VMAC57 TYPE57 was updated to list all of the possible IMAC6ESS
Jul 19, 2006 variables, which had not been updated since 2004.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Change 24.126 Variables NDMPRCNM NDMPRCNO NDMSTEP NDMUNODE are now kept
VMACNDM in the NDMFI dataset, so that NDMFI can be matched to the
Jul 16, 2006 NDMCT record to obtain the full file name.
Thanks to Mary Lou Arredondo, Federal Reserve, USA.
Change 24.125 ZIP variables were not kept in TYPE72GO dataset; IBM had
VMAC7072 used different names in early and later documentation,
Jul 13, 2006 and I was awaiting a reply as to which set was actually
going to appear in the SMF manual, and I expected their
reply would trigger my revision of names, but no reply
was received, and I forgot to go back and add the names
that I had started with. These are the new variables
that are now kept in TYPE72GO dataset for zip data:
R723NFFS CPUZIETM CPUZIPTM R723CIFA R723CIFC R723CSUC
R723CSUP R723SUCU R723SUPD R723SUPU ZIEUNITS ZIPUNITS
But the error was mine, not IBMs; my ESP contact had said
that because it was "only a documentation/naming query,
that I should not expect a fast reply".
Thanks to Scott Wigg, USBank, USA.
Change 24.124 -Warnings ZDATE and ZTIME in DROP/KEEP/RENAME not being
VMXG70PR referenced for the FINL70LP dataset because the call to
Jul 13, 2006 include IMACZDAT to create them was missing. That also
caused those variables to NOT be populated in ASUM70LP,
and also impacted variable SHIFT.
-All four datasets default output token are now consistent
(all use the _LSUxxxx macro token, which has the same
default value, so this should be a transparent change,
but now the actual output agrees with the revised doc in
the comments.
Thanks to Paul Gillis, Pacific Systems Management Pty., AUSTRALIA
Thanks to Ken Jones, Xwave, CANADA.
Change 24.123 The debugging PROC PRINT DATA=R73HOUR; statement was
VMXGRMFI removed.
Jul 13, 2006
Thanks to Tom Kelman, Commerce Bank - Missouri, USA.
Change 24.122 Variable R85FLGS is now decoded for the TYPE85RQ,TYPE85TP
FORMATS datasets in new R85ST74F,R85ST78F variables by formats
VMAC85 $MG085DM and $MG085TM for optical disk and tape mounts:
Jul 13, 2006 VALUE $MG085DM
'80'X='80X:MOUNT NOT REQUIRED'
'40'X='40X:FLIP DISK REQUIRED'
'20'X='20X:MOUNT ON EMPTY'
'10'X='10X:DISMOUNT REQUIRED'
;
VALUE $MG085TM
'80'X='80X:MOUNT NOT REQUIRED'
'40'X='40X:MOUNT ON EMPTY'
'10'X='10X:ATL TAPE USED'
'20'X='20X:DISMOUNT REQUIRED'
;
Thanks to Betra Reeves, Infocrossing, USA.
Change 24.121 Support for IFCID=350, the SQL statement produced by the
VMAC102 parser written during the bind of dynamic or static SQL;
Jul 7, 2006 this IFCID can be activated with Trace Class 32 for 350.
Jul 13, 2006 The IFCID=350 replaces the IFCID=63 record because the
SQL text in the IFCID=63 record was limited to 5000 bytes
and any additional text was truncated. Instead now, DB2
writes multiple IFCID=350 records with 5000 bytes each if
the SQL text exceeds 5000 bytes.
Thanks to Christian Vandenbossche, Societe Generale, FRANCE.
====== Changes thru 24.120 were in MXG 24.05 dated Jul 3, 2006=========
Change 24.120 Internal utility used only in MXG QA revised to exeute on
UTILVREF ASCII or EBCDIC systems; previously, a manually edited
Jul 2, 2006 version was required to run on ASCII.
Change 24.119 Typos introduced in Change 24.064 had _WKBLD instead of
WEEKBL3D _WEEKBLD for the new datasets, causing 180 syntax errors.
WEEKBL3T
WEEKBLDD
WEEKBLDT
Jul 1, 2006
Thanks to Art Hunter, Penn Mutual, USA.
Change 24.118 The INTERVAL=DURSET default is restored in ASUM70PR, as
VMXG70PR it was in MXG 24.03 and earlier, so PDB.ASUM70PR/ASUM70LP
Jul 1, 2006 will again have the same STARTIME as RMFINTRV when both
have DURSET defaults. I changed the default in MXG 24.04
to QTRHOUR because with DURSET, the ASUMCEC/ASUMCELP
datasets sometimes had wrong STARTIME/SMF70GIE/DURATMs,
but 24.04 was needed for its zIIP engine support. Now,
with the other enhancements in 24.111 to support SYNC59
along with DURSET, VMXG70PR has again been revised so the
original MXG default can be restored safely.
Defaults are: INTERVAL=DURSET,CECINTRV=HOUR.
Change 24.117 Variables IFAUNITS IFEUNITS CPUIFATM and CPUIFETM are now
TRND72GO created in the TREND.TRND72GO dataset.
Jun 30, 2006
Thanks to Stan Dylnicki, Royal Bank of Canada, CANDAD.
Change 24.116 z990/2084 CPUs don't have 'IFA' in LPARNAME='PHYSICAL'
VMAC7072 segments, which caused NRIFACPU count in LPAR datasets
VMXGINIT (TYPE70PR,ASUM70PR,ASUMCEC) to be zero. The IFA variables
Jun 29, 2006 in System datasets TYPE70 and RMFINTRV is fine, because
they count the IFAs assigned to each SYSTEM, but RMF 70s
for z990s do not contain the number of installed IFAs in
your CEC (later hardware/software does). So, if you have
IFAs on z990s, you will have to tell MXG how many IFAs
you have, by setting a text value in new macro variable
with a %LET statement, in IMACKEEP or //SYSIN DD stream:
- If you have the same number of IFA engines in all of
your CECs, then you would use this statement:
%LET CECIFANR= %QUOTE( CECIFANR=1; );
which stores the text "CECIFANR=1;" (which is a SAS
statement to set variable CECIFANR to 1), in the macro
variable &CECIFANR. When executed, CECIFANR=1 causes
MXG to change SMF70CIN='ICF' to SMF70CIN='IFA' in that
many LPARNAME='PHYSICAL' segments in each interval;
these are output in the PDB.TYPE70PR dataset.
- If you have different numbers of IFAs in different CECs
you will need to tell MXG how many IFAs you have on
each of your CECs, by CECSER, using this logic:
%LET CECIFANR =
%QUOTE (
CECIFANR=0;
IF CECSER='ABCD' THEN CECIFANR=1;
ELSE IF CECSER='1234' THEN CECIFANR=2;
);
so that MXG will change 'ICF' to 'IFA' in the correct
number of TYPE70PR observations.
-Once you have created PDB.TYPE70PR with this change,
you can rerun your %INCLUDE SOURCLIB(ASUM70PR) program
to create the corrected ASUM70PR/ASUMCEC/etc summaries.
-VMXGINIT GLOBALs macro variable CECIFANR with blanks.
Thanks to Jan Bigalke, Allianz, GERMANY.
Change 24.115 CICSTRAN variable WTUNIOTM was not kept when UTILEXCL was
UTILEXCL executed; the logic to calculate it was correct, but the
Jun 28, 2006 added code that is needed in UTILEXCL to KEEP a cacluated
variable was missing in UTILEXCL.
Thanks to Robert Blackburn, Dominion Resources, USA.
Change 24.114 The "bucket" variables S94ADV00-S94ADV95 with the number
ASUM94 of volumes containing 0-5 pct, 5-10, etc, are shifted so
VMAC94 their values match S94AD00-S94AD95, and labels now are:
Jun 28, 2006 S94ADV00='VOLUMES*CONTAINING*0-5PCT*ACTIVE'
S94ADV95='VOLUMES*CONTAINING*95-100PCT*ACTIVE'
Those distribution values were incorrectly SUMmed in the
ASUM94 program; now, their MAX value is output in the
summary dataset.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Change 24.113 The DTF segment was changed, causing invalid data values
VMACOMCI for DTFCKLnn and DTFCNTnn variables (but no error message
Jun 27, 2006 was printed. Segment increased from 140 to 172 bytes,
which now is the expected length.
Thanks to Karl B. Schweitzer, State Street Bank, USA.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 24.112 Variable RESIND/SMF77DFG, a bit map, is now decoded into:
VMAC77 RESIND00='RESOURCE*STILL IN*CONTENTION?'
Jun 27, 2006 RESIND01='SCOPE OF*SYSTEMS(A)*OR SYSTEM(B)?'
RESIND02='OWNER*HAD EXCLUSIVE*OR SHARED?'
RESIND03='FIRST JOB*WAITING*EXCLUSIVE*OR SHARED?'
RESIND04='SECOND JOB*WAITING*EXCLUSIVE*OR SHARED?'
RESIND05='RESOURCE*IS*GLOBAL?'
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.111 RMFINTRV is enhanced to support SYNC59 if INTERVAL=DURSET
VMXGRMFI is specified, provided that your IMACRMFI member _DURSET
VMXG70PR logic does NOT alter the value of STARTIME (i.e., the MXG
VMAC7072 default IMACRMFI is used). With INTERVAL=DURSET the
VMXGINIT STARTIME/SMF70GIE timestamps in RMFINTRV, ASUM70PR,
Jun 27, 2006 ASUM70LP, ASUMCEC, and ASUMCELP will be the original time
Jun 29, 2006 values of your RMF data, and you can now use SYNC59= in
Jul 1, 2006 both RMFINTRV and ASUM70PR members to shift times so the
times in the summary datasets are "exact and pretty".
Change 24.110 Support for z9BC processor CPUTYPE='2096'x, COMPATIBLE if
FORMATS your z/OS is 64-bit. If your z/OS is NOT 64-bit, this
VMAC7072 change is required so that variables SMF70CPA, which
VMXGRMFI becomes CECSUSEC, the SU_SEC value of the hardware CEC,
Jun 27, 2006 will be set by table lookup in the MG070CP format, which
was also updated by this change to contain the 2096 SUs.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
====== Changes thru 24.109 were in MXG 24.04 dated Jun 22, 2006=========
Change 24.109 -ASUMTAPE enhancement for MXGTMNT with IBM Volume Mount
ASUMTAPE Exit enabled now populates these job-level variables:
VMACTMNT ASID INITTIME JOBCLASS LOCLINFO PGMRNAME RACFTERM
Jun 22, 2006 RACFUSER READTIME STEPNAME STEPNR TMNTEXIT
from the first-volume mount, which goes thru that exit
and is captured by MXGTMNT, into subsequent multi-volume
mounts, that do not go thru IBM's exit, and thus are not
captured by MXGTMNT. This enhancement populates the job
variables, but the TAPMNTTM (MXGTMNT monitor mount time
duration) will still be missing in the second and later
multi-volume mounts. However, the new TOTMNTTM added by
Change 24.102, created from MAX of the SYSLOG or MXGTMNT
mount delay, is populated for these multi-volume mounts,
so the new BEGTMNT and ENDTMNT datetime values should now
be used for the start and end times of mount events.
The SYSLOG mount time is earlier than the mount start the
MXGTMNT monitor captures, and the SYSLOG mount verifiy is
later than the MXGTMNT end time, so the new TOTMNTTM is
a more accurate measure of tape mount delay to each job.
-The SORT order of PDB.ASUMTAPE is changed
from BY DEVNR DESCENDING EVENTIME;
to BY DEVNR EVENTIME;
but as the expected SORT order in WEEKBLD/MONTHBLD is
just BY DEVNR
the change from DESCENDING to ASCENDING order should have
no impact and is the more righteous order, anyhow.
-Note that the IBM Volume Mount Exit still misses mounts
issued by some programs: DFHSM, OPC, and DMS jobs have
mounted tapes that MXGTMNT did not see in the IBM exit,
and many of those missed mounts created a type 21 record
with a blank volume serial, and these missed do not have
the standard SYSLOG mount messages. But with those few
exceptions, this iteration of the ASMTAPEE/MXGTMNT
monitor and ASUMTAPE summary program captures all
possible IBM controlled tape mounts, to virtual or real
devices, and populates all possible job-related variables
in ASUMTAPE.
-VMACTMNT correction; SYSLOG records with INVALID MSGID
notes were due to incorrect processing of the IEC235D
WAITING FOR VOLUMES message, so those events were not
output in TYPESYMT dataset. However, as the IEC235D
message does not contain a DEVNR, it cannot be stored
in the PDB.ASUMTAPE dataset.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Paul Naddeo, FISERV, USA.
Change 24.108 Variable TSUDRECD and TSUDXMDA, Datagrams Received/Sent
VMAC119 were incorrectly read as 4-bytes, but they are documented
Jun 22, 2006 as 8 byte binary fields.
Thanks to Al Smye, IBM Canada at PWGSC, CANADA.
Change 24.107 Variable CPUCEPTM is now kept in PDB.STEPS and PDB.JOBS;
BUILD005 it was already included by IBM in CPUTCBTM, but should
BUIL3005 have been kept when created, since BUILDPDB intends to
Jun 22, 2006 keep all of the CPU time component variables.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.106 Heuristic revisions to calculation of WAITTOTM total wait
VMXGUOW time of the constructed PDB.ASUMUOW event; the original
Jun 22, 2006 estimate included WTDISPTM and WTLMIOTM but data suggests
those wait durations are overlapped with other delays.
The total count of wait events WAITTOTL was also revised.
And RCT time should not be included; consider the MRO
TOR/AOR/DOR combination; the transaction starts in the
TOR, moves to AOR, then moves to DOR. While the tran
is not in TOR, the TOR CICSTRAN still clocks RCT wait,
even while the AOR may be waiting on something else.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Thanks to Tom Kelman, Commerce Bank - Missouri, USA.
Change 24.105 Corrections, enhancements for ASUM70PR zIIP and zAAPs.
ASUM70PR -If you had more than one IFA or more than one ZIP, the
VMXG70PR counts NRIFACPU/NRZIPCPU and uptimes IFAUPTM/ZIPUPTM
VMXGDUR in PDB.ASUM70PR and PDB.ASUMCEC summary datasets were
Jun 20, 2006 wrong, but all other IFA/ZIP CPU times were summarized
Jun 22, 2006 correctly, and all of the individual LPAR data values
(LPnXXXX variables in PDB.ASUM70PR/ASUMCEC datasets, and
all of PDB.ASUM70LP and PDB.ASUMCELP datasets) were fine.
-SYNC59 logic (for ex-MICS sites!) was imperfect and did
not always create the expected shifted exact datetime.
-Note: See Change 24.118, which reversed the change in the
default for INTERVAL: The discussion is correct, but
the default was only changed in 24.04, then restored to
the original INTERVAL=DURSET in MXG 24.05.
-The INTERVAL=DURSET default for the summary interval for
PDB.ASUM70PR and PDB.ASUM70LP datasets only works if the
_DURSET macro does NOT change the value of STARTIME. If
the value is changed, there is no way that I can tell the
desired interval, and the logic to build the
PDB.ASUMCEC/ASUMCELP datasets requires knowledge of their
INTERVAL.
DURSET says to use the _DURSET macro definition in
the IMACRMFI member to redefine the STARTIME value,
but if you do change STARTIME therein, I cannot tell
what summary interval you wanted, and if you leave
STARTIME unchanged (MXG's IMACRMFI default) I still
can't tell what is your minimum RMF interval.
The DURSET can still be used to create PDB.ASUM70PR
and PDB.ASUM70LP datasets with their original STARTIME
values, but the PDB.ASUMCEC and PDB.ASUMCELP datasets
may not be completely valid. It may be possible to
figure out a way to safely use DURSET and still have
the correct DURATM values in ASUMCEC, but for now the
safe resolution is to require you to specify the
INTERVAL= and CECINTRV= values in your ASUM70PR member
and then I can build all four datasets without errors.
-Internal VMXGDUR invocations invoke SYNC59=YES only for
the ASUM70PR/ASUM70LP creation; the second invocations
for ASUMCEC/ASUMCELP specify SYNC59=NO because times have
already been shifted.
-Change: Variables IFAWSTTM and ZIPWSTTM are now set to
a missing value in the PDB.ASUM70PR/PDB.ASUMCEC datasets
as they are overlapped wait times across all LPARs that
had an IFA or a ZIP, and really are meaningless totals.
-LPMSUHR was actually per second rather than per hour,
not fixed until Jun 22.
-LPCTBY and LPCTOV were wrong in PDB.ASUM70LP as they were
not divided by LPARCPUS.
-Enhancement: Variables NRIFACPU and NRZIPCPU are added
to the PDB.ASUM70LP and PDB.ASUMCELP dataset, calculated
from IFAUPTM or ZIPUPTM divided by DURATM.
-Some Labels and Formats were revised, including remvoal
of *PCT from the Current and Initial SHARE WEIGHTs.
-This change has been extensively tested but only with Z9
processors that populate SMF70CIN. There may still be
a problem counting IFAs on earlier hardware that did not
populate SMF70CIN.
-VMXGDUR: Variable MXGDURTM is created/dropped for time
intervals and used to reset SMF70GIE after STARTIME has
been SYNC59'd/FLOORed back to start of final interval.
-Jun 22: Variables LPSHARE, LPSHARC, TOTSHARE, TOTSHARC
were sometimes incorrect but the LPnSHARE/LPnSHARC values
were correct.
-SMF70LAC was wrong (zero) in PDB.ASUM70PR and PDB.ASUMCEC
datasets (but LPnLAC values were valid for all LPARs).
Now, the LPnLAC values are summed to create the total of
the 4-hour Average MSU values back into SMF70LAC. But
SMF70LAC isn't an LPAR variable; it comes from the "this
system" segment of the TYPE70 record, and while it is
always valid in per-system TYPE70 & RMFINTRV datasets,
in the LPAR data in PDB.TYPE70PR, SMF70LAC is non-zero
ONLY in the "this system" observations, so this is just
one more variable that requires your ASUM70PR program to
read the PDB.TYPE70PR with data from ALL of your SYSTEMs
to create correct data in the CEC-level summary datasets
PDB.ASUMCEC and PDB.ASUMCELP.
Thanks to Nathan Loewenthal, CitiGroup, USA.
Thanks to Douglas C. Walter, CitiGroup, USA.
Thanks to Michael Salyer, CitiGroup, USA.
Thanks to Brent Turner, CitiGroup, USA.
Thanks to Tom Koelle, CitiGroup, USA.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Thanks to Tom Kelman, Commerce Bank - Missouri, USA.
Thanks to Deborah L. Soricelli, CIGNA, USA.
Thanks to Ray Dunn, CIGNA, USA.
Change 24.104 BMC CMRDETL data file is created by their CMRCMPW program
TYPE110J but the output format is determined by a control card.
TYPEMVCI When FORMAT=CMR is specified, the output format is the
Jun 19, 2006 decompressed T6E record that MXG's TYPEMVCI processes.
When FORMAT=2.2 or FORMAT=2.2Y is specified, the output
format is an SMF 110 record, but written as RECFM=U that
does NOT contain valid BDW/RDWs, and instead has only a
4-byte record length field; this is the old "DOS JOURNAL"
type 110 format, which is processed by MXG's TYPE110J.
Thanks to Pat Perecca, Pershing, USA.
Change 24.103 Variable QWHCCV was misspelled in READB2 as QWHCCCV,
ADOCDB2 which caused selection by CORRID to fail. The variable
READDB2 was also misspelled in ADOCDB2 documentation.
Jun 17, 2006
Thanks to Julain Smailes, Experian, ENGLAND.
Change 24.102 Documentation: PDB.ASUMTAPE will have zero observations
ASUMTAPE if you do not have any observations in SYSLMNT dataset.
Jun 15, 2006 You must install ASMTAPEE (MXGTMNT) monitor at ML-38 or
later, which captures the SYSLOG mount information, now
required by the ASUMTAPE logic to create PDB.ASUMTAPE.
-New variables BEGTMNT, ENDTMNT, the begin and end times
of each tape mount event, and TOTTMNTM, total duration of
the tape mount are created:
BEGTMNT is SYLMTIME (SYSLOG Mount Start), which is
usually fractions of a second earlier than the
TMNTTIME when MXGTMNT saw the mount start, but
TMNTTIME is used if SYLMTIME is missing.
ENDTMNT is SYL5TIME (SYSLOG IEC705I Label Written) that
is usually fractions of a second later than the
TENDTIME when MXGTMNT saw the mount end, but
TENDTIME is used if SYL5TIME is missing.
TOTMNTTM=ENDTMNT-BEGTMNT, the mount delay to the job.
Change 24.101 Flag variable FSRFALT='WRITTEN*IN*DUPLEX*MODE?' is added
VMACHSM to the HSMFSRTP dataset.
Jun 14, 2006
Thanks to Michael E. Friske, Fidelity Systems, USA.
Change 24.100 Utility to get the ENGINE type of a SAS data library was
VGETENG revised to use PROC SQL instead of VGETOBS, to eliminate
Jun 14, 2006 the annoying MXGWARN that MXGENG datasets doesn't exist.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.099 Format MG116TY for SMF 116 MQSeries type was updated to
FORMATS add 0:INTERNAL TASK and 8:IGQ AGENT values, and to revise
Jun 14, 2006 so now 2:BATCH OR TSO.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 24.098 Support for the DCE segment in RACFTYPE 301 segment will
VMAC80A populate TOKDCE variable in the many events that can
Jun 14, 2006 have a DCE segment.
Thanks to Colin Wessels, Unicible, SWITZERLAND
Thanks to Pierre Beda, Unicible, SWITZERLAND
Change 24.097 More than six RACFTYPE=42 CLASS NAME segments caused MXG
VMAC80A to get INPUT STATEMENT EXCEEDED error, the "TRUNCATED
Jun 13, 2006 RECORD FOUND" that was added by Change 24.021. This
change added protection to skip over extra segments for
RACFTYPE 33, 42, and 43 segments.
Thanks to Michael Yuan, University of California Office of Pres, USA.
Change 24.096 Revised STK Exit UX01 protects a local UX01 exit that
ASMHSCEX does not save registers and status. This enhancement is
Jun 13, 2006 for sites that specify SYSPARM(Y) to include their local
UX01 exit in our link-edit step.
Change 24.095 PDB.ASUM70LP variables LPCTBY LPCTOV PCTLPBY PCTLPOV
VMXG70PR were always missing values because the DURATM=SYSDUR
Jun 10, 2006 statement was mis-located, and LPARDUR for PHYSICAL LPAR
was zero, now is set to DURATM*NRPHYCPS.
Thanks to Steve Olmstead, Northwestern Mutual Company, USA.
Change 24.094 Support for APAR OA12857 which adds PDSE Caching stats to
VMAC1415 the type 14/15 SMF records, with these new variables:
Jun 9, 2006 SMF14DRD ='PDSE*DIRECTORY*READ*REQUEST*COUNT'
SMF14DRDH='PDSE*DIRECTORY*READ*HIT*COUNT'
SMF14MCE ='PDSE*MEMBER*CACHE*ELIGIBLE*COUNT'
SMF14MCF ='PDSE*MEMBER*ELIGIBLE*CACHE FULL*COUNT'
SMF14MNC ='PDSE*MEMBER*ELIGIBLE*NOT CACHED*COUNT'
SMF14MRD ='PDSE*MEMBER*READ*REQUEST*COUNT'
SMF14MRDH='PDSE*MEMBER*READ*HIT*COUNT'
SMF14MST ='PDSE*MEMBER*CACHE*STOLEN*COUNT'
But see Change 24.196; it is required to avoid ABENDs.
Change 24.093 New variables added to EDALOGOF dataset:
VMACEDA EDACOMPL='COMP'
Jun 6, 2006 EDAOFA40='FULL*ACCOUNT*NUMBER'
EDAOFID1='SYSPLEX*ID1'
EDAOFID2='SYSPLEX*ID2'
EDAOFPID='POOLED*USERID'
EDAPRTY ='PRIORITY'
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Change 24.092 z/OS 1.8 support (COMPATIBLE).
FORMATS -TYPE30 new EXSRMERR flag variable if SRM is unable to
VMAC108 return the SMF30AIx and SMF30EIx variables, and the
VMAC30 EXCPERR flag for over 4 Billion EXCP logic was revised.
VMAC7072 -SMF30MLS new value 10 decoded by MG030ML format.
VMAC71 -TYPE70 new variables:
VMAC74 SMF70CSC='SEQUENCE*CODE*OF*CONFIGURATION'
VMAC80 SMF70GJT='TIME WHEN*PARTISHN*JOINED*CAPACITY GROUP'
Jun 5, 2006 SMF70POM='PLANT*CODE*OF*MANUFACTURE'
Jun 22, 2006 -TYPE71 new variables for UIC statistics:
Aug 13, 2007 SMF71ULM LOWEST*MINIMUM*SYSTEM*UIC
SMF71ULC LOWEST*CURRENT*SYSTEM*UIC
SMF71UHC HIGHEST*CURRENT*SYSTEM*UIC
SMF71UHX HIGHEST*MAXIMUM*SYSTEM*UIC
SMF71UAM AVERAGE*MINIMUM*SYSTEM*UIC
SMF71UAC AVERAGE*CURRENT*SYSTEM*UIC
SMF71UAX AVERAGE*MAXIMUM*SYSTEMI*UIC
-TYPE72GO new Resource Group Capacity variables
R723GMLP='PERCENT*CAPACITY*OF LPAR?'
R723GMSS='PERCENT*CAPACITY*OF SINGLE*SYSTEM?'
-TYPE72DL new Resource Manager state samples
R723BPMI='BUFFER*POOL*IO*MISSES*SAMPLES'
R723RW05-R723RW15 'RESOURCE TYPE NN SAMPLES'
-TYPE74 new flag variable
IOTMERR ='CONNECT*TIME*IN ERROR?'
-TYPE74CF variable R744VLVL corrected to R744FLVL.
New variable R744FMPC with Plant Code of CF.
New variable R744FSEQ with CF Sequence Number.
-TYPE88 new variable
SMF88GRP='GROUP*VALUE*FOR THE*LOG STREAM'
-TYPE108, new transaction type values in MG108TR format.
-Jun 22: IBM confirmed SMF70GMU is binary, and not the
EBCDIC format in the pre-GA documentation.
-Aug 13, 2007: These group variables are in TYPE70PR and
should not have been output in TYPE70 dataset:
SMF70GNM='CAPACITY*GROUP*NAME'
SMF70POM='PLANT*CODE*OF*MANUFACTURE'
See Change 25.163.
Change 24.091 Revision to RMF III VSAM decompression utility corrects
ASMRMFV processing of the ENCG3 table for the ENC option, adds
DOCLRMFV reporting of the RMF III Index usages, and contains the
Jun 2, 2006 CPUG3 record size reduction.
-The CPUG3 Table output record is reduced in size to
contain only the data that is currently documented by
IBM; previously, a large number of LPARs/LCPUADDR could
generate a record that was greater than 32K.
-New optional messages RMFVO28I and RMFV029I report the
usage of RMF III Index; see prolog in ASMRMFV.
-DOCLRMFV documentation of the CLIST is updated.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.090 RMF III RESOURCE TYPE AND USE/WAIT TYPE MISMATCH messages
VMACRMFV caused ZRBUWENQ dataset to be incomplete or wrong; the
Jun 2, 2006 MXG code for REDG3 and UWDG3 segments was revised.
Thanks to Betty Wong, Bank of America, USA.
Change 24.089 MXGWARN: INTERVAL IS NOT A VALID VALUE FOR INTERVAL= may
VMXG70PR occur if you changed the default INTERVAL=DURSET in your
Jun 2, 2006 own %VMXG70PR invocation. The error was due to line 304
which should have had INTERVAL=&INTERVAL, syntax.
Thanks to David J Schumann, Blue Cross of Minnesota, USA.
Change 24.088 Variables QJSTCIWR QJSTLOGW QJSTLSUS QJSTSERW QJSTTHRW
VMACDB2 in the DB2STATS dataset have been wrong since they were
May 30, 2006 added by Change 18.305; the wrong variable name was used
in MXG's deaccumulation logic.
Thanks to Erling Andersen, SMT, DENMARK.
Change 24.087 Auditors requested the values of QW0141AC be formatted,
FORMATS so format $MGD141A now exists and it decodes:
VMAC102 'G'='G:GRANT'
May 30, 2006 'R'='R:REVOKE'
Thanks to Mike Duffy, LLoyds, ENGLAND.
Change 24.086 New variable R783CSSC is a character variable with $HEX2.
VMAC78 format that contains the value of R783CSs, which is a
May 26, 2006 numeric variable with HEX2. format, so that the TYPE78IO
R783CSSC and the TYPE73 SMF73CSS are both characters, so
they can be used without conversion to MERGE the two data
sets by Channel Subsystem ID.
Thanks to Bill Cool, EDS, USA.
Change 24.085 -Invalid values for NDMCPUTM because MXG read only the
VMACNDM first VOLSER in the Receiving or Sending VOLSER list.
May 26, 2006 -New values set for bits in NDMBYTE1 for NDMCOMPR:
NDMCOMPR='T' - COMPACTED?
NDMCOMPR='E' - COMPRS EXT?
NDMCOMPR='X' - DMDSSIOX
Thanks to John Shuck, SunTrust, USA.
Thanks to Srinivas Guntapalli, Citigroup, USA.
Change 24.084 Support for optional CICS fields with CMODHEAD/CMODNAME
IMACICMN values of MSGNAME and MSGTYPE.
IMACICMT
VMAC110
UTILEXCL
May 26, 2006
Thanks to Alan O'Hara, HBOS plc, SCOTLAND.
Change 24.083 Documentation. The ASUM70PR in MXG 24.03 can't summarize
ASUM70PR old PDB libraries built prior to MXG 23.23, because the
May 22, 2006 SMF70GIE variable was NOT kept in all RMF datasets until
Change 23.231. YOu can use ASUM70PR to summarize PDBs
built with 23.23-24.02, but you must add this OPTIONS:
OPTIONS DKRICOND=NOWARN;
%INCLUDE SOURCLIB(ASUM70PR);
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 24.082 RACF formats MG080EV for Event and MG080QU for Qualifier
FORMATS decoding were updated with new values of both Events and
May 22, 2006 Qualifiers.
Thanks to Linda S. Berkley, DISA, USA.
Change 24.081 -MXG 24.03 did not have ZDATE kept in PDB.ASUM70LP nor in
VMXG70PR PDB.ASUMCELP, which will cause an error if MONTHBLD from
May 19, 2006 24.03 is used, because those datasets were added to the
MONTHLY PDB, but ZDATE is used to select observations.
(The error message only occurs if ALL of your WEEK/DAY
datasets were created by MXG 24.03; if any PDB used in
the MONTH job was created with this change, then that
MONTHBLD run will not fail with an error; however, the
two output datasets will still be incomplete and wrong.)
-Since those two datasets never existed in the MONTH PDB
previously, you could use the prior MONTHBLD until all of
your DAY/WEEK PDBs have been created with this change.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 24.080 Analysis of MIPS/MSU from SMF 30 and RMF 72 by SRVCLASS
ASUMMIPS adds _SYNC59 macro for sites still stuck with the unwise
May 23, 2006 SYNCVAL(59) SMF option that was only required by MICS and
is unneeded and unwise if you no longer have MICS, and a
new _INTVAL macro so you can change the summary interval.
The default _INTVAL is HOUR, and _SYNC59 is NO.
Thanks to Pat Curren, SuperValu, USA.
Change 24.079 -New NOTYPE74=YES (DEFAULT) option skips PDB.TYPE74 data
VMXGRMFI when creating PDB.RMFINTRV dataset. Only these variables
May 18, 2006 AVGRSPMS DEVACTTM DEVCONTM DEVDISTM DEVPNDTM
SIO74CNT SIO74TAP
in PDB.RMFINTRV come from TYPE74 data, and they are total
across ALL of your DASD devices, so they have very little
value if you have ESCON and FICON channels, or have both
Cache/Non-Cache Controllers, or have different devices;
they will all have missing values with the YES default.
The new default can significantly reduce the run time and
CPU time of your RMFINTRV execution, but if you need the
above variables, specify NOTYPE74=NO in your RMFINTRV
will read the PDB.TYPE74 dataset and populate them.
-Datasets PDB.TYPE72 and PDB.TYPE73P are no longer used as
those datasets now always have zero observations.
-Comments document the only PDB datasets required are
TYPE70 TYPE71 TYPE72GO TYPE74 TYPE75 TYPE78 TYPE78IO.
Thanks to Steve Olmstead, Northwestern Mutual Company, USA.
Change 24.078 All z/VM MONWRITE datasets now have variable SYSTEM, that
VMACVMXA was previously only in the VMMTRSYS configuration dataset
May 18, 2006 from the 1.4 record, so you can combine MONWRITE data and
SORT/REPORT by each of your z/VM SYSTEMs.
Thanks to Barbara Nitz, Deutsche-Boerse, GERMANY.
Change 24.077 Value QLIM and MDC for SAS/ETS product were added to the
FORMATS $MGSASPR format that maps SAS Procedure Name to the SAS
May 17, 2006 product that "owns" that procedure, for the decoding in
the TYPESASU SAS User Record dataset.
Thanks to Len Rugen, University of Missouri, USA.
Change 24.076 -WARNING: VARIABLE CPCFNAME IN THE DROP KEEP RENAME LIST
VMXG70PR HAS NEVER BEEN REFERENCED (and the same warning for the
May 16, 2006 variables SMF70CPA, SYSDUR, MAXCPUS, MINCPUS, SYSSHARE
May 19, 2006 and CURSHARE), fortunately, does NOT impact the output.
These variables were left in DROP statements from an
earlier iteration of the redesign, but were not used in
the DATA steps that produced the warning message.
These messages are not printed using the MXG default
OPTIONS DKROCOND=NOWARN; using DKROCOND=WARN will cause
the above messages to be printed on the log, and if you
set OPTIONS DKROCOND=ERROR, my failure to remove them
will cause your job to fail with ERRORs.
-Variable DURATM in ASUMCELP is again TIME12.2 format.
Thanks to Randy Shumate, LexisNexis, USA.
====== Changes thru 24.075 were in MXG 24.03 dated May 15, 2006=========
Change 24.075 ML-39 of MXGTMNT Tape Mount Monitor enhancements include:
ASMTAPEE - support for the hardcopy message set, which allows for
May 15, 2006 the monitor to capture suppressed SYSLOG messages.
(Previously, if console messages were suppressed,
MXGTMNT didn't capture SYSLOG messages, and there
were zero observations in TYPESYMT dataset.)
- eliminates S0C4 ABEND in IEAQPGTM+01E6, which occurred
only at shutdown of the MXGTMNT task, with no impact
on the monitor's records. Because it was unexpected,
and appeared to be circumvented by changing the SYSOUT
class of the SYSUDUMP DD, IBM Support was invoked, but
their SLIP trap proved the error was, as they had said
before the SLIP trap, in our code!
- provides protection for future z/OS releases which may
enforce the No User Key CSA rule, by eliminating the
use of CSA Key 8 virtual storage in MXGTMNT coding.
While ASMTAPEE requested SP 241 in Key 0, it was
being ignored and the storage was allocated instead
in Key 8, which, while still "legal", is undesired.
Added Sep 2008: This change from 2005 does support
VSM ALLOWUSERKEYCSA(NO) to be specified in
your DIAGxx member.
- The B78-5C ABEND condition was also prevented in ML-39
Note added Apr, 2008: ML-39 is REQUIRED for z/OS 1.9.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Ed Webb, SAS Institute z/OS, USA.
Thanks to Eladio Aviles, Arizona Public Services, USA
Thanks to George Kozakos, IBM Support, AUSTRALIA.
Change 24.074 Variables INTBTIME and INTETIME, Interval Begin and End,
VMAC30 were never defined for the TYPE30_4 and TYPE30_5 step and
May 15, 2006 job termination events, because they were previously only
output in the TYPE30_V Interval dataset. For the subtype
4 & 5 records, not only were they on the GMT clock, their
times were for the last interval, but for step and jobs,
the interval of the data is the step or job itself.
Fortunately, only the TYPE30TD dataset contained the two
variables from the subtype 4/5 records, and TYPE30TD is
only used internally in BUILDPDB to count tape drives,
and MXG's logic didn't use those timestamps; it was only
if you investigated the WORK.TYPE30TD dataset that you
could have observed the incorrect values. Now, for the
step and job termination records, the two variables are
now set as INTBTIME=INITTIME and INTETIME=SMFTIME, so the
variables describe the data interval in all cases.
Thanks to Mike O'Brien, Bank of America, USA.
Thanks to Betty Wong, Bank of America, USA.
====== Changes thru 24.073 were in MXG 24.03 dated May 13, 2006=========
Change 24.073 Change 23.334 caused type 30 interval records to always
IMACINTV be created, without having to edit IMACINTV, by removing
May 12, 2006 the old comment block around the OUTPUT statement. But,
the &MACINTV macro variable was located physically after
the OUTPUT statement, so it could not be used to alter
the TYPE30_V - PDB.SMFINTRV datasets as intended.
The &MACINTV statement was relocated ahead of the OUTPUT.
Thanks to Willy Iven, Fortis Bank Belgium, BELGIUM.
Change 24.072 INVALID DATA FOR SYTNLPMG/SYTACTM with XAMSYS 3507 data.
VMACXAM MXG used the TOTALs SEGLEN (if GE 48) to INPUT the two
May 11, 2006 percent SYTPCTBY/SYTPCTOV fields that may or may not be
present, and that worked for prior test data, but this
new data has SEGLEN=40 in TOTALs for its 1 LPAR, so the
LENDATA=12 (bytes after DURATM, so PCT fields are NOT in
the TOTALs section, but the LPARA section has LPAR count
of six with SEGLEN=168, but there are seven "buckets" of
LPAR data, so the LENDATA=20, and the "real" LPAR data
does have the PCT fields, while the TOTALs doesn't.
That 7th LPAR segment has a Partition Number of '0040'x.
To process these records and protect for the future, MXG
code now recalculates LENDATA for each SYTCUP record, no
longer retaining the value from the TOTALS record, and
used LENDATA to conditionally input the two fields.
May 13: Barton acknowledges the undocumented seventh LPAR
is actually a sub-total for that LPAR, with the
'40'x the LPARNUM of decimal 64 as his flag.
Outputting totals and details to the same dataset
is exposed to reporting errors, and since only
detail LPAR data was previously output to XAMSYT
dataset, this change does NOT output the new LPAR
sub-total section. The decision is internal now,
but could be externalized to EXXAMSYT if someone
convinces me they need that facility.
Thanks to Michael J. Salyer, CitiGroup, USA.
Change 24.071 The SMF manual mis-documented DFSORT bit 6 in ICEFLBY3 to
VMAC16 set new MEMOBJUS='Y' when a Memory Object is USED, but
May 10, 2006 SMF data shows MEMOBJUS must be IBM bit 7 (last), and the
updated DFSORT Installation and Customization Guide, pub
SC26-7524-00, page 212) confirms that bit, as well as
documenting that ICEMON is a 2-byte field at offset 438,
but MXG had input it as a 4-byte field at offset 436.
Fortunately, offset 436 and 437 are reserved and zeros so
ICEMON's value was correct, but MXG code is now revised.
Thanks to Diane Eppestine, AT&T Services, Inc, USA
Thanks to Gennady Katsnelson, AT&T, USA.
Change 24.070 The right-hand-value of format MG074PT for values of 3 is
FORMATS changed to '03'X='3:LIST STRUCTURE'
May 10, 2006 instead of '03'X='1:LIST STRUCTURE'
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Thom Kight, Fidelity Systems, USA.
Change 24.069 Comments only. ARRAY EXCEEDED error when running _BLDDICT
UTILEXCL if the PGM=DFHMNDUP was used to create CICS Dictionary
May 10, 2006 "SMF" records for five executing regions, but each of the
SMF files were read in five separate _BLDDICT executions.
The SMFTIMEs of DFHMNDUP were all the same (and in 1906!)
and because the records were processed one at a time, the
NREC variable was the same in all of the records, so the
MXG sort on SMFTIME NREC saw way too many entries.
If the five "SMF" files had been concatenated in one run
of _BLDDICT, the problem does not exist, even with same
SMF value, because they will get a different NREC when
there are five records read by _BLDDICT.
However, a new example in comments in UTILEXCL show
how you can correct an existing PDB.CICSDICT dataset
without going back to re-read the SMF data.
Thanks to Doug Jones, T-SYS, USA.
Change 24.068 -SHORT SEGMENT error messages in SYTCPC & STOSHR segments
VMACXAM are corrected; MXG logic did not protect for new fields.
May 9, 2006 The SHORT SEGMENT message is a real error in MXG code
that must be fixed, because that means that observations
were NOT output. Contact support@mxg.com if these occur.
-There were UNKNOWN SEGMENT xxxxx messages printed on the
SAS log that are NOT real errors; they are simply MXG
notes that new segments exist in the XAM data that are
not yet decoded, but the record was still output.
-The text of both messages was rewritten to clarify which
is an error (and what to do), and which is just a note.
-New segments are always supported when a user asks for
the new data, as I prefer to have real data and a real
user to validate new stuff, especially in zVM.
Thanks to Pat Curren, SuperValu, USA.
Change 24.067 Additional INTERVAL=DETAIL value is now supported, which
VMXGDUR will cause DATETIME value to be the original, raw, value
May 6, 2006 to be output, unmodified.
Change 24.066 Variables SYTPCTBY,SYTPCTOV, added by MXG Change 24.017,
VMACXAM were always expected, but they did not exist in Release
May 5, 2006 3507 of XAM. Logic revised to keep the SEGLEN of the
"Total" segment and use to INPUT the two fields that
were found in Release 3519.
Thanks to Michael J. Salyer, CitiCorp, USA.
Change 24.065 Variables STARTIME and SYNCTIME in TYPE23 were in the GMT
ADOC23 timezone while SMFTIME was (always) in Local time, but
VMAC23 the only documentation clue was that third argument "GMT"
May 4, 2006 in the %VMXGTIME(SYNCTIME,SYSTEM,GMT); statement
used only by the optional TIMEBILD facility, and only
when there was no GMT offset in the SMF record.
However, the PROC PRINT of TYPE23 (from 1999!!) in the
ADOC23 member clearly shows an exact 6-hour difference
between SMFTIME and SYNCTIME, so the GMTOFF23 can now be
calculated and used to convert SYNCTIME and STARTIME to
the local time zone. GMTOFF23 is kept in TYPE23, and if
it is non-missing, then STARTIME/SYNCTIME were converted
from GMT to local time zone.
I think this was not done before because nobody asked,
and maybe because SYNCTIME was not always present in
SMF 23 records way back when.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.064 Redesign of ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP creation.
VMAC7072 Major changes, perhaps incompatible:
VMXG70PR - ASUMCEC/ASUMCELP default summary interval is HOURLY.
VMXGINIT - ASUM70PR/ASUM70LP interval no longer set by IMACRMFI
WEEKBLD so you may have to add INTERVAL= in your ASUM70PR.
MONTHBL* - BY List variables were changed for all four datasets.
VMXGINIT
TRNDCEC This redesign is required because the old BY list of MXG
May 9, 2006 variables that I thought were sufficient to identify a
May 11, 2006 unique "SYSTEM", for summarization, these variables:
May 13, 2006 SYSPLEX SYSTEM SYSNAME STARTIME
are not sufficient, and cause incorrect output.
The new BY variables required to identify a "SYSTEM"
CECSER SYSPLEX SYSTEM SYSNAME LPARNUM LPARNAME SMF70GIE
are used in VMXG70PR logic to group, but you would use
CECSER SYSPLEX SYSTEM SYSNAME LPARNUM LPARNAME STARTIME
for your reports by Start time, and any other summaries.
-The ASUM70PR/ASUM70LP "SYSTEM" and "SYSTEM-LPAR" summary
data were less exposed to serious errors (because they
are per system with less time variance) than were the
ASUMCEC/ASUMCELP "CEC" and "CEC-LPAR" datasets, which
were very wrong when DURATM and/or STARTIME values were
not the same for all SYSPLEX and SYSTEMS in a CEC, but
all four datasets could be in error with the old "BYs".
And even with the revision, you need to remember that the
"SYSTEM" and "SYSTEM-LPAR" datasets have observations for
each interval from every SYSTEM in each SYSPLEX, so they
have duplicate and replicated data, and you must always
select which "SYSTEM" to use.
-While I do find a PROC PRINT of PDB.ASUM70PR/PDB.ASUMCEC
datasets can be useful to get a snapshot of overall usage
for each LPARs, those two datasets are very unwieldy for
reports, with their 61 sets of different variable names
to deal with. Furthermore, the "LPARNUM" bucket-number
changes with new LPARs so it's not really stable for long
term comparisons.
-Instead, the best datasets to use for LPAR analysis are
the ASUM70LP or ASUMCELP, as they have only one set of
variable names, and you can select and sort by LPARNAME
or SYSTEM, etc., without scanning 61 possible variables.
-The errors that were found in the old ASUMCEC/ASUMCELP
logic could result in multiple observations with slightly
different STARTIME or SMF70GIE values, and/or you could
have duplicate, overlapping, or incorrect data:
-The SPLIT70 rewrite correctly used SMF70GIE to group
by the end of interval for all "BY SYSPLEX-SYSTEM"
(TYPE70,RMFINTRV,ASUM70PR/ASUM70LP) datasets, but it
cannot be used (as-is) to group "BY CECSER", because
SMF70GIE is not the same value in all LPARs in a CEC
for a particular interval, and it caused multiple
observations with overlapping STARTIME to SMF70GIE.
-The DURATM of ASUMCEC was wrong when there were LPARs
with different interval durations. The minimum DURATM
for CEC summary must be at least the largest DURATM,
but for some DURATM values, it must be larger still.
It must be the Least Common Denominator of all of
your DURATMs, so with 10 and 15 minute DURATMs,
your minimum summary interval is 30 minutes.
-Interval DURATM values are very "fuzzy", even for the
"interval pop" observations that you expected to have
the exact INTERVAL you requested (10, 15, or 30 min).
Here's some reality from four CECs that share SYSPLEX:
Interval DURATM
Min Max
CECONE 14:58.99-15:53.26
CECTWO 14:59.62-15:00.50
29:59.88-30:00.11
CECTHREE 09:59:54-10:00.74
14:59.24-15:23.17
CECFOUR 14:59.75-15:00.23
28:54.08-30:00.08
And there are always intervals of much smaller DURATM:
the first RMF interval's end is forced so the next is
synchronized with time of day, so any value of DURATM
less than the maximum can occur in SMF data, which
prevents using the data to set the summary interval.
-CECs with LPARs with both SYNC(0) and SYNC(59) have
some SMF70GIE values of 00/15/30/45 minutes and some
with values of 59/14/29/44 minutes, so it's impossible
to exactly summarize that data to a true CEC interval.
-Inexactness of DURATM across LPARs in a CEC caused the
STARTIME=SMF70GIE-DURATM; to be as inexact as DURATM,
so STARTIME can not be used, either.
-With these inconsistent/fuzzy times, creating a perfect
CEC-LPAR summary dataset for each LPAR in each CEC is not
possible, but we can create a very-good summary dataset,
that gets to be nearly-perfect if all of your systems are
on the same SYNC() and INTERVAL() specifications in RMF.
But you still may occasionally get percentages over 100%!
-The PDB.ASUM70PR and PDB.ASUM70LP datasets summary DURATM
used to be set by the IMACRMFI member's _DURSET macro, so
the interval of those two datasets matched your RMFINTRV.
And this still works fine, if your _DURSET macro made no
change in STARTIME (i.e., your RMFINTRV/ASUM70PR/ASUM70LP
were at the original, raw datetimes of your RMF data).
But if you have used _DURSET to change the STARTIME of
PDB.RMFINTRV to a summary interval, I can't tell what you
wanted for your interval, so I will now print a message
that I have to build those two datasets a detail level,
and telling you to use the INTERVAL= parameter in your
ASUM70PR member, instead of IMACRMFI, to define interval.
-The redesign creates the CEC-level by-LPAR summary data
in the PDB.ASUMCELP ("CEC-LPAR") dataset, starting with
the just=built PDB.ASUM70LP ("per-SYSTEM-LPAR"
resources for each "LPAR" for each "STARTIME" within each
"CECSER" box, with the new duration DURATM = "CECINTRV":
"LPAR" - Variables SYSPLEX LPARNUM LPARNAME are
used to uniquely define each "LPAR", as
the same LPARNUM and/or LPARNAME can be
used in different SYSPLEX on same CECSER.
"STARTIME" - STARTIME and SMF70GIE are shifted to the
"expected, exact" time of day value for
CECINTRV interval. See algorithm below.
"CECINTRV" - Default summary interval is 60 minutes,
so STARTIME/SMF70GIE will be on the hour.
As noted above, the CEC summary interval
MUST be the Least Common Denominator of
all of your DURATMs, so using 60 minutes
safely summarizes every RMF Interval that
I've ever used (1,3,5,10,15,20,30,60).
You can use a smaller value for CECINTRV
only if it is equal to the LCD of all of
your DURATM values for all of your LPARs.
- SMF70GIE is changed to be the "correct" interval end
time of day for the CECINTRV duration. One minute is
added if SYNC(59) minutes of 14,29,44 or 59 are found,
other endtimes are pushed to the correct TOD value.
So the CEC-summary data can still be slightly wrong
because two slightly different intervals are summed
together, but that's all that can be done, unless
you change all of your interval and SYNCs to be the
same!
Each SMF70GIE and LPARNAME is summarized to combine the
short intervals into the summary interval, using
BY CECSER SYSPLEX LPARNUM LPARNAME SYSTEM SYSNAME
(revised) SMF70GIE
That summary of each LPARNAME is then sorted
BY CECSER SMF70GIE LPARNUM LPARNAME
DESCENDING SMF70LAC DESCENDING DURATM,
and the first instance of each LPARNAME is output
to create the PDB.ASUMCELP dataset, with the total
resoures consumed by each LPAR in that CEC for the
constructed CEC Interval. Variable STARTIME is
recalculated as SMF70GIE-CECINTRV so all of the obs
will have the same "pseudo" STARTIME for reporting.
-While the new sort order BY CECSER SYSPLEX .... is used
inside VMXG70PR to ensure correct assembly and summary,
at the end, the four output datasets are sorted back to
their old sort order, with the new variables added at the
end, hopefully to avoid NOTSORTED errors in your weekly
and/or monthly jobs that combine ASUMs built with both
the old and new logic. The final sort order is:
ASUM70LP:
BY SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER
LPARNAME LPARNUM
ASUM70PR:
BY SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER
ASUMCELP:
BY CECSER STARTIME SHIFT LPARNAME LPARNUM
ASUMCEC:
BY CECSER STARTIME SHIFT
-A new macro variable, &MXGNOBY, is created for NOTSORTED
circumvention in each of the WEEKxxxx/MONTHxxx members.
The current circumvention, documented in comments in each
of those members, still works fine, but it requires you
to EDIT your WEEKxxx/MONTHxxx member to insert:
MACRO _BY % MACRO _SORTBY %
which disables the BY processing in the SET statements.
Without the BY processing, the output dataset is not
in sort order, but instead is the concatenation of
the input datasets, but there is no requirement that
the datasets be sorted (except in MXG's MONTHxxx and
WEEKxxx code!!). Even though MXG normally builds its
datasets sorted, you should never make that assumption
and thus should always sort the input data yourself;
however, if the dataset is already sorted in the same
order, SAS will bypass your sort. Thus having output
of the weekly or monthly only impacts run times, but
not the contents of the output datasets.
This new &MXGNOBY macro variable is located so that it
can be used in your //SYSIN to disable BY processing,
without EDITing your WEEKxxx/MONTHxxx member, using
%LET MXGNOBY = MACRO _BY % MACRO _SORTBY % ;
%INCLUDE SOURCLIB(MONTHBLD);
And, then remove the %LET before the next MONTHBLD!
-May 11:
Variable LPARWAIT was incorrectly kept in ASUMCEC/TRNDCEC
but it is an LPAR-specific field that was stored into its
LCPUWAIn variable, so LPARWAIT is not kept in ASUMCEC nor
TRNDCEC. The labels for the LCPUWAITn variable now are
'LCPU n*WAIT*COMPLETE?'.
-May 13:
The variables NRIFCCPU/NRIFACPU/NRIFLCPU/NRZIPCPU that
count the number of "specialty engines" was sometimes
incorrect in the PDB.ASUMCEC and PDB.ASUM70PR datasets.
They are corrected, and documented as to when they will
be zero and when they won't:
For the "this system" PDB.TYPE70 dataset, SMF70CIN='IFA'
is used to count the NRIFAS available to "this system";
but even when SMF70CIN is not populated with that new
value, the original MXG heuristic algorithm detects and
counts IFAs, and populates CPUIFATM and the other IFA
durations. The "this system" datasets PDB.TYPE70 and
PDB.RMFINTRV do not depend on new values in SMF70CIN.
However, for "LPAR summary" PDB.ASUM70PR & PDB.ASUMCEC
datasets, SMF70CIN must be populated with "IFA" to count
each type of "specialty engines". But SMF70CIN is only
populated with new 'IFL' or 'IFA' values on z9 and later
processors, so only z9+ systems will have the correct
count values in all four NRxxxCPU counters. Pre-z9
systems have only 'CP' or 'ICF' in SMF70CIN so they will
have zeros in NRIFACPU and NRIFLCPU, and the NRICFCPU
variable will contain the total count of all of the
specialty engines in that CEC.
But it is only the NRxxxCPU counters that may be zeroed.
Whether it's a z9+ or not, the IFACPUTM,IFAUPTM,IFAWSTTM
duration variables were correct when an IFA is used, and
you can have NRIFACPU=0 with IFACPUTM non-zero pre-z9's!
Change 24.063 The calculation of MACHTIME in TYPE89 & TYPE892 datasets
VMAC89 was revised with SMF data that had SMF89DTO and SMF89HOF
Apr 29, 2006 populated. Now, MACHTIME=SMF89UET-SMF89DTO-SMF89HOF, and
May 4, 2006 it is the "TRUE" GMT Clock datetime when the actual usage
occurred to be used by IBM for usage charges. MACHTIME is
needed for IBM to charge you correctly, since you can IPL
IPL with any date/time/offset, as you did for Y2K tests,
and may to do again for Y2042 testing (8-byte STCK fields
will wrap at 23:53:48 on Sep 17, 2042, but must be fixed
prior to 2012, because tape retention can be 30 years.)
Only MACHTIME is is adjusted, as all of the other times,
SMF89UST, SMF89IST, SMF89IET, SMF89UET and SMFTIME are
always on the same (local) time zone.
And SMF89DTO, unlike all other SMF GMT Offset fields,
is the offset from local back to GMT.
The SMF89IST/SMF89IET times are the start/end of the
interval of data (twelve 5-minute intervals in an hour),
while the SMF89UST/UET are always the hourly start/end
of each usage hour, so they have the same value in all
twelve detail observations for that hour.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Stephen H. Hodges, OneBeacon, USA.
Change 24.062 SAS ERROR: BIT CONSTANTS ARE NOT SUPPORTED BY SQL because
MXGSASV9 the Service Pack SASMSG DSN was not first in the //SASMSG
Apr 27, 2006 concatenation. When you install a SAS Service Pack, the
new SASMSG DSNAME contains ...SL..., and that DSNAME must
be first in the //SASMSG DD concatenation. This change
adds a ...SL... DD/DSNAME to the MXG Example JCL Proc.
Due to how SAS messages are built, if the wrong SASMSG
is first, you can get all types of failures, including
ABENDS. Many times there will be a message text that
makes no sense (there are no BIT tests in any of the
code that produced the above error), because the SAS
message formatting is processing the wrong message ID,
due to the incorrect library being first.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 24.061 Revised to work on ASCII systems; SAS WENT TO A NEW LINE
TIMEBILD error message if there was no data in the OFFGMT column.
Apr 26, 2006 On z/OS, TIMETABL is a RECFM=F/FB file, so there always
May 22, 2006 is at least a blank in column 64, where OFFGMT was read,
but on ASCII, the text file is variable length, and that
unconditional INPUT @64 with no data caused SAS to skip
the next line in TIMETABL. The INPUT @64 OFFGMT is now
conditionally executed only if there is data there.
The error was observed when the time stamps on systems
that were listed in TIMETABL were not being changed.
-May 22: The LRECL=72 in the INFILE &TIMETABL statement
left during testing this change was removed.
It caused an OPEN ERROR if the &TIMETABL DD
pointed to an LRECL=80 dataset (i.e. SOURCLIB).
Thanks to Ingegerd Jansson, Volvo, SWEDEN.
Change 24.060 The RMF-like CPU Activity Report is updated for IFAs and
ANALRMFR IFL engines.
Apr 26, 2006
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 24.059 For z/890's only, the three IFA CPU Time variables in the
VMAC30 TYPE30/STEPS/JOBS, CPUIFATM, CPUIFETM CPUIFDTM, were the
Apr 26, 2006 "measured" rather than "normalized to CP seconds" in MXG,
and thus their values were too large on z/890s. The
three times are now revised to be the "normalized" time:
CPUIFATM=CPUIFATM*SMF30ZNF/256;
CPUIFETM=CPUIEATM*SMF30ZNF/256;
CPUIFDTM=CPUIDATM*SMF30ZNF/256;
and those equations could be used to correct existing
MXG datasets.
Change 24.058 -The SORT order of PDB.ASUMTAPE was changed in MXG 23.09
ASUMTAPE (Change 23.300) to BY "LOCATION" DEVNR. Previously, it
WEEKBLD was BY SYSTEM DEVNR, but it was never correct to include
Apr 26, 2006 SYSTEM if you shared tape devices across systems. One of
the major corrections in Change 23.300 was the removal of
SYSTEM from the ordering (and the creation the optional
"LOCATION" to support multiple locations with the same
DEVNR for two different devices), as well as the addition
of the SYSLOG mount-related messages in the redesign.
Unfortunately, I did not document this change in the sort
order of PDB.ASUMTAPE, and I failed to update the WEEKBLD
programs, which still had the old BY statement. SYSTEM
has now been removed from the BYLIST in those WEEKBLx's.
-Macro _GRPMNCD to define the optional "LOCATION" was not
invoked in the ASUMTAPE member (which only proves that no
one yet had tried to use that option!), but now it can be
used if needed.
====== Changes thru 24.057 were in MXG 24.02 dated Apr 26, 2006=========
Change 24.057 New analysis of RAID boxes, creates new PDB.RAIDMAP and
ASUMCACH PDB.CSSSID datasets that shows, for each CSSID, all of
ASUMRAID the volumes on that CSSSID (typically 80 to 256). Some
GRAFRAID user tailoring of the ASUMRAID member will be required;
Apr 25, 2006 read the comments in ASUMRAID.
-The ASUMRAID analysis requires ASUMCACH to have been run
to create PDB.ASUMCACH; this change cleaned up ASUMCACH
so it won't fail even if there was no TYPE74CA dataset
observations.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.056 New GLOBAL macro variable MGCMPNY is now defined as null
VMXGINIT in VMXGINIT, but it will be used in MXG reports so your
Apr 25, 2006 Company Name can be printed on reports. You could set it
permanently in IMACINIT, with
%LET COMPANY='MERRILL CONSULTANTS;
or you could just put that %LET in your //SYSIN stream.
The reports that have been revised to use &MGCMPNY will
be added to this list:
ASUMRAID
Change 24.055 See Change 24.063.
VMAC89
Apr 25, 2006
Change 24.054 This example, which reads SMF data to run ASUMTAPE, was
ASMFTAPE not updated for the new SYSLOG Messages dataset, which
Apr 24, 2006 caused FILE PDB.TYPESYMT NOT FOUND error. The example
was revised to use the _STMNT product sort macro so that
all present and future TMNT datasets are sorted.
Thanks to Andre Vossen, ABN AMRO Bank, THE NETHERLANDS.
Change 24.053 Error messages printed for negative CPUUNITS are now only
VMAC30 printed if the delta is 1000 unweighted service units, or
Apr 24, 2006 about 0.05 CPU seconds on an SU_SEC=25000 machine. The
messages were added by Change 23.323 when the cause was
not known, but new analysis of a full day's SMF interval
records had only 56 records which had IFAUNITS greater
than ORGUNITS, but the max delta was only 650 units, or
0.03 seconds on the SU_SEC=25000 machine. The CPUTCBTM
was 0.00 or 0.01 CPU seconds, and CPUIFATM was between
0.25 to 0.44 CPU seconds for the 30 minute intervals.
MXG's value of CPUUNITS will not be changed, so you can
see if this occurs, but the MXG Error Message will only
be printed when the negative delta is significant.
After discussions of this data with IBM, I agree that
these negative values are the result of imprecision in
CPU timings (.01 resolution) and in the way Service Units
are calculated (remainders are discarded in some fields,
rounding is done in others) and are not a problem to be
immediately corrected, although IBM does plan to review
their remaindering/rounding logic.
Jul 27, 2006: It appears the correction to IBM Service
Unit remaindering is corrected by APAR OA16005.
Change 24.052 Debugging PUT statement removed.
VMACFILA
Apr 24, 2006
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 24.051 In DB2 V8.1, QISEDBW was missing but shouldn't have been,
VMACDB2 QISEDSC should have been but wasn't, and these four new
Apr 24, 2006 variables are now INPUT for the DB2ACCT dataset.
Apr 25, 2006 QISEDYNP QISECFAL QISECPGE QISECFRE
Apr 27, 2006 And, QISESTMT should not have been de-accumulated.
And, QISEDSI and QISEDSG are now de-accumulated.
Thanks to Clayton Buck, UniGroup, iNC.
====== Changes thru 24.050 were in MXG 24.02 dated Apr 24, 2006=========
Change 24.050 New variables INDXUSED and POLYUSED are created from DSIG
VMACRMFV offset variables that are now kept in ZRBBDSHI dataset,
Apr 23, 2006 to detect and eliminate "dead space" in RMF VSAM files.
RMF Monitor III "indexes" each Sample Set in the DSH
table; a sample set is written for each MINTIME interval
and the index provides the offset into the data set for
each sample. But the max DSH is 32K long; the fixed DSH
header is 256 bytes, leaving 32512 bytes for the 28-byte
indexes, for a maximum possible of 1161 indexes; Cheryl
Watson reported 50 are saved for Policy Indexes, leaving
1111 indexes for the actual sample data indexes. In the
past sites had cumbersome calculations to insure the RMF
III VSAM files were not too large; otherwise, those 1111
index entries could be exhausted. But with the INDXUSED
calculation, Jerry found they were only using 80-95 of
the indexes on each dataset because their sample sets are
so large. With RMF III data sets of only 2250 tracks
each, they would exhaust space long before running out of
indexes. The datasest could be made much bigger, keeping
more data online for interactive analysis, and still not
risk creating any "dead space". And adding new RMF III
datasets may not be an option, as there is a hard limit
of 100 datasets.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.049 Variables WTASFLAG and WTASFLG2 are now kept in MQMQUEUE
VMAC116 dataset, from MQMACCTQ segment, and new variable SM116EVT
Apr 23, 2006 is created to distinguish between records written at the
Apr 25, 2006 end of each thread from records written at interval end.
Data showed that the thread end had WTASFLAG='30'x and
the interval end had WTASFLAG '00'x or '20'x.
IBM now provided these bit explanations:
WTASFLAG
WTASERR 0 set if an error occurred
WTASLAT 1 Latency Error
WTASAEOT 2 Accounting End of Thread
WTASDEAL 3 Thread Deallocated
WTASFLA2
WTASHERE 8 WTASHERE Block has been used
So new MXG variable SM116EVT is now created, with
LABEL S116VENT='EVENT*I=INTERVAL*T=THREAD END';
IF WTASFLAG='..11....'B THEN SM116EVT='T';
ELSE SM116EVT='I';
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.048 A new version of the CLRMFV TSO Clist, the driver for the
CLRMFV ASMRMFV RMF Monitor III decompression utility, adds new
DOCLRMFV options to provide better support for the single large
Apr 23, 2006 output file if can now create with CALLBY(ALL):
-OUTSCL() SMS STORCLAS, now default is null.
-OUTMCL() SMF MGMTCLAS, now default is null
-OUTMLQ() to specify middle level qualifier for RMF dsn.
-OUTRLSE() to specify YES or NO (YES is default)
-OUTTYPE() to specify DSNTYPE.
See DOCLRMFV for full description and usage notes.
A special thanks to Acxiom leadership for allowing this
effort to continue to go forward.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.047 LABEL statements with duplicated variable names are now
Apr 23, 2006 detected in MXG's QA stream, and all have now been fixed.
DOC In some cases, this was a real error: two different data
fields were stored in the same variable, so a new named
variable had to be created for that second field. All of
the other cases were examined and the "better" label was
kept. SAS uses the last label it compiles, so if "last"
was "better", then there was no change, but some labels
will now be different (and, hopefully, "better').
Change 24.046 zIIP support. (APAR OA13499, z/OS 1.6, 1.7, and 1.8).
VMAC30 The metrics and variables for the new zIIP engines are
VMAC7072 very much like the metrics for IFA/zAAP engines.
VMACDB2 -TYPE30 New Variables:
VMACRMFV CPUZIPTM='TOTAL*EQUIVALENT*CPU TIME*ON_ZIP'
VMXG70PR CPUEZITM='INDEPENDENT*ENCLAVE*CPU TIME*ON ZIP'
Apr 20, 2006 CPUDZITM='DEPENDENT*ENCLAVE*CPU TIME*ON ZIP'
Jun 5, 2006 CPUZIETM='ZIP-ELIGIBLE*CPU TIME*ON CP'
Jun 13, 2006 CPUEZETM='ZIP-ELIGIBLE*IND ENCLAVE*CPU TIME*ON CP'
Jun 14, 2006 CPUDZETM='ZIP-ELIGIBLE*DEP ENCLAVE*CPU TIME*ON CP'
Jun 15, 2006 CPUEZQTM='ZIP-QUALIFIED*IND ENCLAVE*CPU TIME'
Jun 22, 2006 CPUDZQTM='ZIP-QUALIFIED*DEP ENCLAVE*CPU TIME'
Oct 13, 2006 ZIPUNITS='ZIP-EQUIVALENT*CPU*SERVICE*UNITS'
ZIEUNITS='ZIP-ELIGIBLE*CPU*SERVICE*UNITS'
-TYPE70 New Variables
NRZIPCPU='NUMBER OF*ZIP*ENGINES*AVAILABLE'
Oct 13, 2006 Note: Originally spelled NRZIPS in
this text, I chose NRZIPCPU for the new name in all
TYPE70/RMFINTRV/ASUM70PR/ASUMCEC/etc datasets.
Since NRIFAS already existed in TYPE70/RMFINTRV,
I had to leave that spelling in those datasets, but
I used NRIFACPU in the ASUM70PR/ASUMCEC/.. datasets
which previously didn't have a count of IFAs.
SMF70SUP='ZIP PROCESSORS*ONLINE*AT END OF*INTERVAL'
PCTZIPBY='ALL ZIPS*PERCENT*BUSY (DISPATCHED)'
ZIPAVAIL='ZIP*PROCESSOR*AVAILABLE?'
ZIPACTTM='ZIP ENGINE*EXECUTING*(ACTIVE) CPU TIME'
ZIPUPTM ='ZIP ENGINE*AVAILABLE*(UP) TIME'
ZIPWAITM='TOTAL*ZIP WAIT*DURATION'
ZIPWAIT0='ZIP WAIT*DURATION*ZIP 0'
ZIPWAIT1='ZIP WAIT*DURATION*ZIP 1'
ZIPWAIT2='ZIP WAIT*DURATION*ZIP 2'
... 3 thru 30 ...
ZIPWAITW='ZIP WAIT*DURATION*ZIP 31'
ZIPWAITX='ZIP WAIT*DURATION*ZIP 32'
PCTZIBY0='ZIP 0*PERCENT*CPU BUSY TIME'
PCTZIBY1='ZIP 1*PERCENT*CPU BUSY TIME'
PCTZIBY2='ZIP 2*PERCENT*CPU BUSY TIME'
... 3 thru 30 ...
PCTZIBYW='ZIP 31*PERCENT*CPU BUSY TIME'
PCTZIBYX='ZIP 32*PERCENT*CPU BUSY TIME'
-TYPE72GO New Variables
CPUZIETM='ZIP*ELIGIBLE*CPU*TIME'
CPUZIPTM='ZIP*CPU*TIME'
R723CIFA='IFA*SERVICE*UNIT'
R723CIFC='IFA-ELIGIBLE*SERVICE*UNITS'
R723CSUC='ZIP-ELIGIBLE*SERVICE*UNITS'
R723CSUP='ZIP*SERVICE*UNITS'
R723SUCU='ZIP-ELIGIBLE*ON CP*USING SAMP'
R723SUPD='ZIP*DELAY*SAMPLES'
R723SUPU='ZIP*USING*SAMPLES'
ZIEUNITS='ZIP*ELIGIBLE*UNITS'
ZIPUNITS='ZIP*SERVICE*UNITS'
-DB2 CPU Time fields added to DB2ACCT (APAR PK18454).
QWACZIEL='CPU TIME*ZIP ELIGIBLE*ON CP*ENGINE'
QWACZIS1='CPU TIME*EXECUTING*ON ZIIP'
QWACZIS2='CPU TIME*IN DB2*EXECUTING*ON ZIIP'
QWACZITR='CPU TIME*IN TRIGGERS*EXECUTING*ON ZIIP'
-DB2 CPU Time field QPACZITM for Package ZIP execution:
QPACZITM='CPU TIME*
-RMF Monitor III fields added to CPUG3 segment for zips:
CPUITSUP='LOGICAL CPU*TIME ON*ZIP*PROCESSORS'
CPUPRSUP='ONLINE*TIME ON ZIP*PROCESSORS'
CPUSTSUP='PHYSICAL CPU*TIME ON*ZIP*PROCESSORS'
CPUSUCOL='AVERAGE*ZIPS*ONLINE*DURING*INTERVAL'
CPUSUCON='ZIP ENGINES*ONLINE*AT END'
See Change 24.181 for more RMF III zIIPs data.
-ASUMCEC new calculated variables:
PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'
PCTZIPBY='ALL ZIPS*PERCENT*BUSY (DISPATCHED)'
Jun 5: VMAC7072 was revised to correctly input variables
R723SUP/R723CSUC/R723CIFA/R723CIFC.
Jun 13: Some 70 zIIP variables had IFA in their labels.
Jun 14: Some 30 zIIP variables had IFA in their labels.
Jun 15: DB2 zIIP variables created in DB2ACCT,DB2ACCTP
Jun 15: TYPE72GO fields added to KEEP=, LABEL.
Jun 20: Change 24.105 revised ASUM70PR for zIIPs.
Jun 22: VMACRMFV updated for RMF Monitor III Zip data.
-And now that IFA/ZIP text is in all MXG variable labels,
the APAR documents that IBM has changed RMF reports to
now print 'AAP' for IFA/zAAPs and 'IIP' for zIIPs, but
I am not going to change either those existing labels nor
the variable names that already exist.
Change 24.045 Support for APAR UK12301 (Tivoli Allocation Optimizer SMF
VMACTIAO record) adds flag bit for Not Cataloged 2 error condition
Apr 19, 2006 (which only applies to non-SMS-managed datasets!), and
new TIAOVOL variable if Not Cataloged bit is on, with the
VOLSER of the dataset in error.
Change 24.044 Variable BEGTIME was missing in DB2STATB dataset for the
VMACDB2 startup record (QWHSISEQ=1), which is now corrected (by
Apr 19, 2006 setting BEGTIME=ENDTIME=QWHSSTCK and DURATM=0). But for
the first instance of each Buffer Pool that was not a
startup record, not only was BEGTIME a missing value,
but also the rest of the variables were trash, because
the accumulated values were output. A long term solution
would be to introduce "SPIN" logic into DB2 processing,
but as no one has noticed the trashed data, and as the
introduction of the need for the //SPIN DD into stanalone
DB2 processing could cause well-running programs to fail,
my present solution is to not output that first instance,
and if that observation is truly ever needed for ad hoc
problem analysis, using the prior day's SMF data and
today's SMF data, concatenated as input, will completely
provide correct data, without a redesign to use SPINing.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 24.043 Variables PCTCPUBY=. and CPUACTTM=. in PDB.TYPE70 dataset
VMAC7072 if the SYSTEM is is not-LPARed, but instead only exists
Apr 7, 2006 as a single image. This case is now detected and the
code sets PCTCPUBY=PCTMVSBY, and CPUACTTM=CPUMVSTM.
Thanks to Ronald Kveton, Experian, USA.
Thanks to William Whitehead, Experian, USA.
Thanks to John Rourke, Experian, USA.
Change 24.042 Support for CPC RMF III report data, which is now INPUT
EXZRBLCP from the ERBCPUG3 segment; some of the variables are
IMACRMFV output into the existing ZRBCPU dataset, but the LCPUADDR
VMACRMFV details are output in the ZRBLCP dataset.
VMXGINIT Five of the new fields in ZRBCPU dataset are accumulated:
Apr 7, 2006 CPUPRIFA, CPUWEICD, CPUWEIND, CPUUNCTD and CPUCAPTD and
a revision to this change will be made shortly to sort
and deaccumulate those values, and this text will be
revised when that logic has been added and tested.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 24.041 As noted in Change 23.132, the new MACHTIME variable was
VMAC7072 created but not validated, and my guess to add SMF70HOF
VMAC89 was incorrect; test data shows that SMF70HOF is to be
Apr 7, 2006 subtracted in VMAC7072 to get back to true GMT.
May 1, 2006 May 1: test 89 data confirmed SMF89HOF is also to be
subtracted in VMAC89 to create MACHTIME; Change 24.063.
Thanks to Manfred Giezendanner, Credit Suisse, SWITZERLAND.
Thanks to Gion Cabernard, Credit Suisse, SWITZERLAND.
Change 24.040 CICS/TS 3.2 iteration 2 time fields 12 bytes, April.
VMAC110 CICS/TS 3.2 iteration 3 time fields Pib8.8/4096.
Apr 7, 2006 Sep 21: UTILEXCL expanded for Iteration 3.
Sep 19, 2006 Oct 14: Updates for the changed Statistics Subtypes
Oct 14, 2006 (INCOMPATIBLE except for DST,DSR,MNG):
STID DSNAME New Variables added.
- 2 SMS
==> Nothing New in DSECT.
- 64 CICDST DSTCIUHI DSTCIULO DSTNIUHI
DSTNIULO
==> But 20 bytes added are not doc'd.
- 65 CICDSR DSRCIULO DSRCIUHI
==> But 20 bytes added are not doc'd.
- 67 CICFCR DFHA17DS DSECT.
==> Nothing New in DSECT
- 74 MQG MQ Connection Statistics Global
New
==> DFHMQGDS DSECT does not exist
- 81 MNG New Compression Variables
==> DFHMNGDS DSECT is not current.
-109 ISR IP Connection (Resource)
New
==> DFHUSRDS DSECT does not exist
-117 SJG
==> Nothing New in DSECT.
-117 SJR
==> Nothing New in DSECT.
Change 24.039 New example program to create a Monthly PDB from only the
JCLMNTHW six weekly PDBs that might be required to span the prior
MONTHWEK month when only WEEK PDBs are to be read. This example
can be run on any day of the next month to create last
Apr 7, 2006 Month's PDB library. You would still need to tailor:
May 4, 2006 JCLMNTHW - the _SELDSN macro to list only the datasets
that you want created, and
MONTHWEK - delete two lines (MACRO _DSET, MACRO _BYLIST)
for each dataset that you do not want created.
May 4: Revised to read 6 weekly files; while only five
are needed for the normal MONTHBLD on the first of
the month, some months (July 2006) would need to
read six weekly PDBs to create that month's PDB
if only the week PDBs were to be read.
Thanks to William Carroll, Grange Insurance, USA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 24.038 "ERROR: UNABLE TO CREATE PDB.MXGENG.DATA BECAUSE VIEW
VMXGENG PDB.MXGENG.VIEW ALREADY EXISTS" with MXG 24.01 BUILDPDB
Apr 5, 2006 occurs only if OPTIONS='USER=PDB' was specified
For BUILDPDB that option should never be used. It
tells SAS to write all datasets that would have been
written to the //WORK DDname, to instead be written
to the //PDB DD. But the BUILDPDB design is to write
first to the //WORK DD, sort and write the output to
the //PDB DD, so you can get I/O between volumes and
not hammer the //PDB DATASET by read and write to a
single PDB library for both work and output.
The VMXGENG code used to create MXGENG as a VIEW, and
with USER=PDB, that created PDB.MXGENG.VIEW in the //PDB
library each day, but you can replace a SAS VIEW with a
SAS VIEW of the same name. But Change 23.328 revised
VMXGENG to create a DATASET of the same name, rather than
a VIEW, and (for reasons I don't understand) SAS will not
let you replace a VIEW with a DATASET, so this error
occurred when the new MXG Version wrote to a //PDB that
had been created by the prior version, that still had the
VIEW. By removing the USER=PDB option, the MXGENG and
similar MXG internal facilities' data will be written to
//WORK which is temporary and goes away at job step end,
so the replacement of a VIEW with a DATASET never is an
issue.
Thanks to Karen Fry, Comerica, USA.
Thanks to Theresa Johnston, Comerica, USA.
Change 24.037 A new version of the CLRMFV TSO Clist, the driver for the
CLRMFV ASMRMFV RMF Monitor III decompression utility, plus major
DOCLRMFV enhancements in the documentation in the DOCLRMFV member.
Apr 4, 2006
This CLRMFV version reduces the number of ASMRMFV calls
for users with many LPARs, and provides more flexibility
to specify the input and output data sets, so perhaps it
reduces the need to tailor CLRMFV or at least is easier.
There are no changes required for the ASMRMFV program.
Enhancements:
A new parameter CALLBY() lets the user control the
granularity of the RMF Monitor III data passed to ASMRMFV
in each call. CALLBY(DSN) invokes ASMRMFV once for each
and every RMF Monitor III data set. This setting is NOT
recommended due to overhead and is only included for
compatibility with earlier versions of CLRMFV.
CALLBY(SID) invokes ASMRMFV once for each unique LPAR and
is compatible with CLRMFV default behavior in prior
versions. CALLBY(ALL) invokes ASMRMFV once for all LPARs
and is ideal for users (such as our installation) who
want to process many LPARs at once with ASMRMFV with
minimal overhead. CALLBY(ALL) is the new default.
The ONECALL() parameter is now obsolete. If ONECALL(NO)
is coded, it is converted to CALLBY(DSN). If ONECALL(YES)
is coded it is converted to CALLBY(ALL). ONECALL() will
be removed entirely in a future version of CLRMFV, but is
here so you have plenty of time to remove it and use the
CALLBY() instead.
A new parameter INLLQ() lets the user specify the low
level qualifier if needed for the input RMF Monitor III
data set names. The default is null. Similarly a new
parameter OUTLLQ() lets the user specify the low level
qualifer for the output sequential data set(s). The
default is OUTLLQ(RMFIII) and produces the same data set
name as in prior CLRMFV versions.
A new parameter OUTDISP() gives the user more control on
the allocation method for the output data set(s). There
are three possible values: NEW, MOD, and OLD. The default
is OUTDISP(NEW) and produces the same behavior as prior
CLRMFV versions. See the DOCLRMFV documentation member
for more details. Regardless of this parameter setting
ASMRMFV always appends data from multiple input files
into the output file(s). Only the initial output file
allocation procedure is affected by OUTDISP().
A new parameter OUTDCL() allows the user to specify an
SMS Data Class for the output file(s). The default is
null. This is a companion to OUTMCL() and OUTSCL()
parameters which were available in the prior version for
SMS Management Class and SMS Storage Class respectively.
A new parameter OUTVOL() allows the user to specify a
non-SMS volume serial(s) for the output file(s). The
default is null.
A new parameter OUTVOL#() allows the user to specify a
maximum volume count for the output file(s). The
default is null. The z/OS maximum is allowed 255 and
CLRMFV will validate the value.
A new parameter OUTDEV#() allows the user to specify a
device count for the output file(s). The default is
null. The z/OS maximum allowed is 59 and CLRMFV will
validate the value.
A new parameter TS() allows the user to specify time
stamping on CLRMFV messages. The default is TS(NO) and
only the very first and last messages are time stamped.
TS(YES) causes all CLRMFV generated messages to be time
stamped and so provides the behavior in prior CLRMFV
releases. TS(NO) reduces CLIST overhead.
CLRMFV will now validate that the length of the total
PARM field passed to ASMRMFV does not exceed z/OS 100
character maximum and fail if this is not the case. As
before the //SYSIN DD in JCL can be use to provide
additional ASMRMFV parameters to overcome this z/OS
limitation.
The DOCLRMFV documentation member is enhanced, expanded,
and clarified to explain all the new parameters.
Migration Issues:
With the new CLRMFV default of CALLBY(ALL) the single
output file size will be now the sum of space used for
all the prior LPAR files with the old CLRMFV version .
The SPACE() parameter will need to be increased
substantially if output is to DASD to avoid SB37 abends
or alternately the output file will have to be directed
to tape. The new OUTDEV#() parameter can also help with
the additional space needs by spreading the space needed
over multiple volumes.
The benefit is a reduction in CPU usage by ASMRMFV
because initialization, termination, and summary code is
only used once instead of once for each LPAR. Users who
prefer not to make changes to support CALLBY(ALL) should
specify CALLBY(SID) to get the prior behavior.
With CALLBY(ALL) the single output data set name will be
of the form &OUTHLQ.ALL.&OUTLLQ where &OUTHLQ is the
value of OUTHLQ() and &OUTLLQ will be the value of
OUTLLQ(). So DSN= on the //RMFBSAM DD statement in the
MXG RMF III PDB Build step will need to be changed
accordingly. A DD concatenation of files from multiple
LPARs will no longer be required and the extra DDs should
be removed.
Since all RMF Monitor III data sets will be dynamically
allocated at once with CALLBY(ALL), users may need to
substantially increase the value of DYNAMNBR= in their
JCL invoking CLRMFV. Otherwise the Dynamic Allocations
done by CLRMFV can fail. The TIOT SIZE parameter in the
ALLOCxx member in SYS1.PARMLIB ultimately determines the
maximum size value allowed for DYNAMNBR=. This is
discussed in the DOCLRMFV member.
As a side effect since CALLBY(ALL) results in ASMRMFV
being invoked only once, the ASMRMFV summary report
produced will be for the grand totals from all LPARs
instead of 1 summary report per LPAR as in the prior
version. Users who want the earlier behavior should use
CALLBY(SID).
A special thanks to Acxiom leadership for allowing this
effort to continue to go forward.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.036 An extra, undocumented 8 bytes have been added to the
VMACRMFV RMF III ASI table in z/OS 1.7, although IBM will issue
Apr 4, 2006 a documentation change in the future. This change tests
for ASIVERE3 GE '10'X to skip the extra 8 bytes.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Rodger Foreman, Acxiom CDC, USA.
Change 24.035 XAM SYS error INPUT STATEMENT EXCEECED LENGTH was caused
VMACXAM by an unexpected value of 'FFFF'x in the NSIMBUSY field,
Apr 4, 2006 or 65536 decimal, for the number of fields in the array
HFCHSIM that follow this count, which MXG tried to read
when there were no fields following.
Now, MXG detects this value, and bypasses the logic to
read any elements of HFCHSIM array.
The 'FFFF'x value is actually -1 if input as Integer
Binary, and is set by XAM because IBM no longer keeps
track of concurrent channels in use, so there no longer
is an HFCHSIM array to INPUT.
Thanks to Brian Carter, EDS UK Mainframe Hosting Services, ENGLAND.
Thanks to Jeff Gribbin, EDS UK Mainframe Hosting Services, ENGLAND.
Change 24.034 Converting a character variable that contains a hex value
DOC (e.g., a four-byte character variable DEVCHAR='1F1A')
Apr 4, 2006 into a numeric variable that contains that hex value
Apr 20, 2006 (e.g., a two-byte numeric variable DEVNR=1F1Ax when it is
FORMATed hex4.) can be done using the HEXnn INFORMAT
in an INPUT function:
DATA;
DEVCHAR='1F1A';
DEVNR=INPUT(DEVCHAR,HEX4.);
FORMAT DEVNR HEX4.;
will store the decimal value 7962 in DEVNR, which will be
printed as 1F1A with the HEX4. format.
This change was rewritten on April 20, when the HEXnn.
format was suggested in a SAS-L posting by Jiann-Shiun
Huang. Below, is the original April 4 change text:
The format $MGHEXC can be used to convert a character
variable that contains a hex value in EBCDIC text into a
numeric variable with the value formatted as HEX.
For example, if DEVCHAR='1F1A' is DEVNR='1F1A'x, then
this code will create numeric variable DEVNR:
DEVNR= 4096*INPUT(PUT(SUBSTR(DEVCHAR,1,1),$MGHEXC.),2.)+
256*INPUT(PUT(SUBSTR(DEVCHAR,2,1),$MGHEXC.),2.)+
16*INPUT(PUT(SUBSTR(DEVCHAR,3,1),$MGHEXC.),2.)+
INPUT(PUT(SUBSTR(DEVCHAR,4,1),$MGHEXC.),2.);
The $MGHEXC format was created to decode SYSLOG character
Device Number, but can be used for any hex-text .
Thanks to DJ Chen, Florida Department of Corrections, USA.
Thanks to Jiann-Shiun Huang, AmerUs Group, USA.
Thanks to Nick Johns, Sainsbury, ENGLAND.
Change 24.033 When UTILEXCL detects CMODNAMEs of EZA01 and EZA02, you
IMACICE2 must tailor members IMACICEZ, IMACICE1, and IMACICE2 to
Apr 4, 2006 process those data. The fields INPUT in IMACICEZ and E2
are consistent at all sites, but the number of fields in
the IMACICE1 exit varies from site to site, so if MXG's
REPORT ONE lists IMACICE1 to be tailored, you must then
look at REPORT THREE to see exactly which fields are in
your data, and will have to change the INPUT and LABEL
statements if your data does not contain all twelve of
those fields. This list is an excerpt of REPORT THREE
that is overlaid with the MXG variables that are INPUT.
MEMBER=IMACICEZ:
CMODHEAD CMODNAME MXG VARIABLES
EZA01 INIT S 001 8 TCPINITM TCPINICN
EZA01 READ S 002 8 TCPREATM TCPREACN
EZA01 WRITE S 003 8 TCPWRITM TCPWRICN
EZA01 SELECT S 004 8 TCPSELTM TCPSELCN
EZA01 OTHER S 005 8 TCPOTHTM TCPOTHCN
MEMBER=IMACICE1:
CMODHEAD CMODNAME MXG VARIABLES
EZA01 EZA01 A 001 4 EZA01A01
EZA01 EZA01 A 002 4 EZA01A02
EZA01 EZA01 A 003 4 EZA01A03
EZA01 EZA01 A 004 4 EZA01A04
EZA01 EZA01 A 005 4 EZA01A05
EZA01 REUSABLE A 006 4 EZA01A06
EZA01 ATTACHED A 007 4 EZA01A07
EZA01 EZA01 A 008 4 EZA01A08
EZA01 EZA01 A 009 4 EZA01A09
EZA01 EZA01 A 010 4 EZA01A10
EZA01 EZA01 A 011 4 EZA01A11
EZA01 EZA01 A 012 4 EZA01A12
MEMBER=IMACICE2:
CMODHEAD CMODNAME MXG VARIABLES
EZA02 CONN A 001 4 EZA02CON
EZA02 STARTED A 002 4 EZA02STA
EZA02 INVALID A 003 4 EZA02INV
EZA02 DISTRAN A 004 4 EZA02DIT
EZA02 DISPROG A 005 4 EZA02DIP
EZA02 GIVESOKT A 006 4 EZA02GIV
EZA02 SECEXIT A 007 4 EZA02SEC
EZA02 NOTAUTH A 008 4 EZA02A08
EZA02 IOERR A 009 4 EZA02A09
EZA02 NOSPACE A 010 4 EZA02A10
EZA02 LENERR A 011 4 EZA02A11
(See also text of Change 25.018.)
Compare your UTILEXCL report with those three IMACICEx's.
The IMACICEZ and IMACICE2 should always match; contact
support@mxg.com (send UTILEXCL report) if they don't.
If IMACICE1 in your REPORT THREE ends with "ATTACHED" as
the last field (i.e, you only have 7 fields in EZA01),
then must EDIT the IMACICE1 member into your tailoring:
-change the test for MCTSSDRL to GE 28 instead of GE 48
-delete the LABELs for variables EZA01A08 thru EZA01A12
-change the INPUT statement to read
INPUT (EZA01A01-EZA01A07) (&PIB.4.) @;
-You create REPORT THREE with the _RPTEXCL macro run with
or after your UTILEXCL execution:
//SYSIN DD *
%INCLUDE SOURCLIB(UTILEXCL);
_BLDDICT;
_BLDEXCL;
_RPTEXCL;
-This change added text in labels for EZA02A08-EZA02A11
with their contents (NOTAUTH,IOERR,NOSPACE,LENERR).
-This text was revised Oct 10, 2007; see Change 25.215.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 24.032 -SPLIT70 rewrite could cause PCTCPUBY/PCTMVSBY in TYPE70
VMAC7072 to be too small, for CPs that were not online for a full
Apr 3, 2006 interval. The recalculated PCTCPUBY used DURATM in the
Apr 5, 2006 denominator instead of SMF70ONT for these CPs.
-NRCPUS was wrong if an LPAR is WLM Managed AND the LPAR
has any IFAs, which affected many PCT calculations. When
an LPAR is WLM Managed, (LPARWLMG='Y'), MXG used variable
SMF70BDA=SMF70BDA/SMF70DSA, documented as the average
number of engines under WLM control, as NRCPUS, but
impossible values of 10.27 for a system in a CEC with
only 10 CP engines was observed. Using the sum of
SMF70ONT (online time of each engine) showed there were
only 8.27 CP engines online during that interval, and
IBM's own Partition Data Report had 8.3 for the Average
Processor NUM for that LPAR for that interval. In reply
to my "impossible" value allegation, IBM RMF Development
replied that SMF70BDA samples include both CPs and IFAs,
and thus the 10.27 value was not impossible, as there
were 8.27 CPs and 2 IFAs online; however it is a
completely useless value to use for anything.
As a result, the MXG calculation of NRCPUS is now always
calculated from the sum of SMF70ONT for CP engines, and
SMF70BDA is no longer used for NRCPUS.
And SMF70BDA will also include zIIPs, if any exist.
Thanks to Marco A. Micchia, Uniocredit Global Info Services, ITALY.
Change 24.031 Cosmetic cleanup of MXG variables during ITRM validation
ASUMTAPE for their dictionary updates:
VMAC80A -VMACTMNT: Variables SYSLDDN,SYSLDSN now labeled.
VMAC94 -VMAC80A : Variables TSREADTI,TSTIME now formatted, TSTIME
VMACTMNT is now KEPT in TYPE80TS dataset.
VMXG70PR Variable TOKDANAM now labeled.
VMACTMO2 -VMXG70PR: Formats for new variables added for 60 LPARs
Apr 3, 2006 were missing in ASUMCEC dataset.
Apr 10, 2006 Sort order in _BSU70PR was incorrect, but it
was not used, so only caused confusion and
deceptive documentation. Correct BY list is
SYSPLEX SYSTEM SYSNAME SMF70GIE
-ASUMTAPE: Instances of %VMXGWORL inside the MACRO _DEBUG
require double percent signs.
-VMAC79: Variables R799CNX2-5 were incorrectly decoded.
R799CNX is now labeled even though its decoded.
-VMAC94: Variables S94XLCSI/S94XLCLS are now kept; they
had been misspelled as XCLSI/SCLSL.
-VMACTMO2: Label for TAWRDCT corrected; QA stream now
tests for duplicate/different labels.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.030 Solaris 9 changed the format of the year in sar data from
TYPEUSAR YY to YYYY; code was revised to support either format.
Apr 3, 2006
Thanks to Greg Meyer, ITresources, USA.
Change 24.029 ERROR.CMRFILE. FILE SEGMENT LENGTH IS 16 BUT 220 EXPECTED
VMACMVCI messages are eliminated. The two file segment sizes are
Apr 2, 2006 supported. The short segment will cause missing values
in most variables in CMRFILE, but the data is valid.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Change 24.028 Support for APAR PK15468, which adds variable QWSnPSRB,
VMACDB2 Preemptable SRB CPU Time consumed by SRBs in the Address
Apr 1, 2006 Space named in QWSnASID. Note that this SRB CPU time in
the new QWSnPSRB variable is included in QWSnSRBT.
Thanks to Roger L. Rush, Nav-International, USA.
Thanks to James S. Lazowski, Nav-International, USA.
Change 24.027 SQL Text in DB2 102 Audit Trace IFCIDs 140,141,142,145
VMAC102 was missing after Change 24.01, for DB2 Version 7 and
Apr 1, 2006 earlier, because QW014nLE was only INPUT for DB2 8.1.
Now, IF QW014nLE=. THEN QW014nLE=QW014nLL; corrects.
Thanks to Jim Kovarik, AEGON USA, USA.
Change 24.026 Equal signs were missing from most of the value in the
FORMATS $MGSYSIP format definition.
Apr 1, 2006
Thanks to Lars-Olof Thellenberg, Svenska Handelsbanken, SWEDEN.
Change 24.025 Five 4-byte SYNCSORT fields had expanded 8-byte fields
VMACSYNC that MXG failed to use when the 4-byte fields were full.
Apr 1, 2006 These variables are now reset if their 8-byte field is
greater than their 4-byte field:
CHARACTS INRECS OUTRECS INSERTS DELETES
Unfortunately, the input and output byte count variables,
SIBYTES and SOBYTES exist only as 4-byte fields and do
not have 8-byte counterparts.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 24.024 New E2dddddd members created for "2 Phase" MXG datasets:
E2TY70 -Most MXG datasets are "SIMPLE" or "One Phase": obs are
E2TY70PR OUTPUT to a _Wdddddd dataset in the _Edddddd exit macro
VMAC7072 (which %INCs the EXdddddd exit member) from the raw data,
Apr 1, 2006 then _Wdddddd is sorted to create the _Ldddddd (PDB).
May 1, 2006 For those datasets, code in the EXdddddd member can be
used to create new variables and label them, and the
_Kdddddd macro is used to KEEP those new variables.
-But when datasets are created in a "Second Phase", those
original EXdddddd exit cannot be used for your SAS code
that creates your new variables; instead, you must use
a new exit member, the "Second Phase" exit. The name of
the member is E2dddddd, to be somewhat consistent with
the original EXdddddd naming; your SAS code to create or
modify variables, and LABEL, FORMAT or LENGTH statements
would be put in your E2dddddd exit member.
Note: all variables you create in that exit member
will automatically be KEPT, so you do not need to list
them to be kept. In fact, if you create any temporary
variables in your exit code, you would need to DROP
them so they won't be kept in the output dataset.
-The old EXdddddd exit member had an old-style macro
counterpart, MACRO _Edddddd, which could be redefined in
your IMACKEEP member. So this new "Second Phase" exit
member also has an old-style macro counterpart, named
MACRO _2dddddd, which can alternatively be used to tailor
these datasets.
-The SPLIT70 redesign changed the creation of TYPE70 and
TYPE70PR datasets from "SIMPLE" to "SECOND PHASE", and
thus invalided the use of EXTY70/EXTY70PR exit members
to add variables to the TYPE70 and TYPE70PR datasets, so
this first implemenatation of "Second Phase" exits are
the E2TY70 and E2TY70PR members added by this change.
May 1: SPLIT70 redesign documentation, related note:
You cannot drop these variables
SYSPLEX SYSNAME SMF70GIE SMFTIME
from TYPE7xxx RMF datasets. They are required
to reassemble the pieces, and the MXG logic.
-Example to add SHIFT to the PDB.TYPE70 and PDB.TYPE70PR
datasets you would need to add these two old-style macro
redefinitions in your IMACKEEP tailoring member:
MACRO _2TY70
%%INCLUDE SOURCLIB(IMACSHFT);
%
MACRO _2TY70PR
%%INCLUDE SOURCLIB(IMACSHFT);
%
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Warren Cravey, Fidelity Systems, USA.
Change 24.023 The default value of macro variable &TAPENGN, used for
VMXGINIT the engine for the TAPETEMP DD in Weekly/Monthly examples
Apr 1, 2006 that output to tape, is now changed to V9SEQ if executing
Jun 24, 2006 MXG under SAS V9, or to V8SEQ if executing under SAS V8.
This should have been done back in Change 23.061, which
changed CONFIGV9 to set the MXG default SEQENGINE=V9SEQ,
(it previously had been V6 due to SAS errors in V9SEQ),
but changing TAPENGN default was overlooked. The V6SEQ
engine does not support character variables longer than
200 bytes, and there are now many long variables in MXG.
Jun 24: The April change caused UNKNOWN ENGINE V9SEQ when
the Weekly or Monthly job was run for the first
time under SAS V8. New logic now tests the
&SASVERS to set V8SEQ or V9SEQ as appropriate.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 24.022 The BY list in the default MONTHBLD example for ASUMDB2B
WEEKBLD now ends with ... QBACPID QWACBSC SHIFT to match the BY
MONTHBLD list used to build PDB.ASUMDB2B.
Mar 31, 2006 Jul 3: Unfortunately, the March change incorrectly had
Jul 3, 2006 MONTHBLD with QWACPID instead of QBACPID, and
WEEKBLD had QWACPID QBACBSC, and the preceding
change test also had incorrect spellings.
Now, all BYs agree with line 2 of this change.
Thanks to Michael Creech, Fidelity National Information Svcs, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 24.021 A invalid RACF SMF 80 record with NRSEGS=252 but that had
VMAC80A only 235 actual segments caused INPUT STATEMENT EXCEEDED.
Mar 31, 2006 The last segment was complete, and the RDW matched the
size of the actual SMF record, so this was not a record
that had been truncated in SMF post-processing. MXG now
prints an error message and hex dump on the log for each
instance of this type of invalid SMF record, so you can
send to IBM RACF Support if you choose to resolve their
invalid record. Jun 13, 2006: See Change 24.097.
Thanks to Randy Shumate, LexisNexis, USA.
Change 24.020 ASUMTAPE is still in development, pending STK reply to
ASUMTAPE our problem with their exit, but I accidentally made it
Mar 7, 2006 fail if run under ITRM; I replaced the previous use of
%VMXGWORL macro (to find the location, WORK or PDB, of
the input datasets) with hardcoded &MXGPDB..TAPES and
similar references. Now, the use of %VMXGWORL is
reinstated.
Thanks to Dan Squillace, SAS Institute ITRM, USA.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.019 MXG set OPTIONS DKROCOND=NOWARN in BUILD001/BUILD005/3005
BUILD001 to prevent WARNING: VARIABLES NOT REFERENCED messages,
BUILD005 as those members execute code with many optional variable
BUIL3005 names in its KEEP= lists, but in BUILD005/3005 the option
Mar 7, 2006 was reset back to DKROCOND=WARN, and if your code had the
condition, the warning message caused condition code 4.
So the hardcoded reset changed the MXG DKROCOND=NOWARN
that is set by CONFIGVn/AUTOEXEC at initialization.
Now, %VMXGOPTR is used to store the original value of the
DKROCOND option, and the hardcode reset is change to now
restore the original value of the option.
And so you won't see any of these messages, unless you
change the OPTION after MXG initialization, in your
code or in mine.
Thanks to H.E. Tempelmans Plat, Corus, THE NETHERLANDS.
Change 24.018 INPUT STATEMENT EXCEEDED in RACF Extended Relocate 301
VMAC80A SMF30TP2 because new TOKSUBSY='PROXY' records were not
Mar 6, 2006 supported.
Thanks to Fred Schmidt, Northern Territory Government, AUSTRALIA.
Change 24.017 Two four-byte fields were inserted in the SYTCUP segment,
VMACXAM causing INVALID DATA FOR SYTNLPMG messages, and trashed
Mar 5, 2006 data in some SYTxxxxx variables. New variables SYTPCTBY
and SYTPCTOV for each LCUCPUID are now created and kept
in the XAMSYT dataset.
-IODQDS segment no longer flagged as UNKNOWN.
Thanks to Tony Curry, BMC, USA.
Change 24.016 Datetimestamp variables WTNIDTIM, WTUOWTIM and QWHSSTCK
VMAC116 were not called by %VMXGTIME, which is used to shift date
Mar 2, 2006 time variable's values to a common time zone, if you have
LPARs or SYSTEMs on different time zones.
Note that while UOWTIME contains a datetime value, it is
never shifted, because it is used as a token to match to
other records; this part of Change 19.286 is added in the
comments in VMXGTIME as a self-reminder:
Two very important "token" variables that are necessary
to match records together, READTIME and UOWTIME, are
NOT converted by VMXGTIME.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.015 Documentation only. Identifying CRYPTO users and usage.
VMAC30 -TYPE30 variable ICSFSCNT/SMF30CSC may or may not identify
VMAC7072 crypto users. It is the number of crypto instructions
Mar 1, 2006 executed on behalf of the caller (within that caller's
address space). However, new machine instructions are
available on T-Rex processors with the CPACF feature that
provide clear key DES/TDES functions as well as hashing
functions, and applications can call these functions
directly, bypassing ICSF, and those application calls
would NOT be included in this count.
-TYPE70Y2 Crypto dataset variables added by OA10556 in
MXG 23.05 to record these CPACF function statistics:
R702NH2B='SHA-256*DATA*BYTES*HASH'
R702NH2C='SHA-256*CALLS*TO*HASH'
R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH'
-This information was extracted from a lengthy and very
informative IBM note ASKQQA Item BDC000034378, in reply
to the question "Is there a way to measure encryption
overhead in TLS/SSL for TN3270":
There is no separate SMF field that tells you how much
CPU time is consumed to do this encryption. However,
since it is the TCP/IP address space that is doing the
instructions for encryption, the CPU time consumed
would be included in the regular SMF fields for that
Address Space, i.e., both TYPE30 for the ASID and
TYPE72GO for its Service Class and Reporting Class.
The CPU time consumed by the PCIXX engine (the
handshake part) will be reported in the R7023T0 in
dataset TYPE7002 (RMF 70 subtype 2 crypto).
-That note suggests that for other crypto applications,
their CPU time will also be recorded in the address space
and service class records for the address space that does
the encryption. The TYPE1415 record now contains the
elapsed time for tape encryption, but no separate CPU
time exists in any address space records.
Change 24.014 Support for new QWSnPSRB DB2 Address Space preemptable
VMACDB2 and non-preemptable SRB CPU time in PDB.DB2STATS dataset.
Mar 1, 2006 Variables QWSnSRBT have always contained the SRB time for
DB2 Address spaces and for the IRLM Address space, and
included both preemptable and non-preemptable SRB time.
New variables QWSnPSRB will now contain only the SRB CPU
time consumed by preemptable SRBs in the address space
specified by QWHAASID.
Note: CHANGE was made in Change 24.028.
Change 24.013 Support for new memory object data in DFSORT records:
VMAC16 ICEMON - MEMORY OBJECTS ALLOCATED
Mar 1, 2006 ICEMOUSE - MEGABYTES USED FOR MEMORY OBJECTS
ICEMOSIZ - MOSIZE VALUE IN EFFECT
MEMOBJUS - MEMORY OBJECT USED?
These data were added in z/OS DFSORT V1R5
Thanks to Rob D'Andrea, Royal Bank of Scotland, UNITED KINGDOM.
====== Changes thru 24.012 were in MXG 24.01 dated Mar 1, 2006=========
Change 24.012 INPUT STATEMENT EXCEEDED in RACF Extended Relocate 301
VMAC80A SMF30TP2 because MXG only expected 8 bytes for TOKDANAM.
Feb 27, 2006 Field expanded to 80. Values of NOCPUTIMAX, NOASSIZMAX,
NOFILEPROCMAX NOPROCUSERMAX NOTHREADSMAX NOMMAPAREAMAX
are observed as values for TOKDANAM, with no values after
the TOKDANAM field.
Thanks to Fred Schmidt, Northern Territory Government, AUSTRALIA.
Thanks to Andrew Krink, Northern Territory Government, AUSTRALIA.
Thanks to Scott Thomson, Northern Territory Government, AUSTRALIA.
Change 24.011 Negative and missing values were created in PDB.TYPE30_6
VMAC30 after Change 23.296 revised the deaccumulation logic to
Feb 27, 2006 support wrapping of ACTIVETM/RESIDTM. Additionally, the
coversion of GMT timestamps to local using GMTOFF30 fails
when ONLY subtype 6 records are read; subtype 6 records
don't contain the SYNCTIME value needed calculate the GMT
offset, so MXG gets the RETAINed GMTOFF30 from the prior
SMF 30 record of different subtype.
-The errors could also cause fewer observations to be
created in PDB.TYPE30_6.
-However, variable GMTOFF30 will still be missing value in
PDB.TYPE30_6 if no prior 30s were found, and that will be
the only clue that the INTBTIME/INTETIME/SYNCTIME values
that MXG created (for symmetry with PDB.SMFINTRV) are not
on local time, but are still on GMT.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Change 24.010 Variable LPARNSW (percent when capped) in RMF/NTRV and
VMAC7072 TYPE70 datasets could be zero when capping was active,
Feb 26, 2006 due to an error in the SPLIT70 redesign. The statement
LPARNSW=SMF70NSW should only have been executed when the
LPARNUM=PARTISHN, but it was mislocated and executed for
the last LPARNUM. And, of course, my test data did have
PARTISHN equal to the last LPARNUM, so the error was not
caught sooner.
-Array subscript out of range with exactly 60 LPARS. The
S70LPCP array was defined with 60 elements, but 61 are
needed to account for the PHYSICAL LPAR. I had assumed
than only 59 real LPARs plus the PHYSICAL was the limit.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 24.009 Variable AVGWKSET in TYPE30 datasets was too large if you
VMAC30 have IFAs, because I didn't know that PAGESECS, which is
Feb 27, 2006 the source of AVGWKSET, is based on service, and IFA time
and TCB time are included in service. IBM separates the
IFA and TCB time in RMF for performance management, and
in SMF for charge back, but doesn't separate them in the
Service Units, nor for TIME= on JCL, or in the CPUTIMER
or TIMEUSED services. zIIPs will be handled the same
way. This would be important if AVGWKSET and PAGESECS
had any real use in memory utilization measurmement, but
they don't, as PAGESECS only counts the memory frames
owned by the task when it is executing TCB or IFA. All
of the pages owned by the task while in wait state
(wait for CPU dispatch, page fault, I/O, cross memory)
are NOT counted in PAGESECS. In addition, AVGWKSET by
itself is a poor metric, because it only measures the
average number of pages that might be swapped out; it
does NOT measure memory utilization because it does NOT
indicate how LONG those pages were held. Why does the
AVGWKSET exist? Primarily for modeling programs, which
can take that as a metric, and inside the model, multiply
by the modeled duration, so the model program can measure
memory utilization (like old K-Core HOURS) and compare
with the memory capacity (GIGABYTES times 24 Hours).
And finally, tasks don't "OWN" real memory; z/OS decides
how much memory to dole out to tasks based on service
objectives, so whatever memory utilization might be
measured is not because the task 'wanted' that memory,
but because z/OS decided to give it that memory.
-Variable CSTORE30 should never have been created as such.
It does not measure CSTORE pages, but only measures the
IARVSERV Shared Pages used by this task, and thus it is
almost always zero, except for tasks that share pages.
Shared segments allow two address spaces to have
addressability to the same data, like a private CSA,
and was added for posix compliance. The shared areas
must be overtly set up by applications and I'm not
aware of any current exploiters.
To avoid confusion, and hopefully to draw your attention
to this change, CSTORE30 is now set to a missing value.
Thanks to Gennady Katsnelson, AT&T Services, Inc, USA.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Thanks to Jack Hudnall, AT&T Services, Inc, USA.
Change 24.008 Corrections for TPF Continuous Monitor date; the "QUICK
UTILTPFC FIX" that reset 3827 to 3826 was removed, since it fixed
VMACTPFC nothing and created errors. Debugging PUT statements in
Feb 23, 2006 UTILTPFC and VMACTPFC members were commented out.
-BY variables were corrected from SYSTEM SMFTIME (MVS!!)
to the TPFC variables TPFCSS TPFCSSU TPFCTIME.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.007 Support for the "Memory Monitor" that writes an SMF
ASMUSR1 record that tracks the memory object sizes by JOB.
EXUSR1ME This is in intial testing.
FORMATS You must run FORMATS and then update IMACKEEP with the
IMACUSR1 MACRO _IDUSR1 nnn %
TYPEUSR1 definition to set the SMF record number.
TYPSUSR1
VMACUSR1
VMXGINIT
Feb 22, 2006
Thanks to Dean Montevago, Visiting Nurse Service of New York, USA.
Change 24.006 APPARENT MACRO MAC102S error with ANALDB2R or READDB2 is
READDB2 corrected with this revision, although we have NOT been
Feb 22, 2006 able to replicate the error, we know the code was wrong.
Thanks to Jim Nickolas, LEXIS-NEXIS, USA.
Change 24.005 Support for APAR OA14340 (follow on the OA11675) which
VMAC30 now creates an 8-byte field (SMF30TEX) to replace 4-byte
Feb 22, 2006 SMF30TEP when TEP overflows. Variable EXCPERR=Y is set
if bit SMF30TEF is on by OA11675, but with OA14340, MXG
stores SMF30TEX in EXCPTOTL instead of SMF30TEP, and the
EXCPERR is blanked, since EXCPTOTL is now valid.
Similar change made to SMF32 fields also.
Change 24.004 ASUMTMNT failed if _GRPMNNM and _GRPMNCD were used to
ASUMTMNT define "Locations" for tape devices; Change 23.253 had
Feb 23, 2006 changed to those macro names, but ASUMTMNT still had the
initial _Gxxxxxx names that were later changed.
Thanks to Paul Bennett, JPMorganChase, ENGLAND.
Change 24.003 Toleration support for z/VM 5.2 (INCOMPATIBLE). The 10.1
VMACVMXA Application Server 10.2 record was changed from 24 to 28
Feb 23, 2006 bytes, but there is no field with the number of entries,
nor the length of the entries, so a MOD(CALDATLN,24) and
MOD(CALDATLN,28) to create LEN0D of 24 or 28 is inserted
to figure out which length is present.
Without this correction, BROKEN CONTROL RECORD messages
are printed on the log.
There are many new data fields added to the MONWRITE data
in z/VM 5.2, and these data are not yet supported in this
change. The known records and new data lengths are here
so I can whittle them down over time:
REC SKIP REC SKIP REC SKIP REC SKIP REC SKIP
1.6 12 0.22 64 3.1 220 3.14 20 6.21 8
1.14 2 0.3 96 3.19 68 3.18 40 4.9 20
4.9 20 0.21 64 3.2 80 4.3 20
0.4 12 3.3 12 3.20 108 5.9 92
Thanks to Pat Curren, SuperValu, USA.
Change 24.002 The ML-38 default DEBUG=YES should be changed to DEBUG=NO
ASMTAPEE (unless you are specifically working with MXG support).
Feb 20, 2006 The DEBUG=YES option was intended only for investigation
Apr 7, 2006 of STK HSC exit code, and should not have been enabled,
as DEBUG=YES causes a dump for any ABEND the monitor
encounters, even ones that we know can happen.
One specific known ABEND occurs when we are in cross
memory and running TIOT entries, and the chain has
been modified while we're in it: with DEBUG=NO, that
ABEND is ignored and suppressed and our code recovers
and then continues, minus only the information we now
can't find in the modified TIOT.
However, there is NO loss of data; the SMF records were
written and the monitor continued to monitor; it is only
to suppress the unneeded dumps.
While this change was dated in Feb, and should have been
made in the ASMTAPEE member in MXG 24.01, the actual
debug option was not disabled until April 7, 2006, which
is now the LAST CHANGED date in ASMTAPEE. Only if your
ASMTAPEE is dated earlier, would you need to change the
line 3248 in that ASMTAPEE at ML-38, from what was there:
DODEBUG EQU B'00001000' DO DEBUGGING STUFF
to now read:
DODEBUG EQU B'00000000' DO DEBUGGING STUFF
and then reassemble ASMTAPEE to disable DEBUG=YES.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Thanks to Beau Chavis, Bank of America, GERMANY.
Change 24.001 The DB2 Audit Trace IFCIDs 140, 141, 142, and 145 caused
VMAC102 INPUT STATEMENT EXCEEDED error if the SQL Text length was
Feb 20, 2006 more than 4000 bytes. MXG used length field QW014nLL in
its INPUT QW014nTX $VARYING. QW014nLL, but the ERROR made
me RTFM ("F=Fine"), amd I found that IBM did document the
truncation, providing adjacent QW014nLE field with the
length of the truncated SQL text in the record, so it is
now used for the SQL text INPUTs.
And IBM doesn't always store exactly the first 4000;
one record had QW0145LL=13120, but QW0145LE=3980.
Thanks to Bjorn Helgestad, VPS ASA, NORWAY.
Thanks to Steinar Amot, VPS ASA, NORWAY.
LASTCHANGE: Version 24.
=========================member=CHANGE23================================
/* COPYRIGHT (C) 1984-2006 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 23.23 is dated Feb 20, 2006, thru Change 23.358
PreRel MXG Version 23.23 was dated Feb 15, 2006, thru Change 23.351
Final MXG Version 23.11 was dated Feb 2, 2006, thru Change 23.340
Third MXG Version 23.11 was dated Feb 2, 2006, thru Change 23.338
Second MXG Version 23.11 was dated Jan 31, 2006, thru Change 23.336
First MXG Version 23.11 was dated Jan 30, 2006, thru Change 23.336
MXG Version 23.10 was dated Jan 23, 2006, thru Change 23.328
MXG Version 23.09 was dated Dec 7, 2005, thru Change 23.309
Third MXG Version 23.09 was dated Dec 6, 2005, thru Change 23.309
Second MXG Version 23.09 was dated Dec 1, 2005, thru Change 23.303
First MXG Version 23.09 was dated Nov 30, 2005, thru Change 23.300
MXG Version 23.08 was dated Oct 27, 2005, thru Change 23.273
First MXG Version 23.08 was dated Oct 25, 2005, thru Change 23.271
Final MXG Version 23.07 was dated Aug 10, 2005, thru Change 23.209
First MXG Version 23.07 was dated Aug 9, 2005, thru Change 23.207
MXG Version 23.06 was dated Jun 29, 2005, thru Change 23.176
MXG Version 23.05 was dated Jun 7, 2005, thru Change 23.154
First MXG Version 23.05 was dated Jun 5, 2005, thru Change 23.148
MXG Version 23.04 was dated May 4, 2005, thru Change 23.107
MXG Version 23.03 was dated Apr 22, 2005, thru Change 23.090
MXG Version 23.02 was dated Apr 4, 2005, thru Change 23.061
MXG Version 23.01 was dated Mar 15, 2005, thru Change 23.050
MXG Version 22.22 was dated Feb 1, 2005, thru Change 22.378
MXG Newsletter FORTY-SIX was dated Feb 1, 2005.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. 2006 Annual MXG Software Version 23.23 automatically was sent.
II. Incompatibilities and Installation of MXG 23.23.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. 2006 Annual MXG Software Version 23.23 dated February 20, 2006.
The Annual Version was available for ftp download on Feb 20, but
a CD-ROM containing MXG 23.23 will also be sent to all sites; the
copying/packaging began on the 20th, with mailing on Feb 25th, so
all sites should receive the package in early March.
Major enhancements added in MXG 23.23 - 2006 Annual MXG Version
TYPE70 23.348 Final "70's Record Rewrite", PARTNCPU corrected.
TYPE115 23.347 Support for MQ for z/OS Version 6.0 (COMPAT)
TYPE110 23.342 Support for CANDLE UMBRELLA optional CICSTRAN data.
READDB2 23.345 New WANTONLY= enhancement for %READDB2 utility.
MONTHxxx 23.351 &MXGSYSN macro variable for compatibility.
WEEKxxx 23.351 &MXGSYSN macro variable for compatibility.
MACKEEP 23.346 DB2 Tailoring Example to add DB2 102 to PDB.
Major enhancements added in MXG 23.11
1. Corrections for "Split 70/Over 60 LPAR" RMF 70 Re-Write.
TYPE70 23.330 Corrections to Split 70/Over 60 LPAR Change 23.321.
2. Yet another major revision to RMF 70 processing:
TYPE70 23.336 Support for RMF with repeated SYSTEMs in a SYSPLEX.
3. ITRM sites that build RMFINTRV do NOT have to change anything;
the previous "INCOMPATIBILITY" that required _STY70 to be put
in your EXPDBOUT member is NOT needed when RMFINTRV is created,
and everyone SHOULD create the XRMFINT/RMFINTRV dataset.
"Routine" enhancements/changes:
TYPENDM 23.331 Support for NDM/Connect Direct subtype TF, TL, TW.
TYPE30 23.329 Support for SMF30CEPI field, new CPUCIPTM variable.
TYPE7072 23.335 Variables SMF70OIL and SMF70SYN now KEPT in TYPE70.
TYPE30_V 23.334 IMACINTV default now OUTPUTs TYPE30_V/PDB.SMFINTRV.
TYPEVMXA 23.332 Variables HFLLIST,HFPGACT were accumulated.
Major enhancements added in MXG 23.10
1. Support for over 60 LPARs. Support for Split RMF 70 records.
Required extensive rewrite of the "heart and soul" logic in the
VMAC7072 and VMXG70PR members, potentially impacting datasets
TYPE70 TYPE70PR RMFINTRV ASUM70PR ASUM70LP ASUMCEC and ASUMCELP
from TYPE7072, TYPS7072, BUILDPDB/BUILDPD3, or RMFINTRV programs.
New DATA records that now exist that required this change:
INCOMPATIBLE: If you have more than 32 LPARs defined, versions
earlier than MXG 23.10 will fail with ARRAY errors.
See Change 23.322/23.321 text.
INCOMPATIBLE: IBM now splits RMF 70 records when you have lots of
LPARs and lots of spare engines; MXG 22.22+ detects
and reports split records were found in messages on
the SAS log, but created incomplete/wrong data in
TYPE70/TYPE70PR/ASUM70PR/ASUMCEC from split 70 SMF.
See Change 23.322/23.321 text.
New stuff YOU may have to do when you install MXG 23.10 or later:
INCOMPATIBLE: ITSV/ITRM sites that run BUILDPDB but do NOT create
the XRMFINT (RMFINTRV) dataset, MUST insert this
_STY70
text (an invocation of that old-style macro) in the
EXPDBOUT member of the site's "USERID.SOURCLIB" MXG
tailoring library. See Change 23.322/23/321 text.
Note: MOST ITRM SITES DON'T HAVE TO DO ANYTHING!
It is rare for an ITRM site's data dictionary
to specify processing of the RMF 70 records
and then NOT create the XRMFINT dataset.
This is ONLY REQUIRED if you have NOT
installed ITRM 27IS03 hotfix applied
INCOMPATIBLE: If you use the _VAR7072/_CDE7072 macros in your own
programs (or the programs you inherited!), then you
must also add the statement _STY70 after the data
step that reads the SMF data.
COMPATIBLE AND TRANSPARENT: MOST MXG USERS. Do nothing; drop-in
MXG 23.10+ and be corrected and protected.
NOTE: This is the most extensively tested change in MXG history:
un-split RMF/CMF 70 records from 34 sites with old and new
z/OS levels, were read with the old and new code and their
outputs compared with the TEST70SP program; PLEASE use the
TEST70SP program to read a day's RMF data and then examine
its reports for any un-documented discrepancies.
- SPLIT records can't be directly compared, since the old
code mishandled them. But the MXG data sets were run
thru ANALRMFR and those reports exactly matched IBM's
CPU reports for the split records. That code has been
in production for weeks with split records with no
reported errors. MXG now writes a note on the SAS log
that split records were processed, but it's just FYI.
- The rewrite corrected some errors and inconsistencies
that are noted in the change text that will cause false
positives in the PROC COMPARE output; primarily these
were intervals in which a policy change occurred or in
which an LPAR was not active for the full interval, or
in CPUs with CAI error bits set, and the new results
appears to be correct and consistent.
Major enhancements added in MXG 23.09
1. Critical corrections that require you to install MXG 23.09 for:
-JES3 with MXG 23.02 thru 23.08 must install MXG 23.09; there were
zero observations created in TYPE26J3. Change 23.282.
-DB2 V8.1 Package Data could be truncated. Change 23.280.
-z/VM VXSYTEPM deaccumulation now correct. Change 23.290
-ASUM70PR corrected for RMF Intervals with DURATM less than 1 min.
TYPE26J3 23.282 HIPER: 23.02-23.08, JES3 only. No obs in TYPE26J3.
TYPEDB2 23.280 DB2ACCTP Package Data required fix (final, trunc!).
TYPEVMXA 23.290 z/VM MONWRITE VXSYTEPM dataset finally correct.
ASUM70PR 23.289 RMF Intervals with DURATM less than one minute fix.
TYPE70PR 23.288 BMC SMF 70 from z9 have LPARCPUX=0, counts wrong.
VMXG70PR 23.276 PDB.ASUMCEC PCTL0OV,LP0MGTTM,LPCT0OV were zero.
2. New ML-37 of MXGTMNT captures SYSLOG messages for mounts, but can
also capture any SYSLOG message into its SMF records.
ASMTAPEE 23.300 ML-37 MXGTMNT monitor now captures SYSLOG messages
ASUMTAPE 23.300 Now merges SYSLOG, MXGTMNT, and IBM SMF 21s.
TYPETMNT 23.300 New TYPESYMT, TYPESYSL datasets from SYSLOG messages.
3. Easy creation of desired DB2 datasets with only wanted variables.
READDB2 23.287 Selective creation of DB2 datasets and data now easy.
4. Other enhancements, followed by less important fixes:
TYPE30 23.292 Support for APAR OA11675, EXCPTOTL max now 4 gig.
TYPENDM 23.291 Support for CDI/NDM subtypes HW and NM.
TYPEVM 23.285 Support for VM Account optional YYMMDD date format.
TYPESTC 23.279 Support for STK VTCS 6.0 and 6.1 SMF records (COMPAT)
TYPE80A 23.275 Support for CA TopSecret 103-105,109,255 SMF80DTPs.
TRNDxxxx 23.293 New &INTTRND can change default INTERVAL=WEEK in TRND
TYPE6 23.284 Print accounting for "Printway" tcp/ip SMF 6 records.
TYPE26J2 23.277 New UNSPUNJB, JOEPURGE status variables created.
TYPE30 23.296 TYPE30_6 RESIDTM/ACTIVETM wrapped after 51 days.
TYPEDB2 23.295 DB2ACCTG dataset didn't contain nine QBGA variables.
TYPETMVS 23.294 TYPETMVS CIJN and other CI variables INCOMPAT.
TESTIBM1 23.281 MXG 23.08 only. ERROR: File WORK.TYPE791.DATA does ..
VGETENG 23.298 MXG 23.08 only: FILE INSTREAM IN USE.
INSTREAM 23.298 MXG 23.08 only: INSTREAM DD was required, not now.
Major enhancements added in MXG 23.08
TYPE70 23.270 PCTIFBYn variables restored to TYPE70 dataset.
TYPEVMXA 23.269 z/VM MONWRITE dataset VXSYTEMP is now validated.
TYPE79 23.268 RMF 79 subtype 9 records are now validated/corrected.
RMFINTRV 23.265 23.05-23.07. IFA/IFE CPU times zero in RMFINTRV wkld.
TYPESYSI 23.258 Support for CA SYSVIEW IMS user SMF records.
TYPEMWSU 23.254 ADOCMWSU for HP MeasureWare on Sun was updated.
ASUMTAPE 23.253 Initial rewrite of ASUMTAPE for TMNT/21 records only.
ASUMUOW 23.251 More robust definition of "TRANNAME" in PDB.ASUMUOW.
READDB2 23.249 OBID and DBID are decoded in DB2 102 Trace datasets.
ASMTAPEE 23.247 ML-36 is now available of MXGTMNT.
VGETDDS 23.244 Using VGETDDS to get all DDNAMES can fail.
ASMRMFV 23.243 Enhancement to RMF III VSAM Support
TYPE82 23.242 Support for SMF type 82 subtypes 20 and 21 added.
ASUMUOW 23.240 IRESPTM and ELAPSTM in PDB.ASUMUOW revised.
VMXGDUR 23.239 Support for DURATM keywords TENMIN and FIVEMIN.
ASUM70PR 23.237 Variables NRIFACPU,NRIFLCPU added to PDB.ASUM70PR/CEC
TYPEENDV 23.236 Support for Endeavor Release 7; no changes.
TYPEDB2 23.235 DB2TCBTM in DB2ACCT obs with DB2PARTY='R' was wrong.
GRAFWLM 23.234 CPU Utilization graph by goal importance, Enrico's.
TYPEWWW 23.233 Enhancement/corrections to Web Log support.
TYPE1023 23.231 Support for DB2 IFCIC 225.
TYPETMS5 23.229 Support for DEVTYPE='3592' devices in CA-1.
TYPEEREP 23.228 INPUT STATEMENT EXCEEDED for IBM ATL record.
TYPENDM 23.227 NDMCPUTM in NDMCT is now deaccumulated and correct.
TYPEIPAC 23.223 Support for Mobiud/IPAC Rel 6.3 INCOMPATIBLE.
TYPE6156 23.219 ICF Catalog 05 record GATGEN and GATWRAP corrected.
TYPE88 23.213 All SMF88xxx datetime variables are now local zone.
Major enhancements added in MXG 23.07
TYPEDB2 23.181 DB2 V8.1 DB2ACCTP still wrong for multi-package.
ASMTAPEE 23.177 ML-34 MXGTMNT now GA, has ASMHSCEX for HSC mounts!!!
TYPE7072 23.186 Support for z9 CPU, new CPUTYPE='2094'x INCOMPAT.
TYPEMGCR 23.200 Support for MegaCryption's user SMF record
TYPETPFC 23.199 Support for TPF Continuous Data Collection TPFCDC.
TYPESARR 23.196 Support for CA SAR/VIEW R11, INCOMPATIBLY CHANGED.
TYPETNG 23.193 Support for TNG AIX CA PROCESS GROUP (PID) object.
TYPE7072 23.187 Support for APAR OA10346 adds LPAR User Partion ID.
MXGABND 23.184 New %LET MXGABND=nnnn forces ABEND for CICS EXCL ERR.
TYPE89 23.183 Support for APAR OA11036 added MACHTIME to SMF 89.
ASUMTALO 23.201 Condition Code (Return Code) 4 in ASUMTALO eliminated
BUILD005 23.197 Hardcoded "SPIN" DD replaced by &SPINOUT.
IMACICDA 23.190 Comments only. IMACICDA is not used with IMACEXCL.
Major enhancements added in MXG 23.06
TYPE6 23.159 PSF SMF 6 with SMF6LN6=24 another INPUT EXCEEDED.
TYPE22 23.175 Support for subtype 11 I/O Configuration Change
TYPESAMS 23.172 SAMS POOLS record INCOMPATIBLY CHANGED.
TYPE99 23.169 Support for SMF 99 Subtype 2 additional segments.
TYPEMVCI 23.166 Support for additional CMRFILE fields in CMRDETL.
TYPE120 23.164 Support for PQ96144, SM120JHF/JHT corrected.
TYPESYNC 23.163 New "SMS" UCB Address caused INVALID ARGUMENT error.
TYPE102 23.160 Many new variables added to T102S106 dataset.
Major enhancements added in MXG 23.05
TYPEDB2 23.140 REQUIRED FOR DB2 V8.1, more IBM INCOMPATIBLE CHANGES.
TYPEVMXA 23.128 z/VM 5.1 record 1.19 IBM misdocumented, had ERRORs.
TYPE119 23.146 Support for new FTP Server Security Section in st 70.
TYPEPRPR 23.142 Support for Oce's Prisma Print log file.
TYPECYFU 23.139 Support for CyberFusion user SMF record validated.
TYPESYSV 23.137 Support for CA SYSVIEW CICS data in XPFCMCR,XPFCSDCR.
TYPECMF 23.136 Support for 2180 RAID RANK data in CMF user record.
TYPE80A 23.135 Support for Top Secret Versions 5.2 and 5.3.
TYPE80A 23.134 Unexpected RACF TOK80LN2=0 record was deleted.
TYPESTC 23.125 Support for HSC V6 changes to STCLMU subtype 4 SMF.
TYPEIWAY 23.133 Support for Iway Software's IWAY (aka EDA/SQL) SMF.
TYPE102 23.131 Support for DB2 IFCID=313 creates T102S313 dataset.
ASUMMIPS 23.126 RPRTCLAS added to identify Service/Reporting Classes.
RMFINTRV 23.123 CPUIFATM/IFE and BATIFA,CICSIFA,etc now in RMFINTRV.
ASUM70PR 23.121 BY VARIABLES NOT SORTED corrected, PROC SORT added.
TYPE6 23.120 Support for ESS GEPARMKY=004Dx variable ESSMAIL2.
TYPETNG 23.113 Zero observations with a Solaris cube.
FORMATS 23.144 "Expanded Length" format values revised logic for S2.
TYPEDB2 23.111 Support for DB2 V8.1 Package Data INCOMPATIBLE.
BUILDPDB 23.124 Duplicate SMF 30 interval records duped in SMFINTRV.
Major enhancements added in MXG 23.04
TYPEIMS 23.099 Support for IMS Version 9.1 was already in MXG 22.22
TYPEDB2 23.098 Support for DB2 V8.1 restructured Package Data.
TYPE30 23.101 Support for APAR OA10901, SMF30ZNF zAAP noralize fact
TYPE74 23.093 Support for Type 74 subtype 8 corrected.
TYPETMO2 23.100 TMON for CICS/TS V2.3 for CICS/TS 3.1. No Changes.
VGETJESN 23.096 Blank TYPETASK in TYPE30_6 data, STCs, corrected.
TYPE6 23.091 Printway File Transfer, z/OS 1.6 from VPS corrected.
ASUMTALO 23.104 Enhancement to summarize by "groups".
ASUMTMNT 23.104 Enhancement to summarize by "groups".
Major enhancements added in MXG 23.03
ASUM70PR 23.071 PDB.ASUMCEC contains CEC total IFA CPU time
RMFINTRV 23.071 IFA CPU time added to PDB.RMFINTRV
TYPE7072 23.070 Correction for IBM inability to get STARTIME right.
ASUM70PR 23.069 Short RMF interval impacts PDB.ASUMCEC.
TYPERMFV 23.080 RMF III data for IFAs added to ZRBASI, ZRBENC
ANALPATH 23.078 Path Activity Report includes CMR and OTH pend.
UTILEXCL 23.075 CMODNAME=RMI,CMODHEAD=DB2CLOCK didn't generate skip.
ANALFIOE 23.074 FICON Open Exchange analysis includes CMR pend time.
TYPE73 23.072 Support for APAR OA09921 IBM TotalStorage DS6000.
BUILDPD3 23.282 BUILDPD3 now sets Condition/Return Code of zero.
TYPE80A 23.066 Support for RACF Events 27, 28, 29 for unix.
TYPE78SP 23.064 TYPE78SP only had below-16MB subpool variables.
TYPE90A 23.081 WLM Service Policy new name tracked in TYPE9024.
Major enhancements added in MXG 23.02
TYPEVMXA 23.051 Support for z/VM Linux Application Server data.
TYPEVMXA 23.061 Support for z/VM TCP/IP Application Server data.
Major enhancements added in MXG 23.01
Typos 23.012 MXG 22.22 JCLTEST/MXGSASVn had error-causing typos.
These typos only affected your testing of 22.22.
VMXGUOW 23.017 Default IMACUOW in 22.22 caused NO BY error.
If you use ASUMUOW, you MUST update your IMACUOW.
If you don't use ASUMUOW, remove it from JCLPDBn.
WEEKxxx 23.015 Sort Order for SMFINTRV may have to be changed.
MONTHxxx 23.015 Sort Order for SMFINTRV may have to be changed.
TYPETMS5 23.045 Support for TMS Release 11 - no changes.
TYPEMPLX 23.027 Support for IMPLEX Versions 3.1 and 3.3
TYPESTC 23.022 Support for VSM subtype 20, problems with ST 4.
TYPECYFU 23.020 Support for CyberFusion user SMF record.
TYPE80A 23.006 Support for many new RACF events.
TYPESAMS 23.004 Support for SAMS Vantage "LSPACE" record subtype.
TYPECSF2 23.024 CONTROL-D SF2 records INCOMPATIBLY changed.
UTILCONT 23.025 Failed if DISP=NEW dataset was contented.
TYPE74 23.029 AVGxxxMS variables now FORMAT 6.3.
TYPEVMXA 23.050 z/VM VXBYUSR CPU and DELTATM corrected.
TYPEDB2 23.011 DB2 QWHT/QWHU/QWHD/QWHA could be blank/missing.
ASUM70PR 23.021 LP0xxxxx variables were not populated.
TYPEQACS 23.007 CPU variables in QAPMJOBL were incorrect.
TYPENDM 23.001 INPUT STATEMENT EXCEEDED for NDM subtype 'SY'.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements added in MXG 22.08" in CHANGES, for the major
items, then search Newsletters for V9 for all of the minor items.
MXG executes best under the most recent SAS Version, with all
Critical HotFixes installed by your SAS Installer:
For SAS V9.1.3 on z/OS:
There are no reported errors, and MXG's CONFIGV9 now specifies
V9SEQ instead of V6SEQ. V6SEQ does not support long length
character variables. SAS V9.1.3 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with V7SEQ,V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are still SAS V9.1 or V9.1.2,
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 is REQUIRED to be safe.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it is now the default in CONFIGV9.
V6SEQ, if used under V9.1.2, requires SN-013514.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
MXG New-Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on Windows XP with SAS V9.1.3. But previous QA tests
have been run with all SAS releases on z/OS, SAS V8.2 and V9.1 on
Linux RH8 on Intel, with V9.1 on Solaris v2.8 on Model V880, and
V9.1 on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V8.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
Availability dates for the IBM products and MXG version required for
the processing of that product's data records:
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 21.05
z/OS IRD TYPE70PR Mar 11, 2004 22.01
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 22.12
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 23.05
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *23.09
More than 32 LPARs Jan 30, 2006 23.11
SPLIT RMF 70 records Jan 30, 2006 23.11
Duplicate SYSTEMs in a SYSPLEX Jan 30, 2006 23.11
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
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Dec ??, 2004? 22.08
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
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 20.04
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 CICS/ESA 2.1 - 20.04
The Monitor for CICS/ESA 2.2 - 20.335, 21.134 21.04
The Monitor for CICS/ESA 2.3 including cics/ts 3.1 22.08
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
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for MVS/ESA 3.1 - 21.02
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 CICS V500 User SMF 18.01
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 22.08
Memorex/Telex
LMS 3.1 12.12A
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
II. Incompatibilities and Installation of MXG 23.09.
1. Incompatibilities introduced in MXG 23.09 (since MXG 22.22):
a- Changes in MXG architecture made between 23.11 and 22.22 that might
introduce incompatibilities.
ITRM Sites MUST add _STY70 invocation in their EXPDBOUT member.
See Change 23.321.
If you use MXG _VAR7072 and _CDE7072 in your own program to read
RMF 70s, you MUST now invoke _STY70 after your data step due
to MXG support for split SMF 70 records. Change 23.321.
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.
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. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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.
_PAGE_ 8
Alphabetical list of important changes in MXG 23.11 after MXG 22.22:
Dataset/
Member Change Description
Typos 23.012 MXG 22.22 JCLTEST/MXGSASVn had error-causing typos.
ANALFIOE 23.074 FICON Open Exchange analysis includes CMR pend time.
ANALPATH 23.078 Path Activity Report includes CMR and OTH pend.
ASMHSCEX 23.177 ML-34 MXGTMNT GA, has ASMHSCEX for HSC mounts!!
ASMRMFV 23.243 Enhancement to RMF III VSAM Support
ASMTAPEE 23.177 ML-34 MXGTMNT GA, has ASMHSCEX for HSC mounts!!
ASMTAPEE 23.247 ML-36 is now available of MXGTMNT.
ASMTAPEE 23.300 ML-37 MXGTMNT monitor now captures SYSLOG messages
ASUM70PR 23.021 LP0xxxxx variables were not populated.
ASUM70PR 23.069 Short RMF interval impacts PDB.ASUMCEC.
ASUM70PR 23.071 PDB.ASUMCEC contains CEC total IFA CPU time
ASUM70PR 23.121 BY VARIABLES NOT SORTED corrected, PROC SORT added.
ASUM70PR 23.237 Variables NRIFACPU,NRIFLCPU added to PDB.ASUM70PR/CEC
ASUM70PR 23.289 RMF Intervals with DURATM less than one minute fix.
ASUM70PR 23.322 Support for 60 LPARs - INCOMPATIBLE
ASUMCACH 23.073 MODEL, taken from DEVMODEL, added to BY list.
ASUMDB2 23.319 Summary of DB2ACCT detail into interval buckets.
ASUMMIPS 23.126 RPRTCLAS added to identify Service/Reporting Classes.
ASUMTALO 23.104 Enhancement to summarize by "groups".
ASUMTALO 23.201 Condition Code (Return Code) 4 in ASUMTALO eliminated
ASUMTAPE 23.253 Initial rewrite of ASUMTAPE for TMNT/21 records only.
ASUMTAPE 23.300 Now merges SYSLOG, MXGTMNT, and IBM SMF 21s.
ASUMTMNT 23.104 Enhancement to summarize by "groups".
ASUMUOW 23.240 IRESPTM and ELAPSTM in PDB.ASUMUOW revised.
ASUMUOW 23.251 More robust definition of "TRANNAME" in PDB.ASUMUOW.
BUILD005 23.197 Hardcoded "SPIN" DD replaced by &SPINOUT.
BUILDPD3 23.282 BUILDPD3 now sets Condition/Return Code of zero.
BUILDPDB 23.124 Duplicate SMF 30 interval records duped in SMFINTRV.
CONFIGV9 23.061 SEQENGINE=V9SEQ now default in CONFIGV9 for 9.1.3.
FORMATS 23.144 "Expanded Length" format values revised logic for S2.
GRAFWLM 23.234 CPU Utilization graph by goal importance, Enrico's.
IMAC6ESS 23.008 Invalid ESS data caused INPUT STATEMENT EXCEEDED.
IMACICDA 23.190 Comments only. IMACICDA is not used with IMACEXCL.
INSTREAM 23.298 MXG 23.08 only: INSTREAM DD was required, not now.
MACKEEP 23.346 DB2 Tailoring Example to add DB2 102 to PDB.
MONTHxxx 23.351 &MXGSYSN macro variable for compatibility.
MXGABND 23.184 New %LET MXGABND=nnnn forces ABEND for CICS errors.
READDB2 23.249 OBID and DBID are decoded in DB2 102 Trace datasets.
READDB2 23.287 Selective creation of DB2 datasets and data now easy.
READDB2 23.345 New WANTONLY= enhancement for %READDB2 utility.
RMFINTRV 23.071 IFA CPU time added to PDB.RMFINTRV
RMFINTRV 23.123 CPUIFATM/IFE and BATIFA,CICSIFA,etc now in RMFINTRV.
RMFINTRV 23.265 23.05-23.07. IFA/IFE CPU times zero in RMFINTRV wkld.
TESTIBM1 23.281 MXG 23.08 only. ERROR: File WORK.TYPE791.DATA does ..
TRNDxxxx 23.293 New &INTTRND can change default INTERVAL=WEEK in TRND
TYPE102 23.056 Dataset T102S199 was incorrect; only first seg output
TYPE102 23.131 Support for DB2 IFCID=313 creates T102S313 dataset.
TYPE102 23.160 Many new variables added to T102S106 dataset.
TYPE1023 23.231 Support for DB2 IFCIC 225.
TYPE110 23.077 CICS STAT RECORD STID=106 message.
TYPE110 23.342 Support for CANDLE UMBRELLA optional CICSTRAN data.
TYPE115 23.347 Support for MQ for z/OS Version 6.0 (COMPAT)
TYPE116 23.049 MQM variable QWHCCV QWHSSSID renamed.
TYPE119 23.146 Support for new FTP Server Security Section in st 70.
TYPE120 23.164 Support for PQ96144, SM120JHF/JHT corrected.
TYPE22 23.175 Support for subtype 11 I/O Configuration Change
TYPE26J2 23.277 New UNSPUNJB, JOEPURGE status variables created.
TYPE26J3 23.282 HIPER: 23.02-23.08, JES3 only. No obs in TYPE26J3.
TYPE30 23.101 Support for APAR OA10901, SMF30ZNF zAAP noralize fact
TYPE30 23.292 Support for APAR OA11675, EXCPTOTL max now 4 gig.
TYPE30 23.296 TYPE30_6 RESIDTM/ACTIVETM wrapped after 51 days.
TYPE30 23.329 Support for SMF30CEPI field, new CPUCIPTM variable.
TYPE30_V 23.334 IMACINTV default now OUTPUTs TYPE30_V/PDB.SMFINTRV.
TYPE6 23.091 Printway File Transfer, z/OS 1.6 from VPS corrected.
TYPE6 23.120 Support for ESS GEPARMKY=004Dx variable ESSMAIL2.
TYPE6 23.159 PSF SMF 6 with SMF6LN6=24 another INPUT EXCEEDED.
TYPE6 23.284 Print accounting for "Printway" tcp/ip SMF 6 records.
TYPE6156 23.219 ICF Catalog 05 record GATGEN and GATWRAP corrected.
TYPE70 23.270 PCTIFBYn variables restored to TYPE70 dataset.
TYPE70 23.330 Corrections to Split 70/Over 60 LPAR Change 23.321.
TYPE70 23.348 Final "70's Record Rewrite", OS/390 support!
TYPE7072 23.013 LPARCPUX kept in TYPE70PR for count of reserved CPs
TYPE7072 23.070 Correction for IBM inability to have STARTIME right.
TYPE7072 23.083 Variable NRCPUD, CPU segments this MVS, added.
TYPE7072 23.186 Support for z9 CPU, new CPUTYPE='2094'x, INCOMPAT.
TYPE7072 23.187 Support for APAR OA10346 adds LPAR User Partion ID.
TYPE7072 23.306 PARTNCPU final correction for z9 microcode error.
TYPE7072 23.321 Support for Split RMF 70 Records: INCOMPATIBLE
TYPE7072 23.322 Support for 60 LPARs - INCOMPATIBLE
TYPE7072 23.335 Variables SMF70OIL and SMF70SYN now KEPT in TYPE70.
TYPE70PR 23.288 BMC SMF 70 from z9 have LPARCPUX=0, counts wrong.
TYPE73 23.072 Support for APAR OA09921 IBM TotalStorage DS6000.
TYPE74 23.029 AVGxxxMS variables now FORMAT 6.3.
TYPE74 23.093 Support for Type 74 subtype 8 corrected.
TYPE78SP 23.064 TYPE78SP only had below-16MB subpool variables.
TYPE79 23.268 RMF 79 subtype 9 records are now validated/corrected.
TYPE80A 23.006 Support for many new RACF events.
TYPE80A 23.066 Support for RACF Events 27, 28, 29 for unix.
TYPE80A 23.134 Unexpected RACF TOK80LN2=0 record was deleted.
TYPE80A 23.135 Support for Top Secret Versions 5.2 and 5.3.
TYPE80A 23.275 Support for CA TopSecret 103-105,109,255 SMF80DTPs.
TYPE82 23.242 Support for SMF type 82 subtypes 20 and 21 added.
TYPE88 23.213 All SMF88xxx datetime variables are now local zone.
TYPE89 23.183 Support for APAR OA11036 added MACHTIME to SMF 89.
TYPE90A 23.081 WLM Service Policy new name tracked in TYPE9024.
TYPE99 23.169 Support for SMF 99 Subtype 2 additional segments.
TYPEBE91 23.311 Support for Beta 91 Version 3.1.1.0, INCOMPATIBLE.
TYPECMF 23.136 Support for 2180 RAID RANK data in CMF user record.
TYPECSF2 23.024 CONTROL-D SF2 records INCOMPATIBLY changed.
TYPECYFU 23.020 Support for CyberFusion user SMF record.
TYPECYFU 23.139 Support for CyberFusion user SMF record validated.
TYPEDB2 23.011 DB2 QWHT/QWHU/QWHD/QWHA could be blank/missing.
TYPEDB2 23.082 QWHSLOCN CONTAINS UNICODE TEXT message
TYPEDB2 23.098 Support for DB2 V8.1 restructured Package Data.
TYPEDB2 23.111 Support for DB2 V8.1 Package Data INCOMPATIBLE.
TYPEDB2 23.140 REQUIRED FOR DB2 V8.1 More IBM INCOMPATIBLE CHANGES.
TYPEDB2 23.181 DB2ACCTP data was still wrong for DB2 V8.1, fixed.
TYPEDB2 23.235 DB2TCBTM in DB2ACCT obs with DB2PARTY='R' was wrong.
TYPEDB2 23.280 DB2ACCTP Package Data required fix (final, trunc!).
TYPEDB2 23.295 DB2ACCTG dataset didn't contain nine QBGA variables.
TYPEENDV 23.236 Support for Endeavor Release 7; no changes.
TYPEEREP 23.228 INPUT STATEMENT EXCEEDED for IBM ATL record.
TYPEHSM 23.179 All byte-containing HSM variables FORMATed MGBYTES.
TYPEIMS 23.099 Support for IMS Version 9.1 was already in MXG 22.22
TYPEIPAC 23.223 Support for Mobiud/IPAC Rel 6.3 INCOMPATIBLE.
TYPEIWAY 23.133 Support for Iway Software's IWAY (aka EDA/SQL) SMF.
TYPEMGCR 23.200 Support for MegaCryption's user SMF record
TYPEMPLX 23.027 Support for IMPLEX Versions 3.1 and 3.3
TYPEMPLX 23.143 IMPLEX subtype 4 revised, validated.
TYPEMVCI 23.166 Support for additional CMRFILE fields in CMRDETL.
TYPEMWSU 23.254 ADOCMWSU for HP MeasureWare on Sun was updated.
TYPENDM 23.001 INPUT STATEMENT EXCEEDED for NDM subtype 'SY'.
TYPENDM 23.227 NDMCPUTM in NDMCT is now deaccumulated and correct.
TYPENDM 23.291 Support for CDI/NDM subtypes HW and NM.
TYPENDM 23.331 Support for NDM/Connect Direct subtype TF, TL, TW.
TYPEPRPR 23.142 Support for Oce's Prisma Print log file.
TYPEQACS 23.007 CPU variables in QAPMJOBL were incorrect.
TYPERMFV 23.080 RMF III data for IFAs added to ZRBASI, ZRBENC
TYPESAMS 23.004 Support for SAMS Vantage "LSPACE" record subtype.
TYPESAMS 23.172 SAMS POOLS record INCOMPATIBLY CHANGED.
TYPESARR 23.196 Support for CA SAR/VIEW R11, INCOMPATIBLY CHANGED.
TYPESTC 23.022 Support for VSM subtype 20, problems with ST 4.
TYPESTC 23.125 Support for HSC V6 changes to STCLMU subtype 4 SMF.
TYPESTC 23.279 Support for STK VTCS 6.0 and 6.1 SMF records (COMPAT)
TYPESYNC 23.163 New "SMS" UCB Address caused INVALID ARGUMENT error.
TYPESYSI 23.258 Support for CA SYSVIEW IMS user SMF records.
TYPESYSV 23.137 Support for CA SYSVIEW CICS data in XPFCMCR,XPFCSDCR.
TYPETHST 23.076 BMC THRDHIST file contains invalid package records.
TYPETMNT 23.300 New TYPESYMT, TYPESYSL datasets from SYSLOG messages.
TYPETMO2 23.100 TMON for CICS/TS V2.3 for CICS/TS 3.1. No Changes.
TYPETMS5 23.045 Support for TMS Release 11 - no changes.
TYPETMS5 23.229 Support for DEVTYPE='3592' devices in CA-1.
TYPETMVS 23.294 TYPETMVS CIJN and other CI variables INCOMPAT.
TYPETNG 23.113 Zero observations with a Solaris cube.
TYPETNG 23.193 Support for TNG AIX CA PROCESS GROUP (PID) object.
TYPETPFC 23.199 Support for TPF Continuous Data Collection TPFCDC.
TYPETPFC 23.324 TPF Continuous Data rate variables now calculated.
TYPEVM 23.285 Support for VM Account optional YYMMDD date format.
TYPEVMXA 23.050 z/VM VXBYUSR CPU and DELTATM corrected.
TYPEVMXA 23.060 Support for z/VM 5.1 enhanced: all new data supported
TYPEVMXA 23.128 z/VM 5.1 record 1.19 misdocumented, caused ERRORs.
TYPEVMXA 23.269 z/VM MONWRITE dataset VXSYTEMP is now validated.
TYPEVMXA 23.290 z/VM MONWRITE VXSYTEPM dataset finally correct.
TYPEVMXA 23.332 Variables HFLLIST,HFPGACT were accumulated.
TYPEWWW 23.026 Zero length URIQVALU caused INVALID ARGUMENT.
TYPEWWW 23.233 Enhancement/corrections to Web Log support.
TYPExxxx 23.052 New EOdddddd, _Odddddd MXG architecture enhancements.
UTILBLDP 23.036 CC=4 with BUILDPDB=NO eliminated, now CC=0.
UTILBLDP 23.057 Enhanced; USERADD supports SMF record number.
UTILBLDP 23.087 EXPDBOUT= a %INCLUDE failed when output executed.
UTILCONT 23.025 Failed if DISP=NEW dataset was contented.
UTILEXCL 23.075 CMODNAME=RMI,CMODHEAD=DB2CLOCK didn't generate skip.
VGETDDS 23.244 Using VGETDDS to get all DDNAMES can fail.
VGETENG 23.298 MXG 23.08 only: FILE INSTREAM IN USE.
VGETJESN 23.096 Blank TYPETASK in TYPE30_6 data, STCs, corrected.
VMXG70PR 23.276 PDB.ASUMCEC PCTL0OV,LP0MGTTM,LPCT0OV were zero.
VMXGDUR 23.239 Support for DURATM keywords TENMIN and FIVEMIN.
VMXGFOR 23.127 Semi-colon at end of macro invocation in AUTOCALL.
VMXGUOW 23.017 Default IMACUOW in 22.22 caused NO BY error.
%VMXGVERS 23.005 New %VMXGVERS member embedded to detect old versions.
WEEKBLD 23.246 Support for adding un-sorted datasets to WEEKLY PDB.
WEEKxxx 23.015 Sort Order for SMFINTRV must be changed
WEEKxxx 23.351 &MXGSYSN macro variable for compatibility.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 23.
====== Changes thru 23.358 were in MXG 23.23 dated Feb 20, 2006=========
Change 23.358 Support for WebSphere Application Server z/OS Version 6.0
VMAC120 compatibly added 8-byte fields to replace 4-byte fields
Feb 18, 2006 in the Server Activity CSS and Server Interval SIL data.
MXG stores the new data into the existing variable names,
which were already formatted MGBYTES and thus kept long.
Thanks to Victoria Lepak, Aetna, USA.
Change 23.357 Macro variable "SYSNAME" is renamed "MXGSYSN" as SAS has
DOC recommended (SN-012275) that "SYS" not be used as a macro
Feb 18, 2006 variable name's prefix. Only sites with duplicate SYSTEM
names in the same SYSPLEX will need to change the default
value (blank) to "SYSNAME" as noted in Change 23.351.
Those sites could simply put this statement
%LET MXGSYSN=SYSNAME;
in their IMACKEEP member so their WEEKLY/MONTHLY will use
SYSNAME in its BY processing.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.356 Cosmetic, unless you are running a non-PR/SM system. The
VMAC7072 recalculation of CPUUPTM and CPUACTTM used the PR/SM vars
Feb 17, 2006 and overwrote the just-finished non-PR/SM calculation.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 23.355 Enhancement to DB2PM-like reports, adds CONNTYPE= option
ANALDB2R for selection criteria for Accounting Detail (PMACC02).
Feb 17, 2006 For example, CONNTYPE=4, selects only CICS connections.
Thanks to John Paul, HighMark, USA.
Change 23.354 MXG 23.23 PreRel; variable PARTNCPU, the count of engines
VMAC7072 in the box/partition, could be too large, if you have ICF
Feb 17, 2006 or IFA engines, in some cases. The test to use SMF70BNP
Feb 19, 2006 instead of NRCPSCPU (temp count PHYSICAL CPs) was added
to protect sites that won't let an LPAR see its physical
segments, was replaced with IF NRCPSCPU GT 0 instead of
comparing IF PARTNCPU GT NRCPSCPU.
-Feb 19: NRCPSCPU was removed from a DROP statement where
it didn't belong, but it is NOT a kept variable.
-Apr 7: How do you cause SMF 70s to not have a PHYSICAL
LPAR segment, and not report on other LPARs?
On the HMC, there is a Global Performance Data
Control switch, which controls the amount of data
returned by the Diagnose instruction RMF uses to
obtain CPU utilization information; if not on,
the RMF 70s will contain only information on this
SYSTEM, and there will be no PHYSICAL segments.
Thanks to Stan Adriaensen, Axa-Tech Belgium GIE, BELGIUM.
Thanks to Scott Barry, SBBWorks, USA.
Change 23.353 Support for OCE Prisma Ser5ver Version 3.04 added new
FORMATS data, compatibly, to their user SMF records, and new
VMACPRPR values for the existing MGPRPRA format, in this perfectly
Feb 17, 2006 written user contribution update.
Thanks to Siegfried Trantes, IDG, GERMANY.
Thanks to Willi Weinberger, IDG, GERMANY.
Change 23.352 Short ML-36 SYSLOG record caused INPUT STATEMENT EXCEEDED
VMACTMNT error for the subtype 8 record. ASMTAPEE at ML-38 fixes
Feb 16, 2006 the short record, and VMACTMNT now tests SYSLLEN before
it inputs the MSGID fields in the captured SYSLOG event.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
====== Changes thru 23.351 were in MXG 23.23 dated Feb 15, 2006=========
Change 23.351 Change 23.336 had to change the RMF dataset sort order to
MONTHASC BY SYSPLEX SYSTEM SYSNAME STARTIME ....
MONTHBL3 by inserting SYSNAME, but if SYSNAME does not exist in an
MONTHBLD old PDB, your weekly/monthly/etc combining job fails with
MONTHBLS ERROR: BY VARIABLE SYSNAME NOT FOUND ON INPUT DATA ...
MONTHDSK While MXG must use SYSNAME in its logic, only sites with
VMXGINIT duplicate SYSTEM names actually need SYSNAME in their
WEEK70PR BY list for their weekly/monthly jobs, so this change:
WEEKBL3 - defines macro variable &MXGSYSN, with blank value
WEEKBL3D - uses &MXGSYSN in BY statements for post processing of
WEEKBL3T daily/weekly/monthly datasets.
WEEKBLD With the blank default, then your weekly/monthly jobs
WEEKBLDD will not fail when old/new RMF datasets with/without the
WEEKBLDT SYSNAME variable are combined.
Feb 15, 2006 If you have duplicate SYSTEM names, then when all of
Feb 18, 2006 the input datasets to the week/month merge contain
variable SYSNAME, you would then use this statement
%LET MXGSYSN=SYSNAME;
%INCLUDE SOURCLIB(Weekbld, monthbld, ... etc);
Feb 18: The PreRelease use macro variable "SYSNAME" but
Change 23.357 changed it to MXGSYSN.
Change 23.350 Labels for variables DSxTCBAF are now "ATTACH*FAILURES"
VMAC110 instead of "ATTACHES".
Feb 15, 2006
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.349 The exit _EPDBOUT is again invoked when BUILDPDB=NO; it
UTILBLDP had been in MXG 22.22, but was lost along the way. Note,
Feb 15, 2006 however, that EXPDBOUT=_EPDBOUT and BUILDPDB=YES can not
Feb 16, 2006 be used together, and a new warning message will be print
if they are both specified.
-Feb 16, 2006: Revised so EXPDBOUT= argument is now always
created either when BUILDPDB=YES is used or if EXPDBOUT
argument is non-blank.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 23.348 Final (?) "70's Record Rewrites" change, for OS/390 R2.1!
VMAC7072 The last error in validation was caused by really old RMF
VMXG70PR records from OS/390 R2.1 that didn't have SMF70CIN field,
VMXGRMFI which caused PARTNCPU to be zero. The revision uses the
Feb 14, 2006 value in SMF70BNP when SMF70CIN is not populated.
-PROC DELETEs were added for a few WORK datasets that were
not deleted after their last use, but now are.
Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.
Change 23.347 Support for Websphere MQ for z/OS Version 6.0 (COMPAT).
VMAC115 -Added compatibly, i.e., at end of SMF 115 records:
VMAC116 Data Set MQMMSGDM new sets of duration variables:
Feb 14, 2006 LMSDEL ='DB2 BLOB*DELETE*REQUESTS'
LMSDSCUW='DB2 BLOB DELETE*SQL DELETE*CUM-TM'
LMSDSMXW='DB2 BLOB DELETE*SQL DELETE*MAX-TM'
LMSDTCUW='DB2 BLOB DELETE*THREAD DELETE*CUM-TM'
LMSDTMXW='DB2 BLOB DELETE*THREAD DELETE*MAX-TM'
LMSINS ='DB2 BLOB*INSERT*REQUESTS'
LMSISCUW='DB2 BLOB WRITE*SQL DELETE*CUM-TM'
LMSISMXW='DB2 BLOB WRITE*SQL DELETE*MAX-TM'
LMSITCUW='DB2 BLOB WRITE*THREAD DELETE*CUM-TM'
LMSITMXW='DB2 BLOB WRITE*THREAD DELETE*MAX-TM'
LMSLIS ='DB2 BLOB*LIST*REQUESTS'
LMSLSCUW='DB2 BLOB LIST*SQL DELETE*CUM-TM'
LMSLSMXW='DB2 BLOB LIST*SQL DELETE*MAX-TM'
LMSLTCUW='DB2 BLOB LIST*THREAD DELETE*CUM-TM'
LMSLTMXW='DB2 BLOB LIST*THREAD DELETE*MAX-TM'
LMSSEL ='DB2 BLOB*READ*REQUESTS'
LMSSSCUW='DB2 BLOB READ*SQL DELETE*CUM-TM'
LMSSSMXW='DB2 BLOB READ*SQL DELETE*MAX-TM'
LMSSTCUW='DB2 BLOB READ*THREAD DELETE*CUM-TM'
LMSSTMXW='DB2 BLOB READ*THREAD DELETE*MAX-TM'
LMSUPD ='DB2 BLOB*UPDATE*REQUESTS'
LMSUSCUW='DB2 BLOB UPDATE*SQL DELETE*CUM-TM'
LMSUSMXW='DB2 BLOB UPDATE*SQL DELETE*MAX-TM'
LMSUTCUW='DB2 BLOB UPDATE*THREAD DELETE*CUM-TM'
LMSUTMXW='DB2 BLOB UPDATE*THREAD DELETE*MAX-TM'
A BLOB object is used to access binary large objects
(BLOBs), such as sound byte (wav) or image (gif) file,
using the DB2Blob interface with Java 2. With the BLOB
class, the LOB threshold property specifies the maximum
large object (LOB) size (in kilobytes) retrieved as
part of a result set. LOBs over that threshold are
retrieved in pieces, requiring communications overhead
with the server, so they can reduce the frequency of
communications, but they also download more LOB data,
that unwanted data that was never used. Smaller LOBs
may increase the frequency of communications with
server, but may move much wasted data.
-Added compatibly, i.e., at end of SMF 116 records:
Data Set MQMACCTQ:
WTASVER ='WTAS*VERSION*NUMBER'
WTASDBPT='WTAS*DB2 BYTES*WRITTEN'
WTASDBGT='WTAS*DB2 BYTES*READ'
Data Set MQMQUEUE:
WQFLAGS '=FLAGS'
WQGETDVA'=SUCCESSFUL DESTRUCTIVE GETS'
WQGETJCE'=ELAPSED WAIT*FOR FORCE*JOURNAL GETS'
WQGETJCN'=NUMBER OF FORCE JOURNAL GETS'
WQMAXQDP'=MAXIMUM ENCOUNTERED QUEUE DEPTH'
WQPUT1JE'=ELAPSED WAIT*FOR FORCE MQPUT1*JOURNAL WRITES'
WQPUT1JN'=FORCE MQPUT1 JOURNAL WRITES
WQPUT1PW'=MQPUT1 CALLS WHERE MSG PASSED'
WQPUTJCE'=ELAPSED WAIT*FOR FORCE*JOURNAL WRITES'
WQPUTJCN'=FORCE JOURNAL WRITES'
WQPUTPWG'=NUMBER OF MQPUT CALLS WHERE MSG*PASSED'
WQSETJCE'=ELAPSED WAIT*FOR SET'
WQSETJCN'=NUMBER OF SET'
Thanks to Victoria Lepak, Aetna, USA.
Change 23.346 Documentation example; to add DB2 102 records to BUILDPDB
IMACKEEP and to create the T102S022 T102S044 T102S063 datasets and
Feb 13, 2006 copy them into the //PDB library you would use:
%LET MACKEEP=%QUOTE(
MACRO _CDEUSER
_HDR102 _C102022 _C102044 _C102063 _C102105 _END102
%
MACRO _VARUSER
_V102022 _V102044 _V102063 _V102105
%
);
%LET EPDBOUT=%QUOTE(
RUN;
PROC COPY INDD=WORK OUTDD=PDB;SELECT T102: ;
RUN;
);
%INCLUDE SOURCLIB(VMAC102);
%INCLUDE SOURCLIB(BUILDPDB);
We're not sure why both RUN; statements are required, but
the PROC COPY doesn't execute without them.
Thanks to Ricci Hsial, China Trust, TAIWAN.
Change 23.345 Enhancement for the %READDB2 utility to read DB2 records.
READDB2 New WANTONLY option lets you create observations only in
Feb 13, 2006 selected datasets, with sub-options to DROP or KEEP the
variables you want in that dataset, and logic to choose
which observations are output. See documentation in the
comments, but for example.
%READDB2(IFCIDS=ACCOUNT,WANTONLY=DB2ACTB,
DB2ACTB=YES/IF QBACGET GT 0);
would create observations only in the DB2ACCTB dataset,
and only if the observation had non-zero GETS count.
Change 23.344 The KEEP= list for dataset FICON73 needed SYSNAME added,
ANALFIOE as a result of the RMF changes in MXG 23.11.
Feb 10, 2006
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 23.343 MXG 23.11. PDB.TYPE72GO NOT SORTED. Several BY statements
VMXGRMFI had only BY SYSPLEX SYSNAME STARTIME; but the correct BY
Feb 10, 2006 list is BY SYSPLEX SYSTEM SYSNAME STARTIME;. This error
only occurred when SYSTEM and SYSNAME were not the same.
Thanks to Paul Naddeo, FISERV, USA.
====== Changes thru 23.342 were in MXG 23.23 dated Feb 9, 2006=========
Change 23.342 Support for more Optional CICSTRAN "Candle" CICS fields
IMACICD9 Field/Variable Label IMAC
IMACICC1 CANFLAGS CANDLE*UMBRELLA*FLAGS IMACICD9
IMACICC2 CANGMTOF CANDLE*GMT*OFFSET IMACICC1
IMACICC3 CANUMBTR CANDLE*UMBRELLA*TRANID IMACICC2
IMACICC4 CANUMBUS CANDLE*UMBRELLA*PROGRAM IMACICC3
UTILEXCL CANUSRWK CANDLE*UMBRELLA*USER*WORKAREA IMACICC4
VMAC110 The UTILEXCL program must be used to create a tailored
Feb 8, 2006 IMACEXCL member, and the UTILEXCL output tells you which
Feb 15, 2006 of the IMACICxx members also must be EDITed to create the
optional variable(s) in the CICSTRAN dataset.
Thanks to John Shuck, SunTrust, USA.
Change 23.341 CICS Statistics dataset CICSJR variable SJRPRXMX, the XMX
VMAC110 value, was read as an 8-byte binary value, but the field
Feb 5, 2006 contains either blanks or '32M ' in EBCDIC text, and
reading text fields as binary gets large values:
input field read as binary decimal exponential
8-bytes of blanks 4.6*10**18
'F3F2'x -32- in first bytes 17.5x10**18
4-bytes of hex FFx 4,294,967,294 4x10**9
4-bytes of FFx 1,077,952,576 1x10**9
Now, new character variable SJRPRXCH is the text field,
which is parsed and decoded into the original numeric
variable SJRPRXMX, now formatted MGBYTES.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
====== Changes thru 23.340 were in MXG 23.11 dated Feb 2, 2006=========
Change 23.340 MXG support for Omegamon for DB2 Archive file records.
VMACOMDB -A short IFCID 44 record caused INPUT STATEMENT EXCEEDED;
Feb 2, 2006 the record was only 350 bytes, and contained none of the
actual IFCID 44 data fields; MXG now INPUTs the first 350
and tests to see if there is any more before INPUTing.
-IFCID 63 had a fixed INPUT of $5000 for the SQL text,
which caused INPUT STATEMENT EXCEEDED error when there
was a shorter text. This statement was taken as-is from
Candle's SAS code in 2003, but apparently no IFCID 63
data had been tested before by an MXG user or Candle!
The MXG logic now INPUTs using VARYING informat
Thanks to Rosaline E. Howe, IBM Global Services, USA.
Change 23.339 -Harmless DIVIDE BY ZERO because TOTSHARC was not tested
VMAC7072 to be non-zero, but results are still fine; the variables
Feb 2, 2006 LPARSHAR and LPARSHAC will be missing when TOTHARC=0.
-SHIFTHRS references in DROPs removed as it doesn't exist.
-Missing labels, and other RMFINTRV cosmetics cleaned
-TEST70SP did not include VMXGRMFI for NEWRMFI compare,
which caused many false positive comparison differences.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Chris Weston, SAS ITRM Cary, USA.
====== Changes thru 23.338 were in MXG 23.11 dated Feb 2, 2006=========
Change 23.338 ML-38 of MXGTMNT, Tape Mount/etc Monitor program adds new
ASMTAPEE event trace to the STK user exit in ASMHSCEX; we now have
ASMHSCEX excellent cooperation with STK developers who are working
Feb 1, 2006 with "asmguy" to install ML-38 at STK so we can diagnose
why we miss so many mounts in that user exit.
-ASMTAPEE corrects MXGC009E Unrecoverable error messages;
the error was introduced back in ML-30 with the Volume
mount enhancement, but only one site has reported only
two instances, and it was with ML-37.
-ML-38 also corrected 0C4 ABEND during processing of an
IEC6000I reply message in offline device allocation.
This note added Feb 21.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 23.337 Missing values for these PR/SM variables in PDB.RMFINTRV
VMAC7072 PLATBUSY,PLATCPUS,TOTSHARE,TOTSHARC,LPARSHAR,LPARSHAC
VMXG70PR can occur, even with Jan 31 MXG 23.11, but only if there
VMXGRMFI were short intervals, as when an LPAR is started/stopped,
Feb 2, 2006 or as when a Policy Change is issued, which wrote two
short intervals (an 8:45 STARTIME with a 2 minute DURATM,
an 8:47 STARTIME with 13 minute DURATM).
-Previously, those variables were extracted by ASUM70PR
from PDB.ASUM70PR dataset and merged into PDB.RMFINTRV;
however the rewrite in Change 23.322 to ASUM70PR uses the
SMF70GIE time interval (9:00 in the above example),
but the PDB.RMFINTRV is created for each of the STARTIME
values, so all of the old logic was moved from VMXG70PR
into the VMAC7072 and VMXGRMFI members.
-So: ASUM70PR no longer updates PDB.RMFINTRV.
-This, too, was not a trivial revision.
The biggest difficulty with this change was validation;
these short intervals created invalid data in the old
ASUM70PR/ASUMCEC datasets, which now have fewer obs than
the old MXG version, so this change was filled with false
positive differences in the PROC COMPARE output!
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
====== Changes thru 23.336 were in MXG 23.11 dated Jan 31, 2006=========
Change 23.336 Support for RMF with repeated SYSTEM names in a SYSPLEX.
VMAC7072 Variable SYSNAME (SMF70SNM) was inserted in the BY list
VMXG70PR for all RMF-based datasets. These RMF records all have
VMXGRMFI the same value in variable SYSTEM, but SYSNAME is unique
ANALRMFR to each system and must be used to separate them. Test
VMAC7072 data's SYSTEM was different from each of the two SYSNAME
ADOC7xxx values. The new RMF sort order is changed to:
ANALRMFR BY SYSPLEX SYSTEM SYSNAME STARTIME .... ;
Jan 29, 2006
ANALRMFR This change in sort order should have NO impact if you
VMAC70PR have no repeated SYSTEM names in a SYSPLEX. By putting
VMXG70PR SYSNAME to the right of SYSTEM, merges with old MXG data
Jan 31, 2006 (that were sorted BY SYSPLEX SYSTEM STARTIME...) won't
be impacted, and your report code with logic testing for
FIRST.SYSTEM or LAST.SYSTEM won't be impacted.
INCOMPATIBILITY:
ONLY if you have multiple SYSTEM names in a SYSPLEX do
you need to deal with this changes. You MUST revise BY
statements in your report programs, inserting SYSNAME
after SYSTEM, and using SYSNAME instead of SYSTEM in
reports. Tests for FIRST.SYSTEM or LAST.SYSTEM must be
changed to FIRST.SYSNAME or LAST.SYSNAME in your code.
But without this change, these multiple SYSTEM names
created incorrect output, without any error messages.
You might think having repeated SYSTEM names is dumb, but
it is useful for Disaster Recovery LPARs, and can avoid
changing SYSTEM in JCL, etc., when moving a SYSTEM to a
SYSPLEX that already has a SYSTEM with that same name.
Some initial revisions were made to ANALRMFR, but they
are still being validated, and those reports will be
enhanced to support selection by SYSNAME or SYSTEM.
Full list of members changed by this change:
ACHAP35 ADOC7072 ADOC70PR ADOC71 ADOC73 ADOC74
ADOC75 ADOC76 ADOC77 ADOC78 ADOC89 ADOCPDB
ANALDALY ANALFIOE ANALMPL ANALPGNS ANALRMFI ANALRMFR
ANALSRVC ANALSTOR ASUMMIPS DOCMXG GRAFWORK GRAFWORX
GRAFWRKX JCLQAOLD MONTHASC MONTHBL3 MONTHBLD MONTHBLS
MONTHDSK QASAS TEST70SP TRNDRMFN VMAC7072 VMAC71
VMAC75 VMAC76 VMAC77 VMXG70PR VMXGRMFI WEEKBL3
WEEKBL3D WEEKBL3T WEEKBLD WEEKBLDD WEEKBLDT
These changes are in the MXG 23.11 dated Jan 31, 2006:
Jan 31 updates (hooray - no critical changes!!):
-ANALRMFR: revised, not DROP SYSNAME after SHAR74).
-VMAC7072: cosmetic removal of duplicate SYSNAME in KEEP=
in several places, eliminated NOTE on log.
-VMXG70PR: variable SMF70GIE now kept in RMFINTRV.
-If _STY70 is executed twice, you will get an ABEND and
ERROR: DATASET WORK.TYPE70SP NOT FOUND
That error is intended, as it alerts you that your
program has caused that macro to be executed a second
time. Please rerun with
OPTIONS SOURCE SOURCE2 MACROGEN MPRINT;
and send the full log to support@mxg.com so we can
understand what you were doing that is incompatible with
the new MXG redesign.
-VMAC73: variable SYSNAME was added to KEEP= list for the
always-zero-obs TYPE73L,TYPE73P datasets; WEEKBLD etc
need those variables because they are in the BY list,
even though those datasets have not had observations for
decades. (And I can't safely stop creating them, as
that can only cause somebody's report program to fail.)
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Alain Delaroche, CA-Atlantica, FRANCE.
Thanks to Chris Weston, SAS ITRM Cary, USA.
Change 23.335 Variables SMF70OIL and SMF70SYN are added to dataset
VMAC7072 TYPE70; they have always been INPUT but were not kept.
Jan 27, 2006 SMF70OIL='ORIGINAL*INTERVAL*LENGTH'
SMF70SYN='SYNC*VALUE'
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 23.334 MXG's unwise default to NOT create observations from type
IMACINTV 30 subtype 2/3 records is finally changed so that now,
INSTALL observations will always be output into TYPE30_V dataset,
Jan 26, 2006 if the SMF file contained SMF 30 subtype 2/3 records.
-Always use PDB.SMFINTRV, created by BUILDPDB and NOT the
"raw" TYPE30_V dataset, nor the PDB.SMFINTRV created by
TYPS30 program; those other "PDB.SMFINTRV/TYPE30_V" data
sets still have incomplete data because they still have
those multiple observations if MULTIDD='Y'. Only MXG's
BUILDPB logic combines the multiple TYPE30_V obs into
a single complete observation in PDB.SMFINTRV.
-The default was unwise because many new users have wasted
their time and were frustrated when they got no output,
and wasted more time looking for what they had done wrong
OK, they had done something wrong: they had failed to
read (and understand the impact of) every word in the
INSTALL member, which is where I documented that zero
obs would be created by default!
-I originally chose to not write the interval record when
they first appeared in 1980, because I was concerned for
the additional disk space that might blind-side your fine
running daily job, and because back then they weren't
sychronized with time of day, and were not of much use.
-Now, however, PDB.SMFINTRV is synchronized, so you can
create legitimate interval sums of all tasks to compare
with RMF, and potentially use in place of PDB.RMFINTRV
for workload measurement, and it so important that it is
normally created by everyone, and so I could have saved
many support calls if I'd changed the default a long time
ago. And, the cost of a little of DASD space is still a
lot cheaper than the cost of the beginner's time and
frustration, so it now is populated by default.
Change 23.333 Cosmetic. Missing Value calculations when OFFWQ was a
VMAC116 missing value; now, OFFQW is tested first so those log
Jan 26, 2006 messages are eliminated.
Change 23.332 Variables HFLLIST and HFPGACT are accumulated in the raw
VMACVMXA z/VM MONWRITE data, but were not de-accumulated in MXG.
Jan 25, 2006 Logic to use DIF() was added to properly decode and
Feb 1, 2006 convert them to percentages.
Feb 1: typo HFLPGACT corrected to HFPGACT
Thanks to Kris Ferrier, State of Washington DIS, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.331 Support for NDM/Connect-Direct subtypes TF, TL, and TW
EXNDMTX (TCQ Full, TCQ Below Threshold, or TCQ At Threshold)
IMACNDM create observations in the new NDMTX dataset.
VMACNDM
VMXGINIT
Jan 25, 2006
Thanks to David Kaplan, Depository Trust, USA.
Change 23.330 Change 23.321/322 corrections:
TEST70SP The "best tested ever" revisions in MXG 23.10 for RMF 70s
VMAC7072 were still not perfect. The TYPE70/TYPE70PR/ASUM70PR and
VMXG70PR ASUMCEC datasets have had no reported data-value errors,
VMXGRMFI but the RMFINTRV dataset had missing values for the PR/SM
Jan 24, 2006 variables, due to an incorrect sort order, and errors in
Jan 26, 2006 building the WEEK/MONTH PDBs with new/old data uncovered
Jan 27, 2006 the need for additional PROC SORTs to put the new data
back in the old and expected sort order.
Chronological list of revisions to the revision:
23Jan2006:
-VMXG70PR. Cosmetic. Variables SYSPLEX SYSTEM were in
KEEP list for the new ASUMCELP but should not have been;
only impact was a possible WARNING message.
24Jan2006,27Jan2006:
-TEST70SP fails in its comparison of OLDRMFI and NEWRMFI,
with VARIABLES SYNCTIME LPARNAME LCPUADDR not found. The
two BY statements for the two SORTs and one BY statement
for the DATA step in lines 88-96 of TEST70SP should be:
BY SYSPLEX SYSTEM STARTIME;
BY SYSPLEX SYSTEM STARTIME;
BY SYSPLEX SYSTEM STARTIME;
26Jan2006:
-VMXGRMFI fails if SPIN.SPINRMFI dataset had observations:
ERROR: BY VARIABLES NOT SORTED ON DATASET WORK.SPINRMFI
because the new logic needed a sort of the old SPINRMFI
into the new sort order.
-VMXG70PR rebuilt PDB.RMFINTRV caused OUT OF SORT ORDER
error when (for example, WEEKBLD) old and new RMFINTRV
datasets were combined. Adding a final sort to force the
output to be BY SYSPLEX SYSTEM STARTIME corrected.
27Jan2006:
-VMXG70PR creation of PDB.TYPE70PR needed an additional
PROC SORT to put it in the original SORT order for the
WEEKLY merge.
-VMXG70PR rebuild PDB.RMFINTRV had missing values for the
"PLATCPUS" variable; re-sequencing the BY statements was
necessary.
All four members have now been redated 27Jan2006, so you
will know you have all current changes.
Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.
Thanks to Alain Delaroche, CA-Atlantica, FRANCE.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Change 23.329 Variable CPUCEPTM, CPU Time while Enqueue Promoted is
VMAC30 accumulated in SMF 30 interval records, but Change 22.326
BUILDPDB added logic to deaccumulate CPUCEPTM in PDB.SMFINTRV.
BUILDPD3 Now, IBM has added field SMF30CEPI, the interval CPU time
Jan 23, 2006 and MXG creates new variable CPUCIPTM from that field in
all of the TYPE30 datasets, as well as in PDB.STEPS and
PDB.JOBS.
Thanks to Scott Barry, SBBWorks, Inc, USA.
====== Changes thru 23.328 were in MXG 23.10 dated Jan 23, 2006=========
Change 23.328 New macro variable &MXGEOF with null value is now called
VMACSMF when EODOFSMF or ENDOFLOG condition is true; you could
VMXGINIT use &MXGEOF to execute code, like storing the MNSMFTME
Jan 22, 2006 value into a macro variable for subsequent use. While
Jan 26, 2006 this may look slightly kludgy, using an old-style macro
to hold the text (quotes, parens, semicolons etc.) that
is to be stored into a %LETed macro variable is often
much safer, cleaner, and easier to type-in, although the
use of %LET macvar= %QUOTE ( ... text ... ) ; may often
be all that is required, and, occasionally, you can even
use %LET macvar= ... text ... ;, but this always works to
pass executable SAS code into a macro variable:
MACRO _MXGEOF
CALL SYMPUT("MNSMFTME",PUT(MNSMFTME,DATETIME21.2));
%
%LET MXGEOF= _MXGEOF ;
%INCLUDE SOURCLIB( .. any SMF processing ) ;
%PUT &MNSMFTME;
Jan 26: Two instances of ENDOFSMF in seldom-used JOURNAL
INFILEs were corrected to ENDOFLOG; only impact was an
UNINITIALIZED VARIABLE ENDOFLOG message on the log.
Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.
Change 23.327 Enhancements to IBM-RMF-Report-like report examples.
ANALRMFR Revisions for Change 23.321 to insert _STY70 when PDB=SMF
Jan 22, 2006 and REPORT=CPU is requested.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.326 Macro variable PSUDB2 (used only by the new ASUMDB2) was
VMXGINIT not GLOBALed, even though it was %LET in VMXGINIT, caused
Jan 18, 2006 APPARENT SYMBOLIC REFERENCE PSUDB2 NOT RESOLVED on MVS.
Thanks to John Riera, InfoCrossing, USA.
Change 23.325 Syntax error 180 underscoring _C1020, only when TRACECLS
READDB2 argument is used, was introduced by Change 23.287 and is
Jan 18, 2006 corrected by relocating the test for TRACECLS argument to
Feb 17, 2005 after the include of VMAC102 code.
Feb 17: MAC102S initialized, eliminated error if no 102s
were requested.
Thanks to Thomas Zuber5, Independence Blue Cross, USA.
Change 23.324 On IBM's recommendation, these TPF Continuous Data values
VMACTPFC are now converted to rates per second by division by the
Jan 20, 2006 TPFCTDIF interval duration, which is already in seconds
and fractions. Their labels were also revised as shown:
Variable Label
TPFCHMSG HIGH*SPEED*MESSAGES*PER SEC
TPFCLMSG LOW*SPEED*MESSAGES*PER SEC
TPFCROEN ROUTED*ENTRIES*PER SEC
TPFCCREN CRTD*ENTS*PER SEC
TPFCSIMS SSCP*INPUT*MESSAGES*PER SEC
TPFCCIMS INSDB*IN*MESSAGES*PER SEC
TPFCCMTS COMMITS*PER SEC
TPFCCFRQ CF*REQUESTS*PER SEC
Thanks to Chris Weston, SAS Institute Cary, USA.
Thanks to Martha Hays, SAS Institute Cary, USA.
Thanks to Luis R. Vega-Zayas, IBM, USA.
Change 23.323 IBM APAR OA14365 corrects negative CPUUNITS in SMF 30s,
VMAC30 which occurs only when IFAs are used, and only when the
Jan 16, 2006 address space had little activity. The negative value is
created when CPUUNITS=CPUUNITS-IFAUNITS finds IFAUNITS
are greater than CPUUNITS. CPUUNITS is SMF30CSU, and
IFAUNITS=CPUIFATM*CPUCOEFF*LOSU_SEC or in IBM names:
(SMF30_TIME_ON_IFA) * SMF30CPC * (16000000/SMF30SUS)
MXG now detects that the CPUUNITS are negative, and
prints warning messages on the SAS log that you need to
install this APAR. Text revised March 6, 2006.
Thanks to Micchia Marco Antonio, UniCredit, ITALY.
Change 23.322 Support for 60 LPARs and corrections to ASUM70PR logic:
VMAC7072 z/OS 1.7 now supports up to 60 LPARs; your MXG code will
VMXG70PR fail with messages (ARRAY OUT OF RANGE) if you have an
Jan 19, 2006 LPARNUM greater than 32. This change was extensive:
-VMAC7072:
Size of temporary ARRAY S70LPCP was increased from 32
to 60. No other changes were required for the TYPE70
and TYPE70PR datasets.
-VMXG70PR summarization.
1. New PDB.ASUMCELP dataset is created from PDB.ASUMCEC,
with only one set of variable names, and it should be
used for reporting instead of PDB.ASUMCEC.
2. Major mechanical rewrite to support 60 LPARS.
Created 28 sets of 25 new variables for each of the
new LPARs in the PDB.ASUM70PR and PDB.ASUMCEC datasets
(so they are even more unwieldy for report writing).
While those datasets are valid, I strongly recommend
that you instead use PDB.ASUM70LP and PDB.ASUMCELP
datasets, instead of PDB.ASUM70PR and PDB.ASUMCEC;
those "LP" datasets have only one set of variable
names, for easy reporting, and you can select by
LPARNAME. The LPARNUM is no longer valid because an
LPARNAME's LPARNUM will change if a new LPARNAME is
created (LPARNUMs are set by alphabetical LPARNAME
order).
But in case you have reports based on those clumsy
sets of variable names in ASUM70PR/ASUMCEC datasets,
the variable names for LPARs 33-34 have Y and Z as
markers (1-9 and A-X were used for LPARs 0-32), and
these new names are created for LPARs 35-60 in the
(archaic, but valid) ASUM70PR and ASUMCEC datasets:
LPARS 0-34 LPARS 35-60
LPnAAAAA LQnAAAAA
LPCTnAAA LQCTnAAA
PCTLnAAA PCTQnAAA
3. MXG variable CPUOVHTM has been wrong for some time;
it contained both LPPUPDTM and LP0MGTTM, which are
identical measurements of the "PHYSICAL" CPU time, and
only one of them should have been included; this error
caused both the CPUOVHTM and PCTOVHD values to be
slightly too large.
4. LPARs with the same STARTIME but different DURATM's
caused incorrect calculations in PCTCPUBY and/or in
individual LPAR percentages, which could be over 100%,
in the ASUM70PR/ASUM70LP/ASUMCEC summary datasets.
To properly summarize data across a CEC, neither the
STARTIME nor SYNCTIME can be used to identify the
minimum set of interval data from all systems on that
CEC. STARTIME has been documented as varying by one
to several seconds for the same logical interval on
the same CEC. While SYNCTIME is constant in all RMF
records for a "normal" interval, when a WLM Policy
Change was made for six of nine LPARs in a CEC, there
were six 1.5-minute-DURATM obs, three 15-minute-DURATM
obs, and then six 13.5-minute obs. Those six 1.5
minute short duration records, written as a result of
the policy change, each had a unique SYNCTIME, so it
could not be used to group the observations. Only the
SMF70GIE value appears to be safe to use to get all of
the pieces together in CEC and 70PR/70LP summarization
and this redesign now uses SMF70GIE in place of the
STARTIME for the grouping into summary intervals.
(RMF Development later confirmed that they also use
SMF70GIE for their report grouping. 26Apr2006.)
5. PDB.ASUMCEC will contain invalid data if your LPARs
are on different time zones; you must use TIMEBILD to
force all of the datetimes to a single time zone for
ASUMCEC/ASUMCELP to be valid.
6. For ASUMCEC/ASUMCELP, comparisons should be extremely
close, but possibly not exact, for "normal" intervals.
For intervals were some LPARs were not present for the
full interval, or when a Policy Change was issued,
i.e., when there are more than one STARTIME in an
SMF70GIE interval, the new code should be correct,
creating only one observation for each SMF70GIE,
whereas the old code had an observation for each
STARTIME, and the old data for those "broken"
intervals was usually incorrect.
7. The circumvention member EXCECTIM is now unnecessary
and is no longer referenced by MXG code.
Thanks to Alain Delaroche, CA-Atlantica, FRANCE.
Change 23.321 Support for Split RMF 70 records: CRITICAL. SPLIT70.
VMAC7072 -If you have enough LPARs (32) with SPARE engines, IBM now
XMAC7072 splits the RMF 70 data into multiple physical SMF records
TEST70SP that are completely INCOMPATIBLE and REQUIRE this change.
Dec 7, 2005 MXG KNEW SPLIT RECORDS COULD EXIST AND PRINTS TEN ERROR
Jan 19, 2006 MESSAGES ON THE LOG THAT THERE ARE ERRORS AND BAD DATA.
Change 22.344, Jan, 2005, added that logic in MXG 22.22.
-But until I had actual records, I couldn't revise MXG.
-The support required a complete restructure of the code
and logic that creates the TYPE70 and TYPE70PR datasets
from RMF or CMF type 70 SMF records. None of the other
datasets created in the VMAC7072 "product" code were
touched by this change. Work started at CMG, and across
the holidays in chunks of development and testing using
RMF and CMF data from 33 sites that were not split (so
the old and new logic could be compared; the old logic
created trashed data with split records so there is no
"old" for split). Instead, the ANALRMFR RMF-like report
was compared with IBM RMF reports from the one split RMF
70 record that precipitated this major redesign!
-As long as you use BUILDPDB/3, RMFINTRV, TYPE7072 or the
TYPS7072 MXG code to read your RMF/CMF 70/72 records, the
MXG redesign will execute transparently with MXG 23.10+:
- Dataset WORK.TYPE70 initially has zero observations
after the SMF data is read; instead, new WORK.TYPE70SP
dataset will have observations, whether your records
are split or not.
- The WORK.TYPE70PR dataset is created from SMF, but it
is completely invalid if it was created from a SPLIT
SMF 70 record.
- The redesign now must invoke the _STY70 Data Set Sort
macro, which processes the WORK.TYPE70SP/TYPE70PR data
and in that process, creates these temporary datasets:
SORT70SP - Sort of TYPE70SP
PHYSICAL - LPARNAME='PHYSICAL' obs from TYPE70PR
NUCPCXPU - Count CPs, ICFs, IFLs, IAFs from PHYSICAL
THISPART - PARTISHN=LPARNUM subset from PHYSICAL
FROM70PR - Summary, create LPARn vars from THISPART
Three (SORT70SP, FROM70PR, NUCPSCPU) are then merged
to create the PDB.TYPE70 output dataset, which is also
enhanced by the addition of these new variables:
LPARNAME SMF70BDA LCPUDEDn-x, LCPUWAIn-x
Then _STY70 logic sorts TYPE70PR into SORT70PR so it
can be MERGEd with NUCPSCPU to populate the PARTNCPU
and NRICFCPU/NRIFLCPU/NRIFACPU variables from the
PHYSICAL segments to create the PDB.TYPE70PR dataset.
-If you use YOUR OWN CODE that uses the _VAR7072 _CDE7072
macros, then you MUST also invoke the _STY70 macro to
create the TYPE70 and TYPE70PR datasets; otherwise, you
will have zero observations in TYPE70 and bad data in the
TYPE70PR dataset. (If you already use the _S7072 product
sort macro to sort all of the 7072 datasets, you're home
free, since the product sort macro always invokes the
data set sort macro for all datasets from that product.)
The default output DD for _STY70 is "PDB" for both the
TYPE70 and TYPE70PR datasets. If you want your old
code to continue to write those two datasets to the
"WORK" DDname, you would insert:
%LET PTY70=WORK;
%LET PTY70PR=WORK;
before your DATA step.
-Note that _STY70PR sort macro is now null and must be
replaced with _STY70.
-The MXG TYPE7072 member now must invoke the _STY70 macro,
but with %LETs inserted in TYPE7072 so that the rebuilt
TYPE70/TYPE70PR datasets are still written to //WORK.
(So an existing %INCLUDE SOURCLIB(TYPE7072) will still
create those datasets in the //WORK library.)
But if you use %INCLUDE SOURLIB(TYPE7072), you can not
add an invocation of _STY70, because of that under the
covers execution. And you'll get an error if you do:
-You can get ERROR: FILE WORK.TYPE70SP DOES NOT EXIST:
a. if you do attempt to invoke _STY70 a second time,
b. if you have an old VMAC7072 in your "USERID" tailoring
source libraries
c. if your predecessor had (incorrectly) tailored MXG and
had redefined MACRO _VAR7072 or MACRO _CDE7072 macros
(usually in IMACKEEP member). It has ALWAYS been
incorrect installation tailoring to redefine those
critical MACRO _VARxxxx or MACRO _CDExxxx macros in
your USERID MXG Tailoring Library, precisely because
they block MXG from it correct definitions.
-ITRM/ITSV section: revised Jan 31, 2006:
Most ITRM sites do NOT have to do anything at all for the
new 70's architecture, as long as you create XRMFINT (the
RMFINTRV MXG dataset) with your %CMPROCES ITRM execution.
ONLY if you process RMF 70 records, but do NOT create
the RMFINTRV dataset, you will, at present, need to
insert the text _STY70 in your EXPDBOUT member.
This original change text said all ITRM sites needed
to add that statement, but that text was wrong, and it
is the rare site that would process 70s without also
creating the XRMFINT/RMFINTRV dataset. A later change
to ITRM can be expected that will make the invocation
of _STY70 internal to ITRM, and that statement will
need to be removed at that time.
-This iteration has no protection for incomplete sets of
split records: first record filled today's SMF file, next
record is in tomorrow's SMF file. That may be done in a
later iteration, using the //SPIN DD to hold data.
-VSETZERO member has been removed from the VMAC70s logic.
It was added in MXG 23.03 by Change 23.070 in an
attempt to deal with inconsistent STARTIME values
across LPARs, by setting STARTIME to the exact minute
when seconds were 58,59, or 01-10.
It is removed because the unchanged STARTIME value must
be used for the merge of the split records, but also
because VMXG70PR is revised in Change 23.323 to use the
SMF70GIE variable for the merge, and the minimum value of
STARTIME is used only for reporting those summary data.
-In both rewrites, I discovered a few cases in which the
old MXG code was inconsistent or even wrong:
- LPARn variables for unused LCPUADDRs were occasionally
zeros when they should have been a missing value; now
they are always missing. Had no impact on your data,
but they cause false positives in PROC COMPARE in the
TEST70SP program because they are different.
- Handling of engines with CAI='00'x (not on at end of
interval) and CAI='02'x or CAI='03'x (error flag on)
was inconsistent in the old code. Since SMF70ONT now
should be populated, it is used to determine if each
engine's dispatch/wait times are included in totals,
impacting the values in those individual "n" engine
variables and the totals, in particular variables
MVSWAITn,CPUWAITn,CPUPDTMn,CPUEFFMn and
MVSWAITM,CPUWAITM,CPUPDTMM,CPUEFFMM
If these values differ in your compare, look first at
the CAIn variables to see if they account for the
compare differences, knowing the new is correct now.
- Because values are now summed and then divided that
were previously divided and then summed, some small
differences (less than .001 absolute value) were found
in some time and percentage variables, but they only
impacted the PROC COMPARE, and not the real world.
- Duplicate SMF records were not always deleted, which
caused PCTCPUBY in ASUM70PR and ASUMCEC over 100%.
The sort order of TYPE70PR to remove duplicates is:
BY SYSPLEX SYSTEM SYNCTIME STARTIME SMF70GIE LCPUADDR;
- Variables NRICFCPU and NRIFAS in ASUM70PR/ASUMCEC were
sometimes incorrect in the old code.
- The SMF6CNF bit macro no longer exists; not needed with
the revised handling of the CAI '02'x and '03'x values.
- APAR OA14024 just reported that the IBM RMF Report Writer
fails with an ABEND 0C4 when it tried to read a split SMF
70 record from a system with 60 LPARs, because the total
length of all records was then over 64K bytes, a value
that killed the report writer, due use of a signed field.
And this happened after an RMF Developer told me that it
was very simple to reassemble their split data!
- This SMF 70 record really did not need to be split by
IBM now! The record contained 368 LCPUADDR segments from
the 32 LPARs, but there were actually only 68 LCPUADDR in
use; all of the other LCPUADDR segments were for each of
the SPARE engines on the z9, so if IBM had chosen to only
write the non-SPARE engine's, this rewrite would not have
occurred now. But, the rewrite is now done so the future
is safe.
- New TEST70SP member creates TYPE70/TYPE70PR datasets with
the old MXG 23.09 code (in XMAC7072 member) and with the
new VMAC7072 code, and uses PROC COMPARE to identify any
differences between new and old logic. TEST70SP can ONLY
be used with NON-SPLIT RMF 70s.
(The old code didn't support split records, which cause
multiple TYPE70 observations with same STARTIME and
with incorrect data values.)
It also created new and old ASUM70PR and ASUMCEC data and
compares them, but if your data has multiple STARTIMEs in
an SMF70GIE interval, the old and new will not compare,
as the old was split into multiple observations, but the
new logic correctly summarizes those multiples, so there
will be fewer observations in the new compared with the
old, which PROC COMPARE reports as lots of differences,
but there is no error.
Thanks to Matt Clarke, Charles Schwab & Co., Inc, USA.
Thanks to Neil Ervin, Charles Schwab & Co., Inc, USA.
Change 23.320 -Truncated SMF 102 record caused INPUT STATEMENT EXCEEDED
VMAC102 RECORD LENGTH error is now detected and reported on the
Dec 23, 2005 SAS log as a truncated record, rather than an ABEND.
-IFCID 83 record from DB2 V7.1 caused similar ABEND, but
this was because the MXG code for that IFCID was only
for DB2 V8.1, as only that version's test data had been
received; now, both V7 and V8 IFCID 83 are supported.
Thanks to Tony Pratt, Tampa Electric, USA.
Change 23.319 New ASUMDB2 program summarizes DB2ACCT events to create
ASUMDB2 interval (hourly default) transaction counts, resources,
VMXGINIT and response time buckets, using the same macro variables
Dec 18, 2005 to define those buckets as are used in ASUMCICS/ASUMCICX
that creates PDB.CICS.
Thanks to John Rivera, (i)Structure, USA.
Change 23.318 Incorrect syntax with character text for NRPERIODS caused
VMXGRMFI strange and unobvious error messages; now, if NRPERIODS
Dec 18, 2005 is not a number, the execution will ABEND so you can fix
your syntax.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 23.317 -Syntax error in TRNDUOW due to a semi-colon after a ELSE.
TRNDCEC -Variable NRPRCS NOT FOUND in TRNDCEC because it was
TRNDUOW removed some time ago.
Dec 18, 2005 -TRND members had not been fully tested in QA, now are.
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 23.316 Changes to VGETENG required corresponding changes to this
UTILCONT utility that provides the size of contents of your SAS
Dec 15, 2005 data libraries.
Thanks to Paul Naddeo, FISERV, USA.
Change 23.315 Dataset ICFD70PR NOT SORTED error due to short interval
ASUM70PR RMF records required yet another sort to force proper
Dec 15, 2005 sequence.
Thanks to Jimmy J. Hu, Ameren, USA.
Change 23.314 Documentation only. APAR OA06476 documents that TYPE74CA
VMAC74 fields R745INCR, R745BYTR, R745BYTW, R745RTIR, R745RTIW
Dec 13, 2005 have never been populated and are now reserved fields
that will always be zeros. The data was planned for the
2105 800 models, but the data was not available on those
boxes. The data has become available with the 2105 box,
but that interface and APAR OA06476 adds new R7451INC,
and R7451CT1-4 to RAID Rank/Extent Pool Section.
Change 23.313 -Variables R791TIFC/R792TIFC were incorrectly normalized
VMAC79 by R791NFFI/R792NFFI, but they are already in CP seconds
Dec 12, 2005 so they are no longer normalized.
-Variables R791TCP and R729TCP are now deaccumulated, and
the label for R792TCP is now correct.
-Text in Change 22.152 now has correct variable names and
labels for TYPE791 and TYPE792 IFA-related variables.
-Change 23.132 updated to list the TYPE79 changes made.
Thanks to Rick Southby, Insurance Australia Group (IAG), AUSTRALIA.
Change 23.312 New CICSBAD dataset contains "bad" CICSTRAN observations,
EXCICBAD that were previously output in CICSTRAN dataset, but are
IMACCICS known to be defective, and so are now output in CICSBAD.
VMAC110 There are two "bad" conditions supported in this change:
VMXGINIT -When a user types in a TRANNAME that is not a valid name,
Dec 9, 2005 there still is a type 110 segment created with missing
Feb 9, 2006 fields, and TRANNAME contains whatever was typed. Those
records are identified by PROGRAM='########', and are
now output into dataset CICSBAD rather than CICSTRAN.
While these records are usually just typos, hackers have
been known to keep typing names until they find one that
works, so these records might be useful in CICS security
issues. Each record has between 3 and 4 milliseconds of
CPU time in TASCPUTM, which I presume is the fixed cost
to create a CICSTRAN observation (speculation - there may
be uncaptured CPU) on a SU_SEC=10000 speed engine.
-When a CICS task is executing on an OPEN TCB, and is then
purged, APAR PQ86971 documents that all of the clocks are
invalid when this happens, and that APAR adds a new bit
to the TRANFLAG field to identify these tasks. Since the
clock values are all wrong, these transactions are now
also output in CICSBAD instead of CICSTRAN.
-So, CICSBAD will now contain all PROGRAM='########' obs,
and all transactions purged on an open TCB, and CICSTRAN
will no longer have any of those invalid transactions.
-The format for CPU-time fields were changed to TIME13.3,
to display the millisecond level; TIME16.6 would show the
full resolution, but would cause reports based on the
current length to be shifted, so it was not chosen.
Change 23.311 Support for Beta 91 Version 3.1.1.0, which INCOMPATIBLY
VMACBE91 changed the header of their record, and all subtypes.
Dec 8, 2005 This iteration supports BETA91B and BETA91C datasets,
Dec 12, 2005 which were validated with '44'x and '50'x subtypes. Two
other datasets have not been tested with real records.
Thanks to Herve Brusseaus, Fortis Bank, LUXEMBOURG.
Change 23.310 Variable ESMFNTRN was always missing because it existed
VMACMPLX only in a LABEL statement, and was misspelled. The count
Dec 8, 2005 of transactions is in variable ESMFTRAN.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch., USA.
====== Changes thru 23.309 were in MXG 23.09 dated Dec 7, 2005=========
Change 23.309 INVALID ARGUMENT TO FUNCTION SQRT error when an invalid
VMXGUOW transaction (PROGRAM='########') was processed. In the
TRNDUOW VMXGUOW member, CICSTRAN obs with that PROGRAM name are
Dec 7, 2005 now deleted prior to summary, and TRNDUOW is protected.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.308 MXG 23.08-23.09. Note VARIABLE JOBINFO1 IS UNINITIALIZED
VMAC26J2 because of an incomplete ending-comment; fortunately, the
Dec 5, 2005 only impact was that these four variables: OPTJOURN,
OPTOUTPT, TYPRUN and RESTARTD will all be blank.
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Change 23.307 INPUT STATEMENT EXCEEDED after "DTP=24 SEGMENT.." message
VMAC80A because the additional segments were not processed after
Dec 5, 2005 that MXG message.
Dec 9, 2005 -Dec 9. Same error corrected for DTP=25 SEGMENT.
Thanks to Coen Wessels, Unicible, SWITZERLAND.
Thanks to Mark Nouwen, Dexia, BELGIUM.
Change 23.306 MXG variables PARTNCPU and NRICFCPU/NRIFACPU/NRIFLCPUs
VMAC7072 still wrong on z9s, because IBM's SMF70BNP field is in
VMXG70PR error on z9s. MXG calculated PARTNCPU from SMF70BNP,
Dec 5, 2005 but in earlier platforms, SMF70BNP included the count of
Dec 7, 2005 ICFs, which MXG subtracted. So when the z9 added new
'IFA' and 'IFL' values to SMF70CIN, I assumed those also
needed to be subtracted from SMF70BNP. Now, however,
IBM confirmed SMF70BNP is in error and will be changed
with the next z9 microcode:
the expected MCL number containing this change is
J99671.014 in driver d63j (Jan, 2006)
and recommended that instead to count of engines in the
PHYSICAL segments, rather than use SMF70BNP, so this
change does set PARTNCPU from the count of CPs in the
PHYSICAL partition records.
Dec 7: The Dec 5 change accidentally fixed the z9 data
and un-fixed other processors, because I had
spelled PARTNCPU as PLATCPUS in both the code
and text of the original change. PARTNCPU is
the name in the type 70 datasets; PLATCPUS is
the name only in the RMFINTRV dataset.
-In VMXG70PR, NRICFCPU and NRIFACPU could also be wrong;
a SUM was used where a MAX was required; because my test
data has only one of each, the SUM and MAX were the same
and the logic error was not detected.
-Variable NRPRCS is no longer kept in PDB.ASUM70PR and
PDB.ASUMCEC datasets; it has no meaning for those data.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 23.305 Optional OPID variable was never INPUTed!
IMACICO1
Dec 2, 2005
Thanks to Lucy Fukushima, California Health and Welfare, USA
Change 23.304 ANALCNCR could fail when an observation with missing
ANALCNCR values for the number of concurrent events was being
Dec 2, 2005 generated, which caused the calculation of the Y-axis
to fail. The record with missing values is dropped and
axix calculations were protected for the possibility of
missing values.
Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.
====== Changes thru 23.303 were in MXG 23.10 dated Dec 1, 2005=========
Change 23.303 First MXG 23.09 only, and only under SAS Version 8: ERROR
VGETENG LIBNAMES IS NOT A RECOGNIZED PROC SQL DICTIONARY TABLE.
Dec 1, 2005 Change DICTIONARY.LIBNAMES to DICTIONARY.MEMBERS and
Dec 2, 2005 the PROC SQL will work under either V8 or V9.
The LIBNAMES dataset in the DICTIONARY was new in V9,
and we failed to test under V8 with the first 23.09.
Dec 2: We now test version, and use LIBNAMES with V9 or
use MEMBERS with V8. The advantage of the LIBNAMES is
that we can get the engine as long as the LIBNAME has
been referenced (either with a LIBNAME statement, or
implicitly by referencing a dataset), whereas the MEMBERS
only exists if a dataset in the library has been opened.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 23.302 -The RACF Unload Utility output have always had a 4-digit
EXRAC2A0 numeric "RECNR", in EBCDIC, but now a new '02A0' value
IMACRACF is found, which caused INVALID DATA FOR RECNR error.
VMACRACF Since numeric RECNR was a kept variable in all datasets,
VMXGINIT new character variable RECTYPE is now INPUT and used in
Nov 30, 2005 all tests, were also changed to character syntax.
-The new RACF02A0 dataset, for USER OVM DATA, is now
created by this change.
-I am now aware of additional new RECTYPE values and they
are listed in the comments in VMACRACF as "NOT DECODED",
as I need test records to support them.
Thanks to Bruce Hewson, Citigroup N.A., SINGAPORE.
Change 23.301 The MXSMFTME and MNSMFTME variables now exclude SMF 2 & 3
VMACSMF header/trailer records (created in the output SMF file
Nov 30, 2005 when IFASMFDP dumps, or later copies, an SMF file). The
ID 2 and 3s record when the dump/copy program ran, and
do not describe the range of timestamps of the SMF data.
Thanks to Erik Janssen, ING Netherlands, THE NETHERLANDS.
====== Changes thru 23.300 were in MXG 23.09 dated Nov 30, 2005=========
Change 23.300 -ML-37 of MXGTMNT monitor now captures SYSLOG messages in
ASMTAPEE a new SMF subtype 8 for these mount-related events:
ASUMTAPE IEC501A IEC501E IEC705I IEF233A IEF502E IEF234E IOS070E
EXTMNSTS IECTMS6 IECTMS9 IOS690I IEF235D
EXTMNSYM and a new subtype 9 record can be written for any other
EXTMNSYS SYSLOG messages you want captured in your SMF data!
IMACTMNT -Two new MXG datasets are created from MXGTMNT's subtypes:
VMACTMNT dddddd dataset description
VMXGINIT TMNSYT TYPESYMT Mount-specific SYSLOG, subtype 8
Nov 28, 2005 TMNSYL TYPESYSL User-selected SYSLOG messages, st 9.
Jun 15, 2006 -Added Jun 15, 2006:
This redesign REQUIRES you to use ASMTAPEE at ML-38 or
later, as it depends on the SYSLOG Mount-specific records
and there will be zero observations in PDB.ASUMTAPE if
there are zero obs in TYPESYMT syslog mount dataset.
-For the IBM IEF_VOLUMEMNT exit, we seem to capture every
mount that is issued with an IEF233A mount message, and
we appear to capture no mount that is issued with any of
the other messages, in particular, the IEC501A message
that is issued for second-volume mounts of a multi-volume
tape dataset. IBM Support confirmed that is correct for
their exit; it is taken only for Allocation's mounts, and
those OPEN/CLOSE/EOV mounts (the IEC501x messages) do not
go thru that exit. I hope to propagate the jobstuff from
the first mount into the second mount for these multi-vol
mounts, but there are also IEC501A mounts that are the
first and only mount for a job, so I need more test data
from the ML-37 monitor with SYSLOG data to fully resolve
what is and is not captured in the IBM exit, and how the
logic in ASUMTAPE can be enhanced further.
-Revised Jun 15, 2006:
For the STK UX01 exit, STK Support has now installed our
ASMHSCEX and have 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.
-For IBM, SYSLOG data goes a very long way to resolve.
True, you do NOT know the actual duration of the mount
(TAPMNTTM will be missing if MXGTMNT missed the mount)
and the READTIME variable will be missing, so you cannot
directly MERGE the ASUMTAPE back to the PDB.JOBS for any
simple match for billing, but almost all of the jobstuff
that we got from the MXGTMNT data is now picked up from
the SYSLOG data, so the PDB.ASUMTAPE with these changes
is of far better quality than it every as been before.
-But expect revisions to the ASUMTAPE program after more
test data has been received; early adapters of this new
code are requested to send their SMF records (the MXGTMNT
user-SMF record, AND the SMF type 21 dismounts) so that
the new data can be better understood; member SENDATA in
MXG 23.09 has the instruction (and new ip address) to
send SMF data to our ftp site.
-The Tape Allocation subtypes that create TYPETALO data
is still sampled, so job-related data can be missing in
that dataset; I hope to be able to merge the job-stuff
from this new PDB.ASUMTAPE dataset into those missing
variables in PDB.ASUMTALO, in a later enhancement.
-Additional documentation notes:
This enhancement makes the MXGTMNT program in ASMTAPEE,
the "MXG Tape Mount, Tape Allocation, Tape Swap, Tape
Allocation Recovery, and SYSLOG message monitor". The
messages captured in the "MXG-owned" subtype eight are
these that needed for tape mount event events:
IEF233A - First Volume Mount, Allocation Issued
IEF501A - OPEN/CLOSE/EOV, MULTI-VOL, or DEFERRED MOUNT
IEF501E - 2nd+ Volume for OPEN/CLOSE/EOV "Look Ahead"
==> 3 seconds --
IOS070E - MOUNT PENDING sss
IECTMS6 - DEVNR,VOLSER,IS APPROVED FOR TRTCH CHANGE
IECTMS9 - DEVNR,VOLSER, DSNAME17 at OPEN
==> actual time to mount ==> TAPMNTTM
IEC705I - TAPE ON DEVNR,VOLSER
==> duration tape was mounted ==> TAPMTDTM
TMS014 - Copy of IEC502E or IEF234E message
IEF502E - Intermediate Volume KEEP
IEC234E - Last Volume KEEP
and these additional messages are captured in subtype 8
to identify causes of known tape mount delays:
IEF690I - FOLLOWING VOLUMES UNAVAILABLE
IEF235D - JJJ STEP WAITING FOR VOLUMES
IEC205I - VOLUME LIST
New dataset TYPESYMT (SYSLOG MounTs) decodes those SYSLOG
records, which include the JOB, JESNR, SYSTEM, ASID, and
the EVENTIME (same .01 second resolution as SMFTIME).d
The below left-to-right examples show some examples of
the sequence of SYSLOG mount-related event records:
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
New dataset TYPESYSL (SYSLOG Messages) can be populated
with any SYSLOG messages you chose to ask MXGTMNT to
capture in subtype 9. At present, you must EDIT the name
table in the ASMTAPEE and re-assemble, but ASMTAPEE will
be revised so you can use the console MODIFY command to
turn on or turn off capture of any SYSLOG message.
I plan to create an ANALSYSL program to decode those
SYSLOG messages that you decide to capture, so let me
know what messages you find important and useful.
Change 23.299 Support for SPLIT RMF 70 records, created on a z9 with
VMAC7072 25 LPARS. To be investigated. Check text of this change
Nov 28, 2005 in the final MXG 23.09 that will be dated Nov 30, 2005.
No change made yet, await test data with split records.
Change 23.298 MXG 23.08 would fail if you did not have a //INSTREAM DD
VGETENG in your JCL Procedure (there is one in MXGSASVn example),
Nov 28, 2005 because VGETENG was changed to require the use of that DD
in the "mainstream" RMFINTRV processing, or would fail if
you used UTILBLDP and then %INCLUDE INSTREAM; to execute
the program built by UTILBLDP, with FILE INSTREAM IN USE
error. Both errors were introduced when revisions added
the use of //INSTREAM in VGETENG; both are corrected by
backing out the use of //INSTREAM in VGETENG.
That addition was yet another attempt to improve the
accuracy of VGETENG's logic to "GET" the ENGINE of a
LIBREF. Originally, this was to avoid a second tape
mount, but knowing the library is on tape when we are
going to read with a VIEW, we can avoid a second read
of the full (possibly multi-volume) tape dataset.
However, is just not possible to know the media of an
un-referenced DD, so we must revert to the original
logic that can only identify a tape that has been
previously referenced in this step.
So you could force that reference with a LIBNAME
statement, or a DATA _NULL_; SET DD.XX; STOP;
if you see there are multiple mounts on syslog.
In the case of VMXGSUM, which does not use the
VGETENG logic, we are still investigating if we
can detect and eliminate the second read with a
VIEW when the input is on tape.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.297 Support for TCP field ACCEPT in dataset AIXTCP.
VMACAIX
Nov 23, 2005
Thanks to Long N. Nguyen, Department of Home Security, USA.
Change 23.296 Macro _STY30U6 deaccumulates TYPE30_6 into PDB.TYPE30_6,
VMAC30 but it did not protect for wrapping of the four-byte
Nov 22, 2005 RESIDTM and ACTIVETM fields, which wrap at 1221 hours.
Additionally, ACTIVETM was not deaccumulated, but now is.
The created variable UPTM contains the original ACTIVETM
before deaccumulation, but UPTM will reset to zero every
51 days or so.
-Noted and corrected: INTETIME and SYNCTIME in TYPE30_6
were on GMT rather than local time if GMTOFF30 non-zero.
Thanks to Jean-Denis Lacourse, CGI, CANADA.
Thanks to Robert Petel, CGI, CANADA.
Change 23.295 Dataset DB2ACCTG didn't contain these nine QBGA variables
VMACDB2 QGBADG QBGAP1 QBGAP2 QBGAP3 QBGAS1 QBGAS2
Nov 22, 2005 QBGAS3 QBGAU1 QBGAWS
although their sums were kept in DB2ACCT. All variables
are now kept in DB2ACCTG.
Thanks to Steve Olmstead, Thomson BETA Systems, USA.
Change 23.294 TMVSCI dataset variable CIJN was off by four bytes, which
VMACTMVS caused wrong values in it and the subsequent CI variables
Nov 22, 2005 that track storage. In addition, the percentage field's
Nov 5, 2005 values were all off by a factor of 100, as I missed the
precision of that field in the TMVS documentation.
Thanks to Richard Jay Schwartz, State Street Bank, USA.
Change 23.293 The MXG Trending default INTERVAL=WEEK, is replaced with
TRND72GO INTERVAL=&INTTRND, with macro variable INTTRND defaulting
VMXGINIT to WEEK, i.e., the INTERVAL= value is externalized so it
Nov 22, 2005 can be changed with %LET INTTRND= whatever ; before your
%INCLUDE SOURCLIB(TRNDxxxx); statement (where "whatever"
is one of the valid values defined in VMXGDUR).
Only the TRNDxxxx members that had INTERVAL=WEEK, were
changed; a few don't use the INTERVAL= argument (instead
using a date/time variable in their SUMBY= argument) and
a few had INTERVAL=DATE, left unchanged. TRNDCICS/CICX
have INTERVAL=&TRCIINTV, but the %LET TRCIINTV=WEEK; is
inside those two members, so it couldn't be externally
changed. Now, INTERVAL=&INTTRND, is specified and the
useless reference to TRCIINTV is removed.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 23.292 Support for APAR OA11675, which increases EXCPTOTL's old
VMAC30 maximum count of 2 gig to a new maximum of 4 gig. The
VMAC32 field counts the step's lifetime total EXCPs (blocks or
VMAC33 SSCHs, depending on the Access Method used); the original
Nov 14, 2005 APAR text and title erroneously said "2 gigabytes". If
the count is now over 4 gig, (4,294,967,295), the APAR
stores 'FFFFFFFF'x and turns on a new bit to indicate the
count exceeded the maximum. MXG creates EXCPERR='Y' if
that bit is on, and sets EXCPTOTL to a missing value.
The variable name is EXCPTOTL in SMF 30s and PDB datasets
and in SMF 33s, but was named EXCPS in TYPE32.
Change 23.291 Support for NDM subtypes:
EXNDMHW Subtype Description
EXNDMNM HW HIGH WATER MARK STAT RECORD - supported
IMACNDM NM Unknown - Header only until I get the DSECT
VMACNDM
VMXGINIT
Nov 13, 2005
Thanks to David Kaplan, Depository Trust, USA.
Change 23.290 Deaccumulation of the VXSYTEPM dataset was still wrong;
VMACVMXA four byte wrap was not protected, but IBM has created a
Nov 12, 2005 new "architecture" that needed additional logic. For each
device's first instance, CALINIT='Y' and the contents of
that "initial" record is all zeros, so it is deleted.
However, the second record must also be deleted, as it
does not start from zero, but has some large non-zero
values that must be used in the DIF() but the observation
after the CALINIT='Y' instance must then be deleted also.
And since records with CALINIT='Y' are deleted, there is
no reason to keep that variable in VXSYTEMP dataset.
Thanks to Melanie Higching, British Telecom, ENGLAND.
Change 23.289 For RMF intervals with DURATM less than one minute, MXG's
VMXG70PR summarization into PDB.ASUM70PR didn't store the second
Nov 10, 2005 interval's DURATM in SYSDUR, which caused values over 100
percent in PCTCPUBY and the LPCTnBY value for that LPAR.
Change 23.070 documented these very short RMF intervals
(created when a WLM Policy Change was made), and dataset
PDB.ASUMCEC was corrected by that change, but 23.205 was
and additional revision, and it reinstated EXCECTIM exit
to force the STARTIME for all three datasets created by
the ASUM70PR/VMXG70PR program to the nearest minute, both
for cross-CEC timing issues, and to consolidate these RMF
short intervals. But the logic for PDB.ASUM70PR/ASUM70LP
to set SYSDUR was based on IF FIRST.LPARNUM, but that
didn't "see" the second instance with same STARTIME.
By adding DURATM as the last BY variable in the BY in
INCODE=, and by setting SYSDUR from IF FIRST.DURATM, the
summary DURATM is correct for those two datasets, which
also corrects the percentages based on DURATM.
-The WLM Policy Change was installed at 10:32:06, and the
STARTIME and DURATM of the adjacent RMF records were:
STARTIME DURATM
hh:mm:ss hh:mm:ss
10:15:00 00:15:00
10:30:00 00:00:20
10:30:20 00:01:46
10:32:07 00:12:52
Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.
Change 23.288 BMC CMF Product SMF 70 records for z9 have SMF70BND=0,
VMAC7072 MXG variable LPARCPUX, in the LPARNAME='PHYSICAL' segment
Nov 10, 2005 which processor counts, especially for NRIFACPU, NRIFLCPU
Jun 6, 2006 and NRICFCPU will always be zero; investigation with BMC
is in progress.
Jun 8, 2006 update: The error was only in the first level
of CMF support for the z9, and was corrected by CMF APAR
BAM9572, PTF BPM9543.
Change 23.287 Usability enhancement for selective output of DB2 data.
READDB2 You can choose which datasets are to be created, which
Nov 10, 2005 observations are to be output, and even which variables
Nov 16, 2005 will be kept in any of the created datasets:
Nov 22, 2005
SELECTION CRITERIA:
SMFBEGIN= DATE/TIME CONSTANT FOR BEGINNING OF TIME RANGE
SMFEND = DATE/TIME CONSTANT FOR END OF TIME RANGE
SYSTEM = SYSTEM(S) FOR WHICH DATA SHOULD BE SELECTED
PLAN = PLAN(S) FOR WHICH DATA SHOULD BE SELECTED
AUTHID = AUTHID(S) FOR WHICH DATA SHOULD BE SELECTED
CORRID = CORRELATION ID(S) WHICH SHOULD BE SELECTED
CONNID = CONNECTION ID(S) WHICH SHOULD BE SELECTED
DB2 = DB2 SUBSYSTEM(S) WHICH SHOULD BE SELECTED
CONNTYPE= CONNECTION TYPE(S) WHICH SHOULD BE SELECTED
PACKAGE = PACKAGE NAME (FOR DB2ACCTP DATASET ONLY)
DATASET CRITERIA:
DB2ACCT= Any of the below syntax
DB2ACTB= "
DB2ACTP= "
=YES - DATASET IS CREATED WITH ALL OBS/VARS
=NO - DATASET IS CREATED WITH 0 OBS
=KEEP/VAR1 VAR2 VAR3.. - DATASET IS CREATED AND
KEEPS ONLY THE LISTED VARIABLES
=DROP/VAR1 VAR2 VAR3... - DATASET IS CREATED AND
DROPS ALL THE LISTED VARIABLES
Thanks to John W. McAlinney, Vanguard, USA.
Change 23.286 Change 23.153 revised the value of SMF "subtype" for DB2
VMXGGETM 102 trace records to contain the "IFCID" because that is
Nov 9, 2005 the "logical" subtype for the 102s that don't have an SMF
subtype in the SMF header. That change also stores IFCID
for subtype in the 100 and 101 records, even though they
do have SMF subtypes, because DB2 documentation refers to
IFCIDs and not to SMF subtypes. These are the values
that were changed, but not documented.
IFCID: 1 2 202 3 239
Rec.Sty: 100.0 100.1 100.2 101.0 101.1
This change only added documentation notes in the member.
Thanks to Daniel T. Cannon, The Hartford, USA.
Change 23.285 VM Accounting datetimes were incorrect; Change 23.109 had
TYPEVM used the record LENGTH to identify the date format, but
Nov 9, 2005 that test was not sufficient, and I can find no other way
Nov 11, 2005 to discriminate safely between MMDDYY or YYMMDD than to
Nov 15, 2005 have you tell me in a new MACRO _DATEVM with values:
_DATEVM Date Format
1 MMDDYY (Default)
2 YYMMDD
The default format is the IBM MMDDYY format; you can use
this syntax to change the macro value if needed:
//SYSIN DD *
%LET MACKEEP= MACRO _DATEVM 1 % :
%INCLUDE SOURCLIB(TYPEVM);
Nov 15: LENGTH=LENGTH restored to the INFILE statement.
Even though it can't be used for date-discrimination, it
is needed to identify some VM data records.
Thanks to Wah Chu, SIAC, USA.
Change 23.284 PDB.PRINT,TYPE6 variables TOTLINES,NRLINES is 4294967295,
VMAC6 sometimes, in tcp/ip "Printway" file transfer records,
Nov 7, 2005 which are SMF 6 records written by PSF for "print" output
that was sent via tpc/ip to an ip address. That decimal
value results when SMF6NLR contains 'FFFFFFFF'x is the
SMF record.
-These TYPE6/PDB.PRINT tcp/ip records have SUBSYS='TCP',
and only variable SMF6BYTES can be used for print bills
or printer resource measurements.
-They do not have the PSF-APA segment, so SHEETPRN and the
other fields from that segment are all missing.
-Why NRLINES is someimes bad and sometimes has reasonable
values is unknown (query pending to IBM), but NRLINES has
never been recommended (see the PRINTERS section in the
MVS/ESA RESOURCE ACCOUNTING" article in NEWSLTRS.
-But because that large value is confusing and could mess
up your old print billing system with it, I have chosen
to test for the 'FFFFFFFF'x field value, and now set the
variable NRLINES to a missing value for those instances.
-PDB.PRINT variable TOTLINES is the equivalent of NRLINES.
Do not use the old PRINTLNE/PUNCHCRD/EXTWTRLN variables,
because there is no safe way to identify which kind of
device was at the destination, and they are archaic in
any case. TOTLINES is their sum, and the field to use,
if you still must have some count of "linew".
-Note that in non-TCP records for PSF, NRLINES can also be
wierd when the SMF6PRMD printer mode is "DATA" and not
"LINE", but at least those records have valid SHEETPRN
in their PSF-APA segments.
-Note for back-level-MXG users: SUBSYS='TCP' was added in
MXG 22.08 (Change 22.153), but SMF6BYTE has been input
since Change 13.328, and it will be non-missing only in
tcp/ip print records, so it could be used alternatively
to identify these records.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Philip Matthei, State of New York, USA.
Change 23.283 Support for ASG-Landmark TMVS Version 3.2 has confirmed
VMACTMVS that any changes made were COMPATIBLE, but I won't take
Nov 3, 2005 time to compare all of the DSECTS to look for new data
until a user finds a need for it. The last change in
MXG was prior to MXG Version 20.20.
See Change 23.294 for internal record changes in 3.2.
Thanks to Richard Evans, Worldspan, USA.
Change 23.282 MXG 23.08-MXG 23.02. Change 23.068 used a rare GOTO that
VMAC26J3 should have been a LINK statement. The GOTO caused the
Nov 3, 2005 RETURN statement after the label to be a DELETE statement
so the rest of the record was never read nor was the exit
for the OUTPUT every called for that record.
This behavior of the RETURN statement only occurs when
there are OUTPUT statements in the SAS data step.
If there are no OUTPUT statements, a RETURN after GOTO
causes all datasets in the DATA statement to be OUTPUT.
With the LINK statement, the label is called, but RETURN
brings the program back to the statement after the LINK,
so the rest of the record is read and OUTPUT.
Thanks to Dave Falzon, EDS Ottawa, CANADA.
Change 23.281 MXG 23.08. ERROR: File WORK.TYPE791.DATA does not exist
TESTIBM1 when JCLTESTx is run. TYPE79 now sorts the TYPE79xx data
Nov 2, 2005 (to deaccumulate) to the PDB library, but the TESTIBM1
program's PROC MEANS still expected those data in WORK.
TESTIBM1 was changed to find TYPE79xx in the default PDB.
Thanks to Bernd Klawa, Stadwerke Bielefeld GmbH, GERMANY.
Change 23.280 DB2 Package Data could STILL be wrong, if any of these
VMACDB2 fields are longer than the original un-truncated length:
Nov 1, 2005 variable label was now
Nov 2, 2005 QLACLOCN='LOCATION*NAME' $16 $16
Dec 13, 2005 QPACLOCN='LOCATION*NAME' $16 $16
QPACCOLN='PACKAGE*COLLECTION ID' $18 $18
QPACPKID='PROGRAM*NAME' $18 $18
QPACASCH='NESTED*ACTIVITY*SCHEMA*NAME' $8 $17
QPACAANM='NAME*OF*ACTIVITY' $18 $18
In the observed case, QPACASCH was increased to 16 bytes
and contained 'SYSPROC.S1BNLERP' as one example value.
For now, I've increased the default length of QPACLOCN
to $17, pending an understanding of whether the increase
was made by the installation or by IBM. The revised code
inputs them all with $VARYING128, which is the maximum
documented length With MXG's COMPRESS=YES default, they
could be changed to default $128 length, but that could
dramatically increase the size of the DB2ACCTP dataset
if you have turned off COMPRESS=YES, so I chose to leave
the other above fields in their original stored lengths.
The original text contained this next statemnt:
Insert Mar 27, 2013: THIS 2006 statement is false in sas version 9:
"You can change the stored length by the addition of:
LENGTH QPACxxxx $nn ;
in the EXDB2ACP exit; SAS uses the last LENGTH statement
to set the variables stored length."
SAS uses the FIRST instance of the character variable to
set its length, and prints a WARNING that first length if
a LENGTH statement with a different length os found.
SEE NEWSLETTER SIXTY - SECTION 7.1. CHANGING VARIABLE LENGTH.
end of Mar 27, 2013 Insert.
-Dec 13, 2005: HOORAY, package date WAS FIXED in November;
this is only additional documentation about package data:
In DB2 V8 data, in dataset DB2ACCTP, QWACBSC and QWACESC
variables (begin/end datetimes), are now always missing,
because V8 creates only SMF 101 Subtype 1 IFCID=239 data.
In V7 and earlier, IFCID=0003, Subtype=0 records (first
ten packages) did populate those variables, but IFCID=239
records always had BSC/ESC missing for the 11th-plus
package.
Thanks to Tory Lepak, Aetna, USA.
Change 23.279 Support for VTCS 6.0 and 6.1 SMF records (COMPATIBLE).
FORMATS These new variables are created, but only CTP appears to
VMACSTC be new in 6.1 records, all other variables below do have
Nov 1, 2005 real values in 6.0 SMF records:
Dataset STCVSM13:
STC13CTP='CARTRIDGE*TYPE'
decoded by $MGSTCCT format:
'0000'X='0000X:S-CART 400MB'
'0001'X='0001X:E-CART 800MB'
STC13HST='ORIGINATING*HOST*NAME'
STC15MNR='MOUNTED*WITHOUT*A RECALL?'
STC15MRC='MOUNTED*AFTER*A RECALL?'
Dataset STCVSM14:
STC14CTP='CARTRIDGE*TYPE'
decoded by $MGSTCCT format:
STC14HST='ORIGINATING*HOST*NAME'
STC14ULN='MVCS*TO*UNLINK'
In the 6.0 data tested, STC14DSN was always blank; STK is
investigating why.
-Variables 13FLG,14FLG,13HID,14HID,13SEQ,14SEQ,13VTI,14VTI
and STC13OID are archaic and always missing; those fields
only existed prior to version 5.0.
Thanks to Ruth Whitney-Parker, CitiGroup, USA.
Thanks to Nathan Loewenthal, CitiGroup, USA.
Change 23.278 This change was implemented in Change 23.300 and its text
was relocated into that change.
Change 23.277 Two new job status variables are created from new bits in
VMAC26J2 SMF26IX2 (old PRPRTY variable):
Oct 31, 2005 UNSPUNJB='JOB WENT*THRU*UNSPUN*IN ITS*LIFETIME?'
JOEPURGE='JOE*PURGED*DUE TO*PSO/SAPI?'
Thanks to Leendert Keesmaat, UBS AG, SWITZERLAND.
Change 23.276 -PDB.ASUMCEC variables LP0MGTTM, LPCT0OV and PCTL0OV were
VMXG70PR always zero after Change 23.021, due to incorrect logic.
Oct 31, 2005 This error was only in PDB.ASUMCEC; those variables were
correct in PDB.ASUM70PR.
-Also, ASUMCEC variables IFAUPTM, IFAACTTM, and IFAWSTTM
were not formatted with TIME12.2 format.
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 23.275 Support for CA TopSecret SMF 80 records with SMF80DTP of
EXTY80TS 103,104,105,109,255 values. This is preliminary support,
IMAC80A as the DSECT does not exactly match the SMF record, so
VMAC80A further validation is required. Dataset TYPE80TS is
VMXGINIT created from all of those DTP values.
Oct 28, 2005
Thanks to Chris Hober, Charles Schwab, USA.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 23.274 The MACRO definition for MACRO _N120 was missing the text
VMAC120 MACRO for each of the _NULL_ entries; attempting to use
Oct 27, 2005 the _N120 macro to null out all datasets failed.
Thanks to Xiaobo Zhang, ISO, USA.
====== Changes thru 23.273 were in MXG 23.08 dated Oct 27, 2005=========
Change 23.273 NOT SORTED error in building PDB.ASUMCEC (error was right
VMXG70PR after the - IFA2 FOR CEC note on the log) can occur with
Oct 27, 2005 some data values. The reset of STARTIME to the nearest
minute (in EXCECTIM) caused the out of order condition,
which is now corrected by a PROC SORT.
Thanks to Joe Montana, Acxiom, USA.
Change 23.272 -First MXG 23.08 only. ARRAY SUBSCRIPT OUT OF RANGE error
VMAC7072 due to MXG logic introduced in Change 23.237 to count IFA
Oct 27, 2005 and IFL engines using the (new-in-z9) SMF70CIN values in
new NRIFACPU and NRIFLCPU variables (which are non-zero
ONLY if you have a z9 processor that puts IFA and IFL in
the SMF70CIN field). The new logic was fine, but the new
LCPUADDR values that are greater than the number of real
engines in the LPARNAME='PHYSICAL' caused the failure.
The solution was to relocate the LPARNAME='PHYSICAL' test
that sets MXGCIN='PHY' above the test for LCPUADDR.
-New MACHTIME was in the year 2041; the SMF documentation
had SMF70HWM after SMF70LAC, but the new SMF70HOF field
was inserted between LAC and HWM in z/OS 1.7.
Thanks to Joe Montana, Acxiom, USA.
====== Changes thru 23.271 were in MXG 23.08 dated Oct 25, 2005=========
Change 23.271 An unknown NAF record segment caused the record to be
VMACNAF DELETEd, so subsequent segments were not OUTPUT. The
Oct 22, 2005 DELETE was removed and the number of messages limited,
and a hex dump of the first five unknown records is now
printed on the SAS log.
When documentation for the 'C0' segment is found, the
segment causing the problem will be supported.
Thanks to Joe Babcock, JPMC, USA.
Change 23.270 Due to popular demand, though I really fail to see the
VMAC7072 need, I've put back the individual IFA engine percentage
Oct 21, 2005 busy variables, PCTIFBY0-PCTIFBY9,PCTIFBYA-PCTIFBYX in
Oct 25, 2005 the KEEP= list for dataset TYPE70.
Oct 25: And now, they have non-missing values; those
variables were added in 22.09 and then removed, but even
in 22.09 their values were always missing.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Thanks tO Lawrence Jermyn, Fidelity Systems, USA
Change 23.269 z/VM MONWRITE dataset VXSYTEPM, Extended Channel Metrics,
VMACVMXA had not been data-tested for accumulated data values.
Oct 21, 2005 Now, ESCON variables ECMCPBTC and ECMCPBTL and FICON
variables ECMCBC ECMCCWUC and ECMCCWUL are DIF()'ed.
ESCON and FICON observations have different variables
populated; variable CSCCMCMG identifies FICON/ESCON.
The default _TESTMW macro invokes the _SSYTEMP macro that
does the actual deaccumulation.
-Bit CALINIT was on in one observation, uncovering a data
record that must be used to initialize the DIF() function
but then must be delete.
Thanks to Melanie Hitchings, BT, ENGLAND.
Thanks to Brian Crow, BT, ENGLAND.
Change 23.268 RMF 79 subtype 9 records had never been validated; some
TYPE79 fields are accumulated and some are not, and IBM doesn't
VMAC79 choose to document which is which, so real data is needed
Oct 20, 2005 to know that these variables had to be deaccumulated:
R799PCT R799ALC R799ATV R799CMR R799CNN R799CUB
R799DIS R799DPB R799DVB R799MEC R799PEN R799SCC
R799QUE R799UTL
in the _STY799 "Dataset Sort Macro, which is invoked by
the _S79 "Product Sort Macro".
-The TYPS79 member did invokes the _S79 macro, but that
is now also added to the TYPE79 member so you don't
accidentally create only the accumulated datasets.
-Variables R799DPB and R799PCT have clearly invalid values
but IBM documents them as "not used".
Thanks to Jerry Ellis, Liberty Mutual, USA.
Change 23.267 Optional CICS OPID field with CMODHEAD='OPID' creates new
IMACICO1 OPID variable in CICSTRAN dataset, but only if UTILEXCL
UTILEXCL was used to create an IMACEXCL, and only if a dictionary
VMAC110 record had that CMODHEAD entry, and only if the comment
Oct 20, 2005 block in member IMACICO1.
Thanks to Lucy Fukishima, California Health and Welfare, USA.
Change 23.266 Documentation. DFSORT SMF Release 16 SMF 16 records are
VMAC16 already supported; there have been no changes to the IBM
Oct 20, 2005 SMF 16 SMF record since Release 14.
Change 23.265 -MXG 23.05-MXG 23.07, the RMFINTRV workload variables with
VMXGINIT IFA and IFE CPU times were always zero; Change 23.123 did
VMXGRMFI not correctly create those workload variables.
Oct 20, 2005 -Logic was added to VMXGRMFI in Change 23.215 to determine
Nov 3, 2005 if a VIEW could be used, but macro variable name VGETENG
was not GLOBALed in VMXGINIT, which caused SAS error that
MACRO VARIABLE UNRESOLVED errors!
Nov 3: Text updated. Adding VGETENG also required there
be a //INSTREAM DD, which has been in MXGSAS JCL
for years, but I never told ITRM this change made
it now required that their JCL also have this
DDNAME.
Nov 28: See Change 23.298 which eliminated the use of the
//INSTREAM in VGETENG to avoid this exposure.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
Change 23.264 The subtype 31 SARR records had a coding error; the code:
VMACSARR IF SV31IOF+SV31ILN-1 LE LENGTH AND SV30ILN GE 1 THEN DO;
Oct 19, 2005 should have been:
IF SV31IOF+SV31ILN-1 LE LENGTH AND SV31ILN GE 1 THEN DO;
Thanks to Wim Desmecht, NV INFOCO, BELGIUM.
Change 23.263 The length of MXG-created variable CPCFNAME, which is the
VMXG70PR concatenation of CPUTYPE and CPCMODEL, was increased from
Oct 12, 2005 $8 to $10 because an Amdahl GS2108E system has 2000-2108E
for CPCFNAME, which wouldn't fit in 8 bytes.
Thanks to Steve Rowe, DST Systems, Inc, USA.
Change 23.262 Documentation note only. If you get these error messages
BUILDPDB VARIABLE LOCLINFO HAS BEEN DEFINED AS BOTH CHAR AND NUM
Oct 12, 2005 DATASET WORK.TYPE30_4 MAY BE INCOMPLETE
The error is due to a corrupted SPIN library (due to a
prior failure when testing a %UTILBLDP or BUILDPDB run
that didn't complete successfully).
- If this is still in testing, and there WAS nothing of
value in the SPIN library, then you only need to use
PROC DELETE DATA=SPIN._ALL_; and can then re-test.
- If this should happen after BUILDPDB/UTILBLDP is in
production and you had data in the SPIN data library
(VERY RARE, because you had to have done something to
MXG to cause this failure and then tried to run the
production BUILDPDB job), then you must restore the
//SPIN data library to the way it was prior to what
you did that caused the failure, from the last PDB
data library from the last succesful BUILDPDB. This
is easy, because BUILDPDB backs up your SPIN library
datasets into each PDB data library, so you would use:
//YESTER DD DSN=YOUR.LAST.PDB,DISP=SHR
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
PROC COPY IN=YESTER OUT=SPIN;
SELECT SPIN: ;
(the 'colon' is the wildcard in the SELECT statement).
Change 23.261 Invalid Extended Segment section in SMF 14 record caused
VMAC1415 INPUT STATEMENT EXCEEDED RECORD LENGTH error; MXG logic
Oct 11, 2005 tried to read the rest of the record after detecting this
bad segment, but the rest of this record was also trash,
so now, the error messages are printed:
***ERROR.TYPE1415.EXTENDED INFO SEGMENT DEFECTIVE
TYPE1415 OBSERVATION WAS NOT OUTPUT.'
and the rest of the INPUT is now skipped.
Thanks to Sidney Owens, District of Columbia Government, USA.
Change 23.260 Linux under z/VM dataset VXAPLSLM variable PGFAUMI label
VMACVMXA said "PAGE*FAULTS*MINOR*ONLY" but the field contained the
Oct 6, 2005 MAJOR*ONLY faults. This change creates PGFAUMJ with the
Oct 13, 2005 MAJOR*ONLY faults, and corrects the value in PGFAUMI so
it is the MINOR*ONLY to match it's label.
Oct 13: Original divide changed to multiply.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 23.259 The SMF _ID macro for some early SMF records didn't start
VMACWYLB with _ID; this change adds the "standard" ID maro name of
Oct 4, 2005 MACRO _IDxxxx nnn % to replace those archaic spellings,
but the original macro can still be used, since the code
IF ID=_oldname OR _ID= _IDxxxx THEN DO;
is used in these members:
Oldname Standard
_WYLBUR _IDWYLB
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 23.258 Support for SYSVIEW for IMS user SMF records.
EXSYSIDL dddddd Dataset Description
EXSYSIEV SYSITR SYSITRAN SYSITR: SYSV/IMS TRANSACTION
EXSYSIPG SYSIPG SYSIPGM SYSIPG: SYSV/IMS PGM
EXSYSISC SYSIDL SYSIDLI SYSIDL: SYSV/IMS DLI
EXSYSITI SYSISC SYSISCH SYSISC: SYSV/IMS SCHEDULE
EXSYSITR SYSITI SYSITIM SYSITI: SYSV/IMS TIMERS
FORMATS SYSIEV SYSIEVT SYSIEV: SYSV/IMS EVENT
IMACSYSI This code is still in early testing, but because all of
TYPESYSI the test file has only the TRN, CNT and CLK segments, and
TYPESYSI exactly one each, and multiple segments doesn't make any
TYPSSYSI sense for the transaction, I now combine those three into
VMACSYSI a single obs in the SYSITRAN dataset. Because none of
VMXGINIT other segments are populated, the code, for now creates a
Oct 5, 2005 separate dataset for each segment, which may or may not
be the final design.
-Also, there is undocumented data in the records. While
the triplet count is 3 and the first three triplets are
populated for the TRN, CNT, and CLK segments, the eighth
triplet, "WRK" is also populated, pointing to a segment
with at least 8 populated TODSTAMP fields, but the WRK
segment is not described in the DSECT.
Thanks to John Rivera, (i)Structure, USA.
Thanks to Ken Steiner, (i)Structure, USA.
Thanks to David Zelmer, (i)Structure, USA.
Change 23.257 All variables created from TEMP were LENGTH $200, even
VMACTPMX though the actual INPUT was INPUT TEMP $VARYING16. And,
Oct 4, 2005 variables JBBND and JLIMT should have had $VARYING17. as
they can contain two levels and a period. So, lacking a
clear knowledge of exact maximum lengths, I folded all of
the $VARYINGnn (nn=6,14,16,64,80), into (nn=17,80) using
only TEMP17 and TEMP80 variables to set the kept lengths.
Note that as long as the MXG default option COMPRESS=YES
is still in effect, essentiall no space was wasted even
when the length was $200.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 23.256 Updated revision; warning messages RMFV022W and RMFV023W
ASMRMFV could be incorrectly issued, ASI data would be missing
Oct 4, 2005 and ASMRMFV would set Return Code 4.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 23.255 The text for several TNG metrics in $MGTNGVN format were
FORMATS truncated in their VALUE statement, printing MXG messages
Oct 3, 2005 about UNKNOWN fields. Fields 31,34,36,37,46,and 113 for
the NT data for the SMPT Server Object were corrected.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 23.254 The ADOCMWSU member for HP MeasureWare for Sun has been
ADOCMWSU updated with the REPORT command syntax that creates the
VMACMWSU data fiels with the fields that TYPEMWSU expects.
Oct 3, 2005 -VMACMWSU's test for TYPE was expanded to test 'TRAN' so
Oct 5, 2005 those records will now be output.
Thanks to Albert Jacobs, KBC Bankverzekieringsholding, BELGIUM.
Change 23.253 Initial rewrite of the ASUMTAPE program that combines
ASUMTAPE MXG's Tape Mount TYPETMNT data with IBM's Tape Dismount
VMACTMNT TYPE21 SMF data to create PDB.ASUMTAPE dataset, with the
VMAC21 start and end times of the mount, the dismounted time,
Sep 30, 2005 and bytes read, written, and any tape error counts.
Oct 19, 2005 Because the "Exit-Driven" architecture of ASMTAPEE ML34+
captures all mounts and populates all JOB-related data,
only the PDB.TYPETMNT and PDB.TAPES (a/k/a TYPE21) are
needed to create PDB.ASUMTAPE. (PDB.TYPETALO was used
to populate missing fields when mounts were sampled.)
-The SPIN.SPINMOUN and SPIN.SPIN21 will hold incomplete
mount/dismount records, to be reintroduced tomorrow.
-These variables, from the allocation event, are no longer
created in PDB.ASUMTAPE:
ALEERROR ALOCEND ALOCSTRT ALOCVLTM RDRTM SMFUCB
SMFVOL01 TERMNAME TMNT008I XMEMABND
-These job-related variables were only in the Allocate
record; they are now created in PDB.TYPETMNT and will be
created in PDB.ASUMUOW, but they will be blank until the
ASMTAPEE monitor program adds them to the mount record:
PROGRAM RESGROUP RPTCLASS SRVCLASS WLMNAME
-VMAC21 now sets BLKSIZE=. if SMF21LB is not on.
-"Group" definition macros, _GRPMNNM and _GRPMNCD, are now
added in ASUMTAPE to group SYSTEMs that have overlapping
DEVNRs. Using the example in the comments to create a
_GRPMNNM variable, ASUMTAPE groups BY _GRPMNNM DEVNR so
each "location/group" is analyzed correctly.
-A macro _DEBUG is defined in ASUMTAPE, and when invoked
it will print a log of the sequence of mount, dismount
and allocation records for diagnostics if there is a
problem case observed; if you can also send the JOBLOG of
the job(s) involved, it will help our investigations.
-This revision is in early testing; it appears to work
perfectly when there is a match of mount/dismount, and
it recognized back-to-back dismounts (i.e., missed mount)
in variable STATUS, but it needs extensive validation and
comparisons to the SYSLOG of weird cases before I can
fully say it's ready for prime time.
-In testing this revision, I discovered that ASMTAPEE at
ML-34 thru ML-36 do NOT capture all tape mounts in their
exit logic: these are two known cases of missed mounts:
- Multi Volume Mounts - Only first Mount is captured in
the IBM Volume Mount Exit; STK's HSC exit sees all.
- DFHSM Mounts to 3590s - None captured, but mounts for
other jobs on 3590s are captured.
An investigation by "asmguy" has just been started today
as a result of this (unwanted!) discovery, which will
likely require SLIP traps, dumps, and possibly multiple
iterations to find out why these mounts were not seen.
-Oct 19: Macros _grpALxx are renamed to _grpMNxx to be
consistent; AL is for allocation and MN is for mounts,
and ASUMTAPE should be used instead of TYPETMNT for tape
mounts.
-See further revisions in Change 23.300 and later.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Beau Chavis, Bank of America, USA.
Thanks to Jim Sherman, Lockheed-Martin, USA.
Change 23.252 TMS/CA-1 DEVTYPE variable was blank for TRTCH='E2'X, but
VMACTMS5 now DEVTYPE='STK9840-C' is decoded for that TRTCH value.
Sep 29, 2005 DEVTYPE='STK9842' already was decoded for TRTCH='E7'X.
Thanks to John Gebert, FDIC, USA.
Change 23.251 Enhancement to set TRANNAME in PDB.ASUMUOW from CICSTRAN
VMXGUOW observation in each Unit of Work that was not the CSMI
Sep 29, 2005 transaction but that had the longest IRESPTM duration, as
a more robust identification of the "real" transaction.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.250 OPTIONS NODSNFERR NOVNFERR; was missing from the TRNDCACH
TRNDCACH member; it is needed to protect the first-time-through,
Sep 28, 2005 when the TREND.TRNDCACH member doesn't yet exist.
All other TRND members had that option, so I assume it
was inadvertently deleted.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 23.249 Using %READDB2 to process DB2 Trace 102 SMF record now
ANALDB2R decodes the DBID and OBID values, if you enabled 105/107
READDB2 IFCIDs, and those records are in the input SMF data file.
VFMT102 (Previously, only the %ANALDB2R report printed the real
Oct 22, 2005 names of the OBID or DBID). Formats $MGDB2DB/$MGDB2OB
are created by VFMT102 member, used by both ANALDB2R and
VMAC102, if 105 or 107 records were found, but only cover
the time frame of the trace, since DBID and OBID can
change. The 105/107 records are only written at OPEN,
and the formats use the timestamp range of the data read
by READDB2, so you may still find $HEX4. values for the
DBID and OBID variables some of the time.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.248 An ending */ was missing in the exit member, but there
EXDB2ACC were subsequent end comments that apparently prevented an
Sep 22, 2005 error, as this was observed by Bruce, rather than the
result of a reported error condition. Sometimes, a
missing end comment, even when there are subsequent ends
for other comments, has caused strange errors.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.247 ML-36 of ASMTAPEE corrects a problem in the Allocation
ASMTAPEE Monitor introduced in ML-35 that cause a major increase
Sep 22, 2005 in the CPU time of the MXGTMNT task.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 23.246 Support for adding un-sorted datasets to your WEEKly PDB.
WEEKBLD MONTHxxx programs supported adding unsorted datasets by
WEEKBLDT using MACRO _BY % MACRO _SORTBY % in place of
WEEKBLDD the normal MACRO _BYLIST var1 var2 % definition, but the
WEEKBL3 WEEKxxxx programs were not revised to define those two
WEEKBL3D macros, until now. As a reminder, once these two macros
WEEKBL3T have been specified, all subsequent datasets will be
Sep 16, 2005 treated as non-sorted, so the un-sorted dataset build
macros should be at the very bottom of your EXPDBWEK or
EXPDBMON tailoring member.
Thanks to Cheryl Heiner, State of Montana, USA.
Change 23.245 A single quote (') in the WLM data for a variable was not
REXXWLM converted to two single quotes (''), which could cause a
Sep 16,2005 SAS error.
Thanks to Sam Bass, McLane Company, USA.
Change 23.244 NO LONGER TRUE, FIXED BY SAS IN 2005. Original text:
VGETDDS Using MXG's %VGETDDS(DDNAMES=XYZ: ...) and %VMXGSET to
VMXGSET read from all SAS data libraries in your JCL that have
Sep 16, 2005 DDNAMES starting with "XYZn" can fail to read all DDs,
but ONLY if you have installed the IBM PATCH for HSM that
is documented in IBM APAR OY63500, and ONLY if one of the
"XYZn" datasets is independently being migrated by HSM!
That PATCH allows HSM to bypass normal DSENQ protection;
the site runs an HSM job every 30 minutes to migrate data
from ML0 to ML2. The HSM task started the migration, and
then the MXG job started to run (because DSENQ had been
bypassed). VGETDDS tests each XYZn DD with PROC SQL to
find its ENGINE, but SAS did not recognize that XYZ3 was
a SAS Data Library in its DICTIONARY.MEMBERS table (due
to its migration-in-progress status), so VGETDDS saw
UNKNOWN engine, and stopped its search for other XYZn
DDNAMES when the first UNKNOWN engine type is found.
Since VGETDDS only saw XYZ1 and XYZ2, the XYZ3 DDNAME
was never opened by SAS, so the OPEN ABEND discussed in
the IBM APAR text never happened.
If you have the "PATCH" in OY63500, and you permit your
PDBs to be migrated by HSM while trying to use one, there
is no possible MXG fix for this error; the only clues
that there was an error was that many fewer obs were
read than expected, and/or the VGETDDS message on the log
explicitly said it only found two XYZn DDNAMES.
(But the whole point of VGETDDS/VMXGSET is so your JCL
determines how many XYZn DDNAMES are read, and so you
DON'T have to tell me how many to expect!).
The only way to prevent I can think of is to put these
PDB libraries in a dataclass that is not migrated by the
interval task, to eliminate the exposure.
Change 23.243 Enhanncement to RMF III VSAM support ASMRMFV/TYPERMFV.
ADOCRMFV -ASMRMFV corrects a few issues, reduces CPU utilization by
ASMRMFV use of MVCL instruction, and adds the ASI Extension that
CLRMFV had been requested by Lawrence Jermyn, along with other
DOCLRMFV minor changes. The ASI Extension improves the ability to
VMACRMFV subset and group RMF Monitor III data for historical
Sep 15, 2005 analysis at the Address Space level. This version also
Sep 16, 2005 offers additional Assembly Language symbolics to let you
tailor the ASMRMFV defaults.
-CLRMFV: There are no changes to the CLIST; its just here
as a reminder that it is used to process RMFV data.
-ADOCRMFV: Extensive notes on what Jerry did are added!
-DOCLRMFV: Updated notes.
-VMACRMFV:
Variables
ASICNM ASICDE ASICWN ASICRN ASICPO ASICPN
ASICGI ASICWI ASICRC ASIRNM ASIRDE ASIVERG3
were added to ZRBASI dataset. ASIVERG3 values '0F'x and
greater indicate that the zAAP fields are present in the
records.
-Sep 16: Old SVP Buffer Table cleanup added.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 23.242 Support for SMF type 82 subtypes 20 and 21 is added.
EXTY8220 Subtype dddddd Dataset Description
EXTY8221 20 TY8220 TYPE8220 Crypto Coprocessor Timings
FORMATS 21 TY8221 TYPE8221 ICSF Sysplex Group Change
IMAC82 -In TYPE8220, MXG variables NQAPDQAP and DQAPWAIT are the
VMAC82 calculated delta times between TNQ-TDQ and TDQ-TWT, after
VMXGINIT using the TWT-SMFTIME delta to create GMT82OFF. Since it
Sep 12, 2005 is the coprocessor duration, and not time of day, that is
of interest, the original SMF82TNQ, SMF82TDQ and SMF82TWT
variables are not kept.
-SMF82TSF, Coprocessor sub function code is not documented
in the SMF manual; it is a $HEX4. value, and will be
formatted when it's possible values are known.
-SMF82TRN will be missing until you install z/OS 1.7.
-TYPE8221 code has not been tested with records, yet.
Thanks to Ian Arnett, TD Canada Trust, CANADA.
Change 23.241 Two more typos: NR25SEGS in the WHEN (24) group should
VMAC80A have been NR24SEGS, and NR44SEGS in the WHEN(43) group
Sep 12, 2005 should have been NR43SEGS.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Stephen Morris, National Australia Bank, AUSTRALIA
Change 23.240 IRESPTM, the response time of the CICS Unit of Work, and
VMXGUOW ELAPSTM, the total elapsed duration of the DB2 portions
Sep 9, 2005 of the Unit of Work, some which could be in parallel,
are revised. IRESPTM is now the maximum of the CICSTRAN
segments in this unit of work, while ELAPSTM is the sum
of the individual elapsed times of the DB2ACCT segments,
in the PDB.ASUMUOW dataset built by INCLUDE of ASUMUOW.
In addition, new variable DB2IDLE, which was originally
created by archaic ANALDB2C, but lost when ASUMUOW was
built, is now created. DB2IDLE is the elapsed time from
last CICS ENDTIME to the DB2 QWACESC End time, and is the
duration when the DB2 thread was idle, but has not ended,
presumably for possible thread reuse. DB2IDLE is then
subtracted from the sum of the DB2ACCT ELAPSTMs, so the
final ASUMUOW ELAPSTM does NOT include DB2IDLE time.
-This change can make ELAPSTM smaller than before, for
serial transactions that had DB2IDLE time.
-This change can make ELAPSTM larger than before, for DB2
Parallel transactions (DBPARTY='P'), because the prior
ELAPSTM was start to finish. But since parallel=3 can
burn 3 hours of CPU time, the elapsed time must be the
sum of the parallel elapsed time, rather than start to
finish of the unit of work.
-In addition, the _TRANUOW user exit has these additional
variables available for examination, etc.
HOLDIRSP: MAX of IRESPTM from CICSTRAN
HOLDELAP: SUM of ELAPSTM from DB2ACCT
HOLDFSTR: Min of CICS STRTTIME start datetime
HOLDLSTR: Max of CICS STRTTIME start datetime
HOLDFBSC: Min of DB2 QWACBSC begin datetime
HOLDLESC: Max of DB2 QWACESC end datetime
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
Change 23.239 Support for DURATM keywords TENMIN and FIVEMIN. Code had
VMXGDUR been added in VMXGDUR, but not in VMXGSUM. Obscure notes
VMXGSUM in member VMXGSUM did say that if you use DURATM= with an
Sep 9, 2005 unsupported keyword, variable DURATM will not be created.
The actuality is that these DURATM= values:
SECOND MINUTE FIVEMIN TENMIN QTRHOUR HALFHOUR
HOUR THREEHOUR DATE WEEK
do create variable DURATM, while these DURATM= values
MONTH and SHIFT
do not create variable DURATM.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 23.238 Sites that run UTILEXCL daily to create IMACEXCL code
UTILBLDP (due to frequent CICS dictionary changes), normally write
Sep 8, 2005 their IMACEXCL code to a "flat file" rather than a PDS
(avoids need to compress the PDS), adding //IMACEXCL DD
to point to that code, and adding %INCLUDE IMACEXCL;
using MACKEEP= logic. However, the include of an external
DD statement was not supported in UTILBLDP. Now, it is,
with the new IMACEXCL= argument.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.237 -Variables NRIFACPU and NRIFLCPU are added to PDB.ASUM70PR
VMAC7072 and PDB.ASUMCEC datasets built by ASUM70PR for processors
VMXG70PR that populate 'IFA' and 'IFL' in SMF70CIN (only z9 now).
Sep 7, 2005 Variables LPnDSA are now labeled.
-MXGCIN variable now contains new IFA and IFL values.
Change 23.236 Support for Endeavor Release 7; there were no changes to
VMACENDV their user SMF record.
Sep 6, 2005
Thanks to Herb Strozinsky, US Bank, USA.
Change 23.235 DB2TCBTM for Rollup observations (DB2PARTY='R') is wrong
VMACDB2 and could be less than QWACAJST (the TCB time in DB2).
Sep 6, 2005 APAR PQ41012 documented that in rollups the accumulated
Elapsed and TCB were in QWACESC & QWACEJST, but only the
elapsed time was corrected in Change 22.121. Now, the
DB2TCBTM is recalculated when DB2PARTY='R' is set, using:
DB2TCBTM=SUM(QWACEJST,QWACSPCP);
(The final component, QWACTRTE is added in later.)
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.234 Peter Enrico's presentation at SHARE in August 2005 had
GRAFWLM graphs of CPU utilization grouped by SYSSTC, SYSTEM, work
Sep 8, 2005 with a goal, and work without a goal, to show how much
work could or couldn't be managed by WLM. This analysis
produces similar SAS/GRAPH stacked bar charts, showing
CPU Time and MSU consumed by these groupings from top to
bottom:
UNCAPTURED
SYSTEM
SYSSTC
IMP 1 CPU CRITICAL
IMP 1
IMP 2 CPU CRITICAL
IMP 2
IMP 3 CPU CRITICAL
IMP 3
IMP 4 CPU CRITICAL
IMP 4
IMP 5 CPU CRITICAL
IMP 5
SYSOTHER
(All unclassified discretionary work - should have
no unclassified work!)
DISCRETIONARY
(All work classified as discretionary, regardless
of importance. Discretionary work is work in a
service class period that does not have a goal.
An example of the output can be viewed at
http://www.mxg.com/samples/grafwlm
See comments in the member for usage documentation.
Thanks to Peter Enrico, Enterprise Performance Strategies, Inc.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.233 Several corrections and enhancements to Web Log support:
VMACWWW -ELAPSTM, at least for BEA WebLog was way too small; their
Sep 2, 2005 "time-taken" field contains 'seconds.fraction' value, but
Sep 3, 2005 MXG expected a millisecond integer value. Now, MXG will
detect a period in the time field, and inputs ELAPSTM as
'seconds.fraction' when a period is found; otherwise, the
field is input and divided by 1000 to get seconds.
-Example FILENAME now has LRECL=4096 to match the INPUT
$VARYING4096. If LRECL was not specified, LRECL=255 is
the default, which causes "ONE OR MORE LINES TRUNCATED".
-TRANSLATE(RECORD,' ','09'x); added, because BEA log has
a hard tab, '09'x between fields instead of blanks.
Dealing with '09'x can be nasty, since it is usually
turned into a blank by most editors, and blanked by
SAS when input records are displayed, so you often
don't even know there's an '09'x value, until your
read and display the field in hex, using:
INPUT FIELD $CHAR50.; PUT FIELD= $HEX100.;
-Change 23.026 protected one of the two URIQVALU=SUBSTR();
now both are protected for URIQVALU=0, which happens when
when an = in the URIQUERY string is immediately followed
by an &, causing LTOAND=1 and thus causing URIQVALU=0.
-Vars BYTES CSBYTES LBYTES SCBYTES now LENGTH &MXGBYLN.
Before Change 23.026, CSBYTES and SCBYTES were kept as
length $4096 because MXG used CSBYTES=WORD(....); and
WORD's is $4096, so CSBYTES/SCBYTES wasted space when
SAS compression was not used (COMPRESS=YES is default).
That change made them numeric, saving space, but they
were now 4-byte length due to MXG's DEFAULT=4. However,
byte-containg fields need more resolution, and thus they
are now properly set to LENGTH &MXGBYLN. ;
-BYTES added to KEEP= list for _VWWWIIS and WWWIIS22 was
added to $16 length statement.
Thanks to Andrzej Dabrowski, Computing Services, CSIR, SOUTH AFRICA.
Change 23.232 NDM dataset NDMPS ('PS'/'SW' records) now has variables
VMACNDM PSSDSN='DSNAME' and PSSDSNL='LENGTH OF*DATASET*NAME'
Sep 1, 2005 both input and kept, if this is an 'SW' subtype.
-Missing value messages were eliminated for DATE fields
that are known to have missing values; MXG now tests the
DATA field before constructing the DHMS function inputs.
Thanks to Tom Neurauter, Fidelity Systems, USA.
Change 23.231 Support for DB2 IFCID=225 variables
VMAC102 QW0225FA QW0225GA QW0225VA QW0225SJ
Sep 1, 2005 that report DB2 storage used "Above The Bar".
Thanks to Valerie J. Chisholm, Aetna, Inc, USA.
Change 23.230 "EXIT-DRIVEN" MXGTMNT Tape Mount Monitor is AVAILABLE!!
ASMTAPEE ML-35 should be the FINAL iteration in this major effort
ASMHSCEX that replaces the original sampling tape mount monitor
Sep 1, 2005 (it sampled the tape UCBs every 1/2 second, working just
fine for many years of real tape drives, but sampling
now misses many of your very fast VTS tape mounts)
with this event driven monitor that instead uses exits to
capture EVERY tape mount for real drives, silos, and/or
VTS devices, whether mounted by IBM or STK software.
-What's now available is this enhancement that supports
multiple instances of STK's HSC and/or CSC running in the
same system.
-The Exit Driven architecture has been available for some
time, using the IBM Volume Mount exit for all real tape
devices (whether IBM or STK drives), and for IBM VTS.
It was the enhancement to use the STK User Exit in their
HSC and CSC software, used for STK Silos and STK VTSs,
that was extremely difficult to develop, primarily due to
the complete refusal of STK to provide any technical help
(i.e., STK wouldn't/couldn't tell in which address space
their exit was executed!), so MXG's asmguy@mxg.com had to
figure it all out without assisance from that vendor.
-Both ASMTAPEE and ASMHSCEX were updated by this change.
-The solution for multiple HSC/CSC is in the new ASMHSCEX,
which now create two exits, SLSUX01 for HSC, and SCSUX01
for CSC, so all you're HSC guru will have to do is to
define the appropriate exit to whichever one (or ones)
your site is running for your STK Silos and VTSs.
-What to do when both are run:
There may be a little extra overhead for those sites that
run multiple exits on the same system, but that won't
affect a site that only runs one exit. Exit 01 in HSC or
CSC behave the same; either exit will provide the
information we need. With ML-35, you can run any number
of those exits, but now, we'll create only one record per
tape mount!
Asmguy's advice when both are running is to pick one,
whichever is most likely to be active all the time, and
define the exit to it. If you want to run multiple exits
on the same SYSTEM, ML-35 will allow this, but there is
additional overhead involved. If you chose to do this,
you can just define the exits as you would normally, and
no change is required to ASMTAPEE, as it automatically
will detect that multiple exits are running, and respond
accordingly.
-ML-35 ASMTAPEE is NOT compatible with earlier ASMHSCEX.
You must use the ML-35 ASMHSCEX with the ML-35 ASMTAPEE.
- ML-35 corrected several old ASM coding exposures found by
Dick Zieske, mostly dealing with cleanup of CSA when
MXGTMNT is cancelled, rather than STOPed, or if MXGTMNT
ever ABENDS (which has never happened in production)!
- Sampling is still used for Tape Allocation records.
Thanks to "asmguy@mxg.com" who has figured out how to use the HSC/CSC
exits in spite of complete lack of help from STK.
Thanks to Dick Zieske, AIG, USA.
Thanks to Steve Martin, Fidelity Systems, USA.
Thanks to Paul Naddeo, FiServ, USA.
Thanks to Jeff Holst, FiServ, USA.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Thanks to Shirley Fhng, Hong Kong Shanghai Bank, Hong Kong.
Thanks to Shane Dowling, DEWR, AUSTRALIA.
Thanks to Scott Chapman, American Electric Power,USA.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 23.229 Support for DEVTYPE='3592' tape devices. Observations
VMACTMS5 were output by MXG for those devices, but variable DEN
Aug 31, 2005 was not decoded, causing "DENSITY IS MISSING" non-fatal
log messages; more important: variable DEVTYPE was blank.
DEN and DEVTYPE are populated by table lookup in the MXG
program, after I find out what hex value CA has chosen.
Thanks to Todd Wright, CSC Australia, AUSTRALIA.
Change 23.228 INPUT STATEMENT EXCEEDED RECORD error from IBM ATL record
VMACEREP that had a message shorter than the 96-bytes that MXG had
Aug 31, 2005 hardcoded for the INPUT of ETRMESSG. Code was revised.
Thanks to Steven Clark, DHL, USA.
Change 23.227 The NDMCT dataset contains accumulated NDMCPUTM for multi
TYPENDM step processes; deaccumulation is always done by MXG in
VMACNDM the "_Sdddddd" macro, the "Data Set Sort" macro, so the
Aug 31, 2005 heuristic logic to sequence and deaccumlate adjacent data
was added to the _SNDMCT macro.
-The TYPSNDM macro automatically sorts the output, but if
you have added processing of NDM data to your BUILDPDB,
you should replace your PROC COPY; SELECT NDM:; with the
"Product Sort" macro _SNDM in your EXPDBOUT member to
sort all of the NDM datasets, and deaccumulate NDMCT.
-If you are using ITRM, you only need the _SNDMCT "Dataset
Sort Macro" in your EXPDBOUT, since ITRM will separately
handle the adding of the other NDM datasets to DETAIL.
-While the TYPExxxx members normally only write to //WORK,
when an xxxx product requires deaccumulation, I add the
_Sdddddd data set sort macro (s) to the TYPExxxx member
to ensure you don't accidentally use the unaccumulated
data, so _SNDMCT was added to the TYPENDM member's code.
Thanks to Thomas Clark, SEI Investments, USA.
Change 23.226 Nearly Cosmetic. MXG deleted STK subtype 4 records that
VMACSTC were in error (see Change 23.125), but did not print a
Aug 30, 2005 message on the log that you were missing that PTF.
Now it does advise you that records were deleted.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.225 Requesting RUNTRND=DAILY in %BLDSMPDB did not work as
BLDSMPDB expected.
Aug 30, 2005
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 23.224 Cosmetic corrections found during ITRM dictionary build.
VMXG70PR -TYPE70LP: SMF70DSA was not labeled.
VMACCMF -CMF27C93: C2795RFL,C2795RTY "THUS:" removed from label.
VMACNDM -NDMRJ: NDMJOBNM,NDMRJDSN,NDMSYSRC were not labeled.
VMAC79 -TYPE791/TYPE792: R791NFFI,R792NFFI were not labeled.
Aug 30, 2005
Thanks to Chris Weston, SAS Institute ITRM Cary, USA.
Change 23.223 Support for Mobius/IPAC Release 6.3 (INCOMPAT, because of
EXIPAC08 changes in the length of IPSPAGE/IPEPAGE fields in the
IMACIPAC subtype 1 record). Other changes in this release:
VMACIPAC -New variable IPPACCES='PAGE*ACCESSED*COUNT' in IPAC03.
VMXGINIT -Variable IPLOC is now $8; it includes the former reserved
Aug 30, 2005 one following byte.
Aug 31, 2005 -New subtype 8 creates dataset IPAC08, similar to IPAC03.
-But, there still is no change in their VERSION field, so
the LENGTH of the record must be used to identify the new
data added to the subtype 1 and 3 records.
-And, the vendor documentation for Release 6.3 does not
document the SMF records they write:
The REQSTART and REQEND documentation is unchanged, but
records show the values are reversed physically, with
END first and START last, and the format of their time
part still says 0hhmmssF, but the data shows four-byte
EBCDIC numeric HHMM value.
The vendor's technical support chose not to compare the
hex dump of their defective record we sent, which shows
the START field with 2208 and the END field with 2205,
but simply replied that their their dsects were the
definitive documentation source.
Just in case they ever acknowledge their error, and fix
their code so the records match the "definitive" DSECT,
MXG code now tests START versus END and reverses their
values if necessary.
Thanks to Erik Janssen, ING Netherlands, THE NETHERLANDS.
Thanks to Debby Blackey, HCA Health Care, USA.
Change 23.222 Change 23.216 was updated for APAR OA10346; new values
VMAC7072 in SMF70CIX for "IFA", "IFL", are now used to create new
Aug 29, 2005 NRIFACPU and NRIFLCPU variables, and the count of those
non-"CP" engines is subtracted from variable PARTNCPU.
Without this change, PARTNCPU included IFAs and IFLs.
MXG variable MXGCIN was also updated with new SMF70CIN.
Data from z9 processor was used to validate this change,
which also validated Change 23.186, the z9 support.
Change 23.221 The default example variable names for the TSO workload
RMFINTRV was incorrectly/accidentally changed from the historic
Aug 29, 2005 "TSO" to "TSOP" in the RMFINTRV member in MXG 22.07.
The example is now corrected so the TSO variables will
start with just the historic "TSO" prefix. If you have
your own tailored RMFINTRV member, it controlls the names
of the variables, so this change would have no impact.
However, if you were using the MXG 22.07-23.07 default,
this change could cause your reports to fail, since your
reports expect TSOP.... variable names, so your best
choice is to copy the RMFINTRV from 22.07-23.07 into your
tailoring library, and your variables will continue to be
spelled TSOPxxxx. I made his reversion because the MXG
example reports expect the TSOxxxx variable names.
Thanks to Paul N. Ross, Computer Sciences Corporation, USA.
Change 23.220 MXG logic error caused INPUT STATEMENT EXCEEDED INPUT
VMAC80A for a valid SMF 80 record that contained no segments.
Aug 30, 2005 I noted the "USER IS NOT DEFINED TO RACF" bit was on.
Originally I had the customer open a problem with IBM
for their "short record" error, because the OFFSET was
greater than the LENGTH of the SMF record, but now I am
"eating my own words", as the record was completely valid
and it was an MXG logic error that wasted both IBM's and
this MXG Customer's time:
IBM's response was completely accurate and to the point
and completely detailed the offset and locations that
proved the record was completely valid. It's one of
the best written and complete replies I've seen!
I had inserted code in MXG to read in a 4-byte test for
a vendor product, but I put the input before the group
DO _I_= 1 TO NRSET that input the segments that exist.
My input was always executed, even when NRSET=0!
That IBM reply recommended the use of the count field,
which is now done, but I also test LENLEFT GE 4 to make
sure there really are 4 bytes left to be read.
The error was overlooked when tested with the vendor SMF
because they all had the field, and there were no errors
when QA SMF 80s from several sites were read, so the code
was released in October, 2003. Since then, billions and
bullions of SMF 80 records have been read, and all had
one or more segments and no error.
I can live with those odds!
Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM.
Thanks to Victor_Van-Cakenberghe,IBM, BELGIUM
Change 23.219 The ICF Catalog 05 record variable GATGEN should have
VMAC6156 been input as &PIB.2., instead of one byte, and variable
VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005 to mark that this GDG member has "wrapped"; i.e., its
generation number has exceeded 9999. If GATWRAP is on,
GATGEN=GATGEN-32768 to contain the correct Gen number.
This discovery was precipitated by IGD07001I ABENDs in
production, which occurred when a GDG that had GATWRAP
on for some members, and GATWRAP off for others, when
that GDG generation number goes from 999 to 1000.
Normally, when all members of a GDG have wrapped, the
next catalog action turns off the wrap bit in all of
the catalog records. For a "normal" GDG, that should
happen when the +256th gen is created after wrap, as
only 255 members can exist in the catalog. But this
site had had a very old application that originally
created +1 thru +5 each day, and then deleted +1 thru
+4, leaving only +5 in the catalog. However, back when
Clinton was President, an application change was made
that created only +1 thru +3 and deleted only +1 & +2,
so there were 2 old GooooVoo's left in the catalog.
When the GDG wrapped, and when the create of +1 would
have created G1000V00, those old GooooVoo's still had
their wrap bit off, and the production job failed:
IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
Return Code 140:
Inconsistent or conflicting arguments were provided.
Reason Code 122:
Catalog G1000Vxx will cause the GDG to exceed the
limit of 10,999.
Programmer Response:
Clean up the GDG in error then catalog G1000Vxx.
The site found Information APAR II07276, which explained
how wrap works, but it says to 'see the "Z" page for
internal details of the wrap bit interface'.
So the site asked IBM Support: "We need to identify other
GDGs that have the same exposure to causing ABENDs. Can
I look at the 'Z' page? Does the 'wrap bit' appear in
SMF 61, 65, 66 ICF Catalog records?"
IBM Level 2 Catalog Support refused to answer the quite
valid question, with this answer:
"Unfortunately, the 'Z' page in our info APARs refer to
information meant for IBM eyes only, for helping us get
to problem determination quicker. We are not at
liberty to discuss any control block internals that are
not provided in our published manuals. As for
information in SMF records relating to this, this info
would be included in the updated record portion
of the SMF record, however we cannot discuss offsets
for those either. I am sorry I cannot be more helpful.
Please let me know if there are any other questions
that I can answer for you."
Even escalation to my IBM Poughkeepsie z/OS support did
not convince IBM Level 2 Catalog Support to identify
which bit is the "GATWRAP" bit. The ICF Support and
Developers hid behind "OCO", Object Code Only, as the
reason they could not provide catalog record
documentation (but DSECTS are NOT CODE!).
So I suggested the site could create a GDG and force it
to wrap, and by examining SMF records, we concluded that
first bit of GATGEN was the GATWRAP bit.
Then, I remembered I still had lots of archaic printed
manuals, and located the very old "MVS/XA Catalog
Diagnosis Reference for DFP Release 1.2", which confirmed
that the GATWRAP bit was indeed the first bit of the
GATGEN field in the 05 Catalog Record!
Thanks to Daniel F. Schwarz, Inc, Univ of Wisconsin Hospitals, USA.
Thanks to Joseph Stoll, University of Wisconsin Hospitals, USA.
Change 23.218 Format $MGDB2PT did not have value for 'R'='R:ROLLUP'.
FORMATS
Aug 23, 2005
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.217 Typo at line 392 had WEEKBLD instead of _WEEKBLD.
WEEKBLDT
Aug 23, 2005
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
=Attended the 50th Anniversary meeting of SHARE, the world's first
=computer User Group, in Boston.
Change 23.216 APAR OA10346 was supported by Change 23.187, but it was
VMAC7072 revised on Aug 18, with these new enhancements:
VMXG70PR -TYPE72Y2 dataset, variables CRYIH2R and CRYIH2s created
Aug 19, 2005 for hashing rate and hashing size for SHA=256.
-Tests in VMXG70PR were revised, because SMF70CIN can now
contain "IFA", "IFL", "ICF" or "CP" to identify the type
of processor.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.215 While not "hard-coded" DDname, these two statements that
VMXGRMFI were inadvertently left in the middle of VMXGRMFI
Aug 18, 2005 %LET SPININ = SPIN;
%LET SPINOUT = SPIN;
were just as bad as hardcoded, and cause errors if you
had changed your SPIN library's DDNAME elsewhere in MXG.
Both lines were deleted.
Thanks to Ken Williams, CPT Global, ENGLAND.
Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 23.214 Cosmetic. Label for variable A20E2HWM was corrected to
VMAC110 now read A20E2HWM='PEAK*CONTENTION*WINNERS'.
Aug 17, 2005
Thanks to Scott Wiig, U.S. Bank, USA.
Change 23.213 All SMF88xxx datetime variables were on GMT time zone.
VMAC88 Now, the GMT88OFF offset is calculated and the variables
Aug 17, 2005 are all now on the same time zone as SMFTIME.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.212 Cosmetic. Labels for RTSMAP01-RTSMAP14 were clarified to
VMAC7072 'BUCKET nn*RESPONSE TIME*GOAL*PERCENT' because they
Aug 16, 2005 contain the percentage of R723CVAL, rather than a goal
value. If you want to know the goal value of the nnth
bucket, it is RTSMAPnn*R723CVAL.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 23.211 Requesting USERADD=6 25 26J3 21 30, INCLAFTR=BUIL3001
UTILBLDP generated a MACRO _WTY26J2 _LTY26J2; statement which
Aug 16, 2005 should have been MACRO _WTY26J3 _LTY26J3 % statement.
Thanks to Hansruedi Zaugg, EDS, SWITZERLAND.
Change 23.210 MXG 23.07 only. Typo of CURRSHARE in the DROP statement
VMXG70PR should have been CURSHARE. Fortunately, there was no real
Aug 16, 2005 impact on any of the expected variables, just that the
variable CURSHARE was unnecessarily kept. The typo did
cause an error when MXG ran under V6, because the 9-byte
variable name exceeded SAS V6 limits. MXG variables are
normally also 8-bytes-max; our QA tests for name length,
but only for kept variables, and since CURRSHARE was a
typo that didn't exist in a KEEP= statement, this typo
was missed.
Note: I thought this was fixed in the final 23.07, by
Change 23.208, but I typo'd the typo, and MXG 23.07
had CURRSHAR instead of CURSHARE, so the problem was
not corrected until MXG 23.08.
Thanks to Jon Whitcomb, Great Lakes Higher Education Corporation, USA
====== Changes thru 23.209 were in MXG 23.07 dated Aug 10, 2005=========
Change 23.209 Not sure why, but the includes of VMAC7072,VMAC6,IMACKEEP
ASUMPRTR inside ASUMPRTR cause it to fail when it was INCLUDed in
Aug 10, 2005 EXPDBOUT in BUILDPDB to create the PDB.TYPE6ENH dataset.
Removing those three members from the %INCLUDE statement
in ASUMPRTR eliminated the ERROR: OLD-STYLE MACRO NAME
PDB.TYPE6 MUST CONTAIN ONLY LETTERS, DIGITS AND UNDERSC.
Those members only need to be included when SMF data is
read, and that JCL example in the comments has the needed
%INCLUDE statement, so the %INCLUDE for them in ASUMPRTR
was redundant, anyhow.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 23.208 Replaced by Change 23.210.
====== Changes thru 23.207 were in MXG 23.07 dated Aug 9, 2005=========
Change 23.207 Variables IAMNOA and IAMNOP have traded places; they were
VMACIAM coded as documented, but the documentation was wrong.
Aug 9, 2005 Aug 10: it was IAMNOD and IAMNOP that traded places.
Aug 10, 2005
Thanks to Ken Wantuch, BB&T IT Systems Engineering, USA.
Change 23.206 Line 2704 contained a semicolon after SMFPSRVR, but that
ANALCISH should have been a comma. Only caused error if CFEC FEPI
Aug 9, 2005 Connection Statistics report was requested.
Thanks to Scott Wiig, U.S. Bank, USA.
Change 23.205 -Variables LPnNSW/SMF70NSW, percent when LPAR was capped,
EXCECTIM were wrong in PDB.ASUMCEC/ASUM70LP/ASUM70PR and could
VMXG70PR even be greater than 100%. Weighted average had wrongly
Aug 9, 2005 used LPARDUR instead of SMF70DSA. Logic revised.
Aug 10, 2005 -LP1LAC was always missing in PDB.ASUM70LP because of a
Nov 10, 2005 typo that had SMF71LAC instead of SMF70LAC.
-LPnLAC was often missing in PDB.ASUMCEC because logic to
select the first LPARNUM in each CECSER has been wrong.
Variable PCTMVSBY is populated only in "this system" obs
in TYPE70PR dataset, so adding DESCENDING PCTMVSBY to the
end of the sort order that creates CECCLEAN forces that
"this system" observation to be the one that is kept.
-The optional EXCECTIM member is reinstated in VMXG70PR
to change STARTIME in PDB.ASUMCEC, PDB.ASUM70PR, and in
PDB.ASUM70LP datasets to the exact nearest minute for the
summarized output's STARTIME value; observations with
slight differences caused duplicate or semi-duplicate
output. Nov 10: this paragraph revised; originally, it
said only PDB.ASUMCEC's STARTIME was changed. But, now,
you also need Change 23.289 for full short-interval fix.
-Aug 10 enhancement: VMXG70PR logic (ASUM70PR) now adds
variable LPARNSW, percent when this LPAR was capped, to
the PDB.RMFINTRV dataset, so your system-level analysis
will contain LPAR capping.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.204 Documentation only. Change 23.021 correctly populated
ASUM70PR the "PHYSICAL" LPAR's data in LP0xxxxx variables, so the
Aug 9, 2005 total MSU, summed across all LPARs, from PDB.ASUMCEC,
will be slightly larger than the MSUs from versions prior
to MXG 23.01.
Oct 31, 2005: See Change 23.276.
Thanks to Huch Lapham, Royal Canadian Mounted Police, CANADA.
Change 23.203 Change 23.143 did not correctly handle the length 8 data
VMACMPLX fields, and MXG's INPUT did not match the MPLX DSECT.
Aug 9, 2005
Thanks to David Bixler, FISERV, USA.
Change 23.202 -Variables KW21GL01-KW21GL05 are no longer created nor
VMAC80A nor kept in dataset TYPE8021, as the RDEFINE command does
Aug 8, 2005 not contain the GLAUFLGS field.
Aug 30, 2005 -Variables CLASNAM1-CLASNAM4 are now created in TYPE8024
to support up to 5 class names.
-Support for SMF80DTP (43) for SETROPTS GENLIST/NOGENLIST
and enhancement for (42) for SETROPTS RACLIST/NORACLIST;
up to five class names (CLASNAME,CLASNAM2-CLASNAM5) are
now kept from either 42 or 43 RACFTYPE entry.
This assumes that the SETROPTS record contains either
a (42) or a (43) segment, but not both. My test data
had no event 24 records so I could not validate that
assumption. If wrong, then new variable names will be
needed and this text will be revised.
-Aug 30: tests for NR44SEGS should be NR42SEGS in the
WHEN (42) logic; caused job to fail.
Thanks to Adam Thorn, Euroclear, BELGIUM.
Thanks to Aimee Steel, Euroclear, BELGIUM.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Change 23.201 Condition Code (Return Code) 4 in ASUMTALO eliminated.
ASUMTALO The LENGTH statement in ASUMTALO specified DEVICE $8, but
Aug 8, 2005 the actual length of DEVICE is only $7; both the LENGTH
entry and the (redundant) "Compiler Faker" statement were
revised to make DEVICE only seven characters long.
The message appears when SPIN.SPINTALO exists, i.e., only
on the second or later execution of ASUMTALO, but it had
no impact, other than setting the condition code.
-After years of seeing those spurious LENGTH OF CHARACTER
VARIABLE HAS ALREADY BEEN SET messages, when there was no
change in the length (before SAS fixed the message so it
now only prints when the lengths are different), this is
the first time that message actually uncovered an error!
Note: The message text suggests that putting the LENGTH
statement ahead of the SET statement will eliminate the
message; however, that is not acceptable because if the
LENGTH statement precedes the SET statement, then this
DATA step could inadvertently truncate the kept length
of a variable, but there would be no warning message.
Instead, MXG puts the LENGTH statement after the SET
statement so that any mismatch will be detected.
Thanks to Mike Allen, Pacific Corp., USA.
Change 23.200 Support for MegaCrytion's user SMF record creates:
EXMGCRCR dddddd dataset description
IMACMGCR MGCRCR MEGACRYP MEGACRYPTION START/END
TYPEMGCR The start and stop datetimestamps MGCRSTRT/MGCREND are
TYPSMGCR on the GMT clock, and there is no GMT Offset in the
VMACMGCR record that could safely be used to infer the zone,
VMXGINIT until the vendor adds the GMTOFFSET field to the record.
Aug 4, 2005
Thanks to John Rivera, i-structure, USA.
Change 23.199 Support for TPF Continuous Data Collection, TPFCDC, which
EXTPFC80 is a new data source for TPF and creates many datasets:
EXTPFC81 dddddd dataset description typetype
EXTPFC82 TPFC80 TPFC80 SYSTEM MESSAGES 80X
EXTPFC83 TPFC81 TPFC81 SYSTEM LISTS 81X
EXTPFC84 TPFC82 TPFC82 SYSTEM BLOCKS 82X
EXTPFC85 TPFC83 TPFC83 DASD/POOLS 83X
EXTPFC86 TPFC84 TPFC84 DASD DEVICES 84X
EXTPFC87 TPFC85 TPFC85 SYSTEM VFA 85X
EXTPFC88 TPFC86 TPFC86 SUBSYSTEM VFA 86X
EXTPFC89 TPFC87 TPFC87 MPIF 87X
EXTPFC8A TPFC88 TPFC88 TAPE 88X
EXTPFC8B TPFC89 TPFC89 TCP/IP 89X
EXTPFC8C TPFC8A TPFC8A I-STREAM 8AX
EXTPFC8D TPFC8B TPFC8B SUBYSTEM MESSAGES 8BX
EXTPFC8E TPFC8C TPFC8C SUBSYSTEM USER 8CX
EXTPFC8F TPFC8D TPFC8D LODIC 8DX
EXTPFC90 TPFC8E TPFC8E MQ SUMMARY 8EX
EXTPFC91 TPFC8F TPFC8F MQ QUEUE DETAIL 8FX
EXTPFC93 TPFC90 TPFC90 MQ CHANNEL DETAIL 90X
EXTPFC94 TPFC91 TPFC91 USER DATA 91X
IMACTPFC TPFC93 TPFC93 CDC RECORD 93X
TYPETPFC TPFC94 TPFC94 STATIC SYSTEM INFO 94X
TYPSTPFC TPFCDC "records" have a '93'x segment with total length
UTILTPFC the number of segments that follow in that record, and
VMACTPFC then those segments, which can have repeated entries,
VMXGINIT and each of which contains its own-length field, follow.
Aug 3, 2005 -MXG creates an observation in each of the above datasets
Aug 19, 2005 for each instance of each segment.
-But the TPF creation splits these logical records into
multiple physical "tape" records that are most definitely
NOT standard variable length records, and that cannot be
directly read. The first 4095 bytes of data start the
first physical record, but TPF adds a 16-byte trailer
segment, creating a 4111-data-byte (4115 LRECL) variable
length first-record. The remaining bytes of the logical
record start in the first byte of the second "tape"
record, which is padded with nulls thru data byte 4095,
and to which the TPF 16-byte trailer is added at the end.
-Because of this non-standard record format, you will have
to pass the TPFCDC data file twice: first, with the MXG's
UTILTPFC program, which will read those split records and
create a legitimate VBS record for each split record, and
then second, that output file is processed by TYPETPFC to
create the preceding 20 TPFCDC datasets.
Note: UTILTPFC is heuristic based on the sample data,
and it reads a pair of records for each event.
It will need revision if your TPF data length
causes more than two split records to be needed.
-Product Problems Reported to IBM:
1. Their complicated split process is not working; one
byte of data is lost from the segment that is split!
In my test data that was always the '87'x segment,
so MXG resets that segment's length, but that only
works if the '87' is the segment across the split.
MXG will be revised when IBM corrects their error.
Oct 28 Update: IBM APAR PJ30503 corrects the one
byte loss error.
2. Two fields in the '90'x segment have blanks instead
of binary numeric values. Aug 19 update: IBM says
the two fields (TPFCBTSZ, TPFCSZLB) do not apply when
the MQ Channel Type is SERVER (TPFCCTYP='V'); MXG now
sets those two variables missing when TPFCCTYP='V'.
-Product exposure:
Several character fields have field lengths that can be
changed by the TPF installation; MXG code expects these
lengths for those fields; other lengths cause errors:
Length Field Name Length MXG Variable
CDC_SS_NAME_LEN 4 TPFCSSNA,TPFCSS
CDC_SSU_NAME_LEN 4 TPFCSSUN,TPFCSSU
MQ_Q_MGR_NAME_LENGTH 48 TPFCQMGR
MQ_Q_NAME_LENGTH 48 TPFCQNAM
MQ_Q_CHANNEL_NAME_LENGTH 20 TPFCCHAN
Thanks to Luis R. Vega-Zayas, IBM TPF, USA.
Change 23.198 Support for existing NT objects with fewer data fields
VMACNTSM (DATABASE with NRDATA=133, MSEXCHANGEIS MAILBOX with 49,
Aug 4, 2005 DATABASE==>INSTANCES with NRDATA=92, and MSEXCHANGE IS
with NRDATA=110) than MXG code expected. Those objects
records were deleted prior to this change.
Thanks to Paul Billick, Harleysville Insurance, USA.
Change 23.197 The hardcoded "SPIN" DD in PROC COPY IN=SPIN OUT=&PDBMXG
BUILD005 in BUILD005/BUIL3005 was changed to &SPINOUT so the new
BUIL3005 SPIN datasets will be backed up from the correct DD.
Aug 4, 2005 If the &SPINOUT was different than "SPIN", you could get
a VARIABLE NOT FOUND error when SPUNJOBS executed.
Thanks to Ken Williams, CPT Global, ENGLAND.
Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 23.196 -Support for CA SAR/VIEW R11,they INCOMPATIBLY CHANGED the
FORMATS SMF records, increasing these variables to $EBDCID32:
VMACSARR SV20DIST,SV21DIST,SV30RID,SV30VID,SV31RID,SV31VID,
Aug 3, 2005 SV31DIST,SV31BNDL,SV32RID,SV33RID,SV34RID
and by increasing SV33LTM to PIB4. The test for SARR
Version got messy; SMFVPRL is now '11.0' but it used to
be '2.0 ', so instead of IF SMFVPRL GE '11.0' THEN....,
each test was more complicated:
IF INPUT(SCAN(SMFVPRL,1,'.'),5.) GE 11 THEN ....
-Format MGSARTY new value '10:DOC VIEW WEB' for Interface
Type was added.
Thanks to Mark Schrager, Metropolitan Life, USA.
Change 23.195 Line fifteen had an end comment but no start comment,
GRAFTALO which caused the %MACRO statement to never be read.
Aug 3, 2005
Thanks to Ep van der Es, Dow Chemicals, THE NETHERLANDS.
Change 23.194 -Missing value messages for DB2RDWTM when testing IMACEXCL
UTILEXCL built by UTILEXCL found DB2RDYTM had been misspelled as
Aug 2, 2005 DB2RDWTM, which does not exist. Value of DB2RDYTM was
incorrect by a factor of 16 due to that typo.
-Calculation of SEGLEFT for optional segments was only
correct for the first segment; fortunately, it appears
to have had no impact; using SEGSTRT instead of LOC in
each calculation corrects the exposure.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 23.193 Support for TNG AIX new object CA PROCESS GROUP (PID)
EXTAI025 creates new MXG AI025 dataset. New variables are added
FORMATS to datasets AI018 (CA KERNEL GROUP), AI020 (CA NETWORK
VMACTNG GROUP), and AI016, (CA INTERFACE GROUP).
VMXGINIT
Aug 2, 2005
Thanks to Dale Gilbert, AhYum, USA.
Change 23.192 Variable NDMUID in dataset NDMRJ (Run Job) was truncated
VMACNDM to 8 bytes, instead of being input as $EBCDIC64., because
Jul 30, 2005 the test for that input did not contain 'RJ'.
Aug 10, 2005 -Aug 10: additional variables are now read in from 'RJ'.
Thanks to Tom Neurauter, Fidelity Systems, USA.
Change 23.191 Cosmetic. Invocation of VMXGSUM had "ANALCACH" instead
ASUMCACH of "ASUMCACH" for the printed message text.
Jul 30, 2005
Thanks to Chuck Hopf, MBNA, USA.
Change 23.190 Comments only. IMACICDA is not used if IMACEXCL controls
IMACICDA the input for a CICS APPLID/REGION. When IMACEXCL is
Jul 27, 2005 used, it controls the INPUTing of the optional CICS data
segments. Only when there is no IMACEXCL, or IMACEXCL
does not protect an APPLID, does IMACICDA control the
order of the optional CICS data segments MXG expects.
Thanks to Normad Poitras, IBM Global Services, CANADA.
Change 23.189 The example should have had //DAY DD instead of //PDB DD,
PDBCPYDY to copy from the "TODAY" PDB library just created by the
ACHAP35 BUILDPDB program, into the day-of-week PDB library. I use
Jul 21, 2005 //PDB in the "build", but //DAY thereafter to refer to
the "today" PDB library.
Thanks to Jeff Harder, Farm Bureau Insurance, USA.
Change 23.188 Variable R744QFLG should have been defined LENGTH $1, but
VMAC74 ended up as CHAR 34 because it's formatted $MG074QF which
Jul 20, 2005 set the kept length as the longest text in that format.
This variable was not caught by Change 23.170 because it
does NOT appear in an INPUT statement, which was expected
in our original QA analysis program, but that report has
been revised to catch any other similar syntax issues.
Thanks to Travis Hicks, IBM GS (Telstra Account), AUSTRALIA.
Change 23.187 Support for APAR OA10346 adds the LPAR's User Partition
VMAC7072 Identifier (UPID, the value you specified on your HMC
Jul 20, 2005 Customize Image Profile) to RMF 70 PR/SM section for each
LPAR, as variable SMF70UPI in TYPE70PR dataset.
As was reported in MXG Newsletter 46, APAR II13668 said
that after z990s, LPARNUM (SMF70LPN) was no longer a
static identifier, but instead is now a system generated
number of the alphabetical location of the LPAR name, and
the LPARNUM of an LPAR changes when you add/delete LPARs.
But now, IBM has accepted Edward Williams suggestion and
added the new SMF70UPI variable to TYPE70PR dataset.
MXG code
If you want to use SMF70UPI in your reporting, please
send me some SMF 70 records (see member SENDDATA) after
you have the APAR installed, so we can decide how to
add SMF70UPI to the ASUM70PR and ASUM70LP datasets, and
so I can validate those changes.
Thanks to Edward Williams, BMC, USA.
Change 23.186 Support for new CPUTYPE '2094'x for the z9 processors;
VMAC7072 this is an INCOMPATIBLE change: without this change, your
VMXGRMFI TYPE70PR dataset will contain extra observations for
Jul 20, 2005 nonexistent LCPUADDR, and incorrect data values.
Aug 29, 2005 -The exposure in VMXGRMFI for RMFINTRV is minimal; the
CPUTYPE test is used only for OS/390 or very early z/OS
that did not have SMF70WLA or SMF70LAC populated, and it
is used only to create CECSUSEC, CPCNRCPU, CPCFNAME and
CPCMSU variable's values from table lookups.
-In VMAC7072 there are several CPUTYPE tests with impact:
It is used to set SMF70ONT missing when it is zero for
some cases, which affects counting of CPU engines, and
which is used to identify spare engines so they are not
output in PDB.TYPE70PR; without this change, extra and
spurious observations are created in PDB.TYPE70PR.
It is also used to populate SMF70CPA for OS/390 and
early z/OS before SMF70CPA was added to the SMF record.
Thanks to Patricia Hansen, ADP, USA.
Change 23.185 Roscoe creation of PDB.ROSCOE didn't work when UTILBLDP
VMACROSC was used to create the sysin stream to add ROSCOE to PDB.
Jul 19, 2005 Most "DIF" members invoke the _Sdddddd macro for that
dataset with accumulated data, but ROSCOE is unique and
is now revised, so that DIFFROSC is included when _SROSC
is invoked, and all of the datasets that are processed in
DIFFROSC no longer have their _Sdddddd sort macro invoked
in the revised _SROSC macro. And, the ROSCOE datasets
that are merged into PDB.ROSCOE are no longer kept.
Thanks to Jeff Harder, Farm Bureau Insurance, USA.
Change 23.184 Optional new %LET MXGABND=nnnn; enhancement can be used
VMXGINIT to make MXG fail with a USER ABEND nnnn, instead of just
VMAC110 printing error messages on the SAS log. This option is
VMXGRMFI whether or not you want the job to USER ABEND nnnn.
Jul 19, 2005
Oct 19, 2005 -To enable the new MXGABND enhancement, you would insert:
%LET MXGABND= 333;
as your first SYSIN statement, and if any of the below
errors occur, your MXG job will USER ABEND 333.
-The default value for MXGABND is 0000, for NO ABEND. You
must use a value between 0001 and 4095 for nnnn.
Actually, you can use a larger value for nnnn, but the
ABEND code you see will be MOD(ABEND,4096) so using
nnnn=4096 resulted in USER ABEND U0000,
nnnn=8000 resulted in USER ABEND U3904, and
nnnn=9999 resulted in USER ABEND U1807.
The option is only available for these specific errors:
-SMF type 110 CICS record processing (Jul 19, 2005):
***ERROR.TYPE110.CICS/ESA 3.1.0. EXCLUDED FIELDS HAVE
BEEN DETECTED. YOU MUST RUN UTILEXCL.
RECORD WAS DELETED. CICSTRAN DATA WAS LOST.
***ERROR.VMAC110 STRTTIME HAS MISSING VALUES and
***ERROR.VMAC110.ESA.2 INVALID TASKNR OR STRTTIME IN...
Those errors means that your CICS records have
changed or that you have excluded data and you must
run the UTILEXCL program to create IMACEXCL and to
tailor the IMACICxx's that you may also need to
EDIT to properly read the data. But, as the
message was only printed in the middle of the SAS
log of the daily job, which can be kilothousands of
lines of text, they requested a new option that
would let them choose to cause the MXG job to ABEND
for these CICS errors that delete data, in addition
to the error message (which will now be the last
thing printed on the log!!).
-RMFINTRV creation (Oct 19,2005):
***ERROR.RMFINTRV.CPUTM IS MISSING.
The CPUTM variable from TYPE72GO dataset is missing
which can be caused by incorrect tailoring in your
EXTY72GO exit member.
This change will be updated if other error messages are
added to this enhancement. See Change 39.180 for CCode.
Thanks to Mike Perry, Morgan Stanley, USA.
Thanks to Min-che Li, Morgan Stanley, USA.
Change 23.183 Support for APAR OA11036, which adds MACHTIME to SMF 89
VMAC89 and variables SMF89HOF and SMF89DTO values.
Jul 18, 2005
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 23.182 Test of LENCPUC GE 24 should have been GE 64 to input the
VMAC7072 SMF70HWM and SMF70HOF fields in support for APAR OA11375.
Jul 18, 2005
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 23.181 -DB2ACCTP, Package Data, was still wrong for new DB2 V8.1
VMACDB2 IFCID=239 record with LENQPAC=0 and more than one package
Jul 17, 2005 segment. The INPUTed LENQPAC at the beginning of each of
Aug 12, 2008 those segments does not include its own length, so a new
LENxxxx=LENxxxx+2; statement had to be added to each of
of the adjustment DO groups invoked when LENxxxx=0. The
text of Change 23.140 was revised to show new statement.
-For DB2 V7.1 and later, variables QBACxxxx and QTXAxxxx
are always missing in DB2ACCTP package data; those
variables only have values in the DB2ACCT dataset.
MXG logic for the IFCID=0003 record prior to V7.1 had
incorrectly input the QBAC and QTXA fields before the
loop across each of the OFFQPAC segments. Re-locating
the QPAC segment to be processed before the other
segments now correctly causes those sets of variables to
be always missing in DB2ACCTP.
Note: the text in this paragraph was completely wrong
prior to Aug, 2008, but the QBACxxxx,QTXAxxxx
variables have ALWAYS been missing values i
the DB2ACCTP dataset, in spite of that text,
now revised.
-It was noted that in the DB2 V8.1 DB2ACCTP IFCID=239 data
that QWACBSC and QWACESC are both missing, making it less
easy to match the DB2ACCTP back to it's DB2ACCT obs.
-Missing value calculation for QGBAXN eliminated, but that
variable is now always missing; instead, use QBGAEX.
Thanks to Victoria Lepack, Aetna, USA.
Change 23.180 DATETIME logic had incorrect word numbers for the SCAN of
VMACPRPR YYYY and SS, now corrected.
Jul 8, 2005
Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM.
Change 23.179 Variables VSRNBYTR and VSRNBYTW in dataset HSMVSRFU were
VMACHSM way too small, as their value in the record was in KB but
Jul 8, 2005 their label indicated bytes. They are now multiplied by
Jul 11, 2005 1024 to convert their value to bytes, and are formatted
with MGBYTES format to "print pretty". These variables
FSRBTTR FSRBTTW FSRDBYTR FSRDBYTW FSRTBYBK FSRTBYTR
FSRTBYTW DSRBYTR DSRBYTW
that contain bytes in both their values and labels are
now also formatted with MGBYTES for consistency.
However, these storage-value variables:
DSRNGBR ='GIGABYTES*READ'
DSRNGBW ='GIGABYTES*WRITTEN'
VSRTOTKB='TOTAL*CAPACITY*OF VOLUME (IN KB)'
are NOT converted to bytes, and are NOT formatted MGBYTES
because they agree with their labels, and changing their
internal value to bytes could impact existing reports.
Life is filled with compromises when you don't make the
correct first choice!
Thanks to Robert Chavez, Office Depot, Inc, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.178 Variable PARTISHN was not labeled in dataset TYPE73, so
VMAC73 it was also unlabeled in dataset TYPE73OE.
Jul 8, 2005
Thanks to Chuck Hopf, MBNA, USA.
Change 23.177 ML-34 of ASMTAPEE and the HSC exit are production status!
ASMHSCEX Beta Tests with the new HSC exit uncovered some minor
VMACTMNT errors that are now corrected, but the exit works fine to
Jul 3, 2005 capture all HSC-controlled tape mounts, just like the IBM
Jul 11, 2005 Volume Mount Exit, previously implemented in ML-34, works
to capture all IBM-controlled tape mounts. Sampling is
no longer used to detect tape mounts, so none are missed.
As currently implemented, ASMHSCEX supports only a single
HSC or CSC, but now that we are aware that both products
and even multiple copies of HSC and/or CSC can exist, we
are investigating how to support those environments, and
will have a revised ASMHSCEX for those installations.
-Primary correction was in ASMHSCEX, which populated the
JOB file with the JCTJOBID value instead of JOB name.
-But because JCTJOBID=JOB, the MXG logic to create JESNR
from the JCTJOBID caused JESNR to be missing:
JOB=JCTJOBID is a valid condition for "early ASID" STCs
the don't have a "JESNR".
-And beta tests exposed MXG errors in VMACTMNT that caused
INITTIME and PROCSTEP to be missing/blank.
-With this Change, ML-34 is now ready for production use.
Thanks to Steve Martin, Fidelity Systems, USA.
====== Changes thru 23.176 were in MXG 23.06 dated Jun 29, 2005=========
Change 23.176 -Support for SMF 6 ESS GEPARMKY='04D'x with more than one
IMAC6ESS segment creates ESSMAIL3 and ESSMAIL4 variables. Caused
VMAC6 INPUT STATEMENT EXCEEDED error.
Jun 29, 2005 -Support for SMF 6 ESS GEPARMKY='04B'x creates ESSMFILE.
-Support for SMF 6 ESS GEPARMKY='04E'x creates ESSRPLY2.
Thanks to Engelbert Smets, Provinzial, GERMANY
Thanks to Cornelia Opel, Provinzial, GERMANY
Change 23.175 Support for SMF 22 Subtype 11 I/O Configuration Change
EXTY22UA creates new dataset:
IMAC22 dddddd Dataset Description
VMAC22 TY22UA TYPE22_A I/O Configuration Change
VMXGINIT
Jun 28, 2005
Thanks to Shane Dowling, DEWR, AUSTRALIA.
Change 23.174 Change 18.338 created the _Vdddddd macro definitions, but
VMACMVCI not all MXG code members have been revised to create that
Jun 27, 2005 token. This change creates _VMVCICS and _VMVCICF in the
VMACMVCI member.
Thanks to David Edge, Thomson BETA Systems, USA.
Change 23.173 Using TYPEHSM, datasets HSMWWFSR and HSMWWVSR were not
DIFFHSM sorted into the //PDB library, because TYPEHSM included
Jun 24, 2005 the DIFFHSM member, which had separate _Sdddddd sorts
for each dataset, but DIFFHSM had not been updated to add
sorts for those two datasets. Using TYPSHSM, those data
were sorted into the //PDB, because it invoked the _SHSM
product sort macro, which does list all HSM datasets.
The DIFFHSM member is revised to use the _SHSM member.
Normally, TYPExxxx members leave all of their datasets
in the //WORK file, while the TYPSxxxx members sort all
of the xxxx products datasets into the //PDB library.
But when there are accumulated data in the product, the
TYPExxxx member always will invoke the sort into //PDB
to de-accumulate that dataset, and HSM writes SMF data
with accumulated values, so both TYPEHSM and TYPSHSM
now produce identical results.
Thanks to Ian Arnett, TD Canada Trust, CANADA.
Thanks to Luc Audet, TD Canada Trust, CANADA
Change 23.172 -SAMS POOLS record was INCOMPATIBLY CHANGED in 002053V4 by
VMACSAMS increasing NRVOLS field from 4 to 6 bytes, causing all of
Jun 24, 2005 the variables to the right to have wrong values. With the
Jul 20, 2005 help of CA Technical Support to provide the DSECTS of the
Jul 30, 2005 SMF record, MXG code for POOLS was corrected and revised:
-The SAMS Version is used, rather than the circumvention
to test LRECL, to detect the longer NRVOLS field.
-Data in SAMSFBYX/TBYX/VBYX/LBYX were wrong because those
four fields are packed decimal, not binary values, and
MXG was using the incorrect informat for them.
-New in 002053V4 variables SAMSPALL & SAMSBALL are input.
-New in 002053V5 variables SAMSESA/ESB/ESC describe the
storage group in three lines of text.
-Support for 002053V6 was revised and valided Jul 30; the
V6 record's POOLS record was completely restructured.
-Variable SAMSJOBN was removed from the KEEP= and LABEL
statements, as there is no "JOB" name field in SAMS SMF.
Thanks to Abily Christelle, GICM, FRANCE.
Thanks to Patrick Notteghem, CA, FRANCE.
Change 23.171 -Variable LOCLINFO is INPUT $EBCDIC8, which works fine if
VMAC30 SMF30UID contains text or hex characters on z/OS, but if
Jun 24, 2005 executed on ASCII, that INPUT statement changes any hex
characters. The only solution for ASCII execution is to
create a second variable, LOCLINCH, INPUT as $CHAR8 and
FORMATed $HEX16. so any non-text characters in that field
are preserved, and available in the EXTY30Un exits.
-Missing value calculations when SMF30IST was missing were
eliminated; SMF30IST only exists in subtype 2, 3, and 6.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
Change 23.170 Character Variables formatted with $MGdddxx formats that
VMAC102 were NOT in a LENGTH $1 statement were stored in LENGTH
VMAC110 of the maximum text in the $MGdddxx format values, which
VMAC74 wasted disk space. Now, all character variables with $MG
VMAC84 format names have been identified, and added to a LENGTH
VMAC85 statement if needed to reduce their stored length.
VMAC92 VMAC110: DS2TCBMD-DS9TCBMD DSaTCBMD SORSSLFL
VMACAIM6 VMAC74: R744QFLG
VMACBE91 VMAC84: JMFJSJSR
VMACBE97 VMAC85: R85ODT R85OVT R85TVT
VMACCIAO VMAC92: SMF92MFG SMF92UFG
VMACEDGR VMACAIM6: IOCTYPE
VMACFTP VMACBE91: BE91STP
VMACHIOM VMACBE97: B970OBT
VMACHURN VMACCIAO: CIAOETYP
VMACNSPY VMACEDGR: RDVRSTYP RRTYPE2 RSTYPE2
VMACOMDB VMACFTP: DVGSCOMP DVGSRPNT DVGSRTYP
VMACOMSM VMACHIOM: HIOOSTYP
VMACQACS VMACHURN: HU62UMOD HU62UTYP
VMACSAR VMACNSPY: NSPYRTPS
VMACSARX VMACOMDB: QMDAPTYP QPACAAFG QWHSRMID
VMACSPMS VMACOMSM: OMDEVMDL
VMACSYSV VMACQACS: ETLPRCL JBSTYP SCPRCL SHPRCL STPRCL
VMACTIE VMACSAR: SARPMDX
Jun 20, 2005 VMACSARX: GCRPMDX
Jul 21, 2005 VMACSPMS: SPMSRLS
VMACSYSV: TRANTYPE
VMACTIE: TIELOG
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 23.169 Support for additional SMF 99 Subtype 2 data segments.
EXTY99Q2 -These variables added to TYPE99_2 dataset:
EXTY99R2 PCADP ='CURR*ACHIEAVABLE*DEMAND*PCT'
EXTY99S2 PESCS ='ASIDS*EXPLICIT*STORAGE*CRITICAL'
EXTY99V2 PGRIN ='GROUP*NAME'
FORMATS PIFAD ='IFA*DELAY*SAMPLES'
IMAC99 PIFAU ='IFA*USING*SAMPLES'
VMAC99 PIFLAG ='FLAGS'
VMXGINIT PSAMHST ='SAMPLE*HISTORY*ROWS*USED'
Jun 22, 2005 PSBCPUD ='SAMPLE*BASED*CPU*DELAYS'
PSBCPUU ='SAMPLE*BASED*CPU*USINGS'
PSBIOD ='SAMPLE*BASED*I/O*DELAYS'
PSBNIOD ='SYSPLEX*WIDE*NON I/O*DELAYS'
PSPMDP ='MINPCT*PROCTIME*DEMANDED'
PSWCPUU ='SYSPLEX*WIDE*CPU USING*SAMPS'
PSWCT ='SHORT*WAIT COUNT*ACCUMULATE'
PSWIDLE ='SYSPLEX*WIDE*WIDE IDLE*SAMPS'
PSWNONI ='SYSPLEX*WIDE*NON-IDLE*SAMPS*
PSWOTHR ='SYSPLEX*WIDE*OTHER*SAMPS'
SMF99SCI='SERVICE*CLASS*INDEX'
-New datasets are created from subtype 2 segments:
dddddd Dataset Description
TY99R2 TYPE99R2 99-2-Q REMOTE QUEUE DATA
TY99Q2 TYPE99Q2 99-2-Q QUEUE SERVER DATA
TY99S2 TYPE99S2 99-2-S SERVER SAMPLE DATA
TY99V2 TYPE99V2 99-2-V SERVER DATA
Thanks to Chuck Hopf, MBNA, USA.
Change 23.168 Cosmetic. Blanks in SMF6TARG (IP Address) are removed.
VMAC6
Jun 21, 2005
Thanks to Thomas Peiper, Tietoenator, SWEDEN.
Change 23.167 The Installation Data field, INSTDATA, was inconsistently
VMACRACF input as $200 with +55, or $40 with +215, and variables
Jun 21, 2005 OMVSHOME, OMVSPROG, USRDATA, and APPLDATA did not input
their full $255 byte field. The $200 was the SAS V6
limit for character variables, but I've been reluctant to
change those inputs to $255, because that would cause an
avoidable ABEND with V6, and besides, is there really
anything in those last 55 bytes that is needed? However,
since this RACF Unload utility code didn't exist when SAS
V6 was The Thing for MXG years ago, I've chosen to
increase all these variables to input and be stored as
$255, and hope no V6 sites try to use this support! Some
MXG members are already documented as requiring SAS V8
(like records with UCS data, for example), but the few
sites that I know are still on V6 are not their by their
own choice, so I'll try to protect the really important
SMF records, until a real need arises.
Thanks to Len Rugen, State of Missouri, USA.
Change 23.166 -Fields were added to CMRFILE, probably Version 5.6, but
VMACMVCI there is no length-of-file-segment field in the CMRDETL
Jun 21, 2005 record, so the new fields were overlooked, causing trash
values in the second and subsequent file segments in each
CMRDETL record with more than one file segment.
New variables are created and kept in CMRFILE dataset:
T6EF1='RNU*COUNT' T6EF2='RPU*COUNT'
T6EF3='RWD*COUNT' T6EF4='REDSET*COUNT'
T6EF5='RDUSET*COUNT' T6EF6='RNXSET*COUNT'
T6EF7='RPVSET*COUNT' T6EF8='RNUSET*COUNT'
T6EF9='RPUSET*COUNT' T6ET1='RNU*TIME'
T6ET2='RPU*TIME' T6ET3='RWD*TIME'
T6ET4='REDSET*TIME' T6ET5='RDUSET*TIME'
T6ET6='RNXSET*TIME' T6ET7='RPVSET*TIME'
T6ET8='RNUSET*TIME' T6ET9='RPUSET*TIME'
T6ETA='READ*TIME' T6ETB='RDU*TIME'
T6ETD='WRT*TIME' T6ETE='RWT*TIME'
T6ETG='DEL*TIME' T6ETH='UNK*TIME'
T6ETJ='SBR*TIME' T6ETK='RNX*TIME'
T6ETL='RPV*TIME' T6ETM='EBR*TIME'
T6ETO='RBR*TIME' T6ETP='OTH*TIME'
T6ETQ='FCTOT*COUNT' T6ETR='FCTOT*TIME'
T6ETS='FCWAIT*COUNT' T6ESR='SRECS*COUNT'
-T6EV1,T6EV2,T6EV3 are protected for hex zeros for Volume
Serial Numbers; T6EV3 contains hex values in byte 4 that
are changed to blanks by MXG.
-Variable TFILI was kept as $27, because it was assigned
the $MGMVICT format without also being set to the $1
length in a LENGTH statement. Variables that are assigned
an MXG-built character format will have the length of the
longest value statement, if their length is not fixed in
a LENGTH statement; this was overlooked, but we'll add a
new report to detect any other cases of wasted space.
-Variable SYSTEM was always blank; it was only populated
in Version 5.3 records, but now it is populated from the
T6ESMFID SMF TYPE field.
-These variables are now set to blank if they contained
hex zeros:
T6EBMSN T6ECMP53 T6EOPID T6EPSBN T6ERPTCL T6ETMID
T6EAUTH T6ECORR
-However, when T6EBMSN starts with "CSMI" in EBDCIC4., the
last four bytes are non-printable ('1C796A00'x) which may
be trash left over, or may be actual "data" for the BMS
Map Name. I've chosen to detect these and store only the
"CSMI " back in T6EBMSN, and have stored the last four
hex bytes in new variable T6ECSMI until we have an answer
from the vendor as to why that field has mixed EBCDIC and
HEX when it starts with the mirror transaction name CSMI.
Thanks to David Edge, Thomson BETA Systems, USA.
Change 23.165 New MGFMTVR identifies which MXG Version's FORMATS member
FORMATS was used to create the format library pointed to by the
Jun 21, 2005 //LIBRARY (or LIBRARY LIBREF). Using this program
DATA _NULL_; FMTVERS=.; PUT FMTVERS MGFMTVR. ;
will print, on the SAS Log:
MEMBER FORMATS FROM MXG 23.05 CREATED YOUR MXG FORMATS.
Thanks to Ron Alterman, Pacific Gas and Electric, USA.
Change 23.164 Additions in WAS Version 6.01, support for PQ96114 and
FORMATS MXG errors are corrected:
VMAC120 -MQ Series variable SM120CSO has new values of 5 and 6:
Jun 21, 2005 now decoded by the MG120CO format:
5:HTTP SESSION and
6:HTTP ENCRYPTED SESSION
-MQ Series variable SM120JB3 has overlooked values 4,5 and
a new value of 6 now decoded by MG1203B format:
4='4:BMP ENTITY BEAN'
5='5:CMP ENTITY BEAN'
6='6:MESSAGE DRIVEN BEAN'
-Variables SM120JHF and SM120JHT are now correctly input
as &PIB.8 instead of &PIB.4. JHF was always zero, and
JHT contained the value of JHF when they were wrong.
Thanks to Martyn Jones, Euroclear, BELGIUM.
Thanks to Phil Downes, Euroclear, BELGIUM.
Change 23.163 INVALID ARGUMENT FOR INPUT FUNCTION because SyncSort has
VMACSYNC a new and unexpected value of 'SMS' for ths UCB Address.
Jun 18, 2005 'SMS' is now tested to circumvent the error message.
Thanks to Jim Dammeyer, State Farm Insurance, USA.
Change 23.162 ML-34 of MXG Tape Mount Monitor provides ASMHSCEX member
ASMHSCEX that you assemble to create an HSC SLSUX01 user exit that
ASMTAPEE your HSC guru then installs in HSC, so that all of the
Jun 15, 2005 HSC-controlled mounts (STK VTS or STK Silos) will be
Jun 22, 2005 captured by exit (event-driven), instead of by sampling.
(Sampling, even at .5 seconds missed a lot of the very
fast VTS mounts; using an exit captures 100% of them.)
The STKX option tells MXGTMNT to use the HSC exit, like
the MXIT option in ML-31 used the IBM Volume Mount Exit;
the difference is that you have to install the HSC exit,
while IBM's exit was already there! With MXIT and STKX
enabled, all mounts to real drives, all IBM VTS mounts,
and (finally!) all HSC-controlled mounts are captured!
The SLSUX01 exit, created by assembly of the ASMHSCEX,
itself can be used in one of two ways, depending on your
site's current use of the STK HSC exit, and you control
which way via the SYSPARM input during assembly. If your
site does not currently use the STK HSC exit, SYSPARM(N),
which is the default, results in just the MXG replacement
exit code being assembled. But if your site does use the
HSC exit, specifying SYSPARM(Y) at assembly of ASMHSCEX
will cause MXG code to include your existing exit code
during the link edit step that creates the exit module.
Then, when MXG's exit is subsequently defined to HSC, our
exit will invoke your exit as if we weren't there, then
we'll do our thing to collect the necessary data and pass
that to the TMNT address space. This is well documented
in the ASMHSCEX comments, but please let us know if the
instructions need clarification or improvement.
You can assemble ASMTAPEE member to create the MXGTMNT
program load module before you assemble ASMHSCEX to
create the MXG SLSUX01 HSC exit, or vice versa; there is
no forced order for installation, and enablement of
MXGTMNT can occur in any order.
The implementation of the MXG HSC Exit is quite robust:
- it is essentially a NOP if it detects MXGTMNT is not
enabled or is not running, or, conversely,
- if MXGTMNT is enabled, but the exit is not there, the
environment exists to support the exit, but nothing
will happen until the exit is running.
We believe HSC 5.1 and HSC 6.0 versions are supported,
based on STK documentation; it might also work with 5.0,
but we don't have enought information from STK to confirm
if that is true, and, besides, 5.0 is archaic!
You can only specify STKX=YES at assembly or start-up of
the monitor; you cannot start the monitor and then use
a command to turn on STKX later; that might be added in
the future, but it would have delayed delivery of this
release.
We have Alpha tested this code as thoroughly as we can,
and we have NEVER caused a system outage with any ML of
the monitor, but since we don't have a Silo or VTS on our
test system, we ask that you ONLY test ML-34 on an HSC
test system that can afford to be "crashed", before you
use it on an real system. When we have more feedback
from Beta test sites, this text will be revised to
confirm successful tests at real sites.
a. Jun 22 update:
-First test of the HSC Exit did not succeed but it did no
harm: on the first mount after initializing the monitor
and exit, the user exit ABENDed with S978, and then it
disabled itself; tape mount processing then proceeded as
usual without the exit. asmguy@mxg.com examined the dump
and the listing of the assembly of the HSC exit and
corrected a "dumb mistake, bad branch" error in ASMHSCEX,
now dated Jun 22, 2005.
-An IBM-only site raised three question,:
1. Why do I get STKX=NO in the monitor output while I
have 'OPTIONS2 DC AL1(DOARCV+DOMXIT+DOSTKX) in the
assembler code:
asmguy answer ==>
Because I forgot to add code to change the STKX=NO to
STKX=YES if the code is modified to turn this on
instead of using input parms. This is a tough one for
me to remember since it's counter to the way I think
and I always use parms when I test so I don't catch
these things. Anyway, I'll correct it.
2. What does 'MXGC003I MXG STK MOUNT EXIT MONITORING
ENABLED' mean?
asmguy answer ==>
This is a message that indicates the environment
necessary to support the STK exit has been enabled in
MXGTMNT as a result of STKX=YES.
3. Do I need XMem at all?
Barry's answer ==>
XMEM is still needed to get the job-related fields in
the TYPETALO allocation records, at least for now, as
they are independent of the mount records. But I plan
to examine if I need to revise ASUMTAPE to use the new
exit-driven mount records to populate TYPETALO info,
once we've got the monitor working and I've got some
SMF data from a site with both IBM and HSC mounts.
b. Jun 24 update:
-For HSC, you may need to create exit SCSUX01 instead or
in addition to the SLSUX01 exit, depending on the HSC
interface your site uses. SCSUX01 is required if CSC is
used for remote access to the robot and VSMs, which may
be all that's available on your test system. SLSUX01 is
used for local access. Changing all SLSUX01 to SCSUX01
in ASMHSCEX and reassembling worked just fine, but we can
create a new SYSPARM option for ASMHSCEX that will create
both HSC and CSC exits in the same member.
c. Jun 28 update:
No errors have been reported by two sites successfully
using ML-34 and the new HSC exit. I'm awaiting test data
to update the ASUMTAPE program, but that won't happen
until late July, after some vacation time.
Thanks to "asmguy@mxg.com".
Thanks to Paul Naddeo, FiServ, USA.
Thanks to Jeff Holst, FiServ, USA.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 23.161 Comments said PDB.TYPE73OE dataset would be created, but
ANALFIOE the code created WORK.TYPE73OE; this change creates the
Jun 15, 2005 old style MACRO _LANFIOE PDB.TYPE73OE % so the default
dataset will be PDB.TYPE73OE, but also so that you could
change the DD or Dataset name using MACKEEP/IMACKEEP.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.160 New variables added to T102S106 dataset:
VMAC102 QWO4ADM2='OFF*SYSTEM*ADMIN ID2'
Jun 14, 2005 QWO4DFID='OFF*SYSTEM*DEFAULT*USER ID.'
QWO4OPR1='OFF*MVS*OPERATOR ID'
QWO4OPR2='OFF*MVS*OPERATOR ID2'
QWO4OZUS='OFF*ONLINE*ZPARM*USERID*MONITOR'
QWO4REGA='OFF*DDL REG*ART NAME'
QWO4REGC='OFF*DDL REG*TABLE OWNER'
QWO4REGO='OFF*DDL REG*ORT NAME'
QWO4SADM='OFF*INSTALL*SYSADMIN*USERID'
QWP4CONT='CONTRACT*CT*LONG*STORAGE*POOL?'
QWP4CRVW='DBA CAN*CREATE*VIEW-ALIAS*FOR OTHERS?'
QWP4DCFS='SMS*DATACLASS*FILE(DATA)*TABLESPACE'
QWP4DCIX='SMS*DATACLASS*INDEX*TABLESPACE'
QWP4DSMX='MAXIMUM*NUMBER OF*DATASETS'
QWP4EDBC='EDM*POOL*DBD*CACHE SIZE'
QWP4ESTC='EDM*POOL*STATEMENT*CACHE SIZE'
QWP4HINT='OPTIMIZATION*HINTS*ALLOWED?'
QWP4INTE='RTS*STATISTICS*TIMER*INTERVAL'
QWP4LEM ='MAXIMUM*NUMBER OF*LE TOKENS'
QWP4LRTH='UNCOMITD*READ*WARNING*THRESHOLD*(MINS)'
QWP4MDEG='MAX DEGREE*OF PARALLELISM'
QWP4MDSC='MIN SCALE*FOR DECIMAL*DIVISION*RESULT'
QWP4MNTY='MAINTAINED*TABLE*TYPE*BITMAP'
QWP4MXNC='MAX*CURSORS*OPEN PER*THREAD'
QWP4MXSP='MAX*ACTIVE*STORED PROCS*PER THREAD'
QWP4NPAG='NPAGES*THRESHOLD*FOR OPTIMIZER'
QWP4OJEH='OUTER*JOIN*PERFORMANCE*ENHANCEMENT?'
QWP4OZCI='ONLINE*ZPARM*CORRID*MONITOR'
QWP4OZTM='ONLINE*ZPARM*TIME*CHANGED'
QWP4OZTP='ONLINE*ZPARM*TYPE'
QWP4OZUS='ONLINE*ZPARM*USERID*MONITOR'
QWP4PDIX='PAD INDEXES BY DEFAULT?'
QWP4PKYU='ALLOW*UPDATE*PARTITIONING*KEY?'
QWP4RAC ='ROUTINE*AUTHORIZATION*CACHE SIZE'
QWP4RFSH='REFRESH*AGE'
QWP4SJRT='STAR*JOIN*RATIO'
QWP4SJTB='STAR*JOIN*THRESHOLD*(#TBLS/QB)'
QWP4SJXP='MAX SIZE*MEMORY POOL*FOR STARJOIN'
QWP4VDTY='DEVICE*TYPE FOR*TEMPORARY*DATA SETS'
QWP4WAIT='RETAINED*LOCK*TIMEOUT*MULTIPLIER'
QWP4EDMX='EDM POOL MAX DATA SPACE SIZE'
QWP4EDDS='EDM POOL DATA SPACE SIZE'
Thanks to Ron Alterman, Pacific Gas and Electric, USA.
Change 23.159 Yet another INPUT STATEMENT EXCEEDED RECORD for PSF SMF 6
VMAC6 record with SMF6LN6=24 (See Changes 23.091, 22.309).
Jun 13, 2005 The logic for SUBS=7 and SMF6LN6=24 was revised based on
the current SMF manual so that when SMF6LN6=24, there is
no longer an attempt to input SMF6PRTQ name, since there
cannot be roome for a name field when SMF6LN6=24.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 23.158 MXG RMF-like reports printed whole numbers for AVG RESP
ANALRMFR TIME and AVG IOSQ TIME but IBM reports now print one
Jun 13, 2005 decimal place, so MXG format was changed to match.
Thanks to Bob Anders, McMaster-Carr Supply Co., USA.
Change 23.157 SMF file might not have been found, depending on use of
BLDSMPDB SMFIN= argument, and whether FILENAME SMF existed. The
Jun 10, 2005 &SMF was changed to FILENAME SMF "&SMFIN"; to correct.
Thanks to Joe Key, BOC Gasses, ENGLAND
Thanks to Alex DaSilva, BOC Gasses, ENGLAND
Change 23.156 ASUMUOWT had incorrect syntax for _LMONTSK definition.
ASUMUOWT Two periods are required.
Jun 9, 2005
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 23.155 -First 23.05 only; incorrect syntax for default options in
ASMTAPEE "OPTIONS DC" statement, with a comma instead of plus.
Jun 9, 2005 -One site with ASM option CASE as their default had to use
ASM option COMPAT(NOCASE) because ASMTAPEE contains both
upper and lower case text, for readability.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Thanks to Shirley Fhng, Hong Kong Shanghai Bank, Hong Kong.
====== Changes thru 23.154 were in MXG 23.05 dated Jun 7, 2005=========
Change 23.154 First 23.05 only. Line 3138 extended into column 3138.
ASMTAPEE Comments clarified.
Jun 7, 2005
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 23.153 -Utility to read SMF to count IDs and Subtypes did not
VMXGGETM count ID=102 correctly, when run on ASCII platform; those
Jun 7, 2005 PIB4. and PIB2. should have been &PIB.4. and &PIB.2. so
that the code was transparently portable across all SAS
platforms. With PIB4. on ASCII, extremely large values
were created, which caused the ID=102 sub-logic to never
be executed, so all ID=102 had SUBTYPE=0 on ASCII.
-The realization that I had not checked ALL MXG members to
be transparently portable cause me to search and find
these members with either PIB instead of &PIB., or with
$ instead of $CHAR or $EBCDIC; all are now corrected:
ANALCM27 ANALCM29 ANALIPAC ANALSNAP CHANGES EXIMRACF
IDMSJRNL IDMSLO57 IDMSLOG JCLCIMS JCLPDBXX MAKECODE
TYPECIMS TYPEIMSB TYPEMONX TYPESLRI UDB2GTF UDEBLOCK
USMFRATE USTKVOL UTILDBLK UTILGEVB UTILGEVM UTILSPAC
VAXPDS VMACCMFV VMACCOMP VMACMONI VMXGGETM XADALOG
XGTFANAL XIBMFDP XLOGREC XMACACHE XMACVMXP XPAII
XTYPEMVT XTYPEVS1
Fortunately, all are pretty obscure, non-mainstream code,
or someone would have certainly noticed the incorrect
data values if they were exected on ASCII platforms.
Thanks to Alfred Holtz, Medco Health Solutions, USA.
Change 23.152 First MXG 23.05 Only. Debug PUTs at lines 2147 and 2148:
VMACTPMX PUT _N_= COL= FLENGTH= VARNAME= TPMFIELD=
Jun 7, 2005 TOKENID= TOKFIELD= TOKFIELD= $HEX16.;
printed unneeded lines of text on the SAS log.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 23.151 MXG 23.03-First 23.05. Debug PUT statement at line 1425
VMACNDM PUT _N_= COL= NDMPNODE= NDMSNODE= ;
Jun 6, 2005 printed unneeded lines of text on the SAS log.
Thanks to Michael Creech, Fidelity Information Systems, USA.
Thanks to David Kaplan, DTCC, USA.
Change 23.150 First MXG 23.05 only. VARIABLE NOT FOUND ERROR due to
ASUMMIPS typo: BY RPPTCLAS ... should be BY RPRTCLAS ....
Jun 6, 2005
Thanks to Pat Curren, Supervalu Inc, USA.
Change 23.149 Cosmetic. Examples of defining start and end of SHIFTs
IMACSHFT was clarified to make it easier for neophytes to change
Jun 6, 2005 the values to define their installation's shifts.
====== Changes thru 23.148 were in MXG 23.05 dated Jun 5, 2005=========
Change 23.148 General cleanup and revision to QA job stream:
ANALVM -Uninitialized xxxIFE and xxxIFA in RMFINTRV corrected.
QASAS -Specific reference to VMPDB removed in ANALVM, test of
TESTANAL ANALVM removed from TESTANAL as it was tested in TESTVM.
TRNDNTIN -QASAS code revised to PROC DELETE all LIBREFs.
TRNDNTLD -LENGTH/FORMAT added to MAXTIME/MINTIME for PRINTER data
TRNDPRTR set built in TRNDPRTR.
VMXGRMFI -TRNDNTIN,TRNDNTLD revised to use only &Pdddddd, and
Jun 5, 2005 eliminated the confusing _L macro definitions.
Thanks to Freddie Arie, Merrill Consultants, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.147 The response time buckets for the PDB.CICS dataset that
ASUMCICS is built by ASUMCICX from PDB.ASUMUOW dataset (which is
ASUMCICT the recommended way to measure CICS response with MRO),
ASUMCICX (or for the PDB.CICS dataset that can be built by the
VMXGINIT not-recommended ASUMCICS/ASUMCICT members from CICS
Jun 3, 2005 transaction segments in datasets CICSTRAN/MONITASK)
are defined as macro variables but they could not be
overridden without tailoring the ASUM member. Now, the
macro variables are externally defined in VMXGINIT, and
can be overridden in your //SYSIN DD *, before your
%INCLUDED SOURCLIB(ASUMCICx); statement. The default
values remain unchanged:
%LET SUCIVAL1=1;
%LET SUCIVAL2=2;
%LET SUCIVAL3=3;
%LET SUCIVAL4=4;
%LET SUCIVAL5=5;
%LET SUCIVAL6=8;
%LET SUCIVAL7=10;
%LET SUCIINTV=HOUR;
Thanks to Frank Lund, EDB, NORWAY.
Change 23.146 Support for new subtype 70 "FTP Server Security Section"
FORMATS adds these variables to TYP11970 dataset.
VMAC119 FSPSCCPL='CONTROL*CORRECTION*PROTECTION*LEVEL'
Jun 1, 2005 FSPSCIPH='CIPHER*SPECIFICATION'
FSPSDCPL='DATA*CORRECTION*PROTECTION*LEVEL'
FSPSLGME='LOGIN*METHOD'
FSPSMECH='PROTECTION*MECHANISM'
FSPSPRBF='NEGOTIATED*PROTECTION*BUFFER*SIZE'
FSPSPROT='PROTOCOL*LEVEL'
and new formats were created to decode four of them.
Thanks to Randy Shumate, LexisNexis, USA.
Change 23.145 The sample RMF III report had typos; ASISUPR should have
ZRBRPT3 been spelled ASISUCPR, and ASISCDOP should be ASISCDQP.
Jun 1, 2005
Thanks to Mike Obrien, Bank of America, USA.
Change 23.144 The "expanded length" format values introduced for TNG in
FORMATS Change 23.113 were most definitely non-trivial to code.
May 31, 2005 Initially, PROC FORMAT on ASCII SAS V9.1.3 ran without an
error, but values were not-found if a spanned-line had a
blank in column 72; those lines were then shifted right
so column 72 was non-blank, and values were then found.
But on z/OS V8.2, the new code failed to execute, with an
error 22-322 which underlined the equal sign on a line
that had 72 characters. Meanwhile, the new code executed
without error on z/OS 9.1.3, AND all values were found,
even for the spanned-text lines!
Noting that the V8.2 execution errors were on lines that
were exactly 72 positions, the code was revised to delete
a blank on the left of the '=' where possible, or the
line was split at the equal sign, and now the PROC FORMAT
executed without the 22-322 error on V8.2 on z/OS.
But now, values were not-found for spanned-text lines on
z/OS V8.2, while they were found on z/OS V9.1.3! This
problem had been opened with SAS Technical Support, and
their tests suggested that OPTIONS S2 might be involved,
as they could replicate the error when OPTIONS S2=71 was
used. Our real breakthrough was to compare execution on
z/OS V8.2 using %INCLUDE, versus copying the code into
the //SYSIN DD * and submitting the code; the instream
test had no errors AND properly found all values, while
the %INCLUDE-built format had values not-found!
More tests proved that the PROC FORMAT execution on z/OS
requires S2=72, while PROC FORMAT under ASCII requires
S2=0, so the end result is that member FORMATS now tests
its execution platform and sets S2=72 for PROC FORMAT on
EBDCIC, but sets OPTION S2=0 when executed on ASCII.
For z/OS, MXG's CONFIGV8 member has always had S2-72,
but two of the test sites were using SAS default S2=0,
which was known only in hindsight! MXG's CONFIGV9 for
z/OS has S2=0 (as extensively discussed in CHANGES; see
"Major Enhancements in MXG 22.08" and Newsletter 45),
but the AUTOEXEC for ASCII execution does not specify
either S= nor S2= option, so the S2=0 option on ASCII
accounts for my early tests not failing in execution.
This problem is still open at SAS, to understand what
is the righteous way to code formats that have values
that won't fit on one line, but the revised FORMATS
member now appears to work on all platforms with the
internal setting of S2 above.
Change 23.143 IMPLEX subtype 4 record's IMPLEXRT dataset did not have
VMACMPLX all of the possible variables kept, and the deaccumulate
May 31, 2005 logic was incomplete, causing zero observations in the
PDB.IMPLEXRT dataset; groups of the new variables will be
missing, as they are only input for specific values of
the EXMFRTYP variable. Some of the MXG tests for other
DIF()'d variables that were missing the "LT 0" for their
final test are now corrected.
Thanks to David Bixler, FISERV, USA.
Change 23.142 Support for Oce's Prisma Print log file creates these
EXPR1000 forty-five new datasets:
EXPR1010
EXPR1011 DDDDDD MXG MXG
EXPR1012 DATASET DATASET DATASET
EXPR1020 SUFFIX NAME LABEL
EXPR1030
EXPR1031 PR1000 PRPR1000 PR1000:INPUT FILTER
EXPR1032 *PR1010 PRPR1010 PR1010:PRINT JOB MANAGER JOB
EXPR1040 *PR1011 PRPR1011 PR1011:PRINT JOB MANAGER FILE
EXPR1041 *PR1012 PRPR1012 PR1012:ODS
EXPR1042 *PR1020 PRPR1020 PR1020:UI-MANAGER
EXPR1043 *PR1030 PRPR1030 PR1030:SPOOL PARAMETER READ
EXPR1110 *PR1031 PRPR1031 PR1031:JOB FINISHED OR DELETED
EXPR1120 *PR1032 PRPR1032 PR1032:USER DATA
EXPR1130 *PR1040 PRPR1040 PR1040:SNIPDS BACKEND
EXPR1140 *PR1041 PRPR1041 PR1041:BINS USED
EXPR1200 *PR1042 PRPR1042 PR1042:INPUT BIN USED
EXPR1201 *PR1043 PRPR1043 PR1043:OUTPUT BIN USED
EXPR1202 *PR1110 PRPR1110 PR1110:HOST DOWNLOADED
EXPR1400 PR1120 PRPR1120 PR1120:LP TRANSMISSION
EXPR1410 PR1130 PRPR1130 PR1130:HOT DIRECTORY PRINT JOB
EXPR1411 PR1140 PRPR1140 PR1140:LU 6.2 PRINT JOB
EXPR1412 PR1200 PRPR1200 PR1200:XFILTER LCDS REPORT INFO
EXPR1413 PR1201 PRPR1201 PR1201:XFILTER LCDS ADDITIONAL
EXPR1420 PR1202 PRPR1202 PR1202:XFILTER LCDS MORE ADDITI
EXPR1421 PR1400 PRPR1400 PR1400:B1 START SUBSYSTEM
EXPR1422 PR1410 PRPR1410 PR1410:E1 VOLUME HANDLING
EXPR1423 PR1411 PRPR1411 PR1411:F5 HDR1 HANDLING
EXPR1424 PR1412 PRPR1412 PR1412:F6 HDR2 HANDLING
EXPR1425 PR1413 PRPR1413 PR1413:F7 HDR3 HANDLING
EXPR1426 PR1420 PRPR1420 PR1420:N5 PARAMETER SECTION 1
EXPR1430 PR1421 PRPR1421 PR1421:N6 PARAMETER SECTION 2
EXPR1451 PR1422 PRPR1422 PR1422:N7 PARAMETER SECTION 3
EXPR1452 PR1423 PRPR1423 PR1423:P4 PARAMETER SECTION 4
EXPR1453 PR1424 PRPR1424 PR1424:P5 PARAMETER SECTION 5
EXPR1454 PR1425 PRPR1425 PR1425:P6 PARAMETER SECTION 6
EXPR1455 PR1426 PRPR1426 PR1426:P7 PARAMETER SECTION 7
EXPR1456 PR1430 PRPR1430 PR1430:PRINTING RUN
EXPR1457 PR1451 PRPR1451 PR1451:U1 USER SPECIFIC
EXPR1458 PR1452 PRPR1452 PR1452:U2 USER SPECIFIC
EXPR1459 PR1453 PRPR1453 PR1453:U3 USER SPECIFIC
EXPR1600 PR1454 PRPR1454 PR1454:U4 USER SPECIFIC
EXPR1601 PR1455 PRPR1455 PR1455:U5 USER SPECIFIC
EXPR1602 PR1456 PRPR1456 PR1456:U6 USER SPECIFIC
EXPR1603 PR1457 PRPR1457 PR1457:U7 USER SPECIFIC
FORMATS PR1458 PRPR1458 PR1458:U8 USER SPECIFIC
IMACPRPR PR1459 PRPR1459 PR1459:U9 USER SPECIFIC
TYPEPRPR PR1600 PRPR1600 PR1600:FTP BACKEND
TYPSPRPR *PR1601 PRPR1601 PR1601:FTP JOB FINISHED
VMACPRPR *PR1602 PRPR1602 PR1602:FTP TRANSMISSION PRINT FIN
VMXGINIT *PR1603 PRPR1603 PR1603:FTP TRANSMISSION GEN OCT
May 30, 2005 All of the datasets are created, but only those fifteen
asterisk-flagged datases have been decoded and validated
with test data records; all others have only one variable
kept. As there are multiple records for a single job, it
may be necessary to post-process these data to combine to
get job totals, so this is preliminary support.
Thanks to Krista Neven, KBC Bankverzekeringsholding, BELGIUM.
Change 23.141 Enhancement adds MIPFACTR= as a parameter to convert MSU
GRAFWRKX to MIPS, added graph of MIPS used, supported LPARSHAR as
May 30, 2005 a percentage to fix the LPAR percentages.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.140 DB2 Version 8.1 Support: More IBM INCOMPATIBLE changes.
VMACDB2 Errors INVALID DATA FOR QLACCPUR, QLACCPnt, causing
May 30, 2005 INVALID DATA FOR QLACCPUL, QLACCPUR, QLACDBAT messages.
Jul 17, 2005 Change 23.111 discovered that DB2 8.1 sets QPACLEN=zero
to indicate that the real QPACLEN is in the first 2 bytes
at OFFQPAC, but when a QLACLEN=0 segment caused errors,
I realized this "feature" apparently can apply to all DB2
segments, so VMACDB2 was revised to test each segment for
LENxxxx=0 and NRxxxx non-zero, with this inserted code
OFFxxxx=OFFxxxx
IF LENxxxx EQ 0 AND NRxxxx GT 0 THEN DO;
INPUT @OFFxxxx LENxxxx &PIB.2. @;
OFFxxxx=OFFxxxx+2;
LENxxxx=LENxxxx+2; <<= See Change 23.182
END;
to pick up the new LEN and modify the OFFSET.
-Note: The LENQLAC=0 SMF records did NOT produce that same
INVALID DATA message when those records were read by SAS
under Windows; instead, the misaligned RB8. fields were
input as very large negative numbers, but there was no
error message, and I had not used PROC MEANS to see that
that invalid values existed in the output dataset. This
is one of few real differences in executing MXG on ASCII
platforms; ASCII is more tolerant of bad data than z/OS!
-Change 23.181 updated this text and is required for V8.1.
Thanks to Ingvar Rosenberg, SEB, SWEDEN.
Thanks to Glenn Lundgren, SEB, SWEDEN.
Change 23.139 Support for CyberFusion user SMF record has been revised,
FORMATS now that DSECTS that match the data records have been
VMACCYFU received. All of the bit mapped fields are now decoded
May 29, 2005 by 43 new MGCYFxx formats, although there are a few cases
where the hex value is not described in the DSECT EQU's,
so some final tweaking will be required.
Thanks to Robin Murray, ManuLife, CANADA.
Change 23.138 Cosmetic. Labels for SMF88SC1/2/3 are clarified to read:
ADOC88 SMF88SC1='TYPE 1*COMPLETIONS'
VMAC88 SMF88SC2='TYPE 2*COMPLETIONS'
May 30, 2005 SMF88SC3='TYPE 3*COMPLETIONS'
and the explanation from the SMF manual Section 9.1.1.2
was added in the ADOC88 member for those three variables.
Thanks to Helmut Rose, COM Software, GERMANY.
Change 23.137 Support for CA SYSVIEW CICS XPFCMCR DSECT user SMF data
EXSYSVCI record creates these new datasets:
EXSYSVPC -Subtype 17: Documented in XPFCMRC, creates these data:
EXSYSVFC dataset dddddd description
EXSYSVTS SYSVCICS SYSVCI SYSVIEW CICS PERFORMANCE (CICSTRAN)
EXSYSVIN SYSVPROG SYSVPC SYSVIEW CICS PROGRAMS
IMACSYSV SYSVFILE SYSVFC SYSVIEW CICS FILES
TYPESYSV SYSVTEMP SYSVTS SYSVIEW CICS TEMP STORAGE
TYPSSYSV The SYSVCICS dataset is the same in structure as CICSTRAN
VMACSYSV and almost all of the variable names are also the same,
VMXGINIT although not all of the (newer) CICSTRAN fields exist in
May 29, 2005 the SYSVCICS dataset, and there are a few CICSTRAN vars
that are output instead in SYSVPROG,SYSVFILE or SYSVTEMP.
There are additional segments in the SYSVIEW subtype=17
record, but they were not populated in the test data, so
only the subtypes that could be validated were decoded in
this initial support. If data from the other segments is
really needed, updates will be made to this support.
-Subtype 23: Documented in XPFCSDCR, creates this data:
dataset dddddd description
SYSVINTV SYSVIN SYSVIEW SYSTEM DATA COLL INTERVAL
In a radical departure from previous MXG code, the names
of the variables in SYSVINTV are longer than 8-bytes. The
DSECT names are repeated inside structured names, and to
compact the names and avoid duplicates would have taken
more time that it was worth, at least for this first pass
as support for the SYSVIEW product, and especially for
this SYSVINT dataset, neither of which I expect will have
very much usage. I think long names, in general, are more
confusing than useful, so if it turns out that SYSVINTV
is of significant value, I'll revisit and compact the MXG
variable names.
- The DOCVER member will still only show the first eight
characters of the variable names, as that format is
limited so the format and label fit on one line. You
can always use a PROC CONTENTS to see the full name of
each variable in SYSINTV.
Thanks to James D. Lieser, United Health Group, USA.
Change 23.136 -Updates to BMC CMF "240" USER SMF record:
VMACCMF -New variables in CMF27C93 and CMF27CSC for 2105's:
May 26, 2005 C276RCRM='RECORD*CACHE*READ*MISSES'
C276LRED='LOC RCD*DMN/REC*CA*WRITES'
C2795AID='DEVICE ADAPTER ID'
C2795HDD='NO. OF HDD'S IN RAID RANK'
C2795HSS='HDD sector size'
C2795NVS='NVS space allocation'
C2795RFL='FLAGS BYTE, THUS:'
C2795RID='RAID RANK ID'
C2795RMR='record mode read requests'
C2795RRQ='RAID rank read requests'
C2795RRT='RAID RANK READ RESPONSE TIME'
C2795RSV='LOWER*INTERFACE*I/O*RESPONSE'
C2795RTY='RAID RANK TYPE, THUS:'
C2795SR ='RAID rank FB sectors read'
C2795SW ='RAID rank FB sectors written'
C2795TSP='TRACKS TRANSFERRED TO PPRC VO'
C2795WRQ='RAID rank write requests'
C2795WRT='RAID RANK WRITE RESPONSE TIME'
C2795XCW='XRC or CC contaminated writes'
C2795XSF='XRC or CC sidefile read requests'
C279XRSV='LOWER*INTERFACE*I/O*RESPONSE'
Thanks to John Kington, Convergys, USA.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 23.135 -Top Secret Version 5.2 and 5.3 are now supported, simply
VMAC80A by expanding the test for RACFVRSN to include 52x,53x.
May 26, 2005 -Top Secret creates its own user record with SMF80DTP=114,
but that record is really in SMF 80 format, so the user
SMF record can be processed with MXG TYPE80A code, using:
//SMF DD
//SYSIN DD *
%LET MACFILE= %QUOTE ( IF ID=231 THEN ID=80; ) ;
%INCLUDE SOURCLIB(TYPS80A);
to change the (example) ID=231 records back to ID=80 so
they are processed by TYPE80 code.
-The SMF80DTP=114 record is not yet decoded, so the above
code will only output the RACF header variables into the
TYPE80CM dataset; when documentation from CA is received,
the DTP=114 record will be decoded.
Thanks to Brent Turner, CitiGroup, USA.
Change 23.134 -RACF Extended TP2=301 with TOK80LN2=0 was not expected,
VMAC80A so it generated an error message on the SAS log stating
May 26, 2005 the record was deleted, but now, a valid TP2=301 segment
only TOK80FLG and TOKSUBSY='OMVS' is created, for NOOMVS
for RACFEVNT=13:ALTUSER record, although the record is
still does not agree with the IBM documentation:
MXG TOK80LN2 is byte 11 of the TP2=310 segment, which
is documented:
Byte 11: Length of subkeyword; 0 if byte 1 bit 1 is set
==> but byte 1 bit 1 is not set.
Byte 1 bit 4 "keyword has no subfield"
==> should be set, but it isn't.
-However, the documentation did allow the creation of two
new variables in datasets TYPE8009,8010,8012,8013:
KW301IGN='KEYWORD*IGNORED*INSUFFIENT*AUTHORITY?'
KW301DEL='SEGMENT*DELETED*VIA A*NOXXX*KEYWORD?'
so that you could detect the NOOMVS event.
Thanks to Erling Andersen, SMT, DENMARK.
Change 23.133 Support for Iway Software's IWAY (formerly EDA/SQL) SMF
EXIWAY1 record, creates these four datasets:
EXIWAY2 DDDDDD MXG MXG
EXIWAY4 DATASET DATASET DATASET
EXIWAY5 SUFFIX NAME LABEL
FORMATS
IMACIWAY IWAY1 IWAY01 IWAY SERVER START OF TASK
TYPEIWAY IWAY2 IWAY02 IWAY SERVER END TASK
TYPSIWAY IWAY4 IWAY04 IWAY SERVER BEGIN QUERY
VMACIWAY IWAY5 IWAY05 IWAY SERVER END QUERY
VMXGINIT
May 26, 2005
Thanks to Luis Mendoza, ABNAMRO, USA.
Change 23.132 Support for z/OS 1.7 (COMPATIBLE) and APAR OA10556.
VMAC1415 -TYPE70 dataset
VMAC7072 -New MACHTIME='MACHINE*TOD*DATETIME*STAMP' is created by
VMAC88 addition of new SMF70HOF='HYPERVISOR*DATETIME*OFFSET' to
VMAC94 SYNCTIME (SMF70IET + SMF70LGO). MACHTIME will be the
VMAC74 true GMT datetime value, independent of the IPL time and
May 21, 2005 site GMT offsets, and will be used by SCRT to know the
Oct 5, 2005 true time for IBM bills, since it is possible to IPL
Dec 12, 2005 with repeated/future/past datetimes, causing double
Oct 1, 2012 accounting for MSUs, etc. However, this value has not
yet been validated with SMF70LGO populated.
-SMF70HWM='CPC*PHYSICAL*MODEL*IDENTIFIER' is created, and
STFBIT04='SMF70MDL*MODEL*CAPACITY*ONLY?' flag, if true,
then SMF70MDL contains only the CPC MODEL CAPACITY, and
SMF70HWM has the CPC PHYSICAL MODEL IDENTIFIER.
-STFBIT03='SMF70LAC*NO LONGER*INCLUDES*CPU WAIT?'
-SMF70Q00='PERCENT*WHEN*IN READY*LE N CP-S' thru variable
SMF70Q12='PERCENT*WHEN*IN READY*LE N+12 CP-S' now track
the PCTRDYWT, but based on IN-READY greater than the
number of CP engines.
-TYPE70PR dataset:
-LPARCLND='CAPACITY*LIMIT*NOT*DEFINED' is now reserved.
so the new label (new in Sep 2012, MXG 30.07) reads
LPARCLND='RESERVED*FIELD*SINCE*Z/OS 1.7' and the value
is now a blank instead of either Y or N.
-Note that if LPARWTFD='Y' (WAIT TIME FIELD DEFINED?) is
true, then LPARCPUX (SMF70BND) contains the maximum
logical processors defined as shown at the HMC, starting
with z900 processors. The Active Logical Processors
have an online time SMF70ONT greater than zero, which is
how/why MXG now counts NRCPUS.
-TYPE70Y2 Crypto dataset, new variables:
R702NH2B='SHA-256*DATA*BYTES*HASH'
R702NH2C='SHA-256*CALLS*TO*HASH'
R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH'
-TYPE74CA dataset, new variable:
R745DCCU='CONFIGURED*CONTROL*UNIT*TYPE'
-TYPE791/TYPE792: (Note added Dec 12, 2005):
-MXG used variable name suffix TIFE (Eligible CPU) but
the IBM field name is TIFC, and my choice caused some
confusion, so the IBM Field name of TIFC is now used.
-R791NFFI/R792NFFI normalization factor was added and
is used to normalize R791TIFA/R792TIFA times back to
CP seconds.
-TYPE88 dataset, new variables:
SMF88EAF='IXLOGR*STAGING*ASYNC BUFFER*FULL'
SMF88ERS='RESERVED*WRONG NAME' SMF88EDO in manual,
but that field name already exists. Investigating.
-TYPE94 dataset, new variables:
S9SDEMN1='SECURE*DATA*ERASE*MOUNTS*DC 1'
S9SDEMN2='SECURE*DATA*ERASE*MOUNTS*DC 2'
S94XLCSG='VTC 0*WRITE*PROTECT*MODE'
S94XLCSH='VTC 1*WRITE*PROTECT*MODE'
S94XLCSI='VTC 2*WRITE*PROTECT*MODE'
S94XLCSJ='VTC 3*WRITE*PROTECT*MODE'
S94XLCSK='VTC 4*WRITE*PROTECT*MODE'
S94XLCSL='VTC 5*WRITE*PROTECT*MODE'
S94XLCSM='VTC 6*WRITE*PROTECT*MODE'
S94XLCSN='VTC 7*WRITE*PROTECT*MODE'
-TYPE99U7 dataset Subtype 7 new variable
SM997SCS='SUB*CHANNEL*SET='
-TYPE99UA dataset Subtype 10 - need test data to decode
-TYPE1415 dataset, new flag variable ('Y',' '):
SMF14LGE='DSNTYPE*LARGE*FORMAT?'
Note that if SMF14LGE='Y', the value in variable TTRN
will contain 'TTTR', and if EXTNDSEQ='Y' the value in
TTRN will contain 'TTTT', the total number of tracks
used across all volumes.
Oct 5, 2005: Original Reserved Change Number replaced.
Change 23.131 Support for DB2 IFCID=313 creates T102S313 dataset, with
FORMATS dataset labeled 'CHECKPOING LONG RUNNING UR-S'.
VMAC102
May 24, 2005
Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM
Change 23.130 To update the ITRM data dictionary for MXG datasets, all
IMACACCT of my code and datasets created by that code are examined
IMACICD6 and numerous corrections were made as a result of that
IMACICMR process. Most are spelling errors, but many cause the
RMFINTRV variable to be not-kept, or incorrectly labeled, etc.
VMAC110 VMAC110: FILADDCN changed to FCADDCN in CICSRFDI keep.
VMAC30 DSxACT/TCT/TDE/TWT for DSH/DSI/DSJ/DSK FORMATed
VMAC6 DSGTOTMT/DS2/DS3/DS4 formatted.
VMAC7072 DSGTOTWL dual use, now DSGTOTWT kept in CICDS
VMAC80A instead of DSGTOTWL, DGTOTWT labeled.
VMACDB2 VMACICE: SRCEOD changed to SRCEOE in ICEBR8SN keep.
VMACICE IMACICD6: $EBCDUC8. changed to $EBCDIC8.
VMACTPMX IMACICMR: CMDDB2CT formatted TIME12.2.
VMACVMXA IMACACCT: IDMSCPTM formatted TIME12.2. (in comments).
May 24, 2005 VMAC80A: KW24ASTE,KW24KERB kept, labeled in TYPE8024.
CLAS26NM,RES25MEx,RES25TEx labeled in 25/26.
VMACTPMX: TPMUSERC,TPMXPLEX labeled.
VMAC30: SMF30MRD,SMF30MRI formatted TIME12.2
VMAC6: SMF6FTL, leading asterisk removed in label
VMAC7072: IFAWAITM, R723IFAT, R723IFCT formatted TIME12.2
MXGCIN, NRPHYCPS, R723NFFI labeled.
Also NRPHYCPS now labeled in ASUMCEC,ASUM70PR.
VMACDB2: QISESTMT kept in DB2STATS
RMFINTRV: PCTIFABY labeled.
VMACVMXA: APLSDTST labeled.
USAPLxxx temporary variables dropped in
VXAPLCMS/SLM/SLN/SLP/SLO datasets
PCT-prefixed VXAPLSLP/SLO and TICKS labeled.
MRHDRRC labeled
BYTOA and BYFRA are MGBYTES formatted, LENGTH 8
and BFFRA was removed from LENGTH 8.
Stray text in label of PT4ID corrected.
IFINOCWR/IFOUOCWR are kept, logic corrected.
New variables in VXAPLSRV labeled, kept.
Temp variable OLDTODON is dropped from VXBYUSR.
Thanks to Chris Weston, SAS ITRM Development Cary, USA.
Change 23.129 Cosmetic. Label for IPMIGR2 should have been SECONDARY
VMACIPAC as IMIGR1 is 'PRIMARY*MIGRATION*CLASS*NAME'.
May 23, 2005
Thanks to Tom Parquette, AXA Technology Services, USA.
Change 23.128 New z/VM 5.1 1.19 record was misdocumented by IBM, which
VMACVMXA caused ERROR* PROBABLE DATA LOSS DUE TO MONWRITE FAILURE.
May 23, 2005 Correct MRHDRLEN=368 was doc'd as 365, and two bytes at
offset 42 were not listed in the length column, but MXG
was also not guilt-free, as I had guessed wrong at where
those two undocumented bytes were located. Dataset
VXMTRQDC is now corrected.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 23.127 A semi-colon at the end of a %MACRO invocation caused a
VMXGFOR "180" syntax error, and now I know that it is NOT true
May 24, 2005 that every SAS statement ends with a semi-colon!
While MXG Change 20.327 removed all invocations of the
now-unneeded %VMXGFOR macro from all MXG PROC SORTs,
a site with an old PROC SORT DATA=A OUT=B %VMXGFOR; in
their report program failed with "FORCE" underlined.
%VMXGFOR was only needed because Version 5 of SAS did
not support the FORCE keyword; that macro generates
a blank for V5 and "FORCE" with V6 or later.
It turns out the culprit was the addition of the new
%VMXGVERS(23.05,VMXGFOR);
statement after the %MEND; statement in the VMXGFOR
member, added by Change 23.005. It also turns out that
it was that final semicolon after %VMXGVERS() that caused
the error, in this reply from SAS Technical Support:
"The problem is the semi-colons in the autocall source
files that follow the macro call. These semi-colons are
superfluous for the macro call, but not harmless when
contained in an autocall source file. When a macro call
is determined to be the first reference to an autocall
macro, the file containing the autocall macro definition
is processed until the end-of-file is reached and then
the macro is called. In this instance the macro
definition is read and processed. This consumes the
autocall source file up to and including the semi-colon
following the %MEND. Then the following macro call
(i.e., to %VMXGVERS) in the autocall source file is
processed. This consums the autocall source file up to
and including the right parenthesis, leaving the
semi-colon. The dangling semi-colon is then inserted
into the source stream (as model text) and then a call is
placed to the autocall macro that started the process.
This behavior is present in versions 6 thru version 9."
So, a final semi-colon has NEVER been needed after the
invocation of a %MACRO, and none of the examples in the
SAS Macro Manual (yes, we Read The Fine Manual!) show a
semi-colon after the invocation. For example, you can
use %ANALDB2R() and the report program executes!
Fortunately, it appears that only the %VMXGFOR member is
vulnerable, because it inserts text into a SAS statement.
All other VMXGxxxx members that have %VMXGVERS added are
"standalone" executions, and the extra semi-colon, even
though those members are autocalled, is superfluous.
But now I know what caused this strange error, and have
removed the trailing semicolon from the %VMXGVERS call
in the (still-archaic) VMXGFOR autocalled member.
Thanks to Matt Feeney, Defence Department, AUSTRALIA.
Change 23.126 -Dataset PDB.RMFMSUSE contains both Service and Reporting
ASUMMIPS Class obs, but variable RPRTCLAS was not kept, so you
May 18, 2005 couldn't identify which class the observation was for.
May 23, 2005 Now, RPRTCLAS is kept in PDB.RMFSUSE.
May 24, 2005 -Member IMACKEEP was not included, so you could not use
the MACKEEP= to tailor the ASUMMIPS execution. As an
example that you can now use:
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _RMFOUT RMFMSUSE %
MACRO _MIPSMSU
IF SYSTEM='TREX' THEN MIPSFACT=6.7;
ELSE MIPSFACT=5.7;
%
);
%INCLUDE SOURCLIB(ASUMMIPS);
_RMFMIPS;
_SMFMIPS
changes the output from PDB.RMFMSUSE to WORK.RMFMSUSE and
changes the MIPSFACT (MIPS per MSU) depending on SYSTEM.
-The default PROC PRINT for RMFMSUSE is now sorted by the
RPRTCLAS variable, so if you have both Reporting Class &
Service Class data, you will get separate reports. Since
they will overlap, having a single report was deceptive.
-The default PROC PRINT for SMFMSUSE did not use _SMFOUT,
causing an error if _SMFOUT was redefined.
Thanks to Dan Case, Mayo Foundation, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 23.125 HSC V6 changed the STCLMU (subtype 4) SMF record, now STK
VMACSTC PTF L1H12EW documents the new record, but that PTF also
May 17, 2005 changes the record again, so records written with HSC V6
without the PTF will produce strange results in STCLMU.
-And, of course, no version flag is in the STK record, so
the (archaic) logic to test the Record Length is required
to determine if this is a valid pre-V6 record, a short
pre-V6 record (fixed by a prior PTF), an invalid HSC V6.0
prior to the PTF, or a valid HSC V6.0 record after PTF.
-And there are undocumented bytes in the record, as well,
between offsets 11 and 16 (decimal).
Thanks to Dean A. Ruhle, JC Penney Co., Inc, USA.
Thanks to Michael Gresham, JC Penney Co., Inc, USA.
Thanks to David M. Cole, STK, USA.
Change 23.124 -Duplicate SMF type 30 interval records caused duplicate
VMAC30 observations in PDB.SMFINTRV because the revisions in MXG
BUILD005 Change 22.320 removed the NODUP option from the SORT.
May 17, 2005 This change restores the NODUP option.
-The _BTY30UV macro in VMAC30 was revised so the first
five variables match the sort order used in BUILDPDB:
MACRO _BTY30UV READTIME JOB JESNR INITTIME INTBTIME
MULTIDD DESCENDING EXTRADD
just for consistency, even though the PDB.SMFINTRV that
can be created with TYPS30 (or with the _STY30UV macro
invocation) is NOT the same PDB.SMFINTRV dataset that is
created by BUILDPDB:
-The BUILDPDB-built PDB.SMFINTRV has consolidated all of
the "MULTIDD" observations into a single observation.
-The TYPS30/_STY30UV-built PDB.SMFINTRV still contains
all of the additional and confusing "MULTIDD" obs.
Thanks to Joan Nielsen, (i)Structure, USA.
Change 23.123 Variables CPUIFATM and CPUIFETM (total) are added to the
VMXGRMFI PDB.RMFINTRV dataset, and individual workload variables
May 17, 2005 (like BATIFA, BATIFE, etc) with IFA/IFE CPU times added.
Oct 19, 2005: See Change 23.265; 23.123 was incomplete.
Thanks to Andre Baltimore, Unigroup, Inc, USA.
Change 23.122 Datasets PDB.TYPE70LP and PDB.ASUMTAPE were not in the
WEEKBLD default WEEKBLD member, but as they are created in the
WEEKBLDD JCLPDBx daily job examples, they are now added to the
WEEKBLDT weekly example job.
May 17, 2005
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
Change 23.121 ERROR: BY VARIABLES NOT SORTED ON DATASET WORK.BOTHCEC is
VMXG70PR corrected by an insertion of a PROC SORT to ensure the
May 16, 2005 order is correct; values for SHIFT were the culprit.
Thanks to Tony Curry, BMC, USA.
Change 23.120 Support for ESS GEPARMKY=004Dx creates ESSMAIL2 variable
IMAC6ESS in TYPE6 dataset when IMAC6ESS is enabled.
VMAC6
May 13, 2005
Thanks to Engelbert Smets, Provinzial, GERMANY.
Change 23.119 Change 23.025 was not tested with TRENDIN data, and the
UTILCONT semicolon after &PDBOUT..ASUMSIZE should not have been
May 13, 2005 there, since the macro code is still part of the SET.
Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.
Change 23.118 Processing CICS Journal Records (SUBTYPE=0) didn't output
VMAC110 the last record. The test was changed to
May 12, 2005 IF LOC+GLRHLEN-1 LE LENGTH THEN GOTO JOUR5202;
Thanks to Helmut Roese, COM Software, USA.
Change 23.117 If you built your own program, and had _CDE40 before the
VMAC40 _CDE30 macro, you got ERROR 48-59 with the below two
May 12, 2005 notes:
WARNING: VARIABLE PROGRAM HAS ALREADY BEEN DEFINED AS NUMERIC
ERROR 48-59: THE INFORMAT EBCDIC WAS NOT FOUND OR COULD NOT BE LOADED
because MXG didn't fully protect the variable PROGRAM.
-Per the text of Change 20.243, PROGRAM was added to the
ARRAY statement for character variables in VMAC40 so that
the _CDE40 could be located prior to the _CDE30.
-This is really a bummer, as PROGRAM is not even input in
SMF 40 records, but the code in VMAC40 makes a call on
VMACEXC2, which has a PUT statement in case of an error
in the decoding EXCP segments, and when the PUT was the
first instance of variable PROGRAM, SAS made it numeric
which then spawned numerous other errors when it was
referenced as a character variable.
Thanks to Michael S. Noud, IRS, USA.
Change 23.116 Very bad values for some data fields in TYPE 74 subtype 5
VMAC74 records for HDS on their Tagmastore USP, like negative
May 12, 2005 values for SCTO (R745DTC). Under investigation with HDS.
Reporting site now has a microcode fix which is believed
to correct the error; no fix number at press time.
Change 23.115 The default OPTIONS and OPTIONS2 did not agree with the
ASMTAPEE documentation in Change 23.030, and the internal comments
May 11, 2005 about default options were inconsistent. The comments
May 29, 2005 were clarified, and the default options in OPTIONS and
OPTIONS2 are set as documented, for IBM VTS Systems.
As noted, if you have STC VTS, you must remove DOMXIT to
disable the IBM Volume Mount Exit, because we still have
not been able to find an equivalent Exit in STK's HSC,
but we're still working on that enhancement.
Updated: Jul, 2005. See Change 23.162/23.177/23.230.
-Line 3139 extended into column 72, making it look like a
continuation.
Thanks to Shane Dowling, DEWR, AUSTRALIA.
Change 23.114 DCOLLECT dataset DCOLCLUS, VSAM Dataset Info, was not
DAILYDSN used in the original "Daily Dataset Billing" (JCLDAYDS),
May 11, 2005 but has been added so that it will be there if needed.
Thanks to Chairat Tiajanpan, KCS, Thailand.
Change 23.113 -Zero obs with a Solaris cube. The _UTNGCNT array sizer
ADOCTNG only worked for NT data, so the INSTREAM code was not
EXTNT128 generated due to a missing OUTPUT statement, and the new
EXTNT129 MIB-2 UNKNOWN object was processed last, causing 0 obs.
EXTNT130 New So028 dataset supports the MIB-2 object and new field
EXTSO028 added to existing So027 dataset is now supported.
FORMATS -Cubes with data from multiple days had only last day's
IMACTNG data output. Two tests that previously read
TYPETNG IF NRPAREN GT 1 AND NRSYSTMS GT 1 THEN DO;
VMACTNG appear to be the culprit, and by commenting out to be
VMXGINIT IF NRPAREN GT 1 /* AND NRSYSTMS GT 1 */ THEN DO;
May 10, 2005 data from all days was output. That heuristic was needed
May 23, 2005 early on in TNG support, but I think subsequent redesign
May 28, 2005 eliminated the need for that part of the test to invoke
outputting, BUT PLEASE VALIDATE THAT YOU GET DATA FROM
ALL OF THE SYSTEMS, AND ALL OF THE DAYS IN YOUR INPUT!!
-New NT platform names of NTP500I and WNS502I were added
to the MACRO _NTPLAT to eliminate UNKNOWN PLATFORM msgs.
-Support for new Objects for NT: RAS PORT, MICROSOFT
GATHERER, and MICROSOFT SEARCH.
-May 28: $MGTNGVN Format was completely revised, as two
Solaris metrics were identical in first forty characters:
'Interface Traffic (Lifetime) Collisions %'
'Interface Traffic (Lifetime) Collisions'
causing INSTANCES EXCEEDED error messages when tested.
That %MGTNGVN format, used to lookup the concatenation of
Platform abbreviation, Object Name, and Metric Name, had
only allowed 40 positions for metric name. To eliminate
future duplicate exposures, all TNG cubes were read to
find the maximum metric name of 58 chars, so the format
was expanded to allow 64 char metric names, but with the
2-char platform abbreviation and the 20-character object
name, the "expanded length format" now had DEFAULT=86 in
its VALUE statement. But with only 72 positions of MXG
input text, some of the value definitions had to be split
into two lines, a nasty but necessary implementation.
But then the fun began. Read Change 23.144 for solution.
Since more than 40 bytes of METRIC name are now being
looked-up in the format, data for all past test cubes
was read to find all metrics longer than 40 bytes, and
those 55's format data-values were revised so they would
be found in the new format; the longest was 58 bytes.
But if I missed one, it will show up as an observation
in the UNKNOWN dataset, so please check your SAS log to
make sure I found them all.
Thanks to Michael L. Kynch, International Paper, USA.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 23.112 Change 23.070 reset STARTIME for 58,59, and 01 seconds,
VSETZERO but that didn't protect delays beyond 1 second; new data
May 9, 2005 shows that 70 and 72 records with seconds 02 are created;
in fact, the SMFTIME of the 72 subtype 4 was 4.5 seconds
after the interval pop, and that subtype 4 had 00 seconds
for its STARTIME! So the test in VSETZERO is now revised
to set seconds 58 thru 05 back to seconds 00. The main
impact without this change was that the PDB.ASUMCEC had
had two observations, one with 01 seconds, one with 02
seconds as their STARTIME.
Thanks to Diane Eppestine, SBC, USA.
Change 23.111 Support for DB2 V8.1 DB2ACCTP Package Data now validated.
VMACDB2 Change 23.098 guessed wrong, but IBM didn't help; in the
VMACDB2H new IFCID=239 structure, the LENQPAC is zero! But, in
May 9, 2005 a very weak defense of their redesign, there is a very
obscure note that says it is now "legal" to have a DB2
data segment with Length=zero, and it now means: read the
first two bytes at the offset, and use that as the length
of the data segment! So with a hex dump of one of the
new records, the code is now corrected and DB2ACCTP will
be valid for DB2 V8.1 or earlier versions as well.
-There was also an extraneous PUT QWHSRELN= in VMACDB2H
added by Change 23.098, only for DB2 V8.1, but lots of
messages would have been printed, if you had DB2 V8.1,
since it put that message for EVERY SMF 100/101 record!
It was removed by this change.
-Note that this change is required for DB2 V8.1 if there
are ANY package segments in your DB2 records; prior notes
that earlier versions of MXG support DB2 V8.1 are wrong.
Thanks to Steve Olmstead, Thomson, USA.
Change 23.110 Cosmetic. Variable ESMFFAVG was listed in the KEEP list
TYPEVM but was a misspelling and was removed; variables ESMFIAVG
May 5, 2005 and ESMFOAVG are now FORMATed TIME12.2.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch.
Change 23.109 Support for VM:Account product, which reversed the order
TYPEVM of dates from MMDDYY to YYMMDD and writes longer records.
May 5, 2005 This iteration does not support the additional data but
that support will be added in a later change.
Thanks to Richard J. Reents, Abbott Labs, USA.
Change 23.108 -Label was missing for variable PCTCPTBY in VMACQACS
VMACQACS PCTCPTBY='PERCENT WHEN*SYSTASK*CPU BUSY' and "8" in the
VMAC110 label for SYBTAC was changed to *.
VMACDB2 -VMAC110, new Stat variables prefixed DSH/DSI/DSJ/DSK
VMXGRMFI that are time values were not FORMATed TIME12.2;
May 5, 2005 DSxTOTMT variables were not formatted TIME12.2;
May 17, 2005 DSGTOTWT replaces DSGTOTWL in CICDS variable; TOTWL is
a suffix for CICDSPOO variables and had been reused.
-VMACDB2, new 8.1 variable QISESTMT was not kept.
-RMFINTRV, variable PCTIFABY labeled, ZOS70WLA removed.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
====== Changes thru 23.107 were in MXG 23.04 dated May 4, 2005=========
Change 23.107 Several macro definitions were incomplete or mislocated.
VMACVMXA -MACRO _SAPLSRV statement was missing; its code was
May 4, 2005 inside the MACRO _SAPLEDT definition.
May 16, 2005 -Invocations of _SAPLEDT and _SAPLSDT were missing in
the _DELTALL macro definition.
-The _SSYTSCG and _SSYTSYG macros had the DELTATM located
too late, and it was not set negative when missing to
protect the subsequent divides by DELTATM.
-There is no _SAPLAPL macro, but there's a _VAPLAPL macro
now created. The VMXA design preceded the _Vdddddd
macro definition (lists variables kept in the "dddddd"
token's dataset), and the old VMACVMXA uses _Vdddrrr
macros for domain/record groupings. _VAPLAPL wraps all
of the 25 Application Server _WAPLrrr datasets, each of
which has its own _Sdddddd macro, so that's why there
is on _SAPLAPL sort macro definition.
-A number of ommissions for new variables were fixed.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.106 -Variable TIWRDCT should not have been kept in MONIIDS nor
VMACTMO2 should its second label exist; that name was used twice
May 3, 2005 but was caught in QA and the correct TIIDSWRC/TIIDSWRT,
May 5, 2005 fields were input and labelled, but I failed to clean up
this part of the original duplicate names.
-Label for PAJTDLYT and PAJTDLYC were reversed, and some
lables had blanks instead of '*' SPLIT characters.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.105 TYPE73 variable SMF73CSS, Channel Subsystem ID was moved
VMAC73 to the end of the Channel Path Control Section, if bit 2
May 3, 2005 of SMF73CFL (Hardware allows multiple logical channel
subsystems) is enabled, by z/OS 1.5, but I missed that
relocation. SMF73CSS is now conditionally INPUT from the
new location when that bit is enabled.
Thanks to Joel Giacobbe, Federal Reserve Bank, USA.
Change 23.104 The ASUMTALO/ASUMTMNT summarization of tape drives and
ANALCNCR tape mounts is enhanced so that you can summarize by
ASUMTALO "groups" that you define, and ANALCNCR can now be used
ASUMTMNT to determine which jobs were active at the time of the
May 3, 2005 maximum tape drive allocation.
May 11, 2005 -For ASUMTALO, the default assumed all tape devices were
May 16, 2005 shared across all systems in the PDB.TYPETALO input data,
May 18, 2005 and were thus summarized by DEVICE.
-For ASUMTMNT, the default summarized all tape mounts BY
SYSTEM as the high level variable.
a. This change provides these local tailoring options:
-For ASUMTALO, you can define a "group" variable and then
create it based on SYSTEM, and that "group" variable
will then be used as the high-level summary variable in
the BY statements. For example, you can create a group
variable named LOCATION and populate that variable with
this example using the new old-style macros "instream":
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _GRPALNM LOCATION %
MACRO _GRPALCD
IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';
ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';
%
);
%INCLUDE SOURCLIB(ASUMTALO);
-The ASUMTALO data will then show tape device utilization
for each DEVICE type within each LOCATION.
-For ASUMTMNT, you can also define a "group" variable and
create it based on SYSTEM, and that "group" variable
will then be used as the high-level summary variable in
the BY statements. The two macro names are different, in
case you want to sum TMNT different than TALO, but the
structure is similar in this example:
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _GRPMNNM LOCATION %
MACRO _GRPMNCD
IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';
ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';
%
);
%INCLUDE SOURCLIB(ASUMTMNT);
-The ASUMTMNT data will then report tape mount statistics
for each SYSTEM within each LOCATION. If you want your
mount statistics to be summarized by each LOCATION (and
nor for each SYSTEM at each LOCATION, you would just add
SYSTEM=' ';
as the last statement in your _GRPMNNG definition.
-For your daily "BUILDPDB" job, which normally includes
both ASUMTALO and ASUMTMNT, you can put all four of those
macro definitions (_GRPALNM,_GRPALCD,_GRPMNNM,_GRPMNCD)
in a single %LET MACKEEP= for that job (or they could be
defined in the IMACKEEP member and then would apply to
any execution of their respective ASUM members).
b. Revision to find contributors to maximum value:
-ANALCNCR was enhanced so that you can print each of the
input events that caused the "maximum concurrent value".
When you specify %LET MXGDEBUG=ANALCNCR; prior to the
execution of ANALCNCR, then dataset WORK.MXGDEBUG will
be created with the first phase observations, and you can
then use this program to find the time of the peak value,
and then print the specific input events that created the
maximum. For example, ASUMTALO calculates maximum tape
drives allocated, so you would use:
%LET MXGDEBUG= ANALCNCR;
%INCLUDE SOURLCIB(ASUMTALO);
PROC SORT DATA=MXGDEBUG;
BY DESCENDING CONCURNT;
DATA _NULL_;
SET MXGDEBUG;
IF DEVICE=:'9840HSM';
PEAKTIME=PUT(TIMESTMP,DATETIME21.2);
CALL SYMPUT('PEAKTIME',PEAKTIME);
STOP;
RUN;
PROC PRINT DATA=PDB.TYPETALO;
WHERE DEVICE=: '9480HSM' AND
ALOCSTRT LE "&PEAKTIME"DT LE ALOCEND;
RUN;
to print which observations from the PDB.TYPETALO data
caused that maximum tape drive allocations.
For ANALCNCR with other input data, the test for the
"DEVICE" variable would need to be changed to use the
appropriate variable, the SET PDB.TYPETALO would need
to be changed to the input dataset, and the correct
start and end variables would need to be used in the
selection around "&PEAKTIME"DT test.
c. Additional chagnes:
-ANALCNCR was revised to re-locate the INCODE= operand;
this was required so that the "group" support, above,
could be implemented.
-A new TRACE= option for internal debugging was created
in ANALCNCR, unlikely to be needed outside development!
-An unrelated enhancement was also made to ASUMTMNT; the
definition of the mount time values for each of the mount
"buckets" was externalized, so they can also be changed
by redefining those macros with %LET MACKEEP=, as above.
Thanks to Andre D. Walker, Bank of America, USA.
Change 23.103 Documentation. Selecting ANALDB2R for an interval period
ANALDB2R (13:00 to 14:00), MXG's criteria selects any transaction
May 3, 2005 that started in that interval, or ended in that interval,
or started before and ended after that interval, so the
MXG report can easily show an "INTERVAL DURATION" that is
greater than the one hour you requested, but it includes
all transactions that spent any time in the requested
interval. IBM's DB2PM reports appear to only include the
transactions that started and ended within the requested
interval, so MXG can report more activity than DB2PM.
Thanks to Peter Farrell, Commerce Bank of Kansas City, USA.
Change 23.102 Cosmetic, but confusing! The label for PAGEINS/PAGEOUTS
VMAC30 is corrected to the TOTAL PAGE IN/OUT FROM AUX STORE, as
May 3, 2005 they count both blocked and unblocked pages moved.
Thanks to Melanie Hitchings, BT, ENGLAND.
Change 23.101 Support for APAR OA10901, new SMF30ZNF variable with the
VMAC30 zAAP CPU Normalization factor is added to the datasets
May 2, 2005 TYPE30_V/PDB.SMFINTRV, TYPE30_4 and TYPE30_5.
Change 23.100 ASG/Landmark TMON for CICS/TS V2.3 supports CICS/TS 3.1
VMACTMO2 with toleration PTFs for their product, but there are no
May 1, 2005 changes to their data dictionary, i.e., there were no
changes made in their records to add any new 3.1 fields.
Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.
Change 23.099 Support for IMS Version 9.1 was already in MXG 22.22:
VMACIMS -IMS Monitors: BMC IMF, Candle ITRF, Landmark TIMS.
May 1, 2005 -MXG's "Supported" TYPEIMS7 to create IMS0708 dataset
-MXG's ASMIMSL6/JCLIMSL6 to create IMSTRAN dataset.
-There were no significant changes by IBM to any of the
IMS log records in IMS Version 9.1, compared with 8.1.
-The three IMS Monitors that are fully supported by MXG
(and are STRONGLY recommended - See Newsletter 25!!),
BMC's IMF, ASG/Landmark's TIMS, and IBM/Candle's ITRF
products all create their own data records:
-IMF writes two records to the IMS log file, 'F9'x, 'FA'x
but there were no changes made by IMF Version 4.1.00 for
IMS Version 9.1 to the IMF records. However, MXG 22.08
is required for IMF records for all IMS versions, due to
corrections in sequencing of CIMSTRAN in Change 22.199.
Also, Change 22.241 in MXG 22.10 added ASUMCIMS example
for summarization of CIMSTRAN/CIMSDBDS IMF datasets.
-TIMS writes data to its own file; the last update to
TYPETIMS code was in MXG Version 20.09.
-ITRF writes additional records to the IMS log, but then
an ITRF program combines their records with IBM records
to create their file that MXG TYPEITRF then processes;
the last TYPEITRF code change was in MXG Version 17.09.
-MXG's only "Officially Supported" IBM-IMS-log-record read
program is TYPEIMS7, which combines log records 07 and 08
to create the IMS0708 dataset (capturing only resources,
with no response time). Those records were not changed
by IBM in IMS V9.1, but MXG Change 22.199 (in MXG 22.08)
was a major revision to the TYPEIMS7 logic for all IMSs.
- You must update the _IMSVERS macro in IMACIMS to tell
MXG the IMS version you are processing, and you cannot
concatenate IMS logs from different versions, as IBM
does not put a version number in their log records!
-MXG's "pseudo-supported" IBM-IMS-log-record read programs
in the JCLIMSL6 jobstream required no changes to support
IMS Version 9.1, but you must re-assemble ASMIMSL6 with
the IBM IMS Macro Library for IMS Version 9.1 to create
the load module for V9.1 records, and you must run
separate JCLIMSLx jobs with different load libraries and
process each IMS version's data separately; you cannot
concatenate the IMS logs from two versions and read with
JCLIMSLx. MXG 20.03 contained the last changes to these
members, and thus there was no need to create L7, L8, or
L9 suffixed ASMIMSLx/JCLIMSLx members.
-For processing JCLIMSLx/ASMIMSLx on ASCII platforms, MXG
Version 22.06 is required due to Change 22.128.
-IBM did insert fields in the IMS log 31x record in V9.1,
and VMACIMS is updated by this change (in MXG 23.04) for
that insert, but the insert was after any "important" IMS
data, and could only be observed if you were looking at
the IMS31I or IMS31O datasets that are written to //WORK,
but are neither kept nor used by MXG programs.
Thanks to Roland Brugger, Credit Suisse, SWITZERLAND.
Change 23.098 DB2 Version 8 restructured Package Data, and added many
VMACDB2 new variables to DB2ACCTP dataset:
Apr 30, 2005 QTXACHG QTXACHUS QTXACLMT QTXACLNO QTXACLUN QTXADEA
QTXADRNO QTXADRUN QTXAFLG1 QTXAILMT QTXAIRLM QTXALES
QTXALEX QTXALOCK QTXANPL QTXANRUN QTXAPREC QTXAQRY
QTXARLID QTXASLAT QTXASLMT QTXASLOC QTXASOTH QTXATIM
QTXAUNLK
QBACGET QBACSWS QBACRIO QBACSEQ QBACIMW QBACLPF
QBACDPF QBACNGT QBACSIO
QPCALLCT QPCLOSET QPDELETT QPDESCCT QPFETCHT QPINSRTT
QPLOCKCT QPOPENCT QPPREPCT QPSELECT QPUPDTET
Originally, the first ten packages executed by a plan
were written as ten segments in the SMF 101 subtype 0
IFCID=0003 records, and if more than 10 packages were
executed, additional SMF 101 subtype 1 IFCID=239 records
were created. MXG creates an observation in the DB2ACCTP
dataset from each package segment, independent of whether
it was in the 0003 or the 239 IFCID record. But with
DB2 V8.1, package segments are no longer written in IFCID
0003 records; instead only the IFCID 0239 records will
contain package data, and there are three new DSECTS
added that are always present, one of each for each
package segment.
(QXPK, QBAC, and QTXA, and in that order; the DB2 MACRO
Library had inconsistent documentation that will be
corrected with a doc APAR)
MXG will transparently use either 0003 and 0239 or just
0239 segments to create the DB2ACCTP observations, and
those added new variables will exist, but will only be
populated (i.e., non-missing) from DB2 V81 records.
Thanks to Steven Olmstead, Thomson BETA Systems, USA.
Thanks to Ray Willoughby, Thomson BETA Systems, USA.
Thanks to John B. Tobler, IBM Silicon Valley Lab, USA.
Change 23.097 Variables CTCKPNTS MAXLOCKS TOTLOCKS were added to the
VMACCIMS KEEP list of both CIMSTRAN and CIMSPROG, but those three
Apr 29, 2005 variables are only INPUT from the CIMSTRAN records, so
they are now removed from CIMSPROG KEEP list.
Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM
Change 23.096 Change 22.203 protected decoding of JCTJOBID if it was
VGETJESN blank or hex zero, to prevent unnecessary log messages,
Apr 29, 2005 but that caused TYPETASK to be blank in TYPE30_6 data,
because the "Early Address Spaces" records that are
written as type 30 subtype 6 interval records now have
have blanks for JCTJOBID.
(Historically, these records had JOB name in JCTJOBID,
then JCTJOBID was hex zeros, but now JCTJOBID contains
blanks in current z/OS type 30 subtype 6 records).
But they have SUBSYS='STC', so the logic was revised to
sets TYPETASK='STC' (and JESNR=.) if JCTJOBID is blank or
hex zero, and SUBSYS='STC'.
(And if blank-TYPETASK-value-messages are printed now,
more code will be added to test and figure it out!)
Thanks to Michael Creech, Fidelity Information Services, Inc, USA.
Change 23.095 Variable PCTCFULL='PCT OF*CACHE*USED' was added to the
VMAC41 TYPE41VF dataset. Variable SMF41FND is clarified in the
Apr 29, 2005 ADOC41 as the number of objects found in cache in this
interval, which is NOT the total number of objects in the
cache (that number does not exist in SMF 41 records).
Thanks to Ulrich Krueger, National Semiconductor Corp., USA.
Change 23.094 The PROC DATASETS for HSMSTAT needed MT=ALL because that
ASUMHSM dataset is a VIEW, and the default MemType=DATA caused a
Apr 29, 2005 warning note.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.093 SMF 74 subtype 8 INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC74 because I didn't have any test data to catch my typos!
Apr 28, 2005 The INPUT of R748RCNT was missing a period, variables
R748AASP/AAWD/AACP are now PIB1/2/4 instead of RB8, and
variables R748XRCP thru R748XTDY are PIB4. and not RB4.
Thanks to Miguel Francisco Monferrer Carvajal, EDS, SPAIN.
Change 23.092 MXG 23.03 only, and only for ITSV/ITRM. Two hardcoded
VMXG70PR references to "PDB." caused errors with ITSV/ITRM. The
Apr 28, 2005 macro variable "&PTY70PR.." replaced them to correct.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.091 SMF 6 record INPUT STATEMENT EXCEEDED RECORD LENGTH with
VMAC6 a VPS record with the Printway File Transfer segment. The
Apr 28, 2005 Changes 22.309, 22.321 are revised, based on the z/OS 1.6
SMF Manual, which documents both the basic and extended
mode for records created by SUBSYS='TCP', but the values
in SMF6INDC in SUBSYS='VPS' records are 5 and 3 instead
of the 1 or 7 expected, so MXG logic is revised again to
provide special handling for VPS SMF 6 records that have
a file transfer segment. But in one SMF 6 record written
for SUBSYS='PSF', it's file transfer segment does not
agree with either the basic or extended mode TCP segments
or with the PSF segment documentation, so heuristic logic
is added to (hopefully) protect PSF records as well.
Thanks to Udo Frohling, Kommunales Rechenzentrum Niederrhein, GERMANY
Spent week in NYC at The Plaza during its last week as a real hotel, but
our real purpose was to attend the Jammy Awards ceremony at Madison
Square Garden, where our "godson", Keller Williams won one of only nine
Jammy's: Best Live Album, "Stage". See http://www.kellerwilliams.net.
====== Changes thru 23.090 were in MXG 23.03 dated Apr 22, 2005=========
Change 23.090 Executing MXG under ASCII platforms has some differences:
INSTALL -If you use the ftp access method to read your MVS data
IMACFILE directly, you won't have a copy of the SMF data on your
Apr 22, 2005 ASCII system; although most sites back up their SMF data
on MVS, it is possible to backup your SMF data on your
ASCII platform, as you are reading SMF with ftp access.
Writing a 13GB backup file added 20 minutes run time.
See the article "Can you run MXG on a PC' in NEWSLTRS.
Or, if you want to create an SMF file on your ASCII
system that contains selected SMF data, the below example
shows how you can use the "IMACFILE" exit to create an
SMF VBS file on your ASCII system.
-The _NULL_ data step creates macro variable, &DATETXT,
with the date and time as a text string, which is then
used to create the name of the "backup" SMF VBS file.
-The "instream" tailoring statement %LET MACFILE= adds
the code inside the %QUOTE() function (required because
there semi-colons in the code that would otherwise have
terminated the %LET statement) to the exit that is taken
after the SMF header has been read.
If you want to select SMF records, you would add an
IF ... THEN DO; statement after the %QUOTE( and would
add an END; statement before the ) that ends %QUOTE.
The SMF header variables ID SMFTIME SYSTEM and SUBTYPE
are available for selection, although some records with
subtypes don't put their subtype in the SMF header.
-Example to read SMF via FTP and create a local SMFBKUP
file of the input SMF records:
The example shows how to concatenate multiple SMF files:
//SYSIN DD *
DATA _NULL_;
DATE=TODAY();
TIME=TIME();
DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!
PUT(HOUR(TIME),Z2.)!!'-'!!
PUT(MINUTE(TIME),Z2.);
CALL SYMPUT('DATETXT',DATETXT);
RUN;
FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )
USER='XXXXXX' HOST='YYYYYYY'
S370VS RCMD='SITE RDW' LRECL=32760
PASS='XXXXXXXX';
FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;
%LET MACFILE=
%QUOTE(
RDW=LENGTH+4;
BDW=RDW+4;
FILE SMFBKUP RECFM=N LRECL=32760;
PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X
_INFILE_ @;
);
RUN;
%INCLUDE SOURCLIB(BUILDPDB);
RUN;
The backup file name c:\mxg\smfdata\D2005-04-19-T04-20
contains the date and time of creation of the file. The
backup file is slightly larger than the input file
(325,498,825 versus 325,484,807, or +14,018 bytes)
because each VBS record creates a separate block. And,
the FILE with RECFM=N option does print the output file
name on the SAS log, there is not message that any data
was written. SAS Technical Support says that is because
RECFM=N doesn't write records that none are counted, but
a suggestion to provide byte count has been made, so that
you will know if the file was actually written to.
-Comments with this example were added to IMACFILE and to
member INSTALL, but no there was no change to MXG code.
-Example to read SMF via FTP and select a subset of SMF
records to be created on the ASCII platform;
The example shows how to concatenate multiple SMF files:
//SYSIN DD *
DATA _NULL_;
DATE=TODAY();
TIME=TIME();
DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!
PUT(HOUR(TIME),Z2.)!!'-'!!
PUT(MINUTE(TIME),Z2.);
CALL SYMPUT('DATETXT',DATETXT);
RUN;
FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )
USER='XXXXXX' HOST='YYYYYYY'
S370VS RCMD='SITE RDW' LRECL=32760
PASS='XXXXXXXX';
FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;
%LET MACFILE=
%QUOTE(
IF ID IN (70,72);
RDW=LENGTH+4;
BDW=RDW+4;
FILE SMFBKUP RECFM=N LRECL=32760;
PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X
_INFILE_ @;
);
RUN;
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
RUN;
Thanks to Michael Gebbia, Eddie Bauer, USA.
Thanks to Glenn Bowman, Wakefern, USA.
Change 23.089 Variable DCVDVNUM, the Device Number, is retained from
VMACDCOL the DCOLVOLS record and kept in the DCOLDSET dataset;
Apr 21, 2005 this is possible because the DCOLLECT output is ordered
with the DCOLVOLS record before the DCOLDSETs on that
volume.
Thanks to Frank Lund, EDB IT Drift, NORWAY.
Change 23.088 -Variables EV40FLG1 EV40FLG2 and CATGNAME from RACFTYPE=40
EXTY8066 were incorrectly kept in TYPE8007 dataset and were not
IMAC80A kept in TYPE8008 dataset, now they are correct.
VMAC80A -Variables FROMRESN (13), VOLUME FVOLUME (14) and CLAS26NM
VMXGINIT (from RACFTYPE/DTP=26) are kept in TYPE8019.
Apr 23, 2005 -FROMVOLS in RACFTYPE=6 for RACFEVNT=8 is an 8-byte field,
Apr 27, 2005 but MXG only input 6 bytes, shifting SECLEVEL/SECLABEL.
May 12, 2005 Now, FROMVOLS is input as $EBCDIC8 and the "undocumented"
May 17, 2005 +2 bytes are removed from that INPUT statement.
May 29, 2005 -Variables KW09IG06 ande KW09SP06, UNIVERSAL, added to
May 30, 2005 dataset TYPE8009
-Variables SECLEVEL,SECLABEL,KW11SP28-29,KW11IG28-29
added to TYPE8011.
-Variables CLASSP02,04,05,06 added to TYPE8010,TYPE8013.
-Variable KW19CL07 added to TYPE8019.
-Variables KW19FC00-KW19FC07 replace 00-04, which were
incorrectly decoded.
-Variables KW24S102-S109 added, decoded from KW24RSV1.
-Variables KW25VI00-VI01 added, decoded from KW24OVIO.
-Variables KW59ST00-ST06 added, decoded from KW24STAT.
-Dataset TYPE8066 created for RACDCERT command; however,
only the standard RACF variables are output in this
iteration - time ran out for 23.02 QA, but this record
will be fully decoded in the next iteration.
-Variable LOGSTR change length to 200 from 64, but not
until May 12!
-Additional variables, thru KW24S132, KW24I117, KW24KERB
are decoded, May 17.
-ACEEUSER variable now kept in TYPE8024.
-Second (290) should have been (291).
-KW24SP46/KW24SP47/KW24IG46/KW24IG47 are corrected.
-KW11xx13 and later were incorrectly aligned with th4eir
bits and labels, and KW11xx28 and KW11xx29 should not
have been created for ALTDSD event.
-KW10ER00-KW10ER31 are now decoded and kept in both the
TYPE8010 and TYPE8013 datasets; all three of the sets
of bit maps KW10ERnn, KW10IGnn, and KW10SPnn are the same
for ADDUSER (10) and ALTUSER (13), except that some bits
that can be enabled for ADDUSER won't be for ALTUSER.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Andrew Davis, Euroclear, BELGIUM.
Thanks to Aimee Steel, Euroclear, BELGIUM.
Change 23.087 -If USERADD= contained two references (SYNC/208 SYNC/214)
UTILBLDP with different SMF IDs, UTILBLDP generated incorrect code
VMXGINIT but now it will use only the first reference.
BUILDPDB -EXPDBOUT=%INCLUDE SOURCLIB(ASUMPRTR); used in Example 7,
BUILDPD3 failed. Unfortunately, because of macro timing issues,
BUILD001 the only way UTILBLDP can create a %INCLUDE statement
BUIL3001 for EXPDBOUT= required a new macro variable, &BLDPOUT,
Apr 21, 2005 to be defined in VMXGINIT and inserted in the BUILxxxx
members where _EPDBOUT is invoked.
Thanks to Robert Chavez, OfficeDepot, USA.
Change 23.086 DB2STATS variable QDSTNQR2 should not have been DIF()'d.
VMACDB2 Variable QDSTQDBT should have been, and now is DIF()'d
Apr 21, 2005 as it contains accumulated values.
Thanks to Fred Nijdam, Rabobank, THE NETHERLANDS.
Change 23.085 Dataset ICEBRGCH old variables ENDTIME,STARTIME were not
VMACICE adjusted in VMXGTIME macros, old variable CHANSPED is now
Apr 19, 2005 converted to bytes and FORMATed MGBYTRT as it is channel
speed in Bytes per second, and new PCHANBY variable is
created. When ICEBERGs are shared across systems, you
must choose data from only one system, since each system
creates a replicated SMF record for each interval.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.084 The UTILEXCL utility now has "standard" MXG macro tokens
EXCICDIC _VCICDIC/_WCICDIC/_PCICDIC/etc instead of hard-coded name
IMACICD8 for the CICSDICT dataset.
UTILEXCL -Optional CANVRSN field is now supported in IMACICD8.
VMXGINIT
Apr 19, 2005
Thanks to Michael Oujesky, MBNA, USA.
Change 23.083 -Variable NRCPUD, the number of CPU segments in "this" MVS
VMAC7072 SMF 70 record is now kept in datasets TYPE70 and TYPE70PR
Apr 18, 2005 as it describes the maximum engines this system could use
perhaps as an upper bound on engines under IRD control.
-The IFAWAITM and IFAWAIT0-IFAWAITX IFA*WAIT*DURATION
variables have been reinstated in TYPE70 dataset, as it
turns out they are useful in IFA analysis.
Thanks to Art Cuneo, Health Care Service Corporation, USA.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.082 ***ERROR. QWHSLOCN CONTAINS UNICODE TEXT message printed
VMACDB2H with DB2 V8 record, so that I could see what IBM stored
Apr 18, 2005 in QWHSLOCN when QWHSFLAG='80'X. Now, with this first
instance of QWHSFLAG on, I can see that the text value
in QWHSLOCN is simple ASCII data, so MXG's INPUT of the
QWHSLOCN is now revised to INPUT either EBCDIC or ASCII
based on QWHSFLAG. The IBM documentation for QWHSFLAG in
the DSECT is "%U fields contain Unicode UTF-8)", which I
assumed meant that QWHSLOCN would contain UNICODE data
(i.e., 2-byte, DBCS text), but I've now googled UTF-8 and
find that UTF-8 is an ASCII-preserving encoding method,
so the INPUT with $ASCII16. is all that is needed!
With the ERROR message, the only error is that the value
in QWHSLOCN, Local Location Name, was trashed.
Thanks to Ian Arnette, Toronto Dominion Bank, CANADA.
Thanks to ??? , Toronto Dominion Bank, CANADA.
Change 23.081 Changes in WLM Service Policy can be tracked by TYPE9024,
VMAC90A now that the new policy name is input as SVPOLNSP from
Apr 17, 2005 the IWMVSPOL DSECT.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.080 Support for RMF III IFA data added by z/OS 1.6. New data
VMACRMFV was added to ZRBASI and ZRBENC datasets. No change was
Apr 17, 2005 required to the ASMRMFV program, which automatically sees
and writes out the longer records.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Robert Vance, Zurich Insurance Company, USA.
Change 23.079 INVALID DATA FOR MM in NDM NDMRTYPE='SS' SMF record. MXG
VMACNDM input two bytes that should have been substringed from
Apr 14, 2005 NDMSID0, which also should have been INPUT as $CHAR8 and
formatted $HEX16 because it can have hex and character
data.
Thanks to Bernie Mazur, Bank of Montreal, CANADA.
Change 23.078 The path activity report is enhanced to report the CMR
ANALPATH (which can be significant for FICON channels) and the OTH
Apr 14, 2005 pend time in separate columns on the report.
Thanks to Tony P. Steward, CSC, ENGLAND.
Change 23.077 ***ERROR.TYPE110.SUBTYPE 2. CICS STAT RECORD STID=106.
VMAC110 MXG missed an 8-byte reserved field before PIWPGMNM, and
Apr 13, 2005 incorrectly only "skipped" 1160 bytes of the 1168 STILEN.
Apr 15, 2005 The last three variables, PIWPGMNM, PIWCONNM, PIWUSECT in
dataset CICPIW were wrong.
Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.
Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.
Change 23.076 Invalid Package Data detected. The pseudo SMF 101 record
TYPSTHST created by BMC's DB2 THRDHIST file contain a standard
Apr 12, 2005 triplet for the first 10 packages, like an IBM IFCID 0003
record, but then, additional segments are written to the
end of the 32752 byte record. Unfortunately, there is
only room for 69/70 segments. Instead of writing a valid
IFCID 289 record with additional segments, THRDHIST puts
part of the next segment, as many bytes as fit, to fill
the records (splitting in the middle of a field!), and
then creates a new record, without header, with the rest
of that segment, followed by the remaining packages.
This is an invalid architecture, to split fields across
physical records. Until BMC redesigns its file, the best
MXG can do is to process those 69 or 70 segments that are
complete, and report with a message to the SAS log that
additional package segments existed but could not be
processed. (Prior to this change, MXG tested the triplet
to ensure MXG did not read beyond the end of the record,
but when the product of number of segments times their
length exceeded the record size, all packages were just
skipped, without an error message).
Thanks to Bernd Rueckrich, R & V Versicherung AG, GERMANY
Change 23.075 -UTILEXCL. Optional CMODNAME='RMI',CMODHEAD='DB2CLOCK'
UTILEXCL did not generate an UNKNOWN FIELD SKIPPED message, and
IMACICUS did not skip that field in the created IMACEXCL code.
Apr 11, 2005 The MXG code for a CMODNAME='RMI', with multiple fields,
decoded in IMACICRM was revised to recognize this new
RMI variant (which is not to be confused with yet
another RMI-containing segment with CMODNAME='DFHRMI'
that is supported in IMACICRD!
-IMACICUS. Cosmetic; comments were clarified.
Thanks to Christen Ole Christiansen, IBM, DENMARK.
Change 23.074 This Analysis of FICON Open Exchanges is based on work by
ANALFIOE Dr. Pat Artis that was documented in Change 21.087. He
Apr 11, 2005 has revised his calculation, slightly, by inclusion of
the new DLYCMRTM, the Command Response Time, which is a
subset of PEND time that occurs after the channel has
selected the I/O for processing, in his note "Managing
Complex FICON Configurations." DLRCMRTM is added to the
calculation by this change.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to Mike Crowder, Humana, USA.
Change 23.073 Variable MODEL, taken from DEVMODEL, is a numeric value
ASUMCACH that is added to the BY list in TRNDCACH to provide more
TRNDCACH granularity in the summarization. All values of MODEL
Apr 10, 2005 are numeric (3390 33903 33909), but this revision will
need revision if a non-numeric DEVMODEL is ever created.
Thanks to Diane Eppestine, SBC, USA.
Change 23.072 Support for APAR OA09921 for IBM TotalStorage DS6000 adds
VMAC78 the Preferred Pathing Function, with these new variables
VMAC79 in type 78 subtype 3 records:
Apr 10, 2005 -TYPE78CF - R783CPAT - PATH*ATTRIBUTES
-TYPE78CU - LCUDST - DATA STATUS BITS
-TYPE78IO - R783CSS - CHANNEL SUBSYSTEM ID.
and in type 79 subtype 14 records
-TYPE79E - R79ECPAT - PATH ATTRIBUTESS
-TYPE79E - LCUDST - DATA STATUS BITS
Change 23.071 Enhanced IFA summarization in PDB.RMFINTRV, PDB.ASUM70PR,
VMXGRMFI PDB.ASUM70LP, and PDB.ASUMCEC. However, you have to be
VMXG70PR careful in understanding how IFAs are reported; they are
VMXGDUR much like CPs when they are shared across LPARs:
Apr 16, 2005 - "System-level" datasets (RMFINTRV/ASUM70PR/ASUM70LP)
can NOT provide accurate utilization of shared IFAs.
If you have 4 shared IFAs and two MVS systems, these
system obs do have the IFAACTTM (IFA CPU time) used by
that SYSTEM/LPAR, but each obs will also show there
were 4 IFAs, so any percent-used calculation will be
only this system's part of the utilization of all four
installed shared IFAs.
- "CEC/CPC-level" dataset PDB.ASUMCEC does correctly sum
the IFAACTTM across all systems running on that CECSER,
and the PCTIFABY in PDB.ASUMCEC is the correct percent
utilization of all four IFAs by both LPARs.
-VMXGDUR was enhanced with operands for interval values of
10-minute and 5-minute.
Thanks to Scott Weiner, WPS Insurance Corporation, USA.
Change 23.070 IBM cannot guarantee that RMF STARTIME values will be the
VSETZERO exact-on-the-minute value that you thought you'd get when
VMAC7072 SYNC(SMF) is specified in ERBRMFxx member of parmlib:
VMAC71 "When RMF Monitor I runs with SYNC(SMF) option, RMF
VMAC73 will be triggered by SMF via ENF37 at the end of the
VMAC74 SMF interval. SMF sends this ENF37 signal shortly
VMAC75 before the interval end, and RMF starts its interval
VMAC76 processing after receiving that signal. During this
VMAC77 interval processing, RMF sets the interval start time
VMAC78 for the next interval in the SMFxxIST field, and you
VMAC79 must expect some deviation in SMFxxIST time values;
VMACCMF since SMF ENF37 is sent shortly before the interval
VMACEPMV end, SMFxxIST times can also be earlier than the end.
Apr 10, 2005 If you use SMFxxIST field data, which only have one
second granularity, you must plan to tolerate small
deviations in SMFxxIST times."
per Peter Muench, IBM RMF Development, Germany.
IBM's SMFxxIST is the STARTIME variable in MXG RMF data.
Data with STARTIME at :59 seconds instead of :00 caused
the HOUR of the STARTIME to be one hour early, so with
IBM's note that STARTIME cannot be guaranteed to be the
expected exact minute, it is now up to MXG to detect and
correct STARTIME in your RMF datasets.
-New VSETZERO member is %INCLUDEd in all RMF-processing
code members to detect that seconds of STARTIME were
58, 59, or 01, and it resets the STARTIME to the exact
correct hour:minute:00 value.
-Note that it is still possible to have STARTIME values
that are not exact minutes; for example, the value in
Change 23.069 of 19:59:40 would not be changed.
Thanks to Wolfbang Vierling, Allianz, GERMANY.
Thanks to Bernd Tekath, Allianz, GERMANY.
Change 23.069 -RMF Interval less than one minute caused incorrect data
VMXG70PR in PDB.ASUMCEC, because MXG logic recalculated STARTIME
Apr 9, 2005 (only for PDB.ASUMCEC) to the nearest exact minute value.
The STARTIME was 19:59:40 and DURATM was 19 seconds, due
to a WLM Policy Reset just before 20:00:00, with a normal
15 minute interval with STARTIME of 20:00:00, but the obs
in PDB.ASUMCEC had STARTIME of 20:00 with DURATM=19 secs,
and all the calculated PCTxxxxx values were all wrong.
This change removed the code in VMXG70PR that modified
STARTIME for PDB.ASUMCEC, which corrected the error due
to the short interval data, but ONLY because all of the
SYSTEMS on this CEC had identical short intervals, and
because MXG default _DURSET in IMACRMFI was in effect,
causing each original STARTIME value was to be output
(i.e., no summarization to a new INTERVAL was requested).
The result was that there were two observations created
in PDB.ASUMCEC, one with its STARTIME of 19:59:40 and
DURATM of 19 seconds, and one at STARTIME of 20:00:00
with DURATM of 15 minutes, and each was valid, because
all of the SYSTEMs had the same short interval data.
-But if you want PDB.ASUMCEC summarized so that only one
observation is created at the "expected" 15-minute DURATM
then you must tailor the IMACRMFI member to set STARTIME
to the 15 minute time, and then that short interval will
be summed into a 19:45 STARTIME with DURATM of 15 min.
-BUT PDB.ASUMCEC WILL ALWAYS BE WRONG IF YOU HAVE SYSTEMS
ON THE SAME CEC WITH DIFFERENT DURATM VALUES, IF ANY OF
THOSE DURATMs ARE GREATER THAN THE IMACRMFI INTERVAL YOU
REQUESTED. For example, if systems have 15 minute and
hourly RMF data on the SAME CEC, PDB.ASUMCEC dataset has
an observation on the hour with DURATM of 60 minutes, but
there will also be hour:15, hour:30, and hour:45 STARTIME
observations with DURATM of 15 minutes, and all of that
data in PDB.ASUMCEC is likely wrong. Only if you set the
IMACRMFI summarization to hourly can MXG create a valid
PDB.ASUMCEC dataset from that kind of mixed DURATM data.
-Note that it is ONLY the PDB.ASUMCEC dataset that had any
problems; whether you have short DURATM or mixed DURATMs,
the PDB.ASUM70PR and PDB.ASUM70LP datasets were always
correct, since they are summarized by SYSPLEX SYSTEM.
Nov 10: Not True. See Change 23.289 which is needed.
-The IMACRMFI default tailoring sets the interval for the
PDB.RMFINTRV, PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC
datasets, but that can be overridden if you have tailored
either the ASUM70PR member or the RMFINTRV member to use
their INTERVAL= arugment, instead of changing IMACRMFI.
Setting the INTERVAL= or IMACRMFI work equally well.
-Change 21.315 reset the STARTIME in VMXG70PR for ASUMCEC,
but the Change 23.070 enhancements eliminates both that
need and this exposure, so that code was safely removed
Thanks to Diane Eppestine, SBC, USA.
Change 23.068 BUILDPD3 now sets Condition/Return Code of zero under V9!
VMAC26J3 MXG Change 22.365 fixed the problem for JES2 BUILDPDB and
Apr 9, 2005 this revision fixes the problem for JES3. Two changes
were needed; JOBCLASS is now input as J3CLSONE as $1 and
then stored into JOBCLASS, and the initial reference to
ACCOUNT1 was relocated after the include of IMACACCT so
the length would be set by your IMACACCT tailoring. An
extremely-rare-in-MXG GOTO was used to preserve the flow
of execution.
Nov 3: This did not work as expected and caused zero
observations in TYPE26J3; corrected in Change 23.282,
added in MXG 23.09.
Thanks to Diane Eppestine, SBC, USA.
Change 23.067 Cosmetic. MXG 23.02 only. The four listed members will
VGETDDS cause this MXGERROR: message to be printed on the log:
VGETDDS VGETxxxx IS BACK-LEVEL AT 23.01, WHICH IS EARLIER
VGETDSN THAN THE EXECUTING MXG VERSION OF 23.02....
VGETENG Disregard for those members; they were not updated when
VGETSORT MXG 23.02 was created.
Apr 9, 2005 -Also, the message text now prints MXGWARN: vice ERROR.
Change 23.066 Support for RACF Events 27, 28, and 29 for unix
EXTY8028 dddddd Dataset Description
EXTY8029 TY8028 TYPE8028 RACF EVT 28 DIRECTORY SEARCH
EXTY8030 TY8029 TYPE8029 RACF EVT 29 CHECK ACCESS TO DIR
VMAC80A TY8030 TYPE8030 RACF EVT 30 CHECK ACCESS TO FILE
VMXGINIT
Apr 9, 2005
Thanks to Peter Schubert, CITEC, AUSTRALIA
Change 23.065 -Variable EXPCTSRD in dataset VXSTOASP was not
VMACVMXA deaccumulated, but now it is.
Apr 8, 2005 -Variable TCMMIDSZ was changed to bytes by 20.04, but
Apr 10, 2005 its label still had PAGES instead of BYTES.
-Variables PFXSPINC and PFXSPINT were incorrect because
their deaccumulation assumed descending order, but these
two variables are accumulated in ascending order.
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Thanks to Brian Crow, BT, ENGLAND.
Change 23.064 Dataset TYPE78SP, Virtual Storage Subpool for monitored
VMAC78 jobs, only contained subpool information below the 16MB
Apr 8, 2005 line (because I thought a subpool was either above or
below when I wrote that code years ago!). Now, variables
SUBPOOL5-SUBPOOL9 are created, and they will be populated
if the subpool for this job allocated above-16MB-space.
-The storage variables were not in a LENGTH .. &MXGBYLN
statement, so their stored length was the MXG default of
4 bytes, which could have caused small truncation if the
value was large (e.g., 999M instead of 1G). They all now
have the correct length set in a LENGTH statement.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.063 Cosmetic. Label is now ACTRELAP='ELAPSED*TIME'. Label
VMACENTX for prior variable had been copied incorrectly.
Apr 5, 2005
Thanks to Chris Taylor, GMAC Insurance, USA.
Change 23.062 Variables SRMWSSDL, SRMWSSD1, SRMWSSD2, SRMWSSD3 in
VMACVMXA VXSYTSCG are working set sizes, but were still in pages,
Apr 5, 2005 which is inconsistent with other z/VM working set size
variables, so they are now converted to bytes and
formatted MGBYTES.
Thanks to Kris Ferrier, State of Washington DIS, USA.
====== Changes thru 23.061 were in MXG 23.02 dated Apr 4, 2005=========
Change 23.061 The SEQENGINE=V9SEQ is now set in CONFIGV9 for z/OS. You
CONFIGV9 must be at SAS V9.1.3, or you must have HotFix SN-012437
Apr 3, 2005 if you are using SAS V9.1 or V9.1.2, but almost everyone
is now installing V9.1.3, so I deem it safer to use V9SEQ
now. The problem is that using V6SEQ does not work when
character variables are greater than 200 bytes, and there
are many new variables that need to be 255 or greater;
clinging to V6SEQ because you've not installed a Hot Fix
is not fair to all the smarties that are using V9.1.3.
If you've not installed that Hot Fix and are still using
V9.1/V9.1.2, then you MUST change the V9SEQ in CONFIGV9
back to V6SEQ (you cannot use V8SEQ with SAS Version 9).
If you want all the historic details of which sequential
engine did what, you can search CHANGESS and NEWSLTRS
members for V9SEQ for the litany of iterations on what
works and what doesn't work.
(While we can tell that you are at 9.1.3, for sites
still back on 9.1/9.1.2 we cannot tell if you have
the hot fix installed.)
Change 23.060 Support for z/VM 5.1 enhanced; all new data supported.
ADOCVMXA -Nine new "standard" MONWRITE datasets are created:
EOAPLCMS Domain Record dddddd Dataset Description
EOAPLTC0 1 18 MTRCCC VXMTRCCC CPU Capability Change
EOAPLTC1 2 11 SCLIOP VXSCLIOP I/O Priority Changes
EOAPLTC2 5 8 PRCIOP VXPRCIOP IOP Utilization
EOAPLTC3 6 21 IODVSW VXIODVSW Virtual Switch Activity
EOAPLTC4 6 22 IODVSF VXIODVSF Virtual Switch Failover
EOAPLTC5 6 23 IODVSR VXIODVSR Virtual Switch Recovery
EOAPLTC6 6 24 IODSZI VXIODSZI SCSI Device Activity
EOAPLTC7 6 25 IODQDA VXIODQDA Activate QDIO Device
EOAPLTC8 6 27 IODQDD VXIODQDD Deactivate QDIO Device
EOAPLTC9 -Eight existing MONWRITE datasets have new variables:
EOAPLTCA Domain Record dddddd Dataset
EOAPLTCB 0 8 SYTUSR VXSYTUSS
EOAPLTCC 2 4 SCLADL VXSCLADL
EOAPLTCC 2 5 SCLDDL VXSCLDDL
EOAPLTCD 2 6 SCLAEL VXSCLAEL
3 12 STOASC VXSTOASC
EOAPLVMR 4 1 USELON VXUSELON
EXAPLSL0 4 9 USEATE VXUSEATE
EXAPLSLM 4 10 USEITE VXUSEITE
EXAPLSLN 6 26 IODQDS VXIODQDS
EXAPLSLP -Domain 10 (Application Server) logic was revised; the
EXIODQDD separate decoding of Sample and Event data under two
EXMTRCCC separate internal macro pairs (_VAPLSDT,_CAPLSDT) and
EXPRCIOP (_VAPLEDT,_CAPLEDT) was replaced with a single internal
EXSCLIOP pair (_VAPLAPL,_CAPLAPL) because "Configuration Class"
FORMATS data for TCP/IP can be either Sample or Event, or both.
IMACVMXA -These new datasets are created from domain 10 records:
VMACVMXA Source: CMS APPLDATA MDGPROD=5684030MT1020100
VMXGINIT MXG Dataset VXAPLCMS 'CMS Multitasking'
Apr 3, 2005 Source: TCP/IP MDGPROD=5735FALSTx0ttt00
Multiple MXG datasets are created, based on the
hex value "x" in MGDPROD:
x Dataset Description
00 VXAPLTC0 TCP/IP MIB Record
01 VXAPLTC1 TCP/IP TCB OPEN Record
02 VXAPLTC2 TCP/IP TCB CLOSE Record
03 VXAPLTC3 TCP/IP Pool Limit Configuration
03 VXAPLTCX TCP/IP Pool Data
04 VXAPLTC4 TCP/IP Pool Size
05 VXAPLTC5 TCP/IP LCB Link
06 VXAPLTC6 TCP/IP UCB OPEN
07 VXAPLTC7 TCP/IP UCB CLOSE
08 VXAPLTC8 TCP/IP Link Definition
09 VXAPLTC9 TCP/IP ACB
0A VXAPLTCA TCP/IP CPU
0B VXAPLTCB TCP/IP CCB
0C VXAPLTCC TCP/IP Tree Size
0D VXAPLTCD TCP/IP Home
0E VXAPLTCE TCP/IP IPv6 Home
Source: VMRM MDGPROD=5739A03RM0000000
MXG Dataset VXAPLVMR 'VMRM Workloads'
Most of these new datasets have been tested with data,
but some of the de-accumulation may be incomplete, as I
only have a few observations in some of the TCP/IP data.
If you want to use the new data, especially TCP/IP stuff,
please contact support@mxg.com to send your MONWRITE data
so we can investigate these new metrics together.
-ADOCVMXA notes were revised; Richard Steele's paper from
1988 was changed into plain text, without control chars,
and moved to the top of the member, and IBM Manuals that
show you how to set up the MONWRITE Virtual Machine and
its Saved Segment are now references to make it easier
to enable and gather the MONWRITE data from z/VM.
Change 23.059 -z/VM format MGVXCMG had wrong values for CSCCMCMG, the VM
FORMATS Channel Measurement Group, which should have been values
Mar 31, 2005 1-ESCON, 2-FICON, 3-HiperSockets for z/VM, like z/OS.
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 23.058 Cosmetic. Comments referencing Change 22.050 should have
VMACHMF been 20.018, and Change 22.162 should have been 22.168.
Mar 31, 2005
Thanks to Larry Stahl, IBM Global Services, USA.
Change 23.057 UTILBLDP enhancements. The USERADD= xxxx text required
UTILBLDP you to list the "product suffix" xxxx value (e.g., 7072)
Mar 30, 2005 but if you only listed part of the suffix (USERADD=70),
incorrect code was generated and you got errors. Now,
the USERADD= argument can either be the product suffix,
or an SMF record number processed by that product. And,
if you should list duplicate entries (USERADD=7072 72,)
UTILBLDP is now smart enough to remove the duplicates.
Thanks to Jake M. Drew, MBNA, USA.
Change 23.056 DB2 Trace dataset T102S199 was incorrect; it contained
VMAC102 only the first segment, and the DBID/OBID were formatted
Mar 30, 2005 only as $HEX2 when they should have been $HEX4.
Thanks to Karthik Vinayagam, Morgan Stanley, USA.
Change 23.055 Variable DSEXCP: the label should have been EXCP*COUNT*
VMACCTLT SINCE*CREATED, rather than USE*COUNT*SINCE*CREATED.
Mar 30, 2005
Thanks to Stephen Hahne, Capital One Financial Services, USA.
Change 23.054 All z/VM variables that had "SLOTS" in their label are
VMACVMXA now corrected to contain "BYTES" in their labels, as all
Mar 30, 2005 of the variables had already been converted from a count
of 'slots' to the count of 'bytes'. These variables also
had been correctly formatted with MGBYTES format; it was
only their label that was incorrect.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 23.053 Variables TTETIME, TTSTIME, and TITIME are now all on the
VMAC119 Local time zone, and their labels all have "GMT" removed.
Mar 25, 2005 TTETIME and TITIME were converted to local but had wrong
label, and TTSTIME was not coverted from GMT to local.
Thanks to Victor Chacon, Verizon Wireless, USA.
Thanks to Alan Klein, Verizon Wireless, USA
Change 23.052 -z/VM MONWRITE POSSIBLE BAD CONTROL RECORD were because
EOAPLSL0 the 1.17 record test should be SKIP=SKIP-16; instead of
EOAPLSLM SKIP-52. This caused many of the domain 1 records to be
EOAPLSLN skipped and were not output. Fortunately, these are the
EOAPLSLP seldom-needed startup information for MONWRITE, and the
EOdddddd 1.17 record is after all of the critical-to-MXG records.
VMACVMXA -The 1.19 record would have been skipped, as its test for
Mar 25, 2005 MRHDRRC should have been for 19 instead of 17.
-MXG architecture enhancement creates new EOdddddd members
and for "second Output" of a dataset, and defines new
macro tokens named _Odddddd for instream override of the
exit. This "second Output" exit is needed when raw data
is accumulated, so filtering of observations can't be
done during the "first Output" in the DATA step, but only
after the deaccumulation is available for creation of an
interval "usage" variable, USdddddd that is tested in the
new second Output EOdddddd exit member, so only intervals
with activity are output during the final pass of data:
-The EOdddddd member now tests to not output "nulls":
USdddddd=SUM(resources);
IF USdddddd GT 0 THEN DO;
OUTPUT _Ldddddd;
END;
-The MACRO _Odddddd %%INCLUDE SOURCLIB(EOdddddd); %
is defined in VMACxxxx, adjacent to the _Edddddd.
-The _Sdddddd macro sets contain:
IF DELTATM GT 0 THEN DO;
_Odddddd;
END;
Dataset updated thus far to only output active intervals:
Dataset - USdddddd Usage Activity Variable(s)
VXAPLSLP - TICKS (sum of all clock's ticks)
VXAPLSL0 - TICKS (sum of all clock's ticks)
VXAPLSLM - PGALLOC
VXAPLSLN - SUM(PKTSRCVD,PKTSSEND)
-Example in IHDRVMXA shows how you can skip domains and/or
records from being output, when you want to select which
datasets are created from MONWRITE data.
Some DATA step times reading 1024MB MONWRITE:
Elapsed CPU WORK MB Description
641 87 1382 Output ALL
589 61 902 Skip Domain 7 (SEEK)
413 20 20 Only Domain 10 (APPL SERVER)
321 18 0 No Output, READ ALL,DDecode Hdr
Change 23.051 Support for z/VM Linux Application Server data creates
EXAPLSLM four new datasets:
EXAPLSLN APLSLM VXAPLSLM LINUX MEMORY
EXAPLSLP APLSLP VXAPLSLP LINUX PROCESSOR SUMMARY
EXAPLSL0 APLSL0 VXAPLSL0 LINUX EACH CPU DETAIL
VMACVMXA APLSLN VXAPLSLN LINUX NETWORKING
VMXGINIT This support is preliminary, and is in process of being
Mar 16, 2005 validated - the clock tick duration value for Linux times
Mar 24, 2005 is not provided, so actual CPU time is not yet measured
in the VXAPLSLP/SL0 Processor records, and the Linux time
stamp is 18 to 20 seconds earlier than the start of the
MONWRITE interval; both issues are to be opened with IBM.
Thanks to Mike Reeves, Fidelity Systems, USA.
Thanks to Warren Cravey, Fidelity Systems, USA.
Thanks to Rachel Holt, Fidelity Systems, USA.
====== Changes thru 23.050 were in MXG 23.01 dated Mar 15, 2005=========
Change 23.050 z/VM MONWRITE dataset VXBYUSR didn't accurately recognize
VMACVMXA a new LOGON after the same VMDUSER had logged of, causing
Mar 11, 2005 incorrect DELTATM and CPU times for the first interval of
each LOGON in the MONWRITE file. The logic now tests for
a change in CALTODON to recognize each LOGON interval.
Thanks to Mike Salyer, CitiGroup, USA.
Change 23.049 MQ-Series Variable QWHCCV is renamed to QWHCCVMQ because
VMAC116 it conflicted with DB2 variable QWHCCV, and when MQ was
Mar 10, 2005 added to BUILDPDB, the MQ $HEX24. format on QWHCCV made
the DB2 QWHCCV jibberish.
You can make the DB2 QWHCCV print correctly simply
by adding FORMAT QWHCCV $12.; to your DB2 reports.
At the same time, variable QWHSSSID in MQ-Series is now
renamed to QWHSIDMQ and labeled 'MQ*SUBSYSTEM*NAME' so
that it wont override the DB2 QWHSSSID label.
Yes, I know that changing variable names may cause your
MQ Reports to fail, but since only bleeding-edge sites
have begun to use the MQ data, changing now is better
than changing later.
Thanks to Mike Gebbia, Eddie Bauer, USA.
Change 23.048 Amdahl CPUTYPE='2000'X does not populate SMF70ONT, z/OS
VMAC7072 up time of each engine, so for intervals when engines are
Mar 10, 2005 varied on or off line, MXG cannot accurately calculate
the true capacity, since it doesn't know how much of the
interval that varied engine was available. The result is
that NRCPUS counted 2 engines, but part of a third engine
was available, and the CPU time in RMF 72 Service Class
records slightly exceeded the CPUACTTM of those two CPUs.
This was detected ONLY by a NEGATIVE CPU UNCAPTURED TIME
warning from RMFINTRV, which compares the 70 and 72 CPU
times, and there is no cure for the Amdahl deficiency,
so this part of this change is only documentation of the
expected existence of that message with this processor.
(In TYPE70 for this interval, variable CAI3='03'x shows
the third engine was varied, so you can confirm the cause
of the warning message, but I can't use that information
to delete the interval without creating more questions!).
-In addition, this same interval record also caused error
DIVIDE BY ZERO; the unexpected SMF70ONT=0 value caused
PCTCPUBY to be zero when the new SHORTCPS variable was
created (the PCTCPUBY for this record is recalculated
later), but the real cause of the DIVIDE BY ZERO ERROR
was, as always, a programmer's error in not correctly
testing the divisor. IF PCTCPUBY GT . AND PCTMVSBY GT .
is now revised to test both variables for GT zero.
Historic Note: When I was using Netscape years ago,
and had reported erratic Divide by Zero errors and
had stated that this was clearly a programmer error,
their Senior Technician replied "a divide by zero
error is not a programming error - it is a normal
event that happens with Windows". B.S.: A DIVIDE
BY ZERO ERROR IS ALWAYS A PROGRAMMING ERROR.
I later found Netscape's problem; I had printed and
the printer was there, but when I had turned off the
printer, Netscape failed to test that the printer
was still alive, and failed with the DIVIDE error.
Thanks to Robert Blackburn, Dominion Resources Services, Inc, USA.
Change 23.047 The date part of READTIME, JHRRDOD, was changed from PD4
VMACESPH 0101303F for 30Oct2001 to 2005066F for 07Mar2005, causing
Mar 10, 2005 INVALID ARGUMENT TO FUNCTION DATEJUL when MXG read the
changed data format. MXG now tests for the new format.
Thanks to Larry Riggen, Cinergy, USA.
Change 23.046 -DB2ACCT vars QXCRESEQ,QXALTSEQ,QXDROSEQ,QXPRRESI,QXALTVW
VMACDB2 were incorrectly INPUT in DB2 V7 records; those fields
Mar 10, 2005 only exist in DB2 V8. The test IF LENQXST GE 440 for
that INPUT should have been GE 460.
-Those five QX variables were not INPUT at all in the STAT
records, but now are kept and deaccumulated in DB2STATS,
for DB2 Version 8.
-Variable QBGAWS was incorrectly INPUT in DB2 V7 records,
but it only exists in V8; logic was corrected.
Thanks to Allan Winston, MBNA, USA.
Change 23.045 Support for TMS Release 11 is already in place in MXG, as
TYPETMS5 the Appendix A for the TMC Volume and DSNB records shows
Mar 9, 2005 no changes to those records.
Thanks to Norm Hollander, CA, USA.
Change 23.044 Two new variables were added to ASUMCACH, and new member
ASUMCACH TRNDCACH was created:
TRNDCACH NREXPOSR - Maximum number of exposures during interval
Mar 9, 2005 INTCHGEX - Number of intervals in which exposure count
changed.
Also, labels for IORATE, IORATEC, and DURATM now exist.
Thanks to Diane Eppestine, SBC, USA.
Change 23.043 Global Macro Variables EPDBVAR,EPDBCDE,EPDBOUT are now
VMXGINIT defined in VMXGINIT, and referenced in their counterpart
EXPDBVAR EXPDBVAR,EXPDBCDE, and EXPDBOUT members, so that UTILBLDP
EXPDBCDE can use those macro variables for "instream" tailoring.
EXPDBOUT
Mar 9, 2005
Change 23.042 New SAS options DMSLOGSIZE=999999 and DMSOUTSIZE=999999
CONFIGV9 with those maximum values that increase the number of
Mar 9, 2005 lines that can be sent to the log or list windows; the
old limit was 99,999. Unfortunately, these options must
be set at SAS initialization, and cannot be set in the
autoexec.sas file under ASCII. For ASCII execution, you
must either update your sas.cfg file, or you can add
-dmslogsize 999999 to the options in your SAS icon.
Thanks to Kevin Hobbs, SAS Institute Cary, USA.
Change 23.041 This new analysis member calculates the DELTATM between
ANAL30V the end of one SMF 30 interval to the start of the next
Mar 8, 2005 interval for each job, and it also calculates SWAPEDTM,
the duration when the job was swapped out after the true
INTETIME end-of-interval. The true "resource duration"
of each type 30 interval record (subtype 2, 3, and 6) is
from INTBTIME to INTETIME, but if a task is swapped out
at the end of the interval, the SMF record is not written
until the task is swapped back in, which can be minutes
or hours later, and since no resources were consumed
while the task was swapped out, SMF resets the INTBTIME
of the next interval to the SMFTIME of the prior record.
So if you look at just the time between INTETIME and the
next INTBTIME, you can see very large values, because it
is the sum of SWAPEDTM plus DELTATM, but in a test with
70,000 interval records, I found a maximum DELTATM value
of only 0.37 seconds. I did discover that the "normal"
sort sequence of READTIME JOB JESNR INITTIME was not
sufficient for some started tasks (notably OPSOSF) that
have multiple instances per system and that start before
SMF initialization - those STCs have missing JESNR, but
had identical values for those variables for what were
separate instances, so SYSTEM ALOCTIME LOADTIME were
inserted in the sort sequence to separate them; if that
heuristic fails, the DELTATM can be a negative value.
Thanks to Dave Thorn, SUNGARD, USA.
Change 23.040 Condition Code/Return Code 0004 is set in ANALPRTR due to
ANALPRTR WARNING:APPARENT SYMBOLIC REFERENCE xxx NOT RESOLVED
Mar 8, 2005 when there were no observations in PDB.ASUMPRTR; those
two macro variables are normally created by CALL SYMPUT
in a DATA step, but when there are no observations, that
data step is not executed. To resolve the reference, the
%LET EARLIEST=; and %LET LATEST=; statements are inserted
at the beginning of the member, so there is no unresolved
macro even when there are no observations.
In this open code, the choice was either to use the
pair of %LETs, or to put both macro variables in a
%GLOBAL statement. Both choices effectively "GLOBAL"
the macro variable, since its value will exist for any
later program that references that same name. One big
difference is that using %GLOBAL does not change the
value if the macro variable was already %GLOBALed, so
you could (accidentally?) pick up a prior value, while
the %LET will set the always reset the macro variable
value. Finally, while not documented in Change 19.230,
using %GLOBAL to initialize macro variables to null
saved measurable CPU time, compared with using the
several hundred %LET statements, so the VMXGINIT
member now only uses %LETs where a non-null initial
value is required. If ANALPRTR were pervasively used,
I'd have put these two macro variables in VMXGINIT,
but it is very old analysis, and the CPU times that it
estimates are way out of date, and new printer devices
may not be amenable to its thruput measurements, so
using the two %LETs was the simple choice.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.039 Archaic variable QTXASUS is now set missing; long ago it
VMACDB2 was replaced by QTXASLOC, and while it was documented as
Mar 7, 2005 archaic in ADOCDB2, it caused confusion because it had a
value, when it should no longer be used. Instead, the
three variables QTXASLOC, QTXASLAT and QTXASOTH break out
the suspends for Lock, Latch, and Other conflicts.
Thanks to Marty Pruden, Nestle Purina PetCare Co., USA.
Change 23.038 Code was revised to eliminate MISSING VALUE messages by
VMAC30 either relocating calculations or by testing prior to
Mar 7, 2005 the calculation.
Change 23.037 -TYPE30MU and TYPE89 variable MULCURD is now forced to be
VMAC30 a missing value when the MULCUDF/MULCURT is zero, so that
VMAC89 a value is not carried forward when there are multiple
Mar 7, 2005 segments.
-The TYPE30MU decoding now expects MULCUDF=2 to be &PIB.8.
and MULCUDF=3 to be &RB.8., which is consistent both with
IBM documentation and the SMF 89 record descriptions.
All of my 30 test data has MULCUDF=2 with MULCURD=0, or
has MULCUDF=0, so this correction has not been confirmed
with real data; I do have 89 test data with MULCURT=2 and
binary values for MULCURD, so it makes sense to align the
MXG calculations in 30s with those in the 89 records.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.036 Using %UTILBLDP with BUILDPDB=NO and INCLAFTER=RMFINTRV,
UTILBLDP Condition Code 4 was set with SAS V9, because RMFINTRV
VMXGRMFI was not protected with OPTIONS DKROCOND=NOWARN when it
Mar 9, 2005 was executed outside of BUILDPDB code. Now, RMFINTRV
is internally protected, and, in addition, when %UTILBLDP
is used with BUILDPDB=NO, it generates DKROCOND=NOWARN
at the top and resets to DKROCOND=WARN at the bottom.
OPTION DKROCOND=NOWARN is extremely useful for MXG;
it lets me have variables in the KEEP= list that are
optional (e.g.: CICSTRAN has a lot of optional vars
that won't exist unless you open the comments in the
appropriate IMACICxxx tailoring member; using NOWARN
suppresses the normal warning that those variables were
not referenced). But prior to SAS V9, NOWARN was just
my convention to keep unneeded messages from your log;
in V9, SAS now sets Condition Code 4 with WARN, so it
is now necessary to protect all known instances in MXG.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.035 The incorrect references to _LTY30TD were replaced with
UTILBLDP _WTY30TD.
Mar 7, 2005
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.034 The addition of a new dataset (TYPE30TD) to VMAC30 caused
ANALJOBE the old ANALJOBE program to fail, because I failed to add
Mar 7, 2005 the needed override for that new dataset into ANALJOBE.
Adding overrides for that dataset would have worked, but
Scott very nicely revised the logic to use the _Vdddddd
macro tokens so that new datasets could be added to any
of the VMACxxxx members used in ANALJOBE, transparently,
and I don't have to remember to revise ANALJOBE to keep
up with future new datasets in the VMACx it uses!
He also removed the hardcoded MACJBCK= statement which
prevented the use of an instream MACKEEP=.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Sam Bass, McLane Co., USA.
Change 23.033 Example in comment should have been UTILS2ER instead of
UTILS2ER FINDS2ER, which was the earlier iteration; the member
Mar 7, 2005 FINDS2ER should not have been kept and is now deleted.
Thanks to Tom White, SPRINT, USA.
Change 23.032 Variables ASID and TARCASID were not formatted $HEX4. but
VMACTMNT now they are. ASID was only $HEX2. and TARCASID had no
Mar 6, 2005 format, so it printed a decimal value.
Thanks to Scott Chapman, American Electric Power,USA.
Change 23.031 Variables SRCDSN and TRGDSN do not exist in ICEBR8SN data
VMACICE set, but were accidentally in the KEEP= list, causing
Mar 6, 2005 confusion. They are now removed.
Thanks to Doug Medland, IBM Global Services, CANADA.
Change 23.030 -ML-33 of MXGTMNT corrects zero values in these variables
ASMTAPEE in the TYPETARC Tape Allocation Recover Event records:
Mar 2, 2005 DEVNR and UCBTYPE were all 0s.
DEVNRCHR was blank
TARCSTRT and TARCEND had the same timestamps.
TARCELAP was 0
TYPESCRN was always 0.
-ML-33 Mount records now have the Mount Time stamp from
the mount message. Hardware errors caused a 20 minute
delay between allocation reserving the drive and the
issuance of the mount message. Allocation handed off to
OAM the request for the mount, but before issuing the
mount, OAM first made a call to the library to get
eligible device pools. Because of the VTS harware
problems, it was late in responding to the request,
causing the mount message to be delayed.
-Mar 11: Mount Records Mount Time is still not correct;
under investigation.
Thanks to Scott Chapman, American Electric Power,USA.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 23.029 The display format for the average service times, which
VMAC74 are in milliseconds, are now printed by default to show
Mar 1, 2005 three decimal places:
AVGCONMS AVGDISMS AVGIOQMS AVGENQMS 6.3
AVGPNCHA AVGPNCUB AVGPNDEV AVGPNDMS AVGRSPMS 6.3
The need for this higher resolution is because the z990
changed the measurement resolution from 128 microsecond
units to one-half microsecond; Pat showed that with a
real value of 192 microseconds, the old resolution with
truncation was reported as .1 millisecond, but with the
new resolution and rounding, the disk service time was
reported as .2 milliseconds per SSCH, causing concern
that service time had increased, when, in fact, there
was not change in the actual service time, but a great
improvement in the measurement of disk service times.
His full paper on this subject, "Understanding the
Differences between z900 and z990 Service Time
Measurements" is available at http://www.perfassoc.com.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 23.028 DB2STATS variables QDSTCIN2 and QDSTNADS had very large
VMACDB2 values. MXG deaccumulated them, because IBM documentation
VMACDB2H did not indicate otherwise, and early test data had all
Mar 1, 2005 zeroes, but data now shows they should not have been DIFd
and both are no longer deaccumulated.
-Record with only header 1 and header 2 created false
error message that header was invalid.
Thanks to Peter Farrell, Commerce Bank, USA.
Change 23.027 Support for IMPLEX Versions 3.1 and 3.3.
VMACMPLX
Feb 28, 2005
Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 23.026 -Byte-containing fields were carried as characters; they
VMACWWW are now numeric with MGBYTE format to "print pretty".
Feb 28, 2005 -IIS Web Logs printed INVALID THIRD ARGUMENT FOR SUBSTR
Mar 2, 2005 because MXG did not expect a zero length URIQVALU.
Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 23.025 %UTILCONT(PDB=PDB); failed if //PDB was DISP=NEW, with
UTILCONT ERROR: LIBRARY DATA SET xxx.PDB CANNOT BE OPENED BECAUSE
Feb 28, 2005 IT IS EXTERNALLY ALLOCATED DISP=NEW OR DISP=MOD,
Mar 7, 2005 AND IT RESIDES ON MULTIPLE VOLUMES
The cause is our choice to not issue PROC CONTENTS if the
DDNAME points to a sequential library, unless you told us
to by removing SEQUENTIAL from the EXCLUDE= opearand.
(The CONTENTS against a sequential library has to read
the entire library, including all datasets, because there
is no directory in sequential librarys). The problem is
that we cannot detect the engine unless the library:
a) has had activity, or
b) a LIBNAME statement has been issued.
To solve that old problem, we used a LIBNAME xxx DISP=SHR
in UTILCONT so we could always know the engine of the
library, but that is what caused this error!
In this redesign, for z/OS only, when PDB= is a list of
one or more DDNAMEs, the LIBNAME is issued only when the
DD is not allocated, then a %VGETENG determines the
engine, the MXGENG dataset is deleted, and %VGETENG is
reinvoked to get to get the full list of all datasets in
that library.
Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.
Thanks to Paul Naddeo, FISERV Phildelphia, USA.
Change 23.024 CONTROL-D SF2 records were INCOMPATIBLY changed; fields
VMACCSF2 for SF2PAGE and SF2DPAGE were increased in place from 6
Feb 25, 2005 to 8 bytes.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 23.023 ABEND 878-10 with REGION=180M got thru seven systems data
ASMRMFV before the failure. REGION=200M processed the data from
Feb 25, 2005 all ten systems at one time.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.022 -Support for VSM subtype 30.
VMACSTC -HSC V6 made changes to subtype 4, STCVMU dataset, but the
VMXGINIT SMF record does not agree with the documentation, and the
IMACSTC result is large and invalid values. No MXG change has
EXSTCV30 been made, pending STK corrections to their data or doc.
Feb 24, 2005 -Apr 18: Debugging PUT statement, un-commented in tests of
Apr 18, 2005 this enhancement, is now re-commented, as it printed an
un-needed line of text on the log for each STC record.
Thanks to Michael Creech, Fidelity Information Services, Inc, USA.
Change 23.021 -LP0xxxxx variables were not populated; Change 22.293 was
VMAC7072 not properly migrated from test to my master library.
VMXG70PR Only LP0MGTTM is populated with the CPU time, since all
Feb 23, 2005 PHYSICAL CPU time is really "management" time.
Feb 28, 2005 -Variable SHIFT was added to PDB.ASUM70LP dataset.
Oct 31, 2005: See Change 23.276.
Thanks to Ken Jones, Xwave, CANADA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 23.020 Support for CyberFusion user SMF record.
EXCYFUSN
IMACCYFU
TYPECYFU
TYPSCYFU
VMACCYFU
VMXGINIT
Feb 23, 2005
Thanks to Robin Murray, ManuLife, CANADA.
Change 23.019 Although using DCOLLECT (see JCLDAYDS JCL example) is the
ASMVTOC recommended way to "graze" your DASD farm, ASMVTOC can be
Feb 21, 2005 used, but the comments did not give an example of how to
use the //VOLLIST DD to exclude volumes. The comments
now show the explicit syntas.
Thanks to Brian Crow, British Telecom, ENGLAND.
Thanks to Fabio Massimo Ottaviani, DTSITALIA, ITALY.
Change 23.018 Invalid ID=9 record caused ARRAY SUBSCRIPT OUT OF RANGE,
VMXGGETM when UTILGETM was used by JCLTEST8. The SMF 9 record
Feb 18, 2005 does NOT contain a subtype, but the first byte was '7F'x,
with bit 1 (the '40'x bit) on, and that caused MXG to
read the bytes 19-20 as a two-byte SUBTYPE value, which
contained '0200'x, so SUBTYPE=512. Subtype was originally
a one-byte field, so only values of 0-511 were valid
subtypes. But as subtypes can now be two bytes, and
because the array is only used in VMXGGETM to tabulate
the count of SMF IDs and their SUBTYPEs, MXG only
intended to count subtypes 0-511 (and it protected known
larger subtypes, like CICS records from Boole & Babbage
by resetting them). The array error was because MXG's
protection was incorrect, the statement IF SUBTYPE GT 512
should have been IF SUBTYPE GT 511, and that is the
statement corrected by this change. The 02 value in byte
19 that caused SUBTYPE=512 is SMF9VPC, which identifies
the issuer of the Vary Path command that caused this SMF
9 to have been written, and I now see a new value
described:
2=Enterprise System Connection Manager
previously, only 0=Operator was written, which explains
why we are now correcting this problem in VMXGGETM. BUT:
The real error is that Bit 1 in SMF9FLG is on, which says
there's a valid subtype, which is not true for ID=9.
Thanks to Charles Bellamy, SCANA, USA.
Change 23.017 If %INCLUDE SOURCLIB(ASUMUOW) is used (JCLTESTV8/9 do),
VMXGUOW but IMACUOW was not updated to tell MXG that you want us
Feb 17, 2005 to create observations in PDB.ASUMUOW, your job will fail
ERROR: NO BY STATEMENT USED OR NO BY VARIABLES SPECIFIED
WARNING: DATASET WORK.UOWSORT MAY BE INCOMPLETE.
You were not supposed to have to update IMACUOW, but the
changes we made to add MQ-Series data to PDB.ASUMUOW were
always tested with a tailored IMACUOW; I failed to test
with the default IMACUOW in MXG 22.22, and we always
build the PDB.ASUMUOW dataset in our QA streams, to make
sure it is created without error.
The source of the problem is arguably a SAS design error;
we added the creation of a second dataset in a data step
whose first dataset was created as a VIEW, but the
default IMACUOW sets OPTIONS OBS=0; to prevent ASUMUOW
from sorts of both CICSTRAN and DB2ACCT. Unfortunately,
it turns out that that second dataset is NEVER created
when OBS=0 is in effect. While SAS Technical Support
investigates to see if this is a feature or a defect, we
circumvent the error by always creating that dataset
(_UOWCIC) with zero obs, before the data step with the
VIEW, so that it always will exist. If you enable IMACUOW
to create obs, the dataset is re-created with obserations
when the VIEW is executed.
Thanks to Alan Chenoweth, EDS, USA.
Thanks to Linda Piekarski, National Grange Mutual Insurance Co., USA.
Change 23.016 A VM 4.4 system's MONWRITE control block data contained a
VMACVMXA value of 00028709X instead of the normal 00008709X;
Feb 17, 2005 change line 5071 to test for both values:
IF IPARMLF1 NE 00008709X AND IPARMLF1 NE 00028709X THEN DO;
while we await a reply from IBM VM Support as to whether
this is an error or an undocumented feature.
Thanks to Mike Salyer, Citicorp, USA.
Change 23.015 If you create a WEEK.SMFINTRV or MONTH.SMFINTRV, your job
MONTHASC may get ERROR: BY VARIABLES NOT SORTED MON.SMFINTRV. The
MONTHBL3 sort order of PDB.SMFINTRV was changed in MXG 22.13 for
MONTHBLD Change 22.320 consolidation of MULTIDD='Y' observations.
MONTHBLS The original BY list in BUILDPDB was:
MONTHDSK READTIME JOB JESNR INTBTIME INTETIME
WEEKBL3 and the new sort order internally is
WEEKBL3D READTIME JOB JESNR INITTIME INTBTIME
WEEKBL3T In the cases that failed, there were multiple instances
WEEKBLD of the same STC JOBNAME that was an "early ASID" that had
WEEKBLDD started before SMF (i.e., it did NOT have a JESNR), and
WEEKBLDT both interval records had exactly the same values for
Feb 16, 2005 READTIME JOB JESNR and INITTIME, but the INTBTIMEs were
.01 seconds out of order, causing the NOT SORTED.
The solution is simple: in your WEEKBLD/MONTHBLD members,
change the BY list for the PDB.SMFINTRV dataset to only:
READTIME JOB JESNR
to eliminate the exposure.
-While using %INCLUDE SOURCLIB(TYPS30) will create dataset
PDB.SMFINTRV, that is no longer a recommended way,
because that dataset still contains the multiple
MULTIDD='Y' obs. See the example in the text of Change
22.320 if you want to create PDB.SMFINTRV directly from
SMF without BUILDPDB.
Thanks to Kevin Fletcher, CONSECO, USA.
Change 23.014 Consoldiated into Change 23.012.
Change 23.013 -Variable LPARCPUX is now kept in TYPE70PR, because it is
VMAC7072 the count of logical CPs assigned to the LPAR, and that
Feb 13, 2005 includes the number of "initial" CP engines, the number
of "reserved" CPs (which also includes ICFs, IFLs, and
IFAs that are assigned to the LPAR). This is important so
that enough "reserved" CPs can be known for each LPAR.
If too few reserved CPs were defined, you cannot
non-disruptively use Dynamic Capacity Upgrade on Demand
to implement an upgrade to an LPAR.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.012 -Typos in MXG 22.22 JCL examples:
COVERLTR -JCLTEST9: Line 130, WORKVOL=5 needs a comma.
JCLTEST8 Lines 166,168 need // in col 1 and 2.
JCLTEST9 Line 392 should be MXGSASV9
MXGSASV9 -JCLTEST8 and JCLTEST9:
MXGSASV9 //TESTQAPM step needs //QAPMJSUM DD DUMMY.
README -MXGSASV9: Lines 58 and 60, JCL needs //.
UPRINDOC -MXGSASV8 and MXGSASV9: the INSTREAM DD should be:
Feb 12, 2005 //INSTREAM DD UNIT=SYSDA,SPACE=(CYL,(1,20)),
Feb 22, 2005 // RECFM=FB,LRECL=80,BLKSIZE=0
Feb 23, 2005 The change to LRECL=72 caused unnecessary error
May 23, 2005 when UTILS2ER was run, and there's no value in
changing the historic LRECL from 80 to 72.
-Coverltr: Ref to Change 22.133 should be 22.123 for V9.
-README File on CD and the README member was missing an
equal sign: SPACE=(80,2,1)) SPACE=(CYL,(25,5)).
The PUT should be PUT 'c:\mxgcd\ieb....'.
-UPRINDOC: JCL example was missing ending comma, line 11.
Comments updated for example ASCII execution.
The program works, but produces an error; the
lines after the RUN; after %INCLUDE INSTREAM;
were debugging lines that should be deleted.
Thanks to Linda Piekarski, National Grange Mutual Insurance Co., USA.
Thanks to Sam Bass, McLane Company, USA.
Thanks to Jack Basile, PCH, USA.
Thanks to Francisco Ojeda, SAS Cary, USA.
Thanks to John Mattson, EPSON, USA.
Thanks to David Klein, DOITT, City of New York, USA.
Thanks to Sam Bass, McLane Company, USA.
Thanks to Brian Felix, Wachovia Corporation, USA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 23.011 MXG 22.22-22.12. DB2 variables QWHT../QWHU../QWHD./QWHA..
VMACDB2H from DB2 Trace, CPU, Distributed, Data Sharing Header may
Feb 11, 2005 be blank or missing; the extraneous statement at line 130
Feb 25, 2005 LENLEFT=LENGTH-COL+1;
May 20, 2005 must be deleted. Of course, they can also be blank when
those headers don't exist in a particular record, which
is completely normal! In addition, for SMF records that
are created from TMON/DB2 data, that statement caused the
INPUT STATEMENT EXCEEDED RECORD LENGTH, error: TMON SMF
records have headers at the start, rather than the end of
the SMF record (which is okay, since they are relocatable
sections with a "triplet" location pointers); it was MXG
recalculation of LENLEFT that was the cause of the error.
May 20,2005: This error also causes THREADTY variable to
be blank when it shouldn't be!
Thanks to Marty Pruden, Nestle Purina PetCare Co, USA.
Thanks to C. C. VanHook, DST Systems, USA.
Thanks to Steve Cunningham, DST Systems, USA.
Thanks to Craig Gifford, City of Lincoln NE, USA.
Change 23.010 Some fields that could contain '00'x are translated to a
VMAC119 blank value. RACFUSER, TTPOL, TTPROF, FCHOSTNM, FCM1,
Feb 8, 2005 FCRS, FCSUSER, and UDLPHIGH.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.009 The RACF Database "Installation data" filed, INSTDATA,
VMACRACF can be $255, but only $40 was input.
Feb 8, 2005
Change 23.008 -Invalid ESS data that cannot be corrected in MXG caused
IMAC6ESS INPUT STATEMENT EXCEEDED. 0038x segment had Length=127,
VMAC6 but only 27 bytes of data, 0027x segment had length=0.
Feb 3, 2005 While IBM is contacted to resolve their errors, the only
circumvention is to insert MACRO STOPOVER MISSOVER %
as the first statement after //SYSIN. You will still see
MXGWARN: UNDECODED KEYS IN EXTENDED SMG 6 ESS DATA notes.
-A 0047x segment had 64 bytes when MXG expected 62, so the
size of FSSDATA field was increased to 99 bytes in this
change.
-The 0044x segment is supported creates ESSOFSTY variable.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 23.007 Five CPU variables in QAPMJOBL were incorrectly input as
VMACQACS milliseconds (&PD8.3) instead of microsedonds (&PD.8.6).
Feb 3, 2005 The "8.3" was changed to "8.6" for these variables in
the VMACQACS (with Change 22.371 as the last change):
JBCPU 5672
JBRUT 5736
JBSZWT 5757
JBTCPU 5780
JBMTXT 5792
Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.
Change 23.006 -Support for RACF Events 32-34,38-39,42-45,48,50,54-55,57,
EXTY8032 59,61-62, and 64 creates these
EXTY8033 these 18 new TYPE80A datasets:
EXTY8034 dddddd Dataset Description
EXTY8038 TY8032 TYPE8032 RACF EVT 32 CHANGE DIRECTORY
EXTY8039 TY8033 TYPE8033 RACF EVT 33 CHANGE FILE MODE
EXTY8042 TY8034 TYPE8034 RACF EVT 34 CHANGE FILE OWNERSHIP
EXTY8043 TY8038 TYPE8038 RACF EVT 38 INIT OF PROCESS
EXTY8044 TY8039 TYPE8039 RACF EVT 39 TERM OF PROCESS
EXTY8045 TY8042 TYPE8042 RACF EVT 42 MAKE DIRECTORY
EXTY8048 TY8043 TYPE8043 RACF EVT 43 MAKE NODE
EXTY8050 TY8044 TYPE8044 RACF EVT 44 MOUNT FILE SYSTEM
EXTY8054 TY8045 TYPE8045 RACF EVT 45 OPEN NEW FILE
EXTY8055 TY8048 TYPE8048 RACF EVT 48 REMOVE DIRECTORY
EXTY8057 TY8050 TYPE8050 RACF EVT 50 SET EFFECTIVE UID
EXTY8061 TY8054 TYPE8054 RACF EVT 54 UNLINK
EXTY8062 TY8055 TYPE8055 RACF EVT 55 UNMOUNT FILE SYSTEM
EXTY8064 TY8057 TYPE8057 RACF EVT 57 CHECK PRIVILEGE
IMAC80A TY8059 TYPE8059 RACF EVT 59 RACLINK
VMAC80A TY8061 TYPE8061 RACF EVT 61 IPCGET
VMXGINIT TY8062 TYPE8062 RACF EVT 62 IPCCTL
Feb 9, 2005 TY8064 TYPE8064 RACF EVT 64 CHKOWN2
-SMF 80 records with SMF80EVT=0 were discovered and were
being output to TYPE80CM dataset (which should always
have zero observations, since it is used only for events
that are not supported in MXG, and once you have one of
those events and send the SMF data, that event will be
supported!). IBM APAR OA03336 documents on condition
that causes SMF80EVT=0 and installing the PTF for that
APAR eliminated the RACFEVNT=0 observations.
Thanks to Peter Schubert, CITEC, AUSTRALIA
Change 23.005 An old VMXGSUM member in "USERID.SOURCLIB" caused message
VMXGSUM ERROR: APPARENT MACRO VGETENG NOT RESOLVED in BUILDPDB.
VMXGVERS The INSTALL instructions remind you to remove all of the
Feb 2, 2005 VMXGxxxx & VMACxxxx members from your tailoring library
when you install a new version. But even if you enable
diagnosic OPTIONS SOURCE SOURCE2 MACROGEN MPRINT; we can
only see members %INCLUDEd from your library; %VMXGxxxx
members are AUTOCALLed %MACROs, and they do not print the
source text on the log. To prevent these errors due to
a back-level %VMXG.... or %VGET.... macro, each of them
now invoke the %VMXGVERS macro that compares the member's
internal version number with the current MXG version, and
if they are inconsistent, prints this message:
MXGERROR: VMXGxxxx IS BACK-LEVEL AT NN.MM, ....
reminding you to remove that back-level VMXGxxxx member.
Thanks to Bill Whitehead, Experian, USA.
Change 23.004 Support for SAMS Vantage "LSPACE" record subtype, creates
EXSAMLSP SAMSLSPC dataset.
IMACSAMS
VMACSAMS
VMXGINIT
Feb 1, 2005
Thanks to Christelle Abily, GICM, FRANCE.
Change 23.003 Unused Change.
Change 23.002 Comments only. Description of the arguments for SYSTEM=
ANALAVAI and APPn= were confusing, and have been clarified.
Feb 1, 2005
Thanks to Allen O. Homonyom, Department of the Army, USA.
Change 23.001 NDM Subtype 'SY' caused INPUT STATEMENT EXCEEDED RECORD
VMACNDM error; the length in NDMSYOPL included itself, which was
Jan 30, 2005 not documented, causing MXG to read one byte too many.
After the @; after the INPUT of NDMSYOPL, insert
IF NDMSYOPL GT 0 THEN NDMSYOPL=NDMSYOPL-1;
Thanks to Victor Chacon, Verizon Wireless, USA.
LASTCHANGE: Version 23.
=========================Member=CHANGE22================================
/* COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 22.22 is dated Feb 1, 2005, thru Change 22.378
Early MXG Version 22.22 was dated Jan 22, 2005, thru Change 22.366
MXG Version 22.13 was dated Jan 13, 2005, thru Change 22.350
First MXG Version 22.13 was dated Jan 12, 2005, thru Change 22.345
Final MXG Version 22.12 was dated Dec 11, 2004, thru Change 22.316
Second MXG Version 22.12 was dated Dec 10, 2004, thru Change 22.313
First MXG Version 22.12 was dated Dec 2, 2004, thru Change 22.308
MXG Version 22.11 was dated Oct 26, 2004, thru Change 22.277
MXG Version 22.10 was dated Oct 13, 2004, thru Change 22.264
MXG Version 22.09 was dated Aug 25, 2004, thru Change 22.227
Final MXG Version 22.08 was dated Aug 20, 2004, thru Change 22.219
Second MXG Version 22.08 was dated Aug 13, 2004, thru Change 22.207
First MXG Version 22.08 was dated Aug 12, 2004, thru Change 22.205
Final MXG Version 22.07 was dated Jul 25, 2004, thru Change 22.180
MXG Version 22.07 was dated Jul 23, 2004, thru Change 22.177
MXG Version 22.06 was dated Jun 15, 2004, thru Change 22.129
MXG Version 22.05 was dated May 22, 2004, thru Change 22.108
MXG Version 22.04 was dated May 2, 2004, thru Change 22.099
MXG Version 22.03 was dated Apr 5, 2004, thru Change 22.066
First MXG Version 22.03 was dated Apr 2, 2004, thru Change 22.063
MXG Version 22.02 was dated Mar 24, 2004, thru Change 22.055
MXG Version 22.01 was dated Mar 11, 2004, thru Change 22.036
First MXG Version 22.01 was dated Mar 10, 2004, thru Change 22.034
Final MXG Version 21.21 was dated Feb 11, 2004, thru Change 21.320
MXG Newsletter FORTY-FOUR was dated Feb 11, 2004.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 22.22 is now available upon request.
II. Incompatibilities and Installation of MXG 22.13.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 22.22 is available upon request.
Major enhancements added in MXG 22.22
BUILDPDB 22.365 BUILDPDB now sets Condition/Return code of zero.
ASUMMIPS 22.354 Interval Capacity by Workload, MIPS and MSU used.
ASMTAPEE 22.366 MXGTMNT ML-32, has MEXIT=ON,XMEMF=ON,ARCV=ON
TYPE110 22.359 Support for CICS/TS 3.1 with no EXCLUDEd fields.
UTILEXCL 22.347 New CICS/TS 3.1 WBREPRDL/WBREPWDL/PGCRECCT supported.
TYPE7072 22.349 Negative PCTMVSBY/CPUMVSTM/SHORTCPs, SMF70CNF bit 6.
TYPE30 22.375 IBM error in CPUIFATM, MXG error in SRVTCBTM.
TYPETPF 22.374 Support for MQ Series in TPF operating system.
TYPEQACS 22.371 Support for OS/400 5.3.0, new QAPMSYS dataset.
TYPEVMXA 22.369 Support for z/VM 4.4 and 5.1 new data (INCOMPATIBLE).
Major enhancements added in MXG 22.13
BUILDPDB 22.342 TYPE115/TYPE116 are now in BUILDPDB, will cause error
if you have already tailored MXG to add 115/116s.
You must remove your 115/116 tailoring from EXPDBxxx
or you will get this error message if you miss this:
ERROR: DATA SET WORK.MQMLOG IS ALREADY OPEN ....
BUILDPDB 22.320 MULTIDD='Y' obs now combined in PDB.SMFINTRV.
BUILDPDB 22.326 Variable CPUCEPTM now deaccum in PDB.SMFINTRV.
TYPE110 22.312 Support for CICS/TS 3.1 (INCOMPATIBLE).
UTILEXCL 22.350 Support for CICS/TS 3.1 new fields, errors fixed.
ASUMUOW 22.336 MQMACCT/MQMACCTQ data can be added to PDB.ASUMUOW
TYPE70 22.325 "Short CPs" variable SHORTCPS created in TYPE70.
TYPE70PR 22.325 "Short CPs" variable SHORTCPS created in TYPE70PR.
TYPETNG 22.339 Major TNG enhancement - array sizes dynamically set.
TYPE74 22.334 Support for APAR OA06476 type 74 subtype 5 and 8.
ONLYINTV 22.326 Example to build only PDB.SMFINTRV/PDB.TYPE30_6.
TYPE6 22.321 Support for second format type 6 PrintWay record.
TYPE7072 22.340 Revision to support for varying IFAs online/offline.
IMAC6ESS 22.332 Support for GEPARMKY 0036, 0041, 0043, fix 0034x.
TYPEHIOM 22.331 Support for hIOmon File I/O Performance Monitor.
This is a Windows environment monitor that tracks
I/O activity to the filename and user.
MONTHDSK 22.343 "MONTHBLD" program to build MONTHLY PDB on disk.
Major enhancements added in MXG 22.12
MXG 22.12 corrects IRD errors introduced in MXG 22.10/22.11.
MXG 22.12 corrects TYPE6 errors introduced in MXG 22.10/22.10.
TYPE6 22.309 Final correction for type 6 INPUT EXCEEDED errors.
TYPE6 22.298 SMF 6 STOPOVER on PrintWay section - missing @;
TYPE7072 22.307 Negative CPU values for IRD - Required CHANGE.
TYPEHURN 22.304 Support for ObjectStar subtype 45 Page Sweep.
TYPE6 22.302 Support for VPS V1 R8.0 VPS-FAX data
TYPE102 22.294 Support for APAR PQ73385,PQ91101 for IFCIDs 217, 225
TYPE102 22.294 Support for APAR PQ87848 for IFCID 173
TYPECIMS 22.314 Support for Mainview IMS IMF 4.1.00 (NO CHANGES!).
UTILEXCL 22.313 Support for APPLNAME,CANDEXNM,CANDEXTY CICS segments.
TYPENSPY 22.312 Support for NetSpy Version 7.0 (COMPATIBLE).
TYPEQACS 22.311 Support for OS/400 5.3.0 CONF/DISK/POLL/JOBL data.
ASMRMFV 22.316 Enhanced support for RMF III VSAM files.
TYPETNG 22.291 Support TNG NT Platforms NTW400I, WNS502I, ZPP501I.
VMACSMF 22.300 Use of FTP access to read SMF MVS-to-MVS supported.
ASUM70PR 22.293 LP0xxxxx variables now populated with PHYSICAL's data
CICINTRV 22.288 Comments show how to create PDB.CICINTRV from SMF.
VMXGPRAL 22.287 Enhancement to use PROC FREQ, example for 102 "who".
TYPE80A 22.286 Numerous enhancements, multiple RACF segments, etc.
ANALSIZE 22.276 Utility to analyze size of SAS data libraries.
ASUM70PR 22.274 Vars TOTSHARE/TOTSHARC kept for orig/current weights.
Major enhancements added in MXG 22.11
MXG 22.11 is NOW required for z/OS 1.6 with IFA/zAAPs, and it HAS
been tested with SMF 30, 70, and 72s from a system with real IFAs!
MXG 22.09 and MXG 22.10 do correctly support z/OS 1.6 without any
zAAP engines, but actual test data uncovered MXG errors and IBM
undocumented fields (Changes 22.272, 22.262, 22.265) that caused
most of the IFA/IFE fields to contain invalid values.
Additional enhancements in 22.11:
TYPE30 22.272 Support for zAAP IFA engines.
TYPE7072 22.272 Support for zAAP IFA engines.
TYPE30 22.265 Support for APAR OA09118, adds CPUCOEFF to SMF 30s.
TYPE94 22.268 Support for VTS R7.3 additional statistics.
TYPECMF 22.266 Support for CMF Version 5504 User SMF (INCOMPAT).
VMACDB2H 22.270 22.08-22.10 only. DB2 V8.1 INPUT STATEMENT EXCEEDED.
TYPE71 22.269 22.07-22.10 only. LPAxxxx variables missing values.
Major enhancements added in MXG 22.10
MXG 22.10 supports z/OS 1.6, but only if there are no IFA engines.
Additional enhancements in 22.10:
TYPE7072 22.260 Support for z/OS 1.6 WITH IFA engines.
TYPEVMXA 22.240 Support for z/VM 4.4, INCOMPAT.
TYPENTSM 22.246 Support for NTSMF Release 2.4.7 COMPATIBLE.
TYPEXAM 22.245 Support for XAMAP Release 3.4 INCOMPAT.
TYPETDSL 22.249 Support for TDSLink product's user SMF record.
TYPEBETA 22.250 Support for BETA93 Release 3.5 subtypes 0-5.
TYPETMDB 22.235 Support for ASG/Landmark TMON for DB2 V4.0 (COMPAT)
SYSLOG 22.238 Preliminary support for SYSLOG file.
ANALGART 22.242 Example analysis for Gartner Group requests.
ASUMCIMS 22.241 Example summarization of the four IMF datasets.
ERRORASC 22.239 ASCII platform errors when incorrect SMF download.
ANALFLSH 22.236 New member tracks concurrent flash copies executing.
TRND.... 22.258 Symbolics &TRENDINP,&TRENDNEW,&TRENDOLD added.
Major enhancements added in MXG 22.09
MXG 22.09 supports z/OS 1.6, but only if there are no IFA engines.
See Change 22.221 and especially MVS Technical Notes in NEWSLTRS.
Major enhancements added in MXG 22.08
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.
In addition, Syncsort's add-on product PROC SYNCSORT was found to
corrupt INFORMATs, causing fatal errors in BUILDPDB, but because
I could remove all MXG INFORMAT statements faster than they could
even examine their error, I believe you can safely use that add-on
with MXG code (but you'll need to check your own code for INFORMAT
and watch for their eventual revised version that will work with
SAS V9.1.2). Note, the errors are in the PROC SYNCSORT add-on
product (which prints "PROC SYNCSORT" on your SAS log if used).
We have not seen these errors with the Syncsort Sort product.
The Syncsort ticket number # SR387805 is open for PROC SYNCSORT.
The details of the MXG changes that support V 9.1.2 and V 9.1.3 are
in the change text of the below MXG changes, but for execution of
MXG under "MVS", the only critical changes required are to:
- Install MXG 22.08 and use MXGSASV9 and CONFIGV9 from 22.08, and
- Run the UTILS2ER utility against all of your source libraries to
see if any lines of your SAS programs conflict with S2=72 option
that was required to replace the previous S2=0 option in MXG.
Changes related to SAS V9.1.2 and MXG execution:
CONFIGV9 22.207 NOTHREADS specified for 9.1.2 error, fixed in 9.1.3.
(the NOTHREADS change caused the Aug 13 re-date of MXG 22.08!),
CONFIGV9 22.108 CRITICAL Hot Fix SN-012437 Required for SAS V9.1.2
CONFIGV9 22.123 SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.
MXGSASV9 22.130 Revised MXG JCL example for SAS V9, NLS names, etc.
MXGSASV9 22.126 SAS dsnames must be "W0", w-zero, not w-oh.
CONFIGV9 22.108 Support for V6SEQ under SAS V9.1
UTILS2ER 22.123 Utility to detect errors with S2=0 in your programs.
FLASH 22.108 CRITICAL SAS Hot Fix SN-012437 is REQUIRED for V9.1.2
Many 22.184 SAS V9.1.2 $VARYING design change protected.
AUTOEXEU 22.102 autoexec.sas file for unix, protects SASAUTOS error.
Some 22.108 Support for SAS V9.1 and V6SEQ without Hot Fix.
Many 22.192 Protection for PROC SYNCSORT error with SAS V9.1.2
Additional important enhancements in MXG 22.08:
TYPETMO2 22.191 Support for ASG/TMON TCE for CICS/ESA 2.3, COMPATIBLE
Many 22.180 Support for IFA CPU variables for zAAP processors.
Many 22.177 Update to define MACRO _Vdddddd for numeric SMF plus.
Many 22.192 All INFORMAT $NOTRAN statements were removed.
TYPEIMS7 22.199 Major revision to IMS0708 dataset, all events output.
VMACDB2H 22.196 Support for extended length DB2 id variables.
TYPENTSM 22.193 Support for NTSMF Exchange/Outlook/DTS CPU objects.
TYPENTSM 22.190 Support for NTSMF MicroStrategy Server objects.
TYPEOMVT 22.186 Omegamon/VTAM V520 IRNUM 29 Divide by zero corrected.
TYPE80A 22.185 Invalid SMF 80 Extended Relocate Section protected.
ANALRMFR 22.181 Enhancements to RMF reporting.
ADOC110 22.189 Major updated added 1300 lines of CICS documentation.
Note: The Aug 20 re-date of MXG 22.08 was made only because it was
easy to do; I discovered that members were missing from the
3480 tapes (not from ftp nor CD-rom shipments) and so I chose
to create replacement tapes with the added changes that were
made during the week.
Major enhancements added in MXG 22.07
TYPE7072 22.152 Support for IFA Processors, APAR OA05731.
TYPE7072 22.137 Support for z890 CPUTYPE 2086, OS/390-INCOMPAT.
TYPE74 22.141 Support for RMF 74 subtype 8 ESS Link Stats record.
TYPETNG 22.170 Support for TNG Windows Server 2003 new objects+fix.
IMACICHO 22.169 Hogan optional CICS data member now exists
TYPEHMF 22.168 Support for HMF V2.7 new subtypes, compatible.
TYPEHPDM 22.166 Support for STK ExHPDM user SMF record.
BUILDPDB 22.165 BUILDPDB detects overlapped SMF data previously read.
IMAC6ESS 22.161 Support for ESS GEPARMKY 003Bx and 0045x fields.
TYPETNG 22.160 REGION reduced for JCLTEST8 TESTOTHR due to TYPETNG.
UTILBLDP 22.149 Enhancement supports subtype selection in ZEROOBS.
VGETENG 22.148 Enhancement to get Engine and Device Type of LIBNAME
ASUM42DS 22.147 Performance enhancement reduce I/O, CPU using view.
TYPE119 22.146 TYP119nn datasets had GMT time zone, now have local.
JCLRMF 22.143 Example to create "RMF-only" PDB from SMF data.
ASUMUOW 22.139 Variables APPLID/USER/LUNAME/TERMINAL incorrect.
ANAL4GB 22.138 Revised to use DCOLLECT to detect large VSAM files.
IEFU84 22.136 SMF exit to get Initiator Name and Number for jobs.
ASUM70PR 22.135 MVS System Name of each LPAR, SMF70STN, added.
TYPE70 22.134 Percent when each engine online PCTONLN0-PCTONLNX.
TYPENDM 22.133 Support for several additional NDM-CDI subtypes.
TYPENSPY 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
TYPENETM 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
MXGSASV9 22.130 Revised MXG JCL example for SAS V9, NLS names, etc.
UTILCONT 22.175 Utility to Inventory the Megabyte Sizes of PDBs.
Major enhancements added in MXG 22.06
Really major:
Change 22.123 - SAS V9 on "MVS" INCOMPAT due to RECFM=VB on the
SAS-supplied SASMACRO library requires the MXG
default S2=72 be changed to S2=0, which itself
raises another potential incompatibility in SAS
programs, so new UTILS2ER must be run against
your SAS programs before migration to SAS V9,
or your programs may have strange ABENDs. See
extensive discussion in text of Change.
Change 22.121 - CPU time for DB2 Parallel Trans was not output
(i.e., lost, could be very large) in DB2ACCT.
See the Change text, and also the DB2 Technical
Note in Newsletter FORTY-FIVE.
CONFIGV9 22.123 SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.
UTILS2ER 22.123 Utility to detect errors with S2=0 in your programs.
TYPEDB2 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
TYPEDB2 22.124 MXG 22.04-05, QWHSSTCK missing in SMF 102 trace data.
EXDB2ACC 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
TYPEIPAC 22.125 Support for IPAC subtype 5 IPAC05 corrections.
IMAC6ESS 22.117 Support for optional ESS segment GEPARMKY=003Bx.
BUILDPDB 22.115 JES3 PDB only; wrong TYPE26J3 used in BUILDPD3.
TYPE102G 22.109 TYPE102G to read DB2 Trace written to GTF didn't.
BLDIMPDB 22.128 ASCII equivalent of JCL for JCLIMSLx execution.
TYPEIMSA 22.113 ASCII execution only, APPLID not readable.
TYPEEDGS 22.112 INPUT STATEMENT EXCEEDED with MVRECLEV '02'x.
ANALFIOE 22.127 Run time improvement if SMF, instead of PDB, input.
BLDSMPDB 22.111 unix case sensitivity corrections
BLDNTPDB 22.111 unix case sensitivity corrections
MXGSASV9 22.126 SAS dsnames must be "W0", w-zero, not w-oh.
Major enhancements added in MXG 22.05
CONFIGV9 22.108 Support for V6SEQ under SAS V9.1
FLASH 22.108 CRITICAL SAS Hot Fix SN-012437 is REQUIRED for V9.1.2
TYPE102C 22.104 Support for Candle Omegamon II for DB2 IFCID Trace.
AUTOEXEU 22.102 autoexec.sas file for unix, protects SASAUTOS error.
Major enhancements added in MXG 22.04
TYPE110 22.094 Support for CICS/TS 2.3 with no EXCLUDEd fields.
(If you use UTILEXCL with your CICS/TS 2.3 data,
there was no error, but CICSTRAN without IMACEXCL
was wrong if all fields were present in 110-1.)
TYPEQACS 22.095 Support for OS/400 5.2 QAPMMIOP record new fields.
TYPETNG 22.085 Support for NT objects SESSION and USER in TNG cubes.
TYPEAIX 22.083 Support for AIX PTX new objects.
TYPEIBSM 22.079 Support for IBM Session Manager user SMF record.
TYPETPMX 22.077 Support for alternative multiple-ACCT field TPM data.
TYPE74 22.075 Support for 1024 structures in Coupling Facility.
UTILEXCL 22.068 Support for optional RMI data in CICSTRAN.
VMXGINIT 22.096 Macro variables &MACINTV and &MAC30DD created.
TYPEDB2 22.090 MXG 22.02-22.03 only. QWHSSTCK 1960 date in DB2ACCT.
TYPEDB2 22.084 Large QBSTGET in DB2STATB due to DB2 restart fixed.
TYPE70 22.087 Non-PR/SM, IORATE/PCTTPI variables too low.
TYPE7072 22.072 TYPE72GO with R723CWMN GT 0, Periods not output.
MONTHASC 22.064 Example "MONTHBLD" for ASCII systems.
AUTOEXEC 22.064 LIBNAME DUMMY added to support MONTHASC.
Major enhancements added in MXG 22.03
Revision of ThruPut Manager TYPETPMX to not use ARRAYS to save CPU.
(34 new datasets); Change 22.060.
Major enhancements added in MXG 22.02
If you are using IRD, you must install MXG 22.12 or later:
(This note originally said MXG 22.02, but now, Change 22.307 in
MXG 22.12 is required for IRD values to be correct!)
--Full Support for IRD (Intelligent Resource Director) is now 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 Dec 2, 2005 22.12 22.307
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 variable in all of MXG (CPUTM for billing is the most
important); this is the first PCTCPUBY error in MXG's history! When
all engines remained online, however, there was no error.
BUILDPDB 22.052 PDB.STEPS can have wrong EXCP,IOTM,TAPExxxx values,
but only in rare circumstance of identical INITTIMEs.
RMFINTRV 22.050 Variable PCTCPUBY wrong in RMFINTRV when IRD active.
TYPE70 22.050 Variable PCTCPUBY wrong in TYPE70 when IRD is active.
DB2STATB 22.045 Negative QBSTGET, other QBSTxxx, when 4-byte wrapped.
TYPEDB2 22.042 DB2 Stats records not written in subtype order.
ANALALL 22.040 Example now can write all SMF for selected job(s).
ASMTAPEE 22.038 ML-31 of MXGTMNT corrects GMT, MSC APAR support.
Major enhancements added in MXG 22.01
VMXGRMFI 22.017 BUILDPDB run time elongation, if output is to tape.
Circumvention: USE FREE=CLOSE on tape DDs. See text.
TYPE117 22.029 Support for SMF 117 WBIMB WebSphere Business Integrat
TYPE82 22.005 Support for SMF 82 Crypto subtypes 14 thru 19.
TYPEENDV 22.032 Support for Endeavor Release 4.0, INCOMPATIBLE.
TYPEHURN 22.006 Support for Huron/Object Star additional subtypes.
TYPESMSX 22.030 Support for DF/SMS Storage Class Exit User SMF record
Many 22.018 Hardcoded "SPIN" DDname now &SPININ,&SPINOUT macros.
TYPE120 22.014 WebSphere SMF 120s had GMT for many timestamps.
TYPE30 22.022 Variable SRVTCBTM,SRVSRBTM,CPUTOTTM created in TYPE30
TYPETMNT 22.012 RACFUSER/RACFTERM reversed, GMT times, INPUT EXCEEDED
TYPETPMX 22.008 (Final?) revisions to internal Thruput array names.
TYPE30 22.021 Job delays SMF30HQT/JQT/RQT/SQT revisions.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements in MXG 22.08" in CHANGES for details.
MXG executes best under the most recent SAS Version, with all
Critical HotFixes installed by your SAS Installer:
For SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with V7SEQ,V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3; earlier MXG notes that
they were required for 9.1.3 are wrong.
For SAS Version 8.2, HotFix Bundle 82BX08 is REQUIRED to be safe.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it would be my default in CONFIGV9,
but I can't tell that you are at V9.1.3, and because V9SEQ
was badly broken prior to 9.1.3, I still have to use V6SEQ
and MXG's default in CONFIGV9. You should change to V9SEQ
in CONFIGV9 if you have installed SAS V9.1.3.
V6SEQ, if used under V9.1.2, requires SN-013514.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
MXG New Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on (archaic) V6.09, and on Windows XP with SAS V9.1.3.
Previous tests of MXG Software have been run with SAS V9.1.2, SAS
V8.2 and V9.1 with Linux RH8 on Intel, with V9.1 on Solaris v2.8
model v880, and V9.1 on HP-UX v11.11 model rp5470, confirming full
compatibility. So MXG executes with SAS V9.1+ or SAS V8.2 on
every possible SAS platform! Each new MXG version is also tested
with SAS/ITSV/ITRM by ITRM developers.
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.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 21.05
z/OS IRD TYPE70PR Mar 11, 2004 22.01
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 22.12
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
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
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate Mar 31, 2004 20.20
DB2 8.1 New Data Supported Mar 31, 2004 21.08
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
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 20.04
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 CICS/ESA 2.1 - 20.04
The Monitor for CICS/ESA 2.2 - 20.335, 21.134 21.04
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
The Monitor for MVS/ESA 3.0 - 19.19
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 CICS V500 User SMF 18.01
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
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
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
II. Incompatibilities and Installation of MXG 22.10.
1. Incompatibilities introduced in MXG 22.22 (since MXG 21.21):
a- Changes in MXG architecture made between 22.22 and 21.21 that might
introduce incompatibilities.
NONE.
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.
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. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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.
_PAGE_ 8
Alphabetical list of important changes in MXG 22.22 after MXG 21.21:
Dataset/
Member Change Description
Many 22.018 Hardcoded "SPIN" DDname now &SPININ,&SPINOUT macros.
Many 22.177 Update to define MACRO _Vdddddd for numeric SMF plus.
Many 22.180 Support for IFA CPU variables for zAAP processors.
Many 22.184 SAS V9.1.2 $VARYING design change protected.
Many 22.192 All INFORMAT $NOTRAN statements were removed.
Many 22.192 Protection for PROC SYNCSORT error with SAS V9.1.2
Some 22.108 Support for SAS V9.1 and V6SEQ without Hot Fix.
ADOC110 22.189 Major updated added 1300 lines of CICS documentation.
ANAL4GB 22.138 Revised to use DCOLLECT to detect large VSAM files.
ANAL94 22.114 IBM VTS Stat Report used SMFTIME, not STARTIME.
ANALALL 22.040 Example now can write all SMF for selected job(s).
ANALFIOE 22.127 Run time improvement if SMF, instead of PDB, input.
ANALFLSH 22.236 New member tracks concurrent flash copies executing.
ANALGART 22.242 Example analysis for Gartner Group requests.
ANALIDMS 22.372 Sample contributed report for IDMS response times.
ANALPATH 22.275 Support for 256 LCUs in the example report.
ANALRMFR 22.062 REPORT=ALL request failed due to HTTP report, fixed.
ANALRMFR 22.181 Enhancements to RMF reporting.
ANALSIZE 22.276 Utility to analyze size of SAS data libraries.
ASMRMFV 22.316 Enhanced support for RMF III VSAM files.
ASMTAPEE 22.038 ML-31 of MXGTMNT corrects GMT, MSC APAR support.
ASMTAPEE 22.366 MXGTMNT ML-32, has MEXIT=ON,XMEMF=ON,ARCV=ON
ASMTAPST 22.366 Prototype test MXGTMNT for STK HSC = please test.
ASUM42DS 22.147 Performance enhancement reduce I/O, CPU using view.
ASUM70PR 22.135 MVS System Name of each LPAR, SMF70STN, added.
ASUM70PR 22.274 Vars TOTSHARE/TOTSHARC kept for orig/current weights.
ASUM70PR 22.293 LP0xxxxx variables now populated with PHYSICAL's data
ASUMCACH 22.248 Protection for zero obs in PDB.TYPE74CA.
ASUMCIMS 22.241 Example summarization of the four IMF datasets.
ASUMHSM 22.282 Variable DATETIME was missing.
ASUMJOBS 22.031 Incorrect stats for jobs that did not purge.
ASUMMIPS 22.354 Interval Capacity by Workload, used MIPS and MSU.
ASUMUOW 22.139 Variables APPLID/USER/LUNAME/TERMINAL incorrect.
ASUMUOW 22.336 MQMACCT/MQMACCTQ data can be added to PDB.ASUMUOW
AUTOEXEC 22.064 LIBNAME DUMMY added to support MONTHASC.
AUTOEXEU 22.102 autoexec.sas file for unix, protects SASAUTOS error.
BLDIMPDB 22.128 ASCII equivalent of JCL for JCLIMSLx execution.
BLDNTPDB 22.111 unix case sensitivity corrections
BLDSMPDB 22.111 unix case sensitivity corrections
BLDSMPDB 22.329 Major enhancement to "PC Job Stream" for SMF on PC.
BUILDPDB 22.022 Variable LOSU_SEC,SRVTCBTM,SRVSRBTM,CPUTOTTM in PDB.
BUILDPDB 22.052 PDB.STEPS can have wrong EXCP,IOTM,TAPExxxx values.
BUILDPDB 22.115 JES3 PDB only; wrong TYPE26J3 used in BUILDPD3.
BUILDPDB 22.140 BY VARIABLES NOT SORTED FOR DATASET WORK.SPIN30TD.
BUILDPDB 22.165 BUILDPDB detects overlapped SMF data previously read.
BUILDPDB 22.320 MULTIDD='Y' obs now combined in PDB.SMFINTRV.
BUILDPDB 22.326 Variable CPUCEPTM now deaccum in PDB.SMFINTRV.
BUILDPDB 22.342 TYPE115/TYPE116 added to BUILDPDB, may cause errors.
BUILDPDB 22.365 BUILDPDB now sets Condition/Return code of zero.
CICINTRV 22.288 Comments show how to create PDB.CICINTRV from SMF.
CONFIGV9 22.108 CRITICAL Hot Fix SN-012437 Required for SAS V9.
CONFIGV9 22.123 SAS V9 on MVS VB INCOMPAT: S2=72 must be S2=0.
DB2STATB 22.045 Negative QBSTGET and other QBSTxxx, 4-bytes wrapped.
ERRORASC 22.239 ASCII platform errors when incorrect SMF download.
EXDB2ACC 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
IEFU84 22.136 SMF exit to get Initiator Name and Number for jobs.
IHDRMQM 22.290 New "header" exit for MQ record selection.
IMAC6ESS 22.117 Support for optional ESS segment GEPARMKY=003Bx.
IMAC6ESS 22.161 Support for ESS GEPARMKY 003Bx and 0045x fields.
IMAC6ESS 22.332 Support for GEPARMKY 0036, 0041, 0043, fix 0034x.
IMACICHO 22.169 Hogan optional CICS data member now exists
IMACSHFT 22.058 Temporary variable SHFTTIME now dropped and not kept.
IMACZDAT 22.004 New ZTIME variable available.
JCLMNTHD 22.343 JCL example to build MONTHLY PDB on disk.
JCLRMF 22.143 Example to create "RMF-only" PDB from SMF data.
MONTHASC 22.064 Example "MONTHBLD" for ASCII systems.
MONTHDSK 22.343 "MONTHBLD" program to build MONTHLY PDB on disk.
MXGSASV9 22.126 SAS dsnames must be "W0", w-zero, not w-oh.
MXGSASV9 22.130 Revised MXG JCL example for SAS V9, NLS names, etc.
ONLYINTV 22.326 Example to build only PDB.SMFINTRV/PDB.TYPE30_6.
RMFINTRV 22.050 Variable PCTCPUBY wrong in RMFINTRV when IRD active.
RMFINTRV 22.088 Second VMXGRMFI invocation requires SPINRMIN= arg.
RMFINTRV 22.289 Duplicate observations for first hour.
SYSLOG 22.238 Preliminary support for SYSLOG file.
TESTOTHR 22.279 TYPEVTOC no longer executed in MXG test stream.
TRND.... 22.258 Symbolics &TRENDINP,&TRENDNEW,&TRENDOLD added.
TYPE102 22.074 T102S125 variables QW0125SN/PC/PL/PN/TS missing.
TYPE102 22.234 Support for IFCIDs 140-145 SQL text that was blank.
TYPE102 22.294 Support for APAR PQ73385,PQ91101 for IFCIDs 217, 225
TYPE102 22.294 Support for APAR PQ87848 for IFCID 173
TYPE102C 22.104 Support for Candle Omegamon II for DB2 IFCID Trace
TYPE102G 22.109 TYPE102G to read DB2 Trace written to GTF didn't.
TYPE110 22.059 CICS/TS 2.3 Pool Variables corrected in CICDSPOO.
TYPE110 22.094 Support for CICS/TS 2.3 with no EXCLUDEd fields.
TYPE110 22.359 Support for CICS/TS 3.1 with no EXCLUDEd fields.
TYPE117 22.029 Support for SMF 117 WBIMB WebSphere Business Integrat
TYPE119 22.073 TYP11910 variables UCINxxxx,UCOUxxxx corrected.
TYPE119 22.146 TYP119nn datasets had GMT time zone, now have local.
TYPE120 22.014 WebSphere SMF 120s had GMT for many timestamps.
TYPE30 22.021 Job delays SMF30HQT/JQT/RQT/SQT revisions.
TYPE30 22.022 Variable SRVTCBTM,SRVSRBTM,CPUTOTTM created in TYPE30
TYPE30 22.221 Support for z/OS 1.6 and zAAP/IFA Processors.
TYPE30 22.265 Support for APAR OA09118, adds CPUCOEFF to SMF 30s.
TYPE30 22.272 Support for zAAP IFA engines.
TYPE30 22.375 IBM Error in CPUIFATM, MXG Error in SRVTCBTM.
TYPE30MR 22.345 TYPE30MR dataset restructured and corrected.
TYPE42 22.254 False ERROR:INVALID TYPE 42 SUBTYPE 5 corrected.
TYPE42DS 22.055 TYPE42DS variable AVGIOQMX small negative value.
TYPE57 22.057 Support for optional ESS fields.
TYPE6 22.153 SUBSYS='TCP' or 'TCPE' for Printway SMF 6 records.
TYPE6 22.298 SMF 6 STOPOVER on PrintWay section - missing @;
TYPE6 22.302 Support for VPS V1 R8.0 VPS-FAX data
TYPE6 22.309 Final correction for type 6 INPUT EXCEEDED errors.
TYPE6 22.321 Support for second format type 6 PrintWay record.
TYPE70 22.050 Variable PCTCPUBY wrong in TYPE70 when IRD is active.
TYPE70 22.087 Non-PR/SM, IORATE/PCTTPI variables too low.
TYPE70 22.116 Variables SMF70NSI/NSA/NSW incorrectly divided.
TYPE70 22.134 Percent when each engine online PCTONLN0-PCTONLNX.
TYPE70 22.325 "Short CP" variable SHORTCPS created in TYPE70.
TYPE7072 22.063 Calculation of variable PCTDLTDQ in TYPE72GO revised.
TYPE7072 22.072 TYPE72GO with R723CWMN GT 0, Periods not output.
TYPE7072 22.137 Support for z890 CPUTYPE 2086, OS/390-INCOMPAT.
TYPE7072 22.152 Support for IFA Processors, APAR OA05731.
TYPE7072 22.221 Support for z/OS 1.6 and zAAP/IFA Processors.
TYPE7072 22.260 Support for z/OS 1.6 WITH IFA engines.
TYPE7072 22.272 Support for zAAP IFA engines.
TYPE7072 22.307 Negative CPU values for IRD - Required CHANGE.
TYPE7072 22.340 Revision to support for varying IFAs online/offline.
TYPE7072 22.349 Negative PCTMVSBY/CPUMVSTM/SHORTCPs, SMF70CNF bit 6.
TYPE70PR 22.011 PCTCPUBY for IRD was incorrect.
TYPE70PR 22.150 LPAR names for LPARs 16-32 now 8 bytes, were only 1.
TYPE71 22.269 22.07-22.10 only. LPAxxxx variables missing values.
TYPE74 22.075 Support for 1024 structures in Coupling Facility.
TYPE74 22.141 Support for RMF 74 subtype 8 ESS Link Stats record.
TYPE74 22.334 Support for APAR OA06476 type 74 subtype 5 and 8.
TYPE78 22.091 Variable PCTALLBY, TYPE78CU always missing, correct.
TYPE80A 22.185 Invalid SMF 80 Extended Relocate Section protected.
TYPE80A 22.286 Numerous enhancements, multiple RACF segments, etc.
TYPE82 22.005 Support for Crypto subtypes 14 thru 19.
TYPE94 22.268 Support for VTS R7.3 additional statistics.
TYPEAIX 22.083 Support for AIX PTX new objects.
TYPEBETA 22.250 Support for BETA93 Release 3.5 subtypes 0-5.
TYPECIMS 22.314 Support for Mainview IMS IMF 4.1.00 (NO CHANGES!).
TYPECMF 22.266 Support for CMF Version 5504 User SMF (INCOMPAT).
TYPEDB2 22.042 DB2 Stats records not written in subtype order.
TYPEDB2 22.084 Large QBSTGET in DB2STATB due to DB2 restart fixed.
TYPEDB2 22.090 MXG 22.02-22.03 only. QWHSSTCK 1960 date in DB2ACCT.
TYPEDB2 22.121 DB2 Parallel CPU time lost, not output in DB2ACCT.
TYPEDB2 22.124 MXG 22.04-05, QWHSSTCK missing in SMF 102 trace data.
TYPEEDGS 22.112 INPUT STATEMENT EXCEEDED with MVRECLEV '02'x.
TYPEENDV 22.032 Support for Endeavor Release 4.0, INCOMPATIBLE.
TYPEHIOM 22.331 Support for hIOmon File I/O Performance Monitor.
TYPEHMF 22.168 Support for HMF V2.7 new subtypes, compatible.
TYPEHPDM 22.166 Support for STK ExHPDM user SMF record.
TYPEHURN 22.006 Support for Huron/Object Star additional subtypes.
TYPEHURN 22.304 Support for ObjectStar subtype 45 Page Sweep.
TYPEIBSM 22.079 Support for IBM Session Manager user SMF record.
TYPEIMS7 22.199 Major revision to IMS0708 dataset, all events output.
TYPEIMSA 22.113 ASCII execution only, APPLID not readable.
TYPEIPAC 22.125 Support for IPAC subtype 5 IPAC05 corrections.
TYPEMVCI 22.296 Reading CMRDETL on ASCII platform - BLKSIZE error
TYPENDM 22.133 Support for several additional NDM-CDI subtypes.
TYPENETM 22.037 Support for NetMaster 5000x subtype.
TYPENETM 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
TYPENSPY 22.131 TYPENSPY and TYPENETM combined, only one SMF record.
TYPENSPY 22.312 Support for NetSpy Version 7.0 (COMPATIBLE).
TYPENTSM 22.082 Variable MEMINBOX in NTCONFIG was wrong.
TYPENTSM 22.190 Support for NTSMF MicroStrategy Server objects.
TYPENTSM 22.193 Support for NTSMF Exchange/Outlook/DTS CPU objects.
TYPENTSM 22.246 Support for NTSMF Release 2.4.7 (COMPATIBLE).
TYPEOMVT 22.186 Omegamon/VTAM V520 IRNUM 29 Divide by zero corrected.
TYPEQACS 22.095 Support for OS/400 5.2 QAPMMIOP record new fields.
TYPEQACS 22.311 Support for OS/400 5.3.0 CONF/DISK/POLL/JOBL data.
TYPEQACS 22.371 Support for OS/400 5.3.0.
TYPESASU 22.163 Cannot use NODUP option with TYPESASU SAS user SMF.
TYPESMSX 22.030 Support for DF/SMS Storage Class Exit User SMF record
TYPETDSL 22.249 Support for TDSLink product's user SMF record.
TYPETMDB 22.235 Support for ASG/Landmark TMON for DB2 V4.0 (COMPAT)
TYPETMNT 22.012 RACFUSER/RACFTERM reversed, GMT times, INPUT EXCEEDED
TYPETMNT 22.237 DDNAME/STEPNR missing in PDB.ASUMTMNT corrected.
TYPETMO2 22.191 Support for ASG/TMON TCE for CICS/ESA 2.3, COMPATIBLE
TYPETNG 22.081 Protection for '9E'x for Left Square Bracket.
TYPETNG 22.085 Support for NT objects SESSION and USER in TNG cubes.
TYPETNG 22.160 REGION reduced for JCLTEST8 TESTOTHR due to TYPETNG.
TYPETNG 22.170 Support for TNG Windows Server 2003 new objects+fix.
TYPETNG 22.291 Support TNG NT Platforms NTW400I, WNS502I, ZPP501I.
TYPETNG 22.339 Major TNG enhancement - array sizes dynamically set.
TYPETPF 22.374 Support for MQ Series data from TPF Operating System.
TYPETPMX 22.008 (Final?) revisions to internal Thruput array names.
TYPETPMX 22.060 Restructure TPM support, multiple datasets created.
TYPETPMX 22.077 Support for alternative multiple-ACCT field TPM data.
TYPETPMX 22.142 INNODE, JBSBIND, JVLVOL, REQCLA varnames supported.
TYPEVIOP 22.101 Support new VIO/PLUS (Performance Enhancer) subtypes.
TYPEVMXA 22.240 Support for z/VM 4.4, INCOMPAT.
TYPEVMXA 22.369 Support for z/VM 4.4 and z/VM 5.1 additions.
TYPEXAM 22.245 Support for XAMAP Release 3.4 (INCOMPATIBLE).
UTILBLDP 22.149 Enhancement supports subtype selection in ZEROOBS.
UTILBLDP 22.277 New MACFILEX argument to insert SAS code.
UTILBLDP 22.301 Use of ZEROOBS= parameter could fail.
UTILCONT 22.356 ABEND with SAS V9 when PDB=WORK requested fixed.
UTILEXCL 22.068 Support for optional RMI data in CICSTRAN.
UTILEXCL 22.313 Support for APPLNAME,CANDEXNM,CANDEXTY CICS segments.
UTILEXCL 22.317 The final @; was not created in IMACEXCL.
UTILEXCL 22.347 New CICS/TS 3.1 WBREPRDL/WBREPWDL/PGCRECCT supported.
UTILS2ER 22.123 Utility to detect errors with S2=0 in your programs.
VGETENG 22.148 Enhancement to get Engine and Device Type of LIBNAME
VMACDB2H 22.196 Support for extended length DB2 id variables.
VMACDB2H 22.270 22.08-22.10 only. DB2 V8.1 INPUT STATEMENT EXCEEDED.
VMACSMF 22.271 _LOGSMF revised for TYPENDML.
VMACSMF 22.300 Use of FTP access to read SMF MVS-to-MVS failed.
VMXGINIT 22.096 Macro variables &MACINTV and &MAC30DD created.
VMXGPRAL 22.287 Enhancement to use PROC FREQ, example for 102 "who".
VMXGRMFI 22.017 BUILDPDB run time elongation, if output to tape.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 22.
====== Changes thru 22.378 were in MXG 22.22 dated Feb 1, 2005=========
Change 22.378 Type 74 subtype 8 (ESS 2105 PPRC RMD data) with nulls for
VMAC74 R748CFDT (DATE WHEN FIRST RECORD WRITTEN) caused R748CFTM
Jan 30, 2005 to be midnight on 1JAN1960. Now, R748CFTM is set missing
when R748CFDT is not populated.
Thanks to Shirley Fung, Hong Kong & Shanghai Bank, HONG KONG.
Change 22.377 This elegant tweak discovered by this user to my enhanced
TYPETNG dynamic array sizing uses even less virtual storage when
VMACTNG you have multiple TNG cubes from different systems. My
Jan 29, 2005 enhancement in Change 22.339 kept all instances from all
systems to set the array sizes, but by changing counting
from BY PLATFORM OBJECT to BY PLATFORM SYSTEM OBJECT, the
true count of unique instances needed for the array size
is much smaller; for example, NT042I dropped from 1008 to
489, and REGION dropped from 266MB to only 149MB.
-TYPETNG now prints the INSTREAM file on the log after it
was created, useful for debugging.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 22.376 -MXG 22.22 is the last to be tested under SAS V6 on MVS,
UTILXRF1 because my MVS QA site is removing Version 6, but the
UTILXRF2 final tests discovered two variables whose names were
Jan 29, 2005 longer than 8 bytes. While SAS V8+ permits longer names,
Jan 30, 2005 it is my intention to NEVER use them in MXG, not only as
I find them user-unfriendly, but also because all of my
ADOC/DOC members are designed for 8-byte variable names.
But this last test was a great wakeup, so I have enhanced
my Cross Reference utility, run during my Alpha QA tests,
to detect long variable names, and also, for similar
reasons, detect if I have created labels longer than 40.
-Dataset Labels were missing from many datasets in DOCVER,
even though the MXG code had a LABEL= dataset option in
the VMACxxxx members. Dataset labels are propagated from
the input to the output dataset if PROC COPY or PROC SORT
is used (even if the dataset name is changed in SORT),
but creating a new dataset from an old dataset does not
propagate the dataset label. Most MXG _Sdddddd dataset
macros use PROC SORT, and test data is used to determine
the correct BY list to remove duplicates, but when there
is no test data, DATA _Ldddddd; _Wdddddd; is used to
copy the "Work" dataset to the "PDB" output library, and
it was those instances that had missing labels in DOCVER.
While getting test data and revising the _Sdddddd to SORT
and remove duplicates is the eventual solution, to get
the dataset labels for MXG 22.22, I revised CROSSREF to
copy the _Wdddddd datasets to one library, and to copy
the _Ldddddd datasets to a second library, and to use the
label from the _Wdddddd dataset if the _Ldddddd copy had
a blank label. I could not just use the _Wdddddd data,
because some of the _Sdddddd macros add new variables;
in particular, when adjacent interval records have to be
deaccumulated, the _Sdddddd logic creates the DELTATM.
-There are still a few datasets that don't have labels.
Thanks to Jake M. Drew, MBNA, USA.
Change 22.375 MXG variable SRVTCBTM, a CPU TCB time that is calculated
VMAC30 from CPU TCB Service Units was wrong if the task executed
Jan 29, 2005 on a zAAP (IFA) engine, because the MXG calculation used
CPUUNITS before IFAUNITS had been removed from CPUUNITS.
-Now, the order of calculation is correct.
- SRVTCBTM was added by Change 22.022 to the TYPE30xx
datasets so that it could be compared with CPUTCBTM.
Cheryl thought that using Service Units might provide
higher resolution and less truncation for small jobs
due to the .01 second precision of CPUTCBTM, but my
analysis had not shown a significant difference.
- Change 22.221 documented that the "raw" CPUUNITS in
SMF 30 records include the IFA Service Units, but as
IBM provides the CPUIFATM and the coefficients, that
MXG created a separate variable, IFAUNITS, and those
IFA Service Units are removed from CPUUNITS.
-However, new analysis of SRVTCBTM in type 30 records for
2086 (z/890s) for tasks that use IFAs shows an error in
IBM's creation of CPUIFATM: the calculated SRVTCBTM is
significantly larger than CPUTCBTM when IFAs are used:
IFA? SRVCLASS CPUTCBTM SRVTCBTM Diff CPUIFATM
Yes STCHI 31.14 90.58 +59 80
Yes STCMED 129.29 333.35 +204 211
Yes STCHI 4057.62 4517.82 +460 689
Yes STCMED 23.37 118.91 +95 13
No STCHI 1253.96 1248.32 -5
No STCHI 242.15 241.79 0
No STCMED 266.03 265.80 0
IBM is fully aware of this problem and will undoubtedly
correct it in the near future.
Change 22.374 Support for MQ Series data from TPF creates two datasets
EXTPFMQC dddddd dataset description
EXTPFMQQ TPFMQC TPFMQC MQ SERIES CHANNEL INFORMATION
IMACTPF TPFMQQ TPFMQQ MQ SERIES QUEUE INFORMATION
VMACTPF
VMXGINIT
Jan 28, 2005
Change 22.373 Change 22.055 set AVGIOQMS to zero if a negative value
VMAC42 was calculated, due to clock differences, but that change
Jan 28, 2005 only applied to AVGIOQMS for TYPE42SR dataset. Now, the
other two datasets, TYPE42VT and TYPE42DS are protected.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 22.372 Sample contributed report for IDMS response times, using
ANALIDMS the PDB.IDMSTAS dataset built by TYPEIDMS from the IDMS-R
Jan 28, 2005 SMF record. The report also shows how you can send any
SAS report to your company's web site.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 22.371 Support for OS/400 5.3.0. New data in QAPMJOBM, QAPMSYSC
EXQAPDPS QAPMSYST and QAPMIODn, and new QAPMSYS replaces QAPMSYSL.
EXQAPJSU Change 22.311 supported new data in QAPMCONF, QAPMDISK,
IMACQACS QAPMPOLL and QAPMJOBL. As always with AS/400 support, if
JCLTEST8 you are running MXG on z/OS, you must make the LRECL of
JCLTEST9 the MVS dataset into which the QAPM file is sent to be
QASAS the same as the LRECL in the table in VMACQACS for that
VMACQACS dataset; on ASCII, it's the LRECL in your FILENAME that
VMXGINIT must match.
Jan 28, 2005 -The new QAPMSYS with 567 variables replaces QAPMSYSL, but
none of the old JSxxxx variables from QAPMSYSL exist in
QAPMSYS. QAPMSYS is the "long" (LRECL=3344) system file,
and you will need to add _TQAPSYS and //QAPMSYS DD to
create the new dataset.
-The new QAPMJSUM dataset is created with Job Statistics
Performance Data.
-The new QAPMDPS dataset is created with Data Port Service
Performance Data.
-Variables added to QAPMSYSC:
SCTACT - The number of CPUs, so variable PCTCPUBY is now
calculated as 100*SUM(OF SCPU01-SCPU32)/(SCTACT*INTSEC).
-Variables added to QAPMJOBM:
JBASH JBASHA JBBFA JBBFW JBBTA JBBTW
JBCOP JBCOS JBDOP JBDOS JBFSH JBFSHA
JBNSJE JBPGA JBPGD JBPJE JBSJD JBTNW
JBTWT JBUJD JBXRBR JBXRBW JBXRFS JBXRRR
JBXRRW JCUSR
-Variables added to QAPMSYST:
SYBTAC SYBTAP SYBTAPC SYBTAPD SYBTAPP SYCTA
SYIFTA SYIFTE SYIFUS SYJOC1 SYJOC2 SYJOC3
SYJOER SYJOES SYJOIB SYJOS1 SYJOS2 SYJOS3
SYLPTB SYNPLA SYNPLU SYNUAL SYNUTC SYSDFAL
SYSDFRL SYSDNFE SYSDNFO SYSDNST SYSDPFD
SYSDPFF SYSDTET SYSPTU SYUTA
Thanks to Clayton Buck, Unigroup, USA.
Change 22.370 The dataset name in the comments in the code that invokes
TYPEHO15 the _Edddddd macro was incorrect in a number of members,
VMAC84 but in some cases, it wasn't the name in comments, but it
VMACARB was the _Edddddd that was wrong, which caused those data
VMACCMFV to be output to the wrong dataset. Fortunately, none of
VMACTMDB these are "mainstream" datasets, so that error was never
VMACVITA noticed. The MXG QA stream now validates the comment and
Jan 27, 2005 the _Edddddd macro are consistent.
invoke it. This change corrects the dataset name typos
and makes the macro use more consistent within MXG code.
TYPEHO15 VMAC84 VMACARB VMACCMFV VMACTMDB VMACVITA
Thanks to Jake M. Drew, MBNA, USA.
Change 22.369 Support for new fields added to z/VM 4.4 and z/VM 5.1;
EXIODQDS INCOMPATIBLE only because MXG did not properly use the
EXMTRQDC offsets and lengths for the SYTCUG and SYTCUP datasets.
FORMATS -Added prior to z/VM 4.4, but not in MXG until now:
IMACVMXA SYTSYG - CPUCAPAB CPUCFGCT CPUCOUNT CPURESVD
VMACVMXA CPUSTNBY CTNABORT CTNDONE CTNNOTEL VL3CAF
VMXGINIT VL3CFGCT VL3COUNT VL3CPNAM VL3DBCT VL3MNAME
Jan 26, 2005 VL3RESVD VL3STNBY
Jan 27, 2005 USELOF - ASCDEFSZ VMDCTPVG VMDMVB2G VMDMXSHR VMDTHRCT
USEACT - ASCDEFSZ IPQFO IPQRQLO IPQRQHI IPQEFLO
IPQEFHI IPQDSKIP VMDCTPVG VMDMVB2G
-Added in z/VM 4.4:
IODDEV - SCGCOUNT SCGSSCH SCMDBTIM SCMIRTIM
IODMOF - SCGCOUNT SCGSSCH SCMDBTIM SCMIRTIM
MTRMEM - CALSCMAX HCPMMO HCPSYS RSAGSTOR SYSGTORS
SYSSCMEX SYSTRCPC
MTRSYS - CPUCFGCT CPUCHAR CPUCOUNT CPUDEDCT CPURESVD
CPUSHARD CPUSTNBY LPARCAF LPARNAME LPNUMBER
SYSMMODL SYSMPOM SYSMSEQC SYSMTYPE
STOASP - SCGSSCH
STOASS - SCMSSCH (expanded to 4 bytes)
SYTCUG - CPUCFGCT CPUCHAR CPUCOUNT CPUDEDCT CPURESVD
CPUSHARD CPUSTNBY LPARCAF LPARNAME LPNUMBER
SYTEPM - CSCCMCDP CSCCMCDU CSCCMCMP CSCCMCMS ECMMDUS
ECMMDUSC ECMMSNT ECMMSNTC ECMMUATS ECMMURB
ECMMURBC
SYTRSG - TCMMNBLW TCMMNABV RSA2GDCT SYSSCGCT
SYTSCG - CALTLKCT CALTLKTM
-Added in z/VM 5.1:
IODDEV - EDEVTYPE RDEVDEV
IODDTD - RDEVDEV
IODVOF - RDEVDEV
IODVON - EDEVFCP1-EDEVFCP8 EDEVLUN1-EDEVLUN8
EDEVTYPE EDEVWPN1-EDEVWPN8 RDCOBRCO RDCRCUC
RDEVDEVP RDEVPVFG RDEVSER RDEVSID RDEVSIDP
RDEVTYPE
MTRDEV - EDEVFCP1-EDEVFCP8 EDEVLUN1-EDEVLUN8
EDEVWPN1-EDEVWPN8 EDEVTYPE RDEVDEVP RDEVPVFG
RDEVSIDP
MTRPAG - RDEVDEV
MTRSYS - CPUCAPAB SCPCAPAB
STOASS - RDEVDEV
STOATC - RDEVDEV
SYTCUP - LCXPUPID
SYTXSG - TCMFSHVM TCMRDCT TCMPIN4K
USELOF - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI
VEBTVSCT VEBVIRAI
USEACT - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI
VEBTVSCT VEBVIRAI
USEATE - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI
VEBTVSCT VEBVIRAI
SYTSYG - SCPCAPAB
-New Datasets created in z/VM 5.1:
MTRQDC - QDIO DEVICE CONFIGURATION
IODQDS - QDIO ACTIVITY
Other new records will be supported only if you
have a need and can send test data for them:
MTRCCC, IODVSM, IODVSR, IODSZI, IODQDA, IODQDD.
Thanks to Kris Ferrier, State of Washington Dept Info Services, USA.
Thanks to Alexandre Dorsimont, SCNH, FRANCE.
Change 22.368 The "TOTALS" record was still output in XAMSYT, because
EXXAMSYT the test in EXXAMSYT was spelled 'TOTAL' but the actual
Jan 26, 2005 LPAR name test needed to be 'TOTALS:'.
Thanks to Joachim Mayr, Amadeus, GERMANY.
Change 22.367 MXG 22.13-22.22 only. Change 22.320 combined MULTIDD obs
BUILD005 from TYPE30_V into one PDB.SMFINTRV obs, but if you used
BUIL3005 IMACINTV to only output some of the TYPE30_V obs, then
Jan 25, 2005 PDB.SMFINTRV had more obs than were in TYPE30_V. All DDs
for all tape devices from all interval records are output
in TYPE30TD, independent of the TYPE30_V selections. The
TYPE30TD then becomes TYPE30VT, which is merged with the
INTVS (which is a stripped down TYPE30_V) and INT30VSIO
(the sum of all I/Os for the interval records), but now,
the merge is only OUTPUT if the obs is in INTVS.
Thanks to Ron Lundy, AHOLD, USA.
====== Changes thru 22.366 were in MXG 22.22 dated Jan 22, 2005=========
Change 22.366 The MXGTMNT Tape Mount Event and Sampling Monitor ML-32
ASMTAPEE is in member ASMTAPEE, with these enhancements:
ASMTAPST -The ML-32 revisions are primarily for IBM Tape Devices,
ASMTAPSK because it defaults to use the IBM Volume Mount Exit, and
Jan 22, 2005 STK doesn't support that exit. Thus these defaults in
Jan 27, 2005 the ASMTAPEE member will ONLY work with IBM devices:
MXIT=ON, use the IBM Volume Mount Exit to capture all
Mount Events (exit-driven, not sampling for mounts),
which also gets job-level fields for the Mount Event
so Cross Memory Service calls are not needed for the
mount record.
XMEMF=ON, use Cross Memory Services to get job-level
fields for the Allocation Event, which are detected
by sampling.
ARCV=ON, enable detection of Allocation Recovery thru
exit, to write a separate subtype for each delay
because a tape device could not be allocated. This
subtype creates the (new) PDB.TMNTTARC dataset.
-However, you can use ML-32 with STK devices: you have to
set MXIT OFF, so that the old sampling monitor is used to
detect mount events, even though that means that many of
your fast VTS mounts will not be captured. You also need
to leave XMEMF ON, so that Cross Memory Services is used
to get the job-level information for both mount events
and allocate events, even though that may increase the
CPU time used by the MXGTMNT monitor (because there is no
way to know that an address space is no longer present,
except to issue the XMEM call, and then go thru the very
CPU-expensive recovery mechanism when XMEM fails to find
the job, because it had already ended).
-And if you have both IBM and STK devices, you will need
to assemble two different MXGTMNT programs and run them
in two Started Tasks, and use the EXCLUDE LIST DD to tell
the IBM instance to exclude the STK devices by DEVNR, and
to tell the STK instance to exclude the IBM devices.
You can create the same SMF record for both monitors, or
you could set different SMF IDs, and then you would use
MACRO _IDTMNT nnn OR ID= mmm % in the IMACKEEP member
to tell MXG to process both IDs as MXGTMNT records.
-STK devices are allocated by STK's HSC product, which
does not call the IBM volume mount exit; we have written
a test program for the HSC SLSUX01 exit, but have not had
an STK site run the program, which will determine if we
can use that exit for STK devices (and thus eliminate the
sampling and missed mounts). Here's what we need:
ASMTAPST is a test exit for potential STK support. The
program is a wrapper for the site's current SLSUX01 HSC
exit. There is a DD in the linkedit step, HSCLOAD, that
points to the location of the site's current SLSUX01
exit. The output of the linkedit is a combined SLSUX01
exit that the site will use, instead of their current
SLSUX01 exit code. The HSCLOAD and SYSLMOD DDs must not
point to the same library, or the site's SLSUX01 will be
replaced. Once the ASM/LKED are done, the site will
have to define the new MXG version of that exit to HSC.
The logic is as follows:
-HSC calls the MXG SLSUX01.
-MXG SLSUX01 executes the site's local SLSUX01 as-is,
taking whatever actions, were coded by the site.
-Control is returned to MXG SLSUX01 where the code
will do some data gathering and issue WTOs to the job
log, reporting what was discovered, from which we can
tell if the HSC exit can be used for STK devices.
-MXG SLSUX01 returns to HSC.
Once you've installed our exit, run some jobs that
cause both VTS and non-VTS tape mounts, and send us the
MXGTMNT job log, which will show us if all mounts do
actually go through the exit, and what environment
exists at the time the exit is taken. From that info,
we may be able to figure out how to handle the STK
devices. Unfortunately, we have to depend on you to
run these tests, as STK has been unwilling to run these
tests for us on their systems.
- Just discovered: STK no longer provides a dummy exit
SLSUX01 in HSC 6.0! Member ASMTAPSK is the variant
of ASMTAPST that doesn't call that user exit.
-ML-32 corrects ML-31, in which setting MEXIT bypassed the
XMEMF call in the Allocation Monitor (causing job-level
fields to be missing in the allocation records). Now,
XMEMF on/off is independent of the MEXIT on/of setting.
-The TMNT004I message is updated before it is issued at
MXGTMNT initialization, to show any user modifications.
-STEPNAME is now correctly populated, and PROCSTEP name
has been added to TYPETMNT record for mounts.
-Using MXIT on IBM systems is only supported on z/OS. We
have seen, on OS/390 systems, that second and subsequent
mounts for a job-step are not captured by MXIT, and also
mounts from STCs (like DFHSM and JES2) are also missed.
This is just not worth fixing for those archaic systems.
-There is one know error in ML-31/ML-32; the Mount Start
time is taken as the entry time into the Volume Mount
Exit, which now appears to be the same as the Allocation
Allocation Start time, and for most mounts that is very
close to the IEF233I Mount Message timestamp, and hence
not a problem. But one site experienced very significant
delays (30 minutes!, due to hardware errors) between the
TMNTTIME time and the IEF233I time, so "asmguy@mxg.com"
is now working on a revision, ML-33, but it won't be done
and tested in time for MXG 22.22; please email a request
to support@mxg.com when you read this text, asking for
ML-33, and we'll email the revised ASMTAPEE when ready.
Change 22.365 BUILDPDB now sets Condition/Return Code of zero under V9!
BUILD005 SAS V9 tightened when Condition Codes were returned, and
VMAC26J2 the WARNING: LENGTH OF CHARACTER VARIABLE HAS BEEN SET
Jan 21, 2005 returned a CC=0 with SAS Version 8.2, but CC=4 with V9,
because JES3 JOBCLASS is $8, VMAC30 reads JES2 and JES3
30s, but VMAC26J2 for JES2 26s had JOBCLASS of $1, and
VMAC26J2 was located first in BUILDPDB to set $1 length.
This design increased JOBCLASS length in VMAC26J2 to $8,
eliminating the WARNING in the SMF-reading step where
VMAC30 and VMAC26J2 coexist, and new LENGTH JOBCLASS $1
statements were inserted in BUILD005 to keep only $1 for
JES2 JOBCLASS in the PDB and SPIN datasets, so that old
and new datasets built before and after this redesign
will still have a one byte JES2 JOBCLASS variable.
-TYPE30 used by itself always had JOBCLASS $8, so that did
not change; only if you use TYPE26J2 by itself would you
notice that JOBCLASS's length is now $8 instead of $1.
But with MXG's COMPRESS=YES default, you shouldn't see
any increase in the size 'cause those 7 blank bytes will
get compressed real good!
-The SAS change was noted in MXG Newsletter FORTY-FOUR,
but that note was revised, citing this MXG change.
-This should make migration from V8 to V9 even easier.
Change 22.364 Variables BLKPAGE, BLKSAUIN, and NRBLKPAGE in TYPE71 are
VMAC71 rates (per second, like all paging activity rates), but
Jan 21, 2005 their labels did not so indicate; now, they do.
Thanks to David Kaplan, DTC, USA.
Change 22.363 -The JES3 Workload Management Section variables (added to
BUILD005 SMF 26 in OS/390 R2.4; already in TYPE26J2 and PDB.JOBS
BUIL3005 for JES2, are now kept in JE3's TYPE26J3 and PDB.JOBS.
VMAC26J3 JOBMODE0='RAN*IN*MODE=WLM'
Jan 21, 2005 JOBMODE1='RAN*F*J=JOB,RUN'
SMF26WCL='SERVICE*CLASS AT*EXECUTION'
SMF26WIN='JOB*INDICATORS'
SMF26WJC='JOB*CLASS'
SMF26WOC='ORIGINAL*SERVICE*CLASS'
SMF26WSE='SCHEDULING*ENVIRONMENT'
-Variable SMF26WSE, the Scheduling Environment name, was
only previously kept in JES2's PDB.JOBS, but this change
adds SMF26WSE to PDB.STEPS for both JES2 and JES3, as it
is often useful examine STEPS-level data (i.e., PROGRAM)
and the Scheduling Environment name that caused that PGM
to execute on this SYSTEM.
Thanks to Julian Smailes, Experian, ENGLAND.
Change 22.362 Cosmetic. The include of VMACSMF in these products was
Several not needed, as they read different INFILES. No error,
Jan 21, 2005 but it could have been confusing. Members changed:
TYPEASXT, TYPECMFV, TYPEEAGL, TYPEIDML, TYPEMVCI,
TYPEOMDB, TYPEUNIA, TYPEUNIK, and TYPEVITA and TYPS's.
Thanks to Freddie Arie, TXU, USA.
Change 22.361 Variable SYSTEM was blank in PDB.ASUMUOW if there was no
VMXGUOW DB2ACCT observation for that unit of work. The value of
Jan 20, 2005 SYSTEM comes from the last of the two input datasets
(CICS,DB2) that contributed to the PDB.ASUMUOW obs, so
if there are DB2 obs, the SYSTEM of the last DB2ACCT
observation will be the source of the value of SYSTEM.
Thanks to Ron Root, Texas Comptroller of Public Accounts, USA.
Change 22.360 On z/890s with z/OS 1.4 but with SMF70LAC=0, values in
FORMATS the variables CECSUSEC, CPCNRCPU, CPUMSU were missing
VMXGRMFI because the $MG070CP format's table for CPUTYPE='2086'x
Jan 19, 2005 was wrong. When SMF70LAC GT 0, those variables are in
the SMF 70, but the $MG070CP table has to be used when
SMF70LAC=0. MXG ERROR: CPUTYPE WAS NOT FOUND IN TABLE,
CECSUSEC IS MISSING was printed (obscurely) on the SAS
log by RMFINTRV code; this change enhanced that message
in case it again occurs. Changes 21.299 and 20.168 noted
that SMF70LAC was zero on basic (non-LPAR) machines, or
on LPAR'd machines if APAR OW55509 was not installed and
the LPAR had no defined capacity limit. This system was
not running in 64-bit mode, which may also be required
for SMF70LAC to be non-zero.
Thanks to Diane Parker, AmerisourceBergen Corp, USA.
Change 22.359 Full support for CICS/TS 3.1 was only in UTILEXCL in
VMAC110 22.13 as the three new fields (328,341,342) during the
Jan 18, 2005 ESP were not added to VMAC110 INPUT for SMFPSRVR=64.0
until today. MXG 22.13 tested MCTSSDCN=283, but now
MCTSSDCN=286 and MCTSSDRL=1848 is tested for
non-excluded-field records. Using UTILEXCL to create
IMACEXCL has always been the recommended way to minimize
the size of your CICS 110s, and even if there are added
fields, since UTILEXCL read your CICS dictionary records,
it will generate code to skip over any unrecognized
fields (and will tell you on the log it found unknown
fields, so they can be added to the MXG UTILEXCL and
VMAC110 members.
Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.
Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.
Change 22.358 CALTODON, the datetime stamp when user Logged on, was not
VMACVMXA converted from GMT to local time, but now it is.
Jan 18, 2005
Thanks to Xiaobo Zhang, ISO, USA.
Change 22.357 UTILBLDP failed with USERADD=118 because VMACTCP defines
UTILBLDP the macros for SMF 118; originally, the TCP record was a
Jan 18, 2005 User SMF record, and only later was given ID=118. Now,
UTILBLDP is coded for this inconsistency and will work if
use USERADD=118 or USERADD=TCP.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 22.356 UTILCONT reports SAS Data Set sized in MegaBytes; as is
UTILCONT documented in its comments, it can cause log messages of:
Jan 18, 2005 WARNING: LIBRARY xxx WAS ALREADY ALLOCATED
ERROR: LIBRARY xxx MAY NOT BE REASSIGNED
ERROR: DISP=SHR CONFLICTS ASSIGNED
ERROR: LIBNAME XXX IS NOT ASSIGNED
but with MXG default options, these messages to NOT cause
a condition code, nor does the job fail, and the reports
are produced. However, if you have set the SAS Option to
ERRORCHECK=STRICT (default is NORMAL), then errors like
the above in LIBNAME statements do cause ERRORABEND to be
invoked, and the step fails with USER ABEND 999.
An ABEND did occur with %UTILCONT(PDB=WORK); due to the
changes made in Change 22.175, when MXG 22.12 was tested.
This change to UTILCONT detects that the LIBNAME of WORK
was requested and does not reassign it, avoiding those
messages for the WORK library, and the ABEND.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
Change 22.355 EDGRKEXT was wrong; the first +1 did not exist. New
VMACEDGR variables RKRELIXD RKRELSI RKRETAND RKRETNCD RKRETNXD
Jan 17, 2005 are now output.
Thanks to Reinhard Nitsch, Provinzial Vershicherungen, GERMANY.
Change 22.354 Capacity used for each interval for each workload, for
ASUMMIPS each service and reporting class from PDB.TYPE72GO, and
Jan 16, 2005 for each job from PDB.SMFINTRV, with MIPSUSED, MSUUSED,
Jan 22, 2005 and PCTUSED variables, is created in two output datasets
named PDB.RMFMSUSE and PDB.SMFMSUSE by the ASUMMIPS code.
I think MSU is a much better capacity measure than MIPS,
but I used "MIPS" to name the member, so that, when your
boss asks for an MXG report on MIPS used, you will find
this program, which uses MSUUSED and MSU Capacity for the
PCTUSED, but also calculates MIPSUSED from MSUUSED.
-Note that the conversion from MSU to MIPS uses a factor
that you will likely have to change to meet your boss's
MIPS rating of your hardware. IBM giveth the MSU rating.
Comments show how to determine the factor for your boss,
and you can set different factors for different systems.
-The MIPSUSED are the MSUUSED, multiplied by the factor
you set; the default factor is 5.8 MIPS for each MSU, but
IBM now has a factor of 6.7 MIPS for each MSU for T-REX.
-See MXG Newsletter FORTY-ONE, MVS Technical Note 24, for
my documentation of MSU metrics and the MSU capacity
variables that are reported in the ASUMMIPS examples.
-PDB.RMFMSUSE is created from RMFINTRV and TYPE72GO data,
for capacity used by each Service and Reporting Class in
each interval. Be careful: PDB.RMFMSUSE has duplicate
data, because it keeps both the Reporting and Service
Class obs. You will need to select which obs are of
interest for your reporting, before you do any summary of
the data in PDB.RMFMSUSE.
-PDB.SMFMSUSE is created from RMFINTRV and SMFINTRV data,
for capacity used by each JOB in each interval. If your
SMFINTRV data is NOT globally synchronized, the results
in PDB.SMFMSUSE may be inaccurate:
If your RMF Interval is on 0 minutes, but your SMF data
is on 3 minutes, the 00:00 to 00:10 interval created in
PDB.SMFMSUSE includes CPU time from jobs's intervals
that executed from 00:03 to 00:13.
-In both datasets, the MSU capacity is calculated from the
CECSUSEC of the hardware platform, not from the SU_SEC of
the MVS System, because that's what IBM uses in its MSU
calculations. I use the NRCPUS (average number of CPUs
that IRD gave to this MVS system ) to get the capacity
of the specific interval (DURATM). To compare with IBM
hourly MSU rates, you need to multiply by the ratio of
3600 divided by DURATM of your interval data.
-The PCTUSED is the percentage of MSUUSED by the job or
service/reporting class during this interval, divided
by the interval MSU capacity (using average NRCPUS),
which MXG calculates in variable INTMSUCP.
-Be careful to not confuse MIPS/MSU counts with MSU rates.
Read the Newsletter Article (again).
-Macros define the input "RMFINTRV" dataset that is used,
which sets the output interval, and macros define the
output dataset names. The MXG default interval for
"RMFINTRV" is your RMF Interval, but you can execute the
RMFINTRV program many times to create multiple "RMFINTRV"
datasets, each with different interval (see comments in
member RMFINTRV). For example, Hourly in RMFINTHR,
Shiftly in RMFINTSH, Daily in RMFINTDY. Comments in
ASUMMIPS member show how to execute it and how to tailor
it for your needs.
Thanks to George Canning, Abbey Plc, ENGLAND.
Change 22.353 The ERROR*RMFINTRV. WORKLOAD CPU TIMES DO NOT MATCH ...
VMXGRMFI is printed when the sum (CPU72TM) of the workloads that
Jan 16, 2005 you defined, either in your tailored RMFINTRV member
(the recommended way to define which Service/Reporting
Classes you want combined into PDB.RMFINTRV workloads),
or in your tailored IMACWORK member (the old way), do not
match the sum (CPUTM) of all Service-only Classes.
The text of the message was enhanced to show both times
in both TIME12.2 and 8.2 formats and they are collimated
for easier reading.
-If you do receive that error message, you need to review
your RMFINTRV/IMACWORK definitions, and review your data,
which is the purpose of the UTILRMFI program, which will
examine both your TYPE72GO and STEPS/SMFINTRV data to
provide explicit answers, but UTILRMFI requires manual
EDITing, and could require re-reading of your SMF data.
This PROC FREQ might be sufficient to show the error:
PROC FREQ DATA=PDB.TYPE72GO
(WHERE=(STARTIME='02JAN2005:08:00:00'DT));
BY SYSPLEX SYSTEM;
TABLES RPRTCLAS*SRVCLASS*STARTIME/MISSING;
WEIGHT CPUTM;
FORMAT STARTIME DATETIME13.;RUN;
My error message was the result of using an old RMFINTRV
that had USEREPRT=GOAL (use ONLY Reporting Classes), but
the test data I was looking at (for other purposes!) did
not have 100% of its Service Classes mapped to Reporting
Classes. The preceding PROC FREQ showed that the CPUTM
was exactly equal to the RPRTCLAS=' ' observations, and
that CPU72TM was exactly equal to the RPRTCLAS='Y' obs,
and that CPU72TM was less than CPUTM. The PROC FREQ is
also useful since it shows the CPU time and the names of
all Service and Reporting Classes in the interval.
Change 22.352 Test for short record expanded to test both LENMONI and
VMACTMO2 LENGTH, because an archive file contained two 80-byte
Jan 14, 2005 records that contained '4040'x for LENMONI.
Thanks to Tom Parker, CSC, USA.
Change 22.351 HSM format MGHSMFU for 13 is 13:FULL VOLUME DUMP instead
FORMATS of 13:DELETE BACKUP VERSIONS, and descriptions were made
Jan 14, 2005 clearer for migration formats.
Thanks to Michael Yuan, University of California, USA.
====== Changes thru 22.350 were in MXG 22.13 dated Jan 13, 2005=========
Change 22.350 New CICS/TS 3.1 variables WBREPRDL, WBREPWDL, PGCRECCT
UTILEXCL were found in PDB.CICSDICT and are now supported in the
VMAC110 UTILEXCL member, and WBSNDOU1 test was corrected.
Jan 13, 2005 -Duplicate variables were not removed from SORTTEST so
and additional DATA step was added to remove them all.
Without this change, 180 errors when TYPE110 was executed
with IMACEXCL built by the earlier UTILEXCL.
Thanks to Tory Lepak, Aetna, USA.
Change 22.349 Change 22.325 created SHORTCPS/PLCPRDYQ variables, but
VMAC7072 negative values were found in a few TYPE70 observations.
VMXGINIT Those obs also had PCTMVSBY and CPUMVSTM negative, values
Jan 13, 2005 of MVSWAITx greater than DURATM, and unreasonably large
Jan 29, 2005 IORATE values, at two sites, both using IRD (Intelligent
Resource Director, the WLM component that varies engines
on/offline as needed. The occasionally bad data records
occurred with both z/OS 1.4 and 1.5, and all of the RMF
70 records with bad data had SMF70CNF bit 6 on ('02'x or
'03'x in MXG variables CAIx), and no observations with
bit 6 off had bad data values, and only some CPU Data
segments in each bad record had bad data.
-None of the LPAR bits indicated a change in CPUs, but in
one z/OS 1.5 case examined closely, in the LPAR segment
for the CPUID that had CAI='02'x, SMF70ONT was only 230
milliseconds less than SMF70INT/DURATM; the next interval
shows that engine remained offline (CAI='00'x), so it
appears the bad data may only occur when IRD has varied
an engine off right at the end of an interval.
-When engines had been IRD'd on/off with good data, they
had SMF70ONT values that were a multiple of 10 minutes,
the normal WLM decision interval for varying engines.
-SMF70CNF bit 6 was documented in the SMF manual as
"CPU reconfigured during the measurement interval (data
for this CPU is incorrect)"
However, RMF Development now says that the "incorrect"
part of the doc is out of data, is no longer true, and
will be revised.
-Both sites had SLIH counts of 20-30 million in 900 second
(15 minute) interval data, which was much above the value
in normal observations from both sites.
-Many obs had SMF70WAT (CPUWAITM) much larger than DURATM
in the observations with bit 6 on (as much as 26 Hours of
Wait in a 15 minute interval) at one site, while the
second size always had SMF70WAT of zero when bit 6 was on
(which is likely also wrong, as that would be 100% busy
for that engine, which was inconsistent with the other
engines in the LPAR for that interval).
-One of the sites will opening a PMR with IBM, after I had
extensive discussions with RMF Development, but that will
require IBM Support to design a SLIP trap to diagnose the
problem, which will take some time and effort by both IBM
and the customer.
-I had revised MXG code to detect that CNF bit 6 is on, in
this original change, so that you could choose to cause
those bad values to be instead be set to a missing value,
simply by inserting this optional statement:
%LET CNFBIT6=1;
after your //SYSIN. And this change originally made the
MXG default to calculate the bad values, so that you'd
know they existed. Fortunately, that bad data only
affects variables that are "MVS-specific" and are not the
"mainstream" variables you use for CPU calculations; they
have been there some time and were not observed until I
added the Short CPs variables.
HOWEVER: UPDATE JAN, 2006: SPLIT 70 Rewrite eliminated
the CNFBIT6 macro variable option, and these data are
always presented. See change 23.321.
-Several MXG sites without IRD have run the program and
none have seen the symptoms, but that's not conclusive.
-In conclusion, these MXG variables in PDB.TYPE70 and in
PDB.RMFINTRV (where not all are kept) may be negative or
incorrect with MXG's default
PCTMVSBY MVSWAITn SHORTCPS PLCPRDYQ CPUMVSTM
when corresponding CAIx variables have 02x or 03x values.
-Additional notes from RMF Development elaborate meanings:
MXG Variable LPARCHNR='Y' if Bit 1 of SMF70PFG is on:
Bit 1 of PFG (Number of Logical Processors has
Changed) does not indicate any online/offline
activity; it it indicates whether the number of
logical processors changed and does not care whether
those processors are online or offline or whether
their on/of status changed.
MXG Variable LCPUVARY='Y' if Bit 5 of SMF70VPF is on:
Bit 5 of VPF (log proc varied online during interval)
is only set when the processor turned ONLINE compared
to the status at the end of the previous interval
(this is more or less a bit from the old days, prior
to WLM CPU mgmt).
-You can use the below program, to analyze your existing
TYPE70 data to see if the problem exists in at your site:
/* CNFBIT6 PROGRAM, EXAMINE SMF70CNF BIT 6 ERRORS */
/* DISREGARD THE MESSAGES ON THE LOG THAT STATE: */
/* THERE ARE NO VALID OBSERVATIONS... */
PROC CHART DATA=PDB.TYPE70;
BY SYSPLEX SYSTEM MVSLEVEL DURATM NOTSORTED;
HBAR CPUWAIT1-CPUWAIT9 IORATE CAI1-CAI9;
TITLE MXG INVESTIGATION OF SMF70CNF BIT 6 ERROR;
TITLE2 CPUWAIT GT DURATM IS AN ERROR CONDITION;
TITLE3 IORATE GT 10000 IS LIKELY AN ERROR CONDITION;
TITLE3 ONLINE STATUS OF 02-03 ARE SMF70CNF BIT 6 ON;
LABEL SYSPLEX='SYSPLEX' SYSTEM='SYSTEM'
MVSLEVEL='MVSLEVEL' DURATM='DURATM';
Thanks to MP Welch, SPRINT, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Michael Oujesky, MBNA, USA
Change 22.348 The actual variable names are CPUIFATM and CPUIFETM, but
Several there still were references in several members to the
Jan 12, 2005 original-last-August names of IFACPUTM and IFECPUTM.
Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND.
Change 22.347 The IMACEXCL member generated for CICS/TS 3.1 data could
UTILEXCL fail with 180 abend starting with variable PGTOTCCT.
Jan 12, 2005
Thanks to Victoria Lepak, Aetna, USA.
Change 22.346 PCTCPUBY for non PR/SM system was wrong; it was either
VMAC7072 the busy of the last engine, or missing, if the last CPU
Jan 12, 2005 was offline. And the IORATE was way wrong, as it was the
IORATE of the last engine, not the total of all engines.
Thanks to Mary Kay Pettengill, (i)Structure, USA.
====== Changes thru 22.345 were in MXG 22.13 dated Jan 12, 2005=========
Change 22.345 The support for Multi-System Remote Enclave CPU segment
VMAC30 in Change 22.051 was flat out wrong; I was misled by my
Jan 12, 2005 own error: my code INPUT the MOF/MLN/MNO triplet at the
same location as the ARM triplet offset. The data DOES
agree with IBM documentation, and, with this change, the
IBM field names are the MXG variable names in TYPE30MR.
Note: the SMF30MRD/SMF30MRI CPU times are normalized by
MXG back to the system on which this type 30 was created,
but both SMF30MRA and LOSU_SEC variables are kept in the
TYPE30MR dataset, in case you want to do it differently.
The sum of SMF30MRD/SMF30MRI in all MR segments in this
SMF 30 record are summed into variables CPUMRDTM/CPUMRITM
which already existed in TYPE30_4(PDB.STEPS) and TYPE30_5
and are now also kept in TYPE30_V (PDB.SMFINTRV).
However, CPUMRDTM/CPUMRITM are NOT added into CPUTM, at
least not yet by this change; since they have never been
right, they could not have been used, and it is not
clear exactly what use will be made of those CPU times
that occurred on other systems. Your feedback is wanted!
Especially, since I do not have any type 30 records with
the Multi-System segment with which to validate!!
-The original MXG variable names RMSU_SEC and MRENSYST are
now replaced by SMF30MRA and SMF30MRS respectively.
Thanks to Robert Vaupel, IBM RMF Development, GERMANY.
Change 22.344 If you have too many LPARs and LCPUADDRs, it is possible
VMAC7072 for IBM to split your RMF 70 data into multiple physical
Jan 11, 2005 records for each interval, and this is not YET supported
in MXG (because no one yet has actually made it happen).
At least now, MXG will detect the split records and will
alert you with error messages and hex dumps of the first
10 records with SMF70RAN non-zero, and will tell you that
your TYPE70, TYPE70PR, ASUM70PR, ASUM70LP, and ASUMCEC
data are wrong, and that TYPE70 will have multiple obs
for a single RMF interval. Eventually, MXG will support
the split records, and this change text will be revised.
====== Changes thru 22.343 were in MXG 22.13 dated Jan 10, 2005=========
Change 22.343 Discussion and examples for building MONTHLY PDBs.
JCLMNTH -The existing JCLMONTH and JCLMNTH both assume you want to
JCLMNTHD build your MONTH PDB on tape. The original JCLMONTH read
JCLMONTH five weekly PDBs and created MONTH as a sequential format
MONTHBLD ("tape format") SAS data library, but there are multiple
MONTHDSK mounts and rewinds when multiple data steps are used to
Jan 9, 2005 write multiple datasets to a seq-format library on tape.
So the JCLMONTH was revised (in 1987!) to write each
dataset first in sequential format to //TAPETEMP DD on
DASD, and MVS's MOD was used to add each dataset to the
end of the tape, to eliminate backspace/rewind delays.
-But even then, if your weekly PDBs were each on tape, the
JCLMONTH required six tape drives, one for each weekly
PDB and one for the MONTH output data library. So 1992s
JCLMNTH example enhanced the process by requiring only
one tape drive, by first PROC COPYing each weekly tape
PDB with SELECT of the needed datasets to temporary DASD,
(with UNIT=AFF so only one tape drive was needed to read
all weekly PDBs), and then the MONTH PDB was created
using //TAPETEMP, MOD, and UNIT=AFF on the same drive.
-While both JCLMONTH or JCLMNTH were designed to write the
//MONTH to tape, you could write MONTH to a DASD DD.
However, a data library in sequential (tape) format has
no directory, so you must read all N-1 preceding SAS
data sets to read the Nth dataset you wanted, wasting CPU
and I/O.
-In addition, you may have been wasting a lot of DASD
space if you wrote your //MONTH to DASD in sequential
format. This entire discussion was precipitated when the
reporting site's monthly job failed when it ran out of
disk space; they had moved from SAS V8.2 to SAS V9.1.3,
but were unaware they were creating their Monthly PDB in
sequential format:
-Using SAS V8, V8SEQ, and COMPRESS=YES (MXG Default),
and writing //MONTH to DASD in sequential format, they
needed only 55,830 tracks, because V8SEQ, SAS 8.2 and
COMPRESS=YES did compress sequential format libraries,
but V9SEQ and SAS V9.1.3 does NOT compress seq format,
so its data library was 106,710 (uncompressed) tracks!
-So I had Chuck then run these benchmarks to reveal the
source of their ABEND:
Tracks Engine SAS Version CPU sec Compress
34305 DASD V8 8.2 --- Yes
106710 V6SEQ 8.2 65 Yes
106725 V9SEQ 9.1.3 26 No
106725 V9SEQ 9.1.3 26 Yes
34380 DASD V9 9.1.3 138 Yes
63705 DASD V9 9.1.3 22 No
106723 V8SEQ 8.2 22 No
55830 V8SEQ 8.2 126 Yes
34305 V8SEQ 8.2 133 Yes
50145 V8SEQ 8.2 20 No
106725 V8SEQ 9.1.3 26 No
106725 V8SEQ 9.1.3 26 Yes
34380 DASD V8 9.1.3 137 Yes
63705 DASD V8 9.1.3 20 No
-Even though COMPRESS was specified, not all engines
and versions actually compress sequential format, but
that is what I want: if you are writing to tape, the
IDRC hardware compress the tape, so you don't want
SAS to burn CPU time to also compress the data.
Furthermore, you can write a single SAS dataset to
an extended-sequential, striped, hardware-compressed
DASD device, which also shouldn't be SAS-compressed.
-MXG CONFIGV9 still specifies V6SEQ today, because I
cannot tell from within SAS if you are at V9.1.3, or
if you have the critical Hot Fix for earlier V9s.
Originally I recommended V6SEQ, even under SAS V8.2,
because it did NOT waste CPU time by compressing.
While V9SEQ eliminated that compression, prior to
SAS V9.1.3, you MUST use V6SEQ, because there were
data corruption errors using V8SEQ or V9SEQ under
SAS V9s prior to 9.1.3. If you have installed 9.1.3,
it is NOW safe for you to change CONFIGV9 to V9SEQ.
-So back to the new JCL examples, and documentation of all
of your choices. This change adds example JCLMNTHD and
member MONTHDSK, which should be used when yow want your
monthly on DASD, and your weekly PDBs are also on DASD.
Additionally, once you've built "Last Month's" PDB on
DASD, you can archive it to a tape GDG by using:
PROC COPY IN=MONTH OUT=MNTHTAPE MT=DATA;
to write all of those datasets in a single write to tape
when you're finished with this month's reporting and then
free up the DASD space.
JCL Code Weekly Monthly Select Tape
Member include On On Copy Drives
JCLMONTH MONTHBLD Tape Tapes No Six
JCLMNTH MONTHBLD Tape Tapes Yes One
JCLMNTHD MONTHDSK Disk Disk No None
JCLMNTHT MONTHDSK Tape Disk Yes One
-To be complete, JCL example JCLMNTHT is created, but it
is likely to be unneeded - if you can't find space on
DASD for your weekly PDBs, then why try to write a month
to DASD? (Perhaps, if you only build a small number of
datasets monthly, which is really what I personally think
best - I only created the JOBS/STEPS/PRINT/RMFINTRV in my
monthly, and did all of my other reporting week-to-week.
Thanks to Bruce Green, MIB, USA.
Change 22.342 INCOMPATIBLE MXG CHANGE TO BUILDPDB, if you have tailored
BUILD001 your build to add SMF 115 or SMF 116 records. If so, you
BUIL3001 MUST remove the references to 115 and/or 116 in the PDB
BUILD004 exit members, EXPDBINC/EXPDBVAR/EXPDBCDE/EXPDBOUT. If
BUILDPDB you overlook this revision to your tailoring, your first
BUILDPD3 test of the new MXG BUILD will fail, because of duplicate
BUILD606 dataset names being built in the first Data Step.
Jan 10, 2005
Change 22.341 -If you have IFAs but don't have APAR OA09118 installed
VMAC30 (adds CPUCOEFF to SMF 30), MXG-created IFAUNITS/IFEUNITS
Jan 7, 2005 variables are missing, causing CPUUNITS to still include
the IFAUNITS. Now, if there are RMF 72s from the same
SYSTEM in the SMF file that precede the type 30 record,
the old MXG logic to calculate EXCPRMF using CPUCOEFF
from RMF is used to also populate IFAUNITS and IFEUNITS
and to subtracts IFAUNITS from CPUUNITS. If both the
IFAUNITS and EXCPRMF are still missing values, then both
the APAR is not installed and there was no RMF 72 record
from this system before that type 30 record.
-The IFA CPU time variables are now formatted TIME12.2.
Thanks to Bernie Pierce, IBM, USA.
Change 22.340 -If zAAP engines are offline, MXGs PCTIFABY in TYPE70 was
VMAC7072 100%, and IFAACTTM was equal to the DURATM, because MXG
Jan 6, 2005 did not consider offline IFAs. This change restructures
MXG code for IFAs, summing IFAs SMF70ONT into IFAUPTM and
summing IFAs LCPUPDTM into IFAACTTM to calculate PCTIFABY
and also new variable NRIFAONL, the number of IFAs that
were online (which, like NRCPUS, the number of CPs that
were online) can be a fraction if some are offline.
-The MXGCIN variable is also now correctly set to IFA even
for offline IFAs. The original NRIFAS variable is now a
count of installed IFAs, but is not used in calculations.
-The IFAWAITn and PCTIFBYn variables (32 of each!) are no
longer created; they are not needed in TYPE70 and they
can be determined from TYPE70PR.
-If CP engines were varied on/off, PCTMVSBY was wrong, as
it was calculated based on DURATM instead of SMF70ONT;
this also led to incorrect values of the new SHORTCPS
variable, that was added in Change 22.325.
-Mar 7, 2005: The MXGCIN 'guess' depends on IRD, because
variable SMF70SPN, the LPAR Cluster Name, is only found
in systems that are in an LPAR Cluster.
Thanks to Dave Cogar, CA, USA.
Change 22.339 -Major enhancement to TNG support:
EXTNT100- The instance macro variables values and the MAXROW value
EXTNT127 are now set dynamically from the input performance cubes,
EXTNT127 so you won't get any ARRAY SUBSCRIPT OUT OF RANGE errors!
FORMATS The cube's headers are read in a quick pass of the input,
IMACTNG and then used to write the %LET PPoooI=nnn; statements
TYPETNG (to //INSTREAM) for each object that was found in your
TYPSTNG input; the input is then re-read to create the output.
VMACTNG This will also minimize the amount of virtual storage
VMXGINIT required for the MXG job; a REGION of only 200MB was
Jan 6, 2005 used for test data with many objects and many instances
Jan 21, 2005 that previously required over 400MB. And since the array
size is now based on data, the default instance macro
variables in VMXGINIT are now all set to one, and metric
macro variables are back in the VMACTNG member, since
they are only changed when new metrics are added by CA,
and that requires other changes in the VMACTNG code.
-Support for 28 new NT objects with over 600 metrics:
Dataset dddddd Object Name
TNT100 NT100 ASP.NET APPS V1.1.43
TNT101 NT101 ASP.NET V1.1.4322
TNT102 NT102 DOUBLE-TAKE CONNECTI
TNT103 NT103 DOUBLE-TAKE KERNEL
TNT104 NT104 DOUBLE-TAKE SECURITY
TNT105 NT105 DOUBLE-TAKE SOURCE
TNT106 NT106 DOUBLE-TAKE TARGET
TNT107 NT107 FTP SERVER
TNT108 NT108 GOPHER SERVICE
TNT109 NT109 GROUPSHIELD FOR MICR
TNT110 NT110 HTTP SERVICE
TNT111 NT111 INDEXING SERVICE
TNT112 NT112 INDEXING SERVICE FIL
TNT113 NT113 MSEXCHANGE INTERNET
TNT114 NT114 MSEXCHANGECCMC
TNT115 NT115 MSEXCHANGEDS
TNT116 NT116 MSEXCHANGEES
TNT117 NT117 MSEXCHANGEIMC
TNT118 NT118 MSEXCHANGEIS
TNT119 NT119 MSEXCHANGEIS PRIVATE
TNT120 NT120 MSEXCHANGEIS PUBLIC
TNT121 NT121 MSEXCHANGEMSMI
TNT122 NT122 MSEXCHANGEMTA
TNT123 NT123 MSEXCHANGEMTA CONNEC
TNT124 NT124 MSEXCHANGEPCMTA
TNT125 NT125 SQLSERVER:BACKUP DEV
TNT126 NT126 DATABASE
TNT127 NT127 RSVP SERVICE
-When processing TNG data on ASCII platforms, which have
a default LRECL=255, you will need to add LRECL=32000 to
your FILENAME statement.
-Jan 20: temporary datasets used in _UTNGCNT now deleted.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 22.338 The AUTOEXEx and CONFIGVx members now specify the option
AUTOEXEC DLDMGACTION=REPAIR for all platforms; the option causes
AUTOEXEU SAS to automatically repair and rebuild indexes and the
CONFIGV8 integrity constraints, when a damaged SAS dataset is
CONFIGV9 detected; the most common reason for a damaged data set
Jan 4, 2005 is when it was left open because of a prior abnormal
termination (i.e., on z/OS, an x22 timeout ABEND). SAS
defaults are inconsistent, with z/OS having REPAIR for
batch and PROMPT for interactive, but FAIL for batch and
REPAIR for interactive for Windows systems.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 22.337 -WARNING: BIT MASK .. TOO LONG because the RACF variables
VMAC80A KW23SPEC and KW23IGNR are only one byte each, but the bit
Jan 4, 2005 tests were wrong, and were testing for two bytes.
-Variable RACF07DT was increased to 200 bytes.
Thanks to Erling Andersen, SMT, DENMARK.
Change 22.336 Major enhancement: MQMACCT/MQMACCTQ data (SMF 116) can be
ASUMUOW added to the PDB.ASUMUOW dataset for CICS transactions
IMACUOW created by MQ-Series (but you must enable their addition
JCLMQMCI in your IMACUOW member or in your input per comments.
VMXGUOW IBM does NOT provide the variables NETSNAME/UOWTIME in
VMXGINIT MQMACCT/MQMACCTQ datasets that are used to directly match
Jan 10, 2005 up to CICSTRAN data. (IBM MQ-series support claimed that
the STCK value in QWHCNID in MQMACCT could be used, but
its value is NOT the same as the UOWTIME STCK value.)
So this heuristic algorithm first matches CICSTRAN with
MQMACCT by APPLID TASKNR TRANNAME to get NETSNAME/UOWTIME
from CICSTRAN, which is then used to merge MQMACCT and
MQMACCTQ (which can have more than one obs per uow if
multiple MQ queues are used) with the CICSTRAN (and any
DB2ACCT data, although DB2ACCT data is not required).
-There is a clear exposure in using the TASKNR within an
APPLID to get the NETSNAME/UOWTIME from CICSTRAN, as the
IBM maximum for TASKNR is currently 99999, even though
the field is a PD4 that could contain 9999999, but there
is no other way at the present time.
-You MUST have tailored either IMACUOW or ASUMUOW to even
create observations in PDB.ASUMUOW in the first place,
since the MXG default is to create zero observations.
You must re-tailor using the new IMACUOQ or ASUMUOW
member from this MXG to add the MQ Series variables.
-ASUMUOW will not fail, even if there are no MQ data.
-Variable MQTRAN counts the number of MQMACCT/MQMACCTQ
records that were included in the Unit of Work.
-MXG's BUILDPDB was revised by Change 22.342 to add the
processing of SMF 115 and 116 data in the default PDB.
-Member JCLMQMCI is a JCL example that uses VMXGUOW for
standalone processing of SMF for CICSTRAN, DB2ACCT and
SMF 116 data to create PDB.ASUMUOW with all three.
-MXG 22.12. Error due to IMACUOW missing an end comment
symbol. At the same time, CICSUOW dataset was
externalized by MACRO _UOWICIC so that it's destination
can be overridden.
-VMXGINIT defines macro variable MXGMQADD, default blank.
-Cosmetic. Using %INCLUDE SOURCLIB(ASUMUOW); with no DB2
observations caused UNINITIALIZED variable messages that
are now eliminated by adding compiler fakers for DB2PARTY
QWACFLGS and QWHSSSID variables, and missing value notes
have also been almost completely suppressed.
Thanks to Ove Dall-Hansen, Codan Insurance, DENMARK.
Thanks to Diane Eppestine, SBC, USA.
Change 22.335 Unused Change Number.
Change 22.334 Support for APAR OA06476 changes to RMF 74 records.
EXTY748A -Subtype 5 adds these new metrics to TYPE74CA dataset:
EXTY748R R7451CT1='BYTES*READ'
EXTY748X R7451CT2='BYTES*WRITTEN'
FORMATS R7451CT3='READ*RESPONSE*TIME'
IMAC74 R7451CT4='WRITE*RESPONSE*TIME'
VMAC74 R7451PBR='PHYSICAL*STORAGE*BYTES*READ'
VMXGINIT R7451PBW='PHYSICAL*STORAGE*BYTES*WRITTEN'
Jan 1, 2005 R7451PRO='PHYSICAL*STORAGE*READ*OPERATIONS'
R7451PRT='PHYSICAL*STORAGE*READ*TIME'
R7451PWO='PHYSICAL*STORAGE*WRITE*OPERATIONS'
R7451PWT='PHYSICAL*STORAGE*WRITE*TIME'
R7451XID='EXTENT*POOL*ID'
R7451XTY='EXTENT*TYPE'
R7452XFL='EXTENT*POOL*FLAGS'
"Millisec" values are formatted TIME13.3 (so a value of
99 milliseconds will print as 0:00:00.099).
-Subtype 8 creates three new datasets:
TYPE78A - ESS RANK ARRAY DATA
R748AACP='ARRAY*CAPACITY'
R748AAID='RANK*ARRAY*IDENTIFIER'
R748AASP='ARRAY*SPEED*IN 1000*RPM'
R748AAWD='ARRAY*WIDTH'
R748AEBC='ARRAY*TYPE*EBCDIC'
R748ARID='RANK*IDENTIFIER'
R748ATYP='ARRAY*TYPE*CODED'
TYPE78R - ESS RANK STATISTICS DATA
R748RAIX='INDEX TO*FIRST ARRAY*SECTION OF*RANK'
R748RBYR='BYTES*READ'
R748RBYW='BYTES*WRITTEN'
R748RCNT='COUNT OF*ARRAYS*IN RANK'
R748RKRT='READ*TIME'
R748RKWT='WRITE*TIME'
R748RPNM='EXTENT*POOL*NUMBER'
R748RRID='RANK*IDENTIFIER'
R748RROP='RANK*READ*OPERATIONS'
R748RWOP='RANK*WRITE*OPERATIONS'
TYPE78X - ESS EXTENT POOL STATISTICS
R748XPID='EXTENT*POOL*IDENTIFIER'
R748XPLT='EXTENT*TYPE'
R748XRCP='REAL*EXTENT*POOL*CAPACITY*
R748XRNA='ALLOCATED*REAL*EXTENTS*IN POOL'
R748XRNS='REAL*EXTENTS*IN EXTENT*POOL'
R748XRSC='REAL*EXTENT*CONVERSIONS'
R748XSDY='SOURCES OF*DYNAMIC*RELOCATIONS'
R748XTDY='TARGETS OF*DYNAMIC*RELOCATIONS'
R748XVCP='VIRTUAL*EXTENT*POOL*CAPACITY'
R748XVNS='VIRTUAL*EXTENTS*IN EXTENT*POOL'
R748XVSC='VIRTUAL*EXTENT*CONVERSIONS'
Change 22.333 Cosmetic. If you used "views" for MXG datasets that still
DOC "housecleaned" with PROC DELETE DATA=_Wdddddd syntax, you
Jan 1, 2005 got a non-fatal SAS warning message; replacing the syntax
with the preferred %%VMXGDEL(DDDDDD=dddddd); eliminates
the messages. (All were oversights where VMXGDEL should
have been used.) These members were revised:
ANALVVDS ASUMTAPE TYPEDOS TYPETMS5 VMAC103 VMAC108
VMAC29 VMAC30 VMAC50 VMAC79 VMACAIX VMACCIMS
VMACCTLL VMACHMF VMACHSM VMACMPLX VMACTCP VMACTIMS
VMACTMDB VMACTPF VMACTPX VMACVITA VMACVMON VMACVMXA
VMACXXXX
Thanks to Joe Babcock, Bank One, USA.
Change 22.332 Support for (Optional) ESS segment GEPARMKY field values
IMAC6ESS 0036x=ESSRETAS, 0041x=ESSOFSTF, and 0043x=ESSOFSTB, plus
VMAC6 correction for '034'x field, which can have time-in-text
Dec 30, 2004 formats of 10:00 or 0150:00:00.
Jan 2, 2005
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Thanks to Harmuth Beckmann, Itellium, GERMANY.
Change 22.331 Support for hIOmon File I/O Performance Monitor.
VMACHIOM This Windows family I/O monitor records activity at the
Dec 30, 2004 individual file for each process for each user, with both
I/O activity counts, Bytes read/written, and duration of
the I/O. A special export option MXGall creates a csv
file of all 117 I/O metrics, with nulls for those fields
that are not being monitored, and that file is the file
supported in the TYPEHIOM code. Only a single dataset is
presently created, for both files and devices, but that
may change, based on user feedback. The inexpensive I/O
monitor can be downloaded at http://www.hyperio.com, and
a free trial is offered.
Thanks to Tom West, hyperI/O LLC, USA.
Change 22.330 Documentation. The CPUxxxTM variables created from SMF
ADOC30 30 records were not fully documented; they are updated
Dec 30, 2004 and identify what's included in which variables.
Thanks to Michael Bouros, Morgan Stanley, USA.
Change 22.329 Major enhancement to "PC Job Streams" for running MXG on
BLDNTPDB ASCII systems to create "SMF" or "NTSMF" PDB Libraries.
BLDSMPDB Uses the new VMXGALOC utility macro to allocate daily,
VMXGALOC weekly, and monthly PDB Directories, creating directory
VMXGSUM names that contain the DATE of the data, and logic to
Dec 30, 2004 read the correct directories for the MONTH PDB.
Jan 16, 2005 -UPCASE(KEEPALL) was added in VMXGSUM for pc execution.
UTILBLDP -Note: Only VMXGSUM was updated in MXG 22.13; the other
TRND70 three members were not revised until Jan 16, 2005.
ANALSHCP -UTILBLDP now supports OUTFILE=INSTREAM, needed for the
BLDSMPDB enhancement that lets you specify BUILDPDB= to
use the tailored UTILBLDP output for your BUILDPDB code.
-UTILBLDP now has an internal table of SMF records that
are automatically created by MXG's default BUILDPDB, so
that your USERADD= list can be compared and errors
prevented if you list a record that's already in PDB.
-UTILBLDP/BLDSMPDB logic for OUTFILE argument is robusted.
If the name is a PC dataset name it has to be inside
quotes, but if it is not (something like INSTREAM or like
SOURCLIB(MYPDB) then it must NOT be inside quotes in your
invocation. If a colon or backslash is found in your text
it will be put in quotes and treated as a PC filename.
-TRND70 now adds PCTMVSBY SHORTCPS PLCPRDQY MAXSHCPS and
MAXRDYQ to TRND70 dataset.
-ANALSHCP provides sample reports of SHORTCPs and PLCPRDYQ
for your systems.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.328 Cosmetic, unless you used the _NTNG macro to null all of
VMACTNG the TNG datasets (the _NULL should have been _NULL_ in
Dec 29, 2004 each of the lines in MACRO _NTNG), or tried to use the
_KTNT015 macro to tailor NT015 (it was spelled _KTNT016).
Thanks to Freddie Arie, TXU, USA.
Change 22.327 Cleanup of BUILDPDB/BUILDPD3.
BUILDPDB -In BUILDPDB/BUILDPD3, TYPE30MR was not sorted into //PDB
BUILD002 (unless you used BUILD002, which did contain _STY30MR).
BUILDPD3 -Work datasets STEPS, STEPSIO, SPJB30T4 were created in
SPUNJOBS SPUNJOBS but were not deleted, now they are.
Dec 24, 2004
Change 22.326 Variable CPUCEPTM (CPU TIME WHEN TASK WAS ENQUE PROMOTED)
BUILD005 in what I regard as an IBM Design Error, is accumulated
BUIL3005 in the SMF 30 subtype 2 and 3 interval records; no other
ONLYINTV CPU metrics are accumulated in those records. This means
Dec 24, 2004 that the TYPE30_V dataset built from SMF is no longer
valid. But since MXG can correct IBM errors faster than
they can even acknowledge their errors (Level 2 says it's
not their problem to fix), this redesign in BUILDPDB code
deaccumulates the CPUCEPTM in the PDB.SMFINTRV dataset.
(Of course, the CPUCEPTM will be missing in the first
interval for each task that has more than one interval
record, since there is no prior interval record in
"today's" SMF file.)
Dataset PDB.SMFINTRV is automatically built by BUILDPDB.
-If you want to create PDBINTRV.SMFINTRV (and the other
interval dataset, PDBINTRV.TYPE30_6) directly from your
raw SMF file, you can use this example that uses the
BUILDPDB logic, but builds only the PDBINTRV.SMFINTRV
and the PDBINTRV.TYPE30_6 interval datasets:
//PDBINTRV DD DSN=YOUR.PDB.OUTPUT,DISP=(,CATLG),....
//SMF DD DSN=YOUR.SMF.DATA,DISP=SHR
//PDB DD UNIT=SYSDA,SPACE=(CYL,(5,5))
//SPIN DD UNIT=SYSDA,SPACE=(CYL,(5,5))
//SYSIN DD *
%INCLUDE SOURCLIB(ONLYINTV);
Thanks to Tony Hirst, Wells Fargo, USA.
Change 22.325 Variable SHORTCPS=PCTMVSBY/PCTCPUBY is created in TYPE70
VMAC7072 and TYPE70PR datasets, based on Kathy Walsh's Paper that
Dec 23, 2004 was presented at SHARE in August, 2004, available at
Jan 10, 2004 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/
Oct 12, 2004 WebIndex/PRS1077, titled
"Performance Impacts of Running CICS in a Shared LPAR".
The term 'Short CPs' was created by IBM WSC Performance
Staff, and is a performance effect created by the LPAR
hipervisor enforcing LPAR weights on busy processors or
capped LPARs, that can reduce the MIPS delivered by the
logical CPs to the partition. She suggested that when
the SHORTCPS ratio exceeded 2, it could be a sign of
trouble. But Don Deese pointed out that another way of
looking at the phenomenon is as a measure of the queueing
delay when the LPAR is waiting for a CP engine to be
assigned, and that a ratio of 2:1 means that for 50% of
the elapsed time, the LPAR was waiting for a CP engine.
He suggests that even a lower ratio may be the threshold
of pain; a ratio of 1.5:1 means the LPAR was 33% waiting.
Don is working on an extensive discussion of this topic
in the next release of his CPExpert product, and I have
created variable PLCPRDYQ=100*(PCTMVS-PCTCPUBY)/PCTMVSBY;
so that you can use either the ratio or the percent of
time when there was a delay in your analysis to see if
this construct is useful in measuring your LPARs.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Dr. Robert Cross, JP Morgan, USA.
Change 22.324 Cosmetic. Missing value messages eliminated by testing
VMACTNG three NT006 fields before they are multiplied by 1024 or
Dec 23, 2004 1024*1024.
Change 22.323 Line 3624 should have named TOTSHARE TOTSHARC in KEEP=
VMXG70PR list for &OUT70LP dataset, instead of SYSSHARE CURSHARE,
Dec 23, 2004 to keep those variables in the PDB.TYPE70LP dataset.
Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
Change 22.322 Hasty creation of JCL examples for MXG under SAS V9.1.3
MXGSASV9 did not have sufficient testing; W-OH should have been
JCLTEST9 W-zero, WORKVOL was not referenced in JCLTEST9, WORK
JCLPDB9 sizes are all now 500,500, the WORK=200 in JCLPDB9 was
Dec 23, 2004 removed (with only a primary allocation, you cannot use
multiple volumes), and comments with "V8" were revised to
"V9". The instream JCL PROC in the JCLTEST9 example now
matches the symbolics in MXGSASV9.
Feb 23, 2005: This change originally changed the INSTREAM
LRECL to 72, but Change 23.012 corrected that back to 80.
Thanks to Bruce Green, MIB, Inc, USA.
Thanks to Michael Gebbia, Eddie Bauer, USA.
Change 22.321 Type 6 PrintWay records apparently come in two flavors,
VMAC6 and Change 22.302 did not protect both; in some records
Dec 21, 2004 the SMF6PQNM is always 24 bytes, and SMF6PQLN is the
number of non-blank bytes, and in other records, SMF6PQNM
is only the length of SMF6PQLN. (And, to make it more
fun, in VPS-FAX records, SMF6PQLN is always zero, but
PQNM is 24 bytes!). Additional test for blanks when
SMF6PQLN is less than 24 bytes now protects INPUT
STATEMENT EXCEEDED error that occurred even with Change
22.302/MXG 22.12 installed. And, variable SMF6PQLN is
now output in TYPE6 dataset.
Thanks to Robert Vance, Zurich Insurance Co., USA
Thanks to Reiner Luken, Zurich Insurance Co., USA
Change 22.320 This long-overdue enhancement for PDB.SMFINTRV combines
BUILD005 the MULTIDD='Y' observations from TYPE30_V into a single
BUIL3005 observation in PDB.SMFINTRV, with the correct totals for
Dec 15, 2004 EXCPxxxx, IOTMxxxx, and TAPEDRVS variables for each SMF
interval. There will be fewer observations created in
PDB.SMFINTRV, and variables EXCPNODD, IOTMNODD, and
TAPEDRVS are now correct for each interval. Variable
EXTRADD is set to zero, since those extra DDs have been
consolidated in the single observation per interval.
Note: Long ago, the MULTIDD='Y' observations were summed
into the PDB.STEPS dataset in the BUILDPDB logic. It
was only PDB.SMFINTRV that still contained MULTIDD='Y'
observations:
MULTIDD='Y' - steps with more DDs than can fit in one
SMF 30 record write multiple type 30 records; those
additional records contain only IOTMxxxx,EXCPxxxx and
TAPEDRVS values, and are flagged with MULTIDD='Y'.
See Change 23.015 if ERROR: PDB.SMFINTRV NOT SORTED is
encountered in your WEEKLY or MONTHLY PDB jobs.
Thanks to Mary Kay Pettengill, (i)Structure, USA.
Change 22.319 The R747AVFR/R747AVFT average frame size received/sent
VMAC74 in dataset TYPE747P needed to be multiplied by four; the
Dec 15, 2004 source fields are in words, and have 4 bytes per word.
Thanks to Pat Jones, DST, Inc, USA.
Change 22.318 The JCLINSTL example used the SAS V8 JCL procedure; new
JCLINST9 JCLINST9 had the minor changes to execute under SAS V9.
Dec 15, 2004 The correct CONFIGV9 member and ENTRY=SAS are now in the
example that uses the site's installed SAS JCL procedure
to create the MXG Format library during install. Once
this JCL example has been executed, the MXGSASV9 JCL proc
should be use for all subsequent MXG testing/execution.
Thanks to Burchell Williams, HIPUSA, USA.
Change 22.317 The final @; was not correctly created in the second and
UTILEXCL subsequent GRNR's, when there were optional segments; at
Dec 15, 2004 first, I blamed the conversion of CMODLENG from numeric
Dec 21, 2004 to character was the culprit, and revised that logic in
the COMDNAME='USER' code segment to
!!PUT(CMODLENG,4.)!!, but in fact the real error was a
hanging end-comment-*/ in line 745 that I had
accidentally removed during the testing of the CMODLENG
code change!
Thanks to Sally Jordan, Bear Sterns, USA.
Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
====== Changes thru 22.316 were in MXG 22.12 dated Dec 11, 2004=========
Change 22.316 Enhanced Support for RMF III VSAM files have many added
ASMRMFV features and options, all of which are discussed in the
ADOCRMFV documentation note at the beginning of ADOCRMFV member.
Dec 11, 2004 No changes are required to the CLRMFV nor TYPERMFV code.
Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.
Change 22.315 Example ASUM and TRND members for IBM SMF 94 VTS data.
ASUM94
TRND94
Dec 11, 2004
Change 22.314 Support for MainView for IMS IMF 4.1.00. DSECTS show no
TYPECIMS changes in the IMF records for IMS Version 9.1
Dec 11, 2004
Thanks to Tony Curry, BMC, USA.
====== Changes thru 22.313 were in MXG 22.12 dated Dec 10, 2004=========
Change 22.313 Optional field CMODNAME='DFHAPPL', CMODHEAD='APPLNAME'
IMACICAP had CMODIDNT='001', which tripped up MXG logic because
IMACICD6 only CMODNAME=:'DFH' (starting with) was tested; '001'
IMACICD7 generated an extra input of TRANNAME in the wrong place
UTILEXCL in IMACEXCL, which failed when it was executed.
VMAC110 -All of the CMODNAME tests were revised to test for the
Dec 10, 2004 full name (DFHTASK/DFHCICS/etc).
-New exits for optional fields and variables created:
CMODNAME CMODHEAD EXIT Variable
DFHAPPL APPLNAME IMACICAP APPLNAME
CANDEXNM CANDEXNM IMACICD6 CANDEXNM
CANDEXTY CANDEXTY IMACICD7 CANDEXTY
Thanks to Sally Jordan, Bear Stearns, USA.
Change 22.312 Support for NetSpy Version 7.0 (COMPATIBLE).
VMACNSPY -New variables in NSPYTCP.
Dec 10, 2004 NSPYAVRT NSPYINBU NSPYLOGM NSPYNROT NSPYNRTT NSPYOUBU
NSPYRCBS NSPYSGNL NSPYSOOP NSPYSSTZ NSPYTIMR NSPYTNID
NSPYTUID
-New variables in NSPYTCPS.
NSPYASID NSPYIFNR NSPYIPAE NSPYIPFC NSPYIPFD NSPYIPFF
NSPYIPFO NSPYIPFO NSPYIPHE NSPYIPID NSPYIPIR NSPYIPOD
NSPYIPON NSPYIPOR NSPYIPRF NSPYIPRO NSPYIPRR NSPYIPRT
NSPYIPSD NSPYIPUP NSPYIPVE NSPYTSSW NSPYUDDC NSPYUINE
NSPYUNOP NSPYUOUD NSPYURBS NSPYUSBS
Thanks to Leon Schiebel, IBM Global Services, CANADA.
Thanks to Nick Varvarigos, IBM Global Services, CANADA.
Thanks to Norman Hollander, CA, USA.
Change 22.311 Support for OS/400 5.3.0 for QAPMCONF, QAPMDISK, QAPMPOLL
VMACQACS and QAPMJOBL data files/data sets.
Dec 10, 2004
Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.
Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 22.310 An OPTIONS SOURCE; statement inserted to circumvent a SAS
ANALRMFR V8 compiler error under Win98 caused a compiler error on
Dec 10, 2004 z/OS with SAS 9.1.3. Using a conditional test resolved.
Thanks to Steve Gear, Schneider National, INC.
Change 22.309 Change 22.302 revised the IBM File Transfer segment code
VMAC6 to support VPS, but I failed to test with IBM data after
Dec 8, 2004 the revision, causing INPUT STATEMENT EXCEEDED, on IBM
data. I was misled by IBM doc that said the SMF6PQLN was
the "length of the significant portion" of SMF6PRTQ but
it's DSECT length was 24 bytes, so I assumed 24 bytes.
It turns out that SMF6PQLN is the length of the field,
so the INPUT was restored to variable length, and code
knows that the VPS record does always have 24 bytes, and
the SMF6PQLN field is 0 in the VPS record. Both IBM and
VPS records have been tested with this change.
Thanks to George Waselus, State of Arizona, USA.
====== Changes thru 22.308 were in MXG 22.12 dated Dec 2, 2004=========
Change 22.308 Duplicate variable names in KEEP= list are detected by
VMACTDSL one of Freddie's many QA tests that read MXG source; most
Dec 1, 2004 were just duplicates, but the second instance of TDSL09PR
should have been TDSL09PN.
Thanks to Freddie Arie, TXU, USA.
Thanks to Jacky Hofbauer, Atlantica, FRANCE.
Change 22.307 MXG 22.10 & 22.11 only. Support for IRD was STILL wrong,
VMAC7072 causing PCTCPUBY, PCTMVSBY, CPUACTTM and other PCTxxxxx
Dec 1, 2004 to be wrong in ANY interval in which CPUs were varied by
Dec 2, 2004 IRD. If more than 33% of the engines were varied off,
some of those values could actually be negative values!
The revised NRCPUS calculation for IRD in Change 22.233
tested the LPARWLMG flag for the last LPAR (PHYSICAL)
instead of that flag for this MVS system's LPAR. Now,
the correct LPAR's flag is used, and variable LPARWLMG
is kept in TYPE70 dataset so you can tell when IRD is
managing this system's CPUs. This change also protects
for manual vary of engines when IRD is not in control.
The magnitude of the numeric error depended on what pct
of the engines were offline; my IRD test data had 12
CPUs, and only 1-2 were offline, masking the problem;
it took negative values to cause me to see my errors.
Thanks to Dan Case, Mayo Foundation, USA.
Change 22.306 Support for CICS/TS 3.1: INCOMPATIBLE, as ALWAYS, since
EXCICPIR IBM CICS Development continues to insert fields in the
EXCICPIW middle of the existing SMF 110 subtype 1 CICSTRAN record.
EXCICWBG -New variables added to CICSTRAN dataset:
EXCICWBR DSCHMDCN='DSCHMDLY*COUNT'
FORMATS DSCHMDTM='DSCHMDLY*DURATION'
IMACCICS ICSTACCT='LOCAL*IC*START*REQUESTS'
VMAC110 ICSTACDL='BYTES IN*START CHANNEL*REQUESTS'
VMXGCICI ICSTRCCT='INTERVAL*CONTROL*START*CHANNEL*REQUESTS'
VMXGINIT ICSTRCDL='BYTES IN*CONTAINERS*START*CHANNEL REQS'
Nov 30, 2004 L9CPUTCN='L9CPUT*COUNT'
Dec 10, 2004 L9CPUTTM='L9CPUT*DURATION'
Jan 2, 2005 MAXSTDCN='MAXSTDLY*COUNT'
MAXSTDTM='MAXSTDLY*DURATION'
MAXXTDCN='MAXXTDLY*COUNT'
MAXXTDTM='MAXXTDLY*DURATION'
PCDLCRDL='BYTES IN*DPL RETURN*CHANNEL'
PCDLCSDL='BYTES IN*DPL REQUESTS*ISSUED'
PCDPLCCT='DPL*REQUESTS*ISSUED'
PCLNKCCT='LOCAL*PROGRAM*LINK*REQUESTS'
PCRTNCCT='REMOTE*PSEUDOCONV*RETURN*REQUESTS'
PCRTNCDL='BYTES IN*PSEUDOCONV*CONTAINERS'
PCXCLCCT='PROGRAM*XCTL*REQUESTS*ISSUED'
PGBRWCCT='BROWSE*CHANNEL*CONTAINER*REQUESTS'
PGGETCCT='GET*CONTAINER*REQUESTS'
PGGETCDL='BYTES IN*GET CONTAINER*CHANNEL*COMMANDS'
PGMOVCCT='MOVE*CONTAINER*REQUESTS'
PGPUTCCT='PUT*CONTAINER*REQUESTS'
PGPUTCDL='BYTES IN*PUT CONTAINER*CHANNEL*COMMANDS'
PGTOTCCT='CHANNEL*CONTAINER*REQUESTS'
WBBRWOCT='BROWSE*HTTPHEADER*REQUESTS'
WBCHRIN1='BYTES*RCVD FOR*RECEIVE OR*CONVERSE'
WBCHROU1='BYTES*SENT FOR*SEND OR*CONVERSE'
WBIWBSCT='WBIWBSCT'
WBPARSCT='PARSE*URL*REQUESTS'
WBRCVIN1='RECEIVE OR*CONVERSE*REQUESTS'
WBREDOCT='READ*HTTPHEADER*REQUESTS'
WBSNDOU1='SEND OR*CONVERSE*REQUESTS'
WBWRTOCT='WRITE*HTTPHEADER*REQUESTS'
X8CPUTCN='X8CPUT*COUNT'
X8CPUTTM='X8CPUT*DURATION'
X9CPUTCN='X9CPUT*COUNT'
X9CPUTTM='X9CPUT*DURATION'
-New SP, L9, X8, and X9 TCBs exist in CICS/TS 3.1 and CPU
time for each TCB is in CICSDS and CICINTRV datasets. The
full list of CICS TCBs are:
TCB VAR PREFIX DESCRIPTION
QR DSG QUASI REENTRANT MODE
RO DS2 RESOURCE OWNING MODE
CO DS3 CONCURRENT MODE
SZ DS4 SECONDARY LU MODE
RP DS5 ONC/RPC MODE
FO DS6 FILE OWNING MODE
SL DS7 SOCKETS OWNING MODE (SL)
SO DS8 SOCKETS OWNING MODE (SO)
J8 DS9 J8 - OPEN MODE
L8 DSA L8 - OPEN MODE
S8 DSB S8 - SOCKETS (SSL) MODE
H8 DSC H8 - NOT IN CICS/TS 3.1+
D2 DSD D2 - DB2 MODE
JM DSE JM - JVM CLASS CACHE MODE
J9 DSF J9 - OPEN MODE
SP DSH SOCKETS PTHREAD OWNING MODE (SP)
L9 DSI L9 - OPEN MODE
X8 DSJ X8 - OPEN MODE
X9 DSK X9 - OPEN MODE
-New variables in CICCONSR Statistics Dataset (STID=52):
A14ESPCN A14ESPCS A14ESPCR A14ESTCN A14ESTCS A14ESTCR
A14ESICN A14ESICS A14ESICR
-New DS4 variables for H8 POOL statistics are added to
dataset CICDSPOO (STID=60).
-Four new Statistics Datasets are created; the full list
of all STIDs and their datasets is in ADOCCICS member:
MXG Symbolic
Dataset IBM
Name STID Description of Data Set Name
CICWBG 101 URIMAPS (Global) STIWBG
CICWBR 104 URIMAPS (Resource) STIWBR
CICPIR 105 PIPELINE (Resource) STIPIR
CICPIW 106 WEBSERVICE (Resource) STIPIW
Change 22.305 INVALID NUMERIC DATA, 'TOTALS:' AT LINE ... COL ... and
EXXAMSYT INVALID NUMERIC DATA, 'TOTAL:' AT LINE ... COL ... and
Nov 30, 2004 NOTE: CHARACTER VARIABLES HAVE BEEN CHANGED TO NUMERIC...
due to IF NOT UPCASE(NAME)='TOTAL:' THEN DO; syntax.
Using IF NOT (UPCASE(NAME)='TOTAL:') THEN DO; or
using IF UPCASE(NAME) NE 'TOTAL:' THEN DO; corrects.
Thanks to Rodger Foreman, Acxiom, USA.
Change 22.304 Support for subtype 45 (PAGE SWEEP LIMIT EXCEEDED) record
EXHRN45 in ObjectStar SMF user records.
IMACHURN The pdf documentation of this subtype is incorrect.
VMACHURN The first 64 bytes of the HU45MSG field are decoded into
VMXGINIT un-labeled variables HU45H1-HU45H5 (hex), HU45C1-HU45C3
Nov 30, 2004 (EBCDIC text) and HU45N1-HU45N5 (numeric values).
Thanks to Mark King, S.A. Dept of Human Services, AUSTRALIA.
Thanks to Robyn Mcgeachie, S.A. Dept of Human Services, AUSTRALIA.
Change 22.303 -MXG Change 21.251 added support for the optional new data
VMACSASU in the SAS user SMF record, but MXG code was off by one
Nov 29, 2004 byte, causing the last digit of JESNR to be lost.
-SAS Version 9.1.3 has SASVEREL ' 9.10', which SAS sets
for all 9.1 images (9.1.0 1MO, 9.1.0 1M2, and 9.1.0 IM3),
and that will also be the value when SAS releases the new
Service Pack levels starting with SP1.
-The ENTRY had to be changed to SMFEXIT3 in BASMF job to
create the optional 64 bytes in the SMF User Record.
//SYSLIN DD *
INCLUDE SYSLIB(SMFEXIT)
ENTRY SMFEXIT3
NAME SMFEXIT(R)
Thanks to MP Welch, SPRINT, USA.
Thanks to Wilson Chen, SPRINT, USA.
Thanks to Tom White, SPRINT, USA.
Change 22.302 Support for VPS V1 R8.0 VPS-FAX, which uses the PrintWay
VMAC6 file transfer segment to add information for TCP/IP print
Nov 29, 2004 devices. Minor revision to MXG coding for that existing
segment will populate existing variable SMF6URI with:
mailto:email address (primary recipient)
lpr://hostname/queue
lrsq://hostname:port
direct_sockets://hostname:port
Thanks to Peter Harmut, R + V Versicherung, GERMANY.
Change 22.301 Use of ZEROOBS= parameter could fail due to incorrect
UTILBLDP tests for length of operands; using MACFILEX= option did
Nov 29, 2004 circumvent the MXG coding error.
Thanks to Willy Iven, Fortis Bank Belgium, BELGIUM.
Change 22.300 Using the FTP access method to read SMF data from one MVS
VMACSMF system when MXG executes on a different MVS system fails
VMXGINIT with "ERROR 23-2: INVALID OPTIONS NAME JFCB" because MXG
Nov 26, 2004 needs JFCB=SMFJFCB on the INFILE SMF statement so that
either BSAM or VSAM SMF file can be read transparently,
but the FTP access method does not support that option.
Since that option is needed only to read VSAM SMF data,
and since the ftp access method itself does not support
reading any VSAM file, and because there is no way to
know that you have allocated your SMF filename using the
ftp access method, the solution is to create a macro
variable &MXGJFCB in VMXGINIT that is initialized to the
string JFCB=SMFJFCB by default, and use that macro
variable in VMACSMF instead of the hard-coded option.
Then, if you want to use the FTP access method to read
SMF data from a different MVS system, you can eliminate
the SAS error by using
%LET MXGJFCB= ;
to remove the JFCB option from MXG's INFILE statement.
Thanks to MP Welch, SPRINT, USA.
Thanks to Maurice Pascal, ???, ???
Change 22.299 -STORHWMH and STORHWMK were defined in both _KUOWCIC and
VMXGUOW _KUOWCICX, but they are high water marks (maxima) and so
Nov 26, 2004 should only have been maximized.
-Macro _SUOWTMO did not correctly handle max and mins;
macros _KUOWCIX and _KUOWCIN were inserted after _KUOWIDC
and _KUOWCIC as was done in _SUOWCIC.
-Macro _SUOWTMO was reading the CICSTRAN dataset and not
MONITASK; SET _LCICTRN was changed to SET _LMONTSK.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 22.298 MXG 22.11 only. A missing @; caused SMF type 6 records
VMAC6 with the "PrintWay" File Transfer Section to fail with
Nov 22, 2004 INPUT STATEMENT EXCEEDED error
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 22.297 Short 'IF' NDM/CDI record caused INPUT STATEMENT EXCEEDED
VMACNDM error; instead of the expected 64 byte NDMRUID, there
Nov 17, 2004 were only 45 bytes at the end of the record. INPUT of
NDMRUID is now conditional if it exists.
Thanks to Bernie Mazur, Bank of Montreal, CANADA.
Change 22.296 Processing CMRDETL data on ASCII platform failed because
VMACMVCI the INFILE statement and VMXGRFV attributes contained the
Nov 17, 2004 BLKSIZE= parameter, which is not supported on ASCII:
Perhaps ASCII SAS should be smart enough to disregard,
instead of fail, but since ASCII files are nothing but
a single string of bytes, BLKSIZE has no meaning there.
Thanks to Steven Olmstead, Thompson, USA.
Change 22.295 Variable ACCIPAD, IP Address, is now output in WSFEVTPR
VMACWSF as well as WSCEVTSC.
Nov 16, 2004
Thanks to Stephane Attouz, Infosud, FRANCE
Change 22.294 -Support for APAR PQ73385 which adds data to IFCID 217 and
VMAC102 to IFCID 225.
VMACDB2 -Support for APAR PQ87848 which adds data to IFCID 173 to
Nov 12, 2004 monitor Dynamic SQL Statements that exceed RLF ASUTIME
Limit (and issued SQLCODE905).
-Support for APAR PQ91101 which adds more data to IFCID
225, and which added QISESTMT to DB2ACCT dataset.
Change 22.293 In PDB.ASUM70PR and PDB.ASUMCEC, all LP0xxxxx variables
VMXG70PR for LPARNAME='PHYSICAL' are always missing values; at one
Nov 9, 2004 time, Amdahl used zero for a real LPAR, so MXG test for
LPARNAME didn't populate LP0xxxx variables unless it was
a real Amdahl LPARNUM=0). But since Amdahl is now long
gone, it makes sense to populate the PHYSICAL LPAR data
in the LP0xxxx variables for consistency and so that the
newer PDB.ASUM70LP dataset can contain the data for the
LPARNAME='PHYSICAL'. In PDB.ASUM70PR and PDB.ASUMCEC,
the existing LPPUPDTM and PCTPOV variables are unchanged,
and the calculations that included LPPUPDTM and LP0UPDTM
are revised to not double account the PHYSICAL time.
Thanks to Anthony Lobley, EDS, ENGLAND.
Change 22.292 Debugging PUT statement is no commented out.
VMACSFS The Xerox SFS architecture is being replaced by an export
Nov 8, 2004 file produced by the Xerox Docutech 6135 network printer.
Thanks to Robert McElhaney, Texas Workforce Commission, USA.
Change 22.291 -Concatentating TNG files from multiple systems caused
VMACTNG incorrect results when the sets of fields were different;
Nov 8, 2004 values from the first system could be propagated into the
subsequent system's output, because the initialization DO
loop limit had the instance macro (&NT018I for example)
but the upper value should be %EVAL(&NT018I*&MAXROWS).
In addition, the init of the NTxxxINM variables had to be
relocated into their own DO loop.
-New NT Platform Names of NTW400I, WNS502I, and XPP501I
are all supported.
-Also, NT Platform Names are now defined in a new _NTPLAT
macro, so that new TNG names can be added in only one
place, or can be added in your IMACKEEP member.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 22.290 Enhancement for MQM processing creates new IHDRMQM exit
IHDRMQMH that can be used to select MQ records using variables
VMAC115 MQMSSSID SUBTYPE SYSTEM STARTIME
VMAC116 SM115REL (blank if ID=116)
VMXGINIT SM116REL (blank if ID=115)
Nov 5, 2004 Either member IHDRMQMH can be edited with your selection
logic, or %LET MQCMQMH= %QUOTE(your code;); can be used.
The existing TYPENQM member will process both SMF 115 and
SMF 116 records in one pass.
Thanks to Helmut Roese, COM Software, USA.
Change 22.289 The PDB.RMFINTRV dataset could have duplicate obs for the
VMXGRMFI first hour, if your RMFINTRV logic summarized your detail
Nov 5, 2004 RMF data (e.g., written at 15 minutes, but you tailored
IMACRMFI or your RMFINTRV memer to create HOURLY data),
but only if some SMF records for that interval were in
yesterday's SMF and the rest of that interval's records
were in today's SMF data. The MXG logic to calculate the
MSU4HRAV was at fault, incorrectly combining the data in
SPINRMFI with today's data.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 22.288 Comments in CICINTRV show how to create PDB.CICINTRV from
CICINTRV SMF data; CICINTRV is automatically included by TYPS110
VMAC110 and by BUILDPDB/BUILDPD3.
Nov 5, 2004 Default in VMAC110 now creates WORK.CICSACCT instead of
PDB.CICSACCT, so that a //PDB DD is not required if you
run %INCLUDE SOURCLIB(TYPE110). CICSACCT has had zero
observations for years, but historically was written to
the //PDB library.
Thanks to Neil Ervin, Charles Schwab, Inc, USA.
Change 22.287 Enhanced %VMXGPRAL utility. New option to run PROC FREQ
VMXGPRAL can be used to find out who's writing DB2 SMF 102 Trace
Nov 4, 2004 Records with this example:
%LET MACDB2H %QUOTE(KEEP QWHSSSID QWHSLUNM QWHSLOCN;);
%READDB2(IFCIDS=ALL);
%VMXGPRAL(DDNAME=WORK,NOBS=MAX,NOFREQ=FREQ,
NOPRNT=NOPRNT,NOMEANS=NOMEANS);RUN
- Note: the KEEP statement should almost never be used,
but it turns out that by using MACDB2H to insert
that statement inside the READDB2 processing,
only those variables listed will be output, so
the Trace Datasets won't take much disk space.
I first kept QWHCCV and QWHCCN, but the SMF 102 trace
records do not contain the Correlation Header.
Thanks to Hoang Ho, Experian, USA.
Change 22.286 -Two variables were not converted to EBCDIC when MXG was
VMAC80A executed on ASCII platforms:
Nov 4, 2004 RACF07DT ENTITYNM
Nov 5, 2004 -Support for RACFTYPE=29 DTP adds variable RACF29AD to the
Nov 8, 2004 TYPE8020 and TYPE8021 datasets.
Nov 9, 2004 -RACFTYPE=42 DTP segment variable CLASNAME was not kept.
Nov 10, 2004 In almost all datasets with variable CLASNAME, it comes
Dec 10, 2004 from DTP=17 segments. But datasets TYPE8024 and TYPE8X24
Dec 7, 2006 can have CLASNAME from DTP=21 and/or DTP=42 segments:
- TYPE8024 dataset can have both 21 and 42 segments, and
can have more than one DTP=42 segment, so that dataset
contains variables CLASNAME,CLASNAM1-CLASNAM4 from any
DTP=42 segments, and variable CLASNA21 from DTP=21s.
- TYPE8X24 dataset contains only DTP=21 segments, so the
variable name kept is CLASNA21, so as to matches the
name in the related TYPE8024 dataset.
This text was revised 2006, no code was changed.
-Multiple RACFTYPE=24 DTP segments, up to fifteen, are now
supported in RALTER (TYPE8020) and RDEFINE (TYPE8021) in
variables RESBYTE1-RESBYTEF and RESNAME1-RESNAMEF, like
the handling of multiple RACFTYPE=44 DTP segments in the
ADDUSER (TYPE8010) and ALTUSER (TYPE8013) datasets. The
choice of 15 is arbitrary, and could be increased if it
is needed, or a secondary dataset could be created in the
future if there are many more repeated segments in one
SMF 80 record.
-Multiple RACFTYPE=25 DTP segments in RALTER/DELMEM are
also supported, as above.
-Note that some cases of multiple segments currently will
be created as separate observations in additional data
sets, rather than separate variables. Specifically:
Dataset Command Multiple Segments
TYPE8X13 ALTUSER 40s
TYPE8Y13 ALTUSER 41s
TYPE8X24 SETROPTS 21s
-Dataset Label for TYPE8X13 and TYPE8Y13 were corrected to
ALTUSER (incorrectly had SETROPTS).
-Variable RACF07DT is now correctly input and it length is
set at $80 to hold installation data.
-Variable RESBYTE uninitialized was corrected.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Thanks to Larry Krause, Rite-Aid, USA.
Change 22.285 Label values for two variables were incorrect/incomplete
VMAC7072 and are revised to this description:
Nov 3, 2004 PCTDLCDE='CPU DELAY*PERCENT*NOT INCLUDING*WLM CAP'
PCTDLPDE='PCT WHEN*RESOURCE GROUP*MAXIMUM*ENFORCED'
And PCTDLPDE is not a delay; only PCTDLCDE will show
if there actually was a delay.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.284 Allocation Recovery subtype 7 (TYPETARC) support was not
FORMATS correct for variables after TARCDSN, now revised to match
VMACTMNT the DSECT. But the SMF records are not always correct;
Nov 2, 2004 many have 0 for DEVNR and following fields, all have ACTN
value 0, and ASID is only two bytes. Those errors in the
SMF record will be corrected in the next ASMTAPEE.
Thanks to Doug Medland, IBM Global Services, CANADA.
Change 22.283 Cosmetic. Error BIT MASK ... TOO LONG caused examination
VMAC1415 of all bit tests and three members were found to have
VMAC63678 bit literals that were not 8 or 16 symbols; fortunately,
VMACF127 none of those tests are currently executed, but the code
Nov 2, 2004 was revised nonetheless:
-TYPE1415 - bad test was inside ISAM code, not used now!
-TYPE6367 - VSAM catalog records no longer exist.
-TYPEF127 - FACOM operating system, probably defunct.
Change 22.282 Variable DATETIME was missing, because MXG code to create
ASUMHSM it from REQUEST was located before REQUEST was created;
Nov 2, 2004 this caused WHERE clause errors in a tailored IMACSHFT
Nov 5, 2004 member that used WHERE clauses and did not expect missing
values in DATETIME (nor should it have, since the error
was in MXG, not in the tailored IMACSHFT!).
-SUMBY FSRTYPE SHIFT logic in the internal invocations of
ANALCNCR had to be revised to remove SHIFT from SUMBY, as
it conflicted with SYNCINTV=YES default in ANALCNCR, and
the recalculation of SHIFT was relocated. This change
also corrected deeper errors, and the number of output
observations in PDB.ASUMHSM is now correct.
Thanks to Karl Lasecki, Chemical Abstracts, USA.
Thanks to Bruce Zink, Honda of America Manufacturing, USA.
Change 22.281 RACF SMF80DTP 44 segment with only SEGNAME and no text
VMAC80A caused *** RACF EV(44) ERROR. INVALID RACFDLNN=0 and
Nov 1, 2004 NOTE: INVALID THIRD ARGUMENT TO FUNCTION SUBSTR... and a
hex dump of each record. Code revised to protect zeroes.
Thanks to Ike Hunley, Blue Cross Blue Shield of Florida, USA.
Change 22.280 NRCPUS calculated in PDB.RMFINTRV using SMF70ONT could
VMXGRMFI have fractional values (0.999) instead of an integer when
Oct 29, 2004 IRD was not involved; the calculation was revised to add
0.005 and FLOOR/1000 to produce the expected integer.
Note that with IRD, fractional NRCPUS is very legitimate.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 22.279 Member TYPEVTOC is no longer executed in the test stream;
TESTOTHR it caused 0C4s under SAS V9 because of CCHHR= operang,
Oct 28, 2004 but it has been archaic ever since DCOLLECT/TYPEDCOL was
released. Because it is no longer in the test stream,
the three datasets it created VTOCLIST,VTOCMAP,VTOCINFO
will no longer be documented in DOCVER.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 22.278 In (archaic) VMAC90, variable SMF9029N was changed from
VMAC90 character to numeric in Change 21.320, but if you combine
Oct 28, 2004 TYPE90 built before and after that change, you got the
ERROR: VARIABLE SMF9029N HAS BEEN DEFINED AS BOTH CHAR...
This change replaces SMF9029N with SMF9029X to avoid that
error, but use of VMAC90A is the preferred solution.
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
====== Changes thru 22.277 were in MXG 22.11 dated Oct 26, 2004=========
Change 22.277 New argument MACFILEX allows you to insert SAS code after
UTILBLDP the SMF header has been read (like MACFILE), for user
Oct 26, 2004 tailoring of what records to read or not to read.
Change 22.276 A utility to analyze the size of SAS data libraries, with
ANALSIZE the number of datasets, number of variables, data bytes,
VMXGSIZE compressed bytes, and average compression percentages.
Oct 26, 2004
Thanks to Chuck Hopf, MBNA, USA.
Change 22.275 The array LCUZ in data step C4 was changed to LCU1-LCU256
ANALPATH and the final report will show up to 256 LCUs if present.
Oct 26, 2004
Thanks to Harald Seifert, HUK Coburg, GERMANY.
Change 22.274 Variables TOTSHARE and TOTSHARC are now kept in both the
VMXG70PR PDB.ASUM70PR and PDB.ASUMCEC so the original and current
Oct 26, 2004 total Weights are available; for summary intervals that
Oct 27, 2004 had more than one RMF record, the weights from the first
record are kept.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.273 The variable PCTCPUBY in QAPMSYST is now set to a missing
VMACQACS value, because there is no "total" CPU busy in QAPMSYST;
Oct 26, 2004 it is still kept so your report programs won't fail with
VARIABLE NOT FOUND errors, but set missing because it was
calculated from SHCPUTM, which is only the SystemTask CPU
time. New PCTCPTBY='PERCENT WHEN*SYSTASK*CPU BUSY' is
now calculated from SHCPUTM.
Thanks to Chris Selley, Zurich, ENGLAND.
Change 22.272 Support for zAAP IFA engines now requires MXG 22.11 due
VMAC30 to this change and change 22.265.
VMAC7072 =TYPE72GO Corrections:
Oct 25, 2004 -New zAAP CPU time CPUIFETM was incorrectly adjusted with
R723NFFI from R723IFCT, but IFCT is the time when zAAP-
eligible work executed on a CP, and that work executes at
the CPU speed, so the NFFI adjustment in MXG was wrong.
-Label CPUIAFTM='IFA*EQUIVALENT*CPU TIME' more accurately
describes the contents of that MXG variable.
-Variables R723IFCT (now, always equal to CPUIFETM), and
R723IFAT (unadjusted, equal to CPUIFATM ONLY if R723NFFI
is 256, and hence probably more confusing that useful),
are both now kept in TYPE72GO dataset.
-Calculation of IFAUNITS, IFEUNITS was corrected, and the
code to subtract IFAUNITS from CPUUNITS was relocated.
=TYPE30 Corrections:
-All TYPE30 IFA/IFE CPU times were wrong: I could blame
IBM, because there are two undocumented bytes after the
SMF30TF2 field that caused misalignment (but my +2 after
the SMF30TF2 was also wrong, it is now +1 for the second
byte of TF2, but now there's a new +2 needed to skip over
those undocumented two bytes). However, my guess that the
new times were like the immediately preceding SMF30CEP
field (input PIB4.6, multiply by 1024) was also wrong;
the new CPU times are PIB4.2 without the multiply).
And the offsets in the SMF manual are wrong starting at
SMF30TF2. (In my defense, Change 22.221 did note that the
changes had NOT been tested with data!).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Adam Warkow, Citigroup Technology Infrastructure, USA.
Change 22.271 The Macro _LOGSMF, used to read log files (like NDM/CDI)
VMACSMF that have "SMF Records" without the SMF Header, did work
Oct 23, 2004 when last tested, but DATA STEP STOPPED DUE TO LOOPING
error occurred using the TYPENDML example! Inserting
INPUT @; after the ELSE DO; appears to now be required
by SAS, and eliminated that error.
Thanks to Albert Jacobs, KBC, BELGIUM
Change 22.270 22.08-22.10 only. INPUT STATEMENT EXCEEDED RECORD LENGTH
VMACDB2H error with DB2 V8.1 SMF 100/101 records. INPUT of new
Oct 23, 2004 variable QWHSLOCO was PIB4, but the field is only PIB2.
Thanks to Roman Jost, ERGO Integration, NORWAY.
Change 22.269 MXG 22.07-22.10. Six variables in TYPE71 dataset:
VMAC71 LPAPGMN LPAPGMX LPAPGAV LPAFXMN LPAFXMX LPAFXAV
Oct 23, 2004 had missing values, because an extraneous "V" was added
to each variable name in its INPUT statement, when I had
added the IBM SMF field name in comments on each line.
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 22.268 Support for VTS R7.3 adds many statistics to TYPE94 and a
FORMATS few to TYPE94P; some 2-byte fields were expanded to four
VMAC94 bytes, but existing, reserved bytes were used for the
Oct 23, 2004 expansion, so the changes are compatible. You can tell
Oct 27, 2004 that R7.3 has been installed because S94LVVCF=730.
Oct 27: MXG 22.11 input these fields as $HEX2 per IBM doc
but IBM reports show them as decimal values, so
they were changed to PIB2 numeric variables:
S94LVVCM='VTS*CODE*MODIFICATION*VALUE'
S94LVVCF='VTS*CODE*FIX*VALUE'
S94LVLMV='LIBRARY*CODE*VERSION*VALUE'
S94LVLMR='LIBRARY*CODE*RELEASE*VALUE'
Change 22.267 The debugging PUT statement at line 745 should have been
VMACMVCI removed; it could flood sysout with millions of lines of
Oct 22, 2004 text: COL=390 T6ECPRID=F5 AFTER F4X
Thanks to Udo Froehline, Signal Iduna, GERMANY.
Change 22.266 Support for CMF Version 55.04 user SMF record (INCOMPAT).
VMACCMF INPUT STATEMENT EXCEEDED for CMF Version 5504 because the
Oct 22, 2004 BMC user SMF record removed four fields from subtype 1;
CMFREC01 was changed by BPM8956/BPM9152. MXG now INPUTS
those fields only for the old length of CMF01CSL=232.
Thanks to Peter Giles, Centrelink, AUSTRALIA.
Change 22.265 Support for APAR OA09118 adds the Service Definition
VMAC30 Coefficients (CPUCOEFF,SRBCOEFF,IOCOEFF,MSOCOEFF) into
Oct 22, 2004 the SMF type 30 records; these fields are needed now for
Oct 25, 2004 zAAP calculations, but have always been wanted in SMF 30.
-If the SDCs are in the SMF 30 record, variable IFAUNITS
will be non-missing, and variable CPUUNITS will contain
ONLY the CP TCB Service Units (i.e., IFAUNITS will be
subtracted from CPUUNITS if this APAR is installed).
-And if SDC values are present, the MXG-created variables
SRVTCBTM and SRVSRBTM will use the CPUCOEFF/SRBCOEFF from
the SMF record, rather than the &CPUCOEFF/&SRBCOEFF macro
default values of one, and CPUTOTTM will use the correct
SRVTCBTM/SRVSRBTM values. See text of Change 22.022.
-This change replaced Change 22.256.
====== Changes thru 22.264 were in MXG 22.10 dated Oct 13, 2004=========
Change 22.264 Variable QTGSUSLM in DB2STATS was not deaccumulated, so
VMACDB2 it have very large and meaningless values. DIF() logic
Oct 13, 2004 was added.
Thanks to John Shuck, Suntrust, USA.
Change 22.263 Revision of the original ANALDSET (DataSet Analysis) that
ANAL42DS uses the TYPE42DS interval records instead of TYPE1415
Oct 13, 2004 and TYPE64 close records. However, only SMS managed DISK
datasets are captured in TYPE42DS (but then ANALDSET only
reports on CLOSED datasets, so both may be necessary!).
Thanks to Chuck Hopf, MBNA, USA.
Change 22.262 Hardcoded DDNAME of PDB for PDB.DTSLOGPR and PDB.DTSCPU
VMACNTSM were replaced by their symbolic &PNTDTLP and &PNTDTCP.
Oct 13, 2004
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 22.261 The token for dataset TYPE4237 was missing from the _N42
VMAC42 and _S42 macro definitions, so that dataset was not NULLd
Oct 13, 2004 if _N42 was used, or wasn't sorted if _S42 was used.
Thanks to Ambat Ravi Nair, ATOSORIGIN, SINGAPORE.
Change 22.260 -MXG Change 22.221 for z/OS 1.6 IFAs has now been tested
VMAC7072 with real IFAs and found wanting, causing negative values
Oct 12, 2004 in PCTCPUBY and incorrect CPUWAITTM (but only for systems
that actually have an IFA; there are NO errors using MXG
22.08+ with z/OS 1.6 if you do NOT have any zAAPs).
The code has been updated for all three configurations of
Shared/Dedicated and Wait Completion Yes/No, but only the
Shared, Wait Complete=NO data has been validated.
-New variable MXGCIN in TYPE70PR is an attempt to identify
IFAs (which have SMF70CIN='ICF') from ICFs, with values:
'PHY' - Physical
'CP ' - CP Engine
'VM ' - VM Engine
'IFA' - IFA Engine
'ICF' - ICF (Coupling Facilit) or IFL (Linux) Engine
' ' - SPARE Engine
but this is a heuristic algorithm based on my test data,
but could use validation with your system's data.
-New variables IFACROSS and IFAHONOR are now kept in the
TYPE72GO dataset, where they are created, instead of the
TYPE70 dataset, where I originally kept them.
However: it really makes no sense for IBM to have put
the global parameters in the service-class TYPE72GO
records, but since that's where IBM put them, I have
to do the same.
-I originally spelled IBM field R723IFCU as R723IFEU in
TYPE72GO dataset, trying to use "IFE" for IFA-Eligible
and "IFA" for IFA-Actual, but the variable name is now
changed back R723IFCU to be consistent with the IBM name.
-The test data was from an early system, and these notes
may not be relevant to current IFAs, but are documented
in case these data are observed:
- During Startup Interval, the IFAWAITM is slightly
larger (tenths of a second) than the Interval Duration
which causes PCTIFABY to be slightly negative. While
I could detect and set PCTIFABY to zero, I will wait
to see if this is actually necessary with your data.
- The PHYSICAL LPAR data has LCPUADDR values that are
totally unexpected: 0,2,5,7,8,10,12,14,16,18,21,23,24,
26,28,30,32,34,37,39,40,42,44,46,48,50,53,55,56,60,62
for the 32 engines! While this has no impact, it does
look strange; IBM says its working as designed.
- Update from Martin Packer, Oct 17, 2005:
It turns out there is an explanation: when LCPUADDR
is displayed as a hex value, the first nybble is the
book number minus one, the second is the CPU number.
So the values above are for book 1 thru book 4, with
hex CPU numbers of 00,02,05,07,08,0A,0C,0E
-See Change 22.272, which corrected further errors and is
required for zAAP IFA processors.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.259 Variable NDMCPUTM had missing value in NDMPT dataset; a
VMACNDM circumvention now detects that "CPUTIME=" text is present
Oct 12, 2004 and inputs NDMCPUTM.
Thanks to Andreas von Imhof, RaboBank, THE NETHERLANDS.
Change 22.258 All TRND.... members were enhanced with macro variables
TRND.... &TRENDINP, &TRENDNEW, and &TRENDOLD (all of which are set
Oct 12, 2004 to "TREND" by default) so that you can override the MXG
default, and create a new TREND library, instead of reuse
(so that your TREND libraries can be GDGs, which is
required for CA's 11 job recovery product).
-Summarization of DB2ACCTB (Buffer used by Plans) should
have had WEEK.DB2ACCTB instead of WEEK.DB2ACCT.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.257 Summarization of MXGTMNT Tape Mount Monitor data can now
ASUMTMNT alternatively use the STK VSM STCVSM13 and STCVSM16 data
Oct 11, 2004 sets as input. Comment blocks must be removed, and you
must provide a way to identify the VSM devices.
Change 22.256 This change was replaced by Change 22.265.
VMAC30
Oct 11, 2004
Change 22.255 MXG format $MGSASPR, which maps the SAS procedure name to
FORMATS SAS Product Name, was updated for alternative spellings
Oct 11, 2004 (eg., SUMMERY for SUMMARY). The SMF record contains what
name was typed in, but when incorrectly spelled, SAS can
often "guess" the correct procedure name, leaving the
wrong spelling in the SMF record.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.254 False ***ERROR.INVALID TYPE42 SUBTYPE 5 RECORD DELETED
VMAC42 message caused only the last entry for that VOLSER to be
Oct 11, 2004 not output in TYPE42VT dataset; all other entries were
correctly output. Three tests for invalid length were
revised: each needed "-4" to be added to each test:
IF 0 LT S42VTVDO LT COL OR S42VTVDO+S42VTVDL-4 GT LENGTH
0 LT S42VTVXO LT COL OR S42VTVXO+S42VTVXL-4 GT LENGTH
0 LT S42VTVVO LT COL OR S42VTVVO+S42VTVVL-4 GT LENGTH
Thanks to John Parkes, Experian, USA.
Change 22.253 Change 22.211 required BLDNTPDB/BLDSMPDB invocation text
BLDNTPDB in your source code to be all lower case, but internal
Oct 11, 2004 code in BLDNTPDB was incorrect; using upper case text
in your invocation caused errors in the Week and Month
selection.
Thanks to Terry Heim, ECOLAB, USA.
Change 22.252 Variable QW0258TS is revised; it is input TODSTAMP8. and
VMAC102 formatted as DATETIME21.2, and the divide by 4096 was
Oct 12, 2004 removed.
-All raw DB2 datetimestamps are on GMT clock, so each must
be converted to local by the addition of GMTOFFDB, and
then each must then be in a %VMXGTIME call (in case your
site uses %TIMEBILD to convert all times to a different
time zone). These variables were missing the GMTOFFDB
addition: QW0022TS,QW0022BT,QW0125TS,QW0316TS.
Also, extraneous refs for QW0260TS,QW0261TS,QW0262TS
were removed.
Thanks to Christa Neven, KBC, BELGIUM.
Change 22.251 Format $MGSTCMR, for the type of mount, had additional
FORMATS values '03'x thru '07'x that are now decoded.
Oct 10, 2004
Thanks to Gilles Fontanini, ABS Decision, FRANCE.
Change 22.250 Support for Release 3.5 of BETA93 product for subtypes
FORMATS 0, 1, 2, 3, and 5 has been revised and 0-3 validated:
VMACBETA -Dataset BETA1 new variables:
Oct 11, 2004 BETAPCR BETADCR BETAFRM BETAEXT BETAPDEF BETAFDEF
BETABTKN BETARBTK BETAREPR BETARMOD BETARUSR
- However, the new REPRINT variables BETARPUS, BETAREPR,
BETABTKN, BETARMOD, and BETARBTK appear to be trashed
in the SMF record, producing missing/strange values.
-Dataset BETA3 is now valid; most variables were missing.
-Dataset BETA5 new variables:
BETAFRM BETAEXT BETARPTN BETAWRPT BETALTKN BETARTKN
-Some inconsistent variable names (FRM2,FRMX,EXT2,EXTX)
were eliminated.
-Other subtypes will be validated when sample records are
received; some timestamps are now SMFSTAMP8 format, but
only real records will reveal their internal formats.
-The subtype 50 record still has not been validly created
so it is not yet supported.
Thanks to Graham Cornwell, Donovan Data Systems, ENGLAND.
Thanks to Klaus Messer, COMLAB GmbH, GERMANY.
Change 22.249 Support for TDSLink user SMF record creates 26 datasets:
EXTDS01F dddddd dataset description
EXTDS01I TDS01T TDSL01TC TCP REJECTED PORTS
EXTDS01M TDS01I TDSL01IC ICMP EVENTS
EXTDS01T TDS01F TDSL01FT FTP EVENTS
EXTDS01V TDS01X TDSL01XO XOT EVENTS
EXTDS01X TDS01V TDSL01VT VTAM EVENTS
EXTDS04 TDS01M TDSL01MV MVS EVENTS
EXTDS06 TDS04 TDSL04 XOT CONNECTIONS
EXTDS07 TDS06 TDSL06 TCP CONNECTIONS
EXTDS08 TDS07 TDSL07 IP INTERFACES
EXTDS09 TDS08 TDSL08 LOCAL APPLICATIONS
EXTDS0A TDS09 TDSL09 REMOTE APPLICATIONS
EXTDS0B TDS0C TDSL0C TCP/IP STACK
EXTDS0C TDS0A TDSL0A IP NETWORKS
EXTDS0D TDS0B TDSL0B ENTERPRISE EXTENDER/IP NODES
EXTDS0E TDS0D TDSL0D CSM BUFFERS
EXTDS0F TDS0E TDSL0E PING OBJECTS
EXTDS10G TDS0F TDSL0F MQ SERIES QUEUES
EXTDS10L TDS10X TDSL10XC XCA HEADER
EXTDS10M TDS10G TDSL10GR GROUP
EXTDS10P TDS10M TDSL10MX CROSS DOMAIN RESOURCE MGR
EXTDS10R TDS10P TDSL10PU PHYSICAL UNIT
EXTDS10S TDS10S TDSL10SK SKLETAL PHYSICALUNIT
EXTDS10X TDS10L TDSL10LU LOGICAL UNIT
EXTDS11 TDS10R TDSL10RX CROSS DOMAIN RESOURCE
EXTDS12 TDS11 TDSL11 CPU AND MEMORY
TYPETDSL TDS12 TDSL12 DISK
TYPSTDSL
VMACTDSL
VMXGINIT
Oct 7, 2004
Thanks to Khalid Meskinia, SAS France, FRANCE.
Thanks to Alain Delaroache, Atlantica (Credit Agricole), FRANCE
Thanks to Jacky Hofbauer, Atlantica (Credit Agricole), FRANCE.
Change 22.248 ASUMCACH revised to tolerate zero obs in PDB.TYPE74CA.
ASUMCACH Previously, zero obs caused $CACHID format to not be
Oct 6, 2004 created.
Thanks to Jeff Harder, Indiana Farm Bureau, USA.
Change 22.247 Default test for Oracle SUBSYSID EQ 'OSDI' replaced the
VMACORAC SUBSYSID EQ 'TGW9' value, left after debugging. If you
Sep 30, 2004 re-define the _IDORACO macro in your IMACKEEP, it will
use your subsystem IDs, rather than the default in the
VMACORAC member, but 'OSDI' should have been the default
in the MXG code. See also change 20.111 text.
Thanks to John Rivest, TDS Corporate, USA.
Change 22.246 Support for Demand Technology's NTSMF Release 2.4.7.
VMACNTSM -MSEXCHANGEDSACCESS PROCESSES object, dataset MSEXPROC
Sep 30, 2004 has only seven variables, down from thirty nine.
-EPOXY object, dataset EPOXY, has two new variables.
-MSEXCHANGEIS MAILBOX object, dataset MSEXCHPU has six
new variables.
Change 22.245 -Support for Velocity Software's XAMAP Release 3.4, which
EXXAMSYT is INCOMPATIBLE, because new SYTCUP segment with LPARNAME
VMACXAM of "Totals:" had an invalid value for the number of LCPUs
Sep 30, 2004 causing INPUT STATEMENT EXCEEDED RECORD Length error if
Release 3.4 records are read without this change.
-The "Totals:" record is not output, as it duplicates the
CPU time in XAMSYT dataset, and caused 200% CPU busy's!
That tailoring code is externalized into the EXXAMSYT
exit member, if you ever decide you need it, unlikely.
-New variables are added to the XAMSYS dataset:
CPUCAPAB CPUCFGCT CPUCFGCT CPUCHAR CPUCOUNT CPUCOUNT
CPUDEDCT CPURESVD CPURESVD CPUSHARD CPUSTNBY CPUSTNBY
DEDCNT IOPCNT LPARCAF LPARNAME LPNUMBER MONECONH
MONECONL MONEVNTH MONEVNTL MONSAMPH MONSAMPL MONSCONH
MONSCONL SCPCAPAB SYSMMODL SYSMPOM SYSMSEQC SYSMTYPE
VL3CAF VL3CFGCT VL3COUNT VL3CPNAM VL3DBCT VL3MNAME
VL3RESVD VL3STNBY
-New variables added to the XAMSYT dataset:
CALPTIS LCUCWCPL LCUCCAPP LCPTYCP LCPTYICF LCPTYIOT
-Additional data from SUBSUM, PRCIOP, and IODVSW will be
added later, when someone asks to use the new data, or
I get bored/caught up. The preceding changes are all
that are needed to keep your current reports valid, and
add those new variables.
This note will be revised when that happens.
Thanks to Tony Curry, BMC, USA.
Change 22.244 RACF REMOVE event, dataset TYPE8023, did not decode the
VMAC80A Data Type 6 segment; the OWNER/GROUP and bit variables
Sep 30, 2004 are now created.
Thanks to Robert D. Mitchell, UBS, USA.
Change 22.243 INPUT STATEMENT EXCEEDED if old VMACNSPY member (prior to
VMACNSPY Change 22.131) read a NETSPY record that is a NETMASTER
Sep 30, 2004 subtype. NETSPY and NETMASTER are now combined and write
Referenced: a single SMF record with both NSPY and NETM subtypes, and
EXNETM50 Change 22.131 added support to create both NETM and NSPY
VMXGINIT datasets from the single SMF record. However, messages
INVALID NETSPY SUBTYPE were printed with Change 22.131,
and NETMASTER datasets all had zero observations, because
the more robust test for NETMASTER subtype must be first,
and the test for a NETSPY subtype can be executed when it
is clear the record is not a NETMASTER subtype.
Note that TYPENETM will still process NetMaster subtypes
in the NETSPY record, but if you have added both NSPY and
NETM logic to your BUILDPDB, either VMACNSPY will ABEND,
because both want to create the five NETMxxxx datasets.
You should remove NETM tailoring and use only NSPY to
create both NSPYxxxx and NETMxxxx datasets.
-This VMACNSPY requires MXG 22.02 or later, because 22.02
contained Change 22.037, which created the new EXNETM50
member and updated VMXGINIT to support the new NETM5000
NetMaster dataset.
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
Change 22.242 Example analysis provides Gartner Group with information:
ANALGART Batch Workload (e.g., MVS Batch Percentage CPU)
Sep 28, 2004 Interactive Workload (e.g., MVS/TSO Percentage CPU)
Online Workload (e.g., CICS,DB2,IDMS Percentage CPU)
across all partitions data.
The example assumes your Batch Work is in WORKLOAD=JES2,
TSO in WORKLOAD=TSO, Enclaves in DDF, CICS in CICS, so
you may need to tailor those definitions, and then it
reads your PDB library and build a tailored "RMFINTRV"
dataset named GARTNER, and print a summary report.
Thanks to Atle Mjelde, Ergo, NORWAY.
Change 22.241 Example summarization of the four IMF datasets:
ASUMCIMS PDB.ASUMIMTR : /*SUMMARY OF CIMSTRAN */
VMXGINIT PDB.ASUMIMDD : /*SUMMARY OF CIMSDBDS */
Sep 28, 2004 PDB.ASUMIMDB : /*SUMMARY OF CIMSDB2 */
PDB.ASUMIMPR : /*SUMMARY OF CIMSPROG */
Thanks to Ray Dorsing, Affiliated Computer Services, USA.
Change 22.240 Support for z/VM 4.4 INCOMPAT changes in SYTCUP record.
VMACVMXA New LCPTYPE='HARDWARE*CPU*TYPE' variable inserted in the
Sep 28, 2004 record is now supported. As no other errors with data
from z/VM 4.4 have been reported, I can claim "support"
with this change, but there could be new data variables
that are not yet decoded.
Thanks to Reinhard Lidzba, AGIS Allianz Dresdner, GERMANY.
Change 22.239 Member ERRORASC shows ASCII platform errors that occur if
ERRORASC you incorrectly download SMF data, and the member shows
Sep 28, 2004 how to use the %UDUMPEBC utility to determine what is in
the downloaded file, and how to resolve the cause of the
ERROR: Undetermined I/O failure.
ERROR: Unrecoverable I/O error detected...
This was originally in the undocumented "ERRORS" member,
but it contained unprintable characters that caused other
problems when that member was downloaded, so the revision
updated the contents and removed the unprintables.
Thanks to Dan Squillace, SAS Institute, USA.
Change 22.238 First pass at support for z/OS 1.4 SYSLOG file.
SYSLOG -Appends the type 'S' continuation record to create a
Sep 30, 2004 single event record
-Creates LOGGROUP sequence number for multi-record SYSLOG
events. See preliminary comments.
Please contribute suggestions for enhancements, as this
present implementation is still in first tests; some
important LOG events may be create new datasets, etc.
-Original example completely replaced.
Thanks to Freddie Arie, TXU Energy, USA.
Change 22.237 -To monitor STK tape devices with ML-31, you must use the
VMACTMNT XMEM=YES,MXIT=NO options when you assemble ASMTAPEE, to
Sep 27, 2004 capture the job-level information via Cross Memory calls.
Instead, for IBM tape devices, MXIT=YES,XMEM=NO is used
to eliminate Cross Memory calls and capture all mounts
in the IBM Volume Mount Exit - STK's HSC does not use
that exit, so you still have to use XMEM, until we can
find a usable HSC exit, research long underway.
Using the above options for STK caused DDNAME and STEPNR
to be blank/zero, because of a logic error in VMACTMNT:
The MXIT architecture captures these new variables:
ASID INITTIME JOBCLASS LOCLINFO PGMRNAME
RACFGRUP RACFTERM RACFUSER STEPNAME STEPNRX
TMNTACTN TMNTDEVC TMNTEDUR TMNTFLAG TMNTRCN
and these old variables:
DDNAME STEPNR
ML-31 SMF records have a new segment with those fields,
but they are not populated unless MXIT=YES was used;
MXG incorrectly INPUT those variables if the segment
was detected, causing the DDNAME/STEPNR fields in the
new segment overwrote the valid old . That logic was
corrected in this change.
-PDB.ASUMTAPE had missing values in RACFxxxx and ASID
variables because of the TYPETMNT error; that blank
DDNAME in TYPETMNT caused ASUMTAPE's merge of TYPETMNT,
TYPETALO, and IBM TYPE21 datasets to fail to correctly
propagate old ASID variables from TYPETALO into the
output PDB.ASUMTAPE dataset. Fixing TYPETMNT fixed.
Thanks to Normand Poitras, IBM Global Services, USA.
Change 22.236 New ANALFLSH member tracks how many flash copies are run
ANALFLSH in each 15 minute interval, as lots of parallel flashes
FORMATS can degrade performance. New format $MG022ST decodes the
VMAC22 copy status, and tests for LENGTH-COL were corrected to
Sep 26, 2004 use LENGTH-COL+1 for the bytes remaining in the record.
Since multiple records are written from multiple systems,
the ANALFLSH report must be tailored to select data from
only one system, since TYPE22_A dataset can have pseudo
duplicates. The sort order for TYPE22_A was changed to
SYSTEM SMFTIME SMF22CUA SMF22VOL to remove acutal dupes
when TYPS22 is used to sort TYPE22_A dataset.
Change 22.235 Support for ASG/Landmark TMON for DB2 Version 4.0.
VMACTMDB Only one dataset, TMDB7P appears to have been changed.
Sep 26, 2004
Thanks to Martin Legendre, Regie des Rentes du Quebec, CANADA.
=Drove to East Coast(NYC, NJ, DEL) then drove thru Hurricane Ivan in GA
=enroute to FLA (Wakulla County), then drove thru Hurricane Ivan again
=one week later in Shreveport, LA. Rain was 6 inches per hour, for
=about an hour both times, but traffic only slowed to 60 mph.
Change 22.234 Support for DB2 V8.1 IFCIDs 140,141,142,145 SQL text that
VMAC102 was relocated; without this change the QW014nTX variable
Sep 9, 2004 was blank even when there was SQL text in the record.
Thanks to Ep van der Es, Dow, BELGIUM.
Change 22.233 MXG's calculation of NRCPUS when IRD was NOT active could
VMAC7072 be very slightly wrong, calculating 2.0020 for 2 engines.
Sep 1, 2004 The use of NRCPUS=ROUND(SMF70ONT/DURATM,.001) was the
cause, but by replacing that calculation with
IF SMF70ONT GT 0 AND NRCPUS GT 0 AND LPARWLMG='Y' THEN
NRCPUS=SMF70BDA;
the correct IRD calculation (LPARWLMG='Y') is done, and
for non-IRD, MXG had correctly counted the integer number
of engines, which is unperturbed when LPARWLMG NE 'Y'.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 22.232 CMR time is added to the calculation of MPL74 time:
VMAC74 MPL74=SUM(DEVCONTM,DEVDISTM,DLYCMRTM)/DURATM;
Sep 1, 2004 Originally, errors in the CMR field in the record caused
it to be left out, but APARs have corrected the value.
This agrees with Cathy Cronin's "FICON and FICON Express
Channel Performance Version 2.0" IBM White Paper.
Thanks to Ray Waugh, Merrill Lynch, USA.
Change 22.231 If an NTSMF data set was unlabeled, using %BLDNTPDB with
EXNTDB2A RUNWEEK=WTD caused VARIABLE NOT IN DATASET errors. The
EXNTDB2D new PDB.DTSCPULP was build from two datasets by did not
FORMATS have a label.
IMACNTSM -FORMATS was updated with the $MGDDDDD and $MGDDDSN for
VMACNTSM all of the new NTSMF datasets.
VMXGINIT -DATABASE object with 170 fields support added.
Aug 31, 2004 -MSEXCHANGEIS object with 126 fields support added.
Sep 8, 2004 -DB2 DATABASE MANAGER (originally DB2 NT DATABASE MANAGER)
object with 28 fields is support added.
-New objects DB2 DATABASE and DB2 APPLICATIONS with 94 and
90 fields respectively create NTDB2DAT,NTDB2APL datasets.
Thanks to Terry Heim, ECOLAB, USA.
Change 22.230 Variable A17DTCFP, CFDT Pool Name was hex zeros rather
VMAC110 than blanks when there was no pool name. MXG now tests
Aug 30, 2004 and sets the variable to blanks instead of hex zeroes.
Thanks to Harald Seifert, HUK=COBURG, GERMANY.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.229 Cosmetic. ABNDRSNC TERMIND UNINITIALIZED messages were
BUILD005 printed the first time BUILDPDB/BUILDPD3 were executed,
BUIL3005 with nothing in the //SPIN library, but those messages
Aug 26, 2004 had no impact. Compiler fakers suppress the messages.
Change 22.228 Second instance of INCLASS in the KEEP list should have
VMACTPMX been INCLASSJ.
Aug 26, 2004
Thanks to Bruce W. Christopher, Housholde International, USA.
====== Changes thru 22.227 were in MXG 22.09 dated Aug 25, 2004=========
Change 22.227 Typo left a start-comment /* as the last line of member
VMAC99 VMAC99, which caused problems. Stray text was deleted.
Aug 25, 2004
Thanks to Chris Weston, SAS ITSV Development Cary, USA.
Change 22.226 Back-level ASG/TMON Version 2.0 records caused INVALID DO
VMACTMO2 LOOP CONTROL because I forgot that SAS won't tolerate a
Aug 25, 2004 missing value and had added DO _I_=1 TO TAAMQCNT; without
testing that TAAMQCNT had been input; it was a new field
in ASG/TMON Version 2.3 that was missing when 2.0 records
were read. All the DO _I_ statements are now protected.
Thanks to Nori Abakah, Progress Energy, USA.
Change 22.225 ANALDB2R(PDB=PDB,PMAUD02=YES) caused FORMAT MGD140O NOT
ANALDB2R FOUND (but a $MGD140O did exist in the format library),
Aug 25, 2004 because the variable that was PUT with $MGD140O format
did not exist, and thus was created as numeric, causing
SAS to look for a numeric rather than a character format.
The variable did not exist because not all datasets that
ANALDB2R expected were in the PDB library. If you use
%ANALDB2R(PDB=SMF...), it creates all needed datasets for
the requested reprots; if %READDB2(INFILE=SMF,IFCIDS=...)
is used to create a PDB, and all IFCIDs are not requested
then using %ANALDB2R(PDB=PDB ..) may fail. You can use
%READDB2(INFILE=SMF,CLASS=AUDIT...) to create a PDB with
all needed datasets for AUDIT reports (and that PDB will
have zero obs datasets for the IFCIDs with no records,
with all datasets created, all variables exist. Seeing
this exposure, a "compiler faker" was added for each of
the character variables that are PUT with FORMAT, forcing
those variables to be character variables, to circumvent
the error when all expected datasets are not present.
Thanks to Sharon Nagy, Comerica Bank, USA.
Change 22.224 SMF 6 or 57 record with ESS segment, but with SMF57TUL=0,
VMAC57 was not expected, caused INPUT STATEMENT EXCEEDED error.
VMAC6 Since there was an ESS segment, text was assumed present!
Aug 24, 2004 Now, the text length is tested. This text was revised
Oct 26, 2004 Oct 26, when same error did occur with SMF 6 record.
Thanks to Scott Wiig, US Bank, USA.
Thanks to Jurgen Strauch, Zweckverband Kommunale Stuttgart, GERMANY.
Change 22.222 NDM subtype QE record caused INPUT STATEMENT EXCEEDED.
VMACNDM The CDI DSECT does not agree with the record; the QTYPE
Aug 24, 2004 field is only 1 byte in the record but the DSECT shows a
Aug 26, 2004 halfword. The Queue Status contains a valid 'SS', and
the SEQ field contains '0000'x, but the error was because
MXG always expected that was followed by an 8-byte field
with SYSPLEX SERVER NAME, but that field does not exist
in all releases of NDM. Code was added to conditionally
input SERVER NAME only when it exists for the QE, TP, PI
and FA subtypes, and all with SERVER NAME field.
-Invalid value for OFFSET to JOB DATA SET NAME protected.
Thanks to Gerrit Van Meerbeek, HP/Procter and Gamble Cie, BELGIUM.
Change 22.221 Support for z/OS 1.6, but now, Change 22.272 is required.
VMAC30 Change 22.180 and prior APARs supportd most z/OS 1.6 new
VMAC7072 data and changes in MXG 22.07 and 22.08, but TYPE72GO
BUILD005 code (ONLY FOR z/OS 1.6 RECORDS) was wrong, causing many
BUIL3005 INVALID DATA messages and incorrect output in TYPE72GO
Aug 25, 2004 when z/OS 1.6 records were read (NO errors with 1.5 RMF).
The SKIP=SKIP-16 needed to be SKIP=SKIP-28 in SUBTYPE=3
code block for LENSCS GE 532.
-The extensive MXG Technical Note on IFAs/zAAPs in MXG
Newsletter FORTY-FIVE discussed MXG revisions to some of
the existing MXG variables; this change implements those
new calculations and new variables for TYPE72GO/TYPE70:
-In TYPE72GO:
CPUIFATM - IFA CPU Time spent on IFA
CPUIFETM - CP CPU Time that was Eligible to run on IFA
IFAUNITS - IFA Service Units spent on IFA
IFEUNITS - CP Service Units that were Eligible for IFA
CPUTCBTM - CP CPU Time (does NOT contain IFA CPU time)
CPUUNITS = CP Service Units (NOT contain IFA Units)
-It is likely the VELOCITY calculations in TYPE72GO will
be changed, but this is just a note that they have NOT
been revised to include IFA samples.
-TYPE70 dataset was revised to include only CP engines in
existing PCTCPUBY, CPUACTTM, etc, and labels now include
"CP" to identify. New IFA Capacity Variables added.
PCTCPUBY,CPUACTTM,CPUUPTM,CPUWAITM are all "CP-only".
PCTIFABY,IFAACTTM,IFAUPTM,IFAWAITM are all "IFA-only".
Individual PCTIFBYn and IFAWAITn variables exist for
each of the possible 32 IFA engines.
IFAACTTM='IFA ENGINE*EXECUTING*(ACTIVE) CPU TIME'
IFAUPTM ='IFA ENGINE*AVAILABLE*(UP) TIME'
NRIFAS ='NUMBER OF*IFA*ENGINES*AVAILABLE'
PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'
IFAWAIT0-IFAWAITX - IFA wait for each of 32 engines
PCTIFBY0-PCTIFBYX - IFA PCT BUSY for each engine.
-This data has been tested with z/OS R 1.6 RMF 72 records,
but not with IFAs installed, so please validate the
old and new percentages when you install an IFA.
Change 22.272 updates have been tested with 30s and 72s.
-TYPE30 variable's names were changed to be consistent:
CPUIFATM='TOTAL*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'
and these variables are added to the PDB.JOBS & PDB.STEPS
in the BUILDPDB/BUILDPD3 logic.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 22.220 All 275 ADOC members were updated with new variables and
ADOC.... the variable lengths were corrected back to their MVS
Aug 22, 2004 lengths. The text in these documentation members was not
touched by the elegant utility that Freddie implemented,
which uses the text in DOCVER to update the variables.
Thanks to Freddie Arie, TXU, USA.
====== Changes thru 22.219 were in MXG 22.08 dated Aug 20, 2004=========
MXG 22.08 was re-dated Aug 20, 2004, when I discovered seven members
were missing from the 3480 tapes,including VMAC0 which caused JCLTESTx
to fail. The re-dated version included these additional changes:
Change 22.219 -Variable DISKRATE was misspelled in two KEEP= lists ad
VMACMWUX DISKRT.
Aug 20, 2004 -Variable DISKNAME was increased to $64 as $20 was too
short; only $35 were seen thus far, but this will avoid
yet another change later, hopefully!
-Comments revised to caution that a dollar sign should not
be used as a delimiter, as dollar signs appear in the tty
field in the MeasureWare PROC records.
Thanks to Roman Gudz, Penske Logistics, USA.
Thanks to Albert Jacobs, KBC, BELGIUM.
Change 22.218 The PDB exit _EDBJOBS was relocated so it precedes the
BUILD005 OUTPUT ACCOUNT; statement; if you used the _EDBJOBS exit
BUIL3005 to populate ACCOUNTn variables for Started Tasks that do
Aug 20, 2004 not have accounting parameters on their "JOB" card, your
code worked just fine for the PDB.JOBS dataset, but the
observations in PDB.STEPS and especially in PDB.SMFINTRV
contained blanks for the ACCOUNTn variables, because the
ACCOUNT (temporary) dataset is used to "back fill" those
other PDB datasets. With this code relocation, any exit
changes to ACCOUNTn variables will be propagated into the
PDB.STEPS, PDB.PRINT, and PDB.SMFINTRV datasets.
Note: It used to be that you HAD to use a table lookup
based on JOB name to assign ACCOUNTn variables
for STCs, but for all current OS/390 and z/OS,
you can put account fields on the "JOB" card for
the STC, and they will automatically be carried
into the PDB.JOBS/STEPS/PRINT/SMFINTRV datasets.
Thanks to Ken Jones, Xwave, CANADA.
Change 22.217 The extraneous IF in IF BYTEAVAIL=MAX(...) was removed,
VMACNTSM but it had no impact since the prior test for AVAILMEK
Aug 20, 2004 was never satisfied.
Thanks to Xiaobo Zhang, ISO, USA.
Change 22.216 The utility to convert character-variables-containing-hex
UTILCVRT after you move SAS datasets from MVS to ASCII worked fine
Aug 20, 2004 but added temp variables LENGTH and _I_ to the output.
Now it doesn't, and LENGTH was respelled as _L_.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 22.215 Creating CPU graphs of NT SMF data caused errors VARIABLE
BLDNTPDB STARTIME NOT FOUND and INVALID VALUE FOR SORTEDBY; the
Aug 20, 2004 sumby= statement was corrected and the DROP was removed.
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 22.214 Commas were missing after XX='EN' and YY='WO' in lines
MXGSASV9 15 and 16 in the JCL procedure for SAS V9.
Aug 20, 2004
Thanks to Wade Peterson, McMaster-Carr Supply Company, USA.
Change 22.213 Variable R723CRTF was not kept in the TRND72GO dataset
TRND72GO because it was misspelled as R723CRFT in the ID=
Aug 19, 2004 statement.
-The default example TRND72GO summarizes at the SRVCLASS
level of detail, but you may prefer to summarize at the
PERIOD level, since Goals and Importance can be set at
the lower level. You can add PERIOD at the end of the
SUMBY= statement in your tailored TRND72GO if you want
the PERIOD level included in the trending summary.
Thanks to Rick Mansfeldt, IBM Global Services, USA.
Change 22.212 The FTPREPLY field changed from a binary value to EBCDIC
VMACTCP numeric; APARs PQ92769 and PQ83055 documents this change
Aug 18, 2004 in the format of the field; MXG code supports both the
old and the new format transparently.
Thanks to Tom White, SPRINT, USA.
Change 22.211 The JCL example for testing with SAS Version 9 needed the
JCLTEST9 //MONITASK and //SPIN DDs in step TESTOTHR.
Aug 17, 2004
Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd
Change 22.210 JES3 JMF SMF 84 caused INPUT STATEMENT EXCEEDED RECORD;
VMAC84 the statement LOCJSTOF+LOCJSTOF+48; in VMAC84 should
Aug 17, 2004 have been: LOCJSTOF=LOCJSTOF+48;
Thanks to Paul Gillis, Pacific Systems Management Pty. Ltd
Change 22.209 While all INFORMAT xxx $NOTRAN statements were removed in
BUILD005 Change 22.192, using PROC SYNCSORT still caused BUILDPDB
BUIL3005 to fail, because the SPIN.SPIN30_4 dataset had variables
Aug 17, 2004 with that INFORMAT. This change removes the informat for
the two variables ABNDRSNC TERMIND as that dataset is
read, eliminating that (hopefully!) final exposure.
Alternatively, you could just use
DATA SPIN.SPIN30_4;
SET SPIN.SPIN30_4;
INFORMAT ABNDRSNC TERMIND ;
to replace the SPIN30_4 data set and remove the INFORMAT.
-I discovered the INFORMAT statement must be AFTER the SET
statement to remove the informat from the variables!
Thanks to Michael L. Kynch, International Paper, USA.
Thanks to Peter Giles, Centrelink, AUSTRALIA.
Change 22.208 -Support for TOKDANAM=GID creates new variable TOKGID in
IMAC6ESS TYPE80xx datasets that can contain the 53 segment.
VMAC80A -Removed unneeded PUT statement in IMAC6ESS member that
Aug 13, 2004 was observed in the log.
Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY.
====== Changes thru 22.207 were in MXG 22.08 dated Aug 13, 2004=========
Change 22.207 FLASH. For MVS SAS V9.1 and V9.1.2. SAS Note SN-12943
CONFIGV9 reports incorrect results with PROC MEANS,SUMMARY,REPORT
Aug 13, 2004 and TABULATE only on "MVS", if threading is used, and the
SAS default option is THREADS. Specifying NOTHREADS does
corrects the error, which is fixed in SAS V9.1.3, and SAS
will have a Hot Fix very soon for V9.1 and V9.1.2, but I
still decided this was sufficiently critical to re-date
the MXG 22.08 release and include NOTHREADS in CONFIGV9
member, since you could easily change that option in your
CONFIGV9 later, or use OPTIONS= on your // EXEC statement
when you have the fix and find threading is of value.
Thanks to MP Welch, SPRINT, USA.
Change 22.206 Cosmetic. Some fields caused 'Note 49' and blanks were
VMACEREP inserted, to support that future version possible change.
IMACICBB
Aug 13, 2004
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
====== Changes thru 22.205 were in MXG 22.08 dated Aug 12, 2004=========
Change 22.205 New CICS Statistics datasets were not listed in IMACCICS,
IMACCICS and worse, were not invoked in the _CICSTAT nor _S110ST
VMAC110 macros, and the example to use both in Change 18.152 did
Aug 12, 2004 not work. The new datasets are now added/listed.
-The _S110ST macro sorts all CICS Statistics datasets from
the "Wdddddd" work default (WORK) to their "Pdddddd" PDB
library.
-The _CICSTAT changes both the _W and _Pdddddd names, to
the value (ddname) you stored in macro variable CICSTAT,
but could not be used with the _S110ST macro because the
same DD would be used for both _W and _P datasets.
-The new _CICSTAS (S=sort!) changes only the Pdddddd for
the output of the SORTs, so it can be used in EXPDBOUT
ahead of _S110ST to sort all CICS statistics datasets to
the DDname specified in macro variable CICSTAT.
To COPY all cics stats datsets to DDname "CICSSTAT", use
%LET CICSTAT = CICSSTAT;
_CICSTAS;
_S110ST
in your EXPDBOUT member, and all of the CICS statistics
datasets will be CICSSTAT.CICxxxxx.
Thanks to Nori Abakah, Progress Energy, USA.
Change 22.204 Support for new fields added by DB2 V7 and V8 in T102S172
VMAC102 for IFCID=172 (all units of work involved in a deadlock).
Aug 12, 2004 The test for QWHSRELN EQ 7.1 was changed to GE 6, as the
Aug 13, 2004 "V7" data existed starting with DB2 Version 6.
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
Thanks to Brad Kiemann, Department of Defence, AUSTRALIA.
Change 22.203 Cosmetic. VGETJESN decodes JCTJOBID to create JESNR and
VGETJESN TYPETASK, but if JCTJOBID was hex zeros or blank, as for
Aug 12, 2004 some records for JOB='INIT', unnecessary messages that
WARNING - TYPETASK NOT DECODED were printed on the log.
Now, VGETJESN tests to see that JCTJOBID is non-blank,
so the unnecessary warning messages won't be printed.
Thanks to Ng Kin, Acxiom, USA.
Change 22.202 Cosmetic. Invalid SMF 42 subtype 21 record cause MXG to
VMAC42 print an MXG error message that APAR OA02184 corrects the
Aug 11, 2004 bad records, but that APAR only corrects errors when the
delete used ISPF STOW command; if the delete was done by
DESERV FUNC=DELETE, the record is wrong and IBM has just
created APAR OA08693 to correct that error. The text of
MXG's error message said the record was DELETED, but at
the point of the error, MXG had already output TYPE4221.
The bad segment prevents an output to TYPE422A dataset,
so the text of the error message was clarified that it is
the rest of the record that is being deleted.
Thanks to Scott Wiig, U.S. Bank, USA.
Change 22.201 Aren't you glad SAS developers use MXG for testing new
VMXGSUM releases of SAS? Their early tests of SAS V9.2 found an
Aug 11, 2004 MXG syntax error that had previously been absorbed with
no compiler error. The text %ELSE %THEN %DO; was
corrected to %ELSE %DO;
Thanks to Rick Langston, SAS Institute Cary, USA.
Change 22.200 Variables SASVEREL SASUSER and SASJOBID are created by a
VMACSASU SUBSTR() of a $64 variable, so they defaulted to length
Aug 11, 2004 of 64. They are now defined in a LENGTH $8 statement.
These fields were added by Change 22.251, but, now, see
Change 22.303 for the (final?) correction.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.199 Major revision to IMS0708 dataset, created by TYPEIMS7,
EXIMS78 from the IMS 07/08 log records. Previously, transactions
EXIMSMRY with the same DTOKEN were summed into only one output
TYPEIMS7 observation, but that destroyed the detail "servictm" of
VMACIMS each program schedule event, and there can be thousands
VMXGINIT of Quick Restart program schedules with the same DTOKEN.
Aug 12, 2004 And each program schedule event could have serviced many
(NMSGPROC) transactions for each detail event. This
redesign eliminates the summarization by DTOKEN, creating
one observation for each program schedule event, with the
detail NMSGPROC, IMSCPUTM, etc., for each schedule event.
-If both 08 and 07 are found, STRTTIME and ENDTIME will
be non-missing; if only an 07 end event with no matching
08 start is found, STRTTIME will be missing, and for an
08 only with no 07 start (or back-to-back 08s) ENDTIME
will be missing.
-For events with the same DTOKEN, new variable INSTANCE
counts individual event instances.
-New variables SYSABEND and USRABEND decode the COMPCODE
into more meaningful variables in IMS0708 detail dataset.
-VMACIMS had to be revised to increase the stored length
of IMSRECNO to 8 bytes; it is now used to sequence events
within each DTOKEN. Originally it was a PIB4. field that
was stored in 5 bytes, but it was changed to a PIB8 field
in IMS Version 6, and should have been increased then.
-VMXGINIT was updated to support the new tokens PIMS78 and
PIMSMRY which can be used to set the DDNAME of IMS0708
and IMSSUMRY datasets. The default value for the output
DD is the _IMSTRAN old-style macro, so if you have set it
in your IMACIMS7 member to "IMSTRAN", the new TYPEIMS7
will still create IMSTRAN.IMS0708, or the example in the
TYPEIMS7 member shows you can use %LET PIMS78=IMSTRAN; in
your //SYSIN stream to set the destination DDname.
-But in case you really want the summary by DTOKEN, new
IMSSUMRY data set can be created by the _IMSUMRY macro,
as documented in comments in TYPEIMS7 member.
-And the original TYPEIMS7 program is preserved in the MXG
member ZTYPIMS7, just in case you feel a need to revert.
-The requestor of this change also wanted to create a new
dataset, IMSABEND, with only ABENDing transactions, but I
decided against making that an "MXG dataset", because the
IMACKEEP member and the _KIMS78 and _EIMS78 macros can
easily be used to create the new dataset, as shown below
in the example that also creates a new ORIGUSID variable
at the same time:
MACRO _KIMS78
ORIGUSID )
IMSABEND (KEEP=COMPCODE ORIGUSID USRABEND SYSABEND
%
MACRO _EIMS78
ORIGUSID=IMSUSID;
IF '0' LE IMSUSID LE '9' THEN IMSUSID='INTERNAL';
OUTPUT _LIMS78;
IF COMPCODE NOT
IN('00000000'X,'40404040'X,'20202020'X)
THEN OUTPUT IMSABEND;
%
The use of the _Kdddddd and _Edddddd macros to create new
datasets is documented in the DOCMXG member.
Thanks to Glenn Lundgren, SEB IT Service, SWEDEN.
Change 22.198 The PCTWFLOW calculation was revised to match the WFL %
ZRBRPT3 value shown on the RMF III panels, using the revised
Aug 6, 2004 equation from the RMF Programmers Guide that had been
overlooked since 1996.
Thanks to Randy Shumate, LexisNexis, USA.
Thanks to Steven L. Hankins, LexisNexis, USA.
Change 22.197 The Ficon Open Exchange analysis program was revised to
ANALFIOE keep only Online channels, and to delete Ficon Bridge
Aug 5, 2004 channels, to which the analysis does not apply.
The example in comments to create the datasets from SMF
was revised again, now using the three _Sdddddd dataset
sort macros instead of the _Sxxxx product sort macros.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 22.196 Support for longer length DB2 identification variables:
VMACDB2H QWHSLOCN QWHSAID QWHCOPID QWHCEUID QWHDRQNM QWHDSVNM
Aug 5, 2004 is prepared to read in the up-to-128-byte character text,
but the length of those variables is not changed, yet.
Only when you actually increased-length data would you
want to increase their stored length in each observation
in your DB2ACCT dataset, and that can be done in your
//SYSIN in the job that creates your DB2ACCT data, using:
%LET MACFILE= %QUOTE( LENGTH QWHSLOCN $128;);
The longer fields can also now be in UNICODE, but until I
have test data, and until there is a need, I chose not to
to add that alternative code (UNICODE requires SAS V8,
and because the DB2 code is used in BUILDPDB, the longer
I hold off adding the UNICODE support, the longer those
few sites still running SAS V6 can limp along).
Thanks to Charles Harbour, John Deere, USA.
Change 22.195 INVALID DATA FOR YYYY warning for SMF 102 IFCID=22 when
VMAC102 the QW0022TS field contained nulls; the inputs with NUM
Aug 4, 2004 informat were protected with ?? syntax.
Thanks to Jim Poletti, Edward Jones, USA.
Change 22.194 Typo. SUN.ASUM79PR should have been SUN.ASUM70PR.
WEEK70PR
Aug 4, 2004
Thanks to Ingegerd Jansson, Volvo Information Technology AB, SWEDEN.
Change 22.193 Support for many new NTSMF objects, including DTS CPU
EXNTDTCP configuration records, Exchange 2003, Exchange 2000
EXNTDTLP instant messaging, Outlook 2003, and RSVP objects create
EXNTIACP these new datasets:
EXNTIAUP dddddd dataset description
EXNTMEII NTDTCP DTSCPU NT DTS.CPU
EXNTMETF NTDTLP DTSLOGPR NT DTS.LOGICALPROCESSOR
EXNTMSAS NTIAUP IASAUTPR NT IAS AUTHENTICATION PROXY
EXNTMSDC NTIACP IASACCPR NT IAS ACCOUNTING PROXY
EXNTMSGC NTMEII MSEXIM NT MSEXCHANGEIM
EXNTOUTL NTMETF MSEXTRFS NT MSEXCHANGE TRANSPORT FILTER SINK
EXNTRSVI NTOUTL OUTLOOK NT OUTLOOK
EXNTRSVP NTRSVI RSVPINTR NT RSVP INTERFACES
EXNTSMSM NTRSVP RSVPSERV NT RSVP SERVICE
IMACNTSM NTMSAS MSEXCHAS NT MS EXCHG ACTIVESYNCNOTIFY OMAPUSH
VMACNTSM NTMSDC MSEXCHDC NT MS EXCHG DSACCESS DOMAIN CONTROLLER
VMXGINIT NTMSGC MSEXCHGC NT MS EXCHG DSACCESS GLOBAL COUNTERS
Aug 3, 2004 NTSMSM SMSMSE NT SMS SMSMSE 4.5
Aug 5, 2004 -Most of the sample data records from the test system have
zero values, so it is impossible to know which, if any,
will need to be de-accumulated; if you have real data for
any of these objects, please contact support@mxg.com for
instructions on sending us your file for validation.
-The new DTSCPU and DTSLOGPR objects indicate HyperThread
Support and Status. MXG merges the two objects into an
enhanced PDB.DTSLOGPR dataset (in the _SNTDTLP sort macro
when you use TYPSNTSM) with the CPU information from the
DTSCPU object and the logical processor information from
the DTSLOGPR object. HyperThreading is determine by:
DTCPNLPS - Number of Logical Processors Supported
DTCPNLPA - Number of Logical Processors Active.
DTCPNLPS DTCPNLPA
Hyperthreading Unsupported: missing one
Supported/Disabled: not missing one
Supported/Enabled: not missing more than 1
-The new HyperThread objects were added structurally by
NTSMF 3.4.7, so this change supports that release.
Change 22.192 All INFORMAT xxxx $NOTRAN.; statements are removed from
DOC all source code. That informat has never actually done
Aug 2, 2004 anything; it was planned to "mark" the hex-containing
character variables, so SAS could detect NOTRAN and not
translate them, but that was never implemented in SAS,
and the circumvention (to use UTILCVRT instead) has been
provided in MXG since Change 19.271.
Note that the $NOTRAN. format will always be created in
the MXG FORMATS member, to protect old MXG datasets.
The motivation for this change was the error in Syncsort
PROC SYNCSORT product under SAS Version 9.1.2, which does
not correctly handle INFORMATs, and since the $NOTRAN was
no longer needed, removing all will eliminate one more
possible error, if you have the PROC SYNCSORT product and
they have not fixed their error when you install 9.1.2.
Search NEWSLTRS for PROC SYNCSORT for details.
IMACICBB IMACICOC IMACICSA TYPEMOND TYPETMON TYPEVM
VMAC1415 VMAC21 VMAC22 VMAC28 VMAC33 VMAC36
VMAC37 VMAC38 VMAC39 VMAC41 VMAC42 VMAC60
VMAC6156 VMAC64 VMAC78 VMAC79 VMAC80 VMAC84
VMAC88 VMAC89 VMAC8911 VMAC90 VMAC90A VMAC91
VMAC92 VMACACF2 VMACACHE VMACAICO VMACAICS VMACAIM6
VMACBETA VMACBGSI VMACCIAO VMACCIMS VMACCMF VMACCMFV
VMACCOMP VMACCRAY VMACCTLG VMACDALO VMACDLMN VMACDMON
VMACEPIL VMACEPMV VMACFILA VMACFOCU VMACFTEK VMACFTP
VMACHBUF VMACHIPR VMACIAM VMACIDMJ VMACIDMS VMACILKA
VMACILKV VMACIMS1 VMACITRF VMACLMS VMACMDF VMACMIM
VMACMON8 VMACMPT VMACNAF VMACNNAV VMACNOAM VMACODS
VMACOMAU VMACOMCI VMACOMVT VMACOPC VMACPKMN VMACPRFS
VMACPROS VMACQAPM VMACRDS VMACROSC VMACRTE VMACSAMO
VMACSAR VMACSARS VMACSARX VMACSFTA VMACSMF VMACSNAP
VMACSOLV VMACSPMS VMACSTX VMACTCP VMACTIE VMACTIRS
VMACTMNT VMACTMS5 VMACTMV2 VMACTPX VMACTSOM VMACVMON
VMACVMXP VMACVSME VMACWSF VMACX37 VMACXCOM VMACXPSM
VMACXSTR VMACXXXX VMXGHSM VMXGVTOC VMXGVTOF
Subnote: in my class, discussing "sub-second" response
response time, I compare measures of EDITing under TSO
with three (okay, old!) connections: 2400 and 9600 baud
and local channel attached, and measured a max of 900
"TGET"s (inputs) per hour. This PC updated 120 members
took 20 minutes; there were at least one sequence of
SELECT, FIND, MARK, DELETE, FIND, SAVE for each member,
so, without the delay due to TSO swapping, this EDIT
session exceeded 2100 transactions per hour.
Change 22.191 Support for ASG/TMON TCE for CICS/ESA 2.3: COMPATIBLE, as
EXMONAMQ all new fields were added at the end of records, so MXG
IMACTMO2 21.21 or later will read the new records without error.
VMACTMO2 The new version added many fields now supported in MXG in
VMXGINIT the many TMON datasets, and one new dataset is created:
Aug 2, 2004 Dataset MONITASK dataset new variables:
TAWRDCT ='WAIT FOR*REDISPATCH*COUNT'
TAWRDTM ='WAIT FOR*REDISPATCH*TIME'
TAUSRWCT ='USERWAIT*TIME'
TAUSRWTM ='USERWAIT*COUNT'
Dataset MONISYST new variables:
TIMIDNSC='MIDNIGHT*NON-SEGMENTED*TASKS*COUNT'
TIUSRWCT='WAIT FOR*REDISPATCH*COUNT'
TIUSRWTM='WAIT FOR*REDISPATCH*TIME'
TIWRDCT ='WAIT FOR*REDISPATCH*COUNT'
TIWRDTM ='WAIT FOR*REDISPATCH*TIME'
Dataset MONIAWT new variables:
TAAWTWRC='WAIT FOR*REDISPATCH*COUNT'
TAAWTWRT='WAIT FOR*REDISPATCH*TIME'
Dataset MONICMX new variables:
TICMXHWM='CLASS*HIGH*WATER*MARK'
TICMX ='TICMX*SEGMENT*COUNT'
Dataset MONIIWT new variables:
TIIWTWRC='WAIT FOR*REDISPATCH*COUNT'
TIIWTWRT='WAIT FOR*REDISPATCH*TIME'
Dataset MONITJ new variables:
TJSREQCT='JVM*REQUESTS*WITH*RESET'
TJCREQCT='JVM*REQUESTS*WITH*CLASSCACHE'
Dataset MONIPA new variables:
PACBRNM ='CORBASERVER NAME'
PADSCWC ='STG CONSTRAINT WAIT COUNT'
PADSCWT ='STG CONSTRAINT WAIT TIME'
PADSMWC ='TCB MISMATCH WAIT COUNT'
PADSMWT ='TCB MISMATCH TIME'
PADSTHW ='PEAK OPEN TCBS'
PAEJBACT='BEAN ACTIVATION REQUESTS'
PAEJBCCT='BEAN CREATION REQUESTS'
PAEJBMCT='EJB METHOD CALLS'
PAEJBPCT='BEAN PASSIVATION REQUESTS'
PAEJBRCT='BEAN REMOVAL REQUESTS'
PAEJBTCT='TOTAL EJB REQUESTS'
PAHTDLYC='HOT POOL DELAYS'
PAHTDLYT='HOT POOL DELAYS TIME'
PAJ9CPUC='J9 CPU COUNT'
PAJ9CPUT='MODE J9 CPU TIME'
PAJTDLYC='JVM TCB DELAYS TIME'
PAJTDLYT='JVM TCB DELAYS'
PAKY9CPC='KEY 9 CPU COUNT'
PAKY9CPT='KEY 9 CPU TIME'
PAKY9DSC='KEY 9 DISPATCH COUNT'
PAKY9DST='KEY 9 DISPATCH TIME'
PAPTPWTC='PARTNER WAIT COUNT'
PAPTPWTT='PARTNER WAIT TIME'
PAROCPUC='RO CPU COUNT'
PAROCPUT='RO CPU TIME'
PARODSPC='RO DISPATCH COUNT'
PARODSPT='RO DISPATCH TIME'
PASOI1C ='SOCKET CHARS RECEIVED'
PASOIMC ='SOCKET RECEIVE REQUESTS'
PASOO1C ='SOCKET CHARS SENT'
PASOOMC ='SOCKET SEND REQUESTS'
Dataset MONIPA new variables:
PIRECICT='PI*RECORD*COUNT'
PIKY9DST='KEY 9*DISPATCH*TIME'
PIKY9DSC='KEY 9*DISPATCH*COUNT'
PIKY9CPT='KEY 9*CPU*TIME'
PIKY9CPC='KEY 9*CPU*COUNT'
PIJ9CPUT='MODE*J9*CPU*TIME'
PIJ9CPUC='J9*CPU*COUNT'
PIDSMWT ='TCB*MISMATCH*TIME'
PIDSMWC ='TCB*MISMATCH*WAIT*COUNT'
PIDSCWT ='STG*CONSTRAINT*WAIT*TIME'
PIDSCWC ='STG*CONSTRAINT*WAIT*COUNT'
PIEJBACT='BEAN*ACTIVATION*REQUESTS'
PIEJBPCT='BEAN*PASSIVATION*REQUESTS'
PIEJBCCT='BEAN*CREATION*REQUESTS'
PIEJBRCT='BEAN*REMOVAL*REQUESTS'
PIEJBMCT='EJB*METHOD*CALLS'
PIEJBTCT='TOTAL*EJB*REQUESTS'
PIRODSPT='RO*DISPATCH*TIME'
PIRODSPC='RO*DISPATCH*COUNT'
PIROCPUT='RO*CPU*TIME'
PIROCPUC='RO*CPU*COUNT'
PIPTPWTT='PARTNER*WAIT*TIME'
PIPTPWTC='PARTNER*WAIT*COUNT'
PISOOMC ='SOCKET*SEND*REQUESTS'
PISOO1C ='SOCKET*CHARS*SENT'
PISOIMC ='SOCKET*RECEIVE*REQUESTS'
PISOI1C ='SOCKET*CHARS*RECEIVED'
PIJVIRST='JVM*RESET*TIME'
PIJVIRSC='JVM*RESET*COUNT'
PIJTDLYT='JVM*TCB*DELAYS*TIME'
PIJTDLYC='JVM*TCB*DELAYS'
PIHTDLYT='HOT*POOL*DELAYS*TIME'
PIHTDLYC='HOT*POOL*DELAYS'
Dataset MONITKP new variables:
TKPTOTMT='MVS*STORAGE*CONSTRAINT*WAIT*TIME'
TKPTOTMW='MVS*STORAGE*CONSTRAINT*WAITS'
Dataset MONITR new variables:
TRSTGWWT='STORAGE*REQUEST*WAIT*TIME'
TRSTGWCT='STORAGE*REQUEST*WAITS'
New Dataset MONIAMQ for MQ variables:
TAAMQCLC='MQCLOSE*CALLS'
TAAMQCLT='MQCLOSE*CALL*TIME'
TAAMQFLG='QUEUE*MQ*API*FLAG'
TAAMQGTC='MQGET*CALLS'
TAAMQGTT='MQGET*CALL*TIME'
TAAMQICT='TAAMQ*SEGMENT*COUNT'
TAAMQIQC='MQINQ*CALLS'
TAAMQIQT='MQINQ*CALL*TIME'
TAAMQMGO='ORIG*QUEUE*MANAGER*NAME'
TAAMQMGR='MQ*QUEUE*MANAGER*NAME'
TAAMQOPC='MQOPEN*CALLS '
TAAMQOPT='MQOPEN*CALL*TIME '
TAAMQP1C='MQPUT1*CALLS '
TAAMQP1T='MQPUT1*CALL*TIME '
TAAMQPTC='MQPUT*CALLS'
TAAMQPTT='MQPUT*CALL*TIME'
TAAMQQUE='MQ*QUEUE*NAME'
TAAMQQUO='ORIG*QUEUE*NAME'
TAAMQSTC='MQSET*CALLS'
TAAMQSTT='MQSET*CALL*TIME'
Change 22.190 Support for NTSMF Objects MicroStrategy Server Jobs and
EXNTMSSJ MicroStrategy Server Users create new datasets MSTRSRJB
EXNTMSSU and MSTRSRUS (MSTRSRJB is complete, but only structure
IMACNTSM code exists MSTRSRUS, with no fields, as the dictionary
VMACNTSM record for the User's object has not yet been created).
VMXGINIT Because some of the fields are presented as totals, and
Jul 29, 2004 are not deaccumulated interval values, the _SNTMSSJ sort
macro must be used to de-accumulate the datasaet, so the
first observation for each instance has missing values.
Additional heuristics to detect when these total values
went to zero (perhaps a shutdown of the process?) were
necessary.
Thanks to Bob Gauthier, Albertsons, USA.
Change 22.189 Major update added 1300 lines of text to document most of
ADOC110 the undescribed CICSTRAN variables, using IBM's CICS
Jul 29, 2004 Performance Analyzer Report Reference 1.3 manual.
Change 22.188 Variables S94VCA41-S94VCA48, S94CA481-S94CA488, and
VMAC94 S94CA351-S94CA358 are all multiplied by 60 (so their
Jul 29, 2004 internal value is seconds) and then formatted TIME8.
so they will print as hh:mm:ss units of time, since they
are all rolling average cache ages.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.187 The format to map SAS Procs to their Product for the SAS
FORMATS user SMF record was updated for PROC SORTT, which is an
Jul 29, 2004 undocumented way of forcing the internal SAS Sort utility
to be used instead of a "host" sort product.
Thanks to Dave Thorn, SunGard Availability Service, USA.
Change 22.186 Omegamon/VTAM V520 IRNUM 29 caused DIVISION BY ZERO and
VMACOMVT LOOPING; the test for IRNUM IN (29,30) was incorrect for
Jul 28, 2004 IRIND NE 'L'.
Thanks to Phil Baxter, Capgemini Group, ENGLAND.
Change 22.185 Invalid SMF 80 Extended Relocate Section contained token
VMAC80A PROGRAM but there was no length of program name nor the
Jul 28, 2004 program name field following the token) caused and INPUT
STATEMENT EXCEEDED RECORD error. Circumvention tests for
expected length field, while IBM support is contacted.
Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY.
Change 22.184 ASCII Execution only, SAS V9 only: EBCDIC character
DOC variables can contain hex zeros instead of blanks due to
Jul 28, 2004 a V9 SAS design change, which can cause character tests
to fail and/or cause spurious MXG error messages when an
expected character was not found. Under ASCII execution,
the $VARYINGn informat reads a variable length string,
but the value is "raw" and must be converted to EBCDIC if
that's what's really in the text. Previous to Version 9:
INPUT VARIABLE $VARYINGnn. LENTEXT @;
VARIABLE=INPUT(VARIABLE,$EBCDICnn.);
VARIABLE=TRANSLATE(VARIABLE,' ','80'X);
was sufficient: when LENTEXT was less than nn, $VARYINGnn
returned ASCII blank '20'x for the extra characters, the
INPUT function converted them to '80'x, and thus the
TRANSLATE of '80'x back to blank was necessary. Now, SAS
V9 $VARYING informat returns hex zeros, rather than ASCII
blanks for the extra characters, and the INPUT function
passes the hex zeros into it's output, so it is necessary
now to use these statements for each $VARYING variable:
INPUT VARIABLE $VARYINGnn. LENTEXT @;
VARIABLE=INPUT(VARIABLE,$EBCDICnn.);
VARIABLE=TRANSLATE(VARIABLE,' ','80'X);
VARIABLE=TRANSLATE(VARIABLE,' ','00'X);
to convert those unexpected hex zeros to character blank.
All 511 TRANSLATE statements with '80'x were replicated
and the '80'x changed to '00'x in the second instance in
these 55 MXG members:
ANALSNAP IMAC6ESS IMACACCT INSTALL SYSLOGJ3 UTILTPMX
UTILXREF VMAC102 VMAC103 VMAC119 VMAC120 VMAC24
VMAC33 VMAC37 VMAC42 VMAC4789 VMAC59 VMAC6
VMAC60 VMAC6156 VMAC80A VMACACC VMACACF2 VMACASXT
VMACCMA VMACCTLG VMACDB2 VMACEDGS VMACENDV VMACHMF
VMACHPDM VMACIMS VMACNDM VMACNETM VMACNSPY VMACOPFT
VMACPOOL VMACQACS VMACQAPM VMACRSDA VMACSARR VMACSASU
VMACSHDW VMACSOLN VMACTCP VMACTMDB VMACTPMX VMACTSOM
VMACVMON VMACVMXA VMACVVDS VMACXPSM VMXGHSM
- An alternative was to replace the INPUT and TRANSLATE
functions with INPUTC(variable,'$EBCDIC.'); but its
syntax needs additional quotes (the second argument
is not an INFORMAT, but a literal/variable containing
an informat), the length has to be removed, (it fails
if the informat has an "n" value), and in some cases
just didn't seem to work correctly (returned only one
character when there were three), all of which made
it very unattractive to EDIT/CHANGE those many times!
- The TRANSLATE statement supports multiple pairs, so
it could have been written as
VARIABLE=TRANSLATE(variable,' ','80'x,' ',00'x);
but that too was mechanically risky, and was too long
for some existing lines of code, so a second function
statement was inserted.
Change 22.183 The Working Set Size variables ACTVWSS and VMDWSSPR are
VMACXAM in 4096 byte blocks, so they are now converted to bytes
Jul 27, 2004 and FORMATed MGBYTES to "print pretty" storage units.
Aug 8, 2004 Aug 8: Semi-colon added to FORMAT statement to correct
error detected in Freddie's QA tests.
Thanks to Rodger Foreman, Acxiom, USA.
Thanks to Freddie Arie, TXU, USA.
Change 22.182 The field FCFILENM was truncated at 32 bytes; the INPUT
VMAC119 was 64 bytes, but the statement MINLEN=MIN(32,LEN11903);
Jul 26, 2004 is now corrected to MINLEN=MIN(64,LEN11903);.
Thanks to Ken Jordan, Pacific Gas & Electric, USA.
Change 22.181 Enhancements to RMF Reporting.
ANALRMFR -Online Time Percentage field added to CPU Activity Report
Jul 26, 2004 -Updates to Partition Data Report
-LPAR Cluster Report added, use REPORT=LCLUS to request.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
====== Changes thru 22.180 were in MXG 22.07 dated Jul 25, 2004=========
Change 22.180 IFA CPU variables added by APAR OA05731, Change 22.152
VMAC22 variable names are clarified and more consistent:
VMAC30 R723IFAT - IFA*CPU TIME*ON IFA
VMAC7072 R723IFCT - IFA-ELIGIBLE*CPU TIME*ON CP "C-for Coulda?"
VMAC71 Some additional revisions were made for IFA processors.
VMAC74 This change includes new fields added to RMF 74-5 by
VMAC75 APAR OA04877.
VMAC79
BUILD005
BUIL3005
Jul 24, 2004
Change 22.179 The UCICSCNT utility to examine and count CICS records in
FORMATS your SMF file was enhanced with additional reports on the
UCICSCNT Statistics STIDs found in your data, and corrected so the
Jul 23, 2004 PROC FREQs always work without error. New formats for
a description of STID and MNSEGCL are added in FORMATS.
Thanks to Tren Burner, City of San Antonio (TEXAS, of course), USA.
Change 22.178 The INSTANCE=, argument allows selection by "UOWIDCHR",
ANALDB2R the first six bytes of UOWID (which is also QWHSLUUV),
Jul 23, 2004 but the internal logic was wrong in ANALDB2R. The test
and comments for how to use INSTANCE= were revised; the
value passed must be hex characters, with no quotes and
without the "X" that is used for hex literals in data
step logic.
Thanks to Jim Mourgelas, TD Bank Financial Group, USA.
====== Changes thru 22.177 were in MXG 22.07 dated Jul 23, 2004=========
Change 22.177 Update to define MACRO _Vdddddd in selected members.
VMACIDMS -VMACIDMS: The _Sdddddd macros now invoke PROC SORT with
VMACTMS5 NODUP and the _Bdddddd macros are defined.
Jul 22, 2004 -VMACTMS5: _Vdddddd defined.
Aug 8, 2004 -Aug 8: These members were EDITed and support _V macros:
VMAC20 VMAC25 VMAC26J2 VMAC26J3 VMAC28 VMAC31
VMAC32 VMAC33 VMAC36 VMAC37 VMAC38 VMAC39
VMAC40 VMAC41 VMAC434 VMAC4345 VMAC44 VMAC4789
VMAC50 VMAC5234 VMAC535 VMAC5568 VMAC57 VMAC59
VMAC60 VMAC6156 VMAC6367 VMAC68 VMAC69 VMAC7
VMAC75 VMAC81 VMAC83 VMAC85 VMAC88 VMAC89
VMAC8911 VMAC90 VMAC90A VMAC91 VMAC92 VMAC94
VMAC97 VMAC99 VMACNSPY VMACSTC VMACSYNC VMACTCP
VMACTMNT VMACTPF VMACTSOM
Thanks to Dale Houg, Abbott Labratories, USA.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.176 Invalid SMF 42 subtype 5 caused INPUT STATEMENT EXCEEDED
VMAC42 error; this record contained only volume segments, with
Jul 21, 2004 422 valid segments, but the 423rd segment was overlaid.
It has valid S42VTNXT (00004FE4x) VOLSER (IMS210), DEVNR
(6BC5x) and S42VTFL1 (80x, indicating online), and 2 in
S42VTUNC, but the 2nd and 3rd offsets are overlaid:
S42VTVDO/S42VTVDL are '000000000000'x
S42VTVXO/S42VTVXL are '000000006C87'x and
S42VTVVO/S42VTVVL are '0001C4C2F2C2'x,
and the hex dump shows that last data is a VOLSER DB2B91
overlaying the third offset/length, and the rest of the
record is control unit information that doesn'b belong
there. MXG added tests to detect these invalid offsets,
and prints error messages for the first five bad records,
and prints a hex dump of the first bad record; variable
OFFVOL in the error message is the start of the defective
volume segment.
This text will be updated when an IBM fix is identified.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
Change 22.175 Major revision to this Utility to inventory the Contents
UTILCONT of SAS data libraries, reporting on size of each dataset
Jul 21, 2004 in MegaBytes, and the percentage of the library occupied
by each SAS dataset. The inventory can be output to the
ASUMSIZE dataset, which could be added to your PDB and
then TRENDed over time to monitor growth of your PDBs.
But only datasets are reported; DICTIONARY.TABLES doesn't
provide the size of CATALOGS (GRAPHS, SASMACR) in the
LIBNAMEs.
You can specify the list of LIBNAMEs to be inventoried
PDB=PDB WEEK MONTH (default is PDB=PDB), so to size the
datasets in yesterday's PDB in a standalone job on MVS
you would need to use this syntax:
// EXEC MXGSASV9
//PDB DD DSN=YOUR.PDB,DISP=SHR
//SYSIN DD *
%UTILCONT(PDB=PDB);
Under MVS, when you supply a list of LIBNAMEs, UTILCONT
issues a LIBNAME DDNAME SHR; statement for each LIBNAME;
the DICTIONARY.TABLES requires that each LIBNAME has
been 'referenced' (OPENed, or in a LIBNAME statement).
If any LIBNAME is sequential-format (e.g., tape), that
ENTIRE physical library must be read to find its size,
taking time and resources; you can skip reading of all
sequential format libraries using EXCLUDE=SEQUENTIAL,
or just don't put that LIBNAME in your list!
Instead, you can use PDB=_ALL_ to inventory all LIBNAMEs
that have been referenced; the _ALL_ choice enables the
EXCLUDE=SEQUENTIAL DUMMY GISMAPS LIBRARY MAPS SAS SASHELP
default list to skip sequential and 'SAS-owned' LIBNAMEs
that we think you don't want reported, but you can use
EXCLUDE=DUMMY GISMAPS LIBRARY MAPS SAS SASHELP in your
%UTILCONT invocation if you do want sequentials reported.
On MVS, the reported size closely matches the MVS dataset
allocated size, but on ASCII platforms the actual files
are slightly larger than the reported size; the directory
of variables is not included in pagesize*number-of-pages.
Change 22.174 Using the IDCAMS EXPORT Catalog function, the output file
VMACCTLG always has a few defective records, but those records do
Jul 20, 2004 not appear to actually contain any catalog segments. This
change revises the old "NOT UNDERSTOOD" MXG messages with
specific description of the two possible defects found.
IBM's "trench-holder" technican who "owns" the catalog
records refused to provide any documentation, claiming
the catalog records are "object code only", and their
contents could not be released, and his manager was also
unable to listen to reason (like, do they really think
think Microsoft is going to create a competing catalog
dataset, as kludgy as IBM's???), so I can only continue
to delete the defective records in the export file.
-The comments now contain the JCL for the IDCAMS program.
Thanks to Greg Burt, Fifth Third Bank, USA.
Change 22.173 Support for RMF 99 subtypes 3, 4, and 8 create four new
EXTY99U3 datasets:
EXTY994I dddddd dataset description
EXTY998L TY99U3 TYPE99_3 99-3 Service Class Period
EXTY998P TY994I TYPE994I 99-4 Device Cluster
IMAC99 TY998L TYPE998L 99-8 LPAR
VMAC99 TY998P TYPE998P 99-8 Priority Table
VMXGINIT -None of the "Plot" tables are created for these subtypes;
Jul 17, 2004 only tables that had test data are supported.
-I made blind guesses as to the format of two variables,
S998CPUT and S998PTMA.
Thanks to Richard S. Ralston, Humana, USA.
Change 22.172 ASCII only. Zero observations in TYPEVVDS because the
VMACVVDS INPUT of VVRTYPE was $EBCDIC1. instead of $CHAR1. Other
Jul 17, 2004 HEX-containing variables were also corrected and INPUT
with $CHAR and formatted with $HEX. On "MVS", $EBCDIC
and $CHAR are the same, but not so on ASCII platforms
This member was overlooked, because most sites use the
TYPEDCOL/DCOLLECT data to examine VVDS data, but the
TYPEVVDS has more detail information and is now correct.
Thanks to Glenn Bowman, Wakefern, USA.
Change 22.171 Enhancement for RMF III VSAM file reading program.
ASMRMFV -The very last CSR table entry was not being output.
Jul 16, 2004 -RMFV104I message for RED record type always showed Y for
SELECT, even when that table was not selected. Only the
message was incorrect; data exclusion did occur if RED
table was not selected.
Thanks to Jerome Urbaniak, Acxiom CDC Inc, USA.
Thanks to Len Romano, Hewitt Associates, USA.
Change 22.170 Support for TNG NT Windows Server 2003 Enterprise Ed 5.2,
EXTNT067 PLATFORM='WNE502I', added 35 new objects, some of which
thru are also created on PLATFORM='NTS500I. New NT datasets
EXTNT099 NT065 thru NT099 are documented in updated IMACTNG.
FORMATS -LENTEXT GT 99 tests caused errors with INSTANCE names
IMACTNG greater than 36 characters; all were revised to test for
VMACTNG GT 35 (TNG's base-35 encoding has '10'=36) to bump LOC
VMXGINIT by 2 positions; this should have been fixed earlier, but
Jul 16, 2004 -New MIB-2 Object data had over 12,000 instances for three
metrics, which makes little or no sense, and until that
data is better understood, only the first instance will
be output in new NT089 dataset.
-If you use the distributed TYPETNG/TYPSTNG members, you
must remove the %LET MAXROWS=1; statement that was added
by Change 22.160 to override the MAXROWS=288 MXG default
(288 supports 24 hours of 5-minute-interval data cubes).
-With MAXROWS=288 and the MXG default array sizes, the
TYPETNG program now needs about 300MB of virtual memory.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 22.169 Support for Hogan System's optional CICS segment was not
IMACICHO complete; UTILEXCL recognized Hogan data was present, but
VMAC110 the IMACICHO member did not exist. It does now, and will
UTILEXCL create these four Hogan variables:
Jul 15, 2004 FPSAPPL - Application Code
FPSFUNC - Function Code
FPSCSCR - Current Screen
FPSSIPR - Previous Screen
Old code in IMACICUS had additional Hogan variables:
FPSACTN ='HOGAN*ACTION*CODE'
FPSOPTN ='HOGAN*OPTION*CODE'
FPSSCRN ='HOGAN*SCREEN*NAME'
PLDVERS ='HOGAN*PAS*VERSION'
TCTPLD ='HOGAN*ODS TCTNAME/*PAS PLDNAME'
TCBFUNC ='HOGAN*ODS TCT*TRANCODE'
and those variables will be in the _VCICTRN macro if the
Hogan data is detected by UTILEXCL, but only the fields
actually created in your IMACICHO will exist in CICSTRAN.
Thanks to Scott Wiig, USBank, USA.
Change 22.168 Support for HMF V2.7 adds subtypes 26, 27, 28 creating
EXTYHMFP St dddddd Dataset Description
EXTYHMFQ 26 TYHMFP TYPEHMFP ULTRANET SNMP TRANSPORT STATS
EXTYHMFS 27 TYHMFQ TYPEHMFQ ULTRANET SNMP TRANSPORT STATS
VMACHMF 28 TYHMFS TYPEHMFS ULTRANET SNMP DECOMPRESSION
VMXGINIT Variables in TYPEHMFT TYPEHMFU stored in the original
Jul 7, 2004 named/labeled variables; both 29 and 30 subtypes have
fewer variables, but Change 21.143 did not handle that
revision correctly.
Thanks to Perry Lim, Union Bank of California, USA.
Change 22.167 Variable STATIND in TYPE77 is a one byte numberic flag
ADOC77 byte, but it should have been formatted as HEX2. The bit
VMAC77 descriptions in ADOC77 were incomplete and incorrect, and
Jul 8, 2004 bit 6 ON was not even documented by IBM, but the bits are
now correct. A value of 03 is normal, as it indicates
that bit 6 and bit 7 are on, i.e., you have a GRS=STAR
configuration.
Thanks to Rodger Foreman, Acxiom, USA.
Change 22.166 Support for STK ExHPDM user SMF record.
EXHPDM00 DDDDDD DATASET DESCRIPTION
EXHPDM01
EXHPDM02 HPDM00 HPDMAU00 AUDIT STARTUP/SHUTDOWN
EXHPDM03 HPDM01 HPDMAU01 AUDIT CLIENT REQUEST
EXHPDM04 HPDM02 HPDMAC02 AUDIT CONNECTION ACCOUNTING
TYPEHPDM HPDM03 HPDMPE03 AUDIT STREAM TASK PERFORMANCE
TYPSHPDM HPDM04 HPDMAU04 AUDIT DATABASE TRANSACTION
VMACHPDM -Problems in data:
VMXGINIT Variable SOV2DEVN, 'Device Definition Name' has '0E'x in
Jul 19, 2004 in first byte, then 7 blanks in subtype 2, but is text
'DEVICE3' in subtype 3 records.
Thanks to Al Holtz, MEDCO, USA.
Change 22.165 BUILDPDB now detects "overlapped" SMF data was read in.
BUILD005 If you read the same SMF file in two separate PDB runs,
BUIL3005 or if you rerun BUILDPDB to re-create a PDB library and
Jul 8, 2004 did not restore the SPIN library, there will be duplicate
Aug 25, 2004 observations in the SPIN30_1 dataset; MXG now detects the
Oct 28, 2004 duplicates, and prints ERROR. DUPLICATE TYPE 30 SUBTYPE 1
messages on the SAS log. I had considered ABENDing for
this condition, but in this implementation, only error
messages are printed.
-The symptom that detected this problem was a change in
the number of observations in PDB.SMFINTRV, and messages
NOTE: MERGE STATEMENT HAS MORE THAN ONE DATASET... for
the TYPE30_V interval dataset, because the SPIN30_1 data
is used to populate the ACCOUNTn variables in PDB.SMINTRV
dataset, even though no interval records are "spun".
-For any rerun of BUILDPDB, you must restore the //SPIN
library to contain what it did before that failed run;
BUILDPDB automatically backs up your SPIN datasets into
the PDB library, so all you need do is to go back to the
last successfully build PDB library and restore the SPIN:
// EXEC MXGSASV9
//PDB DD DSN=LAST.GOOD.PDB,DISP=SHR
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
//SYSIN DD *
PROC COPY IN=PDB OUT=SPIN;
SELECT SPIN: ;
and then you can rerun BUILDPDB with the SMF data that
failed; you may need to edit IMACZDAT to set the ZDATE
of the re-built PDB library, if you have skipped a day.
-Aug 25: Added restriction to only examine BAT/TSO/STC job
records with a JES Number. OMVS/USS creates multiple job
initiate records with the same READTIME/JOB/JINITIME and
a missing JESNR that erroneously caused the "duplicate"
MXG message.
-Oct 28: Corrected tests for BAT to JOB and TSO to TSU, as
those are the correct spelling of TYPETASK values. With
original spelling, only STC tasks were being examined.
And the CRITICAL ERROR. DUPLICATE TYPE 30 message now
shows where the overlapped records were found.
Thanks to Tim Gilchrist, Department of Defence, AUSTRALIA.
Thanks to Pat Curren, SuperValu Inc, USA.
Thanks to Udo Froehling, Signal-Iduna, GERMANY.
Change 22.164 The %VGETJESN invocation was moved after variable SYSTEM
VMACSFTA has been set. Initially, I saw no error in my tests, but
Jul 8, 2004 the PUT in VGETJESN for error conditions had a blank for
Aug 11, 2004 SYSTEM that was corrected by the relocation. However, I
now have test data that failed with error messages that
NOTE: INVALID NUMERIC DATA, STEPNAME='XXXX' that were
corrected by this change, so it all depends on which of
the SoftAudit files have data as to whether this change
is cosmetic, or required!
Thanks to Jim Kovarik, Aegon, USA.
Thanks to Ng Kin, Acxiom, USA.
Change 22.163 The SAS User SMF record does not contain enough data to
VMACSASU permit the use of the NODUP option in PROC SORT to safely
Jul 7, 2004 remove duplicates; NODUP removed 51,596 non-duplicates
from 2,687,811 SMF records. Using READTIME JOB SMFTIME
has only 10 milliseconds resolution, which is much larger
than the elapsed time of many SAS steps, especially the
repetitive SORTing of small datasets. A sequence number
of the proc/data step within the session is needed to be
able to safely remove duplicates, but for now, the NODUP
option was removed from the PROC SORT for TYPESASU, to
prevent the unwanted deletion of records that appear to
be duplicates, but aren't.
Thanks to MP Welch, SPRINT, USA.
Change 22.162 In TYPEBET0 dataset, new variable BETARETP, Retention
VMACBETA Period is now input as &PIB.4. where BETAEXPD was &PD4.,
VMACBE97 in VMACBETA, and in BETA974 dataset, variable B974XPDT is
Jul 7, 2004 input as &PD.4., as it is an expiration date.
Thanks to Ruben de Leeuwe, Independent Consultant, THE NETHERLANDS.
Change 22.161 Support for optional ESS segment GEPARMKY=003B creates
IMAC6ESS variable ESSITRAY (INTRAY) and GEPARMKY=0045 creates the
VMAC6 variable ESSPORNO (PORTNO) in TYPE6 when comment block
Jul 7, 2004 in member IMAC6ESS is opened.
Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY
Change 22.160 TYPETNG/TYPSTNG default array sizes, based on actual TNG
TYPETNG data from a large site, requires REGION=280M, but this
TYPSTNG caused INSUFFICIENT MEMORY errors in TESTOTHR step of the
JCLTEST8 JCLTESTn test job for sites that didn't even have TNG.
Jul 7, 2004 This change inserted %LET MAXROWS=1; so that only 20M
is required, but a site with real TNG data will need to
remove that statement, and may need 280M. However,
sites with TNG should read Change 21.269 which discusses
other MXG facilities for actual processing of TNG data.
Thanks to Pius Nwaobasi, IBM Global Services, USA.
Change 22.159 Variable SMF89LPI now always contains the correct LPAR ID
VMAC89 whether less than or greater than 15, and SMF89LP3 is no
Jul 5, 2004 longer kept, now that doc indicates what both contained.
Change 22.158 "Support" for JMF SMF 84 subtype 10, but only the header
EXTY84A variables are input; no one has actually ever requested
VMAC84 MXG to support this JES3-only SMF record, and I'd be very
VMXGINIT pleased if no one ever does.
Jul 5, 2004
Change 22.157 TYPE78IO new variable:
VMAC78 R783GFLG='IOQ*GLOBAL*FLAGS'
Jul 5, 2004
Change 22.156 TYPE73 new variables added by z/OS 1.5:
VMAC73 CHANDCMG='CHANNEL*PATH IS*DCM*MANAGED'
Jul 5, 2004 CHANCHCH='CHANNEL*PATH*CHARACTERISTICS*CHANGED'
Change 22.155 TYPE71 new variables added by z/OS 1.5:
VMAC71 SMF71PTH='AVG*TOTAL*SHARED*FRAMES*ABOVE 2GB BAR'
Jul 5, 2004 SMF71PCH='AVG*TOTAL*CSTORE*FRAMES*ABOVE 2GB BAR'
SMF71PAH='AVG*TOTAL*AUXSTORE*FRAMES*ABOVE 2GB BAR'
SMF71BLG='PEAK*SHARED*BYTES*LARGE*VIRTUAL'
SMF71PIH='PAGEINS*FROM AUXSTOR*FOR ABOVE*2GB BAR'
SMF71POH='PAGEOUTS*TO AUXSTOR*FOR ABOVE*2GB*BAR'
Change 22.154 TYPE1415 new variable created:
VMAC1415 SMF14EDI='EXTENDED*DATA*INTEGRITY*EDI*FLAG'
Jul 5, 2004 and FORMATed $HEX2.:
Bit Meaning
'1.......'B DSN found in EDI exclusion table
'.1......'B DSN being opened for out, already open in
'..1.....'B DSN being opened for in, already open out
'...1....'B application requested EDI be bypassed
Change 22.153 -TYPE6/PDB.PRINT variable SUBSYS='TCP ' is for PrintWay
VMAC6 basic mode records; SUBSYS='TCPE' is now set if the SMF 6
Jul 5, 2004 record is from PrintWay Extended mode records.
-New variables for PrintWay file transfer:
SMF6URI ='TARGET*UNIVERSAL*RESOUIRCE*INDICATOR*URI'
SMF6URIL='LENGTH*OF*URI'
SMF6FTL ='*FILE*TRANSFER*LEVEL*INDICATOR'
and SMF6BYTE is now input from PIB8 field.
Change 22.152 Support for IFA Processors, APAR OA05731.
FORMATS -TYPE70 dataset, new variables:
VMAC7072 IFAAVAIL='IFA Processor AVAILABLE?'
VMAC79 SMF70IFA='NUMBER OF*IFA PROCESSORS*ONLINE'
Jul 5, 2004 IFACROSS='IFA*CROSSOVER?'
Dec 12, 2005 IFAHONPR='IFA*HONOR*PRIORITY?'
-TYPE72GO dataset, new variables:
R723NFFI='*NORMALIZATION*FACTOR*FOR IFA*TIMES'
R723RCOD='CONTENTION*DELAY*SAMPLE*COUNT'
R723RCOU='CONTENTION*USING*SAMPLE*COUNT'
R723ECTC='CPU TIME*WHILE DP*RAISED'
R723IFAU='IFA*USING*SAMPLES'
R723IFEU='IFA-ELIGIBLE*ON CP*USING*SAMPLES'
R723IFAD='IFA*DELAY*SAMPLES'
R723IFAC='IFA*CPU TIME*ON IFA'
R723IFEC='IFA-ELIGIBLE*ON CP*CPU TIME'
-TYPE791 dataset, new variables:
R791TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs)
R791TCP ='CPU TIME*SPENT ON*STANDARD CPS'
R791TIFC='IFA-ELIGIBLE*CPU TIME*ON CP'
R791NFFI='NFFI*NORMALIZATION*FACTOR'
-TYPE792 dataset, new variables:
R792TIFA='IFA*CPU TIME*ON IFA' (normalized to CP secs)
R792TCP ='CPU TIME*SPENT ON*STANDARD CPS'
R792TIFC='IFA-ELIGIBLE*CPU TIME*ON CP'
R792NFFI='NFFI*NORMALIZATION*FACTOR'
Dec 12, 2005: TYPE791/TYPE792 variable names/labels now
match the actual variable names.
Change 22.151 Cosmetic, only labels were changed.
ADOC71 -CSLPFXAV/CSLPFXMN/CSLPFXMX contain only CSA FRAMES; back
VMAC71 in MVS/370 those variables contained the sum of CSA+LPA,
Jul 4, 2004 but ever since MVS/XA, they contain only the CSA Fixed
Frame counts, so LPA was removed from their Labels.
-Variables that had just "FRAMES" in their label now have
CSTORE*FRAMES if the area was CSTORE.
-Unfortunately, some variables in TYPE71 are in units of
byte-storage (and formatted MGBYTES to "print pretty"),
while these old variables still have counts of frames,
but there is no way to be consistent without destroying
your existing reports. Hindsight is wonderful, but can't
be applied now!
Thanks to Mayflor Dageforde, Blue Cross Blue Shield of Kansas, USA.
Change 22.150 The LPAR name variables for LPARs 16-32 were only one
VMXG70PR byte long; their initialization was corrected to eight
Jul 2, 2004 bytes to hold the full name.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.149 Enhancement to the UTILBLDP utility that "builds" a "PDB"
UTILBLDP (actually, builds the SYSIN code) for arbitrary combos of
Jul 1, 2004 SMF records:
- ZEROOBS= parameter supports subtypes, so datasets
built from specific SMF subtype can be created with
zero observations.
USERADD= 74,
ZEROOBS= 74.1 74.5,
creates TYPE74 and TYPE74CA with zero observations,
but all other TYPE74XX datasets will be populated.
- New MACFILEX= parameter allows insertion of code that
would normally be inserted with %LET MACFILE= ....;
UTILBLDP internally uses MACFILE=, so your MACFILE=
insert is ignored. Probably not needed, as the main
need for MACFILE= here was to suppress subtypes!
-See member JCLRMF
Thanks to Sue Castona, Rockwell, USA.
Change 22.148 With assistance from SAS developers, %VGETENG(DDNAME=XXX)
VGETENG returns the SAS Engine name (in macro variable &VGETENG)
VMXGENG and the Device Type (in macro variable &VGETDEV), if xxx
VMXGTAPE points to an existing SAS data library that was OPENed,
VMXGINIT and sometimes even if the library has not been opened.
Jul 6, 2004 The redesign also corrects these previous glitches:
Jul 20, 2004 - If the XXX pointed to a sequential format library,
on disk or on tape, the entire data library was read,
wasting CPU, I/O, and elapsed time.
- VMXGTAPE failed when the LIBNAME had not been opened.
-When a LIBNAME statement exists for XXX, VGETENG/VGETDEV
are always correct, whether XXX has been opened or not,
unless there is a LIBNAME (XXX or some other ddname) that
points to a non-existent data library on tape, i.e., a
DISP=NEW file that has not yet been written to.
The logic searches LIBNAMEs, and if an uncreated tape
DD is found (perhaps before your wanted XXX ddname) an
IEC145I 413-18 message is printed on SYSMSG and SASLOG
has an I/O ERROR HAS OCCCURRED message, and the search
is terminated (with a zero return code). If the XXX
ddname is the uncreated file, VGETENG will have the
Engine from LIBNAME XXX statement, but VGETDEV will
always be blank for an un-created file.
-If there is NO LIBNAME statement, the engine and device
are correct only if the DDNAME has been OPENED, but the
function does not fail; engine is UNKNOWN and device is
blanks for unopened or even uncreated ddnames, on tape or
on disk. Test %VMXGENG before using in production!
-If XXX accesses a REMOTE SAS/CONNECT file, the MVS device
type will be correct; on ASCII VGETDEV will be blank.
-The other %macros, VMXGENG and VMXGTAPE were revised with
the new logic, and return their original variables, but
they exist only for backwards compatibility, as MXG's
convention for %macros that "get" something is %VGETxxxx.
-VMXGINIT was updated to %GLOBAL macro variable VGETDEV.
LIBNAME Statement in SYSIN: YES NONE
VGETENG VGETDEV VGETENG VGETDEV
DISK
DISP=SHR/OLD REFERENCED CORRECT CORRECT CORRECT CORRECT
DISP=SHR/OLD NOT REFERENCED CORRECT CORRECT UNKNOWN BLANK
DISP=NEW CORRECT CORRECT UNKNOWN BLANK
TAPE
DISP=SHR/OLD REFERENCED CORRECT CORRECT CORRECT CORRECT
DISP=SHR/OLD NOT REFERENCED CORRECT CORRECT UNKNOWN BLANK
DISP=NEW CORRECT BLANK UNKNOWN BLANK
The 413-18 ONLY occurs when there is a LIBNAME, the
device is TAPE, and the DDNAME has not been referenced.
Thanks to Lewis King, SAS Institute Cary, USA.
Thanks to Rick Langston, SAS Institute Cary, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Diane Eppestine, SBC, USA.
Change 22.147 Performance enhancements to reduce I/O and CPU time, by
ASUM42DS eliminating second pass of TYPE42DS, which was input to
Jun 30, 2004 VMXGSUM and then input again to ANALCNCR. The redesign
builds a View to create input to ANALCNCR at the same
time the data is being read into VMXGSUM. New SAS NOTES:
DATA STEP VIEW SAVED ON FILE WORK.SUM142DS
DATA STEP VIEW SAVED ON FILE WORK.MXGSUM1
THERE WERE x OBS READ FROM DATASET WORK.TYPE42DS
THE DATASET WORK.CNCR42DS HAS Y OBS AND 4 VARIABLES
COMPRESSING ....
MISSING VALUES ....
THE VIEW WORK.MXGSUM1.VIEW USED THE FOLLOWING RESOURCES
are printed on the log. The savings?
Resource Before After Redesign
EXCPs 1.8 Million 760K
CPU time 78 minutes 46 minutes
Elapsed 236 minutes 135 minutes
Thanks to Chuck Hopf, MBNA, USA.
Change 22.146 Most variables in the TYP119nn datasets, except for the
VMAC119 STARTIME and SMFTIME, were on the GMT clock, but all of
Jun 29, 2004 the internal variables are corrected to local time zone.
Thanks to Robert Sample, Atlanta Journal Constitution, USA.
Change 22.145 -TYPETCPC and TYPETCPF FTP Client/Server in SMF 118 record
VMACTCP has GMT time in TOD variables FTPSTART and FTPEND; they
Jun 29, 2004 are now corrected to local time zone.
-Variable ELAPSTM is added to TYPETCPC/TYPETCPF datasets.
-Without this change, ANALTCP reports sometimes had wrong
TOD and zero duration because of the GMT time issue. No
change was needed in the ANALTCP code.
Thanks to Robert Sample, Atlanta Journal Constitution, USA.
Change 22.144 DB2 Trace IFCID 140 variable QW0140RC, Return Code from
FORMATS Access Control Exit has legitimate negative value of -1
VMAC102 if the Exit was not called, so the input was changed to
Jun 29, 2004 IB instead of PIB; additionally, new format MGD140R is
created to decode all of the return codes. Also, the
QW0140RS, a four-byte reason code is HEX8. formatted.
-Additional new values for format MGD140P for V7 and V8
are added.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 22.143 An example that reads only RMF SMF records to create an
JCLRMF "RMF-only" PDB library, including PDB.RMFINTRV, and the
Jun 29, 2004 PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC summary data.
The default example skips the RMF 74 subtypes 1 and 5,
so that PDB.TYPE74 and PDB.TYPE74CA datasets will have
zero obs (i.e., they take no disk space).
This example uses the enhancement in Change 22.149.
Thanks to Sue Castona, Rockwell, USA.
Change 22.142 Support for Thruput Manager SMF record VARNAME/TOKENID of
VMACTPMX INNODE/16448, JBSBIND/50240, JVLVOL/57920, REQCLA/58082
Jun 28, 2004 was added to the CARDS; section; these VARNAMEs had only
blank values for TOKENID, but had existing variables.
Thanks to Kasandra Natzke, Information Resources, Inc, USA.
Change 22.141 Support for RMF 74 subtype 8 ESS LINK STATISTICS record,
FORMATS added by APAR OA04877, creates new dataset TYPE748 with
EXTY748 counts of I/O operations, Bytes Read/Written, and Active
VMAC74 Time for ECKD, PPRC, and SCSI devices. Also, TYPE74CA
Jun 28, 2004 dataset has Bytes Read/Written, and Time to Read/Write.
The APAR adds the fields to the 74-5 and 74-8 records,
but the new data is only populated if the ESS D/T 2105
device has micro code version 2.3.0.455 (Sand) or higher.
Thanks to Willy Iven, Fortis Bank, BELGIUM.
Change 22.140 ERROR: BY VARIABLES NOT SORTED FOR DATASET WORK.SPIN30TD
BUILD005 because Change 22.052 did not add STEPNR in all places
BUIL3005 where it was needed (CVRT30TD and SPIN30TD); fortunately,
Jun 25, 2004 the exposure only occurs if two adjacent steps have the
same INITTIME, and all sorts are now protectd.
Thanks to Rich Lopez, Johnson and Johnson, USA.
Change 22.139 The CICS ID variables in PDB.ASUMUOW: APPLID,USER,LUNAME,
UTILUOWC SYSTEM,TERMINAL, and USERCHAR were incorrectly kept from
VMXGUOW the LAST transaction segment, but should have been kept
VMXGUOWT from the FIRST transaction segment. The sort order was
Jun 29, 2004 was changed in Change 21.220, from descending ENDTIME to
ascending STRTTIME to recognize the TOR transaction as
the first transaction within the UOW, but the logic to
store those ID variables was not changed.
-LISTALL= argument, primarily for debugging, can now be
used to add any of the FRSTxxxx, LASTxxxx, and HOLDxxxx
variables to the PDB.ASUMUOW dataset.
-New UTILUOWC member can be used to examine the CICSTRAN
observations that made up a Unit-of-Work, for debugging.
-Oct 2, 2020: Revised UTILUOW replaces UTILUOWC.
Thanks to Carla Fleming, King County, USA.
Thanks to Sydney Cheung, King County, USA.
Change 22.138 The original ANAL4GBO member uses the SMF TYPE64 records
ANAL4GB to identify VSAM files that are approaching the 4GB size
ANAL4GBO limit, but that only saw VSAM files that were opened in
Jun 25, 2004 the SMF file that was read. This revision uses the
DCOLCLUS dataset, created from IBM's DCOLLECT option of
IDCAMS (JCL example in JCLDAYDS) so that all VSAM files
can be examined for their size.
- Using TYPE64, the HIGHALLOC was 3354M from TYPE64, but
LISTCAT showed only 1234M, because it was run at a
later time, and that VSAM file was defined as reusable
and an RST was specified on the ACB at OPEN, so it was
reset to empty before the LISTCAT was run.
Thus both members may be useful in tracking VSAM size.
Thanks to Dennis Cole, Commerce Bank NJ, USA.
Change 22.137 Support for z890 new CPUTYPE='2086'x, REQUIRED ONLY for
FORMATS OS/390 R2.10; MXG does not error with data from z890s,
VMAC7072 but without this change, MSU-containing variables will be
VMXGRMFI missing if you are still running your z890 under OS/390.
Jun 28, 2004 -The '2084x CPUTYPE tests added to support the z990 CPU
in Changes 21.141, 21.149, and 21.216 are expanded to now
also test for the '2086'x CPUTYPE of the z890.
-The table of "MSU" values in MG070CP format are updated
with IBM announced Software Pricing MSU for the z890,
which will eliminate the "CPUTYPE NOT IN TABLE" messages.
Thanks to Ed May, Western Power, AUSTRALIA.
Thanks to Al Sherkow, I/S Management Strategies, Ltd, USA.
Change 22.136 The SMF Exit code to put Initiator Name and Init Number
IEFU84 if the PROGRAM field in the SMF 30 subtype 1 record that
Jun 24, 2004 was announced in Change 19.269 now exists in the member
IEFU84, which is the JOB to assemble that SMF exit. Your
System Programmer will need to install the exit for you,
as it must be placed in an authorized load library, and
he/she will want to examine this SMF exit code.
MXG member VMAC30 already has the code in place and will
now populate the variables INITNAME and INITNUM after you
have installed the IEFU84 exit to add the data to SMF 30.
But note that only "real" initiators have names/numbers;
WLM-managed initiators will have blank initname and no
value for initiator number.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 22.135 The "MVS" SYSTEM NAME of each LPAR, SMF70STN, is added to
VMXG70PR datasets ASUM70PR and ASUMCEC as variables LP0STN-LPXSTN,
Jun 24, 2004 and in dataset ASUM70LP as SMF70STN.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.134 The percentage of DURATM when each of the 32 CPU engines
VMAC7072 was online is added in variables PCTONLN0-PCTONLNX in the
Jun 24, 2004 TYPE70 dataset.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.133 -Support for additional NDM-CDI Connect Direct subtypes:
VMACNDM FA,FI,GO,IF,NL,PI,SY,TP,TR,UU,WS,ZI
Jun 23, 2004 -Exit members EXNDMEV,EXNDMSB,EXNDMWS were deleted, as
those subtypes are now output into existing datasets.
-Comments in VMACNDM identify all known subtypes, those
that have known DSECTS, and those for which I have had
test data; if you have observations created in any of the
datasets identified as "NO DSECT", contact support@mxg.
Thanks to Jim Petersen, Washington Mutual, USA.
Thanks to Stuart Hubbard, Washington Mutual, USA.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 22.132 This example for detail trace of the events in the life
ANALJOBE of a JOB did not keep CPUTM, had MULTIDD mispelled, did
VMACSYNC not use MACJBCK to select specific jobs whose events are
Jun 25, 2004 to be tracked, and deleted some 14/15 records for some
long-running jobs.
Change 22.131 NETSPY now writes both TYPENSPY and TYPENETM subtypes in
VMACNSPY one SMF ID, which caused messages ERROR.VMACNSPY.1 with
Jun 22, 2004 NSPYENTL=54754 and NSPYOFF=1539954642 in the text. This
change merges the VMACNETM code into the VMACNSPY code so
that NETSPY records (all of which have alpha subtypes)
and NETMASTER (which have two-byte hex subtype) are now
processed with the single TYPENSPY/VMACNSPY member to
creates all NSPY and NETM datasets. This change requires
MXG 22.01+, because of the new EXNETM50 and the revised
VMXGINIT members added by Change 22.037.
-While TYPENETM will still decode NETMASTER records, it is
now archaic, since TYPENSPY creates both NETMASTER and
NETSPY datasets.
-Change 22.243 is required; it corrected this change.
Thanks to Susan Fassette, Erie Insurance Group, USA.
Change 22.130 The "W0" in DSNAMEs in SAS V9 is only part of new naming
MXGSASV9 conventions, many of which are documented in the section
Jun 15, 2004 "Languages, Encodings, and Installation Codes" in the SAS
Aug 24, 2004 "Installation Instructions for SAS 9.1.2 Foundation for
z/OS" manual. The DSNAME and MEMBER names created depend
on the two NLS/LOCALE options for your country, the "XX"
Language Value and the "YY" Encode Value. Some DSNAMES
use XXYY, some member names end in YY, and both SASHELP
and SASMSG have ENYY in their DSNAME for the help and the
messages that have not been translated into local. For
example, "ENW0" for English in US, "DEW3" for most GERMAN
languages, but "DEWB" for GERMAN in Switzerland.
-To support this SAS change, the MXGSASV9 JCL procedure
example has two new symbolic parameters, &XX and &YY with
&XX=EN and &YY=WO as their default values, and you can
see in that JCL where the XX and where the YY is used to
form part of the DSNAME or MEMBER names.
-New DD statements added in V9 are also added in the JCL
example: TRNSHLP, ENCDHLP, and TMKVSENV.
Thanks to Bernd Klawa, Stat Bielefeld, GERMANY.
====== Changes thru 22.129 were in MXG 22.06 dated Jun 14, 2004=========
Change 22.129 "MVS" SAS only, I think! In SAS V9, the NLSCOMPATMODE
CONFIGV9 option was changed to default to NONLSCOMPATMODE, which
Jun 15, 2004 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.
Jan 2012: See Change 27.356, which shows how to use the
CONFIMXG and // EXEC SAS and //MXGNAMES to use the site's
default SAS JCL and removes the NLSCOMPATMODE option.
Thanks to Bernd Klawa, Stat Bielefeld, GERMANY.
Change 22.128 New BLDIMPDB is "JCL" for ASCII platforms, for STEP03/04
BLDIMPDB of the JCLIMSLx/ASMIMSLx IMS log processing on ASCII SAS
TYPEIMSB platforms; BLDIMPDB provides the filename statements with
Jun 14, 2004 correct DCB attributes that are used after STEP01/STEP02
(which do not require SAS) were executed on "MVS".
-Member TYPEIMSB had to be changed to process character
fields containing hex data as $CHAR rather than $EBCDIC,
logic was added to convert text fields back to EBCDIC.
Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.127 The example in comments to read SMF data (instead of PDB)
ANALFIOE was enhanced to create only the datasets, and keep only
Jun 14, 2004 the variables that are required, reducing run time and
DASD space. This is not needed if you run ANALFIOE with
BUILDPDB, since the PDB has all of the needed datasets
to analyze concurrent FICON Open Exchanges.
Thanks to Neil Ervin, Charles Schwab, Inc, USA.
Change 22.126 The "WO" must be "W0", i.e., w-zero not w-oh in the DSNs
MXGSASV9 and member names in the JCL example.
Jun 11, 2004
Thanks to Robert Chavez, Office Depot, USA.
Change 22.125 Support for Mobius/IPAC subtype 5 IPAC05 dataset duration
VMACIPAC variables were incorrectly input, but nobody had noticed,
Jun 9, 2004 until now. Version 6.2 data has been validated.
Thanks to Marty Wertheim, Bank of America, USA.
Change 22.124 MXG 22.04-MXG 22.05, QWHSSTCK was missing in SMF 102 DB2
VMACDB2H trace records after Change 22.090; the reset for ID=101
Jun 9, 2004 statement should have also have reset ID=102.
Thanks to David M. Forbes, McLeodUSA, USA.
Change 22.123 SAS Version 9 INCOMPATIBILITY, on "MVS" only, CRITICAL:
CONFIGV9 The MXG default value for the SAS system option S2=
UTILS2ER (it sets the line size of source statements that will
MXGSASV9 be read from %INCLUDE and AUTOCALL members),
Jun 8, 2004 which is set in the MXG CONFIGV9 member,
Jun 12, 2004 MUST now be changed for MVS from the MXG default of S2=72
(which was chosen so that SAS only read columns 1-72,
and prevented errors when user-written code had mixed
blank and non-blank lines, or had invalid line numbers
in columns 73-80. Only user-written code members had
the exposure, since all of MXG fits in 72 positions),
to be S2=0, because:
- MVS SASMACRO library was changed from RECFM=FB to VB.
There are no standards for line size of SAS-provided
%macros; previous MVS-used %macros fit in RECFM=FB, but
new V9 macros now have line sizes up to 255 positions.
These new macros were created on ASCII platforms,
where all text files are variable length, with 255
default length (which SAS handled because it treats
variable length input and fixed length differently),
so the coders (with no legacy background) had no
reason to restrict their code to the 72 bytes that
we had found necessary on MVS systems, and they did
all of their testing on ASCII platforms.
If they had known of the restriction, their macros
could easily have been written to fit, this change
wouldn't have been necessary, so you could have
read their source code, to understand and learn,
without line wrapping on green screen terminals!
- So the MVS folks had to change RECFM from FB to VB to
deliver these long-length %macros, and since the real
SAS System default is S2=0, the MVS QA tests did not
see any of the errors that their change causes when the
S2 option is set to S2=72.
- And, unfortunately, while MXG programs do use some of
the SAS-provided %macros (%LOWCASE,%LEFT,%CMPRES,%TRIM)
the utilities that use them (UTILBLDP,BLDSMPDB) weren't
executed with the arguments that happen to invoke them
in our QA, so we missed this V9 problem in our testing.
- The SAS Change to RECFM=VB with the MXG S2=72 default
has caused real errors, and has the potential for more:
- With VB and S2=72, real errors occurred:
A site that had always put their own local %macros
in the SASMACRO FB library in previous SAS versions
got "macro not found" errors when they copied their
%macros into the VB file, and executed with S2=72,
because SAS started reading in column 73, and never
saw their %macro definition. SAS Technical Support
recommended they change S2=0, SAS Note SN-011929,
which did correct this error.
An alternative to putting user %macros in the
SAS-supplied library is to put them in the MXG
"USERID" tailoring source library, because MXG
uses MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS)
precisely so that %macros will be found.
- But with VB and S2=0, potential errors may be worse:
Since MXG has always set S2=72, any text in your own
source code in columns 73-80 was ignored, but now,
if you have a member with invalid line numbers in
columns 73-80 (mixed numbers and characters; some
vendors use 73-76 for a line number and put version
characters in 77-80), or if you have a member with
unnumbered first line and numbers in later lines,
your perfectly running job now will fail under V9
(with a 180 syntax error, at the non-blank line),
and the defective numbering will not be identified.
That member must be either all unnumbered or all
lines must be numbered to eliminate this error.
MXG set S2=72 to protect users from the very common
human error we found in MVS systems, when a user
EDITed a new line with blank number into a member
that was already numbered, but now, you must detect
and correct those members so that S2=0 can be used.
- But since CONFIGV9 must now specify S2=0 to prevent the
real errors encountered, those potential errors due to
"bad" line numbers MUST be detected and corrected prior
to migration to V9. The new UTILS2ER program MUST be
run against each of your Source PDS libraries that have
SAS code; it will identify all members with "bad" line
numbers, so that you can EDIT those members and avoid
the potential errors caused by changing S2=72 to S2=0,
prior to migrating to SAS Version 9 on "MVS".
- Tutorial on S2 option values:
- The S2=72 option has completely different meanings for
RECFM=VB than for RECFM=FB:
-For FB, S2=72 says to only read the first 72 positions
-For VB, S2=72 says to skip the first 72 positions and
start reading in column 73!
- The S2=0 option is also different, for the two RECFMs:
-For FB, the last 8 columns of the first line of each
member is read; if that first line does not have a
valid sequence number, SAS reads the full LRECL of the
source line. If that first line has a valid sequence
number, SAS reads all but the last 8 columns of that
member's lines.
-For VB, columns 1-8 of the first line of each member
is read, and if a valid line number is found, SAS then
internally uses S2=8 to start reading in column 9.
If there is no line number in columns 1-8, SAS then
internally uses S2=0 to read the entire line length.
- Fortunately, SAS separately opens each member, so with
S2=0 and either FB or VB, SAS examines each member for
line numbers, so you can have one member without line
numbers, and another member with line numbers, even in
the same PDS, without any error; it is only when you
have invalid line numbers, or have a blank line before
a numbered line, that the 180 syntax error will happen.
Note that MXG did NOT change the S=72 default value:
- S controls SAS action on code read in from //SYSIN
- S2 controls SAS action on code read by %INCLUDE or
by SASAUTOS)
because you want that protection: it is very common to
have mixed numbered and unnumberd lines in your members
that have both the JCL and the SAS code, that you EDIT
and SUBMIT, and using S=72 allows that inconsistency,
so your job will continue to run without errors.
Summary of changes:
-CONFIGV9 now specifies S2=0 instead of S2=72.
-UTILS2ER is a new program to find S2=0 bad lines.
-MXGSASV8/V9 has //INSTREAM with SPACE=(CYL,(1,20))
instead of CYL,(1,1), which could only hold 168,000
lines of source for UTILS2ER. With (1,20) that temp
file has room for 3 million lines from each PDS.
Thanks to Michael L. Kynch, International Paper, USA.
Change 22.122 Cosmetic. Error messages were made consistent, with both
VMAC28 SYSTEM and SMFTIME printed with all errors.
Jun 8, 2004
Thanks to Pascal Maurice-Prestataire, La Poste, FRANCE.
Change 22.121 See the extensive discussion of DB2 Parallel Transactions
VMACDB2 (and the significant loss of DB2TCBTM if you have any)
EXDB2ACC in the "DB2 Technical Notes, Newsletter FORTY-FIVE).
EXDB2ACB -This old code in the MXG exit members EXDB2ACC/ACP/ACB:
EXDB2ACP IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;
Jun 6, 2004 was removed by this change, and should be removed from
your exits. It was added by Change 20.266 to resolve a
problem with duplicate records, but the new DB2PARTY='R'
value is set when QWACPARR='Y', so the DELETE could never
have been executed.
-New value 'R' for the RollUp record, and value 'P' is now
for the Parallel Task (or Utility Subtask):
DB2PARTY Description Set by
'R' Rollup QWACPARR EQ 'Y'
'P' Parallel QWACPACE GT 00000000X
'O' Parent/Orig QWACPCNT GT 0, QXMAXDEG GT 0
'S' Sequential None of the above
-The code to set DBPARTY was relocated, and the test for
'O' is now set IF QWACPCNT GT 0 OR QXMAXDEG GT 0, which
is a stronger test for the Parent/Originating record.
Without this change, DB2PARTY was "S" for the Parent.
-In DB2PARTY='R' Rollup records QWACESC is not a datetime
value, but as noted in IBM APAR PQ41012, it contains the
total elapsed time for all child tasks, a duration. MXG
now detects when QWACESC is smaller than QWACBSC, (or if
QWACESC or QWACBSC are zero) and for those observations:
MXG stores the "QWACESC" time in variable CHIELPTM.
MXG creates QWACESC as datetime, equal to QWHSSTCK.
QWACBSC may be zero
ELAPSTM is set to missing
For all other observations, CHIELPTM will be missing,
and ELAPSTM=QWACESC-QWACBSC.
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
Thanks to Andy Schuermann, Department of Defence, AUSTRALIA.
Change 22.120 MXG 22.05, MVS only, using UTILBLDP, you will get error:
CONFIGV8 APPARENT INVOCATION OF MACRO CMPRES NOT RESOLVED and
CONFIGV9 APPARENT INVOCATION OF MACRO LEFT NOT RESOLVED because
Jun 4, 2004 during tests for Change 22.102, I had mis-understood SAS
techs to say that the %LOWCASE and other %MACROS had been
implemented in base SAS, and that SASAUTOS was no longer
required, so I had changed SASAUTOS=SOURCLIB in testing,
but found it was only the function LOWCASE and not the
%macro %lowcase that had been implemented; unfortunately
I failed to go back and correct the SASAUTOS= statements
in those CONFIGVn members. The correct statement is
SASAUTOS=(SOURCLIB SASAUTOS)
which has always been required in CONFIGxx and AUTOEXEx
to retrieve the SAS-provided %macros that are not defined
in base SAS: %LOWCASE, %CMPRES, %LEFT, and %TRIM.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.119 Cosmetic: Four of the BY statements in the _CHAIN macro
VMACCIMS were replaced by _BIMFTRN, since that "BY" macro had the
Jun 3, 2004 same variables as the replaced BY statements.
Thanks to Joe Babcock, Bank One, USA.
Change 22.118 Cosmetic: Semi-colons at the end of some MACRO _BTY91xx
VMAC91 were removed, to be consistent with other definitions.
Jun 3, 2004
Thanks to Joe Babcock, Bank One, USA.
Change 22.117 Support for optional ESS segment GEPARMKY=003B creates
IMAC6ESS variable ESSFRMLN (FORMLEN) in dataset TYPE6, when the
VMAC6 comment block in member IMAC6ESS is opened.
Jun 3, 2004
Thanks to Engelbert Smets, Provinzial Rheinland Versich., GERMANY
Change 22.116 Variables SMF70NSI SMF70NSA SMF70NSW were incorrectly
VMAC7072 divided by NRSAMPLE, which is ten times greater than the
Jun 3, 2004 SMF70DSA that should have been used.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.115 JES3 only. The BUILDPD3 program could use the wrong type
BUIL3005 26 purge record, which caused ABEND='JCL' for jobs that
Jun 2, 2004 had actually executed, especially for jobs that were read
in on one system and sent to a second system via NJE for
execution, because the first TYPE26J3 observation was the
one used. This revision uses the SYSEXEC field, which is
non-blank only in the "execution" purge record; all other
purge records are output in dataset PDB.DJEPURGE prior to
the logic that matches the purge record with the other
job records.
-The READTIME value can be different in the purge record
that was written for the job's output processing which
occurred on the original node. The first two 26 records
(one on the read-in system, one on the execution-system)
but the third 26 record had a READTIME that was after the
purge time of the execution purge record. As this was a
non-execution purge record, it is output in PDB.DJEPURGE,
but searching for it by READTIME would not find the obs.
Thanks to Ray C. Lau, Nav-International, USA.
Thanks to Roger Rush, Nav-International, USA.
Change 22.114 This VTS Library Statistics report replicated the IBM
ANAL94 report, but IBM uses the SMFTIME (end) rather than the
Jun 1, 2004 STARTIME (begin) of the interval, so, to match their
report, SMFTIME is now used, and the REPORT TITLE has
been modified to indicate it the end of the interval.
Thanks to Cheri Sample, Ford Motor Car Company, USA.
Change 22.113 ASCII execution only, using ASMIMSLx/JCLIMSLx steps 3 & 4
TYPEIMSA on PC, variable APPLID was unreadable because it was not
May 27, 2004 converted back to EBCDIC. APPLID=SUBSTR(DTOKEN,1,4); was
replaced by APPLID=INPUT(SUBSTR(DTOKEN,1,4),$EBCDIC4.);
Thanks to Mark Van Der Eynden, Hewlett-Packard Australia, AUSTRALIA.
Change 22.112 INPUT STATEMENT EXCEEDED if MVRECLEV EQ '02'X but you did
VMACEDGS see the circumvention in the comments to change the 58 in
May 26, 2004 _SKPEDGS to 122, because the INPUTs for MVAUTID1-8 were
not compared with their length. However, this error is
now eliminated, as logic now tests MVRECLEV and sets the
value to either +58 or +122 automagically.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.111 Durn unix, and it's case sensitivity: these two members
BLDSMPDB must be all lower case, and all of the %UPCASE functions
BLDNTPDB must be changed to %LOWCASE, and when you type in the
May 26, 2004 %bldsmpdb(....) or %bldntpdb(....) those text lines
must also be typed in lower case.
-References to &SYSSCP were changed to &OPSYS, because
&SYSSCP is a SAS-owned macro variable that cannot be
%LOWCASEd, but &OPSYS is set in VMXGINIT and can be.
Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.110 The label for R744STSA was reversed; it is now
VMAC74 R744SSTA='REQUESTS*CHANGED FROM*SYNC TO ASYNC'
May 25, 2004
Thanks to Thom Kight, Fidelity Systems, USA.
Change 22.109 -DB2 data written to GTF and read with TYPE102G caused
ANALDB2R INVALID DO LOOP CONTROL INFORMATION error.
ANALDBTR because some IFCID 070 and 071 Trace Records contain only
VMAC102 a product section; MXG expected a second section with the
VMACDB2H QW0070 and QW0071 DSECTs, as described in DSNDQW01. The
VMACSMF two IFCIDs now only INPUT the second if QWHSNSDA GE 2.
May 30, 2004 When QWHSNSDA=1, T102S070/T102S071 dataset will have
missing values for the variables from those DSECTS, i.e.,
QW0070FR/CK or QW0071RT/RS/NI/FR will have missing value.
-Additionally, these two IFCIDs have only the Standard DB2
Header and the CPU Header in their Product Section. the
Correlation Header does not exist, so the QWHCCN QWHCCV
and all QWHC variables are missing in T102S070/T102S071.
-The _GTFDB2 macro in VMACSMF was corrected to run under
ASCII SAS; $EBCDIC was changed to $CHAR and $HEX format
was added.
-The _GTFDB2 macro did not store TODSTAMP into QWHSSTCK,
so the use of GTF data for ANALDBTR to create "PAIRS"
datasets, and/or the use oF PMSQLnn reports in ANALDB2R
did not work, causing blanks for Interval Start, etc.
-ANALDBTR did not include _114PAIR in ALLPAIRS macro,
causing S114S115/S114S116 DATA SET NOT FOUND errors in
ANALDB2R.
-ANALDB2R had misspelling of QW006PG vice QW0006PG, and an
incorrect &TRACEIN..S183S183 that is now just S183183; it
had caused a DATASET PDB.S183S183 not found error.
Thanks to Wayne Montefiore, CSC GIS Engineering Services, AUSTRALIA.
====== Changes thru 22.108 were in MXG 22.05 dated May 22, 2004=========
Change 22.108 CRITICAL for SAS V9.1, if you did NOT install CRITICAL
CONFIGV9 SAS Hot Fix in SN-012437 for V9.1 and for V9.1.2:
VMAC110 Summary: -SAS V9.1, using V7SEQ,V8SEQ,or V9SEQ, creates
VMAC120 corrupted and un-readable datasets, with no
VMAC80A error messages until you try to read the data,
VMACOMDB and the data is NOT recoverable; it's lost!
VMACSMSX See the FLASH posted May 21 to MXG-L/ITSV-L,
VMACTMTC or see FLASH in Newsletters at www.mxg.com.
May 22, 2004 -SAS V9.1, using V6SEQ, creates valid datasets
that have no errors, but if a dataset has any
long-length variables (greater than 200 bytes),
the copy/write caused error messages, and you
could not copy/write that dataset.
-SAS 9.1.3 has corrected all known errors and
V9SEQ can be safely used; however, CONFIGV9
still has V6SEQ, because I cannot tell that you
are running under SAS V9.1.3.
-Under SAS V8.2, V8SEQ creates valid datasets,
and supports "long length" variables; the error
only occurs under SAS V9.1, without hot fix.
This revision shortens all "long-length" variables in
datasets from MVS data, so that SEQENGINE=V6SEQ can be
safely used without errors; and the change reinstates
the SEQENGINE=V6SEQ in the CONFIGV9 member.
There is now another CRITICAL change to CONFIGV9 that is
also required for SAS V9, in Change 22.123.
These SMF variables were reduced to $200 bytes length,
(and it is extremely unlikely that your MVS data has
and text longer than 200 bytes in these fields):
SMF TYPE Dataset Variable Orig length
80 TYPE80EK EKC80FRD 1024
80 TYPE8XEK EKC80FRD 1024
110 CICSJR SJRPRPTH 255
110 CICPGR PGRJVCLS 255
120 TYP120JI SM120JI7 400
120 TYP120WA SM120WAL 400
120 TYP120WA SM120WAQ 400
120 TYP120WI SM120WIQ 400
120 TYP120WI SM120WIW 400
USER SMSX IGDACSSC ACEROJFL 256
USER SMSX IGDACSSC ACEROMFL 256
USER SMSX IGDACSSC ACEROSFL 256
USER TMTC TMTCIS ISCONTCT 256
USER TMTC TMTCIS ISDESCR 256
USER TMTC TMTCIS ISLOC 256
USER TMTC TMTCIS ISNAME 256
USER TMTC TMTCIS ISOBJID 256
These MVS-but-not-SMF variables were reduced to $200,
(and data loss here is also unlikely):
Product Dataset Variable
Candle OMDB DB0035 QMDAASTR 247
Candle OMDB DB0630 QW0063ST 5000
Candle OMDB DB1920 QW0192DT 250
Candle OMDB DB2060 QW0206MR 256
Candle OMDB DB2060 QW0206MS 256
Candle OMDB DB2080 QW0208MR 256
Candle OMDB DB2080 QW0208MS 256
Candle OMDB DB2360 QW0236MR 256
Candle OMDB DB2360 QW0236MS 256
Candle OMDB DB2571 QW0257MS 256
Candle OMDB DB3120 QW0312PR 250
Candle OMDB DB3140 QW0314PL 256
Candle OMDB DB3190 QW0319D1 256
Candle OMDB DB3240 QW0324CP 254
Candle OMDB DB3270 QW0327MS 256
And what's at least "slick" about this change:
If you need the extra characters in these variables,
once you have installed the Hot Fix, you can increase
them back to their maximum length just by inserting a
LENGTH var1 var2 ... varn $256 ;
statement in one EXdddddd member for each product!
MXG code still INPUTs the original long length, but
this change inserted a LENGTH varx $200; statement
in the VMACxxxx member, but SAS uses the LAST
LENGTH statement, and the EXdddddd member's code
will then change the stored length of the variable.
But not all variables over 200 bytes were changed:
- These variables created by TYPEWWW from Web Logs were
unchanged; that code is normally run on ASCII SAS,
which does not use the SEQENGINE option, and
Dataset Variable LENGTH
WWWIIS BROWSER URISTEM 256
" COMPNAME CSBYTES CSHOST 4096
" CSVERSN PORT SCBYTES 4096
" SITENAME STATUS32 URIQUERY 4096
WWWLOG BROWSER URISTEM 256
WWWLOG URIQUERY 4096
WWWREFER REFERER 4096
WWWURQRY URIQVALU 4096
WWWCOOKE COOKVALU 4096
- These variables are ONLY longer that 100 bytes if the
COMPRESS=YES option is enabled, none of the datasets
are likely to be created in BUILDPDB nor archived,
especially the T102Snnn DB2 trace datasets that are
usually created only for ad hoc analysis. And all of
these variables can be changed by inserting
%LET SASCHRLN=100;
or
OPTIONS COMPRESS=NO;
as your first //SYSIN statement:
Dataset Variable LENGTH
T102S004 QW0004MS 32000
T102S005 QW0005MS 32000
T102S059 QW0059CN 32000
T102S061 QW0061CN 32000
T102S062 QW0062ON 32000
T102S063 QW0063ST 32000
T102S064 QW0064CN 32000
T102S065 QW0065CN 32000
T102S066 QW0066CN 32000
T102S090 QW0090CT 32000
T102S092 QW0092P1 32000
T102S097 QW0097P1 32000
T102S124 QW01242T 32000
T102S140 QW0140TX 32000
T102S141 QW0141TX 32000
T102S145 QW0145TX 32000
T102S168 QW0168ST 32000
T102S180 QW0180DS 32000
T102S194 QW0194DS 32000
T102S203 QW0203PA 32000
T102S204 QW0204TH 32000
T102S206 QW0206MR QW0206MS 32000
T102S207 QW0207HR 32000
T102S208 QW0208MR QW0208MS 32000
T102S236 QW0236MR QW0236MS 32000
T102T124 QW01242T 32000
T102T140 QW0140TX 32000
T102T141 QW0141TX 32000
T102T145 QW0145TX 32000
TMDBBD QW0140TX 32000
TMDBBD0 QW0140TX 32000
SHADOW06 SM06SQSR 32000
Note: Jan 11, 2011. Change 28.325 updated this list.
Thanks to Diane Parker, AmerisourceBergen Corp, USA
Change 22.107 Formats MGTMDRC for ASG/TMON DB2 and MGDB2RC for IBM DB2
FORMATS slightly out of sync, but now match.
May 22, 2004
Thanks to Chuck Hopf, MBNA, USA.
Change 22.106 Variables EDSDSMEM, EDSESMEM, EDTDSMEM, EDTESMEM were not
VMACENDV correctly input.
May 22, 2004
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 22.105 MXG 22.04 ONLY. If there were no optional CICS segments,
UTILEXCL the IMACEXCL created by UTILEXCL failed with ERROR 22-322
May 22, 2004 on this statement: STRTTIME=STRTTIME+MCTMNTAD-MCTMNLSO;
The error was due to a mislocated comment symbol after
the LASTCHEK: label around a debugging PUT statement.
-ZDATE protected if _RPTEXCL run against PDB.CICSDICT that
had been created by an old UTILEXCL prior to ZDATE keep.
Thanks to George Waselus, Arizona State Department of Admin, USA.
Thanks to Noel D'Sousa, CSC, AUSTRALIA.
Thanks to Helmut Roese, Com-Software, GERMANY.
Change 22.104 Support for Candle Omegamon II for DB2 IFCID Trace data
TYPE102C that is written to a sequential file. Use the file name
VMAC102 //CANDB2 to point to their file, and %INC the TYPE102C
VMACSMF program to create obs for all IFCIDs in the file.
May 20, 2004
Thanks to Joseph Pugh, Fujitsu, ENGLAND.
Change 22.103 Cosmetic. Example had lines 648 and 652 the same; the
DOCPDB second MACRO _LDBJOBS &PDBJOBS..JOBS % statement in
May 20, 2004 line 652 was deleted.
Thanks to Christa Neven, KBC BankVerzekeringsHolding, BELGIUM.
Change 22.102 SAS under unix does not fileref SASAUTOS (SN=000444), and
AUTOEXEC this caused NO LOGICAL ASSIGN FOR SASAUTOS followed by
AUTOEXEU WARNING: Apparent invocation macro LOWCASE not resolved.
May 20, 2004 ERROR 23-2: Invalid option name ) messages, plus the MXG
Version number and date are missing from this message:
MXG DATED HAS BEEN SUCCESSFULLY INITIALIZED.
The real cause of this error is that the %LOWCASE macro
function is not implemented in base SAS, but instead is
provide as a %MACRO in the "SASAUTOS" library; if that
function (and %LEFT) were in base SAS, there
would be no need to concatenate the "SASAUTOS" fileref
with the MXG SOURCLIB. For both z/OS and Windows and
Linux, SAS does "fileref" the SASAUTOS (with a -SET in
the SASVn.CFG file, so this syntax in the MXG-provided
AUTOEXEC.SAS works just fine.
OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB,SASAUTOS);
However, under unix, you must provide the "pointer" to
the SASAUTOS directory; you could use a FILENAME to do
that, but it is simpler to use the new AUTOEXEU member
for your autoexec.sas under unix, as it contains
OPTIONS SASAUTOS=(SOURCLIB !SASROOT/SASAUTOS);
which should be the correct location of unix sasautos.
For Windows, of course, the location is different, and
OPTIONS SASAUTOS=(SOURCLIB !SASROOT\CORE\SASMACROS);
is the correct syntax.
If any of the above fail in the future, all you need do
is to search your disk for the file "lowcase.sas", which
will be found in some directory under the sas root, and
use that directory name in your AUTOEXEC/AUTOEXEU file.
Thanks to Steven Hudson, Avnet Inc, USA.
Change 22.101 Support for VIO/PLUS subtypes 1 and 2 create new datasets
EXTYVIOL subtyp dddddd dataset description
EXTYVION 1 TYVION TYPEVION VIO PLUS NON-VSAM STATISTICS
IMACVIOP 2 TYVIOL TYPEVIOL VIO PLUS LOAD STATISTICS
VMACVIOP and eliminates INPUT STATEMENT EXCEEDED RECORD LENGTH
VMXGINIT error. Both new subtypes have been validated with data.
May 5, 2004
Thanks to Billy Westland, Kaiser Permanente, USA.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 22.100 Invalid SMF 80 created by EKC's ETF/R FIRECALL product
VMAC80A caused INPUT STATEMENT EXCEEDED RECORD LENGTH ERROR. The
May 4, 2004 second segment length was 197, but only 7 bytes remained
in the record. This vendor's "ETFR" modified SMF 80 was
supported by Change 21.215, after a similar error in that
record was circumvented by Change 21.201. This new EKC
record contains "EKCS" rather than "ETFR", and eventually
I'll support that unique record, also, but for now, this
additional test will prevent your daily job from ABENDing
no matter what EKC comes up with next.
May 22: EKC Inc fix for this error is their PTF LK12029.
Thanks to John Grasing, Metropolitan Life, USA.
====== Changes thru 22.099 were in MXG 22.04 dated May 2, 2004=========
Change 22.099 Documentation only. If a "dddddd" macro variable WTNT063
VMXGINIT %GLOBALed but was not %LET a value, then SAS syntax
May 2, 2004 errors 22, 202, and 455 and their messages were created:
+ &WTNT063..NT063
22
202
455
ERROR 22-322: Syntax error, expecting one of the following:
a name, a quoted string, RC, _DATA_, _LAST_,;, _NULL_.
ERROR 202-322: The option or parameter is not recognized
and will be ignored.
ERROR 455-185: Data set was not specified on the DATA
statement.
Change 22.098 Variables LCPUSHAR,LPnSHARE in ASUM70PR/ASUM70LP/ASUMCEC
VMXG70PR are the Initial Weight of the LPAR (SMF70BPS). Now, new
May 2, 2004 variables LCPUSHAC,LPnSHARC in those datasets contain the
Current Weight of the LPAR (SMF70ACS).
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 22.097 Assembly error for ASMRMFV if an old OS/390 MACLIB was
ASMRMFV used: "ASMA017W Undefined keyword parameter - GETDS/LOC"
May 2, 2004 because the old GETDSAB macro did not support LOC=ANY.
Reassemble with a current z/OS MACLIB, or you can remove
",LOC=ANY" from the GETDSAB macro call in ASMRMFV source,
if you're still stuck with an old system and MACLIB.
No change was made in MXG code; documentation only.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.096 Global macro variables &MACINTV and &MAC30DD are defined
IMAC30DD in VMXGINIT and located in IMACINTV and IMAC30DD so that
IMACINTV TYPE30_V(PDB.SMFINTRV) and TYPE30_D(PDB.DDSTATS) datasets
VMXGINIT can be optionally created using %LET MACINTV= syntax as
May 2, 2004 an alternative to EDITing the IMAC members.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.095 Support for OS/400 5.2 QAPMMIOP with three new fields
VMACQACS that were added compatibly at the end of the record;
May 2, 2004 the length for QAPMMIOP is now 290 instead of 272.
Thanks to Clayton Buck, UniGroup, USA.
Change 22.094 CICS/TS 2.3 records with no excluded fields had wrong
VMAC110 values for all variables after CBSRVRNM in the CICSTRAN
May 1, 2004 dataset. If, instead, you had excluded fields from SMF,
Aug 13, 2004 like all my test CICS/TS 2.3 data, and used the UTILEXCL
program to create your IMACEXCL tailoring member, that
code did input CBSRVRNM correctly as $EBCDIC4., but the
code for un-excluded records input CBSRVRNM as $EBCDIC8,
throwing every thing else in the record off by 4 bytes.
Note: Not to defend my error, but I do STRONGLY recommend
that even if you do not have any EXCLUDEd fields in
CICS data, you should still use UTILEXCL to create
a tailored IMACEXCL for your installation; it will
minimize the size of CICSTRAN by keeping only the
CICS variables in your current release(s), and some
some optional CICS fields are only decoded if you
use UTILEXCL to create an IMACEXCL to create your
CICSTRAN data.
Aug 13: More Important Note: Variable TASCPUTM is one of
the VERY MANY CICSTRAN variables that are wrong if you
read CICS/TS 2.3 records without this change. As listed
in CHANGES since last May, MXG 22.04 or later is the
REQUIRED version to support CICS/TS 2.3 records fully.
Thanks to Helmut Roese, COM Software, GERMANY.
Change 22.093 Cosmetic. Blank lines between FIRST/LAST record messages
VMACSMF were removed, _N_= value is consistently located, and new
May 1, 2004 Start of Read SMF and End of Read Time of Day messages.
Change 22.092 For SMF 116 Subtype 1 and 2, the CICS and IMS id fields,
VMAC116 variables QWHCTNO,QWHCTRN,QWHCTASK for CICS and
May 1, 2004 variables QWHCPST, QWHCPSB for IMS
were not in the same location as the subtype 0 record.
New input statements correct those variables in the
MQMACCTQ and MQMQUEUE datasets.
Thanks to Helmut Roese, COM Software, GERMANY.
Change 22.091 Variable PCTALLBY in dataset TYPE78CU should have always
VMAC78 been a missing value, with z/OS 1.2+, per the June, 2002,
May 1, 2004 note added to the text of Change 19.203, but it has been
alway 100% instead of missing. The test was revised so
that it now is as documented, always missing value.
Thanks to Phil Baxter, Cap Gemini Ernst & Young, ENGLAND.
Thanks to Simon Bolland, Cap Gemini Ernst & Young, ENGLAND.
Change 22.090 MXG 22.02-22.03 only. Change 22.045 corrected QWHSSTCK in
VMACDB2 DB2STATx datasets (so statistics intervals would MERGE),
VMACDB2H but that change caused QWHSSTCK in the DB2ACCTx datasets
May 1, 2004 to be zero (printed as year 1960).
-MXG Logic in VMACDB2H was revised to RETAIN the STCK of
the first ID=100 record in variable STATSTCK, and use
QWHSSTCK=STATSTCK for statistics data, but directly use
QWHSSTCK=THISSTCK for ID=101 DB2ACCTx datasets.
-The RETAIN QWHSSTCK in VMACDB2 was removed as not needed.
Thanks to Dean Ruhle, J. C. Penney, USA.
Change 22.089 Variable QWHCCV was INPUT $EBCDIC12. in MXG 20.20, but as
VMAC116 the field contains both EBCDIC text characters and binary
May 1, 2004 hex values, the INPUT was changed to $CHAR12 in MXG 21.21
so that the hex values were preserved when MXG executed
under ASCII. On EBCDIC platforms, there is no difference
between $EBCDIC and $CHAR, but $CHAR informat variables
must be formatted $HEX: a binary '00'x value, PROC PRINTd
can stop VTAM output, so QWHCCV is now $HEX24 formatted.
16Jan04: Note that my choice to format QWHCCV as $HEX24
will cause printed reports to be expanded from 12 to 24
positions.
Thanks to Dean Ruhle, J. C. Penney, USA.
Change 22.088 If VMXGRMFI is invoked a second time with PDB= non-null,
RMFINTRV to re-read the PDB.TYPE7xx datasets to create different
VMXGRMFI output "PDB.RMFINTRVs", perhaps with different workload
Apr 30, 2004 definitions, the SPINRMFI dataset was reused and became
May 19, 2004 corrupted, causing spurious observations to be created.
Note:
This does NOT happen with the example in RMFINTRV using
PDB=, TRENDIN=PDB.RMFINTRV, to resummarize the first
output to create separate hourly and daily summary
datasets PDB.RMFINTHR and PDB.RMFINTDY. When the PDB=
argument is null, the SPINRMFI dataset is not used.
The SPINRMFI is only needed to keep the prior day's
last four hours, for calculation of MXG's MSU4HRAV.
If your PDB= argument is non-null in subsequent VMXGRMFI
invocations, you must use the SPINRMIN= argument to name
your spin dataset (e.g. SPINRMIN=SPINRMXX,), so that that
summarization's SPIN will be in SPIN.SPINRMXX dataset.
The default value for SPINRMIN is SPINRMFI, and I suggest
you use SPINRMxx naming convention for your dataset.
-This change also created new argument SPINRMOU, for the
output dataset name, for consistency, but it is unlikely
to be used. SPINRMOU defaults to the value in SPINRMIN.
-Each VMXGRFI with PDB=non-null must use a different SPIN
dataset; the SPINRMIN= argument changes the dataset name,
but the default "SPIN" library is used for all of them.
There is an alternative: you can have multiple "SPIN"
libraries, instead of multiple "SPIN" datasets, using the
&SPININ/&SPINOUT macro variables created in Change 22.018
(so that you could have different input and output SPIN
libraries so you could use a GDG for your SPIN library).
So you could %LET SPININ=SPIN01, to change the DDNAME for
each %VMXGRMFI invocation.
-May 19: Example in comments in RMFINTRV was missing the
comma after SPINRMIN=SPINRMDY, now corrected.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 22.087 Non-PR/SM systems. Datasets PDB.TYPE70 and PDB.RMFINTRV
VMAC7072 had variables IORATE and PCTTPI too low; they contained
Apr 30, 2004 values from only the last CPU, instead of the totals.
This error was introduced in MXG 21.05 when Change 21.170
moved the three lines inside the PR/SM Control Section,
which does not exist on non-PR/SM systems. The lines are
relocated after the PR/SM Control Section (NRPRCSS) loop.
Thanks to Dean Ruhle, J. C. Penney, USA.
Change 22.086 The second IF ID=xx AND MVSXA THEN DO; statement should
VMAC74 have been ELSE IF ID=xx ...., for performance reasons,
VMAC75 and to be consistent with SMF TYPE logic in MXG, but it
VMAC76 had no other impact on execution.
VMAC77
Apr 30, 2004
Thanks to Dr. Alexander Raeder, Intellium, GERMANY
Change 22.085 Support for TNG NT platform SESSION and USER objects:
EXTNT063
EXTNT064 dddddd Dataset Description Vars Instances
FORMATS TNT063 NT063 SESSION 77 181
IMACTNG TNT064 NT064 USER 17 75
VMACTNG You must update your MXG Format Library with this FORMATS
VMXGINIT member (see FORMAT step of JCLINSTL).
Apr 29, 2004
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 22.084 Large QBSTGET in PDB.DB2STATB after Change 22.045 occurs
VMACDB2 if the DB2 Subsystem was restarted, and the buffer pool
Apr 29, 2004 was not used in every interval. MXG Logic was revised
to use QWHSACE to detect a restart had occurred.
Thanks to Steve Dyck, Canadian Depository for Securities, CANADA.
Change 22.083 Support for additional unix AIX PTX objects create new
EXAIXIP datasets:
EXAIXNFS dddddd dataset description
EXAIXRPC AIXIP AIXIP AIX IP DATA
EXAIXTCP AIXNFS AIXNFS AIX NFS DATA
EXAIXUDP AIXRPC AIXRPC AIX RPC DATA
IMACAIX AIXTCP AIXTCP AIX TCP DATA
VMACAIX AIXUDP AIXUDP AIX UDP DATA
VMXGINIT
Apr 29, 2004
Thanks to Glenn Bowman, Wakefern, USA.
Change 22.082 Variable MEMINBOX in NTCONFIG dataset was 1/100th of the
VMACNTSM actual memory in the box; the INFORMAT MEMINBOX 16.2 was
Apr 28, 2004 changed to INFORMAT MEMINBOX 16. because the value is an
integer, and does not have two implied decimal places.
Thanks to Diane Parker, AmeriSource Bergen, USA.
Change 22.081 -If the translate table used to send TNG ASCII data to MVS
VMACTNG created '9E'x/'9F'x for Left/Right Square Bracket & '4F'x
Apr 28, 2004 for Exclamation Point, those unexpected values caused MXG
Apr 29, 2004 ERROR: UNEXPECTED CAPMPCM HEADER RECORD. The Left Square
Bracket test now has '9E'x for that EBCDIC value, and has
'92'x, because the ftp of the '9E'x value back to ASCII
created that unexpected value. The full test now is:
IF TYFLG IN : ('[','5B'X,'AD'X,'BA'X,'92'X,'9E'X)
-Change 21.269 blanked variable DOMAIN, but did not note
that there is no "domain" value in TNG, and that variable
should not have been created. SYSTEM is the one to use.
-The "DATA FROM PLATFORM" message now has the SYSTEM from
each new Header record; it was blank in the first message
and had the prior record's SYSTEM value in the rest.
Thanks to Gunner Jacobsen, Nordea, NORWAY.
Change 22.080 Variable CPUTM was removed from PDB.CICS built from ASG-
ASUMCICT The Monitor's MONITASK dataset, since TASCPUTM is the TCB
Apr 28, 2004 CPU time variable. CPUTM had been removed from PDB.CICSs
built by ASUMCICS and ASUMCICX by was accidentally left
in the ASUMCICT member.
Thanks to Frank Lund, EDB IT Drift, NORWAY.
Change 22.079 Support for IBM Session Manager User SMF record creates
EXIBSMSM IBMSESMG dataset. Unfortunately, there is no field that
IMACIBSM indicates what Application was connected to, so for a
TYPEIBSM specific USERID/LTERM (variables SSTUSER/SSTTNAM), that
TYPSIBSM connected to multiple applications, records with overlap
VMACIBSM between Session Start (SSTSTRTT) and SMFTIME (Signoff).
VMXGINIT Use SMFTIME instead of the lower resolution SSTSTIME for
Apr 28, 2004 the signoff time. Query to IBM as to why there is no
field for the application to which session connected.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 22.078 Cosmetic. Variable PCTDLCCA Label was corrected to be
VMAC7072 PCTDLCCA='CPU*CAPPING*DELAY*PERCENT'
Apr 27, 2004 instead of RESOURCE*GROUP... (which is in PCTDLPDE).
Thanks to Ronald Kveton, Experian, USA.
Change 22.077 Support for "second flavor" of ACCT fields; original data
VMACTPMX had the "standard type 30 job accounting string", but new
Apr 27, 2004 data has multiple ACCT fields; new logic detects which is
present and still populates ACCOUNT1-ACCOUNT9, LENACCT1-
LENACCT9 from the individual fields.
-TSSUSR2 and TSSUSR3 fields now supported.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 22.076 Cosmetic. Variable _N_ was added to PUT statements for
IMACACCT error conditions and messages were single spaced.
Apr 27, 2004
Change 22.075 ARRAY SUBSCRIPT OUT OF RANGE error occurs if you have
VMAC74 more than 255 structures in your CF; the temporary arrays
Apr 27, 2004 allocated only 255 elements, but they have been raised to
1024 elements, which I believe is the maximum number of
structures supported in a CF.
Thanks to Bob Miller, CONSECO, USA.
Change 22.074 DB2 Trace SMF 102 Subtype 125 dataset T102S125 variables
VMAC102 QW0125PC QW0125PL QW0125PN QW0125TS QW0125SN were missing
Apr 27, 2004 values because the test for QWT02R1L GE 64 should have
been GE 62. The original DSECT showed two reserved bytes
but those bytes do not exist in the current record, so
the +2 at the end of segment was also removed.
Thanks to Ron Alterman, PG&E, USA.
Change 22.073 SMF 119 Subtype 10 dataset TYP11910 had invalid values in
VMAC119 variables UCINDTGR UCOUDTGR UCINBYTE UCOUBYTE because +2
Apr 27, 2004 was needed to skip two reserved bytes before UCINDTGR.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 22.072 For Service or Reporting Classes with R723CWMN GT 0, not
VMAC7072 all periods were output. With three periods, only the
Apr 27, 2004 first period was output; with four periods, only the 1st
Aug 5, 2004 and 2nd periods were output. This is NOT a new error;
MXG has always been this way:
Inner loop IF R723CWMN GT 0 THEN DO _I_=1 TO R723CWMN;
(for the two state/delay sections), and the outer loop
(for each period), DO _I_=1 TO NRSCS; used the same _I_
variable! Transaction Service Classes have R723CWMN=2
(begin and end entries), causing _I_=3 when R723CWMN=2,
so if NRSCS (number of periods) was 2 or 3, only the
first period's data was created. (With 4 periods in
the service class, only the first and second period
data was output, but not the 3rd nor 4rd, etc.).
The DO variable in the inner loop was changed to _II_ to
correct this error.
-The April text cited R723TYPE=3 as the only exposure, but
the error actually occurred with any service or reporting
class with R723CWMN non-zero. This text was revised in
August, but the April code change was not affected.
Thanks to Tom Koelle, CitiGroup, USA.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 22.071 Test string for "SAS Product SMF Record" change to SASU
UTILBLDP (it was SAS) to correctly include VMACSASU, etc., when
Apr 26, 2004 SAS USER records are to be processed.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 22.070 Modification to VMXGSUM to prevent a bizzare abend that
VMXGSUM should not happen but did happen in one isolated case,
VMXGSUME where a slash was used. Addition of %STR resolved.
Apr 26, 2004
Change 22.069 The BLDSMPDB utility for daily/weekly/monthly/trend PDB
BLDSMPDB had used SMF= for its input argument, but Change 22.060
Apr 26, 2004 replaced hardcoded SMF DDname in VMACSMF with &SMF, which
caused BLDSMPDB code to fail; the name in BLDSMPDB was
changed to SMFIN= to eliminate the conflict and error.
Thanks to ???, ???, USA.
Change 22.068 -Support for optional RMI data for both CMODNAME='RMI' in
VMAC110 IMACICRM and CMODNAME='DFHRMI' in IMACICRD adds similar
UTILEXCL but different sets of RMIxxxxx variables.
IMACICRD -UTILEXCL was revised to support DFHRMI and RMI segments;
IMACICRM without this change, if CMODNAME='DFHRMI' was in the CICS
Apr 17, 2004 dictionary, the IMACEXCL created by UTILEXCL failed with
a SAS 180 error, underscoring variable TRANTYPE.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 22.067 Ending */ comment was missing, but the only impact was
SPUNJOBS that work datasets were not be deleted.
Apr 16, 2004
Thanks to Dov Brosch, Bank Hapoalim, USA.
====== Changes thru 22.066 were in MXG 22.03 dated Apr 5, 2004=========
Change 22.066 Cosmetic. Labels for SOMSGIN1 and SOMSGOU1 were reversed.
VMAC110
Apr 5, 2004
Thanks to Allan J. Winston, MBNA, USA.
Change 22.065 The six undocumented ESS fields in SMF 57 (Change 22.057)
VMAC6 are also in SMF 6 records, and are decoded in variables
Apr 5, 2004 SMF6C1, SMF6C2, SMF6C3, SMF6N1, SMF6N2,and SMF6N3
Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.
Change 22.064 -Executing "MONTHBLD" on ASCII platforms caused errors, as
AUTOEXEC it was designed to run on "MVS", with RECFM=FB, which SAS
MONTHASC does not honor on ASCII; it presumed MVS JCL provided the
INSTALL required //DUMMY DD'; it created the MONTHPDB in "tape"
Apr 2, 2004 (sequential) format, to eliminate MVS tape mounts, etc.
This new MONTHASC member executes under ASCII and creates
a "disk" format SAS Data Library, but it also executes on
"MVS", and it may be preferred there, now that Virtual
Tape drives have eliminated most of the concerns about
tape mounts, and the "disk" format library with directory
is much faster to access a single dataset; furthermore,
the "disk" format PDB can be migrated to tape by HSM!
-AUTOEXEC member was revised to add LIBNAME DUMMY, which
is used for "dummy" datasets in MONTHASC.
-INSTALL for MXG install under ASCII was revised to note
that you need to create c:\mxg\dummy directory and the
c:\mxg\userid\instream.sas file, if you did not copy the
MXG product from CD-ROM (that directory and file are now
created on the CD-ROM).
Thanks to Joe Keey, BOC, ENGLAND.
====== Changes thru 22.063 were in MXG 22.03 dated Apr 2, 2004=========
Change 22.063 The delay percentages in TYPE72GO are calculated by using
VMAC7072 R723CTSA, execution samples, if it is non-zero as the
Apr 1, 2004 denominator, replacing VALDSAMP. But PCTDLTDQ, pct total
delay including batch, when there was batch queueing is
incorrect, because in that case, VALDSAMP and R723CTSA
can be major-different (R723CTSA=7, VALDSAMP=202,206!),
so the calculation of PCTDLTDQ is now based on VALDSAMP
instead of R723CTSA, to get a sensible percentage!
Thanks to Phil Baxter, CGEY, ENGLAND
Thanks to Simon Bolland, CGEY, ENGLAND.
Change 22.062 When REPORT=ALL is specified, the HTTP report abends with
ANALRMFR ERROR: FILE WORK._LTY1031 DOES NOT EXIST. The HTTP report
Apr 1, 2004 logic was not included in the "ALL" logic, but now it is.
Thanks to David Klein, DOITT - City of New York, NY.
Change 22.061 Cosmetic. VARIABLE QWGTDSC1 IS UNINITIALIZED had no
UDB2GTF impact; it was in a Debugging PUT that was not executed.
Apr 1, 2004 This UDB2GTF utility is required as a pre-step to convert
GTF 256-byte "chunks" into readable VB records, which can
then be read by MXG. The output DDNAME of UDB2GTF is
GTFOUT, so to process that converted file, you would use
%READDB2(GTF=GTFOUT,IFCIDS=ALL) to create all possible
DB2 datasets and populate those found in your data.
Thanks to George French, Liberty Mutual, USA.
Thanks to John Pierce, Liberty Mutual, USA.
Change 22.060 -The ARRAYs added in TYPETPMX in MXG 21.21 cause horrific
EXTPMACT CPU time increases, from 3 Minutes to 71 Minutes for
EXTPMAFF TYPETPMX to read 4 million SMF records (4GB), of which
EXTPMAFT only 16,000 (70MB) were TPM records. (Processing the SMF
EXTPMBFR file of only those 16K TPM records took 3 CPU minutes.)
EXTPMBND The ARRAYs were used to store the variables that can have
EXTPMBVL multiple instances (like the list of VOLSERs used), and
EXTPMDEA you had to update IMACTPMX to tell MXG the maximum number
EXTPML10 of instances of each of the arrays. The problem is that
EXTPML11 real variables were defined in each array, and that was
EXTPML12 the cause of the CPU increase; for real variables, SAS
EXTPML13 initializes each array variable before each SMF record
EXTPML14 is read. Using _TEMPORARY_ instead of real variables
EXTPML15 eliminated the CPU hit, as did removing the ARRAYs and
EXTPML16 their references.
EXTPML17 -With real variables in an ARRAY, SAS initializes every
EXTPML18 one of the variables for each new SMF record, even for
EXTPML19 the non-TPM SMF records that are skipped after their ID
EXTPML20 in INPUT and tested, before any arrays were referenced.
EXTPML21 -The only solution was to completely rewrite TYPETPMX and
EXTPML22 eliminate the use of real variable ARRAYs, and instead,
EXTPML23 create 34 new TPMxxxxx datasets, one for each variable
EXTPML24 that can have multiple instances, keeping the instanced
EXTPMLL1 variable and JOB JESNR SMFTIME SYSTEM variables so you
EXTPMLL2 can select and report, or use those key variables to
EXTPMLL3 JOIN the instanced dataset with TYPETPMX if needed.
EXTPMLL4 There is a counter variable in TYPETPMX for each of the
EXTPMLL5 instanced variables to tell you if there are instances.
EXTPMLL6 -The %LETs that you were required to update in IMACTPMX,
EXTPMLL7 which told MXG the maximum number of instances are no
EXTPMLL8 longer required and were removed ("a Good Thing"), as
EXTPMLL9 were the now-unnecessary DROP statements in the EXTYTPMX
EXTPMLLM exit member for those instanced variables. And TYPETPMX
EXTPMLMT dataset now has only 480 variables, but you may have to
EXTPMVVL revise your TPMX reports as a result of this redesign.
EXTYTPMX -Before TYPETPMX was redesigned, a circumvention was seen
IMACTPMX possible: my changing the hardcoded INFILE SMF ... in the
VMACSMF MACRO _SMF definition in VMACSMF to INFILE &SMF ..., and
VMACTPMX transparently adding %LET SMF=SMF in VMXGINIT, you could
VMXGINIT then change the INFILE name "on the fly", and could use
Apr 1, 2004 the MACFILE exit to send the TPM records to a temp file,
and then use "TYPETPMX" only against the TPM records:
// EXEC MXGSASV9
//SMF DD YOUR.SMF,DISP=SHR
//SMFOUT DD UNIT=SYSDA,SPACE=(CYL,(200,200))
//SYSIN DD *
%INCLUDE SOURCLIB(VMACTPMX); /*defines _IDTPMX*/
%LET MACFILE=
%QUOTE(
IF ID=_IDTPMX THEN DO;
FILE SMFOUT DCB=SMF;
PUT _INFILE_;
FILE LOG;
END;
);
%INCLUDE SOURCLIB(BUILD001);
RUN;
%LET MACFILE= ;
%LET SMF=SMFOUT;
%LET PTYTPMX=PDB;
DATA _VARTPMX; _SMF; _CDETPMX; RUN;
%INCLUDE SOURCLIB(BUILD002,BUILD003,BUILD004,BUILD005)
Although this specific need to change the SMF infile to
use the temporary SMFOUT file is no longer needed with
the revised TYPETPMX support, it was left in place for
possible future use.
Thanks to Richard S. Ralston, Humana, USA.
Change 22.059 New CICS/TS 2.3 Pool variables were added using reserved
VMAC110 fields in STID=60 subtype 2 SMF 110 stat record, but were
Mar 30, 2004 not input (no vertical bars in CICS Data Areas!):
Mar 31, 2004 DSGMMWTS DSGMMWTM DSGCMMWS DSGPMWWS DSGCMMWT
DSGTOTMT DSGTOTMW
DS2MMWTS DS2MMWTM DS2CMMWS DS2PMWWS DS2CMMWT
DS2TOTMT DS2TOTMW
DS3MMWTS DS3MMWTM DS3CMMWS DS3PMWWS DS3CMMWT
DS3TOTMT DS3TOTMW
These new variables measure TCB Mismatch Waits/durations
and MVS Storage Waits/durations, and are output in the
CICDSPOO datas for the three pools.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.058 -Temporary variable SHFTTIME should have been DROPed in
IMACSHFT IMACSHFT when it was added by Change 21.204; now it is
VMACTMDB DROPped so it will not be kept in any MXG dataset.
Mar 29, 2004 -Variables added to ASG Monitor for DB2 in Change 21.237
were not labeled.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 22.057 -Support for the optional ESS fields in TYPE57J2, for JES2
VMAC57 sysout transmission between NJE nodes; the ESS variables
Mar 29, 2004 are now (optionally) created if your IMAC6ESS member has
been tailored (comment block removed) to keep them.
-Six undocumented variables SMF57C1-C3 and SMF57N1-N3 are
decoded from the 28 bytes following SMF57TUL; they will
be re-labeled if their documentation can be located.
-SMF 57 is created when sysout was sent thru this JES2 NJE
node, but it counts only the number of logical TP records
(which may or may not count actual lines or images!).
-The SMF 57 record is also created by unisys's DEPCON
(output management tool), which routes print from unisys
to the z/OS print queue. While actual lines printed may
not be available, at least the destination printer is
available, but as there is no MVS "job" that created the
output, merging with BUILDPDB for unisys print accounting
is not really possible.
Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.
Change 22.056 Q3STHWIB variable should still be good; UNINIT Q3STHIWB
VMACDB2 note caused by a typo, but code is executed only if field
Mar 26, 2004 wrapped, and the next interval's Q3STHIWB value is valid.
Thanks to Lori A. Masulis, FMR, USA.
====== Changes thru 22.055 were in MXG 22.02 dated Mar 24, 2004=========
Change 22.055 TYPE42DS variable AVGIOQMS=RESP-PND+DIS+CON+CUQ is often
VMAC42 a negative 0.128 milliseconds, which is one clock tick in
Mar 24, 2004 the type 42 "clock", and AVGIOQMS is at best an estimate
of an average value. Since this is a calculated value,
rather than a value in an SMF record, I think it wise to
just set these negative values to zero, and document what
I've done here, so you don't get sidetracked by the small
negatives; the max AVGIOQMS was 902 Millisec/SIO.
Thanks to Ron Alterman, PGE, USA.
Change 22.053 Cosmetic. The MXG-created character variable CPCFNAME
VMXGRMFI was inconsistently built, sometimes with a dash 2064-2C8,
VMXG70PR sometimes without, 20642C8. It now always has the dash.
Mar 24, 2004
Thanks to Kenneth D. Jones, xwave, CANADA.
Change 22.052 PDB.STEPS can have some EXCP, IOTM, TAPEDRVS, TAPNMNTS
BUILD005 and TAPSMNTS counts from one step of a job output in the
BUIL3005 previous step of that job, if both steps have exactly the
VMAC30 same INITTIME: the first step was FLUSHED (condition code
Mar 23, 2004 bypass), so it was never initiated, nor allocated, nor
executed), AND, the next step initiated instantaneously,
without any delay, in the same 10 millisecond clock tick.
MXG's BUILDPDB logic was revised to use INITTIME STEPNR
instead of INITTIME to separate the two steps, so these
I/O counts are now output in the correct PDB.STEPS obs.
While I/O counts were in the wrong PDB.STEPS observation,
the values were correct, so the PDB.JOBS observation did
have the correct total I/O counts for the job (although
the TAPEDRVS count could have been incorrect). Also, in
PDB.STEPS the STEPNR was not equal to variable STEP (but
that is normal for restarted jobs, as STEP is a counter
of steps executed, and restarted jobs will have multiple
instances of the same STEPNR with different STEP values).
-Member VMAC30 had to be changed to add STEPNR to KEEP=
list for the TYPE30TD dataset.
Thanks to John R. Parla, CIGNA, USA.
Thanks to Ray Dunn, CIGNA, USA.
Thanks to Paul E. Cohen, CIGNA, USA.
Change 22.051 The Multi-System Remote Enclave CPU segment is 80 bytes
BUILD002 instead of the 20 bytes documented in SMF; I have guessed
VMAC30 what some of the fields contain, but the MRENxxxx names
Mar 22, 2004 will likely be changed when I understand what's what.
Mar 24, 2004 But assuming the data is eventually valid, I have added
Jan 12, 2005 _STY30MR to the BUILD002 so that PDB.TYPE30MR will now be
automatically created in the PDB library in BUILDPDB/PD3.
-Jan 12, 2005: This Change was COMPLETELY wrong; the code
was completely revised by Change 22.345, with correct
SMF30MRx variable names.
Thanks to Chuck Hopf, MBNA, USA.
Change 22.050 IRD caused wrong PCTCPUBY in TYPE70 and RMFINTRV datasets
VMAC7072 for intervals in which engines were varied offline. The
VMXGRMFI MXG support for IRD should now be complete; it was added
Mar 22, 2004 in these increments for these "CPU-measuring" datasets:
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
MXG accumulated CPUWAITM for each engine only when it was
online at the end of interval (CAIx='01'B), but when IRD
varies an engine CAIx='11'B, so CPUWAITM for that engine
was not added, causing CPUACTTM and PCTCPUBY both to be
too large. Now, CPUWAITM is accumulated if SMF70ONT is
non-zero (i.e., the engine was used, a stronger test).
-An unrelated error in the first RMF interval after an IPL
was also detected and corrected. The first records have
their interval DURATM greater than SMF70ONT, but CAI0=01
so engines were not varied off. For one IPL, the 25 sec
difference caused PCTCPUBY and CPUACTTM to be NEGATIVE!
These first interval records have short DURATM because
RMF is synchronizing with time of day:
IPL TIMESTAMP STARTIME DURATM SMF70ONT
22FEB04:02:15:05.95 02:19:12.00 0:09:47.39 0:09:24.26
22FEB04:02:22:46.45 02:26:59.00 0:02:00.63 0:01:35.19
22FEB04:01:28:39.42 01:31:52.00 0:12:07.05 0:11:39.81
I conclude that RMF starts to count DURATM before engines
are available for use, so MXG now uses SMF70ONT (if it is
non-zero) instead of DURATM to correct IBM's error.
-Variable CPUPDTTM is added to PDB.RMFINTRV. (It was the
validation of this user request that exposed the prior
MXG error!).
Thanks to Kenneth D. Jones, Xwave, CANADA.
Change 22.049 Variable TMNTUSER added to the Mount record is actually
VMACTMNT the existing LOCLINFO variable (in all JOB-related SMF
Mar 21, 2004 records), so TMNTUSER variable no longer exists.
Change 22.048 If SPF Statistics are enabled, the MXG.SOURCLIB PDS will
JCLINSTL now require 1199 directory blocks; JCL examples with 999
JCLTEST9 blocks were increased to 1199. Without SPF statictics,
COVERLTR only 399 blocks are required.
Mar 21, 2004
Thanks to Peter Giles, Centrelink, AUSTRALIA.
Change 22.047 -Datasets QAPMTCP and QAPMIFC were not automatically built
TYPEQACS by TYPEQACS/TYPSQACS, so they were not listed in DOCVER.
TYPSQACS -Variables PCTCPUBY NRCPUS were not labelled in QAPMSYSL.
VMACQACS -Variable INTSEC was not kept in QAPMTCP nor QAPMIFC.
Mar 21, 2004
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.046 %VMXGTIME was invoked before SYSTEM had been input in two
VMACRMFV places; the %VMXGTIME and IMACSHFT invocations were moved
Mar 20, 2004 to below the INPUT of variable SYSTEM.
Thanks to Michael Oujesky, MBNA, USA.
Change 22.045 Dataset PDB.DB2STATB was not protected for wrap of 4-byte
VMACDB2 counters, which caused negative values in variables like
Mar 20, 2004 QBSTDPP,QBSTGET,QBSTRIO,QBSTSGT,QBSTSPP,QBSTSWS, all of
which can have very large raw values before their DIF().
All other DB2 variables that are DIF()'d were protected.
This error was introduced in Change 21.140 when DB2STATB
was restructured and I forgot to protect for wrapping.
Thanks to Ron Alterman, PGE, USA.
Change 22.044 The %%INCLUDE SOURCLIB(VGETJESN) should have been only
ANALEPMV one %INCLUDE SOURCLIB(VGETJESN) because it is inside a
Mar 18, 2004 %MACRO statement; two are needed inside MACRO statements.
Thanks to David Klein, DOITT - City of New York, NY.
Change 22.043 APPL records with or without the nine APPRM variables are
VMACMWUX supported in a heuristic test for LENGTH LE/GT 565, based
Mar 18, 2004 on 535/536 length without, 594/595 with, in test data.
Thanks to Miguel Fernandez, Information Services International, USA.
Change 22.042 DB2 Statistics SMF 100 Subtypes 0, 1, and 2 have always
VMACDB2H been written to SMF in order, but because their QWHSSTCK
Mar 18, 2004 datetime values could be fractions apart, I retained STCK
from each 0 into its 1 so DB2STAT0 and DB2STAT1 had the
same value in QWHSSTCK, so they could be MERGEd to create
DB2STATS directly. But now, one site's DB2 6.1 SMF 100
records are completely out of order, with subtype 0 with
an earlier STCK written after that interval's subtype 1
with a later STCK value, and MXG's algorithm to create a
common QWHSSTCK value created this ERROR message:
DB2 TYPE 100 SUBTYPE 1 FOUND AT START OF INPUT FILE.
The error corrupts the DB2STATS0,DB2STATS1 and DB2STATS
datasets; QWHSSTCK will have wrong values, and subtype 1s
from one interval may be merged with subtype 0 from next
interval in the DB2STATS dataset, and negative values in
DB2STATB dataset may result when this message is printed.
-The QWHSSTCK logic now recognizes the start of interval
as a delta of 10 seconds, and the first record's STCK is
now stored in QWHSSTCK for all three STAT subtypes.
-It's only a guess as to why this has not been seen before
but it may be the "tactical" interval of one minute that
exposed the error; for whatever reason, it is now clear
that each of these subtypes are created by independent
subtasks, so their physical writes are not in any order,
and my ASSUMEption of order was wrong.
Thanks to Ron Alterman, Pacific Gas and Electric, USA.
Change 22.041 If you EXCLUDEd variable OPERATOR or TERMINAL in CICS SMF
ASUMCICS and if you used ASUMCICS (which we no longer recommend)
Mar 17, 2004 to create PDB.CICS, the length of OPERATOR and TERMINAL
are now $1, but they were $4 in previous versions. This
can cause a warning if you combine PDB.CICS datasets in
your MONTHBLD that were built with two different versions
of MXG. This change restores the length to $4 for both.
See Change 21.xxx on why ASUMCICS may not be the
right program to use.
Thanks to Gary Keers, AES, USA.
Change 22.040 The ANALALL example, which selects all SMF records from a
ANALALL JOB(s), creates all MXG datasets from those SMF records,
Mar 17, 2004 and then prints all observations and all variables, can
also be used to create an SMF output VBS file with all of
the selected SMF records. Comments in the member show
how to add
FILE SMFOUT DCB=SMF;
PUT _INFILE_;
FILE LOG;
after the IF JOB=: selection in %LET MACJBCK=, and how
to add an //SMFOUT DD statement for those records.
Thanks to Alex Puno, LACO, USA.
Change 22.039 If you use the _N42 macro to null data set creation, the
VMAC42 _WTY4237 null definition was missing; it has been added.
Mar 16, 2004
Thanks to Jon Whitcomb, Great Lakes Educational Loan Services, USA.
Change 22.038 ML-31 of the Exit-Based MXG Tape Mount, Allocation, and
ASMTAPEE Allocation Recovery monitor corrects GMT timestamps that
Mar 15, 2004 should have been on the local clock, and supports an IBM
Mar 25, 2004 MSC APAR that changed bit meanings. The MXGTMNT DIAG
command provides additional diagnostics in its WTO text,
but will also write a "dump" to a file (for sites where
taking a "system dump" is political issue), if there is
an MXGDUMP DD included in the monitor program's JCL:
//MXGDUMP DD RECFM=FB,LRECL=4160,BLKSIZE=4160,
// UNIT=SYSDA,SPACE=(CYL,(100,100)),
// DISP=(,CATLG),DSN=YOUR.CHOICE
The DIAG command is issued from a console:
F jobname,DIAG
where jobname is the "job" name of the MXGTMNT monitor.
-The IBM IEF-VOLUME-MNT exit in our Exit-Based logic is
not called by StorageTek's HSC software, so you will NOT
see any mount records with HSC with MXIT=YES in ML-31.
Now that we've examined the dump and saw that STK did not
call the IBM exit, and knew who/what to ask, STK has been
very cooperative in providing documentation of HSC, so I
believe it is only a matter of time (weeks?) before our
"asmguy@mxg.com" will develop the needed enhancement to
support both HSC and IBM tape mounts with MXIT=YES.
April 1, 2004.
Change 22.037 Support for NetMaster subtype 5000x record, Performance
EXNETM50 Monitoring record.
IMACNETM
VMACNETM
VMXGINIT
Mar 24, 2004
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
====== Changes thru 22.036 were in MXG 22.01 dated Mar 11, 2004=========
Change 22.036 The MG070CP format, used only if you are still on OS/390,
FORMATS or running z/OS on a non-zSeries machine, was updated for
Mar 11, 2004 the 2066-E1 and 2066-X2 processors.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Edward Ogonosky, Blue Cross Northeast PA, USA.
Change 22.035 The z/VM MONWRITE "User" dataset, VXBYUSR, was left in
VMACVMXA the //WORK file and was not written to the //PDB, but now
VMXGINIT is; this is the dataset with interval data for each CMS
Mar 11, 2004 "user", i.e., each VM Machine, and is THE dataset to use
to track individual Linux-under-VM machine activity. Only
the default output "DDname" was changed.
Thanks to Reinhard Kelm, GAD, GERMANY.
Change 22.034 -Support for Candle optional CANADABN and CANADABT fields
IMACICD4 (for Adabas Count/Duration variables of same NAME) is
IMACICD5 added. UTILEXCL will detect and tell you to open the
UTILEXCL comments in the appropriate IMAC, if fields exist in your
VMAC110 CICS SMF 110 records, with Candle's additions.
Mar 10, 2004
Thanks to James Hein, Erie Insurance, USA.
Change 22.033 -Support for XIDTYP='A' ADAPATER record in new QAPMIOP5
EXQAPIO5 dataset.
IMACQACS -Correction for LRECL=359 QAPMIOPD record which has an
VMACQACS extra byte betwen XIDTYP and XIDTA1.
VMXGINIT
Mar 10, 2004
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 22.032 Support for Endeavor Release 4.0 user SMF (INCOMPATIBLE,
VMACENDV because ELEMT, DSNAME, and DSMEM fields were relocated.
Mar 10, 2004 The Action Record (subtype 2) has been validated with
new data; the Block Header's record version had to be
used to identify the new format record because C1VER was
not changed (only has before/after 2.5), and SM2RECVN is
'01' in the new records. The Security Record (subtype 2)
also had incompatible changes, and has been coded, but no
subtype 1 records have been validated. The DSECT shows
a subtype 3 (ESI Exception) and a subtype 4 (MCF CHANGES)
but there is no sub-DSECT for those records; if a 3 or 4
is found, MXG will print one record on the log.
Thanks to John Paul, Highmark, USA.
Change 22.031 The ASUMJOBS logic calculated the Initiation Wait Time as
ASUMJOBS IWT=INITTIME-JRDRTIME, but JRDRTIME is only in the Purge
Mar 9, 2004 record, so a PDB.JOBS observation that did not have a
Purge record (probably because member IMACSPIN had not
been tailored to change MXG's SPINCNT=0 default) had a
missing value for JRDRTIME, causing IWT to be missing.
This caused the summarized observations in PDB.JOBSKED to
have incorrect bucket percentages because IWT missing was
counted as a zero-wait job. It also caused IWT (summed)
to be equal to IWTMAX in some obs that had NUMJOBS more
than one (but closer examination showed that these case
actually had had only one job with non-missing IWT!).
The IWT calculation was revised; if JRDRTIME is missing,
IWT=INITTIME-SUM(READTIME,RDRTM) is used, as those data
are in the JOB Termination record. And if the IWT is
still a missing value, that job will be deleted.
Thanks to Miguel F. Montferrer Carvajal, RSI EDS, ESPAGNE.
Change 22.030 Support for DF/SMS Storage Class Exit User SMF record,
EXSMSXSC written at Storage Class assignment, so you can examine
FORMATS how your ACS rules actually perform. New dataset:
IMACSMSX dddddd Dataset Description
TYPESMSX SMSXSC IGDACSSC DF/SMS STORAGE CLASS EXIT
TYPSSMSX I arbitrarily only output the first six VOLSERS of the
VMACSMSX possible 1464 volumes that a dataset can have, until
VMXGINIT someone needs all of them!. I was unaware of that limit.
Mar 9, 2004
Thanks to Tobias Cafiero, Depository Trust and Clearing Company, USA.
Change 22.029 Support for new SMF 117 record from WBIMB, WebSphere
EX117FLO Business Integration Message Broker creates four new
EX117THR datasets:
EX117NOD dddddd Dataset Description
EX117TRM 117FLO S117FLOW MESSAGE FLOW
FORMATS 117THR S117THRD THREAD
IMAC117 117NOD S117NODE NODE
TYPE117 117TRM S117TERM TERMINAL
TYPS117 Data for FLOW, THREAD, and NODE have been validated.
VMAC117
VMXGINIT
Mar 8, 2004
Thanks to Victoria LePak, AETNA, USA.
Thanks to Jeff Martens, AETNA, USA.
Change 22.028 The BY-list-macro _BCICRDQ for new CICSRDQU had TSQNAME,
VMAC110 but that should have been TSQUEUE. This misspelling was
Mar 5, 2004 missed because CICSRDQU is not sorted by default.
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.027 -Variable SM120WIP is a count, not a duration; it is input
VMAC120 now as &PIB.4. instead of &PIB.4.3, and is no longer in
Mar 5, 2004 the TIME13.3 format list.
Mar 10, 2004 -For subtype=7, MXG output only the first server segment
from web application section, causing the counts in the
web activity TYP120WA dataset to be wrong, and much lower
than corresponding web interval counts in TYP120WI. All
server segments are now output.
Thanks to Andre Baltimore, Unigroup Inc, USA.
Change 22.026 Cosmetic. The time-of-day when the read of the SMF file
VMACSMF ended is now printed in the "SUCCESSFULLY READ SMF FILE"
Mar 4, 2004 message on the SAS log.
Change 22.025 The JCL Procedure for MXG and SAS execution for SAS V 9.1
MXGSASV9 is slightly different than the original SAS V9.0 JCL. The
Mar 4, 2004 entry point is SAS, the "BATCH" config member is BATWO,
and the DSNAMES are now .WO.AUTOLIB, .ENW0.SASHELP, and
.ENW0.SASMSG.
Thanks to Ed Finnell, University of Alabama, USA.
Change 22.024 This text just documents all of the names of %MACROs that
doc are currently defined anywhere in MXG source code.
Mar 4, 2004 ACTIVITY ANAL115 ANAL94 ANALAVAI ANALBLSR ANALCISH
ANALCNCR ANALDB2C ANALDB2R ANALDBTR ANALDMON ANALEPMV
ANALHSM ANALMNTS ANALNPMR ANALRMFR ANALTCP ANALUOW
ARGS BITCHECK BLDNTPDB BLDSMPDB CALCPOLC CDE_BCR
CDE_BVR CDE_DCL CDE_DCR CDE_DGN CDE_DSR CDE_DVL
CDE_L2CR CDE_MC1 CDE_MCA CDE_MCB CDE_MCC CDE_MCD
CDE_MCM CDE_MCO CDE_MCP CDE_MCR CDE_MCT CDE_MCU
CDE_MCV CDE_MHCR CDE_TTOC CDE_VAC CDE_VSR CECLEVEL
CHART CHKWORK CICCONSM CICDLIR CICDUMP CICFILE
CICSTOR CONVERT COPYIT CPUGRAF DASDGRPH DB2DBID
DB2RSELA DB2RSORT DBUGDB2C DEVTYPE DISKREPT DMIDET
DMISUM DMONREP1 DMONREP2 DMONREP3 DMONREP4 DOMAIN
DSNUPDT DSNUPDT DSNUPDT DT EMAIL EPIVARS
EXTRACT FACILITY FINALRPT FTPDATA FTPRPTD FTPRPTS
GENFTP GETHEX GETOBS GETSUM GRAFDB2 GRAFHSM
GRAFLPAR GRAFREGR GRAFRMFI GRAFTALO GRAFTAPE GRAFTMNT
GRAFTRND GRAFWORK GRAFWRKX GROUP HEADALL HSMBALL
HSMDELT HSMDELU HSMMALL HSMMMIG HSMMTYP HSMPALL
HSM_SUMT HTTPDTL HTTPSRY IMFDLCHA IMFDLSRT IMFDLTRX
INTVREPT IOSTAT IPHOST IPHOSTF LBLCLS LDSKREPT
LOOP LPARSUM MIGSGRPH MMRYREPT MNMXTIME MONTH
MONTHMTD MQMBUF MQMCFS MQMDB2 MQMLOG MRPDBCMD
MXGCAH MXGCF MXGCHAN MXGCOMM MXGCPU MXGDAY1
MXGDEVC MXGDOMI MXGENQU MXGHTTP MXGIOQU MXGPAGE
MXGPGDS MXGSDV MXGSMRY MXGVDAIL MXGVHOUR MXGVSTOR
MXGVUSAG MXGWKLD MXGWLMG MXGXCF NETWREPT NODATA
NPMSMR01 NPMSMR02 NPMSMR03 NUMTYPE OBSCHEK OBSCHEK1
OPTIONS OUT_BCR OUT_BVR OUT_DCL OUT_DCR OUT_DGN
OUT_DSR OUT_DVL OUT_L2CR OUT_MC1 OUT_MCA OUT_MCB
OUT_MCC OUT_MCD OUT_MCM OUT_MCO OUT_MCP OUT_MCR
OUT_MCT OUT_MCU OUT_MCV OUT_MHCR OUT_TTOC OUT_VAC
OUT_VSR PCSRREPT PERIOD PMACC01 PMACC02 PMAUD01
PMAUD02 PMAUD03 PMIOS01 PMIOS02 PMIOS03 PMIOS04
PMIOS05 PMLOK01 PMLOK02 PMLOK03 PMLOK04 PMSPR01
PMSQL01 PMSQL02 PMSQL03 PMSQL04 PMSTA01 PMSTA02
PMTRC01 PMTRC02 PMTRN01 POLICY PRINTIT PRINTNL
PROCESS PROFILE PRT_BCR PRT_BVR PRT_DCL PRT_DCR
PRT_DGN PRT_DSR PRT_DVL PRT_L2CR PRT_MC1 PRT_MCA
PRT_MCB PRT_MCC PRT_MCD PRT_MCM PRT_MCO PRT_MCP
PRT_MCR PRT_MCT PRT_MCU PRT_MCV PRT_MHCR PRT_TTOC
PRT_VAC PRT_VSR PSSTAT RCLASS RDCAT READDB2
READMAP READMXG READREC READSAR REAL REG
REPDATE REPLAY REPORT REPORTS RESP RPTAUSS
RPTCONSM RPTDLIR RPTDUMP RPTFILE RPTJCR RPTLDG
RPTLDR RPTLGR RPTLGS RPTLSRFR RPTLSRR RPTNQG
RPTRMG RPTTCR RPTTSR RPTXMR SCLASS SCPER
SELECT SELTM SMBVTOC SMBVVDS SORTPDB SORTPDB
SPLITCHK SPMAP SRIF SRVPOLCY STM SUMRIZE
SUMTAB TEMP TEMPDB2 TESTLONG TESTN TESTSITE
TIMEBILD TMP70PR TNDATA TNRPTD TNRPTS TRENDIT
TRNDDB2A TRNDDB2B TYP30DD TYP_HDR TYP_HDR2 UDUMPEBC
UNIXTOP USERID USERS UTILBLDP UTILCONT UTILCVRT
UTILPRIN UTILRMFI UTILXRF1 V6COMPCL V6COMPEN VAR_BCR
VAR_BVR VAR_DCL VAR_DCR VAR_DGN VAR_DSR VAR_DVL
VAR_L2CR VAR_MC1 VAR_MCA VAR_MCB VAR_MCC VAR_MCD
VAR_MCM VAR_MCO VAR_MCP VAR_MCR VAR_MCT VAR_MCU
VAR_MCV VAR_MHCR VAR_TTOC VAR_VAC VAR_VSR VAXLOOP
VAXNUM VGETDDS VGETDSN VGETENG VGETOBS VGETSORT
VMACFRYE VMSTAT VMXG2DTE VMXG344 VMXG70PR VMXGCC
VMXGCHR VMXGCICI VMXGCOMP VMXGCON VMXGDEL VMXGDKRN
VMXGDOWN VMXGDSNL VMXGDUR VMXGENG VMXGETM VMXGEXP
VMXGFOR VMXGGETM VMXGGMT VMXGGOPT VMXGINIT VMXGINV
VMXGJFCB VMXGLBIN VMXGLRC VMXGLRF VMXGLRI VMXGLRO
VMXGLRV VMXGMLST VMXGOPTR VMXGPPDS VMXGPRAL VMXGPRO
VMXGRFM VMXGRFV VMXGRMFI VMXGSET VMXGSUM VMXGTAPE
VMXGTIME VMXGTPFI VMXGUOTT VMXGUOW VMXGUOWC VMXGUOWL
VMXGUOWT VMXGUSE VMXGVBS VMXGVTOC VMXGVTOF VMXGVTOR
VMXGWORL WEEKBLD WEEKWTD WGPER WGROUP WKLDUPDT
XMINX _MTG01 _MTG02 _NDMMAKE _VRD30
Change 22.023 No Change, doc only. PCHANBY over 100% for SMF73ACR='OSD'
VMAC73 channels occurs but variable VARIED='Y' (bit 6 SMF73FG2)
Mar 4, 2004 is true in those obs. The SMF manual says for bit 6:
"Data Recorded is incorrect because channel path was
reconfigured during the interval". While I could chose
to not calculate fields, it has always been my policy to
give you whatever IBM puts in the record, so you can then
chose to keep or not to keep that observation in reports.
And, hopefully, the larger-than-100% value will cause you
to find this note, understand why, and then take actions
for your installation to delete those observations from
your reports.
Thanks to Frank DeBree, DEXIA, BELGIUM.
Change 22.022 -Variable LOSU_SEC (unweighted service units per second of
BUILD005 the hardware platform where this step executed) is kept
BUIL3005 in PDB.STEPS and PDB.JOBS.
VMAC30 -Two new service-unit-based CPU variables are created in
Mar 4, 2004 TYPE30_x, PDB.SMFINTRV, PDB.STEPS, and PDB.JOBS datasets;
so they can be compared with the SMF-recorded TCB and SRB
fields:
SRVTCBTM='SERVICE*UNIT*BASED*TCB TIME'
SRVSRBTM='SERVICE*UNIT*BASED*SRB TIME'
The CPUUNITS, SRBUNITS & LOSU_SEC are in SMF 30 records,
but the CPUCOEFF/SRBCOEFF coeffs are not. They are only
in RMF 72s, but since they almost never are changed, the
new variables use macro variables which default to ONE,
a very common weighting value. You MUST override default
coefficients, using these %LETs in IMACKEEP or //SYSIN:
%LET CPUCOEFF=10;
%LET SRBCOEFF=10;
if CPUCOEFF and SRBCOEFF in TYPE72/TYPE72GO are not one.
Note: IBM added those coefficients into the SMF 30 record
with APAR OA09118, and they will be used if that
APAR has been installed. See Change 22.341.
Cheryl Watson suggested using SU-based CPU time instead
of SMF CPU time, because SUs have more precision than the
.01-second SMF resolution, and truncation of those extra
decimal places added up to a few hours of CPU per month.
I examined 879 step records (z/OS 1.5), and did find 216
steps with SRV TCB/SRB CPU times greater than their SMF
TCB/SRB CPU times, but the max delta was only 0.0069 secs
and the "extra" SRV time, due only to truncation, was a
total of only 0.62 seconds for those 216 steps.
However, I also found there were 377 other steps that had
SMF TCB/SRB CPU time greater than SRV CPU; 38 steps had
deltas of over 1 second, and the total SMF CPU captured
was 168 seconds more than the SRV captured CPU time, so
replacing the SMF CPU with the SRV CPU seems unwise.
But what does make sense, now that I have the variables,
is to use the maximum TCB/SRB time, so any decimals that
would have been truncated won't be, creating new variable
CPUTOTTM='TOTAL CPU*MAX TCB,SRB*FROM SMF OR SU'
with this equation in SMF 30 processing:
SUM(MAX(SRVTCBTM,CPUTCBTM),MAX(SRVSRBTM,CPUSRBTM),
CPITCBTM,CPISRBTM,CPURCTTM,CPUHPTTM,CPUIIPTM);
However, remember that CPUTOTTM is COMPLETELY DEPENDENT
on you having %LET correct CPUCOEFF and SRBCOEFF values,
if your coefficients are not the MXG default of one.
-Now, see also the text of Change 22.265.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 22.021 -Job delay variables SMF30HQT/JQT/RQT/SQT should not have
VMAC30 been created in TYPE30_V,PDB.SMFINTRV,TYPE30_6 interval
Mar 3, 2004 datasets from subtype 2,3,6 type 30 records, because they
Mar 8, 2004 are job-level, and not interval-level. Their value is
Mar 12, 2004 now always set to a missing value for those records.
-TYPE30_4 dataset, those job-related variables will now be
missing except in the STEPNR=1 observation.
-TYPE30_5 dataset, those job-related variables will now be
missing if TYPETASK IN ('STC','OMVS'), as they are not
"jobs that are initiated".
-No changes were made to BUILDPDB code; those variables
are summed from their TYPE30_5 observation(s) into the
PDB.JOBS dataset, so they will be non-zero if variable
INBITS contains a "J" in the third character, indicating
that a 30-5 job termination was found for this job.
-Variable SMF30PF2, flag byte 2 is now kept.
-Jobs run under CA's JobTrack control have zeros for these
variables in their type 30-5 record, even though they are
non-zero in step records, but it is not JobTrack's error.
We now find that ANY job that has a flushed last step has
zero values for SMF30HQT/JQT/RQT/SQT in the job's SMF 30
subtype 5, even when the step records have non-zero
values; JobTrack showed up because it adds a non-executed
step at the end of every job under its control for
tracking information! The zero values, I believe, are an
IBM error in failing to propagate the values when the
last step is flushed, and a problem report will be opened
with IBM; this note will be updated when IBM replies.
Thanks to Bret Hoesly, TDS, USA.
Change 22.020 The example to create only DB2ACCT.DB2ACCT & PDB.DB2STATS
ADOCDB2 fails with ERROR: FILE WORK.SUMSTATB DOES NOT EXIST. The
Mar 2, 2004 redesign in Change 21.140 moved the interval statistics
for buffers into DB2STATB, which is now required as input
to create the desired PDB.DB2STATS summary dataset. The
example now creates DB2STATB, DB2STAT0, and DB2STAT1 so
PDB.DB2STATS can be created, but they are written to the
//WORK file, so only the two desired datasets are kept.
//SYSIN DD *
%LET PDB2ACC=DB2ACCT;
%LET PDB2ST0=WORK;
%LET PDB2ST1=WORK;
%LET PDB2STB=WORK;
%LET MACKEEP=
%QUOTE(
_NDB2
MACRO _WDB2ACC _LDB2ACC %
MACRO _WDB2ST0 DB2STAT0 %
MACRO _WDB2ST1 DB2STAT1 %
MACRO _WDB2STB DB2STATB %
MACRO _SDB2 _SDB2STB _SDB2STS %
MACRO _SDB2ACP %
MACRO _SDB2ACB %
MACRO _SDB2ACG %
MACRO _SDB2PAT %
MACRO _SDB2ST2 %
MACRO _SDB2STR %
MACRO _SDB2PST % );
%INCLUDE SOURCLIB(TYPSDB2);
RUN;
Thanks to John Croasdale, Abbey National, ENGLAND.
Change 22.019 -Variables STARTIME and DURATM are now created in each of
VMAC119 the 119 interval statistic datasets, TYP11905, TYP11906,
Mar 3, 2004 TYP119A7, and TYP119B7. There are four duration variables
in TYP11905, but all have identical values in test data,
so DURATM is set to the MAX of the four variables. Some
labels were revised and misspellings corrected. All other
TYP119xx datasets are events, rather than intervals, so
they don't contain the STARTIME/DURATM pair.
-Variable TCDURTM and UDDURTM are now divided by 4096 vice
by 496.
-Protective double question mark modifiers were inserted
before the two &NUM.3. inputs for FCLREPLY and FSLREPLY.
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.018 All references to the "SPIN" DDNAME/LIBNAME have been
ASUMTALO replaced with macro variables &SPININ or &SPINOUT, so
ASUMTAPE that input and output can be separate MVS datasets. As
BUIL3005 both macro variables default to "SPIN", this should be a
BUILD005 transparent change. This enhancement is needed by sites
JCLUOWP that run their MXG jobstream under CA's Job Scheduler,
JCLUOWV which requires separate datasets for its recoverability.
SPINSORT To use this enhancement, you would change your JCL to
VMACFRYE // EXEC MXGSASV9
VMXGINIT //SPININ DD DSN=OLDSPIN,DISP=SHR
VMXGRMFI //SPINOUT DD DSN=NEWSPIN,DISP=(,CATLG),...
VMXGUOTT and put your %LETs either in //SYSIN or in IMACKEEP:
VMXGUOW %LET SPININ=SPININ;
VMXGUOWT %LET SPINOUT=SPINOUT;
Mar 2, 2004 -These VMXGRMFI temporary datasets that should have been
deleted, now are:
MERGERMF SORINTRV MSU4HRAV SPUNRMFI MSU4HRMR
MERGEMSU MERGESOR SPUNRMFI
-Typo'd member named VMAGUOTT was discovered and deleted.
Change 22.017 FLASH: BUILDPDB (only-under"MVS") runtime elongation can
VGETENG be significant IF any output libraries (like CICSTRAN or
VMXGRMFI DB2ACCT) are on tape or in sequential format on DASD.
VMXGSUM This problem does NOT affect ITRM's normal job, because
VMXGSUME %CPPROCES/CMPROCES puts everything in //WORK, and ITRM
Mar 2, 2004 doesn't use tape libraries during its "BUILD".
Mar 12, 2004 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-vol 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( MACRO _EPDBOUT
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!
Permanent Changes made in this change:
a. VMXGRMFI. The permanent correction in this change:
- %VGETENG(DDNAME=SPIN) and ENGINE logic was removed.
- If you execute VMXGRMFI/RMFINTRV by itself, a //SPIN
DD is now required; you'll get an obvious SAS error
if you don't have one.
The test that caused this problem was added only to
prevent an abend that might happen, only if you used
RMFINTRV in a standalone job. RMFINTRV is normally
created by BUILDPDB, and a //SPIN DD has always been
provided in JCLPDBxx examples, but when the MSU4HRAV
variable was created in PDB.RMFINTRV, the history of
the last four hours was to be "spun" in SPIN.SPINRMFI
if a //SPIN DD was found. But if you ran RMFINTRV in
a standalone job that didn't have a //SPIN DD, the
MSU change would cause your "running just fine" daily
job to fail. So the VGETENG and associated logic was
added in VMXGRMFI in MXG 19.19 to protect no //SPIN.
Unfortunately, even that was also wrong. The PROC SQL
with DICTIONARY.MEMBERS sees only LIBNAMEs that are
OPEN, and BUILDPDB has not OPENed the SPIN library
when RMFINTRV is called, VGETENG set ENGINE=UNKNOWN
and so SPIN.SPINRMFI has never been created; only the
WORK.SPINRMFI has been output, and then deleted!
Fortunately, the only impact is that MSU4HRAV in
PDB.RMFINTRV has missing values for the first four
hours of each day. But since you have been wisely
using the PDB.ASUM70PR/ASUMCEC/ASUM70LP LPAR data
to measure and report "MSU" capacities, you have
never noticed nor used MSU4HRAV in PDB.RMFINTRV.
It was added for convenience when looking at a
single SYSTEM in RMFINTRV data.
Now, SPIN.SPINRMFI will always be created.
b. VGETENG: Permanent change, but VGETENG is NOT used in
VMXGRMFI with this change. Read carefully.
You can heal VGETENG's missing WHERE clause problem
by copying the member VMXGENG into member VGETENG,
and then CHANGE "VMXGENG" "VGETENG" ALL. The old
VMXGENG member does have the needed WHERE clause.
However, even with a WHERE clause, if the DDNAME is a
sequential format library, PROC SQL still must read
all of that (one) data library. And if it happens to
be a multi-volume, extended format, striped, and DASD
hardware compressed dataset; it will take time and
there won't even be mount messages to account for the
wasted time.
The VMXGENG member worked fine with its WHERE clause,
but when I standardize macro/member names that "GET"
a value to start with VGET instead of VMXG prefix, I
got a VGETENG without the WHERE clause. We would not
be having this pleasant conversation if I had used
%VMXGENG in VMXGRMFI in place of the new %VGETENG.
But since the %VGETENG is not removed from VMXGRMFI,
it really doesn't matter, now.
c. VMXGSUM, VMXGSUME: A very minor exposure to delay.
If you created your own %VMXGSUM execution that uses
TEMP01=, TEMP02=, TEMP03= arguments (DDNAMEs for temp
workspace), a PROC SQL; FROM DIRECTORY.MEMBERS is
used to find the engine, which was then set to VnSEQ,
if the fall-thru case of UNKNOWN engine is found, so
that an extended-format, hardware compressed, striped
file can be used, if that's in the DATACLAS/STORCLAS.
Since this PROC SQL does have the WHERE clause, only
the one TEMPnn DD would be read, but it would be read
once for every %VMXGSUM invocation.
But because the primary reason for TEMPnn= arguments:
to circumvent limitations back in SAS Version 6
for multi-volume temporary disk data libraries
was eliminated by SAS V8 multi-volume support, I have
removed this exposure by removing the PROC SQL and
logic for ENGINE in the VMXGSUM members. If you are
bright enough to use those specialized files that
require a sequential engine, that I believe you are
also bright enough to know that you need to add a
LIBNAME TEMPnn VnSEQ;
in your program before your %VMXGSUM invocation.
Especially since SAS will tell you if is needed!
d. Two other MXG "utility"s use FROM DICTIONARY.MEMBERS:
- VGETDDS, which you would use ahead of VMXGSET to
read multiple SAS libraries for the same dataset.
- VGETDSN, which returns the MVS DSNAME of a SAS data
library.
As both members have WHERE clauses for the LIBNAME,
so only one library would be read in any case, and as
both are optional and unlikely to be used during the
BUILDPDB process, they remain unchanged.
Thanks to Jim Poletti, Edward D. Jones, USA.
Change 22.016 The ANALSRVC report still had BY SYSTEM STARTIME for the
ANALSRVC RMF sort order, and failed with RECORDS OUT OF ORDER;
ANALPGNS BY SYSPLEX SYSTEM STARTIME has been the RMF sort order
ANALSTOR for years, but these examples had not been updated until
ADOCPDB now.
ACHAP35
XPRSMSUM
Mar 1, 2004
Thanks to Dave Crowley, Blue Cross Blue Shield of Florida, USA.
Change 22.015 Cosmetic. White space was inserted after single quotes
ANALDB2R to eliminate the SAS Version 9.1 " 49 " Warning message.
VMAC94
Feb 29, 2004
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 22.014 WebSphere SMF 120 records don't have GMT offset, and the
VMAC120 MXG algorithm was wrong, so all of the SM120xxx datetime
Feb 27, 2004 variables were wrong, if your GMT offset is non-zero.
Some were off by one-GMT-offset, some were off by two!
And SM120WAU could still be wrong, if it spans the
Spring/Fall time changes, since it can be several days
earlier than the SMFTIME of the record.
Thanks to Tom Draeger, Aurora Health, USA.
Change 22.013 -Members EXNDMIP and EXNDMSP were removed; all references
EXNDMIP to NDMIP and NDMSP were removed; the IP and SP subtypes
EXNDMQT are output in the NDMDT dataset.
EXNDMSP -Member EXNDMQT and all references to NDMQT were removed;
EXNDMTI subtype "QT" is output in NDMQE.
EXNDMUM -Member EXNDMTI and all references to NDMTI were removed;
VMACNDM subtype "TI" is output in NDMCI.
VMXGINIT -Member EXNDMUM and all references to NDMUM were removed;
Feb 26, 2004 subtype "UM" is output in NDMAE.
-Data set Label "NDM AUTHORIZATION" was revised to show
the subtypes, for severaly NDM datasets.
Thanks to Chris Weston, SAS ITRM, USA.
Change 22.012 -Variables RACFUSER & RACFTERM were reversed in MXG code.
VMACTMNT -The new subtype 6 stats record from ML-28/ML-29 caused an
Feb 26, 2004 INPUT STATEMENT EXCEEDED error; MXG expected ML-30, which
which added two new fields.
-Pending March 3: some timestamps created in ASMTAPEE are
on GMT clock, and support for a bit-changing APAR are in
development/testing.
Thanks to Tom L. White, SPRINT, USA.
Thanks to Jon Whitcomb, Great Lakes Educational Loan Services, USA.
Thanks to Normand Poitras, IBM Global Services, USA
Change 22.011 Calculation of PCTCPUBY in PDB.TYPE70PR for IRD was not
VMAC7072 correct for any engine with SMF70ONT less than DURATM.
Feb 24, 2004 The calculation of PCTCPUBY was revised to use SMF70ONT
as the denominator instead of DURATM when IRD has varied
the engine off during the interval. This only affected
the PDB.TYPE70PR dataset; both PDB.ASUM70PR and ASUMCEC
with MXG 21.05 (Change 21.170), but see Change 22.050.
Thanks to Scott Barry, SBBWorks, USA.
Change 22.010 Two typographic errors were corrected; /* before SMCASID
RMFMON instead of just /, and in the PUT statement variable name
Feb 24, 2004 IRARMCNS instead of IRAMCNS.
Thanks to Daniel T. Cannon, The Hartford, USA.
Change 22.009 Hyperspace buffers, reads, and writes variables are now
VMACMBO input and kept.
Feb 24, 2004
Thanks to Job Babcock, Bank One, USA.
Change 22.008 -The TPMX arrays were redesigned so that it is no longer
EXTYTPMX fatal to have more instances in your data than you %LET
IMACTPMX in your IMACTPMX member. A new message will be printed:
VMACTPMX ***ERROR.TPMX JBL19NN ARRAY SIZE EXCEEDED.
Feb 22, 2004 with the name "JBL19nn" of the %LET statement to change,
Feb 24, 2004 but extra instances are skipped and all records are now
Feb 25, 2004 output. New variables with the same name as the macro
Mar 11, 2004 variable are created in TYPETPMX dataset, so you can use
PROC MEANS DATA=TYPETPMX MAX; to see how many instances
were found in your data. The %LET statements in IMACTPMX
set the number of variables created in each array, and
all variables are normally kept, but you can increase the
%LET to eliminate the message, and then use the example
DROP statements in your EXTYTPMX member, if you don't
want to output that many instance variables.
-Array names were changed (since they are internal to the
VMACTPMX code) and all now match the base of the variable
name that are output; the "WHEN" values in the format are
also changed for the arrays and also match the base name.
-Format "VARNAME" values were also changed to match their
array base name.
-Bind variables were not output, but are now.
-The original count variables are still kept, to prevent a
VARIABLE NOT FOUND condition, but those variables can be
removed by uncommenting this DROP statement in EXTYTPMX:
DROP JBACTC JBAFFC JBBNDC JRBNDC JBDEAC JCAFTC JCBFRC
JLLIMC JLIMTC JBVOLC JVVOLC JBLL1C JBLL2C JBLL3C
JBLL4C JBLL5C JBLL6C JBLL7C JBLL8C JBLL9C JBL10C
JBL11C JBL12C JBL13C JBL14C JBL15C JBL16C JBL17C
JBL18C JBL19C JBL20C JBL21C JBL22C JBL23C JBL24C;
-Documentation of the syntax of the PROC FORMAT in the
IMACTPMX member was (hopefully!) improved.
Thanks to Richard S. Ralston, Humana, USA.
Change 22.007 Variable RVOLTYPE, VOLUME*TYPE*PHYSICAL*OR LOGICAL is now
VMACEDGR kept in EDGRVEXT dataset; previously it was only INPUT
Feb 18, 2004 and kept in EDGRXEXT dataset.
Thanks to Ray Bole, IBM Global Services, USA.
Change 22.006 Support for Huron/Object Star subtype 23, and corrections
EXHRN23 for subtypes 08, 11, 22, 24, 26, which could cause an
IMACHURN INPUT STATEMENT EXCEEDED error. New HURN23 dataset is
VMACHURN created. The symbol # was removed from labels; they
VMXGINIT are not needed and don't always print correctly. Huron
Feb 18, 2004 Versions R3 and R4 have been tested with this change.
Thanks to Greg Meyer, Isuzu, USA.
Change 22.005 Support for subtypes 14 thru 19 for SMF 82 CRYPTO records
EXTY8214 creates new TYPE8214 thru TYPE8219 datasets.
EXTY8215
EXTY8216
EXTY8217
EXTY8218
EXTY8219
IMAC82
VMAC82
VMXGINIT
Feb 17, 2004
Thanks to Willy Iven, Fortis Bank, BELGIUM.
Change 22.004 New variable ZTIME='ZEE DATETIME*ZEE OBS*WAS CREATED' is
IMACZDAT created and retained in member IMACZDAT, which currently
VMACEDGS creates the existing ZDATE variable. ZTIME is needed for
VMACTMS5 raw data that doesn't have a "datetime" event variable,
Feb 17, 2004 like TMS/CA-1 and DFSMS/rmm tape data that are created by
taking a "snapshot" of the tape catalog by running a job.
The new ZTIME variable can be used to detect or separate
multiple runs, and can be used for duplicate observation
detection, and can eliminate the need for ITSV sites to
tailor MXG exits.
Variable ZTIME is kept in TYPETMS5 and TYPEEDGS datasets.
Thanks to Christa Neven, KBC BankVVerzekeringsHolding, BELGIUM.
Change 22.003 Several new APPLICATION PRM METRICS are now supported and
VMACMWUX these variables created in HPUXAPPL dataset.
Feb 16, 2004 APPPRMMD='APPPRM*LOGGING*MODE*APP=0*PRM=1?'
PRMMEMUT='APPPRM*MEM*UTILIZED'
PRMSTATE='APPPRM*STATE'
PRMCPUCA='APPPRM*CPUCAP*MODE'
PRMCPUEN='APPPRM*CPU*ENTITLEMENT'
PRMMEMAV='APPPRM*MEM*AVAILABLE'
PRMMEMUP='APPPRM*MEM*UPPERBOUND'
PRMMEMEN='APPPRM*MEM*ENTITLEMENT'
Thanks to Miguel Fernandez, Information Services International, USA.
Change 22.002 -MQ Series variable WTINDXTY, index type, is now decoded
FORMATS with format MG116IN:
Feb 16, 2004 VALUE MG116IN
Feb 17, 2004 0='0:NO INDEX'
1='1:MSG_ID INDEX'
2='2:CORREL_ID INDEX'
4='4:MSG_TOKEN INDEX'
5='5:GROUP_ID INDEX'
Index type can be a critical factor in WebSphere MQ
message retrieval. With No Index, message retrieval for a
browse is sequential, and can take a long time for large
queues, since each page must be retrieved to see whether
the page contains the message of interest. With indexing
it can take only one page retrieval, and the difference
can be seconds or even minutes. If the browse is of many
messages, the difference can be "many" times the scan of
a single queue, since the queue must be scanned for each
message retrieved. And this really gets *ugly* if the
queue has spilled over to the page set on DASD.
-Labels for WQPUTPMS,WQPUT1PM are 'PERSISTENT*CREATED...'
instead of 'PERSISTENT*GOT'. MQPUT calls create messages,
MQGET calls retrieve messages (either GET-and-delete or
BROWSE). And the distinction between NON-PERSISTENT and
PERSISTENT is important because the two types should not
normally be intermingled in a queue, for performance.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA
Change 22.001 Support for MQ Series counts and times in ASG-TMON/CICS
VMACTMO2 adds four variables to MONITASK and
Feb 12, 2004 See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 11Feb04.
Thanks to Alex Nielsen,
The below Change may be required for your MXG 21.21, depending on its
internal date. Tape were copied starting Feb 6, and that edition of the
MXG 21.21 annual version need this change. But if your CHANGES in your
MXG 21.21 indicates Feb 11, 2004, then this change is already installed.
Change 21.320 MXG 21.21 final post-QA corrections/incompatibilities:
CLRMFV -SEQENGINE=V6SEQ changed to V8SEQ/V9SEQ in CONFIGV8/V9.
NOTE: SEQENGINE HAD TO BE RESET TO V6SEQ IN CONFIGV9.
in May, 2004, in Change 22.108.
CONFIGV8 See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 10Feb04.
CONFIGV9 -VMACDB2. Remove line 8259: PUT _N_= 'HAVE 239 ';
EXTMNSTS -UTILEXCL. Add a second percent-sign to change line 218 to
IMACTMNT %%INCLUDE SOURCLIB(IMACZDAT);
UTILEXCL -CLRMFV. Cosmetic. A "NOT" and EQUAL symbols slipped thru
VMAC90 and were changed to "NE"; NOTs don't translate well among
VMACDB2 platforms, and were removed back in Change 8.093
VMACTMNT -Only if you received MXG on CD: Change line 57 in member
VMXGINIT VMACTMNT, removing "DEVNR", changing the line to be:
Feb 10, 2004 MACRO _BTYSTS SYSTEM SHIFT INTBTIME %
-The CD-only VMACTMNT error was caused by my accidental
copying of support for the new TYPESTAT statistics data
from the subtype 6 ASMTAPEE ML-30 SMF record, after the
ftp and tape files were built. TYPESTAT was validated,
but I didn't use TYPSTMNT to test its sort macro. Member
EXTMNSTS was added and VMXGINIT updated for TYPESTAT and
the sort has been tested in this final iteration.
-Variables SMF9029N,SMF9029A,SMF9030I in archaic VMAC90
were renamed A, N, and Y, only in case someone foolishly
uses both VMAC90 and VMAC90A in same step. Use VMAC90A.
Thanks to George Canning, Abbey National Plc, ENGLAND.
Thanks to Vernon Kelley, IBM, USA.
LASTCHANGE: Version 22.
=========================member=CHANGE21================================
/* COPYRIGHT (C) 1984-2004 MERRILL CONSULTANTS DALLAS TEXAS USA */
Final MXG Version 21.21 is dated Feb 11, 2004, thru Change 21.320
Annual MXG Version 21.21 was dated Feb 6, 2004, thru Change 21.319
Last MXG Version 21.08 was dated Jan 28, 2004, thru Change 21.292
First MXG Version 21.08 was dated Jan 25, 2004, thru Change 21.289
Final MXG Version 21.07 was dated Dec 2, 2003, thru Change 21.247
First MXG Version 21.07 was dated Nov 30, 2003, thru Change 21.245
Final MXG Version 21.06 was dated Nov 12, 2003, thru Change 21.230
Second MXG Version 21.06 was dated Nov 10, 2003, thru Change 21.228
First MXG Version 21.06 was dated Nov 7, 2003, thru Change 21.226
MXG Version 21.05 was dated Sep 22, 2003, thru Change 21.183
First MXG Version 21.05 was dated Sep 18, 2003, thru Change 21.181
MXG Version 21.04 was dated Aug 25, 2003, thru Change 21.159
MXG Version 21.03 was dated Jul 28, 2003, thru Change 21.133
MXG Version 21.02 was dated Jun 9, 2003, thru Change 21.101.
Second MXG Version 21.02 was dated Jun 5, 2003, thru Change 21.094.
First MXG Version 21.02 was dated Jun 3, 2003, thru Change 21.091.
MXG Version 21.01 was dated Mar 24, 2003, thru Change 21.051.
Annual MXG Version 20.20 was dated Feb 7, 2003, thru Change 20.341.
MXG Newsletter FORTY-TWO was dated Feb 8, 2003.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 21.21 was shipped to all sites by Feb 13.
II. Incompatibilities and Installation of MXG 21.21.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 21.21, the Annual Version, was sent by Feb 13.
MXG 21.21 supports every new version of every new product that you are
likely to install this year, especially for MVS systems, including new
z/OS 1.5, CICS/TS 2.3, DB2 V8.1, and IMS V8.1 products, and new data
added by PTFs, and data for those releases from the monitor vendors
IBM, ASG, BMC, Candle, CA, etc. And for ASCII system there are new
objects in existing products (NTSMF, TNG) and more support for "sar"
and AIX Performance Tool for unix systems. Details provided below.
MXG 21.21 has been tested under SAS Version 9.1 and runs fine; use the
CONFIGV9 member and MXGSASV90 JCL Procedure member for z/OS execution;
for ASCII, use the current AUTOEXEC file. See Change 21.290.
And replacing your existing version of MXG is easy; as there are no
structural changes, you shouldn't have to change any of your current
MXG "Tailoring"; you build the Source Library, create/update the MXG
Format Library, change the DSNAME/DIRECTORY name to use MXG2121, and
run your acceptance test. That's all that should be required.
Major enhancements added in MXG 21.21
all 21.310 Support for z/OS 1.5.
AUTOEXEC 21.290 Option defaults changed for SAS V 9.1 for ASCII.
CONFIGV9 21.290 Option defaults changed for SAS V 9.1 for EBCDIC.
ASMTAPEE 21.304 New MXG Tape "Event" Mount/Allocate/Recvr Monitor.
TYPE120 21.294 Support for JVM Heap sizes in SMF 120 st 1 and 3.
TYPEBE97 21.312 Support for Beta97 User SMF record.
TYPEOMVT 21.311 Support for Omegamon/VTAM subtypes 29 and 30.
UNIXSAR1 21.309 Support for "sar", "acctcom", "ps" for AIX/SUN unix.
UNIXTOP 21.314 Support for "top" unix report.
DAILYDSR 21.293 Support for DFSMS/rmm+DCOLLECT in JCLDAYDS example.
EMAIL 21.308 Example to email a PROC PRINT to a list of users.
SYSLOG 21.307 Example program to read SYSLOG for job events.
Major enhancements added in MXG 21.08
SAS V9.1 21.289 Note 49-169 blanks inserted to eliminate note
TYPEDB2 21.281 Support for DB2 Version 8.1, COMPATIBLE back to 20.20
TYPE42 21.288 Support for Type 42 Subtype 10 TYPE42VS Vol Sel Fail
TYPENDM 21.286 Support more NDM/Connect Direct subtypes, 26 new dset
TYPENTSM 21.285 Support for Web Service Cache, WSRM objects.
PROCCOPY 21.279 Use MT=DATA with PROC COPY + SELECT for performance.
TYPETPMX 21.271 Major enhancement/validation of ThruPut Manager SMF
TYPETNG 21.269 Major enhancement/validation of new TNG objects.
TYPENETM 21.263 Support for UniCenter NetMaster Automate Services SMF
TYPE115 21.262 WebSphere MQ Version 5.3 SM115REL added.
TYPE116 21.262 WebSphere MQ Version 5.3 SM116REL added.
TYPEDB2 21.259 Using VMXGTIME with DB2 caused GMTOFFDB/QWACBSC wrong
BLDSMPDB 21.255 New BLDSMPDB builds SMF PDB Jobstream, weekly, etc.
VMXGINIT 21.253 Global macro variables TRENDOLD/TRENDNEW/TRENDINP.
RMFMON 21.252 Free Interactive RMF control block monitor.
TYPESASU 21.251 Support for SAS SMFEXIT adds SAS Version/User/JOBID.
ANALALL 21.250 ANALALL/ANALJOBN/VMXGPRAL job counting SMF records.
Major enhancements added in MXG 21.07
TYPEOMDB 21.243 Support for Candle Omegamon II for DB2 Historical.
TYPEOPFT 21.233 Support for Fujitsu Siemens openFT ftp SMF record.
TYPE110 21.240 Support for new S4RSP7CT in STID=124 CICS record.
TYPEMWUX 21.241 Revised support for HP Measureware for HPUX.
ASUMCICS 21.242 Protection for OPERATOR/TERMINAL variable not found.
TYPE74 21.238 Dataset TYPE74DU (RMF DUPLEX CF) was trashed.
ANALDB2R 21.239 Ability to read multiple PDBs in ANALDB2R restored.
ASUMUOTT 21.237 New ASUMUOTT combines TMDBDB2 and MONITASK datasets.
ASMRMFV 21.236 Wrong member replaced; this has change 21.186 code.
UTILBLDP 21.231 USERADD=80/90 create TYPE80A or TYPE90A execution.
Major enhancements added in MXG 21.06
ASUMUOW 21.220 FLASH: MXG 21.06 required to have all errors fixed.
TYPETSMF 21.210 Support for IBM Tivoli Storage Manager Acct Records.
TYPE102 21.175 Support for IFCIDs 217 and 254.
TYPETNG 21.160 Support for TNG Version 7 (INCOMPAT, Header changed).
TYPE99 21.217 Support for SMF 99 subtype 7 PAV Device record.
TYPE80A 21.215 Support for EKC's ETF/R FIRECALL SMF 80 data.
TYPEORAC 21.213 Support for Oracle V9.x, no changes.
TYPE110 21.212 Support for CMODNAME='MQSeries' CICSTRAN segment.
TYPE110 21.152 Support for CICS/TS 2.3 (INCOMPATIBLE)in MXG 21.05+.
TYPE80A 21.211 Support for RACF segment RACFDBP=44, new variables.
TYPECIMS 21.205 Support for Shared Message Queue Group in SMQGROUP.
TYPEEXCH 21.195 Support for Microsoft Exchange Server 5.5 Log file.
TYPE119 21.190 Support for APAR PQ77633, corrects FTPREPLY.
none 21.184 Support for 3592 Tape Drives, they look like 3590s.
TYPESYNC 21.192 Up to 255 SORTWORKs supported in z/OS 1.1 SMF record.
RMFINTRV 21.225 RMF WORKLOAD name can be used to define workloads.
TYPE70 21.170 NRCPUs in TYPE70 redefined to Average Online for IRD.
RMFINTRV 21.170 NRCPUs in TYPE70 redefined to Average Online for IRD.
TYPEDB2 21.200 Negative values for DB2TCBTM if QWACEJST small.
TYPE110 21.198 Missing value for STRTTIME in CICSTRAN possible.
VMXGSUM 21.185 New INTERVAL=SECOND now supported.
CONFIGV8 21.168 SORTSEQ=EBCDIC or SORTSEQ=ASCII forced default.
RMFINTRV 21.216 z990 CPUTYPE 2084 NOT IN TABLE with OS/390 R2.10.
TYPE6 21.210 Support for several ESS segments '34x,35x,37x,47x'.
TYPEDB2 21.208 QWACBSC/QWACESC missing in DB2ACCTP, some packages
ASUMCACH 21.197 Enhanced to keep I/O by LPAR in PDB.ASUMCACH.
TYPE110 21.189 New 110 St=1 MNSEGCL=5 caused INVALID DO LOOP CONTROL
Major enhancements added in MXG 21.05
TYPE70 21.170 NRCPUs in TYPE70 redefined to Average Online for IRD.
RMFINTRV 21.170 NRCPUs in TYPE70 redefined to Average Online for IRD.
TYPE110 21.176 New TSQUEUE SMF 110 CL 5 INPUT STATEMENT EXCEEDED.
TYPE110 21.165 STID=126 UNEXPECTED data corrected.
TYPE102 21.175 Support for IFCIDs 217 and 254.
TYPE116 21.173 Subtype 0 SMF 116 INVALID PRODUCT SECTION message.
TYPE119 21.162 IFDURTM was incorrectly divided by 496 vice 4096.
TYPETNG 21.160 Support for TNG Version 7 (INCOMPAT, Header changed).
TYPEWWW 21.166 IIS Web Log with missing fields now supported
CONFIGV8 21.168 SORTSEQ=EBCDIC or SORTSEQ=ASCII forced default.
MONTHBLD 21.163 Enhancement for un-sorted input, or NOT SORTED ERROR.
Major enhancements added in MXG 21.04
TYPE7072 21.149 Support for z990 - INCOMPATIBLE - REQUIRED.
While the support for z990s was in MXG 21.04, it was not
realized that MXG 21.04 is REQUIRED for z990s until 16Sep.
ASUM70PR 21.149 Major LPAR Measurement Enhancement: PDB.ASUM70LP.
ASMTAPES 21.137 ASMTAPES new Allocation Recovery event record.
UTILBLDP 21.148 Enhancement to the "Build your own PDB" utility.
TYPEEDGR 21.158 Support for z/OS 1.4 DFSMS/rmm EDGRXEXT (INCOMPAT)
TYPECTLL 21.156 Support for Control-D Log file.
TYPENSPY 21.155 Doc: support for NetSpy V6 or V7 in MXG 20.10+.
TYPECIMS 21.153 Support for BMC MVIMS IMF 3.3.0 (COMPAT)
TYPE120 21.150 Support for CPU Time in WASserver APAR PQ74463.
ASUMUOW 21.147 Near-constant value STRTTIME error in PDB.CICS.
TYPENTSM 21.146 Support for Windows 2003 Server MEMORY object.
TYPEHMF 21.143 Support for HMF Subtype 29,30,32,33 changes.
TYPETCP 21.142 TYPETCPS contained accumulated, not interval data.
FORMATS 21.141 $MG070CP updated for MSU for CPUTYPE 084 table.
TYPEDB2 21.140 PDB.DB2STATS QBGLxxxx wrong, negative B3HITRAT.
TYPE7072 21.138 R723Rxxx vars now kept in TYPE72DL vice TYPE72SC.
TYPENTSM 21.136 SMPTSERV for Windows 2000 had accumulated values.
ANALSTC 21.135 Report using STK SMF + MXGTMNT to track Virtual tape.
ANALDB2R 21.157 Accounting Summary Class 2 were totals, not avgs.
Major enhancements added in MXG 21.03
TYPE7072 21.130 Support for APAR OW56656 for RMF for z990 (COMPAT).
TYPE102 21.121 Support for IFCID 251, 257, corrections for 21.
TYPE103 21.115 Support for APAR PQ71799 HTTP Server SMF 103 data.
TYPE120 21.107 Support for WebSphere APAR PQ74463 - adds CPU time.
TYPETMMQ 21.129 Support for ASG-Landmark TMON for MQ Series.
TYPENDM 21.133 Support for NDM Release 4.3 (INCOMPATIBLE).
TYPEENTX 21.124 Support for EntireX user SMF accounting record.
TYPEICE 21.102 Support for STK IXFP SMF L2P00A2/LZP00A9 (COMPAT)
TYPEQACS 21.118 Support for TCP and TCPIEF objects for AS/400.
TYPEMVCI 21.117 Support for Mainview for CICS 5.6 CMRDETL (INCOMPAT).
TYPEAIX 21.116 Major revision to AIX PTX Support - new datasets.
VMXGRMFI 21.125 Different SRVCLASS definitions can map to same WORK.
Incompatible revision:
If you used ASUMCICS to read ASG-TMON/CICS MONITASK to create
PDB.CICS, you must now instead use ASUMCICT. But MXG recommends
you no longer use either ASUMCICS nor ASUMCICT, but instead you
should use ASUMUOW/ASUMUOWT to create PDB.ASUMUOW, and then create
PDB.CICS using ASUMCICX to properly measure CICS. See the
discussion in Change 21.105 text.
ASUMCICS 21.105 Reads only CICSTRAN, creates PDB.CICS, don't use.
ASUMCICT 21.105 Reads only MONITASK, creates PDB.CICS, don't use.
ASUMCICX 21.105 Reads PDB.ASUMUOW; use instead of ASUMCICS/ASUMCICT.
ASUMUOW 21.105 Combines CICSTRAN,DB2ACCT, creates PDB.ASUMUOW, use!
ASUMUOWT 21.105 Combines MONITASK,DB2ACCT, creates PDB.ASUMUOW, use!
Major enhancements added in MXG 21.02
TYPE7072 21.065 Support for more than 16 CPUs or LPARs.
TYPE74 21.058 Support for APAR OW54347 CMR Command Response time
TYPETMS5 21.097 Support for PDC # QI30130 new variables.
TYPEIMS7 21.064 Support for IMS Version 8.1, some changes.
ASMIMSL6 21.064 Support for IMS Version 8.1; just reassemble L6.
IMAC6ESS 21.082 Support for additional GPARMKY values in SMF 6 ESS.
IMAC6ESS 21.096 Support for GEPARMKY=001B.
TYPE30 21.086 Support for IDMS PerfMon type 30 subtype 3 per tran
TYPENTSM 21.063 Support for NTSMF 2.4.5 (INCOMPATIBLE).
TYPENTSM 21.053 Support for NTSMF BlackBerry Server object.
TYPETNG 21.095 Support for six new TNG objects, new fields.
EXUTILEX 21.069 Exit for UTILEXCL for non-standard "User" field.
VMXGRMFI 21.067 Examples to invoke RMFINTRV twice, general cleanup.
ASUMUOW 21.062 Revised SPINUOW logic, forward sequence of times.
ASUMUOW 21.093 Blank SYSTEM in PDB.ASUMUOW for CICS-only fixes.
TYPE102 21.061 Support for dataset T102S196 (locks) validated.
TYPE74 21.059 TYPE74ST negative values corrected, QSIZ retained.
FORMATS 21.057 RACF MG080QU,TY formats updated for z/OS 1.2-1.4.
BUILDPDB 21.056 Exit EXPDBSPJ created for local variables for spin.
UTILEXCL 21.054 Variables KY8DISTM/KY8CPUTM corrected.
MICSMXG 21.089 New member documenting MICS replacement by MXG.
Major enhancements added in MXG 21.01
ASMRMFV 21.002 Improved processing of RMF III data.
CLRMFIII 21.002 CLIST for batch execution to read all RMF III data.
DOCLRMFV 21.002 Documentation of CLRMFIII CLIST.
GRAFTRND 21.040 New plots of Peak to Average Utilization ratio.
MXGSASV8 21.009 Symbolic parm WORKVOL= added, default 5 volumes
SAS V9 21.028 Early V8-V9 comparisons flawed, V9 is better.
TYPE108 21.018 Support for Domino Server Relase 6.0.0 new data.
TYPECTLT 21.026 Support for Control-T Release 6.0/6.1(INCOMPATIBLE).
TYPEQACS 21.033 AS/400 5.2 file's LRECLs have been validated.
TYPETNG 21.024 Support for TNG "Enterprise Cubes", Processes, plus.
TYPEXAM 21.023 Support for TCP/Linux/etc, plust lots of cleanup.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
MXG New Version QA tests are executed on OS/390 & z/OS with SAS V8.2,
V9.0 and (archaic) V6.09, and on Windows 2000 & XP with V8.2 and V9.1
on Intel platforms. Additional tests have been run with SAS V8.2 on
Linux RH 7.2 on Intel, with V9.1 on Solaris v2.8 model v880, and V9.1
on HP-UX v11.11 model rp5470, confirming full compatibility. So MXG
executes under SAS V8.2 or later on every possible SAS platform!
Each new version is also tested with SAS/ITSV by ITSV development.
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.7.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2, IRD enhancements Apr 26, 2002 20.01
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
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
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003 21.04
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate Mar 31, 2004 20.20
DB2 8.1 New Data Supported Mar 31, 2004 21.08
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
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
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
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 Jul 23, 2003 21.03
Note: An asterisk before the version number indicates that this
entry was changed to a later version of MXG being required,
after it was found that the previous version did not support
the listed product level, usually the result of an APAR to
the product that modified the products data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
SAS Institute
MXG executes best under SAS Version 8.2, with 82BA77 HOTFIX for
MVS-OS/390-z/OS which includes Critical fixes; see NEWSLTRS.
It has executed succesfully under SAS Version 9 Beta on both
MVS and Windows platforms.
See Newsletters for expanded discussion of other versions.
Read member NEWSLTRS (search 'V8') for SAS Version 8 notes.
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
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
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 20.04
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 CICS/ESA 2.1 - 20.04
The Monitor for CICS/ESA 2.2 - 20.335, 21.134 21.04
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
The Monitor for MVS/ESA 3.0 - 19.19
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 CICS V500 User SMF 18.01
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
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
Amdahl
APAF 4.1, 4.3 16.08
II. Incompatibilities and Installation of MXG 21.03.
1. Incompatibilities introduced in MXG 21.06 (since MXG 20.20):
a- Changes in MXG architecture made between 21.06 and 20.20 that might
introduce incompatibilities.
ASUMCICS: If you used ASUMCICS to read ASG-LANDMARK MONITASK CICS
data to create PDB.CICS, you must now use ASUMCICT.
See Change 21.105.
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.
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.
OBSERVATION COUNT CHANGE: xxxxxxxx more/fewer observations.
This new note will be the last line of new Changes that alter the
number of observations MXG creates in dataset xxxxxxxx.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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.06:
Dataset/
Member Change Description
many 21.131 &OPSYS now consistently used in place of &SYSSCP.
many 21.289 Note 49-169 in SAS V9.1 is harmless.
none 21.310 Support for z/OS 1.5.
none 21.184 Support for 3592 Tape Drives, they look like 3590s.
ANALALL 21.250 ANALALL/ANALJOBN/VMXGPRAL job counting SMF records.
ANALDB2R 21.015 Using %ANALDB2R(PDB=SMF) caused syntax errors.
ANALDB2R 21.157 Accounting Summary Class 2 were totals, not avgs.
ANALDB2R 21.239 Ability to read multiple PDBs in ANALDB2R restored.
ANALSTC 21.135 Report using STK SMF + MXGTMNT to track Virtual tape.
ASMIMSL6 21.064 Support for IMS Version 8.1; just reassemble L6.
ASMRMFV 21.002 Improved processing of RMF III data.
ASMRMFV 21.236 Wrong member replaced; this has change 21.186 code.
ASMTAPEE 21.304 New MXG Tape "Event" Mount/Allocate/Recvr Monitor.
ASMTAPES 21.004 Using //EXCLUDE DD with highest DEVNR cause 0C4.
ASMTAPES 21.137 ASMTAPES new Allocation Recovery event record.
ASUM70PR 21.149 Major LPAR Measurement Enhancement: PDB.ASUM70LP.
ASUMCACH 21.197 Enhanced to keep I/O by LPAR in PDB.ASUMCACH.
ASUMCICS 21.105 Reads only CICSTRAN, creates PDB.CICS, don't use.
ASUMCICS 21.242 Protection for OPERATOR/TERMINAL variable not found.
ASUMCICT 21.105 Reads only MONITASK, creates PDB.CICS, don't use.
ASUMCICX 21.105 Reads PDB.ASUMUOW; use instead of ASUMCICS/ASUMCICT.
ASUMUOTT 21.237 New ASUMUOTT combines TMDBDB2 and MONITASK datasets.
ASUMUOW 21.062 Revised SPINUOW logic, forward sequence of times.
ASUMUOW 21.105 Combines CICSTRAN,DB2ACCT, creates PDB.ASUMUOW, use!
ASUMUOW 21.147 Near-constant value for STRTTIME in PDB.CICS.
ASUMUOW 21.194 Variables added to PDB.ASUMUOW
ASUMUOW 21.220 FLASH: MXG 21.06 required to have all errors fixed.
ASUMUOWT 21.035 ASUMUOWT failed with BY VARIABLES NOT SORTED.
ASUMUOWT 21.105 Combines MONITASK,DB2ACCT, creates PDB.ASUMUOW, use!
AUTOEXEC 21.290 Option defaults changed for SAS V 9.1 for ASCII.
BLDNTPDB 21.103 Relocated copying of WEEKn.
BLDSMPDB 21.255 New BLDSMPDB builds SMF PDB Jobstream, weekly, etc.
BUILDPDB 21.056 Exit EXPDBSPJ created for local variables for spin.
CLRMFIII 21.002 CLIST for batch execution to read all RMF III data.
CONFIGV8 21.168 SORTSEQ=EBCDIC or SORTSEQ=ASCII forced default.
CONFIGV9 21.290 Option defaults changed for SAS V 9.1 for EBCDIC.
DAILYDSR 21.293 Support for DFSMS/rmm+DCOLLECT in JCLDAYDS example.
DOCLRMFV 21.002 Documentation of CLRMFIII CLIST.
DOCMXG 21.132 ERROR: NO DATA SET OPEN TO LOOK UP VARIABLES cause
EMAIL 21.308 Example to email a PROC PRINT to a list of users.
EXUTILEX 21.069 Exit for UTILEXCL for non-standard "User" field.
FORMATS 21.057 RACF MG080QU,TY formats updated for z/OS 1.2-1.4.
FORMATS 21.141 $MG070CP updated for MSU for CPUTYPE 2084 table.
GRAFTRND 21.040 New plots of Peak to Average Utilization ratio.
IMAC6ESS 21.014 Multiple 6-ESS "0031" USERDATA segments supported.
IMAC6ESS 21.082 Support for additional GPARMKY values in SMF 6 ESS.
IMAC6ESS 21.096 Support for GEPARMKY=001B.
MONTHBLD 21.163 Enhancement for un-sorted input, or NOT SORTED ERROR.
MXGSASV8 21.009 Symbolic parm WORKVOL= added, default 5 volumes
PROCCOPY 21.279 Use MT=DATA with PROC COPY + SELECT for performance.
RMFINTRV 21.170 NRCPUs in TYPE70 redefined to Average Online for IRD.
RMFINTRV 21.216 z990 CPUTYPE 2084 NOT IN TABLE with OS/390 R2.10.
RMFINTRV 21.225 RMF WORKLOAD name can be used to define workloads.
RMFMON 21.252 Free Interactive RMF control block monitor.
SAS V9 21.028 Early V8-V9 comparisons flawed, V9 is better.
SAS V9.1 21.289 Note 49-169 blanks inserted to eliminate note
SYSLOG 21.307 Example program to read SYSLOG for job events.
TYPE102 21.061 Support for dataset T102S196 (locks) validated.
TYPE102 21.121 Support for IFCID 251, 257, corrections for 21.
TYPE102 21.175 Support for IFCIDs 217 and 254.
TYPE103 21.115 Support for APAR PQ71799 HTTP Server SMF 103 data.
TYPE108 21.018 Support for Domino Server Relase 6.0.0 new data.
TYPE110 21.100 CICSTRAN RTYPE='S' or 'F' decoded.
TYPE110 21.101 CPURLSTM wrong with CICS/TS 1.1 or later
TYPE110 21.165 STID=126 UNEXPECTED data corrected.
TYPE110 21.176 New TSQUEUE SMF 110 CL 5 INPUT STATEMENT EXCEEDED.
TYPE110 21.189 New 110 St=1 MNSEGCL=5 caused INVALID DO LOOP CONTROL
TYPE110 21.198 Missing value for STRTTIME in CICSTRAN possible.
TYPE110 21.212 Support for CMODNAME='MQSeries' CICSTRAN segment.
TYPE110 21.240 Support for new S4RSP7CT in STID=124 CICS record.
TYPE115 21.183 SMF 115 ST 2 INPUT STATEMENT EXCEEDED corrected.
TYPE115 21.262 WebSphere MQ Version 5.3 SM115REL added.
TYPE116 21.173 Subtype 0 SMF 116 INVALID PRODUCT SECTION message.
TYPE116 21.262 WebSphere MQ Version 5.3 SM116REL added.
TYPE119 21.162 IFDURTM was incorrectly divided by 496 vice 4096.
TYPE119 21.190 Support for APAR PQ77633, corrects FTPREPLY.
TYPE120 21.107 Support for WebSphere APAR PQ74463 - adds CPU time.
TYPE120 21.150 Support for CPU Time in WASserver APAR PQW74463.
TYPE120 21.294 Support for JVM Heap sizes in SMF 120 st 1 and 3.
TYPE30 21.086 Support for IDMS PerfMon type 30 subtype 3 per tran
TYPE42 21.010 SMF 42 offsets subtype 20,21 wrong in IBM doc, fixed.
TYPE42 21.288 Support for Type 42 Subtype 10 TYPE42VS Vol Sel Fail
TYPE6 21.210 Support for ESS segments '34x,35x,37x,47x'.
TYPE6 21.226 Support for GEPARMKY=000B in ESS, variable ESSDEFAU.
TYPE6156 21.123 Non-duplicate (Data/Index) TYPE6156 were NODUPed.
TYPE70 21.170 NRCPUs in TYPE70 redefined to Average Online for IRD.
TYPE7072 21.065 Support for more than 16 CPUs or LPARs.
TYPE7072 21.130 Support for APAR OW56656 for RMF for z990 (COMPAT).
TYPE7072 21.138 R723Rxxx vars now kept in TYPE72DL vice TYPE72SC.
TYPE7072 21.275 SMF70CIN/LPARCPUS wrong if VSAM SMF read
TYPE7072 21.287 NRCPUS=ROUND(NRCPUS,.001); for 2.00000040 value.
TYPE70PR 21.108 LPnNSW - Percent When Soft Capped variables added.
TYPE71 21.218 TYPE71 variables had AVAILABLE...USED, USED removed.
TYPE73 21.007 PCHANBY missing for 'CFS/CFP/CBP/CBS/IFP' TYPE73.
TYPE73 21.098 Some TYPE7204 "SUM OF" variables weren't.
TYPE74 21.058 Support for APAR OW54347 CMR Command Response time
TYPE74 21.059 TYPE74ST negative values corrected, QSIZ retained.
TYPE74 21.238 Dataset TYPE74DU (RMF DUPLEX CF) was trashed.
TYPE79 21.003 Variable R791FMCT needed to be multiplied by 4096.
TYPE80A 21.201 Protection for SMF80DTP=53 (RUTKN) with wrong len.
TYPE80A 21.211 Support for RACF segment RACFDBP=44, new variables.
TYPE80A 21.215 Support for EKC's ETF/R FIRECALL SMF 80 data.
TYPE85 21.104 OAM SMF 85 from R85PRVM 1.3.0 caused STOPOVER.
TYPE90 21.196 INVALID DATA FOR VERSN90 has no impact.
TYPE94 21.191 Variable SMF94VCZ recalculated when it is zero.
TYPE99 21.217 Support for SMF 99 subtype 7 PAV Device record.
TYPEAIX 21.116 Major revision to AIX PTX Support - new datasets.
TYPEBE97 21.312 Support for Beta97 User SMF record.
TYPECIMS 21.153 Support for BMC MVIMS IMF 3.3.0 (COMPAT)
TYPECIMS 21.205 Support for Shared Message Queue Group in SMQGROUP.
TYPECTLL 21.156 Support for Control-D Log file.
TYPECTLT 21.026 Support for Control-T Release 6 (INCOMPATIBLE).
TYPEDB2 21.006 Negative values in DB2STATB after stop/start DB2.
TYPEDB2 21.140 PDB.DB2STATS QBGLxxxx wrong, negative B3HITRAT.
TYPEDB2 21.187 PDB.DB2GBPST occasionally had invalid (large) values.
TYPEDB2 21.200 Negative values for DB2TCBTM if QWACEJST small.
TYPEDB2 21.208 QWACBSC/QWACESC missing in DB2ACCTP, some packages
TYPEDB2 21.259 Using VMXGTIME with DB2 caused GMTOFFDB/QWACBSC wrong
TYPEDB2 21.281 Support for DB2 Version 8.1, COMPATIBLE back to 20.20
TYPEEDGR 21.158 Support for z/OS 1.4 DFSMS/rmm EDGRXEXT (INCOMPAT)
TYPEEDGS 21.122 MACRO _LNEDGS resolves STOPOVER with rmm data.
TYPEENTX 21.124 Support for EntireX user SMF accounting record.
TYPEEXCH 21.195 Support for Microsoft Exchange Server 5.5 Log file.
TYPEHMF 21.143 Support for HMF Subtype 29,30,32,33 changes.
TYPEICE 21.102 Support for STK IXFP SMF L2P00A2/LZP00A9 (COMPAT)
TYPEIMS7 21.064 Support for IMS Version 8.1, some changes.
TYPEMVCI 21.117 Support for Mainview for CICS 5.6 CMRDETL (INCOMPAT).
TYPEMWUX 21.241 Revised support for HP Measureware for HPUX.
TYPENDM 21.133 Support for NDM Release 4.3 (INCOMPATIBLE).
TYPENDM 21.286 Support more NDM/Connect Direct subtypes, 26 new dset
TYPENETM 21.263 Support for UniCenter NetMaster Automate Services SMF
TYPENSPY 21.155 NetSpy Version 6 and 7 already supported since 20.10.
TYPENTSM 21.053 Support for NTSMF BlackBerry Server object.
TYPENTSM 21.063 Support for NTSMF 2.4.5 (INCOMPATIBLE).
TYPENTSM 21.136 SMPTSERV for Windows 2000 had accumulated values.
TYPENTSM 21.146 Support for Windows 2003 Server MEMORY object.
TYPENTSM 21.193 Variable BYTEAVAI can be zero.
TYPENTSM 21.285 Support for Web Service Cache, WSRM objects.
TYPEOMDB 21.243 Support for Candle Omegamon II for DB2 Historical.
TYPEOMVT 21.311 Support for Omegamon/VTAM subtypes 29 and 30.
TYPEOPC 21.202 INPUT STATEMENT EXCEEDED.
TYPEOPFT 21.233 Support for Fujitsu Siemens openFT ftp SMF record.
TYPEORAC 21.019 Oracle ASID, ELAPSTM corrected.
TYPEORAC 21.213 Support for Oracle V9.x, no changes.
TYPEQACS 21.013 INVALID DATA for QAPMDISK file corrected.
TYPEQACS 21.033 AS/400 5.2 file's LRECLs have been validated.
TYPEQACS 21.118 Support for TCP and TCPIEF objects for AS/400.
TYPEQACS 21.224 New QAPMCONF GDESIL/IT/PU were missing values.
TYPESARR 21.223 INPUT STATEMENT EXCEED for CA-VIEW SMF record.
TYPESASU 21.251 Support for SAS SMFEXIT adds SAS Version/User/JOBID.
TYPESYNC 21.192 Up to 255 SORTWORKs supported in z/OS 1.1 SMF record.
TYPETCP 21.142 TYPETCPS contained accumulated, not interval data.
TYPETMMQ 21.129 Support for ASG-Landmark TMON for MQ Series.
TYPETMO2 21.134 MONITASK UOW variables were incorrect.
TYPETMS5 21.097 Support for PDC # QI30130 new variables.
TYPETNG 21.024 Support for TNG "Enterprise Cubes", processes, plus.
TYPETNG 21.095 Support for six new TNG objects, new fields.
TYPETNG 21.160 Support for TNG Version 7 (INCOMPAT, Header changed).
TYPETNG 21.269 Major enhancement/validation of new TNG objects.
TYPETPMX 21.209 New fields supported.
TYPETPMX 21.271 Major enhancement/validation of ThruPut Manager SMF
TYPETSMF 21.210 Support for IBM Tivoli Storage Manager Acct Records.
TYPEWWW 21.166 IIS Web Log with missing fields now supported
TYPEWWW 21.221 Web Log INVALID ARGUMENT with negative GMT offset.
TYPEXAM 21.023 Support for TCP/Linux/etc, plus lots of cleanup.
UNIXSAR1 21.309 Support for "sar", "acctcom", "ps" for AIX/SUN unix.
UNIXTOP 21.314 Support for "top" unix report.
UTILBLDP 21.148 Enhancement to the "Build your own PDB" utility.
UTILBLDP 21.231 USERADD=80/90 create TYPE80A or TYPE90A execution.
UTILEXCL 21.054 Variables KY8DISTM/KY8CPUTM corrected.
VMACSMF 21.127 Variable INFILENM contains input DSNAME or dir/file.
VMXGINIT 21.253 Global macro variables TRENDOLD/TRENDNEW/TRENDINP.
VMXGRMFI 21.067 Examples to invoke RMFINTRV twice, general cleanup.
VMXGRMFI 21.094 Corrections to MSU4HRAV calculation.
VMXGRMFI 21.113 Parsing of more than 99 service class names.
VMXGRMFI 21.125 Different SRVCLASS definitions can map to same WORK.
VMXGRMFI 21.234 Test for '2084'x CPUTYPE, only needed S/390 R2.10.
VMXGSUM 21.185 New INTERVAL=SECOND now supported.
VMXGSUME 21.277 Enhanced alternative, tolerates non-present variables
VMXGUOW 21.093 PDB.ASUMUOW corrected, blank SYSTEM plus others.
WEEKBLDT 21.045 WEEKBLDT fails under SAS Version 6.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 21.
====== Changes thru 21.320 were in MXG 21.21 dated Feb 10, 2004=========
Change 21.320 MXG 21.21 final QA corrections/incompatibilities:
CLRMFV -SEQENGINE=V6SEQ changed to V8SEQ/V9SEQ in CONFIGV8/V9.
CONFIGV8 See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 10Feb04.
CONFIGV9 -VMACDB2. Remove line 8259: PUT _N_= 'HAVE 239 ';
EXTMNSTS -UTILEXCL. Add a second percent-sign to change line 218 to
IMACTMNT %%INCLUDE SOURCLIB(IMACZDAT);
UTILEXCL -CLRMFV. Cosmetic. A "NOT" and EQUAL symbols slipped thru
VMAC90 and were changed to "NE"; NOTs don't translate well among
VMACDB2 platforms, and were removed back in Change 8.093
VMACTMNT -Only if you received MXG on CD: Change line 57 in member
VMXGINIT VMACTMNT, removing "DEVNR", changing the line to be:
Feb 10, 2004 MACRO _BTYSTS SYSTEM SHIFT INTBTIME %
-The CD-only VMACTMNT error was caused by my accidental
copying of support for the new TYPESTAT statistics data
from the subtype 6 ASMTAPEE ML-30 SMF record, after the
ftp and tape files were built. TYPESTAT was validated,
but I didn't use TYPSTMNT to test its sort macro. Member
EXTMNSTS was added and VMXGINIT updated for TYPESTAT and
the sort has been tested in this final iteration.
-Variables SMF9029N,SMF9029A,SMF9030I in archaic VMAC90
were renamed A, N, and Y, only in case someone foolishly
uses both VMAC90 and VMAC90A in same step. Use VMAC90A.
Thanks to George Canning, Abbey National Plc, ENGLAND.
Thanks to Vernon Kelley, IBM, USA.
====== Changes thru 21.319 were in MXG 21.21 dated Feb 6, 2004=========
Change 21.319 Variables PARTNCPU and CPCMSU were added to the new
VMXG70PR PDB.ASUM70LP dataset so the hardware attributes of
Feb 6, 2004 the number of engines and MSU capacity are kept.
Feb 10, 2004
Thanks to Una Cho, CIGNA, USA.
Change 21.318 The label for DB2 variable QLACRBND should be
VMACDB2 SQL STATEMENTS*BOUND FOR*REMOTE ACCESS insteadd of
Feb 5, 2004 ... REMOVE ....
Thanks to Marnel Groebner, State of Washington, USA
Change 21.317 IBM changed the contents of SMF64BMH; its new label is
VMAC64 SMF64BMH='REQUEST HITS*FROM RLS BMF*BUFFER POOL'
Feb 5, 2004 the number or requests obtained from the local shared
buffer pool, and not the old VSAM LSR pool.
Thanks to Thomas R. Coccia, Bank One, USA.
Thanks to Hari Maramraju, Bank One, USA.
Thanks to Raymond G. Seeley, IBM OS/390 Support, USA.
Change 21.316 Updates for SMF record from Serena Ultimizer fix an INPUT
VMACULTM EXCEEDED error and revised INPUT logic have been tested
Feb 4, 2004 with Version R313, but the DSECT indicates no changes
since R310.
Thanks to Scott Barry, SBBWorks, Inc, USA
Change 21.315 PDB.TYPE70PR data with STARTIME 10:13:59 and 10:14:00
VMXG70PR caused multiple observations in PDB.ASUMCEC; the logic
Feb 4, 2004 to force STARTIME across the CEC to the nearest minute
was changed to STARTIME=60*FLOOR((STARTIME+30)/60);
and now those two observations are correctly combined.
Why the STARTIME are off by a full second in a SYSPLEX
is not known at this time. See Change 23.070 redesign.
Thanks to Alan Gray, Carefirst, USA.
Change 21.314 Support for "top" unix command in this user contribution.
UNIXTOP This member contains input for IEBUPDTE to create a PDS
Feb 4, 2004 or directory of the sample program.
This code is not yet "MXG-structured".
Comments in the members tell you what to do!
Thanks to Xiaobo Zhang, ISO, USA.
Change 21.313 Error IEC143I 213-04 on STEPLIB DD with the SAS JCL PROC,
MXGSASV8 after you have executed MXGSASVx JCL Proc, tells you to
MXGSASV9 change your SAS proc to //NULLPDS DD DISP=(NEW,DELETE),
Feb 4, 2004 to matches MXG's discovery that (NEW,DELETE) is safer for
all sites than (MOD,PASS) - see text of Change 20.076.
However, if you do NOT have CA-11, and you are not the
SAS installer, you can circumvent this error by making
//NULLPDS in MXGSASxx PROC use the archaic (MOD,PASS).
This change is doc only; nothing was changed in MXG.
Thanks to Allana Jacob, IBM CANADA LTD, CANADA.
Change 21.312 Support for Beta97 creates new datasets in this user
EXTYB970 contribution.
EXTYB972
EXTYB974
EXTYB97L
IMACBE97
VMACBE97
VMXGINIT
Feb 4, 2004
Thanks to Stephen Bell, Sparkassen Informatik, GERMANY.
Change 21.311 Support for Omegamon for VTAM subtype 29/30 additions and
VMACOMVT protection for INPUT STATEMENT EXCEEDED error, and for
Feb 3, 2004 records that are too short to contain all IRECS.
Thanks to Manfred Engelhart, Candle GmbH, GERMANY.
Change 21.310 Support for z/OS 1.5 (V 1 Release 5) is already in place
DOC in MXG 21.04 and later (required for z/OS 1.4 PTFs), so
Feb 3, 2004 no new MXG changes are required. Minor additions in data
fields that were reserved were compatibly made by IBM.
Change 21.309 Enhanced support for "sar", "acctcom", and "ps" reports
UNIXSAR1 for AIX & SUN unix platforms, in this user contribution.
Feb 3, 2004 In addition to the existing UNIXSAR example, this member
contains four SAS members and two Perl scripts that you
can use to process "sar" data. You need to install the
daemons in the SUN and AIX operating systems; collect the
data in each system, ftp or nfs the data to MXG, and then
process the sar data with the SAS programs.
This member contains input for IEBUPDTE to create a PDS
or directory of the sample program.
This code is not yet "MXG-structured".
Comments in the members tell you what to do!
Thanks to Uriel Carrasquilla, NCCI. USA.
Change 21.308 Member EMAIL previously contained examples to send an
EMAIL email from SAS; this enhancement defines %MACRO EMAIL
Feb 3, 2004 that will send a PROC PRINT of any SAS dataset via a
list of email addressees.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.307 Example program that reads z/OS SYSLOG file for specific
SYSLOG events; an excellent starting place for additional event
Feb 3, 2004 analysis. Please send your updates for other events.
This example tracks these SYSLOG events:
AQ/HQ Activate/Hold JES2 input job queue
SI/TI/PI Start/Modify/Purge Initiators
TJ Modify a job - class, scheduling environment
SJ Force a job to start, disregard class limits
T JOBCLASS Modify characteristics of a job class
Thanks to Chuck Hopf, MBNA, USA.
Change 21.306 This change was rewritten. There is no new "87F3x" flag
VMACVMXA (which was actually a typo, the value was "873Fx") and
Feb 3, 2004 MONWRITE was not changed. However, if you ftp MONWRITE
Mar 22, 2004 data, and translate it from EBCDIC to ASCII, instead of
using a BINARY ftp transfer, you will find the incorrect
0000873Fx value instead of 00008709x at the start of the
data file, and you'll get *ERROR* PROBABLE DATA LOSS DUE
TO MONWRITE FAILURE messages. Always ftp MONWRITE as
BINARY, (i.e., NOASCII NOCRLF if using IND$FILE, etc.)
Aug 20, 2004: If you send VMACCT data and translate it
from EBCDIC to ASCII, CPUMODEL='3F84'x results, which is
the cause of INVALID DATA error for a '2084'x CPU.
Thanks to Dwain Majak, ACS, USA.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch Companies, USA.
Change 21.305 UNDECLARED ARRAY REFERENCED: ICSRDQU error precedeed by
VMXGINIT an APPARENT SYMBOLIC WCICRDQ NOT RESOLVED error was due
Feb 3, 2004 to back-level VMXGINIT in tailoring that didn't define
&WCICRDQ. The text &WCICRDQ..CICSRDQU (KEEP= without
the macro var was parsed to ISCRDQU (KEEP= which
looks just like an array reference to SAS compiler.
Real purpose of this note is to suggest to always take
care of the first SAS error first, and then rerun to see
if that also took care of subsequent SAS errors during
compile of complicated programs.
Thanks to Michael Cosentino, Rohm & Haas, USA.
Change 21.304 New MXG Tape "Event" Mount/Allocate/Recovery monitor sees
ASMTAPEE all tape events, no longer samples for mounts, and gets
VMACTMNT back all of the JOB-level data lost when we gave up XMEM.
Feb 5, 2004 ASMTAPEE is a complete redesign that executes in a mount
exit in the address space of the job, so we not only see
all mount events, but no longer have to use Cross Memory
Services. The new design had one field test iteration
last year, and only one graceful failure (i.e., only an
ABEND of the monitor program, no impact to the system)
when two concurrent allocation recovery events for the
same device occurred, which is now protected.
However, please test this new design with extreme care;
this text will be updated when we have had confirmed
field tests and feed back from new users. See comments
in the ASMTAPEE member for more information.
Since ASMTAPEE will eventually replace ASMTAPES, this
is "ML-30" of the MXGTMNT program.
When MXIT=YES is used, then the mount exit monitoring is
used instead of interval sampling. MXIT=NO is default;
you must change that default to create the exit monitor.
The new MXIT=YES exit monitor (like the recently added
allocation recovery monitor logic) runs in a subtask of
MXGTMNT to keep it separate and independent. If an
unrecoverable error occurs in the MXIT=YES subtask, it
will shut itself down and switch back to using the old
interval sampling method, so that records won't be lost.
New variable TMNTFLAG='1.......'B is set in records that
are created by the new exit monitor.
The tape allocation monitoring function still uses
interval sampling.
Most of the fields that were removed when we disabled
XMEM processing are populated by the exit monitor, and
these new variables are created in TYPETMNT dataset:
ASID ='ASID'
DDNAME ='DD NAME'
DSNAME ='DSNAME NAME'
JOBCLASS='JOB*CLASS'
PGMRNAME='PROGRAMMER*NAME'
RACFGRUP='RACF*GROUP*NAME'
RACFTERM='RACF*TERMINAL*NAME'
RACFUSER='RACF*USER*NAME'
STEPNAME='STEP*NAME'
TMNTACTN ='MNTFLG: 80 04 02 01'
TMNTDEVC='DEVICE*NUMBER AS*CHARACTER'
TMNTEDUR ='EVENT*DURATION'
TMNTFLAG ='MNTFLG: 80 04 02 01'
TMNTRCN ='RELATIVE*CONCATENATION*NUMBER'
Thanks to "asmguy@mxg.com".
Change 21.303 Variable ZARCHMDE, "System is running in z/Architecture"
VMAC7072 is now kept in TYPE70 dataset, since it has been found to
Feb 2, 2004 be a useful discriminant when activating Z/Arch mode.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 21.302 DB2 SMF 102 IFCID=22 variable QW0022OS was negative when
VMAC102 the &RB.4. field contained 'FFFFFFFF'x, an invalid float
Feb 2, 2004 value. MXG now tests and detects and sets QW0022OS to a
missing value instead of -7.237E75. There is no IBM note
describing why the SQL cost was not validly populated.
Thanks to Frank d'Hoine, National Bank of Belgium, BELGIUM.
Change 21.301 Ahh, what we have to do to keep MXG running under SAS V6!
VMXGCICI VARIABLE S2ACT S2TCT IS UNINITIALIZED because their names
Jan 30, 2004 DS2ACT and DS2TCT started in column 1 of the ORDER= stmt,
and the preceding label's ending quote was in column 72,
and the V6 parsing was imperfect. Inserting a blank has
corrected this V6.09-only error, caught in our QA.
P.S. The only impact without this change was that the
real variables DS2ACT/DS2TCT had blank labels.
Thanks to Freddie Arie, TXU, USA.
Change 21.300 The calculated EXPORTIM was incorrect for hour 0; the
VMACHPAI logic was revised to protect that hour of the day.
Jan 30, 2004
Thanks to Nick Johns, Sainsburys, ENGLAND.
Change 21.299 PARTNCPU was zero for z800s running in basic mode. MXG
VMXGRMFI tested SMF70WLA, the image size, to determine what data
Jan 30, 2004 is present, because on OS/390 R2.10 or lower, SMF70WLA
was zero or missing. But when basic mode or LPAR mode is
running with OS/390 R2.10 or z/OS, SMF70WLA is populated
with the image size in MSUs. When there are no LPARS,
PARTNCPU was zero, so using CPCNRCPU=PARTNCPU was wrong.
The test was revised to use SMF70LAC, which is zero on
basic machines, but nonzero for LPARs.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 21.298 Nearly cosmetic; all variables were kept in TYPE30_4 when
ANAL30 four were needed; the MACRO _KTY30U4 V1 V2 V3 V4 % was
Jan 29, 2004 replaced with MACRO _VTY30U4 KEEP= V1 V2 V3 V4 %
Thanks to Diane Eppestine, SBC, USA.
Change 21.297 Variable ZDATE added to the list of variables kept in the
UTILEXCL PDB.CICSDICT dataset, for possible use.
Jan 29, 2004
Change 21.296 Does MXG support the VM Performance Tool Kit data file?
TYPEVMXA There is a VM Perf took kit that apparently creates its
Jan 29, 2004 own output data file, but that file is not supported in
MXG, because MXG's TYPEVMXA member supports all of the
monitor data from the IBM-supplied CMS MONWRITE command,
rather than the tool kit's subset of the monitor data.
I thought there might be an actual MONWRITE execution as
part of the tool kit's process, so that you would only
have to find and read that intermediate file,
and if you find there is one, please let me know,
or if you find there is tool kit data not in MONWRITE,
then I'll consider supporting the tool kit file,
but one user found it easier just to create a virtual
machine and run MONWRITE in it to monitor all of the VMs
on that system (including each of the Linux machines!);
His virtual machine had these directory statements:
IUCV *MONITOR MSGLIMIT 255 NAMESAVE MONDCSS
and then he can issue the "start" command:
MONWRITE MONDCSS *MONITOR DISK
command which will cause the MONWRITE records to be
copied from the monitor to this virtual machine and
written on its a-disk. Then the command
MONWSTOP
is issued to close the file and then reissue the "start"
command to start the monitor back up.
As he said, "it's crude, but it works."
Thanks to Jerry Ellis, Liberty Mutual, USA.
Change 21.295 Documentation of /VIEW limitation. This simple program
doc should read SMF type 110 records, create dataset CICSTRAN
Jan 29, 2004 as a view (to skip a write and read of CICSTRAN), and at
the same time, create all of the CICS Statistics datasets
in the //WORK file, then PROC SORT each of the CICS stats
datasets to the //PDB by the _S110ST macro, and then the
_SUOWCIC macro will PROC SORT the CICSTRAN view to create
the PDB.ASUMUOW dataset. This program fails:
%INCLUDE SOURCLIB(VMAC110,VMACSMF,IMACKEEP...);
DATA
_VAR110 /VIEW=_WCICTRN;
_SMF
_CDE110
_S110ST
_SUOWCIC
because of the /VIEW operand. Remove the /VIEW= and the
program works as expected. Why? Because the existence
of a /VIEW defers the execution of that data step until
that dataset is referenced, but the _S110ST macro starts
with PROC SORT DATA=CICAUSS, so ERROR: CICAUSS NOT FOUND
results since that dataset hasn't yet been create; what's
really confusing is that the INFILE SMF messages are not
on the log, and SMF was never opened.
However, reordering the macro references:
DATA
_VAR110 /VIEW=_WCICTRN;
_SMF
_CDE110
_SUOWCIC
_S110ST
the program works just fine, because the CICSTRAN gets
referenced first, the data step runs, and _SUOWCIC runs,
and the CICS Statistics Data Sets are SORTed at the end.
Okay, since VIEW= is for performance, putting the Sort
of CICS Stats after _SUOWCIC means those stat datasets
will be occupying //WORK space until after _SUOWCIC
ends, which might itself be a bigger performance issue
than the write/read of CICSTRAN saved with the VIEW.
An alternative that writes those CICS Statistics Data
Directly to the PDB library, without the PROC SORT, so
no duplicates will be detected, but without the extra
copy, was described in Change 18.152:
//SYSIN DD *
%INCLUDE SOURCLIB(VMAC110,VMACSMF,IMACKEEP...);
%LET CICSTAT=PDB;
_CICSTAT;
... rest of your program
Change 21.294 Support for new JVM Heap data in SMF 120 subtype 1 and 3:
EXT120SH
EXT120SR Subtype dddddd dataset description
IMAC120 1 T120SH TYP120SH server region heap
VMAC120 3 T120SR TYP120SR server region intervval heap
VMXGINIT Has been tested with only one heap per server region, so
Jan 29, 2004 have not validated with multiple heaps and code is nasty.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 21.293 Support for DFSMS/rmm + DCOLLECT in the JCLDAYDS example.
DAILYDSR The original JCLDAYDS, for "Daily Data Set Accounting"
JCLDAYDS used DCOLLECT for DASD space accounting and TMS/CA-1 for
Jan 29, 2004 tape storage; this enhancement will use IBM's DFSMS/rmm
instead of TMS for your tape storage accounting.
Thanks to Diane Eppestine, SBC, USA.
====== Changes thru 21.292 were in MXG 21.08 dated Jan 28, 2004=========
Change 21.292 Jan 26 21.08: ERROR: VARIABLE R0723AX NOT FOUND TYPE7002,
VMAC7072 when sorted; correct name is R7023AX in the _BTY7002
Jan 28, 2004 macro definition.
Thanks to Craig Loubser, Winn-Dixie, USA.
Change 21.291 If your "PDB" Data Libraries were built by V6, reusing
TYPE102 that old V6 PDB under SAS V8/9 to create MXG datasets
Jan 27, 2004 with "long length character variables", i.e, those with
"LENGTH varname $ &SASCHRLN;" in their VMACxxxx member,
like SQL text variable QW0063ST in T102S063 dataset,
will fail. You must write those V8 SAS datasets to V8
data libraries; you cannot write them to a V6 library.
Create a new data library with SAS V8, and if you need
any of the old datasets as input, the use PROC COPY to
copy from the old V6 library to the new V8 library.
In this specific case, the error that surfaced was that
variables SEG10263 and LEN10263 were missing; they were
counts of 200-byte segments of SQL text under SAS V6.
Thanks to Frank d'Hoine, National Bank of Belgium, BELGIUM.
====== Changes thru 21.290 were in MXG 21.08 dated Jan 26, 2004=========
Change 21.290 Changes in OPTIONS for SAS V9.1.
AUTOEXEC -The options for printing statistics on the SAS log have
CONFIGV9 been enabled and made consistent; benchmarks with V9.1
JCLTEST9 show there is no longer a CPU cost associated with these
MXGSASV9 options, now the default, as their informatiopn on the
Jan 27, 2004 log has been very useful in execution problem resolution.
Jan 31, 2004 -ASCII: AUTOEXEC STIMER FULLSTIMER
-EBCDIC: CONFIGV9 STIMER FULLSTIMER DLEXCPCOUNT MEMRPT
FULLSTATS
Under Windows, SAS V9.1 FULLSTIMER increased run time
by only 14 seconds in a 5 minute execution.
-New options DTRESET added to both AUTOEXEC and CONFIGV9,
to print the current date/time on the SAS log and SAS
listings (rather than the constant step initiate time on
every page!).
-See also Newsletter FOURTY-FOUR, which contains benchmark
comparisons of SAS V9.1, along with other notes
concerning using 9.1.
-The DLEXCPCOUNT option causes these messages to be on the
joblog:
12.56.18 JOB00052 +SAS processed 122 blocks and
and performed 64 EXCPs on library MXG.MONTHRPT.VOLS
====== Changes thru 21.289 were in MXG 21.08 dated Jan 25, 2004=========
Change 21.289 Execution tests with SAS Version 9.1 caused NOTE 49-169
VMAC6156 "NOTE 49-169: The meaning of an identifier after a
IMACICBB quoted string may change in a future SAS release.
VMACX37 Inserting white space between a quoted string and the
VMACEREP succeeding identifier is recommended."
ANALDB2R V9.1 fixed the 9.0 spurious 49 problem, so 9.1 notes were
ANALRMFR used to find the 7 members and 14 lines of MXG code that
ANAL94 needed a blank to be inserted to support for this future
Jan 25, 2004 SAS version now, and make these notes go away.
Because you may have similar now-non-recommended-syntax,
these are the statements that were flagged and revised.
Member Statement Text
VMAC6156 PUT '***'JOB
IMACICBB LABEL 'ID*(='23'x)'
VMACX37 IF EQ 'X37 3'OR PRODREL
VMACEREP LABEL '...('YY'X)'
ANALDB2R PUT ...text='QW0020PC' text'
PUT ...text='QW0020AN' text'
PUT ...text='QW0023PD' text'
PUT ...text='QW0024PD' text'
PUT ...text='QW0025PD' text'
ANALRMFR PUT "*"LPARNAME"*"
PUT PERIOD='PERIOD
ANAL94 PUT 'S94TVCS'GB' 3 times
Change 21.288 -Support for Type 42 Subtype 10, Volume Selection Failure'
EXTY42VS because of insufficient space when allocating a dataset
IMAC42 creates new TYPE42VS dataset.
VMAC42 -Type 42 subtype 3 TYPE42AU SMS AUDIT with SMF42EAC='VARY'
VMXGINIT needed +22 instead of +21 after SMF42ENM, causing vars
Jan 25, 2004 SMF42EVL/ESY/EST to be incorrect by one byte.
Thanks to Chris Edwards, Defence Computing Bureau, AUSTRALIA.
Change 21.287 Calculation NRCPUS=SMF70ONT/DURATM had value 2.00000040
VMAC7072 when IRD was not in use, and that fractional value had
Jan 25, 2004 impact on PCTRDYWT and CPUUPTM calculations. Calculation
now uses NRCPUS=ROUND(SMF70ONT/DURATM,.001);
to keep three decimal accuracy after that calculation.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 21.286 Enhancement to support many NDM/Connect Direct subtypes
EXNDMCS that were previously skipped, with/without log messages.
EXNDMEI All known NDMRTYPEs are now recognized and will be output
EXNDMEV in their corresponding NDMxx dataset; those for which I
EXNDMFA could find DSECTS have additional variables INPUT, and
EXNDMIP those for which I had test records have been validated.
EXNDMJX The ACCOUNT/DATASET name offsets are decoded, but the
EXNDMLS offset not yet exploited, since no one has actually asked
EXNDMMF for any of this new data; users just observed the log
EXNDMPE messages that these new types existed in their SMF data.
EXNDMPX Fully Decoded:
EXNDMQE Dataset NDMRTYPEs Output
EXNDMQT NDMPS - PS or SW
EXNDMRE NDMPX - PX
EXNDMRO NDMQE - QE QH QT QW
EXNDMS2 NDMSY - SY: NO DSECT, ADDL DATA EXISTS.
EXNDMSC NDMAE - AE DU,IU,SU,UM
EXNDMSD NDMSD - SD
EXNDMSH NDMCI - CI CE TI JI
EXNDMSP NDMDT - DT SP FT IB SS SN IS IA ID IP IF IX VP
EXNDMSY Header Only Decoded:
EXNDMTR CS FA GO IF JX LS MF NL PE PI RE RO S2 SB
EXNDMUM SC SH SY TP TR WS XO
EXNDMWS The Header Only subtypes are output, but only with header
EXNDMXO variables; MXG prints a message and hex dump of the first
IMACNDM of each new subtype, up to 10 new subtypes. If you have
VMACNDM the DSECT documentation of those Header Only subtypes,
Jan 25, 2004 please send them so I can fully decode those subtypes.
If you want to suppress those MXG messages from NDM, use:
//SYSIN DD *
%LET MACFILE= %QUOTE( RETAIN NDMNEWST 99; );
%INCLUDE SOURCLIB(TYPSNDM.... );
(or you can put that RETAIN NDMNEWST 99; in IMACFILE).
Change 21.285 New NTSMF Objects supported:
EXNTWBSC dddddd Dataset Object
EXNTWSRR NTWBSC WEBSRVCA NT WEB SERVICE CACHE
EXNTWSRC NTWSRR WSRMPRMC NT WSRM PROCESS MATCHING CRITERIA
EXNTWSRY NTWSRC WSRMPROC NT WSRM PROCESS
VMACNTSM NTWSRY WSRMPLCY NT WSRM POLICY
Jan 22, 2004 -New NRDATA=40 in Active Server Pages supported
Feb 18, 2004 -Variables CIINNAME in dataset CITRIXIN and SQBPNAME in
dataset SQLBUFPT were changed from numeric to character,
as they are Instance Name, and their original numeric
definition was wrong. If you build Week-to-Date, or
combine NTSM datasets built before and after this change,
you will get VARIABLE SQBPNAME HAS BEEN DEFINED BOTH AS
CHARACTER AND NUMERIC (or VARIABLE CIINNAME ....).
You must drop the old variable before combining the old
and new datasets.
Thanks to Terry Heim, ECOLAB, USA.
Change 21.284 TYPE99 variables S99TLPI and S99TSPI were 100 times too
VMAC99 large; they should have been input &PIB.4.2 instead of
Jan 22, 2004 &PIB.4.
Thanks to Adam Warkow, Cicigroup, USA.
Change 21.283 TYPE119 Variables UCRPORT/UCLPORT and CTLPORT/CTRPORT are
VMAC119 now kept as Port Number in numeric variables, instead of
Jan 22, 2004 the variables with suffix C (from which they are created,
but which should not have been kept).
Variables UCLLIP and NILLIP's translate statement typos
that had RIP instead of LIP were corrected.
Some labels were also revised.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 21.282 Change 21.277 created VMXGSUME to tolerate non-present
ASUMDBSB variables, but it ABENDed with several sample ASUM/TRND
ASUMHSM members that ran just fine with its predecessor design.
MNTHDB2S
MNTHDBDS In each case, the VMXGSUM arguments coded in the example
TRNDDB2S were actually in error, and the output dataset created by
VMXGSUME the old version were never correct nor as expected. but
Jan 22, 2004 the old VMXGSUM did not fail.
-ASUMDSDB had DATETIME=QWACBSC, but variable QBACBSC was
not in the SUMBY= argument list. This caused 22-322 and
180-322 errors underscoring DATETIME=&DATETIME with the
new code as only clue as to the real error.
ASUMDSDB was corrected with QWACBSC in place of QWHSSTCK
in the SUMBY.
-ASUMHSM did not create SHIFT in the INCODE for HSMINTRV,
but SHIFT was in the SUMBY, and BY SHIFT was used in the
step after than %VMXGSUM execution. The old design would
create the non-present SHIFT variable, but the design of
the revised VMXGSUM built its SUMBY without SHIFT, so the
VMXGSUM executed correctly, but then the following step
failed when it found no SHIFT variable.
ASUMHSM was corrected to create SHIFT in the INCODE, as
it did in the other steps of that example, with IMACSHFT.
-MNTHDB2S had the token "DATETIME" in the SUMBY list, and
not the correct variable name. Replaced DATETIME in the
SUMBY list with the STRTTIME variable (i.e, the variable
that was in the DATETIME= argument). However, MNTHDB2s
also had two datasteps in the INCODE=, which required a
change to VMXGSUM to support. Finally, however, because
"DATETIME" as a token in the SUMBY= list was the original
recommended syntax for %VMXGSUM, and probably is around
in lots of existing jobs, the enhanced VMXGSUM was again
enhanced, and with this revision:
If "DATETIME" string is in the SUMBY= list, and
it is NOT ALSO the DATETIME= variable name, and
the length of the DATETIME= variable name is not 0,
then the SUMBY uses the DATETIME= variable name
instead of the name DATETIME.
But because the use of "DATETIME" token in the SUMBY
is archaic, and so you know what we've done, there is
a log message that we found this archaic usage.
-MNTHDB2S - Variable QWHSSTCK not found.
-TRNDDB2S - Restructured.
Change 21.281 Support for DB2 Version 8.1, COMPATIBLE. MXG 20.20 or
VMACDB2 later will read V8 SMF 100 and 101 records without errors
Jan 21, 2004 ("MXG 20.20+ TOLERATES DB2 V8"); this change adds support
for the new fields added at the end of existing segments.
New variables in DB2ACCT:
QXCRESEQ='CREATE*SEQUENCES'
QXALTSEQ='ALTER*SEQUENCES'
QXDROSEQ='DROP*SEQUENCES'
QXPRRESI='PREPARES*RESTRICTED*PENDING*INDEX'
QXALTVW ='ALTER*VIEWS'
QLACOFF1='OFFSET TO*REST OF*TRUNCATED*QLACLOCN'
QBGAP1 ='P-LOCK*LOCK REQS FOR*SPACE MAP*PAGES'
QBGAP2 ='P-LOCK*LOCK REQS FOR*DATA*PAGES'
QBGAP3 ='P-LOCK*LOCK REQS FOR*INDEX LEAF*PAGES'
QBGAU1 ='P-LOCK*LOCK REQUESTS'
QBGAS1 ='P-LOCK*LOCK SUSPND FOR*SPACE MAP*PAGES'
QBGAS2 ='P-LOCK*LOCK SUSPND FOR*DATA*PAGES'
QBGAS3 ='P-LOCK*LOCK SUSPND FOR*INDEX LEAF*PAGES'
QBGAWS ='WRITE AND*REGISTER*WAR*REQUESTS'
New variables in DB2STATS:
QBSTLPL ='TIMES WHEN*PAGES ADDED*TO LPL'
QTGSFLMG='FALSE*CONTENTIONS*ENCOUNTERED'
Q3STHWIB='IDBACK*THREAD*HIGHWATER*MARK'
Q3STHWIF='IDFORE*THREAD*HIGHWATER*MARK'
Q3STHWCT='CTHREAD*THREAD*HIGHWATER*MARK'
-Apr 18, 2005: Version 8.1 is "almost" COMPATIBLE; some of
the data fields can be in "UNICODE UTF-8" format; an MXG
ERROR message will be printed if one is encountered, and
MXG 23.03, Change 23.082, supports QWHSLOCN in UNICODE.
-This change also inserted QBGAGG=TBGAGG to correct the
value in QBGAGG.
Thanks to Steve Cunningham, DST Systems, Inc, USA.
Change 21.280 -Variable LGMGEN was input as $EBCDIC8., but that field is
VMACPDSM actually a one byte number with range 1-99. New variable
Jan 20, 2004 LGMGENNR as numeric is now created, and LGMGEN is not.
Jan 23, 2004 -The logic for 'FF'x values and reset to blank values were
removed; that reset is needed for EBCDIC text fields, but
these fields are all $HEX formatted, so changing 'FF'x to
'40'x or '20'x is undesired.
-The FORMAT LGPSRRC LGJRC $HEX1. was changed to $HEX2., as
should be all MXG one-byte character variables containing
hex data; it makes no sense to display just the first hex
nybble. I assumed it was a typo, but a search of all of
MXG found $HEX1 in VMACXXXX, of all places, in VMACIMS,
and in XLOGREC members, which were changed to $HEX2.
However, HEX1. without the dollar-sign is validly used as
an INFORMAT for numeric variables, and was not changed.
Thanks to Peter Lines, RBS, UK.
Change 21.279 Using PROC COPY + SELECT dataset(s) to copy from a tape
DOC data library should specify MEMTYPE=DATA to minimize the
Jan 19, 2004 run time and the I/O resources. PROC COPY with a SELECT
statement without MT=DATA reads the entire tape dataset
(which could be multi-volume!!), and does not stop when
the last dataset in the SELECT list has been found.
Because PROC COPY can copy more than just datasets, it
continues to read for other entries (Graphs, Catalogs)
with the same name. By adding MT=DATA (or MEMTYPE=DATA),
SAS will stop reading the input when the last dataset has
been read, reducing CPU and elapsed time and I/O.
All PROC COPY statements in MXG that copy datasets now
have MEMTYPE=DATA or MT=DATA specified.
Change 21.278 -NTSMF Active Server Pages object has NRDATA=36, was 34,
ADOCNTSM but both new metrics are named "ASP.NET.V1.1.4322", and
EXNTIP4D added at the end of the record. Temp protection reads 34.
EXNTIP4I -Web Service object has NRDATA=86, was 81, with five new
IMACNTSM fields with "COUNTER NAME MISSING" inserted in 4 places.
VMACNTSM Temporary protection added second INPUT for know 81 vars.
VMXGINIT -Four new Objects are supported:
Jan 18, 2004 DDDDDD DATASET Object
NTASPN ASPNET ASP.NET Apps v1.1.4322
NTASPA ASPNETAP ASP.NET v1.1.4322
NTIP4D IPV4SDRV IPSEC v4 Driver
NTIP4I IPV4SIKE IPSEC v4 IKE
-Some recently added new variables, most from new objects,
were not listed in the (required) INFORMAT 16.2 list,
which would cause values to be 100 times too high.
PROC CONTENTS was used to identify those variables with
no informat and the list was updated (although there are
some counters, notably in the headers, that are integers
and correctly do not belong in the INFORMAT 16.2 list.
-Internal notes and instructions describing how to update
the MXG VMACNTSM code to add support for new object and
new variables were revised, and skeleton code examples
added to make my next revision more procedural.
Change 21.277 -VMXGSUME is an enhanced VMXGSUM, designed to tolerate
VMXGSUME dropped variables from a dataset that are expected by an
Jan 17, 2004 invocation of VMXGSUM, if a variable was in the SUMBY=
list, the VMXGSUM execution failed, or if the variable
was in one of the other lists, that variable with missing
value was created in the output dataset. This change
reads one observation of the input dataset and invokes
in INCODE argument to get the full list of all variables
that exist, and compares that with the variables in all
of the VMXGSUM arguments, and rebuilds the SUMBY=, etc.,
to use only the existing variables.
Specific example: Many sites drop OPERATOR from their
CICSTRAN dataset, but ASUMCICS has that variable in its
SUMBY= list, so previously you had to EDIT an ASUMCICS
to remove the references to OPERATOR. Now, that is
done automatically.
-Performance issues if the input dataset is on tape.
There will be multiple tape mounts on the job log; two if
KEEPALL=YES, and three if KEEPALL=NO, as we must open the
input dataset to determine variables that exist.
If this is a single-SAS-data-set tape library, the extra
mounts should not cause any delay, as only repositioning
is needed on real tape, especially if the tape is a VTS.
However, if the input tape data library contains multiple
SAS datasets, on multiple tape volumes, we must at least
open and read the data library sequentially twice to read
one observation, and then a final time to actually read
the full input dataset, and that could cause an increase
in the elapsed time.
You might consider PROC COPY; SELECT xxxxxxx; from tape
to disk before executing VMXGSUM, but initial test show
that is may not be any better, the copy must write the
full dataset with all variables, but VMXGSUM brings in
only the variables it will need, and write is much more
expensive than read.
Adding a PROC COPY step may increase, or may decrease
the execution time.
Note: This is a big performance hit, just discovered:
Always use MEMTYPE=DATA on PROC COPY with SELECT
statement from tape data libraries.
With MEMTYPE=DATA, SAS stops reading the input tape
library when it finds the last SELECTed dataset.
Without MEMTYPE=DATA, the PROC COPY doesn't know
you only want data entries, so it continues to read
the entire tape data library, because there could
be a different entry (Graphs,Catalogs,etc) with the
same name!
Because the enhanced VMXGSUM can cause errors in working
code, it is not used by default anywhere in MXG. But you
can use the enhanced macro defined in the VMXGSUME member
simply by using %INCLUDE SOURCLIB(VMXGSUME); as the first
statement in your //SYSIN stream, as that will compile
the Enhanced-but-named-the-same %VMXGSUM macro that will
be used by SAS for that job.
Change 21.276 Typos caused UNINITIALIZED VARIABLE message for WATSBACT
ANAL116 (s/b WTASBATC) and WTASPSEO (s/by WTASPSE-zero).
Jan 17, 2004
Change 21.275 Reading Active (undumped) VSAM SMF files caused TYPE70PR
VMAC7072 dataset variable SMF70CIN to be blank, which then caused
Jan 16, 2004 variables LPARCPUS, PARTNCPU, and NRIFCPU to be wrong.
The +OFFSMF (needed to read VSAM SMF transparently) was
not added to the OFFCPUID calculation.
Thanks to Melanie Hitchings, BT, ENGLAND.
Change 21.274 Protection for truncated SMF 110 record (LENGTH=76) was
VMAC110 added, testing the APS/ASS triplets before INPUTing the
Jan 15, 2004 rest of the record. Record was truncated because ACS
Jan 21, 2004 rules for Eagle tape drives forced LRECL=80, and the
ACS rule overrode the Model DSCB in the DD statement.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.273 Variable NTLIP, Local IP Address, was incorrect, typo.
VMAC119 The NTLIP=COMPRESS(NTRIP); should have been (NTLIP).
Jan 14, 2004
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 21.272 Typos corrected; MVSWAIT3=CPUWAITE is MVSWAITE=CPUWAITE
VMAC7072 and MVSWAITW=MVSWAITX is MVSWAITX=MVSWAITX twice.
Jan 12, 2004
Thanks to Hugh Lapham, RCMP, CANADA.
Change 21.271 -Enhancement decodes INSYSAF bit map to create variables
IMACTPMX JBAFF1-JBAFF32 for the System Affinities of each JOB, but
VMACTPMX you must EDIT the IMACTPMX member, which now defines two
Jan 11, 2004 formats ($MXTPMPX and $MXTPMBT) that map your SYSTEM IDs
Jan 12, 2004 to your SYSPLEXes, and that maps the bits in INSYSAF for
Jan 13, 2004 each SYSPLEX to the AFFINITY SYSTEM's name. If you do
Jan 20, 2004 not update your IMACTPMX, the values in JBAFFn variables
Jan 22, 2004 will be wrong, or more likely, always blank.
-The INPUT(INSYSAFF,$EBCDIC)/TRANSLATE statements for the
INSYSAFF were deleted: i.e., it was "un-EBCDIC'd". That
pair of functions are used only for variables containing
EBCDIC text characters. INSYSAFF contains hex bit string
data as characters, and is formatted $HEX8.
-Variables NRACCTFL and ACCOUNT1-ACCOUNT9 are now created
from the ACCT field, decoding with your IMACACCT member
that determines how many fields are actually kept. As
old variable ACCT contains both binary numbers and EBCDIC
text, it is "un-EBCDIC'd", and is formatted $HEX32.
-CURREC5, current time of day, was incorrect; it is now
input as hhmmssth in four PK1. fields, and converted to
a SAS time value and formatted TIME12.2. I created new
variable CURRENT from CURRECn, but then found it was
exactly equal to SMFTIME, so I chose to not keep CURRENT.
-Variable JALSYJ is not labeled; it appears to be the
same as SYSTEM.
-Variable RD is not labeled; it has value 'NC' in five obs
and is blank in the other five thousand observations.
-Variable RDRDATE is formatted DATE9.
-In testing, you cannot set OBS= to less than 634, because
there are 634 input records for the CNTLLIN for the token
table look up. You get TOKEN NOT FOUND with OBS=100.
-Variables JTSDATE and JTSTIME were missing because their
informats were incorrect; now they are populated.
-Variable CA7DD was incorrectly input.
-Variable CA7DT was created as a character variable, but
that field is a time duration, so variable CA7DTM is now
created as numeric and formatted. I cannot change CA7DT
from char to numeric without causing someone's perfectly
running weekly or monthly job that combines TPMX data to
ABEND due to a variable conflict, and since CA7DT was not
ever correct, it can safely be replaced by CA7DTM.
-Variables CA7JCL, CA7SCHID formatted Z3. to print 001.
-Variable CPU FORMATed TIME12.2.
-Variable CURPRIO now INPUTs only first for bits.
-Variables DISPLD1 formatted DATE9, DISPLD2 corrected.
-Variable INPRIO input BITS4.0.
-Variable INRMT is input $EBCDIC8, but the field changed
to numeric in 5.2.1; new numeric INRMTNR variable is now
created and input PIB.2., but INRMT is still created.
-Variable INSEI input $EBCDIC8 instead of 4.
-Variable JXCPUCA should have been name of JCXPUCA; both
variables now exist, but use only JXCPUCA.
-New variables JES3M26,JESM27,JES3M28 and JES3M29 were
replaced with JLSENQ, JLSENQN, JLSLIMTT and JLSLIMTN,
as they had nothing to do with JES3.
-User character variables TPMUC1-TPMUC99 and user numeric
variables TPMUN1-TPMUN99 are now supported, but none are
kept by default; you remove comments in the EXTYTPMX to
choose which user variables you want kept, and you code
LENGTH and FORMAT statements for character variables to
control their stored lengths and protect any $HEX data.
You also blank out the variable's name from the DROP code
in that member. The example also shows how you can
create variables from any binary fields in your character
fields, and how to use MACRO _KTYTPMX to also keep them.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Kelly Vogt, Humana, USA.
Change 21.270 Short CMRDETL record caused INPUT STATEMENT EXCEEDED
VMACMVCI and STOPOVER condition; test now validates the record
Jan 8, 2004 is at least 277 bytes, prints error messages and dump of
first two short records, but no longer ABENDs.
Thanks to Mike Kevlin, CSC, AUSTRALIA.
Change 21.269 -Support for many new TNG objects from AIX, NT,and SOLARIS
EXTAI013 dddddd dataset description
thru TAI013 AI013 CA CPU GROUP
EXTAI024 TAI014 AI014 CA DISK GROUP
EXTSO016 TAI015 AI015 CA FILE SYSTEM
thru TAI016 AI016 CA INTERFACE GROUP
EXTSO026 TAI017 AI017 CA KERNEL CONFIG GROUP
FORMATS TAI018 AI018 CA KERNEL GROUP
IMACTNG TAI019 AI019 CA MEMORY GROUP
VMACTNG TAI020 AI020 CA NETWORK GROUP
VMXGINIT TAI021 AI021 CA PER CPU GROUP
Jan 6, 2004 TAI022 AI022 CA SWAP GROUP
Jan 7, 2004 TAI023 AI023 PRINTER QUEUE
Jan 14, 2004 TAI024 AI024 USERS
TSO016 SO016 CA CPU GROUP
TSO017 SO017 CA DISK GROUP
TSO018 SO018 CA FILE SYSTEM
TSO019 SO019 CA INTERFACE GROUP
TSO020 SO020 CA KERNEL CONFIG GROUP
TSO021 SO021 CA KERNEL GROUP
TSO022 SO022 CA MEMORY GROUP
TSO023 SO023 CA NETWORK GROUP
TSO024 SO024 CA PER CPU GROUP
TSO025 SO025 CA SWAP GROUP
TSO026 SO026 USERS
TNT051 NT051 NTMSSQL$IN01:ACCESS ME
TNT052 NT052 NTMSSQL$IN01:BUFFER MA
TNT053 NT053 NTMSSQL$IN01:BUFFER PA
TNT054 NT054 NTMSSQL$IN01:CACHE MAN
TNT055 NT055 NTMSSQL$IN01:DATABASES
TNT056 NT056 NTMSSQL$IN01:GENERAL S
TNT057 NT057 NTMSSQL$IN01:LATCHES
TNT058 NT058 NTMSSQL$IN01:LOCKS
TNT059 NT059 NTMSSQL$IN01:MEMORY MA
TNT060 NT060 NTMSSQL$IN01:SQL STATI
TNT061 NT061 NTMSSQL$IN01:USER SETT
TNT062 NT062 NTMSSQL$IN01:BACKUP DE
NOTE: DATASETS NT051-NT062 CONTAIN DATA
FOR ALL SERVER='IN01' thru 'IN07'
Twelve MSSQL Server Objects are created for each unique
Server Name ("IN01"-"IN07"), so with 7 servers there are
84 unique objects, but only twelve datasets are needed.
Datasets NT051-NT062 contain data for all servers, with
variable SERVER="IN0n" identifying the server.
Capturing the server name from object name, and mapping
84 objects to 12 datasets required new algorithms, and
this implementation is specific to those server names.
Arrays nt063-nt134 are used for "IN02"-"IN06".
-The array sizes directly impact the REGION size needed.
Now, you can change array sizes directly with %LETs in
SYSIN, before the %INCLUDE SOURCLIB(TYPSTNG); statement.
One very large NT site, had to set:
//SYSIN DD *
%LET NT005I=21;
%LET NT007I=999;
%LET NT013I=75;
%LET NT014I=625;
%LET NT017I=625;
%LET NT035I=2000;
%INCLUDE SOURCLIB(TYPSTNG);
This works now, because all of the TNG macro variables
(MAXROWS,AInnnI,AInnnV,NTnnnI,NTnnnV,SOnnnI,SOnnnV,etc)
definition %LETs were moved to VMXGINIT and GLOBALed.
You cannot use %LET MACTNG= to redefine the array
size macro variables; you can't %LET a %LET. You can
define a MACRO _MYSIZE %%LET NT035I=2000; % and use
%LET MACTNG= _MYSIZE ; %INCLUDE SOURLIB(TYPSTNG); ,
but you cannot define MACRO _MYSIZE in your SYSIN
stream - that causes a recursion error.
-By default TYPETNG reads all cube types, and MXG default
array sizes (set so that I can read all test data sent
thus far) requires a REGION=225M. Region is NOT a real
resource, but some sites artificially constrain REGION
size. You can save some virtual storage by reading only
one cube type at a time, and also using MACTNG to specify
the _AIONLY, _SOONLY, or _NTONLY macro, to set unwanted
array sizes to a value of one.
//SYSIN DD *
%LET MACTNG= _NTONLY ;
%INCLUDE SOURCLIB(TYPSTNG);
With _NTONLY REGION=120M
With _SOONLY REGION= 66M
With _AIONLY REGION= 30M
-SAS V8.2 and MXG 21.07 defaults required REGION=100M on
z/OS 1.4; the same program used 86M Total Memory when run
with SAS V9.0 under Windows 2000.
-If there are any observations in the UNKNOWN dataset, it
means there were new objects and/or new metrics that are
not yet supported, and when there are obs in UNKNOWN, it
is possible that MXG will not output any observations
(when the last object in a group is unknown, the output
of the entire cube never occurs).
Adding support for all new objects and metrics causes the
observations to be output.
-An ARRAY EXCEEDED error messaged, because AI007V should
have been 7 instead of 2.
-Some of the new "CA.." objects have identical metrics in
both Solaris and AIX cubes, but other datasets, notably,
the SO016, 020, 021, 022, and SO023 have a different set
of variables than their AIX counterparts; always use the
variable's LABEL, and not the NAME, to match AIX data to
Solaris data in those dataset.
-Major enhancements in error detection and reporting of
array size issues were added; the number of instances
and the number of variables in your data are compared
to the array limits, and messages print which object's
value in which array is too small, and by how much.
Thanks to Ralton R. Van Heerden, CSC South Africa, SOUTH AFRICA.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 21.268 The PDB.ASUMCACH variable IORATE was wrong, because both
ASUMCACH TYPE74 and TYPE74CA datasets have a variable IORATE, and
VMAC74 both values were being summed. But in investigating the
Jan 6, 2004 error, I found that the TYPE74 IORATE variable is often
a very different value than IORATE in TYPE74CA:
In TYPE74, the SIO74CNT variable is directly used:
IORATE=SIO74CNT/DURATM; in TYPE74 dataset.
But in TYPE74CA, as there is no SIO count variable, the
I/O request counts RDREQS+WRREQS+ICLR+BPCR are added
to get the total I/O request count, SIO74CA:
IORATE=SIO74CA/DURATM; in TYPE74CA dataset.
Both SIO74CNT and SIO74CA variables are in PDB.ASUMCACH,
so you can see the differences in your own data. One test
had TYPE74 with 4,635,246, while TYPE74CA had 18,425,069.
-In VMAC74, variable SIO74CA is created in TYPE74CA data
set, for direct comparison with TYPE74 data.
-In ASUMCACH, the IORATE variable is now calculated in the
OUTCODE= argument, using IORATE=SIO74CNT/DURATM, since
the TYPE74 IORATE existed long before cache controllers,
but also, new variable IORATECA=SIO74CA/DURATM is created
so that you can compare the two I/O rates directly.
-The local variables IORATEA-IORATEZ were also removed.
Thanks to Kasandra Natzke, Infores, USA.
Change 21.267 -Syntax of the redefinition of old-style "dataset" MACRO
ASUMUOWT names _LDB2ACC _LMONTSK, _LCICTRN and _INMQ had hardcoded
VMXGUOW DDnames of DB2ACCT, MONITASK, CICSTRAN, and PDB, but now
VMXGUOWT have &PDB2ACC, &PMONTSK, &PCICTRN, and &PTY116 (&Pdddddd)
Jan 7, 2004 macro variable names for the LIBNAME/DDNAME, so they can
be easily overridden, and to be consistent.
-ERROR: OLD-STYLE MACRO NAME MUST CONTAIN ... in ASUMUOWT
was corrected by redefining each old-style macro name to
itself immediately before the %LET MACKEEP= statement.
(see Change 21.244).
-PSUUOW macro variable is no longer re-set in ASUMUOWT.
Thanks to Chris Weston, ITRM Development, USA.
Change 21.266 Calculation of CPCMSU in PDB.RMFINTRV and PDB.ASUM70PR
VMXGRMFI and PDB.ASUMCEC is now rounded to an integer, to more
VMXG70PR closely match the IBM values.
Jan 5, 2004 CPCMSU - Announced MSU alue, calculated from SMF70CPA.
CPCFNAME - MXG-created "standard" long name for the box.
SU_SEC - SRM "constant" value in SMF 72 record, changes
when the LPAR configuration is changed, cannot
be used to exactly calculate CPCMSU.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 21.265 Variable SMF70LAC (IBM's 4-hr-avg-MSU) was incorrectly
VMAC7072 output in every observation in PDB.TYPE70PR, which made
Jan 5, 2004 the LPnLAC values identical for all LPARs. This change
recognizes SMF70LAC is a "this-partition-only" value and
it is now non-missing only in PDB.TYPE70PR dataset from
the 'this-partition' records, which will correct values
of LPnLAC in PDB.ASUM70PR and PDB.ASUMCEC. However, MXG
must read the raw SMF type 70 records from each LPAR
for the LPnLAC values to be completely non-missing.
Thanks to Richard S. Ralston, Humana, USA.
Change 21.264 New utility %VGETSORT macro reads the contents of a SAS
VGETSORT data library, and, for each dataset in that library, will
Jan 5, 2004 build a macro variable that contains the member name and
the SORTEDBY variables,or UNSORTED if there is no SORTBY.
This will be used to dynamically build a WEEKBLD/MONTHBLD
process that will preserve the default sort order.
Change 21.263 Support for UniCenter NetMaster Automation Services SMF
EXNETM22 record with Event View, Resource View, and Server View
EXNETM30 Statistics creates two new datasets:
IMACNETM DDDDDD Dataset Description
TYPENETM NETM22 NETM2200 Subtype 2000, 2200 Event View
TYPSNETM NETM30 NETM3000 Subtype 3000, Resource/Service View
VMACNETM Some problems exist with datetimestamps that are under
VMXGINIT investigation, and no 2200/2000 data has been tested.
Jan 4, 2004
Thanks to Andy Creet, Defence Computing Bureau, AUSTRALIA.
Change 21.262 WebSphere MQ Version 5.3 new variables SM115REL/SM116REL
VMAC115 with Version and Release ("531") is now kept in all MQ
VMAC116 datasets. However, as there are no other changes in 5.3
Jan 3, 2004 DSECTS, except for these two new Release variables, MXG
Jan 23, 2004 21.05 or later supports MQ Version 5.3 SMF 115/116s.
-Label for QPSTDMC is now SYNC, it was incorrectly ASYNC,
a very important difference in this case, since Sync page
writes can significantly delay transactions.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 21.261 Dataset TYPE74CF could have multiple observations, when
VMAC74 more than one SMF 74 subtype 4 record was written (due to
Jan 2, 2004 a large number of structures). The MXG logic test to
output TYPE74CF included variable SMF744SN, which has
been removed, and only if the XN, GN, and PN segments are
present in this SMF 74 record will TYPE74CF be output.
Thanks to Art Cuneo, Health Care Service Corporation, USA.
Change 21.260 Macro compilation ERROR: A CHARACTER OPERAND .... is
UTILBLDP corrected; this error was introduced in Change 21.231.
Jan 2, 2004
Thanks to Scott Barry, SBBWOrks, Inc, USA.
Change 21.259 Using VMXGTIME to shift timezones caused MXG's calculated
VMACSMF GMTOFFDB GMT offset to be wrong, and so QWACBSC/QWACESC
VMACDB2H were also wrong. DB2 has no GMT offset value in the SMF
VMAC110 records, but all timestamps are on the TODCLOCK, so MXG
VMACOMCI compared SMFTIME with TODSTAMP values to create the GMT
Jan 2, 2004 offset, and then shift the DB2 timestamps to local zone.
But when VMXGTIME is enabled, the SMFTIME was shifted in
VMACSMF, before the GMT offset calculation in VMACDB2H,
causing this error. Variable UNMODSMF is now created and
it contains the un-modified SMFTIME value, and UNMODSMF
is used in VMXGDB2H to calculate the GMT Offset for DB2.
-SMFTIME was also used in the calculation of UOWTIME, to
find the FRSTBASE (epoch) of the 205-day-wrapping-clock.
While that exposure is extremely small, UNMODSMF is
also now used in that calculation.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.258 Label for variable ESFRLSAV in TYPE71 dataset revised to
VMAC71 ESTORE vice CSTORE, and ESFRLSAV=. is now set instead of
Dec 17, 2003 CSFRLSAV when ESFRLSAV is LT 0 (line 1412).
Thanks to Jennifer C. Chu, State Street Corporation, USA.
Change 21.257 Output statement for ZRBSVPP dataset was relocated to
VMACRMFV after the segment has been input, causing variables to be
Dec 17, 2003 populated.
Change 21.256 Variable CECSER now kept in PDB.TYPE70LP dataset.
VMXG70PR
Dec 17, 2003
Thanks to Hugh Lapham, RCMP, CANADA.
Change 21.255 New BLDSMPDB builds an executable "BUILDPDB jobstream"
BLDSMPDB that executes under either ASCII or EBCDIC SAS, reads an
Dec 16, 2003 SMF file to create the MXG recommended, enhanced, Daily
"SMF" PDB library, optionally copies that daily PDB to
the appropriate one-of-seven day-of-week PDBs, optionally
updates the current Week-To-Date PDB library, optionally
creates the Weekly PDB library from the seven dailies on
the first day of your week, optionally creates the
Monthly PDB on the 1st day of the month, and optionally
updates your TREND PDBs. First draft, to be revised.
This program effectively implements the suggestions in
the (still out of date documentation) ACHAP35 member.
Thanks to Joe Key, BOC, ENGLAND.
Change 21.254 Revised.
TRNDDB2A
Dec 16, 2003
Change 21.253 New GLOBAL macro variables TRENDOLD, TRENDNEW, TRENDINP
VMXGINIT default to TREND, TREND, and WEEK respectively, and will
Dec 16, 2003 be used in place of those hard-coded DDNAME/LIBNAMEs in
the MXG Trend Members.
Change 21.252 Two ways to see RMF control blocks, happy values, SU_SEC:
RMFMON one uses the LIST subcommand of the TSO TEST command,
Dec 16, 2003 a better one uses the SAS PEEK() function specifically to
display the SU_SEC value in your z/OS system.
Change 21.251 SAS has a new SMFEXIT that adds SAS Version/Release, User
VMACSASU and JOBID to the SAS User SMF record; those fields are
Dec 16, 2003 now input as variables SASVEREL, SASUSER, and SASJOBID.
The revised SMFEXITs are available from SAS Institute at:
http://ftp.sas.com/techsup/download/mvs/SMFEXIT.ASMSRC
Thanks to David Heiniluoma, Commonwealth of Massachussets, USA.
Thanks to Rich Anderson, SAS Institute, USA.
Change 21.250 -New ANALJOBN reads all job-related SMF records to count
ANALALL how many records of which type and subtype were written
ANALJOBN by each JOB, so you can track down which runaway JOB
VMXGPRAL filled your SMF file.
Dec 12, 2003 -Existing ANALALL member (prints all variables and all
Dec 15, 2003 observations for all job-related datasets created by
selected jobnames) was revised so only datasets with
JOB name are created.
-The VMXGPRAL utility (invokes PROCs PRINT or PROC MEANS
against all datasets in a SAS data library:
%VMXGPRAL(DDNAME=WORK,NOBS=50);
was enhanced with the NOFREQ= option used by ANALJOBN.
-The confusing SAS NOTE on the log when VMXGPRAL was run:
"The variable NOBS exists on an input dataset, but was
also specified on an I/OI statement option. The
variable will not be included on any output data set."
was eliminated, thanks to Charley.
Thanks to Adam Floro, Southern Illinois University, USA.
Thanks to Charley Mullin, SAS Technical Support, SAS Institute.
Change 21.249 TIC_UTIL in the NSPYTIC3 dataset was missing because the
VMACNSPY wrong time per frame variables were used in the equation.
Dec 10, 2003 Jan 17: Typo NSPYTMFS corrected to NSPVVTMFS.
Jan 17, 2004
Thanks to Steve Donahue, BCBS of Texas, USA.
Change 21.248 MWUX GLOB records with missing delimiter after the field
VMACMWUX "Process Queue Histogram" and before "Process Waiting"
Dec 5, 2003 caused INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Circumvention coded while the vendor is being contacted.
Thanks to Miguel Fernandez, Information Services International, USA.
====== Changes thru 21.247 were in MXG 21.07 dated Dec 2, 2003=========
Change 21.247 Support for MVS Solution's ThruPut Manager now supports
VMACTPMX all of the fields created as of their latest version,
Dec 2, 2003 TMT5210, adding 259 new variables to TYPETPMX dataset.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Nancy DiFilippo, MVS Solutions Inc, CANADA.
Change 21.246 Cosmetic, sort of. Text was added to two error messages
VMXGRMFI to clarify their known causes:
Dec 1, 2003
-If your workload definitions are incorrect:
***ERROR.RMFINTRV. WORKLOAD CPU TIMES DO NOT MATCH REAL CPU.
YOU HAVE CPUTM=00:30:00 REAL CPU TIME IN SMF 72, BUT HAVE
CPU72TM=00:45:00 CPU TIME IN YOUR WORKLOAD DEFINITIONS.
AT STARTIME=30NOV2003:00:02:30.00 FOR SYSTEM=SYS1.
THIS IS A SERIOUS ERROR IN YOUR TAILORING IN IMACWORK, OR
IN RMFINTRV MEMBERS. ALL OF YOUR WORKLOAD VARIABLES
(BATXXXX, TSOXXXX, CICSXXXX AND THEIR SUMS
(CPUTCBTM,CPUSRBTM,CPUHPTTM,CPU72TM) ARE WRONG.
SEE TEXT OF CHANGE 15.138.
-If MXG detects NEGATIVE UNCAPTURED CPU TIME in 70 vs 72:
*** ERROR. NEGATIVE UNCAPTURED-CPU-TIME (TYPE70-TYPE72).
*** ERROR. NEGATIVE UNCAPTURED-CPU-TIME (TYPE70-TYPE72).
*** ERROR. NEGATIVE UNCAPTURED-CPU-TIME (TYPE70-TYPE72).
FIRST: LOOK AT THE VALUES OF CPUTM AND CPU72TM, BELOW.
IF THEY ARE NOT EQUAL, THERE WAS AN EARLIER ERROR
MESSAGE: ERROR.RMFINTRV. WORKLOAD CPU TIME...
TELLING YOU THIS ERROR IS DUE TO TAILORING OF YOUR
WORKLOAD DEFINITIONS IN IMACWORK OR RMFINTRV.
THIS MESSAGE IS PRINTED HERE FOR REINFORCEMENT.
SECOND: LOOK AT THE VALUES OF CPUACTTM AND CPUEFFTM,
BELOW, IN THIS MESSAGE. IF CPUEFFTM IS MORE
THAN CPUACCTM, THEN READ APAR II10549 ABOUT
SLOW COUPLING FACILITY AND HARDWARE PROBLEMS.
YOUR CE NEEDS TO OPEN A HARDWARE PMH TO FIX.
SEARCH MXG NEWSLTRS FOR II10549 FOR MORE INFO.
THIRD: IF NEITHER, THEN YOU HAVE BAD DATA IN YOUR 70/72
RECORDS. BMC CMF PRODUCT NEEDS CMF PTF BPM6782.
IBM RMF APARS OW28256 (1997) OR OY51878 (1992).
ONLY 2 INSTANCES OF THIS MESSAGE ARE PRINTED.
READ TEXT OF CHANGE 15.238 IN MEMBER CHANGES.
*** ERROR. THIS IS A SERIOUS ERROR**********************
CPUOVHTM=-00:00:01.40
SYSTEM=PRD2 STARTIME=30NOV2003:00:30:00
CPUACTTM=0:05.22.35 CPUEFFTM=0:05:59.77
CPUTM=0:05:23.75 CPU72TM=0:05:23.75
and you can see this error was for the Second case.
Thanks to Hugh Lapham, RCMP, CANADA.
====== Changes thru 21.245 were in MXG 21.07 dated Nov 30, 2003=========
Change 21.245 Revisions to resolve errors and inconsistencies.
ASUMUOW
ASUMUOWT
ASUMUOTT
VMXGUOW
VMXGUOWT
VMXGUOTT
Nov 30, 2003
Change 21.244 Cosmetic cleanup after first MXG 21.07 QA runs:
ANALCNCR -ANALCNCR. UNINITIALIZED VARIABLE NEXTINTV/LASTINTV
VMXGTPFI messages had no impact on the results, but have been
VMACOMDB eliminated.
ANAL16 -VMXGTPFI revised to remove unneeded sorts and messages
Nov 28, 2003 about MXGSUM2.
-VMACOMDB minor revisions to remove duplicate variables in
FORMAT statement, and $CHAR instead of $EBCDIC for $HEX.
-ANAL16 following INCLUDE of TYPE16 failed with message
ERROR: OLD-STYLE MACRO NAME MUST CONTAIN ONLY LETTERS.
because ANAL16 used %LET MACKEEP to redefine old-style
macros. Redefinition (MACRO _KTY16 _KTY16 %) inserted
ANAL16 before the %LET MACKEEP re-definition, as noted in
the DOCMXG comments related to use of %LET MACKEEP.
Change 21.243 Support for Candle Omegamon II for DB2 Historical D2540
EXDB0010 file creates 312 new datasets, based on the SAS code that
...310 more Candle provided with the product. This iteration
EXDB3370 supports DB2 V7.1; only forty-two of the datasets have
IMACOMDB been populated with observations, and only cursory
TYPEOMDB validation of formats, labels, etc., has been completed.
TYPSOMDB
VMACOMDB
Nov 24, 2003
Change 21.242 JCLTEST8 fails with VARIABLE OPERATOR NOT FOUND if your
ASUMCICS CICS guru has Excluded OPERATOR or TERMINAL from CICSTRAN
JCLTEST8 dataset, because those two variables are historically in
Nov 24, 2003 in the default SUMBY list in MACRO _BSUCICS.
- See Change 21.105: We no longer recommend ASUMCICS be
used, since it summarizes transaction segments instead
of unit-of-work transactions.
Instead, you should create PDB.ASUMUOW and then use the
ASUMCICX program to create PDB.CICS summary dataset:
%INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);
(and you need to tailor IMACUOW - read its comments).
- You should always use ASUMUOW, even if you don't have
DB2 data, to combine CICS MRO segments together to get
correct TRANNAME, etc. If you do not create the
PDB.DB2ACCT dataset, you can create a zero-observation
DB2ACCT dataset to satisfy ASUMUOW, using:
OPTIONS OBS=0;
%INCLUDE SOURCLIB(TYPEDB2);
RUN;
OPTIONS OBS=MAX;RUN;
&INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);
- If you still must create PDB.CICS from CICSTRAN, you
can re-define the old SUMBY list "instream":
//SYSIN DD *
%LET MACKEEP=
MACRO _BSUCICS APPLID USER STRTTIME TRANNAME
SYSTEM SHIFT %
;
%INCLUDE SOURCLIB(ASUMCICS);
to remove the OPERATOR and TERMINAL variables.
- But so you don't get blindsided during testing with my
defaults,
One site with excluded fields had never used ASUMCICS
but their "clean running" JCLTEST8 job failed.
this change added "compiler fakers' in ASUMCICS to
create one-byte OPERATOR/TERMINAL variables when they
do not exist in your CICSTRAN.
Jan 25, 2004 Update: You can now use the VMXGSUME member
created in Change 21.277, and not have to modify ASUMCICS
or ASUMUOW to deal with dropped variables.
Change 21.241 Revised support for Hewlett Packards MeasureWare for HPUX
VMACMWUX now a/k/a OVPA.
Nov 22, 2003 -DISKKBYT,KBYTRATE,PREADKBS,PWRITKBS are mult by 1024.
-GLOBAL Transaction variables no input by default
-The REPORT ALL command in ADOCMWUX is the command to use
that creates the MXG-expected data fields.
-Many TRAN fields were removed as they are not in the HP
default REPTALL, and I had no test data to validate with.
Thanks to Tony P. Steward, Royal Mail, ENGLAND.
Thanks to Miguel Fernandez, Information Services International, USA.
Change 21.240 Support for new S4RSP7CT in STID=124 CICS Statistics data
VMAC110 record. Caused "FOUND WITH SKIPPED FIELDS" warning with
Nov 21, 2003 STID=124,SKIP=4,STILEN=120, but no error.
Thanks to Tim Vanderhoek, Fidelity Systems, USA.
Change 21.239 The ability to read multiple PDB libraries was lost in a
ANALDB2R prior change, but has been restored, so you can again use
Nov 20, 2003 the documented syntax PDB=MON TUE WED THU FRI SAT SUN,
to read multiple PDBs as input to ANALDB2R.
Thanks to Bill Bonfitto, MassMutual Financial Group, USA.
Change 21.238 Dataset TYPE74DU (RMF DUPLEX COUPLING FACILITY) was trash
VMAC74 because the offset SMF744RO is unlike other RMF offsets.
Nov 20, 2003 It is from the first data byte and not from the RDW, so
SMF744RO=SMF744RO-3 used to calculate the byte location
had to be deleted. And with data to look at, the two sum
of squares R744RSSS and R744RSSD are actually &PIB.8 and
not the &RB.8 that I had assumed.
Thanks to Tom Draeger, Aurora Health Care, USA.
Change 21.237 New ASUMUOTT member creates new PDB.ASUMUOTT from the
ASUMUOTT ASG-Landmark DB2 TMDBDB2 dataset and ASG-Landmark CICS
EXTMDDB2 MONITASK dataset. The output is named PDB.ASUMUOTT,
IMACUOTT even though it is logically the same as PDB.ASUMUOW,
JCLUOTT because the TMDBDB2 variable names are used instead of
VMACTMDB the DB2ACCT names.
VMXGUOTT -Member VMACTMDB was modified to create the DB2PARTY
Nov 19, 2003 variable, to identify DB2 Parallel event records (see
Nov 30, 2003 Change 14.287).
Formats MGDB2RC and MGDB2LM applied to RINV/PREC vars.
All ACE vars are now all numeric, $HEX8. &MXGBYLN.
All /4096 are now formatted TIME12.2.
-Member EXTMDDB2 was revised to use DB2PARTY to delete
events that should not be output (see Change 19.027).
-Member JCLUOTT is a standalong example to read the raw
TMON CICS and TMON DB2 files to create PDB.ASUMUOW.
-Member VMACDB2, variable QWACLRAB now formatted MGBYTES.
Nov 30:
New member ASUMUOWT and VMXGUOWT created to support the
combination of MONITASK.MONITASK and DB2ACCT.DB2ACCT.
Thanks to Hamid Tavakolian, CSC, USA.
Change 21.236 The ASMRMFV member in MXG 21.06 was an earlier iteration
ASMRMFV that did not include the enhancements in Change 21.186.
Nov 18, 2003 I copied the wrong member into the source library. The
ASMRMFV at Change 21.236 dated Nov 18, 2003 (or later)
contains that major revision to the ASM program for the
RMF III VSAM data; Change 21.228 added VMACRMFV support.
Change 21.235 Variable CPCFNAME, the CPC FULL NAME (2064216) created in
VMXG70PR PDB.RMFINTRV, is now also created in PDB.ASUM70PR and in
Nov 18, 2003 PDB.ASUM70LP datasets.
Thanks to Kenneth D. Jones, xwave, CANADA.
Change 21.234 Test for '2084'X added, but only needed if OS/390 R2.10
VMXGRMFI with SMF70WLA=. (i.e., do not have the APAR that added
Nov 18, 2003 SMF70WLA installed) is running on a z990.
Change 21.233 Support for Fujitsu Siemens openFT file transfer propgram
FORMATS user SMF record creates new OPENFT dataset for each SMF
EXOPENFT event record.
IMACOPFT
TYPEOPFT
TYPSOPFT
VMACOPFT
VMXGINIT
Nov 17, 2003
Thanks to Wolfgang Prescher, Itellium, GERMANY
Change 21.232 Replaced change.
Change 21.231 Now, USERADD=80 USERADD=90 cause the TYPE80A or TYPE90A
UTILBLDP code to be generated, and not TYPE80 nor TYPE90, which
Nov 17, 2003 were replaced by their "A" counterparts. MXG's original
logic for RACF TYPE80 and OPERATOR COMMAND TYPE90 created
one TYPE80/TYPE90 dataset with hundreds of variables; the
"A" replacements create many TYPE80nn/TYPE90nn datasets,
one for each event with only that event's variables kept.
You can see what events occurred, just by looking at the
non-zero observation counts for each dataset on the log.
Previously: "USERADD=90," created obs in TYPE90, but
"USERADD=90 90A," generated both _CDE90 and _CDE90A
segments, and that first ELSE IF ID=90 ... in _CDE90
prevented _CDE90A from being executed, so there were
never any obs in any of the TYPE90nn datasets.
Thanks to Gadi Ben-Avi, Malam Systems Ltd, ISRAEL.
====== Changes thru 21.230 were in MXG 21.06 dated Nov 12, 2003=========
Change 21.230 SAS V6 Only. OUT OF MEMORY error with MXG 21.04+ because
VMXGCICI the ORDER= argument "clean up" by Change 21.152 increased
Nov 11, 2003 the number of lines which exceeded the maximum size of a
SAS V6 macro argument. Compacting the lines reduced the
total bytes and the code now executes under V6 or V8+.
Thanks to Kelvin Wells, ScaleOn GmbH, GERMANY.
Change 21.229 -Variable CPUTM=SUM(PRODTCB,PRODSRB) added to TYPE89 data
VMAC89 set for consistency; MXG datasets with multiple CPU Time
Nov 11, 2003 measurements were intended to always have variable CPUTM
as the total, unoverlapped, billable, etc., CPU time, but
TYPE89 was overlooked.
Thanks to Jake M. Drew, MBNA, USA.
====== Changes thru 21.228 were in MXG 21.06 dated Nov 10, 2003=========
Change 21.228 Support for RMF III ASMRMFV data added by Change 21.186.
EXZRBCFI - CFI segment creates ZRBCFI dataset
EXZRBRCB - RCD segment creates multiple datasets:
EXZRBRCD ZRBRCB ZRBRCDB RMFIII RESPONSE TIME BUCKETS
EXZRBRCP ZRBRCS ZRBRCDS RMFIII SERVICE CLASS
EXZRBRCR ZRBRCR ZRBRCDR RMFIII REPORT CLASS
EXZRBRCS ZRBRCP ZRBRCDP RMFIII PERIOD
EXZRBRCT ZRBRCT ZRBRCDT RMFIII RESPONSE TIME COUNTS
EXZRBSVC ZRBRCD ZRBRCDD RMFIII SUBSYSTEM DELAY
EXZRBSVG - SVP segment creates multiple datasets:
EXZRBSVP ZRBSVP ZRBSVPP RMFIII SERVICE POLICY
EXZRBSVR ZRBSVW ZRBSVPW RMFIII SERVPOLICY WORKLOAD DEFN
EXZRBSVW ZRBSVC ZRBSVPC RMFIII SERVPOLICY SRVCLASS DEFN
EXZRRSVZ ZRBSVZ ZRBSVPZ RMFIII SERVPOLCY SRVCLASS PERIOD
IMACRMFV ZRBSVR ZRBSVPR RMFIII SERVPOLICY REPORC CL DEFN
VMACRMFV ZRBSVG ZRBSVPG RMFIII SERVPOLICY RESOURCE GROUP
VMXGINIT - UWD segments produce warnings (first five) that will
Nov 9, 2003 will be investigated, and only cursory validation of
all of the new data has been accomplished. Some back
end merges/unions may be necessary, and/or there may
be some variables that need to be carried forwared,
but that awaits someone who really wants to use these
new data segments, but lots of the data is already in
the TYPE7xxx RMF Monitor I data.
Change 21.227 Final Cleanup after full QA runs:
ANALDBTR -ANALDBTR updated to include all pairs datasets; I183R183
ANALDB2R was changed to S183S183 for consistency in pair names.
CONFIG -Archaic CONFIG member for SAS V6 specifies MEMSIZE=128M.
JCLTEST6 -VMAC6,IMAC6ESS ESSPIMSG/ST spellings corrected, all vars
IMAC6ESS in DROP and KEEPs.
VMAC6ESS
Nov 8, 2003
Thanks to Freddie Arie, TXU, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA
====== Changes thru 21.226 were in MXG 21.06 dated Nov 7, 2003=========
Change 21.226 Support for GEPARMKY=000B in Extended SMF 6 ESS data now
IMAC6ESS creates ESSDEFAU variable if IMAC6ESS is enabled to
VMAC6 decode those optional ESS data fields.
Nov 7, 2003
Thanks to Engelbert Smets, Provinzial Rheinland Versicher, GERMANY
Change 21.225 -PDB.RMFINTRV workload definitions can now be based on the
VMXGRMFI WORKLOAD name, variable WKLDNAME, instead of a long list
Nov 7, 2003 of Service Class Names, by this enhancement that adds an
eight value to the WORK= argument.
Caveats: USECNTRL must be YES or GOAL, or nothing will
be found. And if you mix up workloads, service
classes, and reporting classes, the UTILRMFI
can't help you figure out what you've done wrong
because WORKLOAD doesn't exist in TYPE30 SMF.
-The SPIN logic to detect existence was enhanced.
-Note that if both SRVCLASS and WORKLOAD are specified,
that WORKnn workload will include all observations that
match either the SRVCLASS or the WORKLOAD names, so you
must be careful to avoid any overlap.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Thanks to ??? who actually asked for it earlier. Identify yourself.
Change 21.224 New QAPMCONF variables GDESIL/GDESIT/GDESPU were missing
VMACQACS values because they were not in the RETAIN statement, and
Nov 6, 2003 the configuration file has one record per parameter; all
Nov 10, 2003 GDESxxxx variables are now RETAINed.
-New variables GDESIL/GDESIT/GDESDL/GDESDT had incorrect
values; they are now input as PIB2.1 instead of PIB4.1;
I misread the OS/400 description of B(4,1) as being a
four byte field.
-New variable GDES18 decodes the GDESKEY='18' record.
-Variables GDESAP and GDESAT are addresses, and are now
formatted as MGBYTES (so they print 255G for 255 GBytes).
-Variable GDESI, interval value, was multiplied twice by
60, causing an incorrect value.
Thanks to Jim Wertenberger, Antares Management Solutions, USA.
Thanks to Al Kadowaki, IBM Corporation, USA.
Change 21.223 CA-VIEW TYPESARR user SMF records caused INPUT STATEMENT
VMACSARR EXCEEDED RECORD LENGTH error because MXG used $VARYING40.
Nov 6, 2003 but one instance had 45 characters. Now use $VARYING80.,
and protection was added if the text length is greater
than 80. Then I realized these character variables were
not even output (probably because I didn't have any data
with index data), so the subtype 30/31 datasets now have
variables SV30/31INAM,SV30/31IVAL,SV30/312VAL,SV30/313VAL
with the Index name and the first three index values.
Thanks to John Rivest, TDS, USA.
Change 21.222 SAS Version 6 ERROR 29-185 WIDTH INVALID $EBCDIC255 when
VMAC102 MXG was executed under SAS V6, which limited character
VMAC110 variables to 200 bytes. While execution under SAS V8.2
VMXGINIT or later is STRONGLY RECOMMENDED, it was my intention to
Nov 3, 2003 support execution under V6 for all of the "standard" code
Nov 27, 2003 members, so this oversight was corrected with a new macro
variable &EBC255 that will input $EBCDIC200. +55 for V6.
These new products require execution under SAS V8:
TYPEAIX - AIX Performance Tool
TYPETMTC - TMON ASG-Landmark TCP/IP monitor
TYPEWWW - Web Logs
TYPEOMDB - Omegamon II for DB2 Historical File
-In addition, a $VARYING250 in VMAC102 was changed to only
read in the first 200 bytes with $VARYING200.
Thanks to Kevin Wells, ScaleOn Gmbh & Co KG, GERMANY.
Change 21.221 -MXG Web Log processing of data with negative GMT offset
VMACWWW caused INVALID ARGUMENT messages, and causing variable
Oct 31, 2003 GMTOFFTM to be missing, but ENDTIME was correct.
Nov 5, 2003 -ELAPSTM was missing value in IIS logs due to typo, and
is now formatted TIME8.
Thanks to Robert Gauthier, Albertsons, USA.
Change 21.220 FLASH: MXG 21.07 is required for PDB.ASUMUOW to have all
ASUMCICX reported errors fixed. If you use JCLUOWV from an
ASUMUOW earlier MXG version, or use VMXGUOW, ASUMUOW, ASUMUOWT on
ASUMUOWT Landmark MONITASK data to build PDB.ASUMUOW, you're at
JCLUOWP risk of having incorrect data, like missing values for
JCLUOWV STRTTIME, or your perfectly running BUILDPDB can ABEND
VMACTMO2 with DATASET DB2ACCT NOT SORTED or with the VARIABLES NOT
VMXGUOW FOUND error condition. We have had a series of
Oct 30, 2003 architectural revisions to correct the sort sequence for
Nov 30, 2003 LU 6.2 transactions, and corrections to that redesign,
and restructured into ASUMUOW for IBM CICSTRAN and
ASUMUOWT for ASG MONITASK data, to eliminate double
mounts of tape libraries, and only now does it appear
we've fixed everything or at least documented that you
must use the JCLUOWV or JCLUOWP members from MXG 21.06,
due to these changes:
Change 21.194 - Added Variables
Change 21.147 - Populated STRTTIME
Change 21.134 - MONITASK fixed
Change 21.093 - SYSTEM blank, cleanup
Change 21.076 - Stored Procedure vars added
Change 21.062 - SORT ORDER CHANGED, vars dropped
Change 21.237 - ASUMUOWT fixed
This change is only documenation of the INCOMPATIBLE
changes that have been made to this very-important MXG
program that we strongly suggest you use to put the DB2
and CICS transaction data together.
Thanks to Larry Nova, Transamerica, USA.
Change 21.219 Support for IBM Tivoli Storage Manager Accounting Records
EXTSMACC creates new TSMACCT dataset when data files are
IMACTSMA transferred, with counts of transactions and bytes
TYPETSMA transferred.
TYPSTSMA
VMACTSMA
VMXGINIT
Oct 27, 2003
Thanks to Simone Niemczura, Sungard, USA.
Change 21.218 Six variables in TYPE71 had "AVAILABLE ..USED" in the
VMAC71 label, but the "USED" did not belong, as all count the
Sep 24, 2003 number of available, not used, frames:
AVLEXTAV AVLEXTMN AVLEXTMX PVTAFCAV PVTAFCMN PVTAFCMX
Thanks to Tom Buie, Southern California Edison, USA.
Change 21.217 Support for SMF 99 subtype 7 PAV Device data creates new
EXTY99U7 TYPE997 dataset. Observations are only output if there
IMAC99 were activity counts for the device.
VMAC99
VMXGINIT
Oct 23, 2003
Thanks to Randy Shumate, LexisNexis, USA.
Change 21.216 z990 CPUTYPE 2084 with OS/390 R2.10 caused CPU NOT IN
VMXGRMFI TABLE error; this member should have been updated by
Oct 23, 2003 Change 21.149, but my z990 test data was z/OS and the
VMXGRMFI test was overlooked.
Thanks to Peter Giles, Centrelink, AUSTRALIA.
Change 21.215 Support for EKC's ETF/R FIRECALL SMF 80 optional data
EXTY80EK segment creates two new MXG datasets:
EXTY8XEK TYPE80EK - Contains fixed data plus first EKC80FRD.
IMAC80A TYPE8XEK - Contains any additional EKC80FRD relocate
VMAC80A data segments.
VMXGINIT This change requires execution under SAS Version 8 to
Oct 23, 2003 input the full length (up to 1024 bytes) in EKC80FRD; the
Nov 2, 2003 code executes under SAS V6 without error, but variable
EKC80FRD will be truncated to 200 bytes.
Thanks to Jim Holloway, MetLife, USA.
Change 21.214 Cosmetic. The FORMAT statement in MACRO _VMRPT3 (for
VMACVMXA "report three" listed the variables from _VMRPT2, but
Oct 22, 2003 there is no need for those variables in _VMRPT3.
Thanks to Thom Kight, Fidelity Investment Systems Co, USA.
Change 21.213 Support for Oracle V9.x SMF data is already in MXG, as
VMACORAC there were no changes in their SMF record; you need to
Oct 20, 2003 set the record ID macro, and the Subsystem macro, but
they can be set "instream" after your //SYSIN DD *
%LET MACKEEP=
MACRO _IDORAC 200 %
MACRO _IDORACO SUBSYSID EQ 'TGW9' %
;
%INCLUDE SOURCLIB(TYPSORAC);
Thanks to Ralf-Henning Glomb, BMW, GERMANY
Change 21.212 Support for optional CMODNAME='MQSeries' CICSTRAN data
UTILEXCL fields from IBM, added starting in CICS/TS 3.2, creates
VMAC110 variables MQGETWTM,MQGETWCN,MQREQS,MQWTCBUS,MQONTCBU, and
Oct 20, 2003 MQREQUS. This support requires that you use UTILEXCL to
create an IMACEXCL for those variables to exist in the
CICSTRAN dataset. But see Change 31.223.
Thanks to Ricke Godehard, Itellium, GERMANY.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 21.211 Support for RACF segment RACFDTP=44 decodes the value of
VMAC80A the command into new variables EV44VAL1-EV44VALF and
Oct 20, 2003 stores only the name (PROC,ACCTNUM,SIZE,MAXSIZE, NOUNIT,
Oct 28, 2003 and COMMAND) in the existing EV44TXT1-TXTF variables.
Oct 29, 2003
Thanks to John McDermott, Blue Cross Blue Shield of Florida, USA.
Change 21.210 Support for several new ESS segments (34x,35x,37x,47x)
IMAC6ESS and for GEPARMNR more than 1 for 21x and 2Fx added in
VMAC6 (optional) IMAC6ESS, also adds new variables to TYPE6
Oct 14, 2003 (but only if comment block in IMAC6ESS is opened, and the
DROP= statement is edited in that member to keep the new
variables).
Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY.
Change 21.209 New fields added by ThruPut Manager are now supported:
VMACTPMX ADDRSA CA7 CONVEC CURMSC CURREC1-CURREC6
Oct 14, 2003 observations in dataset DB2ACCTP if the package data
Thanks to Lawrence Jermyn, Fidelity, USA.
Change 21.208 Variables QWACBSC and QWACESC are missing in package
VMACDB2H observations in dataset DB2ACCTP if the package data came
Oct 13, 2003 from SMF 101 Subtype 1 (IFCID=239) records, as those
records do not contain the QWAC segment.
The SMF 101 Subtype 0 IFCID=3 Accounting Record
contains the first ten package executions, each of
which is output in DB2ACCTP; the SMF 101 Subtype 1
IFCID=239 records contains the rest of the package
segments when there are more than 10 per plan.
It is also not possible to retain the QWACBSC/ESC from
the prior SMF 101 Subtype 0 (IFCID=3) record, because IBM
in their infinite wisdom decided to write the 239 record
first (even though QWHSSTCK time in that first IFCID=239
record is later than QWHSSTCK time in the following
IFCID=3 record). Only with dual sorts of DB2ACCT and
DB2ACCTP plus a massive merge, could the QWACBSC/QWACESC
timestamps of the account record be added to the DB2ACCTP
package dataset, and that's a lot of cost for very little
value. The DB2ACCTP dataset variables QPACSCB & QPACSCE
are datetimestamps of the "entry to, and exit from" DB2,
like a start/end of the package call, but they are also
inconsistent:
QPACSCE always has a non-missing datetime value
QPACSCB is always missing in all IFCID=239 records, and
is only non-missing in the first package
segment in IFCID=3 records.
When QPACSCB is missing, you could consider calculating
variable PSEUDOSCB=QPACSCE-QPACSCT, to estimate the SCB
start time (by subtracting the execution duration from
the end datetime). PSEUDOSCB was slightly earlier than
QPACSCB when QPACSCB existed.
This change added disabled debugging PUT statements that
were used to examine these records, in case they are
needed for future investigations.
Thanks to Daniel O. Russo, Vanguard, USA.
Change 21.207 The test for NTSMF Object MSEXCHANGECCMC replaced the
VMACNTSM incorrect spelling (MSEXCHANGECMCC).
Oct 10, 2003
Thanks to Philip Henning, Demand Technology, USA.
Change 21.206 Variables QW0125PC QW0125PL QW0125PN QW0125SN QW0125TS
VMAC102 are now input and kept in DB2 102 IFCID=125 T102S125.
Oct 10, 2003 dataset.
Thanks to Ron Alterman, PG&E, USA.
Change 21.205 MXG Support for BMC's IMF/CIMS IMS already includes the
VMACCIMS variable SMQGROUP, the IMS Shared Message Queue Group
Oct 9, 2003 Name, so that you can summarize BY SMQGROUP to see the
total response and resources of the entire group. This
change is only for documentation (because I didn't know
what the heck an IMS Shared Message Queue Group was,
either)!
A Shared queues group is just a group if IMS systems
(an IMS Plex) that share incoming transactions with
their shared message queue stored as a structure in a
couling facility. A transaction arrives at any IMS
System but can be executed anywhere in the Plex. Only
one 'FA'x IMF Transaction record is created, even
though IMSA may have put the message on the Q and IMSB
executed the transaction (and IMSB will be where the
FA record was written).
Thanks to Ulrich DIllenberger, BMC, GERMANY.
Change 21.204 If you use %LET MACSHFT= syntax to replace or override
IMACSHFT the SHIFT definitions in your tailored IMACSHFT member,
Oct 8, 2003 the input temporary variable DATETIME will have been
changed by IMACSHFT logic to the start-datetime of the
shift, so that MXG Summarization and Trending datasets
have a common STARTIME value. The addition of &MACSHFT
support was done only for consistency with other IMACs,
but I never considered that anyone would ever want to
pass static definitions, like SHIFT, thru %LET MACSHFT!
This change stores the original value in DATETIME when
IMACSHFT was invoked into temporary variable SHFTTIME,
so that if you do use %LET MACSHFT, and don't tailor the
default MXG IMACSHFT member, you can set
DATETIME=SHFTTIME;
as your first statement in MACSHFT=, and then redefine
the shifts. However, your MACSHFT= logic must also
the DATETIME variable to the beginning of the shift,
to protect for later summarization in that job.
Thanks to Klaus Messer, COMLAB, GERMANY.
Change 21.203 Variable RESIND should have been formatted HEX2 as it
VMAC77 contains individual bit values regarding the enqueue.
Oct 7, 2003
Thanks to Doug Medland, IBM Global Services, CANADA.
Change 21.202 INPUT STATEMENT EXCEEDED due to invalid OPC record that
VMACOPC had LENGTH=83 but TRLLENGT (expected length) of 420. OPC
Oct 7, 2003 records have new data inserted, currently the new fields
are skipped, pending documentation.
Thanks to Andrew Phillip Davis, Abbey, ENGLAND.
Change 21.201 Protection for SMF80DTP=53 (RUTKN) with SMF80DLN=76.
VMAC80A Segment is documented for z/OS 1.2 SecureWay as DLN=80.
Oct 9, 2003 Caused INPUT STATEMENT EXCEEDED RECORD LENGTH error.
This change circuvents by skipping over the segment.
This data segment is created by the add-on ETFR product
(EKC Tools for RACF is an extension to RACF.ETF/R that
selectively grants extended privileges under emergency
situations), and that vendor will be advised of their
invalid record.
Thanks to John Grasing, MetLife, USA
Change 21.200 Negative values for DB2TCBTM occur if QWACEJST (ending
VMACDB2 CPU time) is smaller than QWACBJST (starting CPU time).
Oct 5, 2003 Out of 9,000 transactions, four transactions were neg:
QWACBJST QWACEJST QWACRINV
1.61 0.00452 10
0.12 0.00458 10
0.25 0.00415 10
3.63 0.00436 10
IBM notes that BJST or EJST are zero when CPU timing is
not available; MXG only calculated the difference when
when both are non-zero; this change adds a test to also
calculate DB2TCBTM if EJST is greater than BJST, while
IBM investigates further.
PQ71119 is a correction for Tivoli that mentions why
EJST may be zero: rrs commit request can be issued in a
different address space than the original attach so DB2
does not have the original TCB; their solution was to
force a zero value, as was done here by MXG. However,
MXG adds QWACSPCP and QWACTRTE to the delta so you
could have DB2TCBTM non-zero even if the EJST-BJST
difference is not calculated.
Note added Jan 21, 2004: This note is also in NEWSLETTER
FORTY-FOUR, MVS Technical Note 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, so that class 1 non-nested CPU time
could erroneously be a negative value.
Thanks to Roger L. Rush, Nav-International, USA.
Thanks to Richard L. Steele, Nav-International, USA.
Change 21.199 -IMACxxxx members with incorrect spelling of the DDDDDD
IMAC119 values in the comments, or that were missing new data
IMAC28 sets were revised. Only documentation was changed.
IMAC42 -VMAC members _Nxxxx and _Sxxxx Null/Sort macros had
IMAC74 tokens added for new datasets that had been overlooked.
IMAC85
IMAC94
IMACAIX
IMACDOS
IMACILKA
IMACMVTP
IMACNDM
IMACNSPY
IMACNTSM
VMAC90A
VMACMWAI
VMACNTCP
Oct 5, 2003
Change 21.198 A missing value for STRTTIME in CICSTRAN can occur if you
VMAC110 have optional data segments in your transaction SMF
Oct 5, 2003 records, but you did copy and remove the comment block
in the IMACICxx member for those optional segments.
The UTILEXCL program lists all optional data segments
and lists the IMACICxx members you must tailor. If
you don't tell MXG about the data, its INPUT gets out
of alignment, and if STRTTIME happens to have all hex
zeros, a missing value results. Since STRTTIME is the
Start Time of the transaction, it must always exist in
your CICS records. A new message is now printed if
STRTTIME is missing.
Change 21.197 -ASUMCACH enhanced to keep track of I/O by LPAR (in the
ANALCACH variables IORATEA, IORATEB,...) in PDB.ASUMCACH that it
ASUMCACH creates.
Oct 2, 2003 -Second example Analysis Report added to ANALCACH that
Nov 6, 2003 reads the PDB.ASUMCACH dataset, and uses two formats
(that you EDIT in your program) that map your DASD UCB
addresses to Raid Groups and HDS Rank, so that you can
report and measure I/O activity down to the Raid Group
within RAIDBOX.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.196 INVALID DATA FOR VERSN90 message had no impact on the
VMAC90 created dataset, but it and associated hex dump are
Oct 2, 2003 prevented by the insertion of ?? in the INPUT.
Thanks to Jim Petersen, Washington Mutual, USA.
Change 21.195 Support for Microsoft Exchange Server 5.5 Log file
EXEXCHLG creates EXCHANGE dataset from INFILE EXCHLOG. This
IMACEXCH support is preliminary and covers all fields, but parsing
TYPEEXCH of sub-fields is contemplated where needed, creating new
TYPSEXCH variables eventually.
VMACEXCH
VMXGINIT
Oct 2, 2003
Thanks to Bob Gauthier, Albertsons, USA.
Change 21.194 Variables added to _KUOWCIC (CICSTRAN) into PDB.ASUMUOW
ADOCUOW STORHWMH STORHWMK SYNCDLTM SYNPTCN
VMXGUOW ENQDIOCN ENQDIOTM LU62IOCN LU62IOTM
Oct 1, 2003 Variables added to _KUOWCIX (Max):
Oct 22, 2003 STORHWMH STORHWMK
ADOCUOW was updated to be consistent with VMXGUOW.
Oct 22: End Comment before ENQDIOCN =.; was added.
Thanks to Paul Gillis, ColesMeyer, AUSTRALIA.
Change 21.193 -Variable BYTEAVAI can be zero if AVAILMEM or AVAILMEK is
EXNTIPV4 zero (still under investigation). The MXG statement
EXNTTCV4 BYTEAVAI=AVAILMEM; is now replaced by the statement
EXNTUDV4 BYTEAVAI=MAX(BYTEAVAI,AVAILMEM,AVAILMEK); to cover all
IMACNTSM possibilities of values in the three fields.
VMACNTSM -Support for new IPV4, TCPV4, and UDPV4 objects create
VMXGINIT three datasets of the same name.
Oct 1, 2003 -Pending DISCOVERY Records, new data added to ACSR 0/36
and WEBS 1/86 are not yet supported.
Thanks to Barry Neff, Infores, USA.
Change 21.192 SYNCSORT for z/OS 1.1 can have 255 SORTWORKs, but MXG
VMACSYNC only outputs details on the first 99, and would have
Oct 1, 2003 failed (ARRAY OUT OF RANGE) if you had more than 99.
This change protects for more than 99, but only by
printing a message that more were found, and to contact
support@mxg.com, if you really have a need for details on
the 100th+ sort work area.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.191 SMF 94 variable SMF94VCZ (Average MB per Logical Vol) is
ADOC94 recalculated when it is zero in the IBM record but
VMAC94 SMF94VBA/SMF94VLA is non-zero. Many of the SMF94Vxx
Sep 30, 2003 variables are zero if SMF94VNO='FF'x (Composite), some
are the composite of all AX0's if VNO='FF'X, and some are
non-zero only if VNO='FF'x. ADOC94 was updated to
identify the "Note 1 and Note 2" variables in TYPE94.
Thanks to Art Hunter, Penn Mutual, USA.
Change 21.190 Support for APAR PQ77633, which corrects FTPREPLY code in
VMAC119 FTP client records; it should have been a three digit RFC
Sep 29, 2003 code in left-justified EBCDIC, but the SMF 119 record had
Mar 2, 2004 a binary value prior to this APAR. See Change 22.019.
Change 21.189 CICS SMF 110 subtype 1 MNSEGCL=5 records caused ERROR:
VMAC110 INVALID DO LOOP CONTROL INFORMATION because I forgot that
Sep 23, 2003 DO _I_=1 TO MNR5LEN3; fails if MNR5LEN3=., and the third
triplet is not always present. Change to IF MNR5LEN3 GT
0 THEN DO _I_=1 TO MNR5LEN3 to fix.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 21.188 NDM SMF user record subtypes 'IP','JI','QH','QW', and
VMACNDM 'WS' are still not undecoded, until an MXG user wants
Sep 23, 2003 those data, but the UNKNOWN RECORD messages are now no
longer printed for those subtypes.
Thanks to Trevor Ede, EDS, NEW ZEALAND.
Change 21.187 Data values in PDB.DB2GBPST were occasionally way too
VMACDB2 large; the logic to deaccumulate did not test the
Sep 23, 2003 SEQCHECK variable, and thus missed restarts/resets. The
test for SEQCHECK was also added to the logic for
PDB.DB2STATR and PDB.DB2STATB, although neither had any
reports of bad data values.
Thanks to Lori A. Masulis, Fidelity Systems, USA.
Change 21.186 Another major enhancement for RMF III VSAM support now
ASMRMFV adds support for six new RMF III data tables:
Sep 23, 2003 CFI (Coupling Facility Information Table)
Nov 18, 2003 RCD (Resource Collection Data Table)
SVP (Service Policy Data)
SHD (Sample Header Data)
RED (Resource Data Record)
UWD (Use/Wait Record)
See change 21.228 for updates to VMACRMFV to support the
new data added by this change to ASMRMFV.
See Change 21.236.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 21.185 INTERVAL=SECOND in VMXGSUM, VMXGDUR, and ANALCNCR is
ANALCNCR added to MINUTE HOUR etc values to set the interval in
ANALCNCR summarization and concurrency analysis (e.g. counting
VMXGSUM concurrent NT processes in each second). But use the
VMXGDUR INTERVAL=SECOND value with care, as it can require
Sep 23, 2003 workspace that is many times the size of the input data.
Sep 30, 2003
Thanks to Art Morelock, CheckFree, USA.
Change 21.184 Support for 3592 Tape Drives already exists in MXG, as
none they are still 3590s (UCBTY34='8083'x) in SMF records.
Sep 23, 2003 The specific type and model is contained in the TYPE74
for each device in variable SMF74NID='003592J....'.
Thanks to MP Welch, SPRINT, USA.
====== Changes thru 21.183 were in MXG 21.05 dated Sep 22, 2003=========
Change 21.183 SMF 115 Subtype 2 INPUT STATEMENT EXCEEDED because the
VMAC115 protection in Change 21.161 was incomplete.
Sep 21, 2003
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 21.182 Support for z/OS 1.4 Feature 1 (COMPATIBLE) that adds
VMAC89 SMF89LP3 variable with one or two digit LPAR ID value.
Sep 19, 2003 Feature 0 is "z/OS V1.4 z999 Compatibility Support".
Feb 13, 2004 Feature 1 is "z/OS V1.4 z990 Exploitation Support".
Feature 2 is "z/OS V1.4 Consoles Enhancements".
====== Changes thru 21.181 were in MXG 21.05 dated Sep 18, 2003=========
Change 21.181 TMS/CA1 Release 5.2 (finally!) lets you block the TMC
TYPETMS5 file to half-track blocksize of its 340 byte records, so
Sep 18, 2003 the MXG recommendation to use BUFNO=200 on //TMC is
withdrawn when you have enabled half-track blocksize.
That large a BUFNO with half-track blocksize could cause
an 80A out-of-virtual-memory ABEND. Reblocking the TMC
to half-track reduced the MXG run time of TYPETMS5 from
6.5 minutes to only 2.5 minutes.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.180 -Example to build Weekly PDB from Daily PDBs on tape to
JCLWEEKD eliminate backspace/rewind/remount wasted time, using the
WEEKBLDD same technique as MONTHBLD: copy the selected PDB
WEEKBL3D datasets from tape to temporary DASD and build WEEKLY
Sep 17, 2003 from those disk copies rather than by reading tapes.
Thanks to Ron Lundy, AHOLDUSA, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 21.179 -TYPE50 records contain interval data, but there is no
FORMATS interval value in the record; this enhancement creates
VMAC50 new variable DELTATM as the delta between SMFTIMEs for
Sep 16, 2003 the same instance; however, DELTATM will be missing in
the first record for each instance, even though the rest
of the data is valid in those first-per-day data.
-Format MG050AT was updated for 3:Read Write Subchannel
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 21.178 Variable STARTIME is now created in TPXINTRV dataset in
VMACTPX the _STPXINT (DIFFTPX) deaccumulation logic.
Sep 16, 2003
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 21.177 Cosmetic; suppressed printing of temporary datasets that
VMXGPRAL were created by a prior run of VMXGPRAL.
Sep 12, 2003
Change 21.176 -Support for CICS APAR PQ76703 new Transaction Resource
EXCICDSR Class Monitoring TSQUEUE segment in SMF 110 Subtype 1
EXCICDST with MNSEGCL=5, which caused INPUT STATEMENT EXCEEDED
EXCICRDQ error: the new triplet and class were unexpected. You
VMAC110 can confirm this error by seeing MNSEGCL=5 in the list of
VMXGINIT variables after the error is printed. The new data
Sep 12, 2003 tracks Temporary Storage at the transaction level with ts
queue name, and is output in new CICSRDQU dataset. The
DFHMCT TYPE=INITIAL TSQUEUE=4 default captures four
queues, a maximum of TSQUEUE=32 is allowed, and if
TSQUEUE=0, no data segments will be created and the
CICSRDQU dataset will have zero observations.
-New STID=64 and STID=65 for DSR and DST DSECTS create two
new CICDSR and CICDST Statistics Datasets. These
segments were added by IBM APAR PQ76697.
Thanks to David Klein, DOITT - City of New York, USA.
Thanks to Eileen Barkow, DOITT - City of New York, USA.
Change 21.175 Support for DB2 102 IFCID=217 (Storage Manager Pool)
EX102T17 creates four datasets:
EX102U17 T102S217 QW0217HE DSECT - Storage Available
EX102V17 T102T217 QW02172 DSECT - Storage each QW0217PH
VMAC102 T102U217 QW02173 DSECT - Storage each QW02173H
VMXGINIT T102V217 QW02174 DSECT - Dictionary Storage
Sep 10, 2003 for initial investigation of the new data. These data
records are strange, with the 2nd,3rd,& 4th triplet's
segments containing different DSECTs in different SMF
records, so logic using Segment Length is required to
determine exactly which DSECT is in which triplet! The
only unique variable in T102T217 and T102U217 is the
undocumented "Serviceability" token, QW0217PH and
QW02173H. Revision is possible if a better way seen!
-Support for IFCID=254 (Group Buffer Pool) adds 22 new
variables to the T102S254 with only common variables.
existing T102S254
Thanks to Phil Parker, TNT Post Group, ENGLAND.
Change 21.174 The PROC FREQ in _RPDBID failed, if you used _STYID in
BUILD001 EXPDBOUT (to sort WORK.ID to PDB.ID), because MXG hard
BUIL3001 coded the DATA=_WTYID token, so SAS only looked for ID in
BUILDPDB the Work Lib. Instead, the %VMXGWORL macro is used to
BUILDPD3 determine where you left that dataset, populating macro
Sep 9, 2003 variable &MXGWORL ("W or L") with its location:
%VMXGWORL(DDDDDD=TYID);
PROC FREQ DATA=&MXGWORL;
This should have been done when %VMXGWORL was created.
Thanks to Hugh Lapham, RCMP, CANADA.
Change 21.173 SMF 116 Subtype 0 records with QWHS header LENQWHS=36
VMAC116 caused INVALID PRODUCT SECTION message, and were then
Sep 9, 2003 deleted (and hence not output in MQMACCT dataset).
LENQWHS=36 segment is now decoded, up thru QWHSMTN, but
QWHSLOCN/NID/LUNM/LUUV/LUCC/QWHSLUCN are all missing
values in MQMACCT short QWHS segment observations.
-Input of QWHCCV was changed to $CHAR12 from $EBCDIC12.,
to support execution under ASCII. See Change 22.089.
Thanks to Jacob Nudel, Thompson BETA Systems, USA.
Change 21.172 Variable PROCNAME in HPSUPROC dataset was not in the
VMACMWSU LENGTH $32 statement, so it defaulted to only 8 bytes.
Sep 9, 2003 It is now $32 bytes, as process names can be long.
Thanks to Chris Morgan, UFI, ENGLAND.
Change 21.171 ASCII execution only. RACF variables INTENT and ALLOW
VMAC80A were incorrect when MXG executed under ASCII SAS; the
Sep 7, 2003 INPUT of INTENTCH and ALLOWCH should be $CHAR1.
Thanks to Matthew T. Chappell, Queensland Transportation, AUSTRALIA.
Change 21.170 -TYPE70 variable NRCPUS is redefined to be the Average
VMAC7072 Number of CPUs that were Online, because IRD can vary
VMXGRMFI CPUs On and Off dynamically, and the original NRCPUS was
Sep 7, 2003 the integer number of CPUs online at interval end that
had not been varied, which is incorrect for IRD.
SMF70ONT, the Online Time from PR/SM segment is now
summed across all of the LCPUs in this MVS System, and
that sum is then used to recalculate NRCPUS
NRCPUS=SMF70ONT/DURATM
to now be the Average Number of Online CPUs, and its
Label changed. SMF70ONT is also now output in TYPE70,
and MXG percentages based on NRCPUS in TYPE70 were moved
to use the Average NRCPUS value in calculations. One
visible impact will be that NRCPUS will no longer be an
integer value!
-RMFINTRV was revised, adding new SMF70ONT variable and
with NRCPUS recalculated to be Average Number of CPUs.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 21.169 Specifying KEEPALL=YES in %VMXGSUM invocation in these
BUILD005 three members improves performance, and eliminates
BUIL3005 confusing messages if you happen to test with OBS=1.
SPUNJOBS
Sep 7, 2003
Thanks to Chuck Hopf, MBNA, USA.
Change 21.168 ERROR: DATASET WORK.MXGSUM2 IS NOT SORTED IN ASCENDING
AUTOEXEC may occurs if your SAS installation's SORTSEQ= option is
CONFIGV8 not SORTSEQ=EBCDIC or SORTSEQ=ASCII, as documented in SAS
Sep 7, 2003 Note SN-07151, which has no fix yet. So to eliminate the
exposure with MXG jobs, the appropriate SORTSEQ=EBCDIC or
SORTSEQ=ASCII is now set in MXG's defaults.
Thanks to Brian Sanger, Zurich Financial Services, ENGLAND.
Change 21.167 Support for multiple uniquely-named CICS user fields is
EXUTILEX added by the new _UNIQUE macro defined in member
UTILEXCL EXUTILEX, allowing you to create your own named variables
Sep 19, 2003 in CICSTRAN from your user data fields.
Thanks to Terry Fox, Principal Insurance, USA.
Change 21.166 IIS Web Log data caused UNRECOGNIZED HEADER and ARRAY
VMACWWW SUBSCRIPT OUT OF RANGE because MXG expected all 21 IIS
Sep 4, 2003 fields were present. Logic to recognize the end of
fields and protect for non-existent fields was added.
Thanks to Mike Penlington, Westpac, NEW ZEALAND.
Change 21.165 CICS/TS 2.2 STID=126 UNEXPECTED DATA due to STILEN=284
VMAC110 because MXG didn't INPUT variable S6RSP9CT, but now it
Sep 3, 2003 does and the variable is kept in dataset CICCFS6D.
Thanks to Allen Mayer, Prudential Securities, USA.
Change 21.164 Typos caused unprintable characters in MXG 21.04. In
DOCLRMFV member DOCLRMFV ASCII '85'x "dashes" were converted to
IMAC6ESS EBCDIC '25'X, but 'real dash' is '2D'x ASCII, '60'X on
Sep 3, 2003 EBCDIC. In member IMAC6ESS, there is a '0D'x that should
have been '40'X on EBCDIC, '20'x on ASCII.
Thanks to Scott Barry, SBBWorks, USA.
Change 21.163 Enhancement permits un-sorted datasets in MONTHBLD and
MONTHBLD circumvention for the (very rare) NOT-SORTED ERROR if you
MONTHBL3 build a monthly from daily/weekly PDBs that were created
MONTHBLS with two different MXG versions that spanned a change in
Sep 3, 2003 MXG sort order (last time this happened was when SYSPLEX
had to be added to RMF sort order!). Now, inserting this
statement:
MACRO _BY % MACRO _SORTBY %
before the _MNTHBLD invocation, both the expectation that
the input dataset is sorted, and the assertion that the
output dataset is sorted, are both disabled.
The building-in-sort-order by MXG is only for the
performance of your report programs, so that if you PROC
SORT in the same (recommended) order, SAS will bypass the
unnecessary sort. Nothing else in MXG requires datasets
be sorted.
Once you have nulled those macros, all subsequent
invocations of _MNTHBLD will be unsorted in and out.
Thanks to Caron Knox, Willis Corroon, ENGLAND.
Change 21.162 Typo of IFDURTM/496 instead of IFDURTM/4096 caused
VMAC119 invalid value for IFDURTM.
Sep 3, 2003
Thanks to Elisabeth Ballet, Michelin, FRANCE.
Change 21.161 MQ V5.3 CF dataset MQMCFMGR with MQ 5.3 has very large
VMAC115 values. MXG assumed QESTLL of 64, as documented, but
Aug 27, 2003 protection for longer QESTLL was added to see if that
could account for the problem. Await SMF test data.
Thanks to Ruud van Zundert, UBS, ENGLAND.
Change 21.160 Support for TNG Version 7 (INCOMPAT, due to insertion of
VMACTNG one field in the CAPMPCM HEADER record).
Aug 27, 2003
Thanks to Colin Bowen, CSC, SOUTH AFRICA.
====== Changes thru 21.159 were in MXG 21.04 dated Aug 25, 2003=========
Change 21.159 Variable SYNCTIME in TYPE23 is on the GMT time zone, so
VMAC23 it should have had ",GMT" at the end of its
Aug 21, 2003 %VMXGTIME(SYNCTIME,SYSTEM,GMT); statement.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.158 Support for new DFSMS/rmm EDGRXEXT data eliminates MXG
VMACEDGR "LESS THAN 545 BYTES" messages and incorrect data. New
Aug 20, 2003 variables in 'X' record, EDGRXEXT dataset:
RDLABNO ='LABEL NUMBER LABEL=(XX,LL) NEW'
RDLABNOX
RVALVERS='ANSI*LABEL*VERSION'
RVDCRSID='FIRST*FILE*CREATION*SYSTEM ID'
RVDSNNO ='LABEL*NUMBER OF*FIRST FILE*ON VOLUME'
RVEXPTKN='EXPORT*TOKEN'
RVLABNO1='LABEL*NUMBER OF*FIRST FILE*ON VOLUME'
RVOLTYPE='VOLUME*TYPE'
RVPERCNT='VOLUME*FULL*PERCENTAGE'
RVRBYSET='VOLUME*RETAINED*BY SET?'
RVSTKVCN='STACKED*VOLUME*COUNT'
RVSTKVLE='STACK*VOLUME*RECORD*ENABLED?'
New variables in 'D' & 'X' record, EDGRDEXT & EDGRXEXT
datasets: (SEE CHANGE 27.046 CORRECTIONS).
RDDEFRET='DEFAULT RETPD USED'
RDDSNSEQ='DATA SET SEQUENCE NUMBER NEW'
RDEXPDT ='DATA SET EXPIRATION DATE'
RDEXPDTO='ORIGINAL D/S EXPIRATION DATE'
RVDSTBIN='DESTINATION BIN NUMBER'
RVDSTMED='DESTINATION BIN MEDIA NAME'
RVMVDSN1='FIRST DSNAME OF A VOLUME SET'
RVVOL1 ='VOL1 LABEL VOLSER'
The two separate code blocks for the DEXT/RDEXT data was
consolidated into a single block and linked to.
Thanks to James D. Lieser, United Health Group, USA.
Change 21.157 DB2PM-like reports DB2 Accounting Summary had totals
ANALDB2R instead of averages for Class 2 Elapsed, Class 2 CPU, and
Aug 20, 2003 Lock Suspensions. Now they match DB2PM averages.
Thanks to Dr. Yao-Chun Rickert, Bank One, USA.
Change 21.156 Support for Control-D Log file creates 9 new datasets
EXCTLOGA reading their log records from the INFILE name CTLLLOG to
EXCTLOGB create a dataset for each record type:
EXCTLOGC MXG MXG
EXCTLOGD DATASET DATASET LOG
EXCTLOGE NAME LABEL TYPE
EXCTLOGF
EXCTLOGL CTLDOGA CTLD CONTROL REGION A
EXCTLOGM CTLDOGB CTLD ARCHIVE B
EXCTLOGX CTLDOGC CTLD USER C
FORMATS CTLDOGD CTLD DAILY D
IMACCTLL CTLDOGE CTLD AMF E
TYPECTLL CTLDOGF CTLD DECOLLATE F
TYPSCTLL CTLDOGL CTLD AUX REGION L
VMACCTLL CTLDOGM CTLD MIGRAION M
VMXGINIT CTLDOGX CTLD OTHER LOG TYPES ?
Aug 20, 2003 The "C" and "F" datasets contain the variables decoded
Nov 27, 2003 from the Log Message Text; for now, the other datasets
just contain the full LOGMSG text. If the CTLLLOG file
is to be sent to an ASCII platform for MXG execution, the
file must be sent as binary, as it contains both EBCDIC
text and binary values that cannot be translated to
ASCII. The correct DCB is RECFM=F,LRECL=6400, and that
is specified in the MXG program.
-Nov 27: Missing STARTIME in CTLDLOGF when log on/off time
stamps were identical corrected by revised SORT order.
Thanks to Elisenda Masacana, la Caixa, SPAIN.
Change 21.155 Support for Netspy Versions 6 and 7 already exists in MXG
VMACNSPY since MXG 20.10. Test V7 data was read without errors
Aug 18, 2003 nor any indications of inserted fields.
This change is documentation only; no change was made.
Thanks to Ron Byers, British Energy, ENGLAND.
Change 21.154 WARNING:LABELS EXCEED LENGTH 40 NOT SUPPORTED BY V6SEQ
ASUMCICS AND ARE BEING TRUNCATED had no impact, as it was only the
ASUMCICT DSNLABEL= argument revised in Change 21.090 that was too
ASUMCICX long.
Aug 18, 2003
Thanks to Pat Curren, SuperValu Inc, USA.
Change 21.153 -Support for BMC's MVIMS 3.3.0 (COMPAT) adds new data in
VMACCIMS reserved fields in 'FA'x IMS log record that are created
Aug 18, 2003 in these new variables in TYPECIMS dataset:
ABENDSYS='SYSTEM*ABEND*CODE'
ABENDUSR='SYSTEM*ABEND*CODE'
SAPEXTP1='SAP*EXIT*PASS*1?'
SAPEXTP2='SAP*EXIT*PASS*2?'
SAPTRNCD='SAP*TRANSACTION*CODE'
SMQFLAG ='SHARED*MESSAGE*QUEUE*ENVIRONMENT?'
SMQGROUP='SHARED*MESSAGE*QUEUE*GROUP NAME'
SRVCLASS='SERVICE*CLASS*NAME'
UOWTRANS='UOW*FOR*TRANSACTION'
The ABENDSYS/ABENDUSR variables already existed in the
CIMSPROG (program deschedule) dataset, they were added to
record Transaction Abends in CIMSTRAN dataset.
-Variables COREALOC/COREUSED are converted to bytes,
labeled 'BYTES*AVAILABLE/BYTES*USED' and formatted as
MGBYTES to "print pretty". Previously they contained the
count of 2K blocks.
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 21.152 Support for CICS/TS 2.3 (INCOMPATIBLE):
CICINTRV - New variables were inserted into CICSTRAN Subtype 1.
EXCICPGR - Two new CICS TCBs, 'J9' and 'JM' added, supported in
EXCICSJR Subtype 2 CICDS and CICINTRV datasets.
IMACEXCL - New Subtype 2 vars added to STID=2 and STID=117.
UTILEXCL - New Subtype 2 STID=118 and STID=119 create datasets.
VMAC110 -While you can use TYPE110/TYPS110/BUILDPDB to create the
VMXGCICI CICSTRAN dataset, we strongly recommend that you use the
VMXGINIT UTILEXCL program to read your CICS Dictionary records to
Aug 22, 2003 create an IMACEXCL tailoring member that will input and
Sep 1, 2003 keep only the CICSTRAN variables in your CICS records,
Sep 9, 2003 as that can reduce MXG runtime and save disk space.
Sep 10, 2003 UTILEXCL is required if you have excluded any fields
Nov 11, 2003 from your Performance Class (Subtype 1) records.
-New fields are inserted in SMF 110 Subtype 1 creating 17
new variables in CICSTRAN dataset:
CBSRVRNM='CORBA*SERVER*NAME'
DSMMSCCN='MVS*STORAGE*NO TCB*WAIT*COUNT'
DSMMSCTM='MVS*STORAGE*NO TCB*WAIT*TIME'
DSTCBMCN='TCB*MISMATCH*ELAPSED*WAIT*COUNT'
DSTCBMTM='TCB*MISMATCH*ELAPSED*WAIT*TIME'
EJBCRECT='EJB*BEAN*CREATION*CALLS'
EJBMTHCT='EJB*BEAN*METHOD*CALLS*EXECUTED'
EJBREMCT='EJB*BEAN*REMOVAL*CALLS'
EJBSACCT='EJB*BEAN*ACTIVATIONS'
EJBSPACT='EJB*BEAN*PASSIVATIONS'
EJBTOTCT='EJB*TOTAL*REQUESTS'
J9CPUTCN='USER TASK*J9 MODE*CPU TCB*COUNT'
J9CPUTTM='USER TASK*J9 MODE*CPU TCB*TIME'
KY9CPUCN='USER-TASK*KEY 9*TCB CPU*COUNT'
KY9CPUTM='USER-TASK*KEY 9*TCB CPU*TIME'
KY9DISCN='USER-TASK*KEY 9*TCB DISPATCH*COUNT'
KY9DISTM='USER-TASK*KEY 9*TCB DISPATCH*TIME'
-Two new TCBs, 'JM' and 'J9' are created in the CICDS and
CICINTRV datasets from the STID=60 Dispatcher Statistics
110 subtype 2 record, creating new DSExxxxx and DSFxxxxx
variables for those 14th and 15th TCBs. MXG input based
on TCB Number is no longer valid, as IBM uses the same
TCB number for different named TCBs; the TCB name is now
used to store TCB data into the correct set of variables
and the MXG Variable label accurately identifies what
TCB is stored in each set of MXG variables:
Prefix: DSG DS2 DS3 DS4 DS5 DS6 DS7 DS8 DS9
TCB Name: QR RO CO SZ RP FO SL SO J8
Prefix: DSA DBB DSC DSD DSE DSF
TCB Name: L8 S8 H8 D2 JM J9
-The VMXGCICI member was revised to include the two new
TCBs in the PDB.CICINTRV dataset.
-New variables added from STID=2 DFHSMSDS to CICSMDSA:
SMSWAITM='TOTAL*TIME*WAITING FOR*MVS STORAGE'
SMSWAICN='NUMBER OF*REQUESTS*CAUSING*WAITS'
-New variables added from STID=117 DFHSJGDS to CICTCPSJ:
SJGCUWCJ='JVM*CURRENT*WORKER CACHE*JVMS'
SJGMXWCJ='JVM*PEAK*WORKER CACHE*JVMS'
SJGRQWCJ='JVM*REQUESTS*CLASS*CACHE'
-New CICSJR dataset created from STID=118 DFHSJRDS with
the JVMPROFILE Resource Statistics, one observation per
Storage Key for each Profile/Path:
SJRJVCRE='SJR*NEW*JVMS*CREATED'
SJRJVDES='SJR*JVMS*DESTROYED*SOS'
SJRJVHWM='SJR*JVM*HEAP*HWM'
SJRJVRES='SJR*JVMS*RESETTABLE'
SJRLEHWM='SJR*LE*HEAP*HWM'
SJRMMSTE='SJR*MISMATCH*STEALER'
SJRMMVIC='SJR*MISMATCH*VICTIM'
SJRPRCLC='SJR*PROFILE*CLASS*CACHE*SETTING'
SJRPRCUR='SJR*CURRENT*PROFILE*USE COUNT'
SJRPRFRQ='SJR*PROFILE*REQUESTS'
SJRPRHWM='SJR*PEAK*PROFILE*USE*COUNT'
SJRPRNAM='SJR*PROFILE*NAME'
SJRPRPTH='SJR*PROFILE*PATH*NAME'
SJRPRXMX='SJR*PROFILE*XMX*VALUE'
SJRSTOKY='SJR*STORAGE*KEY'
-New CICPGR dataset created from STID=119 DFHPGRDS with
the JVM Program Resource Statistics, one obs per record
Storage Key:
PGRJVCLS='JVMPROGRAM*JVMCLASS*NAME'
PGRJVKEY='JVMPROGRAM*CICS/USER*KEY'
PGRJVPGM='JVMPROGRAM*NAME'
PGRJVPRO='JVMPROGRAM*PROFILE'
PGRJVUSE='JVMPROGRAM*USE*COUNT'
-The new and changed STIDs have been validated with data.
-Note: Several new fields in the SMF records can have up
to 255 characters; for now, MXG only inputs the first
200 characters, so that MXG can still execute under SAS
Version 6, with its 200-byte limit. But as soon as any
MXG customer actually has a name field that is 201 bytes
of text, I will revise those INPUTs to $EBCDIC256, and
the SMF 110 code will have to be executed under SAS V8.
P.S. New stuff, like WebSphere, that is not in the
default BUILDPDB already requires SAS V8!
CICS/TS 2.3 Documentation Errors:
1. In the Data Areas, the SJGDS description does not
show "117" for the STID of that segment, so you
cannot find that SJGDS is the DSECT for that STID.
2. The first SJRDS description is actually the PGRDS
descrption for the STID=119 segment; the bold face
title and the index entry need to be changed to
PGRDS. The ID field does not show "119".
3. The second SJRDS description is correct for the
STID=118 segment The ID field does not show "118".
Change 21.151 Total CREATES in DB2 reports was incorrect; the second
ANALDB2R occurrence of QXCRTAB in CREATES=SUM( ... ) should have
Aug 15, 2003 been QXCTABS.
Thanks to Dr. Yaou-Chun Rickert, Bank One, USA.
Change 21.150 -Support for CPU Time fields in SMF 120 WASserver that
VMAC120 were put in the SMF record by APAR PQ74463, but were only
Aug 13, 2003 documented in the HOLDDATA section of the PTF; Change
Aug 19, 2003 21.107 added support for the other new fields.
Dataset TYP120WI:
SM120WJ4='AVERAGE*CPU TIME' TIME13.6
SM120WJ5='MINIMUM*CPU*TIME' TIME13.6
SM120WJ6='MAXIMUM*CPU*TIME' TIME13.6
Dataset TYP120WA:
SM120CPU='CPU*TIME' TIME13.6
Variable SM120CPU was added by Change 21.107, but
units were undocumented; I assumed divide by 4096,
but the HOLDDATA documentation says microseconds,
so the divide was removed.
-Spurious "UN READ DATA FOUND" messages from SMF 120 were
due to incorrect calculation of SKIP, now fixed.
Thanks to Jan ter Laak, Rabobank, THE NETHERLANDS.
Change 21.149 -Support for z990 CPUs. INCOMPATIBLE: Variables in data
VMAC7072 sets TYPE70PR (LPARCPUS) and ASUM70PR (LPnNRPRC) have
VMXG70PR the total number of engines, rather than the number of
VMXGINIT online engines in RMF data with new CPUTYPE='2084'x.
Aug 13, 2003 MXG tests in VMAC7072 had to be revised for that new
Aug 15, 2003 value. The code was corrected in August in MXG 21.04.
Aug 22, 2003 (This note was not in the original change; it was
Sep 16, 2003 added Sep 16, 2003 to document the requirement).
-New PDB.ASUM70LP dataset for LPAR Reporting is easier and
safer to use than either the detail PDB.TYPE70PR dataset
or the summarized PDB.ASUM70PR dataset.
TYPE70PR - Most Detail - One obs for each LCPUADDR in
each LPARNAME, so CPs, ICFs, PHYSICALs, and
Linux engines are included; reporting must
select which obs to use, how/what to
summarize, and the criteria keeps changing
with IBM hardware or OS level, making your
report maintenance complex and exposed. Once
PDB.ASUM70PR existed, MXG has always
recommended its use, but many user reports
were written using TYPE70PR before there was
a PDB.ASUM70PR.
ASUM70PR - "Platform" summary - All LPARs measured in a
single observation, with a set of vars
(LP0NAME,LP0DUR,PCTL0BY,LP0MSUHR...) for 32
LPARs. Summarized from TYPE70PR with MXG
logic keeping track of what to count,
calculating percentages and MSU variables,
plus the totals for the "Platform". Very
Very accurate and useful, but having all
those different variable names makes for very
messy coding in your reportings, so:
ASUM70LP - A "vertical" dataset built from ASUM70PR.
For each online LPAR, one observation is
created in ASUM70LP for each LPARNAME, and
with only one set of variable names, so you
can select and sort and report easily. (This
is probably how ASUM70PR should have been
originally structured!)
You still must select the "production" SYSTEM whose
observations are used; each SYSTEM creates obs in
all three of the above datasets.
-Corrections/enhancement for PDB.ASUM70PR/PDB.ASUMCEC were
made in both VMAC7072 and VMXG70PR:
.Variables LPnDUR and LPCTnBY in PDB.ASUM70PR/ASUMCEC were
sometimes incorrect, perhaps since Change 19.189! Obs
with SMF70ONT=0 in PDB.TYPE70PR were included in LPnDUR,
so it to be much greater than DURATM*LPnNRPRC, and LPnDUR
is used to calculate LPCTnBY percentage.
.The VMAC7072 logic to creates SMF70ONT was revised
SMF70ONT - missing - Pre 2064, does not have ONT
SMF70ONT - zero - ONT valid and zero
SMF70ONT - nonzero - ONT valid and non-zero
to be more robust and consistent across hardware, and
then VMXG70PR logic that decides to sum this LPARDUR was
revised to include old and new but not spares:
IF SMF70ONT=. THEN LPARDUR=DURATM;
ELSE IF SMF70ONT GT 0 THEN LPARDUR=SMF70ONT;
ELSE LPARDUR=0;
.For LPARs with no CPUs (LPnNRPRC=0), these LPnXXXXX
variables LPnDUR,LPnBDA,LPnLAC,LPnMSU70,LPnNSW,LPnWST are
now set missing when LPnNRPRC=0, (i.e, when the LPAR had
no CPUs assigned) to be consistent with the other
variables that were already missing.
.Divide by zero error was corrected in ASUM70PR.
-Correction in VMAC7072 for PDB.TYPE70PR var SMF70CIN
which could be blank for observations after an offline
LPAR, because MXG's test to set SMF70CIN should have been
IF NRCIXGTO (instead of NRICFCPU) as the flag that
OW37565 was installed.
-The CSTORE storage, SMF70CSF, is added for each LPAR in
PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC. (ESTORE is
a thing of the past; SMF70ESF not added.)
See also Change 21.216 if you are back-level on OS/390 or
early z/OS and SMF70WLA is not populated in SMF 70.
Thanks to Brian Cummings, Federal Reserve Information Technology USA
Thanks to Shirley Fung, HSBC, HONG KONG.
Thanks to Joe Key, BOC Gases, ENGLAND.
Change 21.148 This UTILBLDP enhancement honors your %LET MACKEEP=
UTILBLDP tailoring when you execute %UTILBLDP "instream", i.e.,
VMXGINIT when you invoke %UTILBLDP to create an OUTFILE= and then
Aug 12, 2003 %INCLUDE that file to execute the BUILD program.
Aug 14, 2003 (Previously, UTILBLDP disregarded any tailoring that you
Aug 18, 2003 tried to use in a %LET MACKEEP= statement).
- If you execute UTILBLDP "instream" with this syntax:
%LET MACKEEP= ... tailoring code ... ;
%UTILBLDP(..,OUTFILE=zzzzzzzz,...);
%INCLUDE zzzzzzzz;
the text in your %LET MACKEEP statement text will be
stored in the new &MACBLDP macro variable, which is
executed by a new &MACBLDP invocation appended to the
end of the %LET MACKEEP= statement in zzzzzzzz.
- So to execute %UTILBLDP a second time in the same
data step to create a different zzzzzzzz program
(not sure that you'd ever want or need to), you
need to null MACKEEP, or set to a new value,
before each %UTILBLDP execute.
- If instead you don't want to run the zzzzzzzz code in
this step, but you want to tailor it later with %LET
MACKEEP= logic, then you must have a non-blank
&MACKEEP when you run %UTILBLDP to create zzzzzzzz,
and then you must use %LET MACBLDP= instead of the
%LET MACKEEP= statement to pass your tailoring to the
zzzzzzzz program.
%LET MACBLDP= ... your MACKEEP text ... ;
%INCLUDE zzzzzzzz;
- If MACKEEP is blank when %UTILBLDP creates zzzzzzzz
there is no &MACBLDP statement created in zzzzzzzz.
- The %UPCASEs of macro variables OUTFILE, EXPDBOUT, and
IMACKEEP was removed because unix permits mixed case
file names. (This is not an exposure under Windows,
which sees the same name regardless of the case in its
file and directory names).
- If you have specified BUILDPDB=NO, but you want the
program to contain the _EPDBOUT invocation, you can
specify EXPDBOUT= _EPDBOUT, to create that text.
A later iteration of UTILBLDP may let you put SAS
statements in its EXPDBOUT= argument.
- Several dataset sort macros for type 30 datasets were
misspelled and should have been _STY30xx.
Thanks to Scott Barry, SBBWorks, INC, USA.
Change 21.147 MXG 21.02-21.05 Change 21.062 caused variable STRTTIME in
VMXGUOW dataset PDB.ASUMUOW to be wrong, although temporary
Aug 11, 2003 internal variable TIMESTMP (which should not have been
Sep 23, 2003 kept) was correct and could be used for STRTTIME. The
variables HOLDSTRT and HOLDEND were not initialized, but
now they are, and so STRTTIME will always equal TIMESTMP.
I'd should also drop the redundant variable TIMESTMP, but
since you may have used it, I'll hae to continue to keep
both STRTTIME and TIMESTMP variables. Note: This change
was not in MXG 21.04 nor 21.05. You can correct those
versions by inserting
HOLDSTRT=TIMESTMP;
HOLDEND=TIMESTMP;
after EARLIEST=TIMESTMP;
Thanks to Pat Curren, SuperValu Inc, USA.
Change 21.146 Support for Windows 2003 Server MEMORY object, which has
VMACNTSM NRDATA=31 with one new variable added.
Aug 9, 2003
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 21.145 MXG 21.02-21.03, Change 21.090 made variable DATETIME not
ASUMCICS exist in the PDB.CICS dataset. Variable STRTTIME should
ASUMCICT be used in reports, and it was just fine. Even though
ASUMCICX variable DATETIME is a temporary variable that is created
Aug 7, 2003 inside VMXGSUM logic, and should not have been kept, it
was accidentally added to some datasets, and since some
users have used it instead of STRTTIME, it is again
created in PDB.CICS so your existing reports that still
uses DATETIME won't fail.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 21.144 Protection for truncated (invalid) SMF 119 subtype 7
VMAC119 record with offsets for 32760 bytes of data, but the
Aug 6, 2003 maximum SMF data bytes are 32756. This invalid SMF
record caused INPUT STATEMENT EXCEEDED RECORD LENGTH
error condition. There either is, or will be, an APAR to
correct the SMF 119 record, but this type of bad record
is now recognized and the last segment is not input.
Thanks to Dan Doan, Verizon, USA.
Change 21.143 Support for HMF Release 2.7 (INCOMPAT) changed the
EXTYHMFW subtype 29 and 30 records, and added subtype 32 and 33
EXTYHMFX that create new TYPEHMFW and TYPEHMFX datasets.
IMACHMF See Change 22.162, which corrected this change.
VMACHMF
VMXGINIT
Aug 6, 2003
Thanks to John Mitchell, IBM Global Services, USA.
Change 21.142 SMF 118 TCP Statistics TYPETCPS dataset values are not
VMACTCP interval values, like in the other TYPETCPx datasets.
Aug 6, 2003 The _STYTCPS dataset sort macro is revised to sort and
deaccumulate the TYPETCPS variables. And to ensure you
don't overlook this need, the _STYTCPS dataset sort macro
is added in the TYPETCP member; if you have added TCP
processing to your BUILDPDB and have added either _STCP
(to sort all dataset) or at least the one _STYTCPS sort
macro, then your BUILDPDB-built TYPETCPS data will
contain legitimate interval values.
Thanks to Brian Crow, BT, ENGLAND.
Change 21.141 With S390/R2.10 on z990 processors, CPU NOT IN TABLE
FORMATS message for CPUTYPE=2084 is printed; R2.10 does not
Aug 6, 2003 contain SMF70CPA, so MXG must use a table lookup in the
Aug 17, 2003 $MG070CP format table. The message only impacts the
CECSUSEC and MSU variables, and is eliminated by adding
the new CPUTYPE and CPCMODEL to the format. The $MG070CP
has been updated for the CPCMODEL=307. 17Aug03: FORMATS
updated for all 2084's by Al.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 21.140 -Dataset PDB.DB2GBPST DB2 Global Buffer Pool has always
VMACDB2 had correct values for the QBGLxxx variables for each
Aug 6, 2003 Global pool, but the summarization of those data into the
Aug 24, 2003 QBGLxxx variables in PDB.DB2STATS was never right. MXG
summed those variables by interval as SMF data was read,
but that logic can never work because the data is
accumulated by buffer pool within each interval. Since
those variables in PDB.DB2STATS have never been valid,
all QBGLxxx variables were removed from both PDB.DB2STAT1
and PDB.DB2STATS datasets.
-Dataset PDB.DB2STATB DB2 Buffer Pool has always had
correct values for the QBSTxxx variables for each of the
buffer pools, but their sum in PDB.DB2STATS into the four
QB1Txxx/QB2Txxx/QB3Txxx/QB4Txxx variable sets were only
correct when there was only one buffer pool in a variable
set. Those variables are no longer created in DB2STAT1
during SMF read, but are created by summarization of the
PDB.DB2STATB dataset after it as been built by the
_SDB2STB macro in SUMSTATB temp dataset that is then
merged in _SDB2STS macro to add those variables back into
PDB.DB2STATS.
-Some old variables that have not existed for several DB2
versions were going to be dropped, but their absence
caused TRNDDB2S/MNTHDB2S to die with VARIABLE NOT FOUND
errors, so they are added back in, but are always missing
value:
QBnTBPX QBnTPFDC QBnTPID QBnTPWU QBnTSWU QBnTWMAX.
-B3HITRAT had negative value, due to QBnTxxx errors.
-To document in one place, the four buffer sets are:
QB1T=BP0 QB2T=BP1 QB3T=BP2-49 (other 4K)
QB4T=BP80-89 (32K) BP100-109 (16K) BP120-129 (8K)
-And in DB2 V7.1, data for a buffer pool can just stop,
perhaps when a pool is no longer used, and that caused
MXG's deaccumulation logic to require refinement.
Thanks to Sim Williams, Fidelity, USA.
Change 21.139 -Variable SU_SEC was missing in the optional TYPE6ENH
ASUMPRTR dataset with Goal Mode; TYPE72GO was added to the SET
Aug 5, 2003 statement to populate SU_SEC.
-The second ELSE THRUPUT=.; is now ELSE PCTAFP=.;
Thanks to Diane Eppestine, SBC, USA.
Change 21.138 Change 20.069 created new variables, but added them to
VMAC7072 the wrong KEEP= list. These variables:
Aug 4, 2003 R723RAPP R723RW01 R723RW02 R723RW03 R723RW04 R723RW05
R723RWRR R723RWRT R723RWST
are now relocated to the MACRO _VTY72DL's KEEP list for
the TYPE72DL datasets, instead of TYPE72SC's list.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 21.137 ASMTAPES enhancement detects Allocation Recovery of tape
ASMTAPES devices, creates new SMF subtype to record which job was
EXTMNTAR delayed for how long and which tape devices, real or
IMACTMNT virtual, were unavailable for allocation. The new subtype
VMACTMNT creates observations in new dataset TYPETARC.
VMXGINIT The MXG Allocation Recovery Monitor, "ARCV", feature of
Aug 4, 2003 the MXG Tape Mount and Tape Allocation Monitor is created
Oct 23, 2003 as a sub-task of the MXGTMNT monitor's main task. ARCV's
purpose in life is to establish, under Main Console
Services, an Extended MCS console whose purpose is to
look at those specific console messages that are related
to device allocation recovery. When an allocation
recovery event starts, information related to that event
is maintained for the duration of the event. When the
event concludes (device allocated or request cancelled),
an SMF record containing information about the event is
written.
This feature is implemented as a separate subtask within
the existing MXGTMNT address space, both for isolation
from the current functionality, and to exploit MVS
multiprocessing.
The "ARCV" function can be enabled in the ASMTAPES source
before assembly with the DOARCV flag (default is
ARCV=NO), or the ARCV=YES/NO can be specified in a PARM=
or via a Modify operator command, so it can be enabled or
disabled at any time without having to restart the
MXGTMNT address space.
To clean out ASUMTAPES codewebs that were there only for
seriously-old-releases of MVS, ML-29 eliminated exposures
in archaic code by eliminating the archaic code; ML-29 of
ASMTAPES now requires a minimum OS level of OS/390 2.8.
Six sites have had ML-29 for several weeks and none have
reported any failures, but then none have reported they
have tested it yet, either. 22Aug03.
Oct 23: Just discovered that ASMTAPES in MXG 21.04 and
MXG 21.05 did NOT contain ML-29 version. Now
it does.
Change 21.136 NTSMF dataset SMTPSERV, Windows 2000 and later, didn't
VMACNTSM input CATQUELN, causing the subsequent 85 variables to be
Aug 1, 2003 incorrect.
And with test data, I found that these variables
BYTESRCV BYTESSNT BYTETOTL CONNERRS CONNINBD
CONNOUBD MSBYSRCV MSBYSSNT MSBYTOTL MSGRCVD
MSGSENT MSGTOTS
are accumulated values, rather than interval values; the
_SNTSMTP sort macro now does the deaccumulation of those
variables. (Others variables may also need to be
deaccumulated, but only when I have non-zero data values
can I determine what needs to be deaccum'd.) And the
Instance Name is only one character long in the NTSMF
record - being investigated by NTSMF.
Thanks to Xiaobo Xhang, ISO, USA.
Change 21.135 Sample daily reporting from StorageTek SMF (TYPESTC) and
ANALSTC MXGTMNT (TYPETMNT) datasets to track STK Virtual Tape
Aug 1, 2003 activity. Documented in comments in the member. Note
that all of the internal timestamps in the STC records
are on GMT; you may need to enable VMXGTIME to set the
GMT times back to local time zone before running these
reports.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.134 ASG-TMON V2.2 only.
VMACTMO2 Dataset MONITASK, variables NETSNAME UOWID and UOWTIME
Jul 31, 2003 were incorrectly input, and TALOUOWID was not input at
all. Only critical if you use ASUMUOWT to create
PDB.ASUMUOW from MONITASK data.
Dataset MONIUTG, variable TAUTGICT was not input, and
variable TAUTSTIM has been removed, since it does not
exist.
Thanks to Shantha Hallett, CGEY, ENGLAND.
====== Changes thru 21.133 were in MXG 21.03 dated Jul 28, 2003=========
Change 21.133 Support for NDM Release 4.3 has been tested with most
VMACNDM existing subtypes, but only partial documentation has
Jul 26, 2003 been found. New subtypes exist and are protected, but
until users require the new subtypes, and their DSECTS
are located, the new subtypes are skipped. See the
comments in member VMACNDM as to status of individual
NDM subtypes.
Thanks to Thomas Heitlinger, FICUCIA Karlshruhe, GERMANY.
Change 21.132 Tailoring MXG to only create some datasets can cause
ADOCDB2 ERROR: NO DATA SET OPEN TO LOOK UP VARIABLES
DOCMXG which is the result of trying to PROC SORT a dataset that
Jul 25, 2003 doesn't exist. This can happen even when you use _Nxxxx
"product null" macro to null out all datasets, redefine a
_Wdddddd "work dataset" macro for each one you want, and
redefine the _Sxxxx "product sort" macro to list only the
_Sdddddd "dataset sort" macros for those datasets that
you created: if a later part of your job has an _Sdddddd
macro invoked.
Most MXG programs use the _Sxxxx product macro, but
there are some cases where the individual _Sdddddd
macro is invoked, and the SAS/ITSV "BUILDPDB" job
invokes several _Sdddddd members, because they were
created in MXG before the more-recent _Sxxxx product
sort macro was created.
The _Nxxxx,_Sxxxx,_Sdddddd etc macros are documented
in the DOCMXG member.
This example for either MXG or ITSV will keep only the
DB2ACCT.DB2ACCT and PDB.DB2STATS datasets.
Mar 4, 2004: The earlier example, below, was replaced.
See the text of Change 22.020.
//SYSIN DD *
%LET PDB2ACC=DB2ACCT;
%LET PDB2ST0=WORK;
%LET PDB2ST1=WORK;
%LET PDB2STB=WORK;
%LET MACKEEP=
%QUOTE(
_NDB2
MACRO _WDB2ACC _LDB2ACC %
MACRO _WDB2ST0 DB2STAT0 %
MACRO _WDB2ST1 DB2STAT1 %
MACRO _WDB2STB DB2STATB %
MACRO _SDB2 _SDB2STB _SDB2STS %
MACRO _SDB2ACP %
MACRO _SDB2ACB %
MACRO _SDB2ACG %
MACRO _SDB2PAT %
MACRO _SDB2ST2 %
MACRO _SDB2STR %
MACRO _SDB2PST % );
%INCLUDE SOURCLIB(TYPSDB2);
RUN;
Thanks to Chrisa Neven, KBC, BELGIUM.
Change 21.131 The value in SAS macro variable &SYSSCP is the operating
VMXGINIT system of this execution, and it returns "OS", "CMS", or
VMXGGETM "others" (listed in comments in VMXGINIT). MXG copies
VMXGTAPE &SYSSCP into &OPSYS, and tests for "OS", "CMS", or ELSE,
VMXGVTOC creating different code on different execution platforms.
VMXGTAPE I was misinformed that SAS had changed values of &SYSSCP,
VMXGSUM and in revising my code, found inconsistent testing for
VMXGDSNL both &OPSYS and &SYSSCP, so all logic now uses only the
VMXGDEL MXG-created &OPSYS macro variable, whose value is set in
VMACVMXA VMXGINIT. Then my mis-informant RTFM and discovered that
VMACVMON it was not the macro &SYSSCP, but instead macro &SYSSCPL
VMACUNIK that SAS changed ("MVS" became "OS/390" or "z/OS", with a
VMACTPF lower case z!), but MXG never uses &SYSSCPL, so this
VMACTAND change was not actually required. But consistent coding
VMACOPC is the end result, and I consider the time well spent.
VMACMVCI
VMACEREP
VMACDCOL See SAS Notes SN/004/004358, SN/006/006346 on &SYSSCPL.
VAXPDS Note: If you did want to test &SYSSCPL for that new
UTILBLDP "z/OS" value, in macro language, the syntax is
PRINTNL %IF %QUOTE(%UPCASE(&SYSSCPL)) EQ %QUOTE(Z/OS) %THEN ..
GRAFWRKX
BLDNTPDB
ANALDB2R
ANALCISH
VMXGRMFI
Jul 24, 2003
Change 21.130 Support for APAR OW56656 for RMF for z990 family adds
VMAC7072 variables to existing datasets:
VMAC73 - TYPE70X2 dataset
VMAC74 R7024EN /*NUMBER OF*CRYPTO*ENGINES*/
VMAC78 - TYPE73 dataset
VMAC79 SMF73CSS /*CHANNEL*SUBSYSTEM*ID*/
Jul 23, 2003 SMF73SFL has new bit 2 value
Hardware Allows Multiple Channel Subsystems
SMF73FG4, MXG variable CHANINDY, has new bit 5 value
Chan Characteristics Changed in Interval
- TYPE74 dataset
SMF74ENF (not kept, has new bit 0 "Extended Mode")
- TYPE78 dataset
R783GFLG MXG variable IOPIFLG has new bit 6 value
Initial-Command-Response measure supported
- TYPE78CU dataset new variables:
R783CBTM='CU BUSY*TIME FOR*DCM MANAGED*CHANS'
R783CMRM='CMR*TIME FOR*DCM MANAGED*CHANS'
R783SBSM='SWITCH*BUSY COUNTS*FOR DCM*MANAGED'
R783CSST='CHANNEL*SUBSYSTEM*WAIT*TIME'
- TYPE78CF dataset new variables:
R783CBT ='CU BUSY*DELAY TIME'
R783CMR ='INITIAL*COMMAND*RESPONSE*TIME'
R783CPXF='CHANNEL*PATH*EXTENDED*FLAGS'
R783SBS ='SWITCH*BUSY*COUNTS*ALL PARTITIONS'
- TYPE799 dataset
R799CNX - new bit 3 value.
- TYPE79C dataset
R79FLAG - new bit 5 value.
New variable:
R79CCSS ='CHANNEL*SUBSYSTEM*ID'
R79CFG3 - new bit 5 value.
- TYPE79E dataset
IOPIFLG (R79EGFLG) new bit 6 value.
New Variables:
R79ECBT ='CU BUSY*DELAY*TIME'
R79ECMR ='CMR*TIME'
R79ESBS ='SWITCH*BUSY*COUNT'
R79ECPXF='CHANNEL*PATH*EXTENDED*FLAGS'
R79ECBTM='CU BUSY*DELAY*TIME'
R79ECMRM='CMR*TIME'
R79ESBSM='SWITCH*BUSY*COUNT'
R79ECSST='CHANNEL*SUBSYSTEM*WAIT*TIME'
Change 21.129 Support for ASG-Landmark's TMON for MQ-Series creates
EXTMQQC these new MXG datasets from the TMMQIN infile:
EXTMQQE Dataset Description
EXTMQQH TMMQQC CHANNEL STATISTICS
EXTMQQMA TMMQQE EVENT
EXTMQQMB TMMQQH DEAD LETTER QUEUE (DLQ) PROCESSOR ACTIVITY
EXTMQQMD TMMQQMA QUEUE MANAGER - ASID DATA
EXTMQQML TMMQQMB QUEUE MANAGER - BUFFER MANAGER
EXTMQQMM TMMQQMD QUEUE MANAGER - DATA DATA
EXTMQQS TMMQQML QUEUE MANAGER - LOG MANAGER
EXTMQQT TMMQQMM QUEUE MANAGER - MESSAGE MANAGER
EXTMQQU TMMQQS PAGE SET STATISTICS
EXTMQQV TMMQQT THREAD INTERVAL
EXTMQQX TMMQQU QUEUE STATISTICS INTERVAL
IMACTMMQ TMMQQV DLQ PROCESSOR ACTIVITY SUMMARY
TYPETMMQ TMMQQX EXCEPTION
TYPSTMMQ
VMACTMMQ
VMXGINIT
Jul 23, 2003
Change 21.128 If you used UTILEXCL (for CICS Excluded Fields) to create
IMACEXCL an IMACEXCL member, or if you tailored the MXG IMACEXCL
UTILEXCL member, variables SC24CHWM and SC31CHWM were wrongly
Jul 23, 2003 divided by 4 million (4E06 in floating point syntax),
and variables SC23COCC and SC31COCC were wrongly not
divided by 4E06. Using the un-modified VMAC110 produced
correct values for all four variables.
Thanks to Art Cuneo, BlueCross Blue Shield of Illinois, USA.
Change 21.127 The INFILE SMF statement has FILENAME=INFILENM added, and
VMACSMF LENGTH INFILENM $64; so that INFILENM will contain the
Jul 21, 2003 MVS DSNAME or the ascii directory/filename of the input
SMF file that is being read. INFILENM is NOT kept in any
MXG datasets, but is available as each record is read,
and could be used to track what DSNAMEs have been read.
Although MVS DSN is only $44, I picked $64 because of the
typical size of ascii directory and filenames.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Change 21.126 TYPE74CA variable R745DCIR is now reserved; variables
VMAC74 R745CUID (from "CO" segment) and R745DCID (from "DO")
Jul 21, 2003 are documented by IBM as "Control Unit ID", but when
only two unique values ('1B'x=2105s and '15'x=3390-6s)
were found in RMF data, IBM was queried and confirmed
that the fields actually contain a unique code for the
cache controller type; IBM documentation will be revised.
Variable R745DCID is now formatted HEX2.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.125 You can now map different SRVCLASS from different SYSTEM
VMXGRMFI or SYSPLEXes into a single workload in PDB.RMFINTRV.
Jul 22, 2003 You use two WORKnn statements, with different nn values,
but with the same first two arguments (workload name,
label text), and then the SYSTEM or SYSPLEX arguments
control which SRVCLASS observations from TYPE72/TYPE72GO
are included in this workload name. For example
WORK01=TSOP/TSO Prod//TSOPROD/2//PLEXA,
WORK02=TSO/TSO//TSO/2//PLEXA,
WORK03=TSO/TSO//TSOPROD/2/PLEXB,
would create two workloads, TSO containing SRVCLASS
TSOPROD from PLEXA, and TSOP containing SRVCLASS TSO from
PLEXA and SRVCLASS TSOPROD from PLEXB.
Because PERIODS=2 is specified, the "PERIODS" response
variables for two periods will be created for each
of these workloads, comprising these variables:
TSOP1RSP TSOP1SWP TSOP1TRN
TSOP2RSP TSOP2SWP TSOP2TRN
TSO1RSP TSO1SWP TSO1TRN
TSO2RSP TSO2SWP TSO2TRN
In addition, because the workload name starts with TSO,
the "TSO" response variables for the entire system:
TRIVRESP TSO2RESP TSO3RESP TSO4RESP
TRIVTRAN TSO2TRAN TSO3TRAN TSO4TRAN
TRIVSWAP TSO2SWAP TSO3SWAP TSO4SWAP
(Note: Previously, only the workload 'TSO' exactly was
in these "TSO" response variables, but now, all
workloads with XXXX starting with "TSO" are
included in the "TSO" response variables, and
you can use the "PERIODS" response variable for
the individual TSO workloads if more than one.
The comments documenting the VMXGRMFI arguments was also
revised by this change.
Note: To use these enhancements, you MUST execute MXG
with SAS Version 8.2 or later.
Thanks to Shirley Fung, HSBC, HONG KONG.
Change 21.124 Support for EntireX user SMF accounting EXXACTR record
EXENTIRX creates ENTIREX dataset.
FORMATS
IMACENTX
TYPEENTX
TYPSENTX
VMACENTX
VMXGINIT
Jul 18, 2003
Thanks to John Cousins, Bristol City Council, ENGLAND.
Change 21.123 Non-duplicate TYPE6156 records were deleted by the NODUP
VMAC6156 in MXG's PROC SORT, because all of the kept variables in
Jul 17, 2003 TYPE6156 were identical. However, the two records were
different, only in the catalog segment E3 (TRUENAME), and
one record was for Data, the other for Index, so variable
TRUETYPE and TRUEDSN are now decoded from the 'E3'x data,
and are kept in TYPE6156, and are added to the _BTY6156
by list, so the non-duplicate records are not duplicates
any more.
Thanks to Art Cuneo, BlueCross Blue Shield of Illinois, USA.
Change 21.122 The +58 in Volume Record from MVSRECLV=01 RMM records
VMACEDGS was changed to +122 by Change 19.284, but now records
Jul 16, 2003 have been found with MVSRECLV=01 that still have only
+58 bytes to skip between MVDCRSID and MVDSN1L, and
I can find no flag that indicates how many bytes need to
be skipped. Using +122 with +58 record causes STOPOVER,
while using +58 with +122 causes no error (and only the
variables listed in Change 19.284 to be in error), so I
have changed the default back to +58, and have created
a new "old-style" MACRO _LNEDGS +58 % in VMACEDGS
that can be changed externally, if you have +122 records,
by inserting this statement as your first //SYSIN DD *:
%LET MACEDGS= MACRO _LNEDGS +122 % ;
Thanks to Jim Bentley, AHOLD Information Services, USA.
Change 21.121 DB2 Trace IFCID=21 variable QW0021GS, input as $CHAR4.,
VMAC102 should have been variable QW0021GF, input as $CHAR1., and
Jul 14, 2003 variable QW0021CS should have been input as $CHAR1. Both
QW0021CS and QW0021GF are now formatted $HEX2. and
variable QW0021GS is no longer kept in T102S021 dataset.
-IFCIDs 251 and 257 internal QW0251xx and QW0257xx are now
input, formatted, and kept.
Thanks to Richard Link, BlueCross BlueShield of Illinois, USA.
Change 21.120 Condition Code variable NDMSCC is a character variable
VMACNDM with $HEX8. format, so it prints '00000000' for a zero
Jul 14, 2003 and '00000008' for an 8, but that is messy for testing,
so new variable NDMSCCNR, a numeric variable, is added to
the NDM datasets that actually contain condition code:
AE CH CT DP DT FP GF MC RJ RT PS PT SI WO
and is created with NDMSCCNR=INPUT(NDMSCC, &PIB.4.);
Variable NDMSCC was incorrectly kept in these datasets:
CE CI FI GO IF NL PI SB TI TP
that do not contain it, so it was removed from them.
Thanks to George Canning, Abbey National, ENGLAND.
Change 21.119 One debugging "PUT" statement should have been removed,
TYPETHST and the second one commented out.
TYPSTHST
Jul 11, 2003
Change 21.118 Support for AS/400 TCP and TCPIEF objects create two new
EXQAPTCP datasets:
EXQAPIFC dddddd dataset contents
IMACQACS QAPTCP QAPMTCP TCP Statistics
VMACQACS QAPIFC QAPMIFC TCP-IFC Statistics
VMXGINIT
Jul 11, 2003
Jul 23, 2003
Thanks to Roger Zimmerman, Hewitt, USA.
Change 21.117 Support for MainView for CICS 5.6 CMRDETL file (INCOMPAT)
VMACMVCI required changes to the T6ECPRID NE 'F4'x tests to GE as
Jul 10, 2003 the new version has T6ECPRID='F5'x. There are a few new
Jul 16, 2003 variables that were added to the datafile, including the
Jul 17, 2003 GMT Time Zone offset, MVCVTTZ. So with this change:
Variables STARTIME,ENDTIME,T6ETKSTR and T6ETKSTO are
now converted to Local Time Zone; previously, they were
in the GMT time zone. Fortunatly, if you were using
datetime variables CMRLBEGN or CMRLENDT in reports,
the have always been on the local time zone.
-A number of duration variables were not formatted with
TIME12.2; all now are.
-Variable T6EUCPUT was incorrectly read as PIB8; it is a
pair of time and count PIB4 fields, T6EUCPUT & T6EUCPUC.
Variable T6EUCPUT is now identical to existing T6ECPUR,
and T6EUCPUC counts CPU dispatches.
-File data is now correct; the file offset is now used to
locate the file data.
Thanks to Udo Froehling, Signal-Iduna, GERMANY.
Thanks to Reinhold Lehmann, Signal-Iduna, GERMANY.
Change 21.116 Major revisions to AIX PTX support. The original TYPEAIX
EXAIXCPN member read the "SpreadSheet" format and created only the
EXAIXDSK AIXPTX interval dataset, with cryptic variable names and
EXAIXFS "room" for only 3 disk drives, etc., because that design
EXAIXFSV requires a new variable name for repeated values. The new
EXAIXINT code will continue to create AIXPTX from SpreadSheet
EXAIXIPN format (recognizable by the text "TIMESTAMP" in 2nd
EXAIXLAN record), but that format is no longer recommended and
EXAIXMEK AIXPTX will be static (i.e., will be missing data).
EXAIXMER
EXAIXMEV This re-design reads the "comma" PTX output format (has
EXAIXPRO text "TIME=" in 2nd and following records), and creates
EXAIXPSP multiple datasets, properly supporting an unlimited
EXAIXPSP number of disks, lans, paging spaces, processes, etc.,
IMACAIX for objects with multiple instances per interval. New
VMACAIX AIXMEMR, AIXMEMV, and AIXMEMK provide data for the MEM
VMXGINIT Real, Virt, and Kmem records; other segments that are
Jul 9, 2003 written once per interval (CPU, PAGSP, PROC, SYSCALL and
SYSIO, at present) are output in AIXINTRV dataset.
DDDDDD MXG MXG
DATASET DATASET DATASET
SUFFIX NAME LABEL
AIXDSK AIXDSK AIX DISK DATA
AIXFS AIXFS AIX FS DATA
AIXFSV AIXFSV AIX FS VOLUME GROUP DATA
AIXLAN AIXLAN AIX LAN DATA
AIXCPN AIXCPUNR AIX CPU/CPUNUMBR DATA
AIXIPN AIXIPNET AIX IP/NETIF DATA
AIXMER AIXMEMR AIX MEM/REAL DATA
AIXMEV AIXMEMV AIX MEM/REAL DATA
AIXMEK AIXMEMK AIX MEM/KMEM DATA
AIXPSP AIXPAGSP AIX PAGESP/PAGESPAC DATA
AIXPRO AIXPROCS AIX PROC/PROCESS DATA
AIXPSP AIXPAGSP AIX PAGESP/PAGESPAC DATA
AIXINT AIXINTRV AIX INTERVAL DATA
(CPU/PAGSP/PROC/SYSCALL/SYSIO)
AIXPTX AIXPTX ARCHAIC "SPREADSHEET ONLY" INTERVAL
Some data appears to be completely destroyed when names
(process, file system, cpu number) are to long to fit in
the output file's LRECL; other data is ambiguous when the
three variables CPUACC, CPUMS, and CPUPCT are all trunc'd
to two positions of 'CP' in the PROC/CPUNUMBR records!
There are additional data (ICP/AREA, IP/ROUTING, IP/=,
TCP/=, UDP/=, RPC/CLSERV, NFS/SERV, and RTIME) that will
be supported (and create more datasets) when test data is
received to validate those data.
"INVALID OBJECT" messages with numbers for the object are
created in the PTX output file for Java processes that
have extremely long names; PTX cuts off the process name
at a specific maximum assumed length, and important info
is lost in the name pattern. One solution is to have the
application developer use shorter process names, but the
issue is still being investigated in Nov, 2003.
Thanks to Sam F. White, CocaCola, USA.
Thanks to C. Tim Browning, Coca-Cola Enterprises, USA.
Change 21.115 Support for APAR PQ71799 HTTP Server SMF 103 record fixes
VMAC103 errors in data, adds new variables, and adds options to
Jul 7, 2003 "separate" and "sync" SMF 103 records. See extensive
notes in the APAR text. Variables added to TYPE1032:
APLENVNM='APPLICATION*ENVIRONMENT*NAME'
CGIREQST='CGI*REQUESTS'
DNSLOKUP='DNS*LOOKUP*DIRECTIVE'
PROXYRES='PROXY*RESPONSES'
REQCOUNT='REQUEST*COUNTER'
SRVICPLG='SERVICE*PLUGINS'
SSLHANDS='SSL*HANDSHAKES'
SUBSYS ='SUBSYSTEM*NAME'
The first and last variables are also added to TYPE1031.
Change 21.114 The JCL example still had double single-quotes after each
JCLTEST6 MXG2102 that should have been a single single-quote.
JCLTEST8
Jul 7, 2003
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 21.113 -Only the first 99 service class names were examine in the
UTILRMFI VMXGRMFI parsing of its arguments, and arbitrary limit
VMXGRMFI that is now increased to 999 names in each argument list.
Jun 27, 2003 -KEEPALL=NO is now specified for the TYPE70 logic, so that
the new more-than-16-CPUs-in-TYPE70 logic in VMXGRMFI
won't fail if you read an old PDB with VMXGRMFI.
Thanks to Jay Brookover, First Citizens, USA.
Change 21.112 Variables CPUDETTM, Dependent Enclave CPU time, exists in
BUILD005 PDB.SMFINTRV, but it was not kept in PDB.STEPS, and was
BUIL3005 not summed into PDB.JOBS, until this change did so.
Jun 27, 2003
Thanks to Brenda Rabinowitz, The Prudential Insurance Co., USA.
Change 21.111 Variables GBLCACSA and GBLCAC24 should have been divided
VMAC28 by GBLSAMPL, to get their average values in NPM dataset
Jun 26, 2003 NPMVSVGB (VTAM Global Resourcesd).
Thanks to Andre D. Walker, Bank of America, USA.
Change 21.110 RMF type 78 subtype 2 "Job-Level Virtual Storage Monitor"
VMAC78 sections for "Early Address Spaces" may have invalid data
Jun 25, 2003 ('070E000000000000'x) for R782RDTM/R782RDDT, causing the
INVALID DATA FOR READTIME messages and dumps on the log.
This change adds the "??" modifier to the READTIME INPUT
to suppress the message and hex dumps, so READTIME will
still be missing, so you could identify which JOBs had
invalid values in TYPE78PA. You can identify your Early
Address Spaces by looking JOB in TYPE30_6 dataset, as it
only contains the obs for your Early ASID jobs. If you
find JOBs that are not Early ASIDs, then you probably
have CA's CA-7 Job Scheduling Product (which modifies the
read date/time of jobs under it's control) and you need
to contact CA Technical Support to correct their error.
Thanks to Josep Miquel, La Caixa, ESPAGNE.
Change 21.109 SYSTEM record with NRDATA=35 was unexpected; the record
VMACNTSM was from an NT 4.0 system with Service Pack 6, and NTSMF
Jun 25, 2003 was at PRFSENVR=2.4.4 and VERSION=2.2.2. The discovery
records show that six fields (five %total xxxxx time and
total interrupts) are repeated (just like NRDATA=32 case)
so there was no new data, just another exception now
covered!
Thanks to Xiaobo Zhang, ISO, USA.
Change 21.108 -In VMXG70PR, new variables LPnNSW for each LPAR, labeled
VMAC7072 LP1NSW ='LPAR 1*PERCENT WHEN*LPAR WAS*SOFT CAPPED'
VMXG70PR are created in PDB.ASUM70PR and PDB.ASUMCEC datasets,
Jun 26, 2003 from SMF70NSW.
-Labels for some capping-related variables were revised:
In TYPE70PR dataset:
SMF70NSW='PCT WHEN*LPAR WAS SOFT CAPPED*BY WLM'
In TYPE72GO dataset:
PCTDLCCA='RESOURCE*GROUP*CAPPING*DELAY*PERCENT'
PCTDLCDE='CPU*DELAY*PERCENT*INCLUDES*WLM CAP'
-Labels for variables PCTLGBY and PCTLGOV were corrected
to LPAR 16 and blank variables PCTLNBY and PCTLNOV are
now labeled for LPAR 23.
Thanks to Harry Price, Florida Power and Light, USA.
Thanks to Freddie Arie, TXU, USA.
Change 21.107 Support for WebSphere APAR PQ74463 that adds CPU time to
VMAC120 SMF 120 Version 5.0 records; that APAR pointed to new SMF
Jun 24, 2003 record documentation, and I found many new fields were
added by Version 5; all are now input and kept.
Datasets: TYP120SA,TYP120SI,TYP120JC,TYP120JI,TYP120WI:
SM120CEL='WEBSPHERE*CELL*NAME'
SM120NOD='WEBSPHERE*NODE*NAME'
Datasets TYP120JC and TYP120JI:
SM120JME='EJBLOAD*INVOCATIONS'
SM120JMF='EJBLOAD*AVG*EXECUTION*TIME'
SM120JMG='EJBLOAD*MAX*EXECUTION*TIME'
SM120JMH='EJBSTORE*INVOCATIONS'
SM120JMI='EJBSTORE*AVG*EXECUTION*TIME'
SM120JMJ='EJBSTORE*MAX*EXECUTION*TIME'
SM120JMK='EJBACTIVATE*INVOCATIONS'
SM120JML='EJBACTIVATE*AVG*EXECUTION*TIME'
SM120JMM='EJBACTIVATE*MAX*EXECUTION*TIME'
SM120JMN='EJBPASSIVATE*INVOCATIONS'
SM120JMO='EJBPASSIVATE*AVG*EXECUTION*TIME'
SM120JMP='EJBPASSIVATE*MAX*EXECUTION*TIME'
SM120JMQ='AVG*CPU*TIME'
SM120JMR='MIN*CPU*TIME'
SM120JMS='MAX*CPU*TIME'
Dataset TYP120SA:
SM120WCP='TOTAL*WLM ENCLAVE*CPU TIME'
Dataset TYP120SI:
SM120TEC='TOTAL*WLM ENCLAVE*CPU TIME'
SM120NHS='HTTP*SESSIONS*EXIST*AT END'
SM120NHA='HTTP*SESSIONS*ATTACHED*AND ACTIVE'
SM120BTH='BYTES*TO SERVER*FROM ALL*CLIENTS'
SM120BFH='BYTES*FROM SERVER*TO ALL*CLIENTS'
Change 21.106 Variable ENDTIME was incorrectly converted back to GMT;
VMACWWW raw log values of: [22/Jun/2003:23:32:54 +0400] are
Jun 24, 2003 the local time followed by the delta to add to convert
to GMT, but I thought the datetime was GMT and the +0400
was the GMT offset, and so ENDTIME ended up back on GMT.
The GMT conversion code was removed so ENDTIME is on the
Local time zone; new variable GMTOFFTM is created in case
you need to convert back to GMT or to know the zone.
The above example from Eastern Daylight Savings offset
of +0400 will have GMTOFFTM= -4 hours, consistent with
all GMT offset values, normally used in conversion:
LOCAL = GMT + GMTOFFTM;
So to convert WebLob ENDTIME back to GMT, you'd use:
ENDTIME = ENDTIME - GMTOFFTM;
Thanks to Jim Agrippe, Cleveland Clinic Foundation, USA.
Change 21.105 MXG 20.20 ASUMCICS caused zero observations in PDB.CICS
ASUMCICS if the input CICSTRAN was on tape. ASUMCICS has always
ASUMCICT caused two mounts (one open to test if CICSTRAN has data,
ASUMCICX reading one record, then one open to read the data), but
Jun 25, 2003 MXG 21.02 caused the full dataset to be read twice.
All of that complexity and exposure was so that ASUMCICS
would figure out if you had IBM or Landmark CICS data to
be used to create your PDB.CICS summary dataset.
But I do not recommend that you use ASUMCICS; with MRO,
CICS creates multiple observations in CICSTRAN/MONITASK
for one "unit of work", so that a PDB.CICS built from
CICSTRAN/MONITASK won't count user transactions, and all
CPU time will be under the TRANNAME=CSMI,etc.
Instead, you should have been using the ASUMUOW member
(if you have CICSTRAN data), or the ASUMUOWT (if you
have the MONITASK data), to first create PDB.ASUMUOW
dataset (one obs per "unit of work", correct TRANNAME,
etc) and use that for your CICS response measurement.
Then include the ASUMCICX member, which used PDB.ASUMUOW
as the input to create the PDB.CICS summary dataset.
To eliminate the multiple opens and complexity, I have
made an INCOMPATIBLE change, but only if you were using
ASUMCICS to summarize Landmark's MONITASK data:
Instead of using ASUMCICS to read MONITASK data, you
must use new ASUMCICT to create PDB.CICS from MONITASK.
If you were (wisely) using ASUMUOWT and ASUMCICX to
create your PDB.CICS from Landmark MONITASK, there is
no change required to your daily job.
To summarize what these members do after this change:
ASUMCICS - Reads only CICSTRAN, creates PDB.CICS.
ASUMCICT - Reads only MONITASK, creates PDB.CICS.
ASUMUOW - Combines CICSTRAN,DB2ACCT, creates PDB.ASUMUOW
ASUMUOWT - Combines MONITASK,DB2ACCT, creates PDB.ASUMUOW
ASUMCICX - Reads only ASUMUOW, creates PDB.CICS.
Verically: use ASUMCICS or ASUMCICT (left pair) if you
need the "old" PDB.CICS ("CSMI" tranname, segment counts)
but most sites should use one of the right pair, using
ASUMUOW/ASUMCICX for IBM, or ASUMUOWT/ASUMCICX for ASG,
to first create PDB.ASUMUOW (correct TRANNAME, counts a
unit-of-work as a transaction), and then create PDB.CICS
from that PDB.ASUMUOW data.
IBM ASG IBM IBM ASG IBM
dataset: CICSTRAN MONITASK CICSTRAN DB2 MONITASK DB2
program: ASUMCICS ASUMCICT ASUMUOW ASUMUOWT
dataset: PDB.CICS PDB.CICS PDB.ASUMUOW PDB.ASUMUOW
program: ASUMCICX ASUMCICX
dataset: PDB.CICS PDB.CICS
===wrong TRANNAME=== ====correct TRANNAME=====
==obs per CICS segment= ====obs per CICS UOW====
==not the recommended = ====the recommended=====
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 21.104 OAM SMF type 85 records R85PVRM '130' caused STOPOVER and
VMAC85 INPUT STATEMENT EXCEEDED error condition in subtype 74
Jun 23, 2003 records. Four tests for R85PVRM GE '150' were changed
to R85PVRM GE '130' as these new records contain those
fields thought to have been added by their 1.5.0 level.
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Change 21.103 The copying of WEEK4-WEEK5, WEEK3-WEEK4, WEEK2-WEEK1 and
BLDNTPDB WEEK-WEEK2 was relocated to be just prior to building of
Jun 12, 2003 the new WEEK pdb on the first day of the week; it will
also note on the log what is being done for you.
Thanks to Terry Heim, ECOLAB, USA.
Change 21.102 STK IXFP Iceberg SMF records fix L2P00A2 and LZP00A9 are
VMACICE already supported by MXG; the fix corrects a problem with
Jun 9, 2003 records being created that were greater than 32756 bytes;
the fix creates multiple records when necessary, and has
two new count fields added, but those fields are not
needed for MXG to handle the multiple records, so there
is no change to MXG needed for those fixes.
Records with the fixes have been read and validated.
However, SNAPDUR was corrected; it has always been wrong
by a factor of ten, because the documentation had it in
"hundredths" when it is actually in milliseconds.
Thanks to Mikal W. Green, STK, USA.
====== Changes thru 21.101 were in MXG 21.02 dated Jun 9, 2003=========
Change 21.101 CICSTRAN variable CPURLSTM was not multiplied by 16 when
VMAC110 created by VMAC110 for CICS/TS 1.1 or later, but if you
Jun 9, 2003 used UTILEXCL, it correctly multiplied by 16 for all CICS
versions. VMAC110 was revised to correctly calculate the
CPURLSTM for all versions. CPURLSTM is valid CPU time and
is included in variable CPUTM; fortunately, CPURLSTM is
usually small.
Thanks to Vernon Kelly, IBM Global Services, USA.
Change 21.100 CICSTRAN variable RTYPE has two new values, 'F' and 'S',
FORMATS that are now decoded by the $MG110RT format:
Jun 9, 2003 'C'='C:TERMINAL CONVERSE'
'D'='D:USER EMP DELIVER REQUEST'
'F'='F:FREQUENCY REQUEST'
'M'='M:SEMI-PERMANENT MIRROR SUSPEND'
'S'='S:SYNCPOINT'
'T'='T:TASK TERMINATION'
Thanks to Diane Eppestine, SBC, USA.
Change 21.099 Support for ten new NDM subtypes; this is incomplete;
VMACNDM only the skeleton set of variables is created for each
Jun 8, 2003 subtype, but all of the new members and VMXGINIT macros
exist, so only VMXGNDM will likely need to be updated;
just got DSECTs and no time to write the code today.
Thanks to Peter Lines, Royal Bank of Scotland, SCOTLAND.
Change 21.098 These TYPE7204 variables that contained 'SUM OF ALL'
VMAC7072 R724ACTF /*SUM OF ALL ACTIVE FRAMES*/
Jun 8, 2003 R724IDLE /*SUM OF ALL IDLE FRAMES*/
R724SLOT /*SUM OF ALL SLOTS USED*/
R724DIV /*SUM OF ALL DIV FRAMES*/
R724FIX /*SUM OF ALL FIXED FRAMES*/
in their label are now divided by NRSAMPLE to change
their value to the more useful and expected average
value for the interval, and 'SUM OF ALL' was removed from
their labels.
These variables had correct values because MXG did divide
by NRSAMPLES, but still had 'SUM OF ALL' in their labels:
R724TSV /*SHARED PAGE VIEWS*/
R724VIN /*VALID SHARED PAGES IN CSTOR*/
R724VLC /*SHARED PAGE VALIDATIONS*/
R724GPI /*SHARED PAGEINS FROM AUX*/
which is now removed.
And these variables were correct by accident, as they had
the average value already, but MXG had 'SUM OF ALL':
R724USER &PIB.4. /*USERS*FOUND*/
R724ACTV &PIB.4. /*ACTIVE USERS*FOUND*/
so only the label was changed and no division required.
The IBM documentation in both the SMF Manual and DSECTS
are incorrect for USER and ACTV variables; it took real
RMF data to revise the code to decode the data.
Thanks to Lawrence Jermyn, Fidelity, USA.
Change 21.097 -Support for CA/TMS PDC # QI30130 which adds 4 variables:
TYPETMS5 to the TYPETMS (Volume) dataset:
VMACTMS5 COMPRES ='PCT SPACE*SAVED*DUE TO*IDRC COMPRESS'
Jun 8, 2003 CTLGCNT ='NR TIMES*DATASET WAS*UNCATALOGED'
FILPERC ='PCT OF*PHYSICAL SPACE*USED BY*FILE'
VOLPERC ='PCT OF*PHYSICAL SPACE*ON VOL*IN USE'
and adds the first 3 variables to the TYPEDSNB (file)
dataset.
-Support for TRTCH='EC'x,'ED'x decode for 3590-384T
(standard) and 3590-384X (extended length cart) 3590
devices with 384 tracks.
-Variables B1INT and B1DIS were replaced by the new fields
and no longer exist.
Thanks to Len Rugen, University of Missouri, USA.
Change 21.096 Support for GEPARMKY=001B (PRTQUEUE) creates new variable
IMAC6ESS ESSPRQUE in TYPE6 if IMAC6ESS is used to decode ESS data.
VMAC6ESS The 001B also caused INPUT STATEMENT EXCEEDED error if
Jun 6, 2003 had a tailored, earlier IMAC6ESS in your USERID.SOURCLIB.
Thanks to Reinhard Nitsch, Provinzial Versicherungen, GERMANY.
Change 21.095 -Support for six new TNG objects from NT:
EXTNT036 ACTIVE SERVER PAGES, DISTRIBUTED TRANSACTION,
EXTNT037 HTTP INDEXING SERVICE, INTERNET INFORMATION,
EXTNT038 PRINT QUEUE, and WEB SERVICE,
EXTNT039 that create NT036 thru NT041 datasets.
EXTNT040 -Support for new fields in LOGICALDISK, PHYSICALDISK,
EXTNT041 MEMORY, SYSTEM, and UDP objects.
FORMATS -Support for 1-Header record, found only in a "Monthly"
IMACTNG TNG Performance Cube.
VMACTNG
VMXGINIT
Jun 8, 2003
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
====== Changes thru 21.094 were in MXG 21.02 dated Jun 5, 2003=========
Change 21.094 Calculation of MSU4HRAV in PDB.RMFINTRV was revised. It
VMXGRMFI was incorrect in several instances: after a change in RMF
Jun 5, 2003 interval value, or after an IPL, and it was calculated
when it should not have been, notably, if there was a gap
in the data. It can still be missing when SMF70LAC is
not, and it can be different from SMF70LAC when there are
not four hours of data available to MXG.
Thanks to Frank De Bree, DEXIA, BELGIUM.
Thanks to Mark Nouwen, DEXIA, BELGIUM.
Change 21.093 PDB.ASUMUOW corrections (SYSTEM could be blank) and logic
VMXGUOW revisions more robustly handle CICS and DB2 data merge.
Jun 5, 2003 -Several variables, including QWACAJST added to SUM= list.
-Added HOLDSTRT/HOLDEND to RETAIN, and a DATA step to get
the FIRST.UOWIDCHR values, to correct an exposure that
could have caused missing STRTTIME and wrong ELAPSTM.
-Corrected LAST.UOWIDCHR logic that was assigning blanks
for the SYSTEM variable for CICS-only work.
-Moved &OUTCODE to the end of the DATA step, for safety.
-Formatted WAITTOTM as TIME12.2.
-If an OBS was SPUN, when it came back in, if any MIN/MAX
variables had been specified, the values from SPIN were
not used in the MIN/MAX calculation, but now are.
These changes were suggested with implemenation examples!
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 21.092 User records RMDS,SYNC,WYLA,WYLB,HSM,TSMO,COM,M204 might
UTILBLDP have zero obs; those products have non-standard _aaaaID
Jun 4, 2003 macro names for their SMF IDs, or they create multiple
multiple SMF records and they all require separate tests,
but only 2 of 3 places had been fully updated to protect
all of these special user records. The error only
occurred whenf %LET MACKEEP= was used.
Thanks to Scott Barry, SBBWorks, Inc, USA.
====== Changes thru 21.091 were in MXG 21.02 dated Jun 3, 2003=========
Change 21.091 A major revision of support for RMF III VSAM files.
ASMRMFV Changes to ASMRMFV in particular are to position the code
CLRMFV for future upgrades to handle more RMF III tables.
DOCLRMFV -When ENDTIME of a MINTIME interval was the same as the
Jun 3, 2003 STARTIME of the next MINTIME interval, it was incorrectly
selected. RMF III almost always has the same time for
the end of one MINTIME interval and the start of the
next. Only noticed when testing for a single minute to
be selected, but two were output.
-Parameter processing completely rewritten to be table
driven, allowing new keywords and keyword aliases to be
easily added for new table support.
-Parm keywords have shorter aliases to fit in the JCL
limit of 100 characters for a parameter. The full list
of all alias names are given in the DOCLRMFV member.
NOxxx names added to assist.
-Max LRECL=32760 (increased from incorrect LRECL=32756).
-Date selection formats expanded YYYDDD YYYDDD YYDDD YDDD
DDD DD or D.
-Time-based selection added, with FROMTIME/TOTIME= parm
and HHMM, HMM, MM, or M formats, plus FROM/TO= nn, for
relative number of days before or after today.
-ASMRMFV output reports MXG Last Change Number in output,
includes DSNAME and filtering counts, and a summary if
multiple systems are processed, min/max times, etc.
NODETAIL keyword will suppress the detail reports.
-Debugging enhancement in RMFSKIP option.
-ENC record outputs only one per enclave, correcting case
where extensive use of Enclaves caused the RMF output
record to exceed the output LRECL limit.
-An (unexpected) Table ID mismatch will cause ASMRMFV to
issue a message and then ABEND.
Changes to the CLRMFV CLIST that executes ASMRMFV:
-The changes in CLRMFV are not backwards compatible; this
version must be used with the revised ASMRMFV program.
-PARM keyword default is no PARM('-D'), equivalent to the
old default of PARM('ALL,NODVT')
-New keyword RMFSKIP(NO) to control optional debugging.
-New keyword ONECALL(YES). This allocates all RMF III
Monitor Files for an LPAR first, and then calls ASMRMFV
once to process all records from that LPAR.
(Code ONECALL(NO) to invoke ASMRMFV once for each file,
which is how it was in prior versions).
The default YES should be best for typical use; ASMRMFV
specifies FREE=CLOSE internally so that each RMF III file
is freed after it was read, and the SHR enqueue released
as soon as possible. This produced a 9-11% reduction in
elapsed and CPU time with ONECALL(YES) default.
-Allocation messages show DDNAME
-New keywords FROMTIME/TOTIME added to support time based
data selection in ASMRMFV.
A special thanks to Acxiom management for allowing this
MXG user to contribute these enhancements for others!
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 21.090 Multiple enhancements to CICS summarization:
ASUMCICS -Macro _BSUCICS is used in the BY list instead of the
ASUMCICX list of specific variables, to be consistent and in case
TRNDCICS of future changes. Aug 7: this change caused variable
TRNDCICX DATETIME to not be created in PDB.CICS in MXG 21.02-03.
Jun 3, 2003 STRTTIME, which has always been the correct variable to
Jun 4, 2003 use, was not affected. But Change 21.145 reinstated the
Aug 7, 2003 creation of variable DATETIME in PDB.CICS, so you would
not have to cange your reports to use STRTTIME.
-SHIFT and SYSTEM added to the BY list.
-Modified to carry the values used to set the buckets in
variables RESPVAL1-RESPVAL7, and comments placed around
the place to reset the values for "User Change".
-The FLOOR(IRESPTM) was removed, so that fractional values
can be used for the RESPVALn bucket values.
-ESUCICS is used to control the output of CICS dataset.
-Macro variables SUCIVAL1-SUCIVAL7 are created so that the
response buckets values can be set externally, and macro
variable SUCIINTV externalizes the summarization interval
(with HOUR as the default). The chosen interval value is
imbedded in the dataset label, while the response bucket
values are imbedded in the variable labels for RESPBKTx.
-For Trending, macro variable TRCIINTV sets the interval
default of WEEK.
Note: We generally do NOT recommend the use of ASUMCICS
and TRNDCICS, based on CICSTRAN dataset, because
CICSTRAN has an obs for each segment of an MRO
unit of work; CICSTRAN observation are incomplete:
- the TOR obs has no CPU time, but has the real
TRANNAME and LUNAME
- the AOR obs has all of the CPU time, but its
TRANNAME is 'CSMI' (the mirror transaction).
- observation counts are not transaction counts.
Instead, we recommend you include ASUMUOW first,
to create the PDB.ASUMUOW "unit of work" dataset,
which has one observation for each UOW with the
correct TRANNAME, LUNAME, CPUTM, IRESPTM, etc,
and then include ASUMCICX, which reads ASUMUOW to
create a PDB.CICS dataset that summarizes UOWs.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 21.089 New MICSMXG member contains notes and comparisons from
MICSMXG users who have replaced CA's MICS with MXG Software.
Jun 2, 2003
Change 21.088 Execution under ASCII only.
ANALCISH -VMACDB2H. NETSNAME was incorrectly TRANSLATEed; the
VMACCRAY statement TRANSLATE(NETSNAME,'00'X,'40'X); needs to be
VMACDB2H TRANSLATE(NETSNAME,'00'X,' '); to execute under ASCII,
VMACEREP so that blanks (which are '20'x on ASCII) are converted
VMACSFS to hex zeroes.
VMACTMDB -All TRANSLATE() statements were examined, and these
VMACTMS5 members had similar incorrect-under-ASCII-only-syntax:
VMACTMVS VMACCRAY, VMACEREP, ANALCISH, VMACSFS, VMACTMDB,
VMACTSOM VMACTMS5, VMACTMVS, and VMACTSOM
Jun 2, 2003
Thanks to Matthew T. Chappell, Queensland Transport, AUSTRALIA.
Change 21.087 New variable MPL74 is created in the TYPE74 dataset, as
ANALFIOE MPL74=SUM(DEVCONTM,DEVDISTM)/DURATM;
VMAC74 LABEL MPL74='IO*MULTI*PROGAMMING*LEVEL'
Jun 3, 2003 an estimate of the concurrent I/Os to this device.
Jun 4, 2003
New ANALFIOE member reads TYPE73, TYPE74 and TYPE78CF to
create two new datasets:
TYPE74OE - Sums the MPL74 for each LCU from TYPE74.
TYPE73OE - The LCUs from FICON channels are selected,
and their I/O is uniformly distributed to
each CHPID in that LCU, and each CHPID's
concurrent "Open Exchange" variables are
estimated in these variables:
MPL73 ='ESTIMATED*FICON*OPEN*EXCHANGES'
IORATE ='ESTIMATED*FICON*CHANNEL*IORATE'
OEDURATM='EST*OPEN*EXCHANGE*msec per io'
The TYPE73OE is just the original TYPE73
with these variables added for FICON CHPID.
The MPL73, or "Open Exchanges" appears to be a useful
new metric for detecting saturation in FICON channels;
See http://www.perfassoc.com/publishedpapers for Pat's
"Understanding FICON Channel Path Metrics" article.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 21.086 Support for IDMS Performance Monitor type 30 subtype 3.
IMACACCT In addition to the user SMF record created by PERFMON,
VGETJESN that CA product also creates SMF type 30 subtype 3
VMAC30 records at transaction end. These are very-old-format
May 30, 2003 subtype 3 that do not contain JCTJOBID nor SUBSYS (fields
SMF30JNM/SMF30WID) causing TYPETASK NOT DECODED messages.
The record has a (very old length=14) Product section,
a (very old length=124) ID Section (causing INTBTIME
to be, and which caused ITSV to error these records as
it uses INTBTIME for its DATETIME validation!), a
Completion section, and a Storage Section, but it does
not have the UREC, CPU, PERF, OPER or EXCP sections.
The record is identifiable because PRODUCT (SMF30PNM)
is 'PERFMON'.
It does have useful information about each transaction,
in the unique accounting fields, with different fields
for batch, DC/UCF, and CICS access to IDMS.
-VGETJESN recognizes PERFMON records, sets TYPETASK='STC'
and SUBSYS='PERFMON'.
-IMACACCT contains a comment block around the PERFMON code
that creates these IDMS variables from the Account field
IDMSCPTM='IDMS*TRANSACTION*CPU*TIME'
IDMSTID ='IDMS*TASK*ID*NUMBER'
IDMSACT1='IDMS*BATCH*ACCOUNT*ONE'
IDMSACT2='IDMS*BATCH*ACCOUNT*TWO'
IDMSTRN ='IDMS*ERUS*TRANSACTION*ID'
IDMSTRM ='IDMS*ERUS*TERMINAL*ID'
IDMSOPR ='IDMS*ERUS*OPERATOR*ID'
IDMSTSK ='IDMS*DC/UCF*TASK*CODE'
IDMSLTE ='IDMS*DC/UCF*LTERM'
IDMSBLG ='IDMS*DC/UCF*BILLING*GROUP'
and when you remove the comment block, those variables
will then be output in TYPE30_V, PDB.SMFINTRV, XSMFINT
datasets. IMACACCT also populates INTBTIME if it is
still missing in these PERFMON type 30 records.
-VMAC30 was updated to output the IDMS variables if they
have been created; unrelatedly, those LENACCT1-LENACCT9
variables that exist will now be output in TYPE30_V; they
should have been there all along!
Thanks to Martin Legendre, Regie des Rentes du Quebec, CANADA.
Change 21.085 Protection for 0 length records, which are not created by
VMACNTSM NTSMF product, but have been unintentionally created by
May 27, 2003 user's SAS programs that copied raw data filed. On MVS,
the records actually have length 1.
Thanks to Uriel Carrasquilla, NCCI, USA.
Change 21.084 Type 42 Subtype 8 (which is not yet documented in the SMF
VMAC42 manual) caused ERROR.VMAC42.CLLEN and hex dump of the SMF
May 23, 2003 record. The record did not contain a CL segment, but MXG
did not test NRCL to see there was no segment before it
printed the error message. However, the record was then
deleted, whereas now it is output.
Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.
Change 21.083 With either RUNWEEK=WEEK or RUNWEEK=WTD, the rolling of
BLDNTPDB weekly datasets was occurring at the wrong time, causing
May 23, 2003 weeklies with no data.
Thanks to Terry Heim, ECOLAB, USA.
Change 21.082 GPARMKY=002F segment in SMF 6 Extended ESS data is now
IMAC6ESS recognized and decoded into new variable ESSNOTFY that
VMAC6 will be kept in TYPE6 dataset (only if IMAC6ESS has been
May 19, 2003 tailored and its commment block un-commented). Some
May 23, 2003 misspellings were discovered and corrected, and all of
May 26, 2003 the $VARYING fields are now translated to $EBCDIC; a few
had been overlooked.
-GEPARMKY=002E segment decoded, ESSULIB1-ESSULIB4 for up
to four DSNAMEs of USERLIBs.
-GEPARMKY=002B, 002C decode OUTDISP NORMAL/ABNORMAL in the
ESSOUTDB and ESSOUTDC flag variables.
-GEPARMKY=001B is now correctly decoded with 001B instead
of 000B in the IF test; variable ESSUCS is expanded to
four bytes to match the size of the UCS field.
-GEPARMKY=0021 is supported in ESSPMISG flag variable.
-A 002C segment with unexpected GEPARMLN=0 was found, so
all segments are protected for a zero length, and that
segment's variables are not created.
Thanks to Reinhard Nitsch, Provinzial, GERMANY.
Thanks to Denny Wong, New York Life, USA.
Change 21.081 The Undocumented +2 bytes for alignment are after SMSMC,
VMACCTLT not after DDSPOS, which caused wrong values for BLOCKCT
May 19, 2003 and DDSCSIZE thru DDSPOS. The +2 statement was moved.
Jul 8, 2003 -The BLKSIZE field had been relocated to the end of the
Jul 25, 2003 record as a 4-byte field, but that was overlooked in the
Jul 28, 2003 MXG support - 8Jul03.
-MXG 21.02 only: CTLT Version 5 created zero observations
because it has LRECL=460; MXG logic changed to test for
... 400 LE LENGTH LE 460 ....
in two places to read V4, V5, and V6 records. 25Jul03
Thanks to Francesco Bragadin, Phoneix Spa, ITALY
Thanks to Rob Gibson, CPR, AUSTRALIA.
Change 21.080 The example JCL procedure name of MXGSASV8 is now used in
JCLMNTH place of the old MXGSAS example name, to point new users
JCLMONTH to the correct, current JCL procedure example for SAS V8.
JCLWEEK
JCLWEEKT
May 19, 2003
Thanks to Matthew Collier, Oklahoma State University, USA.
Change 21.079 SMF 80 with APPLNAME less than 8 caused INPUT STATEMENT
VMAC80A EXCEEDED in RACFTYPE=20 segment, due to hard-coded input
May 19, 2003 with $EBCDIC8. Now, the RACFDLN=7, etc is honored.
Thanks to John Grasing, MetLife, USA.
Change 21.078 The optional CA-Dispatch variables are now automatically
IMACCADI added to PDB.PRINT dataset, when you open the comment
May 14, 2003 block in your IMACCADI member. By adding a %LET ADD6= ..
statement, the BUILDPDB &ADD6 macro will be added to the
KEEP= list for PDB.PRINT dataset.
Thanks to Dan Adams, NITC, USA.
Change 21.077 Variables EXCPDASZ EXCPTAPZ IOTMDASZ IOTMTAPZ RACFUSRZ
ANALDSET SELAPSTZ STEPTIME were not initialized, sometimes causing
May 14, 2003 their counterpart variables to be incorrect.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.076 Variables QWACSPEA QWACSPEB QWACSPNE QWACSPTT for Stored
VMXGUOW Procedure activity are now included in the PDB.ASUMUOW
May 5, 2003 dataset.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.075 This TCP/IP report example was truncating leading chars
ANALTCP of Host Name, and had additional revisions.
May 2, 2003
Thanks to R. Wells, American General Finance, USA.
Change 21.074 IBM documentation for the raw units of time in RMF III's
VMACRMFV DVT table was incorrect; instead of 128 microsecond units
May 2, 2003 the fields used to calculate CONNTM, PENDTM, DISCTM,
DVBUSYTM, CUBUSYTM and SWPODLTM are in 2048 microsecond
units, so those variables are now corrected in the ZRBDVT
dataset.
Thanks to Betty Wong, Bank of America, USA.
Change 21.073 Format MGPDSTY is updated for PDSMAN Version 7.41 which
FORMATS has new value "E:EXEC', used in TYPEPDSM support.
May 2, 2003
Thanks to Rob d'Andrea, Royal Bank of Scotland, SCOTLAND.
Change 21.072 ESAMAP v2.2 caused SHORT SEGMENT errors. MXG code had
VMACXAM not been tested with that earlier release. MXG code in
May 2, 2003 XAMSYS for MTRMEM, SYTSYG, and STOASI, in XAMCPU for
SYTRSP, and in XAMDEV for CONFIG and IODDEV was revised
to read the shorter segments.
Thanks to Tony Lobley, EDS, ENGLAND.
Change 21.071 If you used %VMXGTIME/TIMEBILD to shift time zones, you
VMAC30 could have negative RDRTM, and it was possible that
May 1, 2003 ALOCTIME and/or LOADTIME could have had the wrong date.
The calculation of RDRTM was moved above the %VMXGTIME
for REND, and the logic to set dates for ALOC/LOAD times
was precedeed by %VMXGTIME with REVERSE=YES, and then all
four datetimes (INIT,TERM,ALOC,LOAD) were un-REVERSED.
Thanks to Chuck Hopf, MBNA, USA.
Change 21.070 Variable RDRETDAT should have been FORMATed DATE9., and
VMACEDGR now it is.
Apr 30, 2003
Thanks to Barry McQueen, Department of Defence, AUSTRALIA.
Change 21.069 Exit member EXUTILEX allows you to process a non-standard
EXUTILEX "User" segment (i.e., your CICS guru created a segment
UTILEXCL but did not use "USER" for the CMODNAME/CMODHEAD entries.
Apr 25, 2003 Comments in EXUTILEX show how to reset the CMODNAME/HEAD
Nov 3, 2003 values to "USER" so that MXG will generate IMACICUS call.
You will also, then, have to update IMACICUS to tell MXG
the length of data to be kept in the USERCHAR variable.
Nov 3, 2003 documentation update:
Using this EXUTILEX member solved USERCHAR always blank.
One site's Hogan data segment was named "HOGAN", and so
the IMACEXCL member created by UTILEXCL did not contain
the call to IMACICUS, where the site's code to decode the
Hogan data was located, but the UTILEXCL program didn't
see a "USER" segment, so it did not generate an include
for the IMACICUS code, so USERCHAR was always blank.
By using this (new) EXUTILEX exit, you can tell UTILEXCL
to treat your "HOGAN" segment as if it were named "USER".
An error "BY VARIABLES MUST BE IN FIRST 4096 BYTES" was
seen with SAS Version 6, but not with SAS Version 8+, so
run UTILEXCL under V8+ to be error-free.
Thanks to Michael Creech, Fidelity Information Services, USA.
Thanks to Herb Strozinsky,US Bank, USA.
Change 21.068 MXG variable VELOCIOD when I/O Priority Management is NOT
VMAC7072 enabled (i.e., R723VELI=' ') did not match IBM RMF report
Apr 24, 2003 value: MXG was including PCTDLTDQ (R723CTDQ) in the denom
but IBM's calculation does not include that value. MXG
was changed to match the IBM reports, assuming they are
correct.
Thanks to Russell Dewar, National Australia Bank, AUSTRALIA.
Change 21.067 -SYSPLEX was not in the BY list for TRNDRMFI, but now is.
VMXGRMFI -Variable PCTMVSBY is added to PDB.RMFINTRV and TRNDRMFI.
Apr 18, 2003 -In Trending logic, EXRMFINT is now invoked; without that
logic, variables dropped from RMFINTRV in EXRMFINT were
not being dropped in the TRNDRMFI dataset.
-Invoking VMXGRMFI twice, using PDB=PDB logic to create
two levels of summary (like RMFINTRV and RMFINTHR, as
suggested in comments in the original RMFINTRV member)
corrupted the SPINRMFI dataset so it did not keep enough
data for correct calculations of MSU4HRAV. The example
is revised, and the TREND logic should be used for the
second summary, to eliminate SPINRMFI corruption:
%VMXGRMFI(PDB=PDB,
OUTDATA=PDB.RMFINTRV,
INTERVAL=DURSET);
%VMXGRMFI(PDB=,TRENDIN=PDB.RMFINTRV,
TRENDOLD=,
TRENDOUT=PDB.RMFINTHR,
TRENDINT=HOUR);
%VMXGRMFI(PDB=,TRENDIN=PDB.RMFINTRV,
TRENDOLD=,
TRENDOUT=PDB.RMFINTDY,
TRENDINT=DATE);
These examples assume the IMACWORK=YES default, i.e., the
workload definitions are in your IMACWORK member. If you
instead invoke %VMXGRMFI with IMACWORK=NO and use its
WORKnn= arguments to define your PDB.RMFINTRV workloads,
then you must specify those same WORKnn= arguments when
you use the VMXGRMFI to create TREND.TRNDRMFI dataset;
otherwise, none of the extended varaibles will be in
TREND.TRNDRMFI.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 21.066 TYPSZARA was revised to copy the ZARA datasets into the
TYPSZARA PDB library; the ZARA support is unique in that it does
Apr 18, 2003 depend on the macro overrides in IMACZARA, so this was
the safest change to copy ZARAxxxx datasets into the
PDB ddname, and still preserve prior user's tailoring.
Thanks to Bob Miller, Conseco, USA.
Change 21.065 Support for servers with more than 16 CPUs or LPARs.
VMAC7072 -TYPE70 Dataset: Support for 32 engines.
VMXGRMFI The existing sets of 11 CPU-specific variables per CPUID
VMXG70PR CAIx CPUSERx CPUWAITx CPUEDTMx CPUPDTMx IORATEx
May 29, 2003 PCTCPUBYx PCTTIPx VFAFFTMx VMONx MVSWAITx
where suffix 0-9 and A-F are for CPUs 0-15, have 17 more
suffixes, G-L and N-X, for CPUs 16 thru 32 (187 vars).
Note that the suffix letter "M" had to be skipped,
because variable CPUWAITM was already defined.
Labels document which suffix is for which CPU number.
-TYPE70PR Dataset:
No change was needed for more than 16 LPARs; MXG stores
the LPARNUM in four bytes. Note, however, we recommend
you use the MXG-build PDB.ASUM70PR or PDB.ASUMCEC dataset
for your LPAR and CEC analysis, as those datasets know
how to recognize and not count LCPUs that are ICFs or
Linux partitions; if you use TYPE70PR, you'll have to
make sure you understand how to recognize what's what.
-RMFINTRV Dataset:
CPU Serial variables CPUSERG-CPUSERL and CPUSERN-CPUSERX
were added to the ID= operand for PDB.RMFINTRV dataset.
-ASUM70PR,ASUMCEC datasets (built by member ASUM70PR):
The existing sets of 22 LPAR-specific variables per LPAR
LPxNAME LPxDUR LPxUPDTM LPxUEDTM LPxMGTTM LPCTxBY
LPCTxOV PCTLxBY PCTLxOV LPxNRPRC LPxBDA LPxCAP
LPxCHG LPxDED LPxWAIT LPxSHARE LPxLAC LPxMSU
LPxMSUHR LPxMSU70 LPxONT LPxWST
where suffix 0-9 and A-G are for LPARs 0-16, have 16 more
suffixes, H-O and Q-X, for LPARs 17 thru 32 (+352 vars).
Note that the suffix letter "P" had to be skipped,
because variable CPUWAITM was already defined.
Labels document which suffix is for which LPAR number.
This was "Feature 0" or "z/OS 1.4 z990 Compatibility".
Change 21.064 Support for IMS Version 8.1:
ASMIMSL6 -BMC's IMF, Candle's ITRF, Landmark's TIMS.
VMACIMS -MXG's "Supported" TYPEIMS7 to create IMS0708 dataset
Apr 17, 2003 -MXG's ASMIMSL6/JCLIMSL6 to create IMSTRAN dataset.
May 21, 2003
-BMC's IMF, Candle's ITRF, and Landmark's TIMS products
write their own records that MXG reads, and none have
changed in their output records, so MXG 20.20+ supports
their products under all versions of IMS, including 8.1.
-MXG's "Supported" TYPEIMS7 program to create the IMS0708
dataset from 07 and 08 log records (has IMS resources by
transaction name, but no response times) does work with
IMS 8.1, but there are "INVALID DEQDATE" messages and hex
dumps printed on the job log, because IBM incompatibly
changed their 036x log record. VMACIMS has been updated
to support the non-fast-path IMS log records, and when
fast path 8.1 records are available along with DSECTS,
the VMACIMS code for them will be examined for changes.
The _IMSVERS macro default value in IMACIMS7 and
IMACIMS are left at 7.1, since some sites may be
exploiting that existing default; change to 8.1 to
process IMS Version 8.1 records.
-MXG's "pseudo-supported" ASMIMSL6 program and JCLIMSL6
examples work just fine with IMS Version 8.1 records, as
they do with IMS Version 7.1 records, but you must first
re-assemble the ASMIMSL6 assembly program using the IMS
Version 8.1 macro library to create the V 8.1 program,
and you must run separate JCLIMSLx jobs to process the
V7.1 and V8.1 data separately; you cannot concatenate
the IMS logs from two versions and read with JCLIMSLx.
MXG 20.03 contained the last change to this support.
-Log record 31x with PSTNUMBR=0 are output in IMS31O in
VMACIMS logic, and a FLAG2 test added for log record 36x.
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 21.063 NTSMF 2.4.5 new 0.10 record INPUT STATEMENT EXCEEDED due
VMACNTSM to NRTRIPLT=1 but no triplets in that record. Error is
Apr 16, 2003 circumvented by inserting a statement
IF OID=0 AND OBJECT NOT IN ('0','1') THEN DELETE;
before the test for the NRTRIPLT input statement.
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 21.062 MXG 20.07 thru 21.01 may have filled SPIN.SPINUOW with
FIXASUOW many observations that should not have been spun. Change
JCLUOWP 20.221 did not expect cases when the DB2ACCT ending time
JCLUOWV stamp was after the CICS end time, which caused TRANNAME
VMXGUOW to be blank, causing that observation to be "spun". And
Apr 15, 2003 because TRANNAME is now blank (and we will most likely
never see another record for that unit of work) that
record will spin up for 7 days (default in SPINUOW), and
that increased the size of SPIN.SPINUOW. This change
now uses a forward sequence of the Start Time to put all
the CICS and DB2 pieces together, and is not dependent on
the end times.
-If you wish to preserve the "spining" records currently
in your SPIN.SPINUOW dataset, member FIXASUOW can be used
to create a revised SPIN.SPINUOW dataset that can then be
used with the revised VMXGUOW to create the corrected
PDB.ASUMUOW. That first execution will "clean out" many
of the spinning transactions that should not have been
spun in the first place. Or, you can just delete your
existing SPIN.SPINUOW and start fresh with the new code.
-VMXGUOW has a new parmeter, TRACEUOW=YES (Default NO) to
trace the UOW chain for diagnostic purposes (printing
lots and lots of messages on the log).
Thanks to Alfred Nardi, CMX Group, USA.
Change 21.061 Dataset T102S196 was never fully decoded, but now is, for
FORMATS V6 and V7. An observation is created for each holder of
VMAC102 this lock that caused a timeout for the "victim". This
Apr 9, 2003 "victim" is identified in QWHCxxxx & QWHSxxxx variables.
Apr 14, 2003 The lock is identified in QW0196RH/RL/FR/KD/KP/K1-K7/WU
/WS/WD/WF/TI and QW0196TC variables; those QWHC, QWHS, &
QW0196xx variables repeat in subsequent observations if
there was more than one holder (QW0196NU counts holders)
segment in an SMF record. The identity of the holder(s)
are in the three sets of variables QW0196Hx, QW1196Hx, &
QW21196Hx for up to 3 holders of the lock. More than 3
holder prints a note.
-MGD044K format was expanded for new values.
Thanks to Ron Alterman, Charles Schwab, USA.
Change 21.060 The row between 16M-2G was added to the Paging Report;
ANALRMFR this row shows values only if your system is running in
Apr 6, 2003 ESAME mode; in ESA mode, the row will show 'N/A'.
The Channel report READ(MB/SEC) and WRITE(MB/SEC) values
in the IBM report are incorrect: IBM code divides the raw
byte values by 1000*1000 to print as MegaBytes, but they
should have used 1024*1024 to convert; the IBM values are
about 5% too high.
Thanks to David Kellerman, ADP, USA.
Change 21.059 -Type 74 Subtype 4 Structure data (TYPE74ST) has several
FORMATS fields thate were negative, because IBM documented them
VMAC74 as floating point, but they contained binary data. The
Apr 9, 2003 variables R744SPST,SPSS,SRST,SRSS,SCST,R744SCSS are now
Apr 22, 2003 correctly input as binary, and R744SLSV as TODSTAMP8.
Apr 24, 2003 -Some (but not all) observations in TYPE74ST had missing
values for R744QSIZ, when there were a large number of
structures. The QSIZ (SMF744QN) segments are written at
the beginning of one physical physical record, followed
by as many SSIZ segments that can fit in that record,
but additional SSIZ segments are in a separate physical
record. Those additional SSIZ elements had missing QSIZ.
By retaining the QSIZ array and storing the number of
elements, the subsequent SSIZ segments are now populated
with their QSIZ values.
-But R744QSIZ will only be non-missing in records from the
one system in a sysplex that "owns" the Coupling Facility
i.e., the "Sysplex Master" system. This is now discussed
in IBM Information APAR II13172, which applies to both
the RMF III data and the RMF 74 subtype 4 QSIZ segments.
-Variable R744QFLG is now decoded by new $MG074QF format,
which includes '00X: NOT SYSPLEX MASTER, NO QSIZ' value
for TYPE74ST observations from non-master systems, and
obs with R744QFLG='00'X will also have R744QSIZ missing.
Thanks to Coen Wessels, Unicible, SWITZERLAND.
Change 21.058 Support for APAR OW54347 adds Command-Response (CMR) time
VMAC74 to RMF records and RMF Device Activity Reports, and sets
VMAC79 the existing Director Port Busy (DBP) and Control Unit
Apr 6, 2003 Busy (CUB) Delay fields to zero in SMF 74 and 79 records.
Apr 29, 2003 The CMR time for a start or resume function of the sub-
channel is the time needed until the device indicates it
has accepted the command; this allows distinction between
real hardware errors versus workload spikes (contention
in the fabric and at the destination port).
-In dataset TYPE74, new variables DLYCMRTM and AVGCMRMS
are created. Variables DLYDIRTM, DLYCHATM, PCTPNDIR,
DLYCUBTM, AVGPNCUB PCTPNCUB will all be zero when this
APAR is installed. And I've assumed that DLYCMRTM should
also be subtracted from DEVPNDTM to calculate DLYOTHTM
(since DLYCUBTM and DLYDIRTM were).
-In dataset TYPE799, new variable R799CMR is created, and
variables R799DPB and R799CUB will be zero with the APAR.
-OW54347 documented that R799CMR was added at offset +92,
but the original text of APAR OW31701 had R799TMS added
at offset +92. IBM now confirms that OW31701's text was
wrong, R799CMR is at +92, and that R799TMS does not exist
in the RMF 79 record.
Thanks to Ermanno Bewrtolotti, Banca Intesa, ITALY.
Change 21.057 Format MG080QU for RACFQUAL, and format MG080TY for
FORMATS RACFTYPE are updated for new values in z/OS 1.2 and 1.4.
Apr 7, 2003
Thanks to Chuck Hopf, MBNA, USA.
Change 21.056 -Enhancements to BUILDPDB/BUILDPD3. Exit member EXPDBSPJ
BUILD005 and old-style macro _EPDBSPJ are created so that local
BUIL3005 variables can be added to the PDB.SPUNJOBS dataset.
EXPDBSPJ -Variable DATETIME (Start of Shift, equal to INTBTIME) is
SPUNJOBS added to PDB.SMFINTRV for consistency.
Apr 4, 2003 -Variables SMF6LPGE and DOCLENFT are added to PDB.PRINT,
and those variables plus PAGECNT are summed into the
PDB.JOBS and the PDB.SPUNJOBS datasets.
Thanks to Scott Barry, SBBWorks, USA.
Change 21.055 Support for FACOM SMF records 116 caused JCLTEST8 to fail
VMACAIM6 when ID=116 MQ Series records were in your test SMF data.
Mar 28, 2003 To avoid conflict, FACOM support was changed to use an
_IDAIMn macro to set SMF TYPE of FACOM records, and the
default value is set to the impossible value of 512. All
FACOM users will have to redefine the appropriate macro
in their IMACKEEP member to create observations in the
FACOM datasets from the FACOM records:
FACOM Record MXG MACRO NAME
110 _IDAIM0
111 _IDAIM1
112 _IDAIM2
113 _IDAIM3
116 _IDAIM6
117 _IDAIM7
98 _IDAIMR
For example, to process the FACOM 116 record, you would
put this statement
MACRO _IDAIM6 116 %
in your IMACKEEP member.
Thanks to Mike Hoiey, Ameren Services, USA.
Change 21.054 UTILEXCL created incorrect values in KY8DISTM & KY8CPUTM;
UTILEXCL the KY8DISTM=16*KY8DISTM; after the IF CMODIDNT='263'...
Mar 28, 2003 should have been KY8CPUTM=16*KY8CPUTM;
Jun 12, 2003 -Jun 12,2003: Original change only changed the first
instance, but there was a second instance in lines after
CMODIDNT='263' that also needed to be changed.
Thanks to Steve Yucha, Aetna, USA.
Thanks to Tony P. Steward, Royal Mail, ENGLAND.
Change 21.053 Support for BlackBerry Server object.
EXNTBLKB
VMACNTSM
VMXGINIT
Mar 28, 2003
Thanks to Jim Quigley, ConEd, USA.
Change 21.052 -Archaic V6 JCL example was revised to match MXGSASV8 with
MXGSAS DISP=(NEW,DELETE) per Change 20.076.
MXGSASV8 -DISP was changed to NEW,DELETE in MXGSASV9 as it should
MXGSASV9 have been in MXG 20.20
Mar 27, 2003 -The WORK DD symbolic &WORK was not in parenthesis in V8
example.
Thanks to Yao Chun Rickert, Bank One, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
====== Changes thru 21.051 were in MXG 21.01 dated Mar 24, 2003=========
Change 21.051 -Negative values for LOGNATMP & TOTANONS in WEBSERVR occur
VMACNTSM because MXG de-accumulation did not recognize a stop and
Mar 23, 2003 start of the webserver. Adding SEQCHECK=DIF(SEQNR) and
testing SEQCHECK EQ 1 now correctly deaccumulates.
-Support for SYSTEM object with 32 fields; that object has
only 26 unique fields; the last six are repeats.
-The Discovery Print macro _UNTDISC was updated to support
multiple sets of discovery records.
Thanks to Xiaobo Zhang, ISO, USA.
Change 21.050 Support for 2105 Cache Controller data in CMF User SMF
VMACCMF record adds variable CMF27MDL to dataset CMF27C93, which
Mar 21, 2003 will now contain both 2105 and 3390 observations; the
2105 observations contain CMF27MDL='20', while 3990s have
CMF27MDL='96'.
Thanks to Kevin Batty, EMC Engineering, USA.
Change 21.049 MXG Execution under unix at SAS with early ports of V9.1
AUTOEXEC suggested revisions for MXG's IEBUPDTE program, and found
IEBUPDTE a workaround for a unix SASAUTOS error that is now fixed:
Mar 21, 2003 -MXG's IEBUPDTE program (IEBUDPTE for ASCII) needed these
Apr 10, 2003 revisions to work under unix:
- LENGTH MEMBER $200; was added, as that becomes the full
member plus path name and 50 was too short as default.
- Only the PDS_MEMBER is lower cased; previously, the
full path and member were lowcased, but unix path names
can be mixed case.
- The suffix "sas" in the member is now lower case, so
that the files do not have to be re-cased.
-The OPTIONS SASAUTOS=(SOURCLIB SASAUTOS) statement in the
MXG autoexec.sas file did not correctly work under unix:
SAS Note SN-000444 - SASAUTOS fileref is not
automatically generated on unix platforms.
The SASAUTOS is required, because MXG uses the associated
MAUTOSOURCE options so that %MACROs references (%ANALDB2R
%VMXGSUM, etc) are automatically resolved. A workaround
OPTIONS SASAUTOS=(SOURCLIB,
%scan(%sysfunc(getoption(sasautos)),1,%str(())));
was added in MXG's AUTOEXEC member in MXG 21.01, which
works on both unix and Wintel SAS platforms, but in April
SAS unix developers fixed the problem, so that syntax is
not required, and was removed in MXG 21.02.
Thanks to Jan Squillace, SAS Institute, USA.
Change 21.048 INFO: CHARACTER VARIABLES DEFAULTED TO LENGTH OF 200 are
TYPEVLFC printed if OPTIONS MSGLEVEL='I' is in effect; this has
VMAC6 been documented since V6, and occurs when a character
VMAC6156 variable is defined by a function, and the variable is
VMACCTLG not in a LENGTH/ATTRIB statement (unless the function is
VMACEAGL SUBSTR - then, the length of the first argument is used).
VMACTNG The longer length has no MXG impact, but the seven cases
Mar 21, 2003 where the message was produced are now protected with the
variables now in a LENGTH statement, just to eliminate
that possibly confusing message:
Member Variable
VMAC6 - PR
VMAC6156 - SYSPAR61 (was SYSPARM, but renamed).
VMACCTLG - SYSPARCL (was SYSPARM, but renamed).
TYPEVLFC - HITPCT
VMACEAGL - IDS, MSGIDC
VMACTNG - TEXT
Thanks to Stephen Bell, Sparkassen Informatik, GERMANY.
Change 21.047 Format $MGCICCL (applied to variable A17DTTYP in dataset
VMAC119 CICFCR) adds values for K:CFDT CONTENTION MODEL and
Mar 20, 2003 L:CFDT LOCKING MODEL'.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 21.046 Support for SMF 119 APAR PQ71376, which changes TICONNID
VMAC119 and TTCONNID from $EBCDIC8 to $CHAR4 with $HEX8 format.
Mar 19, 2003 Originally the CONNID fields had jobname, which was not
unique; now they contain the unique hex Connection ID.
Variable TISUBTSK was removed; it never really existed.
Change 21.045 The (LABEL= SORTEDBY= _BYLIST) fails under Version 6, and
WEEKBLDT works fine under Version 8, but the LABEL= was not fully
Mar 18, 2003 implemented, so it can be removed if you're under V6. I
intended to have (LABEL= _LABEL SORTEDBY=_BYLIST) and
set MACRO _LABEL 'this is the dataset label' for each of
the weekly and monthly datasets, but didn't do that yet.
Thanks to Jesse Gonzalez, CSC - NASA, USA.
Change 21.044 Using R70MAX to add maximum to the TRNDRMFI dataset did
VMXGRMFI not work, because the &R70MAX statement was left out of
Mar 18, 2003 the Trending part of VMXGRMFI, and because the doc was
not clear: to use the &R7xMAX= macro to "add" variables,
you must list all existing variables in the default list,
and then add you new variables in your invocation.
Thanks to Rick Mansfeldt, IBM Global Services, USA.
Change 21.043 Variables JHSUBT and JHEXCP are calculated, and JHRFLAG1
VMACESPH and JHRFLAG2 are decoded into individual variables.
Mar 18, 2003
Thanks to Jesse Gonzalez, The Gap, USA.
Change 21.042 Variables QPPCTNOW and QPPCTLOW, the percent buffers are
VMAC115 full now, and full lowest, are created in MQMBUFFER.
Mar 18, 2003
Change 21.041 Both members now tolerate the complete absence of input
ASUMCICS datasets while still creating a 0 obs output dataset with
ASUMCICX all variables labelled and formatted. Additionally, some
Mar 14, 2003 variables that were only output in ASUMCICX are now also
created by ASUMCICS.
Thanks to Diane Eppestine, SBC, USA.
Change 21.040 New graph plots the Peak to Average Utilization ratio at
GRAFTRND the SYSTEM SHIFT level; the peak value of the shift is
Mar 14, 2003 compared to the average for that shift and plotted on a
range of 1 to 2 by .1. If the ratio exceeds 2, it is set
to 2.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 21.039 Cosmetic. LABEL was missing for NDMCPUTM.
VMACNDM
Mar 12, 2003
Thanks to Khoan Dang, MBNA, USA.
Change 21.038 Protection for WORD7 to be the last word eliminated NOTE:
VMACWWW INVALID THIRD ARGUMENT TO FUNCTION SUBSTR when processing
Mar 11, 2003 a WebSphere HTTP log file.
Thanks to Craig Collins, State of Wisconsin, USA.
Change 21.037 Documentation. Thou shalt not use a RENAME= statement in
VMXGSUM your OUTCODE= argument to %VMXGSUM that renames variables
Mar 11, 2003 that are in the SORTEDBY= list; thy %VMXGSUM will fail
with ERROR: VARIABLE xxxxx NOT SORTED and
and ERROR: INVALID VALUE FOR THE SORTEDBY OPTION.
Thanks to Khoan Dang, MBNA, USA.
Change 21.036 -RSDA AUDIT error message was printed even though AUDHEXZR
VMACRSDA was zero; the test should have been 0000X (numeric) but
Mar 11, 2003 was incorrectly coded as '0000'X (character, so the test
failed when AUDHEXZR was zero).
-But then View Records (AUDACT=04) caused INPUT STATEMENT
EXCEEDED message, because those records do not have the
Folder Name segment that MXG expected; a test was added
to see that the Folder Name segment is present.
Thanks to Christa Neven, KBC BankVerzekeringsHolding, BELGIUM
Change 21.035 Using ASUMUOWT to combine TMON and DB2 data failed with
VMXGUOW BY VARIABLES ARE NOT SORTED ON WORK.TEMPCICS because the
Mar 10, 2003 BY list in MACRO _SUOWTMO was not updated in VMXGUOW.
Thanks to Tom Heaton, Texas Legislative Council, USA.
Change 21.034 Protection for missing STARTDTE was added; records with
VMACXCOM only ENDDTE populated caused INVALID DATA FOR STARTDTE
Mar 10, 2003 message, but no actual impact on the output XCOMDATA.
Thanks to Mark Williams, Marks & Spencer, ENGLAND.
Change 21.033 Additional AS/400 5.2 files LRECL have been validated and
VMACQACS are listed in the comments in VMACQACS. Minor cosmetic
Mar 7, 2003 changes were made to suppress INVALID DATA messages for
Mar 17, 2003 reserved packed fields. The data files had been sent to
MVS with incorrect LRECLs, and when those MVS files were
ftp'd to me, I discovered Padded Bytes added to the last
record of each file; the bytes are all hex zeros and they
caused invalid data messages when PD fields were input.
So MXG tests the INTNUM packed decimal field and prints a
message "PAD RECORD FOUND AND DELETED _N_= nnnn" on the
log. As long as the _N_= value is the same as the xx in
the SAS NOTE: xx RECORDS READ, then the delete record was
comprised of these pad bytes and there was no error.
Thanks to Brian Keller, ConAgra Foods, USA.
Change 21.031 -Tests for FTPSTART xx FTPEND and FTPEND xx SMFTM were
ANALTCP incorrect as GE, and are changed to the correct GT, and
Mar 7, 2003 two output columns were shifted one position.
Mar 14, 2003 -A sort step was added, required only when PDB=SMF.
Thanks to Matt Martin, USPS, USA
Thanks to Craig Collins, State of Wisconsin, USA.
Change 21.030 Protection added for subtype 8 record with NRSEGS=295
VMACICE (295*128 = 37760, which cannot fit in 32760 LRECL) while
Mar 7, 2003 reporting site contacts STK for a fix.
Change 21.029 MXG Newsletter FORTY cited APAR PQ56039, which supposedly
VMAC116 corrected invalid values for many of the MQMQUEUE fields,
Mar 7, 2003 in particular the WQMAXLAT and WQTOTLAT fields. However,
data records with very large values (168 hours plus) at
one site, and "large values" at another site are still
under investigation, which uncovered these unrelated
changes: The label for WQTOTUSE was corrected to be
WQTOTUSE='TOTAL*API CALLS*USING THIS*QUEUE', and the test
for the three PMS fields tests is LENWQ GE 588 instead of
the old test for 592.
Change 21.028 Early V8-V9 comparisons were flawed because CONFIGV8 did
CONFIGV9 not collect statistics, but CONFIGV9 enabled these:
Mar 7, 2003 DLEXCPCOUNT FULLSTATS FULLSTIMER STIMER MEMRPT
This change disables those statistics options in CONFIGV9
so that you should NOT see any increase in CPU time when
you install SAS V9 and use the same options as SAS V8.
Change 21.027 Mostly documentation. When you are using a SAS View to
JCLUOWV pass data from a data step to PROC SORT, SAS cannot give
Mar 6, 2003 the SORT the estimated record count (because SAS does not
know the observation count of a view), and thus the SORT
cannot be optimized in its choice of SORTKWs and memory.
In these cases, for SYNCSORT, you can use the $ORTPARM DD
to pass the size estimates to the sort program:
//$ORTPARM DD *
VSCORE=756K,VSCORET=512M,FILSZ=E40000000
which tells SYNCSORT to use 756K below the line (fixed)
and 512M total (fixed) storage, and the estimated record
count to be sorted is 40,000,000 records.
Previously, SORTSIZE=40000000 was used, but SYNCSORT
now ignores SORTSIZE= and instead uses the syntax of
FILSZ=Ennnnnnnn. The E is required; without it, SORT
fails if the record count is not exactly nnnnnnnn.
Similar parameters can be passed to DFSORT; if you
tell me that syntax, I'll update this note.
But note that the //$ORTPARM parameters apply to EVERY
sort in the job-step, so use with care, especially
because the memory will be fixed.
The change replaced SORTSIZE= with FILSZ=E.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Steve Dunn, Mainframe Performance Products Pty., AUSTRALIA
Change 21.026 Support for Control-T Release 6.0.0 (INCOMPATIBLE). New
VMACCTLT data fields were inserted, and the LRECL was increased to
Mar 6, 2003 600 bytes in their new version. Instead of feet, you get
Mar 27, 2003 bytes compressed/uncompressed for volume and datasets.
-Mar 26: Support for Control-T Release 6.1.0 (INCOMPAT,
because the LRECL was increased to 660 bytes, and MXG had
only protected for 600 bytes. Three fields were added to
their volume record by 6.1.
Thanks to Craig Collins, State of Wisconsin, USA.
Thanks to Stefano Baldi, Phoenix Spa, ITALY.
Change 21.025 Documentation only. The removal of Cross Memory Calls in
ASMTAPES ML-27 MXGTMNT causes these variables to be missing in the
Mar 6, 2003 TYPETMNT and ASUMTAPE datasets:
DDNAME INITTIME JOBCLASS PGMRNAME PROCSTEP PROGRAM
RACFGRUP RACFTERM RACFUSER RDRTM READTIME STEPNAME
and these variables to be missing in TYPETALO/ASUMTALO:
ALOCSTRT DDNAME STEPNR
(ALOCSTRT is commented in the ASM code and it appears
it has never been populated in the SMF record).
Stay tuned for a new algorithm that will merge TYPETALO,
TYPETMNT, TYPE1415, and TYPE30TD to not only populate the
missing fields, but enhance tape mount analysis with new
data as well. Maybe by the end of third quarter.
Note that the removal of Cross Memory calls was to solve
problems caused by VTS mounts; if your site does NOT
(yet!) have any VTS devices (or VTS-simulating-software)
so that all of your tape mounts are real mounts that take
real time, then you can still have the above variables
populated by MXGTMNT program, by re-assembling ASMTAPES
with the XMEM=YES parameter enables.
Change 21.024 -Support for TNG "Enterprise Cubes", which contain data
EXTNT007 from multiple servers, required structural revision of
EXTNT034 the code, which had expected a CAPMPCM Header record
EXTNT035 betweeen each system. This redesign has been tested
FORMATS with TNGVERS 6 data from multiple systems.
IMACTNG -New NT object NETWORK SEGMENT creates new NT034 dataset.
VMACTNG -New variables were added to existing SYSTEM object in
VMXGINIT dataset NT018.
Mar 7, 2003 -Support for NT PROCESS Object creates new NT035 dataset
Mar 19, 2003 and a major design change, because each process instance
Mar 27, 2003 does not record all process metris: out of 327 process
Apr 1, 2003 name records, only 175 had PROCESSOR TIME metric records,
but 324 had ID Process, and 326 had Page File records.
MXG presumed TNG recorded all metrics for each instance,
but now a new context-based array (NT035INM) maps each
process name to its metrics's location (INSTLOC), instead
of assuming a sequential INSTNR for each process metric.
-The arrays to support process data can require large
virtual storage if there are very many process names.
With NT035I=2000, NT007I=999, and MAXROWS=325, TYPETNG
required about 180MB of virtual storage! The MXG defaults
of NT035I=500, NT007I=100, MAXROWS=288 needs REGION=64M.
-TYPETNG will ABEND with USER 1111 if it finds more unique
process names than your chosen NT035I=value permits.
-EXTNT035 now only outputs observations that have non-zero
value of % PROCESSOR TIME; most processes are idle and do
not record any time. There were 2,448,576 observations
created when all process records were output, but only
31,320 observations had and CPU. That logic was located
in EXTNT035 in case you ever think you want to output all
observations.
-The process records for the Idle and _Total process names
both have % PROCESSOR TIME of 100, so they should be
removed in your analysis of process utilizations.
-EXTNT007 now only outputs observations that have non-zero
value of Total Bytes, i.e., that had activity.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 21.023 -Messages SHORT XAMSYS SEG FOUND, DELETED.... were caused
VMACXAM by incorrect subtraction in line 2275, which should be
Mar 5, 2003 SKIP=SKIP-20; instead of SKIP=SKIP-24; The error occurs
Mar 12, 2003 only in records with MTRSYS length of 164 or greater.
Mar 16, 2003 -Support for SYTCPC (Channel Activity) creates new dataset
Apr 22, 2003 XAMSYCPC with Channel Busy array HFCHB0-HFCHB255 (where
the CHPID is the array suffix, and the array is populated
with NBUSY entries), and Channel Simultaneous Bussy Array
HFCHSI0-HFCHSI50 (populated with NBUSYSIM).
-Support for TCP data files creates many new datasets from
Linux, NT, Sun systems, as well as from VM Monitor:
UCD - From UCD-SNMP or NET-SNMP
HST - From ANY SNMP DAEMON supporting HOST MIB
TCP - From either VM MONITOR RECORD FOR VM, or SNMP
FAL - From VM MONITOR RECORDS, exclusive to VM
OTHERS - SUBNET, TCPCON, TCPAPP come from either FAL
or a "NETSTAT" interface.
The datasets have been validated, but this is preliminary
support, and variable names may change slightly as the
data is better understood.
-Additional XAMDEV variables, including RDEVSER, VOLSER,
are now decoded. Apr 22, 2003.
Thanks to Rebecca Cates, Merrill Lynch, USA.
Thanks to Tom White, SPRINT, USA.
Change 21.022 All daily PDB datasets that are created in the JCLPDB8
WEEKBLD example JCL are now copied into the WEEKLY PDB in the
WEEKBLDT example WEEKBLD/WEEKBLDT members. Most datasets were
WEEKBL3 copied into the weekly PDB, but many new datasets were
WEEKBL3T created by BUILDPDB/BUILDPD3 that were not also copied
Mar 5, 2003 into the weekly that now are.
Yes, this change could cause a perfectly good weekly MXG
job to ABEND with an out of space condition, but that, I
decided, was less painful than discovering later that the
data you thought was in the weekly wasn't!
Thanks to Ronald Lundy, AHOLD, USA.
Change 21.021 The Active Server Pages object's INPUT statement has been
VMACNTSM incorrect, at least since NTSMF 2.2.2. ASMEMALO no longer
Mar 5, 2003 exists, and a DUMMYFLD was inserted after ASTMCAHT in the
logic for NRDATA=34 for the ACTVSRVR dataset.
Thanks to Chris Morgan, UFI, ENGLAND.
Change 21.020 Relocated the VMXGOPTR call that resets OBS= value to
VMXGSUM earlier; if KEEPALL=NO and the first data step bypassed,
Mar 4, 2003 and you had changed OBS= to a small value, the original
location was too late. Seen only in unrelated test runs,
has been that way for a long time and never reported, but
is now corrected.
Change 21.019 Oracle variable ASID was not input and ELAPSTM was not
VMACORAC created for Release 8. Several variables no longer are
Mar 1, 2003 created in the Oracle SMF record with that release, and
Mar 13, 2003 will always have missing values:
CPUCICTM CPUSRBTM CPUTCBTM CPUTIMER DDLCOMIT DDLROLLS
ENDSRB ENDTCB ORACMSB PCCOUNT STRTSRB STRTTCB
-Cosmetic. Text in labels had misspelled OSDI as ODSI and
OSID are now all OSDI.
Thanks to Forrest Nielson, State of Utah, USA.
Thanks to Marvin Wapnitsky, TIAA-CREF, USA.
Change 21.018 Support for Domino Server Release 6.0.0 added five new
IMAC108 HTTP-related variables to the Subtype 1 record that are
VMAC108 now output in dataset TYPE1081:
Mar 1, 2003 DOMCACOM='DOMINO*CACHE*COMMAND*COUNT'
DOMCADES='DOMINO*CACHE*DESIGN*COUNT'
DOMCAREQ='DOMINO*CACHE*REQUESTS*TOTAL'
DOMCASES='DOMINO*CACHE*SESSION*COUNT'
DOMCAUSR='DOMINO*CACHE*USER*COUNT'
Their existence was found in APAR PQ70810, which added
the fields to IBM's TIVOLI product; that is what alerted
me that there was a new Domino version to support.
Change 21.017 For devices with IORATE=0, variable DEVIOQTM was carried
VMAC74 from the preceding device that had non-zero IORATE. The
Feb 28, 2003 missing DEVIOQTM=.; statement was inserted where it
should have been, after the AVGIOQMS=.; statement.
Thanks to Barry McQueen, Department of Defence, AUSTRALIA.
Change 21.016 Several "Wdddddd" macro variables were incorrectly %LET
VMXGINIT to &DEFAULT instead of &MXGWORK: all for VMACLDMS and for
Feb 27, 2003 VMACMIM were wrong, as were two for VMACTAND. This only
surfaced as an actual error if you used the USER= option.
Thanks to Ken Kelso, National Australia Group, SCOTLAND.
Change 21.015 Using %ANALDB2R(PDB=SMF); to get the default set of DB2
ANALDB2R reports failed with 76-322 and other strange errors, due
READDB2 to changes made to READDB2 by Change 20.233. The READDB2
Feb 27, 2003 calling logic in ANALDB2R was corrected. However, using
%ANALDB2R(PDB=SMF,IFCIDS=ACCOUNT);
will circumvent the error.
-READDB2 now detects that it was invoked without arguments
and gracefully reports that error.
-IFCIDS=ALL is now recognized.
Thanks to D. J. Chen, State of Florida, USA.
Change 21.014 More than one type 6 ESS '0031'x USERDATA segment was not
IMAC6ESS expected, causing INPUT STATEMENT EXCEEDED if comments in
VMAC6 IMAC6ESS were opened. Multiple USERDATA now supported.
Feb 23, 2003
Thanks to Ricke Godehard, Itellium, GERMANY
Change 21.013 -INVALID DATA messages reading QAPMDISK file because of
VMACQACS ELSE INPUT INPUT in lines 3984 and 3985. Remove one.
Feb 22, 2003 -Variable DSASPN 'ASP RESOURCE NAME' was not kept and was
Mar 5, 2003 not labeled, but now it is.
Thanks to Paul E. Bennett, JPMorganChase, ENGLAND.
Change 21.012 The MNTH72GO example still had PERFGRP and PERFRPGN where
MNTH72GO it should have had SRVCLASS and RPRTCLAS
Feb 22, 2003
Thanks to Mike Kynch, International Paper, USA.
Taught the first tuition-free three-day class in Dallas to 64 students.
Change 21.011 The format MGSASPR had PARETO misspelled, and had several
FORMATS procedure names that were longer than 8 characters that
Feb 18, 2003 are now truncated to 8 bytes so they will match the name
in the TYPESASU dataset (from the SAS user SMF record).
And SETINIT (BASE) was added to the list of procs.
Thanks to Tom White, SPRINT, USA.
Change 21.010 SMF 42 offsets for subtype 20 and 21 are incorrect in the
VMAC42 z/OS SMF manual, but (without test records), I believed
Feb 17, 2003 the manual. Offsets for SMF42KN1 thru SMF42KN3 and for
SMF42LN1 thru SMF42LN6 should have started at decimal 36,
but the manual showed them starting at dec 52 and dec 60.
MXG printed error messages, but the job did not fail, but
it did not output those subtypes, either!
But the subtype 21 records that are only 176 bytes long
have invalid offset SMF42LN4 (177) and number of SMF42LN6
(1) for the Alias Names Deleted in Sympathy segments,
causing MXG to print an error message. It's not clear if
there were Alias names that were not written, or whether
the offset/number should have indicated there were no
Alias names in the record. This will be purusued with IBM
but this Change does correctly populate TYPE4221 dataset.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 21.009 Symbolic parameter WORKVOL= is added to the MXGSASV8 JCL
MXGSASV8 procedure, defaulting to 5 volumes, and the WORK= parm
Feb 12, 2003 is (200,200) in CYL. SAS only allocates what it needs,
but this will reduce the probability of B37 ABENDS for
new users.
Change 21.008 Documentation. TYPE70PR PR/SM data for IFL Linux LPARs
VMAC7072 are not identified as such: they have SMF70CIN='ICF', so
Feb 12, 2003 you can't tell an IFL from an ICF partition, so you must
use a table lookup of LPARNAME to select the Linux LPARs
from PDB.TYPE70PR. And only LCPUPDTM is non-zero; the
LCPUEDTM is always zero.
Thanks to Tony P. Steward, Royal Mail, ENGLAND.
Change 21.007 PCHANBY is missing for SMF73ACR='CBP/CBS/CFP/CFS/ICP'
VMAC73 Channels. Originally corrected by Change 20.096, that
Feb 12, 2003 was overridden in Change 20.172, which reset it missing.
Feb 17, 2003 The initialization to prevent carry forward was moved to
above the PCHANBY calculations.
Thanks to John Gebert, Office Depot, USA.
Change 21.006 Negative values in DB2STATB variables occurred when a DB2
VMACDB2 subsystem was stopped and started, and the first record
Feb 11, 2003 after the start had QWHSISEQ=4, but MXG expected first
record to have QWHSISEQ=1. MXG's test to recognize start
was revised to also test SEQCHECK GT 0 or ISEQ=1. This
may be an IBM error, but the MXG circumvention should be
sufficient.
Thanks to Tony P. Steward, Royal Mail, ENGLAND.
Change 21.005 Cosmetic. The INVALID DEVICE messages now include the
VMACEXC2 PROGRAM name, making it easier to identify if they are
Feb 11, 2003 coming from the same program.
Thanks to Paolo Uguccioni, UNICREDIT, ITALY.
Change 21.004 ML-28 corrects an 0C4 in ML-27 that occurred only with
ASMTAPES the //EXCLUDE DD, and only if the tape drive with the
Feb 11, 2003 highest DEVNR was excluded. Trivial to fix once seen,
Feb 17, 2003 hard to include in all combinations of our testing.
Thanks to Anthony A. Ziegler, UMB, USA.
Change 21.003 Variable R791FMCT should have been multiplied by 4096 to
VMAC79 convert from frame count to bytes, which will be printed
Feb 11, 2003 as nnnnKB/MB/GB; the variable is FORMATed MGBYTES.
Thanks to Tom Draeger, Aurora Health Care, USA.
Change 21.002 Major enhancements to MXG processing of RMF III VSAM data
ASMRMFV includes revisions to the ASMRMFV assembly program, the
CLRMFV new CLRMFV CLIST member that will read all of your RMF
DOCLRMFV III VSAM files on all your system in one job (since you
Feb 13, 2003 cannot concatenate VSAM, and member DOCLRMFV to document
Feb 18, 2003 the CLRMFV CLIST, and provides JCL examples of how to
use CLRMFV and ASMRMFV (which will create the RMFBSAM
file that is then read with MXG's TYPERMFV to create all
of the MXG RMF III datasets). Enhancements in ASMRMFV:
-Minimum and maximum LRECL output is now reported for each
RMF III Table/Header.
-Total Displays restructured to combine selection, input,
output records written/skipped and output LRECL min/max.
-CC=4 set when input records are skipped due to exceeding
32756 LRECL or decompression errors; previous CC was 0.
-Messages show FROM=/TO= keyword selection Time Stamps in
Date/Time Format for each RMF III data set processed.
-Messages show FIRST/LAST Sample Set Time Stamps
-Messages assigned RMFVNNN with I=INFO,W=WARN,E=ERROR, and
S=SEVERE ERROR suffixes.
-Major performance improvement with Selection: entire RMF
VSAM dataset is skipped if Data Set Header FIRST/LAST
shows all sample sets are outside FROM=/TO= keywork.
-Minor performance improvement: entire Sample Set bypassed
if FIRST/LAST header is outside FROM/TO keyword range.
-Table access validated by comparing eyecatcher.
-If a specific table exceeds maximum LRECL, next table is
processed; previously, remainder of this sample set was
abandoned.
-Internal ASM improvements; counters that used fullword
Register to Storage arithmetic instructions replaced with
Load Address or Branch on Count Register instructions.
-Improved documentation in the program prologue.
-Tables that are not processed by TYPERMFV (because no one
has needed them)are skipped by ASMRMFV and documented.
-Performance: processing 7 LPARs with 44 RMF III datsets
(a total of 308) in a single job reduced Elapsed Time,
CPU Time, and EXCP count by 70%
-CLRMFV is run in batch and repetitively calls ASMRMFV
for each RMF Monitor III dataset it finds, making ASMRMFV
truly useful for bulk processing; without this CLIST a
separate job step must be used for ASMRMFV, since VSAM
does not support concatenation.
The code, CLIST, and documentation were all written by
and contributed to MXG by Jerry.
-Feb 18: Use PGM=IKJEFT01 instead of PGM=IKJEFT1B, doc'd
in member DOCLRMFV. ASMRMFV now recognizes FROM= and/or
TO= keywords for filtering.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 21.001 Archaic report example member ANALCICS caused V8 to 0C4
ANALCICS ABEND in module VXBSM doing the autocall for %VMXGFOR,
Feb 8, 2003 now removed by MXG Change 20.327, but the cause was the
old OPTIONS SASAUTOS=(SOURCLIB SASAUTOS) statement in the
ANALCICS member, which as been unneeded for years, and
now removed, as MXG sets SASAUTOS at MXG Initialization.
But SAS had documented this problem before: "It is not
advisable to change SASAUTOS during a SAS session. If
you change the SASAUTOS= specification in an ongoing SAS
session, the SAS System will store the new specification
only until you invoke an uncompiled autocall macro, and
then SAS will close all opened libraries, and open all
the newly specified libraries that it can open."
LASTCHANGE: Version 21.
=========================member=CHANGE20================================
/* COPYRIGHT (C) 1984-2003 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 20.20 is dated Feb 7, 2003, thru Change 20.341.
MXG Version 20.12 was dated Feb 3, 2003, thru Change 20.335.
MXG Version 20.11 was dated Jan 30, 2003, thru Change 20.330.
MXG Version 20.10 was dated Jan 3, 2003, thru Change 20.307.
MXG Version 20.09 was dated Dec 20, 2002, thru Change 20.299.
MXG Version 20.08 was dated Dec 4, 2002, thru Change 20.280.
MXG Version 20.07 was dated Nov 4, 2002, thru Change 20.244.
MXG Version 20.06 was dated Oct 7, 2002, thru Change 20.215.
MXG Version 20.05 was dated Sep 6, 2002, thru Change 20.186.
First MXG Version 20.05 was dated Sep 1, 2002, thru Change 20.177.
MXG Newsletter FORTY-ONE was dated Sep 1, 2002.
MXG Version 20.04 was dated Aug 12, 2002, thru Change 20.157.
MXG Version 20.03 was dated Jun 19, 2002, thru Change 20.111.
MXG Version 20.02 was dated May 8, 2002, thru Change 20.082.
Final MXG Version 20.01 was dated Apr 11, 2002, thru Change 20.061.
Second MXG Version 20.01 was dated Apr 9, 2002, thru Change 20.058.
First MXG Version 20.01 was dated Apr 1, 2002, thru Change 20.046.
Annual MXG Version 19.19 was dated Feb 14, 2002, thru Change 19.300.
MXG Newsletter FORTY was dated Feb 14, 2002.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 20.20 is now available upon request.
II. Incompatibilities and Installation of MXG 20.20.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 20.20 is now available.
Major enhancements added in MXG 20.20
ASMTAPES 20.320 ML-27 now robust, low CPU, sees VTS, no XMEM, etc.
ML-27 eliminates the cross memory call and 0E0s,
changes interval to 0.5 seconds, which captures
all VTS allocations and most VTS mounts
TYPETMO2 20.335 Support for ASG/TMON CICS V2.2 INCOMPATIBLE.
TYPEXAM 20.315 Support for Velocity Software's ESAMON VM Monitor 3.2
and support for TCP and Linux data almost made it.
TYPE28 20.316 Support for Tivoli Netview NPM 2.7 SMF 28 records.
TYPE102 20.336 Support for IFCID=247 in T102S2347 dataset.
TYPEEDGR 20.331 Support for DFSMSrmm Extended Extract 'X' records.
TYPEESPH 20.318 Support for Cybermation's ESP Product JOBHIST file.
TYPESYNC 20.309 Support for SYNCSORT for z/OS 1.1 SMF record.
IMAC6ESS 20.332 Support for more ESS variables (on OUTPUT statement)
TYPERMFV 20.334 Numerous enhancements/corrections to RMF III support.
BUILDPDB 20.330 New CSTORE30,ESTORE30 variables in STEPS,SMFINTRV.
TYPE30 20.330 New CSTORE30,ESTORE30 variables in TYPE30_4,_5,_V.
TYPE30 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
ANAL116 20.313 Example graphs of MQ Series SMF 116 data.
VGETJESN 20.326 Type 30s with JCTJOBID='INTnnnnn' protected.
UNIXSAR 20.314 Enhancements to process unix sar command output.
VMXGFOR 20.327 All %VMXGFOR were removed, to avoid a SAS zap.
BUILDPDB 20.319 OMVS task filled //SPIN, had TYPETASK='JOB' in error.
BUILDPDB 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
JCLUOWP 20.312 JCL example for ASUMUOW using Views/Pipes corrected.
UTILBLDP 20.329 Enhancement if BUILDPDB=NO is specified.
BLDNTPDB 20.323 Some combinations of arguments didn't work right.
TYPEOPC 20.321 IBM's OPC Log causes INVALID ARGUMENT TO FUNCTION....
TYPE79 20.325 TYPE792 was incorrectly deaccumulated.
TYPESRMH 20.317 Security Resource Manager for MVS V2.3 correction.
Many 20.324 Semi-colons added after each _Edddddd exit statement.
Versions 20.11 and 20.12 were QA tests, sent to only a few sites.
Major enhancements added in MXG 20.10
TYPE7072 20.307 Errors in TYPE72GO (MXG 20.08-20.09 only) corrected.
TYPENSPY 20.305 Support for NetSpy Version 6 subtypes G,H (COMPAT).
TYPEIDMS 20.304 Support for IDMS V1500 new subtypes 13, 14, 15.
TYPECIMS 20.306 No observations in CIMSDBDS after Change 20.138.
Major enhancements added in MXG 20.09
VMAC115 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
VMAC116 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
FORMATS 20.291 Support for APAR OW57121 new SMF 99 trace codes.
TYPE94 20.283 Support for undoc SMF 94 Subtype 2, heuristically.
REXXWLM 20.289 Support to read Workload Manager's WLM Defs PDS.
A very slick REXX exec and SAS step to output the WLM
definitions into a SAS dataset.
TYPEQACS 20.295 AS/400 CPU times merged in optional QACSCPU dataset.
ANAL94 20.294 VTS activity reports selection SUBREP= parm added.
TYPE110 20.293 UNKNOWN STID=115 messages should not exist.
FORMATS 20.292 Mapping of SAS Procedure Name to Product updated.
TYPENTSM 20.286 MicroSoft added instance names for SMF objects.
RMFINTRV 20.297 Workloads can use SYSTEM/SYSPLEX as criteria.
Major enhancements added in MXG 20.08
TYPEQACS 20.260 Support for AS/400 5.2 Collection Services (INCOMPAT)
UTILEXCL 20.256 Major UTILEXCL enhancement, MCTSSDCN/DRL DO grouping,
so you don't have to rerun UTILEXCL for new APPLIDs.
TYPENTSM 20.276 Support for NTSMF new objects from MS Exchange 2000
SP3, XP Professional, Citrix, DataCore, MSMQ, and
changes to PROCESSOR and MQSERIES objects.
TYPE94 20.265 SMF 94 FC4001 undoc fields caused wrong values.
TYPEMVCI 20.263 Support for BMC MVCICS 5.6, fix for 5.5 CMRDETL data.
TYPETMO2 20.253 Support for ASG-Landmark TMON/V2.1 TH01595 (COMPAT)
TYPETAND 20.250 Support for Tandem G07 new data, fix TANDPROC G06.
CONFIGV9 20.252 Support for Version 9 TS M0 Production Release.
AUTOEXEC 20.252 Support for Version 9 TS M0 Production Release.
TYPE79 20.274 Support for APAR OW56739, RMF 79 subtype 3.
TYPE7072 20.274 Support for APAR OW56739, RMF 72 subtype 3.
GRAFWRKX 20.273 Workload Graph examples include MSU used by workload.
ANALRMFR 20.277 RMF Channel Activity Report CHP= selectivity added.
TYPE71 20.259 Medium Impact Frames ESFRMExx are now input in order.
TYPE119 20.267 TSIPxxxx variables wrong in TYPS11905, other fixes.
Major enhancements added in MXG 20.07
Status of ASMTAPES:
ML-26 tests show no improvement; CPU time same as ML-25, even
when scan excluded VTS devices. Update: USE ML-27, in 20.20.
TYPE73 has PCHANBY/PNCHANBY mising with SMF73CMG=0.
Support for CICS APAR PQ63143 changes to 110-2 stats; only STID=24
(for CICAUTO) was INCOMPATIBLY changed.
Support for RMF 74-4 APAR OW55968 (R744SST 4 to 8-byte).
Support for APAR OW54010 Large Virtual Memory (>2GB).
Support for Candle Omegamon for CICS V520 User SMF.
Support for Control-D "SF2" User SMF record.
Support for Control-D "POD" User SMF record.
Circumvention for IDMS Version 1500, no new data yet.
UTILEXCL USERCHAR variable generated wrong INCLUDE post 20.148
TYPEDB2 Negative DB2SRBTM with DB2 V7 forced back to missing.
Trending for TYPE23 (SMF Buffer Usage) was wrong.
Documentation: Don't use TEMP01 with %VMXGSUM.
Example of RACF Filtering with TYPE80A and MACJBCK=.
TYPE80A Support for UID/HOME/PROGRAM OMVS/USS RACF fields.
Major enhancements added in MXG 20.06
Status of ASMTAPES:
ML-25 uses lots more CPU time (30 minutes per day versus 30 secs
with ML-19) and there is no immediate fix. Update: Use ML-27.
Support for APAR OW52396 (no change) SMF 74-7 FICON.
Support for APAR OW56162 new SMF 64 CATALOG UPDATE.
Support for SMF 94 subtype 2 and subtype 1 new stuff.
Support for z/OS 1.4 is in MXG 20.06, but MXG 20.03 or later is all
that is truly REQUIRED for z/OS 1.4. The minor 1.4 enhancements
that are now supported (i.e., decoded) by MXG 20.06 have very
little impact. See Change 20.101 for why 20.03 is the minimum,
and see Change 20.205 for the z/OS 1.4 enhancements.
However, if you're leading edge enough to be install new releases
of your operating system, then you surely should install the most
recent MXG Version (20.06, this week), because of likely changes
to at least one of your other products; the current MXG is always
more aware of other product's changes than was the prior version.
And installing a new MXG Version, now, is very easy, and with no
changes needed to your MXG tailoring, very simple.
Note that IBM has announced that the next major z/OS release is
scheduled for March, 2004 (yes, 18 months), to be followed by a
release in September, 2004, and thereafter major z/OS releases
will be annually, each Fall.
But you can still expect to see a new MXG Version available
practically every month, as we keep up with constant change in
the other 399 products whose data records are supported by MXG;
z/OS itself is but one product.
Support for SMF 120 subtype 7 and 8 WebSphere 4.0.1.
Support for BMC's Mainview for DB2 THRDHIST file.
Support for ASG-Landmark TMON/MVS V3 (INCOMPATIBLE).
Support for CICS Transaction Resource Class new data.
Support for SAMS:VANTAGE 3.2.0 OBJ=POOLS record.
Major enhancements added in MXG 20.05
ASMTAPES: ML-25 corrects CPU loop or 0C4 in ML-24. Now: Use ML-27.
Support for Oracle and Analysis Server NTSMF objects.
Revision/enhancement of MSU calculations in RMFINTRV, ASUM70PR and
ASUMCEC, plus description of important MSU variables and MXG
recommendation to use MSU instead of MIPS. Change 20.168.
Support for EMC's Catalog Solution user SMF record.
Technical Note in NEWSLETTER FORTY-ONE: CICS-DB2 ACCOUNTING change.
Major enhancements added in MXG 20.04:
ASMTAPES: ML-24. Corrects 0E0 logrec, CPU loop. Update: Use ML-27.
Support for APAR PQ61349 to SMF 103 records.
Support for APAR OW54007 to SMF 42 records..
Support for RMF 74 subtype 7 FICON Port data.
Support for type 90 subtype 32 in TYPE90A member
Support for multiple CICS user fields in UTILEXCL.
Support for IMPLEX Version 2.1 has been coded.
Landmark TMON/CICS datetimes wrong zone if GMTOFF GT 0.
Landmark TMON/DB2 datetimes wrong zone if GMTOFF GT 0.
Support for NTSMF 2.4.4, MODULE Object, Disk pct and Averages.
Support for NTSMF File System Collector. DCOLLECT for NT!
New ANALDB2K merges package DB2ACCTP data with DB2ACCT data.
Major enhancements added in MXG 20.03:
Support for JES "Z2 Mode" (INCOMPATIBLE JESNR): YOU MUST HAVE THIS
version before you enable Z2 mode in z/OS 1.2 or later!!!!
ML-23 of MXGTMNT, skips over list of UCB addresses for VTS devices.
Support for subtype 27/28 of STK HCS/VSM records.
Support for many new TNG Platforms (SOL, AIX) etc.
Support for G06/G08 TANDPROC LRECL=442 (INCOMPAT).
Support for NTSMF Citrix process record.
Support for AIX PTX (Performance ToolBox) adds objects/variables.
GRAFWRKX Enhanced "Weighted LPAR Capacity" Graph/Tabular reports.
ANALRMFR "RMF HTTP Server Report" multiple servers, etc.
Domain Error in TYPE78, TYPE79 and TYPE91 were corrected.
PCHANBY missing for TYPE73 Coupling Facility channels.
Doc: Variable UOWTIME may look wrong, but it's okay.
Variable MSU72 created in TYPE72/TYPE72GO.
EXECAPPL, the "execution" APPLID, added to PDB.ASUMUOW.
UTILEXCL Final (?) cleanup covers all reported optional data.
Major enhancements added in MXG 20.02:
Support for z/OS 1.3 (COMPATIBLE, except SMF 42 needs MXG fix).
Biggest enhancement: new TYPE4221 dataset records every delete
of a PDS or PDSE member, and who dun it.
Support for APAR OW52227 (Active Application State) for WLM.
New state counters are used, changing percent calculations.
Support for multiple CICS versions with EXCLUDEs added in UTILEXCL.
Support for unexpected z/VM record with DATABYTE=0, caused STOP.
Support for IBM Product NPM/IP monitor user SMF record.
Support for TMON/CICS TCE 2.1 (COMPLETELY INCOMPATIBLE).
Support for full LRECL and VBS output for RMF III in ASMRMFV.
SAS Inherit option created wrong label in ANAL94.
Major enhancements added in MXG 20.01:
CPU Busy Pct in TYPE70/TYPE70PR/ASUM70PR wrong with WLM IRD.
There is no correction yet; see text of Change 20.046.
Additional corrections to UTILEXCL.
Support for z800 2066 CPU factors for OS/390 R2.8-R2.10.
Support for Top Secret V5.2, INCOMPATIBLE.
Support for Mobius RDS InfoPac Subtypes 6 and 7.
Support for Oracle OSDI format (8.1.7) SMF record INCOMPATIBLE.
Support for RMF III Enclave Table ENCG3.
Support for CA TNG Windows 2000 performance cube.
New ASUMUOWT creates PDB.ASUMUOW from Landmark TMON + DB2ACCT.
Enhanced UTILBLDP, examples for only RMFINTRV, only JOBS, etc.
MXG 19.19 corrections:
- TYPEIMSA Syntax error: Two %%VMXGTIME should be %VMXGTIME.
- AS/400 JBCPU/JBTCPU wrong in QAPMJOBM, IBM doc was wrong.
- VMXGUOW did not increment SPINCNT for ASUMUOW.
- If you used the new UTILEXCL utility to create your IMACEXCL, it
causes ASUMUOW to syntax fail; some computed variables weren't.
Also, some optional segments were not correctly recognized.
And it is enhanced to report if you have deleted any variables
are required to create ASUMUOW.
- DAILYDSN writes to PDB versus DATASETS; four _P should be _L.
- JCLTEST6 SAS V6 only, temp var SYS000008 name is too long.
- VMXGSUM with OPTIONS OBS=0 could cause errors.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
MXG QA test are with SAS V8.2 and (archaic) SAS V6.09 on OS/390, and
SAS V8.2 on Windows 2000, but previous QA tests on Linux RH 7.2 had
confirmed MXG's unix compatibility, so MXG should execute under SAS
V8.2 or later on every possible SAS platform!
MXG has also executed without error under SAS Version 9 beta, on both
"MVS" and Windows platforms.
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.7.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2, IRD enhancements Apr 26, 2002 20.01
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.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 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 30, 2001 19.19
DB2 7.1.0 corrections Mar 30, 2001 20.06
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
MQ Series 5.2 Dec 16, 2000 18.10
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
NTSMF 2.4.4 Aug 9, 2002 20.04
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
IMS 4.1 Jul 4, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 20.01
IMS 7.1 ??? ?, 199? 20.01
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
AS400 4.5.0 Jul 27, 2000 18.07
Note: An asterisk before the version number indicates that this
entry was changed to a later version of MXG being required,
after it was found that the previous version did not support
the listed product level, usually the result of an APAR to
the product that modified the products data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
SAS Institute
MXG executes best under SAS Version 8.2, with 82BA77 HOTFIX for
MVS-OS/390-z/OS which includes Critical fixes; see NEWSLTRS.
It has executed succesfully under SAS Version 9 Beta on both
MVS and Windows platforms.
See Newsletters for expanded discussion of other versions.
Read member NEWSLTRS (search 'V8') for SAS Version 8 notes.
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
Windows 2000 Build 2195 17.10
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
NTSMF Version 2.3 17.10
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 20.04
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 CICS/ESA 2.1 - 20.04
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
The Monitor for MVS/ESA 3.0 - 19.19
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 CICS V500 User SMF 18.01
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
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 7.0 - ASMIMSL6/TYPEIMSA *20.01
IMS 6.1 - ASMIMSL6/TYPEIMSA *20.01
IMS 5.1 - ASMIMSL5/TYPEIMSA *19.08
Amdahl
APAF 4.1, 4.3 16.08
II. Incompatibilities and Installation of MXG 20.09.
1. Incompatibilities introduced in MXG 20.09 (since MXG 19.19):
a- Changes in MXG architecture made between 19.19 and 20.09 that might
introduce incompatibilities.
NONE.
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.
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.
OBSERVATION COUNT CHANGE: xxxxxxxx more/fewer observations.
This new note will be the last line of new Changes that alter the
number of observations MXG creates in dataset xxxxxxxx.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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.12:
Dataset/
Member Change Description
Many 20.268 Syntax INPUT +(-4) @; replaces M4=-4; INPUT +M4 @;
Many 20.299 MXG Checked by SAS/ITSV Dictionary Build process.
Many 20.324 Semi-colons added after each _Edddddd exit statement.
ADOCxxxx 20.338 All 282 ADOCs updated with all variables, old text.
ADOCSASU 20.292 Mapping of SAS Procedure Name to Product updated.
ANAL116 20.313 Example graphs of MQ Series SMF 116 data.
ANAL94 20.080 Revised to use SMF94VLC rather than SMF94VLS.
ANAL94 20.294 VTS activity reports selection SUBREP= parm added.
ANALCICS 20.193 VARIABLE OPERATOR NOT FOUND if OPERATOR excluded.
ANALCNCR 20.224 KEEPIN= argument no longer used, won't cause failure.
ANALDB2K 20.128 New member combines DB2ACCTP with DB2ACCT data.
ANALPROG 20.075 SAS V8 INHERIT option caused wrong label for NRTIMES.
ANALRACF 20.015 Bogus SAS error; ENTITY was used as array name.
ANALREG 20.183 Example regression of two variables with DATA step.
ANALRMFR 20.104 "RMF HTTP Server Report" multiple servers, etc.
ANALRMFR 20.277 RMF Channel Activity Report CHP= selectivity added.
ASMRMFV 20.033 Support for RMF III Enclave Table ENCG3.
ASMRMFV 20.068 RMF III support enhanced and corrected.
ASMRMFV 20.135 OC4 ABEND in ASMRMFV if CSR table was empty.
ASMTAPES 20.320 ML-27 now robust, low CPU, sees VTS, no XMEM, etc.
ASUM42DS 20.124 SORTEDBY= in VMXGSUM required change to ASUM42DS.
ASUM7072 20.169 Variable LPnLAC (4-hr MSU) added to ASUM70PR/ASUMCEC.
ASUMDB2A 20.039 Tailoring example for dropped variables from DB2ACCT.
ASUMUOW 20.086 EXECAPPL, the "execution" APPLID, added to ASUMUOW.
ASUMUOWT 20.038 Create PDB.ASUMUOW from Landmark TMON/CICS + DB2ACCT.
ASUMUOWT 20.251 Change 20.221 to VMXGUOW caused ASUMUOWT to fail.
AUTOEXEC 20.252 Support for Version 9 TS M0 Production Release.
BLDNTPDB 20.323 Some combinations of arguments didn't work right.
BUILDPDB 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
BUILDPDB 20.319 OMVS task filled //SPIN, had TYPETASK='JOB' in error.
BUILDPDB 20.330 New CSTORE30,ESTORE30 variables in STEPS,SMFINTRV.
CONFIGV8 20.019 //USER or directory named "user" causes SAS errors.
CONFIGV9 20.252 Support for Version 9 TS M0 Production Release.
DAILYDSN 20.020 DCOLLECT datasets written to PDB instead of DATASETS.
EXddddd 20.266 EXdddddd members are now one executable statement.
FORMATS 20.127 IBM MSU Capacity for 7060s only in format table.
FORMATS 20.194 MSU constants updated for 2064-2xxx family.
FORMATS 20.291 Support for APAR OW57121 new SMF 99 trace codes.
FORMATS 20.292 Mapping of SAS Procedure Name to Product updated.
GRAFWRKX 20.105 Enhanced "Weighted LPAR Capacity" Graph/Tabular
GRAFWRKX 20.273 Workload Graph examples include MSU used by workload.
IMAC6ESS 20.332 Support for more ESS variables (on OUTPUT statement)
IMACESS6 20.090 Unknown ESS keys not skipped if GEPARMNR GT 1.
JCLTEST6 20.002 SAS V6, VMACTMV2, variable SYS000008 name too long.
JCLUOWP 20.312 JCL example for ASUMUOW using Views/Pipes corrected.
JCLUOWV 20.269 VARIABLE TIMESTMP NOT FOUND building ASUMUOW.
MONTHBLD 20.094 SORTEDBY= added to Monthly PDB datasets
READDB2 20.270 Enhancement for IFCIDs 202, 230, 230, not in SMF 102.
REXXWLM 20.289 Support to read Workload Manager's WLM Defs PDS.
RMFINTRV 20.168 MSU4HRAV corrected, MSU-related variables documented.
RMFINTRV 20.297 Workloads can use SYSTEM/SYSPLEX as criteria.
TRND23 20.239 Trending for TYPE23 (SMF Buffer Usage) was wrong.
TRNDRMFI 20.099 Variable MSU4HRMX was missing in TRNDRMFI.
TRNDRMFI 20.249 New TRENDOLD= parm lets you use GDGs for TREND.
TYPE102 20.228 QW0022TS/BT were wrong if your GMTOFFDB was non-zero.
TYPE102 20.336 Support for IFCID=247 in T102S2347 dataset.
TYPE103 20.104 TYPE103x HOSTNAME increased to $32
TYPE103 20.130 Support for APAR PQ61349.
TYPE108 20.032 Timestamps DOMBTIME/DOMETIME incorrect.
TYPE110 20.102 CICSJOUR was incorrect for CICS/ESA 4.1, 5.1.
TYPE110 20.108 Doc: Variable UOWTIME may look wrong, but it's okay.
TYPE110 20.200 Support for CICS Transaction Resource Class new data.
TYPE110 20.225 Support for CICS APAR PQ63143 changes to 110-2 stats.
TYPE110 20.293 UNKNOWN STID=115 messages should not exist.
TYPE119 20.085 Subtype 3 caused INVALID DATA, now corrected.
TYPE119 20.267 TSIPxxxx variables wrong in TYPS11905, other fixes.
TYPE120 20.029 Lower case "f" in DBCS variables changed to blank.
TYPE120 20.066 Datasets TYP120JC/JI were not sorted to PDB by _S120.
TYPE120 20.204 Support for SMF 120 subtype 7 and 8 WebSphere 4.0.1.
TYPE26J2 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE26J2 20.149 TIMEBILD now uses correct SYSxxxx for time conversion
TYPE26J3 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE28 20.316 Support for Tivoli Netview NPM 2.7 SMF 28 records.
TYPE30 20.082 Support for z/OS 1.3 (COMPATIBLE).
TYPE30 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE30 20.197 JOB=JES2 blank READTIME caused INVALID READTIME msg.
TYPE30 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
TYPE30 20.330 New CSTORE30,ESTORE30 variables in TYPE30_4,_5,_V.
TYPE42 20.082 Support for z/OS 1.3 (MXG Change Required).
TYPE42 20.129 Support for APAR OW54007.
TYPE42 20.134 S42DSBUF was incorrect, buffer type wrong.
TYPE42 20.182 SMF42NRS, JPF,JPE,JNF,JNE documentation wrong.
TYPE6 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE64 20.212 Support for APAR OW56162 new SMF 64 CATALOG UPDATE.
TYPE70 20.043 Support for z800 2066 CPUs at OS/390 R2.8-2.10.
TYPE70 20.046 PCTCPUBY etc wrong with WLM IRD controling CPUs.
TYPE7072 20.089 Variable MSU72 created in TYPE72/TYPE72GO.
TYPE7072 20.140A Values in SMF70CSF,ESF now correct, IBM doc wrong.
TYPE7072 20.169 Variable SMF70LAC (4-hr MSU) added to TYPE70PR
TYPE7072 20.274 Support for APAR OW56739, RMF 72 subtype 3.
TYPE7072 20.307 Errors in TYPE72GO (MXG 20.08-20.09 only) corrected.
TYPE71 20.259 Medium Impact Frames ESFRMExx are now input in order.
TYPE72GO 20.045 Variable VALDSAMP now reset to equal R723CTSA.
TYPE72GO 20.069 Support for APAR OW52227 (Active Appl State) for WLM.
TYPE73 20.096 SMF73ACR='CFS' TYPE73 obs had PCHANBY missing.
TYPE73 20.172 Variables PCHANBY/PNCHANBY/PBUSBY carried forward.
TYPE73 20.240 PCHANBY/PNCHANBY mising with SMF73CMG=0.
TYPE74 20.116 Support for type 74 subtype 7 FICON data.
TYPE74 20.205 Support for z/OS 1.4 (COMPATIBLE), minor change
TYPE74 20.213 Support for APAR OW52396 (no change) SMF 74-7 FICON.
TYPE74 20.241 Support for APAR OW55968 (R744SST 4 to 8-byte).
TYPE78 20.050 Domain Error in 78 IOP corrected.
TYPE78 20.077 Using TIMEBILD, STARTIME was converted twice.
TYPE78 20.235 Support for APAR OW54010 Large Virtual Memory (>2GB).
TYPE79 20.083 Domain Error in 79-12, new CMG data now DIF()'d.
TYPE79 20.205 Support for z/OS 1.4 (COMPATIBLE), minor change
TYPE79 20.274 Support for APAR OW56739, RMF 79 subtype 3.
TYPE79 20.325 TYPE792 was incorrectly deaccumulated.
TYPE80A 20.010 Support for Top Secret V.2.
TYPE80A 20.218 Support for UID/HOME/PROGRAM OMVS/USS RACF fields.
TYPE80A 20.226 Example of RACF Filtering with TYPE80A and MACJBCK=.
TYPE90A 20.125 Support for type 90 subtype 32 (don't use TYPE90).
TYPE90A 20.281 VERSN90 is binary in some subtypes, was EBCDIC.
TYPE91 20.097 Domain Error in SMF91SDI/SDO corrected.
TYPE94 20.080 SMF94VLS now contains characters, new SMF94VLC.
TYPE94 20.206 Support for SMF 94 subtype 2 and subtype 1 new stuff.
TYPE94 20.265 SMF 94 FC4001 undocumented fields caused wrong value.
TYPE94 20.283 SMF 94 Subtype 2 now heuristically decoded.
TYPEAIX 20.091 Enhanced AIX PTX (Performance ToolBox) adds obj/vars.
TYPECIMS 20.138 CIMSDBDS DBDORG='00'X no longer output.
TYPECIMS 20.306 No observations in CIMSDBDS after Change 20.138.
TYPECPOD 20.230 Support for Control-D "POD" User SMF record.
TYPECSF2 20.231 Support for Control-D "SF2" User SMF record.
TYPEDB2 20.173 QWAXvvvv variables shouldn't be used, but now valid.
TYPEDB2 20.195 DB2 QWACAWTK/M/N/O/Q ARNK/M/N/O/Q etc missing/wrong.
TYPEDB2 20.210 DB2 V6 variables QWACARLG & QWACAWLG were missing.
TYPEDB2 20.222 Negative DB2SRBTM with DB2 V7 forced back to missing.
TYPEDCOL 20.171 Variable DCDRECFM decodes FBA or VBA Record Formats.
TYPEEDGR 20.331 Support for DFSMSrmm Extended Extract 'X' records.
TYPEEMCS 20.165 Support for EMC's Catalog Solution user SMF record.
TYPEESPH 20.318 Support for Cybermation's ESP Product JOBHIST file.
TYPEHURN 20.248 Overlooked HU47xxxx and HU49xxxx variable input.
TYPEIDMS 20.237 Circumvention for IDMS Version 1500, no new data yet.
TYPEIDMS 20.304 Support for IDMS V1500 new subtypes 13, 14, 15.
TYPEIMSA 20.021 Syntax error. Two %%VMXGTIME( should be %VMXGTIME.
TYPEIPAC 20.014 Support for Mobius RDS InfoPac Subtypes 6 and 7.
TYPEMPLX 20.141 Support for IMPLEX Version 2.1 has been coded.
TYPEMVCI 20.263 Support for BMC MVCICS 5.6, fix for 5.5 CMRDETL data.
TYPENDM 20.211 NDM/Connect Direct writes invalid SMF record.
TYPENPIP 20.070 Support for new IBM Product NPM/IP monitor SMF.
TYPENSPY 20.305 Support for NetSpy Version 6 subtypes G,H (COMPAT).
TYPENTSM 20.100 Support for Citrix process record.
TYPENTSM 20.132 Support for NTSMF File System Collector. NT DCOLLECT!
TYPENTSM 20.144 PROCESS object POOLxxxx,HANDLES were wrong.
TYPENTSM 20.156 Support for NTSMF 2.4.4, MODULE Object, Disk percents
TYPENTSM 20.176 Support for Oracle and Analysis Server NTSMF objects.
TYPENTSM 20.276 Support for MS E2K SP3, XP Prof, new vendor objects.
TYPENTSM 20.286 MicroSoft added instance names for SMF objects.
TYPEOMCI 20.234 Support for Candle Omegamon for CICS V520 User SMF.
TYPEOMVT 20.189 Candle OMEGAMON/VTAM Release 5.2.0 IRNUM=27 corrected
TYPEOPC 20.321 IBM's OPC Log causes INVALID ARGUMENT TO FUNCTION....
TYPEORAC 20.007 Support for Oracle OSDI format (8.1.7) (INCOMPAT).
TYPEORAC 20.111 Oracle OSDI Subsystem Name text externalized.
TYPEQACS 20.004 JBCPU/JBTCPU wrong in QAPMJOBM, IBM doc is wrong.
TYPEQACS 20.078 AS400 4.5.0 INVALID data, 5.1.0 JBEDBC/JBTDCB fixed.
TYPEQACS 20.260 Support for AS/400 5.2 Collection Services (INCOMPAT)
TYPEQACS 20.295 AS/400 CPU times merged in optional QACSCPU dataset.
TYPERMFV 20.334 Numerous enhancements/corrections to RMF III support.
TYPESAMS 20.192 Support for SAMS:VANTAGE 3.2.0 OBJ=POOLS record.
TYPESASU 20.236 Variable SASPROD, SAS Product Name, now kept.
TYPESRMH 20.317 Security Resource Manager for MVS V2.3 correction.
TYPESTC 20.088 Support for St. 27/28/29 of STK HCS/VSM records.
TYPESTC 20.220 STC28TIM in STCVSM28 from STK User SMF was wrong.
TYPESTC 20.242 STK HSC Subtype 29 INPUT STATEMENT EXCEEDED error.
TYPESYNC 20.309 Support for SYNCSORT for z/OS 1.1 SMF record.
TYPETAND 20.106 Support for G06/G08 TANDPROC LRECL=442 (INCOMPAT).
TYPETAND 20.250 Support for Tandem G07 new data, fix TANDPROC G06.
TYPETMDB 20.095 TMON/DB2 Timestamps wrong if GMT Offset is nonzero.
TYPETMDB 20.139 Landmark TMON/DB2 datetimes wrong if GMTOFF GT 0.
TYPETMDB 20.161 Support of ASG-Landmark TMON/DB2 Version field 3.2.
TYPETMO2 20.072 Support for TMON/CICS TCE 2.1 (INCOMPATIBLE).
TYPETMO2 20.140 Landmark TMON/CICS datetimes wrong if GMTOFF GT 0.
TYPETMO2 20.187 MONITASK variables STORVIOL/ABNDMONI weren't created.
TYPETMO2 20.253 Support for ASG-Landmark TMON/V2.1 TH01595 (COMPAT)
TYPETMO2 20.335 Support for ASG/TMON CICS V2.2 INCOMPATIBLE.
TYPETMVS 20.201 Support for ASG-Landmark TMON/MVS V3 (INCOMPATIBLE).
TYPETNG 20.028 Support for CA TNG for Windows 2000.
TYPETNG 20.062 STARTIME in TNG datasets was an hour early.
TYPETNG 20.092 Support for many new TNG Platforms (SOL, AIX) etc.
TYPETNG 20.180 TNG Start Hour defaults to zero, externalized.
TYPETPMX 20.208 TYPETPMX variable SPACE renamed to SPACERQ.
TYPEVIOP 20.216 INPUT STATEMENT EXCEEDED with VIO PLUS SMF record.
TYPEVMXA 20.081 z/VM MONWRITE DATABYTE=0 caused MXG to stop reading.
TYPEXAM 20.315 Support for Velocity Software's ESAMON VM Monitor 3.2
TYPSMQM 20.188 Example member to read //SMF to create all MQM data.
TYPSTHST 20.202 Support for BMC's Mainview for DB2 THRDHIST file.
TYPSTHST 20.245A MACRO _THRDHST should have INFILE THRDHIST, not SMF.
UNIXSAR 20.314 Enhancements to process unix sar command output.
UTILBLDP 20.013 Enhancement, examples for only RMFINTRV, JOBS.
UTILBLDP 20.329 Enhancement if BUILDPDB=NO is specified.
UTILEXCL 20.008 UTILEXCL caused ASUMUOW to fail, missed IMS data.
UTILEXCL 20.040 Tests IF SEGLEFT GE CMODLENG now IF SEGLEN GE nn.
UTILEXCL 20.074 Excluded fields from multiple CICS versions support.
UTILEXCL 20.084 Final (?) cleanup covers all reported optional data.
UTILEXCL 20.118 Support for CANPROD2/CANPROD3 optional CICS data.
UTILEXCL 20.148 Support for multiple CMODNAME,CMODHEAD='USER' fields
UTILEXCL 20.223 USERCHAR variable generated wrong INCLUDE post 20.148
UTILEXCL 20.256 Major UTILEXCL enhancement, MCTSSDCN/DRL DO grouping.
UTILRMFI 20.162 Revised to use identical arguments as %VMXGRMFI.
VGETDSN 20.035 New utility to get DSNAME, can allocate next GDG.
VGETJESN 20.190 "Z2" Jnnnnnnn JESNR support protects SMF 6 record.
VGETJESN 20.326 Type 30s with JCTJOBID='INTnnnnn' protected.
VMAC115 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
VMAC116 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
VMAC7072 20.272 Zeroed MSU variables from old S/390 are now non-zero.
VMAC80A 20.257 Message VMAC80A.WARN. MORE DTP... revised, 15 kept.
VMXGFOR 20.327 All %VMXGFOR were removed, to avoid a SAS zap.
VMXGINIT 20.278 %UPCASE added by 19.295 was dropped in 20.019
VMXGINIT 20.296 Macro variables &TRNDIN,&TRNDOUT defined for TREND.
VMXGRMFI 20.017 OPTIONS OBS=0 could cause errors.
VMXGRMFI 20.079 Mismatch now reports all INn status variables.
VMXGSUM 20.017 OPTIONS OBS=0 could cause errors.
VMXGSUM 20.094 SORTEDBY= added to Output VMXGSUM dataset.
VMXGSUM 20.142 SORTEDBY= filed if dropped variable only in SUMBY=.
VMXGSUM 20.238 Documentation: Don't use TEMP01 with %VMXGSUM.
WEEK70PR 20.199 Typo SAT.TYPE70PR read twice, FRI not read.
WEEKBLD 20.094 SORTEDBY= added to WEEKLY PDB datasets
Inverse chronological list of all Changes:
NEXTCHANGE: Version 20.
====== Changes thru 20.341 were in MXG 20.20 dated Feb 5, 2003=========
Change 20.341 Support for APAR OW57396 adds two flag fields, SMF22CYS
VMAC22 and SMF22PCY to the TYPE22_A dataset (the APAR calls the
Feb 6, 2003 two fields SNSSDST3 and SSCBDVC4, to describe the reason
for the state-change interrupt during FlashCopy.
Thanks to Susan Greenlee, IBM, USA.
Change 20.340 Summarized RMFINTRV data (for example, RMFINTHR from 15
RMFINTRV minute RMFINTRV data) will have a high value for MSU4HRAV
Feb 6, 2003 in any interval that crosses an IPL. The interval will
have a DURATM considerably smaller than your requested
hour summary, so these intervals can be detected/deleted
by testing for DURATM less than your summary interval
This is an MXG coding error, only in RMFINTHR; the
ASUM70PR and ASUMCEC data is correct across an IPL
(but note that MXG keeps history, and uses those
prior hours, IBM's SMF70LAC starts new with each
IPL, so "correct" is in the eyes of the beholder).
and I will eventually take time and figure out how to
correct the logic, but not right now!
Jun 9 2003: See Change 21.094.
Thanks to Craig Collins, State of Wisconsin, USA.
Change 20.339 Support for MainView TCP/IP SMF record with many datasets
EXMVTPA and almost all of them are wrong; the only documentation
EXMVTPC available was the sample SAS code from BMC, and it was
EXMVTPD restructured into MXG source format, labeled, etc., and
EXMVTPF then the test records were examined, only to find that
EXMVTPH the data and sample code do not agree.
EXMVTPI If you are interested in this support, please contact me,
EXMVTPN send me your current SMF records, and I will pursue the
EXMVTPO actual DSECT documentation so I can rewrite the support.
EXMVTPP And since I could not validate the new support, there may
EXMVTPR be variable names in conflict with existing MXG names
EXMVTPS that may need to be changed.
EXMVTPT But at least the structure and contents of all of the 14
EXMVTPU new datasets is complete!
EXMVTPV
IMACMVTP
TYPEMVTP
TYPSMVTP
VMACMVTP
VMXGINIT
Feb 6, 2003
Change 20.338 All ADOCxxxx members were programatically updated with
ADOCs all variables created by MXG 20.10, but all existing
Feb 6, 2003 comments and descriptions (manually made) are preserved
by a slick utility program Freddie developed to read the
old and merge in the new (and by agreed syntax standards
in the ADOCs structure, so his program works!).
Thanks to Freddie Arie, TXU, USA.
Change 20.337 Using example 4 in UTILEXCL, which reads CICS records to
UTILEXCL create and write member IMACEXCL to your USERID.SOURCLIB
Feb 5, 2003 tailoring library, writing to this DD statement:
//IMACEXCL DD DSN=MXG.USERID(IMACEXCL),DISP=SHR
then the example reads that IMACEXCL member from that
dataset, using %INCLUDE SOURCLIB(IMACEXCL); from this DD:
//SOURCLIB DD DSN=MXG.USERID,DISP=SHR
// DD DSN=MXG.SOURCLIB,DISP=SHR
resulted in an UNDETERMINED SAS I/O ERROR and a SYSMSG
entry "OUT OF EXTENTS", with both SAS V8.2 and V9.0, but
only when:
the USERID.SOURCLIB was extended into another extent
by the writing of the IMACEXCL member to the PDS.
Breaking the example into two MVS steps did not fail; the
IMACEXCL member was read correctly from the extended-PDS
in the second step. While this will ultimately be fixed
by SAS (I hope!), if you use this technique of writing to
your USERID.SOURCLIB, you should make sure it has a large
primary, and compress it after each run, to avoid this
exposure.
That same error message is also documented in NEWSLTRS
for a completely un-related problem: if you have your
datasets in your //SOURCLIB concatenation that are
mixed PDS and PDSE source libraries.
Only all-PDS libraries is guaranteed to be error free!
The error will be discussed with SAS Institute, and this
note will be revised if a correction becomes available.
No code change was made; documentation only.
Thanks to MP Welch, SPRINT, USA.
Change 20.336 Support for DB2 Trace IFCID=247 (SMF 102 subtype 247) now
VMAC102 populates the trace variables in dataset T102S247.
Feb 2, 2003
Thanks to Terry L. Berman, DST Systems, USA.
====== Changes thru 20.335 were in MXG 20.12 dated Feb 2, 2003=========
Change 20.335 Support for ASG/Landmark TMON for CICS/ESA Version 2.2.
VMACTMO2 INCOMPATIBLE, causing INPUT STATEMENT EXCEEDED errors:
Feb 2, 2003 -Field inserted in 'TP' record header and sub records.
-Field inserted in 'TR' record header.
-Field inserted in 'TK' record header.
-Field inserted in 'TS' record header.
-Field inserted in 'T2' record header.
-Field inserted in 'TM' record header.
-Field inserted in 'TN' record header.
-Field inserted in 'TT' record header.
-Field inserted in 'TX' record header.
-Fields inserted and removed in 'TA' record.
-Some overlooked $CHAR fields are now formatted $HEX.
-Useful new MQSERIES counts/duration variables are created
in MONITASK dataset.
Change 20.334 -ZRBDVT kept twelve accumulated start and end values which
VMACRMFV are unneeded and are now dropped; the delta values are in
Feb 2, 2003 the six variables PENDTM DISCTM CONNTM DVBUSYTM CUBUSYTM
Feb 3, 2003 and SWPODLTM. The _SZRBDVT now actually sorts vice copy.
-ZRBGEI kept four accumulated start and end values which
are unneeded and are now dropped; the delta values are in
new variables GEIESPM and GEIESPR. OS/390 set several GEI
fields reserved, causing CPUWAITM to be zero and PCTCPUBY
to be missing. The PCTCPUBY is in dataset ZRBCPU.
-Variable ASIAUXSC is now divided by sample count, and the
_SZRBASI now actually sorts vice copy.
-ENCG3 record with RDW=804, DEO=@296 DEL=608 caused INPUT
STATEMENT EXCEEDED RECORD ERROR and is now protected, but
it was caused by using ASMRMFV program earlier than MXG
20.02, which corrected Enclave support. No-longer-needed
triplet variables are no longer kept.
-All _SZRBxxx macros now PROC SORT their dataset to PDB
(most just had a Data step) because their _BZRBxxx macro
now have BY-list variables of SYSPLEX SYSTEM SSHTIBEG and
possibly more.
Thanks to Betty Wong, Bank of America, USA.
Thanks to John Gebert, Office Depot, USA.
Change 20.333 Using READDBw with IFCIDS=ALL is strongly disrecommended,
READDB2 as it requires massive virtual storage and compile time
Jan 31, 2003 to generate the data step for all 300+ DB2 trace records,
and you could never have all those IFCIDs enabled; if you
did, you'd be running an SMF stress test, not a DB2 test!
but now, IFCIDS=ALL will compile correctly; Change 20.270
introduced syntax errors when IFCIDS=ALL was used.
Additionally, IFCIDS= 1 2 are now supported as arguments
(although they are redundant with ACCOUNT).
Thanks to John Gebert, Office Depot, USA.
Change 20.332 -IMAC6ESS: Support for optional ESS variables from OUTPUT
FORMATS statements, including the USERDATA= field, which can be
IMAC6ESS used: USERDATA=(ACCT=123456) to set accounting fields
VMAC6 for each OUTPUT statement, new variable ESSUSDAT, plus
Jan 31, 2003 less-important variables ESSTRC, ESSDATCK, ESSCHARS-4,
Feb 3, 2003 ESSUCS and ESS0013 for undocumented IEFDOKEY='0013'x.
Feb 4, 2003 Protection added if more than four ESSCHARn fields are in
the SMF record.
-VMAC6: Variable BINUSED='00'X is set for non-PSF type 6
records; all BINxxxxx fields only exist in APF-PSF data.
-FORMATS. Variable BINUSED's format MG006BN was updated
for bins 3,4 and combo's of bins, "NOT PSF" for '00'x.
Thanks to Ricke Godehard, Itellium, GERMANY.
Change 20.331 Support for DFSMSrmm Extended Extract Data Set Records,
EXEDGRX which are written as EDGRTYPE='X', along with the other
IMACEDGR records, by IBM's EDGHSKP program to a flat file that is
VMACEDGR read by MXG from the INFILE name of EDGHSKP. The new 'X'
VMXGINIT record creates new EDGRXEXT dataset with all variables
Jan 30, 2003 from the 'V' volume record (MXG dataset EDGRVEXT) and all
of the variables from the 'D' dataset record (MXG dataset
EDGRDEXT); now that I've written the code to create the
new dataset from the new X record, I realize I could have
instead created it simply by MERGEing the EDGRVEXT Volume
and EDGRDEXT Dataset MXG dataset, since the X record is
completely redundant with the V and D records. IBM added
the 'X' record with APAR OW47651, June, 2001.
Thanks to Donald P. Ludwig, United Health Care, USA.
====== Changes thru 20.330 were in MXG 20.11 dated Jan 30, 2003=========
Change 20.330 Useless MSO-based variable PAGESECS (SMF30PSC):
BUILD005 the CPU-TCB-only-based memory occupancy page-seconds,
BUIL3005 the soon to be useless variable RESESFTP (SMF30ERS):
VMAC30 active-time-based expanded memory storace occupancy,
Jan 30, 2003 and the very useful variable IARVPSEC (SMF30PSF):
active-time-based central memory storage occupancy
were all 2.4% too low; IBM now documents them as being in
'page-milliseconds - 1.024 milliseconds', but MXG had
used 1000 rather than 1024 in its internal conversion.
This change creates new CSTORE30 and ESTORE30 variables
with the average storage occupancy size in bytes, for the
TYPE30_4, TYPE30_5, TYPE30_6, and TYPE30_V datasets, and
those new variables are also propagated into the dataset
PDB.STEPS and PDB.SMFINTRV if BUILDPDB/BUILDPD3 is run.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 20.329 -With BUILDPDB=NO, and enabling USERADD=6 26 30, and also
UTILBLDP INCLAFTR=BUILD005, macro names generated for input data
UTILRMFI for BUILD005 now knows to get it from //PDB, which is
Jan 31, 2003 where USERADD= stored them. Also, UTILBLDP defaulted to
execute ASUMxxxx members if it found you were USERADDing
their input, even when you specified BUILDPDB=NO. Now,
those ASUMs are generated only with BUILDPDB=YES, so you
would use INCLAFTR=ASUM70PR, to execute only the ASUMs
you want.
-UTILRMFI now prints a report2 even if there is no data;
the report says there was no data. Previously, only a
message to the log was written when there was none.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 20.328 The period in the //TAPETEMP DD was changed to a comma.
JCLWEEKT
Jan 28, 2003
Thanks to Dave Crowley, Blue Cross Blue Shield of Florida, USA.
Change 20.327 All references to %VMXGFOR and %%VMXGFOR were removed in
VMXGFOR all MXG members (except CHANGES/CHANGESS) and the VMXGFOR
Jan 28, 2003 member remains for historical interest! This %MACRO has
the value "FORCE" in SAS V6 and later, and was blank in
SAS V5. In SAS V6, SAS chose to prevent a SORT which had
the same input and output dataset names when the option
OBS=N (rather than =MAX) was in effect (so that a dumb
user didn't replace a million obs dataset with only N
obs), but then initially provided the FORCE option so you
could override that choice. Because using OBS=N is smart
for testing (so you don't have to read the whole file),
MXG added %VMXGFOR to all PROC SORTs to permit it. And
then SAS made the original behavior the default with a
6.07 zap, but MXG users didn't have to install the zap,
since %VMXGFOR permited the sorts with OBS=N anyhow.
Now, a new 0C4 error in SAS has occurred in the handling
of the autocall for %VMXGFOR in SAS V8.2, and SAS note
SN-009297 documents the problem that will be corrected,
but by removing the FORCE option from all 282 members,
the autocall is avoided, and you won't have to install
the SAS fix when its available.
Change 20.326 Type 30 records from OS/390 R2.10 with JOB='INIT' have an
VGETJESN undocumented and unexpected value of JCTJOBID='INTnnnnn';
Jan 28, 2003 JCTJOBID='STCnnnnn' is the expected value of SMF30JNM.
This unexpected prefix caused MXG to set TYPETASK='INT '.
The logic to set TYPETASK was changed to recognize these
values and set TYPETASK='STC ', and additional protection
for future undocumented values of JCTJOBID was added.
Thanks to Roger P. Martens, International Truck and Engine Corp, USA.
Change 20.325 TYPE792 was incorrectly deaccumulated, as there are many
VMAC79 repeated entries with same JOB (R792JBN); added ASID to
Jan 24, 2003 separate in the SORT and in the IF FIRST. logic. This
problem was only seen for OMVS jobs. Same change made in
TYPE791 just because it was also sorted by R791JBN.
Thanks to Stan Dylnicki, RBC, USA.
Change 20.324 Almost cosmetic; semi-colons were added after each of the
DOC _Edddddd exit invocations. In general, not required, but
Jan 24, 2003 their existence can be exploited in members that generate
code (BLDNTPDB, READDB2), and it was my intention to have
them always present, even if unneeded.
Change 20.323 Using RUNDAY=YES,RUNWEEK=YES,RUNMNTH=YES,RUNNTINT=NO
BLDNTPDB caused errors, attempting to create NTINTRV, even though
VMACNTSM RUNNTINT=NO. TRNDNTIN was initialized and fixed. The
Jan 23, 2003 KEEPERS= logic was revised.
Jan 28, 2003 -VMACNTSM did not have the normal semicolon after each of
the _Edddddd exit macro invocations, which are required
only if you re-define those exits (as is done in this
case by BLDNTPDB), and a dataset label was respelled.
Thanks to Fiona Benoist, UFI Limited, ENGLAND.
Thanks to Chris Morgan, UFI Limited, ENGLAND.
Thanks to Terry Heim, ECOLAB, USA.
Change 20.322 The PROC FREQ failed if &OUTDETAL was specified; a test
ANALCNCR for &OUTDETAL now uses DATA=&OUTDETAL when that option is
Jan 22, 2003 specified.
Thanks to Kris Ferrier, State of Washington, USA.
Change 20.321 IBM's OPC Log data causes: INVALID ARGUMENT TO FUNCTION
IHDROPC error messages followed by INVALID MTD SUBTYPE. IBM has
VMACOPC changed their data, but no OPC site has yet been able to
VMXGINIT get IBM to provide the DSECTS for the MTD sub-segment,
Jan 17, 2003 which is part of the TRLRCTYP=24 "MCP EVENT" OPC record.
Fortunately, since neither site needed the datasets built
from that OPC record, they just deleted that record and
were able to continue using OPCLOG for their purposes.
This change creates the IHDROPC "OPC LOG Header Exit"
member (and &MACOPCH macro variable) so that you can
delete the TRLRCTYP=24 records in the exit or instream.
In member IMACOPCH, use IF TRLRCTYP=24 THEN DELETE;
Or instream, after your //SYSIN, you would use:
%LET MACOPCH=%QUOTE( IF TRLRCTYP=24 THEN DELETE; );
Thanks to Andrew Phillip Davis, Abbey National, ENGLAND.
Change 20.320 ASMTAPES/MXGTMNT is healed in ML-27. Option XMEM=OFF now
ASMTAPES elimimates the increase CPU time cause by fast VTS mounts
TAPEVENT (that caused 0E0 ABENDs because the job was already gone)
Jan 20, 2003 by elminating the cross memory call. This permits the
MXGTMNT monitor to be run at 0.1 seconds with minimal CPU
ML-19 @2 sec 1.36 sec/hr ML-27 @2 sec 1.8 secs/hr
ML-27 @.5 sec 6 sec/hr ML-27 @.1 sec 28.5 sec/hr
Feb 5: Do not use //EXCLUDE DD statement; causes 0C4,
awaiting dumps to examine. No other problems
have been reported. At 0.5 seconds interval,
the monitor takes less than 1 second per hour
when there are no tape mounts on that system.
Change 20.319 VGETJESN erroneously set TYPETASK='JOB' for OMVS tasks,
BUILD005 instead of TYPETASK='OMVS', causing OMVS TYPE30_1/_4/_5s
BUIL3005 to be sent to SPIN, instead of being written to the PDB
VGETJESN (OMVS type 30s have no 6s nor 26s to match), causing the
Jan 15, 2003 SPIN library to increase in size.
VGETJESN now sets TYPETASK='OMVS' if SUBSYS='OMVS', even
though those OMVS data have JCTJOBID='JOBnnnnn'.
Fortunately, these type 30 step records for OMVS tasks
are rarely important; if you do nothing, these records
will be output into your PDB library in SPINCNT days.
To remove the OMVS records from your SPIN library and to
thus prevent further growth, you can use the IMACSPCK
tailoring member to set OKFLAG=1 for these OMVS jobs.
In the SPIN30_1 and SPIN30_4 datasets, variable SUBSYS
exists and can be tested for 'OMVS', but you will need to
examine variable RACFGRUP in your SPIN30_5 dataset, as it
is the only variable you can use for SPIN30_5 (other than
a large table of JOB names). Then you can put this code:
IF SUBSYS='OMVS' OR RACFGRUP='OMVSGRUP' THEN OKFLAG=1;
in your IMACSPCK tailoring library.
The MXG change-in-error was to support the new JCTJOBID
values in JES "Z2" mode; to further protect OMVS records
from being spun due to any future Merrill error, the two
members BUILD005 and BUIL3005 that hand the OMVS 30s was
redesigned to look for either TYPETASK='OMVS' or for the
SUBSYS='OMVS' value, for added protection.
Thanks to Roger P. Martens, Navistar International, USA.
Thanks to Roger Rush, Navistar International, USA.
Change 20.318 Support for Cybermation's ESP Product's JOBHIST file.
EXESPJHR Dataset ESPJBHIS is created from the INFILE ESPHIST.
IMACESPH
VMACESPH
TYPEESPH
TYPSESPH
VMXGINIT
Jan 14, 2003
Thanks to Jesse Gonzales, The Gap, USA.
Change 20.317 Correction for the Security Resource Manager for IBM MVS
VMACSRMH V2.3, Thales e-security, Host Security Module SMF record.
Jan 14, 2003 Datasets SRMHSMDV and SRMHSMAP did not output repeated
segments, but repeatedly output only the first segment.
Thanks to Russell Dewar, National Australia Bank, AUSTRALIA.
Change 20.316 Support for Tivoli Netview NPM 2.7 SMF 28 changes.
FORMATS -NAC. Eighteen existing variables LNACPT01-LNACPT18 are
VMAC28 now documented and each contains the 3746-900 line
Jan 14, 2003 processor type, now decoded by the new MG028LT format:
Jan 17, 2003 LNACPTnn
value Description
0050X='0050X:CBP (3745-3746/900 LINK)'
0051X='0051X:NNP (APP-Resource)'
0052X='0052X:CLP (SDLC, Frame Relay, X.25)'
0053X='0053X:ESCP (ESCON)'
0054X='0054X:TRP (Token-Ring'
The CPU "NN" value in the MXG label for each of those 18
sets of LNACPxNN variables in the MXG Label is documented
(e.g., LNACPT01='3746-900*LINE*CPU 1*TYPE') and this
table maps the NN value to these line address ranges:
CPU Line Addresses CPU Line Addresses
1 2080-2111 10 2624-2687
2 2112-2175 11 2688-2751
3 2176-2139 12 2752-2815
4 2240-2303 13 2816-2879
5 2304-2367 14 2880-2943
6 2368-2431 15 2944-3007
7 2432-2495 16 3008-2071
8 2496-2559 17 3072-3135
9 2560-2623 18 NNP Processor
-NIT. INCOMPATIBLE inserts of new variables:
NITALIMB='MESSAGE*I-FRAME*BYTES*RECEIVED'
NITALIXB='XID*BYTES*RECEIVED'
NITALOMB='MESSAGE*I-FRAME*BYTES*SENT'
NITALOXB='XID*BYTES*SENT'
NITAPPNI='APPN*DATA'
NITIFSPB='INTERFACE*TABLE*SPEED*BYTES'
NITIFUC ='INPUT*UNICASTS*PACKETS*DLVD HIGHER'
NITIFUTI='PERCENTAGE*TOTAL LINK*CAPACITY*USED'
NITINUC ='INPUT*BCST/MCST*PACKETS*DLVD HIGHER'
NITISLL ='TABLE*STACK*LOW*LAYER'
NITOFUC ='OUTPUT*UNICASTS*PACKETS*DLVD HIGHER'
NITONUC ='OUTPUT*BCST/MCST*PACKETS*DLVD HIGHER'
INCOMPATIBLE in that the NIT variables are trashed by the
inserted fields, but MXG will not fail with the new data;
however, it also will not tell you NIT data is trashed!
-SMC. Scores of new low/high criteria variables are added
(COMPATIBLY, at the end).
-ACD/RCD. The Session Type, LSCDSTYP field, formerly at
offset 006C, is now documented as reserved, but in 2.7
LSCDSTYP still contains known values of session type:
'02'X='02X:3270 RELAY'
'03'X='03X:3270 CONTROL'
'04'X='04X:3270 TRANSIT=DR'
'05'X='05X:3270 TRANSIT=DFC'
'06'X='06X:AGENT SERVER COMMUNICATIONS DATA'
'08'X='08X:APPC PROTOCOL 1'
'09'X='09X:APPC PROTOCOL 2'
'0A'X='0AX:TN3270'
'0B'X='0BX:TN3270=DR'
'0C'X='0CX:TN3270E'
'0D'X='0DX:TN3270E=DR'
(plus a new, undocumented '0007'x value was found once.)
-Jan 17: Logic for LSCDIPPN was corrected, and above 0A-0D
values were added to MG028ST format.
Thanks to Michael H. Thompson, IBM Global Services, USA.
Thanks to Vernon Kelly, IBM Global Services, USA.
Change 20.315 -Support for Velocity Software's ESAMON VM Monitor 3.2 and
EXXAMSTO 3.1 with both YY and YYYY year formats in either release.
EXXAMSTO Restructured CPU, SYS, DEV, and USR records are supported
EXXAMEP1 new fields added to some segments and existing datasets,
EXXAMEP2 and new datasets created for these repeated segments:
EXXAMEP3 SEGMENT DDDDDD DATASET
EXXAMSYC SYTEP1 XAMEP1 XMXAMEP1 EP1
EXXAMVDK SYTEP1 XAMEP1 XMXAMEP2 EP2
IMACXAM SYTEP3 XAMEP3 XMXAMEP3 EP3
VMACXAM SYTCPM XAMSYC XMXAMCPM CHANNEL PATH
VMXGINIT STOVDK XAMVDK XAMSTVDK STO VDK
Jan 12, 2003 SHRSTO XAMSTO XMXAMSTO SHARED DCSS/NCS
Feb 6, 2003 -Support for the TCP file, with IBM TCPIP Monitor records,
and HST and UCD segments for Linux, NT, and HP servers is
nearly ready; contact support@mxg.com for that update.
-The USER data segments SFSAPL and MTSAPL will be decoded
only when someone wants to use that data; I previously
have decoded it from the MONWRITE output, but want a body
to make it worth my while to reuse the old code.
-Support for the default YY date format, or the optional
(if you set XAM PARM Y2K=ON in localesa.write file) YYYY.
Thanks to Tony Curry, BMC Software, USA.
Thanks to Tom White, SPRINT, USA.
Change 20.314 Enhancements to process unix sar command output increase
UNIXSAR the size of some fields that were too short.
Jan 11, 2003
Thanks to Uriel Carrasquilla, NCCI, USA.
Change 20.313 Example graphs of MQ Series SMF116 data; CPU by Region,
ANAL116 Elapsed time by Region, Bytes Get/Put, etc.
Jan 11, 2003
Thanks to Amanda Sumner, Royal Bank of Scotland, SCOTLAND.
Change 20.312 JCL examples to create ASUMUOW using Views or using the
JCLUOWP Batch Pipes product did not create the TIMESTMP variable,
JCLUOWV which caused errors that are corrected by this change,
Jan 11, 2003 which also bypasses and additional pass of both data.
Thanks to Larry Nova, TransAmerica Distribution Finance, USA.
Change 20.311 Utility to create tailored BUILDPDB jobs has new argument
UTILBLDP EXPDBOUT= that lets you insert additional code. The need
Jan 11, 2003 was to copy the TYPE6 dataset to the PDB library, so that
use would be to use the new argument in your UTILBLDP:
EXPDBOUT= DATA PDB.TYPE6;SET WORK.TYPE6; ,
or similar code to copy the dataset in that exit.
It would be wiser to use the _STY6 macro to PROC SORT the
dataset to the PDB library, since that will remove any
duplicate type 6 SMF records, but that macro will also
delete the TYPE6 dataset from the //WORK file, which will
cause BUILDPDB to fail when it tries to build PDB.PRINT
from WORK.TYPE6. If you use this logic:
EXPDBOUT= _STY6 ;
DATA TYPE6 (SORTEDBY= _BTY6); SET PDB.TYPE6; ,
the _STY6 will sort and remove duplicates, and WORK.TYPE6
will be created, marked as sorted, so that the later PROC
SORT in BUILDPDB will be bypassed.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 20.310 Transparent redesign of processing of TYPETMNT/TYPETALO
BUILD005 in BUILDPDB was needed for the planned TAPEVENT program,
BUIL3005 which is still in development, but needed these changes:
VMAC30 -VMAC30 adds subtypes 2/3 interval tape DDs to TYPE30TD
Jan 6, 2003 dataset, and variables SUBTYPE INTBTIME INTETIME and
Jan 17, 2003 DDNAME are now kept in TYPE30TD. Subtype 4s are needed
by BUILDPDB now, and the 2/3s will be used later.
-BUILDPDB's now selects only subtype 4's in its PROC SORT
of dataset TYPE30TD, as the existing logic expects.
Change 20.309 Support for SYNCSORT for z/OS 1.1 User SMF (COMPAT).
VMACSYNC Five new variables are added, and two two-byte block
Jan 6, 2003 size of sortin and sortout are replaced by four-byte
fields, using the existing +36 bytes at end of record.
A new one byte SYNCHDB2 flag and reserved byte are input,
replacing variable NRWRKUSE, Number of Work Units Used,
which will now be missing with the new version. And the
new SYNCLVL value is 1.1 for this version, the previous
version was 3.7, making for less than elegant logic!
Thanks to Chuck Hopf, MBNA, USA.
Change 20.308 Variable ATTRQUAL was changed from LENGTH $8 to $24, as
VMACSOLN it can be longer than the original 8 byte length.
Jan 6, 2003
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
=======Changes thru 20.307 were in MXG 20.10 dated Jan 03, 2003=========
Change 20.307 Change 20.274 (OW56739) was flawed, causing INVALID DATA
VMAC7072 FOR CPUHPTTM, EXETTM .. messages, and creating invalid
Jan 2, 2003 values in some observations in TYPE72GO dataset (only for
periods 2 and higher, and only if LENSCS was GE 488). The
code after IF LENSCS GE 488 THEN DO; should have INPUT
only R723PLSC field. Change 20.274 erroneously had four
additional fields that had been copied from earlier code.
Thanks to David Klein, City of New York, USA.
Change 20.306 Change 20.138 caused almost no observations in CIMSDBDS
VMACCIMS dataset; the correct test for output should have been:
Jan 2, 2003 IF NOT (DBORG EQ '00'X AND FLGOVERF EQ '00'X ) THEN DO;
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 20.305 Support for NetSpy Version 6.0 new subtypes 'G' and 'H'
EXNSPYIN create new datasets:
EXNSPYUD DATASET DDDDDD Subtype Description
IMACNSPY NSPYUDP NSPYUD G UDP Connections
VMACNSPY NSPYINTR NSPYIN H Interface
VMXGINIT However, the "H" Interface records are invalid, with only
Jan 2, 2003 76 bytes in each segment (while 176 is documented and is
the length field in these bad records). MXG will detect
and delete the invalid records, printing a note on the
SAS log. A problem will be opened with CA Support.
Thanks to Chris Selley, Zurich Finaincial Services, ENGLAND.
Change 20.304 Support for IDMS V1500 new subtypes 13, 14, and 15 create
EXIDMXLI new datasets:
EXIDMXLK DATASET DDDDDD Description
EXIDMXMS IDMSXLI IDMXLI DSG XESLOCK WAIT
IMACIDMS IDMSXLK IDMXLK DSG XESLIST WAIT
VMACIDMS IDMSXMS IDMXMS DSG XCFMSG WAIT
VMXGINIT
Dec 30, 2002
Thanks to Gilles St-Amand, DGSIG, Province of Quebec, CANADA
Change 20.303 This utility constructs DB2 GTF trace segmented records
UDB2GTF into legitimate variable length records, but printed the
UDB2GTFA "LOST EVENT" messages on the log.
Dec 30, 2002 -Member UDB2GTF only works on EBCDIC SAS (z/OS, etc).
-The new UDB2GTFA member works on ASCII SAS, if that's
where your DB2 trace records are downloaded.
Thanks to Ron Alterman, PGE, USA.
Change 20.302 Mostly cosmetic.
ANALUAFF -ANALUAFF (Unit Affinity Candidates analysis) needed an
ANALSRVC end comment in line 6.
Dec 30, 2002 -ANALSRVC replaced "compiler fakers" with ARRAYs statement
to initialize variables.
Thanks to Bruce Widlund, Merrill Consultants, USA
Change 20.301 This archaic member was replaced by VMXGTIME, but it had
VMXGGMT typo's corrected and comments updated to steer you to use
Dec 29, 2002 the VMXGTIME to convert timestamps between time zones.
Thanks to David Klein, DOITT - City of New York, USA.
Change 20.300 SAS Version 9 has tightened syntax validation, and found
VMACLMS these MXG syntax violations that were tolerated by V8.2:
VMACNTSM -VMACNTSM variable DUMMYFLD was LENGTH $32 but was also in
Dec 23, 2002 (incorrectly) INFORMAT 16.2 - error raised on the 16.2.
-VMACLMS had two instances of ELSE ELSE corrected.
-Many NOTES: 49-169 The meaning of an identifier .... that
won't go away until there's a V9 maintenance release.
=======Changes thru 20.299 were in MXG 20.09 dated Dec 20, 2002=========
Change 20.299 -Member ANALALL, which selects and prints all SMF records
ANALALL for a job is enhanced to include all user SMF records,
Dec 20, 2002 and some new SMF records added since it was last updated,
and the printing is now done with the %VMXGPRAL utility.
-Member VMACHSM now include member IMACJBCK, which is the
member that permits selection of SMF job-related records.
Thanks to Ronald Lundy, AHOLD, USA.
Change 20.298 The macro override in the MACKEEP= for LDCOVOL had the
DAILYDSN dataset name spelled wrong; the statement should be:
Dec 18, 2002 MACRO _LDCOVOL DATASETS.DCOLVOLS %
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.297 This enhancement adds SYSTEM and SYSPLEX to the criteria
VMXGRMFI that can be used to define RMFINTRV's workloads.
Dec 18, 2002 If you have the same SRVCLASS name on different systems
that have different meanings in your workload terms, you
can use the new positional arguments to differentiate.
(The old IMACWORK gave you access to write code for this,
but it is limited to only 15 workloads.)
Two new sections are added to the WORKx= macro arguments
(that you would tailor in the VMXGRMFI invocation in your
RMFINTRV member in your USERID.SOURCLIB).
The syntax to defina a workload now is:
WORKx=varname/label/pgn(s)/srvclass(s)/periods/system(s)/sysplex(s)
-varname is used as the first 4 characters of the name of
your workload variables
-label is the first line of the workload variable labels
-pgn(s) is a list of one or more performance group numbers
to sum into this workload (COMPAT MODE only).
-srvclass(s) is a list of one or more service or reporting
classes to sum into this workload (GOAL MODE only).
-periods is the number of periods in the workload
-system(s) is a list of one or more systems whose srvclass
or pgn will be summed into this workload.
-sysplex(s) is a list of one or more sysplexes whose pgn
or srvclass will be summed into this workload.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.296 New macro variables &TRNDIN and &TRNDOUT are defined in
VMXGINIT VMXGINIT and initialized to "TREND", so that the input
Dec 18, 2002 and output TREND libraries can be different. Originally,
I backed up the trend library and then updated in place,
but for restartability products, input and output must
be different. These macro variables can be %LET to your
different DDnames, and your Trend library can be a GDG.
Only TRND23 (Change 20.239) has been updated to use these
macros, but all of the MXG TRNDxxxx members will have
this enhancement.
Macro LSU23 was defined and set to PDB for TRND23.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.295 Investigation of CPU times in AS/400 datasets is enhanced
VMACQACS by new _400CPU and _400PRN macros to summarize and merge
Dec 18, 2002 all of the variables containing CPU time from QACSJOBL,
QACSSYSL, and QACSSYST into new dataset QACSCPU that
includes these CPU-related variables from these datasets:
QACSJOBL: JBCPU JBTCPU JBEDBC
QACSSYSL: SCIFUS SCIFTE SYSSWC
JSCPUTOT (sum of JS/3/1/b/c/d/e/i/m/p/s/CPU)
SCPUSTOT (sum of SCPU01-SCPU32)
NRCPUS (count of nonzero SCPUnn)
PCTCPUBY 100*SCPUSTOT/(NRCPUS*INTSEC)
QACSSYST: SHCPU
(the data in QACSSYSC is a subset of QACSSYSL).
Examination of these CPU times shows that the total CPU
time in SCPUSTOT is very close to JSCPUTOT+SHCPU.
Note that the old calculation of PCTCPUBY in QAPMSYS used
variable SHCPU, but this revision uses the total hardware
busy time (SCPUSTOT, the sum of SCPU01-SCPU32), as it is
clear that SHCPU is nothing close to the total CPU used.
To create the QACSCPU dataset, add _400CPU after you
have built the above datasets in the work file. To then
print the comparison, add _400PRN after the _400CPU
macro invocation.
Cosmetic: MXG 20.08 debug PUTs with COL=17 GDES=XX were
removed.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Thanks to John Gebert, Office Depot, USA.
Change 20.294 VTS activity reports enhanced and updated. A new
ANAL94 selection parameter, SUBREP= to select desired report:
Dec 17, 2002 ALL, PHY, VIR, TAP.
Dec 30, 2002 Dec 30: cosmetic: "compiler fakers" replaced with RETAIN.
Thanks to Wally Danielson, Airborne, USA.
Change 20.293 CICS Stats "UNKNOWN STID=nnn" messages are printed by MXG
VMAC110 to alert us both that IBM has added a new statistics STID
Dec 17, 2002 segment to the SMF 110 subtype 2 record, one that is not
yet supported by MXG, so that I can begin the process of
finding the documentation from IBM and updating MXG for
that new STID. But when the "UNKNOWN STID=115" message
was printed, it took several iterations of customer's
system programmers time to report the problem and send a
record dump, and hours here trying to find documentation
that doesn't exist, and then reinvolvement of the site's
CICS staff to open a PMR with IBM, and then IBM CICS
support technicians time to finally document that:
The STID=115 for Enterprise Java Beans (DFHEJBDS) was
produced by early levels of CICS/TS 2.1 code but then
withdrawn, with the external mappings and documentation
removed, so these records should not be produced by the
currently supported IBM CICS code. (If you are still
getting these records on CICS TS 2.2, you need to raise
a PMR with your CICS support centre.)
This record type may be reinstated in a future release.
This change in VMAC110 bypasses the UNKNOWN STID= message
for STID=115, and documents the STID number!
02Jan03: APAR PQ69408 was opened 24DEC02.
Thanks to Chris Selley, Zurich Financial Services, ENGLAND.
Thanks to Tony Hurlston, Zurich Financial Services, ENGLAND.
Change 20.292 SAS Technical Support provided updated mapping of SAS SMF
ADOCSASU User record's Procedure Names to the SAS Product Name, so
FORMATS the $MGSASPR format was updated with new procedure names,
Dec 16, 2002 and the table in member ADOCSASU was revised.
Thanks to Tom White, SPRINT, USA.
Change 20.291 Support for APAR OW57121 which documents many new SMF 99
FORMATS Trace Code values; format MG099TC was updated.
Dec 16, 2002
Change 20.290 The Management Class Name variable DMCNAME is padded with
VMACDCOL hex zeros, which are now converted to blanks.
Dec 11, 2002
Thanks to Dave Gibney, Washington State University, USA.
Change 20.289 Support for the Workload Manager's WLM Definitions PDS.
REXXWLM The REXX exec contributed by this user will read the WLM
Dec 11, 2002 PDS to extract the names of tables, keys, and variable
names, and the exec then generates the SAS code to read
the PDS to create a SAS dataset for each WLM table.
Thanks to Sam Bass, McLane Company, USA.
Change 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data:
VMAC115 -SMF 115 Subtype 2 MQMMSGDM Data Set new vars:
VMAC116 QISTDLMM='DELETE*MARKED*MESSAGE*REQUESTS'
Dec 9, 2002 QISTENUM='ENUMERATE*SELECT*REQUESTS'
QISTGETB='GETS THAT*GOT MESSAGE*FROM BP'
QISTGETD='GETS THAT*GOT MESSAGE*OFF DISK'
QISTLOMM='LOCK*MARKED*MESSAGE*REQUESTS'
QISTMBLR='RELEASE*BROWSE*LOCK*REQUESTS'
QISTMCNT='MESSAGE*COUNT*REQUESTS'
QISTRABP='READ*AHEADS*FROM*BUFFER*POOL'
QISTRAIO='READ*AHEADS*DOING*I/O'
QLSTGETL='GET*LOCK*REQUESTS'
QLSTHLDL='TIMES*REQUESTED*LOCK*HELD'
QLSTRELL='RELEASE*LOCK*REQUESTS'
And all of the QSST fields that exist in DB2ACCT:
QSSTABND QSSTCONF QSSTCONT QSSTCONV QSSTCRIT QSSTEXPF
QSSTEXPV QSSTFPLF QSSTFPLV QSSTFREF QSSTFREM QSSTFREV
QSSTGETM QSSTGPLF QSSTGPLV QSSTRCNZ
-SMF 116 MQMACCTQ Data Set new vars:
QWHSRN =' RELEASE*INDICATOR'
QWHSACE ='ACE*ADDRESS'
QWHSSTCK='STORE*CLOCK*VALUE OF*HEADER'
QWHSISEQ='SEQUENCE*NUMBER*FOR*IFCID'
QWHSWSEQ='SEQUENCE*NUMBER*FOR*DESTINATION'
QWHSMTN ='ACTIVE*TRACE*NUMBER*MASK'
WQGETPMS='PERSISTENT*GOT BY*MQGET'
WQPUTPMS='PERSISTENT*GOT BY*MQPUT'
WQPUT1PM='PERSISTENT*GOT BY*MQPUT1'
Change 20.287 PROC DELETE DATA=_Wdddddd; syntax for four z/VM datasets
VMACVMXA were overlooked and are now %VMXGDEL(DDDDDD=dddddd); as
Dec 9, 2002 they should have been. The %VMXGDEL is used only for
datasets that are directly sorted from _W to _Ldddddd,
and prevents deletion when _W is equal to _L dataset.
Thanks to Chris Weston, SAS Institute ITRM, USA
Change 20.286 -Three SMS objects were revised to contain Instance Names;
EXNTSQBP variables SMEXNAME in SMSEXTHR, SMIMNAME in SMSINMEM and
VMACNTSM SMSENAME in dataset SMSSENDR are now supported.
Dec 8, 2002 -Dataset SQLBUFMG has new fields and fields deleted.
-New SQLSERVER:Buffer Partition Object supported.
-INPUT STATEMENT EXCEEDED INPUT with MSExchangeIS object
if it had NRDATA=49; MXG logic corrected.
-Antigen Scan object with only NRDATA=12 supported.
Thanks to Jim Quigley, ConEd, USA.
Change 20.285 Using the _NTIMS macro to tailor Landmark IMS processing
VMACTIMS failed; each line of that MACRO definition was missing
Dec 8, 2002 the work MACRO at the start of each line.
Thanks to Michael Gresham, JCPenny, USA.
Change 20.284 Cosmetic cleanup of first MXG 20.08 only:
VMAC119 VMAC119: PUT at line 1794 was deleted.
VMAC110 VMAC110: PUT at line xxxx was deleted.
VMACNTSM VMACNTSM: Labels for DAPASTRT, DBPAFLRT missing quote.
Dec 8, 2002
Change 20.283 SMF 94 Subtype 2 SMF94SOF/SLN/SON triplet is nonstandard,
VMAC94 so it cannot be used to determine how many pool segments
Dec 5, 2002 need to be output to TYPE942P. SMF94SON should be the
Jan 2, 2002 number of repeated segments, but is always 1. SMF94SLN
should be the length of a segment, but it is 1792, the
total length of all 16 possible pools, even when fewer
pools are used. MXG initially used SON, outputting only
the first pool, but the test site knew they had defined
two pools. Their SMF records had an (undocumented) field
S94PPP='...0....'B in the first 2 segments, and had
S94PPP='...1....'B in the other 14 segments, so that test
was added to VMAC94, to only output if that bit was zero,
while awaiting this answer from IBM:
"We consider all pools to be defined, they just may not
be in current use. Other than assuming that a pool
with no logical volumes in it is 'not defined', there
is no way to make that determination. The bits of
SMF94PPP are now described, but they will not help in
determining which pools are defined."
So the heuristic test was removed, and MXG now always
outputs all 16 pool segments to TYPE942P dataset.
These new variables are created from that S94PPP field:
S94PPPRA='RETURNS*ALLOWED?'
Bit 0:
"Y" if borrowed volumes are to be returned to
the common scratch pool when scratched; blank
if borrowed volumes remain in the pool that
borrowed them when scratched.
S94PPPFM='FIRST*MEDIA*TYPE*TO BORROW'
Bits 2-4 converted to a decimal value.
First media type to borrow, if additional
physical scratch volumes are needed by the
pool.
S94PPPSM='SECOND*MEDIA*TYPE*TO BORROW'
Bits 5-7 converted to a decimal value.
Second media type to borrow, if additional
physical scratch volumes are needed by the
pool, and none of the first media type are
available.
Both are decoded by MG094PP format:
0 - No Borrowing
1 - Borrowing of Media ID 0 is allowed
2 - Borrowing of Media ID 1 is allowed
3 - Borrowing of Both Media is allowed
Change 20.282 The debugging PUT _N_= STARTCOL= .... statement at line
VMACCTLG 580 was removed.
Dec 5, 2002
Thanks to Len Rugen, University of Missouri, USA.
Change 20.281 SMF 90s from OS/390 V2.9 and z/OS 1.3 have VERSN90 as a
VMAC90A binary field in subtype 30 records, although the z/OS 1.4
VMAC90 SMF manual still shows an EBCDIC number. INVALID DATA
Dec 5, 2002 messages were printed, but no impact, as VERSN90 is not
Dec 11, 2002 used. Revised code inputs VERSN90 ?? &NUM.2. and then
tests for missing to re-INPUT as &PIB.2. Subtype 6 have
VERSN90='0002'x, subtype 6s have 'F0F1'x, or EBCDIC 1.
Note: USE TYPE90A, the old TYPE90 was replaced by TYPE90A
and this fix was extended to TYPE90 just for protection.
I have opened a documentation issue with IBM.
Thanks to Peter Webber, Co-operative Insurance Society Limited, UK.
=======Changes thru 20.280 were in MXG 20.08 dated Dec 4, 2002=========
Change 20.280 MXG-constructed variable PLAN in DB2ACCT was incorrect in
VMACDB2 Distributed/Remote records (QWHCATYP=7,8); the statement
Dec 4, 2002 in the DO group for those attachments was changed from
PLAN=SCAN(QWHCCV,1,' .'); to PLAN=SCAN(QWHCPLAN,1,' .');.
Thanks to Warren E. Waid, JCPenney, USA.
Change 20.279 The Local IP address TCBINDIP in TYP119A7 dataset was not
VMAC119 correctly stored; the statement to compress TCBINDIP must
Dec 4, 2002 be: TCBINDIP=COMPRESS(TCBINDIP);
but MXG code had .... TCBINDIC .. causing the error.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 20.278 The %UPCASE(&SASSWORK) and %UPCASE(&USERWORK) added by
VMXGINIT Change 19.295 were lost, probably by Change 20.019. When
Dec 3, 2002 ITSV set USER=work (lowercase), their absence caused the
VMXGDEL to delete dataset work.ANYTHING because it was
different from dataset WORK.ANYTHING. %UPCASEs restored.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 20.277 RMF Channel Activity Report enhanced with two selection
ANALRMFR parmaters, CHP= to select desired CHPID values, and
Dec 3, 2002 CACR= to selected SMF73ACR channel types.
Thanks to Don Isenstadt, Parker Hannifin Corporation, USA.
Change 20.276 Support for numerous NTSMF new objects and new data:
VMACNTSM -Support for MS Exchange 2000 SP3 changes:
VMXGINIT -DATABASE: Variables renamed:
EXNTxxxx TOCAPCHT==>CACHTOHT
Dec 3, 2002 TOCAHIRT==>CACHTORT
TOCAMIRT==>CACHTOMI
Variables removed:
TOOPENRT LGTHWAIT FIOPPEND FIOPRATE LGWRITRT LGRESTRT
CACHSTAL
Variables added:
DBPAFLRT DAPAEVRT DAPASTRT DBCASIZE
-DATABASE ==> INSTANCES: Variables renamed:
TOCAPCHT==>CACHTOHT
TOCAHIRT==>CACHTORT
TOCAMIRT==>CACHTOMI
Variables removed:
CACHFALT CACHSIZE FIBYWRRT FIBYRDRT TOOPENRT FIOPPEND
FIOPRATE LGWRITRT LGRESTRT CACHSTAL
-MSEXCHANGEDSACCESS CACHES: New variables:
CAEXPIRX CAINSRRX TOTENTRX DNENTRX SEAENTRX NDNENTR
NGUENTRX TOTENTMX DNENTMX SEAENTMX NDNENTMX NDUENTM
CAEXPITX CAINSRTX
-MSEXCHANGEIMAP4: New variables:
INVALICR CONNFAIL CONNREJE
-MSEXCHANGEPOP3: New variable:
INVALICR
-MSEXCHANGEIS: New variables:
RPCAVLAT RPCSLOPK
-Support for XP Professional:
-PROCESSOR: New Variables
PCTIDLTM PCTC1TM PCTC2TM PCTC3TM TRNSC1RT TRNSC2RT
TRNSC3RT
-Two new XP Professional Objects supported:
dddddd Dataset Object
NTPSFL PSCHFLOW PSCHED FLOW
NTWMIO WMIOBJCT WMI OBJECTS
-Support for MQSERIES QUEUES: New Instance variable
MSMQINST added.
-Support for new objects: Antigen Scan, Citrix, MSMQ,
and Data Core:
dddddd Dataset Object
NTANGN ANTIGENS ANTIGEN SCAN
NTCIIN CITRIXIN CITRIX IMA NETWORKING
NTCIMF CITRIXMF CITRIX METAFRAME XP
NTDCCA DACOCACH DATACORE CACHE
NTDCDC DACODOMC DATACORE DOMAIN CONTROLLER
NTDCFC DACOFIBC DATACORE FIBRE CHANNEL
NTDCMI DACOMIRR DATACORE MIRRORING
NTDCND DACOSCHD DATACORE SCHEDULING
NTDCNP DACONMVP DATACORE NMV POOLS
NTDCSC DACONMVD DATACORE NMV DISKS
NTMQMQ MSMQUEUE MSMQ QUEUE
NTMQMS MSMQSRVC MSMQ SERVICE
Change 20.275 HSM new variables added to dataset HSMDSRDS:
VMACHSM DSRDRECN='DATA SETS*RECONNECTED'
Dec 2, 2002 DSRBRECN='TRACKS*RECONNECTED*TO TAPE'
DSREXRED='EXTENT*REDUCTIONS'
DSRABACK='ABACKUPS*REQUESTED'
DSRABAKF='ABACKS*FAILED'
DSRABXTR='EXTRA*MOUNTS*RECALL*TAKEAWAY'
HSM now has the ability to "Reconnect" the MCDS record
when migrating a dataset that had been recalled; the
update-bit is tested, and if the dataset was not changed,
HSM "Reconnect"s that MCDS record to the migrated copy
on tape, updates the catalog to MIGRATE, and avoids any
movement of data to tape, counting the tracks that were
not moved to tape!
-There are 13 function types, not 12, so the DO loop was
increased to read all 13 array elements.
Thanks to Frank Cortell, Credit Suisse First Boston, USA.
Change 20.274 Support for RMF APAR OW56739. For RMF 79 subtype 3, adds
VMAC79 4-byte fields at the end of the segment (i.e. COMPATIBLY)
VMAC7072 to replace the existing and now-overflowing 2-byte frame
Dec 2, 2002 count variables. For RMF 72 subtype 3, TYPE72GO dataset,
adds new variable R723PLSC, with the period-level service
class name, which is now used in RMF reports to flag as
'HETEROGENEOUS' if R723PLSC is not identical to R723CLSC
for a certain period across the sysplex.
See Change 20.306 - correction.
Change 20.273 Workload Graph examples now include plots of MSU used by
GRAFWRKX each workload.
Nov 27, 2002
Thanks to Chuck Hopf, MBNA, USA.
Change 20.272 MSU variables that were zero in ASUM70PR/ASUMCEC from old
VMAC7072 S390 data with SMF70CPA=0 are now populated by using the
Nov 26, 2002 CPUTYPE/CPUMODEL variables and the $MG070CP table lookup
to get and store the CECSUSEC value back into SMF70CPA in
the TYPE70PR dataset; the non-zero SMF70CPA is then used
to calculate the MSU values in ASUM70PR/ASUMCEC.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 20.271 -VMAC108: DOMPVN now labeled.
several -VMAC42: S42JDDSO now labeled.
Nov 26, 2002 -VMAC60: VVROPIND SMF60FNC VVRAMAT3 VVRTPEXT now labeled.
-VMACTPF: TPFRECNR, GMTOFF, SYSTEM are now labeled, and
temporary variable MZHDVAL is no longer kept.
-VMAC73: SMF73BSY now labeled.
Thanks to Chris Weston, SAS ITRM, USA.
Change 20.270 Enhancement for DB2 Trace IFCIDs 202, 230, and 239; those
READDB2 IFCID values are not SMF 102 subtypes, but are SMF 100
Nov 26, 2002 subtype 2 and 3, and SMF 101 subtype 1. READDB2 will now
create DB2STAT2 (202), DB2GBPAT (230) or DB2ACCTP (239)
datasets when those IFCIDs were requested in your READDB2
invocation.
Thanks to ???, ???, USA.
Change 20.269 Change 20.221 for ASUMUOW created variable TIMESTMP and
JCLUOWP changed the sort order of _SUOWCIC, but the JCL examples
JCLUOWV to use Views (JCLUOWV) or to use Pipes (JCUUOWP) were not
Nov 26, 2002 updated with the revised _SUOWCIC definition, causing the
VARIABLE TIMESTMP NOT FOUND error.
Thanks to Larry Nova, TransAmerica, USA.
Change 20.268 Cosmetic. Syntax of M4=-4; INPUT +M4 ... was replaced
DOC by INPUT +(-4) ... and the Assignment or RETAIN statement
Nov 25, 2002 for variables M1, M2, M4 ... were deleted. There is no
need to create/retain the negative valued variable to
move backwards in an INPUT statement.
Change 20.267 -Type 119 subtype 5 TYP11905 variable TSIPMAXS was not
VMAC119 input, causing the following 8 TSIPxxxx variables to be
Nov 23, 2002 wrong, and the label for TSIPCURS was changed to CURRENT.
-Type 119 subtype 2 TYP11902 variable TTSTATUS was 0 or
16777216 when it should have been 0 or 1; documented as
length 4, it's actually only length 1. Variable TTTOS is
only PIB1, TTXRT is PIB2, and TTINSEG and TTOUSEG are
both PIB8 instead of PIB4; IBM's originaly documentation
was corrected by the z/OS 1.3 online manual.
Thanks to Mark Cohen, DTS, ITALY.
Change 20.266 Most EXdddddd "Data Set Exit" members have one executable
EXDB2ACC statement, OUTPUT _Wdddddd or IF ... THEN OUTPUT ....
EXTY39 which permits instream tailoring syntax that will execute
EXNSPYAP the existing EXdddddd member's statement:
EXIMRACF %LET MACKEEP=
EXDB2ACP %QUOTE(
EXDB2ACB MACRO _EDB2ACC
EXCICJRN IF (your-new-selection-logic-is-true)
EXARBnnn THEN %%%INCLUDE SOURCLIB(EXDB2ACC); %%
Nov 20, 2002 );
However, that logic failed with EXDB2ACC, one of the few
exit members that has more than one executable statement:
IF something THEN DELETE; OUTPUT _WDB2ACC;
DB2 Parallel duplicate must be deleted by MXG, but IBM
techies using MXG inside DB2 Development needed to see
those records, so the normal DELETE was externalized.
Note: That DELETE was removed by Change 22.121.
a. The DELETE statement should not normally be used in
dataset exits, as it deletes the entire record; if
the record has repeated segments, a DELETE will stop
MXG from seeing the rest of that record's segments.
But by adding a DO; END; pair in the exit member code:
DO;
IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;
OUTPUT _WDB2ACC; /* DB2ACCT, DEFINED IN IMACDB2 */
END;
there is only one executable statement, so the preceding
logic IF ... THEN %INCLUDE SOURCLIB(EX...) works.
All exit members were examined, and those with more than
one executable statement were wrapped in a DO; END; pair.
HOWEVER: The actual MXG recommended syntax for tailoring
in exit members when overriding the _Edddddd macro, as
shown in examples in member DOCMXG, show that I expected
that YOU would put the DO; ... END; pair in your logic:
%LET MACKEEP= %QUOTE(
MACRO _EDB2ACC
IF selection-critera THEN DO;
%%%INCLUDE SOURCLIB(EXDB2ACC);
END;
%%
);
and I still think that syntax is clearer and safer.
But this is still an worthy enhancement, because, now, no
matter which syntax you use to override _Edddddd macros,
either will work, transparently!
Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.
Change 20.265 Undocumented fields added by FC4001 cause new SMF 94 data
VMAC94 (added by Change 20.206, using the text of the IBM PTF!)
Nov 19, 2002 to be wrong. IBM Redbook SG24-2229-05 now lists the 128
Nov 25, 2002 byte field we found at offset 400, but an 8-byte field
Nov 26, 2002 between S94OPM_AVG_VDM at offset 534 and S94OPM_DC1 at
offset 536 is not documented; it was located only by this
user's astute validation, knowing what values to expect.
The validation and -05 document made these corrections:
-S94VPSET is now input as PIB2 instead of 1.
-S94PSVC0-S94PSVC3 are now input as PIB2 instead of 1.
-S94DRIC1-8, S94xxWN1-2, S42ADI, S42DTW are recorded in
megabytes and were too small by a factor of 1048076, and
ADI/DTW were not formatted MGBYTES.
-The *1 or *2 text in many labels that didn't belong was
removed (added by erroneous CHANGE X Y ALL edit command).
-Variable SMF94VLC, the 5-byte alphanumeric Library Serial
"number" is now kept in TYPE942 & TYPE942P datasets, and
SMF94VLC should now be used in place of SMF94SNO in your
reports, as the 12-byte SMF94SNO field does not exist in
subtype 2 records. SMF94SNO was replaced by SMF94VLC in
the sort macros for the TYPE94, TYPE942, and TYPE942P
data sets, for consistency and so they could be matched.
SMF94VLC is created from SMF94SNO in (older) subtype 1
records that still have hex zeros in the VLC field.
SMF94VLC is not documented in the SMF 94 subtype 2
record, but MXG creates it as a five-byte character
variable from the 3-byte hex field that was observed to
contain it in the VPS Message Header field. SMF94VLS
is always missing value in TYPE94 when VLC contains a
character, so SMF94VLS is of no use in reporting.
OBSERVATION COUNT CHANGE: TYPE942 fewer obs.
OBSERVATION COUNT CHANGE: TYPE942P more obs.
Thanks to Wally Danielson, Airborne Express, USA.
Change 20.264 Variable MSEXISPU in MSEXCHPU dataset was increased from
VMACNTSM $32 to $64 to hold names like:
Nov 19, 2002 "First Storage Group-Public Folder Store (ISOMAILP1)"
Thanks to Xiaobo Zhang, Insurance Service Office, USA.
Change 20.263 -Support for BMC MVCICS 5.6 and correction to 5.5 CMRDETL
FORMATS support. New data BMC added to file segments in 5.5 was
VMACMVCI optional, the old (5.4) 16 bytes, or an expanded 92 bytes
Nov 16, 2002 but MXG always expected the new 92 byte length, causing
Nov 19, 2002 INPUT STATEMENT EXCEEDED error if you did not turn on the
new optional longer length records. The MXG test to
INPUT the longer length segment was revised to
IF T6ECPRID EQ 'F4'X AND T6EQUAL EQ '1.......'B THEN
using the new T6EQUAL field added in 5.5 to discriminate.
-In MVCICS 5.6, BMC added segment length into a reserved
field; new variable T6EFENLN is created by this Change.
-And MVCICS 5.6 extends the extended information to DB2,
MQSERIES, and DBCTL so the $MGMVCTI format that decodes
the file type variable, TFILI, was updated to identify
those types of files that were accessed from CICS.
Thanks to Franco Carmignani, IntesaBCI, ITALY.
Change 20.262 Support for APAR xxyyyyy added new RMF 99-1 trace codes
FORMATS for WLM dynamic resource group additional measurements,
Nov 16, 2002 that are now decoded by the MG099TC format.
Change 20.261 Preliminary look at Velocity Software ESAMON V3.2 data.
VMACXAM Updated the header from YY to YYYY; received documenation
Nov 15, 2002 of the current version, but yet to validate and compare.
Text of this change will be updated when changes made.
Change 20.260 Support for AS/400 5.2 Collection Services. INCOMPATIBLE
VMACQACS because you must change the LRECL for the files that IBM
Nov 15, 2002 IBM changed; if you upload 5.2 data with the new LRECL,
these data are readable with prior versions of MXG since
IBM added the new data at the end of the record:
Dataset Variable 5.2 LRECL
QAPMSYSL SYLPTB Added at end 3294
But these data were inserted or increased in length, so
you must have this change and correct LRECLs to read:
Dataset Variable 5.2 LRECL
QAPMETH ETMDIF Length increased 266
QAPMETH ETMUPF Added at end 266
Dataset Variable 5.2 LRECL
QAPMDISK DSASPX was DSAASP now NUM 367
QAPMDISK DSASPN Added at end 367
Thanks to Warren Cravey, Fidelity Systems, USA.
Change 20.259 TYPE71 Medium Impact Frames variables ESFRMEAV/MN/MX were
VMAC71 input out of order (AV had Min, MN had Max, MX had Avg)
Nov 15, 2002 this change also affected ESFRHIAV,ESFRHIMN,ESFRHIMX due
May 12, 2003 to subsequent calculations.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Tony P. Stewart, Royal Mail, ENGLAND.
Change 20.258 -Cosmetic. Labels for variables MCTSSDCN/MCTSSDRL added.
VMAC110 Only if the new UTILEXCL is used to create IMACEXCL, will
Nov 21, 2002 those variables (field count, segment length) exist in
Nov 29, 2002 CICSTRAN, so that you can know which exclude code was in
use to create these observations with excluded fields.
-The debugging PUT statement for STID=82 was removed.
Thanks to Craig Collins, State of Wisconsin DEG, USA.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 20.257 Message VMAC80A.WARN. MORE DTP (44) SEGMENTS UNIMPORTANT
VMAC80A is unimportant, but the for the 10/13 RACFEVENTS, MXG now
Nov 14, 2002 will keep 15 segments (previously kept was 12, this site
had 14) to suppress the warning message.
Thanks to Hersch White, UICI, USA.
Change 20.256 Major enhancement in UTILEXCL redesigns its IMACEXCL.
UTILEXCL Instead of creating a DO-GROUP for each APPLID+SMFPSRVR,
Nov 15, 2002 only the SMFPSRVR (CICS Version), MCTSSDCN (field count)
and MCTSSDRL ("record" length) combination are used to
create a DO-GROUP for each unique record structure, so
you won't have a separate DO-GROUP for each APPLID. And
more important, you won't have to update IMACEXCL every
time you add a new APPLID that clones an existing record
structure. Thus to support a new CICS version (or any
changes in existing EXCLUDED fields), you only need one
dictionary record from a test run to create the IMACEXCL
that will support the new record format for all APPLIDs.
The reporting of UTILEXCL was enhanced. If optional CICS
segments are found in your data, it prints the list of
IMACICxx members whose comment blocks must be removed to
input those optional segments. New reports show which
APPLIDs are in which DO-GROUP, list the non-excluded
dictionary fields for each DOGROUP, and print the text
of the IMACEXCL that was created.
To detect the very unlikely event that your CICS guru
created two exclude lists for the same APPLID that have
exactly the same number of fields and same record length,
but have different fields excluded, UTILEXCL compares the
internal sequence of fields, and will print an ERROR
on its log if that conflict is discovered.
The redesign is inside the _BLDEXCL macro that creates
the IMACEXCL file from PDB.CICSDICT, so you don't need to
re-read SMF dictionary records. You use _BLDEXCL to read
your previously-built PDB.CICSDICT as shown in examples
in the comments in the UTILEXCL member.
This also corrects INPUT STATEMENT EXCEEDED errors with
the previous design caused by multiple dictionaries for
an APPLID+SMFPSRVR that had different DCN/DRL lengths.
The old logic did not handle correctly, and it created an
IMACEXCL that had repeated variables in the INPUT.
When you execute UTILEXCL on MVS to create IMACEXCL, with
SYNCSORT as your host sort, you'll get WARNINGS that the
BY list length is greater than 4092, which is a SYNCSORT
limit, but then SAS recognizes that SYNCSORT failed and
uses the internal SAS sort successfully. One site got a
ERROR: WER723A: CONTACT YOUR SYNCSORT REPRESENTATIVE
message, but I believe that was with SAS Version 6.09.
Using OPTIONS SORTPGM=SAS should circumvent on V6.
Thanks to Kevin Van Houten, Worldcom, USA.
Thanks to Erling Andersen, SMF, DENMARK
Change 20.255 MXG 20.08-20.07, only if VSAM SMF is read with TYPEDB2,
VMACDB2 an INPUT STATEMENT EXCEEDED RECORD LENGTH error occurs;
Nov 12, 2002 the test added by Change 20.202 should have been
ELSE IF TR03OFF GT 0 THEN OFFSMF=TR03OFF;
The original test with TR03OFF GT . THEN was always true
because it is TR03OFF is initialized to zero in RETAIN,
so when VSAM data (with OFFSMF=4) was read, the first 100
record resetn OFFSMF incorrectly to zero.
Thanks to Michael Oujesky, MBNA, USA.
Change 20.254 Invalid SMF ID=100 Subtype=226 record caused STOPOVER.
VMACDB2 The record was in fact not written by DB2, and MXG's code
Nov 12, 2002 recognized the non-standard subtype, but because IBM puts
the actual subtype in QWHSIID, in the DB2 product header,
MXG has to INPUT from @LOC, but did not validate that the
value in LOC was inside the record. The logic now checks
and detects invalid (short) records, printing the first
five on the log, but continuing to process the SMF file.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.253 Support for ASG-Landmark TMON/CICS V2.1 TH01595 (COMPAT).
VMACTMO2 TCB Switch counts and durations were restructured in both
Nov 10, 2002 TA and TI records, adding new count/duration variables:
TAWRDCT/M TIWRDCT/M Ready Queue Wait for Dispatch
TAAWTWRC/T TIIWTWRC/T Ready Queue Wait after Satis
TADSPWRC/T TIIDSWRC/T Ready Queue Wait While Switched
and making TADSPQCN/M and TIIDSQCN/M now reserved = zero.
The new fields were added compatibly and will be skipped
over without error with MXG 20.02 or later (Change 20.072
is required for base V2.1); this change will create and
populate the new variables when found.
Note: the order and location of the fields is a guess, as
the documentation is unclear, and no records with
the new fields have been tested. But since all are
input as binary, no errors in MXG execution will
occur, and I might have guessed luckily.
Thanks to Frank Lund, EDB Teamco AS, NORWAY.
Change 20.252 Support for SAS Version 9 TS M0 Production Release. MVS
CONFIGV9 Benchmarks in Newsletter FORTY-TWO show there is no real
AUTOEXEC change in resources between V8.2 and V9.00; this change
Nov 8, 2002 is not required for V9, but turns on reporting options
Mar 1, 2003 that can help in diagnosing problems with your SAS job.
-In CONFIGV9 (used only for "MVS" execution) SAS options
DLEXCPCOUNT FULLSTATS FULLSTIMER STIMER MEMRPT
are now enabled to print those statistics by default.
MXG's previous override to MSGCASE was removed so that
the SAS default of NOMSGCASE is specified (to circumvent
a SAS error in the DLEXCPCOUNT counts with MSGCASE).
-In AUTOEXEC (used only for "ASCII" execution), FULLSTIMER
was added; it had been removed due to problems way back
in SAS V6 for PCs.
-This change is not required, but has the recommended new
options for SAS Version 9 on MVS-OS/390-z/OS systems.
-SEQENGINE=V6SEQ is still required; see Change 20.150.
Change 20.251 Change 20.221 to VMXGUOW causes ASUMUOWT to fail; the new
VMXGUOW variable TIMESTMP was added by that change only to the
Nov 7, 2002 code used when CICSTRAN was input, and was not added to
the separate macro used when MONITASK data is input.
Thanks to Terry Warnke, CUNA Mutual, USA.
Change 20.250 -Enhancement for Tandem G07 and later creates new datasets
EXTANDIF TANDISKO (Disk Open) and TANDISKF (Disk File) from those
EXTANDIO same filenames. If you do not have a tailored TYPETAND
IMACTAND or TYPSTAND member, you will need to add //TANDISKO and
TYPETAND //TANDISKF DD DUMMY, as the default MXG member TYPETAND
TYPSTAND member always looks to read all possible Tandem files.
VMACTAND -MXG code for TANDPROC G06 record expected 42 bytes of the
VMXGINIT variables MSGSQTIM thru RPLCBYTE, but documentation shows
Nov 6, 2002 only a 16 byte reserved field added by G05, and I can't
Nov 25, 2002 find documentation that caused me to add those fields, so
their input is made conditional to eliminate STOPOVER.
In addition, the divide by DURATM was relocated until
after all fields have been input, and PER SEC was added
to several rate variables' label.
Thanks to Erling Andersen, SMF Data A/S, DENMARK.
Change 20.249 Enhancement adds TRENDOLD= parameter so you can have your
VMXGRMFI old TREND and new TREND be different datasets, i.e., be
Nov 6, 2002 part of a GDG, so the Trend Job is recoverable by CA-11.
Previously, the TREND parm was used for both the old and
the new Trend Library, and that is unchanged unless you
actually use the TRENDOLD= parameter in your VMXGRMFI.
Also, the disfunctional NORM70= (obviously had never been
used) was corrected to work as designed.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.248 Variables HU47BJOB and HU47BSTP were input and kept in
VMACHURN dataset HURN47, and variables HU49BJOB/HU49BSTP added to
Nov 6, 2002 dataset HURN49.
Thanks to Deborah Churchyard, IBM Global Services, AUSTRALIA.
Thanks to Roger Stenlake, TELSTRA, AUSTRALIA.
Change 20.247 ASUMUOWT stopped working in MXG 20.03-20.07; the _SUOWTMO
VMXGUOW macro definition that was in VMXGUOW in 20.02 when 20.038
Nov 6, 2002 was tested was somehow deleted in the VMXGUOW in 20.03.
Thanks to Terry Warnke, CUNA Mutual, USA.
Change 20.246 Two STG THLD titles were corrected and TOTEFS is now
ANAL88 spelled correctly as TOTALs in headings of this report
Nov 6, 2002 example for SMF 88 System Logger data.
Thanks to Fred Mathew, Nordstrom, USA.
Change 20.245A Internal note. MXG's PROCSRCE program is used to create
PROCSRCE the IEBUPDTE-format sequential file from the MXG Source
Nov 6, 2002 directory, and it is part of MXG QA, checking line length
and for unexpected ./ characters inside those files. It
now also checks for 'E3'x and 'FC'x in my ASCII source,
as they should have been ] '5D'x and u '75'x.
Change 20.245 MACRO _THRDHST should have had INFILE THRDHIST instead of
TYPSTHST SMF, which was left over from testing, and wasn't caught
Nov 5, 2002 in QA because there was an //SMF file allocated.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
=======Changes thru 20.244 were in MXG 20.07 dated Nov 4, 2002=========
Change 20.244 A second instance of DSNLABEL= in TRNDCEC caused ERROR:
TRNDCEC THE KEYWORD PARAMETER DSNLABEL PASSED TO MACRO VMXGSUM
TRNDHSM WAS GIVEN A VALUE TWICE. The second instance was
Nov 4, 2002 removed, and a similar error prevented in TRNDHSM.
Thanks to Mike Kynch, International Paper, USA.
Change 20.243 Cosmetic, in seldom-used TYPE40 (last updated in 1995).
VMAC40 If TYPE40 is executed alone, SAS prints notes that
Nov 3, 2002 VARIABLE ABEND, CONDCODE IS UNINITIALIZED
because those variables don't exist in SMF 40 (dynamic
deallocate). That note is caused by a PUT statement in
included VMACEXC2 (common code that decodes the TIOT EXCP
counts in SMF 30s and 40s) that prints ABEND and CONDCODE
in an MXGERROR log message if an error is found in EXCPs,
and ABEND/CONDCODE do exist in the type 30s. There is no
impact on the TYPE40 dataset since those two variables
are not kept nor used to create TYPE40.
However, UNINITIALIZED notes often expose errors in logic
or in spelling during alpha testing, so the QA test looks
for those notes during error correction. But even when
the cause is valid, like here, and even though they have
no impact, those notes are eliminated (primarily because
they cause confusion and unnecessary support questions),
by a "compiler faker" statement:
IF charvar=' ' THEN charvar=' ';
IF numrvar=. THEN numrvar=.;
an executable statement, but one that is placed after the
RETURN; statement in VMAC40, they are never actually
executed. Nevertheless, I considered replacing those
executable statements with the RETAIN compiler statement:
RETAIN ABEND ' ' CONDCODE .;
to initialize, define length and char/numr type. However
RETAIN can never be used if the variable is conditionally
INPUT, because values from a prior record would then be
retained and incorrectly output when they were not INPUT.
When I asked Rick Langston about a RETAIN without retain
he pointed out that ARRAY statements could be used:
ARRAY INIC40 $ ABEND (' ');
ARRAY ININ40 CONDCODE (.);
as it initializes without retaining values. The ARRAY
statement must be physically located before the variable
name is used, and a unique token must be used for each
array (some names are restriced, like ENTITY, and the
array name cannot be the same as a variable name in some
other member that can be compiled together, but with the
naming convention INICxxxx and ININxxxx in VMACxxxx, the
compiler faker statements in VMAC40 were replaced by two
ARRAY statements, and I will likely replace others as I
find them in other members.
Thanks to Bruce Widlund, Merrill Consultants, USA
Thanks to Freddie, TXU, USA.
Change 20.242 STK HSC User SMF Subtype 29 (1Dx) caused INPUT STATEMENT
VMACSTC EXCEEDED error; MXG expected +6 at the end of the record
Oct 31, 2002 should have been +4, and STC29MVN is PIB4. and not NUM4.
And that subtype was incorrectly OUTPUT into STCVSM28,
but now those typos are corrected to OUTPUT to STCVSM29.
Thanks to Dwain P. Majak, Blue Cross Blue Shield of Kansas, USA.
Change 20.241 Support for APAR OW55968 replaced 4-byte R744RSST with a
VMAC74 new 8-byte field (R744RSSE) to prevent overflow. When
Oct 29, 2002 the new value exists, it is still stored in R744RSST,
as keeping R744RSSE would be redundant. Also OW55586.
Change 20.240 TYPE73 with SMF73CMG=0 still had missing PCHANBY/PNCHANBY
VMAC73 because the initialization logic was still incorrect and
Oct 29, 2002 had to be relocated, again.
Thanks to Michael L. Kynch, International Paper, USA.
Change 20.239 Trending for TYPE23 dataset (SMF Buffer Usage) was wrong;
TRND23 the include of ASUM23 was incorrect and macro names were
Oct 28, 2002 also corrected.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.238 Documentation. Using TEMP01= with %VMXGSUM can cause
VMXGSUM ERROR: FILE PDB1.MXGSUM1.VIEW IS SEQUENTIAL. THIS TASK
Oct 28, 2002 REQUIRES READING OBSERVATIONS IN A RANDOM ORDER, BUT
THE ENGINE ALLOWS ONLY SEQUENTIAL ACCESS.
Remove the TEMP01=PDB1 argument in your tailored %VMXGSUM
invocation to eliminate this error. MXG Change 19.151
documented the changes in use of the TEMP01/TEMP02/TEMP03
arguments; while you can make TEMP01= work (by changing
your DD or adding a LIBNAME PDB1 V6SEQ; statement), MXG
has recommended that you never use TEMP01, and you use
TEMP02/TEMP03 only for specific large dataset cases, e.g.
when you want to exploit hardware compression.
"MXGSUM1" errors are in an VMXGSUM invocation. When the
message is XXXX.MXGSUM1.VIEW instead WORK.MXGSUM1.VIEW,
it shows that your %VMXGSUM invocation has TEMP01=XXXX.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 20.237 IDMS Performance Monitor for Version 1500 circumvention;
VMACIDMS MXG will skip over unknown sections, rather than failing
Oct 25, 2002 with an INPUT STATEMENT EXCEEDED; new sub-subtype 13, 14
and 15 records are created, but I have no documentation
of those record subtypes, nor of any changes to any of
the existing subtypes (which, while seeming to be still
correct, should be closely examined and validated).
This text will be updated when those sub-subtypes are
requested to be supported by a site with documentation.
Change 20.236 SAS User SMF record variable SASPROD, SAS Product Name,
VMACSASU was decoded with the table look-up, but was neither kept
Oct 25, 2002 nor was the variable labeled.
Thanks to Alfred Holtz, Merck Medco, USA.
Change 20.235 Support for APAR OW54010 adds Large Virtual Memory (above
VMAC78 2 GigaBytes) fields to RMF's Private Area Virtual Storage
Oct 24, 2002 Job-Level Monitor SMF 78 subtype 2, in TYPE78PA dataset:
SHBYHWM ='HWM*BYTES SHARED*ABOVE 2GB'
SHBYMAX ='MAX BYTES*SHARED*ABOVE 2GB'
SHBYMIN ='MIN BYTES*SHARED*ABOVE 2GB'
SHBYNTME='TIME STAMP*OF MIN*SHARED*ABOVE 2GB'
SHBYTOTL='TOTAL*SAMPLES*SHARED*ABOVE 2GB'
SHBYXTME='TIME STAMP*OF NAX*SHARED*ABOVE 2GB'
TOBYHWM ='HWM*BYTES ALLOCATED*ABOVE 2GB'
TOBYMAX ='MAX BYTES*ALLOCATED*ABOVE 2GB'
TOBYMIN ='MIN BYTES*ALLOCATED*ABOVE 2GB'
TOBYNTME='TIME STAMP*OF MIN*ABOVE 2GB'
TOBYTOTL='TOTAL*SAMPLES*ABOVE 2GB'
TOBYXTME='TIME STAMP*OF MAX*ABOVE 2GB'
You must have put JOB name(s) for VSTOR in your ERBRMFxx
to monitor job-level and create 78-2s, and these new data
are present only if the Detail Option was set for VSTOR.
This change is required if you install this APAR; the MXG
code was not prepared to skip over the new data.
Thanks to Brian Currah, Performance Associates, CANADA.
Change 20.234 Support for Candle Omegamon for CICS V520 User SMF record
VMACOMCI was added by adding 'V520' to the IF FOCVER test; visual
Oct 24, 2002 scan of a PROC PRINT of first 20 observations showed no
obvious errors (as would occur if a field was inserted).
Thanks to Art Cuneo, Health Care Services Corporation, USA.
Change 20.233 Fairly obscure tailoring: the KEEP= _PDB30_4 LOCLINFO was
BUILD005 reversed to KEEP = LOCLINFO _PDB30_4 ; so that redefine
BUIL3005 of _PDB30_4 could use DROP= syntax without accidentally
Oct 24, 2002 dropping LOCLINFO; the MXG syntax in KEEP= must have the
old-style macro name last, so that DROP overrides KEEP.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 20.232 Cosmetic. Labels for REGSEXAV/MN/MX are 'REG+SWA PAGES';
VMAC71 the original label mistakenly had 'REG+SQA PAGES'.
Oct 23, 2002
Thanks to Tom Buie, Southern California Edison, USA.
Change 20.231 Support for Control-D "SF2" User SMF record, described by
EXTYCSF2 their CTDSF2 DSECT, for Batch, creates new dataset
IMACCSF2 CTLDSF2, but the data does not exactly match the DSECT:
TYPECSF2 Variable SF2VSMCP, CPU Writing to VSAM, contains data
TYPSCSF2 values that are impossible ('0009CBEF'x, if that field
VMACCSF2 is in milliseconds, as are the preceding four fields);
VMXGINIT that value is greater than the elapsed time. Problem
Oct 22, 2002 will be opened with the vendor and this note updated.
Thanks to Kerstin Jansson, Tietoenator, FINLAND.
Change 20.230 Support for Control-D "POD" User SMF record, described by
EXTYCPOD their CTDPSMF DSECT, for Web-Access creates new dataset
IMACCPOD CTLDPOD, but the record does not agree with the DSECT:
TYPECPOD Variable PODPTMLI (Login Time) is hex zeros with no
TYPSCPOD time nor Julian Date. The next field, PODPCPUT, CPU,
VMACCPOD is '91FD75D4'x in one record, but is '40404040'x in
VMXGINIT two others, and the alignment of the rest of the fields
Oct 22, 2002 are thus in question.
Thanks to Kerstin Jansson, Tietoenator, FINLAND.
Change 20.229 -VMAC94:Variable S94BMPI2 was not in the $MG094MI. FORMAT.
VMAC94 -VMAC120: New WebSphere subtype 7 variables SM120WAF and
VMAC120 SM120WAG labels are Activity Begin and End datetimes.
VMACNTSM The _B120WI had all the SM120aaa variables, but now has
Oct 31, 2002 only these: SM120WIA-SM120WIE and SM120WIQ-SM120WIW.
In all new interval datasets (TYP120JI,TYP120SI,TYP120WI)
the interval duration is kept in variable DURATM. Some
old event datasets still have DURATM as their elapsed
time variable, but new event datasets like TYP120WA will
have elapsed time variable SM120ELP instead of DURATM.
Variable DURATM is kept in both TYP120CC and TYP120CM,
but only subtype=4 records will have non-missing DURATM.
Variable SM120ST is now labeled.
-VMANTSM: Variables EXCHHTEX, EXCHHTI1 and ORDFDATA were
input as $ but also in INFORMAT 16.2, which SAS did not
raise as an error, but SAS/ITSV does! All were removed
from the INFORMAT, and EXCHHTI1 added to $32 length.
The MACRO _BNTMECO still had all variables, from testing;
only the first five variables should have been listed.
-These inconsistencies were uncovered in the QA process by
ITSV/ITRM development while updating their dictionary
with new variables and new datasets from MXG 20.06.
Thanks to Chris Weston, SAS ITRM, USA.
Change 20.228 MXG 19.11-MXG 20.06. DB2 variables QW0022TS and QW0022BT
VMAC102 were wrong, if GMT Offset is non-zero. Change 19.286
Oct 21, 2002 incorrectly added +GMTOFFDB to those variables, but they
are already on the local time zone.
Thanks to Scott McDonall, Southern California Edison, USA.
Change 20.227 INTRNAME, the interface name in NETWINTR dataset, was
VMACNTSM increased from $32 to $64 in length; the original was too
Oct 21, 2002 short for 'Compaq Ethernet_Fast Ethernet Adapter_Module'.
Thanks to Xiaobo Zhang, ISO, USA.
Change 20.226 Documentation example for RACF TYPE80A processing.
VMAC80A The TYPE80A/TYPS80A member should be used for RACF SMF 80
Oct 17, 2002 (and not TYPE80), because TYPE80A creates a separate data
set for each RACF command, keeping only the variables for
that event. But that means there is an EXTY80xx exit for
each dataset, and if you wanted to filter the type 80 SMF
record and (for example, delete all events with RACFAUTH
with BIT0:NORMAL AUTH set, so you only output the events
with the other bits -SPECIAL, AUDITOR, etc-) you would
have to put your test in each of those EXTY80XX exits.
Fortunately, there is an MXG exit, IMACJBCK, that applies
to all of the TYPE80A-built datasets (although designed
just for "Job Checking"), and when it is taken, these
RACF variable have been input:
RACFDESC RACFEVNT RACFQUAL RACFUSER RACFGRUP
RACFAUTH RACFREAS RACFTLV RACFERR RACFTERM
JOB READTIME LOCLINFO RACFVRSN
To use the exit instream and delete all records with the
BIT0:NORMAL AUTH bit turned on (to output all the rest):
// EXEC MXGSASV9
//SMF DD DSN=your.input.smf.data,DISP=SHR
//PDB DD DSN=your.output.type80a.pdb,DISP=OLD
//SYSIN
%LET MACJBCK=
%QUOTE(
IF ID=80 AND RACFAUTH EQ '1.......'B THEN DELETE;
);
%INCLUDE SOURCLIB(TYPS80);
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Change 20.225 Support for CICS APAR PQ63143 SMF 110 subtype 2 stats.
FORMATS Incompatibly changed STID=24, CICAUTO dataset segment,
VMAC110 added new fields at the end of other STIDs. Without the
Oct 17, 2002 change, MXG log messages about new data for STID= print,
but all other MXG datasets were still correctly built;
only CICAUTO is incorrect without this Change, and it is
seldom used.
-STID=24 +4 byte insert: CICAUTO changed INCOMPATIBLY.
In addition, time variables A04CIDLE/CMAXI/TIDLE/TMAXI
are now input correctly; they were missing previously.
-STID=60, reserved field now DSGTCBAF, variables DSnTCBAF
are created for each of the 13 CICS TCBs. DFHDSGDS.
-STID=81 +124 bytes added at end, eight new variables
added to dataset CICM compatibly. DFHMNGDS.
-STID=121 +4 bytes added at end, one new variable in the
CICXQ1 dataset compatibly. DFHXQS1D.
-The APAR did not list the STID=24 nor STID=121 changes
that were uncovered by MXG's "Skipped Data" messages.
-The APAR text also indicated that the SMDCC DSECT was
changed, but I can find no difference nor new data.
-The APAR text also indicated that the MNCBS DSECT was
changed, but I am unable to find that DSECT, nor have I
found any prior reference to DFHMNCxx DSECTS.
-That APAR text documents that APPLNAME=YES enables two
new EMPs, DFHAPPL.1 and DFHAPPL.2, that you can use to
move 4 and 8 bytes of user data; unfortunately, I've not
yet found where that data will be moved into the SMF 110
record. Let me know if you find where IBM puts it!
Note that new DFHMNRDS (Transaction Resource Class) data
also in this APAR was added by MXG Change 20.200.
Thanks to MP Welch, SPRINT, USA.
Change 20.224 The KEEPIN= argument provided no performance benefit and
ANALCNCR is no longer used; it remains defined only so that any
Oct 16, 2002 existing %ANALCNCR invocation with KEEPIN= will not fail.
All input variables are now kept, and the existing KEEP=
option on the DATA statement will keep only the variables
that are needed, to minimize the work space required.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.223 CICSTRAN variable USERCHAR was still wrong after 20.148.
UTILEXCL The %INCLUDE statement UTILEXCL creates should have been
Oct 16, 2002 IMACICDU, which inputs the temporary USRSTRNG variable,
and then it includes member IMACICUS. All notes telling
you to EDIT member IMACICUS (to set the length, etc.) are
still correct and unchanged.
Thanks to Victoria Lepak, Aetna, USA.
Change 20.222 Negative value for DB2SRBTM with DB2 V7 and CICS V2.2.
VMACDB2 Starting with DB2 Version 6, IBM's documentation in the
Oct 16, 2002 DSNDQWAC copybook states that "SRB times are no longer
set by DB2", and because QWACBSRB and QWACESRB fields
were always zero, the original MXG calculation logic:
IF QWACBSRB GT 0 AND QWACESRB GT 0 THEN
DB2SRBTM=QWACESRB-QWACBSRB;
was never executed and DB2SRBTM was always missing, as is
documented in the ADOCDB2 member. However, new data from
DB2 V7 (connected to CICS V2.2, which may be the factor)
show non-zero values for both BSRB and ESRB, causing the
unexpected non-missing (and negative) value in DB2SRBTM.
MXG is now changed to force DB2SRBTM to always be a
missing value, as was originally documented in MXG Change
19.094, no matter what values are found in the ESRB/BSRB.
We will ask IBM DB2 support to explain what is being put
in the ESRB/BSRB fields to see if this is new data that's
undocumented, or if it's just random noise!
Additional data observations: QWACASRB is also non-zero.
QWACESRB is nonzero for all connection types, not just
CICS. For CICS Attach (QWHCATYP=4), QWACASRB, QWACBSRB,
and QWACESRB may be cumulative (like QWACBJST, QWACEJST).
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 20.221 Internal changes to ensure correct sequencing of multiple
VMXGUOW records with new (internal) TIMESTMP variable.
Oct 15, 2002
Nov 4, 2002
Change 20.220 Variable STC28TIM in STCVSM28 from STK's User SMF record
VMACSTC was input as &PIB.8. but it should have been &PIB.4. (and
Oct 15, 2002 that caused the subsequent ST=28 variables to be wrong).
Thanks to Nathan Walsh, STK, USA.
Change 20.219 ASMTAPES ML-26. This revision is the circumvention that
ASMTAPES lets you EXCLUDE your VTS devices from the Mount-Scan (to
Oct 14, 2002 eliminate the high CPU cost of recovery from 0E0 ABENDS;
Nov 2, 2002 see Change 20.214), while still scanning for Allocates to
record the job's JESNR/READTIME/etc and populate them in
the PDB.TYPETALO dataset for drive utilization measures.
And by using dataset PDB.ASUMTAPE instead of the original
PDB.TYPETMNT dataset, each mount event will be recorded
because ASUMTAPE merges PDB.TYPETALO and IBM's TYPE21 to
capture the mount event, although the MNTTM duration will
be missing for DEVNRs excluded from the Mount Scanning.
Comments in ASMTAPES document the syntax of the EXCLUDE
text file that is used during Assembly of MXGTMNT.
The ML-26 has been tested under z/OS 1.3, and it contains
additional enhancements:
One condition under which READTIME was incorrect was
found and corrected.
New messages are printed by MXGTMNT at startup:
TMNT018I - displays interval setting at initialization
TMNT020I - acknowleges the existence of EXCLUDE DD
TMNT021I - displays list of devices that are excluded
New diagnostic command (F MXGTMNT,DIAG) will display a
series of informational messages:
TMNT025I - count of cross memory ABEND recoveries
followed by one line per tape device with
UCB address, monitoring status, current job
name, and current volser. Status shows if
the DEVNR is enabled for Mount/Alloc/Both.
Any DEVNR not in the list is not monitored.
The ML-26 revision does not solve the problem of missed
VTS mounts, and won't solve all problems with missing job
fields in PDB.TYPETALO and PDB.ASUMTAPE when allocation
duration is too short for MXGTMNT sampling.
We are now looking for an exit that would capture mounts
and miss none and not require cross-memory services to
find the mounting job's identity and information, but
there is no guarantee we'll be successful.
Regretably, ML-26 early tests show it still uses the same
and significantly higher CPU time that ML-25 uses, even
when both mount scans and allocate scans were excluded,
so we still have no fix, as of 2Nov02.
Change 20.218 RACF USRSEKTN (Security Token, SMF80DTP=53) is decoded
FORMATS with new TOKxxxxx variables added to TYPE80nn datasets
VMAC80A that contained variable USRSEKTN. New data found in SMF
Oct 12, 2002 80 record from z/OS Secure Way Security RACF Server (with
Oct 21, 2002 SMF80RVM=7706), with keywords UID, HOME, and PROGRAM are
now realized to be Extended-length Relocate Sections with
SMF80RL2 offset and SMF80CT2 count of 3, whose existence
is documented in the SMF manual (previously unnoticed)
but whose contents are not documented. The one record
found with these keywords all have Data Type SMF80TP2=301
and are heuristically decoded. Because they were found
after the last "normal" Relocate Section, which happened
to be SMF80DTP-53, I thought they were part of USRSEKTN,
and gave them variable names of TOKUID, TOKHOME and
TOKPROG. For now theyu are kept only in the TYPE8013
(ALTUSER command) dataset, while I await documentation
from IBM RACF Support to see if there are other data in
these Extended-length Relocate sections.
Thanks to Peter Skov Sorensen, JN-data, DENMARK.
Change 20.217 Variables D6ASCODE and D7ASCODE are input &IB.4 instead
VMACTMDB of &PIB.4. because SQLCODEs can be negative values.
Oct 8, 2002
Thanks to Richard Schwartz, State Street Bank, USA
Change 20.216 INPUT STATEMENT EXCEEDED was circumvented by changing the
VMACVIOP input of VIOPDCA,VIOPBND, and VIOPBNI from 4 to 2.
Oct 7, 2002
Thanks to Michael E. Friske, Fidelity Systems, USA.
=======Changes thru 20.215 were in MXG 20.06 dated Oct 7, 2002=========
Change 20.215 This user contributed code has been in MXG since 17.17;
IMACAAAA it reads a Solaris flat file log from ddname SUNSLOG,
EXSUNSOG but it was never listed in a change, nor in the IMACAAAA
IMACSUNS "list of all products" member, nor documented in any way.
TYPESUNS Freddie's QA program detected this, and many, omissions:
TYPSSUNS Long ago (on a NEC 286 notebook and a 12 hour run) he
Oct 6, 2002 wrote a SAS program to read the MXG Source Library
looking for specific text (i.e., a smart parser), and
found code that he thought might be wrong, because he
had seen me correct similar code in earlier CHANGES.
For example, a duplicate variable name does not cause
an execution error in a SAS program, but is a true
programmER error (not a programmING error - they do
not exist) when a separate variable name was needed.
That text scan of the MXG Source now looks for scores
of exceptions (e.g. DATETIME formatted variables not
stored in 8 bytes) and for inconsistencies between the
contents of documentation members and reality (do all
members listed in IMACAAAA exist in the MXG Source?).
But his QA program goes much further: by exploiting
the consistent structure of the VMACxxxx members that
create MXG datasets, and the consistent macro names
for the data-set-related _L/_W/_E/_B/_Sdddddd macros,
(and by telling me to fix my code when I'm careless)
he compares the documentation in comments with what
happens when the program is run. For example:
_Edddddd /* EXdddddd OUTPUTS DATASET */
is examined to verify that "DATASET" is the actual
dataset created when that statement is executed.
The SAS error-detection during the MXG QA Execution,
followed by Freddie's Source QA Program provides the
Quality Assurance to MXG users that the newest version
is better than the last and most likely error-free.
If you contributed the VMACSUNS, let me know to cite you,
or if this is useful, let me know so I can update this
text as to what Sun log, etc.
Thanks to Freddie Arie, TXU, USA.
Change 20.214 This is documentation of the status of of ASMTAPES ML-25.
ASMTAPES If you have Virtual Tape devices, ML-25 uses a lot more
Oct 4, 2002 CPU time (30 min per day vs 30 secs) than ML-19, but if
you have no VTS devices, there was no increase in cost:
- When you have VTS devices with their very fast scratch
mounts, 0E0 ABENDs occur when MXGTMNT Cross Memory's to
get the JOB/JESNR/READTIME/etc from the job's ASID, but
finds the job issuing the mount has already gone away.
- When ML-19 encountered an 0E0 condition during the UCB
scan for mounts, it recovered, but then quit for that
interval, and did not scan the rest of the UCBs for a
mount condition, nor did it even start the scan of UCBs
for allocations. This caused many TYPETMNT/TYPETALO
events to be missed (i.e., no SMF record written), and
0E0 recoveries could fill SYS1.LOGREC, and made it look
like MXGTMNT was not scanning 4-digit UCBs!
- ML-25 recovers from each mount UCB with a 0E0, (but it
still writes a record when appropriate, although the
ASID-related variables will be missing), and then scans
all UCBs for allocations, so it should see a lot more
allocaations, since allocations are usually much longer
than mounts. ML-25 also prevents the 0E0 LOGREC write.
And the DDNAME in TYPETMNT can be wrong, like JOBLIB!
- STROBE showed that the increase in CPU time is in the
IBM recovery modules, which are now being invoked many
more times than before, and we can't rewrite IBM code.
ML-26 is in development as a short-term circumvention that
will let you skip the UCB scan for mounts for VTS devices
(you'll specify the device addresses to be skipped), which
should significantly reduce the 0E0 recovery CPU cost, but
the UCBs will still be scanned for allocations. Due to a
(presumed) longer duration of allocation than mount time,
we should have very few 0E0 recoveries for allocations.
While the TYPETMNT record won't exist for the skipped VTS
UCBs, TYPETALO data will exist and it contains ASID info.
Not only is TYPETALO sufficient for measurement of tape
device utilization, but also member ASUMTAPE combines the
TYPETMNT, TYPETALO, and TYPE21 to create the PDB.ASUMTAPE
dataset that records each mount-dismount event, even for
VTS mounts without a TYPETMNT, and the ASID fields from
will populate the ASID variables into PDB.ASUMTAPE for
mount analysis (but with MNTTM missing for skipped UCBs).
This "ML-26-to-be" might be avaliable in early November.
It's availability will be posted to MXG-L when tested.
Once the ML-26 is available, we intend to go continue our
investigation of a permanent fix, to be exit-driven rather
than sampling UCBs, and hope to locate an exit that runs
in the mounting job's address space, which would remove
the 0E0 exposure, but that is clearly a non-trival and
major re-design of the MXG Tape Mount and Alloc Monitor.
Change 20.213 Support for APAR OW52396 (COMPAT) for Ficon Switches adds
VMAC74 meaning for existing bits in R747PTFL and R747PSFL, which
Oct 3, 2002 are already formatted $HEX2. to expose all flag bits.
No change was made to VMAC74.
Change 20.212 Support for APAR OW56162 for SMF type 64 new VSAM EOV SMF
VMAC64 that is written when there is a record management catalog
Oct 3, 2002 update request. Variable SITUIND='CATALOG UPDATE' is set
from SMF64RIN bit 7 for this new event; this record will
not contain any extent information.
Change 20.211 NDM caused INPUT STATEMENT EXCEEDED error when it wrote
VMACNDM an invalid NDM Statistics SMF record (it also wrote a
Oct 3, 2002 message to SYSLOG to let you know it knew it messed up),
that was only 24 bytes long. MXG now tests the length
of the NDM record and avoids the ERROR, instead printing
an ERROR message on the MXG log that an invalid NDM SMF
record was found and deleted. This text will be updated
when a resolution is provided by NDM's vendor.
NDM is now called Connect Direct.
Thanks to Jim Petersen, Washington Mutual, USA.
Thanks to Rick Ramirez, Washington Mutual, USA.
Change 20.210 For DB2 V6 variables QWACARLG & QWACAWLG were not input
VMACDB2 because the two tests for LENQWAC 224 AND QWHSRELN 7
Oct 3, 2002 should have tested QWHSRELN LT/GE 6 instead of 7.
Thanks to Terry L. Berman, DST Systems, Inc, USA.
Change 20.209 VGETDSN now detects that the requested DDNAME is not
VGETDSN allocated, printing a message on the log.
Oct 3, 2002
Change 20.208 TYPETPMX for ThruPut Manager SMF records, variable SPACE
VMACTPMX had to be changed to SPACERQ, because variable name SPACE
Oct 2, 2002 was already defined in TYPE1415 as a character variable.
If you combined TPMX and 1415 SMF records processing in
the same step, you got a strange "INFORMAT PIB UNKNOWN"
error.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 20.207 Variable MODULE was increased from $32 to $64 because the
VMACNTSM length of the module path was found to exceed 32 bytes.
Oct 1, 2002
Thanks to Xiaobo Zhang, ISO, USA.
Change 20.206 Support for SMF 94 subtype 2, and subtype 1 enhancements
EXTY942 adds many valuable VTS variables to existing TYPE94 data
EXTY942P set and creates new TYPE942 dataset with Volume Pooling
FORMATS Statistics added by IBM Field Change 4001.
VMAC94
VMXGINIT
Sep 30, 2002
Change 20.205 Support for z/OS 1.4 (COMPATIBLE) has only minor changes
FORMATS to the SMF manual text and one new variable in TYPE74CA:
VMAC74 -Variable R7451RTY added to TYPE74CA dataset identifies
VMAC79 the RAID Rank Type of RAID-5, JBOD, or RAID-10. Note
Sep 30, 2002 that JBOD is 'Just a Bunch of DASD'!
-SMF records 63, 67, and 69 pages now clearly state they
do not exit because VSAM catalogs no longer exist.
-SMF71LIC (HIUICMN) documents that UIC values can range
from 0 to 2540 seconds; Don Deese clarified that those
larger values are for systems with all central (i.e., no
expanded storage), while 0 to 254 seconds is recorded for
systems that have expanded storage.
-R793CPUU in TYPE793 set missing if it 7FFFx or 00FFx, and
"PERCENTAGE" is added to its label.
-R793CUT should not have been TIME12.3, as it contains the
MVS Utilization (MVS Non-Wait) as a percentage of the
interval length; it is the same as R793CUU if not LPAR.
-These TYPE79A variables are documented as reserved (maybe
was an earlier release): R79AMPLT,R79AGOOU,R79ATCTL,
R79ATYPE, and R79AMSO.
Change 20.204 Support for SMF 120 Subtype 7 and 8 from WebSphere
FORMATS Application Server V4.0.1 for z/OS and OS/390 creates new
EXT120WA datasets:
EXT120WI TYP120WA - Web Container Activity - subtype 7
VMAC120 TYP120WI - Web Container Interval - subtype 8
VMXGINIT These data were added by APAR PQ59911.
Sep 30, 2002
Thanks to Randy Shumate, LEXISNEXIS, USA.
Change 20.203 Variable PONBR should have been kept in the QAPMPOLL
VMACQACS dataset for OS/400 5.1 Collection Services; now it is.
Sep 29, 2002
Thanks to Raymond Dunn, CIGNA, USA.
=Attended 35th Reunion of the NESEP (Navy Enlisted Scientific
=Engineering Program) Class of 1967 at Purdue University.
Change 20.202 Support for BMC's Mainview for DB2 THRDHIST file. The
TYPSTHST type 'K' record contains a beheaded SMF 101 accounting
VMACDB2 record. This new TYPSTHST member reads the THRDHIST data
Sep 23, 2002 and creates all of the DB2 Accounting datasets (DB2ACCT,
DB2ACCTB, DB2ACCTG, and DB2ACCTP) in the PDB library.
Member TYPSTHST defines macro _THRDHST to decode the BMC
header and uses it in place of the standard _SMF macro,
so that the MXG code in VMACDB2 can be used to decode
THRDHIST records. However, when there are more than 10
packages, THRDHIST puts extra package segments in a new
area at the end of their record. Reading the additional
package segments could not be done within VMACDB2 code,
so it was necessary to create a copy of the QPAC logic
from VMACDB2 in the TYPSTHST member, and to invoke that
code in the EXDB2ACC exit redefinition in TYPSTHST.
So now, anything I or IBM does to the QPAC logic in
VMACDB2 must be repeated in TYPSTHST!
-One additional IF statement to reset OFFSMF for THRDHIST
had to be added in VMACDB2 to support this change.
Thanks to Mr. Globisch, R+V, GERMANY.
Thanks to Mr. Peters, R+V, GERMANY.
Change 20.201 Support for ASG-Landmark TMON/MVS 3.0 and 3.1, INCOMPAT.
EXTMVWG TMVS records are completely revised, a new header in all
EXTMVWGS records, and reordering of fields within the existing
FORMATS segments, so you must have this change for TMVS V3 data.
VMACTMVS All existing datasets have been fixed and tested. These
VMXGINIT new subtypes: MC,XC,XD,XS,X2,X3,X4,XP, and XW will be
Sep 23, 2002 supported in the order you request. Comments in member
Oct 1, 2002 VMACTMVS list the record subtypes and TMVS version and
Oct 17, 2002 which MXG datasets are populated by which TMVS version.
Oct 21, 2002 Note: The support for TMON/MVS V3.0 and later is now
Nov 4, 2002 back in TYPETMVS/TYPSTMVS. (Do not use TYPETMV2).
Nov 4: RETAIN M8 (-8); statement inside MACRO _TMVS was
relocated; it was not in the IMACTMVS example, and
if you redefined IMACTMVS for Compressed Data you
got M8 UNINITIALIZED and STOPOVER ABEND.
Thanks to Yves Terweduwe, CIPAL, BELGIUM
Thanks to Michael Stark, 5-3 Bank, USA.
Change 20.200 Support for CICS Transaction Resource Class Data.
EXCICRDS Added by CICS APAR PQ63143 and documented in DFHMNRDS,
EXCICRDF this new CICS SMF 110 Subtype 1 MNSEGCL=5 creates these
IMACCICS two new datasets:
VMAC110 CICSRDS - Resource Class Data - Transaction data
VMXGINIT CICSRDFI - Resource Class Data - File Details.
Sep 21, 2002 There is one observation in CICSRDS for each transaction
whose data is collected, and one observation in CICSRDFI
for each FILENAME that was accessed by the TRANNAME in
the CICSRDS dataset. The transaction data is in the
CICSRDS dataset, and the File information is in CICSRDFI
to minimize the disk space for these data; it may be
necessary to merge the two datasets for some reports.
This new data (finally!) allows you to track what files
had how much activity (counts AND durations) for each
CICS transaction.
As both datasets can be large, neither are sorted by MXG
by default, and both are written to the //WORK file.
To instead write both to the "PDB" ddname, you can use
%LET WCICRDS = PDB;
%LET WCICRDF = PDB;
before your %INCLUDE SOURCLIB(TYPE110) or (BUILDPDB).
Note that to create this new files-used-per-transaction
data, you must change the IBM default FILES=0 in DFHMCT.
Change 20.199 This example program read SAT.TYPE70PR twice and failed
WEEK70PR to read FRI.TYPE70PR at all, causing the WEEK.TYPE70PR
Sep 21, 2002 dataset to be incorrectly build.
Thanks to Michael Marcus, Affilliated Computer System, USA.
Change 20.198 These MONIDBDS variables, from old versions, should not
VMACTMO2 not have been created and can be dropped in _KMONDBD
FORMATS FILEADIN FILEUPRP FILEGET FILEBROW FILEOPCL FILEDEL
Sep 21, 2002 FILESRV
(but they are still kept by default, so any existing
reports you have won't fail with VARIABLE NOT FOUND).
And the field that was used to create those variables is
new variable FILEACM, decoded by new format $MGMONAM.,
to describe the access method that was used for this
file: (ISAM,BDAM,VSAM,QSAM,RMTE,DL/I,DB2,DCOM)
Thanks to Richard Jay Schwartz, State Street Bank, USA.
Change 20.197 Type 30s for JES2 job have blanks for READTIME with valid
VMAC30 REND (Reader End), causing INVALID READTIME messages. Now
Sep 21, 2002 the READTIME=REND if READTIME is blank.
Change 20.196 The ***ERROR.VMACEXC2.2 INVALID DEVCLASS/DEVTYPE message
VMACEXC2 now prints variables ABEND and CONDCODE and a hex dump of
Sep 21, 2002 the first three instances; these messages should be sent
to support@mxg.com for examination. This message occurs
when MXG reads a type 30 with a DD segment in the TIOT
with an unknown Class/Type value. This has been caused by
- errors in your installation's SMF exit code, which can
accidentally overwrite data in the type 30 before the
record is actually sent to the SMF data set. The step
termination exit is often used to print step resources
on the job's SYSMSG, and that exit code has been found
to overlay these fields in the past, (but usually the
DDNAME is still valid). The "your" code may have been
provided by a vendor; for example, CA's job scheduling
product changes the values in SMF records in SMF exits.
- an overlay of the TIOT by the executing program in this
job. Often, the step will have ended with an ABEND, of
a SYSTEM 5xxF or 9xxF, if other control blocks were
also overlaid.
If there were EXCPCNTs in this segment, they can't be put
in the correct EXCPdddd/IOTMdddd bucket, since I don't
know the device type/class to put them in!
Change 20.195 New variables QWACAWTK/M/N/O/Q QWACARNK/M/N/O/Q and
VMACDB2 QWACSPVT/RLSV/RBSV were missing; IBM changed QWACLEN from
Sep 21, 2002 500 to 496 bytes, and removed a reserved field, but MXG
code was expecting 500 bytes.
Thanks to Victoria Lepack, Aetna, USA.
Change 20.194 Formats for MSU constants were updated for the 2064-2xxx
FORMATS processor family. These values are used only if you do
Sep 18, 2002 not have z/OS (which populates the CECSUSEC directly).
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 20.193 ANALCICS example ERROR: VARIABLE OPERATOR NOT FOUND if
ANALCICS you excluded the archaic OPERATOR field; Change 13.268
Sep 17, 2002 noted that OPERATOR is almost always blank and that USER
is better, but ANALCICS still used OPERATOR. The example
was revised to use USER, as ANALCICS is included in the
JCLPDB8 job, and the old reference caused an unnecessary
test run to fail.
Thanks to Rick Salazar, City of Long Beach, USA.
Change 20.192 Support for the SAMS:VANTAGE 3.2.0 OBJ=POOLS record adds
EXSAMPOO new SAMSPOOL dataset with interval DASD pool statistics.
IMACSAMS There is an undocumented datetime value, but when decoded
VMACSAMS it is slightly earlier than the SMFTIME, but not enough
VMXGINIT to be a start of interval value:
Sep 17, 2002 SMFTIME SAMSTIME
Sep 30, 2002 07:19:13.44 07:17:45
07:39:05.58 07:37:45
08:00:27.22 07:57:45
Thanks to Jennifer Chu, Goldman, Sachs & Co., USA.
Change 20.191 Tape Mount Monitor records with blank JCTJOBID can occur,
VMACTMNT causing WARNING - TYPETASK NOT DECODED log messages and
Sep 16, 2002 TYPETASK blank in datasets TYPETMNT/TYPETALO/ASUMTAPE.
To suppress the warning message, VGETJESN is now only
invoked when JCTJOBID is non-blank, but TYPETASK will
still be blank when JCTJOBID is blank.
Thanks to Jesse Gonzales, The Gap, USA.
Change 20.190 The new MXG logic to create TYPETASK from "Z2" JCTJOBID
VGETJESN (i.e., the Jnnnnnnn format), tested variable SUBSYS for
Sep 16, 2002 TSO/JES2/JES3/STC to set TYPETASK='JOB', but variable
SUBSYS in TYPE6 is print subsystem (VPS,PFS, etc), and
and those records had TYPETASK='J ' (as would any SMF
record without a SUBSYS variable). This revision sets
TYPETASK='JOB ' for any record whose SUBSYS is not one
of the above four values, if JCTJOBID starts with a "J".
Thanks to Don Cleveland, Wellpoint Health Networks, Inc, USA.
Change 20.189 Candle OMEGAMON/VTAM Release 5.2.0 caused STOPOVER for
VMACOMVT IRNUM=27 internal subtype. Field OMVTINTV was inserted
Sep 16, 2002 and 40 new variables are now created in OMVTTCP dataset.
Thanks to Dave Crandall, Farmer's Insurance, USA.
Change 20.188 Example/member TYPSMQM will read //SMF and create all of
TYPSMQM the MQMxxxxx datasets from SMF 115 and 116 MQ-Series data
Sep 16, 2002 in one pass of SMF, sorting the output in to //PDB.
Thanks to Walt Blanding, Washington Mutual Bank, USA.
Change 20.187 Landmark/ASG for CICS 2.1 variables decoded from TAFLAG1
VMACTMO2 were not all decoded; variables STORVIOL and ABNDMONI are
Sep 5, 2002 now created and output, so the MONITASK dataset has the
same variables as with TYPEMON8 datasets.
Thansk To Arvid Lilleng, IBM Global Services, NORWAY.
=======Changes thru 20.186 were in MXG 20.05 dated Sep 6, 2002=========
Change 20.186 The RMF Reports printed blank for the MVS Level for z/OS
ANALRMFR systems; the test for MVSCHRLV was revised to test for
Sep 5, 2002 ZV prefix to recognize z/OS and print "Z/OS" for Level.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.185 Change 20.168 caused MXG to create missing values for the
VMXGRMFI MSU-related variables, but only for non-z/OS systems that
Sep 5, 2002 don't have any IBM MSU numbers, and for which MXG uses a
table look-up to get the values for MSU calculations.
These old records don't have SMF70WLA populated, and MXG
incorrectly tried to calculate a value for WLA, when the
table can only return CPCMSU. The variable ZOS70WLA is
now always zero, as it should never have been created.
This error was caught in the deep QA of the first 20.05.
Note that old SMF 70s not only have SMF70WLA=., but also
SMF70CPA=., so the MSU variables in ASUM70PR/ASUMCEC will
also be missing until your SMF 70s have the added fields.
Change 20.184 Support for z800 processors might be incomplete; tests
VMAC7072 for CPUTYPE='2064'X must be CPUTYPE IN('2064'x,'2066'x).
Sep 5, 2002 Might affect LPARCPUS count and whether spare CPUs were
Sep 6, 2002 output in TYPE70PR for 2066, but if variable SMF70ONT is
populated, i.e., your z/OS maintenance is current, then
that eliminates the need to know the CPUTYPE, and your
z800 TYPE70/TYPE70PR data was just fine. No problem was
reported; this was accidentally observed as a possible
exposure that needed protection.
Change 20.183 A nice example of using a DATA step to perform a linear
ANALREG regression for two variables, returning the equation of
Sep 5, 2002 the best-fitting line, without requiring SAS/STAT.
Documented in its comments and contributed to MXG.
Thanks to Rab McGill, Standard Life, SCOTLAND.
Change 20.182 Type 42 Subtype 19 SMF42NRS='NUMBER OF SYSTEMS' is wrong.
VMAC42 Created when I saw "total cpu across sysplex" and the
Sep 4, 2002 "average cpu per system" and the number=total/average,
SMF42NRS=JNF/JNE for X1, and = JPF/JPE for X2 always
produced a value of 60 for the total to average value
for both the X1 and the X2 segments; for example, one
obs had JPF=71.555 seconds, JPE=1.193 for one system,
with SMF42JPA (interval)=900 seconds. The only clue
as to the meaning of the total:average ratio of 60 is
that SMF42JPG, the number of buffer intervals processed,
was also 60. Assuming the total CPU time is the total,
then the "average" CPU time is the average per buffer
interval, rather than the average per system, so the
label for JNE and JPE were corrected to reflect this
conclusion. The number of systems is now set from the
number of system segments, SMF42NRS=NR42X2.
Thanks to Helmut Roese, COM Software, GERMANY.
Change 20.181 Messages FILE WORK.DSNBREC WAS NOT FOUND BUT APPEARS ON A
TYPETMS5 DELETE STATEMENT were eliminated by replacing two PROC
Sep 4, 2002 DATASETS and DELETE TMSREC and DSNBREC with PROC DELETEs
with DATA=_WTMSTMS and DATA=_WTMSDSN.
Thanks to Dr. Alexander raeder, Itellium, GERMANY.
Change 20.180 MXG used the undocumented STARTHR-1 as the start time of
VMACTNG eachstart time of a performance cube, but the STARTHR may
Sep 4, 2002 only be a daylight savings flag and may not be the start.
Since the TNG data apparently should always start at hour
zero, that is now the MXG default, but that zero default
is externalized in the new MACRO _TNGSTHR TNGSTHR=0; %
If your data needs the MXG equation, you can replace that
TNGSTR=0; statement with any SAS statements that set the
variable TNGSTHR to your desired start hour. Your MACRO
definition would be put in member IMACKEEP, or could be
set in the SYSIN stream using this syntax:
%LET MACKEEP=
%QUOTE( MACRO _TNGSTHR TNGSTHR=STARTHR-1; % );
%INCLUDE SOURCLIB(TYPETNG);
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.179 TNG variable INSTANCE was blank in the NT014 (PROCESSOR)
VMACTNG data instead of zero. MXG expected the INSTANCE variable
Sep 4, 2002 to exist and be input from each 3-HDR record, and so set
INSTANCE=' ' to prevent an unexpected carry-forward of
the RETAINed value. This worked with all other objects
with more than one instance, but for the PROCESSOR object
(and presumably any other objects that can have more than
one instance, but actually have only one), CA puts the
INSTANCE value only in the 2-HDR for the object. To fix,
the INSTANCE=' '; statements were removed from the 3-HDR
logic so that the INSTANCE from the 2-HDR will be output.
For documentation and future reference, the sequence of
the TNG records for an NT server are listed here:
Record Object Metric Instance OOO
(-HDR Logical Disk %Disk Time 0;C: 5
4-HDR 1;D: 5
4-HDR _total;_total 5
3-HDR %Free Space 0;C: 5
4-HDR 1;D: 5
4-HDR _total;_total 5
... repeat one 3, two 4 for each metric in object
2-HDR Memory Avail Bytes blank 6
3-HDR Comm Bytes blank 6
... repeat one 3 for each metric in this object
2-HDR Network Interf Bytes Recvd 1 10
4-HDR Bytes Recvd 2 10
3-HDR Bytes Sent 1 10
4-HDR Bytes Sent 2 10
... repeat one 3, one 4 for each metric in object
2-HDR PROCESSOR %priv time 0 10
3-HDR %proc time blank 10
3-HDR %user blank 10
... repeat one 3 for each metric in object
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.178 The JCLTEST8 example did not have a DB2ACCT DD statement
JCLTEST8 in step TESTIBM3; if you change the default to send your
Sep 4, 2002 DB2ACCT data to the DB2ACCT DD, this test job failed.
Thanks to Jesse Gonzalez, The Gap, USA.
=======Changes thru 20.177 were in MXG 20.05 dated Sep 1, 2002=========
Change 20.177 The PHYSDISK dataset from Win 2000 Beta 3 (NRDATA=31) had
VMACNTSM incorrect values in AVGSKQL, AVDSKWQL, PCTDSKRD, PCTDSKWR
Aug 30, 2002 and SPLTIORT. Variables are now correctly INPUT in order.
Thanks to Andrzej Dabrowski, CSIR, SOUTH AFRICA.
Change 20.176 Support for ten new Oracle objects and ten new Analysis
EXNTANAC Server objects create these new MXG datasets:
EXNTANCO NTANAC ANSRAGCA ANALYSIS SERVER:AGG CACHE
EXNTANLA NTANCO ANSRCONN ANALYSIS SERVER:CONNECTION
EXNTANLO NTANLA ANSRLAQU ANALYSIS SERVER:LAST QUERY
EXNTANPA NTANLO ANSRLOCK ANALYSIS SERVER:LOCKS
EXNTANPI NTANPA ANSRPRAG ANALYSIS SERVER:PROC AGGS
EXNTANPR NTANPI ANSRPRIN ANALYSIS SERVER:PROC INDEXES
EXNTANQD NTANPR ANSRPROC ANALYSIS SERVER:PROC
EXNTANQU NTANQD ANSRQUDI ANALYSIS SERVER:QUERY DIMS
EXNTANST NTANQU ANSRQURY ANALYSIS SERVER:QUERY
EXNTORBC NTANST ANSRSTRT ANALYSIS SERVER:STARTUP
EXNTORD1 NTORBC ORACBUFF ORACLE9 BUFFER CACHE
EXNTORD2 NTORD1 ORACDBW1 ORACLE9 DBWR STATS 1
EXNTORDD NTORD2 ORACDBW2 ORACLE9 DBWR STATS 2
EXNTORDF NTORDD ORACDADI ORACLE9 DATA DICTIONARY CACHE
EXNTORDY NTORDF ORACDAFI ORACLE9 DATA FILES
EXNTORFR NTORDY ORACDYSM ORACLE9 DYNAMIC SPACE MANAGEMENT
EXNTORLI NTORFR ORACFREE ORACLE9 FREE LIST
EXNTORRL NTORLI ORACLIBR ORACLE9 LIBRARY CACHE
EXNTORSO NTORRL ORACREDO ORACLE9 REDO LOG BUFFER
IMACNTSM NTORSO ORACSORT ORACLE9 SORTS
VMACNTSM
VMXGINIT
Aug 29, 2002
Thanks to Steven M. Dunn, Mainframe Performance Products, AUSTRALIA.
Thanks to Wojtek Stanczew, Northern Territory Government, AUSTRALIA.
Change 20.175 Comments only. Corrected typo and revised descriptions of
WEEKBLD which WEEKBLD/WEEKBLDT/WEEKBL3/WEEKBL3T/JCLWEEK/JCLWEEKT
Aug 29, 2002 member to use for what.
Thanks to Ed Billowitz, Medical College of Virginia - VCU, USA.
Change 20.174 -Change 19.176 created variable R791MLIM but did not add
VMAC79 that variable to the KEEP= list for dataset TYPE791.
Aug 28, 2002
Change 20.173 Change 18.348 documented that QWACvvvv variables should
VMACDB2 be used instead of the QWAXvvvv counterparts in DB2ACCT,
Aug 28, 2002 and why the QWAXvvvv variables were kept. This change
makes these shouldn't-be-used-variables to be correct:
QWAXAWDR QWAXALOG QWAXAWCL QWAXAWAR QWAXOCSE QWAXSLSE
QWAXDSSE QWAXOTSE; they needed to be divided by 4096.
Thanks to Glen Yee, The Gap, USA.
Change 20.172 Variables PCHANBY, PNCHANBY and especially PBUSBY were
VMAC73 not initialized; PBUSBY was non-missing in SMF73CMG=1 and
Aug 27, 2002 SMF73CMG=2 records, causing confusions. Now, all three
are initialized to missing along with the others.
See Change 20.240, 29Oct2002 correction.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.171 Variable DCDRECFM now contains values 10, 11, 12, or 13
FORMATS for FBA/FBM/VBA/VBM Record Formats; DCDRECFM is now set
VMACDCOL and formatted to 10:VBA, 11:FBA, 12:VBM, 13:FBM
Aug 27, 2002 by addition to the MGDCORF format.
Sep 4, 2002 Feb 4, 2003: Text and values for 10: and 11: had been
Feb 4, 2003 reversed; now change text, code, and format all agree.
Thanks to Steve Gormley, Royal Bank of Scotland, ENGLAND.
Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.
Thanks to Steve Lottich, University of Iowa Hospitals, USA.
Change 20.170 Labels for Single-Engine CPU Utilization variables SBUTIL
VMACQAPM SIUTIL, SUTIL, and SWUTIL now contain "Single Engine" and
Aug 27, 2002 PCTCPUBY now contains "All Engines" for clarity.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 20.169 -VMAC7072 adds variable SMF70LAC to TYPE70PR dataset, and
VMAC7072 -VMXG70PR creates new variables LPnLAC from SMF70LAC with
VMXG70PR IBM's 4-hour average hourly MSU, which can be compared to
Aug 25, 2002 the interval hourly rate in LPnMSUHR, and to the LPAR's
Defined Capacity, LPnMSU70, to both PDB.ASUM70PR and
PDB.ASUMCEC datasets.
-New macros added in VMXG70PR let you set the "RMFINTRV"
dataset that will be updated with the PLATxxxx variables,
and set the "ASUM70PR" and "ASUMCEC" dataset names that
will be output, making it easier to create multiples of
"PDB.RMFINTRV/PDB.ASUM70PR/PDB.ASUMCEC" with different
names and different INTERVAL= values. New comments in
member RMFINTRV show examples of the new possibilities.
For example, to build detail, hourly, and daily datasets,
you could use this code as your RMFINTRV member:
%VMXGRMFI(INTERVAL=DURSET,OUTDATA=PDB.RMFINTRV);
%VMXG70PR(INTERVAL=DURSET,RMFINTDS=RMFINTRV,
OUT70PR=PDB.ASUM70PR,OUTCEC=PDB.ASUMCEC);
%VMXGRMFI(INTERVAL=HOUR,OUTDATA=PDB.RMFINTHR);
%VMXG70PR(INTERVAL=HOUR,RMFINTDS=RMFINTHR,
OUT70PR=PDB.ASUM70HR,OUTCEC=PDB.ASUMCEHR);
%VMXGRMFI(INTERVAL=DATE,OUTDATA=PDB.RMFINTDY);
%VMXG70PR(INTERVAL=DATE,RMFINTDS=RMFINTDY,
OUT70PR=PDB.ASUM70DY,OUTCEC=PDB.ASUMCEDY);
which will create these datasets in your PDB library:
Raw RMF Interval RMFINTRV ASUM70PR ASUMCEC
Hourly RMFINTHR ASUM70HR ASUMCEHR
Daily RMFINTDY ASUM70DY ASUMCEDY
You should also put a member ASUM70PR with only comments
in USERID.SOURCLIB, so it is not executes a second time.
Your %VMXG70PR/ASUM70PR must use the same INTERVAL= value
that was used to create the RMFINTRV it will update, by
either using the same INTERVAL= argument, or by using the
DURSET macro for both RMFINTRV and ASUM70PR programs.
The system in the numeric example inChange 20.168 was in
LPARNUM 10, so that LPAR's data in PDB.ASUM70PR will be
in the LPnxxxx variables, (where n=A), for example:
STARTIME LPALAC LPAMSU LPAMSUHR LPAMSU70
12:30 42 6.65 26.62 50
Changes 20.168 and 20.169 should correct and clarify the
calculations of MSU, and I believe that MSU, rather than
MIPS, is the way we will be measuring usage and capacity
on z/OS systems. A newsletter article is in progress.
Change 20.168 With z/OS 1.1 or later, MXG logic to calculate MSU4HRAV
VMXGRMFI could be wrong, and PDB.RMFINTRV variables CECSUSEC,
Aug 24, 2002 CPCMSU, CPCNRCPU and CPCFNAME were missing. MXG logic
Aug 28, 2002 for non-zero SMF70WLA was wrong, revised, and broken in
two steps for clarity and debug, and fewer variables are
needed to be kept in SPIN.SPINRMFI.
I and others 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 a constant provided by IBM to describe your processor.
For either constant, it is the CPU seconds that are used,
along with the constant, to describe your capacity and
your capacity used in MIPS or MSU.
These are the important MSU-related variables:
-MSUINTRV - "CPU seconds" * CECSUSEC / 1E6 - is a count
and not an hourly rate, used to calculate
rates. Use only if you are summing MSU.
-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 theMSU 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.
-CPCMSU - The CPC total capacity in hourly MSU rate.
-Al Sherkow's excellent research with IBM has found that:
-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.
"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 and reports at the customers
SMF interval.
-The Sub Capacity Reporting Tool uses SMF70LAC, but it
averages all values per LPAR per hour.
-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 4-hr Maximum
RMFWDM snapshot 41 58
IBM SMF70LAC in 12:30 RMFINTRV 42 43
MSU4HRAV (RMFINTRV 15-min data) 41.95 55.4
MSU4HRAV (RMFINTRV hourly data) 40.28 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)
-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's 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:
Eg: 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:
Eg: 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 Change 20.169 for associated MSU notes.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Thanks to Melanie Hitchings, British Telecom, ENGLAND.
Thanks to Andy Billington, British Telecom, ENGLAND.
Thanks to Keith Munford, British Telecom, ENGLAND.
Change 20.167 Using BLDNTPDB with the KEEPERS= option failed, with an
BLDNTPDB "Apparent symbolic reference SUFX not resolved." message.
Aug 23, 2002 First two references to &SUFX should have been &DDDDDD.
Aug 29, 2002 Similar error with _S&KEEPS1X then was exposed and fixed.
-A new value for RUNDAY=PDB, can be used if you just want
to create a PDB from an NTSMF file and put it in the PDB
libname (you want to suppress the normal Daily, Weekly,
Monthly and Trending process that are executed when the
default of RUNDAY=YES is used).
Thanks to Andrzej Dabrowski, CSIR, SOUTH AFRICA.
Change 20.166 Variable RDPERCNT was not input in the EDGRDEXT dataset,
VMACEDGR causing the subsequent variables to be misaligned.
Aug 19, 2002
Thanks to Reinhard Nitsch, Provinzial Versicherungen, GERMANY
Change 20.165 Support for EMC's Catalog Solution user SMF record
EXEMCASO (earlier from Softworks, and even earlier that product
IMACEMCS was named VSAM Mechanic) creates new EMCATSOL dataset.
TYPEEMCS
VMACEMCS
VMXGINIT
Aug 17, 2002
Thanks to Lawrence Jermyn, Fidelity, USA.
Change 20.164 This Analysis example caused sort errors that have been
ANALHSM corrected by this change.
Aug 16, 2002
Thanks to Steve Clark, California Federal Bank, USA.
Change 20.163 Support for the additional four fields in subtype=15,
FORMATS variables SMF15TIM, SMF15LTR, SMF15RSN, and SMF15MGT.
VMACSTC Format $MGSTCVT was created to decode SMF15RSN reason.
Aug 15, 2002
Thanks to Perry Lim, Union Bank of California, USA.
Change 20.162 The UTILRMFI utility (used if RMFINTRV reports duplicate
UTILRMFI CPU time, or to find out what is being put in 'OTHR') now
Aug 15, 2002 has arguments identical to VMXGRMFI, so to run UTILRMFI
reports with your definitions, just copy your tailored
"%VMXGRMFI(..." text into your //SYSIN file, change that
"%VMXGRMFI" to "%UTILRMFI", keeping all your tailoring
arguments, and UTILRMFI reports will be produced using
your definitions, with no retyping!
Comments in UTILRMFI were revised.
Thanks to Ada Phillips, University of Michigan Medical, USA.
Change 20.161 -Support for ASG-Landmark TMON/DB2's Change in format of
EXTMDBD0 the Version field. Originally a binary number, in 3.2
IMACTMDB it became an EBCDIC numeric, 'F3F2'x for 3.2, which made
VMACTMDB LMRKVER=24.3. Accidentally, all of the MXG tests worked,
VMAC102 but MXG code now detects and inputs the new format.
VMXGINIT -INPUT of the header fields starting with HDLEN was out of
Aug 14, 2002 aligment because of undocumented fields (inserted by the
assembler to maintain alignment) that are now skipped.
-The new DBHCDUID, DBHCEUTX, and DBHCEUWN End User USERID,
Transaction Name, and Workstation Name were observed to
contain lower case characters, just FYI for testing, etc.
-Dataset TMDBBD, Authorization Failure, 'BD' record, which
is the data segment from IBM's SMF 102 IFCID=140, now has
all of the QW0140xx variables created and kept, using an
extract of the VMAC102 source code.
-VMAC102 and VMACTMDB documentation of SQL text variables:
(This design change was made in Change 17.251, but was
never clearly documented, especially the zero obs part):
For the SMF 102 DB2 trace records containing SQL text:
T102S063,T102S124,T102S140,T102S141,T102S142,T102S145
(or for the Landmark dataset TMDBBD QW0140TX variable),
the SQL text variable that contains the SQL text
QW0063ST,QW01242T,QW0140TX,QW0141TX,QW0142TX,QW0145TX
was broken into 100 byte chunks, with the 1st 100 output
in the T102Snnn dataset, and the rest "chunked" into the
T102T063,T102T124,T102T140,T102T141,T102T142,T102T145
(for Landmark, TMDBBD0)
"text" datasets that contain only the text and key vars.
But SAS Version 8 supports long character variables, so
with V8 and (the MXG default of) COMPRESS=YES enabled,
only one observation is output in the T102Snnn dataset,
with the entire text stored in the SQL variable, and the
"Text" T102Tnnn datasets will contain zero observations.
(With archaic SAS V6, or with V8 and COMPRESS=NO, MXG
reverts back and "chunks" the test into the T102Tnnn.
-Some incorrect EBCDIC conversions were found in the
VMAC102 code that had impact only when the code executed
under ASCII SAS were relocated and corrected, and then
that code was used in VMACTMDB.
Thanks to Richard Jay Schwartz, State Street Bank, USA.
Change 20.160 MACRO _K102CMN is defined so that you can add variables
VMAC102 to the _V102CMN list of variables that are kept in all
Aug 14, 2002 T102xxx (DB2 trace) datasets, as this is safer than
redefining the _V102CMN macro, in case MXG ever needs to
add variables to that common list.
Thanks to Dr. Alexander raeder, Itellium, GERMANY.
Change 20.159 ASMTAPES ML-25 replaces ML-24; two sites had CPU loops in
ASMTAPES MXGTMNT itself, and one noticed 0C4 Logrec records. The
Aug 13, 2002 error was an unexpected fall-thru after recovery of a 0E0
Aug 30, 2002 or 0C4 ABEND in one of the two cross memory environments
(one, during device scan, and the second during a check
for device allocation for the subtype 4, each of which is
protected by a separate recovery ESTAE). The recovery
logic was revised to fix the CPU loop, but ML-25 now also
eliminates MXGTMNT logrec entries for those 0E0, 0C4, and
any other abends that occur in cross memory (because the
called address space had already been terminated before
our next 2-second sample). Any "real" abends in MXGTMNT
will not be suppressed from logrec.
Thanks to Steve Simon, Alltel, USA.
Change 20.158 First PROC DELETE DATA=ZZAIXPTX is changed to _WAIXPTX.
VMACAIX
Aug 13, 2002
=======Changes thru 20.157 were in MXG 20.04 dated Aug 12, 2002=========
Change 20.157 MXG 20.04 QA cleanup:
-Non-used or typo-s members EXAIXAIX,EXCICEJB,EXQCSCON,
VMACAIX EXQCSDIS,EXQCSJOB,EXQCSPOO,EXT120JM,EXTMTCIN,EXZRBASH,
VMACNPIP EXZRBDSI,EXZRBDVH, and EXZRBENH were deleted.
VMACTMO2 -In _SAIXPTX and _SNPIP02 sort macros in members VMACAIX
VMAC103 and VMACNPIP, typos WAIXPTX and _WNPIP02 were corrected
Aug 11, 2002 to ZZAIXPXT and ZZNPIP02.
-In VMACTMO2, variables QAPRCPUT/QAPRCPUC were misspelled
in MONIPA KEEP list and were not kept, and duplicate
variables in KEEP list were removed, and some VMXGTIMEs
were added.
-Datetime variables not in %VMXGTIME() calls were found in
VMAC103/SERVSTRT
Change 20.156 Support for new NTSMF object, MODULE, tracks DLL modules
EXNTMODU used for application analysis, in new MODULE dataset.
VMACNTSM The new %Disk Busy, Avg Disk Service Time, and Avg Disk
VMXGINIT Queue Time counters created in NTSMF 2.4.4 are now
Aug 9, 2002 supported in both the Logical and Physical Disk datasets.
Change 20.155 Specifying INTERVAL=NONE for CICINTRV is not typically
VMXGCICI useful, since it sums all data for all executions of an
Aug 9, 2002 APPLID, but at least now it works without a zero divide
error, and comments suggest it is not likely useful.
If you specify INTERVAL=HOUR, etc., you must have data
with SMFSTREQ='INT', i.e., you must have interval records
enabled by your CICS guru, and the actual interval must
be less than or equal to the INTERVAL= value you use in
your CICINTRV - IBM default interval is 3 hours. Check
the SAS log, as MXG will print a warning if your INTERVAL
request can't be honored.
Thanks to Brian Keller, ConAgra Inc, USA.
Change 20.154 MXG expected LDSKNAME to be a single letter, but now data
VMACNTSM with HarddiskVolume1, etc., appear in a Win/2000 server
Aug 9, 2002 that shares data on a Hitachi Data Systems 7700E array.
(This is a fail-over cluster, and the system that is
'in control' has the expected disk letter as LDSKNAME,
but on other servers in the cluster that are not in
control, this longer name value is seen).
The problem is that MXG kept LDSNAME in $8, which caused
all of these separate disks to be combined as HARDDISK.
Increasing the length of variable LDSKNAME to $16 should
be sufficient to store the longer name value.
Thanks to John Compton, Bristol and West, ENGLAND.
Change 20.153 Documentation only. If you have multiple systems with
IMACTIME different time zones sharing a common JES spool, and you
Aug 9, 2002 failed to use TIMEBILD to convert those datetimes to a
common zone, your //SPIN library will fill and nothing is
output to the PDB.JOBS/STEPS/PRINT datasets, because MXG
compares the type 26 JES purge JTRTIME/JENDTIME with the
JINITIME from the type 30 (to ensure, only for restarted
jobs, that the correct (final) job termination record has
been found). When you realize this is why your SPIN
library is growing, you first need to enable the TIMEBILD
to correct future timestamps, but you can clean out old
records in the SPIN file using the old IMACTIME member,
which has always externalized the time test logic. Use
IF IN26 AND IN30_5 THEN OKFLAG=1;
to completely suppress the time check part of PDB logic.
This change only added comments to member IMACTIME.
Change 20.152 SMF 118 Subtype 70 caused INPUT STATEMENT EXCEEDED error.
VMAC119 Four MAX(nn,xxxLEN) were changed to MIN(nn,xxxLEN).
Aug 8, 2002 Three were in subtype 70 and one was found in subtype 3.
Aug 9, 2002 Also, variable IFHOMEIP was corrected in subtype 6.
Also, variables FCLREPLY and FSLREPLY were changed from
character variables to numeric variables, because they
are the 3-digit numeric FTP reply codes in RFC959.
Note that FCLREPLY is a four-byte binary value, with
'000000E2'x for decimal 252, but FSLREPLY is a three
byte EBCDIC numeric value 'F2F5F0'x for 250, so the
two fields are input with different informats and the
extra byte of FSLREPLY is skipped.
Thanks to Bob C. Allen, John Deere, USA.
Thanks to Jonathan M. Miller, John Deere, USA.
Change 20.151 This example report now shows local time rather than GMT,
ANALTCP offers new %MACRO arguments to control the reports, and
Aug 9, 2002 made minor corrections. See comments in the member.
Oct 15, 2002 Note that IBM still does not provide the Start Date in
TCP data, so with only a Start Time of Day value, the
elapsed time calculation will be wrong for multi-day
sessions.
Oct 15: Realignment of columns on TOTAL report and clean
up of comments.
Thanks to Jim Hayes, Huntington Services, USA.
Thanks to Judy Doherty, Florida Legislature, USA.
Change 20.150 -Initial support for SAS Version 9 Pre-Production. In MXG
CONFIGV9 20.04-20.05, the CONFIGV9 member had no SEQENGINE option,
MXGSASV9 so the V9 default V9SEQ engine was used. But MXG 20.06
Aug 8, 2002 added SEQENGINE=V6SEQ when it was discovered that the V9
Oct 3, 2002 sequential engine still compresses tape dataset.
Mar 1, 2003 -The JCL Procedure example member MXGSASV9 is the same as
MXGSASV8, but points to the CONFIGV9 member, just in case
you look for the MXGSASV9 JCL example.
Note: Updated Oct 3, 2002 here, without the reason:
The SEQENGINE=V6SEQ was added to CONFIGV9 because both
the V8SEQ and V9SEQ engine compress tape datasets.
SEQENGINE=V6SEQ is the only safe sequential engine.
Do NOT use the default SEQENGINE=V9SEQ.
See Newsletter FORTY-ONE, SAS Technical Notes, for V9.
Change 20.149 If you enabled TIMEBILD/VMXGTIME to change timestamps,
VMAC26J2 datasets TYPE26J2/TYPE26J3/PDB.JOBS had variables
VMAC26J3 JRDRTIME JCNVTIME JCNETIME JSTRTIME JENDTIME JPRNTIME and
Aug 8, 2002 JFINTIME incorrect if that event occurred on a system
which has a different GMT offset than the SYSTEM of the
purge event. Variable SYSTEM was used to get the GMT
offset. Now, the correct event system variable is used
(SYSREAD SYSCVRT SYSEXEC SYSOUTP) to get the GMT offset.
Change 20.148 Multiple CMODNAME='USER' CMODHEAD='USER' fields are now
UTILEXCL correctly supported, creating a single INCLUDE statement
Aug 8, 2002 for the IMACICUS member, with the sum of CMODLENG from
the multiple fields used for detection/protection logic.
Previously, multiple INCLUDEs were created, with notes
for you to remove those duplicates, but the length tests
were wrong, so the output dataset was trashed.
Thanks to Victoria Lepak, Aetna, USA.
Change 20.147 Variable PLATFORM was added to all TNG datasets so you
VMACTNG can identify the software version that created each
Aug 7, 2002 observation in each dataset.
Thanks to Gunner Jacobsen, Nordea Bank Sverige AB, SWEDEN.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.146 ASMTAPES/MXGTMNT ML-24 provides these revisions:
ASMTAPES -Fix to eliminate filling logrec due to 0E0 ABENDs:
Aug 7, 2002 the 0E0 Software ABENDs still occur when the mount is
so fast that the ASID has gone away, and MXGTMNT still
recovers, but now it prevents the unneeded and unwanted
logrec record from ever being created.
-Enhanced recovery logic. Previously, the 0E0 recovery
routine would skip all remaining devices after a 0E0.
Now it only skips the DEVNR with the 0E0.
-Fix for high CPU loop and/or high SMF record write loop
(only in ML-21 thru ML-23).
We're pretty certain this is corrected, but please
look closely and verify all is well with the CPU
time used by MXGTMNT.
-Correction for a pre-existing programming error in
memory management (a "storage leak") in the recovery
logic found while testing.
That it has taken since February until August to find a
solution to the original problem of filling logrec shows
this was a non-trivial redesign!
ML-24 doesn't solve the missed mount due to fast VTS
mounts, since some are as fast as tens of milliseconds.
But reducing the 2 second sample pop to 1/2 second can
improve the percent of mounts captured, and you can see
if there was a significant cost in the CPU time of the
MXGTMNT monitor (and let me know your results!).
However, by using the ASUMTAPE program to merge TYPETMNT
mount, TYPETALO allocate, and (always-there) TYPE21
dismount record to create the PDB.ASUMTAPE dataset, and
use it instead of the PDB.TYPETMNT dataset, then your
total mount activity will be captured; fast mounts will
just have missing/blank values for MNTTM (and other
variables only available when the mount is captured).
Depending on feedback from you as to how important these
missed mounts actually are, we may begin to investigate
if there is any alternative to sampling, but at the very
best, that would be a many-month, many tests, redesign.
Let me know your thoughts.
Thanks to my new ASMTAPES support person, who chooses to be anon.
Change 20.145 SAS Version 9 Beta prints a warning when it finds syntax
VMAC74 with a quoted string that is not followed by a blank:
Aug 6, 2002 NOTE 49-169: THE MEANING OF AN IDENTIFIER AFTER A QUOTED
STRING MAY CHANGE IN A FUTURE SAS VERSION....
Only one instance was detected in MXG, in VMAC74, where a
blank was needed before the OR in IF R74ETYPE='B'OR ....
A blank was not previously required, and even with V9,
the program compiled correctly, but the warning will let
you identify and correct any similar "unwise" syntax in
your SAS programs, so you can revise your code now, long
before SAS tightens up the syntax requirements.
Thanks to MP Welch, SPRINT, USA.
Change 20.144 MXG incorrectly read NTSMF PROCESS object records with
VMACNTSM NRDATA=20 or NRDATA=27 (NTSMF 2.2.2 with NT 4.0 or 5.0).
Aug 6, 2002 Variable CREATPID was not INPUT, causing the next three
three variables (POOLPGBY, POOLNPBY, and HANDLES) to be
wrong, and for NRDATA=20, the new READYTHR variable was
not INPUT. The IN() test for CREATPID now tests for both
20 and 27, and the IN() test for READYTHR now tests for
20 to correct these errors.
Thanks to Xiaobo Zhang, Insurance Services Office, USA.
Development stopped from August 1st thru August 5th, 2002, so Judy and I
could attend the Terrapin Station concert at Alpine Valley, Wisconsin,
the first reunion of "The Other Ones" as the remaining four originals
from "The Grateful Dead" now call themselves. Fantastic performances,
peace and love among deadheads prevailed; it was a "grate show".
Change 20.143 APAR OW55735 for the NPM/IP 1.3 and 1.4 product changes
VMACNPIP the documentation for BYTESSNT and BYTESRCV variables in
Jul 30, 2002 dataset NPMIP02; previously "ACCUMulated", now "DELTA"
values, so the DIF() logic in the _SNPIP02 Sort Macro
was removed.
Change 20.142 Addition of SORTEDBY= still failed if a dropped variable
VMXGSUM only appeared in the SUMBY= argument, because VMXGSUM
Jul 30, 2002 used the original SORTBY= string as the SORTEDBY= value.
(For example, if variable OPERATOR was not in CICSTRAN,
your TRNDCICX now failed). Code was relocated so now the
variables that actually exist are used for both SORTBY=
and SORTEDBY= values, protecting dropped variables.
Thanks to John Gebert, Office Depot, USA.
Thanks to Justin Peterson, Office Depot, USA.
Change 20.141 Support for Williams Data Systems IMPLEX Version 2.1 adds
VMACMPLX five new datasets for Protocol Monitor of FTP, NTT, EE,
Jul 26, 2002 OSPF, and MIBs. No SMF records from new version have
Feb 3, 2003 been tested. Feb 3: This change supports Version 2.3.
Change 20.140A Actual data values for SMF70CSF,SMF70ESF show they are in
VMAC7072 megabytes and not frames, so their 4096 multiplier needs
Jul 26, 2002 to be 1048576. IBM acknowledged the documentation error.
Thanks to Allan Winston, MBNA, USA.
Change 20.140 MXG 20.02-20.03 only. ALL Landmark TMON/CICS datetimes
VMACTMO2 are wrong, if your GMT Offset value is non-zero. MXG
Jul 25, 2002 Change 20.072 incorrectly assumed that TODSTAMP values
were in GMT and incorrectly added the GMTOGMTO offset to
every datetimestamp variable. Close examination of data
with non-zero GMT offset shows all timestamps are local,
except for TMMDCCLK, which is not kept nor converted, so
all of the xx=xx+GMTOGMTO; statements were removed.
-Variable TKLSTTOD was incorrectly treated as a duration,
but now is input and formatted as a datetimestamp.
-The one statement GMTOGMTO=GMTOGMTO/4096; was deleted.
Thanks to Dean Ruhle, J C Penny, USA.
Change 20.139 If your GMTOFFTM is non-zero, most datetimes in TMON/DB2
VMACTMDB will be wrong; Change 19.288 assumed all STCKs were GMT,
Jul 25, 2002 but data shows that only REGNTIME, DBKSCB/DBKSCE, and
(only for LMRKREC=:'B') HSSTCK and HDTSTP are GMT and now
only those variables have +GMTOFFTM conversion to local.
Thanks to Martin Legendre, Regie des Rentes du Quebec, CANADA.
Change 20.138 CIMSDBDS dataset had obs with DBORG='00'X that should not
VMACCIMS have been output. Those DBD segments are now documented
Jul 22, 2002 as dummy, when DB2 was called but no DB2 data collected;
previously, documented as ALLDBS Sync Point Writes. This
change no longer outputs to CIMSDBDS if DBORG='00'X AND
FLGOVERF='00'X, added to ensure that only dummy segments
are skipped.
OBSERVATION COUNT CHANGE: CIMSDBDS has fewer obs.
Note: 02Jan02: See Change 20.306 revision.
Change 20.137 The Print/Means/Contents all datasets utility VMXGPRAL
VMXGPRAL had minor corrections to eliminate a note about TITLEs,
Jul 22, 2002 and to reset OBS=MAX after its execution, and defaults
were changed so %VMXGPRAL(DDNAME=WORK,NOBS=10); now will
only PROC PRINT the first ten obs of each dataset in the
work file that had any observations, which I find quite
useful in validating datasets I've just created.
Change 20.136 The %LET DDNAME=QAPMPOLB; after MACRO _TQAPPOL should be
VMACQACS %LET DDNAME=QAPMPOLL; to read from the correct file.
Jul 18, 2002
Thanks to John Gebert, Office Depot, USA.
Change 20.135 An 0C4 ABEND reading RMFVSAM was caused by a bad branch
ASMRMFV in old code in ASMRMFV, which was exposed only if the CSR
Jul 18, 2002 Common Storage Remaining table was (unexpectedly) empty.
Jul 22, 2002 The CSRG3 table was empty because the DIAG member in
parmlib was set to OFF on one LPAR, but the correction
protects for an empty table. Thanks to Jerry for his ASM
skills, and to his management for allowing him to examine
Betty's dump to diagnose and correct the error. And an
error if only ASI was selected was also corrected.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 20.134 Variable S42DSBUF in dataset TYPE42DS was off by one bit,
VMAC42 so Buffer Type (NSR/RLS/LSR/GSR) values were incorrect.
Jul 18, 2002 The corrected decoding of VSAM Buffer Type is:
S42DSBUF=FLOOR(INPUT(S42DSFL1,&PIB.1.)/64);
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 20.133 Variable TYPETASK was added to LENGTH as $4 to protect
VMAC26J2 and to be consistent with other instances of TYPETASK.
Jul 18, 2002
Change 20.132 Support for the new NTSMF File System Collector, which is
VMACNTSM like DCOLLECT for NT! The new FS Statistics object will
Jul 17, 2002 capture the size, type, name, owner, etc., of all or some
NT disk files with the create, last access, and last use
datetimes, so you can measure and chargeback disk space.
The new dataset FSSTATS will have an observation for each
file that was captured (you can set thresholds on size,
etc., to determine if all or only some files are reported
by this new collector.
Change 20.131 Cosmetic. The conversion of variable AVAILMEK is now
VMACNTSM tested to be non-missing, to suppress the Missing Values
Jul 17, 2002 SAS Note if you do not collect that field in NTSMF data.
Thanks to Bob Gauthier, Albertsons, USA.
Change 20.130 Support for APAR PQ61349 adds SERVSTRT (HTTP Server Start
VMAC103 Datetime) to both TYPE1031 and TYPE1032 datasets, and
Jul 16, 2002 JOB and ASID to TYPE1031 dataset. When not running in
single server mode, the entity name is not unique, these
fields provide unique tokens so the subtype 1 and subtype
2 can be merged together.
Note: Jul 16, 2024. Dataset TYPE1031 is not kept as it
is created in //WORK but then combined with TYPE1032 to
create PDB.TYPE1032 and WORK.TYPE1031 and WORK.TYPE1032
are then deleted.
Change 20.129 Support for APAR OW54007, which adds SMF42ESA (UCBSTAT)
VMAC42 and SMF42EFL (UCBSFLS) variables to TYPE42AU dataset.
Jul 16, 2002
Change 20.128 -New ANALDB2K member combines DB2ACCTP Package counts with
ANALDB2K DB2ACCT Accounting variables and creates dataset DB2ACCTK
EXDB2ACB with both Package and Accounting data. Comments in the
EXDB2ACP ANALDB2K document what was discovered about Packages.
VMACDB2 -This analysis uncovered errors in MXG; observations were
Jul 16, 2002 output into DB2ACCTP and DB2ACCTB for Parallel RollUp
records that were not output in DB2ACCT (See discussion
in text of Change 19.027). The logic added to EXDB2ACC
to delete if DB2PARTY='Y' AND QWACPARR='Y' was added to
the EXDB2ACB and EXDB2ACP members so all rollups will be
deleted. This required relocation of code inside VMACDB2
so those variables would exist for those exits.
OBSERVATION COUNT CHANGE: DB2ACCTP has fewer obs.
OBSERVATION COUNT CHANGE: DB2ACCT has fewer obs.
Thanks to Nicholas Ward, Northern Territory Government, AUSTRALIA.
Change 20.127 IBM MSU Capacity Values for MultiPrise 7060 CPUs are not
FORMATS going to be provided by IBM (!!!), but Al used Cheryl's
Jul 16, 2002 input and his best guess to estimate an MSU capacity in
this update to the MXG format $MG070CP, used to create
the MSU capacities in dataset RMFINTRV, for the 7060
models H30, H50, H55, H70, and H75.
Thanks to Andrew Woods, FT Ineractive Data, ENGLAND.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.126 Variable UNITADDR was changed to DEVNR in this report
ANALCACH example, so all four digits of the address are displayed.
Jul 16, 2002
Thanks to Jon G. Whitcomb, Great Lakes Educational Loan Service, USA.
Change 20.125 The SMF type 90 subtype 32 record was not supported in
EXTY9032 the TYPE90A member (which should be used instead of the
FORMATS old TYPE90 member) and the MG090CM format was updated for
VMAC90A subtypes 27-32.
VMXGINIT
Jul 16, 2002
Thanks to Bruce Hewson, Citicorp, SINGAPORE.
Change 20.124 The automatic creation of SORTEDBY= added to VMXGSUM by
ASUM42DS Change 20.094 caused this special case to fail, because
Jul 15, 2002 one of the variables in the SORTEDBY= list was renamed in
the final data step. The code was revised to relocate
the rename to avoid the error.
Thanks to Gary Keers, Indianapolis Light & Power, USA.
Change 20.123 Unused Change Number.
Change 20.122 Variable QWACAWDR, Wait Time for Drain Lock, was wrong.
VMACDB2 The statement QWACAWDR=QWAXAWDR; was deleted, because it
Jul 14, 2002 overrode the QWACAWDR=QWAXAWDR/4096; statement a few
lines earlier that set the correct value.
Thanks to Scott Mcdonall, Southern California Edison, USA.
Change 20.121 The Read/Write variables S94CLRD0-7 and S94CLWD0-7 were
VMAC94 formatted with MGBYTES to display bytes transferred, but
Jul 14, 2002 not converted internally from frames to bytes; they are
now multiplied by 4096 to correctly contain and display.
Thanks to Thomas Heitlinger, FIDUCIA IT AG Karlsruhe, GERMANY.
Change 20.120 Cosmetic. Labels for NSPL/NSPP/NSPS frames now contain
VMACNSPY Logical Link, Physical Link, and Physical Unit to clarify
Jul 14, 2002 their contents.
Thanks to Bruce Rosenthal, Inovant, USA.
Change 20.119 Variable S94MTVCA, Maximum Age of any Volume in VCA, was
VMAC94 not converted to seconds nor format TIME8, and thus was
Jul 14, 2002 unlike SMF94VCA, Average Age of volumes in the VCA. Now
both "age" variables are displayed in units of duration.
Thanks to Frank Zemaniak, Vanguard, USA.
Thanks to Ep van der Es, Dow Chemicals, BELGIUM.
Change 20.118 Two additional optional Candle CICS segments, CANPROD2
IMACICD2 and CANPROD3 are now supported when UTILEXCL detects they
IMACICD3 have been added to your type 110 SMF records. Each is a
UTILEXCL four byte field that now creates variables CANPROD2 and
VMAC110 CANPROD3 with those data.
Jul 14, 2002
Thanks to Junaina Haji Abdul Jalil, Qantas Airways Limited, AUSTRALIA
Change 20.117 SAS V6-only: %macro compiler appears to have mis-parsed
VMXGRMFI and lost an end-of-comment */ that ended in column 72,
Jul 14, 2002 immediately prior to an imbedded old-style definition of
MACRO _KRMFINT, with a user-tailored VMXGRMFI execution.
Removing the */ and rerunning under V8 generated the same
error message. This is not the first time that parsing
MXG code with both old-style MACRO definitions and %macro
statements has gone astray when text was in column 1 or
72, but since this error does not occur with SAS V8, I
chose to EDIT end comments so column 72 and 1 are blank
in VMXGRMFI, just for future problem avoidance, and so
the program will still work with Version 6.
Thanks to Albert Nosier, Qantas Airways Limited, AUSTRALIA.
Change 20.116 Support for Type 74 subtype 7 FICON data, new datasets:
EXTY747P TYPE747P - FCD Global, Switch, and Port data
EXTY747C TYPE747C - FCT Connector data
VMAC74 TYPE74P matches RMF reports, but only ports of type CHPID
VMXGINIT (R747PTFL='20'X) appear to have real data. Other ports
Jun 25, 2002 have R747PTFL='00'X and R747PCU='0000'X, but have large
Jul 14, 2002 (and unreasonably large) counts for frames and bytes.
I chose to output any port that had non-zero frame count,
since those ports are the only ports printed by RMF.
This support will likely be enhanced/revised when more
test data has been analyzed and IBM has been contacted.
Jul 14: Labels for PCTPNCHA/DLYCHATM variables changed to
"Director" verus Channel to agree with Change 17.269
APAR OW49638 relates to an RMF problem with FCD option.
Oct 5: Without this change, 74-7 caused DOMAIN ERROR
message; R747PFPT was only input as 4 bytes.
Thanks to Scott Wiig, U.S. Bank, USA.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 20.115 Cosmetic, has been this way for a long time; the dataset
VMXGSUM label was a single double-quote (rather than blank) for
Jun 24, 2002 datasets when DSNLABEL was not used to label the dataset.
Thanks to Freddie Arie, TXU, USA.
Change 20.114 STCVSM28 dataset (new in MXG 20.03) variable STC28CLN had
VMACSTC STC28VID as its value, and STC28VID was not kept. Change
Jun 23, 2002 the second STC28CLN of each pair to STC28VID.
Variables STC27RES an STC27STP are formatted $MGSTCSL.
and $MGSTCSD. after extraneous lines were removed.
Thanks to Freddie Arie, TXU, USA.
Change 20.113 VVDS fields were not correctly decoded if the component
VMACVVDS name was exactly 44 bytes; the MXG $VARYING44. INPUT must
Jun 21, 2002 be increased to $VARYING45. (four places) because the one
byte length field has a value of 45 when the name is 44,
and that put MXG's INPUT out of alignment.
Thanks to Mike Field, Royal Bank of Scotland Group, ENGLAND.
Change 20.112 197 source files in my master directory had a '1A'x EOF
DOC character as their last byte; these stray characters are
Jun 20, 2002 created on Windows by SPF/PRO or SPFPC EDITORs, when the
FILE TERMINATOR='Y' is specified instead of ='N'. That
option is set for each profile (file suffix) on the 2nd
page of the PROFILE options. That character only causes
a problem if you upload the ASCII file to MVS, which will
create a new source line with an unprintable '3f'x hex
character that causes a syntax error, or an ASM error.
The MXG tape and CD-ROM have never contained an '1A'x,
nor do the ftp ebcnnnn/ascnnnn files (it did exist in the
ftp dirnnnn.zip file). All '1A'x were removed. This
change was included in the MXG 20.03 release.
Thanks to MP Welch, SPRINT, USA.
=======Changes thru 20.111 were in MXG 20.03 dated Jun 19, 2002=========
Change 20.111 Oracle OSDI records can only be recognized by SUBSYSID;
VMACORAC MXG's default IF SUBSYSID='OSDI' THEN DO; in VMACORAC
Jun 18, 2002 caused lots of missing values if your subsystem name(s)
were something else. This change created new _IDORACO
macro definition to externalize the test. To select your
Oracle subsytems, you would code the expression you want
to be true as the value of the _IDORACO macro:
MACRO _IDORACO
SUBSYSTEM IN ('ABCD','EFGH', :'OSD')
%
and that MACRO definition can be put in your IMACKEEP
tailoring member, or can be defined in the //SYSIN with
//SYSIN DD *
%LET MACKEEP= MACRO _IDORACO .... % ;
Note the colon before 'OSD' selects starting-with-OSD.
Thanks to Dick Triplett, Lockheed Martin, USA.
Change 20.110 New WEEKCEC annd WEEK70PR members based on TRNDCEC/70PR
WEEKCEC will build the WEEK.ASUMCEC/WEEK.ASUM70PR correctly from
WEEK70PR partial weeks data.
Jun 18, 2002
Thanks to Diane Eppestine, SBC Services, USA.
Change 20.109 ENCG3 record with no segments (ENCG3TEO=0 or ENCG3DEO=0,
VMACRMFV or both 0), caused INPUT STATEMENT EXCEEDED error. MXG
Jun 17, 2002 tests TEO/DEO, deletes record if either are zero, and
prints a message for each deleted zero segment record.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 20.108 Documentation note. Variable UOWTIME can have a value in
VMAC110 the future or the past, but not likely a valid "present"
May 23, 2002 value. UOWTIME is decoded from the first six bytes of
Jun 17, 2002 UOWID field, historically displayed as a datetime value.
Jul 25, 2002 But its only use is as a token, to match multiple CICS
MRO transactions together, or to match CICS and DB2ACCT;
so the datetime value is never used nor important.
Now, IBM often puts a valid TODSTAMP value in those six
bytes of UOWID, but I cannot change the MXG UOWTIME code,
safely, simultaneously, in all of the datasets that have
the UOWTIME variable for matching, so we are thus stuck
with a seemingly invalid value in variable UOWTIME.
But, if you see that UOWIDCHR does contain a TODSTAMP
value, (like 'B74AA17CB093'x for 07MAR2002:14:03:56.26),
you can create the actual arrival time in a new variable
UOWTOD, using the UOWIDCHR and GMTOFFxx variables:
UOWTOD=INPUT(UOWIDCHR!!'0000'X,TODSTAMP8.);
FORMAT UOWTOD DATETIME21.2;
LENGTH UOWTOD 8;
UOWTOD=UOWTOD+GMTOFFTM;
in your analysis programs. Adding the GMT Offset is
required because the UOW time is on GMT; note that MXG
has different names for the GMT offset variable.
P.S. That 'B74AA..'x UOWID value was decoded by MXG
in UOWTIME as '13OCT2001:01:56:38.49'.
Change 20.107 Syntax ARRAY CTR{54} was not accepted by SAS 6.09 at TS
TYPEIMSA TS450; CTR {54} with a blank inserted before and after
Jun 17, 2002 the "Squiggly" parentheses was required for old 6.09.
Thanks to Romain Capron, MATMUT, FRANCE.
Change 20.106 Support for G06 TANDPROC LRECL=442 record (INCOMPATIBLE)
VMACTAND eliminated the DIVIDE BY ZERO error. This record had
Jun 15, 2002 DURATM of zero in the record; MXG re-calculates duration
as DURATM=ENDTIME-STARTIME if the DURATM field is zero.
Variables starting with DEVICENM were misaligned; GNPUT,
because TMFFILL3 in the G05 record is where DEVICNM is
found in this G06 record. Six new variables are INPUT as
F1-F6 from the end of the record; they will be renamed
and labeled when I get G06 TANDPROC documentation.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Change 20.105 Enhanced with new graph of "Weighted LPAR Capacity" used,
GRAFWRKX and a new print report (PROC TABULATE) can be printed if
Jun 15, 2002 you don't have SAS/GRAPH. The tabular report will be
created if you specify TABULATE=YES. If you do have
SAS/GRAPH, specifying TABULATE=YES will create both the
graphs and the report.
The "Weighted LPAR capacity" can be important because it
is based on the defined weight of the LPAR and the number
of processors, whereas the "MVS Capacity" (PCTCPUBY
in RMFINTRV) is based solely on the number of processors
defined to an LPAR. The Weighted utilization can exceed
100%, which means simply that the LPAR is exceeding the
share of the CEC that is defined by its specified weight.
As an example, assume an LPAR with 2 CPs and a weight
of 15, on a 10 engine CEC with total weight of 100.
Then this LPAR has a weighted capacity of 1.5 CPs, and a
maximum usable capacity of 2 CPs. When the CEC is
constrained, the PCTCPUBY reported by RMFINTRV from the
MVS perspective will never exceed 1.5/2.0 or 75% busy,
but the LPAR is running at 100% of its weight-defined
capacity. However, if the CEC is not constrained, the
LPAR can use some or all of the extra 0.5 CP. RMFINTRV
could show PCTCPUBY=90%, using 1.8/2.0 but that means the
LPAR used 120 "percent of the weighted capacity", which
may be an indication that this LPAR needs more power.
Whether you are creating graphs or tabular reports, you
can create HTML and GIF datasets on an OS/390 platform to
be displayed only on OS/390, or you can create HTML/GIF
output with TRANTAB=ASCII that can only be displayed on
ASCII systems. The VMXGWRKX argument HTMLDEST=ASCII
sets ASCII as default; to create EBCDIC-displayable PDSE
members, add HTMLDEST=, i.e., a null value, to your
%VMXGWRKX(HTMLDEST=, ...); invocation.
The HTML output must be written to a PDSE on OS/390 with
RECFM=VB,LRECL=8000,BLKSIZE=8004; that PDSE dataset must
be allocated using a FILENAME statement rather than with
a DDNAME in your JCL. When %VMXGWRKX is executed the
HTML text and images are written to the PDSE library to
members named FRAMWRKX, GRAFWRKX, CONTWRKX, and GCHARTnn,
if graphs were also generated. For ASCII viewing, those
those members should be downloaded (as binary files) to
file on your ASCII system using names of:
framwrkx.html grafwrkx.html contwrkx.html gchartnn.gif
(NOTE: CASE is important. Your browser may not find them
all if the case does not match its expections.)
One either EBCDIC or ASCII systems, point your browser at
member FRAMWRKX or the FRAMWRKX.HTML file to access the
contents and the reports and graphs you created.
Obscure Note: If HTMLDEST=ASCII and TABULATE=YES, a
FORMCHAR='xxxxxxxxxxxxxxxxxxxxxxxxxx' is generated on
the PROC TABULATE, and it makes the printed report on
the SASLIST output pretty much meaningless; however,
without that FORMCHAR= operand, HTML written to the
PDSE is pretty much useless.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.104 The MXG ANALRMFR "RMF HTTP Server Report" didn't print
ANALRMFR web server name (MXG variable HOSTNAME), didn't print
VMAC103 separate reports for multiple servers on same system,
Jun 14, 2002 and had incorrect/transposed values. VMAC103 was revised
to increase variable HOSTNAME from $8 to $32; I thought
it was MVS System "host" name and limited to $8 bytes.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.103 Whether or not to comment out the BO DROPMAP NONRECOV?
ASMIMSL6 instruction for OTMA records may be something you have
Jun 13, 2002 try both ways and see which gives correct results. One
site, with IMS 6.1, found it necessary to reinstate the
comment to disable the BO DROPMAP NONRECOV? statement.
Change 20.102 Logic for CICSJOUR dataset (unidentified CICS Journal
VMAC110 segment in SMF 110 Subtype 0 record) was not correct for
Jun 12, 2002 CICS/ESA 4.1 and CICS/TS 5.1, causing the USERDATA field
to be blank. ELSE IFs were missing, and 4.1 did not set
the LENUDAT field from JCRLL.
Thanks to Len Rugen, University of Missouri, USA.
Change 20.101 Support for JES2/JES3 "Z2 Mode" (INCOMPATIBLE) to allow
ANAL30DD 200,000 jobs and 9,999,999 job numbers. MVS Technical
ANALEPMV Note 11 in MXG Newsletter FORTY-ONE provides reference to
IMACCADI the IBM Flash that lists the many exposures when your
VGETJESN enable the Z2 Mode, which changes JCTJOBID to "Jnnnnnnn"
VMAC26J2 for JOBS, etc. This change created member VGETJESN to
VMAC26J3 decodes both formats of JCTJOBID into TYPETASK & JESNR.
VMAC30 Note: CONTROL-D has only a 5-byte position for JESNR;
VMAC32 That product will require changes in their SMF
VMAC42 record to support the Z2 mode, and this note will
VMAC6 be updated when/if that product supports Z2.
VMAC91 Some additional symptoms: TYPETASK='J00', 'T00', 'S00'.
VMACBETA
VMACDALO
VMACIPAC
VMACNNAV
VMACSFTA
VMACTMNT
VMACXPSM
Jun 13, 2002
Thanks to Michael Richard, CompuWare, USA.
Change 20.100 Support for Citrix was not included in Change 19.148; the
VMACNTSM Citrix process record has an extra counter (NRDATA=22)
Jun 11, 2002 that is now supported by this change.
Thanks to Robert Gauthier, Albertsons, USA.
Change 20.099 New variable MSU4HRMX was missing in PDB.TRNDRMFI dataset
TRNDRMFI because it was calculated in the INCODE= argument, but
Jun 11, 2002 its source variable, MSU4HRAV was not in any of the other
arguments to VMXGSUM. While using KEEPIN=MSU4HRAV would
have corrected this one variable, KEEPALL=YES is better,
as it has lower overhead and protects future variables.
Thanks to Fred Kaelber, Southwestern Bell, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.098 This is "Maintenance Level, ML-23" of MXGTMNT, the Tape
ASMTAPES Mount and Tape Allocation Monitor program, which adds the
Jun 10, 2002 EXCLUDE logic so you can suppress monitoring of your VTS
devices by DEVNR, so you can avoid filling your Logrec
file with 0E0 Software ABEND records.
When a very fast VTS scratch mount occurs, MXGTMNT can
receive (and recover from) the 0E0 ABEND (because the
job had already terminated before its next sample),
but our friends at IBM still write a Logrec record for
each 0E0 recovery, and MXGTMNT has filled Logrec with
over 25,000 records in one day, causing a B37 in EREP!
After four months research with IBM'd trying to use an
STOKEN to prevent the logrec record, IBM now says that
only an FRR (Functional Recovery Routine) can suppress
the Logrec record, and an FRR is not trivial to add.
This change is an interim solution, pending the FRR code.
To exclude DEVNRs from MXGTMNT, you will need to add the
optional //EXCLUDE DD statement (FB,LRECL=80) to the JCL
for the MXGTMNT Started Task that points to the file that
contains your exclude control statements. The new logic
skips over UCBs that are both Tape Devices AND that are
specified in the EXCLUDE statements. Single DEVNRs
and/or ranges of DEVNRs are supported in this syntax:
Device Numbers can be specified like this, separated from
each other by blanks:
XXX /* ONE 3-DIGIT DEVICE NUMBER */
XXXX /* ONE 4-DIGIT DEVICE NUMBER */
XXX-XXX /* A RANGE OF 3-DIGIT DEVICE NUMBERS */
XXXX-XXXX /* A RANGE OF 4-DIGIT DEVICE NUMBERS */
Any combination of the above can be used, separated by
blanks in columns 1 thru 80 on the statements read from
the //EXCLUDE DD. Characters in device numbers must be
Hex Digits, 0-9 and/or A-F.
These Device number Specifications are NOT valid:
XX-XX
X-XX
XX-X
X-X
XXX-XX
XX-XXX
X
XX
Comments may NOT appear on the same statement as a device
number to exclude.
Each device number or device number range must be
followed by at least one blank.
In addition to adding the FRR to ASMTAPES/MXGTMNT monitor
program to ultimately monitor VTS devices without 0E0s, I
hope to enhance the ASUMTAPE program (that creates the
PDB.ASUMTAPE dataset from the MXGTMNT records and IBM's
SMF 21 dismount record) first by adding the STK VTC SMF
data, and second with the IBM SMF 94 data to provide
additional timestamps and values from those records into
an enhanced PDB.ASUMTAPE dataset. The ASUMTAPE changes
will hopefully be completed by the end of Summer.
17Jun02: ASMTAPES is now being enhanced, and an FRR is
not going to be required, so the ML-24 that will monitor
VTS devices (catching those mounts longer that 2 seconds,
but without writing 0E0 messages to logrec) should be
available very soon.
Change 20.097 Another instance of DOMAIN ERROR was caused by IBM's mis-
VMAC91 documentation of fields SMF91SDI and SMF91SDO as long
Jun 10, 2002 floating point values, but the data values in the subtype
3 were '0000000000000002'x and '000000B600000070'x, which
are clearly not floating point values. The second value
is 728GB is highly suspect, as all of the other counters
are zero in this particular record. A problem will be
opened with IBM and this note will be updated when they
respond, but the two inputs for SDI and SDO are now PIB
instead of RB, which will eliminate the DOMAIN ERROR.
See NEWSLETTER FORTY-ONE, SAS TECHNICAL NOTE 7.
Thanks to Dan Doan, Verizon, USA.
Change 20.096 TYPE73 observations for SMF73ACR='CFS' (Coupling Facility
VMAC73 Channels) had PCHANBY missing, but RMF Reports showed non
Jun 7, 2002 zero values for "Total" Channel Utilization (but had dash
for the "Partition" percent). The records had SMF73CMG=1
and thus I calculated PCHANBY and PNCHANBY only if the
SMF73PTI (measurement interval) was non-zero. But in the
'CFS' records, SMF73PTI, PBY, PTI, PUT, and TUT are all
zero. In looking in detail, it turns out that for the
'CFS' channel, the old SMF73BSY and SMF73STP fields are
what IBM is using to calculate PCHANBY, and the PNCHANBY
file is not calculatable for the CFS channels. MXG now
uses the PTI-based fields if present, but will use the
original BSY/STP calculation when PTI is zero.
Thanks to John Gebert, Office Depot, USA.
Change 20.095 MXG did not correctly input the GMT Offset value, causing
VMACTMDB GMTOFFTM and all timestamps were incorrect, if your GMT
Jun 6, 2002 offset was non-zero. The timestamps printed as astricks.
Thanks to Paul van den Brink, Fortis Bank, THE NETHERLANDS.
Change 20.094 A combination of circumstances caused NOT SORTED error in
MONTHBLS dataset TYPE30OM, but MXG Change 19.172, that increased
MONTHBLD the stored length of many numeric variables from 4 to 5
MONTHBL3 bytes, was the underlying culprit:
WEEKBLD - TYPE30OM is unique; it's BY list has integer numeric
WEEKBL3 variables OMVSOSI, Session ID and OMVSOPI, Process ID.
WEEKBLDT Most variables in BY lists are character variables.
WEEKBL3T - The problem occurs only when both OMVS/USS and OS/390
Jun 4, 2002 have stayed up a long time, allowing ID number value in
VMXGSUM OMVSOSI/OMVSOPI to exceed 16,217,666. Only integers of
Jun 18, 2002 that value can be truncated when stored in 4 bytes.
VMXG2DTE In this case OMVSOSI and OMVSOPI were equal and large!
Jun 13, 2002 - The problem occurs only when the WEEK1 DD, which is the
ASUM78CF first libref in the SET statement, points to an old PDB
Jun 14, 2002 that was built by MXG earlier than 19.10. That old PDB
had the original, sort, 4-byte length, and the first
dataset in the SET statement is used by SAS to define
the stored length of the output MONTH.TYPE30OM dataset.
It is better that the WEEK1 DD points to the most
recently build PDB, created by the new MXG version,
so that all new changes (like the longer length) are
seen first to set the definitions.
And it is best to install a new MXG Version on
the first day of your week; if you build WEEKLYs
on Monday morning, then install the new version
Monday afternoon when all is done, so that all of
next week's PDBs are built with the same version.
With the MXG change and those circumstances, the old PDB
4-byte definition was used, causing the new 5-byte values
to be truncated to smaller numeric values, which SAS saw
as an out-of-sequence error in the sort-order validation
that is invoked when there is a BY statement in a DATA
step. The simple correction is to point WEEK1 at the new
PDB, so that the new attributes are seen first and used.
Or you could add a LENGTH OMVSOSI OMVSOPI 5; statement
between the DATA statement and the SET statement.
One other alternative is to remove the BY statement,
since no reports in MXG demand that the TYPE30OM dataset
is in sort order.
When you have DATA ONE; SET TWO THREE FOUR; BY A B C;
the BY statement causes the output dataset to be built
in the A B C sort order of the input datasets, without
invoking a PROC SORT. When there is no BY statement,
dataset ONE will be the concatenation of TWO, THREE,
and FOUR, and won't be sorted. The big advantage of
having the dataset sorted is so you don't have to SORT
in report program that exploit the same sort order.
And if you should invoke PROC SORT to sort an already
sorted dataset, PROC SORT recognizes sorted data and
will bypass an unnecessary sort, saving lots of time
with big datasets.
That was the end of the original text, and there had been
no MXG code changed, until after I added this note:
When you create a dataset with PROC SORT, SAS stores
the BY list in the directory of that dataset, but when
you create an output dataset with a DATA step, you
need to use the SORTEDBY= dataset option to tell SAS
that the dataset is created in that SORT order, so
that subsequent PROC SORTs can be bypassed by SAS.
I then looked at my code; while SORTEDBY= is used in the
BUILDPDB code for datasets created by DATA steps instead
of by PROC SORT, I discovered I had never implemented the
SORTEDBY= dataset option in the weekly and monthly code.
The actual code change made by this MXG Change was to add
SORTEDBY= to each DATA step in the listed MONTHxxx and
WEEKxxxx members, so that SAS can now recognize and
bypass unnecessary sorts of the weekly and monthly PDBs.
-VMXGSUM was revised to set the SORTEDBY= parameter when
it creates its output dataset, whether it uses a DATA
step, or a PROC MEANS to create the dataset. This change
exposed an unanticipated option in ASUM78CF's invocation
of VMXGSUM, which had the dataset options (LABEL=...) in
its OUTPUT= argument, which previously worked but was not
supported (instead, the DSNLABEL= argument is provided in
VMXGSUM for the output dataset label option). While the
ASUM78CF member was revised to use DSNLABEL, VMXGSUM was
revised to detect the existence of a start paren in the
OUTDATA= and will now suppress the addition of SORTEDBY=
so your existing ASUM78CF won't fail. A later revision
will actually parse to the end-paren and insert the
SORTEDBY= list inside your dataset options!
-VMXGSUM revised to protect DATETIME in a SUMBY= list by
moving the DATETIME= list into the SORTEDBY= list.
This will be further enhanced in the next version to move
the SORTEDBY string inside the parens, if possible, but
this eliminated the abend caused by ASUM78CF syntax.
Obscure Note: In this revision it was noticed that
VMXGSUM could ABEND with INVALID DATASET OPTIONS:
- 1. you use dataset options in the OUTDATA=, and
- 2. the final data setp is flagged as unneeded
- 3. PROC MEANS is used to conditionally drop vars:
This happens only if all these are true:
no NORMx, ERASEOUT NE NO, no OUTCODE statement,
no FREQ, no INTERVAL, no NEWSHIFT, SAS V8+.
Has not occurred, it is likely no one is using dataset
options in the OUTDATA= argument, but now documented.
Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
Change 20.093 Variables VVROPIND, SMF60FNC, VVRAMAT3 and VVRTPEXT were
VMAC60 not kept in dataset TYPE60. Those variables and VVRSMSFG
Jun 3, 2002 are now input as $CHAR1 instead of $EBCDIC1 (which has no
impact when MXG is executed on MVS, but is required for
hex-containing variables if MXG is executed on ASCII);
all five variables are now formatted $HEX2.
Thanks to Michael E. Friske, Fidelity Systems, USA.
Change 20.092 Major enhancement for TNG support for new Platforms, new
EXTAI006 Objects, and new Variables, plus logic revisions to cover
EXTAI007 new idiosyncrasies in the TNG performance cube data:
EXTAI008 -Platform tests for PLATFORM=:'SOL' and PLATFORM=:'AIX'
EXTAI009 should eliminate dependency on specific platform name.
EXTAI010 -Instance counts were increased where new instances found.
EXTAI011 -Algorithm for text length in the CAPCM Header was found
EXTAI012 to be inconsistent with text length in other records,
EXTNT021 which caused the DOMAIN name to be incorrect; whereas the
EXTNT022 base-26 syntax is used in data records (i.e., '10'=36),
EXTNT023 the Header algorithm has '10'= 10!
EXTNT024 Note: Always look to see if any observations were output
EXTNT025 in the UNKNOWN dataset, and send the performance
EXTNT026 cube to support@mxg.com if there are any. If the
EXTNT027 last metric for an object is UNKNOWN, there will be
EXTNT028 zero observations output for that object.
EXTNT029 The complete list of TNG Objects now supported:
EXTNT030 PLATFORM OBJECT MAXIMUM MAXIMUM MXG
EXTNT031 NAME INSTANCE VARIABLES DATASET
EXTNT032
EXTNT033 AIX BUFFER 1 8 AI001
FORMATS AIX CPU 1 5 AI002
IMACTNG AIX PAGING 1 4 AI003
TYPETNG AIX QUEUES 1 4 AI004
VMACTNG AIX SWAPPING 1 1 AI005
VMXGINIT AIX IPC 1 2 AI006
May 27, 2002 AIX SYSTEM-CALLS 1 7 AI007
Jun 3, 2002 AIX FILE-ACCESS 1 3 AI008
AIX FILESYSTEM 1 2 AI009
AIX NETWORK 1 4 AI010
AIX TABLES 1 4 AI011
AIX TERMINAL 1 6 AI012
CIS2500 CISCO 7 130 C2001
CIS2500 MIB-2 34 89 C2002
CIS7500 CISCO 24 166 C7001
CIS7500 MIB-2 34 89 C7002
NT BROWSER 1 20 NT001
NT CACHE 1 27 NT002
NT ICMP 1 27 NT003
NT IP 1 17 NT004
NT LOGICALDISK 5 21 NT005
NT MEMORY 1 27 NT006
NT NBT CONNECTION 8 3 NT007
NT NETBEUI 2 39 NT008
NT NETBEUI RESOURCE 13 3 NT009
NT NETWORK INTERFACE 3 17 NT010
NT OBJECTS 1 6 NT011
NT PAGING FILE 2 2 NT012
NT PHYSICALDISK 3 19 NT013
NT PROCESSOR 2 10 NT014
NT REDIRECTOR 1 37 NT015
NT SERVER 1 26 NT016
NT SERVER WORK QUEUES 3 17 NT017
NT SYSTEM 1 25 NT018
NT TCP 1 9 NT019
NT UDP 1 5 NT020
NT NWLINK IPX 1 38 NT021
NT NWLINK NETBIOS 1 38 NT022
NT NWLINK SPX 1 38 NT023
NT SQLSERVER:ACCESS MET 1 19 NT024
NT SQLSERVER:BUFFER MAN 1 16 NT025
NT SQLSERVER:CACHE MANA 6 4 NT026
NT SQLSERVER:DATABASES 7 21 NT027
NT SQLSERVER:GENERAL ST 1 3 NT028
NT SQLSERVER:LATCHES 1 3 NT029
NT SQLSERVER:LOCKS 6 6 NT030
NT SQLSERVER:MEMORY MAN 1 14 NT031
NT SQLSERVER:SQL STATIS 1 7 NT032
NT SQLSERVER:USER SETTA 10 1 NT033
SOL BUFFER 1 8 SO001
SOL CPU 1 5 SO002
SOL DISK 3 6 SO003
SOL FILE-ACCESS 1 3 SO004
SOL FILESYSTEM 2 3 SO005
SOL IPC 1 2 SO006
SOL KERNEL MEMORY ALLOC 1 8 SO007
SOL MEMORY 1 2 SO008
SOL NETWORK 5 5 SO009
SOL PAGING 1 11 SO010
SOL QUEUES 1 4 SO011
SOL SWAPPING 1 5 SO012
SOL SYSTEM-CALLS 1 7 SO013
SOL TABLES 1 7 SO014
SOL TERMINAL 1 6 SO015
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.091 Support for IBM AIX PTX (Performance ToolBox) adds over
VMACAIX 100 new fields, and additional variable name sequences:
May 24, 2002 LABEL STARTS WITH BECOMES VARIABLES NAMED
CPU/ AIXCPU01-AIXCPU21
DISK/ AIXDIS01-AIXDIS56
FS/ AIXFS01 -AIXFS03
IP/NETIF AIXIP01- AIXIP49
LAN/ AIXLAN01-AIXLAN16
MEM/ AIXMEM01-AIXMEM15
NFS/ AIXNFS01-AIXNFS02
PAGSP/ AIXPAG01-AIXPAG05
PROC/ AIXPRO01-AIXPRO02
RPC/ AIXRPC01-AIXRPC04
SYS/ (SYSCALL,SYSIO) AIXSYS01-AIXSYS07
TCP/ AIXTCP01-AIXTCP06
UDP/ AIXUDP01-AIXUDP02
Thanks to Glenn Bowman, Wakefern, USA
Change 20.090 Unknown ESS keys were printed on the SAS log correctly,
IMAC6ESS but MXG did not skip over second and subsequent parms if
May 23, 2002 a key had GEPARMNR GT 1 parameter per key value. The
protection logic now skips correctly and prints the keys
found, but only in the first SMF type 6 record found.
The second part of this change will be the actual decode
GEPARMKY=0021x,2022x,002E segments, as soon as I can find
the new IBM documentation, which ain't easy for ESS data.
Thanks to Roman Jost, ERGO Integration, NORWAY.
Change 20.089 Variable MSU72 is created for each observation in TYPE72
VMAC7072 and TYPE72GO, using the total CPUTM captured:
May 23, 2002 MSU72=CPUTM*SU_SEC/1000000;
Thanks to Jim S. Horne's posting to MXG-L, Lowe's Companies, USA.
Change 20.088 Support for new Subtypes 27, 28, and 29 for STK HSC/VSM
EXSTCV27 user SMF record create these three new datasets:
EXSTCV28
EXSTCV29 dddddd Dataset Description
FORMATS STCV27 STCVSM27 VTV Scratch Status
IMACSTC STCV28 STCVSM28 VTV Replication
VMACSTC STCV29 STCVSM29 VTV and MVS Unlink Event
VMXGINIT
May 20, 2002
Thanks to Harold Radalin, Reader's Digest, USA.
Change 20.087 Internal macro definition of MACRO _VTYTPMX was added
VMACTPMX as described in the Change 18.338 that had not yet been
May 20, 2002 applied to this member.
Thanks to Lawrence Jermyn, Fidelity, USA.
Change 20.086 New variable EXECAPPL, hopefully the "execution" APPLID
VMXGUOW of the CICS Unit-of-Work observation in PDB.ASUMUOW, will
May 15, 2002 contain the APPLID name of the first region found with a
May 20, 2002 TRANNAME starting with CSxx (expected CSMI for the mirror
transaction). This should be the first AOR that handles
the Unit of Work, after the TOR. If you need more logic
to store an "APPLID" in variable EXECAPPL for a UOW that
uses many APPLIDs, new temp PATH1-PATH10 and TRAN1-TRAN10
variables are created with first ten APPLIDs (PATHs) and
corresponding first ten TRANNAMEs, so you could use them
in your "Case" logic to tailor VMXGUOW. The examples of
Case 1 and 2 were revised and tested, Case 3 example was
deleted.
Thanks to Ron Root, Texas Comptroller of Public Accounts, USA
Change 20.085 Type 119 subtype 3 records caused INVALID DATA message
VMAC119 and were not correctly decoded, because no test records
May 15, 2002 were available. Dataset TYP11903 is now validated.
Thanks to Keith Jefferson, Citicorp, USA.
Change 20.084 Continued picking away at flaws; if you EXCLUDEd WTTCIOTM
UTILEXCL (Terminal Control Wait), UTILEXCL did not create the code
May 15, 2002 statement "IRESPTM=ELAPSTM-WTTCIOTM;" in the IMACEXCL.
May 22, 2002 Now "IRESTPM=ELAPSTM;" is coded if WTTCIOTM is EXCLUDEd,
and since WTTCIOTM is normally zero except in the TOR
records, you should see little difference in IRESPTM.
22May02: Typo 'PSB SCHL' was changed to 'PSB SCHD',
to fix error message with IMS DL/I optional segment.
Thanks to Pat Curren, SuperValu Inc, USA.
Thanks to Richard S. Ralston, Whirlpool Corp. USA.
Change 20.083 Type 79 subtype 12 PIB fields were input as RB, causing
VMAC79 invalid values (and a DOMAIN ERROR on MVS), and new CMG
May 14, 2002 data was not DIF()'d, nor reset. Logic was revised.
Thanks to Dan Doan, Verizon, USA.
=======Changes thru 20.082 were in MXG 20.02 dated May 6, 2002=========
Change 20.082 Support for z/OS 1.3 (COMPATIBLE, except for SMF 42).
VMAC30 IBM changes to SMF records in z/OS 1.3 were compatibly
VMAC42 made (no data inserted), but MXG logic for SMF type 42
May 6, 2002 did ot correctly handle the IBM changes.
May 7, 2002 -New data added in SMF type 30 records:
New CPUCEPTM added to TYPE30_V,TYPE30_4,TYPE30_5,TYPE30_6
dataset; records the CPU time for an address space while
it was Enqueue Promoted, i.e., getting ERV Service Units
at high priority because it owned an enqueued resource,
and had been swapped out.
-New data added in SMF type 42 records:
New variables in dataset TYPE42D1 from subtype 16:
SMF42GAP='DATA CLASS NAME'.
SMF42GAJ='GT 4K CF*CACHE*ACTIVE*STATUS'
Values: blank or GT4ACTIVE, GT4KNOTACT, ALL,
UPDATESONLY, or NONE.
SMF42GRA='RE-DOS'
SMF42GRB='RECURSIVE*RE-DOS'
SMF42GRC='BMF*WRITES'
SMF42GRD='SCM*READ*REQUESTS'
SMF42GRE='SCM*READ REQUEST*CASTOUT*CONTENTIONS'
SMF42GRG='RE-DO*PERCENTAGE'
SMF42GRH='RECURSIVE*RE-DO*PERCENTAGE'
SMF42GRI='SCM*CASTOUT*LOCK*PERCENTAGE'
SMF42GZ8='SMS*DIRECT*WEIGHT'
SMF42GZ9='SMS*SEQUENTIAL*WEIGHT'
SMF42GBN='WLM*SERVICE*CLASS*NAME'
SMF42GBO='WLM*REPORT*CLASS*NAME'
SMF42GBP='SMS*DATA*CLASS*NAME'
-New variables in dataset TYPE42D2 from subtype 16:
SMF42GRL='RE-DOS'
SMF42GRM='RECURSIVE*RE-DOS'
SMF42GRN='BMF*WRITES'
SMF42GRO='SCM*READ*REQUESTS'
SMF42GRP='SCM*READ REQUEST*CASTOUT*CONTENTIONS'
SMF42GRR='RE-DO*PERCENTAGE'
SMF42GRS='RECURSIVE*RE-DO*PERCENTAGE'
SMF42GRT='SCM*CASTOUT*LOCK*PERCENTAGE'
-New variables in dataset TYPE42X1 from subtype 19:
SMF42JN7='WRITE*REQUEST*SYSPLEX*TOTAL'
SMF42JTA='AVG SCM*READ REQUEST*CASTOUT'
SMF42JTB='TOT SCM*READ REQUEST*CASTOUT'
SMF42JTC='AVG SCM*READ REQUEST'
SMF42JTD='TOT SCM*READ REQUEST'
SMF42JTE='CURR PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTF='LOW PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTG='HIGH PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTH='AVG PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTI='AVG*RE-DOS'
SMF42JTJ='TOTAL*RE-DOS'
SMF42JTK='AVG*RECURSIVE*RE-DOS'
SMF42JTL='TOTAL*RECURSIVE*RE-DOS'
SMF42JTM='CURR PCT*RE-DOS'
SMF42JTN='LOW PCT*RE-DOS'
SMF42JTO='HIGH PCT*RE-DOS'
SMF42JTP='AVG PCT*RE-DOS'
SMF42JTQ='CURR PCT*RECURSIVE*RE-DOS'
SMF42JTR='LOW PCT*RECURSIVE*RE-DOS'
SMF42JTS='HIGH PCT*RECURSIVE*RE-DOS'
SMF42JTT='AVG PCT*RECURSIVE*RE-DOS'
SMF42JUA='AVG*INTERVALS*PROCESSED*ACCELERATED'
SMF42JUB='TOT*INTERVALS*PROCESSED*ACCELERATED'
-New variables in dataset TYPE42X2 from subtype 19:
SMF42JP2='INTERVALS*PROCESSED*ACCELERATED'
SMF42JSA='SCM*READ REQUEST*CASTOUT'
SMF42JSB='SCM*READ REQUEST'
SMF42JSC='CURR PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSD='LOW PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSE='HIGH PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSF='AVG PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSG='RE-DOS'
SMF42JSH='CURR PCT*RE-DOS'
SMF42JSI='LOW PCT*RE-DOS'
SMF42JSJ='HIGH PCT*RE-DOS'
SMF42JSK='AVG PCT*RE-DOS'
SMF42JSL='RECURSIVE*RE-DOS'
SMF42JSM='CURR PCT*RECURSIVE*RE-DOS'
SMF42JSN='LOW PCT*RECURSIVE*RE-DOS'
SMF42JSO='HIGH PCT*RECURSIVE*RE-DOS'
SMF42JSP='AVG PCT*RECURSIVE*RE-DOS'
-New SMF 42 subtype 20 is written when STOW INITIALIZE IS
used to delete all members of a PDSE. The new TYPE4220
dataset contains variables:
SMF42KJB='JOB NAME*STC OR*TSO USERID*WHO STOW-D'
SMF42KST='STEP*NAME'
SMF42KPR='PROC*NAME'
SMF42KDS='DATA SET NAME'
SMF42KVS='VOLSER'
-New SMF 42 subtype 21 is written when a member of a PDS
or a PDSE is deleted, with new dataset TYPE4221 vars:
SMF42LJB='JOB NAME*STC OR*TSO USERID*WHO STOW-D'
SMF42LST='STEP*NAME'
SMF42LPR='PROC*NAME'
SMF42LDS='DATA SET NAME'
SMF42LVS='VOLSER'
SMF42LNL='LENGTH*OF MEMBER*NAME'
SMF42LFL='ALIASES*EXCLUDED*DUE TO*RECORD LENGTH'
SMF42LMN='MEMBER*NAME*THAT WAS*DELETED'
-New SMF 42 subtype 21 is also written with the Alias
Names that were deleted because its primary member
name was deleted. New variable description says it all:
SMF42LAN='ALIAS NAME*DELETED IN*SYMPATHY'
-Status:
This change has not been validated with 1.3 data.
IBM additions to RMF 79 Channel data, and additions to
SMF 99 (License Manager) won't be written until I have
test data records.
Change 20.081 z/VM MONWRITE Control Records with DATABYTE=0 caused the
VMACVMXA "WHOOPS ..." error and MXG stopped reading records. IBMs
May 4, 2002 MONWRITE now creates an "E" Event Control Record with
May 14, 2002 DATABYTE=0 that is followed by a data record that MXG did
not expect, since the control record said there were zero
bytes following! Pairs of bad records were found 4 times
in 900 intervals; each bad pair was immediately followed
by a valid pair of an Event Control Record (DATABYTE=20)
and an Event data record with one 20 byte (1.11) segment.
Knowing what IBM writes, this change detects and deletes
both records, and prints a one-line message when any of
these bad DATABYTE=0 records are found and deleted. If
IBM ever corrects these records, it will be noted here.
May 14: IF DEBUG=. THEN DEBUG=-99; changed to DEBUG=.;
Thanks to Pat Curren, SuperValu Inc, USA.
Thanks to Jean Nelson, SuperValu, USA.
Change 20.080 The SMF94VLS (Library Sequence Number) is no longer a
ANAL94 number, but now contains characters ('B1031'), causing
VMAC94 SMF94VLS to have a missing value; and ANAL94 produced
May 2, 2002 no reports if you had selected a Library number. Since
Aug 11, 2002 SMF94VLS is defined as a numeric variable, changing it
to a character variable could cause execution errors in
your perfectly running reports, so new variable SMF94VLC
with LABEL='LIBRARY*SEQUENCE*NUMBER*CHARACTER' is created
in dataset TYPE94, and the ANAL94 program was changed so
you can use the value in your SMF94VLC to select reports
for a specific Library.
Thanks to Oliver H. Richter, American Management Systems, USA.
Change 20.079 Cosmetic. When there is a mismatch between 70s and 72s
VMXGRMFI in building RMFINTRV, the MXG note was enhanced to print
May 2, 2002 the IN71 IN73 IN74 IN75 and IN78 status variables in
addition to the IN70 and IN72, for diagnostic help.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.078 AS400 Version 4.5.0 (but not 5.1.0) had INVALID DATA FOR
VMACQACS variable SYSJDUM in the QAPMSYST dataset because fields
May 2, 2002 SYSDBC and SYSSWC were inserted by the earlier '4.5.0'
May 5, 2002 version. Change the IF ASLEVEL GE '5.1.0' THEN INPUT...
before SYSDBC/SYSSWC to QIF ASLEVEL GE '4.5.0' THEN ....
And PCTCPSBY was wrong; the SYSDBC was changed to SYSSWC
in its equation. And Change 20.004 needs to be applied
to the other two CPU-time-variables JBEDBC and JBTDBC in
both QAPMJOBL and QAPMJOBM datasets; non-zero data values
now show they too are &PD.8.6 rather than documented 8.3.
Thanks to Andre Baltimore, Unigroup Inc. USA.
Change 20.077 If you enabled TIMEBILD/VMXGTIME to change timestamps,
VMAC78 TYPE78 data had incorrect STARTIME; it was converted
May 2, 2002 twice. Remove the STARTIME in the second %VMXGTIME
invocation.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.076 The JCL Procedure examples MXGSAS and MXGSASV8 contained
MXGSAS DISP=(MOD,PASS) for //NULLPDS, as does SAS defaults, but
MXGSASV8 the CA Job Scheduler CA-11 product regards any step with
May 2, 2002 DISP=PASS to be non-restartable (because it cannot tell
JCLTEST6 if that dataset will be referred to in a later step). The
JCLTEST8 DISP=(SHR,PASS) were changed to DISP=SHR, and the NULLPDS
Sep 7, 2002 DD was changed from MOD,PASS to now MOD,DELETE in May.
Updated Sep 7: MOD,DELETE failed in second execution in
SMS site, 213-04. Change back to MOD,PASS avoided that
SMS-induced error, but that site did not have CA-11.
Changing MOD,PASS to NEW,DELETE resolves both the CA-11
and SMS errors, and there is no real need for MOD anymore
(it's a hold-over from pre-SMS days to protect if a real
dataset already existed that would have failed with NEW
but now that all datasets must be cataloged, MOD is not
needed here).
Bottom line:
DISP=(NEW,DELETE) for NULLPDS works for SMS and CA-11
and DISP=SHR instead of DISP=(SHR,PASS) works for CA-11.
Thanks to J.C. Houck, Bank of America, USA.
Thanks to Jesse Gonzales, The Gap, USA.
Thanks to Art Cuneo, Health Care Services Corporation, USA.
Change 20.075 Variable NRTIMES was created with PROC MEANS NOPRINT with
ANALPROG OUTPUT OUT=SUMS N=NRTIMES; VARIABLES CPUTCBTM; but the
May 1, 2002 LABEL for NRTIMES in the output dataset is the label of
the CPUTCBTM variable, which I thought was a SAS error.
However, documentation of V8 INHERIT option does state:
By default the statistics in the output data set
automatically inherit the analysis variable's format
and label. However, statistics computed for N, NMISS,
SUMWGT, USS, CSS, VAR, CV, T, PROBT, SKEWNESS, and
KURTOSIS do not inherit the analysis variable's format
because this format may be invalid.
so INHERIT is working as designed, even though I still
think the LABELs for those listed stats also should not
be inherited. In any event, ANALPROG was re-written to
use %VMXGSUM and to correctly label NRTIMES.
Thanks to Mark McCallum, EDS, USA.
Change 20.074 Support for multiple CICS Versions with Exclude added.
UTILEXCL The IMACEXCL created by UTILEXCL failed with syntax error
Apr 30, 2002 if APPLID had multiple dictionary records from different
releases of CICS. This change supports multiple releases
for the same APPLID, by creating a code block for each
APPLID and CICS version:
ELSE IF APPLID='CICSTNW1' AND SMFPSRVR=53 THEN DO; ...
ELSE IF APPLID='CICSTNW1' AND SMFPSRVR=62 THEN DO; ...
And IMACEXCL will print an ERROR message on the SAS log
(as it reads your SMF data), if it finds a new version
for a CICS APPLID that is already in your list of regions
with excluded fields. Thus to support two CICS Versions,
you only have to run the _BLDDICT with the new version's
dictionary records to create a new PDB.CICSDICT, combine
that with your old PDB.CICSDICT from the old version, and
run _BLDEXCL to create an IMACEXCL that is aware of both
CICS version's excluded variables.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 20.073 Under ASCII only, a latent 180 syntax error was triggered
VMXGRMFI and corrected in the macro logic that failed to expand a
Apr 29, 2002 macro variable J due to a missing ampersand.
Thanks to John G. Talafous, Timken, USA.
Change 20.072 Support for TMON/CICS TCE 2.1 (INCOMPATIBLE). Landmark
EXMONPA (now Allen Services) completely restructured all records,
EXMONPI and even changed the version from numeric to character!
EXMONTF HWM/maximum values were removed from some datasets, some
EXMONTFF variables will have missing values. New fields were added
EXMONTJ to many existing datasets, and new records are supported.
EXMONTK Since every record and subtype was touched, MXG support
EXMONTKM for TCE was enhanced with all the MXG bells and whistles:
EXMONTKP duration variables are formatted TIME13.3, storage and
EXMONTN byte-containing variables are formatted MGBYTES, etc., to
EXMONTO both "print-pretty", and to document what data is stored
EXMONTOS in which of these hundreds of new variables.
IMACTMO2 The new PA/PI records capture IBM CICS Monitor Facility
VMACTMO2 data at the transaction and interval level, and the new
VMXGINIT TK Dispatcher Record provides CPU time for each CICS TCB.
Status: TA,TD,TI,TP,TR,TS, TX, and T2 records were all
Apr 28, 2002 changed, some new variables, some dropped.
May 1, 2002 TF was so changed that new MONITF/MONITFF datasets are
May 5, 2002 created for TF records with Release 2.1.
New PI,PA records create MONIPI/MONIPA with massive
numbers of new variables.
New TJ for Java, TN for Enqueues, and TO records for
Sockets create MONITJ, MONITN, MONITO and MONITOS, for
a total of 11 new datasets and hundreds of variables.
PTF TCE3400-21 changes were added May 5.
This complete rewrite took three full days to write and
validate (thanks to a full suite of test records from
Landmark, and nearly accurate documentation); over 3000
lines of code were added by this change.
Thanks to Martin Jensen, JyskeBank, DENMARK.
Change 20.071 The JCL example (Testing MXG under SAS Version 8) still
JCLTEST8 MXGSAS instead of MXGSASV8 as its JCL procedure name.
Apr 28, 2002 Also, the example suggests REGION=80M for installations
that restrict the use of REGION=0M.
Thanks to Donald J. Likens, AON, USA.
Change 20.070 New IBM Product, NPM/IP user SMF record, is supported.
EXNPIP01 Two datasets are created from the two subtypes:
EXNPIP02 DDDDDD Dataset Description
IMACAAAA NPIP01 NPMIP01 Performance Record - each observation
IMACNPIP measures the round trip response time
TYPENPIP for one of four packet sizes to a
TYPSNPIP specific IP address.
VMACNPIP NPIP02 NPMIP02 Workload Record - accumulated bytes
VMXGINIT from an application to an ip address.
Apr 28, 2002 Records must be deaccumulated (use
TYPSNPIP or _SNPIP in your EXPDBOUT)
to create interval duration and bytes
sent/received during each interval.
To minimize the size of PDB.NPMIP02,
observations are created only for
intervals with non-zero bytes.
Many duplicate SMF records were
found, but MXG logic deletes them;
IBM will be contacted to fix or to
explain their duplicate records:
Subtype 2 records in SMF: 29762
duplicate records removed: (14407)
unique subtype 2 records: 15265
MXG obs in PDB.NPMIP02: 6963
Updated 2Jan03: APAR OW56033 reports duplicate records
were cut by the "AESTNETS" task's AEST044 program, and
provides the PTF to correct that error.
Thanks to Sue Kemper, Universal Music Group, USA.
Change 20.069 Support for APARs OW52227 and OW51848 for z/OS 1.2, adds:
VMAC7072 -New variables to TYPE72GO dataset (type 72 subtype 3):
Apr 26, 2002 New wait state sample counts (SSL Thread, Regular Thread,
Registration to Work Table, R723RWST/RWRT/RWWR), and new
"Active Application State" sample count, R723RAPP, that
indicates there is a program executing on behalf of a
work request, from the perspective of the WLM (this does
not mean that the program is active from the BCP's
perspective), so RMF reports can distinguish between
active subsystem and active application; from APAR text:
Before this APAR, state samples were reported as percent
of response time, calculated when a transaction ends,
which could cause values over 100% when samples for long
running transactions were included that did not complete
in the RMF interval. With OW52227, the problem is solved
by showing the single states as percentages of total
state samples, instead as percentages of response time.
This eliminates percentages over 100% in the BREAKDOWN
section. Thus the RESPONSE TIME BREAKDOWN is replaced
by a STATE SAMPLE BREAKDOWN, and the STATE SWITCHED TIME
is replaced by a STATE SWITCHED SAMPL(%) breakdown. Only
the TOTAL column will be kept as percentage of response
time, which is the current view; however, the field name
will be changed to RESP TIME(%).
The APAR text contains a numeric example of the change
in the values printed with and without OW52227.
The APAR also states that the RMF III SYSWKM Report has
changed the meaning of ACT (Active State); in addition
to the time spent in an active subsystem state, it also
contains the time spent in an active application state,
if that information is provided by the subsystem, for
example, WebSphere.
The APARs also now count delays for service classes with
goal types other than response time goals, and count
delays for multi-period service AND report classes.
This MXG change adds the new variables to TYPE72GO data.
A later change to ANALRMFR will detect OW52227 and will
use R723RAPP to match IBM calculations, when test data
is available for validation.
The associated OW51848 added the new function that allows
Performance Block (PB) state reporting for enclaves. Now,
report-only PBs can be associated with an enclave or an
address space in a service class with multiple periods.
(Previously, a PB could only be associated with an ASID
that was in a Service Class with a response time goal.)
-The APAR documents that the new delay and sample counts
are also added to RMF III VSAM ERBRCDG3 segment, but that
segment is not yet supported in MXG's VMACRMFV, because
no one has yet sent sample data records to be decoded.
Change 20.068 Significant user contribution enhances the MXG RMF III
ASMRMFV support. This change is the last part of Change 20.033.
VMACRMFV -ASMRMFV, the program that reads the RMF III (compressed)
Apr 26, 2002 VSAM file to create the RMFBSAM flat file that is then
read with MXG's TYPERMFV, originally had hardcoded LRECL
of 800 bytes, but IBM now writes 1500 byte records that
were truncated by the original program. This revision
sets DCB to RECFM=VBS,LRECL=32756,BLKSIZE=0, which will
support any future record length. VBS is used (instead
of VB) so that half-track DASD will be allocated and DASD
space won't be wasted by the output flat file.
-VMACRMFV was enhanced to create variables SHIFT, SYSTEM
and SYSPLEX in all datasets, added SSHTIBEG/SSHTIEND to
datasets that did not contain them, corrected four vars
(GEIESPMB/SPME/SMRB/SMRE) to be input with RB instead of
with informat PIB, creates PCTLOGBY and PCTCPUBY vars as
percents of logical and physical CPU busy, added labels,
and corrected typos and spelling errors! Whew!
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 20.067 z/VM datasets VXBYUSR, VXSUMUSR, VXBYCPU, VXSUMCPU, and
TYPSVMXA VXBYTIME were not copied into the PDB library when the
Apr 26, 2002 TYPSVMXA member was used to SORT all datasets into the
PDB library. These summary datasets are built from the
other datasets, so they are now copied with a PROC COPY
that was added at the end of TYPSVMXA.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 20.066 New datasets TYP120JC and TYP120JI were created in the
VMAC120 //WORK file, but their _ST120JC/_ST120JI Sort macros were
Apr 26, 2002 not invoked inside _S120, so they were not sorted into
the PDB library by TYPS120 nor when _S120 was invoked.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 20.065 Support for BMC MAINVIEW FOR CICS 5.4 CMRDETL file, which
VMACMVCI was completely and incompatibly changed. Release 5.5 only
Apr 24, 2002 added two fields in reserved fields; both are supported.
Apr 30, 2002
Thanks to Ermanno Bertolotti, INTESABCI, ITALY.
Change 20.064 The example to send email from an MVS SAS job should have
EMAIL spelled the option EMAILSYST as EMAILSYS, without that
Apr 15, 2002 "T".
Thanks to James A. Monahan, National Grid USA, USA.
Change 20.063 Boole/BMC CIMS/IMF CIMSTRAN dataset variables CTCKPTNTS,
VMACCIMS MAXLOCKS, and TOTLOCKS were input but not kept; now they
Apr 15, 2002 are kept in dataset CIMSTRAN.
Thanks to Siegfried Trantes, IDG mbH, GERMANY.
Change 20.062 STARTIME in TNG datasets was an hour earlier than actual.
VMACTNG I originally assumed the "hour" was the hour of end of
Apr 12, 2002 the data, and used STARTHR-1 to set the ORIGTIME to the
previous hour. But the hour really is the START hour of
the data, so the two STARTHR-1 were changed to STARTHR.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
=======Changes thru 20.061 were in MXG 20.01 dated Apr 11, 2002=========
Change 20.061 UTILEXCL recognized and reported "UNKNOWN FIELD" but did
IMACICD1 not build correct logic in IMACEXCL to skip over the data
IMACICDA so the CICSTRAN dataset was invalid, strange dates, etc.,
UTILEXCL if that "POTENTIALLY SERIOUS ERROR" message was printed
VMAC110 when you executed UTILEXCL. The particular unknown field
Apr 11, 2002 CANPROD1 perhaps is the last CICS field to be supported.
This change corrects UTILEXCL to properly skip over any
future unknown CICS segments, and supports the CANPROD1
segment, creating the 4-byte variable CANPROD1.
Candle describes CANPROD1 as "Internal, used to provide
statistics for VSAM, DL/1, IDMS, ADABAS, SUPRA, and
DATACOM. Used to provide Application Trace Statistics.
Thanks to Hailin Wu, Cover-All, CANADA.
Change 20.060 SAS V6 Only, Warning. Labels added in Change 20.05x were
VMXG70PR longer than V6 limit of 40 bytes; non-fatal.
Apr 11, 2002
Thanks to Freddie Arie, TXU, USA.
Change 20.059 With UTILEXCL created IMACEXCL, STRTTIME/ENDTIME were not
UTILEXCL converted to Local Time if your GMT offset was non-zero,
Apr 10, 2002 and variable CPUTM was not populated. Both are corrected.
Thanks to Raff Rushton, Kaiser Permanente, USA.
=======Changes thru 20.058 were in MXG 20.01 dated Apr 9, 2002=========
Change 20.058 DB2 report PMSQL02 had missing TCB time values for two
ANALDB2R trace events (62058 and 59058) due to carry-down typos.
Apr 9, 2002 The CPU=S058UCPU-S066UCPU; is now CPU=S058UCPU-S062UCPU;
and CPU=S058UCPU-S066UCPU; is now CPU=S058UCPU-S059UCPU;
for those trace events.
Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM.
Change 20.057 -The daily NT PDBs are no longer all deleted when the WEEK
BLDNTPDB NT PDB is built, in keeping with the MVS BUILDPDB design,
Apr 9, 2002 so that you can read FRI's PDB on TUE without reading the
entire past-week's WEEKLY PDB.
-The RERUN parameter now works, but is subject to this
exposure that requires intelligent manual intervention:
If RERUN is used and it happens to be the day of the
week that is specified for running of the weekly or
the monthly, those programs will automatically be run.
Turn off the weekly and/or monthly options with RERUN,
and then evaluate what restores may be needed before
you can rerun to build weekly or monthly.
Thanks to Terry Heim, Ecolab, USA.
Change 20.056 Enhancements for MSU-based Capacity Measurement for IRD
VMAC7072 (z/OS Intelligent Resource Director, see Change 20.046):
VMXG70PR -Variable SMF70BDA,SMF70CSF,SMF70ESF, and SMF70MSU are now
Apr 8, 2002 corrected in dataset PDB.TYPE70PR; they were zero because
I used early doc and missed document revisions at GA.
-Variable SMF70CPA is kept into TYPE70PR from the TYPE70
segment, so the MSU can be calculated later in ASUM70PR
and ASUMCEC - see Change 20.046 equation.
-Both PDB.ASUM70PR and PDB.ASUMCEC now contain six new
variables for each LPAR:
LPnBDA ='LPAR n*AVERAGE*LOGICAL*CPUS*SMF70BDA
LPnMSU ='LPAR n*INTERVAL*MSU*COUNT
LPnMSUHR='LPAR n*INTERVAL*MSU*AS HOURLY*RATE
LPnMSU70='LPAR n*MSU*DEFINED*CAPACITY*SMF70MSU
LPnONT ='LPAR n*LPAR*ONLINE*DURATION*SMF70ONT
LPnWST ='LPAR n*LPAR*WAIT STATE*DURATION*SMF70WST
and three new variables for totals:
MSULICEN='SUM OF*LICENSED*MSU CAPACITY*OF ALL LPARS'
MSUTOTAL='TOTAL*MSU*DELIVERED*TO ALL LPARS'
MSUPERHR='HOURLY*MSU RATE*DELIVERED*TO ALL LPARS'
-SMF70BDA is usually equal to LPARCPUS, and sometimes is
slightly less, showing that IRD seems to be working,
but it does not seem to be useful to calculate any of
the LPAR utilizations.
-SMF70ONT (LPAR Online Time) and SMF70WST (LPAR Wait State
Time) are summed for each LPAR in ASUM70PR/ASUMCEC, but
are also still not understood for these 5 LPAR's data:
LPAR LPnDUR LPnUPDTM LPnBDA LPnONT LPnWST
1 2:15:00 0:19:06 9 2:15:00 0:51:50
3 2:15:00 0:12:02 9 2:15:00 1:07:33
5 0:15:00 0:00:00 1 0:15:00 0:00:00
7 2:15:00 0:08:23 8.37 2:05:36 1:32:51
14 2:15:00 0:04:12 8.40 2:06:07 1:43:43
Total+Phys: 0:46:24 ==> 34.3% busy, 9 engines, 15 min.
-I note that the only place where IBM records their 4-hour
rolling average MSU is in the TYPE70 data for each MVS in
variable SMF70LAC, but IBM does not calculate that value
in the PR/SM data for each LPAR. The MXG calculation of
the rolling average MSU4HRAV is in the PDB.RMFINTRV data.
Change 20.055 The Group Buffer Pool GBPxxxxx variables in DB2ACCTG (for
VMACDB2 each pool) and their sum in DB2ACCT have never been right
Apr 5, 2002 if more than one GBP was used; MXG repetitively input the
first segment. Adding OFFGBP=OFFGBP+LENGBP; and removing
the unused SKIP logic corrects the error.
Thanks to Warwick Robinson, National Westminister Bank, plc, ENGLAND.
Change 20.054 -The optional CICS User segment is now the last segment in
IMACICDA the default order in member IMACICDA, as was intended and
IMACICMR as is documented. If you have your own IMACICDA, it will
UTILEXCL still input the CICS segments in your chosen order. If
VMAC110 you use member UTILEXCL to create IMACEXCL, IMACICDA is
Apr 4, 2002 not used, so this has no impact there.
-The optional CICS CMRDATA segment from Mainview is now
supported in member IMACICMR, and UTILEXCL now knows of
that member for that optional data for its notes to you.
-VMAC110 was updated with the optional CMRDATA variables.
Thanks to Helgund Linck, BASF-IT-Services, GERMANY.
Change 20.053 Mitchem ACC/SRS support corrections. The offset was INPUT
VMACACC into variable SRHPHL, but references spelled it SHRPHL,
Apr 4, 2002 so ASHxxxxx variables were not INPUT. MSGLENGTH was 3
bytes short when SRHPHL was present. And so that this
member will execute correctly under ASCII SAS, INPUT()
and TRANSLATE() functions were added (because
EBCDIC-containing variable MESSAGE must be INPUT with
$VARYING informat).
Thanks to Heinz-Bernd Leifeld, Provinzial Rheinland Versich., GERMANY
Thanks to Engelbert Smets, Provinzial Rheinland Versicherung, GERMANY
Change 20.052 INSTANCE was blank if a 3-HDR records contained (*) for
VMACTNG the length of the instance field, indicating there was no
Apr 4, 2002 new instance value. MXG incorrectly blanked the value in
Apr 5, 2002 retained variable INSTANCE. Now, INSTANCE will be from
the preceding 2-HDR record, unless the 3-HDR has a real
length for the INSTANCE. Noted in NT014, but pervasive.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.051 Documentation. When you use UTILEXCL to create IMACEXCL
UTILEXCL for CICSTRAN, old variables that no longer exist in CICS
Apr 3, 2002 are no longer kept; these variables will not exist:
Pre CICS/ESA: FCOTHCN MAXTASK SHRTSTOR OPERATOR PAGEINS
CICS 3.3 only: PC24UHWM PC31UHWM TCSTG TCLASS
Thanks to Helgund Linck, BASF-IT-Services, GERMANY.
Change 20.050 MXG incorrectly decoded the second TYPE78IO IOP segment
VMAC78 if z/OS 1.2 extended data was present, causing very large
Apr 3, 2002 values for R783ICPB/IDBP/ICUB/IDVB when &RB.8 input was
Apr 25, 2002 mis-aligned. Those values caused PROC MEANS to fail with
Mar 25, 2003 a "DOMAIN ERROR", because SAS does not validate data when
the "RB" (floating point) informat is used.
Mar 25 2003: This change may increase the number of obs
created in dataset TYPE78IO, and may increase NRIOPREQ,
the SIO count, and that variable is summed and renamed in
RMFINTRV as SIO73CNT.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Jeff Rash, American Honda, USA.
Change 20.049 TYPE89 dataset variable MULCURD was wrong when MULCURT=2
VMAC89 or MULCURT=3. For MULCURT=2 the INPUT is &PIB.8. and for
Apr 3, 2002 MULCURT=3 the INPUT is &RB.8, but MXG had them reversed.
The specific error with MULCURT=2 and incorrect informat
of &RB.8. used for a data value of '00.....01'x resulted
in a MULCURD value of -1.606E60, and that value caused a
SAS DOMAIN ERROR when PROC MEANS summed that dataset.
Thanks to Glenn Harper, Memorial Hermann Hospital System, USA.
Change 20.048 The KEEP= list spelled SMF4VLS instead of SMF94VLS, so
VMAC94 that variable was not kept in TYPE94 dataset.
Apr 2, 2002
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 20.047 DAILYDSN still wrote to the //PDB libref, after Change
DAILYDSN 20.020. Change OUTDATA=&PDBMXG..DATASETS,
Apr 2, 2002 to OUTDATA=DATASETS.DATASETS,
Thanks to Tien Truong, Citicorp Asia Pacific, SINGAPORE.
=======Changes thru 20.046 were in MXG 20.01 dated Apr 1, 2002=========
Change 20.046 CPU Busy Percentages are very different if WLM's IRD is
VMXGRMFI in control of allocating CPUs to LPARs. Previously the
Mar 31, 2002 PCTCPUBY (TYPE70) and PCTLnBY (ASUM70PR/ASUMCEC) measured
the percentage of the fixed capacity (NRCPUS*DURATM) that
you gave to an LPAR, i.e., that you gave to the system
running in that LPAR, so 100% meant the MVS system was
using all of the CPUs you gave that LPAR.
Now, WLM's Intelligent Resource Director will dynamically
change the number of engines given to an LPAR, so there
is no fixed capacity to measure an LPAR's work against:
variables NRCPUS/LPARCPUS/LPnNRPRC now contain the count
of engines that were used (even briefly) in an interval.
Fortunately, though, when IRD is in control, the PCTCPUBY
(TYPE70 and RMFINTRV), and the PCTLnBY (ASUM70PR/ASUMCEC)
calculations are valid; they have just changed in meaning
and now measure the percentage of the hardware platform
(the CPC, all PARTNCPUs) that was used by this MVS system
or this LPAR. If you had a 2-engine LPAR running at 100%
of those two engines, PCTCPUBY=100% in that MVS's system.
But if that 2-engine LPAR is now run under IRD on a z900
10-way, the PCTCPUBY will be measured as 20%, since only
the fixed capacity of the total CPC platform can be used
now to measure "percent CPU busy".
So what to do? For starters, while we all learn this
new playground, MSUINTRV, the total MSU consumed by each
LPAR during each interval, can be summed for each hour
and compared with SMF70WLA, the (hourly) Defined Capacity
that you chose for your Licensed Software MSU capacity.
You can also convert the MSUINTRV value for intervals
less than an hour to an hourly rate with the ratio:
MSUPERHR= MSUINTRV*3600/DURATM.
But what capacity percentage makes sense anyhow. On a
2064-1C9 (MSU hardware capacity of 305/hour), you could
assign an LPAR to a Defined Capacity of 50 MSU, but you
could easily consume all 302 MSU in that LPAR for an
hour (only impacting Software costs!); what percentage
should be calculated: 302/50= 600% of capacity?
You can detect that WLM's IRD is in control in the
TYPE70PR dataset, which will have LPARWLMG='Y' (SMF70WLM
bit in field SMF70PFG), but only in observations with
SMF70CIN='CP'; the LPARNAME='PHYSICAL' observations have
LPARWLMG='N',and SMF70CIN=' '.
The number of LCPUADDRs in TYPE70PR varies for the same
LPAR; some intervals had 9 LCPUADDRs of 0-8, and some
some intervals had only eight LCPUADDRS of 0-7.
Unless you change the Defined Capacity for an LPAR, the
hourly MSU Capacity of each LPAR, SMF70WLA, is constant,
in spite of the change in the actual count of LCPUs.
The CPC capacity of the 2064-1C9 is 302 MSU (9 CPUs with
SMF70CPA=9329.45), but the sum of SMF70WLA across all of
the LPARs in each CPC is only 185 MSU:
CPCSER xxx3: 65 40 60 15 5 (sum=185)
CPCSER xxx2: 65 55 50 15 (sum=185).
So this site is a perfect example of the real value of
IRD and the IBM License Manager: IBM has installed a 302
MSU box, but the customer is only paying for the 185 MSU
that they currently need for all their LPARs.
Note that even though the CPC has 11 engines, because two
are ICF engines, the CPUMODEL='2064-1C9', showing 9 CPUs.
The change was to revise the calculation of RMFINTRV's
MSUINTRV value, to use the CPUACTTM*SMF70CPA/1E6 rather
than the original that was based on LPAR percent busy.
Expect additional enhancements as we learn more, and
as we decide how to measure this changing landscape.
NOTE: Change 21.170 re-defines NRCPUS and recalculates
PCTCPUBY using the new SMF70ONT online-time measure.
Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND.
Change 20.045 MXG 19.04-19.19. PCTDLxxx variables in TYPE72GO divided
VMAC7072 by variable VALDSAMP can be slightly different than the
Mar 29, 2002 RMF report values; the calculation of the PCTDLxxx and
Apr 5, 2002 PCTUSxxx variables is now based on R723CTSA instead of
on VALDSAMP to match the RMF system level reports, and
both VALDSAMP and R723CTSA are kept in TYPE72GO so that
sysplex-wide velocity can be calculated.
Thanks to John A. Doan, Total System Services, USA.
Change 20.044 If two products write the same user SMF record number,
VMACSMF you can still tailor MXG to read both records, although
Mar 29, 2002 it would be wise to use unique SMF record numbers! The
exact syntax depends on finding a "marker" in one of the
records that can be used to differentiate between the two
products. In this case, both CA's NETSPY and Sterling's
NDM wrote ID=132 SMF records, and the NETSPY Version of
"R5.3" could be used as the "marker", and this example
assumes the NDM record ID will be changed to ID=133. The
example uses MACFILE and MACKEEP macro variables in the
job's input stream, and will read the existing (old) 132s
and the new 133s when they show up in your SMF file:
%LET MACKEEP=
MACRO _NSPYID 132 %
MACRO _IDNDM 133 %
;
%LET MACFILE=
%QUOTE(
IF ID=132 AND LENGTH GE 50 THEN DO;
INPUT @39+OFFSMF MARKER $EBCDIC4. @;
IF MARKER NE 'R5.3' THEN ID=133;
END;
);
%INCLUDE SOURCLIB(BUILDPDB);
(or if you only wanted one or the other, you would
%INCLUDE the TYPSNDM or TYPSNSPY record instead of the
example's BUILDPDB member).
P.S. Yes, the SMF Record ID macro for NETSPY is spelled
backwards. It should be _IDNSPY, like almost every other
_IDxxxx macro names, but it is one of the inconsistent
names. The exact name of the ID macro for each SMF data
record is in the IMACxxxx member for that product, in the
IMACNSPY and IMACNDM members for this example.
Thanks to Aldo Raimondo, Global Value Services, Italy.
Change 20.043 Support for z800 2066 CPUs running OS/390 R2.8, R2.10.
FORMATS These records without the type 70 SMF70WLA field do not
VMXGRMFI have their MSU capacity in their SMF 70 record, causing
Mar 29, 2002 MXG messages "CPU NOT IN TABLE CPUTYPE=2066", causing the
MSU-related variables to be missing in RMFINTRV dataset.
Some non-IBM machines are in the table, but we don't yet
have #CPs nor their SU_SEC value, but if you get one, the
SU_SEC is in the TYPE72/TYPE72GO dataset for the update.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Thanks to Winnie Pang, Hawaiian Medical Service Association, USA.
Change 20.042 Extraneous last byte '1A'x hex value in ASCII IMACPTF
IMACPTF was translated to '3F'x and could cause SAS 180 syntax
Mar 29, 2002 error. Deleted that byte.
Thanks to John R. MacDonald, Public Works and General Svcs, CANADA.
Change 20.041 Change 19.248 removed ID statement from member ASUMNTIN,
TRNDNTIN but should also have removed the ID statement from the
Mar 28, 2002 TRNDNTIN member.
Thanks to Terry Heim, ECOLAB, USA.
Change 20.040 -UTILEXCL incorrectly generated IF SEGLEFT GE CMODLENG in
IMACICOC the IMACEXCL it created; "CMODLENG" should have been the
IMACPTF expected segment length value, not the variable name.
UTILEXCL -If you enabled IMACICOC, and did NOT have _QOC0109 turned
Mar 25, 2002 on in IMACPTF, the IMACEXCL INPUT statement was out of
Mar 30, 2002 alignment and CICSTRAN was not valid. Since all Omegamon
records now have that old APAR enabled, I have removed it
from the IMACICOC member that was the only place it was
used, and changed the default value in IMACPTF from 0 to
1, just for compatibility.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 20.039 The default ASUMDB2A member will fail if variables are
ASUMDB2A DROPed from the input DB2ACCT dataset, but with minor
VMXGSUM tailoring, ASUMDB2A will tolerate dropped variables.
Mar 24, 2002 ASUMDB2A invokes the %VMXGSUM macro, and in ASUMDB2A,
MXG specifies KEEPALL=YES for performance reasons. But
if you remove variables from the input dataset, you need
create a tailored ASUMDB2A member, with these changes to
the %VMXGSUM invocation in that member:
- Change the KEEPALL=YES to KEEPALL=NO in your ASUMDB2A.
- Run the ASUMDB2A against your modified data, and look
for any uninitialized variable messages on the log,
where the view WORK.MXGSUM1.VIEW was used:
NOTE: Variable QTXAPREC is uninitialized.
NOTE: Variable QTXAILMT is uninitialized.
NOTE: Variable QTXANRUN is uninitialized.
NOTE: Variable QWACRINV is uninitialized.
NOTE: Variable THREADTY is uninitialized.
NOTE: Variable DB2PARTY is uninitialized.
NOTE: View WORK.MXGSUM1.VIEW used:
- Those variables are used in the INCODE logic, but are
not in any SUM, MIN, etc. request, so they were not
kept by KEEPALL=NO, so you must add an argument to the
%VMXGSUM invocation to cause them to be kept for the
input phase, with this syntax:
KEEPIN= QTXAPREC QTXAILMT QTXANRUN QWACRINV
THREADTY DB2PARTY,
You cannot (safely) drop the variables in the KEEPIN=
argument, nor can you drop the variables in the SUMBY=
argument, as they are all required for the logic of the
summarization.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.038 ASUMUOWT builds the PDB.ASUMUOW dataset, using MONITASK
ASUMUOWT from Landmark's TMON/CICS, instead of the CICSTRAN data
VMXGUOW from IBM SMF 110s. Unlike ASUMUOW, the default in the
Mar 23, 2002 ASUMUOWT program creates observations; you only need to
%INCLUDE SOURLCIB(ASUMUOWT); with the correct DDnames:
//DB2ACCT and //MONITASK, and with //ASUMUOW for output,
as shown in the example in the ASUMUOWT member.
The MONITASK values are stored in CICSTRAN variables, but
I could not find 43 CICSTRAN variables in the MONITASK
dataset, so I have just sent the list of those missed
fields to Landmark, and will update this note is any of
them are identified. (All are set missing and listed in
the _SUOWTMO macro in VMXGUOW.)
Thanks to Jacky Kwoka, ATOS Origin, FRANCE.
Change 20.037 The calculation of VELOCPU in TYPE72GO was incorrectly
VMAC7072 calculated when I/O Priority Management is enabled.
Mar 23, 2002 VELOCPU is the velocity calculated if only CPU is enabled
but with IOPM, VELOCPU included I/O effects. Now, the
VELOCPU is recalculated to measure the CPU-only velocity.
Of coure, variable VELOCITY has always been the correct
velocity value - variables VELOCPU and VELOCIOD are only
"what if" calculations of possible velocity values.
Thanks to Pat A. Perreca, Bear Stearns, USA.
Change 20.036 CICS/TS Statistics dataset CICXQ3 (Shared ts queue server
VMAC110 storage, STID=123) fields have been mis-documented in all
Mar 23, 2002 releases, TS 1.3 thru TS 2.2. The Data Areas lists them
May 14, 2002 as RQG(Gets) ,RQF(Fails) ,RQS(Frees) ,RQC(Compress), but
SMF data shows RQG and RQF are equal, and RQS and RQC are
both zero, so I assume that RQF contains Frees instead of
Failures, and so RQS must contain Storage Failures, and
not Frees. The S3ANYRQF/RQS and S3LOWRQF/RQS variable's
labels were corrected to match the observed data values.
May 14: IBM confirms my assumption, and Don found and IBM
confirmed the same problem exists in the Coupling
Facility Data Tables S9ANYxxx and S9LOWxxx) and the Named
Counter Sequence Number Server Statistics (S5ANYxxx and
S5LOWxxx); those variable's LABELs were also corrected.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 20.035 New %macro that will get the DSNAME of an allocated SAS
VGETDSN Data Library, and if that DSNAME is an MVS Generation
Mar 22, 2002 Data Group (GDG), %VGETDSN will allocate the next new
member (next "Go0ooVoo") dynamically, specifying its UNIT
SPACE, DISP, and ENGINE in the %VGETDSN arguments. And
You can specify JOB= to cause the dynamic creation of the
next GDG to only occur if that Job name invoked %VMXGDSN.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.034 Cosmetic - variable labels. The Dispatcher Variables
VMAC110 DSGSYSW,DSnSYSW, documented as 'Operating System Waits',
Mar 22, 2002 were re-described by IBM as 'Exits from Partition' when
IBM moved the Dispatcher Statistics to STID=60 and added
twelfth and thirteenth TCBs to CICS, and some of those
variables labels were changed. Since the CICS/TS 2.2
Performance Guide still refers to the DSnSYSW fields as
Operating System Waits, the newer labels were removed and
all labels are as before.
Thanks to Gerhard Hellriegel, ???, GERMANY.
Change 20.033 Support for RMF III (RMF VSAM) for Enclave Table ENCG3.
VMACRMFV Only ENCG3 support was actually added by 20.033; the rest
Mar 22, 2002 of the original change was implemented in Change 20.069.
Thanks to Betty Wong, Bank of America, USA.
Change 20.032 Domino R5.04+ DOMBTIME/DOMETIME variables could be wrong,
VMAC108 because the GMT offset field was input as &IB.4. when it
Mar 18, 2002 should have been input as $CHAR4. The actual bad values
depended on your actual GMT offset, but were in the year
2020 if your offset was zero.
Thanks to Bob Furlong, JPM Chase UK, ENGLAND.
Change 20.031 Example Trend member had PDB.DB2STATS syntax, instead of
ANALDB2R WEEK.DB2STATS syntax, but is now correctly using WEEK. as
TRNDDB2S input. Additional typos were corrected
Mar 18, 2002 In TRNDDB2S: QJSTWT should have been QJSTWTB.
Mar 30, 2002 In ANALDB2R: QXSETCR should have been QXSETCRL.
Thanks to Scottt Snyder, First Data, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.030 Divide by Zero messages (but no error) when TOTBECPP, the
VMACICE total back end capacity, production partition, was zero.
Mar 14, 2002 The calculation of NCL is now protected for zero divide.
Thanks to David Ehresman, University of Louisville, USA.
Change 20.029 A typo changed all lower case "F" values to a blank in
VMAC120 WebSphere DBCS character values (SM120JA8='De ault').
Mar 14, 2002 The many TRANSLATE() statements had '86'x, but should be
SM120xxx=TRANSLATE(SM120xxx,' ','80'X);
which is needed because of the $VARYING and DBCS data.
Thanks to Bill Feeney, Hennepin County, USA.
Change 20.028 -Support for Windows 2000 TNG. PLATFORM name tests for NT
VMACTNG data look for both NTS400I and (new) NTS500I for Win 2K.
Mar 12, 2002 The same NTnnn datasets are created from either version.
Mar 18, 2002 -Both old and new TNG NT records caused ABENDS, because
Mar 25, 2002 SAS does not properly input numbers-with-leading-blanks
Apr 3, 2002 when you mix LIST and non-LIST input modes, and you have
INFILE xxx DLM='' specified. The MXG statement:
INPUT VALUE FLAG $1. @; INFORMAT VALUE 20.;
stored zero in VALUE when its input column was blank.
And BZ20. can not be used - SAS documents that you must
change DLM='' to "something" for the BZ20 informat to
treat blanks as zeros, but MXG logic requires that the
INFILE TNG DLM='' be specified so that it can parse all
of the other data fields in the records.
So the INPUT VALUE FLAG $1. @; logic was revised and is
first input as a variable length string, and then blanks
are detected and skipped before the numeric INPUT.
-Variable DOMAIN kept length increased from $20 to $30 to
keep longer domain names.
-46 character Instance Name of Network Interface value of
'Compaq Ethernet_Fast Ethernet Adapter_Module#1' exceeded
MXG's default of 40, requiring revision to the INSTANCE
handling logic to handle 64 character instance name.
(This last part was only in the Apr 3 dated member).
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.027 NDM PNODE and SNODE Account fields are now input and kept
VMACNDM in the NDMCT and NDMRT datasets.
Mar 8, 2002
Thanks to Betra Reeves, (i)Structure, Inc.
Thanks to John Rivera, (i)Structure, Inc.
Change 20.026 The Availability Report example would terminate with no
ANALAVAI output & no diagnostics if no applications were defined
Mar 8, 2002 or failed if the DATASET options was used to change
the name of the output dataset.
Change 20.025 Worked, but only with a KEEPER or DROPER argument used;
VMXG2DTE without both, either invalid syntax error or no SET
Mar 6, 2002 statement was generated.
Change 20.024 -If UNKNOWN FIELD messages were printed on the log when
UTILEXCL UTILEXCL was executed, the created IMACEXCL had extra
VMXGUOW END; statement for each unknown field.
Mar 6, 2002 -MXG expected both ABCODE fields 113 and 114 so it input 8
Mar 7, 2002 bytes into ABCODE; now UTILEXCL is enhanced to create the
Mar 8, 2002 8-byte ABCODE variable as before, from either or both of
the abend code fields, when one or both are found.
-The "ASUMUOW-CRITICAL-ALERT" tests in both UTILEXCL and
added in VMXGUOW did not test for variable "UOWID", so it
was always reported as not being in your CICSTRAN data.
-Variables UOWTIME and UOWIDCHR were not kept when UOWID
was found, causing spurious "ASUMUOW-CRITICAL-ALERT" that
listed those two variables, but not UOWID, as missing.
Thanks to Hailin Wu, Cover-ALL, CANADA.
Thanks to Chris Voris, QRS Corporation, USA.
Thanks to MP Welch, SPRINT, USA.
Change 20.023 ANALDB2R failed if your report request SORT list had only
ANALDB2R one variable. Line 2978 was changed
Mar 6, 2002 from /@1 &SORT2 $CHAR16.
to /@1 ' ' to correct the error.
Thanks to Brad Brewer, Humana Inc, USA.
Change 20.022 The PDBOUT parameter did not work in ANAL94, but now it
ANAL94 does.
Mar 5, 2002
Change 20.021 TYPEIMSA (19.19 only) fails with 180 syntax error; the
TYPEIMSA two statements %%VMXGTIME(... should have only one
Mar 5, 2002 percent sign %VMXGTIME(... in both statements.
Thanks to Yves Terweduwe, CIPAL, BELGIUM.
Change 20.020 Change 19.230 sent the four DCOLLECT datasets to the PDB
DAILYDSN DDname instead of the DATASETS because the 4 lines with
Mar 4, 2002 MACRO _PDCOxxx should have been spelled MACRO _LDCOxxx.
Mar 22, 2002 And the correct SAS dataset name should be:
MACRO _WDCOVOL DCOLVOLS %
MXG 19.19 incorrectly had DCOLDVOL instead of DCOLVOLS.
Thanks to John Muir, Illinois State University, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.019 SAS Version 8.2 under Windows Professional Service Pack 2
SASV8.CFG fails if there is a directory named "user" under either
VMXGINIT the SAS root, or (in this specific case), under \WINDOWS
Mar 4, 2002 under \SYSTEM32. This error was first reported for unix
Mar 18, 2002 systems under SN-001262 but was reportedly fixed in V8.
That note gave this unix fix: add -user work in your
SASV8.CFG member, which also fixed the error on Windows.
This error surfaces as a DATA SET NOT FOUND when MXG
tries to delete a WORK.xxxxxxxx dataset, but the SAS log
shows the data was written instead to USER.xxxxxxxx
instead. Under MVS, we found the existence of //USER in
the JCL also caused an error, so VMXGINIT was revised to
detect a user option value problem, to change it to work,
to report what we found on the SAS log, and to keep on
truckin' without an error. SAS Usage Note ZZ-yyyy will
document these discoveries.
Thanks to Mark Darvodelsky, Royal SunAlliance Australia, AUSTRALIA.
Change 20.018 HMF Subtypes 29, 30, and 31 variable HMFHDNOD is actually
VMACHMF an IP Address in those subtypes, so new HMFIPADR variable
Mar 1, 2002 is created to decode and display the n.n.n.n ipaddress.
Thanks to Perry Lim, Union Bank of California, USA.
Change 20.017 Using OPTIONS OBS=0 can be useful, but can cause errors.
VMXGSUM You can use OBS=0 to syntax-test your programs, and it is
VMXGRMFI the correct way to create a 'zero-obs' SAS dataset or an
Feb 28, 2002 'zero-obs' SAS data library with multiple SAS datasets,
so you can test subsequent references to datasets and to
variables, and OBS=0 and PROC COPY is the recommended way
to initialize a SAS data library with all datasets, etc.
But: when OPTIONS OBS=0 is used with summary programs
that use %macros, especially %VMXGSUM, it can cause error
messages, because macro variables are not created if the
SYMPUT/SYMGET statements are after SET statements that
don't get executed, so code has to be relocated just to
support OBS=0. We continue to plug holes when we find
them; this change relocated %VMXGOPTR calls to support
OPTION OBS=0 in VMXGSUM and VMXGRMFI, but there is an
alternative for testing: use a DUMMY file as input, so
that all datasets have zero observations, but with the
OPTION OBS=0 being set. On MVS you can do this with JCL
with //SMF DD DUMMY for the input file, or on all SAS
platforms you can use FILENAME SMF DUMMY; to read nil.
And if your need is to actually test, but you don't want
to use much CPU nor disk space, use OPTIONS OBS=5000; to
to restrict the input volume; it is only the exact OBS=0
value that is our nemesis.
Change 20.016 Sample PROC PRINTs of WebSphere SMF 120 data had several
ANAL120 prints bypassed during testing (by adding MACRO __ before
Feb 28, 2002 and a % after the block of code to be bypassed, which is
fine ONLY if there are no percent signs in the code being
bypassed!), but that MACRO and Percent Sign should have
been removed so all PROC PRINTs would execute.
Thanks to Jim Kovarik, AEGON, USA.
Change 20.015 This old report program has ENTITY as an array name, and
ANALRACF under SAS V8.2, a bogus message is printed on the log:
Feb 28, 2002 ERROR: THE PRODUCT WITH WHICH THE FUNCTION/SUBROUTINE
IS ASSOCIATED IS EITHER NOT LICENSED FOR YOUR SYSTEM OR
THE PRODUCT LICENSE HAS EXPIRED. PLEASE CONTACT YOUR
SAS INSTALLATION REPRESENTATIVE.
but there was no real error, and data step was correctly
executed. Once discovered (and with same day service!),
SAS Technical Support Usage Note SN-007039 documents that
the names: ENTITY, GENDER, STDNAME, should not be used as
array names in V8, but those names will be changed in V9,
to protect the innocent. I changed ENTITY to ENTITI to
eliminate the exposure.
Thanks to Clive Talbot, EDS, UK.
Change 20.014 Support for new subype 6 and 7, Mobius RDS InfoPac View
EXIPAC06 Direct Product's user SMF record create new datasets:
EXIPAC07 DDDDDD Dataset Description
IMACIPAC IPAC06 IPAC06 PAGES/HIERARCHY CODE
VMACIPAC IPAC07 IPAC07 ARCHIVE PLACEMENT/LONGEVITY
VMXGINIT
Feb 27, 2002
Thanks to Mary Beth Delphia, Texas Comptroller of Public Accounts, TX
Change 20.013 Enhancements for building "PDB's" from various SMF data
UTILBLDP is enhanced so that datasets can be "ZERO-OBS'ed". This
Feb 27, 2002 is needed if you want to build PDB.ASUM70PR & PDB.ASUMCEC
from SMF, which needs only PDB.TYPE70 and PDB.TYPE72GO
datasets, but the logic in member ASUM70PR also updates
the PDB.RMFINTRV dataset, so it must be created, but with
zero obs for all of the unwanted RMF datasets. Two new
examples in the comments are show here so you can see
that UTILBLDP is a powerful tool if you want to create
particular MXG datasets without running BUILDPDB:
Example 2.
Create PDB.ASUM70PR and PDB.ASUMCEC from SMF 70 and 72s:
%UTILBLDP(OUTFILE=INSTREAM,
USERADD=7072 71 73 74 75 78,
ZEROOBS=71 72 73 74 75 78,
BUILDPDB=NO,
INCLAFTR=RMFINTRV ASUM70PR
);
RUN;
%INCLUDE INSTREAM;
RUN;
Note that by using OUTFILE=INSTREAM, and then by using
%INCLUDE INSTREAM; this example will actually execute
the code that it just built.
Example 3.
Create only PDB.JOBS, PDB.STEPS, and PDB.PRINT from the
SMF 6, SMF 26 (JES2 in this example), and SMF 30 records.
Since PDB.JOBS is the sum of the steps data, you must
create PDB.STEPS to be able to create PDB.JOBS.
%UTILBLDP(OUTFILE=INSTREAM,
USERADD=6 26J2 30,
SORTOUT=NO,
BUILDPDB=NO,
INCLAFTR=BUILD005
);
%INCLUDE INSTREAM;
RUN;
Change 20.012 This report that mimics IBM's IXGRPT1 was wrong in column
ANAL88 headed "NTRY FULL", because variable SMF88ALS was printed
Feb 27, 2002 instead of SMF88EFS; All SMF88ALS were changed to EFS,
Mar 1, 2002 and some report field widths were increased from 5 to 6.
The SORT order now uses SMF88LTD to match IBM's report.
Thanks to Wesley Andrews, Alltel, USA.
Change 20.011 DO NOT USE ML-21 OF THE MXG TAPE MOUNT MONITOR. That
ASMTAPES level of the monitor was included only in the fix1919.zip
Feb 27, 2002 file, but as found to create still more 0E0 ABENDS. The
ASMTAPES member in MXG 20.01 is still at ML-20. A new
Maintenance Level is in development.
Change 20.010 Support for Top Secret V5.2 required only the change of
VMAC80 OR RACFVRSN=051X THEN DO; to
VMAC80A OR RACFVRSN=051X OR RACFVRSN=052X THEN DO;
Feb 25, 2002 While both members were updated, the TYPE80A member
is really the only member to use for SMF 80 RACF records.
Thanks to Chris Taylor, GMAC Insurance, USA.
Change 20.009 Execution of MXG under ASCII only. Some source members
TYPEMOND still had hardcoded informats of IB, PIB, PK, and RB
TYPETMON instead of "&IB.", of "&PIB.", &PK.", and "&RB." macro
TYPEVM variable names, needed for transparent execution of MXG
VMAC33 across platforms. The members that had IB or PIB would
VMAC71 have had incorrect values for those variables if MXG was
VMAC94 was executed under ASCII SAS, and they are listed below.
VMACAXC The other members revised had only PK and RB hardcoded,
VMACFTEK which works fine, but which are now changed so they are
VMACMONI consistent across MXG source, if ever needed.
VMACQTRT Members with PIB or IB:
VMACSTRS Member VARIABLE Notes
VMACTMDB VMAC71 GMTOFF71 - would impact STARTIME
VMACXAM VMACFTEK REASON
Feb 25, 2002 VMACSTRS Many
VMACXAM Several
Thanks to Freddie Arie, TXU, USA.
Change 20.008 Fixes for UTILEXCL and ASUMUOW for CICS after MXG 19.19:
UTILEXCL -ASUMUOW still did not increment SPINCNT, even with Change
VMXGUOW 19.230, but now it does. This had no impact if you left
Feb 21, 2002 the default SPINCNT for ASUMUOW at zero, or if you had
Mar 5, 2002 relatively few "inflight" transactions.
-UTILEXCL caused ASUMUOW to fail, with VARIABLES NOT FOUND
because the utility failed to create 9 CICSTRAN variables
(computed from other variables) that were required by the
syntax of the ASUMUOW program:
UOWTIME UOWIDCHR
CPUTM ELAPSTM IRESPTM TRMCHRCN
WTOTIOTM WTTOIOTM WTUNIOTM
You could circumvent the syntax error in ASUMUOW program
by adding those variables to the list in MACRO _VCICTRN
in the IMACEXCL member you created with UTILEXCL, but
your PDB.ASUMUOW dataset could still be invalid:
Satisfying the syntax above does not satisfy the logic in
ASUMUOW that requires these MXG variables be populated in
CICSTRAN so that matchup by Unit of Work is possible:
Variables required in CICSTRAN to build ASUMUOW
MXG variable IBM CMODHEAD IBM CMODIDNT
TRANNAME TRAN DEC 001
STRTTIME START DEC 005
ENDTIME STOP DEC 006
NETSNAME NETNAME DEC 097
UOWID UOWID DEC 098
UOWIDCHR UOWID DEC 098
UOWTIME UOWID DEC 098
So UTILEXCL is now enhanced and will tell you if you have
excluded fields that are required to run ASUMUOW, and
will list which of the above fields are not in your CICS
transaction records.
But VMXGUOW should not have failed when a variable in the
sum list is deleted from your SMF record, so by inserting
OPTIONS DKRICOND=NOWARN; and OPTIONS DKRICOND=ERROR;
appropriately, VMXGUOW now only sums variables that are
found in your CICSTRAN dataset.
-UTILEXCL did not correctly recognize DBCTL and IMS data
segments, causing messages "POSSIBLE CRITICAL ERROR" and
UNKNOWN FILED CMODHEAD=PSB WAIT CMODNAME=USER
UNKNOWN FILED CMODHEAD=DBCTL CMODNAME=DBCTL
UNKNOWN FILED CMODHEAD=RMIDATA CMODNAME=DBCTL
notes on the UTILEXCL log. The CICS dictionary lists the
DBCTL/DBCTL fields as 64 individual 4-byte fields, while
the DBCTL/RMIDATA field is a single field of 256 bytes; I
believe both describe the same DBCTL data fields, and are
processed by IMACICDB, and are different than the 60-byte
example in IMACICUS (that I want to believe was replaced
by the DBCTL/DBCTL and DBCTL/RMIDATA data segment). This
note will be revised if the two DBCTLs are not the same.
Thanks to Barry Mueller, Tyco Electronics, USA.
Thanks to Donald Williams, University of North Carolina, USA.
Change 20.007 -Variable ORACMSB (Max Additional Stacks Used) is created
VMACORAC in TYPEORAC from the old-format Oracle SMF records.
Feb 22, 2002 -Oracle8 i Enterprise Edition with OSDI, Release 3 (8.1.7)
Mar 1, 2002 for OS/390 has INCOMPATIBLY changed the layout from "MPM"
based to "OSDI" based, and it took several iterations to
discover their data did not agree with their DSECT:
DSECT: DTAI-8,DTAO-8,XCPU-8,RPCS-4,HWST-4,INV-1 but the
DATA: DTAI-8,DTAO-8,RPCS-4,XCPU-8,HWST-8,INV-1 showed
where the fields really were to get realistic values.
The only CPU time measure now is the CPUXMETM, so CPUTM
variable (always the total of all CPU times) will only be
equal to CPXMETM in the OSDI records; the other CPUxxxx
variables are all missing, as are all of the variables
that are no longer created in the new OSDI record. And
that includes the ORACMSB field added earlier in this
change that is not carried forward into the OSDI record.
This support also protects the READTIME field from CA-7,
which writes a 'EE'x or 'EF'x in the first byte of Read
Time to flag jobs, but CA-7 did not provide the exit code
for IEFU83 to correct their overwrite. MXG detects and
resets to 00, but it turns out that SAS read the EE1B897F
time value as a negative, and shifted the READTIME back
four days; I've suggested that the SAS SMFSTAMP8 format
should not treat the first bit as a sign bit, but instead
should have input the field as positive, causing the
READTIME to be 462 DAYS into the future, and more likely
to be detected as incorrect, so you will notice and then
get the fix you need from CA to correct the Oracle SMF.
Mar 1: the above change did handle the OSDI format Oracle
8.1.7 records, but there was a missing @; in the MPM-only
section of code, so the 8.1.7 MPM format records were not
correct; this change inserted the missing @;.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
Thanks to Matt Martin, United States Post Office, USA.
Thanks to Leslie Arndt, NITC/USDA, USA
Thanks to Yvonne McDonough, NITC/USDA, USA
Change 20.006 READDB2 and VMAC102 only recognized DB2 102 subtypes thru
EX102316- 314; this changes adds the exits and macros needed to
EX102350 recognize those subtypes. However, the actual subtypes
READDB2 themselves are not decode; test data is required to write
VMAC102 the support code, so only when you enable a new subtype
VMXGINIT and send sample data can the subtype be supported.
Feb 15, 2002
Thanks to Ford Wong, Workers Compensation Board of Alberta, CANADA.
Change 20.005 -Variables STC16SCL, STC17SCL, and STC17MVC were created
VMACSTC as stated in MXG Change 19.298, but only in my test lib.
Feb 15, 2002 The tested member is now moved to the source library and
Feb 27, 2002 those three variables will now be created and kept.
-Variables STC11CUB is now FORMATed TIME12.2; it was
always the time in seconds and fractions, but now will be
printed as a time duration, and documented as a time
variable by virtue of being formatted with a TIME format.
Thanks to Kis Ranai, Citicorp, USA.
Change 20.004 IBM documentation for AS/400 V5R1 QAPMJOBM JBCPU/JBTCPU
VMACQACS CPU time fields are wrong; documented as in milliseconds,
Feb 15, 2002 the data in QAPMJOBM is in microseconds, but QAPMJOBL's
same-named variables are still in milliseconds. The two
&PIB.8.3 in the INPUT lines for JBCPU and JBTCPU after
the INFILE QAPMJOBM statement were changed to &PIB.8.6
and the QAPMJOBM CPU times now match the QAPMJOBL CPU.
Thanks to Pat Wingfield, Bank of America, USA.
Change 20.003 Change 19.264 described NPM documentation errors for the
VMAC28 NRP/NRT/NIT RTYP field in APAR OW53087 which led me to
Feb 12, 2002 think there were undocumented data, but IBM has clarified
and will revise their APAR text. There is only one value
for RTYP in each of those segments: NRPRTYP=2, NRTRTYP=1
and NITRTYP=3, so there is no need to test RTYP value.
NRPRTYP was correctly tested in 19.264, but the MXG test
for NRTTYPE=2 was removed by this change, once IBM
documented what's really there!
25Apr02: Variable NRTDTYPE was removed by this change; it
is now a reserved field, but that removal was not noted.
Change 20.002 MXG 19.19 with SAS Version 6 only: fails in the JCLTEST6
JCLTEST6 because of one error in spelling, but also because some
VMACTMV2 MXG support for new products that did not exist before,
Feb 12, 2002 now require SAS V8.2 or later:
Mar 29, 2002 -Landmark TMVS. MXG support for new release was added to
19.19 on the last day, only QA'd under SAS V8.2, and the
unacceptable-to-SAS-V6-nine-byte-character-variable-name
of SYSFIL003 (temporary, and not KEPT!) was not detected
(until you ran JCLTEST6 under SAS V6!). Deleted one byte.
New support members were NOT changed; they are listed for
documentation only; all require SAS V8 for execution:
-TYPEWWW WebLog requires SAS V8 because web data is long
strings of variable length text that requires V8.2's
support for stored character variables length of 32K.
By using COMPRESS=YES, you don't waste any DASD, but
can have the entire string in one variable.
Both LENGTH and $VARYING4096 text caused error messages.
-TYPEAIX code requires V8.2 for $VARYING4096 statement.
-TYPETMTC code requires V8.2 for $256 length variables,
and PDJULI6. informat; that informat was added in the
SAS Y2K release 6.09E (TS-470) for the IBM mainframe,
and in 6.12 for all other platforms.
Thanks to Freddie Arie, TXU, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 20.001 Never Used.
LASTCHANGE: Version 20.
=========================member=CHANGE19================================
/* COPYRIGHT (C) 1984-2002 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is MXG Version 19.19, dated Feb 14, 2002, thru Change 19.300.
MXG Version 19.11 was dated Feb 4, 2002, thru Change 19.288.
MXG Version 19.10 was dated Jan 28, 2002, thru Change 19.282.
MXG Version 19.09 was dated Jan 21, 2002, thru Change 19.267.
MXG Version 19.08 was dated Dec 20, 2001, thru Change 19.247.
MXG Version 19.07 was dated Nov 3, 2001, thru Change 19.218.
First MXG Version 19.06 was dated Oct 31, 2001, thru Change 19.214.
MXG Version 19.05 was dated Oct 24, 2001, thru Change 19.207.
MXG Version 19.04 was dated Oct 5, 2001, thru Change 19.189.
First MXG Version 19.04 was dated Oct 1, 2001, thru Change 19.183.
MXG Version 19.03 was dated Jul 30, 2001, thru Change 19.151.
First MXG Version 19.03 was dated Jul 26, 2001, thru Change 19.148.
MXG Version 19.02 was dated Jun 1, 2001, thru Change 19.098.
First MXG Version 19.02 was dated May 27, 2001, thru Change 19.097.
MXG Version 19.01 was dated Apr 4, 2001, thru Change 19.060.
First MXG Version 19.01 was dated Apr 3, 2001, thru Change 19.057.
MXG Version 18.18 was dated Feb 12, 2001, thru Change 18.360.
MXG Newsletter THIRTY-EIGHT is dated Feb 12, 2001.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 19.19 is the 2002 Annual Version.
II. Incompatibilities and Installation of MXG 19.19.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 19.19 dated Feb 14, 2001, is available.
Major enhancements added in MXG 19.19:
Support CICS/TS 2.2 CICSTRAN (INCOMPATIBLE).
Support for TYPE94 APAR OW52989, adds 8-way AX0 controlers.
Support for OS/400 Release 5.1.0 Collection Services, in TYPEQACS.
New UTILEXCL program for CICS EXCLUDEd fields automatically creates
an IMACEXCL member to read your records, without any EDITing, but
this major enhancement should be used by ALL sites that read SMF
110 records, even if you do not EXCLUDE fields. UTILEXCL creates
an IMACEXCL member with these performance enhancements:
- a single INPUT statement (more efficient than conditionals)
- eliminates unnecessary arithmetic (avoids missing values)
- KEEPs only the variables that exist in your records; all the
EXCLUDED fields are dropped, and all of the extra variables
that are in the CICSTRAN KEEP= list for new/old versions that
do not (yet) exist in your data are also not kept.
See text of Change 19.293 and examples in member UTILEXCL.
User contributed code to read the output of the unix sar command.
ASMVTOC enhanced to select/exclude VOLSER and UCBs above the line.
Versions 19.12 thru 19.18 were never created.
Major enhancements added in MXG 19.11:
INCOMPATIBILITY: MXG CHANGED LANDMARK SUPPORT FOR IMS, DB2, MVS:
Datetime values are now automatically converted from GMT fo LOCAL
Landmark CICS values are NOT changed, but now could be.
See Change 19.288.
TIMEBILD/TIMETABL/VMXGTIME supports LOCAL and GMT Time Zone deltas
and has identified all MXG datetime variables that contain GMT
(few) in the text of Change 19.286. If you have SYSTEMs on
different time zones that needs to be shifted to a common zone,
of if you have GMT values to change to Local, this massive change
will let you do all of the above. And if you do nothing, it does
nothing; the VMXGTIME() statements do nothing until TIMEBILD has
been invoked for a specific job to change datetimes.
UGMTCHEK Utility will check for datetime variables still on GMT
Major enhancements added in MXG 19.10:
MXG sets OPTIONS COMPRESS=YES as the default. Change 19.279.
MXGLEN=5 (EBCDIC) or MXGLEN=6 (ASCII) LENGTH CHANGE in MXG 19.10.
MXG changes LENGTH DEFAULT=4 to =5 on EBCDIC, to =6 on ASCII, to
eliminate any truncation of PIB4-input numeric variables, and the
stored length of MGBYTES-Format'd PIB4 variables was reduced from
8 to 5/6 to eliminate wasted space. &MXGLEN/&MXGBYLN macro vars
can be %LET if you need to restore original defaults; only known
exposure is if you use PROC APEND, but did not specify FORCE.
No size increase with compress; benchmarks/text in Change 19.272.
Initiator Number and Name variables added to PDB.JOBS and TYPE30_1
but missing until you install the IEFU84 SMF Exit Assembly code
that moves those fields into type 30 subtype 1. Change 22.136.
Major enhancements added in MXG 19.09:
Support for SMF 119 from IBM z/OS V1R2.0 Communications Server.
Support for IBM AIX Performance Toolbox, PTX V2.
You can change the time zone of all SMF datetime variables, by
SYSTEM and TimeRange, to put all of your systems on their own
time zones (EST/PST/GMT) to the common time zone of the floor
of the data center, so you can compare RMF, response, etc.,
when your SYSTEMS are on different time zones. This is in the
VMXGTIME, TIMEBILD, and TIMETABL members.
ML-20 ASMTAPES, wrong DDNAME in MXGTMNT SMF if tape on 4-digit.
Select step records, then corresponding 14 15 & 64s - see ANAL30.
Select SORTs with concat SYSIN, then matching 14 15 - see ANAL16.
Support for WebLogs: IIS, WebSphere, CLF, Cookies+.
Major enhancements added in MXG 19.08:
MXG 19.04-19.07: TYPE73 PCHANBY/PNCHANBY zero, ONLINE wrong.
Support for Crypto (for SSL) RMF 70 Subtype 2 APAR OW49808.
Support for IBM CICS/TS 2.2 Statistics Record TCBs
Support for IDMS Log Statistics Records.
Support for Landmark's TMON for TCP/IP v1.1.
Support for RSD Folders ASTRE Auditing User SMF record.
MXG Software (all versions) supports euro symbol.
New HSM variables, start/end timestamps for HSMFSRST events.
Sample MQ Series reports were enhanced.
Enhanced support for NPM subtypes 18x/19x.
ANALDB2R PMACCnn reports caused ERRORS and ABENDS.
ASUMUOW Doc updated: which _K macro to use for what data.
%GLOBAL macro variables no longer %LET to null value.
Major enhancements added in MXG 19.07:
Errors in datasets PDB.ASUM70PR, PDB.ASUMCEC, and PDB.TYPE70PR
were introduced by MXG 19.05 and not completely fixed by MXG 19.06
changes. IBM's unexpected insertion of segments for spare CPUs in
type 70 records (APAR OW49536) precipitated Change 19.189 to fix,
and that worked fine with 2064 CPUs, but failed with 9672 data.
The next fix took care of 9672s, but that fix created too large
values for LPnDUR, causing bad percentages, but now only on 2064s.
And then a user pointed out that Dedicated CPUs were not quite
correctly summed in ASUM70PR logic. Another user had mis-matched
values for LPAR busy of the same LPAR from three different systems
with MXG 18.18, because he had Dedicated/Wait Complete CPUs, and
(after hours of looking at his data, I re-found my) Change 17.203
that created PDB.ASUMCEC to solve the problem with missing values
and Dedicated/Wait Complete processors. (That the values were not
missing in his 18.18 data was itself an error also now corrected).
And Change 19.201 was needed to correct variable SHIFT in ASUM70PR
and ASUMCEC.
But, in summary, we did not handle that APAR well!
Major enhancements added in MXG 19.06:
Support for Tivoli/Netview NPM 2.6 COMPATIBLE.
Support for NTSMF SMS Objects.
"Support" for DB2 QLES section added to DB2STATS.
Major enhancements added in MXG 19.05:
Support for APAR OW49806, z/OS 1.1 and 1.2 required correction.
Support Windows 2000, SP2 for Exchange 2000, SQLSERVER, objects.
Support for Serena's Ultimizer user SMF record
Support for SMF type 82 crypto facility record.
New RMFINTRV vars PARTISHN TOTSHARE LPARSHAR CECSER
Revised to invoke VMXG70PR to match RMFINTRV interval
Major enhancements added in MXG 19.04:
Support for z/OS Version 1 Release 2, most new stuff (COMPATIBLE):
Existing important SMF and RMF records have been updated, but
some new data records, SMF 109, SMF 119 are not yet written.
See Change 19.176. (SMF 119 support was added in MXG 19.09).
Support for CICS/TS 2.2 Subtype 1 CICSTRAN (COMPATIBLE, unless you
have tailored MXG process any optional "user" segments in your
SMF 110 Subtype 1 Performance record (how to tell?: if you have
any tailored IMACICxx members in your USERID.SOURCLIB).
This support does NOT yet support the Subtype 2 Statistics 110.
See Change 19.181.
Support for IMS 6.1 Fast Path records (INCOMPAT)
Support for CISCO Works Blue ISM user SMF record st 01/05/06/66.
Support for WAS/390 4.0 EE Websphere SMF 120; won't fail, but this
support requires SAS V8.2+ for some character variables to be
valid; IBM introduced "Unicode" UCS/DBCS data in SMF 120's.
New SPINSORT member to sort SPIN if MXG moves from MVS to ASCII.
Documentation of the IHDRxxxx "INFILE" header exits.
Support for NTSMF V 2.4.2.11 & Windows 2000 changes.
Major enhancements added in MXG 19.03:
Support for TPF releases PUT08, PUT10, PUT12 (INCOMPATIBLE).
Support for z/VM 3.1 and VM/ESA 2.4 on z900 CPUs.
Revisions to ASMIMSL5 (5.1) and ASMIMSL6 (6.1 and 7.1) IMS log.
Enhanced ASUMCACH, from 74s: DASD Cache and DASD I/O.
New TYPE42XV dataset for XRC Volume segments.
Correction for TNG STARTIME, two-digit base-36, etc.
Read same MXG dataset from many DDnames/libraries with VGETDDS
Major enhancements added in MXG 19.02:
New MSU calculations were wrong with new z/OS 70 records.
PDB.ASUMUOW now contains USERCHAR from CICSTRAN.
Support for BMC Mainview Batch Optimizer, BMO SMF.
Support for DCOLLECT APAR OW48529, new value.
Support for HMF Subtypes 29, 30, and 31.
Support for IBM changes to Websphere SMF 120 record.
Support for SMF 102 IFCID 096 was corrected.
Support for objects NETWORKINTERFACE and PAGINGFILE.
ANALUSS example sums CPU time from USS/OMVS task's type 30s.
ASMIMSLn deletes IMS 01 records with recovery bit.
CICSTRAN STRTTIME/ENDTIME did not include Leap seconds.
JCL example to use BatchPipes with SAS - big savings!
KEEPALL=YES is now specified in ASUMs to save CPU.
SAS V8.2 WARNING: OPTION BLKSIZE(2311) NOT SUPPORTED.
Spurious SAS NOTE: "might be uninitialized".
TYPE73 records different for SMF73CMG=1 and SMF73CMG=2.
Major enhancements added in MXG 19.01:
z900 2064s and ICFs without OW48190 have wrong CPU count.
- causes CPU busy values to be wrong, too. Change 19.015
DB2ACCT Parallel Transactions are double accounted.
- See 19.027. IBM now "rolls up" child records into duplicate.
Duplicate observations created in MQMMSGDM dataset.
- See Change 19.054. MXG 18.18 error had two outputs.
Support for APAR OW46268 TYPE74 USS Kernel in place.
Support for APAR OW46622 for Temporal Affinity.
Support for CICS TCP/IP EZA01 optional variables.
Support for IMS Version 7.1 Log Records - no changes.
Support for Omegamon/IMS V500 - no changes.
Support for Tandem G06/G07/G08 CPU & DISK records.
Support for Landmark's The Monitor for IMS records.
Support for TLMS Release 5.5 (COMPATIBLE).
Support for CA/TNG new, post-9907 V6, format (INCOMPAT).
CICS CPU time captured is now documented in ADOC110.
Protection for invalid ALOCTIME (before INITTIME).
CHAIN logic in IMF IMS trans corrects negatives.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
MXG 19.19 has been tested with SAS V8.2 and SAS V6.09 on OS/390, and
with SAS V8.2 on Windows 98 and 2000 and Linux RH 7.2, but should run
without error under V8.2 on every possible SAS platform!
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.7.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.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 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
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Oct 31, 2001 19.04
CICSTRAN subtype 1 support only 19.04
CICSTRAN subtype 2 completed 19.05
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 7.1.0 Mar 30, 2001 18.11
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
MQ Series 5.2 Dec 16, 2000 18.10
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
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
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 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
IMS 4.1 Jul 4, 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
AS400 4.5.0 Jul 27, 2000 18.07
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
SAS Institute
MXG executes best under SAS Version 8.2, with 82BX01 HOTFIX for
MVS-OS/390-z/OS which includes Critical 81BA57 fix).
See Newsletter FORTY for expanded discussion of other versions.
Read member NEWSLTRS (search 'V8') for SAS Version 8 notes.
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
Windows 2000 Build 2195 17.10
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
NTSMF Version 2.3 17.10
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 CICS V500 User SMF 18.01
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
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 19.03
IMS 5.1 - ASMIMSL5/TYPEIMSA 19.03
Amdahl
APAF 4.1, 4.3 16.08
II. Incompatibilities and Installation of MXG 19.19.
1. Incompatibilities introduced in MXG 19.19 (since MXG 18.18):
a- Changes in MXG architecture made between 18.18 and 19.19 that might
introduce incompatibilities.
- A small increase, perhaps 5-6MB, of virtual storage may be
required for BUILDPDB due to MXG code changes (new variables
and datasets require more REGION=, and Change 19.272) has
has been observed. If you have a fixed REGION=nnM in your
JCL, even a small increase could cause an ABEND, so you must
compare the region used in your current job (Total Memory on
on the SAS log, for that big DATA step) with your REGION,
and may need to increase your fixed REGION size. At present
REGION=128M is larger than any BUILDPDB, and thus should be
safe, if you can't use REGION=0 and must specify a value.
- COMPRESS=YES is now the MXG default for new datasets. ITSV
sites have always had COMPRESS=YES specified, but if you did
not have that option set, you could see an increase in the
CPU time of BUILDPDB jobs. On some early CMOS systems cost
of compression was significant; you can turn it off with:
OPTIONS COMPRESS=NO;
Our benchmarks on 2064s with 307MB SMF showed:
Data Step sec BUILDPDB total CPU sec
NO YES NO YES CPU increase
18.18 71 -> 110 54% 172 -> 243 41% 71 seconds
19.19 106 -> 123 16% 205 -> 255 24% 50 seconds
The cost of compression with 18.18 was substantially higher
as a percentage than is the cost of compression with 19.19,
which mostly shows how poor percentages can be for real
comparisons. The real cost of total job compression is one
minute of CPU time per day for 300 MegaBytes of SMF data.
And you not only save lots of DASD space, but also avoid the
3am phone call that BUILDPDB had a B37 ABEND!
- Changes between 18.18 and 19.19 (new data, new subtypes
of existing BUILDPDB records) may cause a small increase in
the MXG CPU time for the "Big DATA" step; perhaps 2-3% for
an untailored BUILDPDB. But even when the new VMXGTIME time
zone convert option was enabled, the monster BUILDPDB that
reads almost every IBM and user SMF records, saw only a 12%
increase in the Big Data Step. However, other MXG changes
(KEEPALL=YES in VMXGSUM invocations) actually significantly
reduced the CPU time for the rest of the BUILDPDB job, and
the net increase (again, with VMXGTIME enabled) was only 5%:
Extended BUILDPDB Timings 307MB SMF;
Big DATA step BUILDPDB Job Total
18.18 110 sec 102MB 243 sec 104MB
19.19 123 sec 105MB 255 sec 107MB
Other cross-hardware benchmarks without VMXGTIME enabled
showed 2064 CPU time increased by 3% but by 5% on 9672
- MXG changed Landmark Support code for IMS, DB2, MVS:
Datetime values are now automatically converted from
GMT to LOCAL, as there is an offset in those records.
Landmark CICS values are NOT changed, because I could
not confirm if they should be. See 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.
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. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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.11:
Dataset/
Member Change Description
none 19.234 MXG Software (all versions) supports the euro symbol.
Many 19.176 Support for z/OS Version 1 Release 2 (COMPAT)
ADOC110 19.025 CICS CPU time captured is now documented in ADOC110.
ANAL115 19.231 Sample MQ Series reports were enhanced.
ANAL16 19.257 Select SORTs with concat SYSIN, then matching 14 15.
ANAL30 19.257 Select step records, then corresponding 14 15 & 64s.
ANALDB2R 19.222 ANALDB2R PMACCnn reports caused ERRORS and ABENDS.
ANALQAPM 19.262 Sample AS/400 report from QAPM Perf Monitor data
ANALUSS 19.087 Example to sum CPU time from USS aka OMVS 30 records.
ASMIMSL5 19.135 MXG 19.01-19.02 only. Change 19.061 removed.
ASMIMSL6 19.135 MXG 19.01-19.02 only. Change 19.061 removed.
ASMIMSLn 19.061 IMS 01 records with recovery bit are deleted.
ASMTAPES 19.259 MXGTMNT DDNAME in SMF wrong if tape on 4-digit UCB.
ASUM70PR 19.015 z900 and ICFs without OW48190 have wrong CPU count.
ASUM70PR 19.201 Revised to invoke VMXG70PR to match RMFINTRV interval
ASUMCACH 19.123 Enhanced ASUMCACH, from 74s: DASD Cache and DASD I/O.
ASUMCACH 19.167 INVALID ARGUMENT TO FUNCTION INPUT corrected.
ASUMUOW 19.219 Doc only. Which _K macro to use for what.
ASUMxxxx 19.074 KEEPALL=YES is now specified in ASUMs to save CPU.
AUTOEXEC 19.279 MXG now sets OPTIONS COMPRESS=YES as default.
BLDNTPDB 19.199 Incorrect copying in the weekly phase corrected.
BUIL3005 19.162 JES3-only, variable NETNAME (DJC) now kept in JOBS.
BUILDPDB 19.036 Variable ABENDS in PDB.JOBS counted pseudo steps.
BUILDPDB 19.237 Variable LOCLINFO in PDB.STEPS was not from step.
BUILDPDB 19.269 Initiator Number and Name added to PDB.JOBS.
CONFIGV8 19.089 SAS V8.2 WARNING: OPTION BLKSIZE(2311) NOT SUPPORTED.
FORMATS 19.073 Support for DCOLLECT APAR OW48529, new value.
IEFU84 19.269 SMF Exit to add Initiator Number and Name to SMF 30.
IHDRxxxx 19.232 Documentation of the IHDRxxxx "INFILE" header exits.
IMACICEZ 19.047 Support for CICS TCP/IP EZA01 optional variables.
JCLUOWP 19.079 JCL example to use BatchPipes with SAS - big savings!
MXGBYLE 19.272 Default of MXG numeric variables changed, externalizd
MXGLEN 19.272 Default of MXG numeric variables changed, externalizd
RMFINTRV 19.011 CPCNRCPU,CPFCNAME wrong for CPUTYPE='2064' in 18.18.
RMFINTRV 19.020 %VMXGRMFI(PDB=SMF) error, MERGERMF not found.
RMFINTRV 19.156 Using fewer than the default workloads caused Notes.
RMFINTRV 19.201 New RMFINTRV vars PARTISHN TOTSHARE LPARSHAR CECSER
SPINSORT 19.172 PROC SORT of SPIN if MXG moves from MVS to ASCII.
TIMEBILD 19.260 Change time zone of all datetime variables by SYSTEM.
TIMEBILD 19.286 LOCAL and GMT Time Zone Deltas for VMXGTIME.
TIMETABL 19.260 Change time zone of all datetime variables by SYSTEM.
TIMETABL 19.286 LOCAL and GMT Time Zone Deltas for VMXGTIME.
TRNDCEC 19.150 Example of TRENDing the ASUMCEC dataset.
TYPE102 19.019 Type 102 subtype 140 INPUTE EXCEEDED error.
TYPE102 19.081 Support for SMF 102 IFCID 096 was corrected.
TYPE110 19.028 Variables DSxPERCT in CICDS are endpoint values.
TYPE110 19.076 CICSTRAN STRTTIME/ENDTIME did not include Leap secs.
TYPE110 19.181 Support for CICS/TS 2.2 Subtype 1 CICSTRAN
TYPE110 19.224 Support for IBM CICS/TS 2.2 Statistics Record TCBs
TYPE110 19.293 Support for CICS/TS 2.2 CICSTRAN (INCOMPATIBLE).
TYPE115 19.054 Duplicate observations created in MQMMSGDM dataset.
TYPE116 19.139 Invalid SMF 116 with QWHS length=108 protected.
TYPE119 19.267 Support for SMF 119 IBM z/OS V1R2 CS TCP/IP Product
TYPE120 19.077 Support for IBM changes to Websphere SMF 120 record.
TYPE120 19.180 Support for WAS/390 4.0 EE Websphere SMF 120
TYPE28 19.211 Support for Tivoli/Netview NPM 2.6 COMPATIBLE.
TYPE28 19.221 Enhanced support for NPM subtypes 18x/19x.
TYPE28 19.264 NRPxxxxx variables in NPMINNRP were all missing
TYPE30 19.056 Protection for invalid ALOCTIME (before INITTIME).
TYPE30 19.163 Variable JOBCLASS was unprintable under ASCII SAS.
TYPE30 19.169 Initiator Number and Name added to TYPE30_1 job init.
TYPE30 19.283 Actual Midnight ALOCTIME=0 caused ELAPSTM=24 hours.
TYPE30_D 19.060 Variable BLKSIZE in TYPE30_D, PDB.DDSTATS, wrong.
TYPE42 19.043 TYPE 42 subtype 5 INPUT EXCEEDED reading VSAM SMF.
TYPE42 19.145 New TYPE42XV dataset for XRC Volume segments.
TYPE42 19.147 Invalid SMF 42-5 protected.
TYPE42 19.160 Type 42 subtypes 7 and 8 were revised.
TYPE42 19.173 INPUT STATEMENT EXCEEDED, SMF 42 ST 6, invalid.
TYPE60 19.174 INPUT STATEMENT EXCEEDED, VVRTYPE='Z' SMF 60.
TYPE7072 19.018 Zero-divide by SMF70CPA corrected (no impact).
TYPE7072 19.245 Support for CRYPTO RMF 70 Subtype 2 APAR OW49808.
TYPE70PR 19.030 LPARCPUS=0 if back level OS/390 and no OW37565.
TYPE70PR 19.189 APAR OW49536 "spare" LPARCPUS/LPnNRPRC counted.
TYPE71 19.270 CSFRLSAV/ESFRLSAV can be small negative, reset to 0.
TYPE73 19.084 Offline channels in TYPE73, document CMG=1 and CMG=2.
TYPE73 19.240 MXG 19.04-19.07: PCHANBY/PNCHANBY/ONLINE were WRONG.
TYPE74 19.017 Support for APAR OW46268 TYPE74 USS Kernel in place.
TYPE74 19.186 "Broken" 74 subtype 4 incorrectly output in TYPE74CF.
TYPE74 19.239 TYPE74CF/TYPE74ST some R744S/R744F variables wrong.
TYPE78 19.070 TYPE78SP's _BTY73SP BY list didn't remove all dupes.
TYPE78 19.203 Support for APAR OW49806, z/OS 1.1 and 1.2 correction
TYPE79 19.051 Support for APAR OW46622 for Temporal Affinity.
TYPE82 19.200 Support for SMF type 82 crypto facility record.
TYPE91 19.241 Batch Pipes datasets have added variables for merge.
TYPE94 19.290 Support for APAR OW52989, adds 8-way AX0 controlers.
TYPEAIX 19.261 Support for IBM AIX Performance Toolbox, PTX V2.
TYPECIMS 19.031 CHAIN logic in IMF IMS trans corrects negatives.
TYPECISM 19.158 Support for CISCO Works Blue ISM user SMF record.
TYPEDB2 19.027 DB2ACCT Parallel Transactions are double accounted.
TYPEDB2 19.213 DB2 V7 QLES section variables added to DB2STATS.
TYPEEDGR 19.252 Variables added by OW40710 in 1999 now added in MXG.
TYPEEDGS 19.284 DFSMS/rmm "V" records had blank MVDSNx variables.
TYPEHMF 19.082 Support for HMF Subtypes 29, 30, and 31.
TYPEHSM 19.227 New vars, start/end timestamps for HSMFSRST events.
TYPEIDML 19.244 Support for IDMS Log Statistics Records.
TYPEIMS 19.046 Support for IMS Version 7.1 Log Records.
TYPEIMS 19.242 IMSGTEXT/OMSGTEXT were incorrect.
TYPEIMS7 19.117 NMSGPROC in IMS0708 no longer counts unmatched 08's.
TYPEIMSA 19.177 Support for IMS 6.1 Fast Path records (INCOMPAT)
TYPEIMSA 19.188 Times were GMT vice local: IMS SRV/RES/ TM/TS.
TYPEITRF 19.003 Support for Omegamon/IMS V500 - no changes.
TYPEMBO 19.067 Support for BMC Mainview Batch Optimizer, BMO SMF.
TYPEMPLX 19.185 Support for the Implex User SMF record.
TYPENDM 19.275 NDMCPUTM added in NDM/Connect Direct records.
TYPENSPY 19.044 NETSPY type 'R' INPUT STATEMENT EXCEEDED.
TYPENTSM 19.065 Support for objects NETWORKINTERFACE and PAGINGFILE.
TYPENTSM 19.148 Support for NTSMF V 2.4.2.11 & Windows 2000 changes.
TYPENTSM 19.153 Corrections for Process with NRDATA=27, old NTSMFs.
TYPENTSM 19.197 New Windows 2000, Exchange 2000, etc, objects.
TYPENTSM 19.214 Support for NTSMF SMS Objects.
TYPENTSM 19.276 MSEXCHANGE DS object has new variables.
TYPEQACS 19.289 Support for OS/400 Release 5.1.0 Collection Services
TYPERSDA 19.229 Support for RSD Folders ASTRE Auditing User SMF rec.
TYPESFTA 19.166 Soft Audit variable STEPNAME contained SYSTEM.
TYPESHDW 19.032 Shadow Direct INPUT STATEMENT EXCEEDED error.
TYPESTC 19.264 Zero observations in HSC dataset STCHSC from STK SMF.
TYPESYNC 19.004 Array name DD conflicts with existing DD variable.
TYPESYNC 19.228 VARIABLE UNIT1 HAS BEEN DEFINED AS BOTH CHARACTER
TYPETAND 19.029 Support for Tandem G06/G07/G08 CPU & DISK records.
TYPETCP 19.053 SMF 118 ERROR.4. HFS FILE error created in error.
TYPETIMS 19.050 Support for Landmark's The Monitor for IMS records.
TYPETIMS 19.288 Landmark for IMS datetime variable now on Local zone.
TYPETLMS 19.013 Support for TLMS Release 5.5 (COMPATIBLE).
TYPETMDB 19.288 Landmark for DB2 datetime variable now on Local zone.
TYPETMNT 19.088 INITTIME could be off by one day.
TYPETMS5 19.164 TMS Audit variables TMAUxxxx/TMVAxxxx correct now.
TYPETMTC 19.225 Support for Landmark's TMON for TCP/IP v1.1.
TYPETMV2 19.288 Landmark for MVS datetime variable now on Local zone.
TYPETMV2 19.297 Support for Landmark Monitor for MVS Version 3.
TYPETNG 19.009 Support for CA/TNG new, post-9907, format (INCOMPAT).
TYPETNG 19.146 Correction for TNG STARTIME, two-digit base-36, etc.
TYPETPF 19.125 Support for TPF releases PUT08,PUT10,PUT12 INCOMPAT.
TYPETPF 19.136 TPF datetimes now corrected from GMT to local zone.
TYPETPF 19.170 TPF enhancements for wrapped counters.
TYPETSOM 19.075 New TSMPxxxx variables now kept in TSOMCALL dataset.
TYPEULTM 19.202 Support for Serena's Ultimizer user SMF record
TYPEVMXA 19.132 Support for z/VM 3.1 and VM/ESA 2.4 on z900 CPUs.
TYPEWWW 19.249 Support for WebLogs: IIS, WebSphere, CLF, Cookies+.
UGMTCHEK 19.287 Utility to check for datetime variables still on GMT
UGMTCHEK 19.287 Utility to examine if GMT values are in your data.
UNIXSAR 19.294 User contribution reads unix sar -A -f reports.
UTILCVRT 19.271 Utility converts historic MVS PDB's $HEX on ASCII.
UTILEXCL 19.293 UTILEXCL creates IMACEXCL without EDIT for CICS.
VGETDDS 19.116 Read same MXG dataset from many DDnames/libraries.
VGETOBS 19.247 New MXGDSN macro variable exist/zero obs detection.
VGETxxx 19.002 Documentation of VGETxxx macro naming convention.
VMXGDEL 19.268 Replaced use of PROC SQL/VTABLE in internal macro.
VMXGDEL 19.295 Lower case work. did not match upper case WORK.
VMXGDUR 19.282 SYNC59=NO specification did not work.
VMXGINIT 19.230 %GLOBAL macro variables no longer %LET to null value.
VMXGINIT 19.279 MXG now sets OPTIONS COMPRESS=YES as default.
VMXGOPTR 19.268 Replaced use of PROC SQL/VTABLE in internal macro.
VMXGRMFI 19.083 New MSU calculations wrong with new z/OS 70 records.
VMXGSUM 19.151 Use of TEMP01/TEMP02/TEMP03 revised.
VMXGSUM 19.246 New HOUSKEEP= option to leave temporary datasets.
VMXGSUM 19.251 &MXGLEN added, TEMPnn logic corrected, PROC SQL fix.
VMXGTIME 19.260 Change time zone of all datetime variables by SYSTEM.
VMXGTIME 19.286 LOCAL and GMT Time Zone Deltas for VMXGTIME.
VMXGUOW 19.092 PDB.ASUMUOW now contains USERCHAR from CICSTRAN.
VMXGWORL 19.063 Spurious SAS NOTE: "might be uninitialized".
Inverse chronological list of all Changes:
NEXTCHANGE: Version 19.
=======Changes thru 19.300 were in MXG 19.19 dated Feb 14, 2002=========
Change 19.300 One site using MXGTMNT MXG Tape Mount Monitor found their
ASMTAPES LOGREC filled with MXGTMNT generated X'E0' ABEND messages
Feb 13, 2002 to the extent that they had to stop MXGTMNT. This site
is a massive user of virtual tapes, and the E0 results
when the monitor saw the job at one pop, but the job is
no longer in the system a 2-second pop later, because its
done its virtual mount and ended in milliseconds.
The original design used a previously saved ALET during
cross-memory access to an address space for which a tape
mount occurred, but, no check was made to see if the ALET
has been invalidated because the job had ended.
Instead, this redesign will
- Save the ASID and JOBNAME for the job associated with
the device when it sees a mount pending, and now save
the STOKEN for the address space. Each STOKEN value is
unique across the life of the IPL, whereas the ASID and
the ALET are not.
- When the CROSSMEM routine executes, it checks to see if
the STOKEN for the address space it is in (ASSBSTKN in
the ASSB) matches what was saved previously when the
mount was detected; if it matches, it's safe to do the
SAC instruction. If the STOKEN does not match, then
the original address space that caused the mount is
indeed gone, and we will stop CROSSMEM processing for
that address space.
-The SMF record will be written the same way a job
change is currently handled: MXGTMNT writes out the
SMF record as it is up to that point, without the
allocation information in it. The data currently
captured from the ACEE, JCT, OUCB, ACT, JMR, DSAB, and
the SCT will be missing from these records.
This enhancement to MXGTMNT will be "ML-21" and the
ASMTAPES member will have that noted at its beginning.
As of the February 14 start of tape build for MXG 19.19
this change has only been designed; if you encounter
significant counts of LOGREC 0E ABEND messages from the
MXGTMNT program, please request the "ML-21" level of
the ASMTAPES member, and it will be sent when tested.
Feb 27, 2002: ML-21 is now available, Change 20.011.
Change 19.299 MXG Messages "New NTSMF OBJECT Found" did not contain the
VMACNTSM name of the SYSTEM with the new object, making it hard to
Feb 13, 2002 know on which system to enable NTSMF's DISCOVERY option.
Sending the discover file to support@mxg.com is all that
is needed to add support for the new object into MXG.
But if that message has OBJECT=, then you
will need to contact NTSMF support, because that message
results when the MicroSoft code-writer failed to comply
with standards, so the NTSMF programmers have to develop
a fix to Cover Their Actions and get the correct name.
Thanks to Denny C. Wong, New York Life Insurance, USA.
Change 19.298 Variables for Storage Class name are now input in subtype
VMACSTC 16, 17, and 18 STK records, as is STC17MVC, the VOLSER in
Feb 13, 2002 subtype 17.
Thanks to John Ellis, Powergen Retail, ENGLAND.
Change 19.297 Support for Landmark TMON for MVS Version 3.0 (INCOMPAT).
VMACTMV2 The documentation does not agree with their actual data,
Feb 13, 2002 but by considerable sleuthing I believe I have found what
Oct 17, 2002 was changed, but you must validate this support with your
data, and report any discrepancies to support@mxg.com.
The DV record is bypassed because it has inserted data
that I can't figure out, but these 3.0 datasets have been
created and printed and look okay except as noted:
XIS, XIM, XI, WG , TR (DURATM is in error in the record)
SYS, YSSW, YSUI, PS (CHANGED) NQ, MLV, MLL, MLG, LC,
JDSW, JDDL, JDIN (suspect) EL CS,CP,CH,CF (suspect)
Oct 17, 2002: Support for TMON/MVS V3.0 and 3.1 is
now in member TYPETMVS/TYPSTMVS/VMACTMVS and not in
the TMV2 suffixes. See Change 20.201.
Thanks to John Jackson, REDCATS (UK), ENGLAND.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 19.296 While DCOLLECT is generally used to graze your DASD farm
ASMVTOC for dataset space, etc., there are cases when ASMVTOC is
Feb 13, 2002 needed, and this revision will make it easier and better
when you need to look at all the VTOCs.
-The program now allows Volume select/exclude processing,
so you can avoid multiple scans of volumes shared between
images. To invoke select/exclude, set PARM='VOLLIST' and
add a //VOLLIST DD.
-The program revised the CVAFSEQ access to handle UCBs
that are above the line.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 19.295 An ITSV-only problem appears to have been introduced by
VMXGDEL SAS Version 8.2; apparenly the ITSV %CMSTART macro now
VMXGINIT sets the option USER='work', and VMXGDEL tried to compare
Feb 13, 2002 work.DB2STAT2 with WORK.DB2STAT2, which was not equal, so
VMXGDEL deleted the WORK.DB2STAT2 dataset it had built.
This change protects the VMXGDEL test with UPCASE, but
also VMXGINIT was enhanced to force the USER and SASWORK
options to upper case if they had been lower case, for
consistency.
Thanks to Roderic Gass, British Energy Group, ENGLAND.
Change 19.294 This user contribution processes unix sar reports files
UNIXSAR created with the command sar -A -f sardata.mmmyy
Feb 12, 2002 This preliminary code will eventually be revised into the
normal MXG member naming, macros, etc, but this code will
give you access to the sar information now.
Thanks to Carmen Vitullo, Acxiom, USA
Thanks to Uriel Carrasquilla, NCCI, USA.
Change 19.293 -Support for CICS/TS 2.2 CICSTRAN (INCOMPATIBLE, IBM again
VMAC110 inserted new fields in their SMF 110 subtype 1 records.
UTILEXCL -New UTILEXCL program for EXCLUDEd fields in CICS records
Feb 9, 2002 automatically creates the tailored IMACEXCL member from
Feb 11, 2002 your CICS dictionary SMF records, eliminating any manual
EDITing of the IMACEXCL member. In addition, using the
UTILEXCL to create an IMACEXCL member, even if you don't
exclude fields, will provide performance benefits:
- a single INPUT statement for each APPLID is created;
the default TYPE110 code has many conditional tests
that break up the INPUT statement, and that is more
CPU-expensive that a single INPUT execution.
- conversion statements (times are multiplied by 16) are
only generated for the fields that are input. The
old IMACEXCL you created skipped over Exclude fields,
but then all variables were converted, causing many
unnecessary calculations on missing values, which is
itself a performance negative in SAS V8.
- all EXCLUDEd fields are DROPped automatically, so you
do not have to tailor the KEEP or DROP macros for the
CICSTRAN dataset.
This is new and very powerful; see its comments.
And this design will be enhanced: I would like to detect
changes in your CICS dictionary and create a new IMACEXCL
that can use SMFTIME to differentiate the old from the
new records from the same APPLID, in a future revision.
Change 19.292 Overdue cleanup of TRENDing for DB2 datasets has correct
TRNDDB2A spelling of all variables and KEEPALL=YES is specified on
TRNDDB2B each VMXGSUM invocation so they work. The TRNDDB2X member
TRNDDB2S summarizes the DB2STATB, Interval Buffer Statistics, by
TRNDDB2X Buffer Pool, named TRNDDB2X because TRNDDB2B is used for
Feb 8, 2002 the DB2ACCTB (Plan Buffer Details, by Buffer Pool).
Change 19.291 The NOAMSGID field in the Version 2.3 record is now an
VMACNOAM 8-byte character variable, instead of a 2-byte numeric,
Feb 6, 2002 so it is now input into new variable NOAMSGCH.
Thanks to Mike Fry, HSBC, ENGLAND.
Change 19.290 Support for IBM SMF 94 record, APAR OW52989 that added
VMAC94 support for 8-way AX0 controllers (AX0 to AX7). MXG will
Feb 6, 2002 input the additional 4 AXO's data fields when they are
present.
Thanks to Alex MacFarlane, Bank of New York, USA.
Change 19.289 MXG Support for OS/400 Release 5.1.0 Collections Services
EXQAPJOL was added in the TYPEQACS member (introduced in 4.5 for
EXQAPJOM IBM's first Collection Services), instead of the TYPEQAPM
EXQAPJOM member, because the records were completely incompatibly
EXQAPJOL restrucured, and in three instances, split apart. While
EXQAPPOB the Member name you execute is changed from QAPM to QACS,
EXQAPPOL all datasets created still start with QAPMxxxx and all of
EXQAPPOT the former variable names are preserved. Three old files
EXQAPSYC are split: JOBS, POOL, and SYS. For example, from IBM's
EXQAPSYL Collection Services documentation:
EXQAPSYT Performance data files: QAPMJOBS and QAPMJOBL.
IMACQACS The QAPMJOBL file is provided for compatibilty with
TYPEQACS the PM and combines data from QAPMJOBMI and QAPMJOBOS
TYPSQACS files. The QAPMJOBS file is created when the PM
VMXGINIT database files are migrated with the Convert
Feb 6, 2002 Performance Data commmand (CVTPFRDTA) to the new
Feb 9, 2002 release, but Collection Services does not create the
QAPMJOBS file.
MXG will create QAPMJOBL, or QAPMJOBM, or QAPMJOBO, from
whichever those three files you create, but it appears
the new "Logical" dataset, QAPMJOBL, contains all that
was in the old QAPMJOBS dataset, so the JOBMI/JOBOS files
probably are not needed. And similarly, the POOL records
are split and create QAPMPOLB, QAPMPOLL (old QAPMPOOL),
and QAPMPOLT datasets from those three Pool files, and
the SYS records now create QAPMSYSC, QAPMSYSL (old
QAPMSYS), and QAPMSYST datasets from those files. Your
choice of macros you invoke in your copy of TYPEQACS
determines what MXG will create. This changes has been
validated with all of the above records, plus QACSCONF
and QACSDISK, but there are three new records (JSUM, TCP,
and TCPIFC) that have not been requested (i.e., test
data). The list of specific LRECLs that must be used to
upload to MVS (or to use in your FILENAME statement on
ASCII) are listed in the comments in VMACQACS.
Thanks to Paul Gillis, Pacific Management Systems, AUSTRALIA.
Thanks to Gary Katerelos, Coles Meyer, AUSTRALIA.
Thanks to Martyn Jones, ABN-AMRO, THE NETHERLANDS.
======Changes thru 19.288 were in MXG 19.11 dated Feb 4, 2002======
Change 19.288 MXG Support for Landmark's IMS, DB2, and MVS products is
VMACTIMS changed INCOMPATIBLY, possibly, because all datetimes are
VMACTMDB now converted from GMT to LOCAL, using the record's GMT
VMACTMO2 offset, which is the way is should have been done.
VMACTMV2 IF YOU USE THESE PRODUCTS, YOUR TIMES WILL CHANGE FROM
Feb 3, 2002 GMT TO LOCAL, OR IF YOU ARE ALREADY CHANGING THOSE FIELDS
IN MXG EXITS OR IN OUR REPORTS, YOUR REPORTS WILL CHANGE
FROM RIGHT TO WRONG, and you will need to remove your
tailoring code. (Of course, if your site's GMT offset is
zero, no change in before or after values will occur.)
Alternatively, you could use the new TIMEBILD/TIMETABL
in Change 19.286 to change those local times back to
GMT, using a TIMETABL just for these MXG jobs with the
negative of the GMT offset in the LOCAL delta entry,
and with SYSTEM blank. help.
Note that ONLY Landmark IMS, DB2, and MVS were changed;
the CICS support in TYPETMO2 is still unchanged, because
there IS no GMT offset in those records. In fact, you
can now use the new TIMEBILD architecture for your
TYPETMO2 jobs to convert those GMT datetimes into local.
Change 19.287 Utility UGMTCHEK selects all datetime variables in all
UGMTCHEK datasets in a SAS data library, PROC PRINTs only those
VMXGPRAL variables from the first observation, and PROC MEANS to
Feb 2, 2002 get the min and max value of each datetime variable, so
that you can see whether a datetimestamp is on the local
or GMT time zone. Change 19.286 required knowledge of
the zone of each datetime variable, rarely found in the
record's documentation; only actual data can confirm the
time zone of a datetime variable, hence this new utility.
MXG always intends to convert datetime variables to the
local timezone, if a GMT offset is present in the record,
and for the vast majority of data, times are local zone.
UGMTCHEK requires SAS V8 because it uses the AUTONAME
option (so variable names in MEANS output are appended
with their statistic: SMFTIME_MIN and SMFTIME_MAX for
these reports; it is still my intention NOT to create any
real MXG variables in MXG datasets with names longer than
8-characters, but AUTONAME was perfect for this report.
UGMTCHEK uses %VMXGPRAL to "PRint ALL datasets in a SAS
Data Library"; VMXGPRAL was revised to choose any or all
of the three procs (CONTENTS, MEANS, PRINT) to execute;
in this instance, I only wanted a PRINT of each dataset.
Change 19.286 LOCAL and GMT Time Zones Delta conversion in VMXGTIME.
IMACINIT -This enhancement to Change 19.260 supports two time zones
TIMEBILD in TIMETABL: a LOCAL delta for datetime variables on the
TIMETABL local time zone, and a GMT delta for those few variables
VMACmanymany still on GMT time zone (because there is no GMT-offset
VMXGTIME in their record). All GMT-time-zone datetime variables
VMXGINIT were put in separate %VMXGTIME source statements:
Feb 2, 2002 %VMXGTIME(.list-of-GMT-vars.,SYSTEM,GMT=YES)
Feb 5, 2002 so that VMXGTIME uses the GMT delta column in TIMETABL
Feb 8, 2002 member to convert those variables.
Feb 11, 2002 Almost all important variables are in local time zone,
but actual data is the only way to know for sure, so
all possible data records were run thru the UGMTCHEK
utility that display the actual values of each variable
that has a datetime format in all datasets in a PDB.
But since vendors can add GMT offsets, and they will be
used when found, you should use UGMTCHEK against your
own datasets to confirm and validate your datetimes.
The full list of GMT variables is at the end of this
change, and it will be revised if vendors add GMT
offsets to their records, or if your validation shows
that I've overlooked something.
If there is a difference in your datetime values, check
your "USERID.SOURCLIB" Exit members (EXdddddd) to see
if the previous MXG-person changed those values in your
installation tailoring exit member.
The specific case that created VMXGTIME was a site with
multiple LPARs, each on different time zones, and this
change is running in production to bring all of those
data to the common, local time zone of the data center.
But for records that do not contain a GMT Offset, you can
now enable TIMEBLD with a zero LOCAL Delta and your site
GMT offset for the GMT delta, and convert GMT datetimes
based on your instructions in TIMETABL.
Most MXG datetimestamp variables contain local time; the
SMFSTAMP/RMFSTAMP informats are local; most TODSTAMPs are
GMT, but are converted if there is a GMT offset. Records
that contain only the first 4-bytes of GMT offset were
originally decoded with this calculation:
INPUT OFFSET &IB.4. @; OFFSET=1.048576*OFFSET;
but the result can be off by a second, it has no obvious
reason for that constant, and must be "rounded" to give
picture-pretty values. And now, real logic can be used
to replace that engineering estimate:
INPUT GMTCHAR $CHAR4. @;
OFFSET=INPUT( (GMTCHAR!!'00000000'X),&IB.8.6)/4096;
IF . LT OFFSET LT 0 THEN OFFSET=CEIL(OFFSET);
ELSE OFFSET=FLOOR(OFFSET);
Only a few members had the old code.
Two very important "token" variables that are necessary
to match records together, READTIME and UOWTIME, are
NOT converted by VMXGTIME:
READTIME - its time zone is that of the SYSTEM that saw
the job card, but the records on this SYSTEM
do not tell where the job was input (except
for the type 26 purge record), so it is not
possible to correctly re-zone READTIME. And
even if it were, you would have the READTIME
in your PDB datasets different that READTIME
in the other (unprocessed) SMF data.
UOWTIME - similarly, it's time zone is unknown, and it
must be unchanged to allow CICS and DB2 to
be merged in ASUMUOW.
The variables below are still in GMT time zone (because
there is no GMT offset value in their data records) so
they are in VMXGTIME (GMT=YES) statements, and will be
converted only if you have a non-zero GMT-offset value
in your TIMETABL member:
VMAC110:
A06GOFTM A06GONTM A08GBKCD A08GBKDD A14GACT A14GADT
A17GCLST A17GOPNT AUSGOFTM AUSGONTM D2GCONGM D2GDISGM
DS2LSTRT DS2START DS3LSTRT DS3START DS4LSTRT DS5LSTRT
DS6LSTRT DSGLRT DSGLSTRT DSGLSTRT DSGLSTRT DSGSTART
GLRHGMT GLRUGMT SORCLOSG SOROPENG STACTIME STADTIME
STGCSTRT STGLRTVL
VMAC116:
WQCLOSTI WQOPENTI WTASINTE WTASINTS WTASSTRT
VMAC119:
CITITIME CTTITIME CTTTTIME FCSETIME FCSTTIME FSSETIME
FSSTTIME NIINTIME NTTITIME NTTTTIME STTIME TITIME
TTETIME TTSTIME UCCTIME UCOTIME
VMAC42:
STARTIME ENDTIME
S42EXSTM S42EXETM
S42CCSST S42CCEIT S42CCSET
VMACCMF:
CMF29SCK CMF29TIM SMF29ECK SMF29PCK
VMACACF2:
ACSMFTOD LIDLUPT LIDPSTOD
VMACAPAF:
APAFTOD IMLTOD LITOD UPDATE
VMACASXT:
RSIOMT RSIO RCENDT
VMACHURN:
HU01RST HU02END HU05RST HU06RST HU08RST HU09RST
HU10RST HU11RST HU12RST HU12TIM1 HU12TIM2 HU12TIM3
HU12TIM4 HU12TIM5 HU13ETIM HU13RST HU13STIM HU16SSTM
HU22RST HU24RST HU25RST HU26RST HU40DRST HU42CRTM
HU47ONDT HU47RST HU49ONDT HU49RST HU50CRTM HU51CRTM
HU51DRST HU51RST HU52DRST HU52RST HU60CRTM HU60DRST
HU60SSTM HU61CRTM HU61DRST HU61RST HU62CRTM HU62DRST
HU62RST HU62SSTM HU72CRTM HU72DRST HU72RST HU72SSTM
HU72TSTM
VMACOMSM:
OMFS2STM OMFS2ETM OMFS2JTM
VMACSTC:
STC09TIM STC13MET STC13MST STC13TIM STC14TIM STC16MET
STC16MST STC18MET STC18MST STC18TIM STC19RET STC19RST
STC19TIM STC23TIM STC26MET STC26MST VARDATI VARDATL
VMACSUNS:
ENDTIME
VMACTMV2:
ENDTIME JDINTST JDITIME JDJETIME JDJSTIME JDOSTCK
JDRDTIME JDSETIME JDSSTIME LMRKCARK STARTIME TRLAST
TRSTCK TRSTK1 TRSTK2 TRSTK3
-Performance Impact:
- Changes between 18.18 and 19.19 (new data, new subtypes
of existing BUILDPDB records) may cause an increase in
the MXG CPU time for the "big DATA" step: perhaps 3%
for an untailored BUILDPDB, and as much as 12% at one
test site with a heavily tailored and extended PDB that
contains almost all possible IBM and user SMF records.
However, the CPU time for the post-big-DATA processing
was significantly with 19.19 than with 18.18, so the
net increase in the entire BUILDPDB job was only 5%:
Extended BUILDPDB Timings 307MB SMF;
Big DATA step BUILDPDB Job Total
18.18 110 sec 102MB 243 sec 104MB
19.19 123 sec 105MB 255 sec 107MB
- Many %VMXGTIME() invocation statements were added in
source code, but MXG initialization invokes %TIMEBILD
with TIMEBILD=NO to create a dummy %VMXGTIME macro that
has minimal impact on CPU and virtual storage costs.
- Enabling %TIMEBILD in your //SYSIN will create the real
%VMXGTIME macro, with a small, measurable compile cost,
but the actual execution CPU costs depend on how many
variables in how many records are actually changed.
- BUILDPDB with only default SMF records with no DB2/CICS
(375K records, 1.1GB) showed no increase between 18.18
and 19.19. Enabling VMXGTIME, CPU increased from 9 to
10 minutes.
- BUILDPDB with only default RMF records (4.8GM) also had
no increase between 18.18 and 19.19; enabling VMXGTIME
increased 79 seconds CPU time to 98 seconds.
MXG 19.07 base - 1637 CPU secs Virtual 69411K
MXG 19.19 disabled - 1638 CPU secs + 0% Virtual 69574K
MXG 19.19 enabled - 1839 CPU secs +12% Virtual 70951K
- The delta between 19.07 and 19.19 VMXGTIME-disabled
run shows there was no cost in adding that code.
- The VMXGTIME-enabled increase of 201 seconds is the
(small, fixed) compile-time cost of each %VMXGTIME
statement, and the actual execution costs to change
377 variable's values across those 10 million SMF
records to shift all records to the local zone.
There were 210 VMACxxxx members that were EDITed for this
change, with 1054 %VMXGTIME statements added that list in
excess of 1,500 datetime variables.
-Feb 8 revision. TIMEBILD with TIMEBILD=NO is now invoked
at MXG Initialization to create a null %VMXGTIME macro,
so there is NO cost for those %VMXGTIME() statements
added in MXG source code to provide this enhancement.
-Unrelated, but done as part of this change, there is a
new IMACINIT, for user tailoring at MXG Initialization,
which is included as the last statement each time that
%VMXGINIT is initialized or re-initialized. Likely very
few sites will ever need it, but now it's there.
-If you enable TIMEBILD, you can get a count of how many
variables were changed by adding this statement:
%PUT MXG USED VMXGTIME TO CONVERT &MXGTIMEC VARIABLES.;
at the end of your sysin.
Change 19.285 Incorrect macro references caused syntax errors if you
VMXG70PR used the OUT70PR= WORK.ASUM70PR or OUTCEC=WORK.ASUMCEC
Feb 1, 2002 arguments of %VMXGRMFI to send those two datasets to WORK
(VMXG70PR was wanted to only update the PLATxxxx vars in
the PDB.RMFINTRV dataset). The correct macro references
now work as documented.
Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY.
Change 19.284 DFSMS/RMM "V" records have changed at some point in the
VMACEDGS past, but unless you wanted the MVDSNx fields, you would
Jan 31, 2002 not have notices. The +58 in the INPUT for the V record
is now +122 to skip over the new blank data inserted in
the record.
See Change 21.122, which changed the +122 back to +58,
and externalized the value in MACRO _LNEDGS.
Thanks to Bruce J. Danderline, Memorial Sloan Kettering, USA.
Change 19.283 My very earliest (1972) heuristic, to identify steps that
VMAC30 did not Allocate or Load by setting ALOCTIME or LOADTIME
Jan 31, 2002 to a missing value, was based on exact zero values in the
Feb 1, 2002 raw data, but has finally been exposed by a step that did
allocate exactly at midnight (0.00), causing ALOCTIME to
be wrong, ELAPSTM to be 24 hours, and ALOCTM negative in
step and interval datasets. A heuristic is required here
because IBM only provides times, without dates, for these
events timestamps. This revision eliminates any exposure
to incorrectly setting LOADTIME, now setting it missing
only when virtual storage was not acquired; if PVTTOP=0
PVTTOP=0, the "PROGRAM FETCH" event never occurred. And
with this external criteria to guarantee LOADTIME valid,
ALOCTIME can be always valid when LOADTIME is nonmissing.
One remaining exposure cannot be corrected: a step that
did not load, so it has LOADTIME=., but had an allocation
start time exactly at midnight, will still have ALOCTIME
missing, rather than a midnight time on potentially the
wrong date, because there is no separate criteria to tell
whether that was a midnight or a no-allocate event, but
since LOADTIME is missing in this case, ALOCTIME is far
more likely to have also been missing, and not midnight.
SMF 30 records for STCs for O/MVS a/k/a USS can be valid
but appear inconsistent. Step records for JOB=BPXAS with
both ALOCTIME and LOADTIME missing, but a SELAPSTM of 45
minutes, and with PVTBOT and PVTTOP both zero but with a
small non-zero CPUTCBTM recorded have been observed; the
examples all had PGM=IEFIIC, the initator program name.
Because Change 19.056 reported that the ALOCTIME can be
slightly earlier than INITTIME, and won't be fixed by IBM
a 5-second fuzziness is included in the revision.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 19.282 Explicitly specifying SYNC59=NO in $%VMXGRMFI invocations
VMXGDUR did not work, printed "uninitialized variable NO " notes,
Jan 30, 2002 and could create incorrect datetime value; even though
SYNC59=NO is the default in VMXGRMFI and works. The user
found that SYNC59=N circumvented this error, that occurs
only if you add SYNC59 to your invocation of
%VMXGRMFI(PDB=...,SYNC59=NO);
The actual error was in the VMXGDUR macro that is called
by %VMXGRMFI, and its handling of SYNC59 is now correct.
Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY.
======Changes thru 19.281 were in MXG 19.10 dated Jan 29, 2002======
Change 19.281 Internal utility macro %VGETOBS is now modified to test
VGETOBS that DDNAME is not blank; instead of failing, it will pop
Jan 29, 2002 a warning message and will set the DDNAME to WORK.
Thanks to Michael Oujesky, MBNA, USA.
Change 19.280 WebLog read fails if the ASCII-to-EBCDIC conversion table
VMACWWW in the ftp/upload program that moved the web log to MVS
Jan 29, 2002 changed left/right ASCII square brackets into 'AD'x/'BD'x
instead of the expected 'BA'x/'BB'x hex values. IBM's
"Yellow Card" does show 'AD'x/'BD'x for EBCDIC square
brackets, and some editors and (we now know!) some ftp
packages also output AD/BD values, but IBM's own ISPF/PDF
editor has always created the BA/BB value that is in MXG
source code on MVS! Now, when MXG code that reads data
records with brackets as delimiters is executed on MVS,
MXG will use the TRANSLATE function to change 'AD'x/'BD'x
into 'BA'x/'BB'x so either delimiter will be recognized.
Thanks to MP Welch, SPRINT, USA.
Change 19.279 MXG now sets option COMPRESS=YES by default, to enable
AUTOEXEC compression of new SAS datasets, to significantly reduce
CONFIGV8 the disk space required for work and PDB libraries:
CONFIGV6 - primarily to eliminate unnecessary out-of-space ABENDs
CONFIGxx that wake up a human at 3 am when BUILDPDB fails,
Jan 28, 2002 - Avoid B37 ABENDS
- Job that now needs two or more work volumes will still
run without changing its JCL to UNIT=(SYSDA,3)
- Big reduction in I/O time and I/O conflicts
- Faster run time: lots on Intel, somewhat on IBM
- Automatic; no human intervention or action on your
part is required; many sites already made this choice
- For MXG under ITSV: no impact; ITSV has always used
COMPRESS=YES default option.
- Reversible; just specify OPTIONS COMPRESS=NO; as your
first statement in the //SYSIN stream.
Those benefits far outweigh the only possible negative:
a moderate increase in CPU time on old CMOS pre-G6 CPUs.
The savings in human intervention alone is worth the very
small increase in CPU time of your MXG jobs.
Benchmarks in Newsletter FORTY justify this change.
-All CONFIGs now have OPTION SOURCE, so that the SAS code
statements in your //SYSIN stream will be printed on the
SAS log (so I can figure out what program you are running
if you have a problem).
Change 19.278 Support for RMDS 2.3 added new RMDSORG=5 RMDSACT=A Report
FORMATS with several new variables in TYPERMDS, and new Sign On
VMACRMDS and Sign Off RMDSORG=4 RMDSACT=U/X events with no new
Jan 28, 2002 data fields. FORMATS was updated for RMDSORG values.
Thanks to Bruno Peeters, Dexia Bank, BELGIUM.
Change 19.277 New examples of Availability Reporting based on TYPE30_V
ANALAVAI a/k/a PDB.SMFINTRV data from type 30 interval records.
Jan 27, 2002
Thanks to Chuck Hopf, MBNA, USA,
Change 19.276 NTSMF object MSEXCHANGE DS has two added fields:
VMACNTSM MSEXCMTA='MSEXCHANGE*MTA'
Jan 27, 2002 ABANRRRT='AB*ANR*PER SEC'
Thanks to Terry Heim, ECOLAB, USA.
Change 19.275 Support for NDM Connect Direct for OS/390 CPU time that
VMACNDM was added to the end of PT, CT and RT statistics record.
Jan 27, 2002 MXG variable NDMCPUTM now exists in those datasets, and
will be non-missing if the extra field is found.
Thanks to John Rivera, (i)Structure, Inc, USA.
Change 19.274 Variables B1HITRAT/B2/B3/B4 in DB2STAT1 dataset were not
VMACDB2 changed when BPHITRAT in DB2STATB was, by Change 17.338.
Jan 26, 2002 Now all Buffer Hit Ratios use that same equation.
Thanks to Helmut Roese, COM Software GmbH, GERMANY.
Change 19.273 IMACEXCL now defines MACRO _CICXC22 for CICS/TS 2.2, if
IMACEXCL your CICS guru has excluded CICSTRAN fields from the SMF
VMAC110 type 110 subtype 1 record.
Jan 24, 2002
Change 19.272 The default stored length of numeric variables is changed
VMACmanymany from 4 bytes for most and 8 bytes for MGBYTES-formatted
Jan 24, 2002 memory variables, to 5 bytes for most, and 5 bytes for
Jan 28, 2002 memory, on EBCDIC, and to 6 bytes for both under ASCII.
Two macro variables were created so you can change either
default back; %LET MXGLEN=4; for most numerics, and with
%LET MXGBYLEN=8; the variables will be their original
stored lengths. MXGLEN=5 ON EBCDIC MXGLEN=6 ON ASCII.
MXG Newsletter FORTY, SAS Techical Note 2 documented the
truncation of up to 255 counts when a large-value 4-byte
binary input field is stored in 4 bytes (floating point).
It was SAS's original choice of using floating point
that made SAS shine in 1972; other programs used
integer values in fixed length fields, and truncated
the high-order digits with large values! Using FP
keeps track of the decimal point, avoiding errors!
All LENGTH DEFAULT=4 are now LENGTH DEFAULT=&MXGLEN,
and all variables with MGBYTES format lengths are now
set with &MXGBYLN instead of ' 8 ' bytes.
Both MXGLEN and MXGBYLN are set by VMXGINIT when MXG
initialized, but can be changed in your //SYSIN code
or in IMACKEEP with %LET MXGLEN=4; %LET MXBYLN=8; to
restore the pre-MXG 19.10 default values.
There is only one exposure when I change variable length:
If you use your own PROC APPEND, you must make certain
that it uses the FORCE operand, which has always been an
MXG reconnendation, so that datasets with dissimilar
attributes can be concatenated.
The only use of PROC APPEND in MXG is optional in the
VMXG2DTE member, which has always specified FORCE.
This change has been under discussion for some time, but
it was DB2 Statistics records, which contain accumulated
counters, that precipitated the change, which was not
needed until now (because DB2 and OS/390 used to crash
before the counters got this large: QB2TGET=301,219,072).
Two adjacent intervals with truncated large values with
a delta less than 255 resulted in a zero delta value.
I considered just identifing the MXG variables that are
accumulated and could get "big" enough now, but that is
both human-intensive and high-exposure-to-missing-one;
the real exposure should never have existed, and the
default length of 5 for a PIB4 has absolutely integrity.
Historical choice of 4 versus 5. In early 70s, sorts
with SYNCSORT failed when lengths other than 4 or 8
were used; SYNCSORT thought only FORTRAN *4 and *8 FP
could exist. Old memories of 3am ABENDS remain strong!
But MXG has had length 3, 5, and 6 for sometime, so I
now deem it completely safe to use!
Datetimestamp variables are still kept in 8 bytes stored
length, as are a few other variables that need the full
resolution possible (like SERVUNIT, which may be used
directly for billing, and there, pennies ARE important!).
With the increased lengths, PROC COMPARE between 19.10
and 19.09 showed many variables are slightly larger now
than before, but the magnitude of the difference is very
small; a 60 minute time value was 0.006 seconds larger.
But PROC COMPARE will not show exact values before and
after MXG 19.10.
The net impact of changing the default stored lengths on
the size of the //WORK space and the //PDB libraries, as
usual, depends! It depends on how many numeric variables
were increased from 4 to 5, and how many were reduced
from 8 to 5, in the datasets that interest you.
But, if you use compression, almost always a wise choice
now, there is NO increase in the disk space required.
Without compression, the storage increase depends on how
many records of what type you keep, but here are a two
examples of what we have measured with MVS defaults:
a. An 842 MB 6/26/30 SMF file created JOBS/STEP/PRINT
datasets; PDB increased from 350MB to 390MB, 11%.
b. A 456 MB all-record SMF file, 30 RMF intervals, full
PDB increased from 316MB to 356MB, 12% increase.
c. Chuck's big 1160 Cyl PDB increased by 30 Cyl, 3%.
There is also a small increase in Virtual Storage needed
for a big job like BUILDPDB. Chuck's Total Memory went
from 69MB to 71MB, but that 2MB increase did cause one
one site to fail with an out-of-memory error:
viloada: autoload failed for module SASXKRN2
because they were limited to 64M by their defaults:
In V6: set by the MEMSIZE=64M default in CONFIGV6.
In V8: Do not have MEMSIZE in CONFIG, use REGION=80M
You should compare the Total Memory used reported on the
SAS log, or in the IEF374I message on the job's SYSLOG,
with your REGION= parm to make sure you have VS left!
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
Thanks to M.J.H. Elbersen, Rabobank, THE NETHERLANDS.
Thanks to F. Nijdam, Rabobank, THE NETHERLANDS.
Change 19.271 This conversion utility, used to convert $HEX FORMATed
UTILCVRT character variables in PDB libraries moved from EBCDIC
Jan 23, 2002 to ASCII platforms (if you move your MXG processing from
MVS to PCs/unix, you'll copy your historical PDBs),
never did work right, but it now works as designed.
CPORT/EXPORT changes all characters variables values,
like '40'x EBCDIC to '20'x ASCII, during download,
but we need the original '40'x value so bit tests work
and so that the CPU Model is '9672'x and not '96B7'x.
The 1994 iteration used $EBCDIC, but Change 19.163 shows
that won't work. Instead, UTILCVRT now uses the $MGAS2EB
mapping ASCII-2-EBCDIC, defined in member FORMATS, and
selects variables with FORMAT=:'$HEX', no longer using
the original and 'not happening' INFORMAT=:'NOTRAN' test.
Of course, this conversion works only if the table that
SAS uses in your country matches that format; some sites
may find it necessary to edit the $MGAS2EB format into
the IMACFMTS tailoring member to match your tran table.
But any MXG datasets that you create under ASCII, reading
SMF,etc, data, are correct and do not need UTILCVRT.
Thanks to Mark Darvodelsky, Royal Sun, Australia
Change 19.270 Two variables that estimate the Average Logically Swapped
VMAC71 frames, CSFRLSAV and ESFRLSAV were found to be negative
Jan 22, 2002 CSTORE=1040MB,CSFRTOAV=920,CSFRFXAV=142==>CSFRLSAV=-4MB
which printed as -42E5. The problem is subtracting two
average values on a system with essentially no logical
swapping, the "zero" is slightly negative. I now test
the calculation, and when negative, the variable is set
to a missing value, so that a real zero value would still
be preserved as a zero value, but these negative values
will just be missing.
Thanks to Kenneth D. Jones, xwave, CANADA.
Change 19.269 The Initiator Number, INITNUMB and Name, INITNAME are now
BUILD005 added to the type 30 subtype 1 (job initiate) record when
BUIL3005 you install the Assembly code in SMF exit IEFU84 that
IEFU84 will move those values into the subtype 1 record.
VMAC30 -This change creates and keeps those two new variables in
Jan 23, 2002 dataset TYPE30_1, and updated BUILDPDB logic to add them
Jun 24, 2004 to the PDB.JOBS dataset as well. The variables will be
missing/blank if the SMF exit has not been installed.
Jun 24, 2004: The IEFU84 exit code member was added by
MXG Change 22.136; the original IEFU83 references were
wrong, as it is IEFU84, not IEFU83, that writes the SMF
30 subtype 1 SMF record. Text was changed from 83 to 84.
-The SMF exit IEFU84 source code is in member IEFU84,
along with notes, so your SYSPROG can see what it does.
The exit moves the initiator number (in binary) into
the first four bytes of PROGRAM (SMF30PGM) name field,
and the initiator name (character) into the second
four bytes of PROGRAM name. SMF30PGM is not populated
at job initiate since PROGRAM doesn't exist until
after the step initiates.
-However, it is your System Programmer's responsibility to
install and test any SMF exit, and thus your company, and
not Merrill Consultants, must take all risk in choosing
to adapt this enhancement SMF exit into your systems:
recognize that the risk with an SMF exit-in-error could
be as bad as a system outage.
I would not provide this example if I did not think it is
safe, and almost every MVS site uses an SMF exit, but you
should read up on SMF exits in the SMF manual before you
convince your friendly SysProg to install the exit.
Remind them that the exit will let you to help them track
which job us which initiator, to help in chasing ABENDS
with overlaid initiators, or in measuring which init is
used how often, etc.
This exit is provided because IBM does not currently
provide this information in their SMF type 30 record. I
have provided them with the tested exit code in the hope
that they will eventually add the fields so that you
don't have to install an SMF exit to get them.
Several MXG-L postings on the subject of initiator number
precipitated this change, but the guys who suggested and
coded the solution, respectively, get the CodeShark cite!
Thanks to Mike Shaw, MVS QuickRef/Chicago Soft, USA.
Change 19.268 Under very strange circumstances: when %LET MACKEEP= was
VMXGDEL used to redefine an old style macro that contained an
VMXGOPTR %VMXGDEL(DDDDDD=dddddd) invocation, the internal call to
VMXGSUM %VMXGOPTR by VMXGDEL generated this error message:
Jan 23, 2002 ERROR 14-12: Invalid option OBS=;; for SAS option OBS.
Jan 26, 2002 VMXGOPTR was needed by VMXGDEL solely because PROC SQL
doesn't execute if OBS=0, but PROC SQL/VTABLE had to run
in VMXGDEL (even when OBS=0 was specified) to populate
macro variables, and OBS=0 is commonly set for testing.
We had used VMXGOPTR to store the old OBS=value, set it
to OBS=MAX (so PROC SQL would execute), and then restore
the original OBS= value, all inside VMXGDEL. But when
we could not diagnose this particular macro error, Rick
Langston at SAS showed us the GETOPTION() function, which
allowed us to remove the PROC SQL/VTABLE in both VMXGDEL
and in VMXGOPTR, with a cleaner, safer approach.
The GETOPTION() function can be used in two ways:
- DATA step solution:
%GLOBAL OBSVALUE;
DATA;CALL SYMPUT("OBSVALUE",GETOPTION("OBS"));RUN;
- pure macro solution:
%MACRO GETOBS;
%GLOBAL OBSVALUE;
%LET OBSVALUE=%SYSFUNC(GETOPTIONS(OBS));
%MEND GETOBS;
%GETOBS;
We chose the pure macro solution in VMXGDEL and VMXGOPTR.
We also changed the design of VMXGOPTR so that it resets
the option value to what it was in the prior VMXGOPTR
execution; the original design kept the value of the
option only from the very first invocation of VMXGOPTR,
and did not recognize if you changed the option between
paired invocations of VMXGOPTR. See comments in VMXGOPTR.
-In QA tests of these VMXGOPTR and VMXGDEL changes, Bruce
set OPTION OBS=10, and found two places inside VMXGSUM
where we had failed to use %VMXGOPTR to protect for user
change of OBS=; VMXGSUM was corrected to now protect.
With OBS=11, this error would not have been corrected!
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Rick Langston, SAS Institute, USA.
Thanks to Rosalind Howe, IBM Global Services, USA.
======Changes thru 19.267 were in MXG 19.09 dated Jan 21, 2002======
Change 19.267 Support for IBM SMF 119 (TCP/IP) record from z/OS V1R2.0
EXT11901 Communications Server, which replaces the SMF 118 record
EXT11902 from the current IBM TCP/IP product. The data content is
EXT11903 significantly enhanced beyond what is in the current 111,
EXT11905 with many new subtypes and these datasets created:
EXT11906
EXT119A7 SUBTYPE DATASET description
EXT119B7 1 TYP11901 TCP CONNECTION INITIATION
EXT11908 2 TYP11902 TCP CONNECTION TERMINATON
EXT11910 3 TYP11903 FTP CLIENT TRANSFER COMPLETION
EXT11920 5 TYP11905 TCP/IP STATISTICS
EXT11921 6 TYP11906 INTERFACE STATISTICS
EXT11922 7 TYP119A7 SERVER PORT STATISTICS - TCP
EXT11923 7 TYP119B7 SERVER PORT STATISTICS - UDP
EXT11970 8 TYP11908 TCP/IP STACK START/STOP
EXT11972 10 TYP11910 UDP SOCKET CLOSE
FORMATS 20 TYP11920 TN3270 SERVER SNA SESSION INIT
IMAC119 21 TYP11921 TN3270 SERVER SNA SESSION TERM
TYPE119 22 TYP11922 TSO TELNET CLIENT CONNECTION INIT
TYPS119 23 TYP11923 TSO TELNET CLIENT CONNECTION TERM
VMAC119 70 TYP11970 FTP SERVER TRANSFER COMPLETION
VMXGINIT 72 TYP11972 FTP SERVER LOGIN FAILURE
Jan 18, 2002
Change 19.266 Variable RVSTBIN, Bin Number, can be characters, but MXG
VMACEDGR did not know that, and character data caused a non-fatal
Jan 16, 2002 INVALID DATA FOR RVSTBIN message. New variable RVSTBINC
is now Character; RVSTBIN is still numeric, but missing
value now if RVSTBINC has non-numeric characters.
Thanks to Joe Ellis, American Century, USA.
Change 19.265 Dataset STCHSC has zero observations, because STK changed
VMACSTC the length of the record; long ago MXG had to protect for
Jan 16, 2002 records shorter than the then-written 140 bytes, but now
their subtype=7 record is only 120 bytes. Logic revised.
Thanks to Fraser Wong, CitiCorp, USA.
Change 19.264 Cisco Memory Pool variables NRPxxxxx in NPMINNRP were all
FORMATS missing; MXG tested NRPDTYP=1 for Cisco, but the records
VMAC28 contained NRPDTYP=0, so nothing was input. Now, the test
Jan 14, 2002 is for NRPRTYP=2 (Record Type, not Data Type) for the
Jan 16, 2002 Memory Pool data. IBM lists two other NRPRTYP values of
NRPRTYP=1 - CPU and Memory NRPRTYP=3 - Interface
but does not document the contents of the NRP segment for
those (as yet) unsupported values. Variables NRPRTYP and
NRPDTYP are now kept in NPMINNRP so you can see if any of
the new Record Types are in your SMF data; contact MXG
support when you find any, so we can decode them!
New format MG028PT decodes Cisco pool type variables
NRPCPTYP and LNCDCPTY:
1='1 PROCESSOR MEMORY 4='1:FAST MEMORY'
2='1:I/O MEMORY' 5='1:MULTIBUS MEMORY'
3='1:PCI MEMORY'
Jan 24: IBM APAR OW53087 documents that the DTYP=0 in the
NRP and NRT segments is now a reserved field, but that
APAR does not document the RTYP=1 and RTYP=3 data.
Feb 15: IBM will correct OW53087. The xxxRTYP field has
only one value in each record: NRPRTYP==2 NRT=1 NIT=3,
so there are no undocumented segments, and the misleading
documentation will be revised by IBM. See Change 20.003.
Thanks to Howard Swift, HSBC Bank, UK.
Thanks to John Wilmot, HSBC Bank, UK.
Change 19.263 The _SDB2ACC sort macro for DB2ACCT and _BDB2ACC BY list
VMACDB2 were defined as blank, to prevent an accidental sort of
Jan 14, 2002 that potentially large dataset, but since the _SDB2ACC
reference in _SDB2 is commented out, both macros are now
defined, in case you do need to sort and remove dupes
from your DB2ACCT dataset.
Thanks to Rosalind E. Howe, IBM Global Services - South, USA.
Change 19.262 A sample AS/400 report from TYPEQAPM Performance
ANALQAPM Monitor data.
Jan 11, 2002
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND
Change 19.261 Support for IBM AIX Performance Toolbox and Performance
ADOCAIX AIDE for POWER, PTX Version 2, refs: SG24-2011-00.
EXAIXPTX This internal design is extremely robust, and is similar
IMACAIX to the new WebLog support; the list of fields in your
TYPEAIX data is read and used to input the record, so you can
TYPSAIX have different sets of fields defined for different AIX
VMACAIX servers, and the one MXG program will work on all their
VMXGINIT data, transparently.
Jan 15, 2002 This implementation supports the default set of 55 fields
Jan 17, 2002 and the heavy work is done; expansion to keep any of the
other 2000 possible fields is easy, when anyone actually
has actually created those additional fields!
Thanks to Glenn Bowman, Wakefern, USA.
Thanks to Al Sias, Wakefern, USA.
Change 19.260 New optional design will change timezones of all datetime
TIMEBILD variables read from SMF records, based on a table lookup
TIMETABL of SYSTEM/SYSPLEX/datetime-range in which you set the
VMACmanymany offset to be added to all datetime variables.
VMXGTIME This is needed when you have SYSTEMs with different time
Jan 11, 2002 zones, so you can have a common timezone for analysis of
Jan 15, 2002 shared dasd, time of day, etc.
Jan 26, 2002
The table is defined in member TIMETABL (copied into your
USERID.SOURCLIB tailoring library) with a syntax of:
SYSA 01/01/2002 00:00:00 01/31/2999 23:59:59 -21600
to change SYSA datetimes back 6 hours, for a datetime
range from now until infinity.
Even if you have defined your table in member TIMETABL,
nothing happens until you enable time change with this
statement in your //SYSIN stream:
%TIMEBILD;
Invoking %TIMEBILD enables the time changing logic, and
reads the TIMETABL member with the TIMEBILD program that
creates the (temporary) format $MGTMPTM that is the look
up table that is used by %VMXGTIME.
The default table is the TIMETABL member in your SOURCLIB
concatenation, but you can use %TIMEBLD(TIMETABL=XYZ);
to use a different time change table; see its comments.
While the table supports SYSPLEX for selection, SYSPLEX
only exists in some records, so it is really there only
for future selection. Only in the case where you know
that all records you want to change (RMF is the only one
at present) contain SYSPLEX, then and only then could you
have a value for SYSPLEX in the TIMETABL, and you could
not then use that same TIMETABL to select TYPE1415 data
that does not contain a SYSPLEX variable.
To make the actual time change itself, this statement
%VMXGTIME(var1 var2 var3,system,sysplex);
was inserted in the correct place in every VMACxxxx
member that creates datetime variables from SMF records.
All MXG members that process IBM or User SMF records have
been updated, as were most other products that contain a
SYSTEM variable. Some non-SMF products that do not have
a "SYSTEM" field were set aside until a need arises.
VMXGTIME statements were inserted 874 places in 380 MXG
members, listing 1,300 variables that can be changed in
'one felt swoop': update TIMETABL, invoke %TIMEBILD.
See VMXGTIME revisions, GMT support, and corrected CPU
and memory cost measurements in Change 19.286/MXG 19.11.
Change 19.259 The MXGTMNT Tape Mount and Tape Allocation Monitor SMF
ASMTAPES record had the wrong DDNAME if the tape UCB was a 4-digit
VMACTMNT address (the incorrect DDNAME was the last DDNAME in the
JAN 20, 2002 TIOT). The previous logic compared UCB address to get the
the correct DDNAME; this revision compares device numbers
for the UCBs, so this logic will work regardless of
whether the tape UCB address is above or below the 16MB
line, or 3 or 4-digit device address. The revision also
gets the correct DSAB allocation flags for tape mounts.
This revision is "ML-20" of the monitor program. Your
SysProg must re-assemble ASMTAPES and link edit the new
MXGTMNT program that is executed by your MXGTMNT started
task that writes the SMF records, to get the corrected
DDNAME into those SMF records, but you don't need to do
anything to your daily MXG SMF processing jobs; they will
get the correct DDNAME without any change. Only if you
want the new DSABFLAG variable (which is not currently
used by MXG) in your TYPETMNT dataset, will you need to
use the revised VMACTMNT member.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Jim Sherman, FDC, USA.
Change 19.258 Variable XCPUFLAG is now formatted with new $MGXCMCP
FORMATS format to decode the CPU type of the ftp transfer, and
VMACXCOM the list of old and new values for XCPUFLAG in ADOCXCOM
Jan 9, 2002 was updated with the new values.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 19.257 Two examples that select related pairs of SMF records.
ANAL16
ANAL30 Program ANAL16 reads SMF to create TYPE16 (sort) obs for
Jan 8, 2002 selected sorts (in this example, those with concatenated
Jan 15, 2002 SORTIN datasets, because only the first DSNAME is in the
TYPE16 record), and uses those selected TYPE16 obs to
create a table lookup that is then used to re-read SMF
and select only the matching SMF TYPE1415 records; the
site could thus find the dsnames of all SORTIN datasets.
Program ANAL30 reads SMF to create only TYPE30_4 obs for
steps you selected (this example, programs IEBCOPY and
IEBGENER), creates the lookup table, which is then used
to select all of the non-VSAM TYPE1415 and VSAM TYPE64
datasets that were opened by that step.
These examples are easily extended to select other
pairs of data where one event defines a timerange, and
the matching events must occur within that timerange.
I've been meaning to write this example technique for
some time; this specific request precipiated the program!
Thanks to David Goldstein, EDS, AUSTRALIA.
Change 19.256 Variable UMRECRD in dataset DCOLMIGS is now formatted by
FORMATS the new $MGDCORF format to decode the Record Format when
VMACDCOL UMRECRD is printed or displayed. And variable DCERECRD
Jan 4, 2002 in dataset DCOLDSET is now kept, and formatted with the
new $MGDCORF format, also displays the Record Format (and
eliminates the need to combine the same information from
the variables DCDRECFA/B/C/F/J/S/U/V to get it!
Thanks to Wanda Prather, The John Hopkins Applied Physics Lab, USA
Change 19.255 Comments only. If you add NPM TYPE28 processing to your
DIFF28 BUILDPDB, you must either add %INCLUDE SOURCLIB(DIFF28);
Jan 2, 2002 in member EXPDBOUT (to deaccumulate the NPMINPMT data) or
if you want all NPM datasets written to your PDB library,
then you would instead add _S28 in member EXPDBOUT, as
that "product" sort macro sorts (and deaccumulates where
necessary) all datasets created by TYPE28 code.
The DIFF28 member contains only _S028IN7, the "dataset"
sort macro for NPMINPMT, which is included in _S28 macro.
DIFFxxx members exist only for products with accumulated
data fields, and MXG always invokes the DIFFxxx member in
both the TYPExxx and TYPSxxx members, to hopefully assure
that you always have legitimate (i.e., deaccumulated)
values. But now, the DIFF logic is contained in the
"dataset" sort macro, so the DIFFxxx members contain only
the specific datasets that must be deaccumulated.
Thanks to Bruce Hewson, CitiCorp, N.A., SINGAPORE.
Change 19.254 Support for the configuration record (NTCONFIG dataset)
VMACNTSM adds variables DCSDURATM (DCS Interval) and DSCVRYRT
Jan 2, 2002 (Discovery Record Types) - existing fields not decoded,
and variable SUMRYVER (Summary Version Number), to be
added to the record when this data file was created by
NTSMF's summarization program, which is also the flag
that this input file contains summarized data.
Change 19.253 Variable LABEL in TYPETMNT was wrong; the INPUT location
VMACTMNT of TMNTLAB should have been the first byte, with the
Dec 30, 2001 second byte unused.
Thanks to Mike Jacques, Branch Banking & Trust, USA.
Change 19.252 "New" DFSMS/rmm variables include Creating Program Name,
VMACEDGR Total Block Count across all volumes, and "Last Used"
Dec 30, 2001 Program/Job/Step/DD/DEVNR are now INPUT and kept in
TYPEEDGR. They were added by IBM by OW40710 in 1999.
Thanks to Joe Lodyga, Whirlpool Corporation, USA.
Change 19.251 Use of long-variable-names was not fully supported in
VMXGSUM VMXGSUM; names could be truncated to eight bytes. Since
VMXGINIT MXG does not use long variable names, this only impacted
Dec 27, 2001 use of VMXGSUM with long variable names in SAS V8.
Dec 30, 2001 To accomplish this change, TEMPnn libnames will be built
Jan 4, 2002 with ENGINE=V8SEQ under V8, and ENGINE=V6SEQ under V6,
Jan 20, 2002 and TEMPnENG is set blank if TEMPnn is not used.
Corrected logic if KEEPALL=NO was used.
-In member VMXGINIT, new global macro variable MXGLEN
defaults to 4, and it is used by VMXGSUM (instead of the
hardcoded 4) to set the length of variables on the output
side of VMXGSUM, for those rare cases where you need to
increase kept length, by using %LET MXGLEN=8; before
your %VMXGSUM invocation. NO LONGER TRUE.
PARAGRAPH WAS CHANGED BY CHANGE 19.272 in JANUARY.
-PROC SQL's scope was limited to look only at LIBNAMEs;
under very unlikely circumstances, it could read all SAS
datasets on a multi-volume tape data library; nothing
failed, but the job took longer than expected.
Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.
Change 19.250 The Logically Swapped ESTORE in variable ESFRLSAV was
VMAC71 wrong; ESFRHSAV was being added instead of subtracted.
Dec 27, 2001 ESFRLSAV=ESTORE-(ESFRTOAV+ESFRHSAV); is now used.
Thanks to Peter Webber, CIS, US.
Change 19.249 Major revision in support for Web Logs.
EXWWWCOO The original TYPEWWW was completely restructured and now
EXWWWIIS creates multiple datasets, and more are likely over time.
EXWWWLOG -Multiple web log data formats are automatically detected,
EXWWWREF and multiple "Log Event" datasets will be created where
EXWWWURQ the contents of the logs are sufficiently different. An
IMACWWW observation in the "Log Event" dataset is created for
VMACWWW each web log record that is not filtered. At present:
VMXGINIT
TYPEWWW Dataset Description of Web Log
TYPSWWW WWWLOG Netscape/I-planet,Common Log Format,Websphere
Jan 7, 2002 WWWIIS Microsoft IIS (old and new versions)
-"Multiple segment" datasets are created for content items
when there can be more than one item in a log event. The
individual segments can be mapped back to their parent
log event observation using the ZTIME/WEBSEQNR variables.
At present, these multiple segments are decoded:
Dataset Description of contents
WWWCOOKE Cookies, COOKNAME and COOKVALUE pairs
WWWREFER Referer text, may be revised.
WWWURQRY URI Query, URIQNAME, URIQVALU pairs.
-By default, MXG Sorts invoke the NODUP option to remove
all duplicates, but duplicate log events occur (refresh
same page in same second), and to allow you to override
and keep duplicates, macro variable &SASNODUP is defined
in VMXGINIT (Default is NODUP) and it is used in VMACWWW
so you can supress duplicate removal in web logs by
using %LET SASNODUP=; in your //SYSIN
-There is a lot of logic in VMACWWW that will eventually
be documented in ADOCWWW, and there will be new exits to
allow filtering of what records are kept during INPUT, as
web log data can be voluminous. Current notes:
Variable HOST is LOWERCASED, so that all of the casing
spelling variants (WWW.MXG.COM, www.mxg.com) will be
combined.
Variable VISITOR is created from cookies if either the
SITESERVER=ID= or ASPSESSIONID cookie name (COOKNAME)
is found, to track the same user thru your servers. If
neither cookie is found, a VISITOR variable is created
as TRIM(HOST)!!TRIM(CLIENTIP)!!TRIM(USERNAME). Note the
USERNAME exists only for URLs in the authenticated
realm
For web logs with self-contained documentation of their
contents (currently, the IIS "#FIELDS" record and the
Netscape "format=" record), this new architecture reads
those header records to determine what data fields are in
your data records, and in what order, to automatically
process logs with excluded, skipped, optional fields,
and with those fields in any order, transparently!
These powerful algorithms will be easy to use to support
other new data that contain self-documenting headers.
While this support is fully usable now, I anticipate the
expansion of analysis and reporting of this clickstream
data. Unfortunately, at present, there is no way to
correlate the computer resources that are associated with
these web activities. But this is ongoing research, and
additional enhancements can be expected.
Thanks to Tom Gray, SPRINT, USA.
Change 19.248 Change 19.187 was incomplete; an ID statement referenced
ASUMNTIN non existent variables and was removed.
Dec 21, 2001
Thanks to Jim Quigley, ConEd, USA.
======Changes thru 19.247 were in MXG 19.08 dated Dec 20, 2001======
Change 19.247 Some ANALDB2R reports failed if all DB2 datasets had zero
ANALDB2R observations. The original design of %VGETOBS macro did
VGETOBS did not differentiate a non-existent dataset from one
VMXGINIT with zero observations. This enhancement to %VGETOBS
Dec 19, 2001 creates new GLOBALed macro variable VGETDSN that will be
blank if the dataset does not exist in the DDNAME, or
will contain the data set name if it exists. If the
dataset is found, an MXGNOTE with name and number of
observations is printed on the log; if not, an MXGWARN is
printed that the requested dataset was not found.
The invocations of %VGETOBS in ANALDB2R were then revised
to exploit the enhancement.
Change 19.246 Sophisticated option for VMXGSUM when two output summary
ADOCSUM datasets at different summary levels are to be created.
VMXGSUM MXG's normal HouseKeeping deletes the MXGSUMx temporary
Dec 18, 2001 datasets, to make disk space available, but with the new
HOUSKEEP=NO specified in your first %VMXGSUM invocation,
no housekeeping is done, so a second %VMXGSUM can then
specify NOSORT=YES to bypass the PROC SORT, and since the
first step (when needed) will be a VIEW, there is no I/O
associated with the output side of the first data step,
which is then read directly by the PROC MEANS.
You have to be very sure of what you are doing; if the
sort order is not correct, the second %VMXGSUM invocation
will fail. Examples of using these options are given in
member ADOCSUM.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.245 Support for APAR OW49808 to RMF Type 70 Subtype 2 CRYPTO
EXTY70X2 record (new in z/OS 1.2, Change 19.176) enhances the data
EXTY70Y2 measures and there are now three datasets created from
IMAC7072 the 70-2 record:
VMAC7072 DDDDDD Dataset Description
VMXGINIT TY7002 TYPE7002 RMF PCI CRYPTO COPROCESSOR PCICC
Dec 18, 2001 TY70X2 TYPE70X2 RMF PCI CRYPTO ACCELERATOR PCICA
TY70Y2 TYPE70Y2 RMF CRYPTO COPROCESSOR FACILITY CCF
These data will become important as they will be used by
the Secure Sockets Layer associated with Websphere and
similar secured systems.
These data have not yet been validated with test records.
Change 19.244 Support for IDMS Log Statistics Records decodes LGRTYPE
EXIDML01- 'F6'x and '76'x record's into eleven datasets, one for
EXIDML11 each STLTYPE (01x-11x), but only the STLTYPE=02 TASK
FORMATS records are fully decoded (in dataset IDMLOG02). Records
TYPEIDML with STLTYPE=01 (SYSTEM) have three non-zero fields, but
VMACIDML do not match their DSECT descriptions, and all other STL
VMXGINIT TYPEs in the test file have no data fields.
Thanks to Hugh O'Neill, Dow Jones, USA.
Change 19.244 This Windows Disk Space Used utility read the output of
UDSKCONT DIR commands to report disk space by direcory and file.
Dec 13, 2001 It now supports Windows NT/2000/XP, which has a different
output format for the DIR command, but you have to tell
it which format you want to read. I use this to find out
why I've run out of space on a PC disk.
Change 19.243 IBM declared field QBACSWU to be 'Reserved' in DB2 6.1,
VMACDB2 but the field appears to continue to contain QBACSWU, so
Dec 13, 2001 the QBACRSVD field is now input into QBACSWU variable,
but please validate and use it with caution.
Thanks to Charles Harbour, John Deere, USA.
Change 19.242 For users of TYPEIMS7 and VMACIMS, variables IMSGTEXT and
VMACIMS OMSGTEXT in IMS01/IMS03 datasets were blank with IMS 6.1
Dec 12, 2001 and wrong with 5.1 that are now correctly input in this
almost-archaic member. Some unnecessary/confusing tests
IF _IMSVERS were removed for readability. Several new
variables were INPUT but not kept; MSGRACUS (RACF User
ID, also "LogonID"), MSGSAFNM, MSGUSIDI, and MSGWLMSC are
now kept in the 01/03 datasets.
The recommended MXG IMS Log processing is in the members
JCLIMSLn, ASMIMSLn, and TYPEIMSA/TYPEIMSB, and they are
not impacted by this change. This site had reports that
were based on the raw IMSnn datasets created by VMACIMS,
so it was updated to preserve their reports.
Thanks to James Seitz, Oklahoma Department of Human Services, USA.
Thanks to Ken Sharpe, Oklahoma Department of Human Services, USA.
Change 19.241 MXG enhancement for Batch Pipes adds these variables
VMAC91 DDNAME JESNR JOB READTIME STEPNAME STEPNR to the
Dec 11, 2001 TYPE91nn datasets for subtypes 11,12,13, and 15, and
increases the number of system names/flags variables
SMF91XYn and SMF91XFn from eight to sixteen to support
sixteen systems in a sysplex.
Thanks to Michael Oujesky, MBNA, USA.
Change 19.240 MXG 19.04-19.07 only. Variables PCHANBY and PNCHANBY can
VMAC73 be always zero in error. Change 19.176 mis-located the
Dec 10, 2001 initialization of those variables for SMF73CMG=0 records.
Thanks to John Gebert, Office Depot, USA.
Change 19.239 Several Coupling Facility variables in TYPE74CF/TYPE74ST:
VMAC74 R744SASQ/R744SSSQ/R744SQSQ/R744SDSQ/R744FCSQ/R744FSQU
Dec 6, 2001 were all sums of squares that are now divided by 1000000.
Variables R744FTIM/R744FCTM were incorrectly divided by
4096. Our test data had all zeros, so these incorrect
conversions were not previously caught.
Thanks to Bill Cool, EDS Federal Government, USA.
Change 19.238 Variable DEVNR is now created in dataset TYPE42VL as a
VMAC42 numeric field with format HEX4; variable SMF42DEV in that
Dec 6, 2001 dataset is a 4-byte character device number in hex, but
Dec 18, 2001 DEVNR is numeric in all other datasets, and is needed to
merge TYPE42VL with other data.
Dec 18: SMF42DEV input changed to $CHAR and logic to
INPUT the DEVNR variable was revised to work.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA
Change 19.237 Variable LOCLINFO in PDB.STEPS was incorrect. Its value
BUILD005 in a step record was being overlaid with LOCLINFO from
BUIL3005 the other job-level records, so if you put different data
Dec 4, 2001 in the STEP records, it was lost. Now, the step value
is preserved for each step.
Thanks to Diane Eppestine, Southwestern Bell, USA
Change 19.236 Values for SMF73CPD (Channel Path Description), decoded
FORMATS by MXG Format MG073CD, were updated for new '14'x,'15'x,
Nov 26, 2001 values for HSSI and Ethernet Open System Adapter Channel.
Change 19.235 Observations were created in new dataset MQMCFMGR only by
VMAC115 accident; the test IF SM1152O2 GT 0 THEN DO; should have
Nov 26, 2001 been coded as IF SM1152OC GT 0 THEN DO;
Thanks to Martin Lee, Safeway Stores PLC, ENGLAND.
Change 19.234 MXG Software (all versions) supports the euro symbol, as
none there are no MXG variables that contain financial values
Nov 23, 2001 in euros, dollars, or any other units of currency.
Of course, you can always create financial variables
in your reporting and billing programs, and there, you
can use the SAS FORMAT EUROw.d, which complies with
the European Monitary Union rules and displays an "E"
as the euro symbol, without any special characters.
But be careful with EUROw.d (and DOLLARw.d) formats;
you must not underspecify the field width w, or SAS
will truncate from the left and your euro/dollar sign
will not be printed (as shown in SAS documentation!):
With a value of x= E1254.71 euros
using format will print as
EURO6.0 E1,255
EURO5.0 1,255
EURO5.1 1255
EURO6.1 1254.7
Thanks to K. Strange Bruun, IBM Denmark A/S, DENMARK.
Change 19.233 For NT Trending, default DDNAMES could not be changed, as
BLDNTPDB the user tailoring could be overwritten by TRND defaults.
TRNDNTIN Now, user tailoring of DDnames works as expected.
TRNDNTLD
Nov 23, 2001
Thanks to Greg Jackson, National Life Insurance of Vermont, USA.
Change 19.232 The new IHDRTMO2 exit that was supposedly added by Change
IHDRTMO2 Change 19.154 was created but not included in VMACTMO2.
VMACTIMS This change adds the %INCLUDE of IHDRTMO2 in VMACTMO2; it
VMACTMO2 is called after the Transaction Header or Interval Header
VMACTMV2 has been INPUT. Comments in IHDRTMO2 were updated and
Nov 20, 2001 now include an examples of tailoring, either by EDIT of
Nov 23, 2001 the IHDRTMO2 member, or by using the %LET MACTMOH= in
your //SYSIN input.
-Similarly, the INCLUDE of IHDRTIMS and IHDRTMV2 have been
added to their appropriate VMAC member.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 19.231 Sample MQ Series reports were updated. Originally, the
ANAL115 ANAL115 member contained an MXG "program" that was read
Nov 20, 2001 with a %INCLUDE, and then executed with the syntax:
%INCLUDE SOURCLIB(ANAL115);
Now, the ANAL115 member defines %MACRO ANAL115;, so your
%INCLUDE statement is now replaced with:
%ANAL115;
to execute with all defaults, or with
%ANAL115(PDB=SMF,REPORTS=ALL);
if you want to change the input to use SMF data, select
reports, etc. See the complete list of arguments in the
comments in the ANAL115 member. The member was changed
into a %MACRO so that we could provide you with arguments
to tailor the execution and provide report selection:
- The %INCLUDE(ANAL115); statement now would not fail,
but it would only read the member and compile the
%ANAL115 macro, but it would not "do" anything, since
it does not invoke the actual %MACRO name.
- You don't need the %INCLUDE(ANAL115); statement now,
because when SAS sees that %ANAL115; statement in your
//SYSIN (because MXG set options SASAUTOS=SOURCLIB and
MAUTOSOURCE in its CONFIGV8/AUTOEXEC), SAS will read,
compile, and execute the %MACRO defined in ANAL115.
There are extensive IBM notes about measuring/monitoring
MQ series in the comments of this report member.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 19.230 -Using %LET MACKEEP= to tailor the DCOLLECT part of the
DAILYDSN DAILYDSN program (used in the JCLDAYDS example to read
VMXGINIT DCOLLECT and TMS data for "Daily Dataset Accounting")
Nov 19, 2001 did not work. The second execution of %VMXGINIT inside
DAILYDSN was re-executing the %LET MACKEEP=; statement to
set the MACKEEP macro variable back to blank. Further
examination of the %GLOBAL statement documentation showed
A macro variable created with a %GLOBAL statement has
null value until you assign it some other value. If a
global macro variable already exists and you specify
that variable in a %GLOBAL statement, the existing
value remains unchanged.
so there is no need to initialize macro variables to null
value if the variables is in a %GLOBAL statement, and the
removal of those %LET xxxxxx=.; (null value) statements
permits multiple execution of %VMXGINIT.
-However, the purpose of the user's MACKEEP= tailoring was
to make DAILYDSN only create the four DCOLLECT datasets
that are used in DAILYDSN, so that member now has an
example of a %LET MACKEEP= statement that only keeps the
four DCOLxxxx dataset that are used by DAILYDSN:
DCOLDSET DCOLVOLS DCOLMIGS DCOLBKUP
Thanks to Joseph Stoll, University of Wisconsin Hospital, USA.
Change 19.229 Support for RSD Folders ASTRE Auditing User SMF Record
EXRSDAUD creates new RSDAUDIT dataset with member TYPERSDA, and
FORMATS new formats MGRSDAU and $MGRSDFO. One set of fields,
IMACRSDA Folder Type is not documented, but will eventually be
TYPERSDA decoded with another format.
TYPSRSDA Note that the other RSD Folder SMF records are supported
VMACRSDA in TYPERSDF.
VMXGINIT The tested version is RSD/Folders V 4.1.
Nov 17, 2001
Thanks to Christa Neven, KBC Bank, BELGIUM.
Change 19.228 MXG 19.01-19.07 only, execution under ITSV, received this
VMACSYNC ERROR: VARIABLE UNIT1 HAS BEEN DEFINED AS BOTH CHARACTER
Nov 16, 2001 AND NUMERIC, because MXG 19.01 unintentionally changed
those variables from CHAR to NUM, but ITSV's dictionary
(righteously!) expected them to still be character.
This change creates variables UNIT0-UNIT99 as CHAR $4
variables, as they were in MXG 18.18, but it also creates
new numeric variables DEVNR0-DEVNR99, that should be used
instead of UNITn variables, so that your devices are in
numeric order: 181x..18Ax..A18x..B41x... If you use the
character unit address, you get A81x..B41x..18Ax..181x..
Variables DEVNR0-DEVNR99 are FORMATed HEX4, so they
print the same value as the UNITn variables.
Thanks to Bob Funk, Progressive Insurance, USA
Change 19.227 Fields added to HSM User SMF (usually 240/241) last year,
VMACHSM compatibly, in what were reserved bytes. These new MXG
Nov 15, 2001 variables now exist in HSMFSRST dataset:
FSRFLG3 ='FSRFLG3*REQUEST*FLAGS'
FSRTIMS2='TIME WHEN*PREPROCESSING*COMPLETED'
FSRTIMM1='TIME WHEN*DATA MOVEMENT*STARTED'
FSRTIMM2='TIME WHEN*DATA MOVEMENT*COMPLETED'
FSRTIME1='TIME WHEN*HOST PROCESSNG*STARTED'
FSRHOST ='HOST*IDENTIFIER'
Those new timestamps for phases of HSM may be useful.
I chose to keep only the one-byte flag variable FSRFLG3,
to save DASD space, but these tests can be used for the
bit-level-field-names, some of which may be important:
FSRFLG3='1.......'B FSRFVINI RECOVERY REQUEST
FSRFLG3='.1......'B FSRVXPL1 DS EXPIRED FROM ML1
FSRFLG3='..1.....'B FSRFXPL2 DS EXPIRED FROM ML2
FSRFLG3='...1....'B FSRFEXBV BACKUP VER BEING EXPIRED
FSRFLG3='....1...'B FSRFBKTP BACKUP VER DELTD IS TAPE
FSRFLG3='.....1..'B FSRFEXDT DELETED BY EXPDT/MGTCL
FSRFLG3='......1.'B FSRRECON MIGRATE DUE TO RECONNECT
Thanks to Judith Bruner, Wal-Mart, USA.
Change 19.226 There was a missing end-of-comment */ in this member.
ASUMTCPT
Nov 15, 2001
Thanks to Dan Riggs, Wachovia, USA.
Change 19.225 Support for Landmark's The Monitor for TCP/IP v1.1 has
EXTMTCIA been tested with actual data for all subtypes! These new
EXTMTCIC datasets are created from the dumped TMON records:
EXTMTCIE dddddd dataset description
EXTMTCIF TMTCIA TMTCIA TMON TCP/IP IA API TERM
EXTMTCIG TMTCIC TMTCIC TMON TCP/IP IC TCP GROUP
EXTMTCIL TMTCIE TMTCIE TMON TCP/IP IE EXCEPTION
EXTMTCIM TMTCIF TMTCIF TMON TCP/IP IF INTERFACE/ICMP
EXTMTCMO TMTCIG TMTCIG TMON TCP/IP IG PING RESULTS
EXTMTCIO TMTCIL TMTCIL TMON TCP/IP IL TELNET EVENT
EXTMTCOD TMTCIM TMTCIM TMON TCP/IP IM CSM INTERVAL
EXTMTCIP TMTCMO TMTCIMO TMON TCP/IP IM CSM OWNER
EXTMTCPA TMTCIO TMTCIO TMON TCP/IP IO CISCO
EXTMTCPR TMTCOD TMTCIOD TMON TCP/IP IO CISCO DEVICE
EXTMTCPT TMTCIP TMTCIP TMON TCP/IP IP IP GROUP
EXTMTCIR TMTCPA TMTCIPA TMON TCP/IP IPA IP ADDRESS
EXTMTCIS TMTCPR TMTCIPR TMON TCP/IP IPR IP ROUTING
EXTMTCIU TMTCPT TMTCIPT TMON TCP/IP IPT IP TRANSLATE
EXTMTCIZ TMTCIR TMTCIR TMON TCP/IP IR TRACE ROUTE
IHDRTMTC TMTCIS TMTCIS TMON TCP/IP IS SYSTEM GROUP
IMACTMTC TMTCIU TMTCIU TMON TCP/IP IU UDP GROUP
TYPETMTC TMTCIZ TMTCIZ TMON TCP/IP IZ FTP EVENT
TYPSTMTC Invalid packed dates in IASDAT, IZSDAT, and ILSDAT have
VMACTMTC '101271F0'x instead of '0101271F', causing missing values
VMXGINIT values, and IZFTPTY is sometimes shifted right, but there
Nov 16, 2001 is lots of new data here, especially from SNMP v1/v2 MIB.
Thanks to Julie Haines, Direct Line, ENGLAND.
Thanks to Pete Gain, SAS Software PTY, ENGLAND.
Change 19.224 Support for CICS/TS 2.2 Statistics Record was enhanced
EXCICDSP with new datasets CICDSPOO, CICS Dispatcher TCB Pools to
IMACCICS record the number of TCBs attached, allocated, etc., for
VMAC110 the Open, JVM and HP TCB pools. Now understanding that
VMXGCICI CICS TCB number is no longer valid to identify what is in
VMXGINIT which TCB, the text of Change 19.204 and ADOC110 were
Nov 13, 2001 revised to show that the TCB "Name", rather than number
Nov 19, 2001 determines what is stored in the dsNxxxxx set of CICS TCB
variables: trust the variable's Label, not its number!
-The VMXGCICI member was updated to bring in the twelfth
and thirteenth TCBS
-New (and undocumented) "D2" TCB is now recognized.
The STID=114 EJR and STID=66 STG segments have new fields
added to their existing datasets.
Change 19.223 Invoking _N108 to null out all TYPE108x datasets failed
VMAC108 because the MACRO _N108 statements were wrong - each was
Nov 12, 2001 of the subsequent lines were missing the word "MACRO".
Thanks to Martin Lee, Safeway Stores PLC, ENGLAND.
Change 19.222 -%ANALDB2R WARNING: ARGUMENT 2 TO MACRO FUNCTION and then
ANALDB2R ERROR: FILE WORK.DB2ACCTP.DATA DOES NOT EXIST, if there
Nov 14, 2001 are no observations in DB2ACCTP, but observations were in
Nov 22, 2001 both DB2ACCT and ASUMDB2A, causing USEACCT to be blank,
Nov 26, 2001 causing SKIPPAK to be wrong, which caused the incorrect
open. The logic to set USEACCT and SKIPPAK and the code
that uses then was corrected and made consistent for both
PMACCT01 and PMACCT03 reports.
-%ANALDB2R failed when PMACC01 and PMACC03 were requested,
with ERROR: FILE WORK.ASUMDB2A.DATA DOES NOT EXIST,
because the OPTIONS NODSNFERR NOVNFERR statement was not
executed the second time (after the PMACC01 report was
created, it reset those options to DSNFERR and VNFERR).
Adding the OPTIONS statement inside %MACRO PMACC01 fixed
that error, but uncovered an extra END; statement in the
PMACC03 report, that had to be conditionally generated.
-With PDB=SMF and both PMACC01 and PMACC03 requested, no
package detail was printed, but UNINITIALIZED VARIABLE
log messages were, because the VMXGSUM output of PMACC01
was written to OUTDATA=DB2ACCTP, but that overwrote the
original DB2ACCTP data, and then that summary was used as
the input to PMACC03. Using a different dataset name in
the OUTDATA= statement (and in subsequent references) was
required for both DB2ACCTP and DB2ACCTB, and now they are
OUTDATA=OUTACCTP and OUTDATA=OUTACCTB.
-A conditional execution of a PUT statement was inserted
in the Package Detail.
-Statements were indented to make the logic more obvious.
-Nov 26: Eliminated UNINITIALIZED DATETIME varialbe notes,
two CPUTIME headings became one ELAPSED and one CPUTIME,
and when there's more than a page of package detail, the
headings on package section now propagate to the first
heading lines on the second and following pages.
Thanks to Simone Niemczura, Harleysville Insurance Companies, USA.
Thanks to Andrew Taylor, AXA Shared Servicess Limited, ENGLAND.
Change 19.221 Enhanced support for NPM subtype 18/19x (Exception and
EX028EX1 Resolution events) are now output in eight new datasets
EX028EX2 based on NPMTYPE (LSCDRTYP) value, with detail sets of
EX028EX3 variables from each Volume/AOFTYPE segment. This will
EX028EX4 cause zero observations in datasets NPMEVNET & NPMERNET,
EX028EX5 which are replaced by the new datasets:
EX028EX6 NPMTYPE Exit Dataset Event Description
EX028EX7 24x EX1 NPMEXXPU X.25 (NPSI/XI/3746) PU
EX028EX8 26x EX2 NPMEXXVC X.25 (NPSI/3746) VC
VMAC28 27x,47x EX3 NPMEXNEO Generic NEO link/PU
VMXGINIT 28x,4Cx EX4 NPMEXCSL ODLC LAN
Nov 12, 2001 2Ax,2Bx EX5 NPMEXFRP Frame Relay
49x,4Ax " "
44x,45x EX6 NPMEXTRI NTRI logical/physical link
46x EX7 NPMEXXLK X.25 (NPSI/XI/3746) link
4Bxc EX8 NPMEXETH Ethernet LAN physical link
These Event/Resolution records were not reported as being
a problem, but in validating NPM 2.6 records, INVALID
DATA FOR MDY FUNCTION with NPMTYPE=28x exposed the need
to create a separate dataset for each of these events.
-Variable BASTIME now existsin NPMSUBTY 51x & 62x records,
so the test for NPMSUBTY added by Change 7.237 (!) is now
removed; only BASNCPDT and BASNCPTM GT 0 are now tested.
-Labels for CONTENT*FLAG variables were made consistent
and all are now formatted $HEX2.
-All Byte-Measurement variables are now formatted MGBYTES
so that their values will be printted with K/M/G suffix.
-Four variables previously in Kilo-Bytes are now converted
to contain bytes, and formatted with MGBYTES:
LLBVP1BB LLBVP1NB LLBVP2BB LLBVP2NB
-FORMAT statements were sorted and reorganized.
Thanks to William Sherriff, IBM Global Services, USA.
Change 19.220 SMF type 42 subtype 6 INVALID DATA FOR READTIME message
VMAC42 and hex dump were caused by blanks for both JOB name and
Nov 9, 2001 for READTIME, in a record from (old) DFSMS/MVS 3.1 for a
started task that may have been cancelled/forced. This
change supresses the message and hex dump by inserting
double-question-mark-modifier, but with or without this
change, READTIME is missing in the TYPE42DS dataset for
a record with blanks instead of a time and date.
The blanks could also have been caused by user SMF exits.
Thanks to Jesse Gonzales, The Gap, USA.
Change 19.219 Documentation only. Comments added to identify which of
VMXGUOW the "_K" macros are to be used for what. There is a pair
Nov 9, 2001 of "_Kxxxxxx" macros that can be tailored to control what
additional variables are kept from CICSTRAN, DB2ACCT, and
MQACCT. One is for numeric variables that are summed and
kept in PDB.ASUMUOW from each input dataset:
_KUOWCIC CICSTRAN
_KUOWDB2 DB2ACCT
_KUOWMQC MQACCT
and one is for character variables that are added to the
ID statement and are kept in PDB.ASUMUOW:
_KUOWIDC CICSTRAN
_KUOWIDD DB2ACCT
_KUOWIDM MQACCT
Thanks to Kenneth Johnsonk, Vanguard, USA.
======Changes thru 19.218 were in MXG 19.07 dated Nov 3, 2001======
Change 19.218 Revision to RMF III ASMRMFV program, additional revisions
ADOCRMFV to VMACRMFV will follow. Extensive documentation of the
ASMRMFV changes in ADOCRMFV.
Nov 3, 2001
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 19.217 CPUTYPE='2064'x with Spare CPUs still made PDB.ASUM70PR
VMAC7072 have bad values for LPnDUR and LPnPERCENTAGES. The real
Nov 3, 2001 source of the problem was that the TYPE70PR dataset had
an observation for each spare CPU, with non-zero DURATM,
and the LPARDUR included the DURATION of all the spares.
I considered deleting the spares in the ASUM70PR logic,
but believe many MXG users do their own sums of TYPE70PR,
so it makes more sense to only output observations in the
TYPE70PR dataset for 2064 CPUS for LPARNAME=PHYSICAL (as
it has SMF70ONT=0), or if SMF70CIN NE 'CP' (so ICFs and
anything else will be output) or if SMF70ONT NE 0 (so the
2064s with the APAR will have non-zero ONT for non-spares
and 2064s without the ONT APAR will have missing ONT and
will also be output.
If you have LPnDED='Y' or LPnWAIT='Y' (Dedicated CPUs or
Wait-Complete), then the only PDB.ASUM70PR observations
that have non-missing values for those LPARs will be the
ASUM70PR observation written on the Dedicated LPAR, i.e.,
those with SYSTEM=LPnNAME. For Dedicated/Wait Complete
CPUs, the PDB.ASUMCEC dataset was invented to solve this
problem; read the extensive discussion in the text of the
Change 17.203 that added the creation of PDB.ASUMCEC into
the ASUM70PR logic, and see member ACHAP10 for general
PR/SM CPU measurement discussion.
OBSERVATION COUNT CHANGE: TYPE70PR fewer obs.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Thanks to Jim Gilbert, EDS-Sabre, USA.
Change 19.216 MXG ASCII Execution only: R723MSCF in TYPE72GO is wrong,
VMAC7072 but not when MXG runs under MVS. It was INPUT with the
VMAC71 $EBCDIC format, but it is a character-variable-containing
VMAC73 hex-values, formatted with $HEX, and all such variables
VMAC74 MUST be INPUT with $CHAR informat to preserve the bits
VMAC75 and for MXG to be portable across platforms.
VMAC76 Under MVS, $EBCDIC and $CHAR are identical, but on ASCII
VMAC77 platforms, the INPUT must be with $CHAR to preserve the
VMAC78 original bits; if you input with $EBCDIC under ASCII, as
VMAC79 designed, SAS converts '40'x to '20'x for blanks, etc.,
VMAC102 for each byte in the field. Under ASCII, $CHAR stores
TYPEDOS the unmodified hex value in the character variable (and
VMAC102 so does $VARYING).
VMAC110 Don's discovery precipitated an audit of old MXG source
VMAC116 for other cases of incorrect informat: all variables
VMAC22 listed below are now correctly INPUT with $CHAR and
VMAC42 formatted with $HEX; none are important flags, some are
VMAC6 not even kept, many are reserved fields, but a few are
VMAC6156 used to create other (apparently-not-very-important) flag
variables, and since no one else had caught this failure
in MXG transparency across platforms, I feel very lucky!
VMAC80A I should have done this long ago.
VMAC84
VMAC90A VMAC7072: R723MSCF TEMPIOML SMF70PRF SMF70PRF
VMACACF2 SMF72RV5 SMF70V
VMACACHE VMAC71: TEMPIOML SMF71PRF
VMACAPAF VMAC73: TEMPIOML SMF73PRF
VMACAPAF VMAC74: R747PNUM R747PADR R747CNUM R747CADR
VMACBETA VMAC75: TEMPIOML SMF75PRF SMF75RV3 SMF75RVA
VMACCTLG VMAC76: TEMPIOML SMF76PRF
VMACDB2 VMAC77: TEMPIOML SMF77PRF
VMACEREP VMAC78: TEMPIOML SMF78PRF
VMACFTP VMAC79: TEMPIOML SMF79PRF SMF79RV2 R79FRCVT R79RV1
VMACIDMJ R79RSV R79USER R796FLG R797FLG R797RES
VMACIDMS R798FL1 R799RVO R799CNF R799RV0 R799CNF
VMACIMS R79BFL2 R79BRESV
VMACIMSA TYPEDOS: SUFFIX
VMACMVCI VMAC102: QW0011PS QW0015C2 QW0021KD QW0021KP QW0021K1
VMACOPC QW0021K2 QW0087AD QWP1SMRC QWP3WLST QWP4DATE
VMACSNAP QWP4DATE QW0170FC QW0177CT
VMACSPMS VMAC110: TRANPRI TCLASS TRANPRI TRANPRI TRANPRI
VMACSYNC TRANPRI TRANPRI TRANPRI TCLASS
VMACTMV2 VMAC116: WTIDUOWI WQCORREL
VMACTMVS VMAC22: CPUTYPE
ZMACxxxx VMAC42: SMF42DEV
Nov 1, 2001 VMAC6: SMF6OTOK
VMAC6156: RELFLAG
VMAC7072: R723MSCF
VMAC79: R79FRCVT
VMAC80A: CLASOPT1
VMAC84: SMF84FL1
VMAC90A: SMF9031U
VMACACF2: ACVMFMF
VMACACHE: DEVMAP1 DEVMAP2 CSDEV DVID
VMACAPAF: CPUMAP
VMACAPAF: IOPMAP
VMACBETA: BETAALVL
VMACCTLG: RELFLAG
VMACDB2: QBGBGR1 QBGBGR2
VMACERE: SYRELLVL
VMACFTP: DVGDRETC DVGDREAC
VMACIDMJ: DBKOWNER DBKOWNER
VMACIDMS: DBKOWNER DBKOWNER
VMACIMS: SYNCDMAP
VMACIMSA: SYNCDMAP
VMACMVCI: T6EUDATA
VMACOPC: EXRPURGE
VMACSNAP: SNAPSVCI SNAPDTE SNAPSTA1 SNAPSTA2 SNAPREAS
SNAPDIAO
VMACSPMS: SPMSEXTB SPMSEXTE
VMACSYNC: SYNSOIO SYNSOIO
VMACTMV2: JDCLASS
VMACTMVS: ICLCUNUM ICSUBCHN IOELCUNO IOEDDVNO IVDEVADR
IVDEVNR JDCLASS
Fortunately, except for R723MSCF in TYPE72GO cited above,
none of these variables have been reported in error by
users.
Note: most of these CHAR variables were assigned MXG's
$NOTRAN informat: that was to be used by SAS as a flag to
"Not Translate" that variable between platforms, but that
scheme will not be implemented, so whether hex-containing
character variables have informat $NOTRAN or not has no
impact. Sep 2009: MXGNOTRA in CHANGE 27.014 implemented
the NOTRAN attribute support for SAS.
I also eliminated many ZMACxxxx members that were old and
no longer needed as penultimate backup for major changes.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 19.215 MXG 19.05 only. PDB.ASUM70PR and PDB.ASUMCEC variable
VMXG70PR SHIFT was usually wrong. The _DURSET logic changes made
Nov 2, 2001 by Change 19.201 were incorrect and were revised with the
insertion of DATETIME=STARTIME; before the first include
statement for IMACSHFT, and that code block was copied to
the second include statement for IMACSHFT.
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 19.214 were in MXG 19.06 dated Oct 30, 2001======
Change 19.214 Support for NTSMF SMS Objects create five datasets:
EXNTSMDI dddddd dataset description
EXNTSMEX NTSMDI SMSDISDM SMS DISCOVERY DATA MANAGER
EXNTSMIM NTSMEX SMSEXTHR SMS EXECUTIVE THREAD STATES
EXNTSMSE NTSMIM SMSINMEM SMS IN-MEMORY QUEUES
EXNTSMST NTSMSE SMSSENDR SMS STANDARD SENDER
IMACNTSM NTSMST SMSTATUS SMS STATUS MESSAGES
VMACNTSM
VMXGINIT
Oct 31, 2001
Thanks to Jim Quigley, ConEd, USA.
Change 19.213 "Support" for DB2 V7 QLES section was added to DB2STATS
VMACDB2 dataset (from 100 subtype 1) record, even though none of
Oct 31, 2001 the QLES fields are described in the DSNDQLES DSECT; they
are all flagged with (S) - Serviceability. Additionally,
the 8-byte QLETIMEx "time" fields, are actually two four
byte fields, which I have assumed to be like CICS "time"
values, with a 4-byte time value and a 4-byte count when
the time value was updated. While all of the other four
byte counters are accumulated, five of the "time" fields
are not accumulated: QLETIMEW,QLECNTM,QLETIMEI,QLECNTDY,
and QLECNTW. (The pair of time and count variables are
named QLETIMEx and QLECNTx, labelled "QLETIMEx*TIME" and
"QLEXTIMEx*COUNT". The QLExxxxx variables are discussed
in IBM documentation concerning the use of DSNTIP7 and
Section 2 of the DB2 Installation Guide, specifically to
measure and set the MAXIMUM LE TOKENS (LEMAX) on that DB2
panel to ensure that there are enough, and not too many,
LE tokens. Whether I've guessed correctly on the order
of time-count, and whether my assumed time units of secs
are valid, will hopefully confirmed or corrected, when
either IBM provides additional documentation, or when you
users can prove or disprove the numbers! Why only five
counters are not accumulated, especially since they are
really in pairs, suggests possible alignment errors, but
even then, I would expect four or six, not five.
Thanks to Harry Price, Florida Light and Power, USA.
Thanks to Ed Gambon, Florida Light and Power, USA.
Change 19.212 MXG 19.05 ONLY, CPUTYPE not 2064, LPARCPUS count is wrong
VMAC7072 in TYPE70PR and in ASUM70PR, because the test added by
Oct 30, 2001 Change 19.189 to support APAR OW49536 only was valid if
the CPUTYPE='2064'x. The revised change now counts CPUS:
IF SMF70CIN NE 'ICF' AND ( (SMF70ONT NE 0) OR
(SMF70ONT EQ 0 AND CPUTYPE NE '2064'X) )
THEN LPARCPUS=LPARCPUS+1;
and thus is CPU-Type dependent until IBM externalizes the
DDBOnlin flag into the RMF type 70 record as a safer test
field in the future.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 19.211 Support for Tivoli/Netview NPM 2.6 COMPATIBLY added one
EX028INN new subtype, 17x, for new NPMINNRC dataset containing
VMAC28 Router CISCO CIP Interval Volume Data (i.e., records are
VMXGINIT written only for the routers that have installed CISCO
Oct 30, 2001 CIP card).
Oct 31, 2001
Change 19.210 NOT SORTED TYPE72GO error in WEEKBLDT caused by Change
WEEKBLDT 17.353 that added variable RPRTCLAS to the BY list in
WEEKBL3T TYPE72GO/WEEKBLD/MONTHBLD but missed WEEKBLDT/WEEBL3T.
Oct 30, 2001 This worked fine for two years, but a SET CLOCK event at
two sites exposed the MXG inconsistency that caused the
error. Correcting the BY list eliminated the error.
Thanks to Art Hunter, Penn Mutual, USA.
Thanks to Richard Lopez, Johnson and Johnson, USA.
Change 19.209 RMF III job monitor total storage is created in new
VMACRMFV variable ASIDTOT=SUM(ASIFMCT,ASIFMCTI,ASIESF,ASIESFI);
Oct 28, 2001 in ZRBASI dataset.
Thanks to Mark Wittie, FMR, USA.
Change 19.208 First 19.05 only. SYSTEM object has missing counters if
VMACNTSM NRDATA=24; first IF test was revised.
Oct 24, 2001
Thanks to Jim Quigley, ConED, USA.
======Changes thru 19.207 were in MXG 19.05 dated Oct 24, 2001======
Change 19.207 Some sample MQ Series Exception reports based on SMF 115
ANAL115 records (TYPS115).
Oct 24, 2001
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Yakov Nudel, Beta Systems, USA.
Thanks to Jan Hess, America West, USA.
Change 19.206 Unexpected blank 80-byte record at start of compressed
VMACTMO2 Landmark file caused INPUT STATEMENT EXCEEDED error. This
Oct 24, 2001 change detects short records, lists them on the SAS log,
and deletes them. These records are probably being added
as part of the site's tape initialization process, rather
than being created by Landmark.
Thanks to Tim Sisk, CSC Corp, USA
Change 19.205 Using ASUMCICS with Landmark TYPSTMO2 member failed, due
ASUMCICS to the incorrect include of member IMACMONI instead of
Oct 23, 2001 VMACTMO2 (so _LMONTSK was not defined).
Thanks to Robin Murray, Maritime Life, CANADA
Change 19.204 Support for CICS/TS 2.2 Statistics changes to CICDS data.
VMAC110 IBM has changed the 9th and 11th TCB buckets contents and
Oct 23, 2001 added a twelfth bucket:
Nov 12, 2001 MXG Prefix TCB Number TCB Name 2.1 TCB 2.2 TCB
DSG 1 QR 1 1
DS2 2 RO 2 2
DS3 3 CO 3 3
DS4 4 SZ 4 4
DS5 5 RP 5 5
DS6 6 FO 6 6
DS7 7 SL 7 7
DS8 8 SO 8 8
DS9 9 J8 9 H8 12
DSA 10 L8 10 11
DSB 11 S8 11 9
DSC 12 D2 -- D2 10
MXG variable DSnTCBNM, where n is the TCB number, will
contain the actual name of the TCB so you can verify
which set of TCB values applies to which TCB; because of
the IBM change, the LABEL values for DS9,DSA,DSB, and DSC
variables may be incorrect, but DSnTCBNM will be valid.
There are additional DSG Pool segments that are not yet
decoded, as I need actual data to validate their location
in the SMF record to write that code.
Change 19.203 Support for z/OS Version 1.1 and 1.2 APAR and MXG error.
VMAC78 APAR OW49806, for z900 with z/OS 1.2, adds new IOP
Oct 23, 2001 (I/O Processor) utilization measurements have been added
TYPE78IO dataset:
R783IIPB='TIMES WHEN*IOP*WAS BUSY'
R783IIPI='TIMES WHEN*IOP*WAS IDLE'
R783IIFS='IO FUNCTIONS*INITIALLY*STARTED'
R783IPII='PROCESSED*I/O*INTERRUPTS'
R783ICPB='RETRIES*DUE TO*CHANNEL*PATH*BUSY'
R783IDPB='RETRIES*DUE TO*DIRECTOR*PORT*BUSY'
R783ICUB='RETRIES*DUE TO*CONTROL*UNIT*BUSY'
R783IDVB='RETRIES*DUE TO*DEVICE*BUSY'
But in installing this support, I found the new variables
for DCM managed channels, added by Change 18.134 for 1.1
(R783MCMN/MX/DF/PTM/DBPM/CUBM added to dataset TYPE78IO),
should have instead been added to dataset TYPE78CU, so
this change is required for z/OS 1.1 and 1.2 on all
platforms, not just z900s.
14May02: Documented in comments in VMAC78, but not here,
z/OS 1.2 R783GSAM/NRCMPTSM and R783PB/PCTPTHBY are now
reserved, causing PCTPTHBY to be missing in TYPE78CF.
16Jun02: This also causes PCTALLBY to be missing in
TYPE78CU, beginning with Z/OS 1.2.
Change 19.202 Support for Serena's Ultimizer user SMF record.
EXULTM01 Four datasets are created:
EXULTM02 ULTM01 ULTMIZ01 VSAM BLOCKSIZE OPTimIZATION
EXULTM03 ULTM02 ULTMIZ02 QSAM BUFFER OPTIMIZATION
EXULTMNN ULTM03 ULTMIZ03 QSAM BLOCKSIZE OPTIMIZATION
FORMATS ULTMNN ULTMIZNN BLDVRP OVERRIDE OR BYPASSES
TYPEULTM This vendor puts the RDRDATE where the SYSTEM should be
TYPSULTM in the SMF header. The subtypes 4 thru 10 are all output
VMACULTM in the ULTMIZnn dataset, which appears to also have
VMXGINIT duplicate records created for some subtypes.
Oct 20, 2001
Change 19.201 Several enhancements to PDB.RMFINTRV and PDB.ASUM70PR:
ASUM70PR -Variables PARTISHN TOTSHARE LPARSHAR and CECSER added to
VMXG70PR PDB.RMFINTRV by your include of ASUM70PR after BUILDPDB
VMXGRMFI that updates PDB.RMFINTRV after PDB.ASUM70PR is built.
Oct 22, 2001 -The SYNC59 logic in VMXGRMFI was revised; it could be
off by one minute in creating PDB.RMFINTRV.
-The 70ID list was cleaned up and now is in one place.
-If you used the (recently added) INTERVAL= and SYNC59=
arguments in your RMFINTRV member to control %VMXGRMFI's
summary interval, variables PLATBUSY and PLATCPUS could
be missing, because the ASUM70PR program that adds them
into PDB.RMFINTRV uses the _DURSET macro in IMACRMFI to
set the ASUM70PR interval, causing the mis-match. This
exposure is fixed by new member VMXG70PR, a new %MACRO
definition, that is now invoked by member ASUM70PR, with
the same arguments as VMXGRMFI, so that if you do tailor
RMFINTRV with INTERVAL= and/or SYNC9=, you now can (and
now MUST!) use the same arguments and values in both your
RMFINTRV and ASUM70PR members, so that the intervals in
RMFINTRV, ASUM70PR, and ASUMCEC are identical.
-The default value in both RMFINTRV and ASUM70PR are set
to INTERVAL=DURSET and SYNC59=NO, so that the default
interval in PDB.RMFINTRV and PDB.ASUM70PR is set by the
member IMACRMFI (in it's _DURSET macro definition).
By default, IMACRMFI member does no summarization, and
instead creates one observation in PDB.RMFINTRV and
PDB.ASUM70PR for each original RMF interval.
-If you have tailored member IMACRMFI to set the summary
interval (eg, HOUR, SHIFT, etc) you want, then it will
be used for both RMFINTRV and ASUM70PR.
-If instead you tailored member RMFINTRV to use INTERVAL=
or SYNC59= arguments, then you MUST also tailor member
ASUM70PR to use those same arguments and values.
-With the added variables, the maximum percent CPU busy
that a system can reach based on LPAR weights can be
calculated
LPARMAX=100*(LPARSHAR/TOTSHARE)*(NRCPUS/PARTNCPU);
E.g.: CEC with 11 physical engines and with 3 LPARS:
6 engines and weights of 47 in two LPARS
2 engines and weight of 6 in one LPAR
LPARMAX = 100 * (47/100) * (11/6) = 86.6 %
is the busyiest those six engine LPARs can be,
even though PLATBUSY is 100%
-Correction in ASUM70PR for Dedicated processors to change
IF LCPUDED='Y' AND LCPUWAIT='Y' THEN DO; to now read
IF LCPUDED='Y' OR LCPUWAIT='Y' THEN DO;
because the logic only worked for Dedicated and LCPUWAIT,
which could cause the non-dedicated CPU busy to be wrong.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Steve Emson, TESCO, ENGLAND.
Thanks to Richard Rich, State of California Teale Data Center, USA.
Change 19.200 Support for SMF type 82 crypto facility record
EXTY8201 creates thirteen new datasets:
EXTY8203 TY8201 TYPE8201 INITIALIZATION
EXTY8204 TY8203 TYPE8203 STATUS CHANGE
EXTY8205 TY8204 TYPE8204 CONDITION CODE 3
EXTY8206 TY8205 TYPE8205 SPECIAL SECURITY MODE
EXTY8207 TY8206 TYPE8206 MASTER KEY PART
EXTY8208 TY8207 TYPE8207 KEUK PART
EXTY8209 TY8208 TYPE8208 CKDS REFRESH
EXTY8210 TY8209 TYPE8209 CKDS UPDATE
EXTY8211 TY8210 TYPE8210 PKA KEY PART
EXTY8212 TY8211 TYPE8211 CLEAR NEW MASTER KEY PART
EXTY8213 TY8212 TYPE8212 PUBLIC KEY SECURE CABLE
VMAC82 TY8213 TYPE8213 PUBLIC KDS UPDATE
VMXGINIT
Oct 19, 2001
Change 19.199 Incorrect copying in the weekly phase was corrected by
BLDNTPDB inserting a RUN; statement between the PROC COPY and the
Oct 19, 2001 %VMXGOPTR invocation (to force macro resolution).
Thanks to Greg Jackson, National Life of Vermont, USA
Change 19.198 Invalid values for sample counts of 'FFFFFFFF'x for the
VMAC7072 PCTDLTOT (R723TOT) and PCTDLQ (R723CQ) and 'FFFFFFFA'x
Oct 19, 2001 for PCTDLTDQ (R723CTDQ) caused very small VELOCITY and
very large PERFINDX values. MXG now tests those three
fields and forces a missing value when large values are
found in the IBM record.
Updated: Oct 30, 2001: IBM APAR OW50380 fixes the error,
at least for basic mode.
Thanks to Jiann-Shiun Huang, CIGNA, USA
Thanks to Perry Metzel, Hewitt, USA.
Change 19.197 -Support for revised SYSTEM object with NRDATA=24, which
EXNTEPXY reinstated Total Interrupts/Sec counter to match all of
EXNTEXEX the SYSTEM fields that used to exist in NT 4.0.
EXNTMEAL -Support for the restructured SQL 2000 objects creates
EXNTMECA these seventeen new SQLServer datasets:
EXNTMECO NTQLAM MSQACCES NT MSSQL:ACCESS METHODS
EXNTMEIM NTQLBD MSQBKPDV NT MSSQL:BACKUP DEVICE
EXNTMEM NTQLBM MSQBUFMG NT MSSQL:BUFFER MANAGER
EXNTMEOE NTQLBP MSQBUFPA NT MSSQL:BUFFER PARTITION
EXNTMEOR NTQLCM MSQCACMG NT MSSQL:CACHE MANAGER
EXNTMEPO NTQLDA MSQDATAB NT MSSQL:DATABASES
EXNTMEPR NTQLGS MSQGENST NT MSSQL:GENERAL STATISTICS
EXNTMESA NTQLLA MSQLATCH NT MSSQL:LATCHES
EXNTMESR NTQLLO MSQLOCKS NT MSSQL:LOCKS
EXNTMETD NTQLMM MSQMEMMG NT MSSQL:MEMORY MANAGER
EXNTMETS NTQLRA MSQREPAG NT MSSQL:REPLICATION AGENTS
EXNTMEWM NTQLRD MSQREPDI NT MSSQL:REPLICATION DIST.
EXNTMIGA NTQLRL MSQREPLR NT MSSQL:REPLICATION LOGREADER
EXNTMIGP NTQLRM MSQREPME NT MSSQL:REPLICATION MERGE
EXNTMISC NTQLRS MSQREPSN NT MSSQL:ACCESS METHODS
EXNTMISE NTQLSE MSQUSRSE NT MSSQL:USER SETTABLE
EXNTMISI NTQLSS MSQSTATS NT MSSQL:SQL STATISTICS
EXNTQLAM -Support for 14 new MS Exchange objects create datasets:
EXNTQLBD NTMEAL MSEXMEAL NT MSEXCHANGEAL
EXNTQLBM NTMECA MSEXCACH NT MSEXCHANGEDSACCESS CACHES
EXNTQLBP NTMECO MSEXCONT NT MSEXCHANGEDSACCESS CONTEXTS
EXNTQLCM NTMEIM MSEXIMAP NT MSEXCHANGEIMAP4
EXNTQLDA NTMEM MEMORY NT MEMORY
EXNTQLGS NTMEOE MSEXOLEV NT MSEXCHANGE OLEDB EVENTS
EXNTQLLA NTMEOR MSEXOLRE NT MSEXCHANGE OLEDB RESOURCE
EXNTQLLO NTMEPO MSEXPOP3 NT MSEXCHANGEPOP3
EXNTQLMM NTMEPR MSEXPROC NT MSEXCHANGEALACCESS PROCESSES
EXNTQLRA NTMESA MSEXMESA NT MSEXCHANGESA - NSPI PROXY
EXNTQLRD NTMESR MSEXSRS NT MSEXCHANGESRS
EXNTQLRL NTMETD MSEXTRDR NT MSEXCHANGEIS TRANSPORT DRIVER
EXNTQLRM NTMETS MSEXTRSD NT MSEXCHANGETRANSPORT STORE DRIVER
EXNTQLRS NTMEWM MSEXWEBM NT MSEXCHANGEWEB MAIL
EXNTQLSE The duplicate removal logic was validated and BY lists
EXNTQLSS were enhanced where needed to ensure removal. There are
IMACNTSM actual duplicates in MSEXCONT that are being investiaged.
NTINTRV -In NTINTRV, the NTCONFIG dataset is no longer combined in
VMACNTSM to PDB.NTINTRV because is is not an interval dataset.
VMXGINIT -SP2 for Exchange 2000 added object MSExchangeIS Mailbox
Oct 19, 2001 that appears to have the same fields as MS..eIS Public,
so the Mailbox records are output in MSEXISPU dataset.
Object for MSExchangeIS was restructured with some new
and some removed fields. The "Database ==> Instances"
object is questionable, and missing fields in Database
object have yet to be resolved, but both objects with
"Database" in their name are now output into DATABASE.
-New Epoxy object creates new EPOXY dataset.
-New MicroSoft Gatherer object creates new MIGATHER
-New " Gatherer Projects object creates new MIGATHPR
-New Microsoft Search object creates new MISEARCH
-New " Search Catalogs object creates new MISEARSC
-New " Search Indexer Catalogs creates new MISEARSI
-New Exchange Server HTTP Extensions new EXCHHTEX
Change 19.196 Variable QBGBGCS, the current status of GBPCACHE (NO/YES)
VMACDB2 was added by DB2 Release 6, but was skipped by MXG; now
Oct 17, 2001 that variable is INPUT and kept in dataset DB2GBPAT.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 19.195 Cosmetic. Some of the error messages for bad segments
VMAC108 had incorrect segment name in the text, possibly causing
Oct 17, 2001 confusion, if any of those conditions ever occurred.
Thanks to Bob Furlong, Chase, USA.
Change 19.194 Change 19.101 removed PGMRNAME from the TYPE30_4 step
BUILD005 dataset in BUILDPDB processing to protect against blank
BUIL3005 values, but that change caused PGMRNAME to not be kept
Oct 17, 2001 in PDB.STEPS; by adding PGMRNAME to the PDBADD2/PDBADD3
Apr 5, 2002 macros, the PGRMNAME from the PDB.JOBS dataset will now
be copied into the PDB.STEPS dataset. However, PGMRNAME
will still be blank if no PGMRNAME was used on the JOB
card: PDB.JOBS and PDB.STEPS contains observations for
all "jobs": STCs, TSO, OMVS, USS, APPC, etc, all will
create "job" records that can have no PGMRNAME value,
so variable TYPETASK may explain blank PGMRNAME values.
Since BUILDPDB keeps PGMRNAME from only the 30.1 Job Init
and 26 Job Purge, if "Spinning" was not enabled in your
IMACSPIN, and if only step/job/print without init/purge
are found for a job, then variable INBITS won't contain
an I or a P, and PGMRNAME will be blank in JOBS/STEPS.
5Apr02: Text revised: why it can still be blank.
Thanks to Bob Greer, Nissan North America, USA.
Change 19.193 Support for IFCID=225, DB2 Storage Manager Pool Summary
VMAC102 Statistics to create dataset T102S225, with lots of stats
Oct 17, 2001 on pool sizes and concurrent activity.
Thanks to Sim Williams, Fidelity, USA.
Change 19.192 New formatted variable S42DSBUF for VSAM Buffer type:
FORMATS S42DSBUF='VSAM*BUFFER*TYPE'
VMAC42 with values 0:NSR 1:RLS 2:LSR 3:GSR
Oct 16, 2001 and new character flag variables ('Y' or blank) are added
S42DSEXC='OPEN FOR*EXCP*PROCESSING?'
S42DSFXD='NONVSAM*FIXED*LENGTH*RECORDS?'
S42DSPL ='PROGRAM*LIBRARY?'
S42DSEF ='EXTENDED*FORMAT?'
S42DSEFC='COMPRESSED*FORMAT?'
to TYPE42DS by decoding the existing S42DSFL1 variable.
These new variables were used to examine why the S42AMxxx
Access Method Statistics variables are sometimes missing
in TYPE42DS. Thus far, all observations with
S42DSEXC='Y' - EXCP Access Method
do not contain an Access Method Statistics section, but
no other pattern has been found to explain why that A.M.
segment is not present (S42DSAMO=0) for other datasets.
Thanks to Rob D'Andrea, NatWest, SCOTLAND.
Change 19.191 Variable CPUTYPE was added to the KEEP= list for TYPE70PR
VMAC7072 dataset.
Oct 15, 2001
Thanks to Helmut Roese, COM Software GmbH, GERMANY.
Change 19.190 This example report to calculate per-service-class CPU
ANALSRVC busy percentages had a FORMAT PGPCTCAP PGPCTUSE 5.1; that
Oct 7, 2001 should have been FORMAT SVPCTCAP SVPCTUSE 5.1; .
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
======Changes thru 19.189 were in MXG 19.04 dated Oct 5, 2001======
Change 19.189 Support for APAR OW49536 (INCOMPAT if you have SPARE CPU
VMAC7072 engines on your 2064 CPU). Reserve/Spare CPUs on 2064s
Oct 5, 2001 have segments in type 70 records that were being counted
as a real CP engine (both in RMF reports and in MXG!).
This change tests SMF70ONT, the new LPAR "online time";
only if that value is non-zero will that CP be counted.
A missing value in SMF70ONT will be counted; that is a
record without the new field that can't have the problem.
A non-zero non-missing value in SMF70ONT will be counted,
because it was online during the interval.
Variable LPARCPUS in dataset TYPE70PR, and the LPnNRPRC
variables for each LPAR in dataset ASUM70PR will be wrong
and LPAR percentages based on these variables will also
be incorrect without this change.
Thanks to Al Sherkow, I/S Management Strategies Ltd, USA.
Change 19.188 TYPEIMSA corrected ENDTIME and STRTTIME for GMTOFFTM, but
TYPEIMSA variable END7TIME was not corrected, so these variables
Oct 5, 2001 IMSSRVTM IMSRESTM IMSSRVTS and IMSRESTS were off from TOD
by the value of GMTOFFTM. All are now corrected.
Thanks to Daniel Cannon, The Hartford, USA.
Change 19.187 Enhancements for MXG NTSMF support:
ASUMNTIN -NTCONFG file has been added in NTINTRV so KEEPALL=YES can
BLDNTPDB be used in ASUMNTIN.
NTINTRV -ASUMNTIN now uses KEEPALL=YES for performance reasons.
-RUNMNTH processing in BLDNTPDB corrects problem passing
Oct 5, 2001 a variable that should not have been.
Stay tuned: more enhancements, like RERUN, in progress.
Change 19.186 Support for RMF type 74 subtype 4 "Broken Records" output
VMAC74 observations from the subsequent, incomplete record when
Oct 2, 2001 that record should have been deleted, as it was precedeed
by the MXG "Broken Record" message from the previous SMF
record. This change only outputs to TYPE74CF when the
SUM(SMF744XN,SMF744GN,SMF744QN,SMF744SN,SMF744PN)
is greater than zero.
For First 19.04: This change relocate the RO section,
inserted the missing END; and corrected the comment that
has masked the missing END;
Thanks to Wally Danielson, Airborne, USA.
Change 19.185 Support for Implex USER SMF record creates five datasets
EXMPLXGA one per subtype, from Williams Data Systems:
EXMPLXIN Subtype DDDDDD Dataset
EXMPLXPE 1 MPLXIN IMPLEXIN Interface Statistics
EXMPLXPM 2 MPLXSE IMPLEXSE Service Statistics
EXMPLXPO 3 MPLXGA IMPLEXGA Gateway Statistics
EXMPLXRT 4 MPLXRT IMPLEXRT RTT Statistics
EXMPLXSE 5 MPLXPR IMPLEXPR Protocol Monitoring
FORMATS These records contains accumulated fields, so the member
IMACMPLX both TYPEMPLX and TYPSMPLX invoke the _SMPLX "sort MPLX"
TYPEMPLX macro, which sorts and deaccumulates these datasets into
TYPSMPLX the default DDname of PDB. Implex is an IP monitor with
VMACMPLX 3270 response time monitoring.
VMXGINIT
Oct 5, 2001
Thanks to Rolf Meinert, Volkswagen, GERMANY.
Change 19.184 MXG Data Sets contain labels with unique syntax DDDDDD:,
BLDNTPDB that is used via PROC CONTENTS to control copying of the
Oct 2, 2001 daily/weekly/monthly in the BLDNTPDB logic. However, the
DATA WEEK.NTxxxxx; SET MON.NTxxxxx ... SUN.NTxxxxx; does
not propagate a dataset LABEL, causing RUNMNTH=YES to
fail with ERROR: BY VARIABLE _B IS NOT ON INPUT DATASET
(because the DDDDDD value is used to create &SUFX, but if
there is no DDDDDD value in the label, &SUFX is blank).
The circumvention is to use the PDB, instead of the WEEK.
as the library to read to get the DDDDDD values. Change
%VMXGINV(LIBNAME=WEEK); to %VMXGINV(LIBNAME=PDB) after
the comment "BUILD THE MONTHLY" to circumvent.
Thanks to Liz Slack, Premera Blue Cross, USA.
======Changes thru 19.183 were in MXG 19.04 dated Oct 1, 2001======
Change 19.183 Variable R742PIOT in dataset TYPE74PA was always missing.
VMAC74 The test IF SKIP GT 4 THEN DO; prior to its INPUT should
Oct 1, 2001 have been IF SKIP GE 4 THEN DO;
Thanks to Philip Foster, CGI Inc, CANADA.
Change 19.182 A new alternative report member for GRAFWORK, enhanced to
GRAFWRKM support all workload that are now createable in RMFINTRV,
GRAFWRKX with an additional neat twist. With GRAFWORK, workloads
Oct 1, 2001 are stacked from bottom to top and the order was fixed:
Overhead, CICS, IMS, TSO, BATCH, OTHER OTH1-OTH9.
But now with GRAFWRKS, if IMACWORK=NO is used, there is
total control of the order of stacking (except that the
"overhead", or uncaptured, is always at the bottom, so
you can order the stacking to map the priorities of your
workloads. GRAFWRKM is an example using GRAFWRKX.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.181 Support for CICS/TS 2.2 SMF 110 Subtype 1 CICSTRAN record
VMAC110 is almost compatible! IBM added two new variables at the
Sep 29, 2001 end of the standard transaction segment:
PTPWAITM='3270 BRIDGE*PARTNER*WAIT*ELAPSED*TIME'
PTPWAICN='3270 BRIDGE*PARTNER*WAIT*COUNT'
so that all of the standard IBM fields are still correct
with earlier versions of MXG that supported TS 2.1 data.
However, if you are processing any of the optional CICS
segments, this change is required so that the optional
variables are valid: (you ARE processing optional CICS
segments if there are IMACICxx members in your tailoring
MXG library).
This change supports only the subtype 1 record. A later
change will support the CICS TS 2.2 Statistics subtype 2
record changes (INCOMPAT: CICDS data moved to STID=60).
Change 19.180 Support for SMF 120 WAS/390 4.0 EE (Websphere Application
EXT120JI Server, Enterprise Edition) which adds new Server Type:
EXT120JC -MOFW server supports both C++ and Java BOs (in 3.02)
FORMATS -J2EE server supports EJBs only (new in 4.0)
VMAC120 The existing subtype 1 and 3 records for MOFW servers are
VMXGINIT reused for the new J2EE server, so existing MXG datasets
Sep 28, 2001 TYP102SA and TYP102SC from subtype 1 Server Activity and
Oct 17, 2001 TYP102SI from subtype 3 Server Interval are changed only
by the addition of new variable SM120ST, Server Type, to
identify MOFW or J2EE server type. Existing MOFW subtype
2 and 4 could not be reused; new subtypes 5 and 6 create
MXG dataset TYP120JC (subtype 5 J2EE Container Activity)
and dataset TYP120JI (subtype 6 J2EE Container Interval).
-These new records are the first SMF records to contain
UCS, or Unicode DBCS (Double Byte) character data in new
variables SM120JA8/SM120JB1/SM120JM1/SM120JA, with the
names of containers, ejbRoles, methods, and AMCNames of
the bean, etc. However, SAS support for UCS (Informat
$UCS2Bnnn.) became available in SAS V8, so those new
UCS variables will have valid printable names only if
SAS Version 8 or later is used to build the datasets.
Although those names can be as large as either 256 or 512
characters (512 or 1024 bytes of DBCS data in the record)
until there is a need for more text, and for simplicity
and compatibility, only the first 200 characters are
kept, creating a unique new MXG macro variable named
UCS2B4, with value:
IF &SYSVER GE 8.2 THEN %LET UCS2B4= $UCS2B4 ;
ELSE %LET UCS2B4= $EBCDIC2;
so that using "&UCS2B4.00" syntax, SAS V8.2+ will INPUT
with $UCS2B400. while earlier INPUT is with $EBCDIC200.
Code was revised and validated with J2EE data, Oct 17.
Change 19.179 RMF III LENGTH=0 cause INPUT STATEMENT EXCEEDED error,
VMACRMFV but a rerun does not fail, (but a rerun against the VSAM
Sep 28, 2001 file to create the BSAM file will have different records
because RMF III VSAM continuously runs and wraps). This
change tests and deletes LENGTH=0 records with a message
on the log to show how many records were found.
Thanks to John F. Gebert, Office Depo Inc, USA.
Change 19.178 DB2 variable QWHSLUCC is the character variable with the
VMACDB2 Commit Count, but that should have been a numberic value.
VMACDB2H Since I can't change the type from CHAR to NUM without a
Sep 27, 2001 serious compatability issue, I have created QWHSLUCN as
a numeric variable with the Commmit Count.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.177 Support for IMS 6.1 Fast Path records (INCOMPAT).
VMACIMS Fast Path subcodes 01, 03, 36, 37, and 38 were all
VMACIMSA changed by IBM; fields were inserted in all records, and
Sep 27, 2001 new variables are now created and kept. Support was then
Oct 15, 2001 revised Oct 15 to correct VARIABLE STRTTIME NOT FOUND
errors introduced by the first change.
Thanks to Pete Gain, SAS, ENGLAND.
Change 19.176 Support for z/OS Version 1 Release 2 changes in SMF data:
EXTY7002 -TYPE30xx - bit 2 in field SMF30SFL (Storage/Paging) new
EXTY74DU variable IEFUSIME='IEFUSI*CHANGED*MEMLIMIT?'
FORMATS in TYPE30_4, TYPE30_V, TYPE30_5, TYPE30_6.
IMAC7072 - new vars MEMLIMIT='MEMLIMIT*VALUE'
IMAC74 and SMF30MLS='SOURCE OF MEMLIMIT' which
VMAC30 is decoded by new MG030ML format:
VMAC7072 1:MEMLIMIT SET BY SMF
VMAC71 2:MEMLIMIT SET IN JCL
VMAC73 3:MEMLIMIT BASED ON REGION=0
VMAC74 4:MEMLIMIT SET BY IEFUSI
VMAC78 but SMF30MLS and MEMLIMIT are set missing (and
VMAC79 not zero) if SMF30MLS has no bit set (i.e., if
VMAC90 MEMLIMIT is not specified).
VMXGINIT -TYPE70PR - Existing SMF70BDA is now divided by SMF70DSA
Sep 25, 2001 to calculate Average number of LCPUs Active,
as the variable was labelled, and existing
SMF70ACS is now documented as 4 bytes (z/OS
R1.1 doc had ACS 2 bytes with +2 after MAS; I
assume this is an IBM doc correction).
SMF70ACS is now divided by SMF70DSA.
-TYPE7002 - New Dataset for Cryptographic Coprocessor data
contains PCCI Cryptographic Hardware execution
times and counts for all operations and all
RSA-key-generation operations.
-TYPE71 - New Swap Reason "In-Real Swap" is added in new
variables SWAPIR/EXTAUXIR/LOGAUXIR/LOGEXTIR/
PHYAUXIR/PHYEXTIR.
-TYPE72GO - New variable R723CLSC, only in Reporting Class
observations, contains the name of the Service
Class that last contributed to this Reporting
Class; blank if this obs is for Service Class.
Note: Previously Reporting Classes did not
have Periods, (only Service Classes
had periods), but now both can have
up to 8 periods.
- New variable R723HETR='Y' if this report class
period is "Heterogeneous":
If the report class contains transactions
from a single service class, R723HETR='N'
for a "Homogeneous" reporting class.
Report classes now can combine transactions
running in different service classes, and
those "Heterogeneous" have R723HETR='Y'.
BUT: IBM says data is invalid if hetero.
- New variables R723CAMU/R723CAMD (CAM CRYPTO)
and R723APU/R723APD (AP CRYPTO) contain TCB
USING and TCB DELAY samples for Cryptographic
Asynchronous Message Processor (CAM) and for
Cryptographic Assist Processor (AP).
- New R723FQD Feature Queue Delay Samples: a TCB
was found waiting on a processor feature queue
associated with a CPU, are also included in
the delay samples in R723CCDE (MXG PCTDLCDE).
Note: Feature Queue Using Samples are in
MXG variable PCTUSCUS (R723CCUS).
-TYPE7204 - Type 72 subtype 4 delay samples have new var
R724OR18 for new "In-Real" Swap Reason delays.
-TYPE73 - New CPMF Channel Measurement Groups 3 adds new
channel traffic variables for HiperSockets, or
the IQDIO, a/k/a IQD (Internal Queued Direct
Communication) channel type, a high-speed LAN
for communications between LPARs in a CEC/CPC.
Eleven variables with byte rates per second,
for both LPAR and Totals, for both data unit
and message unit traffic, plus unsuccessful
sends and receive counts, but there is no
capacity measure for the IQD. These new
variables exist only for SMF73CMG=3:
SMF73PDS SMF73PDU SMF73PMS SMF73PUB SMF73PUM
SMF73TDS SMF73TDU SMF73TMS SMF73TUB SMF73TUM
SMF73PUS
-TYPE74CF - New variables added to TYPE74CF with bit masks
of paths available and installed and channel
path type acronym for each of 8 possible paths
in variables
R744FPAS R744FPIS R744FPCM R744FTA1-R744FTA8
-TYPE74ST - New variables for waits, wait duration, and
square of wait duration for waiting for peer
subchannel, for waiting for peer with reserve
held, and for waiting for peer completion in
these new variables:
R744SCSS R744SCST R744SCTC R744SLSV R744SPES
R744SPLN R744SPSS R744SPST R744SPTC R744SRSS
R744SRST R744SRTC
-TYPE74DU - New remote facility data section in subtype 4
Coupling Facility data for your Duplexed CFs
creates new dataset TYPE74DU.
-TYPE746x - SKIP calculation corrected for 746BL/746DL.
-TYPE747x - While decoding of the subtype 7 FICON Director
is in place in VMAC74, no datasets are created
until I have test data to understand.
-TYPE78CF - IBM removed PCTPTHBY and NRCMPTSM fields, so
they will now have missing values.
-TYPE791 - Variable R791TTOD now is non-zero and contains
"Real Time into Transaction".
- Added swap 'SR'='IN REAL' to FORMAT $MG079SR
- New R791MLIM variable ASID Memory Limit added.
- Bits in R791FLG and R792FLG added for temporal
affinity
-TYPE79C - New CMG=3 data added
-TYPE79E - Variables CHPIDTKN and NRCMPTSM now reserved.
-TYPE90 - Support for subtypes 26,27,28,29,30,31,32.
Change 19.175 Statistics reports for multiple intervals used the number
ANALDB2R of intervals as a divisor, incorrectly, but only on one
Sep 25, 2001 summary page, and only for the Long Statistics summary
and trace, PMSTA01/PMSTA03, which are not invoked by
default. It's been this way for some time, suggesting
that a) that page of that report is not very useful, or
b) no user has looked at it that closely until now!
Thanks to Liesbeth Post, KLM, THE NETHERLANDS.
Change 19.174 Two separate sites report errors in SMF type 60 records,
VMAC60 causing INPUT STATEMENT EXCEEDED RECORD error when read.
Sep 21, 2001 Both had VVRTYPE=Z:PRIMARY, but the two SMF records are
Oct 1, 2001 wrong in different ways:
-ENTTYPID=C:CLUSTER record, VVR has impossible value for
offset-to-next-field of 1792 in a 588 byte SMF record:
VVRLOKYL=1792 (0700x located at byte 563) can't be
valid, but the expected fields VVRXSC1 that I tried to
INPUT look like they are there after VVRLOKYL in the
record. Maybe first byte of VVRLOKYL is now a flag
(note '.....11100000000'B value in this record)?
CIRCUMVENTION: This change now compares VVRLOKYL with
LENGTH to prevent INPUT, but when prevented, those
additional fields will have missing or blank values.
-ENTTYPID='A:NON-VSAM', NVR has invalid values in length
and name fields for the Storage Class, Data Class, and
the Management Class names:
VVRSTGLN Length field = 6 , but 8 EBCDIC bytes follow
before the next length:
VVRDATLN Length field = 4 , and 4 bytes do follow, but
only 3 are EBCDIC, final is
'00'x instead of '40'x, and
VVRMGTLN Length field = 6 , but four unprintable hex
bytes are followed by four
EBCDIC bytes.
so the name field variables VVRSTGCL, VVRDATCL, VVRMGTCL
are trashed, as is the VVRSBKUP datetimestamp, whose byte
location is now indeterminate with those invalid length
length fields. My old DSECT ends with VVRSBKUP, but this
record has nearly 200 bytes more data, with several new
TODSTAMP fields that should be new event variables, since
type 60s are frequently used to investigate security
issues about who has access, and who accessed, and when
did they access sensitive data on DASD volumes.
Oct 1, 2001 update to this change text:
I held this as the last change for 19.04, expecting IBM
would supply me with the VVR and NVR "DSECTS" so I could
see if something had been changed, and if so, how to
continue decoding the SMF type 60 records without error.
IBM's official reply to Merrill Consultant's request for
the DSECTS for the SMF type 60 record came from the IBM
DFSMS Vendor Activity manager:
"I've discussed this matter with the developer and since
the VVR and NVR contains proprietary information, we
cannot honour you request to acquire the DSECT for the
VVR and NVR records in the VVDS. Instead, please
contact IBM Service and be prepared to FTP the dump and
the SMF records for analysis. No promises are made as
to how we'll choose to resolve this issue."
Stay tuned for future updates to this bigger problem!
Feb 14: IBM DFSMS refuses to provide documentation of
either the Catalog or the VVDS records. One of the
above IBM errors was fixed by OW51353/OW50528 that
reports creation of defective VVR; it's a shame that
IBM would not let me have the documentation so I could
have detected the bad record and told you the APAR that
you need to correct IBM's error, but I've given up.
Thanks to Lawrence Jermyn, Fidelity, USA.
Thanks to Peter Krijer, National Bank of New Zealand, NEW ZEALAND.
Change 19.173 Invalid SMF type 42 subtype 6 (TYPE42DS) record caused
VMAC42 INPUT STATEMENT EXCEEDED error. OFFDSAM segment started
Sep 19, 2001 data byte 32697 but the record length of 32722 data bytes
left only 26 bytes for the 48-byte Access Method segment.
This change now protects for the short record, printing a
message that bad records were found and missing values
were set for the S42AMxxx variables.
Thanks to Linda S. Berkley, USPS, USA.
Change 19.172 Moving your EBDCIC SPIN library from an existing BUILDPDB
SPINSORT to run under ASCII versions of SAS will require a re-SORT
Sep 19, 2001 of the SPIN library after it has been XPORT/IMPORTed to
ASCII, or you will get SPINxxxx NOT SORTED errors.
This member has the PROC SORT and BY statements to resort
all of the SPIN datasets.
Thanks to Robert Battilana, Franklin Mint, USA.
Change 19.171 Misspelled variable CSRENTLE was corrected to CSRENTIN,
VMACRMFV and the dataset labels for ZRBCPU and ZRBENC were revised
Sep 14, 2001 in this almost-cosmetic change.
Thanks to ???, ???, ???
Change 19.170 -Dataset TPFFM variable FMIOTIM, unlike the SXxxxxxx wait
VMACTPF variables, should not have been divided by 4096.
Sep 14, 2001 -All accumulated counters in all TPF datasets are now
protected for wrapping (when they exceed their four byte
field max value) using this logic to correct the wrap:
IF . LT FVDATAn LT 0 THEN FVDATAn=FVDATAn+4294967296;
This change was not originally needed, because the TPF
monitor was only permitted to run for a few hours, so the
counters didn't wrap, but now that TPF SYSPROGs/Managers
are seeing how useful it to measure TPF, they permit the
monitor to run all day, and the counters now do wrap!
-In the TPFFV dataset (VFA Database Activity), variable
SLOTNR was replaced with new variable FVDATBAS that has
the Database Number, 1 if there is only one database,
sequentially more when there are more than one.
Thanks to Robert Wilcox, Sabre, USA.
Thanks to Jim Gilbert, Sabre, USA.
Change 19.169 The IBM field name DCVFRAGI should have been used as the
VMACDCOL variable name, but DCVFRAG1 is what I thought it was, but
Sep 10, 2001 now its too late to change the name without impact, so I
added a comment with the DCVFRAGI name for documentation.
Thanks to Moira Hunter, SchlumbergerSema, ENGLAND.
Change 19.168 Change 19.104 missed some SU_SEC variables that should
VMACTMV2 have been stored in 8 bytes now; variables SU_SEC in the
VMAC97 TMON/MVS data, variable THSU_SEC in TYPE97, and variables
VMAC30 RMSU_SEC and LOSU_SEC in some TYPE30xx are now changed.
Sep 10, 2001
Change 19.167 INVALID ARGUMENT TO FUNCTION INPUT caused messages and a
ASUMCACH hex dump on the log, and missing value in R7451RID that
Sep 9, 2001 are now corrected.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.166 The Soft Audit product's records now contain SYSTEM in
VMACSFTA the field location that previously contained STEPNAME.
Sep 9, 2001 New variable SYSTEM and old variable STEPNAME will now
contain the value of that field.
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 19.165 Revision; if APPEND=YES was specified and DDIN and DDOUT
VMXG2DTE are not the same, the output will reflect only the most
Sep 9, 2001 current day, and an error was generated.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.164 TMS Audit variables TMAUxxxx have been always missing,
TYPETMS5 the TMVAxxxx variables should never have been created,
VMACTMS5 and labels for some TMAUxxxx/TMVAxxxx variables had
Sep 9, 2001 LAST UPDATE when they should have been LAST AUDIT.
This change revises the creation of TMAUxxxx variables,
(which should be used in place of TMVAxxxx variables)
in your report programs (although the TMVAxxxx variables
are correct and still kept in TMS.TMS so reports work).
Note: The TMVAxxxx variables in your old TMS.TMS data
did have correct values with wrong label. TMVATIME,
for example, contains the Last Audit Date, but now you
should use the TMAUTIME variable instead of TMVATIME.
Thanks to Terry Duchow, United States Postal Service, USA.
Change 19.163 Variable JOBCLASS has always been unique, because it had
ADOC30 valid EBCDIC characters (A-Z,0-9) for real TYPETASK='JOB'
VMAC30 records, but non-printable hex characters ('00'x) for SMF
Sep 9, 2001 type 30 records from non-JOBs (TYPETASK=STC/TSU/OMVS...).
Before variable TYPETASK existed, I thought that keeping
those non-printable values might be useful, so JOBCLASS
used the $CHAR informat to preserve the hex value. But,
under ASCII execution, this causes all values of JOBCLASS
to be unprintable; MXG stores a hex 'C1'x in JOBCLASS for
class 'A', but ASCII requires hex '41'x to print an 'A'!
Then, when IBM added the 8-byte class name field SMF30CL8
years ago, MXG input it in JOBCLAS8 with $CHAR8, adding
logic to use it as JOBCLASS only when it was present:
IF JOBCLAS8 GT ' ' THEN JOBCLASS=JOBCLAS8;
But under ASCII, that test was always true when JOBCLAS8
was blank (EBCDIC '40'x), because that GT ' ' test is
IF '40'x GT '20'x , so JOBCLAS8 was always used, even
when the one-byte JOBCLASS had a non-printable hex value!
The fix: SMF30CL8 is now always present, and it does not
contain unprintable characters, so it is now INPUT into
the JOBCLASS variable (not JOBCLAS8), using $EBCDIC as
the Informat, and "IF JOBCLAS8 GT ' ' test was deleted.
What do you do with existing MXG datasets under ASCII?
I thought you could just use the $EBCDIC format in your
PROC PRINT to display the job class value, but that does
not work under either V6 or V8 under Windows:
DATA; X='C1'x; PUT X $EBCDIC1.;
prints a lower case "e" instead of an "A"
However, you can convert the actual data value in the
JOBCLASS variable in your TYPE30_5 or PDB.JOBS dataset
on your ASCII system, using this data step:
DATA JOBS;
SET PDB.JOBS;
JOBCLASS=INPUT(JOBCLASS,$EBCDIC8.);
The description of JOBCLASS in ADOC30 was updated.
Thanks to Paul Gillis, Pacific Systems Management Pty Ltd, AUSTRALIA.
Thanks to Robert Battilana, Franklin Mint, USA.
Change 19.162 JES3-only. Variable NETNAME, The JES3 DJC (Dependent JOB
BUIL3005 Control) Network ID, is now propagated into PDB.JOBS when
Sep 5, 2001 BUILDPD3 is used to create your JES3-PDB.
Thanks to Graham Cornwell, Donovan Data Systems, ENGLAND.
=Cruised from Nome, Alaska, south to St. Lawrence, St. Matthew, St.
=George in the Pribilofs to Chugulak, and thence west across all of the
=Aleutian Islands to Russia's Bering Island, Kamchatka Peninsula's
=Valley of the Geysers (pronounced "geezers" in Russian), and
=Petropavlovsk on the 340-foot Clipper Odyssey, with "birders" from the
=American Birding Association. Landings each morning via Zodiacs to see
=birds at sunrise, often second island landing in afternoon, phenomenal
=weather (while the Alaskan State wine is "When is this fog going to
=lift?", we had sun on every single day!). And evening lectures on the
=geology, flora and flauna! Saw over 100 bird species, including Steller
=Sea Eagles on their nest, 10 mammals (five whale species!), and bones
=of the extinct Steller Sea Cow. Fantastic naturalist experience,
=especially for this EE!
Change 19.161 MXG 19.03 only. Change DEBUG=1; to DEBUG=.; and those
VMACTNG "AFTER HEADERS _N_=" (harmless) notes won't be printed on
Aug 16, 2001 the SAS log.
Change 19.160 Support for type 42 subtypes 7 and 8 was revised; a six
VMAC42 byte filler is now skipped, the OFFCL calculation was
Aug 16, 2001 corrected, and S42FFN and SMF42CHN are now input variable
length, and converted and translated to be printable
under MVS or ASCII platforms.
Thanks to Richard Fortenberry, Mitsubshi Motor Sales of America, USA.
Change 19.159 While TYPEMBO tested just fine, the TYPSMBO member had
TYPEMBO a type _SDEMBO should be _SMBO, and the VMACMBO member's
VMACMBO definitions of _NMBO and _SMBO were obviously incorrect.
Aug 10, 2001
Thanks to David Bixler, FISERV, USA.
Change 19.158 Support for CISCO Works Blue ISM User SMF record creates
EXCISM01 twelve new datasets, one for each subtype:
EXCISM02 Dataset Description
EXCISM03 CISM01 CISCO ISM ROUTER/SWITCH CPU/MEM'
EXCISM04 CISM02 CISCO ISM CMCC(CIP) CPU/MEM'
EXCISM05 CISM03 CISCO ISM OSA CPU/MEM'
EXCISM06 CISM04 CISCO ISM TN3270 STATISTICS'
EXCISM07 CISM05 CISCO ISM INTERFACE PERF STATS'
EXCISM21 CISM06 CISCO ISM INTERFACE STATISTICS'
EXCISM31 CISM07 CISCO ISM PATH STATISTICS'
EXCISM41 CISM21 CISCO ISM REAL SERVER STATS'
EXCISM42 CISM31 CISCO ISM VIRTUAL SERVER STATS'
EXCISM66 CISM41 CISCO ISM FORWARDING AGENT STAT'
IMACCISM CISM42 CISCO ISM WILD CARD STATISTICS'
TYPECISM CISM66 CISCO ISM ISM EVENT LOG'
TYPSCISM This support is preliminary; only subtypes 01,05,06,66
VMACCISM are decoded and tested, and these issues have just been
VMXGINIT observed from the small data sample:
Aug 6, 2001 - The SYSTEM field in the CISCO SMF record is blank.
- There is an extra undocumented file at the end of
the '01' record, that looks like a percentage?
- Additional '06' fields are documented for FDDI, etc
that won't be decoded until they appear in data.
- The documentation shows 8 fields in the '06' record
after the "OE(" marker (UN,OE,CO,IR,RS,OBF,OBS,TR),
but there are only 7 data fields in the '06' record.
Thanks to Harvey Aviles, SSA, USA.
Change 19.157 The PDB.CICS dataset can be created by either ASUMCICS,
JCLPDB8 which always counts from CICSTRAN, or by ASUMCICX, which
JCLPDB6 will use PDB.ASUMUOW if it exists (i.e, if ASUMUOW was
Aug 6, 2001 both included and member IMACUOW updated to create obs in
PDB.ASUMUOW), but what is counted is quite different:
when PDB.CICS is built from CICSTRAN, it counts all CICS
transaction names separately, since each observation in
CICSTRAN is a separate "CICS" transaction, but if ASUMUOW
is built, it has summarized all of the CICS transactions
in one "Unit-of-Work" into one observation, with only the
"Real" transaction name of that UOW, and thus the counts
in PDB.CICS using ASUMCICX are counts of units-of-work,
not CICS transactions, and only the "Real" TRANNAME will
be in the PDB.CICS dataset built from ASUMCICX.
Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.156 -Using %VMXGRMFI(IMACWORK=NO) in your RMFINTRV member and
EXRMFINT defining fewer than the default workloads can cause many
VMXGRMFI notes NOTE: VARIABLE OTHnACTV IS UNITIALIZED one set for
Aug 6, 2001 each workload you didn't use, and all of those UNINIT
variables listed are actually created in PDB.RMFINTRV.
The problem was caused by the default LABEL statement in
EXRMFINT, which was there to support the earlier design
in which you defined the workloads in IMACWORK and their
labels in EXRMFINT. With the revised VMXGINIT design,
the labels in EXRMFINT are not needed in my default code,
and are now commented out, as an example if you are still
using IMACWORK=YES and want to change labels.
-MXG 19.03 only. Change 19.105 causes errors if %VMXGRMFI
arguments end with slash before the comma (mis-matched
DO;-END; pair). This change makes the final slash
optional.
Thanks to Nancy R. Brizuela, University of Wyoming, USA.
Change 19.155 Dataset CTLGVSAM, created by reading an exported Catalog,
VMACCTLG had unique variables missing because macros were spelled
Aug 6, 2001 wrong. Folowing _WCTLGVS /* CTLGVSAM */, the statement
after the label should have been _VCTLGVS _KCTLGVS to
match the CTLGVS (was mistyped as _VCTLGDS _KCTLGDS).
Thanks to Barry McQueen, Department of Defense, AUSTRALIA.
Change 19.154 IHDRxxxx exit members exist for each "INFILE" that MXG
IMACFILE reads from, and are taken after the record header or
IHDR110 sub-header, has been INPUT. They exist so that you can
IHDR110S use ID, SUBTYPE, SYSTEM, APPLID, SMFTIME, etc., in these
IHDRCIMS exits to control whether or not MXG creates observations,
IHDRDCOL primarily for ad hoc runs when you want to output just a
IHDREAGL little bit of the input. For example, IHDR110S for CICS
IHDRNTSM Statistics Segments lets you select by STID value to only
IHDRTMDB output to specific a CICxxxxx statistics dataset, and not
IHDRTMO2 waste temporary disk space with unwanted statistics.
IHDRTMV2 These IHDRxxxx members are not new, but this change adds
IHDRTPF a macro variable to each, so that you can alternatively
IHDRVMXA tailor these headers "instream", using this syntax:
IHDRTMDC %LET MACxxxx= %QUOTE( your code );
IHDRIMS instead of having to EDIT/SAVE of the IHDRxxxx member.
IHDRTIMS The IHDR members and their new MACxxxx macro variables:
Aug 2, 2001
IHDRxxxx Macro
Member Name Data Source
IMACFILE MACFILE SMF Record Header, ID, SUBTYPE, etc.
IHDR110 MAC110H CICS 110 Sub-Header, APPLID, etc.
IHDR110S MAC110S CICS 110 Statistics Sub-Sub, STID.
IHDRCIMS MACCIMH IMF/CIMS Record Header
IHDRDCOL MACDCOH DCOLLECT Record Header
IHDREAGL MACEAGH Eagle Header
IHDRNTSM MACNTSH NTSMF Record Header
IHDRTMDB MACTMDH TMON/DB2 Record Header
IHDRTMO2 MACTMOH TMON/CICS Record Header
IHDRTMV2 MACTMVH TMON/MVS Record Header
IHDRTPF MACTPFH TPF Record Header
IHDRVMXA MACVMXH VM/ESA, z/VM Record Header
IHDRTMDC MACTMCH TMON/DBCTL Record Header
IHDRIMS MACIMSH IMS Log Record Header
IHDRTIMS MACTIMH TMON/IMS Record Header
The MACFILE macro has existed for some time; IMACFILE was
the original name for the SMF File Header, but now all
new INFILE exit member names start with IHDR.
Thanks to MP Welch, SPRINT, USA.
Change 19.153 -NTSMF Process object record with NRDATA=27 is supported.
VMACNTSM -Records from Win2000 Servers with older NTSMF versions
Aug 1, 2001 for Indexing Service, Indexing Service Filters, and Site
Aug 3, 2001 Server Authentication Srevice had an unexpected instance
field, which is now expected, but not kept, as there is
no instance field with the current NTSMF version.
Thanks to Jim Quigley, ConEd, USA.
Change 19.152 Variable NCL, Net Capacity Load, the back-end space used
VMACICE is now created in ICEBRGSY and ICEBRGUT dataset (but the
Jul 31, 2001 ICEBRGUT records are generated only if you run a REPORT
SPACEUTILIZATION, daily, and have turned on subtype 7 in
SVAA or IXFP in SYS1.PARMLIB(SMFPARM), so using ICEBRGSY
which is always present is recommended).
Thanks to Rob Gibson, Centrelink, AUSTRALIA.
======Changes thru 19.151 were in MXG 19.03 dated Jul 30, 2001======
Change 19.151 If you use TEMP01/TEMP02/TEMP03 in a VMXGSUM invocation,
VGETENG a non-impacting Warning 413 may result, if those DDs were
VMXGSUM on tape devices that had not been opened. Our open to
Jul 27, 2001 determine the device type of your (optional) TEMPnn DD
Jul 30, 2001 caused the warning when the tape had not been opened.
Those TEMPxx parms were primarily needed before SAS V8
provided good multi-volume support, and are less needed
now, but as sequential format datasets on disk, they can
be striped and hardware compressed, and for VMXGSUM runs
with large volumes of data, they are still very useful.
This change eliminates the 413 warning by first looking
to see if the TEMPnn libname is already open, in which
case we will use its current engine, and if the TEMPnn DD
is not open, we will force the Sequential Engine for you,
and avoid the open that caused the warning. The TEMPnn
options are not used in any MXG VMXGSUM invocations.
Jul 30: Added GLOBAL to VMXGSUM and VIEW MXGENG.
Thanks to Mike Hoey, Ameren, USA.
Change 19.150 Example of TREND summarization for the ASUMCEC dataset,
TRNDCEC similar to TRND70PR trending of ASUM70PR for LPAR/MDF,
Jul 26, 2001 but TRENDCEC is a the hardware CEC/CPC level.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 19.149 First 19.03 only. TNG support still had incorrect values
VMACTNG for STARTIME for some PLATFORMS, now corrected on all.
Jul 26, 2001
======Changes thru 19.148 were in MXG 19.03 dated Jul 26, 2001======
Change 19.148 Support for NTSMF V 2.4.2.11 and Windows 2000 changes to
VMACNTSM the SYSTEM and PROCESS objects, including new variables
Jul 26, 2001 for I/O activity at the process level:
Jul 27, 2001 IORDOPRT='IO READ OPERATIONS/SEC'
IOWROPRT='IO WRITE OPERATIONS/SEC'
IODTOPRT='IO DATA OPERATIONS/SEC'
IOOTOPRT='IO OTHER OPERATIONS/SEC'
IORDBYRT='IO READ BYTES/SEC'
IOWRBYRT='IO WRITE BYTES/SEC'
IODABYRT='IO DATA BYTES/SEC'
IOOTBYRT='IO OTHER BYTES/SEC'
READYTHR='READY*THREADS'
Revisions to PROCESS and UNTDISC made Jul 27, 2001.
Thanks to Jim Quigley, ConEd, USA.
Change 19.147 Invalid type 42 subtype 5 record caused INPUT STATEMENT
VMAC42 EXCEEDED RECORD LENGTH and/or DIVISION BY ZERO. This
Jul 26, 2001 record was overlaid after 20,500 bytes, with a dataset
name appearing where there should be no data set name!
Segments thru VOLSER DX0004 (starting at byte 20249) were
valid, but the segment for VOLSER DX0003 (at byte 20409)
contains offsets of S42VTVDO=7 and S42VTVXO=1, when those
offsets must be greater than the current column, or zero,
and subsequent fields are clearly invalid. A heuristic
circumvention based on those observed values will detect
and delete these bad records, while the site contacts IBM
for a correction to their invalid SMF 42-5 record created
by DFSMS 2.1
Thanks to M.J.H. Elbersen, RABOBANK, NL.
Change 19.146 -TNG records with (*) in their object name, such as the NT
FORMATS object "NWLINK IPS(*)(G)" saw the (*) and set TEXT='*'
VMACTNG instead of the expected TEXT='G', causing LENTEXT to be
Jul 25, 2001 missing instead of 16, and deleting that record with an
Jul 27, 2001 MXG note. Now, the scan knows to skip (*) when looking
for the (X) length field.
-Existing Format MGALFA only decoded single base-36 values
for TNG field lengths (1)=1, (A)=10, (Z)=35, but now two
position base-36 characters, (12)=38 are supported when
that value was found for an object length. Values to
(1Z)=71 are now decoded by MGALFA:
-The related tests LENTEXT LE 36 were revised to LE 35,
and a separate test for 36 LE LENTEXT LE 40 was added
due to (10)=36 taking one more position than (Z)=35.
-The revised MGALFA format should not have been used in
pre-9907 logic; the old format that stopped at (Z) did
not have values for (11), etc, so an old (12) was seen
as length 12, but the revised format now has (12)=38,
so even though nobody probably still is using the old
TNG format, I fixed it so my QA run with old and new
data still works.
-STARTIME was correct for the first group of records, but
it grew well into the future because it was not reset to
ORIGTIME at the start of each object's counter's input.
-STARTIME was still wrong in the first day's MXG 19.03,
but was corrected in VMACTNG internally dated Jul 27.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 19.145 Support for the Volume sections of type 42 subtype 11 XRC
EXTY42XV (Extended Remote Copy Session statistics) now create new
IMAC42 dataset TYPE42XV to track the read/write/update activity
VMAC42 at the VOLSER level. In addition, all duplicates were
VMXGINIT not being removed in TYPE42S2, but adding SMF42FBG (Cache
Jul 20, 2001 Structure Name) to MACRO _BTY42S2 removed all duplicates.
However, multiple observations from the same subtype 6
SMF record exist in TYPE42DS that were also not removed
by the NODUP sort. These multiples have different I/O
counts, but otherwise are identical, except that their
location in the record (S42JDDSO) is different, so it was
added to MACRO _BTY42DS to remove the duplicates if dupe
SMF records are read, but the two otherwise observations
from the same record will now have different S42JDDSO
values. If you discover why there are these multiples,
let me know and I'll update this text.
OBSERVATION COUNT CHANGE: TYPE42DS fewer obs.
Thanks to Mike Delaney, Pershing, USA.
Change 19.144 RMF Partition data report was updated to report on the
ANALRMFR communication devices. To get full comm reports using the
Jul 20, 2001 DEVICEC=40 parameter for commmunications, add 41 to get
the CTC adapters included.
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 19.143 Candle did NOT correct the unsupported '20'x (instead of
VMACNAF the expected '01'x) value for the century "bit" in their
Jul 21, 2001 internal time stamps; they ONLY corrected the date part
in the SMF header field. The circumventions of Changes
18.025 and 15.211 were replaced with directly forcing the
century bit into their fields and then using an INPUT
function to convert the modified character field. This
circumvention may fail at the end of this century.
Thanks to Joe Faska, Depository Trust, USA.
Change 19.142 MXG 19.02 only. The SPIN logic did not keep SPINCNT, so
VMXGUOW the SPINUOW dataset continued to grow, as there are many
Jul 20, 2001 CICS transactions whose end we don't see until the region
is terminated, and the SPIN logic depends on SPINCNT to
recognize and output those type of events into ASUMUOW.
This error was not caught in our testing because of an
incorrect IMACUOW member in our tailoring library. Sorry!
This change won't be seen until the second day's run.
Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.141 The new type 74 subtype 7 FICON Director record has a new
VMAC74 option in ERBRMFxx of FCD/NOFCD that causes creation of
Jul 18, 2001 that subtype.
Change 19.140 The SASGRAPH argument was not UPCASE'd, causing test to
ANALCNCR fail if you typed your SASGRAPH=yes in lower case.
Jul 18, 2001
Thanks to Ian Davies, Independent Consultant, CANADA.
=Attended the superb SAS 25th Anniversary Party in Raleigh, NC, with
=7,200 SAS employees and families, with two bands popular in 1976:
= The Village People and KC and the Sunshine Band!
Change 19.139 An SMF 116 with invalid QWHS segment length of 108 bytes
VMAC116 (110 is expected) caused INPUT EXCEEDED STOPOVER error.
Jul 13, 2001 The QWHS segment it self was trashed, with invalid data
values for CAID, CCV, CCN, and XTYP, and the 22-byte
accounting segment was only 20 bytes. This change only
detects the short segment and prints an error message on
the SAS log. This note will be updated if an APAR is
found/developed to correct the IBM error in the record.
Thanks to Mat Elbersen, RABOBANK, THE NETHERLANDS.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.138 Local variables ENTEJECT caused a warning because it did
GRAFTAPE not exist, and was not referenced in sample reports, so
Jul 13, 2001 it was removed from the member.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.137 IMF Program record's variable FLGUESQL was incorrectly
VMACCIMS input @79 when that field is located @80. It and a few
Jul 13, 2001 other flag variables were also formatted $HEX2.
Thanks to Sergio Fastella, ALITALIA, ITALY.
Change 19.136 -TPF datetimestamp variables are written in GMT zone, but
VMACTPF MXG now converts them all to your local time of day, by
VMXGTPFI using the DB/DE records, which are written first in each
Jul 11, 2001 file, containing the GMT datetime and a local time and
Jul 12, 2001 local date (but its '01JUL' with no year, so conversion
from GMT to local has special logic to deal with JAN01
and DEC31 data to set the local year correctly!
-Variable SHIFT is now created in all datasets that have
STARTIME, that is, all interval datasets. Your IMACSHFT
definitions are used with STARTIME to set the shift of
each observation.
Change 19.135 MXG 19.01 and 19.02, IMS Log processing. Change 19.061
ASMIMSL5 was incorrect, causing invalid time stamp values. The
ASMIMSL6 asterisk in column one that was added by that change:
Jul 11, 2001 * BO DROPMAP NONRECOV Change 19.061
is removed by this change so the statement now reads:
BO DROPMAP NONRECOV Change 19.135
Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.
Change 19.134 Documentation only. When I/O delay is NOT included in
VMAC7072 velocity in your WLM, MXG's calculated VELOCIOD variable
Jul 9, 2001 estimates what the velocity would be if I/O delays, in
R723CIOD/PCTDLIOD, and WLM-managed batch initiator delay,
in R723CTDQ/PCTDLTDQ, were both included. Both impacts
are in the one VELOCIOD variable, because I didn't think
more velocity estimate variables were needed for the now
several possible combinations, and because you could
always use the EXTY72GO exit to recalculate your own
estimate if really needed.
My VELOCIOD won't match either of RMF report's values in
I/O PRTY or INIT MGMT; IBM calculations assume only the
one impact, and also say that if R723VELI is not on, that
both I/O useage and I/O delay are not included!
When I/O delay and/or Init delay are enabled in your WLM,
i.e., when R723VELI='Y', there is no discrepancy, because
VELOCITY and VELOCIOD are equal and correct.
Thanks to Steve Dyck, CDS, USA.
Change 19.133 Some JCL Examples for Assembly and LinkEdit of programs
DOC written in IBM ASM still had PGM=IEV90 and PGM=IEWL for
Jul 3, 2001 the Assembler and Link Editor, but Carl, an ASM Guru at
SAS, pointed out that the more likely names in use in
this millennium would be PGM=ASMA90 and PGM=HEWL.
Thanks to Carl Meredith, SAS Institute, USA.
Change 19.132 Support for both VM/ESA V2.4 and z/VM V3.1. The V2.4
VMACVMXA changes were added first, then the 3.1 LIST1403 was used
Jun 30, 2001 to update those changes, which are listed separately in
this change text.
Some of the new numeric variables may be accumulated and
will need to be DIF'd, so you should verify their values
before using!
These new variables were added in the Jun 30 change:
Dataset New Variables
SYTSYP: PLSDGUCT PLSXITCT
SYTPRP: PFXSPINT PFXSPINC
SYTRSG: TCMMIDSZ TCMMAIN TCMMNMIN TCMMNMAX TCMMNDL TCMSTLMN
SYSSCMAV
SYTSCG: SRMTOTST SRMWSSDL SRMWSSD1 SRMWSSD2 SRMWSSD3 SRMLLCNT
SRMCONLL SRMATOD SRMATOD2 SRMWTCPU CALSLKCT CALSLKTM
SYTUWT: CALLLIST
SYTXSG: TCMXIDSZ TCMXSMIN TCMSTLXS TCMAVGAG HCPSTPXB
MTRSYS: CALADMF VRFSG SYSTEM SYSCKVOL SYSWMVOL
MTRPRP: PFXTYPE CALUDED
MTRDEV: CALTHROT RDCRCUC RDCOBRCO RDEVSER THRDLYS THRIORTE
MTRUSR: VMDBYVAL VMDMXSHR
MTRSCH: SRMXPCTG
STOSHR: ASCCTXBK
USEACT: IUCTOTCN IUCMXCN VMDMXSHA VMDLIMTH VMDTHRCT
USEINT: HFLLIST HFPGACT VMDSLCNT
PRCPRP: CALUDED PFXTYPE HFUSERM
IODDEV: THRDLYS SCMCQTIM
IODCAD: CALSSS2
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.131 Validation of SOL260S TNG data found several minor errors
VMACTNG that have been corrected and MXG's values now matches the
Jun 29, 2001 Excel spreadsheet created by TNG.
Thanks to Bill Shanks, SEMA, ENGLAND.
Thanks to Paul Hargreaves, SEMA, ENGLAND,
Change 19.130 IBM has redefined type 103 variable TIMEWRIT as the time
VMAC103 since the last SMF write, now called SMFRecordingInterval
Jun 29, 2001 in IBM documentation, so it's label was clarified.
Thanks to Dave Cogar, Computer Associates, USA.
Change 19.129 Using UTILBLDP with BUILDPDB=NO option printed warning:
UTILBLDP APPARENT SYMBOLIC REFERENCD IDFLAG NOT RESOLVED
Jun 29, 2001 because IDFLAG was not initialized in that loop. Insert
%LET IDFLAG=NO;
after the existing %LET DE2FLAG=NO; in that loop.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.128 Running MXG under unix hit another lower case problem:
VMXGINIT ERROR: File does not exist /mxg/sourclib/AAAAAAAA.SAS
Jun 28, 2001 Under unix SAS, %INCLUDE SOURCLIB(MEMBER) looks for file
INSTALL "member.sas", while INFILE SOURCLIB(MEMBER) looks for
Feb 4, 2003 "member.dat", both in lower case only, so all MXG source
files must be lower cased on unix. It turns out that
when the MEMBER name has no extension, unix SAS looks
only for lower case file name, but if ANY extension name
is used (MEMBER.EXT), SAS instead looks for a file name
in the case of the source code, and the MXG statement
that was added that caused the error is in upper case:
INFILE SOURCLIB(AAAAAAAA.SAS)
One earlier fix (actually, one still discussed in INSTALL
member's instructions until Feb, 2003!) was to uppercase
the source file to AAAAAAAA.SAS, because that is the only
file in MXG that is read with an INFILE syntax. Or, you
could have lowercased the VMXGINIT member, or I might be
able to modify the MXG install process for unix to UPCASE
that one file.
But instead, the %LOWCASE macro function was inserted in
the INFILE statement for ASCII (i.e. unix/linux/WINDOWS):
INFILE SOURCLIB(%LOWCASE(AAAAAAAA.SAS))
which will cause unix to look for aaaaaaaa.sas, and you
don't have to change anything to run MXG under unix.
This also works under Windows because file names there
are not case sensitive.
Note: Don't try this under EBCDIC systems; using MVS
syntax of INFILE SOURCLIB(%LOWCASE(AAAAAAAA));
fails with a JFCB error, because MVS still can't
handle lower case DDnames.
Feb 4, 2004: The INSTALL member was revised, telling
you to leave the aaaaaaaa.sas filename in lower case.
Thanks to Chris Weston, SAS ITSV Development, USA.
Thanks to Mark Rothschild, Caremark, USA.
Change 19.127 An obscure exposure in VMXGSUM is corrected; if you had
VMXGSUM both INTERVAL= and NORMn= arguments, some variables could
Jun 28, 2001 be missing in the output dataset. None of the MXG uses
of VMXGSUM had both, but the ASUMCACH enhancement added
the INTERVAL= to an existing NORM1= argument, uncovering
the error. Correction was to relocate a code segment.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.126 DFHSM 1.4 via PTF and standard in DFHSM 1.5 and later,
VMXGHSM two new variables for stacked volumes (field sequence
Jun 28, 2001 number DGNFLSEQ, file block ID DGNFBID) were added to the
DGN dataset. A reserved area was used for the two new
fields, so the IBM change is COMPATIBLE.
Thanks to Wanda Prather, Johns Hopkins Applied Physics Lab, USA
Change 19.125 Support for TPF releases PUT08, PUT10, and PUT12, which
VMACTPF inserted data fields incompatibly in several records.
VMXGTPFI The major changes were internal, to add the many new
Jun 27, 2001 variables for the 9th thru 16th Instruction Streams into
Jun 29, 2001 TPFSX dataset, and two new variables in dataset TPFDX.
Jul 10, 2001 Variable SXTWCSPR was dropped from TPFSX dataset and the
VMXGTPFI was revised to not reference that variable.
Internal mapping formats for TPFDR & TPFDH now use CPUID
so that TPF data from multiple systems can be processed
by concatenation of the input files. New variable SYSTEM
is created in dataset TPFINTRV; you must update the table
in your member IMACTPF to map which CPUIDs are in which
system to populate variable SYSTEM. There still is one
observation per CPUID per interval in TPFINTRV dataset,
but if you update that table, variable SYSTEM will exist
so that you can use it in subsequent summarization.
Jul 10: Added ZDATE to TPFINTRV.
Obs with FFCCHHR='00'X are now OUTPUT in TPFFF;
they are Virtual File Access and should not have
been deleted.
Several misspellings of 9-G variables corrected.
Thanks to Robert Wilcox, Sabre, USA.
Thanks to Jim Gilbert, Sabre, USA.
Change 19.124 -Adding the processing of SOLVE SMF to BUILDPDB caused
VMACLDMS WARNING: VARIABLE YYYY HAS ALREADY BEEN DEFINED AS NUM...
VMACMDF Change temporary variable YYYY to YYYYCH in two places to
VMACSOLV eliminate the conflict and the warning message.
Jun 28, 2001 -Changed CONDCODE to CONDCODH in VMACLDMS, to avoid a
conflict, and because it is the Highest CondCode value.
-Changed temp variable DOMFLAGn to DOMDFLGn in VMACMDF.
-This change was precipiated by the VMACSOLV error, but
the MXG QA stream should have caught this conflict of
variable types, because ANALCOMP is now run to compile
simultaneously all SMF-reading MXG programs to find any
such conflicts. Why were all three not caught then? In
fact, this error was caught by the April 5 QA run, but it
took this error to remind me to use that enhancement to
make these corrections!
Thanks to John Temme, Department of Defence, AUSTRALIA.
Change 19.123 Enhancement to ASUMCACH, for DASD Cache and DASD I/O.
ASUMCACH Variables that identify the control unit are added using
Jun 28, 2001 a PROC FORMAT as a table lookup. Summarization is now
forced to QTRHOUR level (so that if there are multiple
systems where the TYPE74 and TYPE74CA dataset times are
not exactly aligned, we will now always put the data
together. And additional variables are created to allow
better downstream reporting capabilities. The SORT order
of the output is now SYSPLEX STARTIME DEVNR VOLSER, so
you can examine the data by SYSPLEX.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.122 Documentation of an example use of the EXPDBSPN exit.
EXPDBSPN The site had used IEFACTRT exit to put account info for
Jun 26, 2001 STCs in type 30_4 and 30_5 SMF records in PGMRNAME, but
BUILDPDB keeps PGMRNAME only from TYPE26 and TYPE30_1,
and their exit was after the type 30-1 was created.
Adding variable PGMRNAME to the Keep list for 30_5 did
now work, because the MXG MERGE statement has TYPE30_5
first, and then TYPE30_1 (as required by BUILD005 logic),
causing the blank value in TYPE30_1 for these STCs to
overwrite the non-blank PGMRNAME in TYPE30_5. For this
site's specific SMF modifications, the solution was to
use the EXPDBSPN exit, which is taken just before the
"Big Merge" (see member DOCPDB for more details than you
probably want to read), and in their exit code, add the
PGMRNAME from their TYPE30_5 dataset into the TYPE30_1
dataset, and then the "Big Merge" logic works just fine.
This example is the code they inserted into EXPDBSPN:
DATA TEMP30_5 (KEEP=READTIME JOB JESNR PGMRNAME);
SET TYPE30_5;
DATA TYPE30_1;
MERGE TYPE30_1 (IN=IN1) TEMP30_5 (IN=IN5);
BY READTIME JOB JESNR;
IF IN1 THEN OUTPUT;
and they also had to insert:
%LET ADD30U5=PGMRNAME;
before their %INCLUDE SOURCLIB(BUILDPDB); statement, to
add the variable PGMRNAME to be kept in TYPE30_5 inside
the BUILDPDB logic.
Thanks to Duncan Walker, Experian Limited, ENGLAND.
Change 19.121 The macros did not UPCASE the DDNAME, so it returned an
VGETENG incorrect value if you used lower case DDNAME in the MXG
VGETOBS macro invocation.
VMXGENG
Jun 26, 2001
Change 19.120 IBM APAR OW49536 documents new bit which is now variable
VMAC7072 LCPUVARY='Y' in dataset TYPE70PR if this LPAR was varied
Jun 26, 2001 online during this interval.
Change 19.119 New VMXGSUM option OUTVIEW=YES (default is OUTVIEW=NO)
VMXGSUM will cause VMXGSUM's output dataset to be a VIEW instead
Jun 25, 2001 of a dataset. We will use this internally so MXG will
be faster & cheaper when we can pass the output from one
VMXGSUM execution into another data step (or VMXGSUM!).
Note that if you use OUTVIEW=NO, the View will have the
same name as the OUTDATA= that you specified, but, since
it is a VIEW, that dataset will NOT exist when VMXGSUM
finishes, and if you do not reference the VIEW after it
is created, it will not physically exist as a dataset.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.118 Test for &SASVER EQ 6 was changed to &SASVER GE 6, but
ANALDB2R luckily, running under Version 8 produced the correct
Jun 25, 2001 reports. The test will bypass a data step when under SAS
V6+ (by using the INHERIT option), but executing the data
step under V8 still worked correctly.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.117 IMS Log processing with TYPEIMS7 (resources, no response)
TYPEIMS7 warning messages *** LCODE 35X NOT OUTPUT for ENQFLG=0C
VMACIMS and FLAG2=40x or 60x are now output to IMS35O dataset.
Jun 23, 2001 The warnings had no impact on the IMS0708 dataset that is
create by the TYPEIMS7 program, since only 07 and 08 log
records are used in IMS0708.
In addition, the MXG logic to set NMSGPROC=1 for 08-only
matches caused the total NMSGPROC in IMS0708 to be more
that the true NMSGPROC in the 07 reocrds, so NMSGPROC=0
is now set for the 08-only matches in TYPEIMS7.
And IMSQBLDN is now a positive number; it was initialized
to -34, but that RETAIN statement was corrected.
Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.
Change 19.116 New %MACROS allow you to read many PDB libraries for one
VGETDDS MXG dataset (SET WEEK1.JOBS WEEK2.JOBS WEEK3.JOBS), and
VMXGSET only those DDnames that are found will be used! You can
VMXGINIT control, by the DDNAMES (or LIBNAMES) in your JCL, which
Jun 22, 2001 PDB libraries will be read, but you do have to change the
SET statement in your SAS program! Two %MACROS are used:
-%VGETDDS - "Get" ddnames:
%VGETDDS(DDNAMES=WEEK: PDB: ALLWEEK);
You tell VGETDDS the DDnamePrefixes and specific DDnames
that you want to use. That example will find all DDnames
starting with WEEKn, PDBn, and the DDnames MON TUE WED
THU FRI SAT SUN that are SAS data libraries, and only
those DDnames will then be read by the second macro.
-%VMXGSET - Use in place of your SET statement:
DATA COMBINE.JOBS;
%VMXGSET(DATASET=JOBS,DEFER=YES);
RUN;
You tell VMXGSET what MXG dataset (aka table) you want to
read, and if any of your datasets are on tape media, you
can specify DEFER=YES (SAS V8+ only) and the OPEN=DEFER
option will be on the SET statement that we construct,
causing each individual dataset in the SET statement to
be opened, read, and closed, left to right, so you use
UNIT=AFF in your JCL, and need only one tape drive to
read all of your datasets!
The only caution with DEFER=YES is that it cannot be
used if there is a BY statement with %VMXGSET, because
a BY statement opens all datasets in a SET statement.
So to read five PDB libraries, PDB1-PDB5, you would have
// EXEC MXGSASV9
//PDB1 DD DSN=YOUR.PDB(0),DISP=SHR
//PDB2 DD DSN=YOUR.PDB(-1),DISP=SHR
//PDB3 DD DSN=YOUR.PDB(-2),DISP=SHR
//PDB4 DD DSN=YOUR.PDB(-3),DISP=SHR
//PDB5 DD DSN=YOUR.PDB(-4),DISP=SHR
//COMBINE DD DSN=YOUR.OUTPUT.PDB,DISP=(,CATLG)....
//SYSIN DD *
%VGETDDS(DDNAMES=PDB:);
DATA COMBINE.JOBS;
%VMXGSET(DATASET=JOBS);
... rest of your subsetting logic ...
More details.
You would execute %VGETDDS(DDNAMES=....); once to build
the DDnames, and then execute a DATA step that executes
%VMXGSET(DATASET=....) for each data set to be read.
(While not likely, you can also execute %VGETDDS multiple
times).
Special values exist for %VGETDDS's DDNAMES= argument:
CCCCCCCC - 1-8 char, specific DDname (all characters)
CCCCCCnn - 1-7 char, final 1-2 numeric - scan CCCCCC1,
CCCCCC2 .. until an CCCCCCn+1 is not found
use CCCCCC1 to CCCCCCn DDnames
ALLWEEK - SUN MON TUE WED THU FRI SAT DDnames
Note: If there is more than one tape dataset, and you
use OPEN=DEFER and UNIT=AFF so that only one tape
drive is needed, there will be two mounts of each
tape dataset's first volume: one to recognize it
is a PDB, and, because UNIT=AFF will dismount the
first to recognize the second, there will be the
re-mount of the first dataset when the read
begins. Of course if your tapes are in a VTS,
there is no actual second physical mount, but you
will see both of the mounts on the SYSLOG.
Currently, an arbitrary limit of 99 DDs can be used in
the ultimate SET statement that results.
Even though references are mostly to MVS DDnames, the
new macros work also work on ASCII SAS platforms.
-VMXGINIT was updated to GLOBAL the VGETDDS name.
-HOWEVER: PRIOR TO 2005, there was a serious problem
in that some LIBNAMEs could have been missed by VGETDSN,
but only if the Data Library were controlled by HSM, and
only if you were missing an IBM Patch. That should not
now be a problem, but you can read the full details in
the text of (old) MXG Change 23.244. (Updated 2009).
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Rick Langston, SAS Institute, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA
Change 19.115 You can disregard these confusing SAS NOTES:
None NOTE: DATA STEP VIEW SAVED ON FILE WORK.MXGSUM1.
Jun 21, 2001 THE ORIGINAL SOURCE STATEMENTS CANNOT BE RETRIEVED FROM
A STORED DATA STEP VIEW NOR WILL A STORED DATA STEP VIEW
RUN UNDER A DIFFERENT RELEASE OF THE SAS SYSTEM OR UNDER
A DIFFERENT OPERATING SYSTEM.
PLEASE BE SURE TO SAVE THE SOURCE STATEMENTS FOR THIS
DATA STEP VIEW.
These notes are because MXG now uses VIEWs where possible
to eliminate I/Os, but the "source" is already in your
MXG Source library, so there is nothing to save or do.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 19.114 RMF type 74 subtype 5 (Cache Subsystem) "broken" records
VMAC74 cause the same "INPUT STATEMENT EXCEEDED" error that was
Jun 21, 2001 seen with subtype 4. See the extensive discussion in the
text of Change 17.398. IBM RMF Development has agreed to
create only 'self-contained' records (and they may well
have done so, as this particular RMF record was written
by SP5.1), but this change replaced the statement:
IF SMF745XN GT 0 THEN DO;
with this replacement statement:
IF NDVCNT LE SMF745XN THEN DO;
so that MXG will only look for Extension sections when
they exist in the first "broken" record.
In this instance, the first record had 254 Device Data
Sections, but only 11 Device Data Extension Sections
(i.e., for the first 11 devices). A second SMF record
contains the remaining 243 Extension Sections, but there
is no Device Section with which to match them, so they
are never input. This change prevents MXG from INPUTing
a non-existent extension section, but that will cause
all of these variables to have missing values in TYPE74CA
when a broken record is processed:
R745XDVN /*DEVICE*NUMBER*- SAME AS DEVN */
RSV /*R745XRSV*LOWER*IO*MILLISEC*/
DCTC /*XCTC*DEV CACHE TRKS CONFIGED*/
DCTR /*XCTR*DEV CACHE TRKS REMOVED */
DVRD /*XVRD*DEV READS*BY CU*/
DVRH /*XVRH*DEV READ HITS*BY CU*/
DVWR /*XVWR*DEV WRITES*BY CU*/
DVWH /*XVWH*DEV WRITE HITS*BY CU*/
TSRR /*XSRR*TRKS*STAGED*FOR RAID RE*/
SFRD /*XFRD*TRKS*READ*FROM SIDEFILE*/
CWCC /*XWCC*CONCUR*COPY*CONTAM*WRIT*/
PPRC /*XPRC*PPRC*WRITE*COUNT*/
The MXG change now also protects the LN/RN/1N/VN INPUTs
in case those segments are in a second record.
Thanks to MXG/ITSV Technician, Promise Co. LTD, JAPAN.
Change 19.113 Several examples were revised; some caused errors and the
NEWUSER others were updated to be clearer.
Jun 20, 2001
Thanks to Lary Nova, COMSI, USA.
Change 19.112 PDB.CICINTRV dataset can contain negative minimum values
VMXGCICI or missing values, when there are no INT (Interval) CICS
Jun 20, 2001 statistics records, i.e., when there are only 'EOD' data.
First, if there are no 'INT' records, and you request the
default INTERVAL=HALF-HOUR for PDB.CICINTRV, you will get
unexpected results - I can't create intervals where there
are not, so you must request INTERVAL=EOD in CICINTRV.
But even if you specified INTERVAL=EOD, there was still
an error in the logic in VMXGCICI, because in each of the
processing code for these datasets ('suffixes'):
DL1 DL3 DBU PGG IRC DMR FEP FEC FET JCR LDR LS1 LS3
SDR SMD SMT TC1 TDR XMC USG XMG XMR
a statement IF FIRST.APPLID THEN DELETE; existed that
could cause those datasets to be not included in the
PDB.CICINTRV (so their variables would be missing).
This change removed that code from VMXGCICI.
Additional internal documentation note:
These yyy's did not have the DELETE statement:
TC TSR DMG VT AUT LDG DTB TCR DQR DQG TSQ
DS ST FCR M TDG SDG SMS AUS CO1 CO3 CON,
These yyy's are not currently used in VMXGCICI:
CSF6/7/8/9, D2G,D2R,LGR,LSG,NCS4,NCS4,NQG,
SOR,XQS1/2/3.
Thanks to Sally Weber, Washington Mutual, USA.
Change 19.111 Support for DFSMS/RMM data in MXG is confusing, because
VMACEDGR IBM has similar data in different formats that can be
VMACEDGS written to SMF or dumped with IBM's EDGHSKP utility in
Jun 20, 2001 two different formats. This is documentation only.
1. MXG's "EDGSxxxx" processing:
RMM can create two SMF records with different SMF IDs,
so MXG has two separate macros to define the SMF record
numbers your installation told rmm to use:
_IDEDGSU for the "Security" record, one subtype,
populates dataset EDGSSECU if found,
_IDEDGSA for the "Audit" record, many "subtypes":
EDGATYPE='C' populates EDGSAREC, only from
SMF records, but the "Audit" record also has
all of the rmm control records subtypes with
EDGATYPE=D/K/O/P/E/F/U/R/S that populate the
EDGSVREC,DREC,KREC,OREC,PREC,RREC,SREC,OVOL
EDGSPVOL datasets.
MXG's members TYPEEDGS and TYPSEDGS will read the infile
"SMF" and create all of the EDGSxxxx datasets.
But the IBM utility EDGSKIP can create a Control Backup
flat file from the rmm Control file (EDGSKIP with BACKUP
option), and that flat file is in almost-SMF-format that
contains the same Audit subtypes, so the same EDGSxxxx
datasets can be crated from either SMF records or the
Control Backup file. Because of slightly different input
format, two different members are needed in MXG, but they
both create all of the EDGS datasets, which will be
populated with observations when those subtypes are read
TYPEEDGS - Reads Infile "SMF" to create "EDGS" datasets
TYPEEDGB - Reads Infile "LOGSMF" from Backup option to
create "EDGS" datasets.
2. MXG's "EDGRxxxx" processing:
But you can also run EDGHSKP to Extract instead of Backup
(EDGSKKIP with RPTEXT), and that creates a flat file that
is physically different in record layout, but it contains
almost all of the same record subtypes. Unfortunately, I
did not recognize the similarities, so MXG dataset names
are EDGRxxxx, and different variable names are used:
TYPEEDGR - Reads Infile "EDGHSKP" from Extract option to
create "EDGR" datasets.
This table should identify which MXG datasets are similar
from these multiple possibilities:
Type "EDGS" process "EDGR" process
- EDGSSECU SMF - Security does not exist
C EDGSAREC SMF - Activity does not exist
D EDGSDREC Data Set EDGRDEXT
K EDGSKREC Vital EDGRKEXT
O EDGSOREC Owner EDGROEXT
O EDGSOVOL ", per volume does not exist
P EDGSPREC Sftw Product EDGRPEXT
P EDGSPVOL ", per volume does not exist
E/F/U EDGSRREC LIB Shelf Location EDGRREXT
R/S EDGSSREC Storage Loc Shelf EDGRSEXT
V EDGSVREC Volume EDGRVEXT
Thanks to Dale Haug, Philip Morris, USA.
Change 19.110 New CICSTRAN variables BARSPACT and BATIAECT were wrongly
VMAC110 spelled BARACTCT and BADFTECT, but are now corrected to
Jun 19, 2001 agree with the IBM field names.
Thanks to Gary L. Keers, Indiana Power & Light, USA.
Change 19.109 ACCOUNTn variables in TYPE33 APPC SMF records are blank
VMAC33 if the TP profiles specify TAILOR_ACCOUNT(YES) and the
Jun 19, 2001 RACF WORKATR account code is not populated. Specifying
TAILOR_ACCOUNT(NO) corrected that problem, but caused MXG
to set READTIME to a missing value because these lines:
JOB=RACFUSER;
READTIME=REQDTIME;
were executed when MXG found both a TP usage section and
an accounting section in the type 33 SMF record, i.e.,
only when TAILOR_ACCOUNT(NO) is specified. When YES is
specified, there is no accounting section in the SMF
record. Those lines were inserted only to suppress a SAS
"UNINITIALIZED VARIABLE" note, back when there was no JOB
name nor READTIME in the type 33 record, so that the MXG
IMACACCT member could be used to decode the ACCOUNTs, but
as both JOB and READTIME are now input in the VMAC33
member, that protection is unneeded, and its unintended
consequence, this error, is eliminated by deleting them.
Thanks to Walter Medenbach, IBM Global Services, AUSTRALIA.
Change 19.108 MXG output only one observation per SMF 108 subtype 2/6
VMAC108 record, because multiple sections were not expected, but
Jun 13, 2001 as they are now known to exist, many observations that
Jul 9, 2001 were not output are now created:
Subtype 2: 513 records, 10487 observations (now)
Subtype 6: 527 records, 71592 observations (now)
Additionally, variables DOMRVN and DOMPVN are now kept in
each subtype dataset (to identify version changes).
Jul 9: SM180UDO re-spelled as SM108UDO.
OBSERVATION COUNT CHANGE: TYPE1082 more obs.
OBSERVATION COUNT CHANGE: TYPE1086 more obs.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
Change 19.107 New exit member EXTPFINT for the TPFINTRV dataset is now
EXTPFINT added, so that new variables can be created in TPFINTRV.
VMXGTPFI See comments in the exit member.
Jun 12, 2001
Thanks to Jim Gilbert, Sabre, USA.
Change 19.106 Archaic VMACIMS member had incorrect IMSRECNO because the
VMACIMS statement LOCRECNO=LEN-3; was missing for three IMS 5.1
Jun 11, 2001 code segments for the 35x log record (which is not used
by the TYPEIMS7 program, which is now the only user of
the VMACIMS member, and it doesn't use the 35x records).
Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.
Change 19.105 -SU_SEC variable is now kept in 8 bytes, because the new
UTILRMFI larger values can loose some low decimal digits in 4.
VMAC7072 For example, a Z-series 5-way has SU_SEC=10540.1845, but
VMXGRMFI that was truncated in 4 bytes to only SU_SEC=10540.1818,
Jun 11, 2001 so the magnitude of the truncation is small, only .0027.
Jun 21, 2001 -The original implementation of VMXGRMFI/UTILRMFI for WLM
required blanks between the parameters of the WORKnn=
operands of VMXGRMFI, causing confusion and errors. Both
members were revised to now tolerate blanks, but they are
no longer required. The / character still is required as
a delimiter to positionally identify the operand.
-Use of both KEEPxxx and DROPxxx VMXGRMFI arguments is not
supported; now you will get a USER ABEND 1913 if you try.
Thanks to Larry Nova, TransAmerica Commercial Finance, USA.
Change 19.104 -TYPE72GO variables VELOCITY/VELOCIOD/VELOCCPU were
VMAC7072 propagated into subsequent periods in the same SMF record
VMXGRMFI if there was no activity in those subsequent periods.
Jun 11, 2001 Now, all are set to missing if they cannot be calculated.
-Temporary dataset WORK.RMF72DS (built in VMXGRMFI) is now
deleted, as it should have been, for housecleaning.
-Comment references to NORM70=YES were removed, as that
normalization is now automatically performed for all the
variables in R70NRM list. NORM70 was never needed.
Thanks to Shantha Peetham-Baran, Cap Gemini Ernst & Young, ENGLAND.
Change 19.103A The default DDname of "PDB" in BUILDPDB can be changed by
VMXGINIT re-invocation of the %VMXGINIT macro in your //SYSIN.
Jun 11, 2001 If you want to write directly to the "MON","TUE",etc.,
'day-of-week' dataset and not have a "PDB" ddname, you
can use a DATA step to create the name of "Day-of-Week"
in a macro variable &DAY, and then use that macro as the
default value instead of "PDB":
DATA _NULL_;
DAY=UPCASE(PUT((TODAY()-1),WEEKDATE3.)); /*variable*/
CALL SYMPUT('DAY',DAY); /*macro variable*/
RUN; /*force evaluate*/
%VMXGINIT(DEFAULT=&DAY); /*invoke*/
%INCLUDE SOURCLIB(BUILDPDB.....);
The change made in member VMXGINIT was cosmetic; a flag
for first-time is now used to change the text of the note
printed on the SAS log to "RE-INITIALIZED" (and the new
DEFAULT value is printed) when VMXGINIT is re-executed.
Thanks to Derek Twist, CSC, AUSTRALIA.
Change 19.103 Support for StorageTek VSM NCS 4.0 ("HSC") enhancements
FORMATS for subtypes 13, 14, 18, and 19 add new variables, but
VMACSTC the record changes are INCOMPATIBLE (STCnnTIM is now 4
Jun 11, 2001 bytes, vice 8, in different format), so this MXG change
is required for that version's SMF records. New things:
Dataset Variables Description FORMAT
STCVSM13 STC13RCI RECALL INDICATOR $MGSTCRC.
'01X:MOUNTED WITHOUT A RECALL'
'02X:MOUNTED AFTER A RECALL'
STC13MGT MANAGEMENT CLASS
STCVSM14 STC14MGT MANAGEMENT CLASS
STCVSM18 STC18MT MIGRATE REQUEST TYPE $MGSTCMT.
'01X:AUTO'
'02X:DRAIN'
'03X:DEMAND'
'04X:RECLAIM'
'05X:CONSOLIDATE'
'06X:EXPORT'
STC18MGT MANAGEMENT CLASS
STC18SCL STORAGE CLASS
STCVSM19 STC19RT RECALL REQUEST TYPE $MGSTCRT.
'01X:AUTO'
'02X:DRAIN'
'03X:DEMAND'
'04X:RECLAIM'
'05X:CONSOLIDATE'
'06X:EXPORT'
STC19MGT MANAGEMENT CLASS
STC19SCL STORAGE CLASS
Thanks to Martin Jensen, JyskeBank, DENMARK.
Change 19.102 Variable CPCMODEL ('ZX7' or 'Z77' for example) is added
ASUM70PR to PDB.ASUM70PR and PDB.ASUMCEC datasets to identify what
Jun 10, 2001 is the exact model of the platform. This is important if
a Z-series machine is an 'upgrade' from a G6, as the CPU
Serial Number does not change, even though the physical
hardware does.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.101 Variable PGMRNAME was removed from the KEEP= list for the
BUILD005 TYPE30_4 dataset in the BUILDPDB logic. If a job had no
BUIL3005 Purge record, the always-blank-PGMRNAME-in-TYPE30_4 would
Jun 10, 2001 blank out the PGMRNAME from the TYPE30_1 dataset.
See Change 19.194.
Thanks to Duncan Walker, Experian, ENGLAND.
Change 19.099 Syntax for Goal Mode no longer requires the -99 place
VMXGRMFI holder.
Jun 9, 2001
Thanks to Larry Nova, COMSI, USA.
======Changes thru 19.099 were in MXG 19.02 dated Jun 1, 2001======
Change 19.098 First MXG 19.02 only. Two lines were left from testing:
VMXGRMFI Lines 2398 and 2417: IF SYSTEM='SYSA' THEN
Jun 1, 2001 must be deleted. This error caused PDB.RMFINTRV to have
many missing variables, including NRCPUS and PARTNCPU.
======Changes thru 19.097 were in MXG 19.02 dated May 27, 2001======
Change 19.097 Labels for two variables were confusing and are revised:
VMAC94 SMF94VBR='BYTES*READ*THRU HOST*CHANNEL*FROM VOL'
May 25, 2001 SMF94VBW='BYTES*WRITTEN*THRU HOST*CHANNEL*TO VOL'
Thanks to Simon Everitt, NPI Financial Services, ENGLAND.
Change 19.096 Variables SMF94IN4 and SMF94EX4 were not multiplied by a
VMAC94 1024*1024, but now are (as were IN3 and EX3) to convert a
May 24, 2001 raw megabyte value back into bytes, so the MGBYTES format
will correctly display these bytes-completed variables.
Thanks to David Bixler, Fiserv, USA.
Change 19.095 EMC's InfoMover SMF records INFSTART and INFTIME are now
VMACINMV INPUT as &PIB.4.2; their bad values reported back in MXG
May 24, 2001 Change 17.396 are now corrected to the normal SMF time
format, replacing the MXG circumvention that had &RB4.
and a divide by 150.
Thanks to Bob Bradley, United Airlines, USA.
Change 19.094 Documentation. Variable DB2SRBTM is missing in DB2ACCT,
VMACDB2 beginning with DB2 Version 6.1, and as documented by IBM
May 23, 2001 and as noted in member ADOCDB2. This note added so that
searching changess for DB2SRBTM will expose itself.
But as a result, if you have any reporting code that uses
DB2CPU=DB2TCBTM+DB2SRBTM;
because the SAS assignment statement A=B+C will have A
missing if B or C are missing. Instead, you must replace
the assignment statement with a SUM() statement:
DB2CPU=SUM(DB2TCBTM,DB2SRBTM);
or, you could remove +DB2SRBTM from your equation.
Change 19.093 Support for Release 5.06 (INCOMPATIBLE, in TYPE1082 data
VMAC108 set, because DOMUNAME was expanded from 32 to 36 bytes).
May 23, 2001 And new field DOMPRPID, Process ID, is added to TYPE108
datasets.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
Change 19.092 The PDB.ASUMUOW dataset is enhanced to now keep variable
VMXGUOW USERCHAR (the real transaction name of some transactions
May 23, 2001 can be stored in the USERCHAR field). The first non-blank
May 25, 2001 (character) or non-missing (numeric) value is output. All
CICS "ID" variables are now listed in new MACRO _KUOWIDC
so you can override and add additional "ID" variables.
The current list of "ID" variables from CICSTRAN is:
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
To add another variable, say CLIPADDR, you would code:
%LET MACKEEP=
%QUOTE(
MACRO _KUOWIDC
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
CLIPADDR %
);
New macros _KUOWIDD and _KUOWIDDM for DB2 and MQ are now
defined as null, but can be used in future tailoring.
Option LISTALL=YES on the VMXGUOW invocation can be used
to identify which HOLDxxxx, FRSTxxxx, or LASTxxxx
variable is being used to retain/sum the values for which
real variables in the data step that builds ASUMUOW.
If you really want to create observations in PDB.ASUMUOW
you can use this instream logic before your include:
%LET MACKEEP=
%QUOTE(
MACRO _NOOBS % MACRO _YESOBS %
);
%INCLUDE SOURCLIB(ASUMUOW);
Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.091 An incorrect statement in format $MGFDROP was not caught
FORMATS by SAS, and caused no error, but should have. The text
May 23, 2001 '00'X'='00'X:OTHER (FDRABRM)' was corrected to now read
'00'X='00'X:OTHER (FDRABRM)'
Thanks to Joe Faska, Depository Trust, USA.
Change 19.090 Documentation. Comments had the wrong IBM field name for
VMAC74 two variables. Corrected field name in comments are:
May 21, 2001 @45+OFFSMF LENDDSS &PIB.2. /*SMF74DDL*/
@47+OFFSMF NRDDSS &PIB.2. /*SMF74DDN*/
Thanks to Michael Spencer, BMC Software, USA.
Change 19.089 SAS V8.2 "WARNING: OPTION BLKSIZE(2311) SET INTERNALLY
CONFIGV8 IS NOT SUPPORTED IN THIS VERSION" has no impact; SAS data
May 21, 2001 libraries are still created with half-track blocksize and
SAS Institute will eventually eliminate the spurious
message; a SAS Usage Note will be created later. The SAS
defect was precipitated by a BLKSIZE(DASD)=HALF statement
in MXG's CONFIGV8 member, and to circumvent the SAS error
and eliminate the warning, I have replaced the statement
BLKSIZE(DASD)=HALF
with
BLKSIZE(3390)=27648
BLKSIZE(3380)=23040
so as to still set the desired half track block size for
new SAS data libraries on DASD.
You could make the WARNING go away by removing that
BLKSIZE(DASD)=HALF statement from CONFIGV8, but without
those device-specific half-track values being set in your
CONFIGV8 member, you will instead get the SAS System
default value of 6144 that is set their SAS.CNTL(CONFIG)
member in your //CONFIG DD concatenation.
SAS Institute still sets their default block size for
new MVS SAS data libraries to 6144, because, for some
SAS datasets that have INDEXes, the half-track block
size may be sub-optimal, but specifically for MXG, and
in general for any data-intensive SAS application that
writes large volumes of SAS data that are sequentially
accessed and do NOT use SAS Indexes, a small 6144 byte
block size will waste massive amounts of CPU time, I/O
I/O time, cause unneeded EXCPs, SIOs, and waste real
memory! And your DASD datasets at 6144 byte blocksize
will also waste DASD space! You want your MXG-built
SAS datasets to be built with half-track blocksize on
DASD!
Thanks to John R. Myers, Vanguard, USA.
Thanks to Tricia Henry, John Fairfax Holdings, AUSTRALIA.
and now others, but they reported it first!
Change 19.088 Variable INITTIME in both TYPETMNT and TYPETALO were off
VMACTMNT by one full day starting March 1, 2001, because the MXG
May 15, 2001 logic using YEARSEC did not protect for this year's leap
day, and because ASMTAPES does not get the century bit on
when it copies these IBM fields. The logic using YEARSEC
was revised to force the century bit for INITTIME.
Thanks to Joan Nielsen, i-structure, USA
Thanks to Mike Shapland, i-structure, USA.
Change 19.087 This contributed example sums up all of the CPU time for
ANALUSS a job using Unix System Services (USS) under MVS's OMVS
May 15, 2001 (OpenEdition), as described by its author:
Jobs that call Unix System Services (USS) can have their
Unix work spawned to independant address spaces that are
started tasks. OMVS creates the jobnames for these
address spaces by appending a 1-digit numeric suffix to
the jobname of the original job. (Job ABCD will spawn
STC OMVS address spaces named ABCD1, ABCD2, etc). Eight
character jobnames will spawn A/S's named the same as the
job (e.g., ABCD5678 will spawn ABCD5678). There will
likely be more than one OMVS ASID per job, so the CPU for
the USS work of a job will be in multiple type 30 records
with different job names, numbers, and initiate times.
This program matches up those job records and sums up the
CPU time for the job. (The starting and ending time of
the USS tasks will be within the start/end time of the
originating job.)
The program makes these assumptions:
1. An 8-digit USS jobname could be spawned by either a
7 or 8 digit job. The code assumes the 8-digit USS
job is spawned by an 8-digit job unless it's found
to come from a 7-digit job.
2. We assume the job started yesterday. This code
could be removed or changed.
Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.086 JCL example still referenced &&SOURCLIB, but that temp
ANALDSET dataset is no longer created nor used in the revised JCL
May 15, 2001 to analyze dataset activity from 14/15/64 and SMF 30s.
Thanks to Freddie Arie, TXU, USA.
Change 19.085 TLMS date variables BAPURCH BACLNDT BACERTDT with invalid
VMACTLMS julian day-value of zero (Packed field '0100000C'x in the
May 15, 2001 record) caused INVALID ARGUMENT FOR DATEJUL FUNCTION.
Jul 6, 2001 This change tests the day value of those three fields and
sets the date missing if the day value is zero.
Also, the value of BACTIME was not correctly converted to
a time value but now is and is formatted as TIME8.
Jul 6: Variable BALUNIT was changed to BAIUNIT to match
the TLMS dsect name.
Thanks to Dietmar Lakemann, Rechenzentrum Verden GmbH, GERMANY.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.084 MXG output observations in TYPE73 for channels that were
VMAC73 offline (but with all zeros, the extra observations had
May 15, 2001 no real impact), but they are no longer output. The old
MXG logic had bit tests to protect for MVS/ESA 4.3 that
can now be removed, and the test to output TYPE73 now is:
IF ONLINE='Y' AND VALIDPTH='Y' THEN DO;
Also, variable SMF73BSY was added to the KEEP list, in
case it is needed for later re-calculation.
I was writing this update for ADOC73 to better document
that there are two, different, kinds of observations in
TYPE73, when I found the need for this change.
TYPE73 Contains Different types of Observations, based on
the value of SMF73CMG, the CPMF Group:
SMF73CMG = . or 0 ==> old record, without extension
PCHANBY calculated from SMF73BSY/NRSTCPS
PNCHANBY calculated from SMF73PBY/SMF73PTI
SMF73CMG = 1 ==> CPMF=COMPAT
When present, variables SMF73TUT/SMF73PUT, the new
durations when Total Channel Path, LPAR Channel Path
was busy are INPUT (i.e., will be non-missing).
PCHANBY re-calculated from SMF73TUT/SMF73PTI
PNCHANBY re-calculated from SMF73PUT/SMF73PTI
"Normal" TYPE73 record for ESCON channels, CTC's, etc.
FICON channels are reported upon, but only to the same
level of detail as other channel types.
SMF73CMG = 2 ==> CPMF=EXTENDED
This "new" extended subtype is currently written for
OSD and FICON channels (SMF73CPD=11x:OSA DIRECT
EXPRESS, SMF73CPD=1Cx:FICON BRIDGE). It adds
read/write/total byte counts for total/lpar from which
MXG creates four read/write rates in bytes/second:
SMF73TRU=SMF73TRU*SMF73US/SMF73PTI;
SMF73PRU=SMF73PRU*SMF73US/SMF73PTI;
SMF73TWU=SMF73TWU*SMF73US/SMF73PTI;
SMF73PWU=SMF73PWU*SMF73US/SMF73PTI;
and re-calculates PCHANBY and PNCHANBY:
PCHANBY=100*SMF73TUC/(SMF73MCU*SMF73PTI);
PNCHANBY=100*SMF73PUC/(SMF73MCU*SMF73PTI);
and calculates the new "Bus Busy Percent" in PBUSBY
(which is non-missing only in these SMF73CMG=2 obs).
PBUSBY=100*SMF73TBC/(SMF73MBC*SMF73PTI);
Whether type 73 (and type 79-12) records contain CMG 1 or
2 data is determined by the CPMF parameter of IEAOPTxx
member of PARMLIB. CPMF=COMPAT produces MG1 format data
records and CPMF=EXTENDED produces the MG2 format record.
Note that all TYPE73 observations have variables PCHANBY
and PNCHANBY calculated for Total/LPAR percent channel
busy measurements, so if you need seconds of busy time
you can calculate as BUSYTM= PCHANBY*DURATM/100;
OBSERVATION COUNT CHANGE: TYPE73 fewer obs.
Thanks to David M. Kellerman, ADP, USA.
Change 19.083 MXG's creation of SMF70WLA and MSU4HRAV/MSUINTRV values
VMXGRMFI in PDB.RMFINTRV is wrong if you now have the new z/OS
May 14, 2001 records that have SMF70WLA populated by IBM. I thought
May 16, 2001 SMF70WLA would contain the "this-system" MSU capacity in
May 26, 2001 the type 70 record, so in records without that field, I
created SMF70WLA in PDB.RMFINTRV, and for a 1-way system
I set SMF70WLA=36 (the correct MSU capacity available to
that LPAR with one engine), but now I find that IBM puts
SMF70WLA=253 in their record, which is the "all-engine"
or total "image" MSU capacity of the CPC, the hardware
MSU capacity of the box. Spinning was also corrected.
*** NOTE: IBM NOW STORES THE LPAR CAPACITY VALUE, 36,
AND NOT THE CPC MSU VALUE, 253. THIS WAS
APPARENTLY AN EARLY TEST SITE?
SEE CHANGE 20.168.
Since MXG generally never changes the value of IBM fields
in IBM records (although sometimes "Sums" are converted
into "Averages", and labelled accordingly):
- corrects the MXG value of SMF70WLA in PDB.RMFINTRV
to contain the IBM value and the label now reads
SMF70WLA='DEFINED*CAPACITY*IN MSU*AVAILABLE*TO CPC'
- and creates new variable ZOS70WLA in PDB.RMFINTRV
ZOS70WLA='DEFINED*CAPACITY*IN MSU*AVAILABLE*TO MVS'
to contain the value that you really want, the MSU
capacity of this MVS System, so you can compare this
MVS System's MSU usage (MSU4HRAV/MSUINTRV) with its
MSU capacity (ZOS70WLA). Both SMF70WLA and ZOS70WLA
variables are kept in the PDB.RMFINTRV dataset
So now: NOTE: after Change 20.168:
SMF70WLA is the Defined Capacity of the LPAR
ZOS70WLA is the same as SMF70WLA
MSU4HRAV is MXG's 4-hour average hourly MSU
MSUINTRV is the MSU count for this RMF interval.
SMF70LAC is IBM's 4-hour average hourly MSU
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.082 Support for HMF Subtypes 29, 30, and 31 create threee new
DIFFHMF MXG datasets:
EXTYHMFT Subtype "dddddd" DATASET Description
EXTYHMFU 29 TYHMFT TYPEHMFT CNT2 COMPRESSION ENTRY
EXTYHMFV 30 TYHMFU TYPEHMFU CNT2 IFENTRY
IMACHMFU 31 TYHMFV TYPEHMFV CNT2 SYSGROUP/CNTSYS
VMACHMF Datasets TYPEHMFT and TYPEHMFU have accumulated counters
VMXGINIT so their sort macros _STYHMFT and _STYHMFU were added to
May 14, 2001 the DIFFHMF member.
Thanks to Perry Lim, Union Bank of California, USA.
Thanks to Theo Peelen, Rabobank, THE NETHERLANDS.
Change 19.081 Support for DB2 SMF 102 IFCID 096 was mis-aligned. Field
VMAC102 QW0096WF should have been &PIB.4. instead of 2, and a two
May 10, 2001 byte reserved field was not input after QW0096RC.
Thanks to John Mourtgos, Albertsons, USA.
Change 19.080 NPM processing with TYPS28 invoked only _S028IN7 macro to
TYPS28 sort the NPMINPMT dataset; instead, it should invoke the
May 10, 2001 _S28 macro so that all NPM datasets are sorted to the PDB
DD name.
Thanks to Sue Kemper, Universal City Studios, USA.
Change 19.079 JCL with comments to run ASUMUOW using batch pipes or
JCLUOWP pipes plex. SAS Institute has enhanced their product at
May 9, 2001 our request so that it interfaces with IBM's BatchPipes
product; this example shows how to use SAS and pipes to
significantly reduce run time and physical I/Os. The SAS
support for BatchPipes will be available in SAS Version 9
but if there is enough demand to Technical Support at SAS
for support, a "hot fix" for SAS 8.2 could be possible.
There are 3 jobs and they must all run concurrently.
-READDB2 reads the DB2 SMF data, and, using a view,
passes DB2ACCT to a SORT which outputs into the PIPE for
DB2ACCT and uses a pipe fitting to harden the DB2ACCT
dataset.
-READCICS reads the CICSTRAN data and again, using a
view, passes the data the SORT which then outputs into
the PIPE for CICSTRAN and hardens the CICSTRAN dataset.
-ASUMUOW uses the PIPEs from READDB2 and READCICS to read
the DB2ACCT and CICSTRAN datasets and create ASUMUOW.
Note the SPININ and SPIN DD usage in ASUMUOW allows the
SPIN dataset to be a GDG for ease of recovery.
The hardening via a pipe fitting is certainly optional
but does not materially affect the run, time. In theory,
when the sort of CICSTRAN ends, so does ASUMUOW.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.078 Truncated type 14 record caused INPUT STATEMENT EXCEEDED
VMAC1415 error because MXG did not validate the real length with
May 9, 2001 the length fields in the record. This rare bad record is
now detected and deleted with an MXG message but the rest
of the SMF file will now be read.
Thanks to Howard Unich
Change 19.077 IBM made changes to the SMF 120 record (Websphere CB) and
VMAC120 now with actual records, the MXG design was revised, as
May 9, 2001 only five datasets are now created:
May 11, 2001 TYP120CC - Container and Class information, from either
Subtype 2 (Container Activity) or Subtype 4
(Container Interval). Variable SM120STY can
be used to identify which event created the
observation; the interval records will also
have DURATM,SM120SST,SM120SET non-missing.
TYP120CM - Class and Method information, from either
Subtype 2 (Container Activity) or Subtype 4
(Container Interval). Variable SM120STY can
be used to identify which event created the
observation; the interval records will also
have DURATM,SM120SST,SM120SET non-missing.
TYP120SA - Server Activity from subtype 1
TYP120SC - Communications Session from subtype 1
TYP120SI - Server Interval from subtype 3
Thanks to Martyn Jones, ABN AMRO, THE NETHERLANDS.
Change 19.076 The STRTTIME/ENDTIME values in CICSTRAN segments could be
VMAC110 later than the SMFTIME of the physical record; the MXG
May 8, 2001 conversion from STCK(GMT) to LOCAL did not include the
Leap Seconds. The revised equation is now:
STRTTIME=STRTTIME+MCTMNTAD-MCTMNLSO;
Thanks to Ralph Alcorn, Safeway, USA.
Change 19.075 TSO/MON variables were input but not kept in TSOMCALL.
VMACTSOM These variables are now labeled and kept:
May 7, 2001 TSMPEMCT TSMPEMTM TSMPRTYP TSMPSDCT TSMPSEQN TSMPSWCT
TSMPTRAN TSMPURR
Variable TSMPURR=00x observations do not have counts in
the LONG, TRIV, or NONTRIV transaction counts; those
counts exist only if the '01'x bit is on in TSMPURR.
Thanks to Gerry Girard, Canadian Utilities, USA.
Change 19.074 KEEPALL=YES is now specified in the VMXGSUM invocation in
ASUMCICS these ASUMxxxx members that are all included in JCLPDBx
ASUMDB2A examples. Using KEEPALL=YES bypasses the execution of
ASUMDB2B many DATA steps by VMXGSUM, saving CPU time in these ASUM
ASUMJOBS members. (The prior KEEPALL=NO default caused steps to
ASUMTMNT be executed to build a KEEP= list that was used only for
May 7, 2001 the INPUT dataset to prevent variable not found errors in
subsequent PROC MEANS executions.)
-In ASUMJOBS, IF JSTRTIME=. was changed to IF INITTIME=.
to eliminate jobs that did not initiate more robustly.
Change 19.073 Support for DCOLLECT APAR OW48529 which documents the
FORMATS value of 3 for DSCAVAIL as "Continuous Preferred" so the
Apr 18, 2001 MGDCODV format was updated to decode that value.
Thanks to Jim Petersen, HomeSide Lending, USA.
Change 19.072 USERADD=HSM, resulting in _IDHSM, but in VMACHSM the IF
UTILBLDP statement is looking for _IDHSMDS.
May 2, 2001 Also, COMPLETE has five macro names, now generated.
Thanks to Wayne Bell, National General Insurance Co., USA.
Change 19.071 To allow for the override of _IDTMNT with IMACTMNT
ASMFTAPE Line 53 ( MACRO _IDTMNT 238 % ) must move before the
Apr 26, 2001 %INCLUDE(VMACSMF,VMAC21,VMACTMNT);
Thanks to Normand Poitras, IBM Global Services, USA.
Change 19.070 The _BTY78SP BY list for TYPE78SP was not complete enough
VMAC78 to remove duplicate records, so it was revised to be:
WEEKBLD MACRO_BTY78SP SYSPLEX SYSTEM STARTIME READTIME JOB
MONTHBLx SUBPOOL %
APR 26, 2001 with the addition of SUBPOOL. Since TYPE78SP is optional
job-level subpool monitoring, this exposure is minimal,
but since TYPE78SP is a part of the BUILDPDB process, the
BY lists for it in the WEEKBLDx and MONTBLx also had to
be updated.
Thanks to Iven Willy, Fortis Bank, ENGLAND
Change 19.069 The BY-list MACRO _BFDRDSF had DSNAME instead of FDRDSN
VMACFDR as the name of the variable, causing DSNAME NOT FOUND.
TESSUSR1 Added TYPSFDR to test stream for _S, _B macros.
Apr 26, 2001
Thanks to David Ehresman, University of Louisville.
Change 19.068 Format $MG073CD for type 73 records was updated to
FORMATS include 23X Internal Coupling Peer.
Apr 12, 2001
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 19.067 Preliminary support for BMC Mainview Batch Optimizer, BMO
TYPEMBO that will replace HiperCache product. BMO records quite
Apr 6, 2001 different; code works but at Alpha test site now.
Thanks to Jim Petersen, HomeSide Lending, USA.
Change 19.066 GOPTIONS statement was mis-located; it should be located
GRAFRMFI after the %SYSPROD(GRAPH) statement. Only impact was if
Apr 6, 2001 you did not have SAS/GRAPH on your system.
Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.065 NTSMF Object NETWORK INTERFACE is now NETWORKINTERFACE
VMACNTSM and PAGING FILE is now PAGINGFILE, both without the old
Apr 6, 2001 blank, requiring the test for object name to
now look for either spelling.
Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 19.064 Cosmetic, to avoid confusion. In this example JCL for a
JCLTREND TRENDing, the DISP=OLD on //CICSTRAN and //WEEK is not
Apr 6, 2001 needed, as both are input-only in that job, and so they
were changed to DISP=SHR.
Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.063 SAS Version 8.2 Spurious NOTE "might be uninitialized".
VMXGWORL Fortunately, there is no impact, other than the printing
Apr 6, 2001 of several new NOTES on the SAS log, and SAS Technical
Apr 9, 2001 Support now acknowledges the note should not have been
Jun 11, 2001 printed and SAS be revised to recognize that NOBS will be
initialized by the NOBS=NOBS parameter.
The MXG change was to initialize the NOBS variable before
the CALL to prevent the compiler notes.
Read on, only if details interest you.
Some of the new NOTES include these:
546: LINE AND COLUMN CANNOT BE DETERMINED
NOTE: NOSPOOL IS ON. RERUNNING WITH OPTION SPOOL MAY
ALLOW RECOVERY OF THE LINE AND COLUMN WHERE THE ERROR
HAS OCCURRED.
NOTE: 546-185: THE VARIABLE NOBS MAY BE UNINITIALIZED.
Enabling the SPOOL option did print the source statement,
which was inside the VMXGWORL macro, which MXG uses to
figure out if observations are in "WorL", i.e., in the
"_W" OR the "_L" dataset macro. That code:
DATA;
CALL SYMPUT('MXGOBS',NOBS);
____
546
STOP;
SET CONTENTS NOBS=NOBS;
is code originally recommended by SAS as a safe way to
set macro variable &MXGOBS non-zero if there are obs in
dataset "CONTENTS", to set it zero if there are 0 obs,
or to not-fail if there is no "CONTENTS" dataset.
The NOBS variable in our SYMPUT is uninitialized when the
CALL SYMPUT is seen, but SET CONTENTS NOBS=NOBS populates
variable NOBS, so MXG's logic works just fine.
If we moved the CALL to be after the SET, NOBS would
have been populated, but that logic won't work here:
If the CALL is after the SET, the CALL statement
won't be executed when there are zero observations
in CONTENTS or when CONTENTS dataset doesn't exist.
SAS added this new "may be" note to correct a problem
where it an uninitialized variable was not identified,
but that fix unintentionally fired spuriously here, and
SAS will correct the compiler to recognize the NOBS=NOBS
will populate the CALL statement, even when the CALL is
seen before the SET statement.
To eliminate the printing to these notes SAS V8.2, MXG
simply added a compiler faker statement:
IF NOBS=. THEN NOBS=.;
before each of the two CALL SYMPUTs in member VMXGWORL
to satisfy the compiler's need for NOBS to appear in an
assignment statement; this will work now and when SAS has
fixed the spurious NOTE.
11Jun01: The extraneous %PUT statement was deleted:
%PUT BARRY DEBUG &MXGLYES= &MXGWORL= &MXGOBS=;
Change 19.062 MXG 19.01 only. Change 19.059 introduced an error when
VMACSOLV temporary variable MONTH was changed to numeric. Now, it
Apr 5, 2001 is reverted back to character but renamed MONTHSL.
Change 19.061 IMS 01 records with the recovery bit on were deleted,
ASMIMSL5 causing differences in observation counts in IMSSUMSO,
ASMIMSL6 IMSMERGE, and NODTOKEN. The Branch statement (at line
Apr 5, 2001 1444 in ASMIMSL6, line 1415 in ASMIMSL5), following the
TM MSGFLAGS,MSGFNRQU statement, was commented out to
prevent the incorrect deletion of valid 01 records.
NOTE: JUL 11: This change was in error and was undone by
Change 19.135.
======Changes thru 19.060 were in MXG 19.01 dated Apr 4, 2001======
Change 19.060 Variable BLKSIZE in the optional TYPE30_D => PDB.DDSTATS
VMACEXC1 dataset is wrong in OS/390 R2.10 and z/OS; I input the
Apr 4, 2001 new 8-byte SMF30XBS as floating point with RB8, causing
values of -1E64 or +1E18, as the input should have been
binary &PIB.8. However, IBM uses the first bit as a flag
that the block size was changed, and then I re-discovered
that SAS cannot store all digits of a field input as PIB8
when the first bit is turned on:
X = '8000000000006D10'X; /*hex literal */
Y = INPUT (X,&PIB.8.); /*input as binary*/
Z = MOD(Y,8000000000000000X); /*get the 6d10 */
returns z= 28762 under PC SAS,
z= 27904 under OS/390 SAS,
but z= 27920 is the correct value for '6D10'x.
so the actual INPUT was revised to use &PIB.7.
Fortunately, BLKSIZE/MULTSIZE variables are rarely used.
Thanks to Rob Gibson, CentreLink, AUSTRALIA.
Change 19.059 Compiling of all MXG members that process SMF records has
VMACF127 uncovered a few conflicts where variables are defined as
VMACLDMS numeric in one record and character in another record.
VMACMOUN Renaming the variable in the more-seldom-used product
VMACDECS eliminate the possible exposure.
VMACRMDS VMACF127 - Not-kept DEVNUM renamed.
VMACROSC VMACLDMS - JESNR is now a numeric variable.
VMACSOLV VMACMOUN - Variable UCBTYPE is now a numeric variable.
VMACAIMR VMACDECS - Variable DSORG now DSORGDEC.
VMACLMS VMACRMDS - Not-kept RECSEQNO renamed.
VMAC102 VMACROSC - Not-kept DELETE renamed.
VMACHBUF VMACSOLV - Not-kept YYYY now numeric.
VMAC90 VMACAIMR - Not-kept YY1-SS1 and YY2-SS2 now YY-SS.
VMAC90A VMACORAC - Not-kept Reserved variables renamed.
Apr 4, 2001 VMACLMS - Not-kept DSTYPE renamed to DSTEMPTY.
VMAC102 - Not-kept VALUE renamed VALUE4BY.
VMACHBUF - RECTYPE renamed RECTYPEC.
VMAC90 - Not-kept DOMFLAG renamed.
VMAC90A - DOMFLG renamed DOMFLG90.
Change 19.058 If you changed the PDB2ACC default from PDB to DB2ACCT,
JCLTEST6 the JCL TEST programs failed, because MXG had failed to
JCLTEST8 provide a //DB2ACCT DD statement in some steps.
Apr 4, 2001
Thanks to Jesse Gonzales, Gap Inc, USA.
======Changes thru 19.057 were in MXG 19.01 dated Apr 3, 2001======
Change 19.057 The NTCONFIG dataset only recorded model/speed/etc for
VMACNTSM the first four CPUs; now CPUNUM,CPUSPED,FAMILY,MANUFAC
Mar 31, 2001 variables exist for 32 processors.
Thanks to Bob Gauthier, Albersons, Inc, USA.
Change 19.056 Protection for invalid ALOCTIME in type 30 records, while
VMAC30 IBM investigates the cause. Step records with ALOCTIME
Mar 31, 2001 that is a fraction of a second earlier than the INITTIME
are not possible (steps initiate first, then allocate,
and then load), but are written by OS/390 R2.10. The
MXG logic must compare those times to determine the step
ALOCDATE and LOADDATE (because ALOC/LOAD have only times
with no dates in type 30s), and it concluded "INIT Today,
ALOC Tomorrow" when the ALOC Time was earlier than INIT.
The IBM error of the earlier ALOC time causes MXG to add
one day to the ALOCTIME variable, which then caused the
DSENQTM to be 23:59 hh:mm, ALOCTM to be -23:59, and the
EXECTM could also be very large, positive or negative.
Knowing that it will take IBM time to diagnose and fix
their eror, I have revised the MXG logic to be smarter.
Now, if the INITDATE and TERMDATE are the same, then the
ALOCDATE and LOADDATE are known so the "date bump" logic
is bypassed (all seen observations fell into this case).
So only when the TERMDATE is a day or more later than the
INITDATE will the INITTIME, ALOCTIME (and LOADTIME) be
tested, and their dates are now bumped only if the delta
is more than 5 seconds, so small errors in the time value
in the SMF record won't cause the algorithm to misfire.
Note Sep 25, 2001: IBM APAR OW50134 acknowledges their
error, but that APAR resolution is "FIN", Fixed in Next.
Thanks to Andrew Hebden, Barclays, ENGLAND.
Change 19.055 -Change 18.233 documented new SYNC59 parameter, but it was
VMXGDUR actually added until this change. SYNC59 argument values
VMXGSUM can be:
Mar 30, 2001 N - do nothing.
Y - add 1 Minute to time
nnn - add nnn minutes to time
and a null value is the same as N.
-Additionally, a typo for TEMP02 option that caused error
FILE DDD.MXGSUM1.VIEW IS SEQUENTIAL when TEMP02 was used
was corrected.
Thanks to Karen Florup, Fidelity Investments, USA.
Change 19.054 MXG 18.10-18.18. MXG creates duplicate observations in
VMAC115 MQ-Series dataset MQMMSGDM, because there were duplicate
Mar 29, 2001 _ETY1152 macro executions. Delete the first invocation
of _ETY1152 macro (line 598), leaving one at line 639.
OBSERVATION COUNT CHANGE: MQMMSGDM fewer obs.
Thanks to Jun dela Rosa, U.S. Customs Service, USA.
Change 19.053 TCP SMF118 ERROR.4. HFS FILE TWO NAME ERROR message may
VMACTCP be created-in-error, if the second HFS filename is first
Mar 29, 2001 in the SMF record. MXG protection logic (for invalid
offset values) tested IF COL LE ... (which assumed that
COL would increase as the record was read. But now that
records with the physical positions reversed are found,
changing those tests to IF 205 LE ... will protect for
invalid offsets, and let MXG find the name segments in
whatever order IBM writes them in their SMF record.
The only impact of this error was that one or both HFS
filenames would be blank.
Apr 9, 2003: IBM APAR PQ73030 will correct the offsets,
which should only be non-zero for a RENAME event.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 19.052 INVALID DATA for MOUNSMND/MOUNEMND occurs if those dates
VMACMOUN are nulls; one pair of PD4 INPUT was protected with "??",
Mar 29, 2001 but now all PD4 INPUTs are protected.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 19.051 Support for APAR OW46622 identifies Address Spaces that
VMAC79 have Temporal Affinity (see also OW45238). No code was
Mar 28, 2001 changed, since R791FLG and R792FLG variables already are
input and kept, and bit 7 ('.......1'B) is the flag.
Change 19.050 Support for Landmark's The Monitor for IMS V1.1 records.
EXTIMCH Use TYPSTIMS to create and deaccumulate these datasets:
EXTIMCJ TIMSCH History Statistics
EXTIMCJD TIMSCJ Transaction Statistics
EXTIMCK TIMSCJD Transaction Statistics - Detail
EXTIMCKD TIMSCK Database Statistics
EXTIMCL TIMSCKD Database Statistics - Detail
EXTIMCL1 TIMSCL Buffer Statistics
EXTIMCL2 TIMSCL1 Buffer Statistics - First Pools
EXTIMCL3 TIMSCL2 Buffer Statistics - Second Pools
EXTIMCM TIMSCL3 Buffer Statistics - Third Pools
EXTIMCN TIMSCM Input Messages
EXTIMCO TIMSCN Interval Statistics
EXTIMCP TIMSCO Output Messages
EXTIMCT TIMSCP PSB Completion
EXTIMCU TIMSCT Thread Termination
EXTIMCUD TIMSCU PST Statistics
EXTIMCX TIMSCUD PST Statistics - Detail
IMACTIMS TIMSCX Exception Alerts
TYPETIMS Use the INFILE name of MONITIMS for the Landmark records.
VMACTIMS If your data records are compressed, Assemble and install
VMXGINIT member EXITMON6, an "Infile Exit" for SAS V6/V8, that can
Mar 28, 2001 read the compressed records. See comments in EXITMON6.
Apr 1, 2001
All above datasets have been created, and unexpected and
unwanted accumulated counters were found, so that you
must use member TYPSTIMS to first write to //WORK and
then SORT/Deaccumulate into the //PDB library.
Detection of accumulated fields requires non-zero values,
and some of the fields in the test data were zero, so you
need to use PROC MEANS MIN ; to examine each dataset for
negative minimum (improper deaccum) or large minimum
(variable that probably should be deaccumulated).
TIMSCU: CUMSGOQ and CUPWAIT are occasionally negative
and some timestamps are always missing.
Thanks to Warren Waid, J. C. Penny Company Inc, USA.
Change 19.049 Using JCLTEST8, warnings about CODEPASS option was
JCLTEST8 printed, because the instream proc still referenced the
Mar 27, 2001 (CONFIG) member instead of (CONFIGV8) for SAS V8.
Thanks to Art Hunter, Penn Mutual, USA.
Change 19.048 Variable STC11CSP should have been input as &PIB2.2 so
VMACSTC that its value is 20 for a 20 MegaByte/Sec Channel Speed.
Mar 27, 2001
Thanks to Chuck Hopf, MBNA, USA.
Change 19.047 Support for optional CICS TCP/IP timings and counts from
IMACICDA the EZA01 segment adds ten variables to the CICSTRAN
IMACICEZ dataset, but ONLY if you remove the comment block in the
IMAC110 IMACICEZ member. You need to also run UTILCICS to see
Mar 26, 2001 where the EZA01 segment was added, and may have to change
the expected order of segments in member IMACICDA.
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Change 19.046 Support for IMS Version 7.1 IMS Log Records is almost
VMACIMS compatible; only the '40'x log record was incompatibly
Mar 26, 2001 changed (and it is needed only if he message queue was
built), based on documentation review of the log DSECTS.
Some additional fields are now decoded, but no new
variables were added to the existing log record datasets.
Thanks to Engelbert Smets, Provinzial Versicherungen, GERMANY.
Change 19.045 Variable VERSNRMF was kept in most, but not all, RMF/CMF
VMAC7072 datasets, but is now kept in TYPE70PR/7204/72SC/78PA and
VMAC78 TYPE78SP datasets.
Mar 26, 2001
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.044 NETSPY type 'R' records caused INPUT STATEMENT EXCEEDED
VMACNSPY because MXG expected 89 bytes, but NETSPY 5.3 creates a
Mar 26, 2001 type R record of only 77 bytes, so the three fields that
were added (NSPYBPQU NSPYBPST NSPYRNLP) are now input if
NSPYENTL=89.
Thanks to Reuben de Leeuwe, IZB, GERMANY.
Change 19.043 Reading VSAM SMF caused INPUT STATEMENT EXCEEDED RECORD
VMAC42 for type 42 subtype 5 record. This particular subtype has
Mar 26, 2001 internal offset variables, and the MXG logic looped on
Mar 27, 2001 those offset variables (instead of looping on the count
field, as these internal segments have no count field),
but the MXG logic to convert from IBM offset value to the
SAS byte location: OFFzzzz=OFFzzzz-3+OFFSMF; was
being executed even when OFFzzzz=0, causing OFFzzzz=1
when a VSAM subtype 5 was read (OFFSMF=4 for VSAM SMF).
Now, IF OFFzzzz GT 0 THEN OFFzzzz=OFFzzzz-3+OFFSMF;
logic protects for the input zero value with VSAM input.
(BSAM SMF has OFFSMF=0, so it produced OFFxxxx=-3 if the
input value was zero, but since the subsequent MXG logic
tests IF OFFxxxx GT 0 THEN DO; so the segment was not
input when not present with BSAM dumped SMF input).
Thanks to Ken Williams, IBM Global Services, ENGLAND.
Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 19.042 Variables XMGMXT, XMGPAT, and XMGPQT should have been in
VMXGCICI a MAX= argument instead of the SUM= argument in the first
Mar 26, 2001 %VMXGSUM invocation. Their values were incorrect in the
PDB.CICINTRV dataset.
Thanks to Brian Hawthorne, MONY Life Insurance Company, USA.
Change 19.041 Support for APAR II12xxx clarifies documentation of the
VMAC50 VTAM type 50 record.
Mar 23, 2001
Change 19.040 If a file spanned more than five volumes, the VOLSERs in
VMACCTLG CTLGDSN dataset were overlaid with the subsequent VOLSER;
Mar 23, 2001 (i.e., VOLSER1='BARRY6' instead of 'BARRY1' if 6 vols).
Thanks to Gordy Rogers, Principal Financial Group, USA.
Change 19.039 Error: INVALID ARGUMENT TO SQRT FUNCTION is corrected;
ANALUOW small negative values due to rounding caused the error.
Mar 22, 2001
Thanks to Ed Long, FMR, USA.
Change 19.038 Change 18.286 corrected 1.024 to 1024 for SMF30JQT/RQT/
VMAC30 HQT/SQT, but ENCLACTM should also have been corrected to
Mar 22, 2001 use 1024 instead of 1.024 as the multiplier.
Thanks to Alan Freed, ADP, USA.
Change 19.037 Format MG060ID for type 60 records was updated from the
FORMATS SMF manual; several UNKNOWNs are now known.
Mar 19, 2001
Thanks to Chuck Hopf, MBNA, USA.
Change 19.036 Variable ABENDS in PDB.JOBS counts each OMVS/USS pseudo
BUILD005 step record as an abend. Change 10.325 set variable
BUIL3005 ABEND='OMVSEX' to identify each pseudo step record
Mar 17, 2001 (created when an OMVS/USS address space is "dubbed"), but
Change 16.183, which added variable ABENDS to PDB.JOBS,
should have skipped over these steps. The test in
BUILD005 to count abends was revised to now read:
IF ABEND NE: ' ' AND ABEND NE:'OMVSEX'
AND ABEND NE: 'FLUSH' THEN DO;
This error also could cause ABEND to be blank when it
should not have been, if the job had both pseudo steps
and other real steps that did have abends or returns.
Thanks to Rex Pommier, Western Surety Company, USA.
Change 19.035 New values for format MGSTCLB for variable STC07LBL are
FORMATS added:
Mar 16, 2001 /* $MGSTCLB FORMAT FOR VMACSTC */
VALUE $MGSTCLB
'1'='1:VERIFY LABEL VOLSER (IGNORE MEDIA)'
'2'='2:VERIFY UNLABELED CARTRIDGE (IGNORE MEDIA)'
'3'='3:BYPASS VOLSER AND MEDIA LABEL CHECK'
'4'='4:RECOVERY CARTRIGE NUMBER SPECIFIED'
'5'='5:VERIFY MEDIA TYPE, BYPASS VOLSER CHECK'
'6'='6:VERIFY MEDIA TYPE AND VOLSER'
'7'='7:VERIFY MEDIA TYPE AND UNREADABLE VOLSER'
;
Thanks to Martin Jensen, Jyskebank, DENMARK.
Change 19.034 Support for TNG for SOL260S records added. The SOL260S
VMACTNG records seem to be the same as SOL240S, so both formats
Mar 16, 2001 will create the same SOnnn Solaris TNG MXG datasets.
Thanks to Paul Hargreaves, SEMA, ENGLAND.
Change 19.033 Documentation/example only. No code change was made.
CONFIGV8 If you want to change the global MXG Default "PDB" DDNAME
VMXGINIT to something else, for example "MXG" because that's what
Mar 14, 2001 someone before you did, you should NOT make the change by
EDITing the VMXGINIT member, because that member changes
with every MXG version to GLOBAL all MXG macro variables,
and you would have to re-tailor every time you install a
new MXG version. Instead, you can change the DEFAULT=PDB
to DEFAULT=MXG by EDITing a USERID.SOURCLIB(CONFIGV8),
and changing the statement that invokes %VMXGINIT:
INITSTMT='%INCLUDE SOURCLIB(VMXGINIT);%VMXGINIT;RUN;'
to set the DEFAULT=MXG:
INITSTMT='%INCLUDE SOURCLIB(VMXGINIT);%VMXGINIT(DEFAULT=MXG);RUN;'
The CONFIGV8 member is one that sites may choose to EDIT,
since some of those options are site choices, but it does
not typically change between MXG versions, and it is the
intended location for any changes to the %VMXGINIT parms.
Further note: there should never be members starting with
VMAC nor VMXG in your USERID.SOURCLIBs, except as interim
corrections until you install the next MXG version. Old
VMAC/VMXG members in your tailoring libraries can cause
ABENDs, and require re-tailoring with each new Version.
They should always be removed when the new version is
installed, and all MXG tailoring can be put in the MXG
exit members or in your //SYSIN input stream, so you
never have to change your changes.
And while I'm in tutorial mode, if you have tailored any
VMXG members into your USERID.SOURCLIB, you probably did
it because you wanted to change the default arguments,
and you found how to make it work. But that is not the
correct way to %MACROs should be used. Instead of EDIT
of the VMXGxxxx member that defines the %MACRO %VMXGxxxx,
you simply EDIT the invocation of the %VMXGxxxx macro,
and change the parameter value there. For a specific
example, member RMFINTRV is where the statement that
invokes the execution of %VMXGRMFI macro is located, to
create PDB.RMFINTRV dataset. To change workloads, etc.,
you would EDIT the existing %VMXGRMFI
%VMXGRMFI statement in your RMFINTRV
member in USERID.SOURCLIB(RMFINTRV), adding the new parm:
%VMXGRMFI(PDB=PDB,...,PARM=WHATEVER);
In this manner, never editing the VMXG/VMAC members, the
install of a new MXG version means that you never have to
retrofit your MXG tailoring.
Thanks to Jerry J. Lentz, State of Arizona, USA.
Change 19.032 INPUT STATEMENT EXCEEDED RECORD for Shadow Direct subtype
VMACSHDW 06 record; the record says there was 417 bytes of SQL
Mar 14, 2001 text, but there were only 256 bytes of data, so the logic
to parse the SQL text into 100 byte chunks was revised to
use LENLEFT=MIN((LENGTH-COL+1,SM06SQLN) to control the
length of text bytes read.
Thanks to Chris Morgan, IBM Integrated Technology Services, ENGLAND.
Change 19.031 The CHAIN logic in processing IMF IMS transactions was
VMACCIMS revised by this user-contributed enhancement. When IMS
Mar 14, 2001 transactions are chained, the IMF record for the second
and subsequent transactions contain the arrival time of
the original transaction, which produced incorrect input
queue time measures. The CHAIN algorithm sorted thru the
chain and reset the arrival time of the second to the end
time of the preceding. But the original algorithm was
redesigned by Wolfgang:
- When transactions were started before the prior
transaction had finished, the RESPNSTM was cumulative;
that is corrected, and noted in new variables NEGTIME
and NEGCNT (kept only so you can see the impact of the
enhancement to see how wrong prior values were!).
- Data Steps 2 and 3 were removed, coding was moved into
the last step, reducing the execution and CPU time, I/O
and work space required.
Thanks to Wolfgang Vierling, AGIS GmbH, GERMANY.
Change 19.030 If your OS/390 was back level and did not have OW37565
VMAC7072 (flags ICF CPUs) MXG logic added in Change 19.015 caused
Mar 13, 2001 LPARCPUS=0 in TYPE70PR and missing data in ASUM70PR. The
Nov 15, 2001 logic now confirms the APAR is installed by checking the
NRCIXGT0 field before using SMF70CIX to id an ICF CPU.
Note added Nov 15, 2001: LPARCPUS=0 was a symptom here
because it was always zero AND caused missing data in the
ASUM70PR dataset, in that specific environment. After
this change, it is still normal to have observations in
TYPE70PR with LPARCPUS=0: those with LPARNAME='PHYSICAL',
or with SMF70CIN='ICF', or with LCPUADDR=. (for inactive
LPARs) will have LPARCPUS=0, and that's okay.
Thanks to Joe Montana, Acxiom, USA.
Change 19.029 Support for Tandem G06/G07/G08 TANCPU & TANDISK records.
VMACTAND -New fields were added to the end of the TANCPU record,
Mar 13, 2001 and variable DISKIOSF is now input as DISKIOS because it
is just the 8-byte DISKIOS field. The calculation of
rates was moved to the end of the TANCPU logic.
Code is in place for G06, G07, and G08 changes, but only
G06 with LRECL=770 has been validated.
-New fields were added to end of TANDISK record.
Code is in place for G06, G07, and G08 changes, but only
G06 with LRECL=746 has been validated.
Thanks to Patricia A. Wingfield, Bank of America, USA.
Change 19.028 Variables DSGPERCT and DS1PERCT-DS6PERCT in PDB.CICDS are
VMAC110 are not interval TCB Busy percent, as labeled, but are
Mar 12, 2001 the instantaneous value at the end of interval, which can
be quite different from the actual TCB Percent Busy:
Hour 03 06 09 12 15 18
DSGPERCT: 88 74 88 77 69 19
AVGPERCT: 22 70 58 65 64 40
IBM doesn't create DSxPERCT fields for the newer TCBs.
The PDB.CICINTRV dataset has all 11 TCBs DSnPERCT values
and all are recalculated (DSGPERCT=100*DSGACT/DURATM) so
they do match their label in the PDB.CICINTRV dataset.
The only change was to add "AT END" to the labels for the
7 TCB variables DSGPERCT-DS6PERCT in the PDB.CICDS data
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 19.027 Duplicate DB2ACCT records created by IBM Parallel Trans
EXDB2ACC are now deleted, but without this change, you will have
VMACDB2 duplicate DB2 accounting, negative DB2TCBTM, missing
VMXGUOW ELAPSTM, and these strange values in your DB2ACCT data:
Mar 12, 2001 QWACESC 01JAN1900:02:00:00 QWACEJST less than a second
Jun 5, 2001 QWACBSC 05JUN2001:19:20:21 QWACBJST minutes
The double accounting was introduced by IBM in DB2 APARS
PQ22260,PQ22451,PQ10864,PW06968,PQ45496 but it sure was
not obvious from the text of those APARs. The end result
is that, now, when DB2 parallelism is used, instead of
writing many individual child records, IBM "rolls up"
(sums) all child records into a single record, but that
record now is a duplicate of the previously existing
parent record. IBM finally documented how to identify
and delete these duplicate DB2ACCT records: New MXG
bit flag variable QWACPARR is now created
IF QWACFLGS='.........1......'B THEN QWACPARR='Y';
ELSE QWACPARR=' ';
to identify these "rolled up" records, and the statement:
IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;
was added in the EXDB2ACC exit member so that MXG will
delete this duplicate data.
Note: That IF/DELETE statement was a circumvention and it
was removed from all exits by Change 22.121.
Additionally, VMXGUOW was similarly updated so ASUMUOW
will also delete the dupes, and it could be re-run
against existing DB2ACCT/CICSTRAN data to re-build
PDB.ASUMUOW without duplicates. Normally, I am reluctant
to delete any SMF data, but this duplication is so
obscure and could be so impacting, that I chose to delete
them in MXG to prevent their accidental introduction into
DB2ACCT (and ASUMUOW), which are used for DB2 billing. I
am not aware of any other data in these records which
justifies keeping them, but since the logic was added in
the Exit, you could easily change it to create these
rolled-up data records, if needed.
This note's documentation was enhanced Jun 5, but no code
was changed.
Thanks to Being Hwang, DOA, State of Wisconsin, USA.
Thanks to Gunther Vogt, Audi AG, GERMANY.
Change 19.026 ASUMV14 summarizes STK VTS dismount records to get total
ASUMV14 bytes compressed and uncompressed and the compression
ASUMV11 ratio. ASUMV11 summarizes STCVSM11 to the QTR hour too
Mar 10, 2001 get the back end channel busy for STK VSM.
Note that the STCVSM11 dataset must be selected from only
one system; each system connected to the VSM writes what
are effectively duplicate records, at slightly different
intervals.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.025 CICS CPU time captured in CICSTRAN/CICDS/TYPE30/TYPE72 is
ADOC110 now docummented in member ADOC110. This change adds the
VMAC110 variables QRCPUTTM, MSCPUTTM and KY8CPUTM, which already
VMXGCICI exist in the CICSTRAN dataset, to the CICDS Dispatcher
Mar 10, 2001 Statistics dataset and to the CICINTRV summary dataset.
Change 19.024 Cosmetic. Status variables DVLCSMSS DVLCSMS2-DVLCSMS8
VMACDCOL are now formatted with existing MGDCOVS format, as were
Mar 8, 2001 variables DVLSMSS DVLSMSS2-DVLSMSS8.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 19.023 Change 19.015 removed NRCPUS from TYPE70PR dataset; this
ANALRMFR change revises the RMF reporting to match that change.
Mar 6, 2001
Change 19.022 The First SQL Page Number QW0006PN, a 3-byte character to
ANALDB2R display up to 999, was replaced by QW0006PG, a numeric,
Mar 6, 2001 so now the '1ST PAGE' value for large values will print.
Thanks to Andrew Schmid, EDS Canberra, AUSTRALIA.
Change 19.021 If the rarely used TEMP01 and TEMP02 options of VMXGSUM
VMXGSUM are used, and TEMP02 is tape format, there will be a SAS
Mar 6, 2001 error attempting to open two datases on a tape.
Thanks to Khoan Dang, MBNA, USA.
Change 19.020 Using %VMXGRMFI(PDB=SMF) caused ERROR: FILE WORK.MERGERMF
VMXGRMFI NOT FOUND. The default, PDB=PDB, worked fine. The test
Mar 6, 2001 %ELSE %IF &PDB=PDB %THEN %DO; was changed to now read:
%IF &PDB=PDB OR &PDB=SMF %THEN %DO;
Thanks to Wayne A. Schumack, Blue Cross of Minnesota, USA.
Change 19.019 INPUT EXCEEDED RECORD LENGTH SMF 102 subtype 140 because
VMAC102 new fields INCOMPATIBLY inserted by DB2 5.1 were not read
Mar 5, 2001 in for this Audit Trace record subtype.
Thanks to Brad Dorn, Kohl's, USA.
Change 19.018 Protection for zero-divide in new z/OS variable SMF70CPA,
VMAC7072 (no actual error in the MXG output, only a hex dump print
Mar 5, 2001 on the SAS log) because OS/390 2.10 unexpectedly writes
SMF type 70 records with LENCPUC=40, (2.10 doc says 28).
If LENCPUC GE 40, MXG Inputs SMF70CPA/SMF70WLA/SMF70LAC
(new MSU capacity stuff) and then divided without testing
the denominator before the divide, and the new fields are
all zero in the R2.10 extended segment. And MXG expected
SMF70WLA to be missing if the record did not contain that
new MSU capacity measure, using IF SMF70WLA=. THEN DO...
logic in VMXGRMFI to detect its presence, so this change
also forces SMF70WLA=. if it is found to contain zeroes.
Thanks to Alan Freed, Automatic Data Processing, USA.
Change 19.017 Support for APAR OW46268 for TYPE74 USS Kernel data was
VMAC74 already in place; incorrect format and documentation was
Mar 5, 2001 recognized during MXG validation of those fields.
Change 19.016 Cosmetic. The A2THID=UPCASE(AUTHID) should have been
ANALDB2R AUTHID (only impact would be if you typed selection names
Mar 1, 2001 in lower case, and none would have been selected). Three
repeated IF AUTHID=:' ' THEN AUTHID=' ' "compiler
fakers" were redundant and were deleted.
Thanks to Tom Parker, CSC Hogan Systems, USA.
Change 19.015 If you have 2064 (z900) CPU with ICF-s installed, and
ASUM70PR do not have the PTF for APAR OW48190 installed, the count
VMAC7072 of ICF-s will be incorrect, causing incorrect CPU busy.
VMXGRMFI Without that APAR (no PTF until April), the IBM type 70
Mar 1, 2001 70 field SMF70CIX does NOT properly flag ICF CPUs, so the
Mar 6, 2001 PARTNCPU and LPARCPUS variables that count real CPs will
be wrong in TYPE70, TYPE70PR, ASUM70PR, and RMFINTRV, and
MSU4HRAV will also be incorrect. This change completely
revises how ICFs are counted, moving that logic from the
ASUM70PR back into VMAC7072 so all four datasets above
will be correct, and this change corrects the count with
logic that works whether or not you have installed the
PTF for OW48190.
Caveat: You must use VMAC7072, VMXGRMFI, and ASUM70PR
from this change; make sure you do not have any of those
three members in your "USERID.SOURCLIB" (or if you do,
you must re-tailor your changes into these new members).
First, the code loops thru the type 70 PR/SM segments to
count the number of non-zero values of SMF70CIX. If the
count is always zero, then APAR OW37565 (which populates
SMF70CIX with 1 for "CP" and 2 for "ICF") is not on this
system, so ICF's can't be counted. A non-zero value in
NRCIXGT0 proves the SMF70CIX field is valid, and IFCs can
be counted, and then I can recognize an invalid value of
zero in SMF70CIX is really an ICF, as that is the IBM
error that will be fixed by OW48190s PTF: SMF70CIX had a
zero instead of a 2 for an ICF. This allows MXG to count
and remove ICFs from the PARTNCPU count of CPs in a box.
However, the variable PARTNCPU in TYPE70 and TYPE70PR did
include ICFs; it was only in PDB.ASUM70PR/PDB.RMFINTRV
that both PARTNCPU and LPARCPUS were corrected for ICFs.
This change now corrects all four datasets, so the logic
in ASUM70PR (which both creates PDB.ASUM70PR and updates
PDB.RMFINTRV) was revised to no longer subtract ICFs.
Note also that VMXGRMFI at Change 19.012 is also neeeded
to support the 2064 processors, independent of this fix,
for variable MSU4HRAV valid on 2064s, so it is listed
here as well to alert you to use all three new memgers.
-Variable NRCPUS was removed from TYPE70PR, because it did
not belong there; LPARCPUS is the correct variable that
counts CPs in this LPAR, while NRCPUS is a TYPE70-only
variable that counted the CPUs in the SYSTEM that wrote
this type 70 record, and NRCPUS in TYPE70PR could be
misleading and/or confusing.
-Mar 6 additions. The summarization interval in ASUM70PR
and RMFINTRV is set in member IMACRMFI's macro _DURSET
definition; by default, each original interval is output.
If you change the interval of your PDB.RMFINTRV data:
a. You can tailor your own RMFINTRV member, using
VMXGRMFI(INTERVAL=HOUR);
but then you have to change the _DURSET definition in
your IMACRMFI member to set variable STARTIME hourly:
STARTIME=DHMS(DATE,HOUR,0,0);
because member ASUM70PR not only created PDB.ASUM70PR
using _DURSET, but also then reads and rewrites the
PDB.RMFINTRV dataset (adding Platform Busy, Percent of
Hardware, etc., variables), so, instead,
b. Leave the default INTERVAL=DURSET, in the RMFINTRV
member (if you still need one), and just tailor the
STARTIME value in member IMACRMFI.
c. Watch for a possible re-design to make it consistent.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.014 The original text of this change (about CPUTM in CICSTRAN
VMAC110 possibly being the sum of many variables) was wrong; the
Feb 23, 2001 MXG equation for billable CPU time in CICSTRAN:
Mar 12, 2001 CPUTM=SUM(TASCPUTM,CPURLSTM).
has always been correct and should not be changed.
See member ADOC110 for the new note on CPU capture in the
CICSTRAN, CICDS/CICINTRV, SMFINTRV and TYPE72/72GO data,
which provides a schematic of what's captured where.
Thanks to Trevor A. Holland, TELSTRA, AUSTRALIA.
Change 19.013 Support for TLMS Release 5.5 (COMPATIBLE). Two new
VMACTLMS variables, BACUNIT (Create Unit) and BALUNIT (Last Unit)
Feb 23, 2001 were added compatibly at the end of the record; both of
these new fields were actually added back in Release 5.4.
Thanks to Jon Whitcomb, Great Lakes Higher Education Corp, USA.
Change 19.012 Change 18.348 created QWACALOG/AWCL/AWAR/OCSE/SLSE/DSSE/
ASUMDB2A OTSE/IXLT from QWAX variables, but did so incorrectly,
VMACDB2 they were not formatted as TIME12, and ASUMDB2A was not
Feb 23, 2001 revised to include the QWACs instead of the QWAXs.
Apr 4, 2001 Line 105 in 18.18's ASUMDB2A was removed to eliminate the
"duplicate variables" message (but it had no impact).
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 19.011 MXG 18.18 only, new variables only. Incorrect SUBSTR()
VMXGRMFI argument caused CPCNRCPU to be missing, CPFCNAME could
Feb 19, 2001 have extraneous characters, CPUTYPE='2064'x was not found
Mar 1, 2001 in the MG070CP table because CPCMODE3='404040'x should be
removed. The correct block of code now reads:
END;
CPUSTUFI=CPUTYPE!!CPUVERS1!!CPCMODE3;
CPUSTUFO=PUT(CPUSTUFI,$MG070CP.);
IF CPUSTUFO NE CPUSTUFI THEN DO;
CPCMSU =INPUT(SUBSTR(CPUSTUFO,1,4),4.);
CPCFNAME=SUBSTR(CPUSTUFO,6,8);
CECSUSEC=INPUT(SUBSTR(CPUSTUFO,15,10),10.);
CPCNRCPU=INPUT(SUBSTR(CPUSTUFO,26,2),2.);
SMF70WLA=CPCMSU*NRCPUS/MAX(CPCNRCPU,PARTNCPU,NRCPUS)
END;
No change was made to the logic in member FORMATS that
creates the MG070CP format, but comments that describe
that format's format were revised to match the format.
Note: This correction only applied if the FORMAT was
used. If SMF70WLA was populated, the FORMAT is
not used. But Change 20.168 is then needed.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.010 The FTPREPLY character variable contains '000000FA'x, but
VMACTCP is converted by this change to ' 250', its numeric value
Feb 19, 2001 in a character variable, by inserting this statement
FTPREPLY=PUT(INPUT(FTPREPLY,&PIB.4.),4.);
and by changing the input from $EBCDIC4. to $CHAR4. to
prevent conversion of the binary value.
Using $CHAR versus $EBCDIC under OS/390 doesn't matter
here, but under ASCII, leaving the $EBCDIC4. informat
would convert any binary value that happened to be a
valid EBCDIC character into its ASCII equivalent:
(eg: '0000C1FA'x becomes '000041FA'x when INPUT with
$EBCDIC4. informat under ASCII SAS.)
Now the Reply values for the Client (FTPREPLY) will be in
the same format as the Server (FTPRSRSR) reply.
Change 19.009 Support for CA/TNG post-9907 (INCOMPAT). The initial MXG
VMACTNG support was for the "old" data records, which had simple
Feb 19, 2001 data format, but CA's complete revision (with internal
version 6 or higher), with its base-36 counting and with
repeat-count counters, is now supported with this change.
Thanks to Roman Jost, Gjensidige, NORWAY.
Change 19.008 Variable SYNCNAME was added to the KEEP= for IMS597 so
VMACIMSA that variable PROGRAM will be populated in Fast Path
Feb 19, 2001 dataset.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 19.007 MXG 18.18 only. The BY statement in _SHPSUGL was missing
VMACMWSU its ending semicolon, and the extra semicolon at the end
VMACMWUX of MACRO _BHPUXDS was removed.
Feb 19, 2001
Change 19.006 The calculation of RDHITPCT in TYPE42DS was incorrect in
VMAC42 the denominator; the revised equation is:
Feb 19, 2001 RDHITPCT=(CACHHITS-WRITHITS)/(CACHCAND-WRITCAND);
The previous denominator was just CACHCAND and the value
calculated was too low.
Thanks to Ep van der ES, Dow Chemicals, BELGIUM.
Change 19.005 NTSMF files that have been COPYed and APPENDed without
VMACNTSM the /B parameter (search NEWSLTRS) and/or concatenated on
Feb 16, 2001 MVS have been found with a record of nulls (hex zeroes)
that MXG did not expect. This change detects and deletes
those records, printing a message that these bad records
were found in your input.
Thanks to Howard Glastetter, Weyerhaeuser, USA.
Change 19.004 SAS does not permit an ARRAY name to be the same as a
VMACSYNC variable name; a new ARRAY named DD defined in VMACSYNC
Feb 16, 2001 conflicted with a variable named DD in VMACRMDS, (only
if you tailored MXG to process both RMDS and SYNCSORT SMF
records in the same MXG datastep). Changing the ARRAY
names in VMACSYNC transparently corrects the conflict.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 19.003 IMS Version 7 requires Omegamon/IMS V500, but Candle says
TYPEITRF the upgrade from V300 to V500 is transparent as far as
Feb 14, 2001 their ITRF data records are concerned.
Thanks to Gene Quinn, Blue Cross of Rhode Island, USA
Change 19.002 Two new VGETxxx %MACROs were included in MXG 18.18 but
VGETENG they (and the new VGETxxx prefix) were not documented.
VGETOBS %MACROS that "Get" and return a value are named VGETxxx,
VMXGENG and the value "got" is returned in a macro variable that
Feb 14, 2001 is named VGETxxx. The two new implementations are:
Executing Will return
%VGETENG(DDNAME=yyyyyyyy); The Name of the SAS Engine
that created that yyyyyyyy
data library, in &VGETENG.
(Needed by MXG so we can
exploit V8 features.)
%VGETOBS(DDNAME=,DATASET=); The number of observations
in dataset DDNAME.DATASET
in &VGETOBS.
The earlier %VMXGENG macro still exists for compatibility
but it now invokes %VGETENG.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.001 The _BTY30UV BY list in VMAC30 was not quite the same as
VMAC30 the order needed in BUILDPDB, and was corrected to be:
Feb 12, 2001 MACRO_BTY30UV READTIME JOB JESNR INITTIME INTETIME
DESCENDING INTBTIME MULTIDD EXTRADD %
(Note that SMFTIME is appended during the initial NODUP
sort in _STY30UV sort, but is not needed subsequently.)
Thanks to Barry McQueen, Department of Defence, Australia.
LASTCHANGE: Version 19.
=========================member=CHANGE18================================
/* COPYRIGHT (C) 1984-2001 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 18.18 is dated Feb 12, 2001, thru Change 18.360.
MXG Newsletter THIRTY-EIGHT is dated Feb 12, 2001.
MXG Version 18.12 was dated Jan 30, 2001, thru Change 18.341.
MXG Version 18.11 was dated Jan 4, 2001, thru Change 18.315.
First MXG Version 18.10 was dated Dec 20, 2000, thru Change 18.303.
MXG Version 18.09 was dated Oct 24, 2000, thru Change 18.264.
MXG Newsletter THIRTY-SEVEN was dated Oct 24, 2000.
MXG Version 18.08 was dated Sep 25, 2000, thru Change 18.238.
MXG Version 18.07 was dated Aug 31, 2000, thru Change 18.217.
First MXG Version 18.07 was dated Aug 30, 2000, thru Change 18.216.
Test MXG Version 18.07 was dated Aug 27, 2000, thru Change 18.204.
MXG Version 18.06 was dated Jul 28, 2000, thru Change 18.177.
MXG Version 18.05 was dated Jul 1, 2000, thru Change 18.154.
MXG Version 18.04 was dated May 15, 2000, thru Change 18.109.
Final MXG Version 18.03 was dated Apr 17, 2000, thru Change 18.086.
MXG Version 18.03 was dated Apr 12, 2000, thru Change 18.083.
First MXG Version 18.03 was dated Apr 11, 2000, thru Change 18.081.
Final MXG Version 18.02 was dated Mar 29, 2000, thru Change 18.052.
Second MXG Version 18.02 was dated Mar 16, 2000, thru Change 18.046.
First MXG Version 18.02 was dated Mar 15, 2000, thru Change 18.043.
MXG Version 18.01 was dated Mar 3, 2000, thru Change 18.021.
MXG Version 17.17 was dated Feb 7, 2000, thru Change 17.398.
Newsletter THIRTY-SIX was dated Feb 7, 2000, thru Change 17.398.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 18.18 was shipped to all MXG licensees.
II. Incompatibilities and Installation of MXG 18.18.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 18.18 is the annual version, Feb 12, 2001, and
it was sent to all MXG sites, and contains NEWSLETTER THIRTY-EIGHT.
Major enhancements added in MXG 18.18:
Support for z/OS Version 1.1 (COMPATIBLE).
Support for CICS/TS for z/OS Version 2.1 (INCOMPATIBLE).
Support for DB2 Version 7.1 (COMPATIBLE).
Support for Vital Signs VisionNet VSV TCPIP stats.
Support for Innovation Data Processing's FDR SMF.
Support for SYNCSORT Release 3.7 (COMPAT).
Support for IBM TapeTools MOUNTMON user SMF record.
ASUMTALO MAXDRVS greater than installed tape drives corrected.
New MACRO _Vdddddd KEEP=x y z %; finally makes KEEP= easy.
Major enhancements added in MXG 18.12:
Support for CA UNICENTER TNG AIX, CISCO, NT, and SOLARIS objects.
Support for SOLVE SMF Subtypes 1 and 2.
Support for SHADOW SMF Subtype 6.
Support for IBM Domino WebServer Logs enhanced.
Support for DFSMSRMM 1.5 changes (COMPATIBLE).
Major enhancements added in MXG 18.11:
Support for DB2 Space Manager 2.1 (INCOMPAT).
Support for NPM APAR OW45788 corrects LXETxxxx.
Scheduling Environment variables added to PDB.JOBS
MXG execution under SAS V8.1 notes consolidated in NEWSLTRS member.
Documentation of the Internal Logic of BUILDPDB in DOCPDB member.
Erroneous EXCLUDED FIELDS message, MXG 18.10 only, TS 1.3 only.
Major enhancements added in MXG 18.10:
RMFINTRV now calculates MSU4HRAV 4-hour running MSU avg for z/OS.
DB2ACCT variable DB2TCBTM included Stored Proc AS CPU time twice.
Support for MQ Series V5.2 (INCOMPATIBLE) SMF 115 and SMF 116.
Support for Websphere Appl Server (EE) Component Broker SMF 120.
Support for TMON for MVS 2.0 NQ records corrected.
Support for ANALRMFR to create HTTP Server Report from SMF 103.
Using IMACJBCK for DB2ACCT selection saves CPU time
NPM Type 28 Subtype 'DC'x caused INPUT EXCEEDED.
CICINTRV request for "EOD" did not sum correctly.
CICS 1.3 SAP Journal records in CICSJOUR vice CICSSAP
Support for Vital Signs VisionNet VSAM file.
Short JES3 type 6 record protected.
Support for APAR OW37743 corrected.
CICINTRV DSA size variables corrected.
Support for NETVIEW SMF 38 APAR OW45728.
Major enhancements added in MXG 18.09:
Support for NPM APAR OW37743 (INCOMPATIBLE if TIC3 and 3746).
Support for Neon System's Shadow Server V4.5 SMF record.
Support for NTSMF ADSM, ColdFusion, MQSeries, WorldSecure objects.
Support for Candle's Omegamon for VTAM TCP record.
TYPE74 PCTDVUSE,PCTDVCON, etc for PAV Volumes now less than 100%.
GRAFWORK/GRAFRMFI/GRAFTAPE SAS/GRAPH examples now output as HTML
TYPE70 variable CPCMODEL ('RX6') added, was already in TYPE70PR.
Format $MGSASPR maps SAS PROC name to Product name, for SAS SMF.
Major enhancements added in MXG 18.08:
Support for Landmark TMON for VTAM.
Support for Landmark TMON for DBCTL.
Support for Omegamon for VTAM V500 (COMPAT).
Support for Enterprise Data Access, EDA, SMF record.
Support for AS/400 Collection Services records.
Summarization/Trending for STC datasets.
ANALUAFF finds wasted tape drives for SORT without UNIT=AFF.
Major enhancements added in MXG 18.07:
Support for OS/390 R2.10 (INCOMPAT!). See Change 18.134.
R2.10 support was included in MXG 18.06, although there was no
statement of support in that Version, and the Change text was
"Reserved". MXG 18.06 or later is required for OS/390 R2.10.
Support for BMC MainView for MQ Series History File V2.1.
Support for APAR II11493 (INCOMPAT) type 50 SMF.
Support for APAR PN61399 TCP type 118 SMF.
Support for NTSMF object "SESSION", from Term Svcs.
Support for APAR OW45168 SMF type 94 confirmed.
Support for APAR OW43854, adds OPENTIME to SMF 62 and 64.
VMXGSUM revisions, VIEW used, can avoid I/O, can be big savings.
ASUMUOW revised, MQ Series added to DB2+CICS, VIEW used for speed.
TYPE71 Memory (Hi,Med,Low Impact Frames) now correct and useful.
Datasets TYPE7 and TYPE23 now automatically built by BUILDPDB/3.
Example ANALCNCR and PROC TABULATE create HTML format reports.
New %MACRO VMXGENG returns the ENGINE of a SAS dataset.
MXG Y2K error, BMC CICS Manager type 110 segment corrected.
Major enhancements added in MXG 18.06:
Support for OS/390 R2.10 (INCOMPAT!). See Change 18.134.
Support for OS/400 Release 4.5.0 (INCOMPATIBLE).
Support for IHS WEBSERVER SMF 103 APAR PQ32435, adds JOB/ASID.
Support for BETA93 Release 321 INCOMPATIBLE subtype 1 record.
Revised support for TYPEEDGS/TYPEEDGB for DFSMS/rmm.
TCP SMF 118 Bad Record INPUT STATEMENT EXCEEDED corrected (again).
SAS Version 8.1 causes Condition Code 4 and prints log message:
WARNING: ARGUMENT 3 TO MACRO FUNCTION %SUBSTR IS MISSING
because the length of their &SYSVER Version macro was shortened
from four to three. There is no execution impact, fortunately,
except that the warning causes MVS Condition Code/Return Code of
four instead of zero, and wastes your time in reading this!
See further discussion in Change 18.159 which revises MXG.
Major enhancements added in MXG 18.05:
Support for Domino Server R5.0.3 subtypes 2 and 6.
Support for Type 42 RLS Subtype 19 enhanced, fixed.
Support for COM Tran Integrator, TN3270 Server, etc.
Support for new NTSMF Objects in Windows 2000 Server.
Support for IBM Websphere SMF type 103 subtype 2 undoc field.
Support for 3494 Peer-to-Peer (Gemini).
Support for APAR OW41317 support, INCOMPAT R2.7, R2.8, R2.9.
IMS Log Version 5.1 caused zero obs in IMSTRAN in TYPEIMSA.
ANALSMJB Who is filling your active VSAM SMF file utility.
MEMSIZE removed, S=72,S2=72 restored to CONFIGV8.
Trending of NTSMF LOGLDISK for NT disk space in TRNDNTLD.
Additional ESS variables now decoded from type 6.
Summarize TYPETCPT to track concurrent users in ASUMTCPT.
Major enhancements added in MXG 18.04:
SAS V8.0/V8.1 errors can corrupt variable labels in tape datasets
built by the V8SEQ "tape" engine. Until the errors are fixed, I
strongly recommend that you change the default "tape" engine to
V6SEQ instead of V8SEQ (by adding SEQENGINE=V6SEQ to the CONFIGV8
member in your CONFIG concatenation, and by changing any LIBNAMEs
with "TAPE" engine specified to "V6SEQ", as discussed in the SAS
Technical Note 5 in Newsletter-to-be THIRTY-SEVEN (in NEWSLTRS &
in Newsletters on homepage), and in the text of Change 18.104.
Update July 26: SAS ZAP Z8002651 exists and corrects the error,
so that with that ZAP installed, the V8SEQ engine can be used.
TYPEIMSB correction for IMS 6.1 log processing.
Support for Roger Software Development RSD FOLDERS.
Support for MainView for CICS 5.3.01 (INCOMPATIBLE).
Major enhancements added in MXG 18.03:
Support for OS/390 Release 2.9 (17.17 support was not correct).
Support for NETSPY Release 5.3 (COMPATIBLE).
Support for CMA Release 1.11 (COMPATIBLE).
Support for OAM Release 1.5.0 (INCOMPATIBLE) SMF 85.
Support for Systemware SYSOUT X/PTR, JHS, MPS, and C/QUE.
IMS Log OTMA/APPC transactions supported, dates fixed in ASMIMSLx.
ASUM70PR/ASUMCEC with ICFs had PCTLnBY and LPnDUR wrong
ASUMTALO corrected for SPINning (in-flight) allocations.
KEEPALL= argument for VMXGSUM was externalized to a Global macro.
Major enhancements added in MXG 18.02:
Support for Tivoli Netview Performance Monitor NPM 2.5 (SMF 28).
Support for GUTS Gutenberg Time Sharing user SMF records.
Support for optional CICS RMI counters.
Support for Oracle Version 7.3.3 (INCOMPATIBLE)
Support for retrofit APAR OW41317 was in MXG 17.17
Support for type 21 APAR OW40414, added four byte fields.
Recognition and non-counting of ICF processors is now corrected.
Major enhancements added in MXG 18.01:
MXG 18.01 replaced MXG 17.17 for ITSV sites. Changes made in MXG
17.17 to BUILDPDB/BUILDPD3, RMFINTRV, and ASUMTALO members had not
been tested with ITSV when MXG 17.17 was shipped. Change 18.009.
Using Report Performance Groups or Reporting Classes in IMACWORK
to define the workloads in our RMFINTRV dataset did not work in
MXG 17.17; enhancements to VMXGRMFI (invoked in RMFINTRV) support
using any mixture of report/control/service class to define your
RMFINTRV workloads. Revised UTILRMFI can be used to discover any
overlap if you get the "CPU TIMES DO NOT MATCH" error message.
Support for DB2 6.1 Buffer Pools 100+ in DB2ACCT/DB2STATS.
Support for Type 79 Subtype 15 IRLM Long Lock now validated.
ASUMUOW adds DB2ELAP to output, corrects wait for SPUN UOWs.
You can now use (COMPRESS=YES) with MACRO _Ldddddd definitions.
Blank value in JOBCLASS corrected.
ANALDSET needed _NULL to be added to its DATA statement.
Invalid Y2K date in BETA93 product now protected.
Type 39 record INPUT EXCEEDED RECORD error corrected.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
MXG 18.18 has been tested with SAS 6.09, SAS V8.0 TS M0/M1 and V8.1.
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.7.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
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
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
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 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 7.1.0 Mar 30, 2001 18.11
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
NPM 2.5 Feb ??, 2000 18.02
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 Jul 4, 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
SAS Institute
SAS V8 (TS M0), (TS M1):
(Read member NEWSLTRS (search 'V8') for other V8 notes.
MXG 16.16 runs, prints "options CODEPCT/BLKSIZE don't exist".
MXG 17.01 removed options in CONFIGv8 member, Change 17.073.
MXG 17.07 exploits 32K character var length, Change 17.253
MXG 17.08 exploits INHERIT option VMXGSUM, Change 17.265.
MXG 18.04 changes V8 default to SEQENGINE=V6SEQ. Change 18.104.
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
Windows 2000 Build 2195 17.10
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
NTSMF Version 2.3 17.10
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 CICS V500 User SMF 18.01
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 VTAM V500 18.08
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
NETSPY 5.3 18.03
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 18.03
IMS 5.1 - ASMIMSL5/TYPEIMSA 18.03
Amdahl
APAF 4.1, 4.3 16.08
II. Incompatibilities and Installation of MXG 18.10.
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.
1. Incompatibilities introduced in MXG 18.10 (since MXG 17.17):
a- No changes in MXG architecture were made between 17.17 and 18.10
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.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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.10:
Dataset/
Member Change Description
SAS V8 18.xxx SAS Version 8.1 notes are updated in member NEWSLTRS.
many 18.001 Duplicate removal by MXG _Sdddddd macro enhanced.
many 18.338 Description of soon-to-be-pervasive MACRO _Vdddddd.
many 18.317 Support for z/OS R1.1 (COMPATIBLE).
many 18.338 New MACRO _Vdddddd KEEP=x y z % ; syntax defined.
ANAL94 18.218 Report failed with PDB=SMF/PDBOUT=PDB.
ANALCNCR 18.326 Support for interval specification of MINUTE.
ANALCNR 18.089 Last period for synchronized intervals corrected.
ANALDB2R 18.067 Negative DD counts for OPEN/USED DDs in reports.
ANALDB2R 18.246 DB2 Report PMAUD03 failed, semicolon missing.
ANALDB2R 18.329 DB2 Accounting Summary enhanced for DB2 Version 6.
ANALDSET 18.010 _NULL_ needs to be added to DATA statement.
ANALHTML 18.177 ANALCNCR/PROC TABULATE HTML format reports w/ODS.
ANALRMFR 18.028 Partition Data Report supports CP/ICF.
ANALRMFR 18.302 Support for RMF HTTP Server Report from SMF 103.
ANALSMJB 18.149 Who is filling your active VSAM SMF file utility.
ANALTCP 18.091 Sample TCP/IP basic analysis reports.
ANALUAFF 18.234 Detect wasted tape drives for SORT without UNIT=AFF.
ASMIMSL5 18.030 APPC transactions caused negative SERVICETM
ASMIMSL5 18.060 IMS transactions thru OTMA and APPC revised.
ASMIMSL6 18.287 Assembly error: CLOSE (R3) s/b CLOSE ((R3)).
ASUM42DS 18.140 Variables CIOPCT, HITPCT, RDHITPCT were incorrect.
ASUM70PR 18.131 Amdahl SMF 70 LPARNUM=0, LPARNAME=Inactive error.
ASUMSTC 18.235 Summarization/Trending for STC datasets.
ASUMTALO 18.013 Failed under ITSV or with USER=WORK: Member Lock....
ASUMTALO 18.346 MAXDRVS greater than installed tape drives corrected.
ASUMTCPT 18.122 Summarize TYPETCPT to track concurrent users.
ASUMUOW 18.007 Wait times for spun UOWs corrected, DB2ELAP added.
ASUMUOW 18.204 Major rewrite, adds MQ Series data, easy tailoring.
BLDNTPDB 18.145 Revisions to use symbolics instead of hardcode dsn.
BUILDPD3 18.124 BUILDPD3 fails, VARS NOT SORTED WORK.TYPE25.
BUILDPDB 18.018 Blank value for JOBCLASS corrected.
BUILDPDB 18.094 If you want to write the PDB output to tape.
BUILDPDB 18.184 Datasets TYPE7 and TYPE23 now automatically built.
BUILDPDB 18.217 BUILDPDB Missing _S21 to build PDB.TAPES.
BUILDPDB 18.259 Do not redefine MACRO _BLD005 under SAS V8.
BUILDPDB 18.306 Scheduling Environment variables added to PDB.JOBS
BUILDPDB 18.312 Variable DATETIME now contains correct value.
BUILDxxx 18.014 Warning CODEPASS=2 eliminated, can be disregarded.
CONFIGV8 18.104 SAS V8 requires SEQENGINE=V6SEQ for tape datasets.
CONFIGV8 18.147A MEMSIZE removed, S=72,S2=72 restored to CONFIGV8.
DOCITSV 18.310 Example of ITSV macros needed to add new variable.
DOCMXG 18.168 Example of how to use USER=XYZ with MXG.
DOCPDB 18.315 Documentation of the Internal Logic of BUILDPDB.
EXCECTIM 18.066 Exit for PDB.ASUMCEC with different system clocks.
FORMATS 18.240 SAS user SMF record, $MGSASPR maps Proc to Product.
FORMATS 18.256 MG073CD decodes OSA EXPRESS and OSA EXPRESS DIRECT.
GRAFRMFI 18.263 GRAFRMFI Graphs from RMFINTRV now output as HTML.
GRAFSAMP 18.264 GRAFWORK sample using mainframe PDB, output to LAN.
GRAFTAPE 18.262 GRAFTAPE MXGTMNT and STK TRENDing, output as HTML.
GRAFWORK 18.264 GRAFWORK Graphs from RMFINTRV now output as HTML.
GRAFxxxx 18.220 SAS V8.0 (not 8.1) ERRORABEND with missing values.
IMAC6ESS 18.138 Additional ESS variables now decoded from type 6.
IMACICBB 18.190 MXG Y2K error, BMC CICS Manager now data-validated.
IMACICUS 18.036 Support for optional CICS RMI counters added.
IMACJBCK 18.289 Using IMACJBCK for DB2ACCT selection saves CPU time
JCLIMSL5 18.318 SORT FIELDS value should have been 35,8.
JCLMNTH 18.113 Monthly failed trying to build MONTH.ASUMCEC.
JCLUWOV 18.204 JCL Example for CICS+DB2+MQ Series merge.
MONTHBLD 18.135 WEEKBLD and MONTHBLD had wrong BY for TYPE30MU.
PRINTNL 18.058 No output if you did not use MXGSAS or CONFIG=.
RMFINTRV 18.000 Failed under ITSV, because of hardcode PDB.RMFINTRV.
RMFINTRV 18.111 Variable MVSLEVEL now kept in RMFINTRV.
RMFINTRV 18.298 Calculation of z/OS License Manager MSU4HRAV added.
RMFINTRV 18.345 High/Med/Low Impact Frame variables added to RMFINTRV
TRNDNTLD 18.145 Trending of NTSMF LOGLDISK for NT disk space util.
TYPE102 18.178 DB2 6.1 only, IFCID 106, end comment missing.
TYPE102 18.330 SQL Text truncated to 100 characters with V8/NoCOMP.
TYPE103 18.092 TYPE1032 dataset had missing values for variables.
TYPE103 18.129 IBM Websphere SMF type 103 subtype 2 undoc field.
TYPE103 18.172 Support for IHS WEBSERVER SMF 103 APAR PQ32435.
TYPE103 18.198 Variable BYREADCA negative, now BYREADCA=KBREADCA.
TYPE108 18.119 Support for Domino Server R5.0.3 subtypes 2 and 6.
TYPE110 18.188 INPUT STATEMENT EXCEEDED 110 Journal GLRHTYPE=2.
TYPE110 18.250 CICS STAT STID=126 zero obs in CICCFS6D dataset.
TYPE110 18.276 CICS 1.3 SAP Journal records in CICSJOUR vice CICSSAP
TYPE110 18.313 EXCLUDED FIELDS error message for TS 1.3 in error.
TYPE110 18.314 Support for CICS/TS for z/OS Version 2.1 (INCOMPAT).
TYPE110 18.333 New "Header" exit IHDR110S to skip unwanted STID's.
TYPE115 18.292A Support for MQ Series V5.2 (INCOMPATIBLE)
TYPE116 18.292A Support for MQ Series V5.2 (INCOMPATIBLE)
TYPE120 18.299 Support for Websphere Appl Server Comp Brok SMF 120.
TYPE21 18.026 Support for APAR OW40414, adds four byte fields.
TYPE28 18.032 Support for Tivoli Netview NPM V2R5 new subtypes.
TYPE28 18.254 Support for NPM APAR OW37743 (INCOMPAT if TIC3,3746).
TYPE28 18.257 NPM 28 NPMSUBTY=14x NRT non-fatal MXG messages.
TYPE28 18.273 Support for APAR OW37743 corrected.
TYPE28 18.279 NPM Type 28 Subtype 'DC'x caused INPUT EXCEEDED.
TYPE28 18.308 Support for NPM APAR OW45788 corrects LXETxxxx.
TYPE30 18.001 _Bdddddd list macros were updated for NODUP.
TYPE30 18.286 Init delays SMF30JQT/RQT/HQT/SQT incorrect.
TYPE30 18.344 Some duplicate steps were not removed by NODUP.
TYPE37 18.266 Support for NETVIEW SMF 38 APAR OW45728.
TYPE38 18.015 INPUT EXCEEDED RECORD SMF type 38 record.
TYPE39 18.185 Protection for NETVIEW SMF 39 overlaid ROUTE seg.
TYPE42 18.118 Support for Type 42 RLS Subtype 19 enhanced, fixed.
TYPE42 18.334 TYPE42XR dataset (XRC) was trashed; misaligned INPUT.
TYPE50 18.197 Support for APAR II11493 (INCOMPAT) type 50 SMF.
TYPE6 18.137 Variable CUTSHEET in TYPE6/PDB.PRINT was wrong.
TYPE6 18.274 Short JES3 type 6 record protected.
TYPE64 18.187 Support for APAR OW43854, adds OPENTIME to SMF 64.
TYPE70 18.258 Variable CPCMODEL ('RX6') added to TYPE70.
TYPE7072 18.023 SMF70CIN was reread, didn't remove ICFs.
TYPE7072 18.027 Support for retrofit APAR OW41317 was in MXG 17.17.
TYPE7072 18.120 APAR OW41317 support, INCOMPAT R2.7 or R2.8.
TYPE71 18.199 TYPE71 Memory (Hi,Med,Low Impact Frames) now useful.
TYPE74 18.049 "Broken RMF Record" over-protective, revised.
TYPE74 18.125 Extra observations in TYPE746B (HFG Global Buffs).
TYPE74 18.166 Variables R744Cxxx in TYPE74ST wrong in 2nd segment.
TYPE74 18.261 TYPE74 for PAV had over 100% for PCTDVUSE/ACT/CON/PND
TYPE79 18.004 Type 79 subtype 15 IRLM Long Lock now validated.
TYPE80A 18.024 INPUT STATEMENT EXCEEDED in RACFTYPE=39 segment.
TYPE85 18.055 Support for OAM Release 1.5.0 (INCOMPATIBLE) SMF 85.
TYPE94 18.123 Support for 3494 Peer-to-Peer (Gemini).
TYPE94 18.176 Support for APAR OW45168 confirmed.
TYPEAPAF 18.021 Support for APAF Release 4.6.
TYPEBETA 18.019 Invalid Y2K date now protected in BETA93 records.
TYPEBETA 18.164 Support for BETA93 Release 321 INCOMPATIBLE.
TYPECIMS 18.051 IMF Fast Path INPQUEUE, ARRIVTIME corrected.
TYPECIMS 18.191 New variable PSBNAME was still blank.
TYPECIMS 18.225 Counts in CIMSDB2 and CIMSDBDS wrong after Ch 17.303.
TYPECMA 18.056 Support for CMA Release 1.11 (COMPATIBLE).
TYPECMA 18.142 Subtype 6 variable SMFT06PC incorrect.
TYPEDB1 18.226 Variable JOB in DB2ACCT can be blank.
TYPEDB2 18.003 Support for DB2 6.1 Buffer Pools 100+ in DB2ACCT.
TYPEDB2 18.202 DB2GBPST,DB2STATS some QGBxxxx and QXxxxx vars wrong.
TYPEDB2 18.305 Support for DB2 Version 7.1 (COMPATIBLE).
TYPEDB2 18.348 QWAXxxxx variables now put back in QWACxxxx.
TYPEDCOL 18.224 DCOLLECT sort macros now remove duplicates.
TYPEEDA 18.227 Support for Enterprise Data Access, EDA, SMF record.
TYPEEDGR 18.322 Support for DFSMSRMM 1.5 changes (COMPATIBLE).
TYPEEDGS 18.128 DFSMS/rmm dataset EDGSVREC had blank dataset names.
TYPEEDGS 18.162 Support for DFSMS/rmm TYPEEDGS/TYPEEDGB still wrong.
TYPEEREP 18.183 EREP Symptom Record was incorrectly output.
TYPEFDR 18.351 Support for Innovation Data Processing's FDR SMF.
TYPEFTP 18.141 Variable DVGSBCNT has always been wrong.
TYPEGUTS 18.040 Support for GUTS, Gutenberg Time Sharing, SMF.
TYPEICE 18.136 RECTYPE=5 records were incorrectly output.
TYPEIMSB 18.103 IMS log processing, 18.03 only, IMS 6.1 only, error.
TYPEIMSB 18.139 IMS Log Version 5.1 caused zero obs in IMSTRAN.
TYPEIMSB 18.283 IMS 6.1, MSGSZOUT a constant, wrong value.
TYPEMIM 18.029 Variables labeled and reformatted
TYPEMVCI 18.087 Support for MainView for CICS 5.3.01 (INCOMPATIBLE).
TYPENSPY 18.069 Support for CA's NETSPY 5.3 (COMPATIBLE).
TYPENSPY 18.232 STOPOVER ABEND NETREC='I' with NSPYENTL=124.
TYPENSPY 18.323 Variable TIC_UTIL now created in NSPYTIC3 dataset.
TYPENTSM 18.110 Support for COM Tran Integrator, TN3270 Server, etc.
TYPENTSM 18.143 Support for new NTSMF Objects in Windows 2000 Server.
TYPENTSM 18.193 Support for NTSMF object "SESSION", from Term Svcs.
TYPENTSM 18.245 Support for NTSMF ADSM/ColdFusn/MQSeries/WorldSecure
TYPEOMVT 18.229 Support for Omegamon for VTAM V500 (COMPAT).
TYPEOMVT 18.244 Support for Candle's Omegamon for VTAM TCP record.
TYPEORAC 18.034 Support for Oracle Version 7.3.3 (INCOMPATIBLE).
TYPEORAC 18.133 Oracle CPUTM is revised based on Oracle feedback.
TYPEQACS 18.222 Support for AS/400 Collection Services records.
TYPEQAPM 18.173 Support for OS/400 Release 4.5.0 (INCOMPAT LRECLs).
TYPERMFV 18.326 CSA, ECSA, SQA, ESQA variables calculated.
TYPERMFV 18.349 Support for RMF III for z/OS (COMPAT).
TYPERSDF 18.093 Support for Roger Software Development RSD FOLDERS.
TYPESARR 18.270 SARRU33 records from CA-VIEW subtype 33 corrected.
TYPESHDW 18.247 Support for Neon System's Shadow Server V4.5 SMF.
TYPESHDW 18.311 Support for SHADOW SMF Subtype 6.
TYPESOLV 18.332 Support for SOLVE SMF Subtypes 1 and 2.
TYPESPMG 18.311 Support for DB2 Space Manager 2.1 (INCOMPAT).
TYPESTC 18.035 VTCS 2.2 VTV Timestamps invalid, corrected.
TYPESYNC 18.347 Support for SYNCSORT Release 3.7 (COMPAT).
TYPETCP 18.171 TCP SMF 118 Bad Record INPUT STATEMENT EXCEEDED.
TYPETCP 18.196 Support for APAR PN61399 TCP type 118 SMF.
TYPETLMS 18.355 Support for TLMS 5.5 records; there was no change.
TYPETMDC 18.231 Support for Landmark TMON for DBCTL.
TYPETMS5 18.054 PROC SORTs now have _WTMSTMS/_WTMSDSN for Work copy.
TYPETMV2 18.290 Support for TMON for MVS 2.0 NQ records corrected.
TYPETMVT 18.236 Support for Landmark TMON for VTAM.
TYPETNG 18.337 Support for CA's UNICENTER TNG performance cubes.
TYPEVITA 18.275 Support for Vital Signs VisionNet VSAM file.
TYPEVITA 18.353 Support for Vital Signs VisionNet VSV TCPIP stats.
TYPEWWW 18.327 Support for IBM Domino WebServer Logs enhanced.
TYPEXPTR 18.073 Support Systemware SYSOUT X/PTR, JHS, MPS, and C/QUE
UTILRMFI 18.017 Utility to detect overlap in RMFINTRV workloads.
VMACDB2 18.300 DB2ACCT variable DB2TCBTM included SPAS CPU twice.
VMXGCICI 18.268 CICINTRV DSA size variables corrected.
VMXGCICI 18.278 CICINTRV request for "EOD" did not sum correctly.
VMXGDEL 18.020 You can use (COMPRESS=YES) with MACRO _Ldddddd.
VMXGDUR 18.326 Support for interval specification of MINUTE.
VMXGENG 18.182 New %MACRO to determine the ENGINE of a SAS dataset.
VMXGRMFI 18.009 Using Report PGNs or Reporting Classes didn't work.
VMXGRMFI 18.038 Added COMPAT GOAL SYSx to USECNTRL/USEREPRT
VMXGRMFI 18.062 New RMFINTRV parms KEEPPGN/KEEPRPGN/KEEPSRV/KEEPRSRV
VMXGRMFI 18.088 Using VMXGRMFI with TREND= and PDB=blank corrected.
VMXGSUM 18.182 VIEW used to avoid physical I/O, can be big savings.
VMXGSUM 18.326 Support for interval specification of MINUTE.
VMXGUOW 18.204 New %MACRO to support ASUMUOW revisions.
VMXGUOW 18.281 Logic errors corrected.
WEEKBLD 18.135 WEEKBLD and MONTHBLD had wrong BY for TYPE30MU.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 18.
======Changes thru 18.360 were in MXG 18.18 dated Feb 12, 2001======
Change 18.360 Support for IBM's free MOUNTMON tape mount and allocation
EXMOUNTM monitor creates the new MOUNTMON dataset from either the
TYPEMOUN flat file or the SMF record. Support for this monitor
TYPSMOUN was prompted by concerns that the MXG Tape Mount Monitor
VMACMOUN was missing fast, scratch Virtual Tape mounts, and if the
VMXGINIT IBM freebie did better, I was prepared to restructure the
Feb 11, 2001 ASUMTAPE logic to use their record instead of ASMTAPE's
TYPFMOUN SMF record, but the initial comparison with three day's
data with both monitors running showed MOUNTMON saw 462
mounts with 1 second sampling and MXGTMNT saw 452 with 2
second default sampling, so I'm greatly encourages that
no errors are seen in MXGTMNT capture of mounts. However
as the IBM monitor captures Device Pend/Dis/and Connect
times, I will evaluate an enhancement to combine both
monitor's data and improve the quality of MXG measurement
of tape mounts and tape drive usage. The IBM MOUNTMON
monitor is written and supported by Dennis Haight, and is
available at ftp://ftp.software.ibm.com/storage/tapetool/
-Member TYPFMOUN processes the flat file when MOUNTMON is
not writing to SMF.
Thanks to Mike Shapland, (i)Structure, USA.
Change 18.359 This analysis of the new z/OS MSU capacity was provided
ANALMSU by Alan Sherkow. See the text of Change 18.298 for the
Feb 11, 2001 discussion of PDB.RMFINTRV's new MSU4HRAV variable that
measures your current capacity in Millions of Service
Units (per hour) for License Manager pricing.
Thanks to Al Sherkow, I/S Management Strategies Ltd, USA.
Change 18.358 My QA stream reports variables with blank labels, but now
DOC I've actually used it to clean up labels in these members
Feb 11, 2001 ASUMCACH ASUMTAPE ASUMVMON CHANGES TYPEIMS TYPETMS5
VMAC30 VMAC42 VMAC50 VMAC90A VMAC91 VMACBGSI
VMACGUTS VMACHURN VMACIMS VMACNTSM VMACRSDF VMACSTC
VMACTMDB VMACTMS5 VMACTMV2 VMACTNG VMACVITA VMACXPTR
VMXGRMFI. These member's update date was updated but
the last change referenced is the prior change.
Change 18.357 Eight TMS flag variables from the TMSREC record are now
TYPETMS5 propagated into the pseudo TMSDSNB observation created
VMACTMS5 from the TMSREC. The DSNBssss suffixes updated are
Feb 11, 2001 DSNBUSRU/TMSI/ECAT/ABND/ISCA/DFXU/WSCA/DFLT (into DSNB)
UPD/ETM/CAT/ABN/FILEISCA/DEFEXPOO/E99/DEF (from TMS).
New DEVTYPE values for Redwood, STK 9842 and 3590E are
created from TRTCH values of E4-E7 and EA-EB.
Thanks to David Ehresman, University of Louisville, USA.
Change 18.356 SAS SMF record pads SASPROC with '00'x instead of blank,
VMACSASU causing SASPROD to be UNKNOWN because the $MGSASPR table
Feb 9, 2001 expected blanks. SASPROC= TRANSLATE(SASPROC,' ','00'x);
was added to convert the '00'x to blank (and note that
a blank, rather than '40'x is used so the code will work
under either ASCII or EBCDIC) before the create of:
SASPROD=PUT(SASPROC,$MGSASPR.);
Thanks to Jim Peddycord, The Northern Trust Company, USA.
Change 18.355 Support for TLMS 5.5 records; there were no changes to
TYPETLMS the record or to MXG; this is just for documentation.
Feb 9, 2001
Change 18.354 Collected updates and new features added.
ASUMCACH -ASUMCACH added KEEPALL=YES, ID=DEVICE and the logic to
ASUMSMFI keep only DASD devices; tape devices were reported.
FORMATS -New ASUMSMFI summarizes PDB.SMFINTRV, keeping only the
VMXG2DTE variables needed for problem solving and accounting.
ASUM23 -New format MGPCTGR is used to print horizontal graphs in
TRND23 DB2 reporting.
ASUMVMNT -New VMXG2DTE macro is self-documenting and provides the
TRNDVMNT creation of week-to-date and month-to-date summarization.
ASUMVTVM The algorithms can interleave or APPEND the output.
ADOCUOW -Summarization and trending of TYPE23 (SMF activity) is
Feb 12, 2001 provided in the new ASUM23/TRND23 members
-Summary of VSM recall and migrate activity by hour from
STCVSM19 records is provided in new ASUMVTVM member.
-Summary of VSM mount activity is summarized in ASUMVMNT
and TRNDVMNT from STCVSM13 records.
-Revision of documentation for large volume CICS/DB2 shows
how best to set up VMXGUOW processing, in member ADOCUOW.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 18.353 Support for Vital Signs VisionNet Record created new MXG
EXVITATC dataset VSVTCPIP with VSV TCPIP Interface Stats, but
IMACVITA there will be additional datasets created from their VSAM
TYPEVITA file.
TYPSVITA
VMACVITA
Feb 8, 2001
Thanks to Craig Collins, State of Wisconsin IT Services, USA.
Change 18.352 Running MXG under ASCII SAS to create DB2ACCT dataset did
VMACDB2H not convert the NETSNAME to ASCII, so you could not match
Feb 8, 2001 the DB2 plan back to its CICS transaction.
Thanks to Mark Cohen, DTS, ITALY.
Change 18.351 Support for Innovation Data Processing's FDR user SMF
EXFDRDSF record creates new FDRDSF dataset with an observation for
FORMATS each FDR event.
IMACFDR
TYPEFDR
TYPSFDR
VMACFDR
VMXGINIT
Feb 8, 2001
Thanks to Shawn Beardsley, NDC Health Information Services (AZ), USA.
Change 18.350 Cosmetic. Labels were missing for variables in VMACDB2
VMACDB2 (PLAN,TRAN), in VMAC28(NRTDTYPE), in VMXGRMFI(CECSUSEC),
VMAC28 VMAC42(SMF42NRS), and VMAC74(SMF74CNF,SMF74CNX). Labels
VMXGRMFI for CSFRxxAV and ESFRxxAV that didn't have AVE, now do.
VMAC42
Feb 7, 2001
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 18.349 Support for RMF III changes for z/OS COMPATIBLY added a
EXZRBCPU few fields, and three previously undecoded segments are
EXZRBCSR now decoded to create these three new datasets:
EXZRBPGP ZRBCPU - Processor
IMACRMFV ZRBCSR - Common Storage Remaining
VMACRMFV ZRBPGP - Performance Group Period
VMXGINIT This change also added the CSA/ECSA/SQA/ESQA variables in
Feb 5, 2001 Change 18.325. Many variables are still the accumulated
value, and have not been divided by their sample count.
Please validate that the variables of interest to you do
match their RMF III screen values, and let me know if you
find any needed corrections for MXG variables.
Thanks to Thom Kight, Fidelity Systems, USA.
Change 18.348 MXG created QWAXvvvv variables in DB2ACCT from the new
VMACDB2 QWAX segment, but I failed to realize that most of those
Feb 5, 2001 QWAX fields were existing QWACvvvv variables, with some
new QWAX fields. Instead of extending QWAC, IBM created
the new QWAX segment; if it exists, your QWAC fields are
all zero. I should never have created the QWAXvvvv names.
So this change now stores the QWAXvvvv values in QWACvvvv
variables that exist, and creates new QWACvvvv variables
for the new QWAX fields.
I should DROP the QWAXvvvv variables now, but I can't do
that without warning, as those few of you who found the
QWAX variable names would have reports failed, so this is
your warning: Do Not use QWAXvvvv variable names.
Use their QWACvvvv counterpart instead.
Variable names starting with QWAXvvvv will go away soon!
And if you want to drop them now, with this change, you
can use the _KDB2ACC macro to drop them, with:
MACRO _KDB2ACC DROP=
QWAXALCT QWAXALOG QWAXANAR QWAXARNC QWAXARND QWAXAWAR
QWAXAWCL QWAXAWDR QWAXOCSE QWAXSLSE QWAXDSSE QWAXOTSE
QWAXOCNS QWAXSLNS QWAXDSNS QWAXOTNS
QWAXAWFC QWAXFCCT QWAXIXLE QWAXIXLT
QWAX fields so your existing and future programs work
with the same QWACvvvv names in your future reports, and
this change accomplishes that: use QWACvvvv instead of
QWAXvvvv in any reports you write.
QWAXxxxx variables should not have been created at all,
but since I can't safely DROP them without warning, here
is your warning:
Don't USE DB2ACCT variables named QWAXxxxx;
Instead, use QWACxxxx with the same suffix
Thanks to Alan Winston, MBNA,USA.
Change 18.347 Support for SYNCSORT Release 3.7 (COMPAT) adds variables.
VMACSYNC SYNCSORT now permits up to 100 SORTWORK DDs, so VMACSYNC
Feb 8, 2001 can creates up to 100 sets of variables for each sort
work area, but the MXG default is 32, previously the max
that SYNCSORT allowed. You can increase the number of
sets of variables if you have more than that:
-You can change it permanently by adding this statement in
your IMACKEEP member to re-definite the default value:
MACRO _NSYNCWK 100 %
-Or, to increase it just for this execution of TYPSSYNC,
you can change it "Instream" with this in your //SYSIN:
%LET MACSYNC= MACRO _NSYNCWK 99 % ;
(you can track variable NRWRKUSE in TYPESYNC to see if
more than 32 sort works are being used).
Note: Dec 2001: The DDnames are SORTWK00-SORTWK99, but
SAS will start with SORTWK01 and not use SORTWK00.
Thanks to Chuck Hopf, MBNA,USA.
Change 18.346 ASUMTALO could have MAXDRVS greater than installed drives
ASUMTALO when tape drives are switched between systems, because of
Feb 3, 2001 slightly different timer pops on different systems. One
event with ALOCEND=11:22:05.79 on SYSA was followed by an
event with ALOCSTRT=11:22:05.60 on SYSB. The overlap is
always less than the monitor interval (2 second default);
code inserted into an existing step now detects any such
overlap and resets the ALOCSTRT to the previous ALOCEND.
Thanks to Bruno Peeters, Dexia, BELGIUM.
Change 18.345 The High/Med/Low Impact Average Frame variables are now
VMXGRMFI MAX'ed for each interval and added to PDB.RMFINTRV. The
Feb 2, 2001 variables that are added are these:
CSFRSRAV CSFRWLAV CSFRFXAV CSFRLSAV CSFRTOAV CSFRAVAV
CSFRHIAV CSFRLOAV CSFRMEAV ESFRSRAV ESFRWLAV ESFRHSAV
ESFRLSAV ESFRTOAV ESFRAVAV ESFRHIAV ESFRLOAV ESFRMEAV
Thanks to Peter Smith, SEMA, ENGLAND.
Change 18.344 Some duplicate steps were not removed by PROC SORT NODUP
VMAC30 because the BY list did not force adjacency if there was
Feb 1, 2001 a real step and a flushed step with the same TERMTIME.
Variable INITTIME was needed at the end of the BY list
defined in MACRO _BTY30U4.
Thanks to Michael Oujesky, MBNA, USA.
Change 18.343 MXG 18.12 only. Typo in label had *' instead of * in
VMACIAM one label in this (fortunately) seldom-used code; typo
Jan 31, 2001 was made incorrectly after final QA.
Change 18.342 Variables CSFRLSAV and ESFRLSAV were incorrect; parens
VMAC71 were missing. The correct equations are:
Jan 31, 2001 CSFRLSAV=CSTORE-(CSFRTOAV-CSFRFXAV);
ESFRLSAV=ESTORE-(ESFRTOAV-ESFRHSAV);
Thanks to Peter Smith, Sema plc, ENGLAND.
======Changes thru 18.341 were in MXG 18.12 dated Jan 30, 2001======
Change 18.341 A short first record in the Catalog Export's output file
VMACCTLG caused notes on the log, but no error. The record is now
Jan 30, 2001 decoded and the time stamp text string is printed on log.
Thanks to Len Rugen, State of Missouri Department of Education, USA.
Change 18.340 BETA93 variable JESNR was missing for JOB/TSU/STC. Add
VMACBETA ELSE DO;
Jan 29, 2001 JESNR=INPUT(SUBSTR,JCTJOBID,4,5), ?? 5.);
END;
in two places so JESNR will be populated.
Thanks to Klaus Messer, COMLAB GmbH, GERMANY.
Change 18.339 Divide by zero protected in two places in this analysis
ANALCACH example.
Jan 29, 2001
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.338 New MXG enhancement defines new MACRO _Vdddddd that
DOC lets you use this simple and straightforward syntax:
Jan 28, 2001 %LET MACKEEP= MACRO _Vdddddd KEEP= A B C % ;
(or you can put that MACRO _Vdddddd in member IMACKEEP)
to KEEP only those variables want kept in an MXG dataset!
The original design of the _Kdddddd macro will still
be supported (documented in DOCMXG), but that syntax
still requires you to list those variables that you do
not want to keep, using a DROP= statement; kludgy!
This change moves the text of the KEEP= and its list from
inside the _VARxxxx macro into a new _Vdddddd for each
MXG dataset, and the syntax of the _VARxxxx definition
was changed to use that new _Vdddddd token:
_Wddddddt (LABEL='THE*LABEL*FOR*THE*DATASET'
_Vdddddd _Kdddddd )
While being easy to use, the new _Vdddddd will also truly
keep only what you want; using _Kdddddd to DROP variables
only drops variables you listed; all new MXG variables
(a new release of CICS?) will be kept in your output data
set until you edited your DROP= list.
You can put the MACRO _Vdddddd definitions in IMACKEEP
if you ALWAYS want only those variables kept in that data
set, or you can tailor a job in its //SYSIN "instream",
so the macro changes only what's created by that job.
Using the CICSTRAN dataset as an example, you look up the
"dddddd" dataset-suffix name in the IMACxxxx member for
the TYPExxxx product, so IMAC110 tabulates the dddddd for
each MXG dataset built from the type 110 SMF record. The
IMAC110 member show you that "CICTRN" is the dddddd name
for the "CICSTRAN" dataset, so this instream tailoring
creates CICSTRAN.CICSTRAN with only three variables kept:
//SYSIN DD *
%LET MACKEEP=
MACRO _VCICTRN KEEP= APPLID TRANNAME TASCPUTM% ;
;
%INCLUDE SOURCLIB(TYPE110);
This is an internal text change inside VMAC members, and
it should be transparent to your existing tailoring.
Since datasets with lots of variables are the ones most
likely to need KEEP= tailoring, datasets with the most
variables were revised first; most have been enhanced but
not all MXG members were finished when 18.18 was ready.
These members that already defined an _Vxxxxxx macro were
set aside to be examined later:
TYPEAXC,TYPECMA,TYPEFTP,TYPEICE,TYPEIMS1,TYPEOMCI,
TYPEPW,TYPEQACS,TYPEQAPM,TYPEQTRT,TYPETUX,TYPEVMXA,
TYPEXAM,TYPE102,TYPE28,TYPE79,TYPE84
Change 18.337 Support for CA's UNICENTER TNG performance cubes data for
EXTAI001- AIX, CISCO, WIN-NT, and SOLARIS platforms creating these:
EXTAI005 MXG
EXTC2001- Platform Object Max Max Max DATASET
EXTC2002 Instance Vars Rows NAME
EXTC7001 AIX411: BUFFER 1 8 95 AI001
EXTNT001- CPU 1 5 95 AI002
EXTNT020 PAGING 1 4 95 AI003
EXTSO001- QUEUES 1 4 95 AI004
EXTSO015 SWAPPING 1 1 95 AI005
FORMATS CIS2500: CISCO 7 130 76 C2001
IMACTNG MIB-2 34 89 76 C2002
VMACTNG CIS7500: CISCO 24 166 76 C7001
TYPETNG NTS400I: BROWSER 1 20 95 NT001
TYPSTNG CACHE 1 27 95 NT002
UTILTNGO ICMP 1 27 95 NT003
VMXGINIT IP 1 17 95 NT004
Jan 28, 2001 LOGICALDISK 5 21 95 NT005
MEMORY 1 27 140 NT006
NBT CONNECTION 8 3 95 NT007
NETBEUI 2 39 71 NT008
NETBEUI RESOURCE 13 3 71 NT009
NETWORK INTERFACE 3 17 140 NT010
OBJECTS 1 6 95 NT011
PAGING FILE 2 2 140 NT012
PHYSICALDISK 3 19 140 NT013
PROCESSOR 2 10 95 NT014
REDIRECTOR 1 37 95 NT015
SERVER 1 26 140 NT016
SERVER WORK QUEUES3 17 140 NT017
SYSTEM 1 25 140 NT018
TCP 1 9 95 NT019
UDP 1 5 95 NT020
SOL240S: BUFFER 1 8 12 SO001
CPU 1 5 12 SO002
DISK 3 6 12 SO003
FILE-ACCESS 1 3 12 SO004
FILESYSTEM 2 3 12 SO005
IPC 1 2 12 SO006
KERNEL MEMORY ALLOC1 8 12 SO007
MEMORY 1 2 12 SO008
NETWORK 5 5 12 SO009
PAGING 1 11 12 SO010
QUEUES 1 4 12 SO011
SWAPPING 1 5 12 SO012
SYSTEM-CALLS 1 7 12 SO013
TABLES 1 7 12 SO014
TERMINAL 1 6 12 SO015
The dataset names in this implementation are structured:
Dataset Name: PPOOO
WHERE PP= Platform Type 2-Character Abbreviation:
AI=AIX411 C2=CIS2500 C7=CIS7500
NT=NTS400I SO=SOL240S
OOO= Object Number within Platform (see above)
Variable Name: PPOOOVVV
VVV= Variable (metric) number within object.
The Label for each MXG dataset is the Object Name; the
Label for each MXG variable is the Metric Name. Use the
PROC CONTENTS DATA=PDB._ALL_ DETAILS; to display what is
what in the AInnn,C2nnn,C7nnn,NTnnn and SOnnn datasets.
This is a departure from MXG variable naming. Most MXG
names are abbreviations for what it is, but these names
are all cryptic, except for the common BY variables of
PLATFORM SYSTEM INSTANCE and STARTIME. If it turns out
that having "real MXG variable names" is needed, perhaps
to match existing variables from other data sources, an
optional rename with PROC DATASETS will be developed.
New metrics/platforms/objects are easy to add; MXG notes
new objects and metrics on the log, telling you to run
UTILTNGO program, and email me the report and the OBJECTS
dataset. I can create the needed code from those files.
The next major enhancement to TNG support (2nd Quarter?)
will make the processing of TNG data completely dynamic:
I will only create datasets for those objects that had
data in the input file, and will only keep variables for
metrics that were found in the input file. That will
minimize the space required and remove the clutter of the
un-measured variables, and the completely new algorithms
in this support were designed with that intention.
Standard MXG PDB:
You will continue to have the option of building the
standard all-variable all-datasets PDB library from TNG
data, so your PDB libraries are consistent, with missing
values in variables that were not measured, and with
zero observations in datasets for objects that were not
found in today's data.
Dynamic MXG PDB:
You can tell MXG to construct the datasets and variables
that were found in today's input data stream, using only
the amount of storage and processing to be determined by
the data stream.
This architecture is extendable to other data sources
that have one row of raw data describing the object and
the metric followed by that one column of data values.
-Over a year ago, Roman Jost tried to convince me that
TNG was a find source of data, and sent me code that
read the TNG data, but it took me a year to finally
realize how I could write supportable code. This
development was actually triggered by a phone call
after CMG from the mid-west insurance company that had
written a C-program to "decode the performance cube
data". I had all along assumed that some API-issuing C
program or a vendor-provided utility was needed to read
the data, but when I realized this C program read a
flat file and wrote a flat file, and then actually
looked at a faxed dump of three records, I saw that the
raw data could be processed with SAS.
-My first pass took two days, and I read each record to
create one dataset for each variable, outputting an obs
for each data value, and then merged those datasets
together to create a dataset per object. I tested the
prototype with an NT cube with four objects and twenty
metrics, and the logic performed as designed.
-Then I wrote a SAS utility to generate all of the SAS
statements I would need to create a dataset for all of
the other objects and variables in all cubes for five
platforms, executed the generated code, and it worked.
However, with a small performance cube (64KB in size),
the program used 330 MegaBytes of disk storage and 10
minutes to create those 800+ datasets!
-Examining the structure of these data, I realized that
with fairly limited numbers of observations and limited
numbers of objects in one single input cube, arrays to
store a single performance cube was all that was needed
and that generated names for variables and datasets was
the best solution for this type of data structure; at
the end of each input cube, one dataset per object is
created, containing all of that object's metrics, so
there are 44 datasets created, one per object.
-The final run with multiple input of 24 daily cubes, at
15 minute intervals, 10,000 records, 6.6MB of raw data,
now took 25 seconds (12 to read and create datasets,
and 13 seconds to sort them into the PDB), used 17MB of
disk work space, with less than 6MB virtual storage for
all arrays, so the algorithm should scale well as new
objects and metrics are added in the future. The MXG
output PDB library was 6MB of disk for 24 days data,
using COMPRESS=YES under Win98 on a 500MHz Pentium III.
COMPRESS=NO took 2 seconds longer, needed 37MB for
work space and created a 12MB PDB on disk; I've
previously reported that COMPRESS=YES saves time and
disk space on Pentium architecture.
Change 18.336 -Device Number variables STC13DID/STC14DID are character
VMACSTC variables formatted with $HEX4., which do not translate
Jan 24, 2001 correctly between EBCDIC and ASCII platforms. New DEVNR
variable is created as numeric and formatted HEX4., so it
matches DEVNR in other MXG datasets like TYPE74.
See Newsletter "Executing SAS on PCs and Workstations"
-STC does not store anything into the channel interface
name field, variable STC11INM, so we will now store the
channel interface number as a character in STC11INM with:
IF STC11INM LE ' ' THEN STC11INM=PUT(_I_,8.);
so that if they change their mind and store a value in
the future, you'll get it, but for now, we need to sort
by STC11INM. (The LE ' ' catches both blanks and hex
zeros).
Thanks to Chuck Hopf, MBNA, USA.
Change 18.335 Testing statement PUT RTYPE= $HEX2.; should have been
VMACNAF deleted, and now it is. Only impact was a large SASLOG.
Jan 24, 2001
Thanks to Robert A. Brown, Arthur Anderson, USA.
Change 18.334 XRC dataset TYPE42XR had trash; the INPUT was misaligned.
VMAC42 The following INPUT statement was inserted before the
Jan 23, 2001 existing DO statement in member VMAC42:
INPUT @S42XRSSO @;
DO _I_=1 TO S42XRSSN;
Thanks to John Nalesnik, The Prudential, USA.
Thanks to Brenda Rabinowitz, The Prudential, USA.
Change 18.333 New "Header" exit IHDR110S for the CICS 110 Statistics
IHDR110S STID segments allows you to skip unwanted subsubtypes
VMAC110 and thereby save CPU time for the INPUT statements, if
Jan 22, 2001 you only want to output one or a few STID's (like STID=25
a year's CICLDR observations). See IHDR110S comments;
you simply set variable STIDWANT to 1 or zero, using:
IF STID =25 THEN STIDWANT=1;
ELSE STIDWANT=0;
or
IF STID IN (1,5,9, ..) THEN STIDWANT=1;
ELSE STIDWANT=0;
to skip unwanted STID segments, you should also throw
away the unwanted subtype 1 transaction record and other
unwanted statistics subtypes using the MACFILE tailoring:
%LET MACFILE= %QUOTE (
IF ID=110 ;
IF SUBTYPE=2;
);
so only (in this case) subtype 2 records, which contain
subsubtype 25 records, are input past the SMF header.
Note these mappings of subtypes to STID's:
0 - Journal
1 - Transaction, Exception, Dictionary
2 - Statistics - all other STIDs
3 - Statistics - STIDs 121,122,123
4 - Statistics - STIDs 126, 127, 128, 129
5 - Statistics - STIDs 124, 125
Change 18.332 Support for Solve SMF subtypes 1 and 2 create new dataset
EXTYSOL1 TYPESOL1 for FTS File Send/Receive.
FORMATS
IMACSOLV
VMACSOLV
VMXGINIT
Jan 20, 2001
Thanks to Aubrey Tang, Westpac Banking Corporation, AUSTRALIA.
Change 18.331 Validation of Shadow SMF subtype 6 changed variable
VMACSHDW SM06SQSR from numeric to variable length 32000 if under
Jan 19, 2001 V8 with COMPRESS=YES, or will be broken down into 100
byte pieces and output in multiple records (with resource
counts set to missing values in the SM06SEGN=2nd and
subsequent observations). All test records had SQL text
truncated at byte 255, with the rest of the SM06SQLN
bytes filled with hex zeroes. That may be an error or
an installation choice; it is under investigation, but
MXG prints one instance if found.
Thanks to Chris Morgan, IBM Integrated Technology Services, ENGLAND.
Change 18.330 Character strings (SQL text) greater than 100 bytes long
VMAC102 were truncated to 100 bytes if run under SAS V8 without
Jan 19, 2001 COMPRESS=YES. The tests to decide to break the long text
into 100 byte chunks was IF &SASVER GE 7 THEN DO; but
that was changed to IF &SASCHRLN LE 100 THEN DO; because
the &SASCHRLN length is set greater than 100 only if both
SAS V8 is being used AND COMPRESS=YES is used.
Change 18.329 The DB2 Accounting Summary report is enhanced to match
ANALDB2R the DB2 Version 6 DB2PM reports.
Jan 18, 2001
Jan 30, 2001
Change 18.328 The MQIN view/dataset was not deleted at the end of the
VMXGUOW program, causing no error, but inconsistent with MXG's
Jan 17, 2001 deleting of temporary datasets from the work file.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 18.327 IBM Domino WebServer logs are readable with TYPEWWW code,
TYPEWWW but the statement FULLURL=SUBSTR(FULLURL,1,LOC-1); was
Jan 16, 2001 changed to FULLURL=SUBSTR(FULLURL,1,LOC-10). Without the
change, variable FULLURL contained the URL plus the
variable HTTPCLVS.
Thanks to Greg Meyer, Isuzu Motors, USA.
Change 18.326 Interval specification of MINUTE are now supported in the
ANALCNCR VMXGSUM, VMXGDUR, and ANALCNCR functions, if you need the
ASUMTALO minute details. Hardcode INTERVAL=HOUR and divides by
VMXGDUR 3600 were replaced with _TALOINT and _TALOSECS macros
VMXGSUM that can be changed to MINUTE and 60 to get minutes.
Jan 15, 2001
Thanks to Luc Mattheus, DEXIA Bank, BELGIUM.
Change 18.325 Variables CSA, ECSA, SQA, and ESQA are now calculated in
VMACRMFV the RMF Monitor III dataset ZRBASI to track the sizes of
Jan 15, 2001 those memory areas allocated to each ASID/JOB, and the
variables GEICSAAS and GEISQAAS are divided by samples.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 18.324 Invalid data for RMGTSHTR (CICS Statistics) is because
VMAC110 the MSEC8. format still does not support values greater
VMACTMDB than 24 hours. I thought I had replaced all uses of the
Jan 12, 2001 MSEC8. informat with &PIB.8.6 and a divide by 4096, back
in Change 12.030, a few MSEC8 crept back in the IBM CICS
and the Landmark DB2 code. All have been replaced.
Thanks to Roman Jost, Gjensidige, NORWAY.
Change 18.323 Variable TIC_UTIL is now created in the NSPYTIC3 dataset.
VMACNSPY
Jan 11, 2001
Thanks to Tom Neurauter, Fidelity Investments, USA.
Change 18.322 Support for DFSMSRMM 1.5 changes (COMPATIBLE, new fields
EXEDGRK were added at end, new subtype added):
IMACEDGR -Dataset EDGRDEXT (DSN Record) new variables:
VMACEDGR RDVRSSCH='PRIMARY*VRS*SUBCHAIN'
VMXGINIT RD2VJBN ='SECONDARY*VRS*JOBNAME*MASK'
Jan 9, 2001 RD2VNME ='SECONDARY*VRS*NAME*MASK'
RD2VSCH ='SECONDARY*VRS*SUBCHAIN*NAME'
RD2VXDS ='SECONDARY VRS*SUBCHAIN*START DATE'
RDVRSXDS='PRIMARY*VRS*SUBCHAIN*START DATE'
-Dataset EDGRVEXT (VOL Record) new variables:
RVCONTNR='IN*CONTAINER*NAME'
(appears to be updated only for exported tapes).
RVRQPRTY='MOVEMENT*PRIORITY'
-New dataset EDGRKEXT created from new type K record.
RKCOUNT ='VITAL RECORD COUNT'
RKCRDATE='VITAL*RECORD*CREATE*DATE'
RKCRSID ='CREATE*SYSTEM*ID'
RKCRTIME='VITAL*RECORD*CREATE*TIME'
RKCRTJBN='JOBNAME'
RKDELAY ='DAYS*DELAY*BEFORE*SELECTION'
RKDELDAT='DATE VRS*IS TO BE*DELETED*BY RMM'
RKDESC ='DESCRIPTION'
RKDSNAME='DATA*SET*NAME'
RKDSNG ='DATASET*NAME*MASK IS*GDG?Y/P/N?'
RKGENKEY='DSET/VOL*GENERIC*CHARACTERS?'
RKLCDATE''LAST*CHANGE*DATE'
RKLCSID ='LAST*CHANGE*SYSTEM ID'
RKLCTIME''LAST*CHANGE*TIME'
RKLCUID ='LAST*CHANGE*USER ID'
RKLOC ='NAMEAOF LOCATION TO BE STORED'
RKLOCTYP='LOCATION*TYPE?*A/M/S/ '
RKNAME ='VRS*NAME'
RKNEXT ='NAMEAOF NEXT VRS IN THE CHAIN'
RKOWNER ='VITAL*RECORD*OWNER'
RKRETNC ='RETAIN*BASED ON*CYCLES?'
RKRETND ='RETAIN*BASED ON*ELAPSED DAYS?'
RKRETNR ='RETAIN*BASED ON*UNREFERENCED DAYS?'
RKRETNW ='RETAIN*ONLY WHILE*CATALOGED?'
RKRETNX ='RETAIN*UNTIL*EXPIRED?'
RKSTNUM ='STORE KEEP NUMBER'
RKTYPE2 ='VRS*TYPE*V=VOL*D=DSET*N=NAME'
RKVOLSER='VOLUME*SERIAL'
Thanks to Carl Kyonka, Enbridge, CANADA.
Change 18.321 Warning that variable RPRTCLAS was duplicated in an ID
TRND72GO argument was valid, but of no impact. RPRTCLAS was added
Jan 9, 2001 to the SUMBY= by Change 18.189 but should have also been
removed from the ID= argument. Now it is.
Change 18.320 MXG 18.06-MXG 18.10, and only if VMXGSUM was called twice
BLDNTPDB with &DDNAME as an input argument (we found it only in
VMXGSUM BLDNTPDB and only in the LDSK report). Change 18.182
Jan 9, 2001 added a call to new %VMXGENG (to determine the SAS engine
that created the input dataset), but used DDNAME for a
temporary macro, and then changed its value. This change
eliminates the use of DDNAME inside VMXGSUM. There was no
change made to member BLDNTPDB.
Thanks to Terry Heim, ECOLAB, USA.
Change 18.319 The calculation of Standard Deviation was incorrect;
TRNDCICS the logic from TRNDCICX was imported into TRNDCICS.
Jan 9, 2001
Change 18.318 The SORT FIELDS= value in JCLIMSL5 should have been
JCLIMSL5 SORT FIELDS=(1,12,A,35,8,A,29,1,A),FORMAT=BI
Jan 9, 2001 The change was made in JCLIMSL6 but not in L5.
Thanks to Roman Jost, Gjensidige Gruppen, NORWAY.
Change 18.317 Support for z/OS R1.1 (COMPATIBLE).
VMAC7072 TYPE70: New z/OS metrics for this CPU/SYSTEM:
VMXGRMFI CPUADJCH='PHYSICAL*CPU*ADJ FACTOR*CHANGED?'
Jan 5, 2001 Changed only by Capacity Upgrade on Demand.
Jan 20, 2001 SUAVAICH='SU*AVAILABLE*CHANGED?'
SMF70CPA='SU_SEC*OF THE*PHYSICAL*CEC'
SMF70LAC='IBM*4-HR*AVERAGE*HOURLY MSU'
SMF70WLA='Defined*Capacity*SU*Available'
TYPE70PR: New z/OS metrics for each LPAR segment:
LPARCLND='CAPACITY*LIMIT*NOT*DEFINED?'
LPARDCLC='DEFINED*CAPACITY*LIMIT*CHANGED?'
LPARWLMG='WLM*MANAGEMENT*OF THIS*LPAR?'
LPARWTFD='WAIT*TIME*FIELD*DEFINED?'
SMF70MSU='DEFINED*CAPACITY*LIMIT*IN MSU'
SMF70NSA='PCT WHEN*AT MAXIMUM*PARTITION*WEIGHT'
SMF70NSI='PCT WHEN*AT MINIMUM*PARTITION*WEIGHT'
SMF70NSW='PCT WHEN*LPAR WAS CAPPED*BY WLM'
SMF70ONT='LPAR*ONLINE*TIME'
SMF70PMA='AVERAGE*IRD*ADJUSTED*PARTITION*WEIGHT'
SMF70WST='LPAR*WAIT*TIME'
RMFINTRV: Variables from TYPE70 now maxed into RMFINTRV:
SMF70LAC='IBM*4-HR*AVERAGE*HOURLY MSU'
SMF70WLA='MAX SU*AVAILABLE*TO MVS*IMAGE'
Additional z/OS changes:
New TYPE74 Subtype 7 FICON Director - await test data,
will be supported ASAP, new MXG dataset(s) to be.
New TYPE99 Subtype 8 LPAR CPU Management - no data.
Similar to subtype 2, will decode upon request.
New TYPE99 Subtype 9 Dynamic Channel Path Management.
Have data, will decode upon request.
Type 78.1 documentation was removed.
Type 79.13 documentation was removed.
MXG support is based on pre-GA documentation, and there
may be differences in the GA level of the product.
Change 18.316 The null macro _NSHDW was incorrect and if you tried to
VMACSHDW use it, you got a strange "180" error about "WORK".
Jan 4, 2001
Thanks to Wayne A. Schumack, Blue Cross Blue Shield of Minnesota,USA.
======Changes thru 18.315 were in MXG 18.11 dated Jan 3, 2001======
Change 18.315 Documentation of the Internal Logic of the MXG PDB. This
DOCPDB was presented as a 3-hour Workshop prior to CMG 2000.
Jan 3, 2001
Change 18.314 Support for CICS TS for z/OS Version 2.1 (INCOMPAT):
EXCICEJR As usual, while there's some interesting new metrics that
EXCICIIR IBM added to the CICSTRAN record, they inserted those new
EXCICSJG fields (instead of adding them at the end of the segment)
EXCICSOG so you MUST install this change to process 2.1 records.
EXCICSOR -Dataset CICSTRAN - New variables inserted:
IMACCICS JVMITICN='CICS JVM*INITIALIZE*ELAPSED*COUNT'
VMAC110 JVMITITM='CICS JVM*INITIALIZE*ELAPSED*TIME'
VMXGINIT JVMRTICN='CICS JVM*RESET*ELAPSED*COUNT'
Jan 3, 2001 JVMRTITM='CICS JVM*RESET*ELAPSED*TIME'
Jan 28, 2001 KY8CPUCN='USER-TASK*KEY 8*TCB CPU*COUNT'
KY8CPUTM='USER-TASK*KEY 8*TCB CPU*TIME'
KY8DISCN='USER-TASK*KEY 8*TCB DISPATCH*COUNT'
NETID ='NETWORK*QUALIFIED*NAME*NETWORK ID'
OTSINDCN='OTS*INDOUBT*WAIT*COUNT'
OTSINDTM='OTS*INDOUBT*WAIT*TIME'
OTSTID ='OTS*TRANSACTION*ID*(TID)'
PORTNUM ='TCP/IP*SERVICE*PORT*NUMBER'
RLUNAME ='NETWORK*QUALIFIED*NAME*NETWORK*NAME'
RQPWAICN='REQUEST*PROCESSOR*WAIT*COUNT'
RQPWAITM='REQUEST*PROCESSOR*WAIT*TIME'
RQRWAICN='REQUEST*RECEIVER*WAIT*COUNT'
RQRWAITM='REQUEST*RECEIVER*WAIT*TIME'
SOCHRIN ='SOCKET*CHARACTERS*RECEIVED'
SOCHROUT='SOCKET*CHARACTERS*SENT'
SOCNPSCT='CREATE*NON-PERSISTENT*SOCKET*REQUEST'
SOCPSCT ='CREATE*PERSISTENT*SOCKET*REQUEST*COUNT'
SOEXTRCT='SOCKET*EXTRACT*REQUEST*COUNT'
SONPSHWM='NON-PERSISTENT*SOCKET*HIGH-WATER-MARK'
SOOIOWCN='OUTBOUND*SOCKET*I/O*WAIT*COUNT'
SOOIOWTM='OUTBOUND*SOCKET*I/O*WAIT*TIME'
SOPSHWM ='PERSISTENT*SOCKET*HIGH-WATER-MARK'
SORCVCT ='SOCKET*RECEIVE*REQUEST*COUNT'
SOSENDCT='SOCKET*SEND*REQUEST*COUNT'
SOTOTCT ='SOCKET*TOTAL*REQUEST*COUNT'
TCPSRVCE='TCP/IP*SERVICE*NAME'
WBBRWCT ='WEB BROWSE*REQUEST*COUNT'
WBEXTRCT='WEB EXTRACT*REQUEST*COUNT'
WBREADCT='WEB READ*REQUEST*COUNT'
WBWRITCT='WEB WRITE*REQUEST*COUNT'
-New CICS Statistics STIDs create new MXG datasets:
STID Name MXG DSN Description
107 STISOG CICTCPSO TCP/IP Sockets Global
108 STISOR CICTCPIP TCP/IP Services (Sockets)
111 STIIIR CICTCPII TCP/IP II Domain RequestModel
114 STIEJR CICTCPEJ TCP/IP Entrprse Java ObjContainer
117 STISJG CICTCSJG TCP/IP JVMPOOL Statistics
MXG support is based on pre-GA documentation, and there
may be differences in the GA level of the product.
Change 18.313 MXG 18.10 only. Change 18.280 caused CICS/TS 1.3 records
VMAC110 to print error messages about EXCLUDED fields when there
Jan 2, 2001 were no excluded fields, and records were deleted:
***ERROR.TYPE110.CICS TS 1.3. EXCLUDED FIELDS HAVE BEEN DETECTED.
MXG EXPECTED MCTSSDCN=202 AND MCTSSDRL=1260.
RECORD WAS DELETED, CICSTRAN DATA WAS LOST.
SYSTEM=XXXX APPLID=YYYYYYYY SMFPSRVR=53 MCTSSDCN=203 MCTSSDRL=1288
(Disregard the "MXG EXPECTED" text, which was also wrong,
and note that the final line of the error message showing
MCTSSDCN=203 is the correct minimum number of fields.)
The test in line 6977 in VMAC110 was changed from 203 to
204 when it should have remained 203. The correction is
to change that line back to test for LT 203:
6976 ELSE IF SMFPSRVR GE 53.0 THEN DO;
6977 IF MCTSSDCN LT 203 OR MCTSSDRL LT 1288 THEN DO;
If optional fields exist in your type 110 record, this
error does not occur, which is why I missed it in 18.10!
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.312 Variable DATETIME is kept in 169 MXG datasets, but it has
BUILD005 different meanings depending on which dataset it was in,
BUIL3005 and in the PDB.JOBS/STEPS/PRINT/SPUNJOBS datasets, it was
SPUNJOBS not correct. In those four datasets, while labeled as
Jan 2, 2001 "DATETIME OF SHIFT CALCULATION", its value was the time
of the beginning of the shift, rather than the actual
DATETIME value of the job.
Originally, "DATETIME" was a temporary variable that
was used as the input datetime value for your IMACSHFT
definition, to set the value of the character variable
SHIFT. So that summarization with VMXGSUM could
exploit your shift definitions, IMACSHFT changes the
value returned in variable DATETIME, setting its value
back to the time of the start of this shift.
But along the way, DATETIME was accidentally kept in
some datasets, so now it must be corrected where it is
wrong, and documented where it is different.
Now, in the PDB.JOBS/STEPS/PRINT/SPUNJOBS dataset, the
value that is returned in variable DATETIME will be the
original value that was used to calculate the shift:
PDB.JOBS and PDB.SPUNJOBS:
MAX(READTIME,INITTIME,JINITIME,JINLTIME,JSTRTIME);
PDB.STEPS:
MAX(READTIME,INITTIME);
PDB.PRINT:
MAX(READTIME,PRINTIME);
The MAX() is used since some timestamps may be missing,
and the Max/Last datetime value is the logical time of
the job start, step initiate, or print file print time.
In these summary datasets that contain variable DATETIME:
ASUMxxxx CICINTRV CICS JOBSKED MNTHxxxx TRNDxxxx
it is properly labeled 'START OF INTERVAL' and contains
that correct value. In some of those datasets. variable
STARTIME exists and is equal to DATETIME, and where it
exists, STARTIME is better as it is self-describing!
In dataset EREPTIM, DATETIME='DATETIME FOR IPL RECORDS'
and is correct, as IMACSHFT is not invoked in VMACEREP.
In the many OPCxxxxx datasets, DATETIME='EVENT DATETIME',
and is correct, as IMACSHFT is not used here, either.
Thanks to Cendrine Pezier, ABS Technologies, FRANCE.
Change 18.311 Support for DB2 Space Manager 2.1 (INCOMPATIBLE) from SE
FORMATS (Software Engineering). The "current" date/time fields at
VMACSPMG the start of the record were removed, shifting the real
Jan 2, 2001 date/time fields to the left. No error message occurs,
but variable SPMGTIME is missing. FORMATs were updated
to print "Blank:TYPE1" instead of " :TYPE1" (cosmetic).
And variables FARINDRF,NEARINDR,PCTACTIV and PCTDROP are
set missing if they contain all FFx.
Thanks to Anke Mineur, DVG, GERMANY.
Change 18.310 Documentation. Example invocation of the ITSV macros
DOCITSV that are needed to add a new MXG variable into the ITSV
Jan 2, 2001 PDB (in case you need something not yet in ITSV).
Thanks to Chris Weston, SAS ITSV, USA.
Change 18.309 The WorldSecure SMTP Relay object printed UNEXPECTED OBJ
VMACNTSM message; the NRNAMES=NRNAMES-1; statement for that object
Jan 2, 2001 should have been deleted.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.308 Support for APAR OW45788 for NPM corrects the lengths of
VMAC28 several LXETxxxx variables in the X.25 Session dataset
Dec 26, 2000 NPMEVX25 that were originally mis-documented by IBM.
Change 18.307 Variable MSU4HRAV was correct for a uni-processor, but
VMXGRMFI was wrong in magnitude for multi-processors; NRCPUS(II)
Dec 26, 2000 was needed in the numerator of MSU4HRAV calculation.
Variable CECSUSEC is now kept, and the absence of //SPIN
DD statement no longer causes a failure.
Thanks to Al Sherkow, I/S Management Strategies Ltd, USA.
Change 18.306 The Scheduling Environment name, SMF30PFL, and durations
BUILD005 SMF30HQT/JQT/RQT/SQT, are added to the PDB.JOBS dataset
BUIL3005 (JES2 or JES3, BUILDPDB/BUILDPD3. Those five variables
VMAC30 will be of long term importance in job scheduling, and so
Dec 23, 2000 are now automatically in PDB.JOBS. The change in VMAC30
was cosmetic; SMF30PFL was hex zeros when not populated;
now those '00'x will be translated to blanks.
Thanks to Stephen Marksamer, The Hartford, USA.
Change 18.305 The text of Change 18.300, re DB2TCBTM, was revised and
VMACDB2 the MXG equation, changed by this change, is now:
Dec 21, 2000 DB2TCBTM=
Jan 29, 2001 SUM((QWACEJST-QWACBJST),QWACSPCP,QWACTRTE);
This change added support for DB2 Version 7.1 (COMPAT):
DB2ACCT new variables:
QBGA2H ='ASYNC*IXLCACHE*FOR SECC GBP'
QBGA2S ='COMPLETION*CHECKS*SUSPENDED'
QBGA2W ='CHANGED PAGE*WRITES TO*SEC GBP '
QBGAEX ='*EXPLICIT*XI-S'
QBGAHS ='ASYNCH*IXLCACHE*FOR PRI GBP'
QBGAGG ='GET PAGES*FOR GBP*DEP PAGES'
QWACARLG='TRACE EVENT*FOR WAITS*FOR LOG WRITE*I/O'
QWACARNK='CHILD L-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNM='OTHER L-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNN='PAGESET P-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNO='PAGE P-LOCKS*GLBL CONTENTION*EVENTS'
QWACARNQ='OTHER P-LOCKS*GLBL CONTENTION*EVENTS'
QWACAWLG='WAIT TIME*FOR LOG WRITE*I/O'
QWACAWTK='WAIT TIME*GLBL CONTENT*CHILD L-LOCKS'
QWACAWTM='WAIT TIME*GLBL CONTENT*OTHER L-LOCKS'
QWACAWTN='WAIT TIME*GLBL CONTENT*PAGESET P-LOCKS'
QWACAWTO='WAIT TIME*GLBL CONTENT*PAGE P-LOCKS'
QWACAWTQ='WAIT TIME*GLBL CONTENT*OTHER P-LOCKS'
QWACRBSV='ROLLBACK TO*SAVEPOINT*REQUESTS'
QWACRLSV='RELEASE*SAVEPOINT*REQUESTS'
QWACSVPT='SAVEPOINT*REQUESTS'
QWAXAWFC='WAIT TIME*FOR FORCE*AT COMMIT'
QWAXFCCT='WAITS FOR*FORCE*AT COMMIT'
QWAXIXLE='EVENTS FOR*ASYNC*IXLCACHE*IXLFCOMP'
QWAXIXLT='WAIT TIME*FOR IXLCACHE*IXLFCOMP'
QXDCLGTT='DECLARE*GLOBAL*TEMP TABLE*STMTS'
QXDEGDTT='PARALLEL*GROUPS*DECLARED*TEMP TABLE'
QXSETCPR='SET*CURRENT*PRECISION*STATEMENTS'
DB2ACCTP new variables:
QPACARNK='CHILD L-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNM='OTHER L-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNN='PAGESET P-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNO='PAGE P-LOCKS*GLBL CONTENTION*EVENTS'
QPACARNQ='OTHER P-LOCKS*GLBL CONTENTION*EVENTS'
QPACAWTK='WAIT TIME*GLBL CONTENT*CHILD L-LOCKS'
QPACAWTM='WAIT TIME*GLBL CONTENT*OTHER L-LOCKS'
QPACAWTN='WAIT TIME*GLBL CONTENT*PAGESET P-LOCKS'
QPACAWTO='WAIT TIME*GLBL CONTENT*PAGE P-LOCKS'
QPACAWTQ='WAIT TIME*GLBL CONTENT*OTHER P-LOCKS'
DB2ACCTG new variables:
QBGA2H ='ASYNC*IXLCACHE*FOR SECC GBP'
QBGA2S ='COMPLETION*CHECKS*SUSPENDED'
QBGA2W ='CHANGED PAGE*WRITES TO*SEC GBP '
QBGAEX ='*EXPLICIT*XI-S'
QBGAGG ='GET PAGES*FOR GBP*DEP PAGES'
QBGAHS ='ASYNCH*IXLCACHE*FOR PRI GBP'
DB2STATS new variables:
(DB2STAT0)
Q9STCTRZ='DISPLAY*FUNCGION*COMMANDS'
Q9STCTX0='START*FUNCTION*COMMANDS'
Q9STCTX1='STOP*FUNCTION*COMMANDS'
Q9STCTX2='SET*LOG*COMMANDS'
Q9STCTX3='DISPLAY*LOG*COMMANDS'
Q9STCTX4='SET*SYSPARM*COMMANDS'
QDSTCIN2='CURRENT*TYPE 2*INACTIVE*THREADS'
QDSTMADS='MAXIMUM*ACTIVE DBAT SLOTS NOT INUSE'
QDSTMIN2='MAXIMUM*TYPE 2*INACTIVE*THREADS'
QDSTMQR2='MAXIMUM*TYPE 2*QUEUED*REQUESTS'
QDSTNADS='CURRENT*ACTIVE DBAT SLOTS NOT INUSE'
QDSTNDBA='REQUESTS*REQUIRING*DBAT'
QDSTNITC='CONNECTIONS*TERMINATED*MAX TYPE 1'
QDSTNQR2='CURRENT*TYPE 2*QUEUED*REQUESTS'
QDSTPOOL='REQUESTS*SATISFIED*BY POOL THREAD'
QDSTQIN2='QUEUED*RECEIVE*REQUESTS*FOR TYPE 2'
QJSTBPAG='LOG-WRITE*BUFFER*PAGE INS'
QJSTCIWR='LOG*CI-S*WRITTEN'
QJSTLOGW='LOG WRITE*I/O*REQUESTS'
QJSTLSUS='SUSPENDS*FOR LOG WRITE'
QJSTSERW='SERIAL*LOG WRITE*REQUESTS* FOR REWRITE'
QJSTTHRW='TIMES*LOG WRITE*THRESHOLD*WAS REACHED'
(DB2STAT1)
QISEDFAL='FAIL*DUE TO*DATASPACE FULL'
QISEDFRE='FREE PAGES*IN DATASPACE*FREE CH'
QISEDPGE='PAGES*IN EDM*DATASPACE'
QTRACAUT='SUCCESS*AUTH CHECKS*FOR ROUTINES'
QTRACNAC='DB2 UNABLE*TO ADD ENTRY*TO AUTH CACHE'
QTRACNOT='ROUTINE*AUTH CHECKS*NON USE*AUTH CACHE'
QTRACOW1='DB2 OVERWROTE*AUTHID IN*AUTH CACHE'
QTRACOW2='DB2 OVERWROTE*ENTRY IN*AUTH CACHE'
QTRACPUB='SUCCESS*AUTH CHECKS*HELD BY*PUBLIC'
QXDCLGTT='DECLARE*GLOBAL*TEMP TABLE*STMTS'
QXDEGDTT='PARALLEL*GROUPS*DECLARED*TEMP TABLE'
QXSETCPR='SET*CURRENT*PRECISION*STATEMENTS'
DB2STAT2 new variables:
QDBPPGST='PGSTEAL*ATTRIBUTE'
QDBPSLA ='QDBPSLA*SERVICEABILITY'
QDBPVDQB='POOL*VERTICAL*WRITE*THRESHOLD'
QDBPVPTY='VPTYPE*ATTRIBUTE'
T102S006 new variables:
QW0006PG QW0006FG
T102S016 new variables:
QW0016WT
T102S017 new variables:
QW0017TY
T102S022 new variables:
QW0022AS QW0022CC QW0022CE QW0022FG QW0022QO QW0022RS
QW0022CY QW0022F2 QW0022NP QW0022PA QW0022TT
T102S022 new variables:
QW0023R1
-Additional T102Snnn subtypes will be decoded upon request
MXG support is based on pre-GA documentation, and there
may be differences in the GA level of the product.
======Changes thru 18.304 were in MXG 18.10 dated Dec 20, 2000======
Change 18.304 First MXG 18.10 only. Cosmetic. Label was truncated for
ASUMCICS variable SYSTEM and CPUTM had no label, because the equal
Dec 20, 2000 sign after CPUTM was missing.
======Changes thru 18.303 were in MXG 18.10 dated Dec 20, 2000======
Change 18.303 Cosmetic, in that the statement was never executed, but
VMXGCICI %ELSE INTRVSEC=0; should have been %ELSE %LET INTRVSEC=0;
Dec 19, 2000
Thanks to Russell Dewar, National Australian Bank, AUSTRALIA
Change 18.302 Support for APARs OW44845 and OW47050 adds a new report,
ANAL103 the HTTP Server Report, from SMF 103 records!
ANALRMFR MXG parameter overrides:
Dec 19, 2000 MXG HTTP Server Summary Report
%ANALRMFR(REPORT=HTTP);
DEFAULT is to create:
Interval of DATE and Report is HTTPSUM.
To create another Interval other than Date.
%ANALRMFR(REPORT=HTTP,RPTOPT=HTTPSUM,
INTERVAL=HOUR);
Create MXG HTTP Server Detail Report
%ANALRMFR(REPORT=HTTP,RPTOPT=HTTPDTA);
Values have not been verified, see comments within
ANALRMFR for more detail of overrides.
A DDNAME of PDB is now required anytime ANALRMFR is
invoked, whether it is a TEMPORARY SAS library
//PDB DD UNIT=SYSDA,SPACE=(CYL,(5,5))
or a CATALOGED SAS library:
//PDB DD DSN=MXG.PDB,DISP=(,CATLG),
// DCB=RECFM=FS,
// UNIT=SYSDA,SPACE=(CYL,(5,3))
New member ANAL103(HTTP), documentation only, how to
create the associated Post-processor RMF reports.
Change 18.301 Validated reports with FICON data records. REPORT=CHAN,
ANALRMFR columns READ(MB/SEC) and WRITE(MB/SEC) values were output
Dec 19, 2000 even if they were missing. Values were corrected to
match IBM RMF report. APAR OW42945 updated the Partition
Data Report to now include two TOTAL lines, one for all
CP partitions and one for all ICF partitions.
Thanks to Trevor Holland IBM/GSA Australia
Change 18.300 MXG 17.17 thru MXG 18.09 only. Variable DB2TCBTM in data
VMACDB2 set DB2ACCT included CPU time in Stored Procedure Address
Dec 07, 2000 Spaces twice. Both variables QWACSPCP and QWACSPTT were
Dec 18, 2000 added by MXG Change 17.382 to the DB2TCBTM formula,
Dec 21, 2000 DB2TCBTM=SUM((QWACEJST-QWACBJST),QWACSPCP,QWACSPTT);
because I read "not recorded" in IBM DB2 V6.1 DSNWMSGS:
QWACSPCP ACCUMULATED TCB TIME SPENT PROCESSING SQL CALL STATEMENTS
QWACSPCP IN THE DB2 STORED PROCEDURES ADDRESS SPACE OR A WLM
QWACSPCP ADDRESS SPACE. THIS TIME IS CALCULATED ONLY IF
QWACSPCP ACCOUNTING CLASS 1 IS ACTIVE.
QWACSPCP FOR A THREAD THAT USES RRSAF TO CONNECT TO DB2 AND
QWACSPCP IS SWITCHED AMONG TASKS, THIS VALUE IS 0.
QWACSPTT ACCUMULATED TCB TIME SPENT IN DB2 PROCESSING SQL
QWACSPTT STATEMENTS ISSUED BY STORED PROCEDURES. THIS IS <===
QWACSPTT THE TIME NOT RECORDED IN QWACSPCP. THIS TIME IS
QWACSPTT CALCULATED ONLY IF ACCOUNTING CLASS 2 IS ACTIVE.
and so I concluded that both SPCP and SPTT must be added,
and made Change 17.282 in January, 2000. But when data
had large and nearly equal values in both SPCP and SPTT,
we queried IBM DB2 support, who investigated and replied
that internal documentation showed that SPTT was included
in SPCP, and DSNWMSGS was wrong and would be corrected.
IBM DB2 support also confirmed that the additional CPU
time field for the execution of triggers under enclaves,
variable QWACTRTE, is also not included in EJST-BJST and
it must also be added to get the Total DB2 TCB CPU time
in DB2ACCT. So the final (Dec 21) equation is:
DB2TCBTM=
SUM((QWACEJST-QWACBJST),QWACSPCP,QWACTRTE);
The SPAS accounting error surfaced when one user saw the
daily DB2 CPU time for his AUTHID jump from 20.17 seconds
when only EJST-BJST was charged, to 137.57 seconds when
SPCP=58.76 and SPTT = 58.60 were both added by MXG; the
user's bill increased by a factor of six!
His real cost without the double accounting was 78.93,
so his bill should increase by a factor of only four.
For this one AUTHID, SPAS CPU time was significant, and
because the SPTT time recorded was also large, the MXG
double accounting was significant. But that may not be
the general case; overall, SPTT seems to be quite small,
even when SPCP is large. Looking at the daily totals
from two sites shows that including SPCP can be
significant, but the CPU time in SPTT was insignificant:
One site Other site
EJST-BJST 166,612 1,095,220.92
QWACSPCP 205,839 389.34
QWACTRTE 0 0
DB2TCBTM 372,451 1,095,610.26
QWACSPTT 2,902 388.00
You should run a PROC MEANS SUM DATA=PDB.DB2ACCT;
to determine the impact of including SPTT at your site.
Dec 21 update: Today I looked at the DSNDQWAC DSECT, and
it was right all along, as it documents that:
QWACSPTT THE ACCUMULATED TCB TIME CONSUMED IN DB2 PROCESSING SQL
STATEMENTS ISSUED BY STORED PROCEDURE(S)
AND INCLUDED IN QWACSPCP <<===== !!!!!
It's all about knowing which documentation to believe!
To summarize what has been true in DB2ACCT and ASUMUOW:
- DB2TCBTM is calculated as
SUM((QWACEJST-QWACBJST),QWACSPCP,QWACTRTE);
QWACSPCP and QWACTRTE are added by MXG into DB2TCBTM
QWACSPTT is NOT added, because it is in QWACSPCP.
Thank to Steve Colio, CIGNA, USA.
Thanks to Jiann-Shiun Huang, CIGNA, USA
Thanks to Curt Cotner, IBM, USA.
Change 18.299 Support for SMF 120 record for Websphere Application
EXT120CC Server Enterprise Edition OS/390 Component Broker
EXT120CM Version 3.02, added by APAR OW44456.
EXT120SA There are four subtypes, described by IBM as:
EXT120SC
EXT120SI Subtype=1: Server Activity Record:
FORMATS Created for each activity that is running inside a
IMAC120 Websphere Application Server. This record can be used to
TYPE120 perform basic charge back accounting as well as profiling
VMAC120 of customer written applications to determine in detail
VMXGINIT what is happening inside the Websphere Application
Dec 16, 2000 Server.
MXG dataset TY120SA
Subtype=2: Container Activity Record
Created for each activity that runs inside a container
located in a Websphere Application Server. This record
can be used to perform basic charge back accounting,
application profiling, problem determination, and
capacity planning. MXG Datasets TYP120CA/TYP120CC and
TYPE102CM.
Subtype=3: Server Interval Record
Created for each server instance that has interval
recording active during the interval. The purpose of this
record subtype is to record activity that is running
inside a Websphere Application Server. This record is
produced at regular intervals and is an aggregation of
the work that has run inside the server instance during
the interval. MXG Dataset TYP120SI.
Subtype=4: Container Interval Record
Created for each active container located in a Websphere
Application Server. This interval record provides a
snapshot view of the activity running inside the
container. This record can be used to perform application
profiling, problem determination, and capacity planning.
MXG Dataset TYP120CI.
And IBM APAR OW44456 requires the following doc changes:
Periodically, IBM refreshes documentation on our Web
site, so the changes might have been made before you
read this text. To access the latest on-line
documentation, go to the product library page at:
www.ibm.com/software/webservers/appserv/library_390.html
And support provides a new edition:
Document Name: WebSphere Application Server Enterprise
Edition for OS/390 Operations and Administration
Document Number: GA22-7328-01
The new edition contains a chapter (Chapter 9) that
explains how to set up and use the new SMF recording
support and an appendix (Appendix A) that describes
the new SMF record type 120.
To get the new edition, go to our Web site at:
www.ibm.com/software/webservers/appserv/library_390.html
IBM support also requires changes to existing doc:
Document Name: WebSphere Application Server Enterprise
Edition for OS/390 Component Broker Planning and
Installation Guide
Document Number: GA22-7325-00
See revisions in the APAR OW44456 text.
This support has not been tested with 120 SMF records.
Change 18.298 Support for the z/OS License Manager's new LPAR capacity
VMXGRMFI measurement: "Four-Hour Running Average MSU", with MSU in
TRNDRMFI "Million Service Units per Hour", based on the raw SU_SEC
Dec 12, 2000 of the physical platform. New MXG variable MSU4HRAV is
Dec 18, 2000 now created in the PDB.RMFINTRV dataset, and it is that
Feb 10, 2001 value that z/OS will pass to the License Manager, which
is compared with the licensed MSU for that LPAR (which
you chose in your software License Certificate for that
LPAR). WLM measures the MSU consumed by the LPAR every
five (may be changed) minutes, and if the licensed MSU is
exceeded, WLM will cap the LPAR to that licensed MSU for
the next interval.
So this new License Manager can save you lots on software
license costs, if you don't need an entire machine for an
LPAR; you can even license only part of an engine.
BUT to save that money, you will need to know your peak
MSU4HRAV for the month, in advance, so you can purchase a
correct size license, and you will need to track when
that peak MSU4HRAV consumption occurs, perhaps so you can
time-shift work to reduce that peak MSU consumed. Since
each month's charge is likely to be based on the maximum
peak running average during each calendar month, tracking
closely at near-month-end may be needed!
When WLM capping is invoked (because the LPAR exceeded
its licensed MSU4HRAV), response times may be elongated,
and it remains to be seen what feedback will be available
to alert you that dynamic capping was applied, but with
this new variable now, you can at least estimate the size
of each of your Systems to see how you will be able to
take advantage of License Manager product pricing.
The MSU4HRAV variable is created in PDB.RMFINTRV when
you run BUILDPDB/BUILDPD3, or if you run RMFINTRV or
invoke %VMXGRMFI in your own program. The algorithm
also creates the new SPIN.SPINRMFI dataset, which holds
the last four hours of the previous day, and is read by
the next day's BUILDPDB so that continuous four-hour
means are calculated. Variable CECSUSEC, the SU_SEC of
the physical CEC, is also created in PDB.RMFINTRV.
New variable MSU4HRMX in TRNDRMFI is the maximum value
of the MSU4HRAV during each trended interval.
You can add the new variables MSU4HRAV and CECSUSEC to
existing PDB.RMFINTRV datasets (without re-reading the
SMF data), by using the PDB=ADDMSU option in %VMXGRMFI to
read each existing PDB.RMFINTRV dataset and write back a
replacement, enhanced PDB.RMFINTRV dataset, as shown:
//PDB DD DSN=YOUR.EXISTING.PDB,DISP=OLD
//SYSIN DD *
%VMXGRMFI(PDB=ADDMSU);
If you add a //SPIN DD to that example, and start your
re-creation from the oldest to the newest, MSU4HRAV
will exist in all observations (except for the first
four hours of the oldest PDB):
//WEEKOLD EXEC MXGSAS
//PDB DD DSN=YOUR.WEEKOLD.PDB,DISP=OLD
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
//SYSIN DD *
%VMXGRMFI(PDB=ADDMSU);
... one step per week ...
//WEEKNEW EXEC MXGSAS
//PDB DD DSN=YOUR.WEEKNEW.PDB,DISP=OLD
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
//SYSIN DD *
%VMXGRMFI(PDB=ADDMSU);
If you use the first example, without SPIN, the first
four hour's observations in each output PDB.RMFINTRV
dataset will have missing value for the new variables.
Definitions and description of the algorithm:
"MSU" is Millions of Service Units per Hour, and it is
calculated from the raw (un-weighted) Service Unit Per
Second value (MXG's SU_SEC variable from TYPE72). The
equation to calculate the hourly MSU capacity is:
MSU= 3600*SU_SEC*NRCPUS/1000000 = 336 MSU (per hr)
(e.g.: 10 engine, SU_SEC=9334.8828, a z900 2064-110)
- But SU_SEC value in PDB.RMFINTRV and TYPE72 data is an
LPAR value, and is based on the number of CPU engines
that you gave to that LPAR for this system; increasing
the number of engines decreases the SU_SEC value, due
to the Multi-Processor effect that causes the recorded
CPU time to increase with the number of engines:
Spin loops for access to serialized storage is seen
as CPU time, and the recorded CPU time increases as
the number of engines increases, so to get constant
Service Units, we must multiply by a smaller factor.
An example of the 9021-711 family's MP Factors
CPUs 1 2 3 4 5 6 7 8 9 10
Pct: 100 95 92 88 85 81 79 77 75 72
So instead of using the SU_SEC value for each LPAR,
which varies with the number of engines in each LPAR,
the MSU capacity measurement in z/OS is based on the
new CECSUSEC variable, which is the SU_SEC for all
engines, the "SU_SEC" of the physical "box" or "CEC"
CEC, was Central Electronics Complex,
CPC, now Central Processing Complex,
and CECSUSEC is constant from LPAR to LPAR in a box.
CECSUSEC did not exist in the RMF records, and it has now
been added in z/OS as SMF70CPA, but MXG creates it now so
we can calculate MSU capacity even before you're at z/OS.
a. The original (18.11) algorithm to calculate CECSUSEC
and MSU from pre-z/OS records (replaced, below):
In OS/390 RMF TYPE72 records, we only have the SU_SEC
of this LPAR, but we could calculate the CECSUSEC from
the LPAR SU_SEC and the "table of MP factors",
above, given the engines in the LPAR and in the box:
CECSUSEC=SU_SEC*MP(PARTNCPU)/MP(NRCPUS);
where
MP(n) is the MP factor for n engines, above, and
PARTNCPU=engines in the physical CEC, and
NRCPUS =engines in this LPAR.
A numerical example:
An LPAR with an SU_SEC = 1000
with NRCPU = 2 (2 engines for this LPAR), and
on a 6-way CEC (PARTNCPU=6) would have a
CECSUSEC = 1000 *(81)/(95) = CECSUSEC = 852
At 100% busy that 2-CPU LPAR has MSU capacity of:
MSU = 3600sec*852SU_sec*2engines/1000000=6.1 MSU
b. The present (18.18) algorithm to get IBM MSU capacity
(pre-z/OS) using table lookup of IBM published values:
The original code worked fine for that one set of MP
factors, but the factors vary with CPU families, and
IBM does not publish a table of MP factors; instead
IBM publishs the MSU capacity of each CPU, and with
the help of Alan Sherkow, the new $MG070CP format is
created as a look-up table that returns the capacity
in MSU and the CECSUSEC, given the CPUTYPE, CPUVERSN,
and (for 2064's) the CPCMODEL.
Alan also noted that the MSU capacity calculated from
CECSUSEC does not exactly match IBM's MSU table value,
even though we thought it should; differences of up to
10% were observed on some particular machines.
c. When you're running under z/OS with License Manager,
the needed fields are added by IBM to the type 70 RMF
record and are kept in PDB.RMFINTRV dataset:
MXG Variable z/OS Variable Description
CECSUSEC SMF70CPA SU_SEC of n-way CPC
MSU4HRAV SMF70LAC 4-hour Average MSU
MSUINTRV n/a Interval MSU count
temp SMF70WLA Defined MSU Capacity
While IBM will provide the SMF70LAC field in z/OS, MXG
now calculates MSU4HRAV from RMF Interval records, going
back four hours, and uses the actual interval durations
so it supports different interval sizes. The last four
hours of each system is written out to SPIN.SPINRMFI so
they can be re-introduced tomorrow so that the four-hour
is continuous in RMFINTRV. (If you're using ADDMSU with
a large PDB.RMFINTRV, default array sizes of 9999 permit
three month's worth of 15 minute intervals.)
This is new territory, and we'll know a lot more about
MSU4HRAV when the License Manager product is released,
but at least now you can begin to measure your LPARs in
these IBM units that will certainly be important in the
future of capacity measurement.
Please do not confuse the License Manager measurements
with Usage Based Pricing, because they are not related.
Under the License Manager, it will be the size of the
LPAR that you define that sets the price you pay for
Software that runs in that LPAR, and it is the total
work in that LPAR (and not the usage of any software
product) that is measured and compared with the LPARs
defined capacity in MSU. There is no measurement of
product's software usage under License Manager, and it
is all work in the LPAR that will be capped if the
MSU4HRAV/SMF70LAC exceeds the SMF70WLA capacity.
Change 18.297 Cosmetic. The test IF NUMTRANS GT 0 for the calculation
ASUMCICX of SQRTARG is redundant so it was removed.
Dec 8, 2000
Thanks to Ian Mackay, Royal Bank of Scotland, SCOTLAND.
Change 18.296 Variable SYSTEM and CPUTM are kept/summed respectively
ASUMCICS from input CICSTRAN/MONITASK data into the PDB.CICS
Dec 8, 2000 summary dataset. CPUTM=TASCPUTM+CPURLSTM in CICSTRAN.
Thanks to Aubrey Tang, Westpac Banking Corporation, AUSTRALIA.
Change 18.295 Support for APAR OWxxxxx which adds a flag bit to type 79
VMAC79 subtype 2.
Dec 8, 2000
Change 18.294 QBGLGG now decoded and kept, although the counters in the
VMACDB2 QBGL section are suspect and under investigation.
Dec 7, 2000
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.293 SPINCNT=SPINCNT+1; changed to SPINCNT=SUM(SPINCNT,1); so
IMACUOW that SPINCNT would actually be retained and incremented
Dec 7, 2000 and the SPIN library actually used.
Change 18.292A Support for MQ Series V5.2 SMF 115/116.
EXTY1152 -INCOMPATIBLE because subtype is now a two-byte binary at
EXTY1161 @19, having been corrected by IBM from the non-standard
EXTY116Q one-byte @19 (and that VMACSMF had catered for, and now
FORMATS had to be revised to cover both old and new 115/116 SMF).
VMAC115 -Reading new records with old MXG versions will create
VMAC116 zero observations from the new records.
VMACSMF -Type 115 Subtype 1, dataset MQMLOG has 7 new variables:
VMXGINIT QJSTBPAG QJSTCIWR QJSTLLCP QJSTLOGW QJSTLSUS QJSTSERW
Dec 8, 2000 QJSTTHRW
Dec 18, 2000 -Type 115 Subtype 2, new Q5ST DB2 manager statistics adds
70 new variables to existing dataset MQMMSGDM:
ABNDCNT ACTTASK CONNCNT DEADCNT DELECNT DELESCUW
DELESMXW DELETCUW DELETMXW DHIGMAX DISCCNT LISTCNT
LISTSCUW LISTSMXW LISTTCUW LISTTMXW NUMTASK READCNT
READSCUW READSMXW READTCUW READTMXW REQUCNT SCSBFTS
SCSDEL SCSDSCUW SCSDSMXW SCSDTCUW SCSDTMXW SCSINS
SCSISCUW SCSISMXW SCSITCUW SCSITMXW SCSMAXR SCSSEL
SCSSSCUW SCSSSMXW SCSSTCUW SCSSTMXW SCSUPD SCSUSCUW
SCSUSMXW SCSUTCUW SCSUTMXW SSKDEL SSKDSCUW SSKDSMXW
SSKDTCUW SSKDTMXW SSKINS SSKISCUW SSKISMXW SSKITCUW
SSKITMXW SSKSEL SSKSSCUW SSKSSMXW SSKSTCUW SSKSTMXW
UPDTCNT UPDTSCUW UPDTSMXW UPDTTCUW UPDTTMXW WRITCNT
WRITSCUW WRITSMXW WRITTCUW WRITTMXW
-Type 115 Subtype 2, new QEST Coupling Facility statistics
segment, MXG creates new MQMCFMGR dataset, one obs for
each structure (if QESTSTR structure name is non-blank:
IBM writes an array of 64 possible structures but MXG
outputs only the entries with data). MXG also calculates
the average duration of IXLLSTE and IXLLSTM calls in new
new variables QESTAVGE and QESTAVBM.
Updates to elements in the CF can be made one at a
time with IXLLSTE, or requests to update multiple
elements, a group of changes that have to be made
together, are done with IXLLSTM.
The other IBM variables created in MQMCFMGR dataset:
QESTCMEC QESTCSEC QESTMLUS QESTMNUS QESTMSTC QESTRMEC
QESTRSEC QESTSFUL QESTSSTC QESTSTR QESTSTRN
-Type 116: FORMAT MG116TY updated for '7:RRS BATCH' type
of attachment type.
-Type 116 subtype 0 creates old MQMACCT Message Manager
accounting; this was the only data set created from SMF
116 record prior to Version 5.2.
-Type 116 subtype 1 creates new MQMACCTQ Queue Level
Accounting dataset with WTIDxxxx and WTASxxxx variables.
This is the important, task-level, dataset, with elapsed
and CPU times per verb for commit and back out requests,
and has task identification, including Job, User ID,
Transaction Name if applicable, and Channel Name (TCP/IP
address or APPC LU).
-Type 116 subtype 1 or subtype 2 creates new MQMQUEUE
Queue Detail with WTIDxxxx and WQxxxx variables. This
data set has an observation for each QUEUE used by the
task, including number/elapsed/CPU times for MQOPEN,
MQCLOSE,MQPUT,MQPUT1,MQGET,MQINP and MQSET calls, and
the WTIDxxxx task identifiers.
Change 18.292 Cosmetic. Comment corrected and labels for Mount Wait
ASUMTMNT bucket variables MNTBKTn changed from 'PCT JOBS' to
Dec 6, 2000 the more accurate 'PCT MOUNTS*MOUNT WAIT*LESS THAN....'.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.291 Cosmetic. Labels added for DOMTRESP/DOMTWAIT/DOMTRTYP/
VMAC103 DOMTRNUM variables in VMAC108, and dataset labels in the
VMAC108 VMAC103 are now "HTTP Web Sphere Server" instead of the
Dec 6, 2000 Lotus Domino no-longer-used name.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.290 TMON for MVS 2.0 NQ records were not correct; Landmark
VMACTMV2 inserted data between 1.3 and 2.0, but no one noticed!
Dec 5, 2000 Both record formats are now supported, and new variables
are now created in dataset TMONNQ.
Thanks to Lindsay Robertson, GMAC Insurance, USA.
Change 18.289 Using IMACJBCK exit for DB2ACCT selection saves CPU time!
IMACJBCK The IMACJBCK exit (or MACJBCK= macro) is invoked in every
VMACDB2H SMF record that contains JOB name. For the DB2 SMF 101
Dec 5, 2000 Account records, using it instead of the EXDB2ACC/ACB/ACP
exit member to delete unwanted records can save lots of
CPU time, because it is invoked earlier in the processing
code, after the QWHS (Standard) and QWHC (Correlation)
Headers have been input, and before INPUTing all of the
other variables in all of the segments in the rest of the
accounting record, and then invoking the EXDB2ACx exit.
These QWHSxxxx and QWHCxxxx variables exist when IMACJBCK
exit is taken, and can be used to delete SMF 101 records
early, fully decoding only the selected records and then
taking EXDB2ACx exit before output into DB2ACCT/ACCTB/P:
SMFTIME ='TIME WHEN*SMF RECORD*WAS WRITTEN'
QWHSSTCK='STORE CLOCK*VALUE FOR*HEADER'
QWHSSSID='SUBSYSTEM NAME'
QWHCAID ='AUTHORIZATION ID '
QWHCCV ='CORRELATION ID '
QWHCCN ='CONNECTION NAME '
QWHCPLAN='PLAN NAME '
QWHCOPID='ORIGINAL OPERATOR ID'
QWHSRELN='RELEASE INDICATOR'
JOB ='JOB NAME*OR*TSO USER'
QWHSLUNM='LUNAME'
NETSNAME='ORIGINATING*SYSTEM*NET-NAME'
QWHCEUTX='END USERS*TRANSACTION*NAME'
QWHCEUID='END USERS*USERID*AT WORKSTATION'
QWHCEUWN='END USERS*WORKSTATION*NAME'
QWHCATYP='CONNECTING*SYSTEM TYPE*CODE'
Numeric values and their meaning:
0='0:UTILITY'
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'
0AX='AX:IMS TRANSACTION BMP'
0BX='BX:UTILITY JOBS'
In your logic in IMACJBCK, you must DELETE unwanted SMF
records, so you must use NOT logic to select wanted:
//SYSIN DD *
%LET MACJBCK= %QUOTE(
IF ID=101 THEN DO;
IF QWHSSIID NE 'DB2SYS1' THEN DELETE;
IF NOT (JOB='MINE' AND QWHCPLAN='PLAN1') THEN DELETE;
END;
);
%ANALDB2R(PDB=SMF);
This change is minor: it moved the %INCLUDE of IMACJBCK
in member VMACDB2H to the end of the Correlation Header,
so all QWHCxxxx variables exist when at IMACJBCK. Added
are QWHCATYP/NETSNAME and new-in-6.1 QWHCEUID/EUTX/EUWN.
(There was no change to IMACJBCK; it just listed here so
you'll find this change when searching for that string!).
Savings: Reading 4.3GB of SMF 101 records to create all
these obs on an SU_SEC=2700 engine took 1426 CPU seconds.
Data Set Observations MegaBytes
DB2ACCT 1,842,166 1500
DB2ACCTG 1,289,146 800
DB2ACCTB 3,915,350 1430
DB2ACCTP 2,700,571 920
Total Output 4650
Deleting all obs in the _EDB2ACx exit took 1257 secs. The
delta of 1426-1257 = 169 seconds is the CPU cost for SAS
write out the 4.5 GB of output, about 27 MB/CPU second.
Using MACJBCK to delete all obs took 318 CPU seconds, so
the delta of 1257-318 = 939 seconds (deleting in _E exit)
is the CPU cost for SAS to execute the INPUT statements
for the 4.3 GB of SMF or about 4.6MB/CPU second.
The 318 seconds is the CPU cost just to read in all 4.3GB
of SMF, because the Headers are actually at the physical
end of each SMF record, so SAS reads SMF records at about
13.8 MB/CPU second.
Case Study:
Read 4.3GB Execute Write 4.5GB
SMF Data Input SAS Output Total
Output all: 318 secs 939 secs 169 secs 1426 secs
Output half:
_EDB1ACx 318 939 85 1342
IMACJBCK 318 470 85 873
Using IMACJBCK to select half of the obs saves 470 secs.
With this much possible saving, we will enhance ANALDB2R
in the near future so that any selection we can do in the
IMACJBCK exit will be done there if you use PDB=SMF for
your DB2PM-like reports, but you can exploit this exit
right now using the above example.
Thanks to Ron Alterman, Charles Schwab & Co., Inc, USA.
Change 18.288 The JCL in the TESTOTHR step of JCLTEST8 did not have the
JCLTEST8 //TMDCIN DD DUMMY and //TMDVTIN // DD DUMMY statements.
Dec 4, 2000 Member TESTOTHR had been updated to test the new support
and JCLTEST6 was updated, but JCLTEST8 was overlooked.
Thanks to Peter Herden, TUI (Touristik Union) Hannover, GERMANY
Change 18.287 Assembly error IEC293I FIRST DCB IN CLOSE NOT ACCESSIBLE
ASMIMSL6 because CLOSE (R3) must be CLOSE ((R3)) in line 1333.
Dec 1, 2000 Many MXG users have seen this error when they assembled
that program, but being ASM experts, they fixed it and
never told me about it! Since R3 is an address in reg 3
the parens tell the ASM that R3 is not a ddname!
Thanks to Alan Green, Zurich Financial Services, ENGLAND.
Thanks to Trevor Ede, EDS, NEW ZEALAND.
Change 18.286 The four new duration variables for initiator delays:
VMAC30 SMF30JQT /*JOB*PREPARATION*TIME*/
Nov 30, 2000 SMF30RQT /*INELIGIBLE*FOR*EXECUTION*TIME*/
SMF30HQT /*JOB*HOLD*TIME*/
SMF30SQT /*ELIGIBLE*FOR*EXECUTION*TIME*/
were multiplied by 1.024, but should have been multiplied
by 1024, as they are in 1024-microsecond units.
May 22, 2004: APAR OA07041 corrected SMF30SQT.
Thanks to Steve Simon, ALLTEL, USA.
Change 18.285 Cosmetic. Label for QWACARNG was corrected to be
VMACDB2 QWACARNG='WAITS FOR*SEND MSGS*DATA SHARING'.
Nov 30, 2000
Thanks to Allan J. Winston, MBNA, USA.
Change 18.284 JES 3 only. The WEEKBLD/WEEKBLDT/MONTHBLD members all
WEEKBL3 referenced dataset NJEPURGE which is JES2 only. These
WEEKBL3T three members can be used for JES3 sites; the only change
MONTHBL3 is that DJEPURGE instead of NJEPURGE is processed, and
Nov 29, 2000 the TYPE25 (also JES3-only) processing is added.
Thanks to Robert Sample, Atlanta Journal-Constitution, USA.
Change 18.283 IMS 6.1 only; variable MSGSZOUT is a constant and wrong
TYPEIMSB value in IMSTRAN dataset; the PUT "SUBQ6 $EBCDIC12." was
Nov 29, 2000 corrected to "SUBQ6 $EBCDIC4." to prevent the overlay.
My apologies to Pete Gain who's correct fix I typoed!
Thanks to Alan Green, Zurich Financial Services, ENGLAND.
Change 18.282 Invalid length ILKA record subtype 20 is protected now,
VMACILKA but the record is still invalid. The length of data in
Nov 29, 2000 SMFACDLN is 11,640, but the record is only 4092 bytes,
and the number of subpools expected is 256, but there is
room only for the first 98 subpool segments. This change
detects the bad record, prints a message on the log, and
outputs only the found subpool segments, while awaiting
a correction from the vendor. Only ILKAST20 dataset is
affected by this error.
Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM
Change 18.281 Three logic errors in VMXGUOW were corrected:
VMXGUOW -IRESPTM was being summed from all MRO transactions, due
Nov 24, 2000 to the mis-location of the code that sets IRESPTM to the
single internal response time of the "TOR" transaction
(i.e.: now, IRESPTM is the response of the transaction
used for TRANNAME and TERMID).
-Counters were being summed as: HOLDX=HOLDX+X; but that
results in a missing value in the PDB.ASUMUOW output data
set if any counter was missing for any observation in the
input. Instead, the more robust HOLDX=SUM(HOLDX,X);
statement is used in VMXGUOW, so that only if all values
of a variable is missing in all input observations will
that variable have missing value in PDB.ASUMUOW output.
-The INCODE= segments (intended to allow tailoring things
like normalize CPU times across different processors, or
to add new variables) was mis-located after the code that
added the new variables, so new variables were missing.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.280 Cosmetic, only affected MXG processing under ASCII SAS.
VMAC110 The variables RTYPE and RRTYPE should have been INPUT as
Nov 24, 2000 $EBCDIC1. instead of $CHAR1., so that they were converted
into ASCII characters for printing and MG110RT format.
See Change 18.313.
Change 18.279 NPM Type 28 Subtype 'DC'x (VTAM CSM Buffer Pool data) had
VMAC28 INPUT STATEMENT EXCEEDED INPUT RECORD error because I
Nov 24, 2000 mis-read the documentation. The four fields input at the
Nov 27, 2000 end of the sub-subtype VCSVDTYP=1 record (VCSMAXFS thru
VCSCUREC) exist in the VCSDTYPE=2 record, where they are
properly input. The four lines in the VCSVDTYP=1 INPUT
statement were replaced by +4 (to skip over the four
undocumented bytes at the end of the 176 byte segment).
Nov 27: Variable NRTDTYPE now kept with other NRT vars.
Thanks to Bruno Peeters, Dexia Bank Belgium, BELGIUM.
Change 18.278 -Summarization of CICS Statistics into CICINTRV for "EOD"
ADOCCICI (sum all "INT" and "End-of-Day" shutdown records into one
VMXGCICI total observation for each execution of a CICS region)
Nov 23, 2000 did not work properly: INTERVAL=EOD was never defined in
VMXGSUM/VMXGDUR, causing missing COLLTIME and STARTIME,
and multiple executions were lumped together. Since EOD
is defined only for CICS "EOD" in CICINTRV (set by adding
MACRO _CICINTV EOD % in your IMACKEEP or IMACCICS),
VMXGCICI was revised if EOD was requested and now passes
INTERVAL=MYTIME, and MYTIME= DATETIME=COLLTIME;, values.
The end result is that you get one observation for each
APPLID COLLTIME, where COLLTIME=CICSSTCK, logically the
the READTIME of each CICS region execution.
Note that if you dump your SMF data at midnight, and
stop/start the CICS regions daily at, say 4am,
requesting EOD will create two observations in todays
PDB.CICINTRV, one with yesterday's CICSSTCK time,
for the interval from midnight until 4am, and one with
today's CICSSTCK, summarizing the interval from 4am
until midnight, and neither observation would have the
total resources for each execution.
-Additional enhancements were also made. The PDB.CICINTRV
dataset is now created with the variables in alphabetic
order (with SYSPLEX SYSTEM SMFPSSPN COLLTIME etc. first)
by inserting a LABEL statement in the ORDER= argument of
the final VMXGSUM invocation.
-Two variables that had been summed are now maxed from the
SMD data: MAX=SMDHWMPS SMDIFREE
-Two variables that had been summed are now maxed from the
SMT data: MAX=SMTHWMPS SMTNTASK
-One variables that had been overlooked is now summed in
the XMC data: SUM=XMCPWQ
-These variables that had been overlooked are now summed
in the XMR data:
SUM= XMRAMISM XMRFAIT XMRFANW XMRFAOPN XMRFAOT
XMRFATX XMRITOV XMRIWAIT XMRRC
-Member ADOCCICI now documents which variables from which
Statistics datasets are SUM, MIN, MAX, and MEANed, and
how interval datasets are sorted. All except the MEANed
variables are defendable: for some datasets with multiple
records per interval (LSRPOOL, FCR), I calculate average
values that are of dubious value, so disregard them if
they are useless. Sometimes, averages are useful for
trending, and in all these cases, you still can go back
to the original detail to examine specifics.
Thanks to Normand Poitras, ISM, Canada.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.277 Cosmetic. Labels for R744SSTA, R744STAC, and R744STRC
VMAC74 were corrected from the original documentation and now
Nov 20, 2000 match the SMF manual's description.
Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND
Change 18.276 CICS TS 1.3 SAP Journal Format SMF records were output in
VMAC110 dataset CICSJOUR instead of CICSSAP. The MXG test
Nov 16, 2000 IF JCRUTRID='SA' AND JCRLL GE 250 THEN DO;
was false because JCRLL is not created for the GLRHTYPE=2
sub-subtype journal format record. Instead of testing
JCRLL, the variable LENUDAT is used to verify that there
are at least 250 bytes of journal data left to read:
IF JCRUTRID='SA' AND LENUDAT GE 250 THEN DO;
and also the test for 00D1 was similarly changed to:
ELSE IF JCRUTRID='00D1'X AND LENUDAT EQ 50 THEN DO;
Thanks to L. Theodorides, Alte-Leipziger, GERMANY.
Change 18.275 Support for Vital Signs VisionNet VSAM file.
TYPEVITA Work in progress; only the subtype '38'x has been decoded
Nov 16, 2000 and code is not yet fully structured. But it works.
Thanks to Craig Collins, State of Wisconsin IT Services, USA.
Change 18.274 JES3 only. A short SMF type 6 record (90 bytes) had a
VMAC6 short "I/O Data Section", with SMF6LN1=30, which MXG had
Nov 16, 2000 not ever seen before. Normally, SMF6LN1=52 because all
thirteen fields existed, and MXG read them all. This
record ended with field SMF6DFE='01C9'x, which itself is
also not expected. Now, MXG tests for SMF6LN1=52 before
inputting SMF6DFE and the four subsequent fields.
Thanks to Robert Sample, Atlanta Journal-Constitution, USA.
Change 18.273 MXG 18.09 only. NPM APAR OW37743 inserted a four byte
VMAC28 field in the CSL segment in the NPMSUBTY='A0'x ODLC SMF
Nov 16, 2000 type 28 record, and MXG attempted to support that APAR in
Change 18.254, using IBM documentation only and no test
data, but now I find out IBM fibbed. MXG coded to test
the bit that IBM said would be on when the new field was
present, but data now shows the bit is on in records that
don't have the field (and without the APAR!), causing an
INPUT STATEMENT EXCEEDED RECORD LENGTH error. MXG now
uses the LENAOF segment length to determine if the field
is or is not inserted in your record. The original code:
IF LCSLCON6='1.......'B THEN INPUT LCSLT3S &PIB.4. @;
IF LENAOF GE 192 THEN DO;
INPUT
was replaced by these statements:
IF LENAOF GE 192 THEN DO;
IF LENAOF GE 196 THEN INPUT LCSLT3S &PIB.4. @;
INPUT
Thanks to Richard Rich, California Stephen P. Teal Data Center, USA.
Change 18.272 This example that analyzes allocation time components
ANALALOC (including HSM recall) had "IOPDB.xxx", but that was
Nov 13, 2000 changed to "PDB.xxx" to be consisted with other ANALs.
Thanks to Forrest Nielson, State of Utah, USA.
Change 18.271 Variable STC14VSZ now is formatted MGBYTES. (so that
VMACSTC it prints pretty!).
Nov 8, 2000
Thanks to Chuck Hopf, MBNA, USA.
Change 18.270 The SARRU33 records from CA-VIEW for subtype 33 (DELETE
VMACSARR REPORT) reserved field before SV33LNES should be +2 and
Nov 8, 2000 not +1. This caused subsequent fields in the dataset
to be incorrect.
Thanks to Craig Raridon, RadioShack, USA.
Change 18.269 ASTEX records were not read under ASCII SAS; the test for
VMACDMON DMONREC='F1'x, 'F2'x, and 'F3'x must be changed to '1',
Nov 8, 2000 '2', and '3' respectively, as DMONREC was INPUT with
$EBCDIC1, it became an ASCII character value under ASCII
SAS.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 18.268 DSA size variables (SMSDSALI,SMDSATO,SMSHWMDS,SMSHWMDT,
VMXGCICI others) were incorrectly summarized into CICINTRV.
Nov 5, 2000 Some size variables were summed when they should not be.
Nov 12, 2000 These SMSDSANM count variables are summed in CICINTRV:
SUM=SMSASR SMSCREL SMSCRISS SMSCSS SMSCSSCM
SMSCSUBP SMSDSR SMSEXTS SMSEXTSA SMSEXTSR
SMSFMREQ SMSGMREQ SMSHWMSS SMSPWWS SMSSOS
SMSSV SMSTSOS SMSUCSS ,
and these SMSDSANM size variables are maxed in CICINTRV:
MAX=SMSUSSCU SMSUSSHW SMSCSSHW SMSDSALI SMSEDSAL SMSDSAT
SMSEDSAT SMSHWMDT SMSHWMED SMSNPAGP
Sizes (current, hwm, total, cushion) of each specific
DSA (CDSA,RDSA,SDSA,UDSA,ECDSA,ERDSA,ESDSA,EUDSA)
were correct in the CICSMDSA detail dataset, and it
must be used for analysis by SMSDSANM (DSA name).
Also, ANALCISH produced correct values.
Thanks to William Sherriff, IBM Global Services, USA.
Change 18.267 Variables SMF14CDL, SMF14CDS, SMF14UDL, and SMF14UDS are
VMAC1415 now formatted with MGBYTES, and they contain byte counts.
Nov 4, 2000
Thanks to Chuck Hopf, MBNA, USA.
Change 18.266 Support for NETVIEW "Hardware Monitor" type 37 SMF record
VMAC37 APAR OW45728 added new variable BRFRIBID, the
Nov 3, 2000 Ring Number (for token-ring LAN) or the bus number (for a
CSMA or token-bus LAN) to dataset TYPE37.
Change 18.265 Corrections based on source code scanning.
VMAC90A -Variable NEWFWKLD was not in keep in VMAC90A.
VMACTMDC -Variable CNSRRBA was not created nor kept in VMACTMDC.
VMACOMVT -Variables ON29UNK1-OM29UNK5 were removed from KEEP list
VMACPMTR as they are now known, input, with correct names.
Nov 3, 2000 -Dataset OMVTTCPC was incorrect, because "NEW" string had
been left in columns 1-3, but now have been removed.
-There was no %%INCLUDE SOURCLIB(IMACZDAT) in VMACPMTR,
so variable ZDATE was never created in dataset PERFMETR.
Thanks to Freddie Arie, TXU Gas, USA.
We took real vacation in Chena Hot Springs, near Fairbanks, Alaska. No
email for six days, saw the aurora three nights, made 9,000 ham radio
contacts (at KL7RA, with six other hams, during the annual 48-hour CQ
World Wide DX contest: made 8,600 contacts during the first 24 hours,
and then aurora hit Saturday night, and we made only 400 more QSO's in
the last 24 hours of the contest!).
======Changes thru 18.264 were in MXG 18.09 dated Oct 24, 2000======
Change 18.264 Changes to this SAS/Graph report example for RMFINTRV and
GRAFWORK TRNDRMFI Workload reporting now exploits HTML and SAS V8.
GRAFSAMP -PDBOUT added, allows you to write the output graphics
Oct 23, 2000 catalog to a different location than the input PDB.
This is important if you are using SAS/CONNECT to read
the input data from a mainframe PDB but want to store
the output on your PC or LAN. The default is "PDB".
-New parameter HTMLPATH= (default is null) should point
to a directory where all of the JPG files and HTML code
created by GRAFWORK will be stored.
-Member GRAFSAMP is a sample execution of GRAFWORK based
on a mainframe PDB as input using SAS/CONNECT with an
output PDB on a LAN and HTML being generated.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.263 Changes to this SAS/Graph report example for RMFINTRV and
GRAFRMFI TRNDRMFI reporting has been enhanced to exploit HTML and
Oct 23, 2000 SAS V8, and to remove the now-obsolete VMXGGOPT macro.
-DEVICE= operand now directly used the GOPTIONS statement
rather than using VMXGGOPT.
-New parameter HTMLPATH= (default is null) should point
to a directory where all of the JPG files and HTML code
created by GRAFRMFI will be stored. At the conclusion
of GRAFRMFI, point your browser at the RMFIFRAM.HTML
dataset in the HTMLPATH= directory to view the generated
WEB pages.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.262 Changes to this SAS/Graph report example for tape usage
GRAFTAPE has been enhanced for usability, and new options that
Oct 23, 2000 exploit ODS and SAS Version 8 for HTML output. This
example uses data from MXG's Tape Mount Monitor and from
STK's HSC and LSM records, expecting these datasets in
your TREND library: TAPEMNTS TRNDTALO TRNDHSC TRNDLMS.
-New parameter HTMLPATH= (default is null) should point
to a directory where all of the JPG files and HTML code
created by GRAFTAPE will be stored.
-DEVICE=JPEG provides a good choice of devices to make
your output more accessible and useable.
-DISPLAY=NODISPLAY now has no effect, since with SAS V8,
no output is produced if this option is in effect.
-GOUTTYPE=INDEPENDENT was removed to eliminate a warning
that had no meaning, and NOLIST added to all executions
of PROC DATASETS.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.261 TYPE74 data for PAV Volumes had percentages over 100% for
VMAC74 PCTDVACT, PCTDVCON, PCTDVPND, and PCTDVUSE, because MXG
Oct 21, 2000 did not average those values across the number of UCBs
that were used during that interval. But now, to match
the IBM RMF report philosophy, all of the duration-based
device percentages are now divided by NREXPOSR to give
the average percentage. Note that only the percentage
values are divided by NREXPOSR; the duration variables
are unchanged, so in a 15 minute you could record true
DEVACTTM=39:58, DEVCONTM=21:33, DEVPNDTM=15:45 (with
DLYDEVTM=04:53 and DLYOTHTM=10:52).
This table maps the MXG variable names for the TYPE74
measures of duration, milliseconds per SIO, and percent
of the interval duration to their IBM DASD Report tag:
IBM MXG Duration Per-SSCH Percentage
---- ACT DEVACTTM dne PCTDVACT
CONN CON DEVCONTM AVGCONMS PCTDVCON
DISC DIS DEVDISTM AVGDISMS PCTDVDIS
IOSQ IOQ DEVIOQTM AVGIOQMS dne
PEND PND DEVPNDTM AVGPNDMS PCTDVPND
CUB CUB DLYCUBTM AVGPNCUB PCTPNCUB
DB DEV DLYDEVTM AVGPNDEV PCTPNDEV
DPB DIR DLYDIRTM AVGPNDIR PCTPNDIR
--- OTH DLYOTHTM dne PCTPNOTH
RESP RSP dne AVGRSPMS dne
USE USE dne dne PCTDVUSE
where dne = "does not exist" = is not created.
Schematically, these fields are related:
|----------------------ACT--------------------|
|----------PND----------|--DIS--|-----CON-----|
|-CUB-|-DEV-|-DIR-|-OTH-|
MXG creates the "Other" Pending time because the sum of
individual pends (CUB + DEV + DIR) is less than the total
device PND time. IBM does not directly report that other
component of pending time (although RMF shows it if you
compare DPB+CUB+DB DLYs with PEND). This PCTPNOTH has
usually zero, but now with PAV volumes, it has been seen
to be quite significant in this DURATM=900 sec interval:
One PAV Volume. NREXPOSR=4. DURATM=900 seconds.
|---------------------2398--------------------|
|----------------------ACT--------------------|
|----------945----------|--159--|----1293-----|
|----------PND----------|--DIS--|-----CON-----|
|-0.0-|-293-|-0.0-|-652-|
CUB DEV DIR OTH
The "Other" Pend time of 652 seconds is significant, and
according to none other than Dr H.P. Artis, for PAV, that
Other Pend, PCTPNOTH, includes the response time of the
subsystem to receive, verify, and acknowledge the first
CCW of the channel program. PEND time ends when the
subsystem (i.e., the logical volume) acknowledges the
first CCW. (Included in Other Pend is the percent of
time when I/O was pended due to conflicting Data Extents
for a track range, that is, overlapping writes and reads
waiting for a Data Extent area that is already being
written.
This Other Pend is the I/O delay to shared users of the
same dataset due to PAV parallelism, but without PAV,
that contending job could have had a much larger delay:
in the old days with MIM, the job would have run into
a DSENQ event, been put in hold and still be waiting in
the JES2 Held Job Queue until the enqued dataset was
freed by the first job, or now, with no limit on number
of batch initiators, the job is waiting in the DSENQTM
duration, initiated and holding an initiator, awaiting
allocation, held due to DSNAME ENQ due to DISP=OLD.
Note also that the Connect duration of 1293 seconds is
greater than the interval duration; PAV drops the point
of exclusive control to the track range in the data
extent for writes, and any number of simultaneous reads
can be concurrent even for one track as long as there is
not a write active for that track. I had trouble with
this until I realized that PAV must be behind cache so
parallel I/O to the channel occurs, and even for a cache
miss, the back end can have a 6:1 raid scheme which would
also permit six parallel I/Os between cache and raid.
Note that EMC's PAV's do not have any miss-parallelism,
due to their choice of a raid-1 back end.
A recent MXG-L posting reported an ADABAS volume with
an average of 37 UCB's assigned, showing PAV might be
a real salvation for that old database system!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 18.260 REPORT=DEVC, columns %DEV RESV, %ANY ALLOC and %MT PEND
ANALRMFR have no values. AVG NUMBER ALLOC value is incorrect.
Oct 21, 2000 Line 4036
Change IF DEVCLASS NE 20X OR DEVCLASS NE 80X
To IF DEVCLASS NE 20X AND DEVCLASS NE 80X
Line 4056
Change IF DEVCLASS EQ 20X THEN PUT @1 STORGRUP @128" " @;
To IF DEVCLASS EQ 20X THEN PUT @1 STORGRUP @;
Change 18.259 Under SAS V8, you cannot re-define MACRO _BLD005 using
BUILDPDB %LET MACKEEP= to add PROC SORT and DATA steps before the
Oct 21, 2000 include of BUILD005, although it worked under V6. Instead
you can redefine MACRO _EPDBOUT (or use member EXPDBOUT)
to insert you code, and that is actually the exit that
should be used. In this case, the user wanted to sort
and create a PDB.TYPE30_5 dataset of today's records.
I will pursue the V8 problem with SAS when time permits.
Thanks to Simon Briggs, Allied Irish Bank, IRELAND.
Change 18.258 Variable CPCMODEL was added to dataset TYPE70PR by Change
VMAC7072 17.138, and is now also added to dataset TYPE70.
Oct 18, 2000
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.257 Tivoli NPM Type 28 Subtype 14X NRT record caused either a
VMAC28 NONZERO AOF NPMSUBTY=14 or UNEXPECTED NRPDTYPE=1 error.
Oct 14, 2000 Only NRPDTYPE=2 records (IBM Router) had been received,
so MXG forced this error to validate the Cisco NRPDTYPE=1
record, which turn out to be validly supported by MXG if
the DO group writing this message is deleted and the test
IF NRTDTYPE=2 THEN DO; is replaced with
IF NRTDTYPE IN (1,2) THEN DO; /*IBM/CISCO */
Thanks to Sandra Mischianti, Nicus Software, USA.
Thanks to Ken Patterson, Chemical Abstracts Service, USA.
Change 18.256 The MG073CD format for SMF73CPD (Channel Path Type) now
FORMATS decodes bits: 10X:OSA EXPRESS and 11X:OSA EXPRESS DIRECT
Oct 14, 2000 for those types of channels.
Thanks to Bob Falla, Clarica, CANADA.
Change 18.255 A semi-colon was missing after _ETY30TD invocation, so if
VMAC30 you tailored _ETY30TD and did not end your tailoring with
Oct 14, 2000 a semi-colon, ERROR 79-322 EXPECTING SEMICOLON occurred.
Thanks to Lawrence Jermyn, Fidelity Investments, USA.
Change 18.254 Support for NPM APAR OW37743 (INCOMPAT) SMF 28 for 3746
VMAC28 devices if NPM is collecting TIC3 (ODLC) link resources.
Oct 12, 2000 A four byte field, LCSLT3S='ACTIVE PU*COUNT*PER TIC3',
was inserted into the CSL segment, trashing some fields
in MXG dataset NPMLANOD dataset. The APAR text notes
that TIC3 data can be created by an NPM NETCOLL command
naming a generic resource, such as ODLCLNLK or ALLLINES,
which will match any ODLC (TIC3) link resource cause the
TIC3 data to be captured and sent to NPM.
Thanks to John Wilmot, Midland Bank, ENGLAND.
Change 18.253 The IBM sample report had two columns labeled STG THLD
ANAL88 which we replicated, but the second column is STG FULL,
Oct 11, 2000 and we've corrected our Logger replica report.
Thanks to Tom Elbert, Fortis, USA.
Change 18.252 Support for APAR OW44456 which creates the new SMF 120
record from the Component Broker element of WebSphere
IMAC120 Application Server Enterprise (EE) Edition. WebSphere
VMAC120 Application Server Standard Edition (SE), Advanced
TYPE120 Edition (AE), and Enterprise Edition (EE) is an IBM
TYPS120 product suite that runs on NT, AIX, Solaris, OS/390 and
VMXGINIT more. The SE version includes JAVA and the WebSphere
Oct 10, 2000 Application Server, but the EE version adds the Component
Broker element, and APAR OW44456 provides SMF type 120
records to record measurement of the Component Broker
that runs on OS/390.
Note: none of these members exist; no doc yet.
Change 18.251 Even after Change 17.348, this SAS/GRAPH example failed
GRAFLPAR if you didn't have SAS/GRAPH. The Graph-only SYMBOL1,
Oct 10, 2000 etc., statements were protected by the %IF .. %DO group,
but the following four lines were not deleted.
Thanks to John Allgire, Group Health, USA.
Change 18.250 ERROR.TYPE110.SUBTYPE 2. CICS STATISTICS RECORD STID=126
VMAC110 is an MXG error. The STILEN is 280, but MXG had miscoded
Oct 18, 2000 STILEN-STILEN-272; where it now has STILEN=STILEN-280;.
The error caused zero observations in CICCFS6D dataset.
STID=126 is new CFDT Coupling Facility statistics.
-Two new data fields were added to STID=127 record for
the CICFS7D CFDT Server Table Access dataset.
Thanks to Bernard Cadet, Michelin, FRANCE.
Change 18.249 Variables IMSGTEXT and OMSGTEXT, the first forty bytes of
IHDRIMS the message text, are decoded from the IMS 01 and 03 log
VMACIMS records. They have been useful in fraud investigation!
Oct 5, 2000 In addition, new exit IHDRIMS has been added, after the
IMS record has been read, but before decoding, so that
unwanted IMS records can be deleted.
Thanks to Frank Baird, Oklahoma Department of Human Services, USA.
Change 18.248 Unused Change number.
Change 18.247 Support for Neon System's Shadow Server V4.5 SMF record
EXSHDW01 creates three datasets:
EXSHDW02 dddddd dataset description
EXSHDW06 SHDW01 SHADOW01 SHADOW END CONNECTION
IMACSHDW SHDW02 SHADOW02 SHADOW INTERVAL
TYPESHDW SHDW06 SHADOW06 CLIENT REQUEST
TYPSSHDW The SHADOW01 observations may be end of Session, SM01RCTY
VMACSHDW ='S', or if the Logging feature is enabled, you will also
VMXGINIT get Interim Interval (='I') and Final Interval (='F').
Oct 4, 2000 Only subtype=1 data has been validated.
Thanks to Jim Gilbert, Sabre, USA.
Change 18.246 DB2 Report PMAUD03 failed (Uninit error for IF, NE, THEN)
ANALDB2R because the semicolon was missing from this line:
Oct 3, 2000 @90 'ORIGINAL AUTHID: ' QW0087OP;
Thanks to Bill Hamilton, Scottish Widows, SCOTLAND.
Change 18.245 Support for new NTSMF Objects:
EXNTADSM dddddd dataset Object
EXNTCFSE NTADSM ADSMCLNT ADSM Client Performance
EXNTMQQU NTCFSE COLDFUSE ColdFusion Server
EXNTWSCT NTMQQU MQQUEUES MQSeries Queues
EXNTWSQU NTWSCT WRLDMSCT WorldSecure/Mail Message Count
EXNTWSSM NTWSQU WRLDMSQU WorldSecure/Mail Message Queue
IMACNTSM NTWSSM WRLDSMTP WorldSecure SMTP Relay.
VMACNTSM The ColdFusion object still has errors in their data that
VMXGINIT Demand Technology is working to resolve. All except the
Oct 1, 2000 ADSM object's records have been tested.
-In addition, the "Full Image" object is now supported, as
it's counters are the same as the "Image" object with the
only difference being the instance name. In the Full
Image object the name includes the full file path name of
the loaded modules, while Image has only the filename.
Oct 24: The new ADSM object had no test records, so its
INPUT statement had not been executed. Compiling
under SAS V8 did not detect an MXG coding error
(there were no comments around the label text in
the ADSM INPUT statement), but SAS V6 did detect
an error at compile, but only accidentally: both
versions of SAS saw each word in the comment as a
variable to be input, but under V6, "variable"
TRANSFERRED was MORE THAN 8 CHARACTERS long.
CHARACTERS! This MXG coding error would have
been eventually detected, when test records were
read, but by using both V6 and V8 in the MXG QA,
yet another, later, change has been avoided!
Change 18.244 Candle's Omegamon for VTAM TCP record documentation was
VMACOMVT incorrect; revised DSECT was received and the code for
Oct 1, 2000 TCPA and TCPB datasets now matches the data records.
Change 18.243 While writing my CMG Workshop Paper on BUILDPDB, I was
MXGSAS stunned to find REGION=4096K on the EXEC PGM= statement
Sep 28, 2000 in the MXGSAS JCL Procedure that I distribute! That
should have been removed long ago. You should specify
either REGION=0 or REGION=64M on your JOB card.
Change 18.242 MXG 18.05-18.08 only. CICSTRAN variable PROGRAMB was not
VMACCIMS kept because it was spelled as ROGRAMB in the KEEP= list
VMACEDGS fortunately PROGRAM is the same as PROGRAMB, so the name
VMACSRMH is still there, and this was not reported, but instead
VMACLDMS was detected by Freddie continued source analysis. Other:
VMACRSDF -VMACIISL - Include of IMACZDAT added to create ZDATE.
VMACIISL -VMACEDGS - MDNDS removed from KEEP= list
Sep 28, 2000 -VMACSRMH - _KSRMNNU changed to _KSRMHNU
Oct 23, 2000 -VMACLDMS - corrected to PCDJJNAM,PCDJPSTN,PCDJCOND,
PCDDRLNG,DIRSVERS,DIRSCTL1 which were missing
the last character in KEEP= list, and LPCABR
changed to LPCAGR.
-VMACRSDF - RSDUNKN1-RSDUNKN4 instead of 2-5.
Oct 23: %%INCLUDE for IMACZDAT.
Thanks to Freddie Arie, TXU Utilities, USA.
Change 18.241 Macro _LNTTN32 was not defined, creating dataset _LNTTN32
VMACNTSM instead of TN3270SV. Insert, before MACRO _WNTTN32:
Sep 28, 2000 MACRO _LNTTN32 &PNTTN32..TN3270SV %
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.240 For SAS user SMF record, new format $MGSASPR maps the
FORMATS variable SASPROC (Procedure Name) to the new variable
VMACSASU SASPROD (SAS Product Name that owns that Procedure).
Sep 27, 2000
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 18.239 Cosmetic. Freddie's post-QA analysis of every line of
VMAC90A MXG source code continues to get better! This iteration
VMAC28 identified variables in the KEEP= list in MXG source
UTILXREF members that were never referenced:
UTILXRF2 -In VMAC90A, variables NEWWKLD and MCPNAME in the KEEP=
Sep 26, 2000 list should be spelled NEWFWKLD and MPCNAME. This does
not cause an error, but those variables did not exist in
the output dataset because of the spelling error; only if
you went looking for those fields would you have noticed
the did not exist.
-And when he ran under SAS Version 6, he got VMAC28 NOTE:
LABEL VALUE FOR VARIABLE NITIFODP HAS BEEN TRUNCATED TO
A LENGTH OF 40, but that note did not appear under my SAS
Version 8 QA run, because V8 permits 256 byte Labels!
I have always limited my LABELS to 40 positions, only so
that you didn't get that TRUNCATED message on your log.
In fact, it is only by searching the SAS Log as part of
my own Post-QA analysis for the string TRUNCATED that I
find and correct these long labels in MXG source.
But now that the message goes away in SAS V8, should I
still keep LABELS to only 40 characters? I say YES:
- For sites still running under SAS V6, eliminating any
unneeded or non-impacting message might save me a tech
support call/email, and will save new users confusion
and wasted time.
- Since PROC PRINT SPLIT='*' is the MXG way to print the
label as column heading, if I were to increase label
length, it could mess up our nicely arranged reports.
Besides, you can always use your own LABEL statement
with your PROC PRINT if you want a wordier heading.
- MXG ADOCxxxx and DOCVER members only have room for 40.
- Forty has been enough to describe the first 112,498
variables I've created in MXG.
So I have modified my UTILXREF/UTILXRF2 programs to
detect any labels longer than 40 bytes as part of the
MXG QA stream, and shorten them before you see them.
Thanks to Freddie Arie, TXU Utilities, USA.
======Changes thru 18.238 were in MXG 18.08 dated Sep 25, 2000======
Change 18.238 The new logic fails when the SPIN.SPINUOW dataset exists,
ASUMUOW because a VIEW cannot be used when the input and output
VMXGUOW datasets are the same. Remove /VIEW=_TMPSPIN from the
Sep 25, 2000 DATA _TMPSPIN; statement.
Sep 26, 2000 Members IMACKEEP and IMACUOW were removed from %INCLUDE
Nov 17, 2000 in member ASUMUOW, and IMACUOW was added to the existing
INCLUDE of IMACKEEP in member VMXGUOW, so that MACKEEP is
only invoked once.
Sep 26: If ASUMUOW were executed in a separate step, and
not in the step that built CICSTRAN, the program fails
with CHAR/NUM conflicts, because macro _LCICTRN did not
exist. Now, new logic validates the existence of that
macro, and defines it with the MXG default if not found.
Nov 17: Under SAS V8, the error message was:
YOU CANNOT OPEN SPIN.SPINUOW.DATA FOR OUTPUT ACCESS
WITH MEMBER-LEVEL CONTROL BECAUSE SPIN.SPINUOW.DATA
IS IN USE BY YOU IN RESOURCE ENVIRONMENT SASDSVX.
Bottom line: Scratch and Reallocate the SPIN Library.
Thanks to Hank Oerlemans, Western Australia Police Service, AUSTRALIA
Change 18.237 The TYPS102A member was expected by the test job TESSIBM3
TYPS102A but that member did not exist.
Sep 22, 2000
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.236 Support for Landmark TMON for VTAM creates datasets:
EXTMVTAA dddddd dataset
EXTMVTAE TMVTAA TMVTAA
EXTMVTAS TMVTAE TMVTAE
EXTMVTIB TMVTAS TMVTAS
EXTMVTIN TMVTIB TMVTINB
EXTMVTSE TMVTIN TMVTIN
EXTMVTSI TMVTSE TMVTSE
EXTMVTSS TMVTSI TMVTSI
EXTMVTTN TMVTSS TMVTSS
EXTMVTVR TMVTTN TMVTTN
IMACTMVT TMVTVR TMVTVR
TYPETMVT Records AA, IN, SI, TN, and VR have been tested; the
TYPSTMVT TN records were discovered to have some fields that are
VMACTMVT accumulated, the _STMVTTN macro will deaccumulate TMVTTN
VMXGINIT dataset, and _STMVTTN is added to the TYPETMVT member so
Sep 21, 2000 that dataset TMVTTN is always deaccumulated; using the
TYPSTMVT member is recommended, since the TYPSxxxx member
invokes the _Sdddddd sort macros, which is where the MXG
DIF() logic for deaccumulation is invoked.
Thanks to Siobhan Hansen, Merrill Lynch, USA.
Change 18.235 Summarization and trending of STC datasets.
ASUMSTC Input dataset(s) Summarized dataset
TRNDSTC PDB.STCLMU PDB.ASUMLSM
Sep 21, 2000 PDB.STCENTER, PDB.STCEJECT PDB.ASUMENEJ
PDB.STCHSC PDB.ASUMHSC
Thanks to Chuck Hopf, MBNA, USA.
Change 18.234 This analysis uses SYNCSORT SMF records to identify jobs
ANALUAFF that used tape-to-tape sort steps, but that did not use
Sep 21, 2000 UNIT=AFF=SORTIN on the //SORTOUT dd statement, causing
the job to use an extra tape drive.
Thanks to Al Holz, Merck, USA.
Change 18.233 Both VMXGDUR and VMXGSUM now have new argument SYNC59 to
VMXGDUR add one minute to DATETIME for Interval calculations, so
VMXGSUM that sites which write at :59 minutes can have the start
Sep 21, 2000 of the interval be one minute later.
Thanks to Ian Davies, Canadian Utilities Ltd, CANADA.
Change 18.232 NETSPY 'I' record with NSPYENTL=124 caused STOPOVER ABEND
VMACNSPY because MXG expected NSPYENTL=170. The INPUT statement
Sep 20, 2000 is interrupted after variable OPTSEGSZ and the remaining
fields are only INPUT if NSPYENTL GE 170.
Thanks to Mark Bailey, HM Land Registry, ENGLAND.
Change 18.231 Support for Landmarks The Monitor for DBCTL creates four
ADOCTMDC new datasets from the 'CN', 'CT', and 'CX' records.
EXTMDCCN These new datasets are created:
EXTMDCCV dddddd DATASET Description
EXTMDCCT TMDCCN TMDCCN Interval Statistics from CN record.
EXTMDCCX TMDCCV TMDCCV VSAM Intervals from CN record
IHDRTMDC TMDCCT TMDCCT PSB/Thread Detail from CT record.
IMACTMDC TMDCCX TMDCCX Exception record
TYPETMDC See member ADOCTMDC for notes on some data values.
TYPSTMDC These TMON records can be dumped in compressed format,
VMACTMDC and MXG member EXITMON6 is the code and instructions to
VMXGINIT install the TMON INFILE exit so MXG will read compressed
EXITMON6 TMON records directly; comments and examples in EXITMON6
Sep 19, 2000 were revised and updated for all TMON products.
Thanks to ???, ???, EUROPE
Thanks to Daniel Strgarsek, SAS EMEA, GERMANY.
Change 18.230 Cosmetic. The LABEL for variables PGPEXCP and PGPIOTM
VMAC7072 are now *BY THIS*PERFGRP/SRVCLASS instead of the old
Sep 19, 2000 PERF GROUP PERIOD. These variables exist in both TYPE72
and TYPE72GO datasets, so their contents were clarified.
Thanks to Joe Martin, Amdahl, USA.
Change 18.229 Support for Omegamon for VTAM V500 (COMPAT) adds new
EXOMVTCA TCP/IP measurements in four new MXG datasets:
EXOMVTCB dddddd Dataset Description
EXOMVTCC OMVTCP OMVTTCP TCP/IP Address Space
EXOMVTCP OMVTCA OMVTTCPA TCP/IP Application
IMACOMVT OMVTCB OMVTTCPB TCP/IP Buffer Pool
VMACOMVT OMVTCC OMVTTCPC TCP/IP Connection
VMXGINIT Only the first three datasets have been tested with data.
Sep 19, 2000
Thanks to Eric Barnes, Prudential, ENGLAND.
Thanks to Norman Hollander, Candle, USA.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 18.228 Add logic to MXGCPU report for number ICF's and CP's
ANALRMFR within the Partition data report.
Sep 18, 2000 Error PDB not assigned, when parameters are PDB=SMF,
REPORT=IOQU, and PDBOUT=PDBO was corrected.
Change _STY78 to _STY78CF;
Add _STY78CU; _STY78IO;
Error Physical file does not exist. When parameters are
PDB=SMF,REPORT=WKLD,PDBOUT=PDBO,RPTOPT=PERIOD corrected.
Change all _N72 to _N7072.
Change all VMAC72 to VMAC7072.
Change all _CDE72 to _CDE7072.
Change all _VAR72 to _VAR7072.
Change 18.227 Support for EDA, Enterprise Data Access, SMF user record.
EXEDALOF Two datasets are created from the four subtypes:
EXEDALON dddddd Dataset Subtype Description
FORMATS EDALON EDALOGON 1,4 EDA LOGON OR BEGIN QUERY
IMACEDA EDALOF EDALOGOF 2,5 EDA LOGOFF OR END QUERY
TYPEEDA The EDALOGON dataset seems useless, since it has only the
TYPSEDA SMFTIME of the start, which becomes MXG variable EDASTIME
VMACEDA in the EDALOGOF dataset. Sorted by EDASTIME, EDALOGOF
VMXGINIT has the 2:LOGOFF event record first, which has the total
Sep 18, 2000 CPU Time and EXCP count, and then each of the individual
5:END QUERY event records follow that LOGOFF record. The
CPU time in the 5:END QUERY records is already contained
in the 2:LOGOFF even record.
Thanks to Glen Yee, California Health & Human Services, USA.
Change 18.226 Variable JOB was blank if QMDACORR was blank, for DB2
VMACDB2 attachment QWHCATYP IN (1,2,0Bx) (TSO, CALL ATTACH, and
Sep 15, 2000 UTILITY JOBS). For those QWHCATYP values, MXG now tests
IF QMDACORR GT ' ' THEN JOB=QMDACORR;
so JOB won't be overwritten if QMDACORR is blank.
Thanks to Diane Parker, Bergen Brunswig, USA.
Thanks to Warren E. Waid, JC Penny, USA.
Change 18.225 Change 17.303 was wrong. The DBORG='00'x segment does
VMACCIMS not contain SQL information, and should not have been
Sep 15, 2000 output to CIMSDB2. That segment (with DBDNAME='ALLDBS')
is the I/O activity for DLI buffers during Syncpoint
processing and is now output back into CIMSDBDS (as it
was before Change 17.303), and its I/O counts are summed
into the CIMSTRAN observation for that transaction. It
is called IOWAITS because only IOWAITS code generates
statistics during this processing.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 18.224 The DCOLLECT _Sdddddd and _Sxxxx SORT macros are updated
VMACDCOL as PROC SORT NODUP and the _Bdddddd BY list will remove
Sep 12, 2000 duplicate observations in the input DCOLLECT data.
Change 18.223 MXG 18.02-18.07 GOAL MODE only. Report 2 printed too
UTILRMFI much because test for RPRTCLAS=Y should have been='Y',
Sep 12, 2000 and reports were revised to use PDB.SMFINTRV/PDB.STEPS
or TYPE30_V/TYPE30_V instead of interval and Job Term,
and the comments were clarified.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 18.222 Support for AS/400 Collection Services records, which is
EXQAPCON a separate product, different from the AS/400 Performance
EXQAPDIS Monitor that is still available (free) and supported by
EXQAPJOB MXG's TYPEQAPM code. This new product captures only a
EXQAPPOO small subset of the data in the Performance Monitor.
IMACQACS This new TYPEQACS support creates these datasets:
TYPEQACS DDDDDD INFILE/DATASET Description LRECL
TYPSQACS QAPCON QACSCONF CS Configuration data 16
VMACQACS QAPDIS QACSDISK CS Disk Storage data 352
VMXGINIT QAPJOB QACSJOBS CS Job data 544
Sep 14, 2000 QAPPOO QACSPOOL CS Main Storage data 78
Aug 21, 2008 (QACSYS/QACSYSM/EXQCSSYS reference/member removed 2008.)
The AS/400 CS data is completely dependent on the correct
LRECL having been specified when the data was uploaded
to MVS, or in the FILENAME statement on ASCII systems.
Member VMACQACS documents the correct LRECL sizes.
Thanks to Joe Faska, Depository Trust, USA.
Thanks to Colin Bowen, CSC, SOUTH AFRICA.
Thanks to Stuard R. Burnett, Reynolds Metal Company, USA.
Change 18.221 Cosmetic. A single byte value, 10995116167810048 was
FORMATS skipped in the MGBYTES format and would not have been
Sep 12, 2000 formatted; the range for TB was increased to include.
Thanks to Danny Ball, CNF, USA.
Change 18.220 SAS V8.0 (TSM0 and TSM1), but not SAS V8.1. SAS/GRAPH
DOC "missing values" warning message in SAS V6 became a real
Sep 9, 2000 _ERROR_ condition in SAS V8.0, causing either CC=12, or a
USER 999 ABEND (because MXG sets option ERRORABEND so
that any true error causes an ABEND instead of just a
condition code), if any graph has missing values for one
variable! This has been corrected in SAS V8.1; only a
WARNING message is printed on the log, as it should have
been. If you are still at SAS V8.0, you can specify
OPTIONS NOERRORABEND; for the steps that use SAS/GRAPH,
and the USER 999 will be avoided, although the condition
code will still be non-zero.
Thanks to Caron Knox, Willis Group Services, ENGLAND.
Change 18.219 ERROR: CHARACTER VARIABLE QW0140TX HAS TOO LONG A VALUE
VMAC102 THE SASEB ENGINE when you execute BUILDPDB or TYPE102
Sep 8, 2000 under SAS V8, but point your output to a pre-existing
V6-built SAS data library (i.e., your "PDB"). You should
build V8-format data libraries when executing under V8;
you must allocate new physical OS data sets and write to
them: you CANNOT use PROC DELETE to clear a V6 library
and then write to it with V8 to create a V8-built data
library, since the SAS Directory is still V6-built.
See SAS Technical Note 11 in Newsletter THIRTY-SEVEN.
However, if you intentionally must keep your PDB in the
V6-format, executing under SAS V8, you can circumvent
the above error by using %LET SASCHRLN=100; as your
first //SYSIN statement.
Thanks to Caron Knox, Willis Group Services, ENGLAND.
Change 18.218 Report macro failed if PDB=SMF and PDBOUT=PDB was used.
ANAL94 The internal logic was revised so that macro &PDB was not
Sep 7, 2000 reset.
Thanks to Steve Gossage, Cummins Engines, USA.
======Changes thru 18.217 were in MXG 18.07 dated Aug 31, 2000======
Change 18.217 First MXG 18.07 only. First day's tape (dated Aug 30).
BUILDPDB Member BUILDPDB was missing the _S21 invocation, causing
Aug 31, 2000 dataset PDB.TAPES to have not been built.
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 18.216 were in MXG 18.07 dated Aug 30, 2000======
Change 18.216 Erroneous "BAD HFS" segment messages were produced from
VMACTCP SMF 118 errors with legitimate data; COL-LENGTH should
Aug 30, 2000 have been LENGTH-COL, and LT LENGTH-1 should have been
LE LENGTH-1.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.215 Each INFILE statement was enhanced with END=ENDOFTAN
VMACTAND so that the end of input file is flagged, as this can
Aug 30, 2000 be used to simplify duplicate data checking in ITSV.
Thanks to Peter Christie, IT Performance Consulting, USA.
Change 18.214 INPUT STATEMENT EXCEED RECORD LENGTH for SMF ID=65 record
VMAC6156 because the '04'x Catalog Segment in the Catalog Record
Aug 30, 2000 that is appended to the SMF record without documentation,
now has Low and High Key field lengths of 112 bytes when
previously that field was only 64 bytes long. The IBM
development programmer who "owns" these catalog records
that are output in the type 61, 65, and 66 records has
refused to make their documentation available ("its OCO")
even for this Vendor, so I have to stumble into changes
in field lengths in the data in the field. The logic to
read those varying length fields was revised to protect
for whatever length is now found.
Thanks to John Doan, TotalSystem, USA.
Change 18.213 Support for BMC MainView for MQ Series History File V2.1.
EXBBMQCH Two new subtypes, 'E4' and 'E5' are now supported and new
EXBBMQLM data was added to the existing 'E1' Queue Manager record.
IMACBBMQ DDDDDD Dataset Description
VMACBBMQ BBMQCH BBMQCHAN 'E5' CHANNELS RECORD
VMXGINIT BBMQLM BBMQLMGR 'E4' LOG MANAGER RECORD
Aug 29, 2000 These data sets have been created and sorted, but only
Sep 5, 2000 just examined; the interval DURATION does not exist in
these records, and I can't tell if the values are exact
or whether they are accumulated until I look at more
data, but the datasets and variables look good.
Sep 5: CHLLRTRY and CHLSEQHI are now stored in length 8,
because their default hex value of '3B9AC9FF'x=999999999
became '3B9AC900'x internally when stored in length 4.
Thanks to Martyn Jones, ABN AMRO, THE NETHERLANDS.
Change 18.212 Cosmetic. Spelling in comments of asterisk are now all
DOC the same; variants asteric, asterics, and asterisk were
Aug 29, 2000 corrected in many places. And occurrences of occurance
Sep 5, 2000 and occurence were corrected, too!
Thanks to Bruce Green, MIB, USA.
Change 18.211 This "BUILDPDB" utility now knows about the inconsistent
UTILBLDP spelling of the SMF "MACRO _IDxxxx" in 17 MXG members.
Aug 29, 2000 While most of the SMF ID macro names are _IDxxxx, these
products have non-standard macro names, typically _xxxxID
and they are now properly generated if you request these
products be added to the BUILDPDB code built by UTILBLDP:
ARB, DLM, DMON, HBUF, HURN, IPAC, M204, NSPY, PDSM, RMDS
ROSC, RTE, SYNC, TSOM, VVDS, WYLA, WYLB, X37.
Thanks to Ian Davies, ATCO I-Tek, CANADA.
Change 18.210 Documentation. Support for Netview 1.3 SMF records
VMAC37 type 37, 38, and 39 has been in MXG since before 16.16,
VMAC38 but there was no MXG note to that effect. No changes
VMAC39 were made by this change.
Aug 29, 2000
Thanks to Harald Seifert, HUK-COBURG, GERMANY
Change 18.209 Cosmetic. The "LAST RECORD IN GROUP" message was not
VMACSMF written if the last record was not a subtype 3 record,
Aug 29, 2000 as when reading only part of an SMF file.
Change 18.208 Y2K Error. MainView for CICS Statistics SMF type 110
IMACICBB special subtype 0B02x records cause year 2020 in 2000:
VMAC110 -in the IBM Statistic Header COLLTIME/STARTIME variables,
Aug 28, 2000 because the BMC type 110 subtype 2 record for CICS 4.1
did not update the SMFMNMFL Maintenance Level field.
That field was updated for IBM type 110 subtype 2 by
PN69653, which changed the date format from YY to YYYY.
With the MFL still zero, MXG assumed the old YY format
and generated the wrong dates. As it's too late for
BMC to fix their error, MXG now tests the ORIGSUBT to
recognize 4.1 BMC records with the YYYY date format.
Logic in VMAC110 was enhanced to protect BMC.
-in the unique datetime variable in all CICSBBxx datasets,
the BMC documentation showed binary (PIB) for their new
YYYY,MO,DD dates, but now with data records, those fields
turn out to be unsigned-packed (PK) format, so member
IMACICBB was corrected.
Thanks to Hartmut Peter, R+V Allgemeine Versicherung AG, GERMANY.
Change 18.207 Documentation for MXG Support for BMC MainView products.
DOC Member Infile Product/Description
Aug 28, 2000 ASMMNVW n/a INFILE Exit for Compressed BMC data
TYPEBBMQ BBMQVSAM MainView for MQ
TYPECMFV CMFVSAM MainView for OS/390, MMR, CMF-VSAM.
TYPECMF SMF MV for OS/390, CMF User SMF record.
TYPECIMS IMSLOG MainView for IMS
TYPEMVCI CMRDETL MainView for CICS CMRDETL/CMRFILE.
IMACICBB SMF MV for CICS Type 110-2 Stat records.
TYPEDB2 SMF MainView for DB2 (no unique records).
Change 18.206 Three TMON V2 Segments did not have the offset variable
VMACTMO2 in their INPUT statement, causing misalignment. The
Aug 27, 2000 offset variables that were added to their INPUT:
TRDSAOFF,TREXPOFF, and TRXMCOFF, for datasets MONIDSA,
MONIEXP, and MONIXMC.
Thanks to Alex Benny Nielsen, TeleDanmark IT, DENMARK.
Change 18.205A The xxxxCMFV members were named for "CMF-VSAM", because
VMACCMFV member xxxxCMF already existed (for the CMF user SMF
Aug 27, 2000 record), and the records came with the BMC CMF product.
Change 18.205 However, the records that xxxxCMFV processes are actually
created by the MMR component of the "New CMF" product,
but as the records are common to both the "CMF" and the
"MMR" products, they exist even if you have only "MMR"
(for example, if you use RMF instead of the "old CMF"
part of the "New CMF" product).
Five datetime variables in ZNTS format are now decoded
(PIB6.2 seconds since 1JAN1980, IB2. minutes GMT offset,
and add 63115200 seconds for the 1960-1980 delta).
The corrected variables are
SYREXTDI SYREXPTI GLSTDAY1 GLSTDAY2 RWREDATE
Thanks to Bill Blair, BMC, USA.
Change 18.204 Major rewrite of ASUMUOW to add variables, make it
ADOCUOW simpler for you to add or delete variables, add the
ASUMUOW possibility of MQ series data, and allow you to break
JCLUOWV the processing of DB2 and CICS data into separate jobs
VMXGUOW to increase parallelism and decrease run times.
Aug 26, 2000
Sep 25, 2000 In larger installations, the processing of CICS and DB2
data can be extremely time and resource consuming. In a
large shop, over 120 million CICS transactions/day are
processed and over 3 million DB2 accounting records in
3 separate runs per day. Each of these creates 5-6
3490 volumes of CICS transaction data and 1-2 of DB2
data. The total processing time often exceeds 18 hours
per day. In the event of an ABEND, recovery time is
very painful.
Consider the flow of the processing. TYPE110 reads the
SMF data and creates the CICSTRAN dataset. This must
be sorted and then read by ASUMUOW. That means that 5-6
cartridges of data are read and written by TYPE110, read
and written by SORT, and read by ASUMUOW. If we assume
6 cartridges for each, then there are 5 full passes of
the data (a total of 30 cartridges!)
Now revise the flow so that a VIEW is used to pass the
data directly from TYPE110 into the SORT. Two full
passes of the data (writing it from TYPE110 and reading
it in the SORT) are eliminated. At 10 minutes per tape
this adds up to about 2 hours of processing time in each
of the three cycles of CICS data per day!
Member JCLSUOW is a set of JCL containing three jobs.
Job TYPE110V executes TYPE110 to read only the CICS
transaction data and sort it into the correct sequence
for ASUMUOW keeping only those variables needed by
ASUMUOW. TYPEDB2V process all of the DB2 data and uses
a VIEW to pass the DB2ACCT data into the SORT for
ASUMUOW. All other DB2 data uses the normal sorts and
processing for DB2. ASUMUOWV uses the output of the
first two jobs as input to ASUMUOW.
ASUMUOW now contains some substitution style macros
for keeping lists of variables and datasets and uses a
new macro VMXGUOW to dynamically build the code to
perform the summarization so that adding and deleting
variables is much simpler (you don't have to invent new
variables names for all of the counters!)
Substitution MACROS in ASUMUOW:
_LASSPIN - SPIN.SPINUOW - OUTPUT SPIN DATASET
_PRESPIN - SPIN.SPINUOW - INPUT SPIN DATASET
_TMPSPIN - TEMPSPIN - INTERMEDIATE SPIN DATASET
_SUUOW - &PSUUOW..ASUMUOW - FINAL OUTPUT
_WSUUOW - NOT USED
_KSUUOW - NOT USED
_BSUUOW - NETSNAME UOWTIME UOWIDCHR - SORT ORDER
_SSUUOW NOT USED
_NOBS - %%VMXGOPTR(OPTNAME=OBS,NEWVALUE=0);RUN;
Controls number of observations
Must be overridden in member IMACUOW
(by completing comment statements)
to create observations in PDB.ASUMUOW.
_YESOBS - %%VMXGOPTR(OPTNAME=OBS,NEWVALUE=MAX);RUN;
Resets number of observations
Must be overridden in member IMACUOW
(by completing comment statements)
to create observations in PDB.ASUMUOW.
_TRANUOW logic to determine which transaction name
is the real transaction name
_SPINUOW - 7 How many spins
_LASCICS &TEMP01..TEMPCICS - intermediate CICSTRAN
_LASDB2A &TEMO02..TEMPDB2A - intermediate DB2ACCT
_LASMQ WORK.TEMPMQM - intermediate MQMACCT
_INMQ _NULL_ - input MQMACCT dataset
_KUOWCIC list of variables to be kept and accumulated
from CICSTRAN
_KUOWDB2 list of variables to be kept and accumulated
from DB2ACCT
_KUOWMQ list of variables to be kept and accumulated
from MQMACCT
_SUOWCIC the sort of the CICSTRAN dataset
_SUOWDB2 the sort of the DB2ACCT dataset
_SUOWMQ the sort of the MQMACCT dataset
_SUOSPN building of the intermediate SPIN dataset
VMXGUOW parameters:
INCODE= A stub of code executed
during INPUT processing
INCICS= A stub of code executed
when a CICS record is found
INDB2 = A stub of code executed
when a DB2 record is found
INMQ = A stub of code executed
when an MQ record is found
INSPIN= A stub of code executed
when a SPIN record is found
OUTCODE= A stub of code executed
during OUTPUT processing
Currently calculates
CLASS3 DB2 times and counts
and SQL counts
CICSVARS=_KUOWCIC variables kept and counted
for CICS
DB2VARS=_KUOWDB2 variables kept and counted
for DB2
MQVARS=_KUOWMQ variables kept and counted
for MQ Series
If all you do with ASUMUOW is a %INCLUDE, you will
not need to make any changes.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.203 RMF Paging Activity Report: corrected values for LPA and
ANALRMFR CSA columns named NON SWAP BLOCK and NON SWAP NON BLOCK.
Aug 25, 2000
Change 18.202 Some DB2 statistics variables, new in DB2 6.1, were input
VMACDB2 but were not deaccumulated, so their values were wrong.
Aug 25, 2000 This change does not affect the DB2ACCT dataset, which
Sep 5, 2000 contains interval values (i.e., valid); it is only the
statistics records that have accumulated values that must
be deaccumulated in MXG logic.
-Group Buffer Pool variables in DB2GBPST/DB2STATS/DB2STAT1
datasets were not deaccumulated:
QBGLAX QBGLAY QBGLAZ QBGLCC QBGLCK QBGLCS
QBGLDG QBGLDN QBGLRB QBGLRD QBGLRG QBGLUN
Don found this error because he knew that QBGLUN must
be lots less than QBGLRC. I had INPUT and KEEPt them but
failed to update the _SDB2PST and _SDB2ST1 macros that do
the deaccumulation. This cause me to examine the other
variables added to the statistics records, and I found:
-QXxxxxx variables in dataset DB2STATS/DB2STAT1 dataset
were only INPUT, and were neither kept nor deaccumulated:
QXALPRO QXALUDF QXCASCDP QXCAUD QXCAUDAB QXCAUDRJ
QXCAUDTO QXCRATB QXROIIDX QXROIMAT QXROITS QXROWTRG
QXSTLOBV QXSTTRG QXTRGERR
-Sep 5: Variables QBGBGR1 and QBGBGR2 were moved from the
$HEX8. to $HEX12. format list; they are 6 bytes long but
with the shorter $HEX8. format, they appeared to be blank
when the first four characters were blank or nulls.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.201 The four variables that measure bytes are now formatted
VMACTCP with MGBYTES so the values will be more readable in the
Aug 24, 2000 units of /KB /MB /GBytes. The four variables are:
APIBYTIN APIBYTOU FTPBYTEC TELINBYT TELOUBYT
Thanks to Chuck Hopf, MBNA, USA.
Change 18.200 The Workload name printed only the first two characters.
UTILRMFI A LENGTH WORK $8; statement had to be inserted after
Aug 25, 2000 each of the INCODE= arguments.
Thanks to David Ehresman, University of Louisville, USA.
Change 18.199 The High Impact (Low UIC), Medium Impact (Medium UIC),
VMAC71 Low Impact (High UIC), and Available Impact frame count
Aug 25, 2000 fields for CStore and for EStore were added to TYPE71 by
Sep 5, 2000 OS/390 R2.4, but only now, as a result of Peter's looking
Sep 12, 2000 at real numbers after seeing a presentation by Martin
(who had them added to type 71), and with free advice
from Don Deese (who first documented their cousins in RMF
type 99), MXG now correctly decodes those twenty-four
memory measurements into these variables:
HI mn/mx/av HI mn/mx/av
CSFR ME mn/mx/av ESFR ME mn/mx/av
LO mn/mx/av LO mn/mx/av
AV mn/mx/av AV mn/mx/av
The field values are accumulated between adjacent values;
it is necessary to subtract MED from HI to get HI values,
LOW from MED to get MED, and AVAIL from LOW to get the
LOW values. Because the MED memory is quite small with
the current IBM-set UIC buckets, its average value was
often a small negative value; in those cases, the MED are
set to missing, and HI-LO is used for HI values. Fields
are in frames, but as the variables were never correct, I
converted all CSFR/ESFR variables to bytes, formatted
them with MGBYTES, and re-labeled them as IMPACT MEMORY.
Martin's paper precipitated creation of additional memory
measures, based on average values that are now created in
MXG's TYPE71 dataset:
CSFRSRAV "SRM-BUFFER" in CSTORE
ESFRSRAV "SRM-BUFFER" in ESTORE
The frames needed to support the Available
Frame Queue, calculated by subtracting the
new free size from the old free size.
CSFRWLAV "Free as Seen by WLM" in CSTORE
ESFRWLAV "Free as Seen by WLM" in ESTORE
The free memory as seen by WLM, calculated
by removing the SRM-Buffer value from the
CSFRAVAV/ESFRAVAV values.
But the "Impact" memory includes only the UIC-updated
pages. WLM updates UICs in Expanded, but not DREF nor
hiperspaces, (but hiperspace size is in TYPE71). Also,
fixed frames and nucleus frames are not UIC-updated (but
they also are in TYPE71). Since the installed CSTORE and
ESTORE memory is known, the missing piece of memory is
all of the memory owned by all of your logically swapped
ASIDs plus any storage isolated pages!
With this change and these new variables, the CSTORE and
ESTORE memory is mapped by these MXG variables:
Online memory CSTORE ESTORE
Logically Swapped CSFRLSAV ESFRLSAV
Fixed CS, Hiper ES CSFRFXAV ESFRHSAV
WLM-viewed Free Memory CSFRWLAV ESFRWLAV
SRM-Buffer Memory CSFRSRAV ESFRSRAV
Low-Impact High-UIC Memory CSFRLOAV ESFRLOAV
Med-Impact Med-UIC Memory CSFRMEAV ESFRMEAV
Hi-Impact Low-UIC Memory CSFRHIAV ESFRHIAV
Because we are adding averages to averages, the measures
are not perfect, and small negative values can still show
up for the MN and MX values, but this provides a complete
picture of how your CSTORE and ESTORE are being used.
Sep 5: The calculation of CSFRFXAV was corrected to use
FIXEDAV instead of PRVFXAV for the fixed memory.
These new CSFRxxxx measures above were compared with the
existing CSTORE72 and ESTORE72 variables in RMFINTRV and
TYPE72/TYPE72GO datasets; those type 72 measurements are
based on resident frame time, and are more accurate than
the averages of averages, in my opinion, and they also
provide memory usage by SRVCLASS/PERFGRP so you can tell
which tasks are occupying how much of your memory.
Sep 12: CSTORE and ESTORE creation was moved up in the
code so that CSFRLSAV and ESFRLSAV are not missing.
Thanks to Martin Packer, IBM, EUROPE
Thanks to Peter Webber, CIS, UK.
Thanks to Tony P. Steward, Post Office, UK.
Change 18.198 TYPE103 variable BYREADCA could have negative values and
VMAC103 contained only the bytes portion of Bytes Read From Cache
Aug 23, 2000 while variable KBREADCA contained only the bytes from the
KiloByte part of the total. Now that IBM revised their
field descriptions, I can correctly sum the KB*1024 plus
the Bytes, and that value is stored in both variables;
both contain bytes and are formatted with MGBYTES format,
and now both describe total bytes read from cache.
An eight byte binary field would have been better!
Thanks to Rex Elbert, SPRINT, USA.
Change 18.197 Support for APAR II11493 changes to SMF type 50 VTAM
FORMATS Statistics record (INCOMPAT) adds new subtype 03 and
VMAC50 restructures that record different from other subtypes.
Aug 22, 2000 The new record provides statistics for TCP connections.
Thanks to Mark Rosen, Office Depot, USA.
Change 18.196 Support for APAR PN61399 (corrects TELNET SMF LOGF record
VMACTCP 'SAVF' in error instead of 'LOGF') adds 'SAVF' to the
Aug 21, 2000 commands that MXG recognizes as TELNET SERVER record, so
even if you don't have the APAR installed, MXG protects.
Change 18.195 Cosmetic. Comments in EXPDBSTP containing the old macro
EXPDBSTP names (prior to MXG 16.04 changes) were revised to show
Aug 16, 2000 the current macro name, _LDBSTEP, in the example.
Thanks to Patrick Julien, France Telecom, FRANCE.
Change 18.194 Error: INVALID DATA FOR GDESIS because the input should
VMACQAPM have &PD.3. instead of &PD.4., but this field indicates
Aug 16, 2000 the data is from Collection Services and not QAPM.
Thanks to Joe Faska, Depository Trust, USA.
Change 18.193 Support for new NTSMF object "SESSION", previously named
VMACNTSM "TERMINAL SERVICES SESSION and with seven new fields:
Aug 16, 2000 ELAPSTM PID PRTYBASE TOTPROHI TOTPROHR TOTPRORE
UNKNCTR1
and removes two:
TOTRANER TOTAL*TRANSPORT*ERRORS
OUTRANER OUTPUT*TRANSPORT*ERRORS
INTRANER INPUT*TRANSPORT*ERRORS
and one unnamed counter is thought to be HANDLES, so the
new record has a total of 80 data fields. It is still
output to the TERMSESS dataset.
Thanks to Luc Gariepy, Regie des Rentes du Quebec, CANADA.
Change 18.192 MXG 18.05-18.06 only INPUT STATEMENT EXCEEDED RECORD. The
VMAC16 +6 before ICEOTBKF should have been +2.
Aug 16, 2000
Thanks to Shabida Khan, Royal Bank, CANADA.
Change 18.191 PSBNAME, added by Change 18.083A was blank because it was
VMACCIMS inserted in the wrong KEEP= list. It should have been
Aug 16, 2000 immediately before _KIMFTRX instead of _KIMFPGM so it
is kept in CIMSTEMP instead of CIMSPROG.
Thanks to Tammy Wellstood, Clarica, USA.
Change 18.190 Year 2000 support for BMC CICS Manager data segments in
IMACICBB type 110 records was incorrect, causing year to be 2020
Aug 15, 2000 instead of 2000. Change 15.179 had never been
tested with Y2K data, and its change was incorrect for
each of its six datetime variables.
Thanks to ???, ???, EUROPE.
Change 18.189 If you had the same name for both a Service Class and a
TRND72GO Reporting Class, TRND72GO lumped them together. Adding
Aug 12, 2000 variable RPRTCLAS at the end of the SUMBY= now separates.
Thanks to Mike Schwencer, Banner Health, USA.
Change 18.188 CICS type 110 Journal (Subtype 0) with GLRHTYPE=2 caused
VMAC110 an INPUT STATEMENT EXCEEDED RECORD error. The statement
Aug 11, 2000 IF CLUPRLE GT 0 THEN INPUT +CLUPRLE @; should not have
been there, and has been deleted (those bytes are read by
the included exit member and the double read were wrong).
Thanks to Shoab Kamran, U.S. Postal Service, USA.
Change 18.187 Support for APAR OW43854 adds new fields to SMF type 62
VMAC62 VSAM OPEN and especially to the SMF type 64 VSAM CLOSE
VMAC64 record, finally adding the OPENTIME of the VSAM file, so
Aug 9, 2000 it is no longer necessary to merge 62 and 64 just to get
the OPENTM duration of a VSAM file! New ACB bits are
also decoded; these variables are added to TYPE64:
ACBMACR4='ACBMACRF*BYTE*FOUR'
OPENTIME='DATETIMESTAMP*WHEN THIS*FILE WAS*OPENED'
OPENTM ='DURATION*THIS FILE*WAS OPEN'
SMF64FG1='MISCELLANEOUS*FLAG*ONE'
SMF64RSC='SMB*INFORMATION'
SMF64SMB='SMB*ACCESS*BIAS*INFORMATION'
ACBBWO ='ELIGIBLE*FOR BACKUP*WHILE*OPEN?'
ACBCCT ='CONTROL*CHARACTER*TYPE?'
ACBJES ='OUTPUT*AND*JES*?'
ACBNLEX ='NO LSR*EXCLUSIVE*CONTROL?'
ACBRLS ='RLS*PROCESSING?'
ACBSNP ='SNP*OPTION?'
-TYPE62 was also enhanced: the OPENTIME variable was added
and all four ACBMACRx bytes were added, so all of the MXG
ACBxxxxx variables in TYPE64 now also exist in TYPE62.
-The new data fields were added compatibly, using either
previously reserved fields or added at the end.
Dec 2005 note: APARs OW45393 and OA03866 reference the
"new" OPENTIME field, but they were already supported and
no additional code changes were needed for those APARs.
Change 18.186 An extra observation in PDB.STEPS can result if a step
BUILD005 with multiple TYPE30_4 records (MULTIDD='Y') has some of
BUIL3005 the records in today's SMF file and the rest are at the
Aug 9, 2000 start of tomorrow's SMF file, i.e., when MULTIDD='Y' step
records are "spun" today and re-introduced tomorrow.
Fortunately, that extra observation has zeroes in all of
the resource variables, so there is no real impact, but
it should not have been created, and is confusing, with
STEP=0, MULTIDD=' ' instead of MULTIDD='Y', and SYSTEM is
blank. The spun MULTIDD records (SPIN30_4) are combined
with today's new MULTIDD records (TYPE30_4) into GOOD30_4
which is then sorted for its SET with GOOD30_5 to create
STEP number, but that sort of GOOD30_4, did not ensure
that the real MULTIDD=' ' step record was always first.
If any spun records with MULTIDD='Y' were physically
before the real MULTIDD=' ' step record, they created the
extra STEP=0 observation!
The original BY list of READTIME JOB JESNR SORTTIME (with
SORTTIME=INITTIME of the step) was expanded to now be by
READTIME JOB JESNR SORTTIME MULTIDD DESCENDING EXTRADD
as this forces the real step record to be first, and also
sequences the MULTIDD='Y' in the order they were written,
by that addition of DESCENDING EXTRADD to the BY list.
Variable RDRTM was removed for the TYPE30_4 keep list, as
it exists only in the TYPE30_1 and TYPE30_5 datasets.
Thanks to Mat Elbersen, Rabobank, THE NETHERLANDS.
Change 18.185 NETVIEW SMF 39 record with invalid ROUTE segment caused
VMAC39 INPUT STATEMENT EXCEEDED RECORD LENGTH. The record looks
Aug 9, 2000 like it was overlaid starting in the SCS section with the
LSESCOSA filed, thru the APPN and ROUTE segments. MXG
added test to INPUT only if there is enough data left in
the record, while investigating the cause of the record.
Thanks to Bruno Peeters, Dexia Bank, BELGIUM.
Change 18.184 Datasets TYPE7 and TYPE23 are now automatically created
BUIL3001 in your PDB library by BUILDPDB/BUILDPD3 programs. The
BUIL3606 PDB.TYPE7 dataset will have observations only if there
BUILD001 was a loss of SMF records. The PDB.TYPE23 dataset has
BUILD002 one observation per SMF interval with the activity to the
BUILD606 SMF datasets, and is useful in tracking down the cause of
BUILDPDB any TYPE7 SMF Data Lost events. Both are very small.
BUILDPD3 Note: if you tailored BUILDPDB to add either of these two
Aug 9, 2000 datasets, you must back out your tailoring in the members
EXPDBINC, EXPDBVAR, EXPDBCDE, and EXPDBOUT.
Change 18.183 The EREP Symptom Record was output to EREPSIM instead of
VMACEREP to EREPSYM; the _EERPSIM in line 2680 should have been
Aug 9, 2000 _EERPSYM.
Thanks to Peter Webber, CIS, ENGLAND.
Change 18.182 VMXGSUM enhancements - 4 major changes:
VMXGSUM -Small differences in results could be seen if INHERIT is
VMXGENG used with V8 to set the lengths of variables and bypass
VMXGINIT the second data step. VMXGSUM was modified to only use
Aug 9, 2000 the inherit option when the data step can be bypassed
Aug 26, 2000 (when no OUTCODE= or NORMx= operands are specified.)
-If TEMP01 or TEMP02 was used and they were sequential
format datasets, the MXGSUM1 and MXGSUM2 datasets were
left in place. Since this can cause subsequent uses
of VMXGSUM to run longer and a PROC DATASETS will fail
on a sequential format dataset, macro %VMXGENG now exists
to detect the ENGINE for a LIBNAME and to set the global
macro variable &MXGENG to contain the ENGINE name, so
that either a PROC DATASETS or LIBNAME DDNAME CLEAR;
LIBNAME DDNAME ENGINE; will be done to appropriately
reset the work files.
-If KEEPALL=YES is used, more WORK space may be required
because there was no KEEP= list on the MXGSUM1 dataset.
So now a KEEP= list (the UNION of all parameters sorted
with duplicates removed) is created, and this is a better
than KEEPALL=NO or KEEPIN=xxxx since it avoids all of the
resources needed to determine what variables exist.
-Significant savings can be had by avoiding the physical
I/O involved in the first data step. This is now done by
using a VIEW on MXGSUM1, but since a VIEW will not work
on a sequential format SAS dataset, the new logic detects
that a sequential engine is being used and instead uses
a data step within the INCODE instead of a VIEW.
In a test of ASUMDB2A with 1743212 OBS in input DB2ACCT
dataset the following results were attained:
CPU EXCP WORK TRACKS
Current 16.75 minutes 124805 117630
New 11.82 100178 59442
-The new %VMXGENG macro can be used to detect the engine
for a LIBNAME/DDNAME, using this syntax:
%VMXGENG(DDNAME=xxxxxxxx);
The name of the SAS engine is returned in the global
macro variable &MXGENG.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.181 Variable CLASS3WT was incorrect in ASUMUOW if there was
ASUMUOW any WAIT FOR IO UNDER DIFF THREAD, variable QWACARNW.
Aug 9, 2000 The count rather than duration variable was in the SUM.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.180 Variable DEVTYPE now supports TRTCH values of E8x,E9x for
VMACTMS5 3590 and 3590E devices, although you must manually update
Aug 8, 2000 the TRTCH value in TMS.
Thanks to Renzo Serena, ENEL, ITALY.
Change 18.179 Variable QLACMDWT, elapsed time waiting because the max
VMACDB2 number of DBATS has been exceeded, is now input and kept
Aug 8, 2000 in DB2ACCT dataset.
Thanks to Phil Downes, ABN AMRO Bank, THE NETHERLANDS.
Change 18.178 DB2 Version 6.1 only, IFCID 106. The end of comment was
VMAC102 missing in line 11081.
Aug 4, 2000
Thanks to Harald Seifert, HUK Coburg, GERMANY.
======Changes thru 18.177 were in MXG 18.06 dated Jul 28, 2000======
Change 18.177 Report example that uses ANALCNCR and PROC TABULATE and
ANALHTML produces reports in HTML format using ODS.
Jul 28, 2000
Thanks to Chuck Hopf, MBNA, USA.
Change 18.176 Doc only. Support for APAR OW45168's minor changes to
VMAC94 SMF Type 94 were already in place in MXG.
Jul 28, 2000
Change 18.175 MXG 18.05 only. INVALID DATA FOR PHMSDATE because three
VMACIDMS debugging lines were incorrectly left. Delete the three
Jul 28, 2000 lines (1223-1226) starting IF PHMRTYPE=18 THEN ....
Thanks to Wim Desmecht, DOLMEN, BELGIUM.
Change 18.174 Documentation only. Comments in both members still had
ASMIMSL5 LRECL=132 for the IMSSUM,INQUEUE, and OUTQUEUE DD names,
ASMIMSL6 but the correct LRECLs (which are ok in the JCLIMSLx's)
Jul 28, 2000 are 136 for V5 and 144 for V6. If you used our old JCL
with incorrect LRECL value, you got IEC141I 013-20 ABEND.
Thanks to Brian Sanger, Zurich Financial Services, ENGLAND.
Change 18.173 Support for OS/400 Release 4.5.0 (INCOMPAT LRECLs and
VMACQAPM data was inserted in the QAPMETH record). If you don't
Jul 27, 2000 use the QAPMETH record, you can change the LRECLs as
Sep 19, 2000 indicated for QAPMBUS, QAPMJOBS, and QAPMSYS, and the
previous MXG Version will work with 4.5 records.
-QAPMBUS has an undocumented single byte character field
added, changing it's LRECL from 111 to 112. New variable
BUCHAR created, was always 'S' in my sample records.
-QAPMETH had six fields with undocumented length changes.
The suffixes MEXR, MM14, MTR, and MDCN increased from 3
to 6 bytes, and MBRV and MBTR increased from 6 to 8.
The LRECL is now 257 for QAPMETH.
-QAPMJOBS has two undocumented 8-byte fields added at the
end of the record, variables JBUNDOC1/JBUNDOC2. The
LRECL for QAPMJOBS is now 835.
-QAPMSYS has five undocumented 4-byte fields added at the
end of the record, variables; the QAPMSYS LRECL is 3288.
Sep 19, 2000: The undocumented variables are now named,
but I still have no description of their contents:
JOBS: JBEDBC, JBTDBC SYS: SYIFUS, SYIFTE, SYDBC, SYSWC
SYSTEM: SCIFUS SCIFTE SYHFTH SYSDBC SYSSWC
BUS: BUTYPE
Thanks to Stuart R. Burnett, Reynolds Metal Corporation, USA.
Change 18.172 Support for APAR PQ32435 OS/390 IHS WEBSERVER SMF 103
VMAC103 adds variables JOB and ASID to the TYPE1032 dataset.
Jul 27, 2000 The APAR also describes changes in values put into the
"EntityName" and "EntityAddress" fields, and documents
when the interval value is not the expected interval:
- The initial write on startup has an interval of zero.
- The termination write on shutdown or restart has an
interval of the time since last write.
- The initial write on restart has an interval of the
time since the restart termination write.
Change 18.171 MXG's protection logic for TCP SMF 118 records with bad
VMACTCP HFS Filename offsets or lengths was still incomplete and
Jul 27, 2000 permitted INPUT STATEMENT EXCEEDED errors. Logic was
revised and the first two bad records are printed on the
SAS log. This supercedes Change 18.144.
Thanks to Francis Berckman, Astra Zeneca, USA.
Change 18.170 MXG 18.04-18.05 only. Variables ONLINE,CMBINVLD,PARTIAL,
VMAC74 BASE, and VARY were always blank. The five lines setting
TYPE74 those variables blank were not removed after the logic to
Jul 26, 2000 set those variables was moved up thirty lines.
Jul 28, 2000
Thanks to Diane Parker, Bergen Brunswig, USA.
Thanks to Peter Webber, CIS, ENGLAND.
Change 18.169 Variable PERFINDX was incorrect in TRND72GO because the
TRND72GO variables R723CVAL and R723CPCT should have been in the
Jul 26, 2000 ID= list, and not in the SUM= list.
Thanks to Pat Perreca, Bear Stearns & Co., USA.
Change 18.168 Documentation. The SAS option USER=XYZ can be used to
DOCMXG send "//WORK" datasets instead to the "//XYZ" DDname.
Jul 25, 2000 However, for MXG to recognize the USER=option, it needs
Oct 11, 2002 to be set before MXG initialization has executed:
OS/390: put USER=XYZ on the EXEC statement:
//STEPNAME EXEC MXGSAS,OPTIONS='USER=XYZ'
ASCII: put USER=XYZ in the AUTOEXEC.SAS file:
LIBNAME XYZ 'C:\XYZ';
OPTIONS USER=XYZ;
If you must put the USER= option in your //SYSIN stream,
then you must insert a %VMXGINIT; statement after it:
//SYSIN DD *
OPTIONS USER=XYZ;
%VMXGINIT;
which will re-invoke the MXG initialization using your
USER= value (printing a second "WELCOME TO MXG" message).
If the USER= value is put in //SYSIN without the VMXGINIT
MXG will not see your USER= option. If you have USER= on
the // EXEC, and you also have USER= and VMXGINIT in your
//SYSIN, the USER= in SYSIN will be used because of the
second MXG initialization.
Putting USER= on the //EXEC statement is preferred, as it
does not require the extra cost of the second VMXGINIT.
An alternative for re-directing datasets in the //SYSIN
is to use the %LET Wdddddd=XYZ; syntax for the "work"
copy of the unsorted dataset (or use %LET Pdddddd=XYZ;
for the sorted, "PDB" copy). The "dddddd" value for each
MXG dataset is documented in the IMACxxxx member for the
product that creates the dataset.
Oct 11: text was revised for clarity.
Thanks to Mike Delaney, Pershing, USA.
Change 18.167 New variables QBGBGR1N and QBGBGR2N are input as numeric
VMACDB2 variables. The original variables QBGBGR1 and QBGBGR2
Jul 25, 2000 were input as characters (because I didn't realize what
they were), and worse, while input as $EBCDIC6, they were
truncated to a kept length of only $4 because they were
in the $HEX8 format item list! Now the character vars
are kept as full length (by moving to $HEX12 format), and
numeric counterparts now exist in DB2GBPAT dataset for
Global Buffer Pools counts of current or pending
directory entries.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.166 The new R744Cxxx variables in the TYPE74ST Structure data
VMAC74 set were wrong if there were more than one segment, due
Jul 25, 2000 to a typo: the 26 lines with SUM(R744Caaa,R744Caaa) were
changed to SUM(R744Caaa,R744Xaaa). The
RLS and OSAM structures have 20+ and 60+ segments each,
but DB2 group buffer pools have only one segment so their
counts were always correct.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.165 New format MGBYTEN converts bytes to KB/MB/GB/TB/PB like
FORMATS existing format MGBYTES, but MGBYTEN handles negative
Jul 25, 2000 and positive byte values (to track increase/decrease in
DASD memory) so it must be 6 characters wide to have room
for the minus sign, so it had to be a different name than
the 5-character-wide MGBYTES format.
Thanks to Tan York Sin, Singapore Exchange Limited, SINGAPORE.
Change 18.164 Support for Release 321 INCOMPATIBLY changed time stamp
VMACBETA formats for BETABT and BETASTRT. More testing may be
Jul 25, 2000 required if other fields were changed, as only the one
subtype=1 record was received for validation.
Thanks to ???, ???, EUROPE.
Change 18.163 Statement IORATE=0; was removed. The devices with no
ANALCACH cache records needed to have cache-related fields zero,
Jul 25, 2000 but not the IORATE.
Change 18.162 Support for DFSMS/rmm TYPEEDGS/TYPEEDGB was still wrong.
VMACEDGS Zero obs or INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Jul 25, 2000 The "D" and "V" dataset/volume records did change in 1.5
Sep 5, 2000 but the old-format 1.4 records still exist in the catalog
dataset. And the handling of variable length name fields
that worked in 16.16 was somehow lost. In any event, the
change has been tested with TYPEEDGB reading a catalog
with both formats of both records, and works correctly,
using the MD/MVRECLEV variable to identify record format.
There are some 1.4 records that have '40'X in their name
length fields, and have enough record length to contain
a DSN, but they do not contain real DS names; however,
they also do not cause any error.
Sep 5: Variable MVRETDAT was not kept.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales, USA.
Taught classes in Amsterdam and London.
Change 18.161 Y2K support was incorrect, but nobody noticed! Inserted
VMACAXC IF IDTE LT 1900000 THEN IDTE=IDTE+1900000; and changed
Jul 7, 2000 each IDTE,5.),JULIAN5. to IDTE,7.),JULIAN7.
Thanks to Stephen Bell, Informatik Kooperation, GERMANY.
Change 18.160 The %INCLUDE of member IMACKEEP was missing from a number
DOC of MXG TYPExxxx and TYPSxxxx members, which prevented use
Jul 7, 2000 of the new-in-16.04 architecture for instream tailoring.
Most are archaic or not mainstream. Members updated were:
TYPxCRAY TYPxFRYE TYPxHO15 TYPxHPAI TYPxHPCS TYPxHPSU
TYPxHPUX TYPxIMFL TYPxIMS TYPxIMS1 TYPxMWAI TYPxMWSU
TYPxMWTE TYPxMWUX TYPxPW TYPxQTRT TYPxRMF TYPxSAM
TYPxSFS TYPxSNIF TYPxSUPR TYPxTRSN TYPxTUX TYPxVMON
TYPxVMXA TYPxXAM TYPxZARA TYPxZRB TYPEIMSD
Thanks to Bart Decat, KBC Belgium, BELGIUM.
Change 18.159 WARNING: ARGUMENT 3 TO MACRO FUNCTION %SUBSTR IS MISSING
ANALDB2R occurs with SAS Version 8.1, because the length of their
BUIL3001 &SYSVER Version macro was shortened from four to three.
BUIL3005 There is no execution impact, fortunately, except that
BUILD001 the warning now sets a step Condition Code/Return Code of
BUILD005 four instead of zero, and wastes your time in diagnosis!
BUILDPD3
BUILDPDB In Version 8.1, SAS changed the length of their &SYSVER
READDB2 macro from four digits (6.06,6.07,6.08,6.09,8.00) to only
VMXGFOR three digits (8.1), but MXG used %SUBSTR(&SYSVER,1,4):
VMXGINIT to differentiate 6.07 from 6.08, so that options that
VMXGSUM were new in 6.08 would be bypassed under 6.07. While
Jul 6, 2000 the %SUBSTR fails, because the option now exists in
SAS releases, there is no execution error. And the
only purpose was to suppress unneeded SAS messages!
To eliminate this exposure in future SAS Version names,
all MXG references to &SYSVER were revised. Now, all
tests for SAS Version use the MXG-created macro variable
&SASVER, which is set by VMXGINIT from &SYSVER to the SAS
Version number (6, 7, 8, etc.). All of the old 4th-digit
of &SYSVER tests are no longer required:
The tests that set OPTIONS CODEPASS=2 were removed
completely, as that option no longer exists and is no
longer set, and tests around OPTIONS DKROCOND= were
also removed, as that option is now present in all
executable SAS versions.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 18.158 The NTSMF Trending macro variables PTRNTIN and PTRNTLD
VMXGINIT were not defined in VMXGINIT. Three labels in VMACNTSM
VMACNTSM longer than 40 characters, that were not caught by the
Jul 6, 2000 SAS compiler when VMACNTSM ran, but were caught when the
data set was copied.
Thanks to Howard Glasetter, Weyerhaeuser, USA.
Change 18.157 The example REPORT command in the ADOCMWUX member did not
ADOCMWUX create the file that was expected by VMACMWUX, so that
VMACMWUX command was revised to include the new variables that are
Jul 6, 2000 expected. Four variables, TFRSTSEC,TPRMPSEC,TTHNKUSE,
and TPRMPUSE are set missing because I cannot find them
in the current list of MeasureWare fields for HPUX.
Thanks to Roman Gudz, Penske, USA.
Thanks to Bart Decat, KBC Belgium, BELGIUM.
Change 18.156 Variable SMF74CNF was not kept, but not initialized, as
VMAC74 it was INPUT into DEVIND, which was not kept. Now it is.
Jun 30, 2000
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 18.155 MXG 18.05 only. Variables S42DSMXR,S42DSMXS were never
VMAC42 input, having been misspelled as DXMXR and DSMXS in the
Jun 30, 2000 INPUT statement.
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 18.154 were in MXG 18.05 dated Jul 1, 2000======
Change 18.154 ANAL4GB member reports on VSAM files approaching 4GB in
ANAL4GB size, but included Extended VSAM files, which show over
Jun 30, 2000 100% utilized space, so IF SMF64EF='Y' THEN DELETE; was
added so those datasets will not be reported.
Thanks to Alfred Holz, Merck & Co., USA.
Change 18.153 Corrections found during QA runs.
VMAC108 -VMAC108. The KEEP list for TYPE108T and TYPE108P did not
VMAC74 keep the variables DOMSPN and DOMSYN, and DOMDBNAM should
WEEKBLD not have been in _BTY108T.
WEEKBLDT -VMAC74. Two variables R745DCID; the "Real CU ID" variable
MONTHBLD was changed to R745DCIR.
VMACEDGS -WEEKBLD/WEEKBLDT/MONTHBLD. The Sort Order for TYPE72SC
VMACMIM was revised to match the VMAC7072 definition, and is now
VMACTMV2 SYSPLEX SYSTEM STARTIME SRVCLASS
VMACSOLV R723SCSN R723SCSR SMFTIME
VMXGCICI -VMACEDGS. Variable MDPDSN repeated in KEEP and LABEL.
Jun 30, 2000 -VMACMIM. Variable DURATM repeated in KEEP list.
-VMACTMV2. Variable WGMSOSCE repeated in KEEP list.
-VMACSOLV. Variable SOLVFLAG had two formats.
-VMXGCICI. Variable STARTIME repeated in FORMAT.
Thanks to Freddie Arie, Lone Star Gas, USA
Thanks to Bruce Widlund, Merrill Consultants, USA
Change 18.152 New _S110ST and _CICSTAT macros are defined in VMAC110 so
VMAC110 that you can control where the CICS Statistics datasets
Jun 29, 2000 are written. With TYPE110 or BUILDPDB, CICS statistics
Aug 29, 2000 datasets are created in the "WORK" DD; BUILDPDB reads 'em
to create the PDB.CICINTRV summary dataset, but those
individual CICS Statistics datasets are not copied or
sorted; they just die at end of step in the //WORK file.
This enhancement lets you control where they written, if
you want to keep any or all of them.
1. You can write them to the 'CICSSTAT' library, sending
all of the CICS statistics datasets (unsorted) to that
DD as the SMF records are read. You would use this:
after your //SYSIN DD statement:
%LET CICSTAT=CICSSTAT;
_CICSTAT;
The _CICSTAT macro invocation uses the value of the
&CICSTAT macro variable as the destination library for
the &WCICddd and &PCICddd CICS statistics data sets.
If you %LET CICSTAT=PDB; before the _CICSTAT invoke,
CICS stats would be written unsorted to the PDB DD.
2. Alternatively, by default, BUILDPDB builds all CICS
Statistics datasets in the //WORK file, and then reads
them to create the PDB.CICINTRV dataset, but then the
CICS Statistics datasets are left in the //WORK DD,
which is temporary and goes away at step end. You can
thus use the member EXPDBOUT to select/sort any of the
CICS Statistics datasets into your PDB. You can use
individual dataset "_Sdddddd" macros for each dataset
that you want to output, or you can use this new
"_S110ST" macro, which will sort only the Statistics
CICS datasets. (The old _S110 macro can't be
used in EXPDBOUT, because it invokes two _Sdddddd sort
macros, _SCICEXC and _SCICSYS, which were already
invoked by BUILDPDB logic.) Just adding _S110ST in
your EXPDBOUT member will sort all CICS statistics
data to the PDB library. You can also invoke the
_CICSTAT macro in member EXPDBOUT after resetting the
default DD name, can could then sort all of the CICS
statistics datasets into the "MYDD" library, using:
%LET CICSTAT=MYDD;
_CICSTAT;
_S110ST
Note: _S110ST did not exist until MXG 18.07, when the
change was revised.
Thanks to Glenn Bowman, Wakefern, USA.
Change 18.151 INPUT STATEMENT EXCEEDED with NETSPY 5.2 subtype "I" and
VMACNSPY MXG 18.03-18.04. In 5.2, the "I" subtype was for TELNET
Jun 29, 2000 sessions, but NETSPY 5.3 deleted the TELNET data, and
reused subtype "I" record for TCP/IP data. MXG 18.03 now
supports the TCP/IP data, but Change 18.069 did not test
for and delete that now-defunct 5.2 "I" record. The code
test after IF NSPYREC='I' THEN DO; was revised to insert
IF NSPYENTL LE 70 THEN DELETE; since the 5.2 "I" record
segment length was 70.
Thanks to Rita Bertolo, Canadian Pacific Railroad, CANADA.
Change 18.150 Negative values for RANDOM PAGES fields in reports. The
ANALDB2R calculation of variable RANDOMP was incorrectly located,
Jun 29, 2000 and was moved to after MEAN=QB&B.TCBA/NUMINTVL;
Thanks to Gary L. Keers, Indianapolis Power & Light, USA.
Change 18.149 New analysis: Who is filling your active SMF VSAM file?
ANALSMJB This program reads the active VSAM SMF file (or any SMF
Jun 29, 2000 file) and counts how many type 14, 15, 30, 42, and 64 SMF
records in that SMF file were created by each JOB, so
that your operators can use this report to cancel a
runaway job. (The program stops reading SMF records when
it sees a timestamp after the start of this program, so
that SAS does not have to read over all the unused CIs
in your VSAM SMF file).
Change 18.148 Documentation only. Change 17.060 showed example syntax
VMXGINIT of %VMXGINIT(MXGWORK=XYZ); to redirect datasets from the
Jun 29, 2000 //WORK default to the "XYZ" libref, but VMXGINIT changes
(VOPTIONS table, resetting MXGWORK based on SASSWORK and
USERWORK) cause that old syntax to no longer work. If you
should ever need to redirect work, now the correct syntax
is to use OPTIONS USER=XYZ; See also Change 18.168
Thanks to MP Welch, SPRINT, USA.
Change 18.147A-SAS V8 no longer requires the MEMSIZE parameter in the
CONFIGV8 CONFIG member, and in some cases it has caused memory
Jun 29, 2000 ABENDs that were eliminated by removing MEMSIZE, so I
have removed it from CONFIGV8 member. Using REGION=0M
on your JOB card is recommended, but you should be aware
that installation exits IEALIMIT and/or IEFUSI can limit
the virtual storage that be allocated.
-I had to reinstate the S=72 and S2=72 options in CONFIGV8
member. It was removed (Change 17.392) to protect from
potential problems if your SOURCLIB was RECFM=VB, but its
absence caused errors if you had numbered lines in your
MXG Tailoring Library (USERID.SOURCLIB), including 180
syntax ABENDs, and APPARENT MACRO &WORDI UNRESOLVED.
Unnumbering your lines eliminated the error, but so does
putting back the S=72 and S2=72 in the CONFIGV8 member,
and you don't have to touch your numbered lines.
Thanks to John Mattson, Espon, USA.
Change 18.147 The data step previously in the _STYMEMx sort macros were
VMACMEMO replaced with PROC SORT and the _BTYMEMx macros now have
Jun 29, 2000 the correct BY list variables.
Thanks to Fred Kuhstoss, Norfolk Southern Corp, USA.
Change 18.146 Variables S42DSMXR and S42DSMXS were added to TYPE42DS
VMAC42 when they were discovered in the SMF manual.
Jun 29, 2000
Change 18.145 -New TRNDNTLD trends NT DISK Space Utilization using the
BLDNTPDB NTSMF dataset LOGLDISK.
NTINTRV -Hardcode dataset names in BLDNTPDB text were replaced
TRNDNTLD with their _Ldddddd symbolic macro name, and NTINTRV was
VMXGINV changed to use the symbolic, and to %INCLUDE the member
Jun 28, 2000 IMACKEEP so the BLDNTPDB builds a fully compatible code
member that accepts IMACKEEP/MACKEEP= tailoring.
If TRENDing is invoked by BLDNTPDB, both TRNDNTSM and the
new TRNDNTLD are invoked.
Thanks to Greg Jackson, National Life of Vermont, USA.
Thanks to Howard Glasetter, Weyerhaeuser Company, USA.
Change 18.144 Protection for bad length/offset for TCP HFS filename
VMACTCP segments was over slightly in error; some records with
Jun 26, 2000 valid HFS lengths of zero were flagged as in error. The
test for IF 0 LT FTPHFS01 LT LENGTH-1 THEN DO; line 440
and IF 0 LT FTPHFS02 LT LENGTH-1 THEN DO; line 472
were changed IF 0 LT FTPHFS01 LE LENGTH-1 THEN DO; 440
and IF 0 LT FTPHFS02 LE LENGTH-1 THEN DO; 472
so only bad segments with non-zero length are detected.
Thanks to Sal Fazzino, First American, USA.
Change 18.143 -Support for new NTSMF Objects in Windows 2000 Server:
EXNTBENG "dddddd" "dataset" vars description
EXNTDHCP NTBENG BEENGINE 131 BE Engine
EXNTDNS NTDHCP DHCP 14 DHCP Server
EXNTFIRC NTDNS DNS 62 DNS
EXNTFIRS NTFIRC FILREPCO 24 FileReplicaConn
EXNTNTPC NTFIRS FILREPSE 91 FileReplicaSet
EXNTNTPS NTNTPC NNTPCMND 44 NNTP Commands
EXNTNTDS NTNTPS NNTPSERV 40 NNTP Server
EXNTNTSH NTNTDS NTDS 140 NTDS
EXNTWMSS NTNTSH NETSHIEL 40 NetShield
EXNTWMUS NTWMSS WINMEDSS 3 Windows Media Station Service
IMACNTSM NTWMUS WINMEDUS 24 Windows Media Unicast Service
VMACNTSM -And the NTSMF 2.2.2 change that puts back into the SYSTEM
VMXGINIT object the variables PCTCPUTM PCTUSRTM PCTPRVTM that
Jun 27, 2000 Microsoft had previously removed from SYSTEM.
-And the NTCONFIG file was corrected; the CPUSPEDn/FAMILYn
MANUFACn/CPUNUMn fields were RETAINed from each 0,0, but
were not initialized, and so could contain data in the
N+1 fields when the value of NRCPUS was only N.
Thanks to Hansueli Vogt, Credit-Suisse, SWITZERLAND.
Change 18.142 CMA SPOOL record, subtype 6, variable SMFT06PC, added by
VMACCMA Change 18.056, was incorrectly decoded, as a two-byte
Jun 26, 2000 reserved field precedes that field. The DSECT shows a
two byte reserved field after SMFT06PC, but it is not
input (to preserve compatibility).
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.141 Variable DVGSBCNT, the Transfer Byte Count, has always
VMACFTP been wrong; it should have been input as &PD.8., but it
Jun 26, 2000 was documented as binary instead of packed decimal.
Jul 25, 2000 In addition, variable DVGSCFAC should have been &PIB.1.1
but was previously only &PIB.1.
Thanks to John Sheridan, Aer Lingus, IRELAND.
Thanks to Theo Peelen, RABOBANK, THE NETHERLANDS.
Change 18.140 Variables CIOPCT, HITPCT, and RDHITPCT were not being
ASUM42DS recalculated after the summation; the were revised into
Jun 26, 2000 NORM= operands to be properly recalculated as percents.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 18.139 IMS Log Version 5.1 cause zero observations in IMSTRAN
TYPEIMSB in STEP4 of JCLIMSL5, because IF _IMSVERS LE 5 THEN DO;
Jun 22, 2000 should have been IF _IMSVERS LE 5.1 THEN DO; in three
places in member TYPEIMSB.
Thanks to Pete Gain, SAS UK, ENGLAND.
Change 18.138 Additional, optional variables are now decoded from the
IMAC6ESS ESS segment in the type 6 record. Comments in IMAC6ESS
VMAC6 describe how to enable the creation of these variables,
Jun 21, 2000 and how to add them to TYPE6, or to PDB.PRINT. The full
list of TYPE6/PDB.PRINT variables that are decoded from
the ESS/IEFDOKEY optional fields are these:
ADDRESS1='FIRST LINE*OF ADDRESS'
ADDRESS2='SECOND LINE*OF ADDRESS'
ADDRESS3='THIRD LINE*OF ADDRESS'
ADDRESS4='FOURTH LINE*OF ADDRESS'
BUILDING='BUILDING'
DEPT ='DEPARTMENT'
DESTNATN='DESTINATION'
ESSBURST='BURST*IN*ESS'
ESSCHARS='CHARS*IN*ESS'
ESSCLASS='CLASS*IN*ESS'
ESSCOPIE='COPIES*IN*ESS'
ESSFCB ='FCB*IN*ESS'
ESSFMDEF='FORMDEF*IN*ESS'
ESSFORMS='FORMS*IN*ESS'
ESSLINCT='LINECT*IN*ESS'
ESSMODFT='MODIFY TRC*IN*ESS'
ESSMODFY='MODIFY*IN*ESS'
ESSPGDEF='PAGEDEF*IN*ESS'
ESSPRMOD='PRMODE*IN*ESS'
ESSPRTY ='PRTY*IN*ESS'
ESSWRITR='WRITER*NAME*IN ESS'
GROUPID ='GROUP ID'
NAME ='NAME'
ROOM6 ='ROOM6'
TITLE ='TITLE'
Thanks to Todd Wright, CSC, AUSTRALIA.
Change 18.137 Variable CUTSHEET='Y' in dataset TYPE6 and PDB.PRINT was
VMAC6 incorrectly decoded; the wrong bit was tested. It should
Jun 21, 2000 have been IF OPTBIT='..1.....'B THEN vice '.1......'B.
Thanks to Peter Robinson, IGM-GSA, AUSTRALIA.
Change 18.136 The RECTYPE=5 Deleted Data Space Release records were put
VMACICE in ICEBRGDR instead of ICEBRGDE, because the statement in
Jun 21, 2000 the RECTYPE=5 DO group should have been _EICEDEL instead
of _EICEDRV (i.e., the comments were correct).
Thanks to Nick Johns, J. Sainsbury, ENGLAND.
Change 18.135 WEEKBLD and MONTHBLD still had the wrong BY list for the
MONTHBLD TYPE30MU dataset (but WEEKBLDT was correct!). All were
WEEKBLD changed to match variables in the _STY30MU sort macro
Jun 12, 2000 that is used in BUILDPDB:
READTIME JOB JESNR INITTIME SUBTYPE PRODOWNR PRODNAME
PRODQUAL PRODID SMFTIME
Thanks to Michael Creech, ALLTEL, USA.
Thanks to Ed Billowitz, Medical College of Virginia Hospital, USA.
Change 18.134 Support for OS/390 R2.10 (INCOMPATIBLE).
VMACEXC1 -TYPE30 DD segment has new 8-byte SMF30XBS field for large
VMAC1415 tape block size that requires revised VMACEXC1 to read.
VMAC16 Processing V2.10 data with old MXG will cause INVALID
VMAC30 DEVICE DATA error messages, with trashed DDname, because
VMAC7072 of this INCOMPATIBLE change to SMF type 30.
VMAC71 Note: A common symptom of using an MXG version without
VMAC73 this change to read OS/390 R2.10 or later SMF is
VMAC74 ***ERROR.VMACEXC2.2 INVALID DEVICE DATA message
VMAC78 that has TEMPLSEG=30 in that message text.
VMAC79 This note was added Jun 20, 2001.
Jun 10, 2000 -TYPE1415 has new 8-byte BLKSIZE field for large tape
blocksize, and the CCSID Information added in 2.7 is
now decoded into new variables SMF14CFG/USR/TPE/LBL.
-TYPE16 had only cosmetic changes.
-TYPE30 new variables added to 30_4, 30_5, 30_V, 30_6
datasets: SMF30ASP SMF30CCP SMF30CPR SMF30CSP SMF30JPN
SMF30SME SMF30SPR
-TYPE70 new variable SMF70DSA
-TYPE70PR new variables SMF70ACS SMF70BDA SMF70CSF
SMF70ESF SMF70MAS SMF70MIS SMF70NSA SMF70NSI SMF70ONT
SMF70SPN SMF70STN
-TYPE71 new variables ESAMEMOD SMF71AFB SMF71AHI SMF71AVI
SMF71HRS SMF71HWS SMF71MFB SMF71MHI SMF71MVI SMF71VRS
SMF71VWS SMF71XFB SMF71XHI SMF71XVI
-TYPE72GO new variables R723PRCP R723PRST
-TYPE73 new variable SMF73SFL
-TYPE74 new variable TIMFACNO
-TYPE74PA new variable R742PIOT
-TYPE74CA new variables R745DCID R745LFRE R745LKBF
R745LKBR R745RBYF R745RBYS R745RRID R745VBYW R745VFLG
R745VNTR R745VNUM R745VSER
-TYPE74?? new subtype 7, two or three datasets, but need
test data to decide on structure of datasets created.
Code is in place for Global/Switch/Port sections.
-TYPE78IO new variables R783CUBM R783DPBM R783MCDF
R783MCMN R783MCMX R783PTM
-TYPE791 new variables R791RLG2 R791RCL
-TYPE792 new variables R792FXAB
-TYPE79E R79EEPTM R79EDPBM R79ECUBM R79EMCDF R79EMCMN
R79EMCMX
Change 18.133 Variable CPUTM, the total CPU Time for billing Oracle use
ADOCORAC is modified based on Oracle technical feedback. For the
VMACORAC Batch/TSO connections (CONNID='BATCH' OR CONNID='TSO'):
Jun 9, 2000 CPUTM=SUM(CPUTIMER,CPUCICTM,CPUTCBTM,CPUSRBTM);
and for all other connections,
CPUTM=SUM(CPUTIMER,CPUCICTM,CPUXMETM);
Further discussion of Oracle data is in member ADOCORAC.
Thanks to Yvonne McDonough, USDA, USA.
Thanks to Leslie Arndt, USDA, USA.
Change 18.132 VMXGSUM failed if you used both AUTONAME=YES and NORMx
VMXGSUM operands. AUTONAME is a new feature in SAS Version 8,
Jun 8, 2000 and when specified with PROC MEANS/SUMMARY, new variable
names are longer than 8-bytes and are suffixed with the
statistics (VARIABLE_SUM instead of VARIABLE). With this
change, AUTONAME can be used with VMXGSUM. Why use the
AUTONAME option? If you wanted to sum PDB.JOBS to get
the min/max/mean/sum/std of CPUTM/SELAPSTM/IOTMTOTL, the
VMXGSUM invocation without AUTONAME would be:
%VMXGSUM(INDATA=PDB.JOBS,
OUTDATA=JOBSSUM,
SUMBY=JOBCLASS,
SUM=CPUTM SELAPSTM IOTMTOTL,
MIN=MINCPU MINELAP MINIOTM,
MAX=MAXCPU MAXELAP MAXIOTM,
MEAN=MEANCPU MEANELAP MEANIOTM,
STD=STDCPU STDELAP STDIOTM,
INCODE=
MINCPU=CPUTM;
MINELAP=SELAPSTM;
MINIOTM=IOTMTOTL;
MAXCPU=CPUTM;
MAXELAP=SELAPSTM;
MAXIOTM=IOTMTOTL;
MEANCPU=CPUTM;
MEANELAP=SELAPSTM;
MEANIOTM=IOTMTOTL;
STDCPU=CPUTM;
STDELAP=SELAPSTM;
STDIOTM=IOTMTOTL;
);
But with AUTONAME specified, only this is required:
%VMXGSUM(INDATA=PDB.JOBS,
OUTDATA=JOBSSUM,
SUMBY=JOBCLASS,
AUTONAME=YES,
SUM=CPUTM SELAPSTM IOTMTOTL,
MIN=CPUTM SELAPSTM IOTMTOTL,
MAX=CPUTM SELAPSTM IOTMTOTL,
MEAN=CPUTM SELAPSTM IOTMTOTL,
STD=CPUTM SELAPSTM IOTMTOTL
);
The major difference using AUTONAME=YES is that you no
longer need to equate the new variables in the INCODE=
operand as they are built automatically using the
variable name suffixed by the statistic. This can also
result in the bypassing of a data step or two depending
on the invocation; in this example, two data steps are
bypassed and all that is left is a PROC SORT and a PROC
MEANS, but you are then left with long variable names!
Change 18.131 Amdahl processors can create type 70 RMF records with
ASUM70PR PR/SM segment with LPARNAME='Inactive',LPARNUM=0, and
Jun 7, 2000 LPARCPUS=0, but LPARNUM=0 was previously used to identify
the LPARNAME='PHYSICAL' obs. These records have missing
values for durations, so there was no error in
PDB.ASUM70PR numeric values, but variable LP0NAME had
'Inactive' (yes, in mixed case) instead of PHYSICAL. The
change is to delete these observations as ASUM70PR reads
them, but they will still exist in the TYPE70PR dataset,
as they are really there in the type 70 SMF record.
Change 18.130 Tailoring in EXDB2STS to create variables in DB2STATS did
EXDB2STS not work, because the exit was not included properly.
VMACDB2 -In VMACDB2, the OUTPUT _LDB2STS ; statement was replaced
Jun 2, 2000 with _EDB2STS to invoke the EXDB2STS exit, and
-In EXDB2STS, the _WDB2STS must be OUTPUT _LDB2STS.
The DB2STATS data set is different because it is created
not during the SMF processing, but in subsequent data
steps (after de-accumulation of DB2STAT0 and DB2STAT1,
which are then merged to create DB2STATS). As a result,
the EXdddddd member outputs to the final destination
"_Ldddddd" macro instead of the "_Wdddddd" work file.
Additionally, any variable that is created in EXDB2STS
exit member will be kept in DB2STATS, and thus there is
no need to update the _KDB2STS macro, as it is never
referenced (but now a comment in VMACDB2 explains!).
Thanks to Mr. Chiarle, Gruppo Miroglio Tessile, ITALY.
Change 18.129 IBM Websphere SMF type 103 subtype 2 record contained
VMAC103 an undocumented 4-byte reserved field between CONNSNLA
Jun 2, 2000 and RTDNSMAX caused the subsequent min/max/avg response
Jun 7, 2000 fields to be incorrect. The field was not in the -03
manual but was added in SC31-8690-04. In addition, the
-03 had the 7 ERRORnnn fields ahead of the 4 ERRLVnnn,
but the -04 manual has the ERRLVnnn first, so MXG was
revised to match the revised documentation. Some thread
wait variables are now "IBM internal", but MXG still
inputs that field into the original variable names.
Thanks to Rex Elbert, SPRINT, USA.
Change 18.128 DFSMS/rmm dataset EDGSVREC had blank data set names in
VMACEDGS the volume record, because the data was located +62 from
Jun 1, 2000 where MXG expected, but since the record level value in
the record is still 01, I don't know if this record was
always this way, or was changed between versions.
New variables were added by SMS 1.5 to both the EDGSVREC
and EDGSDREC datasets that are supported by this change.
Thanks to Pat Osborne, DND/DGISDS/DIOM, CANADA.
Change 18.127 Comments only, but message TMNT010E RC=0028 is written by
ASMTAPES MXGTMNT when there is an SMF buffer shortage (or all SMF
May 31, 2000 datasets are full). The RC in MXGTMNT's TMNT010E is the
return code from the SMFWTM macro (documented in the SMF
Manual, GC28-1783-09) and thus this message appears on
your SYSLOG when MXGTMNT tried to write a mount or an
allocation record, but found it couldn't. The list of
all SMFWTM return codes was added in comments.
Thanks to Herb Strazinski, US Bank, USA.
Change 18.126 The string LABEL='NTACSR: was misspelled once as NTACRS,
VMACNTSM and was repeated incorrectly five times that are changed
May 31, 2000 to NTDIST, NTIACC, NTIACS, NTIATC, and NTIATS. These
typos caused BLDNTPDB to see duplicates in &MXGDSNS.
Also _KNTACSR was misspelled once as _KNTACRS.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.125 Extra observations were created in TYPE746B (HFS Global
VMAC74 buffers) and R746GBF/R746GBNF were negative, because the
May 30, 2000 DO R746GSBN=1 TO SMF746FN should have been TO SMF746BN.
Also, variable R746GSB, R746GSBF, and R746GSBP are now
formatted MGBYTES.
Thanks to Alan Deepe, Perot Systems, ENGLAND.
Change 18.124 BUILDPD3 fails "BY VARIABLES NOT SORTED WORK.TYPE25" when
BUIL3005 two jobs with the same READTIME and JOB are executed with
May 29, 2000 the second JESNR first. MXG's heuristic algorithm merges
Jun 1, 2000 TYPE30_1 with TYPE25 to add JESNR into the TYPE25 dataset
(because IBM still has not added JESNR to the TYPE25),
but previously, the output dataset was in order by JESNR.
This unexpected out-of-sequence execution is corrected
by adding PROC SORT DATA=TYPE25; BY READTIME JOB JESNR;
to ensure the TYPE25 is now in the expected order. This
is the first instance I have seen that confirms that the
two jobs can be read-in in the same .01 second READTIME,
but MXG addition of JESNR in BUILDPDB/BUILDPD3 was done
knowing that someday the reader would be fast enough to
create two jobs of same job name with same READTIME.
Thanks to Ron Lundy, Navistar, USA.
Change 18.123 Support for 3494 Peer-to-Peer (Gemini) adds an Enhanced
FORMATS Statistic segment with dozens of new variables, added by
VMAC94 APARs OW42071 and OW42073. Code has not yet been tested
May 25, 2000 as records are not yet available.
Thanks to Greg Kent, IBM Global Services, USA.
Change 18.122 Summarization of TYPETCPT to track the number of users
ASUMTCPT concurrently logged on, using TYPETCP/TYPSTCP to first
May 24, 2000 create the TYPETCPT dataset.
Thanks to Charlie Sticher, University of Georgia, USA.
Change 18.121 Bad offset for second HFS filename caused INPUT EXCEEDED
VMACTCP error; the record is wrong and being investigated, but
May 24, 2000 logic was now added to prevent reading off the record,
while we open a problem with IBM.
Thanks to Michael Creech, Alltel, USA.
Change 18.120 MXG 17.17-18.02 only. Revision to text of Change 18.071.
RMFINTRV That change (in MXG 18.03 and later) is now required for
VMAC7072 OS/390 R2.7 or R2.8 if APAR OW41317 is installed (and 2.9
May 24, 2000 which includes the APAR). That APAR added multi-system
May 30, 2000 enclave fields that were incorrectly read by MXG. While
R2.9 generates error messages, R2.7 and R2.8 do not; both
create bad values (negative, asterisk, etc) in TYPE72GO
observations for periods two and higher.
RMFINTRV sums the TYPE72GO data, so data in RMFINTRV
will also be bad without this change; this is just an
alert, as nothing in RMFINTRV was changed.
This change is really just to update the text of 18.071,
as that change only mentioned Release 2.9. A cosmetic
change (LENSCS test from GE 448 to GE 460) that has no
execution impact was made in VMAC7072.
Thanks to Jane Huong, Cigna, USA.
Thanks to Steve Colio, Cigna, USA.
Change 18.119 Support for Domino Server R5.0.3 new subtype 2 & 6
EXTY1082 type 108 records now create two new datasets:
EXTY1086 Dataset Description
IMAC108 TYPE1082 Domino Server User Activity
VMAC108 (IP address of user, Notes User Name, Type
VMXGINIT of connection, CPU time, Bytes Read/Written
May 23, 2000 an interval record).
May 31, 2000 TYPE1086 Domino Server Database Activity
(Database name, index ops, replicates, docs
added, docs deleted)
In addition, the _Sdddddd sort macros for all TYPE108x
datasets were revised for duplicate SMF record removal.
These new data are a good start to tracking Domino Server
activity to users and causers, but it is still incomplete
and provides only resource measurements, with no counts
of user activity other than bytes, and no intersect of
which databases were used by which users when! The good
news is that IBM is listening and we will continue to see
enhancements in the SMF 108 records as Domino Server is
finally a mainstream product for mainframes!
The type 108 SMF record's product has had these names:
Domino Server R5.0.3
Lotus Domino Server R5.0.2
Domino Server R5.0/R5.0.1
Lotus Domino R5
Lotus Notes Domino Server
The MXG-L Archives contain several discussions of Domino
Server: IBM Redbooks SG24-2083 (Install, Customization,
Admin) and SG24-5149 (Performance Tuning and Capacity
Planning) have both been recommended, especially the USS
customization and installation in SG24-2083.
See Change 18.092 for the type 103 SMF record.
Thanks to Stella Lim, United Air Lines, USA.
Change 18.118 Support for Type 42 RLS Subtype 19 has been revised and
EXTY42X2 validated; two datasets are now created:
IMAC42 Dataset Description
VMAC42 TYPE42X1 VSAMRLS Local Buff Mgr SYSPLEX Totals
VMXGINIT TYPR42X2 VSAMRLS Local Buff Mgr SYSTEM Details
May 18, 2000 However, these two datasets have lots of data, and in
keeping the IBM field name as part of the prefix of each
variable name for the 16 buffer pool with six measures
per buffer pool got messy, but here is the table of the
variable name prefixes for the Buffer Pool measurements:
IBM Buffer Pool Megabytes Buffer Pool Extents
Array LOW HIGH CURR LOW HIGH CURR
"JOE" SMFJOF SMFJOG SMFJOH SMFJOJ SMFJOK SMFJOL
"JRL" SMFJRJ SMFJRK SMFJRL SMFJRN SMFJRO SMFJRP
"JPY" SMFJPZ SMFJQA SMFJQB SMFJQC SMFJQD SMFJQF
There are sixteen variables for each of these prefixes
and their suffixes are 01-09,0A-0G, so SMFJOF01 is the
Low Size (in Megabytes - note that MXG Labels & Formats
for the Megabyte variables have been converted from the
min/max/current count of buffers to the size of that
buffer pool in bytes, and is formatted to print KB/MB/GB
with the MGBYTES format) of the 2K buffer pool, and
SMFJOL0G is the current number of extents in the 32K
buffer pool. Labels identify the pool size.
This is valid data, but may be enhanced as the data is
viewed and used.
APAR OW44739 (May 30, 2000) acknowledges that the SMF
manual for V2R5 and V2R6 subtype 19 documentation was
wrong and that the V2R7 and later are correct.
Thanks to Edward McCarthy, IBM GSA, AUSTRALIA.
Change 18.117 Tailoring failed because IMACKEEP was not included in the
TYPEMWUX TYPEMWUX member.
May 18, 2000
Thanks to Bart Decat, KBC Belgium, BELGIUM.
Change 18.116 Two occurrences of AND SV30ALN GE 1 THEN must be changed
VMACSARR to AND SV31ALN GE 1 THEN and to AND SV32ALN GE THEN as is
May 18, 2000 obvious from the other variables in those statements.
Thanks to Ian Mackay, RBS, UK.
Change 18.115 Assembly of ASMTAPES under OS/390 R2.8 or 2.9 with ASM H:
ASMTAPES IEV122 ERROR ILLEGAL OP-CODE FORMAT MACRO STCKCONV, due
May 17, 2000 to IBM error (APAR OW39924, macro STCKCONV has blank line
at sequence number 10075000 - remove or commend out blank
line. Or use the High Level Assembler instead of ASM H,
which tolerates the blank and is IBM's recommended ASM
Thanks to Scott Wigg, USBank, USA.
Change 18.114 Variable UOWTIME was kept LENGTH 4 in dataset MONITASK,
VMACTMO2 which would cause a problem only if you were to merge the
May 17, 2000 MONITASK and DB2ACCT datasets; UOWTIME is INPUT from the
first six bytes of UOWID; it is only a token for matching
DB2ACCT to MONITASK/CICSTRAN, but it needs to be kept as
LENGTH 8, as it is everywhere else in MXG except this one
member. (It was also not formatted as DATETIME21.2, but
rarely is the time value of UOWTIME useful; the truncated
value wraps every few weeks and from some originations is
completely off from current time, but that's ok for a
token.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.113 The SELDSN macro did not list ASUMCEC after ASUM70PR,
JCLMNTH but MONTHBLD expected to create MONTH.ASUMCEC. Added
May 17, 2000 ASUMCEC to the list of datasets.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.112 Variable NSPYTIPL is now formatted DATETIME21.2 and kept
VMACNSPY as LENGTH 8 instead of the default 4 (which can truncate
May 17, 2000 a datetime variable by as much as 255 seconds).
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.111 RMF variable MVSLEVEL from RMF 70 is now kept in the
VMXGRMFI RMFINTRV dataset.
May 16, 2000
Thanks to Marc Matthys, Hudson Williams, BELGIUM.
Change 18.110 -NTSMF object SNA ADAPTER SNADLC* has an Instance Field
EXNTCOTI that is now decoded when it is present.
EXNTTN32 -Support for COM Transaction Integrator object in the new
IMACNTSM COMTRNIG dataset.
VMACNTSM -Support for TN3270 Server object in the new TN3270SV
VMXGINIT dataset.
May 15, 2000
Thanks to Tom Aaslet, SMT, DENMARK.
Thanks to Richard P. Clarke, Freemans PLC, ENGLAND.
======Changes thru 18.109 were in MXG 18.04 dated May 15, 2000======
Change 18.109 Comments only were changed in MONTHBLD (that it expects
MONTHBLD that your Weekly PDB is built on Monday morning), and new
MONTHBLS member MONTHBLS expects that your Weekly PDB is built on
May 15, 2000 Saturday instead. The actual weekly job doesn't care
when it is run; it simply combines the last seven dailies
to create a Weekly PDB thru that morning's daily PDB, but
the MONTHBLx has to know what is your first day of week.
Thanks to Larry Heath, Shaw, Inc, USA.
Change 18.108 Variable SVCCIO inserted between SVCCKERN and SVCCSEM4.
VMACSVCC However, 75% of Peregrine's elapsed times are zeroes, and
May 13, 2000 many records that should be there aren't! Open problem.
Change 18.107 Variable NOAMIDBK is now INPUT as &PIB.2 (instead of 4),
VMACNOAM variable NOAMCOLN=INPUT(NOAMCOLL,&PIB.4.) is the numeric
May 15, 2000 value of NOAMCOLL, which is now input as $CHAR4. with
$HEX8. format, and the non-Y2-compliant 0yymmddF NOAMMIGD
"Object Migration Date" is now protected with a 1960
window.
Thanks to Peter Skov Sorensen, Jyske Bank, DENMARK
Change 18.106 Inconsistent macro names were used in BLDNTPDB and in the
BLDNTPDB TRNDNTIN trending for NTSMF. The Macro _LASUMNT in the
May 13, 2000 BLDNTPDB member was changed to _LSUNTIN to be consistent
with the TRNDNTIN naming conventions.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 18.105 -Workload Activity Report was updated for APAR OW41317:
ANALRMFR three enclave fields (AVG ENC/REM ENC/MS ENC) added in
May 13, 2000 the TRANSACTIONS column.
-Workload Activity Report was updated for APAR OW41317:
goal mode, REPORT=WLMGL,RPTOPT=WGPER, the PERIOD
summarization and calculations were revised to remove
SYSTEM from all BY statements.
-Device Activity Report was updated for APAR OW31701:
Add column MX to DASD ACTIVITY REPORT to show the
number of UCBs that were active for PAV devices.
-Channel Activity Report was updated for APAR OW35586:
columns for Ficon data transfer rates and Bus Utilization
were added.
Change 18.104 SAS data libraries built in tape format with OS/390 SAS
CONFIGV8 V8.0 TS MO, TS M1, and V8.1 cannot be safely used. You
JCLQAJOB may get errors when you write or read; or worse, datasets
JCLUXRE6 created from tape datasets can have trashed labels.
MONTHBLD See "SAS Technical Notes" in Newsletter THIRTY-SEVEN for
MXGSASV8 a technical discussion of the errors (also on homepage).
VMXGINIT Instead of using the V8SEQ engine, until these errors are
WEEKBLD corrected by SAS Institute, you must change the default
WEEKBLDT tape engine so that the V6SEQ engine is used, by either:
May 13, 2000 - adding SEQENGINE=V6SEQ to your CONFIG member, or
- using MXGs revised CONFIGV8 member with that option, or
- adding OPTIONS SEQENGINE=V6SEQ; in every job's SYSIN
input stream, or
- adding ,OPTIONS='SEQENGINE=V6SEQ' to each // EXEC SAS
or // EXEC MXGSAS JCL statement for each job.
Also, MXG members WEEKBLDT and MONTHBLD, which create
tape format datasets on temp DASD, will fail, as they
contain LIBNAME TAPETEMP TAPE ; statements that force
the V8SEQ engine even when SEQENGINE=V6SEQ is set, so
"TAPE" in those LIBNAME statements was replaced with a
new macro variable &TAPENGN, set to V6SEQ by VMXGINIT.
And there now exists member MXGSASV8, a JCL Procedure
example to use for SAS Version 8, as I discovered that
SAS member BATCHXA in the SAS CNTL library is now named
BATCH, and the MXGSASV8 example now uses member CONFIGV8
(instead of CONFIG) for execution under SAS V8.
(Confused? CONFIG08 was for SAS 6.08, not SAS V8)
SAS Institute opened SAS Note 002651 and found that the
LABEL error applies to all platforms where TAPE engine is
supported, so they are aggressively attacking the error.
July 26 update: SAS ZAP Z8002651 now exists for SAS V8.0
and V8.1, and the error is corrected in SAS V8.2.
With that zap, you can change the CONFIGV8 to V8SEQ, but
since I can't detect if that ZAP is installed.
Thanks to Dan Riggs, Wachovia, USA.
Thanks to Ron Adkins, Wachovia, USA.
Thanks to Alan Lankin, Towers Perrin, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to MP Welch, SPRINT, USA
Change 18.103 IMS log processing, MXG 18.03 only, IMS 6.1 only (whew!):
TYPEIMSB WARNING: UNINITIALIZED VARIABLE _IMSVERS message because
May 12, 2000 %INCLUDE SOURCLIB(VMACIMSA,IMACKEEP);
should have been added by change 18.086. Our testing was
with IMS Version 5, so we missed this error, as even with
that note, the 18.03 IMS Support processes V5 just fine.
Thanks to Pete Young, University of Toronto, CANADA.
Change 18.102 SMF 108 records from the early release 5.0 cause error
VMAC108 INVALID DO LOOP CONTROL because the DO loop on SM108PTN
May 12, 2000 did not test first that SM108PTN was non-missing.
Thanks to Coen Wessels, UNICBLE, SWITZERLAND.
Change 18.101 INVALID DATA FOR REQSTART resulted when the date field
VMACIPAC contains packed decimal value of zero for both the time
May 11, 2000 and date parts ('0000000C0000000C'x). Inserting the
"double question-mark modifier" in the INPUT statement
suppresses the note and hex dump of the SMF record. This
subtype (for KSDS VSAM) should not have been created by
IPAC, since that feature is not enabled at this site.
So MXG now protects the zero date in this useless record.
Thanks to Jim Petersen, Homeside Lending, Inc, USA.
Change 18.100 Variable FILDATEX was not protected for invalid Julian
VMACZARA date values of 1998000, but now those expiration dates
May 11, 2000 will be set to MXG's "infinite" date of '31DEC2099'D.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 18.099 Dataset ASUMCEC is now automatically built in the Monthly
MONTHBLD and Weekly PDB libraries. Since it is built by %INCLUDE
WEEKBLD of ASUM70PR member, and MXG already expected the ASUM70PR
WEEKBLDT dataset to exist, adding ASUMCEC to the WEEK/MONTH PDBs
May 11, 2000 should be transparent.
Thanks to Normand Poitras, ISM, Canada.
Change 18.098 Variable FTPDATFM added to LENGTH $1 statement, as it
VMACTCP is decoded by $MGTCPFM and its length must be forced in
May 10, 2000 the LENGTH statement.
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 18.097 Summarization example for DB2STATB, the DB2 Statistics
ASUMDBSB Buffer Pool data, which is not yet provided by ANALDB2R
May 2, 2000 Statistics Detail report. This is a first pass effort.
Thanks to Chad Heck, BEPC, USA.
Change 18.096 Execution under ASCII only. Some hex variables were read
VMAC74 with $EBCDIC instead of $CHAR, causing possible incorrect
Apr 30, 2000 values in internal variables TEMPIOML/SMF74PRF/DASDRCFG/
SMF74CNX/RF8FLAG/DSG2 and kept variables TYPEIOML,
EXTNDSTO,ESCAENAB,ESCACONF,MTPATBEG,MTPATEND,DEVDYNCH,
DEVDISNV,BASE,NRALEXCH,SNAV,DVID,RCOL,DIFN,DBDP, &PDAT,
but only if the raw SMF data was read with MXG under SAS
on an ASCII platform. Fortunately, most of these are new
variables, and the old ones were rarely used.
-I misread APAR OW31701 and used the wrong hex field to
set variable NRALEXCH (number of aliases changed?).
and overlooked bit 2 of SMF74CNX, now variable PAVBASE.
Change 18.095 The HFS Dataset Names for FTP Client and Server are now
VMACTCP created as variables FTPHFSD1/FTPHFSD2 in the TYPETCPF
Apr 30, 2000 and TYPETCPC datasets. While the theoretical length of
an HFS dsname could be 1024 bytes, only the first 200
bytes (the maximum length of a character variable under
SAS V6) are kept. However, if you actually have dsnames
longer than 200, this could easily be changed, and when
the entire world is on V8 with compression, variable
lengths can be 32000 with no wasted space!
Thanks to Steve Clark, California Federal Bank, USA.
Change 18.094 Building the daily MVS PDB on tape is not recommended, as
VMXGCICI there will be lots of rewinds (and possible dismounts and
VMXGRMFI remounts). If you want to put your daily PDB on tape, it
Apr 30, 2000 is far better to create it on temporary DASD and then use
Feb 27, 2003 PROC COPY IN=PDB OUT=PDBTAPE MEMTYPE=DATA; to copy all of
the PDB datasets to the tape in one write after creation.
MXG has always intended that the BUILPDB could write to
//PDB when it points to tape, so code was revised so that
you could make the below changes and put //PDB to tape:
To write all the PDB datasets directly to //PDB on tape:
//SYSIN DD *
%LET PCICTRN=WORK;
%LET PDB2ACC=WORK;
%LET PCICACC=WORK;
%INCLUDE SOURCLIB(BUILDPDB);
PROC COPY IN=WORK OUT=PDB;
SELECT DB2ACCT CICSTRAN CICSACCT;
DB2ACCT and CICSACCT are normally written to //PDB during
the SMF-processing step, but you cannot have two datasets
open simultaneously in a sequential data library, so they
will be written initially to //WORK and copied to //PDB.
The CICSTRAN dataset is normally written to //CICSTRAN as
a separate sequential data library, but in this example,
CICSTRAN will be written to //WORK and then copied to the
//PDB. Of course, if you don't want to keep CICSTRAN and
DB2ACCT you can eliminate the PROC COPY. (CICSACCT always
has zero observations, and is not likely used anymore.)
If you have large CICSTRAN and DB2ACCT datasets, you may
prefer to write them to separate tape datasets and have
the rest of the PDB datasets written to //PDB, taking
much less //WORK space and eliminating double handling:
// EXEC MXGSASV9
//CICSTRAN DD DSN=CICSTRAN,DISP=(,CATLG),UNIT=TAPE
//DB2ACCT DD DSN=DB2ACCT,DISP=(,CATLG),UNIT=TAPE
//SYSIN DD *
%LET PCICTRN=CICSTRAN;
%LET PDB2ACC=DB2ACCT;
%LET PCICACC=WORK;
%INCLUDE SOURCLIB(BUILDPDB);
And if you want to include ASUMCACH, you must use this
code; ASUMCACH normally reads PDB.TYPE74 and PDB.TYPE74CA
and outputs to PDB.ASUMCACH:
DATA TYPE74; SET PDB.TYPE74;
DATA TYPE74CA; SET PDB.TYPE74CA;
The actual MXG changes made in CHANGE 19.084 were these:
-In VMXGCICI, protection for archaic CICEOD/REQ/RRT/USSRV
datasets had input and output from the PDB ddname; now a
temporary file is created and used for the four inputs.
-In VMXGRMFI, the TYPE72 and TYPE72GO datasets were read
concurrently from the PDB ddname; a temporary copy is
made of the TYPE72 dataset (which eventually will have
zero observations always when the world is goal mode!).
Read Change 18.104 before using SAS V8 tape datasets.
The text of this change was revised in Feb 2003.
Change 18.093 Support for Roger Software Development, RSD FOLDERS 4.0.
EXRSDFBA Two datasets are created
EXRSDFOL dddddd dataset description
IMACRSDF RSDFBA RSDFOBAT RSD FOLDERS ASTRES BATCH
TYPERSDF RSDFOL RSDFOONL RSD FOLDERS ASTRES ONLINE
TYPSRSDF Most fields documented in DSECTS ACCIO and ACCIOAP are
VMACRSDF now decoded, but there still are a few unknown fields
VMXGINIT in the record, but they seem to contain zeroes.
Apr 29, 2000
May 13, 2000 Note that member TYPEWSF supports RSD's EOS/WSF product.
Thanks to Chairat Tiajanpan, KrungThai Bank, Thailand.
Change 18.092 The _ETY1032 statement, which OUTPUTs SMF 103 subtype 2,
VMAC103 was in the wrong place (too early in the INPUT logic),
Apr 27, 2000 causing many TYPE1032 variables to have missing values.
The type 103 SMF record's product has had these names:
Websphere Application Server for OS/390
HTTP Server Version 5.2
Lotus Domino GO Webserver
ICSS (Lotus Domino GO)
IICS V2 R2
See Change 18.119 for the type 108 SMF record.
Thanks to Steve Clark, California Federal Bank, USA.
Change 18.091 A set of sample reports for some basic TCP/IP analysis
ANALTCP from IBM type 118 records (MXG Member TYPETCP) for the
Apr 27, 2000 analysis of FTP and Telnet usage.
Thanks to Steve Clark, California Federal Bank, USA.
Change 18.090 Cosmetic, to avoid confusion. VMXGSUM's WARNING message
VMXGSUM that a dataset did not exist had a confusing reference to
Apr 27, 2000 KEEPALL=NO that was removed. The message now states that
it is normal for the first TRENDing run; but otherwise
the warning that an input dataset did not exist is valid.
Thanks to Normand Poitras, ISM, CANADA.
Change 18.089 The last period for any BY group when intervals are
ANALCNCR synchronized may not have been synchronized, because the
Apr 26, 2000 RUNTIME variable was not forced to be a discrete interval
time value. Adding RUNTIME=CEIL(RUNTIME/&TIMER)*&TIMER;
and DO up to LASTINTV in &TIMER chunks fixed the error.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 18.088 Using VMXGRMFI with TREND= specified and PDB= blank to
VMXGRMFI invoke only for TRENDing failed with messages:
Apr 26, 2000 WARNING: APPARENT SYMBOLIC V70NRM NOT RESOLVED....
Local macro definitions mis-located inside the PDB loop
were relocated, and KEEPALL=YES was added to the VMXGSUM
invocation in its TRENDing section.
Thanks to Normand Poitras, ISM, CANADA.
Change 18.087 Support for MainView for CICS 5.3.01 (INCOMPATIBLE). The
VMACMVCI CMRDATE format was changed to YYYYMMDD, and a PTF added
Apr 26, 2000 variables STRTTIME, ENDTIME, and SYSTEM to the CMRDETL
transaction dataset. Nine new file count variables were
added in the CMRFILE dataset.
Thanks to Steve Smith, BMC, USA.
======Changes thru 18.086 were in MXG 18.03 dated Apr 17, 2000======
Change 18.086 Revised TYPEIMSB member for IMS log processing completes
TYPEIMSB MXG 18.03 revisions, correcting earlier TYPEIMSB members
Apr 17, 2000 (post 17.17) that created dates of Jan 1, 2000 instead of
the correct date. MXG 18.03 dated Apr 17, 2000 has now
corrected all reported IMS 5.1 log errors, and thus the
IMS Log processing now requires that release of MXG.
Change 18.085 Revisions to Sterling's Solve Management Services V3.7
VMACSOLV support. New subcategory '50'x is undocumented, and MXG
Apr 15, 2000 code will be revised to create separate datasets for each
subcategory. The original MXG code was only for the '06'
USERCPU segment, which is now the only subcategory that
is output in TYPESOLV, pending receipt of documentation
and additional test data.
Apr 29: SOLVLAST changed from TODSTAMP8. to SMFSTAMP8.
Thanks to Silas J. White, FDIC, USA.
Thanks to Ian Davies, Workers' Compensation Board of Alberta, CANADA.
Change 18.084 Variable VERSION is now XPTRVERS, because it conflicted
VMACXPTR with pre-existing character variable VERSION, and it is
Apr 14, 2000 now labeled 'XPTR*REPORT*VERSION'. The KEEP= list for
May 12, 2000 XPTR50 and XPTR52 were missing SYSTEM/SUBSYSTEM/SMFTIME
May 15, 2000 causing _SXPTR50/_SXPTR52 to fail. I protected the Y2K
non-Ready records for 2000, expecting only new dates, but
the RPRTTIME date in XPTR52 have 98 and 99, which MXG
interpreted as 2098/2099. Apparently, the RPRTTIME date
is when the report (format?) was put out to this X/PTR
Report repository, and so now both 19xx and 20xx dates
are protected. LOC_7ATA is respelled as LOC_DATA.
May 12: SRC_FLG logic revised.
May 15: SRC_FLG '... .100'B now '.....100'B.
Thanks to Mike Shapland, PKS Information Services, Inc, USA.
Change 18.083A IMF variable PROGRAMB (@149) was originally documented
VMACCIMS "BMP Program name", when it was added to the IMF record
Apr 14, 2000 by IMF Release 1.3 years ago, because variable PROGRAM
May 22, 2000 was already input (@53), and so MXG used the logic
"IF PROGRAMB GT ' ' THEN BMP='Y';"
to identify BMPs. However, BMC Technical Support has
informed me to instead use variable PROGTYPE (@78), so
IF PROGTYPE='B' THEN BMP='Y';
is now the revised change in VMACCIMS to identify BMPs.
BMC Technical Support also told me that the field I named
PROGRAM has always actually contained the PSBNAME, and
the field I named PROGRAMB contains the actual program
name. This has not been noticed; first, MPPs must have
PSBNAME and PROGRAM name the same, second, for BMPs and
other transaction types that can have different names,
most sites use the same name, and third, IMS analysis is
usually more interested in transaction name than program.
But now that I know the truth, VMACCIMS was changed:
- variable PROGRAMB is still input @149 but re-labeled
to make no reference to "BMP".
- variable PROGRAM is now input @149 instead of @53.
- new variable PSBNAME is now input @53 and kept in the
CIMSTRAN dataset from the 'FA'x IMF records.
The entire text of this change was revised May 22, 2000,
but the change to VMACCIMS that corrected BMP='Y' was
made by the original change contained in MXG 18.03 of
April 17, 2000. Only the changes to PROGRAM/PSBNAME
were not available until MXG 18.05.
Thanks to Betty Paterson, BMC, USA.
Thanks to Dan Sills, The Mutual Group, CANADA.
Thanks to Bob Falla, The Mutual Group, CANADA.
======Changes thru 18.083 were in MXG 18.03 dated Apr 12, 2000======
Change 18.083 ICF CPUs support was still imperfect. The PCTLnBY in
ASUM70PR both PDB.ASUM70PR and PDB.ASUMCEC was wrong (too low)
Apr 11, 2000 if there was an ICF in the box, and the LPnDUR in
PDB.ASUMCEC was DURATM instead of LPnNRPRC*DURATM.
Note that for ICF removal from capacity calculations,
you need APAR OW37565 or the current OS/390 release that
stores 'ICF' into SMF70CIN. If you have systems that are
back level, you can use EXTY70PR to force SMF70CIN='ICF'
for the TYPE70PR observations for the ICF LPARNAME, but
you also must set SMF70CIN='ICF' for the PHYSICAL entry
for that LPAR by its LCPUADDR:
IF SYSTEM='CMC1' AND (LPARNAME='CFP2' OR
(LPARNAME='PHYSICAL' AND LCPUADDR=2))
THEN SMF70CIN='ICF';
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 18.082 First MXG 18.03 only. Sort macro for TYPE64X had a
VMAC64 missing underscore before the _WTY64X in the PROC SORT.
Apr 11, 2000
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 18.081 were in MXG 18.03 dated Apr 11, 2000======
Change 18.081 Very minor. Protection for a 16th IFCID destination
VMACDB2 eliminates the VMACDB2 NOTE: YOUR DATA HAD NRQWSC=16.
Apr 11, 2000
Change 18.080 Revisions to correct tape drive counts for SPINing tape
ASUMTALO allocations, and additional exits have been added so that
Apr 11, 2000 selection by SYSTEM and changes to bucket definitions can
Apr 12, 2000 be made without EDITing the ASUMTALO member (by using
%LET MACKEEP= to redefine the exit macros:
_ESUTAL1 allows for the insertion of code to select
which SYSTEMs data is summarized.
_ESUTAL2 allows for overriding the buckets built by
ASUMTALO's invocation of ANALCNCR.
_ESUTAL3 allows for adding to the renames of buckets
if more than 8 bucket are present (supports
new buckets added in _ESUMTAL2)
Thanks to Anthony Lobeley, EDS, ENGLAND.
Change 18.079 These two summary members require KEEPALL=NO to override
ASUMCICS the VMXGSUM new default of KEEPALL=YES, Change 18.065.
ASUMCICX These members will read either IBM or Landmark CICS data,
Apr 10, 2000 but only one set of variables was kept; with KEEPALL=NO,
VMXGSUM constructs a KEEP= with only needed variables,
but KEEEPALL=YES passes the hardcode SUM= list, which
caused variable not found condition. I will revise the
members in a cleaner fashion in a later release, but by
restoring KEEPALL=NO for these two VMXGSUM invocations,
it constructs the correct KEEP= list, and all is well!
Change 18.078 The change in order of sort variables by Change 18.001
MONTHBLD was not propagated into WEEKBLD, WEEKBLDT or MONTHBLD,
WEEKBLD causing NOT SORTED errors TYPE30MU, TYPE30OM, and TYPE89
Apr 10, 2000 datasets. The BY lists were corrected and now match the
Apr 24, 2000 BUILDPDB sort order, but NOT SORTED errors will still
Apr 27, 2001 occur if you build weekly/monthly from daily/weeklys that
Aug 7, 2001 were created with different sort orders.
To get that failing weekly/monthly job to finish, you
only need to add the NOTSORTED option to the end of the
BY list in your WEEKBLD/WEEKBLDT/MONTHBLD:
in WEEKBLD: add NOTSORTED to the BY statement after
each SET statement BY .... NOTSORTED ;
in WEEKBLDT: add NOTSORTED to the MACRO _BYLIST ... %
& MONTHBLD after each MACRO _DSET TYPExxxx %
Explanation: The BY statement with multiple datasets
in a SET statement creates an output
dataset that is sorted, so that a SORT in
a report programs can be bypassed by SAS
to save time and resources, but nothing
else in MXG requires datasets to be in a
sort order, so adding option NOTSORTED
will create the output dataset (which is
partially sorted!) without the error.
Install a new MXG version on the first logical day of
your week (e.g.: my week is MON to SUN PDBs, or Tue-Mon
daily runs, so I move my new version into production on
Monday afternoon, before the Tuesday morning's BUILDPDB,
so that all of the new week's dailies will be created by
the same MXG version) to minimize sort change issues.
Thanks to David Ehresman, University of Louisville, USA.
Thanks to Alan Lankin, Towers Perrin, USA.
Thanks to Scott Snyder, First Data, USA.
Change 18.077 A final PROC SORT was added to put PDB.CICINTRV back in
VMXGCICI the correct order for the WEEKLY merge. The final step
Apr 9, 2000 logic can recalculate STARTIME, so the added sort was:
PROC SORT DATA=CICINTRW OUT=&OUTDATA;
BY SYSTEM APPLID SMFPSSPN STARTIME;
Thanks to Michael L. Knych, International Paper, USA.
Change 18.076 NETSPY report NSPYPRT exposed that MXG NETSPY datasets
VMACNSPY needed revisions in some of its response calculations.
Apr 9, 2000 -Julian discovered and tested with TARGETS=HOST:
NETRSPNO and NETRSPN6 appear to be the number of
instances where a 'definite response' has occurred, as a
result of either (1) FORCEDR in the NetSpy INITPRM, or
(2) the application running in DR-mode anyway. Therefore
they represent the number of times network response time
has been measured, and can correctly be used to calculate
average network response time (by division by CRSPNET and
CRSPNET6). They can only be used to calculate %responses
on target if TARGETS=USER is in force. With TARGETS=HOST
the value of NETRSPNO and NETRSPN6 should be irrelevant.
-The revision of TRANSNO +1 or -1 relates to the number of
inputs to the number of transactions terminated at the
host, which is redundant with LUNRSPSS, and was removed.
-TARGETS=HOST/USER based on NETRSPNO LT Sum(T1-T4RSPNO)
is an approximation that fails with small numbers.
Instead, using SMFTFLG1 for NSPYLU and XDOMAIN for the
NSPYAPPL is a better determination.
Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
Change 18.075 Dataset TMVSWG's _STMVWG and _NTMVWG macros were not in
VMACTMV2 the _STMV2 and _NTMV2 macro lists, and comments with the
Apr 9, 2000 TMVSWKP instead of TMVSWG were corrected.
Thanks to John Jackson, Redcats (UK), ENGLAND.
Change 18.074 CICS Statistics dataset CICTCPIP variables SOROPENG/OPENL
VMAC110 which should be open timestamp on GMT and Local are bad;
Apr 9, 2000 OPENG is zero, and OPENL is 'FFFFFFFFD1' which produces
a datetime of 17SEP2042:18:53:47.18 in every record. And
the GMT and Local clock values for OPEN/CLOSE are not the
same; they are off by about .2 seconds.
This change is only for documentation; when an IBM APAR
exists that corrects those fields, this will be updated.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.073 Support for Systemware SYSOUT X/PTR, JHS, MPS, and C/QUE
EXXPTR02 product's user SMF record. There are 30 XPTRnn datasets
... created, but only these subtypes have been data tested:
EXXPTR52 04,06,09,10,11,12,18,20,50,51,52. This vendor provides
IMACXPTR sample SAS code that was used as a starting point, and
TYPEXPTR some of its variable names were used in MXG datasets, but
TYPSXPTR that program failed when executed, had fields input from
VMACXPTR wrong locations, was incomplete, and not Y2K compliant,
VMXGINIT so the DSECTS were used to create this MXG support with
Apr 9, 2000 its structure, formatting, exits, etc.
Thanks to Mike Shapland, PKS Information Services, Inc, USA.
Change 18.072 ObjectStart/Huron have new HU62KEYn/HU72KEYn variables so
VMACHURN that the multiple observations from a single type 62/72
Apr 7, 2000 (multiple Process, Accounting, Locking, etc) can be
Apr 10, 2000 combined into a logical transaction. HU47INTV/APL/SSNO,
HU49INTV/HU49APL/HU49SSNO and HUxxHPSN/PUIN/ACTN/SCN/SAN/
PERN/LKN/RPN/ for 62 and 72 subtypes are all now kept.
Variables HUnnSSNO were changed from &PIB.4. to $CHAR4.
with $HEX8 so that the type 49 and 62 records can be
merged together by HU49SSNO and HU62UNQI to show Huron
resource usage by JOB/STEP. The LABEL for HU49TCPU is
TCB+SRB (was TCB).
Thanks to Lindsay Oxenham, TELSTRA, AUSTRALIA
Thanks to John Toohey, TELSTRA, AUSTRALIA.
Thanks to Greg Meyer, Isuzu Motors, USA.
Change 18.071 MXG 17.17-MXG 18.02 only INPUT STATEMENT EXCEEDED or
VMAC7072 INVALID DATA FOR R723CIEA in Goal Mode Type 72 Subtype 3.
Apr 7, 2000 The OS/390 R2.9 added code was wrong. The INPUT of CXEA
Apr 10, 2000 and CFEA should have been &RB.8. vice &RB.4., and there
was a missing SKIP=SKIP-24; after that input statement.
See Change 18.120: R2.8 with APAR OW41317 also requires
this change, but has no error message. 24May2000.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.070 DB2ACCT variable JOB has been revised based on the source
ASUMDB2A of the connection, and new variables TRAN and PLAN are
VMACDB2 also created for possible use in matching to CICSTRAN:
Apr 7, 2000 TRAN=' ';
Apr 10, 2000 PLAN=QWHCPLAN;
IF QWHCATYP IN (1,2,0BX) THEN DO;/*TSO,CALL ATTACH*/
JOB=QMDACORR; /*UTILITY JOBS*/
END;
ELSE IF QWHCATYP IN(3,5,6,9,0AX) THEN DO;/*DLI,IMS*/
JOB=QWHCCN;
END;
ELSE IF QWHCATYP =4 THEN DO;/*CICS*/
JOB=QWHCCN;
TRAN=SUBSTR(QMDACORR,5,4);
END;
ELSE IF QWHCATYP IN (7,8) THEN DO;/*DISTRIBUTED,REMOTE*/
JOB=QWHCOPID;
PLAN=SCAN(QWHCCV,1,' .');
END;
-Testing with the new VMXGSUM change (KEEPALL=YES) found
that some DB2 6.1 variables had been added to ASUMDB2A
but were not in the KEEP= list for dataset DB2ACCT. The
old default of KEEPALL=NO had masked the omission, and
ASUMDB2A's spelling of two QZZ variables as QXX.
Thanks to Paul Weissman, Perot Systems, USA.
Change 18.069 Support for CA's NETSPY 5.3 (COMPATIBLE) adds nine new
EXNSPYAD datasets and removes one. The NSPYTELE TELNET dataset
EXNSPYAT introduced in 5.2 has been completely replaced in 5.3,
EXNSPYHP so references to NSPYTELE and EXNSPYTE were deleted.
EXNSPYMA The nine new dataset created are:
EXNSPYMC dddddd Dataset Record Description
EXNSPYMR NSPYAD NSPYAPPD D APPN Directory Services
EXNSPYRT NSPYAT NSPYAPPT E MNPS Application Recovery
EXNSPYTC NSPYHP NSPYHPR N High Performance Routing
EXNSPYTS NSPYMA NSPYMNPA M MNPS Application
IMACNSPY NSPYMC NSPYMNPF F MNPS Coupling Facility Struct
VMACNSPY NSPYMR NSPYMNPR E MNPS Application Recovery
Apr 7, 2000 NSPYRT NSPYVRTP R VTAM RTP
NSPYTC NSPYTCP I TCP/IP Connections
NSPYTS NSPYTCPS J TCP/IP Stack
These datasets have been added but only syntax tested, as
no test records are yet available for validation.
Thanks to Roger Zimmerman, Scudder Kemper Investments, USA.
Change 18.068 DB2ACCT variables ACCOUNT1-ACCOUNT9 were not populated
VMACDB2 for DBAAS nor for non-Local-DB2-ACCOUNTING records. The
Apr 6, 2000 logic for Local-DB2 was replicated for the other two DB2
record types. Note if you put your own accounting values
in your DB2 records, you must use a 'FF'x delimiter if
you want those accounting fields separated into separate
account variables; only DB2 takes MVS accounting fields
and inserts a 'FF'x delimiter in its 101 records, so that
is what MXG's VMACDB2 logic expects. If there is only
on field with no 'FF' delimiter, then it will be stored
into variable ACCOUNT1 (and member IMACACCT sets the
stored length of each of the ACCOUNTn variables).
Thanks to Ian McKay, Royal Bank of Scotland, SCOTLAND.
Change 18.067 Negative DD counts for OPEN/USED DB2 Dataset calculation:
ANALDB2R -IBM APAR PQ21969 (see NEWSLTRS for APAR details) corrupts
Apr 5, 2000 QTSLWDD, "Slow DDs", which is subtracted from QTDSOPN.
-MXG logic error if there were more than one interval in
the summary. The statement QTDSOPN=QTDSOPN/INTRVLS;
was moved to follow DSUNUSED=(QTDSOPN-QTSLWDD)/INTRVLS;
so total-total instead of average-total is subtracted!
Thanks to John McCray, Huntington National Bank, USA.
Change 18.066 The PDB.ASUMCEC dataset requires that all SYSTEM's clocks
ASUM70PR are on the same timezone, since the merge is by STARTIME.
EXCECTIM This change adds new exit member EXCECTIM to allow you to
Apr 5, 2000 insert your own logic to change the time zone of STARTIME
to a common time zone. You could use logic like this:
IF SYSTEM='CST ' THEN STARTIME=STARTIME+HMS(-5,0,0);
ELSE IF SYSTEM='EUR ' THEN STARTIME=STARTIME+HMS(1,0,0);
to change STARTIME from local to GMT.
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 18.065 The KEEPALL=NO default of VMXGSUM can cost CPU time with
ANALCISH minimal benefit, especially when VMXGSUM is used multiple
ASUMCICS times, as in ANALCISH which invokes 45 executions of the
ASUMCICX VMXGSUM macro if all CICS shutdown reports are requested!
ASUMDBDS MXG enhancements to support all possible syntax in that
ASUMHPAI KEEPALL=NO logic (constructs KEEP= statements with only
ASUMHPSU needed variables, but parsing must be in macro language
MNTHDB2S that is more expensive that data step logic) cost too:
TESTOTHR 16.16 17.17 17.17
TYPEMON8 KEEPALL= NO NO YES
TYPEMONI CPUTM 62 sec 93 sec 43 sec
VMACMON8 ELAPSTM 15 min 19 min 10 min
VMACMONI Hi Block Used 1905 1905 1921
VMXGSUM for ANALCISH, with no savings in the work space needed!
Apr 4, 2000
Apr 11, 2000 I had planned to change the default to KEEPALL=YES, but
found that some VMXGSUM invocations require KEEPALL=NO
to prevent VARIABLE NOT FOUND errors:
With KEEPALL=NO, variables can be listed that don't
exist in the input dataset; both IBM and TMON vars are
listed in the dual-input ASUMCICS program, but only
one set will actually exist. With KEEPALL=YES, all
variables must exist. And with KEEPALL=NO, you can
still use ASUMDB2A to summarize DB2ACCT, even if you
have removed variables that you don't need, since the
KEEPALL=NO option tolerates non-existent variables.
By adding an explicit KEEPALL=YES in each VMXGSUM use in
member ANALCISH, and by adding an EXPLICIT KEEPALL=NO in
ASUMCICS/ASUMCICX, and by cleaning up variables in SUM=
lists that didn't belong there, all of MXG members in the
18.03 library have been tested with KEEPALL=YES as the
default, but I decided that it was not worth the exposure
of creating an error perfectly running programs to save a
few seconds of CPU time, so the MXG default remains
KEEPALL=NO.
But because KEEPALL=YES can be very useful in specific
cases, I have instead externalized KEEPALL to a Global
macro variable, so it can be changed from KEEPALL=NO with
%LET KEEPALL=YES;
in your //SYSIN before the program that invokes VMXGSUM,
so you can test the possible savings and any impact.
Note that if your program uses %VMXGSUM(KEEPALL=xxx,...),
i.e., explicitly specifies the KEEPALL= argument in its
invocation, that local xxx value will always override and
replace the Global value set with a %LET statement.
Thanks to Steve Colio, CIGNA, USA.
Change 18.064 MXG 18.01-18.02 only. Changes in the _Bdddddd "BY list"
VMAC6156 macros caused VARIABLE xxxxxxxx NOT FOUND errors:
VMAC64 -VMAC6156: VARIABLE SMF6XFNC NOT FOUND. Macro should be:
VMAC79 MACRO _BTY6156 SYSTEM READTIME JOB FUNCTION CATNAME
VMACGUTS ENTRNAME VOLSER1-VOLSER5 ACTION SMFTIME %
Apr 4, 2000 -VMAC64: VARIABLE SITUATN NOT FOUND. Macro should be:
MACRO _BTY64X SYSTEM READTIME JOB CATNAME ENTRNAME
COMPONT BEGCCHH VOLSER EXTENTNR SMFTIME %
-VMAC79: VARIABLE SYSPLEX NOT FOUND. Here the KEEP= for
dataset TYPE79F was incomplete; variables SYSPLEX
SYSNAME and STARTIME were added to its KEEP list.
-VMACGUTS: VARIABLE JOB NOT FOUND. Here the KEEP= for
datasets GUTSSESS and GUTSINTR was incomplete;
variable JOB was added to their KEEP lists.
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 18.063 The count of CLASS3WT events typographically included the
ANALDB2R variable QWACAWTW, the wait duration, when it should have
Apr 4, 2000 been QWACARNW, the number of wait events, (three places).
Thanks to Tom Benson, Amdahl U.K., ENGLAND.
Change 18.062 New RMFINTRV parameters KEEPPGN/KEEPRPGN/KEEPSRV/KEEPRSRV
VMXGRMFI can be used to minimize the list of entries when you only
Apr 3, 2000 want to keep/drop a few PERFGRPs/SRVCLASSes.
Thanks to Normand Poitras, ISM, CANADA.
Change 18.061 The statement segment AND %LENGTH(&USERADD) NE 0
UTILBLDP was removed, because it could have caused no USERADD=
Apr 3, 2000 to be created when there should have been one.
Thanks to Dave Gibney, Washington State University, USA.
Change 18.060 Continued IMS quirk removal; Open Transaction Manager
ASMIMSL5 Access, OTMA, and APPC differences in LCODE=31x records
ASMIMSL6 were revised. While OTMA may have been only an IMS 5.1
Apr 3, 2000 facility, I put the code in both members while we await
an answer from IBM. We think OTMA is very rare in any
event, so this change should have no negative impacts!
Thanks to Pete Gain, SAS Institute, ENGLAND.
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Change 18.059 -TPF support did not work with SAS USER= or WORK= options,
IMACTPF causing ERROR DATASET WORK.TPFTD NOT FOUND because the
TYPSTPF PROC COPY at the end of member TYPSTPF should have been
VMXGINIT removed when the _STPFxx PROC SORT macros were added.
VMXGTPFI -Hardcode "PDB." references were replaced with _Ldddddd
TESTUSER macro references in VMXGTPFI.
Apr 3, 2000 -VMXGINIT now defines WTPFINT and PTPFINT macro variable
for dataset TPFINTRV for consistency in naming.
-IMACTPF now documents the many TPF datasets/dddddd.
-VMACTPF had data set labels that were repeated/unclear.
-These were found by running TESTOTHR with their options.
-TESTUSER was also revised, with its one PROC COPY with
INDD=WORK being replaced with three separate PROC COPYs
each with INDD=&Wdddddd for the specific dataset to copy.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.058 Zero observations were processed if you did not use the
PRINTNL MXGSAS procedure (or used the SAS procedure without the
Apr 1, 2000 CONFIG=MXG.SOURCLIB(CONFIG) parameter specified) because
the MXG macro variable OPSYS was tested instead of the
original SAS macro variable SYSSCP. Since nothing else
in CONFIG is required for PRINTNL, changing to use the
SAS macro variable SYSSCP eliminates the exposure so that
PRINTNL will work with the plane vanilla SAS JCL proc.
Thanks to Glenn Harper, Memorial Hermann Hospital System, USA.
Change 18.057 Variable PROCSTEP should not have been kept in TYPE30_1
VMAC30 or TYPE30_5, as it is a step-level variable, and it was
Apr 1, 2000 added to the KEEP= list for all TYPE30 datasets that
contained STEPNAME (except for TYPE30_D, because that is
a DD-level dataset, and adding PROCSTEP doesn't see to
be needed there and would only waste space (and you can
always use the MACRO _KTY30UD to add PROCSTEP if you
really decided you needed it at the DD-level dataset.
Thanks to Michael Oujesky, MBNA, USA.
Change 18.056 Support for CMA Release 1.11 (COMPATIBLE) added two new
VMACCMA variables, SMFT05PL and SMFT06PC to the subtype 5 and 6
Apr 1, 2000 SMF records.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.055 OAM Release 1.5.0 changed the type 85 subtypes 74-77 and
VMAC85 subtypes 78-79 and 88 INCOMPATIBLY by inserting 32 bytes
Mar 31, 2000 (R85ORMN,R85OTMN) at the front of the segment, and by
Apr 10, 2000 inserting R85LXQT in the middle of the segment. Jobname,
stepname/procname were added to the OAM product segment
and those are now kept in all OAM data sets.
Apr 10: corrected tests for 1.4.0 to 150.
Subtypes 80-86 are not supported yet because I have no
test data, but MXG now prints a note if one of those
unsupported records are found, and I'll add support if
you'll send me your type 85s with those subtypes!
Thanks to Jeff Schuster, American Century, USA.
Change 18.054 The two PROC SORTs should have had _WTMSTMS and _WTMSDSN
TYPETMS5 instead of TMSRECS and DSNBREC, so that you could change
Mar 31, 2000 the location of the WORK copy. If you changed the ddname
you will get "TMS MERGE ERROR" message because MXG did
not use your changed destination.
Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY
Change 18.053 The macro token _K102TX5 did not follow the _W102TX5
VMAC102 segment in the DATA statement; an oversight, but no
Mar 30, 2000 impact unless you wanted to change the variables kept.
Thanks to Jim Kovarik, AEGON USA, USA.
======Changes thru 18.052 were in MXG 18.02 dated Mar 29, 2000======
Change 18.052 IMS log record 01s are now deleted if MSGFLAGS '10'x bit
ASMIMSL5 is set (MSGFNRQU, the non-recoverable bit). Pete found
ASMIMSL6 duplicate IMSTRAN observations for some transactions that
Mar 29, 2000 were being submitted to the IMS input queue via the IMS
OTMA facility from an MQ series box. The non-recoverable
transaction exists merely to enter the message onto the
queue so that it can be requeued for execution. That
original (non-recoverable) 01 lacks critical identifiers
anyway, cannot be analyzed, and its processing is not
recorded in a type 7 record as a processed message, so
there is no loss by discarding that record.
The non-OTMA log records sequence all had the same DRRN:
01/35/08/56/31/03/35/37/7/33/56/07; the OTMA sequence was
01/35/08/56/31/03/31/33/56/37/33/56/07 records, but the
03/35/31/33 had one DRRN value, while the 01/31/33 had a
second DRRN generated by OTMA's processing, and it was
the second DRRN that created the "duplicate" transaction.
This change removed nine redundant XC USERKEY,USERKEY
statements in ASMIMSL5/ASMIMSL6 to make room for the four
new statements added to drop the unwanted records.
Thanks to Pete Gain, SAS Institute, ENGLAND.
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Thanks to Pete Sadler, IBM, ENGLAND.
Change 18.051 IMF Fast Past records contain INPQUETM as a PD instead of
VMACCIMS the documented PIB format, affecting both INPQUETM and
Mar 28, 2000 ARRVTIME. CICS transactions with ARRVTEST='0000000C'x
are now included in the fast path calculation for the
ARRVTIME, although they are not strictly queueing.
Thanks to Stephen Hoar, Lloyds TSB ENGLAND.
Change 18.050 -IMS transactions with non-zero value for SUBQ6 time had
ASMIMSL6 the divide by NMSGPROC incorrectly located, causing the
JCLIMSL6 averaged resources (CPUTM, DLI, etc) to be incorrect.
IMACIMSA Fortunately, only one site has observed the problem. The
TYPEIMSA moved code had been added by Change 17.315 to cover the
TYPEIMSB rare case when FIRST.DTOKEN also has INIO and MTYPE='7 '
VMACIMSA because then, the averaging needed for Quick reschedule
Mar 28, 2000 transactions must be bypassed. (That change also added
Jun 5, 2001 IMSACCQ6, IMSSQ6TM and DLRUSSN to the list of variables
to be averaged.)
-Alan's changes that accommodate the 10-byte timestamps in
IMS 6.1 were incorporated in this change, and cosmetic
changes (colons to long vertical bars) were cleaned up.
-Note: error WORK.IMSMERGE.DATA DOES NOT EXIST occurs if
you try to copy an archaic IMACIMS member into your new
IMACIMSA member in your USERID.SOURCLIB. In general,
no tailoring of the IMACIMSA member is required for most
sites, and it is delivered with only comments.
-1Jun01: This change also changed the default in IMACIMSA
to IMSVERS 6.1 instead of 5.1, but that was not noted
in the original change text.
Thanks to Alan Green, Zurich, ENGLAND.
Thanks to Daniel Cannon, The Hartford, USA.
Thanks to John Pierce, Liberty Mutual, USA.
Thanks to Carl Meredith, SAS ITSV Cary, USA.
Thanks to Yves Terweduwe, CIPAL, BELGIUM.
Change 18.049 TYPE 74 subtype 4 "Broken RMF Record" Change 18.045 was
VMAC74 over-protective, falsely throwing away each last segment
Mar 26, 2000 with that error message. The test CDSILOC+SMF744CL GT
should have been CDSILOC+SMF744CL-1 GT LENGTH THEN DO;
Change 18.048 Cosmetic cleanup of MXG members. Sample PROC Prints in
CREATEBC ADOCxxxx members had non-text hex-values (like '00'x)
IMACEAGL that are now blanks, and the hex values in IMACEAGL and
VMACEAGL are replaced by hex literals. Some members had
DOC a small circle or a tiny "3" instead of the long vertical
Mar 25, 2000 bar for flow chart documentation inside comments (members
had been emailed from ASCII to EBCDIC with non-standard
conversion tables, particularly RHUMBA and/or European
ASCII to EBCDIC tables). The creation of MXG EBCDIC text
from ASCII text has not been documented previously, but
it uses the SAS ASCII to EBCDIC conversion, except that
two changes are required to the SAS ASCII to EBCDIC table
to match OS/390 TSO ISPF EDIT's characters:
Left Bracket - ASCII '5B'x EBCDIC 'BA'x
Right Bracket - ASCII '5D'x EBCDIC 'BB'x
Split Vertical - ASCII none EBCDIC '6A'x
New member CREATEBC is a ASCII SAS program that reads the
ASCII IEBUPDTE file to creates the MXG EBCDIC IEBUPDTE
file. The Variable length ASCII IEBUPDTE file is about
half the size of the fixed length EBCDIC 80-byte file.
The output of CREATEBC is a binary file that can be
written directly to a 3480 tape drive under ASCII, or the
EBCDIC file can be ftp'd into an RECFM=FB,LRECL=80 MVS
file which can then be directly read by PGM=IEBUPDTE to
create the MXG PDS Source Library under OS/390.
Change 18.047 Change 18.044 was still incomplete; variable STARTIME was
VMXGRMFI not reset after %VMXGDUR, so changes to _DURSET were
Mar 19, 2000 still not being applied until this (final!) revision.
======Changes thru 18.046 were in MXG 18.02 dated Mar 16, 2000======
Change 18.046 Variable RESPSTD was not created in this member, so it
TRNDCICX was inconsistent with TRNDCICS.
Mar 16, 2000
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 18.045 TYPE 74 subtype 4 "Broken Record" protection added in MXG
VMAC74 Change 17.378 did not protect when the number of segments
Mar 16, 2000 exceeded the count in the record, but now it does.
Thanks to Steve Lottich, University of Iowa Hospitals, USA.
Change 18.044 MXG 18.01-First 18.02. If you changed _DURSET, either
VMXGRMFI in IMACKEEP or with %LET MACKEEP= , it caused CPU TIMES
Mar 16, 2000 DO NOT MATCH ERROR. Relocate the IF &INTERVAL EQ DURSET
and following eight lines so they are after &INCODE72.
======Changes thru 18.043 were in MXG 18.02 dated Mar 15, 2000======
Change 18.043 Lotus Domino Server SMF type 108 variable DOMTMXSZ, the
VMAC108 Maximum Size of NSF Bufferpool, needs to be multiplied by
Mar 15, 2000 4096, as it is the number of 4096 byte frames.
Thanks to B. Brewer, Humana, USA.
Change 18.042 -This report fails under SAS V8 under OS/390 (but not with
ANAL30DD Windows) with APPARENT SYMBOLIC MAXRUN error because the
Mar 15, 2000 statement %LET MAXRUN=%EVAL(&MAXRUN); is invalid in open
SAS code, and should have caused a syntax error under V6
and under V8 under Windows, but didn't. If there was no
syntax error, the report ran fine, because MAXRUN is set
in the following statement, but the line is now deleted.
-The report example had 'B3'x instead of '7C'x in seven
places, causing a little 3 instead of a vertical bar to
be printed on these example reports.
Thanks to Edward J. Finnell, III, University of Alabama, USA
Change 18.041 ITSV 2.1 and 2.2 failed with CA1-TMS records, due to
VMACTMS5 hardcode TMS.TMS and TMS.DSNBRECD references, that are
TYPETMS5 now replaced with _LTMSTMS and _LTMSDSN tokens, which are
Mar 15, 2000 themselves redefined in VMACTMS5 now (they were not used
Apr 13, 2000 until now, so there is no compatibility issue) to be:
MACRO _LTMSTMS &PTMSTMS..TMS %
MACRO _LTMSDSN &PTMSTMS..DSNBRECD %
and in member VMXGINIT, the default value of PTMSTMS and
PTMSDSN was changed to "TMS" for both macro variables.
This change makes TMS processing consistent with the MXG
16.04 architecture. TMS records are initially written to
their two _Wdddddd tokens, and then sorted and combined
and output to the _Ldddddd tokens.
There was an additional ITSV fix required on top of this
MXG change for ITSV Release 2.2 and earlier (see ITSV
defect number S0079863), but the problem is corrected
in ITSV Release 2.3.
Thanks to Harald Seifert, HUK=COBURG, GERMANY.
Change 18.040 Support for GUTS, Gutenberg Time Sharing, user SMF
EXTYGUTI records. Two records are created, so two _ID macros are
EXTYGUTS defined, and either or both datasets will be populated.
IMACGUTS dddddd dataset description
TYPEGUTS TYGUTI GUTSINTR GUTS Interactive Execution Session
TYPSGUTS TYGUTS GUTSSESS GUTS Session
VMACGUTS
VMXGINIT
Mar 14, 2000
Thanks to Jeffrey Ball, Information Resources Inc, USA.
Change 18.039 Variable LOSU_SEC is now decoded from SMF30SUS, which
VMAC30 was added in OS/390 R2.6, and provides the Service Units
Mar 13, 2000 per second of CPU value for the SYSTEM on which his step
Mar 28, 2000 locally executed. Variable LOSU_SEC was added to dataset
TYPE30_V, TYPE30_4, TYPE30_5, and TYPE30_6.
Additionally, variables SMF30MSI and SMF30WMI were added;
those variables, new in OS/390 2.9, were documented in
MXG Change 17.385, but were not created until now.
March 28, 2000:
Variable SMF30SUS replaced SMF30TET, but SMF30TET has not
had any value so nothing is lost by its removal.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.038 Further enhancements now permit USECNTRL/USEREPRT to use
VMXGRMFI YES NO COMPAT GOAL SYS1 SYS1... to select control
UTILRMFI or report groups or classes for your workload definition.
Mar 15, 2000 All RPRTCLAS='N' were replaced with RPRTCLAS NE 'Y'
because RPRTCLAS is either Y or blank, and defaults work.
Thanks to Michael L. Kynch, International Paper, USA.
Change 18.037 %INCLUDE SOURCLIB(IMACJBCK) was added to VMACTMNT
VMACTMNT in case that job selection member is used for TYPETMNT
Mar 13, 2000 or TYPETALO selection.
Thanks to Chuck Hopf, MBNA, USA.
Change 18.036 Support for optional CICS RMI counters is added as an
IMACICUS example in using IMACICUS to decode user segments, and
Mar 13, 2000 the comments on how to use IMACICUS were updated.
Thanks to Bernie McGinnis, Charles Schwab, USA.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 18.035 Invalid datetime values in VTCS 2.2 VTV Timestamp in VSM
VMACSTC subtypes 13,14,18,19 STCxxTIM variables. New 2.2 version
Mar 14, 2000 records have start/end variables in TODSTAMP8 format
Mar 16, 2000 ('B3B5488A226EE1C1'x) but have '38A8D15E000580C0'x for
VTV timestamp. Old 2.1 version records have all three as
valid seconds-since-1970 values '0000000038CD028F'x, so
the VTV timestamp was shifted left by four bytes, with
new flag variables in the low four bytes.
Because there is no version number in the STK records,
MXG's heuristic to detect VTCS Version 2.2 versus 2.1
did not expect this shifted value, causing STCxxTIM to
have a date in 1931 (or 1970 if value was zero). MXG's
algorithm to decode VTV STK timestamps is expanded to
Value greater than corresponds to input with
4294967295 FFFFFFFFF missing value
'B000------00'x 11Feb1998 TODSTAMP8.
'3800------00'x 10Oct1999 Left 4 PIB+DEL6070
'0000000038--'x All 8 PIB+DEL6070
I first tried IF X GT 0B000000000000000X syntax, but
doesn't work, and SAS Institute has accepted a bug in
both V6 and V8: you cannot use a 16-digit hexadecimal
constant literal value that starts with A or higher,
because the leading zero that is required (so that SAS
doesn't think it is a variable name) makes the string a
rejected 17 positions. SAS promises a fix in a future
release, but here I just used the decimal value for the
test:
X GT 4E18 for TODSTAMP, or
X GT 1.2E19 for shifted, or
otherwise input as unshifted PIB8.
If STK ever puts a version number in their record, this
heuristic will be removed.
The media size variables are now formatted MGBYTES and
the VPOs to HEX. See also Changes 17.195 and 17.332.
Mar 16: The low four bytes of VTV timestamp now create
STCxxSEQ, STCxxHID, STCxxVTI, and STCxxFLG for subtypes
13, 14, 18, and 19 thanks to STK documentation.
Change 18.034 Support for Oracle Version 7.3.3. INCOMPATIBLE. The SMF
VMACORAC record with CONNID=CICS have KERNNUM=0, but it should be
Mar 10, 2000 KERNNUM=1 because there is a valid Kernel segment in the
record. When KERNNUM=0, MXG does not read the kernel
segment, causing missing values for all kernel variables.
Now, MXG detects and corrects the Oracle error and will
read a Kernel segment even if the count field is wrong.
This error has been reported to Oracle.
An additional problem is being investigated: CPUTCBTM and
CPUSRBTM fields are zero with the 7.3.3 release, and so
far, Oracle has no knowledge of any change, but this text
will be updated when more is known.
Thanks to Yvonne McDonough, USDA NITC, USA.
Thanks to Leslie Arndt, USDA NITC, USA.
Change 18.033 Member ASUMTAPE was finally tested under ITSV and it too
ASUMTAPE contained hardcode references to PDB.xxxxxxxx that are
Mar 10, 2000 now changed to their &PDBMXG..xxxxxxxx symbolic names.
Change 18.032 Support for Netview NPM V2R5 changes and two MXG errors.
EX028INK -MXG error: VCD segment was not input for 'DC' or 'DE'.
EX028INL It would have helped if IBM and documented those subtypes
EX028INM in NPM 2.4 tables 73/74 or NPM 2.5 tables 80/81! Change
FORMATS to ELSE IF 0D0X LE NPMSUBTY LE 0DEX THEN COFTYPE='VCD';
IMAC28 -MXG error: VCS segment has two flavors, and the last 4
VMAC28 variables, VCSMAXFX/CURFX/MAXEC/CUREC are now input only
VMXGINIT if VCSVDTYP=2; MXG code was restructured for VCS segment.
Mar 10, 2000 -IBM error: APAR OW37758 for NPM 2.4 corrected error in
subtype DDx record, but that APAR is not included in the
NPM 2.5 release: new APAR AW43578 documents the error.
Change 16.336's circumvention still works to protect 2.5.
-New datasets from new subtypes:
Subtype Exit Dataset Description
14x 028INK NPMINNRT Router Interval
15x 028INL NPMINNRP Cisco Pool Interval
16x 028INM NPMINNIT Router Interface Interval
-The NCD and SCD segments' logic was revised to only input
the IP address for IP resource, and not input SLUNAME,
SLUPU, SLNKNAME and NPMNAME for IP resource type.
Thanks to Jerome Vitner, Experian Information Solutions, USA.
Thanks to Cendrine Pezier, ABS Technologies, FRANCE.
Change 18.031 Uninitialized variable messages for MROTRAN and DB2TRAN
ASUMUOW caused no actual problem, but they are now initialized in
Mar 9, 2000 the first DO; loop in the last DATA step.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 18.030 IMS Log processing with APPC transactions caused negative
ASMIMSL5 SERVICTM and N+1 rather than N transactions per schedule.
ASMIMSL6 After label P031, after USING statement, insert:
Mar 9, 2000 TM QLGUFLGX,QLGUAPPC APPC?
BO DROPMAP SKIP APPC REDUNDANT 31
This has only been tested with IMS 5.1 data. If you have
APPC under IMS 6.1 and have validated this change, or if
you find any problems under IMS 6.1, please contact MXG.
Thanks to Kenneth D. Jones, ISM, CANADA.
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Change 18.029 Variables were labeled, times were re-formatted and the
VMACMIM label (MS) was removed and fields divided by 1000 to put
Mar 3, 2000 durations in units of TIME13.3.
Mar 6, 2000 Mar 6: Uninit variable messages MIMCELL-MIMVCF were in
first 18.01, but had no impact. Variable MIMMPOS is now
labeled and variables MIMADTCR/MIMHDTCR/MIMATMCR/MIMHTMCR
are no longer kept
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 18.028 Partition Data Report was updated for APAR OW37565, in
ANALRMFR the body of the Partition Report, where 'CP ' or 'ICF'
Mar 3, 2000 will be shown for Processor TYPE.
Mar 7, 2000 Mar 7: VMAC75 replaced VMAC71,VMAC77 in line 938.
Change 18.027 APAR OW41317 retrofits the OS/390 R2.9 multi-system
VMAC7072 enclave support (which added data fields in type 72)
Mar 3, 2000 back to OS/390 R2.7. Change 17.385, in MXG 17.17 and
later already supports those fields; this change is
only for documentation; no change was made.
Change 18.026 Support for APAR OW40414, which adds two four-byte fields
VMAC21 at the end of the record (i.e., compatibly) that replace
Mar 3, 2000 the existing two-byte fields for SIOCOUNT and BLKSIZE.
Mar 7, 2000
Change 18.025 If you did not put all SuperSession maintenance on, its
VMACNAF SMF record still contains CENT=39 instead of CENT=01
Mar 3, 2000 caused MXG's circumvention algorithm to be off by one
day. Remove the term (CENT-38)*86400 from each of the
datetime adjustments when CENT=39 and Y2K dates after
March 1, 2000 will be correct.
Thanks to Joe Faska, Depository Trust, USA.
Change 18.024 RACF SMF 80 INPUT STATEMENT EXCEEDED RECORD LENGTH error
VMAC80A in RACFTYPE=39 segment (PROGRAM NAMES, PERMIT). The line
Mar 3, 2000 SKIP=RACFDLNN=64-3 must be SKIP=RACFDLN-RACFDLNN-3;
Mar 9, 2000 Mar 9: The debugging PUT statement was deleted.
Mar 14, 2000 Mar14: Variables KW21AU04/05 and KW21GL04/05 formatted.
Change 18.023 SMF70CIN was reread from the same offset, and it should
VMAC7072 have been LENGTH $3 instead of $2, since it contains CP
Mar 3, 2000 or ICF. This error prevented ASUM70PR from recognizing
and removing ICF processors from the CEC capacity.
Change 18.022 Variable DURATM was added to those MIM datasets that
VMACMIM contained start and end time; it previously had been
Mar 3, 2000 kept only in the MIMTAPE dataset, but MXG intends to
keep DURATM in all interval datasets. Only the TYMIM2,
TYMIM4, and TYMIM6 are event datasets. Mar 6 note:
Uninitialized variables messages MIMCELL-MIMVCF are
created but have no impact; labels were removed.
======Changes thru 18.021 were in MXG 18.01 dated Mar 3, 2000======
Change 18.021 APAF Release 4.6 added a new field Series Name to the
VMACAPAF Pool segment, causing the second and subsequent pools'
Mar 1, 2000 data to be trashed. Insert
IF LENPOOL GE 36 THEN INPUT APAFSENM $EBCDIC16. @;
add APAFSENM='SERIES*NAME' to the LABEL, and to the KEEP=
list for dataset APAFPOOL, and then notice and correct
the _KAPAFLC to be _KAPAFPO for the APAFPOOL dataset.
The other APAF data sets appear to have been unchanged
by this release
Thanks to Art Cuneo, Health Care Service Corporation, USA.
Change 18.020 Using MACRO _Ldddddd to add (COMPRESS=YES) did not work,
VMXGDEL but revisions to this %VMXGDEL macro now supports that
Feb 29, 2000 syntax. I had not provided an option for compressing of
a sorted dataset, but redefining the dataset's _L macro:
MACRO _Ldddddd ddname.dataset (compress=yes) %
is now valid for compressing individual datasets.
VMXGDEL now uses PROC DATASETS MT=ALL so that if you
made a SAS dataset to be a SAS view, both will be deleted
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Thanks to Michael L. Kynch, International Paper, USA.
Change 18.019 The vendor of BETA93 writes non-Y2K-Ready date values in
VMACBETA the BETAJOBT SMFSTAMP8 value, with 00dddF format for Y2K
Mar 1, 2000 with no century bit turned on. The SMFSTAMP8 input was
broken into Time and Date pieces, the Date is now
protected with MXG's DATEJUL algorithm, and BETAJOBT is
then reconstructed from its (protected) pieces.
Thanks to Frank d'Hoine Nationale Bank van Belgie, BELGIUM.
Change 18.018 Variable JOBCLASS in datasets TYPE30xx, PDB.JOBS/STEPS
VMAC30 may be eight blanks, or may have only the first of JES3's
Feb 29, 2000 8-character job class, because IBM changed SMF30CLS, the
old one-byte job class field. Before IBM added SMF30CL8
in 1993, SMF30CLS was INPUT into the 1-byte MXG variable
JOBCLASS. In support for IBM's 8-byte SMF30CL8 field for
JES3, MXG increased JOBCLASS to 8-bytes, read SMF30CLS
into the first byte of JOBCLASS, then input SMF30CL8 into
variable JOBCLAS8, and used this logic to prevent a blank
JOBCLAS8 value from overriding a non-blank JOBCLASS:
IF JOBCLASS LE ' ' AND JOBCLAS8 GT ' '
THEN JOBCLASS=JOBCLAS8;
But now in JES2 R2.8 OS/390 records, SMF30CLS is blank
and SMF30CL8's first byte contains the JES2 jobclass, and
now in JES3 R1.3 OS/390 records, that 1-byte SMF30CLS
field that used to be blank is not blank, so the MXG
logic had to be changed to match the IBM Incompatibility:
IF JOBCLAS8 GT ' ' THEN JOBCLASS=JOBCLAS8;
Variable JOBCLASS is length 8 in TYPE30xx datasets built
by VMAC30 code (because I can't tell if a type 30 record
is from JES2 or JES3), and kept as length 8 in JES3's
BUILDPD3's datasets, but with JES2's BUILDPDB, I can
keep the variable JOBCLASS in only one byte.
Thanks to Allan Koch, Ford Motor Company, USA.
Thanks to Rich Anderson, SAS Institute Cary, USA.
Thanks to Ken Hansen, Exxon, USA.
Change 18.017 The UTILRMFI utility is used to examine any overlap of
UTILRMFI CPU time in your RMFINTRV workload definitions. It has
Feb 29, 2000 been updated to match the VMXGRMFI workloads, and uses
type 30 and type 72 records. See its comments for usage.
Change 18.016 Variable TYPEIOML was blank in dataset TYPE70 because of
VMAC7072 an extraneous line IF SMF70RAN THEN that should have
Feb 26, 2000 been deleted. Fortunately, TYPEIOML is always '3090' and
is unlikely to have been used in any reports!
Thanks to Bill Shanks, SEMA, UK.
Change 18.015 -INPUT EXCEEDED RECORD LENGTH error because the INPUT of
VMAC38 S38CUSER should have been $EBCDIC4. instead of $EBCDIC8.
Feb 25, 2000 -Additionally, TYPE38 failed if you tried to read the VSAM
SMF file because OFFSMF was not added to each offset
calculation.
Thanks to Kenneth D. Jones, ISM, CANADA.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 18.014 SAS Version 7/8 only. Option CODEPASS=2 no longer exists
BUILD001 in SAS Version 7 or 8; it caused a warning message that
BUIL3001 had no other impact, and CODEPASS=2 itself had no impact
BUILDPDB on MXG, and was only specified to suppress a V6 message
BUILDPD3 that suggested you should try CODEPASS=2! Now it will be
Mar 1, 2000 specified only under SAS V6 execution.
Thanks to Mike Hoey, Ameren Services, USA.
Change 18.013 MXG 17.17 only. Running ASUMTALO under ITSV (or using the
ASUMTALO USER= option to send all of the datasets created during
Feb 25, 2000 ASUMTALO's execution to the same DDname) fails with error
V6: You cannot open WORK.TYPETALO.DATA for output access
with member level control because WORK.TYPETALO.DATA
is in use by resource environment SASEDSNX
V8: MEMBER lock is not available for WORK.TYPETALO.DATA
lock held by another user
because views and datasets of the same name cannot exist
in the same data library. The logic was revised and
temporary dataset/view names that do not conflict are now
used, and SPINTALO is no longer a view to avoid conflict.
Thanks to Sharon L. Nagy, Comerica, USA
Thanks to Robert K. Hare, Comerica, USA
Change 18.012 The calculation of RESPSTD (Std Deviation of Response)
TRND72GO did not protect for TRANS=0 before the divide by TRANS,
Feb 24, 2000 causing DIVIDE BY ZERO note on the log (but the dataset
created was still valid). Now divide is protected.
Thanks to Mike Hoey, Ameren Services, USA.
Change 18.011 The object SNA ADAPTER SnaDlc* caused Unknown Object
VMACNTSM message because MXG was expecting SnaDlc1 as the string.
Feb 24, 2000 The test was changed to SNADLC*, and the label of the
SNAADAPT dataset was also corrected.
-Variables DATABASE and APPLETLK appear in both LENGTH $32
and in INFORMAT 16.2 statements, but the SAS compiler did
not flag the inconsistency. Both were removed from the
numeric INFORMAT statement as they are indeed characters.
Thanks to Richard C. Clarke, Freemans PLC, ENGLAND
Change 18.010 Change 17.343 to ANALDSET causes error message "dataset
ANALDSET _NULL_ is not in the data statement". Change the DATA
Feb 19, 2000 statement and insert the needed _NULL_ so it reads:
DATA _VAR1415 _VAR30 _VAR64 _NULL_ _SMF _CDE1415 _CDE30 _CDE64;
Thanks to Ed Long, Fidelity Investments, USA.
Change 18.009 MXG 17.17 only. Using RMFINTRV under ITSV failed, or use
RMFINTRV of Report PGNs or Reporting Classes to define workloads
VMXGRMFI (either in your IMACWORK definitions, or in your
Feb 18, 2000 tailored %VMXGRMFI invocation your RMFINTRV member)
Feb 25, 2000 caused the error message "CPU TIMES DO NOT MATCH" on the
SAS log during creation of dataset PDB.RMFINTRV.
That error message occurs because either:
- you used the new DROPPGN= or DROPSRV= operands, which
didn't work correctly until this change to VMXGRMFI, or
- you didn't use those new operands, in which case there
was double accounting.
This change corrects VMXGRMFI logic for the new operands.
and now has six operands to make tailoring easier if you
want to use RPGNs/Reporting Classes to define workloads:
USEREPRT= Default NO, set to YES to permit Report PGN
or Reporting Classes to be used.
USECNTRL= Default YES, set to NO to delete all Control
PGNs or Service Classes. This is only used
if you want to use only Report PGN/Classes,
and you don't want to list all of them in the
DROPSRV= or DROPPGN= arguments.
DROPSRV = List of Service Classes to drop.
DROPPGN = List of Control Performance Groups to drop.
DROPRSRV= List of Reporting Classes to drop.
DROPRPGN= List of Report Performance Groups to drop.
To be able to use either Reporting Classes or Report PGNs
to define your workloads in dataset RMFINTRV, you MUST
use these new arguments in your member RMFINTRV's invoke
of VMXGRMFI to drop the Control PGN or Service Class
observations that correspond to the RPGN/Reporting Class
observations you want kept in your workloads, to avoid
double accounting and that error! You must also ensure
that every SUBSYS has a default Report PGN or Reporting
Class so that all work in the corresponding Control
Performance Group or Service Class is recorded in type 72
records.
-RMFINTRV failed when it was finally tested under ITSV
because it contained a hardcode OUTDATA=PDB.RMFINTRV,
in the actual %VMXGRMFI invocation in member RMFINTRV,
but ITSV expected the symbolic &PDBRMFI..RMFINTRV so
that ITSV could redirect to the WORK library. The real
bummer is that that OUTDATA= operand is not needed in the
actual invocation, and was added only as a documentation
example and reminder of the default output dataset name!
Remove that operand from the %VMXGRMFI invocation, and
the expected symbolic value will be used.
-This change also corrects an unrelated problem: when no
PERFGRP number was needed to be specified, a blank value
caused VMXGRMFI to fail. While using a bogus number like
9999 circumvented the problem, now a blank can be used,
but using a null value ( // ) fails. Use / / instead.
Thanks to Normand Poitras, ISM, CANADA.
Thanks to Jon G. Whitcomb, Great Lakes Higher Education Corp, USA.
Change 18.008 Variable NRSAMPLES is now kept in dataset TYPE7204; it is
VMAC7072 used to create several variables and should have been
Feb 17, 2000 kept.
Thanks to Frank Cortell, Credit Suisse Group, USA.
Change 18.007 SPIN logic was revised to correctly pick up class three
ASUMUOW wait times, and DB2ELAP (elapsed time in DB2) was added
Feb 29, 2000 to the final dataset. Previously, if a UOW was SPUN,
the DB2 Wait buckets and transaction counts were not put
in the record in the SPIN dataset.
Thanks to Brandon Persinger, The Gap, USA.
Thanks to Allan Winston, MBNA, USA.
Change 18.006 If the QAPMCONF configuration file has a start date of
VMACQAPM 02Sep99, records from this century will have dates in
Feb 16, 2000 year 1900 instead of year 2000. The QAPMCONF file must
match the century of the data you want to process, since
MXG gets AS400CC "Century" value from QAPMCONF.
However, you can circumvent the missing CC=1 value
in your QAPMCONF file by resetting the value of
the macro variable after you have invoked _TQAPCON:
%INCLUDE SOURCLIB(VMACQAPM);
_TQAPCON
%LET AS400CC=1; /*<<= insert to set cc=1 */
RUN; /*<<= insert to set cc=1 */
_TQAPSYS
etc...
Thanks to Kim Johnson, Bank of America, USA.
Change 18.005 There is an end-of-comment */ missing from the second
TRNDSMFI line of this trending example.
Feb 15, 2000
Thanks to Carl Kyonka, Enbridge Consumers Gas Company Ltd, CANADA.
Change 18.004 Type 79 subtype 15 IRLM Long Lock record has SMF79TRN=2
VMAC79 but there is no product section, so STARTIME, SYSPLEX,
Feb 17, 2000 DURATM and other product fields do not exist in TYPE79F.
Feb 22, 2000 In addition, the second triplet is SMF79ASS rather than
SMF79MCS, so the input logic for triplets was revised.
Finally, variables are now formatted to HEX when they do
not contain printable characters, and R79FTRNM is now
kept and labeled.
Note that this type 79 subtype 15 record replaces the
type 74 subtype 100 dataset that MXG creates in VMAC74.
That subtype 100 was a test version that doesn't exist.
Thanks to Johannes-Matthias Laveuve, DVG, GERMANY.
Thanks to Jurgen Scherwa, DVG, GERMANY.
Change 18.003 DB2 6.1 added Buffer Pools 100-109 (8K) and 120-129 (16K)
VMACDB2 and they cause "UNEXPECTED BUFFER POOL ID" messages to be
Feb 11, 2000 printed, because MXG did not know about .
Those new buffer pools are output in the detail by-pool
datasets DB2STATB and DB2ACCTB (although you have to have
removed the comment block in member EXDB2ACB to cause MXG
to create observations in DB2ACCTB), but the new pools
counts were not included in DB2ACCT or DB2STAT datasets.
In DB2ACCT/DB2STAT, MXG creates four sets of buffer pool
variables: QB1xxxx for BP zero, QB2xxxx for BP one,
QB3xxxx for all other 4K buffers, and QB4xxxx for all 32K
buffers. Rather than create yet another set of summary
counters for the 8K and 16K buffer pools, I have added
the 8K and 16K buffer counts to the QB4xxxx variables
in DB2ACCT and DB2STAT, since you can always retrieve the
individual buffer pool counts from DB2ACCTB/DB2STATB.
This change replaces the statement:
ELSE IF 80 LE QBACPID LE 80 THEN DO;
with
ELSE IF 80 LE QBACPID LE 89 OR 100 LE QBACPID LE 109
OR 120 LE QBACPID LE 129 THEN DO;
for DB2ACCT, and replaces this statement:
ELSE IF 80 LE QBSTPID LE 80 THEN DO;
with
ELSE IF 80 LE QBSTPID LE 89 OR 100 LE QBSTPID LE 109
OR 120 LE QBSTPID LE 129 THEN DO;
for dataset DB2STATS.
Thanks to Joachim Mayer, Amadeus Data Processing GmbH, GERMANY.
Change 18.002 Omegamon V500 records were deleted simply because the
VMACOMCI test for version number did not include V500. Add
Feb 7, 2000 AND FOCVER NE 'V500' and the records will be read.
Thanks to Peter Webber, CIS, UK.
Change 18.001 The _Bdddddd BY List macro was not sufficiently robust to
VMAC1415 remove all duplicates for some datasets, so the BY list
VMAC30 of variables has been revised so that you can PROC APPEND
VMAC42 to combine possibly duplicated data and then use the MXG
VMAC6156 _Sdddddd sort macro (which uses the revised _Bdddddd BY
VMAC64 list macro) to eliminate duplicates. However. there are
VMAC7072 four datasets that contain intrinsic duplicates; there
VMAC74 are repeated observations for the same set of BY vars
VMAC89 for the first four datasets listed (with asterisk) that
VMAC115 will require further research and discussion with IBM.
VMAC116 *MQMACCT _BTY116 now SYSTEM MQMSSSID QWHCAID
VMACACC QWHCCV QWHCCN SMFTIME
VMACTCP *TYPETCPA _BTYTCPA now SYSTEM APIJOBNM APISTART
Feb 18, 2000 APILCLPO APILCLPN APILOCAL
APIREMOT SMFTIME
*TYPE42DS _BTY42DS now SYSTEM STARTIME JOB READTIME
DSNAME DEVNR
*TYPE30MU _BTY30MU now READTIME JOB JESNR INITTIME
SUBTYPE PRODOWNR PRODNAME
PRODQUAL PRODID SMFTIME
TYPEACC _BTYACC now SYSTEM READTIME JOB SRHSTEPN
SRHDDN MESSAGE SMFTIME
MQMBUFER _BTY115B now SYSTEM MQMSSSID QPSTPOOL
SMFTIME
TYPE30OM _BTY30OM now READTIME JOB JESNR SUBTYPE
STEPNR SUBSTEP OMVSOPI
OMVSOUI OMVSOSI SMFTIME
TYPE892 _BTY892 now SYSPLEX SYSTEM PRODOWNR
PRODNAME PRODFEAT PRODID
PRODSTFL PRODREGS SMF89IST
SMFTIME
TYPE89 _BTY89 now SYSPLEX SYSTEM PRODOWNR
PRODNAME PRODQUAL PRODID
MULCUFG SMF89IST SMF89UST
SMFTIME
TYPE74SY _BTY74SY now SYSPLEX SYSTEM STARTIME
R742SNME R742SDIR R742STCN
SMFTIME
TYPE74ME _BTY74ME now SYSPLEX SYSTEM STARTIME
R742MSYS R742MGRP R742MMEM
SMFTIME
TYPE72SC _BTY72SC now SYSPLEX SYSTEM STARTIME
SRVCLASS R723SCSN R723SCSR
SMFTIME
TYPE64 _BTY64 now SYSTEM READTIME JOB CATNAME
ENTRNAME SITUATN COMPONT
DDNAME VOLSER1-VOLSER3
SMFTIME
TYPE6156 _BTY6156 now SYSTEM READTIME JOB SMF6XFNC
CATNAME ENTRNAME GENNO VERNO
VOLSER1-VOLSER5 SMFTIME
PDB.SMFINTRV _BTY30UV add SMFTIME DESCENDING INTBTIME
MULTIDD EXTRADD
TYPE1415 _BTY1415 now SYSTEM READTIME JOB OPENTIME
DDNAME DSNAME UCBSEGNR
SMFTIME
TYPE1718 _BTY1718 now SYSTEM READTIME JOB DSNAME
VOLSER NEWNAME SMFTIME
This is work still in progress; I need to formally open
a problem with IBM to discuss the duplicate records that
we've identified. This note updated 1Mar00.
Thanks to Abakah Nori, United Parcel Service, USA.
LASTCHANGE: Version 18.
=========================member=CHANGE17================================
/* COPYRIGHT (C) 1984-2000 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 17.17 is dated Feb 7, 2000, thru Change 17.398.
MXG Version 17.11 was dated Feb 2, 2000, thru Change 17.395.
First MXG Version 17.11 was dated Jan 31, 2000, thru Change 17.394.
First MXG Version 17.10 was dated Jan 20, 2000, thru Change 17.375.
MXG Version 17.09 was dated Dec 22, 1999, thru Change 17.339.
MXG Version 17.08 was dated Nov 12, 1999, thru Change 17.308.
First MXG Version 17.08 was dated Nov 10, 1999, thru Change 17.301.
MXG Version 17.07 was dated Oct 8, 1999, thru Change 17.264.
First MXG Version 17.07 was dated Oct 7, 1999, thru Change 17.261.
MXG Version 17.06 was dated Aug 12, 1999, thru Change 17.216.
MXG Version 17.05 and dated Aug 5, 1999, thru Change 17.207.
First MXG Version 17.05 and dated Aug 4, 1999, thru Change 17.203.
MXG Version 17.04 was dated Jul 16, 1999, thru Change 17.175.
First MXG Version 17.04 was dated Jul 14, 1999, thru Change 17.172.
MXG Version 17.03 was dated Jun 8, 1999, thru Change 17.126.
MXG Version 17.02 was dated May 19, 1999, thru Change 17.104.
MXG Version 17.01 was dated May 3, 1999, thru Change 17.079.
First MXG Version 17.01 was dated Apr 29, 1999, thru Change 17.073.
MXG Version 16.16 was dated Feb 20, 1999, thru Change 16.394.
Newsletter THIRTY-FIVE was dated Feb 20, 1999, thru Change 16.367.
Contents of member CHANGES:
(Please see member NEWSLTRS for Technical Notes
that were previously in member CHANGES).
I. MXG Software Version 17.17 is now available.
IX. Incompatibilities and Installation of MXG 17.17.
X. Online Documentation of MXG Software.
XI. Changes Log
I. MXG Software Version 17.17 is now available, upon request.
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 14, 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 subtype 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 forsubtype6.
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 supresses 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 Jul 4, 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
Windows 2000 Build 2195 17.10
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
NTSMF Version 2.3 17.10
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
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 incompatiblities.
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.
ASMIMSLx 17.172 Significant IMS Log processing enhancements for test.
ASMIMSLx 17.228 Major IMS Enhancements for MXG IMS log processing.
ASMIMSLx 17.315 Final IMS Revisions for all know negative values.
ASMTAPES 17.046 ML-19 of ASMTAPES supresses 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 subtype 7/8 NFS Usage/Users.
TYPE42 17.278 Support for APAR OW40579/41407 SMF 42 subtype 4.
TYPE42 17.355 Type 42 st 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, Icebert 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) sorworks 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 cause 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:
NEXTCHANGE: Version 17.
======Changes thru 17.398 were in MXG 17.17 dated Feb 7, 2000======
Change 17.398 DEVICE Activity Report can now utilize the INTERVAL and
ANALRMFR MYTIME parameters for summarization tailoring. All of
Feb 6, 2000 the ANALRMFR reports will eventually hav these options.
Change 17.397 The revised CICINTRV dataset did not contain variable
VMXGCICI DATETIME, which is archaic and STARTIME should be used
Feb 6, 2000 in your reports, but now they will still work.
Change 17.396 Support for EMC's InfoMovers Product's SMF record.
EXINMVCL creates two datasets:
EXINMVSR INMVCLNT - Infomover Client Record Subtype 1
IMACINMV INMVSRVR - Infomover Server Record Subtype 2
TYPEINMV These records look much like FTP records, but do not
TYPSINMV contain IP addresses, but do have additional statistics.
VMACINMV However, the start and end time variables INFSTART/END
VMXGINIT are bad, containing INFEND= '38970868'x which should be
Feb 6, 2000 close to the record's SMFTIME of '005F7F11'x.
Feb 7, 2000 EMC has opened tracking number 2951232 to resolve, but
was unaware of the error.
Thanks to Charles Piggott, SAS Europe, GERMANY.
Thanks to Mr. Ragaglia, ITS - FIAT, ITALY.
======Changes thru 17.395 were in MXG 17.11 dated Feb 2, 2000======
Change 17.395 Change 15.268 was supposed to have added DURATM=INTERVAL,
ASUMHSM to the VMXGSUM invocation in ASUMHSM, but was overlooked
Feb 2, 2000 until now. And work datasets HSMINTVL/HSMSTAT are now
deleted at the end of execution of ASMHSM.
Thanks to Chris Weston, SAS Institute ITSV, USA.
======Changes thru 17.394 were in MXG 17.11 dated Jan 31, 2000======
Change 17.394 Example had three sets of pairs of strange characters in
ANALBATW lines 77, 78, and 170; those characters should each be
Jan 31, 2000 an exclamation point, since a pair of exclamation points
are used for character string concatenation (instead of
long vertical bars, precisely because exclamation points
are correctly translated by Rhumba, but long vertical
bars are not, and I missed that error when I edited this
contribution that had gone thru Rhumba enroute to MXG).
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 17.393 IBM RMF-like CACHE Subsystem Activity Report can now be
ANALRMFR created by ANALRMFR. New REPORT=CACHE argument will
Jan 31, 2000 create the report from TYPE74CA Cache DASD records.
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 17.392 MXG 17.01-17.11, on ASCII (PC or Workstations) only. To
AUTOEXEC make AUTOEXEC and CONFIGxx members consistent, I added
CONFIG OPTIONS S=72 S2=72 into the AUTOEXEC member in MXG 17.01,
CONFIGV7 but only today did Chuck discover that those options have
CONFIGV8 entirely different meanings to SAS under MVS than under
Jan 31, 2000 ASCII! Originally they were needed to prevent SAS from
reading source statement columns 73-80, because that's
where MVS fixed length files are numbered, and under MVS
with fixed length input, options S=72/S2=72 do set the
MAXIMUM column to be read. However, under PC/unix, with
variable length -SYSIN input, SAS documents that they
instead set the MINIMUM column to be read, causing SAS to
skip input columns 1-71! When PC SAS read that OPTIONS
statement in AUTOEXEC.SAS, it began ignoring columns 1-71
in remaining lines, and never read nor ran the %VMXGINIT
statement that followed that OPTIONS statement!
Fortunately, those options are now deleted from AUTOEXEC
(and for consistency, also from the CONFIGxx members),
because MXG Software has been unnumbered since 1992.
P.S. I keep several AUTOEXEC.xxx members in the SAS root
directory and copy the one I want (kinda like JCL) into
the AUTOEXEC.SAS member and then start SAS. However, you
can also change the autoexec using
c:\sas\sas.exe -config 'c:\mxg\sourclib\config.sas'
-autoexec 'c:\mxg\sourclib\autoexec.sas'
either in batch execution or in separate shortcuts for
your differing file allocations, etc.
Making MXG.SOURCLIB VB on MVS reduced it from 150 cyl
to 95 cylinders, reduced BUILDPDB EXCPs for compile
from 13,326 to 12,886, and CPU time from 45 to 43 sec.
It doesn't hardly seem worthwhile!
Change 18.147 reinstated S=72,S2=72 in CONFIGV8. 29JUN00.
But S=72,S2=72 should NOT be in your AUTOEXEC.SAS file.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.391 -CICINTRV dataset creation logic was wrong, causing the
CICINTRV non-INT event records (REQ/USS/EOD) to be put in the
VMXGCICI wrong interval. But IBM caused STARTIME to be wrong in
VMXGDUR INT interval records, because DURATM was found wrong:
VMXGSUM CICDS Interval records with DURATM=03:00:00 and the
Jan 30, 2000 COLLTIME=06:00:00 (so then STARTIME=03:00:00), but
CICSSTCK=03:48:00 when this region started. The
interval record has SMFSTINO=1, but that interval
number is reset at midnight! Since the CICDS record
has the dispatcher durations, adding DSGTWT=DSGTDT
showed the true duration of this interval was 02:12:00
and the IBM DURATION of 3 hours was wrong!
MXG uses COLLTIME to group records. The COLLTIME in the
INT records is the end-of-interval value and is the same
in all INT records for that interval (e.g. 03:00:00),
which VMXGCICI floored correctly to 03:00:00 for summary.
However, because the COLLTIME in the EOD, REQ and USS
records is a distinct event time (e.g. 03:05:01.99 for a
file close), it is not the end of interval, so VMXGCICI
incorrectly floored that COLLTIME back to the 03:00:00
end time of the prior interval. This logic error was
corrected by adding the INTERVAL value to the COLLTIME
for the non-INT records and then flooring that sum back
to the end of this interval.
This works for timed intervals, but INTERVAL=SHIFT is
not supported at this time, as there is no obvious
way to determine the end of shift. Call if wanted.
-STARTIME is now calculated based on the DSGTDT+DSGTWT or
DURATDS from the dispatcher record, if one is found, and
the STARTIME will be exact if the COLLTIME is exact and
the DURATDS is within 30 seconds of exact. If there were
no CICDS records for an interval both the STARTIME and
DURATM will be set missing and COLLTIME will be the end
of interval.
-Variable SMFSTRQT is now kept in PDB.CICINTRV to identify
the source (EOD/INT/REQ/USS).
-New INTERVAL=EOD option will combine all of the records
for a region's execution together and give you total
resources for each execution.
-New INTERVAL=THREEHR option is an attempt to match IBM's
default interval, and works fine as long as all regions
create interval records.
-But you can still get strange results if you request
CICINTRV to be summarized at an INTERVAL that is smaller
that your CICS interval, or if a region writes EOD,REQ
and USS but doesn't write interval records: a region
started at 01:00, wrote three USS CICFCR close records at
05:05:, and then wrote an EOD record at shutdown at
12:00. CICINTRV with hourly default created one obs for
the 05:00-06:00 event, with only the FCR counts, and then
the EOD record created an overlaping 01:00-12:00
observation with all other measurements.
Thanks to Normand Poitras, ISM, CANADA.
Change 17.390 The default value for &SASCHRLN was changed back to 100
VMXGINIT from 200 so those SQL text variables under SAS V6 are the
Jan 28, 2000 original length and agree with labels. See Change 17.253.
Thanks to Jarl L. Bruvoll, VPS, NORWAY.
Change 17.389 Support for HP's Measureware V11.0 for HPUX adds several
VMACMWUX fields (incompatibly, since they were inserted in the
Jan 28, 2000 middle of the records).
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.388 Additional arguments were added for better tailoring, and
VMXGRMFI additional new variables are now kept in both RMFINTRV
Jan 27, 2000 and TRNDRMFI datasets.
-New OPERANDS:
If you specified IMACWORK=NO and USEREPRT=YES, you could
not drop unwanted Control Performance Groups or Service
Classes; now you have these new operands:
DROPPGN= A list of performance groups numbers, which
could be either Control or Report Performance
groups, that are to be deleted.
DROPSRV= A list of service class names, which could be
either Service or Reporting Class names, that
that are to be deleted.
In case you really need to add special logic as each of
the individual TYPE7xxx datasets are brought in, these
new macro variables permit insertion of any SAS code:
INCODE70= INCODE71= INCODE72= INCODE73= INCODE74=
INCODE75= INCODE78=
-Migration age was not being tracked by RMFINTRV so the
MIGAGEMX, MIGAGEMN, and MIGAGEAV variables were added,
and if it makes sense to track migration age, it should
make sense to also add the HIUIC values.
RMFINTRV new variables:
HIUICMN HIUICMX MIGAGEMN MIGAGEMX MIGAGEAV IORATE70
TRNDRMFI new variables:
HIUICMN HIUICMX MIGAGEMN MIGAGEMX MIGAGEAV IORATE70
PMGIEXAU
-Note that the actual values many variables in RMFINTRV &
TRNDRMFI datasets that came from TYPE71 with labels that
indicate they are average values are actually the maximum
value of the average value of each of the individual RMF
interval values. These variables are:
FIXEDAV CSLPFXAV LPAFXAV LSQAFXAV PRVFXAV SQAFXAV
FIXLOAV PCTLSWAP PVTAFCAV CSTORE ESTORE
Thanks to Normand Poitras, ISM, CANADA.
Thanks to Raymond Schwartz, First Data, USA.
Change 17.387 The _STY94 macro contained PROC DELETE instead of invoke
VMAC94 of %VMXGDEL(DDDDDD=TY94), so you could not change the PDB
Jan 26, 2000 ddname and sort into work. With this correction, the MXG
syntax: %INCLUDE SOURCLIB(TYPE94);
%LET PTY94=WORK;
_STY94;
will sort WORK.TYPE94 into WORK.TYPE94. Note that this
syntax is general, and works with all TYPExxxx members.
Thanks to Joseph M. Marchesani, Equitable, USA.
Change 17.386 MXG 17.10 only. Labels for BYTEREAD and BYTERPCR contain
VMACNTSM extraneous trash and hex characters that should have been
Jan 26, 2000 errored by the SAS compiler, but weren't detected until
execution of their data records, causing unrelated error
message INVALID HEXADECIMAL CONSTANT STRING CONNXAFA=....
Thanks to Bob Gauthier, Albertsons, Inc, USA
Change 17.385 Support for OS/390 Release 2.9.
BUIL3005 TYPE30:
BUILD005 - New SMF30WMI variable 'Y' identifies jobs executing in
EXTY30MR a WLM managed batch initiator.
EXTY9207 - New SMF30MSI variable 'Y' if remote system data is
EXTY94 incomplete. I don't know what this really means, but
FORMATS suspect it means a permanent data loss.
IMAC97 - New triplet for the Multisystem Enclave Remote Data,
TYPE97 with a separate section for each system on which remote
TYPS97 enclaves of this job were executed, contains:
VMAC30 RMSU_SEC - CPU SU_SEC OF THIS REMOTE SYSTEM
VMAC7072 MRENSYST - SYSTEM ID OF THIS REMOTE SYSTEM
VMAC97 CPUMRDTM - CPU TIME FOR DEPENDENT REMOTE ENCLAVES
VMXGINIT CPUMRITM - CPU TIME FOR INDEPENDENT REMOTE ENCLAVES.
Jan 26, 2000 These variables are output in the new TYPE30MR dataset
with an observation for each segment in this job, but
the CPUMRDTM and CPUMRITM are summed across all of the
remote segments and the sum is kept in TYPE30_V, _4,
and TYPE30_5 datasets, as well as being kept in the
PDB.STEPS and PDB.JOBS built by BUILDPDB.
If your remote systems are of different speeds, you
may want to normalize these remote CPU times before
they are output; the exit member EXTY30MR allows you
to normalize the new CPUMRDTM and CPUMRITM if needed.
TYPE72/TYPE72GO
- Three new Active durations for enclaves were added:
to the TYPE72 and TYPE72GO datasets:
TYPE72 TYPE72GO Description
SMF72IEA R723CIEA INDEP*ENCLAVES*ORIGINATED*ACTIVETM
SMF72XEA R723CXEA EXPORTED*ENCLAVES*TOTAL*ACTIVETM
SMF72FEA R723CFEA FOREIGN*ENCLAVES*TOTAL*ACTIVETM
TYPE92
- New subtype 7 for NFS FILE SYSTEM MOVE creates new
TYPE9207 dataset with 33 variables.
TYPE97
- New SMF type 97 for FOREIGN ENCLAVE CPU TIME creates
dataset TYPE97 with an observation for every system
that exported Enclaves to this system containing the
Dependent and Independent Enclave CPU time consumed
by Foreign Enclaves on this system.
Change 17.384 Support for Lotus Domino Server Release 5.02 SMF 108,
EXTY1083 added GMT interval start/end times, system, sysplex and
IMAC108 level to the product section, which are now added to the
VMAC108 existing subtype 1 datasets (with a heuristic algorithm
VMXGINIT to convert GMT to local until IBM adds the GMT Offset).
Jan 26, 2000 The new subtype 3 Monitoring and Tuning data record now
creates new dataset TYPE1083 with interval activity and
buffer pool statistics. Problems with subtype 3 data:
- Five counters in Release 5.02 are accumulated:
DOMTDBCI (DBCACHE Initial DB Opens) and
DOMTDBCO (DBCACHE OVERCROWDING REJECTIONS)
DOMTDBHI (DBCACHE Hits)
DOMTDBPR (DATABASE BUFFERPOOL READS)
DOMTDBPW (DATABASE BUFFERPOOL WRITES)
which was not IBM's intention, and those counters will
be fixed in Release 5.03 later this year. The MXG
_STY1083 SORT macro deaccumulates those variables only
if the record is from Release 5.02, but you will need
to add _STY1083 in your EXPDBOUT member if you add
SMF 108 record processing to you BUILDPDB.
- These MXG subtype 3 variables are set by environmental
server variables, rather than being measurements:
DOMMXUS /*MAXIMUM*NUMBER*OF USERS*/
DOMTLMCS /*LIMIT FOR*CONCURRENT*TRANSACTIONS*/
DOMTMXCS /*MAXIMUM*CONCURRENT*SESSIONS*/
DOMTTMOT /*DURATION*IN*TIMEOUT*/
DOMTMXCU /*MAXIMUM*CONCURRENT*UPDATE*TASKS*/
DOMTMXRE /*MAXIMUM*CONCURRENT*REPLICATORS*/
DOMTSATH /*SERVER*AVAILABILITY*THRESHOLD*/
If you don't change the corresponding environmental
variable at your installation, a default value is put
in the SMF record. For the 2nd-4th fields, default
values are meaningless: FFFFFFFF FFFF000 F900, (so
variables DOMTLMCS, DOMTMXCS and DOMTTMOT are set
missing if they contain those values).
Thanks to Tom Wieland, Phoenix Home Life, USA.
Change 17.383 Member IMACJBCK ("Job Check" exit) is now included in
VMAC83 these members that input JOB and READTIME. The IMACJBCK
VMAC92 exit lets you select SMF records for specific JOBs. Four
VMACHIPR other members, VMACSTC, VMACSUIN, VMACTCP, and VMACWSF
Jan 24, 2000 do contain job name, but they do not have the READTIME so
without both JOB and READTIME (the "job log"), they are
not really written on behalf of a job execution, and so
they don't include IMACJBCK.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.382 DB2 TCB time for stored procedures (QWACSPCP & QWACSPTT)
VMACDB2 are now added into DB2TCBTM variable in DB2ACCT, as they
Jan 24, 2000 are not already captured in DB2TCBTM.
Thanks to Brandon Persinger, The Gap, USA.
Change 17.381 Revised utility program to print MXG Newsletters from the
PRINTNL member NEWSLTRS or CHANGESS, under either MVS or ASCII.
Jan 24, 2000 To print Newsletters using MS Word:
Open NEWSLTRS.SAS as a new document.
Adjust the page setup:
Select portrait
Set top.bottom margins to .6 inches.
EDIT/REPLACE ALL _PAGE_ with a "manual page break",
by select "more" on the replace panel then
"special" to get to this option.
EDIT/SELECT ALL change font to COURIER NEW 9 point
PRINT
Change 17.380 First MXG 17.10. The first few tapes had version date of
AAAAAAAA Jan 20, 1999, which was not Y2K Ready. MXG 17.10 dated
Jan 24, 2000 Jan 24, 2000 corrected that cosmetic error, since that
is only a display string and is not a SAS date value.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.379 Documentation. All ADOCxxxx members were examined and
ADOCall revised to be consistent (i.e., force ZDATE to always be
Jan 24, 2000 the last listed variable for each dataset) so that we can
programatically compare the variables in member DOCVER
with each ADOC and update the ADOC with new or changed
variables while still keeping the original ADOC text.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.378 Type 74 subtype 4 (Coupling Facility) records caused MXG
VMAC74 to "INPUT STATEMENT EXCEEDED" because only 12 of the 18
Jan 24, 2000 structures had complete data in the RMF record. Whenever
the total size of the structure Request Data and Cache
Data sections is greater than 32760, IBM creates multiple
"broken" records from the "large" record, but the 74.4
"broken" records, unlike the 74.1 and 74.2, are invalid.
Instead of RMF writing one SMF record with 12 structure
Request Data sections and the associated 134 Cache Data
sections, and then writing a second record with the other
6 structure's Request Data sections and the associated 2
Cache Data sections, RMF wrote a first record containing
all 18 structure Request Data sections and the 134 Cache
Data sections for structures 1-12, and then RMF wrote a
second SMF record containing only the two remaining Cache
Data sections (one each for structure 13 and 14), but as
neither the Structure nor Request Data sections are in
that second record, it is IMPOSSIBLE for MXG to decode
the second broken record.
The record has SMF74RAN=1, indicating the "Reassembly
Area" exists, but that design (to reassemble multiple
"broken" records into a large record in the virtual
memory of the reading program) requires offsets from one
SMF record to be used to input fields in another SMF
record, and that algorithm fails unless all of the SMF
broken records are adjacent and found in the input SMF
file, which cannot be guaranteed (as, for example, when
the first broken record is the last record in today's SMF
file, or if the SMF data was presorted).
"Broken" records and reassembly areas are not new, but
IBM has previously never spanned logical data fields
between two physical records. Both the 74 subtype 1 and
subtype 2 records are "broken" when there are many
devices, but each "broken" record is self-contained and
can be decoded with no dependency on other records. The
required solution for the type 74 subtype 4 record is for
IBM to write self contained data records. The first
record should contain only as many Request Data sections
as will fit with their associated Cache Data sections.
Second and subsequent records must contain the Product,
Local Coupling Facility, and Structure data sections, and
then as many Request Data and their Cache Data sections
that will fit together.
To circumvent the error, an additional condition:
AND CDSILOC+SMF744CL LT LENGTH
was inserted in the existing IF statement
IF R744CDSI GT 0 AND R744CDNE GE 1 THEN DO;
before the THEN, so that the missing cache data sections
are skipped (causing missing values in TYPE74ST). Thus
far, only a few bad 74.4 records have been found per
day on this OS/390 R2.8 system.
While IBM's RMF Reporter does handle these broken records
if they are found in the same SMF input file (which RMF
has to first sort for the reassembly algorithm), if the
second record is not in today's data, the RMF Report just
skips that interval in its reports!
In conversation with RMF developers, they have now agreed
to revise their design so that when "broken records" must
be written, they will be self-contained and not dependent
on the contents of other records for decoding.
This investigation also uncovered an MXG oversight; only
the first cache data section was read for each structure,
but there are a few structures that have as many as 63
cache data sections, (but only two of those sections had
any non-zero counter values!). Now MXG sums all of the
cache data section counters for each structure.
Thanks to Steve Lottich, University of Iowa Hospitals, USA.
Change 17.377 Change 17.290 changed SORT fields, but this JCL example
JCLIMSL6 was overlooked (LG and L5 were correct). It should be:
Jan 21, 2000 SORT FIELDS=(1,12,A,43,8,A,29,1,A),FORMAT=BI
as described in the text of that change.
Thanks to John Pierce, Liberty Mutual, USA.
Change 17.376 Variables POOLNPBY and POOLPGBY in NTINTRV dataset were
NTINTRV from the SERVER dataset instead of from the MEMORY data,
Jan 21, 2000 so their values were not correct in NTINTRV. Inserting
(DROP=POOLNPBY POOLPBY) after _LNTSERV in the MERGE
statement will correct this error.
Thanks to Greg Jackson, National Life of Vermont, USA.
======Changes thru 17.375 were in MXG 17.10 dated Jan 20, 2000======
Change 17.375 Report was showing equal utilization of the channel for
ANALPATH both the LPAR and the CEC.
Jan 20, 2000
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.374 Windows 2000 NTSMF enhancements, etc.
EXNTSMTN -Objects 'Job Object' and 'Job Object Details' are still
EXNTTRMS flakey, sometimes containing NRNAMES and instance names
EXNTTRMV (1 in Job Object, 2 in Details), sometimes NRNAMES=0.
FORMATS While this is being resolved, MXG now protects both,
IMACNTSM (but if NRNAMES=0, then the names will be blank and the
VMACNTSM records of questionable utility!).
VMXGINIT -New variable FTPUPTME added to FTPSERV dataset from the
Jan 20, 2000 'FTP Service' object.
-Three new objects supported:
dddddd Dataset Object
NTSMTN SMTPNFS SMTP NFS Store Driver
NTTRMV TERMSERV Terminal Services
NTTRMS TERMSESS Terminal Services Sesion
-Sixty new variables added to SMTPSERV dataset from the
'SMTP Server' object are protected, but not input; I
ran out of time in building MXG 17.10, but call for
the update.
Jan 21, 2000: No update needed; MXG 17.10 did contain
all of the new variables, but I forgot to go back and
change this text.
Thanks to Jim Quigley, Con Edison, USA.
Change 17.373 TRNDRMFI has been updated to keep xxxxMEMR memory vars
TRNDRMFI as 8 bytes, like all other measures of memory, so that
Jan 20, 2000 there is no loss of resolution.
Change 17.372 Replaced by Change 17.378.
VMAC74
Jan 20, 2000
Change 17.371 Support for LDMS product creates three new datasets:
EXLDMSDB dddddd dataset label
EXLDMSDI LDMSDB LDMSBASE SI-LDMS-BASE
EXLDMSPC LDMSDI LDMSDIST SI-LDMS-DIST
FORMATS LDMSPC LDMSPC SI-LDMS-PC
IMACLDMS in this user-contributed enhancement.
TYPELDMS LDMS is from Software Innovation in Germany, and it is
TYPSLDMS used for archiving and viewing JCLLOG, SYSLOG, reports
VMACLDMS and lists that were previously printed and delivered.
VMXGINIT
Jan 20, 2000
Thanks to Thomas Heitlinger, FIDUCIA IT AG AG, GERMANY.
Change 17.370 This test version of VMXGSUM enables a SAS VIEW in the
XMXGSUM first datastep to reduce time and resources (CPU, I/O,
Jan 19, 2000 and especially DASD space, since a VIEW is essentially a
pipe that avoids hardening a dataset. This version also
allows you to create the output dataset as a view with
OUTDATA=X/VIEW=X, syntax (but of course you must use that
dataset before you invoke VMXGSUM again). This member
will become VMXGSUM in the next version, but is placed
here for wider testing; copy this XMXGSUM into VMXGSUM
in your USERID.SOURCLIB to test it yourself.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.369 CPU Activity Report can now utilize the INTERVAL and
ANALRMFR MYTIME parameters for summarization tailoring.
Jan 18, 2000
Change 17.368 Support for Beta91 Balancing Manager SMF Record creates
EXTYBE9A four new datasets from the many subtypes:
EXTYBE9B "dddddd" Dataset Label
EXTYBE9C TYBE9A BETA91A BETA91 HEX ST 10,14,28,48
EXTYBE9C TYBE9B BETA91B BETA91 HEX ST 22,24,36,42,44
FORMATS TYBE9C BETA91C BETA91 HEX ST 50
IMACBE91 TYBE9D BETA91C BETA91 HEX ST 60
TESTUSR1 The second variable data portion of the subtype 22-44
TYPEBE91 record is not documented, so those fields are not yet
TYPSBE91 decoded into dataset BETA91B.
VMACBE91 -Minor, but SMFCSTIM was shifted one byte to the left in
VMXGINIT the record ('45400000'x instead of '00454000'x for noon),
Jan 17, 2000 so there is an extra divide by 256 required.
Thanks to W. Waldeyer, BHF-Bank AG, GERMANY.
Change 17.367 NETSPY NSPYAPPL dataset had missing values for response
EXNSPYAP time and percentages when NETRSPN6 (computed number of
VMACNSPY LU6.2 responses) was zero. Logic was added to use the
Jan 15, 2000 TOTRSPN6 (total number of LU 6.2 responses) if NETRSPN6
is zero. Additionally, exit EXNSPYAP tested only TRANSNO
or OUTPUTNO, which suppressed output of any interval that
had LU6.2 traffic but no 3270 traffic. The test now also
tests TOTRSPN6 so that LU6.2-only intervals are output.
Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
Change 17.366 Deleted TMS volumes still in the TMC that had DENX=00x
VMACTMS5 printed DENSITY IS MISSING and a hex dump of the record
Jan 14, 2000 on the log, with no other impact. The existing test
ELSE IF DENX=0DEX THEN DEN=0; was expanded to read
ELSE IF (DENX=0DEX OR DEL='Y') THEN DEN=0; and that
block of code was relocated to after DEL='Y' is set.
Thanks to Warren Hayward, TJX, USA.
Change 17.365 The _Sdddddd and _Bdddddd macros (SORT and BY list) have
VMACTCP been updated so they can now be used. The _SUBTCP5 macro
Jan 13, 2000 was deleted, as it was never referenced; the statistics
record is recognized by length, not by subtype (which was
user-settable and thus not reliable!).
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.364 XCF Path Statistics report, updated to report all
ANALRMFR paths.
Jan 13, 2000
Thanks to Neil Ervin, Schwab and Company, USA.
Change 17.363 Year 2000. Julian Date Values for these products have
VMACACF2 been protected to convert 01yyddd values to 20yyddd:
VMACCTLT TYPEACF2 - LIDADATE, LIDCDATE, LIDDXPDT, LIDIPDAT, prot.
VMACLMS TYPECTLT - CTLTDSN/CTLTVOL variables protected.
VMACPROS but there are EXPDT fields that are not
Jan 14, 2000 protected for invalid dates (like 99366).
TYPELMS - This code had not been updated in a long time.
EXPDT is now correct, but several datasets
were also corrected, and the code now runs
under ASCII as well as EBCDIC versions of SAS.
These changes support Sutmyn/VTS/LMS 3.4.
TYPEOMAU - OMJULDAT is protected, and OMDATIME corrected.
TYPEPROS - GWADATE protected. GWAEXPDT is character.
TYPEWSF2 - No julian date variable, listed in error.
Unfixed, awaiting raw data:
TYPEIAM: IAMCDATE=0852 decimal, 0354 hex, doc dddy!!!
Unvalidated, these products have unvalidated fields and
no test data has been made available. See the
member YEAR2000 for variables and datasets:
TYPEBETA TYPECMF TYPEDECS TYPEEDGR TYPEEDGS
TYPEEPIL VMXGHSM TYPESARS TYPETMDB TYPETMVS
TYPETLMS
Thanks to Warren Hayward, TJX, USA.
Thanks to David Ehresman, University of Louisville, USA.
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Thanks to Caron Know, Willis, ENGLAND.
Thanks to Steve Clark, California Federal, USA.
Thanks to Coen Wessels, UNICIBLE, SWITZERLAND.
Thanks to Caron Knox, Willis Corroon Group Services Limited, ENGLAND.
Change 17.362 Documentation only; no code was changed. Highwatermark
VMACTMO2 and lowatermark values in TMON for CICS/ESA 2.0 (TCE)
Jan 13, 2000 statistics interval records will be always zeroes after
applying SYSMOD TH01288 to TMON, but the HWM values in
the TI record will still be valid, as they are obtained
differently than the TCE records. The SYSMOD text has an
extensive discussion of why the TCE HWM/LWM values cannot
be calculated when the TCE interval is different than the
CICS statistics interval. These fields in these records
will be zero:
Record Fields
TP TPGWLRHW TPGHWMT
TS TSGSTA6F TSGQNUMH TSGNCIAH TSGBUWTH TSGNVCAH
TSGVUWTH TSGQINH
TD TDGAMXIU TDGAMXAL TDGAMXWT TDGAMXCI TDGSMXAL
TDGSMXWT
TX TXGPAT TXGPQT
TR TRVRPLX TRVRPLXT TRXMCPAT TRXMCCPQ TRVLUHWM
T2 T2TCBQHW T2TCBHWM T2ETHDHW T2EPTHDP T2EHTASK
T2EH
TM TMCE1HWM TMCE2HWM TMCEBHWM TMCESTAM
TT TTRMCNT
TF TFFDSHSW TFFDTSHI
Change 17.361 Extension to Change 17.339 for EREP records. Now, all
VMACEREP EREP record types are tested and will be bypassed (and
Jan 12, 2000 and MXG WARNING message printed on the log) if any of the
invalid record bits are enabled; previously only the
record types that had experienced bad bits were
protected. IBM's EREP writes out truncated records when
it runs out of buffer space, and sometimes EREP doesn't
edit the record and only writes out what's in the buffer,
and sometimes EREP writes out incomplete records. Also,
MCH '13'x record conditionally inputs ERRORID by testing
length in LRBMLNH to avoid STOPOVER.
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Thanks to Les Geraghty, DMR (an Amdahl Corporation), IRELAND.
Change 17.360 The RMFINTRV/VMXGRMFI enhancements added in MXG 17.09
VMXGRMFI have been revised and corrected, so the errors and fixes
RMFINTRV apply only to the 17.09 code, but all of the new stuff
TRNDRMFN now works! Your existing IMACWORK member will continue
Jan 12, 2000 to work to define your workloads, if you do nothing, but
Jan 20, 2000 now you can EDIT member RMFINTRV (instead of IMACWORK) in
your USERID.SOURCLIB to create new workloads either in
addition to your IMACWORK workloads, or instead of, by
ignoring in IMACWORK completely. Member RMFINTRV invokes
%VMXGRMFI, so you EDIT RMFINTRV to change the arguments.
Remember, you NEVER change member VMXGRMFI; you only read
it for its documentation of the arguments in comments.
Then, in your RMFINTRV member, you invoke %VMXGRMFI with
your chosen workload definitions, parameters, etc.
Member RMFINTRV has documentation and examples in its
comments.
To match output to input sums exactly, all of the length
4 variables in RMFINTRV are now stored in 8 bytes. The
truncation when stored in four bytes is only in the 7th
significant digit, so using length 4 is not wrong, but
with a daily totaly of 1,000,000 seconds, that caused a
visually-obvious-even-if-not-significant difference of
0.1 of those million seconds lost between RMF & RMFINTRV.
Since I wasted a full day chasing down that difference, I
decided the small increase in DASD space would be worth
you never having to ask why there was any difference!
RMFINTRV now uses SAS VIEWS to pass data from one step to
another without using DASD space, but now, an ignorable
note "A stored DATA STEP view cannot run under a
different operating system" is printed on the SAS log.
Some additional documentation comments.
Specifying IMACWORK=NO may cause UNINITIALIZED VARIABLE
messages on the SAS log for the old variables that you
no longer want. Putting a comment block aroung the
label statement in your EXRMFINT member will eliminate
those messages, but they have no impact.
Any workload can be broken into periods, with a set of
variables for each period, including response time,
transaction count, and swap count as has always been
done for the TSO workload. You need to tell VMXGRMFI
how many periods to be mapped with the syntax:
WORKn=NNNN/LLLLLLLL/PGN/SRVCLASS/PERIODS
See PERIODS= in member VMXGRMFI.
If you specify to use Report Classes/Perfgrps, but you
also say to use your IMACWORK member, and that IMACWORK
member still contains the default to delete Report stuff
the IMACWORK will have deleted the Report stuff before
the new definitions are used. You will need to revise
your IMACWORK member to permit use of Report stuff.
Trending on the new RMFINTRV variables can now also be
done, with this new VMXGRMFI's TRENDIN=, TRENDOUT=,
TRENDBY=, and TRNDINTV= arguments, and by setting PDB=.
Member TRNDRMFN is an example of the new syntax that
will invoke VMXGRMFI to create TREND.TRNDRMFI with all
of the new workload variables.
These 17.09-only errors were corrected:
-The default IMACWORK=YES caused MXG error message that
RMFINTRV CPU TIMES DO NOT MATCH because OTHRCPU was
included twice in the creation of variable CPU72TM.
17.09 sites can remove the OTHRCPU from the end of:
,BATCPU,TSOCPU,CICSCPU,IMSCPU,OTHRCPU,
OTHRCPU is the fallthru workload for undefined PERFGRP or
SRVCLASS that were not mapped in your IMACWORK, so if all
work was mapped, then OTHRCPU will be zero and this error
does not occur.
-That error message does NOT set a return code nor stop
your BUILDPDB job (because once you see the error and
fix your workload definitions in your IMACWORK member
or in your RMFINTRV invocation of %VMXGRMFI, you can
simply re-run the RMFINTRV program to re-create the
PDB.RMFINTRV dataset, without re-reading SMF data.
-Detailed validation of 17.09 corrected values in a few
variables from TYPE71 and TYPE74 datasets.
-Using IMACWORK=NO and RPGNs did not use the RPGN data.
Thanks to Bruce Lietz, Cessna Aircraft, USA.
Thanks to Normand Poitras, ISM, CANADA.
Change 17.359 VMXGSUM fails if variable names are created in lower case
VMXGSUM and KEEPALL=NO default is used with SAS V7/V8, as that
Jan 12, 2000 space-saving option invokes logic to figure out what
variables need to be kept, and because the output dataset
created by PROC CONTENTS that contains the list of
variable names that exist has lower case values in
variable NAME, but the dataset created by parsing of the
arguments (like SUMBY=) that contains the list of
variables that are needed has upper case values in its
variable NAME, which then causes the MERGE matchup:
MERGE A (IN=INA) B (B=INB); BY NAME; IF INA AND INB;
to fail, as it sees those NAMEs as different values.
And since there is no SAS facility for case-insensitive
character tests nor case-insensitive MERGEing, three
UPCASE() functions were inserted in the three places
where variable NAME is read from the PROC CONTENTS output
dataset.
I discovered this one while creating CHANGE 17.358, and
accidentally used lower case in my test program, but it
was very nasty in impact and not obviously caused. There
was no error condition, but the output dataset had only
17 observations instead of 212; there were a few MISSING
VALUES messages on the log during MXGSUM1 creation. Only
when the SUMBY variables were printed was it found that
one of them did not exist in the output dataset, which
led to the discovery and fix.
Using argument KEEPALL=YES will circumvent this error,
because that bypasses the NAMEs matchup, but it can waste
//WORK space if there are many unused variables.
Ain't mixed case fun?????
Change 17.358 An additional sample NETSPY report that replicates the
ANALNSPY MICS SNTNSS report from MXG's NSPYLU dataset was added to
Jan 12, 2000 the examples in ANALNSPY. (However, the MICS report does
not correctly count input transactions; the MXG report
prints both the MICS number and the true number).
Thanks to Gene Rahe, Experian, USA.
Change 17.357 To modify BUILDPDB to copy CICS Statistics datasets to
EXPDBOUT your PDB, you should insert this code in EXPDBOUT:
Jan 12, 2000 _S110
Jan 20, 2000 MACRO _SCICEXC %
The BUILDPDB writes all CICS Statistics datasets to the
work file (to later create PDB.CICINTRV), but those 50+
individual CICxxxx datasets are not copied into the PDB
by default (they can be large; if you don't ask for them,
they won't waste any space in your PDB). That macro
invocation of _S110 sorts each TYPE110 dataset to the
PDB, and the two MACRO redefinitions to null out the
sorts of datasets CICSEXEC and CICSYSTM are needed
because BUILDPDB will try to sort them later in its own
logic, after the EXPDBOUT exit has been executed.
Note: if you don't want to create any observations from
the type 110 subtype 2 CICS statistics records, add this
statement: IF ID=110 AND SUBTYPE=2 THEN DELETE; in
your IMACFILE exit member.
Thanks to David Ehresman, University of Louisville, USA.
Change 17.356 Using Excluded CICS fields with CICS TS 1.3 failed,
IMACEXCL because the DO group IF MCTSSDCN LT 202 ... should have
Jan 11, 2000 been deleted when the TS 1.3 INPUT logic was copied into
member IMACEXCL. Delete that DO group.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.355 Type 42 Subtype 7/8 NFS records caused INVALID NF-CL
VMAC42 SECTION TRIPLET error, but the message itself was in
Jan 11, 2000 error. The test OFFCL+LENGTH GT LENGTH should have been
OFFCL+LENGTH-1 GT LENGTH. The INPUT of SMF42CHL (twice)
was changed from &PIB.4. to &PIB.2. and SUBTYPE= was
added to those INVALID messages. Datasets TYPE42NF and
TYPE42NU were affected.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.354 Summarized variable RESPSTD was always zero; the code
ASUMCICS SQRTARG=(SSQELAP/NUMTRANS)-(IRESPTM**2);
ASUMCICX must be changed to read:
Jan 11, 2000 SQRTARG=(SSQELAP/NUMTRANS)-((IRESPTM/NUMTRANS)**2);
Thanks to Normand Poitras, ISM, CANADA.
Change 17.353 Protection for the unwise. If you use the same name for
VMAC7072 a Service Class and for a Report Class, the MXG NODUP
WEEKBLD removal would not remove all duplicates. Adding variable
MONTHBLD RPRTCLAS at the end of MACRO _BTY72GO will not impact the
Jan 11, 2000 existing sorted datasets but will delete any duplicate
records in TYPE72GO.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.352 Year 2000. Variable OUTDATE was still a 0cyyddd value,
VMACTMS5 having been overlooked by Change 16.330, but now it is
Jan 11, 2000 converted into a yyyyddd value.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 17.351 Format MGSTCRS was corrected to 00/01 UN-/CONFIGURED.
FORMATS Labels for STC26MST/MET were changed to TAPECOPY vice
VMACSTC MIGRATE, for STC26VPO was changed to Position on the new
Jan 8, 2000 MVC, and for STC26MID was changed to VTV VOLSER.
Thanks to Herb Strazinski, US Bank, USA.
Change 17.350 SYNCSORT flag variables CONTIGn was wrong if SMFWKCID
VMACSYNC contained multiple bits, variable CACHFWn was created but
Jan 8, 2000 not kept, and two new flag variables were not decoded.
Now, CONTIGn and CACHFWn are kept and right, and two new
variables are decoded and kept:
DYNALOn = 'WORK n*DYNAMICALLY*ALLOCATED?'
UNOPENn = 'WORK n*UNOPENED*DISP=OLD?'
for n=1 to 32, for each possible Sort Work Area. Also,
the UCB address in variables UNIT1-UNIT32 is now the four
digit character address, so their stored length was
increased from $3 to $4.
Thanks to Steve Colio, CIGNA, USA.
Change 17.349 IBM Documentation of TELNET LOGF Date and Time Fields was
VMACTCP wrong, causing MXG variable TELLOGFT to be wrong.
Jan 7, 2000 Instead of being the time of logoff, the time field at
offset 82-85 is the elapsed duration of the session! And
the date field at 86-89 is redundant with the SMF date
field (and this is the date field that IBM's APAR PQ34359
plans to change from the non-standard yyyydddF format to
0cyydddF in spite of its uselessness!). Adding the
session duration and that date field created a value on
Jan 3, 2000, for a session that ended Jan 1, which made
this look like a Year 2000 problem, but it was just bad
documentation! Now, TELLOGFT is the LOGF datetime value,
new variable TELLOGON is the calculated LOGN datetime
value, and new variable TELLOGTM is the elapsed session
duration.
Thanks to Freddie Arie, Texas Utilities, USA.
Thanks to Jerome Vitner, Experian, USA.
Change 17.348 This GRAF example failed if you did not have SAS/GRAPH;
GRAFLPAR while the actual PROC GPLOTS were protected, the graph
Jan 6, 2000 control statements AXIS1, SYMBOL1, etc, were not and
caused AXIS1; to create a 180 syntax error.
Thanks to Michael E. Rounceville, Shaw Industries, USA.
Change 17.347 APAR OW42559. Variable UCCOLDT contains 1900001F for
VMACDCOL data on Jan 1, 2000, and records will be lost until the
Jan 5, 2000 end of January, 2000, according to that APAR text.
Change 17.346 INVALID DATA FOR IOSSTIME error because an additional 4
VMACICE bytes were added to the subtype 8 ICEBERG SMF record, but
Jan 5, 2000 MXG failed to protect for a change in segment size. The
correction is to insert these two lines:
SKIP=LENSEG-128;
IF SKIP GT 0 THEN INPUT +SKIP @;
immediately before this line:
_EICE8NP /*INC SOURCLIB(EXICE8NP); _WICE8NP .... */
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Change 17.345 MXG 17.06-17.09 only. INVALID NUMERIC DATA CECSER=...
ASUM70PR error because MXG 17.06 added statements that used CECSER
Jan 5, 2000 as a numeric variable, but it is created as a 6-byte
character variable. The actual CPU Serial number
contained xxC4, which surfaced this error.
The test IF CECSER=. THEN CECSER=.; must be changed
to IF CECSER=' ' THEN CECSER=' '; and the
test IF CECSER=. THEN DELETE; must be changed to
IF CECSER=' ' THEN DELETE;
Thanks to Darlene Wnukowski, Schreiber Foods, Inc, USA.
Change 17.344 Year 2000. Support for ZARA Release 1.3 (INCOMPATIBLE).
VMACZARA Release 1.3 is the only Y2K Ready version of ZARA, and
Jan 5, 2000 the record format was changed to the API records, so you
will need this change to support ZARA records. In
addition to 1.3 record changes, MXG's logic for the
FILDATEX was wrong; the test FILDATEX GE 1999365 was
corrected to read:
FILDATEX EQ 1999365 OR FILDATEX EQ 1999366 OR
FILDATEX EQ 1999999)
Thanks to Norbert Ravarani, European Commission, LUXEMBURG.
Change 17.343 Variable NEXTENT, the number of extents on this volume,
ANALDSET was added to dataset DSETOPEN created by ANALDSET. The
Jan 3, 2000 DCOLLECT/TYPEDCOL is probably better for analysis of
Feb 2, 2000 dataset extents, because DCOLLECT sees all datasets on a
volume at the time DCOLLECT is run, while ANALDSET only
sees datasets that were closed in input SMF file time
interval (SMF type 14,15,64). Nevertheless, if you need
to track which job and which open is causing datasets to
extend, using this revised ANALDSET will now provide
NEXTENT for both VSAM and non-VSAM files. The structure
of ANALDSET was also revised; no longer do you need to
IEBUPDTE step to create the temporary tailoring PDS
library; the revised program now tailors instream using
%LET MACKEEP= architecture.
Feb 2: _N30, _N1415, _N64 added to null all datasets and
then define the wanted; creation of new TYPE30MR caused
the earlier revision to fail, but now its futurized.
Thanks to Tien Truong, CITICORP, SINGAPORE.
Change 17.342 Year 2000. TYPE1415 variables EXPDT and CRDATE were not
VMAC1415 converted to yyyyddd format (they were overlooked in
VMXGINIT Change 16.330) and are still in cyyddd format, so they
Dec 31, 1999 print as 100001 for 1Jan2000. This change adds in the
Jan 12, 2000 algorithm from member YEAR2000 to convert both EXPDT and
CRDATE to value 2000001 instead of 100001, and changes
their label to show YYYYDDD as their value. Member
VMXGINIT is also needed if you are still at MXG Version
16.16, or you can insert this statement:
%LET WTY1415=WORK;
as your first //SYSIN DD statement.
Thanks to Rebecca Cates, PKS Information Systems, USA.
Thanks to Frank Cortell, CSFB, USA.
Change 17.341 Year 2000. MXG created SAS date variables CREATED,
VMXGVTOF EXPIRES, and LASTUSED are wrong in Y2K in this archaic
Dec 31, 1999 VTOC reading program (which was replaced by DCOLLECT),
although the julian date variables CRDATE, EXPDT, and
LASTUSE are correct. The correct equations are:
CREATED=DATEJUL((CRCENT+19)*100000+CRDATE);
EXPIRES=DATEJUL((EXCENT+19)*100000+EXPDT);
LASTUSED=DATEJUL((LACENT+19)*100000+LASTUSE);
The incorrect equation produced dates that were either
off by one day if YEARCUTOFF=1900, or off by 36525 days
if YEARCUTOFF was 1960.
Thanks to Geoff Morley, Origin Netherlands, THE NETHERLANDS.
Change 17.340 Three cases of "$EBCDIC8 " were changed to "$EBCDIC8."
VMACOMVT
Dec 24, 1999
Thanks to Freddie Arie, Texas Utilities, USA.
======Changes thru 17.339 were in MXG 17.09 dated Dec 22, 1999======
Change 17.339 INPUT STATEMENT EXCEEDED RECORD LENGTH for EREP records
VMACEREP because the HDRIS flag bits were not being tested for all
Dec 21, 1999 record subtypes. IBM's EREP writes out truncated records
when it runs out of buffer space, it sometimes doesn't
edit the record but writes out what's in the buffer, and
writes out incomplete records, all of which are flagged
by HDRIS and BYTE0 flag bytes. MXG covered most but not
all cases, writing out an MXG WARNING that EREP had
created bad records, but now all cases are protected.
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Change 17.338 -The calculation of BPHITRAT, Buffer Pool Hit Ratio, in
VMACDB2 DB2STATB dataset was revised based on Don's research: The
Dec 20, 1999 new algorithm substitutes QBSTRIO for QBSTSIO, and
restores QBSTSPP, which was removed due to negatives:
BPHITRAT=
QBSTGET-(QBSTRIO+QBSTSPP+QBSTDPP+QBSTLPP)/QBSTGET;
-QBSTSPP had been removed when MXG had negative ratios,
but it is better to use it (as it includes all prefetch
pages, regardless of whether these pages were discarded
before actually being used by the application), so that
negative values indicates a potentially serious problem
that could be overlooked without QBSTSPP: pages that are
read via prefetch, discarded before use, and then read
via synchronous sequential read. Large values in QBSTSIO
would also be true for this case, but negative BPHITRAT
would be less likely to be overlooked. Without QBSTSPP,
the equation calculated terrific buffer hit ratios that
were meaningless, since they did not consider the number
of pages that were read via normal sequential prefetch.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 17.337 -Remove TYPE79 processing, not used in IBM reports.
ANALRMFR -Remove TYPE76 processing, not used in IBM reports.
Dec 20, 1999 -New optional parameter ALLTYPE= to build TYPE70-75,
TYPE77 & TYPE78 datasets, or build only those record
types needed for the reports that are requested.
-New optional parameter DEVICEC=, allows selection of
only certain device classes for device reports.
-Update Channel Avtivity report column TYPE of channel.
Change line
IF LPARCPUS GT 0 AND LPARNAME NE 'PHYSICAL' THEN DO;
To
IF LPARCPUS GT 0 THEN DO;
Thanks to Neil Ervin, Charles Schwab & Co.
Thanks to Al Sherkow, Management Strategies, Ltd.
Thanks to Susan Walters, Michelin Tires, USA.
Change 17.336 Variables IMSVERS, IMSRELEASE, and SMBCLASS were changed
VMACITRF from character to numeric (input now with &PIB.1.) to be
Dec 20, 1999 directly readable and to now make sense!
Thanks to Warren E. Waid, JC Penny, USA.
Change 17.335 -Support for Windows 2000 Build 2195 changed field counts
EXNTACRS from the Beta 3 release, so the code was revised to read
EXNTDIST only the Build 2195 records:
EXNTIACC Memory - AVAILMEK and AVAILMEM variables added.
EXNTIACS Logical Disk - Instance Name restored (was missing).
EXNTIATC Print Queue - Instance Name restored (was missing).
EXNTIATS Web Service - SRVUPTME (service up time) added.
IMACNTSM Job Object - Instance Field added, sometimes, but
VMACNTSM data fields are accumulated.
VMXGINIT Job Object Details - Instance Fields added, sometimes.
Dec 19, 1999 Note: we're still researching why some of the Job and
Job Detail records contain no instance fields,
and NTSMF will need to be revised to deaccumulate
the Job Object counters.
-New Objects found in Build 2195:
Dataset dddddd Description
ACSRSVPS NTACRS ACS/RSVP Service
DISTRNCO NTDIST Distributed Transaction Coordinator
IASACCTC NTIACC IAS Accounting Clients
IASACCTS NTIACS IAS Accounting Server
IASAUTHC NTIATC IAS Authentication Clients
IASAUTHS NTIATS IAS Authentication Server
Thanks to Jim Quigley, Con Edison, USA.
Change 17.334 Variables PGBKSYSA PGBKLPA SHPGINAU SHPGOUAU SHPGINES
VMAC71 SHPGOUES in TYPE71 are now converted to rates per second
Dec 19, 1999 and their labels corrected, since they paging rates.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.333 Support for additional Landmark TMVS subtypes, including
EXTMVXC WG (Workload Manager) and XC (Coupling Facility), and
EXTMVXC1 additional fields in other records are now decoded and
EXTMVXC2 created. Test data was available, and most number have
EXTMVXC3 been verified, but there was lots of coding here!
EXTMVXC4
IMACTMV2
VMACTMV2
VMXGINIT
Dec 15, 1999
Thanks to John Jackson, Redcats, UK.
Change 17.332 INPUT STATEMENT EXCEEDED error for VSM subtype 24; the
VMACSTC input of STC24MID should have been $EBCDIC6 instead of
Dec 15, 1999 $EBCDIC8.
Dec 21, 1999 In addition, variable STC13TIM is now corrected by the
addition of DEL6070 (the delta seconds between unix's
1970 epoch and SAS's 1960 epoch - see Change 17.195),
and further protected in case STC changes that to the
TODSTAMP format in the future!
And more: All of the VSM timestamps (except SMFTIME) are
on GMT, and there is no offset provided!
And finally, just in time for the 17.09 build, the bit
test for STC11TOL had an extra 9th postition to delete.
Thanks to Herb Strazinski, US Bank, USA.
Change 17.331 Variable SMF77RF2, a second status indicator, is input to
VMAC77 match RMF report replication in member ANALRMFR.
Dec 14, 1999
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.330 17.05-17.08 only. STOPOVER and/or BAD RECORD messages
VMAC80A if you have installed APAR OW39128, which added RPDSNAME
Dec 13, 1999 to the WHEN (66) decoding, but I believed IBM and read in
with INPUT RPDSNAME $EBCDIC44. But actual data records
show the segment is variable length. Change the above
line to read: RPDSNAME $VARYING44. RACFDLN
Thanks to Joe Faska, Depository Trust, USA.
Change 17.329 Partition Data Report, *PHYSICAL* values zero. Change
ANALRMFR IF LPARCPUS GT 0 AND LPARNAME NE 'PHYSICAL' THEN DO;
Dec 10, 1999 to
IF LPARCPUS GT 0 THEN DO;
References to TYPE79 were removed, as it is not used in
any reports, and caused space problems if PDB=SMF was
specified.
Thanks to Neil Ervin, Charles Schwab & CO.
Thanks to Al Sherlow, Management Strategies, Ltd., USA.
Thanks to Susan Walters, Michelin Tires, USA.
Change 17.328 This utility to show the size (MegaBytes) of each data
UTILCONT set in a SAS Data Library did not have the DETAILS
Dec 10, 1999 parameter specified, and thus returned zero when run
under SAS Verson 6, 7, or 8. Now it always works.
Thanks to Jerry Urbaniak, Peoples Energy Corporation, USA.
Change 17.327 The order of the code in IMACACCT was revised, so that
IMACACCT the &MACACCT invocation now is located after the LABEL
Dec 7, 1999 statement and before the LENGTH statement, so that the
length and label of the account variables can both be
changed instream. For example, this syntax in //SYSIN:
%LET MACACCT=
%QUOTE(
DROP ACCOUNT4-ACCOUNT9 SACCT4-SACCT9
LENACCT4-LENACCT9;
LENGTH ACCOUNT3 SACCT3 $12; ) ;
will drop and change the length as indicated.
Thanks to Paul Oliver, BHP Petroleum, AUSTRALIA.
Change 17.326 Documentation only. The old //PROCLIB DD DSN=xxxxxxx
INSTALL statement was replaced some time ago by the JCLLIB
Dec 7, 1999 statement. An example of that syntax is:
//PROCLIB JCLLIB ORDER=MXG.USERID.SOURCLIB
Thanks to MP Welch, SPRINT, USA.
Change 17.325 This CICS utility to detect what PTFs are installed so
IMACPTF that you can then update member IMACPTF to tell MXG what
UTILCICS is installed has been cleaned up. The double output for
Dec 6, 1999 OMEGADLI, CANMQ, and CANWLMSC were removed, the test for
PTF UN98309 should have been for SMFPSRVR=51.0 instead of
SMFPSRVR=41.0 (and the associated comments in member
IMACPTF were corrected to 51.0), and the test for DBCTL
now tests for CMODNAME=DBCTL.
Thanks to Harry Olschewski, DeTecCSM GmbH, GERMANY.
Change 17.324 The WTIRIOTM (inter region wait time) in ASUMUOW was the
ASUMUOW sum of all of WTIRIOTM values from all transactions in
Dec 6, 1999 the unit of work, but this value is meaningless, as the
multiple waits in the TOR, AOR, etc., were summed. Now,
the WTIRIOTM in ASUMUOW is the WTIRIOTM from the first
transaction, which is also the source of IRESPTM, as this
will provide a more meaningful indication of IR wait for
the unit of work.
Thanks to Alan Meyer, Prudential-Bache Securities, USA.
Change 17.323 -This utility to understand the sequencing of CICS TOR/AOR
UTILUOW transactions now avoids all duplicates in the reports by
Dec 5, 1999 adding variables APPL5, TRAN5, ... TRAN10 to the BY list
for the PROC SORTs of datasets FIRST/MIDDLE/LAST/MOREONE,
and variable INDEX was added at the end for a better sort
sequence.
-Comments for Report 5 were enhanced, because when DBCTL
is used, there are lots of non-mirror transactions with
RTYPE=D that belong to one unit-of-work, that show up in
Report 5 and that are correct and should use case 1.
-Eliminated the first step (and IEBUPDTE to create a temp
PDS for tailoring) by using the 16.04 design to override
instream.
Thanks to Harry Olschewski, DeTecCSM GmbH, GERMANY.
Change 17.322 -Parameter SYNC59 will correct the RMFINTRV interval for
EXRMFINT sites still stuck with SYNC(59) in SMFPRMxx in PARMLIB.
RMFINTRV Because MICS originally used the end-of-interval SMFTIME
VMXGRMFI to summarize data, they required the RMF interval to be
Nov 30, 1999 at 59 minutes rather than on the exact hour. This new
Dec 21, 1999 parameter will "correct" the STARTIME in PDB.RMFINTRV
by adding one minute to STARTIME and ENDTIME so your old
13:59 to 14:59 report shows 14:00 to 15:00.
-Member IMACKEEP was only included if PDB=SMF.
-Parameter IMACWORK=NO did not function in VMXGRMFI, and
it has been corrected, redefined, and redocumented in
member VMXGRMFI. The default IMACWORK=YES causes MXG to
use definitions in member IMACWORK to create workloads in
dataset PDB.RMFINTRV in addition to any workloads that
are created in the WORKnn= parameters in your %VMXGRMFI
invocation. Now, if IMACWORK=NO is specified, not only
is the INCLUDE of IMACWORK suppressed, but also the old
MXG workload variables (BATxxxx,TSOxxxx,..,OTHnxxxx) will
NOT be created in PDB.RMFINTRV; only the workloads that
you define in your %VMXGRMFI invocation will create
workload variables (but you can still create workloads
with those old prefixes in your invocation and they will
be kept).
-Member RMFINTRV now invokes %VMXGRMFI to create the data
set PDB.RMFINTRV, using the IMACWORK definitions, to
exploit the VMXGRMFI performance enhancements (by using
VMXGSUM, especially in SAS V8, when entire data steps can
be skipped due to the new PROC MEANS INHERIT feature).
-An example of how you can invoke VMXGRMFI multiple times
to create additional "RMFINTRV" datasets that are at the
Hour (RMFINTHR), or at the Shift (RMFINTSH), etc., are in
sample VMXGRMFI invocations in member RMFINTRV.
-If you have tailored EXRMFINT to provide labels for OTHxx
variables, your definitions will be used for RMFINTRV,
but if you use VMXGRMFI to create a different dataset
name (like RMFINTHR), you will first need to change the
OUTPUT in your EXRMFINT to read OUTPUT _LRMFINT ; cause
if you don't, you'll get a 455-185 error due to your old
OUTPUT statement in your old EXRMFINT member.
Thanks to Normand Poitras, Banque Nationale du Canada, CANADA.
Change 17.321 Support for IIS Log provides event records with identity
EXIISLOG of user, IP Address, byte counts, etc. in new dataset
IMACIISL IISLOG. This support reads the #FIELDS list of fields and
TYPEIISL populates only those variables in your log records. All
VMACIISL possible IIS Log variables are kept in IISLOG dataset, so
Nov 27, 1999 compression is strongly recommended to eliminate wasted
Dec 19, 1999 space, especially since many character variables are
defined as $64, but usually contain far fewer characters.
Of course you can always use MACRO _KIISLOG to drop any
unwanted variables as well.
Thanks to Xiaobo Zhang, Insurance Services Office, USA.
Change 17.320 The logic to detect the last-complete-interval-time to
ASUMTALO control SPINTALO was imperfect, and could cause part of
Nov 24, 1999 the data for an hour to be split into two separate obs
Dec 5, 1999 in two day's separate PDB.ASUMTALO datasets. The logic
Dec 20, 1999 was revised, which required a change in the sort order of
dataset PDB.ASUMTALO to now be BY DEVICE DEVNR ALOCSTRT.
In addition, we are now using SAS Views to "pipe" data
and avoid physical writing and then reading records.
This works fine, but prints notes on the log reading:
"A stored DATA STEP view cannot run under a different
operating system.", which has no impact.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 17.319 Landmark DB2 Version 3.0 caused INPUT STATEMENT EXCEEDED
VMACTMDB error, because MXG tried to input the CF fields (starting
Nov 24, 1999 with variable DABRH) that don't exist in that version.
The INPUT statement was revised.
Thanks to Paul P. van den Brink, MeesPierson, THE NETHERLANDS.
Change 17.318 Documentation. MXGTMNT TMNT010E WRITE FAIL RC=0024 will
ASMTAPES result if you try to create SMF records with MXG's Tape
Nov 24, 1999 Mount monitor, but have excluded that SMF record number
in your SMFPRMxx member. Depending on how your SYSPROG
chose to code the TYPE/NOTYPE, etc parameters, you may
have to update SMFPRMxx before you can write the SMF
record, and you'll get one of these messages for each
tape dismount and deallocation.
Thanks to Steve Smith, BMC, USA.
Change 17.317 ABEND 2415 due to no RECFM=U in //NULLPDS DD in SAS proc,
MXGSAS and message "INVALID RECFM is DCB NOT (U|F|V)" is printed
on your SYSMSG, if your SMS ACS allocation rules for new,
Nov 23, 1999 temporary PDS libraries leaves RECFM blank, and you are
Nov 29, 1999 using MXG 17.04 or later. The permanent fix from SAS is
Jan 31, 2000 in Usage Note G645 for V6, Usage Note 1651 for V8, is to
add RECFM=U to the //NULLPDS DD statement in SAS proc.
The ABEND was precipitated by MXG 17.04, which added an
INFILE read of //SOURCLIB during initialization, but as
SOURCLIB is also in SASAUTOS, SAS opened that DD, which
concatenates the //NULLPDS DD, and SAS cannot tolerate
a blank value for RECFM when an INFILE is opened.
The MXGSAS JCL Procedure was changed, but if you use
// EXEC SAS instead of // EXEC MXGSAS, you will need to
add RECFM=U to the //NULLPDS DD in the SAS procedure.
The //NULLPDS DD statement exists in the SAS JCL proc,
but it is there only for maintenance and testing, and it
and was included in MXGSAS only for consistency. That
default was changed from only DCB=BLKSIZE=6160, to now
DCB=(RECFM=U,BLKSIZE=6160).
Adding RECFM=FB to //NULLPDS fixed the ABEND and it was
my initial circumvention, because MXG 17.04+ reads from
the //SASAUTOS DD, which points to RECFM=FB datasets.
Now, SAS Technical Support and I now agree that RECFM=U
is slightly the better choice: Both work fine now, but
NULLPDS is also used in //STEPLIB, which is read by IBM
programs, so using RECFM=U protects if a future OS/390
release decides not to tolerate RECFM=FB in STEPLIB.
Thanks to Mike Kepler, Wright State University, USA.
Thanks to Phil Wise, Wright State University, USA.
Thanks to Eladio Aviles, Arizona Public Services, USA
Change 17.316 WARNING: BIT MASK TOO LONG, TRUNCATED ON THE LEFT occurs
VMAC80A if two bytes of bits are compared with a one byte field,
Nov 23, 1999 but the warning is not detected by the compiler, and it
give no clue as to which statement is in error, which was
introduced in Change 17.094 decoding of keyword bits.
Three tests for KW08AUDT, 8 tests for KW25SPEC, and two
tests for KW25ADSP were stripped of the right eight dots.
eg, the line IF KW25ADSP='........1........'B THEN ...
now reads IF KW25ADSP='........1'B THEN ...
Thanks to Joe Faska, Depository Trust, USA.
Change 17.315 MXG 17.08 only. I introduced typos into IMS Log members
ASMIMSL6 when I updated the MXG library from the tested members,
ASMIMSL5 and one more houskeeping statement was added to TYPEIMSA:
ASMIMSLG - TYPEIMSA:
TYPEIMSA Semicolon was missing in this statement:
Nov 22, 1999 IF MTYPE EQ: 'T' THEN STRTTIME=GUTIME; /*RESET....*/
Nov 23, 1999 New statement ENDTIME=STRTTIME; was inserted after
the WSRVTS=ENDTIME-NEWSQ6; statement (line 864).
- ASMIMSL6/L5/LG: Three statements must be changed:
BNZ P301000I should be BNZ P031000I.
CLI MTYPE+3,=C'P' should be CLI MTYPE+3,C'P'
MVI MTYPE+3,=C'T' should be MVI MTYPE+3,C'T'
- ASMIMSL6:
Blank line before label P031000C must be removed.
I thought that my revisions had been re-tested before
MXG 17.08 was sent, but it is now painfully obvious that
they were not!
Thanks to Alan Green, Zurich, ENGLAND.
Change 17.314 The de-accumulation of the Web Server TYPE1032 data was
VMAC103 expanded to BY SYSTEM HOSTNAME IPADDRES PORTNUMB SMFTIME;
Nov 19, 1999 because you can have two copies of the server running in
the same host with same IP Address, differing only in the
Port Number.
Thanks to Joe Faska, Depository Trust, USA.
Change 17.313 Tests for STC11CI, STC11CE, and STC11TOL should have been
VMACSTC IF STC11xx='.......1.B THEN DO .... instead of ='01'.
Nov 17, 1999 Variables were blank without this change.
Thanks to Herb Strazinski,
Change 17.312 The _KSU70PR "Keep/Drop" macro was not referenced in the
ASUM70PR building of ASUM70PR dataset, so variables could not be
Nov 17, 1999 dropped. The token _KSU70PR was added inside the parens.
Thanks to Gary Morris, Centre Link, AUSTRALIA.
Change 17.311 If you had an old IMACPDB from before MXG 16.04, you can
SPUNJOBS get and error DATASET CONDCODE NOT FOUND. Removing your
Nov 12, 1999 old IMACPDB and instead using the new %LET ADDnn= macro
variables will correct the error, but this change also
protects by using the same logic in BUILD005 to create a
zero obs CONDCODE dataset.
Thanks to Rudolf Werner, Audi Ag, GERMANY.
Change 17.310 Input statement #25 (STIVSR36-STIVSR44) should have been
VMACCADM #25 (STIVSR37-STIVSR44).
Nov 12, 1999
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.309 The remaining subtypes of CA-VIEW Metrics have now been
VMACSARR validated and corrected. Segment tests were change to
Nov 12, 1999 IF SV31xOF+SV31xLN-1 LE LENGTH AND SV30xLN GE 1 THEN DO;
and the input of SV30IVAL now uses SV30IVLN vice SV30INLN
to eliminate INPUT STATEMENT EXCEEDED on some subtypes.
Thanks to Bruce Sloss, PNC Bank, USA.
======Changes thru 17.308 were in MXG 17.08 dated Nov 12, 1999======
Change 17.308 Support for the SQL*NET Network Information Vector, added
VMACORAC to the Oracle user SMF record. New variables IPADDR and
Nov 12, 1999 PORTNR for TCP/IP connnections or NIVNETNM and NIVLUNAME
for SNA connnections are created and kept.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
Change 17.307 Support for APAR OW41147 to recognize ORGEXPDT=0099999 as
VMACDCOL a "valid" migration date when creating variables DCDEXPDT
Nov 12, 1999 and UMEXPDT. This change (insert before ORGEXPDT=9999999
in two places the line ORGEXPDT=99999 OR ) corrects
SAS dates to be "MXG infinite" date in 2099 instead of to
be missing in DCDEXPDT or UMEXPDT. However, the variable
ORGEXPDT is unchanged, so you can use your current MXG to
examine your DCOLLECT datasets DCOLDSET and DCOLMIGS, and
if you have any datasets with ORGEXPDT=99999, then you
MUST either install that APAR or follow its instructions
to prevent unexpected loss of any SMS dataset with its
ORGEXPDT=99000 on Jan 1, 2000. What is critical is that
you read the APAR and see if it has impact on our site.
This MXG change is not required for year 2000 support in
MXG Software.
Change 17.306 Support for CA VIEW Metrics report program SARSMFUX SMF
EXSARR20 records create seven datasets:
EXSARR21 Dataset Label
EXSARR30 SARRU20 User Logon
EXSARR31 SARRU21 User Logoff
EXSARR32 SARRU30 Report was viewed
EXSARR33 SARRU31 Report was reprinted
EXSARR34 SARRU32 Report was loaded to database
TYPESARR SARRU33 Report was deleted
TYPSSARR SARR&34 Report was deleted from disk
VMACSARR
Nov 11, 1999
Thanks to Bruce Sloos, PNC Bank, USA.
Change 17.305 Support for RACF General Resources Started Task subtype
EXRAC540 540 in RACF Database Unload Utility IRRDBU00 file.
IMACRACF
VMACRACF
Nov 11, 1999
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 17.304 Counts could be negative in TYPE1032 Web Server dataset,
TYPE103 because the accumulated counters are reset each time the
TYPS103 server is "bounced". Now, MXG interleaves the subtype 1
VMAC103 (start) and 2 (interval) records to eliminate negative
Nov 11, 1999 values. Additional protection prevents negative values
if a subtype 2 is read before a subtype 1, or if data
records were lost, for the first subsequent record.
Member TYPE103 or TYPS103 both now invoke the DIFF103
member to sort both TYPE1031 and TYPE1032 datasets.
(So the //PDB ddname is required for TYPE or TYPS103).
Thanks to Joe Faska, Depository Trust, USA.
Change 17.303 IMF DB2 counts are lost in datasets CIMSTRAN and CIMSDB2
VMACCIMS in MVIMF 3.2, because BMC enabled IOWAITS by default,
Nov 11, 1999 which puts some SQLCALLS in a new, undocumented DBORG=00x
Nov 19, 1999 DBD segment, instead of the documented DBORG='80'X DBD.
Sep 15, 2000 IOWAITS is the MVIMF Event Collector DBIO initialization
parameter, and the new 00x segment accounts for sync
point write activity and is also flagged by the
PLANNAME='ALLDBS'. MXG previously only knew about the
80x DBD, so the new 00x segments were decoded incorrectly
and output to the CIMSDBDS instead of CIMSDB2. And while
MVIMF documentation said there would be only one '80'x
segment, logic was added to sum SQLCALLS for these
multiple segments into CIMSTRAN. The drop in SQLCALLS
coincided with installing IMF 3.2.61.
This change was not correct. See Change 18.225.
Thanks to Winfried Waldeyer, BHF Bank, GERMANY.
Change 17.302 Format $MG074PT expected 'F1'X or 'F3'X, but actual data
FORMATS values are '01'X or '03'X, so the format now supports
Nov 11, 1999 both formats, just in case.
Thanks to Alan M. Sherkow, I/S Management Strategies, Ltd., USA.
======Changes thru 17.301 were in MXG 17.08 dated Nov 10, 1999======
Change 17.301 Variable DURATM was not created in PDB.CICS built with
ASUMCICX member ASUMCICX. Insert DURATM=INTERVAL, before the
Nov 10, 1999 INTERVAL=HOUR, macro argument.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.300 If DB2 stays up long enough, and does enough SELECTs, the
ANALDB2R four-byte accumulated counter in the type 100 SMF records
VMACDB2 can wrap, causing MXG to create a negative value when it
Nov 10, 1999 DIF()'d the adjacent observations. Now, each DIF() is
followed by a test for four-byte wrapping of the form:
IF . LT Qxxxxxxx LT 0 THEN Qxxxxxxx=Qxxxxxxx+4294967296;
in member VMACDB2 (the "DIFFDB2" logic was relocated into
the _SDB2xxx sort macros in MXG 16.04 redesign). Also,
several fields in MXG's ANALDB2R reports were not wide
enough for large values, causing SAS to print exponential
notation (valid, but confusing to neophytes), so they are
now expanded along with other minor report revisions.
Thanks to Victor Chacon, Bell Atlantic Mobile, USA.
Change 17.299 MXG Variable CECSER is created by substringing the last
VMAC7072 four nybbles of the three byte CPUSER to get the hardware
Nov 9, 1999 serial number of the "CEC" or "CPC", (i.e., the box), but
Nov 10, 1999 CPU segments have been found with 'E03333'X instead of a
valid CPU Serial Number. These segments are all flagged
for an engine "not online at the end of the interval", or
"came online during the interval", and the CPUSER is not
valid in those instances. So now, MXG sets CECSER only
IF CECSER GT '000000'X AND CAI EQ '......01'B THEN ...
so that only CPUs that were online at the end of the
interval and had not come online during the interval
will be used to set the CECSER. Note, however, that
CPUSERnn (CPUSER stored into a serial number for each
CPU) will still contain whatever CPUSER value was in
its CPU segment if CAI had any bits turned on.
Thanks to Linda S. Berkley, Amdahl, USA.
Change 17.298 Batch Pipes datasets TYPE9112, TYPE9113, and TYPE9115 now
FORMATS contain the Input and Output counts summed from all of
VMAC91 the IEC and OEC connection segments for the End, Close,
Nov 9, 1999 or Delete events, and the Highest Error Code from those
Nov 27, 1999 connection segments. Format $MG091EC was also updated.
Nov 27: additional formats added to $MG091EC.
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.297 Support for unix PerfMeter Freeware Monitor that creates
EXTYPMTR interval resource data on CPU, PKTS, PAGE, SWAP, INTR,
IMACPMTR DISK, CNTXT, LOAD, COLLS, and ERRS rates in new dataset
TYPEPMTR PERFMETR. This monitor is free from Sun MicroSystems,
TYPEPMTR for their unix.
VMACPMTR
VMXGINIT
Nov 8, 1999
Thanks to Michael Lefkofsky, Wayne State University, USA.
Change 17.296 The de-accumulation logic in DIFFTPX caused NOT FOUND as
DIFFTPX was not updated; now it has only _STPXINT invocation, as
Nov 8, 1999 deaccum is now done in the data set sort macro.
Thanks to Mike Shapland, PKS Information Services, Inc.
Change 17.295 The creation of ZDATE in this VMAC member was replaced by
VMACCTLT %%INCLUDE SOURCLIB(IMACZDAT); to be consistent with the
Nov 8, 1999 rest of MXG VMACs. The ommission was an oversight.
Thanks to Steve Clark, California Federal Bank, USA.
Change 17.294 MXG 17.06 added macro _CICXC13 to support excluded fields
IMACEXCL for CICS/TS 1.3, but the "END; /* END CICS TS 1.3 ..."
Nov 8, 1999 line number 547, must be deleted to use the 1.3 Excludes.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.293 TYPEIMSA did not include member IMACKEEP; now it does.
TYPEIMSA This should have been included in Change 17.228 but was
Nov 8, 1999 overlooked.
Thanks to Gilles Fontanini, SAS Institute, FRANCE.
Change 17.292 Variable SMF6DDNM contains hex zeros for DDNAME in some
IMAC6ESS type 6 SMF records (perhaps spin data sets?), but the ESS
VMAC6 segment appears to have the DDNAME in the SWBTU text, so
Nov 5, 1999 this change inputs new variable SMF6TUDD from ESS segment
and stores SMF6TUDD into SMF6DDNM if SMF6DDNM is blank or
nulls. I'm still seeking the DSECTS for the SWBTU, and
the ESS segment itself is incorrectly documented in the
SMF manual and the DSECT, to make sure this is permanent.
Thanks to Hartmut Richter, BASF Computer Services GmbH, GERMANY.
Change 17.291 -Variable PERFINDX in dataset TYPE72GO was non-zero when
EXTY72DL it should have been missing for Service Classes with a
EXTY72GO Percentage goal. MXG calculated PERFINDX even when there
VMAC7072 were no transactions completed in the interval. Now, the
Nov 5, 1999 statement ELSE IF R723CRGF='P' THEN DO; was changed to
read ELSE IF R723CRGF='P' AND TRANS GT 0 THEN DO; so that
PERFINDX will be missing when TRANS=0. Additionally,
PERFINDX was not reinitialized for each Period, and thus
it could have been carried forward as non-zero when it
should have been missing. However, PERFINDX will always
be missing in Reporting Class (RPRTCLAS='Y') observations
and in observations for Service Classes that have System
or Discretionary Goals (R723CRGF='S' or 'D'). PERFINDX
will also be missing if the percent of transactions that
meet the goal falls into the 14th (last) bucket, which
make it impossible to calculate the PERFINDX. On RMF
reports, IBM prints four asterisk for the index; you
can recognize these cases in MXG because R732CRGF='P',
PERFINDX=., but TRANS or TRANSEXC will be non-zero.
-Observations were output in TYPE72GO for Service Classes
that had no resources nor transaction completions. The
variable NOACTVTY was non-zero (indicating activity) when
it should have been zero. Logic in VMAC7072 was revised
so R723RESS (trans states sampled) is no longer included
in NOACTVTY, and VELOCITY and PERFINDX are initialized
for each period (they were propagated into subsequent
periods in the same record that had no activity), and the
logic in EXTY72GO now tests only
IF NOACTVTY GT 0 THEN OUTPUT _WTY72GO;
-Observations were also output in TYPE72DL where there
were no delay samples. Now, EXTY72GO was revised so that
observations are only output in TYPE72DL when R723RESS is
non zero (i.e., there were transaction states sampled).
Thanks to Tan York Sin, Stock Exchange of Singapore, SINGAPORE.
Change 17.290 MXG 17.07 IMS code still had negative RESPNSTM/SERVICETM
ASMIMSLG in 5704 (out of 130000) IMS transactions. Data records
ASMIMSL5 for this (yet another!) unique sequence of IMS log events
ASMIMSL6 plus lots of detailed digging thru mounds of data allowed
JCLIMSLG Carl to enhance MXG for these new IMS idiosyncrasies:
JCLIMSL5 1. TYPEIMSA corrected 5411 of the negative cases, which
JCLIMSL6 included all of the negative RESPNSTM values. Logic
TYPEIMSA added protects when ENDTIME is less than GUTIME. This
Nov 10, 1999 left 293 transactions with negative SERVICTM.
2. ASMIMSLx assembly program revision protects cases when
IMS rerouting exits change destinations causing the
IMS communications manager to do the get unique of a
message that was originally destined to an SMB. The
change sets MTYPE='PTOT' for messages GU'd by comm.
So you must re-assemble the ASMIMSLG/L5/L6 program for
your version of IMS to correct this problem, which
corrected 291 cases of negative SERVICETM.
3. TYPEIMSA corrected the remaining two cases of negative
SERVICETM was to change the reset of STRTTIME=GUTIME
for all transactions, to use that reset only for MTYPE
starts with T, and otherwise reset STRTTIME=ENQTIME
for cases such as MTYPE='PTOT' in which the GU happens
ascynchronous to the end of the transaction.
4. The SORT statement in STEP02 of the JCL examples needs
to be changed. The "35,8" entry, for the message
arrival time, is changed to "43,8" so that the enq
timestamp is used to force the records in absolute
order (because the arrival timestamp can be zero, as
for 03 output record messages for PTOT transactions).
In summary, you need to reassemble ASMIMSLx, use the new
TYPEIMSA, and change the SORT parameter in your JCL.
The cause of the 291 negatives is documented in IBM APAR
PQ01976; they result when the site uses the IMS Input
Message Routing Exit, DFSNPRT0, to reroute a message that
was originally destined to an SMB instead to a CNT. In
this case, a multisegment IMS log 03 record has MSGDFLG2
indicating a program-to-program message switch ('81'X),
but the Exit changed the destination from another SMB to
the CNT of an IBM 3614 cash dispensing ATM terminal, so
the message is picked up by the IMS communications
manager instead of by DLI, so the get unique from the
message queue for that message is represented by a type
31 record that has a QLGUFLGS ('A0'X), indicating it's
pretty much just a normal output message, but the
resultant mismatch in log coding created a transaction
record with negative value for SERVICTM variables in
IMSTRAN. The PTF associated with IBM APAR PQ01976 does
NOT correct the log records; it only prevented IBM's
merge utility DFSLTMG0 from ABENDing (as it did when it
first saw this sequence of IMS log records!).
Thanks to Carl Meredith, SAS Institute ITSV Development, USA.
Change 17.289 Labels for several sets of TYPE71 variables AV/MN/MX
VMAC71 suffixed, now contain "*USED", to clarify which are the
Nov 3, 1999 usage measures and which are capacity measures.
Thanks to Forrest Nielson, State of Utah, USA.
Change 17.288 Variable TOTSHARE was removed from the DROP statement so
ASUM70PR it will be kept, as it may be useful to recalculate the
Nov 3, 1999 original system weights.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.287 Revised Support for SMF Type 90, TYPE90A/VMAC90A should
EXTY9001 be used instead of the old TYPE90/VMAC90 members, which
EXTY9003 will no longer be updated. That old architecture kept
EXTY9004 all variables from subtypes 1-26 in the TYPE90 dataset,
EXTY9005 which not only wastes DASD space, but always requires a
EXTY9006 subset operation to select the observations you want.
EXTY9008 The TYPE90 code was the first written when subtypes were
EXTY9010 added to SMF records, and when there were only a few and
EXTY9011 they were similar in content, it made sense to create one
EXTY9012 TYPE90 dataset, and when new subtypes were added it was
EXTY9014 easier to add variables to an existing data set than to
EXTY9016 create a new data set, but now with 31 often-dissimilar
EXTY9017 subtypes, this "redesign with hindsight" is the righteous
EXTY9018 way it should have been done in the first place, as it
EXTY9019 creates 26 separate datasets, TYPE9001-TYPE9031, one for
EXTY90.. each of the operator commmand events, with only variables
EXTY90.. from that event kept in that TYPE90nn dataset. There was
EXTY9030 no complaint with the old design, since everything that
EXTY9031 was supported was in the old TYPE90 dataset, but the need
IMAC90A to support the new subtypes (27 and above, plus some that
TYPE90A per previously missed) motivated the redesing. Now all
TYPS90A subtypes are decoded, except for data segments of subtype
VMAC90A 24 and 31 (no request, no test data, complicated, shelve
Nov 3, 1999 until someone want's to us them).
Thanks to Philip Foster, Desjardins, CANADA.
Change 17.286 MXG Support for FICON Channels was wrong. Variables
VMAC73 PCHANBY/PNCHANBY were incorrectly calculated for FICON,
Nov 2, 1999 and Percent Bus Busy, PBUSBY was not even created, and
variables SMF73PRU/PWU/TRU/TWU are recalculated to now
contain read/write lpar/total rates in bytes per second,
formatted with MGBYTRT to print KB/Sec, MB/Sec, etc, to
match IBM RMF reports, now that I have test data and RMF
reports for validation!
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Change 17.285 New NPM 2.4 field LSCDIPNM (IP Name) was input for all
VMAC28 records but is valid only if resource type is 'IP', so
Nov 1, 1999 that field will now be blank if not an 'IP' record.
Variable LSCDUSER is blank if LENCOF is 112, which is the
documented length for VM Session Configuration (SMF28SCD)
records, and other LSCDxxxx fields are only input if the
record is for Session Managers.
Thanks to Robert A. Brown, Arthur Andersen, USA.
Change 17.284 Support for TRMS Version 51A08 changes (COMPATIBLE) to
EXTRMS05 their user SMF record. New fields were added to subtype
VMACTRMS 3 and 4 datasets TMRS03 and TMRS04, and new subtype 5
VMXGINIT record creates new dataset TMRS05, 'Browse Tracking'.
Oct 28, 1999 The S0nACCT character variables are now formatted as
$HEX64, because the contain non-printable characters.
The length of new fields S05KEY is not defined in the
dsect, but was found to be 14 bytes in this site's data
record. It's length, T00KLEN is set somewhere else and
could be different; we're investigating.
Thanks to Carol King-Baer, Vanderbuilt University, USA.
Change 17.283 Format $MG091EC now decodes Batch Pipes error codes in
FORMATS variables SMF91IEC and SMF91OEC.
VMAC91
Oct 28, 1999
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.282 Protection for bad type 80 record was not robust if MXG
VMAC80A got out of alignment and thought it had a bad record; it
Oct 27, 1999 could STOPOVER abend instead of gracefully deleting that
bad record, but protection logic from WHEN (00) was also
added in OTHERWISE DO; logic to eliminate the abend.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 17.281 Support for DFSMS/MVS V1R5 is already in place, as there
VMACDCOL were no changes in the DCOLLECT records in 1.5.
Oct 26, 1999
Change 17.280 Support for Landmark DB2 Monitor Version 3.2 (INCOMPAT).
EXTMDD7 Many new variables were added to existing MXG datasets
EXTMDD7B TMDBDB, TMDBDA2, TMDBDAB, TMDBDBB, TMDBDBF, TMDBDBK and
EXTMDD7P TMDBDE2, and TMDBD6, and the new 'D7' record creates new
VMACTMDB TMDBD7, TMDBD7B, and TMDBD7P datasets. This version has
VMXGINIT lots of new stuff, including pairs of duration/counts of
Oct 26, 1999 many waiting-for-something's. Since Landmark inserted
new fields instead of adding at the end, you must install
the change to process Version 3.2 or higher data. Using
an earlier MXG version for TMDB Version 3.2 records will
cause the job to fail with many errors!
Thanks to John Enevoldson, Ellos AB, SWEDEN.
Change 17.279 CICS Statistics "EOD" records do not contain a duration,
UCICSCNT even though the "EOD" records is just the Interval Record
VMAC110 since the last "INT" record. (The "EOD" is written at EOD
Oct 24, 1999 but DOES NOT contain the entire day's data!). With no
Oct 27, 1999 DURATM, MXG sets STARTIME=COLLTIME (SMFTIME), so while
all of the obs are really there in the MXG data set, it
looks like the 9pm interval was missed with STARTIME:
STARTIME COLLTIME SMFSTRQT
31OCT:15:00 31OCT:18:00 INT
31OCT:18:00 31OCT:21:00 INT
1NOV:00:00 1NOV:00:00 EOD
1NOV:00:00 1NOV:03:00 INT
While STARTIME is wrongly equal to COLLTIME in the "EOD"
interval record in CICxxxxx Statistics datasets built by
the TYPE110/BUILDPDB programs, STARTIME is set correctly
in the PDB.CICINTRV dataset that is created from nineteen
of the "raw" CICS Stat datasets by the member CICINTRV:
-It constructs true intervals from INT/EOD/USS/REQ/RRQ
records, some of which are intervals and some of which
are accumulated, and by sorting and merging, it creates
the correct STARTIME of each interval.
-Fifteen CICS statistics datasets that are used in the
creation of PDB.CICINTRV are created one-per-interval,
so they are merged into PDB.CICINTRV with no loss of
detail; thus there should be no need to use these "raw"
CICxxx datasets with wrong STARTIME in their EOD record
because they are redundant with PDB.CICINTRV:
CICAUTO CICDMG CICDQG CICDS CICDTB CICLDG
CICM CICSDG CICST CICTC CICTDG CICTM
CICTSQ CICVT CICXMR
-Four CICS statistics datasets used in the creation of
PDB.CICINTRV have multiple observations per interval
CICDQR CICFCR CICTCR CICTSR
(i.e., CICFCR has an observation for each File). Some
useful counters are summed per interval and merged in
PDB.CICINTRV, but detail observations are likely needed
to be kept in your PDB, and you will have to live with
the incorrect STARTIME in the EOD obs.
So why not fix IBM's ommission (which was designed this
way and not likely to change)? Because the only way to
correct it would be to add a PROC SORT and DATA step for
each stat dataset to re-construct the correct STARTIME,
and that seems an unnecessary expense at this time.
However, the architecture of each _Sdddddd macro would
make this possible, so if this remains a problem for you,
let's discuss this as a future enhancement.
The initial "Missing 9pm Interval" report was thought to
be a real data loss, but that possibility was eliminated
when there were no messages that CICS had suspended write
to SMF. But to re-document what might happen:
When CICS cannot send data to the SMF address space, you
get "DFHMN0101 CICS COPYNAME SMF RC '0028'X" or
"DFHST0103 CICS COPYNAME SMF RC '0028'X" messages
on both SYSLOG and the JOBLOG of that CICS region. The
MN message says CICSTRAN (subtype 1) records were lost,
the ST message is for Statistics (subtype 2) records.
This happens briefly when SMF Buffers are being expanded
or when SMF SWITCH occurs (because both are serialized
functions under the single SMF TCB). By scheduling the
SMF dump/SWITCH away from the interval pop, its impact
may be eliminated. By increasing the size of your SMF
buffers with APAR OW12836 (increases minimum from 1MB
to 8MB, which might eliminate the need for expansion;
increases the maximum from 32MB to 128MB; and increases
each increment from 1MB to 8MB so there are fewer buffer
expansions and fewer exposures to data loss) you may be
lucky and avoid the problem, until IBM responds to the
SHARE requirement to fix this design!
The only code change was an enhancement to the UCICSCNT
program that counts CICS records by APPLID and type; a
new reports details Statistics counts by STID and record
so I could tell if stat data really was lost!
Thanks to David Lyle, Total System Services, USA.
Change 17.278 Support for APAR OW40570/OW41407 for SMF 42 Subtype 4
VMAC42 adds S42CVLUX to contain the 4-digit UCB address in MXG
Oct 22, 1999 dataset TYPE42CV. The existing 3-digit S42CVLUA variable
contains 'UCB' for any 4-digit UCB address!
Change 17.277 Documentation only, no code was changed. TYPE94 data
VMAC94 fields VMV/VPS/VPM/VPR/VMP/VBW/VBR/VTW/VTR will be zero,
Oct 22, 1999 and fields VBA/VEC/VLA/VNM/VCA/VCZ will stop accumulate,
if the screen on the PC that is attached to the VTS/ATL
and that is collecting those physical back end activity
counters is minimized! Discussions with IBM in progress.
Change 17.276 New Format $MGTCPFM decodes the FTPDATFM data format
FORMATS variable (ASCII/EBCDIC/IMAGE/DOUBLE-BYTE/UCS-2) values.
VMACTCP Variable FTPDSNA2 is no longer kept in TYPETCPC dataset
Oct 22, 1999 (FTP Client), as that field exists only in TYPETCPF
(FTP Server), and was filled with hex trash.
Thanks to Jason Cooley, CITICORP, USA.
Change 17.275 Reading type 39 SMF records directly from VSAM SMF file
VMAC39 failed because the calculation of offset for two optional
Oct 21, 1999 triplets did not include (+OFFSMF).
Thanks to Bruce Hudson, Payless Cashways, USA.
Change 17.274 The symbolic &TAILOR and its //TAILOR DD were removed
JCLTEST6 from the MXGSAS example JCL procedure, because in a few
MXGSAS sites either SAS 180 errors or USER ABEND 2415 occurred
Oct 20, 1999 due to (strange?) problems, and so I've decided that the
optional tailoring library is more pain than value, as
no one really used it anyhow!
Thanks to Richard Phelps, Arizona State University, USA.
Change 17.273 The estimated length of tape, DSNBFEET and TAPEFEET, was
TYPETMS5 non-zero when BLKSIZE=0 because the two calculations in
Oct 20, 1999 TYPETMS5 did not match the logic in VMACTMS5, so tests
for BLKCNT GT 0 and BLKSIZE GT 0 AND RECFM conditions
in VMACTMS5 were added to calculations in TYPETMS5.
Thanks to Pat Moffett, CMX Group, USA.
Thanks to Patsy Hildreth, CMX Group, USA.
Change 17.272 Calculation of variable OVRSPPC6 incorrectly used the
VMACNSPY 3270 buckets instead of the LU6.2 buckets. It should be:
Oct 20, 1999 OVRSPPC6=100-T1RSPPC6-T2RSPPC6-T3RSPPC6-T4RSPP6;
Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
Change 17.271 This utility was developed to show you how your IMACWORK
UTILRMFI definitions cluster PERFGRP or SRVCLASS into the workload
Oct 18, 1999 variables in RMFINTRV dataset. It shows where the type72
CPU times came from, using your IMACWORK, and it also
reads type 30s to show SRVCLASS/RPTCLASS/JOB CPU times.
The utility is needed when your RMFINTRV execution prints
error messages that your workload definition CPU time
does not match the true CPU time in SRVCLASS/PERFGRPS.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.270 Support for APAR PQ28258 for the SMF type 103 record that
VMAC103 was created by Internet Connection Secure Server (R3,R2)
Oct 18, 1999 and then by Lotus Domino Go Webserver for OS/390 (R4-R6),
May 31, 2000 now named WebSphere Application Server OS/390 (R7-R8),
(and now May, 2000 sub-titled HTTP Server Version 5.2),
adds many new statistics, including five sets of avg/min
max response times for DNS, Plugins, CGI, SSL, & Proxy,
to subtype=2 record in dataset TYPE1032.
Change 17.269 Long ago, when I observed that the total device pending
VMAC74 time (PCTDVPND) was more than the sum of its two parts,
Oct 18, 1999 Pend for Device (PCTPNDEV) plus Pend for CU (PCTPNCUB),
Dec 16, 1999 I stored the difference as the Pend for Chan (PCTPNCHA).
But when IBM added Pend for Director Port (PCTPNDIR), I
did not treat that as a component of PCTPNCHA, and now I
measure there still is a difference between the Total and
its components, so I now:
- Store Pend Dir Port into PCTPNCHA/DLYCHATM variables
and changed their labels to be Chan Dir Port delay
- Calculate the Other Pending PCTPNOTH/DLYOTHTM as
PCTPNOTH = PCTDVPND - (PCTPNDEV+PCTPNCUB+ PCTPNDIR)
Other Pend = Total - (Device + CU + Dir Port)
Independent of this change, type 74 data records with
Total Pend Time (SMF70PND) of 28 seconds but Pending for
Device component (SMF70DVB) was 37 seconds are written
occasionally for devices simulated in an EMC box. The
error causes PCTPNOTH to be negative (and, before this
change, PCTPNCHA was also negative because it used to
be the same as PCTPNOTH). We have also seen similar, but
much smaller differences, for tape devices.
Thanks to Robert Girard, EMC, USA.
Change 17.268 Variables UBCOMPR UBUSRSIZ UBCMPSIZ were INPUT but were
VMACDCOL not in the KEEP= list for dataset DCOLBKUP. Now they are.
Oct 18, 1999
Thanks to Alastair Gray, Philip Morris EDC, SWITZERLAND.
Change 17.267 The VTS report program was corrected; while its example
ANAL94 in comments worked fine, invoking %ANAL94(PDB=SMF); to
Oct 13, 1999 read SMF to produce reports did not produce! Parameter
REPORT=HOURLY is now the default, so that a report will
now always be produced, plus other cleanup.
Change 17.266 The "GT" was changed to "GE" so all lines now read
VMACHARB IF HH GE 0 AND MM GE 0 AND SS GE 0 THEN ....
Oct 11, 1999 because the "GT" caused some missing timestamps.
Nine flags, AXR0nFL1, are now formatted $HEX2.
Thanks to Patsy Hildreth, CMX Group, USA.
Change 17.265 The VMXGSUM error in Change 17.264 is corrected, by
VMXGSUM relocating the ALLVARS initialization higher up in the
Oct 11, 1999 logic; it was bypassed when INCODE= was not used, and
was blank when it should have had a list of variables.
When &ALLVARS was blank, VMXGSUM generated code was
PROC MEANS; VAR ; OUTPUT OUT=X SUM(A B C);
(i.e., a VARIABLES statement with no variables).
This PROC MEANS failed "NO ANALYSIS VARIABLES" with
SAS V6, but under SAS Version 8, it ran just fine!
Exactly why is under investigation; but I think it is
enhancements SAS made under SAS V8: in this specific
PROC MEANS invocation, a VAR statement is not needed
because the SUM(A,B,C) syntax provides the names, so
SAS V8 ignored the unneeded VAR statement?
In any event, VMXGSUM now always populates ALLVAR with
the list of variables so it won't be blank.
======Changes thru 17.264 were in MXG 17.07 dated Oct 8, 1999======
Change 17.264 The VMXGSUM of Change 17.255 was never put in MXG 17.07,
VMXGSUM because it was not correct. MXG QA under SAS V8 had no
XMXGSUM errors, so 17.07 was built, but final QA with SAS V6
Oct 8, 1999 found errors in VMXGSUM that were not caught by V8, so I
removed VMXGSUM for the MXG 17.07. Note that 17.255 was
reinstated by Change 17.265 in MXG 17.08.
Change 17.263 Support for Domino Server SMF type 108 record creates
EXTY1081 three new datasets from subtype 1 interval records:
EXTY108P Dataset Description
EXTY108T TYPE1081 Server Statistics
IMAC108 TYPE108P Port Statistics
TYPE108 TYPE108T Transaction Statistics
TYPS108 Additional development work is ongoing by IBM so you can
VMAC108 anticipate additional measurements for Domino soon.
Oct 8, 1999 Domino Release R5.0 & R5.01 are supported by this change.
The type 108 record originated with Lotus Notes Domino
Server, and was primarily a mail server for Lotus Notes,
but now the Lotus Domino Server provides services for
Notes, and contains its own HTTP server & JAVA function.
Note that the Websphere Application Server HTTP Server
is the product that creates the SMF 103 record.
Thanks to John Milne, Suncorp Metway, AUSTRALIA.
Change 17.262 Revisions in DAILYDSN to use TYPSDCOL instead of TYPEDCOL
DAILYDSN (so the PROC SORT and NODUP logic would be taken from the
Oct 8, 1999 VMACDCOL instead of being coded in DAILYDSN) wrote the
output to the //PDB instead of the expected //DATASETS.
By inserting %VMXGINIT(DEFAULT=DATASETS); before the
include of TYPSDCOL, the default PDB becomes DATASETS and
DAILYDSN now works as it did previously.
Thanks to Craig Gifford, City of Lincoln, USA.
======Changes thru 17.261 were in MXG 17.07 dated Oct 7, 1999======
Change 17.261 Unexpected Expiration date of 2099366 (also invalid, as
VMACDCOL 2099 is not a leap year) was found, and caused missing
Oct 7, 1999 value for DCDEXPDT/UMEXPDT. The logic was revised to add
test (YREXPDT=199 AND DAYEXPDT GE 365) OR in two places
so that the '31DEC2099' infinite MXG date is stored in
DCDEXPDT or UMEXPDT.
Thanks to Jens Mohring, HUK Coburg, GERMANY.
Thanks to Harald Seifert, HUK Coburg, GERMANY.
Change 17.260 NTSMF SQLServer Objects Cache Manager, Databases, Locks,
VMACNTSM and User Settable were corrected (NRNAMES and/or NRDATA,
Oct 5, 1999 and NRNAMES=NRNAMES-1 was added) and validated with data.
Thanks to Leigh Ann Payne, Wachovia Operational Services, USA.
Change 17.259 Landmark PTF TD01655 for TMON Version 2 added fields
VMACTMV2 COMPATIBLY to the CI and JD records:
Oct 5, 1999 -Variables CICSALUB,CIECSLUB added to TMVSCI dataset.
-Variables (enclave CPU times)
JDDECPU JDENCSU JDENCTR1 JDENCTR2 JDIECPU JDJDECPU
JDJENCSU JDJIECPU JDSDECPU JDSENCSU JDSIECPU JDSWPRSN
were added to TMVSJD dataset.
-Variables
JDOPRID JDOSTCK
were added to TMVSJDOM dataset.
Thanks to ???, IDUNA NOVA, ITALY.
Change 17.258 The trending of ASUMUOW into TRNDUOW failed with error
TRNDUOW TREND.TRNDUOW.DATA DOES NOT EXIST because the statement
Oct 4, 1999 OPTIONS NODSNFERR; should have been at the start of the
TRNDUOW member. "No DSN Not Found" option protects the
first-time execution of TRND members, but was left out of
the TRNDUOW member.
Thanks to Tom Marchant, Wayne State University, USA.
Change 17.257 Variable SMF26WIN, a bit map, is now formatted $HEX2.
VMAC26J2
Oct 4, 1999
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.256 This revision, used by UTILGETM, allows you to read an
VMXGGETM SMF file and report on the contents by type, subtype, and
Oct 4, 1999 system, using PROC TABULATE. If you specify SMFOUT= a
null string, and specify FREQ=YES, the report is created.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.255 This revision adds new statistics (notably percentiles)
VMXGSUM in VMXGSUM output, and detects execution under SAS V7/V8
Oct 6, 1999 so that the new INHERIT parameter in PROC MEANS can be
used, which may eliminate the need for the final datastep
(previously required to reset variable lengths).
Thanks to Chuck Hopf, MBNA, USA.
Change 17.254 A number of new timestamp fields from DB2 and CICS were
IMACNORM added to the PDB.ASUMOW dataset. In addition, new member
ASUMUOW IMACNORM is added to permit you to normalize the CPU time
Oct 3, 1999 created in the PDB.ASUMUOW dataset, in case you have CICS
Regions and/or DB2 Subsystems executing in machines of
different speeds. IMACNORM is preliminary, and may be
changed in the future, but it has no impact unless you
change it, as IMACNORM now only contains commments.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.253 -MXG options SASCHRLN is implemented to save space in some
VMAC102 DB2 trace records that contain variable length text. See
Oct 3, 1999 Change 17.251 text. Both COMPRESS=YES and execution with
SAS V7, V8, or later is required.
-For trace subtypes 206, 208, and 236, if the message text
was greater than 200 bytes, the first 200 bytes were not
input, but now are. The first INPUT of QW0207HR was
removed, as the second one, inside the test for length,
was the correct one.
See minor revision in Change 17.390.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.252 This analysis of all SAS dates in all SAS datasets that
ANALDATE was added by Change 17.168 now works; the debugging lines
Oct 3, 1999 302 and 303 are now removed, and line 10 now has an
ending */.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 17.251 If SAS options USER= or WORK= were specified, the output
VMXGINIT of an MXG %INCLUDE SOURCLIB(TYPExxxx); program always
Oct 2, 1999 went to //WORK, but with this change, the WORK= or USER=
destination will be honored.
Apr 5, 2000: The USER= or WORK= options must be specified
on // EXEC SAS or on the SAS command; they are resolved
when VMXGINIT executes at MXG startup, and cannot be
changed later with an OPTIONS statement.
-A new macro variable, SASCHRLN, is set to 32000 if SAS V7
or V8 is executed AND if COMPRESS=YES is turned on, but
SASCHRLN=200 for V6 (and for V7, V8 with COMPRESS=NO).
This macro may be used to set the length of character
variables in some specific cases:
With the SAS character variable limit of 200 bytes, MXG
datasets with long text strings (SQL text in DB2 trace
averages 2000 bytes per statement) are output into many
observations for each 200 bytes of text (and the fixed
fields are many hundred repeated bytes!). Instead, now
that variables can be 32000 bytes long, only one output
observation is needed, and by using compression, only
the actual data has to be stored, so the unused length
won't actually take up any space, and you can get the
effect if variable length text storage in SAS!
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Change 17.250 Member VMXGINIT creates macro variable MXGVERS, the MXG
VMXGINIT Version Number that is printed in MXG messages and kept
Oct 4, 1999 in dataset TYPE70. The MXGVERS value was kept in member
VMXGINIT, but its value is now read from member AAAAAAAA
used because it has always had the version and because
it is never modified by user tailoring), so that now I
can email you a change that includes an altered VMXGINIT
member (two new macro variables are defined there for a
new MXG dataset), but the MXG Version will be unchanged.
Only when you install the full new MXG Version will the
new number be seen. This had not caused any error nor
had anyone noticed, but this seems more righteous.
Change 17.249 New FORMAT MGKILO is created to print five-position
FORMATS values with K/M/G/T/P suffix for Kilo/Mega/Giga factors
Oct 2, 1999 (not 1024 byte-factors, but 1000 kilo-factors) for pretty
printing of data with wide range of values compactly. It
is not used in MXG Software, and will not replace MGBYTES
format for true "mega-bytes" values, but if your manager
demands that you use "million-byte" values to match the
lies from your DASD vendor, you can use MGKILO in your
reports to satisfy him/her, but I suggest you create a
second variable and format it MGKILO and print both the
MGBYTES and MGKILO values side-by-side, and use a LABEL
to clearly identify which is which!
Thanks to Alan Phelan, PKS Systems, USA.
Change 17.248 Support for MQ Series Version 2.1 (COMPATIBLE) type 115
VMAC115 SMF records adds new variables QISTMGET/QISTMPUT to the
Oct 2, 1999 MQMMSGDM MQ Message Data Manager dataset. Previously
reserved fields were used for the new data.
Thanks to MP Welch, SPRINT, USA.
Change 17.247 A new exit member, EX80ASEG, for type 80 SMF records
EX80ASEG (RACF or TOP SECRET) is added so that installation-unique
VMAC80A RACFTYPE segments can be decoded external to the VMAC80A.
Oct 2, 1999 Old-style macro _E80ASEG is defined so MACKEEP= logic can
be used as an alternative to EDITing EX80ASEG.
Thanks to Marc Matthys, Hudson Williams Europe, BELGIUM.
Change 17.246 The subtype 3 TELEVIEW SMF record has four extra bytes
VMACTELE inserted before the startup/shutdown times in the 4.3B
Oct 2, 1999 release that is now supported. An additional internal
TeleView error in the USERID field is corrected by their
fix T19C017.
Thanks to Tom Parquette, MONY Life Insurance Company, USA.
Change 17.245 MXG 17.06 only. Change 17.213 typo caused VTS variables
VMAC94 to have zero values, and ERROR.VMAC94.AUDITLEN INVALID
Oct 1, 1999 messages printed. The line added by that change:
IF SMF94XOF+SMF94VLN*SMF94XON-1 GT LENGTH THEN DO;
should have been
IF SMF94XOF+SMF94XLN*SMF94XON-1 GT LENGTH THEN DO;
(and the SMF94VLN= in the following PUT statement should
also have been SMF94XLN=).
Thanks to Robert Carballo, WORLDSPAN, L.P. USA.
Change 17.244 DCOLLECT variables DCACISZ and DCACACIC were missing,
VMACDCOL because the test before the INPUT of DCAHURBC should have
Oct 1, 1999 been GE 16 instead of GE 32, and the +16 after the INPUT
of DCAHARBC should have been deleted.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to Stewart Spyker, FISERV, USA.
Change 17.243 The _BTY91xx By List macros and _STY91xx Sort macros are
ANAL91 populated and will eliminate duplicate Batch Pipes SMF
FORMATS records. The label for SMF91OW as changed from EMPTY to
VMAC91 FULL, format $MG091XW was updated, and the new ANAL91
Oct 3, 1999 was intended to summarize TYPE91IC/TYPE91OC data to look
for lost data as described in APAR PQ25641. However, as
SMF91IEC/SMF91OEC are almost always zero (7 nonzero in
33,609 TYPE91IC obs, 3 nonzero in 23,570 TYPE91OC obs),
ANAL91 is not much use (yet) in detecting that data loss.
Also, type 91 is incomplete. These pipe criteria values
(ALLOCSYNC,ALLOCNOW,FIT/FITDD,OPENSYNC,NOEOF,EOFREQUIRED,
ERC,CLOSESYNC,TERMSYNC) are not reported in type 91s, nor
are replacement values for WAITALLOC,WAITOPEN,IDLE,WAIT,
WAITEOF,WAITCLOSE or WAITTERM reported when one of those
values is overriden for a specific pipe connection. And
the STEPNAME in TYPE91IC/TYPE91OC still does not match
the SMF 30 record's STEPNAME for same job/step number!
A new APAR PW31018 will correct some documentation for
type 91 records, but a new ETR is still open on counts.
Thanks to Michael Oujesky, MBNA Hallmark Information Services, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.242 If you ran ASUMTALO against a months input, and you had
ASUMTALO one system whose last TYPETALO timestamp was on Aug 5th,
Oct 1, 1999 (either that system went away, or the MXGTMNT monitor
program that writes the SMF records was STOPped, or
MXGTMNT was no longer automatically started at IPL, or
MXGTMNT had shut itself down with an MXGTMNT message on
SYSLOG, etc.) then PDB.ASUMTALO output had data only thru
Aug 5, because the MXG SPIN logic in ASUMTALO put all of
the TALO records for Aug 6-31 into the spin library!
The SPIN logic in ASUMTALO uses the TMNTTYPE=5 Hourly
Interval records (created just for this logic so that
active allocations can be included) in TYPETALO input
to get the timestamp of the last-complete-interval on
each SYSTEM, and uses the minimum last-interval time
across all SYSTEMs as the spin criteria: TYPETALO obs
with timestamps greater than that criteria (both the
TMNTTYPE=5 hourly and the TMNTTYPE=4 end-of-allocation
event) go to SPIN.SPINTALO for tomorrow's ASUMTALO,
because only records up thru the last complete interval
from ALL systems can be used to count tape allocations
when tape drives can be shared across systems.
This SPIN logic works fine when you run ASUMTALO daily,
(ASUMTALO is invoked by BUILDPDB), although if the last
TYPETALO timestamp for one system is at 9:00am THU, the
PDB.ASUMTALO built early Friday will contain data only
up to 9:00am THU, but then the next day's PDB.ASUMTALO
will have picked up the spun records, so PDB.ASUMTALO
built early Saturday will contain 9:00am THU thru FRI
end of day, so no data is really lost, but at most is
delayed one day.
But to support processing of multiple day's TYPETALO data,
the ASUMTALO spin logic now calculates the delta between
the minimums of each system last-complete-interval, and if
there is more than 24 hours difference between systems,
that execution of ASUMTALO will suspend the SPIN logic and
will output all TYPETALO events in the input data.
If you have missing data in PDB.ASUMTALO datasets that
were created from multiple day's TYPETALO, you can delete
the subtype 5 interval records and recreate ASUMTALO with:
//PDB DD DSN=PDB.TO.BE.REPAIRED,DISP=OLD
DATA PDB.TYPETALO;
SET PDB.TYPETALO;
IF TYPETMNT=5 THEN DELETE;
%INCLUDE SOURCLIB(ASUMTALO);
Deleting the subtype 5 interval records eliminates SPIN
logic in ASUMTALO, so all dates will be output into the
replacement PDB. The tail-end intervals will be missing
in-flight tape allocations, but the real data will be
correct. Note that if your PDB.ASUMTALO dataset is on
tape, you cannot directly replace it, and would have to:
//REALPDB DD DSN=REAL.PDB.ON.TAPE,DISP=OLD
//TAPECOPY DD DSN=TEMPTAPE,DISP=(,DELETE,CATLG),UNIT=TAPE
//PDB DD DSN=&&TEMPPDB,DISP=(,DELETE),UNIT=SYSDA,
// SPACE=(CYL,(100,100))
DATA PDB.TYPETALO;
SET REALPDB.TYPETALO;
IF TYPETMNT=5 THEN DELETE;
%INCLUDE SOURCLIB(ASUMTALO);
PROC COPY INDD=REALPDB OUTDD=TAPECOPY;
EXCLUDE ASUMTALO;
PROC DELETE DATA=REALPDB._ALL_;
PROC COPY INDD=TAPECOPY OUTDD=REALPDB;
PROC COPY INDD=PDB OUTDD=REALPDB;
SELECT ASUMTALO;
Thanks to Jonathan A. McVey, Lowe's Companie, Inc, USA.
Thanks to David Zeems, Bank of America, USA.
Change 17.241 The Tandem Utility to read "Unstructured" records was
UTANDSTR re-commented and set up to convert the five Measure files
VMACTAND that MXG supports, and the table of LRECLs for both the
Sep 30, 1999 "Normal" and "Unstructured" tandem records in VMACTAND
was updated.
Change 17.240 The addition of dataset TYPE30TD by Change 17.111 was not
ANALDSET nulled out in ANALDSET, causing ERROR 455-185. New lines
Sep 29, 1999 XY ADD NAME=EXTY30TD
/* override and output no type30td records */
were added to STEPONE.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.239 Variable ENDDTE was not converted back into a SAS date,
VMACXCOM because ENDTIME was created so ENDDTE was redundant, but
Sep 28, 1999 since ENDDTE was also kept, it is now a valid SAS date.
Thanks to Andrew Nyiri, EDS Australia, AUSTRALIA.
Change 17.238 RMFINTRV didn't support non-contiguous shift definitions,
RMFINTRV like a three hour peak-shift that includes 10:00-11:59
Sep 28, 1999 and 14:00-14:59, because some TYPE7xD datasets were not
resorted after the value of STARTIME was changed by the
DURSET macro in member IMACRMFI. Now, all of the TYPE7xD
data sets are sorted BY SYSPLEX SYSTEM STARTIME, so as
long as your shift definition for this peak shift resets
STARTIME to 10:00 as the start of this three hour shift,
all three hours will be summarized as expected.
Thanks to Jim Quigley, Con Edison, USA.
Change 17.237 NETSPY X.25 line stats are in NSPYNPSI dataset instead of
VMACNSPY dataset NSPYLINE (only non-X.25 lines are there), and now
Sep 28, 1999 the line utilization variables SLNU/PLNU are calculated
and kept in NSPYNSPI, for NSPNRECI='04'x (X.25 lines).
Variable NSPX25R is no longer kept in NSPYLINE dataset,
because NSPYLINE contains no X.25 resources and the
existence of that variable was misleading.
Thanks to Sharon Hindle, EDS Australia, AUSTRALIA.
Change 17.236 Invalid user SMF records written with '40'x for record ID
VMAC64 caused TYPE64 code to fail, so protection was added to
Sep 27, 1999 prevent the INPUT EXCEEDED RECORD error. The INPUT is
now conditionally executed:
IF 137+LENEXT+OFFSMF+114 LE LENGTH THEN
INPUT @137+LENEXT+OFFSMF
Thanks to Fred Kaelber, Pacific Bell, USA.
Change 17.235 Support for OS/400 Release 4.4.0 (INCOMPATIBLE due to the
VMACQAPM changes in LRECL of the new records), but if you change
Sep 27, 1999 the LRECLs in your JCL, then MXG 16.02-17.06 "tolerate"
the new records: MXG does not fail, reads all of the
existing fields, but the new fields will not be input
until you install this change, in MXG 17.07 or later).
4.2 4.4
File LRECL LRECL
QAPMBUS 57 111
QAPMDISK 346 352
QAPMECL 276 277
QAPMJOBS 812 819
QAPMLIOP 144 150
QAPMMIOP 232 270
QAPMRESP 58 68
QAPMSYS 3250 3268
-Dataset QAPMCONF now has only one observation, with all
of the Configuration options in that one observation,
instead of a separate observation for each GKEY value.
-Dataset QAPMSYS has three new variables, SYSHEAO, SYHFTH
and SYHFTS.
-Dataset QAPMJOBS has two new variables: JBSVIF JBTFLT.
-Dataset QAPMDISK has one new variable: DSCERC
Change 17.234 Mobius View Direct 6.1.2 (a/k/a INFOPAC) added new field
VMACIPAC for the Caller Type, new variable IPCALLER in dataset
Sep 26, 1999 IPAC03, compatibly.
Thanks to Steve Clark, California Federal Bank, USA.
Change 17.233 TRND70 was enhanced to contain OMVSAVG, OMVSMIN and
TRND70 OMVSMAX to track number of Open Edition users.
Sep 26, 1999
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 17.232 The new PDB.ASUMCEC dataset was created BY SYSPLEX CECSER
ASUM70PR but SYSPLEX should not have been used in the summary (a
Sep 26, 1999 CEC can have LPARs in different SYSPLEXes) and has been
removed. Also, the "PDB" was hardcoded, but it should
have been the "&PDBMXG" macro reference (which defaults
to "PDB" but permits global destination changes by ITSV).
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Thanks to Toby Olberding, Hudson Williams, USA.
Change 17.231 The date variables XPMLKDT and XPMXPDT were formatted as
VMACSFTA DATE9, but they contained Julian dates and had not been
Sep 26, 1999 converted to SAS dates. These lines were inserted after
their input so they will now contain valid SAS dates:
XPMLKDT=DATEJUL(XPMLKDT);
XPMZPDT=DATEJUL(XPMZPDT);
The actual code change was more extensive, as it includes
the Y2K JULDATE algorithm from member YEAR2000.
Thanks to Ove Dall-Hansen, CODAN Insurance A/S, DENMARK.
Change 17.230 MXG constructed variables STC07FPS and STC07TPS did not
VMACSTC match the format printed on the STK Silo LSM Info report
Sep 26, 1999 but once STK Technical Support told me how they drop the
Oct 5, 1999 first nybble and print three character positions with the
last nybble of ACS in one hex and both nybbles of LSM in
two hex positions, both fields now match the STK utility
report format from the STK user SMF record.
However, truncated subtype 1, 4, and 7 records that cause
INPUT RECORD EXCEEDED RECORD LENGTH, STOPOVER abends were
found and are under now protected in VMACSTC.
One circumvention for these short records (prior to
this change) that eliminates the ABEND and lets MXG
read thru all of the SMF data is to use MACRO STOPOVER
MISSOVER % after //SYSIN to change MXG's default of
STOPOVER to MISSOVER.
However, MISSOVER will still OUTPUT each of the bad
records, so the MXG datasets will contain unexpected
missing values, possibly causing your report programs
to die with divide by zero exceptions!
A safer workaround was to delete the short records
in the IMACFILE exit member, using:
IF ID=222 AND SUBTYPE=7 AND LENGTH LT 140 THEN DELETE;
IF ID=222 AND SUBTYPE=4 AND LENGTH LT 552 THEN DELETE;
IF ID=222 AND SUBTYPE=1 AND LENGTH LT 198 THEN DELETE;
Thanks to Jorge Fong, Depository Trust, USA
Thanks to Joe Faska, Depository Trust, USA.
Change 17.229 The EXCLUDE logic for Omegamon for archaic CICS Version 2
IMACEXCL in macro _CICXCOM did not test for SMFPSRVR, so if you
Sep 26, 1999 had both _CICXCOM and _CICXCU4 enabled, the _CICXCOM code
was executed for the 4.1 region, causing INVALID RECORD
DELETED error message and STOPOVER abend. Inserting
IF SMFPSRVR LE 3 THEN DO; ... END;
inside the MACRO _CICXCOM definition in IMACEXCL allows
the old and new version's excludes to coexist.
Thanks to Charles McAfee, Cover-all, CANADA.
Change 17.228 MXG Change 17.172 enhancements to MXG IMS log processing
ASMIMSLG are now implemented as the standard MXG support members.
ASMIMSL5 (Those changes were added in new "X" members for testing
ASMIMSL6 and with no reported errors, they have now become the MXG
EXIMSBMP support for IMS log processing.) In addition, the exit
EXIMSTRN members for the IMSTRAN, IMSBMPS, and IMSFASTP datasets
JCLIMSLG are now used (i.e., the _EIMSxxx macro did not call the
JCLIMSL5 %INCLUDE SOURCLIB(EXIMSxxx); ) so that the MXG exit
JCLIMSL6 facility can be exploited by ITSV.
TYPEIMSA
TYPEIMSB I strongly recommend that you install the new IMS support
VMACIMSA and use it to reassemble the ASMIMSLx member to re-create
Sep 25, 1999 the MXGIMSLn program, which is then used in the JCLIMSLx
JCL example. Using these new members will correct the
SubQ 6 times as well as provide the many enhancements
to IMS log processing described in member ADOCIMXA.
Change 17.227 The SAP IMS log record 'AE'x was NOT Y2K Ready until SAP
VMACIMSA Release 5.0i, which (INCOMPATIBLY) changed the date from
VMACIMS 0DDMMYYF to YYYYMMDD format. This change supports the
YEAR2000 new format, adds Y2K protection for their old YY format,
Sep 25, 1999 and also corrects an MXG error in the HH/MM/SS fields
that could cause the SAPTIME date to be a day later than
the actual date (those fields are actually PK format, but
they were input with PIB format, so an HH of '18'x or
larger became 25 hours, and bumped the date when HH was
added to create SAPTIME.
Thanks to Alain Kerninon, Generali AG, AUSTRIA.
Thanks to Ottfried Dorok, ICG Informationssys, GERMANY.
Change 17.226 An expiration date of 2099366 caused INVALID VALUE FOR
VMACDCOL DATEJUL FUNCTION and UMEXPDT or DCDEXPDT were missing,
Sep 18, 1999 although ORGEXPDT still contained the 2099366 value.
Since 2099366 itself is an invalid value (2099 is not a
leap year), MXG's algorithm for invalid dates (which is
to set the calculated expiration date to 31Dec2099 so
that any calculation on days-to-expire will be large) is
now extended to protect the invalid date of 2099366,
by inserting
(YREXPDT=199 AND DAYEXPDT GE 365) OR
after the (YREXPDT=99 AND DAYEXPDT GE 365) OR statement
in two places.
Thanks to Harald Seifert, HUK-Coburg, GERMANY.
Thanks to J. Hohring, HUK-Coburg, GERMANY.
Change 17.225 SAS/GRAPH examples are now updated to report
GRAFWORK BY SYSPLEX SYSTEM; instead of just
Sep 18, 1999 BY SYSTEM;
Thanks to Tom Kelman, Sun Trust, USA.
Change 17.224 Member IMACKEEP was not included in TYPETAND, but it now
TYPETAND has been added after the include of member VMACTAND.
Sep 17, 1999
Thanks to Steve Hurley, National Westminster Bank, ENGLAND.
Change 17.223 Report example fails if there were more than one SYSTEMs
ANAL42 data, because the PROC SORT DATA=JIM2 OUT=JIM; and DSD
Sep 15, 1999 BY DESCENDING IOCOUNT;
should have been BY SYSTE DESCENDING IOCOUNT;
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.222 Support for APAR OW39508 adds support for 7060 Multiprise
FORMATS 3000 Enterprise Server's new EIO (Emulated I/O) and DSD
Sep 15, 1999 (Direct System Device) type of CHPIDs. MXG Format named
$MG073CD decodes the CHPID type and was updated for these
two new entries, plus additional entries that were in the
complete list (which should have been in the APAR text,
but was not printed there).
Change 17.221 Deaccumulation of WEBSERVR dataset had DURATM and
VMACNTSM STARTIME missing because PREVWEBS=SYSTEM should have been
Aug 27, 1999 PREVWEBS=WEBSERV. Additional variables are deaccumulated
and minor other corrections were made.
Thanks to Jim Quigley, CONED, USA.
Change 17.220 SMF type 110 subtype 0 records written by CICS 5.1 caused
VMAC110 JCRLL=0 MXG error message, because MXG expected the new
Aug 27, 1999 Journal Format SMF records in CICS 5.2 instead of 5.1!
To correct, find the two IF statement with comments that
contain "Journal Format" and change them to now read:
IF SMFPSRVR LT 51 THEN DO /* PRE 5.1 JOURNAL FORMAT */
ELSE IF SMFPSRVR GE 51 THEN DO; /*POST 5.1 JOURNAL FORMAT*/
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Change 17.219 SAS ITSV CPDUPUPD fails with APPARENT MACRO error because
DIFFTPX an old statement: OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB;
DIFFROSC was still in these members. The SASAUTOS was changed to
TYPEDOS OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS); back in
TYPEIMS Change 16.066, and since they are set in member CONFIG,
TYPEIMS1 those old statements in these members were deleted so as
Aug 23, 1999 to eliminate the error.
Thanks to Jens Mohring, HUK Coburg, GERMANY.
Thanks to Harald Seifert, HUK Coburg, GERMANY.
Change 17.218 Support for Top Secret Release 5.1 (INCOMPATIBLE, due to
VMAC80 the need for a specific test to recognize Top Secret type
VMAC80A 80 records from the standard IBM type 80 record). To fix
Aug 23, 1999 MXG to support this release, you need only to add
OR RACFVRSN=051X
to the existing test for Top Secret Versions.
Thanks to Peter Vines, THE University of Virginia, USA.
Change 17.217 The member still contained a %INCLUDE for EXTY94 instead
VMAC94 of invoking the _ETY94 substitution macro, so overriding
Aug 16, 1999 the _ETY94 did not work. Now it does.
Thanks to Tom Parker, CSC/Hogan, USA.
======Changes thru 17.216 were in MXG 17.06 dated Aug 12, 1999======
Change 17.216 To be Y2K Ready, ASMTAPES must be assembled with "ES6"
VMACTMNT when the MXGTMNT Tape Mount Monitor program is assembled
Aug 12, 1999 for under OS/390 R1.3 or later. Your old MXGTMNT program
that had been assembled with "ES5" or "ESA" still ran on
OS/390 R1.3, so there was no error to alert you that the
"ES6" was now required, but if you are still running the
old MXGTMNT after January, 2000, the date in the INITTIME
field will still be 1900! IBM moved that date from a 3
to a 4 byte field that is only seen by "ES6".
ASMTAPES documents that "ES6" is for OS/390 R1.3, but
I had not previously highlighted that requirement.
This change protects VMACTMNT; if 1900 records are still
being written at your site in Jan, 2000, the variable
INITTIME in TYPETMNT and TYPETALO will be correct.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 17.215 The variable R791ES in this old report example became the
ANALSTOR variable R791ESCT in Change 8.167, but the report was not
Aug 10, 1999 updated until now.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 17.214 OS/390 R2.8 is already supported in MXG, as there were
several only minor, compatible changes, most of which have been
Aug 10, 1999 released as APARS to the type 89, 92, and 94 SMF records.
MXG Versions 16.09 or later can process the R2.8 records.
Change 17.213 Support for the Import/Export Statistics section in SMF
VMAC94 type 94 adds new variables to dataset TYPE94.
Aug 10, 1999
Change 17.212 TYPE110 SUBTYPE 2 ERROR STID=67 SKIP=80 because the value
VMAC110 of A17DT was hex '00' in the record, but MXG's statement
Aug 8, 1999 A17DT=TRANSLATE(A17DT,' ','00'x) was incorrectly changing
the '00'x to a blank, causing the two 40-byte sections
to be skipped. Delete that line and these records will
be properly decoded in to the CICFCR statistics dataset.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.211 TYPE74CF observations have the XSYSn variables non-blank
VMAC74 in only one record per SYSPLEX, and you can't pick which
Aug 8, 1999 SYSTEM's record has the info, accoring to this IBM reply:
To avoid collection of redundant data within a sysplex,
RMF selects one system as a 'master system'. This
selection is RMF internal, there is no option to select
the master system. For this 'master system' all CF
data, SMF 74-4 data, are collected. For the other
systems within a sysplex, the redundant but expensive
CF-data are omitted (expensive in terms of CPU
utilization). That explains why we see the
'Connectivity Data Section' and 'Structure Data
Section' only for one system within a sysplex. For
more details, please see apar OW31699, as this was
introduced with this APAR.
Thanks to Dennis Wong, New York Life Insurance, USA.
Change 17.210 -PDB.ASUMTAPE can have the wrong JOB/READTIME/INITTIME for
ASUMTAPE some jobs from TYPETMNT, but these events are detected
Aug 8, 1999 and the TYPETALO information is used to identify the job
that caused the mount. These mismatched events occur
only for jobs that went thru allocation recovery and are
usually few in number (5 of 2500).
-PDB.ASUMTAPE can have small negative values for TAPMTDTM
because the TENDTIME is the sampled MXGTMNT end of mount,
but TY21TIME is the exact dismount timestamp. The value
will be less than two seconds (the default MXGTMNT sample
rate) so to avoid negative numbers for the duration a
a tape is mounted, these negatives are now set to zero.
Thanks to Gene Rahe, First American, USA.
Thanks to Judy Arroyo, Summit Bank, USA.
Change 17.209 Support for NTSMF: Lotus Notes, SMTPDS & SMTPRS objects:
EXNTLNAG Object Dataset Variables
EXNTLNCA Lotus.Notes.Agent LONOAGNT 8
EXNTLNDB Lotus.Notes.Calendar LONOCALN 6
EXNTLNDI Lotus.Notes.Database LONODB 21
EXNTLNDV Lotus.Notes.Disk LONODISK 2
EXNTLNDO Lotus.Notes.Disk.Inventory LONODINV 1
EXNTLNMA Lotus.Notes.Domino LONODOMI 66
EXNTLNME Lotus.Notes.Mail LONOMAIL 16
EXNTLNNE Lotus.Notes.Memory LONoMEM 5
EXNTLNNL Lotus.Notes.Network LONONETW 11
EXNTLNRE Lotus.Notes.Network.Log LONONETL 2
EXNTLNSE Lotus.Notes.Replica LONOREPL 5
EXNTLNWE Lotus.Notes.Server LONOSERV 16
VMACNTSM Lotus.Notes.Web LONOWEB 39
VMXGINIT SMTPDS SMTPDS 4
Aug 7, 1999 SMTPRS SMTPRS 4
-NTSMF 2.1.1 could write an interval begin (0,0) with the
DURATM=0, which caused STARTIME to be missing. While now
fixed, this change also protects that case and uses the
previous interval to construct STARTIME.
Change 17.208 The RECFM=F and LRECL=256/512 were removed from the
VMACSPMG INFILE statements so that the DCB attributes are read
Aug 6, 1999 from the dataset. SpaceManager files can be F or FB.
Thanks to Anke Mineur, dvg Hannover, GERMANY.
======Changes thru 17.207 were in MXG 17.05 dated Aug 5, 1999======
Change 17.207 Microsoft SP4 and HotFixes have changed the version text
VMACNTSM from "Service Pack 3" to "Service Pack 4, RC 1.2", which
Aug 5, 1999 was passed by NTSMF into its output comma delimited file,
so an extra new field was inadvertently inserted in this
configuration record. MXG now looks for that syntax and
appends the "RC 1.2" to the NTVERSN. NTSMF will protect
the field in a future version to blank the comma.
Thanks to Norbert Ravarani, European Commission, LUXEMBURG.
Change 17.206 Member IMACJBCK (the "job check" exit to select SMF
IMACJBCK job-related records by JOB/READTIME/etc) was not changed
VMXGINIT to support dynamic changes, but by defining MACJBCK in
Aug 5, 1999 VMXGINIT and locating &MACJBCK; at the end of IMACJBCK
you can now use %LET MACJBCK= ... ; syntax instream
instead of editing your tailoring into IMACJBCK member.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.205 Variables MCTDLWTV and MCTDPWTV, bytes logically written
VMXGHSM and bytes physically written, are now created in dataset
Aug 5, 1999 MCT from the HSM catalogs. Many sites now use DCOLLECT
rather than reading the catalogs directly with MXG.
Thanks to Dave Jackson, Capital One Financial Services, USA.
Change 17.204 Negative PGMLODTM was caused by the DEFAULT=4 which was
VMACCIMS truncating timestamps and record number. Change the
Aug 5, 1999 both DEFAULT=4 to DEFAULT=8.
Thanks to Alan Green, Zurich Co., ENGLAND.
Thanks to Brian Sznger, Zurich Co, ENGLAND.
======Changes thru 17.203 were in MXG 17.05 dated Aug 4, 1999======
Change 17.203 If you have Dedicated CPUs in LPARs, PR/SM forces Wait
ASUM70PR Complete=Yes (which makes sense: to reduce overhead when
Aug 4, 1999 there's nothing to share), but MXG's PDB.ASUM70PR reports
100% CPU busy in that LPAR (LCPUPDTM, partition dispatch
time is 100% in a Wait Complete=YES LPAR) because MXG did
not see this before! The immediate fix to your ASUM70PR
member is to insert this DO group in the INCODE= section,
immediately after the "LPARDUR=DURATM;" statement:
IF LCPUDED='Y' AND LCPUWAIT='Y' THEN DO;
IF PCTCPUBY GT . THEN DO;
LCPUPDTM=LPARCPUS*PCTCPUBY*DURATM/100;
LCPUEDTM=LCPUPDTM;
END;
ELSE DO;
LCPUPDTM=.;
LCPUEDTM=.;
END;
END;
The PCTCPUBY that is tested is MVS CPU busy for Dedicated
CPUs, but it exists only in the SMF record from the MVS
System running in that LPAR. In the ASUM70PR observation
from other LPARs in this CEC (Central Electronic Complex)
the dedicated LPAR CPU busy measures will be missing, as
they simply are unknown to the other LPARs. If you have
only one LPAR in a CEC, then there is only one SYSTEM and
the ASUM70PR data will be valid with the above fix.
However, this error is an opportunity to design a better
solution to measuring CEC/LPAR CPU busy. The ASUM70PR
dataset is created per SYSTEM, but what you need is now
the new PDB.ASUMCEC dataset that summarizes TYPE70PR data
by the CECSER (CPU Serial Number of the CEC/CPC), so the
hardware platform is measured by PDB.ASUMCEC, with true
CPU busy for each of the LPARs running on that CEC.
The structure of PDB.ASUMCEC has the same variable names
(except for SYSTEM, which doesn't have any meaning here),
so your existing reporting should require minimal change.
But MXG has to read all of the type 70 records from every
MVS system that executes in an LPAR with Dedicated CPU to
create true CPU measurements; you cannot measure CPU busy
in a Dedicated-CPU-LPAR from any other LPAR's SMF record;
if MXG does not see the true CPU busy record, the CPU for
those dedicated engines will be missing values and the
total CPU busy will be wrong.
Check your EXTY70PR exit to see if there was user code
added to output records from only one system; delete
that logic if you find it, so you output all records.
The bottom line is that PDB.ASUMCEC should have been the
dataset created long ago, but now it should correct the
existing error and give you a single record per box to
measure total and per-LPAR CPU utilizations.
Thanks to Brandan Hock Kwan Wong, DBS, Singapore.
Thanks to Chee Hwee Chua, DBS, Singapore.
Change 17.202 This example report program processes VTS SMF type 94
ADOC94 records and replicates IBM PGM=VTSSTATS reports. The
ANAL94 report is documented in member ADOC94. Remember to use
Aug 2, 1999 only one system's data to report on a library box.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.201 APAR OW40390 identifies SMF92CPN, pathname, that may be
VMAC92 in your type 92 OMVS/USS file records; that field is now
Aug 2, 1999 input if present. The APAR also adds two subtypes to SMF
Aug 10, 1999 type 94 that create two new MXG datasets for OMVS/USS:
Subtype Dataset Description
12 TYPE9212 MMAP
13 TYPE9213 MUNMAP
Change 17.200 Support for IBM's TPF Operating System.
EXTPFxx Forty datasets are created from the fifty or so records.
FORMATS Some datasets are written at monitor initialization to
IMACTPF map things, but the interval records are deaccumulated
TPFINTRV and written as individual PDB datasets, and then TPFINTRV
TYPETPF is invoked to summarize into PDB.TPFINTRV. This support
VMACTPF has been tested with data from one system, and TPFINTRV
VMXGINIT intervals the SA/NX/SX/SU/SP/MD/MG/FV/FS/SC records.
VMXGTPFI This is preliminary support, but TPFINTRV and its input
Aug 2, 1999 datasets have been tested extensively; there are still a
number of questions and some variable names may change.
For over two years I have requested the DSECTS for the
TPF records; it took a vote of the TPF Users Group to
"convince" IBM it would be worthwhile to allow MXG to
support this high-speed transaction processing system.
Formerly know at the Airline Control Program, it can
drive 30,000 I/Os per second on an 8-engines CPC!
The initial development of the VMACTPF code took 40 hours
across four days to write about 4,000 lines of SAS code.
Another 40 hours were required to add the roughly 400
lines to deaccumulate and validate the PDB.TPFINTRV data.
Thanks to Jack Opgenorth, Sabre, USA.
Thanks to Linda Tallent, Sabre, USA.
Change 17.199 Support for APAR OW39128 adds DSNAME to SMF type 80-2
VMAC80A Resource Access event, so that you can tell what library
Aug 2, 1999 an audited controlled program was loaded from! So if
you need to know which program library is being used by
which users for which programs, you can use RACF to
control access and write a record for each successful
or failed attempt to run that program and finally know
which STEPLIB dataset was actually used by that job!
Variable RPDSNAME is added to dataset TYPE8002. The APAR
also populates variable VOLSER in the DTP=15 section for
this case, but that variable is already in TYPE8002.
Change 17.198 Variables that contain '00'x, when printed across VTAM or
VMAC110 downloaded as a text file from MVS to your PC, can cause
Aug 2, 1999 the download to stop. Other unprintable characters in
a PROC PRINT output can make your PC see an end-of-file
long before the real end of the file. When these values
are seen for a character variable, it is either formatted
with a HEX/$HEX format, or if the variable is normally a
printed variable that maybe has nulls at the end, then
the TRANSLATE function is used to convert nulls to blank
values. Variable SMFSTRTK was formatted $HEX16. and the
variables A13LVW, A17FLOC, A17DTTYP, A17DT, and DS5TCBNM
have any nulls translated to blanks.
Change 17.197 Starting from ANALDSET, this new ANALJOBE, "Job Events"
ANALJOBE adds to the 14, 15, 64, and 30s, the information from the
Aug 2, 1999 the VSAM type 62 OPEN time, the statistics from the type
Aug 12, 1999 42 subtype 6 TYPE42DS close, and the type 30 interval
records are used to capture PROGRAM name for Started
Tasks and long running steps whose step termination type
30 has not yet been seen. Additionally, if new datasets
were cataloged, the 61/65/66 SMF records in TYPE6156
identify that activity. The result will be a tool to
examine every timestamp in the life of a job, for delay
analysis, etc. This phase is complete, but HSM is soon
to be added.
And ANALJOBE is a single step, cleaner implementation:
When ANALDSET was first written in 1976, tape had to
be used because of data volume, and frequent system
crashes were circumvented by using multiple steps, so
a recovery might not have to re-read the SMF data
again!. Reliability, cheaper DASD, and better code
makes that unnecessary: two days SMF data opens used
than 1000 Cylinders (a/k/a 750 MB) of //WORK space.
The output dataset of this algorithm, ANALJOBE, may be,
in a future program, merged into the ASUMTAPE dataset to
identify the first-open-time and last-close-time of each
tape dataset, to identify where FREE=CLOSE can be used to
save tape drives.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.196A If the CPMF segment exists in the record, but SMF73CMG,
VMAC73 the CPMF Measurement Group is 0, MXG did not skip over
Aug 2, 1999 the CPMF segment, and stopped reading Channels at CHPID
'55'x (one third of 'FF'x, because the old segment was
24 bytes long, the new is 72). Also, variables CHANIND
CHANINDX CHANINDY SMF73CPD SMF73FG5 are now hex format.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 17.196 Dataset CONTROLD variable ACCOUNT2 is renamed CTLDACCT,
VMACCTLD so that its label does not override the real ACCOUNTn
Aug 2, 1999 field if CTLD records are processed with BUILDPDB. The
label as changed from second to first, as CTLDACCT has
(in ten fixed bytes) the first account field.
Thanks to Mike Penlington, Westpac Truse, NEW ZEALAND.
Change 17.195 Support for STK's VTCS 2.2.0 INCOMPATIBLE change to VSM
VMACSTC SMF subtype 13-26 records. Version 1 timestamps used the
Aug 2, 1999 unix epoch of 1/1/1970, which MXG handled, but now their
developers decided to waste my time and your time by
changing what was working just fine, back to what it
should have been in the first place, a TODSTAMP8 format.
And it doesn't appear that they put a version indicator
in their record, so I have to test each subtype to see
which version you have installed. And because at least
one field (VTV time) was not changed to TODSTAMP, I have
to test each of those timestamps in case they change the
format again! The test uses the first four bytes of the
timestamp, an algorithm that won't fail until Sep, 2042,
when the TOD clock wraps. Hopefully, STK will have added
a version indicator in their record before then.
Thanks to Sue Yarker, Midland Bank a/k/a HSBC, ENGLAND.
Change 17.194 The MXG 16.04+ revisions to HP Measureware did not define
VMACMWUX macros _HPUXCPU and _HPUXDLM in member VMACMWUX, and the
Aug 2, 1999 examples in IMACMWUX were commented out. The correction
was to define the macros in VMACMWUX, so that they are
defined by default in the VMAC, so they can be tailored
in the IMACMWUX, IMACKEEP or with %LET MACKEEP=. logic.
Thanks to Glenn Delvecchio, Stelco Inc, CANADA.
Change 17.193 -Using INTERVAL=NONE caused a warning message that the
VMXGSUM VARIABLE DATETIME IS UNINITIALIZED with no other impact.
Aug 2, 1999 The warning message is eliminated by this change.
-Using a dashed-list of variables in the NORM= argument
could cause errors messages about &EVAL function or
extra variables to be created, but only if there was
more than one dash per line and/or blanks around the
dash. Now the parser handles dashed-lists and blanks.
Change 17.192 The BY list for TYPE42DS needed DEVNR added to the end of
VMAC42 the list to fully protect for duplicate records.
Jul 30, 1999
Thanks to Chuck Hopf, MNBA, USA.
Change 17.191 Comments. The Subtype 5 Interval record is automatically
ASMTAPEE synchronized with SMF ENF Event 37, so there is no longer
Jul 28, 1999 a need to issue the console command to synchronize.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.190 The SPIN.SPINMOUN and SPIN.SPINALOC datasets were not
ASUMTAPE copied into the PBD library (for backup and recovery),
Jul 28, 1999 but now they are.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.189 Member DIFFDB2 is automatically invoked by TYPEDB2, and
DIFFDB2 it separately listed the _Sdddddd macro for each dataset
VMACDB2 to be sorted/deaccumulated, which works fine, until you
Jul 27, 1999 try to create only dataset DB2ACCT. You can null all DB2
datasets with the _NDB2 macro, and can reinstate DB2ACCT
with the MACRO _WDB2ACC redefinition, but then DIFFDB2
fails ("NO DATASET OPEN TO LOOK UP VARIABLES") when it
tries to sort the non-existent datasets. You can fix the
design flaw by nulling out each of the individual sort
sort macros that are listed in DIFFDB2:
%LET MACKEEP= _NDB2
MACRO _WDB2ACC DB2ACCT.DB2ACCT %
MACRO _SDB2ACP %
MACRO _SDB2ACB %
MACRO _SDB2ACG %
MACRO _SDB2PAT %
MACRO _SDB2ST2 %
MACRO _SDB2STB %
MACRO _SDB2STR %
MACRO _SDB2STS %
MACRO _SDB2PST %
;
%INCLUDE SOURCLIB(TYPEDB2);
to build only the DB2ACCT.DB2ACCT dataset. However, to
correct the design flaw, the definition of MACRO _SDB2
in VMACDB2 was changed so that it does not sort the
DB2ACCT dataset (just like _S110 doesn't sort CICSTRAN)
and DIFFDB2 now invokes _SDB2 instead of all of the
individual _SDB2ddd macros, so now (17.05+) you can use:
%LET MACKEEP= _NDB2
MACRO _WDB2ACC DB2ACCT.DB2ACCT %
MACRO _SDB2 %
;
%INCLUDE SOURCLIB(TYPEDB2);
to create only DB2ACCT.DB2ACCT. And this protects you
for future datasets, and they will be listed in both the
_NDB2 and _SDB2 macro definitions.
Thanks to Alastair Gray, Phillip Morris International, SWITZERLAND.
Change 17.188 This user contribution was posted on MXG-L; it reads the
USTKVOL output of the StorageTek Volume Report utility to find
Jul 26, 1999 the date when each volume was mounted in the ATL, and the
the date when each volume was mounted in the ATL, and the
example invokes MXG member TYPETMS5 and appends the ATL
data with the TMS information on each volume.
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 17.187 The MXG Test JCL stream step TESTOTHR fails in VMXGTAPE
JCLTEST6 because SAS option USER=PDB had been added to their JCL.
Jul 26, 1999 Don't do that to this JCL example that didn't expect it!
A comment has been added to the member.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.186 IBM RMF Report replicator example used TYPE74OM dataset
ANALRMFR to now produce their OMVS KERNEL ACTIVITY REPORT.
Jul 22, 1999
Change 17.185 IBM's sample IXGRPT1 for SMF type 88 Logger records is
ANAL88 now replicated in this example report program that uses
Jul 21, 1999 both TYPE88 and TYPE8811 datasets.
Change 17.184 Revision to correct ZEROOBS= argument, which did not work
UTILBLDP in the prior version. Further updated August 3.
Jul 21, 1999
Thanks to Mike Utting, Hitachi Data Systems, AUSTRALIA.
Change 17.183 Continued IMS Log enhancements for Fast Path transactions
TYPEIMS is revised and made available for testing.
VMACIMS
Jul 21, 1999
Change 17.182 Numerous errors in OMVS/USS dataset TYPE74OM. MXG failed
VMAC74 to divide seven variables by NRSAMPLE, so they had large
Jul 21, 1999 values: OMVSSYSC OMVSCPU OMVSOPRP OMVSOUS OMVSOPRU
OMVSCURP OMVSCURU
And NRSAMPLE was not kept in TYPE74OM, but now is there.
Then IBM documented twelve fields as binary, but they in
fact contain s_float (RB4.) data, also causing largeness:
OMVSCMSG OMVSCSEM OMVSCSHM OMVSCSPG OMVSCMAP OMVSCPAG
OMVSOMSG OMVSOSEM OMVSOSHM OMVSOSPG OMVSOMAP OMVSOPAG
-A few labels had TOT or TOTAL for Average variables.
-Note that the IBM OMVS Kernel Activity Report prints
CPU time in units Hundredths of a Second, so a MAX CPU
of 8 on their report is actually .08 CPU seconds, which
is what MXG variable OMVSCTMX contains.
-RMF fields for Shared Memory, Memory Map Storage, and
Shared Storage are in bytes in the raw data, so MXG now
formats those variables with MGBYTES to show the true
MegaBytes, etc, but IBM still prints K or M after the
value for a factor of 1000 instead of 1024. For Shared
Storage actual value 32,768,000, IBM prints 32.8M, but
MXG prints that true size in megabytes as 31M.
Thanks to Ed Woodward, ADP/BSG, USA.
Change 17.181 Cosmetic. DCOLLECT variables DCDCUDSZ and DCDUDSIZ were
VMACDCOL correct, but their labels were reversed. DCDCUDSZ is the
Jul 21, 1999 Data Size AFTER compression, DCDUDZIZ the size BEFORE.
Thanks to Alan Winston, MBNA, USA.
Change 17.180 Support for APAR OW31701, "ESS Parallel Access Volumes"
VMAC74 adds new variables to TYPE74 and TYPE799 datasets:
VMAC79 PAVBASE ='PAV*DEVICE?'
Jul 20, 1999 NRALEXCH='NUMBER OF*ALIAS*EXPOSURES*HAS CHANGED'
Sep 12, 2000 SMF74PCT='SUCCESSFUL*PAV*SAMPLE*COUNTS'
SMF74TMS='TIME SKIPPED*IF NR*ALIAS EXP*WAS CHANGED'
NREXPOSR='NUMBER OF*UCBS FOR*PAV VOLUME'
Text of this change revised after change 18.096 added the
variable PAVBASE instead of old variable BASE.
Change 17.179 Using the 17.04 ANALRMFR against a 14.14-built PDB failed
ANALRMFR with VARIABLE SMF72QDT NOT FOUND; five variables added to
Jul 20, 1999 TYPE72GO (SMF72QDT/IQT/ADT/IOT/CVT) by later versions of
MXG were not protected for non-existence in ANALRMFR, but
now they are and it can be used against back-level PDBs.
Thanks to Normand Poitras, Banque Nationale du Canada, CANADA.
Change 17.178 New summarization member creates PDB.ASUM78CF dataset by
ASUM78CF summarizing dataset PDB.TYPE78CF for analysis of I/O
Jul 20, 1999 Configuration activity.
Thanks to John Meli, Queensland Rail, AUSTRALIA.
Thanks to Paul Dirkis, Queensland Rail, AUSTRALIA.
Change 17.177 Support for Control D release 5.1.4 has been confirmed,
VMACCTLD as there were no changes in the record format.
Jul 20, 1999
Thanks to Trevor Ede, EDS, NEW ZEALAND.
Change 17.176 OMVS (Open Edition/MVS), now USS (Unix System Services)
BUILD005 tasks create no purge records, so BUILDPB held their data
BUIL3005 in the SPIN library for SPINCNT days (in member IMACSPIN)
VMAC30 before they were OUTPUT into the PDB.STEPS and PDB.JOBS.
Jul 20, 1999 These OMVS tasks have SUBSYS='OMVS' but TYPETASK='STC '.
To output the OMVS tasks without purge records, BUILD005
and BUIL3005 were revised to detect and to not spin OMVS
tasks. To be consistent with its purpose, MXG variable
TYPETASK='OMVS' will now contain 'OMVS' for OMVS tasks.
You can fix the SPIN problem by using member IMACSPCK
by inserting: IF SUBSYS='OMVS' THEN OKFLAG=1;
until you install the version with this change.
Note that these JOBS/STEPS observations for OMVS tasks
are the TSO resources; the count of OMVS functions are in
the TYPE30OM dataset, which was not affected.
Thanks to Larry Ludwig, Northern Illinois University, USA.
======Changes thru 17.175 were in MXG 17.04 dated Jul 16, 1999======
Change 17.175 The preliminary IMS Log Enhancements in Change 17.172
ADOCIMS required one more tweak. The SubQ 6 time from the type
TYPEIMSA 7 record was being applied to the following transaction
VMACIMSA instead of the preceding transactio for pseudo/WFI or
Jul 16, 1999 Quick Reschedules, causing timestamps used to calculate
service times to be bad in occasional transactions.
Also, the member ADOCIMSX now exists in the MXG 17.04
dated Jul 16 that is now being shipped.
Change 17.174 IBM has confirmed Don's discovery that the R723CCHS
VMAC7072 (MXG variable PCTDLCHS) was trashed (like 600,000%!),
Jul 16, 1999 and will eventually fix their in counting those delays.
This correction recalculates by subtracting all of the
other wait fields so that PCTDLCHS will be valid with
or without the IBM correction.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 17.173 -Reading AS/400 data on ASCII platforms caused variable
VMACQAPM AS400SYN to be trash, because it wasn't converted from
VMXGINIT ASCII to EBCDIC when it was input as variable GDESS, but
Jul 15, 1999 inserting these two lines after the input of GDESS:
Jul 20, 1999 GDESS=INPUT(GDESS,$EBCDIC8.);
GDESS=TRANSLATE(GDESS,' ','80'X);
will create readable values for GDESS and AS400SYN.
-Also, WARNING: APPARENT SYMBOLIC REFERENCE LOLEVEL NOT
RESOLVED note is eliminated by the addition of LOLEVEL
in VMXGINIT as a GLOBAL macro variable with null value.
Macro variable LOLEVEL was used under MVS to pass the
lowest level of the DSNAME of the input file into an
MXG variable (AS400SYS in this case), because there
used to be no "System" name in the AS400 records.
Now, the MXG variable AS400SYN contains the system
name, so AS400SYS can be left blank.
-The include of member IMACKEEP was missing from TYPEQAPM
member, so tailoring in IMACKEEP was not recognized for
the AS/400 processing. It has now been added.
Thanks to Don Goulden, SAS Institute, USA.
======Changes thru 17.172 were in MXG 17.04 dated Jul 14, 1999======
Change 17.172 Significant enhancements to IMS log processing are now
ASMIMSLG available for testing. These added members will replace
ASMIMSL5 their counterparts in the next version of MXG, so I
ASMIMSL6 chose to use temporary names with an X in the penultimate
JCLIMSXG position to keep the new members apart. For the ASM and
JCLIMSX5 JCL members, change the X to an L, and for the TYPE and
JCLIMSX6 VMAC members, change the X to an S, as you copy them into
TYPEIMSA your USERID.SOURCLIB for testing.
TYPEIMSB Member ADOCIMSA contains the discussion of the changes in
VMACIMSA these revisions.
Jul 14, 1999
Thanks to Carl Meredith, SAS Institute ITSV, USA.
Thanks to Ken Whitehead, Bank of New York, USA.
Change 17.171 PRINTWAY records contain JCTJOBID='PSnnnnnn', so the MXG
DOC logic to create TYPETASK='PS' and JESNR=nnnnnn in all of
Jul 13, 1999 these MXG members that create TYPETASK from JCTJOBID:
VMAC6,VMAC26J2,VMAC26J3,VMAC30,VMAC32,VMAC42,VMAC91,
VMACBETA,VMACDALO,VMACIPAC,VMACNNAV,VMACTMNT,VMACXPM
and BUILD005 was revised to test for the 'PS' value.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 17.170 DB2ACCT variables added by versions 5.1 and 6.1 are now
ASUMDB2A added to the summarization by member ASUMDB2a in creating
Jul 13, 1999 dataset PDB.ASUMDB2A. Comments in member ASUMDB2A list
the 75 variables added to the SUM and one to the MAX.
Thanks to Glenn Bowman, Wakefern, USA.
Change 17.169 Landmark TMON V2 response time TARSPTM will contain the
VMACTMO2 sum of all conversations if SEGMENT CONVERSTATION is NOT
Jul 13, 1999 set to Y in Landmark Record Collection Options, and the
total count of conversations is counted in TARSPCT. So
if TARSPCT is greater than one, TARSPTM is recalculated
as the average response time of those conversations:
IF TARSPCT GT 1 THEN TARSPTM=TARSPTM/TARSPCT;
Thanks to Dan Ternosky, IBM, USA.
Change 17.168 This utility will analyze a SAS data library for date or
ANALDATE datetime formatted variables, and will print a summary of
Jul 12, 1999 minimum and maximum dates found in your data, as well as
dates outside the expected range (user definable, default
earlier than 1/1/1999 or later than 1/1/2001). This may
be useful in your final Y2K testing of SAS libraries.
Thanks to Freddie Arie, LONE STAR GAS, USA.
Change 17.167 Corrections to Boole's MainView for CICS VSAM file. The
VMACMVCI division of T6EP24HW by 62500 was incorrect and was thus
Jul 12, 1999 removed. The input of T6EUSTGO was moved back two bytes,
by creating M6=-6; and using +M6 instead of +M4, and by
inserting +2 after the input to re-align with the rest of
the data fields.
Thanks to Mrs. Peridon, Ministere du Budget, FRANCE.
Thanks to Mr. Deledalle, SAS Institute, FRANCE.
Change 17.166 An IBM-provided PSF ZAP (change APSPPSMF to set SMF6IMPS
VMAC6 with Logical Page Count in DIAPAGE instead of Side Count
Jul 12, 1999 from DIAIMPS) overlays the record with zero for SMF6LN2,
that cause INPUT STATEMENT EXCEEDED error condition.
While IBM investigates, this circumvention resets a zero
SMF6LN2 to 36 so that the rest of the record is output.
If these invalid records are found, MXG will now print a
note for the first three instances.
Thanks to Rick Knapp, AON, USA.
Change 17.165 Preliminary NTSMF support for Win 2000 Beta 3 and support
VMACNTSM for new data and record formats for four existing objects
Jul 11, 1999 as well as protection for the new 0.8 and 0.9 records.
The Beta changes are incomplete, as the discover records
had fields with missing names that are input with place
holders, but the important existing fields should be ok.
Win 2000 Beta 3 Changes:
Object Status
Memory: Reordered, 3 Name Missing field
Process: 6 Name Missing fields
PhysDisk: 5 new fields inserted somewhere
LoglDisk: No Instance name, 3 new
Other Object Changes:
Object Status
IIS Global: Complete Revision, all new vars
Web Service: Twenty-Seven new variables
Indexing Service: Instance variable removed
Indexing Service Filter: Instance variable removed
Thanks to Jim Quigley, Con Edison, USA.
Change 17.164 The _SVMxxxx sort macros had PROC COPY syntax instead of
TYPEVM the DATA _LVMxxxx; SET _WVMxxxx; logic that is needed
Jul 11, 1999 until the _BVMxxxx BY macros are populated.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 17.163 ASUM70PR discards SMF70CIN='ICF' observations so they are
ASUM70PR not counted in NRCPUS, LPARCPUS, or PARTNCPU variables in
Jul 11, 1999 PDB.ASUM70PR (as long as you have APAR OW37565 on your
system - see Change 17.162). If you have more than one
ICF CPU, the circumvention in member XSUM70PR from Change
16.381 is not valid, and this revision does not depend on
a table of SYSTEM/LCPUADDR. It first counts the number
of ICF engines, and then subtracts that count from the
above variables in the real CPU records while deleting
the ICF CPU records. It also creates new variable
NRICFCPU with the count of the number of ICF engines
found in the CPC (and whose detail can still be found in
the TYPE70PR 'ICF' observations), but whose data are not
included in PDB.ASUM70PR (nor in TRND70PR either).
If you use this new ASUM70PR to summarize old TYPE70PR
data, you will get 'SMF70CIN UNINITIALIZED' messages, but
that has no impact unless you actually have ICF, in which
case you will need to recreate TYPE70PR with the new
TYPE7072 with Change 17.162 installed.
Change 17.162 Support for APAR OW37565 creates SMF70CIN='CP ' or 'ICF'
VMAC7072 in TYPE70PR dataset to identify if the CPU is a General
Jul 11, 1999 Purpose CPU (SMF70CIN='CP '), or an Internal Coupling
Facility CPU (SMF70CIN='ICF'). While most sites use the
PDB.ASUM70PR dataset, revised by Change 17.163, for PRSM
measurements, if you use the PDB.TYPE70PR detail dataset
you will want to revise your reporting to exclude the
ICF CPUs from your capacity counts and measurements.
Change 17.161 Support for APAR OW37816 adds data for new 2105 cache
VMAC74 subsystem to dataset TYPE74CA, and the data looks very
Jul 11, 1999 interesting with these new variables:
R7451AID='DEVICE*ADAPTER*ID'
R7451DVN='DEVICE*NUMBER'
R7451FLG='0=NO INFO*1=RAID RANK DATA'
R7451HDD='NUMBER OF*HDDS IN*RAID RANK'
R7451HSS='HDD*SECTOR*SIZE'
R7451NVS='NVS*SPACE*ALLOCATION'
R7451RID='RAID*RANK*ID'
R7451RMR='RECORD*MODE*READ*REQUESTS'
R7451RRQ='RAID*RANK*READ*REQUESTS'
R7451RRT='RAID*RANK*READ*RESPONSE*(MILLISEC)'
R7451RSV='R7451RSV*LOWER*IO*MILLISEC'
R7451SR ='RAID*RANK*FB SECTORS*READ'
R7451SW ='RAID*RANK*FB SECTORS*WRITTEN'
R7451TSP='TRACKS XFERED*TO SECONDARY*PPRC VOL'
R7451WRQ='RAID*RANK*WRITE*REQUESTS'
R7451WRT='RAID*RANK*WRITE*RESPONSE*(MILLISEC)'
R7451XCW='XRC OR CC*CONTAMINATED*WRITES'
R7451XSF='XRC OR CC*SIDEFILE*READ*REQUEST'
The change also populates field R745XRSV, which has been
in dataset TYPE74CA as MXG variable RSV for some time:
RSV ='LOWER*INTERFACE*IO*(MILLISEC)'
And the Real Control Unit ID, R745CUID/R745DCID was added
to both the Cache Control Section and the Cache Device
Data Sections.
This change has been syntax checked, but not yet tested
with records with the PTF installed. This note will be
deleted when the change has been validated with data.
Change 17.160 SAS requires all BY list variables to be in the 1st 4092
ANALRMFR bytes of the physical record, a SAS restriction that I
Jul 11, 1999 had not hit before, but this RMF report program failed
when many reports were requested, as it creates a single
dataset with many variables. By creating a copy of the
data with an added RETAIN statement (as suggested by the
text of the SAS Error message!!):
DATA newcopy; RETAIN list-of-BY-variables; SET oldcopy;
the zY variables are located at the front of the newcopy.
Thanks to Jon Whitcomb, Great Lakes Higher Education Corporation, USA
Change 17.159 RMF Type 99 Subtype 2 variable PCDCLOCK was input as PIB
VMAC99 but it can be negative, so it should have been input IB,
Jul 11, 1999 and it was input from the wrong location, and new fields
added by OS/390 R2.6 are now decoded in dataset TYPE99_2.
Thanks to Ralph Acorn, Safeway, USA.
Change 17.158 Top Secret writes TYPE80 SMF records with RACFTYPE values
VMAC80A of 0,103-105,109, and 255 that caused "SEGMENT SKIPPED"
Jul 11, 1999 messages on the MXG log. This change revised the MXG
logic so only five messages will be printed on the log:
INPUT +RACFDLN @; old
NSKPRACF+1; new
IF NSKPRACF LE 5 THEN new
PUT /' SKIPPED SEGMENT ' RACFEVNT= .... old
Fortunately, the TYPE80xx datasets created are valid.
I'm awaiting test data to decode these TSS-only events,
and this text will be updated when MXG is enhanced to
deal with the TSS-only data records and fields.
Thanks to Marc Matthys, Hudson Williams Europe, BELGIUM.
Change 17.157 The new _STY30TD sort macro for TYPE30TD had SMFTIME in
VMAC30 the BY statement, but it is not kept in the dataset, and
Jul 9, 1999 the BY list is now READTIME JOB JESNR DEVNR INITTIME.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.156 Support for CICS TS 1.3 new field TRNGRPID which was
IMACEXCL inserted in the CICSTRAN record (INCOMPATIBLY), causing
VMAC110 many fields to have incorrect values. IBM did not
Jul 7, 1999 automatically refresh my documentation when they added
the field (which happens to reuse a previously used field
number, 082 decimal). To just skip over the new field,
insert a line with +28 after CLIPADDR $EBCDIC16.
Thanks to Dirk Frijlink, Shell Services International, NETHERLANDS.
Change 17.155 Support for Connect Direct Release 3.2 record 'CT'.
VMACNDM The documentation is wrong in their Appendix pages,
Jul 6, 1999 but MXG tolerates the 3.2 record. There are three
fields added in existing location, one of which,
MXG variable NDMCTDOF, is an offset to a new table,
but I have no example record with that offset present,
so the CTDTOTAL table cannot be decoded until a data
record with that event (process was restarted) is
available.
Thanks to Fiona Crane, IBM United Kingdom, ENGLAND.
Change 17.154 Zero observations in dataset NSPYTIC3 and non-zero in
VMACNSPY NSPYETHR is the result of Change 16.147 overriding
Jul 6, 1999 Change 15.268. The tests for NSPYRECI have been again
corrected, so that for NSPYREL 4.5 and higher, only the
NSPYRECI is used to select ETHERNET versus TIC3, but
4.4 and earlier are protected by using the other flags,
but only for R 4.4.
Thanks to Simon D. Briggs, Allied Irish Bank, IRELAND.
Change 17.153 Variable MCBSCRD, Uncatalog Date, is now created in HSM
VMXGHSM dataset set in dataset MCB from the HSM control file.
Jul 6, 1999
Thanks to Stephen Hahne, Capital One Financial Services, USA.
Change 17.152 Support for MIM's user SMF record is enhanced, and a new
EXTYMIMD dataset is now created, with GDIF benefit counts at the
VMACMIM MIIPLEX LPAR level. The new dataset keeps the old name
Jul 6, 1999 of MIMGDBE, but is at a higher level of detail now, and
the lower level of detail at the enqueue QNAME level that
was MIMGDBE is now created as dataset MIMGDBC.
Thanks to Martyn A. Jones, Chase, ENGLAND.
Change 17.151 TMS records containing DENX='DE'x are undocumented, but
VMACTMS5 appear to be stored in records for Deleted VOLSERs, as
Jul 6, 1999 none of the dates are populated, and Create Job Name is
Jul 11, 1999 DELETE, and Stepname is EBCDIC zeroes. This unexpected
DENX value caused MXG to print a note and a hex dump on
the SAS log, because Density is used to estimate the feet
of tape used, but this note has no real impact on the TMS
datasets created by MXG. To suppress the notes, I added
ELSE IF DENX=0DEX THEN DEN=0; after ELSE IF DENX=0E8X...
-The %%INCLUDE SOURCLIB(EXdddddd); statements should have
been replaced with their _Edddddd macro invocations in
the 16.04 re-architecture; they are now revised so that
those MXG dataset exits can be overridden with MACKEEP=.
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.150 While support for CICS TS 1.3 was in member VMAC110, the
IMACEXCL support for excluded fields was not added to IMACEXCL
Jul 5, 1999 until this change.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 17.149 The VVDS Key Cluster Name was not converted to blanks
VMACVVDS if the fieldname contained '80'x or '00'x, but now, like
Jul 5, 1999 the other names, the TRANSLATE function converts.
Thanks to Tom Benson, Amdahl U.K., ENGLAND.
Change 17.148 Cosmetic. Label for variables DSG32NAM and DVL32NAM
VMACDCOL are now 'DSG FLAG*SMS 8-WAY OR*32 WAY?' and 'DVL ....'
Jul 5, 1999
Thanks to Grahm West, NPI, ENGLAND.
Change 17.147 MXG 17.03, "BY VARIABLES NOT SORTED IN WORK.SPIN30TD"
BUILD005 error is corrected by moving these two existing lines:
BUIL3005 PROC SORT %VMXGFOR DATA=CVRT30TD OUT=CVRT30TD ;
Jun 30, 1999 BY READTIME JOB JESNR INITTIME DEVTYPE DEVNR;
from before the DATA SPIN30TD; statement, to after the
PROC DELETE DATA=CVRT30TD; statement, and then change
the CVRT30TD in both places in the PROC SORT to SPIN30TD.
Thanks to Dirk Frijlink, Shell Services International, NETHERLANDS.
Change 17.146 Inconsistencies and typos were corrected.
MONTHBLD -The BY list in WEEKBLD-MONTHBLD for TYPE89 caused NOT
WEEKBLD SORTED error because SYSPLEX should have been added as
WEEKBLDT the first var in the BY list after Change 16.xxx was made
VMAC25 to its VMAC.
VMAC80A -The BY list for TYPE70PR caused no error, but was changed
VMACRMFV in WEEKBLD-MONTHBLD by adding LPARNUM LCPUADDR, so as to
VMACTMO2 be consistent with its VMAC.
VMACTMV2 -The BY list for TYPE30_6 could error, so it was changed
Jun 28, 1999 in WEEKBLD-MONTHBLD by inserting SYSTEM after JESNR so as
to be consistent with its VMAC.
-Typo WTY24 was changed to WTY25 in member VMAC25.
-Typo WTY8025 and WTY8X25 were changed to WTY8X24 in
member VMAC80A.
-Typo ZRBSDSIH was changed to ZRBBDSIH in VMACRMFV.
-Typo MONIDBD was changed to MONIDBDS in VMACTMO2.
-Type TMVSSSW was changed to TMVSYSSW in VMACTMV2.
Thanks to Fredie Arie, Lone Star Gas, USA.
Change 17.145 SYNCSORT variables COREREQ and COREUSED are now format as
VMACSYNC MGBYTES (to print KB/MB/GB etc), and their stored length
Jun 28, 1999 is increased from 4 to 8 bytes (because memory values of
16MB or larger cannot be stored exactly in 4 bytes).
If you use PROC APPEND to combine datasets with variables
of different length, you will get an error if you do not
specify FORCE, and even when you specify FORCE (which I
recommend: I think FORCE should be PROC APPEND's default)
you will still end up with the variables as 4-bytes. You
must recreate your "BASE" dataset with corrected lengths:
DATA BASE; LENGTH list-of-variables 8; SET BASE; and then
PROC APPEND won't fail and will have correct length 8.
The TYPESYNC variables that are now length 8 are:
SYNCAVLA SYNCAVLT SYNCREQT SYNCUSEA SYNCUSET SYNDSMVL
SYNVSCOR SYNVSCRT COREREQ COREUSED
Change 17.144 Cosmetic. The deaccumulation logic that was still in the
DIFFNTCP DIFFNTCP member was moved into the _SNTCPSY macro in the
Jun 28, 1999 VMACNTCP member; now, DIFFNTCP member invokes _SNTCPSY.
Change 17.143 The BY list was insufficiently specified and might not
VMAC42 remove duplicates for dataset TYPE42VL (variable SMF42VOL
Jun 24, 1999 was added to _BTY42VL), and for dataset TYPE74PA (macro
_BTY74PA has variables R742PTCN R742PDEV R742PODV added).
Thanks to Chuck Hopf, MBNA, USA.
Change 17.142 VMXGRMFI creates PDB.RMFINTRV with up to 115 workloads,
VMXGRMFI but had uninitialized and missing values if you used the
Jun 24, 1999 new WORKn= variables; those ommissions are now corrected.
-New option PDB=PDB or SMF lets you create RMFINTRV from
either an existing PDB library, or directly from SMF.
-Comments have examples of how to create new workloads:
%VMXGRMFI(WORK1=OMVS/OMVS/66 67/OMVS);
xxxx yyyy nn aaaa
where xxxx = prefix of the variable names to be created,
yyyy = prefix of the label of the created variables
nn = for Compatibility Mode: list of PERFGRPs
that make up this workload.
aaaa = for Goal Mode: list of Service Class Names
that make up this workload.
will create 17 variables named OMVSCPU,OMVSIOTM,... from
PERGRPS=66 or 67 or from SRVCLASS='OMVS' records.
Comments in the member show how you can invoke %VMXGRMFI
multiple times with different INTERVAL= values to create
multiple "RMFINTRV,RMFINTHR,RMFINTDY..." hourly, daily,
summary datasets in the same PDB library, and more.
Change 17.141 -The utility to create the SYSIN for a tailored BUILDPDB
UTILBLDP did not null the _Sdddddd sort macro when you suppressed
Jun 24, 1999 an SMF record. Also, while most product's ID macro name
Jul 9, 1999 is of the form _IDxxxx, a few members had the _xxxxID,
and these exceptions are now known by UTILBLDP logic,
so the correct macro name will be generated.
-We recommend that the ID macros for your user SMF records
be defined in member IMACKEEP, so that anyone running an
MXG TYPExxxx program will get the right records selected.
If you use UTILBLDP and specify USERADD=XXXX/NNN, it will
create the _ID macro, but if you use only USERADD=xxxx,
UTILBLDP will not generate an _ID macro for product xxxx,
and instead expects to find your _ID macro in IMACKEEP.
-A new parameter, IMACKEEP=, has been added, so you can
write all _IDxxxx and _xxxxID macro definitions to a
file, and then use that file as your IMACKEEP member, if
you have not already created the IMACKEEP definitions.
-New parameter RMFINTRV will suppress creation of RMFINTRV
dataset, and is used: if TYPE7072 is suppressed, RMFINTRV
won't be built and warning message will be printed; if
other datasets needed by RMFINTRV are suppressed, the
PDB.RMFINTRV will be built, but warning messages will be
printed on the SAS log.
-If TYPE70PR dataset is detected, ASUM70PR will be added.
-Only the _DIFFxxx's that exist will be created.
-USERADD=6, 30, or 26 caused BUILD005 to fail because the
datasets were deleted; now they are kept for BUILD005.
-IMACKEEP= option will create an IMACKEEP member with your
optional records added, etc.
Thanks to Simon Briggs, Allied Irish Bank, IRELAND.
Change 17.140 The PROC SORT of TYPE30_D had SMFTIME specified twice; in
VMAC30 the _BTY30UD macro and at the end of the BY statement.
Jun 24, 1999 This is not really an error, but now SAS Version 7 will
not permit repeats in the BY list, so the SMFTIME in the
BY statement was removed to satisfy SAS syntax.
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Thanks to Ed Powers, Pearson, USA.
Change 17.139 Documentation. One of the examples had a LIST; statement
SENDDATA that should have been after the FILE LOG; statement, but
Jun 23, 1999 it was after the FILE SMFOUT; statement.
Thanks to Solomon Baker, The Prudential, USA.
Change 17.138 Support for APAR OW37254 "Capacity Upgrade on Demand" for
VMAC7072 type 70 record (COMPATIBLE) adds flag variable STSICPC=Y
Jun 23, 1999 if the STSI facility is available for the CPC, and adds
CPCMODEL (CPC Model Identifier) to TYPE70PR dataset.
A "CPC" is a Central Processing Complex (previous IBM
name: "CEC" for Central Electronic Complex), for example,
a parallel enterprise server 9672 is a CPC, and variable
CPUTYPE='9672'X. An RX6 is a model of 9672, so the new
variable would contain CPCMODEL='RX6' in TYPE70PR.
Note: Change 18.258 added CPCMODEL to TYPE70 dataset.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 17.137 Format $MG039SN for type 39 Netview record has new value
FORMATS '5'='5:CP-CP' now created; the value is not new but had
Jun 23, 1999 been overlooked.
Thanks to Chris Taylor, Wachovia, USA.
Drove 990 miles to Telluride BlueGrass Festival, Telluride, Colorado.
Four days, forty groups, four hundred tunes - a great show!
Change 17.136 TCP TELNET Server variable TELLOGFT in dataset TYPETCPT
VMACTCP is created by IBM with date format of yyyydddF, which is
Jun 15, 1999 not supported by the SMFSTAMP8. format (which expects
Jul 29, 1999 the IBM SMF "century bit" format of 0cyydddF). With a
raw value 1999099F, SMFSTAMP8 creates year 3899 for date!
The SMFSTAMP8. input was replaced with the algorithm from
member YEAR2000 to support the unexpected date value.
Jul 29: Removed PUT TELLOGTM= ; debugging statement.
Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 17.135 Support for NETSPY type I Telnet Session record creates
EXNSPYTE new NSPYTELN dataset with written at interval and session
FORMATS end, with bytes in/out, smooth time, IP addresses and the
IMACNSPY LUNAME of the session.
VMACNSPY
VMXGINIT
Jun 10, 1999
Thanks to Stuart Robertson, GIO, AUSTRALIA.
Change 17.134 MXG message ERROR - STID=123 FOUND WITH SKIPPED FIELDS
VMAC110 is an MXG error. The statement SKIP=STILEN-100; in the
Jun 10, 1999 ELSE IF STID=123 THEN DO; must be SKIP=STILEN-104;
Thanks to Jean-Pierre Ravera, Michelin, FRANCE.
Change 17.133 Using TYPSCIMS caused errors (but TYPECIMS was okay).
VMACCIMS The _BIMFDB2 by-list macro must have PLANNAME instead
Jun 10, 1999 of DBDNAME, and variable DBDSEQNR must be added to the
KEEP= list for the CIMSDB2 dataset
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 17.132 Cosmetic. Temporary variables MNSMFTME and MXSMFTME are
VMACSMF now formatted DATETIME21.2, so they will be readable if
Jun 10, 1999 printed on the SAS log due to an error condition.
Change 17.131 If you used VMXGSUM with the NORM= argument to normalize
VMXGSUM values, and if the denominator was zero, you got DIVIDE
Jun 10, 1999 BY ZERO. Now, the divide is protected. No error was
reported; the exposure was observed and protected.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.130 RMM Extract EDGHSKP, support for its four date formats:
IMACEDGR Julian 1999/365 YYYY/DDD JULIAN7.
VMACEDGR ISO 1999/12/31 YYYY/MM/DD YYMMDD10.
Jun 9, 1999 European 31/12/1999 DD/MM/YYYY DDMMYY10.
Jun 24, 1999 American 12/31/1999 MM/DD/YYYY MMDDYY10.
Jun 29, 1999 is implemented in this revision. Originally, dates were
Jul 9, 1999 stored as character fields, and MXG 16.16 converted them
into date variables (so you can count number-of-days),
but MXG 16.16 only supported the ISO format. All four
date formats are now supported, but only JULIAN and ISO
are supported automatically, by default. So if your RMM
extract dates are European or American format, you must
update member IMACEDGR and change the default definition
of MACRO _EDGRDTE YYMMDD10. % to the desired format (or
you could put that redefinition in member IMACKEEP).
-RMM Extract Type='V' records (EDGHSKP utility) caused
INVALID DATA FOR RVLCDATE. MXG was off by 6 bytes. The
line with RVCFTIME $EBCDIC6. /*DSN*CREATE*TIME*/
must be deleted (it's decoded by the following HH/MM/SS).
-Variables RDRETDAT/RVRETDAT may contain a date, but can
be CYCL/nnnnn or WHILECATLG, so new variables RDRETCHR/
RVRETCHR now contain the character string of their date.
If the RDRETDAT/RVRETDAT are not valid dates, they will
be missing values, but RDRETCHR and RVRETCHR will
contain the original string value.
-Times are now calculated IF SS GE 0 THEN ... instead of
IF SS GT 0 THEN ... as zero is a valid value for SS; the
test is to protect if SS/HH/MM are missing, not zero.
-Variables RVSTBIN and RVOBIN are changed from character
to numberic, as they are bin numbers.
Thanks to Darlene E. Wnukowski, Schreiber Foods, Inc, USA.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.129 SAP R/2 5.0i under CICS 4.1 at one site created type 110
VMAC110 subtype 0 journal records with JCRLL=30, which was not
Jun 9, 1999 not expected nor protected in VMAC110 for 4.1, so the
three statements IF JCRUTRID='SA' THEN DO; are changed
to IF JCRUTRID='SA' AND JCRLL GE 250 THEN DO;
Thanks to W. Weber, V.I.S. Informationssysteme Gmbh, GERMANY.
Change 17.128 Utility to produce EBCDIC hex dumps under ASCII SAS was
UDUMPEBC enhanced with OUTPAGES= operand to limit the number of
Jun 9, 1999 pages printed. I needed this so I don't have to print
all 32760 bytes of a type 110 record if I don't need it!
Change 17.127 Support for APAR OW29849, which adds variables counting
VMAC88 writes and suspends by the system logger; this APAR also
Jun 9, 1999 improves the write performance of IXGWRITE by offloading
asynchronously to overlap I/O.
======Changes thru 17.126 were in MXG 17.03 dated Jun 8, 1999======
Change 17.126 Boole and Babbage has provided an enhancement to their
ASMMNVW MainView history file decompression SAS Infile Exit that
Jun 7, 1999 decompresses on the data on the fly. The new algorithm
supports both the original implementation as well as the
current compression implementation.
Change 17.125 Sample ANALPATH report expected no more than 16 LCUIDs on
ANALPATH on CHPID, and was revised in MXG 17.03 to handle up to 32
Jun 7, 1999 but the report was revised after 17.03 was built to only
Jun 9, 1999 print a line for LCU17-LCU32 if there were 17 LCUIDs.
Thanks to Bruce Koelker, Gates Rubber Company, USA.
Change 17.124 Support for TYPE 42 Subtypes 7 NFS File Usage and subtype
EXTY42NF 8 NFS User Session Statistics, creates new TYPE42NF and
EXTY42NU TYPE42NU. TYPE42NF File has only the end time; there is
FORMATS no OPEN/Start time, but includes counts in bytes and I/O
IMAC42 blocks. TYPE42NU User Session interval record has start
VMAC42 and session end times, elapsed/active durations, bytes
VMXGINIT read/written for network/files during the session. Both
Jun 5, 1999 TYPE42NF and TYPE42NU contain RACFUSER,RACFGRUP, the unix
Process and Group Ids, IP Address of the client host and
the client host name. Some field names in subtype 7 are
the same as existing subtype 15 field names, so some new
variables are named S42xxx instead of SMF42xxx. Two new
formats were added to decode NFS variables. These two
subtypes have existed since 1994, but no one noticed, as
they are only documented in "NFS Customization and Ops"
manual; they are not listed in the SMF manual!
Thanks to Mat J.H. Elbersen, Rabobank, THE NETHERLANDS.
Change 17.123 Support for SoftAudit Version 7.1 COMPATIBLY added the
VMACSFTA CPU Product Group and CPU Product Version variables to
Jun 4, 1999 the SOFTPROD Installed Products dataset.
Change 17.122 Support for STK's NearOAM V2.2 COMPATIBLY added variables
VMACNOAM like intercept and scheduling datetimestamps, the name of
Jun 4, 1999 the requesting job, name of the object, ... to TYPENOAM.
Thanks to Fiona Crane, Sun Alliance Insurance Group, ENGLAND.
Change 17.121 Variable SMF88AWB was mis-documented by IBM as RB8., but
VMAC88 it is a PIB8. Variable SMF88AIT was a character string,
Jun 4, 1999 but is actually a TODSTAMP value, so it is now decoded as
numeric and formatted as DATETIME21.2. The subtype 11
record has an observation written at the end of each
interval with blank SMF88STN (structure name), with only
SMF88ALS (log streams connnected at end of interval).
The TYPE8811 dataset now has variable SMF88LTD (interval
end datetimestamp) kept from the preceding subtype one,
since there is no interval end value in TYPE8811. Also,
there is no interval start nor interval duration in the
subtype 1, so the rates cannot be calculated without an
extra de-accumulation step to construct the duration of
the interval. Pending IBM's reply as to whether they
will correct the problem, and due to overwhelming nonuse
thus far, I have not added deacculumulation yet.
Since SMF88LTD is on the GMT clock and since there is no
GMT offset in the record, the times cannot be converted
to local time of day.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.120 For Goal Mode (a/k/a Workload Manager Mode), the PERFGRP
VMAC30 variable had value of zero in type 30s but missing in 72
Jun 2, 1999 so it is now set missing in type 30s, so it won't be
confused with Compat Mode PERFGRP=0, and so that BY lists
can contain PERFGRP SRVCLASS to merge step interval data
with either TYPE72 or TYPE72GO data. To know from the
job's TYPE30s/PDB.JOBS datasets if a job ran under Goal
Mode or under Compat Mode, you can now test IF PERFGRP=.
(or alternatively, IF SRVCLASS GT ' ') and both are true
for Goal Mode) and both are false if Compat mode.
Change 17.119 SyncSort supports up to 32 sort work areas, but MXG had
VMACSYNC only decoded the first twelve. Now all thirty-two sets
Jun 2, 1999 of the eight variables are created for all possible.
Thanks to Chairat Tiajanpan, KTB, THAILAND.
Change 17.118 Minor cleanup. The default DDNAME for the CIMSTEMP
TYPSCIMS temporary dataset is now //WORK instead of //PDB, and
VMXGINIT member TYPSCIMS now invokes _S macros to sort the
Jun 1, 1999 CIMSDBDS, CIMSDB2, and CIMSPROG datasets into the default
ddname of PDB.
Thanks to Carl Meredith, SAS Institute, USA.
Change 17.117 Sample RACF Violation reports, originally posted on MXG-L
ANAL80A use the TYPE80A and TYPE8002 datasets for reports.
May 31, 1999
Thanks to Brian Cavanaugh, Key Services Corporation, USA.
Thanks to Sean Sullivan, Key Services Corporation, USA.
Change 17.116 Support for APAR OW37091 for Measured Usage (MULC) adds
VMAC89 support for Concurrent CP Upgrades ("the capability to
May 31, 1999 increase the number of usable CPs without requiring a
hardware IML or operating system IPL"). New fields are
added to the ID section, so they are kept in both usage
and state datasets: Type/Model/Manufacturer/Plant/etc,
counts of the configured and standby CPUs, and the value
of SMF89CPC, the "CPU Capability" value, an integer that
specifies the CPU capability of one engine. While there
is no formal description of the algorithm used to create
the value, CPU Capability Value is used as an indication
of the capability of this CPU relative to the capability
of other CPU models. Then to adjust that single engine
Capability value to get the actual value for your number
of CPs in use, you use the Multiprocessing CPU Capability
Adjustment Factor for that number of CPs. There are up
to fifteen factors, each containing the percentage of the
single engine CPU capability for that number of CPs: MXG
variable SMF89MA1 contains the percentage for 2CPs, and
SMF80MAF contains the percentage if there are 16CPs. The
new information comes from the Store System Information
Instruction (STSI).
Change 17.115 IMF/CIMSTRAN variable FLGSPCHR decoded 'W' for WFI, but
FORMATS did not know that value 'Q', documented as "Pseudo WFI",
VMACCIMS but also called Quick Restart, exists also. Now the MXG
May 31, 1999 format MGIMFCS decodes both Q and W in FLGSPCHR.
Thanks to Ulrich Dillenberger, BMC Software, GERMANY.
Change 17.114 Change 17.037 was wrong for TANDDISK for TANDEM G05 plus.
VMACTAND Two IF OPSYSVER GE ... should end with "@;", not "END;".
May 28, 1999 The ERROR message is INVALID DATA FOR END ....
If you pull the data files from the Tandem System using
UserAccess - Stream Mode, you get the "unstructured" file
format discussed in Change 15.119, and you will have to
EDIT and use the UTANDSTR utility to double process the
records to create the "structured" records to be read.
Change 17.113 Variables SMF6PRMD (Print Mode) and SMF6USID (User) are
BUILD005 now carried into the PDB.PRINT dataset in BUILDPDB/PD3
BUIL3005 logic, by adding them to the _PDB6 list of variables to
May 28, 1999 be kept from TYPE6 into PDB.PRINT.
Thanks to Bob Falla, The Mutual Group, CANADA.
Change 17.112 MXG 17.02 only, cosmetic. WARNING: NOT ALL VARIABLES
VMAC80A KW24MO00-KW24MO50 WERE FOUND is eliminated by changing
May 27, 1999 KW24MO50 to KW24MO18 in the KEEP= list, but there was no
impact of this warning, as there were only 18 to keep.
Thanks to Jos Schwab, Newell Company, USA.
Change 17.111 Variables TAPEDRVS/TAPE3420/TAPE3480/TAPE3490/TAPE3590 in
BUIL3005 observations in TYPE30_V, TYPE30_4 and TYPE30_5 datasets
BUILD005 count only the number of tape devices allocated in each
EXTY30TD physical step record, and that is still true after this
FORMATS change. But this redesign in BUILD005/BUIL3005 will now
IMAC30 count the number of unique tape drive addresses that were
SPUNJOBS allocated by the step (across all multiple records) in
VMAC30 those TAPExxxx variables in the PDB.STEPS dataset.
VMXGINIT Note, however, that even the corrected TAPExxxx count for
May 27, 1999 the step is not necessarily the number of concurrent tape
Jun 7, 1999 drives that were used by the step, but is just the total
number of drives allocated by the step: you cannot tell
from the step data whether those allocations were
sequential or concurrent. In addition to changes in the
BUILD005/BUIL3005 members, a new "temporary" dataset
WORK.TYPE30TD is created by VMAC30, with one observation
for each tape DD segment, that is used to correctly count
tape drives. This also required a new SPIN.SPIN30TD
dataset to hold these new data for incomplete jobs, and
revisions to member SPUNJOBS, as well as logic to convert
spun Step records tape drive counts to the new design.
And macros _S30 and _N30 were corrected in member VMAC30
so they include TY30UD and TY30UV datasets that had been
overlooked.
Note 10/19/2000: The TAPEDRVS/TAPExxx variables were
removed from the SPINxxxx datasets (because they were the
old, probably wrong values), and were relocated into the
SPIN30TD dataset (tape allocation count by DEVNR) that
will be used tomorrow to put TAPEDRVS/TAPExxxx variables
back in the output PDB.STEPS and PDB.JOBS.
Change 17.110 Variables EXCPNODD/IOTMNODD are now corrected, and the
BUILD005 observations with MULTIDD='Y' in PDB.STEPS dataset will
BUIL3005 no longer exist (although they still will exist in the
SPUNJOBS TYPE30_4 and TYPE30_5 datasets). Instead of there being
May 25, 1999 multiple observations for those steps, there now is only
one observation for each step in PDB.STEPS, so the number
of observations in PDB.STEPS will be reduced by this fix.
This redesign sums the STEP I/O counts from the multiple
step records to create only one observation per step, and
it re-calculates the NODD "Not Recorded in a DD" values.
Previously, the NODD numbers were TOTL - TODD, but when
the step had MULTIDD='Y' records, the TODD counts in the
"real" step record (the one with MULTIDD=' ') did not
include the TODD counts from the MULTIDD='Y' records, so
the NODD values in the MULTIDD=' ' observation were too
high, and the NODD values in the MULTIDD='Y' observation
were missing (because the TOTL values exist only in the
MULTIDD=' ' record). The values of the NODD variables in
the PDB.JOBS dataset were also incorrect, because they
were sums of the incorrect NODD values from PDB.STEPS.
This internal redesign splits the STEPS dataset into
STEPS and STEPSIO, with all EXCP/IOTM counts in STEPSIO,
which is VMXGSUM'd and merged to re-created STEPS with
NODD calculations now based on the TODD sum from all
records, and so there is no longer any need to create the
MULTIDD='Y' observations in the PDB.STEPS dataset.
This change was precipitated by the analysis of a step
record from TSO-in-batch that executed DB2 that had very
large values for EXCPNODD and IOTMNODD. The large NODD
counts were completely valid, had nothing to do with any
MULTIDD='Y' steps, and in fact were caused a design flaw
in the site's DB2 QMF exit that caused repeated loads of
the same module from a linklist library, and all linklist
accesses are captured by the NODD counts.
But before I knew that, I had asked Chuck Hopf to scan
his PDB for executions under TSO that called DB2 to see
if DB2 might be involved in high NODD counts. While his
data proved high NODD counts were not DB2 related, he did
serendipitously find MULTIDD='Y' steps with the incorrect
NODD counts that led to this redesign.
Thanks to Kirk Hampton, Texas Utilities, USA.
Change 17.109 Typo and a logic error that have been in VMXGHSM for some
VMXGHSM time were detected and corrected. The corrections:
May 25, 1999 IF MCPDGNCT=. THEN MCPDGNCT=0 instead of MCTDGNCT, and
P2=P2+14; instead of P2=P2+(14C);
Thanks to Neville Wright, TELSTRA, AUSTRALIA.
Change 17.108 Type 39 records may cause SHORT RECORD messages and zero
VMAC39 observations output, depending on APARs you have applied,
May 21, 1999 because Change 16.258 was incorrect.
The ELSE DO; group must be relocated to be before the
first "IF OFFPROD-3-COL+1 GE 8 THEN INPUT" statement.
And APPN fields may be incorrect, because the INPUT after
the second "IF OFFPROD-3..." statement should have offset
values of @61, @65, and @67 vice @53/@57/@59.
Thanks to Jim Tintle, Mack Trucks, USA.
Change 17.107 Support for OS/400 V4.3.0 (compatible) was in MXG 16.16,
VMACQAPM as a comparison of the 4.3 and 4.2 record formats found
May 21, 1999 no changes.
Change 17.106 PDB.ASUMTAPE observations with STATUS='MISSEDMNT' due to
ASUMTAPE to the fuzzyness of sampled mount times in MXGTMNT are
May 20, 1999 now STATUS='MATCHED', by changing the TYPETMNT timestamp
used in sorting the Allocate, Mount, and Dismount events.
The problem is that the timestamp of the TYPE21 record
is exact, whereas the TMNTTIME/TENDTIME (mount start and
mount end times) are up to 2 seconds later (with MXGTMNT
sampling default value) than their real event time.
Using TENDTIME gave good results, but when TENDTIME was
later than TY21TIME, the sequence was A/D/M and the mount
was missed. By using SMFTIME=MAX(TMNTTIME,TENDTIME-2),
in the step that creates MOUNT dataset, those now match.
-Status of known causes of STATUS='MISSEDMNT':
-tape ape "knocking-down" the outstanding mount for a
specific volser by mounting the wrong VOLSER, perhaps
by accident, perhaps intentionally so that the message
"Mount Pending For 10 Minutes" won't be created, which
stops the MVS console operator from harrasing tape ape.
Tape apes know they can put in any VOLSER and that MVS
Volume Verification will reject and dismount the wrong
tape (so the job doesn't fail) and that the new mount
event for the original VOLSER resets mount pending!
In this case, MXGTMNT still was in mount pending state,
so the second mount does not reset the TMNTTIME start of
mount pending, but the TENDTIME end of mount does not
occur until after the bad mount was dismounted and the
correct VOLSER was verified, so the TY21TIME is in the
middle of the mount start and end times:
Wrong Vol Right Vol
TMNTTIME TY21TIME TENDTIME TY21TIME
10:50:51.26 10:52:15.96 10:52:39.00 10:58:29.11
ASUMTAPE creates an observation for the dismount of the
wrong volume with STATUS=MISSEDMNT, but I can't yet see
how to status that mount as a "wrong volume mount", or
even if that is needed! ASUMTAPE also creates the real
observation for the mount of the right volume, and its
TAPMNTTM=TENDTIME-TMNTTIME does include all of the delay
caused by mounting-the-wrong-volume, because the real
mount (and this job) is still pending until the correct
VOLSER is mounted).
-one mount of a tape by one job that was not used but the
tape was then picked up (without a new mount event, as
the tape was in the drive) by a second job. The first
mount is output to EXTRAMNT dataset rather than ASUMTAPE
and the second job has ASUMTAPE obs with MISSEDMNT.
-tape swap (an I/O error caused your VOLSER to be moved
to a different physical tape drive) creates an extra
mount event for each swap, and MXG properly creates an
obs in ASUMTAPE, so these mounts are true, counted mount
events, but they were not caused by the job.
-I may investigate if a further post-processing step is
needed to merge TYPETSWP to identify mounts caused by
tape swaps, to detect passing of an unused tape from one
job to another, or to identify "kicked-down" mounts.
-Note that observations in PDB.ASUMTAPE with MISSEDMNT for
STATUS are still completely valid tape mount events, with
true dismount time, bytes, etc,; it just that the start
and end of tape mount time are not known because there
was no MXGTMNT mount event found.
Change 17.105 TYPE39 variable LSESFQLN should have been &PIB.1. instead
VMAC39 of &PIB.2., which caused LSESFQNM to be missing its first
May 20, 1999 byte.
Thanks to Anthony Pagliano, Summit Bank, USA.
======Changes thru 17.104 were in MXG 17.02 dated May 19, 1999======
Change 17.104 DF/SMS 1.4 additional variables UMUSRSIZ, UMCMPSIZ, and
VMACDCOL UMFRVOL may be missing because the tests for existence
May 19, 1999 should have been GE 8 for the first two, and GE 20 for
the DO group for UMFRVOL.
Thanks to Dave Cogar, U.S. Department of Transportion, USA.
Change 17.103 TCP records for APICALLS have invalid APISTART values
VMACTCP in the IBM record. While contacting IBM, the INPUT was
May 19, 1999 changed to APISTART ?? SMFSTAMP8., inserting the double
question marks to suppress the error message and dump.
Nov 3, 1999 update: APAR PW29974 and PQ32322 document
negative values for APICALLS bytes in and bytes out.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch Companies, USA.
Change 17.102 TMS variable DEVTYPE was blank for 3490-E tape volumes;
VMACTMS5 a new test IF TRTCH=0E1X THEN DEVTYPE='36TRK-E'; was
May 18, 1999 added to decode them.
Thanks to Sal Fazzino, Excelis, Inc, USA.
Change 17.101 Support for NTSMF Version 2.3 (COMPATIBLE), and support
EXNTSQAM for new Seagate, Site Server, and SQLSERVER 7 objects:
EXNTSQBD
EXNTSQBM Dataset Object Name Vars
EXNTSQCM
EXNTSQDA QUOTAS QUOTAS 5
EXNTSQGS SEAGATE SEAGATE INFO 13
EXNTSQLA SITESVAU SITE SERVER AUTHENTICATION SERVICE 32
EXNTSQLO SITESVCO SITE SERVER CONTENT DEPLOYMENT 34
EXNTSQMM SITESVLD SITE SERVER LDAP SERVICE 86
EXNTSQRA SITESVMB SITE SERVER MESSAGE BUILDER SERVICE 7
EXNTSQRD SQLACCES NT SQLSERVER7 ACCESS METHODS 20
EXNTSQRL SQLBKPDV NT SQLSERVER7 BACKUP DEVICE 1
EXNTSQRM SQLBUFMG NT SQLSERVER7 BUFFER MANAGER 18
EXNTSQRS SQLCACMG NT SQLSERVER7 CACHE MANAGER 5
EXNTSQSE SQLDATAB NT SQLSERVER7 DATABASES 22
EXNTSQSS SQLGENST NT SQLSERVER7 GENERAL STATISTICS 3
FORMATS SQLLATCH NT SQLSERVER7 LATCHES 4
IMACNTSM SQLLOCK NT SQLSERVER7 LOCKS 6
VMACNTSM SQLMEMMG NT SQLSERVER7 MEMORY MANAGER 14
VMXGINIT SQLREPAG NT SQLSERVER7 REPLICATION AGENTS 1
May 17, 1999 SQLREPDI NT SQLSERVER7 REPLICATION DIST. 3
SQLREPLR NT SQLSERVER7 REPLICATION LOGREADER 3
SQLREPME NT SQLSERVER7 REPLICATION MERGE 3
SQLREPSN NT SQLSERVER7 REPLICATION SNAPSHOT 2
SQLSTATS NT SQLSERVER7 SQL STATISTICS 7
SQLUSRSE NT SQLSERVER7 USER SETTABLE 1
Only dataset QUOTAS has been data-tested, but there is a
lot of new NT measurements in this change!
-Additionally, the WEBSERVR dataset is now deaccumulated,
as suggested by Jim Quigley's posting to MXG-L LISTSERV.
These IIS counters are accumulated in NT 4.0, but are
supposedly corrected in NT 2000, so the deaccumulation
(done in the _SNTWEBS sort macro, where all DIF() code
is now located) may need to be suppressed in NT 2000.
Change 17.100 Support of i-data afp-software SMF record. The dataset
EXTYIDAP TYPEIDAP has counters of pages and bytes printed by
FORMATS i-data, for distributing AFP print thru the enterprise
IMACIDAP network, using commodity laser printers.
TYPEIDAP See their homepage at www.i-data.com.
TYPSIDAP
VMACIDAP
VMXGINIT
May 15, 1999
Thanks to Engelbert Smets, Provinzial Versicherungen Duessl,GERMANY.
Change 17.099 Support of Lexmark MarkVision "job statistics file" for
EXTYMRKV printing on Windows, OS/2 and Windows-NT platforms. The
FORMATS dataset MARKVISN created counts sheets and impressions,
IMACMRKV by treys and feeders and by auto and manual and by color
TYPEMRKV of toner. Each observation is either a successful print
TYPSMRKV or an error condition (in which case varible ERROR will
VMACMRKV be blank and most fields will be missing. This code has
VMXGINIT only been tested executing under ASCII reading ASCII data
May 14, 1999 but the program should work under EBCDIC reading the raw
datafile that were sent to MVS (and converted to EBCDIC).
Thanks to Martin Laursen, Danske Data, DENMARK.
Change 17.098 Enhanced creation of RMFINTRV now permits over 100 unique
VMXGRMFI workloads to be defined.
May 14, 1999
Change 17.097 MXG 17.01 only. Some dataset names for AICS and APAF
VMACAICS were misspelled in their _Wdddddd macro definition (but
VMACAPAF if you used the _Sdddddd or TYPSxxxx member to sort from
May 14, 1999 //WORK to the //PDB, there was no error).
Thanks to Freddie Arie, TXU, USA.
Change 17.096 Support for CICS TS 1.2 Journal segment for SAP. CICS TS
VMAC110 1.2 has two different formats of Journal data in SMF 110,
VMXGINIT and only GLRHTYPE=1 was previously validated, but now the
May 14, 1999 GLRHTYPE=2 segment (which happens to be used by SAP) are
May 17, 1999 recognized and decoded, eliminating "SOR TYPE NOT ONE"
MXG error message and hex dump of the record.
This change also corrected a 17.01-only error: the macro
&WCICACC was repeated inside other _WCICxxx definitions,
and &WCICJRN is now defined in VMXGINIT.
Thanks to Roy Pennington, Vertex, ENGLAND.
Change 17.095 In an undocumented, verbal change to SYNCSORT records,
VMACSYNC new variable MAXSORT='Y' or blank if the MAXSORT option
May 13, 1999 was specified for a sort.
Thanks to John Parla, Cigna, USA.
Change 17.094 Extensive additional decoding of RACF bit flags create
FORMATS new one-byte character variables to identify the keywords
VMAC80A specified, keywords ignored, keywords in error, and many
May 13, 1999 other options of RACF events. Since each RACF command
has a unique set of keywords, and there can be many in
each single record, the naming convention and variable
labels convey the keyword specified/ignored etc. The
naming convention is KWnnSPmm for Specified Keywords,
KWnnIGmm for Ignored Keywords, and similar names for
other options, class names, and other flags. For example
the TYPE8019 (PERMIT) command has fourteen keyword
specification variables, named KW19SP00-KW19SP13,
and the corresponding keyword ignored variables are
named KW19IG00-KW19IG13:
KW19SP00='KEYWORD*SPECIFIED*CLASS?'
KW19SP01='KEYWORD*SPECIFIED*ID?'
KW19SP02='KEYWORD*SPECIFIED*ACCESS?'
KW19SP03='KEYWORD*SPECIFIED*FROM?'
KW19SP04='KEYWORD*SPECIFIED*DELETE?'
KW19SP05='KEYWORD*SPECIFIED*FCLASS?'
KW19SP06='KEYWORD*SPECIFIED*VOLUME?'
KW19SP07='KEYWORD*SPECIFIED*FVOLUME?'
KW19SP08='KEYWORD*SPECIFIED*GENERIC?'
KW19SP09='KEYWORD*SPECIFIED*FGENERIC?'
KW19SP10='KEYWORD*SPECIFIED*RESET?'
KW19SP11='KEYWORD*SPECIFIED*WHEN?'
KW19SP12='KEYWORD*SPECIFIED*RESET(WHEN)?'
KW19SP13='KEYWORD*SPECIFIED*RESET(STANDARD)?'
KW19IG00='KEYWORD*IGNORED*CLASS?'
KW19IG01='KEYWORD*IGNORED*ID?'
...
KW19IG13='KEYWORD*IGNORED*RESET(STANDARD)?'
About 800 new variables are created, with a max of 205 in
one dataset (TYPE8024), but at one byte per variable, the
impact is minimal. If you use PROC PRINT SPLIT='*', the
variable label prints as column heading and you can see
which keywords were specified/ignored/errored/etc. You
can look at member DOCVER to see what variable name is
created for each keyword, or you can use PROC CONTENTS to
see the label, but the variable label names the contents.
This code has NOT been validated, and there was lot's of
opportunity for typos, so please verify with known RACF
events that all of the bits are mapped correctly.
-One new format was added and old one enhanced.
Thanks to Michael Brench, National Bank of Australia, AUSTRALIA.
Change 17.093 The LRECL=xxx value for each Tandem file was specified on
VMACTAND each INFILE statement, but that was removed so that you
May 11, 1999 don't have to modify the VMAC for new Tandem versions;
instead you can use the LRECL of the dataset on MVS or
a FILENAME statement with LRECL=xxx to specify the LRECL.
Thanks to Kim S. Johnson, NationsBank, USA.
Change 17.092 Support for SOFTAUDIT 6.1.2 (COMPATIBLE) added three new
VMACSFTA fields at the end of the Installed Products File.
May 11, 1999
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY
Change 17.091 Support for TELEVIEW 4.3 (INCOMPATIBLE). Field TELUSER
VMACTELE was expanded to 9 bytes and 3 bytes were inserted in the
May 10, 1999 subtype 1 and subtype 2 record. In addition, while the
May 18, 1999 variable SMFTIME has been accurate, none of the internal
datetimestamps were validated and all were wrong, but now
are corrected and Y2K compliant!
Thanks to Yvonne McDonough, USDA NITC, USA.
Change 17.090 Some QXxxxxxx variables in DB2STATS were misaligned and
VMACDB2 wrong, starting with QXRLFDPA. The stat code was revised
May 10, 1999 and the line with +4 after QXDEGENC was replaced with the
input of QXRLFDPA and its associated +3, and the tests
for length were corrected: the 256 to 252, 284 to 280,
and 316 to 312. Only DB2STATS was affected; the QXxxxxxx
variables in DB2ACCT were not misaligned.
Thanks to Ken Michalik, Kraft Foods, Inc, USA.
Change 17.089 Unused.
Change 17.088 Variable BANDTIME in NPM dataset NPMINNSA is missing.
VMAC28 The equation should be BANDTIME=DHMS( ... BANDTTME);
May 10, 1999 instead of the typo BANDTIME=DHMS( ... BANDTIME);.
Thanks to Mr. Holscher, BWS Munster, GERMANY
Change 17.087 Documentation. If your DB2 datasets are on tape, you
ANALDB2R must specify DATASET=DDNAME, arguments and PDB=PDB to
May 6, 1999 prevent TWO OPEN SEQUENTIAL DATASETS ON ONE TAPE error.
If your DB2ACCT, DB2ACCTP, and DB2ACCTB datasets are on
tapes with DDNAMES of DB2ACCT, DB2ACCTP, and DB2ACCTB,
then you would specify
%ANALDB2R(
PDB=PDB,
DB2ACCT=DB2ACCT,
DB2ACCTB=DB2ACCTB,
DB2ACCTP=DB2ACCTP,
... );
The documentation in the comments has been revised;
the code has been in place since version 14.14!
Thanks to Alan Fendler, Pershing, USA.
Thanks to Harold Wentz, Pershing, USA.
Change 17.086 The DCOLLECT example had LRECL=644 in comments, but you
JCLDAYDS must specify LRECL=32756. With LRECL=644, DCOLLECT sets
May 6, 1999 a Return Code of 4 and a message that it encountered a
record that was too long to process, but does not ABEND,
and some of the records are not created. (Fortunately,
the long records are the SMS structure definitions for
Storage Class, Storage Group, etc., rather than the real
Dataset and Cluster records used for accounting/sizing.
Thanks to Chuck Hopf, MBNA, USA.
Change 17.085 Support for RACAL IT Security's SRM product for HSM SMF
EXSRMHAP record creates three new datasets:
EXSRMHDV SRMHSMAP SRM HOST SECURITY MODULE APPL
EXSRMHNU SRMHSMDV SRM HOST SECURITY MODULE DEVICE
FORMATS SRMHSMNU SRM HOST SECURITY NULL RECORD
TYPESRMH The Null Record dataset is created from records that have
TYPSSRMH no Device nor Application segment, just a 36-byte record;
VMACSRMH it is not clear of what use they may be.
VMXGINIT
May 6, 1999
Thanks to Choo Hui Chuin, Maybank, MALAYSIA.
Change 17.084 -The %INCLUDE of IMACIMSA should have been just before the
TYPEIMSA MACRO _VARxxxx definition, and has been moved, but there
VMACIMSA was no error since IMACIMSA is re-included by TYPEIMSA.
May 15, 1999 -The _KIMSBMP macro was added to the step that builds the
BMPS dataset so that full tailoring is supported.
Thanks to Chris Weston, SAS Institute, USA.
Change 17.083 The label for variable STRTTIME was changed to INTERVAL
VMAC25 START TIMESTAMP because in BUILDPD3, the type 25 label
May 4, 1999 was overriding the CICS and other Interval datasets.
I should have chosen a different name for the JES3 TYPE25
dataset, but its too late for that now, but changing its
label will eliminate the JES3 confusion.
Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 17.082 DATASET PDB.TYPE200 NOT FOUND results when TYPSIDMS is
VMACIDMS used; the four lines _STY200, _STY201, _STY202, _STY203
May 4, 1999 are deleted as the TYPE200 members were IDMS 10.2 only.
Thanks to Alan Deepe, Perot Systems Europe, ENGLAND.
Change 17.081 The invocation of the sort macro, _STMVS, should have
TYPSTMV2 been spelled _STMV2 in member TYPSTMV2.
May 4, 1999
Thanks to Kathy Gordon, General Nutrition, Inc, USA.
Change 17.080 Comments only were changed, on how to handle CADI record
IMACCADI with ID=239 instead of ID=6. Those comments are now the
May 4, 1999 MXG Note Example of using IMACFILE to change ID number.
Thanks to Bob Cooney,
======Changes thru 17.079 were in MXG 17.01 dated May 3, 1999======
Change 17.079 Yet another enhancement to the UTILBLDP utility that will
UTILBLDP create the //SYSIN file BUILDMXG to build your tailored
May 1, 1999 PDB. This iteration detects if CICS, DB2, TMNT, or TY74
May 14, 1999 data was requested, and if the ASUM member appropriate to
that data are not included, they will be added with a new
comment "/*RECOMMENDED*/". New options to run BUILDMXG
instead of creating the file, INCLAFTR= to name members
to be included after BUILDMXG runs, and SPINUOW to pass
the SPIN count for ASUMUOW build, if requested.
Change 17.078 Change 17.029 was also needed in MONTHBLD; two lines with
MONTHBLD non-blank character in column 72 caused failure, even tho
May 1, 1999 the syntax should be valid.
Thanks to David Gibney, Washington State University, USA.
Change 17.077 Chuck discovered that some PDB.ASUMTAPE observations with
ASUMTAPE STATUS=MISSEDMNT had TMNTTIME incorrect and traced some
May 3, 1999 to be caused by "multi-unit,never-used" tape mounts:
May 20, 1999 Using UNIT=(TAPE,2) allocates two tape drives, and
See 17.106 two scratch tapes will be initially mounted. When a
volume fills, writes switch to the second drive while
a new tape is mounted on the first drive, so at CLOSE
of the DDNAME, there will always be a hanging mount
that was never used and never opened. But MXGTMNT
saw that mount, and at deallocation time it writes the
SMF record with the actual (earlier) mount start and
end times; MXG sets VOLSER='UNKNWN' because without an
OPEN, the VOLSER is unknown. And IBM's type 21 SMF
record contains blanks for VOLSER for the dismount!
This and other discoveries led to revisions in internal
algorithms in ASUMTAPE, described below, but there was
no error in the number of observations in PDB.ASUMTAPE.
Some obs that previously had STATUS='MISSEDMNT' will now
be MATCHED, and a few will now be STATUS='WRONGVOL'.
-The VOLSER=UNKNWN mount records are no longer discarded.
They are for those "multi-unit,never-used" mounts in
which the MXGTMNT monitor is still waiting for a VOLSER,
and their type 21 record has blanks for volser.
-The "sorttime" used for MOUNT records is now based on the
end of mount timestamp, TENDTIME, moved two seconds back
to account for the MXGTMNT timer pop, but not moved back
before the start of the mount timestamp, TMNTTIME:
sorttime = MAX(TMNTTIME,TENDTIME-2);
These choices for sort order were tested:
TMNTTIME - start of mount (sampled) timestamp. Used
early, but found to cause many MISSEDMNT
events, correcting moved it before ALOCSTRT
so TENDTIME was used in 17.01/17.02.
TENDTIME - end of mount (sampled) timestamp. Used
in 17.01 and 17.02, revised above in 17.03.
Without subtraction, a few were found with
TENDTIME after the TY21TIME, which created
MISSEDMNT events, but the 2 second pop now
sorts the mount record before the dismount,
and the MAX(TMNTTIME) ensures the it will
not be shifted to earlier than TMNTTIME (as
that could put the mount before allocate).
SMFTIME - when record written, can be after TENDTIME,
eg., for "multi-unit,never-used" mounts
whose SMF records are written at (sampled)
deallocate time, so SMFTIME can even be
after TY21TIME.
-Some MISSEDMNTs had mount records, but their mounts had
been discarded due to missing JESNR, which was used to
recognizing a new JOB. I have revised that logic to not
require JESNR, and thus can keep those mount records.
-Some MISSEDMNTs are for "start-up effect missed-mounts"
whose mount had occurred before the begin time of the SMF
file (ALOCSTRT earlier than the first dismount), but they
occur on the first day's run of ASUMTAPE and are
eliminated when the SPIN library takes effect on the
second run.
-Some MISSEDMNTs are now STATUS=TY21ONLY, because the test
is now IF ALOCSTRT LE TY21TIME LE ALOCEND THEN (added
test for ALOCEND) so that 21s with times after the end of
the held alloc record are recognized.
-Some MISSEDMNTs are now STATUS=WRONGVOL, because I found
I can recognize many instances of the operator putting in
(intentionally) an incorrect volume (when he/she cannot
find the correct volser, the stick in any tape to knock
down the outstanding mount message).
-Some remaining MISSEDMNTs in non-VTS environment are the
result of allocation recoveries when allocation switching
occurs; sometimes the mount was seen but the wrong job
name was put in the mount record so the mount did not
match up. A new version of MXGTMNT is in testing that
may be able to detect this state and correct or eliminate
those bad mount records.
-This revision now matched 13,822 tape mounts, found 5
WRONGVOL, 26 TY21ONLY, and only 24 are now MISSEDMNTs!
Thanks to Chuck Hopf, MBNA, USA.
Change 17.076 Type 73 with APAR OW15406 (IODF date expanded to YYYY)
VMAC73 and first 17.01 printed debugging lines on the SAS log:
May 1, 1999 YYYY IODFTIME=25MAR1999:08:24:18.00 _N_= ....
because the PUT statement had not been deleted.
Thanks to MP Welch, SPRINT, USA.
Change 17.075 The SORT order in these examples did not include SYSPLEX
ANALMTP variable in the PLOTs of TYPE70 and RMFINTRV, causing
ANALMPL a NOT SORTED error. SYSPLEX was added to RMF sort order
Apr 30, 1999 in MXG Change 16.288 but these examples were overlooked.
Thanks to MP Welch, SPRINT, USA.
Change 17.074 EXCP/IOTM variables did not exist in TYPE434 because the
VMAC434 "%INCLUDE SOURCLIB(IMAC434);" statement should have been
Apr 30, 1999 "%INCLUDE SOURCLIB(IMAC30IO,IMAC434);". This error was
introduced in the MXG 16.04 redesign.
Thanks to Mike Hoey, Ameren Services Corporation, USA.
======Changes thru 17.073 were in MXG 17.01 dated Apr 29, 1999======
Change 17.073 -SAS Version 7 causes error message on SYSMSG that options
AUTOEXEC CODEPCT and BLKSIZE(TAPE) are not supported in V7, but
CONFIGV7 there a return code of zero is set, so there is no real
Apr 28, 1999 error condition. To eliminate those messages, however,
new CONFIGV7 member exists and it can be used instead of
CONFIG in your MXG SAS JCL procedure. (Note that members
CONFIG, CONFIG07 and CONFIG08 are identical, and they are
for SAS Version 6.07 thru 6.09.).
Note: Feb 17, 2000: Members CONFIGV8 and CONFIGV7 are
the same and eliminate warning messages on the SAS log
with SAS Version 8.
-For ASCII execution, member AUTOEXEC is the equivalent of
CONFIG and it has been updated to pass the same options
for ASCII MXG execution as are set by CONFIGV7 for MVS.
Change 17.072 ANALDALY's sort order had not been updated to include the
ANALDALY SYSPLEX variable (BY SYSPLEX SYSTEM STARTIME), causing a
Apr 28, 1999 NOT SORTED error message.
Thanks to MP Welch, SPRINT, USA.
Change 17.071 Duplicate obs were detected and deleted from MQMACCT data
VMAC116 set (type 116 MQ-series accounting) because identical 116
Apr 28, 1999 records are created, in pairs and triplets (284 removed
of 24,000). The sort macro _BTY116 was expanded to hold
the full set of unique variables, but each observation is
from a different SMF record, so variable SMFRECNR was
added to the KEEP list, so that no records are duplicates
and so none are deleted by the SORT. (TYPE116 does not
sort, so it deleted no observations; only if you used the
TYPS116 member or the _S116 or _Sty116 macros were dupes
removed.) Further investigation with IBM is planned.
Note added Feb 18, 2000: While SMFRECNR was added to the
KEEP= list for dataset MQMACCT, it was not added to the
BY-list macro, because it would prevent removal of dupes
that came in two different SMF-reading jobs. See the
sort revisions in Change 18.001 and discussion there.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 17.070 Using ANALCNCR to count concurrency failed if the values
ANALCNCR for start or end were missing. ANALCNCR now deletes any
Apr 28, 1999 input observations with missing timestamps (and reports
how many if any were found).
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 17.069 Thirty-nine instances of "&NUM.2 "
VMACEDGR were changed to "&NUM.2. "
Apr 28, 1999 Retention Date field RDRETDAT can contain "WHILECATLG"
as date value; that string is now reported and new MXG
variable RDWILCAT='Y' and RDRETDAT will be missing.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.068 Change 16.078 increased variables CSTORE and ESTORE in
RMFINTRV dataset TYPE71 to eight bytes stored length, but RMFINTRV
Apr 28, 1999 had the variables in the new LENGTH 8 and in the old
LENGTH 4 statement; remove them from LENGTH 4 statement.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.067 Inconsistent documentation and code, but thankfully with
VMXGSUM no impact. The invocation of &INCODE1 is now located
Apr 28, 1999 after the invocation of &INCODE instead of before, but we
have never used &INCODE1= nor do I really think anyone
else would have; it was really there just for insurance
if we ever needed it.
Thanks to Jan van Lent, Hudson Williams Europe, GERMANY.
Change 17.066 Several IMACs still had active macro definitions for the
IMACxxxx "_L and _K" macros that should have been removed in the
Apr 21, 1999 16.04+ design (they are now defined in the VMAC, and the
IMAC should be only comments). Only if you tried to use
the %LET MACKEEP= architecture to tailor these IMACs was
there a problem - your tailoring may have been ignored!
These IMACs were revised: IMACNTCP, IMACSTX, IMACSUIN,
IMACSUPR, IMACSVCC, IMACSTC, IMACICE.
Change 17.065 Eight DB2 variables in DB2ACCT and DB2STATS were only
VMACDB2 input if LENQXST was GE 428, for DB2 Version 6, but the
Apr 21, 1999 fields exist in DB2 Version 5.1. These variables
QXALOCL QXALOCC QXSTFND QXSTNFND QXSTIPRP
QXSTNPRP QXSTDEXP QXSTDINV
are now INPUT if LENQXST is GE 16, and the remainder of
the 6.1 fields are then input if LENQXST is GE 428.
Thanks to Ken Michalik, Kraft, USA.
Change 17.064 The ASMIMSLG/ASMIMSL5 programs still had symbolic value
ASMIMSLG &DFSMS set to 0 (for DFP) that must be changed to one if
ASMIMSL5 you have DF/SMS instead. If you overlooked this value,
Apr 20, 1999 you might read 107 out of 110 log tapes without error and
then fail with 0C4 abends on the other three log files!
I have made the default now to be DF/SMS installed with:
&DFSMS SETB 1
in both programs (ASMIMSL6 already had 1 as its default).
Thanks to David Pearce, Westpac Banking, AUSTRALIA
Thanks to Andrew Barrett, Westpac Banking, AUSTALIA
Change 17.063 Reserved Change.
Apr 20, 1999
Change 17.062 Comments only. TMON data can be dumped in two modes, and
EXITMON6 MXG supports only the "Data-Image" format. If the TMON
Apr 20, 1999 data instead is dumped with their "Export-Import" format,
an extra 104 bytes prefix each record. Comments remind
you to create "Data-Image" format, but also provide an
example of how to use the INFILE's START=105 value to
strip off those extra bytes so MXG can process the badly
dumped data anyhow!
Thanks to Coen Wessels, UNICIBLE, SWITZERLAND.
Change 17.061 The DASD Allocation Monitor program had return code 4 in
ASMDALO its assembly, but runs fine on an OS/390 2.4 system with
Apr 19, 1999 all of its UCBs below the 16MB line, while it 0C4's at
one site which has dynamic UCBs - we are investigating
and will update this text when more is known.
Thanks to Paul Parragio, U.S. Geological Survey, USA.
Change 17.060 "Final?" enhancement to MXG 16.04 architecture defines a
VMXGINIT new &Wdddddd macro variable for the //WORK destination of
VMACXXXX each MXG dataset, just like the &Pdddddd macro variables
Apr 17, 1999 for the output "PDB" destination. The macro _L and _W
are now defined with this syntax in their VMACs:
MACRO _Ldddddd &Pdddddd.DATASET %
MACRO _Wdddddd &Wdddddd.DATASET %
so any existing overrides of the _L or _W macros continue
to work, but instead you can use the simpler syntax:
%LET &Wdddddd = DDNAME ;
to redirect that dataset to DDNAME. That %LET can be
stored in your IMACKEEP member, or can be put ahead of
of the %INCLUDE program statement. I'm only sorry I did
not think of this in time to include in MXG 16.16!
This enhancement is transparent, unless you use USER=XYZ:
There were 272 members EDITed for this change.
Before, if you use // EXEC MXGSAS,OPTIONS='USER=XYZ'
all datasets that SAS wrote by default to //WORK would
be sent to the XYZ DDname, but now, SAS sees a real
DDNAME (yep, it happens to be "WORK", but SAS doesn't
see that, so the datasets are not output to XYZ).
Now, to send all //WORK datasets to the //XYZ DDname,
you can re-initalize MXG and change the work default:
%VMXGINIT(MXGWORK=XYZ);
%INCLUDE SOURCLIB(TYPExxxx);
and get the same effect as the USER=XYZ option.
Jan 2009: The preceeding example to send //WORK to //XYZ
has not worked since 2000. See Change 18.148.
The MXGWORK argument of %VMXGINIT was removed
in Change 26.310.
It took 240 minutes to locate and change the 2450 lines
in 272 members. It then took 120 minutes to locate and
correct the 19 characters in 17 lines in 14 members that
had been incorrectly typed. I had an error in 5.1% of
the members I edited, but that is only 0.7% of the lines
Change 17.059 Support for APAR OW37708 and/or APAR OW38073 add four new
VMAC42 variables, SMF42BUF/BMX/LRU/UIC to the TYPE42TO dataset,
Apr 16, 1999 with total and highwater mark of BMF buffers and BMF LRU.
interval and cycles until castout.
Change 17.058 For RMM/EDGS records EDGATYPE R or S, there are two
VMACEDGS different sets of variables depending on MSRMSTID. Now
Apr 16, 1999 both sets are decoded, and new variables MSUSTNAM,
MSMEDIA and EDGATYPE are added to dataset EDGSSREC.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales of America, USA
Change 17.057 -Change 16.225 was incomplete; the INPUT of the variables
VMACHSM WFSCPUTM and WFSACCT was added in the ID+1 record but was
FORMATS not added in the ID record, but since the FSR segment is
Apr 16, 1999 now in the ID+1 record, there should be little impact,
unless you are missing the APAR that moved the segment.
-Format MGHSMFU was updated to include values 15 and 16,
for ABARS ABACKUP and ABARS ARECOVERY records.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales of America, USA
Change 17.056 Support for the index information in DB2 Type 102 subtype
VMAC102 22 for DB2 5 and later is now decoded and creates ten new
Apr 16, 1999 variables in dataset T102S022.
Thanks to Scott Mcdonall, Southern California Electric, USA.
Change 17.055 Support for NTSMF new Quota Server object creates new MXG
EXNTQTAS dataset QUOTASRV.
FORMATS
IMACNTSM
VMACNTSM
Apr 15, 1999
Change 17.054 Using UTILBLDP to create your tailored sysin for BUILDPDB
UTILBLDP had errors and not clearly documented. If your tailoring
Apr 15, 1999 generated a MACRO _Edddddd .... statement, it was missing
an end comment on that line that cause a recursion error.
If you added the TMNT (MXG Tape Mount) product records,
you got an OPEN failure because UTILBLDP forgot that TMNT
records are in BUILDPDB by default. The missing "*/" is
now created, and your request to add TMNT records will be
used to set the _IDTMNT value without the OPEN failure,
so that observations are created in TYPETMNT dataset.
Comments were revised to document that you run %UTILBLDP
once to build an output text file, (BUILDMXG is now the
recommended name, and the recommended destination is in
your USERID.SOURCLIB). Then that "BUILDMXG" file with
your tailoring changes is used instead of the BUILDPDB
member in your daily job, either by pointing the SYSIN
of the daily job at BUILDMXG file:
//SYSIN DD DSN=USERID.SOURCLIB(BUILDMXG),DISP=SHR
or by replacing the %INCLUDE SOURCLIB(BUILDPDB); in your
daily PDB job with %INCLUDE SOURCLIB(BUILDMXG);
If you name the output file "BUILDPDB", it cannot be
put in the //SOURCLIB concatenation, because it will
recursively include itself. It could be put in a PDS
that is not in the SOURCLIB concatenation and pointed
to in that source library, but using BUILDMXG as the
member/file name for the output of UTILBLDP is much
safer and clearer.
Thanks to Keith McWhorter, State of Georgia DOAS, USA.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 17.053 Typo in VMXGINIT caused _S110 (sort all type 110s) to
TYPS110 fail with APPARENT SYMBOLIC REFERENCE PCICCF9 error. The
VMXGINIT two occurrences of PCICCF0 in VMXGINIT were changed to
Apr 15, 1999 PCICCF9. The ultimate cause of the error, however, was
Jul 20, 1999 that the _S110 macro was not used in the TYPS110 member,
so it was not fully tested; now, _S110 will execute when
member TYPS110 (to sort all datasets) is tested.
Jul 20: Typos in text: PCICFCn changed to PCICCFn.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Thanks to Tom Elbert, FORTIS, USA.
Change 17.052 Variable A08DURAT was missing in CICS/ESA 4.1 and later,
VMAC110 because the timestamps used to create it moved from the
Apr 14, 1999 STID=37 to the STID=39, and I overlooked creating the
duration variable from them. In addition, A08DURAT is
now truly the duration, since now the start and stop
variables are datetimestamps; previously they were only
a 24-hour time of day, so its calculation is direct:
A08DURAT=A08LBKDD-A08LBKCD;
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 17.051 A MACKEEP= example in Change 16.134 and DOCMXG does not
ChangeSS work safely, and was removed. The bad example showed
DOCMXG that you could sometimes tailor an _Edddddd exit macro
Apr 14, 1999 without using a semicolon and avoid the %QUOTE( ), but
that does not always work, depending on the contents of
the EXdddddd member used by the _Edddddd macro. Instead,
the second (and good) example showed that you should add
IF ... THEN DO; %include (member); END; logic around
the include of the EXdddddd member, and how to put the
MACKEEP= argument inside the %QUOTE ( ) function. This
is always safe, and only that second example was kept.
Thanks to C. Fred Kuhstoss, Norfolk Southern Corporation, USA.
Change 17.050 Using the new PDB.ASUMTAPE as input to member ASUMTMNT
ASUMTAPE can cause INVALID DO CONTROL error for "MISSEDMNT" mounts
Apr 14, 1999 because their TMNTTIME and TENDTIME variables were left
missing. But these MISSEDMNT events are all very fast
mounts, which had physical mount time in less than one
sample interval (max 2 seconds by default, may be 0.5),
so I have chosen to set the TMNTTIME and TENDTIME equal
to the ALOCSTRT datetimestamp for MISSEDMNT events in the
PDB.ASUMTAPE dataset to protect member ASUMTMNT.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 17.049 Typo caused no observations for dataset NPMSEEND. The
VMAC28 statement _E028SE1; after IF NPMSUBTY=49X THEN DO;
Apr 14, 1999 should be _E028SE2; (as in the comment).
Thanks to Bill Shanks, SEMA, ENGLAND.
Change 17.048 Support for IXFP/ICEBERG Subtype 8 and Subtype 6 fix.
EXICE8CL -IBM/STK mis-documented the IXFP SNAPSHOT DDSR segment,
EXICE8DD causing INVALID DATA FOR DSSRTIME error. DDSRTYPE is
EXICE8DS a four-byte binary and not a one-byte character.
EXICE8NP -New subtype 8 is an extended subtype 6 record that now
FORMATS creates four new MXG datasets, replacing two:
IMACICE ICEBR8CL - Cluster Definition
VMACICE ICEBR8DS - Dataset Name Segment
VMXGINIT ICEBR8SN - Snapped Extents List Segment
Apr 15, 1999 ICEBR8DD - DDSR Extents List Segment
Thanks to Judy Arroyo, Summit Bank, USA.
Change 17.047 Some 24 variables with MGBYTES format also had labels
VMACDCOL with "(MGBYTES)", which misled some to think the field
VMACTSOM contained "mega-bytes". MXG variables formatted with
VMACNETP the MGBYTES format contain bytes, but are converted when
Apr 13, 1999 printed to display their value in K/M/G/T-suffix for
Kilo/Mega/Giga/Tera-byte (i.e., 1024*) units. Because of
this confusion, the "(MGBYTES)" in the LABEL of all
variables was removed. The LABEL of a variable describes
the contents of that variable; the FORMAT of a variable
describes its display format, and implicitly its internal
units (MGBYTES in bytes, TIME/DATETIME in seconds, etc.).
I just read that the International Standards body has
defined new prefixes of KIBI/MEBI/GIBI/TEBI to
explicitly describe "binary thousands", or units of
1024-per-"thousand", so the MGBYTES format formally
supports those units with its "K/M/G/T/P" suffixes!
Change 17.046 ML-19 of ASMTAPES supresses the TMNT005E messages that
ASMTAPES should not have been printed. Originally a message for
Apr 12, 1999 an unexpected event, these messages occur with very fast
mounts. We detected that an ASID has a tape allocation,
but when we (slightly later) scan to that UCB, it no
longer is owned by the ASID number we got at the start
of the sample. Fast scratch VTS mounts now cause this
message to print in flurries, but the message has no
impact on the SMF records created by ASMTAPES, which are
just fine even when there are TMNT0005E log messages.
This correction returns to the caller with an RC-8, which
will cause the main logic to simply continue processing
with the next tape drive. At the next sample interval
we'll detect the ASID change and cut the allocation for
the job that used to have the drive allocated.
Thanks to David Gayle, Alltel, USA.
Change 17.045 Changing the Interval of PDB.ASUM70PR with _DURSET macro
ASUM70PR no longer worked, because of internal changes to VMXGSUM
Apr 12, 1999 to the &DATETIME parameter. To synchronize ASUM70PR with
RMFINTRV, IMACRMFI's _DURSET macro was used in a MYTIME=
argument, instead of using the VMXGSUM interval settings.
Additionally a SHIFT variable was needed to be created,
complicating the old logic. This redesign removed the
MYTIME= and INTERVAL=, and instead substitues the _DURSET
and IMACSHFT statements directly in the INCODE= argument.
This is both simpler and forces synchronization with the
PDB.RMFINTRV that is demanded in the later merge.
Thanks to Mike Hill, Abbey Life Assurance Company Limited, ENGLAND.
Change 17.044 Another typo in the _CDE102 macro causes error if TYPE102
VMAC102 is used to create all 300+ possible IFICIDs. The line
Apr 9, 1999 _C102206 _C102107 _C102108 ... should have been
_C102106 _C102107 _C102108 .... See Change 17.020.
Thanks to Hans Coolen, Zwolsche Algemeene, THE NETHERLANDS.
Change 17.043 Variable FSRDLM was not converted to yyyyddd julian date.
VMACHSM Eleven lines after CC=FLOOR(FSRDLM/100000) statement, the
Apr 9, 1999 IF YYYYDDD GT . THEN FSRBDATE=YYYYDDD; should have been
IF YYYYDDD GT . THEN FSRDLM=YYYYDDD; (Date Last Moved).
Thanks to Solomon Baker, Prudential, USA.
Change 17.042 Type 42 subtype 16 was out of alignment; after the input
VMAC42 of SMF42GAI and SMF42GBI, lines with +3 were inserted
Apr 9, 1999 to skip over the remaining three bytes of those four byte
fields. Type 42 subtype 19 timestamps SMF42JNE/SMF42JNF
are now input as &PIB.8.3 instead of 8.6. Many times that
were documented as microsec in OS/390 R2.6 SMF manual are
now documented as milliseconds in OS/390 R2.7 manual, and
most were caught in MXG 16.16, but these two were missed.
Thanks to Ben Cheung, Bank of Montreal, CANADA.
Change 17.041 The original PDB.ASUMTAPE dataset had SYSTEM='ALL ' for
ASUMTAPE all observations, but that is now corrected and the obs
Apr 9, 1999 will contain the SYSTEM of the Allocate (or Mount, if
there was no Matching Allocate, or Dismount if neither
an Allocate or a Mount was found. MXG sets SYSTEM='ALL'
internally so that grouping is done by DEVNR, but now the
true system is reset into variable SYSTEM.
See Change 17.010 for more complete details on why you
must use the new PDB.ASUMTAPE in place of PDB.TYPETMNT.
Thanks to David Ziems, NationsBank, USA.
Change 17.040 STC SMF record subtype 14 apparently does not always
VMACSTC contain step name and dataset name, STC14SNM/DSN (and
Apr 9, 1999 the label for STC14DSN was typoed too!). Now the MXG
logic tests for those fields existence before input.
Thanks to Jorn Ernebjerg, Kommunedata A/S, DENMARK
Change 17.039 Cosmetic. Typos in example for DATASET=DB2STATB were
DOCMXG corrected. The actual _SDB2STB code in member VMACDB2
Apr 6, 1999 was correct and can be viewed as an example.
Thanks to Engelbert Smets, Provinzial Versicher. Dusseldorf, GERMANY
Change 17.038 Cosmetic. Typos in the list of DDDDDD and DATASET names.
IMACACF2 ACFJEL/ACF2JEL should be ACFJRL/ACF2JRL and ACFAR/ACF2VR
Apr 6, 1999 should be ACFVR/ACF2VR. Only comments were changed.
Thanks to Mike Penlington, WestPac Trust, NEW ZEALAND.
Change 17.037 Support for TANDEM F40, G04, and G05 Operating System
VMACTAND changes to CPU, DISK, and PROCESS (INCOMPATIBLE, because
Apr 6, 1999 you must specify the exact LRECL when you upload TANDEM
records, and the LRECL is different for these records for
these operating systems. A number of new variables,
including Bytes In/Out have been added in this change.
Although these changes have been coded, no test data for
any of these operating systems has been available yet.
Thanks to Kim S. Johnson, NationsBank, USA.
Change 17.036 TPX Start Up record, subtype 1, was not properly decoded.
VMACTPX Now TPX subpool entry count is corrected, and the total
Apr 6, 1999 pool size (instead of entry size) is calculated for each
Apr 8, 1999 of the twelve pools, above and below the 16M line.
Thanks to Tom Parker, CSC Logic, USA.
Change 17.035 DENSITY IS MISSING message will now produce a hex dump of
VMACTMS5 the bad record for the first two errors, for diagnosis of
Apr 6, 1999 the raw record, but the message is no longer printed if
STPNAME='PRE-TMS', which are the only records that that
have had their density field zero.
Thanks to Joe Bruns, Cargill, USA.
Change 17.034 UNEXPECTED TCP/IP DATA VALUE message with TSTTCPCM=STOU
VMACTCP is fixed by adding 'STOU', to the list of commands for
Apr 6, 1999 FTPCLIENT/FTPSERVER events. Also, the message will now
also print a hex dump of the full record for the first
three instances on the SAS log.
Thanks to Pat Hearne, Experian, USA.
Change 17.033 New ratio variables are created in TYPE74CA dataset to
VMAC74 match RMF cache reports and eliminate an extra pass of
Apr 5, 1999 the data in your reports. Variables PCTREAD, TOTDEVHR
and WRITEHR (Percent Read, Device Hit Ratio and Write Hit
Ratio) were added.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Taught my 3-day Class in Dallas, March 31 - April 2, 1999.
Flew to Steve Cullen's retirement at State Farm Mutual Automobile
Insurance Co, Bloomington, Il, on April 2, 1999, in a Lear 25.
Change 17.032 For extended format datasets, HIGHRBA contains not the
VMAC64 highest byte address, but the highest CI number, and
Mar 29, 1999 so MXG stored HIGHRBA into HIGHCIEX, and tried to set the
HIGHRBA to missing (but misspelled it as HICHRBA). But
now, the spelling was corrected and the block of code
for extended format datasets was moved to after the INPUT
of CISIZE, and for extended format datasets, now the
HIGHRBA=HIGHCIEX*CISIZE calculates the highest relative
byte address of these datasets too.
Thanks to Alan Winston, MBNA, USA.
Change 17.031 Documentation. Boole's CMF product can create type 74
VMAC74 subtype 5 Cache records by specifying CMFREC=74 on the
Mar 29, 1999 CACHE control Statement. See CMF Monitor Batch User
Guide and Reference, Version 5 Release 2.3 pp 134-135.
Thanks to Bernd Klawa, Stadt Bielefeld, GERMANY.
Change 17.030 The calculation of RATCNT was revised, based on an email
VMACDMON from a CA technician. They now report that their code
Mar 29, 1999 calculates RATCNT=(RTCNT-RRSCNT)+SSAMPRT; but the old MXG
equation was RATCNT=(RTCNT-RRSCNT)*SSAMPRT+RRSCNT;.
Thanks to Ian Jones, Standard Life Assurance Company, ENGLAND.
Change 17.029 One site encountered syntax errors because two lines had
WEEKBLDT extended into column 72 (which is not wrong, and we can't
Mar 29, 1999 figure out why the one site had a failure), but the blank
before the percent sign was removed in the BYLIST macros
for TYPE72GO and TYPE7204, so that the line had a blank
in column 72, and the syntax error went away. The site
is at SAS 6.09 TS460!
Thanks to Bob LeMaster, Compass Bank, USA.
Change 17.028 TLMS expiration dates of 9990000 caused INVALID ARGUMENT
VMACTLMS TO FUNCTION DATEJUL, and variables BAVEXPDT or BADEXPDT
Mar 28, 1999 had missing values. These fields are now protected just
like TMS: two new variables, ORVEXPDT and ORDEXPDT will
contain the original EXPDT values, and for these non-date
dates (see Change 16.382 for the set of non-date values),
variables BAVEXPDT/BADEXPDT will contain '31DEC2099'D so
than any calculations will return a large value for these
non-date expiration values.
Two statements were changed for each variable in each
TLMS-version-block. The changes for BADEXPDT are:
IF 0 LT BADEXPDT LT 9999999 THEN .... was changed to
IF 0 LT BADEXPDT LT 9900000 THEN .... and
ELSE IF BADEXPDT=9999999 THEN .... was changed to
ELSE IF BADEXPDT GE 9900000 THEN ....
Thanks to Jim VanArsdale, IBM Global Services, USA.
Change 17.027 Support for APAR OW35586 "FICON" channels adds fields to
VMAC73 type 73 record from RMF Monitor I, and the type 79-12 RMF
Mar 28, 1999 Monitor II (optional) record. The TYPE73 and TYPE79C
Jul 11, 1999 datasets have new fields (variables prefixed SMF73 in the
TYPE73 dataset are prefixed R79C in dataset TYPE79C).
Depending on the CPMF Channel Measurement Group for the
Channel, SMF73CMG, one of these two sets of measurements
will be populated in dataset TYPE73:
For SMF73CMG=1, the Group 1 measurements are:
SMF73FG5='CPMF*VALIDATION*FLAGS'
SMF73TUT='TOTAL*CHANNEL*PATH*BUSY*TIME'
SMF73PUT='LPAR*CHANNEL*PATH*BUSY*TIME'
or for SMF73CMG=2, the Group 2 measurements are:
SMF73MBC ='MAXIMUM*BUS*CYCLES*PER SEC'
SMF73MCU ='MAXIMUM*CHANNEL*WORK UNITS*PER SEC'
SMF73MWU ='MAXIMUM*WRITE*DATA UNITS*PER SEC'
SMF73MRU ='MAXIMUM*READ*DATA UNITS*PER SEC'
SMF73US ='DATA*UNIT*SIZE'
SMF73TBC ='TOTAL*BUS*CYCLES*COUNT'
SMF73TUC ='TOTAL*CHANNEL*WORK UNITS*COUNT'
SMF73PUC ='LPAR*CHANNEL*WORK UNITS*COUNT'
SMF73TWU ='TOTAL*WRITE*DATA UNITS*COUNT'
SMF73PWU ='LPAR*WRITE*DATA UNITS*COUNT'
SMF73TRU ='TOTAL*READ*DATA UNITS*COUNT'
SMF73PRU ='LPAR*READ*DATA UNITS*COUNT'
-And these were added to TYPE79C by Change 17.023.
-They provide Channel Path Activity data transfer rates
and bus utilization for FICON bridges (FCV), with new
IBM descriptions:
Bus Utilization: Percentage of bus cycles when
bus has been found busy for
this channel in relation to the
theoretical limit.
Read (MB/SEC) PART: Data transfer rates from the
or control unit for this individual
LPAR partition.
Write(MB/SEC) TOTAL: Data transfer rates from the
control unit for the entire
CPC/CEC.
Change 17.026 APAR OW15406 added YYYY value for IODF Creation Date/Time
VMAC73 IODFTIME. Fortunately, this date is not likely to be
VMAC74 used for anything other than display, if at all! The MXG
Mar 28, 1999 logic to protect the 2-digit YY field in systems without
that APAR was added, and now the MXG code for IODFTIME is
the same for type 73 and type 74 records.
Change 17.025 Adding new variables to the PDB.JOBS/STEPS/PRINT datasets
BUILD005 with the new %LET ADD30U4= NEWVAR1 ... ; syntax is easy,
BUIL3005 but I hadn't thought about an easy way to drop variables
Mar 25, 1999 from those PDB datasets. Of course, you could always do
as before, by copying the appropriate _PDBnnnn macro from
BUILD005/BUIL3005 into your IMACPDB or IMACKEEP member
and blanking out the unwanted variables. But I realized
that by locating all _PDBnnnn macro references to the end
of the KEEP= list (some were, some weren't!), you can now
use the new ADDnnnn macro variable either to add new or
to drop old variables from those three PDB datasets:
%LET ADD30U4= NEWVAR1 NEWVAR2 DROP= UNWANT1 UNWANT2 ;
%INCLUDE SOURCLIB(BUILDPDB);
Since the &ADDnnnn token is at the end of each _PDBnnnn
definition, adding variables worked no matter where the
_PDBnnnn macro occurred after the KEEP=, but the _PDBnnnn
reference must be at the end of the KEEP= list to safely
use the above syntax to both drop and add variables.
In truth, you could have used the ADDnnnn macro to
add and drop, even without my relocating, but you
would have had to protect any variables that followed
the _PDBnnnn reference in the BUILxxxx member by the
use of this syntax for following variables:
%LET ADDnnnn= V1 V2 DROP= X1 X2 KEEP= ;
because SAS accepts this syntax:
DATASET (KEEP=list DROP=list KEEP=list )
Thanks to Larry Melamed, SHL Systemhouse, CANADA.
Change 17.024 I can't seem to ever get VMACIMSA right. Line 1374 has a
VMACIMSA missing semicolon. Actually, the semicolon was in column
Mar 25, 1999 73, which MXG truncates under MVS because S=72 is set in
CONFIG, but my testing under ASCII accepted the longer
record. Shift the line left and put the semicolon in 72.
Thanks to Pete Young, University of Toronto, CANADA.
Change 17.023 -CPU time for Pre-emptible SRBS running in this ASID, and
TYPE79 the CPU time for Pre-emptible SRBs running on behalf of
TYPS79 this ASID, and the Total CPU time consumed in this ASID
VMAC79 are now variables R791ASST/R791PHTM/R791TCPC in TYPE791
Mar 25, 1999 dataset, and R792ASST/R792PHTM/R792TCPC in TYPE792. The
Mar 28, 1999 fields were added by OS/390 Version 2 Release 5.
-In validating the TYPE791 dataset, I note that it has
mostly-accumulated fields, so the _STY791 Sort macro now
includes additional data steps to deaccumulate the data,
and the deaccumulation is automatic if you use member
TYPS79. Or you can use TYPE79 and then invoke _STY791,
so that dataset TYPE791 contains valid interval values.
-Support for FIBERCON/FICON new measures were added. See
text of Change 17.027 for details of new measurements, as
the same variables were added to TYPE73 as to TYPE79C.
-In TYPE79 and TYPS79, the line with _CDE79S was deleted
because it did not belong there; fortunately it had no
external impact, except to confuse my debugging!
Thanks to Tim Crocker, National Council on Compensation Insurance,USA
Change 17.022 IMS 6.1 only, MXG 16.16 still was wrong. Six lines with
VMACIMSA "DHMS(DATEYYYY," must be "DHMS(DATEJUL(YYYYDDD),"
Mar 24, 1999 so that timestamp values are not missing. While IMS 6.1
records had been validated with MXG 16.09, VMACIMSA was
later "cleaned up" to create unique julian date fields to
examine for debug that were not kept, and that revision
introduced this error in MXG 16.16.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 17.021 HSM and TMS Julian Date variables are internally Y2K ok,
VMACHSM but their default print format was still "6.", causing a
VMACTMS5 julian date of 2000001 to print as 2E6. The default
Mar 19, 1999 print format is now changed from "6." to "7." in both
members, but the MXG 16.16-built datasets are still
completely valid internally, and you can add a statement
FORMAT DSRDATE 7.; in your reports to print the seven
digit julian dates.
Thanks to John McCray, Huntington Services Company, USA.
Change 17.020 Typo in the _CDE102 macro causes error if TYPE102 is used
VMAC102 to create all 300+ possible IFICIDs. The text _C012297
Mar 19, 1999 should have been _C102297.
Thanks to Jules Troxler, Swiss National Bank, SWITZERLAND.
Change 17.019 The definition of HSM macro _DIFFHSM was relocated from
DIFFHSM the DIFFHSM member to the VMACHSM member so that you can
VMACHSM redefine the _DIFFHSM macro if you only want one HSM
DOCMXG dataset. For example, after this change, to create only
Mar 19, 1999 the HSMDSRST dataset, you could use:
%LET MACKEEP=
_NHSM
MACRO _WHSMDSR HSMDSRST %
MACRO _DIFFHSM _SHSMDSR %
;
Bob also found a type in DOCMXG examples; the second use
of _N110 example needed a second percent sign to end the
MACRO _ECICTRN definition as it is inside the %QUOTE.
Thanks to Bob Barton, DaimlerChrysler, GERMANY.
Change 17.018 NPM 2.4 only. Datasets NPMINSES and NPMEVSAL have trash
VMAC28 in LSCDxxxx variables. IBM added fields for IP address
Mar 16, 1999 and IP Port Number, but I misread the DSECT and thought
they were inserted; in fact they overlaid existing fields
causing the INPUT statement to be miis-aligned with data.
There are two places that needed correction.
The original code in the first location was:
SLNKNAME $EBCDIC8.
@;
IF COFTYPE='SCD' AND LSCDREVL GE 3 THEN INPUT
LSCDIPNM $EBCDIC15.
@;
INPUT SLUSUBPU $EBCDIC8.
and the correct code in that location now is:
SLNKNAME $EBCDIC8.
@;
M16=-16;
IF COFTYPE='SCD' AND LSCDREVL GE 3 THEN INPUT
+M16 LSCDIPNM $EBCDIC15.
+1
@;
INPUT SLUSUBPU $EBCDIC8.
to back up 16 bytes and input LSCDIPNM correctly.
The original code in the second location was:
VRNUM &PIB.2.
@;
IF LSCDREVL GE 3 THEN INPUT
LSCDIPPN $EBCDIC5.
@;
INPUT
TRANPRTY &PIB.2.
and the correct code in that location now is:
VRNUM &PIB.2.
@;
M5=-5;
IF LSCDREVL GE 3 THEN INPUT
+M5 LSCDIPPN $EBCDIC5.
@;
INPUT
TRANPRTY &PIB.2.
to back up 5 bytes and input LSCDIPPN.
Thanks to Steve Donahue, Blue Cross Blue Shield of Texas, USA.
Change 17.017 Cosmetic. The BY list for the TYPETMNT dataset in the
ASUMTMNT ASUMTMNT and TRNDTMNT members had "DATETIME", but that
Mar 15, 1999 can now be changed to the real variable name of TMNTTIME
Apr 5, 1999 (changes to VMXGSUM several versions ago made that change
possible), and the sort order in TRNDTMNT was changed
changed from ... SHIFT DEVICE ... to ...DEVICE SHIFT ...
to be consistent with the prior sorts. In addition, the
ID=TMNTTIME, statement has to be deleted for this change.
Thanks to John Sheridan, Aer Lingus, IRELAND.
Change 17.016 RMM EDGR dataset EDGRDEXT has zero observations because
VMACEDGR _EEDGRV /*INC SOURCLIB(EXEDGRD); _WEDGRD OUTPUTS EDGRDEXT*/
Mar 15, 1999 should have been:
_EEDGRD /*INC SOURCLIB(EXEDGRD); _WEDGRD OUTPUTS EDGRDEXT*/
Thanks to John Paul, Capital Blue Cross, USA.
Change 17.015 The input dataset was WEEK.PRINTER but member ASUMPRTR
TRNDPRTR now creates WEEK.ASUMPRTR, so the input was changed to
Mar 11, 1999 WEEK.ASUMPRTR. The output remains TREND.PRINTER.
Thanks to John McCray, Huntington Service Company, USA.
Change 17.014 Documentation and revision. The original 16.16 example
UTILBLDP did not properly handle SMF records that had fixed ID,
Mar 24, 1999 such as IBM type 39 records, and there was a missing
end comment sign.
Change 17.013 Dataset TYPE21/PDB.TAPES variable OPEN is always blank
VMAC21 now (MXG 16.04+), but it used to always be "INPUT". In
Mar 9, 1999 fact, the DCBOFLGS field that is tested to set OPEN is
not valid, since it always contains nulls in our data.
(IBM documentation says that if no bit is on in that
field, it was not available to the SMF record). Since
the type 21 record now contains BYTEREAD and BYTEWRIT,
which are clearer indicators of activity, I will leave
the code as it is, with OPEN=blank. If IBM every fixes
the record to retain the DCBOFLGS, then the MXG code
will populate OPEN. In addition, if the new ASUMTAPE
is enhanced to merge in TYPE1415 records, the actual
OPEN value will be available with that analysis.
Thanks to Khoan Dang, MBNA, USA.
Change 17.012 RACF type 80 record with optional RACFTYPE=7 user segment
VMAC80A had INPUT STATEMENT EXCEEDED RECORD LENGTH error. Delete
Mar 8, 1999 the statement INPUT +RACFDLN @; that is immediately after
the statement WHEN (7) DO;
Thanks to Joe Faska, Depository Trust, USA.
Change 17.011 MXG 16.09-MXG 16.16. TYPEIMSA processing is wrong, with
VMACIMSA missing values for STRTTIME. There is one instance of
Mar 8, 1999 DATEJUL(YYYDDD) that has only three YYYs, and that must
be changed to four YYYYs: DATEJUL(YYYYDDD).
Thanks to Werner Bundschuh, SAS Institute, EUROPE.
Thanks to Dr. Harald Lindenmuller, Bayerische Beamtenversich, GERMANY
Change 17.010 MXGTMNT can miss some mounts or can create false ones!!
ASMFTAPE
ASUMTAPE The MXG Tape Mount and Tape Allocation Monitor program
ASUMTMNT MXGTMNT (in member ASMTAPES), has two newly discovered
Mar 11, 1999 serious errors in dataset PDB.TYPETMNT:
Apr 5, 1999
- extra tape mount event records may be created during
allocation recovery with a NOHOLD reply, and
- some very fast VTS scratch mounts are missed.
Fortunately, those errors can be corrected with the new
ASUMTAPE program, which will read these PDB datasets:
PDB.TYPETMNT - Sampled Tape Mount Events
PDB.TYPETALO - Non-sampled Tape Allocation Events
PDB.TAPES - Rename of TYPE21, IBM Dismount Tape
to create the new PDB.ASUMTAPE dataset, that not only
discards any extra mounts, but recognizes missed-mounts
by merging the Allocate with Dismount events, so that the
ownership, durations, plus bytes read/written is known!
This major enhancement should have been written long ago.
A "tape event" is created in PDB.ASUMTAPE for every tape
volume dismounted. An event starts with the allocation
for a volume and ends with the dismount of that volume.
An event could be an allocate/mount/dismount with one
open/close of one dataset on that volume, or a tape event
could have opened many datasets on a volume during one
mount of the volume, or an event could allocate a volume
and mount it in one step and then retain the volume and
use it many times in many subsequent steps until dismount
of the volume. All these are recognized and handled.
These are important variables in the new PDB.ASUMTAPE:
STATUS - MATCHED/MISSEDMNT/TY21ONLY status
VOLSER - Volume Serial Number
DEVNR - Device Number (a/k/a UCB Address)
DDNAME - DDNAME of first use of this volume
INITTIME - Step Initiate time of first step to use
PROGRAM - PROGRAM from first step to use volume
STEPNAME - STEPNAME from first step to use volume
ALOCSTRT - Start Time of allocation for this volume
ALOCVLTM - Duration this volume was allocated
TMNTTIME - Timestamp when Mount was issued
TAPMNTTM - Duration that it took to mount the tape
TMTDTIME - Timestamp when Mount was satisfied
TAPMTDTM - Duration when the tape was mounted
TY21TIME - Timestamp when Volume was Dismounted
BYTEREAD - Bytes Read
BYTEWRIT - Bytes Written
SIOCOUNT - SSCH/SIO Count, number of I/O operations
ERRORxxx - Tape Permanent/Temporary/Erase error counts
JOB - JOB/READTIME/JESNR, and all of the other
information from the first allocate record
and from the mount record.
To correct the errors, all you need do is to insert this
statement after your %INCLUDE SOURCLIB(BUILDPDB):
%INCLUDE SOURCLIB(ASUMTAPE);
and then use PDB.ASUMTAPE instead of PDB.TYPETMNT in your
reports and analysis programs.
If you already %INCLUDE SOURCLIB(ASUMTMNT), to create the
PDB.TAPEMNTS from PDB.TYPETMNT, you will need to add the
include of ASUMTAPE before ASUMTMNT:
%INCLUDE SOURCLIB(ASUMTAPE,ASUMTMNT);
so that the new PDB.ASUMTAPE dataset will be built and
then the revised ASUMTMNT member will create PDB.TAPEMNTS
from the new PDB.ASUMTAPE instead of from PDB.TYPETMNT.
You can correct past PDBs by running this job for each
PDB, starting with the oldest PDB first, because those
"inflight" allocations and mounts are written to the new
SPIN.SPINALOC and SPIN.SPINMOUN datasets at the end of
ASUMTAPE's execution, and are then used as input for its
next run:
// EXEC MXGSAS
//SPIN DD DSN=YOUR.SPIN.LIBRARY,DISP=OLD
//PDB DD DSN=YOUR.PDB,DISP=OLD
%INCLUDE SOURCLIB(ASUMTAPE,ASUMTMNT);
Here are the details of the errors, their cause, etc:
See additional enhancements in Change 17.077.
-MXG SMF Mount records are created for some mounts that
never happened. Jobs that are in allocation recovery
that receive WAIT and NOHOLD replies have mount records
written when message IEF433D "NOHOLD" is printed (but
there are more IEF433D messages than extra records).
Many of these extra mount records have missing JESNR or
READTIME, which are required for validation of matchup,
so those are output to READMSNG dataset and not used.
Some of these extra mount records had VOLSER='UNKNWN',
(MXGTMNT could not get the VOLSER), and originally they
were discarded until Change 17.077. UNKNWN are now used
to build PDB.ASUMTAPE, and also output in dataset UNKNWN.
just in case they are needed. The EXTRAMNT dataset
counts the additional extra mounts that were detected and
discarded in ASUMTAPE. One site had 110
UNKNWN+READMSNG+EXTRAMNT with 745 true tape mounts, while
a second had 406+507+179=1092 false mounts with 8166 true
mounts, so the impact is severe.
While just discovered, this error in MXGTMNT has probably
been there all along. We are presently unable to locate
any flags in OS/390 that can differentiate these IEF433D
mounts as false mounts; all of the bits available to us
when we sample the UCB status during the IEF433D state
look just like the bits during a real mount event, but we
are still investigating corrections to the monitor.
-MXG SMF Mount records are missed for some very fast VTS
scratch mounts, even with 1/2 second sampling. MXGTMNT
missed 219 VTS scratch mounts with 2 second sampling, but
missed only 19 with 1/2 second sampling.
Fast VTS mounts that were too fast and were missed by
MXGTMNT sampling are now captured and identified with
JOB/JESNR/etc by merging their Dismount and Allocate,
although the durations TAPMNTTM will be set to zero
and TAPMTDTM will be set to ALOCVLTM for those mounts
with STATUS='MISSEDMNT'.
-Two new code members were added and one was revised:
ASUMTAPE reads a PDB library to create the PDB.ASUMTAPE
dataset from the PDB.TYPETMNT/TYPETALO/TAPES datasets
that are build by BUILDPDB. ASUMTAPE is in JCLPDB6 so
that it will be build automatically with that JCL.
ASMFTAPE will read SMF data to create the PDB.ASUMTAPE
dataset, for sites that don't run BUILDPDB:
// EXEC MXGSAS
//SMF DD DSN=your.smf,DISP=SHR
//PDB DD DSN=the.output.library,DISP=(,CATLG)...
//SPIN DD DSN=the.inflight.spin,DISP=(,CATLG)
%INCLUDE SOURCLIB(ASMFTAPE);
ASUMTMNT creates the PDB.TAPEMNTS summary dataset that is
used in your tape mount reporting. It is now revised to
use PDB.ASUMTAPE as its input, instead of PDB.TYPETMNT,
if there are observations in PDB.ASUMTAPE. Thus you can
create the corrected PDB.ASUMTAPE dataset and use it in
place of the incorrect PDB.TYPETMNT dataset.
A print of the PDB.ASUMTAPE dataset can be produced by
the macro _TAPERPT, using this syntax:
%INCLUDE SOURCLIB(ASxxTAPE); _TAPERPT;
These WORK datasets are available for examination:
- From the TYPETMNT dataset these defective observations
were not used in the combine logic, but instead were
output to these work datasets:
READMSNG Mount missing READTIME or JESNR.
UNKNWN Mounts with VOLSER=UNKNWN, usually false
mounts, but mounts that were not opened,
like the last volume of multi-unit alloc
for scratch tape that was pre-mounted but
was not used.
- From the TYPETALO dataset these defective observations
were not used in the combine logic, but instead were
output to these work datasets:
ALLOCBAD Allocation with JESNR or JOB missing.
- From the combine of Allocate, Mount, and Dismount:
EXTRAMNT - Extra Mount or Mount with no Dismount, they
were discarded and not counted nor used.
BK2BKDIS - Back to Back Dismounts without alloc/mount.
Has not occurred in testing, but coded for.
ALLOCNOT - Allocation event that was not used; no mount
nor dismount found. Could identify jobs
that are wasting a tape drive, but most of
these are partial allocation events during
allocation recovery. A job needs two drives;
it gets the first but can't get its second.
We see the allocate event record for that
first allocate, but there was no mount nor
dismount because the job never allocated.
The job goes to the bottom of allocation
recovery, and another job is now allocated
to the drive. Typically there is a series
of back-to-back allocates for alternating
job names on the same device as jobs bounce
around.
ALLOCRET - Allocation event that was retained. Very
common to see A,M,A,A,A,A,D sequence for
a tape that was mounted once and then passed
and retained across multiple steps.
DEBUG - Zero obs unless you enable, typically for a
single device, to examine what records come
in what sequence.
SPUNMOUN - Inflight Mounts, held for tomorrow, they get
written out to SPIN.SPINMOUN.
SPUNALOC - Inflight Mounts, held for tomorrow, they get
written out to SPIN.SPINALOC.
The logic expects that a DEVNR is a unique tape drive,
i.e. no two tape devices have the same DEVNR/UCBADDRESS.
By default the variable SYSTEM is set to 'ALL ', so that
the logical merge is by DEVNR, because the IBM dismount
record can be written on a different system than the
system where the allocate and mount were written.
If you do have two tape devices with the same DEVNR
on two different systems, you can group your SMF data
for systems that share and for systems that don't and
run the ASxxTAPE program separately against each set
of SMF records, or better, you will be able to update
a new format table that MXG will use to reset the
variable SYSTEM to separate the shared and non-shared
devices. Contact Merrill to be the test site!
The implementation requires the //SPIN DD exist in your
JCL, and writes out to the //SPIN DD the SPINMOUN and
SPINALOC datasets, holding the inflight mount/allocate
records to be reintroduced in tomorrows processing.
The SPINCNT value in IMACSPIN is not used for ASUMTAPE,
because new allocations will eventually either match up
or confirm that the inflight allocate can be discarded.
I have done a lot of testing, with data from several
systems with different hardware, but this is a brand new
algorithm with lots of opportunities for validation.
I am highly confident that the PDB.ASUMTAPE matchup is
okay, and almost as confident that all other possible
non-matchups are decoded correctly into //WORK.
This program is validated for JES2 only, at present.
It does not fail with JES3, and does match the MXGTMNT
records from JES3 with the TYPE 21 records, but initial
JES3 tests suggest that because JES3 MDS allocations are
never seen by MXGTMNT, this program may not be as useful
for JES3. More JES3 testing is planned and this note
will be revised when more is known about JES3.
These sequences of Alloc/Mount/Dismount events are seen:
Normal: A M D
Multi-Volume A M D M D M D
Retained Allocation A M A A A A D
Dynamic Allocate A M D A M D
Missed Mount A D
Missed Mount Multi-Volume A D D D
Thanks to Chuck Olsen, ALLTEL, USA, whose analysis found the error.
Change 17.009 Support for deaccumulation of TYPE30_6 data. These funny
VMAC30 subtype 6 records are written for address spaces that are
Mar 4, 1999 started before SMF is up, and contain accumulated values
for most fields (but not all, and IBM doesn't document
which are accumulated and which are not) that require the
SORT and DIF() operation to produce valid interval data.
The JOB names that typically write subtype 6 records are:
ALLOCAS CONSOLE EYUX130 GRS IEFSCHAS JES2AUX JES3AUX
PCAUTH RACFDS RASP SMXC SYSBMAS TNF TRACE
VMCF
The dataset sort macro _STY30U6 for TYPE30_6 was revised
to deaccumulate the TYPE30_6 data into PDB.TYPE30_6, and
comments in VMAC30 list which variables are kept, dif()d,
which are not, and which are always missing values. Only
the PROD, ID, UREC, CPU, STOR, and PERF segments exist.
The change also corrects variables INTBTIME/INTETIME in
TYPE30_6. Because subtype 6 records contain nulls for
the SMF30IST timestamp from which GMTOFF30 is calculated,
INTB/INTE were never converted from GMT in TYPE30_6. By
revising the logic so that INTBTIME=SMF30IST only when
SMF30IST is non-missing, and by only calculating GMTOFF30
only when SMF30IST is non-missing, the GMTOFF30 from the
prior type 30 (non-subtype-6) can be used to convert GMT.
Thanks to Ron Hackett, US West, USA.
Change 17.008 Cosmetic. The &MACSHFT statement was moved to the end of
IMACSHFT the member.
Mar 4, 1999
Thanks to Chuck Hopf, MBNA, USA.
Change 17.007 TYPE50 dataset. Input should be BSIZE &PIB.4. instead of
VMAC50 BSIZE ?? 4. and the input of MXTRSIZE should be @75+
Mar 2, 1999 rather than @74+.
Thanks to Peter Durrant, National Australia Bank, AUSTRALIA.
Change 17.006 Support for DB2 type 102 subtype 199 adds QW0199xx fields
VMAC102 that report DB2 Dataset I/O statistics (avg/min/max delay
Mar 2, 1999 time in millisecs for sync/async/cached I/O plus counts).
There is an observation for every Piece or Partition of
every DB2 dataset (DBID/OBID), but only if the piece/part
averaged more than one I/O per second in the interval.
Looks interesting, and I too have used a one-I/O-per-sec
threshold to separate the wheat from the chaff.
One test record out of ten has QW0199xx fields missing
because it has only two segments (QWHSNSDA=2) when
there should be three. To be investigated with IBM.
Thanks to Dennis Pugh, BMC, USA.
Change 17.005 In the "Print first 50 obs of every NTSMF dataset" macro
VMACNTSM _RNTPRNV, the PROC PRINT DATA=_LNTDDB2 should be _LNTDB2.
Mar 1, 1999
Thanks to Mike Kynch, International Paper, USA.
Change 17.004 SYNCSORT variable INVOKSAS was not always set; the test
VMACSYNC should be IF INVOKFLG='...1....'B THEN INVOKSAS='Y'; as
Mar 1, 1999 the value of CMFSAS are x'10' or x'11'.
Thanks to Bruce Christopher, Household International, USA.
Change 17.003 Support for Candle V400 Omegamon for CICS Epilog records.
VMACEPIL Change IF OMPRDVER=451 OR OMPRDVER=450 THEN DO; to read
Feb 24, 1999 IF OMPRDVER=451 OR OMPRDVER=450 OR OMPRDVER=400 THEN DO;
and add MACRO _EPILOFF OFFEPIL=4; % in member IMACKEEP,
as there is an extra four byte length field at the start
of the V400 record.
Thanks to Malcolm Campbell, Marks and Spencer, ENGLAND
Change 17.002 The TYPEUNIC support for CA UniCenter is not for Unix,
TYPEUNIC but is for the Open VMS or VMS operating system, and test
Feb 22, 1999 data validated was from VMS 7.0. Also, the suffix is
UNIC (UNCI was typoed in change 16.391 and Newsletter).
The code is fine, I just failed to realize the data was
from VMS (but I
Change 17.001 The optional IMAC6ESS for the type 6 ESS segment was fine
IMAC6ESS under MVS, but the $VARYING fields were not converted to
Feb 22, 1999 EBCDIC when run under ASCII SAS. The INPUT and TRANSLATE
functions were added to correct.
LASTCHANGE: Version 17.
=========================member=CHANGE16================================
/* COPYRIGHT (C) 1984-1999 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 16.16 is dated Feb 20, 1999, thru Change 16.394.
Newsletter THIRTY-FIVE was dated Feb 20, 1999, thru Change 16.367.
First MXG Version 16.10 was dated Feb 8, 1999, thru Change 16.364.
MXG Version 16.09 was dated Jan 20, 1999, thru Change 16.334.
MXG Version 16.08 was dated Dec 23, 1998, thru Change 16.315.
Last MXG Version 16.07 was dated Dec 5, 1998, thru Change 16.299.
First MXG Version 16.07 was dated Dec 4, 1998, thru Change 16.296.
Last MXG Version 16.06 was dated Dec 2, 1998, thru Change 16.292.
Fifth MXG Version 16.06 was dated Nov 30, 1998, thru Change 16.289.
Fourth MXG Version 16.06 was dated Nov 21, 1998, thru Change 16.285.
Third MXG Version 16.06 was dated Nov 18, 1998, thru Change 16.284.
Second MXG Version 16.06 was dated Nov 17, 1998, thru Change 16.279.
First MXG Version 16.06 was dated Nov 16, 1998, thru Change 16.278.
MXG Version 16.05 was dated Nov 1, 1998, thru Change 16.259.
Fourth MXG Version 16.04 was dated Oct 19, 1998, thru Change 16.242.
Third MXG Version 16.04 was dated Oct 9, 1998, thru Change 16.231.
Second MXG Version 16.04 was dated Oct 7, 1998, thru Change 16.224.
Newsletter THIRTY-FOUR was dated Sep 30, 1998, thru Change 16.221.
First MXG Version 16.04 was dated Sep 30, 1998, thru Change 16.221.
Beta 6 MXG Version 16.03 was dated Sep 23, 1998, thru Change 16.216.
Beta 5 MXG Version 16.03 was dated Sep 9, 1998, thru Change 16.196.
Beta 4 MXG Version 16.03 was dated Aug 11, 1998, thru Change 16.171.
Beta 3 MXG Version 16.03 was dated Jul 15, 1998, thru Change 16.147.
Beta 2 MXG Version 16.03 was dated Jul 14, 1998, thru Change 16.147.
Beta 1 MXG Version 16.03 was dated Jul 10, 1998, thru Change 16.147.
Final MXG Version 16.02 was dated Jun 8, 1998, thru Change 16.120.
First MXG Version 16.02 was dated Jun 2, 1998, thru Change 16.112.
Real MXG Version 16.01 was dated Apr 9, 1998, thru Change 16.053.
First MXG Version 16.01 was dated Apr 8, 1998, thru Change 16.052.
MXG Version 15.15 was dated Feb 23, 1998, thru Change 15.391.
Newsletter THIRTY-THREE was dated Feb 23, 1998, thru Change 15.382.
Contents of member CHANGES:
I. MXG Software Version 16.16 is now available.
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 16.16.
X. Online Documentation of MXG Software.
XI. Changes Log
I. MXG Software Version 16.16 was shipped with Newsletter THIRTY-FIVE.
1. Major enhancements added in MXG 16.16 (not printed in Newsletter 35)
Support for CA UniCenter Unix Performance Monitor.
Support for TMON for CICS Version 2 PTF TH01129
Support for NETSPY Version 5.2 (COMPAT).
Support for new SNA BASE and IBM SNA objects.
ANALHSM rewritten as %MACRO, new thread use/queue measures.
XSUM70PR created to not-count ICF partition's CPU as a CPU.
Trending member for PDB.SMFINTRV / TYPE30_V dataset.
Automatically tailor BUILDPDB with the new UTILBLDP utility.
CPU increase (16.06-16.10) in BUILDPDB due to CICINTRV corrected.
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 Vers 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 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
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 Jul 4, 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.
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 freemain 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 internally in
IBM code. The APAR text cites negative values in SMF30IO (IOUNITS),
but as MXG uses PIB instead of IB, very, very large values (so they
are noticed!) are created rather than small negative values.
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 5.1, 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. Use the DSNZPARM
macro DSN6SYSP PTASKROL parameter for parallel task accounting
control. 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). APAR PQ28414 provides a new ability to
limit the degree of query parallelism, and provides a maximum degree
parameter, PARAMDEG, and adds the field to the install process in
Version 6. This note updated with IBM input 19Dec1999.
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):
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.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 misdocumented 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.
TYPEUNIC 16.391 Support for CA UniCenter VMS Performance Monitor.
TYPE102 16.390 Support for IFCIDS 252 and 260.
TYPETMO2 16.387 Support for TMON for CICS Version 2 PTF TH01129
TYPENSPY 16.386 Support for NETSPY Version 5.2 (COMPAT).
BUILDPDB 16.385 New WLM variables added to PDB.JOBS dataset
TYPENTSM 16.384 Support for new SNA BASE and IBM SNA objects.
ANALHSM 16.383 Rewrite as %MACRO, new thread use/queue measures.
TYPETMS5 16.382 Documentation of TMS EXPDT values.
XSUM70PR 16.381 Circumvention for IBM including ICF partition as CPU.
VMACDB2H 16.380 Invalid QWHSSTCK data value trashed dates/times.
IMAC6ESS 16.376 Optional ESS decoding of type 6 fails with 2 fields.
VMXGSUM 16.375 Invalid Argument to Substring message eliminated.
TRNDSMFI 16.374 Trending member for PDB.SMFINTRV / TYPE30_V dataset.
UTILPLDB 16.373 Automatic generate BUILDPDB utility.
ASUMUOW 16.371A Revisions for SPIN and missing values.
UTILCICS 16.371 Subtype 0 CICS 4.1 caused INPUT STATEMENT error.
TYPE7072 16.370 New PCTMETGO variable was not correct.
CICINTRV 16.367 Big CPU increase in 16.06-16.10 corrected.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 16
======Changes thru 16.394 were in MXG 16.16 dated Feb 20, 1999======
Change 16.394 Support for CA MIM Version 4.3 Product SMF record adds
EXTYMIM thirteen new datasets created from its subtypes. The
EXTYMIM1 original MIMTAPE dataset is still built, but the names
EXTYMIM2 of the variables are changed to be consistent with the
EXTYMIM3 MIM documentation; where they started with STCxxxxx in
EXTYMIM4 the documentation, the variable names are MIMxxxxx now.
EXTYMIM5 This revision was a user contribution that I revised for
EXTYMIM6 the new MXG architecture, but have only run syntax check,
EXTYMIM7 as I have no sample records to test with before 16.16 is
EXTYMIM8 finalized and tapes are built!
EXTYMIM9
EXTYMIMA
EXTYMIMB
EXTYMIMC
EXTYMIMD
IMACMIM
TYPEMIM
TYPSMIM
VMACMIM
Feb 21, 1999
Thanks to Martyn A. Jones, CHASE, ENGLAND.
Change 16.393 This is the "40 GIG" paper that Chuck Hopf and I have
DOC40GIG presented at SHARE and CMG in 1998. The graphs, tables,
Feb 19, 1999 and charts that are not text documents cannot be included
in this text member, but the text contains the link to
those graphic documents, which are now on our homepage.
Change 16.392 Preliminary MXG "New User" manual is far from complete,
NEWUSER but has excellent examples of how to use MXG, how to set
Feb 19, 1999 up SMF, etc., and comprehensive documentation of the MXG
summarization macro, VMXGSUM. This will be expanded.
Most of this document can be directly read, but there are
some figures that are graphics or tables that cannot be
included in a text document; instead, the document has
the link to that document on the MXG homepage, so if you
can connect to the internet while you read, you can see
the figures and tables that can't be included in text.
Thanks to Chuck Hopf, MNBA, USA.
Change 16.391 Support for CA UniCenter VMS Performance Monitor data
EXUNICCP from their ADVISE PERFORMANCE EXPORT/TYPE=ASCII command.
EXUNICDI Thirteen datasets are created:
EXUNICDV dddddd dataset description
EXUNICIO UNICCP UNICTRCP UniCenter CPU statistics
EXUNICLK UNICDI UNICTRDI UniCenter DISK statistics
EXUNICME UNICDV UNICTRDV UniCenter DEVICE statistics
EXUNICPG UNICIO UNICTRIO UniCenter I/O statistics
EXUNICPR UNICLK UNICTRLK UniCenter LOCK statistics
EXUNICSC UNICME UNICTRME UniCenter MEMORY statistics
EXUNICSR UNICPG UNICTRPG UniCenter PAGE statistics
EXUNICSY UNICPR UNICTRPR UniCenter PROCESS METRICS stats
EXUNICVR UNICSC UNICTRSC UniCenter SYSTEM COMM stats
EXUNICXQ UNICSR UNICTRSR UniCenter SERVER statistics
FORMATS UNICSY UNICTRSY UniCenter SYSTEM statistics
IMACUNIC UNICVR UNICTRVR UniCenter VERSION number
TYPEUNIC UNICXQ UNICTRXQ UNICENTER XQP statistics
TYPSUNIC Some counters (RMTPAGNT,RMTSWPNG) in UNICTRDI Disk data
VMACUNIC that have a value of minus one that is not documented but
Feb 19, 1999 I assume means that field was not used? There is a lot
Feb 24, 1999 of information captured by UniCenter in these records!
Feb 24: Originally was mis-stated as UNIX support, but
records are from the VMS and Open VMS operating system).
Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM.
Change 16.390 Support for DB2 Trace IFCIDs 250, 252 and 260, 261, and
VMAC102 262 has been added and validated with DB2 5.1 records.
Feb 18, 1999
Change 16.389 An include of IMACKEEP was added after the definition
CICINTRV of _CICINTV macro that sets the interval duration so
Feb 18, 1999 it can be overridden with IMACKEEP/MACKEEP logic.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK
Change 16.388 An include of IMACKEEP was added after the include of
RMFINTRV IMACRMFI so that the _DURSET macro that set interval
Feb 18, 1999 duration can be overridden with IMACKEEP/MACKEEP.
Thanks to Paul Oliver, BHP Information Technology, AUSTRALIA.
Change 16.387 Support for TMON for CICS Version 2 PTF TH01129 (COMPAT)
VMACTMO2 adds MQ Series fields to both the MONISYST and MONITASK
Feb 18, 1999 records, using existing reserved fields. New variables:
MONISYST MONITASK Description
TIMQQMGR TAMQQMGR MQ Series Queue Manager Name
TIMQSRCT TIMQSRCT MQ Series API Request Count
TIMQSRTM TIMQSRTM MQ Series API Request Duration
TIMQSWCT TIMQSWCT MQ Series Wait Count
TIMQSWTM TIMQSWTM MQ Series Wait Time
These new variables are defined, but the actual DSECT had
not been received so the fields are not yet actually read
in yet, so they will all be missing until this is fixed.
Thanks to Brian Kaczkowski, Kohl's Department Stores, USA.
Change 16.386 Support for NETSPY Version 5.2 is already in MXG, as none
VMACNSPY of the supported subtypes were changed. There is a new
Feb 18, 1999 NSPYREC='I' record for TCP/IP, but that new subtype is
not yet supported, pending fixes from the vendor (there
is time for all transactions and network time for 3270
emulation, but no network time for GUI users who telnet
in, etc.). When valid data is available and the record
format is stable, I will add support for type "I" data.
Thanks to Roger Zimmerman, Zurich Kemper Investments, USA.
Change 16.385 New WLM variables added by OS/390 2.4 are now added to
BUILD005 the PDB.JOBS dataset. Variables are JOBMODE0 JOBMODE1
Feb 18, 1999 SMF26WCL, SMF26WIN, SMF26WJC, SMF26WOC, SMF26WSE.
Thanks to Jack Hudnall, Southwestern Bell, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.384 Support for three new IBM SNA Objects:
EXNTSNA1 dddddd Dataset Object Variables
EXNTSNA1 NTSNAB SNABASE SNA BASE 19
EXNTSNAB NTSNA1 SNAIBMCS IBM SNA CLIENT SERVICES 2
FORMATS NTSNA2 SNAIBMLB IBM SNA LOAD BALANCING 2
IMACNTSM Also, the _UNTDISC macro used to print discover records
VMACNTSM was revised for changed headers.
VMXGINIT
Feb 17, 1999
Change 16.383 HSM Analysis example was rewritten as a %MACRO so that
ANALHSM arguments can be passed, and additional reports on HSM
Feb 17, 1999 activity (concurrent threads, threads queued, etc). The
program requires the ASUMHSM member of change 16.345.
Change 16.382 No change, documentation only. TMS a/k/a CA-1 now has
TYPETMS5 new values for EXPDT that have special meaning:
Feb 17, 1999 EXPDT Meaning TMS Prints
9989xxx Conversion from Prior STATS/xxx
9990000 Catalog Retention CATALOG
9998xxx Retain xxx after LastRef LDATE/xxx
9999xxx Number of Cycles CYCLES/xxx
9999999 Permanent Retention PERMANENT
I have been unsuccesful in creating a FORMAT that will
extract that xxx value and print these special EXPTD
values the way TMSBINQ and other CA programs do.
Thanks to Wayne Hartman, Prudential, USA.
Change 16.381 CECs with an Integrated Coupling Facility, ICF, count the
XSUM70PR "spare" CPU in which the Coupling Facility is running as
Feb 17, 1999 a real processor. This summer, IBM will document changes
to the Diagnose 204 and 224 to define 3-byte codes for CP
types (general purpose and ICF) and will update the RMF
Type 70 SMF record so that the records for the ICF
Partition (and its PHYSICAL record for the ICF) can be
recognized and either deleted or at least excluded from
the count of CPUs. In advance of that APAR, this change
lets you delete the TYPE70PR observations from the ICF
LPAR (by LPARNAME/LCPUADDR) and lets you correct the
number of engines, so that the created PDB.ASUM70PR
counts the real workload and the real processors. You
will have to examine your TYPE70PR observations to see
what combination of LPARNAME, LPARNUM, and LCPUADDR can
be used to identify the ICF LPAR and its "PHYSICAL"
partition observations.
Thanks to Forrest Nielson, State of Utah, USA.
Thanks to Barry Rozemeijer, ING Nederland, THE NETHERLANDS.
Change 16.380 Invalid QWHSSTCK value in DB2ACCT records causes datetime
VMACDB2H variables QWACBSC and QWACESC to be trashed (dates in the
Feb 17, 1999 year 2082, wrong times). Instead of an expected 8-byte
field in TODSTAMP format (for example, the raw QWACESC is
'B1CFB43F08BF37F1'x for '15FEB1999:17:57:26.02'), the bad
QWHSSTCK field has a value in SMFSTAMP format (the raw
value '0020734600099031F'x is '31JAN1999:05:05:54.78' as
an SMFSTAMP, but that date is two weeks earlier than the
actual records (created on Feb 15, 1999), so not only is
the format wrong, the value is wrong too! MXG uses that
bad QWHSSTCK value to calculate your GMT offset, so that
QWACBSC/QWACESC can be converted back to local time, but
MXG input that bad QWHSSTCK as the expected TODSTAMP, it
is '26JAN1900:20:15:19.53', which causes GMTOFFDB to be
98 years (SMFTIME is 15FEB1999:11:57:23.02), which is
what then corrupts the QWACBSC and QWACESC values.
While investigating the source of this bad value, which
may have come from one of those Y2K-date-simulator-tools
that intercept STCK macro calls inside MVS, I now check
to see that the calculated GMTOFFDB is less than 24 hours
and if it is not, then I print an error message on your
SAS log that I could not calculate GMT offset and that
your BSC/ESC timestamps will be on GMT rather than local,
and set GMTOFFDB to zero. I will update this note when
we know if this error is due to a STCK-interceptor or if
it is an IBM DB2 error.
Thanks to Warren E. Waid, JC Penny, USA.
Change 16.379 Syntax error in this JCL example. The test should be
JCLADHOC IF APPLID='PROC' THEN OUTPUT _WCICTRN;
Feb 17, 1999
Thanks to Khalid Meskinia, SAS Institute, FRANCE.
Change 16.378 This analysis failed with dataset not found. This line
ANALVVDS PROC SORT DATA=_WTYVVDS..TYPEVVDS OUT=MXGVVDS.TYPEVVDS;
Feb 17, 1999 should have been
PROC SORT DATA=_WTYVVDS OUT=MXGVVDS.TYPEVVDS;
Thanks to David Mesiano, Sharp Electronics, USA.
Thanks to Steve Mesiano, Sharp Electronics, USA.
Change 16.377 -Format MGX37FL, used in TYPEPROS (STOPX37 replacement),
FORMATS had values of 12/16/20/24/28/32x when the actual data
VMACPROS values are 0c/10/14/18/1c/20x.
Feb 16, 1999 -Label for ABDISP now is 'ABEND*DISPOSITION'.
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 16.376 Optional decoding of the ESS segment in SMF type 6 record
IMAC6ESS fails with INPUT STATEMENT EXCEEDED RECORD LENGTH if you
Feb 16, 1999 have more than 1 address parameter in the JCL. The line
GEPARTLN=0; must be moved to before IF GEPARMKY=27X....
and new line
IF GEPARTLN GT 0 THEN GEPARMLN=GEPARTLN+(GEPARMNR-1)*2;
was added before GEOFFSET=GEOFFSET+GEPARMLN+6;
Thanks to Waldemar Rathfelder, ADP TAYLORIX GmbH, GERMANY.
Change 16.375 Fixes logic dealing with the length of the dataset names
VMXGSUM in the INDATA= that cause warning messages about invalid
Feb 16, 1999 arguments to SUBSTR function. Improved KEEP logic now
uses NODETAILS options on PROC CONTENTS to avoid reading
the entire dataset just to find out what variables exist.
Change 16.374 Trending member for the PDB.SMFINTRV dataset (which is
TRNDSMFI from Type 30 Subtype 2/3 records and is created as
Feb 16, 1999 dataset TYPE30_V, controlled in member IMACINTV.
Change 16.373 Confused by the syntax for the new %LET statements in
UTILBLDP MXG 16.16? This macro will build the SYSIN stream for
Feb 16, 1999 you to run BUILDPDB completely from SYSIN using the new
%LET architecture. You tell us the SPINCNT desired, any
time differences, any additional SMF records that you
want to add to the BUILDPDB process, and anything that
you want to suppress, and this utility builds the sysin
stream, complete with comments.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.371A If you were not using ASUMUOW's normal default (use the
ASUMUOW earliest transaction record as the real transaction name)
Feb 16, 1999 then some of the variables that are used to identify the
Feb 18, 1999 transaction (such as LUNAME, USER, TERMINAL, SYSTEM,
SMFTIME) may not have come from that real transaction
record, but were erroneously picked up from the last
transaction record in the unit of work, which might have
come from the SPIN library and might have blank values.
This change treats these identifying variables the way
that TRANNAME is, so that they all come from the same
record, and corrects the logic for SPINning records.
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Change 16.371 Subtype 0 records from CICS/ESA 4.1 caused UTILCICS to
UTILCICS fail with INPUT STATEMENT EXCEEDED RECORD error. Replace
Feb 16, 1999 IF '02' LE OLDVERCI LE '03' THEN SUBTYPE=0;
IF SUBTYPE EQ 00 THEN DO;
with
IF '02' LE OLDVERCI LE '03' THEN DO;
SUBTYPE=0; /* CICS 1.6, 1.7, 2.1 FORMAT DATA */
The real culprit was the MXG logic error, not the record!
Thanks to Andre van de Riet, Hudson Williams Europe, THE NETHERLANDS.
Change 16.370 New variable PCTMETGO was not calculated correctly; the
VMAC7072 test should be IF R723CVAL*RTSMAP(M) GE R723CVAL THEN DO;
Feb 16, 1999 so we compare the bucket's response time (instead of the
percentage value for that bucket) to the response goal.
At present, counting the first six buckets would produce
the same value, as the 6th bucket is the 100% bucket, but
this algorithm should protect future changes.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.369 MXG 16.06-16.10. Cosmetic. Names of some DROP variables
VMXGCICI were truncated (DIFTQTEM,DIFIOCRS,DIFIOCWF,DIFSTL,DIFST)
Feb 16, 1999 and so they were not dropped from temporary datasets, but
the MXG datasets were built without error.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK
Change 16.368 MXG 16.09-16.10. Macro PMVCICS had not been defined in
VMXGINIT VMXGINIT for the new CMRDETL support added in 16.09.
Feb 16, 1999
Thanks to Stephen Mesiano, Sharp Electronics Corp., USA.
==Changes thru 16.367 were in MXG NEWSLETTER THIRTY-FIVE Feb 20, 1999==
Change 16.367 MXG 16.06-16.10. Big CPU increase in BUILDPDB due to
VMXGCICI CICINTRV revisions introduced in MXG 16.06. MXG's use of
CICINTRV VMXGSUM's KEEPIN= option (which creates KEEP= statement
Feb 9, 1999 to keep only the needed variables) turns out to be very
CPU intensive in CICINTRV/VMXGCICI, even when there are
zero CICS observations! Replacing KEEPIN= option with
KEEPALL=YES removed the excessive cost of KEEPIN= logic.
In a single invocation of VMXGSUM when you need to keep
only a few variables from a large number of variables,
and when you have many observations (e.g., summing ten
variables from CICSTRAN, which was its purpose) using the
KEEPIN= option still makes sense, as it will save lots of
work space during the summarization. But CICINTRV, with
its many invocations of VMXGSUM (and a KEEPIN execution
for each argument of each VMXGSUM), and with essentially
all variables kept, so no space could be saved, the CPU
cost of KEEPIN was greater than the runtime without it!
Mac reported his BUILDPDB increased from 324 to 2650 CPU
seconds, a factor of eight! In my confirming tests, I
isolated the increase to CICINTRV and saw it jumped from
64 seconds to 446 seconds, about the same increase ratio!
That high cost (one build of the OPTVAR dataset took 53
seconds) is because we have to use SAS macro language to
parse arguments into macro variables and then convert to
variables in data steps so we can sort and remove dupes!
Note that VMXGSUM turns off SAS log messages, especially
for the data steps executed by the KEEPIN= algorithms,
and so the sum of "Step Used CPU" log messages will be
much smaller than the "Total CPU Used" value. For Mac,
his Total was 2650 seconds, but sum was only 380 seconds;
over 2270 seconds of KEEPIN= were not printed on the log!
Thanks to Mac Moss, Burlington Industries, Inc.
Change 16.366 NTSMF dataset PROCESOR variable DPCQUERT replaced DPCQUED
NTINTRV but the old variable name was still used in NTINTRV,
Feb 9, 1999 causing a missing value in NTINTRV.
Thanks to Chris Weston, SAS Institute ITSV Development, USA.
Change 16.365 Type 42 subtype 9 (dataset TYPE4237) was validated and
VMAC42 revised, and subtype 19 records showed wholesale revision
Feb 9, 1999 from their earlier documentation. Revised in 10Feb tape.
Thanks to Edward McCarthy, Health Insurance Commission, AUSTRALIA.
======Changes thru 16.364 were in MXG 16.10 dated Feb 8, 1999======
Change 16.364 QA test and MXG 16.04+ revision cleanup analysis:
DOC -TYPETMS5: PROC DELETE DATA=MGTMSVL; added after last use.
Feb 8, 1999 -SPUNJOBS: Variable DATETIME now formatted.
-MNTHDB2S: Variable STRTTIME now formatted.
-VMACTMDB: Variables D6ACBSC/D6ACESC now formatted.
-VMACVMXA: Variable DELTATM is now LENGTH 4 instead of 8.
-VMACEDGS: EDGSV: and EDGSU: added to dataset labels.
-VMACIMS/VMACIMSA: dddddd: added to dataset labels.
-TYPEMON8: dddddd: added to dataset labels.
-VMACOPC: OPC20: added to dataset label.
-VMAC28: L028IN7: corrected to 028IN7:.
-VMAC42: TY42P2: was missing colon in label.
-VMACMDF: Dataset Label was added.
-VMACHMF: Dataset Labels were added where missing.
-DIFFTPX: Dataset Labels was added.
-DIFFNTCP: Dataset Labels was added.
These products are not yet converted to the 16.04 design,
because they are second phase processes that don't read
raw data and don't really need the additional macro names
but they will eventually be revised to be consistent:
TRND70,TRND70PR,TRND71,TRND72,TRND27GO
TRNDDB2A,TRNDDB2S,TRNDDBDS,TRNDIDMS,TRNDRMFI,TRNDVMXA,
MNTH70,MNTH70PR,MNTH71,MNTH72,MNTHCICS,MNTH72GO MNTHDB2A
MNTHDB2S,MNTHDBDS,MNTHRMF,RMFINTRV.
VMXGHSM - does read HSM catalogs, but is standalone.
These products have not yet been 16.04 converted, and
won't be until someone asks for it, or until a change in
data requires an enhancement in these either standalone
or archaic programs:
TYPECRAY, TYPEFACO, TYPEPDL, TYPEVLFC, TYPEWWW, TYPEZARA
TYPE200, TYPETPNS, TYPERRTM.
Change 16.363 16.09 only, JCLTEST6 only. The new VMACMVCI for CMRDETL
JCLTEST6 still had RECFM=S370VB from PC testing, and MVS SAS does
VMACMVCI currently accepts only RECFM=VB, (although SAS has plans
Jan 21, 1999 for a fix to make S370VB an alias on MVS in Version 8?).
Change 16.362 The dataset name in MACRO _LHSMFUN should be HSMDSRFU.
VMACHSM The typo, HSMFSRFU, has never been a real dataset.
Feb 5, 1999 This 16.04 error has impact only if you used the _LHSMFUN
macro as the destination of your own PROC SORT, or if you
used the new _SHSMFUN macro; that created PDB.HSMFSRFU
instead of PDB.HSMDSRFU (but since it has all of the
variables, you can just rename it back to PDB.HSMDSRFU
without re-read of your SMF data).
Thanks to John McCray, Huntington Services Company, USA.
Change 16.361 Support for IDMS Version 14 Journal Records. Most IDMS
TYPEIDMJ sites write to SMF rather than a journal, and the SMF
VMACIDMJ records were fine, but the TYPEIDMJ support for journal
Feb 5, 1999 format had not been updated from IDMS Version 12! This
change only works with Version 14 data; I didn't take the
time to write it to work with both, as I don't think you
can be still running Version 12, but if you need it, I'll
enhance it for the old version too!
Thanks to David Thorn, Dow Jones, USA.
Change 16.360 -VMAC110: 16.09 only, new time variables in CICDS and in
IMACICOM CICINTRV did not have TIME12.2 format.
VMAC110 -IMACICOM: several MQxxxxTM duration variables had the
VMACDB2 same label as the MQxxxxCN count variables.
VMACTMDB -VMACDB2: new variables QXCOORNO/QXCRGTT/QXISORR/QXSTREOP
TYPETMON and QZZCBPNX/QZZCSKIP were missing because they had been
TYPEMONI added to the KEEP= list for DB2STAT0 instead of DB2STAT1.
Feb 5, 1999 -VMACTMDB: variable LMRKFLG1 was listed twice in FORMAT
statement; the last instance - $HEX2. - was removed as
it was overriding the $MGTMDGF decoding format.
-Archaic TYPETMON and TYPEMONI were upgraded to the 16.04
architecture, mostly for QA purposes than real need, as
both are archaic (replaced by TYPETMO2 and TYPEMON8).
Thanks to Chris Weston, SAS Institute ITSV Development, USA.
Change 16.359 Change 16.204 externalized tailoring for IMACACCT among
IMACACCT others, but the &MACACCT; statement was not added to
Feb 3, 1999 the end of the IMACACCT member until now.
Thanks to Paul Oliver, BHP, AUSTRALIA.
Change 16.358 TYPE39_6 variables DURATM, STARTIME, in the SCS segment
VMAC39 were originally only created in Netmaster records, but
Feb 3, 1999 became unneeded when IBM added ACTSTIME/ACTETIME to the
accounting segment. I never noticed, but now in NetView
for OS/390 Version 1 Release 1 type 39 records, IBM has
put several character fields where those old fields were
input, causing strange dates (like 2008) when MXG reads
those characters as TODSTAMP datetimes! The unneeded old
Netmaster variables are now set missing/blank, and the
new fields (Primary/Secondary CP NetworkID/Name and APPN
class of service name and APPN transport priority) were
added to each of the subtype 1-8 TYPE39 datasets.
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 16.357 Variable DDNAME was not kept in TYPETMNT, but no one had
VMACTMNT need of it. But now, in developing a new MXG tool that
Feb 3, 1999 decomposes all job delays, we find DDNAME is needed so we
can detect "parallel" tape mounts (when one tape DD has
multiple tape drives allocated) so we can not-include the
second-and-subsequent mount delays in the job delay total
(the reason you allocate two drives for one tape DD is so
that the rewind/mount time of one is in parallel with the
job's use of the other, to prevent any delay to the job).
Change 16.356 Support for Sterling's SOLVE NetMaster for TCP/IP SMF
EXTYSOLN creates one observation in dataset TYPESOLN for each
FORMATS record (which are identified as either interval or
IMACSOLN event), decoding as many of the up-to-12 fields that
TYPESOLN might be present. Variable ATTRID identifies what is
VMACSOLN measured in each record, and has values in mixed case
VMXGINIT (like "ifInPktsNUcast" and "ifInPktsDiscard") for each
Feb 3, 1999 metric. There are nearly 60 metrics available:
TCP/IP Stack: FTP/TELNET/Workload Connection activity
TCP/IP Node Monitor: SNMP counters/response/available
CISCO Monitor: Channel card load/errors/TN3270 use
Local Interface: Status and Thruput
The complete list and description is in SOLVE:Netmaster
Graphical Performance Manager User's Guide, Appendix C,
Attribute Descriptions.
Thanks to Wendy Wong, Sterling (Field Engineer), AUSTRALIA
Change 16.355 The DB2 Buffer Hit Ratios calculated in DB2STATS became
VMACDB2 negative because the TSPP field apparently should not be
Feb 2, 1999 included. The old equation TGET-(TSIO+TDPP+TLPP+TSPP)
had values of 175-(101+0+0+1621) so clearly TSPP is out
of place, and thus has been removed from the equations
for B1HITRAT/B2HITRAT/B3HITRAT/B4HITRAT and BPHITRAT.
I am now looking for an IBM update to their equations.
Change 16.354 There are additional fields captured in HPs MeasureWare
VMACMWSU for Sun that can now be output; some fields were removed
Feb 2, 1999 and some were reordered. The new fields are defined, but
you may need to compare the headings of the report with
the MXG input sequence to see that they are the same.
Thanks to Tim Crocker, NCCI, USA.
Change 16.353 The RMF WKLD Workload Activity Report was updated for
ANALRMFR OS/390 MODE=COMPAT, the WLMGL Report RPTORP=RCLASS
Feb 2, 1999 SCLASS SCPER has been updated for MODE=GOAL, the WGPER
Feb 20, 1999 BY lists now have BY SYSPLEX STARTIME ....
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 16.352 Some report/summary members had not been revised for the
ANALARB 16.04+ architecture and still %INCLUDEd their product's
ANALDB2R IMACxxxx member instead of its VMACxxxx member. As long
ANALPDSM as the program ran in the same step that built its data
ASUMHPSU sets, there was no error, because the VMACxxxx member
ASUMHPUX would have already been %INCLUDEd, but standalone runs
Feb 2, 1999 caused SAS "180" syntax errors due to missing macros.
MXG no longer defines macros in the product IMACxxxxs,
but instead MXG defines its macros in the VMACxxxx's,
which themselves include the IMACxxxx if you have one.
any overrides of the MXG defaults.
But not all includes of IMACxxxx members were changed,
as there are non-product IMACxxxx members (IMACRMFI)
that are still validly included by these programs.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.351 -Support for BETA93 3.1.3 Subtypes 1, 2, 3, 4, 20, 40, 41
FORMATS and 42 has been validated with single-record tests. In
VMACBETA one subtype 20, the READ DATE and TIME are invalid, which
Feb 2, 1999 means variable READTIME (which is necessary to match the
Beta records to other SMF records for the job accounting)
has a missing value, so the Beta records can't be matched
to their jobs other data! In the one test record:
valid LINP date invalid LJOB date
S20LINPT+S20LINPD S20LJOBT+S20LJOBD
time cyyddd time cyyddd
'0064B47A 0095001F' '00000000 0100000F'x
That record was written on 2Nov98; the 95 date shows the
document has been around for a while. This discovery
will be forwarded to the MXG site to forward to the Beta
vendor for response and correction. I will update this
MXG note when I hear back from the vendor, but since the
invalid date causes a hex dump of the record on the SAS
log, I have added "??" to suppress the dump and message.
Create the Beta datasets and use PROC MEANS N DATA=....
to see how many records have invalid data for READTIME.
-Existing format MGBETRT for variable BETAATT4 was updated
since it now has character rather than hex values.
Thanks to Wolfgang Prescher, Quelle, GERMANY.
Change 16.350 Support for WINDOWS NT 5.0 (INCOMPATIBLE) for NTSMF adds
EXNTAPLT new objects and new counters, but NT 5.0 appears to have
EXNTGWNW removed some important data:
EXNTHTIS =Changes to existing supported objects:
EXNTINSF -SYSTEM object removed all of the CPU busy fields; these
EXNTINSR variables will have missing value in the SYSTEM dataset:
EXNTJOB APCBYPAS DPCQUERT DPCRATE DPCBYPAS INTERUPT
EXNTJOBD PCTCPUTM PCTUSRTM PCTPRVTM PCTDPCTM PCTINTTM
EXNTMACF But those variables are also in the PROCESOR dataset
EXNTPRNQ (although per-CPU instead of per-interval), and NTINTRV
EXNTRASI logic sums those PROCESSOR variables into the interval
FORMATS CPU busy measures (by accident, because it happens that
IMACNTSM the MERGE statement lists SYSTEM before PROCESOR, and SAS
VMACNTSM always takes values from the last dataset when the same
VMXGINIT variable is in multiple datasets), so you should make
Feb 1, 1999 sure you are creating the Processor object so you can get
Feb 4, 1999 those most-important measures in PDB.NTINTRV dataset.
And if you were using dataset SYSTEM in your reporting
for those fields, you'll need to change to use PROCESOR
or PDB.NTINTRV for the interval utilizations in NT 5.0.
Two new variables, PROCESES and THREADS were added to the
SYSTEM object to count processes and threads.
-LOGLDISK object no longer has the physical disk name,
variable PDSKNAME, so you can't recognize which logical
disks are on which physical devices! Two new measures
PCTIDLE (percent idle time) and SPLTIORT (SPLIT I/Os per
second) were added to this object.
-PHYSDISK object has the same two new measures, PCTIDLE
and SPLTIORT that were added to LOGLDISK object.
=New objects, their "NTdddd" suffix and dataset name:
suffix dataset
AppleTalk NTAPLT APPLETLK
Gateway Service for Netware NTGWNW GTWYNETW
Http Indexing Service NTHTIS HTTPINSR
Indexing Service NTINSR INDEXSRV
Indexing Service Filter NTINSF INDSRVFL
Job Object NTJOB JOB
Job Object Details NTJOBD JOBDETLS
MacFile Server NTMACF MACFILE
Print Queue NTPRNQ PRINTQUE
RADIUS Server [IAS] NTRASI RADIUIAS
This support is based on Windows NT 5.0 Beta 2 discovery
records, and some records have been tested, but none of
new objects yet. NT 5.0 is to be renamed Windows 2000.
With 486 processors and NTSMF earlier than 2.2, an INPUT
STATEMENT EXCEEDED RECORD LENGTH on the 0.0 record is now
avoided; the CPUSPEED fields are now only input if your
NTSMF version is 2.2 or higher.
Change 16.349 The statement SQRTARG=(SSQELAP/TRANS-(RESPAVG**2);
ASUMCICS caused INVALID ARGUMENT TO SQRT function because it
ASUMCICX should have been IF TRANS GT 0 THEN SORTARG=(....
TRNDCICS Change 16.137 protected for negative square roots, but
TRND72 did not protect for zero divide with zero transactions.
Jan 30, 1999
Thanks to Normand Poitras, ISM, CANADA.
Change 16.348 The internal _PDB6 macro was enhanced, adding variables:
BUILD005 BINUSED BIN1BNCT BIN2BNCT BIN3BNCT BIN4BNCT
BUIL3005 BIN5BNCT BIN6BNCT BIN7BNCT BIN8BNCT BIN1USED
Jan 30, 1999 BIN2USED BIN3USED BIN4USED BIN5USED BIN6USED
BIN7USED BIN8USED
so they are kept in PDB.PRINT to measure bin activity.
Thanks to John A. Rivest, TDS-Computing Services, USA.
Change 16.347 Preliminary report merges datasets HSMFSRST and PDB.JOBS
ANALALOC to report how much of ALOCTM allocation delay was due to
Jan 30, 1999 HSM recall (and recall time spent queueing for an HSM
Feb 17, 1999 thread is separated from actual recall time), and how
much was real allocation delay. Further enhancements to
bring in other delay records (e.g., MXGTMNT allocation
and tape mount delay) are planned, to ultimately provide
measurement of each separable delay in a job's life.
Revised, Feb 17, 1999, but does not yet account for
overlap of mount times when parallel devices mounts are
used (i.e., multiple tape devices for one DD).
Thanks to Rebecca Cates, PKS Computer Services, USA.
Change 16.346 Thruput Manager SMF records with no token entries caused
VMACTPMX ERROR.VMACTPMX. TOKEN NOT FOUND, FIELD WAS NOT INPUT.
Jan 30, 1999 because MXG logic assumed there would always be tokens.
Change the DO UNTIL (NEXLOC=0); to now read
IF OFFXFE GT 0 THEN DO UNTIL (NEXTLOC=0);
and the record will be output.
Thanks to Joseph Montana, Trans Union Corporation, USA.
Change 16.345 Enhanced HSM summarization now separates the HSM delay
ASUMHSM into active and queued requests so you can track HSM's
TRNDHSM concurrent thread count, used and required. Triggered
Jan 30, 1999 by the new ANALALOC program, in Change 16.347, and now
used by the revised ANALHSM in Change 16.383.
Change 16.344 RMF Reports are enhanced:
ANALRMFR -Coupling Facility, Average CF utilization corrected.
FORMATS PCTCFBSY, if logical processors present, calculate
Jan 30, 1999 using logical processor effective.
-Updates PARTITION DATA REPORT for deactivated LPARs.
The values for counts in the MXG reports, will be
output as they are in the MXG/SAS database. (IBM
reports counts as 80K but ANALRMFR shows 80396).
Some values (standard deviation, delay time and /all
time), are still in development/validation.
-ADD Subchannel Activity Report.
-Format MGRMFF was revised to round percentages better.
Thanks to Scott Wiig, USBank, USA.
Change 16.343 Using JCLIMSLG/ASMIMSLG logic to read IMS log records for
VMACIMSA IMS FastPath transactions created zero observations in
Jan 30, 1999 IMSFASTP dataset, because the variable SUBCODE was not
kept in the IMS591,593,596,597, and IMS598 datasets.
The variable was added to the KEEP= list for those five
datasets (but Pete just used the five _KIMS59x macros
to add SUBCODE to circumvent the error in the interim).
Also, the PUT _ALL_'s that were unlimited will now only
print for the first five instances of unmatched fastpath.
Thanks to Pete Gain, SAS Software Pty, ENGLAND.
Change 16.342 New variable CECSER, the CPU SERIAL NUMBER OF THE CEC,
VMAC7072 (Central Electronic Complex) is created from CPUSER in
Jan 29, 1999 TYPE70 and TYPE70PR datasets, to identify the hardware
box in which this MVS system ran. The last two bytes of
CPU Serial (CPUSER) are converted to hex representation
and stored in the new 4-byte character variable CECSER,
so a CPUSER='03870F'X has CECSER='870F'.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 16.341 IMACPDB documentation. No code was changed.
BUILD005 The new architecture eliminates tailoring member IMACPDB,
BUIL3005 but I failed to document how! Previously, you EDITed the
IMACPDB macros (_PDB6, _PDB26J2, etc.) in IMACPDB to add fields
ZMACPDB (not kept by default) from type 6, 25, 26, and 30 SMF
Jan 29, 1999 records, into the PDB.JOBS, PDB.STEPS, and PDB.PRINT
datasets. But then you had to update your IMACPDB each
time when I changed something, because your IMACPDB will
(still) override my defaults. But now, with the 16.04+
design, you can instead use the &ADDxxxx macro variables,
with %LET ADDxxxx= var1 var2 ... ; syntax, to add your
variables. Your %LET can be in member IMACKEEP or can
be in the SYSIN stream using the "MACKEEP=". So if you
have an IMACPDB member, compare it with the old member in
ZMACPDB to see what your site added, and use the %LETs to
add those variables and eliminate your IMACPDB.
The new macro variable names and their function are:
MACRO Variable For Dataset/Function
ADD6 TYPE6
ADD25 TYPE25 (JES3 only)
ADD26J2 TYPE26J2 (JES2 only)
ADD26J3 TYPE26J3 (JES3 only)
ADD30U1 TYPE30_1
ADD30U4 TYPE30_4
ADD30U5 TYPE30_5
ADDACT2 Account fields back-merged
from JOBS to STEPS/PRINT
(JES2 only)
ADDACT3 Account fields back-merged
from JOBS to STEPS/PRINT
(JES3 only)
The macros formerly defined in IMACPDB member are now
defined in members BUILD005 (JES2) or BUIL3005 (JES3).
Thanks to Mike A. Geiger, A. C. Nielsen, USA.
Change 16.340 Some variables in ENDEAVOR dataset ENDEVRSE were wrong
VMACENDV because the end-of-comment was missing after the INPUT
Jan 29, 1999 of variable EDVIFUNC, causing out-of-alignment.
Thanks to Kenneth D. Jones, SHL Systemhouse, CANADA.
Change 16.339 Type 42 subtypes 15-19 (VSAM RLS) now exist and test data
VMAC42 exposed IBM errors: their length field in the triplet has
Jan 29, 1999 total length, instead of the length of the segment, which
caused MXG to DELETE all the records with a WRONG LENGTH
message on the log because of this invalid length value.
MXG circumvents by constructing the segment length from
the total length and number of segments. However, IBM
has changed some fields after the early documentation,
and real data corrected several typos & logic errors so
that now each repeated segment will be output. Also, all
TYPE42xx datasets now have their _BTY42xx "By" and their
_STY42xx "Sort" macros implemented.
Thanks to Ed McCarthy, Health Insurance Commission, AUSTRALIA.
Change 16.338 The old &PDB70,&PDB71,...&PDB78 macro variable names were
ASUM70PR still used as the source DDNAME of the TYPE7xxx datasets
RMFINTRV that are read into RMFINTRV, but in the new 16.04+ design
Jan 28, 1999 those names should have been &PTY70,&PTY71... PTY78.
There was no execution error, because both sets of macros
variable names have default values of "PDB", but if you
tried to use the new 16.04+ tailoring to split your PDB
into multiple destinations, DATASET NOT FOUND errors
would result. All of the &PDB7xxx's are now &PTY7xxx's.
Note that &PDBRMFI is still the name for RMFINTRV.
-Same error in ASUM70PR, but &PDB70PR is now &PTY70PR.
Thanks to Linda Carroll, IBM Global Services, USA.
Change 16.337 -Support for these new NT objects:
EXNTBENC -DB2 NT DATABASE MANAGER object creates dataset DB2.
EXNTDB2 with one instance variable and 15 counter variables.
EXNTFAXG -FAX SR. GATEWAY MONITOR object creates dataset FAXGATEW,
EXNTMSCC with one Instance variable and 8 counter variables.
EXNTPCHB -VPN ADAPTER object creates VPNADAPT dataset with two
EXNTRADI Instance variables and 15 counter variables.
EXNTUSER -Terminal Server object USER creates dataset USER with
EXNTVINE one instance variable (USER) and the other fields in the
EXNTVPN PROCESS object (except for IDUSER/IDLOGON!).
FORMATS -Radius Server object creates dataset RADIUS, but only
IMACNTSM discovery records have been read.
VMXGINIT -Benchmark Factory object creates dataset BENCHMRK, but
VMACNTSM only discovery records have been read.
Jan 30, 1999 -Microsoft Exchange object MSExchangeMSCC created MSEXCHCC
with counts and rates of mail activity between Exchange
and Lotus CC:MAIL. Only Discovery have been read.
-Vines Communications object creates dataset VINES with
33 counters.
=Enhancement/correction to existing NT objects:
-PROCESS dataset variables IDLOGON and IDUSER had missing
values, because MXG had a test for NRDATA=20 instead of
NRDATA=21. The WIDE2MBE variable was renamed to CREATPID
when Demand Technology was able to discover what was put
in that undocumented field (Creation Process ID).
-WINPROXY dataset has two variables now removed from the
record (but MXG still creates them, with missing value,
so your reports won't die), and five new fields were
added (incompatibly, of course!).
Thanks to Jim Quigley, Consolidated Edison, USA.
Change 16.336 IBM Documentation for NPM 2.4 is wrong, causing STOPOVER
VMAC28 error with NPMSUBTY='DD'x record. The VTT section has a
Jan 26, 1999 documented length of 196 bytes, but records with only 176
bytes (thru VTTNNCDS) are being created by IBM. To avoid
the error, two lines were inserted in the VTT input:
VTTNNCDS &PIB.4. original line
@; inserted line
IF LENAOF GE 196 THEN INPUT inserted line
VTTNRRGC &PIB.4. original line
Mar 10, 2000: APAR OW37758 fixed the 2.4 error, but that
APAR was not applied to the 2.5 release, so APAR AW43578
exists for 2.5, with no PTF. See Change 18.032.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 16.335 Variables H15TCSDT and H15TCEDT in TYPERDSn RDS datasets
VMACRDS have never been correct, because MXG used JULDATE() where
Jan 22, 1999 it should have had DATEJUL(). No one noticed/complained,
probably because variable SMFTIME was valid, but now the
dates use DATEJUL() and its protection algorithm.
Thanks to Forrest Nielson, State of Utah, USA.
======Changes thru 16.334 were in MXG 16.09 dated Jan 20, 1999======
Change 16.334 Variable INNODE in TYPETPMX was changed to INNODEC, from
VMACTPMX numeric to character because INNODE was already defined
Jan 19, 1999 as numeric in other datasets created from SMF records.
Change 16.333 ADSM data transfer units were true Kilobytes so their
VMAC42 multiplier is changed from 1000 to 1024 for variables
Jan 17, 1999 ARCBYTCS,BKPBYTCS,DATBYTCS,ARCBYTRE and BKPBYTRE in
dataset TYPE42AD. I guessed the 1000 because most of
storage in IBM "KB" means 1000 rather than 1024, but
this guess was wrong.
Thanks to Kristyann Manske, University of Wisconsin-Milwaukee, USA.
Change 16.332 Variables DPRTY and IODP are both now formatted as HEX2.
VMAC99 to be consistent with historic priority ranges that are
Jan 17, 1999 commonly in hex (00-FF) rather than decimal.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.331 "Cosmetic Audit" of duplicate variables in LABEL, LENGTH
DOC and FORMAT statements, incorrect dataset name in comments
Jan 17, 1999 and _L macro names where _W macro names belong, and other
similar typos were corrected in these members:
VMAC102 VMAC110 VMAC28 VMAC30 VMAC40 VMACAPAF
VMACCIMS VMACCIMS VMACCMF VMACCMFV VMACDCOL VMACHSM
VMACICE VMACILKA VMACIMS VMACIMSA VMACMWAI VMACMWUX
VMACNTSM VMACPW VMACRMFV VMACVMON VMACVMXA
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.330 Status of MXG Year 2000 Support as of Jan 20, 1999.
ASUMHSM
TYPE80A MXG 16.09 is now required for full Year 2000 Support of
TYPEBETA all fields in all records from all supported products.
TYPEDCOL This replaces all prior statements of MXG Y2K Support.
TYPEHSM
TYPEMON8 MXG 16.01 and later do support almost all products, but
TYPEMOND five common products now require MXG 16.09 or later:
TYPEOPC HSM SMF Records
TYPETMON CA-1 aka TMS Tape Management Records
TYPETMS5 BETA93 SMF Records
TYPETMV2 Landmark Monitor for MVS Version 2
TYPETMVS VM Accounting records
TYPEVLFC Additionally, six other products that have variables
TYPEVM that were not Y2K compliant, but those variables were
YEAR2000 unlikely to have been used in your reports:
Jan 17, 1999 DCOLLECT - one julian date variable, UCCOLDT
Jan 20, 1999 OPC/A - three obscure julian date variables
Landmark - CICS: TYPEMON8,TYPETMON,TYPEMOND
MVS: TYPETMV2,TYPETMVS
one internal datetime TMMDCCLK.
ASTEX - one julian date SDATE
RACF SMF - two variables REVOKEDTE, RESUMEDTE
VLF - VLF Catalog records from SYSLOG.
Products were found with julian dates that were kept as
0cyyddd value (0100001 for 01Jan2000), which is a valid
Y2K format, but which is one not supported by SAS's
DATEJUL() function, so while MXG correctly created valid
Y2K values, your reports or exit logic would fail if they
used DATEJUL() on those 0cyyddd values. No ABEND, but
missing values or invalid argument messages on your log.
For example, TMS records have julian date values like the
EXPDT that are kept as 0cyyddd that could cause problems.
This DATEJUL() problem itself is not new. MXG reported
it and has provided an algorithm (described in member
YEAR2000, implemented by Change 15.050) that protects
julian dates as they are converted into SAS DATETIME
or DATE variables, which are Y2K compliant. But that
algorithm did not change the raw julian date value.
This change revises the protection algorithm so that it
now replaces the original 0cyyddd value with the valid
yyyyddd value in the raw julian date variable, unless the
yyyyddd value is missing (i.e., an invalid "date" like
99000), when the original raw value is not overwritten.
ASUMHSM testing with Y2K HSM records exposed the error,
and I realized that TMS and all products that keep julian
date variables were exposed, so every MXG member that had
a julian date field was examined, and I found four more
with the kept-julian-date-problem. I also found six
products (nine variables) that had been overlooked by MXG
Change 15.050 that were having unprotected sex with the
DATEJUL() function. All are now algorithm-protected.
Members with kept-julian-date-fields and the variables
that are now converted to yyyyddd:
TYPEDCOL UCCOLDT
TYPEHSM DSRDATE,VSRDATE,FSRBDATE,FSRDATR,FSRDLM,
FSRDLU
ASUMHSM DSRDATE
TYPEOPC TRLEVDAT,MT0CPED,MT0DAT
TYPETMS5 BTHDATE,CRTDT,DSADT,EXPDT,TMVADATE,LDATE,
TMAUDATE
TYPETMV2 JDRDATE
TYPETMVS (archaic) JDRDATE
Members overlooked in Change 15.050 and the variables
that are now protected:
TYPEBETA BETASTRT, BETAEND, BETASTSE, BETAENSE
TYPEDMON SDATE
TYPEHSM WFSRDATR, WFSRDATS, WFSRDATE
TYPETMV2 LMRKDATE, ENDTIME, STRTTIME
TYPETMVS (archaic) LMRKCARK
TYPE80A REVOKDTE, RESUMDTE
TYPEMOND TMMDCCLK
TYPEMON8 (archaic) TMMDCCLK
TYPETMON (archaic) TMMDCCLK
TYPEVLFC DATETIME
TYPEVM STARTIME, ENDTIME
In addition, thirty-five other members were changed
to streamline the algorithm where the creation of the
DATEYYYY variable was not required. These members
were and still are Y2K compliant, but are now more
robustly protected and their non-kept julian dates
are now converted to yyyyddd format:
TYPE90,TYPE84,TYPE434,TYPE37,TYPE1415,TYPE110,
TYPECTLT,TYPEFILA,TYPEIDMJ,TYPEIDMS,TYPEIMS,
TYPEIMSA,TYPEIPAC,TYPEITRF,TYPENDM,TYPENETP
TYPENSPY,TYPEOMVT,TYPEPDSM,TYPEROSC,TYPESIM,
TYPETRMS,TYPEWSF,TYPEXCOM,TYPEXSTR,TYPESUPR,
TYPESLRI,TYPERTEJ,TYPEDMS,IDMSLO57,IDMSJRNL,
ANALTMS,ANALSNAP,ANALRACF,ANALCM29
Thanks to John McCray, Huntington Services Company, USA.
Thanks to Xiaobo Zhang, Insurance Service Office, USA.
Change 16.329 Support for OS/390 R 2.7 (COMPATIBLE) adds new subtypes,
EXTY746B records, and segments:
EXTY746F -RMF type 74 record has new subtype 6 which creates three
EXTY746G new MXG datasets describing Hierarchical File Systems.
FORMATS While storage size fields in the raw record are in pages
VMAC42 or MB, MXG converts them all to bytes and formats with
VMAC7072 MGBYTES so the storage variables have the same, standard
VMAC73 units that display as MegaBytes, GigaBytes, etc.
VMAC74 -TYPE746G - HFS Global Statistics - one per interval
VMAC79 R746G1C ='FIRST PAGE*FINDS*IN CACHE'
VMXGINIT R746G1NC='FIRST PAGE*NOT FOUND*IN CACHE'
VMAC109 R746GLRC='RETURN CODE*BPX1PCT*BUFFLIM'
EXTY109 R746GLRS='REASON CODE*BPX1PCT*BUFFLIM'
IMAC109 R746GMC ='METADATA*FINDS*IN CACHE'
TYPE109 R746GMNC='METADATA*NOT FOUND*IN CACHE'
TYPS109 R746GMNF='VALUE OF FIXED(MIN)'
Jan 16, 1999 R746GMXV='VALUE OF*VIRTUAL(MAX)'
R746GSFL='STATUS FLAGS'
R746GSRC='RETURN CODE*BPX1PCT*GLOBSTAT'
R746GSRS='REASON CODE*BPX1PCT*GLOBSTAT'
R746GUSF='PERMANENT*FIXED*STORAGE*IN USE'
R746GUSV='VIRTUAL*STORAGE*IN USE'
-TYPE746B - HFS Buffer Statistics - one per buffer pool
R746GBF ='BUFFER*WAS FIXED*PRIOR TO*IO REQUEST'
R746GBNF='BUFFER*WAS NOT FIXED*PRIOR TO*IO REQUEST'
R746GNDS='NUMBER OF*DATA SPACES*FOR BUFFER POOL'
R746GSB ='SIZE OF*BUFFERS*IN BUFFER POOL'
R746GSBN='BUFFER*POOL*NUMBER'
R746GSBF='SIZE OF*PERMANENT*FIXED*BUFFERS'
R746GSBP='SIZE OF*BUFFER*POOL'
-TYPE746F - HFS File System Detail Statistics
R742PSNM='FILE*SYSTEM*NAME*(DSN)'
R746F1C ='FIRST PAGE*WAS FOUND*IN CACHE'
R746F1NC='FIRST PAGE*NOT FOUND*IN CACHE'
R746FCTM='CURRENT*TIME*STAMP'
R746FIJ ='INDEX JOINS'
R746FINT='INDEX NEW TOPS'
R746FIRH='INDEX PAGE READ HITS'
R746FIRM='INDEX PAGE READ MISSES'
R746FIS ='INDEX SPLITS'
R746FIWH='INDEX PAGE WRITE HITS'
R746FIWM='INDEX PAGE WRITE MISSES'
R746FMC ='METADATA WAS FOUND IN CACHE'
R746FMNC='METADATA NOT FOUND IN CACHE'
R746FMTM='MOUNT*TIME*STAMP'
R746FPC ='DATA BUFFER BYTES CACHED BY THIS FILESYS'
R746FPD ='BYTES USED FOR ATTRIBUTE*DIRECTORY'
R746FPF ='BYTES*INTERNALLY*USED*BY HFS'
R746FRFI='RANDOM FILE DATA I/O REQUESTS'
R746FSF ='BYTE SIZE OF*FILE*SYSTEM'
R746FSFI='SEQUENTIAL FILE DATA I/O REQUESTS'
R746FSFL='STATUS*FLAGS'
R746FSNL='LENGTH OF*FILE*SYSTEM*NAME'
R746FSRC='RETURN CODE*BPX1PCT*FSSTATS'
R746FSRS='REASON CODE*BPX1PCT*FSSTATS'
-RMF type 70 record has new bit values for SMF70PFG that
MXG decodes into two new variables in TYPE70PR:
LPARCHDE='NUMBER OF*DEDICATED*PROCESSORS*CHANGED?'
LPARCHSH='NUMBER OF*SHARED*PROCESSORS*CHANGED?'
-RMF type 73 record has new CPMF (Channel Path Measurement
Facility) mode variable in dataset TYPE73:
SMF73CMI='CPMF*MODE'
which is decoded by the new MG073CP format:
0='0:CPMF IS NOT ACTIVE'
1='1:COMPATIBILITY MODE'
2='2:EXTENDED MODE'
-RMF type 79 record subtype 12 also has a new CPMF*MODE
variable in dataset TYPE79C
R79CCMI='CPMF*MODE'
that is also decoded by the new MG073CP format, above.
-SMF type 42 subtype 5 and 6 contain new field S42DSDAO
that MXG creates in datasets TYPE42DS, TYPE42SR, and
TYPE42VT as new variable named:
AVGDAOMS='AVERAGE*I/O DEV-ACTIVE-ONLY*MS PER SSCH'
-New SMF type 109 record is written by OS/390 Firewall
Server, and contains log messages of firewall activity
that appear to be quite useful to security folks. The
ICAxxxxx and ICACxxxx message structure will be decoded
when I have test data from an interested site; for now,
those messages are just carried as text strings.
These changes have not been tested with 2.7 data yet.
Change 16.328 For Percentile Goal Service Classes, a new MXG variable
VMAC7072 PCTMETGO reports the actual percentage of transactions
Jan 14, 1999 that met the goal. For example, take a Service Class
Sep 17, 2002 that has a goal value of 1 second. Its MAP values are
actually percentages of the goal and the product of the
MAP value and the goal value is the response time value.
If the goal is 90% in 1 second, and your data values are:
MAP .5 .6 .7 .8 .9 1 1.1 1.2 1.3 1.4 1.5 2 4 FF
TRN 8638 108 101 69 59 53 56 43 42 30 1 147 134 22
then 90.9% (8638/9503) of those transactions ended in the
first bucket, in one-half-second. You easily met your
90%-in-one-second goal; in fact 90% of your transactions
were satisfied in less than 50% of your goal value, so
your goal is being met at a level of 50% of the response
time goal, so IBM's PERFINDX is 0.5, "twice as good".
(See why you need to be careful with percentages,
and always include, "of what").
But if we sum the number of transactions in the first six
buckets (i.e., those transactions whose response time was
less than or equal to the goal value), there were 9028 of
the 9503 transactions (95%) that met the one second goal,
and the value of new variable PCTMETGO=95.00.
Thanks to Chuck Hopf, MNBA, USA.
Change 16.327 For Service Classes with Average Goal value that had no
VMAC7072 delay samples (i.e., PCUTSOU=0 and PCTDLTOT=0), VELOCITY
Jan 14, 1999 cannot be calculated so it was missing value, but MXG
then erroneously set PERFINDX to zero, even when it
could be calculated. The original logic:
IF (TRANS EQ 0 AND TRANSEXC GT 0) OR R723CRGF='A' THEN ..
IF R723CVAL LE 0 OR VELOCITY LE 0 THEN PERFINDX=0;
ELSE PERFINDX=AVGELPTM/R723CVAL;
END;
now has the test for VELOCITY removed:
IF (TRANS EQ 0 AND TRANSEXC GT 0) OR R723CRGF='A' THEN ..
IF R723CVAL LE 0 THEN PERFINDX=0;
ELSE PERFINDX=AVGELPTM/R723CVAL;
END;
Thanks to Chuck Hopf, MBNA, USA.
Change 16.326 TYPE72 for Compatibility Mode OS/390 R2.4+ was incomplete
VMAC7072 as new delay variables were input in the subtype 3 SMF
Jan 14, 1999 record for WLM Goal Mode, but were not input for the
subtype 1 Compat Mode record. These variables are new:
SMF72ADT='INELIGIBLE*AFFINITY*TIME'
SMF72CVT='JCL CONVERSION*TIME'
SMF72IOD='TOTAL*I/O*DELAYS*SAMPLES'
SMF72IOT='DASD*IOS QUEUE*TIME'
SMF72IQT='INELIGIBLE*OTHER*RESOURCE*TIME'
SMF72QDT='TOTAL*QUEUE*DELAY*TIME'
SMF72TSA='TOTAL*EXECUTION*SAMPLES'
Thanks to Rick Mansfeldt, GE Capital, USA.
Change 16.325 Documentation only; the instructions implied you needed
BLDNTPDB to run three separate BLDNTDPBs, one for DAY, WEEK, and
Jan 14, 1999 MONTH, but in fact, all you need is to use daily:
%BLDNTPDB(RUNDAY=YES,RUNWEEK=YES,RUNMNTH=YES);
and the daily will always be built, the weekly will be
built on the WEEKSTRT= date (default=MON), and the
monthly will be built on the first day of the month.
Thanks to Wayne Holzback, Reynolds Metal Company, USA.
Change 16.324 Variables R744FTIM, FSQU, FCTM, and FCSQ should have
VMAC74 been divided by 4096.
Jan 14, 1999
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.323 Change 16.271 was not supposed to change VMXGSUM, but it
VMXGSUM did; the comments around &DATETIME=DATETIME; statement
Jan 14, 1999 that were added by 16.271 have now been removed.
Thanks to Freddie Arie, Lone Star Gas, USA
Change 16.322 Support for CICS TS 1.3 (INCOMPATIBLE). IBM inserted
ADOC110 data fields in the middle of the accounting record, so
EXCICCF6 you MUST use MXG 16.09 or later to read CICS TS 1.3 data.
EXCICCF7
EXCICCF8 Lots of new measurements have been added, especially for
EXCICCF9 Web activity (and the first JAVA measurements in MVS!!!).
EXCICNC4 There are also new subtypes 3, 4 and 5, and new stat data
EXCICNC5 records and new fields added to existing statistics, and
EXCICSOR there are now 11 TCBs that CICS can dispatch!
FORMATS The type 110 subtype 1 (CICSTRAN dataset) has these 61
VMAC110 new variables added:
VMXGCICI ACTVTYID='ACTIVITY*ID'
Nov 29, 1998 ACTVTYNM='ACTIVITY*NAME'
Jan 12, 1999 BAACDCCT='ACTIVITY*DATA*CONTAINER*REQUESTS'
BAACQPCT='ACQUIRE*PROCESS*REQUESTS'
BADACTCT='DEFINE*ACTIVITY*REQUESTS'
BADCPACT='DELETE*ACTIVITY*AND CANCEL*REQUESTS'
BADFIECT='DEFINE*INPUT*EVENT*REQUESTS'
BADFTECT='DEFINE*TIMER*EVENT*REQUESTS'
BADPROCT='DEFINE*PROCESS*REQUESTS'
BALKPACT='LINK*PROCESS*ACTIVITY*REQUESTS'
BAPRDCCT='PROCESS*DATA*CONTAINER*REQUESTS'
BARACTCT='RESET*ACTIVITY*REQUESTS'
BARASYCT='RUN*PROCESS*ACTIVITY*ASYNC'
BARATECT='RETRIEVE*REATTACH*EVENT*REQUESTS'
BARMPACT='RESUME*PROCESS*ACTIVITY*REQUESTS'
BARSYNCT='RUN*PROCESS*ACTIVITY*SYNC'
BASUPACT='SUSPEND*PROCESS*ACTIVITY*REQUESTS'
BATOTCCT='TOTAL*DATA*CONTAINER*REQUESTS'
BATOTECT='TOTAL*EVENT*REQUESTS'
BATOTPCT='TOTAL*PROCESS*ACTIVITY*REQUESTS'
CFCAPICT='OO CLASS*LIBRARY*API*REQUESTS'
CFDTWACN='CF DATA*TABLE*WAIT*COUNT'
CFDTWATM='CF DATA*TABLE*WAIT*TIME'
CHMODECT='CICS*DISPATCHER*MODE*CHANGES'
CLIPADDR='CLIENT*IP*ADDRESS'
DB2CONCN='DB2*CONNECTION*WAIT*WAIT*COUNT'
DB2CONTM='DB2*CONNECTION*WAIT*WAIT*TIME'
DB2RDYCN='DB2*READY*QUEUE*WAIT*COUNT'
DB2RDYTM='DB2*READY*QUEUE*WAIT*TIME'
DB2REQCT='DB2*REQUEST*COUNT'
DB2WAICN='DB2*WAIT*WAIT*COUNT'
DB2WAITM='DB2*WAIT*WAIT*TIME'
DHCRECT ='DOCUMENT*CREATE*REQUESTS'
DHINSCT ='DOCUMENT*INSERT*REQUESTS'
DHRETCT ='DOCUMENT*RETRIEVE*REQUESTS'
DHSETCT ='DOCUMENT*SET*REQUESTS'
DHTOTCT ='TOTAL*DOCUMENT*REQUESTS'
DHTOTDCL='TOTAL*DOCUMENT*CREATED*LENGTH'
GNQDELCN='GLOBAL*ENQUE*DELAY*COUNT'
GNQDELTM='GLOBAL*ENQUE*DELAY*TIME'
IMSREQCT='IMS*REQUEST*COUNT'
IMSWAICN='IMS*WAIT*COUNT'
IMSWAITM='IMS*WAIT*TIME'
J8CPUTCN='USER TASK*J8 MODE*CPU TCB*COUNT'
J8CPUTTM='USER TASK*J8 MODE*CPU TCB*TIME'
JVMSUSCN='JAVA*VM*SUSPEND*COUNT'
JVMSUSTM='JAVA*VM*SUSPEND*TIME'
JVMTIMCN='JAVA*VM*EXECUTION*COUNT'
JVMTIMTM='JAVA*VM*EXECUTION*TIME'
L8CPUTCN='USER TASK*L8 MODE*CPU TCB*COUNT'
L8CPUTTM='USER TASK*L8 MODE*CPU TCB*TIME'
MAXOTDCN='MAX*OPEN*TCB*DELAY*COUNT'
MAXOTDTM='MAX*OPEN*TCB*DELAY*TIME'
MSCPUTCN='USER TASK*OTHER MODE*CPU TCB*COUNT'
MSCPUTTM='USER TASK*OTHER MODE*CPU TCB*TIME'
MSDISPCN='USER TASK*OTHER MODE*DISPATCH*COUNT'
MSDISPTM='USER TASK*OTHER MODE*DISPATCH*TIME'
PCDPLCT ='DPL*PROGRAM*LINKS'
PRCSID ='PROCESS*ID'
PRCSNAME='PROCESS*NAME'
PRCSTYPE='PROCESS*TYPE'
QRCPUTCN='USER TASK*QR MODE*CPU TCB*COUNT'
QRCPUTTM='USER TASK*QR MODE*CPU TCB*TIME'
QRDISPCN='USER TASK*QR MODE*DISPATCH*COUNT'
QRDISPTM='USER TASK*QR MODE*DISPATCH*TIME'
QRMODDCN='QR*MODE*DELAY*COUNT'
QRMODDTM='QR*MODE*DELAY*TIME'
RRMSURID='RRMS/MVS*UNIT OF RECOVERY*ID'
RRMSWACN='RRMS/MVS*WAIT*COUNT'
RRMSWATM='RRMS/MVS*WAIT*TIME'
RUNTRWCN='RUN*TRANSACTION*WAIT*COUNT'
RUNTRWTM='RUN*TRANSACTION*WAIT*TIME'
S8CPUTCN='USER TASK*S8 MODE*CPU TCB*COUNT'
S8CPUTTM='USER TASK*S8 MODE*CPU TCB*TIME'
SOBYDECT='BYTES*DECRYPTED'
SOBYENCT='BYTES*ENCRYPTED'
SOIOWTCN='SOCKET*IO*WAIT*COUNT'
SOIOWTTM='SOCKET*IO*WAIT*TIME'
SRVSYWCN='SERVER*SYNCPOINT*WAIT*COUNT'
SRVSYWTM='SERVER*SYNCPOINT*WAIT*TIME'
SYNCDLCN='SYNCPOINT*DELAY*COUNT'
SYNCDLTM='SYNCPOINT*DELAY*TIME'
TCBATTCT='CICS*DISPATCHER*TCB*ATTACHES'
WBCHRIN ='WEB*CHARACTERS*RECEIVED'
WBCHROUT='WEB*CHARACTERS*SENT'
WBRCVCT ='WEB*RECEIVE*REQUESTS'
WBREPRCT='REPOSITORY*READS'
WBREPWCT='REPOSITORY*WRITES'
WBSENDCT='WEB*SEND*REQUESTS'
WBTOTCT ='TOTAL*WEB*REQUESTS'
The type 110 subtype 1 (CICSEXCE dataset) adds variables:
EXCMNBTR='BRIDGE*TRANSACTION*ID'
EXCMNCPN='CURRENT*PROGRAM*NAME'
EXCMNFCN='TRANSACTION*FACILITY*NAME'
EXCMNNPX='NETWORK*UNIT-OF-WORK*PREFIX'
EXCMNNSX='NETWORK*UNIT-OF-WORK*PREFIX'
EXCMNRIL='EXCEPTION*RESOURCE*ID*LENGTH'
EXCMNRIX='EXCEPTION*RESOURCE*ID'
EXCMNTRF='TRANSACTION*FLAGS'
EXCMNURI='RRMS/MVS*UNIT OF RECOVERY*ID'
-Statistics STID=55 now creates CICDS Dispatcher Stats
dataset (replacing STID=56 or STID=57). There are now
eleven TCBs separately reported in CICDS dataset:
TCB Var Prefix Abbreviation Description
1 DSG QR Quasi Reentrant
2 DS2 RO Resource Owning
3 DS3 CO Concurrent
4 DS4 SZ Secondary LU
5 DS5 RP ONC/RPC
6 DS6 FO File Owning
7 DS7 SL Sockets Owning SL
8 DS8 SO Sockets Owning SO
9 DS9 J8 J8 Open
10 DSA L8 L8 Open
11 DSB S8 S8 Open
The CICDS labels now conain the TCB abbreviation.
-Statistics STID=67 (CICFCR dataset) has new variables:
A17DTCFP='CF*DATA*TABLE*POOL NAME'
A17DTCON='CHANGED*RESPONSES*FOR CFDT'
A17DTLDS='LOADING*RESPONSES'
-Statistics STID=42 (CICTQR dataset) has new variable:
TQRPDSMN='PDS*MEMBER*NAME'
-Statistics STID=52 (CICCONSR dataset) has new field:
A14ESTPC='PROGRAM*CONTROL*FUNCTION*SHIP*REQUESTS'
-Statistics STID=97 now creates CICNQG ENQ Manager data;
it was previously in STID=96, but not only was the STID
changed, there are four new variables:
NQGGNQSW='TOTAL*SYSPLEX*ENQUES*WAITED'
NQGGNQWT='TOTAL*SYSPLEX*ENQ*WAITING TIME'
NQGSNQSW='CURRENT*SYSPLEX*ENQUEUE*WAITING'
NQGSNQWT='CURRENT*SYSPLEX*ENQ*WAITING TIME'
-New Statistics segments and new Subtypes create seven new
datasets, but I have no test data to validate the code,
so no deaccumulation (if needed) has been written. The
contents of these new datasets are impressive:
MXG DATASET STID DSECT Subtype Description
CICTCPIP 108 SOR 2 TCP/IP Statistics
CICNCS4D 124 NCS4D 5 NC Server List Structure
CICNCS5D 125 NCS5D 5 NC Server Storage Stats
CICCFS6D 126 CFS6D 4 CFTD Server List
CICCFS7D 127 CFS7D 4 CFTD Buffer Statistics
CICCFS8D 128 CFS8D 4 CFTD Request Statistics
CICCFS9D 129 CFS9D 4 CFTD Storage Statistics
Contents of CICTCPIP - TCP/IP Statistics
SORBACKL='TCP/IP*SERVICE*BACKLOG'
SORBYTRC='BYTES*RECEIVED*(ALL SOCKETS)'
SORBYTSN='BYTES*SENT*(ALL SOCKETS)'
SORCLOSG='GMT SERVICE*CLOSE TIME*(GMT)'
SORCLOSL='LOCAL SERVICE*CLOSE TIME*(LOCAL)'
SORCUCON='CURRENT*NUMBER OF*CONNECTIONS'
SORIPADR='TCP/IP*SERVICE*IP ADDRESS'
SOROPENG='GMT SERVICE*OPEN TIME*(GMT)'
SOROPENL='LOCAL SERVICE*OPEN TIME*(LOCAL)'
SORPKCON='PEAK*NUMBER OF*CONNECTIONS'
SORPORTN='TCP/IP*SERVICE*PORT*NUMBER'
SORRECVS='RECEIVES*(ALL SOCKETS)'
SORSENDS='SENDS*(ALL SOCKETS)'
SORSERVN='TCP/IP*SERVICE*NAME'
SORSSLFL='TCP/IP*SERVICE*SSL*SUPPORT'
SORTRANA='TRANSACTIONS*ATTACHED'
Contents of CICNCS4D - NC Server List Structure
S4ASYCT ='NUMBER OF*ASYNCHRONOUS*REQUESTS'
S4CNPREF='PREFIX FOR*CONNECTION*NAME'
S4CNSYSN='OWN MVS*SYSTEM NAME*FROM*CVTSNAME'
S4CRECT ='CREATE*COUNTER'
S4DELCT ='DELETE*COUNTER'
S4ENTRCT='CURRENT*NUMBER*OF ENTRIES*IN USE'
S4ENTRHI='HIGHEST*NUMBER*OF ENTRIES*IN USE'
S4ENTRLO='LOWEST*NUMBER*OF FREE*ENTRIES'
S4ENTRMX='MAX ENTRIES*RETURNED*BY IXLCONN'
S4GETCT ='GET AND*INCREMENT*COUNTER'
S4KEQCT ='INQUIRE*KEQ'
S4KGECT ='INQUIRE*KGE'
S4POOL ='POOL NAME*PART OF*STRUCTURE NAME'
S4PREF ='FIRST*PART OF*STRUCTURE*NAME'
S4RSP1CT='NORMAL RESPONSE EVERYTHING OK'
S4RSP2CT='NO MATCHING*ENTRY*WAS FOUND'
S4RSP3CT='ENTRY*VERSION*DID NOT*MATCH'
S4RSP4CT='LIST*AUTHORITY*COMPARISON*MISMATCH'
S4RSP5CT='THE LIST*STRUCTURE*IS OUT*OF SPACE'
S4RSP6CT='IXLLIST*RETURN*CODE*OCCURRED*OTHER'
S4SETCT ='SET*COUNTER'
S4SIZE ='STRUCTURE*SIZE*(UNSIGNED*FULLWORD)'
S4SIZEMX='MAXIMUM*STRUCTURE*SIZE'
Contents of CICNCS5D - NC Server Storage Statistics
S5ANYFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S5ANYLO ='LOWEST*FREE*PAGES*(SINCE RESET)'
S5ANYMX ='TOTAL PAGES*IN THE*STORAGE*POOL'
S5ANYNAM='POOL NAME*AXMPGANY'
S5ANYPTR='ADDRESS OF*STORAGE*POOL*AREA'
S5ANYRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S5ANYRQF='GETS*WHICH FAILED*TO OBTAIN*STORAGE'
S5ANYRQG='STORAGE*GET*REQUESTS'
S5ANYRQS='STORAGE*FREE*REQUESTS'
S5ANYSIZ='SIZE OF*STORAGE*POOL*AREA'
S5ANYUS ='NUMBER OF*USED PAGES*IN THE POOL'
S5LOWFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S5LOWLO ='LOWEST*FREE*PAGES*(SINCE RESET)'
S5LOWMX ='TOTAL PAGES*IN THE*STORAGE*POOL'
S5LOWNAM='POOL NAME*AXMPGLOW'
S5LOWPTR='ADDRESS OF*STORAGE*POOL*AREA'
S5LOWRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S5LOWRQF='GETS*WHICH FAILED*TO OBTAIN*STORAGE'
S5LOWRQG='STORAGE*GET*REQUESTS'
S5LOWRQS='STORAGE*FREE*REQUESTS'
S5LOWSIZ='SIZE OF*STORAGE*POOL*AREA'
S5LOWUS ='NUMBER OF*USED PAGES*IN THE POOL'
Contents of CICCSF6D - CFTD Server List
S6CNPREF='PREFIX*FOR*CONNECTION*NAME'
S6CNSYSN='OWN MVS*SYSTEM NAME*FROM CVTSNAME'
S6ELEMCT='CURRENT*NUMBER OF*ELEMENTS*IN USE'
S6ELEMHI='HIGHEST*NUMBER OF*ELEMENTS*IN USE'
S6ELEMLN='DATA*ELEMENT*SIZE'
S6ELEMLO='LOWEST*NUMBER OF*FREE*ELEMENTS'
S6ELEMMX='MAX ELEMENTS*RETURNED*BY IXLCONN'
S6ELEMPE='MAX ELEMENTS*PER ENTRY*(FOR 32K)'
S6ELEMPW='DATA*ELEMENT*SIZE*AS POWER OF 2'
S6ELEMRT='ELEMENT SIDE*OF ENTRY*ELEMENT RATIO'
S6ENTRCT='CURRENT*NUMBER OF*ENTRIES*IN USE'
S6ENTRHI='HIGHEST*NUMBER OF*ENTRIES*IN USE'
S6ENTRLO='LOWEST*NUMBER OF*FREE*ENTRIES'
S6ENTRMX='MAX ENTRIES*RETURNED*BY IXLCONN'
S6ENTRRT='ENTRY SIDE*OF ENTRY*ELEMENT RATIO'
S6FREECT='NUMBER OF*ENTRIES*ON FREE LIST'
S6FREEHI='HIGHEST*ENTRIES*ON FREE LIST'
S6HDRS ='MAXIMUM*NUMBER OF*LIST*HEADERS'
S6HDRSCT='HEADERS*USED FOR*CONTROL*LISTS'
S6HDRSTD='HEADERS*AVAILABLE FOR*TABLE DATA'
S6INDXCT='NUMBER OF*ENTRIES*IN TABLE INDEX'
S6POOL ='POOL NAME*PART OF*STRUCTURE*NAME'
S6PREF ='FIRST PART*OF*STRUCTURE*NAME'
S6RSP8CT='AN IXLLIST*RETURN*CODE*OCCURRED*OTHER'
S6SIZE ='STRUCTURE*SIZE*'
S6SIZEMX='MAXIMUM*STRUCTURE*SIZE'
S6USEDCT='NUMBER OF*ENTRIES*ON USED LIST'
S6INDXHI='HIGHEST*ENTRIES*IN TABLE INDEX'
S6APPLCT='NUMBER OF*ENTRIES*IN APPLID LIST'
S6APPLHI='HIGHEST*ENTRIES*IN APPLID LIST'
S6UOWLCT='NUMBER OF*ENTRIES*IN UOW LIST'
S6UOWLHI='HIGHEST*ENTRIES*IN UOW LIST'
S6RDICT ='READ*TABLE*INDEX*ENTRY'
S6WRICT ='WRITE*TABLE*INDEX*ENTRY'
S6RWICT ='REWRITE*TABLE*INDEX*ENTRY'
S6DLICT ='DELETE*TABLE*INDEX*ENTRY'
S6CRLCT ='CREATE*LIST'
S6MDLCT ='MODIFY*LIST'
S6DLLCT ='DELETE*LIST'
S6RDDCT ='READ*DATA*ITEM'
S6WRDCT ='WRITE*DATA*ITEM'
S6RWDCT ='REWRITE*DATA*ITEM'
S6DLDCT ='DELETE*DATA*ITEM'
S6INLCT ='INQUIRE*ON*DATA LIST'
S6RDMCT ='READ*MESSAGE*QUEUE'
S6WRMCT ='WRITE TO*MESSAGE*QUEUE'
S6RDUCT ='READ*UOW*ENTRY'
S6WRUCT ='WRITE*UOW*ENTRY'
S6RWUCT ='REWRITE*UOW*ENTRY'
S6DLUCT ='DELETE*UOW*ENTRY'
S6RDACT ='READ*APPLID*ENTRY'
S6WRACT ='WRITE*APPLID*ENTRY'
S6RWACT ='REWRITE*APPLID*ENTRY'
S6DLACT ='DELETE*APPLID*ENTRY'
S6RRLCT ='REREAD*ENTRY FOR*FULL DATA*LENGTH'
S6ASYCT ='NUMBER OF*ASYNCHRONOUS*REQUESTS'
S6RSP1CT='NORMAL*RESPONSE*EVERYTHING*OK'
S6RSP2CT='BUFFER LEN*TOO SHORT*FULL LENGTH*REREAD'
S6RSP3CT='NO MATCHING*ENTRY*WAS FOUND'
S6RSP4CT='ENTRY VERSION*DID NOT*MATCH'
S6RSP5CT='LIST*AUTHORITY*COMPARISON*MISMATCH'
S6RSP6CT='MAXIMUM*LIST*KEY*REACHED'
S6RSP7CT='THE LIST*STRUCTURE*IS OUT OF*SPACE'
S6USEDHI='HIGHEST*ENTRIES*ON USED LIST'
Contents of CICCSF7D - CFTD Buffer Statistics
S7OCCLOS='CLOSE*TABLE'
S7OCDELE='DELETE*TABLE'
S7OCOPEN='OPEN*TABLE'
S7OCSET ='SET TABLE*ATTRIBUTES'
S7OCSTAT='EXTRACT*TABLE*STATISTICS'
S7RQHIGH='RETURN*HIGHEST*KEY'
S7RQLOAD='LOAD '
S7RQPOIN='POINT '
S7RQRDDL='READ*AND*DELETE'
S7RQREAD='READ*(INCLUDING READ*FOR UPDATE)'
S7RQREWR='REWRITE'
S7RQUNLK='UNLOCK'
S7RQWRIT='WRITE*(NEW RECORD)'
S7TABLE ='TABLE*NAME'
Contents of CICCSF8D - CFTD Request Statistics
S8IQINQU='INQUIRE*TABLE'
S8OCCLOS='CLOSE*TABLE'
S8OCDELE='DELETE*TABLE'
S8OCOPEN='OPEN*TABLE'
S8OCSET ='SET TABLE*ATTRIBUTES'
S8OCSTAT='EXTRACT*TABLE*STATISTICS'
S8RQDELE='DELETE*RECORD'
S8RQDELM='DELETE*MULTIPLE*RECORDS'
S8RQHIGH='RETURN*HIGHEST*KEY'
S8RQLOAD='LOAD*RECORD*AT INITIAL*LOAD TIME'
S8RQPOIN='POINT*TO*RECORD'
S8RQRDDL='READ*AND*DELETE*RECORD'
S8RQREAD='READ*RECORD*(INCLUDES*FOR UPDATE)'
S8RQREWR='REWRITE*EXISTING*RECORD'
S8RQUNLK='UNLOCK*RECORD'
S8RQWRIT='WRITE*NEW*RECORD'
S8SPBACK='BACK OUT*UNIT OF WORK'
S8SPCOMM='COMMIT*UNIT OF WORK'
S8SPINQU='INQUIRE*ABOUT*UNIT OF WORK'
S8SPPREP='PREPARE*TO COMMIT*UNIT OF WORK'
S8SPREST='RESTART*RECOVERABLE*CONNECTION'
S8SPRETA='RETAIN*LOCKS FOR*UNIT OF WORK'
Contents of CICCSF9D - CFTD Storage Statistics
S9ANYFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S9ANYLO ='LOWEST*FREE*PAGES*(SINCE RESET)'
S9ANYMX ='TOTAL PAGES*IN THE*STORAGE*POOL'
S9ANYNAM='POOL NAME*AXMPGANY'
S9ANYPTR='ADDRESS OF*STORAGE*POOL*AREA'
S9ANYRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S9ANYRQF='GETS WHICH*FAILED TO*OBTAIN STORAGE'
S9ANYRQG='STORAGE*GET*REQUESTS'
S9ANYRQS='STORAGE*FREE*REQUESTS'
S9ANYSIZ='SIZE OF*STORAGE*POOL*AREA'
S9ANYUS ='NUMBER OF*USED PAGES*IN THE POOL'
S9LOWFR ='NUMBER OF*FREE PAGES*IN THE POOL'
S9LOWLO ='LOWEST FREE PAGES (SINCE RESET)'
S9LOWMX ='TOTAL PAGES*IN THE*STORAGE POOL'
S9LOWNAM='POOL NAME*AXMPGLOW'
S9LOWPTR='ADDRESS OF*STORAGE*POOL*AREA'
S9LOWRQC='COMPRESS*(DEFRAGMENTATION)*ATTEMPTS'
S9LOWRQF='GETS WHICH*FAILED TO*OBTAIN STORAGE'
S9LOWRQG='STORAGE*GET*REQUESTS'
S9LOWRQS='STORAGE*FREE*REQUESTS'
S9LOWSIZ='SIZE OF*STORAGE*POOL*AREA'
S9LOWUS ='NUMBER OF*USED PAGES*IN THE POOL'
Change 16.321 If the last structure in a type 74 subtype 4 record had
VMAC74 an extension, the extension was not input, so variables
Jan 12, 1999 R774CRHC thru R744CWUC were missing TYPE74ST dataset for
that observation. My existence test for the extension:
IF R744CDSI GT 0 AND CDSILOC+200 LE LENGTH THEN DO;
INPUT @(SMF744CO+(R744CDSI-1)*SMF744CL)
should have been:
IF R744CDSI GT 0 AND CDSILOC+200 LE LENGTH-1 THEN DO;
but clearer/safer logic is to use R744CDNE to validate
the existence of the extension, so the test now is:
IF R744CDSI GT 0 AND R744CDNE GE 1 THEN DO;
INPUT @CDSILOC
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.320 This test member had hex strings that caused FTP to gag
ZTIMECHK when the MXG Source Library was FTP'd from MVS; as it was
Jan 10, 1999 only for my internal testing, the member was deleted.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.319 Using the new TYPSAIM0 member (for FACOM operating sys)
VMACAIM0 failed, as the MACRO _SAIM0 _SAIM0 % syntax failed. As
Jan 10, 1999 it was not really needed, it was deleted. This was the
only instance in which a dataset sort macro name was the
same as the member sort macro name, and the only place
that that syntax was used in a VMAC member.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.318 Support for DB2 Version 6.1 (COMPATIBLE):
EX102230 It appears that all of the changes in 6.1 were added at
EX102233 the end of segments, so MXG 15.15+ will not fail with the
EX102242 DB2 6.1 records, but none of the new information will be
EX102243 decoded by MXG until you install MXG 16.09 or later.
EX102247 -The QWHA Data Sharing Header (new in Version 5.1) is now
EX102248 decoded, creating new variables in Accounting datasets
EX102249 DB2ACCT,DB2ACCTP, DB2ACCTB and DB2ACCTG:
EX102250 QWHAMEMN='DB2*MEMBER*NAME'
EX102251 QWHADSGN='DB2*DATA SHARING*GROUP*NAME'
EX102252 -The QWHC Correlation Header was extended and contains new
EX102254 End User information added to DB2ACCT,DB2ACCTP,DB2ACCTB
EX102255 and DB2ACCTG Accounting datasets.
EX102256 QWHCEUID='END USERS*USERID*AT WORKSTATION'
EX102257 QWHCEUTX='END USERS*TRANSACTION*NAME'
EX102258 QWHCEUWN='END USERS*WORKSTATION*NAME'
EX102259 -New QWAX segment contains waits and counts, some of which
EX102260 were previously QWACxxxx fields in the DB2ACCT datasets:
EX102261 QWAXALCT='ARCHIVES*LOG MODE*(QUIESCE)'
EX102262 QWAXALOG='WAIT TIME*DUE TO PROCESSING*OF ARCH LOG'
EX102263 QWAXANAR='WAITS FOR*ARCHIVE READS'
EX102265 QWAXARNC='WAITS FOR*SUSPENSIONS*FOR CLAIMS'
EX102266 QWAXARND='WAITS FOR*A DRAIN LOCK'
EX102267 QWAXAWAR='WAIT TIME FOR ARCHIVE READS (TAPE)'
EX102268 QWAXAWCL='WAIT TIME FOR A DRAIN FOR CLAIMS'
EX102272 QWAXAWDR='WAIT TIME FOR A DRAIN LOCK'
EX102273 QWAXDSNS='WAITS FOR*DATASPACE MGR*TASKS'
EX102305 QWAXDSSE='WAIT TIME*FOR DATASPACE SERVICE'
EX102306 QWAXOCNS='WAITS FOR*OPEN/CLOSE OR*HSM RECALL'
EX102311 QWAXOCSE='WAIT TIME*FOR OPEN/CLOSE OR*HSM RECALL'
EX102312 QWAXOTNS='WAITS FOR*SWITCH TO OTHER*DB2 SERV TASKS'
EX102313 QWAXOTSE='WAIT TIME*SWITCH TO OTHER*DB2 SERV TASKS'
EX102314 QWAXSLNS='WAITS FOR*SYSLGRNG*RECORDING'
FORMATS QWAXSLSE='WAIT TIME*FOR SYSLGRNG*RECORDING'
VMACDB2 -The QWAC segment was extended with SIGNIFICANT NEW DATA!!
VMACDB2H for DB2's interaction with Workload Manager's new Enclave
Jan 9, 1999 architecture, as well as new measurements of the elapsed
Jan 12, 1999 and TCB CPU time spent in Stored Procedures and in User
Defined Functions, and with SQL time separated as well:
QWACLRAB='BYTES*LOGGED'
QWACLRN ='LOG*RECORDS*WRITTEN'
QWACPECT='TCB TIME*BEFORE*ENCLAVE*CREATION'
QWACSPEA='ET EXECUTING*STORED PROCS*INCLUDES SQL'
QWACSPEB='ET EXECUTING*STORED PROCS*SQL TIME'
QWACTREE='ET*EXECUTING*TRIGGERS*UNDER AN*ENCLAVE'
QWACTRET='ET EXECUTING*TRIGGERS*NOT UNDER ENCLAVE'
QWACTRTE='TCB TIME*EX TRIGGERS*UNDER AN*ENCLAVE'
QWACTRTT='TCB TIME*EX TRIGGERS*NOT UNDER ENCLAVE'
QWACUDCP='TCB TIME*USRDEFUN*STORED PROC*OR WLM AS'
QWACUDEA='ET USRDEFUN*TOTAL INCLUDES*SQL TIME'
QWACUDEB='ET USRDEFUN*ONLY*SQL TIME'
QWACUDNE='SQL ENTRY/EXIT*EVENTS*USER DEF FUNCTION'
QWACUDST='ET WAITNG FOR AVAIL TCB*TO SKED*USRDEFUN'
QWACUDTT='TCB TIME*USRDEFUN*SQL TIME*(IN QWACUDCP)'
QWACWLME='SERVICE*CLASS*NAME'
-The first QWDA segment is now decoded creating variable
QWDAXCQO='MEMBER NAME OF*PARALLELISM*COORDINATOR'
for child tasks. There can be multiple segments for the
coordinating task, but only the first is read now, until
test data and a need presents itself.
-For packages, the QPAC segment that created DB2ACCTP has
been enhanced with new variables:
QPACAAFG='ACTIVITY*TYPE*FLAG'
(decoded with new format $MGDB2PK with values of
01-stored proc,02-userdefun,03-trigger executing)
QPACAANM='NAME*OF*ACTIVITY'
QPACASCH='NESTED*ACTIVITY*SCHEMA*NAME'
QPACSPNS='STORED*PROCEDURES EXECUTED'
QPACUDST='ET WAITING*FOR TCB*BEFORE SKED*USRDEFUN'
QPACUDNU='USER-DEFINED*FUNCTIONS*SCHEDULED'
-The QXST segment was extended with new variables in both
the DB2ACCT and DB2STATS datasets:
QXALOCC ='ALLOCATE*CURSOR*STATEMENTS*EXECUTED'
QXALOCL ='ASSOCIATE*LOCATOR*STATEMENTS*EXECUTED'
QXALPRO ='ALTER*PROCEDURE*STATEMENTS'
QXALUDF ='ALTER*FUNCTION*STATEMENTS'
QXCASCDP='MAX LEVEL*OF NESTED*SQL CASCADING'
(includes cascading due to triggers, udfs,
and stored procedures).
QXCAUD ='USER*DEFINED*FUNCTIONS*EXECUTED'
QXCAUDAB='TIMES*USERDEFUN*ABENDED'
QXCAUDRJ='TIMES USERDEFUN*WAS REJECTED'
QXCAUDTO='TIMES*UDF*TIMED OUT*WAITING TO BE SKED'
QXCDIST ='CREATE*DISTINCT*TYPE*STATEMENTS'
QXCRATB ='CREATE*AUX TABLE*STATEMENTS'
QXCRPRO ='CREATE*PROCEDURE*STATEMENTS'
QXCRUDF ='CREATE*FUNCTION*STATEMENTS'
QXCTRIG ='CREATE*TRIGGER'
QXDDIST ='DROP *DISTINCT*TYPE*STATEMENTS'
QXDRPFN ='DROP*USER*DEFINED*FUNCTION'
QXDRPPR ='DROP*STORED*PROCEDURE'
QXDRPTR ='DROP*TRIGGER'
QXFREEL ='FREE*LOCATOR*STATEMENTS'
QXHOLDL ='HOLD*LOCATOR*STATEMENTS'
QXREPOP1='PARALLEL*GROUPS*REFORMULATED*SYSPLEX'
QXREPOP2='PARALLEL*GROUPS*REFORMULATED*BUFFERS'
QXRNTAB ='RENAME*TABLE'
QXROIIDX='DIRECT ROW*REVERTED*USED*AN INDEX'
QXROIMAT='DIRECT ROW*ACCESS*WAS SUCCESSFUL'
QXROITS ='DIRECT ROW*REVERTED*USED*TABLESPACE SCAN'
QXROWTRG='ROW TRIGGER*WAS ACTIVATED'
QXSETPTH='SET*CURRENT PATH*STATEMENTS'
QXSTDEXP='EX COPY*DISCARDED*DUE TO*MAXKEEPD LIMIT'
QXSTDINV='EX COPY*PURGED*DUE TO*DEPENDENT OBJECT'
QXSTFND ='PREPARE REQUESTS*SAT BY*COPY FROM CACHE'
QXSTIPRP='IMPLICIT PREPARE*BUT DB2*HAD NO VALID'
QXSTLOBV='MAX STORAGE*BYTES USED*FOR LOB VALUES'
QXSTNFND='PREPARE REQUEST*BUT NO*MATCH IN CACHE'
QXSTNPRP='PREPARE AVOIDED*DB2 HAD*VALID KEEPDYNAM'
QXSTTRG ='STATEMENT TRIGGER*WAS ACTIVATED'
QXTRGERR='SQL ERRORS*DURING EX*OF TRIGGERED ACTION'
-The QBGL segment added new variables to DB2STATS:
QBGL2F ='CHANGED*PAGE WRITES*FAILED*STORAGE'
QBGL2D ='DELETE*NAME*LIST*REQUESTS'
QBGL2N ='DELETE*NAME*REQUESTS'
QBGL2R ='READ*CASTOUT*STATS*REQUESTS'
QBGL2S ='COMPLETION*CHECKS*SUSPENDED'
QBGL2W ='CHANGED*PAGE WRITES*FOR DUPLEXING'
DB2 Trace Records:
-IFCID 106 added these new variables to T102S106:
QWP1BDUR='RESTART*BACKOUT*LIMIT*(0-255)'
QWP1DBPR='DATABASE*PROTOCOL*FOR 3-PART*NAMES'
QWP1DTIM='TIME*BETWEEN*RESET OF*DSET STATS'
QWP1EXBR='MAX EXTRA*DRDA QUERY BLKS*REQUESTER'
QWP1EXBS='MAX EXTRA*DRDA QUERY BLKS*SERVER'
QWP1FLBZ='MAX DSN1DBM1 STORAGE*FAST LOG APPLY'
QWP1IXPL='DEFAULT*BUFFER POOL*FOR USER INDEXES'
QWP1LMBO='LIMIT*RESTART*BACKOUT*(NO,YES,AUTO)'
QWP1LVA ='KILOBYTES*FOR LOB VALUES*PER AGENT'
QWP1LVLC='QWP1LVLC*(S)'
QWP1LVS ='MEGABYTES*FOR LOB VALUES*PER SYSTEM'
QWP1SCER='EXTENDED*SECURITY'
QWP1TBPL='DEFAULT*BUFFER POOL*FOR USER DATA'
QWP1URCK='UR*CHECKPOINT*THRESHOLD'
QWP1WLME='DEFAULT*WLM*ENVIRONMENT'
QWP4AURT='QWP4AURT*(S)'
QWP4FLBS='QWP4FLBS*(S)'
QWP4FLMT='QWP4FLMT*(S)'
QWP4MXKD='MAXIMUM*KEPT*DYNAMIC*STATEMENTS'
QWP4PAC ='PACKAGE*AUTHORIZATION*CACHE'
QWP4RHTI='QWP4RHTI*(S)'
QWP4SREC='QWPRSREC*(S)'
QWP4UBS ='QWP4UBS*(S)'
QWP4UMD ='QWPRUMD*(S)'
QWP4WBMP='IMS/BMP*TIMEOUT*FACTOR'
QWP4WDLI='IMS/DLI*TIMEOUT*FACTOR'
QWP4XCTH='QWP4XCTH*(S)'
QWP9MAX1='MAXIMUM*TYPE 1*INACTIVE*THREADS'
QWPBAGID='ASCII GBCS CCSID'
QWPBAMID='ASCII MBCS CCSID'
QWPBAR ='DECIMAL ARITHMETIC DEFAULT'
QWPBASID='ASCII SBCS CCSID'
QWPBCHAR='CHARSET DEFAULT'
QWPBCMP ='COMPATIBILITY OPTION'
QWPBDATE='DATE FORMAT (ISO,JIS,EUR,LOCAL,USA)'
QWPBDE ='PERIOD/COMMA DEFAULT'
QWPBDL ='DELIMITER DEFAULT'
QWPBDLEN='LOCAL (ONLY) DATE LENGTH DEFAULT'
QWPBDSD ='DISTRIBUTED SQL STRING DELIMITER'
QWPBENS ='DEFAULT ENCODING SCHEME'
QWPBGID ='GBCS CCSID'
QWPBGRA ='YES/NO MIXED GRAPHIC DEFAULT'
QWPBLANG='LANGUAGE DEFAULT'
QWPBLVL ='QWPBLVL*(S)'
QWPBMID ='MBCS CCSID'
QWPBREL ='VERSION*RELEASE*MOD LEVEL'
QWPBRIB ='POINTER TO RELEASE INFO BLOCK'
QWPBSDL ='SQL DELIMITER DEFAULT'
QWPBSID ='SBCS CCSID'
QWPBSQL ='LEVEL OF SQL LANGUAGE SUPPORT'
QWPBSSID='SUBSYSTEM DEFAULT'
QWPBTIME='TIME FORMAT (ISO,JIS,EUR.LOCAL,USA)'
QWPBTLEN='LOCAL (ONLY) TIME LENGTH DEFAULT'
-IFCID 0258 was added by APAR PQ17544 for 5.1 and 6.1. It
is decoded (even though I have no test data) as it may be
very useful: dataset T102S258 tracks when any of your DB2
databases are expanded in size. You can use it to track
database growth and avoid the catastrophy of exceeding
the maximum size of a DB2 table! These variables are
in the new T102S258 (DB2 DATASET EXTEND SPACE) dataset:
QW0258DB='DATABASE*ID*(DBID)'
QW0258DN='DATABASE*NAME'
QW0258DS='DATASET*NAME'
QW0258HA='HIGH*ALLOCATED*AFTER*EXTEND,BYTES'
QW0258HB='HIGH*ALLOCATED*BEFORE*EXTEND*BYTES'
QW0258MS='MAXIMUM*DATA*SET*SIZE,BYTES'
QW0258PQ='PRIMARY*QUANTITY*BYTES'
QW0258PS='PAGESET*ID*(OBID)'
QW0258SQ='CURRENT*SECONDARY*QUANTITY,BYTES'
QW0258TN='TABLE/INDEX*SPACE*NAME'
QW0258TS='TIMESTAMP*AFTER*EXTEND*COMPLETED'
QW0258VA='NUMBER OF*VOLUMES*AFTER'
QW0258VB='NUMBER OF*VOLUMES*BEFORE'
QW0258VM='MAXIMUM*VOLUMES'
QW0258XA='NUMBER OF*EXTENTS*AFTER'
QW0258XB='NUMBER OF*EXTENTS*BEFORE'
QW0258XM='MAXIMUM*EXTENTS'
The storage measures labeled "bytes" are formatted with
MGBYTES so they will print as MB, GB, etc.
The QW0258TS timestamp is a blind guess as to format, so
it may be wrong until I get test data for validation.
-Trace IFCIDs thru 314 now exist, although many IFCIDs are
skipped. MXG defines a set of macro names for all 314 of
the possible IFCIDs, thru dataset T102S314, so that IFCID
ranges can be selected in READDB2 and ANALDB2R logic, but
there are only 32 new IFCIDs (some of which were added by
DB2 5.1) that can have any observations. I have created
the DB2 header variables in the new datasets for these
new subtypes of type 102 records, but I need test SMF
data records before I can decode their innards.
Dataset Description
T102S230 DATA SHARING GLOBAL STATS'
T102S233 START/END CALL TO STORED PROC'
T102S242 BEGIN WAIT FOR SKED STORED PROC'
T102S243 END WAIT FOR SKED STORED PROC'
T102S247 INPUT HOST VARIABLE'
T102S248 INPUT HOST VARIABLE'
T102S249 INPUT HOST VARIABLE'
T102S250 CONNECT/DISCONNECT GROUP BUFPOOL'
T102S251 INTEREST CHANGES DATA SHARING'
T102S252 BEGIN XES REQUEST'
T102S254 CACHE STRUCTS FOR GROUP BUFPOOL'
T102S255 BUFFER REFRESH CROSS-INVALIDATED'
T102S256 ALTER GROUPBUFFERPOOL COMMAND'
T102S257 INTER-DB2 NOTIFY MESSAGE SENDING'
T102S258 DB2 DATASET EXTEND SPACE'
T102S259 P-LOCK STATE CONSTANTS'
T102S260 END MVS XES REQUEST'
T102S261 GROUP BUFFER POOL'
T102S262 GBPOOLT CASTOUT THRESHOLD'
T102S263 PAGESET AND PARTITION CASTOUT'
T102S265 SCA ACCESS REQUEST BEGIN'
T102S266 SCA ACCESS REQUEST END'
T102S267 START CF STRUCT REBUILD/EXPAND'
T102S268 END CF STRUCTURE REBUILD/EXPAND'
T102S272 ASSOCIATE LOCATORS STMT EXEC'
T102S273 ALLOCATE CURSOR STATEMENT EXEC'
T102S305 TABLE CHECK CONSTRAINT'
T102S306 LOG RECORDS'
T102S311 GLOBAL TEMPORARY TABLE USAGE'
T102S312 DCE SECURITY AUDIT TRAIL'
T102S313 CHECKPOINT LONG RUNNING UR-S'
T102S314 ACCESS CONTROL AUTH EXIT PARMS'
Change 16.317 Protection for NTSMF 2.2.1, which does not write a 0.0
VMACNTSM record for each interval. Change the test
Dec 28, 1998 IF VERSION LT : '2.1' THEN to IF VERSION LT : '2.1' or
VERSION EQ '2.2:1' THEN ....
If you have specified COMPRESS, then the expected header
version value of 2.2.2 is created and MXG has no error.
Thanks to Wayne Holtz, Reynolds Metal, USA.
Change 16.316 First MXG 16.08 only. CICINTRV failed in building CICDS
VMXGCICI because the member VMXGCICI from CICS TS 1.3 testing was
Dec 23, 1998 inadvertently shipped. The VMXGCICI from MXG 16.07 has
been put back in this MXG 16.08.
Change 16.315 Year 2000 dates cause this summarization example to fail.
ASUMHSM The DATEJUL() function does not support the Century Byte
Dec 23, 1998 (which is an MVS-only Packed-Decimal-implementation) and
this example used DATEJUL() in an INCODE= on a DSRDATE
value of 0100001 (01Jan2000 in 0cyyddd format). The MXG
use of DATEJUL() was replaced by the YEAR2000 member's
algorithm to protect this example. See Change 16.330.
Thanks to John McCray, Huntington Services Company, USA.
======Changes thru 16.315 were in MXG 16.08 dated Dec 23, 1998======
Change 16.314 New function enhancement to VMXGSUM. Named XMXGSUM for
XMXGSUM testing; it is not yet the default. Copy it into your
Dec 21, 1998 USERID.SOURCLIB, rename to VMXGSUM, and check it out.
Feb 16, 1999 This rewrite exploits some new features added by SAS in
Version 7 (if it finds it is running under V7), and adds
new parameters for additional descriptive statistics
under either Version 6 or Version 7 of SAS.
New Parameters and defaults:
(Percentile values only in version 7+.)
P1=, List of variables to calculate Pctile 1
P5=, List of variables to calculate Pctile 5
P10=, List of variables to calculate Pctile 10
P25=, List of variables to calculate Pctile 25
P50=, List of variables to calculate Pctile 50
P75=, List of variables to calculate Pctile 75
P90=, List of variables to calculate Pctile 90
P95=, List of variables to calculate Pctile 95
P99=, List of variables to calculate Pctile 99
STD=, List of variables for Standard Deviation
STDERR=, List of variables for Standard Error
CV=, List of variables for coeff of variation
T=, List of variables for T value
VAR=, List of variables for variance
KURTOSUS= List of variables for kurtosis
AUTONAME=NO, Use the AUTONAME feature
In prior releases of VMXGSUM, you always had to ensure
that any variable you specified in one of the operands
actually existed or the output variable would not be in
the output dataset. Thus, if you wanted the MAX and the
SUM of the variable CPUTM, you would have to specify:
%VMXGSUM(...
SUM=CPUTM,
MAX=MAXCPU,
INCODE=MAXCPU=CPUTM;,...
The INCODE created the variable MAXCPU as being the same
as CPUTM and the MAX=MAXCPU calculated the maximum value
found. With version 7, there is a new option in PROC
MEANS called 'AUTONAME.' By using this feature, you can
create 'long' variable names and avoid the need to create
the variables via INCODE processing that you want. The
variable name is constructed by adding an underscore
followed by the statistic name such as MEAN or MAX or
SUM. Using the example above, the specification would
be:
%VMXGSUM(...
SUM=CPUTM,
MAX=CPUTM,
AUTONAME=YES,...
In the output dataset you would then have the variables
CPUTM_SUM and CPUTM_MAX. The format, length, and labels
are all inherited from the initial variable so all of
these have exactly the same labels and formats.
It is NOT my intention to use this feature; I do NOT
intend to create MXG variables with long names (at least
not in the near future!). MXG-provided invocations of
VMXGSUM will NOT exploit this capability; they continue
to use the current design of creating 8-character names
in the INCODE= operand.
But adding this feature to VMXGSUM may be useful in your
own invocations of VMXGSUM.
-Both Versions.
Number of obs were counted with SUM(MISS,NMISS) but now
_FREQ_ variable is used because it's better and avoids an
exposure in V7:
If INHERIT is used, the format of output variables
MISS/NMISS will have a DATETIME format if the first
variable in the VARIABLE statement happens to be a
DATETIME variable. Quite confusing, but not wrong!
Feb 16, 1999: Enhanced code after 16.08 version.
Change 16.313 IMS 6.1 support did not correctly decode type 08 records
VMACIMS for IMS usage via APPC, CPIC driven, due to a modified
VMACIMSA record layout. The quick circumvention is to replace the
Dec 19, 1998 line ELSE IF LINTSUB='.1......'B THEN DO;
with ELSE DO;
to ensure TRANSACT is always input. CPIC records caused
"INVALID DATA FOR YYYYDDD in line xx 65-68" messages.
Thanks to Johannes M. Laveuve, dvg Hannover, GERMANY.
Change 16.312 Support for DOS/VS Power V6.3.0 COMPATIBLY added fields
TYPEDOS LSTEPGN and LSTPGN for RECID='L' (dataset DOSLIST) and
Dec 19, 1998 INCOMPATIBLY inserted DESTUID in the RECID='M' and 'V'
(dataset DOSXRC) shifting LOCLNODE/ADJCNODE/NACACCT/
NACINCR/NACDLR. This change assumes you have V6.3.0;
if you have an earlier version, you will need to find
the line with comment "DELETE IF PRE 6.3.0" and delete!
Thanks to Trevor Ede, EDS (NZ) Ltd, NEW ZEALAND.
Change 16.311 A type in a LABEL for variable ASIESF had CSTORE, but the
VMACRMFV variable contains Average ESTORE for Swapped In users.
Dec 19, 1998 The label for ASIESF is now ESTORE, and variables ASIFMCT
and ASIFMCTI contain 'CSTORE' to be consistent and clear.
Thanks to Tim VanderHoek, Fidelity Investments, USA
Thanks to Juergen Holtz, IBM RMF Development, GERMANY
Change 16.310 Support for VM/ESA 2.3 (COMPATIBLE) changes to MTRSYS and
VMACVMXA USEACT segments adds four new variables to VXMTRSYS data
Dec 19, 1998 set and two new variables to VXUSEACT dataset.
Thanks to Steve Clark, California Federal Bank, USA.
Change 16.309 New variable MKDELDAO contains the original julian value
VMACEDGS for the MKDELDAT value (which becomes the data part of
Dec 19, 1998 datetime variable MKLCTIME). For special values that MXG
changed to 2099 in MKLCTIME, you will have the exact,
original value as a numeric in MKDELDAO.
Thanks to Sam Bass, McLane Co., USA.
Change 16.308 -Revision to RMM EDGR support creates numeric SAS date and
VMACEDGR SAT time variables for CREATE/LAST CHANGED dates/times so
Dec 19, 1998 normal SAS data manipulation can be done. Previously the
fields were carried as character variables. This change
is INCOMPATIBLE if you join old and new EDGR datasets
together, but this finalizes the support as it should be.
-Variables RVRETDAT, RVRELIXD and RVRELSI are now input.
Thanks to Don Friesen, ISM-BC, CANADA.
Thanks to Bob Lembo, American Stores, USA.
Change 16.307 -DB2 GTF-format records only. Using TYPEDB2G or PDB=GTF
VMACDB2 to read GTF records created zero observations in DB2ACCT
UDB2GTF and DB2ACCTB because SUBTYPE was missing for the ID=101
Dec 19, 1998 record. The GTF record doesn't have ID/SUBTYPE and MXG
has to create, but this GTF section was not updated when
the ID=101 record was split into subtypes. Most use of
GTF-format for DB2 is trace records, so this had little
impact for most sites.
-It turns out that not all segments for a single record
occur together in the GTF file. For example, the final
segment for record 160 came after the first segment of
record 161. This requires that the GTF file be SORTed
before it is input to UDB2GTF to reconstruct full length
records that MXG can read. The SORT FIELDS=(37,4,BI,A)
will do the trick. Comments added to UDB2GTF.
Thanks to Ted Blank, IBM, USA.
Change 16.306 -SAS Version 7 only. The new INHERIT parameter causes the
VMXGSUM attributes (LABEL, LENGTH, FORMAT, etc.) of same-named
Dec 19, 1998 variables to be propagated from input to output when PROC
MEANS/SUMMARY is used. Designed for MXG, INHERIT is now
invoked when VMXGSUM is run under V7; with it, VMXGSUM
can frequently bypass the last step.
Change 16.305 The APAF variables kept depended on the __NRLPS macro,
VMACAPAF but even if it was set to 10, only 8 engine's data was
Dec 18, 1998 kept. The logic was revised and the &__NRLPS macro was
eliminated; sixteen CPU variables will always exist now,
with online CPUs populating their set of variables.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 16.304 MXG 16.04-16.07 only. Observations for RACFEVNT=19
VMAC80A (PERMIT COMMAND) were output into dataset TYPE8018
Dec 18, 1998 instead of dataset TYPE8019 due to a typo. The line
_ETY8018 after ELSE IF RACFEVNT=19 should be _ETY8019.
Thanks to Michael A. Yaffee, Duke Power, USA.
Change 16.303 Archaic members TYPEMONI and TYPETMON still had _L macro
TYPEMONI names instead of _W macro names, but since TYPEMONI is
TYPETMON for now-defunct version 7 and was replaced by TYPEMON8,
Dec 17, 1998 and since TYPETMON was replaced by TYPETMO2 for V2, this
slipped thru testing.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 16.302 The MACRO _LCIMSPGM CIMSPGM % statement should be
VMACCIMS MACRO _LCIMSPGM CIMSPROG %
Dec 17, 1998 The value was misspelled starting in 16.04.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 16.301 An extended example of AS/400 processing using FTP to
ADOCQAPM send and manage the multiplicity of OS/400 files that
JCLQAPMX must be moved to the SAS execution platform for TYPEQAPM.
Dec 16, 1998
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 16.300 Unused Change Number.
======Changes thru 16.299 were in MXG 16.07 dated Dec 5, 1998======
Change 16.299 Variable MKDELDAT contained '14MAY2051'D for YY=99 and
VMACEDGS DDD GE 365; the statement YYYYDDD='20DEC2099'D; should be
Dec 5, 1998 YYYYDDD=2099365;, which is the julian date, because later
code converts the julian date to a SAS date.
Thanks to Sam Bass, McLane Co., USA.
Change 16.298 Variable DSGTAMXT was removed from PDB.CICINTRV because
VMXGCICI it only existed in CICS 3.3; variables STAMATHD,STAMITHD,
Dec 5, 1998 and STAHIWAT were put back in PDB.CICINTRV; they had been
inadvertently dropped.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.297 MXG 16.07 Dec 4 only; end-comment */ was missing after
VMAC28 variable VRTSTATE, causing UNINITIALIZED variable and
Dec 4, 1998 incorrect data in NPMLANOD dataset.
Thanks to Freddie Arie, Lone Star Gas, USA.
======Changes thru 16.296 were in MXG 16.07 dated Dec 4, 1998======
Change 16.295 Enhancement to MXG RMF reporting replicates IBM XCF
ANALRMFR report. Specify REPORT=XCF,RPTOPT=USAGE MEMBER PATH.
Dec 4, 1998
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 16.294 Cosmetic cleanup of variable labels.
VMAC28 -VMAC110. CICRELSE='CICS*RELEASE*IN JOURNAL*SEGMENT'
VMAC110 -VMACIKLA S23TTIME='SESSION*TERMINATE*TIME'
VMACILKA -VMACMEMO ACTMTEDA='ACCMTEDA='ACC NUMBER OF*PICKED UP*EDA'
VMACMEMO ACTMTETR='ACCMTEDA='ACC NUMBER OF*PICKED UP*ETR'
Dec 3, 1998 Variable SENDNCO now kept in MEMODIST.
(If you have the MEMO product, please send me
the current documentation, as there are other
variables that I do not have good labels for).
-VMAC28 VRTNRCPN='NEW*REMOTE*CP*NAME'
VRTNRNID='NEW*REMOTE*NETWORK*ID'
VRTRTCID='REMOTE*TCID'
Thanks to Chris Weston, SAS Institute ITSV, Cary.
Change 16.293 BETA93 Version 3.1.3 INCOMPATIBLY inserted fields in all
VMACBETA subtypes, causing INPUT EXCEEDED RECORD LENGTH errors,
Dec 3, 1998 and many fields previously in the valid SMFSTAMP8 format
Dec 17, 1998 (BETALT,BETASTSE,BETAENSE,BETASTRT,BETAEND) are now in a
never-before-seen-in-SMF time format of packed hhmmss00!
If you use SMFSTAMP8 to input these non-standard times,
there is no SAS error, but incorrect datetime values
are created. Their data value for 10:12:23 on 23NOV98
is '101223000098325F'x, but when INPUT with SMFSTAMP8
the result is a wrong value of 22Dec1998:04:57:20.64
because SMFSTAMP inputs the 10:12:23:00 time value as
PIB4. and gets 2696240.64 seconds (31.2 days) which is
then added to midnight on julian date 98325, 23Nov98!
READTIME fields should be unchanged, since BETA93 copies
rather than creates them. The below table lists the data
that has been verified that it was changed to new format,
and are supported in this version of MXG. The NODATAYET
subtypes will be printed on your SAS log if found in your
data; please email me that log so I can enhance MXG to
support and validate those NODATAYET subtypes.
Subtype datetime fields MXG dataset/status
0 BETALT BETA0 VERIFIED
1 BETABT, BETALT BETA1 NODATAYET
3 BETART BETA3 NODATAYET
5 BETALT BETA5 NODATAYET
6 BETAWST BETA6 NODATAYET
20 BETALT, BETASTRT, BETAEND BETA20 VERIFIED
21 BETALT, BETASTRT, BETAEND BETA21 VERIFIED
40 BETALT BETA40 NODATAYET
41 BETALT BETA41 NODATAYET
42 BETALT BETA42 NODATAYET
Thanks to Jurgen Niegsch, AUGI AG, GERMANY.
======Changes thru 16.292 were in MXG 16.06 dated Dec 2, 1998======
Change 16.292 Support for APAF Versions 4.1 and 4.3 (INCOMPATIBLE):
EXAPAFPO -Version 4.1 adds new variables to APAFSYSD dataset:
VMACAPAF CPUDEDF ='BIT MAP*OF DEDICATED*FENCED*CPUS'
Dec 2, 1998 CPUDEDG ='BIT MAP*OF DEDICATED*G-POOL*CPUS'
Dec 18, 1998 CPUDEDMP='BIT MAP*OF DEDICATED*CPUS'
CPUFENCE='BIT MAP*OF FENCED*C-POOL*CPUS'
CPUINSTL='BIT MAP*OF INSTALLED*CPUS'
CPUSHRMP='BIT MAP*OF SHARED*CPUS'
IOCD1DAT='IOCDS-1*DATE'
IOCD1NAM='IOCDS-1*NAME'
IOCD1NUM='NUMBER OF*THE ACTIVE*IOCDS-1'
IOCD1TIM='IOCDS-1*TIME'
TOTWEIGF='TOTAL*OPER SPECIFIED*WEIGHTS'
There are two elapsed fields, one in the System section
and one in the LPAR CPU Utilization section, and they
are not exactly the same:
LPAR Duration System Duration LPAR minus System
13:24.79 13:24.71 +.08
15:02.08 15:01.96 +.12
14:59.59 14:59.08 +.51
15:00.48 15:00.79 -.31
14:59.43 14:59.79 -.38
While awaiting an explanation from Amdahl, I keep the
value from the System section as variable DURATM. Amdahl
INCOMPATIBLY inserted TIMESLIC in LPAR CPU Util section,
but it already existed in the System Data Section; if it
is possible to have different timeslice values per LPAR,
then I will change MXG, but for now I keep the TIMESLIC
from offset 82 in the System Data Section.
-Version 4.1 adds new variables to APAFLPAR dataset:
ACTLCPS ='NUMBER OF*ACTIVE*LCPS'
CIDVALUE='CID*VALUE*ZERO*OR ONE'
DEDLCPS ='NUMBER OF*DEDICATED*LCPS'
OPRLCPS ='NUMBER OF*OPERATING*LCPS'
PCPMAP ='BIT MAP*CPUS*EXECUTED ON'
SHRLCPS ='NUMBER OF*SHARED*LCPS'
-Version 4.1 adds new variable to APAFCHN dataset:
CHPSCA ='SYSTEM*CHANNEL*ADDRESS*HEX'
-Version 4.1 creates new APAFLPAC dataset from the
subtype 32x LPAR CPU Utilization Data Subsection.
-Version 4.3 adds a new Pool Data Section, but the test
data was received in time for first release, but the new
APAFPOOL dataset was added Dec 18, from subtype 49 data.
Thanks to Robert Gilbert, National Power, ENGLAND.
Change 16.291 MXG 16.06 dated Nov 30 only. Member RMFINTRV had three
RMFINTRV typos (corrected in testing, but member not updated):
Dec 2, 1998 Line 226, remove SYSPLEX. Lies 361 and 362, add SYSPLEX
to both KEEP= lists.
Change 16.290 NPMLANOD dataset variable TIC_UTIL was missing because
VMAC28 variable DURATM, the denominator of TIC_UTIL equation in
Dec 1, 1998 the AOFTYPE='CSL' logic, was not calculated. The lines
of code inside 'CSL' that created ENDTIME and STARTIME
are moved above the TIC_UTIL calculation, and a new line
of code: DURATM=ENDTIME-STARTIME; was added. Also, the
test IF LENAOF GE 204 in 'CSL' was changed to GE 192.
Variable DURATM was also not calculated in the ETH, LSV,
and SAM segments; it is now calculated there, and is also
added to macros VA28CSL/ETH/LSV/SAM so it will be kept in
the datasets created by those segments.
Variable TIC_UTIL exists in dataset NPMLANOD but has
a missing value. You can create values without having
to re-reading SMF by running this program:
DATA PDB.NPMLANOD; SET PDB.NPMLANOD;
DURATM=ENDTIME-STARTIME;
TIC_UTIL=100*
((((LCSLBYTS*LCSLBTPT)+(LCSLBYTR*LCSLBRPT))/1000000000)+
(((LCSLTFRS*LCSLFTPT)+(LCSLTFRR*LCSLFRPT))/1000000))
/DURATM;
I recommend that you cut and paste those lines of code,
rather than trying to type them!
Thanks to Anke Mineur, dvg Hannover, GERMANY.
======Changes thru 16.289 were in MXG 16.06 dated Nov 30, 1998======
Change 16.289 Final testing of 16.06 left a PUT 'JOURN= ' ... statement
VMAC110 in the (archaic) CICS non-ESA code that could print many
Nov 30, 1998 lines on SAS log, with no other impact. Deleted the line.
Thanks to Ben Coonfield, Browning-Ferris Services, Inc, USA.
Change 16.288 In 16.04+ the sort order for all RMF datasets was changed
ANALRMFI to BY SYSPLEX SYSTEM STARTIME from BY SYSTEM STARTIME,
ASUM70PR but I failed to note the change, and I failed to change
GRAFRMFI the BYs in RMFINTRV until this change. The change is
MONTHBLD required because the same SYSTEM name can be in multiple
RMFINTRV SYSPLEX members. If you have only one SYSPLEX, this
VMAC7072 change has no impact, but if you have multiple SYSPLEXs,
VMAC71 you may have to change your BYs to BY SYSPLEX SYSTEM....
VMAC73 (Otherwise, your reports may fail with NOT SORTED error).
VMAC74 The member ANALRMFI (four PROC PLOTS) was change to add
VMAC75 SYSPLEX to the BY list. In the other ????RMFI members,
VMAC76 GRAFRMFI/TRNDRMFI/etc., the reporting is SORTED by SYSTEM
VMAC77 without the SYSPLEX variable to preserve your existing
VMAC78 reporting BY SYSTEM. Unless you actually have the same
VMAC79 SYSTEM name in two SYSPLEXes, this MXG choice will keep
WEEKBLD your existing reports BY SYSTEM and hopefully avoid any
WEEKBLDT need to change your reports.
Nov 30, 1998
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 16.287 MXG 16.03-MXG 16.06. NPM datasets NPMIN25L and NPMIN25P
VMAC28 were misspelled as NPMINB5L and NPMINC5P beginning with
VMAC110 MXG 16.03, but are now spelled correctly. CICS Stats
Nov 30, 1998 datasets from Boole's MainView for CICS were misspelled
as CICBBxx instead of CICSBBxx, but are now correct.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.286 MXG 16.06 only, CICS TS 1.2 only. INPUT STATEMENT EXCEED
VMAC110 error. Variables DS6SWT and DS6SCT should not have been
Nov 30, 1998 input at all. When I cleaned up the code for the sixth
CICS TCB, I inadvertently INPUT those two variables, but
they existed only back in CICS/ESA 3.3 and do not exist
in the CICS Transaction Servers (and only the CICS TS
releases have the sixth TCB!). Deleting all references
to variables DS6SWT and DS6SCT will correct my error.
Thanks to Thomas Wieland, Phoenix Home Life Mutual Insurance, USA.
======Changes thru 16.285 were in MXG 16.06 dated Nov 21, 1998======
Change 16.285 IBM TCP/IP undocumented fields changed the record lengths
VMACTCP and caused MXG's length-based logic to classify FTPSERVER
Nov 21, 1998 events as TCPSERVER. This revision no longer uses LENGTH
nor subtype; events are now identified based on data in
the record. While there are subtypes that theoretically
could be used, and the initial support for the new STAT
expected subtype 5, using subtypes would require a table
that you would have to update, since IBM did not see fit
to fix subtypes to events, but left them for you to set!
This redesign eliminates the need for subtype tables too.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
======Changes thru 16.284 were in MXG 16.06 dated Nov 18, 1998======
Change 16.284 Support for NPM Release 2.4 (INCOMPATIBLE)!
EX028VCS The good news is that NPM can capture IP resources from
EX028VMN TCP/IP connections. The bad news is that the NPM coders
EX028VRT INSERTED the new fields in the middle of the SCD segment,
FORMATS so many existing fields are trashed without this change.
IMAC28 -SCD segment inserted LSCDIPNM and LSCDIPPN incompatibly:
VMAC28 LSCDIPNM='IP ADDRESS*IF RESOURCE*IS IP' $15
VMXGINIT LSCDIPPN='IP PORT NUMBER*IF RESOURCE*IS IP' $5
Nov 18, 1998 Previously, the ACD/NCD/RCD/SCD segments used the same
MXG code, because they were congruent, but the new data
was inserted only in the SCD segment, so the MXG code was
restructured to separate SCD processing from ACD/NCD/RCD.
-VCD segment added three new fields compatibly:
LVCDCSMN='CSM*GROUP*NAME' $8
LVCDMNPN='MNPN*NAME' $8
LVCDRTPN='RTP*NAME' $8
-VVR segment added new variable
VVRNRBLK='TIMES WHEN*VR*WAS BLOCKED'
-Format MG028VA values 20x-26x (32-38 in decimal) are
actually 14x-1Ax (20-26 in decimal); format corrected.
-Format MG028NT, NPM Resource Type decoding, adds new
values: 14X='14x:IP'
6CX='6CX:CSM BUFFER POOL'
6DX='6DX:CSM STORAGE'
6EX='6EX:APPN TOPOLOGY'
6FX='6FX:APPN DIRECTORY SERVICES'
70X='70X:RTP DATA'
71X='71X:MNPS DATA'
-New subtype 'DC'x creates NPMVSVCS dataset:
LABEL='028VCS: VTAM CSM COMMON STORAGE MANAGER'
with buffer pool/storage/data space statistics
for 4k/16k/32k/64k areas.
CSM enables host applications to share data with VTAM
and other CSM users without having to physically copy
the data, saving memory and CPU by sharring buffers.
-New subtype 'DE'x creates NPMVSVRT dataset:
LABEL='028VRT: VTAM RTP RAPID TRANSIT PROTOCOL'
with first-in/middle-in/last-in/non-seg sent/rcvd pius,
bytes sent/received over RTP, back pressure count/times
RTP is a highly efficient mechanism used by the High
Performance Routing (HPR) to enable SNA to run highspeed
multi-megabit links with low bit error rates on LANS and
WANS and is used by SNA to exploit frame relay, SMDS and
ATM and other new switched virtual network technologies.
-New subtype 'DF'x creates NPMVSVMN dataset:
LABEL='028VMN: VTAM MNPS MULTINODE PERSISTENT SESSION'
VTAM uses multinode persistent sessions MNPS to preserve
sessions across application outages when connected thru
the S/390 coupling facility. While MNPS is primarily
for recovery of hardware, VTAM, MVS, or other failures,
NPM 2.4 now collects, for each application connected
thru MNPS, the percent of CF blocks in use by all MNPS
sessions and by this application, with CF Structure name
and structure sizes/bytes/writes and recovery counts!
The "IBM Marketing" descriptions came from pages xxix-xxx
of NetView Performance Monitor Reference Version 2 Rel 4,
(SH19-6965-02), which also describes the new TCP/IP
Session Collection Capability (response time data for
TELNET sessions to a mainframe application, including
the IP network segment, available for TN3270E servers
that reside on the same host as NPM and are running
OS/390 Release 5 or higher).
The NetWare resource counters, although not new in
NPM 2.4, are described in Appendix B (and support for
those NCV, NGV, NLS, NLV, NRV, NVS, and NVV NetWare
segments and subtypes has been in MXG for some time).
Change 16.283 Comments only, but the LRECL values for AS/400 4.2 were
IMACQAPM wrong for QAPMCONF (LRECL=16 in 4.2, was 46 earlier) and
VMACQAPM AS/400 support is critical for correct LRECL. Comments
Nov 18, 1998 were revised and updated with correct LRECLS where known.
Thanks to Bob Eastlake, Hosiery Corporation of America, USA.
Change 16.282 Comments only, but the examples to create ASUM70PR from
ASUM70PR raw SMF were old and had not been updated for changes in
Nov 18, 1998 the datasets needed by RMFINTRV. These examples have
now been revised and tested.
Thanks to Bob Eastlake, Hosiery Corporation of America, USA.
Change 16.281 The IP Address variable CTCPIPAD in dataset CTCPPERF was
VMACCTCP blank; the eight lines decoding CTCIPAD from CTCPLOAD in
Nov 18, 1998 the SUBTYPE=2 DO group must be moved to within the
SUBTYPE=1 DO group.
Thanks to Patsy Hildredth, CMX, USA.
Change 16.280 Support for IXFP / ICEBERG fields added by L170017 adds
VMACICE new test/prod/both unique/shared capacity/used statistics
Nov 18, 1998 in new variables:
BEBYTSHR BEBYTUNQ NOTRMAPU PHCAPUSS PHCAPUSU TPHCPSRB
TPHCPSRP TPHCPSRT TPHCPUNB TPHCPUNP TPHCPUNT
Thanks to Bonnie Jean Walter, Summit Bank, USA.
======Changes thru 16.279 were in MXG 16.06 dated Nov 17, 1998======
Change 16.279 Errors only in the first 16.06 tape dated Nov 16:
FORMATS -Format MGMVCIT was missing equal signs in member FORMATS,
VMAC434 causing JCLINSTL to fail. Format was added after QA.
VMAC80A -VMAC80A MACRO name is _S80A rather than _STY80A.
VMACTSOM -VMAC434 variable TERMTIME rather than TERMIME.
VMACHMF -VMACTSOM _BTSOCAL/_BTSODRU STRTTIME vice SMFTIME.
Nov 17, 1998 -VMACHMF ending comment missing in _STYHMFB macro.
Change 16.278 SYNCSORT virtual storage sizes are now FORMATed MGBYTES.
VMACSYNC The variables are: SYNCAVLA SYNCAVLT SYNCREQT SYNCUSEA
Nov 16, 1998 SYNCUSET SYNDSMVL SYNVSCOR SYNVSCRT
Thanks to Chuck Hopf, MBNA, USA.
Change 16.277 The PDB.CICINTRV dataset can be very wrong; users must
CICINTRV install MXG 16.06 or later to correct the errors in the
VMAC110 MXG logic. Depending on which CICS Statistics records
VMXGCICI had observations, CICINTRV could be valid, but the logic
Nov 15, 1998 was completely redesigned. Many datasets did not pass
Jul 22, 1999 thru VMXGSUM, so their COLLTIME was never reset to the
start-of-interval-value, and if there were multiple obs
to be summed, their unique COLLTIME values created many
repeated instances in the MERGE which were then falsely
summed. The revised logic sends all 45 CICS Statistics
datasets thru VMXGSUM, and all have INTERVAL=&INTERVAL
and DATETIME=COLLTIME specified so that shorter intervals
are correctly summarized. KEEPIN= and ID= were also set
so that LABELs and FORMATs are propagated, which produces
notes: "Variable xx exists on file WORK.MXGSUM3".
Now that PDB.CICINTRV is valid, you can use it to measure
the maximum CPU time required for any of CICS's six TCBs,
to confirm that that single CICS TCB will fit in single
engine, for capacity planning and for backup site sizing.
MXG creates the interval duration from DSGTDT+DSGTWT and
the individual DSxPERCT is the percent of DURATM when
DSx's TCB was busy; new variable PCTCICBY is the percent
of DURATM when all TCBs in this region were busy.
Note that if you want to see the raw interval data and
set MACRO _CICINTV % (i.e., "none"), and you thought
you were writing 5 minute interval CICS statistics data,
you will find some intervals only seconds apart, because
if there are SMFSTREQ='REQ' or 'USS' event records in
between the 'INT' and 'EOD' records, the CPU times and
counts have to be de-accumulated, and you end up with
erratic, but completely accurate, intervals.
In VMAC110, the _BCICxxx BY lists now agree with those
that are used in CICINTRV, so you can insert in EXPDBOUT
MACRO _SCICEXC %
_S110
to sort and save all CICS Stat datasets into the PDB
library (and CICINTRV detects and uses sorted data).
The redefinition of MACRO _SCICEXC to a null was added
in Jul 99; it is needed because in BUILDPDB, that sort
was already invoked, and the work copy of CICSEXCE has
already been deleted. By nulling the one _Sdddddd
macro, the _S110 can be executed without error.
However, the raw CICxxxxx Statistics Datasets frequently
contain accumulations rather than interval values; this
is especially true of the CICDS (Dispatcher) dataset,
which contains the CPU TCB times (DSGACT, DS2ACT...).
Those numbers in CICDS can be very deceptive, and thus
you should use this new PDB.CICINTRV to be safe. If you
already have existing CICDS data, you can PROC SORT it
PROC SORT DATA=PDB.CICDS OUT=SRTDS;
BY SYSTEM APPLID SMFPSSPN CICSSTCK COLLTIME ;
PROC PRINT; VAR APPLID COLLTIME DSGACT ... SMFSTRQT;
DATA DIFDS; SET SRTDS;
DSGACT=DIF(DSGACT);
DS2ACT=DIF(DS2ACT);
...
DS6ACT=DIF(DS6ACT);
PROC PRINT; VAR APPLID COLLTIME DSGACT ... SMFSTRQT;
and disregard the negative numbers, to get a quick view.
If there is a need, I may expand CICINTRV to optionally
create de-accumulated CICxxxxx Stat datasets, but for
now PDB.CICINTRV in MXG 16.06 is the dataset to use!
Thanks to Mike Marek, First Card - FCC National Bank, USA.
Thanks to Tom Elbert, Fortis, USA.
Change 16.276 Testing of the new TYPSxxxx members uncovered typos:
VMXGINIT -VMXGINIT: PTY848, PTY849, PTY8026 added to GLOBAL.
VMAC79 -VMAC79: SYSTEM added to KEEP= list 79DF/79E/79EF.
VMAC80 -TYPS80: _S80 macro invocation added.
VMAC85 -VMAC85: "%" in column 72 caused SAS ERROR 180 error,
VMAC88 which technically is a SAS compiler bug, but it
VMAC94 is easier just to split the long line into two
Nov 14, 1998 and not use column 72 for ending percent signs!
-VMAC88: _BTY8811 variable is SMF88ANM, not SMF88LSN.
-VMAC94: _STY94 macro, added BY _BTY94 ; after PROC SORT.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 16.275 The INPUT of MVDSNL $VARYING44. MVDSN1L should have been
VMACEDGS MVDSNL $VARYING44. MVDSNLL so that the DSN
Nov 14, 1998 length input was the length of last DSN.
Thanks to Richard Fortenberry, Mitsubishi Motor Sales of America, USA
Change 16.274 -The _S110 macro no longer sorts CICSTRAN (high volume)
VMAC110 nor CICSACCT nor CICSYSTM (both pre-CICS/ESA only). The
Nov 14, 1998 _S110 macro should be invoked in your EXPDBOUT member if
you want all of the CICS Statistics and CICS Journal data
sets sorted into your PDB library with BUILDPDB. If you
use member TYPS110 to directly read type 110 SMF records,
it invokes _S110 to sort from work to PDB library.
Change 16.273 The default for &DFSMS was changed from 0 to 1, i.e.,
ASMIMSL6 DF/SMS is installed. Using the MXG default of zero
Nov 13, 1998 caused an 878 out of memory error, because the table
that had been moved above 16MB by Change 14.149 was put
below the line by the zero value. The correct default,
that DF/SMS is installed (not necessarily active), will
put the table above the line and eliminate the ABEND.
Thanks to Harry Olschewski, DeTeCSM/SLM - Kiel, GERMANY.
Change 16.272 The PROC SORT of TYPE25 in the _STY25 macro had SMFTIME
VMAC25 after _BTY25, but _BTY25 already contained SMFTIME. For
Nov 13, 1998 reasons still not understood, that redundant SMFTIME at
the end caused the data set to be not sorted in BUILDPD3
so it was removed.
Thanks to Jean Quinkert, Inland Steel, USA.
Change 16.271 MXG 16.04-16.05 only. PDB.ASUM70PR summarized by SHIFT
ASUM70PR rather by expected HOUR default. Change 16.146 added new
VMXGDUR line &DATETIME=DATETIME; in VMXGSUM after %VMXGDUR call,
VMXGSUM but the VMXGSUM invocation in member ASUM70PR has both
Nov 15, 1998 NEWSHIFT='Y' and MYTIME=_DURSET specified, which caused
the DATETIME variable used in VMXGDUR to inadvertently be
the start of shift. The correction is in member VMXGDUR,
so that it uses the correct DATETIME value in all cases.
Member ASUM70PR was the only place in MXG where VMXGSUM
used both the NEWSHIFT='Y' and MYTIME=xxxxx options.
Only member VMXGDUR was changed by this change.
Thanks to Lee Teague, Lockheed Martin, USA.
Thanks to Sandra M. Rodriguez, Liberty Mutual, USA.
Change 16.270 Support for CICS TS 1.2 Journal Format 110s (INCOMPAT).
EXCICJRN The type 110 subtype 0 Journal Format record was entirely
VMAC110 restructured in CICS TS 1.2 (a/k/a 5.2). The record now
Nov 12, 1998 contains an LGMS header, an LGMS CICS Product Segment,
a 56-byte LGGF (GLRH Record Header), and a 20-byte LGGF
SOR record at the start of each subtype 0 record. Then
one or more LGGF (GLRH Record Header again), an LGGF
CL_USER-HEADER (which is where the JCRUTRID Journal ID
value is finally found) and then bytes of user data.
This new code has been tested with user journal data, but
not yet with either SAP nor Shared Medical journals from
CICS TS 1.2. IBM provides a COMPAT41 facility for
journal records written to the logger, but IBM says there
is no compatibility service for user journalling records
written to SMF.
Thanks to Thomas Weiland, Phoenix Home Life Mutual Insurance, USA.
Thanks to Mark Hawks, Phoenix Home Life Mutual Insurance, USA.
Change 16.269 New variables DCMEPCT and RCIPCT added to TYPE42DS:
VMAC42 DCMEPCT 'DCME*INHIBIT*PERCENTAGE'
Nov 12, 1998 RCIPCT 'RECORD*LEVEL*CACHE*INHIBIT*PERCENTAGE'
Thanks to Michael Marek, First Card, USA.
Change 16.268 Some variables were not input from SMF type 90 subtypes:
VMAC90 Subtype 5/9/13/15 new variable SMF90SBU (SMF Flags) is
Nov 12, 1998 created, and variable ACTIVEMN is increased to $44 to
contain the full (long) name of the SMF dataset. Subtype
6, OLDDSNSM and NEWDSNSM are increased to $44.
Thanks to Jan van Kemenade, Candle, THE NETHERLANDS.
Change 16.267 MXG 16.04-16.05 only. MACRO _LRAC507 needed two decimal
TYPSRACF points: MACRO _LRAC507 &PRAC507..RACF507 % in VMACRACF,
VMACRACF and the PROC FREQ was removed from member TYPSRACF.
Nov 11, 1998
Thanks to Tom Downey, IBM Global Services, CANADA.
Change 16.266 Change 16.253 for CICINTRV used the new VMXGWORL to find
VMXGWORL the location (_W or _L) of the CICS Stat dataset that are
Nov 12, 1998 read by CICINTRV, but if found in the _L location it was
assumed that the PROC SORT could be bypassed. However,
if you used PROC COPY IN=WORK OUT=PDB; SELECT 7IC:; in
the EXPDBOUT member, CICINTRV failed as the data was not
sorted. Now, the logic in VMXGWORL tests the SORTED flag
in the found data and only if it is true is the PROC SORT
bypassed by MXG now. Why did I not let the PROC SORT
detect that the data was sorted so it would bypass the
actual sorting? Because invoking the PROC SORT would
still result in an unnecessary copy from input to output
that is avoided by MXG not evening calling the PROC SORT.
Instead of the PROC COPY syntax in your EXPDBOUT, you
should instead add the single line containing _S110
which will sort all of the CICS Statistics datasets into
the work file, (and CICINTRV will skip their sorts!).
Thanks to Jean Quinkert, Inland Steel, USA.
Change 16.265 The type 88 subtype 11 was badly misdocumented, but it is
VMAC88 now corrected by APAR OW36033, which also describes three
Nov 11, 1998 new fields, SMF88ATW, SMF88ALS, and SMF88AFG that are now
input and kept in dataset TYPE8811.
Change 16.264 Support for PSF/MVS Release 3.1.0 (APAR 35685) compatibly
VMAC6 adds a new count of the accumulated number of logical
Nov 11, 1998 pages per side, SMF6LPGE, and the size of paper (length
and width in millimeters, BINxBNLE and BINxBNWI).
Change 16.263 Change 16.214 formatted new HSM Functions in DF/SMS 1.4,
VMACHSM but failed to output the new subtypes 17-20.
Nov 11, 1998 FSRTYPE Description
17 Expire primary or migrated data set
18 Partrel function
19 Expire incremental backup version
20 Expire incremental backup version
Now, test data shows they are the same structure as the
existing subtypes 1-14, so changing the test to read:
IF (1 LE FSRTYPE LE 14) OR (17 LE FSRTYPE LE 20) THEN DO;
will output them into dataset HSMFSRTP.
Thanks to Solomon Baker, The Prudential Service Company, USA.
Change 16.262 Candle's Omegamon for VTAM SMF record NTRI segment was
VMACOMVT incorrectly documented, causing INPUT STATEMENT EXCEEDED
Nov 10, 1998 error. The eight-byte reserved field after ON14OP is in
fact only four bytes. Change the +8 to +4.
Thanks to Eric Barnes, Prudential, ENGLAND.
Change 16.261 The LABEL='NTNSHS: should have been LABEL='NTNSHU:
VMACNTSM following the _WNTNSHU reference (lines 1815-1816).
Nov 10, 1998
Thanks to Carl Kyonka, Consumers Gas Company Ltd., CANADA
Change 16.260 Support for Boole & Babbage MainView for CICS CMRDETL
EXMVCICF VSAM file creates two new datasets from CMR52:
EXMVCICS Dataset dddddd Description
FORMATS CMRDETL MVCICF MAINVIEW CICS CMRDETL file detl
IMACMVCI CMRFILE MVCICS MAINVIEW CICS CMRDETL TRANSACTS
TYPEMVCI There is one observation in CMRDETL for each transaction
VMACMVCI and one observation in CMRFILE for each file that was
VMXGINIT accessed by each transaction. The CMRDETL is similar to
Nov 7, 1998 type 110's CICSTRAN and the CMRFILE is similar to CICFCR.
Nov 13, 1998 The raw CMRDETL file is compressed, but the compression
Nov 16, 1998 algorithm Boole used for CMRDETL is not the same as the
compression algorithm that Boole now uses for its other
MainView products (i.e., the new ASMMNVW does NOT work
with CMRDETL file), but Boole intends to provide me with
a separate ASMxxxxx member to handle CMRDETL compression.
You can use Boole's PGM=CMRCMPW to decompress the data
until the new Infile Exit for CMRDETL exists.
Boole also corrected documentation errors; CICS 5.2 date
format is now MMDDYYYY and T6EUSTGX replaces T6EUSTGO.
New format $MGMVCIT decodes File type.
Thanks to Peter Hartmut, R & V Allgemeine Versicherung AG, GERMANY.
======Changes thru 16.259 were in MXG 16.05 dated Nov 1, 1998======
Change 16.259 ML-18 of ASMTAPES to protect against the circular queue
ASMTAPES situation associated with the DSAB flag. The original
Nov 1, 1998 logic looked for the end-of-queue marker, but now the
code uses the count of entries to find the end-of-queue,
as we found one instance in which there was no end-mark
and MXGTMNT went into a loop and had to be cancelled.
Change 16.258 RMFR Reports, variables SYSPLEX and STARTIME NOT FOUND if
ANALRMFR parameter overrides are PDB=SMF and REPORT=ALL. Fields
Nov 1, 1998 R744FMOD/FVER/VLVL added to Coupling Facility Usage, and
the LPAR MGMT column in the Partition Data report was
corrected (it was sometimes negative).
Change 16.257 The new IMS 6.1 Support in ASMIMSLG6 was tested with data
TYPEIMSA from European Summer time, which had GMTOFFTM of zero,
VMACIMSA but with non-zero GMT offset, VMACIMSA converted GMT to
Nov 1, 1998 local only for the ENDTIME variable in the 07/08 records
(because they contain the GMTOFFTM), but the IMSMERGE
records created as output from ASMIMSL6 do not contain
the GMT offset (because it did not exist prior to 6.1!).
The mixed time zones caused invalid (large negative in
the western hemisphere, large positive east of GMT) for
SERVICTM (service time) and RESPNSTM. This fix removed
the conversion of ENDTIME/STRTTIME in VMACIMSA, instead
keeping variable GMTOFFTM from the 07/08 record, and
then in the final MERGE, the GMT offset is added to all
timestamps in that one place. PLEASE VERIFY THIS LOGIC!
Thanks to David Martin, USS-Posco Industries, USA.
Change 16.256 DB2 Version 5.1 variables QISEDSI, QISEDSG, & QISEDSC
VMACDB2 were not input, but now they are.
Nov 1, 1998
Thanks to Craig Collins, State of Wisconsin, USA.
Change 16.255 Support for new DF/SMS OAM type 85 SMF record with 31
EXTY85AC subtypes create eleven datasets tracking Optical Access
EXTY85CV Method activity, volumes, space, durations, objects,
EXTY85LS bytes, deletes, etc., etc:
EXTY85RD Subtypes MXG Dataset Description Test Data?
EXTY85RQ 1- 7 TYPE85AC OAM OSREQ ACTIVITY Y
EXTY85SO 32-35 TYPE85ST OAM OSMC STORAGE MANAGEMENT Y
EXTY85ST 36 TYPE85SO OAM OSREQ SINGLE OBJECT N
EXTY85TD 37 TYPE85LS OAM OAMC LIBRARY SPACE Y
EXTY85TP 64-67 TYPE85VL OAM VARY LIBRARY/DRIVE N
EXTY85TV 68-73 TYPE85CV OAM LCS CARTRIDGE/VOLUME Y
FORMATS 74-77 TYPE85RQ OAM LCS READ/WRITE/REQUESTS Y
IMAC85 74-77 TYPE85RD OAM LCS READ/WRITE DETAILS Y
TYPE85 78,79,88 TYPE85TP OAM LCS TAPE READ/WRITE Y
VMAC85 78,79,88 TYPE85TD OAM LCS TAPE READ/WRITE DETAILS Y
VMXGINIT 87 TYPE85TV OAM TAPE VOLUME DEMOUNT N
Oct 31, 1998 While the record contains "kilobytes", MXG converts all
those storage size variables into bytes and formats them
with MGBYTES format which prints as KB/MB/GB etc.
I assumed 1024 bytes per kilobyte, but need to confirm.
The start and end timestamps are on the GMT clock but
there is no GMT offset in the records, but I used the
delta between SMFTIME and the R85PENDT to create the
GMT85OFF (but it probably won't contain leap seconds).
There are 24 undocumented bytes in the product section
that look suspiciously like job/step/procstep names, but
they are not decoded until they are documented by IBM.
There is an incredible wealth of information provided by
IBM for accounting, performance and capacity planning,
and the SMF manual has a brief discussion of OAM data.
Thanks to Gary Matney, American Century, USA.
Change 16.254 Support for DFSORT Release 14 SMF type 16 record (COMPAT)
VMAC16 required no change in MXG, since the record format was
Oct 31, 1998 not changed, and MXG already supported APARs that had
added bits to some flag fields.
Change 16.253 CICINTRV now figures out whether your CICS Statistic data
CICINTRV is sitting in the Work file ("_Wdddddd") or whether you
TYPS110 had used the _Sdddddd macro to PROC SORT it into the PDB
VMXGCICI ("_Ldddddd destination). This applies only to the type
VMXGWORL 110 subtype 2 SMF records. Normally, BUILDPDB/3 will
Nov 1, 1998 build AND sort all datasets for a product from WORK into
the PDB, but CICS type 110 subtype 2 records are only
created in the WORK file and are not SORTed to PDB,
(because the CICS Statistics datasets can be large and
are not useful unless your are going to use them!).
The old way to add CICS Stat data into your PDB with the
BUILDPDB added a PROC COPY IN=WORK OUT=PDB; SELECT CIC:;
in tailoring member EXPDBOUT to copy all, or individual
PROC SORTs were added in EXPDBOUT. But now with the new
MACKEEP design, you only need to add the _SCICddd macro
for each dataset you want, and you don't even have to use
a %LET PCICDS=PDB; because the default value for PCICDS
is already PDB!
Well, adding the _SCICDS macro in EXPDBOUT does create
dataset PDB.CICDS, but CICINTRV failed with DATASET
NOT FOUND, because it hardcoded the input CICS stat data
to be in the _Wdddddd, but the PROC SORT is from _W to
the _L, and housekeeping deletes the _Wdddddd dataset!
This solution is a redesign of CICINTRV to invoke new
member VMXGCICI (because CICINTRV is a "%INCLUDEd member"
but we needed the power of a "%MACRO), and creation of
a new utility %MACRO VMXGWORL to determine for a given
dddddd value whether the data is in the _W or in the _L
(and if it is in the _L, the new CICINTRV logic will
bypass the PROC SORT since it's already sorted.)
In the interim, you can override the _Wdddddd definition
and send the un-sorted dataset to the PDB library, and
then CICINTRV will use that dataset. Philosophically,
I don't want you to have to manipulate the _W or _L
macro names, just because they are messy to use, but they
will always be there, so this fix will work - it's just
not as pretty as simply adding the _Sdddddd macro(s) in
EXPDBOUT! For example, you would add
MACRO _WCICDS PDB.CICDS %
in either member IMACKEEP or with %LET MACKEEP= logic.
Additionally, member TYPS110 now invokes _S110 to sort
all of the CICS Stat datasets, as it should have.
See final revision in Change 16.266.
Thanks to Jean Quinkert, Inland Steel, USA.
Change 16.252 Six lines with pairs of 'DD'x (ASCII) or 'BD'x (EBCDIC)
ANALBATW characters should have been pairs of exclamation points
Oct 30, 1998 (for concatenation). I use exclamation points instead of
long vertical bars because exclamation points translate
between ASCII and EBCDIC in all languages and long bars
did not translate from UK to USA (hence this change).
Thanks to David Nuechterlein, Nissan Motor Corporation, USA.
Change 16.251 TMS support was still not correct for multi-dataset tape
TYPETMS5 volumes; some variables from TMSRECS dataset were blank
Oct 30, 1998 in the output DSNBRECD dataset, because it turns out that
the RETAIN statement doesn't work like I thought it did!
See SAS Technical Note 1., Newsletter 35 about RETAIN.
The SET statement to combine TMSRECS and DSNBRECS was
changed back to MERGE, the IF FIRST.VOLSER THEN was
changed to IF FIRST.VOLSER and INTMS THEN DO;, and the
subsequent adjacent END; and IF INTMS THEN DO; statements
were deleted (so that now the logic is FIRST.VOLSER to do
all the INTMS processing followed by IF INDSNB to do the
DSNBREC processing, and then the if LAST.VOLSER to output
the volume record into TMS.TMS).
Thanks to Chuck Hopf, MNBA, USA.
Change 16.250 -MXG 16.04 only. Zero observations in dataset SYNCSORT if
ASUMPRTR you used IMACSYNC from 16.04. Syncsort's ID macro name is
IMACRMDS _SYNCID, but the example in IMACSYNC had _IDSYNC. MXG's
IMACRTE convention now is for the name to be _IDxxxx, but three
IMACSYNC early names were spelled _xxxxID ( _SYNCID in IMACSYNC,
Oct 27, 1998 _RMDSID in IMACRMDS, and _RTEID in IMACRTE ) and all are
now correctly spelled in their IMAC comments. These IMAC
members: CADM, CIMS, DIOS, HO15, OLDV, SAM, SFS, TAND had
incorrect comments that have been revised
-Member ASUMPRTR deletes datasets with PROC DATASETS, but
it was missing the NOLIST option, so it printed lines of
unneeded/unwanted messages on your SAS log. Now it don't.
Thanks to Glenn Harper, Memorial HealthCare System, USA.
Change 16.249 Support for Interlink TCPaccess Version 5.2(INCOMPAT).
EXILKA23 -New subtypes and new headers for new subtypes will cause
EXILKAAP the old MXG code to fail.
EXILKAIU -New variables were added to the ILKAST20 dataset, and it
EXILKAOE now contains both subtype 20 and subtype 22 events; the
EXILKAPR variable SMFACTYP identifies which subtype created the
EXILKASP observation (20 is end of ftp, 22 is end-of-volume ftp).
EXILKAVS -New ILKAST23 dataset tracks TELNET sessions from st 23.
FORMATS -Subtypes 110 thru 124 create new ILKASTPR protocols
VMACILKA dataset. Note: Nov 4: The IF 150 LE ... statement was
VMXGINIT wrong; it should have been ELSE IF 150 LE ... and the
Oct 27, 1998 IN (110-112,118,123-124) should have been written as
Nov 4, 1998 IN (110,111,112,118,123,124) to process 111 records.
-Subtypes 150,151,152 create new ILKASTAP, ILKASTIU, and
ILKASTOE for API, IUCV, or Open Edition Close events.
-Subtype 80 creates ILKASTVS with global virtual storage
and creates ILKASTSP with individual subpool virtual
storage; only subpools with non-zero allocation/usage are
output in ILKASTSP.
-Subtype 100 is not yet decoded, no test record yet.
-However the new subtypes 80 and 150-152 have severe data
errors. The UOF and DOF offsets are off by one byte due
to SMFACACB being only 7 instead of 8 bytes. (MXG can
protect that offset). In the subtype 152, the counters
appear to be off by one byte (open problem with vendor).
In the subtype 80, the subpool sections are not all 40
bytes long - some are 39 (open problem with vendor).
Thanks to Will Evans, CNF Transportation, USA.
Change 16.248 The two ELSE IF PCTRDYWT=.; statements should have been
VMAC7072 written ELSE PCTRDYWT=.; but very fortunately, this
Oct 23, 1998 typo-that-became-a-logic-error has never been executed.
Only when there are OS/390 systems with 15 or more CPUs
would this typo have become an execution error, and then
the results (if not the cause) would have been obvious:
zero obs would have been created in dataset TYPE70!
Thanks to Harry Olschewski, DeTeCSM/SLM, GERMANY
Change 16.247 Support for MainView Compressed history files. Beginning
ASMMNVW with MainView for MVS 2.5, and soon with other MainView
TYPEBBMQ products, Boole history files are compressed (although
TYPECMFV specifying HISTCOMP=N as a parm on the EXEC card in the
VMACBBMQ MMR PAS JCL will turn compression off). Boole's SAMPLIB
VMACCMFV member MMRHUNC contains a standalone decompression job,
Oct 23, 1998 but this change creates a new SAS INFILE exit "MNVW" that
decompresses the compressed data during INPUT on the fly!
You assemble the ASMMNVW member to create the load module
named MNVWIFUE and store that member in a load library
that you concatenate to the //STEPLIB for the SAS step
that will read the compressed data.
You then copy the INFILE-macro definition from the VMAC
into the IMACxxxx member for the specific product:
IMACxxxx INFILE-macro INFILE Product
IMACCMFV _CMFV CMFVSAM CMF/MMR
IMACBBMQ _BBMQ BBMQVSAM MQ Series
and add the string "MNVW" (which is the exit name) after
the INFILE name:
MACRO _CMFV
INFILE CMFVSAM MNVW STOPOVER .... ;
%
MACRO _BBMQ
INFILE BBMQVSAM MNVW STOPOVER .... :
%
These INFILE statements are now externalized by new MXG
macros _CMFV and _BBMQ that are defined in their VMACxxxx
member, so you can enable the MNVW INFILE exit either by
copying the _CMFV or _BBMQ macro definition into the
IMACxxxx for that product, or you can use the MACKEEP
architecture to change the definitions in your SYSIN.
As long as you have the load module in the //STEPLIB
concatenation, you can enable the INFILE exit now as it
will read any mixture of compressed or uncompressed data.
The Assembly code in ASMMNVW was written by Ray Revis.
Thanks to Ray Revis, Boole and Babbage, USA.
Change 16.246 Tandem variable RESPTM in dataset TANDLINE was too large
VMACTAND by a million; it should be INPUT as @119 RESPTM &PIB.8.6
Oct 22, 1998 instead of just &PIB.8.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 16.245 Support for the RACF "installation-defined data field" in
VMAC80A SMF80DTP='07'x data segment is now INPUT as new variable
Oct 20, 1998 RACF07DT with maximum length of 32 bytes.
-replace
WHEN (7) DO;
INPUT +RACFDLN @;
END;
with
WHEN (7) DO;
IF 0 LT RACFDLN LE 32 THEN
INPUT RACF07DT $VARYING32. RACFDLN @;
ELSE IF RACFDLN GT 32 THEN DO;
INPUT RACF07DT $EBCDIC32. @;
SKIP=RACFDLN-32;
INPUT +SKIP @;
END;
END;
-add variable name RACF07DT to the KEEP= list for datasets
TYPE8008,TYPE8009,TYPE8010,TYPE8011,TYPE8012,TYPE8013,
TYPE8020 and TYPE8021, as this field can exist in all of
those RACF events.
Thanks to Albert Venetitay, CTICEP, FRANCE.
Change 16.244 Notes amplifying what is captured in which TCP records
ADOCTCP from an IBM Support person were added to documentation.
Oct 20, 1998 The TYPETCPA "APICALLS" event appears to capture all
bytes of all TCP/IP traffic, and even includes FTP counts
so it appears using TYPETCPA for accounting bytes in/out
may be feasible.
Thanks to Xiaobo Zhang, ISO, USA.
Change 16.243 Variable ENDTIME should have been kept in all datasets in
VMACCMFV VMACCMFV, but it was missing from the KEEP= list for some
Oct 20, 1998 datasets.
Thanks to Neil Ervin, Huntington Services, USA.
======Changes thru 16.242 were in MXG 16.04 dated Oct 19, 1998======
Change 16.242 MXG expected the new TCP Statistics record to be created
IMACTCP as SUBTYPE=5, but TCP lets the TCP installer set whatever
VMACTCP value they want for each subtype. MXG has always been
Oct 19, 1998 able to look inside the TCP record to determine what it
was without using the subtype, but the Statistics record
support does depend on the SUBTYPE value. This change
defines the new MACRO _SUBTCP5 5 % with its default of
5 than can be changed with MACKEEP/IMACKEEP/IMACTCP if
your subtype is not five.
Thanks to Ben Coonfield, Browning-Ferris Services, Ind., USA.
Change 16.241 MXG 16.04 only. Dataset VXMTRDEV was not created, so the
VMACVMXA PROC MEANS caused ERROR: THERE ARE NO ANALYSIS VARIABLES.
Oct 19, 1998 The correction was inside MACRO _SIODDEV definition; the
SORT was changed to OUT=_LMTRDEV instead of ZZMTRDEV, and
the SET ZZMTRDEV was changed to SET _LMTRDEV;
Thanks to Steve Clark, California Federal Bank, USA.
Change 16.240 Counter variables MROTRAN/DB2TRAN were set to zero, but
ASUMUOW this should be done only if the observation did not come
Oct 19, 1998 from the SPIN library, so IF NOT INSPIN THEN DO; ... END;
was added around the two statements. After IF LAST.
logic, new variables WTRLIOCN/WTRLIOTM were not reset,
but now are equated to HTRLIOCN/HTRLIOTM.
Thanks to Harry Olschewski, DeTeCSM/SLM, GERMANY.
Change 16.239 Variables SMF30AIC/SMF30AID/SMF30AIW were multiplied two
VMAC30 times by 128, and variables SMF30EIC/SMF30EID/SMF30EIW
Oct 19, 1998 were not multiplied at all; the last three lines should
have been for EIC/EID/EIW instead of repeat AIC/AID/AIW.
These new address space level connect/disconnect/pend
durations were added in OS/390 Release 2.4.
Thanks to Martin Peck, iT-AUSTRIA, AUSTRIA.
Change 16.238 MXG 16.04 only. The dataset names for SMF type 115 MQ
IMAC115 Series are now as they were before 16.04. The correct
VMAC115 names of MQMLOG, MQMMSGDM, and MQMBUFER are created,
Oct 19, 1998 instead of TYPE1151, TYPE1152, and TYPE115B.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 16.237 The first occurrence of &OPTNAME=S2 should have been
VMXGOPTR &OPTNAME=S. This had no effect in any delivered code,
Oct 19, 1998 but if you had used %VMXGOPTR to reset the S= option, it
did not work.
Thanks to Tom Parker, CSC/Hogan Systems, USA.
Change 16.236 New RACFEVNT=26:APPCLU SESSION ESTABLISH now creates new
EXTY8026 dataset TYPE8026. This event is new in RACF 2.2. This
VMAC80A new record causes MXG 14.14 to fail, but MXG 15.15 and
Oct 19, 1998 later did not fail with either TYPE80A or TYPE80.
Thanks to Roger Lowe, CITIBANK Asia Pacific Center, SINGAPORE.
Change 16.235 Invalid CICS type 110 Journal Format Subtype 0 records
VMAC110 with JCRLL value of zero caused MXG to loop on the same
Oct 19, 1998 record. MXG now protects for this invalid record, prints
an error message and deletes the bad records.
Thanks to Tom Wieland, Phoenix Home Life Mutual Insurance Co., USA.
Change 16.234 JES3 with more than 9999 job numbers caused log message
VMAC57 INVALID DATA FOR JESNR because the old 4-byte location is
Oct 19, 1998 now hex zeros. Adding the ?? modifier between JESNR and
&NUM.4. eliminates the message. There actually was no
error in the TYPE57 dataset, since the real JESNR is read
from a 5-digit field later in the record, but this will
eliminate an unnecessary and confusing message.
Thanks to Bendt Wiberg, CSC Computer Management A/S, DENMARK.
Change 16.233 MXG 16.04 only. Two Sort Macros, _SDB2STB and _SDB2STR,
VMACDB2 referenced &PDB2STB..DB2STATB and &PDB2STR..DB2STATR
Oct 19, 1998 instead of _LDB2STB and _LDB2STR, causing ANALDB2R to
fail when PDB=SMF was specified, if there was no PDB DD.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.232 The PROC SORT of dataset INTWKLD needed variable DURATM
NTINTRV to be added at the end of the BY statement.
Oct 14, 1998
Thanks to Howard Glastetter, Weyerhaeuser Company, USA.
======Changes thru 16.231 were in MXG 16.04 dated Oct 9, 1998======
Change 16.231 Variables STDUPLEX, FCB, OVLYLOAD, and OVLYUSED are added
BUILD005 to MACRO _PDB30_6 so that they will exist in PDB.PRINT
BUIL3005 dataset (and hence will be in ITSV's XPRINT table). These
Oct 8, 1998 variables were needed because they had been kept in MICS.
Thanks to Theo Peelen, SHELL, THE NETHERLANDS.
Change 16.230 If there are duplicate type 30 subtype 5 records, and you
VMAC30 have job records with MULTIDD='Y' (there were so many DDs
BUILD005 that SMF had to write multiple physical type 30 records),
BUIL3005 the PROC SORT of TYPE30_5 was not robust enough to delete
Oct 8, 1998 those MULTIDD duplicates, which causes variable RESTARTS
in PDB.JOBS to be greater than 1 for job/TSO/STCs that
were not restarted. Fortunately, nothing else was bad!
Member VMAC30 was changed to KEEP variable EXTRADD in the
TYPE30_5 dataset, and the BY statement in macro _STY30U5
was changed by adding MULTIDD EXTRADD at its end.
Members BUILx005 had the BY statement for the PROC SORT
of DATA=TYPE30_5 changed by adding MULTIDD EXTRADD also.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.229 Validation of revised VMACTPMX uncovered several spelling
VMACTPMX typos and token id typos in the format table. Message is
Oct 9, 1998 now printed on log if an unknown token is encountered.
Oct 19, 1998 The token finding logic was revised to work under ASCII.
Variables PERFORM and INSYSAF no longer have $HEX format.
Labels were "split" with * characters and ending parens.
IMACTPMX's comments were corrected.
Thanks to Lawrence Jermyn, Fidelity Investments, USA.
Change 16.228 NTSMF Version 2.2 records with Record Header 2.2.1
VMACNTSM cause NEW OBJECT errors, OBJECT='SERVICE PACK 3', because
Oct 8, 1998 I did not understand the new Record Header Values:
Header Description
2.0 Original Header format, no 0.0 record
2.0.h Extended Header format, 0.0 record created
2.1 Compressed Header format.
2.2.1 0.1 record created, 2.0.H Extended Format
2.2.2 0.1 record created, 2.1 Compressed Format
Records with Record Header 2.2.2 were read without error.
HEADER FORMAT 1 should be specified in your DCS, as it
reduces the amount of data in each record header and
hence the volume of data sent from the monitored to the
monitor. However, if you have not installed 2.2 on all
of your machines, NTSMF 2.2 will use the old spec on the
monitored machines, and if they contains HEADER FORMAT 0,
you will write the old, longer records until you change
that parameter.
The MXG variable, VERSION, is used not only to determine
the format of the record, but whether there will be a 0.0
record (used to calculate STARTIME if it exists), whether
there are CPU fields in the 0.0 record, whether there
will be a 0.1 record, and whether it will precede (prior
to NTSMF 2.2) or follow (NTSMF 2.2+) the 0.0 record!
Thanks to Howard Glastetter, Weyerhaeuser Company, USA.
Change 16.227 IMS 5.1 records with IMF 3.2 cause INPUT STATEMENT EXCEED
VMACCIMS error, because MXG only input the new segment for 6.1.
Oct 8, 1998 Change the IMSLEVEL test from 61 to 51 so it will read:
IF IMSLEVEL GE '51' AND IMFLEVEL GE '32' THEN INPUT
@373+OFFIMS UTCA ....
Thanks to Harmut Peter, R & V Allgemeine Versicherung AG, GERMANY
Thanks to Don Cleveland, Wellpoint, USA.
Change 16.226 Variable SYSTEM was added to the KEEP= list for dataset
VMAC110 CICSSAP from the optional SAP journal segment. In 16.04,
Oct 8, 1998 the _LCICSAP and _WCICSAP datasets had incorrectly spelt
the dataset CICSAP instead of CICSSAP.
Thanks to Theo T. Peelen, Shell, THE NETHERLANDS.
Change 16.225 MXG 16.04, DFSMS 1.3 caused INPUT STATEMENT EXCEEDED, but
VMACHSM DFSMS 1.4 records caused no error message. MXG Change
Oct 8, 1998 16.136 incorrectly located the INPUT for new variables
WFSCPUTM and WFSACCT to before the INPUT of the VOLSER
segments. If there were 36 bytes of VOLSER data, the new
logic INPUT them as WFSCPUTM/WFSACCT, and then when the
old logic tried to read the VOLSERs, there were none!.
In addition, only the first VOLSER segment would have
been input. This change moves the new logic until after
any VOLSERs were input, and also iterates on WFSRNENT.
Thanks to Michael E. Friske, Fidelity Investments, USA.
======Changes thru 16.224 were in MXG 16.04 dated Oct 7, 1998======
Change 16.224 First MXG 16.04 only. JCLTEST6 fails with ID=220 SMF if
VMACOMVT they are not from OMEGAMON for VTAM. (If you have OMVT
Oct 6, 1998 records and have overridden the _IDOMVT macro in either
your IMACOMVT or IMACKEEP, you don't see this error - it
is only if you don't have OMVT but some other product is
writing type 220 records). Change the "220" in _IDOMVT
to "512", which is the impossible default SMF number that
should have been in VMACOMVT.
Thanks to Edd Carter, General Mills Restaurant, USA.
Change 16.223 The labels for variables CPUACTTM and CPUOVHTM were
RMFINTRV changed from "PROCESSOR" to "PROCESSORS" to be consistent
Oct 6, 1998 with variable CPUUPTTM and because all three variables do
contain the total time that all processors in the CEC
were active, uncaptured, or "up" (i.e., available).
Thanks to Edd Carter, General Mills Restaurant, USA.
Change 16.222 -First MXG 16.04 only. The new _STYTCPA "Sort" macro,
VMACTCP used only by the new TYPSTCP member, was missing an
VMXGINIT ending parenthesis in its definition. The DATA statement
Oct 6, 1998 that follows "MACRO _STYTCPA" statement should be:
DATA _LTYTCPA (LABEL='TYTCPA: .... API CALLS (SOCKETS)');
-Macro variable PTCPTCPS was not GLOBALed nor %LET in the
VMXGINIT member, causing unresolved macro reference.
Thanks to Chuck Hopf, MBNA, USA.
======Changes thru 16.221 were in MXG 16.04 dated Sep 30, 1998======
Change 16.221 Trending of Tape Allocations could overcount in a last
ASUMTALO interval that had data spread across two week's input
TRNDTALO with overlap during the same hour (i.e., last weeks last
Sep 30, 1998 allocation was from 0300-0315, this week has an allocate
from 0330-0345). This change corrects the allocate tape
count in that interval, but MXG's revisions in ML-17 of
ASMTAPES/MXGTMNT automatically synchronizes its interval
with SMF interval, so the exposure is reduced further.
Thanks to Jim Stevens, MBNA, USA.
Change 16.220 Logic for creation of NTCONFIG dataset from 0.0 and 0.1
VMACNTSM records was revised. For NTSMF 2.0 and 2.1, the 0.1 was
Sep 28, 1998 written first and then the 0.0, so MXG could OUTPUT to
NTCONFIG from the 0.0 record (including the three fields
that were RETAINed from the preceding 0.1 record). Now,
the output for NTCONFIG was located until after both the
0.0 and 0.1 were read and all their fields RETAINed, and
then OUTPUT from the 0.1 if NTSMF is 2.2 or later, or
OUTPUT from the 0.0 if NTSMF is Version 2.1 or earlier.
This really has minimal impact, as the NTCONFIG dataset
is only a log of configuration status, and not critical,
but now as new configuration fields are added to the 0.1
record, they will be added to dataset NTCONFIG.
Change 16.219 Final validation of MXG Support for IMS 6.1 Log Records.
ASMIMSL6 -The TIME DEC call returns a 0CYYDDDF format that is used
Sep 28, 1998 as a reference date to decide whether to delete or ignore
"old" INQUEUE records, but that value should have been
converted to the YYYYDDDF format of the INQUEUE record.
-ASMIMSL6 was enhanced to prevent U0012 abends if there
were insufficient slots being allocated on the initial
table load. While the number of slots can be provided to
ASMIMSL6 thru the //SLOTS DD statement, this enhancement
eliminates the need to specify slots in advance; the
INQUEUE is read (fast) to count records and NUMSLOTS is
reset to records+1000 if the slots are too few.
Thanks to Alan Green, British American Financial Services, ENGLAND.
Change 16.218 The VMXGTAPE macro sets TAPELIB=YES if an MVS SAS dataset
VMXGTAPE is on tape, but when run under ASCII SAS, produced notes
Sep 30, 1998 the SAS log. Additionally, when VMXGTAPE was used with a
DISK dataset, the second execution failed with an error
message UNABLE TO CLEAR LIBNAME. That error is fixed by
relocating the RUN; statement to be before the LIBNAME.
The error was not reported, because the only member to
use VMXGTAPE twice, TYPECIMS, uses tape rather than disk
for those large IMSTRAN files from IMF, and VMXGTAPE did
work fine when the MVS SAS dataset was on tape.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.217 -Support for NTSMF new objects NetShow Station Service and
EXNTNSHS NetShow Unicast Service creates NETSHOWS and NETSHOWU
EXNTNSHU datasets, respectively.
VMACNTSM -Logic for NTCONFIG was revised to read CPU Speed field
Sep 23, 1998 when VERSION GE '2.0.H' AND NTVERSN GE '3.51' because
the segment exists in the 2.0.h records. Additionally,
VERSION=UPCASE(VERSION); was inserted after its INPUT
and before the test to avoid case sensitivity.
Thanks to Jim Quigley, Con Ed, USA.
Thanks to Denny C. Wong, New York Life, USA.
======Changes thru 16.216 were in MXG 16.03B6 dated Sep 23, 1998======
Change 16.216 Support for OS/390 2.6 (COMPATIBLE) added new data:
VMAC73 -Dataset TYPE73 new var SMF73ACR, Channel Path Acronym
VMAC74 -Dataset TYPE74 new var DEVDISNV, Device Disconnect Time
VMAC79 Is Not Valid flag, Y or Blank.
Sep 23, 1998 -Dataset TYPE74. IBM renamed field SMF74NID to SMF74DCT
and increased it from 26 to 28 bytes, but MXG continues
to name the variable SFM74NID and it contains either the
Node Descriptor ID for self-describing devices, or the
four-byte Device Number.
-Dataset TYPE74CA new var R745CCMT, Hardware Type and
Model of the Control Unit, 28 byte character variable.
-Dataset TYPE79C new var R79CACR, Channel Path Acronym.
-Changes to TYPE99 subtype 6 were already in MXG.
Change 16.215 ACF2 Version 6.2 INCOMPATIBLY changed the type 'V' record
VMACACF2 causing INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Sep 23, 1998 Fortunately, most sites don't use the ACF2VR dataset that
is built from this record, so you can process their other
6.2 data by inserting the new line that tests LENGTH-COL
so that member VMACACF2 then contains:
IF ACVMFIDC GT 0 THEN DO _I_=3 TO ACVMFIDC;
IF LENGTH-COL+1 GE 8 THEN
INPUT ACVMFSEC $EBCDIC8. @; /*SECONDARY*AUTHID*/
CA provided same day documentation and technical support
of the changes in their record, which inserted an offset
field to the optional DB2 data fields, which is now used
and tested by MXG. No other new data was added.
Thanks to Frank d'Hoine, National Bank of Belgium, BELGIUM.
Thanks to Tim Dockter, CA, USA.
Thanks to Fred Duminy, CA, USA.
Change 16.214 Support for DF/SMS 1.4 changes to HSM records added new
FORMATS values for $MGHSMFU format to decode FSRTYPE:
Sep 22, 1998 Value Formatted value
6 USER requested Delete of a Migrated Data Set
17 HSM Expired/Deleted a Data Set
(FSRFLG3 then indicates where the dataset
existed when HSM expired/deleted it)
18 Partial Release
19='19:EXPIRE OR ROLL OFF INCREMENTAL BACKUP'
20='20:(H)BDELETE INCREMENTAL BACKUP'
Also it was noted that for a full volume restore (FSRTYPE
= 14), FSRFVOL is actually the target volume name, not
the source volume name.
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 16.213 The type 79 subtype 15 (IMS Long Lock record) fields were
VMAC79 not documented completely accurately, but will be in the
Sep 22, 1998 next SMF manual. New variable F79FTRNM is now INPUT, and
new format $MG079RT decodes F79FRGTY values. R79FPSTN is
either a PST number as 4 hex digits, or the character
string 'ID', which is 'C9C4'x. R79FLHTI is 8-bytes long,
but only the first four are used, as seconds after
midnight. R79FRSNA is now only INPUT if R79FETYP='W'.
Thanks to John Keenan, Boeing, USA.
Change 16.212 MXG did not input seven fields in the System record from
VMACTMV2 Landmark's The Monitor for MVS Version 2, causing dataset
Sep 22, 1998 TMVSSYS to have incorrect values. To circumvent, you can
insert a line with +28 between the INPUT lines for
SYSRESV4 and SYSUIC. The seven new variables in TMVSSYS:
SYSUASID,-AASID,-NASID,-SASID,-RASID,-OSASI,and SYSORASI.
are counters of ASIDs in USE/Available/etc.
Thanks to Jeff Justice, Integon, USA.
Change 16.211 Support for TCP/IP 3.4 Type 118 Subtype 5 SMF record.
EXTYTCPS The new TCP Statistics subtype causes MXG CRITICAL ERROR
FORMATS message and a delete of the new subtype, but the other
IMACTCP datasets are correctly built from the other records.
VMACTCP This support created new dataset TYPETCPS with TCP
Sep 21, 1998 Statistics counters.
Thanks to Huug Tempelmans-Plat, Hoogovens Staal BV, THE NETHERLANDS.
Thanks to Xiaobo Zhang, Insurance Service Office, USA.
Change 16.210 INVALID DATA FOR HH/MM/SS/INBUFFSZ/OUBUFFSZ from Super
VMACSUIN IND$FILE SMF records because some EBCDIC numeric fields
Sep 19, 1998 contain nulls instead of valid EBCDIC zeroes. Knowing
this now, each of the INPUTs that use &NUM. informat are
now preceded with ?? to suppress the warning messages.
The records with nulls also contain UNAVAIL for both the
TERMINAL name and the Logmode Entry Name, and the other
counters are zeroes, so I suspect these null records are
otherwise valid, and so their uninitialized fields are
now protected.
Change 16.209 SAS 6.12 for Windows, Maintenance TS045 changed what is
CONFIG printed on the SAS log when option STIMER is enabled.
Sep 18, 1998 Now, sixteen lines of Stack, Heap, Memory, and Images
stats are preceded by "HOST STATS FOR: xxxxxx" and are
printed for every data or proc step by the STIMER option.
MXG's CONFIG member has always enabled STIMER/FULLSTATS,
as they were useful in diagnosing memory problems back in
early V6, but the new output flooded my QA stream log, so
I have removed the overrides from MXG's CONFIG member, so
the SAS defaults (NOSTIMER,NOFULLSTATS) will be used. If
ever needed, they can easily be enabled in your CONFIG
file, thru the OPTIONS= in MVS JCL, or by using an
OPTIONS STIMER FULLSTATS; statement at the beginning
of your SAS program.
Change 16.208 Internal support for the NTSMF DTS 0.1 configuration data
VMACNTSM record created three new variables in NTCONFIG dataset:
Sep 17, 1998 PRFSENVR='PERFORMANCE*SENTRY*VERSION*THAT WROTE'
DCSLOCN ='LOCATION*OF DCS: REGISTRY/PRIDCS/DCSFILE/ETC'
DCSINTRN='INTERNAL*NAME*OF THE*DCS'
Change 16.207 PROC GPLOT has never worked right when its input dataset
ANALVARY has zero observations; in various SAS releases there have
ANALRRTM been Notes or Error messages, but _ERROR_ was never set.
Sep 17, 1998 But under SAS Version 7 Beta, these notes were created:
Sep 25, 1998 NOTE: No Observations in Data Set xxxxxxxx.
NOTE: The SAS System Stopped Processing due to errors.
NOTE: SAS Set Options OBS=0.
That false error message, and the setting of OBS=0, has
been accepted by SAS as a defect. However, SAS Tech
Support found that by relocating the SYMBOL statement to
precede the PROC GPLOT statement, the OBS=0 was not set,
so now the MXG 16.04 QA Stream has successfully executed
all steps under SAS Version 7 Beta!!!
Thanks to Chris Noto, SAS Institute Technical Support, USA.
Change 16.206 If you use the COUNT= option in ANALCNCR, and it has more
ANALCNCR than one variable, the BY list was wrong and it contained
Sep 17, 1998 repeated variable names. The MXG logic error is fixed by
changing &&COUNT&NUMCNT to read &&COUNT&I. Fortunately,
the important uses of %ANALCNCR in MXG don't use COUNT=.
In fact, this error was discovered by the new feature in
SAS Version 7 (ERROR: Duplicate variables in a BY list)
when the archaic example ANALTAPE that has %ANALCNCR with
COUNT=TAPEDRVS TAPE3420 TAPE3480 TAPE3490 TAPE3590,
was tested in the MXG QA stream.
Change 16.205 New format MG099TC decodes the Trace Action Codes in the
FORMATS Type 99 Goal Mode Workload Manager trace data, using the
VMAC99 Table 76 in Appendix A of OS/390 V2R5.0 MVS Workload
Sep 16, 1998 Management Services, mapping number to Trace Code Name.
The codes describe WLM decisions, and their full meaning
from that table is also in ADOC99.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.204 The externalization of tailoring for IMACACCT, IMACSHFT,
IMACACCT IMACWORK, and IMACUCB can now use the "MACKEEP" design of
IMACSHFT Change 16.134, with new MACACCT, MACSHFT, MACWORK, and
IMACWORK MACUCB macros defined and nulled in VMXGINIT and invoked
IMACUCB at the end of each of those IMACs. The BUILxxxx members
BUILDPDB/3 were updated also to invoke new EPDBINC macro variable to
BUILD001 permit tailoring of the EXPDBxxx members as well.
BUIL3001
VMXGINIT
Sep 16, 1998
Thanks to Chuck Hopf, MBNA, USA.
Change 16.203 The statement LENGTH=LEN; was changed to LENGTH=LENGTH;
UTILDUMP to eliminate the Warning "Unitialized Variable LEN". The
Sep 16, 1998 new SENDDUMP is probably better documented to get dumps.
Thanks to Hertwig Rainer, Lufthansa Systems GmbH, GERMANY.
Change 16.202 Finally, the logic to create SASSWORK and USERWORK macro
VMXGDEL variables (so we know where your WORK= and USER= point)
VMXGSUM works under both SAS V6 and SAS V7 and under OS/390 as
VMXGOPTR well as Windows and Unix. All this is for housecleaning
Sep 16, 1998 (delete work datasets when we can), but we needed to not
delete WORK.X after SORTing into USER.X if you had set
SAS options WORK= and USER= to the same data library.
Our logic executes PROC SQL on VTABLE to get the WORK=
and USER= current values. We expected DDNAMES, and the
code worked on OS/390, but under Unix and Windows you get
the full file specification name, with forward and back
slashes, etc, which required more logic revisions. Now,
we find that only under OS/390 can WORK= and USER= point
to the same library, so the logic was simplified. But
then, under Version 7, we found that PROC SQL no longer
reads the VTABLE when OBS=0 is specified, which caused
macro variables SASSWORK/USERWORK to be blank. (That
PROC SQL in Version 6 did not honor OBS=0 was accepted as
a bug and fixed in Version 7; that we got output under V6
was an unintended design feature, now corrected!). But
by inserting VMXGOPTR invocations before and after each
PROC SQL to momentarily override the OBS=0 to OBS=MAX and
then reset OBS to whatever it was, solves that problem.
And VMXGOPTR itself had to be revised for first time run
so it too will work properly when OBS=0 is specified.
Now, MXG has been executed under the SAS Version 7 Beta
on both MVS (OS/390) and Windows (98 and NT) platforms.
Change 16.201 Type 74 Cache data, variable R745CSC was not kept in data
VMAC74 set TYPE74CA, and variables CSDPIDAT and DEVPIDAT were
Sep 15, 1998 misspelled as CSDPIPID and DEVPIPID, and are now correct.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.200 The created variable STARTIME in contained only the date
VMAC94 and hour of the calculated Start time; now the equation
Sep 15, 1998 is STARTIME=SMFTIME-DURATM; but DURATM=3600; is set in
MXG because there is (as yet) no actual duration in the
VTS record, and no way to change IBM's default of hourly.
Thanks to Pat Hansen, Automated Data Processing, USA.
Change 16.199 NTSMF OBJECT='WidetoMBErr' created dataset WIDE2MBE, but
EXNTWIDE that was an April Fool's day trick. I found that object
VMACNTSM name in Discovery records last April, assumed it was a
Sep 15, 1998 new thing, and created the new dataset in Change 16.048.
Today, I discover that THAT string is the error code that
is returned by the translate function API when a Unicode
to ASCII translation fails (like when the Microsoft field
documented as Unicode actually contains ASCII values!),
and there really was no WIDE2MBE dataset to be built, so
its exit member EXNTWIDE and the code in VMACNTSM were
removed by this Change. Demand Technology discovered the
record was really for the SNA Adapter Object, and revised
their code to deal with its idiosyncrasies! So now, when
WidetoMBErr shows up, its time to call Demand Technology
so they can look inside PERFMON to find the actual name
for these aberrant objects, but also please run Discovery
and send the data file, so that I can circumvent it.
For example, the Beta of Microsoft Terminal Server 1.0
now has a counter object named 'WidetoMBErr' inserted in
the middle of the Process object, INCOMPATIBLY causing
an INPUT STATEMENT EXCEEDED RECORD LENGTH error ABEND.
While Demand Technology gets the data to investigate
their end and tell me what's really there, this change
creates variable WIDE2MBE in the PROCESS dataset to get
the field and support the new record. Later, when we
know the field name, this text will be revised to rename
and label and possibly format the variable.
Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.
Change 16.198 -MXG 16.03 only. MACRO _LIMSUNM UNMATCHED % was spelled
IMACIMSA wrong, and must be MACRO _LIMSUNM UNMATCHD % instead.
TYPEIMSA -PROC SORT DATA=IMSMERGE %VMXGFOR ; worked as long as you
Sep 10, 1998 didn't tailor the _LIMSMRG macro in your IMACIMS, but it
is now PROC SORT DATA=_LIMSMRG OUT=ZZIMSMRG %VMXGFOR;
The MERGE PRG (IN=INPRG) IMSMERGE (IN=INIO); is now
MERGE PRG (IN=INPRG) ZZIMSMRG (IN=INIO); and the DELETE
of IMSMERGE now deletes ZZIMSMRG, to make this work. The
macros will change once more when the 16.134 architecture
is applied to the IMS processing shortly.
Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
Change 16.197 The extra include of member IMACCICS in member TYPE110
TYPE110 prevented the &MAC110 or &MACKEEP logic from working to
Sep 10, 1998 redefine the _L macros. Member IMACCICS was removed from
member TYPE110's include, as it is already included by
the VMAC110 member, and there it include is followed by
the MAC110 and MACKEEP macros, so it can be overridden.
Thanks to Jerry Layne, Virigina Power, USA.
======Changes thru 16.196 were in MXG 16.03B5 dated Sep 9, 1998======
Change 16.196 Variables ELAPSTM, INPREQTM, and QUEUETM were calculated
VMAC33 before the variables used had been input. Now, the three
Sep 7, 1998 statements are inside the DO group, after TPNDTIME.
Variable TPUSRTYP was input and formatted, but not kept;
now it is in both TYPE33_1 and TYPE33_2 datasets.
Thanks to John Strumila, IBM Global Services Australia, AUSTRALIA.
Thanks to Lindsay Oxenham, IBM Global Services Australia, AUSTRALIA.
Change 16.195 The Printer Throughput analysis now created PDB.ASUMPRTR
ANALPRTR instead of PDB.PRINTER, to be consistent with current MXG
ASUMPRTR naming conventions. Scan your MXG Tailoring library and
Sep 6, 1998 change PDB.PRINTER to PDB.ASUMPRTR if it exists, but very
few sites regularly use this detailed analysis.
Change 16.194 -IBM now calculates the TYPE72GO Using/Delay Percentages
VMAC7072 using R723CTSA instead of CTOU+CTOT+CUNK+CIDL samples as
Sep 6, 1998 the denominator. R723CTSA adds CIOU+CIOD samples, and is
Sep 22, 1998 used even if I/O Delays are NOT being included in your
Oct 20, 1998 Velocity definition! Since R723CTSA is now larger, the
percentages will be smaller. So that MXG calculations
match the RMF reports, the correction in VMAC7072 is to
insert:
IF R723CTSA GT 0 THEN VALDSAMP=R723CTSA;
before:
IF VALDSAMP GT 0 THEN ....
-Variable PCTEXTSA is now set to missing value, as it is
a total sample count, now in R723CTSA, and not a percent.
-The I/O Velocity calculation when I/O Delay is NOT turned
on was changed to match IBM reports. MXG's old equation
VELOCITY=(CTOU+CIOU)/(CTOU+CIOU+CTOT) is changed to read
VELOCITY=(CTOU+CIOU)/(CTOU+CIOU+CTOT+CTDQ+CIOD) and the
code relocated until after CTDQ had actually been input!
OS/390 R2.4 added CTDQ in an extension of the SMR
record, but MXG's equation was back in the block of
code for the R1.3 extension. Now, 1.3 calculates
without CTDQ while 2.4 and later includes CTDQ.
When I/O Delay IS turned on, MXG sets R723VELI='Y' so the
velocity and I/O velocity are calculated the same way:
VELOCITY=VELOCIOD=CTOU/(CTOU+CTOT);
These changes now match the IBM RMF 2.4 Report values.
Oct 20, 1998 revision:
I/O Velocity enablement is system wide, and when enabled,
all of the Service Classes have R723MSCF='...1....'B, but
that bit is not on in the Reporting Class records. IBM
RMF has acknowledged their error and will fix it in a
future version of RMF, but MXG now stores R723MSCF from
the Service Class record (written first) into retained
variable SERVMSCF, which is now used instead of R723MSCF
to set R723VELI='Y' when I/O is enabled, so the correct
velocity equation will be used in spite of their error.
Thanks to Leonard Ponich, AT&T, USA.
Change 16.193 New reporting variables were added to MEMOACCT dataset:
VMACMEMO MEMDIST MEM3270 NEWMEM RETMEM SENMEM SESSION
Sep 6, 1998 TRXTOT USERPRF for direct reports from MEMOACCT.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 16.192 Variable A08DURAT=A08BKDTD-A08BKCTD is now created in
VMAC110 CICS statistics dataset CICSLSRR to report how long the
Sep 6, 1998 pool existed. However, the base times are time-of-day
rather than datetimes, so if the pool exists for more
than 24 hours, the duration will not be accurate.
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 16.191 TMS revisions were still not complete, as FILSEQ was
TYPETMS5 missing in second and subsequent VOLSEQs. Before the
Sep 5, 1998 END; statement for the ELSE IF FILSEQ=. THEN DO; insert
MAXFLSEQ=FILSEQ;
LSTFLSEQ=FILSEQ;
and after IF MAXFLSEQ LT 999999 THEN FILSEQ=MAXFLSEQ;
insert IF FILSEQ=. THEN FILSEQ=1;
to always populate FILSEQ variable correctly.
Thanks to John Rosewarne, Telstra, AUSTRALIA.
Change 16.190 Variable PCTDLNDI is now set missing, as it was not a
ADOC7072 valid percent of anything. Instead, the raw count of
VMAC7072 samples, R723CNDI, from which PCTDLNDI was erroneously
Sep 5, 1998 calculated, is now kept. See the detail description in
member ADOC7072 for new variable R723CNDI.
Thanks to Don Deese, (CPExpert), Computer Measurement Sciences, USA.
Change 16.189 Support for Thruput Manager, TPM, was supported earlier
EXTYTPMX by member TYPETPM, but that program INPUT only the data
FORMATS fields it knew about. This new TYPETPMX was written by
IMACTPMX Susan, and it creates temporary FORMAT $MXTPMTK to token
TESTUSR1 each possible TPM field, and then VMACTPMX uses that in
TYPETPMX its TPM record processing. The output dataset contains
TYPSTPMX all possible variables, but will likely be very sparce as
VMACTPMX most TPM sites don't enable all fields, so COMPRESS=YES
VMXGINIT is specified, since sparce datasets compress so well that
Sep 5, 1998 dropping the nonexistent variables is unwarranted. As an
example, 1000 obs uncompressed required 1005 pages, but
compressed by SAS, the TYPETPMX dataset needed only 40!
Thanks to Susan Marshall, SAS Institute ITSV Cary, USA.
Change 16.188 Variable R742PSIG is now documented in ADOC74 that its
ADOC74 contents, inbound or outbound request counts, are in or
FORMATS out depending on variable R742PDIR, path direction, which
VMAC74 is now FORMATed ('80'X=Inbound, '40'X=Outbound). Also,
Sep 5, 1998 variable R742PTYP, path type, is now FORMATed ('1=CTC,
3='List Structure') by $MG074PD and $MG074PT formats.
Thanks to Leonard Ponich, AT &T, USA.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.187 Support for XCOM Release 3.0 (COMPATIBLE) adds variables
VMACXCOM TCPIPNAM, TCPIPADR, and XCOMMICR to TYPEXCOM dataset. But
Sep 1, 1998 I discovered that variables FLDSNNME REPTDEST REPTFORM
REPTFCB REPTNAME COPYCNT HOLDFLAG CONTFLAG SPOOFLAG
DISPFLAG and REMFLENM were input from wrong locations. I
have confirmed the two important variables, FLDSNNME and
REMFLENM (input/output dataset names) are properly input,
and I think the others are also now properly aligned, but
they are all blank in my test data.
The test data also XCOMVERS=300 when the connection is
from Unix to MVS, and XCOMVERS=3 when the connection
is from MVS to Unix (actually, the value is 'F30000'X
but it prints as 3). But there's no real problem, as
XCOMVERS is not used in any MXG logic.
Thanks to Aubrey Tang, GIO Australia, AUSTRALIA.
Change 16.186 The PROC SORT %VMXGFOR DATA=_WCICDL2 OUT=SRTDLIR; should
CICINTRV be PROC SORT %VMXGFOR DATA=_WCICDL1 OUT=SRTDLIR; as the
Sep 1, 1998 CICDLIR dataset is _WCICDL1 instead of _WCICDL2 (which is
CICDLIT, but that dataset always has zero observations).
Without this change, the A18xxxx variables were missing.
Thanks to Fiona Crane, Royal and Sun Alliance, ENGLAND.
Change 16.185 MXG Support for IMS 6.1 (Change 16.171) is now validated!
ASMIMSL6 -ASMIMSL6 had references to MXGIMSLG, but the program name
TYPEIMSA CSECT name, and comments were changed to MXGIMSL6 to be
VMACIMSA consistent with the JCLIMSL6 member, and so that IMS 6.1
Sep 1, 1998 program name is different than earlier releases.
-VMACIMSA inputs of ARRTIM, NQTIM, GUTIM and DQTIM were
changed from &PD.4. to &PK.4., and the algorithm to
convert was changed. These inputs are now separated into
a block for pre-IMS 6 and post-IMS 6, using _IMSVERS to
choose the correct format.
-TYPEIMSA KEEP= list for _IMSTRAN.IMSTRAN has variables
OLTERM and OVTAMNDE added; they were inadvertently
dropped.
-With these changes, MXG support for IMS 6.1 matches the
Transit Log Report from IBM's IMS Performance Analyzer!
-See also Change 16.171.
Thanks to Alan Green, Allied Dunbar, ENGLAND.
Change 16.184 Utility to create MXG source for Formats $MGDDDDD and
UDDDDDD $MGDDDSN to map "dddddd" to "dataset" and vice versa,
FORMATS for internal use in Change 16.134 programs, like the new
Sep 5, 1998 %BLDNTPDB. UDDDDDD reads the MXG source to find all _W
macro definitions and writes out the VALUE statement that
defines each format, and the output is copied in at the
end of member FORMATS.
Change 16.183 Revision of MXG logic for ABEND and CONDCODE in PDB.JOBS.
BUILD005 While I still think using the PDB.STEPS dataset for job
BUIL3005 ABEND analyis is strongly preferred (because steps ABEND,
IMACPDB jobs don't, and because the STEPS data gives you the
SPUNJOBS PROGRAM name so you can identify who wrote the program
Aug 31, 1998 that ABENDed, and because jobs can have multiple step
ABENDs), this revision populates the PDB.JOBS variables
ABEND and CONDCODE with useful values, and creates new
variable ABENDS that counts the abending steps in a job.
Previously in PDB.JOBS, the ABEND value indicated that
one or more steps abended, but the CONDCODE value was
taken from the last executed step. If COND=ONLY or EVEN
was specified in the JCL, you could have had an ABEND
with a wrong or zero CONDCODE. Or if a step had what is
called a pre-execution ABEND that causes the step to be
not-executed (this includes FLUSHed steps, steps with a
SYSTEM 822 ABEND, and steps with SYSTEM 213 ABEND on the
STEPLIB, which are not explicitly identified in the step
records) the ABEND='SYSTEM' but CONDCODE was zero.
With this revision, the values of ABEND and CONDCODE will
be stored from the FIRST step that ABENDed. If there are
no ABENDs, but there were non-zero condition codes in any
step, the highest non-zero condition code will be stored
in CONDCODE and ABEND='RETURN'. And if there were no
ABENDs in the step records, but the 30-5 job termination
record has the ABENDed bit set in SMF30STI bit "6", the
logic sets ABEND='PREEXE' to flag that some step of the
job had a preexecution error. (Steps with pre execution
errors will have ABEND='FLUSH', so if there was only one
step with FLUSH, you could determine which step failed,
but if there were multiple FLUSH steps, you may not be
able to identify which step actually had the ABEND).
The default of FIRST can be overridden with the MXGCOND
macro variable, which can be %LET of the values of LAST,
HIGHEST, or LOWEST to choose which ABEND/CONDCODE pair
will be stored in PDB.JOBS.
Defaults:
One or more ABENDing STEPS
CONDCODE=CONDCODE of first ABENDing step
ABEND='SYSTEM' or 'USER' from first ABENDing step
ABENDS=number of ABENDing steps
However: If the JOB TYPE30_5 record has the ABEND
bit on but CONDCODE=0, which happens if
the last step did NOT ABEND, MXG sets
ABEND='ABEND' in the PDB.JOBS dataset.
No ABENDing STEPS - ABEND flag on in type30_5
CONDCODE=CONDCODE from type30_5
ABEND='PREEXE'
ABENDS=1
No ABENDing STEPS - No ABEND flag on in type30_5
CONDCODE=highest non-zero CONDCODE from STEPS
ABEND='RETURN'
ABENDS=0
These possible values for ABEND now exist in MXG:
ABEND Description
JCL PDB.JOBS only - Job did not Start on JES.
CRSH PDB.JOBS only - Job active during SYS FAILURE
PREEXE JOBS-only: Step had a pre-execution ABEND.
SYSTEM System ABEND
USER User ABEND
RETURN Return Code
CANCEX Cancelled in SMF Exit, CONDCODE tells which
FLUSH Step Flushed or Pre-Execution ABEND
RESTAR Step was RESTARTED
NOTCTL Not Cataloged Dataset Error
OMVSEX Open Edition/MVS Execution
COND=J COND= was specified on JOB card
OTHER Any other ABEND condition
If you have an IMACPDB member in your USERID.SOURCLIB, it
must be removed and instead you use the new 16.04+ design
that lets you add variables to PDB.STEPS/JOBS/PRINT with
%LET ADDxxxx= syntax (placed in your IMACKEEP member) as
described in the text of Change 16.341. This is because
to support CONDCODE, a new dataset WORK.CONDCODE is now
created in _PDBSUMS, but your old IMACPDB will override
that with the old logic, causing a SAS error message:
ERROR: FILE WORK.CONDCODE.DATA DOES NOT EXIST.
MXG now protects execution errors by creating a
zero-observation WORK.CONDCODE dataset just before
_PDBSUMS is invoked, but if your IMACPDB is in place, you
will end up with CONDCODE always zero in your PDB.JOBS
dataset. (No matter what you do, the CONDCODE in
PDB.STEPS is always correct!).
Change 16.182 Revised logic because %VMXGDEL did not always delete the
VMXGDEL _Wdddddd dataset, even when it was different from the
Aug 31, 1998 _Ldddddd dataset. This left datasets in //WORK library.
Change 16.181 The label for GDES2 was corrected, and the INFORMAT of
VMACQAPM variable DMSTS was changed from $EBCDIC1. to &PD.1., and
Aug 30, 1998 the INPUT of DIIDLT was changed from &PD.6. to &PD.6.8,
as it caused the value of PCTIOPBY in dataset QAPMDIOP
to be 10**8 too large.
Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA.
Change 16.180 The %BLDNTPDB macro for NTSMF processing is structurally
BLDNTPDB functional for building daily, weekly, monthly PDBs or
IMACNTSM for ad hoc analysis. Some reports exist, more to come!
TYPENTSM -By default, %BLDNTPDB now will read your raw NTSMF data,
TYPSNTSM (KEEPERS= or DROPERS= can be used if you don't want ALL),
Sep 5, 1998 then SORT what you kept to your PDB, then create the
PDB.NTINTRV at the raw data's interval, then create the
PDB.ASUMNTIN summary hourly interval dataset, then copy
your PDB datasets into the correct day-of-week library,
and then print and graph the daily reports. Additional
arguments RUNWEEK=YES or RUNMNTH=YES can be specified to
create the WEEKLY, MONTHLY and TREND libraries, and all
parameters are described in the BLDNTPDB member itself.
For example, if you wanted no reports or summary data,
but want only the four datasets PROCESS, PROCESSOR,
MEMORY, and LOGLDISK, you would use this invocation:
%BLDNTPDB(KEEPERS=NTPROC NTPROR NPMEM NTLDSK,
RUNNTINT=NO,ASUMDUR=NO,RPTDAY=NO);
to read those four objects and sort them into the PDB.
There are more reports to be added, and eventually the
logic will figure out when it is so a single invocation
can be used in every day's run, but that's a while away!
-Member TYPENTSM now only reads the NTSMF data and writes
to the default WORK location using the _WNTdddd macros;
TYPENTSM no longer sorts nor writes to the _LNTdddd macro
names, because new member TYPSNTMS (with the "S" instead
of the "E" to indicate "SORTs") performs the SORTs and
invokes NTINTRV to create PDB.NTINTRV.
If you were using TYPENTSM for your daily processing, you
should now use TYPSNTSM instead.
Member IMACNTSM no longer overrides the _L definitions.
Change 16.179 -SAS Version 7 incompatibility - long variable names.
VMXGSUM SAS Version 7 supports long variable names, and changed
Aug 28, 1998 the length of variable NAME (created by PROC CONTENTS)
Sep 8, 1998 from 8 to 32. MXG uses PROC CONTENTS in VMXGSUM and
expected 8-bytes; there is also a new SAS V7 warning when
different length variables are merged, and all of these
V7 "features" conspire to change the job condition code
from zero to four, which is just enough to cause your job
scheduling system to take notice of the change! The MXG
solution to this incompatibility between V6 and V7 is to
insert the statement LENGTH NAME $8 ; after the first
two statements DATA VAR1 (KEEP=NAME); in member VMXGSUM,
as that forces SAS to expect length 8 (and it is NOT my
intention to use long variable names in MXG, certainly
not in this millennium!).
-SAS Version 7 enhancement - OPEN=DEFER on SET statement.
A long-wanted Version 7 enhancement, OPEN=DEFER, lets you
read several datasets from different weekly PDBs using
only one tape drive:
SET TAPE1.JOBS TAPE2.JOBS TAPE3.JOBS OPEN=DEFER;
However, inside VMXGSUM, if you used this logic for
your input, and those datasets are on tape and KEEP=
logic was also used, VMXGSUM could have caused
unnecessary tape mounts, as it tries to figure out
what data is where, but VMXGSUM has no real awareness
of the individual datasets, and we are still examining
the best solution, but this revision now recognizes
the OPEN=DEFER parameter (and note it is not enclosed
in parenthesis, since it is a SET option and not a
dataset option. It might be that the best fix will be
to build the output keep list rather than the input
list when processing a tape, but that still is under
investigation. The caveat is that if you use the
OPEN=DEFER syntax with VMXGSUM, there will be multiple
mounts if the OS datasets are all multi-volume and the
default KEEPALL=NO is used.
With this change, MXG 16.04 or later is required for MXG
to execute under SAS Version 7. See MXG Newsletter, SAS
Notes for additional Version 7 Compatibility Issues.
-VMXGSUM now correctly figures out where the WORK option
points, so we can do housekeeping without erasing what
you just created. On an MVS system the value of the WORK
option returned by PROC SQL is the DDNAME/LIBREF "WORK",
but on Unix and PCs you get a full path name, for example
"!sasfolder\saswork" or "c:/sas/saswork" depending on the
platform. This change supports these idiosyncrasies.
"Line generated by the macro variable "TEMP01"
followed by E:\SASWORK.M was fixed by this change.
Change 16.178 MXG 16.03 only. Variables added with _PDBADD2/_PDBADD3
BUILD005 were not added to PDB.STEPS or PDB.JOBS because ACCOUNT
Aug 26, 1998 dataset was not output in the new architecture. In both
members, OUTPUT ACCOUNT; was added before _EDBJOBS;
Thanks to Dave Gibney, Washington State University, USA.
Change 16.177 Support for Microsoft Terminal Server 1.0 adds new data:
VMACNTSM for NT 3.51 and Service Pack 5A these were added:
Aug 28, 1998 Dataset SYSTEM:
ICABYTRT='TOTAL*ICA BYTES/SEC'
WINSTNAC='ACTIVE*WIN*STATIONS'
WINSTNIN='INACTIVE*WIN*STATIONS'
Dataset PROCESS:
IDLOGON ='ID*LOGON'
IDUSER ='ID*USER'
-Cosmetically, the LABEL statements in macro _CDENTSM were
consolidated and alphabetized so that they will control
the alphabetizing of the variables in each dataset.
Thanks to Bill Feeney, Hennepin County, USA.
Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.
Change 16.176 MXG 16.03 only. VMXGINIT "TALO" comments were corrected
VMXGINIT and IMACKEEP spelling corrected. Labels added for the
BUIL3005 SPIN datasets.
BUILD005
Aug 21, 1998
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 16.175 Support for Soft Audit's "Installed Products File" will
EXSFTPR read from filename XPPROD to create new MXG dataset
VMACSFTA SOFTPROD to track installed products.
VMXGINIT
Aug 19, 1998
Thanks to Normand Poitras, ISM, CANADA.
Change 16.174 MXG 16.03 only. The statement PUT ' DEBUG NDM .... ;
VMACNDM clearly should have been deleted.
Aug 15, 1998
Thanks to Chuck Hopf, MBNA, USA.
Change 16.173 MXG 16.03 only. Macro variable PSUNTIN was not defined.
VMXGINIT It must be added to the GLOBAL statement and then %LET to
Aug 15, 1998 DEFAULT.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 16.172 MXG 16.03 only. The LABEL='NTTUDP: ...' should have been
VMACNTSM 'NTUDP: ...', as the DDDDDD portion of the label is used
Aug 15, 1998 to drive the _S sort macros.
Thanks to Greg Jackson, National Life of Vermont, USA.
======Changes thru 16.171 were in MXG 16.03B4 dated Aug 11, 1998======
Change 16.171 Support for IMS Log processing for IMS 6.1. As stated in
ASMIMSL6 MXG Newsletter TWENTY-FIVE, this code is not officially
JCLIMSL6 supported. This code has not been fully tested, but the
VMACIMSA ASMIMSL6 program's output was read, and the VMACIMSA code
Aug 11, 1998 changes to the 07 and 08 record were lifted from VMACIMS.
I have high hopes this code will work without problem,
but plan validation against IMF records in September,
as I ran out of time to squeeze this code in as it is!
The logic in ASMIMSL6 stores the MSC time for ARRTIME
when there is an MSC segment, which I think is a change
from ASMIMSL5 - does it make any difference in your data?
Thanks to Dario Franceschi, Nordbanken, SWEDEN.
Thanks to Sal Fazio, IBM Global Services, USA.
Change 16.170 Support for the NCR Teradata DBS performance data. This
ADOCTDTA user contribution works, and even has documentation in
JCLTDTA ADOCTDTA, and the JCL will need to be tailored. This
TYPETDTA was added to MXG 16.03B4 at the last minute and has not
Aug 11, 1998 yet been added to the MXG QA stream.
Nov 12, 1998 Nov 18: Members JCLTDTA and TYPETDTA actually added!
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 16.169 Member ASUMTALO did not copy SPIN.SPINTALO into the PDB
ASUMTALO library for backup, but it should have, so I added:
Aug 11, 1998 PROC COPY IN=SPIN OUT=&PDBMXG;SELECT SPINTALO;
BUILDPDB has backed-up its SPIN datasets into the PDB
since Version 8, and all MXG components that use the
SPIN library will now also backup their SPIN datasets.
Why backup the SPIN library? Because if your daily PDB
job fails, you can recover by copying all of the SPINxxxx
datasets from your last good PDB library into your //SPIN
library: PROC COPY IN=PDB OUT=SPIN; SELECT SPIN:; and
then pick up processing with the SMF data from the day
after the last good PDB was built!
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Thanks to David Ehresman, University of Louisville, USA.
Change 16.168 Variable SMF88RAT was described in Change 13.156, but was
VMAC88 not created in dataset TYPE88 until this change.
Aug 11, 1998
Thanks to Martin Peck, iT-Austria, AUSTRIA.
Change 16.167 Minor. Cleaned up VMACUNIK so it will execute under MVS,
VMACUNIK just for MXG test stream. The real member for UNIKIX on
JCLQAJOB MVS is unchanged, VMACUNIA.
Aug 8, 1998
Change 16.166 Variables SMSHWMDS 'HWM SIZE' and SMSHWMDT 'HWM TOTAL'
ANALCISH were reversed in their INPUT statement; DT is first, then
VMAC110 DS is input. ANALCISH reports were correct, because it
Aug 7, 1998 used the wrong names, so now it too must be changed to
use DS for Peak DSA Size and DT for Peak DSA Total.
Thanks to Andrew Adams, Australian Taxation Office, AUSTRALIA.
Thanks to Craig Magill, Australian Taxation Office, AUSTRALIA.
Change 16.165 Type 79 subtype 15 (IRLM Long Lock) records contain only
VMAC79 two triplets, and IBM's documentation makes no note that
Aug 7, 1998 there are only two, and since all other subtypes had 3,
MXG expected three. Now, the number of triplets is
tested and only two are input when there are only two!
Thanks to Kenneth C. Jones, Boeing, USA.
Change 16.164 MXG's MXGTMNT monitor misses too-fast VTS tape mounts.
ASMTAPES Scratch Tape Mounts to VTS (Virtual Tape System) can be
Aug 11, 1998 satisfied in much less than the 2-second sampling rate.
Tests at 1/2 (500ms) and 1/10 (100ms) will be made, but
the internal VTS log shows the Mount and Ready times can
be in the same .01 second. It might be that the software
delay can be captured with the 100ms sampling even when
the VTS itself thinks it took less time, but it may also
require a significant change to the architecture of the
MXG Tape Mount monitor - we may have to capture the Mount
message as an event to capture these too-fast mounts!
There was no change made by this change, but this text
will be revised when the tests have been completed.
VTS is a pretty slick technology, even if it causes me
design problems in the tape mount monitor. In the day
in question, MXG missed about 300 mounts out of 1200.
Note: Member ASUMTAPE was added after this change, and
corrects the need to reduce the ASMTAPE interval time.
Change 16.163 Variables JESNR, INITTIME, and READTIME were INPUT but
VMACTMNT not kept in TYPETMNT dataset, so Mount and Step records
Aug 6, 1998 can be combined.
Change 16.162 This analysis is not complete, but the program matches
ANALVTS SMF type 30 DD segment for tape allocations, the MXGTMNT
Aug 6, 1998 Tape Allocation SMF record, the MXGTMNT Tape Mount SMF
record, and the type 21 Tape Dismount record to construct
a complete picture of each tape allocation and mount.
The program needs some cleanup to deal with long running
tasks and steps that span the time interval in the SMF
file (start-before-end-in and start-in-end-after), but
for events which all occur within the SMF file, it's
pretty accurate. If you are interested, run the program
and give me a call - there are lots of ways these tape
events can be analyzed, now that we have total duration
of allocation and mount and usage and bytes read/written!
The ultimate name may change; this program was used to
verify that MXGTMNT was missing Virtual Tape System tape
mounts - see Change 16.163 and 16.165.
Thanks to Chuck Olsen, Alltel, USA.
Thanks to Ken Lamonda, Alltel, USA.
Change 16.161 Variables ALOCTIME and LOADTIME were added to the KEEP
VMAC30 list for dataset TYPE30_D (a/k/a PDB.DDSTATS) to support
Aug 6, 1998 the ANALVTS utility.
Change 16.160 Support for Landmark's SQL/CAPTURE type 'D6' record adds
EXTMDD6 three new datasets:
EXTMDD6B TMDBD6 - Base segment stats, CPU, counters, etc.
EXTMDD6S TMDBD6B - Per Buffer Pool counts
VMACTMDB TMDBD6S - SQL Text
Aug 4, 1998 Variable D6RECNR will be common for all observations in
the Buffer Pool and SQL Text datasets for each record and
is the merge variable to use to match observations.
This was challenging: the SQL text field has either text
in ASCII or in EBCDIC but there is no flag. I now test
the first character of the first segment for EBCDIC or
ASCII, and use that mode to decode the rest of the 100-
byte segments of SQL text. Initially, I tested the first
character of each 100-byte segment, until I hit a segment
starting with '6D'x that is an ASCII "m" or an underscore
in EBCDIC. Using the start of the SQL text will decode
correctly since the start text is real text characters.
(And the '6D'x was actually an EBCDIC underscore!).
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
Change 16.159 The calls for OUTCODE and OUTCODE1 exits were moved to be
VMXGSUM after the calculation of DURATM so that its value would
Jul 31, 1998 be available in those exits.
Change 16.158 A new analysis of SMF Write Rates (MEGABYTES at 1/10/100
USMFRATE second intervals) reads your SMF file and produces print
Jul 31, 1998 reports and an export dataset to be sent if needed. If
you have had SMF Buffer shortages, this analysis will let
you know how much SMF data is being produced and how well
it is being handled by your DASD and SMF Buffering. Read
the comments, run the program, and send the listing. An
MXG Technical Article on this subject will follow soon.
Change 16.157 MXG CONFIG member's value of VMCTLISA=40K can cause a 0C4
CONFIG ABEND in function VMZGMAE that goes away if VMCTLISA=60K,
Jul 29, 1998 and the SAS default value in 6.09 is now VMCTLISA=160K!
That old value for VMCTLISA as well as old values for the
VMPAISA VMPAOSA VMPBISA VMPBOSA PSUM SORT31PL PROCLEAVE
and SYSLEAVE options were set years ago for SAS 6.06, but
they are now deleted from member CONFIG so that MXG will
no longer override those SAS memory options.
Thanks to Lee West, Direct Line, ENGLAND.
Change 16.156 Variable R723CQDT in TYPE72GO was misspelled R723CDQT.
VMAC7072 Now, both variable names exist to protect for past usage
Jul 29, 1998 but R723CDQT is the correct spelling.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.155 Support for BGS I/O Monitor Version 5.1.0 (COMPATIBLE)
VMACBGSI added new triplet to support of Goal Mode changes that
Jul 27, 1998 creates new B1MONSRV dataset (I/O by Device by SRVCLASS),
and the new version supports the year 2000.
Change 16.154 ML-17 of MXGTMNT Tape Mount and Alocation Monitor adds:
ASMTAPES - SMF interval support; MXGTMNT now listens for ENF 37
Jul 27, 1998 and automatically synchronizes to your global interval
- Initialization messages are issued when MXGTMNT is run
as a batch job instead of a started task.
- Error recovery recursion was improved.
- USINGs were cleaned up to prevent HLASM warning message
and eliminate CC=4 due to USINGs.
Note that ML-16 was never generally distributed.
Change 16.153 The CICS GMT offset value, MCTMNTAD, is only four bytes,
VMAC110 causing it to be truncated by as much as 1.04 seconds.
Jul 27, 1998 Since MCTMNTAD is added to STRTTIME/ENDTIME to convert to
the local time-of-day, they were also slightly off. But
now I see there is an 8-byte GMT offset value MCTMNDTO
that is exact and eliminates the truncation, so now the
variable MCTMNTAD will be set equal to MCTMNDTO as long
as the two values are within two seconds (to protect for
a zero value in DTO?), by the addition of the line:
IF ABS(MCTMNTAD-MCTMNDTO) LT 2 THEN MCTMNTAD=MCTMNDTO;
immediately after the MCTMNTAD=1.048576*MCTMNTAD line.
(Back in MXG 14.14 I had tried to make MCTMNTAD exact
with MCTMNTAD=3600*FLOOR((MCTMNTAD+900)/3600) logic, but
but I had removed that approximation by MXG 15.15, and it
was the comparison between MXG versions that provided
this opportunity to use the exact GMT offset value.)
Thanks to Andrea C. Schiro, Duke Energy Company, USA.
Change 16.152 These archaic members that were needed only in the past
VMAC110M are deleted to save space and avoid wasting your time
VMAC110S reading their comments to find out what they were! The
VMACRRTM VMAC110's were for SAS 5.18, VMACRRTM became VMACROSC,
VMACZRB VMACTMS became VMACTMS5, and VMACZRB became VMACRMFV.
Jul 26, 1998
Change 16.151 Macro _CMFDATA was still defined in these members, but it
IMACCMF has not been referenced in MXG since Change 7.119, when
VMACCMF Boole added bits by which variable PRODUCT could be set
Jul 25, 1998 to 'CMF...' instead of 'RMF'. The macro definition and
its now-incorrect comments have been deleted.
Thanks to Dan Worsham, Ohio Bureau of Worker's Compensation, USA.
Change 16.150 Variable TYPETASK='A ' for both ASCH and OMVS address
VMAC30 spaces, but in those SMF records that contain the SUBSYS
VMAC32 field, it contains either ASCH or OMVS, so it makes sense
VMAC42 to set TYPETASK=SUBSYS when TYPETASK starts with an 'A'.
VMAC91 There are other SMF records that contain TYPETASK that do
Jul 23, 1998 not contain the SUBSYS field: VMAC's 434, 6, 26J2, 26J3,
BETA, CTLD, IPAC, NNAV, PROS, SFTA, TMNT, X37, XPSM, so
they will still have TYPETASK='A '; While both type 6
26 have a variable SUBSYS, it is not the MVS SUBSYS field
but the PDB.JOBS/STEPS/PRINT datasets will now have the
correct TYPETASK value, from the type 30 records.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 16.149 The SHORT ABAR message still existed after Change 16.025
VMACHSM because an INPUT @15+OFFSMF @; is also needed after the
Jul 20, 1998 ELSE IF 15 LE FSRTYPE LE 16 THEN DO; statement.
Thanks to Alan Freed, ADP, USA.
Change 16.148 Dataset DB2STATR contained repeated outputs of the first
VMACDB2 QLST segment because CHANGE 14.195 was dropped somewhere
Jul 16, 1998 after MXG 14.14 and was not in MXG 15.15. Insert the
statement OFFQLST=OFFQLST+LENQLST; immediately before the
END; /* END TRACE SECTION FOR TYPE 100 SUBTYPE 0*/ as was
described in CHANGE 14.195.
Thanks to Warren E. Waid, JC Penny, USA.
======Changes thru 16.147 were in MXG 16.03B3 dated Jul 15, 1998======
Change 16.147 NETSPY 'N' records from old release 4.4 were dropped by
VMACNSPY MXG between MXG 14.14 and MXG 15.15, because I did not
Jul 9, 1998 think anyone was still using 4.4. The NSPYREC='N' logic
had been changed to use only NSPNRECI in recognizing the
subsubtype, but back with 4.4, NSPNRECI is always zero,
so I have had to put back the test for NCPELTYP and
NSPNSUBT to support these old records.
Thanks to Kevin Marsh, AT&T Solutions EMEA, ENGLAND.
Change 16.146 -VMXGSUM syntax for the "DATETIME" variable was kludgy;
VMXGSUM you had to say DATETIME=xxxxTIME, and then use DATETIME
Jul 9, 1998 in the SUMBY= list instead of the real xxxxTIME variable
name. This was needed so that the variable DATETIME
could carry the modified datetime values generated by
VMXGDUR when you specified INTERVAL= and DATETIME= to
create a new interval value. And, in order to retain
the original labels for the variable used in the
datetime calculations, you also had to use an ID
statement and then manually drop the variable DATETIME.
This change that logic; you no longer need to code the
name "DATETIME" in the SUMBY or ID arguments. You only
need to specify the argument DATETIME=xxxxTIME, to tell
VMXGSUM what variable to use as the datetimestamp value,
and now you can use the real xxxxTIME variable name in
the SUMBY= argument. This change is backward compatible
and will work properly if DATETIME is still used in the
SUMBY= list, but using the real variable name is better!
-VMXGSUM arguments TEMP01=,TEMP02=, and TEMP03= will still
be used to send intermediate WORK files to those DDnames
(for performance or space considerations), when they are
coded on the VMXGSUM invocation, but now you can redirect
the intermediate files externally, by %LETting the new
MXGTMP1, MXGTMP2, or MXGTMP3 global macro variables
to the desired DDname, before the include of the program
that invokes VMXGSUM. For example,
%LET MXGTMP1 = TEMPDD1 ;
%LET MXGTMP2 = TEMPDD2 ;
%INCLUDE SOURCLIB(ASUMDB2A);
Change 16.145 Support for APAR OW31281 adds HSM statistics for RECALL
FORMATS RECOVER, and additional fields to the DSR and FSR SMF
VMACHSM records. New DSR variables DSRNRCL DSRNRCV in dataset
Jul 7, 1998 HSMDSRST measure the number of times when RECALL/RECOVER
was satisfied by a tape that was already mounted. New
FSR variables FSRDEVCL FSRDEVTY FSRDSMNT FSROFF83
FSRRECRE FSRSCNAM in dataset HSMFSRBO provide device
class and device type, the number of tape mounts that
were avoided thru recall/recover, flags, number of tries
to recall, and the Storage Class Name.
The APAR also provided new values 19 and 20 for the
FSRTYPE field that were added to format MGHSMFU, but
values 15-18 have been skipped or are undocumented!
Thanks to Dave Cogar, U.S. Department of Transportation, USA.
Change 16.144 Significant enhancement uses Change 16.134 architecture
BLDNTPDB to build daily/weekly/monthly/week-to-date/month-to-date
Jul 7, 1998 PDBs for NTSMF data, with some simple reports implemented
and more to come. This member is documented in ADOCNTSM.
Change 16.143 One GRAPH of Tape Mounts had seconds instead of hours on
GRAFTMNT the x-axis, and GRAFTMNT did not accept SASGRAPH=YES if
Jul 7, 1998 specified (but using the default SASGRAPH=, did work).
Thanks to Billy Westland, Litton Enterprise Solutions, Inc.
Change 16.142 This utility, used only in JCLTEST6 to get 10 SMF records
VMXGGETM of each type and subtype, is now expanded to expect 512
Jul 7, 1998 subtypes, as DB2 type 102 records exceeded 255 subtypes.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.141 The DURATM calculation in ASUMCACH was revised. Because
ASUMCACH the TYPE74 data can contain data from many systems, the
Jul 7, 1998 DURATM could have been inflated by the number of systems
that shared that volume with activity. Since you must
chose a single source system for the TYPE74CA dataset,
(in EXTY74CA), its DURATM is now used in ASUMCACH.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.140 The weekly interleave of ASUMDB2B in WEEKBLDT failed with
WEEKBLDT wrong sort order. The correct sort variables are:
Jul 6, 1998 SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN
QWHCCV QLACLOCN QWHCCN QBACPID QWACBSC
SHIFT
Thanks to Scott Snyder, First Bank, USA.
Change 16.139 Invalid CMF User "240" SMF record has 20 Cache Statistics
VMACCMF segments (CMF27CCN=20) but only 19 Cache Device segments
VMACCMF (CMF27DIN=19); the device address in the 1st CCN segment
Jul 6, 1998 does not have a corresponding DIN segment. This is a CMF
record error that caused INPUT STATEMENT EXCEEDED error,
but MXG now compares device addresses in the two segments
instead of assuming they matched as documented, and MXG
circumvents their error. Boole fixes BMP6301 (4.3.0) and
BPM6303 (5.2.2) exist to correct the record, now that I
have circumvented their error!
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 16.138 Landmark CICS Version 2 native records protection added.
VMACTMO2 A message is now printed if you try to read compressed
Jul 1, 1998 records without having installed the EXITMON6 decompress
exit.
Thanks to Glenn Delvecchio, Stelco Inc, CANADA.
Change 16.137 NOTE: INVALID ARGUMENT TO FUNCTION SQRT apparently occurs
ASUMCICS due to very small differences (9th digit) in calculating
TRND72 the Standard Deviation as SQRT(A-B) when N=1. A=B to 14
Jun 29, 1998 14 places with PROC PRINT, but A-B is different in 9th
place! Since the real STD is zero in these cases, the
logic now tests A-B for positive before SQRT() and sets
STD=0 if A-B is not GT zero.
Thanks to Jon Whitcomb, Great Lakes Higher Education Council, USA.
Change 16.136 DFSMS 1.4.0 added (compatibly) new variables WFSCPUTM and
VMACHSM WFSRACCT in HSMWWFSR dataset, so you can measure CPU time
Jun 26, 1998 used by HSM for ABARS ABACKUP/RECOVERY processing. If
you can figure out how to populate that WFSRACCT account
field, it might be useful too!
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 16.135 VTS variables SMF94VBA and SMF94VLA were mis-documented
VMAC94 by IBM. They are not the "Midnight" values of data bytes
Jun 26, 1998 and virtual volumes, but are the "End of Interval" values
so their label was corrected.
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 16.134 -The new &MACKEEP and IMACKEEP MXG architecture is here!
BUILDPDB "MACKEEP" Architecture of MXG-built SAS "Datasets"
DIFFXXXX
DOCMXG Everything about the creation of an MXG dataset is now
fully externalized, and all dataset tailoring can now be
IMACXXXX EDITed into a single member, IMACKEEP (instead of using
TYPEXXXX each product's IMAC), or dataset tailoring can be done
TYPSXXXX "instream" using %LET MACKEEP= syntax, with no EDIT!
VMACXXXX
VMACXXXX All MXG datasets can be referenced using the new syntax
VMXGDEL &Pdddddd.DATASET and you can use %LET Pdddddd= MYDD;
VMXGINIT to change the destination to which a dataset is written
VMXGINV or the library from which it is to be read from.
VMXGLBIN
VMXGSUM Member DOCMXG contains the following description, and
Jul 4, 1998 additional discussion of the new architecture, and will
Sep 3, 1998 be the primary documentation of MXG syntax and design.
"MACKEEP" Architecture of MXG-built SAS "Datasets"
Fifth Draft Sep 3, 1998
"Product Suffix"
The xxxx suffix of the TYPExxxx/VMACxxxx/IMACxxxx/
ASUMxxxx/GRAFxxxx/ANALxxxx members for a "product":
Product xxxx Datasets
SMF Type 0 0 TYPE0
SMF Type 30 30 TYPE30_1,TYPE30_4,..
SMF Type 74 74 TYPE74,TYPE74CA,TYPE74CF,..
SMF 110 SMF 110 CICSTRAN,CICINTRV,CICFCR,..
NTSMF NTSM PROCESS,NTINTRV,PROCESOR,..
An MXG "Product" is defined by its VMACxxxx member,
which defines all of the macros for product xxxx, and
defines all datasets MXG builds from that product.
You run %INCLUDE SOURCLIB(TYPExxxx); syntax to read a
product's records and create all MXG SAS datasets in
the //WORK file. You run %INCLUDE SOURCLIB(TYPSxxxx);
to read the records and create SORTED output, normally
into the //PDB file. TYPSxxxx instead of TYPExxxx is
now the recommended program to use for a product.
IMACxxxx product members are now used only to override
the macros that you want to change. Definitions of
the Product Macros (_IDxxxx, _Nxxxx, and _Sxxxx) and
Dataset Macros (_Ldddddd, _W, _K, _E, _B, _Sdddddd)
were moved from the IMACxxxx into the VMACxxxx member.
Product IMACxxxx members are now only comments listing
the product's xxxx and its dddddd and DATASET names.
Even better and also new, all tailoring changes can
now be EDITed into only one place, member IMACKEEP,
instead of having to EDIT a separate IMACxxxx member
for each product. (Your old IMACxxxx's will still be
honored, but IMACKEEP is called after the IMACxxxx, so
existing IMACxxxx changes can still be overridden.
And still even better and also new, especially if you
don't like having to EDIT and SAVE a member to tailor,
you can now do it "on the fly", in your SYSIN stream,
by %LETting the new "&MACKEEP" macro to change any of
the dataset macros, including the Exit Member code to
select which observations are written!
And best of all, if you only want to change the DDNAME
to which a sorted DATASET is written, there is a new
&Pdddddd macro for each DATASET that you can %LET in
your SYSIN with this syntax:
%LET PTY74CA=TAPE74CA ;
%INCLUDE SOURCLIB(BUILDPDB);
to create your normal PDB, except that the TYPE74CA
dataset would be written to TAPE74CA.TYPE74CA instead
of being written to the default of PDB.TYPE74CA.
"DATASET"
SAS "Table Name" or SAS DATASET NAME, 8-characters,
are defined in the dataset's _L macro. Examples are
TYPE0, TYPE30_1, TYPE74CA, CICSTRAN, PROCESS, NTINTRV.
"Dataset Macros"
_L, _W, _K, _E, _B, _S, one set for each DATASET, are
defined in the VMACxxxx member for the product:
_L - "&P OUTPUT/SORT Destination LIBREF" macro
_W - "Work Library Dataset Name" macro
_K - "Keep/DROP Dataset Tailoring" macro
_E - "Dataset Exit" macro
_B - "BY List of Variables" macro
_S - "Dataset PROC Sort" macro
They can be overridden in &MACKEEP/IMACKEEP/IMACxxxx.
"Dataset Suffix"
The six character "dddddd" dataset suffix is a unique
string for each dataset. It is used in the old-style
_Ldddddd/_Wdddddd/_Kdddddd/_Edddddd/_Bdddddd/_Sdddddd
"dataset macros", is the suffix of the EXdddddd exit
member name, and is the suffix of the new &Pdddddd.
The dddddd values are encoded. For datasets starting
with TYPE (TYPE0, TYPE70PR, TYPE74CA) the dddddd is
TYaaaa (TY0, TY70PR, TY74CA). Other datasets encode
dddddd= yyzzzz/yyyzzz/yyyyzzz value with y= product
and z= dataset. CICS 110's have dddddd=CICTRN/CICINT
for CICSTRAN/CICINTRV datasets where yyy=CIC.
Similarly, NTSMF encodes dddddd as NTzzzz, so NTBROW
and NTPROR are dddddd for BROWSER and PROCESOR.
The dddddd value of each MXG dataset is defined in the
VMACxxxx members, but the IMACxxxx for the product is
the documentation of the dddddd and DATASET values.
"&PDB/&P macros"
The seven-character Pdddddd macro variable name, one
for each DATASET, defines the DDNAME/LIBREF to which
that sorted DATASET will be written. First, MXG
writes each DATASET to the //WORK file, using the
old-style substitution macro _Wdddddd:
MACRO _Wdddddd DATASET %
MXG then SORTs from the _Wdddddd to the _Ldddddd macro
that contains the new-style &Pdddddd macro variable:
MACRO _Ldddddd &Pdddddd..DATASET %
The default Pdddddd value, usually "PDB", is set by
VMXGINIT at MXG initialization, so now you can use a
%LET statement in you program to change the output
destination DDname for a dataset:
//SYSIN DD *
%LET PTY74CA = MYDD74CA ;
%INCLUDE SOURCLIB(TYPE74);
and you no longer have to EDIT into an IMAC member.
Most sites should never need to change much else!
(Note that while references use &Pdddddd syntax, the
ampersand is not used in the %LET statement.)
"Product Macros"
_IDxxxx, _Nxxxx, _Sxxxx, _VARxxxx, _CDExxxx members
are defined in the VMACxxxx member for the product:
_IDxxxx - "Record ID macro for user SMF records"
_Nxxxx - "_NULL_ all datasets in this product"
_Sxxxx - "SORT all datasets in this product"
_VARxxxx - "Variables/Datasets structure macro"
_CDExxxx - "Code to Decode structure macro"
The _VARxxxx and _CDExxxx macros should NEVER be
changed, as they are the heart and soul of MXG code;
all tailoring macros exist precisely so that you can
change MXG without changing the _VAR or _CDE macros!
The _IDxxxx macro sets the record number for user SMF
records, and must be changed in IMACxxxx/IMACKEEP or
with MACKEEP= logic to read product xxxx records.
The new _Sxxxx and _Nxxxx macros make tailoring easy.
The _S Sorts all datasets, the _N Nulls all datasets:
MACRO _S74 MACRO _N74
_STY74 MACRO _WTY74 _NULL_ %%
_STY74CA MACRO _WTY74CA _NULL_ %%
... ...
% %
If you %INCLUDE SOURCLIB(TYPS74) or run BUILDPDB, all
eleven TYPE74zz datasets are created and sorted. Now,
if you only want the TYPE74 dataset, and you want to
write it to the "TY74TAPE" DD name (perhaps, a tape?):
//SYSIN DD *
%LET PTY74=TY74TAPE;
%LET MACKEEP=
_N74
MACRO _WTY74 TYPE74 %
MACRO _S74 _STY74 %
;
%INCLUDE SOURCLIB(TYPS74);
and only dataset TY74TAPE.TYPE74 would be created, in
the WORK file, then sorted into the "PDB" default, and
then WORK.TYPE74 is automatically deleted.
The %LET PTY74 sets the Pdddddd macro variable value
with the output LIBREF/DDNAME of the desired dataset.
In the %LET MACKEEP=, the _N74 invocation changes the
default _Wdddddd dataset names to _NULL_, and then the
MACRO _WTY74 override "un-_NULL_'s" that dataset so
TYPE74 will be created, and the MACRO _S74 definition
contains only the _Sdddddd sort macro for the TYPE74
dataset that you want created! It's that simple.
"Old-Style Macro"
All MXG Old-Style macros start with an underscore.
The definition MACRO _oldstyl whatever %
will have "whatever" substituted when SAS sees the
string "_oldstyl" at compile time. "Whatever" can
contain characters and symbols to be used as parts of
SAS statements, or can be entire blocks of SAS code.
If "whatever" contains a percent-sign it must be a
double-percent in the MACRO definition. As SAS uses
the last MACRO definition encountered, any old-style
macro can be redefined with &MACKEEP, or in IMACKEEP.
"Macro Variable"
SAS Macro Variables are also used to substitute stored
text, but with different syntax. They start with &
when they are referenced, but that ampersand is not
used when defined with %LET or CALL SYMPUT statements:
%LET PDByyyy = value ;
or inside a DATA step, you can use SYMPUT:
CALL SYMPUT('Pdddddd','value');
For MXG's &Pdddddd macros, "value" is a LIBREF/DDNAME
for the output DATASET, which can always be %LET.
But for &MACKEEP macro, "value" can be anything from
the (most likely) redefinition of an old-style macro:
%LET MACKEEP = MACRO _IDHSMDS = 240 % ;
to the (less likely) lines of SAS statements to create
new variables, select observations to be output, etc.,
(as when you tailor a "Dataset Exit" _Edddddd macro).
If the text does not contain a semicolon, the simple
syntax of %LET MACKEEP = value ; is used,
even when there are % or %% in the value text.
But if MACKEEP= value contains any semicolons, then
syntax of %LET MACKEEP= %QUOTE( value ) ;
must be used:
And, if the value contains single-percent signs,
they must be doubled inside the %QUOTE function.
And, in a new quirk of the SAS macro language,
if the text contains double-percent-signs (as in
%%INCLUDE in the _Edddddd Dataset Exit macros),
those double-precents must be triple-percents!!
CICSTRAN Example.
You want to read type 110 CICS records but only create
CICSTRAN observations for a specific APPLID, and you
want to write them (unsorted) to the CICSTRAN DDNAME.
The product IMACxxxx member documents which dddddd to
use for which dataset, but in the expected IMAC110
member, it admits that the IMACxxxx for SMF type 110
is the inconsistently-named IMACCICS member, and there
you find out that the dddddd value for the CICSTRAN
dataset is "CICTRN". Then you can use:
// EXEC MXGSAS
//SMF DD DSN=smf.data,DISP=SHR
//CICSTRAN DD DSN=output,DISP=(,CATLG)
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
_N110
MACRO _WCICTRN CICSTRAN.CICSTRAN %
MACRO _ECICTRN
IF APPLID='CICP' AND TRANNAME='XYZ1' THEN DO;
%%%INCLUDE SOURCLIB(EXCICTRN)
END;
%
)
;
%INCLUDE SOURCLIB(TYPE110);
The _N110 invocation nulls out all type 110 datasets,
so we then re-instate MACRO _WCICTRN so that it's data
is created, and by prefixing the dataset name CICSTRAN
with "CICSTRAN.", that dataset will be written to the
//CICSTRAN DD instead of //WORK, so its "full" name is
CICSTRAN.CICSTRAN.
The %QUOTE ( ) syntax is used to add a DO group around
the %%%INCLUDE, and any number of SAS statements could
be used inside the _ECICTRN macro in this better way:
Note that percent-signs were increased by one due
to the QUOTE ( ). Also, don't use "DELETE" logic
in your "Dataset Exit" logic, because records can
contain multiple transaction segments, and the
DELETE would prevent MXG from looking at the rest
of the transactions in the record. Instead, always
cause an OUTPUT of observations you want and skip
past the ones you don't want to output.
The preceding example was revised April, 1999.
The following text describes additional changes that were
made in this redesign, and that is followed by discussion
of possible compatibility issues with past tailoring.
-VMXGINV will "Inventory" a DDNAME with PROC CONTENTS and
will extract the "dddddd" dataset suffix from the LABEL
of every dataset in that library, so we can know which
datasets exist, with their "dddddd" values, so we can
auto-drive additional processing.
-VMXGLBIN will initialize a SAS data library to match the
contents of an existing library, but all datasets in the
new library will have zero observations. This is used in
the first-time logic in WEEKLY/MONTHLY processing.
-VMXGDEL will delete a _W dataset by its dddddd token if
the library pointed to by the _Wdddddd value is NOT the
same as the _Ldddddd (output) library and dataset. This
is used after the PROC SORT to delete its input, but not
when you sort the output back into the input dataset!
-BUILDPDB/BUILDPD3 phases are externalized with new macros
_DIFFDB2, _INTRMF, _INTCICS, and _BLD005 that can be set
to blank to bypass processing. The JOBS/STEPS/PRINT
logic was externalized to BUILD005/BUIL3005, and all of
the _PDB macros are defined in BUILD005/BUIL3005 rather
than in the BUILDPDB/BUILDPD3/BUILD001 members.
-MULTIDD logic in old BUIL3005 was corrected (BUILDPD3 had
been correct all along, and now BUILDPD3 calls BUIL3005).
-New formats $MGDDDDD and $MGDDDSN map dddddd to dataset
and dataset to dddddd values.
-New macro variables MXGTMP1 thru MXGTMP5 are GLOBALed,
defined in VMXGINIT, and default to WORK. Their names
&MXGTMP1, &MXGTMP2, etc., are the "Standard" macro names
for temporary work space that you can set globally. You
used to have to code TEMP01= on the %VMXGSUM invocation,
and VMXGSUM still honors TEMP01 if coded, but now you can
use %LET MXGTMP1 = MYTEMPDD ; and VMXGSUM will use that
destination instead of the //WORK default.
-LIMITATION: If you use %LET MACKEEP= logic to redefine
old-style macros, you can't use %LET MACKEEP= again in
the same SAS execution, unless you reset the old-style
macro to itself before the second %LET MACKEEP= logic:
%LET MACKEEP= MACRO _WTY0 FIRSTDSN % ;
%INCLUDE SOURCLIB(TYPE0);RUN;
MACRO _WTY0 _WTY0 %
%LET MACKEEP= MACRO _WTY0 SECNDDSN % :
%INCLUDE SOURCLIB(TYPE0);RUN;
If you did not have that MACRO _WTY0 _WTY0 % reset, the
second %LET would have used "FIRSTDSN" for the _WTY0 and
you would have %LET MACKEEP= MACRO FIRSTDSN SECNDDSN %;
and the second MACKEEP would not have changed _WTY0!
COMPATIBILITY NOTES:
-If you used a %INC SOURCLIB(TYPExxxx); program and you
also used the IMACxxxx to change the _Ldddddd macro, the
old version wrote to your modified _L destination, while
the new version writes to the _W (work) destination.
Circumvention/workaround/the way to do it now include:
a. Use: %LET MACKEEP= MACRO _Wdddddd _Ldddddd % ;
to use your _L definition from your IMAC for the _W
destination of the unsorted dataset.
b. Change your IMACxxxx to override _W instead of _L.
c. Use new TYPSxxxx instead of TYPExxxx, to write to _W
first and then SORT to your _L destination. Since the
_S SORTS eliminate duplicate records, it is now MXG's
recommendation to use TYPSxxxx instead of TYPExxxx.
d. See notes in member INSTALL, with examples of errors.
Status in MXG 16.04:
-Except for five products, (CRAY,FRYE,RSxx,SNIF,VMXP), all
VMACxxxx members and TYPExxxx members have been revised.
-Some _Sdddddd "sort" macros still have a DATA step rather
then the PROC SORT because I don't know the unique set of
variables that will eliminate duplicates for that data.
-IMACs now contain only comments that define the dddddd
and DATASET names.
-No Beta site has had any real problems with this change!
Change 16.133 -The summarization of NETWSEGM into NTINTRV was wrong if
NTINTRV there was more than one network segment instance. Now
VMACNTSM the rate variables are summed and the maximum percent of
Jun 24, 1998 any segment is added to NTINTRV dataset as NETSxxxx.
-The number of Physical Disks is counted and added into
NTINTRV as variable NRPDISK.
-The instance field NETWSEGM was missing in the _BNTNETS
definition in VMACNTSM.
Change 16.132 Revised utility that reconstructs VB or VBS data on MVS
UDEBLOCK that was uploaded from a PC file. This utility creates
Jun 24, 1998 one record per block, so if you intend to re-read the
output file multiple times, it would be worthwhile to
reblock the output file by copying with IEBGENER or SAS.
The earlier version did not always work correctly.
Change 16.131 On UNIX, VMXGSUM fails because of UNIX forward slashes.
VMXGSUM The failure produces these messages:
Jun 22, 1998 ERROR: A character operand was found in the %EVAL....
ERROR: The macro VMXGSUM will stop executing.
The failing statement is part of MXG housekeeping:
%IF &SASSWORK NE WORK %THEN ....
where &SASSWORK is a macro variable filled in by SAS
from SASHELP.VOPTION table that under MVS contains the
value of the WORK= option, which is a DDNAME or libref.
If your WORK= option is 'WORK' we do housekeeping and
delete work files, but if your WORK= is anything else,
then we don't delete anything in your library.
This statement fails under UNIX, because under UNIX, the
&SASSWORK value does not contain a libref, but instead
has a full UNIX directory pathname, with forward slashes
that here are interpreted by the SAS %Macro Compiler as
divide-by signs, which is invalid in this context, so
VMXGSUM fails to compile under UNIX!
It might be argued that the error is in the SAS macro
compiler, but the real error was in not knowing that what
is returned by SAS in &SASSWORK depends on the platform
on which MXG is executing. For PC SAS, $SASSWORK also
contains a pathname, but since PC pathnames use reverse
slashes, so SAS had no problems in compiling under UNIX.
Although the underlying logic will never be satisfied as
written for PC or UNIX SAS, adding the %QUOTE() function
around the &SASSWORK string tells SAS to ignore those
strange characters, so this change:
IF %QUOTE(&SASSWORK) NE WORK %THEN ....
allows VMXGSUM to execute anywhere!
I did test most of MXG in 1995 under UNIX, but that was
with an earlier VMXGSUM. I do not run MXG QA stream on
UNIX, as I do not have nor intend to have a UNIX system,
and believe that testing under PC SAS, plus many happy
users running MXG under UNIX with no errors, is enough.
This is the first and hopefully the last incompatibility
between ASCII SAS platforms that has had any impact on
MXG, and it's because no one had used the VMXGSUM utility
under UNIX yet.
Chris detected, diagnosed, and provided this solution.
July 9, 1998: See MXG Change 16.146.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.130 -Type 70 RMF records contain an unexpected segment for
VMAC7072 CPUs that were varied offline. The segment does have
Jun 22, 1998 CAI=0 (SMF70CNF) that flags that this CPU was neither
online at the end of the interval nor reconfigured, and
has invalid VOLSER ('E00000'x). The unexpected segment
populated variables CPUSERn, CPUWAITn, IORATEn, where n
is the CPUID that the offline processor had when it was
last online. Now, MXG protects for this segment by only
populating the n-th variables when CAI is non-zero. The
PCTTPIn value was also wrong for the nth segment, but the
cause was a missing ELSE PCTTPI=.; clause to protect its
value when the IOINT denominator is zero, as was found in
these segments. Fortunately, this segment had little
impact on important type 70 measurements, because all of
the CPU-busy variables were already missing or zero. I
intend to suggest that IBM not write this unexpected and
wrong segment in type 70 records.
Thanks to Martyn A. Jones, Chase Manhattan Bank, ENGLAND.
Change 16.129 -A major revision to TMS/CA-1 processing was precipitated
ADOCTMS5 by the discovery that the DSN in the VOL records is not
TYPETMS5 always the true dataset name on that VOLSER: for multi-
VMACTMS5 volume, multi-file sets, the DSN in the VOL record of the
Jun 23, 1998 second and subsequent volumes is the dsname of the first
Aug 11, 1998 dataset in the set of multiple files. This meant there
were observations in TMS.DSNBRECD with the wrong DSN for
some VOLSERS. If you tried to select all VOLSERs for a
specific DSN, you would miss all of the interior VOLSERs
as well as the final VOLSER that contained that dataset.
Fortunately, this past error probably had little, if any,
impact on tape chargeback using TMS.DSNBRECD, for at
least two reasons. First, these sets are usually backups
of groups of common files for an application, so all of
the DSNs are usually owned by the same department that
you billed. Second, since the BLKCNT in these bad VOL
records is always zero, calculated FEET or BYTES would be
zero, so you probably zero billed the wrong DSN anyhow!
The Block Count must be zero in these VOL records (i.e.,
for datasets that start with a DSNB) because the total
block count for the entire dataset across all of its
volumes is recorded in the BLKCNT in the DSNB record.
Unless CA-1 is redesigned to break the total dataset
Block Count into the count per VOLSER, we will never know
how much of one volume is occupied by each piece of these
datasets, but at least now you have the correct DSN for
each VOLSER which contains any part of that DSN.
The final SORT order of TMS.DSNBRECD is
BY ZDATE OVOLSER VOLSEQ FILSEQ CURR;
where OVOLSER is the "Original, or first VOLSER of a set"
and is blank for single-volume tapes, where VOLSEQ and
FILESEQ have been propagated/created by the new logic,
and where CURR is the (current) DSNB number for the
DSNBRECD observations created from DSNB records. CURR
has a missing value in DSNBRECD obs created from VOL
records, and is used as a discriminate in MXG logic.
Additionally, the size of each dataset in TMS.DSNBRECD in
bytes, calculated as Block Size times Block Count, (as
was TAPEFEET) is now created in variable DSNBYTES, and
the total size of each VOLSER in TMS.TMS is now created
in variable TAPEBYTE; both are formatted MGBYTES.
This is a major revision of the logic for TMS processing,
and the gory details of the problem and its solution,
(which took three full days to figure out and implement),
complete with example, is now in member ADOCTMS5.
The before and after runs with a 194MegaByte TMC show:
TMS.TMS TMS.DSNBRECD Elapsed Duration
obs obs vars (PENTIUM II 350)
BEFORE 510,000 203,772 42 12 minutes
AFTER 510,000 203,765 46 14 minutes
so the added cost of the new sorts and data steps seems
minimal. The smaller number of observations in the new
DSNBRECD is the result of removing the VOL records which
have blanks or " IO ERROR" as their DSN values.
The AFTER run with same data on an Amdahl millennium took
15 minutes elapsed (and 9 minutes CPU) under OS/390!
Thanks to John Rosewarne, Telstra, AUSTRALIA.
Change 16.128 For NTSMF Version 2.1.0 running under NT 3.51, the error
VMACNTSM INPUT STATEMENT EXCEEDED RECORD LENGTH occurs because the
Jun 18, 1998 NTSMF record is missing the CPU Speed field in the 0,0
CONFIG record. This change only inputs the new sections
if both VERSION GE '2.1' AND NTVERSN GT '3.51'.
Thanks to Jim Quigley, Con Ed, USA.
Change 16.127 This member is still in testing, but now at least it has
BLDNTPDB been debugged and corrected and works. More is planned.
Jun 18, 1998
Thanks to J. Wayne Holzbach, Reynolds Metal Company, USA.
Change 16.126 Unused Change Number.
Change 16.125 IMACKEEP was added at the end of the %INCLUDE list, where
TYPEIMS7 it had been overlooked. Member IMACKEEP was part of the
Jun 12, 1998 original MXG architecture, designed to let you override
the _VAR macros to change the contents of MXG datasets,
but that turned out to be the wrong way to tailor MXG,
because your _VAR override died when I had to add a new
dataset for that product, so Change 10.175 introduced the
new way, by defining _L and _K macros in each IMAC for
each product. However, I kept the IMACKEEP INCLUDE in
all members, just in case it might be useful to have a
common exit in the future, and its future is now!
That future is described in Change 16.134, but it was a
conversation with Peter that triggered the realization
that IMACKEEP will again be the right place, and that led
to the &MACKEEP architecture.
Thanks to Peter Enrico, Watson and Walker, USA.
Change 16.124 Variables SELAPSTM, the step elapsed time, and JOBCLASS
ANALDSET are now kept in both DSETOPNS and DSETSUMS datasets, so
Jun 12, 1998 the OPENTM can be compared to SELAPSTM, for candidate
analysis for HiperBatch and BatchPipes, and so JOBCLASS
can be used to filter unwanted job observations.
Thanks to Lawrence Jermyn, Fidelity Investments, USA.
Change 16.123 ROSCOE code revised to execute under ASCII SAS; several
VMACROSC $EBCDIC1. fields were changed to $CHAR1. and formatted to
Jun 12, 1998 $HEX2. Fields used in binary tests, for example,
IF ROSREC EQ '60'X THEN ... failed when TYPEROSC was run
under ASCII sas with $EBCDIC informat, because SAS change
the '60'X to '2D'x with that informat. Using the correct
$CHAR informat for these binary values fixed the error.
Thanks to Martha Wearen, Department of Agriculture & Food, IRELAND.
Change 16.122 -Variables SYSID, APPLID, and SYSPLEX were blank in most
VMACTMO2 datasets. Change TMSYSID to SYSID, TMENAPLD to APPLID,
Jun 12, 1998 TMSMFSID to SYSTEM, and TMMVSID to SYSPLEX.
Jun 17, 1998 -The GMT offset variables TMENGMTO and TDENGMTO are now
input as &IB.8. rather than &PIB.8., like TAENGMTO, but
while the TAENGMTO value is almost correct, the other
two GMT offsets are wrong in Landmark's records:
Record Hex Value In Record Input as &IB8.6 value
TA FFFFFFFB CF100000 -5:00:00.90
TI FFFFBCF1 DCC00000 -20480:00:00:00.00
TD FFFFBCF1 DCC00000 -20480:00:00:00.00
Note that the TI and TD values are clearly shifted left
three nybbles, causing their invalid value, but also note
that the TA value is truncated on the right, so it is not
exactly five hours. The correct 8-byte value should be:
FFFFFFFB CF1DCC00 -5:00:00.00
Landmark has opened Activity 111176 to correct the GMT
offset; until a fix is available, the GMT offsets are not
usable.
Thanks to Brian Sanger, Eagle Star, ENGLAND.
Thanks to Mike Wroot, SAS UK Customer Support, ENGLAND.
Change 16.121 New NTSMF objects "Caching Manager" creates CACHEMGR and
EXNTCAMG "Packet Filtering" creates PACKTFLT datasets, and revised
EXNTPKFL object "Web Proxy Server Service" increased the data from
IMACNTSM 37 to 56 fields, which are now supported.
VMACNTSM
Jun 11, 1998
Thanks to Leigh Ann Payne,Wachovia Operational Services, USA.
======Changes thru 16.120 were in MXG 16.02 dated Jun 8, 1998======
Change 16.120 New ERASEOUT parameter was added so that the output data
VMXGSUM set can be erased before creation. For the TREND system
Jun 8, 1998 this will reduce the size of the TREND library, since the
old design created the new TREND dataset while the old
TREND dataset still existed, so the library needed to be
exactly twice the size of the TREND dataset. Making the
change in VMXGSUM will not change the TREND dataset sizes
until a later change adds the ERASEOUT parameter to the
TRND members. The options are NO, YES, or DDNAME, and if
DDNAME is specified, a copy of the old TREND library is
made in that DDNAME before replacement by the new data.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.119 Preliminary support for IMS 6.1 Log Records has tested
IMACIMS the 07 and 08 records, so that member TYPEIMS7 is now
IMACIMS7 supported (it counts transactions and total resources,
VMACIMS without response time, for resource accounting of IMS).
Jun 8, 1998 There were massive changes in all IMS log records, with
new information as well, and more work will be done in
the next few weeks to the other parts of MXG IMS code,
notably there will be an ASMIMSL6 for the JCLIMSLG code.
This change includes the 01, 03, 31x and 35x log records,
but none of the new variables have been added and there
is still much validation needed.
Thanks to Dario Franceschi, Nordbanken, NORWAY.
Change 16.118 Tandem variables C0BLKS, C1BLKS, C2BLKS, and C3BLKS are
VMACTAND the cache blocks of 512/1024/2048/4096 bytes allocated,
Jun 4, 1998 and should not have been divided by DURATM. Variable
C1BLKSAV, average entried in the dirty queue should have
been divided by DURATM (like the other three measures).
Thanks to David Foster, Norwest Services, Inc.
Change 16.117 CODEPCT=150 is now the default, replacing CODEPCT=134.
CONFIG This is a compiler option that controls how much virtual
Jun 4, 1998 storage is set aside for the generated program in a DATA
step. If SAS's original guess is too small, it prints a
message suggesting a larger value of CODEPCT (usually one
unit higher!). By setting MXG's default to 150, that SAS
message and user questions about it are eliminated, and
you may save a couple of CPU seconds during the compile
phase of BUILDPDB's SMF processing step. You can also
eliminate the message (which is seen only if you have
modified your BUILDPDB to process additional SMF record
types) by passing CODEPCT as an option in your JCL:
// EXEC SAS,OPTIONS='CODEPCT=150'
Thanks to Thierry Van Moer, COMPAREX, BELGIUM.
Change 16.116 Support for Candle Omegamon for CICS V400 SMF record 255
VMACOMCI subtype 203 sub-subtypes 1 and 2 (INCOMPATIBLE) added no
Jun 4, 1998 new information but inserted blanks and FFFFs. Other
sub-subtypes are probably affected, but only these two
were available at this time for validation.
Thanks to Steve Smith, BMC Systems, USA.
Change 16.115 The support for Landmark DB2 Version 3.1 (Change 16.097)
VMACTMDB worked fine with 3.1, but failed with 3.0 'DA' record,
Jun 4, 1998 INPUT STATEMENT EXCEEDED, because MXG read in a number of
fields in the 3.0 logic that are not in the 3.0 records!
This change deleted those fields and their INPUTs.
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
Change 16.114 Processing ICEBERG and XCOM SMF records together cause an
VMACXCOM error because variable REQTYPE is numeric in ICEBERG but
Jun 4, 1998 was Character in XCOM. Hoping that changing XCOM has
less impact than changing ICEBERG, I have change the name
in the XCOM datasets from REQTYPE to REQTYPEX.
Thanks to Sharon Hindle, EDS Australia, AUSTRALIA.
Change 16.113 Landmark DB2 Version 3.1 INVALID DATA FOR HSRN is printed
VMACTMDB on the log for record 'DE', but the output datasets built
Jun 2, 1998 are not affected. MXG incorrectly tried to read the
"standard header" but the 'DE' record doesn't have one!
To eliminate the message and hex dump, change the line
IF LMRKREC NOT IN ('DC','DD','DF','DW') THEN DO;
to read
IF LMRKREC NOT IN ('DC','DD','DE','DF','DW') THEN DO;
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
======Changes thru 16.112 were in MXG 16.02 dated Jun 2, 1998======
Change 16.112 Cosmetic. If you drop variables from DB2ACCT and use the
ASUMDB2A ASUMDB2A to summarize, UNINITIALIZED VARIABLE messages
Jun 2, 1998 are printed on the log during the ASUMDB2A execution of
VMXGSUM. These have no impact on the end results, and
are printed for those variables that are used in INCODE=
logic, but cannot be eliminated because VMXGSUM cannot
parse the INCODE or OUTCODE arguments for variable names.
However, additional UNINIT messages that were printed due
to the LABEL statement in the OUTCODE= argument are now
eliminated, by moving that LABEL statement into INCODE.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.111 -MQ Series SMF 115 MQMBUFER dataset misspelled QPSTDWT as
VMAC115 as QPSTDTW, so now (for a while) both variables exist,
VMAC116 but the DTW spelling will go away in a future version.
Jun 2, 1998 Variables QPSTID, QPSTLL and QPSTEYEC are dropped, as
they are always constant and should not have been kept.
-MQ Series SMF 116 MQMACCT dataset variable QWHCXTYP is
named ATYPE in MQ SMF documentation, but the values that
MQ chose for their ATYP are not at all the same as the
DB2 values for ATYP, and so MXG had to spell ATYP XTYP
in the MQMACCT dataset so that it could be formatted
for its values instead of the DB2 ATYP values. This is
not a code change, but rather explanation as to why the
ATYP variable is spelled XTYP in MQMACCT.
Thanks to Richard Tsujimoto, Chase Manhattan, USA.
Change 16.110 Cosmetic. The input data can only be the _LIDMTAS data
ASUMIDMS from the IDMS Perfmon SMF data, and this eliminates
Jun 1, 1998 UNINITIALIZED errors in my QA stream. Previously, there
were MXG-created SMF records for IDMS, and this report
would use either, but the old MXG monitor only ran under
IDMS Version 10 and earlier, and those records no longer
exist.
Change 16.109 IBM has trashed the IODF Creation Date field in RMF type
VMAC73 73-1, 74-1, and 78-3 records at least in OS/390 R1.3.
VMAC74 All three records have two separate IODF Creation Date
VMAC78 fields, and both have exactly the same character strings:
Jun 1, 1998 Field Names format data value
SMF73TDT, SMF74TDT, R783TDT mm/dd/yy 19/98/04
SMF73TDY, SMF74TDY, R783TDY mm/dd/yyyy 19/98/2004
This OS/390 R1.3 production system had never been tested
with a year 2000 IPL - I think the 2004 is an accidental
value. Several APARs document the IODF format starting in
back in 1993 (OY64585) and in 1996/1997 (OW15406/OW27552)
but there is currently no open APAR about bad values.
This error was seen in an RMF record, but CMF could have
the same problem, if IODF is creating a bad value and both
RMF and CMF are simply copying that bad value.
The nasty symptom of these bad date fields are two SAS
"INVALID ARGUMENT TO FUNCTION MDY AT LINE nnnn COL mmm"
messages, hex dumps of the several thousand bytes of the
bad record, the PUT _ALL_ lists of VARIABLE=VALUE for
about 30-40 pages of printed output.
While we research the problem with IBM, I have changed
each IF YY GT 0 THEN IODFDATE=MDY(MO,DD,YY) to now read:
IF 1 LE MO LE 12 AND 1 LE DD LE 31 AND YY GT ) THEN ....
(or YYYY for the TDY fields) to validate the arguments of
the MDY() function to prevent print of the hex dump/list.
Either way, with or without this print-prevention, the end
result is the same: variable IODFTIME will be missing
until IBM corrects their records, but everything else in
the MXG-built datasets is just fine and dandy!
Thanks to Jean Murphy, Capital Group, USA.
Change 16.108 This "NTSMF PDB Build" example is still not in its final
BLDNTPDB state, but it is getting there. This change removed the
Jun 1, 1998 PROC COPY INDD=WORK OUTDD=PDB that was left from testing
(it copied unsorted datasets over top of sorted datasets
and caused DATASET NOT SORTED errors).
Thanks to Carl Kyonka, Consumers Gas, USA.
Change 16.107 The PDB now PROC SORT's the other six TYPE74xx datasets
BUILDPDB into the daily PDB library. Four XCF datasets (TYPE74CO,
BUILDPDB TYPE74ME,TYPE74PA, and TYPE74SY), the OMVS Kernel dataset
BUILDPD3 TYPE74OM, and the IRLM Long Lock dataset TYPE74LK that
BUILD003 should have been put in your daily PDB library now are!
VMXGINIT VMXGINIT was updated to define the &PDB74xx macro name
May 29, 1998 for each PDB dataset. See Change 15.320 for discussion.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.106 Enclave CPU and transaction variables CPUASRTM CPUENCTM
IMACPDB and ENCLTRAN from TYPE30_4 step termination records are
May 29, 1998 now kept in PDB.STEPS and summed into PDB.JOBS datasets
with this enhancement.
Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Change 16.105 Support for the Web Proxy logs in Common Log Extended
TYPEWWW format adds new variables to TYPEWWW:
May 29, 1998 CLHEADER CLRQSIZE CONTLGTH HTTPCLVS HTTPSTAT PRREQHDR
PRRESHDR PRRQSIZE RMRESHDR TOTALTM
The left and right square brackets on UNIX have hex value
of '5B'x and '5D'x, but when FTP'd to MVS, they become
'AD'x and 'BD'x, and if IND$FILE'd to MVS they then are
'4A'x and '4F'x, so MXG now tests for all three values
that have been encountered when these ASCII logs are
sent thru different ASCII to EBCDIC translation tables.
Thanks to Brian J. Farley, Reliastar Life Insurance Co., USA
Change 16.104 -ANALCISH CICFCR report can cause ERROR: MORE THAN 32,767
ANALCISH VARIABLES. The PROC TRANSPOSE and array logic that was
May 29, 1998 used (so that one pass of the CICFCR dataset could
generate four reports) breaks that SAS limit when there
are thousands of CICS files. This redesign eliminates the
array and transpose logic, with one pass of CICFCR for
each report requested. We will enhance the redesign so
that only a single pass will be required, but that change
is more extensive, and this change solves the immediate
problem of getting the reports printed.
-CICJCR report can cause ERROR: MORE THAN 10 LINK
STATEMENTS HAVE BEEN EXECUTED. The LINK HEAD;
logic was eliminated.
Thanks to Eain Aronott, Toronto Dominion Bank, CANADA.
Thanks to Ian Mackay ,Royal Bank of Scotland, SCOTLAND.
Change 16.103 Deleted change.
Change 16.102 Support for Raptor Systems' Eagle V4.0 Log Message 121
EXEAG121 is decoded into dataset EAGLE121 with information on the
IHDREAGL individual connections thru that UNIX firewall product.
IMACEAGL EAGLE121 contains duration, type of service, source and
TYPEEAGL destination IP addresses (with port number), url and the
VMACEAGL filename accessed, and bytes sent and received, etc. The
May 28, 1998 other log messages are output into dataset EAGLEOTH with
the MSGID and LOGTIME and other header variables.
The MXG support reads the Version 4.0 records that were
created by Raptor Systems' FLATTEN program. While those
records are created on UNIX, MXG can read them either as
native ASCII records if you run MXG under ASCII SAS, or
you can ship the records to your MVS system (translating
them to EBCDIC in the process) and run MXG there.
FLATTEN records have a header of fixed fields that are
delimited by '09'x on ASCII (which becomes '05'x on MVS)
and then a series of field1=value1 field2=value2 ...
that are delimited by blanks, and then an undocumented
set of six numeric fields containing one byte of zero
in ASCII/EBCDIC that is delimited by '09'x/'05'x. While
the SAS NAMED INPUT technique is meant to handle data
like the field1=value1 series, it could not be used here
for two reasons: a) one of the data fields (ARG, which is
the full url and filename) can contain equal signs, which
would prematurely terminate its input and truncate its
value, and b) once SAS starts NAMED INPUT in a record,
there can be no following fields. So MXG instead must
parse and test the name field for each field.
These records look useful for tracking firewall accesses
but there are some quirks in the data. First, not all of
the fields in Table 6 in the Eagle Configuration Guide
V4.0 are in each record. In particular, USER and AUTH
appear infrequently (only 98 of 1658 records had them),
and there are some blank values for OP(10), PROTO(59),
RESULT(124), and SRCIF(7).
Most records end with the two fields RESULT and PROTO and
the six numeric fields:
result="200 OK" proto=http.0.0.0.0.0.0.
but some records instead have a date value following the
result= field, and there is no proto= field:
result="200 OK" 05/18/1998.0.0.0.0.0.0. 320
ZONE 2767767323332442233233233330303030303030
NUMR 02535C4D22000FB2005F18F19989090909090909
and some records seem to have trashed the second quote:
280 result="200 Docume05/18/1998.0.0.0.0.0.0. 320
ZONE 76776732333246676633233233330303030303030
NUMR 2535C4D220004F35D505F18F19989090909090909
MXG has additional logic to handle these anomalies.
These values for RESULT have been found in data. Note
the real joy of UNIX programmers who have five different
case sensitive spellings for RESULT 304 and conflicting
meanings for RESULT 200 and other RESULT values!
RESULT value Count
blank or incomplete double-quote 124
"200 Document follows" 36
"200 File data follows" 2
"200 OK" 881
"204 No content" 28
"302 Found" 4
"302 Moved Temporarily" 12
"302 Object Moved" 3
"302 Object moved" 5
"302 Redirection, oh yay" 1
"304 File Has Not Been Modifed" 8
"304 NM" 40
"304 Not Modified" 183
"304 Not modified" 2
"304 Use local copy" 186
"403 Forbidden" 3
"404 File not found" 3
"404 Hostname lookup failure" 5
"404 Not Found" 2
"404 Not found" 3
"404 Object Not Found" 6
"500 Internal Server Error" 2
"500 Unable to connect to remote 6
"Not HTTP/1.0 response" 113
Thanks to Brian Harvey, Navistar International, USA.
Change 16.101 Support for TME 10 NetView for OS/390 V1 R1 SMF type 38
EXTY3801 record creates these new datasets:
EXTY3802 TYPE3801 Command Authorization Table subtype 1
EXTY3803 TYPE3802 Task Resource Utilization Data subtype 2
IMAC38 TYPE3803 Span Authorization Table subtype 3
VMAC38 but only the TYPE3802 has been tested with data. The
Jun 1, 1998 NAME column is missing in tables 45-50 for subtype 3 in
Jul 16, 1998 IBM's "Application Programmers Guide" SC31-8223-01, but
IBM provided the DSECT so MXG variable names match!
In addition, this product is NOT Year 2000 Compliant,
as the date fields in the subtype 1 and 3 are in the
MM/DD/YY HH:MM:SS format! As usual, however, MXG will
protect the YY using the 1959 windowing technique.
Note that many of the raw data fields contained units of
KB per minute, but they have been converted to bytes per
second and formatted with MGBYTES format so they will
print rates in bytes, KB, MB, etc, per second, to be more
consistent with the rest of MXG than this narrow world
that measures per minute. Also, I/O rates were converted
to rates per second versus per minute, and all rates have
"per sec" in the label to make it clear.
Thanks to Leo Meyer, Humana, Inc, USA.
Change 16.100 The NON-FATAL STRUCTURE MISMATCH message that I thought
VMAC74 I had eliminated in Change 16.032 can still show up. The
May 27, 1998 tests R744SFLG EQ '00......'B and R744SFLG NE '00......'B
was added because that value was observed in data, but
those tests must be changed to
R744SFLG EQ '0.......'B and R744SFLG NE '0.......'B
because when the structure is not online (EQ 0) there
never will be a match, so there is no message to print.
Only if there is a mismatch AND the structure was online
at the end of interval, will the message now print.
Thanks to Gary L. Beers, Boeing Information & Support Services, USA.
Change 16.099 Support for MQ Series Version 1 Release 2 (INCOMPATIBLE,
VMAC115 but only for dataset MQMLOG, Log Manager Statistics,
May 26, 1998 which will have missing values for all of the QJSTxxxx
variables without this change). New variable QJSTLLCP
was added to dataset MQMLOG by the new version.
There were no changes to the type 116 SMF record in 1.2.
Note that previous MQM Version numbers were 1.2 and 1.4,
but those were really 1.1.2 and 1.1.4 and this new one,
Version 1 Release 2, is really MQ Series 1.2.0.
Thanks to ???, ???, ???.
Change 16.098 ANALSRVC reports CPU Percentage by Service Class for Goal
ANALSRVC Mode from TYPE72GO (like ANALPGNS for Performance Groups
May 21, 1998 in Compatibility Mode from TYPE72). Two percentages are
calculated:
SVPCTCAP - Pct of total Interval Capacity (NRCPUS*DURATM)
SVPCTUSE - Pct of total CPU Used (CPUACTIV during Intvrl)
For example, a SRVCLASS that recorded 1 hour of CPU time
in a 1 hour interval on a 2-engine CEC that was 75% busy
(TYPE70 was 1.5 hours) would have its SVPCTCAP= 50% and
SVPCTUSE= 66.6%. This report was incomplete in MXG 14.14
so Glen cleaned it up so it actually works!
Thanks to Glenn Bowman, Wakefern Food Corporation, USA
Change 16.097 Support for Landmark's Monitor for DB2 Version 3.1 is
VMACTMDB INCOMPATIBLE (i.e., you must have this update to read
May 21, 1998 the 3.1 records) because fields were inserted in their
Jun 1, 1998 records. New variables were added to these datasets:
TMDBDA2 - 26 TMDBDAB - 18 TMDBDAF - 1
TMDBDB2 - 19 TMDBDBB - 1 TMDBDBR - 1
The headers are now decoded for all records, but there
are additional data in some record segments (notably
the BB-BL family, and the DC, DE, DD, and DF) that are
not decoded until someone wants to use that detail data.
Jun 1: INPUT for DABGLCK comment line was shortened.
Thanks to Robin Tremblay, Regie des Rentes du Quebec, CANADA.
Change 16.096 The Structure Type Identifier, variable R744STYP is now
VMAC74 formatted with $MG074TT format:
May 19, 1998 '01'X='01X:UNSERIALIZED LIST STRUCTURE'
'02'X='02X:SERIALIZED LIST STRUCTURE'
'03'X='03X:LOCK STRUCTURE'
'04'X='04X:CACHE STRUCTURE'
and IBM has agreed to update the SMF manual to document
the values for that field.
Thanks to Yanara Perez, UPS, USA.
Change 16.095 The TYPE74 variable IORATE has been calculated by divide
VMAC74 of SSCHSAMP (SMF74MEC) by DURATM. SSCHSAMP is the number
May 15, 1998 of SSCH instructions for which pending, connect, and
actives were stored, and is returned by the hardware to
RMF. But IBM uses SIO74CNT (SS74SSC), which is the
number of requests to the device and it includes SSCH and
RSSCH instructions, to calculate IORATE in RMF reports.
I have changed to use SIO74CNT in the numerator of IORATE
not only to match IBM, but because this will provide the
IORATE even if SSCHSAMP is zero (which Diane discovered
and is investigating with IBM and her hardware vendor).
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 16.094 The test IF &LOMONTH LE ZDATE LE HIMONTH; must be changed
BLDNTPDB to read IF "&LOMONTH"D LE ZDATE LE "&HIMONTH"D; to avoid
May 15, 1998 a 73-222 error when BLDMNTH=YES (the default) is used.
This member is undergoing revisions and enhancements,
and a new option FIRSTRUN= has been implemented to init
initialize the PDB, daily, weekly, etc., libraries.
but this will not be completed in time for MXG 16.02.
Thanks to Bob Gauthier, American Stores, USA.
Change 16.093 The test IF LENGTH EQ 1464 THEN DO; in the Interval CICS
TYPEMON8 record is now IF LENGTH-COL+1 GE 212, because the fields
May 15, 1998 starting with TIAPREQ are present but were not input (so
they had missing values in dataset MONISYST) in records
of different lengths.
Thanks to ???, ???, GERMANY.
Change 16.092 CICS Statistics (type 110 subtype 2) dataset CICDS has
VMAC110 four divides by 5096 should have been divide by 4096.
May 15, 1998 The four variables for the fifth TCB, DS5TWT, DS5TDD,
DS5TCT and DS5ACT would have been about 20% smaller than
they really were. DS5ACT is a included in CPUTCBTM, so
it too was a little bit low. Fortunately, although there
are now six TCBs in a CICS region, almost all of the CICS
CPU time is still in the first TCB (762 second out of 765
seconds, for example), so the impact of this error in the
fifth TCB is minimal on this CICS statistics dataset.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 16.091 Landmark TMON for CICS V2 Converted Records do not set
TYPEMON8 TAFLAG6 bits to "Detail" (because V2 no longer has the
May 14, 1998 History or Summary records - all V2 records are "D"),
but MXG sets MONIRECD=' ' and then tests TAFLAG6 to set
MONIRECD to D,S, or H. But with no bits set in V2,
MONIRECD remained blank. The correction is to initialize
MONIRECD='D' instead of MONIRECD=' ' so that the V2
records will always be "D" and older version's with
TAFLAG6 bits will set the "S" or "H" if appropriate.
Only if you have added logic using MONIRECD that expects
the 'D' will this problem cause you an error (but this
site had IF MONIRECD='D' THEN OUTPUT MONITASK; in their
EXMONTSK exit, to discard the old History/Summary data,
so they had zero observations in MONITASK dataset due to
the blank value in MONIRECD in V2 records!
Thanks to Tim Downs, CSC TMG Warren, USA.
Change 16.090 Four additional fields were added to the type 42 st 14
VMAC42 ADSM SMF record that are now output as MXG variables
May 14, 1998 in dataset TYPE42AD:
SMSBYTCS='SPACE-MANAGED*DB OBJ BYTES*SENT CL-SRV'
SMSBYTRE='SPACE-MANAGED*DB OBJ BYTES*RETRIEVED'
SMSOBJIN='SPACE-MANAGED*DB OBJECTS*INSERTED'
SMSOBJRE='SPACE-MANAGED*DB OBJECTS*RETRIEVED'
and the conversion of kilo-bytes to bytes now uses the
factor of 1024 instead of 1000.
Thanks to David Ehresman, University of Louisville, USA.
Change 16.089 Zero observations occurred, apparently because the INPUT
TYPEVLFC of RESTOFIT $CHAR80. needs to be RESTOFIT $CHAR72.
May 13, 1998 The actual change was more extensive, calculating LENLEFT
in the record and INPUTting with $VARYING72.
Thanks to Martin Lee, Safeway, UK.
Change 16.088 Magstar drives have 0E8x for both DENX and TRTCH, but
VMACTMS5 MXG failed to decode those values, causing variable DEN
May 13, 1998 to be missing, and DEN is used to create observations in
DSNBRECD records, so datasets were not reported, and DEN
is also used to estimate the number of feet of tape).
This fix sets DEN=99000 for MAGSTAR so that observations
will be created, but a better density estimate may be
needed if length of tape is important. However, with
compressed data on tape, the ability to measure the feet
used is non-existent, since CA-1 provides only the
uncompressed size.
Thanks to Trevor Holland, Telstra, AUSTRALIA.
Change 16.087 The &MAC50 statement was misspelled as &MAC40 in MXG
VMAC50 15.15, but has now been corrected to &MAC50.
May 11, 1998
Thanks to Bill Shanks, BRBS Sema Group, UK.
Change 16.086 The UDKSCONT utility reads the output of PC DIR commands
UDSKCONT to measure PC filespace and estimate PC diskspace needed
May 9, 1998 (considering FAT cluster waste per file), but the MXG
algorithms (which assume the space in the last cluster
is lost) are not exact. My C: drive has 1546MB capacity,
129MB free and 1413MB in use, according to Properties.
Issuing these five DIR commands:
DIR *.* /S >> DISKFARM
DIR *.* /S /AH >> DISKFARM
DIR *.* /S /AR >> DISKFARM
DIR *.* /S /AS >> DISKFARM
DIR *.* /S /AA >> DISKFARM
to get Hidden/Read-only/System files/Archive files.
Change 16.085 The new support for Mobius InfoPac RDS View Direct 6.1
VMACIPAC in change 16.052 was validated, and minor changes were
May 8, 1998 made to deal with the changed records: subtype 1 and 2
are same length but 2-byte century field was added at the
beginning and a 2-byte filler at the end was deleted; the
subtype 3 and 4 was increased by 4-bytes, and the revised
code has been tested with both 5.2 and 6.1 releases.
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 16.084 The new calculation of RESPSTD should have used RESPAVG
TRND72 instead of AVGELPTM.
May 8, 1998
Change 16.083 The new OS/390 R2.5 Job queueing durations in TYPE72GO
VMAC7072 variables R723CQDT, R723CADT, R723CCVT, and R723CIQT were
May 8, 1998 incorrectly multiplied by 128 when they should have been
multiplied by 1024. They are in 1024 microsecond units,
but I carried down the 128 from R723CIOT, which is in 128
microsecond units. Also, R723CQDT was incorrectly
spelled as R723CDQT, but now matches the DSECT name.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 16.082 This ABEND report uses PDB.STEPS (because programs ABEND,
ANALABND jobs don't) to produce a report similar to the example in
May 8, 1998 Table 27.5 in the MXG Guide (see member ACHAP27). This
report tabulates ABENDs by Group, where you define the
groupings by EDITing the PROC FORMAT statements. In this
example, the variable JOBCLASS is used to define groups,
but any variable in PDB.STEPS (including ACCOUNT1, JOB,
etc.) could be used to group the tabulation.
This is also a good example of how to build table lookups
with PROC FORMAT and report with PROC TABULATE.
Thanks to Kevin Clark, Amtrak, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.081 The JCL parameter TAILORNG in the MXGSAS JCL Procedure
MXGSAS causes a JCL error with JES 3.1.3, because the symbol is
May 8, 1998 more than seven characters, so it has been changed to
TAILOR to avoid the error. However, one other site had
to remove both references to the TAILOR parameter to
eliminate a strange SAS 180 error, after the SAS
Initialization but before the MXG initialization
messages, that was followed by another SAS message that
the USERID.SOURCLIB was not a PDS when it most definitely
was. TAILOR is an MXG optional JCL parameter that is not
explicitly used anywhere in MXG and can be removed
without causing a problem.
Thanks to Tom Marchant, Wayne State University, USA.
Change 16.080 Multiple purge records can be created for JES3 jobs,
BUILDPD3 but MXG logic in BUILDPD3/BUIL3005 did not expect more
BUIL3005 than one purge record. These JES3 purge records are
May 7, 1998 identical with same READTIME, JOB, and JESNR values, and
only these variables are different in the three records:
JFINTIME JPURTIME ENTERDJ LEFTDJ TYPETASK SPOOLREC
. 04:46:29 Y STC 780
07:53:00 07:53:00 Y JOB 468
07:53:48 07:53:48 Y JOB 468
Most triplets had STC in the first record, JOB in the
second and third record, and came from started tasks that
had run for a week, were taken down, apparently had their
SYSOUT "dumped" and later had it "entered". There were
also pairs of purge records with TYPETASK='TSU' followed
by TYPETASK='JOB', and there were many pairs with both
first and second records containing TYPETASK='JOB'. It
looks like when JES3 "enters" the SYSOUT, it uses the
same JOB and JESNR, but sets TYPETASK='JOB' in those
subsequent purge records, even when the original "job"
was a STC or a TSO USer.
In all cases of multiple JES3 purge records, the first
record had LEFTDJ='Y', indicating the job left the system
by way of DJ (dump job), and the subsequent records have
ENTERDJ='Y', indicating the job entered the system by way
of DJ, so perhaps if you never use JES3 DJ, you never had
a problem. (There were purge records with LEFTDJ='Y'
and/or ENTERDJ='Y' that did not have multiple records,
but I only looked at part of a day's data.)
The problem with these multiple purge records is that
they cause multiple observations to be built in the
PDB.JOBS dataset, so I had to add logic to ensure that
only one purge record, the first one (i.e. earliest
JPURTIME) will be used to create PDB.JOBS, and the other
purge records create a new dataset DJPURGE for further
investigation.
The actual change was
-add DJPURGE to the DATA statement that creates
TYPE26J3 from SETS TYPE26J3 and SPIN26,
-after the END; statement, insert:
IF FIRST.JESNR THEN OUTPUT TYPE26J3;
ELSE OUTPUT DJPURGE;
Thanks to Brian Harvey, Navistar, USA.
Change 16.079 New format MGDECSR had extra quotes which caused a SAS
FORMATS "WARNING: At least one string was over 98 characters long
May 6, 1998 and had special characters and had to be truncated to
98 characters" that was overlooked (perhaps because that
warning did not set a condition code - I am now revising
the MXG QA stream to automatically detect any warnings in
the PROC FORMAT step, even if it set no condition code.
(SAS does not always set a condition code for a WARNING).
Thanks to Scott Wiig, US Bank, USA.
Change 16.078 All variables with format MGBYTES are now stored in 8
DOC bytes rather than 4 bytes. There were 2051 variables
May 6, 1998 in 332 MXG-built SAS datasets with that format, but by
searching all members of MXG for MGBYTES, there were
only about 220 that had to be scanned and only 105 that
were actually changed. Typically, the lines of the
FORMAT statement were copied into the LENGTH statement
and set to length 8. It is the DEFAULT=4 operand in
the LENGTH statement that sets the stored length. Some
report members that had no length statement did not have
to be changed, and code that only used MGBYTES in a PUT
statement in a DATA step were not changed, because all
SAS numeric variables are length 8 during the data step
that creates them; it is only when output to DASD that
the variable is truncated into four floating point bytes.
See MXG Technical Note on this subject.
Change 16.077 -Under SAS V7, when you create an output dataset using
VMXGSUM the PROC CONTENTS OUT= operand, the lengths of some of
May 5, 1998 the created variables are changed. In particular, NAME
Sep 9, 1998 will be 32 bytes long in the V7 output dataset, whereas
NAME was only 8 bytes long in the V6 output dataset. In
VMXGSUM, we create a list of names in your arguments as
length 8, but when we merge that list with the output of
PROC CONTENTS (to verify the variables you listed are
actually there to summarize), SAS V7 raised a warning
message. This change forces the length of NAME to 8 s
bytes, but was not actually made until Sep 9, 1998.
Change 16.076 -Using the new ASUMTALO summarization with a version of
ASUMTALO MXGTMNT/ASMTAPES earlier than MXG 14.01 (ML-10, which
May 5, 1998 was the first version that created the End-of-Interval
allocation records) created zero observations in ASUMTALO
because the new logic did not validate that there were
any interval records to use. Now the logic only uses
interval records when they are found in your SMF records,
so ASUMTALO observations will always be created now.
-The LENGTH of variable DEVICE defaulted to 8 if there was
no SPIN.SPINTALO (i.e., for the initial run of ASUMTALO),
but the length of DEVICE in TYPETALO is 7. Under SAS V7
this raised a WARNING message about unmatched lengths
of character variables when the new and old datasets are
interleaved, so now DEVICE is set to length 7 to avoid
the warning and its associated return code of four.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.075 -DB2 variables CLASS3WT and CLASS3TM (DB2 Class 3 wait
ANALUOW counts and wait durations) are added to ASUMUOW and
ASUMCICS TRNDUOW datasets. These are the sum for all of the
ASUMUOW twenty individual class 3 wait buckets, for a high
TRNDCICS level view of DB2 waits in the ASUMUOW dataset.
TRNDUOW -The new wait variables added by CICS TS 1.2 (see text
May 5, 1998 of change 15.274) are included in the ASUMUOW and the
TRNDUOW datasets.
-CICS variables SSQELAP, RESPSTD and MAXRESP are now
created in TRNDUOW.
-ANALUOW analysis reports now have MAXRESP on report 2 and
both MAXRESP and RESPSTD on report 3 to show how tightly
clustered response times are. New option PLOTIT= sets
the number of minutes between tickmarks on the X axis for
plots of response time versus time of day (and uses the
specified STARTIME= and ENDTIME= values on the x axis).
If PLOTIT is not specified, no plot is produced. If both
PLOTIT= and GRAFOUT are specified and you have SAS/GRAPH,
a graphics catalog named ANALUOW will be built in the DD
pointed to by GRAFOUT.
-Variables SSQELAP and RESPSTD were added to ASUMCICS and
TRNDCICS output datasets.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.074 Change 15.320 replaced hardcoded PDB DDname references
ANALBLSR with &PDBMXG macro variables to externalize the DDname,
VMACFRYE but these members had wrong syntax. In ANALBLSR &PDBMXG
XDB2LOCK was changed back to &PDB because the usage was inside a
XNALCACH %MACRO with a PDB= operand, while VMACFRYE had PDBMXG
ZGRAFRMF changed to &PDBMXG; the other three disused members were
May 5, 1998 corrected for consistency but are not actively used.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.073 INVALID DATA FOR TMMDMODL message is printed because the
TYPEMON8 INPUT TMMDMODL &NUM.2. should be TMMDMODL ?? &NUM.2.
May 5, 1998 Add the ?? modifier to suppress printing of the message
and hex dump when invalid data is attempted to be INPUT.
MXG's logic to detect whether this Landmark record has YY
or YYYY dates knows that TMMDMODL will be invalid (and
hence set to missing value) for the non-Y2K compliant
records, and so it rereads TMMDMODL as &PIB.2. when
TMMDMODL is missing, and so the datasets built by
TYPEMON8 were just fine. I just forgot to add the ??
modifier to eliminate the unnecessary print messages.
Thanks to Diane DePasquale, CSC TMG Warren, USA.
Change 16.072 Old variables FSPCBTRP FSPCBTRT FSPCCOLP and FSPCCOLT in
VMACICE dataset ICEBRGSY are renamed to FSBYxxxx because the FSPC
May 5, 1998 prefix is was intended for percentages, not storage size,
and FSPCCOLP and FSPCCOLT already existed in ICEBRGUT,
and their label and format was overlaying the ICEBRGSY
variables. The FSBYxxxx variables are formatted MGBYTES.
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 16.071 This new program merges VSAM type 62 and 64 SMF records
ANAL6264 to add OPENTIME to each CLOSE record. Dataset VSAMOPEN
May 4, 1998 has an observation for each open from each job for each
VSAM ENTRNAME.
The ENTRNAME in the OPEN record will end with blanks,
'CLUSTER', 'CL', or 'BASE', but its corresponding CLOSE
records for that open end will end with blanks, 'DATA',
'DT', 'INDEX', or 'IX'. MXG strips the "last" part of the
ENTRNAME, merging on the stripped name, and stores the
"last" part in variable LAST.
For CLOSE (64s) without an OPEN, the OPENTIME is set to
the minimum SMF time of the 62/64s on that system, and
for OPEN (62s) without a matching CLOSE, their SMFTIME is
set to the maximum SMF time found. Variable OPENTM is
created only for a match-up. Close-without-open will
have OPENTM=. and ID=64, while open-without-close will
have OPENTM=. and ID=62 in the VSAMOPEN dataset.
There are often four close records for each open; I guess
the Data and Index are closed, and then when the Cluster
is closed, there is a second pair for the Data and Index.
This is work in progress, and the efficiency of the merge
will be enhanced. One consideration is using the output
dataset to measure availability of VSAM production
datasets, so there will likely be revisions to ANAL6264.
Thanks to Rachel Quiroz Holt, Fidelity Systems, USA.
Change 16.070 New utility likely to be needed only by me. UTILBHEX will
UTILBHEX build a file of readable SMF records from an email of the
May 4, 1998 SYSOUT print file of the SAS log that contains the hex
dump of SMF record(s) that were printed by the "LIST"
statement, or were printed when "INPUT STATEMENT EXCEEDED
RECORD" errors occur. That automatic hex dump on the SAS
log has been invaluable in resolving errors, incompatible
records and new product validation, and I still rely on
the dump, but debugging a problem in CICS type 110 SMF
records with excluded fields plus optional segments was
made much easier by writing this utility to create the
record and then enabling the debugging logic in MXG code.
While member SENDDATA provides instructions by which you
can re-read the SMF data and create an SMF file on MVS to
then be downloaded, zipped, and emailed, now, if you have
an error and I need to see the record, you can simply
save the SYSOUT as a file on MVS, download it and zip it
on your PC, and then email it to me for diagnosis. Also,
member SENDDUMP shows how to produce a hex dump of select
SMF records, and now its output can also be converted to
readable records by this utility.
Change 16.069 IMS log processing datasets now have _L, _K macros for
IMACIMS the additional datasets created by JCLIMSLG's TYPEIMSA,
VMACIMSA so you can control the contents of all IMS log datasets.
Apr 30, 1998 New exit members EXIMSTRN, EXIMSBMP, EXIMSUNM, EXIMSMRG
EXIMS07I, EXIMSFAS, and EXIMS598 (and similarly named
_L and _K macros) exist for the IMSTRAN, BMPS, UNMATCHED,
IMSMERGE, IMS07, IMSFASTP, and IMS5938 datasets.
Change 16.068 Macro variables &PCICTRN, &PDB2ACC, &PIMFTRN and &PIMSTRN
VMXGINIT created and GLOBALed to continue the externalization of
Apr 30, 1998 DDnames for datasets created by BUILDPDB. I have decided
Jun 25, 1998 on the naming conventions for dataset LIBNAME macros:
Exit Member Name Dataset Name Dataset &Macro
EXTYxxxx TYPExxxx &PDBxxxx
EXdddddd All others &Pdddddd
All VMACs that process SMF records will have their
&PDBxxxx or &Pdddddd "Dataset &Macro" defined and set
with a %LET in VMXGINIT member. All resolve to "PDB" by
default, except for the CICSTRAN and DB2ACCT (high
volume) datasets that are not sorted by MXG's BUILDPDB.
See Change 15.320 for further discussion.
Change 16.067 Candle's Omegamon Version V400 for CICS/ESA 4.1 and
IMACICDA CICS TS 1.2 have two new optional segments added to their
IMACICOC type 110 record, CANMQ with MQ Series counts and duration
IMACICOM and CANWLMSC with WLM Service Class names. These new
IMACICOW segments are now supported in new members IMACICOM and
VMAC110 IMACICOW respectively, and member IMACICDA was updated to
Apr 30, 1998 add their include in the default order (MQ before WLMSC),
and the new variables were added to the KEEP= list in the
VMAC110 member (but no new variables are created unless
you remove the comment block in IMACICOM or IMACICOW).
As always, you need to run UTILCICS to find out which of
the segments exist and in what order in each region, and
and might have to update IMACICDA if UTILCICS shows the
order is different in your records than MXG expects.
Since I now have the DSECTS, I found that there are two
bytes of flags in the OMEGBSC segment that are now two
variables, OMDBWRN (DB Warnings) and OMGENWRN (General
warnings) added to CICSTRAN if you enable IMACICOC.
Thanks to Melanie Floyd, UPS, USA.
Thanks to Jon Taf, UPS, USA.
Thanks to Dennis Hancock, UPS, USA.
Change 16.066 The MXG CONFIG option SASAUTOS=(SOURCLIB SASAUTOS) is now
CONFIG used so that sites that have their own macro libraries in
Apr 28, 1998 their SASAUTOS collection can be found under MXG.
The earlier option was just SASAUTOS=SOURCLIB, which
prevented you from finding your macros in your SASAUTOS.
(Many sites concatenated their macro libraries and/or
the SAS.MACRO library to their //SOURCLIB DD.)
Thanks to Alfred Mueller, ABN - Amro, USA.
Change 16.065 The NPM format MG028VA decoded an undocumented '0A'x
FORMATS value. IBM has confirmed the '10'x documented for the
Apr 28, 1998 LVMATYP field should be '0A'X, so FORMATS now contains:
10='0AX:PCT TIME IN BLOCKED RATE' instead of
16='10X:PCT TIME IN BLOCKED RATE'.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 16.064 In dataset TYPE72GO, variable RESPAVG is kept and EXETTM
VMAC7072 is created and kept. RESPAVG is equal to AVGELPTM, but
Apr 28, 1998 keeping RESPAVG, which was the name in TYPE72, will help
Aug 14, 2001 sites migrating to Goal Mode. The Total Transact
Execution time, R723CXET, is now kept in new variable
EXETTM. Previously, only the average value AVGXETTM was
kept in TYPE72GO, and it was calculated only if TRANSEXC
was non-zero (because I thought EXETTTM was updated only
when TRANSEXC - when a transaction in execution phase had
ended). But Brenda found non-zero EXETTM with zero count
in TRANSEXC, and Don Deese's current paper confirms that
EXETTM is non-zero for batch service classes, even though
TRANSEXC is always zero for batch. So now, not only is
EXETTM a kept variable, but also AVGXETTM is calculated
as EXETTM/TRANSEXC if there were subsystem transactions
terminating, or else AVGXETTM=ELAPSTM/TRANS if there were
no TRANSEXC but TRANS was non-zero.
For non subsystem transaction service classes (like batch
and TSO), variable EXETTM now measures in Goal Mode what
was measured in ELAPSTM in Compatibility Mode.
In debugging my change, (examining the missing value
notes on the log), I found a line with PCTUSNDI that
did no harm but is now deleted, and I discovered that
replacing:
SUMPTRAN=SUMPTRAN+RTSTRN(M); /*ADDING*/
with
SUMPTRAN=SUM(SUMPTRAN,RTSTRN(M)); /*SUM FUNCTION*/
not only eliminated the missing value notes on the
log, but also saved CPU time! While SUMPTRAN (the
accumulated transaction count as I loop across the
thirteen response count buckets) was always set to
zero before the loop, if a service class had no
response buckets, RTSTRN(M) was missing, and the loop
ran thru all thirteen buckets, because the ADDING zero
to missing is still missing. Instead, using the SUM
function, zero plus missing is zero, so the test that
follows (IF SUMPTRAN GE NRPTRANS) is now satisfied on
the first iteration, so we bail out of the loop,
instead of DOing it thirteen times!
Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Thanks to Carole Storby, LMCO, USA.
Change 16.063 Support for OS/400 Version 4.2.0 (COMPATIBLE).
VMACQAPM -New QAPMCONF configuration GKEY values of 'CI' and 'SJ'.
Apr 27, 1998 -New QAPMJOBS variables JBTCPU,JBTHDF,JBTHID,JBTHAC,
JBTHCT,JBMTXT, and JBSTSF were added. The QAPMJOBS file
is now LRECL=812 vice 617.
-The +52 after JBSJFG was changed to +58. This change
corrects 4.1.0 variables after JBSJFG.
-New QAPMDISK variables DSBGDR,DSBGDW,DSBGS,DSCOMP,
DSFGDR,DSFGDW,DSFGRE,DSFGS,DSFGWE,DSLBA,DSLBW,DSPBA,
DSPBCO and DSPBU were added. The QAPMDISK file is now
LRECL=346 vice 267. The variable PCTIOPBY seems to be
invalid, as the DSIDLC field contains very large values.
This needs to be examined further, and will be updated
if I learn more.
-New QAPMECL variable EMDUP was added.
-New QAPMETH variable ETMDUP was added.
-New variable XIADRN was added to QAOMIOP1-4 datasets.
Except for possible LRECL changes in your JCL, the 4.2
records were compatibly changed.
Thanks to Clark Jennings, Reynolds Metal, USA.
Thanks to Stuart Burnett, Reynolds Metal, USA.
Change 16.062 This revision to the RMF III VSAM assembly program adds
ASMRMFV support for the CSR, the Common Storage Remaining data
May 10, 1998 segments. This level 002 of ASMRMFV has been tested, but
I have not yet updated the TYPERMFV code for the CSR.
Change 16.061 The UTILCICS output listed UN98309 for any region, but
UTILCICS that APAR only applied to CICS 4.1; the fields added by
Apr 27, 1998 that APAR are in CICS TS by default, so the test to set
PTF='UN97309' now also tests SMFPSRVR=41.0. This CICS
dictionary-reading utility also now knows about the new
CANMQ and CANWLMSC sections and sets the ERRMQ=64 error
if CANMQ segments of only 64 bytes are found. The early
Candle documentation showed 64 bytes, but the correct
length is 76; if you get ERRMQ=64, then your CICS guru
needs to correct the MCT length for CANMQ to be 76 bytes.
Thanks to Melanie Floyd, UPS, USA.
Thanks to Jon W. Taff, UPS, USA.
Change 16.060 Sterling's Connect Direct (formerly NDM) subtype "PT"
VMACNDM process termination data is trashed; timestamp variables
Apr 27, 1998 NDMSUBTM and NDMSKDTM get INVALID VALUES messages, and
other PT variables are also wrong. Sterling has an open
problem report, item PI-754129, but no fix yet, but now
called Sterling CASE 7916. In 1994 there was a similar
error in "PT" in Change 11.326, but this time I found
Sterling Tech Support and received same-day service!.
But there was also an MXG error, as the INPUT for the PT
segment was off by two bytes, and there was a new
variable, NDMSEQ, added at the end that was overlooked.
Also, to prevent those INVALID VALUE messages before you
get a fix from Sterling, I inserted the ?? modifier for
each packed PT field. The MXG fix to the PT input:
change LOC=LENGTH-21; to LOC=LENGTH-23;.
Thanks to Brian Crow, BT, ENGLAND.
Change 16.059 -Variable NWMSINRT was not kept in dataset MSEXCHIS due to
VMACDECS mispelling as NWMSINRJ in the KEEP=list.
VMACNTSM -Repeats of six variables in KEEP= list in VMACDECS were
Apr 27, 1998 removed, though they caused no problem.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 16.058 Changes made in MXG 15.15 caused ASMIMSL5 to fail during
ASMIMSL5 assembly were corrected and the revised member was tested
Apr 27, 1998 with IMS 5.1 log records without error.
Thanks to George Ellard, FEDEX, USA.
Change 16.057 -The label for variable OMVSOPR in dataset TYPE30OM built
VMAC74 by BUILDPDB was wrong, because dataset TYPE74OM also has
VMAC78 a variable OMVSOPR, and the 74's label replced the 30's.
Apr 27, 1998 To resolve the conflict, the type 74 variable OMVSOPR was
renamed to OMVSOPRP to protect the TYPE30OM variable,
which could cause VARIABLE OMVSOPR NOT FOUND, but only if
you use the TYPE74OM data set AND explicitly referred to
OMVSOPR in your SAS report code.
-The label for variable SYSNAME in member VMAC78 was used
for all BUILDPDB datasets, but it had a typo. The
correct spelling is IEASYSXX and not IESAYSXX.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 16.056 Comments and INVOKEBY= were changed to ASUMCICX in this
ASUMCICX optional replacement for ASUMCICS (see Change 15.205).
Apr 25, 1998
Thanks to Jim Ray, Branch Banking and Trust, USA.
Change 16.055 Archaic FMXGUCBL failed under SAS 6.09, but re-assembly
FMXGUCBL of the member with the SETSSI AF010000 (as mentioned in
Apr 25, 1998 Change 12.015), eliminated the 0C4, and by changing
TXTUC15 DC X'0015',X'0001',X'0003' CODE 15 - UNIT ADDRESS
to increase its length from three to five bytes:
TXTUC15 DC X'0015',X'0001',X'0005' CODE 15 - UNIT ADDRESS
eliminated the DYNAMIC ALLOCATION FAILURE FOR VOLUME xxxx
with REASON-021C error on each volume.
The SETSSI statement now sets AF010000 vice AF000000.
This member is archaic in that DCOLLECT is now the MXG
recommendation, and before that, ASMVTOCs had replaced
the very old FMXGUCBL. However, it still works and
fixing it with a re-assembly was easier than re-writing
the existing reports to use ASMVTOC or DCOLLECT!
Thanks to Karl Schlichting, CSC New Zealand, NEW ZEALAND.
Change 16.054 Cosmetic. Now, if you try to use TYPETMO2 to read TMON
VMACTMO2 records that were converted to V 8.1 format, member
Apr 25, 1998 TYPETMO2 (which is for native V 2.0 unconverted format)
will tell you that you should be using member TYPETMO8.
Thanks to Diane DePasquale, CSC TMG Warren, USA.
======Changes thru 16.053 were in MXG 16.01 dated Apr 9, 1998======
Change 16.053 Minor errors corrected after first MXG 16.01 tapes:
ASUMPRTR ASUMPRTR now %INCLUDEs IMAC6 and IMAC7072 to protect the
TRND72 _LTY6 and _LTY72 macro names when ASUMPRTR is run as part
VMACIPAC of the MXG QAJOB. TRND72 had RESPSTD located after the
VMACTRSN the ending parenthesis, causing syntax error.
Apr 9, 1998 VMACIPAC syntax error. IF CC=. THEN IF .... changed to
IF CC=. AND IF .... in four lines.
VMACTRNS was deleted again; it was a misspelling that was
removed from 15.15 but crept back into the first 16.01.
======Changes thru 16.052 were in MXG 16.01 dated Apr 8, 1998======
Change 16.052 Another INCOMPATIBLE Year 2000 change, the RDS 6.1 SMF
VMACIPAC record inserted two bytes to change YY to YYYY in four of
Apr 8, 1998 their five subtypes. This change tests variable VERSION
to be NE 'V-1', but I have not been able to verify if the
record version is actually going to be useable to detect
the changed record format. At worst, you might have to
use a different SMF record number for the RDS 6.1 record,
and change the MXG test in VMACIPAC that reads IF VERSION
NE 'V-1' in four places to IF ID=nnn. V-1 is in current
version records, but is also shown in the Mobius copybook
for 6.1, so I don't know if they actually changed the
VERSION field or not. Look for an update to this change
text on our homepage once 6.1 records have been created.
View Direct 6.1 is the new name of RDS / IPAC product.
See revisions in Change 16.085.
Thanks to Clark Jennings, Reynolds Metal, USA.
Change 16.051 Variable RESPSTD, the standard deviation of the average
TRND72 response of ended SRM transactions, is now created in the
TRND72GO TRND72 and TRND72GO trending. The default MXG summary
Apr 8, 1998 level of PERFGRP or SRVCLASS can be changed to break out
each PERIOD, by simply adding variable PERIOD at the end
of the SUMBY= statement in those members, if you want to
see individual periods' data (so you can trend TSO period
one, for example). I cannot safely change my default to
a lower level without potentially destroying somebodys
reports, but you can change it for your site and then
add PERIOD to your reports.
Thanks to Chuck Hopf, MBNA, USA.
Change 16.050 PROC PRINT's that have multiple pages per BY group are
ANALCNCR messed up due to a SAS problem, a conflict between the
Apr 8, 1998 NOBYLINE parameter (which permits us to make reports
prettier) and the existence of an ID statement with the
same list of variables as the BY statement (and we used
BY &SUMBY; ID &SUMBY; to make the reports even prettier).
SAS Usage note V6-PRINT-6788 discusses the error, found
in SAS 6.07, but there will be no fix sooner than SAS
Version 7. So, while the reports are prettier still with
both the NOBYLINE parameter and the ID statement, I have
commented the two ID &SUMBY; statements, so you still get
pretty reports, but now they will print All report pages!
Thanks to Glenn Bowman, Wakefern Food Corporation, USA
Change 16.049 Landmark's TMON Version 2 records that are converted to
TYPEMON8 Version 8.1 format by TMON utility program TMONCNVT are
Apr 7, 1998 now Year 2000 compliant, but the change was INCOMPATIBLE
so you will need MXG 16.01 or later is you still convert
your new TMON records to the old format. Landmark also
replaced the TMMDCCLK field which was a series of packed
fields (0962821314185700 was 96282 13:14:18.57) with a
new value (B043AA3E81B0F701 now for April 6, 1998),
which causes INVALID DATA FOR D12 messages because D12 is
no longer a valid packed field, and since I have no clue
from Landmark documenting this change (I have only a dump
of the record causing that message), and since it is late
at night and I want to wrap up MXG 16.01 before I sleep,
variable TMMDCCLK will be a missing value in these new
Y2K-compliant-8.1-format records, and the INVALID DATA
message is eliminated. Fortunately, TMMDCCLK is an
internal datetimestamp that was not even kept by MXG.
Thanks to Tim Downs, WCI/CSC Warren Ohio, USA.
Thanks to Mike Cezarro, City of Rochester, USA.
Thanks to Kumar Thavakumar, City of Rochester, USA.
Change 16.048 -Support for NTSMF new Object SNA Logical Unit Sessions
EXNTMSES creates new SNALUSES dataset with the same variables as
EXNTSNAL in the SNA Connection Object (dataset SNACONN).
EXNTSNAR -Support for NTSMF new Object SNA 3270 Response Times
EXNTWIDE creates new SNARSPTM dataset with five response buckets
IMACNTSM R3270TH1-R3270TH5 with percentage of responses (whatever
VMACNTSM that is) in each bucket. However, the values are the
Apr 8, 1998 same for each SNACONNM value, so I believe these data
are still wrong in NTSMF 2.1.0 (which had to deal with
the people writing this object not following the rules
to write data correctly!).
-Support for new MS Exchange Event Services object
creates new MSEXCHES dataset.
-Support for the SNA Adapter SnaDlC1 (yep, that's a
lower case l, a upper case C and the numeral one!)
outputs to the existing SNAADAPT, but there is no
longer an SNAADAPT name field. I reused the same
dataset because there never were any NTSMF records
created with the original name field + counters.
-Support for the WideToMBErr object creates new dataset
WIDE2MBE.
-The _BNT macros needed these variables added to the BY
list for the dataset sorts: _BNTPROC has PID added,
_BNTNETI has INTRNAME added, and _BNTMSMC has CONNNAME
added.
Thanks to Jim Quigley, Con Ed, USA.
Change 16.047 Variable JCSPTOD in CICS Journal Segment was validated
VMAC110 for Shared Medical System's journal data, but only with
Apr 7, 1998 CICS Version 2 data. The CICS/ESA logic in VMAC110 still
had JCSPTOD ?? PDTIME4., which produced wrong values.
The logic from V2 journal was copied into the CICS/ESA
journal processing logic. This error impacts you
only if you were decoding your own journal segments.
Thanks to John Croasdale, Barclays Bank Group, UK.
Change 16.046 New ASUM member to summarize TYPE42DS (SMS Interval
ASUM42DS I/O activity) by dataset to report total I/O to each
Apr 6, 1998 dataset from all users, counting the number of users
using that dataset during each interval.
Thanks to Simone Niemczura, FISERV, USA.
Change 16.045 -Support for Internet Information Services Global Object
EXNTSMTP Version 4.0 in INCOMPATIBLE with Version 3.0; the two
EXNTWEBS counter objects Cache Size and Cache Used, MXG variables
IMACNTSM CACHSIZE and CACHUSED in dataset IISG, were removed by
VMACNTSM the new 4.0 version of IIS.
Apr 3, 1998 -Support for Active Server Pages object's nearly complete
restructure, with 14 fields kept from prior version,
with 19 new fields added, and these 10 fields deleted:
ASTHPOCU ASRQCURR ASRQERRT ASRQTOEX ASRQTONQ
ASCOMFAI ASMEMUSE ASMEMFRE ASRQBREX ASRQTOTQ
-Support for new FTP Service Object replaced the previous
FTP Server Object, but MXG outputs into the same FTPSERV
dataset that was built from the prior FTP Server Object.
The only difference between the old and new objects is
that the new FTP Service Object has an instance field,
new MXG variable FTPSERVR (name of the FTP Server), that
did not exist in the old FTP Server object.
-Support for new Web Service Object creates new WEBSERV
dataset; this new Web Service Object logically replaces
the previous HTTP Service object that created MXG HTTP
dataset, but as many HTTP fields no longer exist in the
new Web Service Object, and as there are many new fields,
the new WEBSERV dataset must be used in place of HTTP.
-Support for new SMTP Server Object creates new SMTPSERV
dataset.
Thanks to Leigh Ann Payne, Wachovia Operational Services, USA.
Change 16.044 The JCL example had //DB2ACCT DD pointing to the DB2ACCT
ANALDB2C dataset, but the default in IMACDB2 creates PDB.DB2ACCT,
Apr 2, 1998 so the example now has //PDB instead of //DB2ACCT.
The newer combination of ASUMUOW and ANALUOW are really
the better tools for matching CICS and DB2 transactions.
Thanks to Alfred Holtz, Merck Medco, USA.
Change 16.043 -ASUMIDMS was touched up. Variable TASTTYPE and TASKTYPE
ASUMIDMS now have their length set as $1 and @26 respectively, in
TESTUSER LENGTH statements instead of FORMAT statements. The
TRNDIDMS -TESTUSER was touched up. The hardcoded IDMSxxx dataset
Apr 2, 1998 names were replaced by the _LIDMxxx macro names.
Jan 19, 1999 -TRNDIDMS is a new contribution from Alan, based on the
TRNDCICS member of MXG, and provides IDMS trending.
-Updated Jan 19, 1999: In ASUMIDMS, the line that read
TSKTIMUS=TASTIMWT; was changed to TSKTIMUS=TASTIMUS;
Thanks to Alan Deepe, Perot Systems, ENGLAND.
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 16.042 Using TYPERACF to read the unloaded RACF database that is
VMACRACF created by IBM utility IRRDBU00, variable OMVSPROG was
Apr 2, 1998 not created in dataset RACF0270, but now it is, being
INPUT @1050 as a $CHAR200 variable.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 16.041 Change 15.320 inadvertently changed the PDB to PDBMXG in
UTILCONT two places and lost an &, so this new utility to print
Apr 2, 1998 the contents (in mega-bytes and obs) of SAS datasets in
a SAS Library fails. Change both PDBMXG to PDB, and
add the missing & to %LET PDB=%UPCASE(&PDB); .
Thanks to Rick Salazar, City of Long Beach, USA.
Change 16.040 Corrupted type 42 subtype 6 caused INPUT EXCEEDED error.
VMAC42 The record has SMF42PDL=DFSMSV1R and SMFPDN='DF TP' but
Apr 2, 1998 the rest of the product section is trash and the record
is longer than its triplets indicate is should be!
The INPUT EXCEEDED occurs because MXG did not validate
that the offset field in the PRODUCT section was less
than the record length. To detect and delete these
corrupted records, insert this circumvention:
IF OFFJDDS+LENJDDS GT LENGTH+1 THEN DELETE;
after the statement LOOP42:
The actual MXG change was more extensive, and will
produce a diagnostic message on the SAS log that the bad
record is being skipped.
Thanks to Melanie Floyd, United Parcel Service, USA.
Change 16.039 Year 2000 only. READTIME in TYPE6 will be 1900 for a job
VMAC6 read in year 2000. MXG's protection for CA-Dispatch's
Apr 2, 1998 corruption of the first byte of julian date was resetting
May 14, 1998 the century bit to zero. The statement in VMAC6 could
have been changed from
IF SUBSTR(READCADI,5,1) GT '00'X THEN
SUBSTR(READCADI,5,1)='00'X;
/*CA-DISPATCH CORRUPTION FIX*/
to
IF SUBSTR(READCADI,5,1) GT '01'X THEN
so both year 2000 and CA corrupt records can be processed
correctly. Following text revised May 14, 1998.
However, the actual change that I made was to remove the
protection for the CA corruption, since their current
versions must be installed for year 2000 anyhow, and the
MXG heuristic protection is just another opportunity for
a future error! This error would also have affected
BUILDPDB; the print records would not match the READTIME
of the other job records, so they will create separate
obs in PDB.JOBS with the 1900 date and only print
resources, while the real PDB.OBS with 2000 date will
have no print resources counted.
Thanks to Arzina Merali, Alberta Public Works, CANADA.
Thanks to Joe Zelyas, Alberta Public Works, CANADA.
Taught 3-day class in Dallas, Mar 30 - April 1, 1998.
Change 16.038 Cosmetic. Messages about INVALID SUBTYPE VALUES that
VMXGGETM seemed endless are now printed only for the first five
Mar 27, 1998 records in this utility used to create SMFSMALL file.
Thanks to Joe Zubras, Pennsylvania Hospital, USA.
Change 16.037 Cosmetic. Format $MG028ST was created by Change 13.072,
VMAC28 but was supposed to be used for variable LSCDSTYP, but
Mar 27, 1998 that was only accomplished now, with this change.
Change 16.036 Nine instances of "=F" must be changed to "@" in this
ANALMULT example report; different character translation tables
Mar 27, 1998 were used during transmission of this member.
Change 16.035 Year 2000 Support for AS/400 was incorrect. There are 44
VMACQAPM instances of IF YY GT 0 THEN ... that must be changed to
Mar 27, 1998 IF YY GE 0 THEN ....
and the four lines preceding GDES1=MDY(MO,DD,.... that
input variables YY MO DD and CC with informat &NUM.n.
need double-questionmarks between the variable and the
informat, eg., YY ?? &NUM.2.
Without this fix, the date variables in the year 2000
(only) will have 1960 dates (Because their value is zero
and the zero SAS date is 1960.
Thanks to Mike Wroot, SAS UK Customer Support, ENGLAND.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 16.034 Support for DECnet/SNA DTF SMF records creates nine new
EXDECS01 MXG datasets:
EXDECS03 Subtype Dataset Description
EXDECS04 01x *DECSSTAR DECNET/SNA ADDRESS SPACE START
EXDECS05 03x *DECSBEGN DECNET/SNA SESSION BEGIN
EXDECS06 04x *DECSEND DECNET/SNA SESSION END
EXDECS07 05x DECSDIR DECNET/SNA DIRECTORY REQUEST
EXDECS08 06x *DECSALOC DECNET/SNA FILE ALLOCATION
EXDECS09 07x DECSOPEN DECNET/SNA FILE OPEN
EXDECS0C 08x *DECSCLOS DECNET/SNA FILE CLOSE
EXDECS0d 09x *DECSERAS DECNET/SNA FILE DELETE
EXDECS0f 0Cx DECSREQB DECNET/SNA IBM REQUEST BEGIN
EXDECS10 0Dx DECSREQE DECNET/SNA IBM REQUEST END
FORMATS 0Fx DECSTERM DECNET/SNA ADDRESS SPACE TERMINATE
IMACDECS 10x DECSRCAL DECNET/SNA DATASET RECALL ON DIR
TYPEDECS The six datasets prefixed with '*' above have been
VMACDECS tested with data records.
Mar 26, 1998
Thanks to Brian Harvey, Navistar International Transportation, USA.
Change 16.033 IDMS 10.2 records were not output, so all seven lines
VMACIDMS with IF 'xxxx' LE SMFHVER LT '1400' THEN DO; were
Mar 25, 1998 changed to IF SMFHVER LT '1400' THEN DO;
Thanks to Ron Larue, FDISG Boston, USA.
Change 16.032 The MXG DISCOVERY. NO STRUCTURE MATCH. NON FATAL message
VMAC74 should no longer occur. The message was printed when a
Mar 25, 1998 structure in the Request Data Section was not found in
the Structure Data Section, and the only impact was that
variable R744QSIZ in TYPE74ST would be missing for that
structure name in that observation. But now, having
examined sample mismatches, I find that there is an entry
for the Structure in the Request Data Section, but there
is no corresponding entry in the Structure Data Section,
and the Request Data Section has R744SFLG='00000000'B, so
this structure neither was Online at End of Interval, nor
did it Become Active during the interval, but it had been
connected at the start of the interval, hence the Request
Data Section. But IBM explains that the Structure data
is a snapshot at interval end of all allocated structures
in the coupling facility (returned by IXCQUERY), and as
the structure was not allocated at interval end, there is
no structure data. This accounts for the mismatch, so
now, the mis-match message won't be printed when R744SFLG
is zero.
Thanks to Steve Smith, BGS, USA.
Change 16.031 CICS UNEXPECTED STATISTICS RECORD with STID=0 or = large
VMAC110 was caused by incorrect processing of STID=94 record. The
Mar 25, 1998 +11 after LGSAUTOP was INPUT must be +7. This also caused
zero observations in dataset CICLGS.
Thanks to Steve Smith, BGS, USA.
Change 16.030 Variable ABENDUSR in dataset CIMSPROG has never been
VMACCIMS right. The equation ABENDUSR=MOD(ABENDSYS,16)+ABENDUSR;
Mar 24, 1998 must be replaced with ABENDUSR=MOD(ABENDUSR,4096); and
ABENDUSR must be removed from the HEX4 format statement
as IMS User Abends range from 0 to 4095, not 0 to FFFx,
so they will now print as decimal by default.
Thanks to Karen Sherman, Franklin-Templeton, USA.
Thanks to Wayne Collins, Franklin-Templeton, USA.
Change 16.029 Variable R723CIMP (Importance Level) was in the SUM=
TRND72GO argument, making it meaningless in non-zero CPU Dispatch
Mar 24, 1998 times and non-zero Percent CPU Busy values.
Change 16.028 MXG 15.15-15.07 Only. For PR/SM Deactivated Partitions,
ASUM70PR observations were created that had non-zero CPU Dispatch
VMAC7072 times and non-zero Percent CPU Busy values, which when
Mar 24, 1998 summed into ASUM70PR could record more than 100% CPU Busy
for the CEC. Fortunately, very few sites have Partitions
Deactivated, but if you have this error, there will be
observations in TYPE70PR with LPARCPUS=0, as that is the
Deactivated Partition flag.
If you do have LPARCPUS=0 obs, you can correct the old
PDB.TYPE70PR data simply by deleting TYPE70PR obs with
LPARCPUS=0, and then re-run ASUM70PR (which reads the
corrected TYPE70PR dataset) to re-create the corrected
PDB.ASUM70PR dataset:
DATA PDB.TYPE70PR; SET PDB.TYPE70PR;
IF LPARCPUS=0 THEN DELETE;
%INCLUDE SOURCLIB(ASUM70PR);
You can prevent the creation of LPARCPUS=0 observations
in tomorrow's PDB by adding an IF test before the OUTPUT
statement in member EXTY70PR:
IF LPARCPUS GT 0 THEN OUTPUT ....;
until you install this change or MXG 16.01 or later.
The Permanent Fix. Change 15.299 created observations
for the Deactivated Partitions (for availability
reporting) but it failed to reset the variables from the
previous segment in this record. The permanent fix is to
insert these lines immediately after the existing IF:
IF LPARCPUS=0 THEN DO;
LCPUPDTM=.;
LCPUADDR=.;
LCPUSHAR=.;
LPARVPF =.;
LCPUEDTM=.;
LCPUDED =' ';
LCPUWAIT=' ';
LCPUCHST=' ';
LCPUCHWT=' ';
LCPUCAP =' ';
LCPUCAPC=' ';
ORIGWAIT=.;
NEWWAIT=.;
PCTCPUBY=.;
PCTMVSBY=.;
Thanks to Wayne Lauck, State of South Dakota, USA.
Change 16.027 While Change 15.273 mentioned that JES3 APAR UW41108
VMAC26J3 was required to fix an IBM error in the JES3 type 26
Mar 23, 1998 purge record, it did not protect the absence of that
APAR. By inserting IF LENGTH-COL+1 GE 10 THEN
immediately before the INPUT SMF27LN7 &PIB.2.
statement, even if the APAR is not installed, MXG won't
fail.
Thanks to Pete Gain, SAS Software, ENGLAND.
Change 16.026 New subtype 6 SMF type 99 record caused INVALID SERVER
VMAC99 SECTION TRIPLET because SMF99CPO=SMF99CPO+SMF99CPN;
Mar 22, 1998 should have been SMF99CPO=SMF99CPO+SMF99CPL;
This also caused truncated values for SRVCLASS.
Thanks to Steve Smith, BGS Systems, USA.
Change 16.025 "SHORT ABAR" warning messages about deleted records could
VMACHSM be erroneously created. Insert the INPUT statement below
Mar 22, 1998 between the ELSE DO; and the LENGTH-COL test so it reads:
ELSE DO;
INPUT @15+OFFSMF @;
IF LENGTH-COL+1 LT 274 THEN DO;
The COL value was still @40 as a result of the prior
INPUT, so records that were sufficiently long were
incorrectly deleted, but with the warning message.
Thanks to Don Friesen, B.C. Government, CANADA.
Change 16.024 -Support for new object "Database" creates new MXG dataset
EXNTDATA named DATABASE. This object has 104 fields in the record
IMACNTSM but only 16 are populated with field names and data.
VMACNTSM -Support for EXCHANGE 5.5 (INCOMPATIBLE) inserted data in
Mar 21, 1998 seven MS Exchange objects (IMC, IS Private, IS Public,
IS, Internet Protocols, MTA, and MTA Connections), which
caused INVALID TRIPLET warnings and skipped records until
this change is installed. Scores of variables were added
and some no longer exist in the Exchange records.
-Messages INVALID DATA FOR DURATM for Discovery Records
(Discovery Records have OID=0) occurs with NTSMF 2.1.4
records, but it has no impact on the real datasets that
MXG creates. The format of the Discovery Records was
changed, causing the MXG message.
-In addition, the _UNTDISC utility to print the Discovery
Records no longer worked with Release 2.0.h, which has a
NRNAMES field only in the 0.5 and not in the 0.6 or 0.6,
and there is an extra field at the end of each 0.7 record
that contains a repeat of the penultimate field. Also,
records from NTSMF 2.1.4 have still different Discovery
records, but the NTSMF Version is still 2.0.h, so logic
based on whether DURATM is missing or not (because the
new format has OBJECT name where DURATM was) is used to
decode which Discovery Format is in place, so that
_UNTDISC is now functional.
Thanks to Jim Quigley, Con Edison, USA.
Change 16.023 Change 15.368 added the DURATM=INTERVAL parameter to the
ASUMJOBS VMXGSUM invocations in most ASUM members, but ASUMJOBS
Mar 20, 1998 was overlooked until now.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.022 Only for those few who use the &DEBUGMXG symbolic during
VMXGSUM testing is this minor fix needed. The three lines
Mar 20, 1998 %IF &MXGDEBUG GE 2 ...; %ELSE %IF &MXGDEBUG GE 3 ...;
May 14, 1998 and %ELSE %IF &MXGDEBUG GE 4 ....; need the %ELSE
removed from the second and third lines.
This Change was not included in MXG 16.01, but was in
MXG 16.02.
Thanks to Graham Bell, Blue Cross Blue Shield of Kansas, USA.
Change 16.021 The TRENDing of TYPE70 dataset had not been updated for
TRND70 more than 8 CPUs. While TYPE70 contained sixteen buckets
Mar 20, 1998 for CPU's (variables suffixes 0-9,A,B,C,D,E,F), but the
TRND70 member was overlooked when variables 9 and above
were added to TYPE70. The lists of these variables were
expanded: CPUWAITn, IORATEn, PCTCPBYn, PCTTPIn, VFAFFTMn,
and logic added for PCTTPIn, PCTCPBYn and PCTRDYWT
calculations.
Thanks to Graham Bell, Blue Cross Blue Shield of Kansas, USA.
Change 16.020 Support for Software Engineering's SpaceManager's two
EXSPMGSP flat files, Space Records and Volume Records create two
EXSPMGVL new datasets:
FORMATS SPMGSPAC - SpaceManager Space Records
IMACSPMG SPMGVOL - SpaceManager Volume Records
TYPESPMG MXG requires both a //SPMGSPAC DD and a //SPMGVOL DD and
VMACSPMG will read both files with member TYPESPMG. If you only
Mar 20, 1998 want to process one file, simply DD DUMMY the unwanted.
Apr 7, 1998 Several new $MGSPMxx formats are created, so you will
need to update your MXG Format library using this new
FORMATS member.
Thanks to Hans Juergen-Beck, DVG, GERMANY.
Change 16.019 -Variables TPXBYTI and TPXBYTO have always been wrong, due
VMACEPIL to an error in CA's documentation. Instead of being two
VMACOMAU 8-byte fields, they are now input as &PIB.4. and a line
VMACOMCI with +4 follows each to skip over the unused 4-bytes.
VMACTPX -It was also noted that all of the internal TPX datetimes:
VMAC39 TPXETIME, TPXSTIME, TPXUTIME were on the GMT clock, while
Mar 20, 1998 the SMFTIME is on the local clock, but there is a GMT
Apr 6, 1998 offset in the record, so now, MXG converts those three
timestamps into local. The CVTTZ field in the record is
the high four-bytes of the GMT offset, which is not an
exact value, so the following algorithm is required to
get the GMT offset in seconds into TPXCVTTZ:
INPUT TPXCVTTC $CHAR4. @;
TPXCVTTZ=INPUT((TPXCVTTC!!'00000000'X),&IB.8.6)/4096;
IF . LT TPXCVTTZ LT 0 THEN TPXCVTTZ=FLOOR(TPXCVTTZ);
ELSE TPXCVTTZ=CEIL(TPXCVTTZ);
For example values, the raw TPXCVTTC is '00000D69'x for
a +1 hour (3600 seconds) European offset, and for a -5
hour (-18000 seconds) USA EST is 'FFFFBCF2'x.
Then to correct timestamps to local, you add TPXCVTTZ:
TPXETIME=TPXETIME+TPXCVTTZ;
-In validating this change, I looked at all of the members
that contain CVTTZ and I discovered that in four members,
VMACEPIL, VMACOMAU, VMACOMCI, and VMAC39, I had reversed
the FLOOR and CEIL functions, which caused a one second
error in value of the GMT offset, so those four members
were also corrected by this change.
Thanks to Harry Olschewski, DeTeCSM, GERMANY.
Change 16.018 Member DOCGRAF is updated with examples of getting graphs
DOCGRAF from the mainframe to your PC. The new examples were
Mar 20, 1998 originally postings on our MXG-L ListServer.
Thanks to Bob Hare, Comerica, INC, USA.
Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 16.017 The three DSORG fields in DCOLLECT (DCDSORG,UMDSORG, and
VMACDCOL UBDSORG) are increased to three bytes long from two, and
Mar 19, 1998 the suffix "U" will be added (e.g., DSORG='PSU') for the
files that "contain location dependent information, the
old "Unmoveable" attribute. I had erroneously set the
DSORT='U' for the Unmoveable attribute.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 16.016 Change 15.356 introduced the &MACxxxx macros, but member
IMACFILE IMACFILE was overlooked. Now, &MACFILE is initialized as
VMXGINIT blank in VMXGINIT and a line with only &MACFILE now ends
Mar 18, 1998 member IMACFILE (which is included after the SMF header
has been input), so that any tailoring of member IMACFILE
(formerly done EDIT and SAVE into your USERID.SOURCLIB)
and now be done inline by setting the &MACFILE variable.
Because this &MACFILE variable will be inserting actual
SAS statements with semi-colons, the always-safe-syntax
to use to insert statements in &MACFILE is:
%LET MACFILE= %QUOTE(
LINE OF CODE TO BE EXECUTED ;
LINE OF CODE TO BE EXECUTED ;
LINE OF CODE TO BE EXECUTED ;
) ;
For a specific example, your //SYSIN program could be:
%LET MACFILE= %QUOTE(
IF ID=110 AND SUBTYPE=2 THEN DELETE;
) ;
%INCLUDE SOURCLIB(TYPE110);
would delete the CICS subtype 2 (Statistics) records so
no //WORK space would be needed by them, but would read
the CICS subtype 1 transaction records to create CICSTRAN
observations. Note that while the references are
&MACFILE, the %LET syntax does not use the ampersand.
If you have an-already-tailored IMACFILE member, you must
either add &MACFILE to the end of your tailored member
(so that any code added inline with &MACFILE will be
executed AFTER the code in member IMACFILE), or you must
remove your tailored IMACFILE member and do all your
tailoring in the %LET MACFILE= statements.
For reasons that are still unclear, it was necessary to
add a semicolon after the &MACFILE statement in the
IMACFILE member to satisfy the SAS compiler under MS
Windows, but not under MVS!
Thanks to Chuck Hopf, MBNA, USA.
Change 16.015 Documentation. Variable JCSPTIME had been INPUT but not
VMAC110 kept, but was re-spelled as JCSPTOD when it was added to
Mar 17, 1998 the KEEP= list for dataset CICSSMED in Change 15.157.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 16.014 Variables XMGMXT and XMGTNUM were not kept in CICINTRV
CICINTRV dataset (in CICS 4.1 XMGMXT replaced DSGTL's MAXTASK
Mar 16, 1998 limit; DSG fields for AMAXTASK no longer exist in 4.1).
In the last VMXGSUM invocation in member CICINTRV, add
XMGTNUM to the SUM= argument and XMGMXT to the MAX=.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 16.013 Cosmetic. Variable WTSCWTCN was given FORMAT TIME12.2,
VMACTMO2 but the variable that should have been in the FORMAT
Mar 16, 1998 statement was WTSCWTTM.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.012 IDMS Version 10.2.1 PMHRTYPE=1 records caused error INPUT
VMACIDMS STATEMENT EXCEEDED RECORD LENGTH. Find the FIRST instance
Mar 16, 1998 of the line reading:
ELSE IF '1201' LE SMFHVER LT '1400' THEN DO; and change
it to read: ELSE IF '1021' LE SMFHVER LT '1400' THEN DO;
Thanks to Alan Deepe, SBC Warburg Dillon Read, ENGLAND.
Change 16.011 Variable SRHCRWRT is now SRCHRWRT to be consistent with
VMACNTSM the other spelling of other SRCHxxxx variables in dataset
Mar 15, 1998 FULCRUM built from NTSMF records.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 16.010 Member YEAR2000 now warrants that MXG is (in IBM terms)
YEAR2000 "Year 2000 Ready", and the cover letter that is normally
Mar 15, 1998 sent in reply to year 2000 requests is now included at
the beginning of member YEAR2000.
Change 16.009 Variable MXGVERSN in dataset TYPE70 was blank in 15.15.
VMAC7072 Originally MXGVERSN=SYMGET('MXGVERS'); was before the
Mar 13, 1998 IF (ID=70 OR ID=72) AND NOT MVSXA THEN DO; logic, but
Change 15.354's relocation of IF tests (for BUILDPDB's
performance) inadvertently caused the SYMGET to only be
executed for pre-XA RMF records. The simple fix is to
just copy the three lines:
IF MXGVERSN=' ' THEN DO;
MXGVERSN=SYMGET('MXGVERS');
END;
to immediately follow the IF ... AND MVSXA THEN DO;....
statement, so the SYMGET statement is executed once for
either type of record. However, Don Deese showed me that
RETAIN MXGVERSN "&MXGVERS" ;
will initialize a RETAINed character variable to the
value of a macro variable, so the actual change replaced
the existing RETAIN MXGVERSN ' ' statement with the
above syntax, deleted the three-line DO group on MXGVERSN
and added a line with MXGVERSN $6 to the LENGTH statement
to define MXGVERSN's length.
Users of CPExpert will need to install this change or get
a one-line fix from Don Deese to circumvent my error.
The PROC COMPARE that should have caught this error that
was not run for MXG 15.15 has been reinstated in MXG QA!
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Lynn Meyer, Storage Tek, USA.
Thanks to David Ehresman, University of Louisville, USA.
Change 16.008 Duplicate observations in TYPE30_V might not be deleted.
BUILDPDB Change 15.235 discussed the addition of MULTIDD EXTRADD
BUILDPD3 to the BY list for TYPE30_4 and TYPE30_5, but those two
BUILD005 variables were not added to the TYPE30_V sort until this
BUIL3005 change.
Mar 13, 1998
Thanks to Allan Winston, MBNA, USA.
Change 16.007 Cosmetic. Format MGILKAT had repeated 4: for the RETR,
FORMATS APPE, and STOR actions, instead of having 8:RETR, 16:APPE
Mar 13, 1998 and 32:STOR for the format values.
Thanks to Ken Mazer, Internal Revenue Service WVA, USA.
Change 16.006 The ARRAY statement permitted only 10 LCUIDs, causing the
ANALPATH SUBSCRIPT OUT OF RANGE error. The array statement was
Mar 11, 1998 increased to 16, the LCU1-LCU9 instances were change to
LCU1-LCU16 and variables LCU10 thru LUC16 were added to
the initialization logic.
Thanks to Tobias Cafiero, Mercedes Benz of North America, USA.
Change 16.005 Variable PCTDLSSW was added by Change 14.318, but its
VMAC7072 value was incorrect because it was never divided by the
Mar 5, 1998 variable VALDSAMP due the misspelling as PCTLDSSW in the
line in which it should have been divided by VALDSAMP.
Thanks to Chris Weston, SAS Institute CARY, USA.
Change 16.004 Change 15.293 discussed why YEARSECS and YEARDAYS can not
TYPEDMS be used to protect non-Y2K-compliant date fields, but the
TYPEMON8 code in these four non-compliant products was not changed
TYPETMON until this change, which uses smart logic to protect.
VMACNSM
Mar 5, 1998
Change 16.003 IBM's NPM product now creates a "century" value in their
VMAC28 unique date fields, but the new and unexpected format of
YEAR2000 'CYYMMDDF'x is still not documented by IBM. APAR II10481
Mar 4, 1998 does make the following statement:
Mar 9, 1998 "97/04/30 NPM will support the year 2000. User's do
not need to do anything special.
Further details provided by NPM development:
NPM's SMF record header contains the date (SMF28DTE)
in the form 0CYYDDDF, where the '0C' represents the
century. This byte contains '00' in this century
(the 20th century) and will contain '01' in the 21st
century. Therefore, for any NPM record, it is always
possible to identify the century"
but nothing in that Informational APAR said that the 99
internal date values (like start and stop times!) were
changed to CYYMMDDF, which is a new brand new date format
that exists in no other SMF record, and that new format
causes an INVALID ARGUMENT error when MXG 15.15 read NPM
records with year 2000 dates. So NPM users do in fact
have to do something special - they now have to install
(unnecessarily) a new version of MXG because the NETVIEW
NPM product did not document their INCOMPATIBLE changes
to type 28 SMF records!
And in addition, one field in NPM, LXETTMST, has yet
another unique date format of "MM/DD/YY.DDDHH.MM.SS"
which does not have room for a "century" nybble, so NPM
is still NOT YEAR 2000 READY. However, by adding MXG
windowing protection (YY LE 59) for LXETTMST, I have now
changed member YEAR2000's NPM entry to move NPM from the
"IS NOT" to "NOW IS" YEAR2000 compliant, even though NPM
really is not compliant without help from MXG logic.
Finally, the implication in the Informational APAR that
only the date field in the SMF header needs a century bit
to be "YEAR 2000 READY" is inaccurate. To truly be YEAR
2000 READY requires that each date value be complete and
self-described. A record that requires programming logic
to test one date field to then set the date of another
date field (which may or may not have been on the same
date as the first date value) is not YEAR 2000 READY.
That IBM ultimately had to change all 99 internal fields
shows that setting only the century bit in the SMF header
was not sufficient!
By the way, NPM APAR, OW28971 is also required to correct
an error in NPM's computation of leap years; without that
APAR, NPM incorrectly thinks 2000 is not a leap year.
This extensive MXG change inserted seven new lines for
each of the ninety-nine date values to decode the new
format, and exists only because CIGNA found the data
values in their year 2000 test partition's type 28 data.
Thanks to Steve Colio, CIGNA, USA.
Change 16.002 IDMS 14.0 new variables TASNINS,TASNUPD,TASNDEL,TASNSRT
VMACIDMS TASNSRR,TASNSMI,and TASNSMX had incorrect labels, and new
Mar 3, 1998 variable TASNAMC was not created. TASNAMC is now INPUT
as &PIB.4. following TASNSMX and the labels corrected.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 16.001 Variable PKSENOUN was renamed PKSENONU in NTSMF dataset
VMACNTSM NETWINTR for consistency with PKRCNONU, but variable
Mar 3, 1998 PKSENOUN is still built, so your old programs won't fail.
Thanks to Marti Henley, MatriDigm, USA.
LASTCHANGE: Version 16
=========================member=CHANGE15================================
/* COPYRIGHT (C) 1984-1998 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is MXG Version 15.15 - dated Feb 23, 1998, thru Change 15.391.
Second MXG Version 15.09 - dated Feb 17, 1998, thru Change 15.384.
First MXG Version 15.09 was dated Feb 16, 1998, thru Change 15.382.
Newsletter THIRTY-TWO was dated Feb 23, 1997, thru Change 15.382.
MXG Version 15.08 was dated Jan 15, 1998, thru Change 15.340.
MXG Version 15.07 was dated Dec 18, 1997, thru Change 15.311.
MXG Version 15.06 was dated Nov 24, 1997, thru Change 15.287.
MXG Version 15.05 was dated Oct 02, 1997, thru Change 15.238.
Newsletter THIRTY-TWO was dated Sep 12, 1997, thru Change 15.206.
MXG Version 15.04 was dated Sep 01, 1997, thru Change 15.206.
Final+ MXG Version 15.03 was dated Jun 30, 1997, thru Change 15.151.
Final MXG Version 15.03 was dated Jun 26, 1997, thru Change 15.148.
Second MXG Version 15.03 was dated Jun 25, 1997, thru Change 15.145.
First MXG Version 15.03 was dated Jun 24, 1997, thru Change 15.144.
MXG Version 15.02 was dated May 23, 1997, thru Change 15.103.
MXG Version 15.01 was dated May 6, 1997, thru Change 15.087.
Newsletter THIRTY-ONE was dated Feb 21, 1997, thru Change 14.343.
Contents of member CHANGES:
I. MXG Software Version 15.15 is now available, upon request.
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 15.15.
X. Online Documentation of MXG Software.
XI. Changes Log
I. MXG Software Version Status.
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:
MXG Tape Mount Monitor ASMTAPES ML-16 now supports four-digit UCBs.
Support for RMF Monitor III CPU, PGP, ENC records.
Support for TME 10 Netview OS/390 1.1 SMF type 37.
Major enhancements added in MXG 15.09 dated 16Feb1998:
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 ICSS 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 Jul 4, 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 "Phsyically" 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
IPLed 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. Note: Jan 2006: Using WAITCOMP=YES is no longer an
issue; only the early AMDAHL implemented that option, as I recall.
(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 raised more questions
than it answers, initially. Note: Jan 2006: However, now it is
used to calculate the SHORTCPS variable, and is thus useful.
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 ML-15 of the MXG ASMTAPES avoids 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.
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-IPLed 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 (Boole or 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). 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 ASMIMSL5 (IMS 5) or
ASMIMSLG (IMS 4) and their JCLIMSLG 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.05 Change 15.220
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.
ASMRMFV 15.384 Support for RMF Monitor III CPU, PGP, ENC records.
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.381 ASMTAPES ML-16 supports four-digit UCBs.
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.132A 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 (Lotus Domino).
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.
TYPE37 15.385 Support for TME 10 Netview OS/390 1.1 SMF type 37.
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 TYPE78CF 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 4.1 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.
UDSKCONT 15.388 Utility to report PC Disk File sizes.
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:
NEXTCHANGE: Version 15
======Changes thru 15.391 were in MXG 15.15 dated Feb 23, 1998======
Change 15.391 Zero observations in MIMTAPE dataset, because somewhere
VMACMIM along the way, the variable MIMCNT, which used to be the
Feb 20, 1998 sample count, is now zero in the MIM SMF record. MXG had
heuristically only invoked the EXTYMIM exit if the record
had "samples" but now no observations were created. The
two DO groups around the %INCLUDE SOURCLIB(EXTYMIM); that
tested MIMCNT GT 0 were eliminated, so all MIM segments
will be output.
Thanks to Joseph Montana, Acxiom, USA.
Change 15.390 Three variables in these two members still had DATE7 as
ANALDB2P their format, but are now changed to DATE9 so that all
ASUMIDMS four digits of year will be displayed.
Feb 20, 1998
Thanks to Pete Gain, SAS UK, ENGLAND.
Change 15.389 Reading type 42 records directly from the SMF VSAM file
VMAC42 caused INPUT STATEMENT EXCEEDED because some of the new
Feb 20, 1998 subtypes did not have "+OFFSMF" added when their offsets
were calculated. The code worked fine with dumped SMF
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 15.388 New utility program that reports PC Disk File sizes and
UDSKCONT disk space required by directory and high-level directory
Feb 20, 1998 names. To use, from the root directory, you issue:
DIR *.* /S >> C:\DISKFARM
which creates the listing of all files in "DISKFARM",
and then, under SAS, you issue:
%UDSKCONT
and the reports will show the total disk space required
(assuming 32K worst-case cluster size for FAT) and the
file bytes in each directory, and then a summary report
shows filesize and space required by highlevel dir name.
Change 15.387 Support for TME 10 Netview for OS/390 1.1 SMF type 39
VMAC39 will not fail with the new records, but there are two
Feb 18, 1998 segments (accounting and availability data section and
APPN route data section) that are added to the existing
subtypes, and there are two new subtypes:
007 - Init Failure Record
008 - Storage and Event Counter Record
If you have these records, see member SENDDATA and email
me a few hour's worth so I can validate the enhancement.
Change 15.386 Support for TME 10 Netview for OS/390 1.1 SMF type 38
VMAC38 is NOT included in MXG; the type 38 record was completely
Feb 18, 1998 restructured and I need test data records to enhance it.
There are now three subtypes that now exist in type 38:
001 - Command Authorization Table
002 - Task Resource Utilization Table
003 - Span Authorization Table
First glance shows lots of interesting fields. If you
have type 38's from Version 1.1, see member SENDDATA and
email me a few hours worth, and I can enhance MXG with
these three new datasets.
Change 15.385 Support for TME 10 Netview for OS/390 1.1 SMF type 37
VMAC37 record IS already included in MXG, as there were no
Feb 18, 1998 changes to the type 37 record, although the table numbers
were changed in documentation: "TME 10 Netview for OS/390
Application Progrmmer's Guide Version 1 Release 1, pub
number SC31-8223-00 (but don't look for that order number
on the publication itself; only on the Readers Comment
Form could I find the pub number!). IBM saves ink???
That publication documents SMF 37, 38, and 39 records.
======Changes thru 15.384 were in MXG 15.09 dated Feb 17, 1998======
Change 15.384 Support for RMF Monitor III VSAM file adds support for
ASMRMFV new record types of CPU, PGP, and ENC, but I have not had
ASMRMFV test data (ASMRMFV, when assembled, converts the RMF III
Feb 17, 1998 compressed files into flat records for TYPERMFV to read),
so output records from ASMRMFV with CPU, PGP, or ENC
enabled needs to be verified with TYPERMFV. In addition,
the support for the CSR records cannot be finished until
we can get a hex dump of the ASMRMFV program when it
tries to read a CSR record. We have created a special
version of ASMRMFV, named ASMRMFVX, that will Abend S0C3
when it tries to read a CSR record; if you have those
enabled and can generate the S0C3 Abend Dump, please send
it (tape or printed) to Merrill Consultants so we can
decode that RMF III record as well.
Change 15.383 MXG 15.09 only. Comma missing at end of INCODE= caused
TRNDRMFI error. This was caught in my QA test, but I failed to
Feb 17, 1998 copy the change from the QA library back into the master!
====Changes thru 15.382 were printed in MXG Newsletter THIRTY-THREE====
Change 15.382 NPM variables STARTIME, ENDTIME, and DURATM had missing
VMAC28 value in dataset NPMINRTM from SMF type 28 subtype '30'x.
Feb 16, 1998 Valid STARTIME and ENDTIME were INPUT in the STT section
processing, but the SAA section also INPUT STARTIME and
ENDTIME, and when there were no timestamps in the SAA
section, their missing value overrode the valid STT
values. To correct, the calculation of STARTIME and
ENDTIME in the AOFTYPE='SAA' section is performed by
IF STARTIME=. THEN DO; and IF ENDTIME=. THEN DO;
logic so that valid STARTIME/ENDTIME will be preserved.
Thanks to ???, Spar Handels AG, GERMANY.
Change 15.381 ASMTAPES Maintenance Level ML-16 now writes records for
ASMTAPES devices with four-digit UCBs. (We thought we had added
ZSMTAPES that support long ago, but testing uncovered our error.)
Feb 17, 1998 In addition, ML-16 corrects the "TEST" SYSPARM which did
not work as advertized. Note that "TEST" (which writes
to a flat file instead of SMF), does not support the WLM
(Workload Manager Fields) that ARE supported in non-TEST.
Thanks to Mark Schmitt, First Card, USA.
Change 15.380 Major enhancement to support for Boole & Babbage CMF
EXCMFVAL VSAM History File. MXG Previously decoded a dozen or
EXCMFVCD so subtypes, but this massive user contribution added
EXCMFVCF fourteen completely new datasets and their exits, and
EXCMFVCS creates variables in ten existing datasets that were only
EXCMFVDC a skeleton dataset before this change.
EXCMFVDV
EXCMFVGL The bulk of this change was written by
EXCMFVHD Pino Todesco, Boole and Babbage, Australia.
EXCMFVMP
EXCMFVMS This text will be updated with correct name, etc.
EXCMFVMV
EXCMFVRV As test data is received from interested sites for the
EXCMFVSO subtypes not yet decoded, MXG will be enhanced to also
EXCMFVST support those subtypes.
VMACCMFV
Feb 15, 1998 This is also called "Mainview" by Boole.
Thanks to Pino Todesco,Boole & Babbage, AUSTRALIA.
Change 15.379 Two new reports for "Batch Window" analysis, one based on
ANALBATW PDB.STEPS as input, and the second based on PDB.JOBS were
Feb 15, 1998 written by Grant and contributed by Ken.
Thanks to Grant Mackay, Standard Life, SCOTLAND
Thanks to Ken Williams, Southern Electric, UK.
Change 15.378 Some simple reports of Data Set activity based on the SMF
ANAL42 type 42 record's dataset TYPE42DS were contributed by
Feb 15, 1998 Ken from a previous lifetime.
Thanks to Ken Williams, Standard Life, SCOTLAND.
Change 15.377 Boole's CMF Cache Stats were split into two CMF datasets
VMACCMF CMF27CSC and CMF27C93, but there were no merge variables
Feb 15, 1998 with which to combine them, so the internal logic was
redesigned, so now the CMF27CSC dataset contains both
sets of variables. The CMF27C93 dataset is still built as
before (so your old reports won't fail), but you should
now use CMF27CSC for Cache reporting (and you can then
use your EXCMFC93 exit member to turn of creation of obs
in the now-archaic CMF27C93 dataset. Use CMF27CSC!
Thanks to Neil Ervin, Banc One Services Corporation, USA.
Change 15.376 Boole CMF subtype 16 record now creates two new datasets
EXCMF16M CMF16MAP (Virtual Storage Map) & CMF16LPA (LPA Modules)
EXDMF16L thanks to this significant user contribution.
VMACCMF
Feb 13, 1998
Thanks to Paul Hill, Midland Bank, UK.
Change 15.375 IMS Log records from Boole's IMF and from SAP and IBM's
TYPECIMS IMS log records can now be processed in one pass of the
TYPEIMFL IMS log. Member VMACIMS had internal variable MSGDRRN
VMACCIMS (a numeric variable) replaced by CMSGDRRN (a character)
VMACIMS to avoid conflict between CIMS and IMS member, and some
Feb 13, 1998 lines were relocated in both VMACCIMS and VMACIMS, and
macro _IMS in member VMACIMS now creates the variables in
the header that VMACCIMS expected, and new macro _CHAIN
is defined in member VMACCIMS, replacing the inline code
that handled Chained Transactions in member TYPECIMS, so
the end result is that new member TYPEIMFL contains:
%INCLUDE SOURCLIB(VMACCIMS,VMACIMS);
DATA _VARCIMS _VARIMS ;
_IMS ; _CDECIMS _CDEIMS ; _CHAIN ;
so TYPEIMFL creates all 25 datasets from IMF, IMS, and
SAP's IMS log records in one pass of the IMSLOG tape:
CIMSTRAN CIMSDBDS CIMSDB2 CIMSPROG
IMS01 IMS01M IMS03 IMS03P IMS07 IMS08
IMS31I IMS31O IMS35I IMS35M IMS35O IMS35P
IMS36 IMS36M IMS5901 IMS5903 IMS5936 IMS5937
IMS5938A
SAPIMSBA SAPIMSON SAPIMSSP
And if you don't want to create all 25 datasets, you can
use MXG's new &MACxxxx macro variable (Change 15.356) to
redefine the _Lxxxxx dataset macros to _NULL_ for the
unwanted data sets, and they won't be created:
%LET MACIMS=
MACRO _LIMS01 _NULL_ % MACRO _LIMS01M _NULL_ %
MACRO _LIMS03 _NULL_ % MACRO _LIMS03P _NULL_ %
MACRO _LIMS07 _NULL_ % MACRO _LIMS08 _NULL_ %
MACRO _LIMS31I _NULL_ % MACRO _LIMS31O _NULL_ %
MACRO _LIMS35I _NULL_ % MACRO _LIMS35M _NULL_ %
MACRO _LIMS35O _NULL_ % MACRO _LIMS35P _NULL_ %
MACRO _LIMS36 _NULL_ % MACRO _LIMS36M _NULL_ %
MACRO _LIMS591 _NULL_ % MACRO _LIMS593 _NULL_ %
MACRO _LIMS596 _NULL_ % MACRO _LIMS597 _NULL_ %
MACRO _LIMS598 _NULL_ %
;
%INCLUDE SOURCLIB(TYPEIMFL);
would only create the 4 IMF and the 3 SAP datasets.
Thanks to Reinhard Kelm, GRZ, GERMANY.
Thanks to Friedhelm Danne, GRZ, GERMANY.
Change 15.374 There was no KEEPs example that worked with ASUMUOW, but
IMACCICS comments implied there was. Now the three examples show
Feb 12, 1998 the KEEPs for CICSTRAN that are required for ASUMCICS,
ASUMCICX, and ASUMUOW. The actual KEEPs examples use
the DROP= statement in the _K macro to control keeping.
Thanks to Tom Weiland, Phoenix Home Life Mutual Insurance Co, USA.
Change 15.373 Support for OS/390 Version 2 Release 5 is contained in
none MXG 15.04 or later, as there were no changes to the SMF
Feb 12, 1998 records between OS/390 2.4 and OS/390 25., and MXG Change
15.270 added support for Version 2 Release 4 in 15.04.
Change 15.372 Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPATIBLE
VMACCIMS because 400 bytes were inserted at the end of the fixed
Feb 12, 1998 portion of the record, causing DBD counts to be wrong
without this change. The 400 bytes added only four new
fields: GMT Adjustment, UTCA, Checkpoints/Syncpoints
CTCKPNTS, Maximum Locks Held MAXLOCKS and Total Locks
Held, TOTLOCKS.
Thanks to Reinhard Kelm, GRZ, GERMANY.
Thanks to Friedhelm Danne, GRZ, GERMANY.
Change 15.371 The new BLDNTPDB macro provides simple daily/weekly/
BLDNTPDB monthly dataset building and reporting from NTSMF data
Feb 12, 1998 records. This macro does everything for you, or you
can override its options. It even supports reruns!
Especially for new users who are not familiar with the
PDB architecture, this runs-only-on-ASCII-SAS example
should make life simple. More documentation on how to
use this facility will be forthcoming, and this is still
in development.
Thanks to Marti Henley, Matridigm, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.370 Concurrency analysis routine ANALCNCR has new MYTIME=
ANALCNCR argument for sites that want to specify a non-standard
Feb 12, 1998 time period for summarization. (Note: the MYTIME=
specification is not used to "sync" the intervals, and
SYNCINTV=YES is ignored if INTERVAL=MYTIME is used.
Thanks to Tom Parker, CSC FSG Banking Division, USA.
Change 15.369 Trending for the ASUMUOW using the PDB.ASUMUOW dataset
TRNDUOW daily as input, rather than building ASUMUOW weekly, is
Feb 12, 1998 recommended for sites that need to analyze CICS MRO with
or without DB2 by UOWID, i.e., by Unit of Work ID, due
to potential large volumes of data, CPU time, work space
and I/O operations if the trending were done from the
weekly PDB.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.368 New argument DURATM=INTERVAL will cause variable DURATM
ASUMCICS to be created in VMXGSUM's output dataset, and DURATM
ASUMDB2A will contain the duration specified on INTERVAL (for the
ASUMDB2B "real" durations of QTRHOUR, HALFHOUR,HOUR, and DATE), to
ASUMHSM be consistent with MXG design intentions of having DURATM
ASUMJOBS in all interval datasets. The eight ASUMxxxx members
ASUMPRTR listed are the first to exploit this new DURATM=INTERVAL
ASUMTMNT argument for VMXGSUM. In addition, both VMXGSUM and
VMXGDUR VMXGDUR now contain new argument MXGWEEK= that allows
VMXGSUM you to change your "first day of the week" in Trending
Feb 12, 1998 datasets from MXG's default of MONday.
Thanks to Chris Weston, SAS ITSV Cary, USA.
Change 15.367 The EXCPNODD and EXCPTODD counts in step and job records
ANALMULT with MULTIDD='Y' (i.e., there were so many DD segments
Feb 12, 1998 that MVS created multiple type 30 records for a step)
are incorrect, because they are created for each step
record and are not summed across all of the multiple
records. Since these MULTIDD='Y' jobs are almost always
data center work (like SAR/RMDS/etc spoolers) the error
has not had any real effect, but this user has provided
a series of macros that will start with the raw SMF data
and correctly calculate EXCPNODD and EXCPTODD for these
MULTIDD='Y' tasks. Because it must sort lots of records,
and takes appreciable CPU and IO resources, I have no
plans to add the logic to BUILDPDB, but it is here if
you need it!
Thanks to Dr. Alexander Raeder, Karstadt, GERMANY.
Change 15.366 Member ANALUOW as announced in Change 15.205, but it did
ANALUOW not get copied into the MXG library until MXG 15.09, and
Feb 12, 1998 it was cleaned up and enhanced now as well.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.365 CICS DFHSTUP "Shutdown" reports CICNQG, CICLGS, and
ANALCISH CICLGR have been added to member ANALCISH.
Feb 20, 1998
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.364 Support for StorageTek VSM SMF records adds 17 new data
EXSTCV09- sets for HSC subtypes 09 thru 26. The datasets are
EXSTCV25 named STCVSM09 thru STCVSM26 and they provide significant
VMACSTC measurements, including bytes read/written, duration of
Feb 12, 1998 mount, dismount, recall, migrate, etc., etc., etc!
Feb 20, 1998 The code has been syntax checked and subtypes 13, 14, 15
and 21 records have been processed.
Change 15.363 IDMS Journal Format Performance Records were apparently
TYPEIDMJ changed in IDMS Version 12, and the old Journal support
VMACIDMJ failed. This revision heuristically skips over the non
Feb 11, 1998 performance segments and has been tested with real data.
Unfortunately, the quick solution was to create VMACIDMJ
that knows about the idiosyncrasies of the Journal data,
but this means dual maintenance in VMACIDMS/VMACIDMJ with
each new version of IDMS!
Thanks to Alfred Mueller, ABN-AMRO Services Co., USA.
Change 15.362 NPM type 28 subtype 82 caused INPUT STATEMENT EXCEEDED
VMAC28 because 36 bytes were input when there were only 24. The
Feb 10, 1998 statement ELSE IF LENAOF GE 172 AND NPMSUBTYP NE 83X
THEN INPUT +36 @;
must be changed to ELSE .... THEN INPUT +24 @;
Thanks to Mel Hitchings, British Telecom, WALES.
Change 15.361 Creation of the WKnnPCPU, WKnnPPRV, and WKnnPUSR percent
NTINTRV values in the NTINTRV dataset was revised to convert the
Feb 10, 1998 percentages to durations, sum the durations, and recalc
the percentage values. If the DURATM of all PROCESS
intervals is the same, the new and old calculations are
identical, but the old calculations were wrong if there
were dissimilar values of DURATM in the PROCESS dataset.
Thanks to Wayne Holzback, Reynolds Metal Company, USA.
Change 15.360 Variable OTHRPUSR was not in the RETAIN list in member
NTINTRV NTINTRV, causing that variable to be missing from the
Feb 10, 1998 NTINTRV dataset.
Thanks to Marti Henley, Matridigm Corporation, USA.
Change 15.359 DCOLLECT variables DDCXSYS and DDCXREG were reversed in
VMACDCOL the input statement; DDCXSYS should have been first and
Feb 10, 1998 then DDCXREG second, as it was in DCOLLECT 1.2. In 1.3
the documentation reversed the order, but tests with
data confirm the real order is XSYS and then XREG.
Thanks to Mike Blocker, Fidelity Investments, USA.
Change 15.358 The TYPE42AU (Audit ACTIVATE, ENF, or VARY SMS events)
VMAC42 was not input correctly, but the record is also wrong!
Feb 10, 1998 MXG errors: insert +16 between INPUT and SMF42ETY.
change +72 to +88 before SMF42ESD.
IBM error: there are only 31 total bytes between SMF42ETY
and SMF42EVL, instead of the 32 documented.
I changed the +22 after SMF42ENM to +21 while
we sort out IBM's error.
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 15.357 Support for APAR OW29790 adds variables PGOALPCT and
VMAC99 SERVER01-SERVER05 and SERVPN01-SERVPN05 to the TYPE99_6
Feb 10, 1998 dataset to track service classes served.
Change 15.356 This enhancement adds a &MACxxxx macro variable in each
DOC VMACxxxx member so that you can dynamically override the
VMXGINIT IMACxxxx member without having to EDIT and save an IMAC!
Feb 8, 1998 In each VMACxxxx member, a new line with "&MACxxxx;" was
added immediately after the %INCLUDE SOURCLIB(IMACxxxx).
For example, in member VMACHSM, the statements are:
%INCLUDE SOURCLIB(IMACHSM);
&MACHSM;
Each of the &MACxxxx macro variables are initialized to
a null string, and GLOBALed, in member VMXGINIT.
So in your program, you can set the value of the &MACxxxx
macro variable equal to the old-style macro definition
syntax ("MACRO macro-name macro-text %" to thus change
the definition of the _L,_K dataset tailoring macros:
MACRO _Lxxxxxx - tailor Libref and Dataset Name
MACRO _Kxxxxxx - tailor KEEP/DROP list of vars
or to change the new _S PROC SORT macro added in 15.328:
MACRO _Sxxxxxx - PROC SORT and BY statements
or in a future version, change the planned _E Exit macro:
MACRO _Exxxxxx - will allow you to override the
%INC SOURCLIB(EXxxxxxx) exit.
and thus have complete dynamically tailoring for each
individual dataset. For example, for SMF 30, you could:
%LET MAC30=
MACRO _LTY30U1 _NULL_ %
MACRO _LTY30U4 MYDD.TYPE30_4 %
MACRO _LTY30U5 _NULL_ %
MACRO _LTY30UV _NULL_ %
MACRO _LTY30UD _NULL_ %
MACRO _LTY30U6 _NULL_ %
MACRO _LTY30MU _NULL_ %
MACRO _LTY30OM _NULL_ %
;
%INCLUDE SOURCLIB(TYPE30);
to create only the dataset TYPE30_4 from the subtype
4 record, and it would be written to the //MYDD library.
For a User-SMF record, where you must set the SMF record
ID in the MACRO _IDxxxx in the IMACxxxx for the product,
you can now redefine the _ID macro with the &MACxxxx.
For example, to process the HSM User SMF record and put
all HSM datasets in the //WORK library, you could use:
%LET MACHSM=
MACRO _IDHSMDS 240 %
;
%INCLUDE SOURCLIB(TYPEHSM);
For those not familiar with the syntax of the %LET, you
use %LET MACxxx= before the old-style macro statements
and then you end the %LET statement with a semi-colon.
If the text contains semi-colons, you can instead use
%LET MACxxx= %QUOTE( whatever-with-semicolons) ;
For those not familiar with the syntax of the old-style
MACRO statement, it is simply
MACRO macro-name macro-text
and then a single percent-sign ends the definition.
If the macro text has a percent-sign, then double it:
MACRO _EXXXXXX %%INCLUDE SOURCLIB(EXYYYY); %
This new &MACxxxx architecture is a significant piece of
the complete redesign to allow external control of all
MXG datasets. Because the &MACxxxx enhancement is safe
and can be used to override existing IMAC definitions, it
is added in MXG 15.09. The remaining pieces of this big
change will be implemented after MXG 15.15 has shipped!
Change 15.355 Variables ASICSAA, ASISQAA, ASIECSAA and ASIESQAA were
VMACRMFV horifically large, because they should have been read in
Feb 5, 1998 with &RB.4. informat instead of &PIB.4.
Thanks to Peggy Dunne, Depository Trust Company, USA.
Change 15.354 All VMACs that process SMF records were made consistent,
VMACSMF by locating the "IF ID = ..." statement immediately after
BUILD606 the MACRO _CDExxxx statement. All new VMACs have been
BUIL3606 written that way, but some old VMACs had LABEL statements
Feb 5, 1998 between the macro definition and the IF test. Now that
the _CDExxxx macros for SMF records all start with the IF
test for record IDs, the efficiency improvements of MXG
Change 15.329 are revised again. Instead of the logic
ELSE IF ID=xx THEN DO;
_CDExxxx
END;
now, the logic
ELSE _CDExxxx
can be used, eliminating the extra test imposed by the
external IF statement.
The VMACs whose IF statement was relocated are:
VMAC25 VMAC7072 VMAC71 VMAC73 VMAC74 VMAC75 VMAC76
VMAC77 VMAC78 VMACCTCP VMACEDGS VMACF127 VMACFTEK
VMACHSM VMACODS VMACSYNC VMACTSOM
Thanks to Chuck Hopf, MBNA, USA.
Change 15.353 Support for Landmark's TMON for CICS Version 2 (MXG1506)
VMACTMO2 conflicted with ITSV because some variables were changed
Feb 5, 1998 incorrectly by MXG, and some variables were not created.
Variable MONIMANT is now created, variable TATASKNN is
re-spelled TATASKNR, variable CICSLV is renamed to be
CICSLEV (Landmark changed it from PIB1 to $CHAR4 so I
had no choice), and variable FACTYP is changed back to
PIB1 and formatted as it was in prior versions.
Thanks to Rod Gaas, Eagle Star, UK.
Change 15.352 MXG 15.08. The label for variable S1ELEMLO was typed as
VMAC110 S1ELEMLO='LOWEST*FREE*ELEMENTS*='/ but SAS did not die
Feb 4, 1998 or produce an error message! The extraneous characters
are now removed. Also, macro _CICSTCMN was added to the
KEEP= list for dataset CICSSMED so the common variables
(in particular, SYSTEM and SMFTIME) will now be kept.
Thanks to Chris Weston, SAS ITSV, USA
Change 15.351 Cosmetic. Variable LCSLOV1 label should have been
VMAC28 'OVERFLOW*FLAG*BYTE'.
Feb 4, 1998
Thanks to Ley Teng, QANTAS, AUSTRALIA.
Change 15.350 The explicit dataset names TYPE72 and TYPE6 were replaced
ASUMPRTR with _LTY72 and _LTY6 macro names instead, so that if you
Jan 31, 1998 re-direct either dataset from the default of "WORK", MXG
will find it where you put it.
Thanks to Chris Weston, SAS ITSV, USA.
Change 15.349 The example "reptprod" file to control fields extracted
ADOCMWAI from HP's MeasureWare for AIX is now provided in the
Jan 28, 1998 ADOCMWAI member.
Thanks to Lorenzo Wright, NCCI, USA.
Thanks to Thierry Van Moer, Comparex, BELGIUM.
Change 15.348 Member VMACTRNS was a copy of VMACTRSN that had been
VMACTRSN saved under the incorrect VMACTRNS name, so the member
Jan 27, 1998 VMACTRNS has been deleted.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 15.347 The VMXGFOR references in the commented out example that
RMFINTRV can be used to read SMF directly must all be %VMXGFOR.
Jan 27, 1998 Only if you remove the comment block to read SMF direct
would you see this error.
Thanks to Jim Chappell, Pacific Power and Light, USA.
Change 15.346 Support for Landmark for MVS Version 2 segments that were
VMACTMV2 not available for testing in MXG 15.08. New segments
Jan 26, 1998 that have now been data-validated are: JD, LM, and TR.
These record subtypes caused INPUT STATEMENT EXCEEDED.
Thanks to Jonathan McVey, Lowe's Company, USA.
Thanks to Mark Derreks, Hershey's, USA.
Change 15.345 MXG 15.08 only. The new MACRO _SCICEXC should have had
IMACCICS &PDB..CICSEXCE instead of &PDB.CICSEXEC. Fortunately,
Jan 20, 1998 the new macro is not (yet!) used in MXG code, so there
was no execution error.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.344 Variable NTVERSP was truncated to 12 positions, so it
VMACNTSM had only "Service Pack" instead of "Service Pack 3".
Jan 20, 1998 Move the NTVERSP in the line with $12 to the next line,
with $32, so it will be 32-bytes long.
Thanks to Marty Henley, Matridigm, USA.
Change 15.343 MXG 15.08 only, JES2 only. Change 15.329 reordered the
BUILD606 _CDE macros for performance, but putting _CDE30 ahead of
Jan 20, 1998 _CDE26J2 caused variable JOBCLASS to be 8 bytes instead
of 1 byte. (JES2 has a one byte JOBCLASS, JES3 has three
bytes kept, but the variable is input at $EBCDIC8 in the
type 30 logic.) By placing the _CDE26J2 processing prior
to the _CDE30 processing for the JES2 BUILDPDB, the
JOBCLASS variable will be 1 byte in JES2 and 8 in JES3.
Thanks to Tom Parker, CSC Hogan Systems, USA.
Change 15.342 MXG 15.08 only. Change 15.330 was not correct, causing
VMAC26J2 type 26 ACCOUNTn fields to be not input. The test
Jan 20, 1998 (SMF26OAG+SMF26LAG-1 LE LENGTH) should have been
(SMF26OAG+SMF26LAG-4 LE LENGTH).
Thanks to Tom Parker, CSC Hogan Systems, USA.
Change 15.341 Support for 'DD'x NPM record did not input the VCD data.
VMAC28 Change the test that sets COFTYPE='VCD' to read:
Jan 19, 1998 ELSE IF 0D0X LE NPMSUBTY LE 0DBX OR
NPMSUBTY EQ 0DDX THEN COFTYPE='VCD';
Thanks to Mel Hitchings, British Telecom, WALES.
======Changes thru 15.340 were in MXG 15.08 dated Jan 15, 1998======
Change 15.340 Cosmetic. Extra variables were kept in NPMINFRP because
VMAC28 the KEEP= list contained _VA28ACD, but that should have
Jan 15, 1998 been _VA28NCD, which is the shorter configuration record
that is in NPMINFRP. Variable names that were misspelled
are corrected: LFRPOBOL is LFRPOBQL, LXLKTSLP/LXLKRSLP is
LXLKTLSP/LXLKRLSP and LXPUTSLP/LXPURSLP is ....TLSP/RLSP.
Thanks to Ley Teng, QANTAS, AUSTRALIA.
Change 15.339 The first MXG 15.08 tapes dated Jan 14, 1998 contained an
UTILUOW error: the member UTILUOW was added at the last minute,
Jan 15, 1998 and I failed to change its "./" IEBUPDTE control cards
to "XY", so when IEBUPDTE read the tape to create your
source library, those "./" cards in UTILUOW overwrote
all of the (previously unloaded successfully!) EXCICxxx
members. Replacement tapes with Jan 15, 1998 date (and
with XY vice ./) were shipped to the 23 sites getting the
bad tape, but you could copy the tape and delete lines
864,653 thru 865,135 inclusive, and then use that copy as
input to IEBUPDTE.
Thanks to Freddie Arie, Texas Utilities, USA.
======Changes thru 15.338 were in MXG 15.08 dated Jan 14, 1998======
Change 15.338 Further cleanup and enhancements to eliminate unneeded
ANALCISH datasets (the INT, EOD, USS, RRT, and REQ datasets are
Jan 14, 1998 not used by any ANALCISH report, so they are no longer
created when PDB=SMF is specified, for example). You
can select from more than one PDB library for input with
the PDB=TUE WED THU, syntax, and handling of the many
WORK.TRANSxx merges was revised.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.337 Support for AIX commands IOSTAT, PSSTAT and VMSTAT
AIXPDS has been revised and enhanced from the original unix
Jan 14, 1998 examples in member VMACRSxx. Those members and new
ones, including JCL examples for FTPing the unix data
to MVS, are provided in this find enhancement authored
and contributed by Joe. See the comments to expand the
member into a separate MXG.RX6000.SOURCLIB library.
Using the unix commands to measure unix performance is
marginal at best, but if you do not have a monitor
product for unix, you can get useful information by
running the PSSTAT, IOSTAT and/or VMSTAT commands and
using this code to turn them into MXG datasets.
Thanks to Joe Faska, Depository Trust, USA.
Change 15.336 Support for NPM APAR OW17876 and NPM Version 2.3 added
EX028VTT variables to the CSL, FRP, GBL, TRI, VCD, VEN, VGB, and
IMAC28 VVR segments, and new dataset NPMVSVTT is created from
VMAC28 from new subtype 'DD'x record. Many new variables
Jan 14, 1998 provide HPR counts (frames/bytes sent/rcv/discarded).
These changes were COMPATIBLY made by IBM, so earlier
versions of MXG will not fail with NPM 2.3 records, but
this change is required to capture the new fields.
Thanks to Melanie Hitchings, British Telecommunications, WALES.
Change 15.335 Utility to examine CICSTRAN observations from MRO CICS
UTILUOW to determine which transaction record contains the real
Jan 13, 1998 transaction name for each unit-of-work. With the output
of UTILUOW, you can edit IMACUOW to tell MXG which name
to keep, so that dataset ASUMUOW will have the "correct"
TRANNAME name for the UOW. Read the member's comments.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.334 Cosmetic. Temporary dataset KEEPERS was not deleted when
VMXGSUM there were no observations in the input dataset, but now
Jan 13, 1998 it is always deleted.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.333 Support for type 79 subtype 15 (IMS Long Lock) record has
EXTY79F only been visually tested, as no IMS site has sent any
IMAC79 test data. For each Long Lock, you get the IRLM lock
VMAC79 structure name and Lock Name, as well as identity of the
Jan 11, 1998 IMS subsystem and even CICS task name (if CICS).
Change 15.332 All ADOC members have been updated to list all variables
ADOCx as of MXG 15.07; this is the output of an extensive piece
Jan 9, 1998 of work by Freddie that merge new variables and datasets
into the existing ADOC members, while preserving the text
descriptions, tutorials, discussions, and the sample PROC
PRINT and MEANS output. This iteration makes all of the
ADOCs conform to the format described in ADOCxxxx, so
that this process can be fully automated and will soon be
an automated part of the MXG QA jobstream.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.331 OMEGAMON FOR VTAM 400, Change 15.296 was not complete,
VMACOMVT amd caused MXG to loop on an INPUT statement. All byte
Jan 9, 1998 related variables are now formatted with MGBYTES. MXG
now creates new interval rate, or "Per Sec", variables
for each pair of ACCUM/PREVIOUS counters. These new
variables, suffixed with R, should be most useful.
The ACCUM/PREVIOUS counters could be dropped if space
becomes an issue. However, the OMVTMPCS pair ON08BCT
and ON08BCTP for one interval produced a negative value
for the "Per Sec" value, ON08PCTR, because the ACCUM of
104,425 was less than the PREVIOUS of 108840! This will
be investigated with Candle.
Thanks to Joseph E. Darvish, Farmers Insurance Group, USA.
Thanks to Robert S. Miller, Farmers Insurance Group, USA.
Change 15.330 APAR OW28613 corrects an error in SMF26OAG; without the
VMAC26J2 APAR, MXG had INPUT STATEMENT EXCEEDED error condition.
Jan 8, 1998 To circumvent the error until you get the APAR installed
change the test of SMF26OAG to read as follows:
IF SMF26OAG GT 0 AND SMF26LAG GT 0 AND SMF26NAG GT 0
AND (SMF26OAG+SMF26LAG-1 LE LENGTH) THEN DO;
(The bad record I saw has LENGTH=417 but SMF26OAG=439!)
Only variables ACCOUNTn in dataset TYPE26J2 (which are
new additions) are affected by the error, and the will be
blank until you install the APAR. Furthermore, MXG uses
the type 30 ACCOUNTn fields in BUILDPDB normally, and
will use the new type 26 fields only for job's with JCL
errors that did not execute.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 15.329 The BUILDPDB logic for the SMF processing phase is now
BUILDPDB more efficient, as the _CDExxxx macros are reordered to
BUILDPD3 process the most frequent records first (the order is
BUILD606 110, 30, 74, 100-101 and then the rest), and the _CDExxxx
BUIL3606 macros are now inside ELSE IF ID= xxx then DO; blocks.
BUILD001 This will result in significant reductions in CPU time!
EXTYID Also, the ID dataset that was hardcoded in BUILPDx code
IMACID has been externalized so it can be tailored to contain
TYPEID additional variables (in IMACID's _KTYID macro) or can
VMACID contain zero observations (by commenting out the OUTPUT
Jan 7, 1998 statement in member EXTYID). See Change 15.354, which
redesigned this change for more efficiency.
Change 15.328 New macros _Sxxyyyy are defined in IMACs that will let
IMACs you sort individual datasets exactly as that dataset is
Jan 7, 1998 sorted into the PDB library in BUILDPDB/BUILDPD3. The
_Sxxyyyy name matches the _L, _K macro names and the
EXxxyyyy exit member naming conventions. The sort macro
is needed by sites that have so much SMF data that they
have to split their SMF data into parallel SMF files. An
example of their use would be for a site that split their
type 74 RMF records to a separate SMF file. To create
the TYPE74 and TYPE74CA datasets into separate SAS data
libraries they could now use:
//SMF DD DSN=SMF.TYPE74.ONLY,DISP=SHR
//TYPE74 DD DSN=YOUR.TYPE74.PDB,DISP=NEW
//TYPE74CA DD DSN=YOUR.TYPE74CA.PDB,DISP=NEW
%INCLUDE SOURCLIB(TYPE74);
%LET PDB74=TYPE74;
_STY74
%LET PDB74CA=TYPE74CA;
_STY74CA
The _STY74 macro definition (in member IMAC74) is:
MACRO _STY74
PROC SORT NODUP DATA=_LTY74
OUT=&PDB74..TYPE74 ;
BY SYSTEM STARTIME DEVNR SMFTIME;
%
so it uses the _LTY74 name to get the location of the
unsorted TYPE74 dataset, and sorts it into the new
&PDB74 macro for the DDname that was just added by
Change 15.320.
(The %VMXGFOR macro, needed so that PROC SORT's FORCE
option is used so that you can SORT when OBS= is not
OBS=MAX, has double percent signs because it is inside
an old-style MACRO definition).
A later MXG Technical note will discuss other examples.
Only those IMACs for products that are in the default
BUILDPDB/BUILDPD3 now have _Sxxxyyy macros, but over time
I hope to provide an _S macro with the MXG "recommended"
sort order for every MXG dataset. At the present time,
none of the _S macros are used in the BUILxxxx members.
Thanks to Billy Westland, Litton Computer Services, USA.
Change 15.327 APAR OW28921 adds a volume segment to type 42 subtype 11
VMAC42 XRC (eXtended Remote Copy) SMF records, but the volume
Jan 7, 1998 data is present only if the volume being copied is in a
duplex state. I need sample data records before I can
proceed to add support for that APAR, so if you can send
sample data for a duplexed volume copied with XRC, do it!
Change 15.326 Cosmetic. Labels were added for variables DCSNAME and
NTINTRV PRODTYPE and NRCPUS, andNRCPUS is now kept in dataset
VMACNTSM NTCONFIG. In NTINTRV, variables DCPQUED and DCPRATE are
Jan 7, 1998 now correctly spelled as DPCQUED and DPCRATE.
Change 15.325 The number of RACF DTP (44) segments kept is increased
VMAC80A from 6 to 12 for RACFEVNT 10 and 13, and the MXG message
Jan 7, 1998 was relocated so the total count in the record is now
printed. See Change 15.289.
Thanks to Tom Parker, Hogan Systems, USA.
Change 15.324 DCOLLECT cluster records do not contain a VOLSER, but the
VMACDCOL Variable DCDVOLSR is now RETAINed from the preceding
Jan 7, 1998 dataset record (DCURCTYP='D', for DCOLDSET dataset) so
that dataset DCOLCLUS now contains DCDVOLSR.
Thanks to John W. Etter, StorageTek, USA.
Change 15.323 All packed decimal inputs are now protected with ?? input
VMACZARA modifier so that hex zeros won't create a SAS log note.
Jan 5, 1998 The file record contains System ID at location 295, so
new variable FILESYST is now created. Both statements
IF FILEDATL=0 THEN DATECR=.; were typos and now read:
IF FILEDATL=0 THEN DATELU=.;
Thanks to Harry Olschewski, DeTeCSM/SES, GERMANY.
Change 15.322 MXG 15.07 only. Remove SMTNTASK from the KEEP statement
ANALCISH 91 lines after DATA &MXGDS1. Change SMTRANI to SMSTRNI
Jan 3, 1998 in all 57 occurrences.
Change 15.321 Some variables in RMF III VSAM processing were wrong.
VMACRMFV -In dataset ZRBASI, variables ASITOTSV, ASISVINR, ASIGSPPI
Jan 3, 1998 and ASIGASPD were wrong because ASICUSE, ASITOTD, and
ASISRVO should have been input as &PIB.4. instead of as
&PIB.2. New variables ASIOREPL, ASIOTOTU, and ASIIOU
(new with OS/390 R1.1) are now created in ZRBASI.
-In dataset ZRBGEI, variables GEIWLMTK and GEISPLXI should
be input $EBCDIC8. instead of $CHAR8. (but under MVS the
results are the same; only if you run MXG under ASCII SAS
would you have noticed the error). Variable PCTCPUBY is
now always missing, as its source field GEICPUOL is now
reserved in OS/390.
Thanks to Joe Faska, Depository Trust, USA.
Thanks to Peggy Dunne, Depository Trust Company, USA.
Change 15.320 All hardcoded references to "PDB" as a DDNAME are now
DOC replaced with a macro variable, &PDBxxxx, so that each
VMXGINIT datasets can be re-directed to a different DD if needed.
Jan 2, 1998 For example, if you want to write the TYPE74 dataset to
Jan 12, 1998 a separate DDname of MY74, you would use:
%LET PDB74=MY74; %INCLUDE SOURCLIB(BUILDPDB);
to create dataset MY74.TYPE74 in the MY74 Libref.
A separate &PDBxxxx macro exists for each dataset in the
PDB architecture. The macro &PDB and "PDB." were changed
to &PDBMXG macro name. All of the &PDBxxxx macros have a
default value of "PDB". VMXGINIT defines these macros:
%MACRO VMXGINIT(DEFAULT=PDB);
%LET PDBMXG =&DEFAULT;
%LET PDB0 =&DEFAULT; /*TYPE0 >> PDB.IPLS */
%LET PDB0203=&DEFAULT; /*TYPE0203 */
%LET PDB6 =&DEFAULT; /*TYPE6 */
%LET PDB21 =&DEFAULT; /*TYPE21 >> PDB.TAPES */
%LET PDB25 =&DEFAULT; /*TYPE25 (JES3 ONLY) */
%LET PDB30UD=&DEFAULT; /*TYPE30_D >> PDB.DDSTATS*/
%LET PDB30UV=&DEFAULT; /*TYPE30_V >> PDB.SMFINTRV*/
%LET PDB30U1=&DEFAULT; /*TYPE30_1 */
%LET PDB30U4=&DEFAULT; /*TYPE30_4 */
%LET PDB30U5=&DEFAULT; /*TYPE30_5 */
%LET PDB30U6=&DEFAULT; /*TYPE30_6 */
%LET PDB30OM=&DEFAULT; /*TYPE30OM */
%LET PDB30MU=&DEFAULT; /*TYPE30MU */
%LET PDB70 =&DEFAULT; /*TYPE70 */
%LET PDB70PR=&DEFAULT; /*TYPE70PR */
%LET PDB71 =&DEFAULT; /*TYPE71 */
%LET PDB72 =&DEFAULT; /*TYPE72 */
%LET PDB72GO=&DEFAULT; /*TYPE72GO */
%LET PDB72DL=&DEFAULT; /*TYPE72DL */
%LET PDB72MN=&DEFAULT; /*TYPE72MN */
%LET PDB72SC=&DEFAULT; /*TYPE72SC */
%LET PDB7204=&DEFAULT; /*TYPE7204 */
%LET PDB73 =&DEFAULT; /*TYPE73 */
%LET PDB73L =&DEFAULT; /*TYPE73L */
%LET PDB73P =&DEFAULT; /*TYPE73P */
%LET PDB74 =&DEFAULT; /*TYPE74 */
%LET PDB74CA=&DEFAULT; /*TYPE74CA */
%LET PDB74CF=&DEFAULT; /*TYPE74CF */
%LET PDB74ST=&DEFAULT; /*TYPE74ST */
%LET PDB74TD=&DEFAULT; /*TYPE74TD */
%LET PDB75 =&DEFAULT; /*TYPE75 */
%LET PDB77 =&DEFAULT; /*TYPE77 */
%LET PDB78 =&DEFAULT; /*TYPE78 */
%LET PDB78CF=&DEFAULT; /*TYPE78CF */
%LET PDB78CU=&DEFAULT; /*TYPE78CU */
%LET PDB78IO=&DEFAULT; /*TYPE78IO */
%LET PDB78PA=&DEFAULT; /*TYPE78PA */
%LET PDB78SP=&DEFAULT; /*TYPE78SP */
%LET PDB78VS=&DEFAULT; /*TYPE78VS */
%LET PDBTMNT=&DEFAULT; /*TYPETMNT */
%LET PDBTSWP=&DEFAULT; /*TYPETSWP */
%LET PDBTALO=&DEFAULT; /*TYPETALO */
%LET PDBNJEP=&DEFAULT; /*PDB.NJEPURGE*/
%LET PDBJOBS=&DEFAULT; /*PDB.JOBS */
%LET PDBSTEP=&DEFAULT; /*PDB.STEPS*/
%LET PDBPRIN=&DEFAULT; /*PDB.PRINT*/
%LET PDBRMFI=&DEFAULT; /*PDB.RMFINTRV*/
The &DEFAULT macro argument in VMXGINIT exists so that
SAS ITSV product can send all datasets to the //WORK
file and then later copy them to their //DIRECT libref.
This eliminated the needs discussed in Change 15.272.
It is unlikely anyone else will need to use that option.
Since the default value for all of these macros is "PDB",
the change should be completely transparent to MXG users.
However, users of SAS ITSV Version 2.0 and SAS/CPE must
install this circumvention with MXG 15.08 or later:
The following two lines of code must be inserted
immediately before any %CMPROCES invocation:
%INCLUDE SOURCLIB(VMXGINIT);
%VMXGINIT(DEFAULT=WORK);
Version 2.1 of ITSV does not need this circumvention.
Change 15.319 Cosmetic. Data set Labels were added to VMAC members to
BUIL3005 label datasets TYPE0203, TYPE7, TYPE21, TYPE75, and
BUILD005 TYPE7204, and Labels for datasets PDB.JOBS, PDB.STEPS,
BUILDPD3 PDB.PRINT, PDB.SMFINTRV and (JES2-only) PDB.NJEPURGE were
BUILDPDB added in the BUILxxxx members. The labels in BUILxxxx
DIFFDB2 members now contain BUILDPDB/BUILDPD3/BUILD005/BUIL3005
RMFINTRV so you can tell exactly which member created your PDB
VMAC0203 library! Data set Label for RMFINTRV was added, and in
VMAC21 DIFFDB2 labels were added for the de-accumulated
VMAC7 statistics datasets (and they too indicate DEACCUM versus
VMAC7072 the RAW tag now used in VMACDB2 for those same datasets).
VMAC75 Data set labels are passed from input to output by PROC
VMACDB2 SORTs, so only DATA steps were labeled.
Dec 31, 1997
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 15.318 Cosmetic. Comments were updated to list all of the MXG
IMACACCT members that contain account fields and thus include
Dec 31, 1997 member IMACACCT:
VMAC20 VMAC26J2 VMAC26J3 VMAC30 VMAC33 VMAC434
VMAC535 VMACBETA VMACDB2 VMACNAF VMACORAC VMACSFTA
VMACTSOM VMACXPSM XTYPEMVT XTYPEVS1
Thanks to Charlie Bloemker, Lockheed-Martin, USA.
Change 15.317 ML-15 of ASMTAPES does not run under MVS/ESA 4.2 or any
ASMTAPES earlier release of MVS; in fact, the monitor program
Dec 31, 1997 will loop under that archaic release. If you are still
stuck with a back level MVS, use the back level ASMTAPES
or ASMTMNT until you upgrade your MVS.
Thanks to Scott Snyder, First Data Merchant Services, USA.
Change 15.316 Support for OS/400 Release 4.1.0 (INCOMPATIBLE in three
VMACQAPM datasets - QAPMETH, QAPMIDLC, and QAPMLAPD, because field
Dec 30, 1997 lengths were changed and/or reserved fields were deleted)
but the other "important" datasets were not changed.
This support is based on examination of DSECTS, but has
not been absolutely verified with AS400 4.1 data yet.
Thanks to Len Marchant, Coca Cola, USA.
Change 15.315 Major enhancement in architecture of ASUMUOW program that
ASUMUOW merges/sums CICSTRAN and DB2ACCT into one observation for
IMACUOW each unit of work. Member IMACUOW now defines new macro
Dec 30, 1997 _TRANUOW that allows you to determine which CICS trans
record is used to supply TRANNAME in the PDB.ASUMUOW data
set that is created by ASUMUOW. For some environments,
the TRANNAME wanted is the first transaction to end, but
with CICS under OS/2, the first transaction name is CPMI
and that mirror name is not the desired transaction name.
Comments in IMACUOW and ASUMUOW discuss the three choices
that now exist, and other tailoring options.
Note that while ASUMUOW is automatically included in the
JCLPDB6 example, so that dataset PDB.ASUMUOW will be
created by default, the dataset PDB.ASUMUOW will contain
zero observations until you tailor member IMACUOW; that
way, there is no sort of CICSTRAN and DB2ACCT until you
tell MXG you want to create observations in PDB.ASUMUOW.
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 15.314 Cosmetic corrections (duplicate variable name in KEEP,
DOC FORMAT, INFORMAT, or incorrect comment statement naming
Dec 30, 1997 dataset OUTPUT, etc., were corrected in members:
EXAIMRA EXAIMRD EXAIMRP EXAIMRR EXAIMRT EXAMIRS
EXHPTEAP EXHPTECO EXHPTEDS EXHPTEGL EXHPTELA EXHPTEPR
VMAC102 VMAC110 VMAC7072 VMAC99 VMACAIMR VMACCMFV
VMACCTCP VMACDCOL VMACEREP VMACHBUF VMACHURN VMACNSPY
VMACOMVT VMACSARX VMACTCP VMACTMO2 VMACTUX VMACVMXP
VMACXPSM
Thanks to Fredie Arie, Lone Star Gas, USA
Change 15.313 Support for ICSS SMF type 103 (Internet Connection Secure
DIFF103 Server, V2R2, but soon it will be renamed to Domino GO
EXTY1031 Webserver V2R4, with no change in the record format).
EXTY1032 Two new datasets are created for this webserver:
IMAC103 Subtype Dataset Name Description
TYPE103 1 TYPE1031 ICSS Configuration
VMAC103 2 TYPE1032 ICSS Performance
VMACSMF Many Configuration Values are decoded by formats.
Dec 20, 1997 Member VMACSMF had to be updated, because the SMF 103
Jan 14, 1998 record does not correctly set the second bit in the
Feb 20, 1998 first byte ("record has subtype field" bit). The
TYPE1032 Performance record contains request counts like
bytes received/sent, but there is no interval duration in
the IBM record. As a result, member DIFF103 was required
(it is automatically invoked by TYPE103) to create the
interval duration variable DURATM. Although the record
default interval is 15 minutes when the logging queue is
full, if the server activity is minimal the logging
queue fills more slowly and the DURATM will be much
longer than the expected 15 minutes
Note that if you add 103 processing to BUILDPDB, you will
need to %INCLUDE the DIFF103 member in your EXPDBOUT
member to create DURATM in dataset TYPE1032.
The TYPE1032 Performance Data is actually an SNMP MIB
with an SMF header; I suspect we will see many future
SMF records based on Simple Network Measurement Protocol
Measurement Information Blocks!
New information Feb 20, 1998: IBM is fixing the problem
in the SMF 103 records and the fix should be in Lotus
Domino Go Webserver 5.0 (LDGW) with GA in May, 1998. As
I don't have the DSECT changes yet, you will need to get
the then-current version of MXG to process the revised
records (which should eliminate the need for DIFF103).
Thanks to Peter Skov, Jyske Bank, DENMARK.
Change 15.312 MXG 15.07 only. In VMXGINIT, a semi-colon is missing
ChangeS after '15.07' in the %LET MXGVERS=15.07 statement, which
VMXGINIT causes an ERROR message and variable MXGVERSN in TYPE70
Dec 19, 1997 to be missing. Also, the date in CHANGES was 17Dec97,
but the real date (in VMXGINIT) was 18Dec97.
======Changes thru 15.311 were in MXG 15.07 dated Dec 17, 1997======
Change 15.311 Support for Fujitsu's AIM Version V20 SMF records adds
VMACAIM2 several fields to the existing AIM and AIM/NDB records,
VMACAIM6 and new datasets from AIM/RDBII's type 98 SMF record
VMACAIM7 with member TYPEAIMR. Datasets are now labeled and
VMACAIMR alphabetized, and INPUT statements were collimated, but
TYPEAIMR the real logic changes were discovered and contributed
IMACAIMR by the cited codesharks!
EXAIMRT Logic changes (i.e., incompatibilities between V12 and
EXAIMRS V20) were made in VMACAIM2 and VMACAIM6 and the new
EXAIMRP VMACAIMR. The other VMACs were changed only by adding
EXAIMRD existing variables to the KEEP= list or deleting dead
EXAIMRB variables from the KEEP= list.
EXAIMRR
EXAIMRA
Dec 18, 1997
Thanks to Ian Heaney, Toyota Australia, AUSTRALIA.
Thanks to D. Ackland, Toyota Australia, AUSTRALIA.
Change 15.310 In ANALCISH reports, "Wait on String - Peak" value was
ANALCISH not the maximum, because it was in the SUM= argument.
Dec 16, 1997 Move variable name A17DSHSW from the SUM= to MAX=.
Thanks to Dale Slaughter, Allied Group Insurance, USA.
Change 15.309 RACF record from 1.0.9.2 caused INPUT STATEMENT EXCEEDED
VMAC80A record, because 3 bytes were documented in Table 4 for
Dec 16, 1997 Event Code 25 (19x), RVARY, but this record contained
only two bytes, so the third byte is now conditionally
input. Change the INPUT to read:
KW25OVIO $CHAR1. /*FLAGS FOR*OTHER*VIOLATIONS*/
@;
IF RACFDLN GE 3 THEN INPUT /* UNDOC RACFDLN=1 FOUND */
KW25ADSP $CHAR1. /*OTHER*KEYWORDS*SPECIFIED*/
Thanks to Len Rugen, University of Missouri-Columbia, USA.
Change 15.308 I changed the CICSEXCE exception dataset when CICS/ESA
IMACCICS was introduced, but I can't find where I really discussed
Dec 16, 1997 the changes to variables. Non-ESA CICS (2.1 & earlier)
had specific variables for each exception, and those only
the variables specific to an exception were non-missing
in a particular observation. But these specific vars
are always missing with CICS/ESA or CICS/TS:
ISAMFILE MSREQWT MSWAITCN MSWAITTM PGMCMPTM
PGMCMPCN SCWTECN SCWTETM TSREQWT TSWAITTM
TSWAITCN VSAMBUFF VSAMFILE VSWAITTM VSWAITCN
because CICS/ESA has one set of variables and their
values describe the exception event and durations:
EXWAITTM - Duration of the exception wait.
EXCMNRTY - Exception Resource Type:
STORAGE FILE TEMPSTOR
EXCMNRID - Exception Resource Identification:
UDSA GLLCLAS FDED
EXCMNTYP - Exception Type (format MG110EX.):
'X01:WAIT (EXCMNWT)'
'X02:BUFFER WAIT (EXCMNBWT)'
'X03:STRING WAIT (EXCMNSWT)'
Exception Exception
Resource Resource
Exception Type Type Identication
EXCMNTYP EXCMNRTY EXCMNRID
'X01:WAIT (EXCMNWT)' STORAGE UDSA
'X02:BUFFER WAIT (EXCMNBWT)' FILE B0INDEX
'X03:STRING WAIT (EXCMNSWT)' TEMPSTOR FDED
This allows for new exception events to be created by IBM
with no need to create new variables for each exception.
Thanks to Dale Slaughter, AMCO Insurance, USA.
Change 15.307 ASUMUOW could produce missing value for MROTRAN count, as
ASUMUOW "spun" observations were not properly reintroduced in the
Dec 16, 1997 next run. Logic involving several lines was revised.
Thanks to Larry Nova, First Card, USA.
Change 15.306 CONTROL-T variables DSUSECT and DSEXCP in CTLTDSN dataset
VMACCTLT were wrong; there are three undocumented bytes before the
Dec 14, 1997 DSUSECT field. Add +3 after INPUT before DSUSECT:
INPUT +3 DSUSECT &PIB.4. ....
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 15.305 Support for DPPX/370 (Release 4) Performance Reporter
TYPEDPPX creates eleven datasets in this user contribution, by
Dec 14, 1997 reading and decoding the report output as MXG input.
DPPX/370 (Distributed PRocessing Programming Executive)
runs on ES/9000 series and was written by IBM, originally
for 8100, then 9370, and then 9221. Release 4 is the
last release and goes out of service in 1998/1999.
Thanks to Mark Robbins, W.H. Smith LTD, ENGLAND.
Change 15.304 Using 14/15 records to determine the size of datasets
ADOC1415 is not straightforward. Descriptions in ADOC1415 have
Dec 14, 1997 been revised based on Richard's discoveries:
I've recently completed a study where I used TYPE1415
data to analyze our tape use and develop a model for
sizing a VTS subsystem we are considering. In the course
of this, I found myself looking at BLKSIZE, BLKCOUNT,
TRKSALOC, and TRKREL to develop a size in megabytes for
these files. Multi-volume files, both tape and disk,
presented a challenge to correctly accumulate the
multiple type 15 records generated into a single record
representing the creation of the entire file.
RECIND1, bit 1 x'40' 'Record written by EOV'
This bit is ON for records written for a change-in-volume (written
by "End-of-Volume", LASTVOFL=' ' if ON), and this bit is OFF for
records written by close (LASTVOFL='Y' if OFF). When ON (EOV),
this is normally a volume switch within a multi-vol dataset.
Rick thinks this may also occur for file 1 through n-1 for a
sequence of n datasets concatenated on a single DDname, but has
not seen that in his data, and he has not prove whether or not
this bit would be on for the first of two files concatenated
together, which happened to reside on the same volume.
If you can confirm/deny his thesis, I will update this note.
TRKSALOC
This is the number of tracks allocated *on the current volume* to
this dataset. This must be accumulated across multiple TYPE15s
when RECIND1, bit 1 is on.
TRKREL
This is the number of tracks released at close. In the case of
RECIND1, bit 1, this will be zero for all but the last record.
Note however, that this last record does *not* have the EOV bit on.
BLKSIZE
No surprise here. Same for all related records.
BLKCNT
Again, these represent the block count written on the current
volume only. Must be accumulated to get accurate file size.
Performing the accumulation.
Because of the fact that the last record for a given step/DD does
*not* have the EOV bit on, this flag is really not useful to group
records to accumulate. I finally arrived at the following PROC
SUMMARY to accomplish the task:
PROC SORT DATA=TYPE1415;
BY JOB OPENTIME DSNAME SMFTIME;
/*ELIMINATE DUPLICATE RECORDS (MULTI-VOL INTERMEDIATE EOV)*/
PROC SUMMARY DATA=TYPE1415 NWAY;
BY JOB OPENTIME DSNAME;
VAR SMFTIME BLKCNT TRKSALOC TRKREL;
ID AVGBLK ID DEVICE BLKSIZE ;
OUTPUT OUT=SUM1415
MAX(SMFTIME)= SUM(BLKCNT TRKSALOC TRKREL)=;
DATA SUM1415; SET SUM1415;
IF AVGBLK NE 0 THEN MBUSED = AVGBLK * BLKCNT;
ELSE MBUSED = BLKSIZE * BLKCNT;
FORMAT MBUSED MGBYTES.;
(AVGBLK is usually zero, so BLKSIZE is usually used.)
Thanks to Richard T. Green, Comerica Incorporated, USA.
Change 15.303 Revised text, 14May2003: MXG's default _M204VER value in
VMACM204 member VMACM204 (4.1, since 1997) is also valid for 5.xt
Dec 14, 1997 Release, as there were no changes to their SMF records.
May 14, 2003 Original Change text, slightly revised.
Support for MODEL204 Version 4.1 or later added two bytes
at the end of the header. Version-based logic was added
to skip over the bytes, and MXG updated VMACM204 so that
the default is now 4.1. Also, a number of variables
added by Version 3.2 were added to the KEEP= list for the
M24SINCE dataset. The new version is INCOMPATIBLE due to
the insertions in the record.
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Thanks to Carole J. Storby, Lockheed Martin, USA.
Change 15.302 With very large DASD farms, ASMVVDS could run out of
ASMVVDS storage, because it FREEMAINed less than it GOTMAINed.!
Dec 14, 1997 Not only was that corrected,, but also optional supports
UCBs above the 16M line, and now executes in AMODE 31.
Additional cleanup of this old programs for sites that
need detail VVDS info (or don't have DCOLLECT).
Thanks to Skip Abadie, MBNA, USA.
Change 15.301 The counts in the starting/ending intervals were usually
ASUMTALO wrong, because spun records ("inflight allocations") were
Dec 14, 1997 kept after output and were counted by the summary logic!
This caused MAXDRVS to be greater than installed devices.
Fortunately, the effect was only for the beginning and
ending interval of the analysis, so the effect should
have been minimal on your analysis.
-After IF ALOCEND GT &LOWTIME THEN OUTPUT SPIN.SPINTALO;
insert ELSE DO; and then after fourteen lines, insert
END; before the PROC SORT DATA=TALOSUM1....;
This corrects the basic error in logic.
-Additionally, LASTTIME was used as a temporary variable,
but was not dropped, and then used in adjusting for clock
synchronization. Now it's DROPped:
After RETAIN HOLDEND LASTTIME 0;
insert DROP LASTTIME;
-In addition, the PROC PRINT DATA=TALOSUM1, WHERE, and VAR
statements left for debugging were deleted.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 15.300 Support for SAR CA-VIEW Selection Request Exit SARSRQUX
EXTYSARX SMF record creates new dataset SARSRQUX.
IMACSARX
TYPESARX
VMACSARX
Dec 14, 1997
Thanks to Tim Haiar, Citicorp, USA.
Change 15.299 TYPE70PR PR/SM dataset did not contain an observation for
VMAC7072 partitions that were deactivated (LPARCPUS=0), and some
Dec 13, 1997 sites have needed an observation for that LPARNAME for
configuration reports. Replace DO J=1 TO LPARCPUS; with
IF LPARCPUS=0 THEN DO; %%INCLUDE SOURCLIB(EXTY70PR);END;
ELSE DO J=1 TO LPARCPUS;
If you do NOT want observations for deactived partitions,
you could delete the obs with LPARCPUS=0 in EXTY70PR!
Thanks to Harmuth Beckmann, Karstadt AG, GERMANY
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 15.298 ERROR: VARIABLE TERMINAL NOT FOUND in these sample CICS
ANALCICS reports occurs when _LCICTRN sends CICSTRAN to //WORK
Dec 13, 1997 instead of to the //CICSTRAN DD, because the report code
used OUT=CICSTRAN for the first PROC SORT with a KEEP=
statement, so a later reference to _LCICTRN got the OUT=
dataset instead of the original CICSTRAN data. Change
CICSTRAN to SORTTRAN (four places) to correct this error.
I also added KEEP= logic to each input of _LCICTRN to
reduce input data read, but the reports will be re-done
using ANALCNCR to much more expeditiously count the CICS
concurrent users.
Thanks to Doug Jungels, Fingerhut Corporation, USA.
Thanks to James Lieser, Fingerhut Corporation, USA.
Change 15.297 Variables VELOCITY, VELOCCPU, and VELOCIOD were 0 to 1 in
ANALRMFR TYPE72 and TYPE72GO datasets, but were multiplied by 100
TRND72GO in ANALRMFR reports where they matched IBM report values.
VMAC7072 But I now realize they should be 0 to 100 in both the IBM
Dec 13, 1997 report and the MXG datasets, so their values are changed.
-In VMAC7072, four lines VELOCITY=... are VELOCITY=100*...
and ELSE VELOCIOD= is now ELSE VELOCIOD=100*
and PERFINDX=R723CVAL/VELOCITY; has its 100* removed.
-In ANALRMFR, the VELOCITY=100*VELOCITY; was removed.
-In TRND72GO, 100* was added to VELOCITY= and the 100*
was removed in the denominator of PERFINDX= calculation.
Thanks to Ken Williams, Southern Electric, ENGLAND.
Change 15.296 Support for Omegamon for VTAM V400 (COMPATIBLE, but new
EXOMVX2L subtypes and exceptions will print "invalid" messages on
EXOMVX2M the SAS log). Three new subtypes create datasets:
EXOMVX2V Subtype Dataset Description
IMACOMVT 15 OMVTX2MC X.25 MCH Link
VMACOMVT 16 OMVTX2VC X.25 VC
Dec 4, 1997 17 OMVTX2LU X.25 LU
There are also nineteen new exceptions, 0939-0957 that
are now decoded.
Thanks to Joseph E. Darvish, Farmers Insurance Group, USA.
Change 15.295 The ACCOUNTn variables in DB2ACCT did not decode skipped
VMACDB2 fields correctly. DB2 replaces the comma delimiters in
Dec 3, 1997 the job card with 'FF'x, and (TOMP,9999,XXX,,,ACCT6) had
variable ACCOUNTn = 'FFFF'xACCT6. Each of the nine
DO groups in VMACDB2 that read:
IF LOC LE 1 THEN DO;LENACCTn=ACCTLEFT;ACCTLEFT=0;END;
were replaced with
IF LOC EQ 1 THEN DO;LENACCTn=0;ACCTLEFT=ACCTLEFT-1;END;
ELSE IF LOC LT 1 THEN DO; LENACCTn=ACCTLEFT;ACCTLEFT=0;
END;
to properly parse the 'FF'x delimiter.
Thanks to Tom Parker, CSC Financial Services Group, USA.
Change 15.294 Change 15.054 intended to have four blanks after SYSTEM
TYPETMON and SYSID, but ended up with five, so SYSID became length
Dec 3, 1997 five instead of four.
Thanks to Jim Wertenberger, Medical Mutual of Ohio, USA.
Change 15.293 SAS Option YEARCUTOFF=1960 is MXG's default specification
CONFIG in member CONFIG, as this makes MXG more robust in its
YEAR2000 attempt to protect non-Y2K-compliant dates. In MXG 15.05
YEAR2000 I added code to protect records written in 2000 that do
Dec 3, 1997 not have the "century value" in julian dates, or still
have only 2 year digits in YYMMDD-type date fields.
I thought I could protect non-Y2K-compliant fields after
the input of the date, by detecting that the year was
pre-1960, and then I could add the number of days between
1900 and 2000 to move the non-Y2K date into the second
millennium.
I now know it is impossible to correct all cases after
the field has been INPUT, because some date values will
be missing after INPUT, because some dates that are valid
in 2000 were invalid in 1900:
non-Y2K value Informat Y2K date
000229 YYMMDD6. 29FEB2000
'000000000000366F'x SMFSTAMP8. 31DEC2000
The YYMMDD6 is in error because there was no leap year
day in 1900, and the SMFSTAMP8 is in error because there
were only 365 days in the year 1900.
The YYMMDD6 error can be eliminated by changing the SAS
default YEARCUTOFF=1900 to YEARCUTOFF=1960, because then
SAS will accept 000229 as Feb 29, 2000; this will also
eliminate the need for the MXG protection logic.
I had been reluctant to base MXG's support of the year
2000 on any SAS option, believing I could provide safer
protection that would function independent of the SAS
YEARCUTOFF option's value. However, it now appears
that the best choice is to make YEARCUTOFF=1960 the
value set in MXG's CONFIG member, and that was done.
The SMFSTAMP8 error cannot be eliminated because the
YEARCUTOFF option does not apply to those julian date
informats, and making it apply is likely to cause more
exposure to error than it is worth. However, SAS
Institute will consider enhancing the SMFSTAMP, RMFSTAMP,
etc., formats to provide this functionality internally,
and it may be available (in a future TS-level maintenance
release).
Fortunately, the logic added by Change 15.167 (that will
be removed) has no impact on present dates and thus
causes no errors until after 1999.
These notes are just for the record:
Change 15.167 used 36524 as the constant number of
days between 1900 and 2000 for YEARSECS, but it turns
out that the number of days to add is not a constant:
For dates in 2000:
01JAN1900 + 36524 = 01JAN2000
01MAR1900 + 36524 = 29FEB2000
That '29FEB2000' might look wrong, but the 60th
julian date of 1900 was 01MAR1900, and the 60th
julian date of 2000 is 29FEB2000, so it is ok!
For dates in 2001
01JAN1901 + 36524 = 31DEC2000
which is definitely wrong; a value of 36525 should
have been used for years after 2000!
Thanks to Nico Lenaerts, SAS Institute, BELGIUM.
Thanks to Michel Laublin, GIB, BELGIUM.
Change 15.292 The example extract command for HP MeasureWare from HPUX
ADOCMWUX statements GBL_BYDISK_ID_LIST and GBL_BYLAN_ID_LIST that
Dec 1, 1997 caused "unknown metrics" error; the statements should
not have been in the example and were deleted.
Thanks to Thierry Van Moer, Procter & Gamble, BELGIUM.
Change 15.291 MXG 15.06 did not contain ML-15 of ASMTAPES. While the
ASMTAPES comments in the member said it was ML-15, in fact it was
Dec 1, 1997 still ML-14 with only comments changed, and when Started
it said it was ML 14! The wrong member was copied into
15.06 and then its comments were edited. This change
really is the ML-15 that was promised, and when it is
Started it actually says that it is ML-15!
Thanks to Glenn Harper, Memorial HealthCare System, USA.
Thanks to Mark Smith, First Card, USA.
Change 15.290 Documentation only. Minor corrections to variables in
ADOCNTSM datasets RASPORT (CONNTOTL did not belong in list),
Dec 1, 1997 NETWINTR (INTRNAME was not listed), IMAGE (IMAGFILE and
IMAGNAME are CHAR 32), and IP (DEVNAM did not belong).
Thanks to Bob Gauthier, American Stores Company, USA.
Change 15.289 MXG keeps only one RACF DTP (44) segment's variables
VMAC80A until multiple segments are actually found in RACF data,
Dec 1, 1997 and then the (usually unimportant) EV44xxxx variables
are added to the KEEP= list for that event. This change
adds six sets of EV44xxxx variables for RACFEVNT=13 (six
were previously kept for RACFEVNT=10), and clarifies the
text of the message printed when new segments are found.
All of this, just to save a little disk space!
Thanks to Gerald Lawrence, ABN AMRO Bank NV, THE NETHERLANDS.
Change 15.288 MXG 15.06 only. Label for variables LOSMCNTR & LOIOCOMP
VMAC16 were too long, causing warning on SAS log but no error.
Nov 26, 1997
Thanks to Freddie Arie, Lone Star Gas, USA.
======Changes thru 15.287 were in MXG 15.06 dated Nov 24, 1997======
Change 15.287 Local and Remote IP addresses are now decoded into their
VMACCTCP dec.dec.dec.dec format in Clever TCP/IP's SMF record, and
Nov 24, 1997 are changed from numeric to character variables.
Change 15.286 Dataset TYPE30_6 is interval data for address spaces that
VMAC30 do not go thru full function startup (examples of JOBs
Nov 24, 1997 that create observations in TYPE30_6 are RASP,ALLOCAS,
IEFSCHAS,CONSOLE,SMXC,GRS,SYSBMAS,TRACE,PCAUTH,OMVSSTFS),
but the interval start times (SMF30ISS,SMF30IST) from
which GMT offset is calculated are missing, so SYNCTIME
in TYPE30_6 was always on the GMT clock. This change
uses a heuristic comparison of SMFTIME and SYNCTIME
to correct the hour-part of SYNCTIME if there is a
difference (inserted before the %INCLUDE of EXTY30U6):
SYNCTIME=SYNCTIME+3600*FLOOR((SMFTIME-SYNCTIME+1800)/3600);
but having the real GMT offset in the record
would have been better!
Thanks to Harmuth Beckmann, Karstadt AG, GERMANY
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 15.285 ML-15 of ASMTAPES MXG Tape Mount and Tape Allocation
ASMTAPES Monitor has two enhancements:
Nov 20, 1997 -Dump suppression. When MXGTMNT intercepts internal
ABENDS (usually do to a logically address space changing
states, often 0C4 or 0E0 ABENDS), now the SVC dump will
be suppressed, unless you enable the 'DEBUG=YES' option,
which will cause an SVC dump to be taken. However, a
logrec record will be created for all ABENDs, so it will
be possible to get some information if required.
-Step start date (INITTIME) year 2000 support relocated
the date from the ASID's JCT to the JCT Extension in
OS/390 Release 1.3 and above. If you are at OS/390 R1.3
or higher, you will need to change the default of 'ES5'
to 'ES6' when you assemble ASMTAPES to pick up the step
start date from the JCT Extension.
Change 15.284 INPUT STATEMENT EXCEEDED with an EREP record, CLASRC=40,
VMACEREP but flag bits indicate that the record was truncated, so
Nov 20, 1997 those bits are now tested before the INPUT statement so
the STOPOVER abend is eliminated.
Change 15.283 Additional CICS DFHSTUP "Shutdown" reports have been
ANALCISH added/revised in this iteration:
Nov 20, 1997 -CICSMDSA, CICSMS, and CICSMT "Storage Manager Statistics
were updated.
-CICDS uses CICS release SMFPSRVR for decision logic.
-CICAUSS adds new CICS 4.1 fields to detail/summarys.
-CICFCR "Files" report is complete.
Thanks to Steve Colio, CIGNA, USA.
Change 15.282 Variables BYTEREAD and BYTEWRIT in TYPE21 (which is
VMAC21 renamed to PDB.TAPES) are now formatted MGBYTES.
Nov 19, 1997
Thanks to Chuck Hopf, MBNA, USA.
Change 15.281 Support for Landmark's The Monitor for CICS/ESA 2.0, a
ANALMONI completely INCOMPATIBLE reformatting of their records.
EXMONARQ You must now use program TYPETMO2 instead of TYPETMON to
EXMONAWT process the new records, but the MONITASK dataset that
EXMONCMX MXG creates should be compatible as only a few old
EXMONDBD variables were removed by LANDMARK, although there are
EXMONDSA many new ones.
EXMONDSP Landmark notes that the TD,TF,TM,TP,TS,TT,T2 and TX data
EXMONEXP is based on CICS statistics, while the TR record is part
EXMONIDS based on CICS stats and part based on data collected by
EXMONIRQ TMON; the TR record contains much of the non-volatile
EXMONIWT data previously written in the TI record. The MONISYST
EXMONMRO dataset may also be compatible, but some variables may
EXMONSYS have moved to the TR-record datasets, and some variables
EXMONT2 may be spelled differently if I did not recognize them!
EXMONT2E
EXMONTSK The meaning of the TI interval data has been changed.
EXMONTDQ Previously, data was posted to the interval as it was
EXMONTFI collected, leading to a highly accurate picture of the
EXMONTMC activity during that interval, but increasing the
EXMONTP collection overhead. Instead, in Version 2.0, the TI
EXMONTPD data is collected by rolling up the TA (Transaction End)
EXMONTPG event records into the interval in which they ended, so
EXMONTR the accuracy of each interval is lost! Landmark claims
EXMONTS "over time this results in the same statistics, but the
EXMONTSQ distribution across intervals may be different. In a busy
EXMONTTR CICS region the difference will be very small. In a
EXMONTX small test region discrepancies may be more noticeable".
EXMONTXN I seriously question the utility of interval data that
EXMONUSR does not represent the interval. It is not the
EXMONUTG busyness of the region but the long-running
EXMONXMC transactions that end from time-to-time that corrupt
IMACTMO2 their interval data, so all of the datasets created
TYPETMO2 from the TI record may be inaccurate.
VMACTMO2
Nov 19, 1997 Thirty MXG datasets are created from the new records:
Record Description
TA - Transaction Performance Record
TD - Transient Data Interval Record
TF - File Interval
TI - Transaction Activity Interval Record
TM - MRO/ISC Interval Record
TP - Program Interval Record
TR - Region Interval Record
TS - Temporary Storage Interval Record
TT - Terminal Interval Record
TX - Transaction Interval Record
T2 - DB2 Interval for CICS Record
Record Segment MXG Dataset
TA ARQ MONIARQ
AWT MONIAWT
DSP MONIDSP
DBD MONIDBDS
MRO MONIMRO
USR MONIUSR
UTG MONIUTG
TAS MONITASK
TD TDQ MONITDQ
TF TFI MONITFI
TI SYS MONISYST
CMX MONICMX
IDS MONIIDS
IRQ MONIIRQ
IWT MONIIWT
TM TMC MONITMC
TP TP MONITP
TPD MONITPD
TPG MONITPG
TR TR MONITR
DSA MONIDSA
EXP MONIEXP
XMC MONIXMC
TS TS MONITS
TSQ MONITSQ
TT TTR MONITTR
TX TX MONITX
TXN MONITXN
T2 T2 MONIT2
T2E MONIT2E
-ANALMONI's example reports using MONISYST were disabled
because many old variables no longer exist, and the old
examples weren't all that good, anyhow!
Change 15.280 Landmark's The Monitor for MVS Version 2.0 INCOMPATIBLE.
VMACTMV2 Essentially all records have been tested and do not fail.
IMACTMV2 Not all datasets have all variables decoded; as users
TYPETMV2 request them, they will be built. You must use member
Nov 19, 1997 TYPETMV2 instead of TYPETMVS for Version 2 records.
Thanks to Chris Taylor, VF, USA.
Change 15.279 MXG 15.04-MXG 15.05. DB2 report PMTRN01 caused APPARENT
ANALDB2R MACRO &SORTUOW UNRESOLVED, because Change 15.173 added a
Nov 18, 1997 new option to %ANALDBTR (UOWSORT=, that creates &SORTUOW
as a local macro variable), but old-style macro _TRANSIT
that is also defined in member ANALDBTR is also invoked
in ANALDB2R, but the &SORTUOW was local to %ANALDBTR and
did not exist when _TRANSIT was invoked. &SORTUOW is not
actually used by _TRANSIT, so the correction is to insert
%LET SORTUOW=; immediately before the _TRANSIT line.
Thanks to Tom Elbert, John Alden, USA.
Change 15.278 Calculation of B1HITRAT,B2HITRAT,B3HITRAT, and B4HITRAT
DIFFDB2 had mis-located parenthesis; there was no syntax error,
Nov 18, 1997 but the value was wrong. (Variable BPHITRAT was fine.)
The four calculations for the BnHITRAT variables need to
look like this
B1HITRAT=(QB1TGET-(QB1TSIO+QB1TDPP+QB1TLPP+QB1TSPP))/QB1TGET;
with all of the parens in the numerator.
Thanks To Yao-Chun Rickert, First National Bank of Chicago, USA.
Change 15.277 Under VM/CMS SAS, it is not possible to specify a MACLIB
INSTALL member in the CONFIG option, so the INSTALL instructions
Nov 18, 1997 for MXG under CMS were revised; now you can create the
CONFIGVM SAS A file from the copy file, and then use
SAS (NODMS CONFIG=CONFIGVM syntax.
Thanks to Sue Kent, CHEVRON, USA.
Change 15.276 IOA/Control-T 5.0 input of variable DSEXPDT was changed.
VMACCTLT If DSEXPTYP is 'C' or 'L', DSEXPDT is INPUT as PIB.4, as
Nov 18, 1997 if 'C' it is a numeric with the number of active cycles,
or if 'L' it is a numeric with the number of days since
last access; if 'D' or 'J' it is INPUT as PD4. as then
it is a date value.
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 15.275 SAP IMS timestamp SAPTIMTR must be used as the Start of
VMACIMSA Transaction, and the true End time is SAPTIMTR+SAPELTI.
Nov 17, 1997 Subtracting the SAPELTI from the Log Time produced bad
results; there appears to be a delay between the true
End time and the Log Time that is being examined.
The LABEL for SAPTIMTR now indicates "START TIME..."
Thanks to Cary Jones, Philip Morris, USA.
Change 15.274 Support for CICS TS 1.2 a/k/a CICS Transaction Server 1.2
EXCICD2G is INCOMPATIBLE because IBM inserted new fields into the
EXCICD2R middle of the Type 110 Subtype 1 Monitor (Transaction)
EXCICXQ1 record, instead of adding them at the end of the record!
EXCICXQ3 You must install this Change to process TS 1.2 records.
EXCICXQ3 In addition, new variables were added to CICSLGS Stats
FORMATS dataset, and five new (and important) interval statistics
IMACEXCL data sets are created with CICS TS 1.2, described below:
VMAC110 Dataset STID Description
Nov 15, 1997 CICD2G 102 DB2 Global Statistics
CICD2R 103 DB2 Resource Statistics
CICXQ1 121 Shared TS Queue Server Coupling Facility
CICXQ2 122 Shared TS Queue Server Buffer Statistics
CICXQ3 123 Shared TS Queue Server Storage Stats.
-New variables added to CICSTRAN dataset:
BRDGTRAN='BRIDGE*TRANSACTION*ID'
CPUTM ='TOTAL*CPU TIME*CAPTURED'
ICTOTCN ='IC START*CANCEL*DELAY*RETRIEVE*REQUESTS'
PCLURMCN='LINK URM*REQUESTS'
WTDWIOCN='DISPATCHABLE*WAIT*GIVE UP*DELAY*COUNT'
WTDWIOTM='DISPATCHABLE*WAIT*GIVE UP*DELAY*DURATION'
WTICIOCN='INTERVAL*CONTROL*DELAY*COUNT'
WTICIOTM='INTERVAL*CONTROL*DELAY*DURATION'
WTLMIOCN='LOCK*MANAGER*DELAY*COUNT '
WTLMIOTM='LOCK*MANAGER*DELAY*DURATION'
WTOTIOTM='TOTAL*OTHER*WAIT*TIME*DURATION'
WTSHIOCN='SHARED*TEMP STORE*DELAY*COUNT'
WTSHIOTM='SHARED*TEMP STORE*DELAY*DURATION'
WTTOIOTM='TOTAL*I/O*WAIT TIME*DURATION'
WTUNIOTM='UNCAPTURED*WAIT*TIME*DURATION'
WTWCIOCN='WAIT*CICS/EVENT*WAIT*DELAY*COUNT'
WTWCIOTM='WAIT*CICS/EVENT*WAIT*DELAY*DURATION'
WTWEIOCN='WAIT*EXTERNAL*WAIT*DELAY*COUNT'
WTWEIOTM='WAIT*EXTERNAL*WAIT*DELAY*DURATION'
-The CPUTM is TASCPUTM + RLSCPUTM, the sum of TCB and SRB
CPU time used by the transaction.
-Three very useful new Wait variables WTTOIOTM, WTOTIOTM
and WTUNIOTM are created in CICSTRAN based on IBM's
equations in the CICS Performance Guide an help explain
why a CICS transaction is waiting:
WTTOIOTM = Total I/O Wait Time, is the sum of:
WTTCIOTM+ Terminal Control I/O Wait
WTTSIOTM+ Temporary Storage I/O Wait
WTSHIOTM+ Shared Temporary Storage I/O Wait
WTTDIOTM+ Transient Data I/O Wait
WTJCIOTM+ Journal Control I/O Wait
WTFCIOTM+ File Control I/O Wait
WTRLIOTM+ RLS File I/O Wait
WTIRIOTM+ Interregion (MRO) I/O Wait
LU61IOTM+ LU 6.1 TC I/O Wait
LU62IOTM+ LU 6.2 TC I/O Wait
SZWAIOTM FEPI Suspend I/O Wait
WTOTIOTM = Total Other Wait Time, is the sum of:
DSPDIOTM+ First Dispatch Delay (MXT+TRANCLASS)
ENQDIOTM+ ENQ Delay
WTICIOTM+ Interval Control Delay
WTLMIOTM+ Lock Manager Delay
WTWEIOTM+ Wait External Wait
WTWCIOTM+ Wait CICS/Event Wait
WTDWIOTM+ Dispatchable or Give Up Wait
RMISIOTM RMI Suspend
WTUNIOTM = Uncaptured Wait Time, is calculated as:
WTUNIOTM=SUSPNDTM-(WTTOIOTM+WTOTIOTM);
The uncaptured time (time unexplained by any variable
in CICS) is the suspend time minus the DB2/IO wait time
and the CICS wait time. What can this uncaptured time
be? We have found in SAP/CICS MRO that if 2
transactions (an update task and dialog task) are
running in tandem, then the dialog task may wait until
the update task is complete and so this wait time is
uncaptured wait time due to it waiting for another task
to complete - monitor this closely, but in most
instances WTUNIOTM is zero.
-New variables added to CICLGS Statistics dataset:
LGSAUTOD='DATA*AUTO*DELETE*FLAG?'
LGSDONLY='DASD*ONLY*FLAG'
LGSMAXBL='MAXIMUM*BLOCK*LENGTH'
LGSRETPD='DATA*RETENTION*PERIOD'
LGSSTRUC='CF*STRUCTURE*NAME'
LGSSYSLG='SYSTEM*LOG*FLAG'
-New dataset CICD2G DB2 Global Statistics contains:
D2GABORT='ABORTS'
D2GACCOU='ACCOUNTREC*SETTING'
D2GATHID='STATIC*AUTHID'
D2GATHTY='AUTHTYPE'
D2GCALLS='CALLS*USING POOL'
D2GCOMIT='COMMITS'
D2GCONGM='CONNECT*TIME*GMT'
D2GCONLO='CONNECT*TIME*LOCAL'
D2GDB2ID='DB2*SYSID'
D2GDB2RL='DB2*RELEASE'
D2GDBCON='NAME*OF THE*DB2CONN'
D2GDISGM='DISCONNECT*TIME*GMT'
D2GDISLO='DISCONNECT*TIME*LOCAL'
D2GDSNAT='DSNC*STATIC*AUTHTYPE'
D2GDSNAU='DSNC*STATIC*AUTHID'
D2GDSNCC='DSNC*COMMAND*CALLS'
D2GDSNCU='DSNC*CURRENT*NUMBER OF*THREADS'
D2GDSNLM='DSNC*LIMIT*NUMBER OF*THREADS'
D2GDSNOV='DSNC*OVERFLOWS*TO POOL'
D2GDSNPK='DSNC*PEAK*NUMBER OF*THREADS'
D2GDSNSI='DSNC*SIGNONS'
D2GDSNTT='DSNC*THREAD*TERMINATES'
D2GPLEXI='PLANEXIT*NAME'
D2GPLNAM='STATIC*PLAN NAME'
D2GRDQCU='NUMBER OF*TASKS ON*READYQ'
D2GRDQPK='PEAK NUMBER*OF TASKS*ON READYQ'
D2GSIGNO='SIGNONS'
D2GSPCMM='SINGLE*PHASE*COMMITS'
D2GTCBCU='CURRENT*NUMBER*OF TCBS'
D2GTCBFR='CURRENT*NUMBER OF*FREE*TCBS'
D2GTCBHW='HIGH*WATER*MARK*OF TCBS'
D2GTCBLM='LIMIT*NUMBER*OF TCBS'
D2GTHRCU='CURRENT*NUMBER OF*THREADS'
D2GTHRLM='LIMIT*NUMBER OF*THREADS'
D2GTHRPK='PEAK*NUMBER OF*THREADS'
D2GTHRPR='THREAD*PRIORITY'
D2GTHRRE='THREAD*REUSES'
D2GTHRTE='THREAD*TERMINATES'
D2GTHRWA='THREAD*WAITS'
D2GTHWSE='THREADWAIT*SETTING'
D2GTRQCU='NUMBER OF*TASKS ON*TCB*READYQ'
D2GTRQPK='PEAK NUMBER*OF TASKS*ON TCB*READYQ'
D2GTSKCU='CURRENT*NUMBER OF*TASKS'
D2GTSKPK='PEAK*NUMBER OF*TASKS'
D2GTSKTO='TOTAL*NUMBER OF*TASKS'
-New dataset CICD2R DB2 Resource Statistics contains:
D2RABORT='ABORTS'
D2RACCOU='ACCOUNTREC*SETTING'
D2RATHID='STATIC*AUTHID'
D2RATHTY='AUTHTYPE'
D2RCALLS='CALLS*USING*DB2ENTRY'
D2RCOMIT='COMMITS'
D2RDBENT='NAME*OF THE*DB2ENTRY'
D2RPLEXI='PLANEXIT*NAME'
D2RPLNAM='STATIC*PLAN NAME'
D2RRDQCU='NUMBER OF*TASKS ON*READYQ'
D2RRDQPK='PEAK NUMBER*OF TASKS*ON READYQ'
D2RSIGNO='SIGNONS'
D2RSPCMM='SINGLE*PHASE*COMMITS'
D2RTHPCU='CURRENT*NUMBER OF*PROTECTED*THREADS'
D2RTHPLM='LIMIT*NUMBER OF*PROTECTED*THREADS'
D2RTHPPK='PEAK*NUMBER OF*PROTECTED*THREADS'
D2RTHRCU='CURRENT*NUMBER OF*THREADS'
D2RTHRLM='LIMIT*NUMBER OF*THREADS'
D2RTHRPK='PEAK*NUMBER OF*THREADS'
D2RTHRPR='THREAD*PRIORITY'
D2RTHRRE='THREAD*REUSES'
D2RTHRTE='THREAD*TERMINATES'
D2RTHRWA='THREAD*WAITS*OR OVERFLOWS'
D2RTHWSE='THREADWAIT*SETTING'
D2RTSKCU='CURRENT*NUMBER OF*TASKS'
D2RTSKPK='PEAK*NUMBER OF*TASKS'
D2RTSKTO='TOTAL*NUMBER OF*TASKS'
-New dataset CICXQ1 CICS Shared Temporary Storage Queue
Server Coupling Facility Statistics (i.e., how much of
the CF does each structure use) contains:
S1ASYCT ='ASYNCHRONOUS*REQUESTS'
S1CNNAME='NAME FOR*CONNECTION*TO STRUCTURE'
S1CRLCT ='CREATE*LIST*FOR A BIG*QUEUE'
S1DLLCT ='DELETE*LIST*1 PER*OVERALL*DELETE'
S1DLQCT ='DELETE*QUEUE*INDEX*ENTRY'
S1ELEMCT='CURRENT*ELEMENTS*IN USE'
S1ELEMHI='HIGHEST*ELEMENTS*IN USE'
S1ELEMLN='DATA*ELEMENT*SIZE'
S1ELEMLO='LOWEST*FREE*ELEMENTS*='/
S1ELEMMX='MAX ELEMENTS*RETURNED BY*IXLCONN'
S1ELEMPE='MAXIMUM*ELEMENTS*PER ENTRY'
S1ELEMPW='DATA*ELEMENT*SIZE*POWER OF 2'
S1ELEMRT='ELEMENT*SIZE OF*ENTRY*ELEMENT*RATIO'
S1ENTRCT='CURRENT*ENTRIES*IN USE'
S1ENTRHI='HIGHEST*ENTRIES*IN USE'
S1ENTRLO='LOWEST*FREE*ENTRIES'
S1ENTRMX='MAX ENTRIES*RETURNED BY*IXLCONN'
S1ENTRRT='ENTRY*SIZE OF*ENTRY*ELEMENT*RATION'
S1FREECT='ENTRIES*ON*FREE LIST'
S1FREEHI='HIGHEST*ENTRIES*IN*QUEUE INDEX'
S1HDRS ='MAXIMUM*NUMBER OF*LIST*HEADERS'
S1HDRSCT='HEADERS*USED FOR*CONTROL*LISTS'
S1HDRSQD='HEADERS*AVAILABLE*FOR QUEUE*DATA'
S1INDXCT='ENTRIES*IN*QUEUE INDEX'
S1INDXHI='HIGHEST*ENTRIES*ON*USED LIST'
S1INLCT ='INQUIRE*ON*LIST*ENTRY'
S1INQCT ='READ*QUEUE*INDEX*STATUS*ONLY'
S1NAME ='FULL NAME*OF LIST*STRUCTURE'
S1RDLCT ='READ*LIST*ENTRY'
S1RDQCT ='READ*QUEUE*INDEX*ENTRY'
S1RRLCT ='REREAD*LIST*DATA*FOR FULL*LENGTH'
S1RRQCT ='REREAD*INDEX*DATE*FOR FULL*LENGTH'
S1RSP1CT='RESPONSES*NORMAL*EVERYTHING*OK'
S1RSP2CT='RESPONSES*BUFFER*LENGTH*TOO SHORT'
S1RSP3CT='RESPONSES*NO*MATCHING*ENTRY'
S1RSP4CT='RESPONSES*ENTRY*VERSION*NO MATCH'
S1RSP5CT='RESPONSES*LIST*AUTHORITY*MISMATCH'
S1RSP6CT='RESPONSES*MAX LIST KEY*REACHED'
S1RSP7CT='RESPONSES*STRUCTURE*OUT OF SPACE'
S1RSP8CT='RESPONSES*OTHER*IXLLIST*RTRN CODE'
S1RWLCT ='REWRITE*LIST*ENTRY'
S1SIZE ='STRUCTURE*SIZE'
S1SIZEMX='MAXIMUM*STRUCTURE*SIZE'
S1USEDCT='ENTRIES*ON*USED LIST'
S1USEDHI='HIGHEST*ENTRIES*ON*USED LIST'
S1WRACT ='WRITE*QUEUE*INDEX*ADUUNCT*AREA ONLY'
S1WRLCT ='WRITE*LIST*ENTRY'
S1WRQCT ='WRITE*QUEUE*INDEX*ENTRY'
-New dataset CICXQ2 CICS Shared Temporary Storage Queue
Server Buffer Statistics measures the queue index buffer
pool and contains:
S2BFACTS='ACTIVE*BUFFERS*OWNED*BY TASKS'
S2BFEMPS='EMPTY*BUFFERS*ON*FREE CHAIN'
S2BFENTH='BUFFERS*USED*SO FAR'
S2BFFNOS='FREE ERRORS*BUFFER*NOT OWNED'
S2BFFRES='FREES*PUT BACK*BUFFER*AS EMPTY'
S2BFGETS='GET*REQUESTS'
S2BFGFRS='GETS*WHICH USED*A FREE*BUFFER'
S2BFGLRS='GETS*WHICH*USED*THE LRU*BUFFER'
S2BFGNBS='GETS*WHICH*RETURNED*NO*BUFFER'
S2BFGNWS='GETS*WHICH*USED*A NEW*BUFFER'
S2BFHITS='GET*WHICH FOUND*A VALID*BUFFER'
S2BFKEPS='KEEPS*PUT BACK*BUFFER*AS MODIFIED'
S2BFLRUS='VALID*BUFFERS*ON*LUR CHAIN'
S2BFLWTS='GET*WAITS*ON*BUFFER*LOCK'
S2BFPNFS='PURGES*WITH NO*MATCHING*BUFFER*FOUND'
S2BFPNOS='PURGE ERRORS*BUFFER*NOT OWNED'
S2BFPURS='PURGES*MARK*BUFFER*INVALID'
S2BFPUTS='PUTS*PUT BACK*BUFFER*AS VALID'
S2BFPWTS='WAITS*ON*BUFFER POOL*LOCK'
S2BFQTY ='TOTAL*BUFFERS*DEFINED'
-New dataset CICXQ3 CICS Shared Temporary Storage Queue
Storage Statistics measure usage of AXMPGANY & AXMPGLOW
storage pool areas, with:
S3ANYFR ='FREE PAGES*IN THE*STORAGE*ANY POOL'
S3ANYLO ='LOWEST*FREE PAGES*ANY POOL*SINCE RESET'
S3ANYMX ='TOTAL PAGES*IN THE*STORAGE*ANY POOL'
S3ANYNAM='POOL*NAME*AXMPGANY'
S3ANYPTR='ADDRESS OF*STORAGE*ANY POOL*AREA'
S3ANYRQC='ANY*COMPRESS*DEFRAGMENTATION*ATTEMPTS'
S3ANYRQF='ANY GETS*FAILING*TO OBTAIN*STORAGE'
S3ANYRQG='ANY POOL*STORAGE*GET*REQUESTS'
S3ANYRQS='ANY POOL*STORAGE*FREE*REQUESTS'
S3ANYSIZ='SIZE OF*STORAGE*ANY POOL*AREA'
S3ANYUS ='USED PAGES*IN THE*STORAGE*ANY POOL'
S3LOWFR ='FREE PAGES*IN THE*STORAGE*LOW POOL'
S3LOWLO ='LOWEST*FREE PAGES*LOW POOL*SINCE RESET'
S3LOWMX ='TOTAL PAGES*IN THE*STORAGE*LOW POOL'
S3LOWNAM='POOL*NAME*AXMPGLOW'
S3LOWPTR='ADDRESS OF*STORAGE*LOW POOL*AREA'
S3LOWRQC='LOW*COMPRESS*DEFRAGMENTATION*ATTEMPTS'
S3LOWRQF='LOW GETS*FAILING*TO OBTAIN*STORAGE'
S3LOWRQG='LOW POOL*STORAGE*GET*REQUESTS'
S3LOWRQS='LOW POOL*STORAGE*FREE*REQUESTS'
S3LOWSIZ='SIZE OF*STORAGE*LOW POOL*AREA'
S3LOWUS ='USED PAGES*IN THE*STORAGE*LOW POOL'
-Formats MGCICDA, MGCICDT, and MGCICDP are created.
-Eight STIDs are no longer created in CICS TS 1.2, so
these datasets(STID) will have zero observations:
CICAUSS(22), CICDLIG(72), CICDLIR(70), CICDLIR(73)
CICDQR (43), CICDTB (33), CICIRCB(75), CICJCR (49).
The table of Dataset/STID/DSECT/etc. has been updated in
member ADOC110.
Change 15.273 MXG 15.05 only. Change 15.228 did not input the ACCOUNT
VMAC26J3 fields because IF SMF26IND='.......1........' THEN DO;
Nov 14, 1997 should have been IF SMF26IND='.......1........'B THEN DO;
the "B" at the end of the bit test was missing, so SAS
did a character comparison, which was never satisfied.
Additionally, JES3 sites must install APAR UW41108, or
you will get INPUT STATEMENT EXCEEDED RECORD LENGTH on
ID=26 record; without that APAR, the bit in SMF26IND was
turned on, but the data segment was not present! This
was for JES3 running with OS/390 Release 1.3.
Thanks to John Allender, National Computer Systems, USA.
Change 15.272 This Change was not implemented. A future change will
XUILD005 change hardcoded PIB. references to a global macro, and
XUIL3005 that will eliminate the need to keep WORK.STEPS.
Nov 14, 1997 The original text of the change was:
Nov 21, 1997 For ITSV, dataset WORK.STEPS is no longer deleted from
the //WORK library in these two "Phase-Five" members that
are used by ITSV and some smart users in place of the
"All Phases" members BUILDPDB/BUILDPD3. The ITSV product
needs the STEPS dataset to be kept in addition to the
"PDB.STEPS" dataset, and ITSV actually has been modifying
the MXG source code during execution to remove the PROC
DATASETS that deleted STEPS! By now leaving the STEPS
dataset in the work library, ITSV will no longer need to
modify the MXG source code. "STEPS" is first renamed to
"REALSTEP" where it was previously deleted (because the
SPUNJOBS member creates a dataset named STEPS so that the
macro _PDBSUMS can summarize PDB.JOBS and PDB.SPUNJOBS),
and after SPUNJOBS has been run, "REALSTEP" is then
renamed back to "STEPS".
I did not include this logic in the BUILDPDB/BUILDPD3
members that do all five phases in one step, because ITSV
does not use those members, and leaving the STEPS dataset
instead of deleting it requires somewhat more DASD space
in the work library. Sites that have created their own
PDB job using the "phase" members may want to add a
delete of the WORK.STEPS dataset after their include of
members BUILD005 or BUIL3005 if more members are included
subsequently in the same SAS step execution.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.271 Further consistency enhancements. All interval datasets
VMAC23 should have SYSTEM DURATM STARTIME (especially for ITSV)
VMAC24 and these didn't:
VMAC94 TYPE23 - STARTIME variable created and kept.
Nov 14, 1997 TYPE24 - SYSTEM variable kept.
TYPE94 - DURATM variable created and kept.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.270 OS/390 R2.4, Goal Mode Only. INVALID DATA FOR R723CIDT
VMAC7072 or R723CDQT error. The SMF Manual showed R723CTSA as
Nov 14, 1997 four-byte binary, but the DSECT shows it is eight-byte
floating point! Change PCTEXTSA &PIB.4. to &RB.8. and
three lines earlier change LENSCS GE 432 to GE 436 and
fourteen lines later change SKIP-48 to SKIP-52.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 15.269 The eight-byte variable UOWTIME (created by INPUTing the
ADOCDB2 first six bytes of UOWID with PIB6.6 and then dividing by
ANALDB2C sixteen to convert time units into seconds) can have the
ANALDBTR same value for two unique values of the six-byte UOWID!
ASUMUOW Since UOWTIME is used to combine CICS MRO observations
IMACEXCL for the same unit-of-work, and is used to combine the
VMAC102 CICSTRAN and DB2ACCT data by unit-of-work, only members
VMAC110 that used UOWTIME (ANALDB2C,ANALDBTR, and ASUMUOW) were
VMACDB2 directly affected; the duplicate values lumped different
VMACDB2H units-of-work's transactions into one observation.
Nov 13, 1997
I had believed that any 6-byte field could be input,
converted, and stored with full resolution in a SAS
8-byte variable, but in an eight-byte floating point
non-integer, SAS can only store 15 digits on MVS and
only 14 digits on ASCII. In UOWTIME, it happens that
16 digits are required to resolve adjacent unitary
changes in the 6-byte UOWID value; one unit change in
UOWTIME is one third of a microsecond, so 8 digits are
needed for the seconds of DATETIME since 1960, and 7
fractional digits were not enough as shown in the table:
The table shows duplicate DIVIDED BY 16 values for the
different UOWID input values, and shows that adjacent
UOWID values could not be resolved:
UOWID 6-bytes INPUT PIB6.6 DIVIDED BY 16
(15 digits) (15 digits)
DDDDDDDDE100 243974979.816704 15246561.2385440
DDDDDDDDE101 243974979.816705 15246561.2385440
DDDDDDDDE102 243974979.816706 15246561.2385441
DDDDDDDDE103 243974979.816707 15246561.2385441
DDDDDDDDE104 243974979.816708 15246561.2385442
DDDDDDDDE105 243974979.816709 15246561.2385443
DDDDDDDDE106 243974979.816710 15246561.2385443
DDDDDDDDE107 243974979.816711 15246561.2385444
DDDDDDDDE108 243974979.816712 15246561.2385445
DDDDDDDDE109 243974979.816713 15246561.2385445
DDDDDDDDE10A 243974979.816714 15246561.2385446
This error wasn't seen earlier in "real" CICS systems
because UOWTIME was the real time of day when a real
transaction started, and real microseconds occurred
between successive events, so UOWTIME values resolved to
unique values for different units-of-work. But clients
like CICS/OS2 and AS/400 now send transactions into CICS,
and these originators store not a timestamp in UOWID,
but rather a counter value that is incremented for each
transaction, and as one counter unit is one third of a
microsecond, MXG's choice of storing the six-byte UOWID
token as an eight-byte datetimestamp is now proven to be
incorrect to resolve adjacent counter values.
The solution is to create a new 6-byte character variable
UOWIDCHR in both CICSTRAN and DB2ACCT datasets containing
the first six bytes of UOWID, and then to insert UOWIDCHR
after UOWTIME in each BY statement so BY NETSNAME UOWTIME
becomes BY NETSNAME UOWTIME UOWIDCHR to guarantee unique
instances are correctly merged. The logic in ASUMUOW was
revised to protect the SPIN library against a variable
UOWIDCHR NOT FOUND error.
Thanks to Carol Arnold, Brown Brothers Harriman & Co., USA.
Thanks to John Krall, Brown Brothers Harriman & Co., USA.
Change 15.268 The new IHDR110 "Type 110 Header Exit" member can be
IHDR110 used to select CICS records by APPLID or other fields,
VMAC110 since the exit is taken after the header of the CICS
Nov 13, 1997 record has been input. It can save lots of time if you
have lots of Test CICS Regions whose SMF data you want
recorded (for problem determination) but whose records
you do not want in your daily CICS PDBs, because you can
use IHDR110 to delete all records from your test regions.
See the IHDR110 member for the list of fields that exist
in the Subtype 0/1/2, for Journal/Transaction/Statistics.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.267 Variable SMFRECNR was added to KEEP= list for TYPE90
VMAC90 dataset. See Technical note on Y2K Test System's SMF
Nov 13, 1997 data in MXG Technical Newsletter THIRTY-THREE.
Thanks to Carol Arnold, Brown Brothers Harriman & Co., USA.
Change 15.266 MXG 15.04-MXG 15.05. Current dates in CREATIME, STRTTIME
TYPETMON ENDTIME, UOWTIME, TIESDATE, and TIREDATE were wrong. The
Nov 6, 1997 three lines IF O LE YY LE 1959 THEN YY=YY+2000; should
have been IF 0 LE YY LE 59 THEN YY=YY+2000;
This error caused 1997 TMON dates to be in the year 2097.
Thanks to Colin J. Fester, Engen Petroleum, SOUTH AFRICA.
Change 15.265 NTSMF version 2.0.H caused INPUT STATEMENT EXCEEDED for
VMACNTSM the 0,0 (Discovery) record. The quick circumvention is
Nov 3, 1997 to replace STOPOVER with MISSOVER by using
MACRO STOPOVER MISSOVER % as the first statement, before
the %INCLUDE statement. The fix is contained in 15.06.
Thanks to Howard Glassetter, Weyerhaeuser, USA
Change 15.264 IDMS 10.02 observations were not OUTPUT in the IDMSTAS
VMACIDMS dataset; the statement IF '1201' LE SMFHVER LT '1400' ...
Nov 3, 1997 that is immediately before %INCLUDE SOURCLIB(EXIDMTAS);
must be changed to IF '1002' LE SMFHVER LT '1400' ... if
you still have records from archaic IDMS 10.02 release.
It is possible there will be no obs in IDMSBUF and INT,
with 10.02 as well.
Thanks to Jill Billings, First Data, USA.
Change 15.263 Support for Boole & Babbage MQ Series 1.1.4 MVMQS 1.2.0
EXBBMQBP VSAM file of statistics records adds 3 new MXG datasets:
EXBBMQPS RTIN MXG DATASET VARS DESCRIPTION
EXBBMQQM 'E1'x BBMQQMGR 125 Queue Manager Record
IMACBBMQ 'E2'x BBMQBUFF 96 MQ Buffer Pool Record
TYPEBBMQ 'E3'x BBMQPAGE 16 MQ Page Set Record
VMACBBMQ This Boole product is also called MainView for MQSeries,
Nov 2, 1997 and the MXG support reads their online historical files.
Change 15.262 Availability Analysis example using PROC CALENDAR and the
ANALAVAL PDB.SMFINTRV dataset (must be enabled in IMACINTV) is
Nov 1, 1997 provided in this nice user contribution.
Thanks to Rob Wunderlich, USS/POSCO Industries, USA.
Change 15.261 Cosmetic. APAR OW15518 is the IBM APAR that added the
YEAR2000 year 2000 support to all SMF-owned SMF records; the
Nov 1, 1997 member YEAR2000 incorrectly typo'ed OW16518.
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 15.260 Cosmetic. Change @28 QWACRINV MGDB2RC16. to MGDB2RC15.
ANALDB2R and there will be a space between the reason and the
Nov 1, 1997 count of SELECTs and so it doesn't look overlaid.
Thanks to Bob Gauthier, American Stores Company, USA.
Change 15.259 Pairing DB2 type 102 59 and 63 records was wrong when
ANALDBTR there were multiple 63s due to lots of SQL text. The
Oct 31, 1997 correction is to only increment PAIRNR in the BEGIN63
logic IF QWHSSTCK NE OLDTME63 THEN PAIRNR+1; and add
OLDTME63 to the RETAIN and DROP statements, and to set
OLDTME63=QWHSSTCK; just before the OUTPUT statement.
This affected the S064058 file because PAIRNR was being
incremented by more than the one count MXG expected in
the IF HOLD63 AND HOLD64 logic block. This correction
was diagnosed and the fix coded by its discoverer.
Thanks to Ken Michalik, Kraft Foods, USA.
Change 15.258 Support for CICS APAR UN98309 (INCOMPATIBLE) which
IMACPTF adds new field RLSCPUT (MXG variables CPURLSTM and
VMAC110 CPURLSCN) to dataset CICSTRAN. You must update member
UTILCICS IMACPTF to enable macro _UN98309 if you install this
Oct 31, 1997 PTF, because there is no way to tell from the SMF
record that the PTF is installed. If you use any
of the "User" fields, or have any optional segments
(e.g., those created by Candle or Boole & Babbage)
those data will be wrong with this PTF until you both
install the MXG 15.06 or later version and update the
IMACPTF member. Sorry, but this is what happens when
IBM adds data to the type 110 transaction record without
changing version numbers (and there is no maintenance
level flag for them to update, either!).
MXG utility UTILCICS was updated and it will now detect
that APAR UN98309 has been installed on any of your CICS
regions; see its comments for instructions and output.
Thanks to Martin Peck, CA-IT/Capacity Management, GERMANY.
Change 15.257 Support for type 88 subtype 11 (System Logger Alter
EXTY8811 Structure) data creates new dataset TYPE8811.
IMAC88 Also, variable SMF88EDO is now input and created in
VMAC88 the TYPE88 dataset.
Oct 31, 1997
Thanks to Pat Quinnette, Principal Mutual Life Insurance, USA.
Change 15.256 OPC segmented type 29 records caused INPUT STATEMENT
VMACOPC EXCEEDED error; MXG only inputs the EQE control block
Oct 31, 1997 fields, which does not exist in the segmented records,
so now MXG verifies both the length and EQE eyecatcher
before decoding type 29 records.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 15.255 Windows NT on a multiprocessor (two or more engines) was
NTINTRV not summarized correctly; each engine created a separate
Oct 30, 1997 observation in the NTINTRV dataset. This revision will
correct that MXG design error by summing INTPROR before
the merge and creating NRCPUS variable to count engines.
Most of the fields from the PROCESOR record exist in the
SYSTEM record, but the percentage values are slightly
different between the records. Variable ACPBYPAS in the
SYSTEM record appears to be half of the sum from the
PROCESOR records with two engines, so the (believed!)
more correct value from PROCESOR is used, rather than the
values from the SYSTEM record, by moving INTPROR to the
end of the MERGE statement (so its values will override
variables of the same name).
Change 15.254 Of no real impact, because adding zeros has none, but MXG
VMAC30 created additional observations in TYPE30_V/30_4/30_5 if
Oct 29, 1997 there were type 30 records containing only MULC or OMVS
segments. These observations had MULTIDD='Y', a flag
that this step record contained only EXCP segments, and
had zeroes for all resource variables, because resources
in the MULC (Measured Usage) and OMVS (Open Edition/MVS)
segments are output in TYPE30MU or TYPE30OM datasets.
Prior to MXG 15.05, when there was more than one multiple
record from a step, they were identical and MXG's NODUP
in PROC SORT deleted all but one. But Change 15.235 in
MXG 15.05 added variable EXTRMULC to be kept, and as its
value was not the same in each multiple record, MXG did
not delete any dupes, and comparison of MXG 15.03 and MXG
15.05 showed different messages on the SAS Log about
duplicates. While they were still zero and had no
impact, they should not have been output in the first
place. So MXG has now added a test
IF MULTIDD='Y' AND NUMDD=0 THEN DELETE;
so that only multiple records due to EXCP segments will
be output into the TYPE30_V/TYPE30_4/TYPE30_5 datasets.
In TYPE30MU dataset, INITTIME will be the job or step
initiate time for subtype 4 and 5 records, but it is now
set equal to INTBTIME in the subtype 2 and 3 interval
records so that duration of the interval can be known.
There can be multiple records created due to too many
ARMS (Automatic Restart) segments, but I have no data
with ARMS segments to investigate what I should do with
those records. Variable EXTRARMS will be nonzero if you
have ARMS segments causing multiple records, and it is
kept in TYPE30_V/_4/_5 datasets. In fact, only the data
in the first ARMS segment is actually input by MXG.
Thanks to Tom Elbert, John Alden Systems Company, USA.
Change 15.253 Text of Change 12.255 now points to revision in Change
ChangeSS 15.061, whose text was also revised to TYPE78CF rather
Oct 29, 1997 than TYPE74CF!
Thanks to Jack Fausti, EDS, USA.
Change 15.252 The example for pre-CICS 4.1 GMT protection should have
ADOC110 spelled STRTTIME instead of STTRTIME.
Oct 29, 1997
Thanks to Rey Marquez, General Accident, USA.
Change 15.251 The CICINTRV logic was still wrong after Changes 15.219
CICINTRV and 15.092. The first interval was dropped when it was
Oct 14, 1997 valid, the COLLTIME value was reset to the start time of
Oct 29, 1997 the interval, variable STARTIME was not propagated into
the PDB.CICINTRV dataset, and the HALFHOUR default value
for MACRO _CICINTV produced strange results in DSGCNT if
15 minute interval data was input. To correct the logic,
DURATM and STARTIME were added to the KEEP= list in the
one-per-interval datasets (i.e., the ones that are not
VMXGSUMed), the DROP of SMFSTRQT was removed (to help in
debugging), and the major logic changes were in both the
big MERGE step (to not drop first interval, and to create
STARTIME) and in the final VMXGSUM (which now uses the
STARTIME rather than COLLTIME to cluster records. This
has been tested with broken data (i.e., an interval with
only FCR (file close) records, which will happen when SMF
is dumped before the end of the interval) as well as with
USS/REQ/EOD records interleaved with INT records, and now
the data looks correct.
Note that an observation in PDB.CICINTRV with missing for
DURATM is a "broken data" interval in which only event
data was found, and STARTIME will equal COLLTIME since
there is no interval duration in the event records.
It was invalid values for DSGCNT (Current Nr of Tasks)
in Dan's reports that led to this revision, so I also
moved DSGCNT from the MEAN= list to the MAX= list as it
is more useful as the maximum number of current users
when multiple intervals are summarized than the average.
Sites with SAS IT Service Vision (ITSV) should install
MXG 15.06 or later if they want to use PDB.CICINTRV
table. With MXG 14.07 thru MXG 15.05, SAS ITSV will
generate a warning message because variable DATETIME
was not found in PDB.CICINTRV. You could delete the
statement DROP DATETIME in member CICINTRV in those
earlier versions and ITSV will populate its tables,
but only the MXG 15.06 version of member CICINTRV
creates a legitimate PDB.CICINTRV dataset.
This change did remove the DROP DATETIME; statement
that was added in MXG 14.07. Eventually, the variable
DATETIME will be deleted, because STARTIME is the name
that should be used, but both are now kept to protect
ITSV until it is updated to use STARTIME.
Early versions of VMXGSUM created variable DATETIME, but
that was not my intention; instead, the original named
variable (i.e., the one used in the DATETIME= argument)
is intended to be used for the summarized datetime value.
Thanks to Dan Gilbert, Bergen Brunswig, USA.
Thanks to Ken Whitehead, Bank of New York, USA.
Change 15.250 The test IF CPUTM NE CPU72TM in RMFINTRV that validates
RMFINTRV that the sum of your work definitions (CPU72TM) is equal
Oct 13, 1997 to the sum of real work (CPUTM, all non-report perfgrps
or service classes) was too strong. Truncation effects
caused fractional differences (1E-9) when totals really
were equal. In the worst case, with 1000 numbers summed
at .01 second resolution, if all lost the max of .001,
a maximum difference of 1 second could exist, so the test
was revised to report error only:
IF ABS(CPUTM-CPU72TM) GT 1 THEN DO;
This test only comes in to play if you have enabled
IMACWORK to use both control/report performance groups
or service/reporting classes to define workloads.
Thanks to David Ehresman, University of Louisville, USA.
Change 15.249 Support for NTSMF Version 2.1 Final Changes (INCOMPAT).
VMACNTSM In the final Beta Tests of NTSMF Version 2.1, we have
Oct 13, 1997 decided to make a structural change in the timestamps of
NTSMF records that can affect the NTINTRV dataset, so
now, MXG 15.06 (or at least Change 15.249) is required
for NTSMF Version 2.1. Prior versions are not affected.
Prior to 2.1, all NTSMF records for a interval had the
same SMFTIME timestamps and DURATM durations, because
only one call to the Registry for all objects was made.
A single call sometimes generated 300K bytes of data,
which the Registry did not handle well, but in using just
one call to the registry we got back every counter in
every object, and we had wanted to allow the collection
of only some counters in some objects.
So NTSMF 2.1 now will issue multiple calls (one per
object) so you can tailor which counters are collected.
But the multiple calls create records with slightly
different SMFTIME timestamps, varying by the milliseconds
it takes NTSMF to get from the first to the last object,
and since NTINTRV uses STARTIME=SMFTIME-DURATM to collect
all of the records for an interval, STARTIME would not be
constant for each interval, which would cause multiple
obs in dataset NTINTRV for each real interval.
That is the incompatibility which is eliminated by this
change. NTSMF 2.1 writes a configuration record with
OID=0, OBJECT=0 (which contains fields that used to be in
each record's header that were moved to this record as
part of 2.1's "reduced header" redesign to reduce data
volume, as well as configuration information). This 0,0
record is now written at the start of each call sequence,
its DURATM is the duration since the last call sequence,
and MXG now uses the 0,0 record's SMFTIME-DURATM as
the retained STARTIME value for all records until the
next 0,0 record is read. So STARTIME will be constant
for each interval, NTINTRV will be correct, and each
individual record's timestamps, SMFTIME, can be examined
to see how long it takes NTSMF to write a set of data!
- This change also creates variable PRODTYPE (Server/WS)
and DSCNAME (NTSMF data set collection that was used)
from the 0,0 configuration record.
Change 15.248 Support for Applied Expert System's Clever TCP/IP SMF
ADOCCTCP record creates two new datasets:
EXCTCPPR CTCPPERF - Clever TCP/IP Performance Statistics
EXCTCPWL CTCPWORK - Clever TC/IP Workload Statistics
IMACCTCP
TYPECTCP
VMACCTCP
Oct 13, 1997
Thanks to Chuck Hopf, MBNA, USA.
Change 15.247 Support for HP MeasureWare for Terra Data Operating
ADOCMWTE System creates six new datasets:
EXHPTEAP HPTEAPPL - HP-MWA TERRADATA APPLICATION RESOURCES
EXHPTECO HPTECONF HP-MWA TERRADATA CONFIGURATION
EXHPTEDS HPTEDSK HP-MWA TERRADATA DISK ACTIVITY FROM DISK
EXHPTEGL HPTEGLOB HP-MWA TERRADATA GLOBAL ACTIVITY
EXHPTELA HPTELANS HP-MWA TERRADATA LANS
EXHPTEPR HPTEPROC HP-MWA TERRADATA PROCESS RESOURCES
IMACMWTE The Report Macro for Terra Data extract is contained in
TYPEMWTE member ADOCMWTE.
VMACMWTE
Oct 13, 1997
Thanks to Alfred Holz, Medco Data Corporation, USA.
Change 15.246 When you used TYPEEREP to read the DASD (i.e. online)
ADOCEREP SYS1.LOGREC file, MXG read the entire file, all the way
IMACEREP to End-of-File, but the DASD file contains old records
VMACEREP that should not have been read. The first record of the
Oct 12, 1997 DASD file is a header record that contains the pointer
LASTTR to the last record written. IBM utilities CLEAR
SYS1.LOGREC by updating LASTTR and leave all the records
where they were. Now, MXG detects that there is a header
record and uses its LASTTR value to STOP the input from
SYS1.LOGREC after that logical end of file record. (If
you should ever want to read the entire DASD LOGREC file,
new macro _READALL in IMACEREP will let you change the
MXG default) Note that this was only a problem if you
read the DASD SYS1.LOGREC file; the dumped file contains
only the valid records, and there is no header record in
the dumped file, so MXG reads dumped data to end-of-file.
An old IBM reference, RTA000138425 dated 11/13/1996 has
more discussion, including pointing out that SYS1.LOGREC
and EREP may not necessarily point to the same file!
This MXG change only applies if you use TYPEEREP to read
the online, DASD, SYS1.LOGREC, as only it contains the
header record. If you were reading the dumped EREP data
records, on tape or DASD, there are no dead records nor
any header, and reading to end-of-file is what you want!
Thanks to Christophe Faure, ATOS Group, FRANCE.
Change 15.245 DB2 Type 102 Subtype (IFCID 140) INPUT STATEMENT EXCEEDED
VMAC102 error due to trashed record. The data thru QW0140UR is
Oct 11, 1997 valid for the Object-Type=Plan record, but the XL8 field
QW0140HO contains '40ffff4040404040'x, and QW0140LL has
'4000'x, (indicating 16,384 bytes of SQL text follows),
but QWT02R1L is only 82 bytes (and there are 9 bytes in
the segment following QW0140LL). It looks to me that the
QW0140HO field was filled with 9 bytes rather than 8, and
it overlaid the first byte of QW0140LL. MXG previously
added protection for this IFCID=140 record when there was
no SQL text in Change 15.216; this Change makes the line
IF QW0140LL GT 2 THEN
look like this:
IF QW0140LL GT 2 AND COL+QW0140LL-3 LE LENGTH THEN
The site will pursue the bad record with IBM.
Thanks to Michael Oujesky, MBNA, USA.
Change 15.244 New variable CPU72TM was formatted TIME12.2 before it was
RMFINTRV output, but was not formatted in the step in which it was
Oct 11, 1997 created and in which it was PUT in an error message, so
it is now FORMATed when created.
Thanks to David Ehresman, University of Louisville, USA.
Change 15.243 DFSORT APAR PN71337 added flag fields (Compatibly) which
VMAC16 are new variables in MXG TYPE16 dataset:
Oct 9, 1997 LOSMCNTR='LOCALE PROCESSING*SORT MERGE*CONTROL FIELD?'
LOIOCOMP='LOCALE PROCESSING*INCL OMIT*COMPARE FIELD?'
EQUALUSE='EQUALS*WAS USED*FOR SORT*OR MERGE?'
Change 15.242 Utility program to re-create SMF VBS data records from a
UVBSNRDW downloaded SMF file that had BDW and RDW stripped. If
Oct 9, 1997 you don't download correctly (see member SENDDATA), you
can end up with an SMF file of only records; the BDW/RDW
are removed when you download from a RECFM=VBS instead of
using the RECFM=U copy. This has happened enough times
that I wrote this utility to reconstruct the original SMF
record, adding the missing BDW (Block Descriptor Word)
and RDW (Record Descriptor Word). As written, the logic
only works for SMF records that have only one instance of
SYSTEM per record (DB2 and CICS qualify); it would need
to be extended for records like JES type 26 that has the
SYSTEM repeated in several places, but it worked so I was
able to reconstruct the problem in the site's SMF data,
and to discover their error had been previously fixed!
Change 15.241 MQ Series type 116 SMF record with blank for CICS Task Nr
VMAC116 caused INVALID DATA FOR QWHCTASK message. The input of
Oct 7, 1997 QWHCTASK was protected by adding the double questionmark:
QWHCTASK ?? &PD.4. to suppress the error message and the
hex dump of the record. QWHCTASK was input only if CICS
attach (QWHCATYP=1 in MQ Series), but MXG did not expect
records with blank values.
MQ Series SMF type 116 record questions answered by IBM:
1. I have SMF type 116 record subtype 0 with QWHCATYP=1
(CICS), but the Thread Cross Reference Data is all
blanks (i.e., the CICS "thread number" QWHCCTNO,
"transaction name" QWHCTRN, and the CICS "task number"
are hex 40's). The CPU time field is hex zeroes, as
are all of the GET/PUT counts.
MQSSeries System Management Guide for Version 1.1.4
SC33-0806-04 page 343 discusses that there may be up
to 9 records containing zero CPU time. Do the blank
values in the CICS fields only occur in these records
with zero CPU time, and is a record with zero CPU time
always going to have blanks for the CICS fields, or is
the zero CPU and the blank CICS fields unrelated
conditions. Aren't blanks an error?
IBM ANSWER: Regarding records with zero cpu time on
CICS adapter related records, the null
records relate to the main CICS TCB and
8 MQ-related CICS TCBs. Depending on the
activity in the queue manager, these null
records will be written.
2. There is a third, undocumented self-defining section
in type 116 records that contains non-zero values,
including two TODSTAMP fields. The Offset of the
triplet is 36 decimal, and the note in Table 25 states
"other self-defining sections refer to data for IBM
use only". However, the data values may be of
significant value to our customers but I need
confirmation of their meaning, as well as the other
fields in the undocumented section:
- The two TOD stamp fields at the beginning of the
section look to be a start time and an endtime, and
as there is no other start time in the record, it
should be kept to measure event duration.
- The end timestamp has more resolution than the .01
seconds to which the SMF record timestamp is
truncated. Additionally, there is yet another
undocumented TODSTAMP field in the record, in the
Message Manager Accounting record QWHS section, as
the first eight bytes of the reserved field at
decimal offset 16, and this is also an ending
timestamp, but it is 26 microseconds later than the
ending timestamp in the undocumented section, so it
is clearly the timestamp of a third event.
Start Time in Undefined Section 05OCT97:04:15:42.970238
SMF Record time stamp 05OCT97:12:50:25.43
End Time in Undefined Section 05OCT97:12:50:25.438630
Reserved Time in QWHS Section 05OCT97:12:50:25.438656
By understanding what events are being timestamped,
the delta-time between them can often be used to
characterize short term problems and long term trends,
so I request information as to their meaning. In
addition, there are a number of fields in the
undocumented section that are non-zero; since they
exist in the site's SMF record, knowing what they
count so that they can be decoded would help our
mutual customers to better measure their MQ Series
systems.
The sample 116 record in SC33-0806-04 on pp 344-346 has
similar data, with SMF time of 29MAR94:16:43:15.17, its
start at 16:43:13.500017, and its two end times are at
16:43:15.174748 and 16:43:15.175460, for a delta of 712
microsec! What is happening during that delta duration?
I am aware that while the SMF time stamp is on the local
clock, all three undocumented TOD stamps are on the GMT
clock. The delta between SMF time and the end time will
let me discover the GMT offset to convert to local for
comparison with other SMF data records from CICS IMS,
etc.
IBM ANSWER: The additional data is not strictly just
for IBM use; it's just that the additional
data is not used for any purpose by MQ.
Part of this core code for MQ is based on
DB2, and while MQ cannot guarantee any of
the information in the additional section,
the layouts for DB2 Accounting Data may
indicate the contents of this section.
BARRY's STATUS: If you want to look deeply into MQ Series
with type 116 records, send me some data
records and I will decode the extra data
segment to see if it really is useful.
Thanks to Ken Whitehead, The Bank of New York, USA.
Change 15.240 Variables that had duplicate entries in LABEL statements
several were removed from members VMAC42, VMAC7072, VMAC79,
Oct 4, 1997 VMAC80A, VMAC99, VMACICE, VMACMWUX, and VMACXPSM. These
caused no error, but should not have been repeated.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.239 New variable LASTVOFL "IS THIS*THE*LAST*VOLUME?" is added
VMAC1415 to dataset TYPE1415 to flag whether an individual 14/15
Oct 4, 1997 record is the last volume, by decoding '40'x in RECIND1.
See Change 15.304.
======Changes thru 15.238 were in MXG 15.05 dated Oct 2, 1997======
Change 15.238 "ERROR. NEGATIVE CPU-UNCAPTURED-TIME (TYPE70-TYPE72)" is
RMFINTRV printed by RMFINTRV when MXG detects bad CPU time values
Oct 2, 1997 in type 72 records. Back in 1992, IBM APAR OY51878 found
bad values in CPURCTTM (SMF72RCT), and now APAR OW28256
reports bad values again! When CPURCTTM is corrupted,
CPUOVHTM (actually the "Uncaptured CPU Time" rather than
overhead) becomes negative because the total CPU in type
72 records exceeds CPU Active time for the box! This is
because MXG includes CPURCTTM in CPUTM in building the
TYPE72/TYPE72GO datasets, and in RMFINTRV calculations.
You can correct this error in advance by inserting in the
EXTY72/EXTY72GO exit members:
CPUTM=CPUTM-CPURCTTM;
so that TYPE72/TYPE72GO and RMFINTRV will not include the
CPURCTTM (Region Control Task, mostly TSO Quiesce/Resore)
in the total CPU time captured, and then remove this
workaround when you install the PTF for the APAR OW28256.
Note: for Boole's CMF, APAR BPM6782 is reportedly also a
requirement. 29May98.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 15.237 Support for BETA93 Release 3.1.3 (INCOMPATIBLE) inserted
VMACBETA fields in the header, and changed the length of many of
Oct 2, 1997 the fields. Unfortunately, I only received subtype 21
records, so only that subtype is supported in MXG 15.05.
In fact, all other subtype will produce a hex dump of the
first record of each unsupported subtype and prints an
MXG message to please send that dump to me so I can add
support for those subtypes. (If the BETA93 vendor had
documented their alignment bytes in their DSECT, I could
have delivered the code for all subtypes, but the subtype
21 record proved their documentation is inadequate. I
presume that since only the subtype 21 records were sent,
that that is the most important record for BETA92, and I
hope this change will get you through the nite!).
Thanks to Manfred Thomas, BHF-Bank, GERMANY.
Change 15.236 DFHSTUP-like CICS Shutdown Reports have been enhanced to
ANALCISH match new IBM reports, but not all reports were finished
Oct 2, 1997 in time for MXG 15.05 (notably, CICFCR). See notes in
the member for additional status.
Thanks to Steve Colio, CIGNA, USA.
Change 15.235 Duplicate step records might not be deleted by SAS NODUP
BUILDPDB option, but only for steps with more than one physical 30
BUILDPD3 record for a step (eg., steps with many DD segments, aka
BUILD005 MULTIDD='Y' steps). The sort order for TYPE30_4 did not
BUIL3005 include MULTIDD EXTRADD variables, and if the multiple 30
VMAC30 records had exactly the same TERMTIME, the sort did not
Oct 2, 1997 place them adjacent, and the NODUP only deletes duplicate
records that are adjacent. The correction is to change
the BY list for PROC SORT NODUP DATE=TYPE30_4 ... ;
to BY READTIME JOB JESNR TERMTIME MULTIDD EXTRADD;
Of course, if you never have duplicate SMF data
(which can ONLY happen when a failure in SMF dump
AND an incorrect human recovery occurs) you will
not have cause for concern!
The impact was that two observations were created in
PDB.STEPS, and the job's CPU time was doubled.
-Variables EXTRARMS, EXTRMULC, and EXTROMVS are now kept
in the TYPE30_V and TYPE30_4 records, as they may be
needed for additional protection.
-Member ADOC30 has been updated with a discussion of the
existence of multiple step records that was written in
reply to a request from IBM to review SMF documentation
on how to know whether a physical step record was the
first, last, or in-between record for a step terminate.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 15.234 Support for TCP/IP 3.2 API Calls SMF record increased the
VMACTCP length of the API Call record (on which MXG depends to
Oct 01, 1997 sort out API from FTP from TELNET), relocated APIJOBNM,
and added new variables APIJOBID (JCTJOBID) and APISTART
(JES Start Time) for HPNS applications (where the HPNS
enabled interfaces are
- C sockets API (including C sockets for CICS)
- Sockets Extended APIs:
- Macro Interface
- Call Instruction Interface, including Call Instr
for CICS and IMS).
Thanks to Harmut Richter, BASF Computer Services GmbH, GERMANY.
Change 15.233 The discussion of documentation of MXG Software, the
DOC MXG books, etc., is now contained in member DOCUMENT.
Sep 30, 1997 There are several "tables of contents" of ACHAPxxx and
ADOCxxx members (this consolidates and enhances the old
"Online Documentation" section of member CHANGES).
Change 15.232 Enhancements to process EASMON/EASMAP data from VM/ESA
EXXAMSYT were contributed to add new XAMSYT and XAMSYU datasets,
EXXAMSYU and to correct "IF SKIP GE 20... SKIP=SKIP-20;" before
IMACXAM the INPUT TCMXIDSZ to ..GE 16 ...SKIP-16" so that the
VMACXAM fields are actually input. Datasets XAMSYT and XAMSYU
Sep 30, 1997 report LPAR dispatch and management time from VM/ESA.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 15.231 Deaccumulation of the NPMINPMT dataset in member DIFF28
DIFF28 (added by Change 15.206) now creates variable DURATM
Sep 30, 1997 instead of DELTATM, and creates variable STARTIME to
be consistent with other interval datasets.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.230 VLF Activity for CATALOGs can be generated in SYSLOG
TYPEVLFC with the F CATALOG,REPORT,VLF command that creates the
Sep 30, 1997 messages IEC359I. This program will read //SYSLOG and
create dataset PDBVLFC.VLFCATLG from those reports and
also trends the new and old reports in PDBVLFC.TRNDVLFC.
Note that the report values are cumulative: the command
must have been issued at least twice to produce data.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.229 These IMS Log Processing Assembly programs were revised
ASMIMSLG in MXG 14.07, but the revisions did not support archaic
ASMIMSL5 pre-DFP 3.0 systems, and there was at least one MXG site
Sep 30, 1997 at that level that encountered an 0C4, so the programs
were revised to support the earlier QSAM level.
Thanks to Skip Abadie, MBNA, USA.
Change 15.228 IBM APAR OW26297 for JES3 add a new triplet section and
VMAC26J3 Job Account fields at the end of the purge record (though
Sep 30, 1997 the original APAR text made it look like it was inserted
in the middle of the record, it was in fact added at the
end). There was already a 42-byte accounting field in
the JES3 purge record, but IBM added the new section to
support all Job accounting fields. MXG previously used
the 42-byte field to decode only variable ACCOUNT1, but
with the new section, MXG will decode ACCOUNT1-ACCOUNTn
(where the number of fields kept is set in your IMACACCT
tailoring member). All of this is relatively unimportant
since MXG needs the Purge record account fields only for
jobs that did not initiate (i.e., JCL errors or cancel
before execution); account fields are normally taken from
the type 30 records.
Change 15.227 IBM APAR OW16975, reported in MXG Newsletter THIRTY-TWO,
VMAC30 is in error, and when installed causes APPC-using flushed
Sep 30, 1997 steps to fill your log with hex dumps, and causes MXG to
Dec 13, 1997 delete those step records. The APPC section was removed
by the APAR, but the triplet values were not zeroed.
This circumvention will print only one instance message
on the log, will skip the non-existent APPC section, but
will then output the type 30 record, and when the APAR
error is fixed, the circumvention will be passive.
Dec 13 update: APAR OW30802 is the new fixing APAR that
will make this circumvention passive.
Thanks to Bill Shanks, BR Business Systems, ENGLAND.
Change 15.226 Support for APAR XXnnnnn, which increases the number of
ANALRMFR structures in a Coupling Facility from 64 to 255. The
VMAC74 SUBSCRIPT OUT OF RANGE error will occur if you install
Sep 29, 1997 the PTF without this change. This change also eliminates
four sets of variables QSTR01-QSTR64, QSIZ01-QSIZ64,
QFLG01-QFLG64, and QVER01-QVER64 from dataset TYPE74CF.
That information was already stored in TYPE74ST dataset,
which has one observation per structure, and those fields
should not have been kept in TYPE74CF anyhow!
Reports in ANALRMFR have not been updated for more than
64 structures, and Total Size of Structures Allocated
value will be missing until the CF Reports are revised.
This change also corrected INPUT STATEMENT EXCEEDED error
with type 74 subtype 4 records with NRTRIPLT=8.
There is still an open problem with IBM for this APAR, as
pointer R744CDSI is sometimes wrong, pointing beyond the
end of the data record; MXG now conditionally inputs the
R744CDSI extension fields, pending a fix from IBM.
Thanks to Dennis Pugh, BMC Software, USA.
Change 15.225 This report for Cached DASD Controllers now will use the
ANALCACH PDB.TYPE74CA and/or PDB.CACHE90 dataset, and will not
Sep 26, 1997 fail if either dataset does not exist. (TYPE74CA has
replaced the old CACHE90 dataset created from CRR.)
Thanks to David Ehresman, University of Louisville, USA.
Change 15.224 Variable TAPEBYTE was not in the KEEPIN= LIST, causing
DAILYDSN variable SPACE5 (Non-HSM Tape) to be missing and causing
Sep 26, 1997 UNINITIALIZED VARIABLE TAPEBYTE message on the log. The
DAILYDSN program is used in JCLDAYDS example to measure
the size of all of your datasets (DASD/TAPE/HSM) using
DCOLLECT, CA-1, and HSM records.
Thanks to Robert Miles Standish, Dean Witter Trust Company, USA.
Change 15.223 Some reports may have timestamps shifted right two bytes,
ANALDB2R causing Authid to be overlaid. I changed DATETIME16. to
Sep 26, 1997 DATETIME18. expecting to show all four digits of year,
but did not check to see there was space on the line for
the two extra positions. (Worse, DATETIME18 does not
print the four digit year, it justs shifts right and then
prints two digits of year!). Therefore, change all of
the occurrences of DATETIME18. to DATETIME16. (Note the
datetimes printed at the top of the page use DATETIME21.2
so you will see the four digit year on each page!)
Thanks to Brian Hawthorne, Mutual of New York, USA.
Change 15.222 MXG 15.04 only. Catalog Cell 'E7' in TYPE6156 record had
VMAC6156 INPUT STATEMENT EXCEEDED error, because Change 15.166 was
Sep 25, 1997 not correct. In the block ELSE IF CLTYPE='E7'X THEN DO;
delete these two lines after the INPUT statement:
ALICELN &PIB.2. /*LENGTH OF ALIAS INCLUDING ITSELF*/
ALITYPE $EBCDIC1.
and then change ALIRESV $EBCDIC1. to ALIRESV $EBCDIC2.
Thanks to Lawrence Jermyn, Fidelity Systems Company, USA.
Change 15.221 The new ASUMUOW in MXG 15.04 fails with LIBNAME TEMP01
ASUMUOW not found. Test code that should have been removed had
IMACUOW the specific reference. You can change TEMP01.CICSTRAN
Sep 24, 1997 to CICSTRAN in both places to circumvent. However, this
revision changes the MXG defaults so that
PDB.ASUMUOW will always have zero observations, until
you enable it in member IMACUOW.
I create dataset PDB.ASUMUOW by default in JCLPDB6, but
the default sets OPTIONS OBS=0 at the beginning and then
resets OBS back to the original value (using VMXGOPTR) at
the end of member ASUMUOW, so no data will be sorted or
merged until you turn it on. I really think that large
CICS and DB2 shops will find PDB.ASUMUOW better than its
predecessor PDB.CICS, but it can use lots of CPU & DASD,
so I think it safer to make you enable it. In addition,
IMACUOW now externalizes the output of the PROC SORTs so
you can send them to tape and save DASD space as well.
The options are documented in comments in both members.
Thanks to Mike O'Brien, McKesson General Medical, USA.
Change 15.220 -Support for NTSMF Version 2.1, COMPATIBLE with 15.03 or
EXNTCNRS later (MXG 15.03 was required for NTSMF Version 2.0).
IMACNTSM -Support for new Object 'Content Replication Service' adds
VMACNTSM creation of new dataset CONTRPSV.
Sep 26, 1997 -Existing dataset CONTNFI (Content Index Filter) has been
validated with data, with new CNFINAME instance.
-Existing CONTINDX (Content Index) has been validated with
data, with new CNINNAME instance.
-Existing IMAGE (Image) has been validated with data, with
two instance variables IMAGNAME and IMAGFILE.
-Existing MSEXCHMS (MSExchangeMSIM) object is validated,
and will have observations (if you change the misspelling
in IF UPCASE(OBJECT)='MXEXCHANGEMSIM' from MXEX.... to
MSEX...., even earlier versions of MXG will have obs!).
-Many new variables in CMPQxxxx datasets (from COMPAQ)
were not in the INFORMAT statement, which would cause
their values to be off by a factor or 100.
-The _BNTxxxx macros were not defined for all datasets,
and not all datasets were in the _SRTPRNL and _SRTPRNV
print macros.
-Member ADOCNTSM's list of datasets and Instance Variables
has been updated to include recently added objects.
-Variables CPUNUM1, FAMILY1, and MANUFAC1 and CPUSPED1 are
now decoded from the "0.0 configuration record" (new in
NTSMF 2.1).
-The location of the calculation of SMFTIME was relocated
so it does not generate "MISSING VALUES" message with 2.1
data; the value was re-calculated later and was never
actually missing.
Thanks to Jim Quigley, Con Edison, USA.
Thanks to Carmen Vitullo, Boeing, USA.
Change 15.219 -In CICINTRV, variables DSGAMXTL, DSGICVSD, DSGICVT, and
CICINTRV DSGTL are static values and should not have been DIF()
VMAC110 (as was DSGTL), and should not have been in SUM= nor
Sep 22, 1997 MEAN= statements, and are now in the ID= statement.
In spite of their mis-location, most of the time they
yielded correct values, so the error was overlooked.
(Note DSGTL only existed in CICS 3.3 and earlier)
-In VMAC110, the new A04 variables in the INPUT statement
begining with A04RDINT were all incorrectly labeled, and
the two time durations, A04RDINT and A04RDIDL had wrong
values with no TIME12.2 format.
-The SKIP=SKIP-220 for archaic CICS 3.1.0 if there were no
index segments and its INPUT +220 were changed to 218, to
suppress an "UNEXPECTED DATA" message that, while
harmless, could be eliminated.
Thanks to Dan Gilbert, Bergen Brunswig, USA.
Change 15.218 Support for CA's IDMS 14.0 (INCOMPATIBLE) splits existing
EXIDMDGB subtypes 1 and 16, adds new subtype 16 for new dataset
IMACIDMS IDMSDBG, and adds variables to IDMSBUF, IDMSINT, IDMSRUS,
VMACIDMS IDMSTAS, and IMDSTAW.
Sep 22, 1997
Thanks to Terry Heim, ECOLAB, USA.
Thanks to Martin Wieland, Neckermann B.V., THE NETHERLANDS.
Change 15.217 The default SMF TYPE in all IMAC members is normally the
IMACDALO the impossible value of 512 (so that JCLTEST6 does not
IMACENDV try to read the wrong record type), but these three IMAC
IMACSVCC members had values left over from testing; all are now
Sep 20, 1997 set to the 512 default value.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.216 DB2 Trace SMF type 102 Subtype 140 INPUT STATEMENT
VMAC102 EXCEEDED if there was no SQL text in the Audit record.
Sep 19, 1997 between NRSQLSEG=CEIL(( .... and DO SEGSQLT=1...
insert IF QW0140LL GE 2 THEN
so that the loop is only executed when there's text.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.215 IXFP records, MXG 15.02-MXG 15.04 only. A line was
VMACICE dropped by change 15.134, causing zero observations
Sep 16, 1997 for subtypes 2, 3, and 4 (datasets ICEBRGCH,DV,DR).
In the DO group for subtypes 1 thru 4, between the
INPUT of ICEVERS and COLLID, insert a line with +2
to skip over the two reserved bytes that were dropped
when ICEVERS's input was added by Change 15.133.
Thanks to Angela Mulcahey, Summit Bank, USA.
Change 15.214 MXG 15.01-MXG 15.04. Variable PCTMVSBY in TYPE70 is
ACHAP10 wrong. The new algorithm used by MXG in Change 15.023
VMAC7072 should only have been used for Wait Completion = Yes,
Sep 16, 1997 and although I think it is a better way to look at the
Sep 20, 1997 MVS busy time for WC=Yes, I decided to revert back to
match IBM's number while I do more research on the whole
subject of PR/SM, MDF, and MLPF instrumentation.
-Member ACHAP10, the MXG Chapter on Processor Utilization
has been revised to describe how PR/SM, MDF, and MLPF
can be measured, and includes description of how IBM
calculates PCTCPUBY and PCTMVSBY and PCTLnBY on their RMF
CPU Activity and Partition Data Reports. Numeric values
for Dedicated, Shared Wait=Yes, and Shared Wait=No LCPUs
are now provided. This article will be in the next MXG
Technical Newsletter and was posted to MXG-L Listserv.
-The test IF CPUWAIT GT 0 THEN DO; ... END; was removed
because CPUEFFTM and PCTMVSBY/PCTCPUBY were missing if an
LPAR was 100% busy in all LCPUS (the case noted was a
single LPAR); the test was unneeded because the block of
code is already inside the LPAR processing section.
-Calculation of PCTCPUBY and PCTMVSBY in TYPE70PR dataset
is made only in the TYPE70PR observation for the LPAR in
which that MVS System executed, because only that LPAR's
TYPE70PR observations knows what ORIGWAIT, the MVS Wait
time, was recorded for that LPAR's LCPUs. They will be
missing in TYPE70PR observations for other LPARs in that
type 70 record.
-Added variable NEWWAIT to TYPE70PR. NEWWAIT contains
the "wait" time that was actually added to CPUWAIT for
the calculation of CPUACTTM=CPUUPTM-CPUWAITM and for
the calculation of PCTCPUBY in TYPE70 dataset. This new
field may be useful to some sites with Dedicated or
Wait Completion=Yes to match some RMF calculations.
Thanks to Carl Downing, Blue Cross Blue Shield of Minnesota, USA.
Thanks to Jan Tits, Amdahl, BELGIUM.
Change 15.213 Support for type 91 SMF record new subtype 21, written by
EXTY9121 SMARTBATCH at data set close for each VSAM or non-VSAM
IMAC91 data set processed by the Data Accelerator component.
VMAC91 New MXG dataset TYPE9121 contains a wealth of statistics
Sep 12, 1997 and activity information for this new component.
Took real vacation to celebrate Judy and her twin's 50th birthday!
Change 15.212 Values for R744SSIZ (Structure Size) are now in 4096 byte
VMAC74 units, rather than the 4000 byte unit discussed in Change
Sep 3, 1997 14.328, probably beginning with OS/390 Release 1.2, so
the three lines multiplied by 4000 are now by 4096.
Note that R744SSIZ rather than R744QSIZ is used by RMF in
its reports as the allocated structure size.
Thanks to Tim VanderHoek, Fidelity Systems Company, USA.
Change 15.211 Candle's CL-Supersession PTF QLG1073 (Y2K support) sets
VMACNAF a value of yyyydddF (instead of 0cyydddF) for SMFSTAMP8
Sep 4, 1997 fields, causing 1997 dates to be in year 3897! While
Sep 26, 1997 Candle's choice is not illegal, SAS's SMFSTAMP8 informat
expected IBM's documented century-bit format, so it used
that first byte as the number of centuries after 1900.
While SAS has agreed to change their SMFSTAMP8 format to
support both yyyydddF and 0cyydddF formats, that fix
won't be available on all platforms until next year,
and as Candle's PTF creates the problem today, all 15
internal timestamps in VMACNAF are now protected by:
CENT=FLOOR(YEAR(DATEPART(datetime))/100);
IF CENT GE 38 THEN
datetime=datetime-59958230400+(CENT-38)*86400;
(The SMFTIME field in byte 3 of Candle's record was
not changed by their PTF, so it needed no protection!)
Update 26Sep97: Candle now says that if you put all of
these PTFs on: QLS1303,1304,1305,1306,1307,1308,1310 and
QLV1465, that their dates will conform to IBM's use of
the century bit.
Thanks to Joe Faska, Depository Trust, USA.
Change 15.210 Replaced by Change 15.218.
Change 15.209 MXG 15.04 only. TRNDTALO fails if TREND.TRNDTALO does
TRNDTALO not exist in your TREND library. Add the statement
Sep 2, 1997 OPTIONS NODSNFERR NOVNFERR; at the beginning of the
member to correct. Note that if you were previously
creating the TRNDTALO member, the new code did not
fail, so only first-time users of TRNDTALO got hit.
Note also that TRNDTALO requires that ASUMTALO be in
your WEEK library, so you will need to update your
WEEKBLD to propagate ASUMTALO before you can use the
trending in TRNDTALO.
Change 15.208 Cosmetic: comments /* _Lxxyyyy OUTPUTS TYPExxxx */
EXVMADSM are after each %INCLUDE SOURCLIB(EXxxyyyy); statement
VMACNTSM name the default MXG dataset for each _Lxxyyyy macro, to
VMAC80A make the MXG source code documentation, but seven new
VMAC99 datasets had wrong names or no comment. I block copy and
VMACSVCC revise when I can, but sometimes I overlook the comments.
Aug 31, 1997 But Freddie's sophisticated analysis of my source code
uncovered seven inconsistencies in MXG 15.04, and I plan
to add his QA to my QA before I build the next version!
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.207 CA-1/TMS 5.2 Change 15.199 had one incorrect new variable
VMACTMS5 DEFEXPOO. The second occurrence in the KEEP, LABEL, and
Aug 30, 1997 assignment should have been NRESTAPE.
Thanks to Freddie Arie, Lone Star Gas, USA.
===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=====
Change 15.206 NPM dataset NPMINPMT contained accumulated fields that
DIFF28 were deaccumulated inside VMAC28, but when SMF data was
TYPE28 sorted before MXG processing, wrong results occurred!
VMAC28 In addition, not all variables were deaccumulated that
Aug 28, 1997 should have been. This change adds new member DIFF28
that externally and correctly deaccumulates NPMINPMT.
DIFF28 is included by member TYPE28, but if you have
added type 28 processing to your BUILDPDB, then you must
add the statement %INCLUDE SOURCLIB(DIFF28);
in member EXPDBOUT to properly deaccumulate NPMINPMT.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 15.205 Alternative CICS Summarization, especially for MRO.
ANALUOW -Member ASUMUOW combines all of the pieces of CICS MRO
ASUMCICX transaction (i.e., TOR, AOR, and FOR records for the
ASUMUOW same Unit-of-Work are combined, and the correct TRANNAME
IMACCICS is picked up), and (if the transaction called DB2) also
TRNDCICX merges in all of the DB2ACCT records to create dataset
Aug 28, 1997 PDB.ASUMUOW that gives a complete picture of each CICS
unit-of-work. This revision to ASUMUOW adds CICS wait
durations/counts to PDB.ASUMUOW so you can determine the
cause of poor CICS reponse time.
-Member ANALUOW is a parameter driven report to examine
why CICS transactions were delayed, using PDB.ASUMUOW.
-Member ASUMCICX is an alternative summary member, like
ASUMCICS to create dataset PDB.CICS, but member ASUMCICX
will use dataset PDB.ASUMUOW as its input, and also keeps
the wait durations/counts.
-Member TRNDCICX is an alternative trending member, like
TRNDCICS, but it keeps the wait durations/counts.
If you have CICS MRO and/or CICS talking to DB2, you
should change the %INCLUDE SOURCLIB(ASUMCICS) in your
BUILDPDB job to %INCLUDE SOURCLIB(ASUMUOW,ASUMCICX) so as
to build both PDB.ASUMUOW and the enhanced PDB.CICS.
The JCLPDB6 example has been updated to build both.
The example macro _KCICTRN in member IMACCICS that keeps
only the variables needed by ASUMCICS has been revised
to keep the original ASUMCICS set or the new ASUMCICX
set of variables, to reduce the size of CICSTRAN.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.204 Tape Capacity Planning graphs based on TREND database
GRAFTAPE and MXG ASMTAPES tape allocation and trending records,
Aug 27, 1997 and also the HSC and LSM data from an STK silo.
If you saw Chuck's paper at CMG94, this is the code that
generated those graphs.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.203 Trending of NTSMF's NTINTRV dataset creates summarized
TRNDNTIN TREND.TRNDNTIM for long term trending of NTSMF systems
Aug 27, 1997 with minimal storage required.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.202 Enhanced measurement of Tape Allocation uses the Interval
TRNDTALO Allocation record created by ASMTAPES at ML-13, MXG 15.02
Aug 27, 1997 or later, so you must have installed ML-13 before you can
use this enhancement. The interval record eliminates any
undercounting of devices still allocated and improves the
accuracy of tape allocation counting.
TRNDTALO assumes you have created WEEK.ASUMTALO in your
WEEKBLD/WEEKBLDT member from your daily PDB.ASUMTALO data
sets; you will need to add the data step in your weekly.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.201 Related members in a way.
ASUMCACH ASUMCACH creates the union of the TYPE74_1 and TYPE74_5
ANALEMC data (device level and cache reporter). This is useful
EMCRANK in figuring out problems in the IO subsystem but it will
EMCMAP also be part of the "I/O Stimulator" that will generate
Aug 27, 1997 control cards for Stress Test based on your RMF data.
ANALEMC takes the ASUMCACH data and carries it a step
closer to the hardware by using a series of formats to
map the logical to the physical in an EMC world. It will
also do this for Spectris and HDS 7700 boxes but no
formats are required. It creates datasets RANK, RAIDVOL,
EMCMAP, and VOLUMES. Each is a slightly different level
of summarization except for EMCMAP which is used to apply
labels to graphs with the annotate facility of SAS/GRAPH.
EMCRANK and EMCMAP use the output of ANALEMC to build
graphs of the performance of EMC boxes. This is a grid
8*12 where each box represents on physical SCSI disk
on the inside of the box. Each box contains the VOLSER,
RANK, and DEVNR of the logical MVS volumes and EMCRANK
applies colors to represent IO rates. EMCMAP leaves all
of the boxes empty of everything except text to make the
text a little easier to read. Find the line that says if
text=:'EM' then color='ORANGE'; This is used to alter the
color of the text. In this code, volumes that contain no
data start with EM in the VOLSER. Making those volumes
ORANGE makes them stand out and is a quick visual
indicator of available capacity.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.200 Support for Peregrine's Service Center SMF record creates
EXTYSVCC new dataset TYPESVCC with one set of variables and two
IMACSVCC subtypes, which can be identified by variable SVCCTYPE:
TYPESVCC SVCCTYPE Description
VMACSVCC 1 Service Center Statistics
Aug 27, 1997 2 Service Center User Termination
Thanks to Chuck Hopf, MBNA, USA.
Change 15.199 Support for CA-1 aka TMS Release 5.2 (COMPATIBLE) adds
TYPETMS5 new flag variables to both DSNB and Volume records:
VMACTMS5 Dataset TMSREC:
Aug 25, 1997 Variable Description
ADDLFILS='ADDITIONAL*FILES*EXIST IN*VOLSET?'
COPYCAT ='CREATED*BY*COPYCAT?'
DEFEXPOO='DEFAULT*EXPDT*USED AT OPEN*OUTPUT?'
DEFEXPOO='NON*RESIDENT*TAPE?'
DEGAUSSD='TAPE*HAS BEEN*DEGAUSSED?'
EMVREL ='RELEASED*BY EXTERNAL VAULT*MANAGER?'
ERASEREQ='DATASET*ERASE*REQUIRED?'
FILEISCA='FILE*ON OS*CATALOG?'
SMSEXPIR='EXPIRED*BY SMS*MAX RETENTION?'
VAULTREQ='VAULT*SPECIFIC*REQUEST?'
VOLACTV ='ACTUAL*VOLSER*IN USE?'
Dataset DSNBREC:
Variable Description
DSNBABND='CLOSED* BY ABEND*PROCESS?'
DSNBDFXU='DEFAULT*EXPDT*USED?'
DSNBECAT='EXPIRED* BY CATLG*INTERFACE?'
DSNBISCA='FILE IS*ON OS*CATALOG?'
DSNBLBL ='B1*SECURITY*LABEL?'
DSNBTMSI='EXPIRED* BY TMS*INTERFACE?'
DSNBWSCA='FILE WAS*ON OS*CATALOG?'
The Release 5.2 data records show that TMS julian
dates in year 2000 are supported. The 311th day
in year 2000 will have julian data of 100311.
Thanks to Xiaobo Zhang, Insurance Services Office, Inc, USA.
Change 15.198 CICS reports were updated to add new data step for CICLDR
ANALCISH processing to calculate the "average fetch time" where
Aug 25, 1997 previously the "total fetch time" was printed.
Thanks to ???, ???, USA.
Change 15.197 ACF2 dataset ACF2JR did not populate variable ACLFLDVL
VMACACF2 if ACLARCFL=02x, because that field type had not been
Aug 24, 1997 previously seen. The data value is a hex string rather
than the EBCDIC characters normally stored in ACLFLDVL,
but rather than creating yet another variable for the
hex representation, I chose to use ACFLLDVL, but to
convert it to the printable-hex value using:
SUBSTR(ACLFLDVL,1,2*ACLFLDLG)=PUT(ACLFLDVL,$HEX100.);
so the three-byte data value of '010203'x in the ACF2
record will cause ACLFLDVL to contain six bytes 010203
as printable characters.
Thanks to Peter J. Lines, NatWest Bank, SCOTLAND.
Change 15.196 New utility old-style MACRO _SMFGOOD defined in VMACSMF
VMACSMF was needed to read an SMF tape with truncated records at
Aug 24, 1997 the end of each block followed by a trashed record at the
start of the next block. As an example of its use:
MACRO STOPOVER MISSOVER %
%INCLUDE SOURCLIB(VMACSMF,VMAC80A);
DATA _VAR80A; _SMFGOOD ; _SMF ; _CDE80A ; RUN;
deletes the trashed records and prevents invalid-smftime
error messages and hex record dumps from being printed,
while the MISSOVER prevents input-statement-exceeded
errors from causing stopover on the truncated records.
At the same time, variable SMFRECNR is now created in the
_SMF macro, so it can be added to a _Kxxxyyy macro if you
need to know which SMF record created an observation.
Very few users will need to use these enhancements!
Change 15.195 Support for ObjectStar 3.0 SMF record. While the record
VMACHURN changes themselves were compatibly made, you must change
Aug 23, 1997 VMACHURN to read them. Change IF SMFHVR EQ 02X THEN DO;
Aug 26, 1997 to read IF SMFHVR LT 02X THEN DO; and MXG will tolerate
(i.e., process the records correctly) Version 3.0, but to
exploit (i.e., pick up the new fields) you will need this
change.
New dataset HURN06 Lock Manager Statistics is created for
both subtype 22 (Interval) and subtype 6 (Termination)
as both records are identical in structure.
New fields were added to existing datasets:
Control Region Start Time variables HU50CRTM, HU51CRTM
HU52CRTM HU60CRTM HU61CRTM HU62CRTM and HU72CRTM are
added to HURN501 HURN511 HURN521 HURN601 HURN611
HURN621 and HURN721 datasets.
Control Region Session Identifier variables HU60UNQI
HU61UNQI HU62UNQI HU72UNQI are added to HURN602
HURN612 HURN622 and HURN722 datasets.
Thanks to Trevor Ede, Bank of New Zealand Ltd, NEW ZEALAND
Thanks to Glenn Bowman, Wakefern Food Corporation, USA.
Change 15.194 The MXG default for MEMSIZE was raised to 64M (from 48M)
CONFIG because if you add lots of additional record processing
Aug 22, 1997 (DMON,ENDV,FOCU,HSM,IDMS,28,NSPY,NTCP,PROS,80A,SASU,
STC,SYNC, and X37, for example!), you will need slightly
more than 48M of virtual addressability. Since there is
no cost to large virtual storage limit for programs that
do not need it, changing the MXG Maximum Default may save
someone diagnostic time to resolve OUT OF MEMORY errors.
The symptoms were that the IEF374I message on SYSLOG had:
VIRT = 1572K SYS = 308K EXT = 47316K SYS=10768K
the EXT value suggested a 48M limit was set somewhere!
Why 64M? Why not 80M? No good reason.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
Thanks to Susan Walters, Michelin Tires, USA.
Change 15.193 Another invalid '04' Catalog Cell requires protection.
VMAC6156 Add the IF SKIP GE 2 THEN DO; and END; statements
VMACCTLG around the two statements to end up with:
Aug 22, 1997 IF SKIP GE 2 THEN DO;
INPUT VOLHKYLN &PIB.2. @;
SKIP=SKIP-2;
END;
The '04' cell had nulls for VOLSER, and only had a low
key range; the high key range was non-existent.
Thanks to Dave Millard, Southern California Edison, USA.
Change 15.192 Support for HMF SMF record Subtype 11 (DS3 Statistics)
DIFFHMF adds new dataset TYPEHMFB, with 44 counter and endpoint
EXTYHMFB values for each link (HMFBUSNO) during each polled
IMACHMF interval. Since the HMF counters are accumulated, the
VMACHMF dataset TYPEHMFB must be de-accumulated by logic added
Aug 21, 1997 to DIFFHMF. Sep 2 update: all non-endpoint counters
Sep 2, 1997 are protected for wrapping.
Thanks to Anne Robbins, Bank of New York, USA.
Change 15.191 ANALDB2R fails with ERROR 31-185 if the SORTBY list did
ANALDB2R not contain PLAN. The error was because variable PACKID
Aug 19, 1997 was not initialized as character; as long as PLAN was in
the SORTBY list, PACKID's definition was picked up by the
assignment IF ... THEN PACKID=PLAN; but that statement
was not generated when SORTBY did not list PLAN.
To correct: Find %MACRO PMACC02; and then find
RETAIN PAGENUM; (about 957 lines later) and then insert
LENGTH PACKID $18; after that RETAIN statement.
Thanks to John Shuck, SunTrust Companies, USA.
Change 15.190 Support for 5 new NTSMF Objects, validation of untested
ADOCNTSM objects and some new counters, and utility for Discovery
EXNTCNME Records.
EXNTFULC -Five new NTSMF Objects create six new datasets:
EXNTPEP5 Dataset Object Name
ENNTSNAA CONECTME Connect-ME
EXNTSNAC FULCRUM Fulcrum Server
EXNTWBSS SNAADAPT SNA ADAPTER SNAD1c1
IMACNTSM SNACONN SNA Connections
VMACNTSM WEBPRSRV WEB Proxy Server Service
Aug 19, 1997 PENTP5 PENTIUM (see next note)
Aug 25, 1997 -Two forms of the PENTIUM object exist. For PENTIUM PRO P6
processors, the record contains the expected 68 fields to
output in the PENTIUM dataset, but for PENTIUM P5, there
there are only 58 fields, with completely different field
names, so the new PENTP5 dataset is now created from
PENTIUM objects with only 58 fields. Instead of sensible
variable names, variables PENTP501-PENTP548 are created
(its a lot quicker, and I expect little need for these
counters); there are only 48 variables because ten of the
fields are place-holders.
Mark has discovered that for either Pentium object, only
two pairs of Pentium counters can be enabled at a time,
and the counter values are accumulated so that you will
need to subtract adjacent observations to calculate the
delta using SAS's DIF() function until MXG provides a
de-accumulation member, but this support is probably all
that is needed for this hardware-level data.
-Five untested NTSMF records have been validated; three
have instance names (cannot tell without test data, as
the Discovery records do not identify instances):
Dataset Object Name Instance
MSEXCHIP MSEXCHANGE INTERNET PROTOCOLS PROTNAME
MSEXCHIS MSEXCHANGEIS 3 new vars
MSEXCHMC MSEACHANGEMTA CONNECTIONS CONNNAME
MSEXCHPU MSEXCHANGEIS PUBLIC 35 new vars
NETWSEGM NETWORK SEGMENT SEGMNAME
-The new utility macro, _UNTDISC, that can be used to
print the Discovery records, is defined in VMACNTSM,
and comments before the MACRO definition show how to
use the utility to find new counters and new objects.
-In Microsoft's NT Resource Kit, there is a utility
\PerfTool\CntrTool\Cntrlist.exe that will provide detail
explain text for all counters; unfortunately it does not
always work in decoding new objects and has been known to
abend, and Microsoft does not support their ResKit, but
now you know it is there.
Thanks to Jim Quigley, Consolidated Edison, USA.
Change 15.189 Support for new ADSM VM Account Records from VM/ESA.
IMACVM New dataset VMADSM matches the TYPE42AD dataset created
TYPEVM from type 42 subtype 14 SMF records on OS/390 and MVS.
VMAC42 While MVS puts the data in one SMF record, VM Accounting,
Aug 15, 1997 forever limited to an 80 byte physical card image record,
has broken new ground by defining subtype and sequence
numbers so that more than 80 bytes can be recorded for an
account event. The subtype 1 and subtype 2 of the 'C0'
must be found in sequence in the VM Accounting input, or
MXG will Delete with Error Message. Since Multiple User
products can create 'C0' VM Accounting Records, the User
ID Name of the ADSM Server must be hardcoded in TYPEVM;
MXG expects the name to start with DSMSERV or records
will not be recognized by MXG as ADSM-created. The new
variable CLSESTYP is now created also in TYPE42AD; that
location was a reserved field in original ADSM SMF doc.
VM also creates a subtype 3 ADSM record, but I need test
data to decode and validate that record.
I took this opportunity to update the VM Accounting
Support in MXG; the _KVMxxxx macros defined in IMACACCT
are now actually referenced in the TYPEVM Data Statement
and labels for the data sets were clarified:
VMID Dataset Description
01/C1 VMSESSN Virtual Machine Resource Usage
02/C2 none Dedicated Devices
03/C3 none Temporary Disk Space
04 VMLOGON Invalid LOGON Password
05 VMDISK LINK to Not-Owned Protected Disk
06 VMLINK Invalid LINK Password
07 VMVCNA SNA/CCS Logoff/Disconnect
08 VMLOGOFF User Logoff/Disconnect/Shutdown/Force
09 none ACNT ALL - ISFC Accounting
ISFC Initialization ISFI Accounting
ISFC Conversation Accounting
ISFS - Conversation Start
ISFA - Conversation Active
ISFE - Conversation End
ISFC Link Statistics ISFL
ISFC Termination Accounting ISFT
0B VMDEVICE Virtual Disk in Storage
C0 VMADSM USER=:DSMSERV ADSM Accounting
VMRSCS USER=:RSCS RSCS Accounting
VMSQLxxx USER=:SQLDBA SQL Accounting
VMSQLINI SQL INIT
VMSQLSYS SQL SYSTEM
VMSQLTRM SQL TERM
VMSQLUSR SQL LOCAL USER
VMSQLRMT SQL REMOTE USER
VMUSRDAT USER=other USER Data
The datasets listed as "none" will be created when test
data is provided. The VM/ESA Account records still do
not contain four-digit years (except in new ADSM record)
but MXG's Change 15.167 does protect VM Account Records
for the year 2000.
Note: CHANGE 28.157 Added Support for the 09 record.
Thanks to Ned Hammond, American Management Systems, USA.
Change 15.188 OPC 3.1 dataset OPC31 had bad values in some variables
VMACOPC because 19 reserved bytes after ETCNAME were not skipped.
Aug 15, 1997 -Insert +19 between ETCNAME and ETCDESC to correct.
-Dataset OPC23 only had obs for TRLEVT23='C' (Completed)
or 'E' (Error). Now, events 'S' (Start) and 'X' (Reset)
are also output, but date variable TRLDUR23 is nonmissing
only for the 'C' and 'E' events.
-Invalid OPC29 records have been observed, but are thought
to be an IBM problem, which is under investigation.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 15.187 CMF. Variable C279SSI in dataset CMF27C93 was INPUT as
VMACCMF &PIB.2., while variable C279CSSI in dataset CMF27CSC was
Aug 7, 1997 INPUT as $CHAR2., but both variables are Subsystem ID,
Aug 28, 1997 and should be the same so they can be MERGED. Therefore
add variable C279SSI to the $HEX4. format list, and
change C279SSI &PIB.2. to C279SSI $CHAR2.
-Aug 28: New variable C279DDIC is created by adding the
Base address to the Device ID and converting to character
so that new variable C279DDIC matches CMF27UA1 in the
CMF27CSC dataset, because merging datasets CMF27CSC and
CSC27C93 must be done BY both SSI and DDI.
C279DDIC=SUBSTR(PUT(INPUT(CMF27CCU,S370FPIB2.)+
INPUT(C279DDI,S370FPIB1.),HEX8.),5,4);
Thanks to Neil Ervin, Banc One Services Corporation, USA.
Change 15.186 STK 4400 SMF records. STCLMU dataset character variables
VMACSTC LSBECON1 and LSBECON2 were $CHAR6 fields, but are now
Aug 6, 1997 replaced with four variables:
LSBELSM1='PASSTHRU*PORT 1*CONNECTED TO*LSM'
LSBEPAN1='PASSTHRU*PORT 1*CONNECTED TO*PANEL;
LSBELSM2='PASSTHRU*PORT 2*CONNECTED TO*LSM'
LSBEPAN2='PASSTHRU*PORT 2*CONNECTED TO*PANEL'
Thanks to Bob Gauthier, American Stores Company, USA.
Thanks to Bruce Sloss, PNC Financial Corporation, USA.
Change 15.185 ACF/VTAM. Type 50 produced zero observations because the
VMAC50 records are now greater than 78 bytes (although I still
Aug 6, 1997 can find no documentation of the IBM change). The test
LENGTH EQ 78+OFFSMF must be LENGTH GE 78+OFFSMF. Also,
variable NCPSLOWS may be defective, as it has values of
zero or 7FFFFFFx (which I am also pursuing with IBM).
Note added Sep 30: It is not possible to distinguish
between an XCF MPC Group Record and a non-XCF MPC Group
record using ATTCHTYP or VERSNO, but for an XCF MPC
Group record, both DEV and BSIZE will be zero, while for
a non-XCF MPC Group record, at least one will be nonzero.
Thanks to Bill Feeney, Hennepin County, USA.
Change 15.184 TMON/DB2. Change 15.114 did not properly handle the "DE"
VMACTMDB record, which only has part of the standard header. Also
Aug 6, 1997 the dates input with MMDDYY informat were changed to use
&NUM.2 so that VMACTMDB will correctly execute under
ASCII systems as well as under MVS.
Thanks to Luc Gariepy, Regie des rentes du Quebec, CANADA
Change 15.183 Dataset TYPE72GO could have observations OUTPUT that had
VMAC7072 no resource consumption for that period, because the MXG
Aug 4, 1997 variable NOACTVTY was not reset to 0 for the second and
subsequent periods within a Service Class. The new test
for _I_ GE 2 was added to zero NOACTVTY (which is then
used in EXTY72GO to control execution of the OUTPUT):
DO _I_=1 TO NRSCS;
IF _I_ GE 2 THEN NOACTVTY=0;
INPUT @COLSCS
Thanks to Ove Dall-Hansen, CODAN Insurance, DENMARK.
Change 15.182 Variable VELOCITY in TYPE72GO was wrong for service class
VMAC7072 periods with Discretionary or System goals; the value was
Aug 4, 1997 carried forward from prior periods. Since neither System
nor Discretionary goals have velocity, the variable is
now set missing with:
ELSE IF R723CRGF='S' OR R723CRGF='D' THEN DO;
PERFINDX=.;
END;
Thanks to Brenda Rabinowitz,
Change 15.181 INVALID ARGUMENT TO FUNCTION INPUT in BETA93 SMF record
VMACBETA is caused by a value of '*RELOAD*' in the JCTJOBID field
Aug 4, 1997 from which MXG extracts the job's JES Number JESNR, for
the BETA93 RELOAD step. Adding two question marks:
JESNR=INPUT(SUBSTR(JCTJOBID,4,5), ?? 5.);
to the INPUT function supresses the NOTE and the hex dump
of the input record. With or without the question-mark
modifiers, JESNR will be a missing value.
Thanks to Winfried Waldeyer, BHF-Bank Frankfurt, GERMANY.
Change 15.180 SAS Compiler Error under Windows 95 and Windows NT when
VMACVMON old-style macro has text in column 1 is circumvented in
VMACVMXA MXG by ensuring a blank is in column one in the MXG code
VMACXAM members that worked under MVS but failed under Windows.
ANALDBTR This error was seen long ago, when initially testing MXG
Aug 3, 1997 on ASCII platforms; it showed up now as I began testing
of all of MXG under Windows. The symptom was a SAS error
message "Variable ACTIVEDSVMAXUS longer than 8 bytes",
(even though ACTIVE and DVSMAXUS were on separate source
lines), but the variable names are in an old-style macro
and the variable name started in column one! Inserting a
blank in column eliminates the compiler's confusion in
these members previously untested on ASCII platforms.
Change 15.179 -Boole & Babbage MainView for CICS (was CICS Manager) will
IMACICBB support the year 2000 in MV for CICS Release 5.2. Their
YEAR2000 date yymmdd0F will be changed INCOMPATIBLY to yyyymmdd,
Aug 1, 1997 so you will need MXG 15.04 or later before you install
that release (late 1997?), if you have enabled IMACICBB
to process their statistics segments in type 110 SMF
records. MXG tests the 0F byte to determine the format.
-Boole & Babbage MainView for IMS (was IMF) will support
the year 2000 in Release 3.2, using yyyydddF format in
place of 00yydddF, but MXG already supported that format
so there was no MXG change to TYPECIMS code.
-Boole informed me that CONTROL-D is a New Dimension Co
product (although it is marketed by Boole in Europe), so
I have updated that product, as well as Boole's products
in member YEAR2000.
Thanks to whoever told Boole marketing about YEAR2000 on www.MXG.com!
Change 15.178 Example macro definitions for _KCICTRN that will keep
IMACCICS only CICSTRAN variables that are needed for ASUMCICS or
Aug 1, 1997 ASUMUOW have been added to member IMACCICS (although they
are commented out). See CICS Technical Note in MXG
Newsletter THIRTY-TWO or comments in IMACCICS itself.
Thanks to Mark Cohen, DTS, ITALY.
Change 15.177 -Typos: after DDD=MOD(MVLCDATE ... change IF 0 LE DDD to
VMACEDGS IF 0 LT DDD. Remove the second occurrence of MVEXPDT in
Aug 1, 1997 the FORMAT statement.
-Logic change. DFSMS/rmm variables MVEXPDT and MKDELDAT
can have value 1999366 as a "never expire" date, but that
is an invalid SAS date. MXG's DCOLLECT algorithm is now
used for these values, and the date is set to the future
date in year 2099 (and the original value is available in
character variable MVEXPDTO for MVEXPDT, although there
is no corresponding character variable for MKDELDAT):
IF DDD GT 366 OR (YY=99 AND DDD GE 365) THEN DO;
MVEXPDT='31DEC2099'D;
END;
Thanks to Peter Young, University of Toronto, CANADA.
Change 15.176 Invalid Catalog Cell '05'x caused INPUT STATEMENT EXCEED
VMACCTLG error. The cell began at byte 279, with Length of Cell
VMAC6156 '2E'x (46) bytes, and at byte 284 the count of four-byte
Aug 1, 1997 segments following is '5C'x (92), so MXG attempted to
read 92*4=368 bytes of GAT segments, but there were only
40 bytes left in the record. To circumvent this IBM
error, MXG had to add code to validate that the number of
segments is consistent with the cell length:
Change DO _I_=1 TO GATCNT;
to IF GATCNG*4 LE SKIP THEN DO _I_=1 TO GATCNT;
and after the END; statement for that DO group, insert:
ELSE DO;
INPUT +SKIP @;
SKIP=0;
NB615605+1;
IF NB615605=1 THEN DO;
PUT // ' *** INVALID CATALOG CELL 05 SKIPPED.'/
_N_= SMFTYPE= SYSTEM= JOB= LENTHIS= GATCNT= COL= ;
LIST;
END;
END;
Thanks to Shana Bereznay, Southern California Edison, USA
Change 15.175 CICS formats $MGCICDL and $MGCICDS that decode variables
FORMATS LDGDSAIN, SMDDSAIN, SMSDSAIN, and SMTDSAIN printed trash
Jul 29, 1997 because the syntax 01X= was used (a numeric hex value)
instead of the '01'X syntax that is needed for character
values. SAS could not raise an error condition, because
(due to legacy considerations) both quoted and unquoted
strings are valid syntax. Adding quotes corrects.
Thanks to Larry Gray, Lowe's Companies, Inc, USA.
Change 15.174 Using ANALCNCR with an INTERVAL greater than 24 hours
ANALCNCR produced valid results, but cause a very large number of
Jul 29, 1997 unnecessary observations to be created in the work file,
because SYNCINTV=YES was set by default. Now, the large
interval value will be recognized and SYNCINTV=NO will be
forced (and a note to that effect printed on the log).
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 15.173 A question on MXG-L concerning how to merge DB2 Trace
ANALDBTR records with DB2ACCT and CICSTRAN data has resulted in
Jul 29, 1997 an new example program in member ANALDBXX. The example
uses ANALDBTR, but an new options, UOWSORT, had to be
created in ANALDBTR. UOWSORT=YES causes variables
NETSNAME and UOWTIME to be kept in all dataset pairs
created by ANALDBTR, and also causes those variables to
be added to the BY list in each sort. This example will
likely become a new option in ANALDB2R in the future,
but this working example is provided for use now.
Member ANALDBXX removed when ANALDB2R was updated.
Thanks to Michael Frey, COMLAB GmbH, GERMANY.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.172 Support for Xerox's XPSM Version 2 (Xerox Print Services
VMACXPSM Manager) Host Accounting Record (INCOMPATIBLE). The new
ZMACXPSM record is a complete restructure of the original record,
Jul 29, 1997 but contains much new and useful information if you are
using XPSM. Among the major additions are:
- The record now contains all fields in IBM's type 6
record for PSF, and MXG uses the same variable names
that you know from TYPE6 processing
- Unlike IBM's type 6, the XPSM V2 record contains the
Account Fields from the Job card, plus a "Department
Account", so it is not necessary to merge TYPEXPSM
with type 30 data to charge back XPSM printing, and
you can account for jobs printed after the job purge
record has been created (e.g., output sent to remote
print servers).
- Repeated segments contains multiple names of Forms,
Overlays, Fonts, Images, Templates, and Colors.
MXG keeps first eight values (three for colors).
- Printer setup names JDL and JDE used.
- Remote Server section provides timestamps of begin and
end of transmission and begin/end of printing.
- MVS Host CPU time (TCB,SRB,RCT,IPT,HPT) are captured.
- MVS I/O SSCH counts and spool size for each DASD and
Printer device used are available, although MXG has
only implemented capture of the totals (a dataset for
each DD will be implemented when requested).
- CPU of cost of data stream transformation (eg, LCDS to
PCL) is captured.
- Outage and change of state information is provided.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 15.171 HSM dataset DGN's variable DGNDCL was blank because the
JCLHSM INPUT DGNDCI should have been INPUT DGNDCL. Several
VMXGHSM non-existent variables were removed from the KEEP= list
Jul 28, 1997 for datasets MCP and DGN. The now-nonexistent option
DQUOTE was removed from JCLHSM. The %VMXGHALL macro
used in the MXG QA job, was updated so that all of the
HSM datasets are created; this accounts for new datasets
BCR, BVR, DCL, DCR, DGN, MCB, MCC, MCM, MCP, MCPDGN, and
MCT now being listed in member DOCVER.
Thanks to Peter Young, University of Toronto, CANADA.
Change 15.170 Support for OS/390 Version 2 Release 4.
VMAC1415 -TYPE1415: Variables PROGRAM and STEPNAME were added:
VMAC26J2 (MXG's ANALDSET, which is still needed to correctly de-
VMAC30 accumulate EXCP counts from 14/15's has always picked up
EXTY4237 PROGRAM and STEPNAME, but having them directly in these
IMAC42 records is long overdue!).
VMAC71 -TYPE26J2: New workload management section added:
VMAC7072 JOBMODE0='JOB RAN*IN*MODE=WLM?'
VMAC42 JOBMODE1='JOB RAN*BECAUSE*OF $S J?'
VMAC74 SMF26WCL='SERVICE*CLASS AT*EXECUTION'
Jul 23, 1997 SMF26WIN='JOB*INDICATORS'
SMF26WJC='JOB*CLASS'
SMF26WOC='ORIGINAL*SERVICE*CLASS'
SMF26WSE='SCHEDULING*ENVIRONMENT'
-TYPE30: datasets TYPE30_V, TYPE30_4, TYPE30_5 and
TYPE30_6 have important new data:
-New DASD-only Connect/Disconnect/Pending time plus
SSCH counts for ASID plus Dependent Enclaves and for
Independent Enclaves (added by OS/390 R1.3).
SMF30AIC='DASD CONNECT*ASID PLUS*DEPENDENT'
SMF30AID='DASD DISCONNECT*ASID PLUS*DEPENDENT'
SMF30AIS='DASD SSCH*ASID PLUS*DEPENDENT'
SMF30AIW='DASD PEND+CU*ASID PLUS*DEPENDENT'
SMF30EIC='DASD CONNECT*INDEPENDENT*ENCLAVES'
SMF30EID='DASD DISCONNECT*INDEPENDENT*ENCLAVES'
SMF30EIS='DASD SSCH*INDEPENDENT*ENCLAVES'
SMF30EIW='DASD PEND+CU*INDEPENDENT*ENCLAVES'
-CPU for Dependent Enclaves is recorded:
CPUDETTM='DEPENDENT*ENCLAVE*CPU TIME'
-Residency time in Page-Seconds in ESTORE was added,
but CSTORE residency is not (yet?) provided:
RESESFTM='ESTORE*RESIDENCY*PAGESECS'
-New Scheduling Environment (when WLM owns Initiators
and adds/drains INITs to meet Service Objectives!)
add several important durations and flags:
SMF30HQT='JOB*HOLD*TIME'
SMF30JQT='JOB*PREPARATION*TIME'
SMF30PFF='JOB INIT*WAS FORCED*BY OPERATOR?'
SMF30PFL='SCHEDULING*ENVIRONMENT*NAME'
SMF30PFR='SRVCLASS*WAS MODIFIED*DURING*EXECUTION?'
SMF30PRJ='SRVCLASS*WAS MODIFIED*PRIOR TO*INIT?'
SMF30RQT='INELIGIBLE*FOR*EXECUTION*TIME'
SMF30RTR='JOB*HAS*BEEN*RESTARTED?'
SMF30SQT='ELIGIBLE*FOR*EXECUTION*TIME'
-TYPE42: new subtype 9 creates new dataset TYPE4237
for every B37/D37/E37 (out of space) ABEND. The record
is useful for tracking these abends, but I have asked
for the record to be (optionally) written when datasets
are extended (so you could track those jobs/datasets that
are going to abend before they do!). Variables are:
DISP ='DISPOSITION'
DSNAME ='DATA SET NAME'
DSORG ='DSORG'
JOB ='JOB NAME*OR*TSO USER'
LOCLINFO='LOCAL*INSTALLATION*FIELD'
READTIME='READ-IN*OR LOGON*EVENT'
S42ABEND='S42FLAGS*B37 OR*D37 OR*E37?'
S42ADRLH='S42ADRLH*AVERAGE*BLOCK*LENGTH'
S42ASSAT='S42ASSAT*SECONDARY*ALLOCATION*AMOUNT'
S42ASYID='S42ASYID*SYSTEM*ID'
S42DCNME='S42DCNME*DATA*CLASS*NAME'
S42MCNME='S42MCNME*MANAGEMENT*CLASS*NAME'
S42NEXT ='S42NEXT*NUMBER OF*EXTENDS*THIS VOL'
S42SCNME='S42SCNME*STORAGE*CLASS*NAME'
S42TNTRK='S42TNTRK*TOTAL*TRACKS*THIS VOLUME'
S42UCBTP='S42UCBTP*UCB*TYPE'
STEPNR ='STEP*NUMBER'
VOLSER ='VOLUME*SERIAL*NUMBER'
-TYPE71: new counts of frames in CSTORE/ESTORE includes
available, and low/medium/high impact frames in memory:
CSFRAVMN='SMF71CAM*MIN*CSTORE*FRAMES*AVAILABLE'
CSFRAVMX='SMF71CAX*MAX*CSTORE*FRAMES*AVAILABLE'
CSFRAVAV='SMF71CAA*AVE*CSTORE*FRAMES*AVAILABLE'
CSFRLOMN='SMF71CLM*MIN*CSTORE*LOW IMPACT*FRAMES'
CSFRLOMX='SMF71CLX*MAX*CSTORE*LOW IMPACT*FRAMES'
CSFRLOAV='SMF71CLA*AVE*CSTORE*LOW IMPACT*FRAMES'
CSFRMEMN='SMF71CMM*MIN*CSTORE*MED IMPACT*FRAMES'
CSFRMEMX='SMF71CMX*MAX*CSTORE*MED IMPACT*FRAMES'
CSFRMEAV='SMF71CMA*AVE*CSTORE*MED IMPACT*FRAMES'
CSFRHIMN='SMF71CHM*MIN*CSTORE*HIGH IMPACT*FRAMES'
CSFRHIMX='SMF71CHX*MAX*CSTORE*HIGH IMPACT*FRAMES'
CSFRHIAV='SMF71CHA*AVE*CSTORE*HIGH IMPACT*FRAMES'
ESFRAVMN='SMF71EAM*MIN*ESTORE*FRAMES*AVAILABLE'
ESFRAVMX='SMF71EAX*MAX*ESTORE*FRAMES*AVAILABLE'
ESFRAVAV='SMF71EAA*AVE*ESTORE*FRAMES*AVAILABLE'
ESFRLOMN='SMF71ELM*MIN*ESTORE*LOW IMPACT*FRAMES'
ESFRLOMX='SMF71ELX*MAX*ESTORE*LOW IMPACT*FRAMES'
ESFRLOAV='SMF71ELA*AVE*ESTORE*LOW IMPACT*FRAMES'
ESFRMEAV='SMF71EMM*MIN*ESTORE*MED IMPACT*FRAMES'
ESFRMEMN='SMF71EMX*MAX*ESTORE*MED IMPACT*FRAMES'
ESFRMEMX='SMF71EMA*AVE*ESTORE*MED IMPACT*FRAMES'
ESFRHIMN='SMF71EHM*MIN*ESTORE*HIGH IMPACT*FRAMES'
ESFRHIMX='SMF71EHX*MAX*ESTORE*HIGH IMPACT*FRAMES'
ESFRHIAV='SMF71EHA*AVG*ESTORE*HIGH IMPACT*FRAMES'
Note of Sep 16, 1997: IBM will not publish the UIC
values that define High, Medium, or Low Impact,
because "the UIC ranges depend on whether the system
is in goal or compatibility mode and several OPT
settings. These are values that may change in the
future. The idea of reporting these buckets was
just to get a high level view of how much stress
there is on the system's storage."
-TYPE72: support for WLM Managed Initiators added new
total sample count that includes batch queue delays,
so the calculation of VALDSAMP now also includes any
batch queue delays; batch queue delay is measured as are
three components, and the DASD IOS Queue Time is also
measured in dataset TYPE72GO:
PCTDLTDQ='TOTAL*(INCLUDES BATCH)*DELAY*SAMPLES'
PCTEXTSA='TOTAL*EXECUTION*SAMPLES'
R723CDQT='TOTAL*BATCH*QUEUE*DELAY*TIME'
R723CADT='INELIGIBLE*AFFINITY*DELAY TIME'
R723CIQT='INELIGIBLE*OTHER RESOURCE*DELAY TIME'
R723CCVT='JCL*CONVERSION*DELAY TIME'
R723CIOT='DASD*IOS*QUEUE TIME'
And dataset TYPE72DL has one new variable:
R723RWNL='STATE WITH*WAIT FOR*NEW LATCH'
-TYPE74: Coupling Facility dataset TYPE74CF now has the
model, version and level information:
R744FMOD='COUPLING*FACILITY*MODEL'
R744FVER='COUPLING*FACILITY*VERSION'
R744VLVL='COUPLING*FACILITY*LEVEL'
An additional change to BUILDPDB to add the new hold
delays (from which TYPRUN=HOLD time can be calculated)
will be available in the next version of MXG.
Revised, Nov 11, 1998: Enhancements to System Logger SMF
type 88 and OAM SMF type 85 records were supported in
MXG 16.06, Changes 16.265 and 16.255.
Change 15.169 Inconsistencies between MVS and ASCII versions of SAS
VMACOPC prevented some MXG members from being executable on the
VMXGINIT ASCII platform. While these members are not likely to
VMXGVTOC be used on the ASCII platforms, by making their code
Jul 22, 1997 transparently execute on all SAS platforms, I can run
the MXG QA stream anywhere, so changes were made:
-ASCII SAS does not accept RECFM=VBS, and MVS SAS does
not accept RECFM=S370VBS, so macro variable VMXGVBS
is now defined in member VMXGINIT to allow member
VMACOPC to execute. All other usage of VBS was already
protected by other means.
-ASCII SAS does not accept INFILE options CCHHR VTOC so
a local %MACRO VMXGCHR is created in VMXGVTOC (even
though that is a very archaic member).
Change 15.168 No observations in NETSPY dataset NSPYTIC3 because the
VMACNSPY logic inside NSPYREC='N' code to identify subtype used
Jul 22, 1997 either NSPNRECI or NSPNSUBT values, but the value '01'x
for NSPNSUBT exists in both Ethernet and TIC3 records, so
TIC3 observations were erroneously OUTPUT in NSPYETHR.
Now, all tests use ONLY variable NSPNRECI, but changing
ELSE IF NSPNRECI='06'X OR NSPNSUBT='01'X THEN ..
ELSE IF NSPNRECI='06'X THEN ...
will correct the immediate problem.
Also, the last alert in each record was not output in the
NSPYALRT dataset, and the second and later were corrupted
because the statement:
OFFNSPY=OFFNSPY-10;
that was just before the INCLUDE SOURCLIB(EXNSPYAL);
should not have been there and must be deleted.
Thanks to Mrs. Silvia Hug, RWG GmbH, GERMANY.
Thanks to Mr. Karl-Heinz Placht, RWG GmbH, GERMANY.
Change 15.167 MXG now protects all two-digit YY dates for year 2000.
IMACICBB Since IBM and other vendors have not expanded all of the
TYPEDMS two-digit YY dates, and since it is likely that some MXG
TYPEMON8 sites will still be back level on some of those products
TYPEMONI that are not year-2000 compliant, and since I could cover
TYPEPDL for the negligent products, I have extended Change 15.050
TYPETMON and have added logic to "Window" all dates that are not
TYPEVM year-2000 compliant. Years 00-59 will be set to 20xx
VMAC28 while years 60-99 will be set to 19xx.
VMACCTLD In some members, this protection was added using:
VMACIPAC IF YEAR(DATEPART(datetime)) LE 1959 THEN
VMACNSM datetime=datetime+YEARSECS;
VMACNSPY where RETAIN YEARSECS 3155673600; is used to store the
VMACODS number of seconds between 1Jan1900 and 1Jan2000.
VMACOPC In other cases, the protection was added using:
VMACQTRT IF YEAR(date) LE 1959 THEN date=date+YEARDAYS;
VMACRMDS where RETAIN YEARDAYS 14610 is used to store the number
VMACROSC of days between 1Jan1900 and 1Jan2000.
VMACSAR
VMACTMDB Member YEAR2000 has been updated to show which dates
VMACVMXP are truly year 2000 compliant (and the APAR which made
VMACXAM them so) and to show which dates are not compliant but
YEAR2000 are now protected by MXG Logic to support the year 2000.
Jul 20, 1997
Change 15.166 Support for Catalog Cell 'E7'x ("X" - Alias Cell) is now
EXCTLGE7 added to VMACCTLG so as to create new dataset CTLGE7 obs
IMACCTLG for each alias cell. In addition, the E7 cell will now
VMACCTLG be decoded in the optional logic in VMAC6156 (which only
VMAC6156 prints catalog cells on the SAS log).
Jul 18, 1997
Thanks to Michael Ayers, Wyeth Labratories, USA.
Thanks to Brian Cooper, Wyeth Labratories, USA.
Change 15.165 Support for new subtype 6 type 99 record creates new data
EXTY99U6 set TYPE99_6, called the "Goal Mode SMF" record by BGS.
VMAC99 The new subtype contains no new data (everything in it is
Jul 18, 1997 already in other subtypes of the type 99), but the new
record compacts the needed data in one subtype so that
you can afford to write that subtype 6 record and can
supress all other subtypes to reduce data volume.
Change 15.164 Variable MSGXRST is missing value because the ARRAY and
TYPEIMSA the DROP statement must be changed to read:
Jul 17, 1997 ARRAY CTR{54} CTR01-CTR54 ;
DROP CTR01-CTR54 I ;
i.e., change the 53's to 54's in those two lines.
Thanks to Kenneth D. Jones, SHL Systemhouse, NOVA SCOTIA.
Change 15.163 Support for DFSMS 1.4 adds (COMPATIBLY!) new fields:
VMACDCOL -Type 'A' - Dataset DCOLCLUS new variables:
Jul 17, 1997 DCACISZ ='NUMBER OF*BYTES IN*A CI'
DCACACIC='NUMBER OF*CI-S IN*A CA'
-Type 'V' - Dataset DCOLVOLS new variable:
DCVDPTYP='PHYSICAL*DEVICE*TYPE'
-Type 'M' - Dataset DCOLMIGS new variable:
DCVDPTYP='PHYSICAL*DEVICE*TYPE'
-Type 'B' - Dataset DCOLBKUP new variable:
UBFRVOL ='1ST SOURCE*VOL*OF BACKUP DATA'
-Type 'DC' - Dataset DCOLDC
Fifteen new DDCxxxxx construct variables.
-Type 'SG' - Dataset DCOLSG
Sixty-four status flags decoded & DSG32NAM corrected.
-Type 'VL' - Dataset DCOLVL
Ninety-six status flags decoded & DVL32NAM corrected.
-Type 'BC' - Dataset DCOLBC
Ninety-six status flags decoded & DBC32NAM corrected.
-Type 'DR' - Dataset DCOLDR
Sixty-four status flags decoded.
-Type 'LB' - Dataset DCOLLB
Sixty-four status flags decoded.
Change 15.162 Minor. Variable CPUSERF wasn not kept, and variable
RMFINTRV CPUHPTTM was not FORMATed nor LENGTHed.
Jul 16, 1997
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.161 Optional Omegamon/CICS DB2 variables OMBDESCN/OMBDESTM &
IMACICOB OMBEXECN/OMBEXETM were not labeled, nor were they kept in
VMAC110 CICSTRAN dataset.
Jul 15, 1997
Thanks to Harald Seifert, HUK-Coburg, GERMANY.
Change 15.160 ASUMUOW/IMACUOW are enhanced to allow large sites to send
IMACUOW the temporary sorted output of CICSTRAN/DB2ACCT to a
ASUMUOW DDname other than //WORK. Comments explain how.
Jul 15, 1997
Thanks to Chuck Hopf, MBNA, USA.
Change 15.159 IBM APAR OW13754 documents type 14/15 CRDATE and EXPDT
YEAR2000 support for year 2000 by allowing those one-byte binary
Jul 15, 1997 fields to have values 100 thru 255 to correspond to year
2000 thru 2155 (giving our descendants the opportunity
to make big bucks fixing the "Year 2155" problem). MXG
had assumed this solution, so no MXG code fix is needed.
Note that these julian dates will now print at 99363,
99364, 99365, 100001, 100002, etc.
Change 15.158 RACF type 80 RACFEVNT=22 and 59 are now supported, with
EXTY8022 new datasets TYPE8022 and TYPE8059. Segments for DTP for
EXTY8059 RACFTYPE=22, 24, 39, 40, 41, and 44 are now decoded. New
EXTY8X13 formats $MG080AF and $MG080UA are created by FORMATS.
EXTY8Y13 FORMAT MG808IA was updated so INTENT/ALLOW value 5 is now
EXTY8X24 decoded, TYPE8010 and TYPE8013 has SECLEVEL added.
FORMATS Dataset label for TYPE8018 is now PASSWORD COMMAND.
IMAC80A Several KW24xxxx variables were also corrected.
VMAC80A
Jul 14, 1997 For some RACF events, repeats of segments 21, 33, 34, 39,
Aug 24, 1997 40, 41, 42, and 44 are possible, but MXG kept only the
last instance. To repeat variables in the base TYPE80nn
or to create new TYPE8xnn dataset(s) depends on how many
repeats occur for a specific RACFEVNT; support for repeat
is added on a case-by-case basis when I receive test data
with multiple segments. Thus far, these instances of
repeated segments are supported as described:
-The many repeats of segment 21 in RACFEVNT=24 (SETROPTS)
are supported by observations in new TYPE8X24 data set,
keeping JOB READTIME SMFTIME SYSTEM as keys back to the
parent TYPE8024 dataset. The SETROPTS command creates
hundreds of repeated segments of questionable utility,
so creating an "Extra" dataset will save space.
-The second repeat of segment 33 in dataset TYPE8004 is
added as new variable RESNAME2 in that dataset. This
is a newname/oldname event, so only a second instance
needs to be supported.
-The six repeats of segment 44 in dataset TYPE8010 are
added as variables EV44FLG1-EV44FLG6, SEGNAME1-SEGNAME6,
and EV44TXT1-EV44TXT6, if more than 6 are found in the
RACFEVNT=10 record, a message will be put on the log.
For the other RACFEVNT's (11,12,13,20,21,22) only one
segment 44 has been observed, so only one is kept, but
a message will be put on the log if more are found.
-The many repeats of segments 40 and 41 in TYPE8013 create
new dataset TYPE8X13 for segment 40's (maximum of 20 has
been observed) and new dataset TYPE8Y13 for segment 41's
(maximum of 4 has been observed).
Thanks to Peter J. Lines, NatWest Bank, SCOTLAND.
Thanks to Len Rugen, University of Missouri-Columbia, USA.
Thanks to Joe Faska, Depository Trust, USA.
Change 15.157 Support for Shared Medical Services CICS application's
IMACCICS OASMON (SMS Online Architecture System) journal segments
IMACICSM creates new dataset CICSSMED. Observations are created
VMAC110 when records are found, with no user action required.
EXCICSME CICSSMED contains the OAS stack or program name and the
Jul 11, 1997 response time in type 110 subtype 0 SMF records without
having to enable CICSTRAN monitoring in your MCT.
Thanks to Kristyann Manske, University of Wisconsin-Milwaukee, USA.
Thanks to Kevin Hurst, Shared Medical Systems, USA.
Change 15.156 Variable DEVNR is now added to dataset TYPE74CA and is
VMAC74 equal to DEVN. The DEVN spelling was kept from the old
Jul 11, 1997 CACHE90 predecessor dataset so your old reports would
run from TYPE74CA, but DEVNR is the more common name in
all other MXG datasets, and is the variable name to use.
Thanks to MH, Allied Irish Bank, IRELAND.
Change 15.155 Cosmetic. Duplicate label statements were deleted in the
DOC members VMAC102, VMAC110, VMACAPAF, VMACCTLG, VMACHPSU,
Jul 10, 1997 VMACHPUX, VMACMWSU, VMACMWUX, VMACODS, VMACQAPM,
VMACTPX, and VMACXAM.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.154 Archaic members VMXGVTOC and VMXGVTOF did not create the
VMXGVTOC ZDATE variable in datasets INFO and VTOCINFO, but now the
VMXGVTOF variables are created. Both members were effectively
Jul 10, 1997 replaced by DCOLLECT: see TYPEDCOL/JCLDAYDS, although
the archaic members are still useful, especially if you
need to know the physical location of extents, since the
DCOLLECT records only contain total sizes of datasets.
Thanks to Mark Zelden, CIBER Network Services, Inc, USA.
Change 15.153 Cosmetic. The LABELs for LPAR variables are now grouped
ASUM70PR by LPAR number, so all variables for LPAR 0 are together
Jul 9, 1997 for ease in viewing; the global CPU and Percentages are
also grouped together, as the 1st variables in ASUM70PR.
Thanks to Jean Quinkert, Inland Steel, USA.
Change 15.152 Formats $MGHEX2H, $MGHEX4H, and $MGHEX8H are added to
FORMATS MXG to print hex character variables's blank values as
Jun 29, 1997 blanks instead of '40's. See MXG Tech Note, NL 32.
===Changes thru 15.151 were included in MXG 15.03 dated Jun 30, 1997===
Change 15.151 Installation tailoring code that defines your SHIFT value
IMACSHFT has added an example of a table of holiday's dates that
Jun 29, 1997 can be used to change Prime/Non-Prime Shift observations
to Weekend Shift, if that is what your manager says to
do because the numbers are skewed. (Personally, I prefer
to leave the shift asis, and observe the week-to-week
difference between weeks with holidays and weeks without,
but MXG is all about freedom and doing it your way!)
The example is commented out, so this change did not
really change anything except comments in IMACSHFT.
Thanks to Mark Zelden, CIBER Network Services, Inc, USA.
Change 15.150 INPUT STATEMENT EXCEEDED with Omegamon VTAM 200 IRNUM=12
VMACOMVT record; variables ON12OQ, ON12SP, and ON12SS must be
Jun 28, 1997 INPUT as &PIB.4. instead of &PIB.8., and variable ON12DX
must be INPUT as $EBCDIC4. instead of &PIB.8. This is
the first instance of anyone processing this subtype.
Thanks to Rich Anderson, SAS Institute Cary, USA.
Change 15.149 MXG 15.03 corrections uncovered in final final tests:
TESTWWW -Step TESTOTHR of JCLTEST6 fails because of the extra
DIFFDB2 close-parenthesis in the DATA statement in member TESTWWW
TRND72GO (twice I caught this and thought I had fixed it!).
NEWSLTRS -"UNINITIALIZED VARIABLE BHHITRAT" in building DB2STATB;
EXNTCMBU BPHITRAT was spelled BHHITRAT in one LABEL statement in
IMACEXCL member DIFFDB2, causing variable BPHITRAT to be created
Jun 28, 1997 without a label. See Change 15.xxx.
-TRND72GO statement LENGTH SERVICE 8 MSOUNITS; caused a
very strange %MACRO compiler error; but the correct
statement should be LENGTH SERVICE MSOUNITS 8;
-Four Thousand lines were deleted from member NEWSLTRS;
The text of changes in the Change Log in Newsletters
TWENTY-SEVEN and TWENTY-EIGHT should have been removed
from member NEWSLTRS, as that text is kept in member
CHANGESS, and a redundant copy is not needed!
-Comment in EXNTCMBU changed to CMPQCMBU vice CMPQBUSU.
-Comments in IMACEXCL were clarified extensively.
Thanks to Freddie Arie, Lone Star Gas, USA.
===Changes thru 15.148 were included in MXG 15.03 dated Jun 26, 1997===
Change 15.148 Omegamon BSC data had incorrect GMTOFFTM calculated; The
IMACICOC variable OMGMTCHR was truncated to only one byte because
Jun 26, 1997 it was in the INFORMAT ... $NOTRAN. statement; it should
be removed from that INFORMAT statement.
Thanks to Dale Wiles, Perdue Farms, USA.
Change 15.147 NTSMF Version 2.0.d requires MXG 15.03 dated Jun 26, or
VMACNTSM at least MXG 15.02 plus this change. MXG coding errors
Jun 26, 1997 will cause error messages "UNEXPECTED INSTANCE FIELDS" or
INVALID DATA FOR MO IN LINE .... and/or STOPOVER ABEND.
-The LENGTH statement VERSION $4. must be changed
to VERSION $5.
-The two tests for Reduced or Extended Header must be
changed to read:
IF VERSION GE : '2.1' THEN INPUT /*REDUCED HEADER*/
and
IF '2' LE : VERSION LT : '2.1' THEN INPUT /*EXTENDED*/
instead of the tests for '2.0.d' and LE '2.0.c'.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.146 IBM Item RTA000099957 (see DB2 Technical Note 2 in NL 32)
DIFFDB2 states that the calculation of Buffer Pool Hit Ratio
ANALDB2R is (QBSTGET-(QBSTSIO+QBSTDPP+QBSTLPP+QBSTSPP))/QBSTGET;
Jun 26, 1997 whereas MXG used QBSTRIO instead of QBSTSIO in ANALDB2R.
I have added variable BPHITRAT to the DB2STATB dataset,
and variables B1HITRAT-B4HITRAT to the summary DB2STATS
dataset. I expect to alter ANALDB2R but want to verify
first (and its an extensive change). See the discussion
of why you can get negative values for Hit Ratio in DB2
Technical Note in Newsletter THIRTY-TWO.
===Changes thru 15.145 were included in MXG 15.03 dated Jun 25, 1997===
Change 15.145 Minor cosmetic changes were made to TRND72GO (Labels, and
TRND72GO DROPs), and 3 documentation-only members: ACHAP99, DOCVER
Jun 25, 1997 and DOCVER15 were updated with 15.03 dataset contents,
and counts in AAAAAAAA & COPYRITE now are for the real
MXG 15.03 dated Jun 25, 1997. Only ten tapes to trusted
sites carried the Jun 24, 1997 date.
===Changes thru 15.144 were included in MXG 15.03 dated Jun 24, 1997===
Change 15.144 TYPERDS records created 0 observations; these corrections
VMACRDS were required: INPUT of H15FTP is &PIB.2. vice &PIB.4.,
Jun 24, 1997 the INPUT of H15HSQ is &PIB.4. vice &PIB.2., and the
test IF H15FOS+H15FL GT ... must be changed to
IF H15FOS+H15FL-1 GT ....
Thanks to Shana Bereznay, Southern California Edison, USA.
Change 15.143 This change was NOT made. After planning the change and
BUILDPDB writing the change text, I realized I could not make the
BUILDPD3 change as described without a negative impact on existing
BUILD005 MXG BUILDPDB/BUILDPD3 users: BUILDPDB deletes the STEPS
BUIL3005 dataset from WORK as soon as PDB.STEPS is created (so its
Jun 24, 1997 workspace can be reused), but keeping WORK.STEPS would
require more WORK space - an existing daily job could
ABEND, needing more //WORK space, if I made the change.
I will revise the change and revise its description when
I can figure out how to meet IT Service Vision's request
without impact on existing MXG BUILDPDB jobs.
For IT Service Vision. After MXG's BUILDPDB logic has
created the PDB.STEPS dataset, SAS's IT Service Vision
uses the WORK.STEPS dataset left in the WORK file. But
then MXG logic to create PDB.SPUNJOBS replaces the real
WORK.STEPS with only the spun steps, because I reuse the
_PDBSUM macro that is defined in IMACPDB. I considered
changing that macro in IMACPDB to use a symbolic for its
output dataset, but that implementation would have caused
incompatibility for any user that had tailored IMACPDB!
Instead, by adding PROC DATASETS to rename WORK datasets:
PROC DATASETS NOLIST; CHANGE STEPS=REALSTEP;
%INCLUDE SOURCLIB(SPUNJOBS);
PROC DATASETS NOLIST; CHANGE STEPS=SPUNSTEPS;
PROC DATASETS NOLIST; CHANGE REALSTEP=STEPS;
both WORK.STEPS and WORK.SPUNSTEP will now exist after
BUILDPDB runs. By making this change in MXG, IT Service
Vision installers will have one less option to tailor.
Again, this change was NOT made. These are notes only,
that will likely be revised in the future.
Change 15.142 New exit EXPDB30V is added to the BUILDPDB/BUILDPD3 logic
EXPDB30V to allow tailoring of the PDB.SMFINTRV after TYPE30_V has
BUILDPDB been merged with the Accounting Information. While the
BUILDPD3 IMACINTV exit can be used to tailor TYPE30_V (which
BUILD005 becomes PDB.SMFINTRV), the accounting fields do not exist
BUIL3005 when IMACINTV is invoked, so the new exit allows for
Jun 23, 1997 more flexible tailoring.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 15.141 ASMTAPES ML-14 populates fields in the Tape Mount record
ASMTAPES (COMPATIBLY) and provides some enhancements to the AR
Jun 23, 1997 mode code to prevent the S0C4 abends with swapped out
address spaces. It does not completely conceal the S0C4
abends (that is still planned) but this should improve
the situation significantly.
Change 15.110 describes the corresponding changes to the
VMACTMNT member to process the newly populated fields,
but as the record format was not changed by the monitor,
earlier versions of MXG can read the ML-14-created SMF
records compatible. You will want to use VMACTMNT from
MXG 15.03 or later to exploit and decode the new fields:
The ALOCSTRT is of value when working with tape mounts
for DFHSM where some DDNAMEs (eg., RESIN1, RESIN2,...)
are re-used many times (dynamically allocated) within
one (long-running) step. The DDNAME is of value when
working with tape mounts for DFHSM were some devices
are allocated multiple times with different DDNAMEs
within a step.
Mark also provided corrections for truncation of JESNR to
four digits in the mount record processing; he found that
the ASMTAPES logic did not replace ALCSTIME with ALISTIME
for INTERVAL records cut after a day boundary has been
crossed; he provided his ASM and SAS code to to add the
above fields; and he found a nit in one series of tests!
Mark is a fine example of an MXG CodeShark!
Thanks to Mark Keimig, VF Information Technology Services Inc, USA.
Change 15.140 Support for new fields in the DFSMSrmm TYPEEDGR extracts
FORMATS that were COMPATIBLY added at some time in the past.
VMACEDGR Dataset EDGRDEXT has new variables:
Jun 23, 1997 RDABEND RDCAT RDCRTJBN RDDCNAME RDDDNAME RDDSSIZE
Jun 26, 1997 RDLABNO RDMDMVID RDRETDAT RDSCNAME RDSGNAME RDSTEPNM
RDVRSJBN RDVRSNAM RDVRSR RDVRSTYP
and new format $MGEDGRT is added to member FORMATS.
Dataset EDGRSEXT has new variable RSBMEDN.
Dataset EDGRVEXT has new variables:
RVABEND RVACTERA RVACTINI RVACTNOT RVACTREP RVACTRET
RVACTSCR RVBMEDN RVDSNREC RVHOMTYP RVLUDEV RVMVMODE
RVNEXTYP RVNLOC RVOBMEDN
27Jun97: Variables RVNVOL RVNPVOL and RVMDMVID were
labelled and added to KEEP for EDGRVEXT dataset.
Thanks to Sam Bass, McLane Co., USA.
Change 15.139 When Landmark maintenance TT00032 was applied after the
TYPETMON March cum tape was installed (to fix a Landmark 0C4 in
TYPEMON8 their dump program), the dump program creates a garbage
Jun 23, 1997 first record, causing MXG to USER ABEND 1099. The bad
record can be deleted by changing the test for dictionary
record deletion to include this garbage record:
IF TMMDREC='DD' OR (TMMDPROD='00'X AND TMMDREC='0081'X)
THEN DELETE;
Thanks to Marcia Ketchersid, Price Waterhouse LLP, USA.
Change 15.138 Report Performance Groups or Reporting Classes now CAN be
IMACWORK used in member IMACWORK to define workloads in dataset
RMFINTRV PDB.RMFINTRV. This redesign separately sums the Control
Jun 22, 1997 Performance Groups (Compat Mode) or the Service Classes
(Goal Mode) into the existing variable CPUTM, and then
sums all of the CPU times from your workload definitions
into new variable CPU72TM. If CPU72TM does not exactly
match CPUTM, then either you have double accounting
(CPU72TM GT CPUTM), or you have failed to map all of your
workloads in your IMACWORK logic (CPUTM GT CPU72TM); MXG
will print an error message on the SAS log if the times
do not match. The new design relocated the DELETE logic
from member RMFINTRV into the revised IMACWORK (since you
will have to change that delete logic if you want to use
RPGNs or Reporting Classes in your workload definitions),
but you do not have to change your IMACWORK member until
you want to use the new facility. The new RMFINTRV will
detect that you are still using an "old" IMACWORK member,
and will continue to delete Report Performance Groups and
Reporting Classes until it detects you are using the new
IMACWORK member. Thus this change is compatibly made!
The optional code to directly read SMF records that is
commented out in RMFINTRV was updated to match BUILDPDB.
Change 15.137 Pre-15.03-QA job found missing labels for variables in
VMACSTRS these members.
TRNDDB2S
VMACTMDB
VMACLMS
TYPEIMS
ASUMDB2A
ASUMDB2B
Jun 22, 1997
Change 15.136 This member for reading Web Proxy logs in Common Log
TYPEWWW Format was revised to conform to MXG style (LABELs,
Jun 22, 1997 FORMATS, LENGTH, and name changes of temporary fields,
and some statements were consolidated. Variable RDRTS
was renamed WWWRDRTS to avoid name conflict.
Change 15.135 Trending for Workload Manager Goal Mode Service Class
TRND72GO dataset TYPE72GO into TREND.TRND72GO now exists, in
Jun 20, 1997 this preliminary version. A revision that will map your
Jun 25, 1997 old TRND72 Performance Group data into the new TRND72GO
is planned so you can track before/after Goal Mode.
Jun 25 note: Cosmetic revisions (LABELs, DROPs) added
after first (Jun 24) MXG 15.03 was created.
Thanks to Mike Billy, Banc One, USA.
Change 15.134 Support for IXFP (Iceberg/IBM RVA) new subtype 6 and 7
EXICEDDS creates three new datasets:
EXICESNP Subtype Dataset Description
EXICEUTL 6 ICEBRGSN SNAPSHOT - EXTENTS SNAPPED
IMACICE 6 ICEBRGDD SNAPSHOT - DDSR EXTENTS
VMACICE 7 ICEBRGUT Space Utilization
Jun 19, 1997 Note that APAR OW25126 corrects errors in subtype 7 in
Mar 30, 1998 sites when Snapshot microcode is installed on an RVA
(RAMAC Virtual Array) subsystem. Put its PTF on!
===>>> Text updated March 30, 1998. This change created an
INCOMPATIBILITY in dataset ICEBRGDE. Before this change,
variable ICEVERS was a numeric and stored in 4 bytes, but
this change (in MXG 15.04) changed ICEVERS to character
of length one in dataset ICEBRGDE, and then created new
new variable ICEVERSN as a numeric stored in 4 bytes in
datasets ICEBRGSN and ICEBRGDD. In retrospect, exactly
why I did it this way is unclear, but I suggest for now,
simply drop the variable ICEVERS from ICEBRGDE, since it
really is not needed to be kept (it's a record version,
but I think there's only been one and it's always a 1?).
Edit member IMACICE and replace the MACRO _KICEDEL %
null definition with
MACRO _KICEDEL DROP=ICEVERS %
to drop the variable from dataset ICEBRGDE to avoid the
conflict. I think ITSV and SAS/CPE can tolerate the
absence of ICEVERS better than its conflicting presence.
This is a preliminary answer, and will be updated if it
does not resolve the conflict.
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 15.133 In sysplex, timestamps converted from "GMT" to "LOCAL"
VMAC30 were off by the number of "leap seconds", currently 20.
VMAC110 These "GMT" time values are actually "Absolute" values
VMACDB2 that include leap seconds; MXG erroneously "floored" the
Jun 18, 1997 delta value to get only the GMT offset hours to convert
"GMT" to "Local". Now, MXG keeps the full delta between
"Absolute" and "Local" to properly convert to local; if
the GMT offset value itself is not exact, it shows the
number of leap seconds in your system (CVTLOS).
Records GMT Offset Comment
30's SMF30IST-INTBTIME Calculated, leap seconds
42 st 6 S42JDGMO Provided, leap seconds
72 GMTOFFTM Provided, leap seconds
100-102 SMFTIME-THISSTCK Calculated, leap seconds
110 MCTMNTAD Provided, leap seconds
Unless you were comparing events with your wrist watch,
you might not have noticed this 20 second error in the
timestamps, but see the discussion in MVS Technical Notes
in Newsletter THIRTY-TWO for synchronization impact.
In addition, this change now converts SYNCTIME to local
time in type 30; it was already converted from Absolute
to local in RMF datasets, so now it is consistent!
Change 15.132 MXG 15.01 or MXG 15.02 cosmetic errors. TESTOTHR brings
VMXGHSM TYPEWWW in, but the FILENAME statement causes dataset not
TYPEWWW found under MVS, so it was commented out. Uninitialized
Jun 18, 1997 variable MCTFLG3 message was corrected by spelling it as
MCTFLGS in the LABEL statement.
Thanks to James McCullough, Economical Mutual Insurance Co., USA.
Change 15.132A DB2 Trace dataset T102S106 was not correct for new fields
VMAC102 added to QWP4 section in DB2 3.1, 4.1, and 5.1. The new
Jun 17, 1997 fields include MXG-constructed QWSU_SEC Service Unit per
CPU-Second value of the machine on which this DB2 Subsys
is executing!
Thanks to Jon Fritz, Levi Strauss & Co., USA.
Change 15.130 Variable SMF94ETO existed in MXG 14.14 but did not exist
VMAC94 with MXG 15.01 or 15.02, while variable SMF94EPM had the
Jun 17, 1997 TOTAL*EJECTS but was labeled POST*EJECTS. The real IBM
documentation now shows that only SMF94ETO should exist
and is the TOTAL*EJECTS, so MXG variables are no longer
created.
Thanks to Robert Miles Standish, Dean Witter Trust Company, USA.
Change 15.129 Label for DB2 QBSTDMC and QBnTDMC variables is now
VMACDB2 QBSTDMC='DATA MANAGER*THRESHOLD*REACHED'.
Jun 17, 1997
Thanks to Joseph Fordham, UPS, USA.
Change 15.128 Dataset TYPE116 MQ Series variable QWHCTNO is now labeled
VMAC116 QWHCTNO='CICS*THREAD*IDENTIFICATION*ADDRESS' instead of
Jun 17, 1997 Thread Number, as IBM now explains it is a control block
address of the thread, so '004dF3D4'x is a valid value.
The address can be reused, so it is not a unique value.
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.127 AS/400 variable AS400SYN is missing if length of SYSTEM
VMACQAPM is less than 8 characters. The original logic is now:
Jun 16, 1997 ELSE IF GKEY=' S' THEN DO;
LENSYS=MIN(LENGTH-6,8);
INPUT @7 GDESS $VARYING8. LENSYS @;
AS400SYN=GDESS;
CALL SYMPUT('AS400SY',AS400SYN);
END;
Thanks to Len Marchant, Coca Cola Enterprises, USA.
Change 15.126 Counting the Average and Maximum Logged On TSO Users each
ANALCNCR 15 minutes (using PDB.JOBS TSO Session records) is done
Jun 15, 1997 in a new example in the comments in member %ANALCNCR.
Thanks to Dan Gilbert, Bergen Brunswig, USA.
Change 15.125 The detection of VIO was based solely on DEVNR='7FFF'x
VMACUCB but as this could now be a legitimate device address with
Jun 15, 1997 4-digit UCBs, the test for VIO in VMACUCB was changed to
require DEVCLASS='00'x also. For type 30 DD segments,
the DEVCLASS for VIO is zero, but in type 14/15 records,
the DEVCLASS is whatever device was installation defined
for VIO space calculations. Fortunately, there is a bit
set in type 14/15 records for VIO, which MXG uses to set
DEVICE='VIO' even though DEVCLASS is non-zero.
Change 15.124 Support for APAR OW25263 adds variables JFCTDSI1 (bits
VMAC1415 for 128 track mode, "1/2 inch/320 meter particle media",
Jun 15, 1997 and JFCTDSI2 (bits for Compaction=YES) for 3590's.
Change 15.123 Comments were revised to describe IMACKEEP as archaic;
IMACKEEP its function was replaced by the MXG Exit Facility that
Jun 15, 1997 is described in Change 10.175.
Thanks to Thierry Van Moer, Comparex Information Systems, BELGIUM.
Change 15.122 Label for variable R744SCN should have been spelled
VMAC74 CONTENTIONS.
Jun 15, 1997
Thanks to Bob Gauthier, American Stores Company, USA.
Change 15.121 DB2 Trace IFCID=125. Variables QW0125NR and QW0125RI are
FORMATS now INPUT as "&IB.4." instead of "&PIB.4." and formats
VMAC102 MGD125N and MGD125R decode their negative values:
Jun 15, 1997 VALUE MGD125N
-2 = '-2:NO STG OR MAX EXCEEDED'
;
VALUE MGD125R
-1 = '-1:RETRIEVE NOT ATTEMPTED'
-2 = '-2:NO STG AVAILABLE'
-3 = '-3:NUM RIDS EXCEEDED MAX LIMIT'
;
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY.
Change 15.120 Change 14.300 (which only affected old RMDS 1.3 and 1.4)
VMACRMDS was not made as documented, causing variables RMDSARN and
Jun 12, 1997 RMDSARI to be missing; the change is now made!
Thanks to Steve Colio, CIGNA Corp, USA.
Change 15.119 You cannot use Tandem's ftp program to upload Measure's
ADOCTAND "Structured" data files because Tandem's ftp sends the
UTANDSTR entire file including header, data records, and trailer.
Jun 17, 1997 Products like BCOM and Connect Direct do understand
Tandem's structured files and will send only the data
records, so they don't have this problem!
If you are stuck with Tandem's ftp, you will have to
convert the Structured file into an Unstructured file
and then you can use their ftp to upload that data.
Member ADOCTAND has been updated with a Tandem-supplied
example that will create an unstructured file from the
structured MEASCOM data files using Tandem utilities.
In addition, although I hope you never need it, member
UTANDSTR will create Unstructured Measure files from
Structured ones that have already been shipped to MVS.
You will have to supply the LRECL of each file in the
program, and will have to EDIT the dataset names, and
you must use RECFM=FB and LRECL=4096 when you upload
their structured file with their ftp.
If Tandem ever changes their ftp program to recognize
their own records, the double processing can go away.
Thanks to Tim Crocker, AT&T UCS, USA.
Thanks to Jack Driscoll, Tandem, USA.
Change 15.118 TYPE94 record without APAR OW27369 caused INVALID AUDIT
VMAC94 SECTION error; the test IF SMF94SDL GE 76 THEN INPUT must
Jun 6, 1997 be changed to IF SMF94SDL GE 84 THEN INPUT.
Thanks to Will Evans, Consolidated Freightways, USA.
Change 15.117 Changes in NPM that were overlooked long ago:
VMAC28 -LCSLxxxx variables added to CSL segment for HPR bytes and
Jun 4, 1997 frames transmitted, received, and discarded, and LCSLCON5
thru LCSLCON7 flag bytes are now kept.
Change 15.116 TLMS 5.3 (archaic, 5.4 has been out for some time) dates
VMACTLMS were not converted completely; the conversion code from
Jun 4, 1997 the 5.4 code was moved to the 5.3 section of VMACTLMS
Thanks to Jim Van Arsdale, IBM Global Services, USA
Change 15.115 MONTHBLD failed for dataset TYPE77, because WEEKBLDT did
WEEKBLDT not have the correct BY list (but WEEKBLD was correct!).
Jun 4, 1997 WEEKBLDT now matches BUILDPDB/WEEKBLD/MONTHBLD.
Thanks to Mike Rouncville, Rose's Stores, Inc, USA
Change 15.114 TMON/DB2. Previously un-tested subtypes "DE" and "DW" had
VMACTMDB coding errors that surfaced when real data was read.
Jun 4, 1997 -The "DW" record INPUT was realigned, DWWLRTME was changed
Jun 24, 1997 from TIME8 to HH &NUM.2 and DWWLRDAT's JULIAN input was
revised so the code will work under EBCDIC or ASCII SAS,
and the variable text is now correctly input.
-The "DE" record has the common header; the test
IF LMRKREC='DA' OR LMRKREC='DB' THEN INPUT
was expanded to also test OR LMRKREC='DE'.
Thanks to Tricia Dudley, SAS Institute Cary, USA.
Thanks to Luc Gariepy, Regie des rentes du Quebec, CANADA
Change 15.113 DB2 Trace SMF type 102 subtype 125.
VMAC102 -The +2 after QW0125MR must be +1. This error affected
Jun 5, 1997 only variable QW0125NR.
-The DO OFFSET=QWT02R2O in the IFCID 125 section was
replaced with DO _I_=1 to QWT02R2N logic from IFCID 172.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstat AG, GERMANY.
Change 15.112 Support for APAR OW26451/OW26453/OW26497 added fields for
VMAC42 MAXRSPTM and MAXSRVTM (Max Response/Service Time) to data
Jun 3, 1997 set TYPE42DS. Other minor changes were made.
Change 15.111 Support for TANDEM D42/D43/D44/G02 releases.
VMACTAND Documentation indicates compatibility, in that new data
Jun 3, 1997 fields are added at the end of the record, but you will
Jun 20, 1997 still find it INCOMPATIBLE, because you will have to
change the LRECL of each MVS dataset into which the data
records are sent when you install the versions with new
data. Initially, it appears there is no problem with
D42, but I need to review the later three systems and
will update this note when I know more.
Thanks to Tim Crocker, AT&T Universal Card Services, USA.
Change 15.110 Enhancements so MXG Tape Mount records that will be in
VMACTMNT ML-14 of ASMTAPES (see later Change) are coded now:
Jun 2, 1997 -New variables are added to TYPETMNT:
DEVFLGS, UCBSTAT, UCBFL1, UCBSTAB, DDNAME, STEPNR,
ALOCSTRT, and TMNTMAIN.
-Existing unpopulated variables will be populated by the
changes in ASMTAPES at ML-14:
READTIME, INITTIME
-Variable JESNR now supports 5-digit JES numbers.
-The interval start value did not replace ALCSTIME with
the interval-start time for interval records created
if a job spans a day boundary; in error, the allocation
timestamp of the original allocation was stored.
Thanks to Mark Kemig, VF Services, Inc, USA.
Change 15.109 Format MGBYTRT (bytes-per-second) truncates on the left
FORMATS (1099KB/Sec prints as 99KB/Sec) because the DEFAULT=8 in
May 30, 1997 the PICTURE MGBYTRT statement must be DEFAULT=10.
After making that change, you need only to re-build your
format library by %INCLUDE SOURCLIB(FORMATS); (with the
//LIBRARY DD allocated with DISP=OLD under MVS).
Thanks to Leigh Ann Payne, Wachovia Operational Services Corp, USA.
Change 15.108 DCOLLECT variable DCASRCI (dataset DCOLCLUS) is relabeled
VMACDCOL to 'USE HARBC/HURBC*INSTEAD OF*HARBA/HURBA?' to flag that
May 29, 1997 variables DCAHARBC and DCAHURBC, according to IBM, should
be used for VSAM space (high RBA) allocated and used in
place of DCAHARBA/DCAHURBA variables. Also, variables
DCAHARBC and DCAHURBC are now formatted MGBYTES.
In merging DCOLDSET and DCOLCLUS for VSAM datasets (to
get HLQ classifications by storage group with accurate
allocated/used statistics), John noted that sometimes,
the High Used RBA was greater than the Allocated Space
(i.e., DCAHURBC GT DCDALLSP). Chuck tracked this to obs
for the Index component for VSAM datasets which used
IMBED or REPLICATE; it appears that the index bytes that
are imbed/replicated in the Data Component are being
counted in the RBA for the Index Component, causing it to
appear to have more "used" than "allocated".
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.107 New TYPE8025 dataset is now created for RACF Event 25,
EXTY8025 RACF RVARY Command. Variable RACFTYPE was removed from
IMAC80A the KEEP= list, as it contained the TYPE value of only
VMAC80A the last segment in a type 80 record. (Variable TYPSTRNG
May 29, 1997 lists all segment types found in each record).
Thanks to Joe Faska, Depository Trust, USA.
Change 15.106 Support for APAR OW20921 which created TYPE42VT dataset
EXTY42VT with response time statistics like TYPE42SR, but for the
IMAC42 VTOC, VTOC Index, and VVDS for each volume. This APAR
VMAC42 also added stripe count and flag variables to TYPE42DS.
May 28, 1997 In the new TYPE42VT, there are occasional observations
with AVGIOQMS less than zero (-.127 maximum), indicating
that the data is not exact.
Thanks to Tim Vanderhoek, Fidelity Systems Company, USA.
Change 15.105 Variables in dataset QAPMAPPN read in after ANDBE8 were
VMACQAPM wrong; the offset 1464 was incorrectly repeated in two
May 27, 1997 lines. Subsequent offsets have now been corrected.
Variable ATCSDR is INPUT @558 vice @588 now.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.104 Duplicate variable names were corrected.
VMACPW -VMACPW: TOIOOPCT should have been TOIOPCRT, first
VMAC102 SWINOPCT is now SWINCTCT and first SWOUOPCT is SWOUCTCT.
VMACSTRS -VMAC102: second QW0221AN was removed
May 26, 1997 -VMACSTRS: second TOTSERV was removed
Thanks to Freddie Arie, Lone Star Gas, USA.
===Changes thru 15.103 were included in MXG 15.02 dated May 23, 1997===
Change 15.103 Support for RACF data for OMVS RACF using IBM's IRRDBU00
EXRAC120 unload utility creates two new datasets, thanks to this
EXRAC270 user-contributed enhancement. New datasets are:
IMACRACF Dataset Description
VMACRACF RACF0120 Group OMVS Data
May 22, 1997 RACF0270 User OMVS Data
Thanks to Ben Cowan, University of Nevada System, USA.
Change 15.102 Support for Filetek's Optical Disk SMF record creates
EXFTEKIC three new datasets:
EXFTEKID Dataset Description
EXFTEKGL FILTEKIC IC Command Link Task Record
IMACFTEK FILTEKID ID Data Transfer Task Record
TYPEFTEK FILTEKGL GL Global Statistics Record
VMACFTEK This is preliminary; the Global record is not complete.
May 22, 1997
Thanks to Joe Faska, Depository Trust, USA.
Change 15.100 A new macro that compares two SAS Data Libraries and
VMXGCOMP lists datasets in one and not in the other, and then
May 22, 1997 generates PROC COMPARE on all datasets that are common
to both Data Libraries. The observations compared are
limitable via an option.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.099 A new macro that resets the setting of most SAS Options
VMXGOPTR (those whose name is 8 bytes or less and which can be
May 22, 1997 changed after SAS Initialization). The current setting
is kept so that MXG can change it and then reset it to
the original value (Change 15.098 uses it in VMXGSUM to
reset the OBS= option). Documentation is in the member.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.098 Enhancement to VMXGSUM that uses the new VMXGOPTR macro
VMXGSUM to examine SAS Options to detect that OBS=n (as opposed
May 22, 1997 to the default OBS=MAX) was specified. OBS=0 causes the
PROC CONTENTS (used to determine which variables to keep)
to have no observations, so the list of kept variables is
wrong. (Even OBS=n will cause trouble, if n is less than
the number of variables to be kept). With this new
enhancement, VMXGSUM detects the OBS=value, sets OBS=MAX
for the Keep-Variable-Create phase, and then resets OBS
to its original value. This greatly improves MXG QA runs,
which use OBS=0, by eliminating unnecessary messages!
Additionally, VMXGSUM now allows use of USER= and the
TEMP01/TEMP02/TEMP03 options.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.097 RACF "SKIPPED SEGMENT RACFEVNT=xx:desc RACFTYPE=nn ...."
VMAC80A messages are normally harmless; they indicate that your
May 22, 1997 RACF record contained a segment (RACFTYPE=SMF80DTP=nn)
that MXG did not know about in creating TYPE80A dataset.
(The event causing the type 80 record is RACFEVNT, which
might not even be an event of interest to you!).
You can look at Table 2. Relocate Section Variable Data
in Chapter 4 in "RACF Macros and Interfaces" SC23-3732
to see a) is the DTP value documented, and b) do you
care! If the segment contains data of interest, when I
get a hex dump of a record with the new segment, I will
decode the segment and add new variable(s) to the event
dataset; if the data is of no interest, I add logic:
WHEN (91) DO; /*FOUND IN 27:GENERAL AUDIT, NO DOC*/
INPUT +RACFDLN @;
END;
to member VMAC80A to bypass the segment without notice.
(the example skips the un-documented DTP=91 value found).
Thanks to Bruce Hewson, CITICORP, SINGAPORE.
Change 15.096 Inconistency analysis uncovered these flaws:
VMACNSPY -Variable APLUIDR in VMACNSPY is now format $HEX8 (the
VMACLMS length was only two bytes because $HEX4. preceded its
VMACOMCI INPUT statement).
VMACRMDS -Variable TDBSYS in VMACLMS is now initialized to a value
May 21, 1997 of 'TMS ' so the kept length is eight bytes.
Variable ISITSL in VMACLMS is LENGTH $3, and the INPUT
@53 is changed to ISITSLX, as are following five IF's.
-Variable EWAITDC in VMACOMCI was removed from $NOTRAN
informat list (because INFORMAT was seen before INPUT,
variable had kept length of only one).
-Variable RMDSFORM is set LENGTH $9 because later code
INPUTs as 9, but first occurrence was for 8.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.095 Support for DB2 Version 5.1.0.
FORMATS New formats $MGD022A, MGD022Q, and $MGD221M were added.
VMACDB2 Type 101 Record (DB2ACCT) Compatibly changed.
VMAC102 Eight new variables added:
May 21, 1997 QWACSUCV='THIS CPU SU_SEC*SERVICE*UNITS PER*SECOND'
QXCOORNO='PARGROUPS*EXECUTED*COORD PARM NO'
QXCRGTT ='CREATE*GLOBAL*TEMPORARY*TABLES'
QXISORR ='PARGROUPS*EXECUTED*REPEAT*READ'
QXSTREOP='REOPTIMIZATION*OCCURRENCES'
QXXCBPNX='PARGROUPS*INTENDED*RUN*DATASHARE'
QXXCSKIP='BYPASSED*DB2S*NOT ENUF BUFFERS'
QBGADG ='CF UNREGISTER*PAGE*REQUESTS'
Type 100 Subtype 0. DB2STAT0. Compatibly Changed.
One new Q9STxxxx variable, three QDSTxxxx variables,
and six QXxxxxxx variables added.
Type 100 Subtype 1. DB2STAT1. Compatibly Changed.
Twelve QBGLxx variables added.
Type 100 Subtype 1. DB2GBPST. Compatibly Changed.
Twelve QBGLxx variables added.
Type 100 Subtype 2. DB2STAT2. Compatibly Changed.
One variable, QDBPXSQT, added.
Type 100 Subtype 3. DB2GBPAT. Compatibly Changed.
One variable, QBGBGAS, added.
Type 102 Record. Only IFCIDs listed have been validated.
IFCID 022. INCOMPATIBLY changed. Record restructured
Fifteen new variables added.
IFCID 221. INCOMPATIBLY changed. INPUT STATEMENT EXCEEDED
Record restructured. Ten new variables added.
IFCID 222. Compatibly changed. Three new variables.
However, MXG created Pipe Duration in variable QW0222SM
by subtraction, but now IBM uses that name, so Pipe
Duration time is now calculated in variable QW0222PD.
IFCID 231. Compatibly changed. Five new variables.
Thanks to Ted Blank, IBM, USA.
Change 15.094 -Variable R723TYPE was kept as LENGTH $23 because it was
VMAC7072 not in the LENGTH $1 statement, so SAS took it's length
VMAC110 from the MGRMFTY format. Now it is kept as LENGTH $1.
VMAC74 -Variable LDGDSAIN was listed both as $1 and $2, but is
May 21, 1997 now only in the $1 list.
-Variable R744QSIZ is now formatted MGBYTES; the variable
R744QFLG is formatted $HEX2. and added to $NOTRAN.
-Variable MCDFLG3 (IF '1.......'B, DATASET is KB) is now
input @291 MCDFLG3 &PIB.1. in the MCD section, formatted
HEX2., labeled, and kept.
Thanks to Neville Wright, Telstra, AUSTRALIA.
Thanks to Lindsay Oxenham, Telstra, AUSTRALIA.
Change 15.093 Comments were revised to explain why the error messages:
JCLPDB6 ERROR: ALL VALUES MISSING FOR PLOT OF xxx
May 21, 1997 ERROR: THERE ARE NO VALID OBSERVATIONS FOR VARIABLE yyy
may print on the SAS log when you run the JCLPDB6 sample
job to build the PDB, and why they actually tell you the
BUILDPDB run was successful. (Briefly, they are from the
ANALxxxx members, and to have gotten that far is to have
successfully built the PDB library; they occur because of
"shotgun" reports that include old and new variables so
everybody gets some sample report output.)
Thanks to Robin Mitchell, SmithKline Beecham, USA.
Change 15.092 MXG 15.01 only. An incomplete CICINTRV member was sent
CICINTRV in MXG 15.01 (last minute changes to add READTIME were
May 20, 1997 tested but not migrated); now I realized that the change
was redundant, as CICSSTCK is logically the READTIME!
Note that the DURATM variable in PDB.CICINTRV is the sum
of the durations of the discrete intervals that were
summed into this observation, and might not be the delta
between COLLTIME values. MXG defaults to HALFHOUR, but
if you are only recording USS records, and you took the
IBM default interval, your records will be written every
three hours, so PDB.CICINTRV will have an obs with the
COLLTIME of the half hour preceding the end of that
interval, but the DURATM value will be the 3 hours
represented by the actual data in that observation.
Thanks to Ben Cowan, University of Nevada System, USA.
Change 15.091 Variables ACTBYTES and ACTPAGES from TYPE26J2 are added
IMACPDB to macro _PDB26J2 in IMACPDB so that they will be kept in
May 20, 1997 dataset PDB.JOBS. The ACTBYTES is the total number of
bytes of SYSOUT text that was created by each job, and is
useful in determining the JES2 Track Group Size.
Thanks to Clark Jennings, Reynolds Metal, USA.
Change 15.090 -Support for Microsoft Windows NT 4.0 Service Pack 2 which
EXNTACSR INCOMPATIBLY inserted a null field in the Process record,
EXNTCNFI and support for Version 5.0 of MS Exchange, which added
EXNTCNIN (need I say INCOMPATIBLY) eight real fields and 33 null
EXNTHTIN fields to MSEXCHDS and MSEXCHPR datasets. NRDATA count
EXNTMSIM was corrected for MSEXCHDB dataset.
EXNTMSIP -Support for NTSMF Version 2.0. Change 15.027/MXG 15.01
EXNTMSWB did not (in spite of saying so) handle the new records.
EXNTWBPR -Support for several new datasets (new objects):
EXNTWSPR Dataset Object
IMACNTSM ACTVSRVR Active Server Pages
VMACNTSM CONTINDX Content Index
May 20, 1997 CONTINFI Content Index Filter
HTTPINDX Http Contents Index
MSEXCHIM MS Exchange Internet Mail Service
MSEXCHIP MS Exchange Internet Protocols
MSEXCHWB MX Exchange WEB Component
WEBPROXY WEB Proxy Server Cache
WINPROXY WinSock Proxy Server
-Of the 68 objects now supported, all but 16 have been
tested with data records.
Change 15.089 MXG 15.01 only. INPUT STATEMENT EXCEEDED for type 94 SMF
VMAC94 record. SMF94VR3 should be +2 vice +1, while variables
May 17, 1997 SMF94VDC,VDX,VDN and VDA should be &PIB.1. vice &PIB.2.
This only affected the new section added for VTS.
Thanks to Pat Quinette, Principal Mutual Life Insurance Co., USA
Change 15.088 MXG 15.01's new ANALDDCN member inadvertently contained
ANALDDCN "./" IEBUPDTE control cards for several IMACxxxx members,
PROCSRCE so when you unloaded the IEBUPDTE file to create your MXG
May 8, 1997 SOURCLIB, those "./"s created those IMACs from ANALDDCN
(and by design they DROPed most variables from type 30s).
But fortunately, the real "./" cards for those IMACxxxx
members were found later on in the MXG tape, so they
successfully replaced the incorrect members, so your
SOURCLIB was correctly built!
Thank you Heavenly Father: if the member name had been
ZNALDDCN, your SOURCLIB would have been wrong!).
It used to be that IEBUPDTE set a CC=4 when a new member
replaced an existing member, but no longer; the IEBUPDTE
set CC=0. The only clue is in the print message "IEB816I
MEMBER NAME FOUND IN NM DIRECTORY. TTR IS NOW ALTERED"
(but IEB messages print to the //SYSPRINT DD, which is DD
DUMMY because it is hugh (1,005,099 print lines, 126 MB,
because IEBUPDTE prints all 980,991 lines of MXG 15.01,
plus 8 lines of IEBxxxx messages and blank lines for each
of MXG's 3,200 members, plus pages and the JES log!).
I have revised PROCSRCE to ERROR ./ cards found in its
input while creating the IEBUPDTE format file, so this
error should not be seen again.
Thanks to Freddie Arie, Lone Star Gas, USA.
===Changes thru 15.087 were included in MXG 15.01 dated May 6, 1997===
Change 15.087 QA tests for MXG 15.01 generated these corrections:
JCLQAJOB -CICINTRV. Variables SDGTSUPR/SDGTTKN were misspelled and
May 6, 1997 are now SDGSSUPR/SDGSTKN.
-VMACDALO. Variables DALODDN/CODE/JFCB are now labeled.
-DIFFDB2. Variables PREVGN,DIFDB21,PREVBPID are dropped,
and dropped only once.
-VMACIMS. Many unlabelled variables are now labeled, and
LABEL statements consolidated.
Change 15.086 Support for World Wide Web Proxy logs in Common Log
TYPEWWW Format to track an installation's access frequency and
May 4, 1997 destinations for URLs and IP addresses via the WWW is
provided in this user contribution, which is based on
Dan Squillace's CMG96 paper. Comments in TYPEWWW by
Brian document his approach to decoding the log into
new MXG dataset TYPEWWW.
Thanks to Brian Farley, Reliastar Life Insurance Co., USA.
Change 15.085 A new utility for ASCII platforms that produces a hex
UDUMPEBC dump like the LIST; statement on MVS, with characters
May 4, 1997 decoded as EBCDIC rather than ASCII (so you can read the
hex dump of your SMF record on your PC!). This utility
was written and contributed by Dan (but I actually made
it into a %MACRO with arguments!).
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 15.084 Sample CLISTs for MXG and SAS execution under TSO.
CLMXGSAS
May 4, 1997
Thanks to ???, ????, USA.
Change 15.083 Documentation. The discussion of why you get fractional
ADOC26J2 priorities in variable ONPRTY in PDB.JOBS or TYPE26J2 now
May 4, 1997 matches the code in VMAC26J2. The old documentation said
that MXG FLOORed ONPRTY to an integer, but it never did;
ONPRTY has always been a real, rather than an integer.
Thanks to Brian Sanger, Eagle Star Group Services Ltd., ENGLAND
Change 15.082 Support for Boole and Babbage IMF 3.2 (for IMS 6.1) is
VMACCIMS already in place in MXG. The changes were a) increase
May 4, 1997 in maximum DBD segments in a record (from 50 to 500, and
associated record length increase) but MXG always reads
whatever segments are in the record, and b) IMF 3.2 now
supports the year 2000 (by documenting dates as yyyyddd)
but MXG support was also already in place for that too!
No code was changed by this change.
Change 15.081 This user contribution is a revision of TYPEIMS7 (which
IMACIMSD reads IMS log records 07/08 for transactions and BMPs),
TYPEIMSD for IMS DBCTL, because TYPEIMS7 threw away DBCTL events.
May 4, 1997 The documentation of the significant logic necessary to
capture IMS DBCTL from the IMS log is provided also by
Bruce, in the comments in member TYPEIMSD.
Thanks to Bruce Galle, Talbots, Inc, USA.
Change 15.080 The revisions in Change 14.349 to support Stress Test's
VMACSTRS enhancements in Release 3.3.6 accidentally failed to
May 4, 1997 INPUT some variables from the earlier version.
Change 15.079 ASUMUOW combines CICS and DB2 transactions by UOW, or
ASUMUOW unit of work, but IRESPTM was kept from the last CICS
May 4, 1997 transaction physically encountered, rather than the
first (initiating) transaction. The ENDTIME should have
been a MAX() rather than MIN(), and QWHCATYP is now in
the DROP list as it is unneeded after first step.
Thanks to Tom Elbert, John Alden, USA.
Change 15.078 DB2 variable QWHCATYP printed a value of '41' when a
FORMATS value of 11 decimal or 0Bx was found. (I now know that
May 4, 1997 the 0Bx value is for "DB2 Utilities" and the MGDB2TY
May 9, 1997 format that decodes QWHCATYP was updated May 9, 1997,
but at the time, the value 0Bx was not in the format.)
Why did MXG print 41 when the value was actually '0B'x?
Because there was a logical error in the MGDB2TY format
for undefined values; the OTHER format was $HEX2, but it
should have been HEX2, because QWHCATYP is a numeric
variable! Using $HEX for a numeric variable in the OTHER
operand of PROC FORMAT is a SAS "feature" that prints not
the hex of the data value, but rather prints the hex of
the internal representation of the numeric value (as
stored by each platform). Since numerics are internally
stored as floating point numbers, the '41'x printed was
the hex value of the first byte of MVS's internal value
of '41B00000'x, where the '41' is the exponent and 'B0'
is the mantissa. But under Windows, a '00' was printed,
because Intel stores eleven as '00002640' with its
exponent in the last byte. In any event, using HEX2
instead of $HEX2 correctly shows the 0B value under MVS
or Windows. (This was the single instance of $HEX for a
numeric in FORMATS.)
Thanks to Roman Jost, Gjensidige, NORWAY.
Change 15.077 The MXG Tape Allocation Monitor records had new fields
ASUMTALO added in ASMTAPES in MXG 14.14 that are now INPUT into
VMACTMNT tape allocation dataset TYPETALO by member VMACTMNT:
ZSUMTALO ALEERROR='ALLOCATION*ERRORS*RECORDED'
May 3, 1997 RESGROUP='RESOURCE*GROUP*NAME'
RPTCLASS='REPORTING*CLASS*NAME'
SRVCLASS='SERVICE*CLASS*NAME'
TMNT008I='TMNT008I*MESSAGE*ISSUED?'
TMNTTYPE='TYPE*OF*MOUNT*OR ALLOCATION*EVENT'
WLMNAME ='WORKLOAD*NAME'
XMEMABND='CROSS*MEMORY*ABENDS'
In addition, ML-12 added the new subtype 5 interval-end
record (to keep track of long-running allocations) but
MXG 14.14's VMACTMNT skipped over the subtype 5 record.
With this change, VMACTMNT now OUTPUTS the subtype 5
into TYPETALO, and this requires a new ASUMTALO member
that exploits these interval observations to improve the
accuracy of counts if you have long-running allocations.
This logic is more accurate than prior ASUMTALO, but may
not be perfect until the ASMTAPES ML-14 monitor provides
time-synchronized subtype 5 records. I have copied the
MXG 14.14 ASUMTALO member into ZSUMTALO and modified it
so that subtype 5 records are deleted, so you could use
the new VMACTMNT with the (renamed) member ZSUMTALO in
case you have problems. Check the counts closely.
NOTE: YOU MUST IMPLEMENT MXG 15.01 MEMBERS TYPETMNT AND
ASUMTALO SIMULTANEOUSLY - IF YOU HAVE A TAILORED
ASUMTALO MEMBER IN YOUR USERID.SOURCLIB, YOU MUST
RETROFIT YOUR TAILORING INTO THE 15.01 ASUMTALO.
(Or use the ZSUMTALO as described above).
The ASUMTALO enhancements use SPIN-type logic as well as
determining which system's SMF had the earliest cutoff of
SMF data (earliest last datetime). Data is "spun" to
SPIN.SPINTALO if it is after the cutoff or if it is the
last observation for an allocation event and it is also
an interval record (we have to adjust the start time of
the real allocation record during the next day's ASUMTALO
so that we don't count the same drive-interval twice.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.076 SAS Warning: ARGUMENT 3 TO MACRO FUNCTION %SUBSTR IS
VMXGTAPE MISSING OR OUT OF RANGE when the length of the DSN= macro
May 3, 1997 argument was three characters or less, but now will work
with any length DDNAME. (VMXGTAPE is a %MACRO to find
out if a DDNAME or SAS DATASET is on tape.)
Change 15.075 Validation of Change 15.061 uncovered opportunities.
ANALRMFR -Updates were made to logic for IOQU reports
May 3, 1997 -Incorrect paging, added array IOPI(9) IOPINSTL, added
RETAIN for IOP, ACTIVITY RATE and AVG Q LNGTH variables
during MERGE.
-MXGCHAN, changed PS=&PGS back to PS=66, because with
PS=&PGS and N=PS (to arrange the contents of an entire
printed page) does not work correctly.
-MXGSMRY moved SWAPRATE=. and PRT=. to SUMRPT dataset to
eliminate "MISSING VALUES" messages.
Change 15.074 Support for Altai's ZARA Tape Management Release 1.2.
TYPEZARA Well, almost. I have created all of the new variables
VMACZARA in datasets ZARADSN and ZARAVOL, an enhanced TYPEZARA's
May 3, 1997 back-end logic to also keep the new variables, but I do
not have the DSECT for the header yet, nor do I have any
test data yet, to the new code is in a never-execute DO
group (IF RECTYP= -99 THEN DO;) Check for an update to
this change when actual support has been tested. Note in
this rare instance, the documentation is done before the
code changes are complete!
Changes to ZARADSN dataset:
Variables added:
FILABEND FILCONT FILCRSID FILENEXT FILEXPIR FILRCFM
FILTPSTK
FILRECFM was replaced by FILRCFM, now is CHARACTER
FILFLAG1 was replaced by FILABEND FILCONT FILEXPIR
Changes to ZARAVOL dataset:
Variables added:
VOLAPERR VOLATRER VOLATWER VOLCBLVL VOLCHECK VOLCLEN
VOLCREAT VOLFILEA VOLLABEL VOLLOCK VOLSTAT1 VOLSTAT2
Variables no longer created in Version 1.2:
VOLSECUR VOLAPPID VOLGRPID VOLOBOX VOLFLG1 VOLFLG2
VOLPOOL
VOLLABL was replaced by VOLLABEL, now is CHARACTER
Thanks to ???, Nissan Motor Manufacturing (UK) Limited, ENGLAND.
Change 15.073 Support for Virtual Tape Server additions to SMF type 94
VMAC94 provide an excellent set of measures for VTS physical and
May 2, 1997 logical volume activity, including counts of mounts,
by type, lots of min/max/avg for times to mount physical/
logical volumes, time virtual drives were mounted, the
number of concurrent physical/virtual drives mounted, and
bytes read/written to host channel/from tape devices!!
Change 15.072 Variable FTPCLHST in ILKAST20 and ILKAST21 datasets from
VMACILKA Interlink has always been wrong. The "FTPCRHS3" in the
May 2, 1997 create for FTPCLHST should have been "FPTCLHS3".
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.071 Support for MEMO subtype 8 record creates new MEMODIST
EXTYMEMD dataset; subtype 8 records are written by MEMO during a
VMACMEMO distribution by an internal process.
May 2, 1997
Thanks to Thomas Peiper, Enator, SWEDEN.
Change 15.070 The start-up observation in DB2STATS and other DB2 Stats
DIFFDB2 datasets will have lots of negative values, and there are
May 2, 1997 two observations with QWHSISEQ=1 created for each real
startup. You can delete both the good and the bad start
up record with IF QWHSISEQ=1 THEN DELETE; to clean up
your reports quickly, but the logic error fixed by this
change applied to each of the Stats datasets and involved
creating an OUTFLAG=1 before the DO group for the first
OUTPUT, then setting OUTFLAG=0 inside that DO group, and
then adding AND OUTFLAG=1 to the subsequent IF QWHSISEQ
test for the second OUTPUT.
This error was introduced by Change 14.231.
Thanks to Trevor Nightingale, SAS Institute Cary, USA.
Change 15.069 Variable ARSPHOST in dataset NSPYLU for NETSPY 4.4 was
VMACNSPY frequently missing when it should have had value.
Apr 30, 1997 Variable LUNRSPSS was to be INPUT if NSPYENTL GE 112, but
the NETSPY 4.4 record had NSPYENTL=108, so LUNRSPSS was
not INPUT and hence missing, and LUNRSPSS is used to
calculate ARSPHOST. The existing test IF NSPYENTL GE 112
must be change to IF NSPYENTL GE 108 and then between the
INPUT lines for LUNRSPSS and LUATTCHS, insert:
@;
IF NSPYENTL GE 112 THEN INPUT
to always INPUT thru LUNRSPSS. MXG was unaware of the
shorter length segment. This error was noticed moving
from MXG 13.02 to 14.14 with NetSpy 4.4; I do not think
there is a problem with 4.5 and later, as I think its
segments are always NSPYENTL=112 or greater.
Thanks to Mark Zelden, Newark Electronics,USA.
Change 15.068 Revised support for HP's MeasureWare for Sun systems has
ADOCMWSU restructured the code to match the default REPORT macro,
VMACMWSU and was validated with data. Examples of moving data via
Apr 29, 1997 ftp are provided in ADOCMWSU's comments.
Thanks to Steve Corson, Cincinatti Bell Information Service, USA.
Thanks to Gary Alexander, BMC, USA.
Change 15.067 Support for NETSPY Version 5.0 is included in MXG 14.14,
VMACNSPY (there was no real change between NETSPY 4.7 and 5.0, and
Apr 29, 1997 4.7 support was added in MXG 14.03). The DSECT shows
fields added compatibly to the type 'X' (Alert) record,
but this is not a primary subtype, so until I have test
data (and a site that needs the new data in this fairly
obscure subtype) I won't add the new fields.
Change 15.066 Variable AVGXETTM in TYPE72GO was wrong; the divisor must
VMAC7072 be TRANSEXC (transactions completing "execution phase"
Apr 29, 1997 during the interval) instead of TRANS (transactions that
completed during the interval).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 15.065 EXCP and IOTM count in TYPE30/PDB.JOBS/PDB.STEPS datasets
VMACEXC2 for devices with 4-digit UCB addresses of 8000x or higher
Apr 29, 1997 were put in variables EXCPMSS/IOTMMSS (instead of the
EXCP3390 or EXCP3480 device-type buckets), and these IOs
were also not included in EXCPDASD or EXCPTAPE, although
they were counted in EXCPTODD and EXCPTOTL variables.
The old logic for the now defunct Mass Storage System,
MSS has now been commented out, but it tested the first
bit of DEVNR to identify MSS devices, causing this error.
Change 15.064 Variable SLOTUTIL is added to dataset TYPE71 to measure
VMAC71 the percentage of local page dataset slots that are in
Apr 28, 1997 use. Find the maximum value of SLOTUTIL during the month
to make sure you have enough page dataset slots defined.
SLOTUTIL should always be less than 25% (because the
ASM's contiguous slot allocation algorithm can move 30
pages in one SSCH only when there are 30 contiguous free
slots, and at utilizations above 25%, ASM begins to not
find 30 slots, so it tries to find 15, then 8... which
causes lots of extra SSCHs to your page volumes at the
very worst possible time - those few times when paging
becomes a performance problem!). I have preached this
concept, but had not provided the variable (and the value
I used in class turns out to need to be changed):
SLOTUTIL=(SLOTLOMN-SLOTUNMN)/SLOTLOMN;
compares the minimum number of defined local slots with
the minimum number of unused local slots to calculate the
maximum utilization of slots during the interval.
Thanks to Jean Quinkert, Inland Steel Company, USA.
Change 15.063 I have begun to analyze the OMVS data in TYPE30OM.
EXTY30OM The variable OMVSEXNP (OMVS Program Name, "grep", "find",
VMAC30 etc) is now 16 instead of 8 bytes.
Apr 27, 1997
TYPETASK='A ', originally for APPC/ASCH type 30 records
(other TYPETASK values are JOB/TSU/STC, taken from the
JCTJOBID), is now also used for OMVS type 30 records, so
there is no direct way to separate OMVS from APPC/ASCH
in type 30 records. However, Goal Mode records contain
WLMNAME and SRVCLASS names, which may be useful along
with TYPETASK to group type 30 records.
Dataset TYPE30OM contains an observation for every OMVS
segment, and there can be segments in interval subtypes
2 and 3, in step termination subtype 4, and in job term
subtype 5, but there is only one slot per record for the
OMVSEXNP Program Name, so the subtype 5 observations are
useless for analysis. Here's what I observed:
SUBTYPE INIT TERM STEPNAME SUBSTEP OMVSEGNR OMVSEXNP
3 59:02.16 02.29 STEP1 0 1 find
4 59:02.16 02.30 STEP1 0 1 find
3 59:02.30 02.51 *OMVSEX 1 1 grep
4 59:02.30 02.51 *OMVSEX 1 1 grep
5 59:02.16 02.52 0 1
5 59:02.16 02.52 0 2
Subtypes 3 & 4 have OMVS program name in interval and
step records. The single subtype 5 job record has two
OMVS segments, representing the two OMVS invocations (one
per each step, in this instance), but the OMVS segments
in subtype 5 cannot be associated with their program
name. As a result, I no longer output obs in TYPE30OM
from subtype 5 records (although you can change my new
default in member EXTY30OM).
Change 15.062 Analysis of impact of DDCONS(NO) versus DDCONS(YES) with
ANALDDCN regard to the number of duplicate DDs that are written to
Apr 27, 1997 SMF when the (recommended) DDCONS(NO) option is
specified. This analysis proves how little duplicates
there are and refutes arguments that lots of additional
SMF records will be created. See MVS Technical Note in
Newsletter 32.
Change 15.061 Variables PCTDIRPT and PCTCUBSY in TYPE78CF dataset were
VMAC78 incorrect. The calculation of PCTDIRPT was changed:
Apr 26, 1997 Variable R783DPB is now INPUT where PCTDIRPT was, and
May 3, 1997 now the calculation of PCTDIRPT is changed to
IF (CHPIDTKN+R783DPB+PCTCUBSY) GT 0 THEN
PCTDIRPT=100*R783DPB/(CHPIDTKN+R783DPB+PCTCUBSY);
ELSE PCTDIRPT=.;
and the calculation of PCTCUBSY was changed to:
IF SUM(CHPIDTKN,R783DPB,PCTCUBSY) GT 0 THEN
PCTCUBSY=100*PCTCUBSY/SUM(CHPIDTKN,R783DPB,PCTCUBSY);
ELSE PCTCUBSY=.;
The SUM() statement is needed for PCTCUBSY calculation to
protect for missing values (old versions of RMF do not
have all three variables), but is not needed for PCTDIRPT
because that calculation is inside loops which guarantee
the existence of the three variables.
Thanks to Thomas Neurauter, Fidelity Systems, USA.
Change 15.060 For CICSEXCE observations from CICS/ESA, variables
VMAC110 DURATM and STARTIME were always missing, but now both
Apr 26, 1997 variables are created in CICSEXCE for consistency.
Thanks to Trevor Nightingale, SAS Institute Cary, USA.
Change 15.059 If a MIM record segment contained MIMCNT=0, Version 3
VMACMIM segments after the zero were not read, because the line
Apr 26, 1997 IF MIMCNT = 0 THEN DELETE; deleted the record. For the
Version 4 record, that statement had been commented out.
This change puts IF MIMCNT GT 0 THEN DO; ... END;
around both of the OUTPUT statements for both versions,
so only records with samples are output, but so that
a zero segment doesn't stop the scan for other segments.
Thanks to David L. Dittmar, IBM Global Services, USA.
Change 15.058 Variable R745CINT is now kept, formatted TIME12.3 and
FORMATS labeled in dataset TYPE74CA; it is the Cache interval
VMAC74 and is used in all rate calculations (instead of the
Apr 25, 1997 RMF variable DURATM). The IF CSCSS1='...1....'B line
misspelled CSCSDFM0='N', should be CSCSDFM1='N'. The
variables CSDEVPI and DEVPI have been incorrectly decoded
by format MGCACPI, which was replaced by MGCACPD. New
variables CSDPIDAT/CSDPIFAI/DEVPIDAT/DEVPIFAI are now
replacements for CSDEVPI and DEVPI. Format values for
MGCACRC format (for variable RCOL) were enhanced; this
field/format describes record level caching mode.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.057 New RACF events are now decoded by format MG80EV, with
FORMATS new Open Edition events, process actions, etc. It is
Apr 25, 1997 worth your while to read the list of possible events!
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 15.056 This utility is now a %MACRO which can be invoked with:
UTILCONT %UTILCONT(PDB=WORK);
Apr 25, 1997 to show the size (Megabytes, Observations, etc) of each
SAS dataset in the PDB= Data Library, with one line per
dataset. And it now works under Windows as well as MVS!
It still requires an //INSTREAM or FILENAME INSTREAM to
write to and read from (ok, it's crude, but it works,
especially when I have filled my WORK file and need to
see which datasets are big and which are small).
This is a structural revision of the earlier UTILCONT.
Thanks to Vickie Drake, Levi Strauss & Co.
Change 15.055 Inconsistency analysis of MXG code found several errors:
ASUM70PR -ASUM70PR. In the calculation of TOTSHARE=SUM(LP0SHARE,..
CICINTRV variable LPESHARE was repeated; the first instance of
DIFFTMDB LPESHARE should be LPDSHARE.
VMAC42 -VMACQAPM. Variable OS2CT16 should have been divided by
VMACQAPM 1000 and formatted TIME12.3, just like variable OS2CT14,
VMACTMDB and now it is. Variables ASBRCV ASBTRN LSBRCV LSBTRN
Apr 25, 1997 SDBRCV SDBREX SDBXMT SYBRCV SYBREX SYBXMT are now
formatted with MGBYTES. Variables ending with PWT in
QAPMSNA are formatted TIME12.3 now.
-VMAC42. Variables SMF42JNC and SMF42JND are now length
8 with format DATETIME21.2, and variable SMF42JNE is
format TIME12.3.
-VMACTMDB. Numerous previously unlabelled variables are
now labeled, and several DA9STCTx variables that were not
kept in TMDBDA2 dataset, now are.
-DIFFTMDB. Datasets TMDBDAB, TMDBDA2 and TMDBDAF are now
SORTed and Deaccumulated to create DURATM and ENDTIME
variables for these interval datasets.
-CICINTRV. The first statement A06TEOT=DIFTEOE should be
A06TEOE=DIFTEOE. The VMXGSUM for INDATA=SRTDLIR had
INVOKEBY comment of INTDBU instead of INTDLIR. Variable
A10IDQN appeared twice in KEEP= list for SORT of CICDQR.
Variable A17DSTSW was misspelled as A17DTSW.
Thanks to Chris Weston, SAS Cary, USA.
Change 15.054 TMON/CICS variables SYSTEM and SYSID were truncated to
TYPETMON only one byte as a result of Change 14.342. Statement:
Apr 25, 1997 IF SYSTEM=' ' AND SYSID=' ' AND TMMDREC='TA' ....
inserted by that change must be changed to read:
IF SYSTEM=' ' AND SYSID=' ' AND TMMDREC='TA' ....
(i.e., four blanks instead of one blank for SYSTEM &
SYSID). The inserted statement became the first
assignment of the two variables, so SAS used it to set
their length, in place of the later INPUT statements
that had previously defined the variable's lengths.
Thanks to Henry Schreiber, Amdahl, USA.
Change 15.053 First draft of MXG recommendations for SMF parameters
SMFPRM00 that are specified in member SMFPRM00 of SYS1.PARMLIB.
Apr 24, 1997 Extensive discussion of why options are recommended.
Will be expanded into discussion of
to synchronize or not to synchronize
to DDCONS(YES) or to DDCONS(NO)
system delays during the SMF interval pop.
Thanks to Henry Pomorski, Harris County, USA.
Thanks to Robert Rudd, Harris County, USA.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 15.052 Support for all AS/400 OS/400 Release 3.7.0 records. MXG
VMACQAPM had earlier supported only the critical records (CONF,
Apr 22, 1997 SYS,JOBS, and DISK), and had coded many new variables
Apr 25, 1997 added to the end of the records, but the incompatible
insertion of IOPRN (IOP RESOURCE NAME) was overlooked
until hit with test records. These datasets were
incompatibly changed between 3.6 and 3.7 by the insertion
of IOPRN: QAPMHDLC,ASYN,BSC,X25,ECL,STNL,ETH,STNE,DDI,
DDI,STND,FRLY,STNY,CIOP,DIOP,LIOP,MIOP,RESP,RWS,LAPD,IDLC
and QAPMIOPD. In addition, IBM incompatibly changed the
field lengths in QAPMPOOL, and fields were removed from
QAPMRESP, QAPMX25, & QAPMRWS. Existing variables named
CIDMAO/CIDMAI/DIDMAO/DIDMAI are now named CIKBY0/CIKBYI/
DIKBY0/DIKBYI, but MXG kept the original names and uses
conversion from KBytes back to bytes so MGBYTES format
will print same magnitudes before and after 3.7.0!
Thanks to Len Marchant, Coca Cola Enterprises, USA.
Thanks to Cheryl Howard, NationsBank, USA.
Change 15.051 Change 14.321 (CF Structures) added trap if number of QO
VMAC74 and SO sections were not equal (trap prints MXG DISCOVERY
Apr 21, 1997 NO STRUCTURE MATCH on log), but trap springs if there was
no QO section at all. While unexpected, I have added
protect for SMF744QN=0 while we talk with IBM to find out
why the record has Request Data sections but had no
corresponding Structure Data Section.
Thanks to Joe Schwartz, Cigna, USA.
Change 15.050 Protection for products that do not support year 2000 has
YEAR2000 been added in MXG Software. Windowing (00-59=20yy, 60-99
Apr 20, 1997 =19yy) has been added during INPUT of JULDATE fields if
the century bit is not enabled (i.e., where the record
vendor does not support the year 2000, MXG can still do
the right thing and create the correct year 2000 date.
A more extensive note and update to member YEAR2000 will
be written and this text will be revised.
As of May 5, JULDATEs have been windowed, but there are
other forms to be protected, and member YEAR2000 has not
yet been updated to identify the new category of products
that are now "MXG-protected".
Change 15.049 TIC_UTIL is now added to NPMLANOD and NPMINTRI datasets.
VMAC28 (It was calculated but not kept in NPMINTRI, and the
Apr 17, 1997 units of time-per-byte were corrected to nanoseconds in
NPMLANOD).
Thanks to Ian Hindshaw, Standard Bank of South Africa, SOUTH AFRICA.
Change 15.048 Variables SMF6FDNM (Form Def) and SMF6PDNM (Print Def)
IMACPDB are added to dataset PDB.PRINT, as they are often used to
Apr 17, 1997 determine print characteristics in analysis. They were
always captured in TYPE6 dataset, but were not in the
list of variables (in IMACPDB) to be kept into PDB.PRINT.
Thanks to Jerry Maier, First Chicago NBD, USA.
Change 15.047 ML-13 of ASMTAPES contains enhancements to provide error
ASMTAPES recovery for the mount monitor's AR code. ML-13 will not
Apr 17, 1997 correct these problems, but it will recover from them so
the monitor stays up. In addition, when the monitor is
run in "DEBUG" mode, an ABEND in ML-13 will generate an
SVC dump of both address spaces (monitor and monitored)
which will hopefully provide enough diagnostics data that
the next iteration will eliminate these errors. In
addition, there are two other fixes: ML-13 prevents S0C4
ABENDS when the TCBTIO is zero, and ML-13 corrects the
ALESERV return code in the TMNT008I message.
Thanks to Ruth Whitney, CITICORP, USA.
Thanks to Tom Parker, Hogan Systems, USA.
Thanks to Will Evans, Consolidated Freight, USA.
Change 15.046 Change 14.345 added code, but the 4DIGITUCB comment was
FMXGUCBL coded into column 72, causing an ASSEMBLY errors such as
Apr 13, 1997 BEGIN-TO-CONTINUE COLUMNS NOT BLANK. Move left one col.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt AG, Germany
Change 15.045 Datetime variables that had DATETIME18. formats are now
DOC DATETIME20., so as to display all four digits of years.
YEAR2000 I also observed that truncated DATETIME formats will not
Apr 13, 1997 display four-digit year for the date, hour, minute or
second truncations - I hoped DATETIME9 could be enhanced
to show the yyyy, but as it now prints seven positions,
and increase could cause existing applications to fail
(the wider field would shift right or overlay), so SAS
Institute cannot make the change.
value printed DATETIMExx. truncation
01FEB84 7-8-9 date,daily
01FEB84:22 10-11-12 hourly
01FEB84:22:33 13-14-15 minutely
01FEB84:22:33:59 16-17-18 secondly
01FEB1984:22:33:59 19-20-21-22 secondly,yyyy
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.044 Format $MGCICLO did not decode values 08x,09x,0Ax values
FORMATS but now it does into 08X:SDSA, 09X:ESDSA, and 0AXRDSA.
Apr 13, 1997
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.043 Change 15.037 changed TYPE116 variable QWHCTNO from
VMAC116 &PIB.4. to &NUM.4., but data values that are not EBCDIC
Apr 13, 1997 numbers (eg., 004DF3D4x), so the input is changed back
back to &PIB.4., is now formatted as HEX8., and is now
kept as LENGTH 5 (to display all four bytes numeric, an
extra byte must be kept). I could have changed to a
character variable of length 4 with $HEX8 format, but
then prior TYPE116 datasets would be incompatible with
newly build TYPE116, so I kept the variable as numeric.
I am also asking IBM if these values are expected for
the CICS Thread Number - their answer was that it really
is a token and is not necessarily a number.
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.042 Tandem Disk Drive subtype 30 is now 30:4GB/4260.
FORMATS (It was decoded as 30:3GB before format MGTANDS was
Apr 13, 1997 corrected by this change). Tandem Disk Drives type
Apr 25, 1997 4245,4255,4265,4560, and 4570 are now decoded.
Thanks to Hannu Koski, SJ Data, SWEDEN.
Change 15.041 Cosmetic. The JCL example for the //CONTENTS DD did not
UTILCONT have BLKSIZE=, but now it does.
Apr 1, 1997
Thanks to Vickie Drake, Levi Strauss & Co., USA.
Change 15.040 IBM can write type 72 subtype 2 (TYPE72MN - RMF III MON)
VMAC7072 records with zero for DURATM, which caused DIVISION BY
Apr 1, 1997 ZERO error, so protection was added to protect PGINRATE:
IF DURATM GT 0 THEN PGINRATE=MONPGIN/DURATM;
These zero duration records occurred under MVS/ESA 5.2.2
and have strange values for SWAPDLUS and SWAPDLIC but
other variables have reasonable values, and the STARTIME
was 15:20:00.00, SYNCTIME 14:27:54.81, and the SMFTIME
was 15:27:59.91, so why DURATM is zero is unknown.
Thanks to Martin Peck, CA-IT/BM, AUSTRIA.
Change 15.039 IBM's "MVS PSF DOWNLOAD" product created invalid SMF type
VMAC6 6 records (SMF6LN3/SMF6LN6 are located two bytes beyond
Apr 1, 1997 where they should be). APAR OW23937 reports the error,
and PTF UW34926 corrects the error, but bad records can
be read by MXG by conditionally INPUTing the two LENx
fields as PIB4 instead of PIB2 by inserting:
IF LENGTH=274 THEN INPUT @OFTONXT SMF6LN3 &PIB.4. @;
ELSE
before the existing:
INPUT @OFTONXT SMF6LN3 ..... statement
and by inserting
IF LENGTH=274 THEN INPUT @OFTONXT SMF6LN6 &PIB.4. @;
ELSE
before the existing:
INPUT @OFTONXT SMF6LN6 ..... statement
NOTE: This Change was NOT made to MXG Software, but is
only printed here for temporary circumvention to read
records created prior to the installation of the PTF.
Thanks to Hal Merritt, Texas Commerce Bank, USA.
Change 15.038 -Dataset TYPE72GO variable R732CIRC is now R723CIRC to be
VMAC7072 consistent with other subtype 3 type 72 variables.
Apr 1, 1997 -The calculation of NRPTRANS was incorrect, which also
caused the calculation of PERFINDX for Percentile Goals
to be incorrect.
The equation that was: NRPTRANS=TRANS*TRANEXEC/100;
is now: NRPTRANS=TRANS*R723CPCT/100;
-IBM's RMF report calculation of PERFINDX for Percentile
Goal Service Classes can be wrong, producing a value that
is greater than true, especially when the number of TRANS
is small. IBM sums transactions until the sum is GT the
percentage goal, but the definition in the SRM (and now
in MXG) should stop when the sum is GE. For example,
with 10 transactions and a 70% goal value
bucket: 1 2 3 4 5 6 7 8 9 10 11 12 13
RTSMAP: .5 .6 .7 .8 .9 1.0 1.1 1.2 1.3 1.4 1.5 2 4
RTSTRN: 3 0 1 2 1 0 1 0 0 0 0 1 1
RMF counts to the 7th bucket, setting PERFINDX=1.1, but
MXG and the SRM stop at the 5th bucket, PERFINDX=.9,
because 7 out of 10 transactions did meet the goal!
The equation IF SUMPTRAN GT NRPTRANS THEN DO;
was changed to IF SUMPTRAN GE NRPTRANS THEN DO;.
-26Jun97: The following error was originally documented
here in April, 1997, but now has been corrected by APAR
OW26609. See MVS Technical Note 22 in Newsletter 32:
Variable R723CIRC appears very right in lots of cases,
but is very wrong in some Service Class data (notable,
TSO, which has multiple periods) when compared to
TYPE30 interval data. This is still under investigation
but it is most likely an IBM error in RMF
daccumulation in multiple period service classes for
this new variable. The numbers on the RMF report look
fine, because RMF only prints the avg time per I/O
(R723CICT/R723CIRC); it looks like both fields are each
wrong! For 5 periods of TSO in a 30 minute interval:
R723CIRC R723CICT R723CIWT R732CIDT ACTIVETM TRANS
23179776 15:45:17.81 2:18:18.80 6:23:29.81 0:01:28 1309
177746 0:07:53.98 0:01:07.03 0:03:24.63 0:01:22 358
342664 0:13:54.80 0:02:06.71 0:05:55.51 0:04:44 378
10639 0:00:29.34 0:00:04.83 0:00:02.56 0:00:49 10
5180 0:00:13.68 0:00:01.76 0:00:00.94 0:02:19 6
That is 16 hours of connect time in 30 minutes (or 32
I/O concurrently transferring data during the entire
interval) or is 13,000 SSCH per second? I think not!
Clearly, APAR OW26609 must be installed to correct!
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Dale Mattison, Shared Medical Systems Corporation.
Change 15.037 The INPUT of TYPE116 variable QWHCTNO must be changed
VMAC116 from &PIB.4. to &NUM.4. (since the value is an EBCDIC
Mar 29, 1997 number) and the INPUT of variable QWHCTASK must be
changed from &PIB.4. to &PD.4. But see Change 15.043.
Thanks to Helmut Roese, COM GmbH, GERMANY.
Change 15.036 Duplicate.
Change 15.035 The INPUT of TYPE80A variable ACEEUSER was increased from
VMAC80A $VARYING20. to $VARYING30., as data of length 25 was
Mar 29, 1997 found at one site, and an MXG note prints on the SAS log
if a longer length string is found in your data. lmut
Thanks to HeRoese, COM Gmbh, GERMANY.
Change 15.034 CICS Statistics variable A08BKHSW must be INPUT &PIB.2.
VMAC110 and +2 instead of &PIB.4., as it is only a half-word that
Mar 29, 1997 is followed by two reserved bytes.
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.033 Change 12.264 for IMF variables ABENDSYS and ABENDUSR was
VMACCIMS only correct for old IMF 1.2, and only for ABENDSYS. The
Mar 29, 1997 revised algorithm to decode the two intermingled fields
(stored as xxSSSUUU in four bytes) now reads:
@117+OFFIMS +1 /*SKIP OVER XX OF XXSSSUUU: */
@118+OFFIMS ABENDSYS &PIB.2. /*OVERLAY 117 118 119 120 */
@119+OFFIMS ABENDUSR &PIB.2. /* XX SS SU UU */
/* +1 ABENDSYS */
. /* +1 +1 ABENDUSR*/
The first byte is skipped, the second two bytes are input
into ABENDSYS as PIB2., the third and fourth bytes are
INPUT in ABENDUSR as PIB2. Then, after the INPUT ends,
in both the old 1.2 and later 1.3 groups, this code:
ABENDUSR=MOD(ABENDSYS,16)+ABENDUSR;
ABENDSYS=FLOOR(ABENDSYS/16);
creates ABENDSYS=0013x and ABENDUSR=0000x from 00013000x
(ABENDUSR must be done first, because it uses ABENDSYS
which then stores into itself).
Thanks to M. Nicolas, BNP, FRANCE.
Change 15.032 Variable SERVUNIT was only length 4 in PDB.STEPS and in
BUILD005 PDB.SPUNJOBS, but it should have been length 5 (since
BUIL3005 Change 14.214). The LENGTH statement following PDB.STEPS
BUILDPDB now has SERVUNIT 5 added in the BUILxxxx members,
BUILDPD3 as does the LENGTH statement following PDB.SPUNJOBS in
SPUNJOBS member SPUNJOBS.
Mar 27, 1997
Thanks to Trevor Ede, Bank of New Zealand, NEW ZEALAND.
Change 15.031 Warning message that datasets WORK.INTxxx don't exist is
BUILD004 because the datasets were deleted in both CICINTRV and
BUILDPDB the BUILD004/BUILDPDB/BUILDPD3 members. Since these are
BUILDPD3 CICS only datasets, the DELETE belongs in CICINTRV and
Mar 27, 1997 they are removed from the DELETE in the three BUILDxxx
members.
Thanks to Martin Peck, CA-IT/BM, AUSTRIA.
Change 15.030 When SOFTAUDIT is enabled to collect data only at the JOB
VMACSFTA level, the record is only 115 bytes long, so the test
Mar 27, 1997 IF LENM=131 THEN DO; must be changed to:
IF LENM=115 OR LENM=131 THEN DO;
Thanks to Rick Green, Comerica, Inc, USA.
Change 15.029 -Error in MXGCHAN macro caused RMF Channel Reports to fail
ANALRMFR with a syntax error. The statements &PDB..TYPE73 ; and
Mar 27, 1997 &&PDB&I...TYPE73 ; must have those semicolons removed.
-All of the "PROC PRINT"s and their TITLE statements
should have been deleted (they were debugging prints) to
save paper (or at least SPOOL space!).
Thanks to Michael Creech, Alltel Information Services, USA.
Change 15.028 Variable RVDSNAM1 (FIRST FILE*DATASET*NAME) is now INPUT
VMACEDGR (immediately after RVMEDATR) and kept in RMM dataset
Mar 27, 1997 TYPEEDGR; I'm not sure when this field was added by IBM.
Thanks to Ben Cowan, UCCSN System Computing Services, USA.
Change 15.027 NTSMF discovered new objects created by COMPAQ so four
EXNTCMBU new datasets are now created from these objects:
EXNTCMCN CMPQBUSU Compaq EISA/PCI Bus Utilization
EXNTCMDV CMPQCTLR Compaq 32-Bit SCSI-2 Controllers
EXNTCMNF CMPQDEVS Compaq 32-Bit SCSI-2 Devices
IMACNTSM CMPQCMNF Compaq NetFlex-3 Network Driver
VMACNTSM I note that the Controllers record appears to have a per-
Mar 26, 1997 controller record with CTRLNAME containing the name of
Apr 28, 1997 the controller (eg. \\.\Scsi0) and a second interval
record with CTRLNAME blank (which I assume is an interval
total, but have not had two controllers' data for
verification). Revised Apr 28: NTSMF Version 2.0 adds
two new fields NTVERSN (NT VERSION, 4.0) and NTVERSP (NT
SERVICE PACK, SPK1) to the header of each NTSMF record.
The variables are kept in the PROCESOR dataset and in
dataset NTINTRV (although they will be blank until you
install NTSMF Version 2.
Thanks to Richard Clary, Entergy, USA.
Change 15.026 The new VELOCITY calculation for OS/390 Release 3
VMAC7072 includes I/O delay time if it was enabled (see Change
Mar 25, 1997 14.318), but some sites may need to know the old or new
May 29, 1997 velocities before they are enabled, so two new variables
were introduced:
VELOCCPU 'CPU ONLY*EXECUTION*VELOCITY'
VELOCIOD 'I/O DELAY*EXECUTION*VELOCITY'
and are kept in both TYPE72 and TYPE72GO datasets. The
variable VELOCITY will continue to contain the actual
velocity, and variable R723VELI='Y' will flag whether or
not the value of VELOCITY contains I/O DELAY time.
Text of this change was incorrect until May 29, 1997, but
the above change was made to the code in March.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 15.025 A typo had real impact - variable BATCHMAX was renamed to
TRNDRMFI MATCHMAX. The correct spelling is BATCHMAX.
Mar 25, 1997
Thanks to Dave Schultz, First Card, USA.
Change 15.024 A typo had minor impact - a FORMAT statement was absorbed
TYPEIMSB as a comment because a comment was not terminated. The
Mar 25, 1997 INFILE IMSSUMS0 END=END; /* comment .... text *
should have ended with */
Thanks to Kristyann Manske, University of Wisconsin-Milwaukee, USA.
Change 15.023 TYPE70 variable PCTMVSBY was wrong (although it did match
VMAC7072 IBM RMF report values) for Amdahl MDF domains with some
Mar 25, 1997 shared and some dedicated CPUs. The MXG equation was
(CPUUPTM-MVSWAITM)/CPUUPTM=58:56-16:00/58:56=43/59=72.8%,
but that assumed the total dispatch time of all CPUs was
CPUUPTM=NRCPUS*DURATM or 59 minutes, when in fact the
true dispatch time was only 46 minutes, and the true CPU
busy time was 30 minutes, and not 43 minutes as shown
below:
The MDF partition had DURATM=14:44.05 with CPUs 0 and 3
given 100% target allocation but CPUs 1 and 2 were shared
with only 55% target allocation for this partition:
LCPUn CPUPDTMn CPUWAITn MVSWAITn MVSBUSYn
0 14:43.99 5:42.42 5:42.37 9:01.62
1 8:35.56 8:22.62 2:14.13 6:21.43
2 8:35.18 8:19.20 2:10.34 6:24.84
3 14:43.92 5:53.71 5:53.59 8:50.33
CPUPDTTM CPUWAITM MVSWAITM CPUACTTM
total 46:38.65 28:17.97 16:00:43 30:38.22
CPUACTTM has 30:38 minutes of actual CPU seconds for the
partition, and CPUPDTTM has 46:30 minutes of dispatch,
so the true PCTMVSBY (percent of dispatch time when this
MVS was busy) is 30/46 or 65.7% (versus IBM's 72.8%) so
the revised MXG equation is now:
PCTMVSBY=100*CPUACTTM/CPUPDTTM;
(IBM footnotes that their value is the arithmetic mean,
which if correct if each LCPU is dispatched equally as
is the case with their PR/SM, so they implied you should
be wary, but apparently IBM won't modify its RMF reports
for MDF idiosyncrasies - but MXG does!).
The variable CPUUPDTM (total partition dispatch time) is
also now calculated and kept in TYPE70 dataset.
This site also enabled the old Amdahl MDF option "Wait
Complete=No Reporting" (see Change 12.289), but that
option appears to be useless when engines are shared
between domains; while the real CPU usage is known, that
option loses the domain dispatch time, so you can never
know what was the capacity available to each
domain/partition.
Thanks to Kirk Poore, Union Electric, USA.
Change 15.022 Old HP-PCS and new HP-MW code still had date litterals of
VMACHPAI JAN70 (the epoch of the Unix Clock) that are now changed
VMACMWAI to JAN1970. (With YEARCUTOFF default, SAS would have set
Mar 19, 1997 the correct date, but it is MXG's intention to support
the year 2000 intrinsicly, rather than thru YEARCUTOFF).
Thanks to Graeme Yeandle, British Telecom, ENGLAND.
Change 15.021 -Variables EDGSADTE and EDGSARSD are added to DATE9 format
FORMATS and the ELSE was removed from ELSE IF after the INPUT of
VMACEDGS EDGSAFLG in the ID=_IDEDGUS logic block (because records
Mar 19, 1997 from SMF were not INPUT due to the extraneous ELSE).
Mar 29, 1997 -Variable EDGSASID must be input as $EBCDIC4. instead of
$EBCDIC8. in the EDGSSECU dataset - not only was EDGSASID
wrong, but all following fields were too, but fortunately
the EDGSSECU data set is just now being investigated!
-Value 18:SAF CALL was added to the MGACFDA format in
member FORMATS for ACF2.
Thanks to Pete Young, University of Toronto, CANADA.
Change 15.020 JES3 BUILDPD3 created additional PDB.JOBS/PDB.STEPS obs
BUILDPD3 that contained only TAPEMNTS TAPFETCH SMFTIME, because
BUIL3005 multiple TYPE25 observations were inadvertently created.
Mar 19, 1997 In the logic following DATA ONE25;, find the statement
TAPEMNTS=MOUNT; and insert the statement OUTPUT;
immediately following (and before the END;).
Thanks to Neal Musitano, Jr., Department of Veterans Affairs, USA.
Change 15.019 Variable ULOGADAE was changed to be INPUT as &PIB.4.3
VMACCOMP in only one statement, but there were two overlooked
Mar 19, 1997 statements for ULOGADAE that are now also changed.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 15.018 -The Label for dataset TYPE8011 should be ALTDSD and not
VMAC80A ADDUSER.
Mar 19, 1997 -Variable USERID was inadvertently removed from TYPE8014
dataset in MXG 14.14, so USERID was added to KEEP= list
for dataset TYPE8014, and the 1st occurrence of USEROWNR
after ELSE IF RACFEVNT=14 THEN DO; after WHEN (6) was
changed back to USERID, so both USERID and USEROWNR will
be kept in TYPE8014 dataset.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 15.017 Support for CA-ROSCOE Version 6 SMF Record has been
VMACROSC verified (i.e., the V6 records do not cause MXG to fail
Mar 18, 1997 although I have not yet verified with the DSECT).
Thanks to Bob Bunt, NYSEG, USA.
Change 15.016 Support for CA-DISPATCH Version 6 and five-digit JESNR.
IMACCADI CA relocated the five-digit JESNR to a new area at the
VMAC6 end of the record, and new fields CADIARCH and CADIBUND
Mar 14, 1997 are now created (only if you enable CADI support in the
IMACCADI tailoring member).
Thanks to Kenton O'Brien, Barclays, ENGLAND.
Change 15.015 Support for Anacom's Anastack product (spools data to
VMAC6 microfiche, etc.) which writes a type 6 SMF record. The
Mar 14, 1997 record is an "External Writer" record (DEVICE='EXT WTR')
so many of the JES-only and PSF-only fields will be
missing, but the event, JOB, and number of lines are
captured. No code was changed in MXG, since external
writer records are already supported.
Thanks to Dave Crandall, Farmers Group, USA.
Change 15.014 Change 14.245 (added variables to some BY statements to
WEEKBLD better protect for duplicate SMF records in BUILDPDB) was
WEEKBLDT not fully implemented in WEEKBLD and WEEKBLDT, so the BY
Mar 12, 1997 lists are not exactly the same, but there should be no
execution error. Now, the BY lists are consistent.
Thanks to Tom Parker, Hogan Systems, USA.
Change 15.013 Variable SSTORE72 (Shared Pages Bytes) is now created in
VMAC7072 dataset TYPE72GO, for consistency with variables
Mar 12, 1997 CSTORE72 ESTORE72 TSTORE72 that were added earlier.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.012 -NTSMF records from NT 3.51 for SQLSERVER, SQLSERVER-LOCKS
IMACNTSM and SQLSERVER-LOG have fewer fields than NT 4.0; now that
VMACNTSM I have raw records, MXG was enhanced to support these NT
Mar 12, 1997 3.51 records.
Thanks to Richard Clary, Entergy, USA.
Change 15.011 Variable SMF744PN was added to dataset TYPE74CF to count
VMAC74 the number of processors in this Coupling Facility. You
Mar 11, 1997 you could have derived the number from CFNUM01-CFNUM16,
by counting, but you should not have to!.
Thanks to Rick Poliak, Amdahl, USA.
Change 15.010 Support for Landmark's "Performance Works/Smart Agents
ADOCPW for UNIX" dumped output (see ADOCPW for syntax of their
EXPWACCT dump command) creates twenty new PWPxyyyy datasets:
EXPWCPUP From Product Detail records:
EXPWDEVD Dataset Name Description
EXPWDEVS PWPDACCT PROCESS ACCOUNTING
EXPWFSL PWPDFSL LOCAL FILE SYSTEM CAPACITY
EXPWFSR PWPDFSR REMOTE FILE SYSTEM RECORD
EXPWMESS PWPDPD PROCESS DETAIL
EXPWNCO PWPDPDI PROCESS DETAIL INTERVAL
EXPWNIND PWPDPDS PROCESS SUMMARY
EXPWNINS PWPDPGM PROGRAM RECORD
EXPWNSO PWPDTERM TERMINAL SUMMARY RECORD
EXPWPD PWPDUFSQ QUOTAS RECORD
EXPWPDI PWPDUFSS USER FILE SYSTEM STORAGE
EXPWPDS PWPDUSER USER SUMMARY RECORD
EXPWPGM From Product Interval records:
EXPWPI Dataset Name Description
EXPWTERM PWPICPUP PROCESSOR RECORD
EXPWUFSQ PWPIDEVD DEVICE USAGE INTERVAL
EXPWUFSS PWPIDEVS DEVICE USAGE SUMMARY
EXPWUSER PWPINCO NFS CLIENT OVERVIEW
IMACPW PWPININD NETWORK INTERFACE INTERVAL
JCLPW PWPININS NETWORK INTERFACE SUMMARY
TYPEPW PWPINSO NFS SERVER OVERVIEW
VMACPW PWPIPI SYSTEM SUMMARY RECORD
Mar 11, 1997 From Product Log records:
Dataset Name Description
PWPLMESS CONSOLE MESSAGES TEXT
Landmark's initial response to documentation was to use
the "ODBC" interface to their database, but this could
only work if you intended to run SAS on the UNIX system
you are measuring, so MXG's more general solution is to
use their ASCII dump of the data store, so you can ship
the raw ASCII data (convert to EBCDIC during transfer) to
OS/390 for processing there like your other "SMF" data.
(The MXG code will also work fine on UNIX or WINDOWS to
directly process the dumped ASCII.)
Unfortunately, their dump has no selectivity of fields,
so you must dump all fields of each record (the CPUP has
32 fields in the Data Model, but 105 fields in their data
store!). And you cannot select the interval; you get all
all six drawers: minute,hour,day,week,month,and year.
And of course, being typically-UNIX, the drawer values
are m,H,d,w,M,Y, with upper and lower case "m" in use for
two different drawers - a nice exposure to coding errors
that mandates VMACPW must be in mixed-case!!!!! In spite
of these deficiencies, the process does work so that you
can monitor your UNIX resources with Landmark's PW
replacement for The Monitor for Unix, formerly TYPETUX.
Thanks to Dan Sedorik, SmithKlein Beecham, USA.
Change 15.009 Support for APAR OW25152 that adds PRINTWAY Print Queue
VMAC6 Name SMF6PRTQ to TYPE6 dataset, compatibly made. I have
Mar 7, 1997 assumed a maximum name length of 16 to save storage. The
Jul 14, 1999 PRINTWAY internal subsystem value of SMF6SBS='0009'x is
used by MXG to set SUBSYS='TCP' for PRINTWAY records.
See Change 17.171 for PRINTWAY impact on TYPETASK.
Change 15.008 -Wrong values for CSCONF,CSAVAIL,CSOFFL,CNCONF,CNPINNED
VMACACHE and CSSTAT with Hitachi 7700, probably due to bad IBM
VMAC74 SMF documentation rather than Hitachi. In the SMF manual
Mar 7, 1997 CSSTAT='....1111'B is the 3990-6 Enhanced Mode flag, and
that is the value in IBM 3990 records, but IBM's Storage
Control manual GA32-0274 documents CSSTAT='.......1'B as
the expected value, and that is the value in Hitachi 7700
records (which are in fact in Enhanced Mode format)! To
support both IBM and Hitachi, MXG's test is changed to:
IF CSSTAT='.......1'B THEN DO;
(The storage sizes are in units of 1024 bytes in the
3990-Enh format records, or are in bytes if not.)
-In VMAC74, the label for CSSTAT is 3990-6 (vice 3880-6!).
-A second HDS 7700 problem: with 3GB of cache, 4080GB of
cache is reported! (Raw data value is 'FF040000'X). PTF
UW36274 may address, but Hitachi is investigating and
this note will be updated when more is known.
Thanks to Miller Dickson, DST Systems Inc, USA.
Change 15.007 Analysis of APAF Shared processors used NUMLP (the number
ANALAPAF of total engines) to calculate PHY_BUSY, but using number
Mar 7, 1997 of engines available to this domain, LINUMLPS, makes more
sense.
Thanks to Gary Strohminger, AT&T Transtech, USA.
Change 15.006 ERROR: WORK.CICINTRV.DATA DOES NOT EXIST if you changed
CICINTRV IMACCICS to write CICS Statistics to the //WORK DD.
Mar 7, 1997 Move the PROC DATASETS; DELETE CICINTRV; to the bottom
of member CICINTRV to correct my error.
Thanks to Fred Kaelber, Pacific Bell, USA.
Change 15.005 Cosmetic. Label for variable SMF42EAC should have been
VMAC42 ACTIVATE*ENF OR*VARY SMS (instead of VARY SMF).
Mar 7, 1997
Thanks to Solomon Baker, Prudential, USA.
Change 15.004 OS/390 V 1 Rel 3 type 72 record INPUT STATEMENT EXCEEDED
VMAC7072 RECORD LENGTH error. The statement SKIP=SKIP-24; that
Mar 1, 1997 is after the statement R723CIDT=128*R723CIDT; must be
changes to SKIP=SKIP-68;
Thanks to Perry Gibson, Candle Corporation, USA.
Change 15.003 All OMVS File Activity datetimestamps were in GMT, but
VMAC92 are now converted from GMT to local (using the same
Feb 27, 1997 algorithm introduced in Change 14.311). In TYPE9210, the
close time, SMF92CTC, is often .01 seconds later than the
SMFTIME value, which in theory should not happen, but is
valid because SMFTIME informat is truncated to .01 sec
resolution while TODSTAMP (SMF92CTC) informat has micro
second resolution that is rounded to .01 seconds by the
DATETIME21.2 format. A true time of .026 seconds will
be .02 input as SMFTIME and .026 if input as TODSTAMP,
but will print as .02 and .03 respectively with the
DATETIME21.2 format (increasing that format to 22.3
would show the .026 value).
Thanks to Perry Gibson, Candle Corporation, USA.
Change 15.002 Variable TERMIND was added to the _PDB30_4 macro so it is
IMACPDB now kept in PDB.STEPS, as enhancement for ABEND decoding,
Feb 27, 1997 in case of multiple bits.
Thanks to Dan Adams, Facilities Systems Office (FACSO), USN, USA.
Change 15.001 File counts were not properly decoded in TYPETMON, and
TYPETMON one MXG 14.14 change made it worse! The statement
Feb 22, 1997 FILECOL=TAFATOFF+6+LOC-LENMONI; must be changed to
FILECOL=TAFATOFF+1;
In addition, MXG 14.14 added a block of code
LOC=COL; INPUT SYSID .... SYSTEM $EBCDIC4 @LOC @;
but both "LOC"s must be changed to "TLOC".
Thanks to Bob Hall, USA Group, USA.
LASTCHANGE: Version 15
=========================member=CHANGE14================================
/* COPYRIGHT (C) 1984-1997 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is MXG Version 14.14 is dated Feb 21, 1997, thru Change 14.352.
Newsletter THIRTY-ONE was dated Feb 21, 1997, thru Change 14.343
2nd MXG Version 14.11 was dated Feb 4, 1997, thru Change 14.324
1st MXG Version 14.11 was dated Feb 3, 1997, thru Change 14.323
MXG Version 14.10 was dated Jan 10, 1997, thru Change 14.299
MXG Version 14.09 was dated Dec 17, 1996, thru Change 14.295
MXG Version 14.08A was dated Nov 18, 1996, thru Change 14.275
MXG Version 14.08 was dated Nov 13, 1996, thru Change 14.271
MXG Version 14.07 was dated Sep 11, 1996, thru Change 14.221
Newsletter THIRTY was dated Sep 10, 1996, thru Change 14.209
early MXG Version 14.07 was dated Sep 10, 1996, thru Change 14.209
MXG Version 14.06 was dated Aug 20, 1996, thru Change 14.191
MXG Version 14.05 was dated Jul 15, 1996, thru Change 14.160
MXG Version 14.04 was dated Jun 13, 1996, thru Change 14.132
MXG Version 14.03 was dated May 27, 1996, thru Change 14.114
MXG Version 14.02 was dated Apr 25, 1996, thru Change 14.096
MXG Version 14.01 was dated Mar 7, 1996, thru Change 14.051
MXG Version 13.13 was dated Jan 20, 1996, thru Change 13.332
Newsletter TWENTY-NINE, dtd Jan 20, 1995, thru Change 13.323
Contents of member CHANGES:
0. Table of contents of NEWSLETTER THIRTY-ONE (see member NEWSLTRS).
I. MXG Software Version 14.14 Status.
1. Announcing email, WWW.MXG.COM home page, and MXG-L LISTSERV.
2. MXG Software Version 14.14, dated Feb 21, 1997, was shipped.
3. What products are not yet supported?
II.-X. Technical Notes are in Newsletter THIRTY-ONE.
IX. Incompatibilities and Installation of MXG 14.14.
X. Online Documentation of MXG Software.
XI. Changes Log
0. Table of contents of 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 Softwar
Version and Newsletter shipment sent in First Quarter, and the Summe
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 Version 1 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,OW25262 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.
Petabytes 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 Jul 4, 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 in development (although Landmark still has not been
able to provide documentaion, users have!) and may be partially
complete in the actual MXG 14.14 version.
b. Landmark's The Monitor for CICS/ESA Version 2 will be relased this
spring, but the documentation and test data had not yet arrived.
c. Enhancements to ASMRMFV (work on ASMTAPES ML 12 pre-empted) are
now hoped for second quarter.
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!
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):
IMACCIMS - For Boole & Babbage IMF - See Change 14.152.
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.
- 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, Enhancements.
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 2955+ 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 between MXG 13.13 and MXG 14.14:
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.
ANALDSET 14.064 Using Tape instead of DASD for ANALDSET fails.
ANALDB2R 14.340 DB2 4.1 Reporting for Buffer Pools and Packages.
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!
ASMTAPES 14.351 ML 12 of MXGTMNT included in MXG 14.14.
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 New ASUMUOW for CICS MRO and DB2 Unit of Work merge.
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.
CICINTRV 14.352 Revised "CICINTRZ" logic now replaced CICINTRV.
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. (1000 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.
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.349 Support for Demand Technology's Stress Test 3.3.6.
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 records with only DRU 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:
NEXTCHANGE: Version 14
===Changes thru 14.352 were included in MXG 14.14 dated Feb 21, 1997===
Change 14.352 Member CICINTRV is now the enhanced logic that was first
CICINTRV tested as "CICINTRZ". The new logic creates only the
Feb 20, 1997 PDB.CICINTRV data set with CICS interval statistics.
The other four old datasets, CICEODRV,CICREQRV,CICRRTRV
and CICUSSRV should have been deleted, as they are now
meaningless, but they are still created (but now with no
observations) to prevent unnecessary failure if any of
your other jobs reference those datasets (in your weekly
or monthly, for example, if they were copied). Take the
time to remove any references to those now defunct data
sets to avoid future errors when they are deleted.
Change 14.351 ML 12 of the MXG Tape Mount and Tape Allocation Monitor
ASMTAPES MUST be installed for MVS/ESA 5.2.2 or OS/390 to avoid
ZSMTAPES possible UCB errors (due to relocated UCBE in MVS). Not
ZZMTAPES only does this revision solve that problem, it builds on
Feb 20, 1997 ML 11 (which replaced SRB with Cross Memory Services) and
Good News:
-Creates new TMNTTYPE=5 "Interval Allocation" record that
is written at the end of each (default=hour) interval for
each drive that was allocated. This will allow us in the
analysis programs to accurately count tape drives without
having to wait (days or weeks?) until the tape drive was
deallocated.
-Supports the workload manager, with new data elements
for Service class, workload name, resource group, and
resource class.
Bad News:
MXG 14.14 VMACTMNT processing code does not decode the
new fields, nor the subtype 5 record; that enhancement
should be available in early April.
Other News:
-Has new assembly time operating system parameter that you
must supply. The values are ESA or ESA5. ESA5 supports
MVS/ESA Version 5 and OS/390 and must be specified so the
correct IBM macros are used.
-Supports the new access to the UCB common extension.
-Changed SRB error fields to AR mode error fields.
-Corrected MODESET errors in AR mode.
-Changed initial tape UCBSCAN into subroutines.
-Support for above the line UCB's.
For archive, ML 9 is now in ZZMTAPES, and ML 11 is in
ZSMTAPES member.
Change 14.350 Dataset TYPE74CA was not created in the WEEKly PDB if
WEEKBLDT you used WEEKBLDT (but was with WEEKBLD). Now it is
Feb 20, 1997 created with either weekly job.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.349 Support for Stress Test Release 3.3.6 Enhancements.
VMACSTRS Both the original and the enhanced SMF record is now
Feb 20, 1997 supported transparently. This release adds new data
to the SMF record that will soon allow control cards
for Stress Test parameters to be created to match your
existing DASD rates (by using TYPE74 and TYPE74CA SMF
data to measure your system). That analysis/generator
should be available in April.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.348 Variable JOBCLASS was increased to LENGTH $8 (from $1)
VMAC30 in VMAC30 and VMAC26J3 because JES3 needs all eight
VMAC26J3 bytes for JES3 Main Class. Only one byte is input in
Feb 19, 1997 VMAC26J3, but by increasing the length in TYPE26J3 will
May 21, 1997 cause the kept size in BUILDPD3 to be eight bytes. What
is really slick is that the length of JOBCLASS in the
JES2 PDB.JOBS and PDB.STEPS datasets will still be only
one byte, so there is no increase in the size of the JES2
PDB as a result of this change to type 30. However, the
TYPE30_x datasets will have JOBCLASS with length 8 to
support either JES2 or JES3 job class names.
Thanks to Jack Mintz, Hudson Williams, USA.
Change 14.347 Continued enhancements to the RMF-like reporting.
ANALRMFR -ANALRMFR now detects and reads PDB on tape or disk.
Feb 19, 1997 -Workload Activity Report-Compatability Mode,
REPORT=WKLD, RPTOPT parameter is now the way
to make report selections. If none are selected
no reports are created.
RPTOUT=PERIOD Performance group period
within performance group.
GROUP Summarizes data for all performance
group periods within the
performance group.
DOMAIN Summarizes data by domain for the
entire system.
STM Summarizes data for the entire
system.
-Workload Activity Report-Goal Mode, REPORT=WLMGL
RPTOPT=WGPER:
Update Sevice Policy Page column Resource Groups
allowing for all service classes to be output.
-Workload Activity Report-Goal Mode, REPORT=WLMGL
RPTOPT=RCLASS, report classes defined in a service
policy, is added.
-Workload Activity Report-Goal Mode, REPORT=WLMGL
RPTOPT=SCLASS, summary of data for all service class
periods defined for a service class, is added.
There was no data to confirm values.
-Coupling Facility Activity, REPORT=CF
Reports created "Coupling Facility Usage Summary"/
"Structure Summary"/"Storage Summary"/"Processor
Summary" and "Coupling Facility Structure Activity"
Unconfirmed values a ouput on the report as "??".
-LCU summary does not include the first device.
Remove LCUIORAT=0 ....... from FIRST.DATE OR
FIRST.TIME OR FIRST.DEVCLASS.
Move LCUIORAT=SUM(LCUIORAT,IORATE)
.
To after FIRST.LCU THEN DO;
Thanks to David Childress, Lowe, USA.
Thanks to Alan M. Sherkow, Management Strategies LTD.
Change 14.346 Variables NRBINDS and NRLIMITS should have been spellec
VMACTPM NBINDS and NLIMITS, and variable JCTJOBID was added to
Feb 17, 1997 the KEEP= list for dataset TYPETPMF.
Thanks to Brian Sanga, Eagle Star Group Services Ltd, ENGLAND.
Change 14.345 The FMXGUCBL function (to allocate dynamically all DASD
FMXGUCBL devices for the archaic VMACVTOC) did not support four
Feb 17, 1997 digit UCBs, but now does, thanks to this contribution.
Thanks to Sue Yarker, Midland Bank, ENGLAND.
Change 14.344 "IHDR" exit for Boole and Babbage IMF records was added,
IHDRCIMS after newsletter text was sent to the printer. See text
VMACCIMS of Change 14.342.
Feb 17, 1997
===Changes thru 14.343 were printed in MXG Newsletter THIRTY-ONE=======
Change 14.343 New ASUMUOW summarizes CICSTRAN and DB2ACCT by "Unit of
IMACUOW Work UOW" to create PDB.ASUMUOW with total CICS and DB2
ASUMUOW resources in a single observation, keeping the original
Feb 19, 1997 TRANNAME and USERID of the real UOW. Member IMACUOW will
May 4, 1997 enable "SPINing" of incomplete CICS transactions (e.g.,
long running LU 6.2 events) to ensure completeness. This
member is a replacement/enhancement of ANALDB2C that is
renamed to an ASUMxxxx because it is now designed to be
executed as a data-set-builder (PDB.ASUMUOW) rather than
an ANALysis example (and UOW makes more sense than DB2C)!
The main assumption is that the earliest transaction for
any UOW must be the first transaction; during the merge,
if the TRANNAME of the first transaction is CSMI (i.e.,
an MRO mirror) or is blank (DB2), that transaction is
not complete, and the current records are SPUN (written
to the SPIN library to be held until the next run, if you
updated macro _SPINUOW in member IMACUOW to non-zero).
The ASUMUOW dataset contains the same CICS variables as
are needed to create the ASUMCICS interval summary from
detail CICS transactions (plus the DB2 variables for CICS
transactions calling DB2), so the ASUMUOW dataset could
be used as input to ASUMCICS (you would probably want to
make your own enhanced copy that also keeps the DB2
variables) so as to create interval UOW statistics. In a
test of 2.6 million tran obs in CICSTRAN, ASUMUOW had
only 1 million obs. ASUMUOW can be used even if only
CICSTRAN data exists, as it will combine all MRO events
into one observation per UOW.
Text revised May, and November, 1997.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.342 "IHDR" exits (taken after the header of raw records have
IHDRTMON been read in) are added for Landmark's Monitor for
IHDRTMDB CICS/ESA and for Landmark's Monitor for DB2. These
IMACMONI "IHDR" exits are similar to the "IMACFILE" exit for SMF
IMACTMDB (which should be named IHDRSMF by my new naming
TYPETMON convention).
VMACTMDB
Feb 15, 1997
Change 14.341 Using EXTMSTMS and macro _KTMSTMS in IMACTMS5 to create
TYPETMS5 new variables did not work as expected. The new
Feb 15, 1997 variables were added to the initial TMSTMS dataset, but
post processing in TYPETMS5 did not include the _KTMSTMS
macro reference, so the new variable was lost. The
_KTMSTMS and _KTMSDSN references were added.
Thanks to Andy Chandler, Eagle Star, ENGLAND.
Change 14.340 DB2 Reporting Enhancements for DB2-PM like reports from
ANALDB2R DB2 4.1. Individual Buffer Pool and Individual Package
ASUMDB2A Execution data is now reported (See DB2 Technical Note in
ASUMDB2P Newsletter THIRTY-ONE). The Account Detail and Long
TRNDDB2A Trace reports now use the detail buffer and package data
TRNDDB2P (DB2ACCTB and DB2ACCTP) if they exeist. The default
Feb 15, 1997 assumption is that all of your DB2 datasets are in the
PDB libref, but if you have used IMACDB2 to send them
to different librefs, you can tell ANALDB2R where to find
them with the new DB2ACCT=, DB2ACCTB=, and DB2ACCTP=
arguments in your ANALDB2R invocation.
This change is incompatible with prior versions of the
ANALDB2R report in that only a single PDB will be used
to generate the report. (Previously, you could specify
PDB=PDB1 PDB2 PDB3, and the libraries would have been
"concatenated". This restructure lost that capability
but you can easily combine multiple PDB datasets first
and then invoke ANALDB2R.)
Most, but not all, of the DB2 4.1 fields have been
added; in particular, the individual buffer and package
sections are complete.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.339 User enhancements to the ASMIMSLG/ASMIMSL5 programs for
ASMIMSLG IMS log processing protect for a short error message,
ASMIMSL5 and in case of MSC transactions, since the ARRVTIME may
Feb 14, 1997 be wrong (out of sync), now, the MSC timestamp is used
for ARRVTIME with good results.
Thanks to Harry Olschewski, dvg Hannover, GERMANY.
Change 14.338 Variable HIUICAV (TYPE71) was added to RMFINTRV dataset
RMFINTRV (the maximum of the individual values is kept) and it is
TRNDRMFI added to TRNDRMFI dataset (the average of the maximum is
Feb 15, 1997 kept).
Thanks to Manfred Thomas, BHF-Bank, GERMANY.
Change 14.337 Candle's EPILOG for MVS decoding was enhanced. The IO
ANALEPMV and ENQ data is now rolled into the EPMVEP dataset. The
VMACEPMV derivation of results to match Epilog screen reports that
Feb 14, 1997 doing straight-forward arithmetic with sample counts did
not resemble their (proprietary) calculations but
diligent work by Simon is now available in the ANALEPMV
member to do those calculations for reports. mon P.
Thanks to SiMundy, Telstra, AUSTRALIA.
Change 14.336 Support for Landmark's The Monitor for CICS/ESA 1.5 is
TYPETMON already in MXG, as the only change in the records is the
Feb 14, 1997 version (LMRKVREL) contains 0Fx rather than 0Ax. Their
Version 2 product is due out this year, but that will
require changes to MXG to support. Stay tuned.
Change 14.335 Support for NPM APAR OW17875 added new NPMSUBTY=2Ax that
VMAC28 is now decoded and output in the existing NPMSUMRY data
Feb 14, 1997 set. Subtype 2Ax allows the collection and reporting of
session data summarized by LU Group; the value of
SCDSPLUG (LU Group summarized) is stored in existing MXG
variable SCDSPNAM, rather than creating a new variable.
Change 14.334 Segmented TSO/MON records containing only DRU segments
VMACTSOM have missing STRTTIME in TSOMDRU dataset because MXG did
Feb 13, 1997 not protect for DRU-only TSO/MON records, but now does.
Thanks to Rick Ireland, Imperial Oil Limited, CANADA.
Change 14.333 NTSMF datasets ICMP, TCP, and UDP have been validated
ADOCNTSM with data records and the table in ADOCNTSM updated.
Feb 13, 1997
Thanks to Richard Clary, ENTERGY, USA.
Change 14.332 New member PROCSRCE is "Proc Source" for ASCII SAS. It
PROCSRCE creates a single IEBUPDTE-format file from individual
Feb 13, 1997 files, so that only a single file upload or download is
required to move MXG Source library between ASCII and
OS/390 platforms. See instructions in member PROCSRCE.
The basic technique is to pipe the DIR command's output
DIR *.SAS >> NAMEFILE.MXG /B /ON
to create a list of file names in NAMEFILE.MXG, then
start SAS and submit %INCLUDE SOURCLIB(PROCSRCE); which
reads NAMEFILE and copies each file into IEBUPDTE.MXG,
inserting the ./ ADD NAME=xxxxxxxx statements.
Ain't elegant, but it is how I build the IEBUPDTE.MXG
master file that is copied to 3480 distribution tapes.
The actual file on 3480 tape is about 75MB (because each
record is exactly 80 bytes long) but on ASCII takes only
about 40MB (variable length records with trailing blanks
removed), and it PKZIPs to less than 9MB. To upload MXG
for OS/390 validation, the 9MB IEBUPDTE.ZIP is sent via
IND$FILE across SDLC at 19.2KB, and on MVS is unzipped by
PKZIP for MVS (from ASI, 513-885-2031). With PKZIPing,
transmission takes 90 minutes. Unzipped, transmission
takes 7 hours!
The existing MXG member IEBUPDTE is the inverse of the
PROCSRCE program, as it reads PROCSRCE's output file to
create each member as a separate *.SAS file.
Change 14.331 NETSPY record 'N' might cause INPUT STATEMENT EXCEEDED;
VMACNSPY the +15 and +29 after the INPUT of NSPSTAFL should be
Feb 13, 1997 +16. No error was directly reported, but this might be
why one European site claimed they had to change the DO
interation's maximum value (reduced by one) to avoid an
ABEND (but I never got a record dump for diagnosis!).
Thanks to Carl Downing, BlueCross BlueShield of Minnesota, USA.
Change 14.330 Amdahl APAF Version 3.0 records have been validated with
VMACAPAF data records. Changed test for SUBTYPE=31 or =32 to be
Feb 13, 1997 =49 or =50 (Amdahl listed subtypes in hex not decimal!),
and corrected algorithm for counting bits on in a field
(see SAS Technical Note in Newsletter THIRTY-ONE).
Thanks to Bob Gauthier, American Stores Company, USA.
Change 14.329 SYNCSORT's product COBOL Advantage populates one byte in
VMACSYNC the SYNCSORT user SMF record. New variable SOOPCAT in
Feb 11, 1997 dataset TYPESYNC contains that byte, formatted in hex.
Thanks to Jim Ray, Branch Banking & Trust, USA.
Change 14.328 TYPE74CF (Coupling Facility) QSIZnn variables are the
VMAC74 structure size as specified in the CFRM in units of 4096
Feb 10, 1997 bytes per unit, while TYPE74ST (Structures) R744SSIZ
(and SMAS/SMIS) variables are actual allocated size of
the structure, in units of 4000 bytes per unit, but IBM
did not document the use of 4000 vice 4096. To properly
size the allocations, MXG now multiplies SSIZ/SMAS/SMIS
by 4000 instead of 4096 (and SSIZ will then be smaller
than QSIZ values).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.327 Variable I was incorrectly used as the index variable
VMAC102 for two nested loops, which caused VMAC102 to loop.
Feb 7, 1997 There are two places, in the QWHSIID=21 and QWHSIID=44
processing that contain DO I= 1 TO 19 BY 3; In that
line, in the two following lines (...PUT(SUBSTR...
and in the line IF I=19 AND J=7 THEN J=20, change the
"I" to "L" to correct the error.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 14.326 MXG 14.11 only. Data set TYPE42S2 had incorrect values
VMAC42 because "NEW" before SMF42FB2/SMF42FB3 was not removed.
Feb 6, 1997 Labels for variables SMFJOD01-SMFJOD16 were corrected.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.325 MXG 14.11 only. Array CFNUM should only have sixteen
VMAC74 elements CFNUM01-CFNUM16 but was accidentally changed to
Feb 6, 1997 CFNUM01-CFNUM64. Had no actual impact.
Thanks to Bruce Widlund, Merrill Consultants, USA.
===Changes thru 14.324 were included in MXG 14.11 dated Feb 4, 1997===
Change 14.324 INVALID RECORD OBJECT=NETWORK INTERFACE error message
VMACNTSM because the test ... OFFDATA NE 20 ... should be NE 21
Feb 4, 1997 (this test is right after the test for
IF UPCASE(OBJECT)='NETWORK INTERFACE' THEN DO;
Thanks to Richard Clary, ENTERGY, USA.
Change 14.323 MXG 14.11 dated Feb 3, 1997 only. Type 102 subtype 100
VMAC102 ERROR: NO MATCHING IF-THEN CLAUSE because the two lines
Feb 4, 1997 QW0100SB=QW0100SB+GMTOFFDB;
QW0100SA=QW0100SA+GMTOFFDB;
were mis-located. They must be immediately before the
OUTPUT T102S100;
statement.
Fortunately, the 100 subtype is not used in ANALDB2R or
any other MXG program, so only specific use of T102S100
exposed the error (my QA caught it but I overlooked it).
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
===Changes thru 14.322 were included in MXG 14.11 dated Feb 3, 1997===
Change 14.322 This is ML11 of the Tape Mount/Allocation monitor.
ASMTAPES This revision eliminates the use of an SRB to capture
ZSMTAPES job-related info, and instead does all of the cross
Feb 3, 1997 memory data collection in AR (access register) mode.
Running in AR mode will cause more recorded CPU time in
the TMNT address space, but what is really happening is
that all of our collection overhead is now captured in
the (calling) TMNT address space, whereas previously some
of the CPU time of the SRB's execution was recorded in
the SMF records of the allocating (monitored) address
space. The previous revision ML9 is in member ZSMTAPES.
ML12 will contain 3 improvements : workload manager
support, UCB common extension access changes, and
configuration change detection using ENF, and will be
available later this year.
Change 14.321 Don Deese's continued research into measurement of the CF
VMAC74 caused me to create new variables R744QSIZ and R744QFLG
Feb 3, 1997 from the QO segment into the SO per-structure segment
so QSIZ/QFLG are added to TYPE74ST (while we investigate
why QSIZ is often very difference thatn R744SSIZ!).
The structures names in QO and SO are not in the same
order, so MXG scans across the QO entries to find the
matching SO entry.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.320 As will be discussed in the next newsletter, this is the
DOC first MXG Version (14.11) to be built at our office on
Jan 31, 1997 my new Overland 3480/3480IDRC/3490/3490E tape drive.
The EBCDIC to ASCII translation with IND$FILE is not the
same as the Overland default, and the Overland default is
also wrong (especially trashing the long-vertical-bar and
the not-sign), so I had to build my own translate table
to create EBCDIC tapes from my ASCII master file:
MXG IND$FILE MXG WRONG MXG OUTPUT
ON OUTPUT ON ON EBCDIC W/
MVS ON ASCII ASCII OVERLAND My Table
cent-sign 4A 5B same AD l. Sq. Bracket
not-sign 5F 5E AA caret
long vertial 4F 5D B3 BD r. sq. bracket
split vert 6A 7C same 4F split vert bar
(Note that in NEWSLETTER THIRTY-ONE 'A9'x was erroneously
typed for a not-sign on ASCII, but it is really 'AA'x).
I found I also had to change Overland's (DataTools for
Windows) default ASCII-to-EBCDIC table three errors
5D-->4F and not BD 5B-->4A and not AD
7C-->6A and not 4F
plus my two additions
AA-->5F B3-->4F
To correct symbols on your ASCII platform after you use
IND$FILE to download, change all '5D'x to 'B3'x and all
'5E'x to 'AA'x and your comments with vertical bars
and non-signs will look correct. Of course, before you
could upload that ASCII MXG to EBCDIC with IND$FILE, you
must reverse that change on ASCII before the upload.
I took this opportunity to rid "not-signs" from all MXG
code, using NE or NOT instead, and replaced all of the
remaining instances of double long-vertical-bars (for
concatenation) with double exclamation points, to
minimize any future exposure if MXG source is moved from
ASCII to EBCDIC, and removed all of the '4A'x extraneous
characters in text members.
However, there were some uses of single long vertical
bars that were inside comments and too pretty to lose,
and a few instances of "not sign" (suggesting not to use
it) that were left. These members were revised:
ACHAP08 ACHAP09 ACHAP12 ACHAP13 ACHAP16 ACHAP16
ACHAP17 ACHAP18 ACHAP19 ACHAP19 ACHAP21 ACHAP22
ACHAP23 ACHAP26 ACHAP30 ACHAP32 ACHAP33 ACHAP34
ACHAP37 ACHAP38 ACHAP39 ADOCEREP ADOCVMXA ADOC1415
ADOC7072 ANALCACH ANALCTLD ANALIPAC ANALRACF ANALRRTM
ANALSNAP ANALVARY ANALVMOS ANALVVDS IDMSBLT IDMSJANL
IDMSJRNL JCLCRAYC LOADINFO REXXCOPY REXXEMAC REXXPDB
REXXTEST SYSLOGJE TTXPDS TYPEIMS UTILFMTX UTILPRNL
UTILSPAC UTILXRF1 VMACIPAC VMACRRTM VMAC102 VMXGHSM
XIBMFDP XLOGREC XNALCACH XNPMSESS XTYPEVS1 ZNALDB2R
ZRBIPSJ
MXG is now distributed as an unnumbered data set; columns
73 thru 80 are blank in all records on the MXG tape.
I have not used line numbers for references for several
years, and eliminating line numbers makes the source
library much smaller on ASCII.
Change 14.319 LPAR data now contains flag variable LPnCAP to indicate
ASUM70PR which partitions are Capped, and variable LPnSHARE which
Jan 31, 1997 contains the partitions percentage of the sum of the LP
share values (i.e., if the partition is Capped, then
LPnSHARE is the capping percentage).
Thanks to Ian Porter, Nissan European Data Center, SCOTLAND.
Change 14.318 Support for OS/390 Release 3 (Compatible) adds major new
VMAC7072 measures to the TYPE72 and TYPE72GO datasets; the first
Jan 30, 1997 five variables were added to both (i.e., COMPATIBILITY
MODE in TYPE72 and WORKLOAD MANAGER in TYPE72GO):
R723CICT='NON-PAGING*DASD I/O/CONNECT*TIME'
R723CIDT='NON-PAGING*DASD*DISCONNECT*TIME'
R723CIWT='NON-PAGING*DASD I/O*WAIT*TIME'
R732CIRC='NON-PAGING*DASD I/O*SSCH COUNT'
R723VELI='EXECUTION*VELOCITY*INCLUDES*I/O DELAY?'
and only in WORKLOAD MANAGER do we find:
PCTDLIOD='DASD*DELAY*SAMPLES'
PCTDLNDI='NON-DASD*I/O USIN/DELAY*SAMPLES'
PCTDLQ ='QUEUE*DELAY*SAMPLES*WAIT FOR*SERVER'
PCTDLSHS='SERVER*HIPERSPACE*PAGING*DELAY'
PCTDLSMP='SERVER*MPL*DELAY*SAMPLES'
PCTDLSPV='SERVER*PRIVATE AREA*PAGING DELAY'
PCTDLSSW='SERVER*SWAP-IN*DELAY*SAMPLES'
PCTDLSVI='SERVER*SPACE VIO*PAGING*DELAY'
PCTUSIOU='TOTAL*USING I/O*SAMPLES'
PCTUSTOU='TOTAL*USING*SAMPLES'
The calculation of VELOCITY is also changed in Release 3,
as PCTUSTOU (R723CTOU) replaces PCTUSCUS (R723CCUS) in
the numerator and variable R723VELI='Y to indicate that
the exection velocity now includes I/O delays.
Change 14.317 Dataset DB2ACCTP (Package Accounting) has new variables
VMACDB2 QWACBSC and QWACESC (start/stop of plan) added to KEEP=
Jan 30, 1997 list because they appear on DB2PM reports, and because
Oct 13, 2003 variable QPACSCB (start of package) cannot be used, as
it is null in the 2nd and subsequent segments of the
type 101 subtype 0 (accounting record, holds first ten
package statistics), and QPACSCB is nulls in ALL of the
type 101 subtype 1 (package only) records, and finally
because the subtype 1 record is written first (so I can
not retain from the subtype 0!).
Update: October 13, 2003: QPACSCB and QPACSCE appear
to always exist, now, in DB2ACCTP observations, both
from Subtype=0 (first 10 packages), and from Subtype=1
(more than 10 packages).
However, QWACBSC and QWACESC will always have missing
value in DB2ACCTP observations from subtype=1 because
that record does not contain the QWAC segment!
This 2003 note is only for documentation.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.316 Subtype 5 HMF record with only 1 segment caused INPUT
VMACHMF STATEMENT EXCEEDED error. Although undocumented, this
Jan 29, 1997 record had only the bus segment; there was no memory
segment present. To correct, insert after the @; that
is after the INPUT of HMF5BUS:
IF HMF5SEGS EQ 2 THEN DO;
and after the following IF SKIP GT 0 THEN INPUT +SKIP @;
insert END;
(so that only the bus stats are read when HMFSEGS=1).
Thanks to Ann Knapik, ISSC Akron, USA.
Change 14.315 DB2 utility programs set QWHCATYP=41 as their attachment
FORMATS type value, an undocumented value that IBM does not set.
Jan 28, 1997 The site is pursuing IBM for a better answer.
Thanks to Roman Jost, Gjensidigo, NORWAY.
Change 14.314 Dataset MEMOACCT new variables ENTRCALE/ENTRFORM are now
EXTYMEMO INPUT from previously reserved fields. In addition, the
VMACMEMO MEMOACCT dataset contains variable CURRMODE with values
Jan 28, 1997 of T - terminate session or C - continuation, the latter
having accumulated values, so in most cases you only want
the type T, so in member EXTYMEMO I have added an example
of the code IF CURRMODE='T' THEN OUTPUT _LTYMEMO; that
would cause only type T obs to be output, but that sample
code in EXTYMEMO is commented out by default, so MXG will
create both C and T observations until you change it.
Thanks to Roman Jost, Gjensidigo, NORWAY.
Change 14.313 Invalid type 80 RACF record caused INPUT STATEMENT EXCEED
VMAC80A error. The record, an RACFEVNT=21:RDEFINE has pairs of
Jan 28, 1997 (SMF80DTP,SMF80DLN) (data type, data length, in decimal)
of (6,151),(12,12),(81,08),(0,21),(6,8), then 543 (24,12)
segments, a (49,20) and a (53,80). The first DTP=6 is
the expected 151 bytes, but there is a later DTP=6 with
unexpected length of 8. The DTP=12 is 12 bytes instead of
the documented multiple of 9. There are no DTP= 0 or 81
values documented by IBM. And inside the DTP=12 data
segment, the characters do not conform with the expected
format, so this record was partially hosed, but still by
adding protection for these (invalid) unexpected lengths
in the DTP= 6 & 12, and for the unexpected DTP= 0 & 81,
the rest of the type 80 records can be read while IBM is
contacted to find a fix to prevent the bad record.
Thanks to Silva Viviani. Fondo Commune D.C. Rurali Trentine, ITALY.
Change 14.312 IMF flag variables in the DBD section were not reset for
VMACCIMS the next DBD segment, and thus were incorrectly carried
Jan 28, 1997 forward. ELSE variable=' '; clauses were added for the
variables: DBTOVFLW DBTMSCNT DBTTYDDN DBTTYOTH DBTTYSEC
DBTVSAM and DBTOSSB
Thanks to Sieghart Seith, FICUCIA, GERMANY.
Change 14.311 MXG now converts GMT timestamps in DB2 records to local
EXDB2ACC time automatically, but this change is INCOMPATIBLE for:
VMACDB2 sites that already use member EXDB2ACC to change GMT to
VMACDB2H local for variables QWHCBSC and QWHCESC (which was the
VMAC102 MXG recommendation prior to this change!). For those
Jan 27, 1997 sites, you must remove your conversion code and let MXG
convert those and all DB2 timestamps for you.
The revised algorithm detects not only the hours of delta
time between SMFTIME (local) and THISSTCK (GMT), but also
now detects the seconds of delta time (values of 20
seconds were seen, which is about the current number of
leap seconds that is included in the STCK value in
SYSPLEX environments, but leap seconds are not included
in SMFTIME values). The value of the GMT Offset,
GMTOFFDB, may not be exact hours. We found a THISSTCK
value of 16:00:20 and SMFTIME was 10:00:00 so GMTOFFDB
was -06:00:20! Without those extra 20 seconds in the
GMT offset, the converted local times would be off by 20
seconds, so don't disbelieve a GMT offset that is not
exact hours. I arbitrarily set any difference less
than 10 seconds to zero, even though current measurements
show a maximum real fuzziness of less than 0.12 seconds,
because I expect delta seconds to be due to leap seconds
and the value of 10 might cover pathological cases when
SMFTIME was delayed. The new algorithm to calculate the
GMT offset, GMTOFFDB, which is used in VMACDB2 & VMAC102
members, is contained in VMACDB2H:
DELTASMF=SMFTIME-THISSTCK;
GMTOFFHR=(100*FLOOR((DELTASMF+30)/100))/3600;
GMTOFFSC=DELTASMF-3600*GMTOFFHR;
IF ABS(GMTOFFSC) GT 10 THEN
GMTOFFDB=3600*GMTOFFHR+GMTOFFSC;
ELSE GMTOFFDB=3600*GMTOFFHR;
Thanks to Chuck Hopf, MBNA, USA.
Change 14.310 -Dataset PDB.DB2GBPST (Global Buffer Pool Interval Stats)
DIFFDB2 contained accumulated (and hence useless) values, but it
VMACDB2 is now deaccumulated to contain valid interval data by
Jan 27, 1997 its support in member DIFFDB2.
-Dataset PDB.DB2STAT1 and PDB.DB2STATS variable QBGLGN
should never have been kept; it is the Group Buffer Pool
ID in each of the segments, and is kept only in the
detail PDB.DB2GBPST dataset.
Thanks to Ermanno Bertolotti, Banca Commerciale Italiana
Thansk to Daniela Busani, Banca Commerciale Italiana
Change 14.309 Support for additional variables in type 42 subtypes 15,
EXTY42X1 16, 17, 18, and new subtype 19 creates new MXG dataset:
VMAC42 TYPE42X1 - VSAM RLS Local Buffer Manager counters.
Jan 25, 1997 See notes in member ADOC42 for details.
Thanks to Michael E. Friske, Fidelity Systems, USA.
Change 14.308 Support for NTSMF Beta added new records, support for NT
VMACNTSM 3.51, and graceful detection of new record types. Have
Jan 25, 1997 tested 34 record types, of the 56 known records. See the
status and complete technical discussion in ADOCNTSM.
Change 14.307 Support for APAF v3.0 added new Millennium subtype 31 and
EXAPAFCB 32 records which create three new APAF datasets:
EXAPAFLP Dataset Subtype Description
EXAPAFSY APAFSYSD 31 Global system data
IMACAPAF APAFLPAR 32 LPAR and Physical CPU data
VMACAPAF APAFCHN 32 Channel data
Jan 25, 1997 Member IMACAPAF was incompatibly changed (because of the
Jan 30, 1997 creation of new datasets) and must be refreshed in your
USERID.SOURCLIB tailoring library.
The new subtype 31 contains only the "Physical" partition
times, while the subtype 32 contains the Total Dispatch
and Effective Dispatch, from which LPAR Management Time
is calculated for the Millennium processors.
Thanks to Bob Gauthier, American Stores Company, USA.
Change 14.306 Variable QBACHRF was added to the SUM= list of variables
ASUMDB2B to be summarized in creation of ASUMDB2B.
Jan 21, 1996
Change 14.305 Year 2000 status was updated. Revised format now shows
YEAR2000 ongoing list of vendor fixes which are required for those
Jan 17, 1996 products that did not support 2000 but now do.
Change 14.304 MXG 14.05-MXG 14.10 only, using the supplied MXGSAS JCL.
MXGSAS Error 180-322, right after the NOTE: THE INITIALIZATION
Jan 17, 1996 PHASE USED 0.13 CPU SECONDS AND 2233K results because the
default value for the TAILORNG symbolic parameter in the
MXGSAS JCL Procedure was still wrong in MXG 14.10. The
error was supposedly fixed by Change 14.239, but that fix
was not implemented in the MXGSAS member until now. The
default TAILORNG symbolic in MXGSAS must be:
TAILORNG='*.NULLPDS,VOL=REF=*.NULLPDS',
Thanks to Ram V. Ramamurthy, Associates Corporation, USA.
Change 14.303 NJE devices with INDEVICE or DEVNAME of LnnnnJRm instead
VMAC26J2 of the (old) expected style of Lnnn.JRm caused INREASON
Jan 17, 1997 to be blank (instead of SR/JR/JT), so these NJE purge
Jan 21, 1997 records were not recognized and were kept as real purge
records in BUILDPDB, causing some fields (like JENDTIME)
to be taken from the wrong purge record. The MXG logic
to create INREASON was revised to recognize the old and
new style of INDEVICE and DEVNAME:
DOTLOC=INDEX(INDEVICE,'.');/*CHECK INDEVICE, 'JR' OR 'SR'*/
IF DOTLOC NE 0 THEN DO;
DOTLOC=DOTLOC+1;
INREASON=SUBSTR(INDEVICE,DOTLOC,2);
IF (INREASON='JR' OR INREASON='SR') AND ORIGNODE GT ' ' THEN
SOURCE=ORIGNODE;
ELSE INREASON=' ';
END;
ELSE IF INDEVICE=:'L' AND '0001' LE SUBSTR(INDEVICE,2,4) LE '9999'
THEN DO; /* FORMAT LnnnnSRm DOES NOT CONTAIN A DOT */
INREASON=SUBSTR(INDEVICE,6,2);
IF (INREASON='JR' OR INREASON='SR') AND ORIGNODE GT ' ' THEN
SOURCE=ORIGNODE;
ELSE INREASON=' ';
END;
IF INREASON=' ' THEN DO;/*IF STILL BLANK, THEN CHECK DEVNAME*/
DOTLOC=INDEX(DEVNAME,'.'); /* 'JT' */
IF DOTLOC NE 0 THEN DO;
DOTLOC=DOTLOC+1;
INREASON=SUBSTR(INDEVICE,DOTLOC,2);
IF INREASON='JT' AND ORIGNODE GT ' ' THEN SOURCE=ORIGNODE;
ELSE INREASON=' ';
END;
ELSE IF DEVNAME=:'L' AND '0001' LE SUBSTR(DEVNAME,2,4) LE '9999'
THEN DO; /* FORMAT LnnnnSRm DOES NOT CONTAIN A DOT */
INREASON=SUBSTR(DEVNAME,6,2);
IF INREASON='JT' AND ORIGNODE GT ' ' THEN SOURCE=ORIGNODE;
ELSE INREASON=' ';
END;
END;
Thanks to Silvio Orsini, Banca D'Italia, ITALY.
Change 14.302 The 22 new Shared Paging variables in TYPE71 starting
VMAC71 with SHPBINAU and thru SHPGLOAV need to be INPUT as
Jan 17, 1997 &RB.8. instead of &RB.4. This corrects Change 14.257.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.301 MXG 14.07-MXG 14.10 only, JES3 only, and only if you use
BUIL3005 BUIL3xxx members instead of BUILDPD3. Error 22-7 UNKNOWN
JCLUXRE6 OPTION because SORTEDBY= was misspelled as SORTECBY=, and
Jan 15, 1997 because BUIL3005 was not in my QA stream (but now is)!
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 14.300 RMDS Versions 1.3 and 1.4 records have an undocumented
VMACRMDS section (or one added by APAR) with Originating Job and
Jan 14, 1997 Originating JOBID that was not previously INPUT by MXG.
To add these variables, insert after the @; that is
immediately after the INPUT of RMDSUDAT:
IF RMDSORG='A' AND RMDSACT='C' AND RECKEY='8080'X
AND LENGTH-COL+1 GE 16 THEN
INPUT
RMDSARN $EBCDIC8.
RMDSARI $EBCDIC8.
@;
(These two variables are already INPUT in the code for
later RMDS versions, and so they are in the KEEP= and
LABEL statements already!).
Thanks to Steve Colio, CIGNA Corporation, USA.
===Changes thru 14.299 were included in MXG 14.10 dated Jan 10, 1997===
(although top of CHANGES said only thru 14.298, 299 was there!)
Change 14.299 Support for NTSMF (Windows NT) measurement is now ready
ADOCNTSM for beta testing, and is very well documented. ADOCNTSM
NTINTRV now documents all 54 NTSMF datasets, and the new NTINTRV
VMACNTSM dataset is created (like RMFINTRV). See NTSMF Technical
Jan 8, 1997 Notes.
Change 14.298 PRO/SMS dataset PROSMS does not contain DSN nor DDNAME,
EXPROSMS but new sample code in this exit member (commented out,
Jan 2, 1997 as it may be installation dependent) shows how one site
was able to parse the text to identify which dataset and
DDNAME was altered by PRO/SMS.
Thanks to Warren Hayward, TJX Companies, USA.
Spent an actual Christmas vacation with family, and nothing broke!
Change 14.297 Variables MVUOBMDN,MVUSBIN,MVUSBMDN,MVUSOBIN,MVRETDAT are
VMACEDGS now INPUT from the type 'V' DF/SMSrmm record and are kept
Dec 19, 1996 in dataset EDGSVREC.
Also, the CDS records can be read directly with TYPEEDGS,
so using IBM's utility to dump the data is not required!
Thanks to Richard Fortenberry, Mitsubishi, USA.
Change 14.296 H-P Measureware variable SOFTWARE was kept as a 200-byte
VMACMWAI variable because it was not in the LENGTH statement; now
VMACMWSU it is set LENGTH $30. (and variable AMPM is now $2) to
VMACMWUX reduce the size of the datasets.
Dec 18, 1996
Thanks to Al Holtz, Medco Data Corporation, USA.
===Changes thru 14.295 were included in MXG 14.09 dated Dec 17, 1996===
Change 14.295 If you create type 74 records for devices other than just
RMFINTRV TAPE and DASD, the DEV..... SIO74CNT and AVGRSPTM values
Dec 17, 1996 include those other devices (eg, CTC) counts. Since it
is the intention to have only DASD counts in those fields
by inserting ELSE DELETE; before LENGTH SIO74TAP 4; those
other device records will not be included in RMFINTRV.
Thanks to W. Rathfelder, Taylorix AG, GERMANY.
Change 14.294 For multi-volume non-HSM-backup tape datasets, only the
DAILYDSN last volume's size was included in variable SPACE5, the
Dec 17, 1996 megabytes on non-HSM tape. Replace SPACE5=BLKSIZE*BLKCNT;
with SPACE5=TAPEBYTE;
Thanks to Chuck Hopf, MBNA, USA.
Change 14.293 Support for Windows NT measurement with NTSMF records
ADOCNTSM created by Demand Technology's product. This support is
EXNTxxxx for the beta testers of NTSMF. The fifty-four new MXG
IHDRNTSM datasets (one per "object") are described in ADOCNTSM
IMACNTSM member, and a more extensive discussion of NTSMF records
TYPENTSM will be in the NT Technical Notes section of the next MXG
VMACNTSM Version. Status of testing is also in ADOCNTSM.
Dec 17, 1996
Change 14.292 The very last IMS log record was not processed, because
VMACIMSA the ELSE IF LCODE=07X THEN DO; statement should have been
Dec 17, 1996 IF LCODE=07X THEN DO;
Thanks to Juerg Frei, SAS Switzerland, SWITZERLAND.
Change 14.291 Coupling Facility data added by PTF UW90312 was on a per
VMAC74 structure basis, not per-CF basis, so variable names were
Dec 14, 1996 R744CCOC thru R744CXRL were moved from TYPE74CF to the
TYPE74ST dataset, and MXG input logic was revised.
IBM's "CF Reporting Enhancements to RMF 5.1", WSC Flash
9609 has an excellent discussion of how to use these
important fields for determining if your Coupling Fac.
becomes the bottleneck in your sysplex. The flash also
lists APARs OW11789, OW12415, OW13418, and OW13536 as
required and it lists the additional hardware ECs that
you want to have installed for accurate CF measures.
-R742MSTF was FORMATed $HEX2, input $CHAR1.
-Variables R744FTIM, R744FSQU, R744FCTM, R744FCSQ are
input with PIB8 instead of the (IBM-documented!) RB8.6
informat, and variables R744CDEC,R744CDAC,R744CTCC, and
R744CDTA are input as PIB4 vice RB4.
Thanks to Steve Dodge, Amdahl Corporation, USA.
=Attended CMG 96 in San Diego, and Bernie Davidovich's wedding in NY.
Change 14.290 If your SAP Accounting Exit was miscoded, invalid length
IMACICSA type 110 records can be created, causing INPUT STATEMENT
Dec 3, 1996 EXCEEDED error. This change, inserted after STCLEN has
been INPUT, verifies the real data length agrees with the
STCLEN value, eliminating the exposure.
Thanks to Helgund Linck, BASF Compuer Services, GERMANY.
Change 14.289 DF/SMS Rmm EDGS records type V can cause INPUT STATEMENT
VMACEDGS EXCEEDED error because variable length fields & variable
Dec 3, 1996 number of fields at the end of the record were not input
Dec 17, 1996 correctly. Conditional INPUT of the variables MVDSN1,
MVDSNL, MVACCINF and MVDESC with $VARYINGnn. INFORMATS
with associated length variable, and INPUT of variables
MVAUTID1-MVAUTIDC based on MVACCLST was necessary.
Dec 17: Input of MVVOLSEQ must be &PIB.2. vice &PIB.1.
Thanks to Richard Fortenberry, Mitsubishi, USA.
Change 14.288 Negative tape allocation duration can result when system
ASUMTALO clocks are out of synchronization, if the clock delta is
TRNDTALO greater than the duration of the allocation, because only
Dec 3, 1996 the start time of allocation had been adjusted. Now both
the front-end and back-end timestamps are adjusted, and a
note is printed on the log that we are adjusting times
(and by how much).
Thanks to Ruth Whitney, CITICORP, USA.
Change 14.287 The number of DB2 Plans executed is no longer equal to
ANALDB2R the number of observations in DB2ACCT, if DB2 Parallelism
ASUMDB2A is used. Variable DB2PARTY (Parallel Type) identifies a
Dec 3, 1996 "real" plan execution (DB2PARTY='S' or DB2PARTY='O'), but
Dec 19, 1996 observations with DB2PARTY='P' are additional records for
parallel tasks within a plan execution and must not be
counted. In ANALDB2R and ASUMDB2R, NUMPLANS is now
calculated as:
IF QWHSRELN GT 4.0 AND DB2PARTY='P' THEN NUMPLANS=0;
ELSE NUMPLANS=1;
and then NUMPLANS is summed to get total count.
Without this change, you will see very, very large counts
of plans executed and per-plan measures will be very
small, if your DB2 application exploits parallelism.
Dec 19: The original test QWHSRELN GE 4.1 was changed to
QWHSRELN GT 4.0 (because 4.1's value is 4.0999994278!).
Also, this change removed the parallelized transactions
from being counted as NUMPLANS, but sequential parts or
parallelized transactions are still counted in NUMPLANS.
I have to count the DB2PARTY='S' transactions, because
for a non-parallelized transaction, that's all there is!
I hope to review this counting and see if there is a safe
way to only count 'S' obs for non-parallelized trans.
Thanks to Glenn Bowman, Wakefern Food Corporation, USA.
Change 14.286 DB2 Buffer Statistics in the Accounting Detail Report did
ANALDB2R not include buffer pools 1 and 2, so they did not cross-
Dec 3, 1996 foot to the "Total Total" field. Additional corrections
were made and fields on HPOOL/VPOOL usage were added.
Thanks to Terry Dehart, First of America Services, USA.
Change 14.285 Change 14.251 circumvented the error in decoding COLLECT
VMAC102 in DB2 Trace IFCIDs 21 and 44, but the real fix is:
Dec 3, 1996 Change both occurrences of IF I=19 AND J=13 THEN J=20;
to IF I=19 AND J= 7 THEN J=20;
and change the LENGTH of COLLECT back to $ 26.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt AG, Germany
Change 14.284 Support for Demand Technology's Stress Test SMF record.
EXTYSTRS This support decodes records into new dataset TYPESTRS,
IMACSTRS but enhancements under development will use your current
TYPESTRS TYPE74 and TYPE74CA statistics to create control cards
VMACSTRS that will drive Stress Test to simulate that current I/O
Dec 3, 1996 configuration.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.283 The HP MeasureWare dataset HPUXGLOB for HP-UX operating
VMACMWUX system had incorrect values for some variables, because
Dec 2, 1996 -the variable PEAKTM should not have been INPUT, and it
must be removed (i.e., the line INPUTing PEAKTM was
deleted by this change, as was the line LABELing PEAKTM
and it was removed from the KEEP= list for HPUXGLOB), and
-the variable NTPACKRT should have been INPUT, between the
INPUT of variables NTOUPKTS and NTCOLPCT (and it was
LABELed as NET*TOTAL*PACKET*RATE, and added to the KEEP=
list for HPUXGLOB).
Thanks to Al Holtz, Medco Data Corporation, USA.
Change 14.282 The archaic ASMVTOC program (which should be replaced by
ASMVTOC using DCOLLECT and TYPEDCOL) is also a pig! For a system
Dec 2, 1996 with 2496 DASD devices, ASMVTOC took 3.25 CPU minutes,
10 million EXCPs and 2.5 elapsed hours, while DCOLLECT
took 2.72 CPU minutes, 86 thousand EXCPs and 23 elapsed
minutes (and got VVDSs, Migration, and Backup data too!).
Note that the MXG 13.13 version of ASMVTOC either failed
during assembly, or assembled but then produced no output
records when executed, so if you still use ASMVTOC, you
will need 14.01 or later (to get Change 14.003).
Thanks to Chuck Hopf, MBNA, USA.
Change 14.281 The T102S221 trace dataset did not keep the low and high
VMAC102 ranges (page range in QW0221PL,PH, index range in KL-KX,
Nov 23, 1996 and KH-KY), which are needed if you wish to verify that
the I/O parallelism partitioning was even, and obs were
only output for the record, not for each segment. The
segment variables were added to the KEEP= list, and the
OUTPUT T102S221; statement was moved to immediatley be
after the @; after the INPUT of QW0221KY.
Thanks to Ted Blank, IBM, USA.
Change 14.280 The BETA93 1.6.5 subtype=3 record is written twice, once
VMACBETA at the start of print, and once at the end of print. As
Nov 23, 1996 there are no resources in the start record, that record
is now deleted. In the SUBTYPE=3 logic, between BETAATTR
and BETABPGE, insert:
@; IF BETAATTR NE 'C5'X THEN DELETE; INPUT
Thanks to Paolo Carloni, AGIP PETROLI S.p.A., ITALY
Change 14.279 HP MeasureWare for AIX variable PROGRAM was added to the
VMACMWAI LENGTH statement for $16 (default of $8 was not enough,
Nov 23, 1996 causing trunctation but no error), and variable SWAPMEM
was added to the KEEP= list for dataset HPAICONF.
Thanks to Lorenzo Wright, NCCI, USA.
Change 14.278 Support for VTAM Session Management Exit SMF record that
EXTYVSME is described in Appendix K of IBM ITSC Red Book "Network
IMACVSME Security Using the VTAM Session Management Exit, pub nr
TYPEVSME GG24-3544-00).
VMACVSME
Nov 23, 1996
Thanks to Kwok Wong, Commonwealth Bank of Australia, AUSTRALIA.
Change 14.277 IMAC6ESS is a user exit that permits decoding of the ESS
IMAC6ESS segment in the type 6 SMF record, and variable ROOM was
VMAC6 used in that commented-out code, but variable ROOM also
Nov 23, 1996 exists in TYPE26J2, so to prevent a possible conflict, I
renamed the ROOM in IMAC6ESS/VMAC6 to ROOM6. This should
cause no compatibility issue, since ROOM was not kept in
TYPE6 unless you tailored IMAC6ESS, and ROOM from TYPE26
was not kept in PDB.JOBS unless you tailored IMACPDB.
Thanks to Helgund Linck, BASF Computer Services GmbH, GERMANY.
Change 14.276 Change 14.040 inadvertently relocated the code to decode
VMACTCP FTPLOCAL and FTPREMOT in the TYPETCPF dataset, causing
Nov 23, 1996 those two variables to be missing in TYPETCPF. To correct
copy the 16 lines beginning with FTPLOCAL=PUT... ending
with FTPREMOT=COMPRESS... so they are immediately before
the %%INCLUDE SOURCLIB(EXTYTCPF) statement.
Thanks to Helgund Linck, BASF Computer Services GmbH, GERMANY.
===Changes thru 14.275 were included in MXG 14.08A dated Nov 18, 1996===
Change 14.275 Cosmetic changes. Duplicate variable names were removed
IMACAAAA from KEEP= list in VMACHARB and VMACMWAI, IMACAAAA was
VMACHARB updated with new member names that were overlooked, and
VMACMWAI the AS/400 support for Release 3.7 was listed under 14.08
Nov 18, 1996 in the list of Significant changes in 14.08.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.274 SuperIND$FILE SMF record had some character fields off by
VMACSUIN one byte, because the +1 between XFERMODE and INBUFFSZ
Nov 18, 1996 does not belong and was deleted.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.273 MXG 14.05-08 only. INVALID DATA FOR R744FCTM and FCSQ.
VMAC74 Added by Change 14.165, conditionally INPUT by Change
Nov 15, 1996 14.196, the fields were still wrong in MXG 14.07 because
the DSECT shows BL8, like the two preceding fields so
I expected &RB.8.6 fields, but actual data values show
the two fields must be INPUT as &PIB.8.6 instead!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt AG, Germany
Change 14.272 SAP Umbrella Transaction's Program and Tranname are kept
IMACICOC in variables OMUMBUSR and OMUMBPTC, while the variables
Nov 14, 1996 PROGRAM and TRANNAME contain the name of the SAP Primary
Program and Transaction. If you want your SAP reports to
show the Umbrella names rather than Primary names, you
can insert these lines in your reporting programs:
IF OMUMBUSR GT ' ' THEN PROGRAM=OMUMBUSR;
IF OMUMBPTC GT ' ' THEN TRANNAME=OMUMBPTC;
You could insert these lines in member IMACICOC to store
the Umbrella names into PROGRAM and TRANNAME in CICSTRAN,
but then you could not go back to determine the Primary
names, if they were ever needed. Thus there was no code
changed in MXG by this Documentation Note Change.
Thanks to Joan Nielsen, PKS Information Services, Inc, USA.
====Changes thru 14.271 were included in MXG 14.08 dated Nov 13, 1996===
Change 14.271 Support for AS/400-OS/400 Release 3.7.0 added many new
VMACQAPM variables to datasets QAPMBUS,QAPMCONF,QAPMJOBS,QAPMMIOP,
Nov 12, 1996 and QAPMRESP. Support for all fields added by 3.6.0 are
also now supported. All 3.7.0 changes were compatible,
except for the QAPMETH dataset, which had ETLFRT expanded
from three to six bytes (and I had misspelled it!). The
3.6.0 partial changes in CHANGE 14.098 were INCOMPATIBLE.
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 14.270 Cosmetic. All of the LABEL, FORMAT, INFORMAT, and LENGTH
VMAC110 statements in the Statistics code (Subtype=2) were moved
Nov 12, 1996 together into single statements with alphabetic lists.
Change 14.269 Execution of MXG Software under Unix requires each PDS
IEBUPDTE member become an individual file with suffix "sas", AND
Nov 12, 1996 the filename must be in lower case! The IEBUPDTE.SAS
program creates the individual files, but their names are
in upper case, causing execution under UNIX to fail!
This change inserts MEMBER=LOWCASE(MEMBER); after the
MEMBER=TRIM.... statement to create the members in lower
case. Make sure the output directory is empty before
running the IEBUPDTE.SAS program, as it appears that if
the output file name already exists as an upper case name
that the data is copied but the name is not re-cased!
Thanks to Mike Orlando, Nalco Chemical Company, USA.
Change 14.268 Protection was added to eliminate DIVISION BY ZERO error
VMAC7072 if IOCCOEFF was zero. I had assumed IOCCOEFF would never
Nov 12, 1996 be zero, but if it was, the divide error occurred.
RMFINTRV Also, PGPIOTM is now forced missing for MVS/ESA 5.2 or
Mar 10, 1997 higher. When IO units could be based on either EXCP or
IOTM, both PGPEXCP and PGPIOTM (raw IO EXCP count or raw
IO Connect time) were calculated (even though only one
was ever valid), because IBM did not flag whether you had
specified EXCP or IOTM for your IO Service Units). But
with MVS/ESA 5.2+, IO Service Units can only be based on
EXCP count, so PGPIOTM has no meaning.
Mar 10, 1997: Because PGPIOTM in TYPE72 is missing, the
variables BATIOTM, CICSIOTM, IMSIOTM, TSOIOTM, OTHRIOTM
in dataset RMFINTRV will also be missing.
Change 14.267 This report showed zeros for channel busy in LPAR mode.
ANALPATH Change PNCHANBY=MIN(PNCHANBY,PCHANBY);
Nov 12, 1996 to read PNCHANBY=MAX(PNCHANBY,PCHANBY);
Nov 18, 1996 (Nov 12 text had PCHANBY on left, corrected Nov 18.)
Thanks to Jim Ray, Branch Banking and Trust, USA.
Change 14.266 MXG 14.04-MXG 14.07. The word "NEW" must be deleted from
VMACITRF line 245 to prevent INPUT STATEMENT EXCEEDED ERROR. This
Nov 4, 1996 was introduced by Change 14.128 and incomplete testing.
Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.
Change 14.265 Support for HP's MeasureWare for SUN operating system.
EXHPSUTT The same datasets that were created by HP's PCS for SUN
IMACMWSU are created, with one new dataset:
TYPEMWSU Dataset Description
VMACMWSU HPSUTRAN Transaction Tracker Record
Nov 1, 1996
Thanks to Gary Alexander, BMC, USA.
Change 14.264 Support for CA's ENDEVOR SMF record creates two datasets
EXENDVAC Dataset Description
EXENDVSE ENDEAVAC Action Record
FORMATS ENDEAVSE Security Record
IMACENDV The Action record has been validated with actual data,
TYPEENDV but no security records had been created (there were no
VMACENDV security violations!) so that code is untested.
Nov 1, 1996
Thanks to Grace Pergament, Amdahl Corporation, USA.
Thanks to Susan Walters, Michelin Tire Corporation, USA.
Change 14.263 Dataset DCOLAG (Aggregate Group Definitions) has several
VMACDCOL fields incorrect, because the @208 preceding DAGEXPYR
Nov 1, 1996 should have been @209.
Thanks to Gary Miner, Fidelity Investments, USA.
Thanks to Lawrence Jermyn, Fidelity Investments, USA.
Change 14.262 Calculation of DOMDSPCH and ADJTARG must be changed to:
VMACAPAF IF ACTIVE GT 0 THEN DO;
Nov 1, 1996 DOMDSPCH=INTERVAL*DOMDSPCH/ACTIVE;
ADJTARG =INTERVAL*ADJTARG /ACTIVE;
END;
(The variables are divided by INTERVAL earlier in code.)
Thanks to Stephen H. Lothes, Flexlogic, Inc, USA.
Change 14.261 Using the new High Level Assembler PGM=ASMA90 instead of
ASMIMSLG its predecessor Assembler PGM=IEV90, a syntax error that
Nov 1, 1996 was overlooked by IEV90 was encountered. The statement
STATS=SKIP following WRITEMSG IMSM101I needs a comma
(STATS=SKIP,) for the continuation.
Thanks to ???, BBK, SPAIN.
Change 14.261A The statement MONICASP=MONACISP; must be changed to
TYPEMON8 MONICASP=MONACASP; to pick up the correct
Nov 1, 1996 temporary value.
Thanks to Alfred Brunner, COMLAB Gmbh, GERMANY.
Change 14.260 DFSMS/RMM SMF records caused INPUT STATEMENT EXCEEDED.
VMACEDGS In the EDGATYPE='O' code, the test IF MOCFLG EQ '08'X ...
Nov 1, 1996 must be replaced with IF MORTYPE EQ '000000000000'X ...
and IF MOVOLNO GT 0 AND MOCFLG NE '08'X THEN DO ...
must be replaced with only IF MOVOLNO GT 0 THEN DO ...
In the EDGATYPE='P' logic, the statement
IF MOVOLNO GT 0 THEN DO _I_=1 TO MOVOLNO; must be
IF MPVOLNO GT 0 THEN DO _I_=1 TO MPVOLNO; must be
Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.
Change 14.259 Support for Omegamon for VTAM V200 was not complete; an
VMACOMVT extra four bytes added to IRNUM=13 segment was overlooked
Oct 30, 1996 in Change 14.268. After input of OM13GT, insert:
OM13DT &PIB.4. /*NCP*INTERVAL*DELTA*TIME*/
and add OM13DT to KEEP= list.
Thanks to Neil McMenemy, Royal Bank of Scotland, SCOTLAND.
Change 14.258 Goal Mode variable RPTCLASS was added to PDB.JOBS. The
IMACPDB variable name was added to the _PDB30_4 macro, and to
Oct 30, 1996 the ID statement in macro _PDBSUMS (just like SRVCLASS).
Thanks to Steve Colio, CIGNA, USA.
Change 14.257 The 22 new Shared Paging variables in TYPE71 starting
VMAC71 with SHPBINAU and thru SHPGLOAV need to be INPUT as
Oct 25, 1996 &RB.4. instead of &PIB.4.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.256 Support for APAR OW22209 which (compatibly) adds fourbyte
VMAC21 counters for bytes read and bytes written, replacing the
Oct 24, 1996 two byte counters that could overflow! Also OW25262.
Change 14.255 Formats MGBYTES and MGBYTRT now format Petabytes, because
FORMATS I finally found (in an IEEE Computer Society article)
Oct 24, 1996 that 1000 Tera is 1 Peta!
Change 14.254 TYPE72GO variables R723CSRS, R723CSPA, R723CSPE are still
VMAC7072 wrong! Their informats are &RB.8.6, &RB.8., and &RB.8.
Oct 24, 1996 respectively.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 14.253 The JCL example showed //SYSID instead of //SYSIN.
ANALDB2C While minor, its still worth fixing, since a non-expert
Oct 23, 1996 with JCL might not recognize the misspelling.
Thanks to David Middlebrook, National Exchange of Police, AUSTRALIA.
Change 14.252 An invalid RACF segment for RACFTYPE=03 caused STOPOVER.
VMAC80A Although IBM documents a single length of 1 byte, the
Oct 23, 1996 segment had 151 bytes! To protect, insert:
SKIP=RACFDLN-1;
IF SKIP GT 0 THEN INPUT +SKIP @;
just before the END; that ends the WHEN (3) DO; clause.
Thanks to Silva Viviani. Fondo Commune D.C. Rurali Trentine, ITALY.
Change 14.251 INVALID SECOND ARGUMENT TO FUNCTION SUBSTR in DB2 102 due
VMAC102 to incorrect length statement for variable COLLECT, which
Oct 23, 1996 must be $28 instead of $26.
Thanks to Dr. Alexander Raeder, Karstadt, AG, Germany
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
Change 14.250 Cosmetic. TMON for CICS variables CPUTCBTM, UNKNCPTM and
TYPETMON CPUTM were not formatted as TIME12.2, but now are.
Oct 19, 1996
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 14.249 Support for HP's Measureware for AIX has been written and
IMACMWAI tested. The same datasets that were created by HP's PCS
TYPEMWAI for AIX are created, although some variables were deleted
VMACMWAI and some new variables are created.
Oct 17, 1996
Thanks to Lorenzo Wright, NCCI, USA.
Change 14.248 Support for Applied Software's SUPER IND$FILE product's
VMACSUIN SMF record, which creates dataset SUPERIND with stats on
Oct 17, 1996 file trasnfer with that utility program under TSO.
Thanks to George Briscoe, MBNA, USA.
Change 14.247 Support for Oracle 7.0.16 and 7.2.3 is in MXG 14.02 and
VMACORAC later, as there was no change in the format of the SMF
Oct 17, 1996 record created by those releases.
Thanks to Paul Hassett, U.S. Department of Transporation, USA.
Change 14.246 AS/400 variable GDES4 (storage size) was increased by IBM
VMACQAPM causing truncation of the size of installed storage. The
Oct 16, 1996 &NUM.7. after GDES4 was changed to &NUM.10. to correct.
Thanks to Ed Shigo, Nabisco, USA.
Change 14.245 Testing with intentionally duplicated SMF data uncovered
BUILDPDB cases where the PROC SORT NODUP did not remove duplicate
BUILDPD3 observations, because the BY list was underspecified.
BUILD002 For TYPE30MU, add PRODOWNR PRODNAME PRODQUAL PRODVERS to
BUILD003 its BY list.
MONTHBLD For TYPE74CA, add DEVN SMFTIME to its BY list.
WEEKBLD For TYPE74CF, add R744FNAM SMFTIME to its BY list.
Oct 16, 1996 For TYPE74ST, add R744SNAM SMFTIME to its BY list.
For TYPE77, add QNAME RNAME SMFTIME to its BY list.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.244 Change 12.179 was not applied to VMACIMSA, used by the
VMACIMSA ASMIMSLG processing, causing SAP variables SAPTIMTR,
Oct 15, 1996 SAPCPUT, and SAPELTI to be incorrect.
Thanks to Markus Joos, SAS Germany, GERMANY.
Change 14.243 Support for RACF 2.1 IRRDBU00 unload utility has now been
VMACRACF verified for most records. The only change was that the
Oct 11, 1996 variable TIMEOUT in RACF0230 should be INPUT as TIME5.,
instead of the previous ZDB5. input.
Thanks to Peter Cannone, The Great Atlantic & Pacific Tea Co., USA.
Change 14.242 A truncated catalog cell=04 record caused INPUT STATEMENT
VMAC6156 EXCEEDED RECORD LENGTH. The cell has VOLHYKLN=2, but
Oct 10, 1996 that is at the end of the record, and there was no high
key following the key length. Protection added so that
MXG checks to see there is still data in the record prior
to INPUT of VOLHIKY.
Thanks to Raff Rushton, Great Western, USA.
Change 14.241 Support for RACFEVNT=27 (GENERAL AUDIT) creates the new
EXTY8027 TYPE8027 dataset. RACFTYPE=36 is now decoded in SETROPS
IMAC80A (RACFEVNT=24) records.
VMAC80A
Oct 10, 1996
Thanks to Robert Miles Standish, Dean Witter Trust Company, USA.
Change 14.240 IPAC SMF records cause INVALID ARGUMENT TO FUNCTION MDY
VMACIPAC (and print hex dump with "RDS " in bytes 15-18) because
Oct 9, 1996 the SDATE and EDATE are julian dates, not MMDDYY as the
vendor documented.
Thanks to Shaheen Pervais, Trans Union, USA.
Change 14.239 The TAILORNG= JCL parameter added by Change 14.140 is bad
MXGSAS and in the sample MXGSAS JCL Procedureit must be:
Oct 7, 1996 TAILORNG='*.NULLPDS,VOL=REF=*.NULLPDS',
(like the LOAD= and SASAUTO= symbolic parameters).
With the delivered TAILORNG=NULLFILE, a JCL error occurs
(because NULLFILE is a sequential file, not a PDS).
Thanks to Mr. Harnischmacher, TEZ Test und Entwicklungszentrum, GER.
Change 14.238 Archaic IDMS 10.2.1 SMF records caused STOPOVER because
VMACIDMS the subtype 2 record is 4 bytes shorter, and the subtype
Oct 1, 1996 6 is one byte shorter than the code expected.
Oct 8, 1996 At the end of the INPUT for PMHRTYPE=2, change the +12 to
Oct 16, 1996 +8, and change SKIP=SKIP-108; to SKIP=SKIP-104;
I suspect a CA PTF changed the record, because I am sure
this code ran against 10.2.1 records in past years, but
the fix protects both 10.2.1 and 12.01 records.
-In the PMHRTYPE=6 code, replace the line with +1
after the line inputting JRLFILE with:
@; IF SMFHVER GE '1201' THEN DO;
INPUT +1 @; SKIP=SKIP-1;
END;
and change SKIP=SKIP-105; to SKIP=SKIP-104;
-In the PMHRTYPE=18 code, change code now reading:
DBKPGGRP &PIB.2.
+2
DBKKYFMT &PIB.4.
DBKLTYPE &PIB.4.
@;
SKIP=SKIP-14;
IF DBKOWNER='80'X THEN DO;
to instead look like this:
DBKPGGRP &PIB.2.
@;
SKIP=SKIP-4;
IF SMFHVER GE '1201' THEN DO;
INPUT +2
@;
SKIP=SKIP-2;
END;
INPUT DBKKYFMT &PIB.4.
DBKLTYPE &PIB.4.
@;
SKIP=SKIP-8;
IF DBKOWNER='80'X THEN DO;
Thanks to Paul Hasset, U.S. Department of Transportation, USA.
Change 14.237 Candle's EPILOG for MVS records with SM180SUB='RCCH' are
VMACEPMV not the expected record and are deleted. The test for
Sep 30, 1996 'RSRC' was expanded to OR SM180SUB='RCCH' THEN DELETE;
Also, the following INPUT statement is now conditionally
executed as IF LENGTH-COL+1 GE 152 THEN INPUT ....
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Change 14.236 Support for new RMF type 74 subtype 100 record, called
EXTY74LK the IRLM 'long lock' package, added by APAR OW20579 and
IMAC74 others, that measures held time for IRLM Structure locks
VMAC74 in the Coupling Facility. This APAR has been in FIXTEST
Sep 28, 1996 for quite a while but has been distributed to some
customers, and there is an RMF User report that displays
locks held/waited. New dataset TYPE74LK contains one
observation for each IRLM lock structure name. This code
has not been data-tested as yet.
Change 14.235 Support for several new fields (mostly SMS-related, like
VMXGHSM Data, Storage, and Management Classes) added to the HSM
Sep 28, 1996 MCC record. Additionally the SC,DC, and MC class names
Oct 9, 1996 in both MCC and MCD records are now input only if their
length is non-zero; some zero-length records had hex
zeroes instead of blanks for these name fields. Also, the
INFILE statements needed LENGTH=LENGTH COL=COL added.
Thanks to Terry Duchow, U.S. Postal Service, USA.
Change 14.234 PRO/SMS support in Change 14.207 was incorrect; test data
EXPROSRE for subtype 1 has now been verified, but subtype 2 record
IMACPROS documentation disagrees with actual content of test data.
VMACPROS There are now two datasets created:
Sep 28, 1996 Dataset Subtype Description
Oct 16, 1996 PROSMS 1 Message
Nov 1, 1996 PRORECOV 2 Recovery Performed
Both datasets have been tested with actual data.
Thanks to Warren Hayward, TJX Companies, USA.
Change 14.233 TYPE89 usage data variable MULCURD, for Batch Pipes, was
VMAC89 incorrectly input. The input format of MULCURD is set by
Sep 26, 1996 the value of MULTCURT, but MXG had reversed the INPUT for
MULTCURT 2 and 3. The correct statements should be:
IF MULCURT EQ 1 THEN INPUT MULCURD &RB.8.2 @;
ELSE IF MULCURT EQ 2 THEN INPUT MULCURD &PIB.8. @;
ELSE IF MULCURT EQ 3 THEN INPUT MULCURD &RB.8. @;
The choice of format for MULCURD is set by the product's
FUNCTIONDATA request in its macro IFAUSAGE; previous data
records contained MULCURT=1, which correctly read MULCURD
but BatchPipes sets MULCURT=3, exposing the error.
Thanks to Michael Oujesky, MBNA, USA.
Change 14.232 HSM warning "FSRTVOLS CAN CONTAIN ONLY 30 BYTES" is writ
VMACHSM in error. The two lines preceding the PUT of that
Sep 25, 1996 message, now reading IF LENGTH(FSRTVOLS) GT 23 THEN ...
must be changed to: IF LENGTH(FSRTVOLS) GT 30 THEN ...
Thanks to Robert Miles Standish, Dean Witter Trust Company, USA.
Change 14.231 Change 14.167 was implemented and printed incorrectly.
DIFFDB2 The four lines after that change that start with:
Sep 25, 1996 IF QWHSISEQ GE 1 AND PREVSSID .... must be changed to:
IF SEQCHECK GE 1 AND PREVSSID ....
One source of the skipped sequence numbers (QWHSISEQ) is
CA's INSIGHT monitor for DB2. When INSIGHT is started at
DB2 startup, several ISEQs are skipped, and several ISEQs
are skipped at shutdown. CA is investigating.
Thanks to Tom Parker, Hogan Systems, USA.
Change 14.230 Huron dataset HURN47 had zero observations if there were
VMACHURN no external resource segments at the end of the record.
Sep 23, 1996 After the END; statement that ends DO I=1 TO HU47XSNO;
insert:
IF HU47XSNO EQ 0 THEN DO;
%%INCLUDE SOURCLIB(EXHRN47);
END;
Thanks to Mark Totleben, Farm Bureau Insurance, USA.
Change 14.229 Support for Interlink's Harbor 4.1 SMF record creates
EXHARARC nine datasets for that backup product:
EXHARBKP Subtype Dataset Description
EXHARCON 01 HARBBKUP Harbor Backup Request Info
EXHARDIS 02 HARBREST Harbor Restore Request Info
EXHARFIL 03 HARBARCH Harbor Archive Request Info
EXHARMIG 04 HARBRETR Harbor Retrieve Request Info
EXHARREC 05 HARBDIST Harbor Distribution Info
EXHARRES 06 HARBMIGR Harbor Migration Info
EXHARRET 07 HARBRECA Harbor Recall Info
FORMATS 08 HARBCONS Harbor Consolidation Info
IMACHARB 09 HARBFILE Harbor File Pickup st
TYPEHARB The first two subtypes have been validated with test data.
VMACHARB
Sep 22, 1996
Thanks to Paul Hassett, U.S. Department of Transportation, USA.
Change 14.228 Support for EOS (Change 14.143) wasn't correct; the Audit
FORMATS records were INCOMPATIBLY changed, causing MXG to trash
VMACWSF the WSFAUDIT dataset (but there was no execution error,
Sep 22, 1996 and the other datasets were validly created). There were
additional compatible changes made to EOS (aka WSF2):
New values for format MGWSFAC
New Audit variables in dataset WSFAUDIT:
AUDCFO - Form Used to Create
AUDCUSR - Report Owned By
AUDCTIM - Report Capture Datetimestamp.
New event variables in dataset WSFEVTSC:
ACCIPAD - IP address
ACCLUTY2 - LU Type (VTAM or TCP/IP)
ACCRESP5 - Responses LE 30 seconds
ACCRESP6 - Responses LE 2 minutes
ACCRESP7 - Responses LE 5 minutes
ACCRESP8 - Responses GT 5 minutes
Thanks to Judy Arroyo, Summit Bank, USA.
Change 14.227 Variable R742PSTA in dataset TYPE74PA is now decoded to
FORMATS describe path status, based on APAR OW22735, with new MXG
VMAC74 format $MG074ST.
Sep 20, 1996
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.226 DB2 Group Buffer Pool dataset DB2GBPST repeats the first
VMACDB2 buffer pool's data because the pointer was not moved.
Sep 18, 1996 Insert @OFFQBGL @; before the DO _I_=1 TO NRQBGL;
statement, and then remove the @OFFQBGL from the INPUT
statement after that DO statement.
Thanks to Bertolotti Emmanno, Banca Commerciale Italiano, ITALY
Thanks to Burani Daniela, Banca Commerciale Italiano, ITALY
Change 14.225 CICS/ESA 3.3, with optional ONC RPC feature creates a 5th
VMAC110 TCB in SMF 110 Statistics STID=57 records that was not
Sep 18, 1996 expected in MXG, causing MXG to print "UNEXPECTED (NEW)
Oct 9, 1996 DATA WAS FOUND" message on the SAS log. The APAR that
made the change was PN63215, closed in 1994, so it seems
that few sites have the ONC RPC feature on CICS 3.3.
MXG supports the 5th TCB for CICS 4.1 (and the 6th for
CICS 5.1), so only the 3.3 logic had to be corrected.
Oct 9: DSGNTCB is supposed to be the number of TCBs, but
in some CICS 3.3 records, it is zero, so the logic was
revised.
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 14.224 Labels for CONTROL-T variables DENSITY, RECFM, TRTCH, and
VMACCTLT VDENSITY were corrected.
Sep 16, 1996
Thanks to Paul Hassett, U.S. Department of Transportation, USA.
Change 14.223 The INFILE statements for TANDCTLR and TANDLINE must be
VMACTAND LRECL=86 and LRECL=128 respectively. While comments had
Sep 12, 1996 correct values, both INFILE statements had LRECL=342.
Thanks to Alan Phelan, Allied Irish Bank, IRELAND.
Change 14.222 ASM fails; last minute changes were not tested. Find
ASMDALO Find 'R12,R11' and remove the blank after MXGDALO
Sep 12, 1996 Exclude ALL, Find 71,71 'X' ALL and in those four lines
move the X in column 71 to column 72 (so the Assembler
will recognize them as continuations).
Thanks to Chuck Hopf, MBNA, USA.
====Changes thru 14.221 were included in MXG 14.07 dated Sep 11, 1996===
Change 14.221 Support for IMS 5.1 Fast Path records using TYPEIMS7 to
VMACIMS read IMSLOG was added. The ASMIMSLG processing member
Sep 10, 1996 VMACIMSA already supported the Fast Path changes; this is
the same code, moved into the VMAC used by TYPEIMS7.
Thanks to MH, Allied Irish Bank, IRELAND.
Change 14.220 CICS Exclude logic for CICS 4.1 had a missing semicolon
IMACEXCL (the line BASETIME=...) and the IF SMFPSRVR GE 41.1 THEN
Sep 10, 1996 must be IF 33.0 LT SMFPSRVR LE 41.0 THEN ...
Thanks to Pat Quinnette, Principal Mutual Life Insurance, USA.
Change 14.218 Support for SNMP IFENTRY tables from TRENDSNMP product
EXTRSIFE from Desktalk, which polls SNMP agents and builds SYBASE
IMACTRSN tables, either under UNIX or WINDOWS-NT. MXG can execute
TYPETRSN either on an ASCII platform that connects to the SYBASE
VMACTRSN system and uses PROC ACCESS to directly convert the data
Sep 10, 1996 into SAS datasets, or instead, you can use the SYBASE BCP
utility to create an ASCII flat file that MXG can read on
the PC/Workstation, or that ASCII file can be shipped to
MVS and processed there. Macro _SIFEN uses PROC ACCESS,
Macro _TIFEN uses INFILE/INPUT to read BCP data. This is
the preliminary implementation and has been tested, and
will read either the Rate table or the History Table.
This code does no date/time selection; you get all of the
data in the SYBASE table, so you will need to select the
desired data. Future enhancements to provide selection
of "just yesterday's" data are planned, as are support
for additional SNMP tables and RMON data. Benchmarks on
my 64MB 166MHz Pentium with Windows NT 3.51 reading 20MB
SYBASE table that contained 6 days hourly data from 1000
devices (66,816 rows):
PROC ACCESS convert SYBASE to SAS: 265 seconds
or
BCP dump SYBASE to ASCII file 471 seconds
INFILE/INPUT read BCP dump 21 seconds
Thanks to Bernie Davidovich, Predictive Systems, USA.
Change 14.217 DB2 4.1 variables QTGA and QBGA were trashed, because the
VMACDB2 offsets were input from the wrong location. After test
Sep 10, 1996 IF QWHSNSDA GE 11 THEN ... the INPUTs with @81,85,87,89,
93, and 95, should be 97,101,103,105,109,111.
Thanks to Bertolotti Emmanno, Banca Commerciale Italiano, ITALY
Thanks to Burani Daniela, Banca Commerciale Italiano, ITALY
Change 14.216 Three new utilities are now available for Beta testing:
UTILCONT UTILCONT produces a PROC CONTENTS-like output with the
UTILFATD size (MegaBytes and observations) of each data
UTILSIZE set in the library pointed to by the PDB DDna.
Sep 10, 1996 UTILFATD reads the directory of all of your FAT disks
connected to this PC and calculates how much
space the data would take on hard disks of
varying cluster size (512 to 32K).
UTILSIZE reads an MVS PDS to calculate how much space
is needed to put that PDB library on a FAT
disk on your PC for all valid Cluster Sizes.
Large Cluster sizes may waste large amounts of
space when you have many little files. This
is useful to predict how much free space you
will need on your PC to store the MXG source
library.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.215 This is the Beta Version of the new MXG DASD Allocation
ASMDALO Monitor, which creates an SMF record for each of these
EXDALOAL DADSM events:
EXDALOEX DALOALOC ALLOCATE
EXDALOPA DALOSCRA SCRATCH
EXDALOPP DALORENA RENAME
EXDALORE DALOEXTN EXTEND
EXDALOSC DALOPART PARTIAL RELEASE
EXDALOVS DALOPPRL PARTREL PARTIAL RELEASE
IMACDALO DALOVSAM VSAM EXTEND WITHOUT A DEB
TYPEDALO and MXGDALO can be enabled for selected devices and/or
VMACDALO selected datasets. This monitor can be used to identify
Sep 9, 1996 jobs that are living on DASD extents (so you can increase
their primary allocation to avoid exposure to B37/E37
ABENDS. This monitor can be used to track (and charge?)
usage of temporary DASD space. Other uses are expected.
Read the comments in ASMDALO before you proceed.
Change 14.214 Variable SERVUNIT (total service units) was stored in 4
BUILDPDB bytes, whick keeps only 7 significant digits; a large
BUILDPD3 value in SERVUNIT (714 million units) was truncated by
BUIL3005 1000 units because 5 bytes storage is required to exactly
BUILD005 represent a numeric field that was input from four binary
VMAC30 bytes. SERVUNIT is now stored in 5 bytes. But the real
VMAC434 error here was the site's MSOCOEFF=3.0, way too large.
VMACTSOM An MSOCOEFF=.0001 is MXG's recommendation, so that the
Sep 10, 1996 MSO units do NOT contribute to SERVUNIT - only CPU time
Mar 10, 2003 and I/O operations are real computer work - and then the
value of SERVUNIT can be used to measure capacity. The
CPU+I/O service was 31 million units, showing the large
MSOCOEFF made the SERVUNIT field meaningless!
Mar 10, 2003: Original text has .000001 but .0001 is the
minimum value, other than zero.
Feb 21, 2005: See MXG Technical Note in Newsletter 47;
IBM Discovered that the smallest value is actually .0122.
Any value less than that value will be reported in the
MSOCOEFF in TYPE72GO, but only 0.0122 will be used!
Change 14.213 Support for NETVIEW 3.1 compatible changes to type 37
VMAC37 record added two fields, BRFEDCP1 and BRFPCCP1 to the
Sep 8, 1996 generic event report. While these fields were added
compatibly, MXG Version 13.13 failed with NETVIEW 3.1
because of MXG logic error that was fixed by MXG 14.090.
Thanks to Herb G. Strozinsky, Burlington Northern Sante Fe, USA.
Change 14.212 CICS/ESA 4.1+ GMT offset MCTMNTAD is not exact hours from
VMAC110 GMT (examples were off by 3.15, 0.9, and 0.6 seconds).
Sep 6, 1996 IBM lists APARs OW02410,OW10435,OW14651,OW14350,OW15036
and (most likely) OW15111 as the corrections, but the IBM
error is now circumvented by using the equation:
MCTMNTAD=3600*FLOOR((MCTMNTAD+900)/3600);
to exactly set the GMT offset to the nearest hour.
With CICS 4.1 and later, MXG uses MCTMNTAD to convert the
CICSTRAN variables STRTTIME and ENDTIME to local time,
so the overall impact was minimal, unless you tried to
compare CICS transaction start/stop times with TPX logon
times; the CICS error had transactions starting before
the terminal had logged on to CICS!
Thanks to Pat Quinnette, Principal Mutual Life Insurance, USA.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 14.211 CICS/ESA 4.1+ does not create obs in STID=4 statistics
CICINTRV dataset CICTSR, causing variable A02TTA in CICEODRV and
Sep 6, 1996 CICINTRV to be missing. However, the transaction counts
are in variable XMRAC in CICXMR, which was previously not
summarized in CICINTRV, but with this change now is, and
if A02TTA is missing, the value of XMRAC will be stored
into A02TTA so your old reports will be protected. Both
A02TTA and XMRAC are kept in CICINTRV/CICEODRV.
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 14.210 Datasets PDB.RMFINTRV, PDB.JOBS, PDB.STEPS, PDB.PRINT
BUILDPDB PDB.SMFINTRV, PDB.SPUNJOBS and (JES2 only) PDB.NJEPURGE
BUILDPD3 are built in sort order, but because they are built in a
BUILD002 DATA step (rather than directly by PROC SORT, as are most
BUILD003 other PDB datasets), SAS does not know they are sorted.
BUILD004 By specifying the dataset option SORTEDBY= on the DATA
BUILD005 statement, SAS now knows the sort order, so that it can
BUIL3005 bypass unnecessary sorting. In making this change, I
IMACPDB also finally removed the archaic _PROTECT token from all
RMFINTRV of the BUILDPDB members; defined in IMACPDB, PROTECT was
SPUNJOBS a SAS version 5 facility that is no longer needed, (see
Sep 5, 1996 comments in member IMACPDB), that defaults to null with
SAS version 6, and to have preserved it and to have added
SORTEDBY= would have required an INCOMPATIBLE change in
member IMACPDB. While the references to _PROTECT in the
BUILxxxx members was removed, the macro itself is still
defined in member IMACPDB to avoid a different
INCOMPATIBILITY (in case you have actually modified
BUILDPDB itself), but the comments in IMACPDB were
revised to clarify its non-use!
Thanks to Carl Sommer, SAS Institute Cary, USA.
====Changes thru 14.209 were printed in MXG Newsletter THIRTY==========
====and were in the early MXG 14.07 tapes dates September 10, 1996=====
Change 14.209 Support for CICS/ESA 5.1.0, now known as CICS Transaction
EXCICLGR Server for OS/390 Release 1, which INCOMPATIBLY inserted
EXCICLGS 19 new fields in the CICSTRAN Transaction Accounting data
EXCICNQG (had the fields been appended instead of inserted, this
EXCICRMG would be compatible!), added 2 new fields to CICSEXCE,
EXCICTQR added new fields in 8 existing Statistic Datasets, and
FORMATS five new Statistics datasets are created from new STIDs.
IMACCICS STATUS: IBM documentation of STID=82 (MNR) record is
IMACEXCL wrong; that STID is skipped without message in this code.
VMAC110 This version has been tested with real data records!
Sep 10, 1996 This change also supports the YYYY versus YY value in the
Statistics subtype's header, and the expanded TRANTYPE
(two bytes, more meanings decoded).
New variables added to CICSTRAN (transaction) dataset:
FCTYNAME='TRANSACTION*FACILITY*NAME'
LOGWRTCT='CICS*LOG STREAM*WRITE REQUESTS'
PERRECNT='PER RECORDS*WRITTEN*FOR TASK'
RMUOWID ='RECOVERY*UNIT OF WORK*ID'
RPTCLASS='REPORT*CLASS*NAME'
SC24FSHR='SHARED BYTES*FREEMAINED*BELOW 16MB'
SC24GSHR='SHARED BYTES*GETMAINED*BELOW 16MB'
SC24SGCT='SHARED*GETMAINS*BELOW 16MB'
SC31FSHR='SHARED BYTES*FREEMAINED*ABOVE 16MB'
SC31GSHR='SHARED BYTES*GETMAINED*ABOVE 16MB'
SC31SGCT='SHARED*GETMAINS*ABOVE 16MB'
SRVCLASS='SERVICE*CLASS*NAME'
TERMCNNM='TERMINAL*SESSION*CONNECTION*NAME'
TERMINFO='TERMINAL*OR SESSION*INFO FLAGS'
TRANFLAG='TRANSACTION*FLAGS'
WTRLIOCM='RLS*IO WAITS'
WTRLIOTM='RLS*IO WAIT*DURATION'
WTSYIOCN='SYNCPOINT*IO WAITS'
WTSYIOTM='SYNCPOINT*IO WAIT*DURATION'
New variables added to CICSEXCE (exception) dataset:
EXCMNTCN='TRANSACTION*CLASS*NAME'
EXCMNSRV='SERVICE*CLASS*NAME'
EXCMNRPT='REPORT*CLASS*NAME'
New variables added to CICDS (Dispatcher, by TCB Stats)
for ONC/RPC Mode (5th) TCB and File Owing Mode (6th) TCB
(STID=56):
DSnACT DSnPERCT DSnSCT DSnSTART DSnSWT DSnSYSW
DSnTCBF1 DSnTCBF2 DSnTCBF3 DSnTCBF4 DSnTCBNM DSnTCT
DSnTDT DSnTWT DSnLSTRT
New variables added to CICXMR (Transaction Manager):
(STID=11):
XMRAMISM='ACTION*MISMATCHES'
XMRFAIT ='FORCED*ACTION*INDOUBT*TIMEOUT'
XMRFANW ='FORCED*ACTION*NO WAIT ABILITY'
XMRFAOP ='FORCED*ACTION*OPERATOR'
XMRFAOT ='FORCED*ACTION*OTHER'
XMRFATXN='FORCED*ACTION*TRANDEF'
XMRIACTN='INDOUBT*ACTION*COMMIT OR*BACKOUT?'
XMRITOV ='INDOUBT*TIMEOUT*VALUE*MINUTES'
XMRIWAIT='INDOUBT*WAITS'
XMRIWTOP='INDOUBT*WAIT*OPTION?'
New variables added to CICCONSR (ISC/IRC stats):
(STID=52):
A14ACCM ='ACCESS*METHOD'
A14AICT ='LOCAL*CONNECTION*CREATE*TIME'
A14AIDT ='LOCAL*CONNECTION*DELETE*TIME'
A14EFLGS='PROTOCOL'
A14EPRMN='RECEIVE*SESSION*COUNT'
A14ESECN='SEND*SESSION*COUNT'
A14ESID ='CONNECTION*NETNAME'
A14E1RY ='PRIMARIES*CURRENTLY*USED'
A14E2RY ='SECONDARIES*CURRENTLY*USED'
A14GACT ='GMT*CONNECTION*CREATE*TIME'
A14GADT ='GMT*CONNECTION*DELETE*TIME'
New variables added to CICCONMR (ISC/IRC stats)
(STID=76):
A20ECONL='CURRENT*CNOS*CONTENTION*LOSERS'
A20ECONW='CURRENT*CNOS*CONTENTION*WINNERS'
A20ELMAX='MAX*SESSION*COUNT'
A20EMAXS='CURRENT*MAX*SESSION*COUNT'
A20EMCON='MAX*CONTENTION*WINNERS*ACCEPTABLE'
A20E1RY ='PRIMARIES*CURRENTLY*USED'
A20E2RY ='SECONDARIES*CURRENTLY*USED'
New variables added to CICFCR (File Control Statistics)
(STID=67):
A17DSBRU='BROWSE*FOR*UPDATES'
A17RLSWT='RLS*REQUEST*WAIT*TIMEOUTS'
New variables added to CICTCR (Term Control Statistics)
(STID=34):
A06GOFTM='AUTOINSTALL*LOGOFF*GMT*TIME'
A06GONTM='AUTOINSTALL*LOGON*GMT*TIME'
A06OFFTM='AUTOINSTALL*LOGOFF*LOCAL*TIME'
A06ONTM ='AUTOINSTALL*LOGON*LOCAL*TIME'
A06SYSID='OWNING*SYSID OF*TERMINAL*OR SESSION'
New variables added to CICDQG (TDQUQUE Global Stats)
(STID=45):
A11ACNAL='CURRENT*CONCURRENT*BUFFER*ACCESS'
A11ACNWT='CURRENT*BUFFER*WAITS'
A11ACNIU='CURRENT*BUFFERS*CONTAINING*DATA'
A11SCNAL='CURRENT*CONCURRENT*STRING*ACCESS'
A11SCNWT='CURRENT*STRING*WAITS'
A11ACTCI='CONTROL*INTERVALS*IN*USE'
New variables added to CICTSQ (TSQUQUE Global Stats)
(STID=48):
A12SHPDF='SHARED*POOLS*DEFINED'
A12SHPCN='SHARED*POOLS*CONNECTED TO'
A12SHRDS='SHARED*READ*REQUESTS'
A12SHWTS='SHARED*WRITE*REQUESTS'
New dataset CICRMG (Recovery Manager Global) (STID=99):
RMGCSHIN='CURRENT UOWS*SHUNTED FOR*INDOUBT'
RMGCSHRO='CURRENT UOWS*SHUNTED FOR*RO COMMIT'
RMGCSHTI='CURRENT DURATION*SHUNTED FOR*INDOUBT'
RMGCSHTR='CURRENT DURATION*SHUNTED FOR*RO COMMIT'
RMGIAFNW='TOTAL FORCED*INDOUBT*ACTIONS*NOWAIT'
RMGIAFOP='TOTAL FORCED*INDOUBT*ACTIONS*OPERATOR'
RMGIAFOT='TOTAL FORCED*INDOUBT*ACTIONS*OTHER'
RMGIAFTI='TOTAL FORCED*INDOUBT*ACTIONS*TIMEOUT'
RMGIAFTR='TOTAL FORCED*INDOUBT*ACTIONS*TRANDEF'
RMGIAMIS='TOTAL*INDOUBT*ACTION*MISMATCHES'
RMGNWMRO='TOTAL*FORCED*NO WAITING*IN MRO'
RMGNWOTH='TOTAL*FORCED*NO WAITING*IN OTHER'
RMGNWRMI='TOTAL*FORCED*NO WAITING*IN RMI'
RMGNWTD ='TOTAL*FORCED*NO WAITING*IN TD'
RMGNW61 ='TOTAL*FORCED*NO WAITING*IN LU61'
RMGRESYN='RESYNCH*RONISATIONS'
RMGSYBWD='SYNCPOINTS*BACKWARD'
RMGSYFWD='SYNCPOINTS*FORWARD'
RMGTSHIN='TOTAL UOWS*SHUNTED FOR*INDOUBT'
RMGTSHRO='TOTAL UOWS*SHUNTED FOR*RO COMMIT FAIL'
RMGTSHTI='TOTAL DURATION*SHUNTED FOR*INDOUBT'
RMGTSHTR='TOT DURATM*SHUNTED FOR*RO COMMIT FAIL'
New dataset CICLGR (Log Manager Journal Stat) (STID=93)
LGRBFLSH='BUFFER*FLUSH*REQUESTS'
LGRBYTES='BYTES*WRITTEN'
LGRJNLNM='JOURNAL*NAME'
LGRJTYPE='JOURNAL*TYPE'
LGRSTREM='LOG*STREAM*NAME'
LGRWRITS='JOURNAL*WRITES'
New dataset CICNQG (Enque Manager Global) (STID=96)
NQGCNQRT='CURR DUR*ENQUEUES*RETAINED'
NQGCNQSR='CURRENT*ENQUEUES*RETAINED'
NQGCNQSW='CURRENT*ENQUEUES*WAITING'
NQGCNQWT='CURR DUR*ENQUEUES*WAITING TIME'
NQGPOOL ='ENQ*POOL*ID'
NQGTIRJB='IMMEDIATE*REJECTED*ENQBUSY'
NQGTIRJR='IMMEDIATE*REJECTED*ENQ RETAINED'
NQGTNQRT='TOT DUR*ENQUEUES*RETAINED*WAITED'
NQGTNQSI='TOTAL*ENQUEUES*ISSUED'
NQGTNQSR='TOTAL*ENQUEUES*THAT WERE*RETAINED'
NQGTNQSW='TOTAL*ENQUEUES*WAITED'
NQGTNQWT='TOT DUR*ENQUEUES*WAITED'
NQGTWPOP='WAITING*ENQS*PURGED BY*OPERATOR'
NQGTWPTO='WAITING*ENQS*PURGED BY*TIMEOUT'
NQGTWRJR='WAITING*ENQS*REJECTED*RETAINED'
New dataset CICLGS (Log Manager Logstream) (STID=94)
LGSBRWRD='LOG*BROWSE*READS'
LGSBRWST='LOG*BROWSE*STARTS'
LGSBUFAP='BUFFER*APPEND*REQUESTS'
LGSBUFWT='WAITS*DUE TO*BUFFER*FULL'
LGSBYTES='BYTES*WRITTEN'
LGSCUFWT='CURRENT*FORCE*WAITERS'
LGSDELET='LOG*DELETES'
LGSPKFWT='PEAK*FORCE*WAITERS'
LGSRTRYE='RETRYABLE*ERRORS'
LGSSTREM='LOG*STREAM*NAME'
LGSTFCWT='TOTAL*FORCE*WAITS'
LGSWRITS='LOG*WRITES'
Change 14.208 DB2 datasets DB2GBPST and DB2GBPAT contained repeated obs
VMACDB2 for Global Buffer Pool zero, with no others output; the
Aug 29, 1996 offset was not incremented. After the %INCLUDE of member
EXDB2PST, insert : OFFQBGL=OFFQBGL+LENQBGL; After the
%INCLUDE of EXDB2PAT insert OFFQBGB=OFFQBGB+LENQBGB;
Thanks to Bertolotti Emmanno, Banca Commerciale Italiano, ITALY
Thanks to Burani Daniela, Banca Commerciale Italiano, ITALY
Change 14.207 Support for Boole & Babbage's PRO/SMS replacement for
EXPROSMS STOPX37 SMF record, a complete rewrite but with almost
IMACPROS all of the same variables in dataset TYPEPROS instead
TYPEPROS of TYPEX37.
VMACPROS
Aug 27, 1996
Thanks to Katrina Le, First Virginia Services, Inc, USA.
Change 14.206 Logic for IFCID=231 was wrong. Replace the statements
VMAC102 LENTRY=(QW0231NM-4)/QW0231RN; DO _I_=1 TO QW0231RN;
Aug 27, 1996 with LENTRY=52;NENTRY=(QW0231NM-4)/LENTRY;DO...TO NENTRY;
Caused INVALID DATA messages, and trashed T102S231 data.
Thanks to Ted Blank, IBM, USA.
Change 14.205 The RMF report REPORT=CHAN was always a summary report;
ANALRMFR with this change, a detail report is produced when an
Aug 27, 1996 INTERVAL= is specified, a summary if not.
Change 14.204 The deaccumulattion of DB2STAT0, DB2STAT1 and creation of
DIFFDB2 DB2STATS was move to the end of member DIFFDB2, and the
Aug 27, 1996 code rearranged so that the %INCLUDE of (EXDB2STS) is the
last physical statement in that data step. In this way,
a sophisticated user can add code in EXDB2STS to do their
own summary of DB2 data, after all of the DB2 statistics
datasets have been deaccumulated. In Pierre's case, he
wanted to extract fields from DB2STATR and DB2STATS and
merge with DB2STATS; now he can do that within EXDB2STS.
Thanks to Pierre Liu, Deere and Company, USA.
Change 14.203 Cosmetic. Duplicate variables in KEEP= list were removed
several in members TYPETMON, VMAC110, VMAC7072, VMAC79, VMAC80A
Aug 27, 1996 VMACCOMP, VMACCTLG, VMACCTLT, VMACMWUX, VMACNOAM,
VMACNSPY, VMACQAPM, and VMACTPX.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.202 Cosmetic. Duplicate labels in VMACACHE were deleted.
VMACACHE
Aug 27, 1996
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 14.201 Change 14.152 revised IMF processing to allow for use of
IMACCIMS tape for large IMS files, but the _KIMFTRN reference in
TYPECIMS TYPECIMS must be deleted, as changes to CIMSTRAN are now
Aug 27, 1996 controlled by _KIMFTRX, not _KIMFTRN, which is no longer
defined. Comments in IMACCIMS clarify their usage.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 14.200 The label for TYPE71 variables SHPxxxAV='MAXIMUM should
VMAC71 be SHPxxxAV='AVERAGE for these new shared page group
Aug 27, 1996 counters.
Thanks to Tim Vanderhook, Fidelity Systems, USA.
Change 14.199 READDB2 required a ddname of PDB (and worked fine as long
READDB2 as one was present), because the _LDB2STR macro was not
Aug 26, 1996 redefined in READDB2. Find the two _LDB2STB macro defs,
replicate each, and change STB to STR, STATB to STATR.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.198 Variable AVGMEMSZ was not kept in TYPE72GO dataset. This
VMAC7072 metric, MSOUNITS based, is a poor indicator of memory,
Aug 26, 1996 but it was not my intention to drop it. It is kept now.
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 14.197 Support for Landmark's TMON/DB2 Version 3 (INCOMPATIBLE).
EXTMDDF The Statistics Interval data TMDBDA1 has 33 new variables
EXTMDDF inserted, and 50 new variables were inserted into TMDBDAB
IMACTMDB dataset. The Accounting data TMDBDB2 has 36 variables
VMACTMDB inserted, 9 new variables in TMDBDBB, 1 new in TMDBDBF,
Aug 26, 1996 6 new in TMDBDBK, and a new dataset, TMDBDF, is created
for the 'DF' record type. Only the 'DA' and 'DB' records
have been validated with Version 3 data. Test data is on
hand for the 'DC','DD','DF','BB','BH', and 'BI' records,
but DSECTs were provided only for DA and DB records. If
there is a need, additional record types will be decoded.
Change 14.196 MXG 14.05-08 only. INVALID DATA FOR R744FCTM and FCSQ
VMAC74 because those two fields, added by Change 14.165, are not
Aug 23, 1996 always there. After INPUT of R744FSQU, insert
@; IF SMF744FL GE 100 THEN INPUT
so they are only INPUT when present in the record!
See Change 14.273.
Change 14.195 Dataset DB2STATR outputs the first QWHSLOCN segment
VMACDB2 NRQLST times, because the OFFQLST pointer was not
Aug 23, 1996 incremented. Insert: OFFQLST=OFFQLST+LENQLST;
immediately before the line reading:
END; /* END TRACE SECTION FOR TYPE 100 SUBTYPE 0 */
But then DIFFDB2 deleted all but the first obs, so the
number of observations was way off too! This error also
caused remote counts to be wrong in ANALDB2R.
Thanks to Pierre Li, Deere & Company, USA.
Thanks to Carl Stotmeister, Deere & Company, USA.
Thanks to Ralph Baechle, Deere & Company, USA.
Change 14.194 MXG 14.05-14.06. DB2STATB dataset will have extra obs
DIFFDB2 that should not have been OUTPUT. Change 14.167 added
Aug 23, 1996 protection for IBMs skipping QWHSISEQ, but four lines
IF SEQCHECK NE 1 ... must be IF SEQCHECK GE 1 ...
to protect for change in Buffer Pool ID, which creates a
negative value in variable SEQCHECK and should not have
been output. A more robust algorithm, testing for change
in QBSTPID was added, and dataset DB2STATR had the same
exposure and was revised to protect for change in
QLSTLOCN in the deaccumulation logic.
Thanks to Tom Parker, Hogan Systems, USA.
Change 14.193 The second occurrences of IOERTMPC and IOERPRMC should be
VMACCTLT spelled IOEWTMPC and IOEWPRMC, in both the Label
Aug 20, 1996 statement and in the INPUT statement.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.192 MXG 14.06 test stream only. In JCLTEST6 and JCLUXRE6,
JCLTEST6 step TESTOTHR, DD DUMMY for //TANDCTRL and //TANDLINE
JCLUXRE6 were missing, and in JCLUXRE6, //XPMODS was misspelled
Aug 20, 1996 as //XPUMODS.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
====Changes thru 14.191 were included in MXG 14.06 dated Aug 20, 1996===
Change 14.191 MXG 14.05 only. ERROR 228-185 INFORMAT $PIB IS UNKNOWN in
VMAC74 BUILDPDB, if you have tailored BUILDPDB to process the
Aug 19, 1996 CRR Cache RMF Reporter SMF records (VMACACHE). Change
14.152 to VMAC74 incorrectly INPUT RTRNCODE $CHAR2.
but that line must be changed to RTRNCODE &PIB.2.
to be consistent with VMACACHE.
Thanks to Damian Stevenson, PMSA, AUSTRALIA.
Thanks to Johnny Allen, Yellow Freight, USA.
Change 14.190 Minor. The count of reports requested was too high by
ANALCISH one.
Aug 17, 1996
Change 14.189 Enhancements to ANALRMFR for IBM-like RMF reports.
ANALRMFR -Shared Device Activity Report is complete ( SDEVC ).
Aug 17, 1996 This report will not contain any Devices that were
OFFLINE or have zero values at time of the interval, as
they are not kept in the MXG PDB.TYPE74 data set.
-Channel Activity Report, updates for MVS/ESA 5.1, the
addition of SMF73CPD adds new channel path descriptions.
Workload Activity Report-Goal Mode, REPORT=WLMGL is
-installed along with a new parameter RPTOPT=WGPER, which
will allow for report selection level. See comments
within ANALRMFR for more details. This report will not
contain any Policies that have all values of zero at end
of interval, as they are not kept in the MXG PDB.TYPE72GO
data set.
Change 14.188 CICINTRV is now restored to the pre-MXG 14.04 logic. In
CICINTRV MXG 14.04 the new "CICINTRZ" logic replaced CICINTRV, but
Aug 16, 1996 CICINTRZ was prematurely released (it creates incorrect
data in some situations, and it stopped creating the
PDB.CICEODRV dataset which is needed for CICS Shutdown
reports). However, the old CICINTRV logic was also wrong
for CICS 4.1 data (because multiple CICLDG observations
were being kept, which caused multiple observations in
datasets it created), so this CICINTRV member was fixed
to keep only the first CICLDG observation, which solved
it error. CICINTRZ ultimately will replace CICINTRV, as
it will create true interval data from the multiplicity
of statistics events (INT,REQ,USS,RVR,EOD) in CICINTRV
and the End of Day in CICEODRV, but until it is fully
validated, it is safer to return to the simpler logic.
So this change negates change 14.132. Additionally
Change 13.154 was removed from this CICINTRV. It added
an INCLUDE of IMACCICS inside CICINTRV (so you did not
have to include IMACCICS before you invoked CICINTRV),
but that change prevented ANALCISH from re-defining the
IMACCICS macros, which is required, so the cosmetic move
to make it easier lost out, and you will have to include
IMACCICS before you invoke CICINTRV if you ever get that
deep in creating your own MXG job for CICS processing.
Change 14.187 Support for Tandem Controller Data and Line Data creates
EXTANCTL two new datasets:
EXTANLIN Dataset INFILE Description
IMACTAND TANDCTRL TANDCTRL Controller statistics
TYPETAND TANDLINE TANDLINE Line statistics.
VMACTAND You will need to add DD statements for TANDCTLR/TANDLINE
Aug 15, 1996 (at least with DD DUMMY) if you do not wish to process
these data, as MXGs TYPETAND will try to read all five
Tandem data sources that are now supported.
Thanks to MH, Allied Irish Bank, IRELAND
Thanks to Joe Fleischmann, U.S. Bancorp, USA.
Change 14.186 Steve Franklin's code to read Network General Sniffer's
ADOCSNIF data records! Sniffer is a hardware monitor attached to
IMACSNIF your network that sees every frame and can be programmed
TYPESNIF to filter, decode and create data records. This code
VMACSNIF reads the Sniffer data, as documented in Steve's article
Aug 15, 1996 "Deriving response time of Client/Server applications",
in "Capacity Management Review", Volume 24, No 7, July
1996, published by Demand Technology (subscribe or buy
the back issue by calling 941 261 8945).
One Sniffer monitor on a LAN/WAN segment sees all of the
frames on that segment, capturing source and destination
addresses plus datastream sequence and acknowledgement
numbers plus the response times and traffic volume, plus
information from the data stream itself, so you can
recognize transactions and decompose their response time.
Several techniques for transaction identification are
discussed. Data from multiple Sniffers is combined to
measure each of the response components across multiple
segments; three Sniffers measured a PC client talking via
two WAN segments to an Oracle database in the case study.
This code is functional, but does not (yet?) have the
normal MXG embellishments (Labels, MXG-names, etc.)
Should there be enough interest, I will doll it up later.
If you have a Sniffer monitor, and you must measure and
understand the transaction response components in your
C/S transactions, this may well be your salvation, but
the analysis is neither canned nor straightforward. You
will need to read the paper and SAS code to understand
how to tailor these sample programs for your environment,
and you best have some good knowledge of the applications
you are measuring! If you also use a script (or modify
the application?) to issue calls that define the start
and end of a logical business transaction, those events
are capturable so you can get true business transaction
response time. You can also capture SQL statements that
are used in Client/Server applications and parse them to
identify TABLE names and WHERE conditions so that network
response time can be decomposed according to specific SQL
statements or RPCs (Remote Procedure Calls); that might
be sufficient for recognition of a business transaction
if it always begins with a unique call and thus avoid the
application modifications or script wraps. There is lots
of opportunity here; this is pretty powerful stuff!
Thanks to Steve Franklin, RGI, Inc, USA.
Change 14.185 VM Print sent to JES2 is now merged in PDB.JOBS with the
BUILDPDB Purge record for these "Print-only" JES2 jobs. Before,
BUILD005 MXG sent the type 26 data to PDB.NJEPURGE, and the type 6
Aug 15, 1996 record(s) were spun (awaiting for the non-existent purge
record) for SPINCNT days, and then later the type 6 data
was output in PDB.PRINT (but with no accounting fields)
and a sparce observation in PDB.JOBS was created. This
change makes the PDB.JOBS data complete and timely for
print-only jobs. The change itself was quite simple:
In the logic to build PDB.NJEPURGE, remove the test for
INREASON='SR' (so those records are output to TYPE26J2),
and in the logic to build PDB.JOBS, change the test to:
IF SUBSTR(INBITS,5,1)='P' AND INREASON NE 'SR' THENDO;
(so that ABEND values of JCL or CRSH are not set for
these print jobs, since they do have no JSTRTIME/JENDTIME
values, because they did not execute on MVS). Note that
these print-only jobs can be identified in PDB.JOBS by
variable INREASON='SR', and that the values of all of the
variables from the type 30 records will be missing.
Peter also pointed out that new options on the VM TAG
command (used to send print to MVS) now allow you to
cause the VM USERID to be sent to MVS and VM USERID will
be the JOB name, rather than the old RSCSnnnn JOB name.
Thanks to Peter J. Jansen, Bank for International Settlements, SWITZ.
Change 14.184 Variable TRANTYPE was increased to two bytes in CICS 4.1.
VMAC110 Change 13.296 changed FORMATS, but the VMAC110 change was
Aug 15, 1996 not migrated into the real MXG library (IBM confidential
requires that I keep dual source libraries until GA, and
I forgot to make the update in both places!).
For CICSTRAN, move TRANTYPE from $1 line to $2 line in
the LENGTH statement, and in the SMFPSRVR GE 41.0 INPUT,
change +3 TRANTYPE $CHAR1. to TRANTYPE $CHAR2. +2.
For CICSEXCE, conditional logic was added.
Thanks to Ove Dall-Hansen, CODAN Insurance A/S, DENMARK.
Change 14.183 TYPE7204 (Goal Mode RMF Monitor III) variable TRANS was
VMAC7072 too small causing AVGELPTM to be way too large because
Aug 13, 1996 variable TRANS should be INPUT as &RB.8. and not &RB.8.6.
This is a continuation of Change 14.122.
Thanks to Tom Parker, CSC, USA.
Change 14.182 Support for New Dimension Software's CONTROL-T Tape
EXCTLTDS Management records creates two datasets:
EXCTLTVL CTLTDSN - Data Set Record
IMACCTLT CTLTVOL - Volume Record
TYPECTLT A number of formats are created to decode fields in the
VMACCTLT data. The volume record has a repeating vault section,
Aug 13, 1996 but test data had only one (of a maximum of three), so
currently only the first vault segment is output.
Thanks to Paul Hassett, Department of Transportation, USA.
Change 14.181 TANDEM variables were misspelled in two places.
VMACTAND Change C2WMISS=C2RMISS/DURATM; to C2RMISS=.... and
Aug 12, 1996 Change C3WMISS=C3RMISS/DURATM; to C3RMISS=....
Thanks to Steve Smith, BGS, USA.
Change 14.180 TYPE72GO Goal Mode dataset did not contain PERFINDX, the
VMAC7072 performance index. Logic was inserted to calculate this
Aug 12, 1996 index, to label it, and to keep it in TYPE72GO.
Thanks to Kevin Carpenter, First of America, USA
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.179 Support for SoftAudit Version 5.1 (INCOMPATIBLE, but only
EXSFTAL because MXG now requires //XPMODS DD statement; if you
IMACSFTA do not have Version 5.1 installed, then use DD DUMMY).
VMACSFTA The //XPMODS flat file (Created by SoftAudit's extract
Aug 12, 1996 program) is now read to create the new MXG dataset
SOFTMODS to describe the Installed Load Module File.
Change 14.178 The SMF Simulator now tests a CISIZE of 18432, which may
ANALSMF be better than 16K on 3390s, as 3 blocks fit per track.
Aug 12, 1996
Change 14.177 In VMXGSUM invocations, if DESCENDING was used in the
VMXGSUM SUMBY=LIST and KEEPALL=NO was used (default), the parse
Aug 12, 1996 logic did not recognize the DESCENDING attribute, which
could cause NOT SORTED conditions. Now the parser does.
Change 14.176 TRNDTALO has been redesigned to "SPIN" allocations that
TRNDTALO are active at the time SMF data is dumped. Comments in
Aug 12, 1996 the member describe the new algorithm designed to fix the
end effects. This still is a circumvention for the basic
problem, that allocation records are only written at the
end of allocation; a redesign of the ASMTAPES monitor to
create interval allocation records will ultimately solve
the problem of counting tape drives for good, but as the
comments describe, only a very small number of jobs are
encountered with hanging allocations, so the new logic is
definitely an improvement.
Thanks to David Childress, Lowe's Companies, Inc, USA.
Change 14.175 Using ANALCNCR, if you did specify an output dataset and
ANALCNCR you also requested reports, you received a DATASET NOT
Aug 12, 1996 FOUND and may get two prints of the Summarized output.
Thanks to Tom Elbert, John Alden, USA.
Change 14.174 DB2 message "VMACDB2 ERROR ... QWHSIID=230 UNEXPECTED"
VMACDB2 due to MXG error. Find IF QWHSIID=230 THEN SUBTYPE=3;
Aug 12, 1996 and add "AND SUBTYPE NE 3" to the next IF statement.
The impact of this error message was that DB2 statistics
observations were not output in DB2GBPAT.
Thanks to John Rosser, Springs Industries, USA.
Change 14.173 Reserved Change Number.
Aug 10, 1996
Change 14.172 Variable EXECTM in TYPE30_V and PDB.SMFINTRV datasets was
VMAC30 wrong for steps that created only a subtype 3 (i.e., they
Aug 10, 1996 did not run long enough to create a subtype 2 interval).
Change the equation EXECTM=INTETIME-INTBTIME to read:
IF SUBTYPE=3 AND INTBTIME LT LOADTIME THEN
EXECTM=INTETIME-LOADTIME;
ELSE EXECTM=INTETIME-INTBTIME;
Thanks to Jean Quinkert, Inland Steel, USA.
Change 14.171 Support for MODEL204 Release 3.2.1 (INCOMPATIBLE) inserts
IMACM204 new fields in the Logoff and the Since-Next records.
VMACM204 This support is based on CCS's Early Warning 006 but has
Aug 9, 1996 not yet been tested with real 3.2.1 data. The new default
for _M204VER in IMAC204 is now 3.2 instead of 3.0.
Aug 16: Variable M24DKAR was inadvertently deleted from
the INPUT statement for LOG records in early code.
Thanks to Allan Rollason, SAS Europe, GERMANY.
Change 14.170 More RACF Reports for Command Events can be produced from
EXTY8008 nine new TYPE80nn datasets from member TYPE80A:
EXTY8012 Dataset EVENT Command
EXTY8015 TYPE8008 08 ADDSD
EXTY8016 TYPE8012 12 ALTGROUP
EXTY8017 TYPE8015 15 DELDSD
EXTY8018 TYPE8016 16 DELGROUP
EXTY8020 TYPE8017 17 DELUSER
EXTY8021 TYPE8018 18 PASSWORD
EXTY8024 TYPE8020 20 RALTER
IMAC80A TYPE8021 21 RDEFINE
VMAC80A TYPE8024 24 SETROPTS
Aug 8, 1996 Because IBM documentation of RACF records is not complete
(undocumented fields, conditional fields), I can only code
if I have data records. If the dataset TYPE80CM contains
any observations, it means you have events I have not seen
before. If you will PROC PRINT DATA=TYPE80CM, you can see
which events exist, and that dataset contains the RECNUM
in your SMF data; use this program to print a hex dump of
those records: DATA;INFILE SMF;INPUT;IF _N_= recnum;LIST;
and send that output with the PROC PRINT for enhancement.
Thanks to V.J. Picotte, Key Services, USA.
Change 14.169 JES3 MDS (Main Device Setup) tape fetch and mount counts
IMACPDB are now captured in variables TAPFETCH and TAPEMNTS in
BUILDPD3 PDB.JOBS dataset created by the BUILDPD3 JES3 PDB. These
BUIL3005 counts have been available in dataset PDB.TYPE25, but now
BUILDPDB the BUILDPD3/BUIL3005 logic sums the TYPE25 counts into
BUILD005 PDB.JOBS. A new dataset SPIN.SPIN25 is also created in
Aug 7, 1996 the SPIN library (and copied into the PDB for backup).
For JES3-sites, if you have tailored your IMACPDB member
in your "USERID.SOURCLIB" for your BUILDPD3 job, this
change is INCOMPATIBLE in that you must re-tailor those
IMACPDB changes, starting with this IMACPDB member; if
you miss this instruction, you will get errors on the log
that variables READTIME JOB JESNR are not in WORK.TYPE25!
This enhancement was not straightforward, because IBM
does not include JESNR in the type 25 record, so it
matches type 25's with type 30_1 initiation records to
add JESNR to TYPE25 before the MERGE. In IMACPDB the
macro _PDB25 contains JESNR in the list, even though
JESNR does not exist in the SMF record, because that
macro is used again later in BUILDPD3 when there has
been created a JESNR in TYPE25.
This change did not add variables TAPFETCH and TAPEMNTS
to PDB.SPUNJOBS dataset (but I will later, if required).
Unrelatedly, the creation of PDB.SMFINTRV was enhanced;
by changing IF ININTRV THEN OUTPUT; to IF ININTRV; and
relocating the statement after the SET statement, code is
bypassed when there are no TYPE30_V observations. This
change was also propagated into JES2 BUILDPDB/BUILD005.
And Change 13.241, which added the %INCLUDE of IMACSPCK
had been overlooked in BUIL3005, but is now added.
Thanks to Alan McBain, National Westminister Bank, ENGLAND.
Change 14.168 Support for Omegamon/VTAM V200 (INCOMPATIBLE, four bytes
EXOMVLU were inserted and eight new trend subtypes are created.)
EXOMVMPG MXG creates these new datasets:
EXOMVMPS IRNUM DATASET Description
EXOMVNCC 7 OMVTMPCG MPC Group
EXOMVNTL 8 OMVTMPCS MPC Subchannel
EXOMVNTP 9 OMVTNCPC NCP CCU
EXOMVPU 10 OMVTSDLC SDLC/BSC Line
EXOMVSDL 11 OMVTPU PU/Cluster
FORMATS 12 OMVTLU LU/Terminal
VMACOMVT 13 OMVTNTRP NTRI Physical Link
Aug 6, 1996 14 OMVTNTRL NTRI Logical Link
but only subtypes 9 and 10 have been validated with data,
(and ON09CU and ON09CF look suspicious in OMVTNCPC).
Forty new exception conditions were added that are now
recognized and decoded by new values for $MGOMVEX format
that is used in dataset exception dataset OMVTEXCE.
Thanks to Harry Olschewski, dvg Hannover, GERMANY.
Thanks to ??? , Sparkassen-Rechenzentrum, GERMANY.
Change 14.167 Some intervals may be missing in DB2STATS, DB2STAT0 and
DIFFDB2 DB2STAT1 in DB2 4.1, because IBM changed QWHSISEQ without
Aug 3, 1996 notice. Statistics interval records contain accumulated
counters, so MXG's DIFFDB2 code must sort records and
then subtract counters in adjacent records to create the
interval statistics. To make sure only adjacent records
are output, the IFCID Sequence Number, QWHSISEQ, is used
to validate that records are adjacent. However, DB2 4.1
now writes records for adjacent intervals with skipped
values of QWHSISEQ (109,110,111,113,115,116), which made
MXG's validation logic to not output those observations.
In addition to adjacency validation, the MXG QWHSISEQ
logic also deleted the first record from each subsystem
(the first record found cannot be output, unless it is
also the startup, QWHSISEQ=1, because there is no prior
record for deaccumulation), so the new logic now protects
for first record found. Change the four occurrences of:
SEQCHECK=DIF(QWHSISEQ); DROP SEQCHECK;
IF QWHSISEQ GE 1 AND SEQCHECK EQ 1 THEN DO;
DIFFDBxx=1;
%INCLUDE SOURCLIB(EXDB2ST0);
END;
to read (change DIFFDBxx=1 in each of the four sets):
LENGTH PREVSSID $4;
SEQCHECK=DIF(QWHSISEQ);
IF SEQCHECK GE 1 AND PREVSSID EQ QWHSSSID THEN DO;
DIFFDBxx=1;
%INCLUDE SOURCLIB(EXDB2ST0);
END;
ELSE DO;
PREVSSID=QWHSSSID;
RETAIN PREVSSID;
END;
Note inserted Sep 25: the previous code was printed
and implemented incorrectly until Change 14.230. The
code stub above has been corrected to the way it
should have been.
While this change prevents deletion of good intervals,
it opens a new exposure if DB2 records are not written
for an interval (if SMF is blocked DB2 does not retry).
Because SEQCHECK can't be used, MXG will deaccumulate
several interval's data into one interval, causing high
values (though not necessarily high rates) in that obs.
To help isolate data problems, the variable SEQCHECK is
now kept in the DB2STATx datasets. SEQCHECK is one if
QWHSISEQ is adjacent, and otherwise is more than one.
I intend to open a problem with IBM to see if this was
an intentional change or an inadvertent error, so this
change may be revised if IBM admits to an error, but with
DB2 4.1 now skipping QWHSISEQ values, this change is
required until IBM guarantees adjacency of QWHSISEQ.
Thanks to Pierre Li, Deere and Company, USA.
Change 14.166 Use of permanent versus temporary ARRAY statements costs
VMAC78 big! Changing the ARRAY statements added by 14.121 from
Jul 27, 1996 ARRAY PCTALLBZ {4096} 4 PCTA0001-PCTA4096;
ARRAY LCUIORAT {4096} 4 LCUI0001-LCUI4096;
to read:
ARRAY PCTALLBZ {4096} 4 _TEMPORARY_;
ARRAY LCUIORAT {4096} 4 _TEMPORARY_;
eliminated the significant increase in CPU time BUILDPDB
and TYPE78 seen in MXG 14.04 and MXG 14.05. See the SAS
Technical Note in Newsletter THIRTY on Permanent Arrays.
Change 14.165 APAR OW13536 adds new fields for the Coupling Facility
VMAC74 (RMF type 74 subtype 4 record, MXG dataset TYPE74CF)
Jul 27, 1996 that are extensively discussed in WSC FLASH 9609.
The Coupling Facility continues to be a potential serious
bottleneck if its capacity (CPU and memory) is not well
managed. IBM has added new instrumentation for that
purpose with this APAR, which was implemented compatibly.
Change 14.164 APAR OW15406 for RMF adds support for Year 2000.
VMAC73 IBM has documented that all packed decimals will contain
VMAC74 0cyydddF format, and added an expanded IODF creation date
VMAC75 (with YYYY format vice YY) field (compatibly!) to the end
Jul 25, 1996 end of the Type 73 Channel Path Control section, the Type
74 Device Control Data Section, and the Type 78 Subtype 3
Control Section for ES/9000 CPUs. MXG detects existence
and uses the YYYY format when it is present. With this
APAR and MXG change, RMF fully supports the year 2000,
and member YEAR2000 has been updated to so indicate.
Change 14.163 APAR OW21583 announces that TCP/IP will write SMF type 6
VMAC6 record with SUBSYS=9, but no more information (APAR is
Jul 25, 1996 still open). Test for SUBSYS=9 was added, but still
await IBM documentation. This change is still open.
Change 14.162 ANALMPT invokes ANALCNCR and caused FILE WORK.SPLIT.DATA
ANALCNCR DOES NOT EXIST error (if OUTSUMRY= is not specified). To
Jul 12, 1996 correct, find the second occurrence of the statement:
PROC PRINT DATA=&OUTSUMRY SPLIT='*';
and delete that line (the second occurrence, but do not
delete the line containing DATA=OUTSUMRY, without paren).
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
Change 14.161 Cosmetic. Two titles with CPU TIM were corrected to read
ANALPROG CPU TIME.
Jul 12, 1996
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
====Changes thru 14.160 were included in MXG 14.05 dated Jul 15, 1996===
Change 14.160 TSO/MON distribution bucket values TSMPDIS1-TSMPDIS8 were
VMACTSOM not converted to seconds (divide by 38400) nor were they
Jul 12, 1996 kept, but now they are.
Thanks to Manfred Thomas, BHF-Bank, GERMANY.
Change 14.159 Documentation of the datasets created by BUILDPDB and the
ADOCPDB sort order of those datasets (from the MXG Supplement)
Jul 12, 1996 was not moved into SOURCLIB. While slightly out of date,
at least it's finally here!
Thanks to Jean Quinkert, Inland Steel, USA.
Change 14.158 Support for OS/390 Version 1 Release 2 (COMPATIBLE).
EXTY72GO MXG 13.13 and later tolerates OS/390 Release 2, but to
EXTY892 capture the several new variables and new subtypes of
IMAC89 type 74 and 89 records, MXG 14.05 is needed.
VMAC4789 -UCBNAME is now $4 in TYPE4789 (but this was not new with
VMAC7072 OS/390 - I had not noticed the new field until now).
VMAC79 -Variables SMF72SPA,SMF72SPE,SMF72SRS (shared page stats)
VMAC89 are added to TYPE72 (again, had been overlooked in 5.2).
VMAC99 -Variables R722GPI,R722TSV,R722VIN,R722VLC (shared pages)
Jul 11, 1996 are added to TYPE72MN (also overlooked in 5.2).
-Variables R724GPI,R724TSV,R724VIN,R724VLC (shared pages)
are added to TYPE7204 (also overlooked in 5.2).
-Variables R791CMNI,R791EXCT,R791SPI,R791PNV,R791PVIO (the
ASID's pages in common, VIO/Non-VIO, shared pagins) are
added to TYPE79. (also overlooked in 5.2).
-New dataset TYPE892 contains interval usage data summary
for each registered product.
-The test R723TYPE IN(1,2,4,5) in EXTY72GO was changed to
R723TYPE IN('1','2','4','5') to eliminate character
conversion (and associated SAS note).
-Variables were added to TYPE99TT and TYPE99U1 datasets.
Change 14.157 For user-written VMXGSUM invocations with INDATA= that
VMXGSUM did not have a blank between the dataset name and the
Jul 11, 1996 parenthesis, i.e., INDATA=MYDATA(IN=MYVAR), the parsing
logic failed. Use INDATA=MYDATA (IN=MYVAR), and the code
works! This change enhances the parser to accept the
dataset options in the INDATA= with or without the blank.
Thanks to Alfred Mak, Asia Pacific Technologies, SINGAPORE.
Change 14.156 Change 14.112 was revised (see text) and additional IDMS
VMACIDMS changes are necessary.
Jul 11, 1996 -In the Journal Wait segment, insert a +1 after JRLFILE is
INPUT and change the SKIP calculation to SKIP=SKIP-105;
vice 104.
-In the DBKEY Wait segment, insert +2 after DBKPGGRP and
change the SKIP calculation to SKIP=SKIP-14; vice 12.
Thanks to Martin Wieland, Neckermann B.V., THE NETHERLANDS
Change 14.155 Utility to reconstruct mainframe data from PC file. When
UDEBLOCK you download an MVS file that was VB or VBS, you had to
Jul 11, 1996 make a RECFM=U copy on MVS, then download that data to a
PC, creating a contiguous file of bytes. But you cannot
upload that PC file (perhaps to a different MVS system)
and use it, because there are no record delimiters. But
now you can upload the PC file , putting it into an MVS
file with RECFM=U, BLKSIZE=32756, and then use this new
UDEBLOCK utility to read that file and create from it a
true copy of the original VB/VBS file. The output file
of UDEBLOCK will have RECFM=U,BLKSIZE=32756, but you will
specify RECFM=VB or RECFM=VBS on the DD statement when
you read that data, and all will be well. You may not
need this utility, but I needed it to be able to move
a VB GTF file from SAS's MVS system thru my PC to my MVS
system. Check it out!
Change 14.154 Support for DB2 records written to GTF. The earlier user
REXXDB2 written utility (REXXDB2) did not always create valid DB2
UDB2GTF events from the multiplicity of 280-byte spanned segments
VMACDB2 in which DB2 data is chunked when sent to GTF.
VMACSMF That's the reason why DB2 trace data should be written
Jul 11, 1996 to SMF rather than to GTF. When you write to GTF, DB2
must stop and do a physical write to GTF for each 280
bytes of trace data! When trace data is sent to SMF,
it is in chunks of 32756 bytes and is done at CPU
speed with a Move Character Long from DB2's ASID to
SMF's ASID without any physical write delay for DB2.
The new MXG utility, UDB2GTF is written in SAS, not REXX,
and correctly reads the raw GTF trace data written by DB2
to reconstruct the spanned segments into valid events,
but its output is still in GTF format, so you must use
TYPEDB2G instead of TYPEDB2, or TYPE102G instead of
TYPE102, or you must specify INFILE=GTF with %READDB2, or
with %ANALDB2R you must specify PDB=GTF to read the data.
But not only was REXXDB2 wrong; the MXG members VMACSMF
and VMACDB2 had to be corrected as well.
REXXDB2 did reconstruct many DB2 GTF events, but it did
not handle all records correctly, and it created invalid
records for incomplete DB2 events (when the last segment
was not written because trace was restarted).
Thanks to G. Bockting, KLM Royal Dutch Airlines, THE NETHERLANDS.
Change 14.153 Major (but compatible) internal enhancement of IMF
EXIMFTRX support for large IMS transaction volumes creates new
IMACCIMS macros _LIMFTRX, _LIMFSRT and _LIMFCHA which can be set
TYPECIMS in member IMACCIMS to write temporary copies of IMS data
VMXGTAPE to tape during the "CHAINED" part of TYPECIMS logic. In
Jul 7, 1996 addition, exit EXIMFTRN was relocated to the final phase
of TYPECIMS logic, so you have complete control of the
contents of the final CIMSTRAN dataset. (New exit
EXIMFTRX for new temporary CIMSTEMP, built in first phase
from IMS log, added, but not likely needed.) Comments in
IMACCIMS describe how to use temporary tape datasets.
Lots of work under the cover in this enhancement. New
VMXGTAPE macro created to determine if a dataset name or
a libname is on tape. For DASD temporary space, PROC
DELETEs must be used to minimize the space required, but
PROC DELETEs added for DASD will fail (with ERROR!) when
DD points to tape, as SAS does not support Deletion of a
tape dataset. This required %MACROs be created and used
to decide if the DD name you chose in IMACCIMS points to
tape or DASD, and then to conditionally execute PROC
DELETE only if DASD. Not too hard, but sure cluttered
the code in TYPECIMS!
For TAPE temporary spaces, we want to reuse the tape to
minimize the number of tape drives to three, but then the
dataset name used for the reuse MUST be the same as the
first dataset on that tape (if not, SAS would read past
that first dataset on tape and only begin writing the
reuse dataset after the first dataset, which could cause
multi-volume tape when not required.
Thanks to Wolfgang Vierling, Vereinte Versicherung, GERMANY.
Change 14.152 Support for RMF Type 74 Subtype 5 Cache RMF Reporter CRR
BUILDPDB record. This new subtype 5 record replaces the user SMF
BUILDPD3 record created by IBM's CRR product. MXG created the
BUILD003 CACHE90 dataset from the user SMF record; this support
EXTY74CA creates new dataset TYPE74CA, but the variables in that
FORMATS new dataset are identical to the old CACHE90 dataset, so
IMAC74 you will need only to change references to CACHE90 to
VMAC74 TYPE74CA in your CRR report programs.
Jul 2, 1996 The subtype 5 record is standard in OS/390 Release 2 and
is retrofit in MVS/ESA 5.2.2 by APAR OW18886, in 5.1 by
APAR OW19337, and in 4.3 by APAR OW19938.
Dataset TYPE74CA is automatically created in your PDB
library by MXG's BUILDPDB/BUILDPD3 programs.
I considered using CACHE90 as the dataset name in this
new support, but any site that had already added
CACHE90 to their BUILDPDB would ABEND with this new
MXG version, as there would then be two instances of
CACHE90, one from VMACACHE and one from VMAC74. 'Tis
better for BUILDPDB to run and only have to change
your reports than vice versa! Additionally, you may
have CRR running on some systems, while you only have
the TYPE74CA on some systems, so by using a different
name you can process both records. And, there are a
few new variables created in TYPE74CA.
Thanks to Brian Currah, Performance Associates, USA.
Change 14.151 TYPE74SY variables R742SDIR and R742SSTF are flag fields
VMAC74 and should have been formatted $HEX2.
Jul 2, 1996
Thanks to Mr. Leineweber, Huels AG, GERMANY
Change 14.150 Support for DFSORT Release 13 APAR PN71337 (Compatibly)
VMAC16 added new variable ICEDSA (Size of DSA in effect) using
Jun 29, 1996 an existing reserved field. This APAR also increases the
maximum number of SORTWORKs from 32 to 100, but that has
no impact on the MXG support.
Change 14.149 In verifying the MXG supported JES2 job numbers GT 32767,
VMAC57 I discovered that variable NJENJJID had been added to the
Jun 29, 1996 JES3 type 57 record; that variable is now created.
Change 14.148 An 878 ABEND can occur because the SLOTS table was below
ASMIMSLG the 16MB line; increasing the SLOTS after the //CONTROL
ASMIMSL5 DD statement avoided expansion, but still abended. The
Jun 27, 1996 solution is to move the SLOTS table above the 16MB line
(so the GETMAIN is not constrained by your private area).
Before the MXGIMSLG CSECT statement, insert (starting in
column one):
MXGIMSLG AMODE 31
MXGIMSLG RMODE 24
In the GETMAIN statement located 25 lines after the label
GETQUEUE, change LOC=RES to LOC=ANY.
Thanks to Grant Thomson, Elf Enterprise, ENGLAND.
Change 14.147 All MXG JCL examples now specify REGION=0M to allow SAS
JCLall to use all virtual storage it needs. See SAS Technical
Jun 27, 1996 Note VI.4 in Newsletter THIRTY for discussion.
Thanks to Jeff Balch, General Electric Capital Corporation, USA.
Change 14.146 All packed decimal fields in IBM's DFSMSrmm records are
VMACEDGS now protected with the ?? modifier (to supress error msg
Jun 26, 1996 when the record contains nulls for PD fields), and all
timestamps set with DHMS() function are now set missing
(instead of zero) when they don't exist. The logic for
the security record was incorrect and was revised.
This change is still open while investigating further
recommendations from this "codeshark".
Thanks to Willi Weinberger, IDG Informationsvararbeitung, GERMANY.
Change 14.145 Almost cosmetic; several hundred lines were printed on
VMXGSUM the SAS log when VMXGSUM's KEEPALL=NO default option does
Jun 26, 1996 its thing (see MXG Technical Notes in Newsletter 30).
This change inserted OPTIONS NONOTES; and then OPTIONS
NOTES before and after the parsing logic to prevent the
printing of these notes on your SAS log.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.144 Support for Anacomp, Inc.'s XSTAR product's SMF record.
EXXSTARB Two datasets are created:
EXXSTARO XSTARBAT - Batch Session Printing
IMACXSTR XSTARDSN - Batch Session sent to a dataset
TYPEXSTR XSTARONL - Online Session
VMACXSTR
Jun 26, 1996
Change 14.143 Support for EOS - Enterprise Output Solution for MVS is
VMACWSF already contained in MXG under its old acrynym, WSF. The
Jun 26, 1996 vendor is RSD - Roger Software Development, Geneva.
Thanks to Tim Crocker, ALLTEL Information Services, USA.
Change 14.142 CICS Statistics datasets did not contain SMFPSRVR (CICS
VMAC110 Version) nor MCTMNTAD (GMT offset), although both were
Jun 26, 1996 added to CICSTRAN and CICSEXCE in MXG 13.13. Now, both
variables were added to the _CISTCMN macro so that they
will now exist in all CICS datasets.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.141 The _LHSMxxx macros (which can be used to change the data
DIFFHSM Library in which HSM datasets are stored) were not used
Jun 26, 1996 in the data steps after the PROC SORTs, so you could not
use the IMACHSM to set the location of HSM datasets.
The syntax now uses _LHSMxxx macro names throughout.
Thanks to Trevor Holland, Bank of Melbourne, AUSTRALIA.
Change 14.140 MXGSAS, the JCL Procedure to execute MXG jobs, has been
JCLADHOC enhanced with the new TAILORNG= symbolic parameter that
MXGSAS allows you to use your own PDS as the first dataset in
Jun 25, 1996 the //SOURCLIB concatenation. This new parameter is
then used in the new JCLADHOC example, which shows how
you can use IEBPUDTE to put your SAS tailoring statements
into a temporary PDS (so you don't have to EDIT a real
PDS tailoring library) for an ad hoc analysis. Also, you
end up with the JCL and SAS code in one single member so
you can go back and remember what you did in one place!
Thanks to Debbie Gould, Acxiom, USA.
Change 14.139 Divide by zero message (but no failure) in calculation of
VMAC76 INTRVAVG in TYPE76 dataset. The second equation now is:
Jun 24, 1996 IF NRSETS*SAMP_SET GT 0 THEN INTRVAVG=INTRVSUM/(...);
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 14.138 DB2 Trace records containing SQL text were inconsistent.
VMAC102 IFCID 63 created all of the text in multiple observations
Jun 26, 1996 with 200-byte variable (which is unprintable because SAS
PROC PRINT truncates instead of wrapping), and IFCIDS 124
140, 141, 142, 145, and 168 kept only the first 200 bytes
of SQL statements. Since SQL text has no limit (after
all, it is a "program"), I decided to change the length
of T102S063's existing 200-byte variable to 100 bytes per
observation, and have created six new datasets for the
other IFCIDS that contain the SQL text in 100-byte chunks
(and the common variables). New datasets T102T124,
T102T140, T102T141, T102T142, T102T145 and T102T168 are
created, with the 2nd "T" in the dataset name being the
indicator that this dataset is for the SQL text. The
segment number is in SEGSQLTX and the actual bytes of
text in the 100-byte character variable is in the
variable LENSQLTX.
The first 100 bytes of text are still output in T102Snnn
for compatibility.
A later change to ANALDB2R will be required to be print
all of the SQL text in the Audit Reports, but with this
change at least you can PROC PRINT to get all of the SQL
statements.
Thanks to Mike Majors, Residential Services Corp of America, USA.
Change 14.137 Code which was never executed was deleted. The DO group
VMAC116 IF QWHCTOKN EQ '0000 ... 00'X was never executed, as the
VMACDB2H length of QWHCTOKN is 22, but the hex string was only 16,
Jun 24, 1996 and even if it had been executed, it only stored hex zero
where hex zero had already been initialized, so that DO
group was deleted and the subsequent ELSE DO; and END;
statements were deleted around NETSNAME creation.
Thanks to Herb Strazinski, Burlington Northern Railroad Co., USA
Change 14.136 Variable ZDATE is inadvertently changed to a character
TYPEIMSA variable with value 'ZEE OBS...' because the semi-colon
Jun 21, 1996 after TRANCLAS='TRANSACTION*CLASS'; must be removed.
Thanks to Mr. Lucca, Wiener Staedtische Versicherung, GERMANY
Change 14.135 Landmark TMON/MVS spanned records are now valid and can
FORMATS be read with MXG. Prior to TMVS 1.3, the spanned records
VMACTMVS were invalid, and MXG had no choice but to skip over them
Jun 20, 1996 (and print a note on the log that records were skipped).
As promised, TMVS 1.3 now writes legitimate records that
can be read with TYPETMVS. The only change required is
to delete the entire 18 lines of the DO group:
IF LMRKFLG1 NE '..00....'B THEN DO; /*SPANNED .... */
--- 16 lines ---
END;
Also, format $MGTMVGF now decodes additional bit values
(that deal with record structure, and probably no one but
me ever need to know!). I also discovered that it and
several other formats had been overlooked when the syntax
of OTHER=(! $HEX2. !) was changed to OTHER=?< $HEX2. ?>
by Change 13.319. Now, all OTHER= are consistent.
Thanks to Wim Desmecht, DOLMEN Computer Applications MV/SA, BELGIUM.
Change 14.134 Support for HP MeasureWare for HP-UX platform. HP's MWA
ADOCMWUX replaces the HP PCS product. The MXG support for MWA
ASUMMWUX is contained in new members with the MWUX suffix instead
IMACMWUX of HPUX, so you will have to change to use TYPEMWUX vice
TYPEMWUX TYPEHPUX, but the MXG datasets created by MWA are named
VMACMWUX the same as their PCS counterparts, and variable names
EXHPUXTT were preserved (except for dropped variables), so your
Jun 17, 1996 existing PCS report programs should function without
error against the MWA-built MXG datasets.
The data records read by MXG are completely controlled by
the syntax of the HP REPORT command that extracted the
data. You must compare the REPORT command syntax in the
ADOCMWUX member with your REPORT command (or use the one
in ADOCMWUX to generate your data!). If your data was
extracted with a different REPORT syntax, then you must
change member VMACMWUX as described in ADOCMWUX. The
delimiter between HP fields is set in member IMACMWUX.
One new dataset, HPUXTRAN, transaction tracker metrics,
is created by MWA that did not exist in PCS, hence the
new EXHPUXTT exit. Note that the same exit members are
used for both PCS and MWA to output the same MXG dataset
names! Support for SUN and AIX platforms will be coded
when there is a user in need of that support.
Thanks to Alfred Holtz, Medco Data Corporation, USA.
Thanks to Thierry Van Moer, Procter & Gamble, BELGIUM.
Change 14.133 Documentation. The MVS Technical Note on differences in
ADOC30 CPUTM between interval and step records was also put in
Jun 15, 1996 ADOC30, and related variables descriptions were revised.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
====Changes thru 14.132 were included in MXG 14.04 dated Jun 13, 1996===
Change 14.132 As promised, the prior member CICINTRZ is now CICINTRV;
CICINTRV i.e., the enhancements described in Change 13.281 are now
CICINTRZ the MXG default (and the old CICINTRV is now CICINTRZ).
Jun 13, 1996 With this change, only the CICINTRV dataset is built; the
CICEODRV CICREQRV CICRRTRV & CICUSSRV datasets are no
longer created. The new logic does not impact execution
resources: CPU only went up 20 seconds (with a total
CPU time of 11min 39sec for both TYPE110 and CICINTRV
with 2132MB of SMF data) and WORK disk space only went up
by 13 Cylinders (10MB). The increase in virtual storage
was only 600K, up to 15204K, but this is still much less
than BUILDPDB requires, so this new CICINTRV won't cause
your BUILDPDB to die with an 80A ABEND!).
A CICS Technical note on the CICINTRV enhancements will
soon be written. See Change 14.188 which reverses this.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.131 Support for APAR PN78083 required no change to MXG. The
VMAC42 APAR redefine's PRODLVL's 2 bytes as two 1 byte fields
Jun 12, 1996 Product Level, Product Sublevel), but PRODLVL is not even
a kept variable, and if it is ever needed in the future,
its two bytes can always be individually tested.
Change 14.130 INVALID DO LOOP error because Change 13.044 was not made
TRNDTALO to this member to protect when ALOCSTRT or ALOCEND are
Jun 11, 1996 missing. The IF statement in the first data step needs:
OR ALOCSTRT=. OR ALOCEND=.
to be added, i.e., make TRNDTALO look like ASUMTALO.
Thanks to David Childress, Lowe's Companies, Inc.
Change 14.129 Support for IMS 5.1 APAR PN76410 extended prefix segment.
ASMIMSL5 With this APAR, LOGONID variable in IMSTRAN is missing.
Jun 9, 1996 To correct, change ASMIMSL5 after label P001000M to make
the code look like this:
P001000M DS 0H old
CLI 2(R4),X'84' IS THIS THE LU6 SEGMENT old
BNE P001000N BRANCH IF NOT (was BNE DROPMAP)
LA R4,MSGLU6ND(R4) BUMP PAST THE SEGMENT old
B P001000K BRANCH TO TEST FOR RACF old
P001000N DS 0H SUPPORT FOR PN76410 new
CLI 2(R4),X'86' IS THIS THE EXT PFX SEGMENT new
BNE DROPMAP BRANCH IF NOT new
USING MSGEPHDR,R4 new
TM MSGEPFL1,MSGESEC IMBEDDED SECURITY SEGMENT? new
BZ DROPMAP BRANCH IF NOT new
LH R2,MSGEPTL LNGTH OF ALL EMBEDDED SEGS new
AR R2,R4 END OF EXTENDED SEGMENT new
P001000P LH R1,0(R4) LENGTH OF THIS SEGMENT new
AR R4,R1 NEXT SEGMENT new
CR R4,R2 HAVE WE REACHED END ? new
BNL DROPMAP BRANCH IF YES new
CLI 2(R4),X'88' SECURITY SEGMENT? new
BNE P001000P BRANCH IF NOT new
DROP R4 new
USING MSGSEC,R4 new
MVC LOGONID,MSGRACUS MOVE IN THE LOGONID new
MVC ORGENT(8),MSGSAFNM MOVE IN ORGENT/INCONT new
DROP R4 new
B DROPMAP new
EJECT old
Thanks to Grant Thomson, Elf Enterprise Caledonia Limited, SCOTLAND.
Change 14.128 Support for ITRF V300 (compatible) added variables UNIQUE
VMACITRF (unique sort key) to all ITRF datasets, and SAPTRN (SAP
Jun 9, 1996 internal transaction code) to ITRFMSG dataset. See IMS
Technical Notes for additional ITRF experience.
Change 14.127 Two datasets in ZRBPDB but not in WORK were not found
ZRBBATCH because they did not have the &LIBNAME.. reference in the
ZRBRPT1-3 ZRBBATCH program. ZRBRPT1-3 had JCL removed and &LIBNAME
Jun 9, 1996 added so as to be consistent with other ZRB members.
Thanks to Jay Beeler, Key Services, USA.
Change 14.126 ANALDB2R Statistics Trace now incorporates Change 14.068
ANALDB2R for each Remote Destination, removing references to the
Jun 9, 1996 QLSTLOCN variable in DB2STATS, now using DB2STATR.
Change 14.125 Support for ASTEX 2.1 (INCOMPATIBLE) replaced four bytes
VMACDMON with eight bytes in the VOL record segment, and created
Jun 9, 1996 new variables:
Dataset Variable Label
DMONVOL RVLVG
DMONVOL,DSN,JOB RCDTME CACHE*TIME*SAVINGS
DMONVOL,DSN,JOB RMLDMOBJ DSN's*DEMOTION*TIME*OBJTV
DMONVOL,DSN,JOB RSCLSFLG SMS*CLASS*FLAG
DMONVOL,DSN,JOB LOGICAL*VOLUME*GROUP*NAME
Thanks to Chuck Hopf, MBNA, USA.
Change 14.124 Change 12.099 was not correct in leap years (like 1996!),
VMACDCOL but the impact was minimal. Three EXPDT variables (HSM's
VMXGHSM MCDEXPDT and DCOLLECT's DCDEXPDT and UMEXPDT) were set
Jun 9, 1996 to MXG "infinite" year of 2099 for a valid leap year date
Jun 18, 1996 of 96366 instead of the correct date. MXG uses this
"infinite" date for EXPDTs that are not valid Julian
dates (like 99999, 99366, and also for the special date
of 99365) that are used by tape management systems, but
Change 12.099 incorrectly set any xx366 date as infinite.
Change the occurrences in VMACDCOL and in VMXGHSM from
OR DAYEXPDT GE 366 to OR DAYEXPDT GT 366.
Additionally, the default date in VMACDCOL was changed to
'31DEC2099'D (from '01JAN2099'D) just to be consistent.
This text was revised when I discovered that 2000 is
indeed a leap year, but the code change supports all leap
years, including 2000.
Thanks to Marc Vanden Bergh, Gemeentekrediet, Belgium.
Change 14.123 Omegamon for CICS variables OMSUPRTM and OMDCOMTM (wait
IMACICOC time for SUPRA and DATACOM) were off by a factor of 16.
Jun 9, 1996 Insert OMSUPRTM=16*OMSUPRTM; OMDCOMTM=16*OMDCOMTM;
after the existing statement OMADABTM=16*OMADABTM;
Thanks to Michel Antoons, 3M, BELGIUM.
Change 14.122 Variable SSQELAP in TYPE72GO was input as &RB.8.6 but it
VMAC7072 should have been input as &RB.8. (causing RESPSTD to be
Jun 7, 1996 wrong). Variable AVGELPTM in TYPE7204 dataset was also
INPUT as &RB.8.6, but is now INPUT as &RB.8. and then
converted with *1024/(1E6) like the other elapsed times.
That these errors have been undetected for so long shows
how infrequently they are needed.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 14.121 Variable PCTALLBY was not calculated for TYPE78CU dataset
ANALRMFR but now is, and new variable LCUIORT in TYPE78CU contains
VMAC78 the aggregate I/O rate for all CHPIDs in that LCU.
Jun 5, 1996 In validating this change, I discovered that TYPE78CF
Jun 7, 1996 variables OFFLINE and ONLINE are interpreted by IBM as:
OFFLINE ONLINE IBM Report Explanation
Y Y PATH OFFLINE
Y OFFLINE
OFFLINE
Y ONLINE
ANALRMFR REPORT=CHAN report now prints LCUIORT, which is
not printed by the equivalent IBM report but is useful!
Thanks to Alan Sherkow, IS Management Strategies LTD, USA.
Change 14.120 Change 13.301 accidentally corrected the DEVNR for MSS
VMACUCB devices, but commenting out IF DEVNR='1...... 'B ...,
Jun 5, 1996 but the subsequent line should be changed from ELSE IF
to IF (DEVNR=0FFFx AND NOT ....
Thanks to Peter Durant, National Australia Bank, AUSTRALIA.
Change 14.119 This archaic member for CICS 2.1 and SAP journal segments
VMAC110S had two typos: variable JCTUTRID should be JCRUTRID and
Jun 5, 1996 SAPTEST='SA' /*$$$*SAP*/ needed a semicolon.
Thanks to Santamaria Antonio, Agip Petroli, ITALY.
Thanks to Mark Cohen, SAS Institute, ITALY.
Change 14.118 Decoding Type 37 DETT section only kept 200 bytes of the
VMAC37 text string BRFDATTX, but some operators type up to the
Jun 1, 1996 maximum of 275 bytes, so the logic of the decoding of the
SELD sections's text into BRFTEXT and BRFTEXTA was used
in the DETT section to create BRFDATTX and new BRFDATTA.
Replace the 7 lines in the DETT section starting with
SKIP200=BRFDATLN-200;
with the 14 lines from the SELD section starting with
IF LENSELD GE 275 THEN INPUT BRFTEXT $EBCDIC200.
and then change SELD to DETT (4 occurrences) and change
BRFTEXTA to BRFDATTA (6) and then BRFTEXT to BRFDATTX (7)
in those 14 lines in the DETT section. Finally, add new
variable BRFDATTA to the KEEP= and LABEL statements.
Thanks to Tony Sandora, CIGNA, USA.
Change 14.117 MSOUNITS was increased from 4 to 5 bytes by Change 14.076
BUILDPDB only in VMAC30, but datasets JOBS SPUNJOBS STEPS TRND72 &
BUILD005 TYPE434 still were stored in only 4 bytes. The impact is
BUIL3005 mathematically minimal, with at most a loss of 255 units
TRND72 with 10-digit values of MSOUNITS
VMAC434 and values that large strongly suggest you should fix
May 31, 1996 your MSOCOEFF value (in IPS) to make it a very small
Mar 10, 2003 value - perhaps .001 to .0001 - so that MSOUNITS are
insignificant (less than .1 percent?) in the total
service units calculated by the SRM. You can use a
PROC MEANS DATA=PDB.TYPE72 SUM; to get the percent of
SERVICE that is recorded in MSOUNITS and change your
MSOCOEFF, because MSOUNITS are not a measure of work,
and should not be included in the SRM's measurement of
work/service. Work is CPU and I/O only. Memory is
like air conditioning and floor space (you have to
have enough, and it only comes in big chunks) but
memory occupancy, floor space occupancy, and cooling
occupancy are not measures of computer work; they are
the fixed costs that makes computing possible!
Why then make this minor change? Because Freddie's QA
stream saw the minor difference in values between 13.13
and 14.03 and so for the sake of perfection (rather than
real impact), the change was extended to these members.
Mar 10, 2003: Original text had .000001 but .0001 is the
minimum permitted value, other than zero.
Feb 21, 2005: See MXG Technical Note in Newsletter 47;
IBM Discovered that the smallest value is actually .0122.
Any value less than that value will be reported in the
MSOCOEFF in TYPE72GO, but only 0.0122 will be used!
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.116 Connect-Direct (originally NDM) V 1 R 4 Mod 1 uses two
FORMATS existing reserved fields to compatibly add variables
VMACNDM NDMLUOTH (Other*node LUNAME) and NDMNETYP (Network Type).
May 31, 1996 New MXG format $MGNDMTY was created to decode NDMNETYP.
Thanks to Steve Beaver, Texas Commerce Bank, USA.
Change 14.115 The date part of SYNCSORT variables SORTBEGN and SORTEND
VMACSYNC are off by one day for sorts that spanned midnight. The
May 30, 1996 statement
May 31, 1996 IF SORTBEGN GT SORTEND THEN
SORTBEGN=SORTBEGN-DHMS(1,0,0,0);
should have been
IF SORTBEGN GT SORTEND THEN
SORTEND=SORTEND+DHMS(1,0,0,0);
Also, the +32 reserved bytes INPUT after HPUSED are now
replaced with +22 TSTSYNCS &PIB.8. +2
and IF TSTSYNCS GT 0 THEN CHARACTS=TSTSYNCS; was added
after the @; to support the (as yet undocumented) 8-byte
value so more than 2.4GB of characters can be counted.
Thanks to Linda S. Berkley, Amdahl, USA.
====Changes thru 14.114 were included in MXG 14.03 dated May 27, 1996===
Change 14.114 Support for RACF 1.10 records (compatible). MXG version
VMAC80 14.03 and later tolerate RACF 1.10 records (i.e., will
VMAC80A not fail), but the new "extended length relocate sections
May 26, 1996 are not yet decoded, as I need test data records to
understand how they can be useful. When test data has
been received and the new section is decoded, this note
will be revised.
Change 14.113 Support for Thruput Manager #V041238 "Job Extract"
IMACTPM extension (INCOMPATIBLE) restructured the fixed segment
VMACTPM and creates these new variables in TYPETPMF dataset:
May 26, 1996 CPUTMINT='CPU USED*BY INTER*AND JOB ANAL'
CPUTMJAT='TOTCPU USED BY JOB ANALYZER'
JCTJOBID='JES*JOB*IDENTIFIER'
TPMTMCTA='CATALOGS*ALLOCATED*IN JOB ANAL'
TPMTMLCA='CATALOG*LOCATES*VIA*CAT LOOKASIDE'
TPMTMLCM='CATALOG*LOCATES*VIA*CAT MANAGEMENT'
TPMTMLRQ='CATALOG*LOCATES*REQUIRED'
The default in MXG is for the new record; if you still
process the base record you must set macro _TPMVERS to 0
in member IMACTPM.
In addition, the processing of the extract segments was
redesigned. Previously, an observation in TYPETPMV was
created for each 16 bytes of the TPM data value in each
TPMFIELD segment. Now, there will be one observation for
each TPMFIELD segment, with TPMVALUE now containing the
first 64 bytes of the data value. $ACCT segments have
been found with 161 bytes, but all other data lengths are
less than 64, so the new design should decrease the size
and number of observations in TYPETMMV dataset.
Thanks to Andy Chandler, Eagle Star, ENGLAND.
Change 14.112 IDMS Performance Monitor dataset IDMSBUFF was incorrectly
VMACIDMS decoded. CA uses ALIGN in their assembly, causing bytes
May 26, 1996 to be inserted in the SMF record that do not exist in the
Jul 11, 1996 DSECT, and two fields were increased from 2 to 4 bytes.
-Insert after INPUT BUFNAME $EBCDIC18. +2 to skip the
undocumented bytes, and change the SKIP=SKIP-18; to -20;
-May 26 change said: Change INPUT of BUFNDEFN and BUFNINUS
from &PIB.2. to &PIB.4., and 28 lines later change the
SKIP=SKIP-104 to -108. However, Jul 11, change puts two
fields back as &PIB.2., and instead inserts +2 after each
of those halfwords. The SKIP change of May 26 is coorect.
Thanks to Terry Heim, Ecolab Inc. USA.
Thanks to Martin Wieland, Neckermann B.V., THE NETHERLANDS
Change 14.111 Support for NETSPY Release 4.7 compatibly added variables
VMACNSPY to several datasets:
May 25, 1996 Dataset Variables added
NSPYNCPY CBPIDTID,CBPCBFLG
NSPYTIC3 NSPNTMBR NSPNTMBS NSPVTMFR NSPVTMFS
NSPYVIRT VRBPIINB VRBBYINB
Change 14.110 Variables BADTAP EDMTAP and DYNAM were created but not
VMACTMS5 kept in dataset TMSREC; they have now been added to the
TYPETMS5 KEEP= lists in both VMACTMS5 and TYPETMS5.
May 24, 1996
Thanks to Terry Duchow, U.S. Postal Service, USA.
Change 14.109 Type 110 SMF record with subtype=2818 ('B02'X) is written
UTILGETM by Boole and Babbage's CICS Manager, but UTILGETM has but
May 24, 1996 255 buckets to count subtypes. Now, UTILGETM recognizes
this record, counts it as a subtype 2 record, and the
UTILGETM FOUND A RECORD WITH SUBTYPE GREATER THAN 255
message is not printed for this statistics record.
Thanks to Trevor Ede, Bank of New Zealand, NEW ZEALAND.
Change 14.108 MXG 14.02 only. BY VARIABLES ARE NOT PROPERLY SORTED.
DIFFDB2 The PROC SORT for DATA = _LDB2STR for new PDB.DB2STATR
May 23, 1996 dataset should have BY SYSTEM QWHSSSID QLSTLOCN QWHSSTCK;
(QLSTLOCN was missing from that BY statement).
Thanks to Tony Sandora, CIGNA, USA.
Change 14.107 MXG 14.02 only. INPUT STATEMENT EXCEEDED with type 37
VMAC37 because BRFLOCAL and BRFRMT are not separate new fields.
May 23, 1996 (The type 37 documentation moved from the NetView Admin
Guide into the Application Programming Guide in NetView
2.4, but I then misread Table 33 and thought there were
two new 30-byte fields (BRFLOCAL, BRFRMT), but they are
actually only redefinitions of table 34 whose fields are
already decoded by MXG, so there truly was NO CHANGE in
the Netview 2.4 type SMF record, and the text of 14.090
has been revised.) This change removed the DO group
(IF BRFREVLT GE 2.4 THEN DO; ... END;) that had been
incorrectly added by 14.090. The other correction in
14.090 was valid.
Thanks to Tony Sandora, Cigna, USA.
Change 14.106 Variable A14EQPCT (MAXQTIME Purge Count) was not kept in
VMAC110 dataset CICCONSR (ISC/IRC data), but now is. Also, the
May 23, 1996 variables MCTMNTAD and SMFPSRVR were not kept in dataset
CICSEXCE, but now have also been added to the KEEP= list.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Dawn Medwid, Aetna, USA.
Change 14.105 Variable QWSDLR (High used RBA address of log) was added
VMACDB2 to the LENGTH statement as length 8, and formatted HEX12.
May 23, 1996 as it is an address, not a number; this was supposedly
fixed by Change 13.129 but was not actually made til now.
Also, the input of QWSCIID after IF NRQWSC GT 15 THEN DO;
was changed to XXXCIID, so that the real value of QWCSIID
is not corrupted when there are more than 15 segments.
Thanks to Tom Parker, Hogan Systems, USA.
Change 14.104 Variables BEGTIME and ENDTIME were not created in the DB2
DIFFDB2 interval datasets DB2STATB (buffer pool) and DB2STATR
May 23, 1996 (remotes), but now they are!
Thanks to Susan Marshall, SAS Institute Cary, USA.
Change 14.103 Variables ACTLNGH, NETLNGH, and USELNGH should be INPUT
VMACORAC as &PIB.2. instead of &PIB.4., so that accounting data
May 23, 1996 is correctly input.
Thanks to Dave Harris, TVA, USA.
Change 14.102 MXG 14.02 only. INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC7072 with MVS/ESA 5.2 type 72 record because of MXG coding
May 22, 1996 errors (and insufficient testing of Change 14.085).
-Find the statement IF LENSCS GE 316 THEN DO;
Change the following INPUT statement for variable
R723CSRS from &PIB.4.6 to &PIB.8.6, and for variables .
R723CSPA and R723CSPE from &PIB.4. to &PIB.8.
-Find the statement SKIP=LENSCS-292; (which was 11 lines
after the IF LENSCS GE 316 THEN DO; statement), and move
it immediately before the IF LENSCS GE 316 THEN DO;
-After R723CSRS=1024*R723CSRS; statement, insert new line
SKIP=SKIP-24;
Thanks to Tony Sandora, CIGNA, USA.
Change 14.101 The error message "JOB WAS NOT EXECUTED ON THE FIRST DAY'
MONTHBLD was made more readable, and now points to MXG Newsletter
May 22, 1996 TWENTY-FIVE for instructions for "Running the MONTHBLD
program on a day other than the 1st day of the month".
Thanks to Bernie Levy, CUC International, USA.
Change 14.100 In fifteen members, the datetime literal value of
IMACEXCL '01JAN00:00:00:00'DT was used to initialize variables to
TYPEMOND IBM's epoch datetime value, but that 00 year value can be
TYPEMONI interpreted as 1900 or 2000, depending on the value of
TYPEMONX your SAS option YEARCUTOFF, so MXG was changed to use
TYPEMON8 '01JAN1900:00:00:00'DT to always set the correct value.
TYPETMON MXG uses this value only when decoding raw records into
VMACCIMS SAS datasets, so it is highly unlikely that you would
VMACHURN have this literal value in your own SAS programs;
VMACOMCI nevertheless, it would certainly be wise to search you
VMACVMON SAS source libraries for '01JAN00's existence and change
VMAC110 to the 1900 value to thereby support the year 2000.
VMAC110M
VMAC110S
VMAC116
VMACDB2H
YEAR2000
May 22, 1996
Thanks to Graeme Yeandle, British Telecom, ENGLAND.
Change 14.099 The @137,141,143,145 for the input of OFFARMS,LENARMS,
VMAC30 NRARMS and EXTRARMS should have been 149,153,155 and 157
May 22, 1996 for the Auto Restart section. I still do not have a dump
of a real type 30 record with Auto Restart section, but
I just happened to notice this error.
Change 14.098 Support for AS/400, OS/400 Release 3.6 INCOMPATIBLY added
VMACQAPM fields to the QAPMDISK, deleted fields in QAPMCONF,
May 1, 1996 increased the size of one field in QAPMSYS, and added and
deleted fields from QAPMJOBS.
Added to QAPMDISK:
DMDRN ='MIRRORED*DEVICE*RESOURCE*NAME'
DMIRN ='MIRRORED*IOP*RESOURCE*NAME'
DSCCFW ='CONTROLLER*CACHE*FAST*WRITES'
DSCCRH ='CONTROLLER*CACHE*READ*HITS'
DSCCWH ='CONTROLER*CACHE*WRITE*HITS'
DSDRN ='DEVICE*RESOURCE*NAME'
DSPCPH ='CONTROLLER*CACHE*PARTIAL*READ HITS'
IOPRN ='IOP*RESOURCE*NAME'
and deleted variables DS/DMARMP DS/DMIOPA DS/DMIOPB
and DS/DMPORT
Added to QAPMJOBS:
JBDRN ='DEVICE*RESOURCE*NAME'
JBIRN ='IOP*RESOURCE*NAME'
JBSJNB ='SUBMITTORS*JOB*NUMBER'
JBSJNM ='SUBMITTORS*JOB*NAME'
JBSJUS ='SUBMITTORS*JOB*USER'
JBTTYE ='TASK*TYPE*EXTENDER'
JBTTYP ='TASK*TYPE'
Only these four structures have been enhanced for 3.6.0
as of this date. Further updates may be expected.
Thanks to Clark Jennings, Reynolds Metal, USA.
Change 14.097 MXG 14.02 only. Zero obs in dataset NSPYLU due to typo.
VMACNSPY In line number 15610061 which read:
May 1, 1996 INPUT LRSPHOST &PIB.4.6 /*
that extraneous "/*" must be removed from that line.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
====Changes thru 14.096 were included in MXG 14.02 dated Apr 25, 1996===
Change 14.096 Duplicate INPUT of the same variable in the same INPUT
VMACNSPY statement did not cause errors, but to avoid confusion,
Apr 26, 1996 those INPUT statements were cleaned up in these members:
VMACIMSA SYNCUOWC Duplicate line deleted
VMACLMS OPTION1 Duplicate renamed OPTIONLM
VMACNSPY CBPPOOL New variable CBPPOOLU created
VMACNSPY NSPBEXPN New variable NSPBEXTN created
VMACQAPM xxIOPA,B Input @20, @21 removed
VMACRMFV SSHCPUX Duplicate renamed SSHCPUX
VMACX37 VOLSER Duplicate renamed VOLSERX
VMACXAM DASDCACH Duplicate renamed DASDCACX
VMACXCOM UNDOC04 Duplicate renumbered.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.095 NETSPY type S record from R4.4 caused STOPOVER; the MXG
VMACNSPY tests for NSPYENTL=108 and NSPYENTL=160 must be changed
Apr 26, 1996 to NSPYENTL=112 and NSPYENTL=164 respectively.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 14.094 Variable SYNCTIME was not kept in TYPE30_0 dataset, but
VMAC30 now it is.
Apr 26, 1996
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
Change 14.093 Support for IBM's Cache RMF Reporter (CRR) 1.7 adds new
VMACACHE variables and a new CACMODEL='02'X, for Emulated 3990s
Apr 25, 1996 (such as the RAMAC Array Subsystem). The IBM changes are
compatibly made, but there will be no observations in
dataset CACHE90 for the new Emulated 3990s records until
you install this change. New variables in CACHE90 are:
CACMODEL='CACHING*SUBSYS*MODEL'
CWCC ='CONCURRENT*COPY*CONTAM*WRITES'
DCTC ='DEVICE CACHE TRACKS CONFIGURED'
DCTR ='DEVICE CACHE TRACKS REMOVED'
DVRD ='DEVICE READS*BY*CONTROL UNIT'
DVRH ='DEVICE READ HITS*BY*CONTROL UNIT'
DVWH ='DEVICE WRITE HITS*BY*CONTROL UNIT'
DVWR ='DEVICE WRITES*BY*CONTROL UNIT'
PPRC ='PPRC*WRITE*COUNT'
RSV ='LOWER*INTERACE*IO*(MILLISEC)'
SFRD ='TRACKS*READ*FROM SIDEFILE'
TSRR ='TRACKS*STAGED*FOR RAID RECONSTRUCION'
CSCSDFM0='CACHE 0*DISABLED*FOR*MAINTENANCE?'
CSCSDFM1='CACHE 1*DISABLED*FOR*MAINTENANCE?'
CSCSTAT0='CACHE 0*STATUS'
CSCSTAT1='CACHE 1*STATUS'
CSNSBAT0='NVS 0*BATTERY*IS*DEFECTIVE?'
CSNSBAT1='NVS 1*BATTERY*IS*DEFECTIVE?'
CSNSDFM0='NVS 0*DISABLED*FOR*MAINTENANCE?'
CSNSDFM1='NVS 1*DISABLED*FOR*MAINTENANCE?'
CSNSPND0='NVS 0*PENDING*DUE TO*ERROR?'
CSNSPND1='NVS 1*PENDING*DUE TO*ERROR?'
CSNSTAT0='NVS 0*STATUS'
CSNSTAT1='NVS 1*STATUS'
Note that variables CSCSDFM, CSCSTAT, CSNSBAT, CSNSDFM,
CSNSPND and CSNSTAT were replaced by the above pairs.
Change 14.092 IBM's RMDS Version 2.2 is supported by MXG, as there was
VMACRMDS no change in the contents of their SMF record.
Apr 25, 1996
Change 14.091 Boole's STOPX37's replacement version records are trash.
VMACX37 The version 3.5 SMF record was replqced by a record with
Apr 25, 1996 only text fields. Many users complained to Boole, and
Boole was finally persuaded to create the SMF record that
should not have been replaced in their next version. As
yet I have no documentation by which to update MXG.
Update: See Change 14.207 for PRO/SMS replacement.
Change 14.090 The original text of this change said that the NETVIEW
VMAC37 2.4 type 37 SMF record was INCOMPATIBLY changed, but that
Apr 25, 1996 is false - see Change 14.107 - there was no change.
May 23, 1996 However, 14.090 did correct MXG's logic error that had
caused INPUT STATEMENT EXCEEDED errors due to incorrect
detection of the existence/insertion of OFFETHD:
The line IF OFFPROD-3-COL GE 16 THEN DO; was changed to
IF OFFPROD-3-COL EQ 16 THEN DO; and the line
IF OFFPROD-3-COL GE 24 THEN DO; was changed to
ELSE IF OFFPROD-3-COL GE 24 THEN DO;
Thanks to Joe Schwartz, CIGNA, USA.
Change 14.089 Support for APAR PN69653, which changes COLLTIME in IBM
VMAC110 type 110 record from YY to YYYY for year 2000 compliance.
YEAR2000 Member YEAR2000 updated.
Apr 25, 1996
Change 14.088 BLKSIZE=23364 values of Change 12.248 were implemented in
JCLIMSLG the sample JCL in member ASMIMSLG, but only now have the
Apr 25, 1996 DCB parameters been corrected in member JCLIMSLG.
Thanks to Waldemar Schneider, SAS Institute Cary, USA.
Change 14.087 Variable QWHCATYP exists both in DB2 datasets and in MQM
FORMATS dataset TYPE116, but with different values for Attachment
VMAC116 Type, so the variable QWHCATYP in TYPE116 dataset is now
Apr 25, 1996 renamed QWHCXTYP which is FORMATed MG116TY to decode
the MQM attachment types. This is an INCOMPATIBLE change,
if any of your reports used variable QWHCATYP from the
dataset TYPE116. Sorry for the inconvenience!
Thanks to Rick Apel, Square-D Company, USA.
Change 14.086 ASMTAPES MAINTLEV 9 supresses the stoppage of writing the
ASMTAPES Allocation subtype after TMNT013E error message. See the
Apr 25, 1996 MXG Technical Note in CHANGES in MXG 14.02 (to be printed
in Newsletter 30 this summer) for further discussion.
Find the TMNT013E message WTO and change that code to
look like this: (change text of WTO, comment NI and MVC):
WTO 'TMNT013I A LOCK OBTAIN LOOP HAS EXCEEDED MAXIMUM TIME AX
LLOWED - POSSIBLE SYSTEM STALL'
* NI OPTIONS,255-DOALLOC TURN OFF ALLOCATION BIT
* MVC PARSSAL,=CL3'NO ' UPDATE STATUS MESSAGE
B MONITOR AND LEAVE
LOCKED EQU *
Thanks to Mike ONeill, Dun and Bradstreet, USA.
Change 14.085 Variables added by IBM in MVS/ESA 5.2.0 but overlooked:
VMAC7072 Dataset TYPE72GO (Goal Mode Service/Report Class data):
VMAC74 R723CSRS='SHARED*PAGE*RESIDENCY*TIME'
Apr 23, 1996 R723CSPA='SHARED*PAGEINS*FROM*AUXSTORE'
R723CSPE='SHARED*PAGEINS*FROM*ESTORE'
Dataset TYPE74OM: (Open Edition MVS):
OMVSCAMN='MIN*MEM MAP STORAGE PAGES*PER CYCLE'
OMVSCAMX='MAX*MEM MAP STORAGE PAGES*PER CYCLE'
OMVSCGMN='MIN*SHARED MEM PAGES*PER CYCLE'
OMVSCGMX='MAX*SHARED MEM PAGES*PER CYCLE'
OMVSCHMN='MIN*SHARED MEM IDS*PER CYCLE'
OMVSCHMX='MAX*SHARED MEM IDS*PER CYCLE'
OMVSCMAP='AVG*MEM MAP STORAGE PAGES*PER CYCLE'
OMVSCMMN='MIN*MSG QUEUE IDS*PER CYCLE'
OMVSCMMX='MAX*MSG QUEUE IDS*PER CYCLE'
OMVSCMSG='AVG*MSG QUEUE IDS*PER CYCLE'
OMVSCPAG='AVG*SHARED STORAGE PAGES*PER CYCLE'
OMVSCSEM='AVG*SEMAPHORE IDS*PER CYCLE'
OMVSCSHM='AVG*SHARED MEM IDS*PER CYCLE'
OMVSCSMN='MIN*SEMAPHORE IDS*PER CYCLE'
OMVSCSMX='MAX*SEMAPHORE IDS*PER CYCLE'
OMVSCSPG='AVG*SHARED MEM PAGES*PER CYCLE'
OMVSCXMN='MIN*SHARED STORAGE PAGES*PER CYCLE'
OMVSCXMX='MAX*SHARED STORAGE PAGES*PER CYCLE'
OMVSMMAP='MAX*MEM MAP PAGES*PER CYCLE'
OMVSMMSG='MAXIMUM*MESSAGE*QUEUE*IDS'
OMVSMPAG='MAX*SHARED STORAGE PAGES*CONSTANT'
OMVSMSEM='MAXIMUM*SEMAPHORE*IDS'
OMVSMSHM='MAXIMUM*SHARED*MEMORY*IDS'
OMVSMSPG='MAXIMUM*SHARED*MEMORY*PAGES'
OMVSOAMN='MIN*EXCEED MEM MAP PAGES*PER CYCLE'
OMVSOAMX='MAX*EXCEED MEM MAP PAGES*PER CYCLE'
OMVSOGMN='MIN*EXCEED MAX SHR PAGES*PER CYCLE'
OMVSOGMX='MAX*EXCEED MAX SHR PAGES*PER CYCLE'
OMVSOHMN='MIN*EXCEED MAX SHRMEM IDS*PER CYCLE'
OMVSOHMX='MAX*EXCEED MAX SHRMEM IDSPER CYCLE'
OMVSOMAP='AVG*EXCEED MEM MAP PAGES*PER CYCLE'
OMVSOMMN='MIN*EXCEED MAX MSGS*PER CYCLE'
OMVSOMMX='MAX*EXCEED MAX MSGS*PER CYCLE'
OMVSOMSG='AVG*EXCEED MAX MSGS*PER CYCLE'
OMVSOPAG='AVG*EXCEED STORAGE PAGES*PER CYCLE'
OMVSOSEM='AVG*EXCEED MAX SEMA IDS*PER CYCLE'
OMVSOSHM='AVG*EXCEED MAX SHRMEM IDS*PER CYCLE'
OMVSOSMN='MIN*EXCEED MAX SEMA IDS*PER CYCLE'
OMVSOSMX='MAX*EXCEED MAX SEMA IDS*PER CYCLE'
OMVSOSPG='AVG*EXCEED MAX SHR PAGES*PER CYCLE'
OMVSOXMN='MIN*EXCEED STORAGE PAGES*PER CYCLE'
OMVSOXMX='MAX*EXCEED STORAGE PAGES*PER CYCLE'
OMVSCYCT='CYCLE*TIME*VALUE'
Change 14.084 INPUT STATEMENT EXCEEDED for SUBTYPE=41. The line with
VMACBETA DATE &PD.4 must be DATE &PD.4. (i.e., the final
Apr 22, 1996 period was missing). Originally, this text also said
May 26, 1996 "there are other changes in the subtype=41 record that
are not documented", but that was not true; there were no
other changes to that subtype of the BETA93 SMF record.
Thanks to Mr. Bronner, Versandhaus Wenz, GERMANY
Change 14.083 Variables QW0045SR and QW0045XR added to T102S045 dataset
VMAC102 by DB2 4.1, with "Suspend Reason" and "Extent of Global
Apr 22, 1996 Contention" flags.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 14.082 Labels for QBGxxx variables were changed from "SES ..."
VMACDB2 to "CF ...". These variables report Coupling Facility
Apr 16, 1996 contentions and false contentions. What was originally
called Shared Expanded Storage (SES) is now known as the
Coupling Facility (CF).
Change 14.081 The OPTIONS MAUTOSOURCE SASAUTOS=SOURCLIB; statement in
TYPEIMSA TYPEIMSA was removed. Those options have been set by the
Apr 16, 1996 CONFIG option for many versions, and so this statement is
redundant; it also caused SAS/CPE problems in the way
they modify MXG code on the fly.
Thanks to Carl Sommer, SAS Institute Cary, USA.
Change 14.080 VM/370 (archaic!) monitor records with RELEASVM='01' were
VMACVMON not recognized in the Device (6.02) section. Before the
Apr 16, 1996 line reading ELSE LENDV2=1; insert this line:
ELSE IF RELEASVM EQ '01' THEN LENDV2=2;
to correct the error.
Thanks to Jim Cheesman, NWNL Corporation, USA.
Change 14.079 Date variables which are zero printed as 01JAN1960, which
VMACTLMS is the SAS date value epoch, but this caused confusion on
Apr 16, 1996 reports (which previously printed only a 0). All of the
statements ... THEN variable='01JAN1960'D; were replaced
with THEN variable =.; (to set zero dates to missing).
Thanks to Rey Marquez, General Accident, USA.
Change 14.078 Reserved Change Number.
Apr 12, 1996
Change 14.077 OPC Release 3.0 and 3.1 may cause INVALID MTD SUBTYPE
EXOPC24Y messages to fill the SAS log, and observations were not
IMACOPC output. New fields that were not in the 3.0 manual are
VMACOPC now in the 3.1 manual, but also now show up in records
Apr 11, 1996 created by OPC Release 3.0! Since I can't get straight
Apr 16, 1996 answers from IBM as to whether the fields were really
there in 3.0 and I missed them, or whether PTFs created
the new fields, I have added support for the new data but
you will have to update macro _OPCVER in member IMACOPC
to a value of 3.1 for MXG to read in the new fields. In
otherwords, try processing OPC 3.0 with _OPCVER 3, and if
that fails, change _OPCVER to 3.1 and try again!
Dataset OPC24D_B has new variables MTDRESE and MTDRESQ.
Dataset OPC24_25 formerly contained subtypes 2,3,4 and 5
(MT0TYPE) of the Type 24 record, but this change creates
new dataset OPC24_2 for the subtype 2, and now OPC24_25
contains only subtypes 3,4, and 5. The new OPC24_2
dataset exit name is EXOPC24Y because EXOPC242 is already
in use.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 14.076 Variable MSOUNITS is now stored as 5 bytes instead of 4,
VMAC30 because a value such as 2,804,486,170 is truncated to
Apr 11, 1996 only 2,814,486,016 when stored in 4 bytes.
Thanks to Aldo Valenti, SAS Italy, ITALY.
Change 14.075 If KEEPALL=YES was specified, and some of the parameters
VMXGSUM were not used in your %VMXGSUM invocation, the logic to
Apr 10, 1996 reconstruct the strings failed since it should never have
been executed. This change makes KEEPALL=YES work as it
was intended, and provides improved error checking.
Thanks to Tom Elbert, John Alden Insurance, USA.
Change 14.074 If TRNDLPAR has less than one week's data (i.e., first
GRAFLPAR time it's being used), strange graphs occurred because
Apr 10, 1996 MXG assumed more than one week's data. This change uses
the "best fit" algorithm of GRAFTRND so that all points
represent a monday or a start of the week.
Change 14.073 ERROR: VARIABLE QWHSIID NOT FOUND with DB2 I/O reports
ANALDB2R (a holdover from before ANALDBTR existed to pair the DB2
Apr 10, 1996 I/O trace records) is corrected by this change.
Thanks to Roland Nieuwenhuizen, SAS Netherlands, THE NETHERLANDS.
Thanks to Paul Ritzen, KLM, THE NETHERLANDS.
Change 14.072 Variable CLASRC was added to EREPOBR dataset (to identify
ADOCEREP which record created the observation), and ADOCEREP was
VMACEREP updated to describe datasets EREPOBL and EREPHDR.
Apr 10, 1996
Change 14.071 Dataset DB2STATB previously had zero observations unless
EXDB2STB you tailored exit member EXDB2STB, because I thought the
Apr 10, 1996 dataset could be large. In fact, there is only one obs
for each buffer pool for each interval, and thus I have
removed the comment block around the OUTPUT _LDB2STB;
statement, so observations will now always exist.
Thanks to Chuck Hopf, MBNA, USA.
Change 14.070 IBM APAR OW19251 addresses RACF and the year 2000; since
VMAC80A the RACF database only has three bytes for date, IBM has
Apr 10, 1996 declared that RACF dates with YY of 71 or higher will be
interpreted as year 19YY and dates with YY of 70 or less
will be interpreted as year 20YY. Further information is
to be in APAR OW19683. In examining VMAC80A, two dates
were not converted from Julian to SAS. After the INPUT
of variables REVOKDTE and RESUMDTE (two separate places),
insert:
IF REVOKDTE GT 0 THEN REVOKDTE=DATEJUL(REVOKDTE);
IF RESUMDTE GT 0 THEN RESUMDTE=DATEJUL(RESUMDTE);
Change 14.069 TYPE99_2 now contains one observation for each period in
VMAC99 each service class that had activity; previously only the
Apr 10, 1996 first period's data was output.
Before the INPUT @SM992CPO insert DO _I_=1 TO SM992CPN;
After the %%INCLUDE SOURCLIB(EXTY99U2); insert
SM992CPO=SM992CPO+SM992CPL; END;
I discovered that the SRVCLASS variable that I INPUT
from the Period Data Section must instead be INPUT from
the Class Data Section (i.e., where SM992NAM was input),
and I now INPUT new variable SM99PCNM where SRVCLASS was
INPUT, labeled SM99PCNM='INTERNAL*SERVICE*CLASS*NAME' and
is kept instead of SM992NAM. The Internal Service Class
Name only appears in type 99 records, with names like
$SRMDInn for discretionary periods, or $SRMBEST, $SRMGOOD
and $SRMDUMP names.
Thanks to Sridhar Gopalaswami, Barnett Technologies, USA.
Change 14.068 MXG only output the first QLST segment in DB2STATS, but
DIFFDB2 there is one segment for each Remote Destination used in
EXDB2STR each interval. Now, the QLSTxxxx variables in DB2STATS
IMACDB2 will contain the sum of all remote activity to all remote
VMACDB2 locations during the interval, while new dataset DB2STATR
Apr 9, 1996 contains one observation for each Remote Location during
each interval with the detail QLSTxxxx counts. Member
DIFFDB2 was altered to also deaccumulate DB2STATR.
Thanks to Peter Li, John Deere, USA.
Thanks to Ralph Baechle, John Deere, USA.
Change 14.067 Variable QBSTHBE in DB2STATB and variables QBnTVPL,
DIFFDB2 QBnTHPL, and QBnTHBE for n=0,1,2,3 in DB2STATS are not
Apr 2, 1996 not accumulated values but are endpoint values, so their
DIF() statements were removed from DIFFDB2. (QBSTHPL and
QBSTVPL were removed from DB2STATB by Change 13.269).
Thanks to Peter Li, John Deere, USA.
Change 14.066 Validation of TYPE88 with data corrected INPUT STATEMENT
VMAC88 EXCEEDED RECORD LENGTH errors Input of SMF88SDL should
Apr 2, 1996 have been &PIB.4. vice &PIB.2., and the +2 after SMF88SAB
must be +4, SMF88RVN is now input as &NUM.2 vice &PIB.2.,
and SMF88LIT is input TODSTAMP8 and formatted, and new
field SMF88EFS (undocumented in SMF manual) is input.
Thanks to Lee Borgman, Boeing Information Services, USA.
Change 14.065 APARS OW08565 and OW10584 adds SYNCTIME and statistics
VMAC28 (CPU utilization, Fast Program Storage Utilization, and
Apr 1, 1996 Buffer Storage Utilization) for each of the (up to 18!)
processors in the 3746/900 in the NAC segment, and adds
TIC utilization per frame and per byte sent and received
in the CSL segment.
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Thanks to Sandro Aiello, National Australian Bank, AUSTRALIA.
Change 14.064 Using Tape instead of DASD for ANALDSET fails; the step
ANALDSET added in MXG 13.02 reused the same DDNAME. The lines
Apr 1, 1996 DATA SORTSTEP.SORTSTEP; SET SORTSTEP.SORTSTEP must be
DATA TYPE30.TYPE30_4; SET SORTSTEP.SORTSTEP; and a new
data step was added after that step with
DATA SORTSTEP.SORTSTEP; SET TYPE30.TYPE30_4;
Thanks to Bill Bechtloff, Acxion, USA.
Change 14.063 DASDMPL value 1000 times too large in dataset TYPE42DS.
VMAC42 RESPTIME is in millisec, not sec, so equation must be:
Apr 1, 1996 DASDMPL=RESPTIME*DASDRATE/1000;
Thanks to Xiaobo Zhang, Insurance Services Office, USA.
Change 14.062 Just before the "DATA PDB.ASUMAPAF;" statement, insert:
ASUMAPAF PROC SORT DATA=TEMPAPA2;
Apr 1, 1996 BY SYSTEM STARTIME LPARNUM LPARNAME;
to protect sort order if you increase the number of
MDF domains.
Thanks to Scott Snyder, Card Establishment Services, USA.
Change 14.061 Variables MVUCDATE and MVUCTIME need ?? modifier (just
VMACEDGS like change 13.124) to prevent INVALID DATA messages when
Apr 1, 1996 there was no last user change date. In addition, dataset
EDGSOREC and EDGSOVOL were not correct. After the +7,
insert @; IF MOCFLG EQ '08'X THEN INPUT before MOOWNSUR,
replace IF LENGTH-COL+1 GE 4 THEN INPUT with ELSE INPUT
and change IF MOVOLNO GT 0 THEN DO to IF MOVOLNO GT 0
AND MOCFLG NE '08'X THEN DO....
Thanks to Emmanuel Chenay, Toyota Motor Europe, BELGIUM.
Change 14.060 UCICSCNT CICS diagnostic tool was enhanced to count the
IMACEXCL different record sizes found in your CICS transaction
VMAC110 (type 110 subtype 1) data that you can verify if all of
UCICSCNT your regions have the same EXCLUDE/INCLUDE definitions.
Apr 1, 1996 Comments in IMACEXCL were improved for multi-line INPUT
statements for the same CICS field number, and debugging
logic in VMAC110 was strengthened.
Change 14.059 TYPE72GO variable VALDSAMP was incorrect, which caused
VMAC7072 the PCTDLxxx variables to sometimes be wrong. The correct
Mar 29, 1996 equation should have five terms:
VALDSAMP=PCTUSCUS+PCTDLTOT+PCTDLUNK+PCTDLIDL+PCTDLPQU;
In addition, VALDSAMP is added to the KEEP= list for the
TYPE72GO dataset.
Thanks to Bruce Widlund, Merrill Consultants, USA
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.058 TYPE71 statistics for Shared Page Groups added in ESA 5.1
VMAC71 by IBM but missed by MXG until now. New variables are:
Mar 29, 1996 SHPG-IN/OU-AU/EX - Page in/out from AUX and ESTORE
SHPGSYxx - Shared Page Groups in the system
SHPGCSxx - Shared Page Groups in CSTORE
SHPGESxx - Shared Page Groups in ESTORE
SHPGAUxx - Shared Page Groups in AUX STORE
SHPGFXxx - Shared Page Groups Fixed
SHPGLOxx - Shared Page Groups Fixed below 16MB
where xx = AV,MN,MX for average, min and maximum.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 14.057 Support for STK's NearOAM (formarly NearImage) user SMF
EXTYNOAM record creates dataset TYPENOAM with one observation for
IMACNOAM each individual request to retrieve an object. Their SMF
TYPENOAM record can contain up to 100 requests from a single tape;
VMACNOAM MXG creates one observation per request, with the start
Mar 28, 1996 and end times and duration of each request, and the name
of the tape dataset being processed.
Thanks to Fiona Crane, Sun Alliance Insurance Group, ENGLAND.
Change 14.056 Cosmetic. Test macro _TESTINTX defined in VMACVMXA is
JCLTEST6 too long and is renamed _TESTINX to conform with 8-byte
VMACVMXA limit of SAS. There was no change to JCLTEST6, but that
Mar 27, 1996 MXG job encountered this error in VMACVMXA.
Thanks to Philip Sills, IFF International Flavors & Fragrance, USA.
Change 14.055 STK's HSC Subtype 08 record comes in two (incompatible)
VMACSTC lengths of 38 or 40 bytes, but MXG Change 14.001 knew of
Mar 27, 1996 only the 38 byte record. STK expanded a one byte thrice
defined field into three separate fields. Either length
record caused INPUT STATEMENT EXCEEDED error message.
To fix, conditionally execute the INPUT statement by
inserting IF LENGTH-COL+1 EQ 18 THEN before input,
then block replicate the input, change the condition to
ELSE IF LENGTH-COL+1 GE 20 THEN
and then remove the +M1 before fields STC08CID, STC08MAG
in the GE 20 input.
Thanks to Herb G. Strozinsky, Burlington Northern Santa Fe RR, USA.
Thanks to Sudie Wulfert-Schickedanz General American Life Ins, USA.
Change 14.054 Support for Netview FTP (File Transfer Protocol) subtype
FORMATS 51x, written when the Server Finished Request Processing
VMACFTP creates FTP25X dataset with bytes transferred, CPU time,
Mar 27, 1996 begin and end, as well as compression factor.
APAR PN82953 corrects documentation.
Thanks to Herb G. Strozinsky, Burlington Northern Santa Fe RR, USA.
Change 14.053 Variables LUNETID PCSESSID VILUNAME in NSPYLU dataset are
VMACNSPY trashed, because two new fields, LUATTCHS and LUUSRSPS
Mar 27, 1996 were not input by MXG. After the line that INPUTs
Mar 28, 1996 variable LUNRSPSS, and before the @; that ends that
INPUT statement, insert
LUATTCHS &PIB.2. /*ATTACHES*INITIATED*ONLY LU 6.2*/
LUUSRSPS &PIB.2. /*USER*RESPONSES*(BOTH6.2+NON-6.2)*/
then add the two variable names at the end of the NSPYLU
KEEP= list, just before the _KNSPYLU macro reference.
Additionally, variable NSPYNETW was trashed, as six bytes
were inserted in July 95 that were not in the March 95
documentation for Netspy 4.6. To circumvent, after the
line that INPUTs SGTRGT4, insert a line with +6 to
skip six bytes. The actual change creates new variable
NSPYDBKY, Database Key from the Netspy Header, but does
not keep the new variable (until someone tells me what
use it is in which Netspy datasets!).
Thanks to Dennis Longnecker, State of Washington OAC, USA.
Change 14.052 HSM ABARS short FSRTYPE=15 record caused INPUT STATEMENT
VMACHSM EXCEEDED RECORD error. While I am still investigating
Mar 15, 1996 what changed, to circumvent the error and skip the bad
record, insert IF LENGTH-COL+1 LT 274 THEN RETURN;
in two places, immediately preceding both occurrences of
INPUT @15+OFFSMF
WFSRJOB $EBCDIC8. /*REQUESTING*JOB*...
Thanks to Robert A. Burns, The Travelers, USA.
Change 14.051 Variable ELAPSTM was not created in dataset TYPE72GO Goal
VMAC7072 Mode, causing RMFINTRV to have missing values for all of
RMFINTRV the response (TSORESP,BATRESP) when you migrate to WLM
Mar 15, 1996 Goal Mode, because ELAPSTM is the numerator of response.
Just adding ELAPSTM to KEEP list for TYPE72GO won't work.
Thanks to Waldemar Schneider, SAS Institute Cary, USA.
Thanks to Kevin Carpenter, First of America Services, USA.
Change 14.050 INVALID DATA FOR BETASTRT and BETAEND with BETA 1.6.5 for
VMACBETA subtype=21 because MXG failed to skip over three reserved
Mar 13, 1996 bytes. Find the statement ELSE IF SUBTYPE=21 THEN DO;
Then find the statement about 21 lines later reading:
BETASTRT SMFSTAMP8. /*S20TRES1*RESERVED*/
Change the line to read
+3 BETASTRT SMFSTAMP8. /*S20TRES1*RESERVED*/
Thanks to Mr. Hasselmann, Braun AG, GERMANY.
Change 14.049 Changes to keep DATETIME in Change 14.028 should also be
BUILDPD3 made in BUILDPD3 and BUIL3005 (for JES3) to be consistent
BUIL3005 with BUILDPDB and BUILD005 (for JES2). Variable DATETIME
Mar 13, 1996 is kept and labelled in PDB.JOBS, PDB.STEPS and PDB.PRINT
and LENGTH statements were also made consistent.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 14.048 Variable ULOGADAE should have been INPUT as &PIB.4.3 vice
VMACCOMP &PIB.4.2.
Mar 13, 1996
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 14.047 DB2 Trace dataset T102S096 variable QW0096SN should have
VMAC102 been INPUT as &PIB.4. vice &PIB.2.; variables QW0096SC
Mar 13, 1996 and QW0096SK should be &PIB.2. vice $EBCDIC1.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
====Changes thru 14.046 were included in MXG 14.01 dated Mar 7, 1996===
Change 14.046 Validation of TMON for UNIX at a real site with real data
VMACTUX uncovered these corrections.
Mar 7, 1996 -Variable INTERVAL added to KEEP= for TUXCPU and TUXDISK.
-Variables UTIME, STIME, UTIMETOT, STIMETOT are divided
by 100.
-For data from AIX, memorymgmt fields swapins, swapouts,
filefault, swapfault, and faultiorate do not exist, and
system fields swapin_rate and swapout_rate do not exist,
and must be commented out in your input statement (until
I find a permanent solution!).
-Comparing the sum of utime and stime from process records
was typically 70%-80% of the usertm from cpu records for
HP G50, but with AIX, stime+utime is always greater than
the usertm, usually about 150%, and utime by itself with
AIX is 75-80% of usertm.
-Nowhere is TMON/UNIX is CPU model/speed/size or memory
size kept.
Thanks to Dan Sidorik, SmithKlein Beecham, USA.
Change 14.045 The //LKED.SYSLMOD DD statement must be moved to the end
ASMRMFV of the member for the assembly and link edit to execute
Mar 6, 1996 without error.
Thanks to Jay Beeler, Key Services, USA.
Change 14.044 A truncated DB2 3.1 type 101 SMF record caused INPUT
VMACDB2 STATEMENT EXCEEDED because MXG validation of the triplet
Mar 6, 1996 (offset, length, number) was not as robust as it is now.
Change the test now reading:
IF 0 LT OFFPROD LT LENGTH AND NRPROD GT 0 THEN DO;
to read
IF 0 LT OFFPROD LT LENGTH AND NRPROD GT 0
AND OFFPROD+LENPROD-1 LE LENGTH THEN DO;
The record may have been truncated during copying after
creation, or DB2 might have created the bad record; the
site is still investigating, and this note will be
updated when more is known. Now, MXG will detect this
class of bad records, tell you they are there while
avoiding the STOPOVER error, and keep on truckin'.
The actual change was made to all forty statements of the
preceding form, one for each record segment type.
The bad record had a product section length (in the
triplet) of 152 bytes, but there were only 114 bytes
left in the record from the start of the PROD data
section. The PROD data section contained a valid
76-byte header 1 subsection, and the beginning of a
header 2 section with expected length of 76 bytes, but
only 38 bytes exist.
Thanks to Dan Null, Caterpiller Inc, USA.
Change 14.043 DCOLLECT dataset DCOLSG (Storage Group definitions) has
VMACDCOL variable DSGGBKUF too large, because MXG was off by one
Mar 6, 1996 byte. After the IF DCOLRTYP='DC' THEN DO; statement,
insert new statement M8=-8; Then change the line that
inputs DSGGBKUP so that it reads:
+M8 DSGGBKUP $EBCDIC1. +7 /* label ... */
(DSGGBKUP is a redefinition of DSGCNFRM).
Thanks to Mike Moss, Royal Bank of Scotland, SCOTLAND.
Change 14.042 -INVALID DATA for TIGETMCT or TIFREMCT because the fields
TYPETMON are documented as XL8 and I assumed they were floating
Mar 6, 1996 point (like all the other Landmark XL8 fields) and input
them as &RB.8. Since all of my test data had zero values
I could not tell. Well, it turns out they are fixed and
not float, and their input must be changed from &RB.8. to
&PIB.8., and the two lines after the @; that multiply by
1000000 must be deleted.
-INVALID DATA FOR TIAPREQ TIAPWAT and/or TIAPEXMT result
when your CICS guy uses new TMON TCE 1.3 programs
TMONCNVT or $DBUTIL to convert old TMON TCM 8.3 records;
trashed records of the wrong length (2276) are created by
the Landmark program when you cross versions. Although I
think the Landmark program should have recognized their
inconsistency and ABEND their convert, they don't, so MXG
will now test for wrong length and warn you on the log
that bad records have been found and deleted.
Thanks to Rudra Rishy Maharaj, Stelco Inc, CANADA.
Change 14.041 -Variables CPUTYPE and CPUVERSN are now added to TYPE72GO
EXTY72GO observations. Retained from the last type 70 record, the
VMAC7072 variables were kept in TYPE72 PERFGRP data, so it makes
Mar 5, 1996 sense to keep them also in the TYPE72GO SRVCLASS data, so
Mar 27, 1996 that old reports can be used for WLM reporting.
Apr 23, 1996 -Variable R723RTYP was added to TYPE72GO KEEP= list.
-Change 13.228 was not actually implemented in MXG 13.13,
but its logic (in EXTY72GO to OUTPUT TYPE72GO only if the
service class or report class had activity during the
interval) was finally added in MXG 14.01. Subsequently,
its test for R723TYPE IN(1,2,4) was changed in MXG 14.02
to test for R723TYPE IN(1,2,4,5), because report classes
were being output with all zeroes for report classes
whose associated service classes were never initiated
(e.g., CICS report classes defined on a CICS backup).
-Because R723CRCA is frequently blank even when resources
are recorded for a Service Class, and because it is used
to set R723RTYP values 4 or 5, the logic to set the value
of R723CRCA was changed to now read:
IF R723CADF='1.......'B OR SERVICE+ACTIVETM GT 0 THEN
R723CRCA='Y';
Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.
Change 14.040 TCP/IP release 2.2.1 prior to APAR PN40511 was a user SMF
VMACTCP record with ID greater than 128, but if you used ID=118
Mar 5, 1996 for this old release, you caused MXG to print UNEXPECTED
TCP/IP DATA message notifying you that MXG had deleted a
record. However, if the bad record happened to have "S"
in column 69, MXG failed with INPUT STATEMENT EXCEEDED.
Correcting SMF TYPE eliminates the error (and with that
APAR and later releases of TCP/IP, you no longer can set
the ID, it is fixed at 118), but I added protection to
avoid the STOPOVER condition.
Thanks to Jim Majors, Barnett Technologies, USA.
Change 14.039 Altai & CA job schedulers can't restart a multi-step SAS
MXGSAS job due to the DISP=(MOD,PASS) on the //NULLPDS DD
Mar 4, 1996 statement in the JCL procedure to execute SAS, because
you cannot restart a step that needs passed datasets.
However, if you could change PASS to DELETE, the step
would be restartable, and since NULLPDS exists only to
satisfy JCL syntax for the LOAD and SASAUTO symbolic
parameters, and since NULLPDS is never actually opened,
it would be safe to change the PASS to DELETE. However,
when PASS was changed to DELETE, now a second execution
of the PROC fails with ABEND 213-04, and the matter is
still under investigation. Stay tuned.
Thanks to Neil Ervin, Huntington Services, USA.
Change 14.038 Consistency clean-up. Datasets DCOLAI and DCOLCN did not
VMACDCOL have variable ZDATE in their KEEP= list, but now they do.
Mar 3, 1996
Change 14.037 MAINTLEV 8 of the MXG Tape Mount and Allocation Monitor.
ASMTAPES Two principal changes: Use of the CVT to load the return
ZASMTAPE address of the SRB routine, so we will no longer be
Mar 3, 1996 dependent on the SRB DSECT to properly exit the SRB, and
far more stringent use of the lockword; the SRB will now
exit immediately if it is unable to obtain the lockword,
whereas prior versions assumed we were serialized and
continued to process. MAINTLEV 7 has failed only once at
only one site (but it was in its SRB routine, while in
FRR), and it may have caused another ASID to fail! Dumps
of that failure did show the exposure in our SRB routine
that are now corrected.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 14.036 Support for type 6 ESS segment decoding is added and is
IMAC6ESS externalized in new IMAC6ESS. By default, no fields in
Mar 3, 1996 the ESS segments will be decoded until you remove the
comment block in this member. You will also want to set
the desired LENGTH of the new variables to be kept, and
if you want the ESS variables in your PDB.PRINT, you will
also need to update _PDB_6 macro in IMACPDB.
Thanks to Martin Wieland, Neckermann B.V., THE NETHERLANDS.
Change 14.035 Format MGD145S (for DB2 trace IFCIDS 124, 145, and 183)
FORMATS should map binary, not hex values, so the X's on both
Mar 3, 1996 sides of the equal sign were removed.
Thanks to Joe Faska, Depository Trust, USA.
Change 14.034 NDM subtypes 'SI' and 'ST' were not correct. In the 'SI'
VMACNDM section, insert +4 between INPUT and NDMUNODE, and
Mar 2, 1996 change $EBCDIC8. after NDMUID to $EBCDIC64. In the 'ST'
section, change $EBCDIC8. after NDMUID to $EBCDIC64.
Worse, I discovered NDMTIME and most other NDM datetime
variables were missing. Thirteen lines that now read
IF DATEYYYY GT 80000 THEN ....
must be changed to read
IF DATEYYYY GT 0 THEN ....
This error was "fixed" by Change 13.178, but that change
was not actually made in my source library until now!
Thanks to H. van den Bergh, Rabofacet, THE NETHERLANDS.
Change 14.033 CMF user SMF record subtype 27 (Cache Controller) did not
VMACCMF recognize 3990-6 control unit records. Change the test
Mar 2, 1996 IF CMF27MDL = '93' ... to IF CMF27MDL IN ('93','96') ....
Thanks to Gavin Ring, Alcatel, AUSTRALIA.
Change 14.032 Support for FACOM MSPE/EX PTF 93061 for the ID=127 SMF
VMACF127 record has been updated by this user contribution.
Mar 2, 1996
Thanks to Ian Heaney, Toyota, AUSTRALIA.
Change 14.031 Specifying %ANALDB2R(PDB=SMF); unexpectedly requires a
ANALDB2R //PDB DD UNIT=SYSDA,SPACE=(CYL,(1,1))
READDB2 because three new-in-DB2-4.1-datasets default to PDB in
Mar 1, 1996 IMACDB2, and ANALDB2R did not intercept and override that
Mar 6, 1996 default for those datasets when it called READDB2, which
was the real culprit, and which was fixed by this change.
This change eliminates the need for //PDB when PDB=SMF
is specified.
Thanks to David Klein, City of New York DOITT, USA.
Change 14.030 Support for IMS log record processing for IMS 5.1.
ASMIMSL5
IMACIMS Note: MXG Strongly recommends you use a monitor, such as
IMACIMS7 Boole & Babbage's IMF (MXG support in TYPECIMS) or Candle
TYPEIMS7 ITRF (MXG support in TYPEITRF).See "IMS Technical Notes"
TYPEIMSA in MXG Newsletter TWENTY-FIVE before proceeding.
VMACIMS
VMACIMSA This is the revised ASMIMSL5 (use it instead of ASMIMSLG
Mar 5, 1996 for IMS 5.1), VMACIMSA and TYPEIMSA for the JCLIMSLG
Feb 15, 1997 algorithms.
I have also created a new member, TYPEIMS7, which reads
IMS 5.1 and earlier releases (you must set _IMSVERS in
member IMACIMS) to process only the 07 and 08 IMS log
records into new dataset IMS0708 which may be all that
you need for IMS log analysis if you need only the counts
of transactions and resources (i.e., no response time
nor LTERM identification). Dataset IMS0708 will have one
one observation for each IMS Program Schedule, with all
all resources (CPU, DL/I calls) for that schedule, and
variable NMSGPROC in IMS0708 is the count of transactions
that were processed during by that program. TYPEIMS7
does not depend on the ASMIMSLx architecture, and thus it
will be supported for all IMS releases in the future for
IMS accounting and resource capture.
Thanks to G. Cossio, Quercia Software S.P.A., ITALY.
Thanks to Sig. Moreschini, Quercia Software S.P.A., ITALY.
Change 14.029 DFSMS/rmm type "O" INPUT STATEMENT EXCEEDED RECORD LENGTH
VMACEDGS because ther are three different kinds of "O" records:
Feb 29, 1996
MORTYPE= nulls - owner details
= ones - end of volume/owner
= VOLSER - volume/owner information
and there is now owner details in the "ones" record.
The correction in MXG is to make VMACEDGS look like this:
+7 /*RESERVED*/ original
@; inserted
IF MORTYPE NE 'FFFFFFFFFFFF'X THEN inserted
INPUT inserted
MOOWNSUR $EBCDIC20. original
........ nine other lines " original
MOOWNVOL &PIB.4. original
@; inserted
IF LENGTH-COL+1 GE 4 THEN INPUT inserted
MOVOLNO &PIB.2. original
+2 original
@; original
Thanks to Chris Taylor, VF Information Technology Services, USA.
Change 14.028 A collection of discoveries and SAS/CPE product needs:
VMACDCOL -VMACDCOL. Variables UBRECOR and UMRECOR were removed
VMACEREP from the $HEX2 format and $NOTRAN informat, as they are
SPUNJOBS printable characters; ...THEN DAGFNCPY=1; was misspelled
VMACTPM and is changed now to ...THEN DAGFNCPU=1;
Feb 29, 1996 -VMACEREP. Data sets EREPDDR and EREPIOS did not contain
variable INCDTIME in their KEEP= list; now they do. In
EREPSLH dataset, variables SLHRSMAD, SLHRSMRC, SLHERRTP,
and SLHRSMST were not in their KEEP= list, but now are.
-SPUNJOBS. The DROP DATETIME; statement was replaced with
LABEL DATETIME='DATETIME*OF SHIFT*CALCULATION'; so that
DATETIME will now exist in PDB.SPUNJOBS (as it does in
PDB.JOBS already).
-VMACTPM. Variable SYSTEM was added to the KEEP= list
for dataset TYPETPMV.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 14.027 New "IHDRyyyy" members are "INFILE header" exits which
IHDRDCOL are invoked after the header of a raw data record has
IHDRSMF been INPUT, so that you can filter or select which raw
Feb 29, 1996 data records are processed, or write out selected raw
Mar 13, 1996 data records to an external file, etc. The existing MXG
member IMACFILE is the "INFILE header" exit for SMF data
records, and examples in IMACFILE show how you to use an
"INFILE header" exit. The "IHDRyyyy" naming convention
created by this change has prefix "IHDR" for its purpose,
and the yyyy suffix identifies the name of the INFILE.
So IHDRDCOL is the "INFILE header" for raw records read
from the INFILE name of DCOLLECT. And so existing member
IMACFILE should have been renamed to IHDRSMF with the new
convention, but instead I have left IMACFILE as is (so no
incompatibility) and created dummy member IHDRSMF to say
that member IMACFILE should be used for SMF records.
Comments in each IHDRyyyy member document what variables
exist when the exit is invoked.
Mar 13: Discovered while IHDRDCOL exists, I had failed to
insert the %%INCLUDE SOURCLIB(IHDRDCOL) in VMACDCOL! It
goes immediately after the INCLUDE of (IMACZDAT).
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 14.026 New values for Channel Path Description were added to MXG
FORMATS format $MG073CD in member FORMATS:
VMAC73 '12X:OPEN SYSTEM ADAPTER CHANNEL'
Feb 27, 1996 '13X:INTEGRATED SYSTEM DEVICE'
and an undocumented '04'x value found in data is under
investigation. Comments in VMAC73 were revised but no
code changes were made.
Thanks to Sandro Aiello, National Australian Bank, AUSTRALIA.
Change 14.025 Variable DASDMPL in datasets TYPE42DS and TYPE42SR is too
VMAC42 large; the equation must be DASDMPL=RESPTIME*DASDRATE;
Feb 27, 1996 instead of DASDMPL=RESPTIME*IOCOUNT; in two separate
Apr 10, 1996 segments of code. Note the equation has to be moved into
the DO; group after DASDRATE is calculated, and an
DASDMPL=.; must be inserted in the ELSE DO; if DURATM is
zero. (Dividing the old DASDMPL by DURATM will give you
correct DASDMPL in your pre-existing TYPE42xx datasets.)
Also, SMF42SSF was added to TYPE42VL so that SMF42DB2 can
be interpreted, as per APAR OW16039, on Apr 10, 1996.
Thanks to Phil Schwartz, Pershing, USA.
Change 14.024 MXG Support for CICS Excluded Fields is enhanced so that
IMACEXCL version-dependent-exclude-lists are supported. The three
Feb 27, 1996 user macros _CICXCU2 (V2 NON-ESA), _CICXCUS (V3 ESA) and
_CICXCU4 (V4 ESA) can now be used together so if you have
a different exclude list for V2 and for V3, you would
then use this statement:
MACRO _CICXCTR _CICXCU2 _CICXCUS %
and MXG will apply the appropriate exclude logic to the
appropriate SMF record (assuming, of course, that you
have used UTILCICS output as input to tailor IMACEXCL in
both _CICXCU2 and _CICXCUS (for this example).
The actual change which makes this possible is to insert
IF 33.0 LE SMFPSRVR LE 33.3 after MACRO _CICXCUS
and to insert END; before the single percent sign that
ends the MACRO _CICXCUS definition, and to insert
IF SMFPSRVR LE 3 after MACRO _CICXCU2
and to insert END; before the single percent sign that
ends the MACRO _CICXCU2 definition, and to then find the
last END; statement in MACRO _CICXCU4 definiton and move
it to just before the single percent sign that ends the
MACRO _CICXCU4 definition.
Also, GMT conversion of STRTTIME, ENDTIME for CICS 4.1
was added to IMACEXCL using MCTMNTAD as in VMAC110.
Thanks to Peter Weaver, Canadian Tire Acceptance Corporation, CANADA.
Change 14.023 NPM SMF type 28 record VVR (VTAM Virtual Route) segment,
VMAC28 variable VVRPSWMX and the 9 following VVRxxxxx variables
Feb 26, 1996 were trashed because of wrong input lengths.
Variable Was Input as Must be Input as
VVRPWSMX &PIB.4. &PIB.2.
... ... ...
VVRWAIT &PIB.2. &PIB.4.
VVRSND &PIB.2. &PIB.4.
VVRRCV &PIB.2. &PIB.4.
Thanks to David Faught, Woolworth Corporation, USA.
Change 14.022 For DB2 report PMAUD03, but only if your PDB is on tape,
ANALDB2R syntax error on dataset T102S169 because of a misplaced
Feb 26, 1996 semi-colon. Find %MACRO PMAUD03; then find t102s145;
Move that semi-colon that follows t102s145 to instead
follow the T102s169 on the next line (i.e., the select
statement ends after T102s169, not after t102s145).
Thanks to Joe Richard, MBNA, USA.
Change 14.021 INPUT STATEMENT EXCEEDED with EREP CLASRC='40'X record
VMACEREP due to a missing @! Find the LAST occurrence of LENLEFT,
Feb 26, 1996 and change the semi-colon to an at-sign semi-colon:
INPUT SDWAVRA1 $VARYING55. LENLEFT @;
Thanks to Victor Chacon , NYNEX Mobile Communications Company, USA.
Change 14.020 SMS has caused I/O errors when it does the allocation of
JCLINSTL SAS data libraries and sets default DSORG other than
Feb 23, 1996 DSORG=PS, so I have added DSORG=PS to the DCB= parameter
in member JCLINSTL, just in case!
Thanks to Andre Micheaux, Michigan National Corporation, USA.
Change 14.019 Support for OS/390 Release 1.0 is already in MXG 13.13!
none Well, at least according to IBM's early documentation,
Feb 22, 1996 there appear to be no impacting changes on MXG Software.
The value of MVSLEVEL in TYPE70 and PDB.RMFINTRV may be
SP5.3.0 or T010101, as IBM changed CVT field values, but
that has no impact on MXG's build programs. This note
will be updated if real data records do impact!
Change 14.018 Documentation of possible INCOMPATIBILITY, if your report
TYPETMS5 programs used the archaic TMSRECS or DSNBRECS datasets.
Feb 22, 1996 These very old data set names did contain most of the
important fields, but since version 9.9 when TYPETMS5
replaced TYPETMS, the MXG dataset names for the TMS data
have been TMS.TMS and TMS.DSNBRECD. If you missed that
change, your report program still ran, because datasets
TMSREC and DSNBREC were still in the //WORK file. But
last summer, to clean up the //WORK file, I added code to
delete the TMSREC TMSRECS DSNBREC DSNBRECS and DSNBRECD
datasets, so now your old program fails because it is
still looking for these nonexistent data sets! The fix
is to use the TMS.TMS for TMSRECx and TMS.DSNBRECD for
DSNBRECx in your report programs, but I apologize for
failing to alert you to this incompatibility!
Thanks to Guy Sayers, Fleet Services Corporation, USA.
Change 14.017 VARIABLE SYSTEM IS UNINITIALIZED message with ASMIMSLG
TYPEIMSA processing member TYPEIMSA is cosmetic because the SYSTEM
Feb 21, 1996 variable only exists if specified in a SYSPARM() on the
// EXEC statement, and SYSTEM is created separately in a
later phase of TYPEIMSA, but the error was introduced by
Change 13.237 (which added IMACZDAT logic). The block in
MXG 13.13 that reads: should have been:
IF _N_=1 THEN DO; IF _N_=1 THEN DO;
ZDATE=TODAY(); SYSTEM=SYSPARM();
END; END;
Thanks to Chris Metzie, University of Wisconsin, USA.
Change 14.016 Variable CSCS should not be used, as it is decoded into
VMACACHE separate variables CSHT, CSIS, CSPA, CSDS, CSIM, CSDC.
Feb 20, 1996 The MGCACST format on CSCS is also incorrect. Because
there are two reserved bits in CSCS, it is still kept (in
case IBM uses those bits) and is now formatted HEX2.
(Between 12.12 & 13.13, the CSCS=FLOOR(CSCS/32) statement
was removed, as it too was incorrect.)
Thanks to John Larry, W. H. Smiths, ENGLAND.
Change 14.015 Hipercache records for VSAM datasets were wrong; a field
EXHIPRBU had been missed, but moreover the MXG design was wrong.
IMACHIPR Dataset VMACHIPR was redesigned to now create new dataset
VMACHIPR HIPRVSBU containing detail buffer statistics from each of
Feb 16, 1996 the buffer segments
Mar 4, 1996 HIPBFS HIPBFT HIPBUFFS HIPFFH HIPFR HIPFTH HIPHFR
Mar 15, 1996 HIPHFW HIPHSB HIPHSR HIPHSW HIPIO HIPLK HIPMFH
HIPMTH HIPWR
and the new variables are then summed across each record
and output in HIPRVSAM dataset (replacing the twelve sets
of fourteen variables named SMFnnXXX that are no longer
created). With real data records, the better design was
obvious. Common variables allow joins between the two
datasets, should the need arise, and space is saved.
Mar 15: PRIMARY or SECNDRY added to labels for variables.
Thanks to Chuck Hopf, MNBA, USA.
Change 14.014 TLMS year 2000 dates were not decoded correctly after
VMACTLMS Change 13.186. A raw date value of '0102037F'x (century
Feb 15, 1996 bit, year 2, day 37, for Feb 6, 2002) should have printed
Feb 22, 1996 as 2002037 but instead printed 104037. In correcting my
error, I also decided to make the TLMS dates to be real
SAS dates instead of numbers.
The original TLMS code used numbers and since I
thought TLMS sites would get a free conversion to TMS,
I left the old format in place, but since I have to
correct this error, it made sense to go ahead and
convert the numbers into SAS dates. However, if you
are using any of the twelve date fields in tests in
your report programs (instead of just printing them),
you will need to change your report logic. The numeric
value of 2002037 becomes the SAS date value of 15377
(days since Jan 1, 1960) when DATEJUL() is used, so
it will print as 02Feb2002 when formatted DATE9.
However, TLMS uses two special values for the raw date
field; zero if the fx. retention period has expired,
and 9999999 if the tape is registered as 'permanent'.
I chose to force the zero value to a date of '01JAN1960'd
and the 9999999 value to a date of '31DEC2099'd (similar
to the way I handled strange dates in TMS records!).
To correct the MXG error AND convert to SAS dates, each
of the twelve lines for variables BAPURCH thru BAIDATE
must be changed from one line:
var=FLOOR(var/100000)+100+var+1900;
to these six lines:
IF 0 LT var LT 9999999 THEN DO;
var=1000*(FLOOR(var/1E5)*100+1900)+MOD(var,1E5);
var=DATEJUL(var);
END;
ELSE IF var EQ 0 THEN var='01JAN1960'D;
ELSE IF var EQ 9999999 THEN var='31DEC2099';
and those twelve variables are now formatted DATE9.
Thanks to Jorge Fong, City of New York, USA.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Change 14.013 INVALID DATA FOR HH,MM,SS messages with SAMS record. The
VMACSAMS three lines inputting HH MM SS with &NUM.2 need to be
Feb 15, 1996 changed to &NUM.2. (i.e., the final period was missing).
Fortunately, only variable SAMSTIME was incorrect.
Thanks to Shaheen Pervaiz, Acxiom, USA.
Change 14.012 Example JCL for reading Landmark's The Monitor for CICS
JCLTMON shows what is needed to process TMON/CICS data daily.
Feb 14, 1996
Thanks to Charles Brown, Fruit of the Loom, USA.
Change 14.011 DB2 4.1 type 101 subtype 1 (written only if more than 10
VMACDB2 Packages are called by a Plan) INPUT STATEMENT EXCEEDED
Feb 13, 1996 because of a mis-located line of code (and no previous
May 22, 1996 test data!). Find the second occurrence of statement
SKIP=LENQPAC-240;. Move the next line (IF SKIP GT 0 THEN
INPUT +SKIP @;) down (about 30 lines) so that it
immediately precedes the statement
%%INCLUDE SOURCLIB(EXDB2ACP);
May 22: original text of this change had -140 vice -240.
Thanks to Mick Glasson, Health Insurance Commission WA, AUSTRALIA.
Change 14.010 NOTSORTED error with WEEKBLD, WEEKBLDT, or MONTHBLD. The
MONTHBLD variable USER was added by Change 13.268 to ASUMCICS, but
WEEKBLD was not added in the _BYLIST macro for the _DSET CICS.
WEEKBLDT In all three members, change the bylist to read:
Feb 12, 1996 APPLID OPERATOR USER TERMINAL STRTTIME TRANNAME
Thanks to Scott Snyder, Card Establishment Services, USA.
Change 14.009 A truncated PSF type 6 SMF record caused INPUT STMT EXCED
VMAC6 error; the record had LN4=116 but there were only 82 byte
Feb 9, 1996 left in the physical record. While IBM is investigating,
to circumvent, change IF SMF6LN4 GT 84 THEN DO; to read
IF SMF6LN4 GT 84 AND LENGTH-COL+1 GE 32 THEN DO;
Thanks to Leonard Issacs, Motorists Mutual Insurance COmpany, USA.
Change 14.008 INVALID DATA FOR PWCOUNT in VMID=06 with PWCOUNT=0Ax. The
TYPEVM logic for decoding these invalid values in VMID=04 should
Feb 8, 1996 be copied into the VMID=06 processing to correct the bad
value for PWCOUNT (which is EBCDIC for 0-9, but then is
binary for larger values!).
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 14.007 Variable SMF73CPD has stored length of 39; the variable
VMAC73 must be added to the LENGTH statement with SMF73CPD $1
Feb 8, 1996 to correct the stored length. (SAS sets character length
from the first occurrence of the variable, and without
the LENGTH statement, SAS saw the FORMAT statement, and
set the length of the variable to the length of the
longest format value!). I know I must always add the
variable to the LENGTH statement - this one I missed!
Thanks to S. Lemaire, Comparex Information Systems, Belgium.
Change 14.006 SAS 5.18 only. Formats $MGERPDS/PHD/PMC/PRC/PSE and PSF
FORMATS were longer than 40 characters, causing errors. Formats
Feb 8, 1996 were re-worded to fit in 40 characters, to be consistent
with all formats, even though SAS version 6 has no error.
Thanks to Walter P. Kraslawsky, Library of Congress, USA.
Change 14.005 Invalid NETSPY type A record caused INPUT STATEMENT ERROR
VMACNSPY because NSPYENTL=108 in the record, but should be 340,
Feb 8, 1996 and with a minimum of 145 bytes. CA had no report of the
bad record, which only occurred sporadically. To avoid
the error until CA fixes it, in the block of code for
IF NSPYREC='A' THEN DO;
immediately before the statement
DO OFFNSPY=NSPYOFF TO ENDREC BY NSPYENTL;
insert
IF NSPYENTL GE 145 THEN
so the INPUT is only executed for valid records.
This note will be updated when more is heard from CA.
Thanks to George Janvrin, ITT Hartford, USA.
Change 14.004 INPUT STATEMENT EXCEEDED RECORD LENGTH for Type 64 if the
VMAC64 CF Cache Structure Statistics segment exists. The input
Feb 6, 1996 of three variables, SMF64BMH, SMF64CFH, and SMF64RIO must
be &PIB.4. instead of &PIB.8. in all three lines.
One sites also saw this when they brought up ESA 5.2.2.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 14.003 Change 13.331 to support four-digit UCBs in this archaic
VMXGVTOF DASD grazer were wrong, producing RC=256 error messages.
ASMVTOC (Member ZASMVTOC is the prior iteration of ASMVTOC, so
Feb 9, 1996 you could revert.) This new ASMVTOC has been tested and
Feb 26, 1996 now appears to execute correctly, and with the second
iteration on Feb 26, the program has been verified with
actual four-digit UCBs. (ASMVTOC is archaic in that the
DCOLLECT utility and TYPEDCOL are the recommended method
for grazing your DASD VTOCs and VVDSs.)
Thanks to Astrid Fridtun, Statens DataSentral a.s., NORWAY.
Change 14.002 APPARENT SYMBOLIC MXGDEBUG error occurs if CONFIG06 is
VMXGINIT used instead of CONFIG, because VMXGINI6 (pointed to by
Feb 2, 1996 the archaic CONFIG06) did not include MXGDEBUG in its
list of macro names in the %GLOBAL statement.
Thanks to Will Evans, Consolidated Freight, USA.
Change 14.001 INPUT STATEMENT EXCEEDED RECORD LENGTH for STC subtype 8
VMACSTC record; support added in October finally read a real SMF
Jan 23, 1996 record and failed, because fields were re-defined in the
Feb 22, 1996 DSECT, but I missed the redefinition. After the line
ELSE IF SUBTYPE='....1000'B THEN DO; insert
M1=-1; before the line
INPUT @21+OFFSMF
Then, on each of the five lines inputting the variables
STC08CID, STC08MAG, STC08LS2, STC08XPT and STC08SLT,
put +M1 on each line, to the left of the variable
i.e., the input for STC08CID would then look like:
+M1 STC08CID $CHAR1. /*CAP*ID*/
so these redefined variables are input from the same
byte as their predecessors.
(Feb 20 correction added STC08CID and STC08MAG).
Thanks to Mike Hildman, Target Stores, USA.
Thanks to Chuck Hopf, MBNA, USA.
LASTCHANGE: Version 14
==========MXG 13.13 dated Jan 20, 1996, thru Change 13.332============
=========================member=CHANGE13================================
/* COPYRIGHT (C) 1984-1996 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is MXG Version 13.13, dated Jan 20, 1996, thru Change 13.332.
MXG Version 13.13 is dated Jan 20, 1996, thru Change 13.332
Newsletter TWENTY-NINE, dtd Jan 20, 1995, 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
Initl 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
Contents of member CHANGES:
I. MXG Software Version Status.
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. Incompatibilities and Installation of MXG 13.13.
IX. Online Documentation of MXG Software.
X. Changes Log
I. MXG Software Version Status.
1. MXG Software Version 13.13, dated January 20, 1996, was shipped
with newsletter, NEWSLETTER TWENTY-NINE.
Major enhancements added in MXG 13.13 dated Jan 20, 1996:
Added after Newsletter 29 was sent to the printer:
Support for 4-digit UCBs in DCOLLECT, ASMVTOC and ASMVVDS.
Support for DOS/VSE POWER 5.2 Accounting Records
Support for MVS Catalog records (Exported with IDCAMS)
Included in Newsletter 29 list of enhancements in MXG 13.13:
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
II. MXG Technical Notes.
III. MVS Technical Notes after Newsletter TWENTY-NINE.
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
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.
ASMVTOC 13.331 Support for 4-digit UCBs.
ASMVVDS 13.330 Support for 4-digit UCBs.
ASUMCICS 13.268 Default summarization now includes USER.
BUILDPDB 13.320 CODEPASS=2 now set only for MVS execution.
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.
FORMATS 13.319 OTHER= syntax now works under MVS or ASCII.
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.322 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.
TYPECTLG 13.325 Support for MVS Catalog Records exported by IDCAMS.
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).
TYPEDCOL 13.332 Support for 4-digit UCBs.
TYPEDOS 13.328 Support for DOS/VSE POWER 5.2 Accounting Records.
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.219 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.
VMACEXC2 13.329 Supression of excess INVALID DEVICE messages
VMAC102 13.273 Support for DB2 4.1 IFCIDs 221, 222, and 231.
VMAC110S 13.323 CICS 2.1 and SAP journal segments intermixed fix.
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:
NEXTCHANGE: Version 13
==========MXG 13.13 dated Jan 20, 1996, thru Change 13.332============
Change 13.332 Support for 4-digit UCB's in DCOLLECT required only that
VMACDCOL the format for variable DCVDVNUM be changed from HEX3 to
Jan 19, 1996 HEX4.
Thanks to Astrid Fridtun, Statens datasentral, NORWAY.
Change 13.331 Although DCOLLECT should be used instead of this old MXG
ASMVTOC Assembly routine, the program has been enhanced to handle
VMXGVTOC 4-digit UCB addresses, and VMXGVTOC has been modified to
Jan 18, 1996 look for the 4-digit address at the end of the record
created by ASMVTOC.
Thanks to Astrid Fridtun, Statens datasentral, NORWAY.
Change 13.330 Although DCOLLECT should be used instead of this old MXG
ASMVVDS Assembly routine, the program has been enhanced to handle
Jan 18, 1996 4-digit UCB addresses. The TYPEVVDS program was already
written to support 4-digit addresses, so it was okay!
Thanks to Astrid Fridtun, Statens datasentral, NORWAY.
Change 13.329 ERROR VMACEXC2.2 INVALID DEVICE DATA is printed for each
VMACEXC2 DD segment with non-zero EXCPCNT that has DEVCLASS=00,
Jan 18, 1996 DEVTYPE=00, and DEVNR=00, because MXG does not know what
to do with EXCPCNT in a DD segment which has no device!
However, the message is printed for EACH DD, filling the
SAS log with these messages from an MVS 3.1.3 system. No
other site has encountered the problem, and the site is
investigating to determine what is unique there, but to
prevent filling the log, the PUT statement is now limited
to the first ten occurrences. The existing EXC2ERR1=1;
statement was changed to EXC2ERR1+1; to make it a counter
and a new line inserted between that statement and the
PUT statement reading IF EXC2ERR1 LE 10 THEN so that
the message is supressed after ten occurrences.
Thanks to Warick Smith, Sun Alliance & Royal Insurance, AUSTRALIA.
Change 13.328 Support for DOS/VSE POWER 5.2 Accounting Records. IBM
IMACDOS again changed the records INCOMPATIBLY, so you must EDIT
TYPEDOS member IMACDOS to specify OFFSET=0 and INPUT @43 RECID.
Jan 17, 1996 to process POWER 5.2 records.
-Additionally, the choice between "American" MMDDYY dates
and "European" DDMMYY dates was externalized into member
IMACDOS (previously, you had to actually change the code
in member TYPEDOS for European formats.). If you have a
member IMACDOS in your USERID.SOURCLIB, you must replace
your existing IMACDOS with IMACDOS from MXG 13.13, or
you will get a VARIABLE _MMDDYY IS UNINITIALIZED message.
Fortunately, even with that message, if your dates are in
American format, MXG 13.13 will still work correctly with
your old IMACDOS. If your dates are in European format
and you use the old IMACDOS, you will also get messages
INVALID ARGUMENT TO FUNCTION MDY and your date values
will be missing until you replace your old IMACDOS with
the IMACDOS from MXG 13.13 (and tailor it for European).
-Finally, MXG code was corrected for the Reader record and
variable FROUSRID $EBCDIC8. is now INPUT after LOCLNODE
is read in. Without this correction, an INPUT STATEMENT
EXCEEDED RECORD LENGTH error occurred if a reader record
did not contain a Network Account Number.
Thanks to ???, Alenia, ITALY.
Change 13.327 The statement %INCLUDE SOURCLIB(IMACZDAT); must be
TYPEMON8 %%INCLUDE SOURCLIB(IMACZDAT); because it is
TESTUSER inside an old-style macro definition (and TYPEMON8 was
Jan 17, 1996 inadvertently removed from TESTUSER, so I missed this!)
MXG 13.07 thru MXG 13.09 only.
Thanks to Andrew Scales, Nissan UK, ENGLAND.
Change 13.326 IDMS Severity Code, TASMSSEV no longer exists in IDMS 12,
VMACIDMS and variable TASABMSG was miscalculated. The statement
Jan 16, 1996 TASMSSEV=MOD(TASABMSG,10); was replaced with TASMSSEV=0;
and the statement TASABMSG=INT(TASABMSG/10); was deleted.
Also, variables DBKKYFMT and DBKLTYPE are now formatted
as HEX8 and DBKOWNER as $HEX2 so as to be recognized by
IDMS-literate database administrators in their tongue!
Thanks to Martin Wieland, Neckermann B.V., THE NETHERLANDS.
Change 13.325 Support for Catalog Records (Exported with IDCAMS). A
EXCTLGC1 separate dataset for each of the 13 Catalog Segments is
EXCTLGC2 created for complete decoding of all possible segments
EXCTLGC3 (and variable CATRECNR can be used to collect all of the
EXCTLGC4 segments from a specific catalog record). In addition,
EXCTLGC7 two datasets are created from specific records:
EXCTLGC8 CTLGDSN - Non-VSAM Data Set record (sequence of catalog
EXCTLGC9 segments C1/01/04/04/...). The first five
EXCTLGDS VOLSERs are kept in CTLGDSN.
EXCTLGD9 CTLGVSAM - VSAM Cluster record record (sequence of
EXCTLGE3 C3/01/C4/01/04/.../C9/01/04/04...). The
EXCTLGVS first Data VOLSER and the first Index VOLSER
EXCTLG01 are kept in CTLGVSAM.
EXCTLG02 This preliminary support code detects and deletes a few
EXCTLG03 "strange" records (always at the beginning of the Export
EXCTLG04 file), printing messages on the log. After MXG 13.13 is
EXCTLG05 built and early users have played with this new support,
EXCTLG06 I intend to examine the strange records further. I also
IMACCTLG need feedback as to intended use of the catalog records
TYPECTLG to enhance contents of the record-level datasets CTLGDSN
VMACCTLG and CTLGVSAM (and may need to add a CTLGGDG dataset!).
Jan 16, 1996 See documentation in the member on usage.
Thanks to Dale Houg, Kraft Foods, USA.
=======NEWSLETTER TWENTY-NINE Printed Changes THRU Change 13.324=======
Change 13.324 If PDBOUT=WORK was specified for READDB2, the datasets
READDB2 were written to //WORK, but then inadvertently deleted!
Jan 13, 1996 Now, they will remain in the //WORK file as requested.
Change 13.323 For CICS 2.1 and SAP, SAP journal segments (which should
VMAC110S be in a subtype=0 type 110 record) are intermixed with
Jan 13, 1996 IBM performance records in records with subtype=1, and no
one at SAP AG can tell why! (See text of Change 13.261).
This problem has only been seen with CICS 2.1 (which is
already off IBM support) at one site, and they were smart
enough to create logic to deal with that aberration and
share it with me, so I have created new member VMAC110S
by adding their workaround to the MXG 13.13 VMAC110 code.
I do not have test data records but have a hex dump of an
example bad record and have validated their logic in that
manner. If you still have CICS 2.1 and have SAP writing
data to the type 110, you should test this new member
and compare the number of observations output in all of
the CICxxxxx datasets; if they are the same, you need not
use VMAC110S, but if you have the defective records, the
normal VMAC110 will throwaway records and you will have
fewer observations output (or SAS may loop!).
To use the VMAC110S member instead of the normal VMAC110,
copy member VMAC110S into your USERID.SOURCLIB library
and rename it to VMAC110.
Thanks to Paolo Carloni, Agip petroli SPA, ITALY.
Change 13.322 Hex dumps of BETA93 release 01.06.50 records have now
VMACBETA been reviewed (See Change 13.304) and they show new time
Jan 13, 1996 values are misdocumented by the vendor. Some binary are
actually HH MM SS in PK1. fields, some HHMMSS are
SMFSTAMP8, and one SMFSTAMP8. field is reversed (date
first, time 2nd!). This change should complete support
for the new release.
Change 13.321 Duplicate LABELs were removed from members ASUM70PR,
DOC ZMACTMVS, and VMAC members 110, 110M, 30, 33, 42, 60, 74,
Jan 13, 1996 80A, 84, BETA, CMF, DCOL, HPAI, HPCS, LMS, MEMO, NDM,
NSPY, RRTM, SAMS, and TPX.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.320 The SAS option CODEPASS=2 is now set only for execution
BUILDPDB under MVS, because CODEPASS is an MVS-only option, but
BUILD001 it causes an ERROR 2-12 INVALID OPTION NAME under ASCII
Jan 13, 1996 SAS. (In actuality, CODEPASS=2 is an MVS compiler option
that has no measurable effect on BUILDPDB, but if the
default CODEPASS=1 is in effect, SAS prints a note on
the log suggesting that CODEPASS=2 might reduce run time
so I specify CODEPASS=2 mostly to suppress the message,
rather than for any performance improvement.)
Change 13.319 The syntax OTHER="left bracket" $HEX2. "right bracket"
FORMATS or OTHER=("vertical bar" $HEX2. "vertical bar") cannot
Jan 12, 1996 be used on both EBCDIC and ASCII platforms. The left
and right brackets do not exist on MVS, and the vertical
bar ('4F on MVS) becomes '5D'x on ASCII, which must be
changed to '7C'x to work under ASCII. Fortunately, the
CHARCODE system option allows a pair of characters to
replace right and left brackets, so the syntax of
OTHER= ?< $HEX2. ?> can be used, as long as the
code is preceded by OPTIONS CHARCODE;, which has now
been added in the FORMATS member to allow this part of
MXG to execute transparently under either ASCII or MVS.
Thanks to Terry Poole, SAS Institute Cary, USA.
Change 13.318 Comparing the CPU times in VM/ESA MONWRITE data, PFXUTIME
VMACVMXA was significantly higher than VMDTTIME, because the data
Jan 11, 1996 for the time from end of last interval to logoff was not
captured. Initially, Ian's rework of the VXBYUSR code
was to use the USEINT data, but he is now convinced that
that data is not complete, and he has suggested to IBM to
include that CPU time (the time from logon to the first
interval) in the USELOF data. Now, however, his rework
produces more VMDTTIME from the combined USEACT & USEINT
datasets than the sum of PFXUTIME and PFXTMSYS derived
from the SYTPRP records! I have implemented Ian's design
in new macro _TESTMWX, which you can use in place of the
normal TESTMW macro, to see how the CPU times captured in
the user records (VMDTTIME) compares at your site. Please
let me know your results; this note will be updated based
on your feedback of his algorithm.
2016: No feedback was ever received, use _DBYUSR/_DELTALL
Thanks to Ian Davis, Worker's Compensation Board of Alberta, CANADA.
Change 13.317 Support for FRYE Systems LAN monitor for NETWARE.
ADOCFRYE Their monitor stores data into five DbaseIII files. This
ASUMFRYE support uses PROC DBF (a part of PROC ACCESS) to convert
GRAFFRYA DbaseIII into SAS files, and produces some very nice SAS
GRAFFRYT plots from the resultant file. This code can only be
IMACFRYE executed on a SAS ASCII platform, as the DBase files can
TRNDFRYE not be uploaded to a mainframe, and PROC DBF only exists
TYPEFRYE on ASCII systems. The member ADOCTYPE provides early
VMACFRYE documentation of the Netware data captured, and also has
Jan 11, 1996 three examples of converting DbaseIII into SAS (PROC DBF,
PROC ACCESS, and a DATA step).
Thanks to Chuck Hopf, MBNA, USA.
Change 13.316 Variables WRHITPCT, RDHITPCT, CHITPCT, CACHRATE, DASDRATE
FORMATS HITPCT and CIOPCT in datasets TYPE42SR and TYPE42DS and
VMAC42 the twelve S42AMxxx variables in TYPE42DS were not set to
Jan 11, 1996 a missing value when they could not be calculated or when
the fields did not exist, so values from a prior segment
in the same record were carried forward incorrectly. An
ELSE clause now sets these variables missing when needed.
The TYPE42DS records variable INTVCLOS indicates whether
the record is for an Interval or Close event, and I had
thought the Close record contained total counts for the
entire open; however, the Close event actually contains
only the counts between the end of the last interval and
the Close, so I have changed the INTVCLOS format values
from 0:CLOSE TO 0:FINAL INTERVAL.
Thanks to Peter Lauper, Bank of America, USA.
Change 13.315 Blue Line Software's Release 4.03 and 4.04 cause INPUT
VMAC28 STATEMENT EXCEEDED RECORD LENGTH with type 28 subtype D6x
Jan 10, 1996 D7x or D9x SMF records. Their fixes are 4030030/4030031
for 4.03 and 4040035 for 4.04. All are reported fixed in
their release 4.10, currently in beta testing. I have
added traps in MXG to recognize their short records and
prevent the ABEND.
Thanks to Kevin Batten, Roses Stores, Inc, USA.
Change 13.314 Variables MVCRTIME,MVLCTIME and MVUCTIME in EDGSVREC
VMACEDGS dataset should have been LENGTH 8 with DATETIME21.2
TYPETMS5 format, and variable DSAUTIME in dataset DSNBRECD should
Jan 10, 1996 have been LENGTH 8 with DATETIME18.; now all are!
Thanks to Freddie Arie, Lone Star Gas, TEXAS
==========MXG 13.09 dated Jan 10, 1996, thru Change 13.313============
Change 13.313 Support for MVS/ESA 5.2.2 Open Edition MVS (OMVS) adds
VMAC92 new flag variable SMF92MFG to TYPE9201 and SMF92UFG to
Jan 9, 1996 TYPE9205 to identify the mounter/unmounter of the file
system, and new subtype 6 (for File System Remount) will
now be output in TYPE9205 dataset (and variable SMF92STP
was added to identify Unmount or Remount).
Unfortunately, the new flag fields were inserted in the
subtype 1 and 5 records, incompatibly altering format.
Change 13.312 Support for DFSMS/MVS 1.3 (compatibly) added several new
VMAC64 variables for VSAM Record Level Sharing (RLS), including
Jan 9, 1996 separate counts of I/O requests satisfied from LSR, DASD,
or the CF (Coupling Facility) Cache Structure (variables
SMF64BMH,SMF64RIO, and SMF64CFH, respectively), and flag
variables to identify if RLS is in effect, if RLS is in
effect but measurement has been turned off, or if this is
an extended addressable dataset. When VSAM RLS is in use
existing Hiperbatch fields and buffer counts are zeroed,
and EXCP count variables ACCEXCPS and EXCPs count buffer
manager request rather than SSCHs.
Change 13.311 Support for DFSMS/MVS 1.3 (compatibly) added four new
EXTY42D1 subtypes for VSAM Record Level Sharing (RLS) activity,
EXTY42D2 with excellent measurement of RLS's usage of CF structure
EXTY42L1 (counts and durations and response). MXG creates eight
EXTY42L2 new datasets from these four new subtypes:
EXTY42P1 From new Subtype 15:
EXTY42P2 TYPE42S1 - Storage Class Sysplex-wide statistics
EXTY42S1 TYPE42S2 - Storage Class By-System statistics
EXTY42S2 These two datasets provide six sets of 17 variables:
IMAC42 DASD Summary (variables SMF42FCx and SMF42FIx)
VMAC42 DASD REDO (variables SMF42FDx and SMF42FJx)
Jan 9, 1996 SEQ Summary (variables SMF42FEx and SMF42FKx)
SEQ REDO (variables SMF42FFx and SMF42FLx)
SEQ READAHEAD (variables SMF42FGx and SMF42FMx)
SEQ PREFORMAT (variables SMF42FHx and SMF42FNx)
From new Subtype 16:
TYPE42D1 - Data Set Sysplex-wide statistics
TYPE42D2 - Data Set By-System statistics
These two datasets provide six sets of 17 variables:
DASD Summary (variables SMF42GCx and SMF42GIx)
DASD REDO (variables SMF42GDx and SMF42GJx)
SEQ Summary (variables SMF42GEx and SMF42GKx)
SEQ REDO (variables SMF42GFx and SMF42GLx)
SEQ READAHEAD (variables SMF42GGx and SMF42GMx)
SEQ PREFORMAT (variables SMF42GHx and SMF42GNx)
From new Subtype 17:
TYPE42L1 - Lock Structure Sysplex-wide statistics
TYPE42L2 - Lock Structure By-System statistics
These two datasets provide 9/10 variables.
From new Subtype 18:
TYPE42P1 - CF Cache Partition Sysplex-wide statistics
TYPE42P2 - CF Cache Partition By-System statistics
These two datasets provide 33/34 variables.
Change 13.310 Support for MVS/ESA 5.2.2 (compatibly) added new fields:
VMAC30 -TYPE30OM dataset has new variables SMF30OMS,SMF30OMR, and
Jan 9, 1996 SMF30OSY for message queue bytes and sync() functions for
Open Edition/MVS.
Change 13.309 INPUT STATEMENT EXCEEDED INPUT for PSF type 6 SMF record,
VMAC6 because IBM added 32 undocumented bytes to the APA
Jan 8, 1996 section. The change was made by APAR OW10067 and PTF
UW18264, but the description and location of the change
to the type 6 record was not contained in the APAR text!
(nor is the change documented in the 5.2.2 SMF manual).
Change VMAC6 to read:
SMF6PTDV $EBCDIC8. /* ... */ existing
@; existing
IF SMF6LN4 GT 84 THEN DO; insert
INPUT insert
SMF6OCNM $EBCDIC20. /*OUTPUT*COM*NAME*/ insert
+12 /*RESERVED*/ insert
@; insert
SKIP=SMFLN4-116; insert
IF SKIP GT 0 THEN INPUT +SKIP @; insert
END; insert
IF SMF6BNOF GT 0 THEN DO; existing
This error only occurs if the Multi-Bins header and
counter sections exist in the type 6 record.
Thanks to Veronique Planes, SAS Institute, FRANCE.
Change 13.308 Setting BUFNO=220 on the //TMC DD statement can make a
TYPETMS5 dramatic reduction in elapsed time. A fifteen-minute run
Jan 8, 1996 ran in under 4 minutes with increased buffers.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.307 Some very simple HSM reports and a preliminary technical
ANALHSM note on how to measure HSM, and what's important in the
ADOCHSM HSM SMF records has been added in these members.
Jan 7, 1996
Thanks to Chuck Hopf, MBNA, USA.
Change 13.306 Cosmetic changes in MXG 13.08 only. The invoked message
VMXGSUM still had "XMXGSUM" and "13.01" hardcoded, now corrected,
Jan 7, 1996 and the output dataset label was double quotes instead of
blank if no dataset label was provided in the outcode.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.305 Internal, temporary variables named DATE, HOUR, DAY, DAYM
VMXGDUR QTRHOUR HALFHOUR and MINUTE were created and dropped
Jan 7, 1996 inside VMXGDUR macro, which is called by VMXGSUM when
INTERVAL= is specified. If you wanted to keep one of
those variable names, the internal DROP statement
prevented you from doing so (and it was most definitely
not obvious why your VMXGSUM did not work!). Now, the
temporary variables names start with DUR to prevent the
inadvertent loss.
Thanks to Neil Ervin, Huntington Services Company, USA.
Change 13.304 Support for BETA93 Release 1.06.50 (INCOMPATIBLE) inserts
VMACBETA fields in existing records, and adds five new subtypes
Jan 7, 1996 which create five new datasets:
BETA20 - Browse or Print of List or Report
BETA21 - Browse Selection Action
BETA40 - Archive of a List
BETA41 - Reload of a List
BETA42 - Deletion of an Archive Generation Record
Existing variable names were based on the DSECT names,
but this caused the same entity (eg., pages or lines) to
have a different variable name in each of the existing
seven datasets; for consistency and ease in reporting I
have renamed some of these variables, knowing full well
that my changes may cause your existing reports to fail
with VARIABLE NOT FOUND errors, for which I apologize!
Labels were also made consistent and more descriptive.
The changes have been tested with prior release data,
but not yet with records from 1.06.50. See Change 13.322.
Change 13.303 New variable MXGVERSN is kept in TYPE70 and PDB.RMFINTRV
RMFINTRV datasets so you can tell which version of MXG created the
VMAC7072 dataset from SMF. I did not think it necessary to add
Jan 6, 1996 the 6-byte version name ('13.13 ') in each MXG dataset.
Should you need to create MXGVERSN in other datasets,
you can use this logic (as macro variable MXGVERS is a
Global macro, set at SAS initialization by VMXGINIT):
MXGVERSN=SYMGET('MXGVERS');
and then add MXGVERSN to the _K macro defined in the
IMACxxxx member for the product - See Change 10.175.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 13.302 Landmark's TMON for UNIX dataset TUXCPU is now created,
EXTUXCPU all datasets have now been tested with data, and formats
VMACTUX for rates and percentages are now consistent. However,
Jan 6, 1996 there are still unfixed problems that won't be fixed at
least until their ML 3.3 release:
-Datasets TUXCONEC (connections), TUXPROG (program) and
TUXPROC (process) have occasional short records (i.e, one
or more fields and their delimiters do not exist in the
data record!), causing INPUT STATEMENT EXCEEDED LENGTH
errors. Landmark Activity 49861 still open.
-Two undefined fields are in the data record that are not
in the header in TUXNFSCL (nfsclient), TUXSOCK (sockets)
and TUXUSERI (userio), causing variables WRITBLOK,
READPART, WRITPART, READFAIL, and WRITFAIL to be trashed
in those three datasets. Ref. 47164.
-Of more concern, monitor intervals are not synchronized
and timestamp values are very suspect.
I expected one minute interval data to be written each
minute, but the one set of TUXINFO (info) records had
event timestamps starting at 17 seconds after the minute,
drifting to 55 seconds after the minute in only a few
minutes: 17,15,26,28,26,26,...26,36,37,39,44,49,55
New test data for the cpu table (TUXCPU) permits better
analysis, because both EVENTIME (log_time) and the true
HRDWTIME (BOOTTIME plus UPTIME) can be compared.
Both clock shows that interval durations are not only not
synchronized but also are quite erratic, and each record
shows a different interval depending on which clock value
you examine! Comparing durations in the same record:
from hardware clock: 59,99,151,41,60,126,146,113
from log_time clock: 60,97,116,61,60,122,142,118
Comparing the hardware timestamp with the log_time in the
same record shows that the logtime sometimes is only 1-2
seconds later than the hardware timestamp (with a 5-hour
difference between GMT in hardware and EST in local), but
other intervals have a log_time several minutes later
than the hardware time, and a few records are really bad,
with the hour-part difference only two instead of five!
This is clearly a serious problem, and Landmark is now
aware of these discrepancies in their monitor. This text
will be updated when Landmark responds.
Thanks to Dan Sidorick, SmithKline Beecham, USA.
Change 13.301 Decoding DEVCLASS and DEVTYPE in VMACUCB still tested the
VMACUCB first bit of DEVNR and set DEVICE='MSS' if on, but this
Jan 5, 1996 is incorrect now, as four-digit device numbers exist, and
MSS devices do not, so that test is now disabled!
Change 13.300 New variable HIGHRBA is now created in TYPE64 with the
ANAL4GB allocated size (in bytes) of the VSAM file (using logic
VMAC64 from GC26-4574-2 to calculate CI's per track for 3380s
Jan 5, 1996 and 3390s). Member ANAL4GB then identifies those VSAM
files that are over 80% of the IBM hard limit maximum of
4GB for VSAM files, so you can forewarn their owners!
Thanks to Chuck Hopf, MBNA, USA.
Change 13.299 H-P's MEASUREWARE (formerly HP-PCS) does not record true
IMACHPAI CPU seconds in the HPxxGLOB and HPxxAPPL datasets, but
IMACHPSU instead records only the Average CPU time per CPU Engine,
IMACHPUX and then does NOT record how many Engines there are, so
VMACHPAI so you get correct total CPU time from the data records.
VMACHPSU While I regard this as an ERROR, HP considered it only an
VMACHPUX enhancement request! The NRCPUS field is in the CONFIG
Jan 6, 1996 records, but unfortunatly the HP Extract program is hard-
Jan 18, 1996 coded to put the CONFIG records at the end of its output
file. HP was persuaded to provide a workaround Script
that was to sort the Extract output and interleave the
CONFIG records to appear first (and simultaneously, that
interleave would have supported dynamic changes in the
number of engines, if "VARY CPU OFFLINE" ever becomes a
UNIX option!), so MXG logic was reordered to look for the
CONFIG records first, and retain NRCPUS into the needed
datasets. Unfortunately, the first Script did not work
as expected, so HP is back working on the problem as this
Newsletter goes to press. As an interim MXG workaround,
I have added a user-specified macro in IMACHPAI, IMACHPSU
and IMACHPUX which defaults to one CPU, but allows you to
tell MXG if you have more than one Engine. That logic
will be revised when HP provides a solution to the basic
problem, and this text will be revised to point to a
later change when there is a solution.
MEASUREWARE records are NOT supported in MXG 13.13; as I
stated in this text in Newsletter TWENTY-NINE, I had just
received test data as that newsletter went to print, and
now my fears are confirmed: HP made INCOMPATIBLE changes
between PCS records and MEASUREWARE records that will
require significant changes in MXG support. If you are
replacing HP-PCS with MEASUREWARE, please fax me for the
status of those changes (and identify the system, HP, AIX
or SUN, that you need supported, as each is different!).
Thanks to Thierry Van Moer, Procter & Gamble, BELGIUM.
Change 13.298 Format MGTANDS now decodes device type =38 (38:2GB) disk
FORMATS device, and variables LDEV and CTRL are now input as
VMACTAND $CHAR2. with a $OCTAL6. format, so device and control
Jan 4, 1996 unit are printed as TANDEM sysprogs expect.
This was my first use of the $OCTAL format, and Steve
Smith discovered what happens when I underspecified
the output width. Forgetting that a two-byte field
requires six print positions for its value in octal, I
initially assigned $OCTAL4 to a two-byte character
variable, but when a two-byte field containing '0056'o
(octal), or '002E'x (hex) was input, the value 0000
was printed, because SAS truncates character variables
on the right. Steve changed $CHAR2 to PIB2 and
$OCTAL4 to OCTAL4, and the correct value 0056 was
printed, because SAS truncates numeric variables on
the left! Of course, specifying the correct width of
$OCTAL6 or OCTAL6 prints 000056 and eliminates the
exposure to truncation differences!
Thanks to Steve Smith, BGS Systems, USA.
Change 13.297 Spelling corrections in labels, consistent comments after
EXVMxxx output statements, and removal of duplicate names in KEEP
VMACIDMS lists were made in members VMACAXC, VMACDB2, VMACDCOL,
Jan 2, 1996 VMAC28, VMACAIM7, EXDB2PAT, EXTY72GO, VMACTPM, JCLUXRE6.
VMACIDMS now includes IMACZDAT (needed only if TYPEIDMS
was executed standalone).
EXVMxxx members now have their "_LVMxxxx" macro names
instead of hard-coded dataset names for VM Accounting.
All of these changes were precipitated by Freddie's
excellent "MXG SOURCE CODE ANALYZER" program.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.296 Variable TRANTYPE in dataset CICSTRAN with CICS/ESA 4.1
FORMATS was changed by IBM. Previously IBM used the fourth byte
VMAC110 of a four-byte field; now they use the first two bytes of
Dec 29, 1995 a four-byte field, so the length of TRANTYPE is increased
to two bytes, the INPUT for 4.1 records was reordered and
the MG110TT format was changed to decode both the old
one-byte value and the new one-and-two-byte values!
Thanks to ????, Banco Santander, SPAIN.
Change 13.295 Support for DFSMS/MVS 1.3 DCOLLECT records COMPATIBLY
EXDCODAI added a number of new variables to these datasets:
EXDCODCN DCOLDSET,DCOLCLUS,DCOLMIGS,DCOLBKUP,DCOLDC,DCOLSC,DCOLBC
IMACDCOL DCOLSC,DCOLVL,DCOLAG,DCOLDR,DCOLLB
VMACDCOL and two new datasets are now created:
Dec 29, 1995 DCOLCN - Cache Names (Cache Set name and 8-SES Caches)
DCOLAI - Accounting Information (audit of definitions
of data class, management class, storage class
and storage group - who/when updated, which
dsname/member)
In addition, enhancements to the existing DCOLLECT code
for the construct datasets were made. Variables with hex
flag values are now INPUT as $CHAR instead of $EBCDIC and
are formatted HEX or $HEX, new MGDCOxx formats now decode
variables, especially in DCOLMC and DCOLSG datasets, and
new multi-valued flag variables were created and decoded.
Thanks to Mike Moos, British Rail, ENGLAND, for construct changes.
Change 13.294 Variable DEVICE in TYPE64 was truncated to two bytes, if
VMAC64 TYPE64 member was executed by itself. The statement
TRNDCICS DEVICE=' '; must be changed to DEVICE=' '; to get
Dec 28, 1995 all seven positions of DEVICE type name.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.293 Change 13.268 (adding USER to the SUMBY list for building
ASUMCICS PDB.CICS from CICSTRAN) was not applied to ASUMCICS nor
TRNDCICS to TRNDCICS, but now both members have been changed.
Dec 18, 1995
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 13.292 IBM creates invalid CICS Statistics records with CICS 3.3
VMAC110 that cause UNEXPECTED STATISTICS RECORDS with STILEN=0,
Dec 18, 1995 which caused MXG to fill the //WORK file. While IBM is
trying to find their error, MXG has added logic to detect
the STILEN=0 condition and prevent the error.
To circumvent the error, in member VMAC110, find the
INPUT statement that inputs STILEN, STID, and STIVERS,
and after the @; that ends that INPUT statement, insert
IF STILEN=0 THEN DELETE;
which will cause MXG to stop processing that 110 record.
Thanks to David Callahan, Caterpiller Inc, USA.
Change 13.291 CICS/ESA 4.1 only, MXG 13.07-MXG 13.08 only. The CICSTRAN
VMAC110 variables ENDTIME, ELAPSTM and IRESPTM are wrong. Change
Dec 18, 1995 13.247 (GMT support) was incorrectly typed in VMAC110.
The two lines reading: ENDTIME =ENDTIME =MCTMNTAD;
must both be changed to: ENDTIME =ENDTIME +MCTMNTAD;
(Since ASUMCICS and TRNDCICS use STRTTIME rather than
ENDTIME to classify a transaction, the ENDTIME error is
noticed only if you look at a specific transaction, but
because IRESPTM is used for the response time buckets,
those data for your CICS/ESA 4.1 systems is wrong.)
ENDTIME is also wrong in dataset CICSEXCE.
Thanks to Neil Ervin, Huntington Service Company, USA.
==========MXG 13.08 dated Dec 15, 1995, thru Change 13.290============
Change 13.290 Cleanup of dead members and dead references; Freddie has
IMACNPM built a SAS program that reads my SAS programs to find
TYPEZRB members-not-referenced, comments-misspelled, etc. This
Dec 12, 1995 sweep removed references to VMAC43PC,VMAC47PC,VMAC48PC,
and VMAC49PC in member VMACTEST (a private test program),
and deleted members IMACNPM and VMACZRB0 (both archaic
and no longer needed nor referenced)
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.289 Support for MVS Solutions's Thruput Manager SMF record
EXTYTPMF creates two data sets from the single SMF record:
EXTYTPMV TYPETPMF - Thruput Manager Job Analysis
IMACTPM TYPETPMV - Thruput Manager Variable Fields
TYPETPM
VMACTPM
Dec 12, 1995
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 13.288 Support for Landmark's TMON for UNIX creates 34 datasets:
EXTUXBLO
EXTUXCLI MXG Data INFILE Landmark
EXTUXCON Set Name name Table name status
EXTUXCUR
EXTUXDIS TUXBLOCK TUXBLO blockdevice TESTED
EXTUXDSK TUXCLIEN TUXCLI clientdetail TESTED
EXTUXFIB TUXCONEC TUXCON connections See Note 1, below
EXTUXFIH TUXCURDI TUXCUR currentdir TESTED
EXTUXFRE TUXDISK TUXDIS disk TESTED
EXTUXINF TUXDSKPR TUXDSK diskprocess TESTED
EXTUXINT TUXFILEB TUXFIB filebalance TESTED
EXTUXLIM TUXFILEH TUXFIH filehistory TESTED
EXTUXMEM TUXFREE TUXFRE freespace TESTED
EXTUXNFS TUXINFO TUXINF info TESTED
EXTUXNFR TUXINTER TUXINT interface TESTED
EXTUXOPN TUXLIMIT TUXLIM limits TESTED
EXTUXPRD TUXMEMRY TUXMEM memorymgmt TESTED
EXTUXPRC TUXNFSCL TUXNFS nfsclient See Note 2, below
EXTUXPRO TUXNFSRV TUXNFR nfsservice TESTED
EXTUXPRF TUXOPENF TUXOPN openfiles TESTED
EXTUXPRS TUXPRODI TUXPRD processdisk TESTED
EXTUXPGM TUXPROC TUXPRC process TESTED
EXTUXPCL TUXPROCO TUXPRO processor TESTED
EXTUXQUO TUXPROFI TUXPRF processfiles TESTED
EXTUXRSP TUXPRODS TUXPRS processdisposition TESTED
EXTUXSRV TUXPROG TUXPGM program TESTED
EXTUXSOC TUXPROTO TUXPCL protocol TESTED
EXTUXSTO TUXQUOTA TUXQUO quotas no test data yet
EXTUXSYS TUXRESP TUXRSP response TESTED
EXTUXTAB TUXSOCK TUXSRV server See Note 2, below
EXTUXTRM TUXSTOR TUXSOC sockets TESTED
EXTUXUSR TUXSYSTM TUXSTO storage TESTED
EXTUXUSI TUXTABLE TUXSYS system TESTED
EXTUXWAI TUXTERM TUXTAB tables TESTED
IMACTUX TUXUSER TUXTRM terminal TESTED
TYPETUX TUXUSER TUXUSR user TESTED
VMACTUX TUXUSERI TUXUSI userio See Note 2, below
Dec 12, 1995 TUXWAITS TUXWAI waits TESTED
The Landmark EXPORT command that is used to create the
data files that are read by MXG has these known errors
December. Landmark expects to have a revised EXPORT
command module by January to correct these errors:
1) The connections table, MXG data set TUXCONEC, has some
data records with fields missing, causing an INPUT
STATEMENT EXCEEDED RECORD LENGTH error with that file.
2) The TUXNFSCL (nfsclient) TUXSOCK (server) and TUXUSERI
(userio) tables have numbers instead of names for some
fields in the header, so those data sets are not yet
completely valid until Landmark corrects their data.
Member JCLTUX gives an example of the JCL required that
will read all 34 files created by TMON for UNIX's export
command.
Change 13.287 Support for the VM/ESA SQL/DS Remote User Record in the
EXVMSQLR VM Account file. The new record INCOMPATIBLY alters the
TYPEVM VMSQLUSR record (SQLCPUTM in hundreds of hours), because
Dec 12, 1995 it the MXG logic unknowingly output the new record there!
This change recognizes the new record and outputs it into
new dataset VMSQLRMT instead.
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.286 MXG 13.06-13.07. ERROR: THE KEYWORD PARAMETER ALOC3590
ANALTAPE WAS NOT DEFINED. Two line reading ALOC3490=TAPE3490;,
Dec 12, 1995 must have the comma at the end of the line removed, and
twos line reading ALOC3490='3490 ALLOCATIONS WAITING';,
must have both the semi-colon and the comma at the end
of the line removed. Four lines needed correction.
Thanks to Jon Caldwell, U.S. Department of Veterans Affairs, USA.
Thanks to Mike Hampton, First Nationwide Bank, USA.
Change 13.285 Cosmetic documentation change. References to ANALDB2 were
ADOCDB2 changed to DIFFDB2, the "four datasets" note was changed
DIFFDB2 to "three datasets", and change 12.033 is referenced
Dec 12, 1995 instead of change 12.034.
Thanks to Nico Lenaerts, SAS BELGIUM, BELGIUM.
Change 13.284 REXX program to convert GTF trace records from DB2 into a
REXXDB2 legitimate (un-segmented) records had typographic errors.
Dec 12, 1995 -All C2K should have been C2X instead.
-The NE should have been <> instead.
-The statement I=REC must be changed to F=REC.
-The concatenation symbol '6A'x needs to be '4F'x for MVS.
That character is mis-translated between EBCDIC/ASCII by
many upload/download packages, so the actual change was
to replace F=F||G with F=(F)(G)so that the
REXX program is impervious to upload/download.
Thanks to Eric Thornton, D&B, USA.
Thanks to Chuck Hopf, MBNA, USA.
======= Attended CMG 95 Conference in Nashville, Tennessee ============
Change 13.283 Support for TANDEM D20, D30, and D40 releases is added
VMACTAND compatibly. However, I found I cannot trust the TANDEM
Dec 2, 1995 MEASURE documentation; its DLLs show changes where there
Dec 12, 1995 were none! (Fortunately, CMG came to the rescue as there
Jan 3, 1996 I met a TANDEM employee who put me in touch with the real
programmer who wrote the code!). Two variables were added
compatibly by D30 (BEGTRANS,ABRTRANS) by using reserved
space in the PROCESS record. Several measurement fields
(lock-pages-qtime/count and UCL-lock-qtime/count in the
PROCESS record, and the four pairs of START/END variables
for UDS-LOCK, SDS-LOCK,UCL- LOCK, and SCL-LOCK in the
DISC record) were made reserved fields in D40 (because
they were too expensive to capture!). The DDL for D40 are
wrong, as they show BEGTRANS/ABRTRANS in the wrong place,
and the now-reserved fields were deleted from the DDL,
but they were not deleted from the physical record.
Thanks to Joe Fleischmann, US Bancorp, USA.
Thanks to Todd Tomita, US Bancorp, USA.
Thanks to Steve Smith, BGS Systems, USA.
Change 13.282 MAINTLEV 7 of the MXG Tape Mount and Allocation Monitor
ASMTAPES corrects the JSCB access problem, the CA-11 restart case,
Nov 30, 1995 and supresses the SRB dump messages (unless we ask you to
enable DEBUGGING!). This iteration has been running in
two sites for several weeks with no failure. The previous
monitor code was copied into ZSMTAPES for backup.
Change 13.281 This replacement for member CICINTRV is temporarily put
CICINTRZ in this member for extensive testing, but it will become
Nov 30, 1995 CICINTRV in the near future. The present CICINTRV logic
is incorrect, and this new logic correctly creates the
CICS interval datasets from the statistics datasets.
This version first summarizes the individual datasets at
the lowest level, and performs deaccumulation with DIF()
function for the REQ and USS records so that all four
types of CICS stat records are correctly summarized into
the CICINTRV dataset. Note that this can be resource
intensive if you have lots of CICS activity, but you can
construct the CICS activity from these statistics records
even if you have turned off CICSTRAN creation!
Revised Jun 13, 1996: Resources are not a problem; see
resource measurements in text of Change 14.132, which
implemented these enhancements starting with MXG 14.04.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.280 Correction. If no summary dataset was created, but
ANALCNCR summary reports were requested, the summary reports were
Nov 30, 1995 not produced.
Change 13.279 New parameters SMFBEGIN and SMFEND were added to allow
READDB2 selection while the raw SMF records are read. These new
Nov 30, 1995 parameters are now used by ANALDB2R (Change 13.278).
Change 13.278 Several enhancements to DB2 reporting.
ANALDB2R -Reports can now be produced from MNTHxxxx datasets, if
Nov 30, 1995 you have used the MNTHxxxx members to trend monthly.
-When reading SMF, the BEGTIME and ENDTIME values are now
passed to READDB2 (as SMFBEGIN/SMFEND) so that selection
applies to the raw data as it is read, which will reduce
DASD space and run time, especially with big traces.
Change 13.277 This utility (used only in JCLTEST6, to select ten SMF
VMXGGETM records of each type) has new INCODE= operand added to
Nov 30, 1995 enhance selection criteria, for those of you who have
found this utility useful! You could now code
INCODE=IF (ID=30 AND 4 LE SUBTYPE LE 5) OR ID=72; ,
to select only those records and subtypes.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.276 The revised VMXGSUM logic has been moved from XMXGSUM to
VMXGSUM VMXGSUM, and member XMXGSUM has been deleted. (Just in
XMXGSUM case, the old VMXGSUM was copied into ZMXGSUM for backup,
ZMXGSUM but that member too will go away in time). The new logic
Nov 30, 1995 in VMXGSUM will significantly reduce the DASD space, CPU
time and run time, as it keeps only the variables that
are actually needed by the summarization, and (unlike the
old VMXGSUM), it does not create dummy variables in
the output dataset. It also supports variable lists with
hyphenated syntax. Many sites with large data volumes
have been using the XMXGSUM logic, so I believe it is now
safe to make the MXG default to be the new logic.
Change 13.275 New parameters INTERVAL and MYTIME are defined for report
ANALRMFR summarization, but they are only implemented in MXGCHAN
Nov 30, 1995 report at this time.
Change 13.274 CICS shutdown reports CICCONSR or CICCONMR can cause many
ANALCISH blank pages with only the heading and no content; several
Nov 30, 1995 line changes were required, too complicated to show here.
Also, END; statement was missing after IF INOBS EQ CXMC.
Thanks to Richard S. Ralston, Whirlpool. USA.
Change 13.273 Support for DB2 4.1 type 102 trace records has tested the
VMAC102 new IFCIDs 221, 222, and 231 for parallel group tracing,
Nov 30, 1995 and adds new fields in existing trace datasets for IFCIDs
8, 10, 20, 21, 22, and 28. There are still other fields
added to other IFCIDs by 4.1 that are not yet decoded by
MXG due to absence of test data records; those will be
added when user demand and test data arrive together.
Thanks to Ted Blank, IBM, USA.
Change 13.272 Corrections to several variables in HP PCS records:
VMACHPAI -VMACHPUX, comment now has HPUX as correct INFILE name.
VMACHPSU -VMACHPUX, PIN variable removed from LENGTH statement so
VMACHPUX that it will be numeric rather than character (as it was
Nov 29, 1995 in HPAI and HPSU members, like all other PINs).
-INTEREST now input as INTEREST $CHAR12. (instead of with
no INFORMAT) as the file may contain leading blanks.
First test for INTEREST that sets IMPWTHI was deleted.
Last four tests for INTEREST must test for lower case
letters c,d,m,i rather than upper case values.
Thanks to Thierry Van Moer, Procter & Gamble Europe, Belgium.
Change 13.271 Variables SYSNAME and SYSPLEX were not kept in BUILDPDB
IMACPDB datasets PDB.JOBS, PDB.STEPS, and PDB.PRINT, but they are
Nov 29, 1995 now added to _PDB30_1, _PDB30_4, and _PDB30_5 macros in
member IMACPDB so they will be kept in the PDB datasets.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
Change 13.270 IBM writes truncated EREP records, but MXG did not catch
VMACEREP the truncation, causing INPUT STATEMENT EXCEEDED RECORD
Nov 29, 1995 for a hardware detected VLF software record. Protection
was added for dataset EREPSDW. Additionally, the ERRORID
field at the end of the SDW record was not input from the
correct location, and variable CLASRC is now kept in the
EREPSDW, EREPEOD, EREPMDR, and EREPOBL datasets.
Thanks to Solomon Baker, The Prudential Service Company, USA.
Change 13.269 Variables QBSTHPL and QBSTVPL were removed from DIF()'ing
DIFFDB2 because they are not accumulated values, but rather are
Nov 28, 1995 the number of hiperspace and virtual pool buffers.
Thanks to Alan Fendler, Pershing Info Management Services, USA.
Change 13.268 Variable USER was added to the default summarization of
ASUMCICS CICSTRAN dataset into PDB.CICS, because OPERATOR is now
Nov 28, 1995 usually blank, while USER contains the wanted user-id.
Dec 18, 1995 The summarization default is now by
APPLID OPERATOR USER TERMINAL TRANSACT (for each hour).
Thanks to Clark Jennings, Reynolds Metal, USA.
Change 13.267 Another IDMS 12.01 error, INVALID DATA FOR PMHSDATE for
VMACIDMS the PMHRTYPE=6 (Journal Wait) subtype. The statement
Nov 20, 1995 SKIP=SKIP-108; that is two lines prior to the statement
%%INCLUDE SOURCLIB(EXIDMJRL); should been
SKIP=SKIP-104;. (My test data stream did not have any
journal wait data, but this was an MXG coding error.)
Thanks to Dan Gilbert, Bergen Brunswig Corporation, USA.
Change 13.266 Variable STARTIME was missing TSOMCMND if the TSO/MON
VMACTSOM SMF record was written in segments (because there were
Nov 20, 1995 more logged on users that would fit in one SMF record).
STARTIME was added by Change 13.089 for consistency, but
the pre-existing, same value variable STRTTIME was never
wrong! Immediately following STRTTIME=TSOMSTAR; insert
STARTIME=STRTTIME;
Thanks to Neil Ervin, Huntington Services Co, USA.
Change 13.265 Support for IMS 5.1 records (INCOMPATIBLE) was reported
ASMIMSLG with these changes.
VMACIMS -ASMIMSLG - Replace these three non-contiguous lines
Nov 17, 1995 TM MSGCFLG1,MSGC1RAC TM MSGCFLG1,MSG3RACF
---17 lines ----
USING MSGRACF,R4 USING MSGSEC,R4
--- 8 lines ----
MVC ORGENT(8),MSGRACGP MVC ORGENT(8),MSGSAFNM
(with this change to ASMIMSLG, it can ONLY process 5.1
records, so you will need to maintain two separate load
libraries and separate job streams).
VMACIMS
18 new 4-byte fields were inserted in the 07 log record
between MSGGCMD and PDATE.
This is a documentation only change at this time, as I am
still awaiting data and documentation so that I can
validate this report and then change the MXG coding.
Now, see Change 14.030.
Thanks to Mr. Hellmann, Sudwestdeutsch Landesbank, GERMANY.
Change 13.264 TANDEM disk type format MGTANDS values are decimal, not
VMACTAND hex, so the "X"'s were removed, and the 35:3GB value has
Nov 16, 1995 replaced the 35:MGB spelling.
Thanks to Steve Smith, BGS Systems, USA.
Change 13.263 IBM lied, and JESNR may show only four digits in TYPE26J2
VMAC26J2 dataset (and if BUILDPDB finds only a purge record for a
Nov 13, 1995 job, its PDB.JOBS observation will have JESNR=1179 where
Feb 26, 1996 it should be JESNR=11179. IBM documentation of SMF26JNM
(the old, 4-position EBCDIC JESNR) says it will be zero
if the job number is 10,000 or greater, causing MXG to
get JESNR from SMF26JID, and this was true until now, but
it appears MVS/ESA 5.2 with JES x.y are now putting the
truncated JESNR back into SMF26JNM! While I chase after
the IBM INCOMPATIBLE change to type 26 record, I can fix
the MXG logic to work no matter what IBM does. Change:
ELSE DO;
IF JESNR GT 0 THEN
INPUT @57+OFFSMF TYPETASK $EBCDIC3.
+5
@;
ELSE
INPUT @57+OFFSMF TYPETASK $EBCDIC3.
@60+OFFSMF JESNR &NUM.5.
to read:
ELSE DO;
INPUT @57+OFFSMF TYPETASK $EBCDIC3.
@60+OFFSMF JESNR &NUM.5.
Feb 26, 1996 update: IBM APAR OW18822 acknowledges the
error and should correct the non-zero value back to zero,
but the MXG correction in MXG 13.13 fixes it anyhow!
Thanks to Tim Terbieten, Newell Company, USA.
Change 13.262 Variable DEVPLX, the device address of the duplex volume,
VMACACHE is an offset from the first device instead of the real
Nov 8, 1995 device number; now, DEVPLX will contain the true device
Dec 2, 1995 number by inserting these lines:
IF NDVCNT=1 THEN BASDEVN=DEVN;
IF DEVS1='....1...'B THEN DEVPLX=BASDEVN+MOD(DEVS2,64);
before the %%INCLUDE SOURCLIB(EXCAC90); statement.
I note that the Cache record does not contain a segment
for the duplex device; DEVPLX=05x, BASDEVN=2C0x, so the
duplex device address is now DEVPLX=2C5x, but there will
be no observation in CACHE90 with DEVN=2C5x.
The above correction worked until MVS/ESA 5.2, which has
caused an unexpected (at least by the CRR-folks) change
in the CRR record. The BASE device number used to be the
first device segment returned by the 3990 controller, and
that address is copied into the statistics segment. But
in 5.2, the order in which devices are varied online at
IPL is different, and the 3990 returns devices in order
they came online, so the base device is no longer going
to be in the first segment. IBM CRR Level II has this;
when they decide what they are going to do, so will I!
Thanks to Kurt Koch, West Publishing Corporation, USA.
Change 13.261 SAP Journal segments in type 110 records caused error
VMAC110 INPUT STATEMENT EXCEEDED, or INVALID DATA FOR HH, or did
Nov 8, 1995 not read in all segments in the SMF record, because MXG
Jan 13, 1996 did not anticipate that SAP would create journal segments
with only a header,
(found for the YISA APPC host-to-host connection
application, with JCSPTRAN='YISA', JCRLL=30, so there
is no data - these segments may be output into a new
dataset if there is usefulness, and this fix still
leaves them available in the EXCICJRN exit),
or with JCRUTRID not containing 'SA',
(found for a most strange segment between other 'SA's,
containing a Global Performance Interval segment with
MCTSSDID=2 which belongs in a subtype =1 record and
is normally output into CICSYSTM from that subtype!;
UPDATED Jan 13. SAP Technical Support has not responded,
but the second problem is circumvented in Change 13.323.
Header only segments are skipped over with these changes:
-Delete the line ... INPUT +6 SAPTEST $EBCDIC2 @LOC @;
-Change IF SUBTYPE=0 OR SAPTEST='SA' THEN DO UNTIL ...
to IF SUBTYPE=0 THEN DO UNTIL ...
-Change IF JCRUTRID='SA' THEN DO;
to IF JCRUTRID='SA' AND JCRLL GE 250 THEN DO;
Unrelated to the above errors, variable APPLID was added
to the KEEP= list for the CICSSAP dataset so CICSSAP can
be analyzed for each CICS region.
Thanks to Jens Schlatter, EDP Consulting Schlatter, GERMANY.
Thanks to Norbert Korsche, OMV, AUSTRIA.
Thanks to Paolo Carloni, Agip petroli SPA, ITALY.
Thanks to ????, Deutsche Post AG, GERMANY.
Change 13.260 RMDS 1.4 records may cause INVALID ARGUMENT TO MDY AT ...
VMACRMDS because only some MDY() functions were protected for the
Nov 8, 1995 'strange' values MO=99 and DD=99.
Feb 26, 1996 -Now, all uses of MDY() are protected with logic of the
form:
IF YY GT 0 AND (YY NE 99 AND MO NE 99 AND DD NE 99)
THEN xxxxDATE=MDY(MO,DD,YY);
-In addition, INVALID DATA FOR MM can occur, because only
some INPUTs of HH MM and SS were protected with the ??
modifier. Now, all fields input with &NUM are preceded
by the double-question-mark modifier.
-Finally, all HMS() functions are now protected with
IF 0 LE HH LE 24 and 0 LE MM LE 60 and 0 LE SS LE 60
logic to prevent invalid arguments to HMS() function.
-The error does not occur with current RMDS 2.1 or later.
Note added Feb 26, 1996: The support for RMDS 1.3/1.4
also deleted the two tests:
IF RMDSACT='D' and RMDSORG NE 'A' THEN RMDSACT='T';
IF RMDSACT='U' AND RMDSORG EQ 'V' THEN RMDSACT='S';
because the activity codes of 'T' and 'S' do not exist
in RMDS version 2.1.
Thanks to Ambat Ravi Nair, Trident Infotech Pte Ltd, SINGAPORE.
Change 13.259 MXG 13.06-13.07 only. ABARS enhancement validation:
EXHSMWWV -UNEXPECTED IDHMSMDS RECORD FOUND because the line now
IMACHSM reading ELSE IF DSRVSR='VRS' THEN ... should have been
VMACHSM ELSE IF DSRVSR='VSR' THEN ....
Nov 8, 1995 -INPUT STATEMENT EXCEEDED RECORD LENGTH on ABARS subtype
Nov 15, 1995 because the four fields WFSRML0U,WFSRML1U,WFSRML2U, and
WFSRTOTU at the end of both ABARS segments are now INPUT
as $EBCDIC1. instead of &PIB.4. MXG now decodes the unit
of space value (blank, K, M, etc.) and converts the space
used during ABACKUP variables WFSRML0S,L1S,L2S,TOTS into
bytes, and are formatted with MGBYTES to print pretty.
-Variable WFSRABCC is now input as $EBCDIC4. vice &PIB.4.
-IBM clarified several issues. Space units of K,M,G,T are
1024 (as expected, but since IBM used 1000 for hardware
"K", and since the ABARs documentation did not say, we
had to ask!). Also, ABACKUP VERIFY does cut a shorter
record that does not contain the space information fields
while ARECOVER creates a longer record, but zeroes out
the space information fields.
-New HSM dataset HSMWWVOL is created, but with zero obs
until you remove the comment block in member EXHSMWWV.
(This dataset will contain one obs for each volser that
was used by ABARS for backup, and I perceive little need
for that information; the useful ABARS information is in
the HSMWWFSR dataset, one obs per ABARS event.)
Thanks to Michael E. Friske, Fidelity Savings, USA.
Change 13.258 Very obscure, and only for the early users of XMXGSUM.
XMXGSUM Change the second occurrence of NUMPOS= from &HYPHEN1 to
Nov 6, 1995 &HYPHEN2. Would have caused an OUT OF MEMORY error.
Change 13.257 Variable AVGQUETM should not have been in the keep list
VMAC7072 for dataset TYPE72GO, as that field is from the subtype 2
Nov 6, 1995 (RMF Monitor III) record, and is output only in TYPE72MN.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 13.256 Variable QBGAGN should be kept only in DB2ACCTG, and not
VMACDB2 in DB2ACCT, and it should not have been summed during the
Nov 6, 1995 creation of DB2ACCTG. It is the pool ID, not a counter!
Thanks to Chuck Hopf, MBNA, USA.
Change 13.255 Tandem variables CnMISSES was repeated in INPUT; the two
FORMATS instances are now named CnRMISS and CnWMISS for Read or
VMACTAND Write misses. C1BLKS is no longer divided by DURATM, as
Nov 6, 1995 it is blocks allocated, not blocks moved in interval.
Format MGTANDS was updated with device 1Fx and will now
print un-coded values in hex rather than decimal.
Thanks to Steve Smith, BGS Systems, USA.
Change 13.254 Support for TOPSECRET Release 4.4 and 5.0, INCOMPATIBLE,
VMAC80 CAUSES INPUT STATEMENT EXCEEDED RECORD error, because the
VMAC80A new release sets a value of 44X or 50X for RACFVRSN, but
Oct 31, 1995 MXG does not know in advance what value TOPSECRET will
use! Add OR RACFVRSN=44X OR RACFVRSN=50X to the test
for TOPSECRET in both members. (44X exists in 4.4 data;
5.0 is not out yet, so I am gambling in advance that they
will use 50X for that version when it's released!).
Thanks to Mark Paulson, Maurices Incorporated, USA.
Thanks to Sarah Gartner, Hudson's Bay Company, CANADA.
==========MXG Version 13.07, dated Oct 30, 1995, thru 13.253==========
Change 13.253 SAP 5.0.E creates invalid journal segments, which caused
VMAC110 INVALID DATA FOR HH and a hex dump of the record, but MXG
Oct 27, 1995 successfully skipped over the invalid segments and output
the valid ones. SAP had no one in tech support on Friday
to discuss their error before MXG 13.07 was built, but I
will pursue this with them later and update this note.
To eliminate the hex dump and message, insert ?? after
HH and MM following the INPUT of JCSPTASK.
Update: See Change 13.323.
Thanks to Paolo Carloni, Agip petroli SPA, ITALY.
Change 13.252 $AVERS SMF record variables SAVPAGES,SAVBLKS,SAVTBLKS are
VMACSAVR now created; these fields existed at the end of the SMF
Oct 27, 1995 record, but were not populated until this user went to
use them! The vendor, Software Engineering of America,
will fix the error in SAVRS V4.0A.33, and interim fix
number S40AF166 (a ZAP) is available from them now that
will populate these fields.
Thanks to Bill Hamilton, Scottish Widows, SCOTLAND.
Change 13.251 Support for STK's SILO SMF HSC View Subtype 8 record now
EXSTCHSV creates dataset STCHSV for every successful VIEW command
IMACSTC initiated by HSC.
VMACSTC
Oct 26, 1995
Thanks to Cheryl Howard, Wachovia Corporation, USA.
Thanks to Rodney L. Reisch, Wachovia Corporation, USA.
Change 13.250 DURATM was added to TSO/MON datasets by Change 13.089,
VMACTSOM but it was often missing! After the second statement
Oct 26, 1995 INTRVTM=TSOMDUR; insert DURATM=INTRVTM;
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 13.249 Support for MODEL204 Release 3.0 INCOMPATIBLY added five
IMACM204 fields to the SINCE record. Since there is no release
VMACM204 number in their record, you MUST update member IMACM204
Oct 25, 1995 in your USERID.SOURCLIB to use this new IMACM204, as it
now also defines macro _M204VER which tells MXG to read
Release 2 or Release 3 records (default is for Rel 3).
Thanks to Mark Wessel, Population Census & Surveys Office, ENGLAND.
Change 13.248 Summarization of IDMSTAS dataset from IDMS Perfmon into
ASUMIDMS PDB.ASUMIDS is provided by this user contribution, which
Oct 25, 1995 mimic's ASUMCICS algorithms to create response time and
resources by CV_NUM DC_USER DC_LTERM TASKCODE ADSODLGN.
Thanks to Richard S. Ralston, Whirlpool, USA.
Change 13.247 CICS/ESA 4.1 or later now contains the GMT offset, so MXG
VMAC110 can finally convert the STRTTIME/ENDTIME in CICSTRAN to
Oct 25, 1995 your local time of day. The INPUT of MCTMNTAD is changed
from &PIB.4. to &IB.4., and this line inserted:
MCTMNTAD=1.0485582324*MCTMNTAD;
to convert from CICS timer units to seconds. Then, in
the CICS/ESA 4.1 section for CICSTRAN and CICSEXCE, the
logic IF MCTMNTAD GT . THEN DO;
STRTTIME=STRTTIME+MCTMNTAD;
ENDTIME =ENDTIME +MCTMNTAD; END;
was inserted to add the (negative in USA) GMT offset.
NOTE: IF YOU HAVE TAILORED member EXCICTRN to convert the
CICSTRAN timestamps (as was described in Newsletter 27),
YOU MUST REMOVE OR REVISE YOUR conversion logic so that
it only converts non-4.1 records. For example, you could
use this logic for USA East Cost time zone in EXCICTRN:
IF MCTMNTAD=. THEN MCTMNTAD=.;
IF MCTMNTAD=. THEN DO;
STRTTIME=STRTTIME-HMS(5,0,0);
ENDTIME =ENDTIME -HMS(5,0,0);
END;
to force the 5-hour conversion for non-4.1 regions. The
first statement setting MCTMNTAD missing if it is missing
if the "compiler faker" statement which eliminates the
"uninitialized variable" message, so you could install
this logic in EXCICTRN even before you install MXG 13.07!
Variable MCTMNTAD was added to CICSTRAN by this change.
Thanks to Glenn Yee, Health & Welfare State of California, USA.
Change 13.246 Variable SETUP was added to _PDB26J2 macro so that that
IMACPDB variable will be kept in the PDB.JOBS dataset. It turns
Oct 25, 1995 out that the existence of a /*SETUP card causes JES2 to
put the job in logical hold until the operator releases
the job, but TYPRUN=HOLD is not set for these jobs. Now,
for observations with SETUP='Y' in PDB.JOBS, you can
identify these jobs that are delayed due to /*SETUP card.
Thanks to Andy Vick, Allied Dunbar Assurance, ENGLAND.
Change 13.245 In revision 4 of the type 6 SMF record, IBM truncated two
VMAC6 bytes of SMF6TU field, but in revision 5 data, the value
Oct 25, 1995 in SMF6TUL matches the length of SMF6TU, so the line that
was added by Change 13.162 is now changed to read:
IF REVISION EQ 04X THEN SMF6TUL=SMF6TUL-2;
I have not found IBM documentation of their change yet!
Thanks to Michael Moyer, Wyeth-Ayerst Labs, USA.
Change 13.244 Support for DB2 4.1.0 (COMPATIBLE) adds new fields to the
ANALDB2P statistics and accounting records, new subtypes and new
EXDB2ACG segments create three new datasets:
EXDB2PAT
EXDB2PST DB2ACCTG - Accounting - Group Buffer Pool usage
VMACDB2 DB2GBPAT - Global Buffer Pool Attributes
VMACDB2H DB2GBPST - Global Buffer Pool Interval Statistics
Oct 22, 1995
The major change is the support for DB2 Parallelism, with
multiple observations now created in DB2ACCT whenever
DB2 event (like a QUERY) is actually parallelized. The
degree of parallelism for a CPU bound task is constrained
by the number of CPU engines, while it is the structure
of your DB2 data (number of partitions, etc.) which
limits the degree of parallelism for an I/O bound task.
New member ASUMDB2P can be used to summarize these child
and parent pairs (and the sequential, or non-parallelized
DB2 events) so that there is only one observation for
each event, with variables PAIRNR (a created sequence
number token that was used to create ASUMDB2P from
DB2PARTY), NRCHILD (number of children records for this
event), and TOTELAPS (sum of elapsed time of all records
for this event, because ELAPSTM is the true elapsed wall
time of the parallel execution). Beware, sorting DB2ACCT
is required to create both the DB2PARTY detail dataset
and the output ASUMDB2P dataset, and DB2ACCT can be big!
The parent record has a non-zero QXMAXDEG, the maximum
number of parallel tasks, but there can be many more than
QXMAXDEG children records written, because tasks can be
parallelized in groups of different degrees. MXG creates
formatted variable DB2TSKTY to describe each observation
in DB2ACCT:
DB2TSKTY Description
C Child
P Parent
S Sequential (i.e., non-parallelized)
Complex queries in test data shows an event of three
groups, with 9, 10, and 8 children respectively, so 28
observations in DB2ACCT were created for that
parallelized query event. Almost all of the resources
(CPU, I/O) are recorded in the child record, but the
parent record contains important counts as well.
Extensive testing of DB2ACCT data was done in creation of
member ANALDB2P for parallel analysis, but the test data
thus far has not used Global Buffer Pools, so those new
datasets have not been data-tested. I have only casually
validated the DB2STATS with 4.1 data for reasonableness,
and VMAC102 has not yet been enhanced (I still await 4.1
trace test data). This note will be revised as testing
proceeds.
Change 13.243 MXG did not output observations to HURN49 if HU49XSNO is
VMACHURN zero (user logs on to Huron server, but did not access
Oct 20, 1995 another database before logging out). After the END;
after the DO I=1 TO HU49XSNO; insert:
IF HU49XSNO=0 THEN DO; %%INCLUDE SOURCLIB(EXHRN49); END;
Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA.
Change 13.242 Correcting TYPE42DS STARTIME/ENDTIME from GMT to local in
VMAC42DS exit EXTY42DS using STARTIME=STARTIME-HMS(5,0,0) (to
EXTY42DS subtract 5 hours, for EST or CDT time zone) will not work
Oct 19, 1995 because the EXTY42DS member will be invoked once for each
dataset in a concatenation, causing STARTIME to be fine
in the 1st dataset, but then off by 5 hours in the 2nd,
off by 10 hours in the 3rd, etc. Instead, you must use
STARTIME=SMF42PTS-HMS(5,0,0); and
ENDTIME= SMF42PTE-HMS(5,0,0);
to force the correct GMT value. When you have installed
MXG 13.07 or later, you can revise your exit logic to use
IF S42JDGMO=. THEN DO;
STARTIME=SMF42PTS-HMS(5,0,0);
ENDTIME= SMF42PTE-HMS(5,0,0);
END:
because MXG 13.07 adds support for APAR OW16125 that adds
the actual GMT offset in S42JDGMO; with this revised code
your forcing code will only be executed prior to install
of that APAR. This is a documentation-only change; no
MXG code was actually changed.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.241 New BUILDPDB exit IMACSPCK allows you to override the MXG
IMACSPCK decision "TO SPIN OR NOT TO SPIN" for specific cases.
BUILDPDB For example, VM Print Jobs, run on MVS, will create only
BUILDPD3 a type 6 print record. If you have tailored IMACSPIN so
BUILD005 that SPINCNT is greater than zero (as recommended), those
Oct 19, 1995 VM jobs will spin for SPINCNT days before finally being
output into the PDB. If you know that all VM Print jobs
have job names starting with RSCS, you can use this new
IMACSPCK member, by coding therein:
IF JOB=:'RSCS' THEN OKFLAG=1;
which will sent all RSCS jobs directly to the PDB instead
of waiting around in the SPIN library for SPINCNT days!
The default exit contains only comments.
Thanks to Norbert Korsche, OMV, AUSTRIA.
Change 13.240 Dataset ASUMDB2B was not created in the weekly PDB from
WEEKBLD the daily PDB's, but now it is.
WEEKBLDT
Oct 17, 1995
Thanks to Merlin Beeching, Generale de Banque SA, BELGIUM.
Change 13.239 S370FRBn informat fails under ASCII SAS if the floating
SASAFIX1 point value is unnormalized. See MXG Technical Note in
Oct 15, 1995 Newsletter TWENTY-NINE for discussion. This member is an
Nov 8, 1995 interim fix for MXG users executing under ASCII platforms
and currently contains two SAS programs that will create
the UWIS370F.DLL file for OS/2 SAS 6.10 or 6.11.
-Nov 8. The OCT 15 fix returned a large negative value if
the field was all hex zero, but that is now corrected,
and SASAFIX1 now provides fixes for SAS for OS/2 for both
6.10 and 6.11 and for SAS for Windows for 6.10.
Thanks to Ian Gibson, Queensland Transport, AUSTRALIA.
Change 13.238 MXG 13.06 only. Variable DELTATM is always missing. The
DIFFHMF semicolon is missing from each of the 6 LABEL statements,
Oct 14, 1995 also causing UNINITIALIZED warning message.
Change 13.237 Variable ZDATE is now created in one place, IMACZDAT, so
IMACZDAT that you can easily force ZDATE to a specific date for a
DOC rerun of a build job. Previously, you had to change the
Oct 14, 1995 value of ZDATE in a separate place for each infile that
you had to rerun. All of the associated statements to
describe ZDATE (LENGTH, LABEL, FORMAT) were moved into
the IMACZDAT member, and each statement ZDATE=TODAY();
or IF ZDATE=. THEN DO; do group were replaced with the
%INCLUDE or %%INCLUDE syntax for member IMACZDAT. There
were 113 members changed in response to this suggestion,
which will surly make someone very happy some day!
Thanks to Bruce Hewson, Alcoa, AUSTRALIA.
Change 13.236 The execution delay percentage variables in TYPE72GO used
VMAC7072 the workload manager sample count (VALDSAMP=R723MTVN;) as
Oct 14, 1995 denominator, but that statement is now replaced with:
VALDSAMP=PCTUSCUS+PCTDLTOT+PCTDLUNK;
because the workload manager counts both address spaces
and dispatchable units in the numerator (eg., an ASID may
have an SRB executing and a TCB waiting). This discovery
by Don was non-trivial and has been IBM-confirmed!
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 13.235 Utility UDOCHECK (rarely needed, used to scan SAS source
UDOCHECK statements to locate DO ... END pairs when you have one
Oct 13, 1995 of those painful "MISSING END STATEMENT" syntax errors,
often caused in my experience because a comment swallowed
the END; statement) did not support DO WHILE / DO UNTILs.
Thanks to Wayne Bell, National General Insurance Company, USA.
Change 13.234 Variable NLDMSUBT should have been added to TYPE39_8 but
VMAC39 it wasn't until now.
Oct 13, 1995
Thanks to Wayne Bell, National General Insurance Company, USA.
Change 13.233 MXG 13.06. Support for Landmark for DB2 V 2 has now been
VMACTMDB tested with data which found undocumented alignment bytes
Oct 27, 1995 and changed header, causing STOPOVER. In addition, many
variables were not formatted that are now.
Thanks to Ken Updegraff, Hershey Chocolate, USA.
Change 13.232 The values of LPMINCnn, LPTARCnn, and LPMAXCnn variables
VMACAPAF are 10000 times too small. Change their informat from
Oct 17, 1995 &PIB.4.6 to &PIB.4.2 to correct. Additionally, variables
LPMINPnn, LPTARPnn, and LPMAXPnn are now created with the
Percentage allocation for each logical processor.
Thanks to John Suters, Telecom Australia, AUSTRALIA.
Change 13.231 The calculation of ARSPNET was sometimes incorrect. The
VMACNSPY statement IF NETRSPNO GE .5*TRANSNO AND TRANSNO GT 0
Oct 12, 1995 THEN ARSPNET=CRSPNET/TRANSNO;
should be ... THEN ARSPNET=CRSPNET/NETRSPNO;
Thanks to Alan Keebel, British Steel, ENGLAND.
Change 13.230 MXG 13.06 only. Change 13.181 caused INPUT STATEMENT
VMAC64 EXCEEDED RECORD error. The five lines at the end:
Oct 11, 1995 INPUT BEGCCHHX PIB4.
ENDCCHHX PIB4.
+18
@;
ALLOCCYL=ALOCCYL+ENDCCHHX-BEGCCHHX+65536;
must be replaced by this single corrected line:
ALLOCCYL=ALOCCYL+ENDCCHH-BEGCCHH+65536;
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.229 Change 12.195 was never made to WEEKBLDT, causing SORT
WEEKBLDT ORDER error. The correct _BYLIST for TAPEMNTS is:
Oct 11, 1995 MACRO _BYLIST SYSTEM SHIFT DEVICE TMNTTYPE TMNTTIME % .
Thanks to Neil Ervin, Huntington Services Company, USA.
Change 13.228 MVS/ESA V5 in Goal Mode only. Pre-Goal Mode, MXG only
EXTY72GO output TYPE72 when the PERFGRP had activity (to save DASD
FORMATS space, because IBM created segments for idle perfgroups),
VMAC7072 and so in Goal Mode, MXG only output TYPE72GO when the
Oct 10, 1995 SRVCLASS consumed resources (by testing, in EXTY72GO, for
non-zero CPUUNIT,SRBUNIT,IOUNIT,MSOUNIT or TRANS).
However, that test should only have been applied against
service classes for address spaces (as only ASIDs contain
resources). The result was that observations for trans
service classes that had no completions during the
interval were not output.
The test should have been qualified by R723TYPE, as it
describes which type of record we have. However, then I
discovered that R723TYPE was missing in some MVS/ESA 5.2
data, because the resource flag, R723CRCA, was not set,
and that had previously been a legitimate identifier that
an observation was an address space. As a result of this
discovery, I had to redefine the way R723TYPE is created:
IF RPRTCLAS EQ 'Y' THEN DO;
IF R723CRCA EQ 'Y' THEN R723TYPE='4';/*REPORT, ASID */
ELSE R723TYPE='5';/*REPORT, TRAN */
END;
ELSE IF R723CWMN GT 0 THEN R723TYPE='3';/*TRANSACTION*/
ELSE DO;
IF R723CRTX GT 0 THEN R723TYPE='1';/*ASID SC WITH RESP*/
ELSE R723TYPE='2';/*ASID SC NO RESP*/
END;
-Now, with the correct definition and setting R723TYPE
values, the logic in EXTY72GO could be changed so that
only observations that could contain resources are tested
to see if they should be output, using:
IF R723TYPE IN(1,2,4) THEN DO;
IF SUM(CPUUNITS,SRBUNITS,IOUNITS,MSOUNITS,TRAN)
GT 0 THEN OUTPUT _LTY72GO ;
END:
ELSE OUTPUT _LTY72GO;
With these changes, R723TYPE will be valid for all obs,
and only those resource-containing observations written
for Address Space Service Classes or Report Classes will
be output by the exit.
-Also discovered, the format names in member FORMATS for
$MGRMFTY and $MGRMFRT were reversed. $MGRMFTY describes
the type of record, while $MGRMFRT describes responses.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 13.227 The VAX Accounting Support was designed for execution on
VAXPDS ASCII platforms, which caused errors when executed under
Oct 10, 1995 MVS. The RECFM=N for ASCII must be RECFM=VB for MVS, so
I now have added a macro %%VMXGLRF in place of RECFM=N on
each INFILE statement, and defined VMXGLRF to set the
correct RECFM depending on where MXG is being executed.
Also, the broken vertical bar character ('6A'x onMVS)
used for concatenation was replaced with the exclamation
points ('5A'x on MVS), because the '6A'x character is not
correctly translated between ASCII and MVS systems.
Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM
Change 13.226 Support for APAR OW16125 which adds GMT offset to type 42
VMAC42 subtype 6 (TYPE42DS dataset) observations. If the APAR
Oct 10, 1995 has been installed, new variable S42JDGMO will be non
missing, and MXG will have converted STARTIME and ENDTIME
from GMT to local time of day. If S42JDGMO is still
missing, the APAR is not installed, and STARTIME/ENDTIME
will still be on the GMT clock.
==========MXG Version 13.06, dated Oct 10, 1995, thru 13.225==========
Change 13.225 Change 13.065 can cause variables INTBTIME,INTETIME to
VMAC30 be really far from the truth, because the line inserted:
Oct 9, 1995 by that change:
GMTOFF30=GMTOFF30+SMF30IST-INTBTIME; /*GET LEAP SEC*/
must be deleted. In attempting to correct IBM's error, I
made the problem worse, by adding that heuristic that
worked with my test data, but failed badly with different
data. Removal of this line may still cause the problems
that were discussed in 13.065, but it is the safest
approach for "normal" sites.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 13.224 Support for Landmark TMON for DB2 Version 2 INCOMPATIBLY
EXTMDxxx changed their records, so MACRO _TMDVER is now defined in
IMACTMDB member IMACTMDB to tell MXG to process version 2 records.
VMACTMDB (The default in IMACTMDB expects Version 1 data records,
Oct 8, 1995 so you MUST tailor IMACTMDB to process Version 2.
The previous support created only TMDBDA,TMDBDB,TMDBDE,
and TMDBDR datasets. For version 2, datasets TMDBDA2,
TMDBDB2, and TMDBDE2 will have observations while their
un-suffixed counterparts will only have observations with
version 2, and TMDBDR no longer exists with version 2.
These new version 2 data sets are now created and will
have observations if their subtypes are found:
TMDBDBA, TMDBDAB, TMDBDAF, TMDBDBB, TMDBDDF, TMDBDBK
TMDBDBR, TMDBDW , TMDBDC.
In addition, these new datasets are defined and will have
observations, but only the record header is decoded for
these subtypes at this time:
TMDBBB , TMDBBC , TMDBBD , TMDBBE , TMDBBF , TMDBBG
TMDBBH , TMDBBI , TMDBBJ , TMDBBK , TMDBBL , TMDBBM
TMDBBT , TMDBDD
This combined support for both versions has not been
tested with data records, but the original code and the
Version 2 code contributed by Peter were separately
tested before I restructured and merged the code into
the single VMACTMDB member, and no error have surfaced.
Thanks to Peter Proppe, Bremer Lagerhaus Gesellschaft(BLG), GERMANY.
Thanks to Ken Updegraff, Jr., Hershey Chocolate, USA.
Change 13.223 Support for IDMS 12.01 Maintenance Level 9506 and later.
VMACIDMS CA INCOMPATIBLY changed their PERFMON SMF record. MXG
Oct 8, 1995 should have detected their change and deleted the changed
Nov 14, 1995 record and print a NOTE on the log, but their change
exposed an MXG logic error in detecting IDMS changes, and
MXG ABENDed with INPUT STATEMENT EXCEEDED RECORD LENGTH.
(In my defense, even CA IDMS Tech Support did not know
THAT there was a change, nor WHAT fields were changed
until I read this text to them!) Originally I thought
the change was introduced in IDMS 12.01, but it is their
maintenance level 9506 that contains the new data fields.
-Delete the final IF SKIP GT 0 THEN INPUT +SKIP (the one
after the END; /* END SUBTYPE 18 */ statement). This
will eliminate the STOPOVER condition with 12.01 data,
However, datasets IDMSARA, IDMSBUF, IDMSDBK and IDMSJRL
will still be wrong because field lengths were changed.
-To process ONLY 12.01 data, you could make these changes:
After PMHRTYPE=1, change INPUTs of
ARANAME $EBCDIC16. to ARANAME $EBCDIC27.
ARAFILE $EBCDIC16. to ARAFILE $EBCDIC27.
ARABUFR $EBCDIC16. to ARABUFR $EBCDIC18.
INPUT ARAFPERA &PIB.2. /* #FILES FOR AREA*/
and change SKIP=SKIP-184 to SKIP=SKIP-208;
After PMHRTYPE=2, change INPUTs of
BUFNAME $EBCDIC16. to BUFNAME $EBCDIC18.
and change SKIP=SKIP-120 to SKIP=SKIP-122;
After PMHRTYPE=6, change INPUTs of
JRLNAME $EBCDIC16. to JRLNAME $EBCDIC27.
and change SKIP=SKIP-120 to SKIP=SKIP-131;
After PMHRTYPE=18, change INPUTs of
DBKAREA $EBCDIC16. to DBKAREA $EBCDIC27.
DBKFILE $EBCDIC16. to DBKAREA $EBCDIC27.
and change SKIP=SKIP-120 to SKIP=SKIP-142;
-The actual change processes 12.01 and earlier data.
Thanks to Don Snively, E-Systems, USA.
Change 13.222 Support for COM-PLETE Version 4.6 has no change in their
VMACCOMP record format, but two errors in MXG were uncovered: if
Oct 7, 1995 you use a single SMF TYPE for your COM-PLETE record, MXG
failed to output the COMPULOF and COMPUCKP datasets. The
line with _IDCOMOF should test ULOGRTYP=3 (was 1), the
line with _IDCOMCK should test ULOGRTYP=2 (was also 1).
These two changes are required for either 4.5 or 4.6, but
only if you use a single SMF record type in the _IDCOMP
macro definition in IMACCOMP.
Thanks to Wayne Bell, National General Insurance, USA.
Change 13.221 Support for Tandem MEASURE processes their Process, CPU,
ADOCTAND and Disk data files. See member ADOCTAND for discussion
EXTANCPU of how to create, process, and use the three datasets:
EXTANDIS TANDCPU - Interval CPU activity statistics
EXTANPRO TANDDISK - Interval DISK activity statistics
IMACTAND TANDPROC - Interval PROCESS activity statistics
TYPETAND The Tandem data files contain ASCII character data with
VMACTAND standard mainframe binary values; this support has been
Oct 6, 1995 executed both under MVS and under OS/2 (and I discovered
Dec 2, 1995 that the FB data records must have RECFM=F on the INFILE
statement under ASCII versions of SAS, but must have
RECFM=FB under EBCDIC versions, necessitating creation of
the VMXGLRF macro to provide transparent support).
NOTE: MXG will process the "native" ASCII TANDEM data on
an ASCII platform (UNIX, OS/2, WINDOWS) as is. However,
if you want to process the TANDEM data on with an EBCDIC
platform (MVS, CMS, VSE), you must NOT translate the
TANDEM data from ASCII to EBCDIC - send the TANDEM data
to MVS as a BINARY file with no conversion and NOCRLF.
If your character variables are filled with @@@@@, you
are reading data that was converted from ASCII to EBCDIC,
and it is not just characters that are corrupted!
Thanks to Barry Pieper, Norwest, USA.
Change 13.220 Length of MXGCHAN variable CHTYPE increased to $4, and
ANALRMFR ELSE clauses removed, and a RETAIN statement deleted in
Oct 3, 1995 report enhancements.
Change 13.219 ISOGON Soft Audit Version 4.1 compatibly changed record
VMACSFTA format from FB to VB format (for better maintenance in
Oct 3, 1995 future versions), and added several new variables to
both the Program and the Module datasets, including the
Accounting Fields from the JOB card in the Program data.
Change 13.218 Support for the ABARS ABACKUP/ARECOVER FSR segment in the
EXHSMWWF HSM user SMF record creates new dataset HSMWWFSR with new
IMACHSM statistics (counts, timestamps/durations, space used).
VMACHSM The new segment is now put in the DFSMShsm smfid record
Oct 2, 1995 (which previously contained only the DSR and VSR
segments), but DFSMS 1.3 or APAR OW11391 will relocate
the new segment to the smfid+1 record (which contains
FSRs). MXG is coded to create it from either of the two
HSM records. The HSMWWFSR dataset is an event record,
written at the end of ABACKUP or ARECOVER, and thus there
should be no accumulated fields across SMF records, so
there is no reference to HSMWWFSR in member DIFFHSM.
Thanks to Michael E. Friske, Fidelity Savings, USA.
Change 13.217 APAR OW14717 for SMF type 42 subtype 2 INCOMPATIBLY
VMAC42 changes the value of SMF42CSS,SMF42SSA,SMF42SAP,SMF42SSU,
Oct 2, 1995 SMF42NSZ, and SMF42SPR (cache controller and non-volatile
storage sizes), but OW14717 should not be installed, as
IBM is replacing it with a better solution. A new APAR
number OW16039 will be issued to fix the same problem but
it sets a flag bit that MXG can use to determine whether
or not the APAR is installed. These APARs affect only
the 3990-6 in Enhanced Mode, and they change the value in
the record to contain kilo-bytes instead of bytes, so
the MXG change conditionally multiplies the six fields by
1024 if the new flag bit is on. Thus with this change
installed in MXG, MXG will be correct with or without the
APAR being installed.
Change 13.216 The value of MAXTIME printed in the Title of reports is
ANALPRTR wrong; the statement IF MAXTIME LT LATEST THEN DO; should
Sep 29, 1995 be IF MAXTIME GT LATEST THEN DO:
Thanks to Jim Ray, Branch Banking and Trust Company, USA.
Change 13.215 CA's IDMS Version 12.01 records cause INPUT STATEMENT
VMACIDMS EXCEEDED RECORD, but that failure should have been caught
Sep 28, 1995 by MXG; the circumvention is to delete the line
IF SKIP GT 0 THEN INPUT +SKIP @;
that is located at the end of member VMACIDMS, after the
END; /* END SUBTYPE 18 */ statement and before the
END; /* END DO _I_ TO SMFHNREC */ statement.
This correction will allow MXG to tolerate 12.01 records.
An update to this change will be made when the DSECTS for
the new version have been received and the MXG code
enhanced to pick up the new variables.
Thanks to Don Snivley, E-Systems, USA.
Change 13.214 The BGS I/O Monitor SMF record produces invalid records
VMACBGSI with MVS/ESA 5.2. MXG does not fail, but prints INVALID
Sep 28, 1995 TRIPLET messages on the log and deletes the records. BGS
alerted me and is investigating their error.
Change 13.213 Variables TSORESP TRIVRESP TSO2RESP TSO3RESP TSO4RESP in
RMFINTRV PDB.RMFINTRV are now FORMAT 7.3 (instead of 5.1), because
Sep 28, 1995 average trivial response is now often measured in tens of
milliseconds, which disappear when printed with the
shorter format.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.212 DB2 stats dataset DB2STAT2 should never have been used in
DIFFDB2 building DB2STATS, as it contains only threshold values
VMACDB2 instead of interval resources used, so all references to
Sep 27, 1995 DB2STAT2 were removed in the building of DB2STATS in
member DIFFDB2. Now, DIFFDB2 creates DB2STATS from only
DB2STAT0 and DB2STAT1 data sets (as MXG did in 11.11!).
Fortunately, the inclusion of DB2STAT2 did not affect the
validity of DB2STATS dataset for its other variables.
-Tom also discovered that only the first buffer pool's
threshold's values were being OUTPUT to DB2STAT2 in its
creation in member VMACDB2. This correction was to move
the statement DIFFDB22=0 and the %INCLUDE of EXDB2ST2 to
be inside the DO group, and to insert statement
OFFQDBP=OFFQDBP+LENQDBP; after that %INCLUDE.
Thanks to Tom Parker, Hogan Systems, USA.
Change 13.211 MXG 13.02-MXG 13.05 only. IMF processing will cause an
TYPECIMS error 80-322 and 201-322 occur if you use member IMACCIMS
Sep 27, 1995 to define MACRO _LIMFTRN CIMSTRAN.CIMSTRAN %, because MXG
Change 13.089 incorrectly added _LIMFTRN to the DELETE
statement. Change DELETE _LIMFTRN CHAINED ; to read
DELETE CHAINED;
Thanks to Jim Wertenberger, Blue Cross Blue Shield of Ohio, USA.
Change 13.210 Labels for variables were clarified in TYPE70:
VMAC7072 NRCPUS ='NUMBER OF*CPUS AVAILABLE*TO THIS MVS'
Sep 27, 1995 PARTNCPU='TOTAL*NUMBER OF CPUS*IN THE CEC'
and in TYPE70PR:
LPARCPUS='NUMBER OF*CPUS IN*THIS LPAR'
Thanks to Angela Mulcahey, United Jersey Bank, USA.
Change 13.209 Comments describing use were enhanced, pointing out that
IMACFILE all SMF-processing programs use IMACFILE; if you want to
Sep 25, 1995 tailor IMACFILE for only one job (eg., BUILDPDB), then
you should put the tailored IMACFILE member in a special
PDS source library in the //SOURCLIB concatenation for
that one job, instead of putting it in the USERID.SOURCLI
tailoring library.
Thanks to Mr. Jan Beukeletrs, ANHYP NV, Belgium.
Change 13.208 INVALID DATA FOR DTL results if there is no value for the
VMACEREP last activity time. Insert ?? between DTL and &PD.4.
Sep 25, 1995 to suppress the invalid data message. This revision also
Oct 3, 1995 adds Machine Check Handler (MCH) record processing.
Thanks to Mr. Geiger, KKH, GERMANY.
Change 13.207 INVALID ARGUMENT error if there are more than 10 LCUIDs
ANALPATH associated with one CHPID, so the ARRAY was increased to
Sep 25, 1995 16, but the source of the error was that ANALPATH applied
Oct 2, 1995 IF &PRMTM; prime-time-only selection only to the TYPE74
dataset, while TYPE73 and TYPE78CF (from whence the error
came) had no shift selection (and the data that cause the
large number was across several IPLs with different I/O
configurations). Thus IF &PRMTM; was added logically to
the subsetting of TYPE73 and TYPE78CF datasets as well as
increasing the size of the ARRAY.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.206 Variables ACTDLYTM, DSPDLYTM, and RESDLYTM are now added
VMAC30 to the TIME12.2 format, to print consistently with other
Sep 25, 1995 duration variables.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.205 Variable HMF5BS29 was always zero, because it should not
DIFFHMF have been DIF()ed. Remove both lines in DIFFDB2 than
Sep 25, 1995 contain HMF5BS29.
Thanks to Shaheen Pervaiz, Acxion CDC, Inc, USA.
Change 13.204 MXG coding for Landmark TMON/CICS 1.3 was INCOMPATIBLY
TYPETMON changed so that TMON data could be processed under ASCII
Sep 25, 1995 and EBCDIC versions of SAS. You MUST change your JCL for
the DDname of MONICICS from RECFM=U BLKSIZE=32760 to be
RECFM=VB LRECL=32756 BLKSIZE=32760 with this change.
(I regret the inconvenience, but this was the only way to
support LANDMARK data processing under OS2/UNIX/WINDOWS
and is the way TYPETMON should have been coded. Since VB
processing is faster than U processing, you may actually
see a faster run time! And even if you don't read this
notice, the error message that you now get will tell you
that you have either used RECFM=U in place of RECFM=VB,
or that you are trying to read compressed data without
having installed the EXITMON6 decompression exit!).
The code changes were to delete the two lines that INPUT
LENMONI1 and LENMONI2, to change all occurrences of
LENMONI1 to MONILEN, and to replace the INPUT of ENDDATE
as YYMMDD6. with YY &NUM.2. MO &NUM.2. DD &NUM.2. and
then use IF YY GT 0 THEN ENDDATE=MDY(MO,DD,YY);
Note that for processing TMON 1.3 data under ASCII SAS,
you must use
FILENAME MONICICS 'C:\...'
RECFM=S370VB LRECL=32752 BLKSIZE=32756;
Thanks to Ian Gibson, Queensland Transport Department, AUSTRALIA.
Change 13.203 MXG execution under ASCII only. Landmark 8.1 format MXG
TYPEMON8 code was not updated for ASCII execution, causing wrong
Sep 25, 1995 values and notes on the log. Change all occurrences of
"RB8." to "&RB.8.", and replace ENDDATE as described in
Change 13.203. There is no error under MVS execution.
Thanks to Ian Gibson, Queensland Transport Department, AUSTRALIA.
Change 13.202 Variable DURATM was created, equal to INTERVAL, to be
VMAC23 consistent with SAS/CPE desires.
Sep 22, 1995
Thanks to Mitch McKenna, Independent Consultant, Australia.
Change 13.201 Support for Omegamon for MVS/ESA V400 adds these new
VMACEPMV twenty-three variables:
Sep 22, 1995 SM180APS SM180ARC SM180ASC SM180CFR SM180CSS SM180EFR
SM180HSP SM180IOC SM180OLS SM180OM1 SM180OM2 SM180QUI
SM180RGN SM180RGP SM180SCN SM180SCP SM180SCX SM180SPS
SM180SVF SM180VIO SM180WKS SM180WLN SM180XME
Thanks to Frank Altrichter, Bell Atlantic, USA.
Change 13.200 Variables SYSNAME and SYSPLEX were not in PDB.RMFINTRV,
RMFINTRV although Change 13.172 supposedly made the addition; the
Sep 22, 1995 variables must be added to the ID statement that precedes
OUTPUT OUT=RMF70D1 .... MXG processing currently assumes
that each of your SYSTEM ids are unique within a SYSPLEX;
if that is not true, I may have to change the sort order
of all of the RMF datasets from SYSTEM STARTIME to
SYSPLEX SYSNAME SYSTEM STARTIME, but I will defer that
change until truly required (and I have test data!).
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.199 SAP variable STICODE in CICS journal records should be
IMACICSA INPUT as $EBCDIC4. (it was &PIB.4.), as it is a transact
Sep 22, 1995 code (similar to STCTCODE).
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.198 Support for 3590 tape drives was incomplete, as variable
ANALTAPE TAPE3590 was not added to PDB.JOBS & PDB.STEPS datasets.
BUILDPDB -IMACPDB must be updated. Variable TAPE3590 must be added
BUILDPD3 to macro _PDB30_4 and to macro _MAXSTP, and then the PROC
BUILD005 MEANS OUTPUT statement required the X9 to be changed to
ChangeSS X10, and the SUM= statement required the addition of X10
IMACPDB after the X9. Note that if IMACPDB exists in your
VMAC30 USERID.SOURCLIB, you must retrofit your tailoring in that
Sep 22, 1995 member, starting with this new IMACPDB member.
-Although not required, the TAPExxxx variables in LENGTH
statements in BUILDPDB, BUILDPD3 and BUILD005 were taken
out, as the _MAXSTP macro reference already contains the
TAPExxxx variables, and their removal avoids confusion.
-It was also noted that none of the EXCPxxxx or IOTMxxxx
variables were kept in TYPE30_6, so member VMAC30 was
updated to add _IO30IO to the KEEP list for TYPE30_6 to
be consistent with other type 30 datasets.
-ANALTAPE was updated to report 3590 tapes separately
-Finally, my notes on what I have to do for a new tape
device (text of Change 9.152 in CHANGESS) were revised
so I do it right the first time the next time!
Thanks to Norbert Korsche. OMV AG, AUSTRIA.
Change 13.197 By changing all occurrences of SORTDSNS to DSNAMES, the
VMXGVTOF PROC SORT DATA=DSNAMES .... that precedes the %DO group
Sep 22, 1995 can be eliminated, saving an extra pass of the data.
Thanks to Graeme Yeandle, British Telecom, ENGLAND.
Change 13.196 Protection for future version changes was not correct for
VMACHMF subtype 4, 5, 8, and 9, as the subtractor should be 26,
Sep 22, 1995 16, 54, and 64 respectively. (The segment lengths do not
include their own length.) However, there was no error
with the current version's records.
Thanks to Shaheen Pervaiz, Acxiom CDC, Inc, USA.
Change 13.195 Variables BATRSPRO BASCRUID BASPCCHN BARTNDTA BAVOLOWN
VMACTLMS were not in the KEEP list, nor were they in the LABEL
Sep 22, 1995 statement, but now they are.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Change 13.194 Variables IMSID (IMS System ID) was added to the KEEP
VMACCIMS list for datasets CIMSDBDS and CIMSDB2 to ease in reports
Sep 22, 1995 by system.
Change 13.193 Variables QWSBIID,ISEQ,OTH1,OTH2,SBNA,SCF,SRND,SRNW,SRSW
VMACDB2 were added by Change 13.139 but those names were already
DIFFDB2 in use, and where they were DIF()ed in DIFFDB2, wrong
Sep 21, 1995 counts were created. Fortunately, these variables record
generally unimportant counts of activity by IFC, and they
were added only to eliminate a nuisance message from MXG,
but now they were renamed to QWSYxxxx to avoid conflict.
This change could not be made with a global change, so if
this is really of concern, you will need the new version.
Thanks to Tom Parker, Hogan Systems, USA.
Change 13.192 INVALID SECOND ARGUMENT IN FUNCTION SUBSTR occurs in the
VMAC102 processing of DB2 Trace IFCIDs 21 or 44. The following
Sep 21, 1995 changes must be made twice; once after MACRO _C102021 and
once after MACRO _C102044.
Find the following code:
DO I= 1 TO 27 BY 3;
IF I LT 27 THEN ....
ELSE ....
....
IF I=27 AND J=7 THEN J=20;
....
Change it to read:
DO I= 1 TO 19 BY 3;
IF I LT 19 THEN ....
ELSE ....
....
IF I=19 AND J=13 THEN J=20;
....
Thanks to Mitch McKenna, SAS Europe, GERMANY
Thanks to Mealin Beecking, Generale de Banque NV/SA, BELGIUM.
Change 13.191 Building the $DB2DBID and $DB2OBID formats may still fail
ANALDB2R when there are zero obs in T102S105 or T102S107, due to
Sep 21, 1995 insufficiently robust logic.
Find IF FIRST.DBID THEN DO; . Replicate this DO group.
In the first DO group, change the IF FIRST.DBID THEN DO;
to IF FIRST.DBID AND LAST.DBID THEN DO; . In the second
DO group, change the IF FIRST.DBID THEN DO; to
ELSE IF FIRST.DBID THEN DO; . In the first DO group,
insert OUTPUT; after LASTNAME=DBNAME;
Find IF FIRST.OBID THEN DO; . Replicate this DO group.
In the first DO group, change the IF FIRST.OBID THEN DO;
to IF FIRST.OBID AND LAST.OBID THEN DO; . In the second
DO group, change the IF FIRST.OBID THEN DO; to
ELSE IF FIRST.OBID THEN DO; . In the first DO group,
insert OUTPUT; after LASTOAME=OBNAME;
Thanks to ????, Union Bank of Switzerland, SWITZERLAND.
Thanks to Werner Schellenbert, SAS Switzerland, SWITZERLAND.
Change 13.190 The format of variable UOWTIME in all datasets is changed
ANALDB2C to DATETIME25.6, because the previous DATETIME21.2 format
TYPEMOND caused the PROC MEANS in ANALDB2C to collapse what were
TYPEMON8 separate events into one output observation (because the
TYPETMON variable UOWTIME is in the BY list, and PROC MEANS, like
VMACCIMS most other procedures, uses the formatted value to build
VMACDB2 its output observation).
VMACDB2H The ANALDB2C error could be corrected with the addition
VMACOMCI of "INCODE=FORMAT UOWTIME DATETIME25.6;," to both
VMAC116 of the %VMXGSUM invocations and by changing the FORMAT
VMAC123 statement, which would let ANALDB2C use date that was
Sep 21, 1995 created prior to this change, but that circumvention will
cause an extra pass of CICS and DB2 data by ANALDB2C.
So the permanent correction was to change the format in
all of the members that create variable UOWTIME, and only
the existing FORMAT statement was changed in ANALDB2C.
Thanks to H. Thomas Lowin, ICG Informationssysteme, GERMANY.
Change 13.189 INVALID DATA FOR AFSTTIME in type 91 BatchPipes/MVS SMF
VMAC91 record because of a reserved field. After the INPUT of
Sep 21, 1995 SMF91IWB &PIB.4. and the INPUT of SMF91OWB &PIB.4.,
insert +4 (to skip over the reserved field).
Thanks to Siegfried Trantes, IDG Gmbh, GERMANY.
Change 13.188 Variable WRBUFUSE (write buffers used) was added to KEEP
VMAC50 list for dataset TYPE50, and is now input by changing the
Sep 20, 1995 @39+OFFSMF +4 to read @39+OFFSMF WRBUF &PIB.4. (for the
subtype 01 (channel-to-channel) record).
Thanks to Earl Berg, Bank of America, USA.
Change 13.187 ASMTAPES revision MAINTLEV 6 now replaces prior version.
ASMTAPES MXG 13.05 ASMTAPES may stop writing allocation records,
Sep 29, 1995 although mount records continue to be written. The SRB
that we schedule fails if the job in allocation (or in
allocation pending) is swapped out. We continue to retry
the SRB, but if an internal maximum count is exceeded, we
(erroneously, I now realize!) shut down the allocation
monitor and stop writing records. This section of the
monitor has been redesigned, now that we realize why the
SRB routine times out. In addition, this revision
-Adds 'DEBUG' mode, which can be invoked via Operator
Modify Command "F MXGTMNT,DEBUG=YES" (default at startup
is DEBUG=NO, so that debugging messages TMNT009I/011I
will not be written by default).
-Corrects incorrect job and step information due to
allocation recovery and step changes
-Enhanced code to get DDNAME when a device is initially
found in allocation recovery, but later sampled during
execution. The DDNAME is unavailable during allocation
recovery, and so records written only for allocation
recovery will not have a DDNAME; once the job goes from
allocation recovery to execution, a subsequent monitor
sample will now pick up the DDNAME.
Change 13.186 Support for year 2000 for TLMS records was added. Twelve
VMACTLMS fields that contain dates with century value will now be
YEAR2000 converted to four digit values (eg., the 0100001 value of
Sep 20, 1995 01Jan2000 will now be converted to 2000001). The logic
is X=FLOOR(X/100000)*100+1900+X; for each of these X:
BAPURCH BADESTDT BACLNDT BACERTDT BAVMOVED BAVKEEPD
BAVEXPDT BAVSCRDT BADKEEPD BADEXPDT BACDATE BAIDATE
TLMS was not previously recognized as needing conversion,
because these twelve variables are simply numbers and are
not converted to SAS date values (and my research in the
YEAR2000 member only addressed MXG variables that are
date values).
Thanks to Rey Marquez, General Accident Insurance, USA.
Change 13.185 INPUT STATEMENT EXCEEDED RECORD LENGTH for type 92 SMF
VMAC92 because the INPUT of SMF92PPL should have been &PIB.2.
Sep 20, 1995 instead of the &PIB.4. that was coded.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.184 Variable SMF22SNV should be labeled SUBSYSTEM*NVS*STATUS.
VMAC22 New variable SMF22PNV should be created by inserting
Sep 20, 1995 SMF22PNV $CHAR1. immediately after the INPUT of
SMF22SNV, and SMF22PNV must be added to the KEEP= list,
the $HEX2. list, and the $NOTRAN. list, after SMF22SNV.
Thanks to Dean Brown, Pacific Bell, USA.
Change 13.183 MXG 13.01-MXG 13.05 only. RACF type 80, ACF2 user SMF and
IMACJBCK DB2 type 101 observations were not output if job name was
VMAC80 hex zeroes.
VMAC80A For consistency, Change 13.076 added IMACJBCK to all SMF
VMACDB2 processing members (IMACJBCK allows selection of records
VMACACF2 by job name), but it contained a default test of
Sep 1, 1995 IF JOB GE ' '; but if the variable JOB has
Sep 20, 1995 nulls, this addition causes the record to be deleted!
Nov 30, 1995 It now turns out that RACF can write records with nulls
for job name - "For RACINIT records for batch jobs,
SMF80JBN can be zero", and those records were deleted.
Also, DB2 records for Distributed Threads for non-DB2
requestors contain nulls for JOB, causing observations in
DB2ACCT and DB2ACCTP datasets to be deleted.
The change was to eliminate that default test in IMACJBCK
so it only contains comments about how it can be used!
There was no change to VMAC80, VMAC80A, nor VMACDB2, but
they are listed here for the alert of the problem.
Thanks to Joe Faska, Depository Trust, USA.
Thanks to Tom Parker, Hogan Systems, USA.
Change 13.182 SNS/TCPaccess Version 2.1.0 added on new variable F20AERR
VMACILKA to dataset ILKAST20 compatibly.
Sep 1, 1995
Thanks to Joe Schwartz, CIGNA, USA.
Change 13.181 APAR OW11142 adds new variables with compression stats:
VMAC64 SMF64CCS SMF64CDS SMF64CMP SMF64CSS SMF64DTK SMF64EF
Sep 1, 1995 SMF64SDS SMF64TRK
In addition, variable ALLOCCYL is now calculated to give
the allocated size of the VSAM component.
Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.
Change 13.180 TYPE42DS and TYPE42SR variable RESPTIME was found to be
VMAC42 greater than the sum of connect, pend, disconnect and CU
Sep 1, 1995 queue; IBM development confirmed that the IOS queue time
is included in RESPTIME but not separately recorded, so
AVGIOQMS=RESPTIME-(AVGCONMS+AVGPNDMS+AVGDISMS+AVGCUQMS);
was inserted after AVGCUQMS=128*AVGCUQMS; in two places,
AVGQIOMS was added to the KEEP= for both datasets.
In addition, these "millisecond" variables RESPTIME
AVGIOQMS AVGCONMS AVGPNDMS AVGDISMS and AVGCUQMS are now
multiplied by 1000 so their values are actually in
milliseconds. I know this will affect those of you that
have started to use the TYPE42DS data, but consistency
with their labels and with counterpart variables in the
TYPE74 dataset justify this annoyance to those pioneers
who have already found this valuable data source.
Thanks to Bruce Sloss, PNC Bank, USA.
Change 13.179 RACFTYPE=34 caused "SKIPPED SEGMENT" message on the log,
VMAC80A but had no impact on created datasets. To eliminate the
Aug 30, 1995 diagnostic, copy the WHEN (55) DO; block to after the
WHEN (33) block, and then change the 55 to 34.
Thanks to Joe Faska, Depository Trust, USA.
Change 13.178 MXG 13.05 only. Variable NDMTIME is missing because the
VMACNDM test IF DATEYYYY GT 80000 AND .. should have been changed
Aug 30, 1995 to IF DATEYYYY GT 0 AND .... (the 80000 test was for a
julian date after 1980, but DATEYYYY was change to a SAS
date by Change 13.158, and current value is only 13,000).
Thanks to Chuck Hopf, MBNA, USA.
Change 13.177 Variable VELOCITY is added to TYPE72 & TYPE72GO datasets
VMAC7072 (for both Compatibility and Goal Mode measurement). The
Aug 30, 1995 equation is VELOCITY=CPUUSESM/SUM(CPUUSESM,TOTDLYSM);
for dataset TYPE72 and the equation is
VELOCITY=PCTUSCUS/SUM(PCTUSCUS,PCTDLTOT); for goal mode.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 13.176 Support for Software Engineering of America's TRMS (Total
EXTRMS01 Report Management Solution) user SMF record adds datasets
EXTRMS02 TRMS01 - Report Accumulation
EXTRMS03 TRMS02 - Report Deletion
EXTRMS04 TRMS03 - Distribution Bundle
IMACTRMS TRMS04 - Distribution Print (Demand)
TYPETRMS with the identity of the print-causing job, duration, and
VMACTRMS counts of lines, pages, etc.
Aug 30, 1995
Thanks to John Rivera, PKS Information Services, Inc, USA.
Change 13.175 If you build your weekly PDB on tape, running the TREND
WEEKBLDT code can cause lots of tape mounts. It may be wiser to
Aug 28, 1995 build the entire PDB on tape first, then use PROC COPY
with a SELECT statement to create a pseudo-PDB on DASD
with only the datasets needed for Trending.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.174 MXG 13.05 only. Assembly of ASMTAPES fails because you
ASMTAPES cannot continue ASM comments with X in column 72. Find
Aug 28, 1995 MAINTLEV, remove X's from column 72, put asterisk in col
1 (except for the final MAINTLEV EQU 5, which was ok.)
This was a stupid error; I changed the comments and then
failed to reassemble the program.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.173 OMEGAMON CICS V300 SMF Subtype 200 subsubtype 4 caused
VMACOMCI INPUT STATEMENT EXCEEDED RECORD LENGTH due to MXG error.
Aug 24, 1995 Insert between EEDRMFS and EEDTSIO these lines:
EEDRMFS &PIB.1.
@;
IF SUBTYPE=200 THEN INPUT +3 @;
INPUT
EEDTSIO &PIB.4.
and change the subsequent IF SUBTYPE=200 THEN LOC=LOC+1;
to read IF SUBTYPE=200 THEN LOC=LOC+4;
Thanks to F. Pulles, Compuzorg B.V., THE NETHERLANDS.
==========MXG Version 13.05, dated Aug 21, 1995, thru 13.172==========
Change 13.172 Variables SYSPLEX and SYSNAME were added to all of the
RMFINTRV RMF/CMF datasets built from type 70-79 records (they had
VMAC7072 been inconsistently kept) and were added to RMFINTRV data
VMAC71 set as well, so as to fully analyze sysplex data from
VMAC73 multiple sysplexes.
VMAC74
VMAC75
VMAC76
VMAC77
VMAC78
VMAC79
Aug 23, 1995
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 13.171 Support for MVS/ESA 5.2.2 was thought to be contained in
none MXG 13.02, as there appeared to be no new record changes
Aug 22, 1995 in 5.2.2. However, that was not true, and once IBM got
Jan 11, 1996 the new SMF manual to me, there were noted several new
data. Fortunatly, the 5.2.2 changes were compatible so
that none of your existing datasets failed with MXG 13.02
and 5.2.2 records (except for Open Edition/MVS type 92
data). Change 13.156 added the support for type 88 data,
Change 13.162 fixed an MXG error in type 6 record that
occurred at a 5.2 site (though the error was due to PSF
and has happened with earlier MVS), Change 13.310 added
fields to type 30, and Change 3.311 dealt with the type
92 so to completely capture all of the new 5.2.2 fields
from all records, MXG 13.13 is required.
Change 13.170 Support for additional subtypes from Landmark TMON/MVS:
EXTMVMLG subtypes CS, IX, ML, and XI are now decoded and these new
EXTMVMLL datasets are created from ML and XI records:
EXTMVMLP Dataset Description
EXTMVMLV TMVSMLG PR/SM Global Segment
EXTMVXIM TMVSMLL PR/SM Logical Partition
EXTMVXIP TMVSMLP PR/SM Product Segment
EXTMVXIS TMVSMLV PR/SM Virtual Processor
FORMATS TMVSXIM XCF Member
IMACTMVS TMVSXIP XCF Path
TYPETMVS TMVSXIS XCF System
VMACTMVS while existing datasets TMVSCS and TMVSIX are now
Aug 21, 1995 populated with variables.
-Additional decoding of several existing segments:
Subtype CI, variables CIJFM and CIJGM are not listed in
either the online documentation (Ver 1.3, Mod 9405):
A: ADVANCED FUNCTIONS
4: DICTIONARY RECORD DIRECTORY
nor in the 'Report Writer' 8: Data Elements document,
but are in member TMVDSECT (with the same OFFSET=54).
Both variables are generally marked as comments.
-The TRANSLATE function was inserted after each input
for some variables in the subtypes 'NQ' and 'PS'.
Thanks to Peter Proppe, Bremer Lagerhaus Gesellschaft(BLG), GERMANY.
Thanks to Rod Fernandes, Albert Heijn B.V., NETHERLANDS.
Change 13.169 Support for OMEGAMON/MVS Version 300 incompatibly changed
VMACEPMV the I/O section, causing INPUT STATEMENT EXCEEDED RECORD.
Aug 21, 1995 The new I/O section logic now looks like this:
IF SM180VRS GE '03' THEN DO; /* OMEGAMAON 300+ */
INPUT @SM180OIO
SM180DVT $EBCDIC1.
SM180DNR $CHAR3.
SM180DEV $EBCDIC4.
SM180ACT &PIB.4.
SM180QCT &PIB.4.
SM180VOL $EBCDIC6.
@;
FORMAT SM180DNR $HEX6. ;
END;
ELSE DO; ... original code ... END;
and variables SM180DNR SMF180DVT were added to KEEP= list
for dataset EPMVEPIO.
Thanks to Frank Altrichter, Bell Atlantic, USA.
Change 13.168 VM/ESA 2.2 UNEXPECTED/INVALID CONTROL RECORD FOUND was
VMACVMXA encountered with IPARMLF1=873Fx and IPARMSG1=MSG2=03Fx,
Aug 22, 1995 causing me to reopen and revise Change 13.126 after it
was printed in Newsletter 28. However, the site's data
is invalid (for example, the 1.14 record had domain 3Fx,
but there are only 10 domains, and the record length of
the 1.14 record is 34, but there are only 28 bytes until
the next 1.14 record). The VM data was sent to MVS with
FTP using MODE S (Stream) with no TYPE E (EBCDIC) instead
of MODE B (Block) TYPE E, and this caused data values to
to be changed in transmission ('09'x was changed to 'F3'x
and '1C'x was changed to '22'x by TCP/IP!). Now that I
know the cause of the bad values, I might not have made
the revisions in Change 13.126, but they make the support
more robust and are thus worthwhile to keep.
Thanks to Connie Mak, Avon, USA.
Change 13.167 This work is incomplete. MVS/ESA 5.2 added several new
ASMRMFV tables that need to be added to ASMRMFV and then decoded
VMACRMFV in VMACRMFV, but I have no test data for validation. As
Aug 21, 1995 test data is provided, the support will be coded and
tested. Nothing was changed in ASMRMFV in this change;
VMACRMFV was updated with new code blocks and new 5.2
variables were added to existing datasets, but more work
is required for the new segments.
Change 13.166 Support for 3590 Tape device adds variables EXCP3590 and
FORMATS IOTM3590 and TAPE3590 to TYPE434, TYPE30_V, TYPE30_4,
IMAC30IO TYPE30_5, TYPE30_6, TYPE40, PDB.JOBS, and PDB.STEPS data
VMAC434 sets. The DEVCLASS/DEVTYPE value for this new device is
VMAC30 '8083'x; in member FORMATS, only the formats MGCMFDD and
VMAC40 $MGDEVTY use those IBM values; the formats MGERPDV (EREP)
VMACEXC2 and MGZAREN/MGZARTQ (ZARA) have their own device type
VMACUCB value and I have guessed that the value '43'x will be the
Aug 19, 1995 3590 value, but I will confirm with IBM and Altai.
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).
Change 13.165 Deaccumulation of HMF datasets TYPEHMF4, TYPEHMF5,
DIFFHMF TYPEHMF6, TYPEHMF7, TYPEHMF8, and TYPEHMF9 is required.
TYPEHMF Member DIFFHMF is automatically invoked now in member
VMACHMF TYPEHMF, but if you add HMF record processing to your PDB
Aug 11, 1995 you must also add %INCLUDE SOURCLIB(DIFFHMF); in the
Aug 20, 1995 member EXPDBOUT to accomplish the deaccumulation.
Some $EBCDIC variables were changed to $CHAR with $HEX
format. Test data has determined what should/should not
be deaccumulated because it is not noted in the vendor's
documentation, but some fields were always zero and thus
you should verify with your own data. The vendor states
that variables HMF8CS06 thru HMF8CS12 in TYPEHMF8 data
set are invalid and should not be used; the problem has
been open for over a year and is not resolved yet.
Thanks to Shaheen Pervaiz, Acxiom CDC Inc, USA.
Change 13.164 Support for EREP (SYS1.LOGREC) records adds 19 datasets:
EXERPCRW EREPCRW - Channel Report Word
EXERPDDR EREPDDR - Dynamic Device Reconfiguration
EXERPEOD EREPEOD - System Ending /EOD/Normal/Abnormal
EXERPETR EREPETR - External Timer Reference Record
EXERPHDR EREPHDR - LOGREC Header Record
EXERPIOS EREPIOS - Input/Output Supervisor Recovery
EXERPIPL EREPIPL - System IPL
EXERPLMI EREPLMI - Link Maintenance Information
EXERPLRS EREPLRS - Lost Record Summary
EXERPMCH EREPMCH - Machine Check Handler
EXERPMDR EREPMDR - Miscellaneous Data Record
EXERPMIH EREPMIH - Missing Interrupt Handler
EXERPOBL EREPOBL - Outboard Long Records
EXERPOBR EREPOBR - Outboard Short Records
EXERPSDW EREPSDW - Software System Diagnostic Area
EXERPSIM EREPSIM - DASD Service Information Message
EXERPSLH EREPSLH - Subchannel Logout Handler
EXERPSYM EREPSYM - Symptom Programming Failure
EXERPTIM EREPTIM - Logrec Time Stamp Record
IMACEREP Either SYS1.LOGREC or EREP records can be processed with
JCLEREP this support, even though the data records are not quite
TYPEEREP identical. All records have been tested except for the
VMACEREP ETR, SIM, IOS, and MCH events, which did not occur in my
Aug 20, 1995 test data.
Thanks to K.U. Geiger, KKH, GERMANY.
Change 13.163 MAINTLEV 6 does not yet exist, although it was listed in
ASMTAPES this change text in the printed MXG Newsletter 28. It is
VMACTMNT still in development testing. The ASMTAPES on this 13.05
Aug 12, 1995 is MAINTLEV 5, which seems to solve the stall problem
Aug 19, 1995 (the monitor would simply stop, using no CPU and writing
no records) by better handling the SRB. You may see some
"TMNT" messages printed on the job log of the MXGTMNT job
(TMNT009I SRB Timeout PURGEDQ attempts, TMNT011I SRB was
PURGED) that are really diagnostics to indicate how often
the SRB we scheduled in the tape job's address space did
not respond. Previously we sometimes scheduled a second
SRB before the first ended; now if the first is not back
we first purge it and then start another SRB. We almost
always eventually get the information back from the SRB
routine, so that the data in the SMF record is usually
good even when SRBs are purged. However, the READTIME
and other timestamp variables may be invalid if the job
ended before we got the SRB response, so I have added ??
modifiers to the SMFSTAMP fields in VMACTMNT so as to
avoid printing of a hex dump if you should by chance get
an invalid READTIME in a record. The "TMNT" messages so
far occur mostly right on or after the hour, and then for
hours there are none, and we are using these diagnostics
to continue to enhance what will be MAINTLEV 6. In that
iteration, the printing of those "TMNT" messages will be
optional, and the default will be not to print them.
The problem that is still in development testing occurs
very infrequently, but we still occasionally find the
PROGRAM=IEFIIC or the incorrect job name will be put in
the SMF record. This seems to be isolated to jobs that
had some tapes allocated, went into allocation recovery
for additional drives, received WAIT,NOHOLD response, had
its drives stolen away, and later was reallocated to the
same device. This fix may require additional records to
be created and additional logic in VMACTMNT to completely
resolve these rare instances. Statistically, the records
created by MXGTMNT still are quite valid.
Please contact Merrill Consultants (or your overseas SAS
office) if you would like to be shipped MAINTLEV 6 when
it is ready (probably not before October, 1995).
A note about CA/LEGENT's MIM product and NOHOLD.
The sites which have had problems with the open problem
above have been MIM sites, and their MIM administrator
had specified that MIM should reply NOHOLD. In the MIM
manual, there is a statement that NOHOLD is required by
MVS 4.3, but the MIM Product Manager has confirmed that
that statement is false; either HOLD or NOHOLD can be
used with any version of MVS. It is true that MIM does
strongly recommend that you use NOHOLD instead of HOLD,
because MIM favors throughput over job importance.
In a MIM environment, when a job gets WAIT,HOLD response,
that job will block any other allocations by any other
job on any other system from getting any tape drive in
that tape group, until it completes its allocation. Thus
HOLD response favors the completion of the job that has
already been initiated ahead of any other job.
By specifying WAIT,NOHOLD, those drives that have already
been allocated are freed, and the job goes to the bottom
of allocation queue, so that maybe another job on this or
another system could now run. This favors other jobs.
I think I would rather finish what I have started first
(especially if I have a smart job scheduling system that
is based on service objectives - I can presume there that
the job that was started was more important than the not
started job), but you must understand the difference and
make your own decision as to which senario is appropriate
for your site's job scheduling system, and not just
arbitrarily accept MIM's NOHOLD recommendation.
======Early MXG Version 13.05, dated Aug 14, 1995, thru 13.162======
Change 13.162 PSF 4.0 type 6 SMF record INPUT STATEMENT EXCEEDED RECORD
VMAC6 LENGTH error because IBM did not document that SMF6TUL
Aug 11, 1995 includes its own two bytes, causing MXG to try to read 2
more bytes than are in the record. After the @; after
the INPUT of SMF6TUL, insert this line:
SMF6TUL=SMF6TUL-2;
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.161 Variable MQMSSSID was added to all MQM datasets; it had
VMAC115 been input separately as SM115SSI or SM116SSI, but it was
VMAC116 not kept. Labelled MQMSSSID='MQM*SUBSYSTEM*ID', it is
Aug 9, 1995 needed to associate MQM records.
Thanks to Pat Quinnette, Principal Mutual Life Insurance Co., USA.
Change 13.160 RMF Reports show MVS/XA for MVS/ESA version 3 because two
ANALRMFR tests GE "4" should have been GE "3". The adjacent MVS
Aug 8, 1995 release number (3.1.3) was printed correctly.
Thanks to Victor Chacon, NYNEX, USA.
Change 13.159 DB2 Statistics Detail report, page 6 had 4 values wrong
ANALDB2R and four labels were clarified, and the SHIFT= parameter
DIFFDB2 did not work quite right.
Aug 8, 1995 Buffers Allocated (VPOOL or HPOOL) were negative because
their variables, QBxTVPL and QBxTHPL, were wrongly built
in data set DB2STATS; those variables were DIF()ed in
member DIFFDB2, but they are endpoint values, instead of
accumulated, a fact not documented by IBM; only non-zero
data can validate whether to DIF() or not to DIF()!
Delete all lines in DIFFDB2 with TVPL or THPL suffix.
-The values for GET/PAGE SYNC READ RANDOM was incorrectly
calculated.
Replace RANDOM with RANDOMP for the random page calcs,
replace RANDOM with RANDOMR for the random read calcs,
and recalculate RATIO=RANDOMP/RANDOMR.
-The value for D PRF PAGES READ was wrong because the
variable RANDOM was printed instead of RATIO.
-Labels for the four rations now read:
RANDOM PAGES PER READ, SEQ PREFETCH PAGES PER READ,
LIST PREFETCH PAGES PER READ, DYN PREF PAGES PER READ.
-If you used SHIFT=P in report PMSTA01, you would not just
get a report for all Prime time in DB2STATS, but got
multiple reports, one short and before prime, and one
that covered almost all of the requested shift (and that
report was accurate for the timeframe it reported). The
error was in using ENDTIME instead of STRTTIME in the
recalculation of SHIFT. After %MACRO PMSTA01, move the
STRTTIME=ENDTIME-DURATM; statement to immediately before
the %IF %LENGTH(&SHIFT) GT 0 %THEN %DO; statement, then
three lines later, change DATETIME = ENDTIME to read
DATETIME=STRTTIME;
Thanks to Neil Ervin, Huntington Service Company, USA.
Thanks to Cal Cooke, Huntington Service Company, USA.
Thanks to Clark Jennings, Reynolds Metal, USA.
Change 13.158 Support for the Year2000, phase one:
DOC -All variables with DATETIME or DATE formats were changed
Aug 7, 1995 to expand the printed width to display the year in four
print positions:
Was Now Is So it will print as
DATE7. DATE9. 08Aug1995
DATETIME16. DATETIME18. 08Aug1995:20:58:20
DATETIME19.2 DATETIME21.2 08Aug1995:20:58:20.99
DATETIME20.3 DATETIME22.3 08Aug1995:20:58:20.999
DATETIME23.6 DATETIME25.6 08Aug1995:20:58:20.999999
Note that only the printed value is changed; all MXG date
variables are stored in 4 bytes, and all of the datetime
variables are stored in 8, so MXG has always internally
supported the year 2000. Those variables that had an
undefined length (DATE. or DATETIME. format) were changed
to one of the above formats. Over 10,000 instances of
these formats were changed in several hundred members.
-The preliminary list of products that do not support the
year 2000 was expanded in member YEAR2000; the earlier
list overlooked some products whose dates were created
using the MDY(MO,DA,YY) function. I believe the list of
products now is very close to complete.
-Those instances of MDY(MO,DA,YY) wherein the actual FIELD
that was input was a PD4 containing 'CYYMMDDF'x are now
converted, using this logic:
CC=FLOOR(FIELD/1000000);
YY=FLOOR((FIELD-1000000*CC)/10000);
MO=FLOOR((FIELD-1000000*CC-10000*YY)/100);
DA=FIELD-1000000*CC-10000*YY-100*MO;
YYYY=1900+YY+C*100;
DATE=MDY(MO,DA,YYYY);
for these types of data values:
Hex Date
0991231F 12/31/1999
1000101F 01/01/2000
1001231F 12/31/2000
1010101F 01/01/2001
The use of YYYY instead of YY signifies that MXG has put
the code in place to support the century bit; of course,
this will be 2000 in 2000 only if the vendor sets that
century bit; otherwise it will look to be the year 1900!
-Those instances of MDY(MO,DA,YY) wherein the YY variable
was input as PIB2. can support either the Century bit or
a four digit year:
Field Decimal Hex Year
YY 99 0063x 1999
CYY 100 0064x 2000
CYY 142 0216x 2042
YYYY 1999 05CFx 1999
YYYY 2042 07FAx 2042
For these fields, this new logic is now used, as it will
correctly resolve the year whether the vendor sets the
century bit or sets a four digit year:
IF 0 LE YY LT 1960 THEN YYYY=1900+YY;
ELSE YYYY=YY;
DATE=MDY(MO,DA,YYYY);
Again, the YYYY confirms the MXG four digit year support.
Note that the MDY() function fails if the YY argument is
100, so this new logic was required.
About 20 members were protected by this additional code.
-All instances of DATEJUL() function, which does not yet
support the century bit, must be revised. Values input
with PD4 format could contain a century bit (0cyydddF0,
or they could contain a four digit year:
Hex Date
0099365F 12/31/1999
1999365F 12/31/1999
0100001F 01/01/2000
2000001F 01/01/2000
0100365F 12/31/2000
2000365F 12/31/2000
0101001F 01/01/2001
2001001F 01/01/2001
Fortunately, the following logic can be used for these
PD4 DATEJUL fields, as it will protect for either the
century bit or a four digit year:
INPUT PD4FIELD ?? PD4. @;
CC=FLOOR(PD4FIELD/100000);
YY=FLOOR((PD4FIELD-100000*CC)/1000);
DDD=MOD(PD4FIELD,1000);
IF 0 LT DDD LE 366 THEN DO;
IF 0 LE CC LE 2 THEN YYYYDDD=DDD+1000*(CC*100+YY+1900);
ELSE IF CC GE 19 THEN YYYYDDD=DDD+1000*(CC*100+YY);
ELSE YYYYDDD=.;
END;
ELSE YYYYDDD=.;
IF YYYYDDD GT 0 THEN DATEYYYY=DATEJUL(YYYYDDD);
ELSE DATEYYYY=.;
Here, the YYYYDDD confirms the MXG support for year 2000.
Eighty-two members contained 340 uses of DATEJUL() that
were modified by the addition of the above logic.
Note: the PD4 logic printed in Newsletter TWENTY-EIGHT
was incomplete; the above code is the tested code that is
now implemented in MXG 13.05.
Change 13.157 Cosmetic cleanup. Members EXECDALY, EXECEMAC, EXECPDB,
EXECDALY and EXECTEST were deleted; they had been replaced by the
EXECEMAC REXXxxxx members of the same suffixes in 1989, were kept
EXECPDB only for transition, and now are no longer needed (and
EXECTEST the EX prefix is now used only for dataset exit names).
Aug 7, 1995
Change 13.156 Support for MVS/ESA 5.2 System Logger Data SMF type 88
EXTY88 creates this new dataset:
IMAC88 TYPE88 - System Logger Data
TYPE88 These interval records record system logger activity and
VMAC88 system wide logger exceptions. IBM comments that if the
Aug 5, 1995 variable SMF88SIB (bytes deleted before the data was
migrated to DASD) is high, and variable SMF88SAB (bytes
deleted after data migration to DASD) is low, then the
system logger is successfully using the coupling facility
structure to avoid DASD input/output. MXG creates the
variable SMF88RAT as SMF88SIB divided by SMF88SAB.
This code has not been tested with data records. When I
have data records, I intend to produce reports similar to
IBM's sample program IXGRPT1 (in SAMPLIB).
Change 13.155 Support for OpenMVS File System Activity SMF type 92 adds
EXTY9201 six datasets:
EXTY9202 TYPE9201 - OMVS File System Mount
EXTY9204 TYPE9202 - OMVS File System Quiesce/Suspend
EXTY9205 TYPE9204 - OMVS File System UnQuiesce/Resume
EXTY9210 TYPE9205 - OMVS File System UnMount
EXTY9211 TYPE9210 - OMVS File System Open
IMAC92 TYPE9211 - OMVS File System Close
TYPE92 The only change in VMAC30 was to make labels consistent.
VMAC92 I used the pre-existing MXG variable names from the type
Aug 5, 1995 30 record where appropriate. This table shows what is
and what is not consistent between 30s and 92s:
MXG Type 30 Type 92 Description
Variable field field
OMVSAPG n/a SMF92APG Parent Process Group ID
OMVSASG n/a SMF92ASG Parent Session ID
OMVSOPG SMF30OPG SMF92PGD Process Group ID
OMVSOPI SMF30OPI SMF92PID Process ID
OMVSOPP SMF30OPP SMF92API Parent Process ID
OMVSOSI SMF30OSI SMF92SSD Process Session ID
OMVSOUG SMF30OUG SMF92GID Process User Group ID
OMVSOUI SMF30OUI SMF92UID Process User ID
JOB SMF30JBN SMF92JBN Job name
READTIME SMF30RST SMF92RST Read-In/Logon Datetime
STEPNAME SMF30STM SMF92STM Step Name
STEPNR SMF30STN n/a Step Number
SUBSTEP SMF30SSN n/a Sub Step Number
The SMF Manual (GC28-1457-01) has a good introduction to
OMVS accounting records in Chapter 8 (but the schematic
does not show when the 92s are written). This new type
92 record looks very useful in measuring Unix-under-MVS
I/O activity, something not available in other Unix!
This code has not been tested with data; I hope to get
test data with both OMVS 30s and 92s for testing and
intend to write a technical note on OMVS at that time.
Thanks to Lee Borgman, Boeing, USA.
Change 13.154 If CICINTRV was executed outside of BUILDPDB, it failed
CICINTRV because the macros defined in IMACCICS were not included.
Aug 4, 1995 (BUILDPDB includes IMACCICS before invoking CICINTRV.)
Add %INCLUDE SOURCLIB(IMACCICS); at beginning of code.
See Change 14.188.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.153 NPM 1.5 creates subtype 18x record with invalid data for
VMAC28 variables LNADDCTD and/or LNADDCTT, causing INVALID
Aug 3, 1995 ARGUMENT TO FUNCTION INPUT message and a hex record dump
is printed on the SAS log. Those fields did not exist in
release 1.5, but when they are non-zero, they cause the
error, because MXG expected if the LENAOF=136, it was
because the two new fields were in your record. There
is no impact on the MXG datasets, but the message and the
printed dump can be avoided by changing the test:
IF LENAOF GE 136 THEN DO; to read:
IF LENAOF GE 136 AND NPMPVN GE 15X THEN DO;
Thanks to ???, ???, Hong Kong.
Change 13.152 User-written invocations of VMXGSUM must be examined, due
VMXGSUM to a just-discovered incompatibility introduced in Change
Aug 3, 1995 12.084 (MXG 12.02 and later). Even though you used the
MXG examples, if your %VMXGSUM uses an OUTCODE= parameter
to re-calculate the DATETIME= variable-name, your results
may be seriously wrong. If your code looks like this:
DATETIME=STRTTIME,
INTERVAL=MONTH,
SUMBY =APPLID DATETIME TRANNAME,
OUTCODE =STRTTIME=DATETIME; DROP DATETIME; ,
it must be replaced with this:
DATETIME=STRTTIME,
INTERVAL=MONTH,
SUMBY =APPLID DATETIME TRANNAME,
ID =STRTTIME,
Prior to 12.084, the DATETIME= variable-name was forced
to LENGTH 8, but when the new ID=variable-name parameter
was added to replace the recalculation in the OUTCODE=
parameter, the automatic forcing of LENGTH 8 was dropped.
All MXG invocations of %VMXGSUM were changed, but I did
not realize nor document this exposure if you did not
make the change.
(Eliminating OUTCODE= eliminates a data step; also, since
12.084+ keeps only the needed variables, the variable
might not even exist to have its length changed.)
When a datetimestamp value is stored in length 4, it can
be truncated by up to 255 seconds, which can cause the
summarization value to be on the prior day, week, or
month!
No code was changed by this documentation-only change.
Thanks to Ahn Ngo, Crowley Maritime Corporation, USA.
Change 13.151 -HP PCS variables NONEW NOKILL and NOSHORT are characters,
VMACHPAI not numerics. Add all three variable names to the $8
VMACHPSU FORMAT statement in VMACHPUX, and add NONEW and NOKILL to
VMACHPUX the $8 FORMAT statement in VMACHPAI and VMACHPUX to fix.
VMACHPUX -Comparing CPU time in the HPUXGLOB and HPUXAPPL datasets
Aug 2, 1995 shows expected comparison (HPUXAPPL records over 90% of
the global CPU time. However, HPUXPROC shows more CPU
time than was recorded in the HPUXGLOB, probably because
the CPU time IN HPUXPROC is in seconds (rather than tenth
of seconds), and it appears that fractional CPU seconds
are written as 1 second. The site has "Short Lived On",
causing records for tasks running less than one second,
which may contribute to the discrepancy. HP is being
contacted concerning the CPU time resolution in HPUXPROC.
Thanks to Dan Sidorick, Smith Klein Beecham, USA.
Change 13.150 MXG 13.04 tape only. Deleted line will cause ABEND.
ASMTAPES After label TIMRPOST, following the WTO statement and
Jul 31, 1995 before the PURGEDQ statement, insert:
L R8,PRGERMTR
MAINTLEV was changed from 4 to 5 to reflect this change.
========MXG Version 13.04, dated Jul 31, 1995, thru 13.149======
Change 13.149 Support for Kodak's ACXIS software for Kodak Optical Disk
ADOCAXC (by Data/Ware Development), Version 2.1.0, thanks to this
EXAXC01X significant user contribution creates ten new datasets.
EXAXC02X AXC01X - AXCIS DATA CREATION SUBTYPE 01X'
EXAXC02I AXC02X - AXCIS INDEX EXTRACTION SUBTYPE 02X'
EXAXC03X AXC02XIS - AXCIS INDEX EXTRACTION SEGMENT XIS'
EXAXC04X AXC03X - AXCIS LOCAL INDEX UPDATE SUBTYPE 03X'
EXAXC05X AXC04X - AXCIS GLOBAL INDEX UPDATE SUBTYPE 04X'
EXAXC06X AXC05X - AXCIS ARCHIVAL SUBTYPE 05X'
EXAXC07X AXC06X - AXCIS USER STATISTICS SUBTYPE 06X'
EXAXC08X AXC07X - AXCIS RETRIEVAL ACTIVITY SUBTYPE 07X'
EXAXC09X AXC08X - AXCIS FAILED RETRIEVAL ACT. SUBTYPE 08X'
IMACAXC AXC09X - AXCIS UNAUTH. ACCESS ATTEMPT SUBTYPE 09X'
TYPEAXC
VMACAXC
Jul 30, 1995
Thanks to Stephen Bell, Westfalisch Lippischen Sparkassen, GERMANY.
Change 13.148 I have never actually published standards for MXG code.
VMACXXXX Many users have contributed code that works, but I often
Jul 30, 1995 have to spend some time revising their code to my format,
because I have never formalized exactly how to write MXG
code. Member VMACXXXX and the other ....XXXX members are
good examples of the basic code structure, but I will now
begin to include specific coding standards that I try to
us, some cosmetic, some functional, for now in VMACXXXX,
but likely to be moved to a different-named member in a
subsequent iteration.
Change 13.147 Support for LEGENT's HyperBuf SMF Record adds new dataset
FORMATS TYPEHBUF, thanks to this user contribution. The original
EXTYHBUF code was tested with Beta Release 4.02 of HyperBuf,
IMACHBUF although I changed some of the code (see change 13.148)
TYPEHBUF and only syntax checked afterwards, as the test data file
VMACHBUF had not yet arrived for validation.
Jul 30, 1995
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 13.146 Five variables in NDM Connect Direct NDMMC dataset
VMACNDM (NDMTNAME,NDMFNAME,NDMANAME,NDMNRECS,NEMNBLKS) and four
Jul 30, 1995 variables in NDMWO (NDMTNAME,NDMFNAME,NDMANAME,NDMTSKNO)
were wrong because NDMUID was expanded from 8 to 64 bytes
in these records. The MXG test:
(NDMRTYPE='MC' AND LENGTH=168) must be changed to read
(NDMRTYPE='MC' AND (LENGTH=168 OR LENGTH=214)) to fix.
In addition, the actual change now inputs and keeps new
variable NDMWODAT, the undocumented text string at the
end of the WO record. (I suspect my DSECTS are old!).
Thanks to ???, Alcatel, FRANCE.
Change 13.145 Support for Packet/Main SMF record creates 11 datasets
EXPKMNBI thanks to this significant user contribution:
EXPKMNBL PKMNCONN - Connect to TIC
EXPKMNCO PKMNDISC - Disconnect from Packet Network
EXPKMNDI PKMNBIND - Bind Completed
EXPKMNER PKMNUNBN - Unbind processed for user
EXPKMNFE PKMNERR - Error Events
EXPKMNFL PKMNSTUP - Startup of PKTMN Program
EXPKMNFS PKMNSHUT - Shutdown of PKTMN Program
EXPKMNSH PKMNBLOG - Bind Image Log (for Session Data Logging)
EXPKMNST PKMNFLOG - Outbound FMD Logical Message (for ")
EXPKMNUN PKMNFTST - File Transfer Start
IMACPKMN PKMNFTEN - File Transfer End
TYPEPKMN The first five datasets have been validated with data.
VMACPKMN
Jul 29, 1995
Thanks to Mr. Loewenthal, Zonussi Elettrodomestici, ITALY.
Change 13.144 Support for NetCompress SMF record creates six datasets,
DIFFNTCP thanks to this significant user contribution:
EXNTCPAP NTCPINAP - Application Interval - type 03
EXNTCPOP NTCPINSY - System Interval - type 02
EXNTCPRT NTCPSESS - Device Session Start - type 05
EXNTCPSE NTCPSESE - Device Session End - type 06
EXNTCPSS NTCPSTRT - System Startup - type 01
EXNTCPSY NTCPSTOP - System Stop - type 04
EXNTCPOP Since the NTCPINSY dataset contains accumulated fields,
IMACNTCP member DIFFNTCP is automatically included in TYPENTCP,
TYPENTCP Note if you tailor BUILDPDB to add NTCP processing, you
VMACNTCP must also add %INCLUDE SOURCLIB(DIFFNTCP) in EXPDBOUT.
Jul 29, 1995 However, since the documentation does not describe which
fields are in fact accumulated versus end point values,
I had to deduce from the test data which fields to DIF(),
so please validate closely that I got them all!
Thanks to Mr. Loewenthal, Zonussi Elettrodomestici, ITALY.
Change 13.143 TSO/MON 6.1 only, variables TRIVTM NTRIVTM and LONGTM are
VMACTSOM were 38400 times too small; replace the three TU4. with
Jul 29, 1995 &PIB.4. and the values will be correct. (When I validated
the 6.1 changes last fall with test data, I only looked
the counts of transactions, and failed to perform a
reasonableness check on the response time values.)
Thanks to Yingha Mui, Canada Life, CANADA.
Change 13.142 Variables LCSLCBR and LETHCBR were misspelled as the 2nd
VMAC28 occurrence of LSCLCBS and LETHCBS, and the second label
Jul 28, 1995 for LCSLXBYT was deleted.
Change 13.141 Cosmetic changes. Duplicate variable names occurred in
VMACHPUX KEEP= statements, causing no error, but as they really
VMACIAM serve only to confuse, the duplications were removed.
VMACOMCI The MEMBER(VARIABLE) that were changed in each member:
VMACXAM VMACHPUX(EXPORTIM), VMACIAM(IAMAVGRL), VMACOMCI(EAMAXT),
VMAC110 VMACXAM(SLORESP1,SLORESP2), VMAC110(LDGDPSCR),
VMAC7072 VMAC7072(CPUWAITD,CPUWAITE,CPUWAITF), VMAC99(PHSPS).
Jul 27, 1995 (Freddie's diagnostic program, which reads MXG source to
look for inconsistencies, found these duplications.)
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.140 DFSORT Release 13 only. Variable ICEINPDS was repeated
VMAC16 four times in the KEEP=, the LABEL, and the INPUT
Jul 27, 1995 statements. The 2nd thru 4th occurrences of ICEINPDS
should have been ICEINNDS, ICEOUTDS and ICEOFLDS.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.139 Almost cosmetic; MXG previously kept only the first 9
DIFFDB2 IFCs and Destinations in DB2STAT0, and printed a message
VMACDB2 ("This is not usually important") if additional segments
Jul 27, 1995 were found in your record. Since this caused a few calls
I elected to increase the kept IFCs and Destinations to
14, since that appears to be the default count. These
counts of activity by IFC and Destination are rarely
needed, but now they exist. See Change 12.279.
Change 13.138 Using TYPEMON8 to process Landmark TMON/CICS Version 1.3
TYPEMON8 will cause the "IT APPEARS YOU ARE TRYING TO PROCESS ..."
Jul 26, 1995 message about decompression exit. That text now reminds
you that TYPETMON is required for Version 1.3 records.
Thanks to Jerry Boggess, County of Sacramento, USA.
Change 13.137 The MICS VM Data Transmission Program's VB output file is
VMACVMXA already supported in MXG VM/ESA member VMACVMXA, by using
Jul 26, 1995 the _VMINPUT macro instead of the _MWINPUT macro.
Only comments were changed by this Change.
Thanks to Ian Davies, Workers' Compensation Board of Alberta, CANADA.
Change 13.136 Variables HMF5BUS and HMF5TIME were not in the KEEP= list
VMACHMF for dataset TYPEHMF5, and they were also left out of the
Jul 26, 1995 LABEL statement in change 13.038.
Thanks to Shaheen Pervaiz, Acxiom CDC Inc, USA.
Change 13.135 This revision to the MXG Tape Mount and Tape Allocation
ASMTAPES monitor provides SRB reliability enhancements and adds
VMACTMNT new diagnostics. This is MAINTLEV 4 of the monitor and
Jul 25, 1995 should resolve several erratic problems with the SRB
Jul 29, 1995 routine (including, possibly, the occasional stall where
the monitor stops writing SMF records). This revision
creates a separate mount record for PROGRAM=IEFIIC, which
is now known to be the program name seen when a job step
is delayed in allocation recovery, and I intend to see if
there is any way to match up this IEFIIC record to its
related job, but I have to get the monitor into test site
hands to create the test data to examine first! Because
these PROGRAM=IEFIIC records represent allocation rather
than mount delays, I chose to delete them in VMACTMNT so
your statistics will not be affected. Sites wishing to
examine these records can remove that test from VMACTMNT.
Thanks to Tom Parker, Hogan Systems, USA.
Thanks to Jim Purdie, BancOne, USA.
Thanks to David Childers, Lowe's, USA.
Thanks to Shaheen Pervaiz, TransUnion, USA.
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 13.134 Date/time selection failed, especially crossing midnight.
ANALRMFR Find and delete each of the 44 lines containing either
Jul 24, 1995 IF TIMEPART("&BEGTIME"DT) LE TIMEPART(STARTIME);
or
IF TIMEPART("&ENDTIME"DT) GE TIMEPART(STARTIME);
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.133 Candle's Supersession Release 147 causes MXG message that
VMACNAF "More account fields were encountered ..." is corrected
Jul 24, 1995 by Candle PTF QLV1372.
Thanks to Mr. Schott, Rehau AGu. Co., GERMANY.
Change 13.132 Variable DURATM was neither calculated nor kept in the
VMAC28 NPMVSVGB data set; it was added to the KEEP= list and
Jul 24, 1995 created in the 'VGB' segment processing.
Thanks to Carl Sommer, SAS Institute Cary, USA.
Change 13.131 Several corrections to HSM FSR SMF record processing:
VMACHSM -Variable FSRTBYTW was mis-calculated. It should be:
Jul 24, 1995 FSRTBYTW=SUM(FSRTBYBK,FSRTBYTW);
-The DO I=1 to FSRNENT1 loop should have included all of
the SUM functions and the FSRTVOLS logic, with the
%INCLUDE SOURCLIB(EXHSMFST) and END relocated to just
before the DO on FSRNENT2. Before this change, MXG only
output the counts for the last tape when this FSR had
multiple tapes, and always had TPTYPE='INPUT'.
-Variable FSRTVOLS was added to LENGTH statement as $30.
Thanks to Wanda Prather, Johns Hopkins University APL, USA.
Change 13.130 Internet addresses FTPCLHST FTPCRHST F20LHST and F20RHST
VMACILKA were numeric variables in hex; with this change they are
Jul 24, 1995 character variables of length 15 with numbers and decimal
points between them. Inputting each of the four bytes as
individually using PIB1. and then concatenate the PUT
function of each byte, using:
ADDR=PUT(B1,3.)!!'.'!!PUT(B2,3.)!!'.'!!PUT(B3,3.)!!'.'
PUT(B4,3.));
Note added Aug 1996: Data from before and after this
change cannot be combined, as these four variables are
numeric before and character after. If you must combine
(i.e., year to date), then you must convert these four
variables in your existing accumulation from numeric to
character, using this logic:
MACRO _CONVERT
B1=FLOOR(X/65536);
B2=FLOOR((X-B1*65536)/4096);
B3=FLOOR((X-B1*65536-B2*4096)/256);
B4=MOD(X,256);
ADDR=PUT(B1,3.)!!'.'!!PUT(B2,3.)!!'.'!!PUT(B3,3.)!!'.'
PUT(B4,3.));
%
DATA NEWACCUM; SET OLDACCUM;
DROP FTPCLHST FTPCRHST F20LHST F20RHST;
X=FTPCLHST; _CONVERT; XTPCLHST=ADDR;
X=FTPCRHST; _CONVERT; XTPCRHST=ADDR;
X=F20LHST; _CONVERT; X20LHST =ADDR;
X=F20RHST; _CONVERT; X20RHST =ADDR;
DATA OLDACCUM; SET NEWACCUM;
DROP XTPCLHST XTPCRHST X20LHST X20RHST;
FTPCLHST=XTPCLHST;
FTPCRHST=XTPCRHST;
F20LHST =X20LHST ;
F20RHST =X20RHST ;
Thanks to Mohammad Mourad, AT&T, USA.
Change 13.129 DB2 Statistics Report again, but only individual fields!
ANALDB2R -PMSTA01/PMSTA02 labels for Buffer Pools BP0 and BP1 for
DIFFDB2 GENERAL and READ ACTIVITY were printed as BP1 and BP2.
VMACDB2 In ANALDB2R find GENERAL and make the following change,
Jul 24, 1995 and then find READ ACTIVITY and make the same change:
Jul 25, 1995 %IF &B EQ 1 %OR &B EQ 2 %THEN %DO;
Jul 26, 1995 @1 "BP&B GENERAL "
Jul 27, 1995 %END;
must be replaced with:
%IF &B EQ 1 %THEN %DO;
@1 "BP0 GENERAL "
%END;
%ELSE %IF &B EQ 2 %THEN %DO;
@1 "BP1 GENERAL "
%END;
-The LOG RBA field is printed as a decimal when it is a
hex address, and must be stored as length 8.
In ANALDB2R, find this line with QWSDLR and add HEX12.:
+2 'LOG RBA :' QWSDLR HEX12. ;
In VMACDB2 add variable QWSDLR to the LENGTH statement
to make it length 8 instead of the default length of 4,
and add a line QWSDLR HEX12. to the FORMAT statement.
(I chose HEX12 for an 8-byte field because RBA is a 24bit
address, and because HEX16 produces wrong values - see
SAS Technical Note).
In DIFFDB2, remove the line QWSDLR=DIF(QWSDLR);
-The second of the two lines with this label is wrong:
DBD REQUESTS NOT IN EDM
Change that 2nd label to DBD REQUESTS/DBD NOT IN EDM
The original calculation was always correct.
-The value for REQUESTS FOR PT SECTIONS in the Statistics
summary is incorrect. Find the line reading
+3 'REQUESTS FOR PT SECTIONS '
and change the next line to QISEKTG instead of QISEKT.
Now, find the previous SUM= statement and add QISEKTG.
-Statistics Detail report, page 4, right half of page
(AUTHORIZATION ATTEMPTS thru LOOK AHEAD MOUNT SUCCEED):
The /MINUTE /THREAD /COMMIT columns contain wrong values
(the left hand COL1xxxx variables are printed instead of
the right hand COL2xxxx variables). You must find each
of the report labels for the right hand column, and for
those that are followed by lines with COL1PMIN COL1PTHD.
and COL1PCOM, change the COL1xxxx to COL2xxxx. Twenty-one
sets of three lines were changed.
-Statistics Detail report, page 6, right half of page,
(GET PAGES thru RANDOM GET PAGE RESULTS), same error as
page 4 - file labels and change COL1xxxx to COL2xxxx.
Thanks to Neil Ervin, Huntington Service Company, USA.
Thanks to Cal Cooke, Huntington Service Company, USA.
Thanks to Dean Berry, Farmland Industries, Inc, USA.
Change 13.128 Support for APAR OW13246 (PSF/MVS Release 2.2.0) adds new
VMAC6 variables SMF6BYTE (bytes transmitted) & SMF6TARG (target
Jul 23, 1995 address) to dataset TYPE6, for sites exploiting the new
PSF/MVS Download feature. Note that these new variables
are not automatically carried into the PDB.PRINT dataset
with BUILDPDB, but you can tailor IMACPDB easily to add
them if you need them.
Change 13.127 This change is for documentation of an incompatibility
FORMATS with SAS Version 5; there was no actual change. Beginning
Jul 23, 1995 with MXG 13.01, member FORMATS cannot be executed under
SAS version 5 or SAS version 6.06, nor can it be executed
if the output LIBRARY is a version 5 format library. The
syntax OTHER=(| $HEX2. |) added by Change 13.061 did not
exist in those archaic versions of SAS. However, if you
delete all of the lines in member FORMATS with that
OTHER= syntax, the formats program will execute without
error, even on those old versions.
Change 13.126 This change was revised after Newsletter 28 was printed.
VMACVMXA VM/ESA MONWRITE records written both by Sterling's
Jul 23, 1995 VM/Monitor and by IBMs MONWRITE have changed in VM/ESA
Jul 24, 1995 2.2. MXG calculated the number of control records using
Aug 22, 1995 NRCRRECS=(IPRMMSG2-IPRMMSG2+1)/12; (even though there is
only one control record per block), and verified that the
record was a control record by testing IPARMLF1=8709x,
but the IPARML control block has changed. Sterling writes
records with IPRMMSG1=IPRMMSG2=028x that have MWTCAREA of
all zeroes (so this is not a valid control record, altho
028x is the correct offset to where MWTCAREA should be!),
and IBM writes records with MSG1=MSG2=3Fx that do contain
a valid MWTCAREA, but 3Fx is the wrong offset to it!
(These heuristics were needed in early VM/XA records, but
now that the IPARML has changed, they can and must be
removed with these changes:
-The block IF MOD(IPARMLF1,10000X) NE 8709 ... to END;
was deleted.
-The calculation NRCRRECS=(IPRMMSG2-IPRMMSG1+1)/12; and
the following INPUT @IPRMMSG1+1 @; was replaced with:
NRCRRECS=1;
INPUT @41 @;
(the code added by the July change, between these two
lines was also deleted by this August change).
-After the @; after CAEND is input, insert this code:
IF CASTR=0 AND CAEND=0 THEN DO;
NRCRRECS=0;
DELETE;
END;
With these changes, MXG now skips over the MWTEXTBF area
that contains the IPARML control block, and instead reads
the MWTCAREA directly to determine how much data (if any)
follows this control record.
Thanks to Ian Davies, Workers' Compensation Board of Alberta, CANADA.
Thanks to Connie Mak, Avon, USA.
Change 13.125 Landmark TMON for MVS corrections. The line reading:
VMACTMVS IF JDSTCBS GT 10000 THEN DO;PUT _N_= COL=;LIST;STOP;END;
Jul 23, 1995 was deleted. That debugging code for a bad record (over
Aug 21, 1995 10,000 TCBs in real memory) caused the MXG job to stop
before the end of the input file, and there was no error
message nor condition code set by MXG; the only clue was
a single record hex dump printed on the SAS log.
Variables STARTIME and DURATM were removed from the KEEP=
list for dataset TMVSCC (which is an event record, not an
interval), and SYSTEM=CCCSMFID; was inserted before the
%%INCLUDE SOURCLIB(EXTMVCC);
to correct the blank value for SYSTEM in that dataset.
Also, variable CFIUTYPE was changed from numeric to
character and formatted $HEX8, to be consistent with the
other occurrences of unit type in other TMVS records. I
recognize this may cause a problem if you combine TMVSCF
data sets built before and after this change.
Thanks to Rod Fernandes, Albert Heijn B.B., BELGIUM.
Change 13.124 RMM SMF Record caused INVALID DATA FOR MDUCDATE/MDUCTIME
VMACEDGS if there had been no user change because the PD4 fields
Jul 21, 1995 were nulls. Insert ?? between the variable name and
the &PDB.4. format name in the two lines which input the
variables MDUCDATE and MDUCTIME.
Thanks to Bob Newbury, University College System of Nevada, USA.
Change 13.123 Variables B1DIS B1INT CPGM LPGM ROBID ROBTY and SMSMC are
TYPETMS5 added to the output datasets created by TYPETMS5; these
Jul 21, 1995 variables (new in TMS Release 5.1) were added to VMACTMS
by Change 13.083, but were not carried into the datasets
created by the TYPETMS5 processing.
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.122 Variable RACFUSER from type 30 was added to the DSETOPEN
ANALDSET and DSETSUMS datasets created from 14/15/64 records so
Jul 21, 1995 that Auditors can know the submittor of the job that did
the access to the file.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.121 Reading your 3990 Mod 11 Fat DASD with SAS INFILE CVAF
VMXGVTOC option will fail, because the DSCB 5 2-byte addresses are
Jul 19, 1995 3-bytes for those devices. Removing the CVAF option will
circumvent the SAS error, because MXG does not need the
DSCB 5 records to constuct the VTOC datasets. However,
far better than using this old VMXGVTOC technology, the
ASMVTOC/VMGXVTOF pair have been the recommended VTOC tool
in MXG for years. If you now have DFSMS, using their
DCOLLECT is even better, since it includes the VSAM and
VVDS data that previously required you to also run the
ASMVVDS/TYPEVVDS pair. I have removed the CVAF option
from the INFILE statement to prevent this error, should
anyone still be using VMXGVTOC and not read this note.
April 20, 2006 Notes:
1. Member JCLDAYDS and DAILYDSN are the members to
use to capture/bill-for disk space and tapes.
2. SAS Note SN-015522 for SAS Version 9.1.3 does
now recommend specifying the CVAF option in the
INFILE statement to circumvent an 0C4 ABEND in
module UNKNOWN function VXVTC at offset 00082C.
Thanks to Terry Poole, SAS Institute Cary, USA.
========MXG Version 13.03, dated Jul 19, 1995, thru 13.120======
Change 13.120 Support for Boole & Babbage's HiperCache 4.1.1 and 4.1.3,
VMACHIPR (INCOMPATIBLE, because data was inserted into the fixed
Jul 18, 1995 portion of the record and LSR segments were expanded).
The JCTJOBID,INITTIME and READTIME were added to the VSAM
record, and LSR subpool information added new variables
SMFnnHSB,HSR,HSW,HFR,HFW,MFH,MTH,FFH, and FTH for buffers
in hiperspace, and successful/failing reads/writes
and move-pages to/from hiperspace.
Thanks to Dave Myers, Time Warner Cable, USA.
Change 13.119 XMXGSUM update. This new enhanced replacement for VMXGSUM
XMXGSUM was ready to go, until I ran TESTANAL and discovered that
Jul 18, 1995 repetitive invocations of the new logic caused strange
errors (Unable to Load IMAGE SASQUIL, Unable to Open
File) due to memory problems. Increasing the REGION= to
48M eliminated the errors, but until I examine why there
is an increase, it is not safe to replace VMXGSUM yet.
But because you are wise enough to read this text, and
can be prepared to increase region size to save lots of
CPU, time, and DASD space, I strongly recommend you use
the new XMXGSUM (see comments therein) for summary of the
large datasets (CICSTRAN, DB2ACCT in particular).
Change 13.118 -DB2 Statistics Detail and Long Trace reports had EDM pool
ANALDB2R variables that were non-zero for never-happened, and some
ADOCDB2 totals were printed instead of averages. One logic error
Jul 18, 1995 (repeated variables in SUM= list) was not caught because
the test suite uses the new XMXGSUM replacement for
VMXGSUM, and one of the many enhancements in the XMXGSUM
replacement is that it weeds out any duplicates! Using
XMXGSUM will correct some of the report values, but not
all, so you will still need to install the new ANALDB2R.
-Audit reports show FORMAT $DB2OBID NOT FOUND, even though
the log shows they were created. I think the error is an
out of memory condition while loading this very large
format, but there is no clue on the log!
But the real culprit is the creation of the TEMPDBID and
TEMPOBID datasets that are used as CNTLIN= for PROC
FORMAT. The early logic to map DBID/OBIDs output one
value for each T102S105/T102S107 obs, (open), but a new
value is needed only if the mapping changed, so the logic
now outputs one value for each unique mapping. The
500,000 obs in TEMDBDID dropped to 2,000 and the memory
problem disappeared.
Increasing MEMSIZE and REGION may circumvent, but 72MB
was not enough with 500,000 obs in TEMPOBID dataset
that is used as CNTLIN= for PROC FORMAT.
-ADOCDB2 was updated with an IBM note on why SRB CPU time
in DB2ACCT is invalid for CICS attachment and for DDF.
-PMSQL01 trace was rewritten as a series of sorts and one
monster data step using SET and a BY statement to save
DASD space. Major reduction in DASD space with this
revisions (200 cyl now, 3000 cyl not enough before!).
Time selection is only at the report level for SQL01;
all data still must be read and processed (hence put on
temporary DASD). We are reviewing alternatives for the
next version, but this change makes SQL trace feasible
even with 500,000 trace events in only 200 cylinders of
WORK space (previous version failed to complete with an
entire 3000 cyl volume!). You can always use IMACFILE
to select SMFTIME of interest with PDB=SMF execution
until we have time to address this enhancement to SQL01.
Thanks to Phil Schwartz, Pershing, USA.
Thanks to Dean Berry, Farmland Industries, USA.
Thanks to ???, Schweizerische Bankgesellshaft, SWITZERLAND.
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 13.117 Variables were not kept because they were misspelled in
VMACCADM the KEEP= list. Variables STFKUS18 STIVSR10 STIVSR16
Jul 15, 1995 STIVSR22 STIVSR28 and STIVSR34 replace their misspelling.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.116 Landmark converted History Records with invalid data for
TYPEMON8 MRO segment cause "INVALID OFFSETS IN USER SEGMENTS".
Jul 15, 1995 The record is defective, and Landmark is investigating
their error, but MXG, by default, DELETEs the record so
there is no observation output. To circumvent, insert
MROCOL=0; MRONUM=0; after MROCOUNT=0; so that the MRO
logic will not be executed. This will cause zero obs in
the dataset MONIMRO, and variables MROTIME,MROCOUNT will
always be zero in dataset MONITASK, but dataset MONITASK
will contain valid observations. This circumvention will
NOT be installed in MXG software; it is printed here only
for user modification until Landmark fixes their error.
Thanks to Warren Tanaka, Farmers Insurance Group, USA.
Thanks to Bill Padilla, Farmers Insurance Group, USA.
Change 13.115 TYPE42 variables AVGCONMS AVGDISMS AVGPNDMS had format
ADOC74 TIME13.3, but those MS PER SSCH variables should be 5.1
VMAC42 (so that 12.1 milliseconds prints as 12.1 instead of
VMAC74 0:00:12.100!). If BUILDPDB includes type 42 records,
VMACVMXA the TYPE74 variables will also have wrong format. The
Jul 12, 1995 -VMAC42. Move AVGCONMS AVGDISMS AVGPNDMS from TIME13.3 to
5.1 format in VMAC42, labels were made consistent.
-VMAC74. Labels were made consistent.
-ADOC74. Variable AVGENQMS noted as always missing in XA.
-VMACVMXA. Labels were made consistent.
-VMAC74. Also, variables AVGPNDIR PCTPNCHA PCTPNDIR were
added to 5.1 format.
Thanks to Tim Carne, Nottinghamshire County Council, ENGLAND.
Change 13.114 Variable TPXSNAME (Session Name) was always blank. Change
VMACTPX IF SKIP GT 8 THEN DO; to IF SKIP GE 8 THEN DO;
Jul 12, 1995 TPXSNAME only exists in dataset TPXAPLON.
Thanks to Jim Tintle, Mack Trucks, Inc, USA.
Change 13.113 MXG 13.01-13.02B only. CICS Shutdown report may cause
ANALCISH NOTSORTED error.
Jul 12, 1995 -Move %REPORTS statement to before %IF &REQ_REP GT 0 ....
-Find the %VMXGSUM invocation with INDATA=CICTM. Change
NOSORT=YES to NOSORT=NO in that invocation. Remove the
statements PROC SORT DATA=&MXGDS OUT=&MXGDS %VMXGFOR;
BY &BYLIST; %LET BYLIST=SYSTEM APPLID;
that immediately precedeed that %VMXGSUM invocation.
Thanks to Chris Weston, SAS Institute, ENGLAND.
Change 13.112 ACF2 subtype "L" (dataset ACF2JR) logic was redesigned.
VMACACF2 The old logic created one before ARE obs and two after
Jul 12, 1995 ARE obs, even when there were multiple ARE segments, and
the LID was decoded but not output. The redesign creates
new dataset ACF2JRL to contain the LID fields (and the
identity of the changer), one obs in ACF2JRL for each "L"
record, and dataset ACF2JR now has one obs for each ARE
entry (either before or after) with the ARE field name
and field value and the identity of the changer.
While I expected a Before and an After ARE for each
field that was changed, that's not exactly what ACF2
writes out. For fields that are bit switches, those
fields only show up in an ARE when their value is 1.
Turning a bit switch on has no Before ARE but has an
After ARE. Switching a bit switch off has a Before ARE
with no After ARE entry, so Before/After AREs cannot
be paired, but ACF2JR dataset has all the information.
Thanks to Normand Poitras, Banque Nationale du Canada, CANADA.
========MXG Version 13.02B, dated Jul 6, 1995, thru 13.111======
Change 13.111 Several variables were not kept due to spelling errors,
IMACHURN macro _KHRN527 was misspelled in IMACHURN, and datetime
VMACHURN variables were not stored as LENGTH 8.
Jul 6, 1995
Change 13.110 MXG Position Paper on support for the Year2000. MXG now
YEAR2000 supports dates after 1999, but many data records from
Jul 6, 1995 many products do not. This paper identifies which fields
in which record from which vendor do not have field width
to support Year2000, and which fields must be validated
by vendors that, while wide enough, do in fact support
the Year2000. This member will be updated as vendors
make changes and verify their date formats.
Change 13.109 Only comments were changed, but a new example of how to
IMACFILE select CICS type 110 records by APPLID or SUBTYPE was
Jul 6, 1995 coded and added as a comment block.
Change 13.108 HSM dataset DGN only processed first dump copy when more
VMXGHSM than one copies were created at the same time; copies
Jul 6, 1995 will have same start date/time and source volume in the
base, but dump copies will have different dump class name
and tape volser, and may have different output units and
device types. Additionally, this correction adds vars
hh0 mm0 ss0 and tt0 to the keep= list (so that the MCDS
key can be reconstructed).
Thanks to Wanda Prather, Johns Hopkins Applied Physics Lab, USA.
Change 13.107 Temporary datasets used in these members were kept when
ANALCNCR they should have been deleted at the end of processing.
ANALINIT This is mostly cosmetic (some of these datasets ended up
ANALTAPE being documented in member DOCVER!) but it is MXG's
TRNDTALO intention to not leave datasets in the //WORK library.
Jul 5, 1995
Change 13.106 DB2 Reporting was still wrong in 13.02A. The Statistics
ANALDB2R Reports produced replicated pages and wrong totals, due
Jul 5, 1995 to a mislocated block of code (introduced in MXG 12.12).
Also, MXG 13.01 introduced a FORMAT NOT FOUND error for
DB2DBID or DB2OBID format in Audit Reports if there were
no IFCID=105/107 observations found; the Audit report was
enhanced to print the tablespace name instead of the hex
OBID/DBID value, but the Audit report logic did not tell
you that you needed the 105/107s to create the format!
Now, we will use 105/107s if found, but will not fail if
they do not exist. (However, our Format building logic
may require REGION=48M and MEMSIZE=48M in your CONFIG
member in this version, due to duplicate entries - we
know how to fix but not in time for MXG 13.02B.)
Finally, the SQL trace report can take a lot of DASD
space, and we are re-designing that report for better
execution performance in the next version, and we will
update the instructions in comments in ANALDB2R for the
IFCIDs needed/used in various reports.
Thanks to Dean Berry, Farmland Industries, USA
Thanks to Neil Ervin, Huntington Service Company, USA.
Change 13.105 DCOLLECT with SMS 1.2 fails with INPUT STATEMENT EXCEEDED
VMACDCOL error, and prints a hex dump of a 260-byte record, if you
Jul 5, 1995 still have LRECL=264 specified in the JCL for DCOLLECT.
With SMS 1.2, the LRECL=644 must be specified for the
output of DCOLLECT (see Change 12.316, only in 12.12A),
but I did not cross-reference that change to this error.
Change 13.104 Variable GMTOFFTM was missing if LENPROD=60 (but this had
VMAC7072 no effect, as GMTOFFTM is not actually used in MXG, it is
Jun 29, 1995 only a kept variable in TYPE70). GMTOFFTM=GMTOFF70; was
inserted after GMTOFF70=GMTOFF70/4096;
Thanks to Don Friezen, B.C. Systems, CANADA.
Change 13.103 Support for 4-digit UCB addresses in Cache RMF Reporter.
VMACACHE Variables DEVN and DEVPLX need to be formatted HEX4..
Jun 29, 1995 Originally, I changed the input of @9 UNITADDR $EBCDIC3.
Jul 12, 1995 to @8 UNITADDR $EBCDIC4., hoping that IBM had the wisdom
to use that extra preceding byte for the UNITADDR, but
no joy, the byte @8 is still a reserved, hex 00 byte.
So UNITADDR in CACHE90 dataset is only 3 characters, and
you must use DEVN variable for the device number (the new
name for unit address). This note revised Jul 12, 1995.
Thanks to Rick Balint, Seattle First, USA.
Change 13.102 Support for AUTOMATE had some incorrect field lengths in
VMACAUTO the initial coding. Input of SMFA_SSN was changed from
Jun 29, 1995 $EBCDIC3. to $EBCDIC4., and SMFA_NAM from $EBCDIC3. to
$EBCDIC8. Also, SMFA_ST was added to DATETIME21.2 format
and SMFA_SSN was added to the KEEP= for all datasets.
Thanks to Rik van Roy, Procter & Gamble ETC, BELGIUM.
========MXG Version 13.02A, dated Jun 28, 1995, thru 13.101======
Change 13.101 VM CPU ID values of 'A01234'X were not supported by the
TYPEVM &PK.3. informat used in MXG, so the input was changed to
Jun 26, 1995 &PIB.3., and formatted HEX6. to support all hex valued
in the CPU ID field.
Thanks to Mr. Koeller, Sparkassen-Datendienst AG & Co. KG, GERMANY.
Change 13.100 MXG inputs DOS dates using MMDDYY8. format, because that
TYPEDOS is the way IBM writes them in the US. However, if your
Jun 26, 1995 site uses European format dates under your DOS, you will
have to change the three MMDDYY8's to DDMMYY8 because
there is no way to detect from the record.
Thanks to Mr. Koeller, Sparkassen-Datendienst AG & Co. KG, GERMANY.
Change 13.099 All nine occurrences of DATE &PD.4. were changed to
VMACFTP DATE ?? &PD.4. to suppress error message and hex dump
Jun 26, 1995 if invalid (or null) dates are found in the record.
Thanks to Mr. Koeller, Sparkassen-Datendienst AG & Co. KG, GERMANY.
Change 13.098 DB2 Accounting fields with repeated commas create SMF 101
VMACDB2 records with repeated 'FF'x values, causing MXG parsing
Jun 26, 1995 logic to fail, generating error messages on the log.
Replace all nine occurrences of IF LOC=0 THEN ...
with IF LOC LE 1 THEN ...
Thanks to Stephen Bell, Westfalisch Lippischen Sparkassen, GERMANY.
Change 13.097 Macro code which stripped blanks out of INDATA operand
XMXGSUM was removed; it was no longer needed (the XMXGSUM logic
Jun 26, 1995 now parses individual words of the INDATA string) and it
was found to consume significant CPU time.
Thanks to Mitch McKenna, SAS Institute Europe, GERMANY.
Change 13.096 DB2 Statistics Reports were corrupted in MXG 12.12 when
ANALDB2R support for DB2 3.1 was added (a block of code was mis-
Jun 26, 1995 located). See Change 13.106.
Thanks to Mitch McKenna, SAS Institute Europe, GERMANY.
=======Spoke at Greater Boston CMG meeting in Waltham, MA, 21Jun95======
Change 13.095 TYPE72 variable DOMAIN (SMF72CDN) has a value of '5c5c'x
VMAC7072 for Report Performance Group observations, because there
Jun 19, 1995 is no domain for RPGN's - it is the Control Performance
Group that measures resource consumption by Domain.
(My transaction in RPGN=99 could span several Domains as
work changes Periods in its Control Performance Group)
Thanks to Maurice Clark, ISSC Australia, AUSTRALIA.
Thanks to Chris Nibbs, ISSC Australia, AUSTRALIA.
========Initial MXG Version 13.02, dated Jun 19, 1995, thru 13.095======
Change 13.095A Variable DEVNR in type 42 datasets was not formatted,
VMAC42 causing device 0181x to print as 385! Add to FORMAT:
Jun 19, 1995 DEVNR HEX4.
Thanks to Mark Robbins, W. H. Smiths Limited, ENGLAND.
Change 13.094 Variable LUNAME was skipped in the 'E3'x record causing
VMACNAF other variables in dataset NAFLOGOF to be trashed. After
Jun 19, 1995 RTYPE='E3'X test, after NAFRLN $CHAR4. insert
LUNAME $EBCDIC8. (and add to the KEEP= list for dataset
NAFLOGOF).
Thanks to Mark Hayden, General Accident, SCOTLAND.
Change 13.093 Support for DFSORT Release 13 (INCOMPATIBLE) added many
EXTY16IN new variables to TYPE16, and three new datasets are now
EXTY16SO created with details on each file used:
EXTY16OU TYPE16IN - Input Data Sets (including concatenations)
IMAC16 TYPE16SO - SORTOUT Data Sets
VMAC16 TYPE16OU - OUTFIL Data Sets.
Jun 17, 1995 Note that DFSORT Release 13 comes with a boost that is
Nov 15, 1995 specifically designed to improve sorting of SAS datasets
(and at no additional cost!) - see the IBM announcement!
Change 13.092 Support for OPC Release 3.0 (INCOMPATIBLE). IBM added 12
IMACOPC new bytes for TRLLENGT in the header, inserted 16 bytes
VMACOPC for new field MT0CAL for dataset OPC24_1, and added new
Jun 17, 1995 MTDTYPE=15 for Step Restart (new MXG dataset OPC24D_J).
To process Release 3 records, you can make these changes
until you get the new MXG version:
-Insert after the @; that is after the INPUT of TRLFILL:
IF _OPCVER GE 3 THEN DO;
INPUT +12 @;
OFFSMF=OFFSMF+12;
END;
-Insert after the @; that is after the INPUT of MT0OTX:
IF _OPCVER GE 3 THEN INPUT +16 @;
-Update your IMACOPC to set macro _OPCVER to 3. I chose to
leave the default Release in IMACOPC unchanged at 2.
This code has been tested against only some OPC records;
there may be additional changes if other subtypes were
changed, and this text will change if necessary.
Thanks to Mr. Riccardi, AGIP Petroleum S.p.A., ITALY
Change 13.091 Support for Legent's AUTOMATE User SMF record creates 11
EXAUTOxx new datasets. Of course, now that the work is done, I
IMACAUTO discover it is Legent's intention to stabilize AUTOMATE
TYPEAUTO and replace it with OPS-MVS! In any event, there is a
VMACAUTO what looks to be useful information in these eleven data
Jun 16, 1995 datasets:
AUTOCICS CICS Statistics
AUTOCMDS CMD Statistics
AUTOIMS IMS Statistics
AUTOMISC Miscellaneous Statistics
AUTOMSGS MSG Statistics
AUTOOPNG OPEN Interface General Statistics
AUTOOPNS OPEN Interface Session Statistics
AUTOPORT Port Session Statistics
AUTORULE Rule Statistics
AUTOSQL SQL Statistics
AUTOVARS Subpool Statistics
Thanks to Rik van Roy, Procter & Gamble ETC, BELGIUM.
Change 13.090 A new exit, EXPDBSPU, taken upon entry to member SPUNJOBS
EXPDBSPU was added for the SAS/CPE product, which needs to rename
SPUNJOBS work datasets prior to SPUNJOBS invocation. I doubt that
Jun 16, 1995 anyone else will need to use this exit.
Change 13.089 All MXG datasets should contain variables SYSTEM, SMFTIME
TYPECIMS and for interval datasets DURATM and STARTIME, and have
VMACOMVT a dataset LABEL. These members revised for consistency:
VMACEPMV -TYPECIMS - LABEL added; dataset was labeled in VMACCIMS,
VMACORAC but I just learned that SAS does not propagate dataset
VMACTSOM LABELs when the dataset name is reused! DELETE of the
VMACMDF temporary datasets TRANSACT and CHAINED was also added.
Jun 16, 1995 -VMACOMVT - Variable DURATM added to datasets OMVTTBUF,
OMVTTVR,OMVTTCTC,OMVTTNCP,OMVTTLCL,OMVTTETE, calculated
as DURATM=ENDTIME-BEGNTIME.
-VMACEPMV - Variable SYSTEM added to all datasets.
-VMACORAC - Variables SMFTIME, SYSTEM added.
-VMACTSOM - DURATM added to TSOMCMND, DURATM STRTTIME and
SYSTEM added to TSOMDRU, SMFTIME added to TSOMDSNS.
-VMACMDF - DURATM added (note archaic MDFTRACK became the
APAF product, supported by TYPEAPAF), calculated as
DURATM=GBLENDTS-GBLBEGTS;
-VMAC78 - DURATM added to KEEP= for TYPE78PA & TYPE78SP.
Thanks to Carl E. Sommer, SAS Institute Cary, USA.
Change 13.088 Datasets TYPETALO, TYPE72SC, and TYPE78 were overlooked
BUILDPDB and were left in the //WORK file after their last use,
BUILDPD3 but are now deleted in the PROC DATASETS, like all of the
BUILD002 PDB work datasets, to minimize the work space required.
BUILD003
Jun 15, 1995
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 13.087 Continued enhancement to IBM-format RMF reports has added
ANALRMFR the Coupling Facility Usage Summary and Coupling Facility
Jun 15, 1995 Structure Activity; PDBOUT logic now builds all of
RMF type 7x datasets; Change 12.310 was added for a
non-partitioned machine.
Change 13.086 CICS Shutdown report failed if compressed datasets were
ANALCISH used, because POINT= cannot be used with compressed data.
Jun 15, 1995 We used POINT= only because NOBS= used to require POINT=,
but since SAS version 6, POINT is no longer required.
Unfortunately, though, without the POINT= operand, if the
SAS dataset is on tape or in tape format, NOBS=NOBS must
read the entire dataset to find NOBS. In this change, we
only needed to know if there were any observations, not
how many, so the problem was circumvented with different
logic, and compressed or uncompressed data worked fine.
7Nov02 update: Above text revised. See member VMXGOBS
to get the number of observations from
disk datasets.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.085 Support for Antares' HURON SMF record creates 44 new data
FORMATS sets from the 20 subtypes of this extensive product. The
EXHRNnnn support exists now thanks to the significant contribution
IMACHURN of Glenn Bowman, who wrote the bulk of this support. I
TYPEHURN reviewed the code and made some cosmetic revisions (new
VMACHURN formats to decode bit strings, PIBx changed to &PIB.x,
Jun 15, 1995 sorted Labels), and validated with SMF data from a second
site (which uncovered an optional data segment in subtype
26), so I am quite comfortable with this code. Huron, to
be renamed ObjectStar, is a complex product with complex
instrumentation, but the "Huron Guide to Performance
Monitoring" documents much of the data quite well, and
two "Focus on Huron Performance" documents, subtitled
"Tuning Guidelines for Huron for MVS", and "Resource
Monitoring and Usage" give excellent discussions of how
best to analyze Huron data.
Thanks to Glenn Bowman, Wakefern Food Corporation, USA.
Thanks to Christa Neven, Geoep Boerenbond, BELGIUM
Change 13.084 -Support for APAR OW10393 which added a four byte field,
VMAC32 trashing the values in dataset TYPE32. The old MXG code
Jun 15, 1995 in this member did not protect for compatible changes by
IBM! The circumvention is to insert:
IF LENTSO GE 44 THEN INPUT +4 @;
after the block that inputs IOTMTOTL.
The actual change created new flag variable SMF32TCF='Y'
if variable SRMTRANS was set to zero by IBM because the
OUCB control block was not valid. When set, SRMTRANS
remains no longer valid for the duration of the session.
-Support for APAR OW12856, which adds one field (SMF32COS,
number of sections in subsequent records) to the header,
and raises the number of TSO command names that can
be monitored from 812 to 32767 by now creating more than
one type 32 record if necessary. This had no impact on
MXG logic, since MXG creates one observation for each
session segment in each record.
Thanks to Luc Mattheus, GEMEENTEKREDIET VAN BELGIE, BELGIUM.
Change 13.083 Support for TMS (CA-1) Release 5.1 (compatibly) adds
EXTMSDSN new variables to both TMS.TMS and TMS.DSNBREC. Both now
EXTMSTMS have CPGM (Creating Program Name) and SMSMC (SMS Mgmt
IMACTMS5 Class Name). Dataset TMS.TMS has new variables LPGM
VMACTMS5 (Last Used Program Name), ROBTY/ROBID Robotic flags,and
Jun 13, 1995 B1INT/B1DIS (B1 Security Integrity/Disclosure labels).
In addition, this revision added the "_L, _K" tailoring
macros in member IMACTMS5 (See Change 10.175), and the
EXTMSxxx Exit Members so TMS is now consistent with other
MXG processing members. These additions should be
transparent, and are needed only if you want to tailor
the contents of the TMS datasets.
Thanks to Lonnie Melamed, SHL, CANADA.
Change 13.082 DB2 3.1 only. No Statistics Reports, DB2STATS has zero
DIFFDB2 observations. The MXG logic demanded there be data in
Jun 13, 1995 DB2STAT0,DB2STAT1, and DB2STAT2 to OUTPUT to DB2STATS,
but DB2STAT2 only has observations if your DB2 uses the
new Hiperpools! The logic was changed from:
IF (QWHSRELN LT 2.9 AND IN0 AND IN1)
OR (IN0 AND IN1 AND IN2);
to:
IF IN0 AND IN1;
so that DB2STATS is created whether or not there are obs
in DB2STAT2.
I'm awaiting doc of a case where non-zero obs in DB2STATS
becomes zero obs in DB2TEMP2.
Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.
Change 13.081 ANALBLSR uses the EXCPDASD variable created by ANALDSET,
ANALDSET but ANALDSET did not sum the MULTIDD='Y' observations in
Jun 13, 1995 the STEPS dataset, so some calculations in ANALBLSR were
greater than 100%! A new data step was added to ANALDSET
to sum EXCPDASD, and also to output only one observation
per step. Insert after PROC SORT DATA=TYPE30.TYPE30_4...
DATA SORTSTEP.SORTSTEP;
SET SORTSTEP.SORTSTEP;
BY SYSTEM READTIME JOB SORTTIME;
DROP TOT_EXCP;
IF FIRST.JOB THEN TOT_EXCP=0;
TOT_EXCP+EXCPDASD;
IF LAST.SORTTIME THEN DO;
EXCPDASD=TOT_EXCP;
TOT_EXCP=0;
OUTPUT;
RETURN;
END;
A future MXG enhancement will provide a separate optional
routine that can be invoked during BUILDPDB or TYPE30
processing to sum all variables in the MULTIDD='Y'
observations into a single observation (applies to the
TYPE30_V, TYPE30_4, TYPE30_5, and TYPE30_6 datasets).
Thanks to Jerry Layne, Virginia Power, USA.
Change 13.080 Support for Sterling SAMS Storage Automation & Reporting
EXSAMSES System's user SMF record creates three new data sets:
EXSAMSTO SAMSTOT - Total pools, volumes, space avail and used
EXSAMSVO SAMSVOL - Per volume space stats, pool(s) of volume
IMACSAMS SAMSESOT - Per pool space statistics.
TYPESAMS SAMS Version 3.2.0 documentation/data was validated.
VMACSAMS
Jun 12, 1995
Thanks to Shaheen Pervaiz, Acxiom, USA.
Change 13.079 -DB2 Statistics Summary PMSTA01 was wrong or not printed,
ANALDB2R especially if INTERVAL=SHIFT was specified; this error is
Jun 12, 1995 fixable as described below.
-Only the first 60 bytes of the SQL text was printed in
the Audit reports; too many lines were changed to print
the change here.
-The PMSTA01 error can be corrected with:
Find the %VMXGSUM(INVOKEBY=PMSTA01 - ANALDB2R) segment.
- Change the argument KEEPIN=MINTIME MAXTIME,
to read KEEPIN=MINTIME MAXTIME STRTTIME,
- After the argument SUMBY= change
OR &PMSTA01 NE YES %THEN BEGTIME; to read
OR &PMSTA01 NE YES %THEN STRTTIME;
-Find the first COMMITS = SUM(Q3STCOMM, ....
then change the previous DURATM=ENDTIME-BEGTIME;
to read DURATM=ENDTIME-STRTTIME;
Thanks to Joe Richard, MBNA, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Mitch McKenna, SAS Institute Europe, GERMANY.
Thanks to Victor Chacon, NYNEX Mobile Communications Co., USA.
Change 13.078 Disregard this change. It was reported that Change
VMAC110 12.324 causes SAP 5.0.c to get INVALID DATA FOR HH MM,
Jun 12, 1995 but &PK fields can't have invalid values! The problem
turned out to be a user problem, and there was no change.
Change 13.077 SAP Variable STCTIMTR bad. Because of MXG Change 12.324,
IMACICSA MXG 12.12A and MXG 13.01 and later expect SAP 5.0 data,
Jun 12, 1995 while MXG 12.12 and earlier expect pre SAP 4.3F records.
(SAP 4.3F changed STCTIMTR, 4.3J split STCFLAG/STCTASK.)
You will have to EDIT IMACICSA and verify (or change) the
INPUT of STCTIMTR (Start time) to match your SAP release:
pre-4.3F: STCTIMTR PDTIME4.
4.3F,4.3J,5.0: STCTIMTR &PIB.4.3
MXG Change 12.324 changed the INPUT of STCTIMTR from
PDTIME4 to PIB4.3 in member IMACICSA, thinking it was an
error, but it was a change between SAP 4.3J and SAP 5.0.
Unfortunately, it does not appear there is any way to
detect which version of SAP wrote the record, so you must
manually update MXG to tell me what you have!
Thanks to Norbert Korsche, OMV, AUSTRIA.
Thanks to Ralf Menz, COMLAB, GERMANY.
Thanks to Jens Schlatter, EDP Consulting Schlatter, GERMANY.
Change 13.076 ANALALL selects and prints all SMF records from a job,
ANALALL but had not been recently updated for new job-related SMF
VMAC24 records. Member IMACJBCK, the "job checking" exit that
VMAC33 is used to select by JOB name, should have been included
VMAC36 by every job-related record processing, but had not been.
VMAC42 Several VMACs create multiple datasets from different
VMAC59 subtypes, but only some subtypes are job-related, so the
VMAC60 ANALALL logic now prevents creation of those unneeded
VMAC78 datasets. These SMF records processing VMACs were hit:
VMAC80 24,33,36,42,59,60,78,80,91,101.
VMAC91
VMACDB2
Jun 12, 1995
Change 13.075 Support for WYLBUR Accounting from ACS Wylbur. This SMF
EXTYWYLA record is similar to TYPEWYLB (WYLBUR Accounting from OBS
IMACWYLA Wylbur), but five variables are added, and fields are in
TYPEWYLA different locations, hence the need for these new members
VMACWYLA to create new dataset WYLBURA.
Jun 12, 1995
Thanks to Matt Anderson, Texas Tech University, USA.
Change 13.074 Further performance improvement. LENGTH DEFAULT=4; is
XMXGSUM now set in first DATA step, saving //WORK space.More
Jun 11, 1995 diagnostics added internally.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.073 PDB.JOBS variables ABEND and CONDCODE cannot be used for
VMAC30 ABEND analysis; instead, PDB.STEPS must be used, because
Jun 9, 1995 a) programs abend, not jobs, and using PDB.STEPS lets you
identify which program was involved, so you can
separate inhouse-written programs from externally
acquired programs. Furthermore, counting ABENDs by
program will identify a trend that might be lost if
the same program abends many times in different jobs;
there may be only one ABEND per JOB so the program
would be overlooked if you counted by jobs.
b) multiple abends can occur in a job - which one do you
want in PDB.JOBS - the first, last, or which?, and
c) the type 30 subtype 5 record values are inconsistent:
variable CONDCODE is the value from the final step,
not the last step which failed, and
variable ABEND relates to the entire job, not a
specific step, based on bits in TERMIND1.
-However, an MXG logic error can cause type 30 subtype 5
to have ABEND='SYSTEM' for a job which had ABEND='USER'.
The correction is to replace
IF COMPCODE>=32768 THEN DO;
with these five lines:
IF TERMIND1='1.......'B THEN DO;
ABEND='SYSTEM';
CONDCODE=COMPCODE;
END;
ELSE IF COMPCODE>=32768 THEN DO;
Thanks to ???, Benetton, ITALY.
Change 13.072 APAR OW08641 for NPM Version 2.2 discusses support for
FORMATS LU 6.2 sessions acting in half-duplex flip-flop mode, and
VMAC28 adds new APPC values for Session Type in LSCDSTYP, so the
Jun 9, 1995 variable is now formatted by new format $MG028ST.
Note added Mar 27, 1998: The format $MG028ST was created
by this change, but the variable LSCDSTYP was not given
the $MG028ST format until Change 16.037!
Change 13.071 OS/400 Version 3.1 only, the DSARM and DSTYPE variables
VMACQAPM are reversed. The IBM documentation shows the order was
Jun 8, 1995 changed, so I coded to agree with the documentation, but
now real data proves that the documentation was wrong,
so now the code agrees with the data! Change the last
pair of INPUT's of DSARM and DSTYPE so that the order is
DSARM, then DSTYPE. There are three pairs of INPUTs, and
now, all will have DSARM before DSTYPE.
Also, two references to variable SPRES2 were removed.
Thanks to Clark Jennings, Reynolds Metal, USA.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.070 Dataset NDMCT variable NDMDSDSN (Source Dataset Name)
VMACNDM was added to the KEEP= list, the second occurrence of
Jun 8, 1995 NDMDODSN in the LABEL statement was changed to NDMDSDSN,
and the first INPUT of NDMDODSN was changed to NDMDSDSN.
Thanks to Sue Yarker, Midland Bank PLC, ENGLAND.
Thanks to Natasja van Gavel, Alcatel, BELGIUM.
Thanks to Bryant Osborn, NationsBank Technology Services, USA.
Change 13.069 Cosmetic changes. Label for DB2END should be "LAST*DB2"
ANALDB2C (it was "LAST*CICS..."), and incomplete comments were
Jun 8, 1995 completed and clarified.
Thanks to Geert De Gand, Nationale Bank Van Belgie, BELGIUM.
Change 13.068 Change 12.196, when implemented, did not contain the
VMACNSPY ELSE ARSPNET=.; statement, but that line has been
Jun 8, 1995 added so the code agrees with the change.
Thanks to Alan Keeble, British Steel, UK.
Change 13.067 Backlevel SAS (TS404 for sure) causes error VFONF DOES
ANALRMFR NOT FOLLOW VFON0 (because syntax of A-F for variable name
Jun 8, 1995 suffix didn't work right in TS404). Install current SAS,
or you could RENAME each of the A-F variables to 10-16,
and change the ARRAYs to VFON0-VFON16.
Thanks to David Childers, Lowe's Companies, Inc, USA.
Change 13.066 Support for MVS/ESA 5.2 (compatible) SMF record changes.
VMAC24 -Type 24 SMF record variables SMF24LN4,SMF24SAN,SMF24SAC
VMAC30 were added to TYPE24, listing system affinity names; I
VMAC42 keep only the first 8 system names in SMF24SAC.
IMAC42 -Type 30 SMF record added new CPU measures CPUASRTM (the
EXTY42XR Preemptable SRBs and Client SRBs CPU time) and CPUENCTM
Jun 5, 1995 (the Enclave CPU time); note that these two new CPU times
are already included in CPUTCBTM. New variables ENCLACTM
ENCLCPSU and ENCLTRAN provide Enclave transaction active
time, CPU Service units, and transaction counts. Also,
variables IARVPSEC,IARVAPIN,IARVEPIN record page seconds
memory residency for IARVSERV shared CSTORE, and page ins
from Aux Store and Expanded Store. Those variables were
added to TYPE30_V,TYPE30_4,TYPE30_5 & TYPE30_6 datasets
but were not propagated into BUILDPDB/BUILDPD3 as yet.
Finally, Automatic Restart Management Section provides
the element name, type, restart group, and the timestamps
when IXCARM issued REGISTER,WAITPRED,READY, & DEREGISTER;
the ARMS variables were only added to TYPE30_5 until more
is understood about their usage.
-Type 42 SMF new subtype 11 for XRC Extended Remote Copy
creates new dataset TYPE42XR with the logical session
name, and per-SSID activity counts (data mover reads,
with/without data, format/update writes, etc.).
The new segments have been coded, but not all have been
tested with data records that have populated those data
segments, so verify your results.
Change 13.065 MVS/ESA 5.1 TYPE30_V (PDB.SMFINTRV) SET CLOCK causes bad
VMAC30 INTBTIME/INTETIME (interval begin/end time of day) value.
Jun 4, 1995 This note revised Jul 12, 1995 - prior belief that error
Jul 12, 1995 was leapseconds value in sysplex timer is not correct.
Fields SMF30IST/SMF30ISS should be identical, with IST on
local clock and ISS on GMT clock (so that we can measure
the GMT-to-local delta), but one site had deltas between
IST and ISS of 36 seconds for days, then 80 seconds, etc.
After chasing through IBM SMF level 2 for weeks with no
answer, the site's IBMer found an IBM note describing the
culprit: the use of SET CLOCK command:
When a system is IPLed, the GMT is exactly in sync
with the local time, but when a SET CLOCK command is
issued to change the local time to be out of sync with
the GMT (and this also causes the "SMF midnight" to be
recalculated), now jobs run show an IST-ISS delta
exactly equal to the GMT-local delta of the SET CLOCK
command! And the note says that IBM plans only to
document to clarify that changing the local time may
get the local time out of sync with the correct offset
from GMT! Note "Relationship between SMF30ISS and
SMF30IST" by David, document number (?) ADB0627.
MXG variable EXECTM in TYPE30_V becomes negative, and
variables INTBTIME/INTETIME/SYNCTIME are earlier than
all other timestamps in the interval record.
Existing TYPE30_V datasets can have the negative
EXECTM corrected by this recalculation:
EXECTM=INTETIME-INTBTIME;
Since IBM plans no change, I have revised my logic to now
expect this difference and to use it:
1. After using the FLOOR(IST-ISS) to calculate the GMT
offset in hours, I now also calculate any delta in
seconds and add that back into the GMT offset so that
ISS and IET values will be brought up to the IST
clock. After the line:
GMTOFF30=100*FLOOR(SMF30IST-INTBTIME+10)/100);
Insert this line:
GMTOFF30=GMTOFF30+SMF30IST-INTBTIME;
This logic will work when the error is fixed, too!
2. The calculation of EXECTM in the interval record does
not use LOADTIME anymore:
First, find the line:
IF MULTIDD NE 'Y' THEN DO;
and then find the subsequent line reading:
EXECTM=(INTETIME-MAX(LOADTIME,INTBTIME));
and change it to read:
EXECTM=INTETIME-INTBTIME;
(The actual change restructured the logic.)
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 13.064 Multi-UCB type 14/15 records were not properly processed
VMAC1415 due to MXG logic error. The actual order of segments is
Jun 2, 1995 basic, (open date), UCB-segments, (hiperbatch), (ISAM),
(extended segment), and there are two possible extended
segments: compressed statistics or SMS classes. Support
required relocating MXG code so that the hiperbatch, ISAM
and extended segment data are read in before processing
the UCB segments. Since MXG OUTPUTs one observation for
each UCB segment, the hiperbatch and compressed file
statistics appear only once per record, not once per UCB
segment. For multi-ucb records, then, the counts for the
hiperbatch and compressed file statistics will be kept in
the first observation from each record and will be set to
missing in the 2nd and subsequent observations created by
the additional UCB segments. Variable UCBSEGNR was also
added to identify whether observations in TYPE1415 are
created by the first or subsequent ucb segments.
Multi-ucb records are created for concatenated BPAM files
for multi-volume files, and for striped files.
Real data records clarified IBM documentation of the real
order of these segments.
The major impact without this fix was that multi-ucb obs
had SMS storage, data, and management class blank in all
but the last observation for that SMF record (and the
compression statistics could have been incorrect).
Thanks to Paul Dzielak, Smith Barney, USA.
Change 13.063 Variables TTOCPREL,TTOCSUCL have value of *NONE* unless
VMXGHSM the volser started with H; a local tailoring mod was left
Jun 2, 1995 in the code that should have been removed. Delete the
two lines that contain '*NONE*'.
Thanks to Wanda Prather, Johns Hopkins Applied Physics Lab, USA.
Change 13.062 MXG 13.01 only.
VMACNSPY -Remove "$HEX16." from line 124700, as those variables are
Jun 2, 1995 should be $HEX.2. Fortunately no harm was done, but the
variables were stored as 8 bytes instead of 1 byte!
-Labels for VRBMAXWD,VRBMINWD are now SIZE vice COUNT.
-Insert STARTIME=ENDTIME-DURATM; immediately before the
%INCLUDE SOURCLIB(EXNSPYVT); to create STARTIME.
-Variable APPLID was removed from the KEEP= list for the
datasets NSPYVTAM and NSPYVIRT as it does not apply.
-INPUT of variable NSPBPOOL was changed to $EBCDIC4. (it
was &PIB.4.) and it is now labelled 'BUFFER*POOL*NAME'.
Thanks to Rod Fernandes, Albert Heijn B.V., NETHERLANDS.
Change 13.061 All MXG-built formats for hexadecimal values now have
FORMATS OTHER=(| $HEXn. |) - for character variables
Jun 1, 1995 OTHER=(| HEXn. |) - for numeric variables
added in their creation so that undefined values are
displayed in hex. This syntax is only available in
SAS Version 6.07 and later, so if you still must try to
run MXG under archaic SAS 6.06 or more archaic SAS 5.18,
you will have to remove all of those lines from member
FORMATS before you build your archaic format library.
Thanks to Shantha Baran, British Steel, ENGLAND.
Change 13.060 MXG 13.01 only. Change 13.055 was not spelled right.
GRAFLPAR The test IF NAME GT ' ' THEN DO; added by 13.055 should
Jun 1, 1995 be IF LP&ID.NAME GT ' ' THEN DO;
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.059 -Label corrections. Variable NSPBOEXP "buffers" misspelled
VMACNSPY and variable CBPFLAG was changed to "TABLE*FLAG".
Jun 1, 1995 -Format correction. Variable NSPXRESO was removed from the
$HEX16 format, as it is a character, not hex, variable.
-MXG 13.01 only, new support for record type X caused
"INPUT STATEMENT EXCEEDED RECORD LENGTH" error. The line
M4=-4; must be changed to M8=-8; and the subsequent
reference to +M4 must be changed to +M8.
Thanks to Norbert Korsche, OMV AG, AUSTRIA.
Change 13.058 ANALDB2R error "BY VARIABLE STRTTIME IS NOT ON INPUT DATA
ANALDB2R SET WORK.DB2DUMRY" resulted from bad MXG logic. Find
May 30, 1995 "%MACRO PMSTA01", and change the next two occurrences of
" BEGTIME" to " STRTTIME" (note, don't change &BEGTIMEs):
First: OR &PMSTA01 NE YES %THEN BEGTIME;
Second: DURATM=ENDTIME-BEGTIME;
Thanks to David Klein, City of New York, USA.
=====Taught in London and Heidelberg, paper at Konigswinter CMG-CE======
Change 13.057 CICS Statistics dataset CICLSRR variables A08BKCTD and
VMAC110 A08BKDTD were incorrectly INPUT as RMFDUR4. Their input
May 4, 1995 lines (two pairs) must each be replaced with:
HH &PK.1. MM &PK.1. SS &PK.1. TH ?? &PD.1. @;
IF TH GE 0 THEN A08BKCTD=HMS(HH,MM,(SS+TH));
ELSE A08BKCTD=.;
INPUT
Thanks to Steve Harris, TVA, USA.
Change 13.056 Change 13.017 (TYPE6 OUTDEVCE for 4-digit Remote) was not
VMAC6 correct. The "5,2" in the SUBSTR should be "6,2". The
May 4, 1995 text of 13.017 has also been changed to be correct.
Thanks to Norbert Korsche, OMV, AUSTRIA.
==Changes thru 13.055 were included in MXG 13.01 dated May 3, 1995===
Change 13.055 Intermittent LPARs (test LPARs) caused strange graphs;
GRAFLPAR The statement IF LP&ID.UPDTM GT 0 THEN DO;
May 3, 1995 should be IF NAME GT ' ' THEN DO;
so the LPAR numbers don't change from hour to hour!
Thanks to Tom Kelman, SunTrust Service Corporation, USA.
Change 13.054 Variable NRSAMPLE was added to the TYPE74CF KEEP= list.
VMAC74 Several calculations on the Coupling Facility require the
May 3, 1995 number of samples.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 13.053 If you used TEMP01 or TEMP02 parameters to segregate the
XMXGSUM work files, variables were missing because dataset VARS
May 3, 1995 was not in the DELETE list. In addition, the logic has
been significantly simplified by using SUM(A B C)=A B C
(instead of the archaic SUM= list with X1-Xnn placeholder
dummy variables). This might be the last iteration as
XMXGSUM has now been tested with just about all feasible
combinations, but I will wait until MXG 13.02 before I
actually replace VMXGSUM with this XMXGSUM. I strongly
suggest that you install XMXGSUM in place of VMXGSUM as
described in the comments in XMXGSUM - XMXGSUM is much
more efficient, especially for CICS and DB2 data.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.052 When ASUMTALO was revised (Change xx.yyy), corresponding
GRAFTALO changes to GRAFTALO should have been made. SYSTEM was
May 2, 1995 removed, ALOCTIME changed to TIMESTMP and the average
tape drives allocated is TAPEDRVS=TAPEDRVS/DURATM;.
Thanks to Tom Elbert, John Alden Life Ins., USA.
Change 13.051 AS/400 3.1 dataset QAPMSYS duration variables SITRNT,
VMACQAPM S6TRNT and SPRES1 are INPUT as &PD.8.3 instead of &PD.8.
May 2, 1995 V 3.1 increased the field width from 6 to 8 bytes but the
change in units to milliseconds was not documented! In
addition, SPRES1 and SPRES2 were renamed SPTRNT and
SPTRNS and added to the KEEP= list for QAPMSYS dataset.
(The "Passthru" SICPU/SITRNT/SITRNS and the "inter"
SPCPU/SPTRNT/SPTRNS variables are both needed to track
total interactive work.) See also Change 13.011.
Thanks to Lynn Marchant, Coca Cola, USA.
Change 13.050 TYPE42DS I/O Statistics Subsection does not always exist,
VMAC42 but MXG input the variables nevertheless, causing really
May 2, 1995 large values for I/O durations and cache statistics.
Insert IF OFFDSIO GT 0 THEN DO;
before OFFDSIO=OFFDSIO-3+OFFSMF;
Before OFFDSAM=OFFDSAM-3+OFFSMF;
insert END;
So the fields will be missing instead of wrong. I am
still investigating why OFFDSIO (S42DSIOO) is zero.
Thanks to Ted Blank, IBM, USA.
Change 13.049 TYPE116 dataset has zero observations. Change both
VMAC116 IF SUBTYPE=1 THEN ... to IF SUBTYPE=0 THEN .... Insert
May 2, 1995 OFFQMAC=OFFQMAC-3+OFFSMF; before INPUT @OFFQMAC
Thanks to E.U.C. Hettinga, Centrum Voor Informatie.., NETHERLANDS.
Change 13.048 XMXGSUM in MXG 13.01 still failed, if the TEMPDD argument
XMXGSUM was used, due to mislocated code when Change 13.032 was
Apr 26, 1995 made. Also, repeated executions of XMXGSUM could fail
because temporary dataset VARS was not deleted at the
end of XMXGSUM.
Change 13.047 ANALTAPE in MXG 13.01 still failed, because Change 13.044
ANALCNCR to ANALCNCR created an error when there was no SUMBY used
Apr 26, 1995 in the %ANALCNCR invocation. (Only ANALTAPE had the
exposure). (See also Change 12.327).
One instance caused A NUMBER HAS BECOME TOO LARGE error.
==Changes thru 13.046 were contained in MXG 13.01 dated Apr 27, 1995==
Change 13.046 Report enhancements to the CICS Shutdown reports, titles
ANALCISH for detail reports, and other cosmetics were added by
Apr 26, 1995 this extensive user contribution.
Thanks to Willi Weinberger, IDG, Germany.
Change 13.045 LENGTH statement was moved to before FORMAT statement so
IMACICSA character variables' length is correct. See SAS Technical
Apr 25, 1995 Note (above, or in MXG Newsletter TWENTY-EIGHT).
Thanks to Stefaan Lemaire, COMPAREX Information Systems, BELGIUM.
Change 13.044 Missing value for timestamp was not protected, causing
ANALCNCR invalid DO loop control variable. ASUMTALO now throws
ASUMTALO away invalid records, and ANALCNCR is now protected for
Apr 25, 1995 missing value in DO loop control variables.
Change 13.043 These members were revised to work with XMXGSUM. They had
ASUMVMON exploited a loophole in VMXGSUM (the right side of the
TRNDVMON NORM= list was an expression instead of a variable name)
Apr 25, 1995 that does not exist in XMXGSUM.
Change 13.042 -The mapping of DB2 DBID/OBID hex values to the table name
ANALDB2R uses the IFCID 105 and 107 records to dynamically create
Apr 25, 1995 a look up table, the $DB2DBID and $DB2OBID formats. The
logic assumed a one-to-one mapping, but it turns out the
values get reused (DELETE and then CREATE a tablespace)
so the logic for creating these formats was redesigned to
append the timestamp of the 105/107 to create the range
of datetimes when that DBID/OBID pair was in effect.
-ANALDB2R now will execute under OS2 - the logic to detect
if the PDB pointed to an MVS tape failed on a non-MVS
platform. Also, OPTIONS LINESIZE=132 is now specified so
proper print width is used for these reports.
Thanks to ???, ???, USA.
Change 13.041 TYPE72MN variables WSETFIX/WSETASM were incorrect.
VMAC7072 They are now created using:
Apr 25, 1995 WSETFIX=FRAMEFIX/AVGUSER;
WSETASM=FRAMEASM/AVGUSER;
Thanks to Jim Gill, St. Johns River Power Park, USA.
Change 13.040 Dataset DB2ACCT variable QBACSWS and QBnCSWS were always
VMACDB2 zero; statement (QBACPID QBACGET QBACRSVD QBACSWS ...
Apr 25, 1995 should have been (QBACPID QBACGET QBACSWS QBACRSVD ...
Thanks to Jason Lau, CSC, AUSTRALIA.
Change 13.039 -The SAS/CPE product expects a "system" variable in each
DIFFTMDB dataset built by MXG, and their cross-check uncovered
TYPEMON8 these datasets which did not have a "system" variable:
TYPETMON MONIDSA - SYSTEM (retained from "TI" record)
VMACCIMS TYPECTLD - SYSTEM (was missing from KEEP= list)
VMACCTLD TMDBDE - SYSTEM (retained from "TA" record)
VMACDCOL -Dataset labels were missing in CIMSxxxx (IMF) datasets.
VMACOMSM -Variable DCDRECFM has been created in dataset DCOLDSET
VMAC7072 -SAS/CPE also expects a "duration" variable in interval
VMAC89 datasets; most MXG interval datasets contain STARTIME,
Apr 25, 1995 ENDTIME, and DURATM, but there were some omissions that
VMAC28 have now been corrected for consistency; you should now
May 2, 1995 expect those three variables in all interval datasets.
TMDBDA - No duration in record, required new member
DIFFTMDB to be invoked by TYPETMDB to SORT
and then create DURATM=DIF(ENDTIME);
OMSMSJOB - DURATM=OMFS2ETM-OMFS2STM;
TYPE7204 - DURATM should have been in KEEP= list.
TYPE7204 - DURATM should have been in KEEP= list.
TYPE89 - DURATM=SMF89IET-SMF89IST;
NPMxxxxx - DURATM=ENDTIME-STARTIME added to datasets
NPMNCINT NPMNGINT NPMNLINT NPMNLSUM NPMNRINT
NPMVSVAD NPMVSVAP NPMVSVBF NPMVSVDV NPMVSVVR
NPMNVINT NPMNVSUM NPMINTRI NPMINNEO NPMIN25L
NPMIN25P NPMINNVC NPMINFRP NPMLANIN
Thanks to Carl Sommer, SAS Institute Cary, USA.
Change 13.038 Support for subtypes 4 and 5 of HMF SMF record was added
EXTYHMFR to decode both subtypes; the subtype 4 creates a new data
IMACHMF set, TYPEHMFR, with path/route detail, while TYPEHMF4 has
VMACHMF the node statistics data. Subtype 4 has been data-tested
Apr 25, 1995 but there were no subtype 5s in the test data file.
Thanks to Shaheen Pervaiz, Acxiom, USA.
Change 13.037 Reports showing union of all systems were missing from
ANALTAPE the revision introduced in MXG 12.12.
Apr 21, 1995
Thanks to ???, ????, USA.
Change 13.036 Continued validation of ANALCNCR closed these exposures:
ANALCNCR -GOPTIONS HTITLE=1 HTEXT=.75 added to reduce the size of
Apr 21, 1995 text and titles to readable proportions.
-Plot of summary had MAX axis value slightly lower than
the max value plotted, and DEVICE= specification was
ignored.
-Plots failed with 0 observations in datasets.
-Invalid DO loop range when no SUMBY= was specified and
intervals were being synchronized.
Thanks to Tom Parker, Hogan Systems, USA.
Change 13.035 Support for APAR OW04653 which adds several variables to
VMAC74 TYPE74ST (Coupling Facility Structures) which appear to
Apr 20, 1995 be quite important in tracking capacity of the Coupling
Facility:
R744SCUF R744SDEC R744SDEL R744SMAE R744SMAS R744SMIS
R744SNLH R744SSIZ
These changes and the MXG corrections in Change 13.004
are important enough for users of MVS/ESA 5.1 in Goal
Mode (Workload Manager) that MXG 13.01 is required.
Users with MVS/ESA 5.1 still in compatibility mode still
require only MXG 12.12, but installing 13.01 is still
recommended.
Thanks to Scott Coryell, First Bank System, USA.
Change 13.034 Protection for RACFTYPE=55 to prevent "SKIPPED SEGMENT"
VMAC80A message, and variable RACFEVNT= was added to the SKIPPED
Apr 19, 1995 SEGMENT message to identify which event contained that
segment, in case it is necessary to decode and add any
new variables.
Thanks to Henrik Tonnisen, Jyske Bank Data A/S, DENMARK.
Change 13.033 A new global macro variable, MXGDEBUG, is now defined in
VMXGINIT VMXGINIT, to facilitate internal debugging %MACRO code.
Apr 18, 1995 Globaling this macro name allows debugging to be enabled
without source code changes; however, I expect that this
option will typically be used only by MXG Tech Support in
problem resolution, or during developmental testing.
It is currently implemented only in member XMXGSUM, with
these initial arguments defined:
1= Display normally non-printed messages about which
variables are being dropped because they were not
found in the input datasets - VMXGSUM specific.
2= Turn on MPRINT
3= Turn on MPRINT SYMBOLGEN
4= Turn on MPRINT SYMBOLGEN MLOGIC
You would use %LET MXGDEBUG=x; to enable this debug.
Change 13.032 More validation of this soon-to-be-replacement for the
XMXGSUM VMXGSUM member. If a variable appeared twice in one of
Apr 21, 1995 the lists or is not found in the input dataset, the
wrong number of 'Xn' variables to skip over in the
PROC MEANS was calculated, causing output variables to
contain incorrect values. The logic to calculate how
many variables are to be skipped was corrected.
-Ranges of variables BKT1-BKT8 were supported, but parsing
BKT1-BKT18 missed variables 9-18; that is now corrected.
-If all variables are missing for a NORM parameter, a note
is printed and the parameter is ignored.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Tom Elbert, John Alden, USA.
Change 13.031 Variables QTPUBDD and QTXAIRLM were incorrectly spelled
TRNDDB2S as QTPUBD and QTXAIRL respectively in MXG 12.12/12.12A.
Apr 18, 1995 Although documented as having been made in April, this
Sep 20, 1995 change was not actually made in TRNDDB2S until September.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.030 Support for IBM's IRRDBU00 - RACF Database Unload Utility
EXRAC... is provided by this significant user contribution from
IMACRACF Peter Proppe. The utility creates a sequential file from
TYPERACF a restructured RACF database, so your RACF administrator
VMACRACF can ask complex queries and create reports about the RACF
Apr 18, 1995 security definitions (like who has access to what, etc.!)
There are 39 MXG datasets created by this enhancement.
See comments in member VMACRACF for documentation, and
the IBM documentation is in RACF Macros and Interfaces.
Thanks to Peter Proppe, Bremer Lagerhaus Gesellschaft, GERMANY.
Change 13.029 Landmark MONIDSA build was copied from TYPETMON in Change
TYPEMON8 12.315, but the LABELs and FORMATs for the variables were
Apr 18, 1995 not copied until now. In addition, this "interval" data
record contains neither a DURATM nor STARTIME nor SYSTEM
fields that describe the interval. Am awaiting Landmark.
Thanks to Carl Sommer, SAS Institute Cary, USA.
Change 13.028 Support for Sterling's SOLVE NCL CPU-time accounting user
EXTYSOLV SMF record creates new dataset TYPESOLV allowing you to
IMACSOLV collect NCL CPU usage at the user level. These records
TYPESOLV are interval records, but records are only created if the
VMACSOLV CPU time used by the user exceeds the threshold specified
Apr 14, 1995 in the SOLVE USERACCT command.
Thanks to Arzina Merali, Alberta Public Works, CANADA.
Change 13.027 0C4 ABEND in this assembly program occurred because IBM
ASMRMFV loaded an offset address for enqueue table, but there was
Apr 14, 1995 no enqueue table. To correct, find the line reading
L R8,ENTENTMX(,R9)
and insert these two new lines:
LTR R8,R8
BZ ENDENT
Then find the label (in column 1) MVEENT, and then find
the statement BNE MVEENT several lines later. Insert
(in column 1) ENDENT DS 0H after that BNE.
The actual change in this version of the RMF Monitor III
decompress program was more extensive - now statistics
of records read/written are printed on the job log, and
you can now select which classes of records are written.
Thanks to Leon Berthou, Dan Computer Management, DENMARK.
Change 13.026 ICEBERG SMF record subtype 5 (deleted data space release)
VMACICE did not use ESTOSET to locate the data segment, causing
Apr 13, 1995 incorrect values for the extent addresses and TOIOTIME.
Jun 3, 1995 After the line now reading: EXTOSET=EXTOSET-3;
insert a new line reading: INPUT @EXTOSET @;
Text added 3Jun95:
And delete the line +4 /* UNDOCUMENTED*/
It turns out there have been two different lengths of
ICEBERG (or IXFP) subtype 5 records, one with that 4-byte
undocumented field (and RDW=148), now without that field
(and RDW=144, which means the SAS LENGTH=140). An INPUT
STATEMENT EXCEEDED RECORD LENGTH error occurred when the
140-byte record was read with the 144-byte-expecting MXG
12.12! The above change using EXTOSET and deletion of
the +4 protects for either length of IXFP record.
Thanks to Tom Kelman, SunTrust Service Corporation, USA.
Thanks to Rich Morris, Progressive, USA.
Thanks to Brian Crow, British Telecom, WALES.
Change 13.025 Dataset TYPE72GO variable PGPEXCP is now kept for goal
VMAC7072 mode. Note that PGPIOTM is no longer calculatable for
Apr 12, 1995 Goal Mode, because the IBM developers eliminated the
option to use IOTM instead of EXCP for RMF I/O units in
MVS/ESA 5.1 Goal Mode.
Thanks to Al Keeble, British Steel, ENGLAND.
Change 13.024 The +1 reserved field after the INPUT of CHIRECNT should
VMACTMVS be +4 instead. This error trashed values in the TMVSCH
Apr 12, 1995 (Channel Path I/O) dataset.
Thanks to Nico Lenaerts, SAS Belgium, BELGIUM.
Thanks to Wim Desmecht, DOLMEN Computer Applications NV/SA, BELGIUM.
Change 13.023 Dataset CICFCR variable A17DSTYP was mislabeled, input as
FORMATS numeric instead of character, and was not decoded. Now,
VMAC110 it is input as character, and new format $MGCICDT decodes
Apr 12, 1995 the Dataset Type as BSAM, ESDS, KSDS, RRDS, or PATH.
Thanks to Chuck Hopf, MBNA, USA.
Change 13.022 Support for NETSPY Release 4.6 added, thanks to advance
EXNSPYAL documentation from LEGENT (that release won't ship until
EXNSPYVT summer). Their changes were compatibly made.
FORMATS -Variable NSPYNETW (Network ID) was added to the header so
IMACNSPY it is now kept in every MXG NSPYxxxx dataset.
VMACNSPY -Dataset NSPYAPPL. New variable NSPNETAP (Network ID of
Apr 12, 1995 the Application) was added. Also, labels for variables
Apr 14, 1995 APOTLN62 and APOTNN62 were corrected; these variables
measure bytes sent outbound on sessions where response
time is or is not monitored.
-Dataset NSPYLU. New variables LUNETID, PCSESSID, VILUNAME
were added, containing Network ID of this LU, Procedure
Correlation ID, and Virtual LU Name respectively.
-Dataset NSPYETHR. New variable NSPEDISD, Discarded
Datagrams was added.
-Additional changes were made that were not 4.6 related:
-New datasets NSPYALRT and NSPYVTAM are now created from
type X and B records; these records are not new with
Release 4.6, but had not been decoded previously. The
type X record has been tested with data, but there are
data values for NSPXRTYP and NSPXVART which are not shown
in NETSPY documentation. NSPYVTAM has not been data-ed!
-Corrections found during early code validation:
Test for LMI Station should have been OR instead of AND
i.e., (NSPNSUBE='20'X OR NSPNSUBE='10'X) THEN DO;
Test for FRSE Station should have been OR vice AND:
i.e., (NSPNSUBE='20'X OR NSPNSUBE='80'X) THEN DO;
Second input of REBYTCT with /*XRBY*/ was deleted.
Second REBYTCT in KEEP list for NSPYTIC3 was deleted.
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Change 13.021 NETSPY type N records subtypes 07 (TIC3) and 08 (Trans
EXNSPYTP Priority) were not correctly processed, causing Divide by
EXNSPYT3 zero with subtype 07 variable CYCLSPD. The circumvention
IMACNSPY is to change the line
VMACNSPY IF NSPNRECI='02'X OR NSPNRECI='06'X OR NSPNRECI='07' OR
Apr 10, 1995 NCPELTYP=80X THEN DO;
to read
IF NSPNRECI='02' OR NCPELTYP=80X THEN DO;
The actual change was more extensive, creating two new
datasets, NSPYTIC3 and NSPYTPRI from the 07/08 subtypes.
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Change 13.020 -XMXGSUM failed if one of the input datasets did not exist
XMXGSUM (as in the first time a TRND members is run) AND any of
Apr 10, 1995 variables in the datasets did not exist. (VMXGSUM did not
fail because it protected by creating missing variables
using the IF X=. THEN X=.; "compiler faker" statement.)
Logic corrected, and switches were added to help in the
debugging of XMXGSUM.
-KEEPIN macro needed to be UPCASE'dED.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 13.019 The example SAS program has a "EXPECTING VARIABLE" error.
ACHAP35 -Insert
Apr 3, 1995 TODAY=TODAY();FORMAT TODAY DATE9.; DROP TODAY;
after the statement
IF LASTDATE NE TODAY()-1 THEN DO;
-Change LASTDATE's FORMAT from MMDDYY8. to DATE9. (to
be consistent with MXG's DATE conventions).
-Change "5X" to "+5".
Thanks to Bruce Hewson, Alcoa, AUSTRALIA.
Change 13.018 The %INCLUDE SOURCLIB(ASUMDB2S); should be deleted from
JCLPDB6 the JCLPDB6 example, as there is no member ASUMDB2S.
Apr 3, 1995 (There is a TRNDDB2S, but it uses the DB2STATS dataset
as its input, and DB2STATS is already an interval dataset
so there is no need for an ASUMDB2S. All ASUMxxxx members
create interval data from detail data.)
Thanks to Bruce Hewson, Alcoa, AUSTRALIA.
Change 13.017 TYPE6 OUTDEVCE for a 4-digit Remote Number is R2030PR1,
VMAC6 instead of the old Rnnn.PRm format. MXG parsed variable
BUILDPDB OUTDEVCE to set DEVICE=PRINTER or PUNCH, expecting the
BUILDPD3 period delimiter, but the new format causes DEVICE to be
BUILD005 blank, which causes lines that were formerly counted in
Apr 3, 1995 variable PRINTLNE or PUNCHCRD to be counted in variable
EXTWTRLN instead, in both the TYPE6 dataset and in the
PDB.PRINT and PDB.JOBS datasets.
In VMAC6, replace these four lines:
IF PR=:'PR' THEN DEVICE='PRINTER';
IF PR=:'PU' THEN DEVICE='PUNCH ';
with these six lines:
IF PR=:'PR' OR
(SUBSTR(OUTDEVCE,1,1)='R' AND SUBSTR(OUTDEVCE,6,2)='PR')
THEN DEVICE='PRINTER';
ELSE IF PR=:'PU' OR
(SUBSTR(OUTDEVCE,1,1)='R' AND SUBSTR(OUTDEVCE,6,2)='PU')
THEN DEVICE='PUNCH ';
Note: above text corrected on May 3, from 5,2 to 6,2.
-Variable TOTLINES, the sum of PRINTLNE,PUNCHCRD,EXTWTRLN,
in the PDB.PRINT dataset was always correct. However, I
now realize that TOTLINES should also be created in the
PDB.JOBS dataset, so the BUILDxxx members were changed to
create and label variable TOTLINES into PDB.JOBS.
Thanks to Norbert Korsche, OMV, AUSTRIA.
Change 13.016 MXG 12.12 inadvertently changed some variables' FORMAT
VMAC7072 from 5.1 to 5.0. Line 102100 in VMAC7072 should be 5.1
Apr 3, 1995 instead of 5. so that one decimal place of precision
will be printed.
Thanks to Joanne Turpie, Department of Labour, NEW ZEALAND.
Change 13.015 MXG 12.12 and MXG 12.12A. MONTHBLD sort error; the BY
MONTHBLD list for TYPE72 should be exchanged with the by list for
Apr 3, 1995 TYPE72DL, and in the TYPE72DL sort list, replace PERFGRP
with SRVCLASS. (Make MONTHBLD look like WEEKBLD!).
Thanks to John Mattson, National Medical Enterprises, USA.
Change 13.014 Semicolon is missing at the end of SET PDB.APAFDOMA and
ANALAPAF the colon after PROC PRINTTO DATA=... should be a semi
Mar 30, 1995 colon, and a PROC PRINTTO; was added as the last line to
Apr 25, 1995 reset the print destination back to the log.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 13.013 Tracking IMS DEDB (Data Entry Data Base) and MSDB (Main
VMACIMSA Storage Data Base) activity is accomplished with the IMS
Mar 30, 1995 fastpath type 59x subcode 37x log record, but MXG only
output when SYNCRTYP='01'X. In IMS 4.1 at least, most of
the 59x37x records contain either 10x or 20x. Since I
don't normally delete observations, and because the 4.1
documentation suggests the meaning of this field has been
changed, I have changed the logic so all subcode 37 log
records will be output in IMS5937 dataset.
Thanks to Don Cleveland, Blue Cross Blue Shield of California, USA.
Change 13.012 MXG now detects that fields have been EXCLUDED from your
VMAC110 SMF type 110 CICS/ESA records, and prints error message
Mar 30, 1995 telling you to run UTILCICS and use its output to update
member IMACEXCL for MXG to support records with EXCLUDE.
Thanks to George Scott, Rockwell International Corporation, USA.
=====Changes thru 13.011 were in Early MXG 13.01 dated Apr 1, 1995=====
Change 13.011 Support for OS/400 Version 3.1.0 has INVALID DATA FOR ...
VMACQAPM because I had no test data for validation until now!
Mar 29, 1995 -Value of ASLEVEL starts with an unwanted blank. Use the
COMPRESS() function to eliminate that blank, by changing:
AS400VRN=PUT(GDESRV,2.)!!'.'!!PUT(GDESRR,3.1);
to read
AS400VRN=COMPRESS(PUT(GDESRV,2.)!!'.'!!PUT(GDESRR,3.1));
(because ASLEVEL is set from AS400VRN).
-All tests of IF ASLEVEL ... for value of '3' must be
changed to '3.1.0' and the one test for LE '2' must be
changed to LT '3.1.0'.
-Variables SWRES1,SPRES1,SMRES1,S6TRNT,SERES1,SARES1,
SBRES1,SXRES1, and SIRES1 input must be &PD.8 vice &PD.6.
-Variables SIRES1 and SIRES2 are now SITRNT and SITRNS.
-Calculation of PCTIOPBY needs to be copied into the 3.1.0
logic.
-Replace ELSE IF LENGTH=2364 OR LENGTH GE 2374 THEN DO;
with ELSE IF ASLEVEL LE '2.2.0' THEN DO;
-Replace ELSE IF LENGTH=3090 THEN DO;
with ELSE IF ASLEVEL GE '3.1.0' THEN DO;
-Reverse DSTYPE and DSARM in the 3.1.0 input for QAPMDISK.
Thanks to Len Marchant, Coca-Cola Enterprises, USA.
Change 13.010 Complete revision of support for HP's PCS for UNIX. There
EXHPAI.. are now separate members for the AIX, SUN, and HPUX UNIX
EXHPSU.. systems, because not all metrics exist on all three UNIX,
EXHPUX.. and the HPPCS record formats are different on each:
IMACHPAI
IMACHPSU Suffix For Members Infile
IMACHPUX HPAI AIX ADOCHPAI,TYPEHPAI,ASUMHPAI... HPAI
TYPEHPAI HPSU SUN ADOCHPSU,TYPEHPSU,ASUMHPSU... HPSU
TYPEHPSU HPUX HPUX ADOCHPUX,TYPEHPUX,ASUMHPUX... HPUX
TYPEHPUX
VMACHPAI These datasets are created from HPPCS records:
VMACHPSU
VMACHPUX AIX : HPAIAPPL,HPAICONF,HPAIDSK ,HPAIGLOB,HPAILANS
Mar 29, 1995 HPAIPROC
SUN : HPSUAPPL,HPSUCONF,HPSUDSK ,HPSUGLOB,HPSULANS
HPSUPROC
HPUX: HPUXAPPL,HPUXCONF,HPUXDISK,HPUXDSK ,HPUXGLOB
HPUXLANS,HPUXPROC,HPUXVOLS
This change replaces the support in TYPEHPCS.
The HPAI and HPUX support has now been validated in real
production sites. I am still trying to understand the
HP UX Disk data (HPUXDISK and HPUXDSK are similar but not
the same, and have repeated Disk addresses in interval
data) and SUMMARY=5 caused a problem with the AIX data,
but both sites are happy and productivly measuring UNIX!
Thanks to Richard Clary, Entergy Services, Inc.
Thanks to Lorenzo Wright, NCCI, USA.
Change 13.009 DB2 dataset T102S145 variables QW1145OB-QWF145OB have the
VMAC102 DB value instead of the OB value. Find all occurrences
Mar 27, 1995 of QWX145DB, and change the DB to OB in the fifteen lines
with QWn145OB on the left of the equality.
Thanks to Peter Durrant, National Australia Bank, AUSTRALIA.
Change 13.008 Support for TCP/IP SMF record APAR PN69321-PN69322, which
VMACTCP adds the API user's job name, APIJOBNM, to the API INIT
Mar 27, 1995 and API TERM event records. This support was coded based
on the APAR description, but has not been data-tested.
Change 13.007 NetSPY dataset NSPYNCP variables FBQ_PCT, FBH_PCT, and
VMACNSPY FBL_PCT can cause zero-divide error because MXG did not
Mar 24, 1995 understand the new data added by LEGENT.
The block of code that read:
CYCLUTIL=10*UCYCLETM/(DURATM*CYCLSPD);
FBQ_PCT =100*FREEBUFQ/MAXFREEB;
FBH_PCT =100*FREEBUFH/MAXFREEB;
FBL_PCT =100*FREEBUFL/MAXFREEB;
BUF_UTIL=100 - FBL_PCT;
now reads:
CYCLUTIL=10*UCYCLETM/(DURATM*CYCLSPD);
IF TFQBANCP GT 0 THEN DO;
FBQ_PCT =100*CFBQUELN/TFQBANCP;
FBH_PCT =100*FBQLNHWM/TFQBANCP;
FBL_PCT =100*FBQLNLWM/TFQBANCP;
END;
ELSE IF MAXFREEB GT 0 THEN DO;
FBQ_PCT =100*FREEBUFQ/MAXFREEB;
FBH_PCT =100*FREEBUFH/MAXFREEB;
FBL_PCT =100*FREEBUFL/MAXFREEB;
END;
BUF_UTIL=100 - FBL_PCT;
See further corrections in Change 13.021.
Thanks to Roger Zimmerman, Kemper Service Company, USA.
Thanks to Mr. Dechamps, R & V Versicherung, GERMANY.
Change 13.006 Error: Variable SYSTEM not Found, because all occurrences
ANALTALO of SYSTEM should be removed from ANALTALO - the analysis
Mar 24, 1995 of tape allocation is across all systems, and variable
SYSTEM is not kept in either ASUMTALO or TRNDTALO.
This error was only in the MXG 12.12A revision.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 13.005 For 3990-6 in Basic Mode, variables CSCONF,CSAVAIL,
VMACACHE CSPINNED,CSOFFL,CNCONF,and CNPINNED were 1024 times too
Mar 23, 1995 large; MXG converted K-bytes to bytes, but the conversion
only applies of the controller is in Enhanced Mode. Put
a DO group around the six lines containing "1024*":
IF CSSTAT='....1111'B THEN DO; .... END;
to convert only for Enhanced Mode.
Thanks to Jim Ritter, Blue Cross and Blue Shield of Oregon, USA.
Change 13.004 MVS/ESA 5.1 TYPE74ST Structures dataset "INVALID DATA FOR
VMAC74 R744SATM ..." error message, plus missing observations.
Mar 23, 1995 -The first structure was reread each time, and the 2nd-nth
text revised structures were not output, because the second occurrence
May 3, 1995 of "INPUT @SMF744SO " should have been just "INPUT "
(note, this is the INPUT statement just after the
DO _I_=1 TO SMF744SN; statement).
Note that this change will increase the count of obs that
are created in dataset TYPE74ST.
-Variables R744SATM,R744SASQ,R744SSTM,R744SSSQ,R744SQTM,
R744SQSQ,R744SDTM, and R744SDSQ were documented by IBM as
floating point, but they are actually binary numbers; the
eight INPUT statements for these variables with
&RB.8.6 must be changed to &PIB.8.6
Thanks to Scott Coryell, FBS Business Technology Center, USA.
Thanks to Steve Smith, BGS Systems, USA.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt, AG, Germany
Change 13.003 If you changed the duration of RMFINTRV (by tailoring the
ANALPGNS _DURSET macro defined in member IMACRMFI) this report did
Mar 23, 1995 not work, because it merges TYPE72 and RMFINTRV. Now,
ANALPGNS uses _DURSET to force the STARTIME of the TYPE72
data to match the STARTIME of RMFINTRV before the merge.
To make the correction, replace the line reading:
PROC MEANS NOPRINT DATA=PDB.TYPE72;
with these six lines:
%INCLUDE SOURCLIB(IMACRMFI);
DATA TYPE72;
SET PDB.TYPE72;
_DURSET
DROP DATE HOUR MINUTE;
PROC SORT DATA=TYPE72 %VMXGFOR ;
BY SYSTEM STARTIME PERFGRP;
PROC MEANS NOPRINT DATA=TYPE72;
Thanks to Carol King-Baer, Vanderbuilt University Medical Ctr, USA.
Change 13.002 DSNAME='UNKNOWN - CONCATENATED BPAM' was set by MXG for
VMAC1415 all striped, multi-volume, and IAM datasets, when it was
Mar 23, 1995 supposed to be set only for PDS datasets. The correction
is to change the ELSE DO; immediately preceding the
DSNAME='UNKNOWN...' statement to read:
ELSE IF DSORG='PO' THEN DO;
Thanks to Jim Zwier, Smith Barney, USA.
Change 13.001 Cosmetic changes. In ANALINIT there was no TITLE3 for
ANALINIT REPORT2. In UCICSCNT, variable BYTES is now formatted
UCICSCNT with MGBYTES (so 2.793E8 prints ast "266MB").
Mar 19, 1995
Thanks to Norbert Korsche, OMV, AUSTRIA.
===Changes thru 12.328 were included in MXG 12.12A dated Mar 20, 1995==
(but were not printed in MXG Newsletter TWENTY-SEVEN)
LASTCHANGE: Version 13
=========================member=CHANGE12================================
/* COPYRIGHT (C) 1984-1995 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is MXG Version 12.12A, dated Mar 20, 1995, thru 12.328.
MXG Version 12.12A is 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
MXG Version 12.07 was dated Feb 6, 1995, thru Change 12.290
MXG Version 12.06 was dated Jan 9, 1995, thru Change 12.240
MXG Version 12.05 was dated Nov 20, 1994, thru Change 12.218
MXG Version 12.04A was dated Oct 23, 1994, thru Change 12.192
MXG Version 12.04 was dated Sep 30, 1994, thru Change 12.169
MXG Version 12.03A was dated Aug 17, 1994, thru Change 12.140
MXG Newsletter TWENTY-SIX, Aug 4, 1994, thru Change 12.128
MXG Version 12.03 was dated Aug 4, 1994, thru Change 12.128
MXG Version 12.02 was dated Jul 4, 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
See member NEWSLTRS for text of Newsletter TWENTY-SEVEN of 1Mar95.
Contents:
I. MXG Software Version 12.12A, dated Mar 20, 1995.
III. MVS Technical Notes not printed in Newsletter TWENTY-SEVEN.
VIII. Incompatibilities and Installation of MXG 12.12A.
1. Members IMAC7072 IMAC74 IMACDB2 IMACPDB IMACWORK
IMACTMNT MONTHBLD WEEKBLD IMACCICS TYPEQAPM changed.
2. Installation instructions.
IX. Online Documentation of MXG Software.
X. Changes Log
I. MXG Software Version 12.12A, dated Mar 20, 1995, contains these major
enhancements:
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).
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/VMS 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.
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.
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 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:
Availability MXG Version
Product Name Date Required
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
III. MVS Technical Notes not printed in Newsletter TWENTY-SEVEN.
1. APAR OW06770 and QW09814 (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
when SYNC is specified, which causes MXG's RMFINTRV dataset to see
incorrect uncaptured CPU times. Boole's fix is BPM5061. Another
symptom is a difference of 1 second between the STARTIME in the type
70 and the STARTIME in the type 71 records.
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- ASUMTALO was incompatibly changed in MXG 12.12, so early users of
the Tape Mount and Allocation Monitor analysis will need to rebuild
PDB.ASUMTALO (by %INCLUDE SOURCLIB(ASUMTALO) against each PDB that
they want to include), so that TRNDTALO will trend tape allocation.
e- 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), 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.V1212.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2500+ 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 re-installing 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.
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.224 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:
NEXTCHANGE: Version 12
Change 12.328 Syntax errors may occur with ANALDB2R (depending on which
ANALDB2R reports are requested).
Mar 19, 1995 -Insert "INCODE=" between lines 045520 and 045530:
045520 QWHSIID QWHCATYP QWHSSTCK,
045525 INCODE=
045530 %DB2RSELA;
This error caused PMACC01 report to fail
-There are two occurrences of this pair of lines:
+1 "&SORT3 - " &SORT3 $CHAR12.;
%END;
%END;
In both pairs of lines, remove the semicolon after the
$CHAR12, and insert a new line with just a semicolon
between the two %END statements, so they now read:
+1 "&SORT3 - " &SORT3 $CHAR12.
%END;
;
%END;
This error occurred with PMACC02 if less that three
SUMBY= variables were specified.
Change 12.327 -ANALTALO failed with VARIABLE NOT FOUND because it had
ANALTALO not been updated for the changes in ASUMTALO variables.
TRNDTALO Now, ANALTALO works with ASUMTALO/TRNDTALO datasets.
Mar 19, 1995 -TRNDTALO failed because a comma was missing after the
calculation of DURATM.
Thanks to Glenn Harper, Memorial Hospital Systems, USA.
Change 12.327A ANALCNCR failed when invoked by ANALTAPE or ANALMTP, but
ANALCNCR the logic error was only in ANALCNCR. Many lines were
Mar 19, 1995 changed, but the ANALMTP error can be eliminated by just
adding OUTSUMRY=SUMMARY, to the %ANALCNCR invocation in
ANALMTP.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Thanks to Steve Harris, Tennessee Valley Authority, USA.
Change 12.326 Support for Memorex/Telex LMS Version 3.1 (INCOMPATIBLE,
FORMATS because a two-byte field was expanded in place to four
VMACLMS bytes in many records). Two new variables are added to
Mar 19, 1995 LMSAINT dataset, and twenty-four new variables are added
to the LMSINIT dataset.
New values for existing MGLMSxx formats were added, but
there were no new formats created.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 12.325 Cross-System DASD Analysis Report columns ran together
ANALPATH when I changed LCU from $HEX2 to $HEX4 in MXG 12.12, so
Mar 19, 1995 Dan spread the columns in this report revision.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Revised: See Change 13.077.
Change 12.324 In IMACICSA, variables STCTIME/STCTIMTR are now formatted
IMACICSA TIME12.2 instead of DATETIME21.2, STCTIMTR is now INPUT
VMAC110 as PIB4.3 instead of PDTIME4., a "LENGTH STCTASK $2;" was
Mar 17, 1995 added, and after the INPUT of STCDB5S &PIB.4., insert
"@; INPUT" (so that either the CPIC statistics or the
Appendage stats are read first, but then STCRUT and other
fields are read for either CPIC or Appendage records).
-In VMAC110, JCSPTIME's PDTIME4. input was changed to
HH &PK.1. MM &PK.1. SS ?? &PD2.1 and then
IF SS GT 0 THEN JCSPTIME=HMS(HH,MM,SS);
Thanks to Jens Schlatter, EDP Consulting Schlatter, GERMANY.
Change 12.323 -The argument 2*_I_ in the SUBSTR function was invalid
VMAC80A when _I_=16; the argument should be 2*_I_-1.
Mar 17, 1995 -STOPOVER occurs if RACFDLN is GT 27 in WHEN (12) logic.
Inside the WHEN (12) logic, inside IF RACFDLN GE 27 ...
insert SKIP=RACFDLN-27;IF SKIP GT 0 THEN INPUT +SKIP @;
to prevent STOPOVER abend when there are more than three
IGNORED IDnames. MXG now keeps first six names.
-Segments with RACFTYPE=32,42, or 44 are now protected so
you won't get "SKIPPED SEGMENT" messages for those data
segments.
Thanks to Tom Parker, Hogan Systems, USA.
Change 12.322 INPUT with QWSBNM after IF NRQWSB GT 9 was replaced with
VMACDB2 INPUT +SKIP @; because if there were ten destinations,
Mar 17, 1995 the tenth destination name replaced the first dest name.
This was not likely to have been noticed, but is fixed.
Also, the reference to Change 12.179 inside VMACDB2
should have referenced Change 12.279.
Thanks to Tom Parker, Hogan Systems, USA.
Change 12.321 CICS/ESA Statistics Dataset CICDS from CICS/ESA 3.3.0 or
VMAC110 4.1.0 can have values in DS3TWT,DS3TDT,DS3TCT,DS3ACT,
Mar 17, 1995 DS3SWT,DS3SCT that are 4096 times too large. Ten lines
that should have been added by Change 12.030 were lost.
This error was overlooked because the Concurrent TCB time
in my test statistics records was essentially zero. A
separate coding error also caused DSGTDT to be wrong; the
statement DSGTDT=DSGTWT/4096 obviously should have had
DSGTDT on the right! Since CICDS is used to create the 6
PDB.CICxxxRV datasets, those datasets will also be wrong
if the DS3 variables are non-zero. Note that only the
CICS Statistics data was affected - the transaction times
in CICSTRAN were not affected by this error.
Thanks to Waldemar Schneider, SAS Europe, GERMANY.
Thanks to Tom Parker, Hogan Systems, Inc, USA.
Change 12.320 Many Landmark CICS Version 1.3 variables were not INPUT
TYPETMON because I used an early DSECT that showed many of these
Mar 17, 1995 fields as reserved. When Svend raised the question, I
found I had a more recent DSECT, and now there are 15 new
variables in dataset MONITASK, and 79 new variables in
dataset MONISYST. This revision has been validated with
sample data for reasonableness, but please validate with
reasonableness checks of your own data records!
Thanks to Svend Henningsen, SMT Data A/S, DENMARK.
Change 12.319 Variables F20LHST F20RHST FTPCRHST FTPCLHST were added to
VMACILKA the LENGTH DEFAULT=4 statement with length 5, because
Mar 17, 1995 4-byte numeric addresses are truncated when they are
stored in only 4 bytes.
Thanks to ???, Nordbanken, USA.
Change 12.318 ANALDB2C error: NO MATCHING IF THEN ELSE CLAUSE because
ANALDB2C the statement END: should have been END; (i.e., change
Mar 17, 1995 the colon to a semi-colon.
Thanks to David Callahan, Caterpiller, USA
Change 12.317 A local external writer type 6 with invalid SMF6LN1 value
VMAC6 caused INPUT STATEMENT EXCEEDED RECORD LENGTH error. The
Mar 17, 1995 line IF SUBSYS='JES2' AND SMF6LN1 GT 30 THEN DO; is now
.... SMF6LN1 GT 30 AND SECTIND='1.......'B THEN DO;
Thanks to Joe Schwartz, CIGNA, USA.
Change 12.316 The DCOLLECT output file LRECL has been increased to 644
JCLDAYDS but this JCL example contained LRECL=264, which caused an
Mar 17, 1995 ABEND. Remove the DCB attributes from the JCL, so the
DCB attributes will be picked up from the data.
Thanks to Glenn Harper, Memorial HealthCare System, USA.
Change 12.315 Landmark CICS records in version 8 format (TYPEMON8)
IMACMONI has these errors:
TESTOTHR -Syntax error (in MXG 12.12 only) - NO MATCHING DO/SELECT.
TYPEMON8 Change the line in member TYPEMON8
Mar 17, 1995 that now reads: ... AND MRONUM GT THEN DO;
to read: ... AND MRONUM GT 0 THEN DO;
This got past my Q/A test because member TYPEMON8
was not tested; when I meant to add member TYPETMON
(support for version 1.3) to my test member
TESTOTHR, I accidentally replaced TYPEMON8. Now,
both TYPEMON8 and TYPETMON are tested!
-Using TYPEMON8 to read TMON 1.3 records converted to 8.1
format caused USER ABEND 1099, and "IT APPEARS YOU ARE
TRYING" message, due to the new TMMDREC='TD' DSA Interval
record, which did not exist in version 8.1!
Change the line in member TYPEMON8 that now reads:
IF TMMDREC='DD' OR TMMDREC='HH' THEN DELETE;
to read:
IF TMMDREC='DD' OR TMMDREC='HH' OR TMMDREC='TD'
THEN DELETE;
-Now that I know that the TD record exists in converted
version 8 records created from TMON 1.3 records, I copied
creation of dataset MONIDSA from TYPETMON into TYPEMON8,
so that you will get the new DSA data from the converted
records, but it would be much wiser if you had used the
TYPETMON support to read the native TMON 1.3 records and
thus avoid the unnecessary conversion step. Note that
member IMACMONI was also changed (the _LMONDSA/_KMONDSA
macro definitions were added), so if you have a tailored
member IMACMONI in your USERID.SOURCLIB, you will need to
retrofit your tailoring with the new IMACMONI member.
-Also, the DO group beginning with
IF LENMONI='1... ..'B THEN DO;
was relocated to follow
IF TMMDREC='DD' ... 'HH' ... 'TD' THEN DELETE;
because one XA site found the LENMONI bit on in an 'HH'
record (causing USER ABEND 1099), even though the site
had the EXITMON6 decompression exit installed. I'm still
investigating, but relocating the DELETE to be prior to
the LENMONI test eliminated the ABEND.
Thanks to Carl Sommer, SAS Institute Cary, USA.
Thanks to Jim Swartz, Dale Electronics, USA.
Thanks to Svend Henningsen, SMT Data A/S, USA.
===Changes thru 12.314 were included in MXG 12.12 dated Mar 1, 1995===
(but were were not printed in MXG Newsletter TWENTY-SEVEN)
Change 12.314 IMACEXCL (for CICS Exclude/Include logic) is updated with
IMACEXCL new _CICXCU4 for CICS/ESA 4.1.0 records; the old _CICXCUS
Feb 24, 1995 macro for Version 3 won't work with the restructured data
records in Version 4 - you get no error, but bad values,
most notably for TASCPUTM.
Thanks to Simon Wu, Southern California Edison, USA.
Change 12.313 TCP/IP error INVALID DATA FOR TELLOGFT encountered at one
VMACTCP site; the 8-byte field added by APAR PN34837 did not have
Feb 23, 1995 a valid date-time-stamp. To eliminate the message, I put
double questionmarks between TELLOGFT and SMFSTAMP8.
Thanks to Barbara Rask, University of North Dakota, USA.
Change 12.312 INPUT STATEMENT EXCEEDED for LANSPY type D record because
VMACNSPY the path segments were not correctly skipped. Inside the
Feb 23, 1995 IF LDLANMAX GT 0 THEN DO; group, after the @;, insert
OFFNSPY=OFFNSPY+LDLANMAX*28;
to move the pointer over the path segments.
Thanks to Mr. Dechamps, R&V Versicherung, GERMANY.
Change 12.311 Early MXG 12.12 only (dated 20Feb95). IEBUPDTE step had
VAXPDS return code of 4, because the "./" in VAXPDS should have
Feb 23, 1995 been changed to "xy".
Thanks to Glenn Harper, Memorial Hospital, USA.
Change 12.310 RMF CPU reporting is now consistent with new APAR OW07986
ANALRMFR (MVS/ESA 5.1) or OW05435 (MVS/ESA 4.3). "CPU ACTIVITY"
Feb 22, 1995 REPORT column showing the CPU busy time percentage (
column header "BUSY TIME PERCENTAGE") has been replaced
by a column showing now the LPAR CPU utilization (new
column header "LPAR BUSY TIME PERC"). In case of an LPAR
system this column contains the same values as in
previous versions. In case of a basic mode system, dashes
are shown here. The previous column showing the wait time
( column header "WAIT TIME PERCENTAGE") has been replaced
by a column showing the MVS view of the CPU utilization (
column header "MVS BUSY TIME PERC"). The wait time is no
longer shown on this report.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 12.309 Xerox Print Services Manager SMF record has been further
FORMATS enhanced and validated. The first 3 downtime segments
VMACXPSM are kept (if you find you need more, let me know), and
Feb 22, 1995 the font list and forms list are now decoded.
Change 12.308 Support for RMDS 2.1 has now been validated with read SMF
VMACRMDS data; some datetimes were missing because all of the YYYY
Feb 22, 1995 inputs should have been &PIB.4. instead of &PIB.2.; the
input of RMDSALC and RMDSPAGE for RMDSORG='1' should have
been &PIB.4. instead of &PD.4. (I guessed wrong!); and
some datetime calculations in the old 1.3,1.4 code were
moved to eliminate missing value messages on the log.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 12.307 Some dates/times were wrong because Change 10.176 was
VMACFTP only partially implemented; PIB4. should have been PIB4.2
Feb 20, 1995 and the DATEJUL() was missing in DHMS functions.
Thanks to Waldemar Schneider, SAS Europe, GERMANY.
===Changes thru 12.306 were printed in MXG Newsletter TWENTY-SEVEN=====
Change 12.306 Support for DB2 Trace Records sent to GTF is provided by
REXXDB2 this user contribution, in REXX, which will read the GTF
VMACSMF records (which are uniquely segmented) and reconstruct a
Feb 18, 1995 valid, un-segmented SMF format type 102 record that can
be processed by conventional MXG code. (DB2 type 102
records that happen to fit in one 255-byte segment can
already be processed, but most of the interesting data is
in longer records, and I had contracted with a slick ASM
programmer to write me an Assembly routine to do exactly
what this slick REXX program does!) I have modified the
GTF macro in VMACSMF to at least now tell you that a
spanned record was deleted - Clyde was justifiably
frustrated when he first tried to use vanilla MXG code
against GTF data, and MXG did not tell him that those
spanned records could not be handled and were deleted!
Thanks to Clyde Thompson, Australian Taxation Office, AUSTRALIA
Change 12.305 -ANALDB2R provides DB2 Version 3.1 reports for PMACC02
ANALDB2R (Accounting Detail Report), PMSTA02 (Statistics Summary
ASUMDB2A Report), and PMSTA01 (Statistic Detail Report), the last
TRNDDB2A now uses the DB2STATS. PMACC02 does not yet include
TRNDDB2B detail stats on each of the new buffer pools; that will
TRNDDB2S be available in the next MXG release, as will package
TRNDDB2X report support. These new DB2 reports take many more
VMACDB2 pages per group, so be cautious and select carefully!
Feb 20, 1995 -ASUMDB2A, TRNDDB2A, and TRNDDB2B were changed to now keep
Oct 19, 1995 new DB2 3.1 variables needed for ANALDB2R reports.
-TRNDDB2S now uses PDB.DB2STATS instead of the (archaic
DB2STAT0, DB2STAT1, and DB2STAT2 datasets, (ANALDB2R also
now uses PDB.DB2STATS for statistics reports). Instead
of creating the old TRNDDB20/TRNDDB21 datasets, TRNDDB2S
now summarizes into TREND.TRNDDB2S. You can convert your
old TRNDDB20/TRNDDB21 datasets into the TRNDDB2S with a
one-time execution of the UCVRTDB2 program.
-New member TRNDDB2X trends the eXtra statistics for each
buffer pool from PDB.DB2STATB data. Revised 10/19/1995.
-VMACDB2 was changed to add variables to DB2ACCTB that are
needed by ANALDB2R (and should have been kept already!).
-The DB2STAT0, DB2STAT1, DB2STAT2, TRNDDB20, and TRNDDB21
datasets should be replaced in your reporting with either
PDB.DB2STATS or TREND.TRDNDB2S, as only these latter two
datasets will continue to be enhanced. Fortunately, the
statistics datasets are physically small, so keeping the
redundant data in your PDB is better than removing it now
(and possibly causing an avoidable ABEND)!
Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.304 XMXGSUM, a much faster and leaner replacement for VMXGSUM
XMXGSUM has all errors fixed (the last fix UPCASED all variables)
Feb 18, 1995 and has been heavily tested. However, because VMXGSUM is
so pervasive in MXG ASUM/TRND/ANAL members, I decided to
leave VMXGSUM intact and deliver XMXGSUM as a separate
member so you would not be accidentally burned. If you
have lots of CICS/DB2 data being summarized by MXG, I
strongly urge you to test XMXGSUM in place of VMXGSUM,
because it runs much faster and uses much less CPU and
DASD when there are lots of data and variables read and
only a few kept. (You can test simply by copying XMXGSUM
into your USERID.SOURCLIB, renaming it therein to VMXGSUM
and running your test programs, because internally it is
VMXGSUM!). However, do not use OPTIONS OBS=nnn with the
new XMXGSUM without reading this detail techie note:
XMXGSUM figures out what variables are really needed
and what variables exist to create a KEEP= list. We
use a PROC CONTENTS of all of the datasets in the
INDATA= parameter to create the list of unique
variable names. If OPTIONS OBS=nnn is in effect, and
if nnn is less than the total number of variables,
unpredictable failures will occur (or no failure with
incorrect values!). created. To prevent these
problems, never set the OBS= to be less than the sum
of the number of variables in the combined INDATA=
datasets or (a better choice) set OBS back to MAX
after selecting the data you want to summarize. A
dataset with 0 obs and a non-existent dataset look the
same (because there is no SAS facility to determine if
a dataset exists). If the dataset does not exist,
then PROC MEANS abends because its expected variables
are not found. Now, an observation is forced so the
number of variables can be used to tell if you made an
mistake (i.e., you referenced a non-existent dataset
for input) or if there just happened to be no
observations (when we go ahead and create the expected
zero-obs output dataset).
Thanks to Chuck Hopf, Merrill Consultants, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 12.303 Analysis of tape mounts pending using the MXG Tape Mount
ANALMTP monitor TYPETMNT data and the new %ANALCNCR concurrency
Feb 18, 1995 analysis tool gives you average and maximum number of
tape mounts outstanding across the day, with built-in
graphs! A fine example of the power of %ANANCNCR!
Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.302 ANALCNCR enhanced to permit multiple MAX= variables and
ANALCNCR multiple COUNT= variables. If no MAX= is used and there
Feb 18, 1995 are COUNT= variables, then the MAX variables will be
MAX1-MAXn where n is the number of COUNT= variables used.
MAX= is positional, and the variables listed will be the
MAX of the same positioned variable in the COUNT= list.
If you don't use MAX= and ask for a summary, then the
MAXCNCR variable will contain the MAX value for the
things you are counting.
Change 12.301 Support for VAX Accounting Data and even some Performance
VAXPDS reports are provided in this user contribution from the
Feb 18, 1995 Australian creators of "The Bill". Member VAXPDS is
really a 12-member PDS in IEBUPDTE format (the first few
lines give you the JCL example to create MXG.VAX.SOURCLIB
PDS from member VAXPDS. I have not tested this code, but
it is self explanatory (read comments in each member to
understand what it does) and has been used by several VAX
sites in Australia, so I anticipate no surprises!
Thanks to Brian Jennings, Pacific Management Systems, AUSTRALIA.
Change 12.300 SYNCSORT has permitted up to 32 SORTWORK DDs, but MXG did
VMACSYNC not decode statistics for 13th-32nd. I have added code
Feb 17, 1995 to INPUT the 13th-32nd sets of variables, but I did not
add the new variables to the KEEP= list in VMACSYNC, as
I really don't think anyone uses that many DDs! If you
really need the extra variables, they can be added using
the _KTYSYNC macro in IMACSYNC (see Change 10.175 for the
general instructions for using _K macros to add/drop
variables to MXG datasets). This was only an MXG change;
while there is a new release 3.6 of SYNCSORT, it made no
changes to their SMF record.
Change 12.299 Support for CICSAO user SMF record written by CICSAD,
EXTYCIAO added by APAR PN06426, provides CICS availability info,
FORMATS in new dataset TYPECIAO, reporting for each CICS region
IMACCIAO under CICSAO control when CICSAO started or shutdown a
TYPECIAO particular region, and when that CICS actually completed
VMACCIAO that function. If the region halts (becomes unusable) or
Feb 15, 1995 is unhalted, that event too is recorded.
Change 12.298 The JCL example for the MXGTMNT PROC did not contain an
ASMTAPES //SNAPOUT DD SYSOUT=C
Feb 15, 1995 causing the monitor to fail at startup. Now it does.
Thanks to Shaheen Pervaiz, Acxiom, USA.
Change 12.297 SAS errors "OBJECT FILE OUT OF SPACE" is an indication
CONFIG that you do not have enough virtual storage, either the
CONFIG07 MEMSIZE in your CONFIG member is too small or the REGION
CONFIG08 parameter on your JOB card is too small. MXG 12.12 does
Feb 15, 1995 require slightly more virtual storage (because of the
additional datasets/variables for MVS/ESA 5.1), and if
you were just below the limit prior to MXG 12.12, you may
fail just due to MXG 12.12. I have raised the default in
CONFIG to 48M to hopefully minimize this occurrence.
Thanks to Shaheen Pervaiz, Acxiom, USA.
Change 12.296 DEBUG messages were printed on the SAS log for some MIM
VMACMIM records; the PUT statement writing these messages should
Feb 15, 1995 have been deleted.
Thanks to Shaheen Pervaiz, Acxiom, USA.
Change 12.295 Support for RDS, Remote Device Support, for Network
EXTYRDS1 Systems Corp. DXE Channel Extenders user SMF record
EXTYRDS2 creates seven datasets:
EXTYRDS3 TYPERDS1 - Device Class Descriptions
EXTYRDS4 TYPERDS2 - Path Descriptions
EXTYRDS5 TYPERDS3 - Device Throughput
EXTYRDS6 TYPERDS4 - Network Throughput
EXTYRDS7 TYPERDS5 - RDEVADPT Errors
IMACRDS TYPERDS6 - HOSTADPT Errors
TYPERDS TYPERDS7 - LINK Network Errors
VMACRDS Activity counts, bytes transferred, and other statistics
Feb 15, 1995 as well as errors are provided in these datasets.
Thanks to Christopher B. Calvin, Ahold Information Services, USA
Thanks to Benny Maynard, Ahold Information Services, USA
Change 12.294 Support for SAR Cross Memory/VTAM Region Session Logoff
EXTYSARS user SMF record contains statistics on storage used above
IMACSARS and below, CPU time, Getmains, etc., in new dataset
TYPESARS SARSESSN. Note that this is a separate SMF record that
VMACSARS can be created by SAR; the other record created by the
Feb 14, 1995 SARSRQU3 exit is supported by member TYPESAR et al.
Thanks to Miguel Trujillo, Salomon, Inc, USA
Thanks to Dov Brosh, Salomon, Inc, USA.
Change 12.293 CPU Utilization for each Performance Group is provided in
ANALPGNS this new, simple analysis algorithm which merges RMFINTRV
Feb 12, 1995 with TYPE72. Two measures of PerfGrp utilization are:
PGPCTCAP = Percentage of Capacity used by PERFGRP.
PGPCTUSE = Percentage of Active Time used by PERFGRP.
The denominator for Percent of Capacity is Duration times
Number of CPUs Online, while the denominator for Percent
of Active Time is the Capacity Duration times PCTCPUBY.
Which number you use depends on whether you want to know
how much of the installed capacity was used by a PERFGRP,
or how much of what was used by everyone was used by a
PERFGRP, so both numbers are provided. This sample will
likely be expanded into a full-blown %ANALPGNS member
with bells and whistles and summarization, but the basic
algorithm is provided in these initial 48 lines.
I have described how to do this scores of times; with
hindsight, this member should have existed years ago!
Thanks to Virginia Tsai, SAS Institute, TAIWAN.
Change 12.292 Support for OS/400 Version 3.1.0 AS/400 Performance Data
EXQAPIO1 records: completely INCOMPATIBLE!! Instead of appending
EXQAPIO2 new fields at the end of the existing records, new fields
EXQAPIO3 were inserted in almost every record, and some record's
EXQAPIO4 fields were reordered even when no new fields were added!
IMACQAPM Previously, MXG logic used LENGTH to identify the OS400
TYPEQAPM Version and hence data format, but QAPMDISK record was
VMACQAPM reordered with no change in LENGTH, so MXG now uses the
Feb 12, 1995 variable ASLEVEL (input from QAPMCONF and retained, which
is why _TQAPCON must always be executed first) to detect
data format.
While almost every other record was also changed, that
change was to insert two 2-byte packed decimal fields for
Bus Number and Bus Address. But those IOPB/IOPA variables
were already created in MXG from the existing 1-byte "IP
Address" (bits 0-2 = IOPB, bits 3-7 = IOPA, easily INPUT
with SAS's BITS informat)! Apparently, it was so hard
for other OS/400 programmers to decode these simple bit
values (dare I say "objects"?), that IBM Rochester had to
convert the bits to numbers and create two new fields for
them (which, of course, were then inserted, instead of
being appended to the end for compatibility)!.
And IBM's pub SC41-3306-00, pp A-14 to A-30, for the
QAPMSYS record, has completely wrong "Buffer Position"
values starting with location 507 of this 3090-byte
record - that was real fun to sort out!
All this from winners of the Malcolm Baldridge award!
In spite of the OS/400 developers inability to provide
compatible records across version changes, there is a
wealth of new data added to the QAPMSYS and QAPMJOBS
datasets, and the new QAPMIOPD record creates four new
datasets from SNADS:
QAPMIOP1 - File Server I/O Processor Pipe Task
QAPMIOP2 - OS/2
QAPMIOP3 - HPFS386
QAPMIOP4 - Lan Server
IBM now says QAPMIOP1 is Internal Use Only, and its
counters were incorrectly documented, and that even
if they were, you can't do anything about them, and
its description will be removed. However, since my
code was already done before I knew that fact, I
decided to leave the code in place with this caveat!
MXG Install note: YOU MUST ADD //QAPMIOPD DD DUMMY to
your existing QAPM job's JCL when you install MXG 12.12,
or that existing job will fail with a JCL error. Then,
when you install V3.1, you can change the DUMMY to the
real dataset, and MXG will automatically create obs in
the new QAPMIOPn datasets.
Yes, this is an incompatibility between MXG 11.11 and
MXG 12.12, that I could have avoided by commenting out
the invocation of _TQAPIOP in member TYPEQAPM, but then
you would have had to modify the source code to create
observations in the future, so I chose this JCL change
as the lesser of the two choices.
As of Newsletter 27 press time, the new 3.1 code had not
been tested with 3.1 data; only 2.2 data was available.
Change 12.291 ERROR. INVALID OFFSETS IN USER SEGMENTS with Landmark
TYPEMON8 CICS/ESA Version 1.1 records converted back to Version 8
TYPETMON format may result because MXG's test is true when the
Feb 11, 1995 offset in the record is greater than record length even
when there is no segment - the number of segments must be
added to the test. The three lines in TYPEMON8 now read:
IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 AND FATNUM GT 0 ..
IF UATCOL+UTNUM*TAUATLEN GT LENGTH+1 AND UTNUM GT 0 ..
IF MROCOL+MRONUM*TAMROLEN GT LENGTH+1 AND MRONUM GT 0 ..
The one line in TYPETMON now reads:
IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 AND FATNUM GT 0 ..
Thanks to Bill Padilla, Farmers Group, USA.
Change 12.290 Amdahl MDF will produce negative/trashed CPU values if
VMAC7072 you use the same LPAR number for different LPARs. The
Feb 10, 1995 error, introduced in microcode ML 6, has been fixed in
Amdahl's ML 8.09, and your SE can show you how to define
your IOCDS with a unique Partition Number, but you must
correct the error, or your CPU busy data is invalid.
Thanks to Dean Brown, Pacific Bell, USA.
Change 12.289 Amdahl MDF has been providing real MVS CPU utilization of
VMAC7072 "this" MVS in TYPE70 dataset since their microcode ML 6;
Feb 10, 1995 Change 12.288 added the PCTMVSBY/MVSWAITM fields which
contain the MDF "CPU using" time for "this" Domain.
A new MDF option, called "Wait Complete=No Reporting",
(available for ML 6, included as a feature in ML 8.09)
can store the Real CPU Active Time (instead of Dispatch
Time) into the TYPE70PR LPAR data segments in type 70.
You can tell that the option is enabled and the CPU times
are real if LCPUWAIT='N' (not enabled, LCPUWAIT='Y'), as
the 'N' record looks like a non-wait-completion PR/SM.
(Without the option, MDF LPAR measures are "dispatch"
time, not "CPU using" time, so you had to use Amdahl's
APAF to get the real CPU busy time of other LPARS. This
new option lets you now use TYPE70PR/ASUM70PR for real
CPU measures, using APAF data for deeper analysis.)
Jul 9, 1997: See Change 15.023 for update on option.
Change 12.288 PR/SM APAR OW07986 puts "MVS Wait" time back in type 70
VMAC7072 records, so the new variables PCTMVSBY MVSWAITM and
Feb 10, 1995 MVSWAIT0-MVSWAITF report the MVS view of CPU busy/wait
contrasting with the existing variables PCTCPUBY (LPAR
dispatch perspective) and PCTCPUEF (LPAR effective
perspective). Looking at one sites numbers, it appears
that the sum of the "MVS Wait" plus the sum of "CPU Eff"
plus the "Physical LPAR" is very close to total duration,
which implies that PCTCPUBY-PCTMVSBY is the true LPAR or
MDF overhead. The text of the APAR includes a complete
discussion of the differences between "MVS CPU Busy" in
PCTMVSBY and "LPAR CPU Dispatch" in PCTCPUBY.
Thanks to Boris Ginis, BGS Systems, USA.
Change 12.287 ITRF note. Candle has corrected the problems that
VMACITRF were reported in Newsletter 26, and the blank field for
Feb 10, 1995 RNJOB, etc., are now populated (except in the TYPE= '13'x
thru '16'x Database records, which being cut from the IMS
Control Region, have no associated Job information).
A small sample of their log records post-APAR have been
validated, and I have no reason to believe there are any
further problems, but as the Newsletter went to press,
the APARs were too new to have had stress testing, so I
would appreciate feedback from active ITRF users.
There was no change to the VMACITRF code; this change is
solely for documentation.
Change 12.286 Zero observations in dataset CISIZE can occur, because
ANALSMF the logic detecting that data was held was unrobust. The
Feb 10, 1995 test IF INCI4K=0 THEN DELETE; must be expanded to
IF SUM(INCI4K,INCI8K,INCI16K,INCI22K,INCI26K)=0 THEN ....
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.285 Support for Type 99 Subtype 1 has been added, creating
EXTY99TT two new datasets:
EXTY99U1 TYPE99TT - Trace Table Entries
VMAC99 TYPE99_1 - System State Information
Feb 9, 1995 Don found this data so useful in his CPExpert product,
that he shared his coding for this record!
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 12.284 Support for IMF 3.1 (for IMS 5.1) is already in MXG 12.12
VMACCIMS because Boole expects there will be no significant change
Feb 9, 1995 in the format of the IMF records in their new version.
Some old MVS fields may be zero when MVS 5.1 is in Goal
Mode, but the fields will still be there, so the MXG code
is expected to be compatible.
Change 12.283 MXG 12.07 Only. TCP/IP records cause INVALID DATA FOR
VMACTCP VARIABLE NEW because the word NEW was accidentally left
Feb 8, 1995 in columns 1-3 of line 020100. Remove "NEW". (NEW was
left as a marker that I needed to add the new variable,
FTPSTRCT to the LABEL and KEEP= lists, so not only did I
fail to remove the NEW, I also failed to add FTPSTRCT
until this change. The syntax check passed because NEW
was just another variable to be INPUT; only when real
data records were read did the error surface.)
Thanks to Richard Clary, Entergy Services, USA.
Change 12.282 Support for Velocity Software's XAMAP Version 2.2 added
VMACXAM many new variables for VM/ESA 2.2, and a few variables
Feb 8, 1995 were renamed. This code has not been tested with actual
data. The new fields were added at the end of the record
so their new version appears to be compatibly made.
Change 12.281 ANALRACF's problem with PROC TRANSPOSE error will not be
ANALRACF corrected, because the enhancements in Change 12.280
Feb 7, 1995 eliminate the need for ANALRACF. The real error was in
my original design of TYPE80, which creates one
observation for each segment in each type 80 record, and
ANALRACF was one user's solution to rebuild each logical
event from the pieces; TYPE80A creates an observation for
each event, solving the need (I believe) for ANALRACF.
Change 12.280 RACF TYPE80A has always decoded RACF events, but this
EXTY8009 enhancement adds new datasets that decode RACF Commands
EXTY8010 that have been requested by Security Administrators (so
EXTY8011 they can generate RACFRW reports from MXG datasets!).
EXTY8013 Seven new datasets are added by this change:
EXTY8014 Dataset Command
EXTY8019 TYPE8009 - ADDGROUP command
EXTY8023 TYPE8010 - ADDUSER command
IMAC80A TYPE8011 - ALTDSD command
VMAC80A TYPE8013 - ALTUSER command
Feb 7, 1995 TYPE8014 - CONNECT command
TYPE8019 - PERMIT command
TYPE8023 - REMOVE command
TYPE80CM - RACF commands not decoded above.
Most of the fields in these command records are decoded,
but some are not; there are 2- and 4-byte bit maps (eg.,
for Keywords specified on the command, where one bit
is used per keyword), and rather than creating 32 or 64
more variables, I chose to store the field as a character
variable with $HEX format to save DASD space. Of course,
this means you must learn which bit does what, and thus
you must become familiar with IBM Table 3, "Data Type 6
Command-Related Data" in the RACF Macros and Interfaces
manual, SC28-1345, in SMF Records chapter, until I have
time to document these bit-maps in member ADOC80A.
TYPE80A should replace TYPE80/ANALRACF, because TYPE80A
creates an observation for each event, whereas TYPE80
creates an observation for each segment in each event,
and ANALRACF was created to reconstruct the events from
the segments! This code has been tested with RACF 1.9.2
data.
Thanks to Richard Banks, Texas Comptroller of Public Accounts, USA.
Change 12.279 DB2STATS can be used to audit if DB2 SMF records were
DIFFDB2 lost. DB2 counts log records written and not-written in
VMACDB2 two ways: by destination (GTF, SMF, etc. in MXG variables
Feb 19, 1995 QW1Bxxxx-QW9Bxxxx) and by writer (accounting, audit, etc,
in MXG variables QWS1xxxx-QWS8xxxx). With a simple:
PROC PRINT DATA=PDB.DB2STATS;
VARIABLES QW1B: QW2B: QW3B: QW4B: QW5B: QW6B:
QW7B: QW8B: QW9B: ;
you can scan the QWnBNM (Destination Name) for SMF, and
then examine QWnBSRNW for that "n" to determine if any
SMF records were lost. If there were records lost, you
can then use a simple:
PROC PRINT DATA=PDB.DB2STATS;
VARIABLES QWS1: QWS2: QWS3: QWS4: QWS5: QWS6:
QWS7: QWS8: ;
to examine which IFCIDs (QWSnIID) had lost records, and
see whether accounting, audit, stat or trace records were
not written. See MVS Technical Notes in Newsletter 27
for a discussion of why DB2 might lose SMF records.
Impress your auditors with your knowledge of the exposure
and that it is detectable!
-Variable QWACFLGS is now INPUT $CHAR2. (it was $CHAR1.)
and this also corrects the value of QWACPKGN.
Thanks to Chuck Hopf, MBNA, USA.
Change 12.278 ERROR.TYPE110.SUBTYPE 2, STID=57, SKIP=84 message and hex
VMAC110 dump on the log with CICS/ESA 3.3.0 results because there
Feb 7, 1995 are undocumented bytes observed at the end of record.
This diagnostic message has no effect on the type 110
processing, so your datasets were built correctly (it's
there so I can detect if IBM adds new, useful data, but
in this instance, they simply added nulls!), but the dump
on the log and the message can be eliminated:
Inside the DO group IF STID=57 THEN DO;
replace IF SMFPSRVR EQ 33.0 THEN SKIP=SKIP-336;
with IF SMFPSRVR EQ 33.0 THEN DO;
SKIP=SKIP-336;
IF SKIP GT 0 THEN DO;
INPUT +SKIP @;
SKIP=0;
END;
END;
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 12.277 Support for ACC/SRS, Allocation Control Center/Space
EXTYACC Recovery System (from Mitchem Technologies) user SMF
IMACACC record. SRS is like STOPX37; an SRS record is written
TYPEACC whenever SRS protected an x37 ABEND by adding secondary
VMACACC space. ACC controls dataset allocation and lets you
Feb 6, 1995 change anything on a DD card. The record is written when
either SRS recovers, or when ACC sends a message.
===Changes thru 12.276 were included in MXG 12.07 dated Feb 6, 1995===
Change 12.276 Continued enhancement to IBM-like RMF reports. The MXG
ANALRMFR device reports can be selected by:
Feb 5, 1995 SG =, Storage Class selection
DN =, Device Number selection
LCU=, Logical Control Unit selection
and Coupling Facility report can be selected by:
RSYSPLX=. Sysplex report selection.
Format MGRMFA3 was removed for variable LCU in the I/O
queueing report (it caused hex instead of decimal values)
and this edition supports more than two IOPIQIDs (using
PROC TRANSPOSE and ARRAY processing).
Change 12.275 The old analysis of tape drives, using PDB.STEPS was
ANALTAPE revised to use the new ANALCNCR macro to speed up the
Feb 5, 1995 analysis, but using the ASMTAPES MXG Tape Allocation
Monitor records and datasets PDB.TYPETALO and member
ASUMTALO is strongly recommended as more accurate.
Change 12.274 New analysis of initiator concurrent use (i.e., how many
ANALINIT jobs are concurrently in initiation), using ANALCNCR (see
Feb 5, 1995 Change 12.272). Unfortunately, there is no way to know
Feb 19, 1995 which initiator is actually used, but at least we can
determine how many jobs are waiting or running in any JES
job class. There are also some limitations to initiator
analysis. Jobs submitted into HOLD cannot be included in
measurement of jobs waiting, because we do not know when
the job was released from hold, so these jobs are deleted
(TYPERUN=HOLD) from the analysis. (Note that jobs that
are read-in and then later placed in HOLD cannot be
detected and are thus inadvertently included as queued.
You might be able to establish a criteria for queue time
that would let you identify these probably-held jobs -
like queue time greater than one hour for 15 minute job
class - and then delete these exceptions from analysis.)
For Duplicate Jobname hold, the job is not counted in the
input queue until the previously-initiated, same-named
job has ended. Finally, the analysis only applies if the
job observation in PDB.JOBS actually completed execution;
i.e., only if INBITS contains a J in the third position.
The analysis first separates held jobs from jobs to use,
and then invokes %ANALCNCR twice to count the number of
jobs in execute/queued/held/samename, and then these 4
datasets are merged for the report. Buckets are created
for distribution values of job counts, and you can change
the number and values of the buckets. The default values
are 5, 10, 15, 20, 25, 30 , 35, and > 35 jobs. ANALINIT
is designed for MXG's PDB.JOBS, but it shows how "open"
MXG routines are to point out that one MICS and MXG user
used ANALINIT with MICS's BATJOBxx dataset, simply
by replacing these MXG variable names with their MICS
counterparts:
MXG Variable MICS Variable
READTIME RDRTS
JINITIME STARTTS
JTRMTIME ENDTS
TYPRUN='HOLD' JOBHOLD GT 0
TYPETASK not applicable
INBITS not applicable
RDRTM JOBRDRTM
Thanks to ???,???, USA, who raised the question at CMG.
Change 12.273 Complete revision of the summarization of Tape Allocation
ASUMTALO using the ASMTAPES Tape Mount and Allocation monitor now
TRNDTALO uses ANALCNCR (See Change 12.272). Early test sites that
Feb 5, 1995 have previously used ASUMTALO/TRNDTALO will need to go
Feb 20, 1995 back and reprocess TYPETALO with ASUMTALO, because the
earlier version of ASUMTALO/TRNDTALO kept averages, but
this version keeps totals (like other ASUM... members).
In ASUMTALO, SAS Compression is turned off, just in case
you had turned it on. Because few variables are kept,
compression saved no DASD space, but caused a significant
increase in CPU time, 230 to 590 seconds with a million
observations as input. Because allocations are not
written until termination, TRNDTALO re-drives the week's
detail in TYPETALO back through ASUMTALO to eliminate the
overlap and increase the accuracy of allocation trends.
See ADOCTALO (when complete, hopefully in MXG 12.12 but
still in progress at press time) for more discussion.
This note was added after MXG Newsletter 27:
TRNDTALO was enhanced to 'fix' the problem of tape
drive allocations that are in effect when the SMF data
is dumped. Since this would be a daily occurrence,
detail data from the WEEK.TYPETALO is resummarized in
TRNDTALO, but since ANALCNCR runs quickly, the impact
is minimal. The duration of a shift is defined as the
actual shift duration as defined in your IMACSHFT
(whether or not we found data during all intervals).
To avoid the remaining overlapping allocations causing
data perturbations, if an interval has already been
summarized (it was in last weeks TREND database) the
duration, max, and buckets for incoming records from
the WEEK.TYPETALO will be set to 0. Thus, the
averages will be correct but (for those small number
of overlapping allocations) the MAX and buckets will
be slightly less than accurate.
Change 12.272 A powerful new MXG tool for the analysis of concurrency
ANALCNCR (how many tape drives, or initiators, or programs ... are
Feb 5, 1995 concurrently being used. Previously, I used brute force
to count concurrency; an observation with a start and end
time was exploded into many observations, with the time
incremented from start to end by a delta-value, and then
observations were summed by time to count concurrency.
Thus a one-hour step record would explode into 600 obs if
the delta-value was 6 seconds. While that algorithm was
accurate, its execution required lots of DASD and time.
When someone at CMG asked about initiator usage, Chuck
used VMXGSUM and the brute force approach in an example,
but I realized that a general purpose routine was really
needed, and then remembered the algorithm in my 1973
simulator (and also recalled that an MXG user had made a
similar suggestion long ago). I gave the algorithm to
Chuck, and the result is this fine new tool: %ANALCNCR.
This concurrency algorithm, instead of exploding obs and
summing by timestamp, creates only two observations per
event, one at the start, with a positive value of the
variable to be counted, and a second at the end, with a
negative value. Then, sorting and scanning by time,
adding or subtracting counts as events occurred in time,
the number of concurrent "things" is easily counted with
no explosion in the number of observations. Furthermore,
there is no delta-interval; the clock resolution of the
timestamp automatically counts any "thing" that exists
for more than one clock interval. The performance of
ANALCNCR over the old algorithm is phenomenal; ASUMTALO
with 860,000 records took only 20 minutes elapsed and 6
minutes of CPU time; the old logic took that time for
only 8000 records! Not only is ANALCNCR a stand-alone
analysis module, it is already used in MXG members
ASUMTALO,ASUMINIT, and ANALTAPE, with more to come!
The logic creates the "detail" data set with the count
value and the duration at that count value (and the
"detail" can have fewer observations than the number of
original events!), and ANALCNCR will (optionally, but
usually) summarize the "detail" data set into intervals
(eg. hourly), as well as creating percentage-of-time
distribution values. There are even canned printed and
plotted reports in Chuck's fine piece of work.
Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.271 Further enhancements after stress tests of XMXGSUM (which
XMXGSUM will eventually replace VMXGSUM). The compiler fakers
VMXGSUM (IF X=. THEN X=.) which eliminated the UNINITIALIZED VAR
Feb 5, 1995 messages were removed, as they were causing dropped
variables to be re-created in the output data set.
If you used DATETIME=xxx and also used xxx in a MINTIME=,
MAXTIME=, or SUM= argument, xxx was inadvertently dropped
(error was introduced by Change 12.084 when the DROP of
DATETIME was added). A new argument, DSNLABEL= was added
to supply a label for the output dataset created. Lots
of effort went into the parsing logic that supports the
use of multiple input datasets that have data set options
(like IN=, KEEP=, END=), since we now force a KEEP=
option on the input datasets to improve performance and
minimize work DASD space. KEEPALL= and DSNLABEL= were
also added to VMXGSUM for consistency.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Roger Zimmerman, Kemper Financial Services, USA.
Change 12.270 DB2PM-like Locking Reports were revised, now using IFCID
ANALDB2R 172 for Deadlock/Timeouts, and syntax errors in PMLOK02
Feb 5, 1995 (missing END) were corrected, and PMLOK03 was revised.
See also Change 12.250.
Change 12.269 Preliminary support for Boole & Babbage's CMF VSAM MMR
EXCMFVAS Historical Records creates 24 new datasets, but only the
EXCMFVCA two most important datasets are complete (CMFVASRE and
EXCMFVCP CMFXDRE). Others will be supported as-requested. These
EXCMFVCX datasets are created directly from the VSAM file:
EXCMFVDI CMFVAS - Address Space
EXCMFVDM CMFVCA - Cache
EXCMFVDX CMFVCP - CPU
EXCMFVEN CMFVCX - Channel Path
EXCMFVES CMFVDI - Dataspace Info
EXCMFVIS CMFVDM - SRM Domains
EXCMFVLP CMFVDX - Device
EXCMFVLX CMFVEN - Enqueue
EXCMFVPD CMFVES - ESTORE Criteria
EXCMFVRW CMFVIS - Interval Summary
EXCMFVSC CMFVLP - LPAR/Domain
EXCMFVSD CMFVLX - LCU
EXCMFVSM CMFVPD - Page Data Sets
EXCMFVSP CMFVRW - Resolve Warnings
EXCMFVSS CMFVSC - SYSID CPU
EXCMFVSU CMFVSD - Swap Data Sets
EXCMFVSY CMFVSM - SMS Storage Group
EXCMFVWK CMFVSP - SYSID Paging
EXCMFVWT CMFVSS - SYSID Swapping
EXCMFVWU CMFVSU - SYSID Summary
IMACCMFV CMFVSY - Global SYSID
TYPECMFV CMFVWK - Workload
VMACCMFV CMFVWT - Wait/Use Summary
Feb 18, 1995 CMFVWU - Wait/Use
Feb 23, 1995 See comments in member VMACCMFV for testing status.
There's lots and lots of data here.
Change 12.268 Support for BGS's BEST/1 I/O Monitor SMF record adds four
EXBGSCPU new datasets:
EXBGSDEV B1MONCPU - I/O Interrupts by CPU
EXBGSMON B1MONDEV - I/O Interrupts by Device
EXBGSPGN B1MONMON - Resources consumption of the B1MON itself
IMACBGSI B1MONPGN - I/O Interrupts by Perf Grp by Device
TYPEBGSI Their monitor is a powerful tool for I/O analysis.
VMACBGSI This code has only been bench checked with a hex dump.
Feb 4, 1995
Change 12.267 Support for Xerox Print Service Manager user SMF record
EXTYXPSM adds new dataset TYPEXPSM which tracks print and CPU
FORMATS resources, with lots of good quality data for managing
IMACXPSM and measuring print activity with XPSM. New records
TYPEXPSM with fixes for all reported problems is in hand, but it
VMACXPSM won't be tested before the Newsletter deadline, so check
Feb 4, 1995 this text in member CHANGES of MXG 12.12 for an update.
Thanks to Tom Bell, Rivendel Consulting, USA.
Change 12.266 If you use TYPEMON8 to process Landmark records that were
TYPEMON8 converted back to Version 8 format from CICS/ESA 1.3 data
Feb 4, 1995 TYPEMON8 fails with invalid records. Their conversion PGM
adds unexpected records at the beginning of the file with
value of 'HH' in TMMDREC. Expanding the test to read:
IF TMMDREC='DD' OR TMMDREC='HH' THEN DELETE;
appears to have resolved the problem. (Of course, the
real solution is to read the native 1.3 records with new
support in MXG's new TYPETMON member; see Change 12.151.)
Thanks to Bill Padillia, Farmers Group, USA.
Change 12.265 IMF variables ABENDSYS/ABENDUSR in CIMSPROG dataset were
VMACCIMS incorrectly documented and wrongly input. Instead of the
Feb 4, 1995 expected two-byte hex fields for each, the codes are in
a four byte field with value xxsssuuu, so the variables
are now input @90 for ABENDSYS and @91 for ABENDUSR, and
these two lines were inserted after the @; after INPUT:
ABENDSYS=FLOOR(ABENDSYS/16);
ABENDUSR=MOD(ABENDUSR,4096);
Thanks to Mel Lallement, Cessna Aircraft, USA.
Change 12.264 Support for RMDS Version 2.1 (completely incompatible!).
IMACRMDS Not only were the key values changed from alphabetic to
VMACRMDS numeric, but also the detail directory data from the
Feb 3, 1995 Archive activity no longer exists, so there are 46 fewer
variables in Version 2.1 than in Version 1.3/1.4. I have
removed those 46 variables from the KEEP= list for the
dataset TYPERMDS, but those variables are now in member
IMACRMDS, in a comment block inside macro _KTYRMDS, so
if you are still on the old release and want them kept,
you simply remove the comments and all 46 additional
(and now archaic!) variables will be kept. Seven new
variables were also added by RMDS 2.1. Fortunately, I
can recognize Version 2.1 records internally, so it is
not necessary to update macro _RMDSVER in IMACRMDS to
tell me you have installed Version 2.1 (although _RMDSVER
still is used for Version 1.2 versus Version 1.3/1.4).
The new version has set a world record for the largest
number of bytes to hold a date-time field; the previous
12-byte format (YYMODDHHMMSS) was expanded to 26 bytes:
YYYY.MO.DD.HH.MM.SS.uuuuuu (with microsecond resolution)!
Change 12.263 Support for TPX 4.0 SMF record adds 9 new TPX datasets:
EXTPXASS TPXASSIS - User starts/ends session assist session.
EXTPXCOI TPXCONFI - User inits/terms conference session.
EXTPXCOJ TPXCONFJ - User joins/leaves conference session.
EXTPXGRA TPXGRANT - User grants temporary view authority.
EXTPXPLY TPXPLYBK - User starts/ends playback session.
EXTPXREC TPXRECRD - User starts/ends record session.
EXTPXTRI TPXTRNGI - User init/terms training session.
EXTPXTRJ TPXTRNGJ - User joins/leaves training session.
EXTPXVIE TPXVIEW - User starts/ends session view session.
IMACTPX These new subtypes were added compatibly, but the TPX
VMACTPX version number change will cause an MXG error message
Feb 1, 1995 "Unrecognized TPX Version=4.0". Until you get the new
version with full support, you can circumvent that error
by inserting a line reading
ELSE IF TPXVER=:'4.0' THEN TPXVER=' 4.0';
after the similar ELSE IF TPXVER=:'3.5'.... statement.
Thanks to Warren Hayward, TJX Companies, USA.
Change 12.262 Zero observations in dataset CACHE90 with RAMAC devices
VMACACHE behind both 3990-3 and 3990-6 cache controllers because
Feb 1, 1995 CLEN (IBM field RF8CLEN) has zero value. Insert the
statement IF CLEN=0 THEN CLEN=108; after the statement
INPUT @OFFDATA+15 CLEN &PIB.2. @;
as a circumvention while we still pursue the IBM error.
Thanks to Miguel Sanchez, Florida Power and Light, USA.
Thanks to Harry Price, Florida Power and Light, USA.
Change 12.261 Support for APAR OW05435/OW07895 adds new variable
VMAC79 R793CUT to dataset TYPE793, but no format for the data
Jan 29, 1995 was given - I have guessed it's really CPU time, but am
pursuing with IBM.
Change 12.260 Reserved Change Number.
Jan 29, 1995
Change 12.259 Replacement support for TYPEZRB RMF Monitor III VSAM data
ASMRMFV for MVS/ESA 4.3 is tested for DSIG3, SSHG3, ASIG3, GEIG3
IMACRMFV & DVTG3 tables and work is planned for the UWDG3, CSRG3,
TYPERMFV & PGPER tables - both the ASMRMFV assembly program and
VMACRMFV the VMACRMFV SAS programs must be changed to support the
Jan 29, 1995 additional segments, but their DSECTS are missing
Feb 20, 1995 -RMF VSAM data is now compressed, so you must assemble the
program ASMRMFV (in member ASMRMFV) for the 2-step job:
-ASMRMFV reads the VSAM file from DDNAME of RMFVSAM,
invokes IBM's Data Set Decompression Interface Service
module (ERB3RDC) to decompress the data, and then writes
each section as a logical record to the output RMFBSAM
DDNAME, which is a temporary file on DASD.
-TYPERMFV reads the INFILE of RMFBSAM to create the MXG
datasets (all starting with ZRB....., and the dataset
names and variable names are the same as those created
by the original TYPEZRB code). In the example JCL below,
the output MXG datasets will be written to the DDNAME of
ZRBPDB because of the USER=OPTION on the EXEC statement.
-First, assemble the ASMRMFV program into YOUR.LOADLIB.
-Second, use this JCL:
//ASMSTEP EXEC PGM=ASMRMFV
//STEPLIB DD DSN=YOUR.LOADLIB,DISP=SHR
//RMFVSAM DD DSN=YOUR.VSAM.RMFIII.DATA,DISP=SHR
//RMFBSAM DD UNIT=SYSDA,SPACE=(CYL,(100,100)),
// DSN=&&BSAMRMF,DISP=(,PASS)
//MXGSTEP EXEC MXGSAS,OPTIONS='USER=PDBZRB'
//RMFBSAM DD DSN=&&BSAMRMF,DISP=(OLD,DELETE)
//PDBZRB DD DSN=YOUR.OUTPUT.PDB.LIBRARY,DISP=(,CATLG)
%INCLUDE SOURCLIB(TYPERMFV);
All storage variables that contained FRAME counts were
converted into bytes and formatted with MGBYTES format,
so installed/used values can be compared easily, and the
labels indicate "storage" rather than "frames".
Many new variables are now created in ZRBASI and ZRBGEI.
This support is preliminary, in that it has not had any
extensive usage by real users, although I have had real
data to look at. Some of the fields may be accumulated,
and it may be necessary to add a post-processing step to
de-accumulate, but I need feedback from active users to
add the polish to this (long-overdue) enhancement. I did
not compare my output with snapshots of RMF III screens,
so please verify my calculations. The next interation of
ASMRMFV will provide record selection and will print a
summary report of records found/written. Originally,
ASMRMFV was named ASMMON3.
Thanks to Don Friesen, BC Systems, CANADA.
Thanks to Danal Estes, Logical Resources, USA.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 12.258 JCLTEST6 may fail with LIBRARY MONITASK UNASSIGNED in
JCLTEST6 step TESTIBM2 or BUILDPDB, if you have changed member
Jan 27, 1995 IMACMONI to specify MACRO _LMONTSK MONITASK.MONITASK %.
JCLTEST6 invokes ASUMCICS in TESTIBM2 in member TYPE110,
and step BUILDPDB also includes ASUMCICS, and if you have
added the MONITASK ddname in IMACMONI, then both steps
will require that ddname. Although obscure, I have put
//MONITASK DD in both steps in the test job stream.
Thanks to Angela Mulcahy, UJB Financial Corp, USA.
Change 12.257 Support for TCP/IP Version 3.1 requires MXG 12.07 or
VMACTCP later to be compatible, but sites with MXG 12.01-12.06
Jan 27, 1995 can process Version 3.1 records by changing the LENGTH
Feb 3, 1995 tests (added by MXG Change 12.041)
from 200 to 204 for TCPEVENT='FTPSERVER'
from 86 to 90 for TCPEVENT='TELSERVER'.
TCP/IP Version 3.1 added FTPLCLUS (local user ID) and
FTPLCLPN/FTPRMTPN (local/remote port) in dataset
TYPETCPF (TCPSERVER), and added TELLCLPN/TELRMTPN in
dataset TYPETCPT (TELSERVER). (FTPLCLUS does exists in
records written by both TCP/IP Versions 2.2.1 and 3.1).
Thanks to Wanda Prather, The Johns Hopkins University APL, USA.
Change 12.256 Variable TRANSACT in Landmark is an eight-byte variable,
TYPETMON but only the first four bytes are used for transaction
TYPEMON8 name; the final four bytes are hex nulls ('00000000'X).
Jan 26, 1995 If you test for TRANSACT='ABCD', the test will always
fail, because SAS pads the literal 'ABCD' with blanks,
and ABCD-blanks is not equal to ABCD-hex-zeroes. You can
circumvent this effect by using the colon-modifier in the
equality: IF TRANSACT=:'ABCD' THEN ... which test true
for all values of TRANSACT that start-with ABCD. However,
I have decided to correct this problem at the source, and
have inserted the following TRANSLATE after each input in
both Landmark members:
TRANSACT=TRANSLATE(TRANSACT,' ','00'x);
Thanks to Tim Carne, Nottinghamshire County Council, ENGLAND.
Change 12.255 TYPE78CF variable PCTDIRPT is mislabeled as percent delay
VMAC78 and was miscalculated. The line
Jan 25, 1995 IF NRCMPTSM GT 0 THEN PCTDIRPT=100*PCTDIRPT/NRCMPTSM;
was replaced with
IF (CHPIDTKN+PCTDIRPT) GT 0 THEN
PCTDIRPT=100*PCTDIRPT/(CHPIDTKN+PCTDIRPT);
with new LABEL of 'PERCENT WHEN*DIRECTOR PORT*WAS BUSY'
Note: See Change 15.061, which revised this change.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 12.254 -BatchPipes/MVS variables INTBTIME/INTETIME are in the
FORMATS SMFSTAMP8 format rather than TODSTAMP8 (obvious, when
VMAC91 you have test data records!). Find their INPUT after
Jan 25, 1995 IF SMF91PRL GE 60 THEN DO; and use SMFSTAMP instead of
Feb 9, 1995 TODSTAMP8 for INTBTIME and INTETIME (SMF91IST/SMF91IET).
Note: Do not change the first INPUT of only INTETIME, as
it (SMF91INT) really is in TODSTAMP format!
The logic for INTBTIME/INTETIME/DURATM is now INPUT only
for the interval subtypes 2 and 12 (their un-cleared, non
zero values were confusing). INTETIME is set to SMFTIME
and INTBTIME/DURATM will be missing in non-intervals.
-The lines with +4 after the INPUT of SMF91IWB and after
the INPUT of SMF91OWB must be deleted to correct the
values of SMF91IEC/SMF91OEC/AFSTTIME/ALSTTIME.
-Variables SMF91SST and SMF91STR are now decoded by format
for subsystem status (ACTIVE/STARTING/STOPPING) and trace
activity (ERROR/ FUNCTION/FLOW).
-APAR PN66074 corrects the value of SMF91PLR, the Pipe's
LRECL, which was 4 too large before the APAR.
Thanks to Lawrence Jermyn, Fidelity Systems Company, USA.
Change 12.253 MXG 12.04-12.06 only. ACF2 SMF record still gets an
VMACACF2 INPUT STATEMENT EXCEEDED RECORD LENGTH error results
Jan 24, 1995 because the code added by Change 12.072:
IF ACVMFIDC GT 0 THEN DO _I_=1 TO ACVMFIDC;
must be IF ACVMFIDC GT 0 THEN DO _I_=3 TO ACVMFIDC;
(the first two authids have already been input!).
Thanks to Peter Arcoudis, NRMA, AUSTRALIA.
Thanks to Dov Brosch, Solomon, USA.
Change 12.252 MVS/ESA 5.1, Goal Mode, TYPE72GO dataset variables from
EXTY72DL the Work/Resource Manager State Samples (all start with
IMAC7072 R723R... or R72XR...) were moved from TYPE72GO into new
VMAC7072 dataset TYPE72DL (for Delay, since these state samples
BUILDPDB report workload delays), because there can be more than
WEEKBLD one pair of Begin-to-End/Execution statistics for these
MONTHBLD "Transaction Service Class" observations (R723TYPE=3).
Jan 21, 1995 For example, if the SRVCLASS is a logical service class
(i.e., for CICS transactions), and those transactions
also call on IMS, the TYPE72GO for the SRVCLASS would
have delay state sections for both the CICS region and
the IMS region delays, but the original implementation
only kept the first set of delay statistics.
Additionally, these variables only exist in R723TYPE=3
records, so creating the new dataset will save DASD by
reducing the size of TYPE72GO dataset.
And dataset TYPE72DL will only have observations if you
have Transaction Service Classes, R723TYPE=3 records.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 12.251 DB2 Transit Report failed with NOT SORTED because the
ANALDBTR pairing of the 015-016-017-018 IFCIDs in ANALDBTR added
ANALDB2R CUBTOKEN (Change 12.124), causing the S015S018,S016S018,
Jan 21, 1995 S017S018, or S018S018 data to be out of sequence with the
rest of the trace events. The fix in ANALDBTR was to add
PROC SORT DATA=SxxxS018 OUT=SxxxS018;
BY SYSTEM QWHSSSID QWHSACE QWHCCN QWHCCV BEGEVENT;
for each of the four SxxxS018 datasets at the end of the
_015PAIR macro. In addition, the design of the Transit
Report was changed to minimize DASD required. The report
previously built the TRANSIT dataset (747 variables!) and
then did a PROC PRINT; now, the report is produced with
PUT statements, and the TRANSIT dataset is now built with
only 6 variables (for a summary report of event counts).
Thanks to Dan Null, Caterpiller, USA.
Change 12.250 DB2 Locking Contention Report PMLOK02 in ANALDB2R was
ANALDBTR incorrect, and the pairing logic for 044-045-054 IFCIDs
XDB2LOCK in ANALDBTR was also incorrect. ANALDBTR has been fixed
Jan 20, 1995 while PMLOK02 is still being repaired. However, member
XDB2LOCK provides an analysis of DEADLOCK/TIMEOUT events
that may meet your needs, and can be easily tailored if
you need more details on these contention events.
Thanks to Charlie Royster, AHOLD, USA.
Change 12.249 The DEVCYL value (cylinders per device) for RAMAC devices
VMXGVTOF is different than for a native device. For native 3390-3
Jan 16, 1995 DEVCYL=3340, but for RAMAC 3390-3, DEVCYL=3339, which is
the number of cylinders that you can really use! So why
is the value different? Because native devices have 15
alternate tracks (one cylinder), which DEVCYL counts, but
RAMAC alternate track support is internal, and does not
count the extra cylinder. In VTOC processing, MXG has
always subtracted one from DEVCYL so that DEVCYL*DEVTRK
would give you the correct capacity, but for a RAMAC VTOC
DEVCYL ends up one cylinder too small!
(The impact of one cylinder of capacity would probably
be overlooked, but this site used exact values of DEVCYL
in a FORMAT to identify which model 3380/3390 was used,
and the off-by-one value fell thru their format!).
At present, there does not seem to be a way to tell that
the VTOC is from a native device versus a RAMAC device,
so I may have to resort to a table of expected sizes, but
I await IBM's response.
Thanks to Paul Polley, PolyGram Holding, Inc, USA.
Change 12.248 The //IMSSUM DD had RECFM=F,LRECL=132,BLKSIZE=132 when it
ASMIMSLG should have been RECFM=FB,LRECL=132,BLKSIZE=23364. This
Jan 16, 1995 can only help the elapsed run time! (Also, the LRECL=132
files with BLKSIZE=13200 were increased to BLKSIZE=23364,
for half track on 3380s.).
Thanks to Don Cleveland, Blue Cross and Blue Shield, USA.
Change 12.248A Cosmetic. The comments and examples for using IMACFILE
IMACFILE were revised, and the list of variables available to the
Jan 16, 1995 exit was corrected.
Thanks to Mr. Loewenthal, Zonussi Elettrodomestici, ITALY.
Change 12.247 Variable LSCDSTYP replaced a reserved field in NPMINSES
VMAC28 dataset in NPM 2.2, but was overlooked until now.
Jan 16, 1995
Thanks to John Steigerwald, Canadian General, CANADA.
Change 12.246 Matching CICSTRAN with DB2ACCT found occurrences when the
ANALDB2C DB2 plan continued to execute long after the CICS trans
Jan 12, 1995 had ended, and a trace of these transactions was needed,
so a new %MACRO DBUGDB2C will now print out the detail
events for a selected NETSNAME/UOWTIME value. Also, the
matchup logic now prints notes on the log on selected
mismatches (first 5, then every 100,000th) so you can
diagnose data problems (like one day's DB2 with another
day's CICS!). See comments in the member, and the DB2
Technical Note in Newsletter TWENTY-SEVEN.
Thanks to Ed Long, Fidelity Systems, USA.
Change 12.245 INVALID DATA FOR OPENDTE in type 14/15 records with nulls
VMAC1415 in that date field are corrected by adding ?? between
Jan 12, 1995 OPENDTE and PD4. and by wrapping the OPENTIME and OPENTM
calculations with IF OPENDTE GT 0 THEN DO; ... END;
I do not know why these records, clearly written after
APAR OW00484 was installed, have zero date, but only one
such record has been found.
Thanks to J. R. Bleeker, Newport News Shipbuilding, USA.
Change 12.244 Variable LCU or LCUID was FORMATted as HEX2., but sites
DOC now have more than 255 LCUs, so the variable was changed
Jan 11, 1995 from HEX2. to HEX4. in members TYPE8911,TYPE10,TYPE1415,
TYPE19,TYPE21,TYPE64,TYPE69,TYPE74,TYPE75,TYPE78,TYPE79.
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Change 12.243 Support for ICEBERG's IXFP SRP Subsystem Performance SMF
VMACICE record PUT9404 changes the subtype 1 record (MXG dataset
Jan 11, 1995 ICEBRGSY) compatibly, adding variables FREBESCT/FREBESCP
(free collected back end space total/in prod partition).
Change 12.242 Support for DFSMSrmm records with DFSMS Release 1.2, and
TYPEEDGB new support for rmm's Control Backup file.
VMACEDGR To summarize MXG support for various rmm data sources:
VMACEDGS Member Infile Reads
Jan 11, 1995 TYPEEDGB LOGSMF Control Backup (EDGSKIP with BACKUP)
TYPEEDGR EDGHSKP Extract (EDGSKIP with RPTEXT)
TYPEEDGS SMF SMF Audit and Security (must update
member IMACEDGS for SMF record ID).
-VMACEDGR support for the DFSMSrmm Extract Record type S
causes INPUT STATEMENT EXCEEDED because the +38 Reserved
field following RSBINNO should have been +31. Also,
field RVSTSTAT does not exist, RVSTBIN and RVOBIN should
have been $EBCDIC6 instead of $EBCDIC8, and RVSTDATE
should have been $EBCDIC10 instead of $EBCDIC8.
This Extract Record is created by EDGHSKP with RPTEXT
option, but all of the dates are in character instead of
SAS dates, so this file may be less than useful.
-However, if EDGHSKP is run with the BACKUP option, that
file creates records that are almost like the SMF records
that are processed by VMACEDGS, except that there is no
SMF header, and there is no EDGS header. With minor
changes to VMACEDGS, new member TYPEEDGB will now read
the backup file (but note, you must use the //LOGSMF DD
to point to the backup file). This seems to be the best
data to use account for and analyze all your rmm tapes!
-The VMACEDGS Audit Record type D variables MDPDSN/MDNDSN
were always INPUT, but they may or may not exist; now the
INPUT is conditional. based on MDPDSNL/MDNDSNL.
Thanks to David Froberg, Software AG, USA.
Change 12.241 MVS/ESA Goal Mode type 72 subtype 3 does not measure the
VMAC7072 SYSTRNTM, the total system transaction time, from read in
Jan 10, 1995 to termination. Instead, variable AVGXETTM (Average
Execution Time), which is a subset of the AVGELPTM
(Average Elapsed time) duration is created. (SYSTRNTM
does exists in Compatibility Mode.)
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA
===Changes thru 12.240 were included in MXG 12.06 dated Jan 09, 1995===
Change 12.240 Cosmetic changes (LABELs for unlabeled variables, names
DOC in comments corrected, delete of temporary datasets that
Jan 8, 1995 should not have been kept, uncovered during QA runs) were
made to these 18 members:
ANALVMDY ASUMTALO INSTALL JCLINSTL JCLUXRE6 TESTIBM3
TYPEMON8 TYPETMON TYPE102A VMACRSPS VMACSIM VMACTIRS
VMACTLMS VMACVMON VMACXAM VMACZRB VMAC0 VMAC44
Change 12.239 Dan Kaberon has revised his analysis that merges the MVS
ADOCPATH TYPE73, TYPE74, and TYPE78CF data to analyze I/O path
ANALPATH statistics. An excellent documentation of the report is
ZNALPATH also provided by Dan in ADOCPATH, and (though unlikely to
Jan 8, 1995 ever be needed again), the original ANALPATH is ZNALPATH.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 12.238 Almost cosmetic. There was no EXDB2STS exit member for
EXDB2STS dataset PDB.DB2STATS, but as there was also no statement
DIFFDB2 "%%INCLUDE SOURCLIB(EXDB2STS);" in DIFFDB2 (the OUTPUT
Jan 8, 1995 statement was implicit). Now there is an INCLUDE to
explicitly invoke the (newly created) exit member.
Change 12.237 MXG 12.04-12.05 only. Support for new subtype 5 Iceberg
EXICEDEL Deleted Data Space Release event (MXG dataset ICEBRGDE)
VMACICE was incorrectly output in dataset ICEBRGDR, and there was
Jan 8, 1995 no exit member EXICEDEL added to the Source Library,
because the "%%INCLUDE SOURCLIB(EXICEDRV);" following the
"MACRO _CICE05" definition in member VMACICE should be:
"%%INCLUDE SOURCLIB(EXICEDEL);/*_LICEDEL OUTPUTS ICEBRGDE*/
No one reported this error (which actually has minimal
impact since the subtype 5 is new and infrequent).
Instead, it was detected by a real fine addition to my QA
jobstream that was written by Freddie Arie. Using the
structure and naming conventions of MXG, Freddie reads
the MXG source library to look for exceptions and lack
symmetry between the IMACs, VMACs, and the exit members,
such as mismatched comments and datasets not output, and
it even verifies that any dataset name in a comment after
each OUTPUT statement is actually the dataset name that
is ultimately output! His powerful logic found my coding
error (I had block replicated code to add support for the
new subtype 5 record, but had failed to change the exit
name!).
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.236 DB2 report PMSQL01 may fail because QWHCTOKN was in the
ANALDB2R BY list for the report step, but was left out of the BY
Jan 8, 1995 list for the sort (and the failure is only apparent if
your data has non-blank QWHCTOKN!). Replace the line
NETSNAME QWHSLOCN BEGEVENT; with
NETSNAME QWHSTOKN QWHSLOCN BEGEVENT;
Change 12.235 Further cleanup of CICS reporting. Correct summarization
ANALCISH of "Storage Manager" CICSMD/CICSMT/CICSMDSA and "Journal"
Jan 5, 1995 CICJCR. "Last Reset time" (DSGLRT) was incorrect on the
report headers. Merged CICxxxxx datasets with CICDS, BY
statement changed to BY SYSTEM COLLTIME;, and VMXGSUM is
now used internally.
Dataset summarization status with this revision:
CICVT "VTAM STATISTICS"
Summarization value (times at RPL maximum) does
not match IBMs value, DETAIL values do match.
CICTCR "TERMINALS"
CICSMD-CICSMT-CICSMDSA "STORAGE MANAGER"
CICJCR "JOURNALS".
CICTCLR "TCLASS STATISTICS"
CICTM "TABLE MANAGER"
CICAUSS "AUTOINSTALLED TERMINALS"
CICAUTO "AUTOINSTALLED STATISTICS"
Summarization value (Times the peak was reached)
does not match IBMs value, DETAIL values do match.
CICDBUSS "DBCTL STATISTICS"
CICLDR "PROGRAMS"
Summarization value (Average fetch time) does not
match.
CICDS "DISPATCHER & TCB STATISTICS"
CICDTB "DYNAMIC TRANSACTION BACKOUT"
CICFCR "FILES DATA TABLE STATISTICS"
CICIRCB "BATCH GLOBAL STATISTICS"
CICLDG "LOADER STATISTICS"
Value in question: "programs loaded but not in use".
CICM "MONITORING STATISTICS"
CICDQG "TRANSIENT DATA GLOBAL"
CICDQR "TRANSIENT DATA RESOURCES"
CICLSRR "LSRPOOLs "
SHARED DATA BUFFERS O.K.
Had no index data or hiperspace data to verify values
CICLSRFR "LSRPOOL FILES"
CICST "STATISTICS DOMAIN STATISTICS"
CICTC "TASK ACCUMULATED SO FAR"
CICTSQ "TEMPORARY STORAGE"
CICCONSS "ISC/IRC ATTACH TIME STATISTICS"
average reuse time values do not match:
IBM Average reuse time tween entries: 00:00:08.3886
MXG Average reuse time tween entries: 0:00:00.296
and the MXG value was summed.
NEW CICS 4.1 REPORTS. None have been validated with 4.1
test data yet; this note will be updated when tested.
CICDLIG "DL/I GLOBAL"
CICFEPIC "FEPI CONNECTION"
CICFEPIP "FEPI POOL"
CICFEPIT "FEPI TARGET"
CICPAUTO "AUTOINSTALL PROGRAM"
CICPUSG "USER DOMAIN"
CICXMC "TRANSACTION MANAGER TCLASS"
CICXMG "TRANSACTION MANAGER GLOBAL"
CICXMR "TRANSACTION MANAGER TRANSACTIN"
Thanks to Mike Major, RSCA, USA.
Change 12.234 This is a documentation change only. No code was changed.
ASMTAPES The Tape Allocation Monitor portion of ASMTAPES still has
Jan 5, 1995 occasional incorrect allocation records (see below), but
ASMTAPES still is the replacement that should be used
in place of ASMTMNT, because the Tape Mount Monitor part
of ASMTAPES is better than ASMTMNT. Comments in ASMTMNT
explicitly tell you to use ASMTAPES instead of ASMTMNT!
Note that if you are running an old copy of ASMTMNT, and
if you suddenly find there are no tape mount records, it
probably means that your site installed the new HCD
architecture (which supports dynamic addition of new tape
devices without a SYSGEN). You will need to re-assemble
ASMTAPES and you will find your mount records will then
reappear. (Some sites assembled ASMTMNT four years ago,
before it was modified for the new HCD architecture!).
These problems are still not resolved in MXG 12.12:
-There are occasional, apparently specious, records with
PROGRAM='IEFIIC' or PROGRAM='STARTING', and typically
with a very short allocation duration that should be
deleted from your analysis. We are still investigating
why these incorrect program names and very short
allocation durations are created; statistically they seem
insignificant, but pragmatically we need to trap and
understand them. I though about deleting them for you,
but that runs against the grain, so I report them here
while the investigation is in progress. I suggest you
look at your data first, and then delete these
observations (and any with a duration less than ten
seconds, as these are insignificant events in the big
picture).
-Thanks to very fine research by Michael Enad of Dun &
Bradstreet, two additional problems in the Allocation
monitor are under development - we apparently miss two
types of deallocation events:
- When a tape volume is swapped from one drive to
another (either due to an error on the first device,
or due to operator command to swap the mount into or
out of a silo), we currently miss the deallocation of
the first device, and instead of writing two separate
allocation records, only one record is written when
the last device is freed, and that record still has
the device address of the first device, so if a
different job happens to allocate the first device
after the swap, that legitimate allocation record
appears to overlap the incorrect allocation record of
the job whose tape was swapped.
- When HSM allocates a device for Migration/Recall and
has multiple mounts, and then later the same day HSM
allocates that same device for Backup, two Allocation
records are written (both at end of the Backup), but
the deallocation time for the Migration/Recall event
has the end of Backup timestamp, causing these two
records to overlap.
Change 12.233 Continued enhancement of what will become VMXGSUM, but is
XMXGSUM currently in XMXGSUM for additional parallel testing.
Jan 5, 1995 Parsing now recognizes the syntax of all options on any
data statement. Output variables are created only if the
variable exists in the input data set (so you can now
drop variables from your DB2ACCT and still run ASUMDB2A
to summarize only your kept variables - previously, all
variables named in ASUMDB2A were created in the output,
even when they did not exist in your DB2ACCT dataset).
See discussion in the member.
Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.232 Labels for FIXEDAV,CSLPFXAV,LPAFXAV,LSQAFXAV,PRVFXAV,
RMFINTRV SQAFXAV,FIXLOAV,PVTAFCAV now state '...*MAX OF AVERAGE'
Jan 5, 1995 instead of AVERAGE. In summarizing these measures of
real frames, taking the real average of all intervals
results with an un-representative number, because of the
slack intervals. By calculating the maximum value of
the averages for each interval, I think you get a much
more representative value, but I should have also made
it clearer in the label, hence this change.
Thanks to ???, ANHYP NV, BELGIUM.
Change 12.231 Label for variable SM012CPU is now 'CPU*TIME*USED' (it
VMACARB was 'CPU TIME USED*TIMER UNITS'), rather misleading. Any
Jan 5, 1995 MXG variable with a SAS time format has already been
converted from TIMER UNITS into seconds.
Thanks to W. F. Hamilton, Scottish Widows, SCOTLAND.
Change 12.230 Weekly and monthly building of PDBs did not include new
MONTHBLD DB2 dataset DB2STATB, which is now added to both members.
WEEKBLD Note that the DB2ACCT, DB2ACCTB, and DB2ACCTP datasets
Jan 5, 1995 are NOT built in the WEEK/MONTH PDB libraries by default
(because they can be quite large, are detail, and may not
be needed - if you want then in your WEEK/MONTH PDB you
can easily add them yourself in your WEEKBLD/MONTHBLD).
Change 12.229 TELEVIEW datasets contain zero observations because the
VMACTELE initial support was written without any data to test.
Jan 4, 1995 -The INPUT of SUBTYPE should have been &PIB.1. instead of
&PIB.2.
-Replace all occurrences of '?? &NUM.2' with ' &PK.1'
so the HH,MM,SS,and TH fields are correctly input.
-Insert ?? between DATE and &PD4. in seven places.
Thanks to Tom Parquette, MONY, USA.
Change 12.228 ICEBERG status variables CAENBCUR and DFWENCUR in dataset
VMACICE ICEBRGDV are incorrect. The two statements testing each
Dec 30, 1994 of these variables for ='00'x should test for ='01'x.
Thanks to Peter McGill, NRMA, AUSTRALIA.
Change 12.227 MXG 12.03-MXG 12.05 only. VMXGHSM still fails with
VMXGHSM "BCRTBLA HAS ALREADY BEEN DEFINED AS NUMERIC". The text
Dec 29, 1994 of Change 12.112 was correct, but in member VMXGHSM you
must delete the semicolon at the end of the line reading:
LENGTH DEFAULT=4;
Thanks to Solomon Baker, The Prudential Services Company, USA.
Change 12.226 Support for Innovation Processing's IAM user SMF record.
EXTYIAM New dataset TYPEIAM provides statistics on usage and the
IMACIAM efficiency of IAM execution. This implementation keeps
TYPEIAM only the first extent location, but if users need to keep
VMACIAM all extents I will revise the MXG implementation.
Dec 16, 1994
Jan 5, 1994
Thanks to David Ehresman, University of Louisville, USA.
Change 12.225 Support for NETSPY 4.5.
EXNSPYNB -If you have LU 6.2 devices, the NSPYAPPL dataset was
FORMATS incompatibly changed because LU 6.2 devices statistics
IMACNSPY are now captured separately in these 27 new LU 6.2
VMACNSPY variables:
Dec 15, 1994 AINPUTS6 AOUTSZT6 AOUTSZW6 ARSPHOS6 ARSPNET6 ATTCHLU6
CINPUTS6 COTPUTS6 CRSPHOS6 CRSPNET6 NETRSPN6 OUTPUTN6
OVRSPPC6 SESSNO6 TOTRSPN6 TRANSNO6 T1RSPNO6 T1RSPPC6
T2RSPNO6 T2RSPPC6 T3RSPNO6 T3RSPPC6 T4RSPNO6 T4RSPPC6
USERRSP6 WRSPHOS6 WRSPNET6
and the 27 existing similarly-named (but without the "6")
variables will now contain only the statistics for your
non-LU 6.2 devices (previously they contained both).
Note that if you need statistics for totals, you will
need to decompose the ratios, sum the numerator and the
denominator separately, and then recalculate the ratio.
(VMXGSUM handles these "normalized" variables easily!).
-New dataset NSPYNCPB contains 27 variables from the new
NCP Control Block Information record, and new MXG format
MGNSPCB was created for that data.
-For all NETSPY versions, variable NSPCURVS was input as
PIB4 and thus wrong. It is now input as PIB2 and new
variable NSPCURVT='VC-S*ESTABLISHED*THIS SESSION' is
created PIB2 after NSPCURVS.
Thanks to Tim Crocker, Computer Power, USA.
Thanks to Alan Phelan, Allied Irish Bank Group, IRELAND.
Change 12.224 VM/ESA 2.2 Scheduler records cause PROBABLE DATA LOSS
VMACVMXA error message. The second occurrence of SKIP=SKIP-148;
Dec 15, 1994 should be SKIP=SKIP-100; (this is the one 67 lines after
IF MRHDRDM=2 AND MRHDRRC=5 THEN DO; /*VXSCLDDL*/
With this change, MXG tolerates VM/ESA 2.2 data records,
but there are additional fields added by IBM (1.7,1.15,
2.4,2.5,2.6,4.9,4.10) that are not yet decoded. This
text will be revised when documentation has been received
and MXG fully supports VM/ESA 2.2 records.
Thanks to Phyllis M. Parisi, University at Buffalo, USA.
Change 12.223 If the INTERVAL= parameter was entered in mixed or lower
VMXGDUR case, its value was not recognized and an error flagged,
Dec 1, 1994 but the value was then printed in uppercase, making it
quite confusing to diagnose. Now, the UPCASE() function
is used to eliminate the exposure.
Change 12.222 Datasets already using LSR are added to the report, since
ANALBLSR you should periodically review the LSR parameters to be
Dec 1, 1994 sure they are still correct. If the current buffer field
(0 when LSR is in use) is 'LSR' then LSR is already being
used. In addition, if there is a '-' beside the number
of buffers being recommended, then that signifies that a
value of 10 was forced in the report (and there were not
really 10 records in the file). This is done because the
minimum you can specify with BLSR is 10 (a lesser value
will cause a JCL error!). The '-' will usually appear on
the index component of a file. If there is a '+' next to
the number of buffers then the recommended setting
reflects the limit applied by the MEMSIZE parameter and
the EXCP count is greater than 20% of the number of
physical records in the file. In this case, sometimes
more buffers can be effective, and you may want to try
higher values. In one case, a file with 400,000 EXCPs
against the data component was reduced to 18,000 by using
BUFND=2000 and HBUFND=7500 (32m of hiperspace buffers),
and this one change reduced the run time from 2.5 hours
to 45 minutes!
Thanks to Phil Henninge, Timken Company, USA.
Change 12.221 FACOM AIM type 117 SMF record causes INPUT STATEMENT
VMACAIM7 EXCEEDED RECORD or ARRAY SUBSCRIPT OUT OF RANGE because
Nov 28, 1994 the INPUT of NUMSUBRG &PIB.4. should have been &PIB.2.
Thanks to Ian Heaney, Toyota Australia, AUSTRALIA.
Change 12.220 DB2 Package Accounting should be an SMF ID=101,SUBTYPE=1
VMACDB2 record, but that IFCID=239 record was originally written
VMAC102 as an ID=102 record. IBM tried to correct the error in
Nov 28, 1994 APAR PN56441, which did change the ID from 102 to 101,
Jan 12, 1995 but the subtype was still a zero, so APAR PN63234 now
corrects both ID and SUBTYPE. This MXG change detects
the uncorrected record and tells you you need to install
the APARs, and deletes the package record.
Pending installation of the APARs, you can use this
program to read your SMF file and to create a new
copy with the bad type IFCID=239 records corrected:
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
FILE SMFOUT DCB=SMF;
IF (ID=101 AND SUBTYPE=0) OR ID=102 THEN DO;
INPUT @25+OFFSMF OFFPROD &PIB.4.
@29+OFFSMF LENPROD &PIB.2.
@31+OFFSMF NRPROD &PIB.2.
@;
OFFPROD=OFFPROD-3+OFFSMF;
LENLEFT=LENPROD;
%INCLUDE SOURCLIB(VMACDB2H);
IF QWHSIID=239 THEN DO;
ID=101;
SUBTYPE=1;
PUT _INFILE_ @2 ID PIB1. @19 SUBTYPE PIB1.;
END;
ELSE PUT _INFILE_;
END;
ELSE PUT _INFILE_;
Thanks to Joseph L. Schwartz, CIGNA, USA.
Thanks to Jeff Marsh, Twentieth Century Services, USA.
Change 12.219 STK ICEBERG records may cause "INFORMAT $PIB UNKNOWN" of
VMACICE "INFORMAT CHAR UNKNOWN", only if ICEBERG SMF records are
Nov 22, 1994 processed with other SMF records (e.g., if you use EXPDB
exits to add ICEBERG processing to your PDB library),
because variable VERSION in VMACICE is numeric, but it is
character in other MXG datasets and variable FLAG1 is
character in VMACICE but numeric elsewhere. Change the
variable name VERSION to ICEVERS and the variable name
FLAG1 to ICEFLAG1 and the conflict is avoided. I will
also revise my Q/A process to better detect this class of
conflicts (actually, VERSION conflict was detected but I
missed reading it - FLAG1 was not detected because it is
kept only in ICEBERG datasets and conflicted with an MXG
temporary variable, and my Q/A stream was not robust enuf
to cover that possibility!).
Thanks to Diane Eppestine, Southwestern Bell, USA.
===Changes thru 12.218 were included in MXG 12.05 dated Nov 20, 1994===
Change 12.218 This redesign of VMXGSUM now keeps only the variables
XMXGSUM that are found in the input dataset (plus those created
Nov 20, 1994 in the INCODE= logic). Previously, to prevent a failure
in the PROC MEANS, VMXGSUM created all variables that
appeared in any of its arguments, but if you used IMACDB2
to drop variables in your DB2ACCT dataset (to reduce its
size), and then you used ASUMDB2A (which invokes VMXGSUM)
to summarize, all of those dropped variables that were
listed in the SUM=, MIN=, etc., arguments in ASUMDB2A
would have been recreated (with missing values) in your
output dataset! Now you can tailor your datasets with the
_K macro in the IMAC member and use existing MXG
ASUM/TRND members to summarize only the variables that
you kept. This version only supports lists of variables
with single digit suffixes (CPU0-CPU9 works, but
CHAN01-CHAN99 will not have all 99 variables created).
The complete support for arbitrary lists will be in MXG
12.06, but none of the ASUM/TRND members in MXG contain
double-digit suffixes, so the exposure is extremely
remote. Because of this limitation, the new logic is in
a separate member named XMXGSUM, so you pioneers can help
test before I make the optimized version the default.
Simply copy XMXGSUM into your USERID.SOURCLIB library and
rename it to be VMXGSUM and you will exploit this
optimization. Note that if it ever becomes necessary to
revert to the original design, you can specify new
argument KEEPALL=YES to create all variables.
See also Change 12.233.
Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.217 GRAFDB2 failed with TRNDDB2A data as input, because the
GRAFDB2 graphs used QWACESC (end time) instead of QWACBSC (start
Nov 20, 1994 time), which is what is used in TRNDDB2A to summarize.
All occurrences of QWACESC were thus changed to QWACBSC.
Thanks to Tom Elbert, John Alden, USA.
Change 12.216 If your requested only report PMSQL01 with PDB=SMF, the
ANALDB2R report failed (and the type of failure depended on which
Nov 20, 1994 version of SAS you were using). Requesting other trace
reports, or using READDB2 first and then ANALDB2R with
PDB=PDB will circumvent the logic error fixed here.
Thanks to Dan Null, Caterpiller Tractor, USA.
Change 12.215 Coding in progress as MXG 12.05 was to be built.
EXTY123 Support for S/390 Parallel Query Server (SPQS) type 123
EXTY123B SMF record. The segments are from DB2ACCT, but not all
IMAC123 of the fields are exactly the same, and time ran out
TYPE123 before I could finish validation. There's a remote
VMAC123 chance it will work, but I doubt it, and I do need test
Nov 20, 1994 data before I can claim support for the new accounting.
Nov 21, 1994 I listed SPQS as supported to attract test data!
Check with Tech Support before you use this support, and
this note will be revised when support is validated.
Update: Nov 21, 1994:
The MXG 12.05 support assumed there was a QWHS section,
and that header had a release value greater than 2.3, but
the IBM DSECT implies QWSH is reserved. Thus MXG may
need an inserted line after the INCLUDE of VMACDB2H with:
QWHSRELN=3.0;
to fake out the rest of the MXG code. I have revised the
VMAC123 member to remove any dependency on QWHSRELN and
streamlined the code, but structurally I still believe
that the MXG 12.05 code is okay. Again, I will revise
this text when I get my hands on a real type 123 record!
MXG 12.06 note: still no validation of this support.
Thanks to Majid Abai, Southern California Edison, USA.
Change 12.214 Analysis of Tape allocation has been revised so a tape
ASUMTALO drive is only counted once per interval. (Previously, if
TRNDTALO two jobs used the same tape drive in the same 15-second
Nov 19, 1994 interval, we counted that one instance twice, which could
cause the maximum tape drives in use to be greater than
the number of installed drives.)
You can also specify is the statistics are created for
each SYSTEM, or across all system with a new macro.
Change 12.213 New exit IMACUCB allows you to change the value of MXG
IMACUCB variable DEVICE in TYPE8911,TYPE10,TYPE1415,TYPE19,TYPE21
VMACUCB TYPE62,TYPE64,TYPE74,TYPE74,TYPE8911 members, and in data
Nov 19, 1994 set TYPE30_D observations. This is especially useful in
analyzing MXG Tape Mount and Tape Allocation statistics,
because MXG cannot tell an Autoloader from a Silo from a
Cartridge Tape device; however, you know which range of
device addresses are which, and could create values of
DEVICE='SILO' or DEVICE='AUTOLOD'
in this new exit, and then automatically your reports
from ANALTMTN,ANALTALO, etc., will be grouped and summed
by subsets of your tape devices!
Change 12.212 Support for CA/SQL's user SMF record appears to already
VMACIDMS have been in MXG - the Performance Monitor records from
Nov 18, 1994 CA/SQL are identical to the IDMS Performance Monitor's
SMF records, except that the version identifier (SMFHVER)
now contains 1200 (presumably for 12.0.0, since the prior
version IDMS 10.2.1 SMF records have the value 1021!).
Thanks to Greg Caliri, The Shareholder Services Group, USA.
Change 12.211 ACF2 variable ACPMFWHY (Reason Code) should have been
VMACACF2 FORMATed HEX2., and its label now indicates hex
Nov 18, 1994 instead of binary.
Thanks to Warren Hayward, TJX, USA.
Change 12.210 Support for Sterling Software's ASM V3.0.0 SMF type 39
VMAC39 record - their records conform to IBM's format and are
Nov 17, 1994 processed without error, including the subtype 255.
Thanks to Bob Berwick, UNIPAC, USA.
Change 12.209 Support for SMF type 116 MQM 1.1.2 Accounting record
EXTY116 creates one new dataset:
IMAC116 MQMACCT - MQM Accounting Data
TYPE116 The CPU time and counts of GETs and PUTs in four message
VMAC116 sizes (0-99,100-999,1000-9999,over 10000) are provided,
Nov 17, 1994 and the NETSNAME/UOWTIME fields are decoded from QWHCTOKN
so that specific MQM events can be matched with their
CICS or IMS transaction. Note that IMS can cause more
than one MQM record, which must be summed to accurately
provide correct totals for the IMS application.
This code has been hand checked with the hex dump printed
in the MQM System Management Guide, SC33-0806-01, which
provides a good overview of IBM's new Message Queue
Manager design and function.
Change 12.208 Support for SMF type 115 MQM 1.1.2 Statistics record
EXTY1151 creates three new datasets:
EXTY1152 MQMLOG - Subtype 1 Log Manager Statistics.
EXTY115B MQMMSGDM - Subtype 2 Message, Data Manager Statistics.
IMAC115 MQMBUFER - Subtype 2 Buffer Statistics for each Pool.
TYPE115 These statistics provide performance statistics, and the
VMAC115 Chapter 6 of SC33-0806-01 even provides guidelines for
Nov 17, 1994 interpreting and using these MQM statistics.
Change 12.207 SUBTYPE in SMF type 115 and 116 records is only one byte,
VMACSMF (instead of the normal two-byte field), so VMACSMF is now
Nov 17, 1994 modified to input SUBTYPE for this anamoly.
Change 12.206 Support for HSM APAR OW05988, which adds HSM CPU time and
VMACHSM management class name, using existing reserved fields so
Nov 17, 1994 the change was compatibly made. FSRCPUTM &PIB.4.2 now
replaces the +4 reserved area following FSRFLG2, and now
FSRMGCLN &PIB.2. FSRMGTCL $EBCDIC8. +18 replaces the +28
reserved area after FSRTRKKW. The APAR text makes no
mention of what CPU time is captured in the new field!
Variables FSRCPUTM and FSRMGTCL were added to datasets
HSMFSRST and HSMFSRTP.
Thanks to Lawrence Jermyn, Fidelity Systems Company, USA.
Change 12.205 TYPE42DS observations for VIO datasets can be recognized
VMAC42 because DEVNR=3FFFx, and most of the I/O counts/durations
Nov 16, 1994 are trash (i.e., non-zero values, but not valid either),
so now they are set missing, and new variable S42VIO is
set to "Y" to flag observations that are for VIO.
Thanks to James Purdie, Banc One Services Corp., USA
Change 12.204 For jobs which only have a type 6 SMF record, variable
BUILDPDB TYPETASK was blank in dataset PDB.JOBS. To correct, the
BUILDPD3 variable was added to the _PDB6 macro definition in
BUILD005 IMACPDB, and the variable was added to the ID= statement
IMACPDB with the PROC MEANS DATA=PRINT in members BUILDPDB,
Nov 16, 1994 BUILDPD3, and BUILD005.
Thanks to Kenneth D. Jones, SHL Systemhouse, CANADA.
Change 12.203 Support for Omegamon for CICS V300 user SMF record. The
VMACOMCI version is incompatible, as new subtypes replace old ones
Nov 14, 1994 and new variables are created in existing datasets, but
there are no new datasets. In addition, many existing
variables' formats were validated and corrected.
Now, MXG supports Omegamon for CICS Versions 550 and 551,
and Omegamon for CICS/ESA Versions 100 and 300. There
were no changes to the type 110 SMF record in V300.
Change 12.202 This CICS utility now identifies if your type 110 records
UTILCICS are actually Omegamon records (which require tailoring in
Nov 12, 1994 member IMACEXCL), which optional IBM and/or Omegamon data
segments are tacked on the base record, and which PTFs in
member IMACPTF must be updated for your sites records,
and you no longer have to go thru the detail reports and
match up fields - two simple PROC PRINTs tell all!
Note: 2010: SEE MEMBER UTILEXCL instead of UTILCICS.
Change 12.201 Support for NPM 2.2 has now been validated with real data
FORMATS for the new NPMVSaaa datasets, with these corrections:
VMAC28 -NPMVSVAD dataset: INVALID ARGUMENT TO FUNCTION INPUT and
Nov 12, 1994 variable VADSTIME is missing, because the VADSTIME=DHMS..
statement had the date and time variables reversed (1st
is VADSDTEX, then VADSTIMX). Also, variable NPMNAME was
incorrect because the two references to LSCDROFF inside
the VAD processing should have been LVCDROFF.
-NPMVSVAP dataset: VAPACTIM was trashed because it was not
documented as a datetimestamp value. VAPSECNA was trash
because it should be formatted with $HEX6. VAPDSTAT and
VAPSTATU were wrong because both had VAPCSTAT in their
percentage calculation instead of themselves.
-NPMVSVBF dataset: VBFUSER is now input as $EBCDIC8 vice
&PIB.4., and VBFAVLBF & VBFBFEXT are &PIB.2. instead of
&PIB.4. (which caused VBFPGEXT,VBFNREQ,VBFMXREQ to be
trashed, as the preceding errors messed the alignment!).
-NPMVSVDV dataset: Most variables were trashed, because I
failed to input VDVNNMAE ($EBCDIC8.) after VDVSCNAM, and
I input VDVLNKST as &PIB.4. instead of &PIB.1., and the
+4 at the end of the first input should not be there.
-NPMLUCON dataset: NCPRLSE should have been input $EBCDIC8
instead of &PIB.4, trashing NCPNEWNM and NCPGENLV.
-NPMNWCWC dataset: Most variables were trashed, because
the reserved field in the NWC section after REVL should
have been +2 instead of +1.
-All other datasets new with NPM 2.2 appear to be valid,
and the above errors had no effect on earlier NPM data.
-Minor, but some subtype values (NPMSUBTY) were not in the
MG028TY format, but now they are.
Thanks to Mr. Robbiany, Comitsiel S.p.A., ITALY.
Change 12.200 -New dataset TYPE72SC, for MVS/ESA 5.1+ in Goal Mode, is
BUILDPDB now created to keep track of the Service Classes that are
BUILDPD3 served by each MVS Server, and new variable SERVER was
EXTY72SC added to existing dataset TYPE72GO to identify the
IMAC7072 service classes that are servers. Don Deese's CPExpert
RMFINTRV is the best tool that I know that exploits all of the new
WEEKBLD data when the Workload Manager is in Goal Mode, and Don
WEEKBLDT found that these datasets enhance his ability to identify
MONTHBLD the cause of many of the delays marked as UNKNOWN in IBMs
Nov 11, 1994 new data. Give Don a call at 703 971 4497 for more info.
-The PDB-Building members were updated to create the new
PDB.TYPE72SC dataset, and in adding that dataset to the
weekly build members, I discovered that I had failed to
add several new PDB datasets to WEEKBLD/WEEKBLDT, and
also found WEEKBLD and WEEKBLDT were not synchronized.
Now, all MXG datasets built by default by JCLPDB6 will
also be built in the Weekly and Monthly datasets as well.
-MXG 12.04-only, a debugging statement IF OFFWRS GT . THEN
PUT OFFWRS= LENWRS= NRWRS=; was also deleted.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 12.199 Type 6 SMF record INVALID ARGUMENT TO FUNCTION INPUT is
VMAC6 caused by CA-DISPATCH SMF records that have overwritten
Nov 10, 1994 the date-part of READTIME with 'EE'x. While the real fix
is to get CA-DISPATCH corrected, MXG added an attempted
fix-up back in Change 11.342, but while the text of that
change was correct, the code I implemented from my own
change finger faulted! The two occurrences that read
SUBSTR(READCADI,1,1) must be SUBSTR(READCADI,5,1)
(because the date starts in byte 5, not byte 1!).
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 12.198 Support for InfoAccess Release 5.1 user SMF record from
EXTYODSE Network Imaging Systems Corporation adds two new datasets:
EXTYODSP ODSCMSPU - CMS (Controller Managed Storage) Report Purge
IMACODS ODSCMSRE - CMS Recache - copy report from optical to CMS
VMACODS and the ODSDEVIC optical device statistics variables were
Nov 10, 1994 completely changed and revised with durations and counts.
InfoAccess is a high-speed, high volume report storage and
retrieval system that takes character-based reports and
compresses and indexes the reports on optical platters and
in RAID arrays. Previously, the company was named Laser
Access Corporation, and the product was the LA1500 Optical
Data System, which accounts for the acronym "ODS" for this
product. The Release 5.1 records are incompatibly with
the previous records, so you will require this change.
Change 12.197 -APAF INPUT STATEMENT EXCEEDED RECORD LENGTH occurs when
VMACAPAF a channel record does not contain channel type and mode.
Nov 10, 1994 Insert after input of CHPIDBSY the statement:
@; IF LENCHPID GE 12 THEN INPUT
-APAF INVALID DATA FOR IOCDSLNO occurs when there is no
IOCDS information in the record; a value of '00'x is not
valid for a field input with &NUM.1. Insert a double
questionmark in its input: IOCDSLNO ?? &NUM.1. to
suppress the error message and associated record dump.
Thanks to Willie Antman, Federal Deposit Insurance Corporation, USA.
Change 12.196 Calculation of variables AOUTSZT and ARSPNET in NETSPY
VMACNSPY dataset NSPYLU were changed by NETSPY, but I did not know
Nov 9, 1994 about the changes until this user diligently validated my
calculations with NETSPY's reports.
-The AOUTSZT= calculation should have divided by TRANSNO
(the number of transactions) instead of NETRSPNO (the
number of transactions with measured response times)
-The ARSPNET value calculated by MXG was missing if the
NETRSPNO was zero, but the NETSPY logic now looks to see:
if more than half of the transactions had a measured
response; if not is the new bit in LUFDRSEQ flagging that
the value in LRSPNET is the calculated ARSPNET value, or
if not, then use the only data available to calculate the
average network response. The new section of code in the
MXG logic for NSPYRECs S, T, and U now reads:
IF TRANSNO GT 0 THEN DO;
AINPUTSZ=CINPUTSZ/TRANSNO;
AOUTSZT=COTPUTSZ/TRANSNO;
END;
ELSE DO;
AINPUTSZ=.;
AOUTSZT=.;
END;
IF NETRSPNO GE .5*TRANSNO AND TRANSNO GT 0
THEN ARSPNET=CRSPNET/TRANSNO;
ELSE IF LUFDRSEQ='...1....'B THEN ARSPNET=LRSPNET;
ELSE IF TRANSNO GT 0 THEN ARSPNET=CRSPNET/TRANSNO;
ELSE ARSPNET=.;
IF LUNRSPSS GT 0 THEN ARSPHOST=CRSPHOST/LUNRSPSS;
ELSE ARSPHOST=.;
IF OUTPUTNO GT 0 THEN AOUTSZW=COTPUTSZ/OUTPUTNO;
ELSE AOUTSZW=.;
IF NETRSPNO GT 0 THEN DO;
/* calculation of ARSPNET, AOUTSZT was originally here */
IF SESSMGR='N' THEN DO; /* DONT CALC TARGET FOR ....*/
... original code ...
and then the two subsequent occurrences of
ARSPNET=.;
were deleted.
Thanks to Wendy Gan, Malayan Banking Berhad, MALAYSIA.
Thanks to Ms Foo Hooi Ping, Maybank, MALAYSIA.
Change 12.195 When WEEKBLD was corrected by Change 11.206, the same fix
WEEKBLDT was not applied to WEEKBLDT, causing TAPEMNTS NOT SORTED
Nov 7, 1994 error. The correct list for dataset TAPEMNTS is:
SYSTEM SHIFT DEVICE TMNTMTYP TMNTTIME
Additionally, %INCLUDE SOURCLIB(EXPDBWEK) was also added
to make WEEKBLDT consistent with WEEKBLD.
Thanks to Gavin Ring, ALCATEL Australia, AUSTRALIA
Change 12.194 3990-6 Cache RMF Reporter storage variables CNCONF,CSCONF
VMACACHE CSAVAIL,CSOFFL,CNPINNED and CSPINNED are in K-bytes in
Nov 7, 1994 the SMF record (while for all other devices, the values
were in bytes!). As a result, those six variables are
now multiplied by 1024 inside the nested DO groups for
IF REPORLVL GE 1.6 ... and IF CACMODEL EQ 06X ...
(so they will be printed correctly with MGBYTES format).
Thanks to Russ Weid, CUNA Mutual Insurance Group, USA.
Change 12.193 Type 6 variable SUPGROUP is now added to PDB.PRINT, as
IMACPDB the destination group name has been found necessary for
Nov 7, 1994 print accounting; macro _PDB6 now includes SUPGROUP.
Thanks to Russ Weid, CUNA Mutual Insurance Group, USA.
===Changes thru 12.192 were included in MXG 12.04A dated Oct 23, 1994==
Change 12.192 SMS Data Class, Storage Class and Management Class fields
VMAC42 can only be 8 bytes, even though many records contained
VMAC60 30-byte areas for these fields. This change changes all
VMAC6156 inputs in all datasets to be length 8, so that the stored
VMACDCOL size of the datasets containing these SMS constructs will
VMACOMSM be minimized. (While some of these variables are named
VMACVVDS consistently as DATACLAS, STORCLAS, MGMTCLAS, there are
VMXGHSM many variant spellings when I instead used the field name
Oct 23, 1994 in the DSECT as the variable's name.)
Change 12.191 Support for Landmark's The Monitor for MVS, TMON/MVS 1.3.
EXTMVCC The new version is incompatible because new subtypes now
EXTMVCD replace old ones, so some existing datasets will have no
EXTMVCF observations; however, MXG will not fail with new records
EXTMVCH and some records (notably the system record) are still
EXTMVCI processed successfully (albeit without new data added at
EXTMVCP the end of the old record!).
EXTMVCS Many new datasets are now created, some from new subtypes
EXTMVDV and some from existing subtypes the MXG did not support.
EXTMVIT The comments in member VMACTMVS identify which datasets
EXTMVIX are created from which subtype. Some subtypes are not
EXTMVJD yet decoded because the DSECT was not provided, and some
EXTMVJDA were not decoded because no test data was provided, but
EXTMVJDD Landmark provided both data and DSECTs for the important
EXTMVJDI subtypes, so the new support has been tested with data,
EXTMVJDO and its been out on the street for months with no report
EXTMVJDR of any problems (but I doubt any power user has attacked
EXTMVJDS each and every record type). Some testing notes:
EXTMVJDT JDCPRES - large negative value for CSTORE residency
EXTMVLC JDJTCBS - unreasonable (327,680) count of TCBs
EXTMVMD and will update this note when I know more.
EXTMVML
EXTMVSG Note: this change was in-progress in MXG 12.04A, and
EXTMVXI existing datasets had new variables added, but the new
IMACTMVS dataset decoding and validation was not added until MXG
VMACTMVS 12.05, which is the minimum level for TMVS 1.3.
Nov 15, 1994
Change 12.190 TCP/IP Port addresses were stored in character variables
VMACTCP with hex format (TCP/FTP/API-LCL/RMT-PO), but I now know
Oct 21, 1994 they really are decimal numbers, so I have created new
numeric variables (TCP/FTP/API-LCL/RMT-PN) and the label
for the sets of variables indicated whether the Port
Address is Hex (old PO variables) or Decimal (new PN's).
Also, variables APILCLAD/APIRMTAD are now format $HEX8.
Thanks to David Ehresman, University of Louisville, USA.
Change 12.189 CICS 3.2.1 only. Statistics dataset CICDS duration
VMAC110 variables with suffix TWT,TDT,TCT,ACT,SWT,SCT and prefix
Oct 21, 1994 DSG,DS2, or DS3 were incorrectly converted. In the 18
lines preceding SKIP=SKIP-216;, make the variable name
on the right hand side of the equal sign match the name
on the left.
Thanks to Tom Parker, Hogan Systems, USA.
Change 12.188 MXG 12.04 only. Type 28 INPUT STATEMENT EXCEEDED error
VMAC28 preceded by INVALID DATA FOR IF message occurs because a
Oct 21, 1994 line was dropped. Insert a line with @; immediately
preceding IF LENAOF GE 128 THEN and this error will
go away. In addition, this error discovered the new date
time stamp SYNCTIME at the end of the NAD section, which
is now captured by MXG.
Thanks to Tom Parker, Hogan Systems, USA.
Change 12.187 NPM type 28 NVV section caused CONVERSION note on the log
VMAC28 and incorrect value for flag variables LNVVCACH,LNVVREMV,
Oct 21, 1994 and LNVVMOUN, because the three variables tested should
have been suffixed with "X". That is, change:
IF LNVVCACH GT 0 THEN LNVVCACH='Y';ELSE LNVVCACH=' ';
IF LNVVREMV GT 0 THEN LNVVREMV='Y';ELSE LNVVREMV=' ';
IF LNVVMOUN GT 0 THEN LNVVMOUN='Y';ELSE LNVVMOUN=' ';
to read:
IF LNVVCACX GT 0 THEN LNVVCACH='Y';ELSE LNVVCACH=' ';
IF LNVVREMX GT 0 THEN LNVVREMV='Y';ELSE LNVVREMV=' ';
IF LNVVMOUX GT 0 THEN LNVVMOUN='Y';ELSE LNVVMOUN=' ';
Thanks to Tom Parker, Hogan Systems, USA.
Change 12.186 Candle Omegamon for VTAM V160 incompatibly changed their
VMACOMVT user SMF record, causing MXG error messages and possible
Oct 20, 1994 looping. A four byte field was expanded to eight bytes
in the middle of the exception record (to store VTAM NODE
name), requiring extensive recoding in MXG; however, you
can partially circumvent the error by inserting:
IF NASMFPVN GE 'V160' THEN INPUT @LOC+60 @;
immediately before the statement:
%%INCLUDE SOURCLIB(EXOMVEXC);
With that circumvention, the looping will not occur, and
the rest of the OMVTxxxx datasets will be valid, but the
OMVTEXCE dataset will still be trashed until you install
the new MXG version. What's really ludicrous about their
incompatible change (and its unnecessary abuse of your
time to install a new version of MXG) is that there was
no need for the incompatibility - there are two other
areas, one of 12 bytes, one of 16 bytes, which could and
should have been used to store the Node Name compatibly!
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Change 12.185 Batch LSR analysis may report no candidates due to logic
ANALBLSR error, if the last observation in DSETOPEN did not meet
Oct 20, 1994 the subsetting IF criteria. The subsetting IF statement
IF TYPETASK=:'JOB' AND ACCESS=:'VSAM' ... etc
must be replaced with this logic:
IF NOT (TYPETASK=:'JOB' AND ACCESS=:'VSAM' AND
(LSRSTAT='Y' OR LSRSTAT='?')) THEN DO;
IF EOF THEN CALL SYMPUT('CANDIDAT',CANDIDAT);
DELETE;
END;
Thanks to Paul Hill, Midland Bank, UK.
Change 12.184 NETSPY Token-Ring Dataset NSPYTR variable TIC_UTIL was 10
VMACNSPY times too large (the convert nanosec to microsec was
Oct 20, 1994 off by 1000, but conversion to percent was off by 100!).
In addition, the old equation used IFRAMESS/IFRAMESR to
calculate TIC_UTIL (because that's what LEGENT used in
its on-line display), but now LEGENT PTF 71565 corrects
their on-line calculation using TRTFRAMS/TRTFRAMR instead
of just I-Frames (so their on-line reports match their
batch reports), so now the MXG calculation agrees with
the LEGENT calculation with that PTF. The correct MXG
equation (in 2 places) is now:
TIC_UTIL=100*
((((BYTSENT*TRTPBYTS)+(BYTRECV*TRTPBYTR))/1000000000)+
(((TRTFRAMS*TRTPFRMS)+(TRTFRAMR*TRTPFRMR))/1000000))
/DURATM;
Thanks to Janice Radel, General American Life Insurance Co., USA.
Change 12.183 Change 11.201 intended to change the spelling of variable
VMAC90 NEWDSN to NEWDSNSM in TYPE90, but it was misspelled as
Oct 19, 1994 NEWSDNSM. It is now correctly spelled NEWDSNSM.
Thanks to Graeme Yeandle, British Telecom, UK.
Change 12.182 UTILCICS fails with syntax error, because line 342 is a
UTILCICS /* */ line which prematurely terminates the comment
Oct 19, 1994 block around the new text. Delete that line and UTILCICS
will execute. Read the comments and you can understand
how to use the output to diagnose MXG error messages in
in your CICS type 110 SMF records.
Thanks to Norbert Korsche, OMV, AUSTRIA.
Change 12.181 MXG 12.03 added dataset PDB.TYPE30_6 to the PDB, but the
BUILDPDB actual change was not noted in member CHANGES. While not
Oct 19, 1994 usually needed, it was added to the PDB for completeness,
since resources for tasks which start before SMF has come
(called "early address spaces" like CATALOG, PCAUTH, GRS,
ALLOCAS, etc.) may have their resources recorded in the
TYPE30_6 instead of TYPE30_V (and since these ASIDs are
not normally terminated, even at shutdown, there may not
ever be a TYPE30_4 record written for them).
Thanks to Norbert Korsche, OMV, AUSTRIA.
Change 12.180 Type 42 subtype 5 (TYPE42SR) and subtype 6 (TYPE42DS)
VMAC42 variables STARTIME/ENDTIME can be erratically wrong. The
Oct 19, 1994 timestamps are in GMT instead of LOCAL if TIMEZONE has a
Nov 9, 1994 non-zero GMT offset specified in SYS1.PARMLIB(CLOCKnn),
(but SMFTIME is always on the LOCAL clock). For the
TYPE42SR and for the TYPE42DS INTVCLOS=0 (CLOSE) records,
MXG did not attempt to convert to GMT, so the only error
in those records was that the STARTIME/ENDTIME are GMT.
However, MXG did use the difference between SMFTIME and
ENDTIME for the TYPE42DS INTVCLOS=1 (INTERVAL) record to
determine the GMT offset and then convert START/ENDTIME
to LOCAL, but I now have data to prove it is impossible
to convert, because the SMF record timestamp can be many
hours later than the end of interval (for swapped out
tasks, the SMF record is not timestamped until the task
swaps back in!).
(In MXG 12.04A only, I actually added GMT conversion
logic to the INTVCLOS=0 in TYPE42DS and in TYPE42SR,
but now this revised change removes conversion of GMT
to local for all type 42 subtypes. Until IBM gives
us a GMT offset in these records, MXG cannot convert
GMT to local in any safe fashion. In addition, some
site's data show SMF42PTE later than SMFTIME, which
really messes up any conversion algorithm, so the
only safe strategy is to leave the timestamps in GMT
as provided by IBM - you, knowing your own GMT offset
must then convert STARTIME/ENDTIME back to LOCAL in
your report programs using TYPE42SR or TYPE42DS.)
See also the MVS Technical Notes for additional type
42 problems and concerns.
P.S. APAR OW05631 added the DEVNR and VOLSER to TYPE42DS.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 12.179 SAP Accounting record under IMS was not properly decoded.
VMACIMS Change the INPUT of SAPTIMTR from "TU4." to "&PIB.4.3",
Oct 19, 1994 change SAPCPUT (three times) and SAPELTI (once) from
"&PIB.4.1" to "&PIB.4.3". Also, the HH, MM, SS and TH
fields used for construction of SAPTIME probably need to
be changed from "&PIB.1" to "&PK.1", but that has not yet
been validated with a hex dump of a record.
Thanks to ???, SJ ECONOMISERVICE, SWEDEN.
Thanks to Boerje Edlund, SAS Institute, SWEDEN.
Change 12.178 Cosmetic, but avoids confusion. Variable CPUTM is now
RMFINTRV labeled consistently as "TOTAL*CPU TIME*CAPTURED" in all
VMAC30 of the SMF/RMF datasets created by MXG. Previously, it
VMAC32 had different labels to describe its contents (TCB+SRB in
VMAC434 some records, TCB+SRB+HPT+... in RMF, etc.) but when you
VMAC435 mixed SMF records (like in BUILDPDB) you ended up with an
VMAC7072 inaccurate label. To know the components of CPUTM in a
VMACDB2 particular record, read the ADOCxxxx description.
VMACORAC
VMACTSOM
Oct 19, 1994
Thanks to Waldemar Schneider, SAS EUROPE, GERMANY.
Change 12.177 Archaic Landmark 1.7 only. Variable STARTIME in MONIDBDS
TYPEMONI was missing, because its creation (five lines, starting
Oct 18, 1994 with IF CREATIME and ending with RESPONSE=) should have
been located immediately after APPLID=SYSID; statement.
Thanks to Warren Tanaka, Farmers Insurance Group, USA.
No Changes while attending Italian CMG meeting in Venice!
Change 12.176 MXG 12.04 only. INTERVAL=SHIFT, should be INTERVAL=WEEK,.
TRNDTALO No test data was available when the trending member was
Oct 3, 1994 written; test data exposed the error.
Change 12.175 MXG 12.04 only. Tape unload with IEBUPDTE has return
ANALTMDB code of 4, a note that ANALTMDB has no lines, and there
Oct 3, 1994 are 2396 members unloaded (instead of the expected 2379)!
This does not really cause a problem, but the error is
because member ANALTMDB contains an unloaded PDS, but I
failed to change the "./" IEBUPDTE control statements to
"XY", in my source PDS, so they were propagated into the
tape, and so when IEBUPDTE unloaded the tape, those "./"
caused members (all starting with RTMD) to be created!
Changing the "./" in my ANALTMDB to XY avoids the error,
but you need to take no action.
Change 12.174 MXG 12.04 only. Variable QWACLOCN that was added to the
VMACDB2 DB2ACCTB dataset by Change 12.169 should have been
Oct 3, 1994 spelled QLACLOCN. The text of 12.169 was changed in MXG
12.04A to avoid further confusion.
Change 12.173 MXG 12.04 only. New NPM dataset NPMLINE did not have all
VMAC28 of the variables it should have, due to spelling error.
Oct 3, 1994 Change the one occurrence of _VA28NLF to _VA28NLV to fix!
Change 12.172 A sample report using Amdahl's APAF records (TYPEAPAF)
ANALAPAF that sums MDF domain busy to provide a total platform
Oct 3, 1994 busy is added by this user contribution. Note that the
report code requires the number of real engines so that
it can calculate correctly.
Thanks to Will Evans, NIKE Information Services, USA.
Change 12.171 Cosmetic changes. In members VMAC110,VMAC74,VMACSTX, and
EXTY99U2 VMACTMNT "3TH" was changed to "3RD". In EXTY99U2 the
VMAC110 comment was corrected to TYPE99_2, and in member VMACTLMS
VMAC74 the missing "%%INCLUDE SOURCLIB(EXTYTLMS);" statement was
VMACSTX added at the end (but its absence caused no error, as
VMACTLMS there is only one dataset in the DATA statement!).
Oct 3, 1994
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.170 MXG 12.04 only. The last twelve lines (starting with
ANALCISH "options ..." in lower case) must be deleted; this was a
Oct 1, 1994 testing invocation within the member that doesn't belong!
Changes thru 12.169 were included in MXG Version 12.04 dtd Sep 30, 1994
Change 12.169 DB2 3.1 detail buffer counts by pool/plan in DB2ACCTB has
ASUMDB2A variables QWACBSC, QWACESC, and QLACLOCN added to its
ASUMDB2B KEEP= list in VMACDB2, so that new summary and trending
TRNDDB2A members ASUMDB2B and TRNDDB2B could be added to MXG. In
TRNDDB2B addition, variables QWACPKGN QLACRRRC and QLACRRSE were
VMACDB2 added to the SUM= operand in existing ASUMDB2A/TRNDDB2A
Sep 29, 1994 to support future report enhancements.
Change 12.168 Support for CA's TELEVIEW user SMF record creates three
EXTELEAP new datasets:
EXTELESH TELEAPPL - TELEVIEW Application Logon/Logoff
EXTELETE TELETERM - TELEVIEW Terminal Logon/Logoff
IMACTELE TELESHUT - TELEVIEW Shutdown.
TYPETELE See Change 12.229 update.
VMACTELE
Sep 29, 1994
Thanks to Tom Parquette, MONY, USA.
Change 12.167 Omegamon/CICS V551 SMF record INVALID DATA FOR EXMXT1-10
VMACOMCI occurs when those supposedly packed decimal fields have
Sep 29, 1994 hex zeroes! Each occurrence of &PD. is now preceded by
the double question mark modifier to suppress the message
and the hex dump of the offending record.
Thanks to Sudie Wulfert-Schickedanz, Edward D. Jones, USA.
Change 12.166 Support for CICS/ESA 4.1.0 is added by this change.
EXCICDL3 The changes are compatible, except that new Statistics
EXCICFEC Subtypes will generate messages on the SAS log if you
EXCICFEP do not have MXG 12.04 or later installed.
EXCICFET
EXCICPGG 1.Major enhancements to the CICSTRAN dataset include:
EXCICUSG a. Of real significance, nine new sets of counts and
EXCICXMC durations of long-wanted delays and waits:
EXCICXMG DSPDIOcn/tm - First Dispatch Total Count/Delay
EXCICXMR ENQDIOcn/tm - KC Enqueue Delay Count/Duration
IMACCICS LU61IOcn/tm - LU 6.1 I/O Wait Count/Duration
VMAC110 LU62IOcn/tm - LU 6.2 I/O Wait Count/Duration
Apr 28, 1994 MXTDIOcn/tm - First Dispatch MAXTASK Delay Cnt/Dur
May 17, 1994 RMISIOcn/tm - RMI Suspend Count/Duration
Jun 3, 1994 RMITIOcn/tm - RMI Elapsed Count/Duration
Jun 23, 1994 SZWAIOcn/tm - FEPI Suspend Count/Duration
Jun 30, 1994 TCLDIOcn/tm - First Dispatch TCLASS Delay Count/Dur
Aug 19, 1994 (This delay is especially important
Sep 29, 1994 for sites that have had to throttle
DB2 resource consumption by using CICS
TCLASS limits - finally you can show
your DB2 guy how much delay is being
caused by his poorly designed DB2
transactions!).
b. GMT offset, so that MXG can finally correct start/stop
times from GMT to local for sites which have non-zero
GMT offset in member CLOCKnn.
c. Replacement of one-byte TCLASS with 8-byte TCLSNAME.
d. Removal of variables OPERATOR TCSTG PC31UHWM PC24UHWM
e. Addition of resource variables TCM62IN2 TCC62IN2
TCM62OU2 TCC62OUT for LU 6.1/6.2 messages/characters.
f. Addition of resource variables PC24RHWM PC24SHWM and
PC31SHWM for read-only and shared program storage.
g. Addition of resource variables SZALLOCT SZRCVCT
SZENDCT SZSTRTCT SZCHROUT SZCHRIN SZALLCTO SZRCVTO
and SCTOTCT for FEPI activity.
h. TASKNR contains special character transaction numbers
that MXG decodes as special values of variable TASKNR:
Characters MXG TASKNR Description
'00'X,'III' 13,224,393 System Initialization Task
'00'X,'J00' 13,758,704- Journal Control, Jnr=00-
'00'X,'J99' 13,761,017 Journal Control, Jrn=99
'00'X,'JBS' 13,746,914 Journal Control
'40'X,'TCP' 14,926,807 Terminal Control
(so that these values do not set the "INVALID TASKNR"
error condition in MXG processing).
2.Major enhancements to the subtype 2 Statistics record:
a. Nine new statistics datasets are created:
CICDLIG CICFEPIC CICFEPIP CICFEPIT CICPAUTO CICUSG
CICXMC CICXMG CICXMR
b. Six existing statistics datasets will now have zero
observations with CICS/ESA 4.1:
CICDLIT CICDMG CICDMR CICTC CICTCLR CICTSR
3. Complete list of all new variables in old datasets and
new datasets can be found in member DOCVER12.
Thanks to Edward McCarthy, Health Insurance Commission, AUSTRALIA.
Thanks to Scott Wiig, First Bank Systems, USA.
Thanks to JP Meijer, Standard Bank of South Africa Limited, RSA.
4. The following table lists all CICS Statistics datasets
now created by MXG (note that those with * after Name
will have zero observations with CICS/ESA 4.1 records):
MXG Symbolic MXG DFH
Dataset IBM Exit sfx
Name STID Description of Data Set Name Name
CICAUSS 22 Autoinstalled Terminal Unsolicited STIAUSS AUS AUS
CICAUTO 24 Autoinstall Global STIAUTO AUT A04
CICCONMR 76 ISC/IRC Mode Entry Specific STICONMR CO3 A20
CICCONSR 52 ISC/IRC System Entry Specific STICONSR CO1 A14
CICCONSS 54 ISC Connection - System Security STICONSS CON A21
CICDBUSS 28 DBCTL Global Unsolicited STIDBUSS DBU DBU
CICDLIG 72 DL/I (Global) STIDLIG DL3 A25
CICDLIR 70,7 DL/I Local Specific STIDLIR DL1 A18
CICDLIT* 71 DL/I Local Totals STIDLIT DL2 A18
CICDMG* 15 Domain Manager Global STIDMG DMG DMG
CICDMR* 13 Domain Manager Specific STIDMR DMR DMR
CICDQG 45 TDQUEUE Transient Data Global STITDQG DQG A11
CICDQR 43 TDQUEUE Transient Data Specific STITDQR DQR A10
CICDS 57,5 Dispatcher Domain, CPU each TCB STIDS DS DSG
CICDTB 33 Dynamic Transaction Backout Global STIDTB DTB A05
CICFCR 67 File Control Specific STIFCR FCR A17
CICFEPIP 16 FEPI (pool) STIFEPIP FEP A22
CICFEPIC 17 FEPI (connection) STIFEPIC FEC A23
CICFEPIT 18 FEPI (target) STIFEPIT FET A24
CICIRCB 75 IRC Batch Global STIIRCB IRC A19
CICJCR 49 Journal Control Specific STIJCR JCR A13
CICLDG 27,3 Loader Domain for Program Global STILDG LDG LDG
CICLDR 25 Loader Domain for Program Specific STILDR LDR LDR
CICLSRFR 40 LSRPOOL File stats each File STILSRFR LS3 A09
CICLSRR 37,3 LSRPOOL Pool stats each LSR pool STILSRR LS1 A08
CICM 81 Monitor Domain Global STIM M MNG
CICPAUTO 23 Autoinstall Program STIPGG PGG PGG
CICSDG 90 System Dump Global STISDG SDG SDG
CICSDR 88 System Dump Specific STISDR SDR SDR
CICSMD 7,5 Storage Manager Domain Subpool STISMD SMD SMD
CICSMDSA 9,2 Storage Manager DSA and EDSA STISMDSA SMS SMS
CICSMT 8,6 Storage Manager Task Subpool STISMT SMT SMT
CICST 66 Statistics Domain Global STIST ST STG
CICTC* 3 Task Control Global STITC TC A01
CICTCLR* 58 TCLASS Transaction Class Specific STITCLR TC1 A15
CICTCR 34 Terminal Control Specific STITCR TCR A06
CICTDG 87 Transaction Dump Global STIDTG TDG TDG
CICTDR 85 Transaction Dump Specific STITDR TDR TDR
CICTM 63 Table Manager Global STITM TM A16
CICTSQ 48 TSQUEUE Temporary Storage Global STITSQ TSQ A12
CICTSR* 4 Transaction Statistics Specific STITSR TSR A02
CICUSG 61 User Domain Statistics STIUSG USG USG
CICVT 21 VTAM Global STIVT VT A03
CICXMC 12 Transaction Manager TCLASS STIXMC XMC XMC
CICXMG 10 Transaction Manager Global STIXMG XMG XMG
CICXMR 11 Transaction Manager Transaction STIXMR XMR XMR
Change 12.165 Support for LEGENT's TSO/MON 6.1 adds Service Class Name
VMACTSOM to TSOMCALL and TSOMSYST datasets when MVS/5.1 is run in
Sep 28, 1994 Goal Mode, and adds a number of Workload Manager fields
to TSOMSYST dataset. There can be up to ten sets of the
Service Class fields, but MXG chooses to keep only the
first two sets by default (others can easily be added in
MACRO _KTSOSYS in IMACTSOM, if really needed!). The real
significant change in 6.1 is internal; the transaction
distribution counters were expanded from 1 to 2 bytes (so
you can have a larger interval and not overflow!). Thanks
to LEGENT for lots of lead time, and test data too!!!
Thanks to Arne Lund, LEGENT TSO/MON Development, DENMARK.
Change 12.164 Omegamon CICS V551 SMF user dataset OMCIVSAM has zero obs
VMACOMCI because 2 extra bytes were added between V551 and V550,
Sep 28, 1994 but also because MXG logic error. The MXG logic error:
After the IF SUBTYPE=103 and RECSUBTY=1 THEN DO; line,
change IF VMAXF GT 1 THEN DO _I_=1 TO VMAXF-1; to read
IF VUSEDF GT 1 THEN DO _I_=1 TO VUSEDF-1;
The extra 2 bytes: Change the IF statement preceding
the INPUT ESRES1 statement from
ELSE IF SUBTYPE EQ 102 THEN to read
ELSE IF SUBTYPE EQ 102 OR SUBTYPE EQ 103 THEN
Unrelatedly, variables EGENAPL ERCDNUM and ESTTIME were
removed from the KEEP= for datasets from subtypes 102 and
103, as those variables exist only in the subtype 100,
(and never should have been in the KEEP= list!).
Thanks to Scott Pearson, King County Medical Blue Shield, USA.
Thanks to Shellia Shih, King County Medical Blue Shield, USA.
Change 12.163 Requesting CICS reports with PDB=PDB,TYPE=ALL,SUMMARY=YES
ANALCISH produced 0 observations and no reports because of logic
Sep 27, 1994 errors for this combination. Specifying SUMMARY=NO will
produce all reports except summary. Many lines changed.
Thanks to Tom Albert, John Alden Life, USA.
Change 12.162 Support for Landmark's The Monitor for DB2 is added by
ANALTMDB this significant user contribution; all of the code was
EXTMDDA written by Peter, and it worked correctly "right out of
EXTMDDB the box". Not only does his contribution process the
EXTMDDE Landmark file (from INFILE TMDBIN) to create 4 datasets:
EXTMDDR Dataset Description
FORMATS TMDBDA Interval Statistics
IMACTMDB TMDBDB Thread Detail
TYPETMDB TMDBDE Exception
VMACTMDB TMDBDR Thread Resource
Sep 25, 1994 but also Peter provided 17 report programs that are in
member ANALTMDB!
Thanks to Peter Proppe, Bremer Lagerhaus Gesellschaft, GERMANY.
Change 12.161 Chapter 99
ACHAP99
Sep 25, 1994
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!
The MXG Change Log (member CHANGESS) follows each change
text with the "Thanks to" note that acknowledges the user
that precipitated that Change. Chapter 99 extracts those
notes, lists the major contributors first, and then lists
(alphabetic by last name) every single user that has ever
precipitated a change!
We sincerely thank you and salute you all!
Change 12.160 Support for STK's ICEBERG SMF record subtype 5 adds new
FORMATS dataset ICEBRGDE for Deleted Data Space Release. The
VMACICE statistics for the first five extents released are kept
Sep 24, 1994 individually, as is the total I/O time for all extents.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Mike Schweitzer, StorageTek, USA.
Change 12.159 MXG 12.01 thru MXG 12.03A. Variables QB3Taaaa/QB4Taaaa
VMACDB2 in datasets DB2STAT1/DB2STATS are still missing because
Sep 22, 1994 typos crept in with Change 12.126. The statement reading
IF 2 LE QBSTPID EQ 49 THEN DO;
should read
ELSE IF 2 LE QBSTPID LE 49 THEN DO;
and the statement reading
ELSE IF 80 LE QBSTPID EQ 89 THEN DO;
should read
ELSE IF 80 LE QBSTPID LE 89 THEN DO;
Thanks to Siegfried Trantes, Gothaer Versicherungsbank, GERMANY.
Change 12.158 -APAR OW00484 incompatibly added Open Date to TYPE1415. If
VMAC1415 you install this PTF and do not have MXG 12.01 or later,
Sep 22, 1994 the variables at the end of the type 14/15 record will be
Sep 27, 1994 bad! The variables corrupted are DEVNR, VOLSER, UCBTYPx,
DEVCLASS, DEVTYPE, NEXTENT, EXCPCNT, TRKSALOC,and all
of the HIPERBATCH statistics. Change 12.036 added support
for the new field (inserted in the middle of the record),
but I failed to note the incompatibility and failed to
provide a temporary fix (you can install this fix before
the PTF is installed for protection, although if you are
going to use TYPE1415 you really should request the
pre-release as the actual change is more extensive).
After
TEMPLOC=265+OFFSMF;
Insert
IF SMF14SDC GE 28 THEN TEMPLOC=TEMPLOC+SMF14SDC-24;
-When IBM added the Hiperbatch fields, they did not set a
bit to indicate the 20 bytes were present, so MXG could
only test if there were 20 bytes, and if present, then
INPUT the hiperbatch fields. Unfortunately, IBM APAR
UW05634 added 30 bytes of SMS data to the end of the
record, and a record with SMS but no Hiperbatch satisfied
the MXG test, so false values were read in the Hiperbatch
variables (SMFIOREQ,SMFCHITS,SMFNMWTS,SMFPHIOS,SMFCIOS).
A new APAR, OW08246, now sets RECIND2='....1...'B when
hiperbatch is present, but you may not have that APAR on,
so this change tests both length and/or RECIND2 to read
in Hiperbatch data. A separate bit, RECIND2='.....1..'B
is set by UW06888 when SMS data exists, and that bit is
used to decide to input the new SMS fields of MGMTCLAS,
DATACLAS and STORCLAS. Until you install MXG 12.04 or
later, you can correct the invalid Hiperbatch values that
are caused by UW06888 by replacing the line now reading:
IF LENGTH-COL+1 GE 20 AND NUCB=1 THEN
with these two lines
LENLEFT=LENGTH-COL+1;
IF LENLEFT=20 OR LENLEFT=50 OR RECIND2='....1...'B THEN
The actual change was much more extensive, as UW05634
or UW06888 or maybe some other as-yet-unavailable APAR
also adds statistics for Compressed Format data; these
new variables now exist in TYPE1415 as missing and will
be populated when filled in by IBM:
SMF14CDL SMF14CDS SMF14CIS SMF14TKL SMF14TKN SMF14UDL
SMF14UDS SMF14XF1 SMF14XF2
Thanks to Paul Dzielak, Smith, Barney, Harris, Upham & Co., USA.
Thanks to John Maher, Home Savings of America, USA.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Jeff Berger, IBM, USA.
Thanks to Don Fink, IBM, USA.
Change 12.157 DB2 3.1 dataset PDB.DB2ACCTB has observations, but it was
EXDB2ACB supposed to have zero observations by default, because it
Sep 21, 1994 can be very large (and since it is summarized in DB2ACCT,
I don't think most sites need the additional detail.).
This change added the comment block (that was supposed to
have been there all along) in member EXDB2ACB around the
OUTPUT _LDB2ACB; statement so there now will be zero
observations created unless you change EXDB2ACB. Also,
misleading comments in member IMACDB2 were changed, and
the text of Change 12.033 was revised to be correct!
Change 12.156 Landmark MONITASK variables MONICISP/MONICASP were blank
TYPEMON8 when the transaction in fact had CA/CI splits, because
TYPETMON the names were reused for the MONIDBD dataset. To fix:
Sep 21, 1994 find the tests for TAFLAG6 that set the variables (four
lines) and respell MONICISP as MONACISP and MONICASP as
MONACASP, and then immediately before the %%INCLUDE
SOURCLIB(EXMONTSK); statement insert two lines:
MONICISP=MONACISP;
MONICASP=MONACASP;
to pick up the temporarily stored values.
Thanks to Brent Holm, Blue Cross and Blue Shield of Oregon, USA.
Change 12.155 Change 12.092 was not implemented due to clerical error.
VMACOMCI Now it has been made in the source library.
Sep 21, 1994
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.154 TYPE37 short LAND segment caused INPUT STATEMENT EXCEEDED
VMAC37 error. Between the lines inputting BRFSMADR and BRFSMNAM
Sep 2, 1994 insert: @; IF LENLAND GE 64 THEN INPUT
Thanks to Phillip Wong, Orient Overseas Container Line, HONG KONG.
Change 12.153 Step TESTOTHR may abend with 213-04 for //DISK DDname if
JCLTEST6 your site sends temporary allocations to VIO; that DDname
Aug 30, 1994 is used by VMXGVTOC and must point to real DASD, so the
DD statement now has VOL=SER=XXXXXX and comments telling
you to provide one of your volume serial numbers.
Thanks to Willie Antman, FDIC, USA.
Change 12.152 TYPE72 and TYPE72GO datasets were enhanced with four new
VMAC7072 variables:
Aug 30, 1994 MPL72 - RESIDENT*MULTI*PROGRAMMING*LEVEL
CSTORE72 - CSTORE*BYTES
ESTORE72 - ESTORE*BYTES
TSTORE72 - TOTAL*CSTORE+ESTORE*BYTES
Thanks to Willie Antman, FDIC, USA.
Change 12.151 Support for Landmark Monitor for CICS/ESA Version 1.3 is
IMACTMON completely incompatible; reading the new records with the
TYPETMON old member TYPEMON8 causes INVALID DATA FOR ENDDATE, D12,
Aug 29, 1994 D34, D56, HH, MM, SS, TH and MXG ERROR2.LANDMARK. The
record architecture was changed and only 3 original data
sets are now created (MONITASK, with 70 fewer variables,
MONISYST with 119 fewer variables, and MONIDBDS with 2
new variables), plus one new dataset (MONIDSA), so I
chose to change the member name from TYPEMON8 to TYPETMON
(and the corresponding IMAC from IMACMONI to IMACTMON) so
that I could reduce the size of the datasets created.
If you have installed the TMON de-compression exit from
member EXITMON6, you must update IMACTMON to tell MXG to
use that exit as described in comments in IMACTMON.
These datasets are no longer created by TYPETMON:
MONIHIST - History record, actually went away in 1.0
MONIMRO - MRO segments no longer exist in TA record
MONIUSER - User segments no longer exist in TA record
There is one new dataset, from the "TD" record:
MONIDSA - Interval DSA Statistics
and only these new fields were added to existing datasets
MONITASK - TAENGMTO TADBCTHC
MONISYST - TIDBCTC TIDBTHC
MONIDBDS - *** unknown, 8 bytes undocumented.
In fact, the major changes were the removal of many, many
variables: all of the non-ESA constructs are now reserved
and I chose to delete those old variables in this support
(because dragging them along made the MONITASK/MONISYST
datasets much larger for no good purpose). However, I am
sure that some of your report programs may fail with
VARIABLE NOT FOUND errors because of these deletions, so
you will need a little extra review to remove references
to these deleted variables. Member DOCVER12 identifies
all of the variables that have been deleted, but note
that variables PRIINCHR/PRIOUCHR (Input/Output character
counts) do not exist in MONITASK, and duration variables
JCCPUTM/JCDSPTM/KCCPUTM/KCDSPTM/TCCPUTM/TCDSPTM
IRCPUTM/IRDSPTM/OSWTCPTM/SYSTCBTM/VSDSPTM no longer exist
in MONISYST.
Change 12.150 DB2 Type 102 IFCID=206 record causes ERROR 73-322, CHAR
VMAC102 VARIABLE EXCEEDS 200 BYTES because the LABEL for variable
Aug 29, 1994 QW0206FL ended with a */ instead of a single quote.
Thanks to Marlin W. Thoma, J.C. Penny, USA.
Change 12.149 AS/400 dataset QAPMLTG does not exist, and all references
VMACQAPM to it have been deleted.
Aug 26, 1994
Change 12.148 TYPE50 dataset has missing values after Change 12.102
VMAC50 because the %%INCLUDE SOURCLIB(EXTY50); statement was
Aug 26, 1994 misplaced. It and its adjacent RETURN; statement need to
be moved after the END; statement in line 012600 (i.e.,
after the penultimate END; and before the ultimate END;).
Thanks to Siegfried Trantes, Gothaer Versicherungsbank, GERMANY.
Change 12.147 Omegamon II for SMS Change 12.123 (MXG 12.03/12.03A) had
VMACOMSM a typo which caused execution errors. The "&PIB.2 " after
Aug 25, 1994 OMFS2INT should be "&PIB.2.". In addition, that Change
did not support continued records, but this change added
substantial logic to process continuations. A complete
logical record contains a VOLUME segment, some number of
DATASET segments, each followed by some other number of
JOBS segments for jobs using that DATASET on that VOLUME.
If the total length of these segments exceeds 32768, the
SMF record is truncated at the end of either a DATASET or
JOBS segment, and subsequent continued records start with
the next JOBS/DATASET segment. Supporting these records
required retaining the data from the VOLUME and last
DATASET segment so the segments in continued records have
the volume and dataset information. There is an exposure
to data loss with Candle's architecture - if the first
record of a continuation is the last record in today's
SMF file, then when those continuations are processed
tomorrow, there won't be a volume or dataset record and
those data will be missing. I have suggested that Candle
change their design, so that when they have to continue
segments, that they put the previous VOLUME and DATASET
segments in each record so that each record is a self-
contained description of activity by jobs against dataset
on volumes.
Thanks to Bob Lembo, American Stores Company, USA.
Change 12.146 Reading the NDM VSAM log (instead of the dumped BSAM log)
TYPENDML caused zero observations, because there are ten extra
Aug 25, 1994 bytes at the beginning of the VSAM record that are not in
the VSAM record. To process the VSAM NDM log, change the
statement OFFSMF=-14; to read OFFSMF=-4;
Comments were added to TYPENDML documenting this feature.
Thanks to Jane Chin, Chevron Information Technology, USA.
Change 12.145 Support for NPM Release 2.2 added twelve new subtypes,
EX028CM8 (64x-6Fx), nine new segments (NCV,NGV,NLS,NLW,NRV,NVC,
EX028ER3 NVS,NVT, and NVV), and MXG creates nine new datasets for
EX028INF these NetWare statistics (which look very useful):
EX028ING NPMNWCMD - NETWARE START/STOP/ALTER
EX028INH NPMNCINT - NETWARE COMMUNICATIONS INTERVAL
EX028INI NPMNRINT - NETWARE ROUTER INTERVAL
EX028INJ NPMNLINT - NETWARE LAN BOARD INTERVAL
EX028SU1 NPMNLSUM - NETWARE LAN BOARD SUMMARY
EX028SU2 NPMNGINT - NETWARE SERVER GLOBAL INTERVAL
FORMATS NPMNVINT - NETWARE SERVER VOLUME INTERVAL
VMAC28 NPMNVSUM - NETWARE SERVER VOLUME SUMMARY
Aug 23, 1994 NPMNVMNE - NETWARE MONITOR EXCEPTION/RESOLUTION
New variables were added to NPMINPMT (4), NPMVSVGB (4)
and NPMVSVDV (22). All changes were compatibly made,
although the new subtypes will cause an MXG message to
be printed on the log.
This support has only been syntax checked; no data has
been available for testing as yet.
Change 12.144 The first occurrence of VALDSAMP in the list of LABELs
VMAC7072 should have been R723CSAC.
Aug 23, 1994
Thanks to Tom Parker, Hogan Systems, USA.
Change 12.143 Change 12.060 was supposed to have changed SACCT3 to read
IMACPDB SACCT9, but that part of the change was not made; now it
Aug 22, 1994 has been! I still don't know how this slipped thru!
Thanks to Tom Parker, Hogan Systems, USA.
Change 12.142 Tape Mount Pending duration (the duration from when the
ADOC30 tape mount was issued until the volume is mounted and the
Aug 22, 1994 VOLSER has been verified and the UCB Ready Bit is on) is
included in the TYPE30_4 duration variable DSPDLYTM. I
have erroneously reported (in documentation member ADOC30
and in the text of Change 10.031) that tape mount delay
was included in ACTDLYTM, but it has always been a part
of DSPDLYTM. The text in ADOC30 and CHANGESS has been
corrected.
Thanks to Roh Rhue, PENNCORP Financial, USA.
Thanks to Bob Drischel, PENNCORP Financial, USA.
Change 12.141 Variable SMF74NID was left out of the KEEP= list for data
VMAC74 set TYPE74, and is needed for ANALRMFR reports.
Aug 19, 1994
===Changes thru 12.140 were in MXG PreRelease 12.03A dtd Aug 17, 1994===
Change 12.140 Chuck Hopf's paper on BLSR (Batch Local Shared Resource),
ADOCBLSR a technique for significantly reducing VSAM run times, is
ANALBLSR now contained in member ADOCBLSR. Also, his BLSR analysis
Aug 17, 1994 program, ANALBLSR, has been revised to tell you if it did
not find any datasets that were candidates for LSR, or if
candidates were found that did not meet the minimum
criteria (EXCPs against the file, specified in IOHIGH,
or percentage of total I/O to a single VSAM component,
specified in PCTIO; both IOHIGH and PCTIO are defined in
ANALBLSR and can be changed by the user).
Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.139 MVS/ESA 5.1 dataset TYPE72GO variables starting with PCT
VMAC7072 are not properly calculated nor completely understood.
Aug 17, 1994 (These are sampled values for using/delay from the new
Workload Manager when in Goal Mode, and while they may be
useful, they are not critical, resource measurements.)
First, I was using R723CSAC instead of R723MTVN as the
number of samples in the denominator, but even with that
correction, there are observations with PCTUSCUS (using
CPU) of 249%! Second, some samples are summed across all
address spaces, requiring additional normalization. As
time ran out for building MXG 12.04, I will revisit the
calculations and revise this text in a future release.
For now, regard them as highly suspicious.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 12.138 Support for APAF 2.2 incompatibly added new data fields,
VMACAPAF and now supports up to 12 LPs. Some new variables were
Aug 17, 1994 added to several data sets. Kudos to Amdahl for giving
me not only documentation but actual test SMF data!
Thanks to Gladys Blaylock, Amdahl, USA.
Change 12.137 Variables CYCLE MVSLEVEL and SYSPLEX were added to KEEP=
VMAC74 list for datasets TYPE74CF and TYPE74ST and SYSPLEX was
Aug 17, 1994 added to KEEP= list for TYPE74 (to support ANALRMFR).
No changes were installed while at Woodstock '94 (a/k/a MUDstock)!
Best announcement from the Woodstock Stage:
"To Bruce, from Karen, y'know, the girl you dumped last weekend?
Well, I just won the New York State Lottery! F... You!"
Change 12.136 Support for CA's TLMS 5.4 (whose records are incompatible
IMACTLMS with the previous 5.3 release) creates the same TYPETLMS
TYPETLMS dataset, with a few new variables. You must change macro
VMACTLMS _TLMSVER in member IMACTLMS from 5.4 to 5.3 if you want
Aug 10, 1994 to process records from the old 5.3 release, as MXG's
default now expects release 5.4 format records.
Thanks to Mike Hill, Abbey Life, ENGLAND.
Change 12.135 DB2 Trace SMF 102 IFCID 125 has extraneous observations;
VMAC102 the iteration across each Index used to obtain RIDS was
Aug 10, 1994 using the Length instead of the Number of sections!
Change the BY QWT02R2L; to read BY QWT02R2N; in the line
DO OFFSET=QWT02R2O TO QWT02R2O+(QWT02R2N*QWT02R2L) BY....
inside the MACRO _C102125.
Thanks to Dave Witkowski, Amdahl, USA.
Change 12.134 MXG 12.03 only, and only if %ANALRMFR(PDB=SMF) is used.
ANALRMFR You get "LIBRARY SMF IS NOT IN VALID FORMAT FOR ACCESS
Aug 10, 1994 METHOD SASEB" error (because MXG is trying to read a
SAS dataset from the SMF DDname!). To correct, insert
%IF &PDB EQ SMF %THEN %LET PDB=WORK; before the line
with the comment /* BEGIN CPU REPORTS */.
Change 12.133 Some DDF Summary variables (QLSTxxxx in DB2STAT0) were
DIFFDB2 not de-accumulated in DIFFDB2, causing incorrect counts
Aug 10, 1994 (most notably, BYTES sent/received on the statistics
summary report ANALDB2R). Change 10.210 removed some of
these deaccumulations in error, and some were new fields
added in DB2 3.1. Now, all QLSTxxxx variables, except
for QLSTLOCN (a character variable) are now DIF()'ed in
DIFFDB2.
Thanks to Don Mosley, Farmland Industries, USA.
Change 12.132 BETA93 test records were received, and proved that the
FORMATS initial support in MXG 12.03 was incomplete. Subtypes 0
VMACBETA thru 4 have been tested; there are some relatively minor
Aug 10, 1994 questions that were sent to the vendor for answers that
will cause another change, but with this change, the data
for the tested subtypes seems valid. Note, however, that
subtypes 2, 3, and 4 are pairs of records, one for Start
and one for End, with most activity counts identical in
both records - be careful not to double account! Feb 95:
Beta 93 Records for Version 1.6.22 have now been tested.
Thanks to Manfred Thomas, BHF-Bank, GERMANY.
Change 12.131 In support of the SAS/CPE Product, variable DATETIME has
BUILDPDB been kept in datasets PDB.JOBS, PDB.STEPS, and PDB.PRINT.
BUILD005 DATETIME is the datetimestamp that was used to calculate
Aug 10, 1994 the shift of the job, step, or print event.
Thanks to Tricia Dudley, SAS Cary, USA.
Change 12.130 Dataset MONIMRO variable TAMRTIME was incorrect because
TYPEMON8 the statement TAMRTIME=64*TAMRTIME should have been
Aug 9, 1994 before the %%INCLUDE SOURCLIB(EXMONMRO) instead of just
after it.
Thanks to Dave Konz, Dreyfus, USA.
Change 12.129 ASMIMSLG program may ABEND 002 on DDNAME of IMSMPRS if
ASMIMSLG the IMS log being read contains records greater than 248
Aug 8, 1994 bytes (some Fast Path records are), because the DCB for
this output file was specified in the ASMIMSLG program.
To correct, delete the line MVC DCBLRECL,IMSTY7L
(so that there is no LRECL is specified in the program);
since the JCLIMSLG example has always had a DCB parameter
of RECFM=VB,LRECL=23572,BLKSIZE=23576, that DCB will be
used instead.
Thanks to Ronnie Stake at NORDBANKEN, SWEDEN.
===Changes thru 12.128 were in MXG PreRelease 12.03 dated Aug 4, 1994===
===Changes thru 12.128 were printed in MXG Newsletter 26 Aug 4, 1994===
Change 12.128 Continued corrections and validation of IBM RMF reports.
ANALRMFR Major change was to revert back to use the Partition pct
Aug 3, 1994 CPU busy (instead of Effective CPU busy) because IBM has
again changed back, (and I want to match their reports!).
Some minor corrections in spelling and labelling too!
Change 12.127 Continued corrections and validation of CICS DFHSTUP-like
ANALCISH reports. Fixed problems are:
Aug 3, 1994 No "Terminal" Report.
WORK.CICAUSS.DATA does not exist.
Missing System and Transaction Dump Stats.
Missing Interval Report for "Task Subpools and DSA"
Thanks to Kusol Voratanitkitkul, Health Care Service Corp, USA.
Change 12.126 MXG 12.01/MXG 12.02 only. DB2 Buffer Pool data for DB2
VMACDB2 2.3 pools BP2 and BP32 and for DB2 3.1 pools with BPID=3
Aug 3, 1994 or greater (these are MXG variables QB3Caaaa/QB4Caaaa in
DB2ACCT, and variables QB3Taaaa/QB4Taaaa in DB2STAT1) are
missing because Change 12.033 did not initialize the 3rd
and 4th sets of variables. Many lines were involved in
this change: the new logic for the 3rd and 4th sets of
variables now tests if QB3CPID=. or QB4CPID=. (for
DB2ACCT logic) or QB3TPID or QB4TPID=. (for DB2STAT1
logic), and if true, a new DO group initializes the full
set of variables (including storing into QB3CPID QB4CPID,
QB3TPID or QB4TPID) to initialization only once, and the
existing sum logic is wrapped in a new ELSE DO group.
This should have been caught in my testing, but I did not
have test data with these higher buffer pool IDs.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank, GERMANY.
Thanks to Waldemar Schneider, SAS Europe, GERMANY.
Thanks to Lori A. Masulis, Fidelity Systems, USA.
Change 12.125 Support for BETA93 Report Distribution & Print Management
EXTYBET0-6 System 1.6.0 user SMF record creates six datasets:
IMACBETA BETA0 - Subtype 0 - Input of Lists
TYPEBETA BETA1 - Subtype 1 - Output of Lists
VMACBETA BETA2 - Subtype 2 - Bundling
Aug 3, 1994 BETA3 - Subtype 3 - Recipient Packeting
BETA4 - Subtype 4 - Address Packeting
BETA5 - Subtype 5 - Action Performed Against List
BETA6 - Subtype 6 - Completion of Print Request
Thanks to Manfred Thomas, BHF-Bank, GERMANY.
Change 12.124 DB2 Trace Paring for IFCIDS 15,16,17,18 mis-matched scans
ANALDBTR when there were multiple BEGIN SCANs before an END SCAN.
VMAC102 This was an extensive logical changed; the first three
Aug 3, 1994 bytes of the CUB (QW0015AC,16AC,17AC,18AC) is now stored
into new variable CUBTOKEN and kept in the four T102S0xx
datasets in VMAC102, and ANALDBTR logic for _015PAIR was
revised to insert CUBTOKEN in all BY statements after
QWHCCV, and CUBTOKEN was added to the six KEEP= lists for
the datasets inside the _015PAIR macro. The CUBTOKEN was
created because the final byte of QW0018AC was a hex zero
while the final byte of the other QW001xAC fields was
found to contain a wide range of non-zero values.
(In addition, QW0018AC's INPUT in VMAC102 was changed to
$CHAR4. instead of &PIB.4.; all other CUB fields had been
input as characters. And finally, while cleaning up the
CUB fields that end in AC, I noted that other IFCIDs have
a field ending in AC (the ACE Token) that was mostly CHAR
but sometimes &PIB, so all occurrences were revised to be
input $CHAR4., formatted $HEX8., and added to $NOTRAN.)
Thanks to Dave Witkowski, Amdahl, USA.
Change 12.123 Support for Omegamon II for SMS V100 and V110. Subtype
VMACOMSM 2 record was restructured (compatibly), and new subtype 3
Aug 3, 1994 record was added, but since the subtype 3 replaces the
subtype 1 record in V110, you will need to install the
new MXG version before you process V110 records.
Change 12.122 Support for APAR OW00157 adds variables SMF62MGT,SMF62STR
VMAC62 and SMF62DAT (Management Class, Storage Class, and Data
Aug 3, 1994 Class names) to the VSAM Open Record. Unfortunately, the
fields would be far more useful in TYPE64 Close Records!
Change 12.121 NETSPY 4.4 added four fields to the NCP record that i did
VMACNSPY not decode; the four fields are all PIB4. and replace the
Aug 2, 1994 first 16 bytes of the +26 toward the end of the NCP code:
CFBQUELN='CURRENT*FREE BUFFER*QUEUE LENGTH'
FBQLNHWM='FREE BUFFER*QUEUE LENGTH*HIGH WATER MARK'
FBQLNLWM='FREE BUFFER*QUEUE LENGTH*LOW WATER MARK'
TFQBANCP='TOTAL*FREE QUEUE BUFFS*ALLOC IN THE NCP'
Note that LEGENT told Roger that for NCP Version 6.2, the
MAXFREEB (Max Free Buffers) is now moved to MXG variable
TFQBANCP (at offset 47). I chose to keep both variables.
Thanks to Roger Zimmerman, Kemper Service Company, USA.
Change 12.120 Support for ASTEX 2.0 adds several fields; the new record
VMACDMON can be read by prior versions of MXG, but variable RDUA
Aug 2, 1994 (device unit address) will be unreadable without the MXG
changes (it was EBCDIC, now it's binary, so MXG decodes
the binary back to EBCDIC). Several other new variables
were added to the record (compatibly). I replicated the
six "May/Must Cache" variables that were misspelled with
"H" to be correctly spelled, but also keep the old named
misspelled variables.
Change 12.119 The REXX example statement containing AND FORMAT IT AS
REXXPDB needs to be shortened and an ending quote added to the
Aug 2, 1994 line.
Thanks to Waldemar Schneider, SAS Europe, GERMANY.
Change 12.118 MVS/ESA 5.1 TYPE72GO dataset RTSTRNnn variables may have
VMAC7072 counts for a Service Class Period that does not have any
Aug 2, 1994 response time goal; MXG logic did not properly match the
SCS section with the appropriate RTS section, instead it
carried the RTSTRNnn variables forward. The observations
with bad counts can be identified; they have R723CRTX=0,
but this change corrects the logic, and also corrected a
related problem with R723TYPE for these observations.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 12.117 Support for SMF type 99 (Workload Manager Trace) Subtype
EXTY99U2 2 creates dataset TYPE99_2 for each Service Class Period
IMAC99 with lots of useful detail about what's really happening
TYPE99 inside the new Workload Manager (for example, you can see
VMAC99 the changes in dispatch priority for each workload with a
Aug 1, 1994 "PROC PLOT DATA=TYPE99_2; PLOT PBDP*SMFTIME=SRVCLASS);".
There are many other subtypes in the type 99, many are so
detailed as to be questionable in value, but as the need
arises, additional subtypes will be decoded.
Thanks to Peter Enrico, IBM Poughkeepsie, USA.
Change 12.116 If ANALDB2R was run with only PMACC04=YES specified, an
ANALDB2R unresolved macro reference for MAXINDT was produced. The
Aug 1, 1994 code was corrected. If any other PMACCnn was requested,
along with PMACC04, the error did not occur.
Thanks to Perry Lim, AVCO, USA.
Change 12.115 Monthly trending members MNTHxxxx were revised to take
MNTH70PR advantage of the enhancements made to VMXGSUM by earlier
Aug 1, 1994 Change 12.084; minor cosmetic improvements also made.
Change 12.114 Minor change to this macro now can select ranges of DB2
READDB2 IFCID values.
Aug 1, 1994
Change 12.113 UTILGETM is used to create the SMFSMALL subset file with
UTILGETM JCLTEST6; this revision was really for me, so I can give
VMXGGETM you a trivial invocation of VMXGGETM when I need to see a
ZMXGGETM particular SMF record. UTILGETM now just invokes the new
Aug 1, 1994 VMXGGETM macro with default parameters. You might find
the new macro useful if you are chasing raw SMF records!
Because the new UTILGETM won't work with SAS Version 5,
the original UTILGETM was copied/renamed into ZMXGGETM.
Change 12.112 Support for UniKix Release 4.1 now creates three datasets
FORMATS from UniKix Technologies "CICS-like-under-UNIX"
VMACUNIA product's accounting files:
VMACUNIK UNIKTRAN - Transaction record, one per transaction for
ZMACUNIA those transactions that are being monitored
ZMACUNIK UNIKUSER - User record, one per transaction for those
Jul 29, 1994 users whose transactions are being monitored.
UNIKEVNT - Event record (STARTUP/SHUTDOWN/etc.)
These three datasets are created from either the Unix
Binary file (using TYPEUNIK to read INFILE UNIKIXBI under
UNIX/WINDOWS/OS/2 versions of SAS), or the three datasets
are also created from the UniKix Account Conversion
Program's output ASCII file (using TYPEUNIA to read the
INFILE UNIKIXAS, which can execute under any version of
SAS, so that the ASCII file could be uploaded first and
then processed with mainframe SAS; however, the ASCII
file is twice as large as the binary file). Note that it
is possible to do double accounting; if a monitored user
executes a monitored transaction, there will be two obs
created for that event, one in UNIKUSER and in UNIKTRAN.
I have used common CICS variable names where possible.
See Chapter 10 of the UniKix Administrator's Guide for
more documentation. data fields. The MXG code for the
earlier UniKix Release 4.0 was copied into the members
ZMACUNIA/ZMACUNIK (see comments on their usage); note
that that old code creates only a single dataset,
TYPEUNIK or TYPEUNIA, and all three types of observations
(event, transaction, and user accounting) are contained
in that dataset. Last minute note for MXG 12.03: Only
the Binary support was finished. ASCII (VMACUNIA) will
be completed in next MXG release.
Change 12.112A VARIABLE BCRTBLA HAS ALREADY BEEN DEFINED AS NUMERIC
VMXGHSM results from insufficient testing after Change 12.030!
Jul 29, 1994 Variables BCRTBLA,BCRTLAB, and BCRTCAB must be spelled
BCRTBLX,BCRTLAX, and BCRTCAX in three lines where they
INPUT as CHAR4., and in three lines where they are inside
INPUT functions (i.e., on right hand side of the equality
but they are correctly spelled on the left hand side).
Also, LENGTH BCRTBLA BCRTLAB BCRTCAB 8; was added.
Thanks to Peter MacDonald, USF&G, USA.
Change 12.111 APAR PN56441 corrects DB2 IFCID 239 record, which was
VMAC102 erroneously written as an SMF ID=102 record; it is fact
Jul 27, 1994 the ID=101 SUBTYPE=1 record that creates DB2ACCTP, and
already supported in MXG. Only comments were revised.
Change 12.110 APAR OW01522 adds new value 7 for Extended Sequential to
FORMATS format MG042DS (for variable DSTYPE); the APAR text also
Jul 27, 1994 states that all values will be documented in IGWDSSBC.
Change 12.109 The PAGRT calculation did not match IBMs Paging Report.
VMAC71 Variable PGMIEXAU was added to PAGRT and should not have
Jul 27, 1994 been, and variable PGBKAUIN should have been added but
wasn't! The MXG code changes were to delete the line
PAGRT=PAGRT+PGMIEXAU; and insert PAGRT=PAGRT+PGBAKUIN;
after the line reading DPR=DPR+PGBKAUIN;
Thanks to Ms Foo Hooi Ping, Maybank, MALAYSIA.
Change 12.108 Variable MULTIDD was left out of the KEEP= list for the
BUILD005 PROC SORT of TYPE30_5.
Jul 27, 1994
Change 12.107 MXG CRITICAL ERROR. UNEXPECTED TCP/IP DATA VALUES will
IMACTCP result if you specify a value of 118 in member IMACTCP
VMACTCP for either macro _IDTCPF or _IDTCPT. The comments in the
Jul 26, 1994 IMACTCP member were strengthened that these macros are
only for the archaic version of TCP/IP, but also MXG is
now robust against this error - the logic in VMACTCP now
tests automatically for type 118 before examining what
you specified in those macros, so this won't recur!
Thanks to Dov Brosh, Solomon, Inc, USA.
Thanks to Rich Warren, Solomon, Inc, USA.
Change 12.106 Continued validation of DFHSTUP-like reports uncovered
ANALCISH more minor glitches. Following the first occurrence of
Jul 25, 1994 &CAUS and &CAUT, the macros CICAUTO and CICAUSS need to
be reversed - CICAUSS is invoked after &CAUS and CICAUTO
is to be invoked after &CAUT. The four tests for INOBS=
SDG,SDR,TDG, and TDR must be changed to CSGD,CSDR,CTDG,
and CTDR respectively. After both occurrences of
PROCESS(MXGDS=CICTCR); insert %RPTTCR(MXGDS=CICTCR);
Thanks to Kusol Voratanitkitkul, Health Care Service Corp, USA.
Change 12.105 MXG Tape Mount and Tape Allocation Monitor, ASMTAPES, is
ASMTAPES now healed of all known glitches! This change corrects
Jul 25, 1994 the MIM flag (mounts were always indicated as from MIM),
and correctly identifies PRIVAT/DEMAND mounts (once a UCB
has a PRIVAT mount, all subsequent mounts were flagged as
PRIVAT). With this change, I believe ASMTAPES is safe to
install in production, in place of the old ASMTMNT that
only tracked tape mounts.
- after the line
MNTPEND OI DEVFLGS,DEVPEND FIRS REMEMBER ITS PENDING
insert this new line;
NI DEVFLGS,X'FF'-DEVPVT-DEVSCR RESET PRIVAT/SCRTCH
- the third line after label SETJOB, now containing:
LH R4,UCBASID-UCBCMEXT(,R4) ALL SO WE CAN GET THE ASID
is replaced by these three lines:
ICM R4,B'0011',UCBASID-UCBCMEXT(R4) GET THE ASID
ICM R4,B'0100',=X'00' ZERO OUT HIGH-ORDER HALF OF R4
STH R4,DEVASID STORE THE ASID FOR MIM CHECK
Thanks to Bob Kinney, Kaiser Permanente, USA.
Thanks to Mike McClean, Travelers, USA.
Change 12.104 Support for EMPACT's HIPER-CACHE Version 1.1.1 (INCOMPAT)
VMACHIPR inserted 24 bytes (JCTJOBID,INITTIME,READTIME) in the
Jul 21, 1994 header. You can process the new version's SMF records
(but not the old!) by changing the +2 after the INPUT of
SMFVERS to +26. The actual change creates the three new
variables.
Thanks to Neil Ervin, Huntington National Bank, USA.
Change 12.103 DB2 Trace IFCID=141 (dataset T102S141) was not correctly
FORMATS decoded for DB2 2.3/3.1, and the SQL text was not read.
VMAC102 Change the statement:
Jul 20, 1994 IF QWHSRELN GT 2.2 THEN INPUT QW0141CO &IB.4.
to read:
IF QWHSRELN GT 2.2 THEN INPUT +2 QW0141CO &IB.4.
After INPUT of QW0141HO $CHAR8. and before the @; insert
QW0141LL &PIB.2.
so that the length of SQL text will be read in.
Thanks to Ricky Wafford, MBNA, USA.
Change 12.102 APAR OW04453 corrects SMF type 50 VTAM Tuning Statistics
FORMATS documentation and I discovered that the type 50 record
VMAC50 is actually four different structures, described in VTAM
Jul 20, 1994 Network Implementation Guide (SC31-6419) Table 29 (SNA
Controller), Table 30 (Channel-to-Channel) and Table 31
(Multipath Channel Adapter, MPNCB or CPNCB). All fields
are now decoded, and variable VERSN50 identifies whether
the record is for SNA, CTC, or MPC, and variable ATTCHTYP
identifies if an MPC record is an MPNCB or a CPNCB.
Change 12.101 Documentation of common error messages is now provided in
INSTALL a new section zero at the beginning of member INSTALL.
Jul 20, 1994 These messages are now described, with more detail:
APPARENT SYMBOLIC REFERENCE PIB NOT FOUND
(missing or old dsname for CONFIG= or //CONFIG DD)
INFORMAT $NOTRAN or FORMAT $MGxxxxx or MGxxxxx NOT FOUND
(missing or old dsname for //LIBRARY DD)
LENGTH OF CHARACTER VARIABLE HAS BEEN SET
(has no effect, to be eliminated by SAS, disregard)
Change 12.100 Documentation of the output reports produced by this CICS
UTILCICS utility that prints the contents of your CICS Dictionary
Jul 19, 1994 records is now extensive, with examples, in comments.
Thanks to Danilo Gipponi, SAS Institute, ITALY.
Thanks to Werner Bundsuhuh, SAS Institute Europe, GERMANY.
Change 12.099 Protection for invalid expiration dates (96366,97366) in
VMACDCOL both DCOLLECT and HSM dataset processing now sets the
VMXGHSM xxEXPDT variables to '31DEC2099' when the day-part of the
Jul 18, 1994 Julian date is 366 or greater. (See Change 14.124).
Thanks to Norbert Korsche, OMV, AUSTRIA.
Change 12.098 DB2 report PMSQL01 or PMSQL02 cause MISSING BY STATEMENT
ANALDB2R because IFCID 54 was not included in the list defined in
Jul 18, 1994 MACRO _PMSQL01. Add 54 to that list and the syntax error
will go away.
Thanks to Dave Witkowski, Amdahl, USA.
Change 12.097 NPM Release 2.0 records cause INVALID DATA FOR MGBYTES
VMAC28 and/or INPUT STATEMENT EXCEEDED RECORD LENGTH and/or
Jul 18, 1994 NONZERO COF SEGMENT for NPMSUBTY=214 thru 219, because
no test data was available for validation to catch my
careless errors in the new VTAM monitoring subtypes:
-Remove both occurrences of " MGBYTES " (without a period)
but do not remove the one occurrence of " MGBYTES." (with
a period).
-Remove one occurrence of "TIME 13.3" (with blank between
TIME and 13.3), but do not remove the one occurrence of
TIME13.3 (without the blank).
-The line now reading:
ELSE IF 0D0X LE NPMSUBTY LE 0D5X THEN COFTYPE='VCD';
should read:
ELSE IF 0D0X LE NPMSUBTY LE 0DBX THEN COFTYPE='VCD';
Also, now with real data, variable VADSTIME in dataset
NPMVSVAD is now properly decoded into a datetimestamp.
Thanks to Tom Parquette, Mutual of New York, USA.
Change 12.096 Support for RSD's WSF Release 3.5.1 (INCOMPATIBLE)! The
FORMATS new records do not cause any MXG error, but the dataset
VMACWSF WSFEVTPR was trashed because ACCPRNAM was expanded from 8
Jul 17, 1994 to 16 bytes! For a workaround to read the new records
(but not the old ones), you can change then INPUT of
WSFEVTPR from $EBCDIC8. to $EBCDIC16. The actual change
added a new variable and its FORMAT, corrected MXG logic
that did not read the Account Extension segment, and now
blanks variables that exist only in the ERD records.
Thanks to M. Kirassian, GIA Rhone Alpes, FRANCE.
Change 12.095 DB2 report PMACC02 variables QWACAWTW/QWACAWTR/QWACAWTE/
ANALDB2R QWACALOG were incorrectly normalized. In two places,
Jul 15, 1994 in the ELSE statement following IF QWACAWTR = ., change
both occurrences of QWACAWTW to QWACAWTR. In two places,
in the ELSE statement following IF QWACAWTE = ., change
both occurrences of QWACALOG to QWACAWTE.
Thanks to Caron Knox, Willis Corroon Group, ENGLAND.
Change 12.094 Dataset TYPE30_V was not deleted (due only to oversight)
BUILDPDB after it was copied and renamed into PDB.SMFINTRV in the
BUILDPD3 BUILDPDB/BUILDPD3 logic, so it has now been added to the
BUILD005 DELETE statement of the PROC DATASETS following its last
BUIL3005 reference.
Jul 15, 1994
Thanks to Diane Eppestine, Southwestern Bell, USA
Change 12.093 Cosmetic correction to spelling in labels for variables
VMACNSPY NSPETHR and NSPLFCNT AND LUGTRGT1-LUGTRGT4.
Jul 15, 1994
Thanks to Warren Hayward, TJX Companies, USA.
Change 12.092 OMEGAMON/CICS 550/551 User SMF record datasets OMCIDTCO
VMACOMCI and OMCIDTCT (DATACOM counts) had zero observations and
Jul 13, 1994 datasets OMCISUPR/OMCISUPT (SUPRA) had extra obs (with
missing variables) because DATACOMM records were not
output into the correct datasets. After "MACRO _COMCDTC"
change %INCLUDE SOURCLIB(EXOMCSUT); to (EXOMCDTT) and
change %INCLUDE SOURCLIB(EXOMCSUP); to (EXOMCDTC).
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.091 Variable QPENRECA should have been spelled OPENRECA in
VMACVMXA VM/ESA Monitor dataset VXAPLSRV.
Jul 13, 1994
Thanks to Mitch McKenna, SAS Institute Europe, GERMANY.
Change 12.090 TCP/IP variables APILCLPO.APIRMTPO,FTPLCLPO,FTPRMTPO,
VMACTCP TELLCLPO, and TELRMTPO (port addresses) should have been
Jul 13, 1994 FORMATted $HEX4.; now they are.
Thanks to Jan Van Kemenade, Univ. Rekencentrum Nijmegen, HOLLAND.
Change 12.089 A cosmetic change; the comment named YOUR.SMF.DATA as the
JCLTEST6 sample SMF input DSNAME, but the actual JCL used a name
Jul 11, 1994 of YOUR.SMF.DUMPED.DATA. Now both use the latter name!
Thanks to Philip Pearson, Ansett Australia, AUSTRALIA.
Change 12.088 DB2 Trace IFCIDS=180,181,182,186,190,192,193,194,195, and
FORMATS 198 are now decoded, although the code has only been
VMAC102 syntax checked as of this date. More subtypes and update
Jul 11, 1994 to this text are planned.
Thanks to Bob Brosnan, Goldman, Sachs & Co., USA.
Change 12.087 New analysis routing which matches CICSTRAN with DB2ACCT.
ANALDB2C See comments in the member for how multiple CICSTRAN and
Jul 8, 1994 multiple DB2ACCT transactions for a single unit-of-work
are handled in this initial analysis.
Thanks to Dan Null, Caterpiller, USA.
Change 12.086 Label for variable DVLVSER was incorrect; it is now
VMACDCOL VOLUME*SERIAL*NUMBER.
Jul 8, 1994
Thanks to Joe Faska, Depository Trust, USA.
Change 12.085 Change 12.059 set SUBSYS='VPS ' for VPS output, but did
VMAC6 not also set SUBSYS6='VPS', so the change was not carried
Jul 6, 1994 into the PDB.PRINT dataset; now it is.
Thanks to Tom Parker, Hogan Systems, USA.
====Changes thru 12.084 were included in MXG 12.02 dated Jul 4, 1994====
Change 12.084 New features/enhancements to VMXGSUM were transparently
DOC added to this powerful MXG summarization utility.
VMXGSUM - A dataset name in the INDATA= string can now be a fully
Jul 1, 1994 qualified SAS name like with "INDATA=PDB.JOBS," or
macros can be used, like with "INDATA=_DAY._DSET,".
- It is no longer necessary to use a DROP DATETIME;
statement, nor do you need to assign the real variable
name in an assignment statement. (The DATETIME= option
set up an internal variable named DATETIME). Now, if
DATETIME=VARIABLE, and VARIABLE appears in the ID list,
and the variable name is not DATETIME, then MXG inserts
VARIABLE=DATETIME in the logic, and drops DATETIME.
- New options allow specialized use of summarization that
are described in detail in member VMXGSUM:
CLASS = Allows specifying CLASS and keeps _TYPE_
so that multiple outputs can be created.
MEANOPTS= Allows passing options to the PROC MEANS.
ORDER = Allows insertion of LABEL statement to force
alphabetic order in the output dataset vars.
INCODE1 = Continuation of INCODE= in case the 32K byte
SAS limit (including blanks!) is too small.
INCODE2 = New exit for code insertion after the
normalization phase on the input side.
OUTCODE1= Continuation of OUTCODE=, see INCODE1.
OUTCODE2= New exit for code insertion before the
de-normalization phase on the output side.
- Although these internal changes were implemented in a
transparent manner, so your existing programs that use
%VMXGSUM should not need any changes, all of the MXG
members that invoke it were cleaned up. Now redundant
DATETIME= references were removed, all invocations now
contain INVOKEBY="member" argument to make it easier to
tell which member has executed %VMXGSUM, and
invocations were collimated for clearer reading.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY, who
suggested several of the new options, and who provided sample
implementation code.
Change 12.083 If an invalid value was specified for INTERVAL=, it was
VMXGDUR ignored without any warning; now a warning message is
Jul 1, 1994 printed on the log.
Change 12.082 If TREND database was used for TMNT reports, the graphs
GRAFTMNT were useless since they were designed for daily reports.
Jul 1, 1994 This revision supports TREND data base reporting.
Change 12.081 Analysis of Measured Usage uses both the new TYPE89 and
ANALUSAG existing TYPE72 data to calculate the "bands" for usage
Jul 1, 1994 based pricing of IBM software products. For TYPE89 the
real product name is used; the analysis based on TYPE72
uses the workload definition in IMACWORK to name the
"product". This report will be revised when IBM makes
their report format available.
Change 12.080 Batch LSR analysis could report I/O exceeded 100% if the
ANALBLSR pattern of utilization of a VSAM cluster by multiple runs
ANALDSET of the same job changed, because average value was used.
Jul 1, 1994 This revision uses the sums to accurately calculate the
percentage of I/O attributable to a given component.
Also, it turns out that turning on BLSR suppresses the
Buffer Count in TYPE64 dataset, so those reports were
eliminated, as they were useless!
Thanks to Freddie Arie, Enserch Corporation, TEXAS.
Change 12.079 DB2 3.1 support was enhanced in Change 12.033 for the new
READDB2 buffer pools in the building member VMACDB2. This change
ASUMDB2A adds that support to the READDB2 utility and to the
TRNDDB2A DB2 Accounting summary and trending members.
VMAC102
Jul 1, 1994
Change 12.078 Using ANALDB2R with PDB= on tape was inefficient; it
ANALDB2R could cause three passes of the tape, especially when
Jul 1, 1994 ACCOUNTING reports were requested and neither ASUMDB2A
nor DB2ACCT was found on the first tape volume. The logic
was changed: if we see the PDB= points to a tape dataset,
we now look only for the PDB.DB2ACCT dataset, unless you
explicitly tell us to use the PDB.ASUMDB2A (by specifying
USEACCT=ASUM option in your %ANALDB2R invocation).
The old logic looked first for ASUMDB2A, and if not found
then looked for DB2ACCT, requiring multiple passes of the
PDB= when on tape. While our example JCL in JCLPDB6 does
build the PDB.ASUMDB2A, we can't guarantee you did so, so
we by default go for PDB.DB2ACCT. (The PDB.ASUMDB2A is
smaller and the preferred source, so if it exists it is
wise to specify USEACCT=ASUM for PDB=tape). This change
does cause new messages on the log:
NOTE: DATA SET ... HAS NOT BEEN DEALLOCATED ...
NOTE: LIBREF PDB HAS BEEN DEASSIGNED.
PDB LIBNAME WAS CLEARED TO CHECK DEVICE TYPE.
because to detect if the PDB= points to tape, we must
first open the DDNAME as an INFILE and then clear it!
Change 12.077 The vertical axis specification on the workload plots was
GRAFTRND removed; if the normalization of CPU time or the
Jul 1, 1994 predicted workload growth exceeded 100%, the workloads
disappeared from the graph as they passed 100.
Change 12.076 If SASGRAPH=NO was specified when you invoked GRAFWORK,
GRAFWORK the numbers for CPUTM and % CPU were cumulative totals
Jul 1, 1994 rather than the values for individual observations.
Also, values of EXCPs, IOTM, and MEMR were added to
Thanks to Tom Bell, Rivendel Consultants, USA.
Change 12.075 Type 30 APPC segment offsets should be zero in
VMAC30 MULTIDD='Y' records, but they are not, causing MXG to
Jun 30, 1994 input values in APPC variables. This is an IBM error,
and APAR OW07036 now has PTFs UW09744-UW09746.
If you use TYPE30_4, TYPE30_5 or PDB.STEPS to analyze
APPC resources, you can delete observations with
MULTIDD='Y' and the APPC resource analysis will be valid,
but any EXCP counts in those MULTIDD records will be
lost. However, this MXG fix eliminates the error, and
will work even after IBM fixes the problem: - After the
@; following the input of @101+OFFSMF EXTRADD
insert these two lines:
IF SUM(0,NRUREC,NRCOMP,NRCPU,NRSTOR,NRPERF,NROPER)=0
AND SUBTYPE NE 1 THEN MULTIDD='Y';
- After the END; after the DO group that sets OFFAPPC,
LENAPPC and NRAPPC equal to OFFAPPCC,LENAPPCC,NRAPPCC,
insert this DO group:
IF MULTIDD='Y' THEN DO;
OFFAPPC=.;
LENAPPC=.;
NRAPPC=.;
END;
Thanks to Bill Keller, West Publishing, USA.
Change 12.074 Several DCOLLECT flag variables that were set to 0 or 1
VMACDCOL for NO or YES are now formatted with MGLMSYN and their
Jun 30, 1994 labels now end with a question mark to clarify that they
are YES/NO values. The variables are these:
DSCDFACC DSCDFAVL DSCDFGSP DSCDFSDR DSCFDIRB DSCFDIRR
DSCFIAD DSCFSEQB DSCFSEQR DSCSYNCD
Thanks to Joe Faska, Depository Trust, USA.
Change 12.073 Type 6 may cause INVALID SUBSTR FUNCTION because variable
VMAC6 RLSELEFT should be FORMATed $HEX16. instead of $HEX8.
Jun 29, 1994 (the FORMAT statement is the first occurrence of this
variable and thus determines the variable's length).
The error occurs only if you have modified JES2 to create
the print release time as described in Change 7.137.
Thanks to Andy Vick, Allied Dunbar Assurance, UK.
Change 12.072 ACF2 SMF record subtype 'V' had INPUT STATEMENT EXCEEDED
VMACACF2 error because DB2 and NEXTKEY segment logic was wrong. To
Jun 29, 1994 circumvent (with no data loss), change the statement
INPUT ACVMFSEC $EBCDIC18. @; to read
INPUT ACVMFSEC $EBCDIC8. @;
The actual code change was more extensive. Additionally,
ACF2 SMF record subtype 'D' printed a note: RECORD TYPE
D, EXCESS DATA AT END SKIP=7 on the log. This had no
impact (NEXTKEY data was not read, but is not kept) but
logic for this subtype was also corrected.
Thanks to Russell Ochocki, Investors Group, CANADA.
Change 12.071 Trending of ASUM70PR PR/SM dataset did not support LPAR
TRND70PR 0; replicate occurrences of LPAR 1 variables and change 1
Jun 28, 1994 to zero to include LPAR 0 in TRND70PR (only Amdahl's MDF
uses LPAR zero).
Thanks to John Chan, The Toronto Hospital, CANADA.
Change 12.070 Support for IBM's CRR 1.6 (Cache DASD RMF Reporter) SMF
FORMATS record. The record format was incompatibly changed by
VMACACHE the 1.6 release. Note that if you run a 3990-6 in Basic
Jun 27, 1994 mode, you can't tell that it's a mod-6, because
REPORLVL=03. If you enable the 3990-6 in Enhanced mode,
REPORLVL=06 and the mod-6-only fields will be
non-missing.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Scott Ashby, Wachovia Operational Services, USA.
Change 12.070A NDM data created zero observations in NDMCT dataset, due
EXNDMCT to misspelling in member EXNDMCT. All occurrences of
Jun 23, 1994 NDMST in that member should have been NDMCT.
Thanks to Freddie Arie, Enserch Corporation, TEXAS.
Change 12.069 VM/ESA MONWRITE processing has caused UNEXPECTED/INVALID
VMACVMXA CONTROL RECORD and PROBABLE DATA LOSS DUE TO MONWRITE
Jun 23, 1994 FAILURE when the end of data was at the end of block with
Jul 6, 1994 a 1.13 record; the MXG logic was not sufficiently robust.
To correct the MXG error, find the second occurrence of
BYTELEFT=BYTELEFT-MRHDRLEN; and insert these four lines
after that statement:
IF BYTELEFT LE 0 THEN DO;
BYTELEFT=0;
NRCRRECS=NRCRRECS-1;
END;
Thanks to Ricky Valeroso, City of New York - CDCSA, USA.
Change 12.068 Boole & Babbage CICS Statistics record subtype 0BB02x has
VMAC110 been suppressed by recent IBM CICS changes, causing these
Jun 23, 1994 special records to not be written. Boole's PTFs BPC2347
and BPC2348 change their subtype value to 00B02x, and MXG
test was changed to IF SUBTYPE=0BB02X OR SUBTYPE=00B02X
to support either value.
Thanks to Bill Gecci, Boole and Babbage, USA
Change 12.067 New Measured Usage datasets TYPE89 and TYPE30MU are built
BUILDPDB automatically in BUILDPDB/BUILDPD3. This change was made
BUILDPD3 in MXG 12.01, but the change was not noted in CHANGES.
Jun 23, 1994
Change 12.066 INFOPAC variables REQSTART and REQEND may be incorrect
VMACIPAC for some subtypes - changing the test IF SMFIPSTP NE 1
Jun 23, 1994 THEN to read IF SMFIPSTP NE 4 has cured the problems.
Thanks to Ron Bleeden, Jewel, USA.
Change 12.065 Variables INTBTIME & INTETIME will be missing in interval
VMAC30 TYPE30_V/PDB.SMFINTRV observations which have MULTIDD='Y'
Jun 23, 1994 if you are at MVS/ESA 4.2 or earlier. The GMT
corrections following setting MULTIDD='Y' in VMAC30 must
be executed only if GMTOFF30 is non-missing:
IF GMTOFF30 GT . THEN DO;
INTBTIME=INTBTIME+GMTOFF30;
INTETIME=INTETIME+GMTOFF30;
END;
Thanks to Tom Parker, Hogan Systems, Inc, USA.
Change 12.064 No IPLS/TYPE0 observations with MVS/ESA 5.1 SMF data (but
VMAC0 MXG did print an error message on the log), or a short
Jun 22, 1994 type 0 record could still cause an INPUT STATEMENT EXCEED
Jul 19, 1994 message, because the tests for LENGTH were incorrect.
-In MXG 11.11, change the line reading IF LENGTH GT 31 ...
to read IF LENGTH-OFFSMF NE 31 AND LENGTH-OFFSMF NE 56 ..
-In MXG 12.01 or 12.02, the first LENGTH test should read:
IF LENGTH-OFFSMF NE 31 AND LENGTH-OFFSMF NE 56 THEN DO;
and the second LENGTH test should now read:
IF LENGTH-OFFSMF GE 56 THEN
and the INPUT of SYSPLEX should be @49 instead of @39.
This text was revised between 12.02 and 12.03.
Thanks to Tom Parker, Hogan Systems, Inc, USA.
Thanks to Mike Skopec, Platinum Systems, USA.
Change 12.063 ACF2 variables LIDCDATE,LIDDXPDT,LIDIPDAT and LIDADATE
VMACACF2 can contain hex zeros, causing INVALID DATA messages. By
Jun 23, 1994 inserting double-questionmarks between the variable name
Jul 19, 1994 and the &PD.4. input format, the messages and hex dump
will be suppressed and the variables still set to missing
when these dates do not exist. This change was revised;
the first two variables were corrected in MXG 12.02, the
final two were corrected in MXG 12.03.
Thanks to Phil Seale, Central Regional Council, UK.
Change 12.062 Variable QTPKALL should have been DIF()ed, in addition to
DIFFDB2 variable QTPKALLA, which was already in the DIF() list.
Jun 22, 1994 Without this change, QTPKALL will contain wrong values.
Thanks to Tom Parker, Hogan Systems, Inc, USA.
Change 12.061 PDB.JOBS variable RESTARTS may be incorrect for a small
BUILDPDB number of jobs on the day you implement MXG 11.11, due to
Jun 22, 1994 change 11.269, which renamed MULTIDD to MULTIDD5 for the
SPIN30_5 logic, but didn't protect existing observations
in SPIN30_5 on the first execution. If there were no
MULTIDD records in the SPIN.SPIN30_5, there is no error.
If the SPIN.SPIN30_5 dataset that you are going to use
for the initial run with MXG 11.11 has the variable
MULTIDD instead of MULTIDD5, and if there are any
observations with MULTIDD='Y', and if those jobs are
matched up by the first execution of BUILDPDB, the count
of RESTARTS will be incorrect, but the count will be ok
on all subsequent days. If you really want to correct
this obscure error, you should rename variable MULTIDD in
your SPIN.SPIN30_5 dataset to MULTIDD5 and then run your
first MXG 11.11 BUILDPDB execution. This might not have
been noticed, but it happened to a TSO session, and
RESTART greater than 1 should not occur for TSO!
Thanks to Tom Parker, Hogan Systems, Inc, USA.
Change 12.060 If you needed more than 3 account fields in your PDB, you
IMACPDB had to change IMACPDB, because it (incorrectly) limited
Jun 22, 1994 the number of fields to three. Since MXG 8.8, member
IMACACCT is where you control how many account fields you
keep, so this change only revises IMACPDB so it now has
ACCOUNT1-ACCOUNT9 and SACCT1-SACCT9 specified; that way,
your definition of kept account fields in IMACACCT will
always be in control.
Thanks to Tom Parker, Hogan Systems, Inc, USA.
Change 12.059 Type 6 records from VPS product have UCS='VPS' but had a
VMAC6 SUBSYS='JES2'. Because it may be important to know which
Jun 22, 1994 subsystem created the type record, MXG now sets variable
SUBSYS='VPS ' if UCS=:'VPS';
Thanks to Chuck Hopf, Primerica, USA.
Change 12.058 The MXG Tape Allocation and Tape Mount Monitor, ASMTAPES,
ANALTALO (which replaces the MXG Tape Mount Monitor, ASMTMNT) has
ASMTAPES been fixed and has been running at two MVS/ESA sites, one
ASUMTALO with both SMS and MIM, for two weeks without any ABEND!
BUILDPDB The monitor creates an SMF record for each tape drive
BUILDPD3 allocation event, so actual tape drive usage is measured,
BUILD002 even for dynamically allocated drives, and it creates an
GRAFTALO SMF record (same ID, different subtype) for each tape
TRNDTALO mount event, so human and silo efficiency is measured.
Jun 17, 1994 MXG member TYPETMNT creates three datasets from the SMF
record: TYPETALO for Tape Allocation, TYPETMNT for Tape
Mounts, and TYPETSWP for Tape Error Swaps. Both TYPETMNT
and TYPETSWP are already automatically created in the PDB
by BUILDPDB/BUILDPD3; now PDB.TYPETALO will also exist in
your PDB library. Members ASUMTALO/TRNDTALO provide the
summarization and trending logic, while ANALTALO/GRAFTALO
provide sample printed and graphical reports, and the CPU
cost of the monitor is minimal. See Change 12.105.
Thanks to Bob Kinney, Kaiser Permanente, USA.
Thanks to Chuck Hopf, Primerica, USA.
Thanks to Bill Fairchild, Royal Software Associates, USA.
Change 12.057 Final support for DFSMS 1.2 added a few variables that
VMACDCOL were not in earlier APARs:
Jun 17, 1994 Dataset DCOLDSET variables DCDBDSZ DCDCCSID DCDCUDSZ
DCDDDMEX DCDEXFLG DCDOVERA DCDUDSIZ
Dataset DCOLCLUS variable DCANSTAT
Dataset DCOLMIGS variable UMSDSP
Thanks to John Maher, Home Savings, USA.
===Changes thru 12.056 were in MXG PreRelease 12.01A dated Jun 15, 1994=
Change 12.056 Support for MEMO subtype 6 SMF record creates new dataset
EXTYMEML MEMOLIST. Code was originally added as member XMACMEMO
IMACMEMO in MXG 12.01A, untested, but now has been verified and
VMACMEMO has replaced VMACMEMO in MXG 12.03.
Jun 15, 1994
Jul 7, 1994
Thanks to Jukka Suhonen, VTTK, FINLAND.
Change 12.055 MXG 12.01 only. Change 12.047 DASD RESP changes were not
ANALRMFR spelled right, causing uninitialized variable messages
Jun 15, 1994 and non-printing of the summary report.
Change 12.054 Variables MNSMFTME and MXSMFTME are not kept by MXG and
VMACSMF thus were not in the LENGTH 8 list, but if you were to
Jun 14, 1994 keep them, the LENGTH DEFAULT=4 would cause truncation of
their datetimestamp values, so they are now added to the
LENGTH 8 list in macros _SMF and _SMFTEMP in VMACSMF.
Thanks to Graeme Yeandle, British Telecom, UK.
Change 12.053 Division by Zero was not protected for the calculation of
VMACNSPY T1RSPPC-T4RSPPC when TRANSNO was zero; that block of code
Jun 14, 1994 has now been protected.
Thanks to Jim Wertenberger, Blue Cross Blue Shield of Ohio, USA.
Change 12.052 MXG 12.01 only. The OUTPUT _LDB2ACC in exit member
EXDB2ACB EXDB2ACB should have read OUTPUT _LDB2ACB instead. (Only
VMACDB2 if you used new Buffer Pools would there have been any
Jun 12, 1994 actual problem). See Change 12.033.
Unrelated, I changed the ID=0 statement before IMACACCT's
%INCLUDE in VMACDB2 to a "faker" for better cosmetics.
Thanks to Chuck Hopf, Primerica, USA.
Change 12.051 DCOLLECT variable DCDNMBLK in dataset DCOLDSET is wrong;
VMACDCOL it needs to be multiplied by 1024. Insert a line for
Jun 12, 1994 DCDNMBLK immediately following DCDSCALL=1024*DCDSCALL;
Additionally, add variables DCAHURBA DCAHARBA and DCAASP
to the MGBYTES format list, to be consistent with other
variables that measure space allocated/used.
Thanks to Mark Mustoe, Nestle Foods, USA.
Change 12.050 In 12.01, new dataset TYPE30MU was not protected in the
ANALDSET IEBUPDTE step. Replicate the two "30OM" lines and change
Jun 4, 1994 "30OM" to "30MU".
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.049 TCP APAR PN34837 added 8 undocumented bytes to the TELNET
VMACTCP Server record - the datetimestamp of LOGF. Variable
Jun 3, 1994 TELLOGFT now contains that value.
Thanks to Barry Pieper, Norwest Technical Services, USA.
Change 12.048 INVALID NUMERIC DATA 'SAT' can occur in ASUM70PR if you
ASUM70PR modified IMACRMFI using the example in comments that uses
IMACRMFI the variable named "DAY". Unfortunately, changes made to
Jun 3, 1994 VMXGDUR (which is invoked internally by ASUM70PR) now use
the variable named "DAY" as a numeric variable, causing
the error message. Since the problem only arises if you
have modified IMACRMFI, you can change "DAY" in IMACRMFI
to "DAYSHIFT" to eliminate the conflict. I have changed
the example in comments to now show "DAYSHIFT".
Thanks to John Chan, The Toronto Hospital, CANADA.
===Changes thru 12.047 were in MXG PreRelease 12.01 dated Jun 1, 1994===
Change 12.047 The RMF-look-alike CPU Activity report may show BUSY TIME
ANALRMFR of zero (but the Summary CPU times are correct) due to
Jun 1, 1994 incorrect logic. Change:
Jun 2, 1994 IF CPEF(I) NE . THEN DO; to IF CPEF(I) GT 0 THEN DO;
then 35 lines later, change
IF PEFT(I) NE . THEN ... to IF PEFT(I) GT 0 THEN ...
then 19 lines later, change
IF LPARNAME =: ' ' THEN DO; to
IF LPARNAME =: ' ' OR TOTEFV LE 0 THEN DO;
On the Summary Report, the "DASD RESP" was incorrect; MXG
included both Tape and DASD in its calculation (but on
Device reports the device and LCU detail was correct).
The DASD RESP fix was not included in the Jun 1 tapes.
Thanks to Linda Carroll, American Software, USA.
Change 12.046 Variables TSO2SWAP TSO3SWAP TSO4SWAP TSO2TRAN TSO3TRAN
TRNDRMFI and TSO4TRAN were left out of the NORM1= argument list,
May 25, 1994 and were incorrect in the TREND.TRNDRMFI dataset.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 12.045 "Performance Management in a DFSMS/MVS World" GG66-3252,
VMAC42 by IBM's J.P. Burg is an excellent discussion of use of
May 25, 1994 the new SMS data in type 42 SMF records. Six variables
that he uses in that manual are now created in TYPE42DS
(data set detail) and TYPE42SR (storage class) datasets:
DASDMPL CACHRATE DASDRATE HITPCT CHITPCT CIOPCT
Take a look at John's analysis and discussion!
Change 12.044 This report member has been revised, but work is still in
ANALRACF progress - the PROC TRANSPOSE still raises an error. The
May 24, 1994 text of this change will be revised when report is fixed.
Sections WPDBRACF,WRACCMDS, and WRACLINK were revised.
Change 12.043 The "Candidates to be moved" report of tape data sets is
ANALTMS5 revised so that tape GDGs will be reported as the root
May 24, 1994 name, without the GooVoo, and the estimate of tape feet
will include all volumes in the GDG.
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 12.042 The ANALTAPE analysis of tape drive allocation has been
ANALMNTS updated to report on 3490 tape drive counts; however, it
ANALTAPE will never be as accurate as ASMTAPES analysis, when that
May 24, 1994 Tape Allocation monitor is fully validated! The archaic
ANALMNTS, which can only calculate average tape mount
time, and which has been effectively replaced by ASMTMNT,
was also updated to recognize 3490 tape mounts.
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 12.041 Recognition of TCP/IP event type in SMF type 118 record
VMACTCP was based on the 4-byte string test, but TELSERVER value
May 24, 1994 of 'LOGN' and FTPSERVER value of 'LOGNSEQ' looked same,
so the logic was revised to use the length of the record
(38-44 is API, 72-86 is TELNET, 194-200 is FTP). While
there is a subtype value in the record, it is not fixed
(you specify it, with different parameters, in different
TCP/IP files, with different syntax, so for me to use it
you would have yet another MXG table to update to tell
me what you chose!), so I chose to use record length and
command string to eliminate the ambiguity. I also noted
there are 8 undefined bytes at the end of the TELNET
record that I am investigating.
Thanks to Barry Pieper, Norwest, USA.
Change 12.040 The %VMXGSUM invocation requires the addition of
ASUMPRTR KEEPIN=STDUPLEX TMBUPLEX,
May 24, 1994 to eliminate the UNITIALIZED VARIABLE condition.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 12.039 Member IEBUPDTE now contains both the IEBUPDTE.BAS BASIC
IEBUPDTE program and the IEBUPDTE.SAS program that will create a
May 24, 1994 separate file (named "member.SAS") for each PDS member
of the mainframe source library that was downloaded, as
described in MXG Newsletter TWENTY-FIVE. As any believer
knows, the SAS program was faster (26 minutes versus 66
minutes for MXG 11.11) than the BASIC program!
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.038 Support for BatchPipes/MVS APAR PN45746, which adds local
VMAC91 timestamps for interval begin/end, and for first/last
May 24, 1994 access for the input and output pipe connections.
Change 12.037 Support for AS/400 Transaction Summary Trace File QTRTSUM
ADOCQTRT is added by this user contribution, which has been tested
EXQTRTSU with OS/400 Version 2 Release 2. Instructions for this
IMACQTRT data source are in member ADOCQTRT.
TYPEQTRT
VMACQTRT
May 24, 1994
Thanks to Colin Adams, ENGLAND.
Change 12.036 APAR OW00484 adds Date of Open to TYPE1415 (finally!), so
ANALDSET now OPENTIME will be correct (prior to this APAR, I could
VMAC1415 only use the record' SMFDATE, or SMFDATE-1 if open time
May 24, 1994 was later than SMF time). Variable OPENTM is now created
with the correct duration of open (but only if the APAR
is installed - OPENTM will be missing if OPENTIME is not
based on a true Date of Open). Also, OPENTM was added
to the variables kept in ANALDSET analysis.
Change 12.035 The CICS Shutdown reports delivered in MXG 11.11 are now
ANALCISH revised so that report selection matches IBM's DFHSTUP
May 23, 1994 program (i.e., so that only EOD reports can be selected -
the original report printed everything, EOD, INT, etc, if
those records were found), and individual datasets are
now created for each report (instead of a single dataset
that could require massive WORK space), and the errors in
Change 12.005 are also corrected by this revision. The
comments in the new member describe the new parameters.
Thanks to Kusol Voratanitkitkul, Health Care Service Corp, USA.
Change 12.034 Support for MVS/ESA 5.1.0:
BUILDPDB -TYPE0 new variables
BUILDPD3 PRODNAME - SMF Product Name
BUILD003 SYSNAME - System Name from IEASYSxx member
EXTY44 SYSPLEX - Sysplex Name from COUPLExx member
EXTY72GO -TYPE6 new variable
EXTY7204 CUTSHEET - flag if Cut Sheet Printer
EXTY74CF -TYPE23 new variables
EXTY74ST SYSNAME - System Name from IEASYSxx member
FORMATS SYSPLEX - Sysplex Name from COUPLExx member
IMAC44 -TYPE30_4,TYPE30_V new variables
IMAC7072 IEFUSICH - Flag if IEFUSI changed Region Size
IMAC74 WLMNAME - Workload Name
IMACPDB RESGROUP- Resource Group Name
IMACWORK RPTCLASS- Reporting Class Name
MONTHBLD SRVCLASS- Service Class Name
RMFINTRV SYSNAME - System Name from IEASYSxx member
VMAC0 SYSPLEX - Sysplex Name from COUPLExx member
VMAC6 -TYPE30OM new variables
VMAC23 OMVSEXNP - OMVS Executed Program Name
VMAC30 OMVSOPP - OMVS Parent Process ID Number
VMAC44 OMVSOKR - OMVS I/O Blocks read for remote Socket
VMAC7072 OMVSOKW - OMVS I/O Blocks written for remote Socket
VMAC71 -TYPE30MU new dataset for Measured Usage - See 12.028
VMAC73 -TYPE32 new variables
VMAC74 SYSNAME - System Name from IEASYSxx member
VMAC79 SYSPLEX - Sysplex Name from COUPLExx member
VMAC89 -New type 44 Subsystem Modify Record creates TYPE44
WEEKBLD SMF44PRC - SS06 Proc Name
Feb 14, 1994 SMF44OPT - Initialization Options
May 23, 1994 -TYPE71 new variables
PGBKLPA - LPA Block Page Page-ins
PGBKSYSA - System Pageable Areas Block Page-ins
-TYPE72 new datasets:
TYPE72GO - Goal Mode (Equivalent of TYPE72)
This dataset is of major importance when Goal Mode
is used, as it replaces the TYPE72 data for resources
by Service Class. TYPE72GO is merged in with RMFINTRV
so that correct CPU utilization is constructed whether
you are in Goal Mode or Compatibility Mode.
There are five kinds of observations in TYPE72GO:
I. Address Space Service Class
(Criteria: R723CRCA='Y' AND NOT RPRTCLAS='Y').
=1. Response Time Goal Sub-Class
(Criteria: Has RTS Section)
RESOURCES + RESPONSE-DIST
=2. No Response Time Goal Sub-Class
(Criteria: Has no RTS Section)
RESOURCES
II. Transaction Service Class
=3. (Criteria: Has WRS Section).
RESPONSE-DIST + WM-STATES
III. Report Class
(Criteria: RPRTCLAS='Y').
=4. Address Space Sub-Class
(Criteria: R723CRCA='Y').
RESOURCES
=5. Transaction Sub-Class
(Criteria: R723CRCA NE 'Y').
Only TRAN count from resources.
Variable R723TYPE has value 1 thru 5 to identify what
kind of TYPE72GO observation you are dealing with.
Note that just like we had Report Performance Groups,
Goal Mode has Report Classes in addition to Service
class, and resources in a Report Class record have
already been reported in the task's Service Class.
One bright spot - work can only be reported in one
Report Class. The dim spot - there is no fall-thru
report class created if you define a report class,
so you can't sum Report Class data and be sure you
have all work in a report class, so MXG still must
use only Service Class (not Report Class) to build
the workload variables in RMFINTRV. Member IMACWORK
has been revised, and you must specify what Service
Class is what workload for Goal Mode, just like you
specify what Control Performance Group is what for
compatibility mode. MXG defaults do try to recognize
workload by your Workload Name. The observation is
a Report Class if RPRTCLAS='Y', or is a Service Class
if RPRTCLAS=' '.
TYPE7204 - Subtype 4
This is the RMF Monitor III data for Goal Mode, much
like TYPE72MN was for Compatibility Mode. Sampled
workload delay statistics and swap counts by all 17
swap reasons are captured for each period of each
service class monitored.
-TYPE73 new variable
SMF73CPD - Channel Path Description
-TYPE74 new datasets from new subtype 4:
TYPE74CF - Coupling Facility Utilization
This dataset is a mini-RMF for the Coupling Facility,
with:
-per-engine CF CPU utilization;
-Storage defined and free for Control, CF, and Dump
Space Storage, Dump Space defined and used,
-Path and subchannel use and contention counts, busy,
duration of delay for unsuccessful requests
-List of each structure and its size that is allocated
to this Coupling Facility. See TYPE74ST dataset.
TYPE74ST - Coupling Facility Structure Request Activity
For each Connected Structure to this CF, the request
activity is provided. Multiple observations in
TYPE74ST can be matched to their parent TYPE74CF
observation BY SYSTEM STARTIME R744FNAM. Contains:
-Requests, both SYNC and ASYNC, and separate durations
for service for SYNC and ASYNC, and for delays due to
queue delay, dump delay, high or low priority queue,
and min/max counts for hi and low priority queues and
dump serialization, plus lock contention counts!
-TYPE89 new record for Measured Usage Pricing was added to
BUILDPDB/BUILDPD3/etc. See Change 12.028.
Status:
Almost all records are now supported, and compatibility
mode data verified. Goal mode data has now been validated
and omissions in the first release were corrected. The
RMFINTRV member now processes either GOAL or COMPATIBLITY
mode type 72 data. Note that IBM thinks there may still
be some incorrect values in some of the data fields.
It's really nice to have new records to test with!!!!!
b. MVS/ESA 5.1 changes were compatibly made, so this
prerelease is required only to support new facilities,
i.e., CPU measurement of Goal Mode requires prerelease.
c. These new records have not been added to this PreRelease.
TYPE90 Subtype 10 coded, not yet described herein
TYPE90 Subtype 23 coded, not yet described herein
TYPE90 Subtype 24 WLM - not yet coded -
TYPE90 Subtype 25 coded, not yet described herein
TYPE92 - OMVS File System activity 11 subtypes not coded.
TYPE99 - WLM data - subtype 2 decoded in MXG 12.03.
Final notes: I spent a lot more time on the code than on this
documentation. Please feel free to fax/call if you see problems
with the data, but I feel real confident about the core of the
change.
I am extremely impressed with the design of the new Workload Manager,
and while migrating to Goal Mode may take a little planning, I am
convinced it is the righteous thing to do as soon as its ready;
it's architecture is clearly what we wanted from MVS all along!
See my note on this subject on page 2 of MXG Newsletter TWENTY-FIVE.
INCOMPATIBILITY NOTE: These IMACs were changed to add new
datasets and to support the Workload Manager:
IMAC7072 IMAC74 IMACWORK IMACPDB
If these members exist in your MXG tailoring library, you
MUST retrofit your changes to the new IMAC member, or you
will get "variable GOALMODE not found" errors in RMFINTRV
or "dataset not found" errors in the other members.
Change 12.033 DB2 Version 3.1 support was not completely correct in MXG
DIFFDB2 11.11. The Buffer Pool variables QBnCaaa in DB2ACCT are
EXDB2ACB all wrong (misaligned, because a new reserved field was
EXDB2STB not skipped), and in both DB2ACCT and DB2STATS, the new
IMACDB2 buffer pools (BPID =3 thru 49 for 4K pool, BPID=81-89 for
VMACDB2 32K pools) were not recognized. In addition, DB2STATS
May 23, 1994 did not correctly de-accumulate most of the variables new
in DB2 Version 3.1. If you have not exploited DB2 3.1,
and still have only BP0, BP1, BP2 and BP32 defined, you
can correct the DB2ACCT variables QBnCaaa by changing the
sixteen lines reading INPUT (QBnCGET QBnCSWS ...
to read INPUT (QBnCGET QBnRSVD QBnCSWS ..
However, if you have exploited DB2 3.1 and have defined
the new buffer pools, both DB2ACCT and DB2STATS will now
include the new buffer pools in the existing MXG variable
groups, as described below. Additionally, the interval
statistics for each buffer pool are now provided in the
new DB2STATB dataset. Furthermore, the detail activity
counts for each buffer pool used by each plan execution
are available in the new DB2ACCTB accounting detail,
Nov 25, 1996 revision: Original text stated:
but as DB2ACCTB could be very large, MXG, by default,
does not output any observations in DB2ACCTB (because
the OUTPUT statement is commented out in member
EXDB2ACB). If you actually need the details in
DB2ACCTB, all you need to do is to remove the comment
block, as described in the comments, in member
EXDB2ACB. In that member, you can also conditionally
execute the OUTPUT statement so that only a specific
buffer pool and/or a specific plan name are output.
(This paragraph was revised 22Sep94).
New text: Now DB2ACCTB by default DOES have observations
since it turned out it's not really that large, so you do
not have to do anything
To compatibly support DB2 3.1's up-to-60 buffer pools in
MXG's existing DB2ACCT and DB2STATS datasets and ANALDB2R
reports, I simply redefined the meaning of the four sets
of buffer pool variables that already existed (in DB2ACCT
the variables are QBnCaaa, in DB2STATS they are QBnTaaa,
where n=1,2,3,4). The QB1 and QB2 sets of variables
still are the counts for the (4K) BP0 and BP1 buffer
pools respectively, but the QB3 set of variables (instead
of just containing counts for the (4K) BP2 pool), now
contain the SUM of the activity for all of the OTHER 4K
Buffer Pools (BPID 2->49), and the QB4 set of variables
(instead of just containing counts for the (32K) BP32),
now contain the sum of activity for ALL of the 32K Buffer
Pools (BPID=80->89).
INCOMPATIBILITY NOTE: IMACDB2 was changed to add the new
datasets. If you have modified IMACDB2 into your MXG
tailoring library, you must retrofit your changes using
the IMACDB2 from this MXG library.
Thanks to Tuomo Rahko, KOP Kansallistieto, FINLAND.
Thanks to Waldemar Schneider, SAS Europe, GERMANY.
Change 12.032 Dataset T102S196 for DB2 type 102 IFCID 196 Lock Timeout
VMAC102 Details record, which identifies holder and wanter(s) of
May 18, 1994 lock requests that resulted in the timeout of a DB2 task,
is now populated by this change. T102S196 contains all
details on the lock request that timed out, and identity
details of the first three holders of an incompatible
lock (the first three agents that caused the timeout.)
Thanks to Majid Abai, Southern California Edison, USA.
Change 12.031 STK's ICEBERG dataset ICEBRGCH is trashed, because there
VMACICE must be a "+1" before "INTENCUR $CHAR1." so that MXG
May 18, 1994 is properly aligned with each data segment. Let me point
out that STK, just like IBM, measures disk capacity in
"Million Bytes" and not "Mega-Bytes"; MXG always converts
sizes in bytes to Mega-, or Giga- bytes, so a 3380 with
a DASD capacity of 630 "Million Bytes" can really only
store 601 true "Mega Bytes" of data!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 12.030 All instances of INPUT XXXXXXXX MSEC8. were replaced by
DOC INPUT XXXXXXXX &PIB.8.6 ... @; XXXXXXXX=XXXXXXXX/4096;
May 18, 1994 because the MSEC8. format sets XXXXXXXX to missing if the
value is greater than 24 hours! While SAS is aware of
this defect, it will not be corrected until SAS Version 7
and I couldn't wait that long! The specific case that
precipitated the error was a CICS Shutdown record which
had total wait time of 25 hours, but all occurrences were
changed (311 times in 29 members) just to be sure. (Note
that IBM's DFHSTUP report did not handle the 25 hour time
either - it reported only 1 hour!).
NOTE: MSEC8. PIB8.6/4096 CPU TIMER UNITS
Change 12.029 Labels for variables DS4VTOCE and DS4VTOCI were reversed.
VMXGVTOF
May 18, 1994
Thanks to John Taylor, Newport Management Corporation, USA.
Change 12.028 Support for Measured Usage License Charges new SMF record
EXTY30MU type 89 (MVS/ESA versions 3.1.3, 4.2, 4.3, and 5.1) and
EXTY89 enhancements to type 30 (MVS/ESA version 5.1 and later).
FORMATS The new architecture is well described by IBM in manual
IMAC30 GC28-1098-00. The new TYPE89 dataset has one observation
IMAC89 for each interval (default, and maximum, one hour) for
TYPE89 each "registered product" that had usage during that
VMAC89 interval. TYPE89 data will be summarized by IBM's IFAURP
May 18, 1994 reporting program to calculate total hourly product usage
Jun 24, 1994 daily, and then the fourth-largest daily-hour during the
month is used as the basis for Measured Usage Charges.
When IBM releases IFAURP, MXG will replicate the report.
For MVS/ESA 5.1 and later, new dataset TYPE30MU will
report on each address space that uses any "registered
product". This preliminary change is based only on the
documentation - no records are yet available to test!
Change 12.027 Candle's OMEGAMON for CICS 550/551 user SMF record DSECT
VMACOMCI was wrong, affecting the contents of OMCISYST dataset.
May 17, 1994 New variable SMRECNT (count of transactions) is created,
and fields are now correctly input. Change these lines:
SMOASID &PIB.2. /*ADDRESS SPACE ID */
SMRES3 $EBCDIC6. /*RESERVED AREA */
SMOFLGS &PIB.4. /*SYSTEM FLAGS -- */
SMRES4 $EBCDIC3. /*RESERVED AREA */
SMCVTTZ &PIB.4. /*GREENWICH MEAN TIME OFFSET */
to read:
SMOASID &PIB.2. /*ADDRESS SPACE ID */
SMRES3 $EBCDIC2. /*RESERVED AREA */
SMOFLGS &PIB.4. /*SYSTEM FLAGS -- */
SMRECNT &PIB.4. /*output transaction rec count*/
SMCVTTZ &PIB.4. /*GREENWICH MEAN TIME OFFSET */
and add SMRECNT to KEEP= list for OMCISYST.
Thanks to Linda S. Berkley, Amdahl, USA.
Change 12.026 Jobs with JCL errors before execution (i.e., ABEND='JCL')
BUILDPDB were not output in PDB.JOBS; they are in PDB.NJEPURGE due
BUILD005 to Change 11.226. Find
May 17, 1994 ((INREASON=' ' OR INREASON='JR' OR INREASON='JT')
and change it to read
((INREASON='JR' OR INREASON='JT')
Thanks to Jack Hwang, Great American Reserve Insurance Co., USA.
Thanks to Jerry Byers, Great American Reserve Insurance Co., USA.
Change 12.025 TYPE26J2 INPUT STATEMENT EXCEEDED error due to truncated
VMAC26J2 type 26 SMF record; field SMF26NRA does not exist in the
May 17, 1994 record in at least one MVS/ESA 4.3 site (although it does
exist at other sites). To circumvent, replace two lines:
SMF26NRA &PIB.1.
@;
with these two lines:
@; IF SMF26LN8 GT 2 THEN INPUT SMF26NRA &PIB.1. @;
ELSE SMF26NRA=0;
The actual MXG change was more extensive.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 12.024 MXG Tape Allocation and Mount monitor ABENDs were caused
ASMTAPES by a typo, wrong field was moved into LOCLINFO (which
May 17, 1994 caused INPUT STATEMENT EXCEEDED in TYPETMNT), and STIMER
loop was relocated to reduce CPU cost (ASMTAPES now takes
about twice the CPU time to monitor both tape mounts and
tape allocations as ASMTMNT to monitor just mounts).
-Find the two lines:
L R5,QBDFELMP-QDB(,R1) GET 1ST ELEMENT IN QUEUE
LTR R1,R1
and change the second line to read
LTR R5,R5
Be careful to change the correct LTR instruction, as
there is a valid LTR R1,R1 just three lines earlier.
This is the typo causing the SRB abends in the monitor.
-Find LOCKLOOP EQU *
Delete that STIMER, and then four lines later, find and
replace the line BNZ LOCKLOOP with these four lines:
BZ UNLOCKED
STIMER WAIT,BINTVL=THETIME
B LOCKLOOP
UNLOCKED EQU *
This change eliminated the high CPU utilization
-Find and delete the line:
MVC SRUSER,JCTUSER
Find the two lines:
SPACE 1
MVC SRRSTM,JMRENTRY READER START TIME
and insert a third line as shown below:
SPACE 1
MVC SRUSER,JMRUSEID LOCLINFO FIELD
MVC SRRSTM,JMRENTRY READER START TIME
Change SMFUSER DS CL7 to SMFUSER DS CL8
Change SRUSER DS CL7 to SRUSER DS CL8
This correction solved the TYPETMNT record error.
May 25, 1994 status:
The monitor now only occasionally fails, and we are
examining dumps of two allocation events that are the
cause - TMS initialization of tape volumes, and when an
ATL doesn't have a tape volume in the library. The
earlier concern for MIM and SMS see unwarranted, as the
monitor is now functioning in those environments.
Thanks to Bob Kinney, Kaiser Permanente, USA.
Change 12.023 CICS Statistics dataset CICLSRR index variables will be
VMAC110 wrong if all LSR pools do not have indexes; an LSR pool
May 15, 1994 without indexes will have index variables from the prior
LSR pool that did have indexes, because MXG did not
set missing the index variables when A08FLAGS NE 'Y'.
To correct, all index variables that were INPUT in the DO
group IF A08FLAGS='Y' THEN DO; are now set missing in
the immediately following ELSE DO; group.
Thanks to Anita A. Bradley, Virginia Power, USA.
Change 12.022 This utility to convert character variables containing
UTILCVRT Hex (Binary) data from ASCII back to EBCDIC was listed in
May 10, 1994 Newsletter TWENTY-FIVE, but did not exist in MXG 11.11;
it now exists and is self-documenting.
Thanks to Damian Stevenson, Policy Management Systems, AUSTRALIA.
Change 12.021 This utility to count CICS type 110 records by APPLID
UCICSCNT produces unclear counts, because there must be an
May 9, 1994 OUTPUT; statement just before the last END;
Thanks to Chris Powell, Vancouver Stock Exchange, CANADA.
Change 12.020 CICS Statistics dataset CICDBUSS variables STACTIME and
VMAC110 STADTIME were missing, because their INPUT should have
May 5, 1994 been TODSTAMP8. instead of MSEC8.
Change 12.019 Type 42 subtype 14 record (ADSM) offsets have now been
VMAC42 corrected by IBM, causing INVALID ADSM SECTION TRIPLET
May 4, 1994 message, and MXG typing errors caused incorrect values.
After first ELSE IF SUBTYPE=14 THEN DO; delete the line
OFFPROD=OFFPROD+4;
After the second ELSE IF SUBTYPE=14 THEN DO; change line
OFFADSM=OFFADSM+1+OFFSMF; to now read
OFFADSM=OFFADSM-3+OFFSMF;
In the INPUT statement for SUBTYPE=14, the final period
is missing from the input format for YYYY (&NUM.4 must be
&NUM.4.) and for MO,DD,HH,MM,SS (&NUM.2 must be &NUM.2.).
Thanks to Harry Price, Florida Power and Light, USA.
Change 12.018 Type 30 Interval records with MULTIDD='Y' do not have a
VMAC30 CPU section, which is where the GMT offset is stored, and
Apr 22, 1994 thus INTBTIME and INTETIME were not corrected from GMT to
local time. Since GMTOFF30 is a retained variable, the
times can be corrected (as long as the MULTIDD record is
found after another type 30 which has a CPU section was
found) by inserting the correction logic:
INTBTIME=INTBTIME+GMTOFF30;
INTETIME=INTETIME+GMTOFF30;
inside the DO group which sets MULTIDD='Y';
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 12.017 Variable BUFNO is now documented by IBM as always zero;
ADOC1415 the number of buffers is valid in JFCBUFNO. MXG now sets
VMAC1415 IF BUFNO LE 0 THEN BUFNO=JFCBUFNO
Apr 22, 1994 so you won't have to read this note in the future!
Thanks to Tom Elbert, John Alden Insurance, USA.
Change 12.016 CA-DISPATCH 5.1 corrupted READTIME (See Change 11.342) is
VMAC6 now corrected by CA PTF T97E056.
Apr 22, 1994
Thanks to Giovanni Dossena, Einchem Elastomeri S.R.L., ITALY.
Change 12.015 FMXGSID and FMXGUCBL functions ABEND 0C4 with SAS 6.08 at
FMXGSID TS407, but work on earlier versions. This is SAS error
FMXGUCBL related to pre-V6 style user written functions where the
Apr 21, 1994 SSI field has a min and max arguments of 0 and function
Sep 21, 1994 is invoked with zero arguments, and may be fixed in SAS
future SAS maintenance (MXG Newsletter 26 said it was
fixed in TS410, but it wasn't and may not be fixed in
TS420 maintenance), but it is circumvented by changing:
SETSSI AF000000 to SETSSI AF010000
For current status, see SAS usage note V6-SYS.SYS-09293.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt AG, GERMANY.
Change 12.014 NDM type FP causes INPUT STATEMENT EXCEEDED error. Find
VMACNDM INPUT +8
Apr 18, 1994 NDMSCC $CHAR4. /*CMD*COMPLETION*CODE*/
and remove the "+8" from the INPUT line.
Thanks to Chuck Hopf, Primerica, USA.
Change 12.013 MXG 11.11 addition of TYPE77 dataset to BUILDPDB/BUILDPD3
BUIL3001 (see Change 11.351) had two problems:
BUIL3518 - If you have added TYPE77 processing to your BUILDPDB,
BUIL3606 "ERROR: OPEN OF FILE WORK.TYPE77.DATA FAILED, ANOTHER
Apr 18, 1994 COPY OF THE FILE IS OPEN." occurs. You must "unchange"
added TYPE77 processing by tailoring your site's PDB.
your tailoring in members EXPDBINC,EXPDBVAR,EXPDBCDE
and EXPDBOUT, removing the _VAR77, _CDE77, VMAC77, etc.
I'm sorry for this aggravation to those of you who had
enhanced their PDB, but I had to add TYPE77 to the PDB
so that ANALRMFR reports would not fail!
- JES3 PDB was not fully tested, and the changes for JES3
were incomplete, causing "DATASET TYPE77 NOT FOUND".
In member BUIL3001, add VMAC77 to the INCLUDE list.
In members BUIL3518 and BUIL3606, insert _VAR77 after
_VAR75, and insert _CDE77 after _CDE75.
-Revised Oct 19, 1994: The actual change also relocated
the _CDE26J3 invocation in BUILD3606 and BUIL3518 to be
after the _CDE30 invocation, so that the length of the
ACCOUNTn variables is controlled by IMACACCT, but the
text did not indicate this change was also made.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Thanks to Kenneth D. Jones, SHL Systemhouse, CANADA.
Change 12.012 SMF Simulator CISIZE analysis miscalculated 3380 tracks
ANALSMF and cylinders for CISIZE=26624. Since that is clearly an
Apr 15, 1994 irrational size for 3380s, no real harm was done, but the
"ELSE IF CISIZE=22528 OR CISIZE=26624 THEN DO;" block
was expanded into separate DO groups, one for each CISIZE
and TRK3380=CEIL(CINUM/1); is calculated for 26624.
Thanks to George Janvrin, ITT Life Insurance Corporation.
Change 12.011 CONTROL-D SMF record caused INPUT STATEMENT EXCEEDED ...
VMACCTLD because the semi-colon after the INPUT of JTYPE should
Apr 14, 1994 have been an at-sign-semicolon.
Thanks to Ms. TAN Siew Peng, United Overseas Bank, SINGAPORE.
Change 12.010 Zero or too few observations in dataset NSPYLANS. The
EXNSPYLS MXG logic (in the "Exit" member EXNSPYLS) that OUTPUTs
Apr 13, 1994 only if there was activity recorded, did not test all of
the resource variables, and caused valid observations to
be not output. These variables must be added to the list
of variables in the SUM() function:
OF LLFRABK1-LLFRABK5,OF LLSERAL0-LLSERAL8,
OF LLSERRS0-LLSERRS8,LSTSNOFB,LSTSNOFN,
LLBYTEIN,LLBYTEOU,LLFRAMIN,LLFRAMOU,LSTFSIFB,LSTFSIFN,
LSTFSOFB,LSTFSOFN,LSTMCIFB,LSTMCIFN,LSTMCOFB,LSTMCOFN,
LSTOHIFB,LSTOHIFN,LSTOHOFB,LSOTHOFN,LSTSNIFB,LSTSNIFN
Yes, it really is worth taking the sum of all of those
variables and only outputting when something is non-zero;
you will waste lots of DASD space if you output every
segment in every record, but you can see for yourself by
removing the IF SUM(...) test completely and comparing
with the above enhanced test criteria.
Note that other LANSPY datasets are also controlled in
their Exit members; see Change 9.165 in CHANGESS.
Thanks to Alan Wick, Chevron, USA.
Change 12.009 IMS Log processing is incorrect. For multiple trans per
TYPEIMSA program schedule, the one occurrence of NSMGPROC should
Apr 13, 1994 have been spelled NMSGPROC. The earlier text of this
change is revised; there are no outstanding problems with
IMS Log processing except for the spelling error. See the
IMS Technical Notes, above (or in Newsletter 26).
Thanks to Cary Jones, Phillip Morris, USA.
Change 12.008 Message "UNRECOGNIZED TPX VERSION TPXVER=202" deletes all
VMACTPX TPX records; that version number was not expected. Insert
Apr 13, 1994 ELSE IF TPXVER='202 ' THEN TPXVER=' 2.0'; after the line
ELSE IF TPXVER='200 ' THEN TPXVER=' 2.0';
Variable TPXSNAME (Session Name) was also added to the
TPXAPLON dataset, and processing the 08 record no longer
tests for TPXVER but instead uses length of segment to
determine what data is present in each segment.
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Change 12.007 Message "** WARNING LMS SMF RECORD TYPE ..." is created
VMACLMS in error, causing true LMS records to be flagged and then
Apr 13, 1994 deleted. The test IF ITISLMS NE 'LMS ' THEN DO;
must be changed to IF ITISLMS NE: 'LMS' THEN DO;
because LMS2 is now stored instead of LMS in that 4-byte
field. (This was reported earlier and should have been
fixed in MXG 11.11, but I failed to make the change!).
Thanks to Doug Mayward, Walsh America, USA.
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Change 12.006 The SYNCTIME is incorrect in type 71, 73, 74, 76, 77, 78,
VMAC71 and 79 datasets (but was correct in type 70 and 72). The
VMAC73 correct equation for the GMT offset must be:
VMAC74 GMTOFFxx=100*FLOOR((STARTIME+DURATM-SYNCTIME+10)/100);
VMAC75 (the +10 was missing).
VMAC76
VMAC77
VMAC78
VMAC79
Apr 12, 1994
Thanks to Mike Skopec, Platinum Technology, USA.
Change 12.005 CICS Shutdown totals for report terminals column xaction,
ANALCISH report transactions column restarts, and report programs
Apr 9, 1994 column newcopy were wrong. Change all three occurrences
of T4=T5+... to T4=T4+....
ANALCISH can also fail with syntax errors, if there are
too many observations for the LSRPOOL SUMMARY, FILES, or
LSRPOOL FILE reports. Those reports will be redesigned
in a future change; you can circumvent the error by
commenting out the %CICSTAT2 invocation for those three
reports:
%CICSTAT2(CICLSRR,LSR,LSR);
%CICSTAT2(CICFCR,FCR,FCR);
%CICSTAT2(CICLSRFR,LSF,LSF);
Thanks to John Vasilakos, New York Life Insurance, USA.
Thanks to Kusol Voratanitkitkul, Blue Cross Blue Shield Ill, USA
Change 12.004 Variable UMLEVEL must be added to the KEEPIN= list. The
DAILYDSN migrated datasets are incorrectly reported as level 2 if
Apr 5, 1994 this error is not corrected.
Thanks to Steve Talley, U.S. Army Personnel Info Sys Command, USA.
Change 12.003 ASTEX can create three SMF records; the comments now show
IMACDMON how to define _DMONID if you create three different IDs:
Mar 29, 1994 MACRO _DMONID 231 OR ID=232 OR ID=233 %
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Harmuth Beckmann, Karstadt AG, GERMANY.
Change 12.002 This is a major change to OPC support, and new JCL is now
JCLTEST6 required by this INCOMPATIBLE CHANGE. See the complete
VMACOPC documentation and JCL example in member VMACOPC. The text
Mar 29, 1994 of this change was rewritten May 17, 1994
Apr 9, 1994 -Type 24 physically split records are now supported, but
May 17, 1994 two new DDNAMEs are required in your JCL, and DSN=OPCTEMP
must have been previously allocated and cataloged:
//OPCTEMPW DD DSN=OPCTEMP,DISP=SHR
//OPCTEMPR DD DSN=OPCTEMP,DISP=SHR
I reconstruct those split records by writing them to the
OPCTEMPW DDNAME and then read the reconstructed records
from the OPCTEMPR DDNAME after the OPCLOG has been read.
New MT0 record type "G" caused INVALID MT0 RECORD error.
-Record type used to be an EBCDIC number, but now can be a
character value; MXG's 11.11 fix to support the new type
"G" was incomplete:
after the @; after the INPUT of MT0TYPE, insert line
IF MT0TYPE=. THEN INPUT @47+OFFSMF MT0TYPE &PIB.1. @;
-Dataset OPC29 did not have all its observations:
the semi-colon ";" that is after the INPUT of EXRSTPNR
must be changed to an at-sign-semi-colon "@;".
Thanks to Randy Shumate, Mead Data Central, USA.
Thanks to Waldemar Schneider, SAS Europe, GERMANY.
Change 12.001 Member ANALDSET in MXG 11.11 is in error. ANALDSET lines
ANALBLSR OR OPEN='OUTPUT' should read OR OPEN='OUTPUT' THEN
ANALDSET LSRSTAT='N'; LSRSTAT='N';
Mar 29, 1994 for ANALDSET to execute without error. However, if you
Apr 8, 1994 use ANALBLSR, it will fail because all of the variables
that are required by ANALBLSR were not kept in ANALDSET.
(The wrong ANALDSET member was moved after testing!).
To run ANALBLSR, you must first make these changes to
ANALDSET (you can also request a replacement ANALDSET on
a 3-1/2 "stiffie" PC diskette):
- add COMPONT to KEEP= for TYPE64.TYPE64
- add EXCPDASD EXCPTAPE IOTMDASD IOTMTAPE to KEEP= for
TYPE30.TYPE30_4
- insert these lines after BUFNO=BUFDRNO;
IF COMPONT=:'INDEX' AND BUFDRNO=0 AND ACBBUFNI GT 0
THEN BUFNO=ACBBUFNI;
ELSE IF COMPONT=:'DATA' AND BUFDRNO=0 AND ACBBUFND GT
0 THEN BUFNO=ACBBUFND;
- add (IN=INTYP64) after SORT64.TYPE64 in the SET
statement following DATA ADDPROG.ADDPROG;
- add EXCPDASZ EXCPTAPZ IOTMDASZ IOTMTAPZ to the
RETAIN list following IF INSTP THEN DO;
- insert these four lines after TYPETASZ=TYPETASK;
EXCPDASZ=EXCPDASD;
EXCPTAPZ=EXCPTAPE;
IOTMDASZ=IOTMDASD;
IOTMTAPZ=IOTMTAPE;
- insert these four lines after TYPETASK=TYPETASZ;
EXCPDASD=EXCPDASZ;
EXCPTAPE=EXCPTAPZ;
IOTMDASD=IOTMDASZ;
IOTMTAPE=IOTMTAPZ;
- add EXCPDASZ EXCPTAPZ IOTMDASZ IOTMTAPZ to the DROP
statement before PROC SORT DATA=DSETOPEN.DSETOPEN....
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Thanks to Neil Ervin, Huntington Service Company, USA.
LASTCHANGE: Version 12
=========================member=CHANGE11================================
/* COPYRIGHT (C) 1984-1994 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is Production MXG Version 11.11, dated Mar 26, 1994.
MXG Production 11.11 was dated Mar 26, 1994, thru Change 11.361
MXG Newsletter TWENTY-FIVE, Mar 26, 1994, thru Change 11.347
Early PreRelease 11.11 was dated Mar 9, 1994, thru Change 11.338
MXG PreRelease 11.10 was dated Feb 14, 1994, thru Change 11.316
MXG PreRelease 11.09A was dated Jan 10, 1994, thru Change 11.290
MXG PreRelease 11.09 was dated Dec 17, 1993, thru Change 11.266
Early PreRelease 11.08 was dated Nov 1, 1993, thru Change 11.238
MXG PreRelease 11.07 was dated Oct 4, 1993, thru Change 11.203
Early PreRelease 11.07 was dated Oct 1, 1993, thru Change 11.192
MXG PreRelease 11.06 was dated Sep 1, 1993, thru Change 11.164.
MXG PreRelease 11.05 was dated Aug 10, 1993, thru Change 11.150.
MXG PreRelease 11.04 was dated Aug 10, 1993, thru Change 11.149.
MXG Newsletter TWENTY-FOUR, Aug 2, 1993, thru Change 11.140.
MXG PreRelease 11.03 was dated Jul 26, 1993, thru Change 11.140.
MXG PreRelease 11.02 was dated Jul 6, 1993, thru Change 11.126.
MXG PreRelease 11.01 was dated May 20, 1993, thru Change 11.084.
Early PreRelease 11.01 was dated May 15, 1993, thru Change 11.068.
Prior Production 10.10 was dated Mar 15, 1993.
Member CHANGES repeats sections I, VIII, and IX of MXG Newsletter 25,
but you MUST also read MXG Newsletter 25 in member NEWSLTRS for major
technical discussions that are not repeated herein.
Contents of member CHANGES
0. HOT FLASH NOTES AFTER NEWSLETTER TWENTY-FIVE WAS PRINTED
I. MXG Software Production Version 11.11, dated March 26, 1994
VIII. Incompatibilities and Installation of MXG 11.11.
IX. Documentation of MXG Software.
X. Changes Log
0. HOT FLASH NOTES AFTER NEWSLETTER TWENTY-FIVE WAS PRINTED
OPC Version 1.2.0 had INPUT STATEMENT EXCEEDED error, new subtype that
is now supported, and still exposure. See Change 11.356.
MXG Tape Mount and Allocation Monitor now works at 2 out of 3 sites.
See Change 11.358.
Problem with zeroes in Cache RMF Reporter Records (Newsletter 25 MVS
Techical Note) is a fixed problem, but maybe not just due to RMF. I
missed phone call with all the details! Fax if you need update.
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
Previously, I also said Z6086442 was required, but SAS Technical
Support corrected me; Z6086442 is already included in 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 Sep 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 still had open problems or were potentially incorrect
when MXG 11.11 was built. Contact Merrill for current status.
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.
NDM - Connect/Direct has only been validated for some records.
See Change 11.326.
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 83-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.237 ANALDB2R can now report from a PDB on tape.
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.
ASMTAPES 11.360 MXG Tape Mount and Allocation Monitor works 2/3.
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 11.025 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:
NEXTCHANGE: Version 11
Change 11.361 The offset for MCCAVSN was hardcoded and thus wrong for
VMXGHSM some levels of HSM; now, instead of INPUT +16, the logic
Mar 25, 1994 is OFFV=65+MCCNVSNO; INPUT @OFFV ....
Thanks to Gary Matney, Twentieth Century Investors, USA.
Change 11.360 The MXG Tape Mount and Allocation Monitor is a major
ASMTAPES extension to MXG's existing MXGTMNT Tape Mount Monitor.
Mar 24, 1994 Now, both tape mounts and tape allocation-deallocation
events are recorded in SMF so you can measure how long
each tape drive was used by what job. The new monitor is
provided in ASM source code in member ASMTAPES and works
fine at two sites (one using MVS/ESA 4.3 with MIM plus
SMS, the other is at MVS/ESA 4.2), but at MVS/ESA 3.1.3
site with both MIM and SMS, the new monitor program
either waits doing nothing or ABENDS gracefully. So if
you really need this monitor now, read Change 11.101 and
then assemble member ASMTAPES (it still creates program
named MXGTMNT) and check it out. I think it is highly
likely it is ok with MVS/ESA 4.2 or 4.3, but your
feedback as to where it works and when it doesn't will
help validate for everyboth. Since both MIM and SMS get
involved in allocation, they may or may not be the
trigger, but we are actively working on the SRB dumps to
understand and fix the program for all environments.
Thanks to Bill Fairchild, Royal Associates, USA
Thanks to Chuck Hopf, Primerica, USA
Change 11.359 If you modified the interval in ASUMTMNT, GRAFTMNT will
GRAFTMNT not correctly place the points on the graphs since it
Mar 24, 1994 was using the HOUR of the time as the axis. It now uses
the time at 3600 second intervals.
Thanks to Chuck Hopf, Primerica, USA
Change 11.358 ASUMHSM, TRNDHSM, GRAFHSM provide some ability to report
ASUMHSM on dataset movement caused by HSM. Since this can be a
TRNDHSM significant contributor to batch run times as well as TSO
GRAFHSM response, you may find these summarization, trending, and
Mar 24, 1994 graphical analysis of HSM useful.
Thanks to Chuck Hopf, Primerica, USA
Change 11.357 The second pair of variables named LLSNAFB/LLSNAFN are
VMACNSPY now named LLSNAEB/LLSNAEN, and LLSNAEB was added tothe
Mar 24, 1994 MGBYTES format (the "E" vars are for SNA over Ethernet).
Thanks to Warren Hayward, TJX, USA.
Change 11.356 Change 11.352 was revised after new iterations. Type 35
VMACOPC caused ABEND that was fixed, and subtype 'G' is now
Mar 24, 1994 supported. There are some spanned subtype 24 records
that MXG does not yet handle correctly; at present all I
could do was to recognize I missed a spanned record with
a message on the log; this only affects the OPC24xxx
data sets, and will be fixed soon. Fax if you need it.
Thanks to Randy Shumate, Mead Data Central, Inc.
Thanks to Maureen Walshe, IBM Nordiska Laboratoirer, SWEDEN.
Change 11.355 Change 11.351 was revised after the Mar 23 early tapes
BUILDPDB were sent. The WEEKBLD/WEEKBLDT/MONTHBLD members had not
Mar 24, 1994 been revised until Mar 24.
Change 11.354 CICS Statistics variables A21LUTTM and A21SNTTM were not
VMAC110 correct; a real value of 30 minutes was reported as only
Mar 24, 1994 .03 seconds.
==Changes thru 11.353 were in MXG 11.11 created March 23, 1994===
Change 11.353 LEGENT SAR records had a number of fields added in 1993
VMACSAR that are now supported in MXG. The maintenance has no
Mar 23, 1994 version/release, only Change #05- Change #9 in DSECT!
Thanks to Bob Mattingly, ARCO-EIS, USA.
Change 11.352 OPC records caused INPUT STATEMENT EXCEEDED RECORD LENGTH
EXOPC24X for TRLRCTYP=35 (delete all references to TRLPOS35). For
IMACOPC TRLRCTYP=24 MT0TYPE=9 (expand IF MT0TYPE NE 6 THEN to
VMACOPC IF MT0TYPE NE 6 AND MT0TYPE NE 9, and expand 7 LE MT0TYPE
Mar 23, 1994 LE 8 to 7 LE MT0TYPE LE 9). Support was added for the
Mar 24, 1994 MT0TYPE='G' (MT0TYPE is a number, so character 'G' =199)
which creates new dataset OPC24_G (not to be confused
with existing dataset OPC24D_5, which caused the new exit
and dataset macros to be EXOPC24X for OPC24_G dataset).
OPC support was revised after March 23 tapes shipped.
Thanks to Randy Shumate, Mead Data Central, USA
Change 11.351 RMF dataset TYPE77 is now automatically created by MXG's
BUILDPDB BUILDPDB/BUILDPD3 algorithms. TYPE77 reports ENQUE
BUILDPD3 conflicts and delays, and is expected in ANALRMFR for
BUILD001 replication of IBM RMF reports from MXG datasets. Logic
BUILD003 in WEEKBLD/WEEKBLDT/MONTHBLD now also expectes the TYPE77
BUILD518 dataset. Added Apr 18: This change is INCOMPATIBLE if
BUILD606 you have tailored BUILDPDB to add TYPE77 processing. See
WEEKBLD text of Change 12.013. This change was also incomplete
WEEKBLDT for JES3.
MONTHBLD
Mar 24, 1994
Change 11.350 Additional CICS Shutdown Reports were added. One problem
ANALCISH with Mode Table report (many pages, all zeros) with all
Mar 23, 1994 APPLIDs went away when a single APPLID was reported, but
this will be investigated as soon as data tape received.
Also, Last Reset time is different between IBM & MXG.
Thanks to Neil Ervin, Huntington Bank Service Company, USA.
Change 11.349 Variable SHEETPRN is now automatically added to PDB.PRINT
IMACPDB to count sheets printed.
Mar 22, 1994
Thanks to Jill Hansen, South Dakota Education, USA.
Change 11.348 Variable DVLNUCBA in dataset DCOLVL is now formatted as
VMACDCOL HEX8 and is LENGTH 5 (because it is numeric, five bytes
Mar 22, 1994 are required to store all possible hex digits).
Thanks to Al Rozewski, Parker Hannifin, USA.
==Changes thru 11.347 were printed in MXG Newsletter 25 dated 26Mar94===
Change 11.347 Support for Boole & Babbage CICS/Manager Statistics data
EXCICBBD in type 110 SMF record, subtype BB02 (which MXG sets back
EXCICBBF to SUBTYPE=2 for processing), Statistic STIDs:
EXCICBBG STID DATASET DESCRIPTION EXIT MEMBER VARS
EXCICBBL 200 CICSBBSI SIT EXCICBBS 52
EXCICBBR 201 CICSBBRC RCT EXCICBBR 47
EXCICBBS 202 CICSBBLT LT X EXCICBBL 55
FORMATS 203 CICSBBFC FCT EXCICBBF 57
IMACCICS 204 CICSBBGL GLOBAL PERFORMANCE EXCICBBG 37
IMACICBB 205 CICSBBDL DLI EXCICBBD 44
VMAC110 Those 6 datasets are created, but they will have zero obs
Mar 20, 1994 and only 15 variables unless you enable processing - see
member IMACICBB for enablement procedure and comments.
Adding this support uncovered several errors in field
alignment (three sets of CPU fields) that will be fixed
by Boole's PTF BPC2312 which you must request and install
for that dataset to be valid.
Thanks to ???, VW Wolfsburg, GERMANY.
Change 11.346 Netmaster 2.2 added new variable SMFNCUSR to type 39 data
VMAC39 that is now decoded and added the TYPE39 datasets. This
Mar 19, 1994 is the only reported change in Netmaster 2.2 records.
Thanks to Colin Bowen, Old Mutual, SOUTH AFRICA.
Change 11.345 TCP/IP addresses contained blanks when only one digit was
VMACTCP used for a node; now the blanks are stripped out by using
Mar 19, 1994 TELLOCAL=COMPRESS(TELLOCAL); on all addresses.
Thanks to Wanda Prather, Johns Hopkins University APL, USA.
Change 11.344 Support for CADAM V3R2 Statistical Data plus corrections
VMACCADM to MXG were provided by this user enhancement. See the
Mar 18, 1994 excellent notes at the beginning of the member.
Thanks to Jouke van Schepen, Fokker Aircraft BV, NETHERLANDS.
Change 11.343 NPM Type 28 NPMLANOD dataset (added in NPM Version 2) did
VMAC28 not decode CSL section correctly, causing INPUT STATEMENT
Mar 18, 1994 EXCEEDED with NPMSUBTY='A0'x, which is 4-bytes shorter
than the 'A1'x subtype. The four final fields LCSLRPTO-
LCSLRSFR are now input only for NPMSUBTY=0A1X and three
new variables LCSLPDUD,LCSLMFRD,LCSLURFR are instead
input for NPMSUBTY=0A0X.
Thanks to Pat McGuire, Texas Instruments, USA.
Change 11.342 CA-DISPATCH 5.1 corrupts READTIME in TYPE6 records - the
VMAC6 date can be 1-2 days in the future! CA stores a 01x in
Mar 18, 1994 the 1st byte of READTIME as a flag. A real read time of
Sep 22, 1994 00021CE8x (00:23:04) is corrupted to 01021CE8x (47:59:16)
and those 48 hours are added to midnight of read in date!
My guess was that CA decided that since 0083D600x is 24
hours, they could use the 1st byte of time for DISPATCH,
(just like CA uses the first byte of date for CA7), but
that is not the case; CA now acknowledges that READTIME
field is being corrupted and CA Level 2 is working at the
one reporting site to develop a fix. I had already added
protection in MXG 11.11 to reset the first byte to zero:
Replace READTIME SMFSTAMP8. @;
with READCADI $CHAR8. @;
IF SUBSTR(READCADI,5,1) GT '01'X THEN
SUBSTR(READCADI,5,1)='00'X;
READTIME=INPUT(READCADI,SMFSTAMP8.);
but now the site reports the READTIME is off by 2 hours,
so it appears the time part of READTIME is just bad,
until CA develops a fix.
See Revision by Change 12.199; 1,1 changed to 5,1.
Thanks to Giovanni Dossena, Einchem Elastomeri S.R.L., ITALY.
Change 11.341 TYPE94 variables SMF94Axx were labeled as EJECT when they
VMAC94 should are AUDIT, and variable SMF94EIN/SMF94EPM were
Mar 17, 1994 dropped from the KEEP= list, as they do not exist, and
could be confusing!
Change 11.340 Support for STC ICEBERG 9200 Disk Array Storage Subsystem
EXICECHA creates four datasets, one for each subtype of the SMF
EXICEDEV interval record which are provided by StorageTek:
EXICEDRV ICEBRGSY - Capacity and Space Utilization - per Subsys
EXICESYS ICEBRGCH - Channel Interface Statistics - per channel
IMACICE ICEBRGDV - Device and Its Cache Statistics - per device
TYPEICE ICEBRGDR - Drive Module Statistics - per drive module
VMACICE The range and content of the ICEBERG statistics are quite
Mar 9, 1994 impressive & comprehensive for this new technology, with
utilization counts and durations provided. This support
has been syntax checked, and simulated test data has been
processed, but no real-world users have used the data yet
Change 11.339 MXG 11.08 thru MXG 11.10. the last 380 lines of this RMF
ANALRMFR Report member were inadvertently deleted. The lines were
Mar 7, 1994 restored in MXG Early 11.11, without a Change number.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
==Changes thru 11.338 were in the MXG Version Early 11.11 dtd Mar 8, 94=
Change 11.338 APAR UW04108 adds new variables to TYPE42 datasets:
VMAC42 TYPE42SR: ICLS RCLS SEQIOS
Mar 7, 1994 TYPE42DS: ICLS RCLS SEQIOS
Sequential I/Os are now counted separately (SEQIOS) and
are NO LONGER included in cache statistics (candidate
I/Os and hits). RLCS are Record Level Caches, ICLS are
Inhibit Cache Loads. ICLS only include those ICLS that
are set by DCME, not those by the STARTIO driver.
An additional APAR due out later this year adds even more
valuable instrumentation to the data set statistics:
TYPE42DS: BLKSIZE DEVNR STORCLAS VOLSER
S42AMDRB S42AMDRR S42AMDWB S42AMDWR
S42AMSRB S42AMSRR S42AMSWB S42AMSWR
S42AMZRB S42AMZRR S42AMZWB S42AMZWR
The long-needed VOLSER and DEVNR will be the first volume
for most multi-volume or striped datasets; however, for
sequential SAM access, there will be one record per
volume. The new Access Method fields (S42AMxxx) are
generated only for access methods that support DCME; the
new S42AMxxB variables count blocks read/written for
sequential/direct/directory and the S42AMxxR fields will
contain the corresponding I/O delay time (they are not
yet implemented). 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). Note
how IBM is making life simple for us both, providing me
with early documentation so this support is already in
place in MXG 11.11 for when you get the APARs!
Thanks to Jeff Berger, IBM SSD, USA.
Change 11.337 CA's TMS can cause a type 80 (RACF) record to be created
VMAC80A for BLP processing, (a ZAP from CA is required to enable
Mar 7, 1994 creation of the records), but they exposed an MXG design
error: variable RESNAME was blank and variable OLDDSN
contained resource name. MXG now correctly inputs the
Resource Name into variable RESNAME; I should then store
RESNAME into OLDDSN only if RACFEVNT=04 (a RENAME), but
since OLDDSN always has contained the Resource Name, and
since you should not have to change your reports, I chose
to continue to put Resource Name in both RESNAME and
OLDDSN variables.
Thanks to Simon Hendy, Reader's Digest European Systems.
Change 11.336 Boole & Babbage CMF PTF BPM4681 adds new variables to
VMACCMF these existing datasets:
Mar 6, 1994 CMF27C93 C279WEH,C279WER,C279WFM
CMF27CSD CMF27CHN,CMF27CU2,CMF27DEV,CMF27LCU,
CMF27MDR,CMF27OBR,CMF27UA1,CMF27UA2,
CMF27uty, and CMF27VOL (the VOLSER!)
In the CMF27CSD dataset, the existence of the new fields
can be identified by testing CMF27VOL; if it is non-blank,
the record was created after PTF BPM4681.
Thanks to Matthew McCue, United Parcel Service, USA.
Thanks to John Piccone, United Parcel Service, USA.
Change 11.335 A minor correction to the revised VMXGSUM summarization;
VMXGSUM if the first data step was not required by the SORT, the
Mar 6, 1994 PROC MEANS looked for MXGSUM1 when it wanted MXGSUM2;
also, a specious error message when the length of the
INDATA= string was less than 40 bytes was eliminated. It
needs to be stressed that the changes made to VMXGSUM are
INCOMPATIBLE if you have tailored any of these members:
ASUMDBDS ASUMDB2A ASUMDOS ASUMHPCS ASUM70PR
DAILYDSN GRAFDB2 GRAFLPAR TRNDDB2A
You must retrofit your tailoring, starting with the new
member in MXG 11.11 (see the text of Change 11.309).
Change 11.334 Batch LSR for VSAM can produce incredible savings, by
ANALDSET using memory for buffers instead of repetitive I/O to the
ADOCBLSR same record. Jobs cost less, use less CPU, fewer I/Os,
ANALBLSR and run in tens of minutes instead of tens of hours. This
Mar 6, 1994 new analysis by Chuck Hopf adds new variables in existing
ANALDSET program (that reads SMF and combines type 14/15,
type 64, and type 30 data) to its output dataset DSETOPEN
which is then used as input to ANALBLSR's algorithms to
identify the jobs and VSAM files that could benefit from
BLSR. ANALBLSR also reports any existing Batch LSR usage
and will suggest increase or decrease in buffering where
appropriate. Implementing Batch LSR requires no change
to the application; only a simple JCL change is required,
and example JCL is in member ANALBLSR. Chuck's full
research paper on this timely subject will be in member
ADOCBLSR when it is available. Chuck points out that for
random access to the same records/index, increasing the
number of buffers (BUFNI,BUFND) does not eliminate I/O.
You would expect that if the data was in the buffer VSAM
would find it there, but actually without Batch LSR, I/O
is done instead of lookaside into the buffers! One case
of an Index with only 6 records had one million EXCPs for
a single step; using BLSR with 10 buffers reduced the I/O
count to seven! ANALBLSR lets you set thresholds of the
amount of memory you want to use, and the percentage of
the total I/O for the step, before it will be selected as
a candidate for Batch LSR, and is self-documenting. This
is still ongoing research.
Thanks to Chuck Hopf, Primerica, USA.
Change 11.333 ANALDB2R PMAUD02 Authorization Failure report had N/A for
ANALDB2R table/object name, when there should have been a name.
DIFFDB2 The length of a SUBSTR() was incorrect, causing tests for
IMACDB2 character values to be incorrect. The DB2PM manual was
READDB2 used to decide when a Target/Owner is printed, and it
Mar 6, 1994 says that they are not printed for "ARCHIVE", yet their
report does print it, so we revised our logic to match!
ANALDB2R PMSTA01 Statistics report timestamps printed
were unclear or misleading. There are two sets of
timestamps; the first is the time range of the data that
was read, the second is the range of data summarized on
that page, if INTERVAL= is specified. Also, DIFFDB2,
IMACDB2, and READDB2 were corrected to use _LDB2STA
instead of the hardcoded PDB.DB2STATS, and IMACDB2 and
READDB2 now know about the new DB2 3.1 dataset DB2ACCTP.
Thanks to Wai Choong Mak, Development Bank of Singapore, SINGAPORE.
Change 11.332 Support for Candle's Omegamon II for SMS user SMF record
EXOMSMDV creates two new datasets:
EXOMSMJB OMSMSDEV - DASD Device Statistics
IMACOMSM OMSMSJOB - JOB and DSNAME activity on each volume.
TYPEOMSM This code has been tested with actual data, but has not
VMACOMSM been extensively validated by real users, yet!
Mar 5, 1994
Change 11.331 The contributed RACF reports program WPDBRACF had to be
ANALRACF changed due to an apparent change in the way that some
Mar 4, 1994 formatted values were named in the PROC TRANSPOSE. The
RENAME= list for dataset RACFREP2 was revised.
Thanks to Neil Campbell, Inland Revenue, ENGLAND.
Change 11.330 DB2 Audit Detail report, Completion Code, was incorrect,
ANALDB2R causing "INVALID NUMERIC DATA" message on the SAS log.
Mar 4, 1994 Two tests for QW0083AD=0 and two tests for QW0087AD=0
should have tested for hexadecimal character zero instead
of numeric. The two pairs of statements now reading :
IF QW0083AD=0 THEN .... and IF QW0087AD=0 THEN ....
must be changed to read:
IF QW0083AD='00'X THEN ... and IF QW0087AD='00'X THEN ...
Thanks to Wai Choong Mak, Development Bank of Singapore, SINGAPORE.
Change 11.329 CICS/ESA DFHSTUP Shutdown Statistics Reports can now be
ANALCISH printed by MXG, either from a raw SMF file, or from a PDB
VMAC110 library (with minor modifications to BUILDPDB). This is
Mar 4, 1994 a significant contribution that uses ESA CICS datasets to
replicate the important IBM Shutdown reports. You can
// EXEC MXGSAS
//SMF DD DSN=YOUR.SMF.TYPE110.records,disp=shr
%ANALCISH(PDB=SMF);
to generate all reports from raw SMF data. You can also
generate these reports regularly, from your PDB, but you
will need to tailor BUILDPDB so that it copies all of the
CICS statistics datasets from the WORK file into the PDB.
You must add, in member EXPDBOUT, this code:
PROC COPY IN=WORK OUT=PDB;
SELECT CIC:;
and then you can invoke %ANALCISH(PDB=PDB); to print
shutdown reports for all CICS regions. Additional macro
arguments let you select date/time/region, and to select
only the desired report.
An minor error in VMAC110 was also corrected; member
IMACCICS is now included by its VMAC, instead of in its
TYPE member or by BUILDPDB. This clerical oversight only
affected me when exploiting my new "_L" logic, but should
have no effect in the field!
Note for the experts: I needed to do this so that I
could null out the CICSTRAN data set (which has high
volume, and is not currently used by ANALCISH) when
I ran against SMF data, and the mislocated %INCLUDE
did not let me. Normally you would null out a dataset
by EDITing the product's IMACxxxx member and change
its "_L" macro's dataset name to "_NULL", but you can
also null out any MXG dataset on the fly, without EDIT
of the IMACxxxx member, by using this syntax:
%INCLUDE SOURCLIB(VMACSMF,VMAC110);
MACRO _LCICTRN _NULL_ %
DATA _VAR110; _SMF; _CDE110;
(You must be at SAS 6.08 for the _NULL_ operand to be
a valid argument of the OUTPUT statement!)
In addition to producing the CICS Shutdown Report, member
ANALCISH lets you see what variable from what MXG dataset
is used for what report field, by reading the code! This
set of reports has been long overdue; the most important
reports have been implemented for both CICS 3.2 and 3.3,
but there are more reports (especially the detail reports
by transaction) that were not finished in time for 11.11.
Thanks to Willi Weinberger, Gothaer Versicherungsbank, GERMANY.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 11.328 Division by zero if there were no TSO transactions in an
TRNDRMFI interval. Change PCTTRIV=TRIVTRAN/TSOTRAN*100; to read
Mar 4, 1994 IF TSOTRAN GT 0 THEN PCTTRIV=TRIVTRAN/TSOTRAN*100;
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 11.327 MXG 11.09A and 11.10 only. Change 11.270 caused INVALID
TYPEMON8 DATA FOR TIAPREQ in the MONISYST dataset if the Landmark
Mar 4, 1994 record was from 8.1 with an archaic history segment (i.e.
when LENGTH=2276). The test in MXG for IF LENGTH GE 1464
should have been IF LENGTH EQ 1464. (The error did not
affect the MONITASK dataset, and the history segment is
no longer created by Landmark.)
Thanks to John Goodstat, Gardner Merchant, ENGLAND.
Change 11.326 Sterling's NDM has been renamed to Connect Direct 1.7.01
VMACNDM and the format of the PT record changed, causing INVALID
Mar 4, 1994 DATA for HH messages. Replacing the single line reading
Mar 21, 1994 INPUT +30 with LOC=LENGTH-21;INPUT @LOC corrected some
records, but there are "PT" records with invalid values
for date/times of 000000000001000Ax & 2800000000FC5B10x
that I need to talk to Sterling about, but I can't find
anyone there to return my call, and I only have the PT,
CT, & MC segments corrected thus far, and I still have
no response from Sterling. If you need to process NDM
records now Connect Direct, send us a fax request, ande
we will advise you of the current status.
Thanks to John Goodstat, Gardner Merchant, ENGLAND.
Change 11.325 Type 42 subtype 6 read from VSAM SMF caused STOPOVER.
VMAC42 (There was no error when dumped BSAM SMF was read.)
Mar 1, 1994 Calculation of these three offsets did not include the
"+OFFSMF" at the end of the line. They should read:
OFFJDDSO=OFFJDDSO-3+OFFSMF;
OFFDSIOO=OFFDSIOO-3+OFFSMF;
OFFJDDSO=OFFDSNXT-3+OFFSMF;
The GMT conversion algorithm should also be changed to:
GMTOFF42=100*FLOOR((SMFTIME-SMF42PTE+10)/100);
Thanks to H. Placht, RWD Gmbh Datenverarbeitungsgesellschaft, GERMANY
Change 11.324 Variables SAMPSKPD, RMFIIIRC and INTRVSYN were always
VMAC7072 blank, because variable CONVFLAG should have been input
VMAC71-VMAC79 as PIB1 instead of PIB2.
Feb 28, 1994
Thanks to Scott Ashby, Wachovia Operational Services Corp., USA.
Change 11.323 MXG 11.09-11.10 only. Change 11.246 added support for
IMAC28 NPM 2.1.0, but in IMAC28, macro _L028NWD should have
VMAC28 spelled its dataset name as NPMNWDWD instead of NPMNWCWD.
Feb 28, 1994 In addition, causing confusion but no execution error,
comments in VMAC28 were misspelled; NPMCLLAN should be
NPMCMLAN, and RMSTR should be RMSTA in all occurrences.
Thanks to Ann Wheeler, American President Lines, USA.
Change 11.322 TYPE72MN variables WSETFIX and WSETASM were incorrect.
VMAC7072 They are now calculated as:
Feb 18, 1994 WSETFIX=FRAMEFIX/AVGUSER;
WSETASM=FRAMEASM/AVGUSER;
Thanks to Jan van Kemenade, Universitair Centrum Info., NETHERLANDS.
Change 11.321 Support for ISOGON's SoftAudit Product Usage File and
EXSFTAM Module Usage File creates two datasets by reading the two
EXSFTAP separate SoftAudit flat files:
IMACSFTA MXG Dataset DDname Description
TYPESFTA SOFTAUDM XPUSAGEM Module Usage File
VMACSFTA SOFTAUDP XPUSAGEP Product Usage File
Feb 17, 1994 Both files will be read if data exists in either DDname:
// EXEC MXGSAS,USER=PDBSFTA
//XPUSAGEM DD DSN=MODULE.USAGE.FILE,DISP=SHR
//XPUSAGEP DD DSN=PRODUCT.USAGE.FILE,DISP=SHR
//PDBSFTA DD DSN=WHERE.YOU.WANT.OUTPUT,DISP=(,CATLG),
// UNIT=SYSDA,SPACE=(CYL,(10,10))
%INCLUDE SOURCLIB(TYPESFTA);
If you only want to process one of the two files, use
DD DUMMY in your JCL for the unwanted file.
Change 11.320 APPC tasks do not go thru JES, so there will be no type
BUILDPDB 26 purge record to match up with APPC type 30 records. As
BUILD006 a result, all APPC work would be held in the SPIN library
Feb 16, 1994 until SPINCNT in IMACSPIN is exceeded. Even if there are
type 6 records for APPC tasks, there is no way to know
they exist, so there is no reason to SPIN APPC tasks, and
therefore, the BUILDPDB logic for outputting APPC tasks
to the PDB.JOBS and PDB.STEPS datasets was revised to
send APPC tasks to the PDB as soon as both a type 30
subtype 4 (step) AND type 30 subtype 5 (job) record have
been found. If there were any type 6 records for the
same JOB JESNR READTIME combination in today's SMF data,
then PDB.PRINT will have the APPC tasks print data with
accounting fields from the type 30. An isolated type 6
record for an APPC task will be output when found, i.e.,
it will not be sent to the SPIN library. The insert:
ELSE IF TYPETASK=:'A' THEN DO;
IF IN30_5 THEN OKFLAG=1;
ELSE IF IN6 AND NOT IN30_4 THEN OKFLAG=1;
END;
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 11.319 AS/400 variable AS400SYN was blank, because the %MACRO
VMACQAPM variable &AS400SY was not passed correctly, and was being
Feb 16, 1994 reinitialized to blanks in QAPMCONF. The three SYMPUTS
in _CQAPCON were enclosed in IF _N_=1 THEN DO; ... END;.
All occurrences of AS400SYN="&AS400SY"; were changed to
read AS400SYN=SYMGET('AS400SY'); Also, the single
occurrence of NRCPUS="&AS400CP"; was changed to read
NRCPUS=SYMGET('AS400CP');
Thanks to Greg Scriba, Budget Rent-A-Car, USA.
Change 11.318 CICS Statistics variable A20E1HWM (Peak Contention Users)
VMAC110 was left out of the KEEP= list for dataset CICCONMR.
Feb 14, 1994
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 11.317 Partial support for LEGENT's MIM Release 4.0 enhances the
VMACMIM MIMTAPE dataset for the new release, but additional work
Feb 14, 1994 is needed to decode new subtypes in this release. This
code is functional, and hence included, but test data for
other subtype is needed before full support is provided.
Thanks to Doug Drain, National City Bank, USA.
==Changes thru 11.316 were include in MXG PreRelease 11.10 dtd 14Feb94==
Change 11.316 Support for LEGENT's NETSPY Release 4.4.
EXNSPYET -Dataset NSPYAPPL, new variables APOTLN62, APOTNN62 count
EXNSPYFR the outbound bytes for LU 6.2 and non-LU 6.2 sessions.
FORMATS -Dataset NSPYLU, new variable RESPNOTC='Y' if response
IMACNSPY time is collected. IF RESPNOTC='N', then variables:
VMACNSPY LRSPHOST LRSPNET WRSPHOST WRSPNET CRSPHOST CRSPNET
Feb 13, 1994 NETRSPNO T1RSPNO T2RSPNO T3RSPNO T4RSPNO
are now set to zero by MXG, as LEGENT says "these fields
may have data in them, however they should not be used
when reporting".
-New Dataset NSPYFRLY for Frame Relay Statistics
-New Dataset NSPYETHR for Ethernet Statistics.
-Several new values for NSPNSUBT are now decoded by
MXG format MGNSPEL, and logic for recognition of which
sub-subtype of the type 'N' was clarified.
Change 11.315 Support for CA's ACF2 Release 6.0 and 6.1 added seventeen
VMACACF2 new variables to type 'V' record, and one to type 'D'.
Feb 12, 1994 Renames of ASSSPCOD to ASSPPCOD and ACFGFOE to ACFGFDEN
correct my misspellings. The use of LENGTH-COL-1 (to know
how many bytes are left in the record) should have been
LENGTH-COL+1 (this could have caused new variables to not
be read in, although no one seems to have noticed!).
In this revision, I have also decoded the LIDREC and the
LIDXARE of the type 'J' record, labelled and formatted
the several dozen new variables, but did not add any of
those variables to the ACF2JR data set; instead, if you
decide you need those variables, you can use the MXG
macro _KACFJR in member IMACACF2 to add them. (Only one
site had requested the LID fields.)
Change 11.314 For developers, this is my recommended test protocol:
Testing
Feb 12, 1994
You need to ALWAYS test it ONE MORE TIME!
When you think your code is done:
Run it once more, as a batch job, and while that job
that job is running, use SPF 3.12 COMPARE to examine
every difference between the before-and-after source
members.
Then,examine the batch job's output:
- The SYStemLOG, for any Operating System warnings,
- The SASPRINT report output, for any differences,
- The SASLOG log output, for any occurrence of each
of these strings (blanks are important!):
"ERROR:" "ERROR :" " UNINIT"
"NEVER BEEN" "NOT FOUND" "CONVERT"
"NOT CATLGD" " NOT " "TRUNCATED"
Change 11.314A MXG 11.09A Only, PMACC02 Report, DB2 Accounting Detail
ANALDB2R Trace was in error due to insufficient testing. The data
Feb 12, 1994 was summarized when it should only have been sorted.
Thanks to Jeff Marsh, Twentieth Century Services, USA.
Change 11.313 OMEGAMON for CICS V550/V551 User SMF record subtype 100
VMACOMCI sub-subtype 2 caused INPUT STATEMENT EXCEEDED RECORD LEN.
Feb 12, 1994 The code expected the same number of segments for EGROUP
as for ETRNAME, but they are unrelated tables. The code
was corrected, but for simplicity both EGROUP and ETRNAME
segments are still output in dataset OMCITRAN; you can
identify which is which by testing :
IF ETRGRPM NE . ==> ETRNAME and ETRGRPM are valid
IF ETRGRPM EQ . ==> EGROUP, EGRPNAM, EGRPESNR are valid
This change supercedes Change 11.115.
Thanks to Ron BLeeden, Jewel Food Stores, USA.
Thanks to Bill Wieland, EDS Westlake, USA.
Change 11.312 Variable AVGENQMS (Average ENQUE time in milliseconds)
VMAC74 was calculated but not KEPT, LABELed nor FORMATted, but
Feb 9, 1994 now it is.
Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.
Change 11.311 GRAFWORK was enhanced with a new graph of memory usage by
GRAFWORK workload (using the ACTFRMTM-based measure of resident
Feb 7, 1994 memory frame seconds in the xxxxMEMR variables). GRAFWORK
now provides graphic depiction of CPU, I/O, and MEMORY
resource usage by workload.
Change 11.310 GRAFRMFI was revised to include new variables added to
GRAFRMFI RMFINTRV recently, and the internal logic revised to make
Feb 7, 1994 maintenance easier.
Change 11.309 This major revision to VMXGSUM reduces runtime and CPU
VMXGSUM time, by keeping only the variables and datasets that are
ANALDB2R needed during the input for summarization, and executes
ANALPRTR only the steps required (i.e., it will bypass PROC SORT
ASUMCICS if it can). If you have tailored some MXG members that
ASUMDBDS invoke %VMXGSUM, you MUST examine the INCOMPATIBILITY
ASUMDB2A note, below, and you MAY have to update your tailored MXG
ASUMDOS members. If you have used %VMXGSUM in your own reporting
ASUMHPCS programs, you may also be vulnerable to required changes.
ASUMJOBS -Changed the logic for MINTIME= and MAXTIME=. No longer
ASUMTMNT are variables named MINTIME/MAXTIME created; instead, the
ASUMVDEV variable name(s) passed into VMXGSUM are retained, which
ASUMVMON permits bypassing the first data step to reduce costs.
ASUM70PR -NOSORT= parameter was added, which allows the sort to be
DAILYDSN bypassed if you KNOW the data is already in order.
GRAFDB2 -Initialization to protect for "UNINITIALIZED VARIABLE"
GRAFLPAR message (the series of IF X=. THEN X=.; statements) was
TRNDDB2A relocated to execute only once.
TRNDDB2S -New logic automatically figures out what variables need
Feb 7, 1994 to be kept (by looking at all variables that are in any
text of of the list-of-variable parameters), so the _KMXGSUM
change was syntax that was added in MXG 11.09 is no longer used.
revised -The new KEEPIN= parameter is required if you have INCODE=
Mar 6, 1994 specified, and if there are unique variables used in your
INCODE= logic that are not referenced by other VMXGSUM
list-of-variable-parameters (SUM= SUMBY= MIN= ... etc.)
-INCOMPATIBILITY NOTE
If there is an INCODE= parameter (for sophisticated use
you can insert SAS code with this parameter), AND only
if there are variables referenced in your INCODE= logic
that are not referenced by the other VMXGSUM parameters
(SUM= SUMBY= MIN= ... etc.),
Then you MUST add a KEEPIN= parameter to your %VMXGSUM
invocation so that those unique variables exist during
the INCODE= code execution.
These MXG-supplied members had to be changed in the MXG
Source Library because all had un-kept variables that
had to be listed in the KEEPIN= parameter:
ASUMDBDS ASUMDB2A ASUMDOS ASUMHPCS ASUM70PR
DAILYDSN GRAFDB2 GRAFLPAR TRNDDB2A
If any of those 9 members are in your USERID.SOURCLIB
tailoring library, you MUST refit your changes,
starting with the MXG 11.11 member that contains the
required KEEPIN= parameter.
You must scan your USERID.SOURCLIB(s) for any of your
own programs that invoke %VMXGSUM, and see if any of
them meet both conditions (INCODE= and nonkept variable
referenced in that INCODE= logic).
Examine the SAS log of your test runs for UNINITIALIZED
VARIABLES messages; that is a sure sign that you have
INCODE= variables that do not exist!
DO NOT OVERLOOK THIS CRITICAL INCOMPATIBILITY, which
should affect only the very small number of sites that
have tailored the MXG summarization or trending code.
As long as you are executing those 9 MXG members
unmodified from the MXG 11.11 library, there is not any
incompatibility with this change.
-All MXG invocations of VMXGSUM were examined and INVOKEBY
was added so the caller would print on the SAS log.
-Especially with a large input dataset (eg., CICSTRAN with
594,000 observations, the keeping of only the needed
variables significantly saves resources. Using:
%VMXGSUM(INDATA=CICSTRAN.CICSTRAN,
OUTDATA=CICSSUM,
DATETIME=STRTTIME,
INTERVAL=HOUR,
SUMBY=APPLID DATETIME,
FREQ=NUMTRANS,
SUM=IRESPTM TASCPUTM);
Showed these comparisons before and after this change:
Run COMPRESS CPU EXCP Memory DASD
Option SEC count used tracks
Before NO 120 21843 4973K 10699
After NO 83 12920 4902K 943
Before YES 650 25330 4913K 7129
After YES 135 13255 4902K 1111
The elapsed times were also significantly reduced. The
37 minutes required for the "before" compressed run was
reduced to 11 minutes for the "after" compressed run.
Thanks to Chuck Hopf, Primerica, USA.
Change 11.308 Support for Candle's Deltamon SMF record creates new MXG
EXTYDLMN dataset TYPEDLMN, which reports activity (ADD,UPDATE,
FORMATS DELETE, or RENAME) at the PDS member level.
IMACDLMN
TYPEDLMN
VMACDLMN
Feb 7, 1994
Thanks to Chuck Hopf, Primerica, USA.
Change 11.307 ASTEX variable RCHCNT=SUM(RHTRD,RHTRDS,RHTDFW,RHTCSW) was
VMACDMON added after the INPUT of the four arguments. In prior
Feb 7, 1994 versions of ASTEX, RCHCNT was directly input, but now it
must be calculated from its four arguments.
Thanks to Jay Stewart, Honda, USA.
Change 11.306 For MVS execution, MEMSIZE=32MB is now the default value
CONFIG in CONFIG. The default BUILDPDB failed "OUT OF MEMORY"
Feb 7, 1994 with MEMSIZE=24MB, and 32MB protects for the future.
Change 11.305 Variable CMF09UIC from Boole's CMF must be divided by the
VMACCMF number of samples:
Feb 7, 1994 IF CMFHDSAM GT 0 THEN CMF09UIC=CMF09UIC/CMFHDSAM;
Variable CMF05NUM is now format HEX4.; variable CMF19TPG
no longer formatted HEX2.!
Thanks to Joanne Turpie, Department of Labour, NEW ZEALAND.
Change 11.304 Support for OPC/ESA Release 2.1 has added 5 new datasets
EXOPC34 (and corrected INVALID MTD SUBTYPE messages):
EXOPC35 OPC24_H MTD Delete/Change CM
EXOPC36 OPC24_I MTD Hold Operations
IMACOPC OPC34 Catalog Management
VMACOPC OPC35 Backup Event
Feb 6, 1994 OPC36 CP Backup Log
Finding all the IBM manuals for this release was a chore;
comments in VMACOPC identify what is documented where!
And I learned that you cannot order Licensed IBM Pubs if
you use your "IBM Customer Number", but if you give the
same number as your "IBM Enterprise Number", the Pubs
clerk discovers you are authorized for Licensed Pubs!
Thanks to Alan Phelan, Allied Irish Bank, IRELAND.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 11.303 TYPE71 variable AVLEXTMN, "Minimum ESTORE Available", can
VMAC71 be negative, according to IBM, so its input was changed
Feb 5, 1994 from &PIB.4. to &IB.4. The actual value of the field is
"number of extended storage e-frames currently on the
available sets excluding those reserved for pref steal."
This means that when the value is zero, all of RSM except
for pref steal will accept that there are "no" available.
If the value is less than zero, pref steal will check to
see if there are any in reserve and will use these.
Thanks to Hr. Leineweber, HUELS AG, GERMANY.
Change 11.302 Testing of TYPEVMXA (VM/ESA) under UNIX, OS/2 or WINDOWS
AUTOEXEC found glitches (but this change is NOT needed if you run
VMACVMXA MXG under either the MVS or VM versions of SAS):
VMAC83 -AUTOEXEC had blanks inside quotes, which is no problem
XMACNCCF for WINDOWS or OS/2, but UNIX did not tolerate, so they
VMXGHSM were removed. Also, a new Filename statement was added:
ANALSNAP FILENAME INSTREAM 'C:\MXG\USERID\INSTREAM.SAS'
IMACACCT and must be suffixed .SAS, because it is written to and
SYSLOGJ3 then %INCLUDEd (to build formats "instream").
UTILXREF -Some variables input as $EBCDIC were not character data
VMACACF2 but were binary data and are now input as $CHAR. Some
VMACASXT also required addition of $HEX formats, and most were in
VMACCMA seldom-to-never-used VM data sets.
VMACDB2 -The building of the "instream" PROC FORMAT failed with
VMACHMF INVALID HEX DATA, because of $EBCDIC versus $CHAR input
VMACPOOL format that was corrected.
VMACTSOM -Discovered that EBCDIC algorithm to identify numeric
VMACVMON EBCDIC characters from alphabetic characters, using
VMACVMXA LT '0' ==> alphabetic GE '0' ==> numeric
VMACVVDS is invalid under ASCII execution. EBCDIC algorithm works
VMAC102 because EBCDIC numbers are 'F0'x thru 'F9'x, which is
VMAC24 larger than EBCDIC letters of '81'x thru 'C1'x (lower
VMAC33 case) and 'C1'x thru 'E9'x (caps), but the ASCII numbers
VMAC37 are '30'x thru '39'x, which is smaller than ASCII
VMAC4789 letters '41'x thru '5A'x (caps) and '61'x thru '7A'x
VMAC59 (lower case). The parsing algorithm was redesigned to
VMAC60 scan for non-blank versus blank, and one more difference
VMAC6156 between ASCII and EBCDIC execution is documented!
VMAC80 -Use of $VARYING200. input for printable characters was
VMAC83 resolved. $VARYING acts like $CHAR instead of $EBCDIC,
Feb 4, 1994 so strings that are to be printed need conversion. The
WINDOWS conversion algorithm is:
INPUT variable $VARYINGnn. lenvar @;
variable=INPUT(variable,$EBCDICnn.);
variable=TRANSLATE(variable,' ','80'x);
Note: only the INPUT function should be required, but
The TRANSLATE was unexpectedly needed because the
$EBCDIC was found to convert '20'x ASCII blanks at
the end of the string to '80'x. SAS Institute
suggested that using INPUTC(string,format,length);
instead of INPUT(string,format) would have eliminated
the need for the TRANSLATE() function, but my code
works, whereas (Jun 24, 1997 update:)
when I tried INPUTC under SAS 6.12 TS020 Windows 95
I got these errors pointing to the $EBCDIC128. when
I tried to use VAR=INPUTC(VAR,$EBCDIC128.,LEN);
386-185 Expecting Arithmetic Expression and
200-322 The Symbol is not recognized
underscored for format $EBCDIC128.. Problem
will be opened with SAS: That's the way it is!
The $VARYING conversion required examination of each
occurrence to see if the field is a printable (text)
string, and if so, insert the above conversion code.
(This also required creation of DO group in some cases.)
Thanks to Chris Powell, Vancouver Stock Exchange, CANADA.
Change 11.301 Labels for the four new SYNCSORT variables SYNDSMVL,
VMACSYNC SYNFMAVL, SYNFMALO, and SYNMMUSE were added; originally
Feb 2, 1994 they were not provided in SYNCSORT documentation.
Thanks to John Borland, Citibank, USA.
Change 11.300 An SMF Writer "Simulator" has been added to ANALSMF, to
ANALSMF examine your SMF data and tell you what is the optimum
Feb 2, 1994 CI Size of your VSAM data set. See the MVS Technical
Note in Newsletter TWENTY-FIVE for a complete discussion
of the impact of the wrong CI Size on the SMF Writer.
You need only to EDIT ANALSMF to set the CI Size of your
VSAM file (in macro _MYCISIZ), and then point the SMF DD
to a dumped SMF file, and the report of DASD Space and CI
Writes at different CI Sizes will be produced. Several
additional reports were added to describe how seldom the
SMF Writer actually writes, and the Statistics from
TYPE23 are also printed, along with a tabulation that
shows the contents (count and bytes) of where your SMF
data records come from.
Change 11.299 The example of the ZARA LIST command to create an OUTFILE
TYPEZARA needs to have the SSFN operand added so that "secondary"
VMACZARA files (i.e., second and subsequent files on a volume) are
Feb 2, 1994 created in the OUTFILE. Without SSFN, you only see the
first dataset on each volume in ZARADSN. Correct is:
LIST OUTFILE ACTIVE SSFN $$
In addition, variable LSTTYPE, type of tape (AUTO,ACTIVE,
SCRATCH) was added to ZARAVOLS and ZARADSN datasets.
Also, variable FILTIMEL may contain trash (seems to be
for volumes converted to ZARA from CA-1); the "??" was
added to the INPUT FILTIMEL ?? &PD.4. statement.
Thanks to David Childress, Lowe's Companies, Inc, USA.
Thanks to Neil Ervin, Huntington Bank Service Company, USA.
Change 11.298 The JCL in this example to analyze all records from a
ANALALL specific job was partially for SAS 6.08 and partially for
Jan 18, 1994 SAS 5.18, causing confusion for novices. The JCL example
now is for SAS Version 6.
Thanks to Rosie Jergovic, Pacific Bell, USA.
Change 11.297 Variable TIC_UTIL in NETSPY is incorrectly computed. The
VMACNSPY BYTSENT+TRTPBYTS should be BYTSENT*TRTPBYTS in both of
Jan 18, 1994 the equations for TIC_UTIL.
Thanks to Linda Liu, Transamerica, USA.
Change 11.296 This analysis of the size of an SMF file was enhanced to
ANALSMF report SMF type 23 statistics, and the categorization of
Jan 18, 1994 SMF record IDs for JOB-IO now includes all VSAM activity.
Change 11.295 Missing value for FATNUM, UTNUM, or MRONUM cause INVALID
TYPEMON8 DO ARGUMENT message if Change 11.270 was not installed to
Jan 17, 1994 circumvent new format of Landmark data. While 11.270 did
avoid these errors, the missing value protection was now
added, just in case!
Thanks to Hr. Dungl, CA-Inform, GERMANY.
Change 11.294 MXG 11.09A only. Accounting detail report not produced
ANALDB2R if time selection was used and DB2ACCT was used as input.
Jan 13, 1994 Find "%MACRO PMACC02;", then find "MINTIME=QWACBSC;".
Insert after that line the statement "MAXTIME=QWACESC;"
Thanks to Jeff Marsh, Twentieth Century Services Inc, USA.
Change 11.293 Additional refinements in the RMF reporting from MXG data
ANALRMFR were added. The time selection logic was corrected so a
Jan 13, 1994 report for 10am-12am Mon-Fri can be requested, and CPUIDs
thru 15 CPUs is now supported.
Change 11.292 MXG 11.09A only. The KEEP= logic did not include &MEAN.
VMXGSUM The three lines starting with &MAX &MAXTIME need to have
Jan 12, 1994 &MEAN added after &MAXTIME. Only if you invoked VMXGSUM
with the _KMXGSUM operand, and had MEAN= parameter, would
this change have had any effect. Change 11.309 revised.
Change 11.291 Analysis of VSAM datasets were sorted by SMFTIME instead
ANALDSET of the STEP initiate time; logic was added to store and
Jan 11, 1994 retain the SORTTIME of each STEP record in STEPTIME, and
then store STEPTIME into SORTTIME for TYPE64 observations
so VSAM is consistent with non-VSAM sort order.
Thanks to Gary Matney, Twentieth Century Investors, USA.
==Changes thru 11.290 were included in MXG 11.09A dated Jan 10, 1994====
Change 11.290 Member ASUMAPAF, a user contribution, summarizes Amdahl's
ASUMAPAF APAF records from MDF, similar to ASUM70PR summary of
TYPEAPAF IBM's PR/SM records. TYPEAPAF was cosmetically changed
Jan 8, 1994 to use __NRLPS to control all of the LPAR variables to
be kept (previously, some variables were controlled by
__NRLPS and some were kept for all possible 15 LPARS).
The value of __NRLPS is set in IMACAPAF.
Thanks to Brian LeBlanc, Candle Corporation, USA.
Change 11.289 AS/400 data sets are now fully documented in this new
ADOCQAPM ADOC chapter, although it has not been final-pass edited.
Jan 8, 1994
Change 11.288 This example of a prime-time cross-system DASD report
ANALDASD from PDB.TYPE74 may be of use in tracking DASD activity
Jan 8, 1994 across multiple systems.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 11.287 Preliminary testing under CMS of MXG 11.09 found that the
REXXTES6 REXX sample did not include VMXGINIT nor did it contain
Jan 6, 1994 the correct FILEDEFs to concatenate USERID and SOURCLIB
MACLIBs. See also the circumvention in Change 11.067 to
remove CICS and DB2 processing to run BUILDPDB. This
text will be revised when testing under CMS is completed.
Thanks to Jerry Maier, NBD Bank, USA.
Change 11.286 DB2PM-like reports have been revised to correct all
ANALDB2R reported errors and now exploit fields added by DB2 2.3.
Jan 6, 1994 Many of the TRACE reports (notably AUDIT, LOCKING, SQL)
were heavily modified, and all reports now use ANALDBTR
pairing where appropriate. Input can now be from a PDB
library on tape, and one new report has been added:
PMLOK04 - Lock Detail Trace report.
Thanks to Mike Skopec, Platinum Technology, USA.
Thanks to Wai Choong Mak, Development Bank of Singapore, SINGAPORE.
Thanks to Andy Vick, Allied Dunbar Life Assurance, ENGLAND.
Thanks to H. Lugert, Datav, GERMANY
Change 11.285 Pairing logic for IFCIDs 114-115 was added, the T102S054
ANALDBTR dataset was added to the S044S045 pairing. Also, all
Jan 6, 1994 observations of T102S063 (SQL text) are now output (only
the first 200 bytes of text was previously output - this
change in ANALDBTR will now cause the ANALDB2R SQL trace
report to now print all of the SQL text). Also, if the
input datasets are from a PDB library, the intermediate
T102Sxx datasets in the WORK file are now deleted.
Change 11.284 Some variables needed for ANALDB2R were not kept in some
FORMATS T102Sxxx datasets, and compressed data in IFCID 21 and 54
VMAC102 are now decoded, using the new $MGDB2XX format. Three
Jan 6, 1994 labels that exceeded 40 bytes were shortened.
Change 11.283 A minor correction: if IFCID=ALL was specified, the
READDB2 output T102Sxxx datasets were not copied to the output
Jan 6, 1994 PDB library, but now they are.
Change 11.282 New dataset PDB.DB2STATS is now created by merging the
DIFFDB2 three DB2 statistics datasets (DB2STAT0, DB2STAT1, and
Jan 6, 1994 DB2STAT2) for ease in statistics reports. Eventually,
the new dataset will be used by ANALDB2R reports, and you
should use DB2STATS in your own reports. As these
statistic datasets are small, there is little cost for
the redundancy.
Change 11.281 Major reduction in VMXGSUM resources (CPU,DISK) are now
VMXGSUM completed. Originally planned as Change 11.245, those
Jan 6, 1994 changes were not implemented until now, because the NODUP
SAS option and the MXG _KMXGSUM operand were in conflict;
NODUP dropped observations that were not duplicate, but
looked like dupes because of the reduced variables kept.
So the NODUP option on the SORTs in VMXGSUM were removed
(although a new option NODUP= lets you reinstate them if
you need them and know what you are doing!), and these
changes in the architecture of VMXGSUM were validated:
- The first data step is bypassed if there is no INCODE=,
no INTERVAL=, no SHIFT=, and no NORMx= arguments, and
if there is only one input dataset.
- The PROC SORT is bypassed if there is no SORTBY=.
In another enhancements, three new symbolic arguments
TEMP01,TEMP02,TEMP03 (which default to WORK) are used as
the high-level node of the work datasets, which permits
placing one or more of the work datasets on tape,
reducing the DASD requirement for VMXGSUM processing. If
all three TEMPxx parameters point to the same DDNAME,
then a PROC DATASETS is run at the end of processing to
clean up the temporary space, but if they are different,
we cannot clean up as we have no way to tell if this is a
tape or disk data set. VMXGSUM now uses DKRICOND=NOWARN
as the default (so input datasets with non-existent
variables do not raise a warning), but DKRICOND=WARN is
reset at the end of VMXGSUM execution.
Yet another enhancement is the new argument TIMERNGE=.
If TIMERNGE= is specified, four macro variables are then
constructed to determine the date, time, or datetime
range of the TIMERNGE= argument across the entire input
datasets. The macro variables created are:
MAXINDT - Maximum datetime value for the input data
MAXSLDT - Maximum datetime value for the output data
MININDT - Maximum datetime value for the input data
MINSLDT - Maximum datetime value for the output data
(You must supply the appropriate FORMAT if you print the
value of these four new variables.)
Note: The VMXGSUM architecture was further enhanced in
Change 11.309. This text was edited after that change.
Change 11.280 TYPE39_8 (Netview Session Awareness) LSAWxxxx variables
VMAC39 are wrong because the INPUT statement was off by 4 bytes.
Jan 6, 1994 Also, variables LSAWPSPU and LSAWPSPM were not input.
Change the LSAW section logic to read:
INPUT @OFFSAW REVISION &PIB.2.
+2
LSAWASBC &PIB.4.
- - - - - - - - - - - - - - 17 lines not displayed
LSAWRDQM &PIB.4.
@;
SKIP=LENSAW-80;
IF SKIP GE 8 THEN DO;
INPUT LSAWPSPU &PIB.4.
LSAWPSPM &PIB.4.
@;
SKIP=SKIP-8;
END;
IF SKIP GT 0 THEN INPUT +SKIP @;
END; /* SAW SECTION */
and add LSAWPSPM and LSAWPSPU to the KEEP= list for
TYPE39_8.
Thanks to Hr. Schulte, GRZ, GERMANY.
Change 11.279 MXG 11.07 thru MXG 11.09 did not process TPX Version 3.0
VMACTPX records (but prior MXG versions did), because the LEGENT
Jan 6, 1994 change in format of TPXVER did not document the 3.0 value
to be expected. The conversion code now reads:
IF TPXVER EQ '100 ' THEN TPXVER=' 1.0';
ELSE IF TPXVER EQ '200 ' THEN TPXVER=' 2.0';
ELSE IF TPXVER=:'3.0' THEN TPXVER=' 2.0';
ELSE IF TPXVER=:'3.5' THEN TPXVER=' 3.5';
ELSE IF TPXVER=:'1.0' THEN TPXVER='10.0';
Thanks to Jan Decuypere, Gemeentekrediet N.V., BELGIUM
Change 11.278 Landmark CICS variable TIESDATE (start date) can be null
TYPEMON8 if PTF U200952 is not installed. MXG uses TIESDATE to
Jan 5, 1994 validate that DUMP CONVERT was specified when you dumped
Feb 16, 1994 the Landmark data (see their examples TMON9DBU/TMON9FSU),
and MXG generates the "ERROR3.LANDMARK.MONITOR" error
message "INVALID FORMAT FOR TIESDATE" when TIESDATE is
null. Install the PTF. However, if you encounter that
error message, and know that your data was converted,
you can suppress the ABEND by commenting out the "ABORT
ABEND 1099" statement in member TYPEMON8, until the PTF
is installed. This change text was revised Feb 16, 1994.
Thanks to Mark Holland, State Energy Commission, AUSTRALIA
Change 11.277 If ASUMDB2A is executed separately from BUILDPDB, there
ASUMDB2A will be errors because %INCLUDE SOURCLIB(IMACDB2); did
Jan 5, 1994 not exist in member ASUMDB2A, but now it does.
Thanks to Steve Bryant, Belk Stores Services, USA.
Change 11.276 Support for ZARA Release 1.1 added 36 bytes to the sort
VMACZARA key and header area. You will have zero observations in
Dec 15, 1993 the ZARAVOL and ZARADSN datasets until you change all of
the @xxx values that are now greater than 100 by adding
36 to the present value. Thus the @172 VRCDTYP became
@208 VRCDTYP, the @183 VOLCHAIN became @219 VOLCHAIN,
and so forth.
Thanks to David Childress, Lowe's Companies, USA.
Change 11.275 IBM APAR OY67002 reports that if the number of LCPUs is
VMAC7072 changed in an LPAR, the data for that RMF interval
Dec 15, 1993 contains the accumulated values from IPL, and there are
no PR/SM segments in the type 70 for the interval.
This corrupts TYPE7072 variables LCPUEDTM,LCPUPDTM,
PCTCPBYx,PCTTIPx, corrupts TYPE70 variables CPUEDTMx,
CPUPDTMx,PCTCPBYx, and PCTTPIx, and corrupts essentially
all ASUM70PR variables for that interval. MXG detects
that the number of LCPUs changed, and sets LPARCHRN='Y'
in TYPE70PR (the Label for LPARCHNR now reads NUMBER OF
LCPUS*IN PARTITION*CHANGED?), but you MUST install the
PTF associated with the APAR if you change the number of
LCPUs in an LPAR while the system is up.
Thanks to Gary Hoover, American Express IPS, USA.
Thanks to Roger Zimmerman, Kemper Services Company, USA.
Change 11.274 Three new variables were added to the SAS User SMF record
VMACSASU in SAS 6.07/6.08. Variables SASVAFF (Vector Affinity CPU)
Dec 15, 1993 SASVUSE (Vector Usage CPU), and SASHSP (Hiperspace CPU)
are now input and formatted TIME12.2.
Thanks to Bruce Lietz, Cessna Aircraft Company, USA.
Change 11.273 Some TRND71 variables were not calculated. In the NORM2=
TRND71 list, the first occurrence of SLOTNVAV should be SLOTNGAV
Dec 15, 1993 and variables ASMNVSC ASMSLOTS ASMSLOTX and ASMVSC were
added to the NORM2= list.
Thanks to Carl Tosetto, E-Systems Garland Division, USA.
Change 11.272 TYPE64 records with SITUATN='COMPONENT CLOSED' are the
ADOC64 only valid records to use for counting EXCPS, etc. The
ANALDSET type 64 records with NO SPACE AVAIL or VOL SWITCHED do
Dec 15, 1993 not contain the "delta" EXCP count, but instead have the
accumulated EXCP count from open to the time of that
event. As a result of this discovery, member ANALDSET
now keeps only TYPE64 observations for Component Closed.
Thanks to Scott Ashby, Wachovia Operational Services Corp, USA.
Change 11.271 Statement DEVASID DS XL2 has an asterisk in column
ASMTAPES 72 which causes the Assembly to fail. This member is
Dec 15, 1993 still in internal testing. See Change 11.360.
Change 11.270 Support for Landmark CICS/ESA Version 1.1 records. That
TYPEMON8 new version added 44 fields to the end of the MONISYST
Dec 14, 1993 interval record, causing "INVALID DO LOOP CONTROL" error.
This error can be circumvented by inserting "HITI=1;"
just before the "DO _I_=1 TO HITI;" statement, but you
will then get "INVALID DATA FOR TASKCPTM" and hex dumps
twice, because Landmark's field TIAPLCPU (MXG variable
TASKCPTM) is invalid until you install Landmark ZAP for
Problem Number U201102. (You can still process without
their ZAP as all other variables in MONISYST are valid,
and only the MONISYST data set was affected by the new
version!). In the actual change, the DO group to read
the history segment was removed, as that segment has not
existed for some time, and MONIHIST always has zero
observations. However, I did not delete the MONIHIST
dataset nor its _L,_K macro names, since that might have
caused a syntax error if you reference MONIHIST in your
report programs. Take heed, though, and remove MONIHIST
references so that I can deleted it in a later version.
Setting HITI=1 has the same effect as skipping the
history record; the TI record is now 1464 bytes long.
Thanks to Mark Holland, State Energy Commission of Western Australia.
Change 11.269 Dataset PDB.JOBS variables ACCOUNTn may be blank, and
BUILDPDB variables RESTARTS, JINLTIME, and NRTRANS can be missing
BUILDPD3 for jobs with MULTIDD='Y' (that is, multiple type 30s due
BUILD005 to many DD segments, typical only for long running jobs
Dec 13, 1993 like SAR, RMDS, CA-DISPATCH, etc., that have lots of
dynamic DDs). The MULTIDD='Y' observations must be
deleted during the second occurrence of the creation of
GOOD30_5 dataset. Find this block of code:
ELSE IF IN30_5 THEN DO:
IF MULTIDD5=' ' THEN RESTART+1;
OUTPUT GOOD30_5;
END;
And change it to read:
ELSE IF IN30_5 THEN DO:
IF MULTIDD5='Y' THEN DELETE;
RESTART+1;
OUTPUT GOOD30_5;
END;
The actual change also cleaned up references to MULTIDD
and TEMP3 which are no longer needed, but which are now
superfluous and safe to leave until you get a tape!
Thanks to Mark van der Eynden, Ferntree Computer Services, AUSTRALIA.
Change 11.268 CICS DL/I counts with CICS/ESA Version 3.3 Omegamon 110
IMACICDL records may be wrong. First, the test in IMACICDL needs
IMACICDA to be changed to IF SMFPSRVR GE 3 instead of EQ 3.
VMAC110 Second, if you have not added a "USERCHAR" optional data
Dec 14, 1993 field in your type 110 record, you must comment out the
statement "%INCLUDE SOURCLIB(IMACICDU);" in member
IMACICDA (because if that statement is present, MXG
always read at least one byte, causing wrong alignment).
Commenting out that %INCLUDE will generate an
"UNINITIALIZED VARIABLE USERCHAR" message, which is
not a problem, but in member VMAC110, I have added
"IF USERCHAR=" " THEN USERCHAR=" "; after both of the
%%INCLUDE SOURCLIB(IMACICDA); statements to correct.
The notes in IMACICDA and IMACICDL were updated to list
the CMODHEAD field names of the DL/I counters to make it
easier for you to know what sections you do or do not
have in your SMF type 110 record from Omegamon, using MXG
program UTILCICS to examine your dictionary.
This text was revised Dec 14, 1993, after MXG 11.09.
Thanks to Khin Zaw, Nordstrom, USA.
Change 11.267 APAF V2.1 dataset APAFCHAN is trashed, because the offset
VMACAPAF had a spelling error. Inside the SUBTYPE=5 DO group, the
Dec 13, 1993 statement LOC=OFFLP-3+OFFSMF should have been written as
LOC=OFFCHPID-3+OFFSMF;
Thanks to George Scott, Rockwell International Corporation, USA.
==Changes thru 11.266 were included in MXG 11.09 dated Dec 17, 1993=====
Change 11.266 Dataset TYPE1415 variable TEMP='TEMP' was incorrectly set
VMAC1415 if DISP1='.......1'B, so that part of the test to set
Dec 12, 1993 TEMP has been removed.
Thanks to Bruce Hudson, Payless Shoe Source, USA.
Change 11.265 Boole and Babbage CMF Type 72 Subtype 2 record is invalid
VMAC7072 and causes INPUT STATEMENT EXCEEDED error. There is only
Dec 10, 1993 one SWAP section, instead of one SWAP section for each
Performance Group, and other fields in TYPE72MN dataset
may be trashed. Boole anticipates a fix in their 9402
maintenance release. MXG changed IF OFFSWP GT 0 THEN DO;
to IF OFFSWP GT 0 AND OFFSWP+60 LE LENGTH+1 THEN DO; to
prevent the STOPOVER condition.
Thanks to Gavin Ring, Alcatel Australia, Australia
Change 11.264 Variable PGPERBLK in RMFINTRV was incorrectly normalized.
RMFINTRV The two lines in which PGPERBLK was multiplied/divided by
Dec 8, 1993 DURATM were deleted, and the division by BLKSAUIN was
protected for zero divide.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 11.263 Members CHANGE01,CHANGE02... are redundant with CHANGESS,
ChangeSS which contains all changes ever made to MXG in one place,
Dec 4, 1993 so the individual CHANGEnn members now only point to the
member CHANGESS, reducing the size of the MXG library.
Searching for all MXG enhancements now involves looking
only two members: CHANGESS or NEWSLTRS. Member CHANGES
will continue to exist, repeated in CHANGESS.
Change 11.262 Support for Softworks' Performance Solution SMF records.
ADOCPRFS Three new datasets are created:
EXPRFSHL Dataset SMF Subtype Description
EXPRFSVI PRFSVIO 00 I/O Plus for VSAM Close
EXPRFSXI PRFSXIO 01 I/O Plus for XSAM Close
IMACPRFS PRFSHLP 02 HiperLoad Plus for VSAM
TYPEPRFS These data records describe the before and after buffers,
VMACPRFS etc., to track the effectiveness of this product.
Dec 2, 1993
Thanks to Yao-chun Rickert, First Chicago, USA.
Change 11.261 VM/ESA dataset VXSYTCUP (PR/SM and MLPF LPAR measurement)
VMACVMXA did not keep LCUCLPTM (LPAR Management time), so it was
Dec 1, 1993 added to the KEEP= list in macro _VSYTCUP, and is DIF'ed
in macro _DSYTCUP. Also, for inactive LPARs, MXG output
an observation, but variables LCUCPUID LCUCWGHT LCUCFLGS
LCUCACTM LCUCLPTM LCPUDED LCPUWAIT LCPUCAPD are not input
and could contain values from a prior LPAR; now they are
initialized. Similarly, VXSYTCUM logic for inactive LPARs
now initialized the un-read variables.
Thanks to Angie Olver, PERSETEL, South Africa.
Change 11.260 SAS Usage note 6886 identifies a SAS error when blank
ANALRACF characters appear between non-blank characters in an ID
Dec 1, 1993 value with PROC TRANSPOSE. In 6.06 the variables were
incorrectly left as blanks instead of being replaced by
underscores (as they were in 5.18, and are now in 6.07
and 6.08), and MXG code was actually modified between
5.18 and 6.06 to compensate. Now, however, UNINITIALIZED
variable messages result, so MXG has been re-modified to
correct. Variables _5_DATA, _6_RACF, _7_DATA,_8_NAME,
and _52_DSN are now spelled with an ending underscore:
_5_DATA_,_6_RACF_,_7_DATA_,_8_NAME_, and _52_DATA_.
Thanks to David Vaughan, Shropshire County Council, ENGLAND.
Change 11.259 A collection of data value errors have cropped up in the
VMXGHSM processing of the HSM BCDS and MCDS datasets:
Dec 3, 1993 -"Error 180" results because a semicolon is in the wrong
place. The semicolon after RECTYPE='REC TYPE ...' must
be removed, and instead a semicolon must be added to the
following line, after the label for TYPE='MCKTYPE ...'.
-"Invalid data for INPUT" results because "INPUT" should
removed from the line now reading "INPUT @65 BCRFLAGS..."
-Invalid argument for DATEJUL occurs if MCDEXPDT=99366,
95366,98000,99999,9999999 (which are invalid dates). The
calculation for MCDEXPDT was changed to set these invalid
data values to '31DEC2099'D (i.e., far into the future):
IF MCDEXPDT=99366 OR MCDEXPDT=95366 OR ...
THEN MCDEXPDT='31DEC2099'D;
ELSE IF MCDEXPDT GT 0 THEN MCDEXPDT=DATEJUL(MCDEXPDT);
ELSE MCDEXPDT=.;
-MHCRBGNT,MHCRENDT,and MHCRNXTT are now input &PIB.4.2 and
not &PK.4, the three PK1 fields after each time were
deleted, the +1 before the three dates was removed, and
the three HMS() calculations were deleted.
-DATEJUL(MHCRENDD) was changed to DATEJUL(MHCRNXTD).
-Two lines calculating DSRDATE were moved to before the
line DO I=1 to 11;
-Change DO C=1 TO MCPDGNCT; to read
IF MCPDGNCT GT 0 THEN DO C=1 TO MCPDGNCT;
-Change input of BCRTCAB from &PK.4. to BCRTCABC $CHAR4.,
delete input of BCRTCABH,BCRTCABM,BCRTCABH and following
+1, replace the BCRTCAB=HMS() line with
BCRTCAB=INPUT(BCRTCABC!!'00000000'X,TODSTAMP8.);
remove BCRTCAB from TIME8. format and instead format it
BCRTCAB DATETIME21.2.
Note: Dec 18, after 11.09 built: used similar logic for
BCRTBLA and BCRTLAB datetime variables.
-Change input of DCRCLEN from &PIB.4. to &PIB.2.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 11.258 Variables ACTDLYTM,DSPDLYTM,RESDLYTM were added by Change
IMACPDB 10.031 to TYPE30_4, but were not carried into PDB.STEPS
Nov 30, 1993 nor PDB.JOBS. They have now been added to the _PDB30_4
and _SUMSTP macros defined in IMACPDB, so they will now
exist in PDB.STEPS and PDB.JOBS.
Thanks to Bob Eastlake, Alternative Marketing Systems, USA.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Change 11.257 ASMVTOC may produce no output under MVS/ESA 3.1.3, 4.1.0,
ASMVTOC or possibly even 4.2.0. APAR OY39355 points out that DFP
Nov 22, 1993 3.3 (which introduced the new UCBSCAN COPY service) does
not run with earlier levels of MVS/ESA. If you have this
problem (no error, but no output from ASMVTOC), you can
simply comment out (by adding an asterisk in column one)
these two lines in ASMVTOC:
TM FLAG,MVSESA42 MVS/ESA V4.2 OR BEYOND?
BO MVS42AAB YES, GO USE UCBSCAN SERVICE
ASMVTOC has also failed with 213-04 when it encounters a
TPF volume. That problem is still under investigation.
Thanks to Ron Willingham, Fina Oil, USA.
Change 11.256 RMF Reports from PDB data are further corrected and
ANALRMFR enhanced. CPU percentages could be wrong, and type 74
Nov 21, 1993 reports were corrected.
Change 11.255 Support for DB2 Release 3.1.0 incompatibly altered SMF
type 100, 101, and 102 SMF records.
== added 11Jan95=======
== Messages on the log "ID=100 SUBTYPE=2 QWHSIID=202"
== tell you that you are reading DB2 3.1 SMF records
== with an old Version of MXG (MXG 11.09 or later is
== required).
ADOCDB2 100, 101, and 102 SMF records. New Datasets created are:
DIFFDB2 Dataset SMF Record Description
EXDB2ACP DB2ACCTP 101 Subtype 1 Package/DBRM executions
EXDB2ST2 DB2STAT2 100 Subtype 2 Hiperpool interval statistics
IMACDB2 Many new variables were also added to existing datasets.
VMACDB2 New variables are listed in member DOCVER11, and ADOCDB2
VMAC102 was updated with which DSECT is in which record and which
Sep 6, 1993 MXG dataset is created from which records. Details:
Nov 30, 1993 Dataset DB2ACCT:
Now contains 312 variables (was 215). New variables in
existing sections QWAC,QXST,QBAC,QTXA,and QLAC, and
new section QIFA. Variables QBACBPX and QBACSWU are
now reserved.
Dataset DB2ACCTP:
New dataset for Package/DBRM executions is built from
QPAC section(s) added to type 101 subtype 0 record (up
to ten sections will create ten observations), or from
new type 101 subtype 1 record (up to 10 per record, for
overflow if sections do not fit in existing subtype 0).
Dataset DB2STAT0:
Now contains 319 variables (was 277). New variables in
existing sections Q9ST,QWSD,QLST,QJST and QDST.
Variable QJSTWTL is now reserved.
Dataset DB2STAT1:
Now contains 447 variables (was 297). New variables in
existing sections QXST,QTST,QBST,QIST, and QTXA.
Variables QTCURPB,QTOPNOK,QTOPNNO,QTTTBRN,QTEXDRN,
QTSTDRN,QTPUBDD,QBSTBPX,QBSTSWU,and QBSTPUW are now
reserved.
Dataset DB2STAT2:
New dataset from new type 100 subtype 2 record.
Dataset T102S148:
New variables: QBnCDPF,QBnCHPG,QBnCHRE,QBnCHRF,QBnCHWF,
QBnCHWR,QBnCNGT,QBnCSIO n=1,2,3,4
Dropped vars: QBnCBPX,QBnCSWU n=1,2,3,4
Change 11.254 Support for AS/400 Version 2.3 Performance Data adds four
EXQAPDDI new datasets:
EXQAPFRL Dataset Description
EXQAPSTD QAPMDDI Distributed Data Interface (DDI) data
EXQAPSTY QAPMFRLY Frame Relay Data
IMACQAPM QAPMSTND DDI Station Counter Data
VMACQAPM QAPMSTNY Frame Relay Station
Nov 20, 1993 Changes were compatibly made, so prior versions of MXG
will not fail with the version's data records.
Change 11.253 Support for Memorex Telex LMS Version 2.17 SMF record now
EXLMSCUP creates these two new datasets:
EXLMSDAL Dataset Subtype Description
IMACLMS LMSCUP 06 Cart Update (inhibit SCR indicator)
VMACLMS LMSDALC 29 Device Allocation
Nov 20, 1993 Also, VMACLMS was restructured for consistent colimation.
Thanks to Dan Kaberon, Hewitt Associates, USA
Change 11.252 Support for Mobius INFOPAC-RDS user SMF record is added
ADOCIPAC by this comprehensive user contribution. Datasets are
ANALIPAC documented in ADOCIPAC, and sample analysis reports are
EXIPAC01 in ANALIPAC! Five new datasets are created:
EXIPAC02 Dataset Subtype Description
EXIPAC03 IPAC01 01 Batch Printing Usage Statistics
EXIPAC04 IPAC02 02 Online Printing Usage Statistics
EXIPAC05 IPAC03 03 Online Viewing Usage Statistics
IMACIPAC IPAC04 04 Archive Recall Usage Statistics
TYPEIPAC IPAC05 05 Archive I/O Subsystem Tuning & Perf
VMACIPAC And the analysis example, ANALIPAC, is comprehensive: it
Nov 19, 1993 combines the VERSIONS and DISTRIBUTION databases from
the INFOPAC-RDS product, with MXG's PDB.HSMFSRST (from
HSM), and PDB.PRINT (from JES2 printing), Vanguard's
RACF database, with three of the five SMF subtypes.
Thanks to Jeff Burnett, Anixter, USA.
Change 11.251 The ASM program to break down MVS/ESA 4.3 RMF Monitor III
ASMRMFV segments into actual records was missing code (lost in
Nov 19, 1993 fax transmission and transcription!). The code has been
corrected, and renamed to ASMRMF3 instead of ASMMON3.
This is preliminary for MXG support of the compressed ESA
4.3 data - the SAS code to process the output of the ASM
utility is still in development. See Change 11.238.
The ASMRMF3 member was replaced by ASMRMFV.
Change 11.250 Xerox SFS records from 9700 INVALID ARGUMENT TO INPUT
VMACSFS FUNCTION occurs if CUSTJNR contains hex nulls instead of
Nov 18, 1993 blanks. Insert this line:
VAR(10)=TRANSLATE(VARS(10),'40'x,'00'x);
immediately preceding the existing line:
CUSTJNR=INPUT(VARS(10),8.);
Thanks to Doug Medland, Confederation Life Insurance, CANADA.
Change 11.249 Support for Integris' UniKix product, used to downsize
EXTYUNIA CICS VSAM and DB2 applications to the Unix environment.
EXTYUNIK The product creates a binary file of performance records
IMACUNIA and provides a conversion program to create a portable
IMACUNIK ASCII file. MXG can process either the binary or ASCII
TYPEUNIA file under UNIX, Windows, or OS/2 SAS, or the ASCII data
TYPEUNIK can be uploaded for processing under MVS SAS. This is
VMACUNIA the beta release of the UniKix measurements, and Integris
VMACUNIK will restructure the data records in their next release
Nov 17, 1993 (at my suggestion) so they will be true variable-length,
self-defining records so that future enhancements can be
made to the data records compatibly, so the MXG support
will be revised when those changes are available.
The current implementation members ....UNIA are for the
ASCII file (infile name UNIKIXAS), and members ....UNIK
are for the Binary file (infile name UNIKIXBI).
Change 11.248 Support for BatchPipes/MVS type 91 SMF record creates 11
EXTY9101 new datasets:
EXTY9102 Dataset Subtype Description
EXTY9103 TYPE9101 01 Subsystem Initialization
EXTY9104 TYPE9102 02 Subsystem Interval
EXTY9111 TYPE9103 03 Subsystem Termination
EXTY9112 TYPE9104 04 Subsystem Parms Changed
EXTY9113 TYPE9111 11 Pipe Connection Open
EXTY9114 TYPE9112 12 Pipe Connection Interval
EXTY9115 TYPE9113 13 Pipe Connection Close
EXTY91IC TYPE9114 14 Pipe Create
EXTY91OC TYPE9115 15 Pipe Delete
IMAC91 TYPE91IC 11-13,15 Input Connection Details
TYPE91 TYPE91OC 11-13,15 Output Connection Details
VMAC91 Subtypes 1 and 3 are Pipes Subsystem event records.
Nov 17, 1993 Subtypes 2 and 4 are interval or termination records with
statistics on each Pipes Subsystem (pipes/connections
created/deleted/active, input/output bytes, etc.).
Subtype 11-15 are Pipe Connection records, which identify
the pipename being accessed, and (for subtype 12 and 15)
contain pipe activity counts. In addition, subtypes 11,
12, 13, and 15 can contain one or more Connection Detail
sections (either Input or Output connection), so MXG
creates one observation in TYPE91IC or TYPE91OC for each
Connection Detail segment (which contains JOB,READTIME,
DDNAME, six timestamps, reads/writes, bytes in/out, etc.)
for each user of a pipe. This structure lets you analyze
overall pipe statistics with the subtype datasets, or the
pipe statistics by user with the IC/OC detail datasets.
MVS Pipes looks to be a very powerful new MVS facility!
Change 11.247 Support for Novell Network Navigator user SMF record now
EXTYNNAV creates one dataset:
IMACNNAV Dataset Description
TYPENNAV TYPENNAV Network Navigator Session Resources
VMACNNAV with session logon and logoff datetimes, JESNR, bytes
Nov 16, 1993 sent/received, and TGETS/TPUTS for the session.
Thanks to Elena Beryozkin, United Parcel Service, USA.
Change 11.246 Support for NetView Performance Monitor NPM Version 2.1.0
EX028NWC added major enhancements, especially in the area of VTAM
EX028NWD monitoring, with CPU and storage used by VTAM. Thirteen
EX028RMA new datasets are created:
EX028RMD Dataset Subtype Description
EX028VAP NPMRMSTR BA RTM ACTIVATE
EX028VAD NPMRMSTP BB RTM DEACTIVATE
EX028VBF NPMVTSTR D0,D1,D2 VTAM START/STOP/MD
EX028VEN NPMVTEXC D3,D4 VTAM EXCEPTION
EX028VDV NPMVSVEN D5 VTAM ENVIRONMENTAL
EX028VGB NPMVSVGB D6 VTAM GLOBAL
EX028VTE NPMVSVBF D7 VTAM BUFFER POOL
EX028VTS NPMVSVDV D8 VTAM DEVICE DATA
EX028VVR NPMVSVVR D9 VTAM VIRTUAL ROUTE
FORMATS NPMVSVAP DA VTAM APPLICATION
IMAC28 NPMVSVAD DB VTAM ASID DATA
VMAC28 NPMNWCWC FC WRKSTN-NPM CONNECT
Nov 13, 1993 NPMNWDWD FD WRKSTN-NPM DISCON
Change 11.245 The original change described in this text in MXG 11.07
VMXGSUM thru MXG 11.09 were never actually implemented. The text
Nov 12, 1993 of the change was written, but the VMXGSUM member was not
moved into the MXG library, because the KEEPIN= logic did
not produce identical output datasets, and it had to be
backed out of the changes. See Change 11.281 & 11.309.
Change 11.244 A new utility, UCICSCNT counts how many SMF type 110 CICS
UCICSCNT records come from each CICS Region, by CICS version, and
Nov 10, 1993 by record subtype, so you can prove to your CICS guru
which APPLIDs have monitoring and/or statistics records.
Thanks to Richard S. Ralston, Whirlpool Corporation, USA.
Change 11.243 Support for NETWISE's RPC EXEC product type 33 SMF record
VMAC33 adds these "accounting" fields to dataset TYPE33_1:
Nov 9, 1993 NETWCAPN,NETWCOMP,NETWCORR,NETWMDNM,NETWRPCM,NETWRPCN,
NETWRPCN,NETWRPCT and NETWSAPN. MXG now creates one obs
in TYPE33_1 for each TPUSE section; previously only the
first TPUSE section's data was output. With NETWISE's
data, there are two sections in each record, one for the
inbound and one for the outbound connections, so there
two observations for each NETWISE SMF record.
Thanks to Linda Marzik, EDS Performance and Evaluation Group, USA.
Change 11.242 DB2 variable NETSNAME still can have blanks, after Change
VMACDB2H 11.050, preventing DB2ACCT matching with CICSTRAN. This
Nov 8, 1993 happens if the last half of NETSNAME contains blanks; the
correction is to translate all blanks in DB2 NETSNAME to
nulls. After the NETSNAME algorithm, and just before
"/* CREATE UOWTIME FROM QWHCTOKN */", insert the line:
NETSNAME=TRANSLATE(NETSNAME,'00'X,'40'X);
Thanks to Edward McCarthy, Health Insurance Commission, AUSTRALIA.
Change 11.241 TRNDRMFI will fail with VARIABLE PLATCPUS NOT FOUND when
TRNDRMFI ASUM70PR is not executed. Add in the INCODE= section:
Nov 8, 1993 IF PLATCPUS=. THEN PLATCPUS=.; just like PARTNCPU.
There is no requirement to run ASUM70PR before TRNDRMFI,
but without it, PLATCPUS did not exist, until the change.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Change 11.240 Variables READY12 READY13 READY14 READY15 were left out
TRND70 of the NORM2= list in this trending member, causing their
Nov 8, 1993 summary values to be erroneously large.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Change 11.239 MXG Early PreRelease 11.08 only. IF ID=80 SOURCE='RACF';
ANALSMF should have been IF ID=80 THEN SOURCE='RACF';
Nov 8, 1993
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
==Changes thru 11.238 were included MXG Early PreRelease 11.08 01Nov93=
Change 11.238 This new Assembler program reads the RMF Monitor III VSAM
ASMRMFV files from MVS/ESA 4.3 (which are compressed, and are not
Oct 30, 1993 standard records). It was typed from a fax, and has not
been tested, but I wanted to make it available for tests
because there are reported problems in the ZRB processing
that are still unresolved. See Change 11.251.
Was ASMMON3 until change 11.251.
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 11.237 ANALDB2R could not use a PDB on tape for reports, because
ANALDB2R multiple datasets were opened simultaneously, but with a
Oct 30, 1993 new TREND= parameter, either the Accounting or Statistics
reports can be run from your PDB= on tape. Only if you
want to include your TREND data base and your PDB data
bases together for a report will you need to point TREND=
to the DDname for your TRNDDB2A, TRNDDB20, and TRNDDB21
datasets.
Change 11.236 Internal logic was improved for performance. If the first
VMXGSUM data step or the SORT is not needed, they are bypassed.
Oct 30, 1993 This can reduce CPU and DASD requirements significantly.
If no INCODE=, no INTERVAL=, no SHIFT=, and no NORMX= are
used and there is only one input dataset, the first data
step is bypassed. If there is no SUMBY=, then no SORT.
Unfortunately, most of the ASUMxxxx and TRNDxxxx members
that invoke VMXGSUM do not meet the criteria and see no
benefit, but ANALDB2R gets some help, and it is the
righteous thing to do anyhow. See Change 11.309.
Change 11.235 Trending of VM/XA and VM/ESA MONWRITE dataset VMXAINTV
TRNDVMXA had logic errors, that causes several variables to be
Oct 30, 1993 incorrect.
Thanks to Sean Chaffee, Amadeus Data Processing GmbH & Co., GERMANY.
Change 11.234 Support for SMF type 42 subtype 14 (IBM ADSM Distributed
VMAC42 Storage Management Product) provides good statistics in
Oct 30, 1993 the new TYPE42AD dataset, with counts of byte traffic
and objects, for backup and archived files moved between
client and server, as well as CPU time plus waiting time
for Communications or Media, and session idle time.
The only identifiers, however, are the client name and
the client owner name. Unrelatedly, but because VMAC42
was "open", DFSMS Data Set, Storage Class, and Total
datasets were enhanced with read and write hit percents.
Thanks to Peggy Schulte, Cincinatti Gas and Electric Company, USA.
Change 11.233 SAS option SORTDEV=3380 was removed from MXG's CONFIG
CONFIG members - it is not needed, and caused errors at sites
Oct 30, 1993 that have no 3380s.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 11.232 Variable AVGMTPTM was retained across device records that
VMAC74 had no Mount Pending. After its calculation, insert
Oct 30, 1993 ELSE AVGMTPTM=.;
Change 11.231 Additional enhancements and corrections to RMF reports.
ANALRMFR MXGCPU - Added OMVSMAX,OMVSAVG statistics.
Oct 30, 1993 MXGPAGE - Added OMVS00-OMVS11 statistics
MXGDEVC - DEVMTPTM to DEVACTTM, changed summary BY LCU
for calculation of AVGMTPTM.
MXGSMRY - BY SYSTEM DATE TIME changed to BY SYSTEM DATE.
Final page per system for overall total/avgs.
Corrected CPU busy percentages (only wrong if
you requested 24 hour report spanning 2 days).
MXGWKLD Added OMVS swap counts.
MXGENQU Circumvented "MISSING VALUE" note.
Thanks to Bill Stoneberg, National-Oilwell, USA
Change 11.230 MXG 11.06 or later. Landmark CICS causes "INVALID
TYPEMON8 ARGUMENT TO FUNCTION MDY" or "MXG HAS DETECTED INVALID
Dec 1, 1993 FORMAT FOR TIESDATE" because MO and DD were reversed in
the MDY() function. Change the MDY() function to read:
TIESDATE=MDY(MO,DD,YY);
See also change 11.278.
Thanks to Tom Clark, SEI Corporation, USA.
Thanks to Mark Robbins, W.H. Smith Limited, ENGLAND.
Change 11.229 Change 11.199 still did not calculate GMTOFF correctly.
VMAC30 Instead of the two IFs and kludgy FLOOR/CEIL logic, the
VMAC7072 correction is to use a single statement with +10 added:
Oct 30, 1993 GMTOFF70=100*FLOOR((STARTIME+DURATM-SYNCTIME+10)/100);
GMTOFF72=100*FLOOR((STARTIME+DURATM-SYNCTIME+10)/100);
GMTOFF30=100*FLOOR((SMF30IST-INTBTIME+10)/100);
Change 11.228 Open Edition/MVS (OMVS) dataset TYPE30OM was added to the
BUILDPDB PDB library. At present, it is simply sorted into the
BUILD005 PDB, but this logic may change with more experience with
Oct 30, 1993 the new data for "Unix under MVS".
Change 11.227 These new (calculated) variables were added to TYPE71,
TRND70 TRND71, and TRNDRMFI, as they have been found useful in
TRND71 MVS/ESA 4.3 analysis of paging and memory.
TRNDRMFI BLKPAGE ='BLOCKED*PAGES*PAGED IN'
VMAC71 NBLKPAGE='NON-BLOCKED*PAGES*PAGED IN'
VMAC7072 COMPAGE ='TOTAL*COMMON*PAGING RATE'
Oct 30, 1993 CS_ESPAG='TOTAL*CSTORE TO/FROM ESTORE*PAGING RATE'
HIPEPAGE='TOTAL*HIPERSPACE*PAGING RATE'
PGPERBLK='PAGES*PER*BLOCK'
SWAPAUX ='SWAP RATE*TO*AUXSTORE'
CSTORE ='CENTRAL*STORAGE*ONLINE'
ESTORE ='EXPANDED*STORAGE*ONLINE'
Variable PCTRDYWT was added in TRND70, and TRNDRMFI was
updated to include the ESA variables that had been added
in RMFINTRV but had been overlooked in TRNDRMFI.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 11.226 JES2 NJE Purge Records for Job Transmission should have
BUILDPDB been OUTPUT to PDB.NJEPURGE, but were not; in rare cases,
BUILD005 they were used in place of the real JES2 Execution Purge
VMAC26J2 record. In BUILDPDB, the test to OUTPUT PDB.NJEPURGE was
Oct 29, 1993 expanded from (INREASON=' ' OR INREASON='JR' AND ... to
((INREASON=' ' OR INREASON='JR' OR INREASON='JT') AND ..
and VMAC26J2 logic was modified to test if INREASON was
still blank after testing INDEVICE, and if so, the same
decoding was applied to DEVNAME. The specific case that
was encountered had INDEVICE=INTRDR,DEVNAME=L329.JT1.
This change can alter the number of observations in the
PDB.JOBS and PDB.NJEPURGE datasets.
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 11.225 Support for Amdahl APAF Version 2.1 adds "Effective" CPU
EXAPAFCH time, "Dispatched" CPU time, and the "In-Domain Mgmt" CPU
EXAPAFCP time variables for each MDF domain in dataset APAFDOMA.
IMACAPAF The "Outside-Domain Mgmt" CPU time, (IBM's "PHYSICAL")
VMACAPAF has been added to dataset APAFGLOB. New CPU Busy dataset
Oct 27, 1993 APAFCPBY provides, for each LP, the sampled percent CPU
busy in Problem state and in Supervisor state. Finally,
the new "Channel Busy" dataset APAFCHAN provides, for
each CHPID, separately for each Domain, the sampled CHAN
busy statistics. There's a lot of good stuff here! The
new subtype 4 and 5 code has only been syntax checked as
of this date, as those new data records were not provided
in the Amdahl sample set, but the APAFDOMA/APAFGLOB data
has been processed. Ultimately, there will probably need
to be a summary routine (like ASUMPRSM, will be named
ASUMAPAF if/when it exists), but only after test data and
some user experience is available! See Change 11.290.
Thanks to George Scott, Rockwell International Corporation, USA.
Change 11.224 CICS/ESA "Requested Reset Statistics", statistics records
CICINTRV with SMFSTRQT='RRT', were overlooked in member CICINTRV,
EXCICRRT but now new dataset PDB.CICRRTRV will be created from the
IMACCICS RRT records. Because this change adds a new dataset, if
Oct 25, 1993 you have tailored IMACCICS in your USERID.SOURCLIB, you
MUST retrofit your tailoring to the new IMACCICS, or you
will encounter "CICRRTRV NOT FOUND" syntax errors.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 11.223 INVALID DATA FOR OWNEXPDT message results when hex zeroes
VMAC6156 are in the Packed Decimal field, but there is no effect
Oct 25, 1993 on dataset TYPE6156, since SAS sets OWNEXPDT missing. By
inserting two question marks between OWNEXPDT and the
PD3. (or &PD.3.) informat, the invalid data message is
suppressed.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 11.222 Variable VIO occurs twice in the NORM1 argument in TRND71
TRND71 causing its value to be incorrect. Remove the first
Oct 25, 1993 occurrence. Variable CPUPAGTM (new in MVS/ESA 4.3) was
not kept in TRND71, so add it at the end of the SUM= .
Thanks to Diane Eppestine, Southwestern Bell.
Change 11.221 CICS/ESA excluded fields can be identified on the output
IMACEXCL of UTILCICS by the value of 65535 ('FF'x) for CMODOFST
UTILCICS (i.e., there is no offset to that field). A title was
Oct 25, 1993 added to that report documenting this fact. Comments in
IMACEXCL for the MACRO _CICXCUS definition now identify
which fields were added in CICS/ESA 3.2.1 and 3.3.
Thanks to Pierre Thibodeau, CGI Group, CANADA.
Change 11.220 Changes required only for execution under ASCII SAS:
VMACCMA a.SAS under Windows has a problem with old-style macros if
VMAC28 the contents start in column 1. Shifting the source code
VMAC102 one byte to the right circumvents the problem. This was
VMACLMS necessary in members VMACCMA, VMAC28, VMAC102.
ANALSMF b.SAS under Windows has a problem with ELSE ending one line
Oct 24, 1993 and its IF starting in column 1 of the next line. The IF
statements in VMACLMS were shifted right one column.
c.ANALSMF contained LENGTH 2, which was changed to 3.
d.Many ANAL members still had the old concatenation symbol
(pair of vertical bars, '4F'x on MVS) which is translated
to brackets under ASCII, which is not recognized by SAS
as concatenation. All were changed to exclamation point
which are acceptable to both ASCII and EBCDIC SAS.
Change 11.219 Support for FOCUS MSO 6.8 added variables FOCUACCT,
VMACFOCU FOCUCOMP,FOCUFACT,FOCUID1,FOCUID2,and FOCUPRTY to dataset
Oct 21, 1993 FOCUSMSO, and variable FOUCFRV no longer exists. Since
these fields were added compatibly to the SMF record,
previous MXG versions will process the new record (but
won't input the new variables!). Additionally, variables
SYSTEM and SMFTIME are now kept.
Thanks to Scott Ashby, Wachovia Operational Services Corp, USA.
Change 11.218 VM variable PWCOUNT is strangely stored by IBM. Values
TYPEVM are EBCDIC numbers 0 thru 9 (i.e., '40F0'x thru '40F9'x),
Oct 21, 1993 but a value of ten is stored as '0A', or 'F0C1'x, sixteen
is '0F' or 'F0C6'x, etc!). MXG now parses each byte and
figures out what IBM did so you get the right number.
Change 11.217 Division by zero can occur in processing TYPE78 data.
RMFINTRV The three lines with /NRATTMPS need to be placed in a DO
Oct 21, 1993 group : IF NRATTMPS GT 0 THEN DO; ... END; so that
division only occurs if NRATTMPS is greater than zero.
Thanks to Tom Miron, State of Wisconsin Dept of Administration, USA.
Change 11.216 GRAFTRND did not print workload data for any workloads
GRAFTRND after an unused workload. So if you don't use the IMS
Oct 21, 1993 workload, the TSO, BATCH, and all OTHx workloads do not
appear on the output graph. Change the 15 occurrences of
CPUSUM=CPUSUM+CPU; to read CPUSUM=SUM(CPUSUM,CPU,0);
Thanks to Bill Stoneberg, National Oilwell, USA.
Change 11.215 SMF type 57 variables added by Enhanced SYSOUT Support
VMAC57 (SMF57LN5,SGT,IND,RSV,JDT, TUL, and TU) are trashed for
Oct 21, 1993 sites without the ESS segment (they should be missing).
Change the test IF OFFESS NE 0 AND NRESS NE 0 THEN DO;
to read IF OFFESS GT 0 AND NRESS GT 0 THEN DO;
so the loop is executed only when the ESS section is in
the record. (NE is TRUE for a missing value, GT is not).
Thanks to John Mattson, National Medical Enterprises, USA.
Change 11.214 JES3 variable CLASS (Class on Main) was added to MACRO
IMACPDB _PDB26J3, so it will now be kept in the PDB.JOBS dataset.
Oct 21, 1993
Thanks to Hong-Suk Yang, Dept. of Health & Housing, AUSTRALIA
Change 11.213 Variable IOTM6421 in TYPE30 should have been formatted
VMAC30 as TIME12.2; now it is.
Oct 21, 1993
Thanks to Dan Squillace, SAS Institute Cary, USA
Change 11.212 ALIGN must be specified for the ASM of this VVDS-grazer
ASMVVDS program, as VMACVVDS expects the data record to contain
Oct 20, 1993 the extra bytes created by the ALIGN Specification. I
completely forgot that ALIGN/NOALIGN can affect the data
format for a DS field, and it appears that most sites use
ALIGN by default (since the program has been in use for
years), but one site whose default was NOALIGN had their
TYPEVVDS program ABEND, so the JCL now explicitly has the
ALIGN parameter.
Apologies to whoever found this problem, whose name/company I lost.
Change 11.211 CICS SAP Accounting variables STCDB1-STCDB5 are character
IMACICSA variables, not numbers. Find all occurrences of STCDB and
Oct 20, 1993 change their label from "CALLS" to "NAME" in five places
and change their INPUT from "&PIB.4." to "$CHAR4." in ten
places.
Thanks to Mr. Bodenbender, BUDERUS, GERMANY.
Change 11.210 The FACOM pseudo-RACF product's type 127 SMF record will
VMACF127 cause "FUNCTION CHAN IS UNKNOWN" and "VARIABLE CHAN HAS
Oct 13, 1993 ALREADY BEEN DEFINED" if the F127 processing is added to
BUILDPDB. Change "CHAN" to "CHANS" in the ARRAY, RETAIN,
and two occurrences of CHAN(CHANNUM+1) statements.
Thanks to Denis Johnco, Datacom Systems Ltd, NEW ZEALAND.
Change 11.209 The INPUT of variables MVTRERR,MVTWERR,MVPRERR,MVPWERR
VMACCOMP in VMACEDGS and variable ULOGCPUT in VMACCOMP need period
VMACEDGS in informat (i.e., they should be "&PIB.2. " instead of
Oct 12, 1993 "&PIB.2 "). Invalid data results without this change!
Change 11.208 The example AUTOEXEC.SAS for OS/2, Windows, and Unix did
AUTOEXEC not invoke %VMXGINIT, but only included it! Change to:
Oct 11, 1993 %INCLUDE SOURCLIB(VMXGINIT); %VMXGINIT;
(Why did I %INCLUDE the macro first, when only its
invocation is required, since MXG uses MAUTOSOURCE?
Because I frequently SAS GO under TSO, and changes to
VMXGINIT did not take effect with the "GO" option!)
Change 11.207 Support for TOP-SECRET type 80 records written to a log
TYPE80 instead of to SMF is accomplished by changing " _SMF "
TYPE80A reference in TYPE80/TYPE80A to " _NETVLOG ". These log
Oct 11, 1993 records are written with only one 4-byte RDW field, so
the MVS RECFM=VBS or RECFM=VB or RECFM=V won't work (all
MVS variable records have both a 4-byte BDW and a 4-byte
RDW). The _NETVLOG macro defined in VMACSMF, used in
place of the _SMF macro, handles this "DOS RECFM=V" data.
Note: MXG members TYPE80/TYPE80A were not changed by this
change; this is an optional change that you must make if
you must process these records from a log instead of SMF.
Thanks to Jan-Ake Christoffersson, GotaData, SWEDEN.
Change 11.206 WEEKBLD/MONTHBLD error "DATA SET TAPEMNTS IS NOT SORTED"
MONTHBLD occurs IF you install Change 11.040, as it was incorrect.
WEEKBLD The correct order for TAPEMNTS (and TYPETMNT) in both
Oct 11, 1993 WEEKBLD and MONTHBLD is:
BY SYSTEM SHIFT DEVICE TMNTMTYP TMNTTIME;
Thanks to Bill Stoneberg, National-Oilwell, USA.
Change 11.205 This change to ANALVVDS and VMACVVDS are needed ONLY if
ANALVVDS you want ANALVVDS to correctly report VSAM statistics.
VMACVVDS Except for adding variable VVRTYPE to TYPEVVDS for that
Oct 11, 1993 report, this change does not alter data set TYPEVVDS:
Variable VVRTYPE was added to the KEEP= list in VMACVVDS,
so that ANALVVDS can test VVRTYPE to prevent the MXG
generated "***NUMEXT" error messages printed because
that report program did not anticipate the existence of
NVR (non-VSAM records) in a VVDS! For the VSAM space
analysis, NVR records must be deleted by inserting
IF VVRTYPE='N' THEN DELETE; after SET MXGVVDS.TYPEVVVDS;
Unfortunately, I discovered that I had reused variable
VVRTYPE, and the value kept was from its second use! To
correct, rename all VVRTYPE to VVRSTYPE in VMACVVDS,
except for its KEEP, LABEL, and the first INPUT statement
and for all tests of '00'x, 'D8'x, 'E9'X, and 'D5'x,
which must still use VVRTYPE).
Thanks to Billy Westland, Hitachi, USA.
Change 11.204 Dataset TYPEVVDS variable VVRBSENM can be blank because
VMACVVDS this test in VMACVVDS:
IF VVRCATNL THEN INPUT VVRBSENM $VARYING. VVRBSENL @;
Oct 11, 1993 must be changed to:
IF VVRBSENL THEN INPUT VVRBSENM $VARYING. VVRBSENL @;
Thanks to Billy Westland, Hitachi, USA.
==Changes thru 11.203 were included in MXG PreRelease 11.07 dtd 4Oct93=
Change 11.203 TYPE60 observations for NVR records have missing SMS
VMAC60 Storage, Data, Management Classes; alignment was off by
Oct 4, 1993 one byte. Change @OFFNVR+04 to @OFFNVR+03, and in the
following line change @OFFNVR+05 to @OFFNVR+04.
Thanks to BIll Cassidy, IST, CANADA.
Change 11.202 Support for NETVIEW APAR OY66237 SMF Type 37 (Hardware
VMAC37 Monitor Log Record) coded for the ETHERNET LAN section,
Oct 4, 1993 but without actually seeing at a dump of a record with
the new data segment. Furthermore, it's not clear which
APAR added the data segment, as OY66237 is documentation
only.
Change 11.201 TYPE90 variables OLDDSN/NEWDSN were renamed OLDDSNSM and
VMAC90 NEWDSNSM (they are the old/new SMF dataset names) to
Oct 4, 1993 avoid conflict with TYPE80A variables OLDDSN/NEWDSN.
Change 11.200 PROC GPLOT can 0C4 ABEND, or CPU loop, unless you have
GRAFLPAR these options in effect on a GOPTIONS statement:
GRAFRMFI NOPCLIP NOPOLYGONFILL NOPOLYGONCLIP
GRAFTMNT This is a known SAS bug with no ZAP yet, but it can be
GRAFTRND circumvented by
GRAFTRND a) removing all GOPTIONS statements in members GRAFLPAR,
GRAFWORK GRAFTRND and GRAFWORK (the only ones with exposure),
VMXGGOPT b) changing the GOPTIONS in member VMXGGOPT by inserting
Oct 2, 1993 NOPCLIP NOPOLYGONFILL NOPOLYGONCLIP
after the existing line:
NOCHARACTERS NOCELL GOUTTYPE=INDEPENDENT
The bug only occurs when area fill is used with GPLOT.
Unrelatedly, TMNTMTYP is now labeled in GRAFTMNT,
V=NONE is added to three SYMBOL statements in GRAFTMNT,
and TRIVRESP is now FORMAT 6.2 in GRAFRMFI.
Thanks to Chuck Hopf, Primerica, USA.
Change 11.199 TYPE30_V and PDB.SMFINTRV variables INTBTIME/INTETIME can
VMAC30 be 100 seconds earlier that actual because my fuzzy logic
VMAC7072 to convert the GMT values to local time was too fuzzy!
Oct 2, 1993 The algorithm
GMTOFF30=100*FLOOR((SMF30IST-INTBTIME)/100);
must be replaced with
IF (SMF30IST-INTBTIME) GT 0 THEN
GMTOFF30=100*FLOOR((SMF30IST-INTBTIME)/100);
ELSE IF (SMF30IST-INTBTIME) GT . THEN
GMTOFF30=100*CEIL((SMF30IST-INTBTIME)/100);
because SMF30IST has 10 millisecond resolution, while the
INTBTIME has 1 microsecond resolution, and IST=30:19.70,
INTB=30:19.7064 created a GMTOFF30=-1:40.00 (-100 secs)
instead of zero, due to the FLOOR of a negative number!
TYPE70 variable SYNCTIME can also be incorrect. VMAC7072
GMTOFF70=100*FLOOR((STARTIME+DURATM-SYNCTIME)/100);
must be similarly replaced with:
IF (STARTIME+DURATM-SYNCTIME) GT 0 THEN
GMTOFF70=100*FLOOR((STARTIME+DURATM-SYNCTIME)/100);
ELSE IF (STARTIME+DURATM-SYNCTIME) GT . THEN
GMTOFF70=100*CEIL((STARTIME+DURATM-SYNCTIME)/100);
and the GMTOFF72 logic must be similarly replaced.
Note: This change revised by Change 11.229.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 11.198 Type 42 subtype 4 records testing caused STOPOVER abend.
VMAC42 After the @; after the INPUT of TYPETEST, insert these
Sep 30, 1993 two statements: M1=-1; INPUT +M1 @;
Also, labels for variables JESNR and TYPETASK were wrong.
Thanks to John Maher, Home Savings of America, USA.
Change 11.197 TYPEQAPM causes SAS 6.07 to 0C4 ABEND IN FUNCTION DSRFMT
SAS 6.07 AT OFFSET 000200. Problem has just been discovered. Does
Sep 30, 1993 NOT fail with SAS 6.08.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 11.196 New Partition Channel busy was incorrectly printed.
ANALRMFR Change ... PUT @20 PNCHANBY 6.2 @;
to read: ... PUT #LIN @COL+20 PCHANBY 6.2 @;
Sep 30, 1993 Change ... @13 CHANSHAR
to read: ... @COL+13 CHANSHAR
Change 11.195 Variable PNCHANBY was propagated into observations with
VMAC73 no activity. After the line that calculates PNCHANBY,
Sep 30, 1993 insert: ELSE PNCHANBY=.; to reset the value.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 11.194 VMXGHSM did not output all observations in dataset DSR.
VMXGHSM The line IF DSNRTRKR = 0 AND DSNRTRKW = 0 THEN DELETE;
Sep 30, 1993 must itself be deleted, and in the OUT_DSR macro, replace
OUTPUT DSR; with
IF DSNRTRKR GT 0 AND DSNRTRKW GT 0 THEN OUTPUT DSR;
Thanks to Mr. Ertingshausen, RWG GmbH, GERMANY
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
Change 11.193 Preliminary NDM support in 11.07 has now been tested with
EXNDMAE SMF records, uncovering these errors for early recipients
EXNDMCH a. Change all "PK2" to "PK1".
EXNDMDP b. Change the one "PIB.2 " to "PIB.2." (add a period).
EXNDMDT c. Add variables NDMRVOLS NDMSVOLS NDMRVOL1 NDMSVOL1
EXNDMFP to the KEEP list for NDMCT.
EXNDMGF d. Change occurrences of "+19+OFFSMF" to "+15+OFFSMF".
EXNDMMC e. Change the INPUT @15+OFFSMF statement to look like:
EXNDMRJ INPUT @15+OFFSMF
EXNDMRT NDMRECLN &PIB.2. /*NDM RECORD LENGTH*/
EXNDMSI NDMRTYPE $EBCDIC2. /*RECORD*SUBTYPE*/
EXNDMST @;
TYPENDML IF NDMRTYPE NE 'CT' AND NDMRTYPE NE 'PS' AND
VMACNDM NDMRTYPE NE 'PT' AND
VMACSMF NDMRTYPE NE 'WO' THEN DELETE;
Sep 30, 1993 INPUT HH &PK.1. /*HOUR*/
Oct 3, 1993 MM &PK.1.
This change also added support for all 22 subtypes, now
creating fifteen NDM datasets:
Dsname Description NDMRTYPEs
NDMAE Authorization Event AE
NDMCH Change Process Termination CH
NDMCT Copy Termination Record CT
NDMDP Delete Process Termination DP
NDMDT Display Termination DT,FT,SP,SN,SS
NDMMC PDS Member Copy Record MC
NDMFP Flush Process Termination FP,FS,TS
NDMGF General Function Termination GF
NDMPS Start Process PS
NDMPT Process Termination Record PT
NDMRJ Run Job Termination Record RJ
NDMRT Run Task Termination Record RT
NDMSI Signon File Record SI,SO
NDMST Stop NDM Event ST
NDMWO Authorization Event WO
Member TYPENDM processes the NDM Statistics from SMF.
The NDM Sample Library member ???????? provides the exit
code to write that data in an SMF record.
Member TYPENDML, added by this change, will process the
NDM Statistic File directly, for sites that did not write
their NDM data to SMF.
Thanks to Chuck Hopf, Primerica, USA.
==Changes thru 11.192 were in the Early MXG PreRelease 11.07 dtd 1Oct93=
Change 11.192 Additional cleanup and enhancement of RMF-like reports
ANALRMFR from MXG data sets continues.
Sep 28, 1993
Change 11.191 The ADOC documentation for data sets built from VM/ESA
ADOCVMXA (and VM/XA) MONWRITE records is now 150 pages, although
Sep 28, 1993 this documentation member is still in progress.
Change 11.190 Support for IBM's DFSMSrmm Removable Media Manager's
EXEDGRD Extract file created by IBM utility EDGHSKP creates six
EXEDGRO new MXG data sets (equivalent of EDGRPTD reports):
EXEDGRP EDGRDEXT - DFSMSrmm Extract Data Set Name Record
EXEDGRR EDGROEXT - DFSMSrmm Extract Data Set Owner Record
EXEDGRS EDGRPEXT - DFSMSrmm Extract Data Set Software Product
EXEDGRV EDGRREXT - DFSMSrmm Extract Data Set Rack Record
IMACEDGR EDGRSEXT - DFSMSrmm Extract Data Set Storage Location
TYPEEDGR EDGRVEXT - DFSMSrmm Extract Data Set Volume Record
VMACEDGR These extract data sets are good for quick reports, but
Sep 28, 1993 have only a subset of the data available in the SMF Audit
data records described in Change 11.189. Let me know
which you find more useful. This code has only been
syntax checked and bench checked with a dump of three
of the Extract records.
Thanks to Leatha Harlow, Sperry Marine Inc, USA
Change 11.189 Support for IBM's DFSMSrmm Removable Media Manager's two
EXEDGSA user SMF records provides extensive measurement of the
EXEDGSD new IBM tape management product. These datasets allow
EXEDGSK you to:
EXEDGSO - List the contents of the system-managed libraries,
EXEDGSP non-system managed shelf space, and storage locations.
EXEDGSR - List volumes that should be moved from the library to
EXEDGSS storage locations.
EXEDGSU - Identify secure volumes that have been created or
EXEDGSV referenced.
EXEDGS0 - Audit library activites.
EXEDGS1 The Security record (EDGSMASR) creates one MXG dataset:
IMACEDGS EDGSSECU - DFSMSrmm Security Record.
TYPEEDGS The Audit Record (EDGSMFAR) creates ten new datasets:
VMACEDGS EDGSAREC - DFSMSrmm Action Record
Sep 28, 1993 EDGSDREC - DFSMSrmm Data Set Information Record
EDGSKREC - DFSMSrmm Vital Record Specification
EDGSOREC - DFSMSrmm Owner Information
EDGSOVOL - DFSMSrmm Owner Information Volume List
EDGSPREC - DFSMSrmm Software Product Record
EDGSPVOL - DFSMSrmm Software Product Volume List
EDGSRREC - DFSMSrmm Library Shelf Location Record
EDGSSREC - DFSMSrmm Storage Location Shelf Location
EDGSVREC - DFSMSrmm Volume Information
These datasets are described in Appendix B, DFSMSrmm
Mapping Macros of DFSMS/MVS 1.1 Customization Guide.
This code has been syntax checked. Only the Audit record
was hand checked with a hex dump, and only subtype 'V'.
I am unsure of the time inputs in the Security record!
See Change 11.190 for DFSMSRMM Extract Record Support.
Thanks to Mike Skopec, Platinum Technology, USA
Change 11.188 %READDB2; %INCLUDE SOURCLIB(ASUMDB2A); will fail because
READDB2 READDB2 modifies the macros defined in IMACDB2, but did
Sep 28, 1993 not restore the original values for ASUMDB2A! Insert
%INCLUDE SOURCLIB(IMACDB2);
after the last %END and before the %MEND in READDB2 and
this class of problems are resolved.
Thanks to Bernard Harrison, VISA International, USA.
Change 11.187 Execution of MXG 11.06 or later under archaic SAS 6.06
CONFIG06 is no longer formally supported. However, if you are
VMXGINIT still stuck on SAS 6.06, using member CONFIG06 as your
Sep 28, 1993 CONFIG= parameter will invoke VMXGINI6 to initialize the
MXG system as best as possible. However, there appear
to be significant errors in the $EBCDIC format under SAS
6.06. If you encounter unexpected/strange characters in
the SMF DUMP HEADER message for SYSTEM=, you will need to
change all occurrences of $EBCDIC to $CHAR to be able to
execute under SAS 6.06. The real message is that MXG now
requires SAS 6.08 or later for safe and easy execution.
Note: See MXG Technical Notes in Newsletter TWENTY-FIVE.
Change 11.186 Timestamps RPTTIME,ODITIME, and ODIELAPS were missing in
VMACODS datasets ODSREPOR & ODSUSER because informat TIME6. does
Sep 27, 1993 not work with a value of 135859. However, Change 11.150
replaced all use of TIMEn with separate input of HH MM SS
and that redesign accidentally corrected this error. A
division by zero was also protected.
Thanks to Cindy Ng, Charles Schwab, USA.
Change 11.185 Invalid MDF value for BDNSKIP in Type 72 record STOPOVER.
VMAC7072 There were only 4 segments to skip, but BNDSKIP was 8.
Sep 27, 1993 Insert this trap after LOCPRDS is calculated:
IF LOCPRDS+LPARCPUS*LENPRDS GT LENGTH+1 THEN DO;
NBDPRDS+1; IF NBDPRDS LE 2 THEN
PUT '***ERROR.VMAC7072.INVALID PRDS LOCATION '
LOCPRDS= OFFPRDS= LENPRDS= BDNSKIP= LOCPRCS= I=
LENGTH= /+5 ' RECORD WAS DELETED. ' SYSTEM= SMFTIME=;
DELETE; END;
Note: The variable BNDSKIP was misspelled BDNSKIP in the
text of this change in 11.07, and in the PUT= statement,
which caused UNINITIALIZED variable BDNSKIP. Those were
corrected Sep 30, but not included in MXG 11.07.
Thanks to Tony Gennari, Harcourt Brace & Company, USA.
Change 11.184 SPIN library can fill if Change 11.060 is not installed!
VMAC30 The incorrect value of JINITIME causes the SPIN logic in
Sep 26, 1993 BUILDPDB to hold records in the SPIN library until the
SPINCNT limit in IMACSPIN is exceeded.
Thanks to Andrea Mulcahey, United Jersey Bank, USA.
Change 11.183 The LABEL for VIOREADS should have been spelled as
VMAC71 *FROM ESTORE instead of *ROM ESTORE.
Sep 26, 1993
Thanks to Helmut Kirrmaier, Comparex, GERMANY.
Change 11.182 A user's technical note about problems accounting for
ADOCWSF printed output for users of RSD's WSF product was added
Sep 26, 1993 to the ADOC for WSF. (Unfortunately, that's all there
is in that particular ADOC right now!)
Thanks to Jonathan Caldwell, Department of Veterans Affairs, USA.
Change 11.181 Support for SAP's IMS log record type 'AE'x accounts SAP
ASMIMSLG transactions under IMS. Three new data sets are created:
EXSAPIBA SAPIMSBA - Batch SAP jobs.
EXSAPION SAPIMSON - Online SAP transactions.
EXSAPISP SAPIMSSP - SAP Spool Task activity.
IMACIMS Whether you use the old TYPEIMS or new ASMIMSLG members,
VMACIMS these three SAP datasets will be created (their default
VMACIMSA destination is WORK, but you set that in member IMACIMS
Sep 25, 1993 in the _LSAPIxx macro definition). Note that since the
IMACIMS was changed, if you have tailored IMACIMS into
your USERID.SOURCLIB, you will need to compare and update
your changes starting with the new IMACIMS in this MXG.
This code has been syntax and hand checked with a dump.
Thanks to J. Cary Jones, Philip Morris, USA.
Change 11.180 Support for AICorp Central Server SMF record creates one
EXAICSCS new dataset:
IMACAICS AICSCS - AICorp Central Server resources.
TYPEAICS This code has been syntax and hand checked with a dump.
VMACAICS
Sep 25, 1993
Thanks to Bob Mattingly, ARCO, USA.
Change 11.179 Support for Concurrent Copy and Extended Sequential Data
EXTY42CC set activity in SMF type 42 subtype 4 records creates
EXTY42CV three new datasets:
EXTY42EX TYPE42CC - Concurrent Copy Job resources per controller
IMAC42 TYPE42CV - Concurrent Copy Job, detail per VOLSER.
VMAC42 TYPE42EX - Extended Sequential Dataset activity.
Sep 25, 1993
Thanks to John Maher, Home Savings of America, USA.
Change 11.178 References to Duquesne Systems was changed to LEGENT in
Several members IMACTPX,IMACSTX,IMACNSPY,IMACDMON,ANALNSPY,
Sep 25, 1993 VMACSTX, and VMACDMON. Morino Associates merged with
Duquesne Systems to create LEGENT.
Thanks to Herbert G. Strozinsky, Burlington Northern Railroad, USA.
Change 11.177 Variable SERVICE is used to determine if a TYPE72 obs
EXTY72 will be created, but IBM Information APAR II07261 says
Sep 25, 1993 SERVICE is zeroed if it overflows! So MXG now uses
IF SUM(CPUUNITS,SRBUNITS,IOUNITS,MSOUNITS) GT 0 ...
to test any of the components of service for non-zero.
Thanks to Randy Shumate, Mead Data Central, USA.
Change 11.176 Character variable STATFLG in TYPEXCOM conflicted with
VMACXCOM numeric variable STATFLG in TYPE5568. The TYPEXCOM
Sep 25, 1993 variable STATFLG is now spelled STATFLGX.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 11.175 Support for Sterling's NDM, Network Data Mover user SMF
EXNDMCT record creates four new datasets for their Release 1.4.0:
EXNDMPS NDMCT - NDM Copy Termination
EXNDMPT NDMPS - NDM Process Start Event
EXNDMWO NDMPT - NDM Process Termination Event
IMACNDM NDMWO - NDM WTO Statistics
TYPENDM This code has been syntax checked and hand checked with a
VMACNDM hex dump of all four records.
Sep 25, 1993
Thanks to Joseph L. Schwartz, CIGNA, USA.
Change 11.174 Support for Release 3.0.0 of 4th Dimension's CONTROL-D
VMACCTLD SMF record added (compatibly) CTLDJBID, the JOB ID field.
Sep 24, 1993
Thanks to Gary Cooper, 4th Dimension Software, USA.
Change 11.173 Significant enhancements of GRAFxxxx members and a change
GRAFLPAR in the basic structure of the graphics catalog that will
GRAFRMFI NOT work on releases of SAS earlier than 6.06. (The old
GRAFTMNT GRAFxxxx members that run on 6.06 and 5.18 were renamed
GRAFTRND to ZRAFxxxx and kept in the MXG Source Library).
GRAFWORK
VMXGGOPT All graphics routines now have common parameter that will
ZRAFLPAR control the construction of the graphics catalog and the
ZRAFRMFI appearance of the graphs. Each GRAFxxxx member defines a
ZRAFTMNT %MACRO of the same name as the member, and uses these
ZRAFTRND standard parameters:
ZRAFWORK
Sep 25, 1993 PDB= The DDname/LIBNAME for the source of the input
data library, and the destination library of
the output graphics catalog containing the
graphs produced. This can be a PDB or a TREND.
COMPANY= The first title line on all graphs. Defaults to
'Merrills Expanded Guide - Graphics Output', but
this parameter lets you change the title to your
company's name.
MXGRAPHS=The name of the output graphics catalog written
to the library specified by PDB=. The default
catalog name is the member=macro name, but could
be changed with this parameter.
GOUTNEW= A new parameter to re-initialize the graphics
catalog. SAS graphic procedures normally MOD
new graphs at the end of the graphics catalog.
If you reuse a PDB/TREND library, that catalog
could quickly consume the available DASD space.
MXG's default is GOUTNEW=YES, overriding SAS's
normal action and causing the catalog to be
erased before building the new graphs. Any other
value for GOUTNEW will cause the old graphs to
remain and the new to be added at the end.
The changes to the individual members are:
GRAFLPAR - New parameters added and old parameters PDBOUT
and SASGRAPH are no longer applicable (although they are
still recognized for compatibility). PDBOUT= was the old
catalog destination, now specified by PDB= parameter. The
SASGRAPH parameter was needed before it was possible to
detect if you have SAS/GRAPH (now, using the new SYSPROD
function, you no longer have to tell us what you have!).
Additionally, where bar charts are produced, plots with
area fills are used now to reduce the clutter on the
horizontal axis. This was always desired, but prior
versions of SAS did not support LEGEND processing to get
the patterns of the fill into the legend.
GRAFRMFI - New parameters added. All output is now to a
single catalog and (if only a single system is detected)
the graphs of the form VARIABLE*DATE=SYSTEM are not
produced. CLIST examples CLGRAF and CLSTRPLY are now
obsolete; using the SAS Display Manager is a much more
effective means of getting to the graphs now.
GRAFTMNT - New parameters added.
GRAFTRND - New parameters added. Parameters SASGRAPH
and SASSTAT are now obsolete. A new parameter GRAFFROM=
was added; this is the date that will be used as the
starting point of the graphs produced. Where bar charts
were produced, they have been converted to plots with
area fills. This will allow you to view more data (only
about 65 bars are possible but many years can now be
viewed on a single plot) and this reduces the clutter on
the HAXIS. The capacity lines have been smoothed by using
your IMACSHFT specification to calculate the capacity
based on the length of your shifts (previously, actual
duration of found data was used). This will eliminate
the annoying peaks and valleys caused by missing data,
outages, and incomplete weeks.
GRAFWORK - New parameters added. Parameter SASGRAPH is
obsolete. Bar charts were converted to plots with area
fills. In addition, plots of IO connect time and EXCP
counts by WORKLOAD were added. Only workloads that were
actually used (i.e., got service) are used.
VMXGGOPT - Specifies graphics options.
You should use:
%VMXGGOPT(DEVICE=xxxxxxxx);
instead of using SAS's
GOPTIONS DEVICE=xxxxxxxx command.
All devices are now supported by modifying the background
and color lists. All GRAFxxxx routines use the PCBATCH
device driver (a modified IBMPCGX driver) with background
color of black and a color list of:
WHITE,RED,GREEN,BLUE,YELLOW,CYAN,PINK
A new parameter HARDCOPY= has been added. If you specify
HARDCOPY=Y, then BLACK and WHITE are reversed.
See the SAS Technical Note in MXG Newsletter 25 about the
problems moving graphs between mainframes and other SAS
platforms; using VMXGGOPT to specify devices should help
minimize those problems.
Change 11.172 If you use WEEKBLD to create your weekly PDB on tape, it
JCLWEEKT can cause multiple tape mounts on the WEEK DD name if you
WEEKBLDT have more weekly data than will fit on one tape. The new
Sep 23, 1993 member WEEKBLDT should be used instead, as it uses the
logic described in MONTHBLD (it creates each dataset in a
temporary DASD library (DDname=TAPETEMP) in tape format,
and then writes each dataset from TAPETEMP to DDname=WEEK
using DISP=MOD so as to eliminate rewinds and remounts,
which also reduces the elapsed run time of the job.
Member JCLWEEKT has been modified to use this new member.
Note that the DDNAME of TAPETEMP must be allocated only
as big as the largest weekly dataset (usually STEPS or
CICSTRAN or DB2ACCT).
Thanks to Eric Huning, Republic Insurance, USA
Change 11.171 Zero observations in TYPE72MN for MVS/ESA 4.2 or earlier
VMAC7072 occurs because the test added by changes 11.016 was only
Sep 22, 1993 tested with MVS/ESA 4.3 data, and variable VALDSAMP only
is non-missing for 4.3. The test to create observations
in TYPE72MN only for valid intervals, located just before
the %%INCLUDE SOURCLIB(EXTY72MN... statement:
IF VALDSAMP GT 0 THEN DO;
must be changed to
IF VALDSAMP GT 0 OR VALDSAMP=. THEN DO;
Thanks to Dennis Smith, Compuware Corporation, USA.
Change 11.165 Reserved Change Number.
==Changes thru 11.164 were included in MXG PreRelease 11.06 dtd 1Sep93=
(Note in 11.06 there were two change 11.162's - the second is now 163!)
Change 11.164 Complete rewrite of GRAFRMFI. Will only run under 6.07
GRAFRMFI and later. Significantly more graphs are produced and
ZGRAFRMD more flexibility is provided. New parameters have been
Aug 31, 1993 added to allow overriding the first line of the headings
with your company name and to allow you to "clean up" old
graphics catalogs in your PDB. See the documentation in
the member. If you are still running version 5, the old
GRAFRMFI is kept in member ZGRAFRMF.
Thanks to Chuck Hopf, Primerica, USA.
Change 11.163 Support for TCP/IP 2.2.1 APAR PN40511 added new recording
VMACTCP for TCP/IP API and for FTP and Telnet clients, and now
Aug 30, 1993 uses SMF record type 118. In theory, your TCP/IP tech
sets subtype values (using the LOGGING command statement
in PROFILE TCPIP, see APAR PN40511), but both the API and
FTP/TELNET server records have the same ID and subtype!
Thus MXG does not use the subtype value, instead deducing
from other fields to determine actual data:
Dataset Contains
TYPETCPF FTP Server - existed previously in MXG
TYPETCPC FTP Client
TYPETCPT TELNET Server- existed previously in MXG
TYPETCPL TELNET Client
TYPETCPA API Calls (Sockets)
Thanks to Richard Warren, Salomon, Inc, USA.
Thanks to Bob Muller, Grumman, USA.
Change 11.162 Support for ASTEX Release 1.7 Interval Database SMF data
VMACDMON record. Variables RIRCX and RNVCCNT were added to all 3
Aug 30, 1993 DMON datasets, and variables RVDISCNH,RVLATNCY,RVMSAMPL,
RVSAMPWH and RVTLOST were added to DMONVOL. Additionally
the label for RHUSTX is now MUST PROBLEM I/O COUNT. I now
realize that I used an "H" in some variable names that
were really spelled with an "M", but the Release 1.5 doc
was a smudged fax! While having M for MUST/MAY would be
better, changing now will cause your report code to have
to be changed, and I don't intend to make extra work for
you now, so we'll live with the MXG misspellings! And
RHTCSW should be RHTCFW, but I've left it alone, too.
Release 1.7 added these new fields compatibly, so that
prior versions of MXG will not fail; they just won't have
the new variables.
Change 11.161 DB2 2.3 can have QWHSRELN=2.299 (due to truncation), so
VMACDB2 all tests GE 2.3 were changed to GT 2.2 to avoid the
VMACDB2H exposure. The specific occurrence affected only the DB2
VMAC102 correlation decoding in IMACDB2, but prudence dictated a
IMACDB2 change to all occurrences.
Aug 30, 1993
Thanks to John Shuck, SunTrust, USA.
Change 11.160 Change 10.133 (multiple type 30 records due to more than
BUILDPDB 1476 DD segments) did not correct JELAPSTM. In extensive
BUILDPD3 notes, this contributor located the several changes to
BUILD005 carry MULTIDD5 from the 30_5 into the final logic so that
IMACPDB JELAPSTM will non-missing in this instance.
Aug 30, 1993
Thanks to Andy Vick, Allied Dunbar Life Assurance, ENGLAND.
Change 11.159 Change 11.130 (NETSPY documentation error) is changed
VMACNSPY again. Now, LEGENT says the field is at offset +34 and
Aug 27, 1993 not +33 as previously documented, and so the MXG test
Previously: IF NSUBNTCN GT 0 AND NSUBNTLN GT 0 THEN DO;
Ch 11.130: IF LDLANLST GT 0 THEN DO;
Now Is: IF LDLANMAX GT 0 THEN DO;
Thanks to Gary Allen, LEGENT, ENGLAND.
Change 11.158 Variable ACTIVE in TYPE90 was renamed to ACTIVEMN because
VMAC90 it conflicted with variable ACTIVE in TYPEAPAF, which is
Aug 27, 1993 numeric. ACTIVEMN is the identity of the Active SMF data
set, and this should have minimal impact on TYPE90 users,
but avoids a conflict of variable types.
Thanks to Bryant Osborn, Department of Transportation, USA.
Change 11.157 IMS Appended Log processing of type 36 log record did not
ASMIMSLG recognize that a '04'X bit in QLDQFLGS indicates the true
Aug 27, 1993 dequeue of a transaction. (The '04'X indicates the free
of a queue-block as opposed to the '01'x which indicates
a CNT (terminal) dequeue. Find AP TYPE36CT,PAKEDONE
and insert after that line: TM QLDQFLGS,QLDQFFQB
BZ DROPMAP
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 11.156 Support for Release 4.5 of Software AG's COM-PLETE SMF
VMACCOMP record (which was incompatibly changed; MXG 11.06+ is now
Aug 24, 1993 required). New variables were added to the existing data
sets. Still in test is verification of PIB4.2 formats.
Thanks to Jill Hansen, South Dakota Regents Information Systems, USA.
Change 11.155 IMACPDB limited the number of ACCOUNTn variables to three
IMACPDB in PDB.JOBS, PDB.STEPS, and PDB.ACCOUNT, even when you
Aug 24, 1993 specified more in member IMACACCT. This was a holdover
from earlier MXG versions, and is no longer correct nor
needed. All occurrences of ACCOUNT1-ACCOUNT3 and of
LENACCT1-LENACCT3 in member IMACPDB were changed to
ACCOUNT1-ACCOUNT9 and LENACCT1-LENACCT9, and then the
number of account variables will be controlled by the
number you keep in member IMACACCT.
Thanks to Esther Ader, TRW Redi Property Data, USA.
Change 11.154 MXGTMNT abended at only one site, with a 0C4. An invalid
ASMTAPEE value for the UCBASID in the UCB Common Extension caused
Aug 24, 1993 this single error, which can be corrected by:
a.Relocate the line MVC DEVASID,UCBASID from after the
line LH R4,UCBASID to before that LH.
b.Insert after line USING ASVT,R5
these two lines: CL R4,ASVTMAXU IS ASID LARGE?
BNL NOJOB
Thanks to David Froberg, Software AG, USA.
Change 11.153 As noted in Newsletter 24, Landmark TMON pseudo type 110
VMAC110 SMF records are invalid. If you must process those TMON
Aug 24, 1993 records, you can change SUBTYPE=SMFPSSTY; to SUBTYPE=1;
and as long as ONLY Landmark type 110 records are in your
SMF file, MXG will successfully create its CICS datasets.
This is a circumvention for you to apply if you need it,
but there was no change to member VMAC110 in MXG.
Thanks to Amy Stammerjohn, IBM WSC, USA.
Change 11.152 TYPE70 dataset now supports CPUIDs of 0 thru 15, because
VMAC7072 it is possible (in PR/SM,MLPF,or MDF) to assign CPUIDs
RMFINTRV of 9 thru 15. Sites which had assigned CPUIDs above 8
Aug 23, 1993 found the wait time for those CPUIDs above 8 was lost,
causing an inflated CPU utilization percentage during
periods of low activity. Not only does this change
protect current users of high CPUID values, but also it
protects all users if/when more than 8 concurrent CPUs
are supported. Variables CAIn, CPUSERn, CPUWAITn,
CPUEDTMn, CPUPDTMn, IORATEn, PCTCPBYn, PCTTPIn,
VFAFFTMn, and VF0Nn, now exist with n values of 0,1,2,3,
4,5,6,7,8,9,A,B,C,D,E and F. (RMFINTRV was changed only
to keep CPUSER9,A-F variables).
Thanks to Ron McAllister, Hitachi Data Systems, USA.
Change 11.151 Variables DCUSYSID and DCUTMSTP were not kept in the new
VMACDCOL SMS Construct datasets DCLODC, DCOLSC, DCOLMC, DCOLBC,
Aug 23, 1993 DCOLSG, DCOLVL, DCOLAG, DCOLDR, and DCOLLB, but now are!
Thanks to John Rosza, Depository Trust Company, USA.
==Changes thru 11.150 were included in MXG PreRelease 11.05 dtd 20Aug93=
Change 11.150 MXG redesign for execution under any SAS platform began
CONFIG with this major structural change, but fortunately, as
CONFIG07 long as you use the CONFIG member from this library for
CONFIG08 your CONFIG= value, the change is transparent under the
VMXGINIT currently supported platforms. (Note that members
DOC CONFIG, CONFIG07, and CONFIG08 are now identical.)
Oct 4, 1993
Now with this change, all of MXG can be stress tested and
validated for execution under the "ASCII" versions
(WINDOWS, OS/2, UNIX). MXG's BUILDPDB has already been
executed under SAS 6.08 under Windows, OS/2, and UNIX.
The original text of this change was revised and is now
included in the Technical Note "Executing MXG and Other
SAS Applications Under Windows, OS/2, and UNIX" in MXG
Newsletter TWENTY-FIVE.
==Changes thru 11.149 were in MXG PreRelease 11.04 dated Aug 10, 1993==
Change 11.149 DOS/VSE POWER variables STARTIME and STOPTIME are okay if
TYPEDOS START and STOP occur on the STOP date, but there is no
Aug 10, 1993 START date in the record, and most DOS event records also
have no elapsed duration by which true START date can be
known, so the date of STARTIME can be incorrect. For the
DOSJOBS data, however, the elapsed time can be estimated
(CALCTM) and can be used to correct the date of start.
(Before this change, MXG wrongly recalculated STOPTIME
instead of STARTIME, causing both to be wrong when STOP
and START occurred on different dates.)
After:
CALCTM=SUM(CPUTM,OVERTM,WAITTM)/3;
Replace the two lines recalculating STOPTIME with
IF CALCTM GT TIMEPART(STOPTIME) THEN
STARTIME=DHMS(-FLOOR(CALCTM/86400),0,0,STARTIME);
Thanks to J. Geluk, ROBECO Group, THE NETHERLANDS
Change 11.148 SAP journal data for release 5 is supported in MXG 11.03.
IMACICSA For SAP release 4.3, the time part of STRTTIME is wrong,
Aug 8, 1993 because SAP 4.3 used PDTIME4. while SAP 5.0 uses PIB4.3.
Sites with release 4.3 need only to change the input
for STCTIMTR from PIB4.3 to PDTIME4. and the value of
STRTTIME will be correct; remember to back out the change
when you convert to SAP release 5.0. Unfortunately, SAP
does not store any indicator of release in the record!
Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.
Change 11.147 Support for Laser Access Corp's Optical Disk System three
EXTYODSD User SMF records. Three datasets are created:
EXTYODSR ODSDEVIC - Device Statistics. Physical activity between
EXTYODSU the ODS and the ODI.
FORMATS ODSREPOR - Report Termination. Control Unit information
IMACODS about the report just recorded.
TYPEODS ODSUSER - Report Statistics. Reflects all activity for
VMACODS that report for that user. Elapsed times
Aug 5, 1993 will be totals of all page activity while
that report was open.
Thanks to Cindy Ng, Charles Schwab, USA.
Change 11.146 Support for LEGENT's SAR product User SMF Record written
EXTYSAR by the SARSRQU3 exit, written when a report is printed
FORMATS from the SAR database. One dataset is created:
IMACSAR SARSRQU3 - SAR Print Report from SAR database.
TYPESAR
VMACSAR
Aug 4, 1993
Thanks to Bob Mattingly, ARCO, USA.
Change 11.145 ASUM70PR was still wrong in MXG 11.03; the BY statement
ASUM70PR BY SYSTEM STARTIME; (after the MERGE statement)
Aug 4, 1993 that was supposed to have been added by Change 11.041 was
lost in a later change to ASUM70PR. If you have PR/SM or
MDF or MPLF data with some MVS systems partitioned and
some native, the absence of this BY statement can corrupt
the PDB.RMFINTRV dataset. Insert it after the MERGE!
Thanks to Randy Shumate, Mead Data Central, USA.
Change 11.144 MXG CIMSTRAN dataset (from Boole's IMF) did not contain a
VMACCIMS flag variable that the transaction was a BMP, which some
Jul 29, 1993 users needed to separate BMP from MPP transactions. New
variable BMP now exists.
Thanks to Vladimiro Viano, Assicurazioni Generali, ITALY.
Change 11.143 Error OVERFLOW HAS OCCURRED, OUT OF MEMORY with ANALDB2R
ANALDB2R if reports PMSTA01 or PMSTA02 are requested, only under
Jul 27, 1993 SAS 6.08, is caused by SAS Usage Note 6719. The INCODE
arguments of PMSTA01/PMSTA02 have 330+ lines each,which
exceeds a SAS internal limit for macro argument length
as discussed in the Usage Note. Most of the 300+ lines
are "faker" statements IF A=. THEN A=.; whose purpose
was to eliminate "UNINITIALIZED VARIABLE" messages on the
log. The simple circumvention is to simply delete all of
those "faker" statements and tolerate a note on the log:
After the second INCODE, delete the first 313 lines.
After the third INCODE, delete the first 311 lines.
The permanent MXG solution is to replace the "faker"
statements with a RETAIN list-of-variables 0; statement
which takes many fewer lines. There are three INCODE
arguments, but only the last two INCODEs must be changed.
Thanks to Ken Rowe, Resolution Trust Corp, USA.
Thanks to Ivan Vasquez, Resolution Trust Corp, USA.
Change 11.142 VM/ESA duration variables that were INPUT as PIB6.6 must
VMACVMXA be stored in LENGTH 8 for the deaccumulation, otherwise
Jul 27, 1993 the subtraction of these very large numbers can cause
small truncation of values (6557.83 seconds became
6556.56 of VMDTTIME). The truncation seems to have been
the cause of small negative values of VMDCTIME as well!
These variables are now length 8:
CALMPNTR CALMPTRV CALQDNTR CALUPNTR CALUPTRV PFXPRBTM
PFXTMSYS PFXTOTWT PFXUTIME PLSVFOTM PLSVFVTM RDEVRTPD
SRMRSCTM SRMSTRD SRMTSHOT SRMTSLIC VMDESLIC VMDTTIME
VMDVFOTM VMDVFVTM VMDVTIME
Thanks to Stan Laugher, NM Computer Services, AUSTRALIA.
Change 11.141 POOL/DASD User SMF record caused INPUT STATEMENT EXCEEDED
VMACPOOL error. The INPUT of PLD $CHAR3. must be changed to
Jul 27, 1993 $CHAR4.
Thanks to Mike Lambert, IHS, USA
==Changes thru 11.140 were printed in MXG Newsletter TWENTY-FOUR 2Aug93
==Changes thru 11.140 were included in MXG PreRelease 11.03 dtd 26Jul93=
Change 11.140 The Asynchronous Data Mover Facility APAR OY65142 adds to
IMACPDB the type 30 SMF record variables ADMFREAD,ADMFWRIT with
VMAC30 count of pages moved by ADMF. Both variables were also
Jul 24, 1993 added to the PDB.JOBS and PDB.STEPS datasets.
Change 11.139 A RACF segment with zero length RACFDLN was not expected
VMAC80A nor protected for, causing INPUT STATEMENT EXCEEDED ...
Jul 24, 1993 error. Change SELECT (RACFTYPE); to read
IF RACFDLN GT 0 THEN SELECT (RACFTYPE);
Thanks to Jeff Burnett, Anixter Information Services, USA.
Change 11.138 Additional protection for changes in Journal records is
VMAC110 accomplished by inserting INPUT @LOC @; after both of
Jul 23, 1993 the occurrences of LOC=LOC+JCRLL; In particular, this
will permit MXG to skip over SAP Journal records until
you install the MXG 11.03 needed for SAS Release 5.0!
Thanks to Thomas Lowin, GESIS, GERMANY.
Change 11.137 An extraneous close-parenthesis on line 011800 (after the
VMACZRB _LZRBUWP statement) must be deleted.
Jul 23, 1993
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 11.136 Major revision to the subtype 102/103 Omegamon/CICS User
VMACOMCI SMF record (Clocks and Counters for VSAM, DL/I, IDMS,
Jul 22, 1993 ADABAS, SUPRA, and DATACOM) in Candle's SPE QOC0553. Now,
two MXG datasets are created for each DB manager, one
with total I/O activity, and one with detail activity at
the "File/Database" level. Candle's misdocumentation of
the VSAM record pre-SPE was also corrected, as were MXG
errors in inputting as PIB4.4 what was PIB4.6! Datasets:
OMCIVSAM,OMCIVSAT - VSAM Detail, Total
OMCIADA ,OMCIATAT - ADABAS Detail, Total
OMCIDLI ,OMCIDLIT - DL/I Detail, Total
OMCIIDMS,OMCIIDMT - IDMS Detail, Total
OMCISUPR,OMCISUPT - SUPRA Detail, Total
OMCIDTCO,OMCIDTCT - DATACOM Detail, Total
Thanks to Thomas Lowin, GESIS, GERMANY.
Thanks to Ross Pover, Immigration & Ethnic Affairs, AUSTRALIA.
Change 11.135 The _K macro name for the _LTY80CM dataset was misspelled
VMAC80A as _KTY8007 instead of _KDY80CM.
Jul 22, 1993
Thanks to Thomas Lowin, GESIS, GERMANY.
Change 11.134 MXG 11.02 only. Changes 11.113 and 11.089 were not in
TYPEVM the code, although both were documented as being there.
VMAC26J2 Labels were missing for CHANIND,CHANINDY,CHANINDY vars in
VMAC73 TYPE73 dataset.
Jul 22, 1993
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 11.133 STOPX37 undocumented fields VOLSER and MSGCODE were found
VMACX37 by this user. Add: @441+OFFSMF VOLSER $CHAR6.
Jul 22, 1993 @497+OFFSMF MSGCODE $CHAR7.
and add MSGCODE to KEEP= list.
Thanks to Lou Sassani, National Australian Bank, AUSTRALIA
Thanks to John Astle, National Australian Bank, AUSTRALIA
Change 11.132 MXG 11.02 only. Change 11.119 was incomplete. Insert:
VMAC37 BRFDATLN=LENDETT;
Jul 22, 1993 after INPUT @OFFDETT @;
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Change 11.131 HSM BCDS dataset MCB records were incorrect (incomplete
VMXGHSM and too few observations, plus INVALID ARGUMENT TO FUNCT
Jul 22, 1993 DATEJUL message). Line 114200 should be P2=P2+64; vice
P2=P2+(I*64); In addition, lines 113500 & 113800-114100
were relocated above the DO loop.
Thanks to Willi Weinberger, Gothaer Versicherungsbank, GERMANY.
Change 11.130 Legent LANSPY Problem # DGL249 acknowledges documentation
VMACNSPY error for extended subtype D record that caused INPUT
Jul 22, 1993 STATEMENT EXCEEDED RECORD LENGTH. The MXG test:
IF NSUBNTCN GT 0 AND NSUBNTLN GT 0 THEN DO;
must be replaced with IF LDLANLST GT 0 THEN DO;
Thanks to Mike Hicks, Centrefile Ltd., ENGLAND.
Change 11.129 SAS Error 76-322 occurred when unnumbered and numbered
CONFIG07 statements were input, and CONFIG07 used.SAS Option S2=0
Jul 22, 1993 should have been S2=72 in CONFIG07. (CONFIG08 was okay.)
See Change 10.109 for discussion.
Thanks to Ann Wheeler, American President Lines, USA.
Change 11.128 Variable DEVTYPE was added to the KEEP= list for dataset
TYPETMS5 TMS.DSNBRECD so that the type of tape device is known.
Jul 22, 1993
Thanks to Chuck Hopf, Primerica, USA.
Change 11.127 In MXG 11.02. an extraneous period in column 1 of line
ASUM70PR 031200 must be removed. Additionally, in some instances,
Jul 21, 1993 the new LPnDUR variables were missing because of sort
reordering. To correct, LPARNUM was added to the BY
statement following INCODE= and FIRST.STARTIME was
changed to FIRST.LPARNUM.
==Changes thru 11.126 were included in MXG PreRelease 11.02 dtd 6Jul93=
Change 11.126 Type 30 APPC variables were accumulated across steps, and
VMAC30 a second step (PGM=IEFBR14) that did not use APPC would
Jul 2, 1993 contain non-zero APPC counts if the first step used APPC!
APAR OY63634 now creates an additional segment in type 30
records which contains the "Delta" values for the step.
MXG supports the new APAR, and will use the Delta segment
if it exists; otherwise, the cumulative values will be
kept (as occurs now) until you install the APAR.
Change 11.125 RMF-like reports from MXG datasets were enhanced with the
ANALRMFR EMIF channel reporting of both total Channel Busy and the
Jul 2, 1993 Partitions part of total Channel Busy. All reports now
match their RMF 4.3 counterparts.
Change 11.124 Variable LSBACS (ACS ID) was added to the STCLMU dataset:
VMACSTC Replace the line INPUT @21+OFFSMF LSBMON PIB2.
Jul 1, 1993 With these two: INPUT @543+OFFSMF LSBACS PIB1.
Oct 21, 1993 @21+OFFSMF LSBMON PIB2.
(The above text was reworded for clarity from that that
was published in Newsletter TWENTY-FOUR, Oct 21, 1993.)
Also, Change 10.116 was not implemented correctly. After
that change, the code should read:
ELSE INPUT STC07CON PIB4. @;
INPUT STC07LBL $CHAR1. ...
Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY.
Thanks to Tom Yarbrough, Rockwell Space Operations Company, USA.
Change 11.123 The order of INPUT statements was modified to make all
VMAC64 TYPE64 variables available to the TYPE64X (extent) data
Jul 1, 1993 set, so that you could optionally add desired variables
into TYPE64X (using _KTY64X macro in member IMAC64).
Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY.
Change 11.122 Variables IVLAWS and IVLOAWS were added to OPC24_6, and
VMACOPC variables MTDRESTA,MTDDIRES,MTDRERUT, and MTDDIRER were
Jul 1, 1993 added to OPC24D_C data sets. This change supplements
Change 11.065.
Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY.
Change 11.121 Variable AOUTSZT was not calculated in NSPYLU data set.
VMACNSPY Insert after ARSPNET calculation (line 123700):
Jul 1, 1993 AOUTSZT=COTPUTSZ/NETRSPNO;
and then after ARSPNET=.; (line 126700), insert:
AOUTSZT=.;
Thanks to Joanne Turpie, Department of Labour, NEW ZEALAND.
Change 11.120 Variable QW0058SN was incorrectly input as $CHAR2,
VMAC102 instead of PIB2., so it was unprintable. Changing to the
Jun 29, 1993 PIB2. will cause the actual statement number to print.
Thanks to Dave Leeker, Southwestern Bell, USA.
Change 11.119 Netview Type 37 "INPUT STATEMENT EXCEEDED RECORD LENGTH"
VMAC37 occurs because APAR OY49717 incorrectly documented the
Jun 24, 1993 format of the "DETT" (Data Network Subfield) text. The
APAR documented an imbedded count of sections BRFDENUM
and an imbedded length of each section, BRFDATLN, yet the
actual data contains neither field; instead, the triplet
LENDETT/NRDETT fields describe the text directly. The
workaround is to insert BRFDENUM=NRDETT; after the
INPUT statement for BRFDENUM, and to insert
BRFDATLN=LENDETT; INPUT @OFFDETT @;
after the INPUT statement for BRFDATLN. The actual MXG
revision eliminates the excess code.
Thanks to Larry Doub, RJReynolds Tobacco Co., USA
Change 11.118 The number of LPAR partitions, NRPRCS, was put back in
ASUM70PR the ASUM70PR data set from TYPE70PR. It had been removed
Jun 24, 1993 by Change 11.003 but turns out useful, so it can now be
Aug 4, 1993 used in reports.
Change 11.117 Support for Top Secret Release 4.3 type 80 SMF record.
VMAC80 Find the test for RACFVRSN following text "Top Secret"
VMAC80A and add OR RACFVRSN=043X to that test in both members
Jun 24, 1993 VMAC80 and VMAC80A to support this release.
Thanks to David Froberg, Software AG, USA.
Change 11.116 APAR OY54370 to NPM allows the Network Transit Time to be
VMAC28 calculated with only user data PIUs that have Definite
Jun 24, 1993 Response (specify TRANSIT=DR in FNMINIT), or now the Time
can include the data flow control PIUs (TRANSIT=DFC).
New MXG variable DFCPIU='Y' if TRANSIT=DFC was specified.
Thanks to Joseph L. Schwartz, CIGNA, USA.
Change 11.115 OMEGAMON V550 User SMF record ("ESRA") fails with INPUT
VMACOMCI STATEMENT EXCEEDED RECORD LENGTH due to MXG logic error.
Jun 24, 1993 Replace @LOC+LENTOTR+1 with @LOC+LENTOTR+1+(-6*(_I_-1))
to correct the alignment.
Thanks to Richard Cooke, Zurich Municipal, ENGLAND.
Thanks to Pete Gain, SAS Institute, ENGLAND.
Change 11.114 APAR OY64585 changes the format of IODFDATE in both type
VMAC73 73 and 74 records to MMDDYY8. (instead of YYMMDD8.), so
VMAC74 both INPUTs were corrected. Variables CYCLE and PARTISHN
Jun 23, 1993 are now kept in TYPE73, and new variable PNCHANBY is now
created in EMIF environments to report the Partition's
use of this CHPID. (PCHANBY is Total CHPID busy, while
PNCHANBY is the Partition's CHPID busy.)
Change 11.113 Support for VM/ESA Release 2.1 Accounting records added
TYPEVM type 0B accounting record for virtual disk in storage,
Jun 23, 1993 which MXG now outputs into dataset VMDEVICE. Variables
VDISKSUB and PAGEUSED in dataset VMDEVICE are non-missing
only for VMID='0B'X virtual disk record.
Change 11.112 Support for VM/ESA Release 2.1 Monitor MONWRITE records
VMACVMXA added several new variables, mostly for virtual disk in
Jun 23, 1993 storage statistics:
VXSYTSHS - QDGSYSLM,QDGUSRLM,QDGSYSCA,QDGLKCNT,QDGDISKS
(size, number, limits on VDISKs). Existing
variable VMSFORE converted to bytes and now
Formatted MGBYTES.
VXUSELOF - New variable VMDVDISK.
VXUSEACT - New variable VMDVDISK.
VXUSEATE - New variable VMDVDISK.
VXIODDEV - New variables VIUSTAMP, VIUSTATE.
(for I/O assist utilization calculations)
Variables now reserved (i.e., have zero value):
VXSTORSP - PLSTRMWT,PLSTRECT,PLSTEFCT,PLSTRDCT,PLSTDFCT,
PLSSYS1 ,PLSSYSE ,PLSSYSP1,PLSSYSPE
New data sets:
VXSTOSHL - 3.15 - NSS/DCSS/SSP Loaded into Storage
VXSTOSHD - 3.16 - NSS/DCSS/SSP Removed from Storage
VXSTOVDK - 3.17 - VDISK Information
Thanks IBM: both data and documentation were provided
for validation!
Change 11.111 VM/ESA dataset VXSYTCPM had incorrect values (DURATM=0,
VMACVMXA PCTCHBSY=wrong), or could ABEND with STOPOVER condition.
Jun 23, 1993 In _CSYTCPM, the ... THEN DO CHPID=0 TO CHPATH; must be
... TO CHPATH-1; Also, SKIP=SKIP-CHPATHLN; must be
replaced with IF SKIP GT 0 THEN INPUT +SKIP @;
Also, after M1=-1; insert SKIP=CHPATHLN-8;
Then in _DSYTCPM, CHPTSTMP+128*4294967296/1E6; must be
changed to CHPTSTMP+128*16777216/1E6 (because CHPTSTMP
is only 3-bytes. Before IF FIRST.BEGINMTR ..., insert
SAMECHAN=DIF(CHPID); DROP SAMECHAN; and add to the
IF FIRST.BEGINMTR OR ... a clauseOR SAMECHAN NE 0 .
Finally, after the END; of DO CHPID=0 TO CHPATH-1; and
before the final END; insert:
SPIN=MRHDRLEN-CALOFFST-CHPATH*CHPATHLN;
IF SKIP GT 0 THEN DO; INPUT +SKIP @; SKIP=0; END;
Thanks to Tom Healy, CHEMNET, USA.
Change 11.110 Support for SAP Releases 4.3.J & 5.0, which incompatibly
FORMATS changed the SAP CICS Journal segment in type 110 records.
IMACICSA Thirty-four new variables are created in the CICSSAP data
VMAC110 set and kept in VMAC110, and format $MGSAPTY was altered
Jun 22, 1993 because STCTASK now contains only a single character.
Note that variables STCIAPPL,STCIDEST,STCIDTYP,STCIMAND,
STCIMODP,and STCIPROG only have value if STC1CPIC='Y',
i.e., for CPIC Communication.
Thanks to Hr. Baehr, Helaba, GERMANY
Change 11.109 MXG 10.10 "Appended" IMS processing members JCLIMSLG and
JCLIMSLG TYPEIMSB were overlaid unexpectedly, and members IMSALOG,
TYPEIMSB IMSFPLOG,IMSTLOG,VIEWS,SUMTAB, and ASMIMSL3 were created
TYPESLRI unexpectedly when the MXG 10.10 tape was unloaded. These
Jun 22, 1993 eight members were supposed to be contained in new member
TYPESLRI as an unloaded IEBUPDTE PDS, but my error was to
fail to change the ./ IEBUPDTE syntax to xy, and thus the
8 members were created in your MXG.SOURCLIB. If you will
delete the last line in TYPEIMSB (a /* in col 1-2), and
ask us to fax you the MXG JCLIMSLG example (116 lines),
you can used the "Appended" IMS processing announced in
Change 10.142. Member TYPESLRI was described in Change
10.290, and now contains xy instead of ./ so that it will
not unload and overlay members again.
Thanks to Kenneth D. Jones, SHL SystemHouse, CANADA.
Change 11.108 DB2 variables CORRNAME and CORRNUM were not decoded for
IMACDB2 IMS connections with QWHCATYP=10. Now, the _DB2CORR IBM
Jun 22, 1993 macro tests for values of 5, 6, 9, or 10 for IMS.
Thanks to Alan Keeble, British Steel, ENGLAND.
Change 11.107 DB2 Trace IFCID=53 and IFCID=58 records can have no data
VMAC102 sections (QWHSNSDA=2 found for CLOSE CURSOR for example),
Jun 22, 1993 but this was not documented by IBM nor expected by MXG,
and those records with QWHSNSDA=2 were not output in
T102S053 or T102S058 data sets. Insert the ELSE OUTPUT
T102S05x; statements as shown:
Change To Read:
OUTPUT T102S053; OUTPUT T102S053;
END; END;
ELSE OUTPUT T102S053;
OUTPUT T102S058; OUTPUT T102S058;
END; END;
ELSE OUTPUT T102S058;
Thanks to John Morgan, Compuzorg B.V., NETHERLANDS.
Change 11.106 Support for DOS/VSE POWER 5.1 has been added. In datasets
TYPEDOS DOSJOBS and DOSREAD, variable TORMOT is now reserved, and
Jun 21, 1993 in DOSSNA variable INVLRESP is now reserved. DOS Network
Account field (8-bytes) was added to DOSLIST, DOSPUNCH,
DOSREAD, DOSXRC, and DOSPOOL, and records inserted or
deleted by OUTEXIT variables were also added in DOSPUNCH,
DOSLIST,DOSXRC, and DOSPOOL datasets. The Execution 'E'
record now documents offsets to either a PUTACCT user
extension or a "VSE/POWER extension area from ACDATE",
I have been unable to find the IBM documentation for that
area. The enhancement code has only been syntax checked.
Thanks to Jean-Claude Burger, Boehringer Ingelheim, FRANCE.
Change 11.105 Cosmetic. The list of members that use %VMXGFOR was out
VMXGFOR of data; now all 95 members are listed in the comments.
Jun 20, 1993
Thanks to Bob Butchco, The Genix Group, USA.
Change 11.104 "VARIABLE SACCT1 NOT FOUND" will result if you DROP all
IMACACCT of the SACCTn variables; BUILDPDB demands that at least
Jun 14, 1993 ACCOUNT1 and SACCT1 exist. You can set the length of
SACCT1 (and ACCOUNT1, if desired) to be one byte and
then DROP SACCT2-SACCT9 ACCOUNT2-ACCOUNT9 if you really
want to minimize the accounting variables that you keep.
Change 11.103 TYPEVVDS can have blank VVRSTGCL, VVRDATCL, or VVRMGTCL
VMACVVDS (Storage, Data, or Management Class) values, because the
Jun 14, 1993 test IF VVRLEN GE 148 ... should have been written as
IF VVRLEN GE 135 ...
Note, however, that there are legitimate TYPEVVDS records
that will still have blank values: Alternate Indexes do
not contain SMS classes, nor will datasets not under SMS!
Thanks to Scott Ashby, First Wachovia Operational Services, USA.
Change 11.102 MXG 11.01 only. Dataset TYPE73 has observations only for
VMAC73 MVS/ESA 4.3 or MVS/ESA 4.2 with APAR OY45991/PTF UY77343
Jun 11, 1993 installed. Change 11.015 was the culprit; VALIDPTH only
exists with the APAR or 4.3. Replace the single line:
IF VALIDPTH='Y' THEN DO;
with these lines:
IF (CFGCHGFL='....1...'B AND VALIDPTH='Y') OR
(CFGCHGFL='....0...'B AND (CHANIND GT 0 OR CHANINDX GT 0 OR
CHANINDY GT 0 OR PCHANBY GT 0 OR
SMF73PBY GT 0 OR SMF73PTI GT 0))
THEN DO;
Thanks to Rich Hawthorne, Nike, USA.
Change 11.101 The MXG Tape Mount Monitor is now the MXG Tape Mount and
ASMTAPES Allocation Monitor. The monitor now creates a subtype 4
EXTMNALO SMF record for each deallocation of a tape drive, with
IMACTMNT the start and end timestamps of how long that drive was
VMACTMNT allocated to that job, so that (finally!) the duration of
Jun 8, 1993 tape drive allocation can be measured, even if dynamic
allocation (eg. HSM, DB2MAST) or dynamic deallocation
(eg., FREE=CLOSE) is used. New MXG dataset TYPETALO is
now created by VMACTMNT (and also by BUILDPDB/3) for each
subtype 4 MXGTMNT record.
The ASM source code for the revised MXGTMNT program is in
ASMTAPES, and installation instructions are in comments;
except for Authorization, it installs exactly as the old
ASMTMNT. Yes, there is a price for this new priceless
data record: the new MXGTMNT load module must now always
be Authorized and stored in an Authorized Library, even
for testing to a flat file. Comments in ASMTAPES discuss
why Authorization is needed.
The allocation monitor was specified by Barry, but the
coding implementation was done for Merrill Consultants
by Bill Fairchild, Royal Software Associates. Chuck Hopf
did a lot of the early testing.
A minor enhancement was also made to the tape mount
monitor: the type of label (SL, NL, NSL, BLP) has been
added to the record and new variable LABEL is added to
TYPETMNT observations.
ORIGINAL TEXT OF CHANGE 11.101:
THIS MONITOR IS STILL IN ALPHA TESTING; IT CREATES VALID
RECORDS, BUT THEN ABENDS WITH AN 0C1, AND WE ARE STILL
DEBUGGING THE NEW MONITOR. DO NOT USE THIS NEW MONITOR!
Text revised Mar 24, 1994, after newsletter TWENTY-FIVE:
See Change 11.357.
Change 11.100 Line 051600 should be INPUT @109+OFFIMS instead of only
VMACCIMS INPUT @109; fortunately, OFFIMS is zero, so there was no
Jun 8, 1993 execution error.
Thanks to Vladimiro Vieno, Assicurazioni Generali, ITALY.
Change 11.099 MXG 11.01 only. A semicolon was missing after MTFLAG=0;
TYPEIMSA
Jun 8, 1993
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 11.098 The DD name //DASDCOLL in this JCL example should have
JCLDAYDS been //DATASETS, as expected by the (DAILYDSN) program.
Jun 8, 1993
Thanks to David Ehresman, University of Louisville, USA.
Change 11.097 Amdahl format MGAMDDT mapped values 7,8,9 to 6380M1,M2,M3
FORMATS but they should be 6390M1,M2,M3, and have been changed.
Jun 3, 1993
Thanks to Graham West, Amdahl, ENGLAND.
Change 11.096 MXG 11.01 only. Insert an @; immediately before the
VMACDCOL IF LENGTH GE 308 THEN ... statement.
Jun 3, 1993
Thanks to Gary Matney, Twentieth Century Investors, USA.
Change 11.095 Variable STARTIME was added to the KEEP= list for the
VMACTMVS datasets TMVSYSSW and TMVSIV.
Jun 2, 1993
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Change 11.094 Several MXG 11.01-only typographical errors:
ASUM70PR ASUM70PR variable LPCTGOV is LABELed twice; delete the
GRAFLPAR second occurrence.
VMXGPRAL GRAFLPAR line 041300 has a missing quote; it should read:
Jun 2, 1993 TITLE2 H=2 F=SWISS 'LPAR % CPU Utilization';
VMXGPRAL utility prints only the first dataset found, and
prints it once for each dataset in the library! These
changes are required, but they also make this utility
work only with SAS Version 6 or later:
Insert COMPRESS=NO after NOBS in the KEEP= list following
the OUT=CONTENTS.
Insert (COMPRESS=NO) after OUT=DATASETS and before NODUP
in the PROC SORT statement.
After DATA _NULL; insert POINT=&I;
Add POINT=POINT to the SET DATASETS statement.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 11.093 0C4 ABEND in SASXKERN occurs if you have the IBM supplied
JCLTEST6 blocksize exit IFGOEXOB installed. The //SMFOUT DD in
Jun 2, 1993 JCLTEST6 does not contain a DCB specification, so the
exit picks one, but it conflicts with the BLKSIZE=23440
in the FILE statement in the SMFSMALL program! Adding
DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=23440)
to the //SMFOUT DD avoids this possible abend.
Thanks to John Visser, Delta Motor Corporation, SOUTH AFRICA.
Change 11.092 Omegamon 2.60 Audit Record moved the 8-byte OMSUBSID name
VMACOMAU (specifically, the DB2 subsystem name) to the existing
Jun 1, 1993 reserved OMRSV4 field, but only the first four bytes are
used! Change OMRSV4 $CHAR8. to OMRSVR $CHAR4. +4
and then after the final @;, insert
IF OMSUBSID='0000000000000000'X THEN OMSUBSID=OMRSV4;
Thanks to Wayne Cope, Belk Stores, USA.
Change 11.091 Variable MESSAGE was not decoded in STOPX37 Release 3.5
VMACX37 (because it is not described in their DSECT), but it is
May 28, 1993 located, and @505+OFFSMF MESSAGE $CHAR140. should
be added to the INPUT for Release 3.5.
Thanks to Bob Guthier, Lucky Stores, USA.
Change 11.090 Although ASMVTOC/VMXGVTOF are strongly recommended rather
FMXGUCBL that this archaic FMXGUCBL, sites under MVS/ESA 4.2 will
May 28, 1993 encounter an 0C2 ABEND OUTSIDE THE SAS SYSTEM (because it
required to be Authorized). Rather than putting SAS in
an Authorized Library, the following changes will correct
FMXGUCBL so that it does not require authorization, in
case you are still using this Archaic member.
1. Locate label MVS42AAA DS 0H, and move this line to
after L R2,UCBADDR
2. Locate label MVS42AAB, and change these arguments of
the UCBSCAN macro: Change ADDRESS, to COPY, Replace
UCBPTR=UCBADDR, with UCBAREA=UCBCOPY, Remove NOPIN,
After all of the arguments to the UCBSCAN macro,
and before the L R15,UCBSCNRT, insert
LA R2,UCBCOPY
3. Locate UCBSCNRT DS F, and insert after that line
UCBCOPY DC XL48'00'
4. In the JCL, change C. to ASM. and L. to LKED. and
add a comma after the PARM.ASM field, and remove the
extraneous comma after the PARM.LKED field.
Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.
Change 11.089 In BUILDPDB, real purge records can go to PDB.NJEPURGE
VMAC26J2 instead of being recognized as real purge records. This
May 26, 1993 can cause jobs to be held in the SPIN library instead of
being output in PDB.JOBS, and when SPINCNT is exceeded
and these jobs are finally written to PDB.JOBS, they will
have ABEND='NOTP' (i.e. did not find a Purge record).
The error was created when IBM replaced PRPRTY with a new
field (SMF26IX2) in ESA 4.3, but when MXG decoded the new
variables DUPJBDLY and OFFLPURG, I failed to decode only
for 4.3+. Variable OFFLPURG is used in BUILDPDB logic to
recognize purge records created by JES2 SPOOL Transfer,
but if the PRPRTY happened to be 4-7 or 12-15, MXG set
OFFLPURG='Y' in VMAC26J2, and then in BUILDPDB that purge
record went to PDB.NJEPURGE! The MXG correction is
to only create DUPJBDLY/OFFLPURG if this is an
MVS/ESA 4.3 record (and, of course, JES2 does not put any
record level indicator in their record, so the only way
to recognize that this is a 4.3 record is to test for the
existence of the accounting triplet that was also added
by 4.3!). In VMAC26J2, add the IF ... DO; and END;
statements as shown:
IF NETFLAG='.......1'B THEN DO;
IF PRPRTY='1.......'B THEN DUPJBDLY='Y';
IF PRPRTY='.1......'B THEN OFFLPURG='Y';
END;
Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.
Change 11.088 In line 4800, :"0. Check if the summary table already
TYPESLRI exists;" - the semicolon must be changed to a period, to
May 26, 1993 prevent a syntax error.
Thanks to Steen Pedersen, Danfoss. DENMARK.
Change 11.087 The calculation of LP0MGTTM=LP1UPDTM-LP1UEDTM should have
ASUM70PR obviously been LP0MGTTM=LP0UPDTM-LP0UEDTM, and the
May 24, 1993 variable LP0MGTTM needs to be added to the RETAIN list.
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.086 Variables F20STRT and F20DURA are now FORMATted TIME12.2.
VMACILKA
May 24, 1993
Thanks to Gary Strohminger, AT&T Transtec, USA.
Change 11.085 DB2 Trace dataset T102S145 (Audit Trace) variables
VMAC102 QW0145SC and QW0145LL were not input under DB2 2.3 due to
May 24, 1993 incorrect INPUT logic. Insert an "@;" after the input
of QW0145HO $CHAR4. and insert an "INPUT" before QW0145SC
so the logic ends up looking like this:
IF QWHSRELN GE 2.3 THEN INPUT
QW0145HO $CHAR8. /*HOST OPTIONS*FOR SQL*/
@;
ELSE INPUT
QW0145HO $CHAR4. /*HOST*OPTIONS*/
@;
INPUT QW0145SC $CHAR4. /*SQL*RETURN*CODE*/
QW0145LL PIB2. /*SQL*STATEMENT*LENGTH*/
@;
Thanks to Wilson Kwong, National Australia Bank, AUSTRALIA.
=====Changes thru 11.084 were in MXG PreRelease 11.01, May 20, 1993=====
Change 11.084 ANALNPMR produced only the first report requested when
ANALNPMR PDB=SMF was specified; the same name was used for both
May 19, 1993 input and output, causing no data to be found for the
second and subsequent reports.
Thanks to Victor Chacon, NYNEX Mobil Communications Co., USA.
Change 11.083 Landmark CICS data under DOS/VSE was previously processed
TYPEMOND by MXG member TYPEMOND, but only for Landmark Version 7.
TYPEMONX That archaic member was copied to create TYPEMONX (just
May 19, 1993 in case someone still has Version 7 under DOS/VSE), and
TYPEMOND was completely revised to (hopefully) support
Landmark Versions 8, 9, and 1.0 under DOS/VSE. However,
no test data nor hex dump of a Version 8 record from DOS
was available, so this support has only been syntaxed.
Change 11.082 CICS/ESA journal data produced by the SAP product was not
VMAC110 coded exactly the same as CICS/non-ESA, although the end
May 19, 1993 results were the same. Now, the code segment for both
CICS/ESA and CICS/non-ESA uses the same logic.
Thanks to Isabelle Mejane, SAS Institute, FRANCE.
Change 11.081 DIVIDE BY ZERO error occurs if GEICPUOL is zero. Replace
VMACZRB PCTCPUBY=100*(INTERVAL-(CPUWAIT/GEICPUOL))/INTERVAL;
May 19, 1993 with
IF GEICPUOL GT 0 THEN
PCTCPUBY=100*(INTERVAL-(CPUWAIT/GEICPUOL))/INTERVAL;
ELSE PCTCPUBY=.;
Thanks to Marcel Frechette, Montreal Trust Technology, CANADA
Change 11.080 STARTIME and CPUTCBTM in all CICS/ESA Statistics datasets
VMAC110 (eg., CICINTRV, CICEODRV, CICDS, etc.) are wrong. This
May 19, 1993 error did NOT affect the CICSTRAN dataset.
a.The STARTIME was set to COLLTIME, which is the END of
interval and not the START. Find these lines
COLLTIME=DHMS(SMFSTDAT,CLTHH,CLTMM,CLTSS);
STARTIME=COLLTIME;
IF 0 LE DURHH LE 24 AND 0 LE DURMM LE 59 AND
0 LE DURSS LE 59 AND
SMFSTRQT='INT' THEN DURATM=HMS(DURHH,DURMM,DURSS);
and change them to read:
COLLTIME=DHMS(SMFSTDAT,CLTHH,CLTMM,CLTSS);
IF 0 LE DURHH LE 24 AND 0 LE DURMM LE 59 AND
0 LE DURSS LE 59 AND
SMFSTRQT='INT' THEN DURATM=HMS(DURHH,DURMM,DURSS);
STARTIME=COLLTIME-SUM(0,DURATM);
b.The CPUTCBTM was correct in CICS 3.1.1, because DSGTCT
did contain total TCB time for each TCB, but beginning in
CICS 3.2, IBM reused field name DSGTCT for the DS-Only
TCB time and put the Total TCB time in new variable
DSGACT, but I failed to change the CPUTCBTM equation.
Find the line:
CPUTCBTM=SUM(DSGTCT,DS2TCT,DS3TCT,DS4TCT);
and replace that equation with:
CPUTCBTM=SUM(DSGACT,DS2ACT,DS3ACT,DS4ACT);
c.Also variables DSnTCBFm are now formatted $HEX2., and the
test for DSGNTCB GE 3 was changed to DSGNTCB GE 4, since
CICS 3.3 can have four TCBs.
Thanks to Scott Pearson, King County Medical Blue Shield, USA.
Change 11.079 SAS 6.08 Usage Note 6719 discusses a SAS error in %MACRO
GRAFLPAR compiler which causes GRAFLPAR to fail with an "OUT OF
May 19, 1993 MEMORY" condition (which is NOT the error!). Apparently,
GRAFLPAR broke an internal limit on characters passed as
%MACRO arguments (and blanks at the end of argument lines
are being counted!). We have been able to circumvent the
ABEND by reducing the number of characterspassed by MXG
by reducing four lines of code with two. In three places
find the four lines beginning with
lparnum=lparnum+1;
and move the 2nd and 4th lines to the end of 1st and 3rd!
SAS Institute is still working on a ZAP; the above Usage
Note will be updated when a ZAP exists.
Thanks to Chuck Hopf, Primerica, USA.
Change 11.078 New HSM dataset HSMFSRBO contains both tape and disk data
DIFFHSM set statistics, with several new variables, based on this
EXHSMFSB user contribution. Additionally, VSRTOTKB is now input
IMACHSM as PIB4. instead of PIB2. This change altered IMACHSM,
VMACHSM if you have tailored IMACHSM in your USERID.SOURCLIB, you
May 19, 1993 must retrofit your changes using this new IMACHSM.
Thanks to Neil Campbell, Inland Revenue, ENGLAND.
Change 11.077 The HSMVSRFU dataset previously was OUTPUT only if two of
EXHSMVSF the data variables were non-zero, but now these variables
May 18, 1993 are tested for the OUTPUT DO group:
IF VSRNTRKR GT 0 OR VSRNTRKW GT 0 OR VSRNDSV GT 0 OR VSRNBYTR GT 0
OR VSRNBYTW GT 0 OR VSRNDSF GT 0 OR VSRNVOL GT 0 OR VSRNSYS GT 0
OR VSRTAGE GT 0 OR VSRTTINQ GT 0 OR VSRTTINP GT 0 OR VSRTTWV GT 0
OR VSRTCPU GT 0 THEN DO;
Thanks to Neil Campbell, Inland Revenue, ENGLAND.
Change 11.076 Lines 001100 thru 001700, the OUT= data set name DCOLMIGS
DAILYDSN was repeated, but it should be the same data set name as
May 18, 1993 the DATA= parameter on the same line.
Thanks to Ian Jones, The Equitable Life Assurance Society, ENGLAND.
Change 11.075 Lines 006300 and 006600 both contain DATA=TYPEVVDS, but
ANALVVDS that should have been DATA=_LTYVVDS in both lines, to be
May 18, 1993 consistent with the new _L macro naming conventions.
Thanks to Ian Jones, The Equitable Life Assurance Society, ENGLAND.
Change 11.074 The new member CHANGESS now contains ALL changes from ALL
ChangeSS MXG Versions, which should make online browse a little
May 15, 1993 easier. Current Changes are still in member CHANGES.
Change 11.073 Boole's IMF MSC Arrival Time was mis-documented. The
VMACCIMS three lines reading:
May 15, 1993
@216+OFFIMS TH PK1.
@;
SEC=SEC+(TH/100);
must be changed to read:
@216+OFFIMS TH ?? PD1.
@;
SEC=SEC+(TH/10);
Thanks to Silvio Orsini, Banca d'Italia, ITALY.
Thanks to Vladimiro Viseno, Assicurazioni Generali, ITALY.
Change 11.072 The code to set MULTRANS='Y' set NMSGPROC=1 only for the
TYPEIMSA first transaction in the group. The code was relocated
May 15, 1993 and a retained flag used to correctly reset NMSGPROC.
Thanks to Lonnie T. Rimmer, Philip Morris, USA.
Change 11.071 Candle's ITRF (a part of Omegamon/IMS Version 110) data
VMACITRF records EVENTIME was incorrect.
May 15, 1993
Change 11.070 STOPX37 Release 3.5 data records do not agree with the
VMACX37 DSECTS provided by EMPACT. Undocumented bytes caused
May 15, 1993 INVALID value for JINITIME. Many lines were changed.
Thanks to Dave Redinger, General Electric Plastics, USA.
Change 11.069 Continued enhancement of RMF look-a-like reports from MXG
ANALRMFR corrected several syntax errors and added additional
FORMATS reports, and formerly temporary formats are now built by
May 19, 1993 new PICTUREs in member FORMATS.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
=Changes thru Change 11.068 were included in MXG Early Prerelease 11.01=
===================that was dated May 15, 1993==========================
Change 11.068 Support for Corporate TIE user SMF record creates six new
EXTYTIE1- MXG datasets, reporting file transfer activity between
EXTYTIE6 PCs and Mainframes with this product:
IMACTIE TYPETIE1 - TIE Initialization/Termination
TYPETIE TYPETIE2 - TIE Logon/Logoff
VMACTIE TYPETIE3 - TIE Virtual Disk OPEN/CLOSE/MOUNT/DISMOUNT
May 11, 1993 TYPETIE4 - TIE File Transfer Send/Receive Start/End
TYPETIE5 - TIE QIMPORT/QEXPORT Start/End
TYPETIE6 - TIE VDIMPORT/VDEXPORT Start/End
Thanks to K. M. Torsvik, Postverkets Datasentral, NORWAY.
Change 11.067 This "split" architecture for BUILDPDB/BUILDPD3 has been
BUILD002 further enhanced. By splitting BUILDPDB into separate
BUILD004 pieces, parallel steps could be used to reduce elapsed
BUIL3001 run time, or some pieces could be skipped, etc. This is
BUIL3005 still in testing and the design may still change.
BUILD006 The CICS sorting that was in BUILD002 was moved to
May 11, 1993 BUILD004, the colon in BUILD003 was changed to semicolon,
new JES3 members BUIL3001 and BUIL3005 were created, and
BUILD006 was deleted. The revised architecture:
To replace BUILDPDB (for JES2):
BUILD001 - Reads SMF and creates all WORK data sets,
CICSTRAN.CICSTRAN, DB2ACCT.DB2ACCT and the
PDB.DB2STATn data sets.
BUILD002 - SORT some WORK datasets into PDB library.
BUILD003 - SORT RMF datasets into PDB and then build
PDB.RMFINTRV dataset.
BUILD004 - Combine CICS Statistics datasets and create
four PDB.CICxxxRV datasets.
BUILD005 - Sort TYPE30xx, TYPE6, TYPE26J2, interleave
with SPIN library, create PDB.JOBS,PDB.STEPS
PDB.JOBS, update SPIN library, copy SPIN
datasets into PDB (for backup), and create
PDB.SPUNJOBS.
To replace BUILDPD3 (for JES3):
BUIL3001 - Same function as BUILD001, for JES3.
BUILD002 - Same as JES2
BUILD003 - Same as JES2
BUILD004 - Same as JES2
BUIL3005 - Same function as BUILD005, for JES3, plus
sorts TYPE25 dataset.
One immediate use of this "split" architecture is for
VM/370 sites running BUILDPDB that do not have CICS data;
the virtual size of BUILDPDB can be reduced by removing
CICS processing. You need only to create a VMAC110 in
your USERID.SOURCLIB member with this line:
MACRO _VAR110 % MACRO _CDE110 %
and then instead of %INCLUDE SOURCLIB(BUILDPDB) use
%INCLUDE SOURCLIB(BUILD001,BUILD002,BUILD003,BUILD005);
It is also possible to remove DB2 processing, but as only
three datasets are created, the saving is much less. To
remove DB2, you would create a VMACDB2 in USERID.SOURCLIB
MACRO _VARDB2 % MACRO _CDEDB2 %
and also create a member DIFFDB2 with a blank line. Then
the preceding %INCLUDE would produce the minimum virtual
storage size by eliminating both DB2 and CICS processing.
Under MVS, the SMF processing (BUILD001) needed virtual
MEMSIZE of 17301K. With no CICS only 11397K was required,
and with neither CICS nor DB2 only 9973K was required.
Thanks to Neil Campbell, Inland Revenue, ENGLAND.
Change 11.066 Variables RDMT, RDTBK1-RDTBK4, and RNVSOV were not in the
VMACDMON KEEP= list, but have now been added for ASTEC datasets
May 11, 1993 DMONVOL, DMONJOBS, and DMONDSN. RDMT was formatted.
Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY.
Change 11.065 OPC/A data records may be lost; line 836, which reads:
VMACOPC IF _OPCVER AND MTDTYPE EQ 9 THEN INPUT +2 @;
May 11, 1993 should be deleted. See also later Change 11.122.
Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY.
Change 11.064 Migrated datasets with ORGEXPDT=9999999 were not expected
VMACDCOL in MXG's calculation of EXPDT='01JAN2099' for never
May 11, 1993 expiring datasets, but now that test is included.
Thanks to Alan M. Sherkow, I/S Management Strategies Ltd., USA.
Change 11.063 DB2 format MGDB2TY did not decode the '0A'X value. Also,
FORMATS values of zero for QWHCATYP occur in data records, but
May 10, 1993 are not documented by IBM; since all 0 occurrences have a
value of UTILITY for both QMDACNAM and QWHCCN, I assumed
that value, and added two lines to the format:
0='0:UTILITY'
0AX='AX:IMS TRANSACTION BMP'
Thanks to Rod Brady, Zurich Insurance, ENGLAND.
Change 11.062 CONFIGVM is a configuration file for MXG under CMS SAS.
CONFIGVM It is a modification to the CONFIG07/CONFIG08 MVS options
May 10, 1993 and has been found to support execution of BUILDPDB in a
32MB virtual machine.
Thanks to Tom Maynard, Nalco Chemical Company, USA.
Change 11.061 Candle's IMS Transaction Reporting Facility has now been
VMACITRF validated with data, and some revisions were required.
May 10, 1993 Five data sets are created:
ITRFMSG - One observation for each IMS transaction;
a transaction is defined by ITRF as a
message received and response sent, or a
program scheduled, processed, and ended.
ITRFMSGO - One observation for each message sent to an
alternate TP PCB by another transaction.
ITRFDATA - One observation for each database call (DLI
or FP)
ITRFSUM - One observation per database called per
transaction.
ITRFDB2 - One summary record per DB2 transaction.
Note that variables QWACNID and QWHCCV are
created in ITRFDB2 so that you can match the
IMS transaction in ITRFDB2 with its DB2ACCT
counterpart transaction.
Change 11.060 For jobs that initiate instantaneously in a multi-system
VMAC30 environment in which system clocks are not synchronized,
May 10, 1993 elapsed duration variables JELAPSTM,SELAPSTM,DSENQTM,
ALOCTM,EXECTM may be wrong (large positive or negative),
and the date of INITTIME,ALOCTIME,LOADTIME,JINITIME may
be one day later than reality! Change 10.213 (MXG 10.3+)
attempted to detect and circumvent an un-fixed IBM APAR,
(an obscure problem after an A78 ABEND), but my cure was
worse than the disease if REND (reader end time) is later
than INITTIME. The correction is to remove Change 10.213:
Find "10.213" and remove the four lines of that DO group.
(For reports with JELAPSTM from PDBs already built, you
can recalculate JELAPSTM=JENDTIME-JSTRTIME;)
Thanks to Shaheen Pervaiz, Trans Union Corporation, USA.
Change 11.059 Support for ZARA, The Tape Media Manager from Altai. This
EXZARDSN product is a replacement for CA-1 (TMS), and this support
EXZARVOL (originally written by Miller Dixon) processes their tape
IMACZARA catalog records to create two MXG datasets useful for the
TYPEZARA chargeback of tape data sets and for capacity planning of
VMACZARA tape volumes:
May 7, 1993 ZARADSN - One obs per dataset on tape, with attributes,
TAPEFEET (estimated), and volume account code
from the corresponding VOL record.
ZARAVOL - One obs per tape volume, with summed TAPEFEET
for all NRDSETS on the volume, and with the
maximum EXPDATE, CRDATE, and last use date of
any data set on this volume.
Member TYPEZARA has example JCL for the ZARA utility that
is executed to create the data records processed by this
support.
Thanks to Miller Dixon, Continuum, USA.
Change 11.058 The MULTIDD='Y' flag was not set before the IMAC30DD exit
VMAC30 was taken, causing MULTIDD to always be blank in dataset
May 7, 1993 TYPE30_D (also PDB.DDSTATS). The block of code which set
MULTIDD was moved to immediately before the IF OFFEXCP...
block of code.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 11.057 DCOLLECT SMSDATA (SMS constructs) records cause STOPOVER.
VMACDCOL As indicated in Change 10.309, no test data was available
May 6, 1993 for these new records. Now that I have test data records
I have corrected for my errors (as well as some of IBM's
mis-documentation) and believe the support is now valid
for seven subtypes (DC,SC,MC,BC,SG,VL,AG). The two OAM
subtypes (DR,LB) apply only for optical drives and were
not available for testing, but should also be valid now.
Thanks to Chris Coldiron, Depository Trust Company, USA.
Change 11.056 Support for SYNCSORT Release 3.5 added 27 new variables,
VMACSYNC including expanded storage usage by the sort, and EXCP
May 6, 1993 counts were relocated to the end of the record.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 11.055 This "PRINT ALL" utility still used POINT= statement, but
VMXGPRAL that fails with indexed datasets in Version 6, so the
May 6, 1993 logic was rewritten to not use POINT=syntax, just in case
you wanted to print an indexed dataset.
Change 11.054 TYPE80A can still fail with INPUT STATEMENT EXCEEDED.
VMAC80A Change 11.017 fixed only one case, but each INPUT with
Apr 30, 1993 "$VARYINGzz. yyyyyyy" syntax must be protected in case
yyyyyyy is greater than zz. (The zz value defines the
length of the variable; IBM docs many of the RACF fields
as 1-255, but MXG, in trying to minimize the stored size
of the TYPE80A dataset, picked more reasonable zz values.
For those fields that exceed the MXG zz choice, an error
occurs). The solution is to insert these two lines:
SKIP=yyyyyyyy-zz;
IF SKIP GT 0 THEN INPUT +SKIP @;
after the @; at the end of each INPUT statement that uses
the $VARYING informat. In addition to this protection,
all of the fields with $VARYING44. or $VARYING32. were
changed to $VARYING64. to minimize data loss in those
cases in which data length was more than MXG's default.
Thanks to Joe Faska, Depository Trust, USA
Change 11.053 NOTE: INVALID NUMERIC DATA, 'AVERAGE*ACTIVE-ONLY...'
VMACVMXA occurs because at line 094370 there is a semi-colon after
Apr 28, 1993 the label for variable AVGCONMS, but that is not the last
variable in the label statement. Remove the extra ';'.
Thanks to Peter Smith, Sema Group FM, ENGLAND.
Change 11.052 Specifying an undefined INTERVAL= value did not warn you
VMXGDUR that MXG did not recognize your request, and fell thru.
Apr 28, 1993 Now, a warning message is printed.
Thanks to Ed Lau, Lucky Stores, USA.
Change 11.051 The text of Change 11.001 was revised (the 8-lines to be
VMAC37 replaced was not exact, but there was no error in the 12
Apr 28, 1993 replacement lines). Additionally, the INPUT of OFFDETT
must be PIB4. instead of PIB2.
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Thanks to Irmgard Polifka, SAS Institute, GERMANY.
Change 11.050 DB2ACCT variable NETSNAME was incorrectly padded with
VMACDB2H blanks, and did not match CICSTRAN variable NETSNAME,
Apr 28, 1993 which is padded with nulls. This prevented merging DB2
and CICS transactions. Find "SUBSTR(NETSNAME...", and
insert just before that line this statement:
NETSNAME='0000000000000000000000000000000000000000'X;
(that's 20 bytes or forty zeros). Then, thirteen lines
later, replace ELSE IF 1 THEN DO;
with ELSE IF LOCBLANK EQ 1 THEN DO;
Now, variables NETSNAME and UOWTIME can be used to match
DB2ACCT observations with their CICSTRAN counterparts.
Thanks to Ron Thein, Mortgage Guaranty Insurance Corp., USA.
Change 11.049 Support for HMF, Host Monitoring Facility Product for
EXTYHMF0-9 Channel-Extension Hardware Monitoring. HMF creates SMF
IMACHMF records with 11 subtypes; this code supports subtypes 0
TYPEHMF and 6 thru 10. This is from Network Systems, known as
VMACHMF DXE's and sometimes called HyperChannel
Apr 27, 1993
Thanks to Bob Hursch, Lockheed Information Technology, USA.
Change 11.048 "ERROR 455-185 dataset TYPE30OM not specified" because
ANALDSET the override for that new dataset was not added to this
Apr 27, 1993 analysis member. Add after the last /* OVERRIDE ...
XY ADD NAME=EXTY30OM
/* OVERRIDE AND OUTPUT NO TYPE30OM RECORDS */
Thanks to Matt Klett, Kohler Company, USA.
Change 11.047 VM/ESA "UNEXPECTED/INVALID CONTROL RECORD" message occurs
VMACVMXA and no observations are created, because MXG's validity
Apr 27, 1993 check tested four bytes for 00008709x, but the first two
bytes may now be non zero. Change the test:
IF IPARMLF1 NE 00008709X THEN DO;
to read:
IF MOD(IPARMLF1,10000x) NE 8709X THEN DO;
Thanks to Walter H. Clark, C.U. Insurance, USA
Change 11.046 Variable SYSTEM was specified twice in the KEEP= list of
VMACTMVS datasets TMVSIV, TMVSJI and TMVSNQ. This caused a SAS
Apr 27, 1993 warning message, but no real impact.
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
Change 11.045 Variable ASISDCDY should have been spelled ASISDCDV in
ZRBRPT1 members ZRBRPT1 and ZRBRPT2.
ZRBRPT2
Apr 27, 1993
Thanks to Marcel Frechette, Montreal Trust Technology, CANADA.
Change 11.044 Variable QTXANPL exists only in DB2ACCT, and should not
ADOCDB2 have been in the KEEP= list for DB2STAT1. It caused no
DIFFDB2 error, only confusion because it was missing in DB2STAT1.
VMACDB2 It was removed from KEEP= list, and from documentation.
Apr 27, 1993
Thanks to Ellen Ulrich, Texas Instruments, USA.
Change 11.043 DB2 PMSTA02 report count of SUSPENDS was usually zero,
ANALDB2R because not all suspend-count-variables were included.
Apr 27, 1993 Insert after line 138120 (reads 120 'QUANTITY';) this
statement: SUSPENDS=SUM(QTXASLOC,QTXASLAT,QTXASOTH);
and then change line 138180 from QTXASUS to SUSPENDS.
Thanks to Ed Lau, Lucky Stores, USA.
Change 11.042 DB2 PMACC02 report count of OPENs was actually the count
ANALDB2R of fetches (from the preceding line), because the 2nd
Apr 27, 1993 occurrence of AVG=QXFETCH /NUMPLANS; should have been
The second occurrence of AVG=QXFETCH /NUMPLANS should be
AVG=QXCLOSE /NUMPLANS; (in line 035330).
Change 11.041 ASUM70PR can corrupt PDB.RMFINTRV if you have a changed
ASUM70PR member IMACRMFI, because IMACRMFI only set the interval
TRND70PR for PDB.RMFINTRV. With this change, the interval of both
Apr 28, 1993 PDB.ASUM70PR and PDB.RMFINTRV are both set by IMACRMFI.
Insert after the comments at the beginning of the member
%INCLUDE SOURCLIB(IMACRMFI);
and after the ID = line, insert these two lines:
INTERVAL=MYTIME,
MYTIME = _DURSET,
which causes both datasets to have the same interval.
Variable NRPRCS was deleted from ASUM70PR (and also from
TRND70PR); it never should have been kept and its value
has caused confusion. ASUM70PR was revised to detect and
flag intervals during which the number of LPARs was
changed (DURATM and PCTCPUBY could have been incorrect)
wrong), and most importantly, these new variables were
added to ASUM70PR for enhanced reporting:
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 56
minutes, it's LPCTnBY would be 31%. 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 18%, because that
LPAR was using 18% of the hardware while it
used 31% 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.
See also the MVS Technical Note III.7, Newsletter TWENTY-FOUR.
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.040 Error "DATASET TAPEMNTS NOT SORTED" in WEEKBLD/MONTHBLD
WEEKBLD results because the BY list for TAPEMNTS should have been
MONTHBLD BY SYSTEM DEVICE SHIFT TMNTMTYP TMNTTIME; instead of
Apr 27, 1993 BY SYSTEM SHIFT DEVICE TMNTMTYP TMNTTIME;
Thanks to David Ehresman, University of Louisville, USA.
Change 11.039 Variables RDRTM,RDRDEVCL,RDRDEVTY were dropped from the
VMAC30 TYPE30_V and PDB.SMFINTRV datasets (because they are JOB
Apr 27, 1993 related, not interval related), but the deletion was not
noted in the Change log for MXG 10.10.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 11.038 Variable QTXAIRLM was inadvertently omitted from the
ASUMDB2A SUM= list in the ASUMDB2A (DB2ACCT summarization) and the
TRNDDB2A TRNDDB2A (DB2ACCT trending) members. It is now added, and
Apr 15, 1993 the SUM= list was sorted & collimated for easier reading.
Thanks to Alan Keeble, British Steel, ENGLAND.
Change 11.037 The Total Read IOs was miscalculated on the Statistics
ANALDB2R Summary Report. It was actually the total Sync Reads but
Apr 13, 1993 should have been the sum of Sync and Prefetch Reads. Also
the calculation of Get Pages per Sync IO was omitted.
Find these five lines:
PUT @1 'TOTAL READ I/O OPERATIONS (RIO)'
@38 QB1TRIO 10.0
@49 QB2TRIO 10.0
@60 QB3TRIO 10.0
@71 QB4TRIO 10.0;
And replace them with these twenty-two lines:
QB1TOTL=SUM(QB1TRIO,QB1TPIO);
QB2TOTL=SUM(QB2TRIO,QB2TPIO);
QB3TOTL=SUM(QB3TRIO,QB3TPIO);
QB4TOTL=SUM(QB4TRIO,QB4TPIO);
IF QB1TRIO GT 0 THEN QB1PSYNC=QB1TGET/QB1TRIO;
ELSE QB1PSYNC=0;
IF QB2TRIO GT 0 THEN QB2PSYNC=QB2TGET/QB2TRIO;
ELSE QB2PSYNC=0;
IF QB3TRIO GT 0 THEN QB3PSYNC=QB3TGET/QB3TRIO;
ELSE QB3PSYNC=0;
IF QB4TRIO GT 0 THEN QB4PSYNC=QB4TGET/QB4TRIO;
ELSE QB4PSYNC=0;
PUT @1 'TOTAL READ I/O OPERATIONS (RIO)'
@38 QB1TOTL 10.0
@49 QB2TOTL 10.0
@60 QB3TOTL 10.0
@71 QB4TOTL 10.0;
PUT @1 'GETPAGE PER SYNC READ IO '
@38 QB1PSYNC 10.2
@49 QB2PSYNC 10.2
@60 QB3PSYNC 10.2
@71 QB4PSYNC 10.2;
Thanks to Victor Chacon, NYNEX, USA.
Change 11.036 Variables QWACARNL and QWACARNE count entries and exits,
ANALDB2R but DB2PM reports the number of suspensions, which is
Apr 13, 1993 one half of the data values. Thus, insert after 038520
QWACARNL=QWACARNL/2; and insert after 038620
QWACARNE=QWACARNE/2;
Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.
Change 11.035 This MXG utility to actually measure TSO response time at
CLTIMER your terminal was affected by SAS Version 6. A "STOP;"
Apr 13, 1993 statement must be added after the last "END;" statement.
Additionally, LS=80 was added to the OPTIONS statement,
also "'FOR TRANSACTION ' _I_" was added to the PUT for
cosmetic effect, and the sample CLIST in comments was
revised to use Version 6 DDnames SASLOG and SASPRINT.
If you have overlooked this utility, take a look now. It
should be made available to all TSO users so they can see
their own response time at their terminal to prove how
good real TSO response is (or isn't!).
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 11.034 "INVALID DATA FOR TAOSTYP" messages result because the
VMACTAO variable TAOSTYP should have been input at PIB1. instead
Apr 13, 1993 of HEX1.
Thanks to Jeff Burnett, Anixter Information Services, USA.
Change 11.033 Variable ACTDLYTM can have small negative (-.0010) values
VMAC30 because EXECTM is .01 resolution but ACTIVETM has .000001
Apr 13, 1993 resolution. After both calculations of ACTDLYTM, insert
IF . LT ACTDLYTM LT 0 THEN ACTDLYTM=0;
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 11.032 Two new variables, TRANTIME and TRANCOST may exist at the
VMACMEMO end of the accounting segment, after EXITAREA, and are
Apr 13, 1993 now added to the KEEP= list and LABELed:
IF MEMOACTL GE 84 THEN INPUT
TRANTIME PIB4. /*transmission*duration*/
TRANCOST PIB4. /*transmission*cost*/
@;
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Change 11.031 TYPE37 LAND segment has 2 fields after BRFDNADR that were
VMAC37 not documented in NETVIEW Admin Reference Manual but are
Apr 13, 1993 in IFASMFR macro and are now INPUT by MXG:
BRFSMADR $CHAR6. /*single mac address*/
BRFSMNAM $CHAR16. /*single mac name*/
Additionally, several variables are now formatted:
BRFALTID $HEX8.
BRFDNADR BRFSMADR BRFLMADR BRFRMADR BRFUPADR $HEX12.
Thanks to Wanda Prather, Johns Hopkins Applied Physics Lab, USA.
Change 11.030 Variable DSIVTOC in the KEEP= list was misspelled, and it
VMXGVTOF should be changed to DS4IVTOC.
Apr 13, 1993
Thanks to Pino Todesco, Western Australia Police, AUSTRALIA.
Change 11.029 NSPYACCT variable SNITIME is incorrect because DSNIMM was
VMACNSPY used for both the month and the minutes. Change DSNIMM to
Apr 13, 1993 DSNIMO in the INPUT for month, in the IF statement and in
the MDY function calculating SNITIME.
Thanks to Aubrey Tang, Government Insurance Office, AUSTRALIA
Change 11.028 TCP/IP address variables FPTLCLAD,FTPRMTAD,TELLCLAD and
VMACTCP TELRMTAD are four-byte character fields, which display
Apr 12, 1993 as $HEX8: "8681800C"x for example. However, TCP/IP users
expect these to be displayed as decimal values separated
by periods: 134.129.128.12 for the above value. Four new
address variables FTPLOCAL,FTPREMOT,TELLOCAL,TELREMOT are
now created with the expected format, using this logic:
INFORMAT FTPLOCAL $15.;
FTPLOCAL=PUT(INPUT(SUBSTR(FTPLCLAD,1,1),PIB1.),3.)
!!'.'!!
PUT(INPUT(SUBSTR(FTPLCLAD,2,1),PIB1.),3.)
!!'.'!!
PUT(INPUT(SUBSTR(FTPLCLAD,3,1),PIB1.),3.)
!!'.'!!
PUT(INPUT(SUBSTR(FTPLCLAD,4,1),PIB1.),3.);
Thanks to Sharon Jacobson, North Dakota Higher Education, USA.
Change 11.027 Variable LP0MGTTM was left out of the RETAIN list. Since
ASUM70PR LPAR=0 is only used by Amdahl's MDF, only those sites
Apr 6, 1993 need add LP0MGTTM to the RETAIN statement.
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.026 The test IF OFFPRCS+LENPRCS*NRPRCS GT LENGTH+1 THEN DO;
VMAC7072 should be NRPRCSS vice NRPRCS, but as this is insurance
Apr 6, 1993 for a bad record, there's no real impact.
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.025 You can create the PDB on tape with BUILDPDB, but it is
PDB to tape not normally recommended because it takes too long due to
Apr 6, 1993 rewinds (after the PDB.TYPE70s are written, they are read
back in to create RMFINTRV). It is much more efficient to
point the PDB DDname to a temporary DASD file, create the
PDB, and then use a PROC COPY IN=PDB OUT=PDBTAPE; to build
your PDB on tape. If you simply do not have enough temp
DASD for the PDB library, you can write the PDB directly
to tape, but you will need to tailor members IMACCICS,
IMACDB2, and EXPDBOUT. The instructions for tailoring
IMACCICS are contained in comments in that member. In
member IMACDB2, you must remove the "PDB." qualifier for
the DB2 datasets in the "_L" macro definitions, and then
in member EXPDBOUT you must add PROC COPY IN=WORK OUT=PDB;
SELECT DB2: ; if you want the DB2 datasets in your PDB
library.
Change 11.024 RMF-like reporting failed if PDB=SMF was specified, but
ANALRMFR works if PDB=PDB is used. This correction is extensive,
Apr 6, 1993 and a replacement member is available upon request. Also,
LET REQUEST should have been %LET REQUEST.
Change 11.023 Omegamon V550 creates invalid type 110 record, which MXG
VMAC110 detects and deletes, with a VMAC110.ERROR.1 message (with
SECTLLBB=0, TEMPLEN non zero, and LENGTH=32400) on the SAS
Apr 5, 1993 log. Candle's fix QOC0451 was the original fix for their
Aug 30, 1993 error, but in August fix QOC0534 superceded QOC0451.
This noted added June 20, 1994: Same error has occurred
with LENGTH=32320 instead of 32400, same fix.
Thanks to Khin Zaw, Nordstrom, USA.
Thanks to Andrew Lockyer, South Wales Electricity Board, WALES.
Change 11.022 If you have some MVS systems under PR/SM and some not and
ASUM70PR if you invoke ASUM70PR after BUILDPDB, your PDB.RMFINTRV
Apr 5, 1993 dataset may have missing data for some systems, because a
BY statement was missing. Change 10.335 added logic to
re-write PDB.RMFINTRV and add PLATBUSY/PLATCPUS variables
from ASUM70PR dataset, but the BY statement for the MERGE
was left out. If all systems are under PR/SM, then there
will be equal observations in ASUM70PR and PDB.RMFINTRV,
and the BY statement is not required, but if only some of
your systems are PR/SM, RMFINTRV is corrupted. To correct,
you must insert BY SYSTEM STARTIME; after the statement
MERGE TEMPINTV (IN=RMF) PLATBUSY (IN=INPRSM);
Thanks to Steve Clausing, Employers Health, USA.
Change 11.021 The new TYPE42DS (SMS data set statistics, subtype 6) has
FORMATS GMT values in SMF42PTE and SMF42PTS in the INTERVAL record
VMAC42 but MXG expected local values (as are in CLOSE record).
Apr 4, 1993 Correct by inserting these lines after the "@;" that
follows the input of variable LENJDIOL:
IF INTVCLOS=1 THEN DO; /* INTERVAL RECORD */
GMTOFF42=100*FLOOR((SMFTIME-SMF42PTE)/100);
SMF42PTE=SMF42PTE+GMTOFF42;
SMF42PTS=SMF42PTS+GMTOFF42;
END;
STARTIME=SMF42PTS;
ENDTIME =SMF42PTE;
DURATM =SMF42PTE-SMF42PTS;
Unrelatedly, the values for S42DSTYP are now decoded by
new format MG042DS., which has these values:
0='0:OTHER' 16='16:KSDS DATA'
1='1:PS' 17='17:KSDS INDEX'
2='2:PDS' 18='18:VARIABLE RRDS DATA'
3='3:PDSE' 19='19:VARIABLE RRDS INDEX'
4='4:DA' 20='20:FIXED LENGTH RRDS'
5='5:ISAM' 21='21:LINEAR DATA SET'
6='6:EXCP' 22='22:ESDS'
Change 11.020 ASTEX variable RMLFLAG2 was added to the KEEP= list of
VMACDMON DMONVOL data set, but it does not exist in the VOL record!
Apr 4, 1993 Instead, it should have been added to the KEEP= lists for
the DMONJOBS and DMONDSN datasets.
Thanks to John Rosza, Depository Trust Company, USA.
Change 11.019 The DIFFHSM member (which deaccumulates the HSM data) did
DIFFHSM not use the "_L" macro names. Each PROC SORT now has the
Apr 4, 1993 syntax of PROC SORT DATA= _LHSMxxx OUT=HSMyyyyy using
member IMACHSM to match the xxx with the yyyyy strings.
Thanks to Sudman Arik, Bezeq, ISRAEL.
Change 11.018 SAS Boolean bit tests of 32-bit strings does not work, as
VMAC30 Usage note V6-SYS.DATA-6047 discusses. The 32-bit test of
Apr 4, 1993 SMF30MFL has been replaced with IF SMF30MFL='1.......'B
and the SMF30MFL PIB4. input was replaced with
SMF30MFL PIB1. +3 to cause IOTMERR to be correctly set.
Thanks to G. W. Shanks, British Rail, ENGLAND.
Change 11.017 New TYPE80A fails with INPUT STATEMENT EXCEEDED if the
VMAC80A LOGSTR= string is more than 16 bytes (my default length).
Apr 3, 1993 I thought that SAS would skip over the extra data with:
RACFDLNN=MAX(16,RACFDLN);
INPUT LOGSTR $VARYING16. RACFDLNN @;
but it doesn't work that way, causing this error! Those
lines in the WHEN (46) clause must be replaced by these:
WHEN (46) DO;
IF RACFDLN GT 32 THEN DO;
SKIP=RACFDLN-32;
INPUT LOGSTR $CHAR32. +SKIP @;
END;
ELSE DO;
INPUT LOGSTR $VARYING32. RACFDLN @;
END;
END;
Note that I also increased LOGSTR's default length to $32.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 11.016 TYPE72MN contains only one PERFGRP from each type 72 RMF
VMAC7072 subtype 2 record, because MXG assumed one record for each
Apr 3, 1993 PERFGRP, but there are multiple PERFGRP segments in each
record. Subtype 2 processing logic was restructured
significantly. In addition, MXG logic was changed so that
TYPE72MN is output only if VALDSAMP GT 0 (i.e, actual
samples exist for this workload). Note that there can be
multiple observations with the same PERFGRP value in an
interval, because TYPE72MN contains a segment for each
combination of PERFGRP and DOMAIN. A replacement VMAC7072
member with this change is available upon request.
Thanks to Mike Skopec, Platinum Technology, USA.
Change 11.015 Change 10.259 implemented IBM APAR II06736 2nd algorithm
VMAC73 but that algorithm is wrong! As a result TYPE73 contains
Apr 3, 1993 an observation for every CHPID from 00 to FFx! Only the
1st algorithm (test SMF73VLD for valid CHPID) can be used
to discard dummy CHPID entries. The statement
IF CHANIND GT 0 OR CHANINDX GT 0 OR CHANINDY GT 0 OR
PCHANBY GT 0 OR SMF73PBY GT 0 OR SMF73PTI GT 0 THEN DO;
is now replaced with
IF VALIDPTH='Y' THEN DO;
Also, the CTC bit is now decoded to set CHANTYPE='CTC' if
the CHPID is actually a CTC, and CHANTYPE is now reset:
IF CHANIND ='..1.....'B THEN CHANTYPE='BLOCK MUX';
ELSE IF CHANIND ='...1....'B THEN CHANTYPE='BYTE MUX';
ELSE IF CHANINDY='.1......'B THEN CHANTYPE='CTC';
ELSE CHANTYPE=' ';
Thanks to Tom Parker, Hogan Systems, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 11.014 The JCL for installation example has a UNIT= coded twice
JCLINSTL in the third step. Use either the UNIT=3380 or UNIT=3390,
Apr 3, 1993 but remove the UNIT=SYSDA from that JCL example.
Thanks to Mark Robbins, Jaguar Cars, ENGLAND.
Change 11.013 Change 10.175 documents how to use the new "_L" and "_K"
DOC macros, but the paragraph beginning 'The "_L" macro lets
Mar 28, 1993 you ...', (first paragraph on page 67 of Newsletter 23)
has two occurrences of _KTY0 that should have been _LTY0.
Thanks to Ron Becham, Southern California Edison, USA.
Change 11.012 JCLTEST with SAS 5.18 has failed at 2 sites with the old
JCLTEST "data set WORK.#DIRMACR is out of space" condition that is
Mar 28, 1993 discussed in Change 8.025 (but neither site used IMACKEEP)
and my SAS 5.18 JCLTEST does not fail! Splitting TESTIBM
into two pieces will circumvent the problem, but since it
only occurs in JCLTEST, it can be ignored. (The primary
purpose of JCLTEST6 is to verify your MXG format library
was correctly built, and that your IMAC tailoring did not
cause a syntax error. Since JCLTEST got to TYPE74, both
sites knew they had tested the important IMACs, so they
proceeded to run JCLPDB, which did not fail. This does
not apply to SAS Version 6 - use JCLTEST6 and JCLPDB6 and
this 5.18 error does not occur!
Change 11.011 FOCUS SMF record 12-byte reserved field FOCUFRS0 was
VMACFOCU changed to @69+OFFSMF FOCUSRV $CHAR8. @77+OFFSMF
Mar 17, 1993 FOCUFRS0 $CHAR4. , and FOCUSRV was labeled 'FOCUS*SERVICE'
and added to the KEEP= list. The value of new variable
FOCUSRV is "FOCUS" in the data observed thus far!
Change 11.010 Dataset TYPETSWP (tape swaps from MXG Tape Mount Monitor)
BUILDPDB is created in the WORK file by BUILDPDB, but was not then
BUILDPD3 sorted into the PDB library. After the BY statement for
Apr 3, 1993 the PROC SORT NODUP DATA=TYPETMNT OUT=PDB.TYPETMNT ...,
replicate that PROC and BY statements, change TYPETMNT to
TYPETSWP, and change the BY statement to read
BY SYSTEM SHIFT DEVFROM TSWPTIME;
Additionally, in the PROC DATASETS following these sorts,
add TYPETMNT and TYPETSWP to the DELETE statement.
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 11.009 NETSPY "Invalid argument to function DATEJUL" might occur
VMACNSPY with NSPYREC='U' because STOPTIME fields TMEE/DTEE added
Apr 3, 1993 by NETSPY R4.3 used previously reserved fields that are
non-zero in R4.2! DTEE is input as packed decimal, and if
the non-zero value happens to end with Fx or Cx, the error
occurs. To correct, find the following statement (it is
the first "IF DTEE" test, 21 lines after the DO group test
for NSPYREC='S' or 'T' or 'U'):
IF DTEE GT 0 THEN STOPTIME=DHMS(DATEJUL(DTEE),0,0,TMEE);
and change it to read:
IF NSPYREL GE 'R4.3' AND DTEE GT 0 THEN
STOPTIME=DHMS(DATEJUL(DTEE),0,0,TMEE);
Thanks to Bob Butchco, The Genix Group, USA.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 11.008 MXG 10.10 only, and only if you write type 74 RMF records
RMFINTRV for tape devices. If so, RMFINTRV variables DEVACTTM,
Apr 3, 1993 DEVCONTM DEVDISTM, DEVPNDTM and AVGRSPMS include both DASD
and TAPE statistics (instead of DASD-only), due to Change
10.299. To correct RMFINTRV, find "SIO74CNT=.;", and then
insert this line after that line:
DEVACTTM=.;DEVCONTM=.;DEVDISTM=.;DEVPNDTM=.; AVGRSPMS=.;
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.007 Using ANALDB2R with PDB=SMF failed when accounting report
READDB2 were suppressed and statistics reports were not. Using
Apr 3, 1993 PDB=PDB does not fail. The error is in READDB2, which is
invoked by ANALDB2R when PDB=SMF is specified. Change the
line (this is the third and last test for LENGTH(&PDBOUT):
%IF %LENGTH(&PDBOUT) NE 0 %THEN %DO;
to read:
%IF %LENGTH(&PDBOUT) NE 0 AND &NUMIFC GT 0 %THEN %DO;
Thanks to Ed Lau, Lucky Stores, USA.
Change 11.006 DB2STAT0 variable QDSTQDBT is incorrectly input. There's
VMACDB2 two occurrences of OFFQJST=OFFQJST-3+OFFSMF; but the last
Apr 3, 1993 one should have been OFFQDST instead of OFFQJST.
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.005 DB2ACCT records cause "INVALID 3rd ARGUMENT IN SUBSTR"
VMACDB2 error because account fields were not protected for zero
Apr 3, 1993 length fields. In addition, variable JOB is blank.
Delete the statement JOB=' '; (just before %INCLUDE for
IMACACCT) to prevent blank JOB name. To protect for zero
length account fields, the nine statements of the form
ACCOUNTn=SUBSTR(QMDAACCT,BEG,LENACCTn);
must each be changed to read
IF LENACCTn GT 0 THEN
ACCOUNTn=SUBSTR(QMDAACCT,BEG,LENACCTn);
where n=1,2,...9.
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.004 TYPE30 variable DSSIZHWM incorrectly changed by Change
VMAC30 10.261, and is much too large. Change the multiplier from
Mar 28, 1993 16777216 to 1048576.
Thanks to Tom Parker, Hogan Systems, USA.
Change 11.003 MVS/ESA 4.3 only. TYPE30_V and PDB.SMFINTRV timestamps
VMAC30 INTBTIME and INTETIME were not converted from GMT to local
Apr 3, 1993 time correctly (however, SMFTIME is valid and can be used
to approximate the interval end local time until this
change is made). Change INTBTIME-SMF30IST to read instead
SMF30IST-INTBTIME.
Thanks to Jim Nissen, Principal Financial Group, USA.
Change 11.002 Processing VSAM SMF type 30 records can produce "INVALID
VMAC30 OMVS TRIPLET" message and no observations in TYPE30xx data
Apr 3, 1993 sets. The three lines reading "IF OFFPROD-3-COL GE ...."
must be changed to "IF OFFPROD-3+OFFSMF-COL GE ...." if
you want to process VSAM SMF data directly. There is no
error in processing SMF data which has been dumped.
Thanks to Jonathan E. Paley, Massachussets Mutual, USA.
Change 11.001 Type 37 can cause INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC37 error.
Apr 3, 1993 First, replace the following eight lines:
Apr 27, 1993 IF OFFSELD GT 0 AND NRSELD GT 0 THEN DO;
SUBSTR(FND37OFF,9,1)='S';
OFFLAND=OFFLAND-3+OFFSMF;
INPUT @OFFLAND
BRFTEXT $CHAR200. /*SELF DEFINING*TEXT*MESSAG*/
BRFTEXTA $CHAR75. /*SELF DEFINING*TEXT*MESSAG*/
@;
END; /* END SELD SECTION TYPE 37 */
with the following twelve lines (note that the first three
lines are unchanged):
IF OFFSELD GT 0 AND NRSELD GT 0 THEN DO;
SUBSTR(FND37OFF,9,1)='S';
OFFSELD=OFFSELD-3+OFFSMF;
INPUT @OFFSELD @;
IF LENSELD GE 275 THEN INPUT BRFTEXT $CHAR200.
BRFTEXTA $CHAR75. @;
ELSE IF 201 LE LENSELD LT 275 THEN DO;
SKIP=LENSELD-200;
INPUT BRFTEXT $CHAR200. BRFTEXTA $VARYING75. SKIP @;
END;
ELSE INPUT BRFTEXT $VARYING200. LENSELD @;
END; /* END SELD SECTION TYPE 37 */
Second, in the "IF OFFDETT GT 0 ..." DO group that follows
the above "IF OFFSELD GT 0 ..." DO group, change all three
occurrences of OFFLAND to OFFDETT.
Third, the INPUT of OFFDETT must be PIB4. instead of PIB2.
Thanks to Larry Doub, R J Reynolds Tobacco USA.
Thanks to Rod Fernandes, Albert Heijn B.V., HOLLAND.
LASTCHANGE: Version 11
=========================member=CHANGE10================================
/* COPYRIGHT (C) 1984-1993 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is the Production MXG Version 10.10, dated March 15, 1993.
Changes through:
Change 10.336 are included in MXG Version 10.10, Mar 15, 1993
Change 10.323 were printed in Newsletter TWENTY-THREE, Mar 15, 1993
Change 10.304 are included in MXG PreRelease 10.6, Feb 23, 1993
Change 10.265 are included in MXG PreRelease 10.5, Jan 28, 1993
Change 10.251 are included in MXG PreRelease 10.4, Jan 8, 1993
Change 10.241 are included in MXG PreRelease 10.3A, Dec 17, 1992
Change 10.235 are included in MXG PreRelease 10.3, Dec 13, 1992
Change 10.208 are included in MXG PreRelease 10.2, Oct 18, 1992
Change 10.199 were included in Early PreRelease 10.2, Oct 12, 1992
Change 10.113 were included in MXG PreRelease 10.1, Jul 10, 1992
Change 10.104 were printed in Newsletter TWENTY-TWO, Jul 10, 1992
Table of Contents:
I. MXG Software Status and Enhancements:
II. Incompatibilities, Installation, and Space Requirements.
III. Documentation of MXG Software.
IV. MXG Technical Notes - see NEWSLETTER TWENTY-THREE
V. MVS Technical Notes - see NEWSLETTER TWENTY-THREE
VI. VM Technical Notes - see NEWSLETTER TWENTY-THREE
VII. CICS Technical Notes - see NEWSLETTER TWENTY-THREE
VIII. SAS Technical Notes - see NEWSLETTER TWENTY-THREE
IX. Change Log
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.
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 notes.
These enhancements are in MXG 10.10, but were not printed in the MXG
Technical Newsletter number TWENTY-THREE:
Note: There are 1965 members in MXG 10.10, not the 2000+ I thought
there would be. MXG now creates 47,292 variables in 1195 data
sets with its 533,759 lines of source code.
Support for type 30 OpenEdition/MVS measurements
NETSPY Average Host Response calculation corrected
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.
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.
Each of these 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.5
RMF 4.3.0 (for MVS/ESA 4.3 Mar 23 1993. 10.5
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
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 thru MXG 10.x should find
no other compatibility issues.
Sites migrating 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 (also in member NEWSLTRS).
MXG 10.10 will still execute under SAS 5.18, but this is likely to
be the last version that will fully work under that archaic version
of SAS; MXG intends to begin to exploit Version 6 features in MXG
future versions, and we strongly recommend use of SAS 6.07 or later!
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 70-cyl PDS: MXG.V1010.MXG.SOURCLIB, & use IEBUPDTE
to read the MXG tape to create the 1800+ member Source Library.
c. 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 V1010.USERID.SOURCLIB.
d. 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.
e. 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.
e. 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.
f. EDIT and submit member JCLTEST6 (JCLTEST if still on SAS 5.18)
to verify that your tailoring did not create any errors.
g. 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 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.
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.
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.332 Seventy-Three 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-formatted RMF reports are now produced by MXG.
ANALRMFR 10.301 IBM's RMF reports produced from MXG datasets.
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.
ASUMDB2A 10.090 DB2 Account "transactions" summarized into ASUMDB2A.
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, for 17 LPARs.
ASUM70PR 10.335 PCTOFHDW busy in this partition added to RMFINTRV.
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.
GRAFxxxx 10.227 SAS 6.07 replaced XSWISS font name with SWISS.
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.
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.
MXGSAS 10.336 Example JCL Procedure MXGSAS now provided
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.
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.
TYPECTLD 10.327 CONTROL-D Release 2.0.0 is also supported.
TYPECTLD 10.327 CONTROL-D Release 2.0.0 is supported.
TYPEDB2 10.024 MVS Account fields added to DB2ACCT!
TYPEDB2 10.333 DB2ACCT fields ACCOUNTn were not input.
TYPEDB2 10.333 MVS Account fields now are actually input 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.
TYPEFOCU 10.334 FOCUS record caused INPUT STATEMENT EXCEEDED error
TYPEFTP 10.176 NETVIEW FTP SMF record timestamps reversed.
TYPEF127 10.162 Support for FACOM PDLF Type 127 for MSP/EX Version.
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.
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.
TYPEM204 10.120 MODEL204 variable M24IODEV input, EXM24ACT eliminated
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
TYPENSPY 10.326 NETSPY AHOSTRSP calculation corrected.
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).
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.
TYPEX37 10.013 STOPX37 Release 3.4 is supported.
TYPEX37 10.276 Support for Empact's STOPX37 Release 3.5.
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.
TYPE30 10.325 Support for OpenEdition/MVS type 30 enhancements.
TYPE30OM 10.325 Type 30 support for OpenEdition/MVS
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 misdocumented.
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/
TYPE70x 10.320 Support for OpenEdition MVS, OMVS, RMF records.
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.
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.
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:
NEXTCHANGE: Version 10
Change 10.336 The sample JCL Procedure MXGSAS is now provided in member
MXGSAS MXGSAS, and is now used in MXG JCL examples. The PROC is
Mar 11, 1993 simply an extension to the SAS607 JCL Proc, with the MXG
data sets and options provided to minimize your JCL.
Using MXGSAS, it is no longer necessary to override the
BLKSIZE on the //WORK DD, because there is no BLKSIZE
specified on that DD in the PROC, which permits the MXG
CONFIG07 default of BLKSIZE(DASD)=HALF to control the
blocksize. (Previous JCL examples showed the override
because the SAS607 JCL Proc had hardcoded BLKSIZE). These
symbolic parameters are provided in MXGSAS:
MXGHLQ= The highlevel qualifier of your MXG data sets,
defaults to MXGHLQ='MXG'
SASHLQ= The highlevel qualifier of your SAS data sets,
defaults to SASHLQ='SAS.SAS607'.
CONFIG= Can be used to override, but the PROC itself
concatenates &MXGHLQ..MXG.SOURCLIB(CONFIG07),
so there is no requirement to specify CONFIG=
WORK = Cylinders of work space. Default is (30,10)
SORT = Cylinders of sort work space in each of three
//SORTWKnn DDs. Explicit DDs are included to
prevent dynamic allocation; historically, SAS
and SORT packages have ABENDed when dynaloc was
used and there are multiple sorts of datasets of
different sizes (large, then small, then large
dataset sorting is common in BUILDPDB).
However, this is an example JCL PROC, and you are free to
modify it to meet your installation's JCL requirements.
Change 10.335 Program ASUM70PR enhanced to merge PR/SM data into the
ASUM70PR RMFINTRV and added these three new variables:
Mar 11, 1993 PLATCPUS - Number of CPUs in the hardware platform
PLATBUSY - Total "platform" CPU busy of the PLATCPUS
PCTOFHDW - Percentage of platform busy in this MVS system
RMFINTRV describes each MVS system in a PR/SM partition,
while ASUM70PR describes the whole box. The RMFINTRV
variable PCTCPUBY is the percentage of the interval during
which the NRCPUS in this MVS system were dispatched.
Assume a 100 second interval, and assume that you have a
3090-600 with two partitions, a "test" partition as a
3090-300 that can use three CPU engines, and a "prod"
partition as a 3090-600 that can use all six engines, and
assume you have Capped the test partition at 33%. At full
utilization, then, PLATBUSY would be 100% (of PLATCPUS=6
engines), the test partition RMFINTRV PCTCPUBY would be
66% (of NRCPUS=3 engines) and the prod partition RMFINTRV
PCTCPUBY would be 66% (of NRCPUS=6 engines). There were
600 seconds of total hardware platform CPU busy
(PLATCPUS=6)*(PLATBUSY=100%)*(DURATM=100) = 600, and
there would have been 200 seconds in test partition busy
(NRCPUS=3)*(PCTCPUBY=66%)*(DURATM=100) = 200, and there
would have been 400 seconds in prod partition busy
(NRCPUS=6)*(PCTCPUBY=66%)*(DURATM=100) = 400 seconds,
and PCTOFHDW can be calculated for the test partition:
PCTOFHDW = 100*(NRCPUS*PCTCPUBY)/(PLATCPUS*PLATBUSY);
= 100*(3*66)/(6*100) = 100*(1/3)= 33%
which shows that while PCTCPUBY=66% in RMFINTRV, in fact,
the test partition was using the full 33% of the hardware
platform that capping allowed it to use; arguably the test
partition is at 100% of the capacity you gave it!
Unfortunately, the Capping Target value is not stored in
the type 70 record, but PCTOFHDW may be a better measure
of processor utilization in a PR/SM environment with
shared processor engines.
Thanks to Gene Fernando, American Honda Motor Co, USA.
Change 10.334 FOCUS SMF record processing code caused INPUT STATEMENT
VMACFOCU EXCEEDED RECORD length (because MXG did not protect for an
Mar 20, 1993 82-byte short record); the change was made in MXG 10.3,
but not entered in CHANGES, and thus I do not know to whom
to give thanks. (If it's you, let me know!).
Change 10.333 DB2ACCT fields ACCOUNTn were not input. The test for the
VMACDB2 existence of account fields (IF QWHSNSDA GE 6) should have
Mar 20, 1993 been GE 7, and needed to be relocated until after IMACDB2H
had been included (since that's where QWHSNSDA is input!).
Finally, the offsets for the QMDA triplet should have been
73, 77, and 79 instead of 75, 81, and 83!
Thanks to Linda Thomas, Alberta Government, CANADA.
Change 10.332 Many new ADOCs members were added to MXG 10.10. Some are
ADOCx completed, but many are still work in progress, with new
Mar 9, 1993 text and discussion to be added. Nevertheless, since all
of the "variable descriptions" have been reviewed, the
usefulness of the information justified baring my soul, as
there's clearly still a lot of writing to be done. Most
now have PROC PRINT and PROC MEANS examples, which I still
find to be the best tool in SAS to learn about new data.
I intend to concentrate more on writing now that 10.10 is
done and looks so robust. Our next newsletter will keep
you informed of my progress toward the consolidation and
rewrite of both MXG books and all Newsletters, but I still
will provide all text in the MXG Source Library first, and
then will concern how much of it is put on paper!
Change 10.331 NETSPY Type "U" record sometimes produced negative value
VMACNSPY for TRANSNO when LUFDRSEQ='.1......'B because I did not
Mar 9, 1993 verify that TRANSNO was non-zero before subtraction. Now,
TRANSNO=TRANSNO-1 is executed only if both the bit is on
and TRANSNO GT 0.
Thanks to Jan-Ake Christoffersson, GotaData, SWEDEN.
Change 10.330 Variables UBRELBK and UMRELBK should have been spelled as
VMACDCOL UBREBLK and UMREBLK, and now they are.
Mar 9, 1993
Change 10.329 MXG 10.10 has been tested under both SAS 6.07 & SAS 6.08,
CONFIG08 and there are no external changes to your MXG jobs when
Mar 9, 1993 you migrate to SAS 6.08. Member CONFIG07 works with 6.08.
However, there is a new CONFIG08 member in MXG 10.10, just
for consistency in naming conventions, and just in case it
turns out that it is needed when 6.08 becomes production.
Because SAS 6.08 is currently a Beta release, benchmarks
of MXG under SAS 6.08 will await the production 6.08.
Change 10.328 MXG 10.10 has been tested under SAS 5.18, but this is the
DOC last MXG version that will completely support that archaic
Mar 9, 1993 version! Future MXG enhancements will now exploit new SAS
Version 6 features, which may cause incompatibility.
Change 10.327 CONTROL-D Release 2.0.0 is also supported by MXG as there
VMACCTLD were no changes to their SMF record in that release.
Mar 9, 1993
Thanks to Brian Cobb, Credit General Industriel, FRANCE.
Change 10.326 NETSPY dataset NSPYLU average host response time AHOSTRSP
VMACNSPY was slightly off if the number of transactions terminated
Mar 9, 1993 at the host (LUNRSPSS) was different than the number of
transactions input (TRANSNO), because MXG incorrectly used
TRANSNO in the denominator; now LUNRSPSS is used.
Thanks to Bob Hursch, Lockheed Information Technology, USA.
Change 10.325 Support for OpenEdition/MVS OMVS, section in type 30 adds
EXTY30OM new dataset TYPE30OM, which will contain one observation
VMAC30 for each process segment in each type 30 record. There
Mar 9, 1993 can be many process segments in a type 30 interval or step
termination record, and TYPE30OM will contain observations
from both step term and interval records. In addition,
type 30 pseduo step termination records are created when
an OMVS address space is "dubbed", indicating a change of
in state of that address space. The pseudo termination
record is identified by ABEND='OMVSEX' (because an OMVS
EX() was issued). Each "dub" creates a separate type 30
step record, which are identified within each STEPNR by a
new sub-step number, SUBSTEP. This support has only been
coded and syntax checked.
Change 10.324 Variable RMLFLAG2 was not kept in ASTEX dataset DMONVOL,
VMACDMON but now it is and it is formatted $HEX2.
Mar 8, 1993
Thanks to John Rosza, Depository Trust Company, USA.
====Changes thru 10.323 were printed in MXG Newsletter TWENTY-THREE====
Change 10.323 The PDB data sets listed in the Weekly and Monthly jobs
JCLMNTH were not in synchronization; some were in the weekly but
MONTHBLD not in the monthly, and TYPETMNT was copied twice in the
WEEKBLD weekly and monthly examples. Now, all data sets created
Mar 7, 1993 by the JCLPDB6 example will be copied to WEEK & MONTH.
Thanks to Barry Lampkin, Polaroid, USA.
Change 10.322 Significant progress has been made in MXG documentation,
ACHAP31 as there are now many new ADOCxxxx members, but it's still
ADOCxxxx a long way from completion. Most ADOCs now contain sample
Mar 6, 1993 PROC PRINTs and PROC MEANS, and variable definitions have
been revised, but some of the text has not been updated.
Change 10.321 This is the "all-your-data-sets-tracking-system" to keep
ADOCDSNS track of storage of all data sets, combining DCOLLECT data
DAILYDSN (all of your online volumes as well as information on
JCLDAYDS HSM migrated datasets, HSM backups, DASD volume capacity,
TRNDDSNS HSM tape capacity, and VSAM clusters) with data from the
WKLYDSNS TMS (CA-1) product's TMC tape data set catalog. It is
Mar 6, 1993 described in member ADOCDSNS and in comments.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.320 Support for OpenEdition MVS, OMVS, in RMF records. TYPE70
FORMATS contains counts for OMVS address spaces (OMVS00-OMVS11 and
VMAC7072 OMVSAVG,OMVSMAX,OMVSMIN). TYPE71 contains six destination
VMAC71 counts for two new OMVS Swap Reasons, SWAPOI=OMVS Input
VMAC74 Wait, SWAPOO=OMVS Output Wait. New TYPE74OM dataset from
Mar 6, 1993 Monitor III captures OMVS Kernel Activity: TOT/MIN/MAX for
System Calls, CPU time, Fork/Dub Fails because of either
max users, max processes, or max processes per user, count
of users, count of processes, and the defined maximum
number of users, processes, and processes per user.
Change 10.319 Very preliminary support for RS6000 AIX commands VMSTAT,
VMACRSIO IOSTAT, and PS, with this user contribution. VMACRSCR
VMACRSPS is the script used that adds the data/time that is not in
VMACRSCR the command output! Not all fields are decoded, variables
VMACRSVM are not labeled, etc., but this is a start if you have the
Mar 6, 1993 need to look at AIX on your RS6000. The next release will
enhance and document, probably rename datasets and members
and add support for the AIX accounting file as well.
Thanks to Rachel Quiroz Holt, Neiman Marcus, USA.
Thanks to Andy Rockwell, Neiman Marcus, USA.
Change 10.318 TYPE42VL variables SMF42DB1 & SMF42DB2 are now formatted
VMAC42 as $HEX2. so they legibly print their bit values.
Mar 6, 1993
Thanks to Stephen W. Sweely, NM, AUSTRALIA.
Change 10.317 The GMT Offset, GMTOFFTM, is now available in RMF records
VMAC7072 under MVS/ESA 4.3, if Global Synchronization is enabled.
VMAC70s By comparing SYNCTIME with ENDTIME and using fuzzy logic,
Mar 3, 1993 MXG now creates the RETAINed variable GMTOFFTM from the
type 70 record, that may be useful in converting other SMF
records that contain GMT instead of local. This work is
not complete, since it only protects records written after
the first type 70 is found in your SMF file. I intend to
enhance the SPIN logic in BUILDPDB to keep the GMTOFFTM
from each SYSTEM to protect those early records!
Change 10.316 MXG formats contain the data value, a colon, and the data
UTILFMTX description, but for some report users (notably auditors)
Mar 5, 1993 the data value and colon confused them. This utility will
create an alternative format library for reports that has
removed the data value and colon. You can then point the
//LIBRARY DD in your report programs to the alternative
format library, or use SAS's FMTSEARCH option in reports.
Thanks to Joe Faska, Depository Trust, USA
Change 10.315 TCP/IP allows for two different SMF record IDs for TELNET
VMACTCP and FTP, but some sites assigned only one record ID. This
Mar 5, 1993 is now supported, as MXG reads inside the record to decide
which dataset is to be output. See also Change 10.256.
Thanks to Kurt Karlsen, NIT.
Change 10.314 MXG 10.1+ only, for JES3 BUILDPD3, "WORK.TAPEMNTS.DATA"
BUIL3606 error message results because the _VARTMNT and _CDETMNT
Mar 5, 1993 macro invocations were not in BUIL3606. Now they are!
Thanks to Hanno Bresch, SAS Institute, GERMANY.
Change 10.313 Variable ZDATE was not in the KEEP= list for TYPETAO data
VMACTAO set, but it is now!
Mar 5, 1993
Thanks to Sharon O'Daniel, Blue Cross Blue Shield of Kentucky, USA.
Change 10.312 The paper "An RMF Bigots View of Measuring UNIX Systems,
ADOCHPCS or how i learned to type in lower case", presented at
Mar 3, 1993 CMG and SHARE by Chuck Hopf, is now contained in ADOCHPCS.
Change 10.311 This is a preliminary change created for initial testing.
BUILD001 BUILDPDB was split into six members:
BUILD002 BUILD001 - Reads SMF and creates all WORK data sets,
BUILD003 CICSTRAN.CICSTRAN, DB2ACCT.DB2ACCT and the
BUILD004 PDB.DB2STATn data sets.
BUILD005 BUILD002 - SORT some WORK datasets into PDB library.
BUILD006 BUILD003 - SORT RMF datasets into PDB and then build
Mar 3, 1993 PDB.RMFINTRV dataset.
BUILD004 - Combine CICS Statistics datasets and create
four PDB.CICxxxRV datasets.
BUILD005 - (For JES2).
Sort TYPE30xx, TYPE6, TYPE26J2, interleave
with SPIN library, create PDB.JOBS,PDB.STEPS
PDB.JOBS, update SPIN library, copy SPIN
datasets into PDB (for backup), and create
PDB.SPUNJOBS.
BUILD006 - (For JES3).
Sort TYPE30xx, TYPE6, TYPE26J3, interleave
with SPIN library, create PDB.JOBS,PDB.STEPS
PDB.JOBS, update SPIN library, copy SPIN
datasets into PDB (for backup), and create
PDB.SPUNJOBS.
This may permit improved run time of the BUILDPDB process,
because once BUILD001 has run, the remaining four phases
may be executable in parallel. However, there will be JCL
constraints, and SAS/SHARE may be required for concurrent
update from parallel steps, and there may be additional
design changes before this becomes a recommended process.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 10.310 For interval observations most MXG datasets have STARTIME
VMACNSPY and DURATM variables for the interval start and duration,
VMAC38 but in some datasets STARTIME does not exist or it has a
VMAC39 different name, and similarly for DURATM. It is now my
VMAC110 intention that STARTIME and DURATM variables will exist
VMACTSOM consistently in all MXG interval data sets, by creating
Mar 1, 1993 them where necessary (and without changing existing names
of their counterparts, so your reports won't break). The
members listed in this Change have all had either STARTIME
or DURATM or both added to their interval data sets,
except for TYPE39FF (NETMASTER), which does not contain
the DURATM and hence STARTIME cannot be determined. Let
me know if you find others that should be updated.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 10.309 Very archaic EPILOG 451 code missed three undocumented
VMACEPIL bytes. Insert +3 after BIODISP PIB1. to correct the
Feb 28, 1993 BIO..... variables after BIODISP.
Thanks to Chris Spikings, Deutsche Bank AG, ENGLAND.
=Changes thru 10.304 were included in MXG PreRelease 10.6, Feb 23, 1993=
Change 10.308 OPC data apparently can be dumped in different formats.
VMACOPC If "OPC" starts in the 1st byte of the logical record, MXG
Feb 25, 1993 default is valid, but if "OPC" starts in the 4th byte of
the record, you must change to OFFSMF=-3 to OFFSMF=0 in
VMACOPC. Use DATA;INFILE OPCLOG;INPUT;LIST;STOP: to
print the first record to find the location of "OPC".
Thanks to Fulvio Robbiani, Banca Commerciale Italiana, ITALY.
Change 10.307 MXG no longer sets ABEND=NOTP in PDB.JOBS & PDB.SPUNJOBS
BUILDPDB because it was overlaying the ABEND value from the job
BUILDPD3 termination record. This will help in counting job-level
SPUNJOBS events, but for analysis of CONDCODE within ABEND, you
Feb 24, 1993 must use the PDB.STEPS data (CONDCODE in PDB.JOBS is wrong
if a flushed step followed the abending step).
Thanks to Steve Talley, Department of the Army, USA.
Change 10.306 Type 0 SMF record processing now checks record length and
VMAC0 deletes invalid records, after putting a message on the
Feb 24, 1993 SAS log. Occasionally, SMF records are created with the
record ID of 0, due to coding errors, but they looked like
IPL events. If you detect bad records, and know what the
true ID is, you can convert the bad record ID in member
IMACFILE, using IF ID=0 AND LENGTH GT 31 THEN ID=42;
if the bad record to be converted was actually a type 42.
Change 10.305 DCOLLECT has been enhanced in DFP 3.3 by APARS OY59795 &
EXDCODAG OY60048 with nine new datasets describing SMS constructs
EXDCODBC and control information. Even more significant, DFSMS 1.1
EXDCODDC adds long-needed VSAM statistics (including space used!).
EXDCODDR Two existing datasets are enhanced with new variables:
EXDCODLB DCOLCLUS (VSAM Data Set Information)
EXDCODMC DCAASP ='BYTES OF*FREESPACE*IN DATA SET'
EXDCODSC DCACAS ='CONTROL*AREA*SPLITS'
EXDCODSG DCACIS ='CONTROL*INTERVAL*SPLITS'
EXDCODVL DCADLR ='DELETED*RECORDS'
IMACDCOL DCAEXC ='EXCPS'
VMACDCOL DCAHARBA='HIGH ALLOCATED*RELATIVE BYTE*ADDRESS'
Feb 24, 1993 DCAHURBA='HIGH USED*RELATIVE BYTE*ADDRESS'
DCAINR ='INSERTED*RECORDS'
DCAKLN ='KEY*LENGTH*
DCANLR ='LOGICAL*RECORDS'
DCARKP ='RELATIVE*KEY*POSITION'
DCARTR ='RETRIEVED*RECORDS'
DCAUPR ='UPDATED*RECORDS'
DCAVRRDS='VARIABLE LENGTH*REL RECORD*DATA SET?'
DCOLDSET (Active Data Set Information) new variables:
DCDALLFG='ALLOCATED*SPACE*RETURNED?'/
DCDNMBFG='UNUSABLESPACE*RETURNED?'
DCDPDSEX='POSIX*FILE SYSTEM*FILE'
DCDSECFG='SECONDARY*SPACE*RETURNED?'
DCDSTRP ='STRIPED*DATA*SET'
DCDUSEFG='USED*SPACE*RETURNED?'
Additionally, if the DCOLLECT option SMSDATA is specified,
these nine new MXG datasets will have observations that
describe your SMS environment:
DCOLAG - Aggregate Group Information
DCOLBC - Base Configuration Information
DCOLDC - Data Class Construct Information
DCOLDR - OAM Optical Drive Record Information
DCOLLB - OAM Optical Library Record Information
DCOLMC - Management Class Construct Information
DCOLSC - Storage Class Construct Information
DCOLSG - Storage Group Construct Information
DCOLVL - Storage Group Volume Information
These nine new MXG datasets have been syntax checked, but
no test data has yet been made available; with 277 new
variables, I'll be surprised if it's perfect!
Change 10.304 Unexpected non-packed decimal field caused IMS log reads
ASMIMSLG program to ABEND with 0C7. After the BZ READIN02 that is
Feb 23, 1993 after the label READINPQ, insert this instruction:
OI ARRVDATE+3,X'0F'
to ensure the field is in packed decimal format.
Thanks to Jeffrey S. Crum, Ashland Oil, USA.
Change 10.303 TYPE1415 variable DSORG can be "PS" when really is "PO"
VMAC1415 and MEMBER can be blank because the IBM record is wrong.
Feb 23, 1993 If PDSs with member name specified are concatenated, the
first type 14 has DSORG='PO' and correct MEMBER name, but
the 2nd and subsequent type 14 records had DSORG="PS", and
MEMBER was blank. The DSORG was wrong because both the
JFCBORG and DCBDSORG are '40'X (PS) in the concatenation
records, instead of '02'X (PO) as is in the first record.
MEMBER is blank because MXG INPUTed it only for DSORG=PO
(the location of MEMBER contains RELGDG if it is not a PDS
and is a GDG!). Why are JFCBORG and DCBDSORG both "PS"
for a PDS? Because when the member name exists in the
JCL, OPEN treats the data set as sequential, even though
the true DSORG (in the VTOC) is still "PO"! Since IBM
will take some time to address this situation, MXG has
circumvented the problem (hopefully): If MEMBER starts
with + or -, it must be a RELGDG and MEMBER is blanked.
Otherwise, if MEMBER is non-blank, it must be a PDS, and
so MEMBER is valid and DSORG if forced to "PO".
Thanks to Herbert G. Strozinsky, Burlington Northern Railroad, USA.
Change 10.302 OPC/A data records are created as RECFM=U but test data I
VMACOPC received had been copied to RECFM=VBS, misleading me to
Feb 23, 1993 assume that RECFM=VBS had to be specified in macro _SMFOPC
defined in VMACOPC. The RECFM=VBS parameter is now removed
from VMACOPC, so MXG will read either VBS or U data, using
the RECFM in the data set label.
Change 10.301 This new report macro replicates IBM's RMF reports from
ANALRMFR MXG's TYPE70xx thru TYPE78xx datasets. In addition to
Feb 22, 1993 producing reports, the source code can be read to find out
which MXG variables are used for RMF report values. This
support includes all RMF reports except Channel and Trace,
(which will be added when there is a groundswell of user
requests, or when we feel like it, whichever comes first!)
The report syntax is self-defined in this member.
Change 10.300 Support for Empact's HiperCache product's SMF record adds
EXHIPRSA two new dataset:
EXHIPRVS HIPRSAM - Hipercache SAM data set activity
IMACHIPR HIPRVSAM- Hipercache VSAM data set activity
TYPEHIPR thanks for this significant user contribution.
VMACHIPR
Feb 22, 1993
Thanks to David Childress, Lowe's Companies, Inc, USA.
Change 10.299 RMFINTRV enhancements have added SIO75CNT (Paging SSCHs),
RMFINTRV SIO74TAP (SIOs to tape devices), and TSO2-TSO4 variables
Feb 22, 1993 SWAP,TRAN,RESP for 2nd thru 4th period TSO counts and
response time. In addition, these swap counts:
EXTAUX LOGAUX LOGEXT PHYAUX PHYEXT
and page movement rates:
HIPMIGRS HIPREADS HIPWRITS PGMIEXAU PGMVTOEX PWSSMIIN
were added to RMFINTRV from the TYPE71 dataset.
Thanks to Tom Parker, Hogan Systems, USA.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.298 PDB.PRINT dataset now contains new variable TOTLINES, the
BUILDPDB sum of PRINTLNE, PUNCHCRD, EXTWTRLN, for sites that still
BUILDPD3 have impact printers. Note that TOTLINES is the number of
Feb 22, 1993 print line images if JES2 or PSF prints line-mode data,
but if PSF prints PSF-mode data, it counts print records,
and a print record can be a single print line or it could
be a multi-page graph. Because of this, variable SHEETPRN
the actual number of sheets of paper printed, should be
used, with TOTLINES only used for impact printers under
JES. See member ACHAP31 for discussion of print charging.
Change 10.297 Support for optional HOGAN application variables was
IMACICUS updated to add new variables FPSSCRN, TCTPLD, TCBFUNC,
VMAC110 PLDVERS, and correct variables FPSOPTN and FPSTYPCD, and
Feb 22, 1993 the new variables were added to CICSTRAN KEEP= list (but,
like all the optional variables in CICSTRAN, they will not
exist unless the optional code is enabled in IMACICUS).
Thanks to Tom Parker, Hogan Systems, USA.
Change 10.296 DB2 Reports. If PMIOS05=YES was requested with PDB=SMF,
ANALDB2R and PDBOUT= was not specified, ERROR "LIBREF SMF IS NOT IN
Feb 21, 1993 A VALID FORMAT" resulted. ANALDBTR should have replaced
the earlier "paring" macros, which were the source of the
real error. Replacing the "paring" with %ANALDBTR invoked
for those pairs eliminated the error. Specifying PDBOUT=
circumvented the error. The PMACC02=YES accounting detail
in the accounting detail report and the values reported as
averages in the Buffer Pool Summary were reported
incorrectly. In addition, a 'Total Average' column was
added to be consistent with DB2PM.
Change 10.295 The variables created to identify why a plan had ended
ASUMDB2A were created but not kept because they were not in the
Feb 21, 1993 SUM= list.
Change 10.294 Support for HP's PCS data from HP/UX is extended to now
ADOCHPCS read MPE data (HP's older, proprietary operating system).
EXHPCSSP Some minor logic bugs were also corrected. Macro HPCSDLM
IMACCSSP was added to member IMACHPCS to identify the character(s)
TYPEHPCS that are to be used as field delimiters when the PCS data
VMACHPCS was created, since the delimiter is a part of the data
Feb 21, 1993 collection command. Member ADOCHPCS now contains the
specific SCOPE commands that was used to create the data
that MXG TYPEHPCS support expects. In addition, that same
ADOCHPCS member contains Chuck Hopf's fine paper on UNIX
resource measurement, "An RMF Bigots View of Measuring
UNIX Systems, or how i learned to type in lower case".
Thanks to Doug McBride, Hewlett-Packard, USA.
for patience with the untutored in this particular world of DP, and
for the data and manuals that made this enhancement to MXG possible.
Change 10.293 Support for Boole & Babbage CMF User SMF record subtypes
EXCMFCAR expanded to support essentially all subtypes; the complete
EXCMFCCS status for each subtype is listed in comments at the start
EXCMFCDS of member VMACCMF. Most of this enhancement is based on
EXCMFCJS the sample SAS code distributed with CMF, so that names of
EXCMFCOS variables and datasets are the same, but their sample code
EXCMFCPQ was architecturally revised and edited into the MXG style.
EXCMFCSC With this enhancement, these datasets are now created,
EXCMFCSS and all have been tested with real data records, too!
EXCMFC93
EXCMFDDS Subtype Dataset Description (Dataset Label)
EXCMFGDA 00 CMFDEVIC CMF 00 DEV
EXCMFJDS 00 CMFDOM CMF 00 DOM
EXCMFPDS 00 CMFIPS CMF 00 IPS
EXCMFPGS 00 CMFOBJ CMF 00 OBJ
EXCMFPDS 00 CMFPG CMF 00 PG
EXCMFUSS 00 CMFSRMC CMF 00 SRM
EXCMFWOR 00 CMFEXTCC CMF 00 TCC
VMACCMF 00 CMFEXTPG CMF 00 TPG
Feb 21, 1993 00 CMFEXTRT CMF 00 TRT
01 CMFCPUQ CPU QUEUE COUNTS
01 CMFCPUS CPU AND CHANNEL SAMPLE DATA
02 CMF02PSD ASM DATA (PAGE/SWAP DATASETS)
03 CMF03PGS PAGING DATA (SRM SAMPING)
04 CMF04WOR WORKLOAD DATA (DOMAIN SAMPLING)
05 CMF05DDS DASD DEVICE DATA
05 CMF05TDS TAPE DEVICE DATA
06 CMF06GDA JES SPOOL ACTIVITY
06 CMF06JDS JES CLASS ACTIVITY
09 CMFASMQ ASM DATA
19 CMFTRACE I/O WORKLOAD TRACE
20 CMF20CCS TSO COMMAND SUMMARY
20 CMF20CSS TSO COMMAND DETAILS
21 CMF21USS TSO USER RESOURCES
23 CMFPG0V CMF 23 PG0V
23 CMFPRIOS CMF 23 PRIOS
27 CMF27C93 CACHE SAMPLING MODEL 3990-3
27 CMF27CAR CACHE SAMPLING MODEL 3880
27 CMF27CSD CACHE SAMPLING CSD
29 CMF29COS COMMON STORAGE COS
29 CMF29CJS COMMON STORAGE CJS
29 CMF29CDS COMMON STORAGE CDS
Change 10.292 Support for IMF Release 2.8 uncovered MXG corrections:
VMACCIMS Dataset CIMSTRAN variable INPQUETM was wrong for fastpath,
Feb 20, 1993 and COREALOC is actually "Storage Available", so its label
was changed.
The IMF Release itself added these changes:
Dataset CIMSTRAN:
New variable UOWTIME is now created from existing
variable ALPCBTRN. For DBCTL, ALPCBTRN is the IMS
Transaction's Unit of Recovery, the same as the CICS
Unit of Work ID, UOWID. MXG converts the first six
bytes of ALPCBTRN into UOWTIME, the 6-byte part of
UOWID that is the constant token across all records for
the same transaction, and the token that is used to
match IMS events to their CICS and/or DB2 counterparts.
UOWTIME is always created, but is only valid when
ALPCBTRS contains a UOR. The second field CICS/DB2
field used to match transaction, NETSNAME, the name of
the originating network on which UOWTIME was created,
is not yet in the IMF transaction record.
Variable FLGSPECL now contains Q for Quick Reschedule.
New variables TRNSKW and TRNSNKW count the SYNC buffer
flush writes (Key-Writes and NonKey-Writes).
New variable APPCIMS flags APPC/IMS transactions.
Dataset CIMSDBDS: Two new counts:
DBTDDNNO='DDN*DBTNO'
DBTSECNO='SEC*DBTNO*(OVERFLOW)'
and seven new flag (status) variables:
DBTMSCNT='DBT CNTRS*OVERFLOWED?'
DBTOSSB ='OSAM*SB IN*EFFECT?'
DBTOVFLW='DBT*OVERFLOW*OCCURRED?'
DBTTYDDN='I AM A*DDNAME*DBT?'
DBTTYOTH='I AM A*CATCH-ALL*DBT?'
DBTTYSEC='I AM A*SECONDARY*DBT?'
DBTVSAM ='VSAM*ACCESS*METHOD?'
Fortunately for everyone, the new fields used existing
reserved fields, so the changes were compatible.
Change 10.291 Support for Oracle 6.0.33.1.51 added two READTIME and JOB
VMACORAC and ACCOUNTn fields, and two additional CPU time measures.
Feb 20, 1993 CPUCICTM is the CICS subtask CPU time (now added to CPUTM
as it was not previously captured). CPUXMETM is the CPU
time spent in cross memory mode in the ORACLE address
space, but as this is already captured in CPUTCBTM or
CPUSRBTM, it is not added to CPUTM; CPUXMETM lets you see
how much of CPUTM was spent in the ORACLE ASID. There is
a new section for SQLNET data, but the contributor site
did not have documentation nor data for that option. The
USER field section is added; see comments in VMACORAC on
how to keep the USER field if it exists in your data.
Thanks to Martyn A. Jones, Data Sciences UK
Change 10.290 This significant user contribution matches SLR-IMS log
TYPESLRI processing - it keeps only a subset of the statistics that
Feb 19, 1993 MXG's new ASMIMSLG produces and it uses the output of IBMs
DBFULTA0 as input for Fast Past processing, which greatly
reduced the elapsed processing time. This contribution is
documented in the author's letter at the beginning of the
member, which is actually the JCL to build a PDS with the
several members of this IMS log processing alternative.
Thanks to George Denissof, Savings Bank Services Ltd, Espoo, FINLAND.
Change 10.289 To bill tape datasets using TMS dataset DSNBRECD is built
TYPETMS5 for the first dataset on the volume by OUTPUTing the info
VMACTMS5 from the volume record, but if the first dataset on the
Feb 19, 1993 volume was SCRatched or DELeted in the catalog, MXG still
output to DSNBRECD, causing a billing charge for a "dead"
tape. Now, the observation is OUTPUT only if the dataset
is neither scratch nor deleted.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.288 Service time could still be zero, because the reset logic
TYPEIMSA had not been moved into TYPEIMSA from TYPEIMS. Lines in
Feb 19, 1993 TYPEIMSA from STRTTIME=GUTIME; thru OUTQUETM=OGUTIME...
were deleted and replaced by TYPEIMS lines from
/* TEST FOR MISSING thru RESPNSTM=ENDTIME-ARRVTIME;.
Thanks to Lonnie T. Rimmer, Philip Morris, USA.
Change 10.287 Format $MGAMDDT is no longer used (it was for an earlier
FORMATS version of Amdahl's SPMS), and has been removed.
Feb 19, 1993
Thanks to Adrian Reynolds, SAS Institute, ENGLAND.
Change 10.286 MXG 10.5 only. Variable AVGMTPTM, the average mount time
VMAC74 per TAPEMNTS (new in ESA 4.3) was incorrect. DEVMNTTM,
Feb 19, 1993 the duration when a mount was pending is added to TYPE74.
Change 10.285 Support for IBM 3495 Tape Library Dataserver Statistics
EXTY94 SMF type 94 record is added, providing hourly statistics
IMAC94 (min/max/avg counts/durations) of drives mounted, mount
TYPE94 requests pending, demounts, ejects, audit requests, and
VMAC94 the number of insert stores.
Feb 18, 1993
Change 10.284 Amdahl MDF creates TYPE70PR observations with LPARNUM=0,
ASUM70PR while the first LPAR in IBM's PRSM or Hitachi MLPF is=1.
Feb 18, 1993 ASUM70PR will produce an error message "MORE THAN 16 LPAR"
when it encountered the unexpected LPARNUM=0. Now, this
summary member supports 17 LPARs, numbered 0 thru 16!
Thanks to Jeff McFadyen, Ministry of Correctional Services, CANADA.
Change 10.283 Some fields (notably R791TCPU) are accumulated in type 79
VMAC79 records created by RMF Monitor II. However, it appears it
Feb 17, 1993 is not possible to deaccumulate the data. Using the sort
order BY SYSTEM R79SES R791ASID R791JBN STARTIME does
correctly sequence the TYPE791 dataset, but MVS/ESA 4.2.2
data contains adjacent intervals in which R791TCPU drops
rather than increases. I assume these are either step
transitions or reuse of the same ASID by the same Job in
which the CPU clock is reset, but there is no indicator of
STEPNR or JESNR in the record by which the reset can be
recognized. Furthermore, even when two intervals happen
to show an increase, it is possible that the CPU clock was
reset, but the CPU time in the second interval just
happened to be larger; in this case, if the values were
deaccumulated, the wrong CPU time would have been created.
In addition, the TYPE791 data contains accumulated counts
for page activity when the task is swapped in, but those
counts are zeros in the next record if the task is swapped
out, requiring additional investigations in the absence of
logic description from IBM as to when this occurs. Thus a
safe algorithm for deaccumulation is not possible until
IBM enhances the record and describes when fields are
zeroed and when they are not!
Thanks to Khalid Al-Harthi, Saudi Arabian Airlines, SAUDI ARABIA.
Change 10.282 This suite of RACF reports was made more user friendly by
ANALRACF removing references to &DAYNUM, and providing specific
Feb 17, 1993 example of how to set &START and &END in JCLRACFR. All
occurrences of RACFTERM $6. were changed to $8. MXG Format
MG080TY was updated with new types. PROC DATASETS were
added to delete unused work data sets, freeing DASD. Two
new members now exist: JCLRACFR executes ANALRACF
programs, and JCLPRINT prints reports created by ANALRACF.
The internal members in ANALRACF that were altered are:
JCLRACFR JCLPRINT MXGDAY1 REPRACF REPRACFB REPRACF2
REPRACF3 REPRACF4 WPDBRACF
While ANALRACF provides a lot of reports, the new TYPE80A
dataset may prove to be a better source of reporting. Much
of the logic in ANALRACF was required because MXG split
the type 80 record into multiple observations. The TYPE80A
member creates one observation per type 80 into several
datasets for improved access and reporting. Try it first!
Thanks to George Waselus, State of Arizona, Department of Admin, USA.
Change 10.281 DB2 Trace IFCID 0044 Lock fields were input incorrectly.
VMAC102 Change INPUT QW0044KL PIB1. to read
Feb 17, 1993 to read INPUT @I+8 QW0044KL PIB1.
Thanks to Jason Lau, AMP Society, AUSTRALIA.
Change 10.280 The 4th TCB (Secondary LU) CPU time was not summed into
VMAC110 CPUTCBTM in dataset CICDS, and thus it was also not in the
Feb 15, 1993 CICEODRV, CICINTRV, CICREQRV or CICUSSRV datasets.
Change 10.279 Believe it or not, there is still SMF data from VS1 being
VMAC535 created, and its type 5 record caused MXG to fail because
Feb 4, 1993 I assumed the MVS/370 service unit fields were present in
the record. Now their input is conditional!
Thanks to Don Mosley, Farmland Industries, USA.
Change 10.278 OMEGAMON/CICS V550 PTF QOC0109-DATACOM SPE- adds 16 bytes
IMACICOC to their BSC segment in the type 110 record for both CICS
IMACPTF Version 2 and CICS/ESA. This will corrupt the data in the
Feb 4, 1993 other OMEGAMON segments, as well as any user data segments
your installation might have added. And, of course, there
is no way to detect whether or not you have installed this
PTF by examining the type 110 record! As a result, you
will need to update member IMACPTF to enable _QOC0109 to
tell MXG when you have installed this OMEGAMON PTF. (Page
9 of Newsletter TWENTY-TWO discussed how to enable the
MXG Support for OMEGAMON V550.)
Thanks to Carol Harper, EG&G Idaho, USA.
Change 10.277 DCOLLECT does not capture VSAM space used. IBM Appendix E
VMACDCOL of the MVS/DFP Access Method Services For ICF documents
Feb 4, 1993 that DCDUSESP is not 'valid' for VSAM datasets. MXG's
ASMVVDS/TYPEVVDS processing, which reads the VVDSs, does
capture space allocate and space used. However, under
user pressure, IBM has announced, in ETR Item E3058,379
that DFSMS Release 1.1 (March, 1993) will add a field to
the "A" record with space used value.
Note: Change 10.305 added the new fields to "A" record,
which is output to DCOLCLUS dataset; see ADOCDCOL.
Thanks to Frank Vessell, ITT Consumer Financial Corporation, USA.
Change 10.276 Support for STOPX37 Release 3.5 added a number of new
VMACX37 variables to the STOPX37 dataset. This support has not
Feb 4, 1993 yet been tested with actual 3.4 data records.
Change 10.275 MXG 10.4-10.5. STOPOVER resulted because line 031500
VMAC73 should be SKIP=SKIP-8; instead of SKIP=LENCHDS-8;. (Note
Feb 4, 1993 that line 030800 still must be SKIP=LENCHDS-8;).
Thanks to Jim Nissen, Principal Financial Group, USA.
Change 10.274 Support for Empact's POOL-DASD user SMF record, written
EXTYPOOL whenever POOL-DASD manages an allocation. The text of the
IMACPOOL WTO messages associated with the allocation override by
TYPEPOOL POOL-DASD describes what action was taken.
VMACPOOL
Feb 3, 1993
Change 10.273 Support for Candle's IMS Transaction Reporting Facility,
EXITRDAT ITRF, is added. MXG reads the output file created by the
EXITRDB2 ITRF Batch Summary program to create these MXG datasets:
EXITRMSG ITRFMSG - Message records
EXITRMSO ITRFMSGO - Message Out records
EXITRSUM ITRFDATA - Database Records (DL1 and Fastpath)
IMACITRF ITRFSUM - Summary Records (DL1 and Fastpath)
TYPEITRF ITRFDB2 - Summary Records (DB2)
VMACITRF ITRF is a new part of Omegamon II for IMS. Its online
Feb 3, 1993 component creates an IMS log record (default ID=160) that
captures response time, CPU time, virtual storage used,
and elapsed time of DL1 and DB2 calls. That log record,
along with IBM log records 01,03,07,08,31,32,33,35,5607,
5901,5903,5936,and 5937 are the input to the ITRF Summary
program, which constructs transaction events and creates
the output file that is the input for MXG's TYPEITRF
program. Although Candle provides an option to send all
of those required IMS log records to SMF for processing
by the Summary program, this is one instance in which I
think it ill advised to use SMF because of the significant
volume of data. (If Candle ever builds a transaction
data in the online component and write a single record for
an IMS transaction, I would strongly endorsed SMF as the
correct destination for such a record!).
Change 10.272 DB2 Accounting report 2nd occurrence "GET PAGE REQUEST"
ANALDB2R is actually "BUFFERPOOL EXPANSIONS". The Average values
Feb 3, 1993 of Buffer Pool statistics are incorrect; they were divided
by the number of occurrences, then divided a second time.
(We missed this careless error because in our test data
we happened to have only one occurrence for each group!)
Finally, the "Total" column will be relabeled to indicate
it is the "Total of Averages", and a new column with the
true total has been added to the report.
Thanks to Tuomo Rahko, KOP / Kansallistieto, FINLAND.
Change 10.271 Processing Landmark's Monitor For CICS data Release 9 may
TYPEMON8 produce "INVALID DATA FOR TIESDATE" and "ERROR"INVALID DO
Feb 3, 1993 LOOP CONTROL INFORMATION", if the Landmark Dump program
does not specify CONVERT on the DUMP statement. (See their
JCL samples TMON9DBU and TMON9FSU). Without the CONVERT
operand, the dumped data is not converted to Release 8
format, which is the only data format that Landmark has
documented externally. As long as DUMP CONVERT is used,
MXG has no problem processing Release 9 data. MXG now
detects this condition and writes an error message to the
SAS log alerting you to the incorrect dumping. Landmark
has also begun shipping of Release 1.0, which has the same
data records as Release 9 (and which also requires the use
of the CONVERT option).
Thanks to Terry Baker, Royal Insurance, USA.
Change 10.270 MXG 10.2 thru 10.5 only. Invoking the READDB2 program:
READDB2 %READDB2(INFILE=SMF,PDBOUT=XXX,IFCIDS=ACCOUNT STATISICS);
Feb 3, 1993 did not write DB2ACCT,DB2STAT0,DB2STAT1 to the XXX ddname,
because the defaults defined in IMACDB2 were not changed
by READDB2. The macro definitions _DB2ACCT and _DB2STAT
were replaced by new definitions of _LDB2ACC, _LDB2ST0,
and _LDB2ST1 to correct this error.
Change 10.269 READDB2 fails with "ERROR: THE FILE WORK.T102S: WAS NOT
READDB2 FOUND" if the USER=xx option is specified, because READDB2
Feb 3, 1993 expected the selected datasets to be in the WORK file.
Thanks to Mike Marek, Kraft General Foods, USA.
Change 10.268 10.4-10.5 only. INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC28 resulted because variable LSAMINID was input twice! The
Feb 3, 1993 second occurrence in the INPUT statement must be deleted.
Thanks to Adrienne Wijlaars, Belastingdienst Automatiser, NETHERLANDS
Change 10.267 Title statements in these graphic members still contained
GRAFBNCH the options .F and .H of an ancient SAS version (82.4).
GRAFCICS The period should have been removed from both options long
GRAFVM ago!
Feb 2, 1993
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.266 DB2 Trace subtype 191 (data set T102S191) is now decoded,
VMAC102 although some of the internal diagnostic sections are not,
Jan 28, 1993 nor is this strange subtype protected if the data length
exceeds 5000 bytes. (DB2 self-limits a DB2 data block to
5000 bytes, even though the SMF record can be 32760 bytes.
When an IFCIC=191 data block exceeds 5000 bytes, DB2
inserts two-byte length fields between the blocks to
build the SMF record, but DB2 does not update the internal
offsets inside the data blocks! This will require lots of
nasty logic to either strip the length fields or to figure
out how many length fields there are and then to correct
the internal offsets to the external record locations! If
someone really needs the diagnostic sections decoded and
provides sample data, only then will I have to spend the
time to figure out how to do it!)
Thanks to Tom Parker, Hogan Systems, USA.
=Changes thru 10.265 were included in MXG PreRelease 10.5, Jan 28, 1993=
Change 10.265 Support for CA's IDMS Release 12 Performance Monitor SMF
VMACIDMS records is confirmed. It was easy, as there were no
Jan 28, 1993 changes in their SMF records!
Thanks to Roger Clayton, Cryovac Division of W.R. Grace & Co, USA.
Change 10.264 Support for NPM Release 1.6 added new values for several
EX028CM7 formats and changed the FRP, NAM, NCD, and TRI segments.
EX028LA6 New subtypes 84x,85x are output in the existing NPMINFRP
EX028LA7 dataset. Six new data sets are created:
EX028LA8 Subtype Dataset
EX028LA9 80x NPMLANET Ethernet Lan
EX028LAA A0x-A1x NPMLANOD ODLC Lan
FORMATS C3x NPMLANSG Lan Segment Utilization
VMAC028 C0x-C2x NPMCMLAN Start/Stop/Alter Lan
Jan 28, 1993 C4x-C5x NPMLANES Lan Monitor Exception
C6x-C7x NPMLANSA Lan Attach/Detach
Change 10.263 Some new TYPE71 page movement variables are rates per
VMAC71 second didn't so indicate in their label but now they do!
Jan 27, 1993 (You can always determine if a variable is a rate simply
by looking at all occurrences of the variable name in the
MXG source VMAC.... member to see if it is divided by the
interval duration.
Thanks to Bill Fife, Computer Associates, USA.
Change 10.262 Support for NETSPY Release 4.3 and LANSPY Release 1.1.
EXNSPYLD NETSPY added STOPTIME to NSPYLU, NSPVTSWD to NSPYTR,
EXNSPYLF NSPYLINE and NSPYNPSI datasets. Many new variables were
IMACNSPY added to LANSPY dataset NSPYLANL, including frame and byte
VMACNSPY counts for LLC, NetBios, IP, IPX, XNS, DEC, LAT, LAVC, ARP
Jan 27, 1993 X.25, AppleTalk, NCP, SMB, VINES, NFS, FTP, ICMP, Telnet,
Feb 20, 1993 Broadcast, Multicast, and SNA over Ethernet! Counts of
frames and bytes were also added to NSPYLANS. New dataset
NSPYLAND captures internetwork delays. Member EXNSPYLF
controlled outputting of dataset NSPYLANF by testing
IF SUM(a,b,c) THEN OUTPUT ..., which created observations
only if the sum was non-zero, but two users were puzzled
why it did not read IF SUM(a,b,c) GT 0 THEN OUTPUT...,
so to avoid unnecessary puzzlement, it now uses GT 0!
(Without the GT 0, the OUTPUT is executed if the sum is
non-zero; since the a,b,c values were input as PIB4, they
could never be negative, and there was no logic exposure,
but it is more accurate and user friendly to use GT 0!)
Feb 20. New Path Entry Layout for Extended Subtype D LAN
SPY records was coded, and several incorrect lengths were
revised. No data for testing yet available.
Change 10.261 Support for MVS/ESA 4.3. These variables were added:
BUILDPDB Dataset Variable Description
IMACPDB TYPE23 SYNCTIME - Datetime value when the SMF Global
RMFINTRV TYPE30_V Recording Interval ended (the STATUS
VMAC23 TYPE70xx function). This value is put into
VMAC26J2 thru other SMF and RMF records so the data
VMAC30 TYPE79xx can be matched exactly! However, the
VMAC32 new SYNCTIME includes the GMT offset,
VMAC33 so if you have a non-zero value for
VMAC42 TIMEZONE= in SYS1.PARMLIB(CLOCKxx),
VMAC60 SYNCTIME will be in GMT while all the
VMAC6156 other timestamps will be in the LOCAL
VMAC71 time zone! And, the GMT offset value
VMAC73 is not provided in these records!
VMAC76 You Synchronize SMF and RMF records
VMAC77 with the SYNCVAL and INTVAL values
Jan 28, 1993 in the SMFPRMxx member of parmlib.
Feb 9, 1993 TYPE26J2 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 event
OFFLPURG - Flag that this purge record was due
to Spool Offload event, and is not
the actual purge event. (This flag
requested only last year, is now used
in BUILDPDB to solve the problem
described in Change 9.243.
TYPE30_V New INTBTIME and INTETIME values are added to
the ID section, and INTETIME is now the end of
the Interval (previously, INTETIME was taken from
SMFTIME, which could be later than the actual end
of the interval). If a task is swapped out at
the end of the interval, a record is not written
until the task is swapped back in, and SMFTIME is
much later than INTETIME. The INTBTIME/INTETIME
values are actually on the GMT clock, but because
the old interval begin time (SMF30IST) remains on
the local clock, the GMTOFFTM can be determined
so that INTBTIME and INTETIME are converted to
local time (like all the other type 30 times).
Variable SYNCTIME is the GMT value of INTETIME
that will match SYNCTIME in type 23 and type 70s,
for matching synchronized SMF and RMF intervals.
SMFTIME was also added to TYPE30_V data set. Data
set TYPE30_V becomes the PDB.SMFINTRV data set.
Also, DSSIZHWM was converted to bytes and format
with MGBYTES format.
TYPE33_1 Now contains JOB READTIME and STEPNAME.
TYPE33_2 New APPC/MVS dataset contains resources at the
conversation level, particularly needed if you
uses 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.
TYPE42SR New DFSMS data set provides response statistics
for each Storage Class for each interval:
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
TYPE42DS New DFSMS data set provides response statistics
for each Data Set, with same statistics as in the
TYPE42SR (above), with additional details.
TYPE60 Existing field SMF60SUB/SMF61SUB which explained
TYPE6156 if the VVR or ICF Catalog record was UPDATED or
INSERTED or DELETED is now "Erroneous Field. Do
Not Use", with no alternative field!
TYPE70s Variable SYNCTIME was added to all RMF datasets
for synchronization with SMF records. See above.
Additionally, all RMF datasets have new variable
INTRVSYN=Y if synchronization is 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; now MXG only OUTPUTs
TYPE73 observations if the CHPID is ONLINE.
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. Since TAPEMNTS now exists, the duration
of Mount Pending, DEVMTPTM is also now created.
If a Mount is Pending (MTP) at the beginning or
the ending of the interval, variables MTPATBET
and MTPATEND are "Y". Only if MTP does not exist
at either the begin or end will MXG calculate the
average mount pending per tape mount per device,
new variable AVGMTPTM.
(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.)
TYPE76 SAMPSKPD variable if samples were skipped
TYPE77 SAMPSKPD variable if samples were skipped, and
WAITS was PIB2., is now moved to a PIB4. field at
the end of the record.
TYPE792 R792EXCP was expanded to four bytes and moved to
the end of the record.
TYPE79C New variables R79FLAG, R79CPBY, 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.
TYPE96 The new type 96 record was already supported in
MXG 10.3, as TYPETIRS, for this record is created
to account for "The Integrated Reasoning System"
users resource usage. However, the name in the
SMF manual for type 96 is "Cross Memory Service
Provider Charge Back", is inaccurate; it's TIRS!
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 TYPE71 CPUPAGTM is added to RMFINTRV as a
separate variable, and is also included in CPUTM,
the sum of all captured CPU time; this will cause
and increase in the capture ration of RMF.
Change 10.260 Negative CPUACTTM and PCTCPUBY in TYPE70 under PR/SM can
VMAC7072 occur if the LPARNUM for the PHYSICAL partition segment is
Jan 24, 1993 non-zero and equal to a real LPARNUM value. The LPARNUM
for the PHYSICAL partition should always be zero, but at a
few sites it was erratically non-zero (which also caused
RMF reports to fail!). IBM APAR OY55704 and PTF UY87723
acknowledge and fix the problem, but MXG now protects the
data by inserting:
IF LPARNAME='PHYSICAL' THEN LPARNUM=0;
following the @; which follows the INPUT of LPARNUM.
Thanks to Tom Hatcher, US Sprint Dallas, USA.
Thanks to MP Welch, US Sprint Dallas, USA.
Change 10.259 There are now always 255 CHPID segments in type 73 record
VMAC73 even though there might not be 'FF'X CHPIDs defined in the
Jan 24, 1993 system. Now, MXG only outputs TYPE73 observations if the
CHPID is defined. APAR II06736 discusses this problem and
suggested two possible algorithms; the above is the second
algorithm in that APAR (beware - there are typo's in the
1st algorithm - Reference to SMF73FGS should be SMF73FG3,
and the bit field names SMF73REP and SMF73VLD do not exist
in the SMF manual - due to OCO!).
Thanks to John Mattson, National Medical Enterprises, USA.
Change 10.258 Variable QW0023DN was not kept in dataset T102S023, which
VMAC102 caused a warning when using ANALDB2R report PMTRN01. It
Jan 23, 1993 is reserved, and should not have been referenced in the
report, but the better fix was to now keep it!
Thanks to Andre Henry, AG 1824, BELGIUM.
Change 10.257 MXG RMF/CMF processing has been enhanced to validate that
VMAC7072 each section actually exists in the physical record. The
VMAC71 previous validation only checked that the section offset
VMAC73 and number of sections was non-zero, but did not protect
VMAC74 for truncated records nor for unexpected invalid records.
VMAC75 Now, if a bad record is encountered, a message will be
VMAC76 printed on the SAS log, the bad record deleted, but the
VMAC77 processing will continue, avoiding the STOPOVER abend!
VMAC78
VMAC79
Jan 23, 1993
Thanks to Phil Hathaway, Spartan Stores, USA.
Change 10.256 SMF type 70 INPUT STATEMENT EXCEEDED RECORD LENGTH occurs
IMACTCP with IBM's TCP/IP SMF record because the IBM sample member
Jan 22, 1993 used record ID of 70! IBM APAR PN34837 addresses this bad
choice, and IBM has now assigned SMF record numbers 118
and 119 to the TCP/IP product SMF records. MXG has thus
changed its default values in IMACTCP to agree with this
IBM correction. To delete the unwanted TCP/IP records,
you can add this code to member IMACFILE:
IF ID=70 AND LENGTH LE 194 THEN DELETE;
until you get the ID of TCP/IP records corrected.
Change 10.255 ICF Catalog cells C4x and C9x were not printed because
VMAC6156 the test prior to their PUT statements tested for 'C4' or
Jan 14, 1993 'C9' (without the X indicator to test for hex value!). New
Feb 17, 1993 variables DATANAME/DATAVOL1 and INDXNAME/INDXVOL1 for VSAM
entries contain the VSAM Data Component name, First Data
VOLSER, Index Component name, and First Index VOLSER. New
variables DATACLAS, MGMTCLAS,and STORCLAS are non-blank
if the Optional SMS Subcell for a Cluster record is found.
Thanks to Steve Dzielak, First Interstate Bank of Arizona, USA.
Change 10.254 Dates last referenced and expiration in TTOC section of
VMXGHSM HSM BCD/MCDS records were wrong. Replace these lines:
Jan 14, 1993 TTOCDLR PD3.
+1 TTOCEFLG PIB2.
TTOCXPDT PD3.
@;
and the subsequent lines that reference TTOCDLR/TTOCXPDT
with these lines:
TTOCDLR1 PIB1.
TTOCDLR2 PIB2.
+1
TTOCEFLG PIB1.
TTOCXPD1 PIB1.
TTOCXPD2 PIB2.
@;
TTOCDLR =TTOCDLR1*1000+TTOCDLR2;
TTOCXPDT=TTOCXPD1*1000+TTOCXPD2;
Unrelated, the line formatting TTOCTYP $HEX2. should be
deleted, as this is an EBCDIC field.
Thanks to Chris Fenn, Andersen Consulting, ENGLAND.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
Thanks to John Dalton, SAS Institute, ENGLAND.
Change 10.253 QW0022OS, the DB2 optimizer's cost estimate, was supposed
VMAC102 to have been changed by Change 10.174, but the code was
Jan 14, 1993 not changed until now. Sorry for this carelessness!
Thanks to Matthew Bildstone, Sun Life, ENGLAND.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
Change 10.252 A spelling error; the "by incrd" in the AXIS2 statement
GRAFLPAR should have been "by &incrd", as incrd is a macro variable
Jan 14, 1993 and was missing the ampersand.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
=Changes thru 10.251 were included in MXG PreRelease 10.4, Jan 8, 1993==
Change 10.251 Preliminary revised support for RACF & TOPSECRET type 80
EXTY8001 SMF record. The original TYPE80 data set built by MXG is
EXTY8002 valid, but it is unwieldy for analysis, as it creates one
EXTY8003 observation for each data segment in each type 80 record,
EXTY8004 and left the decoding of the RACFDATA string to you! This
EXTY8005 revision recognizes that each type 80 record represents an
EXTY8006 event, and the data segments for each event should be kept
EXTY8007 in a single observation. Instead of one TYPE80 dataset,
EXTY80A the new logic creates nine datasets; seven for each RACF
EXTY80CM event category, (TYPE8001-TYPE8007), TYPE80CM for RACF
IMAC80A Commands, and TYPE80A in case records with no segments are
TYPE80A encountered. The data segments in the TYPE80CM Command
VMAC80A dataset are not decoded in this implementation, but the
Jan 7, 1993 command and its issuer, etc., are decoded. Some variables
may be formatted, and some revisions are likely, but the
initial testing suggests that reporting and selection of
RACF data will be much easier with this revision. The 7
event categories and their new dataset names are:
TYPE8001 Job Initiation or TSO Logon
TYPE8002 Resource Access
TYPE8003 End of Volume
TYPE8004 Rename Data Set
TYPE8005 Scratch Dataset or Tape Volume
TYPE8006 Delete Volume one of Multi-Volume
TYPE8007 Define Data Set or Tape Volume
TYPE80CM RACF Commands Issued
TYPE80A Catchall for records with no data segments
Thanks to Joe Faska, Depository Trust, USA
Change 10.250 Twenty-five more ADOC members (Documentation members, one
ADOCx for each "Product" which described all data sets that MXG
Jan 7, 1993 creates from that product data records) have been added.
Most contain sample PROC PRINTs, but not all are fully
completed. However, when an ADOC member exists, it is the
first place to look for notes and contents of MXG datasets
Each ADOC member corresponds to a Section of Chapter 40.
Change 10.249 Existing formats MG080EV, MG080IA, MG080QU, and MG080TY
FORMATS were updated for new values for RACF 1.9.
Jan 7, 1993
Change 10.248 VMXGSUM is enhanced with the SUMLONG function, which is
VMXGSUM the same as the SUM function, but stores the results in an
Jan 7, 1993 8-byte field instead of a 4-byte field. This is rarely a
problem with performance/capacity data, but in chargeback
applications with large dollar amounts, pennies could be
lost with only 4-byte stored variable lengths.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.247 The ESCON Multi-Image Facility (EMIF) Feature for MVS/ESA
VMAC73 4.2.2 added 8 bytes to each CHPID section in type 73 SMF
Jan 6, 1993 record, but MXG failed to skip over the new fields, which
caused alternating good and invalid observations, and MXG
had good records only for the first 128 CHPIDs! As best
as I can discover, there was no TNL to the SMF Manual for
this IBM change! The correction is to insert xx lines as
shown in the following corrected code (note this is the
last PCHANBY input, at the bottom of VMAC73);
exists PCHANBY PIB4. /*SMF73BSY .... */
exists @;
insert SKIP=LENCHDS-8;
" IF SKIP GT 0 THEN DO;
" INPUT SMF73PBY PIB4.6 /*CHANPATH*BUSY TIME*SINCE LAST*/
" SMF73PTI PIB4.6 /*CHANPATH*MEASUREMENT*INTERVAL*/
" @;
" SMF73PBY=1024*SMF73PBY; /* CVT FROM 1024 USEC UNITS */
" SMF73PTI=1024*SMF73PTI; /* CVT FROM 1024 USEC UNITS */
" SKIP=SKIP-8; /*this line is now correct in this change */
/*and in VMAC73, but in 10.4 and 10.5 it */
/*was wrong (SKIP=LENCHDS-8;) in both! */
" IF SKIP GT 0 THEN INPUT +SKIP @;
insert END;
exists IF CHANIND ='..1.....'B THEN CHANTYPE='BLOCK MUX';
Thanks to Linda Lokkesmoe, West Publishing Company, USA.
Change 10.246 IBM's type 36 record has the subtype bit on, indicating
UTILGETM the record contains a subtype in bytes 19-20, but the
VMACSMF subtype is an EBCDIC 00 (hex F0F0) instead of hex 0000,
Jan 9, 1993 and UTILGETM threw the record away. Now, when an invalid
subtype value is found, a message is printed on the log,
and INDEXST=1 is set so that the record will be written.
VMACSMF was also changed to input type 36's subtype as an
EBCDIC number. This change was revised after MXG 10.4.
An "ARRAY SUBSCRIPT OUT OF RANGE" can occur with MXG 10.4;
the statement SUBTYPE=1; should have been INDEXST=1.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 10.245 Support for Legent's ASTEX Trace Record. This data is not
EXTYASXT an SMF record, but is sent to a flat file that must be
IMACASXT first uncompressed by a Legent-provided program and then
TYPEASXT decoded by these MXG members. See the comments in member
VMACASXT VMACASXT, which includes the JCL example for the two-step
Jan 5, 1993 process. (Note that the SMF record created by ASTEX has
been supported for years by MXG members VMACDMON, named
DMON in MXG because it used to be DASDMON).
Thanks to John Rosza, Depository Trust Company, USA.
Change 10.244 Support for VM/ESA 2.0 creates five new data sets:
EXSYTCUM VXSYTCUM - LPAR Management time by Physical CPU
EXSYTCPM VXSYTCPM - Channel Path Busy by CHPID
EXPRCCFN VXPRCCFN - ADD access to CRYPTO facility
EXPRCCFF VXPRCCFF - REMOVE access to CRYPTO facility
EXIODALS VXIODALS - 3495 Automated Tape Library Statistics
VMACVMXA (only partially decoded, awaiting 3495 manual
Jan 4, 1993 because that's where the record is documented)
Perhaps of more importance, VM/ESA 2.0 added a number of
new variables to several datasets:
VXAPLSRV - 25 new counters now exist
VXIODDEV - new measure SCDATIM "Device Active-Only time"
VXMTRDDR - IBM no longer spans across physical blocks!
VXMTRDEV - RDEVSHAR if device is shared
VXMTRPAG - FBA if device is FBA
VXMTRPRP - PFXIDVER identifies CPU model version number
in this and other CPU-related datasets.
VXSYTUSR - SYSDIALD/SYSLUCNT for dialed/SNA connected
users, and flag in VXUSEATE/VXUSELOF/VXUSEACT
and VXUSELOF data sets.
VXUSELOF - Major enhancement adds resources consumed to
the existing (but previously useless) LOGOFF
event record so that it now describes the
resources used by each CMS machine session.
Not only resources (CPU, SSCH, Reserved Pages)
but now a session logon time CALTODON, RACF
group VMCGRPN, and user accounting number
(only 8-bytes!) VMDACTNO make this a much more
attractive source of session-level resources
for accounting and capacity planning.
This description only hits the highlights. The complete
list of new variables is given in member DOCVER10 for the
data sets beginning with VX - twenty five MXG data sets
have new variables!
This code has been tested with real VM/ESA 2.0 data that
was provided by IBM (with my sincere thanks!), but it did
not contain any of the new record types, so not all of the
code has been tested!
An existing error in MXG 10.1 was also corrected; the
second occurrence of "MACRO _MSTOASS ..." should have
been ASI instead of ASS in three places in that line.
This error caused a 180 syntax error.
Change 10.243 As noted on page 10 of MXG NEWSLETTER TWENTY-TWO, SAS ZAP
VMXGVTOC V6-SYS-FILE-4673 (on June 1992 Usage Notes Tape) is needed
Dec 29, 1992 for SAS 6.07 to avoid "CRITICAL ERROR IN VTOC" messages.
Change 10.242 Archaic SAS 5.18 produces syntax error with TPX data due
DIFFTPX to incorrect parsing, but the error can be circumvented by
Dec 29, 1992 re-ordering the PROC SORT to read:
PROC SORT NODUP %VMXGFOR DATA= _LTPXINT ;
Thanks to Mike Marek, Kraft General Foods, USA.
==Changes thru 10.241 are included in Dec 13, 1992 MXG PreRelease 10.3A=
Change 10.241 The JCLMNTH example did not contain the //SOURCLIB DD
JCLMNTH concatenation, and the %INCLUDE SOURCLIB(MONTHBLD); which
Dec 17, 1992 should have been the last line of SAS code was missing.
Thanks to Barry Lampkin, Polaroid, USA.
Change 10.240 SMFSMALL step JCLTEST6 may produce "ARRAY OUT OF RANGE"
UTILGETM error with SMF record types of 127, 128 or 255, depending
Dec 16, 1992 on subtype value, because the index calculation was wrong.
INDEX=(ID+1)*256+SUBTYPE; must be INDEX=ID*256+SUBTYPE+1;
and ELSE IF ID LE 128 ... must be ELSE IF ID LE 127 ....
Thanks to Tom Gillis, Southern National Bank, USA.
Change 10.239 ASTEC variable RDMT must be input as PIB4. vice PIB4.6,
VMACDMON and the statement RDMT=RDMT*128; must be deleted, as the
Dec 16, 1992 units are seconds, not 128 microseconds. Variables
RDTBK1 thru RDTBK4 must be input as PIB4.2 vice PIB4.
Thanks to Chris Nielsen, Wells Fargo Bank, USA.
Change 10.238 VM/ESA 2.0 MONWRITE data causes SFM-OR-CRR SAMPLE message
VMACVMXA and then PROBABLE DATA LOSS message if you have enabled
Dec 15, 1992 the Application Server data. (The MXG protection for new
APL data was incorrectly coded.) Change the line reading
SKIP=SKIP-CALDATLN-8;
to these two lines:
INPUT +SKIP @;
SKIP=0;
With this change, MXG tolerates VM/ESA 2.0 MONWRITE data
records without error, skipping over the new fields and
records. MXG will exploit VM/ESA (i.e., decode new data)
shortly; work is in progress.
Change 10.237 The message when you had more than 9 account fields is
IMACACCT now only printed five times, and the text was made more
Dec 15, 1992 clear.
Thanks to Ann Wheeler, American President Lines, USA.
Change 10.236 All occurrences of PIBR. should have been PIB4. I thought
VMACM204 this one had been fixed, but it slipped through into 10.3!
Dec 15, 1992 This causes FORMAT PIBR unknown during JCLTEST6 execution.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
==Changes thru 10.235 are included in Dec 13, 1992 MXG PreRelease 10.3==
Change 10.235 Existing graphic reports were enhanced in GRAFLPAR when
GRAFLPAR is executed under SAS 6.07 or later using PROC GPLOT with
Dec 13, 1992 filling colors in place of PROC GCHART with bar charts, as
we exploit SAS 6.07 features.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.234 MXG processing message when MXG detects use of EXCLUDE in
VMAC110 CICS records is enhanced by printing a table of expected
Dec 13, 1992 values of Data Length and Number of Fields (MCTSSDRL and
MCTSSDCN) in the MXG error message to help you compare the
actual and expected values. This has been the number one
technical problem in MXG CICS record processing this year
sites CICS person installed a CICS monitor which excludes
fields, but the MXG person doesn't find out until MXG runs
against the modified data! The new error text should help
resolve the error without additional phone calls!
Change 10.233 Variables USER, SQLUSER & SQLDBMAC were added to VMSQLxx
TYPEVM datasets. SQLDBMAC is the full name of the SQL database
Dec 13, 1992 machine (and is stored in from USER after line 028200).
SQLUSER is TERM in VMSQLTRM, is SYSTEM in VMSQLSYS, and is
INIT in VMSQLINI, but it has meaning in VMSQLUSR where it
is taken from the connect process and is sometimes a
different user. USER is always SQL/DS in the -INI, -SYS,
and VMSQLTRM datasets, and at present useless, but it is
kept for consistency and possible future changes by IBM!
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.232 APPC type 33 account record header offsets were off by 6
VMAC33 bytes (the subtype and length of header were omitted). The
Dec 13, 1992 offsets for OFFPROD thru NRTPUS in lines 68-76 must have 6
added to each value. Additionally, the TP name field is
variable length, with a maximum of 64 bytes, so it is now
input conditionally:
SMF33TPL PIB2. @;
IF SMF33TPL GT 0 THEN
INPUT TPNAME $VARYING64. SMF33TPL @;
Thanks to Robin Luff, Dun & Bradstreet Europe, ENGLAND.
Change 10.231 Support for Velocity Software's XAMAP history data files.
EXXAMCPB MXG creates several datasets from the four history files.
EXXAMCPT This code has been tested with actual XAMAP data records
EXXAMDEV and reviewed for reasonableness, but there are many fields
EXXAMSYS and lots of code!
EXXAMUSR See comments at the beginning of VMACXAM for instructions
IMACXAM for processing the four XAMAP files.
TYPEXAM Jul, 2003: EXXAMSYS, EXXAMTCP, EXXAMUSR members were
VMACXAM removed in MXG 21.03 as multiple datasets
Jan 4, 1993 are now created from those XAM data.
Change 10.230 Boole & Babbage CMF type 78 record variable R783PT-number
VMACCMF of times channel path was taken- is in error in CMF 4.3.3
Dec 11, 1992 until you install Boole's fix BAB1081.
Thanks to Bill Stoneberg, National-Oilwell, USA.
Change 10.229 STC 4400 SMF record variable LSBECON1/2 documentation was
VMACSTC incorrect; these are not connect durations but rather are
Dec 11, 1992 the LSM number and Panel number, and they are six bytes
instead of four bytes! They are now input $CHAR6., format
$HEX12., and were removed from the IF test for OUTPUT of
STCLMU dataset. Also, variable LSMNUMBR is created.
Thanks to Dean Ruhle, J.C. Penny, USA.
Change 10.228 MXG summarization of TYPE70PR assumed Effective Dispatch
ASUM70PR time was in TYPE70PR, but sites without the APAR or sites
Dec 1, 1992 with MDF (which does not yet record Effective Dispatch)
ended up with LPAR management time equal to LPAR dispatch
time. Delete the sixteen lines which set LPnUEDTM=0, and
the overhead time will be zero/missing instead of wrong!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.227 SAS 6.07 no longer supports the XSWISS font name, so all
ANALVARY occurrences of XSWISS were changed to SWISS. This change
DOCGRAF works with SAS 6.06, 6.07, 6.08 and later. However the
GRAFBNCH SWISS font name is not supported in SAS 5.18, so if you
GRAFCICS are still on 5.18, you must change SWISS back to XSWISS
GRAFRMFI in these SAS/GRAPH examples.
GRAFVM
Dec 1, 1992
Thanks to Jim Border, Packaging Corporation of America, USA.
Change 10.226 The MXG Tape Mount Monitor has been modified to recognize
ASMTMNT the MIM Pseudo Mount event (see Change 10.200), to create
a TMNTRTRN value of 3 when the Pseudo event is recognized.
Dec 1, 1992 This change has been tested in a non-MIM shop, but the MIM
site tests have not been completed to verify that in fact
a record with TMNTRTRN=3 is created. Please verify!
Change 10.225 The BY list for the WEEK.ASUM70PR dataset should not have
WEEKBLD variables LPARNAME LPARNUM, as these variables don't exist
Dec 1, 1992 in the summarized ASUM70PR dataset.
Thanks to Wayne Bell, National General Insurance, USA.
Change 10.224 JES3 TYPE84 INPUT STATEMENT EXCEEDED RECORD LENGTH error.
VMAC84 a. Remove the line containing +4 immediately following
Dec 1, 1992 JMFJSMXJ $CHAR8. ....
b. Three lines later, change LOCJSOF=LOCJSOF+76; to read
LOCJSOF=LOCJSOF+72;
This MXG error uncovered two other IBM errors. JMFGSNUM
is zero, but there is a GMS/MDS summary entry present,
but the zero causes MXG to not input the entry. Also
noted, R84JSNAM has two leading blanks for DSP names.
These are being reported to IBM for repair.
Thanks to Ellen Ulrich, Texas Instruments, USA.
Change 10.223 Change 10.138 changed ELSE IF MONITOR='JCL' THEN DO; to
VMACROSC ELSE IF MONITOR='JCL' OR MONITOR='JCK' THEN DO; but only
Nov 17, 1992 in one line. The 2nd occurrence needed to be changed also!
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.222 SIMWARE support missed two undocumented bytes, apparently
VMACSIM added for alignment. After the INPUT of VUXBPGRM $CHAR20.
Nov 17, 1992 insert a line with +2 to skip the extra bytes.
Thanks to Mike Roybal, First National Bank in Albuquerque, USA.
Change 10.221 DCOLLECT disk capacity dataset DCOLCAPD variable UCTOTAL
VMACDCOL contains the volume capacity in Kilo-bytes in the DCOLLECT
Nov 16, 1992 record, but was documented as tracks! MXG now multiplies
UCTOTAL by 1024 (to convert Kilo-bytes to bytes) and then
added UCTOTAL to the list of variables formatted MGBYTES
so that the capacity will print 601M for a 3380 (that has
615,472 Kilo-bytes, or 630,243,328 bytes capacity.
Thanks to Frank Vessell, ITT Consumer Financial Corporation, USA.
Change 10.220 VMPRF for VM/ESA now counts a user as "ACTIVE" if either
VMACVMXA the user consumed some virtual CPU time (VMDVTIME GT 0),
Nov 13, 1992 or the user was not in the Dormant List at the end of the
monitor interval (VMDSLIST NE '0B'X). MXG formerly used
only the CPU test to count ACTIVE users, but now the test
for ACTIVE has been expanded to include the VMDSLIST test.
Note, however, that the whole issue of counting VM users
is questionable, since the interval over which the count
is taken completely controls the number of "ACTIVE" users.
This site examined VXBYUSR with different intervals:
5-min interval active count in the 150 range
15-min interval active count in 240-440 range
30-min interval active count in 700-800 range
Thanks to Anne Schroeder, Amway Corporation, USA.
Change 10.219 IDMS DBKDBKEY was incorrectly documented by CA. Instead
VMACIDMS of the DB Key in four bytes, the key is only the first 3
Nov 12, 1992 bytes, and the fourth byte is the DBKEY Line Index. MXG
now inputs DBKDBKEY as PIB3, and creates the new variable
DBKDBINX as the fourth byte.
Thanks to Sal Fazzino, General Electric Capital Corporation, USA.
Change 10.218 MXG 10.2 only. In adding new variables to support LPARS
ASUM70PR 9 thru 16 (for Amdahl MDF), several variables were not
Nov 11, 1992 properly RETAINed due to spelling errors, causing the
ASUM70PR dataset to be corrupted - the effective dispatch
times LPxUEDTM and its associated LPAR management time
LPxMGTTM will be missing except in the last LPAR, and this
caused CPUOVHTM and PCTOVHD to also be incorrect. The
total Partition Dispatch Time, LPxUPDTM, fortunately, was
not affected, so it is possible you may have not noticed
this error. Once you make this change, you should rebuild
ASUM70PR in each PDB that was created by MXG 10.2, by
allocating the //PDB DD DSN=dsname,DISP=OLD, and then
%INCLUDE SOURCLIB(ASUM70PR) to rebuild ASUM70PR. The
correction is to look at the end of the RETAIN statement,
and correct the spelling so that there are four sets of
sixteen variables, each with names LPxUPDTM LPxUEDTM
LPxNRPRC and LPxMGTTM, where x=1,2,...,8,9,A,B,C,D,E,F,G.
Another minor correction, the 2nd occurrence of LPDMGTTM
in the TIME12.2 statement should be LPGMGTTM, and four
lines earlier, LPDUEDTM should have been LPGUEDTM.
Thanks to Ron Kopfer, First Interstate Bank of Arizona, USA.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.217 MXG 10.2 only. MXG Tape Mount Monitor was changed in 10.2
ASMTMNT to default to MVS/ESA, but the SYSPARM parsing was not
Nov 2, 1992 updated, which caused an ASM error if you specify TEST in
SYSPARM (to write the records to a flat file). The parse
logic values are now changed to read:
AIF (K'&SYSPARM LT 7).NOSYS
&ESA SETB ('&SYSPARM'(5,3) EQ 'ESA')
AIF (K'&SYSPARM LT 12).NOTEST
&TEST SETB ('&SYSPARM'(9,4) EQ 'TEST')
AIF (K'&SYSPARM LT 16).NONUM
&C SETC '&SYSPARM'(14,3)
Change 10.216 CICS Version 2 Global Performance Record wasn't protected
VMAC110 for EXCLUDE logic, and a record with excluded fields could
VMAC110M cause MXG to ABEND with INPUT STATEMENT EXCEEDED RECORD
Nov 2, 1992 message. Additional testing logic should now prevent this
ABEND and alert you that EXCLUDE was used in the CICS MCT.
Thanks to Ron Kirk, Union Carbide, USA.
Change 10.215 NPM Release 1.5.1 added six new subtypes, causing "INPUT
EX028EV6 STATEMENT EXCEEDED RECORD LENGTH" error. That error can
EX028EV7 be circumvented by replacing both occurrences in VMAC28 of
EX028INE ELSE IF 21X LE NPMSUBTY LE 35X THEN ....
VMAC28 with
Oct 30, 1992 ELSE IF 21X LE NPMSUBTY LE 25X OR
31X LE NPMSUBTY LE 35X THEN ....
Subtypes 26x,27x,28x,29x are session monitor exception and
exception resolution events for applications, nodes, LUs&
LU groups, and create new datasets NPMEVSAA and NPMEVSAL.
(It was the unexpected fall-thru by a NPMSUBTY=26x record
that caused the MXG ABEND.) Subtypes 82x and 83x report
interval frame relay resources in new dataset NPMINFRP.
IBM really blew this change. While the June, 1992 "TNL"
SH19-6835 supplement to SC31-6835 (the NPM "SMF" manual)
described the new records, the supplement was not SLSS'd
to anyone, so it took an MXG user to ABEND to alert me to
call one of the two remaining NPM IBM'ers in the USA (NPM
is now developed in Rome), who was able to fax me the six
critical pages to add the support the next day, but IBM
Publications is still researching why I didn't
automatically get the change so that it could have been in
Newsletter 22 last summer!
Thanks to Adrienne Wijlaars, Belastingdienst Automatiser, NETHERLANDS
Change 10.214 DFSORT Release 12 added new fields describing Hiperspace
VMAC16 and Data Space usage, PROC Step name, input and output
Oct 28, 1992 DSNs and their first VOLSER, performance group number, the
average record length, and flags if HIPERSORT, DATASPACES,
and/or Work Datasets were used. Additionally, counts of
records and bytes in and out that were previously 4-bytes
were relocated and expanded to 8 bytes.
Change 10.213 ABEND A78-RU FREEMAIN-can create type 30 SMF record with
VMAC30 incorrect INITTIME and REND (Reader End) timestamps. IBM
Oct 28, 1992 is aware but has no fix at present. The INITTIME contains
the initiator start time (not the step start time), and
REND contains the initiator start completion time (not the
end of Read-in), and hence in this defective record the
INITTIME is less than REND! (Note that INITTIME can be
less than READTIME, because READTIME is taken where the
job originally read-in, and with NJE that could be in a
different time zone!). These incorrect time stamps can be
detected and corrected with this circumvention to set an
INITTIME closer to the truth!
IF . LT INITTIME LT REND THEN DO;
INITTIME=DHMS(DATEPART(SMFTIME),0,0,LOADTIME);
IF INITTIME GT SMFTIME THEN INITTIME=INITTIME-86400;
END;
Part of this problem has been reported to IBM under APAR
OY27665 (1989!), which has no PTF and was "CLOSED - SUG",
meaning its only a suggestion to the developers!
Thanks to J. G. Vlietstra, Ultramar Canada, CANADA.
Change 10.212 New variables SPMSCTST and SPMSXSQN are created, and old
FORMATS variables SPMSEL1,EL2,SL1,SL2,SL3 were deleted, and format
VMACSPMS MGAMDCS and MGAMDDT were added to decode SPMSCTST,SPMSDTYP
Oct 27, 1992 respectively. This completes Change 10.069.
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 10.211 DB2 Trace variable QW0145OB in dataset T102S145 has value
VMAC102 of QW0145DB; statement QW0145OB=QWX145DB should have been
Oct 26, 1992 QW0145OB=QWX145DB. Variables QW0141TX,QW0142TX,QW0145TX
are now input as $VARYING200 (were only 100) to be same as
the SQL text field in the other audit trace records.
Thanks to Jorn Fledelius, Kommunedata I/S, DENMARK
Change 10.210 Several DB2STAT0 & DB2STAT2 variables were deaccumulated
DIFFDB2 that should not have been. (Because IBM often fails to
Oct 26, 1992 identify whether fields are accumulated or not, only real
data values can prove to DIF() or not to DIF(). Most of
these fields are from Distributed DB2, and only now do we
have test data with non-zero values with which to validate
accumulation.)
DB2STAT0 variables which must be removed from DIFFDB2:
QWSBSACT QW2BSACT QW3BSACT QW4BSACT QW5BSACT
DB2STAT1 variables which must be removed from DIFFDB2:
QB1TWFM QB2TWFM QB3TWFM QB4TWFM
QDSTQDBT QISEKT QISESKPT QISTRCUR QTCURPB QTPUBDD
QTSLWDD and all QLST fields: QLSTABRR QLSTABRS
QLSTBRBF QLSTBROW QLSTBTBF QLSTBRBF
QLSTBROW QLSTBTBF QLSTBYTR QLSTBYTS QLSTCBLB QLSTCNVQ
QLSTCNVR QLSTCNVS QLSTCOMR QLSTCOMS QLSTMSGR QLSTMSGS
QLSTROWR QLSTRBND QLSTROWS QLSTSQLR QLSTSQLS QLSTTRNR
QLSTTRNS
Thanks to Warren E. Waid, JC Penny, USA.
Change 10.209 Variables A17FLOC and A17FNAM were not in the KEEP= list
VMAC110 for the CICFCR statistics dataset.
Oct 19, 1992
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 10.209A New variable PCTRDYWT was not in the KEEP= list for the
VMAC7072 TYPE70 dataset.
Oct 19, 1992
Thanks to Tom Elbert, John Alden Life Ins, USA.
==Changes thru 10.208 are included in Oct 18, 1992 MXG PreRelease 10.2==
Change 10.208 Something is wrong with this archaic member, for it now
VMXGVTOC has "UNINITIALIZED VARIABLE" messages that I could not
Oct 18, 1992 resolve in time for building this tape, but since MXG
strongly recommends the use of ASMVTOC/VMXGVTOF instead
of this old technology, I hoped this warning is enough!
Change 10.207 All of the MACRO _Txxxyyy definitions should have started
VMAC102 with DATA _Vxxxyyy but the "DATA" was missing. The JCL
Oct 18, 1992 example showing how to use the _Txxxyyy macros will now
execute correctly!
Thanks to Merlin Beeching, Nuclear Electric, ENGLAND.
Change 10.206 WEEKBLD and MONTHBLD were updated so that all of the PDB
WEEKBLD datasets created by the JCLPDB6 example are copied into
MONTHBLD your WEEKly and/or MONTHly PDB libraries. Note that it
Oct 18, 1992 is definitely NOT my recommendation that you build all of
these datasets monthly:
I do recommend that you create all of the WEEKBLD
datasets in your WEEKly PDB, but only build MONTHly the
PDB datasets that you need for monthly reports; often
only the PDB.JOBS, PDB.STEPS, PDB.PRINT and
PDB.RMFINTRV datasets are needed to feed monthly
billing validation. This is especially true if you
have implemented the TREND database and have weaned
your management from monthly to WEEKLY trending (as
exemplified by the MXG report examples in Chapter 42 of
the 1984 MXG Guide!).
However, so you don't have to rummage around in BUILDPDB
or ASUM members to find the MXG Sort Order, they've all
been added so you can comment out the datasets you don't
want created. That's safer and easier for both of us!
The BUILDPDB-created PDB datasets that were added were
PDB.TYPE72MN, PDB.NJEPURGE, PDB.TYPETMNT, & PDB.TYPE0203,
and the ASUM.... PDB Summary datasets PDB.CICS,
PDB.ASUMDB2A, PDB.JOBSKED, PDB.ASUM70PR, and PDB.TAPEMNTS,
which are built by their corresponding ASUM.... member
ASUMCICS, ASUMDB2A, ASUMJOBS, ASUM70PR, ASUMTMNT, have
also been added. Do check your USERID.SOURCLIB for an
EXPDBWEK member you might have added to do some of this
yourself, and avoid duplication!
If you do use MONTHBLD, make sure you use the JCL example
in JCLMNTH instead of the earlier JCL still in JCLMONTH.
JCLMNTH needs only one tape drive to create your monthly
PDB from your dailies and weeklies, and runs much faster.
It does require more temporary DASD space than the old
example, but the saving in tape drives AND tape mounts
is substantial with JCLMNTH. Everyone who has tried it
has kept on using it in production.
Change 10.205 IMS log variable NMSGPROC, IMSTRAN is wrong, but only in
TYPEIMSA MULTRANS='Y' observations, where it should have been set
Oct 17, 1992 back to 1, since a total of NMSGPROC observations will be
created by the MERGE logic. Insert NMSGPROC=1; after the
MULTRANS='Y'; statement to correct the value. Users report
correct response times and faster run times with the IMS
"Appended" Log processing, and it is so much better that
MXG sites MUST use ASMIMSLG/JCLIMSLG/TYPEIMSA instead of
the old TYPEIMS member for IMS log processing.
Thanks to Lonnie T. Rimmer, Philip Morris, USA.
Change 10.204 IBM Changes to OPC records cause INVALID RECORD messages.
IMACOPC There appear to be two different versions of records from
VMACOPC OPC, but IBM did not update the Record Version Number in
Oct 17, 1992 the record, so there is a new _OPCVER macro in IMACOPC to
tell which version to expect. I don't know right now what
OPC version is which, but there are only two choices, a 0
for the old and a 1 for the new format. Try one, and if
it doesn't work, try the other. This text will be revised
when I know more, but the software has been tested with
data from both versions. The changes were the addition of
MT0JVT $16 after MT0OCC, MTDOPTS2 $1 after MTDOPTS, and
+2 after MTDDIATM (but only for MTDTYPE=9), and SPLITLEN
was changed from 71 to 36. One MXG error was found. The
test IF 8 LE MT0TYPE LE 9 should have tested MTDTYPE!
This site also discovered that the records in the EQQTROUT
file with record type of 01, 02, or 03 appear to be copies
of the Current Plan, but have not yet found description
of the format, nor an acknowledgement of the discovery!
Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Change 10.203 Early 10.2 support for Candle's Omegamon II for VTAM V150
VMACOMVT failed with real data records; I gambled and lost when I
Oct 13, 1992 sent a few sites an Early 10.2 before the test data from
Candle finally arrived. The support has now been tested
and the real 10.2 (this one) does support that product.
However, as with all new product support, use with caution
and validate your own data values.
Change 10.202 A blank line in the Early 10.2 choked the ASSEMBLER that
ASMVTOC is fixed in this 10.2. However, ASMVTOC may not work with
ASMVTOCO MVS/ESA 3.1.3; Matt found it executed instantaneously and
Oct 13, 1992 wrote no records on his 3.1.3 system while it worked find
Oct 17, 1992 on his 4.2 system. Apparently the ESA 4.2 enhancement in
10.1 is the culprit, but since the MXG 9.9 version has no
problem with MVS/370 thru MVS/ESA 4.1, I have put the old
MXG 9.9 version of ASMVTOC in member ASMVTOCO for you old
timers!
Thanks to Matt Gallion, Tenneco, USA.
Change 10.201 Boole & Babbage CMF under MVS/ESA 4.2 contains incorrect
VMAC78 triplet R783CPDN in type 78 subtype 3 record, causing MXG
Oct 16, 1992 to create zero observations in the TYPE78CF dataset.
Field R783CPDN (MXG variable NRCPDS), the number of I/O
queueing data sections, is 4 but there are 8 sections in
the record! The length of SMF78DCS (MXG variable LENDCS)
does include those extra 4 sections, so while I believe
CMF should be fixed, it turns out that by a simple change
in MXG "SKIP" logic (the logic to protect for any future
data which might be added, and which had been "faked out"
by the incorrect value), MXG can support this CMF record
and simultaneously protect both CMF and RMF for this new
way of adding unused data segments to type 78 records!
(To Boole's credit, they looked at MXG logic, as they are
also an MXG customer, diagnosed the source of the zero
observations, and gave the MXG site an MXG circumvention
that is part of this change, even before they called me!)
Find the following lines in VMAC78 (note EXCLUDEed lines):
OFFCPDS PIB4.
LENCPDS PIB2.
NRCPDS PIB2.
@;
SKIP=LENDCS-(12+NRCPDS*LENCPDS);
IF SKIP GT 0 THEN INPUT +SKIP @;
DO _II_ =1 TO NRCPDS;
- - - - 39 line(s) not displayed -
END; /* END DO TO NRCPDS */
END; /* END DO TO NRDCSLCU */
and make it look like the following by move and insert:
OFFCPDS PIB4.
LENCPDS PIB2.
NRCPDS PIB2.
2nd: @;
these new lines ==> SKIP=OFFCPDS-12;
were changed ==> IF SKIP GT 0 THEN INPUT +SKIP @;
after copy DO _II_ =1 TO NRCPDS;
- - 39 line(s) not displayed - -
1st: END; /* END DO TO NRCPDS */
these old lines ==> SKIP=LENDCS-(12+NRCPDS*LENCPDS);
were copied ==> IF SKIP GT 0 THEN INPUT +SKIP @;
from above END; /* END DO TO NRDCSLCU */
Boole & Babbage now have PTFs BPM4428/BPM4428 to correct
the original error.
Thanks to Norvell Reeves, Boole & Babbage, USA.
Change 10.200 Legent's MIM product causes the MXG Tape Mount Monitor to
ADOCTMNT write a record with non-zero return code when MIM replies
TYPETMNT "WAIT" or "NOHOLD" to some allocation recovery events.
VMACTMNT
Oct 17, 1992 YOU MUST USE ONLY THE OBSERVATIONS WITH TMNTRTRN=0
TO COUNT AS TAPE MOUNTS IN A MIM ENVIRONMENT, OR AT
LEAST DISCARD MOUNTS WITH TAPMNTTM LESS THAN 5 SECONDS.
MIM manages tape drives across systems by "Plugging"
values into the UCB, and by propagating UCB status bit
values to all systems. MIM "allocates" all drives and
then doles them out to your jobs as needed. One of the
bits plugged by MIM is the Mount Pending, or MTP, bit. For
every allocation recovery scan event (each time a drive is
deallocated while jobs are in allocation recovery), MIM
intercepts messages and replies WAIT,NOHOLD for each job
that didn't get that device, and sends new UCB status bits
for that device to all sharing systems. MXGTMNT sees the
MTP bit change on these other systems, thinks a mount
event was seen and missed, and writes an SMF record,
setting a non-zero Return Code value in TMNTRTRN
(accidentally, a 1 for NOHOLD, a 2 for WAIT) for these
non-mount mount events.
Change 10.226 attempts to recognize these MIM non-mount
events (the UCBASID to zero and the UCB Allocated Bit is
On), and sets TMNTRTRN=3 for them, but that change has NOT
been validated, and one non-MIM site saw valid mounts with
TMNTRTRN=3, so you must verify. Since the minimum mount
time for a real tape mount is 5 seconds, I suggest that
you discard any TYPETMNT mount record with TAPMNTTM LT 5.
Further investigation is planned, and hopefully these MIM
pseudo-mount events can be explicitly identified.
As a result of this investigation, I have finally written
the long overdue documentation of the MXGTMNT monitor and
the datasets created from its SMF records, in the member
ADOCTMNT. Please review it for complete information.
Thanks to Ted Anderson, Kaiser Permanente, USA.
=Changes thru 10.199 were included in MXG PreRelease 10.2, Oct 12, 1992=
Change 10.199 MXG Installation instructions have been revised and are
INSTALL now contained in member INSTALL. JCL to allocate the MXG
JCLINSTL libraries (two source PDS, a SAS data library of FORMATS)
Oct 11, 1992 is contained in JCLINSTL. The references to SAS 5.18 have
been removed, and the philosophy of installation slightly
changed, as described in INSTALL and above in this member.
This is work still in progress, as the rewriting of the
MXG documentation begins in ernest!
Change 10.198 Execution under SAS 5.18 required several changes.
DIFFDB2 Although MXG Strongly recommends execution under SAS 6.07,
VMACOPC for those of you still struggling with Version 5 (you are
VMACAIM6 either still running MVS/370 or are you think you are too
VMACQAPM swamped to take a half-day to install SAS 6.07), MXG still
Oct 11, 1992 executes under SAS 5.18! Only TYPEQAPM (AS400 support)
is known to fail under 5.18 (it uses 6.07-only formats).
a.VMACOPC and VMACAIM6 were written using IN (1,2) logic,
but that syntax was not a part of 5.18, so the IN (,)
logic was replaced with OR logic.
b.DIFFDB2 initially failed under SAS 5.18 because its parser
failed on PROC SORT NODUP DATA=_LDB2ST0 %VMXGFOR; syntax!
Moving the %VMXGFOR to after the NODUP allowed 5.18 to
successfully execute. (This is really strange, because
there are numerous other PROC SORT statements with very
similar structure that did not fail!)
Change 10.197 Variable DEVCLASS has been added to TYPE74 so reports
VMAC74 for DASD (DEVCLASS=20X) or for TAPE (DEVCLASS=80X) can be
Oct 7, 1992 generated without a list of all devices in a class.
Change 10.196 TMS datasets have been enhanced to provide both capacity
TYPETMS5 measures and billing measures for tapes & tape data sets.
VMACTMS5 Dataset TMS contains one observation for each tape volume
Oct 7, 1992 with the count of files on that tape and the TAPEFEET for
that volume, and contains the DSNAME of only the first
data set on that tape volume. TMS is thus useful for the
capacity measurement of your tape library. The major part
of this change was to enhance dataset DSNBRECD so that it
now contains one observation for each tape data set with
the attributes and correct TAPEFEET for that dataset.
(Previously, DSNBRECD contained observations for only the
second and subsequent data sets on tape - the first data
set information was in TMS. Now, the data set information
from the first (and maybe only) data set in TMS has been
added to DSNBRECD so ALL of your tape data sets can be
billed directly from DSNBRECD.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.195 Accounting summary report now has DDF headings suppressed
ANALDB2R if there is no Distributed data, and null values for one
Oct 7, 1992 of the SORTBY variables now prints "BLANK" vice a blank.
The owning and wanting plan were reversed in the Lock
Suspension Trace, and that report is now named the Lock
Contention Trace.
Change 10.194 Support for OMEGAMON II FOR VTAM V150 user SMF record.
EXOMVEXC Seven datasets are created from the record's subtypes:
EXOMVTBU OMVTEXCE - Exception Events
EXOMVTCT OMVTTBUF - Trend Interval Buffers
EXOMVTET OMVTTCTC - Trend Interval CTCs
EXOMVTLC OMVTTETE - Trend Interval End-to-End Response
EXOMVTNC OMVTTLCL - Trend Interval Local Controllers
EXOMVTVR OMVTTNCP - Trend Interval NCP
IMACOMVT OMVTTVRF - Trend Interval VRs
TYPEOMVT Code has been syntax checked, but no test records were
VMACOMVT provided by Candle as yet for validation.
Oct 7, 1992
Change 10.193 STC 4400 SILO HSC (subtype 7) SMF record variables have
VMACSTC been FORMATed, and some $CHAR1. variables were changed to
Oct 6, 1992 PIB1. numeric variables. New variables STC07FPS/STC07TPX
are created and contain the volume in the same format as
the MVS System (LSM ID, Panel, Row, Column display as
000:00:00:00.) Specifics:
- Variables changed from $CHAR1. to PIB1. in their INPUT
statement, and given format Z2. are these:
STC07SAC STC07SPN STC07SRO STC07SCO
STC07TAC STC07TPN STC07TRO STC07TCO
- Variables changed from $CHAR1. to PIB1. in their INPUT
statement, and given format Z3. are these:
STC07SLS STC07TLS
- Variables added to format statement as shown:
STC07FPS STC07TPS $12.
STC07TYP STC07RQS STC07FLG $HEX2.
STC07DRS STC07DRT HEX4.
- New variables created:
STC07FPS=PUT(STC07SLS,Z3.)!!':'!!PUT(STC07SPN,Z2.)!!
':'!!PUT(STC07SRO,Z2.)!!':'!!PUT(STC07SCO,Z2.);
STC07TPS=PUT(STC07TLS,Z3.)!!':'!!PUT(STC07TPN,Z2.)!!
':'!!PUT(STC07TRO,Z2.)!!':'!!PUT(STC07TCO,Z2.);
Thanks to Lou Sassani, National Australia Bank, AUSTRALIA.
Change 10.192 Variables SYSTEM SMFTIME weren't kept in dataset ROSCOSOR
VMACROSC ROSCOPUR,ROSCOHEX,ROSCOCON,ROSCOATT,ROSCOALL,ROSCOSHU,
Oct 6, 1992 ROSCOVPE, and ROSCODSR, but now they are.
Thanks to Willie Antman, Federal Deposit Insurance Corp., USA.
Change 10.191 "Appended" IMS Log processing was enhanced with new logic
ASMIMSLG to test for and locate the RACF segment in the IMS 01/03
Oct 6, 1992 record. Before this change, it was possible that the RACF
variables would have had wrong values.
Thanks to Engelbert Smets, Provinzia Versicherungsanstalten, GERMANY.
Rheinprovinz.
Thanks to Jeffrey S. Crum, Ashland Oil, USA.
Change 10.190 JES2 errors (APAR OY56235) create truncated timestamp
BUILDPDB values for TYPE26 variables JSTRTIME and JENDTIME. These
BUILDPD3 values are compared with TYPE30_5 variable JINITIME in the
IMACTIME BUILDPDB/BUILDPD3 logic to decide whether to SPIN or not.
Oct 6, 1992 Since IBM has not yet fixed their truncation problem, the
macro _TIMEDIF defined in IMACTIME previously used only in
JES3 BUILDPD3 has been added to JES2 BUILDPDB so that the
decision can be externalized without modification to the
BUILDPDB member. The default value for _TIMEDIF is zero,
but if you experience problems (i.e., your SPIN library
fills because of the JES2 error, and few jobs are put in
PDB.JOBS), you should change the default to 10 seconds,
as described in the comments in IMACTIME. The new logic
to decide to SPIN or not to SPIN using _TIMEDIF is now:
IF IN26 AND IN30_5 AND
(JSTRTIME-_TIMEDIF) LE JINITIME LE (JENDTIME+_TIMEDIF)
THEN OKFLAG=1;
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 10.189 Variables TOTMEMR and OTH0MEMR were accidentally left out
RMFINTRV of the FORMAT statement for the other ....MEMR variables
TRNDRMFI in RMFINTRV. In the INCODE= logic in TRNDRMFI, compiler
Oct 6, 1992 "faker" statements (IF OTH0xxxx=. THEN OTH0xxxx=.;) for
OTH6-OTH0 variables were deleted. They were added to avoid
the UNINITIALIZED VARIABLE message between MXG 6.6 and MXG
7.7 (when these new variables were added), but now only
caused confusion as to why they were there!
Thanks to Tom Elbert, John Alden Life, USA.
Change 10.188 Change 10.020 correctly circumvented LENGTH problem in
EXITMONI Landmark records, but the actual cause of the zero value
Sep 28, 1992 is corrected by changing the line reading
MVC 0(2,R1),=H'0' RECORD LENGTH IS MEANINGLESS
to read
MVC 0(2,R1),F$NXTLNG+2
Thanks to Trevor Holland, Bank of Melbourne, AUSTRALIA.
Change 10.187 Change 10.110 mislocated an INFILE & FORMAT statement in
VMACQAPM the new X.25 section, which surfaced as "SYSTEM ABEND 0C4
Sep 28, 1992 OCCURRED OUTSIDE OF THE SAS ENVIRONMENT" on the SAS log.
Change 10.186 Support for XEROX printer SFS "Status File System" data.
ADOCSMS XEROX Printers have always created data records on print
EXTYSFS workstations, but now that data is somewhat more usable,
IMACSFS because you can now capture the MVS JOB and JESNR fields.
VMACSFS This will require your XEROX person to make some changes
TYPESFS to the XEROX software driving the printer, as described
Sep 28, 1992 in member ADOCSFS.
Then, getting the SFS data records from the XEROX printer
to the mainframe may require floppy disk or non-labeled
tapes or communications packages, depending on the
configuration of a particular printer.
You typically cannot use PDB.PRINT for XEROX printer
cost recovery, because JES counts in the TYPE6 record
only what JES sent to the printer, not what was
actually printed; JES may send only one copy, but the
printer can print 100 copies, and only the SFS
Accounting record will tell you what was really
printed. Now it can tell by whom, too!
The ability to process the TYPESFS dataset and merge it
with your PDB.JOBS dataset to pick up accounting data now
makes the XEROX SFS data worth generating and transporting
over to MVS for XEROX printer workstation accounting.
Unfortunately, XEROX does not yet include the data
needed for accurate printer throughput analysis (see
ANALPRTR) and there is still no way to get the MVS
accounting fields put in the SFS data records.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.185 Change 10.060 was not completely correct. If the first of
VMACTMS5 two DSNBs was inactive, the statement IF DSNBACTV='Y';
Sep 24, 1992 that was added by 10.060 caused the next DSNB to be lost!
That statement must be deleted. The statement
IF VOLSER GE 'A' THEN OUTPUT DSNBREC;
must be changed to read
IF VOLSER GE 'A' AND DSNBACTV='Y' THEN OUTPUT DSNBREC;
so only the active DSNBs are output.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.184 Support for IBM's TCP/IP Version 2 Release 2 SMF records.
ADOCTCP The Telnet Server writes a record for each Logon or Logoff
EXTYTCP event; a different SMF record number can be assigned for
IMACTCP each event, but only one record number for both events is
TYPETCP needed/recommended, as MXG will create one observation in
VMACTCP dataset TYPETCPT for each event record which identifies
Sep 24, 1992 which event. The FTP Server writes a record for each
APPEND/DELETE-MDELETE/LOGIN fail/RENAME/GET-MGET/PUT-MPUT
event; like the Telnet Server, a different record number
can be assigned for each event, but only one record number
for all FTP events is needed/recommended, as MXG will
create one observation in dataset TYPETCPF for each event
record which identifies which FTP event. These records
and their installation is described in TCP/IP V2 R2
Planning and Customization, SC31-6085-01.
Thanks to Fred Toro, Lever Bros. Co, USA.
Thanks to Kurt Karlsen, NIT, NORWAY.
Thanks to Oystein J. Blix, Etrinell.
Change 10.183 DB2 Statement Number type 102 trace records are decimal
ANALDB2R values, but some MXG datasets stored them as $CHAR2. with
VMAC102 a $HEX4. format. Now, all statement numbers are decimal
Sep 24, 1992 values, to agree with DB2PM and the catalog information.
Thanks to Dave Leeker, Southwestern Bell, USA.
Change 10.182 Omegamon V550 ESRA (user) SMF record subtype 101 caused
VMACOMCI INPUT STATEMENT EXCEEDED RECORD LENGTH. Immediately before
Sep 24, 1992 "INPUT ESRES1..." insert "IF SUBTYPE NE 101 THEN" (that
header segment does not exist in the subtype 101). After
input of SYSEGS PIB4., insert @; SMSEGO=SMSEGO=3;INPUT
(this subtype had not occurred in earlier test data).
Thanks to David Ehresman, University of Louisville, USA.
Change 10.181 Support for IBM type 96 SMF record from The Integrated
ADOCTIRS Reasoning Shell, TIRS. An observation is created in the
EXTYTIRS TYPETIRS dataset, containing session times, CPU time used
IMACTIRS (both vector and CPU), interactions and ABEND codes for
TYPETIRS each time the TIRS subsystem replies or queries the user.
VMACTIRS This has been coded but not tested with data.
Sep 24, 1992
Thanks to Bill Stoneberg, National-Oilwell, USA.
Change 10.180 Support for SIMWARE SIM/XFER VTAM user SMF record added.
ADOCSIM For each user transfer session, an observation is created
EXTYSIM in TYPESIM dataset, reporting session times and the amount
IMACSIM (bytes and blocks) of data sent and received.
TYPESIM
VMACSIM
Sep 24, 1992
Thanks to Mike Roybal, First National Bank in Albuquerque, USA.
Change 10.179 TYPE73 variable ESCACVC (flag that an ESCON converter is
VMAC73 attached to this CHPID) was never set to "Y" because it
Sep 24, 1992 was misspelled as ESONCVC in one line. Corrected spelling.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.178 Support for Hewlett-Packard Performance Collection System
ADOCHPCS Now available from HP, the PCS product for HP/UX operating
ANALHPRS system creates 4 records from which MXG builds 6 datasets:
ASUMHPCS HPCSAPPL - Application resources by interval
EXHPCSAP HPCSCONF - Configuration at startup of PCS
EXHPCSCO HPCSDISK - Disk activity by device by interval from GLOB
EXHPCSDI HPCSGLOB - Global activity by interval
EXHPCSGL HPCSLANS - LAN activity by LAN by interval from GLOB
EXHPCSLA HPCSPROC - Process activity by process by interval
EXHPCSPR It is quite encouraging that Hewlett Packard recognizes
IMACHPCS the need to instrument its UNIX platform and now offers
JCLHPCS the PCS product to manage HP UNIX systems.
TRNDHPCS
TYPEHPCS
VMACHPCS
VMACHPCS
Sep 23, 1992
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 10.177 Sites still on MVS/XA will need to use ASMTMNTO to create
ASMTMNT the MXG tape mount monitor, as it will assemble under XA.
Sep 23, 1992 (The "real" monitor in ASMTMNT uses MVS/ESA-only macros to
support dynamic device additions).
Change 10.176 NETVIEW FTP SMF record timestamps aren't SMFSTAMP8 format
VMACFTP but have DATE preceding TIME. (Its not standard format,
Sep 23, 1992 but it ain't illegal!) Replace all eleven lines with:
xxxxxxxx SMFSTAMP8.
with these five lines:
DATE PD4.
TIME PIB4.2
@;
IF DATE GT 0 THEN xxxxxxxx=DHMS(DATEJUL(DATE),0,0,TIME);
INPUT
Thanks to Herr Timmermanne, Preussen Elektra, GERMANY.
Change 10.175 Powerful new "_L" 7 "_K" macros are now defined for each
all of MXG MXG dataset, allowing you to completely tailor individual
Sep 22, 1992 datasets. You can now ADD or DROP variables, write the
dataset to a specific DD (libref), add dataset compression
for specific datasets, change BUFSIZE, or even change the
name of the MXG dataset! This MAJOR revision to the MXG
architecture greatly enhances the flexibility and control
for the future. The usage of this new design is described
in the second part of this change. The first part of this
change discusses the incompatibility of the design.
1. INCOMPATIBILITY of the new "_L" macros. These nineteen
IMACs have been changed INCOMPATIBLY:
IMACCICS IMACCIMS IMACCMF IMACDB2 IMACDCOL IMACHSM
IMACIMS IMACINTV IMACMONI IMACNSPY IMACOPC IMACPDSM
IMACROSC IMACSTX IMACTPX IMACZRB IMAC30DD IMAC40DD
IMAC434D
If these IMACs are in your USERID.SOURCLIB, you MUST
make the changes described below, or your job will ABEND!
Prior to MXG 10.2, those IMACs defined old-style macros
which set the DDNAME to which certain MXG datasets were
written. In the new "_L" architecture, these IMACs define
both the DDNAME and DATASET names in one "_L......" macro.
For example, IMACICS defined MACRO _CICTRAN CICSTRAN %
(which was used with DATA _CICTRAN.CICSTRAN syntax) so
that the CICSTRAN dataset was written to the CICSTRAN DD.
Now, IMACCICS defines MACRO _LCICTRN CICSTRAN.CICSTRAN %
(which is now used with DATA _LCICTRN syntax) so that
the CISTRAN dataset is still written to the CICSTRAN DD.
For each IMAC listed above that is in your USERID.SOURCLIB
library, you MUST copy the new 10.x IMAC member into your
MXG.V1010.USERID.SOURCLIB, and set the DDNAME part of the
new "_L" macro definition to the DDNAME value from your
old IMAC member.
The following table lists the old and new macro definition
(with the MXG default value) for each of the IMACs that
were incompatibly changed:
IMAC: Old DDNAME macro: New "_L" ("Library") macro:
IMACCICS MACRO _CICACCT PDB % MACRO _LCICACC PDB.CICSACCT %
MACRO _CICEXCE PDB % MACRO _LCICEXC PDB.CICSEXCE %
MACRO _CICTRAN CICSTRAN% MACRO _LCICTRN CICSTRAN.CICSTRAN%
MACRO _CICYSTM PDB % MACRO _LCICSYS PDB.CICSYSTM %
MACRO _CICEOD PDB % MACRO _LCICEOD PDB.CICEODRV %
MACRO _CICINT PDB % MACRO _LCICINT PDB.CICINTRV %
MACRO _CICREQ PDB % MACRO _LCICREQ PDB.CICREQRV %
MACRO _CICUSS PDB % MACRO _LCICUSS PDB.CICUSSRV %
IMACCIMS MACRO _IMFTRAN WORK % MACRO _LIMFTRN WORK.CIMSTRAN %
MACRO _IMFDBDS WORK % MACRO _LIMFDBD WORK.CIMSDBDS %
MACRO _IMFDB2 WORK % MACRO _LIMFDB2 WORK.CIMSDB2 %
MACRO _IMFPROG WORK % MACRO _LIMFPGM WORK.CIMSPROG %
IMACCMF MACRO _CMF19DD PDB % MACRO _LCMFTRA PDB.CMFTRACE %
IMACDB2 MACRO _DB2ACCT PDB % MACRO _LDB2ACC PDB.DB2ACCT %
MACRO _DB2STAT PDB % MACRO _LDB2ST0 PDB.DB2STAT0 %
MACRO _DB2STAT PDB % MACRO _LDB2ST1 PDB.DB2STAT1 %
IMACDCOL MACRO _DCOLDSN WORK % MACRO _LDCODSN PDB.DCOLDSET %
MACRO _DCOLCLU WORK % MACRO _LDCOCLU PDB.DCOLCLUS %
MACRO _DCOLVOL WORK % MACRO _LDCOVOL PDB.DCOLVOLS %
MACRO _DCOLMIG WORK % MACRO _LDCOMIG PDB.DCOLMIGS %
MACRO _DCOLBKP WORK % MACRO _LDCOBKP PDB.DCOLBKUP %
MACRO _DCOLCPD WORK % MACRO _LDCOCPD PDB.DCOLCAPD %
MACRO _DCOLCPT WORK % MACRO _LDCOCPT PDB.DCOLCAPT %
IMACINTV No macro is defined in this member, and it is unlikely that
this member would cause a problem, but where it used to be
OUTPUT TYPE30_V; it now needs to be OUTPUT _LTY30UV; just
to be consistent with the new architecture.
IMAC30DD No macro is defined in this member, and it is unlikely that
this member would cause a problem, but where it used to be
OUTPUT TYPE30_D; it now needs to be OUTPUT _LTY30UD; just
to be consistent with the new architecture.
IMAC40DD No macro is defined in this member, and it is unlikely that
this member would cause a problem, but where it used to be
OUTPUT TYPE40_D; it now needs to be OUTPUT _LTY40UD; just
to be consistent with the new architecture.
IMACMONI MACRO _MONDBDS WORK % MACRO _LMONDBD WORK.MONIDBDS %
MACRO _MONHIST WORK % MACRO _LMONHIS WORK.MONIHIST %
MACRO _MONMRO WORK % MACRO _LMONMRO WORK.MONIMRO %
MACRO _MONSYST WORK % MACRO _LMONSYS WORK.MONISYST %
MACRO _MONTASK WORK % MACRO _LMONTSK WORK.MONITASK %
MACRO _MONUSER WORK % MACRO _LMONUSR WORK.MONIUSER %
IMACOPC MACRO _OPC20 WORK % MACRO _LOPC20 WORK.OPC20 %
MACRO _OPC23 WORK % MACRO _LOPC23 WORK.OPC23 %
MACRO _OPC24A WORK % MACRO _LOPC24A WORK.OPC24D_A %
MACRO _OPC24B WORK % MACRO _LOPC24B WORK.OPC24D_B %
MACRO _OPC24C WORK % MACRO _LOPC24C WORK.OPC24D_C %
MACRO _OPC24D WORK % MACRO _LOPC24D WORK.OPC24D_D %
MACRO _OPC24E WORK % MACRO _LOPC24E WORK.OPC24D_E %
MACRO _OPC24F WORK % MACRO _LOPC24F WORK.OPC24D_F %
MACRO _OPC24G WORK % MACRO _LOPC24G WORK.OPC24D_G %
MACRO _OPC241 WORK % MACRO _LOPC241 WORK.OPC24_1 %
MACRO _OPC242 WORK % MACRO _LOPC242 WORK.OPC24_25 %
MACRO _OPC246 WORK % MACRO _LOPC246 WORK.OPC24_6 %
MACRO _OPC247 WORK % MACRO _LOPC247 WORK.OPC24_78 %
MACRO _OPC25 WORK % MACRO _LOPC25 WORK.OPC25 %
MACRO _OPC26 WORK % MACRO _LOPC26 WORK.OPC26 %
MACRO _OPC27 WORK % MACRO _LOPC27 WORK.OPC27 %
MACRO _OPC28 WORK % MACRO _LOPC28 WORK.OPC28 %
MACRO _OPC29 WORK % MACRO _LOPC29 WORK.OPC29 %
MACRO _OPC30 WORK % MACRO _LOPC30 WORK.OPC30 %
MACRO _OPC31 WORK % MACRO _LOPC31 WORK.OPC31 %
MACRO _OPC32 WORK % MACRO _LOPC32 WORK.OPC32 %
MACRO _OPC33 WORK % MACRO _LOPC33 WORK.OPC33 %
IMACPDSM MACRO _PDSMDD WORK % MACRO _LTYPDSM WORK.TYPEPDSM %
IMACROSC MACRO _ROSCDDN WORK % - unchanged at present.
IMACSTX MACRO _STXINT WORK % - was defined, but never
referenced in MXG.
IMACTPX MACRO _TPXINT WORK% MACRO _LTPXINT WORK.TPXINTRV %
It is remotely possible that you may have used the old
syntax in your report/analysis program, and if so, you
may encounter syntax errors. The following table lists
the old and new syntax for each possible macro that might
cause syntax errors.
Previous syntax Must be replaced by syntax
_CICACCT.CICSACCT _LCICACC
_CICEXCE.CICSEXCE _LCICEXC
_CICTRAN.CICSTRAN _LCICTRN
_CICYSTM.CICSYSTM _LCICSYS
_CICEOD .CICEODRV _LCICEOD
_CICINT .CICINTRV _LCICINT
_CICREQ .CICREQRV _LCICREQ
_CICUSS .CICUSSRV _LCICUSS
_IMFTRAN.CIMSTRAN _LIMFTRN
_IMFDBDS.CIMSDBDS _LIMFDBD
_IMFDB2 .CIMSDB2 _LIMFDB2
_IMFPROG.CIMSPROG _LIMFPGM
_CMF19DD.CMFTRACE _LCMFTRA
_DB2ACCT.DB2ACCT _LDB2ACC
_DB2STAT.DB2STAT0 _LDB2ST0
_DB2STAT.DB2STAT1 _LDB2ST1
_DCOLDSN.DCOLDSET _LDCODSN
_DCOLCLU.DCOLCLUS _LDCOCLU
_DCOLVOL.DCOLVOLS _LDCOVOL
_DCOLMIG.DCOLMIGS _LDCOMIG
_DCOLBKP.DCOLBKUP _LDCOBKP
_DCOLCPD.DCOLCAPD _LDCOCPD
_DCOLCPT.DCOLCAPT _LDCOCPT
_MONDBDS.MONIDBDS _LMONDBD
_MONHIST.MONIHIST _LMONHIS
_MONMRO .MONIMRO _LMONMRO
_MONSYST.MONISYST _LMONSYS
_MONTASK.MONITASK _LMONTSK
_MONUSER.MONIUSER _LMONUSR
_OPC20 .OPC20 _LOPC20
_OPC23 .OPC23 _LOPC23
_OPC24A .OPC24D_A _LOPC24A
_OPC24B .OPC24D_B _LOPC24B
_OPC24C .OPC24D_C _LOPC24C
_OPC24D .OPC24D_D _LOPC24D
_OPC24E .OPC24D_E _LOPC24E
_OPC24F .OPC24D_F _LOPC24F
_OPC24G .OPC24D_G _LOPC24G
_OPC241 .OPC24_1 _LOPC241
_OPC242 .OPC24_25 _LOPC242
_OPC246 .OPC24_6 _LOPC246
_OPC247 .OPC24_78 _LOPC247
_OPC25 .OPC25 _LOPC25
_OPC26 .OPC26 _LOPC26
_OPC27 .OPC27 _LOPC27
_OPC28 .OPC28 _LOPC28
_OPC29 .OPC29 _LOPC29
_OPC30 .OPC30 _LOPC30
_OPC31 .OPC31 _LOPC31
_OPC32 .OPC32 _LOPC32
_OPC33 .OPC33 _LOPC33
_PDSMDD .TYPEPDSM _LTYPDSM
_TPXINT .TPXINTRV _LTPXINT
2. Usage of the new "_L" and "_K" macros to tailor datasets.
For each MXG dataset, an "_L" ("Library") macro and an
"_K" (Keep) macro is now defined in the product's IMAC.
For example, these IBM Type 0 SMF record product's macros
are now defined in member IMAC0:
MACRO _LTY0 TYPE0 %
MACRO _KTY0 %
The naming convention for the "_L" and "_K" macros use
the same suffix as the dataset's "EX" (Exit macro). The
"EX" members names have one of these forms:EXTYnnnn,
EXTYaaaa, EXTYxxyy, EXxxxyyy or EXxxyyyy, where xx/xxx
is the product acronym and yyy/yyyy is the suffix for
the specific dataset. For example, EXCICTRN is the
exit member name for the CICS product CICSTRAN dataset,
and thus "_LCICTRN" and "_KCICTRN" are the new macros.
The "_L" macro lets you change the DDNAME to which each
dataset is written (for example, you can send a dataset
to a tape, or to a different DASD volume, which can help
with large volume datasets). This is the primary function
of the "_L" (Library) macro architecture. Note that in
the "_LTY0" default definition, only the dataset name is
defined, so the default DDNAME of WORK is used. Changing
the definition to MACRO _LTY0 XYZ.TYPE0 % would cause
that dataset to be written to the XYZ DDname.
It is the "_K" macro that is the real powerhouse in this
implementation. It is located after the KEEP= list of MXG
variables to be kept, and is inside the parenthesis that
can contain dataset options, and so it can be used to
specify dataset options like DROP= BLKSIZE= and COMPRESS=!
Lets look at the before and after structure of MXG code,
using the macros defined in VMAC0 (for the TYPE0 dataset).
The original implementation for dataset TYPE0 was this:
MACRO _VAR0
TYPE0 (KEEP=VAR1 VAR2 ... VARn)
%
MACRO _CDE0
IF ID=0 THEN DO;
INPUT .... @;
%INCLUDE SOURCLIB(EXTY0); ===> OUTPUT TYPE0;
END;
%
The new "_L" and "_K" implementation now looks like this:
%INCLUDE SOURCLIB(IMAC0);
MACRO _VAR0
_LTY0 (KEEP=VAR1 VAR2 ... VARn _KTY0)
%
MACRO _CDE0
IF ID=0 THEN DO;
INPUT .... @;
%INCLUDE SOURCLIB(EXTY0); ===> OUTPUT _LTY0;
END;
%
Examples:
a. The _KTY0 macro can be used to DROP unwanted variables.
Simply define it as
MACRO _KTY0 DROP= VAR2 %
and the unwanted variables will be dropped. (It turns
out that if a KEEP= and a DROP= option are used for the
same dataset, that the DROP= list overrides the KEEP=
list!)
b. The _KTY0 macro can be used to COMPRESS the dataset:
MACRO _KTY0 COMPRESS=YES %
will compress the TYPE0 dataset.
c. You can create new variables (in the Exit member, or in
the case of CICS user data, in IMACICUS) and add them
to the dataset, and drop other variables at the same
time:
MACRO _KTY0 MYVAR1 MYVAR2 DROP= VAR2 %
will cause the TYPE0 dataset to contain your new
variables and drop old variable VAR2.
The earlier implementation of IMACKEEP did permit override
of dataset name and the keep list, but it required copying
the entire _VAR macro definition into IMACKEEP, and this
exposed your site to errors any time a new dataset was
added to that product. The new implementation isolates
your tailoring to the specific dataset, and addition of
new datasets will be transparent to your tailoring.
Change 10.174 The DB2 optimizer's cost estimate, QW0022OS, is input as
ADOC102 RB4. (floating point), not the $CHAR4 input format (that
VMAC102 was printed as $HEX8.). Now, QW0022OS is a numeric field
Sep 22, 1992 instead of character, and contains the cost estimate.
Thanks to Frank Ingrassia, IMS Software, USA.
Change 10.173 SAS 6.07 option FMTSEARCH=(DD1 DD2 DD3), which supports
IMACFMTS concatenation of format libraries, has eliminated the need
Sep 22, 1992 for this SAS 6.06 circumvention. The member was kept for
compatibility, but is unlikely to be needed now.
Change 10.172 Warning "Variable FVOLSER uninitialized" eliminated by
TYPETMS5 removing the incorrect reference to FVOLSER in DSNBREC
Sep 21, 1992 processing. This was only a cosmetic warning.
Change 10.171 VTOC with freespace starting in track 1 did not have that
VMXGVTOC freespace extent reported (except for the first VOLSER).
VMXGVTOF MXG logic was only checking the first volume. This change
Sep 21, 1992 restructured several lines of logic, thanks, Chris. The
Oct 18, 1992 VMXGVTOC changes were incomplete in the Early MXG 10.2 and
were corrected in the PreRelease MXG 10.2
Thanks to Hank Boonstra, GASUNIE NV, THE NETHERLANDS.
Thanks to Chris Weston, SAS Institute Europe, GERMANY.
Change 10.170 DB2 Trace record IFCID=172 (Deadlock, identifies all of
VMAC102 the units-of-work involved in the deadlock, resources they
Sep 17, 1992 were contending for, and attributes of their requests) and
IFCID=177 (Package Allocation) have now been coded/tested.
The only remaining IFCIDs that are not coded are 126-129,
180-182, 186, and 190-195, because none of these subtypes
have yet been created in numerous traces. If you observe
one of these subtypes, please fax a hex dump of the record
so these final DB2 trace IFCIDs can be supported.
Thanks to Gary Smith, Southern California Edison, USA.
Thanks to Frank Ingrassia, IMS Software, USA.
Change 10.169 The JCL example showing how to invoke %GRAFDB2 would not
GRAFDB2 execute; GRAFTRND should have been GRAFDB2, and the ending
Sep 17, 1992 parenthesis and final semi-colon were missing. This error
was only in the example in comments; there was no error in
GRAFDB2 itself.
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 10.168 Support for VSE DOS POWER Version 4.2 accounting records
IMACDOS has been found to require only setting OFFSET=24 and INPUT
Sep 17, 1992 @67 RECID in the Installation tailoring MACro, IMACDOS.
Thanks to Alan Smith, Health and Welfare Data Center, Calif., USA.
Change 10.167 IBM APAR OY49717 adds text to SMF type 37 records for the
VMAC37 Network Alert Report and the Self Defining Text Message
Sep 8, 1992 Report. While there may be multiple Network Alert Report
text segments, in this implementation, only the first is
kept; these are 200 byte variables, and I don't want to
greatly enlarge the size of TYPE37 until a real user tells
me this new data is actually useful! If you use the
TYPE37 and if it uses enough DASD space to be a problem
justifying a re-design (i.e., creating multiple datasets
with restricted sets of variables instead of just the one
TYPE37 with all possible variables) please let me know and
give me your thoughts.
Change 10.166 The _LTRccmm macros names were changed to _XTRccmm names
READDB2 so as to not conflict with the new _L and _K dataset macro
VMAC102 names. (This should have no impact; _XTRccmm macros are
Sep 7, 1992 internal lists and are not normally modified by users.)
Change 10.165 Support for XCOM 6.2 Version 2.2.2G SMF record.
ADOCXCOM Dataset XCOMDATA describes (extensively!) file transfer
EXTYXCOM activity, timestamps, and file attributes and sizes for
IMACXCOM files transferred by XCOM. Additionally, Neil Colombage
TYPEXCOM provided extensive notes about meanings of many variables
VMACXCOM that are now found in member ADOCXCOM.
Sep 6, 1992
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Thanks to Neil Colombage, British Airways, ENGLAND.
Change 10.164 Support for SAP Application Accounting data under CICS.
EXCICSAP The SAP product provides the "STCDUMMY SAP Statistics" in
IMACCICS either a journal format file (which can be read with MXG's
IMACICSA TYPE110J member), or an SMF format type 110 record (as a
VMAC110 journal subtype, which can now be read by TYPE110/BUILDPDB
VMAC110M members). The CICSSAP dataset will contain observations
Sep 6, 1992 automatically if the "user journal type-id" JCRUTRID='SA',
so you need only to find out whether the SAP STCDUMMY data
was sent to a Journal or to SMF. A SAP "event" can have
several CICS transactions, and may last beyond the end of
the last CICS event, so SAP's creation of this additional
transaction information appears to be a very intelligent
architecture to help us measure both CICS and SAP!
Member IMACICSA contains the logic to decode their journal
segment, but you should not have to do anything to that
member; it was externalized only for ease of maintenance.
The internal logic of VMAC110 was restructured to process
journal segments and to specifically recognize the SAP
journal-id. (The logic of VMAC110 is now documented
schematically in ADOC110 for those interested.)
Thanks to Danilo Gipponi, SAS Institute, ITALY.
Thanks to Mr. Eude, Didier Werke AG, GERMANY
Thanks to Mr. G. Guarnaschelli, Hoechet Italia, ITALY.
Change 10.163 Candle's VCOLLECT 5.1.0 still writes the invalid "VVB"
VMACVMXA monitor records first discussed in Change 8.004. The fix
Sep 5, 1992 then was to modify VMACVMXA to add " INPUT +4 @; " before
the actual input statement, but line numbers have changed,
and now the change has been externalized. A new macro in
VMACVMXA is now defined, _VCANFIX, with null value (blank)
but which is located so that you can process Candle data
by the following override in your program:
%INCLUDE SOURCLIB(VMACVMXA);
MACRO _VCANFIX INPUT +4 @; %
_VMTEST
since the resultant program will skip over the unwanted,
additional record length field. (Note that _VCANFIX was
located immediately prior to the INPUT MRHDRDM statement
following MACRO _VMINPUT, as suggested in 8.004).
Thanks to Phil Henninge, Timken Company, USA.
Change 10.162 Support for FACOM PDLF Type 127 SMF record for MSP/EX is
VMACF127 provided by this significant user contribution. Many new
Sep 5, 1992 variables were added to the TYPEF27D (device statistics,
including VOLSER, and pending, connect and disconnect
times), the TYPE27S (CPU statistics, including virtual
pages in the CSA,PLPA, and NUC above and below the line),
and the TYPE27S and TYPE27P (performance Group statistics)
both now support eight-CPU-engine statistics. These data
bring FACOM up to rough equivalence to MVS/XA in terms of
the "RMF-like" PDLF data capture.
Thanks to Joan Dobbie, Attorney-General's Office, S.A., AUSTRALIA.
Change 10.161 Support for FACOM's AIM Version 12 type 116 SMF record is
EXAIM6R added. Version 12 incompatibly changed the record, and
FORMATS there is no record version indicator, so a new Flag AIMVER
IMACFACO was added to IMACFACO to identify which version of AIM MXG
VMACAIM6 is to process. Two formats were added and new AIM dataset
Sep 5, 1992 AIM116_R is created. The changes were extensive, but the
documentation was unclear as to the relationship between
the task information sections and the deadlock resource
information sections; these MXG assumptions were made:
- item 16 (table A.5) should be described as "Offset to
deadlock-related *resource* information section".
- use the pointers to the deadlock resource info sections
that were in each task info section rather than the
triplet in the header which points to all the deadlock
resource info sections
- each deadlock task has only one deadlock resource
section associated with it.
This support has been tested, but only with a small number
of test records.
Thanks to Malcolm Sare, Australian National, AUSTRALIA.
Change 10.160 UTILGETM (used in step SMFSMALL of JCLTEST6 to create the
UTILGETM SMFSMALL sample file now will select ten of each subtype
Sep 5, 1992 of all SMF records, including user records. Previously,
only types 22,30,39,70-79 subtypes were selected. This
implementation makes use of _TEMPORARY_ arrays to avoid
a limitation in SAS 6.07 of 32768 variables in a data step
(that limitation is to be fixed in the November, 1992,
SAS maintenance tape), but you may wish to note that the
variables in _TEMPORARY_ arrays are not similarly limited.
Since this type of array did not exist in SAS Version 5,
UTILGETM tests its operating environment and uses the new
(more robust) logic only under Version 6; the old logic is
unchanged under Version 5.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.159 Although we don't recommend using these archaic read VTOC
FMXGUCBL programs (instead, see member ASMVTOC/VMXGVTOF), they will
VMXGVTOC now work under SAS 6.07. The EXEC ASMHCL statement must
VMXGVTOR be changed so the PARM.C parameter precedes the PARM.L
Sep 3, 1992 parameter, and the //SYSIN following that EXEC must be
changed to //C.SYSIN. Additionally, the function calls in
VMXGVTOC and VMXGVTOR using =FMXGUCBL() was changed to
=UCBL() because functions can only have 4-character names
in SAS Version 6.
Thanks to Bob Smith, Nissan Motor Corporation in the USA.
Change 10.158 FORMAT NOT FOUND error with DB2 SQL Trace reports if no
ANALDB2R T102S105 or T102S107 records (the records that map DBID &
Sep 3, 1992 OBID to their names) were found. While these records are
always written at Trace start-up, the condition can occur
when you process records in the middle of a trace session.
Also, even when the format could be constructed, if there
was no match with your OBID/DBID value, an 8-byte string
(SYSTEM ID + QWHSSSID) was printed. Now, the format is
always created, and for a no-match, the string of SYSTEM,
QWHSSSID, DBID, and OBID is printed. This required some
reformating of some of the SQL reports.
Selection by PLAN, CORRNAME, etc., has now been added to
the Record Trace report.
Regardless of the order in which reports are specified,
ANALDB2R executes and prints the reports alphabetically.
The SORTBY= parameter was ignored in subsequent reports,
if a report such as PMACC03 was requested that had a non-
changeable sort sequence, because of incorrect parsing
that has now been corrected by DB2RSORT macro changes and
invoking this macro for the reports whose sort sequence
can be changed.
Additional changes that will reduce WORK space requirement
are still in development.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.157 (MXG 10.1 only). Assembler error MSGAREA not found cause
ASMVTOC LSPACE UCB=(4),EXPMSG=MSGAREA,MF=I should have been
Sep 2, 1992 LSPACE UCB=(4),MF=I
The EXPMSG=MSGAREA was left over from debugging. Sorry!
Thanks to Sean Chaffee, Amadeus Dataprocessing Gmbh & Co, GERMANY.
Change 10.156 ASMVVDS may fail with User 666 ABEND processing a VVDS on
ASMVVDS a volume which is SMS managed multivolume with guaranteed
Sep 2, 1992 space. The Diagnose VVDS command does not work until you
install IBM APAR OY48199 (PTFs UY74336-339).
Thanks to Chris Taylor, Wachovia Operations Services Corp., USA.
Change 10.155 NPM 1.5 incorrectly documented format of new variables
VMAC28 LLBSSTIM and LLBSPTIM as packed decimal (PDTIME4.) fields,
Sep 2, 1992 but actual data now shows they are PIB4. fields. Change
the PDTIME4. to PIB4. after both variables.
Thanks to Jerry Kleinheinz, Mortgage Guarantee Corp, USA.
Change 10.154 TYPEMONI (archaic Landmark Version 7) does not contain
TYPEMONI APPLID, but ASUMCICS expects that variable, so sites still
Sep 2, 1992 using TYPEMONI (remember, TYPEMON8 is for Versions 8/9)
must add APPLID to the KEEP= list for MONITASK, and must
insert APPLID=SYSID; after the @; and before FILTEM=0; .
Thanks to Russ Weid, CUNA Mutual Insurance Group, USA.
Change 10.153 Step accounting variable SACCT1 is now added to the PDB
IMACPDB datasets JOBS, STEPS, and PRINT, so that Started Tasks
Sep 1, 1992 (which can have only step accounting fields) can be
tracked to account group. This involved adding SACCT1 to
the ID statement in macro _PDBSUMS, and adding SACCT1 to
the _PDBADD2 and _PDBADD3 macros.
Thanks to Mike Skopec, Platinum Technology, USA.
Change 10.152 The //LIBRARY DD in the first step should have specified
JCLTEST6 DISP=(NEW,CATLG) instead of NEW,PASS so that this MXG
Sep 1, 1992 format library is both built AND cataloged!
Thanks to Basil Hines, Rogers Data, CANADA.
Change 10.151 Some DB2 graphs may not have been produced because the
GRAFDB2 statement IF EOF THEN CALL SYMPUT... should have been only
Sep 1, 1992 CALL SYMPUT.... (It worked in testing, because in each of
the cases, the last observation was selected, but if the
last observation was not selected, &MXGOBS was not set.)
Thanks to Andre Henry, AG 1824, GERMANY.
Change 10.150 WSF 3.3.6 causes INPUT STATEMENT EXCEEDED error because
VMACWSF the accounting extension in 3.3.6 contains only three of
Sep 1, 1992 the seven fields added in 3.4.1. To process 3.3.6 data,
you will need to find BOTH occurrences of ACCXPFMR $CHAR8.
and insert the following line after each occurrence:
@; IF LENGTH-COL+1 GE 148 THEN INPUT
so that those following fields are only input if the data
is in the record. There is no error with 3.4.1 data.
Thanks to Frank Sullivan, Woolworth plc, ENGLAND.
Change 10.149 DB2 variables CORRNAME and CORRNUM are determined by the
IMACDB2 connection type (TSO, IMS, CICS, etc.), but prior to DB2
Sep 1, 1992 2.3, the only way to identify connection was by testing
the value of QWHCCN for you site's IMS jobname in macro
_DB2CORR defined in IMACDB2. This macro has now been
redesigned to take advantage of new (in DB2 2.3) variable
QWHCATYP which explicitly identifies the connection type.
(See member ADOCDB2 for all possible values of QWHCATYP.)
The macro definition now reads:
MACRO _DB2CORR
IF (QWHSRELN GE 2.3 AND (QWHCATYP=5 OR QWHCATYP=6 OR QWHCATYP=9))
OR
(QWHSRELN LE 2.2 AND (QWHCCN =: 'IMS1' OR QWHCCN =: 'IMS2'))
THEN DO; /* IDENTIFY IMS CONNECTIONS */
CORRNAME = SUBSTR(QWHCCV,5,8);
CORRNUM = SUBSTR(QWHCCV,1,4);
END;
ELSE
IF (QWHSRELN GE 2.3 AND QWHCATYP=4)
OR
(QWHSRELN LE 2.2 AND (QWHCCN =: 'CICS' OR QWHCCN =: 'PROD'))
THEN DO; /* IDENTIFY CICS CONNECTIONS */
CORRNAME = SUBSTR(QWHCCV,5,4);
CORRNUM = SUBSTR(QWHCCV,1,4);
END;
ELSE DO; /* FOR ALL OTHER CONNECTIONS */
CORRNAME = SUBSTR(QWHCCV,1,8);
CORRNUM = ' ';
END;
%
Thanks to Mr. M. Praet, AG, GERMANY.
Change 10.148 Three DCOLLECT variables in the DCOLBKUP (backup) dataset
VMACDCOL have incorrect values. UBALLSP, UBUSESP, and UBRECSP were
Sep 1, 1992 1024th of what they should have been. Find the line
UBALLSP=1024*UMALLSP;
and the two lines following. Change the "UM" in all three
lines to "UB" to correctly convert the variables.
Thanks to John Ellis, Commercial Union, U.K.
Change 10.147 The MXTDELAY dataset built by these sample CICS reporting
ANALCICS programs is not used by any report (it was a holdover from
ANALMONI CICS 1.6), and the dataset is no longer created.
Aug 31, 1992
Thanks to Kevin Batten, Roses Stores, Inc, USA.
Change 10.146 The new Appended IMS log processing program ASMIMSLG now
ASMIMSLG works with IMS 2.2 as well as IMS 3.1. Sites still using
Aug 31, 1992 IMS 2.2 need only to comment out a single statement:
MVC ORGENT(8),MSGRACGP
(because MSGRACGP is a field name that does not exist in
the IMS 2.2 DSECT as it was added in IMS 3.1), and then
use the IMS 2.2 macro libraries for the assembly. Note
that you will need to have two load libraries, one for
the IMS 2.2 version of MXGIMSLG, and one for the IMS 3.3
version if MXGIMSLG, to keep them separate. The comments
in ASMIMSLG were revised to include IMS 2.2 installation.
Thanks to Warren Hayward, TJX, USA.
Change 10.145 Landmark Monitor for CICS variable TAMRCNT is now INPUT
TYPEMON8 as PIB4. instead of PIB4.6.
Aug 18, 1992
Thanks to David Taylor, Owens & Minor, USA.
Change 10.144 NETSPY NSPYREC=N records with NCPELTYP=41 (29X) cause an
VMACNSPY INPUT STATEMENT EXCEEDED RECORD LENGTH error. Find the
Aug 18, 1992 line with NSPNEWVC PIB4. (note this is the line with
PIB4., not the earlier line with PIB2.), and delete it.
Thanks to Aubrey Tang, Government Insurance Office, AUSTRALIA.
Change 10.143 Amdahl APAF support did not keep variable BALANCE in the
VMACAPAF APAFDOMA data set, but now it does. Note that you specify
Aug 18, 1992 values 0 to 9 or A on the hardware screen, but the value
in the SMF record is 0 thru 10!
Thanks to George Scott, Rockwell International Corporation, USA.
Change 10.142 The "Appended" IMS log processing introduced in MXG 10.1
ASMIMSLG is almost perfect, but even perfection can be improved.
TYPEIMSA There were actually two errors in that release: LOGONID
Aug 12, 1992 was sometimes blank, and STRTTIME/ENDTIME were not reset
to GUTIME/OENQTIME, causing INPQUETM/SERVICTM/RESPNSTM
to be missing/incorrect. LOGONID was an omission in the
ASMIMSLG programs that create MXGIMSLG, and the time value
error was a correction in the back end of TYPEIMSA.
In addition, the Fast Path processing (IMS log 059x) that
was in TYPEIMS (the "old" way) has now been added to both
ASMIMSLG and TYPEIMSA. Moreover, Ashland's six-months use
of their contribution caused them to add enhancements to
the dynamic table allocation algorithms that are described
in comments in ASMIMSLG (and new, cleaner messages are now
printed on the SYSOUT for MXGIMSLG execution).
Thanks to J. Cary Jones, Philip Morris, USA.
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Jeffrey S. Crum, Ashland Oil, USA.
Change 10.141 NPM changes in MXG 10.1-Change 10.106- cause INVALID DATA
VMAC28 FOR NTMPDUTH because PIB4 was mistyped instead of PIB4.
Aug 12, 1992 Change both occurrences of 'PIB4 ' to 'PIB4.'. Once this
was corrected, the values for NTNPDUTH/NTNOCCTH were noted
to be '7FFFFFFE'X, because NPM folks use that hex value as
their "infinity" (the real maximum is '7FFFFFFF'X since
the first bit is the sign bit). However, since MXG stored
these variables in LENGTH DEFAULT=4 variables, and since
the maximum hex value storable in four bytes is '7FFFFF00'
MXG was truncating the "infinity" from 2,147,483,646 to
2,147,483,392. To correct this truncation of infinity,
LENGTH NTNPDUTH NTNOCCTH 5; was added. These NTN fields
are PIUs (PDUs) or bytes (Octets) threshold values at
which NPM is to cut interval records. By specifying the
infinity value, the site is telling NPM to never write an
interval record based on these counters, and instead to
write timed interval records.
Thanks to Scott Ashby, U.S. Customs Data Center, USA.
Change 10.140 An interesting discovery was made by comparing the pagein
RMFINTRV counts in TYPE71 with the sum of the page in counts in the
Aug 7, 1992 TYPE72 observations (SET TYPE72; IF PERFRPGN=.; , to keep
only control performance group data). The TYPE71 PVTNPIN
was 46,912 page ins, while the sum of the TYPE72 PAGEINS
was 45,838, which means that the delta, 1074, page ins
were not counted in the address space data. This may be
a coding error in RMF code, or could be an indicator of a
special category of paging. IBM can't explain it, yet.
Thanks to Sandi Whitmyer, USA Funds, USA.
Change 10.139 The PRUWTR package, from Prudential Insurance, is used to
TYPE6 manage spool printing, and writes an SMF Type 6 record.
Aug 7, 1992 The READTIME value put in that record is incorrect; it is
taken from JCTCNVON, the converter on event, instead of
being taken from JCTRDRON, the correct value of when the
job's JOB card was recognized. Because the wrong time was
in READTIME, these type 6 records did not match up to any
of the other job records (BY READTIME JOB JESNR), and the
PDB.PRINT observations from PRUWTR did not have ACCOUNTn
values, and the PDB.JOBS observations did not include the
PRUWTR lines. Since PRUWTR is also source code, your JES
person can change the value from JCTCNVON to JCTRDRON, and
then the PRUWTR type 6 records will match other records.
Thanks to Norm Lacoe, Confederation Life, CANADA.
Thanks to Beth Wells, Confederation Life, CANADA.
Change 10.138 ROSCOE creates records for two new "ROSCOE monitors". The
VMACROSC JCL-CHECKER (MONITOR JCK) is identical with the JCL RECORD
Aug 6, 1992 and JCK records are added to the ROSCOJCL dataset. The
Documentview creates observations in ROSCOVPE that can be
recognized as documentview because VPEMONNM='DOC'.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.137 MVS/ESA XCF Type 74 record INPUT STATEMENT EXCEEDED
VMAC74 RECORD LENGTH and STOPOVER ABEND, because of an MXG error.
XMAC74 Find INPUT @OFF742MO, and change the immediately following
Aug 4, 1992 statement from DO _I_=1 TO NRDDSS; to DO _I_=1 TO NR742MO;
(make sure you change only this DO statement; there are
two other occurrences of DOs to NRDDSS that are correct!)
Thanks to John Nicholls, Health Insurance Commission, AUSTRALIA.
Change 10.136 MXG 10.1 Tape Mount Monitor ABENDs with S 55F at startup.
ASMTMNT Code added in 10.1 to support MVS/ESA 4.2 dynamic devices
Aug 4, 1992 perturbed the contents of Register 1. When the SYSEVENT
TRANSWAP was issued, the non-zero value in R1 is taken as
the address of an ECB to wait upon, but as it was now not
in the address space of the MXGTMNT, the ABEND occurred.
The fix is simple. Insert SR R1,R1 immediately
prior to the SYSEVENT TRANSWAP statement to zero Register
One, which tells TRANSWAP not to post any ECB address, and
thereby avoids the abend. This error was not in MXG 9.9.
Thanks to Andrew Jeppeal, Marshalls, USA.
Thanks to Matt Gallion, Tenneco, USA.
Change 10.135 DB2 Audit Detail Report isn't produced when more than one
ANALDB2R report was requested, or when the SORTBY operand was used,
Aug 4, 1992 because of a mislocated %END statement. Find the first
DATA _NULL_ after the %MACRO PMAUD02 statement, and insert
a %END; statement immediately before that DATA _NULL_
statement. Then find %MEND PMAUD02; and delete the %END;
statement immediately preceding that %MEND statement.
Thanks to Tom Hubbard, Westone Bancorp, USA.
Change 10.134 NPM variable PCTBUSY, for full duplex lines, contains the
VMAC28 maximum of Primary (outbound from NCP) or Secondary
Aug 3, 1992 (inbound to NCP) utilization, but PCTBUSY won't identify
when one direction dominates. MXG added two new variables
PCTPRBSY/PCTSCBSY which contain the utilization in each
direction. An additional network variable, PCTNEGPL, the
percentage of polls that were negative polls, was added as
it is useful in identifying network response problems.
Thanks to Scott Taylor, Primerica, USA.
Change 10.133 Some observations in PDB.JOBS can have JELAPSTM missing,
IMACPDB even though variable INBITS contains a 'J', indicating a
Aug 1, 1992 type 30_5 record was found. (If there is no 'J' in the
third position of INBITS, then JELAPSTM is expected to be
missing, since it is calculated from the 30_5 record.)
This error affected only jobs with more than 1476 unique
DD segments in their type 30_5 record, and resulted from
the absence of variable MULTIDD in the _PDB30_5 macro that
is defined in member IMACPDB. MULTIDD='Y' identifies the
"extra" type 30 record created where there are more than
1476 DD segments in the record, and is used in BUILDPDB/3
logic to recognize these pseudo job (and step) records.
Because it was not in TYPE30_5 in BUILDPDB, JELAPSTM was
inadvertently missing, and also variable RESTARTS was not
accurate for these jobs. To correct the error, variable
MULTIDD was added to the _PDB30_5 definition in IMACPDB.
You could workaround the error by adding the following
statement in your reporting program that uses JELAPSTM:
IF JELAPSTM=. AND JINITIME NE . AND JTRMTIME NE . THEN
JELAPSTM=JTRMTIME-JINITIME;
Thanks to Jim Cummings, First Interstate Bank of Oregon, USA.
Change 10.132 CICS Journal data can be sent to the type 110 SMF record.
EXCICJRN Some sites modify CICS to send data (such as logon/logoff)
Jul 30, 1992 to a journal and direct that journal to SMF. This change
creates a new exit which allows you to gain control (for
example, to process a user journal record). If you think
you need to use this exit, call for further assistance.
Note that Change 10.164 adds support for the SAP journal
record from SAP accounting, and does not use EXCICJRN.
Thanks to John Ebner, SystemHouse, USA.
Change 10.131 Amdahl's MDF architecture supports 16 LPARs, but MXG only
ASUM70PR supported 8 in its summarization and trending. (A message
TRND70PR alerts you that more than 8 were found.) This change
Jul 27, 1992 adds variables for the additional 8 possible LPARS.
Thanks to Jeff McFadyen, Ministry of Correctional Services, CANADA.
Change 10.130 Calculation of tape length for 3420 (reels) in VMACTMS is
VMACTMS5 slightly incorrect. The IRG (inter record gap) of 0.6" is
Jul 27, 1992 for 1600BPI tapes, and IRG is only 0.3 inches for 6250s.
For a full tape of 5200 blocks at 32760 blksize, the 0.6"
value caused a 2400 foot tape to be reported as 2530 feet!
Thanks to Malcolm Sare, Australian National, AUSTRALIA.
Change 10.129 SAS 6.07 under CMS has serious problems for MXG users.
Jul 27, 1992 The concat of sourclibs (USERID.SOURCLIB, MXG.SOURCLIB)
did not work, although it is now reportedly corrected.
The workaround is to make a complete copy of SOURCLIB
and make your tailoring changes in that copy until SAS
fixes the problem so you can reinstall with your changes
isolated in the USERID.SOURCLIB.
Standard label tapes cannot be read under CMS SAS 6.07,
but SAS is working on the problem with Systems Center.
Change 10.128 BUILDPDB under CMS SAS needs correction. The new macros
BUILDPDB VMXGDKRN/VMXGDKRW must be renamed VMXGDKN/VMXGDKW because
BUILDPD3 CMS SAS is limited to only seven character macro names.
Jul 27, 1992 Additionally, execution under CMS SAS 5.18 will require
the addition of a FILE DEF for SMFTEMP, and the DCB=SMF in
the FILE SMFTEMP statement in BUILDPDB must be changed to
DCB=VB LRECL=32756 BLKSIZE=32760 since CMS cannot create
VBS files.
Change 10.127 JCLPDB6 in MXG 10.1 will fail with DATASET PDB.TYPETMNT
BUILDPDB NOT FOUND error, because ASUMTMNT is included in JCLPDB6
BUILDPD3 sample program, but the intended automatic creation of the
Jul 24, 1992 TYPETMNT (Tape Mount Monitor records, created by ASMTMNT),
did not get into MXG 10.1. Now, BUILDPDB/BUILDPD3 will
create TYPETMNT dataset, so that if you install MXGTMNT to
create SMF records, you will now only have to update the
IMACTMNT member in your USERID.SOURCLIB to tell MXG what
SMF record number you assigned, and your tape mount times
will automatically be in your PDB library.
Thanks to Jeff McFadyen, Ministry of Correctional Services, CANADA.
Change 10.126 Variable QWHSLUUC should have been spelled QWHSLUCC in
ANALDBTR the _VTRCMN macro definition for DB2 Trace processing.
Jul 24, 1992
Thanks to Christophe Faure, SAS Institute, FRANCE.
Change 10.125 Variable DS4VTOCE was input but not kept, and was not
VMXGVTOC labeled. Add it adjacent to DS4VTOCI in the keep list,
VMXGVTOF and add DS4VTOCE='VTOC*EXTENT*DESCRIPTION' adjacent to
Jul 24, 1992 DS4VTOCI in the LABEL statement.
Thanks to Christophe Faure, SAS Institute, FRANCE.
Change 10.124 IBM incompatibly changed the PSF type 6 SMF record, but
VMAC6 the change was not documented! Bin counts were added to
Jul 22, 1992 the APA subsection (and the added length was NOT added to
SMF6LN4!), and the ESS subsection, formerly only in the
JES2 type 6 SMF record, now exists in the PSF record; this
unexpected segment caused incorrect values for the APA
subsection variables DOCLENFT/FONT,OVLY,PGSG USED-LOAD.
The simple fix is to relocate the ESS section DO group
(22 lines) which starts with
IF SECTIND='...1....'B AND OFTONXT ... /* ESS SEG */
to just after the end of the PSF section DO group, which
starts with
IF SECTIND='..1.....'B AND OFTONXT ... /* PSF-APA */
This change also added BINnBNCT variables for 8 bins.
The APAR which apparently made this change is OY30945.
Thanks to Kevin James, Cornhill Insurance, ENGLAND.
Thanks to Tim Sparrow, Cornhill Insurance, ENGLAND.
Change 10.123 Variables R791BPIN,PINE,BPNE,CTAR, and R791VAL were added
VMAC79 to TYPE791 dataset. The test IF SMF79ASL GE 96 before the
Jul 21, 1992 input of R791HIN was changed to IF SMF79ASL GE 98. The
MVS/ESA 4.2 value for R791FMCT is occasionally too large
(129MB for INIT with WM/LW); IBM is investigating.
Variables R794PPIA/LPIA were added to TYPE794 dataset,
and redundant LCUID code was removed from TYPE79E logic.
Thanks to Steve Saunders, Talbots, USA.
Change 10.122 Total page movement between central and expanded storage
VMAC71 is EXTREADS (from ESTORE to CSTORE) plus PGMVTOEX (from
Jul 21, 1992 CSTORE to EXTORE). The sum of EXTREADS+PGMVTOEX is useful
in comparing before and after effects on memory changes.
Thanks to Sigfrido Perdomo, Metropolitan Life, USA.
Change 10.121 Datasets ILKAST20 and ILKAST21 had invalid data because
VMACILKA the offset was incorrect, and the documentation was wrong.
Jul 21, 1992 Change the line reading:
Aug 18, 1992 FPTDCSOF=FTPDCSOF-3+OFFSMF;
to read:
FPTDCSOF=FTPDCSOF+SMFACDOF;
Change the line reading:
FPTDCTOF=FTPDCTOF-3+OFFSMF:
to read:
FPTDCTOF=FTPDCTOF+SMFACDOF;
Change the +3 following F20DTTY PIB1. to +1
Change F21FVOL from $CHAR8. to $CHAR6.
Change F21DAIR from $CHAR8. to $CHAR4.
Change F21DARC from $CHAR8. to $CHAR1.
Insert two lines after F21SBMSG PIB2.
@;
IF FTPDCTLN GE 129 THEN INPUT
to conditionally input F21DAIR/F21DARC (a feature that was
not documented by the record's vendor!).
Thanks to Paul Mei, Imperial Oil Limited, CANADA.
Change 10.120 New variable M24IODEV is input in M24LOGOF and M24SINCE
EXM24ACT datasets, and the account input code formerly in EXM24ACT
VMACM204 (for compatibility with archaic versions of MODEL204) was
Jul 19, 1992 moved into VMACM204. EXM24ACT is no longer referenced.
Change 10.119 A strange type 30 subtype 1 record caused INPUT STATEMENT
IMACACCT EXCEEDED RECORD LENGTH error because of an MXG logic error
Jul 17, 1992 if a type 30 ends with an account section. This record is
questionable, as it contains only a PROD, ID, and ACCT
section, and the "INITTIME" is nulls, so this may in fact
be an invalid record, but MXG still should not fail too!
Change the last line of IMACACCT to read
IF LENGTH GT TEMPLOC THEN INPUT @TEMPLOC @;
so the existing INPUT @TEMPLOC @; is only executed if the
record has additional data sections.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 10.118 The Cache DASD analysis was incorrect. LCU and DEVADDR
ANALCACH could be missing, and only the first LCU was reported.
Jul 17, 1992 The logic was revised to merge BY LCU VOLSER and output
Oct 8, 1992 only when both TYPE74 and CACHE90 had data (MXG does not
output TYPE74 if there was no I/O activity during the
interval, while CACHE90 always had an observation.)
Thanks to Scott Ashby, U.S. Customs Service, USA.
Change 10.117 Execution of MXG's BUILDPDB under the CMS version of 6.07
BUILDPDB causes APPARENT MACRO INVOCATION ERROR message, because I
BUILDPD3 forgot that CMS is limited to seven-character %macro names
BUILD518 when I added %VMXGDKRO and %VMXGDKRW macro definitions and
Jul 17, 1992 invocations in MXG 9.9! Change both VMXGDKRO to VMXGDKO
and both VMXGDKRW to VMXGDKW to comply with the CMS limit.
If you are still executing under CMS 5.18, there are other
problems! The FILE SMFTEMP DCB=SMF; statement will fail
under CMS if the input SMF file is a VBS file, because you
can only read VBS under CMS, you cannot create VBS. You
would need to change BUILD518 to use
FILE SMFTEMP RECFM=VB LRECL=32756 BLKSIZE=32760;
and pray you never see an SMF record that is 32760 bytes
long!
Thanks to J. D. Hill, CyCare Systems, USA.
Change 10.116 STC Release 1.2 of the STC4400 HSC SMF record was changed
VMACSTC incompatibly. The one-byte STC07CON field in the middle
Jul 15, 1992 of the record is now a four-byte field. MXG does not fail
but the data values are trashed, and of course there is no
record version indicator in this subtype 7 record!. The
correction is to replace STC07CON PIB1. with
@;
IF LENGTH-OFFSMF EQ 105 OR LENGTH-OFFSMF EQ 137 THEN
INPUT STC07CON PIB1. @;
ELSE INPUT STC07CON PIB4.
Thanks to Glen Farmer, Hallmark Cards, USA.
Change 10.115 SYNCSORT variable COREREQ can be negative! If you specify
VMACSYNC "MAX-100K", indicating SYNCSORT can use the REGION size
Jul 13, 1992 minus 100K, COREREQ will be -100K, after you change the
INPUT statement for COREREQ from PIB4. to IB4.
Thanks to Brian LeBlanc, Chrysler Corporation, USA.
Change 10.114 CA TOP SECRET causes INPUT STATEMENT EXCEEDED RECORD due
VMAC80 to a change in the value CA stores in RACFVRSN. The type
Jul 12, 1992 80 SMF record created by TOP SECRET is identical in format
to the IBM record, but CA's OFFSET is from the beginning
of the physical record, while IBM's OFFSET is from the
start of the logical record. MXG tests RACFVRSN to know
if the record is an IBM or a CA record. A new value of
43X (previous values were F3X or F4X) must be added to the
test in line 007700 to recognize this as a CA record. I
assume this new value is associated with a new release of
TOP SECRET, but nobody at CA bothers to keep me informed!
As an aside, the CA OFFSET value is actually consistent
with offset values in other SMF records; the RACF type
80 is the only IBM record which calculates offset from
the logical record!
Thanks to Mark Paulson, Maurices, USA.
==Changes thru 10.113 were included in MXG PreRelease 10.1 Jul 10, 1992=
Change 10.113 Sample IEFU83 SMF exit that filters type 40 SMF records,
ASMIEFU8 only write SMF records for tape devices. This exit is in
Jul 10, 1992 use to measure tape drive allocation time by merging SMF
type 30, type 40, type 21, and MXGTMNT SMF records with an
algorithm still in development, but the exit by itself may
be useful so that you can create type 40 (deallocation of
dynamically allocated devices) for tapes only, and thereby
determine the JOB name of those jobs which allocate tape
devices dynamically (so that they can be excluded by JOB
name in MXG's ANALTAPE analysis).
Thanks to Gary Strohminger, AT&T Transtech, USA.
Change 10.112 Major revision in support for OPC/A log processing. This
EXOPC... significant user contribution adds several new datasets
FORMATS and expands logic to handle records spanned across blocks.
IMACOPC The "OPCA" prefix for dataset names was changed to "OPC",
TYPEOPC the variables prefixed "OPC" are now prefixed "TRL" to
TYPEOPC agree with IBM field names, and the input file is now
VMACOPC OPCLOG instead of OPCALOG. (To eliminate confusion with
VMACOPC the earlier MXG support, members TYPEOPCA/VMACOPCA are
Jul 9, 1992 deleted and replaced by TYPEOPC/VMACOPC.). See comments
in member VMACOPC for an appreciation of the extensive
work that the contributor accomplished.
Thanks to Rodney Marwick, Vereinte Versicherungen, GERMANY.
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 10.111 Verstand's product, TTX, is now a part of MXG Software!
TTXPDS The TTX product is a set of tools for capturing MVS data
Jul 7, 1992 (control blocks, data records, etc.) from within a SAS
program; many of its tools are implemented as ASM source
code routines that (once assembled and link-edited) can
be CALLed from within SAS. Most MXG sites probably will
not need to create monitors, but TTX is now available in
MXG if you need it. (TTX customers found TTX useful for
its DASD space measurement and Tape Device analysis, but
both these facilities were already provided to MXG sites
in ASMVTOC, ASMVVDS, and MXGTMNT. In fairness, however,
it must be noted that TTX tape monitoring also provides
device allocation time statistics not (yet!) captured in
MXGTMNT.) The single MXG member, TTXPDS, is actually a
164-member PDS that contains installation instructions,
excellent documentation, and commented source code for the
ASM and SAS TTX programs. Please let us know which parts
of TTX you have found useful.
Thanks to Guy Garon, Verstand, CANADA.
author and creator of TTX.
Change 10.110 Support for AS400 now supports V2R1M0 (and V1R3) and was
ADOCQAPM restructured. New members TYPEQAPM/VMACQAPM now follow
AS400PDS MXG naming conventions and builds all 13 QAPM.... datasets
JCLQAPM from AS400 data. Member ADOCQAPM documents how to extract
TYPEQAPM AS400 data and sending it to MVS, and JCLQAPM shows how to
VMACQAPM split an AS400 tape into 13 files, and invokes TYPEQAPM to
VMXGDSNL create all 13 QAPM.... datasets from those files.
Jul 6, 1992 AS400 data does not contain a "system" identifier, but you
can use the DSNAME of the MVS dataset with the AS400 data
to identify which AS400 system's data is being read. The
macro _MXGDSNL opens the INFILE and extracts the low-level
qualifier of the GDG into the %macro variable &LOWLEVEL
that is then stored in variable AS400SYS in each QAPM....
dataset. AS400 support in VMACQAPM is fully functional,
but variables are not yet labeled and the datasets need to
be better documented.
The _MXGDSNL was originally a %MACRO, but an 0C4 ABEND
in the %MACRO compiler caused me to change it and use
the old-style substitution macro, even though it is in
a "VMXG...." member normally used only for %MACRO. SAS
Zap Z6074721 corrects the problem; when pervasively
installed, I may revert back for consistency.
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Thanks to Greg Scriba, Budget Rent-a-Car, USA.
Change 10.109 MXG source members have always been numbered lines, but
CONFIG if you submit a job with the SYSIN statements unnumbered,
CONFIG07 you will receive a very un-obvious 180 syntax error.
SASOPTV5 With option S=0, SAS reads columns 73-80 of the first SAS
Jun 30, 1992 statement, and if no line numbers are found, SAS concludes
your source statements are unnumbered, and sets S=80 to
read all 80 columns. However, when you %INCLUDE an MXG
member, those line numbers in columns 73-80 cause the SAS
180 syntax error, or even an "UNEXPECTED END OF FILE".
To prevent the occurrence of this error, MXG members
CONFIG, CONFIG07 (for SAS Version 6) and the (now archaic)
SASOPTV5 (for SAS Version 5) contain options S=72 and
S2=72 so that SAS will always only read columns one thru
seventy-two as MXG SAS statements.
Thanks to MP Welch, US Sprint Dallas, USA.
Change 10.108 APPC variables in TYPE30 have incorrect values. Variables
VMAC30 APPCDAT and APPCDAR must be input as RB8. instead of the
Jun 30, 1992 present PIB4. format.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.107 Messages "INFO: THE VARIABLE xxx ON DATA SET yyy WILL BE
DOC OVERWRITTEN BY DATASET zzz" are printed on the SAS log if
Jun 30, 1992 SAS options MSGLEVEL=I is specified (the default is N).
These messages result when MERGE datasets have multiple
occurrences of the variable xxx, and are not informing you
of any problem. (These info messages may be useful during
testing, but they serve no purpose in normal execution.)
Thanks to Doug Drain, National City Bank, USA
Change 10.106 NPM 1.5.1 subtypes 90x-96x (144-150) caused "NONZERO TOF"
VMAC28 or "RECORD NOT OUTPUT" message; these X.25 records had not
Jun 30, 1992 been validated. Only the new NPMEVX25 dataset is affected.
Lines 168100,168200,257100 values 92, 95, 96 must be 92x,
95x, and 96x. Line 329100 must be changed to read:
ELSE IF 90X LE NPMSUBTY LE 92X OR NPMSUBTY=96X THEN DO;
Line 329400 must be changed to read:
ELSE IF 93X LE NPMSUBTY LE 95X THEN DO;
Line 242900 (+1 following DDD input) must be deleted.
Variables LXETDDTA/LXETGDTA (lines 242000-242100) must be
$CHAR9. vice $CHAR8. Most LXET.... variables are now
formatted as $HEX, as they contain unprintables.
Thanks to Scott Ashby, U.S. Customs Data Center, USA.
Change 10.105 STC 4400 SMF record decode used the same bit of STC07TYP
VMACSTC to decode its eight variables, instead of successive bits
Jun 29, 1992 for each variable, starting in line 034800.
Thanks to Daryl Skufca, DITSO Cleveland, USA.
-----Changes thru 10.104 were printed in MXG NEWSLETTER TWENTY-TWO-----
Change 10.104 EPILOG/MVS support was still wrong, after Change 10.079!
VMACEPMV The *SM180NIO and *SM180NEQ should have been
Jun 24, 1992 *(SM180NIO-1) and *(SM180NEQ-1) respectively. Also, the
input SM180RID RMFSTAMP8. is now SM180RID ?? RMFSTAMP8.
because the field is incorrect in the SM180SUB='TOTS' data
record. Because MXG the EPMVEP dataset contains events
TOTS/PGN/PGP/TSO,BAT,STC/tso,bat,stc/ some fields may not
be valid for some values of SM180SUB. It is possible that
separate datasets may be created for each event type in
future MXG versions, but that is still under study.
Thanks to Wayne Parrino, Avery-Dennison, USA.
Change 10.103 A "MONWRITE" equivalent from some vendor creates VM/ESA
VMACVMXA monitor files with an extra, and invalid, control record
Jun 23, 1992 between the valid "end" and "start" control records. The
problem is being investigated with the vendor, but this
circumvention has been added to MXG to strengthen its test
for a valid control record. After the @; after variable
IPARMLF1 has been input, insert the following statement:
IF IPARMLF1 NE 00008709X THEN DELETE;
The actual MXG change also puts a message on the log that
the unexpected/invalid record has been deleted. This
site's "MONWRITE" file also contained incorrect bytecount
values which are also being researched.
Thanks to Yam Tan, British Airways, ENGLAND.
--Changes thru 10.102 were in Beta MXG PreRelease 10.1 of Jun 22, 1992--
Change 10.102 RMDS Delete Directory record, ORG=M,ACT=D,Key=x0101'x is
VMACRMDS written erratically with inconsistent contents when it
Jun 21, 1992 is compared to the IBM DSECT, and causes INVALID DATA
message for variables RMDSMXVR,LLTH,VWDP,HHLD. This is
not an important RMDS record, and only served to print
a hex dump on the log. Now, all Packed Decimals are ??
protected to eliminate the message and hex dump.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.101 ROSCOE variables starting with ADSFUN2 thru ADSFNDSN are
VMACROSC input incorrectly. Starting in line 074800, the offsets
Jun 20, 1992 should be 211,219,227,235,243,251,259, and 259 (it was
obvious once pointed out). Also, ADFSMEM and ADFSNDSN
logic was enhanced and cleaned up in this change.
Thanks to John Ellis, Commercial Union, USA.
Change 10.100 Fujitsu's FACOM MSP/EX SMF records are now supported.
IMACFACO Type 6,22,26 and 57 records were changed incompatibly,
VMAC6 but only TYPE6 (PDB.PRINT) variables NODE,RMOTID and
VMAC26J2 TYPE26J2 (PDB.JOBS) INROUTE,PRROUTE,PUROUTE,INDEVICE
Jun 19, 1992 variables will be incorrect without this change. The
type 6 one-byte NODE/RMOTID pair was expanded in place
to two bytes each. The type 26 record was also changed
to support two-byte node/rmotid for the IN,PR, and PU
route codes, but instead of putting these data in IBM's
pre-defined Routing Section, FACOM decided to tack those
fields on to the end of the descriptor section! Facom
MSP/EX users must update member IMACFACO to tell MXG
your operating system level to cause MXG to read in
their relocated data. See comments therein.
Unfinished in 10.1 Beta:
Type 26 may have also relocated DEVNAME (SMF26NDV), but
that relocation is not coded yet. This should have no
impact except for that variable.
Type 22 record change was only to make existing fields
reserved, and had no impact on MXG code or execution.
Type 57 record has also relocated DEVNAME, but type 57
is not used in any standard MXG BUILDPDB nor reports.
Thanks to Joan Dobbie, Justice Information System, S.A., AUSTRALIA
Change 10.099 I sure missed this one! IBM changed the format of DEVNR
VMAC75 with MVS/ESA 4.2.0 records. DEVNR (or UNITADDR, its old
XMAC75 MVS/370 name) used to be written as hhhF (device BF7 was
Jun 17, 1992 'BF7F'x. Document APAR OY48957 now indicates that DEVNR
is now written as hhhh (to support 4-hex-digit addresses).
Since this was not documented in the 4.2.0 SMF manual, MXG
continued to divide by 16 to shift the "F" out. Now, the
correction is to replace line 020400:
DEVNR=FLOOR(DEVNR/16); with
IF MVSLEVEL LT 'SP4.2.0' THEN DEVNR=FLOOR(DEVNR/16);
I'm surprised it took this long for this error to show
up, but a) the VOLSER was correct, which I guess most
people use in tracking paging activity, b) it did not
create a note or message, just a wrong value, and/or
c) MVS/ESA 4.2.0 is so good, and sites using it are so
smart as to get enough memory, so that paging and swap
are no longer the bottlenecks which caused us to look at
TYPE75 data regularly in earlier operating systems!
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.098 System Center's NETMASTER type 37 SMF record supported.
VMAC37 Their record is basically compatible with NETVIEW type
Jun 19, 1992 37 records, but they set PRODUCT='NETM' instead of the
'NETV' value expected, and their subtype 2 record also
contains the GEND triplet, while IBM's subtype 2 did
not. Change IF PRODUCT='NETV' THEN to
IF PRODUCT='NETV' OR PRODUCT='NETM' THEN and
replace IF PRODUCT='NETV' AND SUBTYPE GE 3 THEN with
IF (PRODUCT='NETV' AND SUBTYPE GE 3) OR
(PRODUCT='NETM' AND SUBTYPE GE 2) THEN
for MXG to support either NETVIEW or NETMASTER records!
Thanks to Normand Poitras, TELEGLOBE Canada, CANADA.
Change 10.097 Analysis of VSAM data sets may have the incorrect value
ANALDSET for PROGRAM name. Variable SORTTIME, created in the
Jun 17, 1992 ADD statements for NAME=EXTY64 in this member, defaulted
to LENGTH 4, causing truncation of the value (up to 255
seconds could be lost), causing incorrect sequence with
the INITTIME value from the file's step record. Insert
LENGTH SORTTIME 8; after SORTTIME=SMFTIME to fix this
error. Also, TYPE64 does not contain variable OPEN that
is used in ANALDSET, causing VSAM Input and Output I/Os
to be summarized together in DSNSUMS. In the IEBUPDTE
step, add OPEN to the KEEP= list for TYPE64, and just
before the OUTPUT TYPE64; statement insert:
IF ACBOUT='Y' THEN OPEN='OUTPUT ';
ELSE OPEN='INPUT';
IBM Info/Sys Item Q494663 (all 39 pages) confuses issues,
but ultimately points out that the count of INSERTS,SPLITS
UPDATES, etc., in a type 64 record "Change" counter is not
due to this job's open, but is the catalog change since
open, and that is why you can see UPDATE counts non-zero
for INPUT! Only the EXCPS count in TYPE64 is for this
open (as it alone was fixed by ancient APAR OY15663).
Thanks to Gary Matney, Twentieth Century Investors, USA.
Change 10.096 PDBTREND JCL example builds PDBs and updates TRENDs from
PDBTREND SMF input for new sites to "initialize" their past trend
Jun 16, 1992 from before they begin regular building of the PDB. The
sample report herein used RMFINTRV/TYPE72 instead of the
TRNDRMFI and TRND72 dataset names (which were change way
back in MXG 8.3, but this example was overlooked).
Thanks to Mike Skopec, Platinum Technology, USA.
Change 10.095 Support for Blue Line's Vital Signs for VTAM product,
VMAC28 which creates type 28 SMF records, has been tested.
Jun 13, 1992 Six subtypes (10x,11x,12x,13x,20x, and 30x) populate the
five MXG interval NPM datasets NPMINLU,NPMINNCP,NPMINPU,
NPMINRTM, and NPMINSES. The Version 2 Release 0 level of
Blue Line is required, as the type 28 records written by
earlier releases were not correct.
Change 10.094 DB2 Accounting Detail and Summary reports now will use
ANALDB2R the (new in 10.1) summarized (and thus smaller) ASUMDB2A
Jun 13, 1992 dataset if it is found in the PDB= input library list.
This will significantly reduce the run time of ANALDB2R.
(Only the Accounting Trace needs the detail transaction
records in DB2ACCT; the Accounting Detail is really a
summary, and ASUMDB2A is summarized at that same level!)
You can force MXG to use the DB2ACCT dataset with the
new USEACCT option: %ANALDB2R(PDB=PDB,USEACCT=YES);
If you have taken advantage of sending your DB2ACCT
data to the DB2ACCT ddname (Change 10.053), and you
have added ASUMDB2A to your BUILDPDB and WEEKBLD jobs
(Change 10.yyy), then your existing %ANALDB2R reports
with PDB=PDB specified will work just fine.
If you have put your DB2ACCT data in the DB2ACCT dd,
but did not build ASUMDB2A, to get your DB2 Account
reports, you will need only to add the DB2ACCT ddname
to the PDB= list of ddnames to be searched:
%ANALDB2R(PDB=PDB DB2ACCT);
The ANALDB2R reports now include the new DB2 2.3 fields
printed by DB2PM, except for the DDF data fields,
because we have no test data (hint, hint)!
Change 10.093 Trending of DB2ACCT data will now use the new ASUMDB2A
TRNDDB2A dataset if it exists in the WEEKly PDB library, but if
Jun 12, 1992 ASUMDB2A has not been created in your WEEKly PDB, then
TRNDDB2A will use the DB2ACCT dataset (which is more
expensive because it has many more observations than
does the ASUMDB2A dataset built by member ASUMDB2A).
Change 10.092 Minor cleanup of several of the TREND members. Variable
TRNDRMFI ZDATE was added where missing and INTERVAL (the number
TRND70 of RMF intervals) is created in RMF based datasets for
TRND70PR enhanced reporting capabilities.
TRND71
TRND72
Jun 12, 1992
Change 10.091 One user asked for it, here it is. Enhancement of the
MNTHCICS MXG TREND architecture to trend monthly in addition to
MNTHDBDS the strongly preferred weekly trending. MXG strongly
MNTHDB2A feels weekly trending must be used for capacity trends,
MNTHDB2S but some sites still think they need monthly trends too!
MNTHJOBS The MNTH.... are corresponding TRND.... members modified
MNTHRMFI to create MNTH.... instead of TRND.... output datasets,
MNTH70 with the interval set to MONTH. The MONTH PDB should be
MNTH70PR used as input, although WEEKly PDBs can be used (but the
MNTH71 current month's data will be incomplete until monthend.)
MNTH72
Jun 12, 1992
Change 10.090 The DB2ACCT dataset was externalized by Change 10.053,
ASUMDB2A but it may be too large for typical analysis. Just like
Jun 12, 1992 ASUMCICS summarizes CICSTRAN transactions records into a
much smaller, yet very usable PDB.CICS dataset in the PDB,
member ASUMDB2A summarizes DB2ACCT detail accounting (DB2
"transaction") records into the much smaller, yet also
very usable PDB.ASUMDB2A. ANALDB2R will use the smaller
PDB.ASUMDB2A (if it exists) in DB2 reports reduce the
amount of data that must be read. The input dataset is
the DB2ACCT dataset and the summarization is BY QWACLOCN
QWHCCN "date-hour" SHIFT (where "date-hour" is the value
of QWACBSC at the hour level).
IT IS STRONGLY RECOMMENDED that all DB2 sites add ASUMDB2A
to your daily PDB by adding
%INCLUDE SOURCLIB(ASUMDB2A);
following the include of (BUILDPDB); this has already been
added to the BUILDPDB step in the JCLPDB6 example.
Sites with extremely large DB2ACCT datasets may choose to
execute the ASUMDB2A include in a separate JCL step, since
the WORK space required for sorting and summarizing
DB2ACCT into ASUMDB2A can be greater than the WORK space
you normally allocate in your BUILDPDB.
If you follow the MXG recommendation and create ASUMDB2A
daily, you will also need to add code to EXPDBWEK (or
modifying WEEKBLD) to create the WEEK.ASUMDB2A dataset
in your weekly PDB from dailies. ASUMDB2 would have
been automatically included in MXG's BUILDPDB except for
the possible problem with work space cited above. The
dataset should prove to significantly reduce the cost of
ANALDB2R reporting.
Change 10.089 %VMXGSUM is enhanced to provide two new macro parameters
VMXGSUM MINTIME= and MAXTIME= that name the datetime variable
Jun 12, 1992 that will be used in building the minimum and maximum
datetimestamp values in each summary record. (Because
timestamps require LENGTH 8, and all SUM= MIN= MAX= or
MEAN= have a length of 4), new parameter names were
necessary. Variables MINTIME and MAXTIME are created in
the output dataset created by %VMXGSUM.
Change 10.088 BUILDPDB/3 redundant SORTs of DB2STAT0 and DB2STAT1 were
BUILDPDB removed because SORTs were relocated into DIFFDB2. Some
BUILDPD3 superfluous OPTIONS were removed from DIFFDB2. READDB2
DIFFDB2 standalone execution that unintentionally always sent the
READDB2 output to the PDB DDname was also corrected.
Jun 12, 1992
Change 10.087 Product Documentation "ADOC...." members have been added.
ADOCAAAA Twenty-five "Products" are now documented in the style of
Jun 12, 1992 future MXG online documentation, although none of the ADOC
members are completely finished, and the text is still in
draft (no spell check, no grammar check, author's "zzzzz"
mark where there's more to be written). Nevertheless, the
detail description of the MXG variables and datasets built
from each "Product" are now consolidated into an ADOC per
VMAC and the technical descriptions are now current. As
additional ADOCs are completed, they are added to the next
MXG PreRelease. Comments, criticism, and suggestions for
this ongoing project are welcome.
Change 10.086 Trending of Printer Throughput could cause divide by zero
TRNDPRTR message (but no impact on the Trend Database). Zerodivide
Jun 12, 1992 protect lines 002200 and 002300 (by adding the IF test):
IF denominator GT 0 THEN XXX = YYY / denominator ;
Thanks to Dan Barbatti, Southwestern Bell Telephone, St. Louis, USA.
Change 10.085 ANALDSET step IEBUPDTE did not create a null member name
ANALDSET of IMAC30DD in &SOURCLIB, and if the MXG.SOURCLIB member
Jun 12, 1992 IMAC30DD had been modified, a 311 error occurred. A new
line XY ADD NAME=IMAC30DD was added to the IEBUPDTE.
Thanks to Mike Crane, Annheiser Busch, USA.
Change 10.084 Pete Shepard and Jeffrey Crum, Ashland Oil, have provided
ASMIMSLG a significant contribution to MXG processing of IMS log
JCLIMSLG records. MXG's algorithms have tried to recognize an IMS
TYPEIMSA transaction after the fact from log records that do not
TYPEIMSB have a consistent token. Pete and Jeffrey's work solved
VMACIMSA that major weakness of the IBM IMS log records by creating
Jun 11, 1992 a pre-processor Assembly program that reads the IMS log
records, acts like the IMS queue manager, adds transaction
identifier to some of the log records, and even stores the
status of the IMS queues to initialize the next run. The
modified records are then SORTed and manipulated with a
new SAS program, TYPEIMSB (that does not create SAS data
sets, but instead manipulates IMS log records).
The fourth and final step of the algorithm uses a modified
version of MXG's TYPEIMS, (named TYPEIMSA for "Appended"
IMS record processing) to combine the two sets of IMS log
records into the _IMSTRAN.IMSTRAN MXG dataset.
The algorithm requires two additional IMS log records, the
10x and the 33x, that must be selected in your IMS archive
log job. These are the IMS log records now required:
01x 03x 07x 08x 10x 31x 33x 35x 36x
The ASM program, MXGIMSLG, is created by MXG member
ASMIMSLG, the ASM source code and the JCL to assemble and
link edit MXGIMSLG. Member ASMIMSLG also contains the
documentation of the algorithms, and a schematic of the
four steps of this "Appended IMS log" processing.
Member JCLIMSLG contains the JCL and documentation of the
four-step job to build the _IMSTRAN.IMSTRAN dataset:
STEP01 - Execute MXGIMSLG to read IMS log, split into
two OS files, IMSSUM and IMSMPRS. In addition,
reads INQUEUE (last run queue status) and then
writes OUTQUE (for input to next run).
STEP02 - SORT the IMSSUM file into IMSSUMSO.
STEP03 - Execute TYPEIMSB SAS step to read IMSSUMSO and
write out IMSMERGE OS file.
STEP04 - Execute TYPEIMSA SAS step to read IMSMERGE and
the IMSMPRS IMS log records to create IMSTRAN.
This enhancement fixes transaction response time measures,
but the IMS log records can never be used for accurate IMS
resource measurement by transaction, because IBM does not
create a resource record per transaction. The IMS 07x
record contains total CPU Time and DL/I calls per program
schedule event, which can include many transactions. Thus
IMSTRAN contains only the average CPU time and DL/I calls
for each group of transactions reported in each 07x.
Only a major change in IBM's functional design of the IMS
log can provide accurate IMS measurement of both resources
and responses of IMS transactions.
Nevertheless, this should be a major improvement in the
response measurement from IMS log records for sites that
do not have an IMS transaction monitor product.
The new algorithm has only been tested with IMS 3.1. It
is not my intention to test or revise the algorithm for
any earlier IMS versions. If any user lets me know that
the algorithm has been validated with earlier IMS log
records (by assembling MXGIMSLG using that version's macro
libraries), we will so report here in this Change text.
Thanks to Pete Shepard, Ashland Oil, USA, USA.
Thanks to Jeffrey S. Crum, Ashland Oil, USA, USA.
Change 10.083 Change 9.017 discussed how vars can be DROPped with a
DOC DROP statement in an EXTY member, but did not stress that
Jun 10, 1992 the DROP statement is global to ALL datasets being built;
if a variable name is DROPped in an EXTY member, it is
dropped from all other datasets with that variable name in
that SAS DATA step, even if the variable name is in the
KEEP= option of the DATA statement!
The only way to drop a variable name from a specific MXG
dataset is to copy the _VAR.... macro into member IMACKEEP
and erase the variable name from the KEEP= list for the
specific dataset. (Perhaps someday, I'll find a simpler
way.)
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Change 10.082 For TMS tapes with multiple datasets per volume, or for
TYPETMS5 datasets that span multiple volumes, the MERGE of their
Jun 10, 1992 TMSREC (volume record, with 1st dataset information) with
DSNBREC (dataset record for 2nd+ datasets on a volume) MXG
overlaid some dataset-related TMSREC variables with their
DSNBREC values requiring revision of the MERGE logic.
More important: the calculation of TAPEFEET was changed.
TAPEFEET of a dataset was calculated only if the RECFM was
F/FB/VBS/VS, which have absolutely known record length.
For V/VB/U files, MXG did not calculate a TAPEFEET,
because record length was not guaranteed. I now think it
better to always calculate the estimated TAPEFEET for all
datasets, even though it may overestimate the feet used
occasionally. Since the primary use of TAPEFEET is to
identify tapes using "lots" or "few" feet (i.e., "good" vs
"bad" tape usage), always calculating TAPEFEET will ensure
that tapes with lots of data (i.e., large BLKCNTS) aren't
misidentified as "few" because they have variable lengths.
Jun 30, 1992 Note: After Newsletter TWENTY-TWO was sent to printer:
Variable TAPEFEET now exists in both TMS.TMS and DSNBREC,
and is calculated for all datasets. Not only was the code
in TYPETMS5 redesigned, VMACTMS5 had to be changed. Now,
VOLSER in DSNBREC is equated to FVOLSER for multi-volume
files, because FVOLSER is the actual volume with this DSN,
and VOLSER was the first volume of the multi-volume tape!
(the original VOLSER in DSNBREC is now in OVOLSER).
Thanks to Tom White, US.Sprint, USA.
Change 10.081 Support for RSD's WSF (or WSF2) Release 3.4.1 added new
VMACWSF accounting fields ACCX.... to the WSFACCT (for AREP, ERD,
Jun 10, 1992 PROFILE, and WSF2 events) and to the WSFERD (for ERD Batch
and WSF2 Batch). It appears the job accounting fields and
jobname are those of the WSF2 Bundling job, and not the
(desired!) users accounting information.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 10.080 Variables FSTTRKR and FSRTRKW (tracks read and written)
VMACHSM can be negative (for Small Data Set Packaging, SDSP, or
Jun 9, 1992 for VSAM, but MXG input them as PIB2. instead of IB2.
We are still asking IBM what it means to read negative
tracks (or write them!)? IBM APAR OY58311/OY61585 fixed.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 10.079 EPILOG/MVS support was wrong. MXG failed to subtract 3
VMACEPMV bytes from two offsets, and did not protect for zero value
Jun 9, 1992 in triplets used in the two iterative DO groups. Before
each of the statements "DO SM180Oxx=SM180Oxx TO ..."
(where xx=IO or xx=EQ), insert the following two lines:
SM180Oxx=SM180Oxx-3+OFFSMF;
IF SM180Oxx GT 0 AND SM180Nxx GT 0 AND SM180Lxx GT 0 THEN
to correctly calculate the offset, and to conditionally
execute the (now following) iterative DO group only if all
triplet fields (offset, length, and number) are non-zero.
In addition, the RSRC subtype (SM180SUB='RSRC') record is
now deleted; it caused INVALID DATA FOR SM180RID message,
and "represents activity recorded by EPILOG that is not
obtained from RMF's SMF records. The RSCS subtype is not
documented further" according to Candle.
Thanks to Wayne Parrino, Avery Dennison, USA.
Change 10.078 Amdahl APAF product (Amdahl Processor Analysis Facility)
VMACAPAF creates a user SMF record describing MDF resource usage by
Jun 8, 1992 domain and LP within each domain that is now documented in
Appendix B, APAF Record Layouts of Amdahl's manual). The
preliminary variable names in MXG 9.9 were changed and now
the MXG variable names are based on the Amdahl documented
field names. Some previous fields are now reserved, and
storage variables are now in bytes, formatted by MGBYTES.
The number of LPs data kept is set in member IMACAPAF with
MXG %macro variable __NRLPS (yes, that's two underscores)
to only keep variables describing your environment, and
MXG defaults to keep four partitions (LP0-LP3) by setting
%LET __NRLPS=3;
Change 10.077 NPM reports caused DIVISION BY 0 because calculation of
ANALNPMR AVGOBYTE and AVGIBYTE were not protected for zero divide.
Jun 8, 1992 Now they are.
Thanks to Mike Jacques, Best Products, USA.
Change 10.076 Preliminary support for UNIX iostat and vmstat command's
XUNIX output data has been tested against ULTRIX data. The code
Jun 8, 1992 is temporarily located in the "X-rated" member XUNIX until
formal naming conventions for UNIX support have been
decided.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.075 Support for North Ridge Software's "The Network Director"
EXNRS... SMF record creates thirteen NRS..... datasets that are
IMACNRS described in the vendor's Network Administrators Guide,
TYPENRS under the topic of "Event Recording", thanks for this
VMACNRS significant user contribution, which included test data
Jun 8, 1992 for validation!
Thanks to Tom Jones, Banks of Iowa Computer Services, USA.
Change 10.074 INVALID VALUE FOR DATEJUL FUNCTION occurs with TMS record
VMACTMS5 with create date of 91000 (found in volume that was shared
Jun 5, 1992 between MVS and TPF). Now, MXG validates the julian date
is valid before creating CREATIME.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.073 Additional code added to avoid 213 or 314 ABENDS, caused
ASMVTOC primarily by VM DASD volumes shared with MVS, which do not
Jun 5, 1992 have a legitimate MVS VTOC. Now, these "bad" volumes are
bypassed and no longer cause ASMVTOC to ABEND.
Thanks to Wayne Beardsley, Citibank National Technology Div, USA.
Change 10.072 DB2 SQLCODE (SQL error code) can be negative, but MXG did
VMAC102 not know that, and thus SQLCODE was input as PIB4, causing
May 21, 1992 a return code of -204 to show up as 4,194,967,091! Change
both occurrences of SQLCODE PIB4. to SQLCODE IB4.
Thanks to Andrew Jeppeal, Marshalls, USA.
Change 10.071 VM/ESA dataset VXSYTCUP may contain only 49 observations
VMACVMXA if member TYPEVMXA is used to process MONWRITE output data
May 19, 1992 because of a misspelling. Change _DSYTCUP in line 010060
(inside the _PRNTALL macro definition) to _PSYTCUP. The
unintended invocation of _DSYTCPU (which deaccumulates the
VXSYTCUP dataset) inside _PRNTALL after OBS=50 was set in
TYPEVMXA caused the correctly built VXSYTCUP data set to
be re-built incorrectly with only 49 observations.
Thanks to Mark Kraut, Walgreens, USA.
Change 10.070 DCOLLECT value of 31Dec2155 expiration caused MXG to fail
VMACDCOL with an INVALID VALUE FOR FUNCTION DATEJUL message.
May 19, 1992 Change DATEJUL(CALEXPDT) to DATEJUL(ORGEXPDT) in 2 places.
In tests and calculation for DCDDATE1, DCDDATE3, UMCREDT,
UMLRFDT and UCCOLDT, remove -1900000 from both the IF test
and from inside the DATEJUL function. MXG converted dates
to yyddd format, which only supported years thru the next
millennium, but the SAS DATEJUL function supports date
yyyyddd formats beyond the year 2155 (the maximum year in
the present IBM calendar). In several labels, asterisks
were omitted and MACINE should have been MACHINE, and two
REBLK? variables are now spelled correctly.
Thanks to Chuck Hopf, Primerica, USA.
Change 10.069 SPMS Version 1.2.1.3 added a 4-byte field after SPMSRSV3
VMACSPMS causing errors. Pending documentation of the new field,
May 17, 1992 insert the following line after the @; after SPMSRVR3:
IF SPMSLEN3 GE 32 THEN INPUT +4 @;
(Note: In NL 22, SPMSRVR3 was misspelled as SMFPSRVR3).
Thanks to Pino Todesco, Western Australia Police, AUSTRALIA.
Change 10.068 Variable TAPE3490 (number of 3490 tape drives allocated)
IMACPDB is now added to PDB.STEPS (drives per step) and PDB.JOBS
May 17, 1992 (max drives in any step).
Thanks to Frank Vessell, ITT Consumer Financial Corporation, USA.
Change 10.067 TMON/CICS dataset MONITASK variable CREATIME was used in
ASUMCICS reports and summarization where STRTTIME should have been.
TYPEMONI Both variables were correctly described in the MXG
TYPEMON8 Supplement, but reports (See Change 10.066) and ASUMCICS
May 17, 1992 now use STRTTIME variable instead of CREATIME. Both are
still kept with equal values in MONITASK.
Change 10.066 TMON/CICS reporting with ANALMONI can loop, filling WORK
ANALMONI file, because STRTTIME from the interval dataset was used
May 17, 1992 where instead of STRTTIME from the MONITASK dataset. The
correction of CHANGE 10.067 corrects the problem. This
change provided a circumvention to ANALMONI that is now
no longer required after Change 10.067.
Thanks to Peter Paproota, BMI N.Y. Operations, USA.
Change 10.065 New dataset TYPE40_D can be created for each DD segment
IMAC40DD in type 40 SMF record. The old TYPE40 dataset creates 1
VMAC40 observation per SMF record, but there can be many devices
May 17, 1992 represented in a single dynamic deallocation event. MXG's
analysis of tape drive utilization (work in progress) will
need this new TYPE40_D dataset. New member IMAC40DD will
control whether observations are created in TYPE40_D; by
default, no observations are created, although comments in
IMAC40DD shows how to create only tape drive events.
Change 10.064 Variable CPURCTTM was invalid due to IBM APAR OY51878;
EXTY72 MXG 9.9 subtracted CPURCTTM from CPUTM in member EXTY72 to
May 15, 1992 prevent negative overhead values until IBM fixed their
error. Now, PTF UY77275 exists and does correct the CPU
value, so MXG has now eliminated the subtraction in this
Exit Member. If you install that PTF before MXG 10.1+, you
need to tailor member EXTY72 from MXG 9.9 into your USERID
and remove the subtraction, remembering to remove EXTY72
from your USERID.SOURCLIB when you install MXG 10.1+.
Change 10.063 Boole & Babbage IMF vars set from OPFLG1N2 & OPFLG3N4
VMACCIMS were not correct if multiple bits were on in these flags,
May 15, 1992 because MXG tested for the Hex value instead of the Bit
value. Variables RGNIOPT,BHTOON,DEPRECN,CPUNONE,CPUDEP,
BILLOVHD,TRNSYNC,BMPNO,DBIOWAIT, and DBIONONE could have
been affected. Change the hex test to bit test to fix.
Thanks to Mr. Steinkopf, Volksvagen Ag, GERMANY.
Change 10.062 Support for IBM CICS/ESA 3.3 type 110 subtype 2 Stats
CICINTRV records is added. IBM changes were incompatible and MXG
MECICALL 10.1 or later is required for CICS 3.3 statistics records.
PRCICALL MXG now no longer creates eleven statistic datasets whose
VMAC110 STIDs were eliminated by IBM in CICS 3.2.1 (they were all
May 14, 1992 summary records that were redundant with detail STIDs).
These datasets no longer exist and their Exit Members have
been deleted from the MXG Source Library:
STID Exit Member Dataset STID Exit Member Dataset
05 EXCICTST CICTST 53 EXCICCO2 CICCONST
26 EXCICLDT CICLDT 59 EXCICTC2 CICTCLT
35 EXCICTCT CICTCT 68 EXCICFCT CICFCT
38 EXCICLS2 CICLSRT 77 EXCICCO4 CICCONMT
41 EXCICLS4 CICLSRFT 82 EXCICBTA CICBTAM
44 EXCICDQT CICDQT
Because four of the above datasets had previously been
used in building the CICEODRV (shutdown statistics) and
CICINTRV (interval) datasets, member CICINTRV was changed
to summarize the detail data previously in CICDQT, CICFCT,
CICTCT, and CICTST. Additionally, exit members now exist
for the four datasets created by CICINTRV. The CICUSSRV
dataset can be large, since it represents every dynamic
resource, and you may wish to disable it in its exit.
Dataset Description Exit Member
CICEODRV - End-of-day "Shutdown" EXCICEOD
CICINTRV - Interval Statistics EXCICINT
CICREQRV - Requested Statistics EXCICREQ
CICUSSRV - Unsolicited (Dynamic) EXCICUSS
The order of the CICS statistics datasets was alphabetized
as were the labels for their variables, and member VMAC110
was renumbered. Fields added by IBM to several statistics
records are now supported.
Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.
Change 10.061 Support for IBM CICS/ESA 3.3.0 type 110 subtype 1 monitor
VMAC110 record is added. Twelve new fields added to CICSTRAN are
VMAC110M very useful, describing program and user storage, but the
IMACEXCL fields were added incompatibly (they were inserted in the
May 14, 1992 middle, rather than added at the end of the record) and
thus MXG 10.1 or later IS REQUIRED for CICS 3.3 CICSTRAN.
Member VMAC110M processes ONLY the monitor (and not the
statistic) subtype, but it should be needed only by sites
still using SAS Version 5 under MVS/370 where virtual
storage constraints exist.
The following table lists the MXG variables in CICSTRAN
which capture transaction-level virtual storage usage:
Virtual Program User User User
Storage Storage Storage Storage Storage
Area HiWaterMk HiWaterMk Getmain Occupancy
Amount Amount Count Page-seconds
Above 16MB:
ECDSA PC31CHWM SC31CHWM SCGETCH SC31COCC
EUDSA PC31UHWM STORHWMH SCGETCNH PAGESECH
ERDSA PC31RHWM
Total Above PC31AHWM
Below 16MB:
CDSA PC24CHWM SC24CHWM SCCGETCT SC24COCC
UDSA PC24UHWM STORHWMK SCGETCN PAGESECS
Total Below PC24BHWM
Above and Below
Total PROGSTOR
Change 10.060 TMS inactive DSNBs are now deleted before merge with TMS
VMACTMS5 records, because their existence created invalid results.
May 13, 1992 A DSNB exists in TMS when multiple datasets are created on
a VOLSER, but when that VOLSER becomes scratch and it is
reused, its old DSNB is not removed from the TMC, and this
old DSNB was incorrectly matched with the VOLSER, creating
an observation in TMS.TMS with incorrect dataset name.
Statement IF DSNBACTV='Y'; was inserted after 012100.
Thanks to Gary Matney, Twentieth Century Investors, USA.
Change 10.059 Invalid CICS/ESA type 110 records caused STOPOVER ABEND.
VMAC110 one site; MCTSSDRN was 16 but there were only 15 segments
May 12, 1992 and MXG did not protect for this IBM error. Now, the test
IF SEGSTRT+MCTSSDRL GT LENGTH+1 THEN DO;
NBAD110+1;
IF NBAD110 LT 10 THEN PUT " INVALID RECORD DELETED "
// _N_= APPLID= MCTSSDCA= MCTSSDCL= MCTSSDRL= COL=
ICICS= ;
DELETE;
END;
was inserted after each statement SEGSTRT=COL; to detect
and delete these bad records, while IBM investigates.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Change 10.058 "Invalid Data for WKLCPURF" messages result with TMON/MVS
VMACTMVS because when IBM eliminated these EBCDIC fields, TMON/MVS
May 12, 1992 wrote hex nulls instead of EBCDIC values, causing the SAS
error condition. The MXG data set is not affected and
variables (WKLCPURF,WKLIOCRF,WKLMSORF) are set to missing
values. Inserting a ?? format modifier for each variable
eliminates the invalid data message and hex dump.
Thanks to Marcia Ketchersid, Price Waterhouse, USA.
Change 10.057 Support for NETSPY Release 4.2 added new dataset NSPYNPSI
EXNSPYNP describing X.25 multi-channel lines, X.25 MCH PUs and X.25
VMACNSPY virtual circuits with 50 variables; variable DLYVALUE was
May 5, 1992 added to NSPYNCP, variables NTRISUBT,NTRISBTE to NSPYTR,
and dataset NSPYLINE now captures resources for six new
elements (X.25 line, PU, LU, and SNA switched line, PU,
and LU). The NTRI entry was internally reformatted.
Change 10.056 Using EXPDB... members to add SMF record processing to
EXPDBCDE your PDB is documented in the MXG supplement (pp 137-140).
May 4, 1992 However, in many instances, you may only want certain of
the SMF record's subtype's datasets to be created. If the
MXG architecture supports "subtype-level-processing" for
this record (see comments in its VMAC.... member), it is
easy to add only specific subtypes to your BUILDPDB.
(It is MXG's intention to extend "s-l-p" architecture to
all SMF records with subtypes.)
The following example shows how you would add DB2 type 102
subtypes 63 and 106 to your BUILDPDB.
Member Would contain
EXPDBIND %INCLUDE SOURCLIB(VMAC102);
EXPDBVAR MACRO _VARUSER _V102063 _V102106 %
EXPDBCDE MACRO _CDEUSER _HDR102 _C102063 _C102106 _END102 %
EXPDBOUT PROC COPY MT=DATA INDD=WORK OUTDD=PDB;
SELECT T102S063 T102S106;
Thanks to Nancy Ayers, General Electric Lighting Business Group, USA.
Change 10.055 Date selection in DB2 reports PMSACC01/PMSACC02 produced
ANALDB2R no report because code was relocated incorrectly. In the
May 3, 1992 %MACRO PMACC01 and the %MACRO PMACC02 definitions, find
the invocation of %DB2RSELA (once in each of the above
macro definitions), and after each of these %DB2RSELA,
insert the following four lines:
IF NOT INTREND THEN DO;
MINTIME=QWACBSC;
MAXTIME=QWACESC;
END;
Thanks to Nancy Ayers, General Electric Lighting Business Group, USA.
Change 10.054 VTOC processing did not capture archaic ISAM index space,
VMXGVTOF warning "CRITICAL ERROR IN VTOF PROCESSING". The FMT2
VMXGVTOC DSCB, which describes the space occupied by ISAM indices
May 3, 1992 is now properly processed.
Thanks to Hr. Leineweber, HUELS AG, GERMANY.
Change 10.053 DB2ACCT dataset can now be written to a DDNAME of your
ANALDB2R choosing, and unnecessary SORTs which wasted WORK space
ASUMDB2A were eliminated. High volume transaction datasets should
BUILDPDB be written to tape (or a separate DASD file) and thereby
BUILDPD3 avoid B37 ABENDs and pollution of the daily PDB. MXG has
DIFFDB2 done this for CICSTRAN, and now that same philosphy has
EXDB2ACC been implemented for DB2ACCT as well. However, if you
IMACDB2 do nothing, the DB2ACCT data will still be written to your
READDB2 PDB, and the only incompatibility of this change is that
May 5, 1992 the DB2ACCT dataset is no longer sorted, which could cause
an error if you build a weekly DB2ACCT expecting it to be
sorted. (If so, simply remove the BY statement following
WEEK.DB2ACCT in your WEEKBLD/MONTHBLD member.)
Of greater impact, however, is the philosophy that now the
DB2ACCT dataset is a transaction file that may not be in
the daily PDB; what about daily/weekly reporting? Just as
CICS transactions are written to a transaction file and
are then summarized into the PDB.ASUMCICS by ASUMCICS, the
DB2ACCT dataset can now be summarized into PDB.ASUMDB2A by
new member ASUMDB2A, and the summarized PDB.ASUMDB2A can
be used for DB2 reports PMACC01 or PMACC02 in ANALDB2R.
a.IMACDB2 now defines MACRO _DB2ACCT PDB % (i.e., default is
PDB). Change that default value to DB2ACCT if you want to
write the DB2ACCT data to the DDname of DB2ACCT (and then
add a //DB2ACCT DD to your job).
b.VMACDB2 and EXDB2ACC now output to _DB2ACCT.DB2ACCT, and
IMACDB2 is included by VMACDB2.
c.DIFFDB2's unnecessary PROC SORT DATA=DB2ACCT was removed.
(This was the primary abuser of WORK space in BUILDPDB.)
d.The PROC SORT DATA=DB2ACCT OUT=PDB.DB2ACCT in BUILDPDB/3
was eliminated, since the DB2ACCT data set has already
been written to _DB2ACCT as the SMF data was processed.
And DB2ACCT was removed from the PROC DATASETS;DELETE list
e.If ANALDB2R or READDB2 is used to read SMF data, and if
PDBOUT= is specified to save the created datasets, the
DB2ACCT dataset will be sent to the DDname in IMACDB2,
while all other selected datasets are sent to PDBOUT=.
Thus if you do not change IMACDB2's default of PDB, and
you specify PDBOUT=PDB, then all datasets created by these
two members will be written to the PDB DDname. If instead
you change the IMACDB2 DDname, the DB2ACCT dataset will be
sent to the IMACDB2 destination.
Thanks to Nora Spencer, Toyota, USA.
Thanks to Bill Stoneberg, National-Oilwell, USA.
Thanks to Neil Ervin, Huntington Bank Service Company, USA.
Change 10.052 LPAR CPU utilization reports created by this rewritten
GRAFLPAR member can use PDB or TREND library PR/SM datasets
Apr 30, 1992 ASUM70PR or TRND70PR. Comments within the member show how
to select and generate desired reports.
Change 10.051 Invalid data for SMFPSRVR reading CICS/ESA dictionary
UTILCICS records, because UTILCICS was not updated at the same time
Apr 30, 1992 that VMAC110 was updated to support IBM's changed format
of SMFPSRVR. 2. The correction is to replace two lines
039200-039300 which now read:
INPUT @OFFPROD SMFPSRVR 2.
APPLID $CHAR8. /*SMFMNPRN*/
with these three lines:
INPUT @OFFPROD SMFPSRVR ?? 2. @;
IF SMFPSRVR=. THEN INPUT @OFFPROD SMFPSRVR PK2.1 @;
INPUT APPLID $CHAR8. /*SMFMNPRN*/
Thanks to Dave Gosse, Univesity of Iowa Hospitals, USA.
Change 10.050 Specifying a DDname other than PDB in IMACMONI caused the
ASUMDBDS ASUMDBDS member to fail with dataset not found error. This
TRNDDBDS change also renames the dataset created by ASUMDBDS to be
Apr 30, 1992 named ASUMDBDS and thereby be consistent with MXG ASUMs.
Finally, TRNDDBDS was added for trending ASUMDBDS output.
Change 10.049 Graphic reports were not perfect. Charts were not printed
GRAFTRND if there were fewer than 40 intervals, the interval was
Apr 28, 1992 not always calculated correctly, and forecast line could
be skewed because the last-actual-value rather than the
last-predicted-value was used. If STAT=NO was specified
or specified in the wrong case, Axes statements were lost.
Workload bar chart axes values for projections were wrong.
All these glitches have been repaired.
Thanks to Van Xydis, VM System Center, USA.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.048 Support for AICorp's KBMS (Knowledge Based Management
EXAICOST System) user SMF record is added by this change, which
IMACAICO creates the AICOSTAT dataset with CPU time, EXCP count and
TYPEAICO elapsed time for each "transaction".
VMACAICO
Apr 30, 1992
Thanks to Kelly Raven, CSX Technology, USA.
Change 10.047 DB2 reporting for DBID and OBID did not print the actual
ANALDB2R name of the object. MXG built formats dynamically to map
Apr 30, 1992 these objects, but failed to use the format in the report
PUT statements. Many lines were altered in this change.
This change also added processing of the T102S183 dataset
to the SQL reports.
Thanks to Carl Koch, AT&T Westminster, USA.
Change 10.046 DB2 reporting LIBRARY SMF IS NOT VALID message occurs if
ANALDB2R PMSQL04 or TRANSIT reports are requested with PDB=SMF.
Apr 29, 1992 Insert after 009060 OR &PMSQL04=YES
and replace line 186700 (currently _ALLPAIR;)
with %ANALDBTR(PDB=&PDB1,PAIRS=ALL);
Thanks to Carl Koch, AT&T Westminster. USA.
Change 10.045 Using READDB2 with TRACECLS= parameter to select desired
READDB2 IFCIDs by trace class does not select all IFCIDs in all of
Apr 29, 1992 the classes you ask for (however, the IFCID= parameter can
be used to list the desired values, and it has no error).
READDB2 itself does not fail, but creates zero observation
datasets for some trace classes, which can cause ANALDB2R
to fail if it is invoked after the READDB2 invocation.
Correct this error by moving the %INCLUDE statement in
line 026400 to immediately after 007400.
Thanks to Carl Koch, AT&T Westminster. USA.
Change 10.044 The calculation of TAPEFEET from TMS data should include
TYPETMS5 test for RECFM='VS ' in line 005200 of TYPETMS5 and in
VMACTMS5 line 037300 of VMACTMS5.
Apr 28, 1992
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.043 Two RECFM codes, FS and VS, were not decoded by VMACRCFM.
VMACRCFM After line 002100 insert:
Apr 28, 1992 ELSE IF RECFMT='1000100.'B THEN RECFM='FS ':
and after line 003200 insert:
ELSE IF RECFMT='0199100.'B THEN RECFM='VS ':
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.042 The percentage of time when there are more Ready tasks in
VMAC7072 memory than there are Processor Engines is a much better
XMAC7072 indicator of CPU "stress", especially in LPARs, because it
Apr 27, 1992 directly measures when tasks are waiting for CPU dispatch.
MXG now creates variable PCTRDYWT in dataset TYPE70:
IF NRCPUS=1 THEN PCTRDYWT=SUM(OF READY02-READY15);
ELSE IF NRCPUS=2 THEN PCTRDYWT=SUM(OF READY03-READY15);
ELSE IF NRCPUS=3 THEN PCTRDYWT=SUM(OF READY04-READY15);
(repeated for NRCPUS up to 8), and is labeled
PCTRDYWT='PERCENT WHEN*READY TASKS*ARE WAITING'.
The only weakness of PCTRDYWT is that it does not identify
WHICH ready tasks are waiting, and with a well-designed
SRM you would typically have your lesser important tasks
Ready and waiting for CPU dispatch while your online tasks
are getting what they need.
Change 10.041 Line 398700 should be STID=77 instead of STID-77, and MXG
VMAC110 did not create observations in CICCONMT statistic dataset.
Apr 27, 1992 Fortunately for me, the STID=77 is the "total" record for
the "interval" STID=76 which was output in CICCONMR, and
thus no data was lost. IBM no longer creates any "total"
records starting with CICS/ESA 3.3, so all of the CICS
statistics datasets which end with "T" will have zero
observations in the future. Total records were redundant
with the interval data.
Thanks to Caron Knox, Willis Corroon Group, ENGLAND.
Change 10.040 Type 39 SMF record caused INPUT STATEMENT EXCEEDED with
VMAC39 subtype=5. Change all occurrences of NE 0 to GT 0
Apr 22, 1992 (a missing value unintendedly satisfied the NE 0 test).
Thanks to Miller Dixon, Continuum, USA.
Change 10.039 The NET-PASS variable NETPACTM was the total response
VMACNETP for NETPTRNS transactions, but it should have been the
Apr 22, 1992 average response time. Insert after 010200 this line:
IF NETPTRNS GT 0 THEN NETPACTM=NETPACTM/NETPTRNS;
Thanks to Nancy Ayers, General Electric Lighting, USA.
Change 10.038 Candle Omegamon for CICS V550 erroneously stored nulls in
VMAC110 the packed decimal field SMFPSRSN, causing MXG to print a
Apr 22, 1992 hex dump of the SMF record. Candle incident 201387 fixes
their error, but MXG circumvents the unwanted hex dump
by adding ?? to the input statement so it now reads:
SMFPSRSN ?? PD4.
Change 10.037 JES2 Spool Offload type 24 SMF record can cause STOPOVER
VMAC24 ABEND because tests for OFFESS and NRESS in line 016100
Apr 21, 1992 must be GT 0 instead of NE 0. (Missing values satisfy the
NE 0 test but not the GT 0 test.)
Thanks to David Ehresman, University of Louisville, USA.
Change 10.036 VM/ESA 1.1.1 is now supported, creating 3 new datasets
FORMATS and adding new variables to existing datasets:
VMACVMXA a.Variables added to existing MXG datasets:
Apr 20, 1992 VXSYTSHS - variables CALNUMSA and RSACTSHR.
VXMTRSYS - flag variable SYSMASFI.
VXMTRPRT - PCCCSU and PFXCFO.
VXSTOSHR - ASCCSPGR,SPGW,SPXR,SXWT,ASCSMIGC,VMDCTLKP and
VMDCTNPS. IBM renamed VMDCTPST to ASCCSPST,
but MXG continues to call it by its original
name, and did not create a redundant variable.
VXBYUSR - VMDASMCT,BLKCT,MDCIA,OPCTN (from VXUSEACT).
VXIODDEV - VIUTIM/CNT for IN,LV, and OT, and RDEVMCIA.
VXIODCAD - CALDATA ($CHAR160) replaced CALPSF ($CHAR96).
b.New data sets VXSTOASI (Interval Shared Address Space
paging activity), VXSTOASC (Address Space Create Event),
and VXSTOASD (Address Space Delete Event) were added.
c.New format MGBYTRT expresses byte rate in B/SEC, KB/SEC,
MB/SEC printed units, similar to MGBYTES for byte values,
and is used for several new storage movement variables.
d.These changes have been tested with HCPCPEID=1101 release.
Change 10.035 TMS variables EDMTAP and DYNAM were incorrect. The bit
VMACTMS5 test should be the '20'X bit for EDMTAP (instead of '40'X)
Apr 20, 1992 and the '10'X bit for DYNAM (instead of '20'X).
Thanks to Ruth Whitney Parker, Citibank South Dakota, USA.
Change 10.034 If you added a SORTBY= operand for DB2 Reports the report
ANALDB2R did not break where you expected; only the first variable
Apr 16, 1992 in your SORTBY= list was used. Lines 006250 and 006260
both now start with %ELSE %IF LENGTH( .... Both must be
changed to start with only %IF LENGTH( ....
Reports requested without SORTBY= had no error.
Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.
Change 10.033 Support for the Software Ag "Natural Process" SMF record
EXNATPAC is added by this change. Dataset NATPACCT contains one
IMACNATP observation for every SMF record, written at user logoff
TYPENATP (including a termination of Natural Process before the
VMACNATP user can logoff), with the Natural Process 8-byte user id,
Apr 15, 1992 the CPU time and I/O count of that session.
Thanks to Joanne Turpie, Department of Labour, Wellinton, NZ
Thanks to Terry Proops, Department of Labour, Wellington, NZ
Change 10.032 Two references to DATA=SMF should have been DATA=LLAEXIT
ANALLLA in this analysis example.
Apr 15, 1992
Thanks to Hanno Bresch, SAS Institute, GERMANY.
Change 10.031 New variables ACTDLYTM/RESDLYTM/DSPDLYTM are now created
VMAC30 in TYPE30_4, TYPE30_V, PDB.STEPS and PDB.JOBS datasets.
IMACPDB These delta times are described on pages 44-45 of the MXG
Apr 15, 1992 Guide, but were not kept as unique MXG variables until a
CPE class student went home and observed confusing values,
because pages 44-45 were not completely accurate. After
further research (and clarification from Bernie Pierce of
IBM) they now clearly deserve their own variables.
ACTDLYTM='Delay duration*executing*not active'
(EXECTM-ACTIVETM)
This delta includes time the address space was
Detected Wait or Long Wait swapped out by SRM,
(which includes TSO user's think time).
RESDLYTM='Delay duration*active*not resident'
(ACTIVETM-RESIDTM)
This delta is the time SRM wanted the ASID to
be in the Multi-Programming Set, but was unable
to get the ASID resident. This includes all
swapped out time (except DW/LW, which is caught
in ACTDLYTM) plus the time to actually do the
swap in. Another name might be MPL Delay time,
because all of the swap out and non-resident
time while active is the time when the Target
MPL was not high enough to include this task.
This delta divided by SWAPS is an estimate of
the time-to-swap-in a task, but since SWAPS
counts both RESDLYTM and ACTDLYTM swap events,
and since RESDLYTM includes the time to swap in
and the time waiting to swapin and the time
swapped out, the estimate is usually poor!
DSPDLYTM='Delay duration*resident*not dispatched'
(RESIDTM-CPUTCB+SRB+HPT+RCT+IPT)
This delta is the time the task was resident
in memory but was not executing instructions.
It includes delay for CPU dispatch (when you
enter the MPL set you don't immediately get
CPU - a hot CICS transaction may still have the
processor), delay for I/O (you execute a few
CPU instructions and then issue an I/O and you
wait for IOS to get the data for you), delay
due to page faults (the next page is not
in memory and you wait for that page to be
brought in), and delay due to tape mounts.
NOTE: PRIOR TO AUG, 1994, THIS CHANGE TEXT SAID THAT TAPE MOUNT
DELAY WAS INCLUDED IN ACTDLYTM, BUT THAT WAS IN ERROR. DELAY FOR
TAPE MOUNTING HAS ALWAYS BEEN INCLUDED IN DSPDLYTM. SEE THE NEW
SCHEMATICS IN MEMBER ADOC30 AND SEE CHANGE 12.142.
Schematic step duration example (numbers from a day's TSO session):
ELAPSTM
|-----------------------------------------------------------------|
| |
INITTIME ALOCTIME LOADTIME ENDTIME
|---------|---------|---------------------------------------------|
DSENQTM ALOCTM / EXECTM |
/ |
/ |
/ |
/ |
/ |
/ EXECTM |
/ 14:29:37.42 |
|------------------------------------------------------|
| |
| ACTDLYTM ACTIVETM |
| 14:16:57.90 759.52 |
|--------------|---------------------------------------|
| |
| RESDLYTM RESIDTM |
| 04.22 755.30 |
|------------|--------------------------|
Session TGETS=1275 | |
TSO/MON TRANS=1276 |DSPDLYTM CPUTM|
| 654.13 101.17|
|--------------|-----------|
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 10.030 JCLTEST6 gets INVALID DATA FOR SMFTIME when a VSAM SMF
JCLTEST6 file is used for step SMFSMALL, because of SAS 6.07 Error
Apr 15, 1992 V6-SYS.DATA-3550, which affects only the creation of BSAM
files from VSAM input. There is no error in creation of
SAS datasets from VSAM input.
The error only occurs if the INFILE SMF START=BEGINCPY
parameter has BEGINCPY not equal to one. To create a
BSAM file of SMF records from a VSAM file, MXG has to
set BEGINCPY=5 (to start the copy in byte 5 of the
VSAM record, and thereby skip over the unwanted first
four bytes containing RDW/SDW of the VSAM record).
This is done in MACRO _SMF defined in member VMACSMF.
This error has been fixed by SAS ZAP MV313550. Only the
members JCLTEST6/JCLTEST use START=BEGINCPY logic, and
only in step SMFSMALL; either install the SAS ZAP or use
a non-VSAM file for the SMF ddname in step SMFSMALL.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 10.029 Cosmetic. Variable QWACARNW in VMAC102 had no asterisks
VMACNSPY in its label. Added asterisks as in variable QWACARNR.
Apr 15, 1992
Change 10.028 Variable SESSMGR was misspelled once as SESSGMR, causing
VMACNSPY it to never have value "Y".
Apr 10, 1992
Thanks to Lindsay Oxenham, State Electricity Commission of Victoria.
Change 10.027 Comments only were changed. The reference to _CICEXCL in
IMACCICS comments do not apply to IMACICS; the Exclude Logic macro
Apr 10, 1992 _CICEXCL is defined/described in member IMACEXCL.
Thanks to Don Sively, E-Systems, USA.
Change 10.026 Dataset TYPE0203 was not deleted from the WORK file after
BUILDPDB PDB.TYPE0203 had been built. MXG "housecleans" the WORK
BUILDPD3 library in BUILDPDB to minimize the amount of workspace
Apr 9, 1992 required. TYPE0203 had been overlooked when added.
Thanks to Tracy Blackstone, Kaiser Foundation Health Plan, Inc, USA.
Change 10.025 SMF type 41 DIV (Data In Virtual) Access/Unaccess records
VMAC41 variables ACCSTIME and UACCTIME are timestamps and not the
Apr 9, 1992 durations implied by the SMF manual. Hex value 'A57F3640'
expanded to 8 bytes was 05APR92:08:50:33 in a record with
SMFTIME=05APR92:09:09:00 in a TYPE41AC observation after
this change. (That large delta of 19 minutes confuses me;
if you use this record, what's your data show?). Change
ACCSTIME PIB4.2 to ACCSCHAR $CHAR4.
UACCTIME PIB4.2 to UACCCHAR $CHAR4.
and insert after the appropriate @; one of the following:
ACCSTIME=INPUT((ACCSCHAR||'00000000'X),TODSTAMP8.);
UACCTIME=INPUT((UACCCHAR||'00000000'X),TODSTAMP8.);
and give both variables format DATETIME21.2 and LENGTH 8.
IBM APAR OY19780 is the Documentation Error acknowledging
these fields to contain the first 4 bytes of TODSTAMP.
Thanks to Terry Poole, SAS Institute Cary, USA.
Thanks to Richard Bear, Gulf States Toyota, USA.
Change 10.024 MVS Accounting fields (+ additional DB2 accounting data)
FORMATS were added to DB2ACCT and some trace records by IBM in a
VMACDB2 revision included in DB2 2.3 release, but documentation
VMAC102 did not arrive in time for MXG 9.9. Additionally, format
Apr 9, 1992 values for PACKADM were added to the IFCID 140/141 data.
This enhancement uses your site's tailoring in IMACACCT
to set the length of the ACCOUNTn variables that are kept.
These new accounting variables are added to DB2ACCT:
Variable Type Length Format Label
ACCOUNT1 CHAR ?? FIRST JOB*ACCOUNT*FIELD
ACCOUNT2 CHAR ?? SECOND JOB*ACCOUNT*FIELD
ACCOUNT3 CHAR ?? THIRD JOB*ACCOUNT*FIELD
QMDAASLN NUM 4 BYTES USED IN QMDAAINF
QMDAAUTH CHAR 8 DB2 AUTHID
QMDACNAM CHAR 8 DB2 CONNECTION*NAME
QMDACORR CHAR 12 DB2 CORRELATION*ID
QMDACTYP CHAR 8 DB2 CONNECTION*TYPE
QMDALOCN CHAR 16 DB2 LOCATION NAME
QMDALUNM CHAR 8 SNA*LU*NAME
QMDANETN CHAR 8 SNA*NETID
QMDAPLAN CHAR 8 DB2 PLAN
QMDAPMOD CHAR 1 PRODUCT*MODIFICATION*LEVEL
QMDAPREL CHAR 2 PRODUCT*RELEASE
QMDAPTYP CHAR 10 $MGDB2PN. PRODUCT*NAME
QMDAPVER CHAR 2 PRODUCT*VERSION
IBM's DB2 group reformatted the standard MVS account data!
Instead of sensibly copying the existing, well-known, and
already-decoded MVS accounting string (which contains a
length-field preceding each account-field), the DB2 group
decided to eliminate the length fields and instead insert
an 'FF'x byte as a delimiter between account fields! This
unnecessary inconsistency by DB2 required a new algorithm
(and of course any new algorithm is an exposure to error)
that required 120 lines of SAS code plus time to test!
Consistency would have been cheaper and lots safer!
Change 10.023 The SAS 5.18 Circumvention for the 344 Compiler Error in
XMAC7072 member XMAC7072 will cause UNINITIALIZED VARIABLE messages
Apr 8, 1992 because the final version of VMAC7072 was not edited into
XMAC7072. Copy in VMAC7072 into XMAC7072, replace all 410
lines in the DO group following 'NOT MVSXA' with this
single line : IF SUPATRN=' ' THEN SUPATRN=' ';
to create the corrected XMAC7072 member.
Thanks to Ken Thomas, Maryland Casualty Company, USA.
Change 10.022 Support for ROSCOE Release 5.7 changes to SMF Records.
EXROSPRN SMF record creates two new subtypes and MXG creates a new
EXROSSTA dataset for each: ROSCOPRN - ROSCOE Printing Services,
FORMATS subtype '80'x, and ROSCOSTA - Roscoe Statistics, subtype
VMACROSC '34'x. Both new ROSCOE datasets appear to have useful
Apr 8, 1992 new information about your ROSCOE subsystem, and its PRINT
activity. This change added about 250 lines.
Thanks to Dave Thorn, Dow Jones & Company, USA.
Change 10.021 New NPMHP, NPMMP, and NPMLP variables for Hi/Lo/Med Prty
TYPE28 bytes sent/received were not all kept, and some had "Sent"
Apr 7, 1992 in their label instead of "Received".
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 10.020 Landmark CICS records may produce ERROR. INVALID OFFSETS
TYPEMON8 message with LENGTH=0 in the message. The first two bytes
TYPEMONI of the Landmark record contain zero, instead of the actual
Apr 6, 1992 record length. (When/Why Landmark made the change is not
known). Change member TYPEMON8: Change "LENGTH" in lines
064700 and 064900 to "LENMONI" so that the field in these
two bytes no longer overrides the LENGTH=LENGTH value that
is captured in the INFILE statement. Archaic TYPEMONI for
Landmark Version 7 was similarly changed for consistency.
Thanks to David Bane, Jefferson County (Colo) Public Schools, USA.
Thanks to Chun-Heng Liu, Bellcore, USA.
Change 10.019 Cosmetic cleanups. Hex dumps produced when MXG finds data
VMAC110 invalid in type 110 records are now only printed for the
VMACSMF first two records. MXG notes of bad records are still put
Mar 27, 1992 on the log for the first 20 occurrences of a bad record.
Apr 20, 1992 Back-to-back type 02 or 03 (dump header/trailer) records
were not expected by VMACSMF's new messages, and the time
of the FIRST RECORD IN GROUP message was not correct.
(I wondered why SMFDUMP output would begin with a pair
of type 02 records, and with the first record's timestamp
several hours later than the second record, but realized
the output was first dumped by SMFDUMP and was then later
copied by SMFDUMP which added the 02 at the beginning and
the 03 at the end of the copy too!).
Change 10.018 Very obscure problem. DASD VTOCs with datasets defined to
VMXGVTOC have a "Standard User Label" (DSORG=PS-SUL) cause an MXG
VMXGVTOF note CRITICAL ERROR IN VTOC PROCESSING, EXTENTS NOT FOUND.
Mar 27, 1992 PS-SUL datasets have NREXTNTS=1 in their DSCB1, but two
extents are contained in DSCB1: extent #0 with EXTYPE=40x
for the one track Standard User Label, and extent #1 with
the real file. MXG now captures this extra track/extent
and includes it in TRKSALOC and TRKSUSED (note, however,
ISPF and LISTVTOC do not properly count this SUL track).
The change is in the FMTID='1' logic in members VMXGVTOF
and VMXGVTOC. The changes to VMXGVTOF are:
a) Move lines 042900 and 043000 (OUTPUT VTOC1/DSNAMES)
to after 044400.
b) Delete line 044000 (IF FIRST EQ 0 THEN DELETE).
c) Change line 044300 (OUTPUT EXTENT;) to now read
IF FIRST GT 0 THEN OUTPUT EXTENT;
d) Insert four lines after 044300 reading:
IF EXTYPE EQ 40X THEN DO; /*STANDARD USER LABEL*/
NREXTNTS=NREXTNTS+1;
TRKSUSED=TRKSUSED+1;
END;
The same changes need to be made to VMXGVTOC. Line numbers
are: a) 055700 and 055800 to after 057200, b) 056800,
c) 057100, and d) after 057100.
The only PS-SUL datasets found thus far are the log files
created by Omegamon/CICS Version 500!
Thanks to Mike Jacques, Best Products, USA.
Change 10.017 Invalid CICS/ESA Type 110 Subtype 2 Stats records can
VMAC110 cause MXG to loop. MXG detects the bad record and PUTs a
Mar 25, 1992 note on the log "UNEXPECTED STATISTICS SUBTYPE", but MXG's
attempt to skip over an unexpected segment fails when the
segment is corrupted (i.e., it has STILEN=0). Line numbers
408200 and 408300 currently read:
IF (COL+SKIP LE LENGTH+1) THEN INPUT +SKIP @;
ELSE INPUT;
but they must be changed to read:
IF (COL+SKIP LE LENGTH+1) AND SKIP GT 0 THEN INPUT +SKIP @;
ELSE DELETE;
The cause of the single occurrence of this type of
corrupted record is still under investigation.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 10.016 Documentation note for TYPE6 (and PDB.PRINT) datasets.
ADOC6 The fields SMF6DDNM, SMF6DSNM, SMF6PRNM and SMF6STNM that
Mar 25, 1992 were added by PSF to type 6 SMF records do NOT exist in a
type 6 record created by JES. Those fields exist only in
the PDDB built by PSF and are not in the JOE built by JES.
The variables exist, but their values are blank for DDname
DSname, Procname and Stepname if JES did the printing.
IBM APAR OY48265 documents their omission by JES.
Thanks to Marcia Ketchersid, Price Waterhouse, USA.
Change 10.015 Support for NETSPY Token-Ring records create the new MXG
EXNSPYTR MXG dataset NSPYTR, thanks for this significant user
VMACNSPY contribution.
Mar 25, 1992
Thanks to Lois Robinson, M & I Data Services, Inc, USA.
Change 10.014 The four new swap events (SWAPIC, SWAPIP, SWAPMR, SWAPAW)
VMAC71 always had missing values because the test in line 084500
Mar 25, 1992 IF LENSWAP GE 360 THEN DO; must be changed to read
IF NRSWAPSG GE 15 THEN DO;
Additionally, variables SWAPSHRT (logical swap candidates)
SWAPLGPY (logical swaps actually swapped) and PCTLSWAP
(pct logical swaps that swapped) used to be MVS/370 only,
but are now calculated for XA and ESA environments by the
addition of these three lines after line 091400:
SWAPSHRT=SWAP-SUM(PHYEXT,PHYAUX);
SWAPLGPY=SUM(LOGEXT,LOGAUX);
IF SWAPSHRT GT 0 THEN PCTLSWAP=100*SWAPLGPY/SWAPSHRT;
Thanks to Lois Robinson, M & I Data Services, Inc, USA.
Change 10.013 STOPX37 Product's SMF Record for Release 3.4 is supported
VMACX37 by changing EQ 'X37 33' THEN to GE 'X37 33' THEN
Mar 24, 1992 because the record format was (apparently) unchanged. The
variable STEPCPU must be changed to STPCPUTM in two places
so the CPU time will be kept by MXG.
Thanks to Mike Jacques, Best Products Co., Inc, USA.
Change 10.012 MVS/ESA V4.2 Dynamic I/O Reconfiguration is now supported
ASMTMNT in these "monitor" programs provided by MXG. The MXG Tape
ASMVTOC Mount Monitor, ASMTMNT, the MXG Fast VTOC Reader, ASMVTOC,
ASMVVDS the MXG VVDS Reader, ASMVVDS, and the MXG SAS Function to
FMXGUCBL Dynamically Allocate All Disks, FMXGUCBL (now redundant in
Mar 13, 1992 purpose with the ASMVTOC program), all use the new UCBSCAN
service so these programs will recognize new devices that
were added by MVS/ESA after IPL.
Thanks to Bill Fairchild, Royal Software Associates, USA.
for enhancement.
Thanks to Guy Garon, Verstand, CANADA.
for review of Bills' work
Change 10.011 SPMS 1.2.1.3 writes invalid record if a volume is deleted
VMACSPMS or renamed, without first changing SPMS parameters. The
Mar 13, 1992 resultant SMF record contains a value of 1 for SPMSREXT,
but sections 3/4 do not exist in the record, causing MXG
to STOPOVER abend. This is really an Amdahl problem, but
this circumvention protects their error. Change
DO _I_=1 TO SPMSREXT; to read
IF LENGTH GT 188 THEN DO _I_=1 TO SPMSREXT;
(Note: NL 22 misspelled 1.2.1.3 as R2.1.4).
Thanks to Peter Evans, Inland Revenue, Worthing, ENGLAND.
Change 10.010 TYPE70PR variable NRPRCS, number of logical partitions
VMAC7072 is still incorrect after the PR/SM Effective Dispatch Time
Mar 12, 1992 APAR is installed. Change 9.179 subtracted one for the
pseudo partition "PHYSICAL", but since that partition
segment is last in the actual record (even though it has
the Logical Partition Number LPARNUM of 0), only the
observations in TYPE70PR for LPARNAME of PHYSICAL have the
correct number of logical partitions! Line 131110,
IF LPARNAME='PHYSICAL' THEN NRPRCS=NRPRCS-1;
must be deleted, and a new line must be inserted after
line 133220 (SKIP=SKIP-16;, inside the DO group to read
LCPUEDTM) containing:
NRPRCS=NRPRCSS-1;
(yes, the variable on the right does have an extra 'S').
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 10.009 Datasets TYPE70PR, DB2STAT0 and DB2STAT1 were added to
WEEKBLD BUILDPDB/3 in MXG 9.9, but were not added to WEEKBLD or
MONTHBLD MONTHBLD. Now they have been added, with these BYs:
Mar 10, 1992 WEEK.TYPE70PR:
BY SYSTEM STARTIME LPARNUM LCPUADDR;
WEEK.DB2STAT0:
BY SYSTEM QWHSSSID QWHSSTCK;
WEEK.DB2STAT1:
BY SYSTEM QWHSSSID QWHSSTCK;
But what about DB2ACCT; wasn't it added to BUILDPDB? Yes,
but, since Change 10.053 now gives you the choice of the
destination of the DB2ACCT dataset, and since I don't know
if you really want to put your detail DB2ACCT data in the
weekly PDB, I can't automatically add it to your weekly
PDB for you; you'll have to do that yourself, (with no BY
statement, since it is no longer sorted), if you really
want detail DB2ACCT data weekly!
Change 10.008 Sites that had added DB2ACCT to their PDB under MXG 8.8
WEEKBLD may get a NOT SORTED condition in WEEKBLD under MXG 9.9,
Mar 10, 1992 because your previous sort order might be different than
Apr 20, 1992 the sort order used by MXG 9.9. Simply remove the BY
May 5, 1992 statement from your WEEKBLD and the daily datasets will be
concatenated instead of interleaved in sort order.
This is not only a circumvention to this specific problem,
but in fact is the way of the future, as DB2ACCT is no
longer built in sort order; see Change 10.053!
Change 10.007 Variable TPXELAP has wrong value. Line 052200, which is:
VMACTPX TPXELAP=TPXELAP*900/40812;
Feb 27, 1992 must be deleted. The value is correct without conversion.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 10.006 Cosmetic change. Variable SMFT0BST should have format of
VMACCMA DATETIME21.2 and should have LENGTH of 8.
Feb 27, 1992
Thanks to Ken French, Wisconsin Gas, USA.
Change 10.005 Type 42 SMF record causes STOPOVER ABEND. One ABEND is
VMAC42 because APARs OY48288 and OY39393 incompatibly re-format
Mar 9, 1992 the record, and require a new VMAC42 member to process the
Mar 14, 1992 completely restructured record. However, MXG could also
fail on records created before the above APAR, because the
NRSTOR in line 020300 should have been (NRSTOR-1). Since
the original records were not correct, the only thing that
makes sense, if you want to process the type 42 record,
(it contains 3990 cache statistics if you have SMS volumes
behind the cache) is to install the above APARs and to ask
for MXG PreRelease 10.1, because these two APARs correct
the errors previously reported (but not fixed) in APAR
OY36035 and OY39393. MXG circumvention for those two
earlier APARs was removed in this almost complete rewrite
of VMAC42. However, users with IBM's Cache RMF Reporter
or Legent's DASDMON/ASTEX products have said they found
TYPE42 added nothing useful to those two products.
Revision 1MAR94: New subtypes of the type 42 record added
great value to the type 42 record! See later changes!
Thanks to Greg Scriba, Budget Rent-A-Car Corp, USA.
Thanks to Glenn Hanna, Textron Defense Systems, USA.
Change 10.004 The value of offset P3 had previously been hardcoded to a
VMXGHSM value of 297 or 405 depending on the release of HSM, but
Mar 9, 1992 it now can be calculated independent of release. In lines
152300 and 153000, replace "405" with "MCDNVSNO+65".
Additionally, MCDMCNAM in lines 140500 (label=SMS...) and
141600 (... $HEX2.) should have been MCDSMSFG. Without
this change, MCDMCNAM printed funny because it was given
the $HEX2. format.
Thanks to Roger Edwards, South Carolina Electric & Gas Company, USA.
Change 10.003 PSF type 6 records had FORM truncated to four bytes. The
VMAC6 original PSF record did not contain the 8-byte FORM name,
Mar 9, 1992 and old MXG code that bypassed inputting the 8-byte field
should have been removed when PSF added the longer field.
Lines 026000 thru 026300 need to be replaced with:
IF SMF6LN3 GE 14 AND LENGTH-COL+1 GE 8 THEN
INPUT FORM $CHAR8. @;
since the 8-byte form name is now in all type 6 records.
Thanks to Lars Hylin, TryggHansa-SPP, SWEDEN.
Change 10.002 Line 184600 changed to _IMSTRAN.IMSTRAN instead of
TYPEIMS IMSTRAN._IMSTRAN, but using MXG's suggested DDNAME of
Mar 9, 1992 IMSTRAN for the _IMSTRAN value caused no error condition!
Only if you used a different DDNAME did an error occur.
Thanks to Richard S. Ralston, Rochester Telephone, USA.
Change 10.001 DB2 Reports truncated values for eight character values,
ANALDB2R and the System Parameter Report ABENDs with "Variable Not
Mar 9, 1992 Found" due to inadequate testing of the final 9.9 code.
a.Insert the following line in two places, after line 016050
and after line 025220:
LENGTH DB2 AUTHID PLAN CONNID CORRNAME CORRNUM
DB2LOCAL DB2REMOT $ 8 ;
b.Replace all occurrences of SM102SSI with QWHSSSID. These
are the lines: 088580, 088620, 093840, 095140, 096260.
LASTCHANGE: Version 10
=========================member=CHANGE09================================
/* COPYRIGHT (C) 1984,1992 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is the Production Version MXG 9.9, dated March 1, 1992.
All Changes listed in this member have been installed in MXG 9.9.
HOT NOTES:
Several new changes were added after NEWSLETTER TWENTY-ONE went to
press; see the Change Log, below, for Changes 9.236 thru 9.245.
The library now has more members, lines, datasets and variables than
was stated in the newsletter. This final MXG 9.9 library contains
1,605 members, 388,651 lines of code, builds 1,093 datasets with
41,332 variables documented in DOCVER with delta-doc in DOCVER09.
Over 800 sites have installed a PreRelease of MXG Version 9!
The installation instructions for MXG 9.9 were contained in NEWSLETTER
TWENTY-ONE, which is contained in member NEWSLTRS, repeated also
below in this member.
I. MXG Version Status.
1. Production Version is now MXG 9.9, dated March 1, 1992.
MXG Version 9.9 was accompanied by Newsletter TWENTY-ONE.
All Changes in this newsletter have been installed in MXG 9.9.
The MXG 9.9 library contains 1,605 members, 388,651 lines of code,
and builds 1,093 datasets with 41,332 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 Boole & Babbage 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.
V. 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.
IMACXXXX 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).
VMACXXXX 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.
VI. SAS Technical Notes.
1. 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.
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.241 are contained in MXG Version 9.9 Mar 1, 1992
Changes thru 9.235 were printed in NEWSLETTER TWENTY-ONE 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 2.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 Boole & Babbage CONTROL-D SMF 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.
VMAC28 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:
NEXTCHANGE: Version 9 72
Change 09.245 Yet another IMS idiosyncrasy was discovered after MXG 9.8
TYPEIMS and corrected by this contributor. For Message Switching,
Feb 20, 1992 each transaction in a single logical business task has the
same ARRVTIME (i.e., the arrival time of the first of the
group). Since RESPONSE time is calculated from ARRVTIME
to ENDTIME, this caused the calculated response time for
Message Switched transactions to be overstated. Russell
tried to use SEQNO and NMSGSW to identify each group of
transactions, but that algorithm did not always uniquely
identify a group, and IBM was unwilling/unable to provide
technical validity of those fields. Thus the solution was
to sequence the IMSTRAN dataset and then, after the fact,
recognize (using the LAG function) and correct the
ARRVTIME of subsequent Message Switched transactions.
Thanks to Russell Dewar, NM Computer Services Pty., AUSTRALIA.
Change 09.244 The "Prudential Writer" program is a "freebie" for Xerox
VMAC6 9700 forms management, which writes a type 6 SMF external
Feb 19, 1992 writer record. Unfortunately, the READTIME value put in
the SMF record is not READTIME but JCNVTIME, and thus this
type 6 record cannot be matched with the other SMF records
written by the same job! There is presently no fix, but
their error was only discovered today! If you use this
program, call/fax us for a status update.
Thanks to David Ehresman, Univerity of Louisville, USA.
Change 09.243 JES2 SPOOL Transfer Program can cause real purge records
BUILDPDB to be mis-recognized by BUILDPDB and sent to PDB.NJEPURGE.
Feb 19, 1992 Change 7.008 discussed the MXG logic added to process the
multiple purge records that are created when a job is
offloaded before execution and then later reloaded for its
execution. The SPOOL transfer purge record was recognized
because DEVNAME begins with 'OFF', and was sent to the
PDB.NJEPURGE, since it is not the true job purge record.
However, it is possible to offload a copy of a job using
SPOOL transfer, but not delete that job from spool. (Sites
specify DISP=KEEP on the JESPARMS OFFLOAD statement to
make a backup copy of the spool before system maintenance,
but only reload if a failure occurred during testing).
The offload does not create a purge record, but the actual
job purge record now contains DEVNAME=OFF1.JT1 (I guess,
so you know the job had been previously copied to spool?).
This caused MXG to send this "real" purge record to the
PDB.NJEPURGE, and the job's other records sat in the SPIN
file waiting on the nonexistent purge record until SPINCNT
was exceeded, when the job was finally output to PDB.JOBS.
This change modifies the test for DEVNAME=:'OFF' and is
(DEVNAME=:'OFF' AND JPURTIME LT JSTRTIME) so that only
the unwanted SPOOL transfer purge record is excluded from
BUILDPDB processing, by comparing the purge record time
with the job start time.
Thanks to David Ehresman, Univerity of Louisville, USA.
Change 09.242 PR/SM variable NRPRCS is the number of partitions, butthe
VMAC7072 pseudo-partition named PHYSICAL added by APAR was also
Feb 18, 1992 being counted. Now it is subtracted out from NRPRCS.
Thanks to Tim Follen, Blue Cross Blue Shield of Ohio, USA.
Change 09.241 A DB2ACCT dataset with 250,000 obs requires 5,000 tracks.
ANALDB2R A DB2 Accounting Summary report needed 10,000 tracks of
Feb 17, 1992 work space (twice the 5,000 tracks because at the end of
the sort phase both the input and output datasets exist),
because ANALDB2R unwisely kept all 221 DB2ACCT variables!
Now, only the 43 variables needed for the Summary report
are kept, and only 1800 tracks are now required! A change
in 9.7 that required yet another copy of DB2ACCT in the
work file was also eliminated in this re-design.
Thanks to Neil Ervin, Huntington Bank Service Company, USA.
Change 09.240 The IRG (inter-record gap) calculation used to estimate
feet of tape should have been IF IRG LT 38000 THEN ....
VMACTMS5 instead of NE (VMACTMS) or LE (VMACTMS5). The 3480 tape
Feb 17, 1992 length was correct, but 3490s calculated too long!
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 09.239 Under MVS/370, SAS 6.06 can execute BUILDPDB, but it has
BUILDPDB required these changes.
Feb 17, 1992 1. CICS processing must be moved from BUILDPDB to a second
step. In member BUILDPDB, you will have to comment out
the _VAR110 and _CDE110 lines, the lines which PROC SORT
datasets starting with CIC....., and %INCLUDEs for members
starting with CIC.....
2. Set MEMSIZE=6M, a Region size of 6M, and insert an
OPTIONS BLKSIZE=2048; preceding the %INCLUDE of BUILDPDB.
3. If you need to process the type 110 CICS SMF records,
you should use IMACEXIT to select ID=110 and write them
to SMFTEMP the BUILDPDB step, then use a second step to
execute %INCLUDE SOURCLIB(TYPE110), with the SMF DDname in
this second step pointing to the temporary dataset name
you used on the SMFTEMP DDname in the BUILDPDB step.
4. Again, all of this flailing around is necessary ONLY if
you are trying to execute SAS 6.06/6.07 under MVS/370. If
you have MVS/XA or MVS/ESA, you need none of the above!
Thanks to Darrell Allen, Special Metals, USA.
Change 09.238 SMS fields (Data Class, Storage Class, Management Class)
VMXGHSM plus SMS-related flag, VSAM organization and last update
Feb 18, 1992 datetimestamp were added to the three MCD datasets created
from the Migration Control Data Set.
Thanks to John E. Schultz, First National Bank of Maryland, USA.
Change 09.237 Reserved Change Number.
Change 09.236 Support for BEI Systems PDQ/PAGE SMF record creates four
EXPDQAMJ datasets:
EXPDQAMO PDQAMON - Auxilliary Storage by performance group
EXPDQEMJ PDQAMONJ - Auxilliary Storage by job (ASID)
EXPDQEMO PDQEMON - Expanded Storage by performance group
IMACPDQ PDQEMONJ - Expanded Storage by job (ASID).
TYPEPDQ This vendor contribution has only been syntax checked.
VMACPDQ
Feb 14, 1992
Thanks to Bill Ek, BEI Systems, USA.
---Changes thru 9.235 were printed in MXG Newsletter TWENTY-ONE-----
Change 09.235 Support for Boole and Babbage IMF 2.7 is provided in MXG
TYPECIMS (it was easy - there was no change in the IMF log record
Feb 12, 1992 format since IMF 2.6!)
Change 09.234 RMFINTRV memory variables ending in MEMR were incorrect.
RMFINTRV Instead of the total memory (bytes) for the workload,
Feb 12, 1992 they contained the per-user bytes for the workload, and
variable TOTMEMR contained frames instead of bytes! The
MEMR variables should have been divided by DURATM and
not the RESD variables, and TOTMEMR should have been
multiplied by 4096 to convert frames to bytes.
Thanks to Shirley Rementer, Atlantic Electric, USA.
Change 09.233 NETSPY variable LRSPNET normally contains the response
VMACNSPY time of the last transaction, but a new variable exists,
Feb 12, 1992 LRSPNETV='Y', to flag that the LRSPNET value contains
the calculated average response for the interval. This
is particularly important for LU 6.2 and APPC sessions,
where only the calculated LRSPNET is available. Labels
for LRSPNET and LRSPHOST should have indicated "LAST".
Thanks to Marty Quinlan, Virginia Power, USA.
Change 09.232 Sample tape error report enhanced with a report by device
ANALESV type added, allowing comparisons of errors by different
Feb 10, 1992 types of tapes and drives in your tape pool.
Change 09.231 Revised documentation of DB2 reporting using ANALDB2R,
DOCDB2PM ANALDBTR, and READDB2 members adds new reports and DB2
Feb 10, 1992 2.3 considerations.
Change 09.230 Major enhancements were made to correct a known bug and
GRAFTRND add an additional set of graphs. If you had more than
Feb 10, 1992 18 months of data in your TRNDRMFI dataset, some of the
graphs (Avg vs Max CPU Busy and All Workload Bar charts)
could not be produced because the x axis could not be
fit on most graphics devices. The best circumvention
would have been to use PROC GPLOT and AREA fill but this
proved impractical because if AREAS=16 is specified and
only 5 workloads are present, the entire area of the
graph is filled with the pattern for workload 5. This is
clearly not what you (or we) wanted. Until this is fixed
(if ever) the workload bar charts will be limited to the
past 65 weeks. Why 65? It appears to be the least common
denominator for most graphic devices. 65 bars fit on all
of the devices we have tried. The data to be retained
is constructed based on the data in your TRNDRMFI data.
An MXGNOTE is produced detailing the range of dates in
your TRNDRMFI dataset and, if too much data is present,
MXGWARNINGs are produced outlining the error condition
and what will be done to circumvent the problem. There
will be notes on the SAS LOG that some observations were
missing or out of range. This is normal. When data is
being projected, the actual CPU is missing. The use
of PROC GLM to project using linear regression has been
extended to the workload level (only if you have the
SAS/STAT product.) These graphs are identical to the
current workload graphs except that they carry workloads
forward into the future the number of weeks specified by
WEEKSOUT parameter. As with the other workload charts,
only 65 weeks are charted. If a workload is shrinking,
at the point in time at which it reaches zero or goes
negative, it will be set to missing.
Change 09.229 Support for Memorex Telex Library Management Software
EXLMSADO Performance Monitor (LMS/PM), a significant contribution
EXLMSAIN written by Dan Kaberon of Hewitt Associates, was provided
EXLMSALD to MXG users by Memorex Telex. Not only did Dan write
EXLMSATL this code in MXG style, he also provided Chapter 40 style
EXLMSCHG MXG documentation, which you will find in ADOCLMS.
EXLMSCIN Seventeen datasets are created from the twenty subtypes
EXLMSEJE of the LMS SMF record. See ADOCLMS for more information.
EXLMSENT LMSXX LMS SUBTYPE INVENTORY
EXLMSEVE LMSINIT LMS SUBTYPE 0: LMS INITIALIZATION
EXLMSINI LMSSDOWN LMS SUBTYPE 1: LMS SHUTDOWN
EXLMSISC LMSCHG LMS SUBTYPE 2/12: SETTING CHANGE
EXLMSLIN LMSALDOM LMS SUBTYPE 4: ALLOCATE/DOMAIN STMTS
EXLMSMOU LMSEVENT LMS SUBTYPES 5,13-15: ATL EVENT
EXLMSSDO LMSATLI LMS SUBTYPES 10: ATL INIT
EXLMSUNL LMSADOWN LMS SUBTYPE 11: ATL SHUTDOWN/INACTIVE
EXLMSVER LMSISCR LMS SUBTYPE 19: ATL INTVL SCRATCH STATS
EXLMSXX LMSENTRY LMS SUBTYPE 20: CARTRIDGE ENTERED
IMACLMS LMSVER LMS SUBTYPE 22: CARTRIDGE VERIFY
TYPELMS LMSMOUNT LMS SUBTYPE 21: ATL MOUNT
VMACLMS LMSEJECT LMS SUBTYPE 23: CARTRIDGE EJECTED
Feb 10, 1992 LMSUNLD LMS SUBTYPE 24: UNLOAD
LMSCINIT LMS SUBTYPE 25: CART INITIALIZED
LMSLINT LMS SUBTYPE 30: INTERVAL
LMSAINT LMS SUBTYPE 31: ATL INTERVAL
Change 09.228 DCOLLECT's space calculation for dataset size (DCDALLSP
VMACDCOL in dataset DCOLDSET) is wrong; the total allocated space
Feb 10, 1992 in the dataset records can exceed the allocated space in
the volume record, because IBM uses the wrong track size
in computing the size of the dataset. The unformatted
track capacity is used, instead of the formatted track
size. Changes 9.180 and 9.144 discuss APAR OY36364 which
corrected the track size used in DCOLLECT volume records,
but the correction was not applied to the dataset record.
APAR OY48920 discusses DCDALLSP for 3390s, but it is not
clear if that APAR recognizes the other fields that are
wrong, nor if the fix (when a PTF exists) will apply to
both 3380s and 3390s. Check the status of that APAR.
Thanks to Terry Duchow, Minnesota Mutual Life, USA.
Change 09.227 CICS Exception variables MSWAITCN and TSWAITCN should be
VMAC110 missing, as these values existed only under CICS 1.6. The
Feb 10, 1992 label for MSREQWT now correctly indicates it is the bytes
of main storage acquired only after waiting.
Thanks to Paul Masters, Blue Cross and Blue Shield of Texas, USA.
Change 09.226 WSF timestamp ACCLOGON was incorrectly input as PD4.2; it
FORMATS needed to be input as HH PK1. MM PK1. SS PD2.1. Variable
VMACWSF AUDACT was incorrectly input as $CHAR1. when it should be
Feb 10, 1992 input PIB2. It is removed from the LENGTH statement, and
it is now formatted with MGWSFAC (a new numeric format).
Thanks to Douglas Clarke, General Accident, ENGLAND.
Change 09.225 Revised JCL for MONTHBLD requires only ONE tape drive,
JCLMNTH eliminates many tape mounts (especially if your weekly
Feb 6, 1992 PDBs are multi-volume), and significantly reduces the run
time of the monthly PDB build job. The revision copies
each of the weekly PDBs from tape to temporary DASD (and
selects only the datasets you intend to build monthly),
and then uses those temporary DASD files as input instead
of spinning input tapes back to the beginning of the tape
for each input dataset to be read. The output monthly
PDB is written to tape, on the same drive used to copy
the weekly datasets. As long as you have enough temp
DASD space for the job, this is a much better and faster
method of building your monthly PDB. The revised JCL is
in member JCLMNTH, but the existing member JCLMONTH was
left in the library as well.
Change 09.224 Support for IBM's Production Control System OPC/A Job
EXOPC03 Tracking and Audit Trail Log Records. Twelve datasets
EXOPC20 are created from the standard IBM log records:
EXOPC23 OPCA20 JT STARTED EVENT
EXOPC24a OPCA23 OPERATION EVENT
EXOPC24n OPCA24 MCP EVENT
EXOPC25 OPCA25 SUBMIT EVENT
EXOPC26 OPCA26 AUTO RECOVERY
EXOPC27 OPCA27 MISSED FEEDBACK RECORD
EXOPC28 OPCA28 FEEDBACK RECORD
EXOPC29 OPCA29 AUTO-TRACKED EVENT
EXOPC30 OPCA30 SPECIAL RESOURCE EVENT
EXOPC31 OPCA31 ETT TAB FILE MAINTENANCE EVENT
EXOPC32 OPCA32 AUDIT TRAIL LOG RECORD
EXOPC33 OPCA33 MESSAGE LOG RECORD
EXOPC34 In addition, four user datasets for user log records are
EXOPC35 defined, OPCA00-OPCA03, for sites which write additional
EXOPC36
VMACOPC data records to the log.
TYPEOPC
Feb 5, 1992
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 09.223 Support for Infomation Builder's FOCUS Multi-Session
EXFOCMSO Option accounting SMF record. One dataset is created:
IMACFOCU FOCUSMSO FOCUS MSO Accounting
TYPEFOCU This record provides CPU and EXCP resources and duration
VMACFOCU of session for accounting, in Release 6.5 Level 6 at PUT
Feb 5, 1992 9109. Technical Memo 7857.1 describes the contents.
Thanks to Mike Boyce, Anderson Consulting, USA.
Change 09.222 A vendor's type 39 record was truncated after 46 bytes,
VMAC39 causing INPUT STATEMENT EXCEEDED RECORD LENGTH error. MXG
Feb 5, 1992 now checks for complete header before INPUTing record,
and prints message and dumps record on SAS log instead of
failing with a STOPOVER abend.
Thanks to Connie Wilson, AMR Travel, USA.
Change 09.221 An archaic and confusing comment at the end of this
IMACFILE member was removed.
Feb 5, 1992
Thanks to Connie Wilson, AMR Travel, USA.
Change 09.220 DCOLLECT Migration and Backup datasets have new variables
VMACDCOL UMFLAG1/UBFLAG1 and UMDSORG/UBDSORG. Variables added by
Feb 4, 1992 APAR OY37378 to the Migration dataset were also added to
the Backup record, but were overlooked by MXG until this
change. (Since on one noticed their absence, they must
not be very important, but they are now decoded!)
Thanks to Joe Faska, Depository Trust, USA.
Change 09.219 Minor typo (which caused no execution error). At line 164
VMACSPMS change the three @113's to @113, @115, and @116.
Feb 4, 1992
Thanks to John Chapman, British Gas, ENGLAND.
=======Changes thru 9.218 were included in MXG PreRelease 9.8 ==========
Change 09.218 Preliminary sample code for processing Amdahl's APAF data
IMACAPAF from MVS or VM data was provided by Amdahl. This code is
TYPEAPAF not in the style of MXG, and may be revised to conform to
Feb 2, 1992 MXG architecture, but it arrived in time to save you the
effort of writing it yourself when you install APAF.
Change 09.217 IMS Multi-Trans with only 03/35/31 sequence didn't always
TYPEIMS have accurate SERVICTM and RESPNSTM, whenever the same
Feb 2, 1992 MSGDRRN was reused at a later time for the same ODEST.
First, the INPUT and OUTPUT datasets contained blank
values for DTOKEN (because, from IBM, not all log
records contain a token), and second, the 31I record was
not used to create pseudo 31O and 35O records containing
DTOKEN to correct the INPUT/OUTPUT datasets. Now, 31I
records create both 31O and 35O records so DTOKEN exists,
and just to be sure, INPUT/OUTPUT observations without a
DTOKEN are now deleted before the final merge. Like all
scotch tape and chewing gum fixes to IMS log processing,
I hope this is the last one, and pray that IBM will soon
replace IMS with DB2, since IBM refuses to enhance the
IMS log with discrete transaction resource data.
Thanks to Lynn Delacourt, Volvo Heavy Truck Corporation, USA.
Change 09.216 IMS 3.1 records contain duplicate values of DLRTOKEN, the
TYPEIMS key that is used to match log records together. The new
Feb 2, 1992 "Quick Reschedule" event creates multiple type 07/08 log
records to be created with the same value of DTOKEN, one
pair for each Reschedule. Because MXG expected only one
pair for each DTOKEN value, MXG's IMSTRAN dataset will be
incorrect (generally overreporting IMSCPUTM, DL/I calls,
etc.) without this change. Now, MXG OUTPUTs the first 08
record (the initial program schedule event), totals the
resources in the subsequent multiple 07 records, and then
OUTPUTs the final 07 record of the set with same DTOKEN.
A "Quick Reschedule" occurs when a message region has run
its maximum number of transactions per program schedule,
finds there are more transactions to execute, AND finds
there is no other program waiting on this message region.
Each 08/07 pair contains the resources consumed by all of
the transactions executed by that schedule, and it has
never been possible to measure the resources used by an
individual "multi-sked" transaction; the best we could
ever do was to divide the total resources by the number
of transactions executed during each program schedule.
Now, that "average" resource per transaction is even more
meaningless, since these multiple schedule records now
have to be summed and divided by a larger total number of
transactions. It would have made much more sense, and we
would not have lost ground in resource measurement, if
IBM had been wise enough to create a new DTOKEN value for
each Quick Reschedule.
Added 1999: Variable SCHEDULE in dataset IMSTRAN flags if
the obs was the scheduled or the rescheduled event.
Thanks to J. Cary Jones, Philip Morris, USA.
Change 09.215 BUILDPD3 (JES3 only) enhancement added in MXG 9.5 had two
BUIL3518 occurrences of 26J2 which should have been 26J3 in both
BUIL3606 of these JES3 members.
Jan 31, 1992
Thanks to Paul Oliver, BHP Information Technology, AUSTRALIA
Thanks to Steve Cavill, SAS Institute, AUSTRALIA
Change 09.214 Support for NPM Release 1.5 added seven new datasets:
EX028CM6 NPMCMEXE - Execute commands
EX028LA1 NPMLANAT - LAN Bridge Attach/Detach
EX028LA2 NPMLANCO - LAN Manager Connect/Disconnect
EX028LA3 NPMLANEX - LAN Bridge Monitor Exception/Resolution
EX028LA4 NPMLANIN - LAN Bridge Interval Resources
EX028LA5 NPMLANST - LAN Start/Stop/Alter Collection
EX028NCP NPMNCPCH - NCP Add/Replace/Delete
FORMATS and some new fields and bit values were added to existing
VMAC28 datasets. IBM publication, "Netview Performance Monitor
Jan 31, 1992 Reports and Record Formats Release 5", SC31-6147-0 is the
new documentation for all of the data records created by
this new release. Thanks again to IBM's excellent vendor
support, documentation was made available in sufficient
time to include support for this significant release in
MXG's production version. Unfortunately, no data records
from the new release were provided for testing, so caveat
user!
Change 09.213 Minor cosmetic change to recognize upper or lower case
READDB2 value for "ALL", and to relocate the %INCLUDE until after
Jan 29, 1992 requests have been parsed for efficiency.
==Changes thru 9.212 were included in MXG PreRelease 9.7==============
Change 09.212 Additional pairing logic for SQL trace report IFCID pairs
ANALDBTR were added for DB2 2.3 IFCIDs 170-171,173-176,178-179,and
VMAC102 183, and these IFCIDs are now decoded in VMAC102.
Jan 27, 1992
Change 09.211 Sites that execute BUILDPDB only six days per week will
MONTHBLD need to locally modify MONTHBLD, as it expects seven day
Jan 27, 1992 per week possible execution. One line in MONTHBLD,
(line 003400, DAY=UPCASE(PUT(TODAY,WEEKDATE3.)); ) was
moved to immediately after line 002100, as this creates
the variable DAY containing the name of the day of week.
With that permanent MXG change in place, the changes you
need to tailor in you own sites copy of MONTHBLD are more
compact and logically clearer. There are two changes to
be made by you:
a. Change IF DAY(TODAY) NE 1 THEN DO; to read
IF DAY(TODAY) NE 1 AND
(DAY(TODAY) NE 2 AND DAY NE 'MON') THEN DO;
This permits MONTHBLD to execute either on the first
day of the month, or on the second day of the month
if the first day fell on Sunday (the day you do not
execute BUILDPDB).
b. Insert after LASTDAY=TODAY-1; the statement
IF DAY(TODAY) EQ 2 THEN LASTDAY=LASTDAY-1;
This causes LASTDAY to contain the date of the last
day of the last month, which is then used to set the
_BEGIN macro value for date selection. Note that as
the _END macro value is TODAY, the selection values
will now be correct whether you execute on the first
of the month or on Monday the second day.
Thanks to Phyllis Reedyk, Witco Corporation, USA.
Change 09.210 Continued enhancement of DB2 reporting added SQL trace
ANALDB2R reports, and many additional internal enhancements:
Jan 26, 1992 1.All WARNING or NOTE messages printed on the log by MXG
now print as MXGWARN or MXGNOTE to clarify their source.
2.Internal macros are now documented with update date.
3.All uses of VMXGSUM use the INVOKEBY parameter to message
which report is being generated ("PMACC01 - ANALDB2R").
4.Selection was consolidated into DB2RSELA macro.
5.DB2DBID macro uses T102S105 and T102S107 (IFCID 105,107)
to build a temporary format which maps hex DATABASE and
PAGESET values to their actual names. Under SAS 5.18,
the INSTREAM DD pointing to temporary sequential space
is required, but under SAS 6.06+, the CNTLIN option of
PROC FORMATS is used to create formats directly from SAS
datasets.
6.Reports now check for the existence of required datasets
(as opposed to just zero observations) and messages now
indicate why reports were not produced.
7.PDB=SMF option (produce DB2 reports directly from SMF)
cannot be used under SAS 5.18 (compiler limit) in a 7MB
region. Messages now tell you how to use READDB2 plus
ANALDB2R instead of PDB=SMF to produce almost all reports
directly from SMF if you are still using SAS 5.18.
Change 09.209 DB2 Trending was not adequately tested. In the second
TRNDDB2A and subsequent week's processing, old data was not even
TRNDDB2S carried forward, and timestamps were not set correctly.
Jan 26, 1992
Thanks to Dave Leeker, Southwestern Bell, USA.
Change 09.208 New ESA 4.2 variables R79AIMPL and R79AOMPL have been now
VMAC79 added to the TYPE79A (subtype 10) dataset for the target
Jan 24, 1992 IN and OUT MPLs respectively.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.207 Variable RDRTM in TYPE30 was always missing after Change
VMAC30 9.102 because the test in line 075198 should also have
Jan 24, 1992 tested for SUBTYPE NE 1 to detect the MULTIDD condition.
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 09.206 Variable EXCMNTYP in dataset CICSEXCE (CICS Exceptions)
FORMATS did not describe the exception type because it was kept
VMAC110 in one byte instead of two. In the LENGTH statement, it
Jan 24, 1992 must be $2. instead of $1. Additionally, the $MG110EX
format in member FORMATS should have been '01X:' instead
of the obvious typographical error '02X:'
Thanks to Bill Hess, Belk Stores, USA.
Change 09.205 This code referenced formats $TABSYS and $FORHEX that are
ANALRACF not in the member. $TABSYS has been replaced by $4., and
Jan 14, 1992 $FORHEX (which converted hex strings to numerics) was
replaced an equivalent algorithm.
Thanks to ???, Alm. Brand, DENMARK.
Change 09.204 Dataset RMF72D NOT SORTED message can result if IMACRMFI
RMFINTRV has been used to re-define the startime of your RMF data,
Jan 14, 1992 since STARTIME is both being changed and in the BY list.
Insert:
PROC SORT DATA=RMF72D %VMXGFOR;BY SYSTEM STARTIME;
immediately before the PROC MEANS NOPRINT DATA=RMF72D;
to ensure that RMF72D is always sorted.
Thanks to Bill Stoneberg, National-Oilwell, USA.
Change 09.203 CA7 corruption of TSO/MON READTIME was only partially
VMACTSOM corrected in MXG 8.8 by Change 8.209. That change should
Jan 14, 1992 have also been applied to the second correction of the
CA7 corruption, lines 076500 and 076800.
Thanks to Paul Hill, Midland Bank, ENGLAND.
Change 09.202 Preliminary support for JES3 Monitoring Facility (JMF)
FORMATS type 84 SMF record. There are nine subtypes, and only
TYPE84 subtype 5 has been addressed thus far, and not even all
VMAC84 of the sub-subtypes are yet coded. This change will
Jan 13, 1992 extend over time.
Thanks to Jonathan E. Paley, Massachussets Mutual, USA.
Change 09.201 A cosmetic change. Variable RECNR should have been
VMAC6156 RECNR156 in line 013400.
Jan 13, 1992
Thanks to James F. Cook, CocaCola Company, USA.
Change 09.200 Support for Emc2/TAO (Fischers Totally Automated Office)
FORMATS Release 3.3.0 SMF record. The new release switched the
VMACTAO database reads and writes, but was otherwise implemented
Jan 12, 1992 compatibly. This support also added format MGTAOTC and
decoded three bitstrings into new variables.
Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA.
Change 09.199 This member creates reports for use at IBM's SNAP/SHOT.
ANALSNAP The SNAP/SHOT report is created from MXG's TYPE30_5 data.
Jan 11, 1992 A DASD farm report was created from DMS DSINDEX report.
A report from CA-11 (JEHF Version 2) was developed.
Mantissa run tracking file formats for RMS/BASIC are
provided, and the TMC file was used for tapes (MXG's
TYPETMS separately processes that data). These reports
could save you lots of time if you plan to model your
workload with SNAP/SHOT (and look at TYPETPNS which will
analyze the TPNS log produced by SNAP/SHOT!)
Thanks to John Leath, Fleet Real Estate Funding, USA.
Change 09.198 IMS Fastpath transactions are now supported, thanks for
TYPEIMS the diligent research of the three authors of this very
VMACIMS significant contribution. VMACIMS now creates temporary
VMACIMS datasets IMS5901,03,36,37, and 38 from those subtypes of
Jan 11, 1992 the 59x log record, and TYPEIMS has additional logic at
the end to sort and combine these to create the IMSFASTP
fastpath dataset (and IMS5838 with syncpoint failures.
Not only has this code been in production (IMS 2.2 & 3.2)
for over a year, its output has been validated with IBM's
DBFULTA0, and these author's comments in member TYPEIMS
are an excellent mini-tutorial on IMS Fastpath.
(Usually ANY activity in IMS makes my stomach hurt, as
there just isn't any documentation or help from IBM.
This contribution was done so well that my stomach
feels like it just received a piece of cake! Thanks!)
Thanks to Lars-Olof Thellenberg, Forsta Sparbanken, SWEDEN
Thanks to Goran Zebuhr, Forsta Sparbanken, SWEDEN
Thanks to Sven Agrell, Forsta Sparbanken, SWEDEN
Change 09.197 A sample report using TYPE30_4, TYPE30_5, and TYPE30_D
ANAL30DD datasets to report on all your active ddnames by job.
Jan 10, 1992 The comments in the member describe how to use ANAL30DD.
Thanks to Phil Mason, ANZ Bank, AUSTRALIA
Change 09.196 Support for LLA exits CSVLLIX1 and CSVLLIX2 are added in
ANALLLA this significant user contribution. Member ASMLLA is the
ASMLLA ASM source for the two exits that will capture LLA module
IMACLLA accesses and create a user SMF record. Members IMACLLA,
EXLLAEX1 EXLLAEX1,TYPELLA, and VMACLLA are the MXG members to read
TYPELLA those SMF records and create dataset LLAEXIT. The final
VMACLLA member, ANALLLA, provides some sample reports on LLA. Be
Jan 10, 1992 very careful as these exits can create many SMF records!
Thanks to Ken Williams, ANZ Bank, AUSTRALIA
Thanks to Peter Beer, Amdahl AUSTRALIA
Change 09.195 SAS can write zero-length VB or VBS records to a FILE
IMACFILE statement, and files containing zero-length records may
VMACSMF cause other programs (specifically, DFSORT) to fail. The
Jan 10, 1992 problem was precipitated by MXG's change in VMACSMF to
Feb 9, 1992 PUT a new message to the SAS LOG telling you how many
megabytes of SMF data had been read. In that message
there is // (two skip to the next line on the log).
The site had used IMACFILE to write selected SMF records
to an external file using FILE SMFOUT; PUT _INFILE_;
The SAS log showed "minimum record length 0" to SMFOUT!
The FILE SMFOUT had changed the destination for all PUTs
from the LOG to SMFOUT, causing the MXG message and its
// to be written as a length zero record to SMFOUT!
The real error was in not recognizing that any FILE
statement changed the destination for all subsequent PUT
statements, and the moral therefore is to ALWAYS follow
any FILE/PUT statement that you add to MXG with a FILE
LOG statement to reset the destination for PUTs. The real
error was MXG's failure to reset the log in VMACSMF; that
has been done. Change 9.087 originally discussed the need
for the FILE LOG; statement, and the new "megabytes" note
was added by Change 9.094.
Thanks to Keith Stout, City of Anchorage, USA.
Change 09.194 Support for NOMAD Session Manager SMF record is added by
EXNSMCON this significant user contribution. Three datasets are
EXNSMPRC created: NSMCON, NSMPRC, and NSMTRM, and you specify the
EXNSMTRM SMF record ID in MXG member IMACNSM.
IMACNSM
TYPENSM
VMACNSM
Jan 9, 1992
Thanks to David B. Adams, National Life of Vermont, USA.
Change 09.193 Three occurrences of $CHARZB43. should be $CHARZB44. so
VMXGHSM all 44 bytes of the dataset name are captured in the
Jan 9, 1992 MCDDSN variable.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 09.192 User of Amdahl Cache Controllers will thank Dick Sziede
ADOCSPMS for his excellent paper "A Look at Cache Performance Data
Jan 9, 1992 for the Amdahl 6100" which is contained in this ADOC.
The member is not complete, but his discussion of what's
good and what's bad is must reading for SPMS users.
Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.
Change 09.191 Members ADOCDB2 and ADOC102 completely describe each of
ADOCDB2 the variables created by VMACDB2 and VMAC102 in DB2ACCT,
ADOC102 DB2STAT0, DB2STAT1, and all 200 of the T102.... datasets.
ANALDBTR The variable-level documentation is complete, but there
FORMATS is still substantial writing to finish before theses two
VMACDB2 ADOCs are completed. It is the process of documentation,
VMACDB2H however, that uncovers inconsistency in formats, names,
VMAC102 labels, etc., and that has been completed. Additionally,
Jan 12, 1992 some datasets that formerly created multiple observations
per SMF record were revised to create a single obs with
multiple variables, so that the SQL trace logic to match
begin and end would be more straightforward. These notes
identify the highlights of this significant enhancement:
1.Variable QWHSIID was added to DB2ACCT/STAT0/1 datasets to
eventually replace incorrectly spelled QWHSSIID. MXG will
now use QWHSIID for IFCID variable in 100,101 and 102.
Both variables continue to exist in DB2ACCT/DB2STATn for
backwards compatibility.
2.Format MGDB2ID replaced with MGDB2II.
3.DB2 database "Object IDs" (PSID,OBID,DBID,ISOBID) are all
now consistently $CHAR2 with format $HEX4, and the labels
are now consistent and accurate. Seven variables had to
be changed from numeric to character: QW0023PD,24PD,25PD,
44KD,44KP,143PS, and 144PS.
4.SQL statement type exists in two different formats. A one
byte character value is found in IFCIDS 59-62 and 64-66
that is decoded by an expanded MGD062S format. A four
hex digit numeric value is found in 124, 145, and 145
IFCIDs that is decoded by an expanded MG145S format.
5.Variable QW0032AR should not have existed; QW0032FT is
the name of the field (QW0032AR is an EQU value!).
6.Variable QW0145TS was changed from numeric to $CHAR8 and
formatted $HEX16 so all 'PRECOMPILER*TIME*STAMP' fields
(in IFCIDs 53,58,59,60,61,64,65,66)are now character.
If I can find out how to decode this timestamp (a hex
value of '148CDFEF19AC29AC'X, for example), all these
variables will be decoded into numeric datetime values!
7.Variable QW0063HL was not kept but should have been, and
is formatted by new $MGD063H.
8.Variable QW0063OT is now formatted $HEX2. The MGD060O
format formerly used did not correctly decode the multi
valued bit fields, and is no longer used.
9.MXG 9.5 created observations for new IFCIDs 126-139 and
170-194 even without any 102 records because the OUTPUT
statement for these IFCIDs was missing in VMAC102.
10.Datasets T102S018,T102S053,and T102S058 formerly had one
or two observations per SMF record, one for index and one
for data. This change eliminates the second record by
putting the data portion counts in QW00.... variables,
and by putting the index portion counts in QW0I.... names
so that pairing these three records with their partners
in ANALDBTR can be more easily/accurately accomplished.
Variable SDSNUM, a sequence counter, is thus no longer
required in these datasets and has been dropped.
11.ANALDBTR was revised to pair 044/045 data, to create
additional datasets (S018S018 and S058S058) for unpaired
ends, and to keep only the first segment of 063 data,
all in support of SQL trace reporting.
12.VMAC102 was revised to create single observations for
IFCIDs 13,15,and 17. Previously, one observation for each
predicate was created. Now, the up-to-ten predicates are
stored is sets of variables. The first set is prefixed
QW0013, the second set QW0A13, the third QW0B13, etc.
13.VMAC102 was revised to create single observations for
IFCIDs 58-62 and 64-66; previously they could have one
or two observations describing DATA and/or INDEX activity
due to SQL statements, but now the QW00nn variables have
the data activity, while new variables QW0Inn contain the
index activity. This made matching begin and end of SQL
events much simpler in ANALDBTR.
14.The only IFCIDs that create multiple observations now are
22 (one miniplan per table per subselect block), 63 (one
per each 200 bytes of SQL statement text), 126 (one per
each index used to obtain candidate RIDs, up to 16), 145
(one per Audit Log Table), 148 (only for distributed
allied agents, R8O one per conversation, R9O, one per
location), and 191 (one per parse, up to 5).
14.VMAC102 and VMACDB2 labels and formats were revised to
be consistently spelled, etc.
15.ANALDBTR, the routine which matches pairs of trace data,
is now a %MACRO which invokes the old-style _nnnPAIR
macros. This change added flexibility to its use and its
invocation inside %ANALDB2R reporting.
16.VMACDB2H now creates variable QWHDYES, indicating that
there was a distributed header, and which is now used in
VMACDB2 to create new variable THREADTY (formatted with
$MGDB2TT) to describe the type of thread (Allied, Allied-
Distributed, DBAT (Database Access) or DBAT-Distributed).
Thanks to Debby Meister, Loews Corporation, USA.
Change 09.190 -CICS 3.2.1 statistics records were not fully supported.
VMAC110 STID=63 (CICTM) record contains sixteen tables, but only
Dec 27, 1991 the first twelve were kept by MXG prior to this change.
Seven records (that contained only totals) are no longer
created by IBM (because they are redundant with their
corresponding detail record) and thus these MXG datasets
always contain zero observations: CICTST(STID=5),CICTCT
(35),CICLSRT(38),CICLSRFT(41),CICCONST(53),CICTCLT(59),
CICFCT(68),CICCONMT(77). (Their detail dataset names
are minus the ending "T".)
-IBM added two undocumented bytes in the STID=57 (CICSDS)
record, which corrupted the CPU times in CICSDS dataset,
and in the CICINTRV, etc., datasets created from it. The
two bytes added for alignment (immediately before the
repeating DSECT) are not documented in DFHGSGDS. And in
an unrelated change, CICS APAR PN02625 removes two filler
bytes following DSGNTCB, but did not update the STIVERS
version indicator, so there is no direct way to know what
length record to expect! As a result, MXG protects for
none, two, or four filler/alignment bytes in this record.
-IBM documentation for statistic record STID=49 is wrong.
DSECT DFHA13DS describes STID=49 as containing 39 bytes,
but actual data records have STILEN=40; a one-byte field
(reserved) following A0013BFC is not described in that
DSECT (the only IBM documentation of the record!). IBM
will correct their error (eventually) with a doc APAR.
How can the record disagree with the DSECT you might ask?
Because IBM records are built by PL/S DSECTS, but IBM
documents with ASM DSECTS that are never actually used!
-Two occurrences of broken CICS 3.2.1 records were found
with only 80 bytes of data. MXG new detects the short
record, messages to the log, and avoids STOPOVER ABEND.
Thanks to Lee F. Johnson, Talbots Systems Center, USA.
Thanks to Bruce W. Galle, Talbots Systems Center, USA.
Change 09.189 Processing VVDSs previously failed with a USER ABEND 666
ASMVVDS when ASMVVDS tried to read a VM system volume that was
Dec 20, 1991 online to MVS (because the volume does not have a normal
VTOC/VVDS). Now, instead of the ABEND, the program puts
out a message that the OBTAIN macro failed for that UCB
(DEVNR), and then continues to process additional UCBs.
Thanks to Chris Taylor, First Wachovia Bank, USA.
Change 09.188 VVDS support skipped over VVRTYPE='D5'X because the test
VMACVVDS in line 017100 was mistyped as ='D5' instead of ='D5'X.
Dec 20, 1991
Thanks to Chris Taylor, First Wachovia Bank, USA.
Change 09.187 Support for ASTEC Version 1.5. Several new fields were
VMACDMON added (incompatibly) to the SMf record. This support was
Dec 16, 1991 actually shipped in MXG 9.5, but this change was not in
member CHANGES of that library.
Thanks to Joe Faska, Depository Trust, USA
Change 09.186 VPD type E records caused STOPOVER ABEND because variable
VMACVPD VPDRSVR2 should have been input as $CHAR11. instead of
Dec 16, 1991 $CHAR12. (line 014200).
Thanks to Jim Nicholas, Mead Data Central, USA.
Changes thru 9.185 were contained in MXG PreRelease 9.5, Dec 1, 1991
Change 09.185 Change 9.164 was a major restructuring of ANALDB2R, and
ANALDB2R had not been sufficiently tested for all DB2 reports.
ANALDBTR Using SAS 6.07 (and reading all of the SAS messages on
Dec 1, 1991 the log!) not only corrected UNINITIALIZED variables, but
the 6.07 feature which warns of unreferenced variables in
the KEEP= list caught a number of mispellings in some of
the type 102 trace reports. SAS 6.07 furthermore found
a syntax error that SAS 5.18 had accepted! This was an
another superb contribution from Koln.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.184 Several important variables have now been added to the
EXRMFINT TYPE70 and RMFINTRV datasets for MVS/ESA and PR/SM data.
EXTY72 1.If PR/SM data section is found in type 70 (PR/SM, MLPF,
RMFINTRV or MDF) records, both the Partition Dispatch (PDTM) and
VMAC7072 Effective Dispatch (EDTM) are carried into the TYPE70
Nov 28, 1991 dataset. MXG continues to calculate PCTCPUBY based on
Sep 21, 1994 Partition Dispatch Time for consistency, but now provides
PCTCPUEF, based on Effective Time, which matches the RMF
reported "CPU Busy" under PR/SM. The individual LCPUs
times are in new variables CPUPDTM0-8, CPUEDTM0-8, and
totals across all LCPUs are in CPUACTTM and CPUEFFTM.
2.RMFINTRV was enhanced to provide the three new CPU times
(HPT,IIP,RCT) in each set of workload variables and their
total for each workload. New variable BATCPU is the sum
of existing BATTCB,BATSRB plus BATHPT,BATIIP, and BATRCT.
Total CPU times are also kept in CPUTM, CPUHPTTM,CPUIIPTM
and CPURCTTM variables.
Next paragraph revised in 1994:
ACTFRMTM replaced MSOUNITS as a metric in 1994:
Additionally, in each workload, the memory is now
calculated (Central+Estore) from ACTFRMTM in bytes in
BATMEMR, CICSMEMR, etc. (but recall that ACTFRMTM does
not include logically swapped pages nor the nucleus, LPA,
nor CSA). This is a much better indicator of memory
utilization than AVGMEMSZ, which is based on MSOUNITS as
discussed in prior newsletters. And the total memory of
all workload's memory is variable TOTMEMR.
3.See the MVS Technical Note on CPURCTTM in Newsletter 21.
It is unmodified in the TYPE72 dataset, so you can see
how wrong it is, but it is now subtracted from CPUTM in
EXTY72 (temporarily, until a PTF exists). This will
prevent negative overhead calculations in RMFINTRV due
to the wrong value of CPURCTTM until fixed by IBM.
Change 09.183 DB2 variable QWHSSTCK is now formatted DATETIME22.3 so as
VMACDB2 to show the milliseconds. Sites using DB2 trace found
VMAC102 the increase in printed resolution useful for tracking
Nov 28, 1991 detail event sequences.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.182 Heavy validation of TYPEIMS from MXG 9.2 uncovered still
VMACIMS additional idiosyncrasies and undocumented Enqueue record
TYPEIMS flags in this significant contribution. In VMACIMS,
Nov 28, 1991 35x records with ENQFLAG=04C or 08C and FLAG2=08 are now
added to IMS35P. This site uses Terminal-Databases with
SPA-information and a Code-Information in the INPUT msg
to jump from one transaction to another, which are now
supported by additional logic, even when outputs do not
match inputs. Compare criteria using LOGONID and ODEST
do not work if there is no external LOGON-processing,
(DEQTIME was always equal to OGUTIME), but by using
CLINENR instead, and revising the MERGE logic, this
case appears to be now protected as well. However, as
past history indicates with IMS, what works at several
sites may not always work at all sites, so please verify
your output if you must process IMS log data.
Additional cosmetic changes were a new message that tells
you how many megabytes of IMS log data MXG read in, and
if invalid 035x records are found, a hex dump of the
record is printed on the log for Merrill debugging!
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.181 -IBM APAR PL83370 adds new field STATCTM1 to CICS/ESA type
IMACICDB 110 DBCTL segment. However, since the APAR does not say
VMAC110 where the field was added, I had to assume it's at the
Nov 27, 1991 end of the known fields (in the 96 skipped bytes).
This new field captures the IMS CPU time in DRA thread
TCBs (but not time spent in the control region, as DBCTL
cannot capture that CPU time). Originally, IMS 3.1.0 did
not provide CPU time for threads because the original
design provided for an alternate method called "commit-
continue"; late in the release, a decision was made not
to support the commit-continue, and nothing was provided
in its place. Now, STATCTM1 has been provided to capture
the CPU time spent in the DRA thread TCB from the begin
of schedule request to the release of the PSB (any SYNC
POINT that also says 'TERMINATE TCB'), using existing
STIMER and TTIMER cancel code in DRA.
STATCTM1='ELAPSED UOR*CPUTIME FOR*THREAD TCB'
-This APAR also corrects the value in STATDBIO: IBM code
existed to catch the SLOG22/SLOG23 pair (OSAM buffer
handler) and count it as one Database I/O, but there was
no code to catch the SLOG24/SLOG25 pair (VSAM buffer
handler). The DBIO field is also copied into the IMS 07
log record, so now that field will also be valid.
-The APAR text also states that the new CPU time, STATCTM1
is added to the IMS log Type 07 record as field DLRTIME,
but I need DSECTS to find out where, before I can update
TYPEIMS (and there'll be a change for TYPECIMS too!).
Thanks to Philip Schwartz, United Parcel Service, USA.
Change 09.180 A volume with 1,260,487,800 bytes capacity (tracks times
VMACDCOL formatted track capacity) was reported by DCOLLECT as
Nov 26, 1991 having a capacity of only 1,260,487,680, a loss of 120
Feb 10, 1992 bytes. The error was thought to be truncation because
the variable was stored in 4 bytes, and in Nov, these
variables were changed to be stored in 8 bytes:
DCDALLSP DCDSCALL DCDUSESP DCVALLOC DCVFRESP DCVLGEXT
DCVVLCAP UBDSIZE UMALLSP UMDSIZE UMRECSP UMUSESP
Now, the truth is known, and there was no MXG error. The
DCOLLECT data field is in kilobytes and not bytes, and
thus the values reported by DCOLLECT will be the nearest
multiple of 1024 bytes that is smaller than the true
value. The extra 120 bytes exist on the volume, but will
never be reported by DCOLLECT!
Thanks to Terry Duchow, Minnesota Mutual Life, USA.
Change 09.179 PR/SM TYPE70PR summary PDB.ASUM70PR and trending TRND70PR
ASUM70PR datasets were correct if NRPRCS (number of partitions
TRND70PR running or defined) was equal to PARTNCPU (number of
Nov 25, 1991 physical processors), but PCTLnBY calculations were wrong
otherwise, and produced logical busy percentages instead
of percent of physical busy that was intended. Now, the
calculations use PARTNCPU so the PCTLnBY measures real
hardware CPU utilization of your PR/SM or MLPF box.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.178 DB2 2.3 SMF type 102 records were changed incompatibly on
VMAC102 Nov 12. (DB2 2.3 just became available Oct 28!). Fields
Nov 25, 1991 were added to IFCIDs 28, 96, 140-142, and 145 (and are
now supported by MXG). IBM provided documentation that
was good and timely for this change.
Change 09.177 MXG PreRelease 9.4 produced zero observations in DB2data
VMACDB2H sets, with no error message. A last-minute "cosmetic"
Nov 25, 1991 change to label the new 2.3 variables corrupted the code.
(The last 32 lines, starting at line number 01860000 must
be moved to after line 005500).
Thanks to Ted Garner, First Union, USA.
Change 09.176 IMS Abend condition codes were always blank, and because
TYPEIMS Change 9.106 was incorrectly located in MXG 9.3, the
Nov 28, 1991 resources for multi-trans were incorrect.
Thanks to Pete Shepard, Ashland Oil, USA.
--Changes thru Change 9.175 were in MXG PreRelease 9.4 dtd Nov 15, 1991
Change 09.175 BUILDPDB has been significantly enhanced. DB2ACCT/STAT
BUILD518 datasets are now added to your PDB from type 100/101 SMF
BUILD606 records. SAS 5.18 users should be able to add many more
BUIL3518 SMF records to their PDB before a SAS 344 Compiler error
BUIL3606 is encountered. However, this change is INCOMPATIBLE for
BUILDPDB SAS 5.18 sites; a new DD statement is required in the JCL
VMACDB2 for the BUILDPDB/3 step (only for SAS 5.18):
VMACSMF
Nov 15, 1991 //SMFTEMP DD UNIT=SYSDA,SPACE=(CYL,(20,20))
An additional INCOMPATIBILITY exists for all BUILDPDB/3
sites that have added DB2 processing to their PDB (this
would have been done by editing members EXPDBINC,EXPDBVAR
EXPDBCDE and EXPDBOUT members as described on pp 134ff of
the MXG Supplement). If you have added DB2 processing,
it must be removed or BUILDPDB will syntax error.
This redesign was caused because the "vanilla" BUILDPDB
in MXG 9.4 could not be compiled under SAS 5.18. The
additions for MVS/ESA, CICS/ESA, etc., added iterative DO
statements, causing a SAS 5.18 "344 Compiler Error". To
circumvent this error, now, (for SAS 5.18 only), MXG
writes RMF 71 and 73-78 records to the (new) SMFTEMP file
while reading your SMF input, and then executes a second
data step to process that small SMFTEMP file. (Type 70,72
records are not split out, because type 30 processing
needs IOCCOEFF to calculate EXCPRMF!). Splitting the
data step reduced the number of iterative DO statements,
avoiding the "344 Error" for sites which have added other
SMF record processing (using the MXG Exit Facility, pages
134-140 of the MXG Supplement). The circumvention that
was previously described in Change 7.038 (in CHANGE07) is
no longer applicable (except for the possible use of the
XMAC7072 member), since MXG has split the RMF processing
out. Since RMF data is not large volume (perhaps 9MB
per day per system at 15 minute intervals), there is very
little increase in processing time.
Unfortunately, this elimination of the 344 SAS error may
only serve to uncover yet another SAS 5.18 limitation. A
160 SAS error occurs if the total length of all variables
in a SAS data step exceeds a SAS 5.18 internal limit, and
there's NO circumvention for the 160 error. If received,
you must remove some of your additional SMF records from
the EXPDB.. members, and instead use IMACFILE member to
write your SMF records the SMFTEMP DD, which can then
be processed in a subsequent step of your job. (Or, you
can use SAS 6.06/6.07 for just the BUILDPDB step and use
a LIBNAME statement to build your PDB datasets in SAS
version 5.18 format).
Note there is no change for SAS Version 6; the compiler
limit does not exist in SAS Version 6, and BUILDPDB logic
uses %MACROs to detect you are executing under Version 6,
and MXG processes all SMF data in one pass; there is no
need for the SMFTEMP DD name under SAS 6.07/6.07.
Adding DB2 processing had been desired for some time, but
because of the 5.18 problems, it could not be easily done
until now.
Change 09.174 Divide by zero error occurred for the type 79 record for
VMAC79 the interval in which the clocks were set back this Fall!
Nov 14, 1991 The record had a duration of 0 seconds after the operator
changed the clock. Now, divides by DURATM are checked to
be non-zero before the divide. Also, RMF 3.5.1 caused a
STOPOVER on type 79 subtype 3 that is now protected.
Thanks to Fred Fettinger, Rockwell Graphic Systems, USA.
Change 09.173 Support for LEGENT's MIM (Multi-Image Manager) user SMF
EXTYMIM records was added by this user contribution. A single
IMACMIM dataset, MIMTAPE, is created from this record.
TYPEMIM
VMACMIM
Nov 14, 1991
Thanks to Doug Drain, National City Bank, USA.
Change 09.172 Support for Softtool Corporations's CCC (Change and
ANALCCC Configuration Control software is added by this user
EXTYCCC contribution. Example reports are also provided, but
IMACCCC will require an installation format for processor power.
TYPECCC
VMACCCC
Nov 14, 1991
Thanks to Sue Swayne, Inland Revenue (UK), Worthing, ENGLAND.
Change 09.171 The collection of RACF reports added by change 9.064 had
ANALRACF invalid concatenation symbols (because the code went
Nov 12, 1991 from MVS to a PC and back!). The reports were also
slightly revised and enhanced.
Thanks to Duncan McKellar, Inland Revenue (UK)
Thanks to Neil Campbell, Inland Revenue (UK)
Thanks to Dave McLaughlin, Inland Revenue (UK)
Change 09.170 FTP SMF records produced no observations because test to
VMACFTP ensure there was data was incorrect. Eleven occurrences
Nov 12, 1991 OFFDATA+(NRDATA*LENDATA) LE LENGTH THEN ...
must each be changed to
OFFDATA+(NRDATA*LENDATA) LE LENGTH+1 THEN ...
Thanks to Kueller, Spardat Wien, AUSTRIA.
Change 09.169 TYPE59 variable QUEUTIME was not formatted DATETIME21.2,
VMAC59 nor was it set to stored length of 8 bytes, but now it
Nov 12, 1991 is!
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.168 A CICS region ABEND caused Landmark to write a "trashed"
TYPEMON8 record that contained invalid values for the offset to
Nov 11, 1991 variable segments. Because MXG did not validate that
the offset value was actually in the record, MXG failed
(with "INPUT STATEMENT EXCEEDED RECORD LENGTH"). There
are three DO statements that need to be protected. Find
the following 3 DO statements in TYPEMON8, and insert
the four lines of protection preceding the existing DO
statement:
IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 THEN D0;
PUT 'BAD RECORD FOUND AND DELETED '; LIST;
DELETE;
END;
DO FILESEG=1 TO FATNUM;
IF UATCOL+UTNUM*TAUATLEN GT LENGTH+1 THEN DO;
PUT 'BAD RECORD FOUND AND DELETED '; LIST;
DELETE;
END;
DO USERSEG=1 TO UTNUM;
IF MROCOL+MRONUM*TAMROLEN GT LENGTH+1 THEN DO;
PUT 'BAD RECORD FOUND AND DELETED '; LIST;
DELETE;
END;
DO MROSEG=1 to MRONUM;
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.167 Support for Codework Software's SNAPAD-MVS product user
EXSNAPAD SMF record. SNAPAD lets mainframes talk to X.25 packet
IMACSNAP switching networks. Feb 20, 1992: This code has now
TYPESNAP been tested and verified, superceeding the note in this
VMACSNAP change printed in Newsletter TWENTY-ONE.
Nov 10, 1991
Thanks to Dennis Uy, Asian Development Bank, PHILIPPINES.
Change 09.166 MXG incorrectly calculated Full Duplex line utilization
VMAC28 PCTBUSY. For half duplex, the calculation was correct.
Nov 10, 1991 Since a Half Duplex line has only one set of buffer for
both send and receive, MXG summed the send and receive
bytes and divided by the send (primary) line speed:
PCTBUSY=800*(BYTSPRSC+BYTSSCPR)/(NCPTM*NPMPLS);.
(The 800 is used because line speed is in baud).
But for a Full Duplex line, there are 2 sets of buffers,
one for send and the other for receive. Thus there are
two separate utilizations that can be calculated. Since
the purpose of PCTBUSY is to identify utilization, and
since the line is out of speed when either its send or
its receive utilization is 100%, MXG now calculates the
PCTBUSY for full duplex as the Maximum of the send or
receive (primary or secondary) utilization:
PCTBUSY=MAX(800*BYTSPRSC/(NCPTM,NPMPLS),
800*BYTSSCPR/(NCPTM,NPMSLS));
MXG's previous calculation for Full Duplex turned out to
be the average of the send and receive utilizations, and
thus underreported the typical utilization in which one
direction predominates.
Thanks to Lee Lik Cheung, DBS Bank, SINGAPORE.
Change 09.165 Support for LEGENT's LANSPY component of NETSPY 4.1 that
EXNSPYLF captures LAN resources and responses in five new MXG
EXNSPYLG datasets. LANSPY creates record segments even when
EXNSPYLL there was no activity on the LAN, but MXG only outputs
EXNSPYLR observations if the activity counts are non-zero (the
EXNSPYLS decision logic is located in the Exit member EXNSPY..).
VMACNSPY This support has been tested with actual LANSPY data,
Nov 10, 1991 thanks for excellent vendor support from Legent.
Change 09.164 This change is primarily internal in that most user will
ANALDB2R not explicitly see these changes, but they are under the
READDB2 cover significant enhancements to DB2 processing. In
VMAC102 VMAC102, new macros of the form _LTRccnn now are defined
Nov 8, 1991 that are the list of the IFCIDs in each trace class.
These list macros are then used by the new READDB2 macro
(invoked by ANALDB2R when PDB=SMF is specified) so that
MXG only processes the IFCIDs that are needed, based on
the reports you have requested. You no longer have to
manipulate member IMAC102 to process trace records, and
this re-design should execute significantly faster.
Note that READDB2 can be invoked independently if you
wish to create datasets from subsets of DB2 data; it
is self documenting. The old keyword parameter names
for trace class selection (DB2TC1-DB2TC16, etc.) do not
exist (they were replaced by the new TRACECLS parameter),
and you will get "KEYWORD PARAMETER NOT DEFINED" errors
if your ANALDB2R invocation uses the old names.
Change 09.163 Trend Data Base updates. DB2ACCT, DB2STAT0, DB2STAT1
TRNDDB2A have been updated to add some new DB2 2.3 variables for
TRNDDB2S identification, if they exist (i.e., when you have DB2
TRND70 2.3 data. New member TRND70 trends RMF TYPE70 dataset.
Nov 8, 1991
Change 09.162 Cosmetic (but then looks do count!). TYPE22_A bit maps
VMAC22 of 3390-3 status should have been formatted $HEX2./$HEX4.
Nov 8, 1991 Now they are correctly formatted to describe status bits.
Thanks to Harry Price, Florida Power and Light, USA.
Change 09.161 CICS/ESA only, DBCTL EMP data only. In IMACICDB, the +98
IMACICDB after STATBFWT should have been +100 (but this would have
VMAC110 only caused a problem if you had additional user data
Nov 8, 1991 after the DBCTL EMP - if you did and decoded that user
data you will have been off by two bytes in your code).
However, IBM has added a new field in those former +100
bytes, so this change in IMACICDB replaces the old +98
with STATUSSN PIB4.
+96
and adds a label STATUSSN='USSN*NUMBER'. In VMAC110, the
new variable is added to the KEEP= list for CICSTRAN.
Thanks to Barry Pieper, First Bank Minneapolis, USA.
Change 09.160 MXG 9.3 only, VMXGVTOF processing of ASMVTOC output will
VMXGVTOF cause "Invalid data for STARTIME" because the variables
Nov 6, 1991 UNITADDR, UCBTYPE and STARTIME (added by Change 9.099)
were off by one byte. The input @151, @154, and @158
for those three variables must be @152, @155, and @159.
Thanks to Normand Poitras, Teleglobe Canada, CANADA.
Change 09.159 A potentially serious error in VTOC/VTOF processing (only
VMXGVTOC under SAS 5.18, not under SAS 6.06+) has been found. The
VMXGVTOF error appears to have been introduced in MXG 7.2 (October
Nov 6, 1991 1989!). If you have this error, dataset VTOCLIST will
describe only the space used by the first three extents!
You have the error if VTOCLIST variable NREXTNTS (extent
count in the DSCB1) is greater than variable NUMEXT (MXGs
count of extents). The logic error is the location of
the CALL SYMPUT; it is now known that under SAS 5.18 the
CALL and STOP must be located after the SET statement for
the below logic to have ever worked:
DATA _NULL_;
POINT=1;
CALL SYMPUT('MXGOBS',PUT(NOBS,7.0));
STOP;
SET DSNAMES POINT=POINT NOBS=NOBS;
RUN;
%IF &MXGOBS EQ 0 %THEN %LET I=11;
Because the CALL was mislocated, &MXGOBS was always zero,
causing MXG to prematurely terminate extent processing.
(Under SAS 6.06, it turns out, the logic worked!). But
the following logic is more straightforward and has now
replaced the above logic in VMXGVTOC and VMXGVTOF:
DATA _NULL_;
IF EOF THEN CALL SYMPUT('MXGOBS','0');
ELSE CALL SYMPUT('MXGOBS','1');
STOP;
SET DSNAMES END=EOF;
RUN;
%IF &MXGOBS EQ 0 %THEN %LET I=16;
Additionally, the %DO statement twenty lines before this
code was changed to 15 instead of 10 (which corresponds
to changing the %LET I= value from 11 to 16), because it
is theoretically possible to require up to fifteen passes
of the extent merge (I've not seen more than two needed).
The actual change in MXG is more extensive; in addition
to the above logic changes, NREXTNTS is now compared to
NUMEXT and an error message produced on the log if data
has been lost (and some of the work dataset names used
in the matching process were renamed to make diagnosis
of any future problems more tractable).
Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.
Thanks to Al Acosta, Brooklyn Union Gas, USA.
Change 09.158 The NETVIEW VPD record type "E", end subrecord STOPOVER.
VMACVPD Variables VPDRSRV1 and VPDDCCAL must be $CHAR8. instead
Nov 5, 1991 of $CHAR12. Offset for VPDDCCAL and VPDRSRV2 must be 86
and 94 instead of 90 and 102. Additionally, informat for
VPDRECNT, VPDPUCAL, and VPDDCCAL were changed from $CHAR8
to ?? 8. so they are changed from character to numeric.
Thanks to Jim Nicholas, Mead Data Central, USA.
Change 09.157 Two DCOLLECT variables, DCDLBKDT in DCOLDSET, and UMLBKDT
VMACDCOL in DCOLMIGS, were previously $CHAR8. (because IBM did not
Nov 5, 1991 choose to document the internal contents, and test data
used for MXG validation had only zeros in those fields.)
Both variables are now changed from character to numeric;
this change may cause a problem if you combine the DCOL..
datasets from before and after the change, but the long
term benefit of having the correct field name and format
out weight the short term impact. Furthermore, BEFORE
and AFTER datasets can be combined while deleting the
previous character variable with simple logic:
DATA DCOLDSET; SET OLD.DCOLDSET (DROP=DCDLBKDT)
NEW.DCOLDSET ;
Thanks to O. V. Hanger, A. C. Nielsen Co., USA.
Change 09.156 DB2 2.3 final validation and documentation found several
VMACDB2 changes, mostly cosmetic, were needed.
Nov 5, 1991 1.DB2ACCT/DB2STAT1 variables QTXABLLM,INLM,IOLM,SALM,SELM,
and SPLM were deleted, as they were completely redundant
with decoded values of QTXAPREC. They had been used in
tests in ANALDB2R, but those tests were replaced with the
explicit tests for values of QTXAPREC. Also, variables
QTXAILMT and QTXANRUN are now set based on bit tests (the
previous tests for '80'X and '40'X were incorrect). Also
variables QTXACHUS and QTXACLMT are now format TIME12.2.
2.DB2STAT0 variable QLSTBRBF needed asterisks in its label.
Variables QWS4ASCB and QWS4ASID are now kept, variables
QWS4EJST and QWS4SRBT are formatted TIME12.2. The twenty
address space variables (prefix QWS1,QWS2,QWS3,QWS4 and
suffix ASCB,ASID,EJST,PROC,SRBT) labels now name each of
the address spaces, and MXG now stores the data for each
address space consistently in these prefixes (in spite of
IBM's inconsistent use of the 3rd and/or 4th buckets!):
QWS1 - Master, or system services address space
QWS2 - DBM1, or data base services address space
QWS3 - IRLM, or inter-region lock manager address space
QWS4 - DDF, or distributed data facility (values will
be missing if no DDF).
Change 09.155 TYPE22_7 variables CHOWNED and CHONLINE are set in lines
VMAC22 lines 079600 and 079700, but were not reset if bit test
Oct 17, 1991 was not satisfied, causing values to be propagated. Now
ELSE CHOWNED=' '; and ELSE CHONLINE=' '; were inserted
respectively.
Thanks to Bruce Read, Attorney General's Department, AUSTRALIA.
Change 09.154 NETSPY variables STARTIME and STOPTIME are reversed in
VMACNSPY lines 089100 and 089200. STOPTIME is based on DTEE/TMEE
Oct 17, 1991 and STARTIME is based on DTES/TMES.
Thanks to Lois Robinson, M & I Data Services, Inc, USA.
Change 09.153 Type 6 "INPUT STATEMENT EXCEEDED RECORD LENGTH" results
VMAC6 from LEGENT's Bundle product record which is logically a
Oct 16, 1991 normal External Writer record, but because the record now
contains the characters "BU" instead of the normal zero
in the SUBS field, the shorter EXTW record format was not
recognized by MXG. Now, SUBS=49892 ("BU" as PIB2.) sets
SUBSYS='BUND', and the two tests for 'EXTW' are extended
to treat 'BUND' as 'EXTW', thereby adding support for
the Bundle product in MXG.
Thanks to David Kyle, Dominion Bankshares, USA.
Change 09.152 Support for new Tape Device 3490E added. In MXG datasets
VMACEXC2 TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40,
VMACUCB variable EXCP3490 is created, in the TYPE30_n datasets
VMAC30 variable IOTM3490 is created, and in datasets TYPE434
VMAC40 and TYPE30_N variable TAPE3490 is created. Change 9.002
VMAC434 created a new value for the variable DEVICE, but did not
Oct 9, 1991 create these new variables. Because the 3490E format is
Aug 19, 1995 completely different than 3480s or the earlier 3490s, it
was consistent with MXG treatment of devices to create
these three new variables in the appropriate datasets.
MXG Internals Architecture Note for the record:
Addition of new device type in MXG requires knowledge of the values
of device class DEVCLASS and device type DEVTYPE returned by the IBM
macro DEVTYPE so that the new variables EXCPnnnn, IOTMnnnn, (and for
tape devices, TAPEnnnn) can be created. The changes that are then
made in MXG (not by you - these are the changes that MXG made when
an MXG Change states "Support for new DASD/Tape Device nnnn added"):
For new DASD device:
a) VMACUCB - create new value for DEVICE within device class.
b) VMACEXC2 - create new DO group within device class.
IF DEVTYPE=0hhX THEN DO;
EXCPnnnn=SUM(EXCPnnnn,EXCPCNT);
IOTMnnnn=SUM(IOTMnnnn,IOTM);
END;
c) VMAC434 - Label EXCPnnnn
d) VMAC40 - Label EXCPnnnn
e) VMAC30 - Label EXCPnnnn, IOTMnnnn
- Add IOTMnnnn to TIME12.2 format list.
f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.
For new Tape device:
a) VMACUCB - create new value for DEVICE
b) VMACEXC2 - create new DO group:
IF DEVTYPE=0hhX THEN DO;
EXCPnnnn=SUM(EXCPnnnn,EXCPCNT);
IOTMnnnn=SUM(IOTMnnnn,IOTM);
END;
- create new counter within device class tests:
IF DEVTYPE=0hhX THEN TAPEnnnn=SUM(TAPEnnnn,1);
c) VMAC434 - Label EXCPnnnn,TAPEnnnn
- Keep TAPEnnnn
d) VMAC40 - Label EXCPnnnn
e) VMAC30 - Label EXCPnnnn,IOTMnnnn,TAPEnnnn
- Keep TAPEnnnn
- Add IOTMnnnn to TIME12.2 format list.
f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.
g) IMACPDB - Add TAPEnnnn to the _PDB30_4 and _MAXSTP macros.
- Then, in the PROC MEANS logic that follows, the
X10 in the DROP= list must be changed to X11, and
X11 must be added after the X10 in the SUM= list.
In addition, member FORMATS must be scanned for all occurrences
of the previously-newest-device-of-this-class. (Eg, when adding
support for 3590 tape drive, locate all occurrences of 3490 in
all formats). Only one or two formats use the IBM DEVCLASS and
DEVTYPE values (eg., '8083' for 3590s); those you can directly
update. The rest (currently, EREP and ZARA) have their own, non-
standard table of values, and their vendor must be contacted to
determine what value they chose.
This note was revised August 19 and again September 22, 1995.
Change 09.151 Support for new DASD Device 9345 added. In MXG datasets
VMACEXC2 TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40,
VMACUCB variable EXCP9345 is created, and variable IOTM9345 is
VMAC30 created in the TYPE30_n datasets. The new device has a
VMAC40 tracksize of 46456 (after R0 is on the track), with 15
VMAC434 tracks per cylinder, and 1440 cyl per vol on Model 1 or
Oct 9, 1991 2156 cyl per vol on Model 2.
Change 09.150 Cosmetic changes. Comments describing the expected sort
ANALCICS order were clarified, and the second occurrence of
Oct 8, 1991 TASCPUTM=0; was deleted.
Thanks to John Chapman, British Gas, ENGLAND.
Change 09.149 DB2 report PMACC01 could produce zeros in two places due
ANALDB2R to MXG typing errors. The two lines now reading
Oct 8, 1991 GSWS=QBACSWS; and L2SWS=QBACSWS; should read
GSWS+QBACSWS; and L2SWS+QBACSWS; respectively.
Though not causing an error, lines 012560-012970 (IF _N_
.... END;) were deleted, as those variables were already
initialized by the RETAIN statement.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to ???, ORDA-B, BELGIUM.
Change 09.148 Cosmetic enhancement to MXG messages when reading SMF.
VMACSMF MXG now prints additional information on the SAS log
Oct 4, 1991 when reading SMF data. The start and end times and the
system id for each dump event are now printed (from the
type 02/03 records) preceding the "SUCCESSFULLY READ"
message, and the minimum and maximum timestamp of any
SMF record are also printed. The 02/03 pairs are very
useful to detect problems in SMF dump processing (if you
don't have matched pairs for each system, you had a real
problem, and if you have duplicate data you can see the
record numbers so you can copy the SMF file, deleting
the duplicate records based on these log messages).
Thanks to John Chapman, British Gas London, ENGLAND.
Change 09.147 Support for Omegamon for CICS/ESA Version 550 user SMF
EXOMCADA record created by ESRA, INTR, SYSINIT, and OMDV. There
EXOMCBOT are three different subtypes (100,101,102) of the user
EXOMCDCT SMF record, and each subtype has sub-subtypes, and the
EXOMCDLI subtype 100 sub-subtype 4 has still additional subtypes.
EXOMCENQ This code has been compared with hex dumps of subtype 100
EXOMCFCT records, but only syntax checked in execution as no data
EXOMCFIX records have yet been received for testing.
EXOMCIDM
EXOMCJCT
EXOMCPCP
EXOMCRTA
EXOMCSYS
EXOMCTIT
EXOMCTRA
EXOMCTRL
EXOMCVIO
EXOMCVSA
EXOMCVVS
IMACOMCI
TYPEOMCI
VMACOMCI
Nov 8, 1991
Change 09.146 This change significantly enhances MXG's processing of
IMACICDA optional CICS data gathered with EMPs. Previously, MXG
IMACICDB member IMACICDL decoded IBM local DL/I counters, member
IMACICDL IMACICDB decoded IBM DBCTL counters, and member IMACICUS
IMACICDU was used to set the length of any remaining user data.
IMACICOB The MXG order of processing those segments was not under
IMACICOC user control. This change externalizes the processing
IMACICOL into new member IMACICDA, which can be used to match the
VMAC110 MXG order with the order your CICS programmer set in her
Oct 3, 1991 CICS MCT table. IMACICDA can also be used to identify
which APPLIDs have which data segments, if not all are
the same. Comments in IMACICDA describe how to use the
enhancement, but this change did NOT change the previous
MXG order (DL/I, UserChar, DBCTL). The change should be
transparent to users already using the existing IMACIC..
members to decode those data.
The real reason for this enhancement now was that it is
now used to add support for additional CICS data that is
created by Omegamon for CICS Version 550. The additional
data are now supported by the new IMACIC.. "Omegamon"
members listed below.
IMACICDL IBM Local DL/I counters.
IMACICDU User counters/clocks/character data.
(Note that the length of the user data is still
defined, and can be decoded, 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.
Note that while the order of segment processing is now
set in IMACICDA, it is still required that you remove the
comment block in each member you want to enable. See the
comments in each member itself.
Thanks to Barry Pieper, First Bank Services Minneapolis, USA.
Change 09.145 Support for Omegamon for CICS Version 550 type 110 SMF
IMACEXCL record EXCLUDE logic (used ONLY by Omegamon for non-ESA
VMAC110 CICS, e.g., CICS 2.2 and earlier) has been added to MXG
Oct 3, 1991 IMACEXCL (itself new in MXG 9.2). Candle keeps only 31
of the standard 60 IBM fields, and Candle reorders them!
Reading a Candle excluded record without IMACEXCL gets
you an "Invalid TASKNR" error with MCTSSDCN=34.
(The exclude/reorder is optional in Omegamon, but your
CICS person must be extremely careful with Omegamon with
CICS Version 2, as the type 110 record that is created by
Omegamon is independent of the type 110 IBM CMF record -
both can be simultaneously created if both are turned on,
which can happen and has caused duplicate accounting of
CICS transaction counts and resources under CICS Version
2 regions. The problem does not occur in CICS/ESA, as
Omegamon does not create a type 110 record under CICS
Version 3 - it simply adds data (EMPs) to the end of the
IBM CMF record as described in Change 9.146).
The IMACEXCL member was originally added in MXG 9.2 to
support Shared Medical Systems exclude logic, and it now
has been revised to provide support not only for these
Omegamon exclude logic, but now can be used for any CICS
system with excluded/included fields.
Note that the three EMPs that Omegamon can also create
in CICS/ESA are separately supported by Change 9.146.
Note also that there is also an Omegamon CICS user SMF
record (that Candle unwisely defaults to ID=255, which
is the same default as their unrelated Omegamon for MVS
audit record!). That new CICS SMF record is supported in
Change 9.147. (The unrelated audit record support is in
member TYPEOMAU/VMACOMAU/IMACOMAU.)
Thanks to Jim Shumaker, American Express Phoenix, USA.
Change 09.144 DCOLLECT values for sizes of volumes and datasets were
VMACDCOL changed by APAR OY36364/UY55804, but MXG Change 8.285
Oct 1, 1991 was also in error. Before APAR, IBM used a track size
of 47968 (3380) or 58786 (3390) bytes, which is the
unformatted track capacity. But every track really has
a record R0, and users complained about DCOLLECT values.
IBM's APAR now uses the formatted track size available
after R0, the familiar 47476 (3380) or 56664 (3390)!
But when I validated the earlier number and found the
numbers were larger than expected, I assumed that the
values documented as "KB" were "thousand-bytes", and not
"kilo-bytes", and thus Change 8.285 incorrectly used a
factor of 1000 to convert raw values into "bytes". Now
the truth is know; DCOLLECT does store Kil0-bytes and
the correct conversion factor should have been 1024.
1.These values must be multiplied by 1024 instead of 1000
(they are listed in the order in which they appear):
DCDALLSP DCDUSESP DCDSCALL DCVALLOC DCVFRESP DCVLGEXT
DCVVLCAP UMDSIZE UMALLSP UMUSESP UMRECSP UBDSIZE
2.Two other variables were also in error, but unrelated
to the above error. Variables DCDBKLNG and UMBKLNG are
block length of datasets, and should not have been
multiplied at all. Delete the respective lines which
erroneously multiplied them by 1000.
The following table shows the values stored and reported
by MXG (after this change has been made to VMACDCOL),
before and after the above IBM APAR is installed. (Note
that after the APAR but without this change, MXG showed
the 3380D capacity as 587MB!).
Before APAR After APAR
Device Tracks Kbytes MB Kbytes MB
3380D 13275 621850 607 615472 601
3380E 26550 1243701 1214 1230945 1202
3380K 39825 1865552 1821 1846417 1803
3390-2 33390 1916859 1871 1847666 1804
3390-3 50085 2875289 2807 2771500 2706
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to Mr. Plaacht, RWG, GERMANY.
Thanks to Stuart Buck, Procter and Gamble Brussels, BELGIUM.
Change 09.143 Support for CMA-SPOOL user SMF record creates twelve new
EXCMA00X datasets, one for each subtype. The support is written
EXCMA01X in the "Subtype-Level Processing" architecture, which
EXCMA02X allows individual datasets to be created from selected
EXCMA03X subtypes, or all twelve datasets can be simultaneously
EXCMA04X created. See examples in the comments at the beginning
EXCMA05X of member VMACCMA. CMA-SPOOL is a product of SCA.
EXCMA06X
EXCMA07X
EXCMA08X
EXCMA09X
EXCMA0AX
EXCMA0BX
IMACCMA
TYPECMA
VMACCMA
Sep 30, 1991
Thanks to Charlan Ledbetter, Anderson Consulting Dallas, USA.
Change 09.142 TMON/MVS creates invalid records (if the data record is
VMACTMVS larger than the CI size of the VSAM dataset TMON/MVS
Sep 30, 1991 uses, the logic record is arbitrarily broken down into
"spanned" physical records that do not conform to normal
spanning, that have incorrect counts of how may real
segments are in a "spanned" record, and that can be
spanned right in the middle of a field!). MXG can only
recognize and delete these defective records, but the
DELETE; statement after the MXG error message was lost.
The spanned record was recognized, the error message was
printed on the log, but MXG still failed with INPUT
STATEMENT EXCEEDED RECORD LENGTH message. This change
put the DELETE; statement after the error message.
Additional failures occurred when "trashed" records were
created by TMON/MVS; these records had julian dates of
1989 and their "triplets" (offset, length, number)had
zeroes for offset and/or length. MXG previously only
tested the triplet-number, which was insufficient
protection for these defective records. Now, MXG uses
all three triplet fields, and the record length to
(hopefully) more robustly detect and delete defective
data records. Finally, MXG now can recognize if you
have tried to process compressed records without having
installed the MXG-provided de-compression exit (in MXG
member EXITMON6 for Version 6, EXITMONI for Version 5),
and the messages in this case are much cleared. Note
that until Landmark chooses to create valid records,
the data in their "spanned" records will be deleted.
Thanks to William Padilla, Farmers Group Insurance, USA.
Change 09.141 IBM APAR OY33312 (PTF UY52529,30,31), says "APAR OY25606
APAR/PTFs Contains an Incompatible Change to Type 30 Records" and
Sep 29, 1991 OY33312 proceeds to state that it will reverse OY25606,
and will change the length of SMF30EOR back to 2-bytes,
etc. Don't worry about it; OY33312 has no effect on MXG
processing of the type 30 record. The APAR affects only
assembly programs using IBM macros which reference the
DSECT fieldname SMF30EOR, but the APAR does not change
the location of any fields that MXG reads; MXG did have
to add code to support OY25606 (Change 8.081), but that
code works fine with or without OY33312.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 09.140 The author of this I/O report found these corrections:
ANALPATH Line 014900 should be XDUR = MAX(XDUR,SDUR); instead of
Sep 29, 1991 containing a + sign.
Lines 016700 and 016800 should use XDUR instead of SDUR
in the denominator (calculating GTSIOPS and GTATTPS).
Thanks to Cindy Batson, Hewitt Associates, USA.
Change 09.139 RMDS records with RMDSORG='D' were incorrectly decoded,
IMACRMDS causing "INPUT STATEMENT EXCEEDED RECORD LENGTH" error.
VMACRMDS in VMACRMDS, change line 043700 to read
Sep 29, 1991 ELSE IF RMDSORG='B' OR RMDSORG='D' THEN DO;
change line 044500 to read
RMDSDEST $CHAR19. (instead of 17),
insert after line 044700 a new line with
IF RMDSORG='D' THEN INPUT RMDSOWNR $CHAR8. @;
and change line 045900 to read:
ELSE IF RMDSORG='V' THEN DO;
Before the change, RMDSORG='D' was processed with 'V'.)
In verifying this error, the code in VMACRMDS was
restructured and renumbered, and comments made clearer
that RMDS Version 3 and Version 4 are identical.
Thanks to Steve Lottich, The University of Iowa, USA.
Change 09.138 Support for DB2 2.3.0.
DIFFDB2 IBM made incompatible changes in type 100 (Statistics,
FORMATS DB2STAT0/1 datasets) and in type 102 (Trace, T102Snnn),
VMACDB2 but existing MXG programs should have no problems, as
VMACDB2H long as you install MXG 9.4+ and update the MXG Format
VMAC102 library. You may want to exploit some of the new data,
Sep 29, 1991 as described in the following notes:
Change 09.137 Minor enhancements to type 30 MULTIDD='Y' observations.
VMAC30 Variable CPUERROR is now retained from the base record.
Sep 29, 1991 (It is a bit map character variable, but since it was
not input in the multi-dd record, it assumed a value of
'4040'X, potentially causing confusion). EXECTM is now
missing in the interval multi-dd records; recalculation
of EXECTM is performed only if not multi-dd record. The
JELAPSTM is now set missing in the multi-dd record.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.136 Variable DUPLXUSE in TYPE6 should not be used. It was
FORMATS originally used to identify Standard/Tumble Duplex, and
VMAC6 MXG format $MG006DU decoded '80'X or '40'X values. But
Sep 28, 1991 now, additional bits are used, invalidating the single
Nov 14, 1991 value hex decoding. SAS 6.07 supports bit testing for
formats, but SAS 5.18 syntax errors. MXG has replaced
format $MG006DU for variable DUPLXUSE with $HEX2., and
you should use the variables (STDUPLEX/TMBUPLEX) instead.
(All of the bits of old variable DUPLXUSE are now used
to set individual variables).
Thanks to Vickie Wong, Manufacturers Life, CANADA.
Change 09.135 ANALDBTR can fail with "DATASET S064058 NOT SORTED" even
ANALDBTR after Change 9.104 was installed, because one more typo
Sep 28, 1991 was missed. Line 161000 must be E064TM instead of the
E063TM variable name.
Thanks to Barry Bluestein, Union Carbide, USA.
Change 09.134 Support for MVS/ESA 4.2.2 (RMF 4.2.2) added several new
VMAC22 fields to several records, but most are not significant.
VMAC23 IBM changes are compatible.SMF manual now GG28-1628-2.
VMAC30 a.TYPE22 added new bit value in TYPE22_1.
VMAC40 b.TYPE23 support in MXG was incorrect. Fields added by
VMAC71 earlier APAR were not INPUTed because the test was for
VMAC90 the wrong length (also, order of new variables was not
Sep 28, 1991 correct). Code has now been corrected, so the new data
on SMF buffer statistics is now useful!
c.TYPE30 contains new 8-byte jobclass JOBCLAS8 (left
justified). Until it's clear that it's needed, MXG has
decoded but not kept the field. However, if the 1-byte
existing variable JOBCLASS is blank and the new JOBCLAS8
is non-blank, the first byte of JOBCLAS8 will be stored
in variable JOBCLASS. Do you see a need for 8-bytes?
This field was added by APAR OY42532.
d.TYPE40 contains two new fields, TDDRCIND/TDDRCTOT which
count the index and number of records in a sequence of
records, but I can't figure why they are needed, and
especially IBM states at the beginning of section that
"IBM recommends you use record type 30 rather than
record types 4, 5, 20, 34, 35, and 40"
its unclear why any change to type 40 was made!
e.TYPE71 record was not changed, but since RECLAIMS no
longer exist in 4.2.2, the four fields which formerly
counted reclaims (PVTNPREC,PVTVAMR,PVTCAREC,LPARECLM)
will now always be zero. Member VMAC71 was enhanced by
adding SMF71xx field names in comments adjacent to the
MXG variable name to map MXG names to IBM names.
f.TYPE90 now supports subtypes 19, 20, and 21 (which were
in 4.2.1 but not decoded by MXG - SET APPC, SET ASCH, &
SET SCH respectively), and supports the new subtype 22
(SET CNGRP) added by 4.2.2.
Change 09.133 Variable ID was added to the KEEP= list, since multiple
VMAC6156 SMF records (61,65, or 66) create observations in the
Sep 28, 1991 TYPE6156 dataset.
Thanks to Tony Curry, Manufacturer's Hanover, USA.
Change 09.132 Typographical errors printed in NEWSLETTER TWENTY have
ChangeS been corrected in the MXG SOURCLIB members. Errors were:
NEWSLTRS a.Newsletter TWENTY correctly stated that NOIMPLMAC must
Sep 28, 1991 be specified in CONFIG, but then should have said that
"IMPLMAC should never be used in ANY program."
instead of "NOIMPLMAC should never be used...."
b.In Change 9.066 text USERFMTS should have been IMACFMTS.
c.Several references to NPM 4.1.1 should have been 1.4.1.
Thanks to Pat Russell, Group Health Cooperative, USA.
Change 09.131 Members CONFIG and CONFIG07 have been updated to contain
CONFIG all of the MXG recommended options (added: ERRORABEND
CONFIG07 MACRO DQUOTE FIRSTOBS=1 OBS=MAX NOSOURCE NOSOURCE2
Sep 28, 1991 NOMACROGEN NOMPRINT NOMLOGIC). The new SAS 6.07 option
CODEPCT=120 was added only to CONFIG07; this option will
avoid a second pass of SAS compiler for very large MXG
programs (like a heavily enhanced BUILDPDB) and will
eliminate an unnecessary and confusing SAS message. Note
that options in the CONFIG file can be overridden by the
the JCL OPTIONS= parameter. For example, to print source
statements, you can print the entire source program with:
// EXEC SAS607,OPTIONS='SOURCE SOURCE2 MACROGEN',
// CONFIG='MXG.SOURCLIB(CONFIG)
Thanks to Pat Russell, Group Health Cooperative, USA.
Change 09.130 SAS Version 6 Compatibility. Options TLS= and TPS= do
ANALTMS5 not exist in Version 6. (They were used to set the line
Sep 28, 1991 size and page size of your terminal, and were set to 132
and 60 respectively in an OPTIONS statement in this ANAL
member. That OPTIONS statement was deleted.)
Thanks to Chuck Hopf, Primerica, USA.
Change 09.129 Variable SPMSEXTL in the KEEP= list for dataset SPMSCED
VMACSPMS should have been spelled SPMSEXTE. Variable SPMSDSN
Sep 28, 1991 should be added to the KEEP= list for dataset SPMSEXT so
you can match Extent data (SPMSEXT observations) to
their Definition data (SPMSCED observation). New Amdahl
PTFs for SPMS 1.2 are supposed to fix some data problems
but STARTIME is completely wrong in records that span
midnight; problem is being discussed with Amdahl now.
It has also been noticed that the SPMSATDC, allocated
track count delta, can be negative when less tracks are
allocated at the end than at the start of interval.
Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.
Change 09.128 -MXG 9.3 only. Change 9.080 incorrectly deaccumulated the
DIFFDB2 DB2STAT0/1 variables QBnTCBA and QBnTPID; eight lines
Sep 26, 1991 with those names must be deleted. QXCRRALS is spelled
Oct 3, 1991 QXCRALS. QISE.... variables RCUR,RHIG,RLLM,RMAX,
RDLM, and RSTG must be changed to QIST.... prefix.
-MXG 8.8 and later. Several sequence counter variables
have been incorrectly deaccumulated. For DB2STAT0,
delete lines DIF'ing QWHSWSEQ, QWSBWSEQ, QWSnISEQ,
QWnBWSEQ. For DB2STAT1, delete DIF'ing of QWHSWSEQ.
(Do not delete DIF'ing of variables ending in TSEQ, nor
the two statements SEQCHECK=DIF(...).)
Thanks to Barry Bluestein, Union Carbide, USA.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 09.127 Variable FSRTIME should have been in the KEEP= list for
VMACHSM dataset HSMFSRST; now it is.
Sep 9, 1991
Thanks to Peter Giles, DSS, AUSTRALIA.
Thanks to Colin Norton, DSS, AUSTRALIA.
Change 09.126 Boole's CMF records caused STOPOVER when record with a
VMACCMF non-zero offset and non-zero length but with a zero for
Sep 8, 1991 number of segments was found. The CHECKSUM logic did
not check for existence of segment before trying to read
the record. Only the Device Type Segment has thus far
had zero number, and changing line 00089700 to now read
IF C00DTYPN GT 0 THEN LINK CMFCKSM;
will circumvent this specific error. However, the MXG
change will protect each triplet by creating a variable
CMFWNUM set equal to the number of segments (immediately
following CMFWPTR which is set equal to the offset), and
then executing the subsequent LINK only if CMFWNUM is
greater than zero. There are 12 triplets to protect.
Thanks to Peter Giles, DSS, AUSTRALIA.
Change 09.125 This Cache DASD analysis report uses both TYPECACH and
ANALCACH TYPE74 data, but did not delete type 74 data from tapes!
Aug 20, 1991 Insert after PDB.TYPE74; IF DEVICE=:'34' THEN DELETE;
to exclude tape devices from Cache DASD reports.
Thanks to Jim Cummings, First Interstate Bank of Oregon, USA.
Change 09.124 Candle's OMEGAMON Audit User SMF Record has existed for
VMACOMAU some time, and defaults to SMF ID=255. However, their
Aug 20, 1991 new CICS V550 product now creates a different user SMF
record, which also defaults to ID=255, causing sites
using VMACOMAU to fail, since the new CICS user records
don't look anything like the Audit Record. You must
change the V550 SMF record ID (in Candle's OC$GLOB
SMFID= parameter in their OCDATA install dataset) to
a different SMF record ID. MXG support for the new
V550 User SMF record is discussed in Change 9.147.
Thanks to Dean Bolick, Belk Stores Services, USA.
Change 09.123 Protection for Shared Medical Systems CICS segments,
UTILCICS which have MNSEGCL values greater than 4, was not added
Aug 20, 1991 to UTILCICS when VMAC110 was updated in MXG 9.2. Now,
this member will skip over these segments instead of
printing ERROR.VMAC110.1 messages with MNSEGCL=209!
Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.
Change 09.122 For IMS measurement with Boole & Babbage's IMF product,
TYPECIMS the processing of Chained Transactions (at the end of
Aug 20, 1991 member TYPECIMS) should have also recalculated the
response time variable, RESPNSTM, using the ACTLARRV
time of the chained transaction. Insert after 008600:
RESPNSTM=ENDTIME-ACTLARRV;
Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.
Change 09.121 MXG decoding of DB2 Correlation ID into CORRNAME/CORRNUM
IMACDB2 was incorrect for CICS connection. The CORRNAME should
Aug 20, 1991 have been SUBSTR(QWHCCV,5,4) instead of (QWHCCV,9,4).
The comments describing the decoding of QWHCCV into the
CORRNAME/CORRNUM were also incorrect for CICS, and have
been revised and clarified.
Thanks to ???, UNI Storebrand, NORWAY.
Change 09.120 IBM now says the three new CPU time values added by ESA
XMAC7072 to the TYPE72 (CPUHPTTM,CPUIIPTM,CPURCTTM) are actually
VMAC7072 in micro-second units, and not 1024-microsecond units,
Aug 16, 1991 as documented in the microfiche for IRAWAMT! MXG Change
9.070 is thus off by 2%; the 1.024 factor added by that
change must be removed (fortunately, by comparing these
CPU times with their counterparts in type 30, I knew the
1000 factor was wrong, but believed IBM when they said
1.024 instead of 1.000!). Therefore, delete the three
lines multiplying these times by 1.024.
Thanks to Peter Doane, Com/Energy Services Company, USA.
Change 09.119 Invalid MODIFY ACF2 user SMF records are created, which
VMACACF2 caused INPUT STATEMENT EXCEEDED RECORD LENGTH error.
Aug 14, 1991 The record has a parm length of 1 byte, but there is no
ACFAPARM field in the record. C A could not see an
obvious code error, and required the Australian site to
open a problem, but not fix yet exists. For now, change
updated when CA responds. The circumvention for now is
lines 038900 and 039100 to read:
... 200 AND (COL-1+ACFAMPLN LE LENGTH) THEN ...
Thanks to Francis Han, Office of State Revenue, NSW, AUSTRALIA.
Change 09.118 Support for Software AG's NET-PASS user SMF record is
EXTYNETP added by this change, which captures response time
IMACNETP (average, and three distribution buckets) as well as
TYPENETP session logon, logoff, and disconnect/reconnect times.
VMACNETP
Aug 13, 1991
Thanks to Nancy Ayers, General Electric Lighting, USA.
Change 09.117 Minor. Variables DLYCHATM and DLYDIRTM in TYPE74 were
VMAC74 not formatted as TIME12.2, but now they are.
Aug 9, 1991
Thanks to Chuck Hopf, Primerica, USA.
Change 09.116 NPM 1.4.1 support was not complete in MXG 9.3. The code
VMAC28 does not fail, but messages (NON-ZERO COF, UNEXPECTED
Aug 9, 1991 SUBTYPE, CALL HOME) are printed, and not all of the new
Aug 12, 1991 subtypes were output. Several changes were required.
Thanks to Jim Shumaker, American Express, USA.
Change 09.115 SAS 5.18 compatibility. Step TESTIBM2 of JCLTEST needs
TESTIBM2 a 6000K region under 5.18 because TYPE102, instead of
Aug 8, 1991 TYPE102A,TYPE102B are included in MXG 9.3's TESTIBM2.
This change uses a %MACRO to detect which SAS version
is used and includes TYPE102 if under 6.06+, or includes
the pair TYPE102A, TYPE102B if under 5.18.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.114 The VM/XA utility UTILGEVX to create VB records for test
UTILGEVX referenced the non-existent member (MACROS) and had the
Aug 8, 1991 wrong macro names. The INCLUDE for (MACROS) should have
been for (VMACVMXA), the _INFILE should be _MWINPUT, and
the _ENFILE should be _MWENDIT. The comments should say
the input comes from fileref MWINPUT and VB records are
written to fileref OUTFILE.
Thanks to Jay Cicardo, Southwestern Bell St. Louis, USA.
Change 09.113 The VSAM Sharing Options in the VVDS were not fully
VMACVVDS decoded in the two flag variables VVRA2REG/VVRA2SYS.
Aug 8, 1991 Two new variables with values 1, 2, 3, or 4 for both
the cross-system and cross-region share options now are
created with:
VVRSHREG=FLOOR(INPUT(VVRATTR2,PIB1.)/64)+1;
VVRSHSYS=MOD(FLOOR(INPUT(VVRATTR2,PIB1.)/16),4)+1;
Thanks to Jeff Fox, SKF USA, Inc, USA.
Change 09.112 In analysis of ESA benchmark data, I discovered PERFGRP
VMAC30 and MULTIDD was not kept in TYPE30_D and PDB.DDSTATS.
Aug 8, 1991 Now they have both been added to the KEEP= list.
Thanks to Chuck Hopf, Primerica, USA.
Change 09.111 MXG recommended half-track BLKSIZEs of 23040/27647 for
CONFIG 3380/3390s but did not realize SAS 6.06+ has an option
CONFIG07 specifically for DASD, and there is also a TAPE option.
Aug 7, 1991 Now, MXG CONFIG/CONFIG07 contain
BLKSIZE(DASD)=HALF
BLKSIZE(TAPE)=MAX
Thanks to Chuck Hopf, Primerica, USA.
Change 09.110 Landmark CICS added the 8-byte APPLID in their 8.1. MXGs
ASUMCICS 7.1 summarization code had stored SYSID into APPLID to
Aug 7, 1991 create APPLID, but that line now causes APPLID to be
truncated to 4 bytes with 8.1. Change line 008700 from
APPLID=SYSID;
to read
IF APPLID=' ' THEN APPLID=SYSID;
and add APPLID to the KEEP= in line 006200.
This change will only work with Landmark 8.1 data; the
datasets built from 7.1 data records does not contain
the variable APPLID, so the change must coincide with
your implementation of TYPEMON8 processing of 8.1 data.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.109 The BLKSIZE of the MXG 9.3 tape was increased to 32720.
ChangeS The 9.3 label printed on the tape was correct, but the
INSTALL change from 6160 was not stated. Worse, a note in the
Aug 7, 1991 Installation section of Newsletter TWENTY said the tape
BLKSIZE was 23440, which it never has been! The tape
blocksize had to be increased so that MXG 9.3 would fit
on a 600-foot 3420 reel, but it also reduced the time to
create 3420 or 3480s. The BLKSIZE=32720 will now be used
for all future MXG Versions. Sorry for my carelessness!
Change 09.108 JCLTEST/JCLTEST6 step SMFSMALL needs SASLIB/LIBRARY DD
JCLPDB6 pointing to your format library because Change 9.094 now
JCLTEST uses the MXG MGBYTES format. In JCLPDB6, a // is needed
JCLTEST6 before the OPTIONS= parameter on the EXEC statement.
Aug 7, 1991
Thanks to Mark Delorme, Minnesota Power, USA.
--Changes thru 9.107 were contained in MXG PreRelease 9.3, Aug 1, 1991--
Change 09.107 MONITASK variable TATASKNR contains transaction counts
TYPEMON8 for history records, but Landmark's Release 8 relocated
Jul 30, 1991 the field to what MXG read as TASINTL1 $CHAR4. Now, that
input is TATASKNR PIB4., the original TATASKNR is now
unkept variable TATASKNN, and TASINTL1 was never kept.
Thanks to Annette Miller, Dale Electronics, USA.
Change 09.106 IMS multiple-message transactions resources were wrong.
TYPEIMS Lines 145300-148400, which calculate the average DL/I,
Jul 30, 1991 CPU, etc., must be moved to after line 144200, so that
the average is calculated only once, instead of being a
moving average.
Thanks to Russell Dewar, NM Computer Services, AUSTRALIA.
Change 09.105 Change 9.100 discussed the new DROP,KEEP,RENAME warning.
DOC While initially I did not like the default of warning,
Jul 30, 1991 it appears to be worthwhile; it uncovered many cases of
misspelled variables in KEEP lists that were not being
output, and some cases of variables that should have not
been in the KEEP list, when I ran the MXG 9.3 QA runs.
All members that could be corrected were, but some MXG
members intentionally contain unreferenced variables,
and these members may produce warnings (which have no
real impact, except for the condition code four!):
VMAC6 VMAC40 VMAC110
The protection in BUILDPDB/BUILDPD3 was extended to
suppress warnings for the entire member.
--Changes thru 9.104 were printed in MXG Newsletter TWENTY Aug 1, 1991--
Change 09.104 DB2 102 Trace Data causes ANALDB2R to fail with DATA SET
ANALDBTR NOT SORTED error in S008S009, S0015S018, or S059S058 due
Jul 28, 1991 to a misspelling in ANALDBTR. The error occurs only if
a one of these trace events was incomplete, i.e., when a
start event or end event record was not in the input.
These three sets of variables were reversed:
Line Now Should be
049000 IF E008TM=. IF S008TM=.
049400 IF S008TM=. IF E008TM=.
068100 IF E015TM=. IF S015TM=.
068500 IF S015TM=. IF E015TM=.
164500 IF E059TM=. IF S059TM=.
164900 IF S059TM=. IF E059TM=.
Thanks to Bob Farrell, Sun Alliance, ENGLAND.
Change 09.103 -A minor revision to ANALPATH was provided by its authors
ANALPATH to deal with a divide by zero if no prime shift data was
IMACPDBX used for the analysis.
Jul 28, 1991 -The new member IMACPDBX will undoubtedly replace the MXG
IMACPDB, but is placed in a separate member for sites to
validate its architecture. Dan Kaberon has implemented
a slick technique that lets you trivially change the
variables that are sum/min/maxed from the steps data to
PDB.JOBS, and you no longer have to count and set up the
"dummy" X variables in the original IMACPDB. The new
member also added three variables, PGSUSED PGSGLOAD and
SHEETPRN to the PDB.PRINT data set.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 09.102 -Multiple type 30 records will be written for each step,
BUILDPDB interval, or job, if more than 1476 DDs are in the task.
BUILDPD3 MXG has always created separate observations for each of
IMACPDB these "Multi-DD" records, which contain only EXCP/IOTM
VMAC30 resource fields. However, several elapsed time measures
Jul 28, 1991 calculated by MXG from timestamps (ALOCTM,DSENQTM,EXECTM
RDRTM,SELAPSTM) should not have been calculated, and are
now set missing. A new variable, MULTIDD='Y' is created
to flag these records in TYPE30_4, TYPE30_5, TYPE30_6,
and TYPE30_V datasets. If the need is demonstrated in
the future, MXG may add logic to sum the MULTIDD type 30
into a single record, but the cost of double processing
does not seem necessary at this time. For now, flagging
these "pseudo-step" records and ensuring there is no
duplication of these elapsed time measures is enough.
MULTIDD was also added in IMACPDB to the _PDB30_4 list.
-The MULTIDD records for TYPE30_V intervals have another
problem; the begin of interval INTBTIME does not exist
(has missing value) in the second and subsequent MULTIDD
record (because IBM puts it in the processor accounting
section, which is not created in MULTIDD records!). The
INTBTIME cannot be retained from the first record to the
subsequent records while processing SMF data, because
other SMF records from other tasks can be sent to SMF in
between the first and subsequent intervals of our job.
It was necessary to modify the logic of BUILDPDB/3 to
add an extra PROC SORT and logic to fill in the missing
INTBTIME, so that sites who wish to account using their
interval records can cluster the MULTIDD records. If
your site creates interval records, you probably want to
have this corrected, and if there is no interval data,
there is no cost to this enhancement of PDB.SMFINTRV.
Note this change does not correct the TYPE30_V data set
built by member TYPE30, but only the PDB.SMFINTRV data
set built by BUILDPDB/BUILDPD3.
-Two other problems with MULTIDD records were corrected
in BUILDPDB/3. The variable STEP was a counter of step
records found, but it was also being incremented for
each of the MULTIDD records. STEP is now incremented
only for the actual step record, not for the MULTIDDs.
The variable RESTART was a counter of job restarts, but
it too was being incremented for each MULTIDD record.
Now it only counts real job terminations as RESTARTS.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.101 DOS/VSE Landmark CICS records are non-standard formats.
TYPEMOND Each block begins with 2-byte block length, followed by
Jul 27, 1991 two 4-byte length fields, the second of which contains
the data-length of the following data record. The 4-byte
pairs and data records are then repeated. This format
can be read with the following changes to TYPEMONI for
Landmark 7.1 records. The new member TYPEMOND contains
this change, but the logic has not been data-tested yet.
Replace With
INPUT INPUT BLKLEN PIB2. @;
LENGTH PIB2. LOC=COL;
MFSREC $CHAR1. DO WHILE (COL+8 LT BLKLEN);
@; INPUT @LOC FIRSTLEN PIB4.
LENGTH PIB4.
MFSREC $CHAR1.
@;
LENGTH=LENGTH-2;
Immediately before the
percent sign before
MACRO _ANALMON insert
LOC=LOC+FIRSTLEN;
END;
Thanks to ???, ???, EUROPE.
Change 09.100 SAS 6.07 compatibility. SAS validation of variables in
BUILDPDB KEEP, DROP, or RENAME statements or options was never
BUILDPD3 consistent; an unreferenced variable in a "D,K,R" could
CONFIG07 print an error, a warning, or no warning, depending on
Jul 27, 1991 whether the "D,K,R" was an option or a statement and/or
whether the "D,K,R" was for input or output. SAS 6.07
now consolidates the action by input or output and has
two new options, DKRICOND and DKROCOND which can set the
action to be taken to ERROR, WARN, or NOWARN. By design,
MXG has unreferenced variables in KEEP= lists for output
and since the SAS 6.07 default is WARN, many unnecessary
WARNING message will be printed on the log, and the step
will end with condition code 0004. These warnings can
be eliminated by adding DKROCOND=NOWARN to the CONFIG
member of MXG, but then SAS 6.06 will fail because this
option is unknown to SAS 6.06! As a result, there is a
now a new member, named CONFIG07, for SAS 6.07 which has
DKROCOND=NOWARN specified. Just in case you miss this
note, however, BUILDPDB/3 are specifically protected by
the addition of %MACRO VMXGDKRN to set NOWARN during the
SMF processing phase under 6.07 or later:
%MACRO VMXGDKRN;
%IF %SUBSTR(&SYSVER,1,4) GE 6.07 %THEN %DO;
OPTIONS DKROCOND=NOWARN;
%END;
%MEND
%VMXGDKRN;
and after the DATA step there is a %MACRO VMXGDKRW to
reset the option to DKROCOND=WARN. This may change as
more experience with these new options accumulates.
Thanks to Rick Langston, SAS Institute Cary, USA.
Change 09.099 Dataset VTOCINFO's variable TRKSALOC contained only the
VMXGVTOC number of tracks allocated for the VTOC; not the total
VMXGVTOF tracks on the volume. This change summarizes the detail
Jul 27, 1991 information into VTOCINFO, correcting TRKSALOC, and adds
variables TRKSUSED, NUMDSN, PCTALOC to make the VTOCINFO
dataset more meaningful for DASD capacity analysis.
Additionally, in the VMXGVTOF member only, each volume's
UNITADDR, UCBTYPE, and STARTIME (of the ASMVTOC run) are
now added to the VTOCINFO dataset. These fields were at
the end of the record created by ASMVTOC, but were not
kept in MXG's processing.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 09.098 The original members WEEKBLD and MONTHBLD contained both
JCLWEEK JCL and SAS code, which required unnecessary JCL changes
JCLMONTH due to SAS or SAS changes due to JCL. This change puts
WEEKBLD the sample JCL in members JCLWEEK and JCLMONTH and has
MONTHBLD only SAS code in WEEKBLD and MONTHBLD. The JCL examples
Jul 27, 1991 in these members (an in all future JCL examples) will be
only for the SAS Version 6 environment.
Change 09.097A -The optimal BLKSIZE for MXG's SAS Data Libraries is half
CONFIG track (See SAS Notes in Newsletter TWENTY). Since these
Jul 26, 1991 libraries are RECFM=FB,LRECL=512, the correct half track
data library block sizes are
Data libraries:
3380 BLKSIZE=23040
3390 BLKSIZE=27648
Member CONFIG now specifies BLKSIZE=23040 as default.
-The MXG Default BUFNO=2 is now specified in CONFIG. With
a half-track BLKSIZE, transferring one track of data per
SSCH results when BUFNO=2 is specified. The incremental
gain of additional buffers above 2 does not seem needed
and I have always felt righteous if I transferred data
for 1 revolution and then freed the device to other
users. Since the virtual storage required for each SAS
data set is BUFNO*BLKSIZE, reducing BUFNO from 3 to 2
concomitant with the above BLKSIZE increase will
mitigate MEMSIZE. I plan further benchmarking to see if
there really is a value in increased BUFNO (only even
values make sense), but early results show half track
and BUFNO=2 gives very good performance and minimized
resources reasonably.
-The increased BLKSIZE value has increased the virtual
storage required for the INFILE processing parts of MXG,
so MEMSIZE=24M is now specified (increased from 12M) to
ensure unnecessary "out-of-virtual-memory" ABENDs. Since
MEMSIZE is above the line virtual storage, I don't think
this increase will affect any real resources, and SAS
only gets what it needs anyhow.
-The option ERRORS=2 was added, so that if you get any
invalid data hex dumps, only the first two will be on
your log, instead of the SAS default of the first 20.
Change 09.097 HSM 2.6 SMF records were changed INCOMPATIBLY. The DSR
VMACHSM and VSR have new fields, VSR fields (VSRTBAK,VSRTALC,
Jul 24, 1991 VSRNDSV, and VSRTCPU), are now reserved, and bit fields
are now decoded into new variables. MXG supports not
only HSM 2.6, but also HSM 2.4 and 2.5 SMF records.
Thanks to Joe Faska, Depository Trust, USA
Change 09.096 VM/XA messages "LOGICAL RECORD SPANS PHYSICAL BLOCK" are
VMACVMXA incorrectly printed on the log. The error was introduced
Jul 22, 1991 by Change 8.244; line 005970 must be (COL-5+MRHDRLEN).
Fortunately, the datasets built were valid, but the MXG
messages sure filled pages of your log!
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Thanks to ???, ???.
Change 09.095 BUILDPDB is enhanced by the automatic addition of the
BUILDPDB dataset TYPE0203 in your PDB, so you can keep track of
BUILDPD3 when SMF data was dumped; a type 2 record is written at
VMAC0203 the start of each SMF dump (IEASMFDP) and a type 3 is
Jul 21, 1991 written at the end of each dump. Back to back type 2s
indicates probable duplicate data, because a dump was
started but failed to complete. Member VMAC0203 was
also changed, to create variable RECNUM, the record
number of each 2 or 3 record, in case you need to strip
out duplicated records.
Change 09.094 The _SMF macro, used by all SMF processing programs, now
VMACSMF prints a message on the log "MXG SUCCESSFULLY READ SMF"
Jul 21, 1991 with the number of records AND the number of megabytes
of data that was found in your SMF file.
Change 09.093 This revision of existing TRND72 member adds several new
TRND72 MVS/ESA 4.2 variables to the TREND.TRND72 dataset.
Jul 20, 1991
Thanks to Chuck Hopf, Primerica, USA.
Change 09.092 Trending of TYPE71 data is added by this change, using
TRND71 the WEEK.TYPE71 dataset as input. (Since the TYPE71
Jul 20, 1991 data already exists as one observation per interval,
there is no need for an "ASUM71" member.)
Thanks to Chuck Hopf, Primerica, USA.
Change 09.091 Trending of PR/SM, MLPF or MDF data in TYPE70PR is added
ASUM70PR by this change. Member ASUM70PR creates PDB.ASUM70PR by
TRND70PR summarizing TYPE70PR into one observation per interval
Jul 20, 1991 for each system. (If you have more than one MVS system
running, remember that each one creates observations in
TYPE70PR for each SYSTEM. Either SYSTEM or LPARNAME has
to be used to avoid duplication in your reporting. MXG
keeps all SYSTEMs found in TYPE70PR). Member TRND70PR
takes the WEEK.ASUM70PR, and adds its new data to the
TREND.TRND70PR data, which can be used for tracking the
utilization of all your LPARs.
Thanks to Chuck Hopf, Primerica, USA.
Change 09.090 ASUMCICS used more temporary work space than needed, as
ASUMCICS some variables were not dropped, and no LENGTH statement
Jul 20, 1991 was used. After line 003400 (DATA NULLCICS;) insert
LENGTH DEFAULT=4 ENDTIME STRTTIME 8;
After line 009199 (END;) insert
DROP ENDTIME FILECN PRIINCHR PRIOUCHR RESPONSE
SYSID TRANSACT;
Change 09.089 VM/XA Trending variables PFXUTIME and PCTCPUBY were not
TRNDVMXA correct. PFXUTIME was wrong because it should be in the
Jul 18, 1991 NORM13 list instead of NORM1. PCTCPUBY was wrong because
it is recalculated and uses PFXUTIME!
Thanks to ???, 3M Europe, GERMANY.
Change 09.088 Amdahl's Cache DASD SPMS Release 1.2 completely rewrote
EXTYSPMC their user SMF record. The original VMACSPMS supported
EXTYSPME SPMS Release 1.0, but that code was temp VMACSPM0, and
VMACSPMS VMACSPMS now contains support only for SPMS 1.2. There
are two data sets created now, SPMSCED "Cache Extent
Jul 18, 1991 Definition" statistics, for each CED (which might be an
entire volume, or just a data set), and SPMSEXT "Cache
Extent" statistics, for each EXTent (which will normally
contain one observation for each CED, unless the dataset
in the CED is itself in extents). Although statistics
can be captured in the CED part of the record, there is
an option to disable statistics in the CED, so MXG will
create the sum of the EXT data and store into the CED
dataset, which seems to be the most likely dataset of
general interest, and by summing the EXT data into the
CED, either data set will be valid. Note that some of
the fields may not be valid; SPMSATBC contains negative
values. Amdahl is investigating.
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 09.087 Only comments were changed in IMACFILE, but the example
IMACFILE showing how to write SMF records out to an OS file now
Jul 18, 1991 has a FILE LOG; statement after the PUT _INFILE_ so that
and error messages PUT by MXG will be sent to the log.
Without the FILE LOG; statement, error messages were
written to the output SMF file!
Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.
Change 09.086 ACF2 records with ACSMFREC='L' and ACSMFCN GE 3 were not
VMACACF2 processed. They are now output in the ACF2JR dataset.
Jul 18, 1991 The LID at the end of these records is not currently
decoded; since the records themselves were not output,
it is not clear the contents of the LID are needed, but
that will change if users request it! The change was to
change ELSE IF ACSMFREC='L' AND ACSMFFCN LE 2 THEN DO;
to ELSE IF ACSMFREC='L' THEN DO; in line 049400, and
change IF ACSMFFCN=2 THEN DO;
to IF ACSMFFCN GE 2 THEN DO; in line 050200.
Thanks to Rachel Bromage, L.O.L.A., ENGLAND.
Change 09.085 Early Address Spaces (Started Task ASIDs that come up
VMAC6 before SMF is fully up) have no JES number and their
VMAC26J2 JCTJOBID variable contains job name. The logic added in
VMAC26J3 MXG 8.8 to support the APPC TYPETASK tested JCTJOBID to
VMAC30 see if it started with an "A", but this caused "Invalid
VMAC32 Data Error" for JESNR if the STC happened to start with
Jul 18, 1991 an "A" (like ACF2!). This change reorders the logic to
first recognize an early address space (JCTJOBID=JOB)
to set TYPETASK='STC ' and JESNR=., or otherwise use the
original logic to determine TYPETASK and JESNR. The only
impact were messy record dumps on the log when MXG tried
to read characters as numbers!
Thanks to Stephen Tull, State Energy Commission of W.A., AUSTRALIA.
Change 09.084 For consistency in CICS, variable PCLOADCN was changed.
VMAC110 Its old contents, the count of load requests, was moved
Jul 18, 1991 to new variable PCLOADCT, which will be non-missing in
all CICSs, and the old variable PCLOADCN contains the
count of actual loads. The change occurred in MXG 8.8
but was not documented.
Thanks to Ms. Ericson, EDV Gmbh, Vienna, AUSTRIA.
Change 09.083 In Newsletter SIXTEEN, I made mention of APAR OY16896,
BUILDPDB but did not elaborate on its significant effect on lines
VMAC6 printed counting in MXG. The APAR changes the variable
Jul 17, 1991 OUTDEVCE (SMF type 6 field SMF6OUT). Formerly, OUTDEVCE
was the name of the output device to which the print was
sent, e.g., PRINTER1, PUNCH2, or R196.PR1 for a remote
printer, R196.PU1 for a remote punch (remember, external
writers for microfiche and other devices often "punch").
The APAR changed OUTDEVCE to contain the VTAM LUNAME of
the printer, which no longer contains indication of the
type of device to which print was sent. MXG still uses
OUTDEVCE to create variable DEVICE in TYPE6, setting
DEVICE='PRINT' (if OUTDEVCE starts with 'PRINT' or 'PRT'
or contains '.PR', or UCS starts with 'VPS, or setting
DEVICE='PUNCH' (if OUTDEVCE starts with 'PUN' or
contains '.PU'). If no match is found in OUTDEVCE, then
MXG sets DEVICE='EXT WTR'. The APAR not only changes
the contents of variable DEVICE in TYPE6, but BUILDPDB
uses the value of DEVICE to decide if NRLINES are put
in variables PRINTLNE, PUNCHCRD, OR EXTWTRLN in both the
PDB.JOBS and PDB.PRINT data sets. The total of those
three variables will still be correct, but you cannot
trust PRINTLNE to contain print lines; all of the lines
printed could end up in variable EXTWTRLN.
If the breakout is important to your site, you will have
to first create a table look up mapping VTAM LUNAME to
the type of device, and use that table in member EXTY6
to set DEVICE= to the correct device type for your site.
As long as you use the SUM(PRINTLNE,PUNCHCRD,EXTWTRLN)
for TYPE6 or PDB.PRINT analysis/billing, there is no
error.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 09.082 Interlink's product SNS/vt is actually the ANET product
VMACILKV from Teubener Associates, and is also marketed by Mitek
Jul 17, 1991 (now Open Connect Systems) as Telenet Client Fullscreen!
By whatever name, however, the disconnect record has a
bug (CONECTIM does not contain a date) that is now fixed
in their release 322.
Thanks to Dan Barbatti, Southwestern Bell St. Louis, USA.
Change 09.081 EPILOG CICS CL1000 records, by default, are dumped by
IMACEPIL Candle's utility as RECFM=U, even though the records are
Jul 16, 1991 actually internally VB, with BDW=600 and RDW=LRECL=596.
The only problem with RECFM=U is that when written to a
tape data set, lots of space is wasted between these
600 byte records. Sites have, therefore, chosen to
change the output RECFM of the Candle dumping program to
specify VB, reducing storage on tape from 5 volumes to a
single volume, but this creates an additional BDW/RDW on
the tape, a "VVBB" RECFM! MXG has always handled these
two formats; if the output is dumped with RECFM=U then
OFFEPIL=0 is specified in IMACEPIL, and if the output is
dumped with RECFM=VB, then OFFEPIL=4 handles the extra
four bytes on each record, but only now do I realize in
which case which offset is specified in IMACEPIL!
Thanks to Myron Highfield, Square D, USA.
Change 09.080 Some new DB2 variables in DB2STAT0/DB2STAT1 were not
DIFFDB2 deaccumulated. QLSTx, QWTRx, QW2x-QW5x, Q9STCTRI,J,K,L
Jul 16, 1991 in DB2STAT0, and QBnTCBA,QBnTPID,QISERx,QXCRRALS,QXDRPAL
QXMRMIAP,QXMSMIAP,QXNSMIAP in DB2STAT1 are now correct.
Thanks to Elliot Weitzman, Orxy Energy Company, USA.
Change 09.079 Data set TYPE30_D can contain duplicate observations, if
BUILDPDB the same DDNAME appears multiple times in a step record.
BUILDPD3 The NODUP option was removed from the PROC SORT of the
Jul 11, 1991 TYPE30_D into the PDB.DDSTATS to prevent unintentional
deletion.
Change 09.078 SAS 6.06 circumvention. In SAS Version 5, a DO variable
VMACCMF could be missing, and SAS treated the value as zero. In
VMXGHSM SAS Version 6, however, a missing value for one of the
Jul 10, 1991 DO loop variables raises a syntax error and terminates
execution. This problem was simultaneously encountered
in two unrelated members on the same day!
a.In VMXGHSM, before the DO C= 1 TO MPCDGNCT; insert
IF MCPDGNCT=. THEN MCTDGNCT=0;
Unrelated VMXGHSM corrections were also made.
MCDCLU should have been spelled MCDDLU. INPUT
MCTFRAG PIB2 should have been PIB2. (with a period).
DCRDATEX should have been DCRDATE.
MCVLSPCT should have been INPUT as PIB4.2, and the
subsequent DMS function deleted, as it was not PK4.
DSRTIME should have been INPUT as PIB4.2, and the
subsequent DMS function deleted, as it was not PK4.
b.In VMACCMF, before the DO on _I_, insert
IF CMFWPTR=. THEN CMFWPTR=0;
IF CMFCHKTG=. THEM CMFCHKTG=0;
and four lines later, change IF CMFCHKRM NE 0 ....
to read IF CMFCHKRM GT 0 ....
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Thanks to Bill Dempster, UOP, USA.
Change 09.077 The macro _CICEXCL referenced at the end of IMACCICS was
IMACCICS only used in MXG testing and should have been removed.
Jul 9, 1991 All of the installation controls for EXCLUDE processing
are contained in member IMACEXCL.
Thanks to Tim Cartwright, University of Wisconsin Madison, USA.
Change 09.076 Option NOTEXT82 was never in SAS 6.06, and is removed
CONFIG from MXG's CONFIG member. It caused no execution error,
Jul 4, 1991 but confused users who tried to figure out what it was.
It should not have been in CONFIG in the first place!
Change 09.075 This is a document change, pending IBM answers. The two
VMAC42 fields SMF42LFW and SMF42CFW are now acknowledged by IBM
Jul 4, 1991 to be accumulators and not counts for the interval. They
have not yet acknowledged this as a bug or a feature!
Thanks to Joe Faska, Depository Trust, USA
Change 09.074 Boole's unique CMF record processing member needs a
VMACCMF RETURN; statement inserted immediately before the label
Jul 4, 1991 CMFCKSM: statement.
Thanks to Bill Dempster, UOP, USA.
Change 09.073 Change 8.213 gave an example for using INSTREAM DDNAME
Change08 to create the _DAY macro for copying yesterday's PDB to
Jul 4, 1991 the correct day-of-week PDB, but the example failed to
execute. First, the OPTIONS NOTITLE; statement should
be deleted (that options no longer exists). Second, the
PRINT option in the FILE INSTREAM statement should be
NOPRINT. Third, a blank is required after _DAY in the
quoted string: 'MACRO _DAY ' to be written to INSTREAM.
The example has been corrected in member CHANGE08 so you
could copy it for execution. Finally, under SAS 6.06+.
WEEKDAY=UPCASE(PUT(TODAY,WEEKDATE3.));
is required because the PUT function returns mixed case.
Thanks to Mark Steeley, Anthem Insurance.
Change 09.072 TYPE70PR data for DEDICATED='Y' LPAR's LCPUADDR 2 and 3
VMAC7072 incorrectly subtracted CPUWAIT0 in lines 134620,134660.
XMAC7072 The obvious typing error should have subtracted CPUWAIT2
Jul 4, 1991 and CPUWAIT3 respectively, and came in MXG 8.8.
Thanks to Helmut Kirrmaier, Comparex Mannheim, GERMANY.
Change 09.071 VLFHITPC hit percentage was conditionally calculated if
VMAC41 SMF41SRC was non-zero, but should also have been set to
Jul 2, 1991 missing with an ELSE clause. Without the ELSE clause, if
the record had classes with no activity, the prior class
value for VLFHITPC was carried forward.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 09.070 TYPE72 new CPU variables CPUHPTTM,CPUIIPTM CPURCTTM,
VMAC7072 added by MVS/ESA 4.2, are wrong. Lines 157900-158200
XMAC7072 must INPUT these three variables as PIB4.6 instead of
Jul 2, 1991 PIB4., and then each variable must be multiplied by
1.024 after the input statement. This error also made
the variable CPUTM, as it includes these three. Note:
see revision in Change 9.120.
======Changes thru 9.069 were on MXG 9.2 built July 1, 1991=============
Change 09.069 Candle's External Security Audit SMF record needs a ZAP
VMACOMAU from Candle, OB270S10 to capture the DB2 Subsystem ID if
Jun 30, 1991 an Omegamon DB2 command is being audited; otherwise you
will not know which DB2 subsystem was the object of the
Candle command that was issued. Even with the ZAP, the
subsystem ID is not put in the right place; instead of
in being in MXG variable OMSUBSID where it belongs, the
ID value is stored in MXG's variable OMSTEP. No change
was made to MXG to move it to the right field, Candle
has not called, and the zap and this note may be enough.
Thanks to Wayne Cope, Belks Stores, USA.
Change 09.068 CA's IDMS Performance Monitor SMF records appear to be
VMACIDMS in error. TASPAGRD contains 'FFFFFFFB'x, which MXG sees
Jun 30, 1991 (inputing at PIB4.) as 4,294,967,040, and the Cullinet
report (no, they have not changed the report header yet)
shows a negative 4. Separately, the TASIMWT wait time
duration is sometimes greater than the delta between the
STARTIME and ENDTIME. No MXG change was made to deal
with what appear to be IDMS errors. Stay tuned.
Thanks to Elizabeth Stronge, Michelin Tier Corp, USA.
Change 09.067 Trending TYPE72 data did not contain PERFRPGN, so you
TRND72 could not know which performance groups were control and
Jun 30, 1991 which were report (unless you resorted to an external
table or format). This change added PERFRPGN to the ID
statement so it will now exist in trended TYPE72 data.
Thanks to Seymour J. Metz, EDS, USA.
Change 09.066 SAS 6.06 does not support concatenated Format libraries
FORMATS (since they are now SAS datasets, which still cannot be
IMACFMTS concatenated). New tailoring member IMACFMTS is created
Jun 30, 1991 to allow you to put your installation's VALUE statements
in this separate member of your USERID.SOURCLIB. The
member IMACFMTS is %INCLUDEd at the end of MXG's member
FORMATS so that your formats will be placed in the same
data library as the MXG formats. One suggested use was
to define performance group mapping in this member.
Thanks to Seymour J. Metz, EDS, USA.
Change 09.065 DASDMON/ASTEC load counts RLDCNT and RDLCNT in VMACDMON
VMACDMON should have been input PIB4.2 instead of PIB4., though
Jun 30, 1991 there was no clue in the DSECT documentation. Only the
observed very large values and comparison with Legent's
reports uncovered their documentation error.
Thanks to Greg Scriba, First National Bank of Chicago, USA.
Change 09.064 This significant user contribution is a 15-member PDS in
ANALRACF member ANALRACF that will analyze the use of MXG TYPE80
VMAC80 observations for the use of RACF commands with SPECIAL
Jun 30, 1991 or OPERATIONS authority. Documentation and flow of the
programs are contained in member ANALRACF. Three new
variables were added to the TYPE80 KEEP= list, NRSET,
RACFDAT1, and RACFVRMN, to support these reports.
Thanks to Duncan McKellar, Inland Revenue (UK), ENGLAND.
Thanks to Neil Campbell, Inland Revenue (UK), ENGLAND.
Thanks to Dave McLaughlin, Inland Revenue (UK), ENGLAND.
Change 09.063 Yet another problem with IMS Input Queue time was found.
TYPEIMS Out of 22,000 transactions, type 35x log records for 18
VMACIMS transactions contained the LTERM value in the NODENAME
Jun 29, 1991 field, causing the 35x (ENQTIME) to not be matched with
the 01x (ARRVTIME) record. These 18 records all have an
ENQFLAG=0Cx and FLAG2=ACx, and had CLBNAME=LTERM and 16
bytes later, the NODENAME needed was found in the "Input
subpool name" part of IBM's QLNQLNID (and, as usual for
IMS, there is no indication in the IBM IMS DSECT of this
condition). MXG has again been patched to support this
IMS variation. Another change, unrelated, had been left
out of the MXG 8.8 changes; for Multi-Transactions per
schedule, the CONDCODE was propagated into all IMSTRAN
observations; now it is blank until the final one. And
occasional negative service times for Multi-Trans and
WFI transactions were corrected by not re-setting the
ENDTIME to an incorrect earlier value. I always want
to think each IMS fix is the last one, but I have little
doubt that there will be future discoveries. But then
even IBM's IMSPARS is frequently unable to correctly
count transactions, and frequently can't figure out the
time stamps that MXG can locate in the log records, so
it is clearly not straightforward to decode the IMS log,
in which the records are written out of order by time!
I do believe there have never been errors in MXG's IMS
resource capture (CPU, DLI, counts, etc.), and only in
the Input and Output Queue times have there been wrong
calculations, and statistically few in number. This does
suggest STRONGLY to avoid using average values for the
analysis of IMS response, service, and queue times. One
large value can completely distort the average value,
but counting the percentage that completed in a specific
duration will not be so affected, and is much safer to
report. Even at its very best, though, the IMS log is
NOT the recommended source for IMS analysis; at best it
provides only one single measure of CPU time for each
program schedule (which might represent hundreds of real
transaction), and that CPU time cannot be subdivided
into Message Region, DB2 services, DL/I services, etc.,
which can and are captured currently by third-party IMS
monitors which write discrete transaction records for
analysis. Sites to whom IMS is a significant workload,
and especially sites with WFI, Fast Path, or lots of
multi-trans per sked activity should invest in an IMS
monitor until IBM decides to provide transaction-level
resource and response time recording in the IMS log.
Thanks to Lindsay Dawe, Mobil Oil, AUSTRALIA.
Change 09.062 CICS/ESA 3.2.1 became available today. MXG now supports
VMAC110 all releases of CICS from 1.5 thru CICS/ESA 3.2.1.
Jun 28, 1991 In fact, due to IBM's ETP program, MXG 8.8 contained
support for CICS/ESA 3.2.1, and thus you do NOT need to
install a new release of MXG just for CICS/ESA if you
have already installed MXG 8.8. Versions of MXG before
MXG 8.8 will fail with CICS/ESA 3.2.1 records, because
3.2.1 records were changed incompatibly (CICS version
SMFPSRVN was changed from an EBCDIC field containing 31
to a PK2. field containing 321). That incompatibility
is actually beneficial; finally we can recognize the
version, release, and modification-level of CICS. The
other changes between last fall's CICS 3.1 and 3.2.1
are minor, but a new timestamp, taken at CICS startup,
was added to the type 110 record, used to collect all
records from a specific execution of a CICS region. It
would really been useful if IBM had stored, not the STCK
value when CICS started, but instead had copied the
READTIME of the CICS job (which already exists) because
then CICS SMF could be directly MERGED/JOINED with the
other SMF records (like 14,15, and 64 I/O records) that
have contained READTIME for the "Job Log" since day 1
of SMF data! Oh, well, something's better than nothing!
Change 09.061 Support for NetView Performance Monitor NPM 1.4.1 is
EX028INA added by this last-minute change (the product became
EX028INB available today, and I received the IBM documentation
EX028INC two days ago!) which has been syntax tested, but has
EX028IND not actually read any SMF records with the new data
EX028EV3 segments. Prior versions of MXG should not fail with
EX028EV4 the new records, but the SAS log will contain many
EX028EV5 MXG notes that unexpected subtypes 0B, 72-77x, 90-96x,
EX028NTN and FAx were found. Eight new NPM datasets are created,
VMAC28 but none of the existing data sets appeared to have been
Jun 27, 1991 changed after a brief review of the new documentation.
MXG documentation of the new datasets is in comments at
the beginning of member VMAC28. IBM's documentation is
on pages 285-411 of NPM Installation and Customization,
SH20-6361-5.
Change 09.060 This graphic analysis program failed if you specified
GRAFTRND SASGRAPH=NO and SASSTAT=YES. Line 038700 should be
Jun 27, 1991 DATA=PERCENTS instead of DATA=PRED1, and line 044800
should be DATA=TIMES instead of DATA=PRED1.
Thanks to Jim Ray, National Council on Compensation Insurance, USA.
Change 09.059 The two PROC SUMMARYs in this analysis of TMS catalog
ANALTMS5 records worked fine in small shops, but with a large
Jun 26, 1991 number of devices and volsers, they ran out of virtual
addressability (i.e., virtual memory), because a CLASS
statement was used. The CLASS statement needs storage
in virtual memory for every possible combination of the
class variables data values; it creates all possible
answers in virtual memory, and then decides how many of
the answers you really wanted. With three variables in
a CLASS statement, if each variable has 100,000 unique
values (e.g., a TMC catalog of 100,000 tapes VOLSERs),
there are 10**15 cells needed per statistic calculated!
One of the historic virtues of the SAS System, in my
opinion, was that by being what I called "data driven",
SAS could solve problems that broke the back of these
"memory driven" algorithms. As long as you could first
afford to PROC SORT your data, you could summarize and
analyze any number of groups with a PROC MEANS with a
BY statement. Being "data driven" is the solution to
this ANALTMS problem. By changing the "CLASS" to "BY"
following the two PROC SUMMARY statements you change the
architecture from "memory driven" to "data driven", and
the virtual memory is now independent of the number of
by groups in your data. Although the TMS.TMS dataset
was already built SORTed, so in general you do not need
an extra sort to summarize, I chose to ensure the sort
order by inserting PROC SORT before the PROC SUMMARY.
However, a PROC SORT was required for the second PROC
SUMMARY, but its input dataset was already a summarized
temporary data subset of the original TMS.TMS dataset.
Since PROC MEANS now actually invokes PROC SUMMARY, this
reminder is not about PROC SUMMARY itself, but rather it
contrasts the "in memory" CLASS statement algorithm to
the "data driven" BY statement implementation. For MXG
data, the BY statement implementation is recommended, as
we DO have many possible unique values, and being "data
driven" not only uses fewer CPU and I/O resources, but
of perhaps even greater importance, being "data driven"
means that your daily production reports use exactly
the same amount of virtual memory every day, and they
will not awake you at 3am because today's data happened
to have more unique values then your test job (you know,
the one you tested in a 4MB region yesterday afternoon!)
Change 09.058 The sample code in comments that could be used to build
RMFINTRV RMFINTRV directly from SMF records did not have the BY
Jun 26, 1991 list correct for TYPE70PR dataset, causing SAS to think
there were duplicate records. The BY list now matches
its BUILDPDB counterpart.
Thanks to Chuck Hopf, Primerica, USA.
Change 09.057 Semicolons were missing at the end of lines 032300 thru
VMACTMS5 032500 in VMACTMS5 and lines 019700 thru 019900 in
VMACTMS, after support for CA/1 Release 5 was added.
Jun 26, 1991
Thanks to Chuck Hopf, Primerica, USA.
Change 09.056 Support for the eleven subtypes of the NETVIEW FTP (file
EXFTP01X transfer program) User SMF record creates eleven FTP...
EXFTP02X MXG data sets, one per subtype, from FTP R1.0.
EXFTP03X The FTP support uses the new "subtype-level-processing"
EXFTP04X MXG architecture, which will be used for all future
EXFTP11X development, and eventually will be retrofitted into all
EXFTP12X of the existing products which create record subtypes.
EXFTP21X The specification and naming conventions of this new MXG
EXFTP22X architecture is presently contained in member VMACFTP,
EXFTP23X but these initial descriptions will be elaborated into
EXFTP24X a formal MXG architecture specification member later.
EXFTP25X "Subtype-level-processing" is completely compatible with
FORMATS the existing MXG "record-level-processing" architecture,
IMACFTP and most sites won't even notice the difference, but for
TESTUSER records with lots of subtypes, the change is required to
TYPEFTP maximize the flexibility and optimize the construction
VMACFTP of MXG programs in the future.
Jun 24, 1991 FTP just happened along at the right time!
Thanks to Stephen Bell, Bunchungszentrale der westfalisch, GERMANY.
Change 09.055 Another MXG error caused STOPOVER with MVS/ESA 4.2 type
VMAC78 78 subtype 3 records because line 171600 should have
Jun 23, 1991 been @; instead of just a semicolon. At the same time,
the ?? format modifier were added to the input for the
IODFDATE/IODFTIME variables to eliminate the INVALID
DATA messages. Mini-tutorial on SAS hex dumps:
The hex dump produced by this error was not for a type
78 record, but instead contained a type 74 record.
The PUT _ALL_ list of variable=value after the dump
showed the _N_ value of 4, but the number on the hex
dump CHAR line was 5! The _N_= value is the accurate
indicator, and shows when the error occurred, and only
if the _N_= value equals the hex dump's record number,
do you know the dumped record is the problem record.
Why did SAS dump the next record? I don't know why,
but for some logic errors, SAS reads into the next data
record before realizing it has switched records, and so
when it goes to dump the record currently in its buffer
it has already gone past the problem record.
Thanks to Tom Parker, Hogan Systems, USA.
Change 09.054 MXG 9.1 corrections for MVS/ESA 4.2 in Change 9.001 were
VMAC7072 inconsistent. Part b was in XMAC7072 but not VMAC7072,
XMAC74 and parts d and e were in VMAC74 but were incorrect in
Jun 23, 1991 XMAC74. Only MVS/ESA 4.2 records were affected.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Dan Barbatti, Southwestern Bell, USA.
Change 09.053 The PROC DATASETS DDNAME=VMXGVVDS ... should have been
ANALVVDS PROC DATASETS DDNAME=MXGVVDS
Jun 21, 1991
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 09.052 SAS 6.06 Usage Note 2066 discusses an unfixed error that
VMAC37 causes the SAS CHARCODE option (see SAS 6.06 Language
ANALDBTR guide page 741) to unexpectedly replace characters that
ANALPDSM are inside a comment block. In VMAC37, a ?- inside a
BUILDPDB comment block was replaced by an underscore, reducing
BUILDPD3 the source line by one byte, which moved the line number
TESTUSER from column 73 to column 72, causing a syntax error!
VMACACF2 MXG did not know of this vulnerability and just happened
VMACTEST to have the ?- in a comment. Nine other MXG members had
VMAC110 either ?- or ?) pairs in comments, and all have been now
VMXGHSM changed to avoid the exposure until 2066 is fixed,
Jun 19, 1991 although SAS option NOCHARCODE could probably been used.
Thanks to Willie Antman, Federal Deposit Insurance Corporation, USA.
Change 09.051 Shared Medical System's CICS application creates its own
IMACEXCL header segment with an unexpected MNSEGCL value, which
VMAC110 caused MXG to fail. These segments were detected and
Jun 19, 1991 skipped over with the first part of this change, but MXG
Jun 27, 1991 still failed with SMS CICS records, because they use the
CICS EXCLUDE option to exclude some fields from their
transaction record.
You can tell a region has EXCLUDEd fields if the value
of MCTSSDRN in the MXG error message is 60 or less;
a minimum of 61 fields are in non-EXCLUDEd CICS data.
The previous "support" in MXG for EXCLUDE/INCLUDE was
marginal at best, was not externalized, and actually
required you to create a modified copy of VMAC110!
Because MXG promised to fix every Error condition, the
second part of this change completely redesigned the MXG
support for CICS EXCLUDEd fields, and now provides an
externalized tailoring member, IMACEXCL, that permits
processing a multiplicity of different CICS regions that
can even have different EXCLUDEs. IMACEXCL not only is
the documentation for this MXG support, it also contains
the code to read the SMS transaction records and shows
how changing only one line in your IMACEXCL will enable
SMS record processing for two specific APPLIDs.
Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.
Thanks to Tim Cartwright, University of Wisconsin - Madison, USA.
Change 09.050 WEEKBLD job failed when automatically submitted by a job
Submitting but ran without error when submitted from TSO. Adding
Jun 19, 1991 DCB=(RECFM=FB,LRECL=80,BLKSIZE=8000) to the DDNAME in
the submitting job that points to the INTRDR solved the
problem. Without that DCB, the SYSIN dataset that SAS
tried to read had VBA or VS attributes, and SAS failed
with "Undetermined I/O Failure". By the way, that I/O
error from SAS always means the error is in a "flat"
file (SYSIN, or INCLUDEd, or FILE/INFILE), and is not
related to I/O to/from a SAS data library.
Change 09.049 Execution of MXG 8.8 under SAS 6.06 under MVS/370 (i.e.,
SAS 6.06 pre-MVS/XA) is possible for BUILDPDB, but testing and
Jun 19, 1991 validation is still on-going. This note identifies the
current recommendations for SAS 6.06 under MVS/370.
-Use maximum REGION size you can possibly get.
-Specify OPTIONS BLKSIZE=1024 BUFNO=1; to minimize the
virtual storage (but at the cost of additional I/O and
CPU time).
-Change CONFIG member to specify MEMSIZE=6M (because SAS
will try to get more, even when it doesn't exist on your
370 system).
-Add SAS option MINSTG to the CONFIG member (to free up
storage after each PROC/DATA step).
-Let me know if it works. Last site testing got through
to building the SPUNJOBS before memory failure, and has
not yet reported if MINSTG solved their problem.
Thanks to Moji Varian, Congressional Information Services, USA.
Change 09.048 The MXG circumvention for IBM's DFP type 42 records in
VMAC42 Change 9.024 protected the STOPOVER condition, but the
Jun 19, 1991 MXG test for wrong record length was invoked first, and
the bad records were thrown away instead of processed
(after a message was printed on your log, however).
This enhancement protects the STOPOVER and prevents the
MXG message on the log. In addition, the PIB8. fields
in the subtype 1 (written only if you have PDSE enabled)
are now input as ?? 8. instead of PIB8. There is still
a long series of questions at IBM DFP, because some of
the statistics (but not all) appear to be accumulated
across records, and the "Current" time stamp is several
minutes earlier than the SMF timestamp. Two APARs now
exist for the type 42, OY39393 and OY44995, and when
PTFs exist, they should be installed.
Thanks to Joe Faska, Depository Trust, USA
Change 09.047 TYPE78CU IO Queuing data will be missing if microcode
VMAC78 level CP HH0124 has been installed. The fix to IBM's
Jun 19, 1991 firmware is microcode level CP HH0130.
Thanks to Miller Dixon, Continuum, USA.
Change 09.046 TYPE6156 variable ACTION is not consistent with the type
VMAC6156 of function creating the respective record, according to
Jun 19, 1991 IBM APAR OZ82412 (1985!). MXG variable ACTION decodes
SMF6xSUB into INsert, DElete, or UPdate, but the APAR
says the field is valid only in the type 60 VVDS record
and is invalid in type 61, 65, or 66 records. Sister
APAR OZ82414 also claims that SMF6xFNC and SMF6xTYP are
equally invalid (which MXG decodes into FUNCTION and
ENTTYPID respectively). In MVS/ESA 4.2 SMF manual, the
SMF6xFNC is now a reserved field, but both SMF6xSUB and
SMF6xTYP are still documented. Your guess is as good as
mine, but beware!
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 09.045 NETSPY accounting record offset cause INPUT STATEMENT
VMACNSPY EXCEEDED RECORD LENGTH STOPOVER error. Change the line:
Jun 10, 1991 @OFFNSPY+OFFSMF+169 to read @OFFNSPY+OFFSMF+168
Thanks to Doug Drain, National City Bank, USA.
Change 09.044 An interesting change in Connect Time ("IOTM") measures
IOTM was observed in GTF traces. The instance was 4K I/O, and
Jun 8, 1991 the normal connect of 2ms per I/O was observed most of
the time, but occasionally the connect time was 18ms!
The device was a 3390 DASD behind a Model 2 3990 (i.e.,
non-cached CU). The additional connect time was traced
to a change in IBM's handling of missed RPS reconnects.
Previously, IBM would simply try, and try, and try again
to reconnect, recording 16ms (one revolution) disconnect
time for each miss. IBM has apparently implemented the
same scheme that other vendors use to limit reconnects:
after some number of misses (perhaps 2?), IBM now tries
continually to reconnect, and when it is finally able to
connect to the channel, it now SEARCHes to find the
desired sector and record. SEARCH, of course, records
not disconnect time, but now records connect time, for
the device in type 74 and for the job in type 30. In
principle this is probably good, since it limits how
long your I/O can sit waiting for reconnect, but it
could lead to problems in repeatability of connect time
for I/O measurement and accounting, because now the
connect time is a function of channel and path conflicts
rather than just the amount of I/O transferred. Since
multiple paths are typically available to devices, there
is much less probability of RPS misses now than in the
past, and the variability in connect time will not be a
significant factor in the absence of RPS misses.
Thanks to Bill Fairchild, Landmark, USA.
Change 09.043 The link edit step in ASMVTOC specifies AC=1, but later
ASMVTOC comments in the program state that authorization is NOT
Jun 8, 1991 required. The comments are correct, and the AC=1 has
been removed from the LKED step.
Thanks to David Ehresman, University of Louisville, USA.
Change 09.042 SAS 6.06 and MXG JCLTEST6 will fail in REGION=2048K with
JCLTEST "OPEN ABORTED FOR SOURCLIB, NO MEMORY FOR DATA BUFFERS".
JCLTEST6 The REGION=4096K is required, but MXG JCL comments were
Jun 8, 1991 incorrect and implied 2048K was enough. It isn't.
Thanks to David Ehresman, University of Louisville, USA.
Change 09.041 Sites with TLMS may encounter 713-04 ABENDS when putting
TLMS SAS datasets on tape, if the TLMS installation Option
Jun 8, 1991 named DBLTIME is set to 0! If DBLTIME=0, TLMS does not
Feb 25, 2006 permit "double opens", but when you build your PDB on
tape, SAS opens and closes each SAS dataset, which OS
sees as multiple opens, and TLMS inhibits. You can set
DBLTIME=1 and TLMS will let the same jobname open the
same tape data set multiple times, as long as the time
between is less than one hour (DBLTIME=2 give 2 hours!).
Unfortunately, DBLTIME is an installation-wide option.
Feb 25, 2006: Using DISP=(MOD,CATLG) instead of using
DISP=(NEW,CATLG) eliminated the ABEND!!!
Thanks to Nancy Vance, ???.
Thanks to Terry Poole, SAS Institute Cary, USA.
Thanks to Carol Arnold, BBH, USA.
Change 09.040 Reading VTOC records created by ASMVTOC with VMXGVTOF,
VMXGVTOF even after Change 9.035 (MXG 9.1), was still incorrect.
Jun 7, 1991 The logic of VMXGVTOC was not properly migrated into
VMXGVTOF, and the first extent on each volume was lost.
You might not have noticed the loss, if the first extent
was free space, but if the first extent was a real
dataset, the entire dataset record could have been lost.
The simple fix is to change VMXGVTOF as follows:
was: must be:
SET EXTENTS END=EOF; SET TOTRACKS EXTENTS END=EOF;
Thanks to Roger Edwards, South Carolina Electric & Gas, USA.
Change 09.039 MVS/ESA 4.2 was still not fully validated, even in 9.1.
VMAC74 Yet another error slipped thru, causing STOPOVER on type
XMAC74 74 subtype 2 RMF records:
Jun 7, 1991 -Find the following statement and changes as shown:
was must be
R742STCN $CHAR4. R742STCN $CHAR8.
-There are three lines containing SKIP=OFFDDSS that must
be changed as follows:
was must be
SKIP=OFFDDSS-52; SKIP=LENDDSS-56;
SKIP=OFFDDSS-72; SKIP=LEN742PO-72;
SKIP=OFFDDSS-44; SKIP=LEN742MO-44;
Thanks to Tom Elbert, John Alden Life Ins, USA.
Thanks to Dan Barbatti, Southwestern Bell, USA.
----Changes thru 9.038 were included in MXG 9.1 dated June 3, 1991------
Change 09.038 Support for Boole and Babbage's CONTROL-D SMF record
ANALCTLD is added by this user contribution. Release 1.6.4 has
EXTYCTLD been processed with this data, which creates the
IMACCTLD CONTROLD data set. Member ANALCTLD provides examples
TYPECTLD of potential reports.
VMACCTLD
Jun 3, 1991
Thanks to Brian Cobb, Credit General Industriel, FRANCE.
Change 09.037 Variable FCOTHCN was not kept in CICSTRAN dataset, for
VMAC110 no good reason, but now it is!
Jun 3, 1991
Thanks to Herr Weismann, Zurich Versicherung Frankfurt, GERMANY.
Change 09.036 Variable APPLID in NSPYVIRT was not kept, causing later
VMACNSPY report programs to fail. Add APPLID to KEEP= list.
Jun 3, 1991
Thanks to Chris Morgan, Post Office (UK), ENGLAND.
Change 09.035 A SAS 5.18-only problem caused when SYMPUT references an
VMXGVTOF unreferenced variable caused VMXGVTOF to not process all
Jun 3, 1991 extents. The MXG circumvention is to insert the line
LENGTH NOBS 4; ahead of the CALL SYMPUT line,
which satisfies the 5.18 compiler and makes the %DO loop
iterate. In addition, there was a redundant PROC SORT
of the EXTENDS data set preceding the %DO which did no
harm, but did no good, and which has been removed. This
was a combined discovery of several SAS folks:
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to Jan van Lent, SAS Institute, NETHERLANDS.
Thanks to Waldemar Schneider, SAS Institute Europe, GERMANY.
Change 09.034 Two exits enhance BUILDPDB tailoring so that changes to
BUILDPDB are externalized for sophisticated users. Exit
BUILDPD3 EXPDB304 is taken so TYPE30_4 step variables can be
EXPDB304 changed/added into PDB.STEPS or summed into PDB.JOBS.
EXPDB6 is taken so TYPE6 print variables can be changed
May 31, 1991 into PDB.PRINT or summed into PDB.JOBS. Comments in the
exit member describe how it can be used. Complete tests
have not been completed; use with caution until this
note is replaced with validation results. At worst, you
may have to modify SPUNJOBS if you use these exits!
Thanks to Jane Graffum, Blue Cross Blue Shield of Massachussets, USA.
Change 09.033 Invalid NETSPY records are now protected from STOPOVER
VMACNSPY by comparing the expected length ENDREC to LENGTH and
May 31, 1991 deleting bad records. LEGENT is investigating the data
(NSPYREC='C' with ENTL=288 and ENTN=216-->62208 bytes
in a record only 21,000 bytes long)!
Thanks to Wilson Wong, Salomon Technology Services, USA.
Change 09.032 DB2 Audit Reports (PMAUD01, PMAUD02, or PMAUD03 were not
ANALDB2R produced if PDB=SMF was specified on %ANALDB2R. These
May 31, 1991 reports ARE produced if instead you use TYPEDB2/TYPE102
to build the datasets first, and then invoke ANALDB2R
with the PDB=PDB option to generate the Audit reports.
The PDB=SMF problem can be corrected by inserting:
AND &PMAUD01 EQ NO
AND &PMAUD02 EQ NO
AND &PMAUD03 EQ NO
two lines prior to each of the following lines:
MACRO _DB2AC1 MACRO _DB2AC2
MACRO _DB2AC3 MACRO _DB2AC4
MACRO _DB2AC5 MACRO _DB2AC6
MACRO _DB2AC7 MACRO _DB2AC9
MACRO _DB2TC2 MACRO _DB2TC10
(The omission of these three lines testing if you had
requested an Audit report caused the PDB=SMF option to
generate the above Macro line, thereby causing MXG to
create 0 observations in the datasets needed by the
audit report.
Change 09.031 The example JCLDASD had incorrect DDNAMEs, and ANALVVDS
ANALVVDS had conflicting DDNAMEs.
JCLDASD -In ANALVVDS both occurrences of PERM should be MXGVVDS,
May 31, 1991 and the OPTIONS statement was deleted (it did not cause
a real problem, but it did not belong there, since it
would prevent you from controlling options externally).
-In JCLDASD step VTOC:
Comment preceding step VTOC should state
DDNAMES DISK AND MXGDASD ARE REQUIRED
MXGDASD should replace PERM as the DDNAME for the SAS
data set to be built,
DISK should replace MXGDASD as the DDNAME for the
*.ASMVTOC.VTOCDUMP dataset, and
-In JCLDASD step VVDS:
Comment preceding step VVDS should state
DDNAMES SMF AND MXGVVDS ARE REQUIRED
Change 09.030 DB2 Reports have several values that are incorrect by a
ANALDB2R factor of two. The error only affects these variables:
May 31, 1991 QB1TCBA QB2TCBA QB3TCBA QB4TCBA QISEPAGE QISECT
QISEFREE QISEDBD QISESKCT
The correction (fortunately) is simple. Delete all
15 occurrences of 2* in member ANALDB2R! I am really
embarrassed by this error due to incorrect testing.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 09.029 The MXG PDS Printing utility ALWAYS printed the SOURCLIB
VMXGPPDS PDS because "PROC SOURCE INDD=&PDSIN ..." should have
May 31, 1991 been used instead of INDD=SOURCLIB!
Change 09.028 Preliminary trend data base support for VMXAINTV dataset
TRNDVMXA has been added. Note that the trending supports only a
May 31, 1991 single VM/XA system. If you have multiple VM/XA systems
they must be separately processed and trended; I am open
to suggestions for the creation of a "SYSTEM" variable
that would allow separate VMXAINTV datasets to be added
to a common VM/XA trend data base. The TRNDVMXA member
existed in MXG 8.9, but had warnings not to use, because
of Variable Not Found messages. If you remove variables
PFXIDSER and PFXIDMDL from the SUMBY= statement in 8.9,
you will then have the MXG 9.1 version of TRNDVMXA!
Change 09.027 Complete online documentation of MXG datasets has begun!
ADOCACHE I plan to provide "Chapter FORTY" style documentation of
May 31, 1991 each data source that MXG supports and each dataset that
MXG builds, as members of the MXG library, so that they
can be viewed and searched online with your text editor.
Since most data sources have a VMACxxxx member that is
the actual processing code, I have decided on the naming
convention that VMACxxxx member's data will be described
in member named VDOCxxxx. A completed VDOCxxxx member
will contain these sections:
a. Data source description. Who, what, when, writes
the raw data records, vendor, releases supported
by which version of MXG, etc. How to process this
data source with MXG (members, IMACs, etc.).
b. MXG Data Set Documentation. For each MXG data set
built, there will be these sections:
1. Description of data set itself, usage, etc.
2. Alphabetic description in detail of every MXG
variable, including usage notes, caveats, etc.
3. Clustering of similar variables.
4. PROC PRINT with variable name of sample data.
5. PROC PRINT SPLIT='*' with label of sample data.
6. PROC MEANS of sample data.
The member VDOCACHE is incomplete, but contains CACHE90
sections b.2, b.4, b.5, and b.6 for starters.
This work will extend over time. Initial estimates of
the number of pages for MXG's 900 datasets and 36,000
variables are from 8 to 13 800-page volumes! How much
will actually be printed, in what form, when will it be
completed, etc., are still under consideration. However,
as individual VDOC.... information is completed, it will
be added to the MXG SOURCLIB (even if not finished) so
the information will always be available online.
Change 09.026 Changes in 8.293 to CACHE90 dataset in VMACACHE have now
XMACACHE been implemented in XMACACHE, the SAS 5.18 member used
May 31, 1991 to circumvent the 344 compiler error.
Change 09.025 TPX variable TPXELAP should have been INPUT as PIB4.2
VMACTPX instead of PIB4.
May 31, 1991
Thanks to Seymour J. Metz, EDS, USA.
Change 09.024 Type 42 subtype 2 SMF records (DFP 3990 SMS cache stats)
VMAC42 are invalid until module IGDDCFSR is at OY39393. The
May 30, 1991 APAR OY39393 which fixed the subtype 3 record last year
didn't get on subtype 2! Without OY39393, the CU and VOL
segments are both mis-located by their offset triplets,
and the final VOL segment is actually truncated by two
bytes). This change enhances MXG to detect and process
both corrected and incorrect format records; since the
truncated bytes happen to be reserved it could be done!
You should still install OY39393 in case IBM makes any
other change to the DFP record. But there's more. In
every other relocatable SMF record, the length triplet
value is the length of a single segment, but the DFP
developers decided to be different and store the total
length of all VOL segments in SMF42VLL (and not only do
they claim there is no standard and that the format of
the length field is up to the creator, they haven't even
said they will issue a document APAR telling you!). MXG
corrects the length value in processing. And then there
are the LTM and CTM time stamps that don't contain the
HHMMSSTH that is documented, but instead contain the
seconds since midnight! And finally, the LYY and CYY
year values contain x'005B' = decimal 91 now, but do not
document what will happen in 2000 - is the format really
0cyy where c is the century bit and the 2000 will be the
x'0100', or is the format the number of years since 1900
so that the 2000 year value will be x'0064'? I have put
code in place that assumes the century bit format, but
am checking with IBM for the actual format.
Thanks to Joe Faska, Depository Trust, USA.
Change 09.023 EXD Release 3.0 added EXDRTECD (EXD/SAR Route COde) to
IMACEXD the additional EXD variables in the type 6 record, and
May 30, 1991 now MXG creates that variable if optional EXD support
is enabled in member IMACEXD. I failed to note which
bright MXG user notified me of this omission.
Change 09.022 SAS 6.06 option VERSIONLONG was added to MXG's list of
CONFIG default options, so that SAS will print the date of the
May 30, 1991 maintenance library on your log (6.06.01.01Feb91P).
Change 09.021 Support for CADAM, Inc.'s Statistics Data File, written
TYPECADM to their DDNAME STATSEQ, provides response averages and
VMACCADM counts of function key activity for CADAM end users. The
May 30, 1991 vendor's documentation warns that the data structures
are not supported by CADAM as user-accessible data and
are subject to change without notice (but the document
is dated 1988 and MXG has decoded data from the current
CADAM version 20.12). Function key use is recorded in 32
function key slots (but note that many CADAM products
(AEC, 3D) use multiple function key tables, redefining
the slots each time, and these re-uses are NOT reflected
in the function key slots.) For each function key slot,
CADAM records the number of uses, the total service time
and the sum-of-squares service times; MXG converts the
total service time to the average service time for each
function key slot. Additionally, CADAM captures the
arrival, service, and response time statistics (average,
minimum, maximum, and distributions of these three "wall
clock" durations in 44 buckets from .01 to 120 seconds.
Service is the duration from when CADAM selects an
attention to process to the point that the operating
system has reported that the display has been updated.
Response time adds to the service time the additional
duration that an attention waits to be selected for
processing (i.e., response is from arrival of an
attention to when the display is updated after
processing the attention).
Arrival time is the interval between the arrival of
attentions at the scope. Since attentions may be
"stacked" this value forms a measure of the "human
factor" in scope usage. Arrival times significantly
lower than response times imply that scope operators
are "getting ahead of the system," and that system
performance is poor.
Thanks to Emery Johnson, Allied Automotive Data Center, USA.
Change 09.020 Support for Interlink's products (used to interchange
EXILKA20 data between IBM, DEC, Internet, etc. platforms) has
EXILKA21 been added. The products each create user SMF records
EXILKGAB which are processed into multiple MXG datasets:
EXILKGAC
EXILKGCO Product MXG Acronym Datasets Created
EXILKGDI
EXILKGRE SNS/TCPaccess ILKA ILKAST20
EXILKVCO ILKAST21
EXILKVDI
EXILKVOF SNS/SNA Gateway ILKG ILKGABRT
EXILKVON ILKGACPT
EXILKVSR ILKGCONN
EXILKVST ILKGDISC
IMACAAAA ILKGREJC
IMACILKA
IMACILKG SNS/TCPvt ILKV ILKVCONN
IMACILKV ILKVDISC
TESTUSER ILKVLOGF
TYPEILKA ILKVLOGN
TYPEILKG ILKVSTOP
TYPEILKV ILKVSTRT
VMACILKA
VMACILKG
VMACILKV
May 29, 1991
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 09.019 The CICS Dictionary Printing Utility added support for
UTILCICS CICS 3.1 dictonary, but failed to sort the data before
May 27, 1991 the PROC PRINT DATA=CICSDI31, causing "INPUT DATASET NOT
IN PROPER SORT SEQUENCE." Insert before the PROC PRINT,
PROC SORT DATA=CICSDI31 ;
BY SMFPSRVR APPLID NREC MNSEGCL MCTSSDID;
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 09.018 This significant user contribution supports SMF user
EXTYTAO records created by Fischer International's TAO (Totally
IMACTAO Automated Office) Electronic Mail System Release 3.2.1
TYPETAO at product maintenance level #82 and up. Earlier
VMACTAO releases are not supported as the vendor had previously
May 15, 1991 used a non-SMF type of recording for statistics from the
EMC2 Electronic Mail System which predates TAO.
Although not as widely used as some EMAIL systems, TAO
is a stand-alone MVS/VTAM application. AMDAHL uses the
TAO system extensively for electronic mail worldwide.
Some problems were encountered processing release 3.2.1
records due to errors in the vendors distribution
packaging. It seems that the documentation which
describes the dsects had been updated along with the
source dsects, however, the load modules were assembled
using earlier versions of the dsects. Assembly was a
problem due to user defined macros which the vendor had
not distributed in source form. These problems were
easily cleared up with a phone call to the vendor, but
some shops may encounter similar difficulties in
attempting to read the TAO generated SMF records using
this code. Several fields have been included in the MXG
code which are not yet supported (or populated) by the
vendor, although they are contained in the dsect areas
and the vendors comments supply documentation of the
future contents of these fields (at least in part).
This is NOT a complete subsystem for processing TAO SMF
records, retaining and summarizing detail data, and
producing reports. It IS a start for people (like me)
who hate using ALC dsects in SAS code.
Thanks to Joe Aldrich, Army and Air Force Exchange Service, USA.
Change 09.017 The use of IMACKEEP to drop variables in MXG datasets is
IMACKEEP vulnerable to error. If a new dataset is created by the
May 15, 1991 new version of MXG (for example, new TYPE74.. datasets to
Jul 23, 1991 support MVS/ESA 4.1), and if you don't retrofit your
changes in IMACKEEP, you will fail with a SAS Error 311,
because your redefinition in IMACKEEP won't contain the
name of the new datasets. It appears there is a better
way to drop unwanted variables from MXG datasets without
using IMACKEEP. You can simply use a DROP statement in
the EXTY.... member to drop unwanted variables. Even
those variable names are still in the KEEP= option of the
DATA statement in the _VAR macro definition, the DROP
statement overrides the KEEP= option and the unwanted
variables will be dropped. Using the EXit member to drop
variables should be less vulnerable to change, and will
eliminate the use of IMACKEEP except in cases where you
want to ADD a new variable to an MXG dataset. A caution;
you cannot drop a variable which is later used in a BY
statement.the DATA step, as one user found when he tried
to drop MVS/370 variable LCHAN using EXTY74. The drop
statement removed LCHAN from not only TYPE74 but also the
TYPE73P dataset, which is later sorted from work to the
PDB with LCHAN in its BY statement. This cause an error!
However, ain't nothin' straightforward. If you should
use a DROP statement in the EXIT member, and if that
variable should ever disappear from MXG, you will THEN
fail with a "Variable in drop list never referenced"
error! Normally this won't happen in MXG code, but
(for example), if you had used the XMAC7... members to
circumvent of the SAS (Version 5 only) 344 compiler
error, MVS/370-only variables do not exist in the XMACx
and your DROP statement in EXTY74 would fail.
But you can be even smarter than SAS. If you add a
"MXG Compiler Faker" statement for each variable to
be dropped ahead of your DROP statement, the compiler
will be faked out whether the variable exists or not,
the variable will be dropped, and you code will be
invulnerable to future MXG changes! What is this MXG
"Faker" statement? Simply for numeric variables it's:
IF N=. THEN N=.;
and for a character variable C, you must have as many
blanks between the quotes as is the length of the
character variable:
IF C=' ' THEN C=' ';
Change 09.016 Support for Computer Associates CA-1 (TMS) Release 5 has
TYPETMS completely changed the format of the TMC records, but as
TYPETMS5 there is no product release number in the TMC, MXG had to
create completely separate, but parallel members to read
VMACTMS5 the new TMC to create MXG data set TMS.TMS. A few new
May 15, 1991 variables do exist (see DOCVER09), but all of the prior
variables still exist (except for the obscure variables
READERR, WRITERR, which were replaced by 8 separate error
values). The value of variable DEVTYPE was changed so it
doesn't waste so much space; the "EIGHTEEN-TRACK" and the
"NINE-TRACK" values were replaced by "9TRK", "18TRK", and
new value "36TRK" (for the 3490-E Serpentine technology)
was added for DEVTYPE. For 3480s ("18TRK"), the IDRC
compaction status is decoded into MXG variable DEN, which
will have the value 38000 for non-IDRC 3480 tapes, and
which is set to 76000 by MXG to indicate IDRC compacted
3480 tapes. Members TYPETMS/VMACTMS must be used for
CA-1 Releases earlier than Release 5, and MXG members
TYPETMS5/VMACTMS5 must be used for Release 5.
Thanks to Debora Reinert, Nordstrom, USA.
Change 09.015 Landmark TMON/CICS Version 8 history file contains a data
TYPEMON8 dictionary record with TMMDREC='DD' which causes MXG to
May 14, 1991 fail because this record was not expected, and should be
deleted. Change lines 065900 to 0660 to now read:
TMMDREC $CHAR2. 065900
@; 065910
IF TMMDREC='DD' THEN DELETE; 065920
INPUT TMMDFLG1 $CHAR1. 066000
Thanks to David A. Faught, FCC National Bank, USA.
Change 09.014 The DROP=_FREQ statement in IMACPDB was supposed to have
IMACPDB been DROP=_FREQ_ (with underscore on both sides), so that
May 13, 1991 the _FREQ_ variable created (only in SAS 6.06+, when PROC
MEANS was replaced by PROC SUMMARY) would be dropped. The
"misspelling" caused _FREQ_ to exist in both PDB.JOBS and
PDB.SPUNJOBS.
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.013 New PDB.SPUNJOBS dataset variables INITTIME/JINITIME were
SPUNJOBS not kept as 8-bytes (which caused their value to be
May 13, 1991 truncated by up to 255 seconds) and were not formatted.
Both are now explicitly in the LENGTH statement and a new
FORMAT statement was added.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.012 Trending of TMON/CICS dataset MONIDBDS built from TMON
ASUMDBDS Release 7 data (i.e., using MXG member TYPEMONI) will
TESTOTHR cause ASUMDBDS to fail with variable APPLID not found, as
May 13, 1991 APPLID did not exist in TMON Release 7. Adding after the
INCODE= operand:
IF APPLID=' THEN APPLID=' ';
will protect ASUMDBDS for either TMON Release 7 or 8.
(This error was not detected because MXG's TESTOTHR step
of JCLTEST had member TYPEMON8 included after TYPEMONI
and then ASUMDBDS was included, masking the error. Now,
ASUMDBDS (and ASUMCICS) are invoked after TYPEMONI, and
then again invoked after TYPEMON8. Note that there is
no way to actually test TMON/CICS with step TESTOTHR and
actual data records; the single MONICICS DDNAME is used
for both TYPEMONI and TYPEMON8, and thus with real data,
one or the other will fail in step TESTOTHR. To really
test TMON/CICS data with MXG, use a separate job with
only the appropriate TYPEMONx member.)
Thanks to William Padilla, Farmers Insurance Group, USA.
Change 09.011 Landmark's TMON/CICS Release 9.0 records will have to be
TYPEMON8 converted to Release 8.1 format for processing by MXG's
May 13, 1991 TYPEMON8 member; Landmark does not intend to make the 9.0
formats available. But TMON/CICS 9.1 will be available
late 1991 or early 1992, and will have significant change
in its records that will be made available and thus 9.1
records will be supported by MXG natively late this year.
Change 09.010 TYPE57 data produced MXG message "INVALID ESS SECTION'
VMAC57 and the record was skipped because IBM documented the LEN
May 13, 1991 and NR of ESS sections as 4 bytes when in fact they are
only two bytes. Lines 010100 and 010200 (where LENESS &
NRESS are INPUTed) should be PIB2. instead of PIB4.
Thanks to David A. Faught, FCC National Bank, USA.
Change 09.009 Processing HSM MCD, etc. data sets may cause STOPOVER,
VMXGHSM may print INVALID DATA messages if HSM dates are nulls,
May 13, 1991 may print INVALID ARGUMENT messages because DATEJUL()
were not protected, misspelled TTOCTYP with an E, and
did not input TTOCALT, the Alternate VOLSER. The STOPOVER
was corrected by moving the two tests for 'junk" records
(SUBSTR(MCDDSN) containing '99999') to immediately after
the variable MCDDSN was input (by breaking the input
statement at that point with @;). The INVALID DATA was
eliminated by preceding all PDB4. formats with the ??
format modifier, and the INVALID ARGUMENT was eliminated
by replacing all DATEJUL(x) functions with:
IF x GT 0 THEN x=DATEJUL(x);
ELSE x=.;
The occurrence of TTOCTYPE was respelled TTOCTYP, and was
formatted $HEX2. instead of HEX2., and the preceding
TTOCKEY variable was now formatted HEX2. Finally, at the
end of the TTOC section, new variable TTOCALT $CHAR6. is
now input, labeled 'VOLSER OF ALTERNATE VOLUME' and kept.
Thanks to Tim Noone, American United Life Insurance Company, USA.
Thanks to Joe Ellis, Shelby Insurance, USA.
Change 09.008 SAS 5.18 344 Compiler Limit circumvention member VMAC110M
CICINTRV (that was added by Change 8.065 to reduce Iterative DOs)
VMAC110M fails with BUILDPDB because after VMAC110M was tested,
May 9, 1991 member CICINTRV was added to BUILDPDB, but VMAC110M does
not create the datasets required by CICINTRV. Since the
purpose of VMAC110M was to suppress CICS/ESA Statistics
processing, and since CICINTRV processes only CICS/ESA
Statistics data sets, the easiest circumvention that lets
you use VMAC110M (by copying and renaming it to VMAC110
in your USERID.SOURCLIB) is to also create a member named
CICINTRV in your USERID.SOURCLIB that contains a blank
line. This will possibly circumvent the 344 error and
will definitely eliminate the "Data Set Not Found" caused
by VMAC110M. However, just to be really robust, the
member VMAC110M was corrected by this change, and now it
does create the CICS/ESA statistics datasets (with zero
observations, and with only the seven variables needed by
CICINTRV) so if a future user does not see this change,
and uses only VMAC110M, he/she won't be burned!
Thanks to John Hassman, Texas Education Agency, USA.
Change 09.007 Applies only to MXG 8.9. Change 8.304 added retrograde
VMAC79 support for RMF 3.5.1 type 79 records, but I miss-typed
May 9, 1991 two lines. In line 037900, R792ARS should be PIB2. vice
PIB4., and in line 039630, R792TWSS should be PIB2. vice
PIB4. Without this change, RMF 3.5.1 records STOPOVERed.
Thanks to Gordon Keehn, Fidelity Mutual Life Insurance Company, USA.
Change 09.006 Minor documentation. Member IMACAAAA failed to list the
IMACAAAA IMACCMF member (Boole's CMF SMF Record ID) in its index,
IMACCMF and member IMAC370 was deleted, as it was not referenced
IMAC370 and should have been deleted during testing; it was going
May 8, 1991 to contain MVS/370-only-RMF processing but was discarded
as a bad idea. It serves no purpose.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 09.005 Minor, unless you tried to build your PDB on tape! The
IMACCICS new SPUNJOBS logic added in MXG 8.8 tried to read the
SPUNJOBS PDB.SPIN26 at the same time it was writing PDB.SPUNJOBS
May 8, 1991 which can't be done if your PDB DD points to tape! Note
that if you really want your PDB on tape you must not
only correct this design error in SPUNJOBS, but you must
also change the default PDB values in member IMACCICS to
WORK, and (if you actually have CICS data) use EXPDBOUT
to then PROC COPY IN=WORK OUT=PDB; SELECT CIC:; as is
now described in comments in IMACCICS. To fix SPUNJOBS,
insert: DATA SPJB26; SET PDB.SPIN26; immediately before
the line containing DATA PDB.SPUNJOBS; and in the
following MERGE statement change PDB.SPIN26 to SPJB26 so
that only one PDB dataset is open at a time. Also,
PROC DATASETS NOLIST;
DELETE SPJB30_1 SPJB30_4 SPJB30_5 SPJB26;
was added at the end of the member. It was also realized
that SPIN6 processing is not currently in SPUNJOBS, and
that will be corrected in another change.
Thanks to Tim Hill, Pacific Bell, USA.
Change 09.004 Minor. Lines 011900 and 012000 both contained */ after
DIFFHSM the semicolon, which should have raised a syntax error,
May 8, 1991 but didn't. Instead, variable DSRNTRKW was never DIF()d!
Thanks to Joanne Turpie, New Zealand Dept. of Labour, NEW ZEALAND.
Change 09.003 Minor. The last occurrence of variable OTHRACTV (in the
TRNDRMFI NORM1= list) should have been OTH0ACTV.
May 6, 1991
Change 09.002 This change is cosmetic, but should be noted. The 3490E
VMACUCB cartridge tape (serpentine, bi-directional) device has a
May 6, 1991 DEVTYPE of 81x, which was formerly assigned to the 9348.
MXG will now report 3490E instead of 9348. Note that the
3490 (non-E variety) cannot be differentiated from 3480s.
And of course 3480s with and without IDRC (compression)
are not identified at the device level. And what's going
to be real fun is trying to figure out what kind of tape
you hold in your hand; all three used identical media
cartridges, but are incompatible; 3490E cannot be read
by 3490/3480/3480-IDRC, and 3490/3480IDRC cannot be read
on 3480. Note MXG shipments are 3480-non-IDRC!
Thanks to Jay Arbabha, Principal Mutual Life Insurance Company, USA.
Change 09.001 MVS/ESA 4.2 data records finally arrived and demonstrate
VMAC30 that it is risky to distribute software that has not been
VMAC7072 tested with actual data records. On the other hand, if
VMAC73 I had waited for the data, you would still be waiting for
VMAC74 the software! These errors ONLY happen with MVS/ESA 4.2
XMAC30 data records, and only one causes an actual error.
XMAC7072 a.In VMAC30, find the line containing
XMAC73 @109+OFFSMF SMF30ASO +8 /*RESERVED*/
XMAC74 and change it to read:
May 6, 1991 @109+OFFSMF +8 /*RESERVED-SMF30ASO*/
This was a soft error, only causing your log to be filled
with "INVALID DATA FOR SMF30ASO" messages and a hex dump.
(If it's not clear, SAS was trying to input SMF30ASO as
an EBCDIC numeric field because there was no format item
following the variable name in the input statement. What
was desired was to skip over 8 bytes, and note that this
reserved field was called SMF30ASO by IBM.)
b.VMAC7072 causes "INVALID DATA FOR IOCRFC/CPURFC" messages
because these two fields no longer exist in 4.2, and the
fields now contain hex zeros instead of EBCDIC zeros!
Find the lines containing
@OFFWRKC+14 IOCRFC 3.
@OFFWRKC+17 CPURFC 3.
and add ?? format modifier between the variable and its
format:
@OFFWRKC+14 IOCRFC ?? 3.
@OFFWRKC+17 CPURFC ?? 3.
The ?? format modifier suppresses the hex dump and the
message, and sets the variable's value to missing.
This is a soft error.
c.VMAC73 causes "INVALID DATA FOR IODFDATE" messages.
Find the lines containing
IODFDATE YYMMDD8.
IODFTIME TIME8.
and add ?? format modifier between the variable and its
format:
IODFDATE ?? YYMMDD8.
IODFTIME ?? TIME8.
because not all records contain this new date/time data.
This is a soft error.
d.VMAC74 also causes "INVALID DATA FOR IOFDATE" messages
for the same reason as the VMAC73. Apply the fix above
for IOFDATE (paragraph c) to the VMAC74 member.
e.VMAC74 causes a STOPOVER condition. This is not soft!!!
Find the three lines reading:
DLYDIRTM PIB4.6
@;
SKIP=SKIP-20;
and change them to read:
DLYDIRTM PIB4.6
DEVDYNCH $CHAR1.
+3
@;
SKIP=SKIP-24;
These extra four bytes were added by IBM, and were added
in the SMF manual, and were even vertically barred, but
I simply missed them. Sorry for the inconvenience.
The actual change in MXG VMAC74/XMAC74 9.2 and later is
more extensive that this "quick fix" printed changed.
Thanks to Diane Eppestine, Southwestern Bell, USA.
LASTCHANGE: Version 9
=========================member=CHANGE08================================
/* COPYRIGHT (C) 1984,1991 MERRILL CONSULTANTS DALLAS TEXAS USA */
I. This is the Production Version MXG 8.9, dated May 1, 1991.
All Changes listed in this member have been installed in MXG 8.9.
MXG 8.9 is a replacement for MXG 8.8 (which had been shipped April 8).
The few minor errors that had been found in 8.8 were corrected, and the
support for Fujitsu's FACOM PDL data was enhanced.
This MXG 8.9 library contains 1370 members, 309,959 lines of code,
and builds 903 datasets with 31,868 variables documented in DOCVER!
Member NEWSLTRS contains all newsletters, including NINETEEN which
contains the Installation and Compatibility notes for MXG Version 8.
Changes thru 8.078 were printed in NEWSLETTER SEVENTEEN, Jul 10, 1990.
Changes thru 8.087 were contained in MXG PreRelease 8.2, Jul 20, 1990.
Changes thru 8.119 were contained in MXG PreRelease 8.3, Aug 26, 1990.
Changes thru 8.157 were contained in MXG PreRelease 8.4, Oct 9, 1990.
Changes thru 8.168 were contained in MXG PreRelease 8.5, Oct 27, 1990.
Changes thru 8.169 were contained in MXG PreRelease 8.6, Oct 27, 1990.
Changes thru 8.186 were printed in NEWSLETTER EIGHTEEN, Dec 3, 1990.
Changes thru 8.203 were contained in MXG PreRelease 8.7, Dec 18, 1990.
Changes thru 8.283 were printed in NEWSLETTER NINETEEN, Apr 8, 1991.
Changes thru 8.285 were contained in MXG Production 8.8, Apr 8, 1991.
Changes thru 8.305 were contained in MXG Production 8.9, May 1, 1991.
Critical Notes:
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.
Please note the new MANDATORY options for SAS 5.18 and 6.06 in the
SAS Notes in Newsletter NINETEEN. Member SASOPTV5 or CONFIG in this
library can be used to specify these options, but if you do not pay
attention to ALWAYS include the appropriate member, you will be
very frustrated by unresolved macro reference or 180 syntax errors!
MXG Newsletter NINETEEN contains Installation Instructions that MUST be
complied with. (Contained in member NEWSLTRS).
SAS 6.06 is repaired, and with the March 1991 or later SAS Usage Notes
tape, it is now MXG's recommendation that you begin your migration
to SAS 6.06. The March tape contains 100% pre-applied SAS ZAPs for
all SAS products, in IEBCOPY format, making SAS maintainance a snap!
Z6062141 is a critical ZAP that MUST be installed if you do not
have the March SAS tape installed.
IV. Documentation 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 31,868 variables from the 903 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.
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 MXG 8.8 enhancements:
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. ???
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.
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 1370 members (and about 309,959 source
lines) in IEBUPDTE format.
Under MVS use the IEBUPDTE utility to build MXG.SOURCLIB PDS library.
Under CMS use the TAPPDS command to build 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.
IMACXXXX 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.234A 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" measure 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.190A 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:
NEXTCHANGE: Version 8 72
--- Changes 8.305 thru 8.286 were added after MXG 8.8 was shipped ---
Change 08.305 About 90 of the 32,000+ MXG variables had no labels, some
DOC obsecure datetime variables were not formatted, and some
Apr 30, 1991 variables were length 8 when they should have been only
4 bytes long, as discovered in the MXG QA jobstreams. All
of these that could be corrected easily were!
Change 08.304 Type 79 support (RMF Monitor II) has now been extended
VMAC79 backwards to include RMF 3.5.1, and code was cleaned up
Apr 29, 1991 with this significant user contribution.
Thanks to Gordon Keehn, Fidelity Mutual Life Insurance Company, USA.
Change 08.303 IMS Log processing temporary variable OENQTO should have
TYPEIMS been spelled OENQO in line 107900.
Apr 28, 1991
Change 08.302 VM/ESA variable CHANBYTM was stored 8 bytes, but can be
VMACVMXA stored in only 4 bytes. Add CHANBYTM before DURATM in
Apr 28, 1991 the LENGTH statement at the end of line 060650.
Change 08.301 The New DB2 Trending members run fine the first week, but
TRNDDB2S in subsequent runs, the three shifts in prior weeks data
Apr 28, 1991 are summarized into a single observation for the entire
week (and SHIFT appears as Weekend). The recalculation
of SHIFT in trending should have only been applied to the
new PDB data, but bad logic caused the corruption.
This correction is for the DB2 Statistics trending member
TRNDDB2S. See Change 8.300 for DB2 Account trending.
1. The INCODE= argument at 005200:
INCODE = 005200
IF INWEEK THEN NUMINTVL = 1; 005300
LABEL NUMINTVL='NUMBER OF*STATISTICS*INTERVALS'; 005400
OUTPUT MXGSUM1; 005500
DATA MXGSUM1 005600
TIMES 005700
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 005800
SET MXGSUM1; 005900
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 006000
ELSE MINTIME=.; 006100
MAXTIME=QWHSSTCK; 006200
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 006300
QWHSSTCK=DATETIME; 006400
OUTPUT MXGSUM1; 006500
OUTPUT TIMES;, 006600
Must be changed to read
INCODE = 005200
IF INWEEK THEN DO; 005300
NUMINTVL = 1; 005310
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 005320
ELSE MINTIME=.; 005330
MAXTIME=QWHSSTCK; 005340
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 005350
QWHSSTCK=DATETIME; 005360
END; 005370
LABEL NUMINTVL='NUMBER OF*STATISTICS*INTERVALS'; 005400
OUTPUT MXGSUM1; 005500
DATA MXGSUM1 005600
TIMES 005700
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 005800
SET MXGSUM1; 005900
QWHSSTCK=DATETIME; 006000
OUTPUT MXGSUM1; 006500
OUTPUT TIMES;, 006600
2. The INCODE= argument at 012300:
INCODE = 012300
IF INWEEK THEN DO; 012400
IF QXMSMIAP=. THEN QXMSMIAP=.; 012500
IF QXNSMIAP=. THEN QXNSMIAP=.; 012600
IF QXNSMIAP=. AND QXMSMIAP GT 0 THEN QXNSMIAP=QXMSMIAP; 012700
END; 012800
OUTPUT MXGSUM1; 012900
DATA MXGSUM1 013000
TIMES 013100
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 013200
SET MXGSUM1; 013300
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 013400
ELSE MINTIME=.; 013500
MAXTIME=QWHSSTCK; 013600
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 013700
QWHSSTCK=DATETIME; 013800
OUTPUT MXGSUM1; 013900
OUTPUT TIMES;, 014000
Must be changed to read
INCODE = 012300
IF INWEEK THEN DO; 012400
IF QXMSMIAP=. THEN QXMSMIAP=.; 012500
IF QXNSMIAP=. THEN QXNSMIAP=.; 012600
IF QXNSMIAP=. AND QXMSMIAP GT 0 THEN QXNSMIAP=QXMSMIAP; 012700
IF DURATM GT 0 THEN MINTIME=QWHSSTCK-DURATM; 012710
ELSE MINTIME=.; 012720
MAXTIME=QWHSSTCK; 012730
%VMXGDUR(DATETIME=QWHSSTCK,INTERVAL=WEEK,NEWSHIFT=Y); 012740
QWHSSTCK=DATETIME; 012750
END; 012800
OUTPUT MXGSUM1; 012900
DATA MXGSUM1 013000
TIMES 013100
(KEEP=SYSTEM SHIFT QWHSSSID QWHSSTCK MINTIME MAXTIME); 013200
SET MXGSUM1; 013300
DATETIME=QWHSSTCK; 013800
OUTPUT MXGSUM1; 013900
OUTPUT TIMES;, 014000
Change 08.300 The New DB2 Account Trending has the same problem cited
TRNDDB2A for the DB2 Statistics Trending discussed above in the
Apr 28, 1991 Change 8.301.
This correction involves also requires two parts:
1. The two lines, 012900-013000, now reading:
MINTIME=QWACBSC; 012900
MAXTIME=QWACESC; 013000
Must be MOVEd to after 004900 (MOVE, not COPY!).
2. Then, the two lines, 019800-019000, now reading:
%VMXGDUR(DATETIME=QWACESC,INTERVAL=WEEK,NEWSHIFT=Y); 019800
QWACESC=DATETIME; 019900
Must be MOVEd to after the lines just moved above.
The end result of these two moves will be:
IF INWEEK THEN DO; 004900
MINTIME=QWACBSC; 004910
MAXTIME=QWACESC; 004920
%VMXGDUR(DATETIME=QWACESC,INTERVAL=WEEK,NEWSHIFT=Y); 004930
QWACESC=DATETIME; 004940
IF QXMSMIAP = . THEN QXMSMIAP = .; 005000
Change 08.299 A "Variable Not Found" condition occurs with ANALDB2R if
ANALDB2R the Accounting Trace Long report was requested by itself.
Apr 28, 1991 (If any other report was also requested, this error does
not occur). Line 021820, which now reads:
TIMES (KEEP=&SORT1 &SORT2 &SORT3 MINTIME MAXTIME);
was replaced by these 6 lines:
%IF &PMACC02 EQ YES %THEN %DO;
TIMES (KEEP=&SORT1 &SORT2 &SORT3 MINTIME MAXTIME);
%END;
%ELSE %DO;
TIMES (KEEP=DB2 MINTIME MAXTIME);
%END;
Thanks to Ron Roberts, The Equitable Life Assurance Society, USA.
Change 08.298 Fujitsu's AIM database manager (CICS-like) SMF records
VMACAIM2 were in error. The FILLER $CHAR2. in VMACAIM2 line 117
VMACAIM3 was deleted. In VMACAIM3, NUMSCHMA is PIB2, not PIB4,
Apr 28, 1991 and the DO loop in line 65 should be 1 to NUMSCHMA. These
changes were received long ago and should have been in
earlier versions. Thanks for the contributor; Bill has
provided them locally to Fujitsu sites down under!
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
Change 08.297 Support for Fujitsu's FACOM operating system now includes
TYPEPDL both MSP and FSP data from PDL reports from PDA records.
TESTFACO Former "X-rated" member XPDLPDA is now renamed TYPEPDL,
JCLTEST and first-time-logic added for history datasets. The MXG
JCLTEST6 test and cross reference jobstreams now separately test
JCLUXREF all FACOM support in step TESTFACO, so that all 25 of the
JCLUXRE6 RTYPExx datasets and histor datasets created by TYPEPDL
Apr 19, 1991 are documented in DOCVER. The coding changes that added
FSP support were a significant user contribution, and
also added decoding of several additional PDL reports.
Thanks to Ian Heaney, M.L.C., AUSTRALIA.
Change 08.296 VM/XA processing requires more work space that it should
VMACVMXA because the PROC DATASETS to delete VXUSEINT and VXACTINT
Apr 19, 1991 was commented out during testing. Remove the comments in
line 798400. Also, variable RDEVOFFL was not kept because
it was misspelled as RDEFOFFL in the KEEP= list.
Thanks to Jay Cicardo, Southwestern Bell, USA.
Change 08.295 SAS datasets will be destroyed/corrupted by CASORT 6.6
CASORT 6.6 if its ATTRLS Option (system wide, set when CASORT was
Apr 18, 1991 installed) was specified ATTRLS=YES. Instead, you MUST
have ATTRLS=NO. With ATTRLS=YES, CASORT will RLSE sort
work space after each invoked SORT, which somehow causes
SAS to think all records were deleted by NODUP, and the
output dataset built by the PROC SORT contains either
zero or one observation! If there is one observation,
all of its numeric variables are zero or missing, which
happened with RMFINTRV, and the garbaged dates/times
put messages on the SAS log, but then caused the TREND
database to be overwritten with only one observation!
CA says the problem is known to affect ANY invoked sort,
not just SAS invoked sorts. SAS tracking 180027 is open,
to determine why SAS built the corrupted 1-observation
data set, and I will investigate how I can make the trend
logic more robust, but you MUST specify ATTRLS=NO to fix
the real problem with CASORT 6.6.
Thanks to Arnold Ruterbories, Standard Insurance Company, USA.
Change 08.294 Additional SAS 6.06 error conditions have been reported.
SAS 6.06 a.VMXGVTOC will fail "VARIABLE VOLSER NOT FOUND", if you
Apr 18, 1991 installed SAS ZAPs Z6061834 or Z6062315, due to an error
introduced by those zaps (the "autovariable" VOLSER was
lost when those zaps were installed). SAS ZAP Z6062674
now exists to correct their error and is required. It is
not on the April SAS Notes tape, but can be downloaded.
b.SAS will ABEND with an 0C4 in SMS sites, if the datasets
in the CONFIG DD concatenation are SMS-managed datasets,
if the CONFIG= JCL parameter is used. (If you used the
prior MXG technique of actually overriding the CONFIG DD,
this abend does not occur, but then you must be careful
to order the JCL override, thus the CONFIG= parameter was
recommended instead of overriding the CONFIG DD!) The SAS
error is fixed by ZAP Z6062264, which is required if your
site has SMS-managed datasets for SAS and or MXG.
Change 08.293 -IBM's Cache DASD RMF Reporter "CRR" Product's SMF records
ANALCACH status bits were changed (don't know when!) and count of
FORMATS sequential-detected sequential read requests was added.
VMACACHE Variables have been dropped from CACHE90. Flag variables
Apr 18, 1991 (CSCS1-CSCS8,CSNVSS1-CSNVSS8, CSDP,CSCD,CSFF,CSFD,CSPD,
CSSD,CSFC,CSPP) are replaced by format-decoded variables,
and the caching/fastwrite/pinning/etc. status variables
from the CSVOL segment (which apply only to that CSVOL,
and not to the VOLUME being reported) are not kept. IBM's
3990 Storage Control Reference, GA32-0099-3, pp 171-177,
Chapter 4, Command Descriptions, describes the statistics
captured much better than the CRR manual (SH20-6295-4).
CACHE90 variable FWDC, the count of DASD fast write ops
that were forced to access DASD directly (because the
nonvolatile storage was insufficient), may be important
in recognizing this performance degradation.
-The Cache analysis program ANALCACH was revised to now
CACHE90 (instead of the CACHETY data from 3880's) along
with RMF TYPE74 data for sample reports.
Thanks to Victor Heiner, Northwest Airlines, USA.
Thanks to Alfred Holtz, Dun and Bradstreet, USA.
Change 08.292 Boole & Babbage CICS Manager product causes MXG messages
VMAC110 "Unexpected Statistics Subtype" with STID=200 to 210, due
Apr 16, 1991 to that product's pseudo type 110 statistics records. The
additional records will be supported in the future.
Thanks to Paul Dean, IBM Hursley, ENGLAND.
Change 08.291 Variables EXCPTOTL and IOTMTOTL should have been in the
ASUMJOBS KEEP= list for dataset BATCHJOB (added by Change 8.230
Apr 16, 1991 for detect duplicate job hold enhancement).
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 08.290 MVS Account Fields with length=0 create MXG error message
IMACACCT "***ERROR.IMACACCT.ACCOUNT FIELD n LENGTH WRONG", and any
Apr 16, 1991 account fields after the zero length field are skipped.
If the "n" in the message is greater than the number of
Account Fields you are KEEPing, there is no impact on the
datasets built by MXG. The enhancement in Change 8.267
(to prevent STOPOVER if account length were wrong) failed
to allow for a zero length field. The nine lines that
now read "ELSE DO;" must be change to read:
(line number)
ELSE IF LENACCT1 GT 0 THEN DO; 012300
ELSE IF LENACCT2 GT 0 THEN DO; 014000
ELSE IF LENACCT3 GT 0 THEN DO; 015700
ELSE IF LENACCT4 GT 0 THEN DO; 017400
ELSE IF LENACCT5 GT 0 THEN DO; 019100
ELSE IF LENACCT6 GT 0 THEN DO; 020800
ELSE IF LENACCT7 GT 0 THEN DO; 022500
ELSE IF LENACCT8 GT 0 THEN DO; 024200
ELSE IF LENACCT9 GT 0 THEN DO; 025900
This error occurs ONLY if your IMACACCT was tailored from
MXG version 8.8.
Thanks to Mike Hoevenaars, Toyota Canada, CANADA.
Change 08.289 ACF2 Release 5.2 added four variables (ACPMFCPM,ACPMFCJN,
VMACACF2 ACPMFCJI, and ACPMFCLI to the ACF2PR dataset & variables
Apr 16, 1991 ACVMFLRT, ACFMFTRT, and ACVMFTRS to ACF2VR dataset.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 08.288 Format MGSYNDB for SYNCSORT value 2 should have formatted
FORMATS to 2:3390 instead of the (now nonexistent) 2:3330 device,
Apr 16, 1991 and values 16 and 24 were added to ACF2 formats MGACFDA
and MGACFDB respectively.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 08.287 Member VMACEPIL on the original MXG 8.8 tape was wrong.
TESTOTHR Instead of the complete revision of support for Candle's
VMACEPIL EPILOG/CICS, VMACEPIL contained a copy of member CHANGES!
Apr 16, 1991 This error also caused JCLTEST step TESTOTHR to fail.
This change simply puts back VMACEPIL in VMACEPIL!
Thanks to Rex Pommier, St. Lukes Hospital Fargo, USA.
Change 08.286 IEBUPDTE unload of MXG 8.8 ends with condition code four,
V88-tape prints "IEB823I SYSIN HAS NO RECORDS for AS400PDS", and
Apr 11, 1991 MXG.SOURCLIB contains 1394 members instead of the stated
1367 members, but this warning has no real impact on the
MXG.SOURCLIB data set. The warning occurs because member
AS400PDS itself was an IEBUPDTE input for a 28-member PDS
with preliminary support for AS400 data. Your unload saw
those "./" statements and created the 28 members starting
with @@@....., AS400..., ICEGENER, and QAPM.... directly
in your MXG.SOURCLIB, and then there were no lines in the
member AS400PDS, causing the warning! I had intended to
change the "./" to "xy" in AS400PDS to avoid this warning
but failed to do so. Sorry for all those phone calls and
faxes that would have been avoided by better testing.
Thanks to Ken Thomas, Maryland Casualty Company, USA.
--Changes thru 8.285 are included in MXG Version 8.8 dated Apr 8, 1991-
Change 08.285 A surprising discovery by looking at DCOLLECT data. DASD
VMACDCOL capacity stated by IBM (eg, 630MB for a 3380 volume) is
Apr 4, 1991 NOT 630 Megabytes, but instead is 630 "Million bytes"!
A 3380 (47476*15*885 = 630,243,900 bytes) actually stores
only 601MB (megabytes)! So much for IBM consistency in
use of "MB". Because VMACDCOL assumed MB was megabytes,
it multiplied by 1024 to convert to bytes for MGBYTES, so
this change replaced all occurrences of 1024 with 1000.
The unknown UK user also noted that the test that set the
values of DCVEVLCP, DCVEBYTK, and DCVELSPC should have
tested DCVERROR instead of DCVFLAG1.
Thanks to Derek Cespedes, Florida Power and Light, USA.
Thanks to ???, ???, ENGLAND.
Change 08.284 Major revision of support for EPILOG/CICS was finished
EXEPCIJC after Newsletter NINETEEN went to the printer. The change
EXEPCISF is INCOMPATIBLE with previous MXG EPILOG/CICS support, as
EXEPCISI the TYPEEPIL dataset no longer is created. Instead, these
five new MXG datasets are created by TYPEEPIL execution:
EXEPCISU EPILCITR - Transaction data - most important.
EXEPCITR EPILCISU - Startup.
TESTOTHR EPILCISF - Suffix.
VMACEPIL EPILCIJC - JCL Parameters
Apr 4, 1991 EPILCISI - SIT Parameters
Each dataset keeps only the appropriate variables.
VMACEPIL code was restructured, with a separate section
for Releases 450-451, which is different from 440 format.
Only EPILCITR records were available for testing from 450
but there is no change in the format when you install 451
so I anticipate no problems. While the (archaic) 440 code
might need work, Candle solves 440 problems by sending a
copy of 451!
Thanks to Richard Evans, Mervyn's, USA.
==Changes thru 8.283 were printed in MXG Newsletter NINETEEN==========
Change 08.283 SAS 6.06 errors like "Data set is not sorted" that were
SAS 6.06 discussed under Usage Note 1000 were finally resolved on
Mar 29, 1991 the March SAS Usage Notes Tape by the inclusion of SAS's
ZAP Z6062141. If you do not have the March SAS 6.06 tape
installed (it's now a 100% pre-applied ZAPed loadlib in
IEBCOPY format), you MUST at least download and install
Z6062141.
Change 08.282 This new member documents all of the "Products" that MXG
PRODUCTS supports. PRODUCTS identifies which product versions are
Mar 29, 1991 supported by which version of MXG and the member name of
the MXG member(s) that processes that product's records.
Use your online editor to search for the product name to
find the entry for a specific product, which will contain
the names of MXG datasets created, their exit names, etc.
Suggestions for enhancement are most welcome.
Change 08.281 This new member documents the IMAC.... exit members which
IMACAAAA tailor MXG for your site. Some IMACs (IMACSHFT,IMACWORK)
Mar 29, 1991 should always be tailored, but most IMACs are not needed
to be changed by most sites. This new member groups the
different purpose IMACs together to make it easier for an
installer to know which IMACs affect their site. The IMAC
itself contains self-documenting comments for its use.
Change 08.280 Transit time reports from DB2 trace are now in ANALDB2R.
ANALDB2R Selection criteria is more robust and is uniform across
Mar 29, 1991 all reports, and can include SHIFT or DB2 Trace Number.
ANALDB2R reports can be produced from either the PDB or
the new TRNDDB2x data (See Changes 8.276 and 8.279) for
Accounting and Statistics reports. Data from the TREND
databases can be input along with data from your daily
PDB to compare history with current with PDB=PDB TREND
syntax to cause ANALDB2R to combine both data sources.
Transit time and SQL trace activity analysis were added
by ANALDBTR (Change 2.249) which creates the trace-pair
data sets needed. ANALDB2R now will use those data for
these new reports, and for the I/O Activity Summary, and
eventually all DB2 trace reports will be restructured to
use the ANALDBTR trace-pairs.
Change 08.279 Summarization of DB2STAT0 and DB2STAT1 statistics data
TRNDDB2S into the TREND database uses PDB.DB2STAT0 and DB2STAT1
Mar 29, 1991 as input to create TREND.TRNDDB20 and TREND.TRNDDB21.
Summarization is by WEEK by SHIFT within SYSTEM, and DB2
Sub-System ID, QWHSSSID. Note that Version 8.8 ANALDB2R
can use these new TREND datasets as input for reports.
See DOCTREND for the structure of MXG trending.
Change 08.278 This significant user contribution for AS400 Records will
AS400PDS eventually be a fully supported part of MXG, but time ran
Mar 28, 1991 out for development and testing. This member is actually
a 27-member unloaded PDS, and is provided so that leading
edge sites who would otherwise have had to start from the
beginning, may find this a starting point for AS400 data.
It should be regarded as preliminary, unverified, and is
certain to change in structure. Your input is welcome.
Thanks to Carolyn Barnett, Sentara Health System, USA.
Change 08.277 Variables INAVG and READYAVG were added to the RMFINTRV
RMFINTRV dataset. I had actually planned to do further revisions
Mar 28, 1991 to RMFINTRV for MVS/ESA, but ran out of time!
Thanks to ???, ???, EUROPE.
Change 08.276 Summarization of DB2ACCT dataset into the Trend Database.
TRNDDB2A Input is weekly PDB.DB2ACCT into TREND.TRNDDB2A. The time
Mar 28, 1991 summarization is for each shift for each week within the
SYSTEM SHIFT QWHSSSID QWHCPLAN QWHCCN values.
Both ANALDB2R and/or GRAFDB2 will produce Accounting
Detail and Summary reports and graphs from TRNDDB2A.
See documentation in the member itself.
Change 08.275 Graphical analysis of DB2 data from MXG PDB or TREND
GRAFDB2 data libraries (three sets of graphs) can be produced
Mar 28, 1991 and a graphic catalog (default DDname of PDB) is built.
See comments in member for documentation.
Change 08.274 Documentation of the techniques implemented in MXG use
DOCGRAF of SAS/GRAPH, and briefly describes the MXG GRAF....
Mar 28, 1991 members and the graphic catalog they produce.
Change 08.273 New style macro generates the code needed to download
VMXGDOWN all of the datasets contained in a single SAS data
Mar 28, 1991 library. This utility is the logical equivalent of:
PROC DOWNLOAD DATA=PDB._ALL_ OUT=PCPDB;
which does not exist.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.272 The MXG utility UTILPRAL will print all datasets in a
UTILPRAL SAS data library. This change simplifies that process
VMXGPRAL by executing as a single step with no external DD.
Mar 28, 1991
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.271 Graphics table added samples for IBM3825 and IBM3827
VMXGGOPT devices (but only in portrait mode; rotating requires the
Mar 28, 1991 use of templates, and is non-trivial). See SAS Technical
A SAS note xxxx that discusses rotation. Also, standard
PATTERN/SYMBOL statements were added for consistency so
they can (eventually) be used in all GRAF.... members.
Change 08.270 Printer analysis logic for NPRO was corrected and support
ANALPRTR for XEROX XPAF CPU calculation (based on testing of early
ASUMPRTR releases of XPAF) was added. The default value for NPRO
IMACPRTR is now zero, since only the (dead?) 3800-3 used NPRO.
Mar 28, 1991 For sheet printers, PAGECNT is equal to the number of
physical sheets that went through the printer; SHEETPRN
is the number of sides printed. For the printer THRUPUT
calculations, SHEETPRN is now used instead of PAGECNT if
SHEETPRN is non-zero (using PAGECNT, duplexing made the
printer's thruput half-speed)!
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.269 Preliminary support for log produced by IBM's TPNS. Its
TYPETPNS pretty simple, but there is not a whole lot of data.
Mar 27, 1991
Change 08.268 Because it was not always clear on the log when %VMXGSUMs
VMXGSUM invocation actually began, a RUN; statement was inserted
Mar 27, 1991 after line 019500.
Change 08.267 Protection for invalid accounting field lengths has been
IMACACCT enhanced. The total length of accounting data was always
Mar 27, 1991 compared with record length, but individual account field
lengths were not verified, until now. A site with a badly
corrupted type 30 record (due to an error in their SMF
exit code) ABEMDED with a STOPOVER. With this change, the
unnecessary STOPOVER is avoided, the bad record detected,
and an MXG message is now printed on the log. The site
chooses to remain unknown!
Change 08.266 Thanks for IBM's excellent vendor support in the CICS/ESA
Mar 27, 1991 Early Test Program, we can confirm that not only will
MXG Version 8.8 correctly process CICS/ESA 3.1 SMF data,
but also that it will not fail with CICS/ESA 3.2 records!
Change 08.265 Support for NETSPY Release 4.0 was added by this change.
EXNSPYAC Four new variables were added to the NSPYAPPL dataset,
VMACNSPY eight new variables were added to the NSPYVIRT dataset,
Mar 26, 1991 and the new NSPYACCT data set with 68 variables for the
Network Accounting type 'C' NETSPY record is created.
Thanks to Richard Warren, Solomon, Inc, USA.
Change 08.264 This change summarizes and documents the MXG DASD space
ANALVVDS management facilities that have been enhanced in 8.8.
ASMVVDS Member JCLDASD/JCLDASD6 contains the sample JCL that is
FMXGUCBL suggested to allow you to process your VTOCs and VVDS.
IMACVVDS Comments in the MXG members elaborate on each of the
JCLDASD programs discussed. Note that "ASM" members are written
TYPEVVDS in IBM Assembler and must be assembled and link edited
VMXGVTOC before they can be used. Sites which have installed
VMXGVTOF DFP 3.2 or later should first look at IBM's DCOLLECT
VMXGVTOR utility (supported by MXG's TYPEDCOL member) to measure
Mar 26, 1991 their DASD farm, as it may be adequate for most sites.
The VTOC/VVDS processing described below gives more data
that is presently provided by IBM's DCOLLECT.
1. VTOC Processing
Original VTOC processing in MXG consisted of these three
members, which in concert would dynamically allocate all
DASD volumes that were online, read each VTOC, and build
three data sets describing VTOCs, Datasets, and extents
in your DASD farm:
FMXGUCBL - a function for dynamic allocation, used by
VMXGVTOR - a %macro that interated the execution of
VMXGVTOC - a SAS program that read a single VTOC
Execution of this sequence created the three MXG datasets
to be used for DASD space management, chargeback, etc:
VTOCINFO - One obs per VTOC, describes the volume
VTOCLIST - One obs per dataset, describes each dataset
VTOCMAP - One obs per extent, for pack analysis.
Large sites (over 500 volumes) found that VTOC reading
with SAS itself, while functional, took scores of seconds
per VTOC. Philip Morris wrote their own ASM program and
graciously contributed it to MXG, and cut the VTOC read
time to seconds per VTOC! You need only to assemble and
link edit the ASM program:
ASMVTOC - "Fast" VTOC reading assembly program
and then execute PGM=ASMVTOC to read all VTOCs and write
a single flat file to the VTOCDUMP DDname, which is then
read by the MXG SAS %macro program %VMXGVTOF in member
VMXGVTOF - Reads VTOCDUMP file created by ASMVTOC and
create three VTOC.... data sets.
(The example JCL in JCLDASD/JCLDASD6 then copies the
three VTOC.... datasets to the SAS data library that
is pointed to by the MXGDASD DDname.)
This is the recommended method for reading all VTOCs.
2. VVDS Processing.
Originally VVDS described only VSAM dataspace on a volume
but with SMS, the VVDS contains an entry for both VSAM
(in a VVR in the VVDS), and for non-VSAM (in a NVR in the
VVDS). Keeping track of VSAM data spaces on a volume was
the primary reason that the MXG Assembly program
ASMVVDS - read all VVDS and create a user SMF record
which was then processed by MXG members
IMACVVDS - identifies the SMF record number you chose
TYPEVVDS - to read the SMF VVDS records and create
the MXG dataset of of the same name with
an obs for each entry in the VVDS.
Additional idiosyncrasies in VVDS entries were found and
corrected in analysis which is now inclued in member
ANALVVDS - executes IMACVVDS/TYPEVVDS, and adds logic
to "clean-up" the VVDSf data.
Member ANALVVDS creates these two MXG datasets for VVDS:
TYPEVVDS - One obs per VVR, cleaned up
VSAM - One obs per VSAM data set.
The two datasets are written to the DDname of MXGVVDS.
Change 08.263 Three variables added by DB2 2.2 were not deaccumulated.
DIFFDB2 Variable Q3STRDON in DB2STAT0 and variables QTAUCCH and
Mar 26, 1991 QXMIAP in DB2STAT1 are now DIF()'d in DIFFDB2.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 08.262 Support for TSO/MON Release 5.3.0 has been added and has
EXTSODRU been tested, due to excellent support from LEGENT; not
VMACTSOM only did this vendor provide documentation in advance of
Mar 25, 1991 the general availability of the product, but also sample
SMF records were provided for testing! The major change
is the new TSOMDRU Dynamic Resource Utilization dataset,
which allows you to identify the most resource intensive
commands so that you can then enable detail recording for
those commands. Minor changes included new fields in the
TSOMSYST and TSOMCALL datasets containing Hiperspace page
in and page out counts.
Change 08.261 TSO/MON system records are restricted to 4089 bytes. When
VMACTSOM more users are logged on than fit in 4089 bytes, TSO/MON
Mar 25, 1991 writes multiple records, which MXG recognized, but the
INTRVTM value was incorrect in these "split" records.
Additionally, the test for INTRVTM=0 as criteria for the
first of a split record was changed to TSMSSEGN=1.
Thanks to Richard Morris, Progressive Companies, USA.
Change 08.260 Many variables in the HSM user SMF record accumulate from
DIFFHSM record to record. The new DIFFHSM provides the logic to
TYPEHSM de-accumulate these ascending values with the SAS DIF()
VMACHSM function. For the first occurrence of a "BY Group" value
Mar 25, 1991 or if values between adjacent observations decrease, MXG
sets the DIF()'ed variable to a missing value. This new
algorithm has been tested, but only with a few sets of
HSM SMF data records. If you have added HSM SMF record
processing to BUILDPDB, you must also %INCLUDE the new
member DIFFHSM in the EXPDBOUT member. If instead you
use member TYPEHSM to process HSM, the DIFFHSM member is
now already included for you. VMACHSM was also changed.
Variables DSRFUNCT,FSRFUNCT,VSRFUNCT were redundant with
DSRTYPE,FSRTYPE,VSRTYPE (which also take less space and
are decoded by an MXG format) so the ...FUNCT variables
were removed from VMACHSM datasets. Several PD4. variable
input statements were protected for hex nulls, and indent
of code was standardized. Some inconsistent data values
were found in IBM records - for example, several of the
fields which contain "number of tracks" contain hex
FFFFFFnn values, which is 4,294,000,000+ in decimal!
Use with caution, and let me know if you find IBM APARs
are needed to correct their data errors!
Change 08.259 TYPE6156 variables VOLSER1-VOLSER5 can be wrong if there
VMAC6156 are more than five volumes, because these variables were
Mar 24, 1991 not initialized. Line 020700 was change to a DO group:
IF NR6XVOLS=1 THEN DO; VOLSER1=VOLSER; VOLSER2=' ';
VOLSER3=' ';VOLSER4=' ';VOLSER5=' ';END;
Thanks to Kenneth D. Jones, Maritime Telegraph and Telephone, CANADA.
Change 08.258 New dataset PDB.SPUNJOBS is created automatically in your
SPUNJOBS MVS PDB by the new SPUNJOBS program, which reads today's
Mar 15, 1991 SPIN datasets and combines those SPINning job's records,
giving you PDB.JOBS variable names and a single dataset,
PDB.SPUNJOBS, describing jobs still spinning. Of course,
many variables in PDB.SPUNJOBS will have missing values,
because only fields from records that were found will be
non-missing for a particular job. Variable INBITS shows
which records were found, and in section "PDB" of Chapter
40 of the MXG Supplement is described which variables in
PDB.JOBS and PDB.SPUNJOBS come from which record.
Change 08.257 Goal Systems Explore/VM records for VM/370 were supported
VMACVMXP by MXG's VMACVMXP, but the VM/XA extensions were not in
XMACVMXP that data. This change stores the original member in the
Mar 15, 1991 XMACVMXP member (for backup, but will eventually go away)
and replaces the contents of VMACVMXP with new code that
was contributed, but only syntax checked. Use with the
appropriate caution.
Change 08.256 IMS Log Processing has been once again been significantly
TYPEIMS re-engineered, and now supports WFI (Wait-for-Input) and
VMACIMS multi-transactions per program schedule correctly, and it
Mar 14, 1991 also eliminates those occasional negative values in the
input and output queue times. The new design uses MXG's
BUILDPDB logic to merge the PRG and INOUT3 (message) data
and puts non-matches in UNMATCHD, but also creates a new
dataset MSGMISSD if the log does not contain all messages
for a program sked, (if WFI runs from 8am to 8pm, but if
the IMS log starts at noon, messages executed before noon
will be counted in the 07 record when the WFI terminates,
but would not have their 01-03-31-35-36 records in this
IMS log dataset). The CPU and DL/I calls for those missed
messages will be lumped into one observation in MSGMISSD
(variable NMSGMISS counts the missed message executions)
and all IMS resources are captured in IMSTRAN + MSGMISSD,
but only IMSTRAN captures transaction response times too.
The re-design eliminated the need to 'explode" IMS07 obs.
This redesign answers all reported problems with IMS log
processing for non-fastpath transactions, but at best the
IMS log is a poor source of IMS measurement data. The IMS
log was designed ONLY for backup/recovery, and IBM does
not care enough for IMS users to enhance the log to put
a transaction identifier in each record, making heuristic
algorithms based on found-data-patterns of MSGDRRN and
DEST necessary to reconstruct a transaction response from
its log records). Even when reconstructed, the IMS log
contains only a single measure of CPU time used which not
only includes the Control Region and Message Region times
but also includes the CPU time used when IMS transactions
access DB2! Large IMS sites deserve better quality from
IBM. Nevertheless, we will continue to do our best to
extract whatever can be captured from IMS log records.
Change 08.255 IMACJBCK allows SMF record selection by jobname, and this
IMACJBCK is a documentation note rather than a change. Only jobs
Mar 13, 1991 with blank or higher jobname are kept by MXG's default.
Type 30 records with nulls are created by IBM errors (see
MXG Technical Notes in Newsletter NINETEEN), and these
"bad" records were deleted by MXG because of the IMACJBCK
default. The default was needed to protect the PDB from
a runaway software monitor that created scores of records
with invalid job names, and the default could probably be
changed (to pass any or all values of jobname) without
any significant impact, but since that can't be proven in
advance, it seemed better to leave the default alone, but
remind you of this MXG default here and in comments in
the IMACJBCK member.
Thanks to Mike Revelette, Defense CEETA, USA.
Change 08.254 Support for OPPSI Operator Single System Image in SYSPLEX
VMAC76 environment added six new traceable variables to TYPE76:
Mar 6, 1991
OMDGWTOI - Lines of messages, WTOs, issued per millisec
OMDGCMDI - Commands issued per millisecond.
OMDGWTLI - WTLs (write to logs) per millisecond.
OMDGWQEB - Max WQEs (WTO Queue Elements) on queue.
OMDGOREB - Max OREs (Operator Reply Entries on queue.
OMDGAMRE - MAX messages on AMRF (Action Msg. Retention)
You must first enable RMF trace for these fields, and use
a PRINT of TYPE76 dataset to examine their values.
Change 08.253 SYNCSORT SCZ 33038 for SYNCSORT 3.3 or 3.4 adds two new
VMACSYNC counters with the number of frames of Hiperspace/Data
Mar 5, 1991 Space allocated (HPALLOC) and used (HPUSED). The two new
fields occupy formerly reserved fields, so prior versions
of MXG will not fail when this SCZ is installed.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 08.252 Talk about great response from IBM for this vendor!!!
VMACDCOL At SHARE 76 last week, IBM mentioned that a future APAR,
Mar 5, 1991 OY37378, would add many new fields to the HSM DCOLLECT
record. Starting with the HSM Hotline telephone number
(listed in Pat Kearney's GC38-7014), it took only three
short telephone calls and less than three elapsed hours
before my fax machine coughed out the DSECT of the new
HSM record produced by DCOLLECT! Due to this great
response from IBM, APAR OY37378 is supported in this MXG
version (transparently), and you won't need to install a
new version later this spring! The new variables are:
ORGEXPDT='EXPIRATION*DATE'
UMALLSP ='ORIGINAL*ALLOCATE*SPACE'
UMBKLNG ='BLOCK*LENGTH'
UMCREDT ='CREATION*DATE'
UMEXPDT ='EXPIRATION*DATE'
UMFLAG2 ='INFORMATION*FLAG*#2'
UMGDS ='GDG?'
UMLBKDT ='LAST*BACKUP*DATE'
UMLRFDT ='LAST*REFERENCED*DATE'
UMNMIG ='NUMBER OF*TIMES*MIGRATED'
UMPDSE ='PDSE?'
UMRACFD ='RACF*INDICATED?'
UMRECOR ='VSAM*RECORD*ORGANIZATION'
UMRECOR ='VSAM*RECORD*ORGANIZATION'
UMRECRD ='RECORD*FORMAT*BYTE'
UMRECSP ='RECALL*SPACE*ESTIMATE'
UMRELBK ='RELBLK?'
UMSMSM ='SMS*MANAGED?'
UMUSESP ='ORIGINAL*SPACE*USED'
UMCHIND ='CHANGED*SINCE LAST*BACKUP?'
UMDSORG ='DATASET*DSORG*ORGANIZATION'
These variables will exist, but will have missing values
or blanks until the PTF for the APAR is installed. See
also the discussion in Change 8.130 for DCOLLECT info.
The PTF for OY37378 requires additional prerequisites.
APARs OY41039 and OY41256 must be installed before 37378.
Change 08.251 This is a revision of and enhancement to Change 8.182.
BUILDPDB The CICS 3.1+ Statistics records are combined to create
BUILDPD3 four interval data sets CICINTRV, CICEODRV, CICINTRV, &
CICINTRV CICUSSRV. CICS Stats records are created at an INTerval,
Mar 5, 1991 (CICINTRV), at EOD (End of Day, or Shutdown), at REQuest
(CICREQRV), or at USS (CICUSSRV). The CICINTRV dataset
replaces and enhances the old CICSYSTM dataset that has
zero observations under CICS 3.1+. The CICEODRV dataset
is brand new and provides Shutdown & EOD statistics. In
fact, CICS 3.1 no longer prints ANY of the shutdown stats
on the Job's listing. IBM provides the DFHSTUP utility to
extract Shutdown stats from SMF data. MXG has CICEODRV!
Printing the CICEODRV data set wil give your CICS folks a
report for each shutdown/end of day evolution. There are
the nineteen CICS datasets that are currently used to
create the four (INT/EOD/REQ/USS) interval datasets:
CICAUTO CICDMG CICDQG CICDQT CICDS CICDTB
CICFCT CICLDG CICM CICSDG CICSMDSA CICST
CICTC CICTCT CICTDG CICTM CICTSQ CICTST
CICVT
Note that there are a few other CICS Statistics datasets
that are not currently included in these four interval
MXG data sets. As we learn more about CICS/ESA, these
four datasets built by CICINTRV member may be enhanced.
These four CIC...RV interval datasets are automatically
created in the PDB library by BUILDPDB/BUILDPD3 if you
do nothing; member IMACCICS defaults the destination DD
name to "PDB". The sort order of these four datasets is:
BY SYSTEM APPLID SMFPSSPN COLLTIME DURATM SMFSTINO;
Change 08.250 PR/SM "overhead" is explicitly captured when APAR OY36668
VMAC7072 (and associated microcode) is installed in ES/9000 or S/J
Mar 4, 1991 models of the 3090 (this APAR is not available on earlier
hardware platforms). The APAR captures the "Effective
Dispatch" duration, LCPUEDTM, for each partition. The
difference between LCPUPDTM, the existing LPAR Dispatch
time, and this new LCPUEDTM "Effective" LPAR Dispatch, is
the time that this LPAR was dispatched for management of
this partition. In addition to capturing the partition
LPAR management time, there will be a new observation in
TYPE70PR with a partition name of PHYSICAL that will have
only a value for LCPUPDTM. This "pseudo" partition does
not actually exist, but is the capture mechanism for the
total additional time that LPAR was dispatched but could
not be charged to a specific partition. See the technical
discussion and schematic in Newsletter NINETEEN.
Note that with this APAR installed, all of the IBM RMF
reports will now use the "Effective" dispatch time as
their 100% CPU busy denominator.
Although unrelated to the primary purpose of this APAR,
two new fields (LCPUCAP and LCPUCAPC) identify if each
partition had Capping in effect, or if Capping status
changed during the interval.
Change 08.249 DB2 trace records are now "paired" (event start and end
ANALDBTR are merged) in this new analysis routine for serious DB2
Feb 28, 1991 questions. (Note that most sites with DB2 do not need the
detail of SMF 102 tracing; member ANALDB2R seems to meet
the reporting needs of the vast majority of MXG sites).
But if you need to trace SQL calls, I/Os, etc., this
routine will sort and match the pairs and builds the many
data sets from your DB2 trace. The instructions for its
use and the datasets created are documented in the member
itself.
Change 08.248 DB2ACCT variable QWHDUNIQ is now formatted $HEX12. Three
VMACDB2 variables, QLACCPUL, QLACCPUR, QLACDBAT, added for DB2
Feb 28, 1991 distributed data durations, are not in 8-byte Timer Units
used every where else in DB2, but are microseconds stored
in an 8-byte floating point number! Change lines 189800
thru 190000 to use RB8.6 instead of MSEC8.!
Thanks to Bob Otis, Rockwell International, USA.
Change 08.247 Support for Boole and Babbage's CMF Monitor's "Type 240"
ANALCM27 SMF record is added by this MAJOR user contribution! The
ANALCM29 subtypes 0, 1, 19, and 23 are processed by the standard
EXCMFASM architecture MXG members TYPECMF/VMACCMF into 16 datasets
EXCMFCPQ CMFASMQ CMFDEVIC CMFEXTRT CMFPG0V
EXCMFCPS CMFCACHE CMFDOM CMFIPS CMFPRIOS
EXCMFDEV CMFCPUQ CMFEXTCC CMFOBJ CMFSRMC
EXCMFDOM CMFCPUS CMFEXTPG CMFPG CMFTRACE
EXCMFID
EXCMFIPS In addition, two specific processing/reporting members
EXCMFOBJ for the subtype 27 (cache sampler) and subtype 29 (the
EXCMFPG CS monitor) are provided in ANALCM27 and ANALCM29.
EXCMFPG0 The actual SMF record ID is set in member IMACCMF.
EXCMFPRI
EXCMFSRM The implementation includes a CALLed function, that is
EXCMFTCC yet to be added in MXG. Also, actual testing with the
EXCMFTPG BUILDPDB has not been performed yet.
EXCMFTRA
EXCMFTRT
IMACCMF
TYPECMF
VMACCMF
Feb 21, 1991
Thanks to Richard L. Gimarc, Boole and Babbage Austin, USA.
Change 08.246 SAS 6.06 Compatibility. LENGTH DEFAULT=4 is positional.
VMACSMF Variables ID and SUBTYPE in TYPE30_V and TYPE1718 were
Feb 21, 1991 stored in 8-bytes instead of 4-bytes because they precede
the LENGTH DEFAULT=4 statement. The LENGTH statement in
VMACSMF now includes LENGTH DEFAULT=4 preceding INPUT.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 08.245 Support for NETMASTER V2.1.0 has been added. The type 39
EXTY39 records written by NETMASTER are generally identical to
FORMATS IBM type 39 records. Two TOD variables exist at the end
VMAC39 of the SCS secion, SMFNCSTM/SMFNCETM, but their values
Feb 20, 1991 are identical to ACTSTIME/ACTETIME in the ACCT section,
and are not kept. The subtype 255 creates a new dataset,
TYPE39FF that is unique to NETMASETR and contains:
SMFNRCFA='RESOURCE*AVAILABLE*?'
SMFNRCLN='RESOURCE*LINK NAME'
SMFNRCNI='RESOURCE*NETWORK*ID'
SMFNRCNM='RESOURCE*NAME'
SMFNRCPU='RESOURCE*PU NAME'
SMFNRCR ='CONFIG DATA REVISION LEVEL'
SMFNRCSP='RESOURCE*SUBAREA PU NAME'
SMFNRCSS='RESOURCE*OWNING/ADJACENT SSCP'
SMFNRCST='END OF*NETMASTER*INTERVAL'
SMFNRCTP='RESOURCE*TYPE'
This change has been bench validated with printed dumps
of several NETMASTER records.
Thanks to Gerry Binas, DCSD, Manila Electric Company, PHILIPPINES.
Change 08.244 VM/XA and VM/ESA MONWRITE records can cause an erroneous
VMACVMXA MXG message "Probable Data Loss Due to MONWRITE Failure".
Feb 20, 1991 MXG detection of internally spanned MONWRITE records was
imperfect. Line 005970 was IF (COL-4+MRHDRLEN) GT LENGTH
but should have been (COL-3+MRHDRLEN) and line 006000 was
SKIPTHIS=LENGTH-COL-1 but should have been LENGTH-COL+1.
Thanks to Bob Small, Grumman Data Systems, USA.
Thanks to Mike Masella, G.T.E. Services Corp, USA.
Change 08.243 The test IF X NE 0 may not produce the expected result.
SAS coding If variable X can be missing, the test wil be TRUE. This
Feb 15, 1991 suggests that a (generally) safer algorithm, which does
ensure that X is both non-zero AND non-missing, is to use
the test IF X GT 0 for this purpose. The example below
tested X (an offset to a data field) to ensure that the
FIELD was present in the record:
wrong: IF X NE 0 THEN INPUT @X FIELD $CHAR1.;
right: IF X GT 0 THEN INPUT @X FIELD $CHAR1.;
Because X was in a conditional INPUT statement that had
not been executed, the value of X was missing, but the
NE 0 test (instead of GT 0) executed the INPUT statement
with @X where X was missing! What did SAS do with missing
pointer? For either a zero or missing pointer value in
an INPUT statement, SAS moves the pointer to byte 1 of
the record and beings normal INPUT. There is no problem
with using X GE 0 if you can guarantee that X will be non
missing, and in all instances of its use in MXG it does
have adequate protection. Fields unconditionally input as
PIBn (full binary) can never be missing, but variables
input as PDn and other packed formats can be missing.
Now that I realize GT 0 is safer than NE 0, I will cease
using NE 0. I'll bet this already written up somewhere.
Change 08.242 An MRO CICS transaction in an AOR that is waiting for a
VMAC110 TOR user to type enter will find the AOR transaction's
Feb 14, 1991 IRESPTM=(ELAPSED-WTTCIOTM) will include all of the time
that the AOR was waiting on the (user) TOR, and the time
waiting is captured in the WTIRIOTM, the time that the
AOR was waiting on inter-region communications. As long
as this AOR has no FOR, then all of the WTIRIOTM can be
recognized as "user think time" and should be subtracted
from IRESPTM to capture the "real" internal response time
for this type of AOR transaction. However, if the AOR
waits for any other inter-region communications, such as
and FOR, then the WTIRIOTM would contain ambiguous delay
time. The IRESPTM=IRESPTM-WTIRIOTM; statement could be
added in your EXCICTRN exit; it cannot be added to MXG
code because it might not apply to all CICS installations
and it might not even apply to all CICS regions at an
installation.
Thanks to John Nursey, Commercial Union Assurance.
Change 08.241 Unused.
Change 08.240 Variable R79GTOD was added to all TYPE79xx datasets, as
VMAC79 that timestamp may be needed in analysis.
Feb 14, 1991
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 08.239 If CICS variables are EXCLUDEd (i.e, the CICS MCT has the
VMAC110 EXCLUDE=(DFHaaaa,DFHbbbb) or INCLUDE=(DFHaaaa,DFHbbbb),
Feb 12, 1991 MXG member VMAC110 can be edited and the excluded fields
can be commented out as described in instructions in this
member (FIND occurrence of EXCLUDE and read comments).
The comments suggested using the UTILCICS program in the
MXG library, but you can just as easily look directly at
the EXCLUDE/INCLUDE statements in your MCT to know which
fields to comment out in VMAC110. This change takes note
of that user suggestion, and protected BMSTOTCN & TDTOTCN
variables against "Un-Initialized Variable" messages.
Thanks to Joe Naussbaum, Morgan Stanley, USA.
Change 08.238 Validation of CICS 3.1 statistics records uncovered some
VMAC110 incorrect input formats. In CICFCR, variables A17OPENT
Feb 12, 1991 and A17CLOST were incorrect. Instead of PD4. format, the
four bytes must be read HH PK1. MM PK1. SS PK1. TH PD1.1
and then SS=SS+TH; and A17OPENT=HMS(HH,MM,SS); and this
is repeated for A17CLOST. In CICSLDG, variables LDRFT,
LDGLLT, and LDGTTW were incorrectly input as TU4., when
they are actually CICS internal clock values and must
be INPUT as PIB4.6 and then multiplied by 16 to convert
to seconds. See Technical Discussion in Newsletter 19
for a table of time formats and how to read them.
Change 08.237 A short SMF record can be created by STC's 4400 Silo when
VMACSTC a silo is varied on/off line. STC ZAP L1H00o8 (yes, that
Feb 12, 1991 is two zeros and an alphabetic o) corrects the bad record
that caused MXG to ABEND (INPUT STATEMENT EXCEEDED ...).
The following circumvention fix has been added to MXG so
that it will not fail even with the short record. Lines
022700 thru 023000 now read:
INPUT @21+OFFSMF SMLSFLAG $CHAR1. @;
IF LENGTH GT 26 THEN
INPUT +3 SMLSATID PIB2. @;
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 08.236 Support for Legent's ASTEX ("Automated Storage Expert"
VMACDMON replacement for DASDMON SMF records. A number of new data
Feb 6, 1991 variables have been added to all three datasets. Some of
the variables that were common in all records now exist
only in the DMONDSN and DMONJOB datasets under ASX, but
since MXG now supports either old DASDMON or new ASX SMF
records, these variables are still kept in both places
for compatibility; the ones moved will exist but have
missing values with ASTEX. The following are changed:
New in all three (DMONVOL,DMONDSN,DMONJOB) datasets:
ASXFLAG ='SPANNING FLAG'
ASXFLAG2='SYSTEM*TYPE*FLAG'
ASXFLAG3='AUTHORIZED*FLAG*DASD'
RALBSY -'TOTAL*CON/DISC*OUTBOARD TIME'
RBYCNT ='TOTAL IO-S FOR BYPASSES'
RCCCNT ='TOTAL IO-S FOR CACHE CANDIDATES'
RCFCNT ='TOTAL IO-S FOR CFW'
RDFCNT ='TOTAL IO-S FOR DFW'
RDLCNT ='TOTAL*DFW*LOAD COUNT'
RHTDFW ='TOTAL DASD FAST WRITE HITS'
RHTRD ='TOTAL*READ*HITS'
RHTRDS ='TOTAL READ SEQUENTIAL HITS'
RLDCNT ='TOTAL*LOAD*COUNT'
RNRCYLS ='NR OF CYLINDERS ON THE DEVICE'
RNWCNT ='IO-S THAT WERE NORM WRITES'
ROICNT ='OPTIMIZER INHIBIT IO-S'
RSTCFW ='TOTAL CACHE FAST WRITE HITS'
RTICNT ='TOTAL IOS INHIBIT IO-S'
RXSCNT ='CROSS*SYSTEM*SEEK COUNT'
New in DMONVOL dataset:
RVCACHFL='CACHE*FLAG*HVLFLAG4'
RVCFLAG2='CACHE*FLAG2 '
RVDMTOBJ='DEMOTION*TIME (SECS)*OBJECTIVE '
RVDSNRBA='RBA OF DSN RECORDS'
RVDSNBKS='NUMBER PHYS. BLOCKS FOR DSN RECS'
RVDSNOFF='OFFSET INTO RBA TO 1ST DSN REC'
RVJOBBKS='NUMBER OF PHYS. BLOCKS FOR JOB RECS'
RVJOBOFF='OFFSET INTO BLOCK TO 1ST JOB REC'
RVJOBRBA='RBA OF JOB RECORDS'
RVMXNBR ='DSNRBA'
RVSIIX ='VSAM IMBEDDED*INDEX I-O*COUNT'
New in DMONDSN and DMONJOB dataset:
RPRGMNM ='PROGRAM NAME*ASSOCIATED*WITH DSN'
RTRATME ='TOTAL*INTRA-DSN*SEEK TIME '
Variables removed from all three DMON.... datasets.
RCHCNT ='TOTAL*CACHE*HITS'
RSQRSP ='SUM*RESP*SQUARED'
Variables removed from DMONVOL dataset
RVMXNBR ='LONGEST*NON-BUSY*RESERVE'
Now missing values (ASX only) in DMONVOL dataset:
RFTCNT ='TOTAL*FETCH*IO-S'
RLRCNT ='TOTAL*LONG*RESERVES'
RSEEKTM ='TOTAL*SEEK*TIME'
RSRCNT ='TOTAL*BLDL-FIND*IO-S'
Thanks to Joe Faska, Depository Trust, USA.
Change 08.235 The support to read HSM data sets needed correction for
VMACHSM HSM 2.4 and 2.5. Two occurrences of 177 for offset P2
Feb 6, 1991 changed to 185, and the two occurrences of 297 for P3 are
changes to 405.
Thanks to Milt Weinberger, Information Services International, USA.
Change 08.234 The Hiperbatch counters for VSAM added to the type 64 SMF
VMAC64 record were wrong, because MXG failed to skip over the 3
Feb 5, 1991 undocumented bytes in the record. Change the test for 193
to 196, and insert +3 between INPUT and SMF64SIO.
Thanks to Bob Brosnan, Goldman Sachs, USA.
Change 08.234A Preliminary support for VPD, "Vital Products Data" aka
ADOCVPD NAM, "Network Asset Management" NETVIEW "hardware monitor
EXTYVPDE records" written to SMF (usually) as type 37 containing
EXTYVPDF "VPD" as SUBSYS and SUBTYPE=22. Member IMACVPD sets the
EXTYVPDM record ID MXG expects, and defaults to 37. (If VP writes
EXTYVPDP the record, I would not be surprised to see the value 0!)
EXTYVPDS Seven internal record subtypes, E,F,M,P,S,T and W create
EXTYVPDT seven VPD..... datasets documented in DOCVPD. An extra
EXTYVPDW part of this user contribution is the INFOLOAD member,
IMACVPD which shows how an MXG SAS data set (in this example, the
LOADINFO PDB.VPDPUHAR) can be "loaded" into an INFO/SYS database!
TYPEVPD All seven subtypes have been coded and syntax checked,
VMACVPD but only "P", VPDPUHAR PU Hardware subrecords have been
VMAC37 tested with data records. Member VMAC37 was updated to
Feb 4, 1991 NOT process type 37 records with SUBSYS='VPD'.
Thanks to Bill Border, Apollo Computer Inc, USA.
Change 08.233 "Invalid data for MSOCOEFF in line ..." error and a hex
VMAC7072 dump is printed with MVS/ESA 4.1 type 72 records, but the
XMAC7072 data sets built by MXG are NOT in error. IBM increased
Feb 1, 1991 the width of the MSOCOEFF field from 4 to 8 bytes in
MVS/ESA 4.1 (because sites wanted to set a small value
and the 4-byte EBCDIC value was limited to .001 for the
memory service coefficient) by adding a new 8-byte field
to the end of the record, and putting a zero in the old
4-byte field. Unfortunately, I expected an EBCDIC zero,
but IBM changed the format to binary zeros, causing the
invalid data message. Since MXG went on to then input a
value from the new 8-byte field, MSOCOEFF was correct in
the TYPE72 data set, in spite of the note on the log!
The correction is simple. Change the line now reading:
@OFFWRKC+34 MSOCOEFF 4.
to read:
@OFFWRKC+34 MSOCOEFF ?? 4.
(the ?? added suppresses the error message and the dump
and sets the variable to missing value on invalid data).
Thanks to Ann Slaughter, Airline Tariff, USA.
Change 08.232 The CICS Dictionary utility had misleading titles and was
UTILCICS accidentally altered when CICS 3.1 support was added. The
Feb 1, 1991 report was valid, however.
Thanks to Phil Shelley, Jewish Hospital HealthCare Services, USA.
Change 08.231 VM/ESA testing found an unprotected divide by zero that
VMACVMXA is now corrected in de-accumulation of the user records.
Feb 1, 1991 (It had no impact on the MXG-build data sets, because the
observation causing zero-divide was the first for a user,
and the first record is always deleted). Additionally,
variable VMDELIST is now formatted $HEX2.
Change 08.230 Duplicate Job Name Hold delay time for batch scheduling
ASUMJOBS is now detected and eliminated in this summarization part
Jan 31, 1991 of the MXG Trend Data base that builds the PDB.JOBSKED
data set and calculates IWT (Initiation Wait Time) by
job class. See the MVS Technical Note in Newsletter 19.
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 08.229 SAS 6.06 Compatibility? SAS 5.18 handled "PIB2 ." in
VMXGHSM line 370300, but SAS 6.06 requires the "PIB2." syntax
Jan 31, 1991 (i.e., no blank between PIB2 and its period)!
Thanks to Andrew Davies, TAB of W.A., AUSTRALIA.
Change 08.228 Support for SESAME, a Volvo (Europe) VTAM Monitor, which
EXTYSESA creates an SMF record. This is preliminary support, that
IMACSESA has only been syntax checked after editing this user
TYPESESA contribution to MXG Software. Formats are defined in
VMACSESA FORMATS but are not yet associated with their variables.
Jan 30, 1991
Thanks to Olli Rautajuuri, SAS Institute Oy, FINLAND.
Change 08.227 Support for MEMO, a European Electronic Mailsystem which
EXTYMEMO creates an SMF "accounting" record. This is preliminary
IMACMEMO support, that has only been syntax checked after editing
TYPEMEMO this user contribution to MXG Software. Formats are
VMACMEMO defined in FORMATS but are not yet associated with their
Jan 30, 1991 variables.
Thanks to Pertti Russcanen, Carelcomp Oy, FINLAND.
Change 08.226 Variable PMHTSKID should not have been KEEPed in these
VMACIDMS non-task-related MXG datasets: IDMSARA,BUF,CPM,INS,INT,
Jan 29, 1991 JRL,LNE,PGM,RUS,STG,YPE. Only caused confusion.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 08.225 Support for Landmark's The Monitor for DB2 type 100 & 101
TYPEDB2 records requires a fix from Landmark. ZAP U900266 exists
Jan 29, 1991 now, and that fix will be included in Landmark's planned
maintenance release level ML911, due out this Spring. The
DB2ACCT data is good without that fix, but DB2STAT0/1 are
wrong until the fix is installed. (The statistics record
sequence number was not updated by Landmark, and MXG uses
it to validate the de-accumulation of interval records,
and to detect skipped intervals and multiple startups).
Landmark does not yet write type 102 SMF records.
Change 08.224 Support for MVS/ESA 4.2 (RMF 4.2.1).
EXTY22IO 1.New dataset TYPE22IO reports I/O configuration changes as
EXTY33U1 a result of the ACTIVATE funcation (add, delete, modify)
IMACPDB with these 33 new variables from the new subtype of the
TYPE33 type 22 SMF record:
VMAC6 FORCEOPT='ACTIVATE*FORCE*OPTION?'
VMAC22 SMF22CCH='CHANNEL*PATH*ID'
VMAC26J2 SMF22CFI='OPSYS*CONFIGURATION*ID'
VMAC26J3 SMF22DCH='ARRAY OF*CHPIDS*ADDED OR DELETED'
VMAC30 SMF22DCM='MASK OF*CHPIDS*ADDED OR DELETED'
VMAC32 SMF22DPC='ARRAY OF*PHYS CU-S*ADDED OR DELETED'
VMAC33 SMF22DPM='MASK OF*PHYSICAL CU-S'ADDED-DELETED'
VMAC4345 SMF22DVN='DEVICE*NUMBER'
VMAC7072 SMF22EDT='ID OF*NEW*EDT'
VMAC71 SMF22EFL='ENTRY*FLAGS'
VMAC73 SMF22EHD='ENTRY*HEADER'
VMAC74 SMF22ELN='LENGTH OF EACH ENTRY'
VMAC78 SMF22ER ='ENTRY*TYPE*(MXG FORMATTED)'
Dec 6, 1990 SMF22ERQ='ENTRY*REQUEST'
Jan 28, 1991 SMF22ETY='ENTRY*TYPE'
SMF22FLS='FLAGS'
SMF22FNC='ACTIVATE*FUNCTION*REQUESTED'
SMF22HCT='HARDWARE*CONFIGURATION*TOKEN'
SMF22IDN='DSNAME OF IODF*WITH NEW*I/O CONFIGURA'
SMF22NE ='NUMBER OF ENTRIES IN THIS RECORD'
SMF22NUA='NUMBER OF*UCBS ADDED*FOR THIS CHANGE'
SMF22NUD='NUMBER OF*UCBS DELETED*FOR THIS CHANGE'
SMF22OFF='OFFSET TO FIRST ENTRY'
SMF22PCH='ARRAY OF*CHPIDS*ADDED OR DELETED'
SMF22PCM='MASK OF*CHANNEL PATH IDS*ADD-DELETED'
SMF22PCN='PHYSICAL*CONTROL UNIT*NUMBER'
SMF22PSU='STARTING*UNIT*ADDRESS'
SMF22PUA='RANGE OF UNIT ADDRESSES*ADD-DELETED'
SMF22PUC='COUNT*OF UNIT*ADDRESSES'
SMF22RNR='RECORD NUMBER OF THIS RECORD'
SMF22TNE='TOTAL NUMBER OF ENTRIES FOR THIS CHANGE'
SMF22TR ='TOTAL RECORD NUMBERS FOR THIS CHANGE'
SOFTOPT ='ACTIVATE*SOFT*OPTION?'
2.New variables have been added to the TYPE30_V, TYPE30_4,
TYPE30_5, and TYPE30_6 datasets built from type 30 SMF
records, and to datasets PDB.SMFINTRV, PDB.STEPS and
PDB.JOBS built by BUILDPDB/BUILDPD3. The BUILDPDB change
required modification to member IMACPDB, so that MXG
users with a modified IMACPDB will need to retrofit its
changes onto the new IMACPDB member.
a. Ten new variables describe pages and blocks moved to
and from Auxiliary and Expanded storage for this job
due to the new Blocked Paging enhancements. Variables
in upper case are actual data fields, while lower case
variables are calculated from actual data fields:
Blocks Blocked Unblocked Total
Pages Pages Pages
In from AUX BLKSAUIN PGBKAUIN
In from ESTORE BLKSESIN PGBKESIN PGUNESIN PGTOESIN
In total BLKSTOIN PGBKTOIN
Out to AUX BLKSAUOU PGBKAUOU
Out to ESTORE BLKSESOU PGBKESOU PGUNESOU
Out total BLKSTOOU PGBKTOOU
Type 71 variables: Blocks Blocked Unblocked Total
Pages Pages Pages
In total BLKSTOIN PGBKTOIN
Type 72 variables: Blocks Blocked Unblocked Total
Pages Pages Pages
In from AUX BLKSAUIN pgbkauin
In from ESTORE BLKSESIN PGBKESIN pgunesin PGTOESIN
In total blkstoin PGBKTOIN
c. Eight new variables describing APPC activity by this
address space were added (but the APPC resources are
not currently contained in the subtype 2 & 3 interval
records, so these variables are not kept in TYPE30_V
nor the PDB.SMFINTRV data set):
APPCATR ='TRANSACTIONS*SCHEDULED*BY ASCH'
APPCCN ='TOTAL*CONVERSATIONS*(ACTIVE+DEALLOC)'
APPCCNA ='NUMBER OF ALL*CONVERSATIONS*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'
d. The JCTJOBID field from which TYPETASK and JESNR are
extracted has changed with APPC. Instead of three
characters JOB/STC/TSU follwed by the five digit JESNR
the JCTJOBID will contain an "A" and a seven digit
number, which MXG stores in TYPETASK and JESNR, but
the maximum JESNR is 999,999 because the first of the
seven digits is always a zero. You should check if
any reporting programs use TYPETASK for selection, and
to ensure they are coded robustly so they will not
fail if TYPETASK='A' is encountered. The JCTJOBID
change was not compatibly implemented and changed
VMAC6,VMAC30,VMAC32,VMAC26J2, and VMAC26J3. SMF
records use the fieldname SMFnnJNM for the eight byte
JCTJOBID field. This IBM change in that field could
also affect "banner page" printing code in your SMF
exits.
3.New dataset TYPE33_1 records APPC Transaction Program,
"TP" resources, for each TP work scheduled by ASCH. Each
type 33 is an APPC event, with the same APPC counts that
are totaled in the type 30, above. In addition, times of
receipt, scheduling, and execution of the TP are recorded
as is the CPU times, I/O connect time and EXCP counts for
APPC TPs. This new data is the resource record for APPC,
and will be used instead of the type30s for APPC resource
accounting, performance measurement, etc. The variables
in this data set from the type 33 subtype 1 record are:
ACCOUNTn='ACCOUNT*FIELD* n'
APPCCNAS='CONVERSATIONS*ALLOCATED*BY THIS TP'
APPCCONS='NUMBER OF*CONVERSATIONS*FOR THIS TP'
APPCDARS='BYTES*RECEIVED*BY THIS TP '
APPCDATS='BYTES*SENT BY*THIS TP '
APPCRECV='RECEIVES*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*ACCOUNT FIELD* n '
LOCLLUNM='LOCAL*LU NAME*FOR THE TP'
NRACCTFL='NUMBER*ACCOUNT*FIELDS'
PARTLUNM='NODENAME*LUNAME*OF PARTNER'
QUEUETM ='SCHEDULER*QUEUE*DURATION'
RACFGRUP='RACF*GROUP*IDENTIFICATION'
RACFUSER='RACF*USER*IDENTIFICATION'
REQDTIME='REQUEST*RECOGNIZED*BY FMH-5'
SKEDTIME='REQUEST*PLACED ON*SCHEDULER QUEUE'
SMFTIME ='TIMESTAMP*WHEN RECORD*WAS WRITTEN'
SYSTEM ='SMF*SYSTEM*ID'
TPCLASS ='TP*CLASS'
TPNAME ='TP*NAME'
TPNDTIME='TP*EXECUTION*ENDED'
TPROFILE='TP*PROFILE*NAME'
TPSKEDTY='TP*SCHEDULER*TYPE'
TPSTTIME='TP*EXECUTION*STARTED'
TPUSECNT='USES OF*THIS TP*BY THIS USER'
TPUSRTYP='TP*USER*TYPE'
ZDATE ='ZEE DATE*ZEE OBS*WAS CREATED'
The following time sequence is unvalidated but is thought
to describe the events for a standard TP scheduled event:
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
4.New variables were added to TYPE4345 for JES2 start
options:
CONSOPT ='CONSOLE*OPTION*SPECIFIED?'
LOGOPTN ='LOG*OPTIONS*SPECIFIED?'
QUIKSTRT='JES2 DID*QUICK*START??
RECNFGOP='RECONFIG*OPTION*SPECIFIED?'
5.New TYPE70 variables APPCMIN,APPCMAX,APPCAVG for the min,
max,avg number of APPC address spaces active, and twelve
distribution buckets APPC00 thru APPC11 count the percent
of time when 0, 1-3, ... over 36 APPC address spaces were
active, paralleling the similar set of fifteen variables
for the existing other three types of address spaces for
BATCH, TSO, and STC addresses.
6.New TYPE71 variables count blocked pages in or out, the
PWSS (Primary working set) pages migrated, and the number
of ESTORE frames that were freed without migration:
ESPGFRNO='ESTORE FRAMES FREED W/O MIGRATION'
PGBKtoin='BLOCKED*PAGES*PAGED IN'
PGBKtoou='BLOCKED*PAGES*PAGED OUT'
PWSSMIIN='PWSS PAGES*MIGRATED*FROM ESTORE'
7.Old TYPE72 variable WKLOAD no longer exists.
Eleven new variables, including the long needed new
ESA CPU times, and the ESTORE residency time (which
can be compared with the existing variable ACTFRMTM,
previously discussed in NEWSLTRS member) to estimate
usage of ESTORE frames.
ACTESFTM='EXPANDED*STORAGE*RESIDENCY'
ACTFRMTM='ACTIVE*FRAME*TIME'
BLKSAUIN='BLOCKS*PAGED IN*FROM AUX'
BLKSESIN='BLOCKS*PAGED IN*FROM ESTORE'
CPUHPTTM='HIPERSPACE*CPU TIME'
CPUIIPTM='I/O*PROCESSING*CPU TIME'
CPURCTTM='REGION*CONTROL*CPU TIME'
PGBKESIN='BLOCKED PAGES*PAGED IN*FROM ES'
PGBKTOIN='BLOCKED PAGES*PAGED IN'
PGTOESIN='PAGES*PAGED IN*FROM ESTORE'
SYSTRNTM='SYSTEM*TRANSACTION*TIME'
8.New TYPE73 variables describe IODF name and creation:
CFGCHGFL='SMF73CFL CONFIGURATION CHANGE FLAGS'
CHPADDED='CHANNEL*PATH*ADDED?'
CHPDELET='CHANNEL*PATH*DELETED?'
CHPMODIF='CHANNEL*PATH*MODIFIED?'
IODFNAME='IODF*NAME'
IODFSUFX='IODF*NAME*SUFFIX'
IODFTIME='IODF*CREATION*DATETIME'
9.Type 74 record contains the same fields added to the type
73 listed above, but the variables are NOT kept in TYPE74
because I don't think the 44 bytes of IODF name needs to
be kept in each device segment of MXG's TYPE74 dataset.
If they really turn out to be needed, I will create a new
data set, one per type 74 record, instead of one for each
device. The code is in place, so the variables do exist
and are available in EXTY74, if needed.
_______ _______ ________
|Offset |Offset |Offset | SMF Type 33 APPC/MVS TP Accounting
|to POF |to IOF |to UOF |
|_______|_______|________|
Product Section:
____________________________
| |
POF: | "ASCH", MVSLEVEL |
|____________________________|
TP Identification Section:
_________________________________________________________
|Offset | |
IOF: |to TPO |TP Class, Standard/Multi-Trans, TP Profile Name |
|_______|_________________________________________________|
\
\
\
\ TP Program Name Section:
\ _______ _______________________________
| | |
TPO: | Len |TP Name (up to 64 characters) |
|_______|_______________________________|
______________________
/ \
TP Usage Section: / \
_______________ _______ _________ _______ \
| |Offset | |Offset | /
UOF: |RACFUSER,GROUP |to AOF |Usecount |to TDO | /
|_______________|_______|_________|_______| /
/ /
/ /
/ /
/ /
_________________/ /
/ /
/ TP Usage Accounting Section:
/ ______ __________________
/ | |Accounting fields |
/ AOF: | Len |(up to 175 char) |
/ |______|__________________|
/
/
/
TP Usage Detail Section
_______ ___________________________________________
|Offset | |
TDO: |to TSO | Sends,received,data,conversations,TCB,SRB |
|_______|___________________________________________|
\
\
\
\ TP Usage Scheduler Section
\ _____________________________
| |
TDO: | LLU, PLU, Four Time Stamps |
|_____________________________|
10.Type 78 record contains the same fields added to the type
73 listed above, but the variables are NOT kept in TYPE78
because I don't think the 44 bytes of IODF name needs to
be kept in each subtype 3 segment. See above note.
Change 08.223 Deaccumulation of EXCP count from type 14/15 records by
ANALDSET this MXG analysis routine did not handle concatenated PDS
Jan 25, 1991 libraries, noticibly causing JES2 job's PROCnn DDNAMES to
have incorrectly high EXCP counts in this analysis. The
BY list in lines 017300 and 017600 should have had the
variable DSNAME inserted between DDNAME and UNITADR:
BY SYSTEM READTIME JOB STEP DDNAME DSNAME UNITADR SMFTIME;
Thanks to Lee Hollis, Lowe's Companies, Inc, USA.
Thanks to Dee Ramon, Mutual of America, USA.
Change 08.222 Default SMF record IDs in IMAC.... members for User SMF
IMACWSF records are intended to all be 512 (an impossible value)
Jan 25, 1991 but some IMACs slipped into the library with a different
value; if your site had a record of that value, the test
of JCLTEST could cause an "INPUT STATEMENT EXCEEDED "
STOPOVER condition. All IMACs for User SMF records now
have the value of 512, as they should have all along!
Thanks to Glenn Hanna, Textron Defense Systems, USA.
Change 08.221 SAS 6.06 Compatibility. Mixed case from PUT function.
MONTHBLD The DAY=PUT(TODAY,WEEKDATE3.); may create mixed case in
Jan 25, 1991 the character variable DAY under SAS 6.06, depending on
several SAS 6.06 options; the first letter is upper case,
while the second and third letters of the name of the day
are lower case. Since the subsequent test is for caps,
the test fails. Line 005200 is now replaced with
DAY=UPCASE(PUT(TODAY,WEEKDATE3.));
to force DAY to be uppercase, independent of the sites
options for case.
Thanks to Barry Lampkin, Blue Cross Blue Shield of Mass., USA.
Thanks to Debora Reinert, Nordstrom, Inc, USA.
Change 08.220 DCOLLECT variable DCDBKLNG should have been multiplied
VMACDCOL by 1024 (like the other adjacent values) to convert to
Jan 25, 1991 bytes for printing by the MGBYTES format.
Thanks to David Stern, CSX Technology, USA.
Change 08.219 Hiperbatch statistics added to the TYPE64 data set were
VMAC64 not kept in the correct dataset. The line containing
Jan 24, 1991 the six new variables was mis-located in the keep list
for TYPE64X (which is output before the variable are
input) instead of the correct keep list for TYPE64.
Variable JFCBDSNM was spelled incorrectly as JCFBDSNM.
Thanks to Michael Enad, Dun and Bradstreet, USA.
Change 08.218 Validation of PreRelease uncovered minor corrections.
IMACPDB 1.Line 029800 in IMACPDB should be _FREQ_ vice _FREQ
IMACACCT (but no error was set as _FREQ_ only exists in 6.06
VMAC110 and the missing underscore only caused _FREQ_ to be kept.
Jan 21, 1991 2.Comments in IMACACCT were enhanced to suggest that the
unwanted LENACCTn variables should also be dropped, and
that meaningless SAS "393" warnings print on the log.
3.CICS 3.1 processing was not protected for an unexpected
Statistics subtype. It did not fail, but the messages
produced were unclear. Now it is protected.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 08.217 Support for Candle's EPILOG for MVS Version 300 SMF "type
EXEPMEP 180" data record is added by this user contribution.
EXEPMIO Three EPMV.. data sets are created:
EXEPMEQ EPMVEP - The fixed workload information and the wait
IMACEPMV statistics for the two kinds of workloads,
TYPEEPMV PG (perf groups, periods, total sys), and
VMACEPMV AS (TSO, JOB, STC). Variable SM180SUB shows
Jan 16, 1991 which of the 10 subtypes created the record:
TOTS - all perf groups combined
PGN - all periods of a perf group
PGP - a single period of a perf group
BAT - end of step for batch address space
TSO - end of step for TSO address space
STC - end of step for STC address space
bat - end of interval for batch ASID
tso - end of interval for TSO ASID
stc - end of interval for STC ASID
RSRC - EPILOG captured data (not from RMF)
EPMVEPIO - I/O counts for each device with counts.
EPMVEPEQ - ENQ counts for each major name with counts.
Thanks to Billy Westland, Candle Corporation, USA.
Thanks to John Ebner, Litton Computer Services, USA.
Change 08.216 Both SIO73CNT and SIO78CNT are missing in RMFINTRV for a
RMFINTRV 4381/3090/ES9000 processor, because I/O counts moved into
Jan 16, 1991 different records for different processors and software.
Mar 13, 1991 Insert after line 070200
DATA TYPE78; SET PDB.TYPE78;
(so a PDB can be on tape), and expand the SET statement
in line 070400 to read:
SET TYPE73P TYPE78 (IN=IN78) PDB.TYPE78IO (IN=IN78IO);
and insert new line after 070700:
IF IN78IO THEN SIO73CNT=IOPACTRT*DURATM;
to now populate variable SIO73CNT to contain total SSCH
count to all channels from the appropriate data set.
Thanks to John McDonald, Arizona State University, USA.
Change 08.215 If only DB2 Report PMLOK03 was requested, a 309 error is
ANALDB2R received. Line 076980, variable QW0054AI should have
Jan 16, 1991 numeric 0's instead of alphabetic o's. Line 077020,
variables MINTIME and MAXTIME need to be added to that
RETAIN statement.
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 08.214 "INVALID THIRD ARGUMENT TO FUNCTION SUBSTR" error message
VMAC6156 from syntax WANT6156=INPUT(SUBSTR(SYSPARM(),10,7),7.);
Jan 15, 1991 when the SYSPARM value is less than 17 characters. This
soft error can be eliminated by storing the value of the
SYSPARM() function into a variable, because SAS sets that
variable's length to 200 bytes. The variable is then used
in place of the subsequent SYSPARM() references. Lines
012200 thru 012600 now read:
IF WANT6156=. THEN DO;
SYSPARM=SYSPARM();
IF SYSPARM EQ: 'TYPE6156-' THEN
WANT6156=INPUT(SUBSTR(SYSPARM,10,7),7.);
ELSE WANT6156=-1;
RETAIN WANT6156;
END;
Apr 1 update. Now I find out from SAS that this message
only occurs in SAS 6.06 if ZAP Z6060627 was installed,
and that zap is now marked REMOVED by the Institute).
But I'll leave my robust circumvention in place!
Thanks to Debbie Matic, Commercial Union Assurance of Canada, CANADA.
Change 08.213 This example shows how new-style macros can be used in
Book place of the old style _DAY macro and INSTREAM DD.
Jan 15, 1991 The example in the Chapter 35 to copy the DAY PDB into
the correct "Day-of-Week" PDB uses a temporary dataset
(pointed to by the INSTREAM DDname), and writes out an
old-style MACRO named _DAY that contains the character
name of the day of the week, which is then used as the
DDNAME into which the daily PDB will be copied. That
example has been updated and commented below:
//INSTREAM DD UNIT=SYSDA,SPACE=(TRK,(1,1))
OPTIONS NOTITLES;
DATA _NULL_ ;
FILE INSTREAM NOPRINT RECFM=FB LRECL=80 BLKSIZE=8000;
TODAY=TODAY()-1; /* get yesterday's date */
WEEKDAY=' ';
WEEKDAY=PUT(TODAY,WEEKDATE3.);
PUT 'MACRO _DAY ' WEEKDAY $CHAR3. '%' ;
RUN;
%INCLUDE INSTREAM; /*read macro just created*/
PROC COPY IN=DAY OUT= _DAY;
Some users have been directed by SAS technical support to
replace the old-style substitution macro with the %MACRO
facility. One recommended implementation is:
DATA _NULL_;
TODAY=TODAY()-1;
DAY=UPCASE(PUT(TODAY,WEEKDATE3.));
CALL SYMPUT('_DAY',DAY);
PROC COPY IN=DAY OUT=&_DAY;
More later.
Change 08.212 This change deletes MXG member XMACEPIL and puts support
VMACEPIL for EPILOG CL1000 back in member VMACEPIL. Change 8.019
XMACEPIL was applied to member XMACEPIL, which was then copied in
Jan 14, 1991 to VMACEPIL. It is believed to support 4.4.0, 4.5.0, and
4.5.1 versions, but test data is not at hand.
Change 08.211 New variable INVOKSAS in TYPESYNC dataset from user SMF
VMACSYNC record produced by SYNCSORT now identifies if this SORT
Jan 14, 1991 was invoked by the SAS System. Note that SYNCSORT's
enhancement PTF number EW2903 must have been installed by
your SYNCSORT installer before this field will be "Y".
Change 08.210 DCOLLECT migration/backup tape data sets datetime values
VMACDCOL UMTIME or UBTIME were wrong. Both occurrences of JULDATE
Jan 14, 1991 must be changed to DATEJUL (lines 037800 and 040000).
In addition, the value written in the record by IBM is
apparently wrong itself, until you install APAR OY37378.
Thanks to Derek Cespedes, Florida Power and Light, USA.
Change 08.209 TSO/MON variable READTIME is missing in PreReleases 8.3
VMACTSOM thru 8.7. Change 8.104 to correct CA7 corruption of the
Jan 14, 1991 first byte of Reader Date worked ONLY if for corrupted
records; normal, non-CA7 records produced missing values.
In line 040110, remove the DO; and delete line 040130
(containing END;) so that READTIME is always created by
the INPUT function.
Thanks to David B. Adams, National Life of Vermont, USA.
Change 08.208 IBM SMF APARs have added new data fields.
VMAC23 1.SMF now flags when the CPU timer goes bad in a new field
VMAC30 in the type 30 timer section. APAR OY24857 applies.
Jan 12, 1991 New variable CPUERROR (which was formerly a reserved
field) will have hex 0000 (APAR not installed), hex 8000
(APAR installed, no error). The subsequent bits are on if
the corresponding CPU measurement value (there are now
seven CPU measures) was defective and set to zero in this
record. The APAR also eliminates an OC9 ABEND of SMF.
2.SMF now flags a step cancellation due to NOT CATLG 2 or
NOT CATLG 7 condition (one bit for both reasons), but
only if the installation specified JOBFAIL(YES) in ALOCXX
SYS1.PARMLIB member (which ABENDs the NOT CTLG JOB). APAR
OY38977 applies. IBM's bit 11 of SMF30STI is used, and
MXG ABEND will contain NOTCTLG if the step was cancelled
due to NON CATLG condition. In addition, new variable
TERMIND contains all 16 bits of the step/job indicator
for detail examination in your programs, if needed.
3.SMF type 23 record (buffer statistics) is expanded to
better describe the SMF writer's use of its memory. APAR
OY27449 applies. New variables created in TYPE23 dataset:
CURALLOC='SMF BUFFER*CURRENT*ALOCATION'
HWMALLOC='SMF BUFFER*HIWATERMK*ALLOCATION'
MAXBUFSZ='BUFFER*MAXIMUM*LEVEL'
MVSLEVEL='MVS*SOFTWARE*LEVEL'
PERALLOC='INCREMENT*PER EACH*ALLOCATION'
WRNBUFSZ='BUFFER*WARNING*LEVEL'
Change 08.207 MXG 8.7 only. Several test sites noted that //SOURCLIB DD
JCLTEST6 JCL statement was missing from the FORMATS step, and the
Jan 12, 1991 SMFSMALL step's //SYSIN DD DSN=MXG(UTILGETM) was replaced
with a //SYSIN DD * statement and a %INCLUDE.
Change 08.206 SAS 6.06 Compatibility, only in MXG PreReleases thru 8.7.
UTILGETM The UTILGETM program, used only during installation of
Jan 12, 1991 MXG (to build a small SMF file for testing), will put SAS
6.06 (even at the October maintenance level) in a 100%
CPU Busy loop, causing a System 322 ABEND. The error is
in the processing of the %VMXGVBS macro which was added
by MXG Change 8.174. This macro generates different DCB
attributes for the FILE statement (CMS can't create VBS)
so new MXG users under CMS did not die during testing.
The %VMXGVBS macro added to UTILGETM was almost exactly
the same as the %VMXGLRC macro for the INFILE statement
in the _SMF macro. The differences were that %VMXGVBS
sets only the LRECL parameter of the INFILE SMF, while
%VMXGVBS sets LRECL, DCB, and BLKSIZE options, and that
their references were located in different positions in
their respective INFILE and FILE statements. Over 50 runs
322 ABENDed before the %MACRO compiler error was found to
be circumvented when there is a "parameter=value"syntax
preceding the %VMXGVBS invocation. Adding COL=COLOUT to
line 01900 in UTILGETM circumvents the loop. This works:
FILE SMFOUT COL=COLOUT %VMXGVBS;
This didn't:
FILE SMFOUT %VMXGVBS;
SAS Institute now knows the loop occurs only a %MACRO on
a FILE or INFILE statement (and also only if the %MACRO
itself starts with %IF), and are working on the problem.
SAS Zap Z606xxxx, available Month dd,yyyy corrects this
error in the SAS 6.06 %MACRO compiler. Tracking 163046.
Thanks to Barry Lampkin, Blue Cross Blue Shield of Mass., USA.
Thanks to Grady Tart, McM Information Services, Inc, USA.
Change 08.205 PreRelease 8.2 thru 8.7 only. The label for CPUTCBTM may
VMAC110 say "SUM OF THREE CPU TCB TIMES", but it is still the
Jan 11, 1991 CPU TCB TIME. (The CICS 3.1 support label overrode the
original label).
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 08.204 DB2ACCT variable QXNSMIAP was misspelled as QXMSMIAP. The
ANALDB2R correct variable QXNSMIAP was added by this change, but
VMACDB2 the original variable is also kept so that any reports
Dec 20, 1990 that you've written won't fail. Please correct in your
report programs and eventually QXMSMIAP will be dropped.
Thanks to Ron Root, Oryx Energy Company, USA.
---Changes thru 8.203 were included in MXG PreRelease 8.7 Dec 18, 1990--
Change 08.203 WSF2 record from RSD newest version 3.3.4 has a section
VMACWSF mis-located two bytes to the right and truncated at the
Dec 17, 1990 end. However, MXG code had not been validated with a real
record from that version, and a nine-bit bit test only
failed when actually executed, and the overlay of two
fields in the WSF2 DSECT was missed in MXG coding. The
two MXG oversights were corrected, and the logic was
expanded to support both the correct and incorrect record
format. Until maintenance exists from its vendor, the
value of ACCNPELT will be incorrect, and usually zero.
Thanks to Dennis Mahlubam, Aetna Life & Casualty, USA.
Change 08.202 MXG didn't calculate converted RMF data (3.5.1 to 4.1.1).
VMAC79 The equation for R791FMCT in line 027800 should be
Dec 16, 1990 ELSE R791FMCT=R791RSV1 + R791RSV2;
Note R791WSS is missing here, since SMF79ASL is only 60.
Thanks to Miller Dixon, Continuum, USA.
Change 08.201 -VM/XA Monitor records appear to have an IBM error. In the
VMACVMXA VXUSEINT record the HFQUCT (Hi Freq Sample Count) resets
Dec 16, 1990 itself erratically. MXG tries to capture the CPU time a
VM machine used between a logon and the end of the first
interval, and used HFQUCT in that heuristic algorithm.
However, that logic is now invalidated by this IBM reset
and the user interval record is no longer output when a
logon event is detected. The actual change was to
comment out the two lines "IF NOT (FIRST.BEGINMTR OR
FIRST.VMDUSER OR FIRST.VMDCPUAD) THEN OUTPUT;"
until HFQUCT can be corrected by IBM.
Perhaps someday, IBM will provide the long-requested
flag in the user sample record so the time from logon
to end of interval can be captured safely.
-An unrelated change was made to better format the notes
MXG writes to the log when operator commands are found.
Additionally, the command variable CALCMD is now length
200 in all kept data sets.
Thanks to Procter & Gamble, BELGIUM.
Change 08.200 IMS Log type 35x with ENQFLAG=0Cx and FLAG2=40x is now
VMACIMS output in the IMS35P record. This is the last reported
Dec 16, 1990 record subtype that was not output in TYPEIMS processing.
Thanks to Magnus Jansson, DAFA Stockholm, SWEDEN.
Change 08.199 SAS 6.06 Circumvention discussed in Changes 8.078 and
ANALDB2R 8.059 were not propagated into all reports in ANALDB2R.
TESTANAL The default set of ANALDB2R reports were changed, but in
Dec 16, 1990 lines 028780 and 45960 the commas after AUTHCHG UTILITY
and OUTCODE=DROP DATETIME; must be removed. The fourteen
occurrences of " .T102" must be changed to " . T102", and
two " .DB2" must be changed to " . DB2". MXG testing of
%ANALDB2R by member TESTANAL was corrected to now invoke
and test all 27 of the DB2 reports.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 08.198 ACF2 variable ACLFLDVB could raise "Invalid Data" note.
VMACACF2 Line 052900 (the only occurrence of PK4.) should end with
Dec 7, 1990 "ACLFLDVB ?? PD4. @;" instead of "ACLFLDVB PK4. @;"
Thanks to Rachel Bromage, L.O.L.A., ENGLAND.
Change 08.197 Unused.
Change 08.196 Unused.
Change 08.195 Change 8.056 had not been installed in PreReleases. Lines
VMACSYNC 023800 and 024800 should now read SIRFM ?? 1. and
Dec 4, 1990 SORFM ?? 1. respectively.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 08.194 Validation of the STC Silo HSC 1.1.0 SMF Record uncovered
VMACSTC an MXG coding error that caused STOPOVER. Line 034600
Dec 3, 1990 should input STC07TNM PIB1. (instead of PIB4.).
Thanks to Leslie Dixon, Santa Fe Energy Resources, USA.
Change 08.193 VMXGVTOF is a modification of VMXGVTOC that will read the
VMXGVTOF output of ASMVTOC (the "Fast VTOC Reading program") and
Dec 3, 1990 will create the same datasets (VTOCLIST,VTOCMAP,VTOCINFO)
that were created by the slower VMXGVTOR/VMXGVTOC pair.
Note that VMXGVTOF replaced the (temorary) MPXGVTOC that
was introduced in Change 8.117.
Thanks to Jeff Fox, SKF, USA.
Change 08.192 Reserved Change Number.
Dec 2, 1990
Change 08.191 This contributed member estimates processor storage
ANALSTOR requirements based on techniques taught by IBM's
Nov 29, 1990 "MVS/ESA Subsystem Analysis: Processor Storage
Estimation" seminar taught by the South Western
Area Systems Center. The two step process suggested
first measures current usage based on RMF type 71 and
type 79 ASD records and second estimates the real and
expanded storage needed for zero paging (or very close
paging) taking under consideration future workload
growths. This analysis program accomplishes only the
first step, and provides a program to report the
current usage based on this IBM methodology.
Thanks to Miller Dixon, Continuum, USA.
Change 08.190A The original author of the support for Arbiter SMF
EXARB404 records (from Tangram product) has updated the code
EXARBC01 to support changes in Version 2.1.1 of that product.
EXARBC02 Three new data sets are created.
IMACARB
VMACARB
Nov 29, 1990
Thanks to J-P Tonnieau, GMF System Team SARAN, FRANCE.
Change 08.190 VMXGVTOC produces a single "error" message,
VMXGVTOC POINT=1 NOBS=0 POINTER=. VOLSER= DSNAME= ...
Nov 28, 1990 that has no real effect, that will disappear if you move
the SET statement (line 063700) to after the STOP
statement (line 063800).
Thanks to Magnus Jansson, DAFA Stockholm, SWEDEN.
Change 08.189 The POINT= operand of the SET statement cannot be used
ASUMCICS for a dataset on tape under SAS 6.06. We used it under
Nov 27, 1990 5.18, but it turns out that 5.18 documentation said that
it couldn't be used for tape! POINT= and NOBS= were used
to determine transparently which CICS dataset (CICSTRAN
or MONITASK or both) was to be summarized. The logic has
been redesigned to make the same determination without
the POINT= operand, so tape datasets can be used.
Thanks to Bob Grant, Gold Bond, USA.
Change 08.188 The final RETURN; statement was after the END; statement,
VMACHSM which caused no problem as long as HSM SMF record was
Nov 27, 1990 processed by itself; adding VMACHSM to BUILDPDB caused
subsequent data sets to be not output! The RETURN; is
now moved inside the END; statement.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.187 Hitachi processors using MLPF (their PR/SM or MDF) can
VMAC7072 mix dedicated and shared processors in the same LPAR,
Nov 27, 1990 but MXG did not protect for that possibility and the
CPUWAITM in the TYPE70 was incorrect (but the individual
CPUWAITn variables were correct). This change expanded
the logic for Dedicated processors to re-calculate the
CPUWAIT variable across both dedicated and shared CPUs.
Thanks to Matthew Bakulich, Crowley Maritime, USA.
=========Changes thru 8.186 were printed in Newsleter EIGHTEEN==========
Change 08.186 PreReleases 8.2 thru 8.5, JES 3 BUILDPDB, line 044500
BUILDPD3 added variables JINLTIME and JSRTTIME to the LENGTH
Nov 16, 1990 statement but left out the "8" before the semicolon.
Thanks to Phil Waters, Arthur Andersen, Bristol, ENGLAND.
Change 08.185 PreRelease 8.3 thru 8.5 had an extra debugging statement
VMACDB2 "IF QWHSTYP GT 2 THEN PUT QWHSTYP= Z=;" after the @; in
Nov 16, 1990 line 165000 which should have been removed. Other than
possibly filling your log, there was no real problem.
Thanks to Ron Allison, UDSI, USA.
Change 08.184 PreRelease 8.5 could fail with a STOPOVER due to SMF
VMAC57 type 57 (only with MVS 4.1) because of typographical
Nov 15, 1990 errors in Change 8.167. Line 009700 should be
IF LEN GE 116 THEN instead of GE 16 and line 009800
should be INPUT @101+OFFSMF instead of @100.
Thanks to Bob Malitz, United Parcel Service, USA.
Change 08.183 PreRelease 8.5 needed minor tuning of Landmark TMON/CICS
TYPEMON8 Version 8 support. The division by TCINPRCN for long
Nov 15, 1990 running mirrors needed zero-divide protection.
Change 08.182 The CICS 3.1+ Statistics records are now combined into
BUILDPDB _CICNTRV.CICINTRV by new member CICINTRV which is now
BUILDPD3 automatically included in BUILDPDB/3 and TYPE110. The
CICINTRV CICINTRV data set merges the interval "INT" records from
IMACCICS statistic data sets, and the original CIC..... datasets
TYPE110 remain in the work file. CICINTRV is a major enhancement
Nov 14, 1990 for CICS 3.1 analysis, and logically is a replacement for
the non-existent CICSYSTM. Note that if no "INT" records
exist (which would happen if only "EOD" was requested),
there will be no observations in CICINTRV. These nineteen
CICS Statistics datasets are merged together to create
the CICINTRV interval statistics dataset:
CICAUTO CICDMG CICDQG CICDQT CICDS CICDTB
CICFCT CICLDG CICM CICSDG CICSMDSA CICST
CICTC CICTCT CICTDG CICTM CICTSQ CICTST
CICVT
Change 08.181 Boole & Babbage IMF product record for IMS chained
TYPECIMS transactions contain the ARRVTIME of the original
Nov 14, 1990 transaction in the subsequent records, causing the input
queue time to be too long. This contributed fix adds the
logic to sort and reprocess the IMS.TRANSACT datasetand
resets ARRVTIME to the ending time of the preceding
transaction in each chain.
Thanks to David Daner, Sun Refining and Marketing, USA.
Change 08.180 IMS Response Mode Transactions are now identifiable
VMAC110 with new variable RSPMODTR added to IMSTRAN dataset.
Nov 14, 1990
Thanks to ???, CED BORSA, ITALY.
Change 08.179 CICS Type 110 variables DSAHWMK, PROGCOMP, PROGSTOR,
VMAC110 STORHWMK, and STORHWMH all measure bytes, but their
Nov 14, 1990 units ranged from bytes, to doublewords to pages. Now,
all are converted to bytes and formatted with MGBYTES
format for consistency and clarity. (MGBYTES prints
100K, 200M, etc, scaling bytes to the appropriate range.)
Thanks to Elisabeth Jensen, Aetna Life and Casualty, USA.
Change 08.178 IMS Log processing algorithms enhanced in MXG 8.3 arenow
VMACIMS corrected for two conditions that had occasionally caused
Nov 11, 1990 INPQUETM and RESPNSTM to be appreciably wrong. The first
change affected 21 transactions, the second affected 134
transactions, out of a total of 368,000 transactions!
1.IMS Log 35x records with ENQFLAG=0Cx and FLAG2=0Cx did
not decode correctly, which caused RESPNSTM to be very
large in a very small number of transactions.
Near line 070600, after line
IF FLAG2='...1.....'B THEN LOC=LOC+2;
insert the following new line:
ELSE IF FLAG2='00001100'B THEN LOC=LOC+4;
This has been validated only for IMS 2.2, but it should
apply also for both 2.1 and 3.1. One of the big logic
problems in MXG support of the IMS log is the decoding of
the 35x records. IBM does not describe all of the bit
values for ENQFLAG, and each combination of ENQFLAG/FLAG2
must be experimentally determined to be an input, output,
message, or program-to-program enqueue event. MXG notes
on the log "LCODE 35X NOT OUTPUT ENQFLAG= FLAG2=" when
unknown values are found, and deletes the record. Values
of 0C/40, 2F/80, 2F/88 have been reported and are thought
to be output enqueue (and hence non-critical to delete).
It appears that FLAG2 must contain the '04'x bit on for
the enqueue to be for input.
2.The logic added in PreRelease 8.3 to reset ARRVTIME when
it was missing was correct and did correct problems by
sorting correctly. Out-of-time-sequence 01/03x records
were also reset by the 8.3 change, and seemed to work for
many transactions, but when the transaction's 35x record
was also out of time sequence, the change overcorrected,
and the INPQUETM and ENQTIME were wrong.
Near line 025600, change the test which read
IF ARRVTIME=. or ARRVTIME LT LASTTIME THEN ARRVTIME=....
to now read
IF ARRVTIME=. THEN ARRVTIME=LASTTIME-.001;
Thanks to J. Cary Jones, Philip Morris, USA.
Thanks to T. H. Witt, Oscar Mayer Food Corp, USA.
Thanks to Magnus Jansson, DAFA Data AB, SWEDEN.
Change 08.177 -CICS/ESA 3.1 transactions accessing DL/I databases with
IMACICDB DBCTL can contain (optionally) a 256-byte segment with
IMACICDL clocks and counters for the CICS-caused DL/I activity.
IMACICUS (DL/I counters from the IMACICDL member can also exist,
UTILCICS but contain DL/I counts only for Local DL/I). Enabling
VMAC110 the DBCTL data is described in the Customization Guide.
Nov 11, 1990 Previously, the transaction record consisted of a static
segment, the optional local DL/I segment, the optional
user counters/clocks, and then ended with the optional
user character field. Since the character field (often
used for application data, account number, etc.) was at
the end of the transaction record, MXG simply read the
rest of the record into USRSTRNG, and then truncated the
data into the kept variable USERCHAR, whose length you
specified with the LENGTH statement in member IMACCICS.
With the restructured CICS 3.1 record, however, you must
now also set the variable USRCHRLN in IMACICUS to tell
MXG how many bytes of character data is to be read into
USRSTRNG so that the DBCTL data can be read; the order in
CICS 3.1 is static, Local DLI, User clocks/counters, user
character string, and DBCTL segment, when the new EMP is
added after your existing MCT calls.
The new IMACICDB member decodes the DBCTL fields when
you remove the comment block (just like IMACICDL did for
local DL/I). The actual DBCTL segment is 256 bytes, but
only 158 bytes are currently used by IBM, and they create
these 34 new variables (only if IMACICDB is changed);
STATBFWT='WAITS FOR*DEDB*BUFFERS'
STATDATN='SCHEDULE*COMPLETED*TIMESTAMP'
STATDATS='SCHEDULE*STARTED*TIMESTAMP'
STATDBIO='DATABASE*I/O-S'
STATDECL='DEDB*CALLS'
STATDERD='DEDB*READ*OPERATIONS'
STATDLET='DATA BASE*DELETES*ISSUED'
STATEXDQ='EXCLUSIVE*DEQUEUES'
STATEXEQ='EXCLUSIVE*ENQUEUES'
STATGHN ='DATA BASE*GHN CALLS*ISSUED'
STATGHNP='DATA BASE*GHNP CALLS*ISSUED'
STATGHU ='DATA BASE*GHU CALLS*ISSUED'
STATGN ='DATA BASE*GNP CALLS*ISSUED'
STATGNP ='DATA BASE*GNP CALLS*ISSUED'
STATGU ='DATA BASE*GU CALLS*ISSUED'
STATINTC='WAIT TIME*INTENT*CONFLICT'
STATISRT='DATA BASE*INSERTS*ISSUED'
STATMSCL='RESERVED*FOR*FAST PATH'
STATNPSB='PSB*NAME'
STATOVFN='OVERFLOW*BUFFERS*USED'
STATPOOL='WAIT TIME*FOR POOL*SPACE'
STATREPL='DATA BASE*REPLACES*ISSUED'
STATSCHT='SCHEDULE*PROCESSING*DURATION'
STATTENQ='TEST*ENQUEUES'
STATTLOC='PI*LOCKING*DURATION'
STATTMIO='DATABASE*I/O*DURATION'
STATTOTC='TOTAL*DL/I*CALLS'
STATTSDQ='TEST*DEQUEUES'
STATUENQ='UPDATE*ENQUES'
STATUOWC='UNIT-OF-WORK*CONTENTIONS'
STATUPDQ='UPDATE*DEQUES'
STATWEXQ='WAITS ON*EXCLUSIVE*ENQUEUES'
STATWTEQ='WAITS ON*TEST*ENQUEUES'
STATWUEQ='WAITS ON*UPDATES AND*ENQUEUES'
-Unrelated, but discovered in this phase of testing, the
%VMXGFOR macro references inside old style macros, in the
UTILCICS dictionary-reading utility were corrected to now
contain double percent signs and titles were clarified.
Thanks to Hamid Tavakolian, Continuum, USA.
Change 08.176 IMS 3.1 DBCTL Thread Type transactions have zero for the
TYPEIMS value for NMSGPROC, causing them to be lost. There were
VMACIMS two errors in MXG logic. First, the setting of PROGTYPE
Nov 9, 1990 from PTYPE values 3, 4, and 5 (for D, Q, and R), near
line 038500 in VMACIMS should have been 4, 8, and 128.
Second, the tests in TYPEIMS for PROGTYPE='B' near line
024400 and 038700 are expanded to protect for DBCTL:
IF PROGTYPE='B' OR PROGTYPE='D' NMSGPROC EQ 0 THEN DO;
Thanks to Hamid Tavakolian, Continuum, USA.
Change 08.175 Landmark's TMON/MVS release 1.11 was supposed to become
EXTMVTR release 1.12, but it is now in managed availability as
EXTMVTRS release 1.1, with two new data records and some changes.
EXTMVWK -In LMRKREC="SY" section, insert a line with +4 after
EXTMVWKP SYSMDL $CHAR2., change SYSTSO1P PIB4.2 to PIB4.4, and
IMACTMVS delete the line with +4 after SYSPDT is read in.
TYPETMVS -Logical data records can span physical blocks, and the
VMACTMVS spanning can split fields! Thus far, only the I/O data
Nov 9, 1990 records have been found to be spanned. For example, with
Nov 28, 1990 552 I/O devices, an interval's logical record contains
41,400 bytes of data (plus headers), but is written in
three blocks of 13844 bytes each. Part of a field is at
the end of the first block, with the rest of that field
continued in the 33rd byte of the second block! There is
only one way to handle these non-standard records that
can exceed 32760 bytes, and that requires the use of an
Infile Exit to the SAS System. Fortunately, the Infile
Exit named TMON that is supplied by MXG for compressed
Landmark CICS records has been modified to support either
compressed and/or spanned record processing! The member
EXITMONI, however, only works under SAS 5.18.
In Newsletter EIGHTEEN, I thought we would also change
the 6.06 exit, and added member EXITMON6 in preparation
for its modification, but it turns out that SAS 6.06
itself will need modifications before the infile exit
can be redesigned. Thus EXITMON6 only supports the
decompression of Landmark records under SAS 6.06; the
EXITMONI member does both decompression and unspanning
but only under SAS 5.18.
Follow the instructions in the EXITMONI member, build
the TMON exit, and then edit new member IMACTMVS to tell
MXG that you have installed the Infile exit. Note that
this modified TMON exit will process either TMON/MVS or
TMON/CICS records. If you have not installed the TMON
exit and MXG finds spanned TMON/MVS records, the bad data
record will now be deleted and so noted on the log; prior
to this change, TMON/MVS spanned records cause STOPOVER.
3.Four new datasets are built, two each from the TR and WK
records. TMVSTR contains the Tape Record statistics, and
TMVSTRS contains one observation for each tape drive in
a TR record. TMVSWK contains the "static" variables in
the WK record, and TMVSWKP contains one observation for
each period of each performance group in the WK record.
4.Further validation added JIJNAME to TMVSJIST, corrected
labels for IOELDNRP,PSMAXSU,PSMINSU, and changed the
INPUT for SYSWTIME from PIB8.6 to MSEC8.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 08.174 This change should be transparent. It permits MXG to be
VMACSMF used for SMF record processing either under CMS or OS
UTILGETM versions of SAS, by using a new %MACRO to set the values
Nov 9, 1990 of RECFM and LRECL differently when MXG is exeuted under
CMS SAS than when MXG is executed under MVS SAS.
(Previously, CMS users had to EDIT these changes.)
UTILGETM was also expanded for both environments to look
for additional subtypes in creating the SMFOUT file.
Under CMS, VBS records can only be read, not written, and
they cannot have LRECL greater than 32756. Furthermore,
RECFM=VB is not supported for output; only RECFM=V
records can be created (CMS SAS accepts RECFM=VB syntax
but actually creates RECFM=V records). With this change,
execution under CMS causes the _SMF macro used for SMF
input to specify RECFM=VBS,LRECL=32756, and the UTILGETM
output spec will be RECFM=V,LRECL=32756,BLKSIZE=32760.
Additionally, since the SAS JFCB= option of the INFILE
statement does not function under CMS, variable SMFJFCB
is now protected to eliminate the uninitialized variable
message when MXG is executed under CMS SAS for SMF data.
Under MVS, VBS records can have LRECL=32760 (and actual
records with 32760 LRECL are written by SMF!). Since the
MXG specification has been LRECL=32760, this change had
no logic change to _SMF or UTILGETM when MXG is executed
under MVS SAS.
Change 08.173 Preliminary support for Amdahl's MPT (MDF Performance
EXMPTDOM Tool) SMF record. This new tool replaces the existing
EXMPTEND TYPEMDF record with enhanced information. Existing names
EXMPTGLO of TYPEMDF variables were preserved when recognized, but
EXMPTSEL until the actual DSECT is provided by Amdahl, all names
IMACMPT are subject to change and should be used with caution.
TYPEMPT The four new datasets created from the MPT SMF records
VMACMPT (whose ID is set in IMACMPT) are MPTDOMAN, MPTGLOBL,
Nov 9, 1990 MPTSELCT, and MPTENDSL. This support has not been tested
with actual data records yet.
Change 08.172 SPIN library suddenly fills after installation of JES2
BUILDPDB maintenance (either migration to MVS/ESA or PUT 8908).
BUILDPD3 This change replaces the discussion (without a change)
Nov 9, 1990 on the MXG 8.5 PreRelease as Change 8.158.
1.The logic decision in BUILDPDB ("to SPIN or not to SPIN")
controls the contents of PDB.JOBS, PDB.STEPS, PDB.PRINT,
and the SPIN data library. BUILDPDB will output to the
PDB library or SPIN library based on these criteria:
a) Job has "spun" more times than your chosen value of
_SPINCNT (defined in IMACSPIN). Each time a job is not
output, its SPINCNT is incremented. If you set the
value of _SPINCNT in IMACSPIN to 0, BUILDPDB will then
always output to the PDB and will never output to the
SPIN library.
b) The job is complete. There are two possibilities:
i.) The job failed before execution (i.e., JCL error
or canceled before initiation). The JES2 JSTRTIME
(start of execution) will be missing, and only
type 26 (and possibly type 6) records exist for
the job.
ii.) The job is really complete, and all SMF records
have been read. This requires that both a type 26
and a type 30 subtype 5 record were found, AND the
timestamp in the subtype 5 (MVS execution ended)
is between JSRTIME to JENDTIME (the JES execution
start to end times). That timestamp test is needed
to ensure that the real execution type 30 record
was found. If the SMF type 30 timestamp doesn't
match the JES type 26 timestamp, all records on
the job are "SPUN" until the correct type 30
subtype 5 is found. (Restarted jobs create
multiple type 30 subtype 5s. With multiple MVS
systems, today's SMF file could contain the type
26 and a type 30 from the first execution, but the
real (final) type 30 record could be in an
un-dumped SMF file that will not be read until
tomorrow's BUILDPDB run.)
This logic is implemented in BUILDPDB by setting OKFLAG;
if OKFLAG is set to 1, the job is created in the PDB,
if OKFLAG is not set, the records are sent to the SPIN.
SPINCNT= MAX(SPIN26,SPIN6,SPIN30_5,SPIN30_4,SPIN30_1,0);
IF IN26 AND IN30_5 AND
JSTRTIME LE JTRMTIME LE JENDTIME THEN OKFLAG=1;
ELSE IF IN26 AND (JSTRTIME=. OR JENDTIME=.) THEN OKFLAG=1;
ELSE IF SPINCNT GE _SPINCNT THEN OKFLAG=1;
2.Several sites suddenly found their SPIN libraries filled
after migration from MVS/XA to MVS/ESA, or after applying
JES2 maintenance (somewhere between PUT 8902 and 8908).
There were PTFs which altered JES2 time stamps, and one
of the PTFs went PE (PTF in Error), and perhaps the site
did not correctly install all of the PTFs, but the actual
result of the maintenance was that the site's JES2 type
26 SMF record's JENDTIME variable (SMF26XPT, JCTEQOF, the
job ended time, also in the $HASP395 job ended message)
was now earlier than the MVS type 30 subtype 5 (the job
termination JTRMTIME variable (SMF 30TME) timestamp!!!
This has NEVER been true before, and the sites with the
problem saw the change occur precisely when they put on
the IBM maintenance. Not only did IBM JES2 Level 2 say
there was no problem, they also tried to say that there
is no correlation between the JES SMF26XPT execution end
and the MVS SMF30TME job termination time (which is the
timestamp when SVC83 moves the record into the SMF buffer
in the SMF address space)! But SMF30TME occurs while the
job is still in MVS initiation and JES2 can't end the
execution until after SVC83 has completed and until after
MVS terminates its initiator. At these sites, the actual
JENDTIME to JTRMTIME delta is hundreds of milliseconds,
and it plots uniformly across the entire day. Note also
that SVC83 does not write data to disk, but only moves an
SMF record into the SMF buffer; the actual VSAM write of
the CI containing that SMF record will occur much later,
under an asyncronous SRB in the SMF address space.
But even if I'm right and IBM's wrong, it doesn't matter.
IBM can't find their problem or fix their code nearly
as fast as you and I can change the MXG logic to protect
for the error. Since the purpose of the time test is to
match the type 30 with its type 26, we will use the MVS
type 30 job initiation time, JINITIME, which has not been
touched by JES2 maintanance, instead of JTRMTIME, which
was altered, in the MXG BUILDPDB logic. Thus if the SPIN
library suddenly fills, compare JTRMTIME in SPIN30_5 with
JENDTIME in SPIN26J2, and if JENDTIME is earlier than the
JTRMTIME, you know you have this problem. To correct,
simply change JTRMTIME in the BUILDPDB "To Spin or Not To
Spin" logic shown above to instead use JINITIME. This
Change has been made in MXG PreRelease 8.7 and later.
Thanks to Georg Simon, Federal Reserve of Philadelphia, USA.
Change 08.171 PreRelease 8.5 support for Landmark CICS Version 8 had a
TYPEMON8 little error, but it caused a big dump and a STOPOVER!
Nov 5, 1990 Add +1 at the end of line 066800 (ends with TH PK1.)
to skip over the eighth byte of that datetimestamp.
Thanks to Marcia Ketchersid, Price Waterhouse, USA.
Change 08.170 The FORMATS step (only on MXG 8.5 PreRelease) was missing
JCLTEST the //SOURCLIB DD DSN=MXG.SOURCLIB,DISP=SHR
Nov 5, 1990 JCL statement.
---Changes thru 8.169 were included in MXG PreRelease 8.6 Oct 27, 1990--
Change 08.169 Support for VM/ESA Version 1 Release 1.0 ESA Feature.
EXAPLEDT The contents of the MONWRITE output data records has been
EXAPLSDT changed with new fields and new records, but the changes
EXAPLSRV were implemented by IBM in a completely compatible manner
EXIODATS and thus previous versions of MXG Software will not fail
EXSTOASS when they process the ESA Feature data records.
VMACVMXA The four new records create five new MXG datasets (and
Oct 16, 1990 thus there are five new EX...... exit members), and 15 of
Nov 5, 1990 the existing MXG datasets have new variables.
Dec 4, 1990
1.These fifteen existing MXG data sets content's have been
changed as indicated:
VXSYTXSP - New variables PLSPGMRD,PLSPGMRX,PLSPGXRD, and
PLSPGXWT (page reads/writes to/from ESTORE/AUX
due to page translations/migrations). Sample.
VXSYTASG - SALPRFAV,SALPRFIU are now reserved (were for
Preferred Paging), and new variables added for
page/spool average/total MLOAD (CALTOTM1,M2,
CALAVGM1,M2). Sample.
VXSYTCOM - New variables for counts of IUCVs good to/from
and bad to services SYSTEM,ACCOUNT,LOGREC,CRM,
IDENT,CONFIG, and SPL, twenty-one variables
PLSIS+{E,T,U}+{SY,AC,LO,CR,ID,CF,SP}.
VXMTREPR - Added new flag if Application Domain Event is
active, and CONFIG time limit variable.
VXMTRPAG - DDIPREF now reserved (was Pref. Paging Flag),
DDIPPCYL renamed RDCPCYL, and RDEVSID, Host
Subchannel ID now added.
VXMTRSPR - Added 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, 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.
2.There are five new datasets which can exist. However, two
of the new datasets (VXAPLEDT,VXAPLSDT) will have nonzero
observations is your site has an application that uses
the new interface to create Application data records.
Note that IBM uses that interface, and MXG creates the
VXAPLSRV dataset for file pool servers.
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:
ADATASDT='APPLICATION*DATA'
CALDATLN='LENGTH OF*APPLICATION*DATA'
CALDATOF='BYTE OFFSET*TO APPLICATION*DATA'
DEDMTFLG='DEDICATED*MAINTENANCE*MODE FLAG'
FIRSTR ='FIRST RECORD*SINCE DIAGNOSE*DC ISSUED?'
MDGPROD ='APPLICATION*PRODUCT AND*RELEASE'
SRVCN001='ACTIVE*AGENTS*HIGHEST VALUE'
SRVCN002='VIRTUAL*STORAGE*HIGHEST VALUE'
SRVCN003='VIRTUAL*STORAGE*REQUESTS DENIED'
SRVCN004='CHECKPOINTS*TAKEN'
SRVCN005='CHECKPOINT*TIME'
SRVCN006='SECURITY*MANAGER*EXIT CALLS'
SRVCN007='SECURITY*MANAGER*EXIT TIME'
SRVCN008='EXTERNAL*SECURITY*MGR EXIT CALLS'
SRVCN009='EXTERNAL*SECURITY*MGR EXIT TIME'
SRVCN010='ADD*STORAGE*REQUESTS'
SRVCN011='CACHE*RELEASE*REQUESTS'
SRVCN012='CHANGE*THRESHOLD*REQUESTS'
SRVCN013='CLOSE*DIRECTORY*REQUESTS'
SRVCN014='CLOSE*FILE*REQUESTS'
SRVCN015='COMMIT*REQUESTS'
SRVCN016='CONNECT*REQUESTS'
SRVCN017='CREATE*ALIAS*REQUESTS'
SRVCN018='CREATE*DIRECTORY*REQUESTS'
SRVCN019='DELETE*DIRECTORY*REQUESTS'
SRVCN020='DELETE*FILE*REQUESTS'
SRVCN021='DELETE*STORAGE*REQUESTS'
SRVCN022='FILE*COPY*REQUESTS'
SRVCN023='GET*DIRECTORY*REQUESTS'
SRVCN024='GET*DIRECTORY*ENTRY REQUESTS'
SRVCN025='GRANT*ADMINISTRATOR*AUTHORIZATION'
SRVCN026='GRANT*AUTHORIZATION*REQUESTS'
SRVCN027='GRANT*USER*CONNECT REQUESTS'
SRVCN028='LOCK*REQUESTS'
SRVCN029='OPEN*DIRECTORY*REQUESTS'
SRVCN030='OPEN FILE*NEW REQUESTS'
SRVCN031='OPEN FILE*READ*REQUESTS'
SRVCN032='OPEN FILE*REPLACE*REQUESTS'
SRVCN033='OPEN FILE*WRITE*REQUESTS'
SRVCN034='QUERY*ADMINISTRATOR*REQUESTS'
SRVCN035='QUERY*CONNECTED USERS*REQUESTS'
SRVCN036='QUERY*ENROLLED USERS*REQUESTS'
SRVCN037='QUERY*LOCK CONFLICT*REQUESTS'
SRVCN038='QUERY*FILE POOL*REQUESTS'
SRVCN039='QUERY*USER SPACE*REQUESTS'
SRVCN040='READ*FILE*REQUESTS'
SRVCN041='RECOVERY*CLOSE CATALOG*REQUESTS'
SRVCN042='RECOVERY*GET CATALOG*REQUESTS'
SRVCN043='RECOVERY*OPEN CATALOG*REQUESTS'
SRVCN044='RECOVERY*PUT CATALOG*REQUESTS'
SRVCN045='REFRESH*DIRECTORY*REQUESTS'
SRVCN046='RELOCATE*REQUESTS'
SRVCN047='RENAME*REQUESTS'
SRVCN048='REVOKE*ADMINISTRATOR*AUTHORIZATIONS'
SRVCN049='REVOKE*AUTHORIZATION*REQUESTS'
SRVCN050='REVOKE*USER*REQUESTS'
SRVCN051='ROLLBACK*REQUESTS'
SRVCN052='UNLOCK*REQUESTS'
SRVCN053='WRITE*ACCOUNTING*REQUESTS'
SRVCN054='WRITE*FILE*REQUESTS'
SRVCN055='FILE POOL*REQUEST*SERVICE TIME'
SRVCN056='REMOTE*FILE POOL*REQUESTS'
SRVCN057='ALIAS*DEFINITIONS*EXAMINED'
SRVCN058='ALIAS*DEFINITIONS*UPDATED'
SRVCN059='BEGIN*LOGICAL*UNITS OF WORK'
SRVCN060='AGENT*HOLDING*TIME'
SRVCN061='LOGICAL*UNIT OF WORK*ROLLBACKS'
SRVCN062='SAC*CALLS'
SRVCN063='STORAGE GROUP*EXPLICIT LOCK*CONFLICTS'
SRVCN064='FILE SPACE*EXPLICIT LOCK*CONFLICTS'
SRVCN065='DIRECTORY*EXPLICIT LOCK*CONFLICTS'
SRVCN066='FILE*EXPLICIT LOCK*CONFLICTS'
SRVCN067='STORAGE GROUP*LOGICAL LOCK*CONFLICTS'
SRVCN068='FILE SPACE*LOGICAL LOCK*CONFLICTS'
SRVCN069='DIRECTORY*LOGICAL LOCK*CONFLICTS'
SRVCN070='FILE*LOGICAL LOCK*CONFLICTS'
SRVCN071='CATALOG*LOCK*CONFLICTS'
SRVCN072='LOCK*WAIT*TIME'
SRVCN073='DEADLOCKS'
SRVCN074='QSAM*REQUESTS'
SRVCN075='QSAM*TIME'
SRVCN076='FILE*BLOCKS*READ'
SRVCN077='FILE*BLOCKS*WRITTEN'
SRVCN078='CATALOG*BLOCKS*READ'
SRVCN079='CATALOG*BLOCKS*WRITTEN'
SRVCN080='CONTROL*MINIDISK*BLOCKS READ'
SRVCN081='CONTROL*MINIDISK*BLOCKS WRITTEN'
SRVCN082='LOG*BLOCKS*READ'
SRVCN083='LOG*BLOCKS*WRITTEN'
SRVCN084='BIO REQ TO*READ FILE*BLOCKS'
SRVCN085='BIO REQ TO*WRITE FILE*BLOCKS'
SRVCN086='BIO REQ TO*READ CATALOG*BLOCKS'
SRVCN087='BIO REQ TO*WRITE CATALOG*BLOCKS'
SRVCN088='BIO REQ TO*READ CONTROL*MINIDISK BLOCKS'
SRVCN089='BIO REQ TO*WRITE CONTROL*MINIDISK BLKS'
SRVCN090='TOTAL*BIO REQUEST*TIME'
SRVCN091='I/O REQ TO*READ FILE*BLOCKS'
SRVCN092='I/O REQ TO*WRITE FILE*BLOCKS'
SRVCN093='I/O REQ TO*READ CATALOG*BLOCKS'
SRVCN094='I/O REQ TO*WRITE CATALOG*BLOCKS'
SRVCN095='I/O REQ TO*READ CONTROL*MINIDISK BLOCKS'
SRVCN096='I/O REQ TO*WRITE CONTROL*MINIDISK BLKS'
SRVCN097='RELEASE*BLOCKS*REQUESTS'
SRVCN098='TEMPORARY*CLOSE*REQUESTS'
SRVCN099='SFS*SEND USER*DATA REQUESTS'
SRVCN100='PREPARE*REQUESTS'
SRVCN101='CHANGE*FILE*ATTRIBUTE'
SRVCN102='HIGHEST*MAXCONN*USER'
SRVCN103='GET*CAPABILITY*REQUESTS'
SRVCN104='GET*LOG NAME*REQUESTS'
SRVCN105='CRR GET LUWID REQUESTS'
SRVCN106='RESYNC*INITIAL*REQUESTS'
SRVCN107='RESYNC*PROTOCOL*VIOLATION REQS'
SRVCN108='RESYNC*QUERY DIRECTION*REQUESTS'
SRVCN109='CRR*WRITE LOG*REQUESTS'
SRVCN110='CRR REQUEST*SERVICE*TIME'
SRVCN111='NUMBER OF*SYNC*POINTS'
SRVCN112='SYNC*POINT*TIME'
SRVCN113='PARTICIP RESC*CRR WRITE*LOG REQS'
SRVCN114='CRR LOG*CHECKPOINTS*TAKEN'
SRVCN115='CRR LOG*I/O*REQUESTS'
SRVCN116='CRR BIO*REQUEST*TIME'
SRVCN117='RESERVED'
SRVCN118='DIRATTR*REQUESTS'
SRVCN119='QUERY*ACCESSORS*REQUESTS'
SRVCN120='RESERVED*COUNTER 120'
SRVCN121='RESERVED*COUNTER 121'
SRVCN122='DIRCONTROL*RESOURCE*LOCK CONFLICT'
SRVCN123='DEADLOCKS*THAT CAUSE*ROLLBACK'
SVMSTAT ='OPTION*SVMSTAT*IN DIRECTORY?'
VMDUSER ='USER*IDENTIFICATION'
3.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 (and were already supported in MXG).
A thanks for IBM for making documentation available so
early; it's nice to not have to play "catch-up". Of even
greater significance: you can install this version of MXG
now, and whenever you install VM/ESA, you won't need to
install yet another version of MXG!
---Changes thru 8.168 were included in MXG PreRelease 8.5 Oct 27, 1990--
Change 08.168 The SAS 6.06 circumvention was misspelled; three lines
GRAFRMFI that now read
Oct 26, 1990 IGOUT=GRARMF5S GOUT=PDB.GRARMF5S
should be
IGOUT=GRARMF5S GOUT=PDB.GRARMF5S
IGOUT=GRARMF5M GOUT=PDB.GRARMF5M
IGOUT=GRARMF5D GOUT=PDB.GRARMF5D
Thanks to Jan Simark, SAS Institute Europe, GERMANY.
Change 08.167 Support for MVS/ESA SP Version 4.1 and RMF 4.2, which
VMACSMF became avaliable October 26, 1990.
VMACSMF 1.New flag variable MVSESAV4 (flag that this is MVS Version
VMAC434 4) is set but not used in MXG logic.
VMAC535 2.TYPE434, new variables CPUWRONG and EXCPLOST are now set
VMAC6 to "Y" if TCB time has overflowed, or EXCPs lost because
VMAC24 over 1635 DD statements existed. Both conditions exist
VMAC57 ONLY in the type 4 and 34 records, and IBM's now states
VMAC71 "Only the type 30 record should be considered valid."
VMAC74 3.TYPE535, new variable CPUWRONG (see above) added.
VMAC78 4.TYPE6 (JES2 only, not PSF nor JES3 nor EXT WRTR) has
VMAC79 a new "Enhanced SYSOUT Support (ESS) section containing
VMAC90 the output descriptor (if any) for the first offloaded
XMAC7072 data set, with five new variables:
XMAC71 SMF6IND ='ESS*SEGMENT*INDICATOR'
XMAC73 SMF6JDVT='JCL*DEFINITION TABLE*NAME IN JDTV'
XMAC74 SMF6SGID='SEGMENT*IDENTIFIER'
XMAC75 SMF6TU ='TEXT UNIT*(SWBTU)*DATA AREA'
Oct 27, 1990 SMF6TUL ='TEXT UNIT*(SWBTU)*DATA AREA LENGTH'
Mar 5, 1991 This paragraph was changed after Newsletter 18.
The SMF6TU character variable contains the SWB text unit,
which contains the JES2 ITEXT (length, key, value) for
the new OUTPUT JCL statement parameters ADDRESS, BUILDING
DEPT, NAME, ROOM, and TITLE. Their key values (IEFDOKEY
in SYS1.MACLIB) are x'27',28,29,2D,26, & 2A respectively.
Once I find out what sets the maximum length of these new
parameters, the fields will be decoded from the SWB. Stay
tuned to this paragraph in this change.
5.The MSS (Mass Storage System) device is no longer and IBM
supported device, and TYPE22_4 and its MSS variables will
now always be missing.
6.TYPE24 contains the same new five Enhanced SYSOUT (ESS)
fields added to the type 6, with these different names:
SMF24IND,SMF24JDT,SMF24SGT,SMF24TU, and SMF24TUL.
These variables are kept in TYPE24.
7.TYPE57J2 contains the same new five Enhanced SYSOUT (ESS)
fields added to the type 24, with these different names:
SMF57IND,SMF57JDT,SMF57SGT,SMF57TU, and SMF57TUL.
These variables are kept in TYPE57.
8.TYPE71 contains three new swap reason codes, because MVS
now has three additional reasons to swap an ASID:
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.
9.TYPE74 data set has been enhanced with new variables
CUNAME ='CONTROL*UNIT*NAME'
DEVMODEL='DEVICE*MODEL*NAME'
and three variables describing pending delay due to the
director port busy, AVGPNDIR, DLYDIRTM, and PCPNDIR.
10.New subtype 2 of the Type 74 record from the Monitor III
Cross-System Coupling Facility (XCF) reports on message
traffic between the local system (where RMF executes)
and remote systems.
Four new TYPE74xx data sets are created:
/*TYPE74CO - control data */
R742MNXT='MEMBER DATA*SECTIONS IN*NEXT RECORDS'
R742MTOT='MEMBER DATA*SECTIONS IN*ALL RECORDS'
R742PNXT='PATH DATA*SECTIONS IN*NEXT RECORDS'
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'
/*TYPE74PA - path data */
R742PAPP='PATH WAS BUSY*WHEN SELECTED*TO TRANSFER'
R742PDEV='DEVICE*NUMBER'
R742PDIR='DIRECTION*PATH'
R742PIBR='INBOUND SIGNALS*REFUSED*MAX MSG LIMIT'
R742PMXM='MAXIMUM*MESSAGE BUFFER*SPACE'
R742PNME='SYSTEM*NAME'
R742PODV='DEVICE*NUMBER ON*OTHER END'
R742PONA='NAME OF*SYSTEM ON*OTHER END'
R742PQLN='OUTBND SIGNALS*PENDING TRANSFER*ON PATH'
R742PRET='PATH*RETRY*LIMIT'
R742PRST='NUMBER*OF*RESTARTS'
R742PSIG='OUT/IN BOUND*SIGNALS SENT/RCVD*OVER PATH'
R742PSTA='PATH*STATUS'
R742PSTF='STATUS*FLAGS'
R742PSUS='PATH NOT BUSY*WHEN SELECTED*TO TRANSFER'
R742PTCN='TRANSPORT*CLASS*NAME'
/*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 MSG LEN'
R742SPTH='SIGNALING PATHS*CURRENTLY*IN SERVICE'
R742SSML='NUMBER OF*SMALL MESSAGE*CONDITIONS'
R742SSTF='STATUS*FLAGS'
R742STCL='MESSAGE LENGTH*FOR*TRANSPORT CLASS'
R742STCN='TRANSPORT*CLASS*NAME'
11.TYPE75 data set has also been enhanced with the same new
variables CUNAME and DEVMODEL that were added to TYPE74.
12.TYPE78 now detects and deletes invalid subtype 3 records
to avoid the STOPOVER condition if you have not installed
PTF UY55476 for APAR OY36517 described in MVS notes.
13.TYPE79 subtype 1 changed R791ES to reserved and previous
reserved R791ESSL now contains what was in R791ES and is
renamed R791ESCT! Both R791ES and R791ESCT are kept.
14.TYPE79 subtype 11, new variables R79BCU and R79BDEVN for
control unit name and device name.
15.TYPE90 new subtype 18 added variables SYSISUED,SMF90SGC
and SMF90GRN for the SET GRSRNL command.
16.All five of the XMAC70xx members (needed only for SAS
Version 5 for circumvention of the "344 Compiler Limit"
error condition) now include these and all previous MXG
changes to their corresponding VMAC members. See Change
8.129 for further information on the "344" error. Due to
additional new subtypes added by MVS 4.1, there were 3
new iterative DOs added by this support which may cause
modified BUILDPDBs to need "344" circumvention. Sorry!
Note that IBM has announced additional RMF enhancements in
MVS/ESA 4.2 (RMF 4.2.1) to be available on March 29, 1991,
that will add additional data to type 72, 74, and 79s.
Change 08.166 Variable INNODE was added to _PDB26J2 macro. INNODE and
IMACPDB (previously kept) INROUTE are both required to know the
Oct 23, 1990 source of a job, using PDB.JOBS.
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 08.165 IMS Log processing variable PGMLODTM is now non-zero only
TYPEIMS for the first transaction, for multiple transactions per
Oct 23, 1990 program schedule (since the program is loaded only once!)
and OENQTIME is calculated differently for MULTRANS.
Thanks to Harry Olschewski, DVG Kiel, GERMANY.
Change 08.164 Page 219 references the _DBUG110 macro which no longer
MXG Guide exists. It was replaced by a new (undocumented) value of
Oct 23, 1990 SYSPARM=TYPE110-5, since specifying a SYSPARM value does
not require the source change mentioned on page 219.
Thanks to Hr. Moser, RBG Munich, GERMANY.
Change 08.163 NETSPY target response variables for session manager
VMACNSPY have no meaning, but contained non-zero values (they are
Oct 23, 1990 addresses) in the SMF record. MXG recognized thesession
manager record and set the percentages T1RSPPC-T4RSPPC to
missing, but left the counts T1RSPNO-T4RSPNO as they were
found, which confused some users. Now, the countsare
also set missing for session manager records.
Thanks to Randy Hallman, LEGENT, ENGLAND.
Change 08.162 NPM variables OPER.... are now correctly labeled to show
VMAC28 these fields represent HOST plus NETWORK durations, and
Oct 23, 1990 the NETW.... variables are now corrected to label these
fields as NETWORK only (i.e., eliminating the previously
incorrect NEWT label of Network Plus Host). The values
were correct, only the MXG label was incorrect.
Thanks to Tom Kiddy, American President Lines, USA.
Change 08.161 Support for Landmark's Monitor for CICS Version 8.0
ANALMONI Member TYPEMON8 is used instead of TYPEMONI for this
EXMONHIS new version. The support added two new datasets, the
EXMONMRO MONIMRO (MRO detail from transaction record), and the
IMACMONI MONIHIST history detail, which contains the total-to-
TYPEMON8 current-minute of the resources in the MONISYST interval
Oct 18, 1990 data set. MONISYST is now written every minute. Many new
fields describe counts and durations of both requested
and waiting states. The variable names are patterned:
WTxxyyzz
where xx=activity (see list below).
yy=IO for request active, or
WT for waiting, a subset of request active.
zz=TM for duration, or
CN for count of times activity performed.
eg:
WTFCIOTM=duration File Control IO was requested,
including processing and waiting time,
WTFCIOCN=count of File Control IO requests,
WTFCWTTM=duration that FC IO actually waited, and
this duration is included in WTFTIOTM,
WTFCWTCN=number of times File Control actually waited.
The xx activities captured in Landmark Version 8 are:
xx Requests Waits
DB ='DB2*WAITS' YES
DL ='DLI*CALL*IO' YES YES
DS ='DISPATCH*QUEUE-WAIT' YES
EN ='ENQUE*SUSPEND*WAITS' YES
FC ='FILE*CONTROL*IO' YES YES
IC ='ICP*SUSPEND*WAITS' YES
IS ='ISC (MRO)*SUSPEND*WAITS' YES
JC ='JOURNAL*CONTROL*IO' YES YES
MD ='MRO/DTP*WAITS' YES
MI ='MIRROR*SUSPEND*WAITS' YES
MR ='MRO/IRC*WAITS' YES
MS ='MRO/DTP*SUSPEND*WAITS' YES
NS ='DB2 NON-SQL*CALLS' YES
OP ='OPER*THINK TIME*FOR CONV' YES
PF ='PROGRAM*FETCH' YES YES
PM ='PREEMPT*WAITS' YES
SC ='MRO/ISC' YES YES
SQ ='DB2 SQL*CALLS' YES
ST ='STORAGE*SUSPEND*WAITS' YES
TB ='TEMPSTG*(AUX+MAIN)' YES YES
TC ='TERMINAL*SUSPEND WAITS' YES
TD ='TD (EXTRA)*IO' YES YES
TI ='TD (INTRA)*IO' YES YES
TS ='TEMPSTG (AUX)*OUTPUT' YES YES
UD ='USER*DATABASE' YES YES
1S ='FIRST*DISPATCH' YES
Wherever possible, previous MXG variable names are used
but Landmark names are in comments adjacent to MXG's
chosen variable name in MXG member TYPEMON8. Complete
description of variables is contained in Landmark's
Appendix C of "Report Writer and Extended Facilities",
and in MXG member DOCVER under each MONI.... dataset.
Change 08.160 DCOLLECT record date fields cause "NOTE: INVALID DATA"
VMACDCOL or "NOTE: ILLEGAL ARGUMENT TO FUNCTION" when the julian
Oct 10, 1990 date is a zero, nulls or 99000 or 99366. The three input
statements for DCDDATE1-DCDDATE3 need ?? before the PD4
format item, and the calculation of DCDCREDT and DCDLSTRF
must be protected for 0. The DCDEXPDT expiration date is
more complicated, because EXPDT values of 99000 and 99366
appear in DCOLLECT records, but these cannot be converted
to real date values. DCDCREDT, DCDEXPDT, DCDLSTRF should
be SAS date values, so that subtraction, formatting, etc.
can be done. However, these "flaky" EXPDT values used for
flags should not be lost. Since only EXPDT contain these
"flaky" values, MXG chooses the following technique. New
variable ORGEXPDT will contain the original (raw, in the
record) value (the raw value for Jan 1, 1991 is 1991001).
DCDEXPDT will contain the real SAS date of ORGEXPDT, or
will be missing if ORGEXPDT was zero or missing, but if
ORGEXPDT contains a "flaky" value (day=000, 99000, 99365
or 99366), MXG sets DCDEXPDT of 1JAN 2099 as a special
flag date to tell you to look at ORGEXPDT if you really
need to know the original expiration date. MXG uses a
SAS date in the year 2099 so that if you should ever use
DCDEXPDT in a calculation, you'll see the expiration
date is well into the future!
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 08.159 Variable PAGRT in TYPE71 now includes PGMIEXAU, HIPAGINS,
VMAC71 and HIPAGOUT, in addition to the original DPR, SPR, & VIO
Oct 10, 1990 variables so that PAGRT counts all pages moved between
auxiliary storage (DASD) and central/expanded storage.
The three new fields are MVS/ESA only.
Thanks to Peter Durant, National Australia Bank, AUSTRALIA.
Change 08.158 This was originally a two part technical discussion with
no actual MXG change. The first half of that discussion
is now Change 8.172 and has been reworded and enhanced.
This is the rest of the original technical discussion.
One site wanted to reset their SPINCNT value to 0 at the
end of each month. (I don't recommend this technique,
and its not clear to me this is wise, but by exploiting
MXG's use of the old style substitution macro _SPINCNT,
it was possible to show them how to do what they wanted
to do, with no change to the BUILDPDB code itself):
In IMACSPIN, define _SPINCNT as follows. The value of 10
in the example assumes your original SPINCNT was 10.
MACRO _SPINCNT
. THEN DO;
IF SYSPARM()='MONTH' THEN SPINTST=0;
ELSE SPINTST=10;
IF SPINCNT GE SPINTST THEN OKFLAG=1;
END;
ELSE IF -1 = +1
%
This logic is not obvious, until you look at BUILDPDB
to see exactly how _SPINCNT is referenced, but it shows
how flexible the old style substitution macros can be!
With this new definition for _SPINCNT, and by using the
OPTIONS='SYSPARM="MONTH"' on the EXEC SAS statement
on the desired day, the SPIN library will be emptied.
---Changes thru 8.157 were included in MXG PreRelease 8.4 Oct 9, 1990---
Change 08.157 SAS 6.06 Compatibility Change. SAS User-SMF record.
IMACSASU The format of the SAS-created user SMF record (describing
VMACSASU resources for each PROC execution) was changed in 6.06.
Oct 8, 1990 Now, IMACSASU defines two macros, _IDSAS5 and _IDSAS6 to
identify the SMF record number of each version's record.
If you are currently building TYPESASU from Version 5.18
records, you will have to replace the modified IMACSASU
in your USERID.SOURCLIB with this new IMACSASU member.
Thanks to Tim Haiar, South Dakota Higher Ed. Computer Services, USA.
Change 08.156 Additional enhancements for RMF III VSAM dataset record
EXZRBUWM processing was provided by National Westminster Bank to
EXZRBUWT these members. Two new members, ZRBBATCH and ZRBPRINT
VMACZRB were added and they produce a detailed analysis of batch
ZRBBATCH job delays. Member ZRBDLYBT was rewritten to be more
ZRBBUILD efficient. Member VMACZRB has been amended to include a
ZRBCHECK division-by-zero test for SQA overflow frames.
ZRBDLYBT The function of the associated code members is explained
ZRBDVDLY in member VMACZRB. New member ZRBIPSJ is an interesting
ZRBMKIDX job which is self-explanatory and reads selected members
ZRBPRINT of SYS1.PARMLIB. Two new data set exits were added. The
Oct 8, 1990 remaining members changes were only in the comments. All
"ZRB" members now cite both NatWest's enhancements and
acknowledge the original "ZRB" author, Dick Whiting.
Thanks to Roland Rashleigh-Berry, NatWest, SCOTLAND.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 08.155 Variable FWRATIO (Fast Write Hit Ratio) was added to the
VMACACHE CACHE90 data set. Because four Fast Write specific fields
XMACACHE (SRCD,SRCDH,WCD,WCDH) were zero, it appeared there was no
Oct 8, 1990 Fast Write, but FWRATIO was actually non-zero. This value
now matches the same-named heading on the IBM report.
Thanks to Dale Mattison, Shared Medical Services, USA.
Change 08.154 This ROSCOE report did not %INCLUDE IMACROSC and did not
ANALRRTM threfore use the _ROSCDDN as the expected location of the
Oct 6, 1990 RRTMPSE data set used for reporting; now it does.
Thanks to Bob Yeager, Whirlpool Corporation, USA.
Change 08.153 Comments were corrected. The correct sort order for the
ASUMJOBS WEEKBLD after using ASUMJOBS is given by the SUMBY= list
Oct 6, 1990 on the invocation of %VMXGSUM, but anytime that the
temporary variable "DATETIME" is used in the SUMBY list
(as it usually is), the actual variable you must use in
any subsequent processing is not "DATETIME" (which will
always be DROPped by VMXGSUM), but instead the actual
variable set equal to DATETIME= in the macro invocation.
For ASUMJOBS the actual resultant sort order will be
JOBCLASS SHIFT INITTIME
because SUMBY=JOBCLASS SHIFT DATETIME, but also
DATETIME=INITTIME, in the VMXGSUM invocation.
Thanks to Linda Carroll, Crawford Long Hospital of Emory Univ, USA.
Change 08.152 VM/370 Monitor data set VMONCHAN now has the sample count
ANALVMDY variables MN602SAM and MN602SA2 added to the KEEP= list,
VMACVMON and they were added to the RETAIN list so that the are
Oct 6, 1990 carried into the CHAN record from the DEV record. This
avoids the need to merge DEV and CHAN to calculate CHAN
busy. The three tests for (LENGTH-COL) GE 64 should all
be GE 63 so that channels 32 and higher actually INPUTed.
ANALVMDY now uses the MN602SAM/SA2 instead of INTERVAL to
correct its CHAN busy calculations. Variable MN003CDD
should not be DIF()d, and variable DRUMUTIL needed to be
added to the big RETAIN list.
Thanks to Bob Small, Grumman Data Systems, USA.
Thanks to Frank Putnam, Ryerson Polytechnical Institute, USA.
Change 08.151 VM/XA support macro _DBYUSR did not DIF() some of the HF
VMACVMXA counters, causing some percentages to be since the start
Oct 5, 1990 of monitoring. These HF counters are now DIF()d. MACRO
_CSYTUWT should have decremented SKIP by 52 vice 72.
If the Interval or HF Sampling rate were changed, MXG
made the change when the record was found, rather that
as it should have at the end of the interval. That has
been corrected, and notes on the log alert you if either
was altered.
Thanks to Peter Strange, BP International London, ENGLAND.
Change 08.150 This JCL member is an example of the MVS job that submits
JCLCRAYC a job to execute on the Cray to extract the accounting
Oct 5, 1990 and performance data records and send them back (asis)
to the MVS system (into dataset MXG.CRAY.MODFILE) that is
then processed by MXG member TYPECRAY under MVS to build
the Cray PDB. (This specific example is for COS 1.17).
With 1000 Cray jobs per business day, and with the SPM
interval set at 10 minutes, the extract will need about
125 cyl, or about 90MB for an entire WEEKs Cray rawdata.
Thanks to Arlin B. Collins, Oryx Energy, USA.
Change 08.149 Support for Amdahl's SPMS product's SMF record for the
IMACSPMS 6100 and 6880 Cache DASD controllers. The code was tested
VMACSPMS with the help of the folks at Amdahl, and one real user,
TYPESPMS as the documentation of the SMF record is less than good.
Oct 5, 1990 Data set TYPESPMS is created from the SMF record, but
only 6100 data records have been validated. Amdahl has
said there will be enhancements in the near future to the
SMF record that will answer many user requirements.
MXG variable names for fields described in the DSECT are
the DSECT suffix prefixed with SPMS. For variables that
are calculated or decoded, the variable name suffix is
SPMS or SPM. Do you like this technique (which was my
choice after looking at the two user contributions from
which this support derived)?
Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.
Thanks to Neville Windeyer, Amdahl, USA.
Thanks to Ray Williams, Amdahl, USA.
Thanks to Neil Avery, Amdahl, USA.
Thanks to Randy Graves, Amdahl, USA.
Change 08.148 NPM Release 4 (NPM 1.4) Support has been added, but not
EX028ER1 yet tested with 1.4 data. This text will change when
EX028ER2 validation has been completed with 1.4 data records.
EX028IN9 Support is in MXG PreRelease 8.4, but because IBM used
FORMATS (correctly!) the relocatable record architecture, their
VMAC28 changes ARE compatible with MXG 7.7. (MXG 7.7 will detect
Oct 5, 1990 the new 1.4 data and will note that unexpected data was
found, but MXG 7.7 will not fail with NPM 1.4 data!). The
change processes mixed 1.3 or 1.4 records, transparently!
1.Support added three New MXG datasets:
NPMERNCP,NPMERNET, for NCP or Network respectively,
are created when a prior Event Exception has been
resolved (either the value is now in range, the
resource was detached, or monitoring was stopped).
NPMINTRI, an interval record reporting resources from
the Network Token Ring Interface.
2.Support added new variables in existing MXG datasets:
NPMINPMT, variables NPMALRCT,NPMARCNT count Alerts
sent or lost.
NPMINSES, variables LSCDANUM,BADI,CNTL,EXTN,GRUP,SMID,
SPLU,SSLU, and LSCDUSER contain (optional) session
manager names (Userid, SLU, etc.) and status.
NPMINNCP, variables NCPNEWNM,NCPGENLV contain NCP load
module name and the GENLEVEL parameter.
NPMINPMT, variables NPMTDROF,DRAD,DRDE,DL18) track the
DDR entries lost, added, or deleted.
3. FORMAT member was updated with new format MG028FL and
existing formats MG028DA and MG028NT contain new
values.
4. The IBM NPM 1.4 Installation and Customization Guide,
Part 1, pages 1-106 provide much better documentation
than its predecessor. A big thanks also to IBM to make
the manual available early so support can be in place!
Change 08.147 TYPE41 variable SMF41LRG is already in bytes and the line
VMAC41 SMF41LRG=SMF41LRG*4096; must be deleted. Some labels did
Oct 1, 1990 not contain * for split characters, but now they do!
Thanks to Ken Williams, Australian and New Zealand Banking, AUSTRALIA
Change 08.146 New members. This set of members provides a capacity
ANALPRTR measurement and planning system for printers, and it
ASUMPRTR defines measures of printer throughput. It is preliminary
IMACPRTR and further additions to BUILDPDB may be made. Definition
TRNDPRTR of printers, costs, etc., are made in IMACPRTR, and then
Oct 1, 1990 member ASUMPRTR can be added to BUILDPDB to create the
dataset PDB.TYPE6ENH ("Enhanced", with throughput stats),
which is the basis for ANALPRTR, and TRNDPRTR. See the
comments in each member for documentation.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.145 RACF variable RACFDESC contains undecoded values which
FORMATS were printed as a colon because the MXG format did not
Oct 1, 1990 recognize the additional bits added by RACF 1.9. The data
itself was not wrong; bit 0 is a violation and bit 3 is
a warning. Because IBM uses multiple bits in this field,
the $MG080DE. format now includes values A0 and 88 for
violation and values 30 and 18 for warning.
Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.
Change 08.144 New members. JCL example and code used to print the MXG
JCLUPPDS source library (or any source PDS) in two column format
VMXGPPDS with an Index of members. The JCL uses standard IBM PSF
Oct 1, 1990 control statements in the SYSIN for all steps.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.143 Critical error, but only in MXG 8.3. The order of INDATA
TRNDRMFI datasets was changed for consistency, but the (IN=INWEEK)
TRND72 option was not re-located, which caused the Trend dataset
Oct 1, 1990 TYPE72 and RMFINTRV to be badly corrupted.
Change INDATA to correctly read:
INDATA=WEEK.TYPE72 (IN=INWEEK) TREND.TRND72,
INDATA=WEEK.RMFINTRV (IN=INWEEK) TREND.RMFINTRV,
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 08.142 This member was intended to produce trend charts from the
GRAFREGR VM/370 trend data set TREND.VMONINTV, but somewhere in an
Oct 1, 1990 EDIT session, VMONINTV inadvertently became RMFINTRV!
Thanks to Bob Yeager, Whirlpool Corporation, USA.
Change 08.141 -Enhancement. The existing code used default pattern and
GRAFTRND color selection when building bar charts. This is fine
Oct 1, 1990 when the graphs are viewed in color, but if reproduced in
black and white they can be very difficult to read. This
change solves this problem by alternating cross-hatching,
left diagonals, and right diagonals in varying densities.
Colors are also selected but only eight are used. If the
default PCBATCH device driver is used, there should be no
difficulty on any device with eight or more colors. You
could use a color catalog (described in the SAS/GRAPH
manual) to modify the colors in use. All MXG GRAFxxxx
routines that use the PCBATCH device driver default to
WHITE for the titles and axes and any text. If you are
using a pen plotter, you may wish to force the conversion
from WHITE to BLACK.
-Bar charts for workloads create segments in the legend
for workloads that have zero CPU time. This is not really
an error but it's annoying to have to explain nonexistent
workloads to your management. This change only outputs
those workloads with non-zero CPU time.
-If SASGRAPH=NO and SASSTAT=YES were specified, the first
plot received a "variable not found" message. The PROC
PLOT was pointed at the wrong dataset.
Change 08.140 New member that produces bar charts of workloads by hour
GRAFWORK from RMFINTRV. Will use SAS/GRAPH if available, otherwise
Oct 1, 1990 produces printer charts and tabular reports.
Change 08.139 Cosmetic change added new optional argument INVOKEBY to
VMXGSUM %VMXGSUM macro that will be printed on the SAS log to
Oct 1, 1990 identify which member invoked %VMXGSUM. As time permits,
each MXG invocation of %VMXGSUM will be changed to pass
the member name into this argument for documentation on
your log. This is mostly helpful when one is debugging!
Change 08.138 Significant validation and enhancement of MXG's supprot
EXHSMDSR for the HSM User SMF records (default is 240 and 241) is
EXHSMFSR added by this user contribution. Code has been unloaded
EXHSMFST and syntax tested, but not actually used. One of the HSM
EXHSMFUN SMF records contains accumulated counts that are reset
EXHSMVSF each midnight, and de-accumulation may be desirable but
EXHSMVSR has not yet been investigated. The other record seems to
FORMATS be directly usable.
IMACHSM
VMACHSM
Sep 19, 1990
Thanks to Wanda Prather, Johns Hopkins APL, USA.
Change 08.137 TYPE1415 Hiperbatch variables (added by Change 8.017) are
VMAC1415 non-zero (garbaged) for type 14/15 records with more than
Sep 19, 1990 one UCB, which occurs only for BPAM accessed concatenated
PDSs, which aren't even eligible for Hiperbatch! The test
IF LENGTH-COL+1 GE 20 THEN .... should be changed to
IF LENGTH-COL+1 GE 20 AND NUCB=1 THEN .... so that only
non-BPAM data sets with a single UCB are tested to see if
the hiperbatch fields exist. (MXG must use the length of
the record to determine if data exists that could be the
hiperbatch fields, because IBM does not set a flag to say
that the fields are present, and IBM also failed in the
original implementation to set the length of the segment
to include the new fields!)
Thanks to Linda Carroll, Crawford Long Hospital of Emory Univ, USA.
Change 08.136 The DFP 3.2 type 42 SMF record to audit an ACTIVATE event
VMAC42 is created in error. IBM APAR OY36035 describes the error
Sep 18, 1990 and PTF UY55307 is the correction for their error. The
subtype 3 (audit) record is mis-located and incorrectly
documented in the SMF manual, and will cause MXG to abend
with a STOPOVER, than can be circumvented only by adding
this test to member IMACFILE (which deletes all subtype 3
audit records) until the PTF exists from IBM:
IF ID=42 THEN DO;
INPUT @85+OFFSMF TESTDFP $CHAR8. @;
IF TESTDFP='ACTIVATE' THEN DELETE;
END;
or alternatively by using the MISSOVER circumvention for
STOPOVER option as described in Change 8.012.
Member VMAC42 was re-written based on the corrected SMF
record description received from IBM Level 2, and tests
for both the right and wrong format record. Fortunately,
the subtype 3 record is not very important and deleting
it won't really hurt the good data in the other subtypes!
Thanks to Dan Barbatti, Southwestern Bell, USA.
Change 08.135 PR/SM changes in status were not decoded in TYPE70PR. Now
VMAC7072 variables LCPUCHST, LCPUCHWT, LPARCHAC and LPARCHNR flag
Sep 17, 1990 that changes occurred in LCPUWAIT status, LCPUSHAR value,
Activation/Deactivation, or Number of LPARS in Partition,
respectively.
Thanks to Richard Evans, Mervyns, USA.
Change 08.134 The ACBMACR1-3 variables added in MXG Version 7 (decoded
VMAC64 after PTF UY40839, APAR OY23661 has been installed) are
Sep 15, 1990 now explicitly decoded into useful new flag variables:
ACBADR ='ACCESS*WITHOUT*INDEX?'
ACBAIX ='AIX OF THE PATH IN THE GIVEN DDNAME?'
ACBCNV ='CONTROL*INTERVAL*PROCESSING?'
ACBDFR ='DEFER*WRITES'
ACBDIR ='DIRECT*PROCESSING?'
ACBDSN ='SHARING*CONNECTION*USING DSNAME?'
ACBGSR ='GLOBAL*SHARED*RESOURCE?'
ACBICI ='IMPROVED*CI*PROCESSING?'
ACBIN ='INPUT*(GET,*READ)?'
ACBKEY ='ACCESS DATA*VIA*INDEX?'
ACBLOGON='LOGON*INCICATOR*(VTAM X03004)?'
ACBLSR ='LOCAL*SHARED*RESOURCE?'
ACBMODE ='VSAM*31 BIT*ADDRESSING?'
ACBNCFX ='CFX IF Y,*NFX IF BLANK?'
ACBOUT ='OUTPUT*(PUT,*WRITE)?'
ACBRST ='SET*DATA SET TO*EMPTY STATE?'
ACBSEQ ='SEQUENTIAL*PROCESSING?'
ACBSIS ='SEQUENTIAL*INSERT*STRATEGY?'
ACBSKP ='SKIP*SEQUENTIAL*PROCESSING?'
ACBUBF ='USER*BUFFERS?'
Thanks to Derek Cespedes, Florida Power and Light, USA.
Change 08.133 The technique for setting the number and length of the
IMACACCT Accounting variables kept in MXG from SMF records has
Sep 13, 1990 always been an exposure to user error, because the user
was required to actually alter the SAS code in member
IMACACCT, which occasionally caused a STOPOVER condition
to new users unfamiliar with SAS syntax. A much safer
and easier technique has now been implemented. Instead of
commenting out code for unwanted account variables, the
simple addition of a DROP statement naming the unwanted
variables will keep only the wanted with no code changes.
Existing sites need not change their IMACACCT member, but
may wish to do so anyhow.
The only price for this technique is that programs that
%INCLUDE member IMACACCT more than once will cause a new
warning message (but only under SAS 5.18) that reads:
WARNING 393:VARIABLE ALREADY SPECIFIED IN DROP/KEEP LIST.
The warning itself has no effect.
Thanks to Rich Hawthorne, Group Health Coop. of Puget Sound, USA.
Change 08.132 One major and several minor changes to RMF to support the
VMAC7072 ES/9000 series under MVS/ESA 3.1.3 from (GC28-1819-3).
VMAC71 1.ES/9000 Processors will cause STOPOVER abend on type 78
VMAC73 SMF records, because IBM added data to the IOP and IOQ
VMAC74 sections which MXG was not prepared to handle! The new
VMAC75 fields (see below) are now supported, and the MXG "SKIP"
VMAC76 logic now protects future segment length changes. Even if
VMAC77 you have this MXG change installed, MXG will STOPOVER if
VMAC78 IBM's PTF for APAR OY36517 is not installed, as the IBM
VMAC79 PTF which added RMF support for ES/9000 (UY90666) itself
Sep 13, 1990 is in error until PTF OY36517 is installed.
2.New flag variables ESCAENAB,ESCACONF identify if this
processor is enabled for ES Connection Architecture, or
there is an ES connection director in the configuration.
3.The MSOCOEFF field in the type 72 and type 79 records was
increased from 4 to 8 EBCDIC characters (I cannot imagine
why) and relocated to the end of the section. MXG picks
up the longer field if it exists, but since an 8 digit
number can still be stored in a 4-byte MXG variable, the
IBM increase has no effect on the MXG MSOCOEFF length.
4.PCTDIRPT, percentage of samples when I/O was delayed due
to Director Port (ESCA, or Fiber Optic Channels) busy is
added to TYPE78CF, TYPE79EF, and as variable R799DPB in
TYPE799.
The only circumvention for the STOPOVER condition until
you receive this change is to delete the type 78 subtype
3 record in member IMACFILE:
IF ID=78 AND SUBTYPE=3 THEN DELETE;
or alternatively use the MISSOVER replacement for the
STOPOVER option as described in Change 8.012.
Change 08.131A Minor enhancement to TYPE41AC and TYPE41UN data sets for
FORMATS Data-in-Virtual added format for object type (DA) and
VMAC41 object mode (Read or Update).
Sep 12, 1990
Change 08.131 The CMS example on page 24 of the MXG Supplement to copy
VM example VM/Monitor data to a CMS file named MONITOR DATA A does
Sep 12, 1990 not specify DCB attributes on the FILE MONOUT statement,
and the CMS default of FB, 80, 960 causes the output data
records to be truncated. The correct FILE statement is:
FILE MONOUT RECFM=VB LRECL=4092 BLKSIZE=4096;
There is additional discussion of possible problems with
the subsequent GLOBAL statement in Change 6.212 in member
CHANGE06.
Change 08.130 Validation and enhancement of the DCOLLECT processing was
VMACDCOL added by this change. All 7 record types are supported to
Sep 12, 1990 create DCOLDSNS, DCOLVOLS, DCOLCLUS, DCOLMIGS, DCOLBKUP,
DCOLCAPD, and DCOLCAPT data sets. The documentation for
the output of this IDCAMS utility named DCOLLECT is found
in several manuals. GG24-3540-00 "DFSMS Planning and
Reporting" provides an overview of DCOLLECT. The first 3
MXG data sets above 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. The final 4 MXG data sets are HSM related,
and their contents is described (poorly, DCOLLECT is not
even cited in the table of contents nor the index) in
Chapter 17 (User Application Interfaces) of SH35-0084-4,
"DFHSM 2.5.0 Installation and Customization Guide".
A future MXG newsletter will contrast the data available
from the DCOLLECT facility with the data created from the
VMXGVTOC and VMACVVDS, and will (hopefully) also compare
the HSM DCOLLECT data captured with the data available
from MXG's JCLHSM (BCDS,MCDS, etc), and the HSM SMF data
record (VMACHSM, still work in progress). The initial
review does make DCOLLECT attractive, especially since it
is a supported interface from IBM, but there appears to
be some data simply not available from DCOLLECT that may
be important (such as physical data set location).
Thanks to Jim Gilbert, Texas Utilities, USA.
Thanks to Sal Fazzino, General Electric Capital, USA.
Change 08.129 SAS 5.18 Compiler Error 344 circumvention. An iterative
XMACACHE DO was added by MXG 8.3 for DB2 Distributed Header in the
Sep 12, 1990 VMACDB2 processing. That broke the compiler limit in 5.18
at a site which had added DB2, Cache DASD, and several of
their own SMF records to BUILDPDB processing. In looking
for additional opportunities to eliminate iterative DOs,
this change creates replacement member XMACACHE from the
existing VMACACHE member. XMACACHE will ONLY process the
3990 Cache Controller records (although the 3880 datasets
will still be built with zero observations) and thereby
eliminated 4 iterative DO statements. If you have added
VMACACHE processing to BUILDPDB and get the 344 Error,
copy XMACACHE into your USERID.SOURCLIB and rename it
therein to VMACACHE. The original discussion of Error
344 Circumvention is in Change 7.038 in member CHANGE07.
Note that 344 is only a problem with SAS 5.18. There is
no limitation on iterative DOs in SAS 6.06.
Thanks to Dan Barbatti, Southwestern Bell Telephone, USA.
Change 08.128 SMS (System Managed Storage) adds a new record to the
VMAC60 VVDS for non-VSAM files on SMS-managed volumes, a pseudo
VMACVVDS VVR record called the NVR. Unlike real VVR records that
Sep 5, 1990 describe space, etc., the NVR record has no such data.
However, the NVR and the VVR records both now contain the
SMS attributes (Data, Storage, & Management Class Names).
The new MXG variables VVRDATCL,VVRSTGCL,VVRMGTCL are the
class names, new variable VVRSBKUP is the last backup
date, and flag variables VVRNATTR,VVRSMSFG were added.
The NVR record was processed without error by TYPEVVDS,
but the TYPE60 member failed with a STOPOVER condition
if it encountered the new NVR data record without this
change.
Thanks to Jim Gilbert, Texas Utilities, USA.
Thanks to Sal Fazzino, General Electric Capital, USA.
Change 08.127 Preliminary support for MVS/ESA Version 4 SMF changes.
IMACPDB 1.New variable VARIEDBY was added to TYPE8911 (but applies
VMAC8911 only for SMF type 9 or 11 vary record) to identify who
VMAC30 issued the vary command. (In Version 4, a terminal user
Sep 5, 1990 can actually signal to MVS to vary the device offline).
2.New variable MVSLEVEL was added to the type 30 datasets
(and will contain SP4.1.0 for MVS/ESA Version 4) so that
you can finally know which software operating system was
in use at the step/job accounting level. MVSLEVEL was
also added (in IMACPDB) to the variables to be kept in
PDB.STEPS and PDB.JOBS.
3.Additional changes in MVS/ESA Version 4 that did not need
MXG changes but which should be noted:
a. A new bit in the header identifies MVS as Version 4.
b. Long standing problem with the internal 3-byte counter
for step/job CPUTCBTM (which wrapped at 17 hours) is
now corrected, and a 4-byte field is used internally.
This will correct CPU times for these long-running job
records in the type 30 (used by BUILDPDB), but for any
site still clinging to the archaic 4, 34, 5,or 35 SMF
record, the CPU times are still only 3-bytes, and will
not be correct. (In fact, MVS Version 4 now sets a bit
if the 3-byte field overflows to tell you to use the
CPU times in the type 30 instead!).
c. APPC support was added, but accounting fields for APPC
are added only to the type 30s, and not 4,34,5,35s.
d. SMF Exits IEFUJP and IEFUJV must be AMODE 31.
Change 08.126 SAS 6.06 Compatibility. JCL Examples.
CONFIG The JCLTEST example creates the MXG Format Library and
JCLTEST exercises the MXG system under SAS. Member JCLTEST was
JCLTEST6 revised for SAS Version 5, and now %INCLUDES new member
JCLPDB SASOPTV5 which specifies the SAS System Options that are
JCLPDB6 now required by MXG Version 8.3 and later. SAS Version 5
SASOPTV5 format library still uses the DDname "SASLIB" and uses a
Sep 5, 1990 DSNAME of "MXG.SASLIB" in this example for Version 5.
New member JCLTEST6 provides an example of the JCL needed
for SAS Version 6.06, and references the CONFIG member to
specify the Version 6 recommended options. SAS Version 6
format library now uses the DDname "LIBRARY" and uses a
DSNAME of "MXG.FMTS606" in this example for Version 6.
Change 08.125 SAS 6.06 Compatibility. SYS prefix reserved in %MACROs.
ANALDMON Syntax of %LET SYSTEM causes "ERROR: Attempt to %GLOBAL
ANALNPMR a name (SYSTEM) which exists in a local environment."
Sep 4, 1990 This is actually a bug in SAS 6.06, but there is a good
possibility that the SYS.... prefix may be reserved in
%MACRO variables/arguments in SAS 6.07, and thus the two
occurrences in MXG in which SYSTEM= was used as a macro
variable (to select the SMF System ID for the report)
have been changed to SMFSYSTM= instead of SYSTEM.
Change 08.124 Variable SMGS_MIN in this NSPY reporting program should
ANALNSPY have been spelled SMSG_MIN in the FORMAT statement in
Sep 4, 1990 line 006000.
Change 08.123 The MXG 8.2 circumvention (Change 8.020) for invalid CPU
VMACSYNC time in SYNCSORT SMF records was mis-typed and caused
Sep 4, 1990 TYPESYNC to contain garbage. Line 042910 was added as
@M4 CPUERTST but it was supposed to be
+M4 CPUERTST $CHAR4.
to redefine CPUERTST as a character value of CPUTCBTM for
the subsequent test (M4 is set equal to minus four).
Change 08.122 Member FORMATS produced warning message because there are
FORMATS no quotes for $MG037FU format definition.
Sep 4, 1990
Change 08.121 DB2 PMAUD02 and PMAUD03 report request produced 145 and
ANALDB2R 170 SAS errors. The format for variable QW0145TS in both
Sep 1, 1990 PUT statements should be HEX16. instead of $HEX16.
Thanks to Tim Kearney, Allied Automotive, USA.
Change 08.120 The allocation for SAS 6.06 format library needed SPACE
FORMATS of CYL,(10,1) during 6.06 beta testing; unbeknownst to
LIBRARY me, the problem had been fixed in 6.06.01, and in fact,
SASLIB MXG's format library under SAS 6.06 requires only space
Sep 1, 1990 of (CYL,(1,1)). References have been corrected.
Thanks to Dan Squillace, SAS Institute Cary, USA.
--Changes thru 8.119 comprised MXG PreRelease 8.3 Dated August 26, 1990-
Change 08.119 IMS Log Input Queue times were incorrect whenever an
TYPEIMS IMS transaction had no ARRVTIME in its 01/03 record.
TYPEIMSX Why IBM can't put the DATE and TIME in every IMS log
VMACIMS record is beyond me, but they don't. Because of the
Aug 26, 1990 missing value, these records sorted early and caused
sometimes significant errors in IMSQUETM & RESPNSTM.
Comparison with IBM's DFSILTA0 output shows that IBM
uses the ENQTIME as the ARRVTIME in these cases, and
now MXG also uses ENQTIME. The implementation was to
use the timestamp of the just-previous-log-record minus
.001 for ARRVTIME when ARRVTIME was missing. That causes
the sort order to be correct, and the .001 allows MXG
to recognize that ARRVTIME was missing (IMS time stamps
are only accurate to .1 seconds), and thus MXG can use
ENQTIME for ARRVTIME in these cases.
In further examination of the test data and the output
of DFSILTA0, it became apparent that even IBM's IMS
guru's can't figure out how to put IMS transactions
together with that program, even though DFSILTA0 is
essentially simulating IMS processing and can keep
everything it needs in virtual storage. About one
third of these IMS 2.2 transactions have missing
time stamps on the DFSILTA0 report, especially when
multiple transactions are executed with a single
program schedule. Further review suggested that if
using the adjacent record's time stamp was good for
a missing ARRVTIME in an 01/03 record, it was also good
in those many cases where the 03 log contained a non-
missing, but much-earlier-than-now timestamp, and now
those cases are also detected and protected this way.
Additional logic enhancements were offered by Ashland
Oil, whose contribution in recalculation of output queue
times were implemented in this change as well.
And for those of you still using IMS 1.3, remember that
member TYPEIMS1 (See Change 7.075 in member CHANGE07)
is only for that archaic IMS version.
Thanks to Richard S. Ralston, Rochester Telephone, USA.
Thanks to Ervin Claxon, Ashland Oil, USA.
Change 08.118 IMS Log processing did not handle a cold start. This
IMACIMS contributed discovery added processing in VMACIMS to
TYPEIMS detect a cold start of IMS (a subtype of type 40 record)
VMACIMS and added IMSQBLDN to count each new queue build event.
Aug 25, 1990 In TYPEIMS, the SORT order which formerly was
IMSTAPNO DTOKEN PSTNUMBR TRANSACT IMSRECNO is now
IMSQBLDN DTOKEN PSTNUMBR TRANSACT IMSTAPNO IMSRECNO
which not only handles cold starts, but solves several
site's problems with incorrect input queue time, by
re-associating IMSTAPNO with IMSRECNO. The same SORT
logic (with different variables) was applied throughout
TYPEIMS, and the conditional tests were restructured.
Thanks to J. Cary Jones, Philip Morris, USA.
Change 08.117 Philip Morris has made this major contribution to MXG
ASMVTOC for DASD management and measurement. They replaced the
JCLDASD functional but slow %VMXGVTOR and %VMXGVTOC programs
VMXGVTOF (which used SAS and CVAF) to read the DASD VTOCs, with
ANALVVDS ASMVTOC, a very fast assembly program that extracts the
Aug 25, 1990 VTOC data into a flat file. JCLDASD is a jobstream to
execute ASMVTOC (and MXG's pre-existing ASMVVDS program)
and it uses VMXGVTOF and ANALVVDS (which were originally
named MPXGVTOC and MPXGVVDS in PreReleases) to
manage, measure, and recover DASD space. This has only
been repackaged before addition to MXG 8.3, but it
has been running at Philip Morris for some time. Note,
however, that it is now Merrill Consutants, and not
Philip Morris who is now responsible for problems!
Thanks to Tuanhung Doanvo, Philip Morris, USA.
Change 08.116 MXG's Quality Assurance job stream is contained in the
JCLUXREF two JCL members, one for 5.18, the second for 6.06, and
JCLUXRE6 the reporting ANAL.... members have finally been added
TESTANAL into the test stream!
Aug 25, 1990
Change 08.115 SAS 6.06 Compatibility. Macro compiler logic error.
ASUMVMON This circumvention was made before it was known that SAS
TRNDCICS ZAP Z6060916 corrected the problem. The %VMXGSUM macro
TRNDJOBS is invoked by these members, and should generate a line
TRNDRMFI SAS code for each variable in the NORMn= list, but this
TRNDTMNT error caused %VMXGSUM to terminate the scan early and the
TRNDVMON code generated was wrong, yet there was no error message!
Aug 24, 1990 The error was discovered because the scan truncated the
name of a variable, causing that variable to surface on
the list of variables without labels in the QA jobstream!
By moving the NORMn= variables in the 2nd and subsequent
lines, the problem seemed to go away, but now that there
is a zap for the problem, put it on and don't trust this
repositioning circumvention.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.114 SAS 6.06 Compatibility. %VMXGFOR macro for FORCE option.
VMXGFOR See ZAP Z6060571 (which was superceded by Z6060969)
Aug 24, 1990 circumvented the need for FORCE on PROC SORTs, but since
that ZAP disables this new FORCE "feature", not all sites
may choose to disable FORCE. So, for those MXG sorts in
which the input and output data sets are the same, this
changes adds %VMXGFOR (which has value FORCE under 6.06,
and a null value under 5.18)in these 65 members. With
this source circumvention installed, the above zap is
now optional, instead of required, for MXG.
However, this change now makes two SAS options mandatory
for execution of MXG. SAS Options MAUTOSOURCE and
SASAUTOS=SOURCLIB is now required to locate the %VMXGFOR
macro which implemented this change. (These options have
always been required for MXG programs which used %MACROs,
such as ANALDB2R, but now ALL executions of MXG must use
these two options to resolve the location of %VMXG...
macros.)
ANALALL ANALAUDT ANALBNCH ANALBNC1 ANALCACH ANALCICS
ANALDB2R ANALDMON ANALDOS ANALESV ANALMNTS ANALMONI
ANALMPL ANALNAF ANALNPA ANALNPM ANALNPMR ANALNSPY
ANALPATH ANALPDSM ANALPROG ANALRRTM ANALSMF ANALSUPR
ANALTAPE ANALTURN ANALVARY ANALVM ANALVMDY ANALVMOS
BUILDPDB BUILDPD3 DIFFDB2 DIFFROSC DIFFTPX GRAFREGR
GRAFRMFI GRAFTMNT GRAFTRND IDMSAPND IDMSJANL JCLHSM
JCLTREND PDBTREND RMFINTRV SYSLOGJ3 TYPEDOS TYPEIMS
TYPEIMS1 TYPEIMS3 TYPEMONI TYPETMS UTILCICS UTILDUMP
UTILPRAL UTILSPAC UTILXRF2 VMACCRAY VMACVMON VMACVMXA
VMXGHSM VMXGSUM VMXGVTOC ZRBRPT1 ZRBRPT2
Change 08.113 Incompatible changes in MXG Trending were implemented by
DOCTREND this change, for prior users of MXG Trending data sets.
GRAFTRND The TREND.RMFINTRV and TREND.TYPE72 data sets have been
JCLTREND renamed to TREND.TRNDRMFI and TREND.TRND72 with MXG 8.3.
TRNDRMFI All that you need to do is to rename these two datasets
TRNDVDEV in your TREND library BEFORE you run the MXG 8.3+ TRND...
TRNDVMON programs, using:
TRND72
Aug 22, 1990 PROC DATASETS LIBRARY=TREND;
CHANGE RMFINTRV=TRNDRMFI
TYPE72 =TRND72 ;
Ok, so now you didn't see this note, you have run your
new TRNDRMFI, and discover only last week's data is in
your trend plots. Have we destroyed your old data? No!
It's still sitting in your TREND library, as datasets
RMFINTRV and TYPE72, but now you can't rename them, as
there's already a TRNDRMFI and TRND72 in your TREND!
In this case, you need only combine the old data sets
with the new data sets:
DATA TREND.TRNDRMFI;SET TREND.TRNDRMFI TREND.RMFINTRV;
DATA TREND.TRND72 ;SET TREND.TRND72 TREND.TYPE72;
and you will have lost nothing and will be compatible!
I apologize for the inconvenience of this change, but the
TREND data sets need to be named differently, because the
contents (especially TRND72) is quite different than the
TYPE72 data set.
The consolation may be the new member, DOCTREND, which is
a preliminary documentation of which members of the Trend
Data Base are built by which members of MXG Software!
Change 08.112 Chuck Hopf's excellent paper on generation of DB2PM-like
DOCDB2PM reports using ANALDB2R (which Chuck wrote) is now added
Aug 22, 1990 to the MXG documentation in DOCDB2PM.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.111 NPM 1.3 Subtype 82 (x'52'), and perhaps other subtypes,
VMAC28 have BASNCPDT and BASNCPTM values of 0, which cause INPUT
Aug 22, 1990 function error when creating BASTIME from those fields.
In line 163610, replace THEN with AND, and insert a new
line containing BASNCPDT GT 0 AND BASNCPTM GT 0 THEN
to eliminate the error message.
Thanks to Ross Pover, Immigration & Ethnic Affairs, AUSTRALIA.
Change 08.110 MXG QA runs uncovered that variable STRTTIME was not kept
TYPEMONI in MONIDBDS and MONIUSER data sets built from Landmark
Aug 22, 1990 CICS data.
Change 08.109 MXG QA now includes testing of the TREND data base, and
JCLTRND as a result, the data sets built by the default TREND
TESTTRND options are documented (finally) in DOCVER and DOVER08
Aug 21, 1990 in MXG 8.3 and later.
Change 08.108 SAS 6.06 Compatibility. Eliminate multiple macro compile.
ASUMCICS These members defined %MACROs VMXGSUM and VMXGDUR using
ASUMDBDS %INCLUDE logic, but this causes a re-compile each time
ASUMDOS that the include is executed. Instead of using %INCLUDE
ASUMTMNT statements, these macros will automatically be defined
ASUMVDEV only one time by the combination of SAS system options
ASUMVMON MAUTOSOURCE SASAUTOS=SOURCLIB (which have always been
TRNDCICS recommended in MXG executions using %MACROs). In an
TRNDDOS unrelated change, DROP DATETIME was also added to each
TRNDJOBS invocation of VMXGSUM to save 8 bytes per observation.
TRNDRMFI
TRNDTMNT
TRNDVDEV
TRNDVMON
TRND72
Aug 21, 1990
Change 08.107 Addition of TREND testing to the MXG QA stream uncovered
TRNDDOS a syntax error, and the delete of DATETIME mention above
Aug 21, 1990 was also added.
Line 001600, delete (DROP=DATETIME) from line
Line 002800, change ;'); to ';
Insert new line after 002800
DROP DATETIME;);
Change 08.106 VM/370 Monitor processing could calculate incorrect value
VMACVMON for date timestamps, but only in the Western Hemisphere,
Aug 20, 1990 and only if the Monitor Start Record (0.97) timestamp in
GMT was after the 202-day interval midpoint and the local
timestamp was before the 202-day interval midpoint, which
at most could occur every 202 days. The error only occurs
in that one day's execution of MXG. The midpoint datetime
of the current 202-day interval was at 04AUG90:03:43:52.
If the VM/Monitor was started on that date at 00:00 local
time, all Western Hemisphere sites had a GMT of 05:00 or
later, and MXG calculated STARTIME 43 minutes too early!
Whew! The error is in the heuristic algorithm to decode
the 5-byte datetimestamp (only 202 days fit in 5 bytes).
and determine the timezone value, which did not protect
for the preceding situation. Replace lines 209200 thru
029600 (now and IF (16*MNHTOD ... to END; ) with:
IF (COLLTIME-BASETIME) GT 0.75*FFFFF AND 16*MNHTOD LT 0.25*FFFFF
THEN BASETIME=BASETIME+FFFFF;
ELSE IF (COLLTIME-BASETIME) LT 0.25*FFFFF AND 16*MNHTOD GT
0.75*FFFFF THEN BASETIME=BASETIME-FFFFF;
IF 16*MNHTOD GT FFFFFOV2 THEN LASTHALF=1;ELSE LASTHALF=0;
Thanks to Frank Putnam, Ryerson Polytechnical Institute, USA.
Change 08.105 IDMS 10.2 Batch Jobs ACCOUNT1-ACCOUNT3 fields were not
EXIDMTAS decoded, because no sample data had been seen. Now it has
Aug 20, 1990 been, and you can decode batch job's account fields into
those variables in Exit member EXIDMTAS, which should be
copied into your USERID.SOURCLIB and modified therein to
contain the appropriate substring operations. For example
if your three account fields are 17, 8, and 4 bytes long,
you would insert the below example. (Note that the first
byte of ACCOUNT1 begins in byte 2 of TASBFLDS):
IF TASTTYPE='.1......'B THEN DO; /* BATCH ONLY */
ACCOUNT1=SUBSTR(TASBFLDS,2,17);
ACCOUNT2=SUBSTR(TASBFLDS,19,8);
ACCOUNT3=SUBSTR(TASBFLDS,27,4);
END;
Thanks to Harold L. Correll, Harris Corporate, USA.
Change 08.104 CA7 (formerly UCC7) job scheduling package still corrupts
VMACTSOM SMF records, as first described in Newsletter TEN, 1986.
Aug 20, 1990 CA says 4 sites have reported the problem and they are
"looking into it", but have no immediate plan for a fix.
CA7 modifies the READTIME of a controlled job by writing
a non-zero value in the first byte of its julian date, to
flag that this job is under CA7's control. When that job
terminates, CA7 is supposed to remove its corruption and
restore the valid julian date, before the SMF records are
written. CA7 corrects the SMF record in IEFU83, after the
record has been built, and only corrects the SMF records
that it knows about. CA7 does not know about TSO/MON!!
TSO/MON creates SMF records for batch jobs that execute
TSO commands, and if that job is under CA7 control, that
SMF record contains corrupted READTIME values, causing an
"INVALID DATA FOR READTIME ...", a hex dump of the record
and several pages of variable=value error messages.
Since CA appears incapable of rapid response, and since
the error is likely to show up again, this specific fix
to CA7s corruption of TSO/MON records can generically be
used for any other (future) SMF record corrupted by CA7.
a.Locate all occurrences of inputting READTIME SMFSTAMP8.
in member (in VMACTSOM, lines 034700 and 068800). Change
all occurrences to now read READCA7S $CHAR8. instead.
b.Find the @; which terminates the INPUT statement you just
fixed (in VMACTSOM, lines 040100 and 072500). Insert four
lines after each @; which read:
IF SUBSTR(READCA7S,5,1) GT '01'X THEN DO;
SUBSTR(READCA7S,5,1)='00'X;
READTIME=INPUT(READCA7S,SMFSTAMP8.);
END;
Note that this fix is only waranteed thru Dec 31, 2099.
If CA7 is still corrupting SMF data in the year 2100,
(since they are overwriting the century byte of date)
the 01 in the algorithm will need to be changed to 02!
Thanks to Keith Mo, Empire Blue Cross Blue Shield, USA.
Change 08.103 SAS 6.06 Compatibility. VMXGSUM DROP= conflict.
ASUMVMON Change 8.089 in MXG 8.2 added DROP=MXGMISS MXGNMISS to
TRNDVMON the %VMXGSUM macro, but two members that invoke %VMXGSUM
Aug 12, 1990 already contained DROP= arguments, causing syntax errors
Aug 21, 1990 (that should have been caught in MXG 8.2 testing), and
thus this change only affects recipients of MXG 8.2. But
while we were at it, we also removed the unnecessary
includes discussed above in Change 8.108.
1.ASUMVMON, delete line 001200 to eliminate %INCLUDE.
Line 001600, remove (DROP=WFRENUM DATETIME)
Line 003700, change ;); to ;
Insert new line after 003700 containing
OUTCODE=DROP WFRENUM DATETIME;);
2.TRNDVMON, delete line 001100 to eliminate %INCLUDE
Line 001500 remove (DROP=WFRENUM DATETIME)
Line 003700 remove )
Insert new line after 003700
DROP WFRENUM DATETIME;);
Change 08.102 For the DB2ACCT Accounting data set in a Distributed DB2
VMACDB2 environment, the Distributed Header fields QWSHCCNT,
VMAC102 QWHDLUNM, QWHDNETI, QWHDRQNM, and QWHDUNIQ are now added.
Aug 12, 1990 In the type 102 trace correlation header, QWHCOPID is now
decoded. In both the 101 and 102 SMF records, MXG now
looks for all five possible header types.
Thanks to Mike Atterberry, Rockwell International, USA.
Change 08.101 ANALDB2R Accounting Trace Long worked if the Trace Short
ANALDB2R was requested, but if the Trace Long alone was requested,
Aug 9, 1990 a SORT VARIABLE error occurred. Adding SORTBY=DBT, to the
ANALDB2R invocation will make the problem go away, or
adding these four lines after line 018980 will fix it:
%IF &PMACC02 NE YES %THEN %DO;
%LET SORTN = 1;
%LET SORT1 = %QUOTE(DB2);
%END:
Thanks to Cindy Schinker, AgriData Resources, USA.
Change 08.100 Support for WSF 3.3.0 and WSF 3.3.4 SMF records from the
EXWSFACC WSF sysout archive product from RSD. Five data sets are
EXWSFAUD created, WSFACCT, WSFDSN, WSFERD, WSFEVTS, and WSFEVTP,
EXWSFDSN from the account record, and data set WSFAUDIT is built
EXWSFERD from the audit SMF record. The WSFACCT and WSFERD data
EXWSFEVP sets contain the total READ, WRIT, etc counts from all
EXWSFEVS of the DSNB sections, and the WSFDSN data set contains an
IMACWSF observation for each DDNAME/DSNAME accessed. The WSFERD,
TYPEWSF WSFEVTS (Screen) and WSFEVTP (Printer) datasets contain
VMACWSF CPU time for WSF processing, unique for sysout archivers!
Aug 6, 1990 Member IMACWSF identifies which SMF record is which.
Thanks to Victoria A. Lepak, Aetna Casualty and Surety Company, USA.
Change 08.099 A plethora of VM/XA changes were discovered in a search
VMACVMXA of INFO/SYS using KWS A MONITOR RECORD NEW UPDATE; some
Aug 6, 1990 of the documention for these VM/XA changes required the
actual script of the PTF, and the documentation leaves
a lot to be desired. This is especially sad, because the
VM/XA monitor itself was one of the best documented IBM
products in a long time. I guess that's the difference
between development and maintenance in IBM.
1.VM39921 added variable CALBASE to seven VM/XA datasets
(VXSCLADL,VXSCLDDL,VXSCLAEL,VXUSEACT,VXUSEATE,VXUSEITE)
to identify if this is the base VMDBK or adjunct VMDBK.
2.VM39196 added variable CALMODE to four VM/XA datasets
(VXMTRUSR,VXUSELON,VXUSEACT,VXUSEATE) to indicate the
architectural mode (ESA, XA, or 370) of the guest.
3.VM36026 added variable CALIOACT to VXSYTUWT and variable
HFIOACT to datasets VXUSEINT and VXUSEITE to count the
number of times the user has an asynchronous I/O that
was outstanding.
4.VM36104 adds two new VM/XA monitor records, 0.15 (SYTCUG)
and 0.16 (SYTCUP), measuring LPAR (Logical Partition) CPU
allocation (dispatched) duration. MXG builds two new data
sets, VXSYTCUG (per time interval) and VXSYTCUP (per LPAR
per time interval). The new data is identical to that
in the MVS TYPE70PR SMF data record, and reports on the
utilization of ALL of your LPARs on the hardware platform
whether they are executing VM, MVS, or DOS.
Thanks to Tom Healy, ChemNet Processing, USA.
Change 08.098 Support for IMS/ESA 3.1 IMS log processing is now added.
FORMATS While several additional fields were added to the IMS log
TYPEIMS records 07 and 08, because they were added at the end of
VMACIMS the log record, MXG 7.7 will not fail with IMS 3.1 data!
Aug 6, 1990 Several of the new fields are 8-byte time durations that
are not documented as to format in the IMS log DSECTS,
and the test data received to data was only from BMPs
that had zero values for these durations, so there is
still some validation/verification required. The new
data fields that have been added are:
DBCTL DB I/O measures:
DLRIOCNT - DBCTL DB I/O Count.
DLRTMEPL - DBCTL DB Locking Elapsed Time.
DLRTMEIO - DBCTL DB I/O Elapsed Time.
Delays during program scheduling:
DLRMINT - Wait time for Intent Conflict with another
PSB for scheduling.
DLRMPOL - Wait time for Pool Space for scheduling.
DLRMSCH - Elapsed time for Schedule Processing
(which includes both DLRMINT and DLRMPOL).
There is only one 07 record per program schedule, but it
describes NMSGPROC transactions, if multiple transacts
are executed by a single program schedule. As MXG has had
to do before, these new 07/08 fields are divided by the
NMSGPROC value and thus each ultimate transaction record
in TYPEIMS contains the average count/duration of these
new resource measures.
What has not been tested for IMS/ESA 3.1 is the data
compaction introduced (I think by an SPE to IMS) in
MVS 3.1.3. APARs OY19751, OY19854, OY19860, OY19863 are
involved, and IBM manual GC28-1057, MVS/ESA Data
Compression and Expansion Services describe the new
callable macro CSRCESRV which is automatically used by
IMS/ESA 3.1 to compress the OLDS and SLDS (System Log
Data Set, the input to TYPEIMS). I am still researching
if, when, and how the data compression occurs, and would
welcome an IMS/ESA log tape with compression in effect
so that I can figure out how to decompress it in MXG!
Thanks to Hamid Tavakolian, Continuum, USA.
Change 08.097 This circumvention member for the 344 Compiler error had
XMAC73 initialized variable LCI as numeric instead of character.
Aug 6, 1990 Line 014500 should be IF LCI=' ' then LCI=' ';
Only when data from before and after the circumvention is
installed, did this cause a conflict.
Thanks to Richard Evans, Mervyns, USA.
Change 08.096 SAS 6.06 Compatibility. PROC PRINT PAGE option.
ANALESV The PROC PRINT option PAGE no longer exists, and it has
Aug 3, 1990 been removed from this example report.
Thanks to Tom Simons, Matson Navigation, USA.
Change 08.095 SAS 6.06 Compatibility. LIBREF reuse as FILEREF.
MONTHBLD SAS Version 6.06 still does not properly recognize the
Aug 3, 1990 TAPECLOSE=LEAVE or FILECLOSE=LEAVE options when reading
or writing tape format SAS data libraries. Just like 5.18
did, a rewind of each tape library is issued after each
SAS data set is read/written, whereas the LEAVE options
should cause the tape to remain positioned at the end
of the SAS data set just read/written on that tape. The
problem is only that this causes many tape mounts if the
input or output data libraries are multi volumes, and it
causes lots of rewinds (and hence longer elapsed times)
even if only single volume tape libraries are involved.
The problem has been most pronounced in building the
monthly PDB (since that has the highest probability to
be multi-volume). MXG has provided a circumvention in
MONTHBLD for the output tape (ddname MONTH), but changes
in the SAS 6.06 language specifications were made. To
protect users from accidentally overwriting a SAS data
library with a FILE/INFILE statement, SAS 6.06 no longer
allows the same ddname for both a LIBREF and FILEREF at
the same time. The following circumvention is required
in MONTHBLD to free the LIBREF name so it can be reused
as a FILEREF (and, of course, the syntax only works under
SAS 6.06 so that version-dependent macros are required so
that the modified MONTHBLD executes under either 5.18 or
6.06!).
1.Before the second "MACRO _MNTHBLD" definition, insert
these two new compatibility macros:
%MACRO V6COMPEN;
%IF %SUBSTR(&SYSVER,1,1) GE 6 %THEN %DO;
LIBNAME TAPETEMP TAPE ; /*6.06+ TAPE ENGINE*/
%END;
%MEND;
%MACRO V6COMPCL;
%IF %SUBSTR(&SYSVER,1,1) GE 6 %THEN %DO;
LIBNAME TAPETEMP CLEAR; /*6.06+ CLEAR*/
%END;
%MEND;
2.Inside the second "MACRO _MNTHBLD" definition, after the
OPTIONS OBS=MAX; and before the DATA TAPETEMP._DSET;
insert (note double percent sign):
%%V6COMPEN;
3.Inside the second "MACRO _MNTHBLD" definition, after the
IF _BEGIN LE ZDATE LE _END; and before the DATA _NULL_;
insert (note double percent sign):
RUN; %%V6COMPCL; RUN;
Thanks to Bud Porter, City of Birmingham, USA.
Change 08.094 Truncated RMF type 79 SMF records resulted when SMF data
VMAC79 records that were actually LRECL=32760 bytes were dumped
VMAC79 with an incorrect LRECL=32756 specified in the SMF dump
Aug 3, 1990 or copy program. The correct LRECL=32760 must be used.
MXG detected and deleted the defective SMF records, but
did not note on the log this had been done. The type 79
subtype 1 record with 32760 bytes occurs only when there
are 331 or more address spaces active. This change now
reports when bad records have been found and reports that
they were deleted. Insert after line number 017100
(the end of MONITOR II Control SECTION):
L79EXPD=OFFSMF+SMF79ASS-3+SMF79ASL*SMF79ASN-1;
IF SMF79ASS GT 0 AND SMF79ASL GT 0 AND SMF79ASN GT 0
AND L79EXPD GT LENGTH THEN DO;
N79BADAS=1;
IF N79BADAS LT 10 THEN PUT
' EXPECTED ' L79EXPD
' BYTES, BUT LOGICAL DATA IS ONLY ' LENGTH
' BYTES IN RECORD. RECORD DELETED.';
END;
Thanks to Ken Trayes, General Electric Capital, USA.
Change 08.093 The 8.2 PreRelease copy of VMACZRB has now been validated
VMACZRB by the original author of the RMF III processing support,
Aug 3, 1990 who discovered that all X'04' must be changed to $ and
all X'52' must be changed to "not" signs. Guess what MXG
source code went from EBCDIC to ASCII and back to EBCDIC!
To avoid future character set conversion problems, I have
further changed all "not-symbol equal signs" to " NE ".
(In printing this change, which was down loaded from MVS
to PCDOS, the "not-symbols" were converted and printed as
"caret" symbols! Please do not use not-symbols!)
Thanks to Dick Whiting, Precision Castparts, USA.
Change 08.092 STC's 4400 Silo SMF record will contain a new subtype 7
EXSTCHSC for HSC 1.1.0. This change adds support for that new
FORMATS subtype, and creates a new STCHSC data set, with some
VMACSTC 60 new variables. New $MGSTCxx. formats were also
Aug 2, 1990 created to decode several variables.
Change 08.091 Amdahl's MDFTRACK SMF records were not quite right. Six
VMACMDF variables, DOMMIN,DOMTGT,DOMMAX,DOMNORM,DOMATGT,DOMUTIL
Aug 1, 1990 were missing.
1.In lines 011700 thru 012300, where these variables were
INPUTed as ?? PD4.2, they should instead be PIB4.
2.Insert six new lines, after 014200, to convert these six
fields to their screen values:
DOMATGT=FLOOR((((DOMATGT)/GBLELTM)+5)/10); 014210
DOMMAX =FLOOR((((DOMMAX )/GBLELTM)+5)/10); 014220
DOMMIN =FLOOR((((DOMMIN )/GBLELTM)+5)/10); 014230
DOMNORM=FLOOR((((DOMNORM)/GBLELTM)+5)/10); 014240
DOMTGT =FLOOR((((DOMTGT )/GBLELTM)+5)/10); 014250
DOMUTIL=FLOOR((((DOMUTIL)/GBLELTM)+5)/10); 014260
Thanks to Vince Loeffler, Searle, USA.
Thanks to Martin Tavener, Reed Travel Group, ENGLAND.
Thanks to Myron King, The Equitable, USA.
Change 08.090 These extensive validation corrections to ACF2 support
VMACACF2 correct the ARE processing, and clean up several other
Aug 1, 1990 minor bugs. This replaces the temporary fix for the
ARE that was made by Change 8.002, and this fix should
have been in PreRelease 8.2, but got lost temporarily!
1.Lines 010400-010500, remove ACEEMLTH ACEELDNM ACEVLOFF &
ACEFLDVL, as they do not exist.
2.Line 011700, ACLMAMFS should be ACLMAFMS.
3.Lines 032600,032700 change ACTMFTOD to ACSMFTOD.
4.Line 035900, change PIB8. to TODSTAMP8.
5.Lines 037300-037400 can be deleted.
6.Line 046200 can be deleted.
7.Line 016010 inserted after 016000 naming all five of
the ACJ..... variables in ACF2TR.
8.Line 062000 (ACVMFRT PIB1.), insert new line after
containing +1
9.Lines 049100-055900 were completely re-written to
properly decode the ARE segments.
Thanks to J. R. Dravnieks, Ladbroke Computer Services, NETHERLANDS.
Change 08.089 Obscure. Using the FREQ= options of VMXGSUM can result in
VMXGSUM erroneous counts if all variables in the MIN=,MAX=,MEAN=,
Jul 31, 1990 or SUM= macro arguments contain missing values.
Replace three lines 034900-035100 (now reading):
%IF %LENGTH(&FREQ) NE 0 %THEN %DO;
N=&FREQ
%END;
with these two lines:
NMISS = MXGNMISS
N = MXGMISS
Change line 035300 to read:
DATA &OUTDATA (DROP=MXGMISS MXGNMISS);
Insert the following after line 035600:
%IF %LENGTH(&FREQ) NE 0 %THEN %DO;
&FREQ = SUM(MXGMISS,MXGNMISS);
%END
Change 08.088 Early alpha tests of a new DB2 monitor created an SMF 100
VMACDB2 subtype 1 data record with a subtype field of zero, which
Jul 30, 1990 caused MXG to STOPOVER abend. Although the real cause of
the error was a bad record (that was immediately fixed),
this change was added to enhance MXG to be more robust
and to avoid the STOPOVER even in the face of bad data!
It's unlikely you will need to install this insurance:
1.Line 086200 should be LENQLST PIB2. vice OFFQLST PIB2.
2.After line 088700 ( IF QWHSLEN GE 52 THEN ...), insert:
IF QWHSNSDA LT 13 THEN OFFRSV3=.; 088710
IF QWHSNSDA LT 12 THEN OFFQJST=.; 088720
IF QWHSNSDA LT 11 THEN OFFQLST=.; 088730
IF QWHSNSDA LT 10 THEN OFFQSST=.; 088740
IF QWHSNSDA LT 9 THEN OFFQVAS=.; 088750
IF QWHSNSDA LT 8 THEN OFFQVLS=.; 088760
IF QWHSNSDA LT 7 THEN OFFQWSD=.; 088770
IF QWHSNSDA LT 6 THEN OFFQ9ST=.; 088780
IF QWHSNSDA LT 5 THEN OFFQ3ST=.; 088790
IF QWHSNSDA LT 4 THEN OFFQWSC=.; 088791
IF QWHSNSDA LT 3 THEN OFFQWSB=.; 088792
IF QWHSNSDA LT 2 THEN OFFQWSA=.; 088793
3.After line 125400 ( IF QWHSLEN GE 52 THEN ...), insert:
IF QWHSNSDA LT 7 THEN OFFEDM =.; 124510
IF QWHSNSDA LT 6 THEN OFFQTXA=.; 124520
IF QWHSNSDA LT 5 THEN OFFQIST=.; 124530
IF QWHSNSDA LT 4 THEN OFFQBST=.; 124540
IF QWHSNSDA LT 3 THEN OFFQTST=.; 124550
IF QWHSNSDA LT 2 THEN OFFQXST=.; 124560
4.After line 165700 ( IF QWHSLEN GE 52 THEN ...), insert:
IF QWHSNSDA LT 6 THEN OFFR5 =.; 165710
IF QWHSNSDA LT 5 THEN OFFQTXA=.; 165720
IF QWHSNSDA LT 4 THEN OFFQBAC=.; 165730
IF QWHSNSDA LT 3 THEN OFFQXST=.; 165740
IF QWHSNSDA LT 2 THEN OFFQWAC=.; 165750
Thanks to Benny Maynard, BiLo, Inc, USA.
==============Changes thru 8.087 comprised MXG PreRelease 8.2===========
Change 08.087 Lines 046800 thru 047100 should have denominator TRANSNO
VMACNSPY instead of TOTRSPNO for calculation of T1RSPPC-T4RSPPC.
Jul 20, 1990 If this DO group was entered (not likely), missing values
were calculated because TOTRSPNO was missing. This only
affected the NSPYLU data set values.
Thanks to Marty Quinlan, Virginia Power, USA.
Change 08.086 PreRelease validation identified many datasets which did
DOC not have ZDATE, some $MG.. formatted variables that were
Jul 20, 1990 length 8, some DATETIME variables that were not length 8,
and many variables with no label. Uninitialized variable
messages were also detected and corrected, and the TREND
data base code was added to the MXG Validation/Cross
reference testing.
Change 08.085 This JCL member contains IDCAMS control statements and
JCLVSAM JCL to build a VSAM ESDS data set that is needed only for
Jul 20, 1990 MXG testing of RMF III (VMACZRB) code.
Thanks to Jeannie Hopf, Hopf Consulting, USA.
Change 08.084 This is a significant internal revision to DB2 reporting
ANALDB2R from SMF trace data. Previously, you had to update/edit
Jul 20, 1990 member IMAC102 to tell MXG what trace classes had been
enabled. If you did not update IMAC102 correctly, MXG
would create zero observations in T102Snnn datasets, even
though there were SMF records for IFCIC nnn in your SMF
file. Now, when you specify PDB=SMF in ANALDB2R, the
program is smart enough to know which datasets are needed
and ANALDB2R no longer uses IMAC102 to control T102S...
datasets. (Note: IMAC102 is still needed if you use the
TYPE102/VMAC102/BUILDPDB method of processing DB2 trace
type 102 records; this change applies only to ANALDB2R,
and only when PDB=SMF is specified to read SMF data.)
Additionally, macro variables corresponding to macro
names constructed by IMAC102 were added to ANALDB2R to
allow you to select specific trace class(s), using the
syntax of DB2TC1=YES as the argument when you invoke the
%ANALDB2R report macro. Documentation (comments in the
member itself) was added to describe the new parameters,
and also to list which trace classes must be enabled for
each report group. The member was renumberd.
Change 08.083 Dataset VXIODDEV variables AVGPNDMS,AVGDISMS,AVGCONMS are
VMACVMXA incorrect (but this should not affect most users, as this
Jul 20, 1990 detail dataset is not typically used; instead VXDEVTOT
and VXSUMIOD are used and their values were correct). But
now, even these variables are always correct.
Dataset VXPRCPRP variable HFUSERZ is now formatted 5.1
and multiplied by 100, as it is a percentage, not a rate.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 08.082 Support for APAR OY32638 which (finally!!) adds PROCSTEP
IMAC30 to the type 30 record datasets, and to the PDB.STEPS data
VMAC30 set in your PDB. This procedure stepname has been wanted
Jul 20, 1990 since OS/360. However, what is still wanted and still not
provided in any SMF record is the actual name of the JCL
procedure that was executed by the user on the EXEC card!
Change 08.081 Support for APAR OY25606/OY33312, which (incompatibly)
VMAC30 added a new 4-byte field (SMF30EOS) to replace the 2-byte
Jul 14, 1990 existing SMF30EOR. Without this change, MXG variable
EXTRADD will contain a value of 61682, but as that is
not actually used by MXG, the incompatibility is one of
principle rather than one of fact. The EXTRADD field had
to be expanded from half-word to full-word to keep count
of the number of extra DD segments in additional SMF
type 30 records that can be written if the new DDCONS(NO)
option is specified. See extensive discussion in IBM's
Washington Systems Center Flash Number 9027, and further
notes in the next MXG newsletter. Inserted to correct:
IF OFFPROD-3-COL GE 6 THEN INPUT @105 EXTRADD PIB4. @;
Thanks to George Scott, Rockwell International Corporation, USA.
Change 08.080 Support for ORACLE SMF Record. The data set ORACLE is
ANALORAC built from the SMF record ID specified in IMACORAC
EXORACLE (which should be copied into your USERID.SOURCLIB and
IMACORAC changed therein). A set of sample reports are also in
TYPEORAC ANALORAC. This user contribution was reformatted and
VMACORAC has been tested with a small sample of ORACLE data.
Jul 7, 1990
Thanks to David Henley, Signet Bank/BISYS, USA.
Change 08.079 Significant validation of RMF III VSAM records is in this
VMACZRB user enhancement. In addition to corrections in VMACZRB,
TYPEZRB new members ZRBCHECK will check the integrity of these
ZRBCHECK datasets produced by VMACZRB, and member ZRBMXIDX now
ZRBDLYBT summarizes and builds an index for the datasets that are
ZRBMKIDX built from VMACZRB, and member ZRBDLYBT reads the index
Jul 7, 1990 and summarized datasets to produce delay reasons for
batch jobs. VMACZRB0 is a backup of previous VMACZRB.
Thanks to Roland Rashleigh-Berry, National Westminster Bank, ENGLAND.
=========Changes thru 8.078 were printed in Newsleter SEVENTEEN=========
Change 08.078 SAS 6.06 Compatibility. Comma after last argument.
TRNDJOBS An extraneous comma after line 002900 works under 5.18
Jul 4, 1990 but is flagged as an error under 6.06. This comma is
after the last macro argument, immediately preceding the
close parenthesis, and was not required, so its gone.
Thanks to M. Cambier, Credit Lyonnais, FRANCE.
Change 08.077 The variable ACCESS should have been created in the exit
ANALDSET for TYPE64, but was not. Insert new line after 007300
Jul 4, 1990 setting ACCESS='VSAM';
Thanks to John R. Grout, Midlantic National Bank, USA.
Change 08.076 Further validation of Trending uncovered incorrect code
ASUMCICS in these ASUM.... members (that take detail data like
ASUMJOBS CICS transactions, JOBs, etc. and summarize in groups).
ASUMTMNT 1.Response buckets in ASUMCICS were off by one bucket. In
Jul 4, 1990 lines 009900 thru 010500 change LE to LT, and in line
010700 change RESPMAX=RESP to RESPMAX=IRESPTM.
2.Similarly, in ASUMJOBS change lines 003600 thru 004200
from LE to LT.
3.Similarly, in ASUMTMNT change lines 002400 thru 003000
from LE to LT.
Thanks to Jim Hinkel, Weyerhaeuser Company, USA.
Change 08.075 The VTOC processing code did not capture free space that
VMXGVTOC is located at the very beginning of the volume. This
Jul 4, 1990 change added about 30 lines to recognize that situation.
Thanks to Uriel Carrasquilla, Vancouver Stock Exchange, CANADA.
Change 08.074 Preliminary support for IBM System Managed Storage (SMS)
EXDCOCLU utility program DCOLLECT, that creates a flat file of
EXDCODSN Data Set, Cluster, and Volume information from SMS. This
EXDCOVOL significant user contribution creates three MXG datasets,
IMACDCOL DCOLCLUS, DCOLDSET, and DCOLVOLS from DCOLLECT output.
TYPEDCOL Not all of the variables have been decoded, and the code
VMACDCOL may be enhanced in the future with decoding formats.
Jul 4, 1990
Thanks to Tom Skasa, General Electric Medical Systems, USA.
Change 08.073 Considerable validation of the VVDS record created by MXG
VMACVVDS member ASMVVDS and processed by VMACVVDS has uncovered
Jun 28, 1990 several errors and additional variables are created.
1.Variables VVRCATSD VVRCOMTP VVRKRQ VVRSELFD VVRSPCFG
VVRSPCOP and VVRSSDAT should be added to the KEEP list.
2.These seven new variable's labels should be added:
VVRCATSD = 'SELF-DESCRIBING*VVR FOR*CATALOG'
VVRCOMTP = 'COMPONENT*TYPE'
VVRKRQ = 'KEY*RANGE*QUALIFIER'
VVRSELFD = 'SELF-DESCRIBING*VVR FOR*VVDS'
VVRSPCFG = 'SPACE*FLAGS'
VVRSPCOP = 'SPACE*OPTIONS'
VVRSSDAT = 'SEQUENCE*SET*WITH DATA'
3.Add variables VVRALTSP VVRAMSTS and VVRTMSTP length 8 to
the LENGTH statement at line 012900.
4.Add variables VVRALSTP VVRAMSTS and VVRTMSTP to the
FORMAT statement at line 014300 with DATETIME21.2;
5.After line 016500 (before the END; before 'D8'X), insert
IF VVRFLAG='.1......'B THEN VVRSELFD='Y';
IF VVRFLAG='..1.....'B THEN VVRCATSD='Y';
IF VVRFLAG='....0...'B THEN VVRCOMTP='D'; /* DATA */
ELSE VVRCOMTP='I'; /* INDEX */
6.Change SMFSTAMP8. in 024100, 024200 and 029100 to
TODSTAMP8.
7.Change test '....1...'B for VVRA1IUP in line 024900 to
instead test '.....1..'B.
8.After line 026000 (after IF VVRAIXFG ...), insert
IF VVRSPCFG='11......'B THEN VVRSPCOP='CYL';
ELSE VVRSPCOP='TRK';
9.In lines 030600 thru 031200 the test for VVRDSATR should
instead test VVRAMATR.
10.Change all " IB" to " PIB" (binary numbers should be
PIBn. rather than IBn. to prevent unexpected negatives.)
Thanks to Tuanhung Doanvo, Philip Morris, USA.
Change 08.072 SAS 6.06 Compatibility. ID statement different.
TRNDRMFI To avoid a very obscure exposure if SU_SEC was missing,
Jul 3, 1990 the order is now ID = NRCPUS PARTNCPU SU_SEC STARTIME,
Change 08.071 SAS 6.06 Compatibility. AUTOCALL fails.
ANALDB2R The first line of an AUTOCALLd macro cannot be non-blank
VMXGGOPT in column 72 of the first line of the member, until SAS
VMXGHSM ZAP Z6060946 exists.
VMXGINIT
VMXGVTOR
Jun 29, 1990
Change 08.070 The MXG 7.7 Tape Mount Monitor (in ASMTMNT) does work on
ASMTMNT MVS/ESA as well as MVS/XA (and, also for MVS/370!). The
Jun 29, 1990 comment in that member is wrong; the code had been tested
under MVS/ESA last year. The argument yy of SYPARM(xx,yy)
value of SP builds the MVS/370 monitor, using XA for yy
creates a monitor that works on either MVS/XA or MVS/ESA.
This change only changed the comments, not any real code.
Change 08.069 BUILDPDB/3 has been enhanced in several ways.
BUILDPDB 1.The contents of the SPIN library are now copied into the
BUILDPD3 PDB library at the end of BUILDPDB/3 processing. This is
Jul 3, 1990 both for Backup/Recovery and for possible analysis.
Should you ever need to back up and recover your PDB jobs
you would simply go back to the last successful PDB, and
copy (PROC COPY IN=PDB OUT=SPIN; SELECT SPIN:;) the SPIN
data sets from that PDB into your SPIN library, and then
re-process the input SMF data.
In addition, by inclusion of the SPIN data sets in your
PDB, jobs which executed yesterday but have not yet
purged will be available in the SPIN30_5 (and their steps
in the SPIN30_4) data set for timely reporting.
2.Job accounting variables ACCOUNTn and SHIFT were added to
the PDB.SMFINTRV data set. SHIFT is defined by your shift
definition in IMACSHFT, applied to the interval INTBTIME
begin time stamp. This would allow shift by shift charging
for your long running jobs, but if you do so, you must be
careful to not double charge between the PDB.SMFINTRV and
the duplicate data in PDB.JOBS and/or PDB.STEPS.
The BUILDPDB logic was slightly altered by this change.
Previously, the PDB.SMFINTRV data set was built by sort
of the TYPE30_V before the EXPDBSPN exit. Now, the logic
is relocated to after all EXPDB... exits, just before
the SPIN library is updated. Completed jobs (PDB.JOBS)
and incomplete jobs (SPIN30_1) are now merged with the
type 30 interval records and output in PDB.SMFINTRV.
Unless you used exit EXPDBSPN and expected PDB.SMFINTRV
to exist in that exit, there is no compatibility issue.
you have used EXPDBSPN
3.TYPE25 data set (JES3 Main Device Scheduled) is now added
automatically to the JES 3 PDB built by BUILDPD3.
Change 08.068 SAS 6.06 Options are controlled by the DDNAME of CONFIG
CONFIG in the SAS606 procedure. The MXG library now contains
Jun 28, 1990 the CONFIG member, which has been used in all of MXG's
testing discussed in Newsletter SEVENTEEN. It may change
as more is discovered in testing SAS 6.06, but it is here
so that you will know what options we had changed from
SAS's defaults. You may find a separate CONFIGTSO member
useful to specify NODMS, NOCENTER, etc., because SAS 6.06
does not automatically recognize the TSO environment. In
the production version 8 there will likely be multiple
CONFIG... members.
* INITIAL RECOMMENDATION FOR CONFIG OPTIONS FOR SAS 6.06.01 IN BATCH
* THESE ARE SUBJECT TO CHANGE AS WE LEARN MORE ABOUT 6.06.
* YOU CANNOT USE /* */ DELIMITER FOR COMMENTS IN CONFIG MEMBER
NOIMPLMAC
MAUTOSOURCE
SASAUTOS=SOURCLIB
FULLSTATS
STIMER
SORTDEV=3380
BUFNO=3
MEMSIZE=12M
PROCLEAVE=100K
SYSLEAVE=100K
VMCTLISA=40K
VMPAISA=256K
VMPAOSA=128K
VMPBISA=512K
VMPBOSA=128K
PSUP=SASXKERN
SORT31PL
SYSIN=SYSIN
Change 08.067 ANALDB2R reporting was slightly different than IBM DB2PM.
ANALDB2R 1.The Accounting Detail showed average instead of total for
Jul 3, 1990 Class 3 System Events. Moved variables QWACARNA,QWACARNE
from MEAN= at line 015240 to the SUM= at line 015330.
2.The ELAPSED time on the MXG report was the ending minus
starting time, instead of the sum of the plan execution
durations. Deleted lines 109400-109430 and 117940-117970
DURATM
%IF .......
%ELSE ....
;
in both places.
3.Selection criteria in MXG reports incorrectly used ending
time stamp instead of start time, causing MXG to report a
different set of intervals than DB2PM. Change to read:
line 006590 and 015850 IF "&BEGTIME"DT LT QWACESC;
line 006620 and 015880 IF "&ENDTIME"DT GT QWACBSC;
line 084930 and 110050 IF "&BEGTIME"DT LT QWHSSTCK;
line 084950 and 110080 IF "&ENDTIME"DT GT STRTTIME;
Thanks to Piara Singh, Ministry of Health, SINGAPORE.
Change 08.066 This change supports the new "SRCL" field added to RMF
VMAC7072 product section by APAR OY28449 and PTF UY49092. The
VMAC71 text of the PTF claims that
VMAC73 "the APAR will not impact the customer unless they
VMAC74 have private programs that process RMF - SMF records.
VMAC75 The customer will have to modify their programs/execs
VMAC76 to include the new SRCL field..."
VMAC77 but there is NO impact on MXG 7.7. The new field was
VMAC78 already a reserved field in the RMF product section, and
VMAC79 its value is currently always zero. This change uniformly
XMAC7072 renames the reserved field @OFFRMFP+51 as RMFSRCL, but
XMAC71 only for possible future use when IBM actually puts a
XMAC73 non-zero value in the field (which is suposed to be an
XMAC74 indicator of the RMF source level that created the RMF
XMAC75 record).
Jul 2, 1990
Change 08.065 This announces support for CICS/ESA Releases thru 3.1.1
EXCIC... Monitor and Performance data. Forty seven MXG datasets
FORMATS are created from the new Statistics class data, and new
IBCICTRN variables were added to CICSTRAN and CICSEXCE. Two data
PRCICALL sets no longer exist in CICS/ESA: CICSACCT was always
UTILCICS redundant with CICSTRAN, and CICSYSTM's interval data is
VMAC110 now contained in (and significantly enhanced) in the 47
VMAC110B new CIC..... CICS statistics datasets. See the technical
VMAC110M note in MXG Newsletter SEVENTEEN documenting changes.
Jun 30, 1990 a.The new member VMAC110 contains support for all CICS data
(1.5,1.6,1.6.1,1.7,2.1,3.1.0, and 3.1.1) concurrently.
b.Member VMAC110B is the backup copy of VMAC110 before the
3.1.1 changes. It will not exist in the next prerelease.
c.VMAC110M processes only subtype 1 records for CICS/ESA
and previous CICS's; it does not process new Statistics
structure, but does know about new fields in the CICS
dictionary in 3.1.1. It may be needed to avoid a SAS 344
Compiler Limit exceeded error under SAS 5.18 for sites
that do not have SAS 6.06 available.
d.FORMATS member on MXG 8.2 contains new CICS formats.
e.IBCICTRN labels all CICSTRAN variables with the CMODHEAD
name from the dictionary. Then, you can
PROC PRINT DATA=CICSTRAN SPLIT='*';
%INCLUDE SOURCLIB(IBCICTRN);
to print the CICSTRAN monitor data with IBM headings.
Useful when you need to talk to IBM about their data!
f.PRCICALL will print (with or without SPLIT='*') all 47
new CIC.... data sets and the pre-existing four as well.
The OBS= parameter limits print to first 300 obs, but
even that can be lots of paper.
g.UTILCICS knows about the CICS/ESA dictionary, but has not
yet been updated for connectors, as there has been no
need thus far for that enhancement.
h.See NEWSLETTER SEVENTEEN for initial documentation.
Change 08.064 Boole and Babbage's IMS Measurement Facility (IMF/CIMS)
VMACCIMS product Release 2.6 supports IMS 3.1 with no changes in
Jun 24, 1990 the IMF data records written to the IMS log, so therefore
MXG now (and before) supports IMS 3.1 IMF records!
Change 08.063 SAS 6.06 Compatibility. SAS/STAT existence and ID.
GRAFTRND Added SASSTAT option to indicate you have SAS/STAT.
Jul 3, 1990 Added error message if SU_SEC (used to normalize CPU in
plots) is missing. Default device changed to PCBATCH.
Code was consolidated, enhanced and renumbered.
Thanks to Bruce L. Green, Medical Information Bureau, USA.
Change 08.062 SAS 6.06 Compatibility. PROC MEANS vs SUMMARY.
ANALBNCH Each PROC MEANS NOPRINT execution with an OUT= option
ANALBNC1 was located and (DROP=_FREQ_ _TYPE_) was added after the
ANALCACH output data set name in the OUT= option, so that these
ANALCICS variables (created because 6.06 PROC MEANS now actually
ANALDB2R is PROC SUMMARY) are not kept. At the same time, all
ANALDMON PROC MEANS statements were re-ordered so that the NOPRINT
ANALDOS option immediately follows the MEANS, for consistency.
ANALESV
ANALMNTS
ANALMONI
ANALMPL
ANALNPMR
ANALPROG
ANALSMF
ANALTAPE
ANALTURN
BUILDPDB
BUILDPD3
IDMSREPT
IMACPDB
RMFINTRV
VMACCRAY
VMACVMON
VMACVMXA
VMXGHSM
VMXGSUM
VMXGVTOC
XPAII
Jul 3, 1990
Change 08.061 SAS 6.06 Compatibility. PROC COPY GCAT change.
GRAFRMFI Replaced use of PROC COPY with the COPY command of PROC
Jul 3, 1990 GREPLAY. Deleted GROUPing logic if executed under SAS
6.06. Changed default device to PCBATCH.
Change 08.060 SAS 6.06 Compatibility. DROP= validation.
VMACVMON Remove MN002RS1,MN002RS2,MN003RSV from DROP= option in
Jun 14, 1990 line 361600. Remove INTERVAL from DROP=option in lines
361800, 362000, 362200, 362400, and 362600.
Change 08.059 SAS 6.06 Compatibility. Parser error. PROC SORT
ANALCICS DATA=_CICTRAN. CICSTRAN fails with a 201 error, but it
Jun 14, 1990 accepts _CICTRAN.CICSTRAN or _CICTRAN . CICSTRAN syntax.
SAS 5.18 didn't care about blanks before or after the
delimiter period in a full data set name.
Will not be repaired until SAS 6.07.
Thanks to Dennis Longnecker, Admin. for the Courts, WA. State, USA.
Change 08.058 This TREND example needed a PROC SORT; BY SYSTEM PERFGRP;
JCLTREND to be inserted before line 005900 (PROC PLOT) to avoid a
Jun 14, 1990 non-sorted condition.
Thanks to Tom Elbert, John Alden Life Insurance, USA.
Change 08.057 Invalid type 6 SMF records can cause an MXG STOPOVER. In
VMAC6 most cases, the record is created by an external writer
May 9, 1990 that lies (by storing subsys of 2 instead of 0, making me
believe this is a JES-written record), but it can also be
caused by an IBM-written record with incorrect data.
This change adds an additional test to detect the invalid
record and avoids the STOPOVER. Replace the three lines
that test SECTIND (lines 022500, 025400 and 028800) with:
IF SECTIND='1.......'B AND OFTONXT+35 LE LENGTH THEN DO;
IF SECTIND='.1......'B AND OFTONXT+ 5 LE LENGTH THEN DO;
IF SECTIND='..1.....'B AND OFTONXT+46 LE LENGTH THEN DO;
Even these tests are not sufficient when a SMF6LN3 value
says 162 bytes exist, but the record is truncated, as is
found in MVS 3.1.3. For this case, an additonal test was
added to line 027100 which now reads
IF SMF6LN3 GE 162 AND LENGTH-COL+1 GE 124 THEN
Finally, all other conditional input statement are now
protected similar to line 027100 to test both the LENGTH
minus COL plus one, against the data to be inputted.
These MXG circumventions for the defective IBM type 6
record are not necessary if you instead install the APAR
OY29986 PTF UY49159 for JES 2 3.1.3 causing the error.
Thanks to Mark Stafford, PHH Fleet America, USA.
Thanks to Diane McCabe, N.J. Dept. of Treasury/OTIS, USA.
Thanks to Leatha Harlow, Sperry Marine, Inc, USA.
Change 08.056 SYNCSORT SMF record for sorts using E15/E35 exits ahve a
VMACSYNC value of hex 00 for SIRECFM, SORECFM, causing an "INVALID
May 8, 1990 DATA" message and a dump of the input record. Inserting a
double questionmark (SIRECFM ?? 1. and SORECFM ?? 1.) the
invalid data message goes away.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 08.055 RMF Type 79 data validation continues. Formats have been
VMAC79 assigned: R791DP HEX4., R791TRTM and R796TOD TIME12.2,
May 8, 1990 and R794AFC MGBYTES. INPUT statements were corrected:
May 9, 1990 R791TRTM PIB4.3 and R792TDEV PIB4.6. Line 051300 (4096*
R793LOUT) was deleted and removed from MGBYTES format,
new lines added 040610 R792TDEV=128*R792TDEV; and added
060110 R794AFC=4096*R794AFC;to correct units. A number
of other fields which contain memory(pages/frames,etc)
measures were inconsistent. They were either not mult.
by 4096, not Formatted MGBYTES, or did not have (MB) in
their label to indicate they are in units of K,M, etc.
They are all now consistent, and they include:
792: FXBL, PNV, PSWP, PVIO CMNI PIN
794: CMNI CMNO CSAI ERTE HSP LPAI MRTE PRVI PRVO PSPI
PSPO and VIO
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 08.054 RMF Monitor III VSAM dataset records cause STOPOVER with
VMACZRB RMF 4.1.1. Since MXG 7.7 supporte RMF 3.4.1, it is not
May 7, 1990 surprising that the lengths in the RELINFO: table needed
to be changed. However, actual data record lengths do not
agree with IBM documentation, and occasional STOPOVERs
still occur (possibly because these records can span a
physical record). Further research and validation will
be done at a later date, but it appears the code can be
used if STOPOVER in line 000200 is changed to MISSOVER,
and try these values following the label RELINFO:
ASISIZE = 120 (IBM document said 114, MXG 7.7 was 88)
GEISIZE = 132 (IBM document agrees, MXG 7.7 was 96)
SSHSIZ = 264 (IBM document said 260, MXG 7.7 was 240)
Thanks to Jim Stebel, Royal Insurance, USA.
Thanks to Richard Evans, Mervyn's, USA.
Change 08.053 SAS 6.06 Compatibility. A RUN; statement was added
GRAFRMFI before each PROC GREPLAY to isolate potential problems,
May 7, 1990 the test for Version EQ 5 was changed to GE 5.
Change 08.052 Type 37 processing directly from VSAM SMF records was
VMAC37 not complete. In lines 017400, 019100, 021300, 022700,
May 7, 1990 024800, 025700, 028100 and 032000 add +OFFSMF after -3.
Thanks to Herr Lehmann, GRZ Norddeutschland, GERMANY.
Thanks to Herr Kumellis, GRZ Norddeutschland, GERMANY.
Change 08.051 Line 008200 should be spelled CPUOVHTM vice CPUOHVTM,
GRAFTRND and GOUT=TREND.GRAPHS should be GOUT=&TREND..GRAPHS in
May 7, 1990 all five places to be consistent with other references.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 08.050 TSO/MON now supports TSO measurement of Batch execution,
VMACTSOM and thus JOB $CHAR7. in line 068700 should be changed to
May 7, 1990 JOB $CHAR8. TSO Userid's were restricted to seven chars,
but batch jobs can be all eight positions. Minor.
Change 08.049 Documentation note. Data set TYPE78CF will contain an
VMAC73 observation only if a CHPID is online (because NRCUS must
VMAC78 be non-zero), but the TYPE73 dataset will contain an obs
May 7, 1990 for each CHPID in the record, whether online or not. Why
the difference? They were written at different times!
To be consistent, I should externalize both tests to the
exit members and consistenly keep only those CHPIDS that
are online (to minimize the unnecessary data in your PDB)
but for now I will leave it the way it is.
Thanks to Laurie Maser, Central Illinois Light Company, USA.
Change 08.048 Variables ABNDRSNC DIVRREAD DSSIZHWM and TERMNAME were
IMACPDB not kept in PDB.STEPS from TYPE30_4, but now were added
VMAC30 in macro _PDB30_4 in member IMACPDB, so they are. Also,
May 7, 1990 variable DSSIZHWM was added to the KEEP list for dataset
TYPE30_V (and thus also will be in PDB.SMFINTRV)
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 08.047 ACF2 dataset ACF2JR will have fewer observations with
EXACFJR MXG 7.7 than it contained with MXG 6.6, because a test
May 4, 1990 in EXACFJR inadvertently deleted SMF records. Remove
the temporary fix "IF ACLEMLTH LT 256;" statement and
its associated comment.
Thanks to Ilana Towery, Houston General Insurance Company, USA.
Change 08.046 Pre-release 8.1 shipped to support ESP product.
May 4, 1990
Change 08.045 MXG's algorithm to detect the wrap of the 202-day clock
VMACVMON in VM/SP failed at 24APR90:08:22:10. MXG's next timestamp
May 4, 1990 was 02OCT89:17:40:04, and the rest of the records in that
VM Monitor file had the Oct 2, 1989 date, because 16* was
left out of line 029400 when Change 6.023 was installed.
The test for new interval in line 029400 should read:
IF LASTHALF AND 16*MNHTOD LT FFFFFOV2 THEN DO;
The incorrect STARTIMEs only occurred on the day of the
clock wrap; the next MXG run (or a monitor start event)
corrected the MXG error.
Thanks to Nancy Ayers, General Electric Lighting, USA.
Change 08.044 Preliminary support for the Cray supercomputer COS 1.16
EXCRA... operating system accounting and performance records. This
VMACCRAY support requires SAS Version 6.06+ (because of ASCII
May 3, 1990 character variables). Future revisions will support the
COS 1.17 changes, and eventually, UNICOS as well. There
are 6 CRAYA... datasets built from account records,
16 CRAYP... datasets built from SPM performance records,
and the MXG-built CRAYPINT "Interval Performance" dataset
built by sum/merging those 16 SPF datasets.
These datasets are currently built:
CRAYAEJ Label='Accounting Job Termination'
CRAYAET Label='Accounting Task Termination'
CRAYAFU Label='Accounting BMR Device Utilization'
CRAYAGU Label='Accounting Generic Resource'
CRAYAPD Label='Accounting Permanent Data'
CRAYATA Label='Accounting Tape Data'
CRAYPCP Label='SPM CPU Times and Task Times'
CRAYPTK Label='SPM Task Requests'
CRAYPER Label='SPM Executive Requests'
CRAYPMU Label='SPM Memory Utilization'
CRAYPDU Label='SPM Disk Utilization'
CRAYPDC Label='SPM Disk Channel'
CRAYPLU Label='SPM Link Utilization'
CRAYPEC Label='SPM Executive Calls'
CRAYPUC Label='SPM User Calls'
CRAYPPU Label='SPM Preemptable Generic Resources'
CRAYP11 Label='SPM JSH Statistics'
CRAYP12 Label='SPM Job Class Information'
CRAYP13 Label='SPM JSH Request Count'
CRAYPIC Label='SPM Channel Interrupts'
CRAYPSB Label='SPM System Buffer Utilization'
CRAYPINT Label='SPM Interval Performance'
Change 08.043 NETSPY Version 3.1 (3.2 is current) can cause a STOPOVER
VMACNSPY because the test in line 032300 should be NSPYENTL GE 177
Apr 30, 1990 (the current test was NSPYENTL GE 167).
Thanks to David B. Adams, National Life of Vermont, USA.
Change 08.042 IMS log processing variable VTAMNODE should be added to
VMACIMS the IMS03 and IMS36 dataset KEEP list and removed from
Apr 30, 1990 the IMS01M dataset KEEP list. The two occurrences of
IF VTAMNODE GE ' ' ... should be changed to now test for
IF VTAMNODE NE ' ' ....
Thanks to Pete Shepard, Ashland Oil, USA.
Change 08.041 EXPLORE/VM second occurrence of CHANBUSY in the LABEL and
VMACVMXP INPUT statements (lines 054000 and 056600) should be
Apr 30, 1990 changed to CHANBUS2 and variable CHANBUS2 should be added
to the KEEP list (line 005700). CHANBUSY is the IPL-proc
Channel Busy and CHANBUS2 is the non-IPL-proc chan busy.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 08.040 MXG 7.7 can have 0 observations in CICS datasets built
VMAC110 from CICS 1.7 records. An anticipatory change was added
Apr 30, 1990 that used a reserved field, but the field is not always
Jun 30, 1990 zero in 1.7 (but it seems okay in CICS 2.1). Either
delete line 025320 (IF SUBTYPE NE 0 THEN DELETE;) for the
present, or if you have both CICS 1.7/2.1 records and
are also testing CICS/ESA 3.1.1, change the logic to:
INPUT @31+OFFSMF OLDVERCI $CHAR2. @19+OFFSMF SUBTYPE PIB2. @;
IF '02' LE OLDVERCI LE '03' THEN SUBTYPE=0;
IF SUBTYPE NE 0 THEN DELETE;
This is a safe test, since the OLDVERCI field in CICS 3.1.1
is the SMFPSNPS (number of product sections, always '0001'X),
and OLDVERCI in CICS 2.1 and earlier will be 'F0F2'X or
'F0F3'X.
Thanks to David Ayresman, University of Louisville, USA.
Thanks to Hunter Chang, Sydney County Council, AUSTRALIA.
Change 08.039 TYPE6156 variable VOLSERs are wrong when additional
VMAC6156 "GOOVOO" entries follow the GOOVOO for this Entry. The
Apr 30, 1990 logic to update VOLSER in MXG was incomplete in this
instance.
a.Add DO; after the THEN which ends statement 019600.
b.MOVE lines 019600-019700 to after 020600 (the @;).
c.Insert new line 021610 (after 021600, END;) containing
END; (to complete the new DO; added above).
Thanks to Tim Kearney, Allied-Signal, Inc, USA.
Change 08.038 NPM records can be created under VM and processed by MXG
VMAC28 with these changes (mostly to VM:)
Apr 23, 1990 a.In FNMINIT FNMPARM A in the NPM MACRO the session
parameter was modified to read session=(session,NPMLOG),
i.e., to write session data to the NPMLOG as well as the
session log.
b.In NPMSTRT GCS A the FILEDEF for FMNLOG1 and FMNLOG2 was
modified to read FILEDEF FNMLOG1 DISK FNMLOG1 LOG A4
FILEDEF FNMLOG2 DISK FNMLOG2 LOG A4
c.To process the log the FNMLOG1 or FNMLOG2 was copied to
a file with a FILEMODE of A1 which was then used as the
input for MXG. The FILEDEF for the input file was also
specified with FILEMODE A1.
d.VMACSMF was copied and modified to create a new macro
named _SMF, which is a copy of the _SMF macro, but which
deleted the VBS and LRECL options on the INFILE statement
in the modified copy.
Thanks to W. C. Cronje, Anglo American Corporation, SOUTH AFRICA.
Change 08.037 VM/370 variable MN000PPC can be zero if preferred paging
VMACVMON is to expanded storage, causing a divide by zero error
Apr 23, 1990 in calculation of DRUMUTIL variable in line 116600. That
calculation is now precedeed by IF MN000PPC GT 0 THEN.
Format MGVM6TY has new value 2420X='2420:3380' added.
Thanks to Gary Zolweg, National Semiconductor, USA.
Change 08.036 Variable CREATIME in dataset MONITASK has date of END if
TYPEMONI a transaction spans midnight. Logic to correct date was
Apr 23, 1990 perturbed by Change 7.171. To correct, change line 00503
to read IF CREATIME LE TIMEPART(ENDTIME) THEN instead of
IF CREATIME LE ENDTIME THEN.
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 08.035 This one is obscure. CICS type 110 records with a error
VMAC110 are usually detected by MXG and STOPOVER prevented, but
Apr 18, 1990 if the invalid segment happens to be the last segment in
a type 110 record, a STOPOVER can still result, because
line 032200 (CONNBYTE+DRLENNUM GT BYTELEFT AND ...)
should be CONNBYTE+DRLENNUM GT BYTELEFT-38 AND ...).
Thanks to Earl Ryan, Life Insurance Company of Georgia, USA.
Change 08.034 IBM documented SMF6XFNC values of S and U for type 65
VMAC6156 and R for type 66, but S and U have been found in SMF
Apr 17, 1990 type 66. Now, MXG tests for R, S, or U for either type
in creating MXG variable FUNCTION.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 08.033 MXG Tape mount monitor variables DEVFROM and DEVTO were
VMACTMNT not formatted to HEX4. (add them in line 004600), and
Apr 12, 1990 DEVNR should be removed from line 020000.
Thanks to Glenn Thompson, Comalco, AUSTRALIA.
Change 08.032 VTOC processing variable RECFM should have been $4. in
VMXGVTOC line 032000 (instead of $3.), although it is unlikely
Apr 12, 1990 to ever see a non-blank in the fourth position.
Thanks to Wyman Young, BHP, AUSTRALIA.
Change 08.031 DB2 Lock Detail report PMLOK03 fails with a 170 format
ANALDB2R conflict error, because variable ELAPSED was previously
Apr 12, 1990 defined as a numeric variable. In three lines within the
PMLOK03 macro, lines 073560, 073570 and 073780, change
the variable name ELAPSED to LOCKTMCH.
Thanks to Dennis Longnecker, Wash. Office Admin for Courts, USA
Change 08.030 DB2 reporting from GTF (instead of SMF or PDB) failed,
ANALDB2R with "GTF is not a SAS library" error. We had failed to
Apr 11, 1990 test the GTF option in MXG 7.7. The correction is to
change line 002670 from
%IF &&PDB&I = SMF %THEN ....
to read
%IF &&PDB&I = SMF OR &&PDB&I = GTF %THEN ....
Thanks to Cindy Schinker, AgriData, USA.
Change 08.029 TSO SPF EDIT subcommand COPY should NOT be used to copy
TSO-SPF an MXG member into your USERID.SOURCLIB library from the
Apr 10, 1990 MXG.SOURCLIB, because the COPY subcommand of EDIT will
renumber the lines! Always use SPF COPY Command (3.3)
to copy members without renumbering, so that numbering
will be preserved. (It's not clear when this began to
happen, nor whether its an IBM design change or an error;
if you know more on the subject, let me know!)
Change 08.028 ROSCOE Audit records were not being output in ROSCOAUD.
VMACROSC Because there is no ROSCOE version identifier in their
Apr 10, 1990 record, an ad hoc test (TIME = . ) used to detect earlier
versions now prevents testing for audit records. In line
073500, replace the (TIME = . OR ROSREC = '30'X) with
(ROSREC='F0'X OR ROSREC='30'X OR 'A0'X LE ROSREC LE 'AB'X)
to process those record subtypes. In addition, variables
ACCTCODE FORMKEY and USERID were added to ROSCOAUD keep.
Thanks to Tom Braswell, Dow Jones & Company Corporate DP, USA.
Change 08.027 TYPE6156 processing can cause STOPOVER because cell '02'X
VMAC6156 record was incorrectly decoded. Correction:
Apr 10, 1990 Delete line 015700 (was ICFPSWRD $CHAR32.)
Change line 016800 from LENTHIS-87 to LENTHIS-55
Remove ICFPSWRD= from line 017200.
Thanks to Brian Kaczkowski, AgriData, USA.
Change 08.026 PDB.JOBS variables JINLTIME and JRSTTIME were up to four
BUILDPDB minutes (about 255 seconds!) earlier than JSTRTIME! This
BUILDPD3 truncation occurs when a DATETIME variable is stored in a
TYPEDOS length 4 variable. Because MXG's default numeric length
UTILXRF2 is 4, all DATETIME variables must be explicitly named in
VMACARB a LENGTH 8 statement, and MXG's QA test member UTILXRF2
VMACROSC is supposed to detect occurrences of DATETIME variables
VMACTMVS with length other than 8. Why did this slip thru QA? Due
VMACVMON to a logic error in UTILXRF2, only DATETIME variables in
VMACX37 more than one MXG-built dataset were tested for length 8!
VMAC102 1.Fixing that error uncovered additional DATETIME variables
VMAC24 that have now been explicitly set to length eight:
VMAC60
VMAC6156 Member Line Number Dataset Variable(s)
VMXGVTOC VMACTMVS 073000 TMVSJIST JISTSTOP,JISTSTRT
Apr 17, 1990 VMAC24 006500 TYPE24 OFLDTIME
BUILDPDB 044100 PDB.JOBS JINLTIME,JRSTTIME
BUILDPD3 044500 PDB.JOBS JINLTIME,JRSTTIME
VMAC102 411100 T102S100 QW0100SA,QW0100SB
VMACROSC 070100 ROSCOHU ROSTERM
VMACVMON 213910 VMONSUSP TODSTIME
2.An unrelated additional QA test was added by this change,
to detect character variables with a $MG.... format that
are also length 8. This causes no error but wastes seven
bytes, and results when the formatted variable was not in
a LENGTH $1 statement. This new test identified these
variables which needed a LENGTH statement:
Member Line Number Dataset Variable(s)
VMAC60 009700 TYPE60 ENTTYPID
VMAC6156 004300 TYPE6156 ENTTYPID
3.The QA CROSSREF output also showed that several members
did not contain LENGTH DEFAULT=4 statements, causing
numberic variables to be 8 bytes instead of only four.
DEFAULT=4 was added in VMACARB, TYPEDOS, and VMACX37,
and SMFTIME READTIME JINTTIME 8 was added in VMACX37.
In VMXGVTOC, VOLUME $6 was added to the LENGTH statement
(VOLUME is returned by SAS's VTOC option as a 30-byte
variable, which caused VOLSER to also be thirty bytes!)
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 08.025 MXG testing step TESTIBM has abended at two sites that
JCLTEST have used IMACKEEP to modify the default KEEP list. There
Apr 10, 1990 is no problem with their normal BUILDPDB, etc., but it
appears there is another SAS 5.18 internal limit that is
encountered. One set of symptoms are ERROR: WORK.DIRMACR
REQUIRES MORE SPACE ... with either THE LIBRARY IS IN 16
EXTENTS or THE LIBRARY IS IN nn EXTENTS, AND NO MORE
SPACE IS AVAILABLE ON VOLUME. Other failures show up as
a DATA SET NOT FOUND when the PROC MEANS or PROC PRINT is
invoked, and the SAS LOG shows the program simply stopped
building datasets, with no error. Increasing WORK space
does not correct the problem. (While not documented in
the JCLTEST member, the default JCLTEST requires a max
of 12 cylinders work space for any step with MXG 8.2).
Nor did REGION size have any effect. When the abend is
DASD space related, the SAS message usually indicates
DATA SET WORK.DIRMACR WAS AT OBSERVATION 16744450!
I think this problem is due to re-definition of old style
macros due to the repetitive include of IMACKEEP in this
test jobstep, which exhausts some internal limit for old
style SAS macro re-definitions. But since the error is
circumventable (run JCLTEST without the sites' modified
IMACKEEP), since the error hopefully does not exist in
SAS 6.06, and since I haven't taken the time to create
a repeatable test for SAS Institute to use to detect and
fix their problem, it is left with this documentation
note, until time or more errors cause further study!
Thanks to Marvin Rockhill, Community Hospitals of Indiana, Inc, USA.
Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.
Change 08.024 STOPX37 product SMF record had minor corrections to the
VMACX37 SELECTBK and ACTIONBK variables (changed from $CHAR10.
Mar 27, 1990 $CHAR8.) and MESSAGE variable (changed from @509 $CHAR144
to @513 $CHAR140.), but no loss of data had occurred.
Change 08.023 Lengths of five character variables were truncated due to
ASUMCICS incorrect initialization in this summary member for Trend
Mar 27, 1990 Data Base. Variables OPERATOR,TERMINAL,TRANNAME,TRANSACT
must be four instead of three bytes, and variables SYSID
and APPLID must be eight instead of three bytes in their
initial statements (where now set equal to 'MXG').
Thanks to Mike Hoevenaars, Toyota, CANADA.
Change 08.022 Fixes that should have been in MXG 7.7, but were not.
EXTY39EL 1.VMAC37 needed new formats $MG037FE, $MG037FI, $MG037FU
FORMATS for variables BRL/BRRFEAER, BRL/BRRFEAIN, BRL/BRRCTRC,
VMAC37 which also were added to the LENGTH statement with $1.
VMAC39 LABEL for BRLTYPE should be LOCAL instead of REMOTE, and
Mar 27, 1990 variables were added to the KEEP list: BRRTYPE, BRLTYPE,
BRLMODEL, and BRRMODEL.
2.VMAC39 needed ZDATE added to all KEEP lists, and the
existing-but-never-referenced EXTY39EL member for the
TYPE39EL (route elements) data set is now referenced.
Because TYPE39EL can get large, and because no one has
said they actually use the TYPE39EL dataset, the EXTY39EL
exit now DEFAULTS to create NO observations TYPE39EL.
Thanks to Bruce Widlund, Texas Utilities, USA.
Thanks to Doug Drain, National City Bank, USA.
Change 08.021 ANALDB2R DB2 report in MXG 7.7 was not tested with PDBs
ANALDB2R created by MXG 6.6, causing uninitialized variable error
VMXGSUM messages. MXG uses SAS's NOVNFERR (No Error when Variable
Mar 27, 1990 Not Found) but when the variable is in a BY statement or
Apr 10, 1990 a PROC MEANS control statement, NOVNFERR does not prevent
Apr 15, 1990 the error condition. The usual fix would add a statement
(IF x=. THEN x=.;) for each variable which might not be
in the input dataset (which fakes out the SAS compiler
by creating a variable if it does not exist). ANALDB2R
was changed (but when it was realized that these "fakes"
already existed in the OUTCODE macro argument, and that
MOVEing the lines from OUTCODE to INCODE would avoid any
retyping (with its high exposure to typing error), and
was more robust. The first three reports worked fine. But
the DB2 Accounting Detail report added 150 OUTCODE lines
to the existing 380 INCODE lines, and SAS died with the
"Excessive Parameter Length" Error, because 380 lines do
fit in MWORK=28K, but 380+150 lines break the maximum!
Part of the solution was to re-design the %VMXGSUM macro
so that it protects for possible missing variables in the
MIN, MAX, SUM, etc. operations done by %VMXGSUM, because
that should have been the original implementation. That
enhancement to %VMXGSUM is implemented herein in the 1st
part of this change.
Additionally, however, MXG 7.7 reports expected several
character variables that did not exist in MXG 6.6-built
PDBs. The second part of this change added statements to
supress the UNINITIALIZED VARIABLE messages if a cross-
version report (7.7 report from 6.6 data) is requested!
1.These sixteen new lines are inserted in member VMXGSUM:
After 025910 (IF DATETIME=. THEN DATETIME=.;) and before
026000 (&INCODE) insert:
%DO I = 1 %TO &NUMMAX %BY 1; 02592000
%LET VAR = %SCAN(&MAX,&I); 02593000
IF &VAR = . THEN &VAR = .; 02594000
%END; 02595000
%DO I = 1 %TO &NUMMIN %BY 1; 02596000
%LET VAR = %SCAN(&MIN,&I); 02597000
IF &VAR = . THEN &VAR = .; 02598000
%END; 02599000
%DO I = 1 %TO &NUMMEAN%BY 1; 02599100
%LET VAR = %SCAN(&MEAN,&I); 02599200
IF &VAR = . THEN &VAR = .; 02599300
%END; 02599400
%DO I = 1 %TO &NUMSUM %BY 1; 02599500
%LET VAR = %SCAN(&SUM,&I); 02599600
IF &VAR = . THEN &VAR = .; 02599700
%END; 02599800
2.If you MUST create new ANALDB2R MXG 7.7 reports from old
MXG 6.6-built PDB libraries, you must make these changes.
a.In two places in ANALDB2R, after lines 084860 and 110130
(each is: IF QWHSLOCN = ' ' THEN QWHSLOCN = ' ';),
replicate each line twice, then change the QWHSLOCN to
QLSTLOCN in the first replicate, then change the QWHSLOCN
to QLACLOCN in the second replicate.
b.Replicate line 006330 and change QWHSLOCN to QLACLOCN.
c.Change lines 015610 and 015620 (which initialize variable
QWHSDBAT and QWHSLOCN to four blanks) to now read:
IF QWHSDBAT=' ' THEN QWHSDBAT=' ';
IF QWHSLOCN=' ' THEN QWHSLOCN=' ':
d.Now, replicate this changed line 015620 thirteen times,
and change the replicated lines to now read:
IF QWHSLOCN=' ' THEN QWHSLOCN=' '; 015620
IF QLACLOCN=' ' THEN QLACLOCN=' '; 015621
IF QTXASELM=' ' THEN QTXASELM=' '; 015622
IF QTXASALM=' ' THEN QTXASALM=' '; 015623
IF QTXASPLM=' ' THEN QTXASPLM=' '; 015624
IF QTXABLLM=' ' THEN QTXABLLM=' '; 015625
IF QTXAINLM=' ' THEN QTXAINLM=' '; 015626
IF QTXAIOLM=' ' THEN QTXAIOLM=' '; 015627
IF QLACTRNS=. THEN QLACTRNS=.; 015628
IF QLACCNVQ=. THEN QLACCNVQ=.; 015629
IF QLACMSGS=. THEN QLACMSGS=.; 015630
IF QLACMSGR=. THEN QLACMSGR=.; 015631
IF QLACBYTS=. THEN QLACBYTS=.; 015632
IF QLACBYTR=. THEN QLACBYTR=.; 015633
Thanks to Dale St. Amant, Tenneco, USA.
Change 08.020 As discussed in Change 7.139 in MXG 7.7 CHANGES, SYNCSORT
VMACSYNC creates an invalid CPUTCBTM value (hex'555555'=15:32HHMM)
Mar 23, 1990 but it was not known why. SYNCSORT Early Warning Nr. 2803
now identifies the culprit; the use of FREE=CLOSE on the
SORTIN DDNAME causes SYNCSORT and MVS to both have issued
active STIMERS, which causes the corruption in their CPU
TCB time measurement. Eventually, SYNCSORT will fix the
conflict by zeroing out the field when a second STIMER is
set. MXG now recognizes '00555555'X and sets CPUTCBTM to
be missing in VMACSYNC. When the SYNCSORT fix is applied
in the future, a zero value instead of missing value will
result. This is a price you pay for FREE=CLOSE. Note that
even DFSORT specifically states to not specify FREE=CLOSE
on SORTIN DD statement
Note that this STIMER conflict ONLY affects the CPU time
that is measured by the 2nd STIMER issuer. The true CPU
TCB time in the SMF type 30 and the RMF type 72 records
are NOT affected, and remains correct.
Note also that FREE=CLOSE similarly affects SAS reported
CPU times on the SAS log, and can actually cause SAS to
ABEND with an internal apparent CPU TIME EXCEEDED error,
that also does not affect type 30/72 data, as was first
discussed on page 6 of MXG Newsletter TEN. With SAS, you
can still use FREE=CLOSE by specifying the NOSTIMER
option, which supresses CPU capture by not even issuing
the STIMER macro. (While SYNCSORT also has a NOSTIMER
option, it does not work in the same way, and will not
zero the CPU field when FREE=CLOSE is used.)
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Thanks to Nanette, SYNCSORT, USA.
Change 08.019 As documented in Newsletter SIXTEEN, MXG support for
VMACEPIL Candle's EPILOG/CICS was incomplete. It was also wrong!
XMACEPIL 1.The correct member to include (in member TYPEEPIL) is
XXACEPIL XMACEPIL in place of VMACEPIL, and DO NOT use XXACEPIL).
Mar 23, 1990 2.In member XMACEPIL, a + sign is missing in line 039300,
which should read: @121+OFFEPIL BISTIME ....
3.Variable WID should be 8 bytes (it is UOWID), but the
DEFAULT=4 causes it to be kept as only 4 bytes. It needs
to be added with explicit length 8, but eventually will
be converted and decoded into UOWID and UOWTIME.
Thanks to ???, ???.
Updated Jan 14, 1991. Member XMACEPIL was corrected and
copied into (replacing) member VMACEPIL, and then the
member XMACEPIL was deleted. All future EPILOG CL1000
support will be in member VMACEPIL, as it should have
been all along. See Change 8.212.
Change 08.018 System Managed Storage (SMS) now uses formerly reserved
VMXGVTOC bits located at offset '4E'x in the DSCB1 in your VTOCs.
Mar 22, 1990 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.
The change in 8.2 creates these new SMS variables in the
VTOCLIST (for VMXGVTOR) or LIST (for VMXGVTOC) dataset:
DS1CRSDB='DADSM CREATE ORIGINATED BLOCKSIZE?'
DS1PDSE ='PDSE MANAGED DATASET?'
DS1REBLK='DATA SET MAY BE REBLOCKED?'
DS1SCAVB='SECONDARY IS ORIG AVG BLOCK LENGTH?'
DS1SCCP1='SECONDARY IS COMPACTED BY FACTOR OF 256?'
DS1SCCP2='SECONDARY IS COMPACTED BY FACTOR OF 65536?'
DS1SCKB ='SECONDARY IS IN KILOBYTES?'
DS1SCMB ='SECONDARY IS IN MEGABYTES?'
DS1SCUB ='SECONDARY IS IN BYTES?'
DS1SCXTV='SECONDARY SPACE EXTENSION VALUE'
DS1SMSDS='SYSTEM*MANAGED*DATASET?'
DS1SMSUC='NO BCS ENTRY EXIST FOR DATA SET?'
OFFSET4E='OFFSET 4E*INTO DSCB1*(USED BY SMS)'
2.The PROC SORT DATA = EXTENT; BY VOLSER POINTER; was
inside the %DO group was relocated outside, just before
the %DO, since no values in EXTENT were changed; this
will speed up execution slightly.
3.Adding variable OFFSET4E to VMXGVTOC is simple: replace
line 045100 (now containing only +4 ), with this:
@84 OFFSET4E $CHAR4.
and add OFFSET4E to the KEEP list for the LIST dataset.
Then, you can execute the following MXG program under TSO
to read the VTOC of your favorite VOLSER to see if it
suffers from DSCB contamination at offset '4E'x:
ALLOC F(DISK) DA('any data set on chosen volume') SHR
SAS OPTIONS('NODMS MAUTOSOURCE SASAUTOS=SOURCLIB VTOC')
%VMXGVTOC(DISK=DISK); RUN;
DATA CONTAMIN; SET LIST;
IF OFFSET4E NE '00000000'X THEN OUTPUT;
(Dataset LIST is built directly by VMXGVTOC. If you
have implemented VMXGVTOR to graze your entire DASD
farm, the SET LIST; statement would be replaced with
SET &LIB..MXGVTOC which contains all LIST datasets.)
If dataset CONTAMIN has non-zero observation count, then
you either have DSCB contamination, or SMF has already
been installed at your site!
Thanks to Tuanhung Doanvo, Philip Morris, USA.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 08.017 Hiperbatch hit/miss stats were added by IBM to type 14/15
VMAC1415 and type 64 by TNL (GN28-1284) dated Jan 3, 1990 that was
Mar 22, 1990 delivered today. (Had it been received even by Feb 20, it
would have been implemented in MXG 7.7, avoiding this
change!). The change adds five new fields to both the
TYPE1415 and TYPE64 data sets. While the fields are the
same, IBM used two different field names/acronyms:
TYPE1415 TYPE64 Description
name name
SMFIOREQ SMF64SIO Hiperbatch total searches/requests
SMFCHITS SMF64HIT Successful searches
SMFPHIOS SMF64MIS Misses; caused physical DASD I/O
SMFCIOS SMF64IOS Misses that were copied into buffers
SMFNMWTS SMF64WTS Suspends due to conflict other users
Change 08.016 TPX dataset TPXINTRV will have zero observations because
VMACTPX of mis-alignment in the subtype 2 or 4 records. After
Mar 22, 1990 line 040900 insert:
IF TPXVER GE 200 THEN INPUT TPX24LEN PIB2.
TPX24ID $CHAR2.
@;
Note: TPX24ID was printed in error as $CHAR4. in Newsletter
SEVENTEEN, but was correct in MXG PreRelease 8.2 and
later software. It should be $CHAR2. as shown above.
Thanks to Kari Strand, Televerkets EDB-tjeneste, NORWAY.
Thanks to Doug Mayward, Pharmaceutical Data Services, Inc, USA.
Change 08.015 New subtype 3 of the existing SMF type 41 record provides
EXTY41AC usage statistics of the Virtual Lookaside Facility (VLF).
EXTY41UN Interval records (15 min) are written for each class in
EXTY41VF your COFVLFnn member of PARMLIB that is currently in use.
VMAC41 MXG creates dataset TYPE41VF from this subtype, reporting
Mar 22, 1990 (for each VLF class used) the MAXVIRT size, the storage
used, counts when objects were found in, added to,
deleted from or trimmed from VLF during the interval,
the largest object attempted to be added to VLF since VLF
was started, and the VLF "pct found/hit ratio". Multiple
VLF classes (CSVLLA, IGGCAS, IKJEXEC) can exist in one
type 41 subtype 3 record; multiple observations with the
same SMFTIME will be created by MXG. This change deletes
the existing TYPE41 dataset built from subtypes 1 and 2
and in its place creates two: TYPE41AC (DIV Accesses)
and TYPE41UN (DIV Unaccesses), which now keep only the
variables specific to those DIV events.
Thanks to Dan Barbatti, Southwestern Bell, USA.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 08.014 These circumvention members (for SAS 344 compiler limit)
XMAC7072 did not keep ZDATE in all datasets and had a typographic
XMAC71 error.
Mar 22, 1990 1.In XMAC7072, add ZDATE to the KEEP list for TYPE70PR and
TYPE72MN datasets.
2.In XMAC71, remove the extraneous period before the final
semicolon in line 031800.
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 08.013 DB2 data read from GTF did not have DATETIME21.2 format
VMACSMF nor LENGTH=8 for SMFTIME variable, but now _GTFDB2 macro
Mar 22, 1990 contains SMFTIME in both FORMAT and LENGTH statements.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 08.012 As noted in comments, type 79 support had not been tested
VMAC79 with real records. Now it has, and these changes will be
Mar 21, 1990 required to avoid STOPOVER or invalid data conditions.
1.These seven actions are SPF commands to be entered on the
command line while SPF EDITing member VMAC79 to make the
global changes (note that blanks ARE important):
a.EXCLUDE ALL
b.FIND ' = ' ALL (16 occurrences found)
c.CHANGE ' = ' '=' ALL
d.CHANGE ' BY ' '-1 BY ' ALL NX
e.EXCLUDE ALL
f.FIND ' LE LENGTH' ALL (21 occurrences found)
g.CHANGE ' LE LENGTH' '-1 LE LENGTH' ALL
2.Change line 013800 to read CYCLE ?? PD4.
3.Insert new line 015910 (after 105900) R79LF2 $CHAR1.
4.Change line 016200 to read R79RSV $CHAR2.
5.Change line 016900 to read R79IST ?? PDTIME4.
6.Change three occurrences in two lines of R792SLQR to read
R792LSQR.
7.These first six items bring the code up for MVS/ESA, but
for MVS/XA, other STOPOVER conditions are guaranteed, as
the code was only written for ESA. Guess what, though.
A real slick trick for MVS/XA execution (pointed out to
me by a user who got the trick from LEGENT's MICS) is to
execute with this code:
MACRO STOPOVER MISSOVER %
%INCLUDE SOURCLIB(TYPE79);
which will simply set the non-MVS/XA variables missing!
(I seldom use MISSOVER, because it does not tell you
that there were short records; I need STOPOVER so that
I GET the dump of the record, but is perfect here.)
Eventually, I may retrograde the code to support the XA
records, by breaking up the INPUT statement and inputting
conditionally the MVS/ESA variables, and thereby support
both MVS/XA and MVS/ESA type 79 data records, if that is
really necesary!
Thanks to Ron Thein, Mortgage Guaranty Insurance Corp., USA.
Thanks to Dan Barbatti, Southwestern Bell, USA.
Thanks to Randy Catlin, CENTEL.
Change 08.011 New member ZZZZZZZZ now exists as the last member of the
ZZZZZZZZ MXG library (AAAAAAAA is the first) so that it will be
Mar 15, 1990 easy to verify that all of the MXG Source Library ("from
AAAAAAAA to ZZZZZZZZ") has been successfully unloaded.
(Twenty new customers received incomplete MXG 7.7 tapes
from SAS before a customer discovered that only 1057 of
the 1100 members had been copied from our master tape!)
Thanks to Don Ehrig, Pearl Vision, USA.
Change 08.010 Support for NETSPY 3.2 was incomplete. NSPYVIRT (Virtual
VMACNSPY Route) variables APACING HOSTSUB OSTAGEP VRBLOCKD VRHELD
Mar 15, 1990 VRBHELDT VRBNSESS VROPEN VRBOPACT VRBPRTME were not input
and APPLID was replaced by SUBHOST. NSPYLINE variables
NSPDLY NSPDIALU NSPNMAXD NAPNMAXO NSPNANC NSPNCA NSPNNELS
NSPNPACE NSPNPLIM NSPNRTO NSPNSLIM were not input. These
un-input variables did not cause MXG to fail, they just
were not read in. Three other variables were actually
wrong and must be changes.
1.Line 052500 should read: BUF_UTIL=100 - FBLPCT;
so that minimum free buffers are used to calculate buffer
utilization (instead of average free buffers).
2.Line 059400 should read: COTPUTSZ PIB8.
(as PIB4., COTPUTSZ, Output Length, was always zero).
3.Move NETWADDR in line 009400 (in data set NSPYLU keep) to
line 008000 (in data set NSPYLINE keep list).
Thanks to Marty Quinlan, Virginia Power, USA."
for extensive validation.
Change 08.009 The %VMXGVTOR macro which invokes the FMXGUCBL function
FMXGUCBL was not correct. Changes made in VMXGVTOC (which is the
VMXGVTOR piece that actually reads the VTOC) were not propagated.
Mar 15, 1990 1.In member VMXGVTOR:
Jun 13, 1990 a. In lines 002200 and 002300 replace &I with &IVTOR.
b. Replace two lines 002500 and 002600 with these three:
PROC APPEND BASE=&LIB..VTOCLIST NEW=LIST FORCE;
PROC APPEND BASE=&LIB..VTOCMAP NEW=MAP FORCE;
PROC APPEND BASE=&LIB..VTOCINFO NEW=INFO FORCE;
2.The FMXGUCBL function was modified in MXG 7.7 (see page
17 of MXG Newsletter SIXTEEN), so the function would work
compatibly under either SAS 5.18 or SAS 6.06+, but it was
only tested under SAS 6.06! Under SAS 5.18, the MXG 7.7
FMXGUCBL returns a value too large by one. The following
change DOES work under either version of SAS and does let
a single assembly of this function to work witheither
SAS 5.18 or 6.06+. Change member FMXGUCBL lines 017400
thru 017500 so they now read:
MVC WORKAREA(4),=XL4'4E000000' 01740000 no change
LD FR0,WORKAREA 01741000 was SD FR0,FR0
XC WORKAREA+4(4),WORKAREA+4 01742000 new line
AD FR0,WORKAREA 01750000 no change
Thanks to Jeff Fox, SKF Inc, USA.
Thanks to David Fahey, SAS Institute Cary, USA.
Change 08.008 This is a complete revision of the text of this change
IMACVMON that was published in MXG Newsletter SEVENTEEN.
VMACVMON 1.The Q1SEC equation was wrong. The actual calculation
Jul 19, 1990 is Q1SEC=SUM(Q1TIME,E1TIME)/SUM(Q1DROPS,Q1); .
The lines affected by this change are:
a. After 035700, insert Q1SEC (to the KEEP= list)
b. After 082100, insert Q1SEC='AVERAGE*Q1SEC*DURATION'
c. After 146800, insert two lines:
DENOM=SUM(Q1DROPS,Q1);
IF DENOM GT 0 THEN Q1SEC=SUM(Q1TIME,E1TIME)/DENOM;
ELSE Q1SEC=.;
d. After 170000, insert Q1SEC (to the RETAIN list).
2.Comments in IMACVMON were added to stress the importance
of setting _INTRV macro value to equal your VM/Monitor
interval. If you leave the MXG default _INTRV value of
1 minute, but actually write records at 15 minutes, MXG
will throw away all USER and DASTAP data.
3.Variables PCTQUEDV/PCTQUECU were wrong, and instead of
containing the percentage of monitor intervals during
which there was a queue (as VM MAP calculates), these
MXG variables actually contained 100 times the average
number of entries in the queue. Now, they are correct and
should agree with VM MAP. The label for PCTQUEDV was
corrected and a label provided now for PCTQUECU.
4.The VM/370 SEEK (Class 7) reports in ANALVMDY do not work
and have not been fixed in MXG 8.7. It was re-packaged
incorrectly and causes syntax errors. Also, the logic to
match Seek address with the Mini-Disk directory may cause
ambiguous results, because it turns out that directory
entries can overlap. Pended for test data and test site.
Thanks to Bob Small, Grumman Data Systems, USA.
Thanks to George Ellard, Federal Express, USA.
Change 08.007 TSO/MON data set TSOMDSNS did not contain SYSTEM, and
TYPETSOM TSOMCMND had missing STRTTIME if there were enough users
Mar 19, 1990 logged on to create multiple System records for one
interval. (The TSOMSYST data set was protected by retain,
but the restore logic was after TSOMCMND was output.)
1.Add SYSTEM to keep list at line 005200.
2.Move three lines 084200 thru 084400 (which restore
STRTTIME,ENDTIME,and MAXUSERS from TSOMSTAR,TSOMENDT,and
TSOMAXUS) to immediately after line 072700 (before the
COMNDTYP='00'X; statement.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 08.006 TYPEIMS IMS Log processing had missing values if IMS
TYPEIMS crashed repeatedly, due to duplicate DTOKEN values.
Mar 19, 1990 1.Move IMSTAPNO in lines 035400 and 035800 to make the line
read: BY IMSTAPNO DTOKEN PSTNUMBR TRANSACT IMSRECNO;
2.Insert IMSTAPNO in line 036900 to make the line read
BY IMSTAPNO DTOKEN;
3.Move IMSTAPNO in lines 094900 and 095300 to make the line
read: BY IMSTAPNO DTOKEN ARRVTIME GUTIME IMSRECNO;
4.Insert IMSTAPNO in line 108300 to make the line read
BY IMSTAPNO DTOKEN;
Thanks to Pete Shepard, Ashland Oil, USA.
Change 08.005 IDMS Performance Monitor SMF record variables PGMTYPE,
VMACIDMS TASPTYPE, and TASTTYPE were kept as 8-byte variables and
Mar 15, 1990 with $HEX2. format. They should have been 1-byte length
with the $MGIDMPP, $MGIDMTT, and $MGRTEPT formats. Also,
the IDMSDBK data set was never output.
1.Delete the semicolon at the end of the LENGTH statement
in line 072000, and insert this new line
PGMTYPE $1. TASPTYPE $1. TASTTYPE $1.;
to force their length to only one byte, and then also
2.Remove these same three variable names from line 072400
(where the $HEX2. format overrode line 072000).
3.Change line 154800 from EXIDMCDM to EXIDMDBK.
Thanks to Mike Eisenhart, York International, USA.
Thanks to Mark Robbins, Jaguar Cars, ENGLAND.
Change 08.004 Candle's OMEGAMON/VM for VM/XA has an option to reformat
VMACVMXA IBM's MONWRITE data records into a Variable Blocked (VB)
Mar 15, 1990 file. Unfortunately, their program did not create valid
VB format records. They incorrectly added an extra RDW
(Record Descriptor Word of 4 bytes) in front of the real
RDW (does this make the record a VVB format!).
Because VB records are easier to work with during testing
and because it was hoped that IBM would eventually change
MONWRITE to create legitimate VB data files, MXG's VM/XA
support defined the _OUTFILE macro, that does create true
VB data records from IBM's MONWRITE records, and MXG's
_VMINPUT macro was defined to process those (future!) VB
records. With only a minor change, MXG's _VMINPUT macro
can be modified by Candle sites to process those invalid
"VVB" format data. Candle has acknowledged their error,
and announced that a permanent solution (i.e., correct
VB record format) would be provided in their next release
of VCOLLECT in their Version 4.10, in second quarter 90.
Before 4.10, Candle sites can read the "VVB" data by the
followin new line inserted after 769000 (ends a PUT that
precedes the INPUT MRHDRDM ... ), skipping over the RDW:
INPUT +4 @;
BUT THIS CHANGE IS ONLY FOR CANDLE "VVB" PRIOR TO 4.10.
IT MUST BE BACKED OUT WHEN YOU INSTALL THEIR 4.10.
Candle's VCOLLECT Incident Number is 81696.
2.To read real VB data (either from Candle 4.10 or using
MXG's _OUTFILE), if you have installed the IBM PTFs that
are described in Change 7.219, you will need to add this
correction (unrelated to the Candle problem, but observed
while debugging the Candle-created problem):
The following line must be inserted after line 769600:
LENGTH=LENGTH+4;
(immediately before the MRHDRLEN=LENGTH; statement), to
set LENGTH to the physical instead of logical record
length, as expected by MXG's MONWRITE logic.
Thanks to Mark Flugrath, WVNET, USA.
Change 08.003 DASDMON data sets did not have SMFTIME and ZDATE in their
VMACDMON KEEP= list, causing uninitialized variable error in the
Feb 26, 1990 ANALDMON report program. Now they do.
Thanks to Danny High, Blue Cross Blue Shield Texas, USA.
Change 08.002 ACF2 ARE data segment had two bytes not read, causing a
VMACACF2 STOPOVER condition. If the ARE did not exist, a program
Feb 23, 1990 loop could occur.
Mar 22, 1990 1.Insert two new lines, after line 052000 and 054200 (both
of which are ACLFLDNM $CHAR8.). The new lines contain
+2
(thereby skipping over two bytes after ACLFLDNM).
2.Change line 051500 to now read:
IF ACLAFARE GT 0 AND ACLMFLGS NE '...1....'B THEN DO;
3.Change line 053700 to now read:
IF ACLBFARE GT 0 AND ACLMFLGS NE '..1.....'B THEN DO;
Thanks to Roman Gudz, Leaseway Transportation, USA.
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 08.001 The first step of JCLTEST builds the MXG Format (SASLIB)
JCLTEST library. MXG 7.7 (unlike previous versions) requires the
VMACIMS SAS option MACRO in building formats (added to support
Feb 23, 1990 both SAS 5.18 and SAS 6.06+). Either specify MACRO on
May 5, 1990 the EXEC statement or use PROC SETINIT to set the default
to MACRO. Other MXG uses of the "new" %MACRO facility
also require DQUOTE to be similarly enabled. For the DB2
reporting and some of the Trend Data Base programs, the
option MWORK=28K (which sets the size of the macro work
area) prevents an "Excessive Parameter Length" error.
MXG now requires these SAS System options:
MACRO DQUOTE MWORK=28K GEN=0
For DB2 reporting (ANALDB2R) additional options are also
suggested (see comments in that member).
The two PUT statements that contained double quotes in
VMACIMS (requiring DQUOTE in step TESTOTHR) were changed
to single quotes.
LASTCHANGE: Version 8
End of Changes Log.
=========================member=CHANGE07================================
/* Copyright (C) 1984, 1990 Merrill Consultants Dallas Texas USA */
/************************ CHANGES ******************************/
This is the production MXG Version 7.7, dated February 15, 1990.
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 is dated February 15, 1990, thru Change 7.247).
(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,277 variables from the 679 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 and 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 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.
III. 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.
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. This is especially critical for IMACPDB
and IMAC30IO which were changed by several changes.
b. It is always wisest to PROC PRINT the first 50 observations of
critical datasets created with the new version. A visual scan
will easily confirm if there were unexpected changes. This is
especially important for PDB.JOBS, which can be affected by
user tailoring in IMACPDB.
Completed changes which have been installed and tested in this library:
NEXTCHANGE: Version 7
Change 07.247 Amdahl MDF record fields DOMMIN,MAX,TGT,ATGT,DUTIL,NORM,
VMACMDF SUTIL,UTIL should have been input as PD4.2 instead of
Feb 15, 1990 PIB4., and now they are.
Thanks to Vince Loeffler, G. D. Searle, USA.
Change 07.246 QA runs uncovered TMON/MVS variables JISTART and STARTIME
VMACTMVS that should have been set to LENGTH 8 (because they are
Feb 15, 1990 datetime stamps). Now they are, and ZDATE is now kept.
Change 07.245 TSO/MON will capture member names of PDS data sets that
VMACTSOM TSO users access, but MXG kept only the first eight names
Feb 15, 1990 in MEMBER1-MEMBER8 (and also did not re-initialize). Now,
multiple observations are created when necessary so that
all member names referenced are in TSOMDSNS dataset.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.244 DASD/MON support did not keep two variables, RSRCNT and
VMACDMON RFTCNT in the DMON.... data sets, but now it does.
Feb 15, 1990
Thanks to Greg Scriba, First National Bank of Chicago, USA.
===========Changes thru Change 7.243 comprised MXG Version 7.7=========
-Newsletter SIXTEEN accompanied MXG Version 7.7 to Merrill's customers-
Change 07.243 Alpha testing of TSO/MON release found that USRTHKTM had
VMACTSOM been INPUTed with TU4. format but then was inadvertently
Feb 12, 1990 also divided by 38400. (Before TU4. format existed, you
had to INPUT PIB4. and then divide that by 38400 to get
a TU4. data field into a SAS Time/Timestamp variable).
I probably should change all the old "PIB4./38400" fields
to TU4. and delete all of the /38400 lines, but that is
too risky a fix (and totally unnecessary in execution)
this close to production shipment, so I chose to change
the TU4. back to PIB4. At a later time I will make
and test the mostly-cosmetic change from "PIB4./38400"
to TU4.!
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.242 PDB logic and user tailoring are controlled by IMACPDB,
IMACPDB (which must always be from the same version of MXG as is
Feb 8, 1990 the BUILDPDB/BUILPD3 member being executed). Two changes
were made:
-The new _SUMPRN macro allows users to name additional
variables in TYPE6/PDB.PRINT data sets that are to be
summed in that job's observation in PDB.JOBS. Not likely
needed at most sites (but requested by a few), it should
have been there along to be consistent with the other
standard PDB-build data sets.
-The archaic PROTECT= option was externalized in MXG 6.4
into macro _PROTECT so sites could disable protection.
SAS Version 6.06 does not have a PROTECT= option, and
when you execute under SAS 6.06 with PROTECT= specified,
you get a NOTE: that the option is no longer supported,
and a condition code of 04 is set by SAS 6.06! This part
of this change creates a temporary new style %macro
%VMXGPRO which detects SAS version and does not supply
the option when you finally execute under SAS Version 6!
The comments have been revised in this important member
for user's wishing to tailor MXG PDB data sets:
Installation exit IMACPDB to control the Performance Data Base.
This member externalizes macros critical to building your PDB.
Most sites should not have to change this member, unless they
want to tailor the contents of the standard MXG PDB data sets.
If you tailor member IMACPDB, you must ALWAYS update that old
tailoring starting with the new IMACPDB member in a new version
of MXG. IMACPDB and BUILDPDB/3 must be at the same MXG version!
These following macros are defined here in IMACPDB and referenced in
either BUILDPDB or BUILDPD3. Please read comments carefully before
changing the contents of these macro definitions, and scan CHANGES.
Macro Purpose/Description
_PDB6 List of variables kept from TYPE6 in PDB.PRINT.
_PDB26J2 List of variables kept from TYPE26J2 (JES2) in BUILDPDB.
_PDB26J3 List of variables kept from TYPE26J3 (JES3) in BUILDPD3.
_PDB30_1 List of variables kept from TYPE30_1 in PDB.
_PDB30_4 List of variables kept from TYPE30_4 in PDB.
_PDB30_5 List of variables kept from TYPE30_5 in PDB.
_SUMPRN Subset of _PDB6 variables to be summed into PDB.PRINT.
_MAXSTP Subset of _PDB30_4 variables to be MAXed into PDB.STEPS.
_MINSTP Subset of _PDB30_4 variables to be MINed into PDB.STEPS.
_SUMSTP Subset of _PDB30_4 variables to be summed into PDB.STEPS.
_PDBADD2 List of PDB.JOBS variables back-merged into PDB.STEPS JES2
_PDBADD3 List of PDB.JOBS variables back-merged into PDB.STEPS JES3
_PDBSUMS Externalized logic of MXG summing algorithms, should only
be changed if _MAXSTP or _MINSTP are changed. Careful!
_NODUP Archaic, needed before SAS 5.16 to disable NODUP option.
Since 5.16 is dead, default now enables NODUP option for
all PDB datasets that are SORTed in BUILDPDB. The CICS
datasets from type 110 are not sorted by BUILDPDB.
_PROTECT Archaic default enables PROTECT=ZZZZZ for most PDB data
sets. The PROTECT option goes away in SAS 6.06, and MXG
will recognize execution under 6.06 and will not supply
the option (thereby avoiding an otherwise unavoidable
SAS NOTE: on your log, and a condition code 04!).
Change 07.241 VM/Monitor USER records do not indicate if a LOGON event
VMACVMON occurred. MXG attempted to detect a LOGON in processing
Feb 8, 1990 User interval records by testing the deaccumulated value
of each variable. If a LOGON occurred, its interval data
values should be less than the accumulated resources in
the preceding record from this user. However, two of the
user fields used in LOGON detection are only two byte
counters, which can wrap/overflow inside VM/Monitor, and
when either DRPCANUS or DRPPOPUS overflowed at the wrong
time, MXG falsely detected a logon event, and this caused
incorrect TTIME, VTIME, etc. values. Now, MXG's algorithm
for LOGON detection no longer uses the DRPCANUS/DRPPOPUS
two byte counters.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.240 TSO/MON Release 5.2 shipped in January 1990 will require
VMACTSOM Legent's maintenance tape TSM9002 to correct problems in
Feb 8, 1990 their capture of service units. TSO/MON Release 5.2 that
is accompanied by a Ship Letter Dated Feb 5, 1990 or
later already contains TSM9002 (which corrects errors MXG
found testing a Legent-supplied early beta test tape).
The support for TSO/MON 5.2 required an additional MXG
change, which could impact the existing MXG variables
SWAPHIGH SWAPSIZE TSMPSIMX TSMPSISZ TSMPSOMX
TSMPSOSZ TSMSIMAX TSMSISIZ TSMSOMAX TSMSOSIZ
which contain the swap sizes and maximum swap sizes
in both TSOMCALL and TSOMSYST data sets. Prior to 5.2
TSO/MON recorded the number of 2K blocks, but now TSO/MON
TSO/MON records the number of 4K pages. Since all of the
swap sizes and high water marks are actually
measures of storage (bytes, frames, pages, KB, MB, etc.)
which can be printed accurately and uniformly with MXG's
MGBYTES format, all of these old variables are now
converted
into bytes and formatted with MGBYTES. Unless you test
the value of those variables or calculate other report
variables, the only impact will be that the size will be
printed 396K instead of 99 pages (5.2+) or instead of 198
2K blocks (5.1 and earlier). This fix also preserved old
variables SWAPSIZE, SWAPHIGH, NRSWAPS to protect reports,
but now swaps are split into two variables each for
In/Out.
I firmly believe presenting KB, MB, GigaBytes, and their
rates per second is far more communicative than using
units of pages, frames, slots, etc., for both the swap
size of a single user (which might be 200K, 400K, etc.),
and for the total swapping load (which might be 9000G
for a 15 minute interval, or 10 MB/sec to/from if 100
100K users are swapped once per second). By expressing
these transfers of data between memories in MB/sec or
similar consistent units, comparisons with channel speed,
memory speeds, etc. become clearer, not just in TSO but
in all subsystems in all operating systems.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.239 Change 7.142 for PR/SM environment corrected CPUWAITM if
VMAC7072 the number of LPARS was greater than the number of real
Feb 8, 1990 processors. That fix also corrects an error in CPUWAITM
when CPUs are varied ONLINE or OFFLINE under PR/SM.
In verifying that the fix solved both problems, it was
noted that the fix was made only to PR/SM SHARED,WAIT=NO
environment (the normal, expected use of PR/SM). Although
no one has ever (nor likely will ever) specified WAIT=YES
for their PR/SM partition, the fix of 7.142 was applied
to lines 136200-141000.
Thanks to Lou DeRosa, Commercial Union, USA.
Thanks to Igor Polevoy, Commercial Union, USA.
Change 07.238 Several collected changes to various things.
ANALAUDT 1.ANALAUDT line 01500001 should be RACFQUAL=107 instead of
Feb 7, 1990 RACFEVNT=107.
2.Misspelled SMF6LN3 now correct in text of Change 7.105.
3.VMAC37 variables BRFMODEL and BRFTYPE removed from keep
list, as they did not exist.
4.VMAC102 variables QW0080CK,QW0082CK and QW0082F1 are now
formatted $HEX2. for printing.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.237 -NETVIEW NPM Type 28 records occasionally produce MXG note
VMAC28 "nonzero AOF segment for NPMSUBTY F1 (NPM End)". In the
Feb 7, 1990 two dumps viewed, the AOF triplet does point to a data
segment, but it contains trashy data (like an uncleared
buffer?). There is no AOF segment documented for the F1
subtype (and none expected; this is the stopping of the
NPM monitor). It sure looks like an IBM coding error in
NETVIEW/NPM, but since it's only impact is the note on
the MXG log, and because this is not important, no one
has gone thru the tedious process of several calls to the
support center Level I and Level II until they find that
no reported problem exists and IBM then issues an APAR,
(Authorized Problem Activity Report), which is IBM's
acceptance of the problem, and then they wait for the IBM
Product Change Team to produce the PTF (Program Temporary
Fix), that now must be installed (a change, with its
exposure to breaking something that was already fixed).
Hoping it eventually goes away or gets reported, you can
ignore the note for the F1 subtype.
-Variable BASTIME does not exist in subtype 51x and 61x,
causing INVALID ARGUMENT FOR INPUT FUNCTION. INFO/SYS
entry E337883 confirms these values are zero for those
subtypes. MXG now causes BASTIME to be missing for those
subtypes. Update Nov 2001: See Change 19.221.
Thanks to H. Beer, Hessische Landesbank, GERMANY.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.236 Support for Empact's STOPX37 Product Release 3.3 added
VMACX37 new variables STEPNAME,PROCSTEP,VMEXTS,VSCLUST,VSCOMP,
Feb 7, 1990 VSTYPE, and VSDTYPE and corrected the length of SELECTBK,
ACTIONBK, and ACTION37. The Empact supplied SAS code for
3.3 is incorrect for at least one field, and this support
has not yet been tested with actual 3.3 records.
Thanks to Duane Reaugh, Empact Software, USA.
Change 07.235 DB2 discoveries and enhancements support DB2 2.2.0:
ANALDB2R 1.DB2STAT0 and DB2STAT1 records have slightly different
VMACDB2 values for QWHSSTCK (time stamp). To associte the two
VMAC102 records from the same interval, MXG carries the subtype
Feb 6, 1990 0 QWHSSTCK into the subtype 1, unless the absolute time
Feb 8, 1990 delta between the 0 and 1 subtypes was greater than one
second (to detect when the previous 0 is the last from
one SMF file and the new subtype 1 is the first from this
system). I assumed one second delta would be enough, but
it is not! One site sent these data for adjacent SMF
type 100 records:
Subtype SMFTIME (SMF) QWHSSTCK (DB2)
0 33:42.55 33:42.4624
1 33:43.69 33:43.6992
a. DB2 STCK to SMF buffer delta time is 90 millisecs.
This possibly represents the elapsed time for DB2
to collect and pass the subtype 0 to SMF.
b. Delta from STCK of 0 to 1 is 1.25 seconds between
DB2 time stamps AND delta from SMFTIME is 1.14
seconds suggest a momentary glitch delayed DB2.
As a result, the THISSTCK check in VMACDB2 now tests for
a delta of 60 seconds between subtype 0 and 1 before a
mis-match is declared. (No records are lost).
2.The DB2ACCT, DB2STAT0, and DB2STAT1 data sets now contain
the 16-byte DDF variable QWHSLOCN (This Location Name) if
this DB2 is part of a Distributed Data Facility network.
3.QWHSLOCN was also added to all T102Snnn trace datasets.
In the trace record, for DDF, there is a new header with
several new DDF fields (including QWHDRQNM, the location
name of the Requestor/Server DB2), which is decoded, but
kept only in the T102S106 dataset. Location names are
$CHAR16. fields (though in the pre-release, QWHDRQNM was
incorrectly $CHAR8.).
4.Type 102 trace subtype 106 T102S106 variables QWP9....,
for DDF are now created and decoded.
5.Variable QXNSMIAP in VMACDB2 is now spellec QXMSMIAP.
6.The CPU time of the 4th address space (DDF) is created
in QWS4EJST and QWS4SRBT and is added to DB2CPUTM.
7.New member XDB2HDR is a debugging aid that decodes the
type 102 record header(s). Hopefully you won't need it!
8.DDF may create multiple segments in type 100 and 101
records (NRQTXA and/or NRQLST greater than 0), but MXG
currently only processes the first segment. Once we have
real DDF data in hand, we'll decide what to do (i.e.,do
we create multiple variables, or multiple observations?).
9.EDM pool reports from variables QB1TCBA-QB4TCBA and
QISEPAGE,CT,FREE,DBD, and SKCT were incorrect (only the
ANALDB2R report was wrong; the values were correct in
the DB2STAT0 data set), and have been fixed.
10.ANALDB2R (DB2PM-like reporting) has been updated thru DB2
Release 2.2.0. The status of all DB2 reporting is in the
comments in member ANALDB2R. Only the SQL TRACE and the
Transit Trace reports were not completed in MXG 7.7. The
reports are generally updated for DDF fields, but we have
had no test DDF data. In all trace reports from DB2PM in
DDF environment, QWHDRQNM, (DDF location) is printed in
the header, but not all MXG trace reports have this one
field (although the system parameter report and other
important reports have been updated.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.234 MXG Algorithms to process IMS log records into IMSTRAN
IMACIMS observations now are further enhanced. Variables MODNAME,
TYPEIMS NODENAME, MSGSIZIN, MSGSIZOU, ODEST, and DTOKEN should no
VMACIMS longer be occasionally missing; incorrect KEEP/DROP logic
Feb 5, 1990 in VMACIMS was changed. A new macro, _IMSVTAM, is now
defined in IMACIMS to indicate if VTAM is your IMS access
method (default _IMSVTAM is yes). For IMS 2.2 or later,
VTAMNODE will be captured. Output queue time was missing
sometimes because CLINENR was set to LINENR/TERMNR but in
VTAM environment NODENAME/VTAMNODE should have been used;
now CLINENR is set appropriately. The response times for
WFI and multiple transactions per program schedule were
sometimes missing, because only one observation was
created for type 35 events, but a type 35 could be both
the end of one transaction and the start of a second;
MXG now creates multiple observations when appropriate,
and this new logic seems to have closed that loophole.
I keep hoping each IMS iteration will be the last, yet
I know it never will be. This one, though, was a cleanup
of many small problems which have existed since Pete
re-vamped the original MXG algorithms in 1988! These
changes have been well tested on IMS 2.2 and tested on
2.1 data, but not yet on IMS/ESA 3.1 data records.
A new debugging macro _IMSDBUG that provides a decoded
trace of each IMS log record used in MXG logic is also
defined and described in VMACIMS.
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Ervin Claxon, Ashland Oil, USA.
Change 07.233 VM/370 Monitor MXG dataset VMONPERF variables Q1LOGDRP
VMACVMON and Q1LOGDRP were documented in the MXG Supplement p 551f
Feb 5, 1990 as being renames of MN002Q1B/MN002Q2Bm but the change was
not made in VMACVMON until now.
Thanks to Bob Small, Grumman Data Systems, USA.
Change 07.232 Landmark's MONITASK record for TRANSACT='OVHD' does not
TYPEMONI contain User segments, and the second fix in Change 7.108
Feb 5, 1990 is now added permanently to prevent STOPOVER when reading
Landmark-created summary files. Note that OVHD transact
do not exist in the "raw" (normal) Landmark records.
Change 07.231 The new-style macro %GRAFRMF was both defined in this
GRAFRMFI member, and automatically invoked as the last line of
Feb 2, 1990 the member, preventing you from passing/changing any of
the macro arguments for RMF reports from RMFINTRV. Now,
the member only defines the macro, and no longer invokes
it for you.
Change 07.230 The variables kept in PDB.STEPS did not include the nine
IMACPDB variables documented on page 278 of the MXG Supplement:
Feb 2, 1990 JOBCLASS,LSQSZHI/LOW,PVTSZHI/LOW,RDRDEVT,REGREQST, and
USRSZHI/USRSZLOW that were supposed to have been added
back in Version 5! Now they have been added to the list
(in the MACRO definition for _PDB30_4 list in IMACPDB).
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 07.229 TYPE70PR (PR/SM only) variable PRSMSLIC (dispatch time
VMAC7072 slice duration) and flag variables DIAG204F, NRPRCHGD,
Jan 30, 1990 and SLICCHGD (X'204' failure, number of processors were
changed, or time slice was changed respectively) were not
kept, labelled, and the last two were not even created,
and PRSMSLIC should have been PIB2.3 instead of PIB3.
Fortunately, that it took until now for this to be seen
suggests they are not of critical import, but due to
detailed debugging by this user, they are now valid.
Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.
===========Changes thru Change 7.228 comprised Prerelease 7.6==========
Change 07.228 NETSPY 3.2 Appendix B did not agree with actual DSECT of
VMACNSPY the T and U records, causing LUUID and LUGTRGT1-4 to be
Jan 29, 1990 missing (but no ABEND nor ERROR, because the Appendix
said to expect 116 bytes, but there were only 108, so the
conditional INPUT was never executed).Change the test
IF NSPYENTL GE 116 to GE 108 and change the subsequent
four occurrences of PIB4.6 to PIB2. (for the LUGTRGT1-4
variables), and delete the four lines where LUGTRGT1-4
are multiplied by 65536,
Thanks to Brian Cooper, Wyeth-Ayerst Labs, USA.
Change 07.227 The alpha test site for Change 7.219 found it deficient
VMACVMXA in two places. The calculation of SKIPTHIS was changed
Jan 29, 1990 to SKIPTHIS=LENGTH-COL-1; and the ELSE INPUT was changed
to just INPUT to properly skip over VM/XA spanned
records.
Thanks to S. Rolin Hymans, Comparex Belgilux, BELGIUM.
Change 07.226 VM/XA changes only in pre-releases 7.2+ caused DELTATM
VMACVMXA in VMXAINTV to be picked up inadvertently from VXSUMIOD,
Jan 29, 1990 where it was inadvertently summed. (DELTATM is the delta
between interval records of the same type, and is used
to calculate rates. In VXDEVTOT, DELTATM is appropriately
summed, because it aggregates device activity across the
day by device address. In VXSUMIOD, however, the interval
is the aggregate, and DELTATM is now taken from the first
occurrence within the interval device records. Note that
DELTATM between device records in an interval will not be
exactly the same as the DELTATM between other interval
records, because all records are not written at the same
time.) The fix: removed DELTATM from the _VSUMIOD macro
definition, added DELTATM explicitly after the references
to _VSUMIOD in building the VXDEVTOT, added ID DELTATM;
to the subsequent PROC MEANS for VXSUMIOD, and added
(DROP=DELTATM) after the VXSUMIOD reference in the MERGE
that builds VXBYTIME. MXG MACRO _TESTINT, which will
process only the interval VM/XA data records, was also
updated to properly handle the I/O interval records.
A brief benchmark of VM/XA processing costs for 30
intervals with 1000 Logged on VM machines shows total
MONWRITE output was 37,735,588 (35MB), written as
1372 4KB control records interspersed with the 3290
data blocks which varied from 4KB to 28KB but averaged
16K. That's about one Megabyte per Logged On user for
30 intervals (at 15 min intervals, thats 7.5 hours, or
one prime shift). MXG _TESTMW took 70.99 TCB 3090-200
seconds for the data step and totalled 117.20 TCB and
46,146 EXCP to create all possible data sets and sample
VM/XA reports, in 14 elapsed minutes of execution. The
_TESTINT macro (keeps only interval records and not all)
took only 9 minutes elapsed with 40.37 TCB in the data
step and 77.33 total TCB with only 31,464 EXCPs.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Thanks to Margaret Curtis, Rutherford Appleton Laboratories, ENGLAND.
Thanks to Yam Tan, British Airways, ENGLAND.
Change 07.225 This update to DB2PM-like reports enhances more of the
ANALDB2R reports to support DB2 2.2.0 reports, although not all
Jan 28, 1990 of the new information (especially the DDF Distributed
Data Facility information) has been added to all of
the existing reporting. See the table in the comments
of the member to identify if the report tolerates or
exploits the new data fields. Member was renumbered.
Change 07.224 Typos crept into XMAC71 change 7.038 (to circumvent the
XMAC71 SAS Error 344 condition) that could cause variable type
Jan 26, 1990 conflict for variable FRAMES in TYPE71. Line 0318 XMAC71
that was IF FRAMES=. THEN FRAMES=.;
must be IF FRAMES=' ' THEN FRAMES=' ';
(to initialize FRAMES, which is non-existent if MVS/XA).
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.223 Typos crept into ANALPATH, added in MXG 7.3. Line 105
ANALPATH should have been HEX4.; vice HEX4; and Line 222 should be
Jan 26, 1990 PDB.TYPE73 vice DB.TYPE73.
Thanks to Christophe Faure, SAS Institute, FRANCE.
Change 07.222 Preliminary support for type 79 SMF record written by RMF
EXTY791 Monitor II session to the SMF file. This support used an
EXTY792 SMF Manual from MVS/ESA 3.1.3 and an MVS/XA 2.2 DSECT in
EXTY793 ERBSMF79. If I am lucky, it should support all MVS/ESAs
EXTY794 and MVS/XAs 2.2 and later. If I should be really lucky,
EXTY795 some of the MVS/370 subtypes and MVS/XA before 2.2 may
EXTY796 also be processed without error, but caveat user.
EXTY797
EXTY798 Added in MXG 7.6, the code has yet to read a 79 record.
EXTY799
EXTY79A For subtypes 1 thru 12, exact IBM field names are used as
EXTY79B variable names, and one observation is OUTPUT for each of
EXTY79C the segments in each subtype into the twelve MXG-built
EXTY79D TYPE791-TYPE999 + TYPE79A-TYPE79C datasets.
EXTY79DF
EXTY79E For subtypes 13 and 14, because they so parallel the type
EXTY79EF 78 SMF record, their dataset names and variable names are
FORMATS taken from the existing TYPE78, TYPE78CF, and TYPE78CU
TYPE79 MXG datasets to create these four new data sets:
VMAC79
Jan 25, 1990 TYPE79D,TYPE79DF,TYPE79E,TYPE79EU
where Ds (13X) are non-3090s and Es(14X) are 3090 plus.
The implementation for this subtyped SMF record creates a
_VAR... and _CDE... MXG macro for each subtype, allowing
you to construct programs for selected subtypes, if your
really need to.
If you have turned on the right monitoring in RMF Monitor
II, you should have only subtypes of interest, and the
standard MXG program for processing an SMF record:
%INCLUDE SOURCLIB(TYPE79); RUN;
will create all 16 of the possible TYPE79.. datasets that
can be created, and for those of the 14 subtypes that
are found in your SMF file, non-zero observations will
appear in the associated MXG-built dataset.
Alternatively, as an example of this new MXG design for
SMF records with subtypes, you could create/execute the
following MXG program:
%INCLUDE SOURCLIB(EXTY79);
DATA _VAR791 _VAR792 _SMF _CDE79S _CDE791 _CDE792 ;RUN;
to create only the TYPE791 and TYPE792 MXG datasets from
the subtype 1 and subtype 2 SMF type 79 records. If you
do create your own subtype-specific program, note the new
required _CDE79S reference to process the RMF 79 header
and product section. (It's already in member TYPE79).
Future enhancements might include an "ANAL79" to merge
some subtypes together, and might include an "IMAC79" for
session selectivity, etc. Let me know what you need.
Thanks to Ervin Claxon, Ashland Oil, USA.
Thanks to Tom Skasa, General Electric Medical Systems, USA.
Thanks to Sterling Green, General Electric Capital, USA.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 07.221 Change 7.189 (only in MXG 7.3 and 7.5) was incorrect.
ASUMCICS While intended to transparently use either Landmark or
Jan 24, 1990 IBM CICS transaction data, it failed miserably if either
source was missing (but it worked great, when both were
present!). Now it self-detects what kind of CICS data
you want summarized from the detail transaction data to
the PDB.CICS (Trending, summarized) CICS data set. Sorry
for not testing all possible alternatives on this one!
Change 07.220 Line 002000 contained a truncated line, and should be
XSYSLOG deleted. (Variable EVENTIME was already calculated just
Jan 20, 1990 a few lines above).
Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 07.219 This change is a series of enhancements to VM/XA Monitor
VMACVMXA support.
Jan 15, 1990 1.VM/XA MONWRITE can span logical records across physical
blocks, but VM does not support a "VBS" format, and the
2-byte field that could be used for "spanning" flag is
a reserved field in VM/XA! As long as the spanned record
happened to split on a field boundary, MXG'S Change 7.086
(which removed STOPOVER), and the robustness of SAS, made
spanning "supported"! Now, however, we find 1.13 records
split in the middle of the 8-byte MRHDRTOD field! (This
occurred at a site that named 240 specific devices to be
monitored, causing a 1.14 record that did not leave space
enough in that page for the 1.13 record to fit!)
This circumvention detects a spanned logical record and
and notes the encounter on the log, deleting the bad data
record, and IBM has been notified of their design error.
It may be that this is the only exposure, as in most of
the other records in which there can be multiple segments
the individual segments are actually separate logical
records and may (accidentally) be protected. How could
IBM overlook this design oversight? Because if you are
thinking about "data pages in memory" rather than the
resultant "physical block on external storage device",
and are simply moving addresses across virtual storage,
the operating system takes care of "page spanning" for
you!
2.If no Monitor START event precedes each package of VM/XA
MONWRITE data, numerous problems result. First, since
there is no 1.4 record, the GMT offset delta is unknown,
causing all timestamps to be of unknown time zone! All
of the records found before an end-of-interval have to
be deleted, because BEGINMTR and ENDTIME are unknown.
Furthermore, since MONWRITE records contain accumulated
data (instead of the actual data for the interval), the
first interval will ultimately also be thrown away, as it
is valid only to initialize values for de-accumulation.
Still further, no Monitor START event record means that
there is no MTRDEV Configuration record, which is needed
to map the static device information (such as device type
class, path, etc.) to the device activity records. All of
those variables will be blank in the IOD... datasets.
MXG now will process VM/XA data that is not precedeed by
a Monitor START record correctly, but even MXG cannot do
anything about the missing data.
How can there be no START event? This problem came about
at a site using Candle's VCOLLECT product that creates a
new MONWRITE file each day with its End-of-Day routine.
The second and subsequent files are incomplete. The only
safe solution seems to require Candle to STOP/START the
monitor as the initial records written to each new day"s
MONWRITE file.
This is not a problem with IBM's MONWRITE-created files,
since their ONLY way to dump VM/XA data requires you to
STOP and then START the monitor!
The real culprit here is the IBM design in which monitor
data records are created that are not self-described and
contain no independent information without the prior time
interval. VM/XA should have looked at RMF design!
3.Since no startup records can be guaranteed, the MXG logic
that attempted to capture VMDTTIME,VMDVTIME and VMDCTIME
in the first interval has been eliminated. Until IBM adds
a flag in the USER data record itself, it is impossible
to unambiguously and safely capture these CPU times from
USER logon to the first interval. The remainder of the
MXG algorithm to detect subsequent logon events (done by
setting variable LOGON) has not been altered.
4.VM/XA SP Release 2.1 did not alter the contents of any
data records, but several VM/XA APARs have changed many
MXG data sets by creating additional variables. As is
always the case, member DOCVER07 in the MXG SOURCLIB
library provides the delta-documentation of the datasets
and variables added. These support of these IBM changes
required these sources of documentation:
I. CP Programming Services, Release 2.1 SC23-0370-2.
Appendix B, Monitor Records, which is now the
basic source of documentation of VM/XA records.
II. VM/XA System Product Release 2.1 Program Directory
for VMSUP Level: 8905 for VM36583 and VM37852.
III. INFO/SYS Entry E343842 for VM35968.
IV. INFO/SYS Entry E337409 for VM35962.
V. INFO/SYS Entry E336950 for VM35321.
a. Variable VMDCPUAD has been added to three MXG datasets
for schedule domain, VXSCLADL,VXSCLDDL and VXSCLAEL by
VM35321 (supported in MXG 7.0 and later).
b. Variable RDEVCUIV flags if Control Unit information is
available in the VXIODATD, VXIODVON, and VXMTRDEV MXG
data sets, and RDEVOFFL in VXMTRDEV identifys if the
device was OFFLINE/ONLINE at Monitor START by VM35962.
c. VM35968 adds information on I/O activity (variables
RDEVSKCT,RDEVSKSM,RDEVWRCT,RDEVRDCT containing Seek
counts and cylinders ('passed over while the arm is
passing over uninteresting data', according to Siebo),
and separate counts of Read or Write channel programs
to VXIODDEV at the device level. Variables IORDWRIT,
IORPOSCT,IORPOSSM, CALECYL,CALUSER,and RDEVDEV were
added to the VXSEKSEK seek trace record that IBM had
previously reported as in error and unusable. This is
thought to mean that seek data is now usable.
d. VM36583 and VM37852 add 27 new fields to the interval
VXSYTXSG dataset extending ESTORE (or XSTORE if you
must, even though MVS' used ESTORE long before VM was
able to use "XSTORE") efficiency measurements.
Thanks to Phil Strange, BP International, ENGLAND.
Thanks to Martyn Stevens, Barclays Bank London, ENGLAND.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.218 VM/370 Monitor data variable STGUTIL could be missing as
VMACVMON it was not in the RETAIN statement. Now it is.
Jan 15, 1990
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.217 TYPE76 RMF Trace variables INTRVAVG and AVG were slightly
VMAC76 wrong if the last sample set did not have complete sample
Jan 15, 1990 count. The calculations were corrected to use NSAMPLE for
NRSETS*SAMP_SET for INTRVAVG, and SAMP_LST instead of
SAMP_SET for AVG if _I_=NRSETS (i.e., for last set).
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 07.216 TYPE60 VVR variables are now labeled.
VMAC60
Jan 12, 1990
Change 07.215 TYPE6156 ICF Catalog Activity records have been enhanced
FORMATS to extract volume serial numbers from the catalog section
VMAC6156 at the end of the record, if a volume segment exists. Up
Jan 12, 1990 to five volumes (VOLSER1-VOLSER5) will be contained in
each observation and multiple observations (sequenced in
variable MULT6156) are created if the entry has more than
five volumes. Catalog records consist of a sequence of
catalog cell records, identified by a hex "cell type".
Not all TYPE6156 records contain a 04 Volume record; to
examine the structure of the catalog segments, variable
CATCELLS contains the first 16 cell types encountered.
Expected sequences of ICF catalog cells are:
C1 01 03 04 Non-VSAM dataset
C2 01 05 GDG Base subrecord
C2 01 05 C8 01 03 04 GDS subrecord
C3 01 02 03 06 Cluster component
C4 01 02 04 Data component
C7 01 03 AIX component
C7 01 C4 01 04 C9 01 04 AIX subrecord
C9 01 02 04 Index component
D8 23 Secondary VVR
D9 01 02 03 Path record
E3 03 Truename record
E4 01 03 04 User catalog connector
E7 03 Alias
E9 21 60 23 Primary VVR
Multiple occurrences of 02 03 can occur. Multiple
04 (volume) occur for multi-volume entries.
There are cases with no 04 volume cell in the record.
Variable ACTION shows DEFINE action for non-VSAM files
files with no 04 cell, and have found SCRATCH action
for GDS G0002V00 but there was no C8 entry for that
gen! (The catalog record for a GDS consists of the
base GDG entry followed by a C8 01 03 04 for each
generation; MXG parses the GooVoo in the entry name
and finds its C8 entry in the catalog record to extract
the VOLSER(s) of that generation). We have also found
catalog records containing only the E3 03 (Truename)
entry, and a GDS with only the base GDG C2 01 05 entry.
Format $MG060ID now decodes the possible values of the
ENTTYPID entry type id field, although we still have
found three data values that IBM level 2 could not
explain (although they did offer to build a slip trap
we were unwilling to install!). Thus far, we have found:
A - non-VSAM ("Alien") N - undocumented
B - GDG Base P - Pagespace
C - Cluster R - Path
D - Data S - undocumented
F - Free T - Truename
G - Alternate Index U - User Catalog
H - GDG V - Volume
I - Index X - Alias Name
K - VSAM VVR Y - Upgrade
M - Master Catalog 00 - undocumented
Perhaps ENTTYPID will assist in explaining why an ICF
entry was changed, but does not have a volume record.
For VSAM entries, the catalog record typically contains
04 volume records for the cluster, the index component
and the data component. In this implementation of MXG,
ALL volume records are extracted and stored in VOLSERn
variables, in the sequence found in the catalog record.
Thanks to Connie Lee, Morgan Stanley, USA.
Change 07.214 Sample RMF Monitor III report programs variable DYDELAY
ZRBRPT1 should have been spelled DVDELAY.
ZRBRPT2
Jan 9, 1990
Thanks to Brian Redmond, Home Savings, USA.
Change 07.213 Support for Candle's Network Accounting Facility (NAF)
EXNAFENT SMF records (written by Candle Products CL/SUPERSESSION,
EXNAFGLI CL/GATEWAY, and VTAMPLUS) have been added by this user
EXNAFGOF contribution. Data sets NAFSTART, NAFSHUTD, NAFENTVA,
EXNAFGON NAFLOGON, NAFLOGOF, NAFVOGON, NAFVOGOF, NAFGOGON,
EXNAFGPA NAFGOGOF, NAFGPASS, NAFGLIMT, NAFGPSTR, NAFGPSTO
EXNAFGPO are created from subtypes of these network records.
EXNAFGPR This support includes NAF thru Version 145 of Candle's
EXNAFLOF CL product line.
EXNAFLON
EXNAFSHU
EXNAFSTA
EXNAFVOF
EXNAFVON
IMACNAF
TYPENAF
VMACNAF
Jan 9, 1990
Thanks to Gene Quinn, Blue Cross of Rhode Island, USA.
Change 07.212 Support for TSO/MON Version 5.2 has been added. This
VMACTSOM version adds a number of resource fields (swaps, paging,
Jan 8, 1990 service units, I/O connect time) to the TSOMSYST and
TSOMCALL datasets. MXG 7.6 or later is required for
TSO/MON Version 5.2 if TSO/MON options ACCOUNTING=YES
or DSNAMES=nnn were specified (because TSO/MON inserted
data before the accounting/dsname sections, and because
MXG did not use the offsets to those sections until MXG
7.6+).
Thanks to Ken Dove, Legent, USA.
Change 07.211 Duplicate records were not deleted by the NODUP option
BUILDPDB in the PROC SORT of DATA=TYPE70PR because the BY list
BUILDPD3 was insufficient to guarantee that duplicate observations
Jan 5, 1990 ended up physically adjacent. The variable LCPUADDR had
to be added to the end of the BY list in BUILDPDB/3.
Thanks to Earl Ryan, Life Insurance Company of Georgia, USA.
Change 07.210 The OUTPUT statements in _ANALMON deaccumulation macro
TYPEMONI are now includes of EXMONSYS, and the first definition
Jan 5, 1990 (unused) of _ANALMON deaccumulaton macro was removed.
Thanks to Glenn Thompson, Comalco, AUSTRALIA.
Change 07.209 -Further ANALDB2R report validation fixed Accounting
ANALDB2R trace long (max page locks) and total lock suspends,
GRAFTMNT corrected ABEND in IOS report if PDB did not contain
ASUMVMON IOS trace data, and eliminated uninitialized variable
GRAFVMON message if nondefault sort parameters are used.
Jan 5, 1990 -GRAFTMNT did not properly handle tape mount reporting
if multiple systems were used, now it does.
-ASUMVMON spelled PFAULT incorrectly as PFAULTT.
-GRAFVMON had trailing ./ IEBUPDTE command.
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.208 Support for Landmark's TMON/MVS product ("TMV or TMVS").
EXTMVEL Twelve data sets: TMVSEL,TMVSIC,TMVSIOL,TMVSIOD,TMVSIV,
EXTMVIC TMVSJI,TMVSJIST,TMVSNQ,TMVSPS,TMVSSYS,TMVSYSSW,TMVSYSUI
EXTMVIOL are currently created, though there may be more later.
EXTMVIOD Landmark cooperated extensively in the development and
EXTMVIV testing/validation of this support. Most variable names
EXTMVJI are Landmark field names, except for "standard" MXG names
EXTMVJIS like STARTIME,ENDTIME,DURATM,SYSTEM, etc.
EXTMVNQ Release 1.12 of TMON/MVS must be installed (as record
EXTMVPS formats have been changed from earlier releases).
EXTMVSYS Unfortunately TMON/MVS does not create SMF records, which
EXTMVSW will necessitate a separate jobstream to read their data
EXTMVUI from the MXG-required DDNAME of TMVSIN.
FORMATS The TMON/MVS monitor data can be created in compressed
TYPETMVS format (as is Landmark's Monitor for CICS data), and
VMACTMVS the MXG-provided "SAS Infile Exit" named TMON (created
Jan 5, 1990 by member EXITMONI as described therein and in the
CICS chapter in the MXG Supplement) can be used to allow
MXG to directly decode their compressed format data.
After the "TMON" exit has been installed by EXITMONI
change "INFILE TMVSIN" to "INFILE TMVSIN TMON" to invoke
that exit which will handle either un-compressed or the
compressed data automatically.
Thanks to George Greenacre, Landmark Systems, USA.
Note added Oct 24, 1990. Landmark renamed Release 1.12 to
Release 1.1 (went from 1.11 to 1.1!).
===========Changes thru Change 7.207 comprised Prerelease 7.5==========
Change 07.207 IBM added nine new fields to the type 64 SMF record for
VMAC64 VSAM activity. Added to support IBM's marketing aid for
Dec 22, 1989 Hiperbatch analysis, these new fields (ACBSTRNO,BUFDRNO,
ACBBUFSP,ACBBUFND,ACBBUFNI,JFCBDSN,PLHCNT,ACBMACR1-3)
may prove useful in normal VSAM analysis, as the data
now indicates concurrent strings, buffer counts, and
read/write sequential/indexed flags as well.
PTF UY40839 (APAR OY23661) added the data to the type
64 record, but failed to update the IDAEXTWA macro to
document the order of the new fields! APAR OY26396
contains the actual DSECT of the new fields.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.
Change 07.206 NETVIEW type 37 record's LPDA (Modem report) section was
VMAC37 off by a few bytes, and some fields were not formatted to
Dec 22, 1989 display in hex. The quick fix is to change BRFLSL from
$1. to $2. and insert +3 after BRFADDR to align MXG with
the apparently undocumented changes in this record!
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.205 DB2 2.1 writes an SMF type 100 record with SUBTYPE='80'x
VMACDB2 instead of the expected value of 0 or 1. When or why is
Dec 21, 1989 not known at this moment, but it appears the field that
was originally documented as subtype is now a reserved
field. This change uses the product section IFCID value
to set SUBTYPE when the expected subtype value of 0 or 1
was not originally found. I'm still pursuing this one.
Find the lines:
@21+OFFSMF DB2BUF $CHAR4.
@;
and insert this new logic following that @; :
IF ID=100 AND SUBTYPE NE 0 AND SUBTYPE NE 1 THEN DO;
INPUT @25+OFFSMF OFFPROD PIB4. @;
LOC=OFFPROD-3+OFFSMF+4;
INPUT @LOC QWHSSIID PIB2. @;
IF QWHSSIID=1 THEN SUBTYPE=0;
IF QWHSSIID=2 THEN SUBTYPE=1;
END;
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 07.204 This is a "protective" change to protect you from your
VMAC6 own system programmers. A JES2 system programmer at one
VMAC26 site made incompatible changes to their type 6 and 26
Dec 20, 1989 SMF records when the site added support for 99,999 JES
numbers! This change eliminates the "NOTE: INVALID DATA
FOR JESNR IN LINE nnn bytes bb-ee. linenr : col " if
these incompatible records are processed by MXG.
What did the system programmer do? The 4-byte EBCDIC
field JESNR (which could contain only 0001-9999 in its
original EBCDIC format) was changed to a 4-byte packed
decimal (SAS PD4.) format! Programs expecting a 4-byte
EBCDIC format raised a data exception when they found
illegal EBCDIC numeric values in what was now a valid
packed decimal field. What did IBM do? As described in
the SMF manual, IBM stores EBCDIC value 0000 (which was
never a valid job number), and tells you instead to skip
3 bytes and read the 5-byte EBCDIC job number from the
previously-existing JCTJOBID field. What did MXG do?
The TYPE6 data set was okay, but the above "NOTE:" was
printed; MXG captured the 5-digit field correctly even
with their modfication. However, the TYPE26J2 dataset
had blank value for JESNR, and this caused BUILDPDB to
put all these jobs into SPIN rather than the PDB. The
simple fixes to MXG were: a) in both VMAC6 and VMAC26J2
change JESNR 4. to JESNR ?? 4. - this suppresses the
NOTE: and the Error condition when invalid data found,
and b) in both VMAC6 and VMAC26 change IF JESNR NE 0 to
IF JESNR GT 0 and c) insert new line in VMAC6 after the
line IF JESNR GT 0 THEN INPUT .. JESNR ?? 4. @; reading:
IF JESNR EQ . THEN INPUT @65+OFFSMF JESNR ?? PD4. @;
The site had made its own mods to JES mods before IBM!
Now MXG is robust enough to support this mod.
Thanks to Robert Manalo, EDS, USA.
Change 07.203 Change 7.061 was not applied to XMAC74 (which is only
XMAC74 used to circumvent a SAS limitation in large shops),
Dec 20, 1989 causing AVGPNCHA, AVGPNCUB and AVGPNDEV to be seconds
instead of milliseconds. Applied the changed.
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.202 Prerelease-only correction. VMAC6 corrections to handle
VMAC6 the SYSOUT release time (Change 7.137, added in MXG 7.1)
Dec 19, 1989 did not handle JES3 print record variables DATAERR,
OUTPRTY, SUPGROUP correctly, and could cause STOPOVER.
The INPUT statement after SUBSYS='JES3' OR SUBSYS='SAR'
should not have the offsets (OFFTONXT, OFFTONXT+nn).
Remove the offset from before variables DATAERR, OUTPRTY
SUPGROUP, SMF6RVSJ, and SMF6RSVU.
Thanks to MP Welch, Sisters of Charity of the Incarnate Word, USA.
Change 07.201 Variable SUBSYS6 has been created, equal to SUBSYS, to
IMACPDB identify the Subsystem (JES2,JES3,EXTW,PSF,SAR,EXD,CADI)
VMAC6 which created the print record. While SUBSYS already is
Dec 19, 1989 in TYPE6, BUILDPDB already uses SUBSYS from the TYPE30_4
(probably not a wise choice now!) Rather than changing a
meaning of an existing variable, adding SUBSYS6 here and
in IMACPDB (to the _PDB6 macro list of kept variables)
avoids a compatibility exposure. Why do you need SUBSYS?
Some sites want to recover CPU time spent by printing
subsystems (read PSF) by surcharging that subsystem's
PRINT charges. Unfortunately, additional CPU time caused
by PSF has been shown to occur primarily when a non-PSF
data stream is converted, and it is not possible to know
if data-stream-conversion occurred from a type 6 record.
record. (Call XEROX at 213-333-2068 for a free copy of
publication number 720P60340 "Benchmark Report JES2 vs
PSF in Text Oriented Printing" by Tom Bell and Chuck
Hopf. IBM should capture the CPU time for print events
and store it in the type 6, or at least a flag bit should
be set if PSF did convert the data stream. One comparison
shows if PSF takes 7 CPU seconds for Line Mode JES2 Dump
convert and print, a JES2 controlled 3800 Model 3 in Mod
1 emulation mode would take 1 sec. But conversion cost
may be only half the cost. A DCF prepared PSF data
stream of same size took 3 seconds. Sustained print rates
of 200 pages per minute are seen feasible for 3800 Model
3. The type 6 record does record PAGEDEFS FORMDEFS
FONT.... activity for PSF; nonzero counts here does
guarantee only that those PSF functions were invoked.
Change 07.200 NETSPY Release 3.2 added fields to the LU and APPL data
VMACNSPY sets, and is now supported.
Dec 15, 1989
Thanks to David W. Anderson, Chase Lincoln First Bank, USA.
Change 07.199 TPX Version 2 causes STOPOVER because the length of the
VMACTPX subtype 5 is incorrect. Their fix number TGB308A fixes
Dec 12, 1989 their problem. MXG failed to recognize the redefinition
of TPXM1SP0 over its two preceding fields (TPXPESIZ &
TPXPECD8) in a subtype 1 record, also causing STOPOVER.
This is corrected by inserting a new statement M4=-4;
after the @; after TPXMSMRT $CHAR8. and before the IF,
and then putting +M4 just before (TPXM1SP0-TPXM1SP9
Thanks to Larry Doub, RJR, USA.
Change 07.198 Goal Systems PDSMAN/XP Release 6 added five new fields
VMACPDSM (incompatibly, in the middle of the existing data!) which
Dec 12, 1989 are now supported by this change. LGJOB, LGMGEN, LGLMM,
LGNMM and LGRMGEN were added.
Thanks to Lesley Woolston, Manufacturers Hanover, ENGLAND.
Change 07.197 MVS/ESA 3.1.3 added numerous new data fields to SMF data.
EXTY42AU 1.TYPE6 data now identifies the Step which caused the print
EXTY42CU activity, and added security related information in these
EXTY42SC new PRINT variables:
EXTY42TO BIN1USED BIN2USED BIN3USED BIN4USED DIASLIG DIADPLWS
EXTY42VL DIAJHWP DIAUPAWS DPAGELBL ERROVRUN ERRSECOV INTEGRTY
EXTY83 PRSUCCES SMF6NSOL SMF6NSFO SMF6NPS SMF6FDNM SMF6PDNM
IMACPDB SMF6PTDV SMF6STNM SMF6PRNM SMF6DDNM SMF6USID SMF6SECS
TYPE42 SPAGELBL STDUPLEX SYSAREA TMBUPLEX
TYPE83 The variables SMF6STNM (stepname), SMF6PRNM (procstep)
VMAC6 and SMF6DDNM (ddname of print file) have been added
VMAC1415 to the default list of TYPE6 variables that will be
VMAC42 automatically carried into PDB.PRINT in MXG's BUILDPDB.
VMAC80 2.TYPE1415 data variables PDSE, TRUNC, and NULLSEG added,
VMAC83 and several fields documented as zero if PDSE-managed
VMAC90 (BLKCNT, TTRN, UCBSTAB, DSSEQCNT, DSSEQNR). The EXCPCNT
Dec 11, 1989 variable for PDSE-managed datasets counts pages read or
written. Before MVS 3.1.1, PDSE was referred to ILIB.
3.TYPE80 additional bit added to $MG080AU for BYPASS, new
character variable RACFVRMN (version, release, mod level)
replaces numeric RACFVERS, and new RACFTOSK (security
label) added by RACF 1.9.0.
4.New type 42 SMF DFP 3.2 record provides SMS statistics
configuration, and audits changes in five data sets
built from this record. Interval buffer statistics for
3990 cache controlers (total and by storage class) are
in TYPE42TO and TYPE42SC. Control Unit configuration and
delta statistics are in TYPE42CU (and SMS managed volumes
behind that control unit are in TYPE42VL). TYPE42AU
audits operator VARY SMS commands, ACTIVATEs in ISMF
or SETSMS, or ENF occurred because operator issued a
vary command to an SMS-managed volume. This is a new,
and significant source of information for management of
System Managed Storage, as well as 3990 statistics.
4.New type 83 SMF RACF Audit Record (For RACF Datasets
whose security label was changed by ADDSD, ALTDSD,
or DELDSD) is now supported in MXG dataset TYPE83.
5.Two new SMF options were introduced in MVS/ESA 3.1.3 that
allow the installation to never loose SMF data. LASTDS
and NOBUFFS can specify MSG (console message and continue
processing with loss of SMF data) or HALT (puts MVS in a
restartable wait state) whenever either no buffers or no
SMF data set is available to SMF. These options are now
contained in MXG TYPE90 dataset.
Change 07.196 DB2 2.2.0 changed SMF 102 SMF values in 21,30,31,44,62,
FORMATS and 140 IFCIDs, affecting formats $MGD044D, $MGD062S,
IMAC102 $MGD062O, $MGD140P, and creating $MGD063O. IFCID'S 63 and
VMAC102 106 were changed incompatibly, although only 106 has new
Dec 9, 1989 variables. The new Distributed Header is decoded, and now
all header variables are output in T102S106. Twelve new
IFCIDs (with many new variables) were added by DB2 2.2.0,
and these IFCIDS (plus the seven DB2 2.1 IFCIDS that had
not been previously decoded) are now supported by MXG.
With this change, ALL data produced by DB2 is now thought
to be supported by MXG. (There may be additional formats
added to MXG for a few of these new variables). The list
of IFCIDs within class has been updated in IMAC102. There
are also eight new "trace class" macro definitions that
are necessary in MXG (but only until SAS Version 6.06 is
universally available; the MXG use of the _DB2TCn macros
is necessary only because of an internal SAS limit on the
number of iterative DO statements, which has effectively
been eliminated in SAS Version 6.06). A later change will
be made to ANALDB2R to provide reports on these new DB2
DB2 elements. Initially, though, the changes primarily
support Distributed Data Facility, and the addition of
the Monitor Class data records (which contain the same
data already available in the DB2ACCT & DB2STAT datasets
from the 100/102 records!).
For the record, these new IFCIDs were added by this
change: TC1 (153), TC6 (156), TC7 (164,165,166,167),
TC8 (125,168), new TC14 (67), new TC15 (154), new TC16
(157,158,159,160,161,162,163), new Monitor Class MC1
(124,147,148,149,150), new MC4 (155), new AC7 (169),
new AC9 (146), new Accounting Class ACT4 (151), and a
new Statistics Class ST2 (152)! Whew!
Summary of this change: many hours to decode many record
segments which are unlikely ever to be needed by any
rational performance analyst!!!!!!!
Change 07.195 MXG assigned COMNDTYP of blank for command from a CCB,
FORMATS but blank is a CLIST from an FCB. This is corrected by:
VMACTSOM Add '40'X to $MGTSOCD format in FORMATS
Dec 7, 1989 Insert after 033700: RETAIN COMNDTYP ' ';
Insert after 042200: COMNDTYP='00'X;
Delete 042800.
Variable COMND may contain an 8-byte name or a 2-byte
command abbreviation padded with nulls instead of blanks,
which makes testing difficult. The translate function is
now used to convert nulls to blanks. In addition, the
date part of ENDTIME is wrong if the interval crossed
midnight. Correct by insert after line 037000:
IF TIMEPART(SMFTIME) LT STRTTIME THEN
ENDTIME=ENDTIME-86400;
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Steve Cavill, SAS Institute, AUSTRALIA.
Change 07.194 ACF2 variables ACTMFCBT (buffer text) and ACTMFKEY
VMACACF2 (record key) were not labeled and not kept, but now they
Dec 7, 1989 are.
Thanks to Ken Williams, ANZ Bank, AUSTRALIA.
Thanks to Raymond Wallace, NRMA, AUSTRALIA.
Change 07.193 Support for DB2 Version 2 Release 2 has been added for
VMACDB2 the DB2ACCT, DB2STAT0, and DB2STAT1 data sets built from
Dec 6, 1989 SMF type 100 and 101 records. IBM changes appear to be
compatible. DB2 2.2 added five QX..... variables for the
MIAP (Multiple Index Access Path) and Create/Drop Alias,
and 21 QLAC.... variables for DDF (Distributed Data
Facility) accounting to DB2ACCT. DB2STAT0 was also
enhanced with 18 QLST.... variables identical to their
QLAC.... counterparts for DDF statistics, and new Q3ST
and Q9ST DDF counters. DB2STAT1 was enhanced with the
same five QX..... variables for MIAP and QTAUCCH. Note
that DDF elapsed and CPU times are captured only in the
DB2ACCT data set (and not in DB2STAT0).
DB2ACCT variable DB2TCBTM is now calculated only if both
QWACBJST and QWACEJST are both non-zero, as IBM now does
document that zero value for either field means that no
CPU timing was available. An additional IBM note says
that QWACEJST is invalid for END OF MEMORY (RINV=24 or
28 decimal), QWACBSRB, QWACESRB, and QWACASRB are invalid
for DB Access Agents, but it is not clear how to identify
that situation. A final note in the PL/S DSECT says that
QWACEJST may be invalid when QWACRINV > 20 while the ASM
DSECT says it is invalid for EOM condition. I am still
checking with IBM:
IFCID 0003 (Type 101 SMF, DB2 Accounting record):
1. When "may" QWACEJST be invalid when QWACRINV > 20 ?
2. Is QWACRINV of 24 or 28 only values for EOM which
cause EJST to be invalid?
3. How does one know this record is for DB Access Agents?
4. When data is invalid, is it non-zero or zero?
5. What are units of QLACCPUL, QLACCPUR, and QLACDBAT?
Change 07.192 Continued validation of STX found the test in line 017500
VMACSTX should test for '02'X, '03'X (instead of '02X' and '03')!
Nov 24, 1989 and '12'X and '13'X should have been added, and corrected
labels for Application connect timestamps, swlu and lu.
Thanks to Larry Doub, RJR, USA.
Change 07.191 VM/SP Monitor channels 17-32 were not input due to bad
VMACVMON logic. Remove the ELSE in three lines 272000, 272400 and
Nov 24, 1989 272800.
Thanks to Bob Small, Grumman Data Systems, USA.
===========Prerelease 7.4 was for special ESP customer support=========
===========Changes thru Change 7.190 comprised Prerelease 7.3==========
Change 07.190 The DASDMON interval start date could be the wrong date.
ANALDMON The Start date in the record is not the interval start,
Nov 24, 1989 but rather the date when DASDMON initiated! The program
now uses the SMF record Date to correctly calculate the
interval start and end dates.
Thanks to Danny High, Blue Cross Blue Shield Texas, USA.
Change 07.189 The ASUMCICS trend program uses detail transaction data
ASUMCICS to create PDB.CICS with response distributions (pct in 2
ASUMDBDS sec) for reports and input to TRNDCICS. Now the program
Nov 24, 1989 will read either data source transparently; you no longer
have to remove comment blocks to use Landmark data.
The new ASUMDBDS program similarly sums the MONIDBDS
detail data into PDB.MONIDBD which matches PDB.CICS.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.188 New DB2 Reports were added. I/O Reports (PMIOS01-05), the
ANALDB2R Locking Reports (PMLOK01-03), and Record Trace Reports
IMACDB2 (PMTRC01-01) are completed. The Correlation Name and
VMAC102 Correlation Number are decoded differently for IMS, CICS
NOv 25, 1989 and other by the new _DB2CORR macro defined in IMACDB2.
However, detection of IMS, CICS, etc. in IMACDB2 can be
based only on job name (unless you can find a better
test), and you may need to modify those names if you
are concerned with CORRNAME and CORRNUM values. New
DATASET and PAGESET selection was added for I/O reports.
Preparation of the Record Trace report uncovered several
obscure type 102 variables that were spelled wrong or
left out of the KEEP= list.
How much storage does MXG need for DB2 data sets?
A site with 10000 DB2 plans executed per day will need
122 tracks of 3380 DASD for storage of the DB2ACCT data
set, and the DB2STAT0/DB2STAT1 data sets will need 8
tracks each (at 15 minute intervals), for a total of
only 138 tracks (9 cyl, or only 6 megabytes per day!)
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.187 SAR variable SARSW should be @165 vice @164 and @164 is
XMACSAR GCRMODFT $CHAR1.
VMACROSC
Nov 24, 1989
Thanks to Dee Ramon, Mutual of America, USA.
Change 07.186 Reading SMF type 71 records and ROSCOE data directly from
VMAC71 VSAM SMF file needed help. Line 066400 in VMAC71 needed a
VMACROSC +OFFSMF at the end, and line 114600 in VMACROSC should
Nov 24, 1989 have tested for LENGTH > 428+OFFSMF .
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.185 Contributed report for MVS/XA and MVS/ESA I/O pathing
ANALPATH configuration and activity, using TYPE73, TYPE74, TYPE78
Nov 24, 1989 and TYPE78CF datasets from a PDB. Self-describing.
Thanks to Cindy Batson, Hewitt Associates, USA.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 07.184 Logic expected subtype of zero, but non-zero value was
VMAC110 not protected. Now it is.
Nov 24, 1989
Change 07.183 SAS 5.18 accepted LENGTH DEFAULT=4 4; syntax, but Version
VMACVMXA 6.06 testing detected the incorrect syntax, which is now
Nov 21, 1989 corrected in line 456800.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 07.182 Change 7.151 fixed IMS, but part of the change was not on
TYPEIMS MXG 7.2. The two PROC SORTs (lines 107610 to 107670) were
Nov 21, 1989 to have been deleted, but were not. NOT SORTED error.
Thanks to Lynn Delacourt, Volvo GM Heavy Truck Corporation, USA.
Change 07.181 Change 7.035 discussed potential problems if you tried to
IMAC30IO eliminate D3330DRV variable. This change eliminates that
IMACPDB variable from the default I/O KEEP= list (in IMAC30IO)
BUILDPDB and the MAX/MIN/SUM logic was redesigned (in IMACPDB).
BUILDPD3 If you have not modified either IMAC30IO or IMACPDB, this
Nov 21, 1989 change is not impacting. HOWEVER, if IMACPDB or IMAC30IO
have been changed by your site, YOU MUST retrofit your
tailoring, using the new members in this MXG Version.
I'm still working on a way to fix this once and for all
sites without impact. An additional change was made in
IMACPDB that should not be impacting. The NODUP option
is now always used in BUILDPDB, and the _NODUP macro is
no longer referenced in BUILDPDB/3. (For compatibility,
though, the macro is still defined in IMACPDB).
Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 07.180 RMDS page counts for one class of data was stored as PD4.
TYPERMDS while all other counts were PIB4.! Change line 035600 to
Nov 21, 1989 PD4. from PIB4. There is no change in the SMF record for
RMDS Release 4.0, so we therefore now support RMDS 4.0!
(Documentation for the SMF record is in SC30-3442-1,
Installing and Customizing RMDS Release 4).
Thanks to Sim Fleisher, Depository Trust, USA.
Change 07.179 3390 DASD Devices are supported. EXCP3390 and IOTM3390
VMACEXC2 variables are created in TYPE30, PDB.STEPS and PDB.JOBS
VMACUCB data sets, and variable DEVICE (TYPE1415, TYPE74, etc.)
Nov 14, 1989 will recognize 3390. This change is in MXG 7.2.
Change 07.178 CICS UOWTIME is now set missing if there actually is not
VMAC110 a timestamp in UOWID. This is a further enhancement found
Nov 14, 1989 when verifying Change 7.170.
Change 07.177 Additional DB2 reporting has uncovered inconsistence in
VMAC102 variable names and some re-definitions of the same field
Nov 14, 1989 as two variables.
1.QW0021RP $CHAR8. is redefined over QW0021KD thru K2.
2.QW0044RP $CHAR8. is redefined over QW0044KD thru K2.
3.DBID and OBID variables were inconsistent. Most were
$CHAR2. formatted $HEX2. but some were PIB2. numerics.
Now all are $CHAR2., formatted $HEX4. and labels are
consistent. Note this affects the variables suffixed
with DB for DBID, but IBM uses PS and OB for PAGESET and
RECORD OBID, and also KP for PAGESET. This inconsistency
in different names for the same logical entity will not
be corrected in the MXG built T102Snnn datasets, but the
MXG MENU macro variable names used in reporting will be
DATABASE and PAGESET, no matter which IFCID variable name
contains the information.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.176 GTF format DB2 Trace Data was still not quite correct,
VMAC102 even after Change 7.122. The GTF header inserts 12
Nov 14, 1989 bytes before the triplets but the offsets themselves are
relative to byte 1. MXG used OFFSMF=12 (set in _GTF) to
flag the difference, but failed to use it properly!
The logic at lines 085900 thru 08500 now reads:
IF OFFSMF=12 THEN DO;
INPUT @29 SM102SSI $CHAR4. @;
OFFPROD=QWT02PSO-3;
END:
ELSE OFFPROD=OFFSMF-3+QWT02PSO;
The reset IF OFFSMF=12 THEN OFFSMF=0 after the triplets
have been INPUT is still correct.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.175 Support for STX Release 1.0+ has been coded and syntax
EXSTX... tested (no error first execution with SMF DD DUMMY!) but
IMACSTX real data has not been yet processed.
TYPESTX Five data sets (STXSTART, STXLOGON, STXLOGOF, STXCONON,
VMACSTX and STXCONOF are created.
Nov 11, 1989
Thanks to Larry Doub, RJR, USA.
Change 07.174 Support for Release 2.0.0 of TPX has been added to decode
VMACTPX the new format records as well as the prior releases. The
Nov 11, 1989 2.0.0 record is incompatible with prior TPX records, and
does require MXG 7.3. TPX 2.0.0 writes a wrong value for
length field MONO5LEN, (it's x28, but there are x30 bytes
in the segment based on MONO6LEN and MONO6ID) that MXG
detects and circumvents. New variables were added to the
TPXSTART, TPXAPLOF and TPXTRMOF datasets by TPX 2.0.0.
Thanks to ???, Swan Hunter Shipbuilders, ENGLAND.
Thanks to Larry Doub, RJR, USA
for excellent dumps and documentation.
Change 07.173 MXG VTOC processing had further validation:
VMXGVTOC a.Change 7.164 was misspelled. The Delete list should have
Nov 9, 1989 listed datasets EXTENT EXTENTS in place of EXTEND.
b.Line 128 example should be NEW=INFO vice NEW=MAP.
c.EQ MXTRACK should be EQ MXTRACK-1 in lines 649, 667.
d.LAST=MXTRACK should be LAST=MXTRACK-1 lines 652, 670.
e.VOLSER should be added to the KEEP= for INFO line 245.
f.Labels added for VTOCINFO new variables NTPC, DEVCYL,
DEVTRK, TOTRACKS, FCYL, FTRK, LCYL, and LTRK.
Thanks to Phil Henninge, Timken Company, USA.
Change 07.172 CA/DISPATCH variables are created in TYPE6 dataset by the
VMAC6 enablement of their decoding in MXG member IMACCADI. The
Nov 9, 1989 variable CADIRCIP was incorrectly spelled as CADIRCVR in
the KEEP= list in member VMAC6, causing CADIRCIP to not
exist.
A note on this MXG technique. SAS does not validate that
variables in a KEEP= list actually exist. If a variable
name appears only in the KEEP= list, that variable will
not be created. All of the CADI.... variables are in the
TYPE6 KEEP= list, but they will not exist in your TYPE6
dataset unless you modify IMACCADI, as all of the code
that creates the CADI variables (LABEL, FORMAT, INPUT)
is inside a comment block in IMACCADI. Removing that
comment block is all that is necessary to cause the
variables to be created AND kept. This technique works
for KEEP= list, but not for the KEEP statement; SAS does
validate the existence of all variables in KEEP statemen
Thanks to Carol Arnold, K-Mart Apparel, USA.
Change 07.171 CICS UOWTIME changes discussed in 7.170 are all true, but
TYPEMONI there was one other error (only in MXG's Landmark code)
Nov 6, 1989 that actually precipitated the discoverys in 7.171.
Line 060700 (ENDTIME=DHMS(ENDDATE,0,0,ENDTIME); must be
moved to new line 014710 (immediately before the line
BASETIME=FRSTBASE + FFFFF*(FLOOR(ENDTIME-FRST....
so that ENDTIME is converted into a datetimestamp first,
before it is used in the UOWTIME decode algorithm!
Thanks to Terry Baker, Royal Insurance, USA.
====FLASH 7.2 (accompanied 7.2 shipment starting in November, 1989)====
================printed Changes 7.170 to 7.162=========================
Change 07.170 CICS UOWTIME can be between 01JAN60 and 22JUL60, or can
TYPEMONI have right date and wrong time, or both may be wrong.
VMAC110 IBM stores times in two different non-unique formats:
Nov 3, 1989 - a 6-byte STCK value in sixteenths of a microsecond,
which wraps every 204 days and which therefore
requires logic to decide in which 204-day interval
since Jan 1, 1900 this UOWTIME occurred, or
- a 6-byte HHMMSS in EBCDIC characters.
Unfortunately, there is no sure way to identify which
format was used. HHMMSS only applies to DL/I batch
originators, but there is not yet an unambiguous test
to identify DL/I session. The 6-byte EBCDIC HHMMSS
field can contain hex F0F0F0F0F0F0x thru F2F3F5F9F5F9x,
all of which are also valid STCK values (on days 192 to
195 on the 204-day clock)! MXG always preserved the
value in UOWTIME, but its datetime value was sometimes
quite far off. Since NETSNAME and UOWTIME are used
to match up the TOR, AOR, and FOR transaction record
for an MRO event, and MXGs algorithm did support that
merge without error. MXG expected NETSNAME would end
with 12 nulls if not from DL/I, but actually NETSNAME
can contain when the originating terminal is
netname local terminal, from TCT
networkid.LUname VTAM ISC LUTYPE6.2 or IRC link
newtorkid.generic_applid non-VTAM or ISC LUTYPE6.1
jobname.stepname.procname DL/I batch session
and non-nulls caused MXG to fail to add BASETIME (real
start datetime of the present 204-day interval) to the
204-day value in UOWTIME. Then adding UOWTIME to the SAS
base date of 01JAN60 created the 1960 datetimes!
Further, MXG logic tested for a HHMMSS format first; a
real STCK value of 15:15:51 on day 192 of the 204-day
clock was changed to 00:00:00 HHMMSS!. Until DL/I can
be uniquely identified, MXG now always presumes the more
likely STCK format. At a specific site with knowledge of
specific newtworkid values in NETSNAME, one should be
able to recognize DL/I and convert back to HHMMSS, but
a generic solution is not obvious at present. UOWTIMEs
value itself may not be very important; as long as it is
constant across MRO regions, it serves its purpose.
In the interim, a quick circumvention happens to be to
change IF SUBSTR(NETSNAME,9,12)='0000...00'X THEN
to IF 1=1 THEN
to always cause the addition of BASETIME to UOWTIME and
to thereby bypass the ELSE DO logic testing for HHMMSS
or HH.MM.SS values at present. I hope it does turn out
that the actual UOWTIME value is useful enough for this!
Thanks to Terry Baker, Royal Insurance, USA.
Change 07.169 The length of variable CHARACTS needs to be 8 to keep the
VMACSYNC full resolution of total bytes sorted (just to make sure
Nov 2, 1989 comparisons are exact). With length 4, no significant
digits were lost, but low order truncation occurred.
Thanks to Glen Farmer, Hallmark Cards, USA.
Change 07.168 The format name MG080IA. was incorrectly spelled MG080AI.
ANALAUDT
Nov 2, 1989
Thanks to Richard Stevens, US Trust, USA.
Change 07.167 This utility which iteratively invokes VMXGVTOC to read
VMXGVTOR all online VTOCs used DO variable I in the outer loop but
Nov 2, 1989 changes to VMXGVTOC also used I. While VMXGVTOC was the
culprit, changing the "DO I=" in VMXGVTOR to "DO IVOR="
was simpler and safer.
Thanks to Don Wensel, Philip Morris, USA.
Change 07.166 Change 7.098 was correct in its text, but the spelling in
MONTHBLD the member should be DDNAME= instead of LIBNAME= in both
Nov 2, 1989 PROC DATASETS.
-----Changes thru Change 7.165 were published in NEWSLETTER FIFTEEN-----
Change 07.165 A comma was lost when re-writing comments in this example
EXITMONI JCL to create the TMON infile exit. Line 048500 needed a
Oct 30, 1989 comma at its end.
Change 07.164 MXG DASD VTOC processing did not clean up the WORK file
VMXGVTOC if multiple DASD Volumes are processed. After line 068200
Oct 30, 1989 insert:
PROC DATASETS DDNAME=WORK MT=DATA NOLIST;
DELETE VTOC1 DSNAMES EXTENT EXTENTS OKEXTENT;
MXG's 3090-200 CPU time to read 206 triple density 3380
DASD volumes is about 20 minutes per day.
Thanks to Phil Henninge, Timken Company, USA.
Change 07.163 TYPE71 variable EXTREADS (Pages Read from ESTORE) is only
VMAC71 valid if you have MVS/ESA (RMF 4.1+), but MXG created a
Oct 30, 1989 value even with RMF 3.5. Now it will be missing if you
are not yet on RMF 4.1+.
Thanks to George Scott, Rockwell International Corporation, USA.
Change 07.162 Format libraries in SAS Version 6.06 will be in a SAS
FORMATS data library, and must be created/referenced with the
Oct 21, 1989 DDNAME of LIBRARY, while SASLIB can still be used for
SAS Version 5.18 Format libraries (i.e., MXG.SASLIB).
This incompatibliity between SAS Version 5.18 and 6.06
will be disussed in Newsletter SIXTEEN. This change uses
the SAS Version under which MXG is executing to decide
if MXG Formats are to be created in the LIBRARY (6.06+)
or the SASLIB (5.18-) DDNAMES.
========Changes thru 7.161 comprised the pre=release of MXG 7.2=========
========Changes thru 7.161 comprised the pre=release of MXG 7.2=========
Change 07.161 This change is documentation of the procedures used in
Oct 19, 1989 the final testing of this prerelease of MXG 7.2.
It may help you in structuring validation of your own SAS
based systems, and will let you see MXG's test plan.
This process accomplishes these goals:
A. Syntax check and execution (no data actually read) of
all MXG code to build all possible MXG datasets.
B. Detection of conflicting definitions of same variable
in different MXG datasets (CHAR/NUM type, length and
format.
C. Detection of known coding errors, such as variables
without labels, DATETIME formatted variables with a
length other than 8, etc.
D. Automatic generation of DOCVER documentation of the
contents of all variables in all MXG 7.2 datasets.
E. Automatic generation of DOCVER07 delta-documentation
of all changes in contents between MXG Verion 6.6 and
this prerelease.
1.UTILXREF creates all possible MXG datasets and uses PROC
CONTENTS to create a SAS dataset of all variables in MXG
which is then analyzed for these known conditions:
-type conflicts (char and num in different datasets),
-missing label for variables,
-DATETIME formatted variable not length=8.
The SYSOUT is also examined for SAS ERROR: messages and
for UNINITIALIZED variable messages and any NOT CATLGD
JCL messages are located.
Change 07.160 Support for the ACF2 ARE data was added to the ACF2JR
VMACACF2 dataset created from the ACSMFREC='L' ACF2 SMF record.
Oct 19, 1989
Thanks to Raymond Wallace, NRMA, Sydney, AUSTRALIA.
Change 07.159 DB2 Trace dataset T102S063 contained only the first 200
IMAC102 bytes of the SQL text for each BIND, but the actual size
IMAC102A of the SQL text can be more than 200 characters. The SQL
IMAC102B text can be useful in understanding why a particular DB2
VMAC102 inquiry consumes large resources (DB2ACCT is used to find
Oct 19, 1989 the expensive executions, and their SQL inquiry text in
T102S063 is then examined to see why). Now, MXG will
create multiple observations in T102S063 for each 200
bytes of SQL text (new variable SEG10263 counts 200-byte
segment number).
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.158 This is not a change, but rather an observation that the
TYPEMONI byte-count on Landmark's own reports defaults to average
Oct 18, 1989 number of bytes per screen (PRIOUCHR/TCOUPRCN) but MXG
PRIOUCHR variable is total bytes for the transaction and
TCOUPRCN is the total number of screen. Landmark reports
will match MXG totals if "T" is added after the Landmark
field number on their report control statements.
Thanks to Tim Follen, Blue Cross of Ohio, USA.
Change 07.157 Preliminary support for Sterling Software's DMS/OS DASD
TYPEDMS management product's VTOC reading utility. Their utility
Oct 17, 1989 will read all VTOCs somewhat faster than MXG's VMXGVTOC
utility, and their utility's output is then used by this
member to create the DMSLIST dataset, similar to the
VTOCLIST dataset creatable by VMXGVTOC. However this
member does not create the VTOCMAP nor VTOCINFO datasets
created when MXG actually reads VTOCs with VMXGVTOC.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.156 Trend Data Base implementation of MXG Tape Mount Monitor
ASUMTMNT datasets includes a daily TAPEMNTS dataset and also a
GRAFTMNT TREND.TAPEMNTS. GRAFTMNT builds graphics catalog TAPEMNTS
TRNDTMNT from data either in PDB or TREND database.
Oct 17, 1989
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.155 Variable TMNTMTPY in line 004900 should have been spelled
VMACTMNT TMNTMTYP. In MXG 7.1 Beta only.
Oct 17, 1989
Change 07.154 This change eliminates a compatibility exposure between
BUILDPDB MXG 6.6 and 7. The SPIN6 dataset built by MXG 6.6 may not
BUILDPD3 be in order expected by MXG 7 (it depends on whether the
Oct 17, 1989 site added PRENTIME to the BY list in BUILDPDB/3 in its
implementation of MXG 6.6). This change inserts a PROC
SORT of the SPIN6 dataset before combining it with the
new TYPE6 dataset to avoid the possibility of the "out
of sort order" condition.
Change 07.153 In what is believed to be the final revision for VTOC
VMXGVTOC measurement, VMXGVTOC was again INCOMPATIBLY changed.
Oct 16, 1989 Previous users will need to change their reporting.
The MXG VTOC-reading facility now creates three datasets:
VTOCLIST - one obs per dataset, tracks allocated, tracks
used, creation, expiration dates, etc. This
was previously named VMXGVTOC.
VTOCMAP - one obs per extent/free space. A map of the
DASD volume. Previously named VMXGFREE.
VTOCINFO - one obs per volume, from the DSCB4. Size of
the volume, and VTOC flags such as Indexed
VTOC, Available DSCB0s, Available tracks,
System Managed Storage status, etc. New.
The description of this VTOC facility for DASD space
management and accounting is contained in extensive
comments at the beginning of the member itself.
Thanks to Don Wensel, Philip Morris, USA.
Change 07.152 IMS log processing variable MSGLEN (message length) may
VMACIMS be wrong. The LOC=MSGPRFLL in MXG 6.6 was changed in
Oct 16, 1989 MXG 7.0 to LOC=MSGPRFLL+1 to locate where MSGLEN is to
be INPUTed. It appears this change in 7.0 was wrong and
the MXG 6.6 logic is restored. Please look at the value
of variable MSGLEN for message size of a known IMS tran
and confirm if this LOC= logic is correct for your site.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.151 IMS log processing logic which merges datasets PRG and
TYPEIMS INOUT was incorrectly changed in MXG 7.0. The PROC SORTs
Oct 16, 1989 of PRG and INOUT just before the MERGE (lines 107610 to
107670) were deleted, and the BY variable of TRANSACT
for the merge was changed to the original DTOKEN. This
merge was more robust than the initial 7.0 change. All
other logic changes in 7.0 appear to be correct. A nit
was also noted: the format for ARRVTIME should be 19.2
for consistency with other DATETIME formats.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.150 -EXPLORE/VM variable SERIAL should be input as $CHAR4.
TYPEVMXP and formatted as $HEX8. in member VMACVMXP.
VMACVMXP -The %INCLUDE SOURCLIB(IMACVMXP) in member VMACVMXP
Oct 16, 1989 was moved to member TYPEVMXP.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.149 Variable OTH0CPU was not in the KEEP= list for dataset
GRAFTRND ALLCPU.
Oct 16, 1989
Thanks to Pete Shepard, Ashland Oil, USA.
Change 07.148 VM/XA Monitor dataset VXIODDEV variables AVGCONMS,
VMACVMXA AVGDISMS and AVGPNDMS are 1000 times to large. The 1000*
Oct 12, 1989 in lines 686900-687100 was removed. This dataset is not
typically kept, and all three values are correct in the
VXDEVDET, VXDEVTOT, VXSUMIOD datasets that are used in
MXG VM/XA report examples (because these averages were
recalculated correctly in building those datasets).
Thanks to Jeff Goodfellow, GTE Services, USA.
Change 07.147 Numerous discoveries during testing 7.1 Beta DB2 reports.
ANALDB2R All but subpart 4 apply only to ANALDB2R reporting and
VMACDB2 only to the STATISTICS reports.
Oct 12, 1989
-All QSDCKPT changed to QWSDCKPT.
-Second WRITE OUTPUT LOG BUFFERS lines 945200-945300 are
replaced by semicolon and line 944600 should be QJSTBFWR.
-After DB2 COMMANDS, lines containing @ 85 PUOR 'N/A'
should contain only @85 'N/A'.
-The Buffer Pool variables DB2ACCT QBnC... and DB2STAT1
QBnT... (where n is 1, 2, 3, 4) now correctly contain the
data corresponding with buffer pool id values 0, 1, 2, 80
for BP0, BP1, BP2, and BP32. Previously, n=1 variables
contained whatever BP was in the first segment. No data
was lost, but now the variable name n=1 to 4 does match
the contents correctly. (This was the VMACDB2 part).
The Buffer Pool reporting now uses a DO loop instead of
repetitive code, and only prints reports for pools with
activity. (This was the ANALDB2R part).
-QWHSSTCK (time stamp) in the DB2STAT1 dataset might not
be exactly the same ast QWHSSTCK in the DB2STAT0 dataset,
but DB2 reporting requires MERGE of those separate data.
Now, QWHSSTCK will be retained from subtype 0 to subtype
1 of the DB2 Type 100 SMF record so that the MERGE will
not fail. This change also compares the STCK value in a
subtype 1 with the previously retained STCK from the 0,
and PUTs error if out of sequence data is encountered.
-Variables QISEPAGE, QISECTS, QISEFREE, QISESKCT, QTDSOPN,
QISEDBD, QB1TCBA, QB2TCBA, QB3TCBA and QB4TCBA values are
end-of-interval values, but MXG summed their values. Now,
the MXG summarization calculates the average value of the
end-of interval data values for the interval.
-CORRNMBR and CORRNUM were redundantly named, and were not
parsed correctly for IMS connections. Now, CORRNUM is the
only variable used in ANALDB2R, and the values of the
QWHCCN (=:IMS,=:CICS, all else) is used to decide how to
parse CORRNAME and CORRNUM from QWHCCV.
-Second occurrence of DATABASE SERVICES in summary CPU
report (QJS3 variables) are actually for the IRLM, and
now the heading is correct.
-Macro variables were defined both in the ANALDB2R macro
definition, and in the macros called by ANALDB2R. This
redundant code added unnecessary lines and required care
in making redundant changes. Now, all macro variables are
defined only in the ANALDB2R definition and are no longer
explicitly defined in the actual report macro.
-QJST.... variables IDEN,CTHD,SIGN,TERM,ABRT,PREP,COMM,
INDT,RIUR,SYNC,CTHW should have been Q3ST in ANALDB2R.
Thanks to Jan van Lent, Fokker, NETHERLANDS.
Change 07.146 Variables QBnTPFDC, QBnTWKPD, QBnTWMAX, added by Change
DIFFDB2 7.130 to DB2STAT1 dataset were not deaccumulated. Now the
Oct 12, 1989 dozen variables are DIF()'d. Only MXG 7.1 Beta.
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.145 Line 942200 should be ARCHIVE LOG instead of ACTIVE LOG,
ANALDB2R Line 459300 NODUPKEY (PC syntax) should be NODUP for the
Oct 12, 1989 mainframe syntax. Only MXG 7.1 Beta.
Thanks to Pete Galaveri, Readers Digest, USA.
Change 07.144 Change 7.137 new line 012301 mistyped SMF6LN1 as SMFLN1,
VMAC6 causing "UNINITIALIZED" message and missing values. This
Oct 12, 1989 only affected the 7.1 Beta code.
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.143 Line inserted by Change 7.008 after line 23610 did not
BUILDPDB agree with Change. Line 023610 should be IF LAST.JESNR as
Oct 12, 1989 stated in the Change, replacing FIRST.JPURTIME in code.
Thanks to Debby Blackey, Marshalls, USA.
Change 07.142 PR/SM environment TYPE70 CPUWAITM and PCTCPUBY were wrong
VMAC7072 if the number of logical processors was greater than the
Oct 11, 1989 number of real processors. An MVS 3090-400 was given six
logical processors by PR/SM. The type 70 record shows MVS
NRCPUS is four, shows CPUs1-4 are online (CAI1-CAI4 are
'01'B, online-for-entire-interval), shows CPUSER1-CPUSER4
with the real serial numbers, and shows other CAIn and
CPUSERn values are blank. For the PARTISHN in which this
MXG is executing, there are six Logical Processor Data
Sections, creating six TYPE70PR observations, but the
only four that have non-zero LCPUPDTM PR/SM Dispatch also
have LCPUADDR values 1-4 matching the online CAIn values!
MXG correctly calculated individual CPU percent busy and
CPU wait in PCTCPBY0-8 and CPUWAIT0-8 variables using the
duration minus dispatch DURATM-LCPUPDTM, but MXG did not
correctly calculate CPUWAITM and PCTCPUBY in TYPE70 when
6 PR/SM Logical Processors are assigned to a 4-CPU MVS!
MXG summed wait time for all 6 LPARS, causing actual CPU
busy to be much lower than accurate. This change precedes
each of the nine CPUWAIT=CPUWAIT+CPUWAITM; statements in
lines 141300 to 146800 (logic for SHARED, WAIT=NO) with
IF CAIn EQ '......01'B THEN CPUWAIT=CPUWAIT+CPUWAITM;
and then changed n in CAIn to 0 thru 8 respectively.
IBM RMF reporting was also wrong with this data. Their
RMF Summary Report CPU BUSY reported an average 54% busy
(they used CPU0-3) instead of the true 65% busy from CPU
1-4 values. The CPU ACTIVITY report was also wrong with
CPU1s printed value taken from CPU0 (of 0%) and with the
2-4 CPU values taken incorrectly from CPU1-3 fields to
incorrectly report 61.4% busy when 78.5% was correct.
Thanks to O. V. Hanger, A. C. Nielsen Co., USA.
Thanks to Tim Klevar, General Electric Plastics, USA.
Change 07.141 Change 7.070 (only in MXG 7.0 BETA) was incorrect. The
ANALDSET lines of code after DATA DSETOPEN.DSETOPEN; from "IF" to
Oct 11, 1989 "DROP" must be moved to after TYPETASK=TYPETASZ;
Thanks to Debby Blackey, Marshalls, USA.
========Changes thru 7.140 were on the 7.1 Beta Tape===================
Change 07.140 IBM's Cache DASD RMF Reporter created SMF records do not
VMACACHE agree with documentation. GSLEN is 40, but the SD1IDCU is
Sep 14, 1989 in SD2ID instead of SD1ID. I am still researching when
this change occurred (this user is at CRR 1.3). The fix
is at line 028200-28300: change SD1ID=SD1IDCU to
(SD1ID=SD1IDCU OR SD2ID=SD1IDCU)
Thanks to Tom Healy, Chemnet, USA.
Change 07.139 SYNCSORT SMF record SIRECFM/SORECFM were decoded wrong,
VMACSYNC because SIRFM and SORFM were input as PIB1. but they are
Sep 14, 1989 actually EBCDIC numerics and should have been inputted
as 1. instead of PIB1. The CPUTCBTM in the SYNCSORT
record is sometimes wrong; values of 15 hrs 32 minutes
have been found by two different sites on SYNCSORT 3.2
and 3.3 (one site found one record per day, the second
found 50 such records in a month's SMF data). SYNCSORT
says this can happen if a SORT EXIT routine issues the
STIMER macro, but one site thinks the problem still
exists even when exits were not used. Still open.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Thanks to Russ Berlin, Time-Life, USA.
Thanks to Sal Fazzino, General Electric Capital, USA.
who reported this first, but who was not listed in Newsletter 15!
Change 07.138 This user contribution creates a SAS Function, FMXGSID,
FMXGSID which can be invoked from a SAS program and returns the
Sep 13, 1989 character variable of the SMF System Id (SMCASID, MXG's
variable SYSTEM) on which the job executed. This was
used to add SYSTEM to MXG VTOC datasets.
Thanks to Gerald Baxter, British Telecom (Red Lion Square), ENGLAND.
Change 07.137 This two-line JES2 system modification stores in a batch
ASMsysmod job's SMF type 6 record the time that that print file was
VMAC6 released to print. This permits direct measurement of the
Sep 18, 1989 printer queue duration for help print jobs. The mod was
originally coded by Carol Toll, Sun Company, and then it
was re-designed by Dean Tesar of Hewitt, who reduced it
to the following system modification:
In macro IFASMFR
after field SMF6RET
and before field SMF6END2.
add new line:
SMF6JTME DS BL4 JOE CREATE TIME
In source HASPPRPU (near label PPSMFBLD)
after MVC SMF6OWC,JOECURCL-JOE(R2)
and just before USING DCT,R2
add new line:
MVC SMF6JTME,JOECRTME-JOE(R2)
As with all system modifications, you accept liability
for all testing and validation of this enhancement to
your SMF data records. VMAC6 was modified to use the
type 6 length fields and will create RLSETIME if it
exists in your type 6 record.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 07.136 Variables CPUSER0-CPUSER9, CPU Serial Number from TYPE70,
RMFINTRV have been added to RMFINTRV, as they may be useful to
Sep 13, 1989 know which operating system was on which hardware when.
Thanks to Dave Clarke, British Airways, ENGLAND.
Change 07.135 NETSPY Versions earlier than 3.1 miscounted transactions
VMACNSPY because missing value of character variable (hex 40) just
Sep 13, 1989 happened to be the bit that 3.1 started using. Insert a
new line 038010 ELSE X2='00'X;
in case your NETSPY is an old version.
Thanks to Maria Clarke, Telecom Australia, AUSTRALIA.
Change 07.134 NETVIEW NPM Type 28 record subtype 41x (DRN Command, in
VMAC28 MXG dataset NPMCMDNC) are not structured as documented by
Sep 13, 1989 IBM. There is no TOF segment, and the AOF pointers point
to a PMC segment! This required relocation of the tests
for NPMSUBTY EQ 41X, and copying the present PMC handler
to before AOFTYPE='SAA' processing, and changing TOF to
AOF in that new PMC handler.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 07.133 IDMS 10.2 Monitor dataset IDMSTAS variables TASBFLD1-3
VMACIDMS should have been TASUFLD. The Batch Account Codes will be
Sep 13, 1989 decoded in the next MXG. See unfinished changes, above.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 07.132 The new 3480-IDRC "Improved Data Recording Capability"
VMAC1415 mode should be decodable from TYPE1415 variable TRTCH.
Sep 13, 1989 This change creates a new variable IDRC='Y' or 'N' for
tape data sets to indicate if IDRC was in effect. This
has not been verified. The new logic is:
IF TRTCH=08X THEN IDRC='Y';
ELSE IF TRTCH=04X THEN IDRC='N';
Thanks to Gene Tolini, IBM Vendor Support, USA.
Change 07.131 NETVIEW "Pseudo-SMF" records can be written to a journal
TYPE39J log file instead of SMF. These pseudo-SMF records do not
VMACSMF have legitimate VBS architecture, and do not have the
Sep 13, 1989 data in the standard SMF header (MVSXA, SMFTIME, SYSTEM).
This change adds a new macro named _NETVLOG which is used
in TYPE39J (J for Journal Log) in place of the _SMF macro
normally used. For a quick fix, make a copy of _SMF macro
and name it _NETVLOG. Therein, 1) Change RECFM on the
INFILE statement from VBS to U, and add BLKSIZE=32760.
2) Insert just before the INPUT statement a new line:
OFFSMF=4;
to align the rest of the record with normal SMF format.
3) Create TYPE39J from TYPE39, but replace _SMF with
_NETVLOG.
The actual fix is more extensive, as unnecessary code in
SMF was removed. Better still, put NETVIEW data in SMF!
Thanks to Gary Korkowski, The St. Paul Companies, USA.
Change 07.130 The DB2 DSECTS for DB2 Dated 11/17/88, which were used to
VMACDB2 add support for DB2 Version 2.1 (and which were supplied
Sep 13, 1989 by IBM) have been changed! There were three additional
fields in the buffer manager statistics (DB2STAT1) which
MXG did not know about, and which caused subsequent data
about buffers to be wrong. MXG added three new variables
QBnTPFDC, QBnTWKPD, and QBnTWMAX (where "n" is 1 thru 4,
for each of the four buffer pools), by adding logic for
LENBUFM GE 116, just like the LENBUFM GE 104 logic took
care of the last IBM change. The support for DB2 2.2
will add protection (with +SKIP logic) to eliminate this
exposure in the future.
Thanks to Robert Olah, Dun and Bradstreet, USA.
Change 07.129 Additional summarization routines for the DOS/VSE POWER
ASUMDOS and VM/370 Monitor data, a daily sample job for DOS/VSE
ASUMVDEV CICS journal and VM/Monitor processing, upgrading of the
ASUMVMON GRAF.... members to use PROC PLOT instead of PROC GPLOT
ASUMVMON if you do not have SAS/GRAF, additonal REXX examples for
DALY110J MXG under CMS version of SAS, Trending for DOS POWER, VM
DALYVMON Device data and VM/370 Monitor. These are preliminary
GRAFREGR examples and are subject to change.
GRAFTRND
GRAFVMON
REXXDALZ
REXXDOS
REXXWKLY
TRNDDOS
TRNDVDEV
TRNDVMON
WKLYVMON
Sep 12, 1989
Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 07.128 The validation of 7.0 Beta uncovered many opportunities:
FORMATS 1.VMACVMON, line 256000 set LENDV2=2 for RELEASVM EQ '05'.
VMACIDMS 2.TYPERTEJ, added MISSOVER on INFILE statement because IDMS
VMACRTE 10.1 writes short records.
VMACVMON 3.VMACRTE (IDMS 10.1 only) line 1301 added colon to now
TYPERTEJ read DBKFILE : $CHAR16. to protect for occasional short
Sep 12, 1989 IDMS record.
4.VMACIDMS: all PIB4.4 inputted variables are now formatted
TIME14.4 (180+ variables!). Variable SMFHDCVN was labeled
'DC SYSTEM*VERSION*NUMBER' and added to all KEEP= lists.
INSTIMSY and INSTIMUS changed from PIB4. to PIB4.4 and
added to TIME14.4 format list. DELTATM formatted TIME12.2
and variables PGMTYPE, TASPTYPE, TASTTYPE are now format
$MGIDMPP., $MGRTEPT., and $MGIDMTT. respectively.
5.FORMATS: values 6420 and 0A420 added to $MGVM6TY with
formatted value of 3380. (Appeared in VM HPO 5.0). New
formats $MGIDMPP and $MGIDMTT added.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 07.127 The validation of 7.0 Beta DB2 processing uncovered more
VMACDB2 cleanup. Labels for QWHCOPID and QXSETSQL were corrected,
Sep 11, 1989 the order in which QWHCOPID and QWHCPREV are INPUT was
reversed, DB2ACCT CPU times are now validated and set to
missing if Begin is greater than End, or if the End time
is missing (see INFO/MVS E321145), and the second INPUT
of QTXANPL was deleted, correcting subsequent QTXA....
Thanks to Stan Majka, Virginia Power, USA.
Change 07.126 The 7.0 Beta changes to the Audit report from RACF TYPE80
ANALAUDT had minor glitches. Line 168 should be OUTPUT SUF and not
Sep 11, 1989 INSUF, and lines 77-79 were replicated and INSUF changed
to SUF (to create SUF with same variables as INSUF).
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 07.125 This major contribution supports the ARBITER product from
ANALARB Tangram Systems which creates eleven different SMF record
EXARB... types with a total of thirty datasets created from the
IMACARB many subtypes.
TYPEARB
EXARBamm
Sep 10, 1989
Thanks to J-P Tonnieau, GMF System Team SARAN, FRANCE.
Change 07.124 MVS/370 CACHE DASD analysis report was updated for XA &
ANALCACH MVS/ESA. (MVS/370 TYPE74 variables LCHAN and DEVBUSY are
Sep 10, 1989 logically LCU and PCTDVUSE in MVS/XA and MVS/ESA). You
you still have to tailor this report as described in the
comments therein. The report combines RMF TYPE74 device
statistics with RMF Cache DASD Reporter TYPECACH data.
Thanks to Bruce L. Green, Medical Information Bureau, USA.
Change 07.123 DB2 APAR PL29461 PTF UL34399 added new data to a segment
FORMATS of the IFCID 0001 (Subtype 0, Type 100 SMF record) which
VMACDB2 MXG did not compatibly handle ("+SKIP" logic was missing
VMAC102 for this particular data segment in MXG code). This made
Sep 8, 1989 CPU variables for the 2nd and 3rd Address Space to be
wrong: QWS2PROC,EJST,SRBT and QWS3PROC,EJST,SRBT, and the
sum of all 3 address spaces cpu, CPUTM, when the above
PTF is installed on your DB2 Version 2.1 Systems. The PTF
new variables QWSnASID and QWSnASCB, the ASID and ASCB
respectively, are now added to the DB2STAT0 dataset, new
values for format MGD140P in member FORMATS were added,
and labels for trace variables QW0083QD,QW0087QD,QW0140SC
and QW140TC were changed based on IBM comment changes.
Only the change to member VMACDB2 is critical: You must
make the following change in member VMACDB2 if you have
the above PTF installed on any of your DB2 systems:
Find the line:
IF 0 LT OFFASID LT LENGTH AND NRASID GT 0 THEN DO;
Insert a new line following that line, containing:
SKIP=LENASID-20;
Find the next three occurrences of a line containing only
"@;". Insert the following new line after each of these
"trailing at-signs" (only three times, not four):
IF SKIP GT 0 THEN INPUT +SKIP @;
Thanks to Chun-Heng Liu, Brooklyn Union Gas, USA.
Change 07.122 DB2 trace records read from GTF (instead of SMF) do not
VMAC102 create observations because the reset was mislocated; in
Sep 8, 1989 addition, SMF102SSI was incorrect.
Find the present line:
IF OFFSMF=12 THEN OFFSMF=0;
Change that line so that it reads:
IF OFFSMF=12 THEN INPUT @29 SM102SSI $CHAR4. @;
Immediately before the present line containing:
OUTPUT SUBTYPES;
Insert this new line:
IF OFFSMF=12 THEN OFFSMF=0;
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.121 GRAFRMFI-produced graphs of RMF data gave funny-looking
GRAFRMFI graphs if your RMFINTRV dataset INTERVAL was less than
Sep 7, 1989 one hour. This change still produces plots versus hour,
but uses fractional values to plot between hours if
necessary. New line 009310 inserted
HOURPART=TIMEPART(STARTIME)/3600;
and change *HOUR= to *HOURPART in all occurrences.
Thanks to Joseph Ng Khek Uak, Port of Singapore Authority, SINGAPORE.
Change 07.120 Was accidentally skipped, and was never used.
Change 07.119 Boole & Babbage RMF replacement CMF product's SMF records
VMAC7072 can be created simultaneously with RMF records. This will
VMAC71 cause MXG datasets to contain essentially duplicate data
VMAC73 for the intervals when both monitors were running. This
VMAC74 change decodes the IBM reserved field at OFFRMFP+28 and
VMAC75 sets variable PRODUCT's value (normally "RMF") to either
VMAC76 "CMF-CPM" or "CMF-IPM", depending on the CMF mode that
VMAC77 created the record. This allows CMF and RMF records to
VMAC78 be separated, if both should exist. Since the variable
Sep 7, 1989 PRODUCT exists only in MVS/XA and later, this change does
not support identification of MVS/370 CMF from RMF data.
On the subject of CMF, though not related to this change,
CMF creates a PR/SM data segment in its type 70 record
under either IBM's PR/SM or Amdahl's MDF hardware. MXG
creates observations in TYPE70PR from the PR/SM segment.
(RMF users must use TYPEMDF, Change 7.087, to decode its
separate SMF record from Amdahl's MDFTRACK instead.)
Also, note there is no type 79 record created by CMF.
Thanks to Richard L. Gimarc, Boole & Babbage, USA.
Thanks to Allan Callahan, SAC Offutt AFB, USA.
Change 07.118 MXG DB2PM-like reporting has been further enhanced. All
ANALDB2R reports possible have been tested with DB2 Version 2.1
Sep 6, 1989 data (as well as prior DB2 versions). Additional reports
have been added, and all reports planned for MXG Version
7 have been named (even though some do not yet exist).
See member for revised documentation and details.
Change 07.117 DB2 Report PMACC01 values on **TOTAL** lines were totals
ANALDB2R of averages because wrong denominator was used in three
Sep 5, 1989 places. Insert three lines to correct:
line 07951000 FREQ=L2FREQ;
line 08411000 FREQ=L1FREQ;
line 08871000 FREQ=GFREQ;
Thanks to Alan W. Maloney, Telenet Communications, USA.
Change 07.116 A minor omission, &OTHER6 was left out in lines 019300 to
GRAFTRND 019600. 12="&OTHER6" inserted after 11=, and &OTHER7 to
Sep 5, 1989 &OTHER9 became 12 to 15, deleting the extra &OTHER9.
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 07.115 ACF2 data sets ACF2NRA & ACF2NRB contain 0 observations.
VMACACF2 ACF2 SMF record subtype 'A' has JOB name of hex zero.
Sep 5, 1989 MXG includes IMACJBCK (an MXG macro which allows for JOB
name selection during creation of MXG data sets) BEFORE
checking the record subtype, which caused all ACF2 'A'
records to be deleted. Line 0345's %INCLUDE was moved to
after 0365 and executed within a do group:
IF ACSMFREC NE 'A' THEN DO;
%%INCLUDE SOURCLIB(IMACJBCK);
END;
Additionally, line 0376 (ACFAPMLN) should be PIB2. vice
PIB1., and line 0379 AFCAPARM should be spelled ACFAPARM.
Finally, ACFACID is formatted as $HEX2. (in line 0328).
Thanks to Raymond Wallace, NRMA, AUSTRALIA.
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
Change 07.114 VMAC7072 PR/SM variables were wrong (only) when SMF data
VMAC7072 was read from the VSAM SMF file. Line 132700 should read:
Sep 5, 1989 LOCPRDS=OFFPRDS+BDNSKIP*LENPRDS-3+OFFSMF;
Additionally, SMFTIME was not kept in TYPE72MN, and
ZDATE was not kept in TYPE72MN or TYPE70PR datasets.
Thanks to Barry Pieper, First Bank System Information Services, USA.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.113 RMF Monitor III VSAM data set support validation found a
VMACZRB few changes. In VMACZRB, field GEISIZ is now spelled as
ZRBJCL GEISIZE. The lengths (see inital comments in VMACZRB) of
Sep 5, 1989 ASISIZE was changed from 84 to 88, and of GEISIZE was
changed from 92 to 96 by RMF 3.5. In ZRBJCL, the correct
DDNAME is RMFIII vice ZRBIII. It has been reported that
only minor changes (tests LENGTH was tested for explicit
value instead of GE, I think) are needed for this code to
also support RMF 4.0 (MVS/ESA) RMF III, but that has not
been identified/tested yet.
Thanks to Neil Ervin, Sara Lee Direct, USA.
Change 07.112 Member ANALBNC1, for the analysis of benchmark runs, is
ANALBNC1 not really complete (in that the benchmark job stream is
Sep 5, 1989 not yet in existence) but some users have still found the
member was a good starting point for comparisons of their
own benchmark stream. This change upgrades the code so
that at least it runs without errors due to incomplete
comments, misspelled variables, etc.
Thanks to Harry Olschewski, DVG Kiel, GERMANY.
Change 07.111 This is a major revision to the MXG VTOC reading utility.
VMXGVTOC All variables are now labeled, and additional fields in
Sep 1, 1989 the VTOC (tracks allocated, tracks used, expiration date,
last use date, etc.) are now decoded in the MXGVTOC data
set. The VTOC itself is now recognized as occupying DASD
space, and free space after the last dsname on the volser
is now included in the MXGFREE data set. With this change
MXG really does capture the VTOC information for capacity
management of your DASD farm as well as for the billing
of DASD usage. The number of tracks on the volume is now
contained in the MXGVTOC data set in the DSNAME of the
VTOC data set (see comments in member).
Thanks to J. Cary Jones, Philip Morris, USA.
Thanks to Chris Luckman, SAS Institute, ENGLAND.
Thanks to Jugdish Mistry, SAS Institute, SCOTLAND.
Change 07.110 In searching for info on 3480-IDRC in INFO/MVS, I found a
VMACEXC2 reference to a new Device Type of x'81' for Device Class
VMACUCB of x'80' (Magnetic Tape), decoded as device type 9348. On
Aug 31, 1989 Sep 5, the 9348 (a 1600/6250 reel drive) was announced!
In examining UCBTYPE for decoding the 9348, a new Device
Class value of x'04' (Character Reader) was noted. Also
on Sep 5, IBM announced the 3490 tape cartridge device,
(a 3480 with IDRC built-in and a smaller footprint).
MXG member VMACUCB creates values of variable DEVICE.
MXG member VMACEXC2 accumulates EXCP/IOTM counts into the
device-specific variables (EXCP3420, EXCP3480, etc.).
a. VMACUCB now sets DEVICE variable values of 2400, 3420,
3480 or 9348. (Previouly, DEVICE was either 3420 or 3480,
and 3420 meant "all tapes not-3480").
b. VMACEXC2 IOTM/EXCP summarization for Tape Class continues
to keep only XXXX3420 and XXXX3480 variables, and 9348
counts are included in the XXXX3420 variables. XXXX3420
variables still mean "all tapes not 3480".
c. VMACUCB also now creates a value of CHARRDR for DEVICE
for device class of x'04'. (If you had actually had any
x'04' values, MXG would have produced an error message on
the SAS log, and none have ever been reported!)
d.VMACEXC2 counts EXCP/IOTM counts from device class x'04'
in the XXXXUREC variables.
Attended SHARE to present paper on the history of SMF Product's 1969
release, twenty years ago (and the 20th anniversary of the SHARE CME
Project as well). The paper is published in MXG Newsletter FIFTEEN,
in Volume One of the SHARE 73 PROCEEDINGS, and elsewhere as well.
Change 07.109 Unknown DOS Accounting records caused MXG to STOP reading
TYPEDOS the DOS file, which was inappropriate. Now, if an unknown
Aug 3, 1989 record id is encountered, a message and a hex dump of the
first ten occurrences are printed on the SAS log, but the
MXG program continues to read the rest of the POWER data.
The unkonwn record encountered was RECID='D', which looks
like an execute record, but is still under investigation;
it may be created by a vendor-product.
Thanks to P.J. Penrith, Kleinwort Benson, ENGLAND.
Change 07.108 Landmark's Monitor for CICS History Data OVHD Records are
TYPEMONI incorrect due to an error in Landmark's TMV630 program.
Aug 1, 1989 The OVHD,History record (not typically used by MXG users)
is one byte too short, and causes an "INPUT EXCEEDED" SAS
error message and STOPOVER ABEND. Landmark now has a fix
to create valid records, but until you apply their fix,
this circumvention will avoid the ABEND:
Insert after line 040600 (USER $CHAR8.) :
@; IF SUBSTR(TRANSACT,1,4) NE 'OVHD' THEN INPUT
Insert after line 040800 (@;) :
ELSE INPUT LUNAME $CHAR7. @;
Remember to remove this fix after you get the fix from
Landmark installed.
THIS CIRCUMVENTION WILL NOT BE PUT IN MXG SOURCE CODE.
IT IS ONLY FOR YOU TO TEMPORARILY INSTALL IN YOUR SYSTEM.
Thanks to Neil Ervin, Sara Lee Direct, USA.
October 19, 1989 update:
Another site tried the above circumvention before they
got the fix from Landmark, and still abended, because
in their case, the record had no FILESEGs, so that the
input DO loop is not executed, then the code in line
048600 is executed, and the STOPOVER occurs in trying
to input UTNUM PIB1.
Their additional circumvention, then, was
IF SUBSTR(TRANSACT,1,4)='OVHD' THEN UTNUM=0;
ELSE INPUT UTNUM PIB1. @;
Thanks to Anthony Miekle, Composite Buyers, AUSTRALIA.
Change 07.107 Change 7.060 (7.0 Beta ONLY) added type 37 support for
VMAC37 NETVIEW 1.2 and NETVIEW 1.3 records. Earlier versions of
Aug 1, 1989 NETVIEW (1.1) and prior NPDA (V3R2,V3R3) STOPOVERed. The
code now supports all of these records, and additionally
now decodes the local and remote modem reports into 12
new variables each.
Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.106 IDMS SMF records have been further validated and a few
VMACIDMS fields (which had existed in the old RTE records) are now
Aug 1, 1989 added in this minor enhancement.
Add TASMSSEV to keep list in line 013700.
Label TASMSSEV='TASK ABEND*SEVERITY*CODE'
PMHTSKID='TASK ID*NUMBER' after 019700.
Add TASPRTY to the $HEX2. format list in 072400.
Insert after 136100:
TASMSSEV=MOD(TASABMSG,10);
TASABMSG=INT(TASABMSG/10);
Thanks to Rodney L. Reisch, Wacovia Bank and Trust Company, USA.
Change 07.105 Type 6 PSF records had variable FORM wrong, because IBM's
VMAC6 8-byte "form" field in the Common Section of the PSF type
Jun 30, 1989 6 record does not contain the form! This fix may change
Feb 7, 1990 if IBM ever moves an 8-byte form name into the PSF record
but for now, you must change line 021300-021500 to read:
IF SMF6LN3 GE 14 AND SUBSYS NE 'PSF' THEN INPUT FORM $CHAR8. @;
ELSE IF SMF6LN3 GE 14 THEN INPUT +8 @;
Feb 7, 1990 update: SMF6LN3 was printed here in CHANGES
as SMFLN3 in error, and corrected today. VMAC6 was okay.
Thanks to Agneta Bergsten, SPP, SWEDEN.
Change 07.104 Shift calculation changes made in Version 6.6 did not
IMACSHFT affect the SHIFT variable, but the value of the DATETIME
Jun 28, 1989 variable passed back to the caller was not always right.
Since the returned value was used only infrequenly and
only in trending, this should not really cause a problem:
Insert new line 005701:
ELSE IF WEEKDAY(DATEPART(DATETIME)) EQ 2 THEN
Remove ELSE from beginning of line 005800.
Thanks to Gary Kallenber, CONTEL, USA.
Change 07.103 New style macro %VMXGSUM requires SAS System Option of
ANALDB2R MWORK=28K, else an 1453 Invalid Parameter Length error
Jun 28, 1989 occurs. While MWORK=28K was shown in MXG Trending example
in 6.6, rewrite of ANALDB2R using the new style macro did
not remind you to specify MWORK=28K for DB2 reports.
Change 07.102 MXG Tape Mount Monitor SMF record processing code had two
FORMATS formats reversed (lines 004900 and 005000) and failed to
VMACTMNT decode TMNTMTYP (Type of Mount, 0=Demand, 1=Private, and
Jun 28, 1989 2=Scratch) correctly. New format MGTMNTM. added to member
FORMATS. Replace present line TMNTRTRN PIB4. with two:
TMNTRTRN PIB2.
TMNTMTYP PIB2.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 07.101 VM/370 Monitor data for USER class did not exactly match
VMACVMON VMMAP. MXG did not output the first interval record, and
Jun 28, 1989 then deleted the second interval user record in the DIF()
logic. Change line 248700 (precedes EXVMOUSR's include)
to read IF INTRVCNT GT 0 THEN DO; instead of GT 1 THEN.
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.100 TMS DSN record caused STOPOVER due to bad logic. Correct
VMACTMS5 by inserting IF I=1 THEN before INPUT in line 0146.
Jun 28, 1989 Also, all packed decimal input fields were precedeed with
?? (between variable and PDn.) to protect if the field
has nulls instead of a valid PD field. The ?? tells SAS
to suppress the "invalid PD" message and to suppress the
hex dump of a record with invalid PD data!
Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.
Change 07.099 Default record ID of 255 in IMACAION caused STOPOVER when
IMACAION an SMF ID=255 record (from a diferent product) was read.
Jun 18, 1989 Default should have been 512.
Thanks to Jim Kane, Reader's Digest, USA.
========Changes thru 7.098 were on the 7.0 Beta Tape===================
Change 07.098 Creation of CICS data sets by BUILDPDB beginning in 6.6
BUILDPDB removed the PROTECT=ZZZZZ option from the CICSACCT,
May 31, 1989 CICSEXCE, and CICSYSTM data sets. This could cause an
error when 6.6 attempts to reuse a 5.5 PDB library. (See
extensive discussion of PROTECT= in member CHANGE06). To
avoid the problem, you can simply scratch and reallocate
each PDB library before its re-use. Alternatly, you could
simply delete the three protected datasets from the PDB
library before you run MXG 6.6, by executing:
PROC DATASETS NOLIST DDNAME=PDB MT=DATA;
DELETE CICSACCT CICSEXCE CICSYSTM PROTECT=ZZZZZ;
Thanks to Greg Bowman, Walmart, USA.
Change 07.097 MXG support for type 79 SMF records is not functional.
VMAC79 This member needs lots more work before it can even be
May 31, 1989 tested. Do not try to use or understand it.
Change 07.096 HSM can create an SMF user record, whose contents is in
EXHSMDSR LY35-0080-1 pp180ff as the Daily Statistics Record. The
EXHSMFUN MXG support creates two data sets, HSMDSRST (statistics)
IMACHSM and HSMDSRFU (for each function) from the DSR record.
TYPEHSM There are two other subtypes of the DSR record that are
VMACHSM documented (FSR, p191 and VSR, p348s) but are not yet in
May 31, 1989 this preliminary code. I have only bench tested the code.
Member VMXGHSM contained the basic code for the DSR data
record, and FSR and VSR will be restructures of that code
as well. All of these segments existed (apparently) in a
single SMF record, but there is yet another SMF record
that I can not recognize. This is just a beginning.
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.095 The VMSQL... datasets created from VM/ACCOUNT cards will
TYPEVM exist only if your VM SQL machine's name (USER) begins
May 30, 1989 with SQLDBA. If your SQL machine has a different name,
see comments in the member. Additionally, data records
with apparently invalid values for SQLCPUTM (FFF91A25x)
have been reported to IBM, but no response yet. MXG uses
PIB4. format, and these values show up as large positive
values. Using IB4. instead would create negative values,
which might be easier to detect if you are looking for
bad values. But I think PIB4. is still safer, since you
can hardly overlook the bad data with large positive data
values, but with mixed positive and negative numbers, the
summing could cause the bad data to be overlooked. You
should always compare CPU measurement with the elapsed
duration of the interval (in this case, how long the VM
SQL machine was executing) to detect this type of IBM
error (which should eventually be fixed by an IBM PTF).
Should I externalize the test for SQL machine name into
a new macro name in a new member of MXG?
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 07.094 EPILOG CL1000 Version 440 support was tabled until later.
XMACEPIL I did not have all of the DSECTs I need when working on
XXACEPIL XMACEPIL, and when Candle provided me with their sample
May 30, 1989 code, it did not agree with the actual records. Member
XXACEPIL is partially corrected, decoding at least the
header (due to the DSECTS sent for Change 7.090), but
development was pended awaiting DSECTS and test data from
Candle.
Thanks to David Lloyd, Talbots, USA.
Thanks to M. Peller, Braun AG, GERMANY.
Change 07.093 Type 22 SMF record for 3990-3 Cache DASD controller has
VMAC22 had its problems. The subtype 10 data was left out of ESA
May 30, 1989 by IBM, and in the fix to that problem, four new bytes
have been added to the end of the record. Unfortunately,
segment length is not in the data record, and if IBM ever
writes more than one subtype 10 per section, the TYPE22_A
data may be incorrect. This is not an important record.
The missing segment was reported in MVS/ESA with APARS
OY22641/OY11323, and PTFs OY22641/UY90164 add the new
fields and for ESA creates the missing subtype.
Change 07.092 Preliminary support for SMF record created by COMPUWARE
IMACFILA product FILEAID. The access records seem usable, but the
TYPEFILA Field Update and Comprehensive Update records appear to
VMACFILA be of questionable value, especially since pointers do
May 25, 1989 not appear to exist to connect the record to its dataset!
Thanks to Mark A. Hawkes, Monarch Systems Group, USA.
Thanks to Timothy T. Tadeo, Monarch Systems Group, USA.
Change 07.091 This contributed report uses the TYPE30_5 record to count
ANALBATQ how many batch jobs are in the input queue. This report
May 25, 1989 has not been extensively tested yet, and may change.
Thanks to Neil Ervin, Sara Lee Direct, USA.
Change 07.090 Support for Candle's Omegamon Audit (hence OMAU) SMF user
EXTYOMAU record, written for each execution by an operator of an
IMACOMAU audited OMEGAMON command. The code is syntax checked and
TYPEOMAU visually validated with a hex dump of the data. but has
VMACOMAU not been actually used to read real audit records.
May 25, 1989
Thanks to Jonathan Swann, Belk Stores Services, USA.
Change 07.089 Support for AION Development System's SMF record, which
EXTYAION creates data set AIONACCT, an accounting record created
IMACAION when AION executes under IMS.
TYPEAION
VMACAION
May 25, 1989
Thanks to David Daner, Sun Refining and Marketing, USA.
Change 07.088 Variable DOWNTIME in TYPE90 is a duration, not a datetime
VMAC90 stamp and should have been FORMATed TIME12.2 instead of
May 25, 1989 DATETIME21.2. (It really should have been spelled DOWNTM
to be consistent, but its too late to change its name.)
Move DOWNTIME from line 009100 to 009000.
Thanks to Jonathan Swann, Belk Stores Services, USA.
Change 07.087 Support for Amdahl's SE Tool MDFTRACK's SMF record. This
EXTYMDF record describes activity in other MDF Domains, using the
IMACMDF MDFWATCH data. Amdahl cautions that this is not really a
TYPEMDF supported product but instead it is an SE's tool and is
VMACMDF subject to change (and not all fields are documented).
May 25, 1989 - GBLTOD is GMT while GBLBEGTS/GBLENDTS/SMFTIME local.
- GLBENDTS/GBLBEGTS resolve only to seconds.
- GLBINTMS is the actual interval duration.
- Units of DOMMIN,TGT,MAX,NORM,ATGT and GBLELTM? All
are same (and 879.068 if PIB4.3).
- Units of DOMDUTIL, DOMSUTIL,DOMUTIL.
- Validity of DOMNTSC.
- Validity of GBLRSERN.
- Avg Time slice calculation?
By comparing your online screen displays of the numbers
with a PROC PRINT of the MXG-built data sets, you should
be able to figure out how to replicate the screen report
values exactly from the MXG variables. Let me know.
Thanks to Dennis Dwyer, Citicorp St. Louis, USA.
Change 07.086 FOR VM/XA ONLY: Remove both occurrences of STOPOVER in
VMACVMXA the two INFILE statements for VM/XA Monitor processing!
May 24, 1989 I never thought I'd recommend not using STOPOVER, but it
looks like that's the best way to deal with the newest
idiosyncrasy of VM/XA. MONWRITE creates logical records
that span physical blocks! The only case in which this
spanning has occurred so far is the MTRDDR (1.14) record,
written only at VM/XA Monitor Start-Up. A large number of
devices + userids created a 1980 byte record which began
at byte 3021 of one 4096 byte block (1076 bytes in the
first block, 904 in the second). If this had been real
IBM VBS Record Format, SAS could handle spanned records,
but the VM/XA data is a series of blocks of 4096 byte
pages written in blocks of from 4096 to 7*4096=28672
bytes, containing two different sets of control records
interleaved between sequences of blocks of data records.
This non-standard record structure would permit the DCSS
to be re-created in an analysis program. The IBM manual
suggested algorithm required keeping track of page within
block and byte within page and databytes within control
interval; that's a lot of unnecessary CPU processing if
it's really "data processing" (i.e., reading lots of
monitor data) you want. Besides, maybe someday we'll
get MONWRITE re-written to create real, valid, VB data
record format to really minimize the I/O overhead.
The MXG Algorithms treat the VM/XA Monitor data as an
imperfect VB architecture, building heuristics to skip
over defects, such as the End of Frame record, a valid
self-describing 20 byte record followed by an undescribed
number of hex zeros - if the Record Length included the
zeros following the header, the MONWRITE data records
would at least be valid Variable-Blocked data between the
control records! But spanned logical records were not in
IBM documentation, nor seen until now.
The STOPOVER option has been discussed in the book, and
in previous CHANGExx/NEWSLTRS entries. It is very useful
to protect me and you from coding and data errors. It
makes SAS stop reading input records when the MXG program
tries to read beyond the end of the current logical (to
SAS) record. HOWEVER, the simplest fix to the VM/XA
Monitor's "spanning" of data is to remove STOPOVER from
the INFILE statements. SAS will continue on to the next
block with no other change to the MXG algorithm! You will
receive a "SAS READ BEYOND THE END OF A LOGICAL RECORD"
note (which does not set any error condition) on the log.
Martyn Stevens has coded a circumvention which works at
his site, but which works only if the end of each 1.14
record occurs exactly at the end of a page. The removal
of STOPOVER is thought to be a more robust solution, and
it demonstrates the versatility of SAS. The ability to
read multiple logical records as a single data record is
a boon to social scientists with 80-byte card image data,
10 card images per subject. SAS lets you treat that as a
single, 800 byte record (which reduces the human errors
in data entry, coding, etc.). STOPOVER is still useful in
SMF and other structured data records, but I think the
tests built into MXG are strong enough to detect any real
VM/XA errors softly. The removal of STOPOVER in this case
may let the latent power of SAS shine through, but Martyn
says even MISSOVER may not always work and he is sending
a VM/XA monitor tape for further analysis.
Thanks to Martyn Stevens, Barclays Bank, ENGLAND.
Change 07.085 VM/XA IUCV/VMCF fields had two labels reversed; PLSVSEVM
VMACVMXA should be "GOOD FROM" and PLSVSTVM should be "GOOD TO".
May 24, 1989 The following table may make IUCV/VMCF analysis easier.
--------TO--------- --FROM--
Service Destination GOOD BAD GOOD
IUCV: BLKIO PLSISTBL PLSISUBL PLSISEBL
CCS PLSISTCC PLSISUCC PLSISECC
MSG PLSISTM PLSISUM PLSISEM
MSGALL PLSISTMA PLSISUMA PLSISEMA
MONITOR PLSISTMO PLSISUMO PLSISEMO
RPI PLSISTRA PLSISUTA PLSISETA
SIGNAL PLSISTSI PLSISUSI PLSISESI
CP*SYSTEM SERVICES PLSISTVM PLSISUVM PLSISEVM
VMCF: A Virtual Machine PLSVSTVM PLSVSUVM PLSVSEVM
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 07.084 The 1984 MXG Guide, page 213, shows the IBM CICS tables
MXG Guide that need to be assembled to create type 110 CMF SMF data
May 24, 1989 records. The syntax CLASS=(PERFORM,ACCOUNT,EXCEPTION) is
not acceptable, apparently, for CICS 1.7. A site reported
IBM support said a separate DFHTYPE=RECORD statement is
needed in the MCT for each Class of data monitored. Also,
the example on page 213 should have suggested CONV=YES be
specified, so that each CICS interaction/conversation's
response time is measured.
Thanks to Bill Fox, National Futures Association, USA.
Change 07.083 RMFINTRV variables SIO74CNT,DEVACTTM,DEVCONTM,DEVDISTM, &
RMFINTRV DEVPNDTM were documented in the MXG Supplement to contain
May 24, 1989 only DASD device data, but RMFINTRV was never updated to
select only DASD type 74 records. (Note that even after
this change, that total SIO counts are still carried in
the SIO78CNT variable). Insert new line 072010:
IF SUBSTR(PUT(UCBTYPE,HEX8.),5,2)='20';
Thanks to Cathy Librachi, Aurora Health, USA.
Change 07.082 CICSTRAN variables MAXTASK and SHRTSTOR were not correct,
VMAC110 because once either condition was found in a transaction,
May 24, 1989 the rest of the transactions in that physical SMF record
were also flagged "Y", because the two variables were not
reset/initialized.
Insert two new lines 058410 and 069310:
ELSE MAXTASK=' ';
Insert two new lines 058510 and 069410:
ELSE SHRTSTOR=' ';
Thanks to Dennis Mahbubani, Aetna Casualty, USA.
Change 07.081 TYPE72MN (MVS/ESA-Only RMF Monitor III records) are all
VMAC7072 trashed because MONIDLS, MONPGIN and MOSLOT should have
May 9, 1989 all been PIB4. (this was a finger fault; the SKIP logic
expected 4-byte counters!)
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.080 These sample CICS SAS/GRAPH routines had not been updated
GRAFCICS for SAS 5.18. All GOUT= were changed to PDB.GRAFCICS and
May 9, 1989 the final data step deleted. After execution, the graphs
can be replayed with PROC GREPLAY IGOUT=PDB.GRAFCICS;
Thanks to Bill Salassi, BHP Systems, AUSTRALIA.
Change 07.079 DB2ACCT and DB2STAT0 variable QTXAPREC was decoded into a
VMACDB2 set of eight new variables: QTXABLLM QTXAIOLM QTXAINLM
May 9, 1989 QTXASALM QTXASELM and QTXASPLM for ease in reporting DB2.
Change 07.078 IBM added four undocumented bytes to the end of RMF 77
VMAC77 record in MVS 3.1.0e (and, yes, it is a lower case "e" in
May 4, 1989 the MVSLEVEL variable!). MXG did not use "skip" logic in
type 77 processing, and the TYPE77 data set is trashed.
Insert two new lines after line 018800:
018810 SKIP=LENEDSS-156;
018820 IF SKIP GT 0 THEN INPUT +SKIP @;
Thanks to Carol Rogers, K-Mart Apparel, USA.
Change 07.077 If you used %VMXGSUM with MAX= but without MIN=, wrong
VMXGSUM values were calculated. This did not affect any MXG code,
May 4, 1989 as all MXG uses of %VMXGSUM specified both MAX= and MIN=.
Delete line 031500 %LET LASTX = &NUMMIN;
Change 07.076 Landmark Monitor system record daccumulation (MONISYST)
TYPEMONI is wrong. The revised de-accumulation algorithm added in
May 4, 1989 MXG 6.6 to process concatenated files always fails. This
ONLY affects the MONISYST data, and not the MONITASK data
set. (That it took until now to be noticed suggests that
few users take advantage of the MONISYST dataset!). The
correction is to change lines 084600 thru 088900. Each
line is now of the form Hnn = Variable;
Each line must be changed to read Hnn=Variable+Hnn;
For example, after the change:
084600 H1 =CPUTCTBM+H1 ;
...
089000 H45 =WTTSIOTM+H45;
Thanks to Joe Faska, Depository Trust, USA.
Change 07.075 Processing IMS 1.3 Log data is NOT possible with the MXG
TYPEIMS1 algorithms for IMS 2.1 and IMS 2.2. These power of these
VMACIMS1 algorithms (which recognize each IMS transaction instead
May 4, 1989 of each program schedule) depend on several fields that
simply do not exist in the archaic 1.3 release:
-LINENR is not in type 35 log record
-LTERM is not in type 31O log record
-ARRVTIME is always nulls in 03P record
-DLRTOKEN only exists in the 07/08 records
The ability to recognize multiple transactions within a
program schedule is absolutely dependent on these data.
Thus MXG cannot claim to support transaction measurement
for IMS 1.3. We have restored MXG Version 5.5 IMS logic
in new members TYPEIMS1/VMACIMS1 for IMS 1.3 sites. That
code made no attempt to recognize multiple transactions
per program schedule, but instead matched IBM's DFSILTA0
results to produce one observation in IMSTRAN for each
program schedule. Since only 7 sites have requested our
IMS 1.3 processing, we can only offer this restoration.
Change 07.074 Unused change number.
Change 07.073 In TYPE26J2, TYPETASK may contain JOB0, TSU0, or STC0 as
VMAC26J2 IBM prepared for JESNR greater than 9999 in the JCTJOBID
May 4, 1989 field. This change reads only the first three bytes of
JCTJOBID into TYPETASK, but keeps its length at four to
avoid conflict with other data sets. Insert new line
013311 after 013310: TYPETASK=' '; /*4 blanks*/
In line 013400 Change $CHAR4. to $CHAR3.
In line 013500 Change +4 to +5
Thanks to Carol Harper, E G & G Idaho, USA.
Change 07.072 In TYPE90, variable DETAIL was not reset for each class
VMAC90 os SMF recording (JOB, TSU, STC). Now it is by insertion
May 4, 1989 of ELSE DETAIL=' '; after DETAIL='Y';
Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.
Change 07.071 In ROSCOE 5.6 RTM the number of complexity levels is set
TYPEROSJ by ROSCOE sysgen parameter RTMCMARK and the number of
VMACROSC time levels is sysgened by RTMTMARK. The actual number
VMACSMF of buckets in the RTM record is one less than the number
May 3, 1989 of levels. MXG expects three complexity level buckets and
five time level buckets (assumed RTMCMARK=4,RTMMARK=6).
You will encounter a STOPOVER abend if you sysgen less.
This change now uses information in the record to read in
only as many fields as exist. Many lines were changed.
An unrelated change to ROSCOE processing was also made:
member TYPEROSJ has been deleted, and the code in VMACSMF
that set OFFROSC was removed, because ROSCOE journal and
ROSCOE SMF records can be processed with member TYPEROSC
using a DDNAME of SMF for either dataset. TYPEROSJ was
only for ROSCOE 5.4 and earlier, and caused confusion.
Thanks to Art A. Brax, Jefferson Co. Colorado School District, USA.
Thanks to Sandy Recchio, Chase Lincoln First Bank, USA.
Change 07.070 This enhancement to dataset activity analysis added VSAM
ANALDSET TYPE64 records, new fields (eg. OPENTIME) from TYPE1415,
Apr 30, 1989 and enhanced the description of the job. If you want to
know which program in which job opened which file for
how long and for how much I/O, this is the place to go.
Change 07.069 This enhancement to DB2PM-like reporting adds many small
ANALDB2R changes as a result of more detailed validation with DB2
Apr 30, 1989 Version 2.1 data and report formats, and adds additional
reports. This revision now invokes %VMXGSUM to summarize
which reduced the size from 12,000 lines to only 7,150!
Change 07.068 The VTOC processing code only expected 16 extents, since
VMXGVTOC the code was written before there was VSAM. With this
Apr 30, 1989 enhancement, MXG now expects up to 128 extents to fully
support VSAM data spaces in a VTOC.
Change 07.067 The long promised MXG Tape Mount Monitor, MXGTMNT, lives!
ASMTMNT Member ASMTMNT contains the assembly source for the load
EXTMNTMN module MXGTMNT and the JCL to create the proclib member
EXTMNTSW MXGTMNT. MXGTMNT executes in its own address space and it
IMACTMNT creates an SMF record for every tape mount with the start
TYPETMNT and end timestamps, duration of the mount, and the job
VMACTMNT causing the mount. MXGTMNT also creates a record if a
Apr 30, 1989 "tape swap" occurs as the result of a permanent error.
The installation instructions for the tape mount monitor
are contained in comments at the beginning of ASMTMNT.
Please read completely before executing. Member IMACTMNT
contains the SMF record ID that you chose in ASMTMNT.
Member TYPETMNT/VMACTMNT creates two data sets from the
SMF record: TYPETMNT contains mount information and
TYPETSWP contains swap events. The monitor has been
tested under MVS/370 and MVS/XA, and should execute under
MVS/ESA as well. Members ASMTPMON and ASMTP370 have been
replaced by ASMTMNT.
Change 07.066 Exits EXPDBWEK and EXPDBMON have been added to the PDB
EXPDBMON WEEKBLD and MONTHBLD members so that users who have added
EXPDBWEK additional SMF records to BUILDPDB/3 (using the MXG Exit
MONTHBLD Facility, page 139 in the MXG Supplement) can copy those
WEEKBLD additional data sets into their MONTH and WEEK PDBs.
Apr 29, 1989
Change 07.065 DB2 Trace SMF type 102 record support has been expanded
FORMATS and further validated and revised with Release 2.1 data.
IMAC102 The subtype 106 (System Parameter) record (in T102S106)
VMAC102 was completely re-formatted by IBM in 2.1, requiring a
Apr 28, 1989 rewrite. Subtypes 67, 98, 99, 101, 112, 122, and 123
May 9, 1989 have now been tested with 2.1 data. An entire new class,
Audit (subtypes/IFCIDs 140-145) is now supported, though
only subtypes 140 and 141 were available for testing.
Logic now tests QWHSNSDA (in 2.1) or record length (1.3)
to determine the actual number of triplets, which avoided
a STOPOVER conditions. Subtype 53 and 58 were rewritten
to decode the SQLCA and to avoid STOPOVER conditions. New
macros are now defined in IMAC102 for the Audit classes.
Some subtypes that were not in their correct trace class
groups were moved to where they belong, and the subtype
to trace class documentation (in IMAC102) revised. This
was a significant change to type 102 processing for 2.1.
Note: All 120+ T102Snnn datasets are always created by
MXG, but only those "enabled" by IMAC102 will actually
have observations. However, SAS requires virtual storage
for each data set at compile time. With only a 4MB region
it was necessary to specify SAS Option BLKSIZE=8192 for
the TYPE102 program to execute.
Thanks to Stan Stoots, Virginia Power, USA.
Thanks to Stan Majka, Virginia Power, USA.
Thanks to Peter Gallinari, Reader's Digest Association, USA.
Change 07.064 CICSEXCE variables TSWAITTM,CN,MSWAITTM,CN,VSWAITTM,CN
VMAC110 were not initialized and could be carried forward into
Apr 27, 1989 a subsequent exception observation. All six variables
are now initialized to missing after line 101600.
Thanks to Dee Ramon, Mutual of America, USA.
Change 07.063 Trending RMFINTRV from PDBs built before MXG 6.6 causes
TRNDRMFI Variable Not Found condition (which cannot be solved by
Apr 27, 1989 the NOVNFERR SAS option), because of the new OTH6-OTH0
variables added in MXG 6.6 to RMFINTRV that are not in
RMFINTRV built by prior versions of MXG. If you want to
use previously built PDB librarys as input for trending
you must create 70 new lines after 014500 (one line for
each of the 14 variables in each of the 5 OTHn groups).
The 70 variable names are in lines 003900-004100 and in
lines 005700-006800. Each new line will be:
IF variable=. THEN variable=.;
For example, the first line will be:
IF OTH6ACTV=. then OTH6ACTV=.;
Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.
Change 07.062 NETSPY records caused zerodivide condition because the
VMACNSPY denominator in lines 041200 thru 041500 should have been
Apr 26, 1989 TOTRSPNO instead of TRANSNO.
Thanks to ???, KF Data, SWEDEN.
Change 07.061 TYPE74 variables AVGPNCHA, AVGPNCUB, AVGPNDEV are labeled
VMAC74 as containing milliseconds of pending time for channel,
Apr 25, 1989 control unit, and device, but erroneously are in seconds.
This change corrects the calculation so that the values
are in milliseconds and agree with the labels. In lines
039700 thru 039900, change the lines which now read:
AVGPNxxx=DURATM*PCTPNxxx/(100*SSCHSAMP);
to read:
AVGPNxxx=10*DURATM*PCTPNxxx/SSCHSAMP;
Thanks to Ron Higgins, American Honda, USA.
Change 07.060 NetView Release 2 writes "Hardware Monitor External Log
VMAC37 Record" as SMF type 37 Records and their contents are
Apr 27, 1989 described in NetView Administration Reference SC30-3361-2
(Appendix A pages 97ff). This change adds support for
three new segments (LPDA-2, LAN, and Generic Event) into
the TYPE37 data set.
Change 07.059 NetView Release 2 writes "Session Monitor External Log
VMAC39 Record" as SMF type 39 Records and their contents are
Apr 27, 1989 described in NetView Administration Reference SC30-3361-2
(Appendix A pages 163ff). This change adds support for
new subtypes 7 and 8. Subtype 7 in TYPE39_7, Init Failure
is identical to pre-existing TYPE39_6 dataset. Subtype 8
in TYPE39_8, Storage and Event contains 44 new variables.
(VM NetView also writes SMF format data to its external
file which should be processable with TYPE39, but this
has not yet verified).
Thanks to Russell Brooks, James River Corporation, USA.
Change 07.058 JES3 BUILDPD3 prints TYPE30_5 (twice!) due to debugging
BUILDPD3 code (lines 013900 and 014300) which are now deleted.
Apr 20, 1989 Two PROC CONTENTS of the PDB and WORK ddnames are deleted
(lines 059100 thru 059400) because ANALCONT provides the
same report. (Some sites did not want the contents, but
I find them worthwhile in tracing problems.)
Thanks to George Scott, Rockwell International Corporation, USA.
Change 07.057 VM/XA Monitor records have been altered by PTF VM35971
VMACVMXA and VM35321 which are now supported by MXG. VM35971 adds
Apr 20, 1989 VMDCTMIG (Pages Migrated from ESTORE to DASD), VMDCTXWT
(Pages written from main to ESTORE) and VMDCTXRD (pages
read into main from ESTORE) to the VXUSEACT and VXUSEATE
detail data sets. MXG adds the new variables to the MXG
created VXBYUSR, VXSUMUSR and VMXAINTV datasets, storing
the values as rates per second as are other paging data.
PTF VM35321 adds VMDCPUAD (CPU Address) to the VXSCLADL,
VXSCLDDL and VXSCLAEL Schedule records. This now permits
MXG to properly de-accumulate those data (prior to this
fix, the schedule data was unusable because VMDCPUAD was
needed to de-accumulate those data).
Thanks to Richard Steele, Louisville Gas and Electric, USA.
Change 07.056 TPX SMF records read directly from active VSAM data set
VMACTPX cause STOPOVER because MXG was incomplete. In line 032000
Apr 19, 1989 change TPXOFF=TPXOFF-3; to TPXOFF=TPXOFF-3+OFFSMF;
There is no problem processing TPX records from a normal
SMF dumped dataset.
Thanks to Bob Lemaster, Central Bank of the South, USA.
Change 07.055 Support for the TLMS (Tape Library Management System) CA
TYPETLMS product is added by this user contribution. The code was
Apr 19, 1989 restructured but has yet been tested with real data in
its revised form. The TLMS Catalog is read to create an
observation for each tape volume.
Thanks to Wing Louie, Chase Manhattan Bank CDC, USA.
Change 07.054 NPM Type 28 Subtype 5C (Dynamic Reconfigure Notification)
VMAC28 caused STOPOVER because DRNTNAM, Target Resource Name, is
Apr 18, 1989 not always present (this is not documented by IBM).
Insert new line 164310 after line 164300:
164310 @; IF LENTOF GE 19 THEN INPUT
to conditionally input DRNTNAM when it is actually there!
Thanks to Larry Doub, R J R, USA.
Change 07.053 DB2 Version 2.1 causes "VMACDB2 DATA. UNEXPECTED ID=100
VMACDB2 NRINSD=14 and NRIFCID=13" messages on the SAS log. This
Apr 18, 1989 is not really a problem to worry about. The NRINSD and
NRIFCID count the number of Destination Data Sections and
Instrumentation Data Sections in the record, which count
records written for the monitor, and do not relate to the
DB2 system itself. As a result, MXG kept only the first
three NRINSD destination names and only the first five
IFCIDs (see page 203 of the MXG Supplement for the list
of variables that are kept). I don't think the counters
are useful, and if they were, it should be done with an
additional data set. Until someone demonstrates a need to
use this obscure data, I have re-worded the text of the
message: "MXG KEEPS THE FIRST THREE/FIVE IFCID/INSD, BUT
YOUR DATA HAD n. THIS IS NOT USUALLY IMPORTANT". If I
knew for sure it was always 14/13 I might suppress the
note. This change also corrected some minor logic errors
in deciding when to print the message: Line 094800 should
GT 3 instead of GT 5, and -4 should be -2, and 094900 is
PIB2. instead of $CHAR4.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.052 SYNCSORT SMF records read from "active" VSAM SMF file
VMACSYNC caused STOPOVER abend (but worked fine from dumped SMF).
Apr 18, 1989 Remove +OFFSMF from line 026200.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 07.051 RMF Monitor III VSAM data sets are supported by this
EXZRB... major user contribution. (In MVS/ESA, a very small
IMACZRB part of the Monitor III data is written as a subtype
TYPEZRB of the Type 72 record and supported in TYPE72MN data
VMACZRB set introduced in MXG Version 6.6). The workload
ZRBJCL delay monitor data is far more extensive that that,
ZRBRPTn and this extensive set of code processes those VSAM
ZRBWORK RMF III data into several data set names. Although
Apr 12, 1989 the "ERB" acronym is the more appropriate name for
these data, I renamed Dick's use of ERB to ZRB as I
expect this code will be short lived as MVS/ESA takes
over in the future.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 07.050 Concatenated VM/Monitor data contained invalid values
VMACVMON for the first interval after each START event, because
Apr 12, 1989 MXG incorrectly outputted all intervals, when it was
intended to only output beginning with the second. In
all twenty occurrences of IF INTRVCNT GT 0 THEN ....
must be changed to IF INTRVCNT GT 1 THEN
Thanks to Rodney L. Reisch, General Electric Plastics, USA.
Change 07.049 The references to _CICOTHR for the ddname of the CICS
ANALCICS ACCT, EXCE, and YSTM data sets should have been changed
Apr 11, 1989 to _CICACCT.CICSACCT, _CICEXCE.CICSEXCE and
_CICYSTM.CICSYSTM to be consistent with IMACCICS.
Thanks to Mark Hutchinson, Atlantic States Bank, USA.
Change 07.048 IMS Log Record decoding corrections.
VMACIMS a.After 024700 (the @; after DEST $CHAR8.), insert line
Apr 9, 1989 IF _IMSVERS GE 2.2 THEN INPUT MSGIHSQN $CHAR8. @;
IMS 2.2 added this eight byte field and MXG missed it.
Without the fix, IMS 2.2 abended with STOPOVER (though
several IMS sites looked at the hex dumps, inserted an
+8 before the SIZELU6 variable to align and circumvent!)
b.Change 027400 from LOC=MSGPRFLL; to LOC=MSGPRFLL-3;
so that MSGXDLEN is correctly read in and used for the
MSGLEN, MSGSZIN, and MSGSZOUT variables.
c.Both references to unused unkept COMMFLAG were deleted.
d.Insert after line 043500 (between DLRTOKEN and PSTTSKID
@; IF _IMSVERS GE 2.1 THEN INPUT
e.Insert after line 056010 (between MSGDRRN and DLRTOKEN
@; IF _IMSVERS GE 2.1 THEN INPUT
Items d. and e. prevent STOPOVER with IMS 1.3 data.
f.Any time stamp was set missing if PTIME was exactly zero
(midnight). The PTIME/PDATE INPUT statement uses the ??
syntax (suppresses hex dump and error message and makes
value missing for invalid PD. data). Thus PTIME could be
zero, causing MXG to not calculate a datetime variable.
All statements testing PTIME GT 0 were changed to test
PTIME GT . (missing value).
g.Log type 35x records were not always output, causing the
ENQTIME to be missing which caused an out-of-sort-order
failure to merge ENQTIME with other transaction records.
Heuristic logic testing ENQFLAG and FLAG2 bits determine
if a 35x record is for input, output, message-switch, or
program-to-program, brute-force determined by finding a
combination, then looking at a detail trace to determine
the proper IMS35x data set to output. Values previously
unseen were skipped and not output. Now, unknown values
are printed on the SAS log. (If you should encounter a
new combination, call and we'll discuss how you can dump
the IMS log records to figure out which IMS35x dataset it
should be put in - I sure wish there were a better way!)
This change restructured logic in IMACIMS to remove the
RETURN statements and replaced IF's with ELSE IF's.
Thanks to Harry Olschewski, DVG Kiel, GERMANY.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.047 RACF Auditor reports from SMF type 80 record exposures.
ANALAUDT 1.In member ANALAUDT, references to _RACF must be changed
FORMATS to _AUDT (which sets the DDNAME containing your TYPE80
Apr 9, 1989 data set, defined in IMACANAL).
2.The remainder of this change corrects only the values of
variables ALLOW and INTENT in SUF/INSUF Auth. reports.
There is no other impact if you do not put this fix on.
This report decoded ALLOW and INTENT from the wrong byte
of RACFDATA, in a block of code in the wrong location,
and were not RETAINed for multi-observation RACF events!
a.ANALAUDT changes:
-Add ALLOW INTENT to RETAIN at line 009400.
-Block COPY lines 016300 thru 018100 (from /* RESOURCE
to associated END;) TO AFTER line 012500. In the new
block you copied:
-Add OR RACFQUAL=200 after RACFQUAL=201
-Change both tests for RACFDLN GE 3 to RACFDLN GE 1
-Change SUBSTR(RACFDATA,3,1) to SUBSTR(RACFDATA,1,1)
in ten statements within this copied block.
-Delete the statement OUTPUT INSUF;
-Now, go back to lines 016300 thru 018100, delete the
entire block, and replace it with these two lines:
016400 IF RACFQUAL=201 THEN OUTPUT INSUF;
016500 IF RACFQUAL=200 THEN OUTPUT SUF;
b.Additional cosmetic changes made for next Version that
are truly optional for now:
-In ANALAUDT, after RETAIN at line 009400 new line:
FORMAT ALLOW INTENT MG080AI.;
-In FORMATS, after MG080EV definition, add new format:
VALUE MG080AI
0='0:ALTER'
1='1:CONTROL'
2='2:UPDATE'
3='3:READ'
4='4:NONE'
;
c.One additional change, but only for users of the FACOM
operating systems type 80 records. Format MG080QU has a
slightly different meaning for four values, which are
changed in member FORMATS (after VALUE MG080QU) to now
describe either IBM or FACOM type 80 records:
101:INVALID PASSWORD (FACOM: OR GROUP)
102:INVALID GROUP (FACOM:UIDCARD)
103:INVALID OIDCARD (FACOM:TERMINAL)
104:INVALID TERMINAL (FACOM:APPLICATION)
Thanks to Ingrid Ahmer of Australian National, AUSTRALIA.
(railways), who sent an excellent discussion and fix for the code
relocation logic.
Thanks to Thomas Peiper, KommunData, SWEDEN.
Change 07.046 MVS Step Accounting fields were decoded in MXG TYPE30_4
IMACACCT variables ACCOUNTn, but BUILDPDB/3 does not carry these
IMACPDB STEP accounting fields into PDB.STEP. Instead, the JOB
VMAC30 accounting variables ACCOUNTn from the TYPE30_1 (Init)
Apr 30, 1989 or TYPE30_5 (Job termination) records are used through
out BUILDPDB/3 logic, which is what almost every site
really wants. Step level accounting really does not work:
you can't tell which step caused which PDB.PRINT data;
which account do you use in PDB.JOBS if different fields
are used on different steps, etc. However, IBM does not
provide a mechanism for putting job-level account fields
in type 30_1 or type3-_5 records for Started Tasks (STC).
This change creates additional variables SACCTn in both
TYPE30_V (interval) and TYPE30_4 (step) records, and the
SACCTn variables are now added to PDB.STEPS. Please NOTE
that PDB.JOBS is unchanged; ACCOUNTn variables for STCs
will still contain blanks. Further design considerations
of BUILDPDB logic is required before step account fields
could replace blank job accounting fields in PDB.JOBS.
1.Member VMAC30
SACCT1-SACCT9 was added to KEEP of TYPE30_4 and TYPE30_V
2.Member IMACACCT
SACCT1-SACCT9 were added. IMACACCT is usually modified as
described on page 311 of the MXG Guide; changes made to
the number and length of ACCOUNTn variables must also now
be made to the SACCTn variables.
3.Member IMACPDB:
SACCT1-SACCT3 added to the MACRO _PDB30_4 list of which
TYPE30_4 variables will be carried into PDB.STEPS. (MXG
defaults to 3 ACCOUNT and now 3 SACCT variables).
Thanks to Michel Leveille, CTTL, USA.
Change 07.045 MXG Programs can be executed through JCL with either an
JCLPDB explicit DD DSN=MXG.SOURCLIB(XXXXXXXX) member name in the
JCLTREND JCL, or by a //SYSIN DD * JCL statement followed by SAS
PDBTREND %INCLUDE SOURCLIB(XXXXXXXX); statements. MXG members that
Apr 9, 1989 contain JCL were inconsistent, some used member name and
some used %INCLUDE.
1. In favor of member name:
a. There was a historical limitation when JES could not
submit a job from a job if the submitted job contained a
SYSIN DD * JCL statement. The submitted job would simply
not execute. Making the DD * statements a member of a PDS
and then using only member name DD statements solved the
problem. (This still is occasionally encountered at some
sites and/or levels of JES - anyone know why/when/what?)
b. JCL is easier to comment out than SAS. JCL needs only a
asterisk in col 3 of the DD statement. SAS usually needs:
an INSERT character to make room for the leading /*,
typing of the /* delimiter before the statement,
a long shift cursor to the end of the statement,
typing of the */ delimiter after the statement,
(and only if you did not first have to cursor right, char
delete to make room in the line buffer!)
c. Production jobs which failed could be re-submitted in one
step by editing the JCL member, commenting out the member
names that had successfully completed and submitted to
run from that point.
2. In favor of %INCLUDE.
a. The MXG Exit Facility. You need the ability to change any
MXG program in your USERID.SOURCLIB, and the use of JCL
member name prevents you from making effective use of the
Exit Facility. Items b. and c. above were encountered at
State Farm and Sun, before there was an Exit Facility!
3. The conclusion. MXG will now use only %INCLUDE statements
in JCL examples. Furthermore, all %INCLUDE statements in
JCL examples will be precedeed by five blanks to make any
editing easier (as long as I don't forget to do so).
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.044 IDMS Performance Monitor SMF record processing did not
VMACIDMS retain TASBFLDS and TASNDBLV in the IDMSTAS data set. Add
Apr 9, 1989 TASBFLDS to the RETAIN statement (line 130300) and change
the 2nd occurrence of TASMXRBB line 131000 to TASNDBLV.
Variable TASTTYPE in IDMSTAS identifies the type of task
(DC Task, CICS ERU, Batch ERU, or TPMON ERU) and several
variables only apply to specific task types. MXG did not
initialize these variables, and because these variables
must be retained (the IDMSTAS record is segmented into
256 byte pieces because of the 256 byte IDMS Journal),
the "other" variables will have retained values from a
prior IDMSTAS observation. As long as you use TASTTYPE
you should not have a problem, but the real fix inserted
25 lines after 123300 to initialize the retained values:
SKIP=SKIP-40; 123300
TASTSKCD =' '; 123310
TASPGMNM =' '; 123320
TASLTEID =' '; 123330
TASPTEID =' '; 123340
TASUSER =' '; 123350
TASPGDBN =' '; 123360
TASPGNOD =' '; 123370
TASLDLST =' '; 123380
TASAMNAM =' '; 123390
TASFACCD =' '; 123391
TASCTI =' '; 123392
TASCPGNM =' '; 123393
TASCTETI =' '; 123394
TASCLID1 =' '; 123395
TASCLID2 =' '; 123396
TASCTEOI =' '; 123397
TASCJBNM =' '; 123398
TASBJBNM =' '; 123399
TASBPGNM =' '; 123400
TASBNFLD =.; 123401
TASBBALN =.; 123402
TASBFLDS =' '; 123403
TASTPGNM =' '; 123404
TASTLID1 =' '; 123405
TASTLID2 =' '; 123406
IF TASTTYPE='1.......'B THEN DO; /*ONLINE - DC TASK */123410
Thanks to Randy Springs, Glidden Paint, USA.
Change 07.043 VM/370 Account records contain blanks (rather than hex
TYPEVM zeros) for the VECVMTM and VECVIRTM vector CPU fields.
Apr 9, 1989 (Four bytes of blanks input as PIB4.3 is 1,077,952.576!)
Lines inserted after 036900 to conditionally input:
036910 @;
036920 INPUT @65 TSTCHAR1 $CHAR4.
036930 @69 TSTCHAR2 $CHAR4.
036940 @;
036950 IF TSTCHAR1 NE ' ' AND TSTCHAR2 NE ' '
THEN INPUT
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.042 NPM Type 28 SMF record subtype 60x,61x, and 62x were not
VMAC28 output. Expand the test at line 200300 to include those
Apr 9, 1989 three values of NPMSUBTY (and change comment in 200400
for EX028IN8 to read for NPMINNSA vice NPMINPMT).
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.041 Variables QTXAFLG1, QTXAIRLM, and QWHCOPID were not kept
VMACDB2 in DB2ACCT keep list, but will be needed in DB2PM-like
Apr 9, 1989 reports for DB2 Version 2.1. They are now kept.
Change 07.040 Support for Tape Management System (TMS) Catalog records
ANALTMS5 (tape volume sizes, last use, etc.) is now upgraded from
TYPETMS "X-rated (i.e, extra but not supported member) XMACUCC1"
VMACTMS5 to these members. There may be additional logic added
Apr 8, 1989 after further testing. See comments in TYPETMS.
Thanks to Joe Faska, Depository Trust, USA.
Change 07.039 The subtype 3 (Storage) type 22 SMF record (seldom if
VMAC22 ever needed) fails with MVS/370 and old MVS/XA because
Apr 7, 1989 NRPAGES may not exist and LOWADDR may be 2 or 4 bytes.
Change lines 046100 to 046300 to read:
046100 IF LENGTH-COL EQ 1 THEN INPUT LOWADDR PIB2. @;
046200 ELSE IF LENGTH-COL GE 3 THEN INPUT LOWADDR PIB4. @;
046300 ELSE IF LENGTH-COL GE 7 THEN INPUT LOWADDR PIB4.
NRPAGES PIB4. @;
Thanks to Dana Yam, Washington University, USA.
Change 07.038 These five members are one possible circumvention for a
XMAC7072 "SAS Error 344 - Compiler Limit Exceeded" condition in
XMAC71 executing BUILDPDB/3. By copying these five members to
XMAC73 your USERID.SOURCLIB library and renaming them to their
XMAC74 corresponding VMAC.... name, the number of interative
XMAC75 "DO" statements is reduced, and BUILDPDB might be able
Apr 5, 1989 to compile successfully. (The ultimate fix will be SAS
Version 6 on the mainframe, which eliminates the limit in
their compiler.) These members reduce the number of "DO"s
by processing only MVS/XA and MVS/ESA RMF records, but
depending on which additional SMF processing members you
have added to BUILDPDB/3, even with this circumvention in
place, you might still exceed the compiler limit.
An alternate circumvention which completely avoids any
exposure, and is only slightly more complicated, is to
use the IMACFILE exit to write the newly wanted SMF data
records to a temporary SMFOUT file, which is then passed
to an additional step in your BUILDPDB/3 job, which then
creates the additional data sets and copies them into the
PDB ddname. In this way you will still only read your SMF
dataset once, and by good choices of which records are in
this temporary data set versus which records you process
in BUILDPDB/3, you can keep the temporary data set small.
The XMAC7... members on Version 6.6 were unfortunately
not built correctly, and created different exposures. If
you need to use these five XMAC7... members to attempt to
avoid the compiler limit, you will need to recreate them
their corresponding VMAC.... member, replace the MVS/370
processing lines with the indicated "Initialization IF"
statements so they end up as shown below:
XMAC7072:
Replace lines 043900 thru 085000 to be:
043900 IF (ID=70 OR ID=72) AND NOT MVSXA THEN DO;
044000 IF SUPATERN=' ' THEN SUPATERN=' ';
085000 END; /* TYPE 70, 72 RECORD FOR NON-MVSXA */
XMAC71:
Replace lines 031500 thru 046100 to be:
031500 IF ID=71 AND NOT MVSXA THEN DO;
031600 IF FRAMES =. THEN FRAMES =.;
031700 IF LPSWRCLM=. THEN LPSWRCLM=.;
031800 IF PVTMVCLC=. THEN PVTMVCLC=.;
031900 IF PVTMVDWN=. THEN PVTMVDWN=.;
032000 IF PVTMVUP0=. THEN PVTMVUP0=.;
032100 IF PVTMVUP1=. THEN PVTMVUP1=.;
046100 END; /* MVS/370 TYPE 71 RECORD */
XMAC73:
Replace lines 012700 thru 002270 to be:
012700 IF ID=73 AND NOT MVSXA THEN DO;
012800 IF AVGENQUE=. THEN AVGENQUE=.;
012900 IF CHANMAP0=. THEN CHANMAP0=.;
013000 IF CHANMAP1=. THEN CHANMAP1=.;
013100 IF C0ANYCH =. THEN C0ANYCH =.;
013200 IF C0BYWT =. THEN C0BYWT =.;
013300 IF C1ANYCH =. THEN C1ANYCH =.;
013400 IF C1BYWT =. THEN C1BYWT =.;
013500 IF DEFCUBY =. THEN DEFCUBY =.;
013600 IF DEFDEVBY=. THEN DEFDEVBY=.;
013700 IF DEFERED =. THEN DEFERED =.;
013800 IF DEFLCHBY=. THEN DEFLCHBY=.;
013900 IF DEFPHYBY=. THEN DEFPHYBY=.;
014000 IF FQCUBY =. THEN FQCUBY =.;
014100 IF FQDEVBY =. THEN FQDEVBY =.;
014200 IF FQLCHRQ =. THEN FQLCHRQ =.;
014300 IF FQPHYRQ =. THEN FQPHYRQ =.;
014400 IF LCHAN =. THEN LCHAN =.;
014500 IF LCI =. THEN LCI =.;
014600 IF PCTDEFCU=. THEN PCTDEFCU=.;
014700 IF PCTDEFDV=. THEN PCTDEFDV=.;
014800 IF PCTDEFER=. THEN PCTDEFER=.;
014900 IF PCTDEFLC=. THEN PCTDEFLC=.;
015000 IF PCTDEFPY=. THEN PCTDEFPY=.;
015100 IF QUEUE0 =. THEN QUEUE0 =.;
015200 IF QUEUE1 =. THEN QUEUE1 =.;
015300 IF QUEUE2 =. THEN QUEUE2 =.;
015400 IF QUEUE3 =. THEN QUEUE3 =.;
015500 IF QUEUE4 =. THEN QUEUE4 =.;
015600 IF SIO73CNT=. THEN SIO73CNT=.;
015700 IF AVGPHYNQ=. THEN AVGPHYNQ=.;
015800 IF CPUID =. THEN CPUID =.;
015900 IF PCHANWT =. THEN PCHANWT =.;
016000 IF IDWRONG=' ' THEN IDWRONG=' ';
022700 END; /* MVS/370 TYPE 73 RECORD */
XMAC74:
Replace lines 012800 thru 002380 to be:
012800 IF ID=74 AND NOT MVSXA THEN DO;
012900 IF CUBUSY =. THEN CUBUSY =.;
013000 IF DEFERCUB=. THEN DEFERCUB=.;
013100 IF DEFERED =. THEN DEFERED =.;
013200 IF DEFERSVD=. THEN DEFERSVD=.;
013300 IF DEVBUSY =. THEN DEVBUSY =.;
013400 IF LCHAN =. THEN LCHAN =.;
013500 IF PCTDEFCU=. THEN PCTDEFCU=.;
013600 IF PCTDEFER=. THEN PCTDEFER=.;
013700 IF PCTDEFRS=. THEN PCTDEFRS=.;
013800 IF PCTQUEDV=. THEN PCTQUEDV=.;
013900 IF PCTQUEPA=. THEN PCTQUEPA=.;
014000 IF QUEUE0= . THEN QUEUE0 =.;
014100 IF QUEUE1= . THEN QUEUE1 =.;
014200 IF QUEUE2= . THEN QUEUE2 =.;
014300 IF QUEUE3= . THEN QUEUE3 =.;
014400 IF QUEUE4= . THEN QUEUE4 =.;
014500 IF UNITADR= . THEN UNITADR =.;
023800 END; /* MVS/370 TYPE 74 RECORD */
XMAC75:
Replace lines 006500 thru 012000 to be:
006500 IF ID=75 AND NOT MVSXA THEN DO;
012000 END; /* MVS/370 TYPE 75 RECORD */
Thanks to Larry Cecil, First National Bank of Chicago, USA.
Change 07.037 Version 6.6 added variable PRENTIME to PDB.PRINT and its
BUILDPDB BY-list, but the change was incomplete and needed to be
BUILDPD3 fixed (see Change 7.006) and documented (Change 7.036).
Apr 3, 1989 Another exposure to incorrect sort order was seen and is
fixed by this change. The exposure only exists on the
very first run of the new BUILDPDB when PRENTIME does not
yet exist in SPIN library, and only if the same job had
multiple print files with exactly the same PRINTIME on
different devices with one record in SPIN and one record
in today's SMF, AND only if the device names are not in
ascending alphabetical sequence! No one has reported the
exposure, but once noted, it was fixed by this change.
References to JPURTIME in this change fix another first
time exposure induced by Change 7.008, and make JES3
purge records sort order consistent with JES2.
Changes made to both BUILDPDB and BUILDPD3:
BUILDPDB BUILDPD3
018800 019200 LENGTH DEFAULT=4 READTIME PRINTIME PRENTIME 8;
019310 019710 IF PRENTIME=. THEN PRENTIME=.;
019320 019720 IF OUTDEVCE=' ' THEN OUTDEVCE=' ';
019330 019720 IF SYSPRN =' ' THEN SYSPRN =' ';
019410 019810 SYSTEM=SYSPRN;
020110 020510 IF JPURTIME=. THEN JPURTIME=.;
n/a 023900 BY READTIME JOB JESNR JPURTIME;
022900 023300 BY READTIME JOB JESNR PRINTIME PRENTIME OUTDEVCE
SYSTEM;
Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 07.036 Implementation Considerations for WEEKBLD/MONTHBLD.
WEEKBLD Changes to MXG Software can usually be implemented at any
MONTHBLD time. A powerful feature of the SAS system is its ability
Apr 3, 1989 to add variables to existing datasets and to create new
datasets automatically. To further ease implementation,
MXG logic uses SAS options "NOVNFERR" and "NODSNFERR" to
avoid "variable not found" and "dataset not found" errors
whenever approriate. Unfortunately, the NOVNFERR option
does not work if the variable is in a BY-list. Thus when
Version 6.6 added variable PRENTIME to PDB.PRINT dataset,
we failed to document all that you might have to do to
avoid a "variable not found" or "data set is not sorted"
error in WEEKBLD or MONTHBLD. This is that documentation:
If you implement the new BUILDPDB/3 code on Monday after
you have built your weekly PDB, you will avoid any change
to WEEKBLD, since all of the new daily PDBs will contain
PRENTIME and will be correctly sorted.
If you must implement the new BUILDPDB/3 in the middle of
a week, you must modify WEEKBLD by inserting new line:
003110 PROC SORT;
(between the SET MON.PRINT ... SUN.PRINT; statement and
the BY ... statement). This will create the WEEK.PRINT
by concatenating all seven dailies in unsorted order, but
now WEEK.PRINT will contain PRENTIME (since at least one
of the seven dailies was built with MXG 6.6 code). Then,
WEEK.PRINT is sorted by the original BY list. The only
cost of this modification is the double processing of the
WEEK.PRINT dataset.
You MUST modify MONTHBLD since at least one prior weekly
PDB will have been built before the 6.6 BUILDPDB. You
must remove "PRENTIME OUTDEVCE SYSTEM" from the end of
the MACRO _BYLIST definition for the MONTH.PRINT dataset
in line 016001. As soon as all input datasets used by
WEEKBLD/MONTHBLD have been built with the new version of
MXG, you can remove the modified members from your USERID
SOURCLIB or MXG.CHANGLIB libraries and use the unmodified
MXG code.
Page 263 of the MXG Supplement documented the sort order
of the PDB.PRINT data set, and should now read:
BY READTIME JOB JESNR PRINTIME PRENTIME OUTDEVCE SYSTEM.
Thanks to Bill Salassi, BHP Petroleum, AUSTRALIA.
========Changes thru 7.035 were printed in NEWSLETTER FOURTEEN==========
Change 07.035 If you used the new member IMAC30IO to remove variable
IMAC30IO D3330DRV from the _IO30DR macro defined therein, and you
IMACPDB did NOT also change member IMACPDB to adjust the dummy
Mar 15, 1989 X1-X9 variables, your PDB.JOBS data set contains wrong
values for ALL numeric values in the _SUMSTP macro that
is defined in IMACPDB. The documentation in IMAC30IO was
grossly inadequate, because it did not tell you to read
the instructions in lines 020000-023900 in IMACPDB. This
error affects ONLY the PDB.JOBS data set. Any TYPE30 data
sets and the PDB.STEPS were built correctly, even if you
removed D3330DRV. Also, removing other variables from the
other two macros (_IO30EX and _IO30TM) in IMAC30IO would
not cause any error.
FIX: The simple fix is to simply leave variable D3330DRV in
the MACRO _IO30DR definition in IMAC30IO.
If you really are concerned about the extra four bytes
and do want to delete D3330DRV from your PDB.JOBS and
PDB.STEPS data, you can remove D3330DRV from the MACRO
_IO30DR definition in IMAC30IO, but you must then change
IMACPDB:
a) Line 024400, change DROP=X1-X9 to DROP=X1-X8
b) Line 024700, remove X9 from the SUM= list
Thanks to Trevor Holland, AUSTRALIA.
Thanks to Richard Evans, Mervyn's, USA.
Comments expanded April 9, 1989:
And even if you do delete D3330DRV as described above,
you will still find an UNINITIALIZED value note because
BUILDPDB/3 still have D3330DRV in two length statements
where it should have been changed to _MAXSTP:
BUILDPDB BUILDPD3
051600 051900 change D3330DRV to _MAXSTP
055300 056100 " " "
Thanks to Lucy Fukishima, California Health & Welfare Agency, USA.
Change 07.034 The FMXGUCBL function to dynamically allocate all DASD
FMXGUCBL devices may attempt to allocate a printer device. This is
FMXGUCBL a soft error condition. It turns out that the FMXGUCB7
Mar 15, 1989 function (provided because FMXGUCBL was thought to be an
MVS/XA-only function) actually uses an MVS/XA facility
that was retro-fitted into MVS/370. FMXGUCB7 not only is
usable under MVS/XA, it does not try to allocate printer
devices! This change replaces FMXGUCBL member with the
contents of FMXGUCB7, changes FMXGUCB7 therein to read
FMXGUCBL, and deleted member FMXGUCB7.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 07.033 The VTOC processing example in member TYPEVTOC should use
TYPEVTOC %VMXGVTOC instead of the erroneous %_MXGVTOC, and comment
TYPEVTOC refering to member VMACVTOC should have been VMXGVTOC.
Mar 15, 1989 Member VMACVTOC was replaced by VMXGVTOC and now VMACVTOC
has been deleted to avoid the confusion.
Thanks to Chun-Heng Liu, Brooklyn Union Gas, USA.
Change 07.032 MVS/ESA-only variables for SQA, LPA, CSA, LSQA, and REGS
VMAC71 frames in CS (Central Storage, formerly Real Storage) and
Mar 15, 1989 in ES (Expanded Storage, formerly Extended Storage) are
missing. The test in these lines should have been:
083000 IF VERSNRMF GE 410 AND LENPGDS GE 504 THEN DO;
085600 IF VERSNRMF GE 410 AND LENPGDS GE 536 THEN DO;
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.031 RMF Monitor III variables in Subtype 2 SMF Type 72 record
VMAC7072 (MVS 3.1.0e only) WSETACT WSETIDL WSETDIV WSETFIX WSETASM
Mar 15, 1989 need zero divide protection in lines 165794 thru 165810:
IF denominator GT 0 THEN WSETACT = numerator/denominat
ELSE WSETACT=.;
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.030 In member ASUMCICS the label in line 009100 for variable
ASUMCICS RESPBKT6 should be 8 SEC instead of 6 SEC. Additionally,
VMXGSUM in member VMXGSUM the example in comments for "min, max,
Mar 15, 1989 and sum" actually calculated mean, max and sum (and also
misspelled statistics).
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.029 An unexpected limitation of CMS SAS (although it is noted
new macros in a documentation footnote): new style %MACRO names are
Mar 9, 1989 limited to seven position names! Current MXG %MACROs that
are now eight-characters long: ANALDB2R ANALDMON ANALNSPY
GRAFRMFI GRAFTRND IBM3287F PCONLINE VMXGGOPT and ZETAFOIL
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.028 Value tested for RECFM=VM should have been (line 003200):
VMACRCFM 003200 ELSE IF RECFMT='0100001.'B THEN RECFM='VM ';
Mar 9, 1989
Thanks to Mr. Rathfelder, Taylorix, GERMANY.
Change 07.027 Beginning and ending times of DB2 reports were taken from
ANALDB2R SMF timestamp and not the actual interval, causing loss
Mar 9, 1989 of first interval.
Line 089300 Change VAR SMFTIME; to VAR QWHSSTCK DURATM;
Line 089400 Change MIN=MINSMF MAX=MAXSMF; to
MIN=MINSMF MAX=MAXSMF SUM=X1 DURATM;
Thanks to Jan van Lent, Fokker, NETHERLANDS.
Change 07.026 DOS/VSE POWER records have again (incompatibly) changed
IMACDOS the location of the RECID and the OFFSET that need to be
Apr 26, 1989 set in IMACDOS. IMACDOS now defaults to DOS 2.1.7.
VSE Version OFFSET value RECID @xx value
3.1.2 0 @43
2.1.7 8 @51
2.1.3 16 @59
Earlier 0 @43
Note that processing DOS data usually requires the JCL
LABEL parameter of (,NL) or (,LTM).
Thanks to Bill Sikora, EDS Auburn Hills Mi, USA.
Thanks to Barry Debenham, Cigna Services, ENGLAND.
Change 07.025 Cache DASD SMF record variables RWRATIO and READHR could
VMACACHE be non-zero even though there was no activity to a device
Mar 9, 1989 because they were not reset missing from the prior device
segment in the same record. Insert two new lines:
051410 ELSE RWRATIO=.;
051510 ELSE READHR=.;
to reset when the denominators are zero.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 07.024 IDMS 10.2 Performance Monitor data written to Journal and
TYPEIDMJ not to SMF was not correctly handled. There is a header
Mar 9, 1989 of 20 bytes when data is written to the IDMS journal that
is not in the SMF format data. Change to read
001100 INPUT +20 PMSTYPE PIB1.
(and make sure IMACIDMS was updated with the same value
set by #PMOPT RECID= in your IDMS gen.)
Thanks to Mike Eisenhart, York International, USA.
Change 07.023 The PROC DATASETS NOLIST; DELETE DUMMY. _DSET; in the old
MONTHBLD definition of _MNTHBLD is not acceptable to SAS. The full
Mar 8, 1989 dataset name is not supported in the DELETE statement. In
place, and also at the end of the new definition which
follows the old definition, the correct syntax added is:
PROC DATASETS DDNAME=DUMMY NOLIST; DELETE _DSET:
All this simply keeps the DUMMY library at minimum size.
Thanks to Pat Stockel, New Jersey Educational Computing Network, USA.
Change 07.022 Reading SMF data with the CMS version of SAS will cause a
VMACSMF DMSSOP0363 Code 04 OPEN error. The CMS Version of SAS is
Mar 8, 1989 limited by IBM's CMS OS Simulation code, which does NOT
support LRECL=32760, even though SMF records can contain
a real LRECL of 32760. MXG Version 6.6 did change the
LRECL value in _SMF macro in VMACSMF from 32756 to 32760
precisely because we encountered STOPOVER abends when SMF
data with real LRECL=32760 was encountered. If you must
process your SMF data under CMS SAS, you will need to
change the LRECL in the _SMF macro to 32756, and try it.
If the actual SMF data contains records actually 32760
bytes LRECL, you will STOPOVER abend, but if there are
no records that long you will be home free. If you do
have actual LRECL=32760 physical records, there may be
no immediate solution, but please call. (The IBM limit
is described on page 172 of SC19-6209 for VB and VBS
support under CMS Release 4). I have an open problem
with IBM on this IBM limitation.
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.021 Sample CMS REXX EXEC for testing of MXG had the wrong
REXXTEST name for the FILEDEF in line 000523. Change MONWRITE to
Mar 7, 1989 MWINPUT (and also in line 000524 change DIKS to DISK).
Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.020 CICS sample reports for AMXT and CMXT task delays could
ANALCICS require lots of work space because all CICSTRAN variables
Mar 7, 1989 were kept. This change keeps only the needed variables.
Remove semicolon from line 043300 and insert new line:
043310 (KEEP=APPLID TERMINAL STRTTIME ENDTIME TRANNAME);
Thanks to Janet Davis, Anchor Systems, USA.
Change 07.019 IBM documents SMF type 30 triplets (offset,length,number)
VMAC30 as present if "number" is non-zero, but one site found a
Feb 20, 1989 record with length=0 and non-zero offset and number. (In
addition, the offset put this section in the middle of
the EXCP section!) Though this is probably an APARable
IBM problem, it caused MXG a STOPOVER abend. As a result,
MXG added a nonzero length test to each test for offset
and number, and then compares the record length to the
offset+(length*number)-1 to protect MXG from yet another
potential IBM data error. Whenever a bad triplet is found
MXG prints an error message on the log, then deletes the
bad record and continues processing the SMF data.
Added Apr 5, 1989: ACCT section variable NRACCT does NOT
count the number of sections of length LENACCT, instead
NRACCT is the count of accounting fields within the one
account segment of length LENACCT. Test for ACCT is thus
offset+length-1.
Thanks to John Brown, Performance Systems Incorporated, USA.
Change 07.018 The variable DEVICE for a Channel-to-channel adapter
VMACUCB was OTHER. This minor change now sets DEVICE='CTC'.
Feb 15, 1989 Add new line
004110 ELSE IF DEVCLASS=41X THEN DEVICE='CTC';
Thanks to Bill Mullen, BGS, USA.
Thanks to Rodney L. Reisch, General Electric Plastics, USA.
Change 07.017 Type 80 SMF records for RACF Version 1 Releases 8.1 and
FORMATS 8.2 were already supported by MXG 6.6! There is only one
VMAC80 new flag field and three new values of RACFQUAL (204-206,
Feb 15, 1989 whose meaning can easily be deduced from Table 1 in the
Appendix 10 of SC28-1343-4) added by RACF 1.8, and none
are significant. This change creates variable RACFRE2
and adds three values to the MXG MG080QU. format.
Change 07.016 This VM/370 HPO-only change affects user class variables
VMACVMON DRPCANUS, DRPPOPUS, and RPCUMUS in VMONUSRD and VMONUSRS
Mar 8, 1989 and their values in VMONPERF. DRPCANUS and DRPPOPUS were
never de-accumulated and have always been wrong. In VM
HPO (version 4.2 and version 5, although documented only
for version 5) the user class record was incompatibly
changed by IBM, affecting the other user class variables
input after DRPPOPUS. This should be low impact for most
VM/370 HPO sites (unless, of course, you need the data!).
a.This part supports the incompatible changes documented in
Release 5 HPO, which have also been found (almost exact,
missing only the new VMACNT field) in HPO 4.2 data.
I don't yet know the PTF which made the 4.2 changes.
Move line 246700 to after 248600
Change line 246800 GE to EQ
Replicate lines 246800 to 248100
Change line 248110 EQ 178 to GE 192
Copy 246200 to 246500 after 248110
Change 248111 from PIB4. to PIB8.
Remove @133 @135 @137 from 248112 thru 248114
Change @139 PPSTSWUS PIB2. (line 248120) to
@145 PPSTSWUS PIB4.
Change line 248130 from PPSTPPUS PIB2. to PPSTPPUS PIB4.
b.This part applies to both HPO releases and corrects the
DPRCANUS and DRPPOPUS variables (and eliminates their
meaningless average and maximum value variables DRP...AV
and DRP...MX).
New Lines:
315910 DRPCANUS=DIF(DRPCANUS);
315920 DRPPOPUS=DIF(DPRPOPUS);
319910 IF . LT DRPCANUS LT 0 THEN LOGON=1;
319920 IF . LT DRPPOPUS LT 0 THEN LOGON=1;
322810 DRPCANUS=.;
322820 DRPPOPUS=.;
Line 328700 (follows /*AVG), DRPCANUS DRPPOPUS. This line
must be moved immediately following 329400 (DEFRQ).
Line 330800 change X12 to X10.
Lines 331000 and 331200, remove DRPCANAV DRPPOPAV.
Line 331500 remove X11 X12.
Line 331800 add DRPCANUS DRPPOPUS after DEFRQ.
Lines 333900 thru 334200 (Labels for DRP...), delete.
Line 338100 remove DRPCANAV DRPCANMX DRPPOPAV DRPPOPMX
Thanks to Ron Roberts, The Equitable Life Assurance Society, USA.
Change 07.015 This new member will be incomplete in your source library
ANALALL even though the complete member is on the source tape!
Feb 15, 1989 The member (to read SMF and print all records from a job)
contains IEBUPDTE ./ control cards, which were processed
(unexpectedly) by IEBUPDTE in creating your MXG.SOURCLIB!
Had you looked at the IEBUPDTE log, you would have seen a
IEB816I message for ANALALL, followed by three IEB816I
messages for IMACJBCK, IMAC30DD, and IMACINTV which were
actually part of ANALALL! (Later in the log you would see
the real IMACJBCK,IMAC30DD,IMACINTV create with IEB817I.)
To create the ANALALL member, copy the source tape to a
sequential dataset on disk (IEBGENER,FB,80,6160), with
SPACE=CYL(1) and DISP=(,CATLG,CATLG). The job will ABEND
with B37, but the one cylinder data set will contain the
ANALALL member. Then use your editor to block copy the
lines between ./ ADD NAME=ANALALL & ./ ADD NAME=ANALAUDT.
I have changed the "./" to "XY" and added comments to
change them back to avoid the problem in the future.
Change 07.014 The Assembler parameters OJB/OBJECT and SYSLIN/SYSGO may
EXITMONI be different for different levels of ASM. Assembler XF
Feb 15, 1989 (IFOX00) used SYSGO and OBJ. Early Assembler H (IEV90)
required SYSLIN and OBJECT, and if OBJ was used, NOOBJECT
was set (with no condition code) and no object deck was
created, causing the LINKEDIT step to fail. An old PTF
(PP29236) to ASM H allows either OBJECT or OBJ (probably
as a result of ASM XF user complaints), even though only
OBJECT is actually documented for ASM H. This change is
for info only, and was revised after Newsletter FOURTEEN.
Thanks to John McAlpine, CSX, USA.
Thanks to Bob Rutledge, CSX, USA.
Change 07.013 This is an interesting problem. Three separate STOPOVER
VMACVMON abends were encountered on three different VM/SP records
Feb 15, 1989 that were shorter than expected. The culprit turned out
to be an error in VM Systems Group's VCOPY Product (a
replacement for IBM's CMS COPYFILE command). This site
used IBM's COPYFILE to copy VM/Monitor data. COPYFILE has
has an option "TRUNC" (although IBM's default is NOTRUNC)
that truncates blanks (X'40') when a fixed length file is
converted to a variable length file (to save DASD space).
When VCOPY replaced IBMs COPYFILE, its default of TRUNC
and a coding error in VCOPY (now fixed by Fix Co0263) had
truncated all X'40's at the end of VM monitor records!
If you have VCOPY, you can either request the fix from
the vendor, change their system wide default to NOTRUNC,
or specify NOTRUNC on the COPYFILE statement to avoid
the unexpected data trunction. Hopefully, you will not
encounter the problem, but the MXG circumventions made
(before the truth was known) were left in place!
Change line 212800 to read:
INPUT @9 USER : $8. @; /*MN098UID*/
Change line 216400 to read
IF LENDATA GE 1 AND LENDATA+19 LE LENGTH THEN
Insert two new lines after 229400:
229410: @;
229420: IF LENGTH GE 40 THEN INPUT
Thanks to Steve Smith, Hammermill Paper Co, USA.
Change 07.012 MVS/ESA TYPE1415 data now uses three bits of SMF14RIN to
VMAC1415 indicate ILIB managed data set (Bit 0 on), Trunc macro
Feb 15, 1989 issued (Bit 1 on) and/or Null segment encountered (Bit 3
on). MXG read byte one of SMF14RIN as variable RECIND1 &
byte two as RECIND2, but kept only RECIND1 (because all
bits in RECIND2 were formerly reserved). This change adds
RECIND2 to the KEEP list for TYPE1415.
Change 07.011 -In a major enhancement to CPU data capture in MVS/ESA,the
IMACPDB type 30 SMF records capture three new CPU measures:
VMAC30
VMAC434 CPUHPTTM - Hiperspace CPU. The CPU time used to read from
VMACSMF and write to hiperspaces by this step/job.
Feb 15, 1989 CPUIIPTM - CPU I/O SLIH time. The CPU time used by the
Second Level Interrupt Handler in servicing
I/O requests for this step/job.
CPURCTTM - Region Control Task CPU Time. The RCT handles
QUIESCE and RESTORE and thus predominately is
involved in SWAP management. This CPU measure
should significantly help TSO capture.
All three CPU measures are NOT captured in the RMF TYPE72
performance group data, nor are they in the type 4 or 34
step records. While the CPUHPTTM is a new measure of an
MVS/ESA-only activity (movement in/out of hiperspaces),
the CPUIIPTM and CPURCTTM now capture CPU times that have
been THE major contributor to uncaptured CPU times: I/O
interrupt handling and TSO swap processing.
IBMs CPU timing comparisons in the DFSORT 11 announcement
(289-036) use the sum of ALL CPU measures (the three new,
plus the two TCB measures AND the two SRB measures). For
those of you who have had trouble convincing your bosses
to use TCB plus SRB for billing, etc., you can use this
example from big blue! Note that IBM refers to "five"
CPU fields, but there are really seven fields now.
-Variables RECLAIMS, COMRECLM, and LPARECLM in TYPE30 and
TYPE434 (and hence in PDB.STEPS and PDB.JOBS) no longer
exist in MVS/ESA. In their same location are three new
MVS/ESA only variables:
CREADMIS - Incorrect CREADS. Number of misses when an
attempt to read data from an expanded-storage-only
hiperspace failed because the data was not found (was
variable RECLAIMS)
HIPAGINS - Hiperspace pageins from auxiliary storage
into processor storage (was variable COMRECLM).
HIPAGOUT - Hiperspace pageouts (was variable LPARECLM).
MXG 6.6 will "Tolerate" the new CPU fields (i.e. execute
without error), but for MXG to be "Capable" (i.e., to
create the new CPU fields in TYPE30 and PDB.JOBS/STEPS
data sets, and to create the three Hiper-related fields
you must make the following changes:
-In member VMAC30:
-Add the three CPU variables (CPUHPTTM,CPUIIPTM,CPURCTTM)
and the Hiper variables (CREADMIS,HIPAGINS,HIPAGOUT) to:
-KEEP list for TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6.
-LABEL statement.
c. CPU vars only to FORMAT statement for TIME12.2 format.
-Delete the CPUTM=SUM( ... ); statement, line 056800.
-Insert the following seven lines after line 057500:
IF LENCPU GE 56 THEN INPUT
CPUIIPTM PIB4.2
CPURCTTM PIB4.2
CPUHPTTM PIB4.2
@;
CPUTM=SUM(CPISRBTM,CPITCBTM,CPUHPTTM,CPUIIPTM,
CPURCTTM,CPUSRBTM,CPUTCBTM);
-Insert these lines after line 062000 (contains @;):
(Note that in the MXG implementation this change is more
extensive; variable MVSESA is now created by VMACSMF for
MVS/ESA. This change avoids that additional Edit.)
IF MVSXAFLG='....1...'B THEN DO; /* MVS/ESA */
CREADMIS=RECLAIMS;
HIPAGINS=COMRECLM;
HIPAGOUT=LPARECLM;
RECLAIMS=.;
COMRECLM=.;
LPARECLM=.;
END;
-In member IMACPDB add the six new variables (CPUHPTTM,
CPUIIPTM,CPURCTTM,CREADMIS,HIPAGINS,HIPAGOUT) to:
-The _PDB30_4 definition at lines 013200-013300.
-The _SUMSTP definition at lines 017700-017800.
Thanks to Dave Greene, Kwasha Lipton, USA.
Change 07.010 DB2 reports had minor errors. The use of "ALL" (to create
ANALDB2R reports for all plans, all ids, etc.) was removed in MXG
VMAC102 6.6 (but not specifically documented) because you might
Feb 17, 1989 have "ALL" as a plan name, etc. Now, to create reports
for "all" of something, use the default (by specifying no
value for the argument).
In ANALDB2R:
Line 235800 and 235900 must be reversed so DB2COUNT+1
precedes the CALL SYMPUT statement.
Line 254300 should be QWPZTOUT and line 255100 should
be QWPZISWI. (They are reversed).
In VMAC102:
Insert new line after 081900:
QWPZTRSZ=QWPZTRSZ*4;
Thanks to Ervin Claxon, Ashland Oil, USA.
Change 07.009 Processing multiple VM/XA Monitor files will cause the
VMACVMXA "Range is Repeated" error message in attempting to create
Feb 16, 1989 the temporary Format which maps Device Information to the
RDEVSID value. Duplicate RDEVSID values do exist in the
VXMTRDEV data set, but MXG's logic to remove duplicate
values incorrectly included BEGINMTR in the BY statement.
FIX: Remove BEGINMTR from both BY statements in lines 678500
and 678800.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 07.008 The JES2 Spool Transfer program causes multiple job purge
BUILDPDB records. If a job which is still in the execution queue
Mar 11, 1989 after it has been executed (eg., a job which encountered
a DSENQ conflict that was canceled and requeued, or any
job processed by the MVS Throughput Manager product) is
spool transfered and reloaded, two purge records will be
created (one at offload, one after real execution) and
both contain non-blank values for SYSEXEC. A non-blank
SYSEXEC separated the "real" purge record (for PDB.JOBS)
from the multiple NJE purge records (into PDB.NJEPURGE).
If two (or more) purge records with non-blank SYSEXEC are
found in the same BUILDPDB run, duplicate observations in
PDB.JOBS were built. The use of just SYSEXEC to identify
"real" purge records is insufficient. Part of this fix is
a guarantee that only one "real" purge record is used by
MXG, even if multiple are found. The other part of the fi
selects the purge record created at offload by JES2 Spool
Transfer program (DEVNAME, Transmit Device Name beginning
with OFF) into the PDB.NJEPURGE data set. If your site
does not use Spool Transfer, you have no exposure.
FIX: 1.BUILDPDB.
Insert new line after 014200:
014210 DEVNAME=:'OFF' OR
Add JPURTIME to the end of the BY list at line 023500.
Insert new line after 023600:
IF LAST.JESNR THEN OUTPUT;
2.IMACPDB
Add DEVNAME to line 008600 (inside _PDB26J2 macro).
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.007 MONTHBLD on the MXG 6.6 Library causes a SAS 180 SYNTAX
MONTHBLD error. In making the member more comsmetically appealing,
Feb 14, 1989 the invocations of _MNTHBLD ended up ending in column 72.
Since the next line starts with MACRO, SAS combined the
end of one line with the beginning of the next to create
the string _MNTHBLDMACRO, which SAS cannot recognize!
FIX: Delete the blank before the percent sign in each line
than ends with _MNTHBLD in column 72.
Thanks to John Mattson, National Medical Enterprises, USA.
Change 07.006 Variable PRENTIME in PDB.PRINT was added to the sort list
BUILDPDB in BUILDPDB but was left in a DROP list in BUILDPDB/3 and
BUILDPD3 not added to the BY list in WEEKBLD. This caused PRENTIME
WEEKBLD to not exist in PDB.PRINT and caused WEEKBLD to ABEND.
Feb 9, 1989
FIX: 1.BUILDPDB: remove PRENTIME from DROP statement line 048300
2.BUILDPD3: remove PRENTIME from DROP statement line 048700
3.WEEKBLD: add PRENTIME to line 003200 between PRINTIME and
OUTDEVCE.
Thanks to John Mattson, National Medical Enterprises, USA.
Thanks to Gary Ruedinger, Response Graphics, USA.
Change 07.005 DB2 Trace 102 SMF record subtype 58 or subtype 87 caused
VMAC102 STOPOVER ("Input exceeded record length") for DB2 1.3 or
Mar 11, 1989 earlier records.
FIX: Insert new line after line 163900:
163910 @; IF QWT02R1L GE 302 THEN INPUT
Add PIB4. after QW0087FR in line 144400.
In subtypes 15,17,18,22,53, and 58 incorrect calculations
caused the input to end before all fields had been read.
Change ENDPROD to ENDPRODA in lines 098200,250800, and
255600.
Change OFFPROD to OFFPRODA in lines 160200,166400,
260400, and 263900.
Thanks to Jan-Ake Christoffersson, Gotabankendata, SWEDEN.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.004 NPM type 28 produces "Unexpected Subtype" message for 08X
VMAC28 NPMSUBTY for the ENABLE NSA event record.
Feb 7, 1989
FIX: Change first occurrence of 09X in line 197600 to 08X.
Thanks to Michelle Buchecker, IBM Boulder, USA.
Change 07.003 JCL for HSM processing included non-existent testing name
JCLHSM of XMXGHSM.
Feb 7, 1989
FIX: Change XMXGHSM to VMXGHSM in line 006600.
Thanks to Billy Westland, Candle Corporation, USA.
Change 07.002 MXG variable CPUTM in the CIMSTRAN data set from IMF data
VMACCIMS from Boole & Babbage did not include all CPU variables,
Feb 7, 1989 and the variable was not in the KEEP list. Also, SERIALIO
was not protected if it overflowed its two byte counter.
FIX: 1.Insert new line 002410 (after 002400) containing CPUTM
2.Add CPUCOPTM,CPUMOPTM, to the SUM function arguments
in line 044000.
3.Add CPUCOPTM,CPUMOPTM,CPUSBFTM,CPUSDLTM,CPUSOPTM,
CPUDB2TM to the SUM function arguments in line 070400.
4.Change LE 12 to LE 13 in line 065900.
Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
Thanks to Agneta Bergsten, SPP, SWEDEN.
Change 07.001 TREND data base code fixes. Always specify SAS Options
GRAFTRND MACRO and DQUOTE when using %MACROs. GRAFTRND will only
TRNDJOBS produce first and last pair of graphs if MXG Version 5.5
TRNDRMFI PDBs were used (because SU_SEC variable did not exist in
TRND72 RMFINTRV until 6.6). When a macro variable is set by data
PDBTREND value in a data step, a RUN; statement seems required at
VMXGSUM the end of the data step to actually set the macro value.
Mar 9, 1989
FIX: 1.GRAFTRND: Change all occurrences of OTHRn (ten separate
times for n=0,1,...,9) to OTHn (without the R).
Line 007800 add OTH6CPU OTH7CPU OTH8CPU OTH9CPU
Insert two new lines:
011310 RUN;
017110 RUN;
2.TRNDJOBS line 002300 Add NUMJOBS after SUM= (before IWT)
3.TRNDRMFI:
Insert new line after 001200:
001210 %INCLUDE SOURCLIB(VMXGSUM,VMXGDUR);
Line 001400 add (IN=INWEEK) after WEEK.RMFINTRV
Lines 002600,29,32,35,38,41,44,47,50,53,56,59,62,65,68,75
add BATCNT TSOCNT IMSCNT CICSCNT OTHRCNT OTH0CNT
OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT
OTH7CNT OTH8CNT OTH9CNT TRIVCNT to respective line.
Lines 011400,115,117,119,121,123,125,127,129,131,133,135
137,139,141,143 change / ....TRAN to / ....CNT
respectively.
Insert new line after 014500:
014510 IF INWEEK THEN DO;
Insert new lines after 014700:
014710 END;
014711 IF SU_SEC =. THEN SU_SEC=.;
014712 IF PARTNCPU=. THEN PARTNCPU=.;
014713 BATCNT=BATTRAN*DURATM;
014714 TSOCNT=TSOTRAN*DURATM;
. (one for each of the 16 ...CNT variables added
. in lines 002600-007500 above)
014727 OTH9CNT=OTH9TRAN*DURATM;
014728 TRIVCNT=TRIVTRAN*DURATM;
After line 15400 insert
DROP BATCNT TSOCNT IMSCNT CICSCNT OTHRCNT OTH0CNT
OTH1CNT OTH2CNT OTH3CNT OTH4CNT OTH5CNT OTH6CNT
OTH7CNT OTH8CNT OTH9CNT TRIVCNT;
4.TRND72 line 001400 Semi-colon must be a comma
5.PDBTREND line 009500 %GRAFTRN must be %GRAFTRND
insert new lines after 011200:
011210 PROC SORT;
011220 BY SYSTEM PERFGRP;
6.VMXGSUM:
line 025900 Add DATETIME &DATETIME 8 before semicolon
new line 025910 IF DATETIME=. THEN DATETIME=.;
line 035400 Add DATETIME &DATETIME 8 at end of line
new line 035510 IF DATETIME=. THEN DATETIME=.;
Thanks to Alan W. Maloney, Telenet Communications, USA.
Thanks to J. D. Hill, CyCare Systems, USA.
Thanks to Pete Shepard, Ashland Oil, USA.
Thanks to Rich Lopez, Ethicon, USA.
LASTCHANGE: Version 7
This page is (almost) blank (intentionally).
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 15
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-INCORROUT
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
=========================member=CHANGE06================================
/* COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS */
This is the true production release of MXG Version 6.6, Jan 21, 1989.
The library is now at Change 6.213 (NEWSLETTER THIRTTEN said 6.206).
MXG now produces 552 datasets with 18070 variables from 910 members.
The enhancements, installation instructions, compatibility issues,
documenation location, for MXG Version 6 are in Newsletter THIRTEEN,
which is now contained in member NEWSLTRS of the MXG Source Library.
YOU MUST READ THAT NEWSLETTER BEFORE INSTALLING MXG VERSION 6.6.
Newsletter THIRTEEN additionally contains Administrative Announcements
Technical notes and enhancements planned for the next version of MXG.
After you have read NEWLETTER THIRTEEN, you will need to return to
this member to read the changes themselves, as much of the technical
information is contained in the detail change descriptions herein.
Note especially that Change 6.206 in this member has been changed
from that printed in MXG Newsletter THIRTEEN. The time between the
printer and tape building allowed enhancements and more consistent
naming conventions for the members which control the new Trend Data
Base enhancement. Note these related features implemented in that
change:
The %VMXGSUM macro is a very powerful generalized algorithm to create
organized summarization of complex SAS data sets with a simple series
of parameters. Its use will go far beyond its first implementation
here in the Trend Data Base.
The ASUMCICS member uses %VMXGSUM to create Hourly CICS service
objectives (percent transactions responses in less than 1,2,3,5,8, 15,
etc. seconds) for each User, Transaction and Terminal, in the new
PDB.CICS data set. The ASUMJOBS member uses %VMXGSUM to similarly
calculate IWT (Initiation Wait Time) distributions hourly by job class
(percent jobs initiated in 2, 5, 15, 30 min, etc.) in the new
PDB.JOBSKED data set. These members implement the measurement of
service objectives as described in Chapter Eight.
%VMXGSUM is used in a different fashion in the four Trend Data Base
building members TRNDCICS, TRNDJOBS, TRNDRMFI, and TRND72, which take
the weekly PDB data sets and the Trend-to-Date accumulation and
produce the new updated trend-to-date ("five years in five CYL") data
base. These members, which can be executed after the weekly PDB has
been built with JCLTREND, provide the long range tracking, trending
and capacity modeling demonstrated in the graphs in Chapter Forty-Two.
Member GRAFTRND provides ready-made 18-month graphics.
The MXG Trend Data Base is a brand new implementation using new style
%MACROs to create a series of a DATA and PROC steps. It has not had
the intense testing the remainder of MXG Version 6 received (444 MXG
users have been using a pre-release of Version 6, many installing it
in a production mode). Thus, while I think it is real good, I reckon
it might still have a few cobwebs I missed. If you have problems in
using these new %MACROS, look real careful that you did not fail to
terminate every parameter with a comma. The %MACRO facility is
equally powerful and equally unforgiving. I almost included the
ASUMCICS and ASUMJOBS members in BUILDPDB to build PDB.CICS and
PDB.JOBSKED by default, but at the last minute decided it had not been
tested widely enough to justify that design. Do not hesitate to let
me know what was missed and what should be added.
Yes, VMers, the Trend Data Base implementation at present is only for
the MVS data sources. The %VMXGSUM macro, however, is there for the
using yourself, until next version, when there really will be support
for the VM Trend Data Base and the VM/XA Trend Data Base as well!
==========================Changes Log==================================
All changes listed below have already been made in this MXG library.
Some of the changes contain the code with line numbers, because those
changes were provided by telephone prior to this production shipment.
You MUST read each Change description below to determine if a Change
will impact your installation. For each impacting change, you should
also read the comments in the beginning of the source members that
are listed under the change number. Notes, comments, and last minute
documentation are usually found in comments in changed members.
NEXTCHANGE: Version 6
=============Changes thru 6.213 as of Jan 21, 1989 ===================
Change 06.213 Talk about making it under the wire, as I was headed to
XMACEPIL the data center to build the production tapes, the mail
Jan 21, 1989 delivered the Candle documentation of changes in their
EPILOG 1000 for CICS Version 440 record formats! Because
the records are changed in so many places, and because I
did not have test data for validation, this new member
contains syntax tested code only, and only applies to
Version 440 records, which are incompatible with their
Version 430 records. See comments at beginning of this
new member. There are 46 new variables (at the end of
the KEEP= list, starting with BI4GLPGM), and there were
21 variables removed (see blanks where they used to be
in the KEEP= list, compared with VMACEPIL member!)
Thanks to Ashok Argarwala, Candle Corporation, USA.
Change 06.212 The SAS supplied EXEC for SAS under CMS does not test to
EXECDALY see if you issued a GLOBAL MACLIB statement to CMS before
REXXDALY you invoked SAS. The SAS EXEC itself issues a GLOBAL
Jan 19, 1989 MACLIB statement for the AUTOEXEC MACLIBs. Since the MXG
execution instructions under CMS (p. 24, MXG Supplement)
tell you to GLOBAL MACLIB USERID SOURCLIB and then type
SAS, the concatenation of USERID and SOURCLIB MACLIBS
is disconnected by SAS's EXEC, and your MXG program may
fail with "Member Not Found". The simplest solution to
execute MXG under CMS SAS is probably to create your own
copy of the SAS EXEC, and add the USERID and SOURCLIB
names to the list of MACLIBs globalled therein. The SAS
Institute plans to change their EXEC in a future version
to check for GLOBAL MACLIBs first, and if found, to add
SAS's desires to your already stated command.
Thanks to Steve Morton, SAS Institute, England.
for bringing this to my attention.
Change 06.211 The RACF report for Insufficient Authority now includes
ANALAUDT the INTENT and ALLOW values, and for RACFAUTH='10'X the
Jan 19, 1989 AUTHRITY=AUDIT was corrected to AUTHRITY=SPECIAL.
Thanks to Wing Louie, Metropolitan Life, USA.
Change 06.210 Newsletter THIRTEEN went to the press on Monday, and it
TYPEIMS said IMS FASTPATH log records were not supported in 6.6.
Jan 19, 1989 I had really planned to add it during this week while
the newsletter was at the printer and while my QA tests
were executing. SAS Europe had provided me with test data
and a copy of DBFULTA0 output for validation. I had the
printed assemblies of ILOGREC RECID=ALL for IMS 1.3,2.1,
and 2.2 at hand, as they contain the DSECTs of all IMS
log records. When what to my dismay, do I find that IBM
does not print the format of the X'59' FASTPATH IMS log
records, even when TYPE=ALL is specified. I have been on
the phone to IBM support with still no answer as to how
or where these records are documented, and I have run out
of time. Well, there's always the next version. Sorry!
Of interest, however, was IBM Level One's sincere comment
that no one knew much about fastpath, because they only
rarely get a call about fastpath!
Footnote: Two Level 1 calls and one Level 2 call later,
but only hours before the production building of MXG 6.6
begins, I did get at least the DBFK.... member names in
DCSOURCE that are supposed to contain the needed DSECTS!
Change 06.209 The response time (RESPNSTM) in the IMSTRAN data set was
TYPEIMS incorrect in some cases when multiple transactions were
Jan 17, 1989 processed per program schedule (eg., WFI). The reason
was that in step 8 the merge of input and output records
did not match in all cases; if an output record is missed
the original code merged the input record with the NEXT
output record. The result was an increasing RESPNSTM
for MULTRANS as much as the time of day continues!!! The
logic now balances the timestamps when output records are
missing by recognizing the condition and then setting the
values missing. An output record will be missed for any
transaction which had not completed when the IMS log was
dumped, but the effect of a single missed output record
was propagated into several IMSTRAN observations.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 06.208 VM/Monitor fields which were divided by 16384 appear to
VMACVMON be slightly in error; the correct divisor should have
Jan 17, 1989 been 16666.666 (which is 1000000/60).
Thanks to Rob Owens, SAS Institute Europe, GERMANY.
Change 06.207 DB2 Trace records, when written to GTF only, are limited
Jan 17, 1989 to 280 bytes (a 24-byte GTF header, and 256 bytes of DB2
trace data per record). The most important trace records
fit in the 256 byte limitation, but Trace events needing
more than 256 bytes are internally "spanned" by DB2 into
several GTF records. Unfortunately, these are not valid
VBS records, and are not straightforward to decode. The
MXG 6.6 support for GTF format DB2 trace data processes
only the un-spanned records at present. If a real need
exists (only startup records are spanned thus far), we
will investigate enhancing the MXG algoritms with you.
I still think GTF is the wrong place for DB2 Trace. In
the first place, the detail accounting reports in member
ANALDB2R meet the needs of almost all DB2 administrators,
and trace should be limited to special occasions. If you
must trace, you should use good sense and SMF files, and
"To ensure adequate buffers exist, specify CISZ(4096)
and BUFSP(81920) for each SMF VSAM data set"
as IBM recommends in SC26-4095-2.
----Changes thru 6.206 were printed in MXG Newsletter THIRTEEN-------
Change 06.206 The MXG MVS Trend Data Base preliminary implementation.
ASUMCICS This series of members are the beginning of the long
ASUMJOBS overdue (almost "fabled") enhancement to provide for
GRAFTRND the long term trending of response, resources, etc.,
IMACSHFT in a very small data library referred to as the Trend
JCLTREND Data Base. More will be written later on its use, but
PDBTREND for starters, PDBTREND will build an initial trend data
TRNDCICS base from the past and thereafter JCLTREND will update
TRNDJOBS the past weeks data into the Trend Data Base, and give
TRNDRMFI management-pretty reports for the past eighteen months
TRND72 trends! The member naming conventions to be used are
VMXGDUR ASUM.... for the first summarization from detail data
VMXGSUM into an interval (eg., hourly) from PDB input back into
Jan 15, 1989 a new data set in the same PDB and TRND.... for second
summarization from one interval (eg., hourly) into a
diffeent (eg. week-shift), from WEEK input combined
with existing TREND to create updated TREND data set.
ASUMCICS - Creates CICS interval summary and response buckets
from detail transaction data (CMF or Landmark!).
GRAFTRND - Graphs of CPU capacity with simple linear regression
prediction CPU usage from TREND.RMFINTRV. See member.
IMACSHFT - Existing IMACSHFT was modified to return both a SHIFT
variable and the start-time of the shift for TREND.
To be compatible with TREND, you must replace your
present IMACSHFT with this new member. The internal
logic was restructured to pass back a modified value
for the inputted variable DATETIME, but there was no
change in the value of SHIFT passed back by IMACSHFT.
JCLTREND - Example JCL to execute weekly after your weekly PDB
has been built, to update the existing Trend Database
with the new week's data. This usually is best run
after you have examined your weekly runs, as there is
no supplied code for backout if you mess up!
PDBTREND - Create your Trend Data Base for the past directly
from weekly SMF files or already build weekly PDBs.
Start here, and work backward in history as far as
you want to go. Each execution adds another week to
your Trend Data Base.
TRNDCICS - Builds TREND.CICS dataset.
TRNDJOBS - Builds TREND.JOBS dataset.
TRNDRMFI - Builds TREND.RMFINTRV dataset.
TRND72 - Builds TREND.TYPE72 dataset.
VMXGDUR - Calculates durations of HOUR, DATE, WEEK, MONTH.
Will optionally calculate SHIFT using IMACSHFT.
Input variable DATETIME contains the timestamp to
be examined. Will calculate SHIFT using IMACSHFT
and will reset DATETIME to the timestamp of the
beginning of the shift interval.
VMXGSUM - The heart and soul of MXG summarization. Contains
multiple macros which make it act like a PROC
that lets you summarize detail data into interval
data and interval data (eg. hourly) into other
intervals (eg., weekly), taking into account the
things like rates and percentages which must be
expanded, summed, and then contracted in the
summarization process. "Self-Documented" - ha?
Thanks to Chuck Hopf, Hopf Consulting, USA.
for lots of help with %macro implementation.
This is the essence of the system which generated the graphs in
Chapter 42 of the MXG Guide. Five years data in five cylinders!
Change 06.205 Several graphics enhancements were made to make MXG
GRAFRMFI co-exist better with SAS/GRAPH. Device selection in
VMXGGOPT GRAFRMFI is now enabled with the new %VMXGGOPT macro
XADMDEFS which added support for IBM3179, IBM3279, IBM3287,
Jan 15, 1989 ZETA887, TCX4107, IBM3800, and especially for SAS/PC.
Member VMXGGOPT allows for the dynamic selection of
graphic devices; see documentation in that member.
XADMDEFS is also referenced in VMXGGOPT; it provides
the GDDM ADMDEFS for IBM 3800 and 3820 graphics.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.204 MXG had provided FMXGUCBL and VMXGVTOC to capture DASD
ASMVVDS space management data, but VTOCs do not provide data on
EXTYVVDS VSAM files. This contracted enhancement now provides
IMACVVDS DASD Space management for VSAM files. Instead of the
JCLVVDS VTOC, space information on VSAM data spaces is in the
TYPEVVDS VVDS, located on each volume which contains VSAM data
VMACVVDS spaces. MXG provides the Assembly source code and the
Jan 15, 1989 JCL to create the ASMVVDS program in member ASMVVDS.
Once assembled, program ASMVVDS can be executed by the
JCL in JCLVVDS, and the VVDS data is extracted and then
written to a flat file, or (my recommendation), can be
written as an SMF record. Once the VVDS data is in the
flatfile or SMF record, member TYPEVVDS will create
the MXG dataset TYPEVVDS which can be then used to
measure, manage, and charge back VSAM DASD space.
See comments in member ASMVVDS; this program must be
authorized to read the VVDS.
Change 06.203 Although no data has been made available from VM/370
IMACVMON Release 6, comparison of IBM's documentation and the MXG
Jan 15, 1989 code in VMACVMON strongly suggests that MXG will support
the Release 6 records, provided only that both the _HPO
and _MP macros defined in IMACVMON are enabled. In fact,
both were required enabled for Release 5 with or without
HPO. The defaults have now been changed to enable both
_HPO and _MP since few new MXG sites will come up on 4.2!
This should not affect current MXG sites, since you have
already tailored IMACVMON into your USERID.SOURCLIB and
that member will override the new defaults in MXG!
Change 06.202 NPM 1.3 type 28 support was enhanced to include subtypes
FORMATS x60-x62 (new with Network Gateway Accounting), and the
VMAC28 additional variables added to the MSA, BAS, BAN, and NTK
Jan 15, 1989 segments. No NGA data has been available for testing, but
having the code in place means that you won't need a new
version of MXG when you install NGA later this year. IBM
really came through in time with this documentation!
Change 06.201 DB2 Trace records processing code has been enhanced to
IMAC102 read most new fields added by DB2 Version 2.1. This is
IMAC102A also a major restructure of the code. Not all of the new
IMAC102B subtypes have been tested against 2.1 data, so there is
VMAC102 a slight risk in using the type 102 code in this version
Jan 14, 1989 of MXG. A new macro, _DB2IID is defined in IMAC102 that
can be used to delete specific IFCID (subtype) values if
there are any problems. All TRACEnn labels were removed,
and comments in IMAC102 identify which IFCIDs are in each
trace class.
Change 06.200 PROC DATASETS LIB=_IMSTRAN NOLIST;DELETE IMSTRAN; was
TYPEIMS removed, because SAS not only does not support deletion
Jan 14, 1989 if _IMSTRAN is a tape, but it creates a condition code
twelve! The purpose of the delete was to re-use the
same space on disk; thus if you create IMSTRAN data on
disk, you will need to do your own delete, eg.:
//SYSIN DD *
PROC DATASETS LIB=IMSTRAN ...
%INCLUDE SOURCLIB(TYPEIMS);
Thanks to Tim Follen, Blue Cross of Ohio, USA.
Change 06.199 DB2 data written to GTF is now supported by the use of a
ANALDB2R new _GTFDB2 macro added to VMACSMF. Members TYPEDB2G and
TYPEDB2G TYPE102G are their "no-G" members with _SMF replaced by
TYPE102G _GTFDB2. If you write DB2 trace data to GTF, you must
VMACSMF apparently specify the complete 0FB9 Event ID to GTF at
Jan 11, 1989 startup; Ron responded with only FB9 and the GTF records
unexpectedly contained EFB9 as their EID! The member
ANALDB2R was also enhanced with the new GTF= option to
use that data source for DB2 reports, and a new option
PDBOUT was added to create an output copy of the DB2
data sets if desired.
Thanks to Ron Roberts, The Equitable Life Assurance Society, USA.
Change 06.198 Support for COM-PLETE SMF Accounting Records creates four
EXCOMASR data sets, one from each of the four records. COMPULON,
EXCOMLON COMPULOF, COMPUCKP, and COMPUTRM correspond to ULOG On,
EXCOMLOF ULOG Off, Checkpoint, and program termination. Only the
EXCOMCKP COMPUTRM data records have actually been fully tested.
EXCOMTRM
IMACCOMP
TYPECOMP
VMACCOMP
Jan 11, 1989
Thanks to Karl Smit, Decision Support Services, SOUTH AFRICA.
Change 06.197 IBM's SNA Application Monitor "SAMON" Release 1.2 creates
EXSMOASR an SMF-format record for a SDXKSTA0 Statistics Data Set.
EXSMOAUR MXG creates six new datasets, SAMONASR,SAMONAUR,SAMONSSR,
EXSMOSSR SAMONTLR,SAMONTSR,SAMONUSR which are described in IBM's
EXSMOTLR SNA Application Monitor Operations and Diagnosis Guide
EXSMOTSR pp.86-98. Caution: no data records have been received
EXSMOUSR as yet, so this code has only been syntax checked.
IMACSAMO
TYPESAMO
VMACSAMO
Jan 11, 1989
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 06.196 This VM/370 report caused an error when no channel data
ANALVMDY was collected, because PROC TRANSPOSE does not create the
Jan 10, 1989 COLn variables when there is not input data. This causes
the RENAME COL1=BUSYPCT statement to fail. To fake out
the SAS compiler to avoid the error, the statement
IF COL1=. then COL1=.; was inserted after the RENAME.
This trick creates the numeric variable COL1 to satisfy
the SAS compiler, but does not change its value if it
already exists.
Thanks to Jay Cicardo, Southwestern Bell, USA.
Change 06.195 This paper on the VM/XA Monitor Facility will be
DOCVMXAF published later this year in a major journal, but
Jan 10, 1989 its author has been kind enough to share his work
with MXG users.
Thanks to Richard Steele, Louisville Gas and Electric, USA.
Change 06.194 The 1987 CMG Paper (Proceedings, pp.432ff), "A Method for
ANALCACH Reporting Cashed I/O Subsystem Performance", by Nancy
Jan 10, 1989 Nearing, Washington Consulting Group discussed methods
to depict cache performance characteristics, using both
RMF type 74 records and the RMF Cache DASD Reporter FDP
SMF records (MXG member TYPECACH). The report examples
in that paper are implemented in this contribution.
Thanks to Bruce L. Green, Medical Information Bureau, Inc, USA.
Change 06.193 RMDS enhancements suggested by this user led to a
VMACRMDS general cleanup of RMDS Version 3 SMF record code,
Jan 9, 1989 and capture of additional useful RMDS data fields.
Thanks to Jenell Ratterree, The Cooper Group, ENGLAND.
Change 06.192 HSM Processing. This is a significant contribution from
JCLHSM this user, a complete self-contained system. I have not
VMXGHSM really tested the code with real data. I simply put all
Jan 9, 1989 the macro definitions into a the single VMXGHSM member,
syntax tested the code with no input records. It will
be examined and documented in the future, and possibly
data set names will be prefixed with HSM
Thanks to Carole Larivee, System One Corporation, USA.
Change 06.191 Support for SMF records created by STC's 4400 tape silo.
EXSTCBLO Six data sets, STCBLOS, STCVARY, STCLSM, STCLMU, STCEJECT
EXSTCVAR and STCENTER are created for BLOS stats, VARY station,
EXSTCLSM modify LSM, LMU read statistics, cartridge ENTER and
EXSTCLMU cartridge EJECT.
EXSTCEJE
EXSTCENT
IMACSTC
TYPESTC
VMACSTC
Jan 8, 1989
Thanks to Rodney L. Reisch, General Electric Plastics, USA.
Change 06.190 Support for SQL/DS accounting records created under VM
EXVMSQLI has been written but has not been tested with data yet.
EXVMSQLS Four data sets, VMSQLINI, VMSQLSYS, VMSQLTRM, VMSQLUSR
EXVMSQLT are created for Initialization, System, Termination and
EXVMSQLU User events as described in SH24-5043-2.
TYPEVM
Jan 8, 1989
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 06.189 Several VMACROSC fixes: Variables VOLSER1-6 in data set
ANALROSA ROSCODSF now exist and are spelled DSFVOL1-6, and DSNAME
ANALRRTM and MEMBER were added. Code to process 'F4'X ROSREC was
DIFFROSC relocated to cause ROSCOSHU observations to be created.
VMACROSC The MONITOR='ATT' test was expanded to include 'AJO' too.
Jan 8, 1989 In DIFFROSC: START ISTART and IEND are now dropped after
their RETAIN (keeping START caused unexpected conflict
in ANALRRTM report). In ANALRRTM and ANALROSA all
divides are now protected against zero-divide error.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 06.188 Additional sets of workload variables are now created in
EXRMFINT RMFINTRV and labeled in EXRMFINT. MXG now creates five
IMACWORK new "OTHn" sets of variables (OTH0, and OTH6 thru OTH9).
RMFINTRV With the four predefined BATCH, TSO, CICS, and IMS groups
Jan 8, 1989 you have fourteen sets of workload variables available.
Comments in all three cited members have been (hopefully)
clarified on how to set workload definitions in IMACWORK
and to then label them in EXRMFINT. Variables CPUTYPE
and CPUVERSN (from type 70) were added to RMFINTRV. The
variable SIO73CNT now contains total SIOs/SSCHs from the
type 73 (if MVS/370) or type 78 (if MVS/XA).
Change 06.187 Support for Netspy Release 3.1 Level 3 new type V record
EXNSPYVR (Virtual Routes being monitored) creates new NSPYVIRT
VMACNSPY data set. Thanks Duquesne for releasing the format of
Jan 8, 1989 the new record before they ship their enhancement!
Thanks to Luis Motles, Duquesne, USA.
Change 06.186 MXG member naming conventions are changed by this change.
ANALDB2 Past members ANALDB2 and ANALROSC performed de-accumulate
ANALROSC using DIF() function, but since they produced no reports,
DIFFDB2 they should not have begun with ANAL. Now, they will be
DIFFROSC contained in new members DIFFDB2 and DIFFROSC. To keep
Jan 8, 1989 your present programs error free, there still are the
members ANALDB2 and ANALROSC on the MXG library, but they
now only %INCLUDE their respective DIFF.... member name.
All future SMF processing which requires DIF() will be in
members beginning with DIFF. At you convenience after
MXG Version 6 is installed, you should change references
to ANALDB2/ANALROSC in your USERID.SOURCLIB(EXPDBOUT) to
DIFFDB2/DIFFROSC (assuming, of course, that you even use
the MXG Exit Facility to process DB2 or ROSCOE SMF data
with BUILDPDB/3!)
Change 06.185 Support for Duquesne's TPX Session Manager SMF records
EXTPXAOF creates six new datasets: TPXSTART, TPXINTRV, TPXTRMON,
EXTPXAON TPXTRMOF, TPXAPLON, and TPXAPLOF. Because TPXINTRV data
EXTPXINT is written as accumulated, member DIFFTPX is required to
EXTPSSTA de-accumulate the interval data. MXG includes DIFFTPX in
EXTPXTOF TYPETPX automatically, but if you intend to read TPX data
EXTPXTON in BUILDPDB/3, you will need to include DIFFTPX in your
IMACTPX EXPDBOUT member.IMACTPX sets your chosen SMF record id.
TYPETPX
VMACTPX
Jan 8, 1989
Thanks to David Daner, Sun Refining and Marketing, USA.
Change 06.184 The text portion of all prior MXG Newsletters are now in
NEWSLTRS this new member (the "Change Log" portion of Newsletters
Jan 3, 1989 are in members CHANGEnn for prior MXG Versions and in
member CHANGES for the current MXG Version.) We choose to
put the Newsletters online so you can search for specific
items, and to (hopefully) eliminate the need for multiple
copies of the printed Newsletters for large sites. Does
this solution meet your needs?
Change 06.183 Variable BRFLDBNO in TYPE37 (Receive level in DBm) is an
VMAC37 IB2. and not PIB4. field.
Jan 3, 1989
Thanks to Claudia Ku, Farmers Insurance, USA.
Change 06.182 Variable TYPETASK from Type 30, which is propagated into
VMAC30 PDB.JOBS and PDB.STEPS, should contain JOB, STC, or TSU.
Dec 29, 1988 However, tasks started before JES (such as LLA, MSTR, SMF
BLSJ, JES, and DUMP) have their jobname in TYPETASK. With
this change, MXG forces TYPETASK to be STC if it is not
JOB or TSU, so that TYPETASK can accurately be used to
differentiate jobs, sessions and started tasks. Variable
TERMNAME (MVS/ESA, symbolic terminal name) contains the
TSO user's terminal name, but contains garbage for JOBs
and STC. (IBM failed to check before moving data - a PTF
will be issued eventually).
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 06.181 Type 74 processing was enhanced to include SKIP logic to
VMAC74 compatibly handle any future IBM changes in data length.
XMAC74 (I thought I had done this to all RMF code last year, but
Dec 29, 1988 must have overlooked this member.)
Change 06.180 DOWNTM estimate from type 0 SMF record will be zero if a
VMACSMF type 90 record (OPERATOR IPL response) precedes the IPL
Dec 28, 1988 record. To give a better estimate of when the last record
was actually created, the PREVTIME PREVSYS variables are
now retained only if it is not a 2, 3, or 90 SMF record;
(i.e., type 90 was added to the test.)
Thanks to Jeff Fox, SKF USA, USA.
Change 06.179 DOS POWER variable SYSID (system identification) was not
TYPEDOS kept in the MXG DOS..... data sets. Now it is.
Dec 28, 1988
Thanks to Richard Steele, Louisville Gas and Electric, USA.
Change 06.178 For VM/370 Monitor data from sites with (a) nonzero value
VMACVMON of SYSTIME in their DMKSYS module, and (b) which process
Dec 27, 1988 concatenated VM/Monitor data, MXG incorrectly reset the
GMT time zone delta when the second 0/97 Monitor Start
record was encountered, causing STARTIME in MXG datasets
to change to GMT instead of Local, because two variables,
FFFFF and FRSTBASE were not retained in the first RETAIN
statement (line 304).
Thanks to Rodney L. Reisch, General Electric Plastics, USA.
Change 06.177 Continuing cleanup of VM/XA replaced several unnecessary
VMACVMXA variables in VXMTRSPR with SDOMAINS and HDOMAINS decoded
Dec 23, 1988 just like EDOMAINS in VXMTREPR to identify which domains
are active for Sampling, Hi-Freq, and/or Event data, and
CHANBYTM label was corrected (ANY channel active). Much
more significantly, the VXIODDEV and VXDEVTOT datasets
are now enhanced and contain the RDEVCLAS, RDEVTYPE, etc.
fields from the VXMTRDEV start-up records. Additionally,
the MXG logic to recognize a user logon failed once when
only 11 actual samples were counted by IBM in a 60 second
interval with hfrate of 5 seconds. Line 6194 was changes
to test (ZZQUCT+1) LT instead of ZZQUCT LT to hopefully
compensate for a lost sample. The implementation to add
device information requires a FILEDEF/DDNAME of INSTREAM,
(temporary, 3 tracks at most) during the creation of the
VXIODDEV etc. data sets. MXG writes SAS code to INSTREAM
filename and then %INCLUDEs INSTREAM to execute the PROC
FORMAT which is the table-look-up of device mapping.
Thanks to Richard Steele, Louisville Gas and Electric, USA.
Change 06.176 This error was only on the 6.5a and 6.5b pre-releases DB2
VMACDB2 type 101 record. Line 1275 took a finger fault. It should
Dec 20, 1988 read IF QWHCLEN GE 56 THEN .... instead of GE 46.
=============Changes thru 6.175 comprised MXG 6.5b pre=release =======
Change 06.175 The MXG exit code which creates SMF records from IDMS is
IDMSEX05 now updated for IDMS 10.2, due to this user. The ASM
IDMSEX13 code formerly in IDMSEXIT is now split into IDMSEX05 and
IMACIDMS IDMSEX13. Exit 05 creates SMF record 190 (was type 200)
VMAC200 and exit 13 creates SMF records 191-193 (was types 201
VMAC201 203 in IDMS 10.1). The same data sets (TYPE200-TYPE203)
VMAC202 are built, and member IMACIDMS tells MXG the actual SMF
VMAC203 type you choose. The variable ID has been added to the
Dec 19, 1988 four MXG data sets so you can tell which IDMS created the
particular SMF record.
Thanks to Ed Dassori, Whirlpool Corporation, USA.
Thanks to Keith A. Immink, Whirlpool Corporation, USA.
Change 06.174 The MXG option to read VM/XA MONWRITE output data and to
VMACVMXA then build "true" VB format records was not true, as four
Dec 16, 1988 extra bytes were embedded. (It worked in testing because
the _VMINPUT macro expected those extra bytes!). Both the
_OUTFILE and _VMINPUT macros were corrected to build and
read real VB data correctly!
Janice Radel, McDonnell Douglas Automation, St. Louis.
=============Changes thru 6.173 comprised MXG 6.5a pre=release =======
Change 06.173 The summarization of CICS transaction data from either
ASUMCICS IBM's CICSTRAN or Landmark's MONITASK into the PDB.CICS
Dec 6, 1988 dataset is accomplished by this program. MACROs defined
in the member determine the grouping (default is by
APPLID OPERATOR TERMINAL STRTTIME TRANNAME) and define
the interval summarized (default is hourly). Data set
PDB.CICS contains resources sums (CPU, I/O, characters)
maximum response, and eight buckets for response counts
of 1,2,3,4,5,8, 10 and over 10 seconds. This will be the
CICS part of the "Trend Data Base" to be implemented in
future.
Change 06.172 Preliminary reports for NPM 1.3 type 28 data sets is now
ANALNPMR available in this user's report contribution.
Dec 6, 1988
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.171 Support for Duquesne's DASDMON SMF records started with
ANALDMON the SAS code provided with the DASDMON product, but the
EXDMDSN code was redesigned to conform to MXG structure and was
EXDMJOBS validated with actual data. Some preliminary reports are
EXDMVOL also available in ANALDMON.
IMACDMON
TYPEDMON
VMACDMON
Dec 6, 1988
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.170 IDMS 10.2 Performance Monitor from Cullinet is a complete
EXIDMaaa re-design of the SMF record subtypes and contents which
IMACIDMS changed variable names and added new data sets as well.
TYPEIDMS This support replaces the TYPERTE and IDMS.... data sets
VMACIDMS built for the 10.1 PM. The 10.2 data sets now all start
Dec 5, 1988 with IDMS, but now have three letter suffixes: ARA,BUF,
CDM,DBK,INS,INT,JRL,LNE,PGM,RUS,STG,TAS,TAW,YPE instead
of four.
Thanks to Keith A. Immink, Whirlpool Corporation, USA.
Thanks to Roger Edwards, South Carolina Electric and Gas Co, USA.
Change 06.169 Support for Network System's Channel Extension equipment
EXHO15LK sequential file creates the HO15LINK and HO15TRNK data
EXHO15TK sets in this user contribution. See comments in TYPEHO15.
TYPEHO15
Dec 5, 1988
Thanks to Rodney L. Reisch, General Electric Plastics, USA.
Change 06.168 VM/SP Monitor data sets VMONCU and VMONDEV are created if
VMACVMON there was activity or queueing (formerly only activity
Dec 1, 1988 caused an observation in CU, and no-activity DEV records
created useless observations. More important, the data in
VMONCU is now merged with VMONDEV into a revised VMONDEV
data set which now contains new useful variables IORATE
PCTQUEDV, PCTQUECU, and MSPERIO (millisec of queue and
service per IO).
Thanks to Ron Roberts, The Equitable Life Assurance Society, USA.
Change 06.167 TSO/MON data set TSOMCALL KEEP= list contained variables
VMACTSOM NRTRIV1-NRTRIV8 which should have been NTRIV1-NTRIV8 to
Nov 28, 1988 KEEP the variables actually inputted!
Thanks to Ed Shigo, Plaza Technology Corp, USA.
Change 06.166 DB2 trace record. In VMAC102 after INPUT QWPZBPID PIB2.
ANALDB2R insert +2 and change next two fields from PIB2. to PIB4.
VMAC102 In ANALDB2R, reverse QWPZTOUT and QWPCISWT lines 2550-53
Nov 28, 1988 and line 2506 QWPZDBC should be QWPZAUTH.
Thanks to Ervin Claxon, Great Western, USA.
Change 06.165 NPM exception variables NPMDATA,NPMMONVL,LNAMLIM,NPMLOWER
VMAC28 and NPMUPPER were not created in NPMEVNCP or NPMEVNET.
Nov 23, 1988 Added to _VA28NAM list, and INPUT (PIB1.,+2,four PIB4.).
Thanks to Doyle Hanel, Compass Computing, USA.
Change 06.164 Support for CICS Version 2 Release 1 CMF Monitor Facility
IMACPTF verified by examination of the SC33-0507-0 Customization
Nov 22, 1988 Guide. Since IBM chose not to change SMFPSRVR's value, it
is not possible to differentiate between CICS 1.7 and 2.1
CMF records. Thus you must still update IMACPTF to tell
MXG the "pft's" installed as described in IMACPTF. There
are no significant changes documented in 2.1.
Change 06.163 Support for DB2 Version 2 Release 1 changes to type 100 &
ANALDB2 101 record added new variables:
VMACDB2 Data set DB2STAT0 (Type 100):
Nov 21, 1988 Q9STCTRE,Q9STCTRF,Q9STCTRG,Q9STCTRH
QWSDLR ,QWSDSCA ,QWSDSCU ,QWSDSCCO,QWSDSCRA,QWSDSCRS
QWSDSCWR
Data set DB2STAT1 (Type 100):
QXSETSQL,QB1-4TMIG,QB1-4TRTO,QB1-4TPIO
QTXASLMT,QTXACLMT,QTXACHUS,QTXASLAT,QTXASOTH,QTXALOCK
QTXAUNLK,QTXAQRY ,QTXACHG ,QTXAILMT,QTXANRUN,QTXAPREC
QTXARLID,QTXASLOC
Data set DB2ACCT (Type 101):
QWHCOPID,QB1-4CIMW
Change 06.162 Several lines removed to make ANALDB2R executable under
ANALDB2R PC SAS. No logical changes were involved. Code still gets
Nov 21, 1988 an error message under PC SAS (NODSNFERR and NOVNFERR are
not yet supported in 6.03) but code does run (slowly!!!)
Change 06.161 Further comparisons of VM/XA Monitor data uncovered two
VMACVMXA incorrect assumptions. SCMCNTIM, SCMFPTIM, and SCMDDTIM
Nov 18, 1988 (in VXIODDEV, connect, pending, and disconnect duration)
are in 128 microsec units, not timer units. RDEVRTPD (in
VXIODDEV, reserve duration) is ascending vice descending.
Thanks to Richard Steele, Louisville Gas and Electric, USA.
Change 06.160 Inserted ELSE PUT /; after line 2915 to put a blank line
ANALDB2R between DB2 AUTHID when only one plan was used.
Nov 18, 1988
Thanks to Allan Russell, SAS Institute Europe, GERMANY.
Change 06.159 -Change 6.129 was not fully tested, but only if you made a
BUILDPDB change to IMAC30IO does an error surface. Only MXG 6.5
BUILDPD3 was affected. In IMACPDB, after MACRO _SUMSTP replace the
IMACPDB lines EXCP thru IOTM with _IO30EX EXECTM _IO30TM after
IMAC30IO MACRO _MAXSTP change D3330DRV to _IO30DR, and after MACRO
VMAC30 _PDB30_4 add IOTMERR just before _IO30IO. In IMAC30IO,
Nov 28, 1988 remove IOTMERR. In VMAC30, add IOTMERR after INPRTY and
before _IO30IO in all three places.
-Change 6.150 created _CICACCT macro to control the DDname
to which CICSACCT dataset is written, but BUILDPDB/3 had
a temporary reassignment of _CICACCT to WORK, built the
WORK.CICSACCT data set in your WORK file and then SORTed
that data set to your _CICACCT.CICSACCT destination. With
large volume CICSACCT data sets this caused problems in
the size of the WORK data set. If you had wanted to use
a tape data set for CICSACCT, you still needed that much
DASD work space for sorting!
With this change, the CICSACCT data set is created direct
into the _CICACCT ddname and is not sorted in BUILDPDB/3.
If you set _CICACCT (in IMACCICS) to PDB, then BUILDPDB
will create PDB.CICSACCT (unsorted) you your PDB.
If your report programs expected CICSACCT to be sorted,
you may have a compatibility problem; you can use the PDB
exit member EXPDBOUT as follows to sort the dataset:
For a sorted CICSACCT dataset in the PDB on DASD:
Set _CICACCT to PDB in IMACCICS.
Then in EXPDBOUT, add:
PROC SORT DATA=_CICACCT.CICSACCT OUT=_CICACCT.CICSACCT;
BY whatever-variables-you-want;
For a sorted CICSACCT dataset on tape DDNAME of MYDATA:
Set _CICACCT to UNSORTED in IMACCICS.
Then in EXPDBOUT, add:
PROC SORT DATA=UNSORTED.CICSACCT OUT=SORTED.CICSACCT;
BY whatever-variables-you-want;
(When you put _CICACCT on tape, you cannot use the
same DDname for OUT= (you can't sort a tape onto
itself), and must use two tape DDnames, SORTED and
UNSORTED, cataloging SORTED and deleting UNSORTED.)
This is an impacting change for BUILDPDB/3 users.
Remember that if you don't want CICSACCT observations at
all, you can forget all of this stuff, comment out the
OUTPUT _CICACCT.CICSACCT statement in EXCICACC, and cause
zero observations to be created from the accounting data!
Thanks to Tracy Blackstone, Kaiser Permanente, USA.
Change 06.158 Member IMACJBCK allows SMF data for only selected job(s)
ANALALL to be processed; its comments were made clearer. It is
IMACJBCK now included in VMAC41 and VMAC6156. A new analysis is
VMAC41 added in ANALALL which will select all SMF records from
VMAC6156 a job, store the records in a SAS library, and will also
Nov 12, 1988 print all observations of all datasets in a SAS library.
This is a collection of several utilities I have found
useful in examining specific job detail resources.
Change 06.157 RMF 4.1.1 creates Monitor III data in new subtype 2 of a
BUILDPDB type 72 record, which creates the new TYPE72MN dataset.
BUILDPD3 TYPE72MN is also created by BUILDPDB/3, and in the PDB it
VMAC72 is sorted by SYSTEM STARTIME PERFGRP. The RMF Monitor III
Nov 11, 1988 data is created for each PERFGRP and contains counts of
initiated, active, idle, out-ready, and DIV users, counts
of users delayed due to paging or swapping, pagein rate,
and memory usage (both total frames for the PERFGRP and
average frames per category of user) for frames held by
active, idle, out-ready, DIV users, ASM slots in use, and
fixed frames for the PERFGRP. For all memory measures,
(frames or slots) MXG has converted to bytes and uses the
MGBYTES format to show the memory measure in KB, MB, etc.
for more direct comparison of values.
Change 06.156 Support for the Hiperspaces in RMF 4.1.1 added two new
VMAC72 variables to TYPE72: HIPPGINS,HIPRDMIS (HIPER pageins and
Nov 11, 1988 read misses) by performance group period.
Change 06.155 Support for the Hiperspaces in RMF 4.1.1 added eight new
VMAC71 variables to TYPE71: HIPMIGRS,HIPREADS,HIPWRITS pagerates
Nov 11, 1988 migrated, read and written to/from ESTORE; HIPAGINS and
HIPAGOUT HIPER pageins/out, and HIPEXAV,MN,MX (average,
minimum and maximum HIPER pages in ESTORE).
Change 06.154 Support for VIO paging into ESTORE (implemented by PTFs
VMAC71 for APAR OY09186) added six new variables to TYPE71:
Nov 11, 1988 VIOMIGRS,VIOREADS,VIOWRITS (VIO page rates migrated, read
and written to/from ESTORE), and VIOEXAV,MN,MX (average,
minimum and maximum VIO pages in ESTORE).
Change 06.153 Support for the 3990-3 Cached DASD Controller CRR SMF
EXCAC90 data, "Cache DASD RMF Reporter" creates a new dataset
IMACACHE CACHE90 with new variable names, although it is quite
VMACACHE similar in structure to the existing CACHETY dataset
Nov 9, 1988 from the 3880-23 controller.
Thanks to John Chase, ???.
=============Changes thru 6.152 comprised MXG 6.5 pre=release =======
Change 06.152 MXG 6.5 Quality Assurance runs uncovered these glitches.
IMACKEEP Most were detected by specifically designed enhancements
TYPEVM to the UTILXREF cross reference utility.
VMAC535 a.@OFFSET+95 removed from INPUT TERMNAME in VMAC535.
DOC b.Extraneous % removed from IMACKEEP.
Nov 2, 1988 c.DEVICE renamed to DEVICEOR in new VMRSCS data set built
from VM/ACCOUNT data to avoid length conflict.
d.Variables with blank labels now have a label. In some
instances the label is simply the variable name, but this
ensures that a variables was not overlooked.
e.Some DATETIME variables were discovered to have length 4,
which caused a loss of the low-order resolution (seconds)
and now UTILXREF catches this coding error.
f.The most pervasive change touched every member which had
a character variable with a $MG.... format. Because MXG
located the FORMAT statement ahead of the INPUT statement
(so the source code reads better), and because SAS does
not work as I thought it did, the stored length of these
character variables in a FORMAT statement was taken by
SAS from the FORMAT statement, rather than being set by
the actual INPUT statement (as documented). The result
was that 8-bytes were being used where only 1-byte was
needed. The circumvention was to insert the affected
character variable in a LENGTH statement preceding the
FORMAT statement with the correct length (not all were 1
byte!). A problem has been opened with SAS to correct the
"design feature". If the character format is unknown in
the SAS System (eg, all $MG formats), SAS picks a length
of 8-bytes for the variable. Note, however that:
DATA;FORMAT X $HEX20.;INPUT X $1.;
causes SAS (mainframe and PC) to used 10 bytes storage
for the one byte variable.
g.All members touched by these LENGTH, FORMAT and LABEL
corrections were renumbered.
Change 06.151 The new PGPAGEIN and ACTFRMTM variables (page-ins and the
RMFINTRV resident frame-seconds by performance group period, new
Nov 2, 1988 with RMF 4.1 in TYPE72) look to be so useful that they
are now created in the RMFINTRV data set as rates by each
workload: BATPGIN,TSOPGIN... and BATFRTM,TSOFRTM, etc.
Change 06.150 Support for ROSCOE 5.6 added new variable USRPRFIX to the
VMACROSC ROSC.... accounting data sets. Another new field, record
Nov 1, 1988 version, is in the data record but not kept in MXG, as it
is there to identify future changes in their record.
Thanks to Paula Bryan, Ohio Edison, USA.
Thanks to John Carafella, CA (ex-ADR), USA.
Change 06.149 Reference to variable PRTY should have been PRTYJOB in
ANALDOS this DOS report example member.
Oct 30, 1988
Merci a M. Bernard, CRCAM de L'Aude, France
Change 06.148 All four CICS data sets built from type 110 CMF data can
EXCICACC now be directed to separate DD names. The existing macro
EXCICEXC _CICTRAN was unchanged, but the single _CICOTHR macro for
EXCICTRN CICSACCT, CICSEXCE and CICSYSTM data sets is replaced by
EXCICSYS _CICACCT, _CICEXCE, and _CICYSTM (defined IMACCICS with
IMACCICS the same default as _CICOTHR had). This change was needed
VMAC110 by some sites to split CICSACCT data away from the other
Oct 29, 1988 data sets.
If there is an IMACCICS member in your USERID.SOURCLIB
library, you MUST replace it with IMACCICS from this MXG
version so that _CICACCT, _CICEXCE, and _CICSYSTM exist.
If there is an IMACKEEP member AND you have overridden
the _VAR110 definition therein, you must prefix the data
set names CICSACCT, CICSEXCE and CICSYSTM with the new
macro names to avoid potential compatibility exposures
The syntax required is:
_CICACCT . CICSACCT
_CICEXCE . CICSEXCE
_CICYSTM . CICSYSTM
Change 06.147 CICSTRAN variable TRMCHRCN (intended to be total chars to
VMAC110 and from terminal) has always been too large. It was the
Oct 29, 1988 sum of in/out chars for both primary and secondary (alt).
Primary are actual chars transmitted, but secondary is
primary characters plus IRC control characters to/from a
remote region or system-to-system. Now that I know whats
in PRIINCHR,PRIOUCHR,SECINCHR, and SECOUCHR, TRMCHRCN is
the sum of only PRIINCHR and PRIOUCHR.
Thanks to Dale Doolittle, Barnett Computing Company, USA.
Change 06.146 Variable SU_SEC (from TYPE72, indicates processor speed)
RMFINTRV is now added to data set RMFINTRV to make normalization
Oct 29, 1988 of CPU times more reliable.
Change 06.145 TYPE74 variables PCTPNCHA, PCTPNCUB, and PCTPNDEV were in
VMAC74 the MXG Supplement (page 434) but not created nor kept in
Oct 29, 1988 the data set. Now they are.
Thanks to Myles McCarthy, Fidelity Systems, USA.
Change 06.144 Incorrect assembly of CICS 1.6 MCT after PTF UL10276 that
VMAC110 changed FCAMCNT length from 2 to 4 cause short record to
Oct 28, 1988 be written. MXG circumvents with new line 390.1:
IF _UL10276 THEN EXPLEN=EXPLEN+2;
Thanks to Greg Goshia, Westfield Companies, USA.
Change 06.143 Line 269 should be +145 instead of +158 for the NETSPY
VMACNSPY variable XDOMAIN to be correct.
Oct 28, 1988
Thanks to Gary Zolweg, National Semiconductor, USA.
Change 06.142 A missing END statement in EPILOG CL 1000 code causing
VMACEPIL a syntax error was detected and corrected at 44700 (after
Oct 25, 1988 the statement BIETIME=BIETIME+CIGMTOFF;).
Thanks to Bruce Groeber, City Federal Savings, USA.
Change 06.141 "Nearly final" validation of VM/XA SP 1 and SP 2 corrects
VMACVMXA several variable's values, revised the reports to fit on
Oct 25, 1988 one line, added IODDEV summarization of I/O data into the
VMXAINTV data set, added and renumbered the 35 reports.
The logic for USER data was re-written to keep the first
user interval instead of deleting it (to capture the CPU
time to first interval).
Change 06.140 Continued enhancement of DB2PM-like reports added and a
ANALDB2R revised version of GRAFRMFI which restores the GROUPing
GRAFRMFI which was lost pending a zap from SAS.
Oct 25, 1988
Change 06.139 CICS reports from Landmark's Monitor are now produced by
ANALMONI ANALMONI just like ANALCICS reports from IBM's CICS CMF.
TYPEMONI (Neither are anything to write home about, and will be
Oct 25, 1988 further enhanced in the future.) TYPEMONI was further
enhanced after Landmark 7.1 testing, and the logic in
de-accumulation of MONISYST re-written to properly take
in multiple systems data.
Thanks to Oystein J. Blix, Televerkets, Oslo, NORWAY.
Change 06.138 Support for SAS user SMF record (written by SAS provided
EXTYSASU exit described partially in SAS publication Y-103R which
IMACSASU is being re-written). The TYPESASU data set reports on
TESTUSER each DATA and PROC step's resource usage in a SAS job.
TYPESASU
VMACSASU
Oct 25, 1988
Change 06.137 Format MGBYTES now will handle Gigibytes and Terabytes
FORMATS (9999G and 9999T) if that many bytes are encountered (as
VMACDB2 was found in a VM/XA sites total paging space). DDNAME=
VMAC102 in PROC FORMAT is now LIB= (for PC-SAS and future).
Oct 24, 1988 New formats were added for QWHSIID and QWHSRMID variables
for DB2 Instrumentation ID and Resource Manager ID. Line
476 in VMAC102 was changed to RETURN from DELETE (with no
explicit OUTPUT statement, DELETE fell thru.)
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 06.136 Variables EXECTM and ELAPSTM for subtype 2 and 3 type 30
VMAC30 interval records (in dataset TYPE30_V) now are duration
Oct 20, 1988 of this interval, rather than from initiation of step.
Thanks to Marty Rhodes, Hertz, USA.
Change 06.135 Perverse issuance of VARY CPU command on all CPUs in one
RMFINTRV interval causes NRCPUS to be zero, causing zero divide!
VMAC7072 Now, test before divide is made where needed!
Oct 17, 1988
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 06.134 IDMS TYPERTE data set variable RT1DCTUT (User CPU time)
VMACRTE for IDMS transactions which came from CICS using UCF (ie.
Oct 17, 1988 application code executes under IDMS, CICS is used only
as a terminal handler) was incorrectly recalculated in
lines 823-824 (apparently a circumvention from the past).
The re-calculation was eliminated.
Thanks to Myles McCarthy, Fidelity Savings, USA.
Change 06.133 IMS Log processing END= logic lost the last record of the
TYPEIMS raw log datasets, causing missing values in at most six
Oct 17, 1988 observations in IMSTRAN data set.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 06.132 More DB2PM-like reports and enhanced friendliness are in
ANALDB2R this self-documenting replacement member.
Sep 26, 1988
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.131 The MXG error message text was changed to be more precise
IMACACCT if you encounter more job accounting fields than you told
Sep 26, 1988 MXG to expect.
Thanks to I. M. Ajzenszmidt, Australian Bureau Meterology, AUSTRALIA
Change 06.130 Support for Fujitsu's FACOM OSIV/F4 SMF data, due to
EXAIM.. major code contributions from the below named authors.
EXF1 Several classes of FACOM data records written to SMF are
FORMATS added by this change. First, PDLF (Performance Data Log
IMACFACO Facility) creates the type 127 SMF interval record; MXG
TESTFACO creates four TYPE127x datasets from member TYPEF127.
TYPEAIM. Second, FACOM SMF records type 1 and DSPRINT type 234
TYPEF... create datasets TYPEF1 and TYPEF234 datasets. Third, AIM
VMACAIM6 (Advanced Information Manager) database manager creates
VMACEXC2 type 110,111,112,113,116, and 117 SMF records which MXG
VMACF1 processes into 22 AIM11n_x datasets with member TYPEAIMx.
VMACUCB Fourth, VMACEXC2 and VMACUCB were modified to support VIO
XPDLPDA from FACOM MSP/E20 data (although you must edit IMACFACO
Sep 25, 1988 member to tell MXG you have MSP), and were also modified
to recognize 6421 disk devices in TYPE30xx, TYPE40, and
TYPE434 and PDB.STEPS and PDB.JOBS data sets. All other
SMF record written by FACOM appear to be compatible with
MXG SMF support. Twenty-eight new MXG datasets were added
by this change. Member TESTFACO (now a part of JCLTEST)
builds all FACOM data sets and is also presently the best
documentation. If Fujitsu will provide the format of the
PDL log data set, that data source will also be supported
but in the interim, if you have the PDA report program,
you can use XPDLPDA to read the report output format and
create PDL datasets much like I hope to build directly.
Thanks to David Fahey, Databank, NEW ZEALAND.
Thanks to Andrew J. Hood, Reserve Bank of Australia, AUSTRALIA.
Change 06.129 New member IMAC30IO defines a new macro _IO30IO which
IMAC30IO controls which I/O device counting variables (EXCP....,
IMACPDB IOTM....) are kept in the TYPE30_V, TYPE30_4, TYPE30_5,
VMAC30 TYPE434 and TYPE40 and PDB.STEPS and PDB.JOBS datasets.
VMAC40 No variables were removed from the previous default, but
VMAC434 the FACOM 6421 device was added (to be consistent with
Sep 25, 1988 the MXG default of keeping all possible variables). This
centralized control has been long overdue and should make
your life simple when you add/delete device classes in
the future. You should tailor this member for your site.
(To not keep the non-existent IOTM.... variables in the
TYPE434 and TYPE40 data sets, _IO30IO is actually made
up of _IO30DR (drive count), _IO30EX (EXCP variables),
and _IO30TM (IOTM variables). TYPE434 and TYPE40 use
only _IO30DR and _IO30EX so as not to change the size
of these obsolete data sets.)
Change 06.128 Support for Boole & Babbage IMF Release 2.5 was added. A
EXIMFDB2 new CIMSDB2 dataset, with one observation per transaction
VMACCIMS that accesses DB2 data, is created to count SQL activity.
Sep 23, 1988 Nine new variables (CPUDB2TM,EXTSSID,IMEUTRN,MSGDRRN,
PROGRAMB,TRNFCNT,TRNRESP,SQLCALL, and SQLCALLS) are added
to CICSTRAN data set. Fourteen new variables (BHTOON,
BILLOVHD,BMPNO,CPUDEP,CPUMDLTM,CPUNONE,DBIONONE,DBIOWAIT,
DEPRECN,EXTSSID,IMEUTRN,RGNIOPT,SQLCALL, and TRNSYNC, all
but two are one byte Y/N flags) are added to CIMSPROG,
and CPUMSKTM was renamed CPUCSKTM in CIMSPROG to reflect
that it is control region, not message region CPU time.
Not only did Boole provide documentation before shipment
of the new version, they also provided actual test data
for validation!!!! The major impact of IMF 2.5 is its
capture of DB2 resources used by IMS transactions, and
the ability to identify SQL activity for DB2 under IMS.
Note that the rename of CPUMSKTM to CPUCSKTM in CIMSPROG
requires you to make the same change, if you actually use
that variable in your IMS reporting.
Change 06.127 Zero divide error in NETSPY because test X2='80'X in line
VMACNSPY 358 to decrement TRANSNO should be X2='.1......'B. Also
Sep 23, 1988 this change added variable VLU (for virtual LU to applic.
session), sets SESSMGR only for session manager to applic
session, and no longer calculates targets if SESSMGR, as
targets are not only inappropriate, but data not valid.
It was interesting to note that NETSPY created 842 tracks
of 121,986 SMF records, but MXG needed only 479 tracks to
store 73,491 LU, 64691 LINE, 1935 APPL and 544 NCP obs,
or 40MB SMF was stored in 22MB of SAS data libraries.
Thanks to Gary Zolweg, National Semiconductor, USA.
Change 06.126 Pre-release 6.4 spelled SQAFXMX as SQAVXMX in the KEEP
VMAC22 list for TYPE71 data set, and the second LSQAEXAV in the
VMAC71 KEEP list for TYPE71 should be LSQAEXMX. In VMAC7072 the
VMAC7072 variable TOTIORAT should not have been in the KEEP list
VMAC78 (TOTIORAT was replaced by IORATE, but the name was still
Sep 26, 1988 in the KEEP= list. Since TOTIORAT was never referenced,
it never existed in the data set. SAS does not validate
that variables in a KEEP= list actually exist (though it
does validate the KEEP statement) and MXG exploits this
ability to have a variable in the KEEP= list which is not
kept if it is not created in the code. However, in this
case, that was not intended!). Also in VMAC7072, SMFTIME
was added to TYPE70PR data set. (I really don't think it
should be, since STARTIME is the analysis time stamp to
be used, and STARTIME+DURATM provide the ENDTIME, but as
SMFTIME is redundantly in TYPE70, it makes sense to keep
it also in TYPE70PR for consistency.) In VMAC22 dataset,
VMAC78, the test (to prevent divide by zero) in line 1723
should be CHPIDTKN+PCTCUBSY; occasionally a missing value
for PCTCUBSY resulted when it could have been calculated.
Thanks to Roger Drabyk, Manitoba Data Services, CANADA.
Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Thanks to Jan van Lent, Sokker, NETHERLANDS.
Change 06.125 CICS program compression count and duration, PCCMPRCN and
VMAC110 PCCMPRTM were in the wrong KEEP= list, and thus were not
Sep 21, 1988 kept in CICSYSTM dataset. Remove the two variables from
CICSTRAN KEEP= list and add them to CICSYSTM KEEP= list.
To summarize CICS variables which deal with compression:
CICSYSTM contains the interval count and duration of the
compressions (PCCMPRCN,PCCMPRTM) and the number of bytes
compressed (PROGCOMP) during the interval. If you want to
know which transactions were compressed, the detail data
is in the CICSEXCE exception data set variables PGMCMPCN
and PGMCMPTM. Compression is not reported in CICSTRAN.
(Note however, that there could have been non-zero values
of PCCMPRCN and PCCMPRTM in CICSTRAN before this change.
The values would have been wrong and were being carried
forward incorrectly from the prior CICSYSTM record.)
Thanks to Jim Gilbert, Texas Utilities, USA.
Thanks to Gary Smith, Southern California Edison, USA.
Thanks to Ken Thomas, Maryland Casualty Company, USA.
Change 06.124 NPM 1.3 TNL SN25-2063 to SH20-6361 describes 5 segments
EX028CM4 and 14 subtypes not in the original type 28 appendix. The
EX028CM5 change creates four new data sets (NPMCMDRN, NPMCMNSA,
EX028IN8 NPMINNSA, and NPMNPTAK) and expands the documentation in
EX028NTK comments at the beginning of VMAC28. MXG support for the
VMAC28 type 28 SMF record now creates 28 data sets from the 53
Sep 21, 1988 subtypes containing from one to three of the 31 different
data segments. The five new segments (BAN, BAS, DRN, MSA,
and NTK) have been syntax checked, but no data for these
segments has yet been encountered.
Change 06.123 The OPERATOR variable in CICSACCT for CICS 1.7 is wrong.
VMAC110 CICS 1.6 contained a 3-byte OPERATOR field in CICSACCT,
Sep 20, 1988 CICSEXCE & CICSTRAN data sets. CICS 1.7 introduced a new
8-byte USER field, but also carries a 4-byte OPERATOR
field in EXCE and TRAN (but not in ACCT!). This made the
MXG variable OPERATOR in CICSACCT for CICS 1.7 either a
blank or the value from the prior CICSTRAN observation.
(To further complicate the matter, OPERATOR in CICSTRAN
and CICSEXCE does not match the first four bytes of USER;
the fourth byte of OPERATOR is null (hex 00) but the 4th
byte of USER is a character! This problem was fixed for
CICSACCT under 1.7 by now storing USER into OPERATOR (it
should have been set blank since it does not exist, but
this way you might not have to change reports that use
OPERATOR from CICSACCT. For CICS 1.7, you really should
use USER instead of OPERATOR in all your reports.
With both 1.6 and 1.7, you can still change your
reports from OPERATOR to USER, and can insert
IF SMFPSRVR LT 3 then USER=OPERATOR;
in MXG exit members EXCICACC, EXCICEXC and EXCICTRN
and therby put the 3-byte OPERATOR value from CICS 1.6
applications into the 8-byte USER variable.
Thanks to Tom Elbert, John Alden Life Insurance Co, USA.
Change 06.122 NPM 1.3 defined multiple fields at same location in STT.
VMAC28 Insert line 947.1 @; IF NPMSUBTY EQ 20X THEN INPUT
Sep 20, 1988 insert line 949.1 @; ELSE IF NPMSUBTY EQ 30X THEN INPUT
and change lines 950-951 from PIB4. to PIB2.
so that TOTLOVER/TOTLOSSQ are read for subtype 20x and
OBJPERCT/OBJCNTNR (now PIB2.) are read for subtype 30x.
Thanks to Bob Smith, Nissan Motors, USA.
Change 06.121 Incorrect test in NPM 1.3 type 28 record caused some CDS
VMAC28 segment data to not be read for subtypes 31x thru 35x.
Sep 14, 1988 In line 691, change LE 35 to LE 35X
Thanks to Bob Smith, Nissan Motors, USA.
Change 06.120 Boole's IMF ARRVTIME field for a fastpath record actually
TYPECIMS contains INPQUETM duration! (Sure glad this user found it
Sep 13, 1988 but sure wish the vendor had told me first!)
Insert six new lines:
IF PROGTYPE='F' THEN DO; 428.1
INPUT @113+OFFIMS INPQUETM RMFDUR4. @; 428.2
ARRVTIME=STRTTIME-INPQUETM; 428.3
END; 428.4
ELSE DO; 428.5
END; 434.1
Thanks to John Donoghue, Bank of Ireland, IRELAND.
Change 06.119 Variable PGMLODTM, "Program*Loading*Duration" was added
TYPEIMS in line 1007, immediately prior to STRTTIME=GUTIME
Sep 9, 1988 PGMLODTM = GUTIME - STRTTIME ;
PGMLODTM is included in the calculated INPQUETM. This
new variable allows identification of IMS programs with
a large load time (often due to poor loadlib blocksize).
==========Changes thru 6.118 were the real 6.4 pre=release===========
Change 06.118 The first prerelease of 6.4 was insufficiently tested.
BUILDPDB 1.BUILDPDB line 74, remove SMFTIME from BY list for SORT
BUILDPD3 of TYPE70PR.
VMACSYNC 2.BUILDPD3 line 78, remove SMFTIME from BY list for SORT
VMAC74 of TYPE70PR.
VMAC102 3.VMACSYNC line 213, add SORTBEGN SORTEND to be LENGTH 8.
Sep 9, 1988 4 VMAC74 line 3451 for MVS/ESA should be GE 100 instead of
GE 99, and line 3452 should be INPUT DASDRCFG instead of
INPUT @LENDDSS+84 DASDRCFG.
5.VMAC102 insert new line after 440:
LENGTH QWHSSTCK 8;
Thanks to Dave Greene, Kwasha Lipton, USA.
Thanks to John Thai, Health Insurance Commission, AUSTRALIA.
========Changes thru 6.117 were a limited pre=release of 6.4=========
Change 06.117 The PR/SM data set TYPE70PR is now created by default in
BUILDPDB both BUILDPDB (JES2) and BUILDPD3 (JES3) PDB libraries.
BUILDPD3 Non-zero observations will exist only if PR/SM data is
RMFINTRV found in your SMF data. (There is essentialy no cost to
TYPE7072 SAS to build a zero observation data set.) In addition,
Sep 6, 1988 the variable PARTNCPU (the number of physical processors
available to this partition) has been added to data sets
TYPE70 and TYPE70PR data sets (both in TYPE member code
and in the PDB and RMFINTRV built data sets).
Thanks to George Scott, Rockwell International Corporation, USA.
Change 06.116 IMS log record processing has been completely redesigned
IMACIMS to capture actual transaction response. Prior MXG logic
TYPEIMS created an observation for each program schedule event,
VMACIMS even though many transactions may have been processed
(each with its own response time) by a single schedule.
Sep 6, 1988 This complete re-design recognizes individual transactns
and calculates individual responses. Since there still is
only one 07 log record with CPU and DL/I counts, they are
averaged across the multiple transactions per schedule.
Pete tested with IMS 2.1. IMS 2.2 log changes were then
put in, and tested with independent 2.1 and 2.2 data from
two sites with IMF data for comparison. Log processing
will never be as accurate as Boole's IMF monitor data,
(IMS log time stamps are only to .1 sec), but this new
design matches transaction counting exactly and appears
to accurately capture IMS response time nearly as well
as does IMF. In addition, Pete found excellent match to
NETSPY measured response time in his production world.
As this is a major re-design, check it out for yourself
and call us for any new info from other MXG users as the
re-design becomes more widely distributed in MXG 6.4.
Note that the 6.3 code (which supported IMS 2.2 with the
old algorithms) was copied into the Z....... members just
in case you want to compare.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 06.115 EXPLORE/VM (a product of Goal Systems) data is processed
IMACVMXP with this contributed enhancement. Comments in TYPEVMXP
TYPEVMXP discuss how to invoke this code to read the EXPLORE DD
VMACVMXP and create the six VMXP.... data sets. This code has not
Sep 1, 1988 been validated with data in Dallas, but it has been in
use for some time by its author.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 06.114 An additional daily report from VM SP monitor data is now
ANALVMDY in member ANALVMDY which is included by EXECDALY.
Aug 24, 1988
Thanks to Steve Glick, Southern Methodist University, USA.
Change 06.113 The average Definite Response AVGDRSP is now calculate in
VMAC28 appropriate NPM data sets (along with AVGHOST, AVGNETW
Aug 24, 1988 and AVGOPER previous calculations).
Thanks to Ron Clark, Chemical Bank, USA.
Change 06.112 The DOS POWER Account Version default was externalized in
IMACDOS new member IMACDOS. The default now expectes DOS VSE SP2
TYPEDOS Release 1.3 or later format data. Comments in IMACDOS
Aug 22, 1988 describe how to change to process earlier version data.
Thanks to Dick Whiting, Precision Castparts, USA.
Thanks to Bruce Groeber, City Federal Savings, USA.
Change 06.111 Continued validation and documentation expansion enhanced
VMACVMXA the VM/XA monitor support. Protection to delete duplicate
Aug 30, 1988 data was added. The VXIODDEV data set now contains an obs
only if there was activity to the I/O device during the
interval. The NODUP option was added to delete duplicate
input data records (which can happen if MONWRITE outputs
are repetitively concatenated). If MONWRITE fills a mini
disk, data blocks are lost. Concatenation of that file to
later MONWRITE output caused the new control interval
record to be swallowed as if it were the missing data
blocks! MXG now looks for and corrects this situation.
Twenty-eight reports are now created (by default with the
_VMRPT or nnth with _VMRPTnn invocation) from VMXAINTV.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.110 This JCL example was less than clear, as it contained the
JCLPDB SOURCE option twice. It is now clearer.
Aug 22, 1988
Thanks to John Kenworthy, Naval Military Personnel Command, USA.
Change 06.109 The GMT offset added to EPILOG CL 1000 V430 records is
VMACEPIL now decoded correctly and is added to the record times to
Aug 12, 1988 produce local time-of-day timestamps in MXG data set.
Change 06.108 The ACCOUNT data set (which contains PDB.JOBS variables
BUILDPDB that are to be "back-merged" into PDB.PRINT and PDB.STEPS
BUILDPD3 is no longer deleted by BUILDPDB, making it available for
Aug 10, 1988 your own use, if needed, following BUILDPDB logic.
Change 06.107 Correct a syntax error (period should be semicolon) and
WEEKBLD eliminate the non-existent PRENTIME variable in the BY
Aug 10, 1988 list for PDB.PRINT.
Thanks to Paul Bergman, Prudential, USA.
Change 06.106 VM/XA SP1 data from several sites has been used to update
VMACVMXA processing logic. The VXBYUSR user interval data is now
Aug 10, 1988 built from VXUSEACT and VXUSEINT data sets with logic to
recognize new sessions unambiguously eliminating negative
deaccumulations in the user data. (Negative delta values
were due to either insufficient delta logic or from two
byte counters which wrapped.) With additonal test data,
it has been possible to validate which fields really are
accumulated and additional variables are now correctly
DIF()'ed.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Thanks to Vic Fadool, Health Net Corporation, USA.
Thanks to Julie Roland, IBM Kingston, USA.
Change 06.105 MXG has been tested under SAS Release 5.18 and there are
EXITMONI three problems which induced MXG circumventions:
GRAFRMFI a.The EXITMONI member which assembles the TMON INFILE exit
IMACPDB (decompression algorithm for Landmark's CICS data) must
Aug 12, 1988 be re-assembled, using the SAS 5.18 macro libraries. The
internal filetable used by the SAS ASM macros increased
by 16 bytes. You cannot use the load members built with
5.16 macros under SAS 5.18, and the load members built
with the 5.18 macros cannot be used under SAS 5.16! You
can link the load modules into your SAS load library, or
keep two separate load libraries for the exit. The MXG
instructions for EXITMONI are on pages 59-60 of the MXG
Supplement, but only the BMACLIB library (file 22 on the
SAS distribution tape, unloaded by JCL in BTSOSRC in the
SAS JCL control library) is now required for the exit.
b.The KILL with PROTECT= option of PROC DATASETS no longer
works in SAS 5.18 (it was an un-documented feature - see
SAS User's Guide page 877.) Unless you have enabled the
PROTECT= feature (by removing comments in IMACPDB), SAS
5.18 has no problem. The change to PROC DATASETS removed
KILL and now requires a DELETE statement naming each data
set with PROTECT= to be deleted. Member IMACPDB now has
the necessary explicit PROC DATASETS code for those who
have chosen to protect their PDB data sets. In addition,
the (PROTECT=ZZZZZ) string has been externalized into a
new macro _PROTECT defined in IMACPDB so that you can go
either way easier.
If I had to do it over, I would never have used the
PROTECT= option in BUILDPDB. Protection was a holdover
from the days when SAS data sets were members of PDSs
and it helped avoid B37 abends and PDS dead space. If
I could I would make no-protect the default in MXG now
but that would require all existing sites to either
scratch and re-allocate each PDB data set or to run a
separate PROC DATASETS (from IMACPDB).set. So to avoid
the un-necessary work and exposure, PROTECT= will be
unchanged in future versions. PDB data sets now with
it still have it and no new protected data sets will
be created. Furthermore, IMACPDB lets you override any
way you want it. The following PDB data sets have been
and will continue to be built with PROTECT=ZZZZZ:
CICSACCT CICSEXCE CICSYSTM DDSTATS IPLS JOBS
PRINT SMFINTRV STEPS TAPES
TYPE70 TYPE71 TYPE72 TYPE73 TYPE73L TYPE73P
TYPE74 TYPE75 TYPE78 TYPE78CF TYPE78CU TYPE78IO
TYPE78PA TYPE78SP TYPE78VS
c.PROC GPLOT now sets an error condition if all values of a
variable are missing on a plot page. In 5.16 only a note
was printed. (Note this change was not made to the GCHART
CHART or PLOT procedures!) This has caused GRAFRMFI from
MXG 5.5 to ABEND if ERRORABEND is specified. SAS now has
a ZAP which restores GPLOT to its former self (the fix is
ZAP Z518.5694). The option NOERRORABEND has been added
to GRAFRMFI in case you have not installed that zap. In
addition, an unrelated, obscure logic error in the macro
logic in GRAFRMFI was uncovered and corrected.
d.GRAFRMFI exploited the GROUP statement so you could get
groups of graphs in batch (interactively, you simply
flag each graph to be grouped by PROC GREPLAY.) Changes
to the Graphic catalog in 5.18 and the lack of a way to
define "group" when building graphs has invalidated the
use of GROUP in GRAFRMFI.
---Changes through 6.104 completed the 7/27/88 2nd prerelease of 6.3--
Change 06.104 Pre-release VMXA code was not prepared to handle multiple
VMACVMXA "packets" of VM/XA monitor data from multiple monitor
Jul 26, 1988 sessions in one input file. Major changes were made to
the MXG logic to recognize the start of a new monitor
session in the de-accumulation logic. The data sets that
create the VMXAINTV consolidated interval data set have
been much more extensively validated, although there are
already twelve known problem areas under discussion with
IBM that I believe are problems in data (for example,
the Schedule records don't contain a processor address,
so it is impossible to validate them for guests which
allocate two or more virtual machines). VMXAINTV and the
sample data sets from which it is built seem to be okay.
However, VXIODDEV, VXSTOASP, VXUSEITE and all VXSCL...
data sets have occasional negative values as minimum,
and are under active investigation. Because VMXAINTV is
believed to be valid and useful, this tape was created.
Change 06.103 DB2 trace type 102 SMF record (new in 6.3) was not fully
ANALDB2R tested, causing FORMAT NOT FOUND errors.
FORMATS RENAME IMACDB2T to IMAC102.
IMACDB2T In member FORMATS change all occurrences of:
IMAC102 $MGDZDBC. to $MGD106C.
IMAC102A MGDZPID. to MGD106I.
IMAC102B In member VMAC102 change all occurrences of:
TYPE102 MG106I. to MGD106I.
TYPE102A In members ANALDB2R, IMAC102 (after RENAME), TYPE102 and
TYPE102B VMAC102 change all occurrences of IMACDB2T to IMAC102.
VMAC102 As documented in IMAC102, there are too many iterative DO
Jul 22, 1988 statements to build all T102.... data sets concurrently.
Members IMAC102A, IMAC102B, TYPE102A and TYPE102B create
half each and are used in JCLTEST and JCLUXREF for MXG
testing and to create DOCVER entries now.
Thanks to Scott Peterson, Southern California Edison, USA.
Change 06.102 ROSCOE 5.5 RTM response time data could be missing if the
ANALROSC SMF data was dumped after ROSCOE started. Change line 254
Jul 21, 1988 START=0; to read START=ROSTIME; to fix.
Thanks to Mike Doyle, Purdue University, USA.
Change 06.101 Member AAAAAAAA is a copy of member COPYRITE which will
AAAAAAAA be seen first if the MXG Source distribution library is
Jul 21, 1988 scanned (since that IEBUPDTE format is alphabetic). This
will simply make it clear what you've got.
Change 06.100 ACF2 sometimes contains ACTMFCBT data which is over 400
VMACACF2 bytes long, but MXG failed to protect, causing STOPOVER.
Jul 19, 1988 Find the line INPUT ACTMFCBX $VARYING200. ACTLTH @;
and change it to IF ACTLTH GT 0 THEN INPUT +ACTLTH @;
to skip over the excess data.
Thanks to Larry Cecil, First National Bank of Chicago, USA.
-------Changes through 6.099 completed the First pre-release of 6.3 -
Change 06.099 Bulk Data Transfer (BDT) variable SMF59NDT in line 184
VMAC59 is TODSTAMP8., not SMFSTAMP8 (although all other BDT
Jul 16, 1988 time stamps are SMF format!)
Thanks to Paul Walker, IBM, USA.
Change 06.098 Apparently a new release of NLDM has changed the size of
VMAC39 the accounting section. VERSNLDM was 000Dx, LENACCT=52.
Jul 16, 1988 Now VERSNLDM is 0014x, LENACCT=50, NLDMRSV1 removed!
On line 301 add @; after REVISION PIB2., replace 302:
IF LENACCT EQ 52 THEN INPUT NLDMRSV1 PIB2. @;
and add INPUT to beginning of line 303.
Thanks to Paul Walker, IBM, USA.
Change 06.097 NETSPY variables ARSPNET, T1RSPPC-T4RSPPC and OVRSPPC
VMACNSPY were sometimes "retained" into the next observation due
Jul 15, 1988 to lack of re-initialization. Now re-initialized.
Thanks to MP Welch, Sisters of Charity of the Incarnate Word, USA.
Change 06.096 Landmark's MONITOR data sets now have individual macro
EXITMONI names defined in IMACMONI which control the destination
EXMONDBD DDNAME to which the four data sets (MONISYST, MONIDBDS,
EXMONSYS MONITASK, and MONIUSER) are written, permitting the high
EXMONTSK volume data sets to be written directly to tape. The
EXMONUSR default DDNAMEs, WORK, were not changed. In the JCL for
IMACMONI the TMON exit installation (in EXITMONI), the DDNAME of
Jul 15, 1988 SYSGO should have been SYSLIN.
Thanks to Robert Manalo, EDS, USA.
Change 06.095 VM/XA SP1 data validation corrected several values and
VMACVMXA formats in the detail data sets. More important, this
Jul 12, 1988 change adds the VMXAINTV data set creation. This is the
consolidated interval data from the sample data from the
system, storage, processor and user domains. With about
228 variables per time interval, it will be the primary
source of VM/XA analysis, yet it holds 24 hours of half
hourly intervals in 1 track! Read comments in VMACVMXA.
Only simple sample reports are created now, but you can
expect more in the next pre-release. VMXAINTV should be
the primary data for investigation of VM/XA response,
resource utilization, etc. Note that the new response
measures provided are the average time and count of both
trivial and non-trivial interactions and are recorded in
two separate categories, UP and MP. CMS response will be
in the UP variables, while the MP variables contain the
response for MVS guests (or any other guest machines that
define more than one virtual CPU). Variables CALMP... and
CALUP... contain response information. CPU utilizations
are also calculated (PCT.....) to reflect overall CPU and
system versus user CPU utilization of all engines.
An unrealistically large test run (ALL possible records
from 60 intervals with 1500 active users from a 3090-600
created 100 MB of raw monitor data. MXG created all data
sets and all possible variables in 369 3090-600 CPU secs
and used 82 MB of 3380 DASD space. The VMXAINTV data set
was only 2 tracks! A smaller test sample (only 7 MB of
raw data) used 11 MB 3380 DASD and 55 3090 CPU seconds
to create all possible variables in all possible datasets
Change 06.094 NPMSLHTM should be input as PIB4.1 vice PIB4.2 to be
VMAC28 consistent with NPM 1.2 internal value, although this is
Jul 12, 1988 not documented by IBM and has not been fully confirmed.
Thanks to Henry Solomon, Merrill Lynch, USA.
Change 06.093 DOS variable LINES in keep list should have been LINEPRT.
TYPEDOS
Jul 12, 1988
Thanks to Jim Groseman, Duquesne Systems, USA.
Change 06.092 Support for NETSPY Release 3.1 added variables CCUNAME,
VMACNSPY LINENAME, and NETWADDR to the NSPYLU data set, along with
Jul 12, 1988 $MGNSPXD format addition and TRANSNO alteration based on
new flag bytes.
Change 06.091 Support for EPILOG 1000 (CICS) Version 4.30 added the GMT
IMACEPIL offset variable CIGMTOFF. Candle took our suggestion and
VMACEPIL created an INFILE exit named EPILOC that decompresses the
Jul 15, 1988 EPILOG CICS data. (Candle provides the documentation, the
ZAPs to SAS and the two load modules to be installed.)
Note that exit load moudules can be concatenated behind
STEPLIB or SASLIB libraries. After you install the exit,
you must then change the INFILE statement in MXG member
IMACEPIL (to add EPILOGC as described therein) to tell
MXG the exit exists.
Change 06.090 Still more undocumented treats from NPM 1.3. Line 1268
VMAC28 added test for NPDSUBTY EQ 041X to set AOFTYPE='NAD' to
Jul 11, 1988 read undocumented NAD(S) data and eliminate reams of
'AOF DNC-SESSION END' notes on MXG SAS log.
Thanks to Paula Lamphear, The Strohs Brewery, USA.
Change 06.089 NETSPY cluster and luname were not read for subtypes 10,
VMACNSPY 11, 20, 21, and 43 (hex). Line 412's ELSE IF statement
Jul 8, 1988 was expanded to add these additional five subtypes. Also
SECONDARY is now correctly spelled in line 179.
Thanks to Rodney L. Reisch, General Electric Silicon Products, USA.
Change 06.088 IMS 2.2 changes the location of the DEST field in IMS log
VMACIMS records type 35 and 36, as discovered by this MXG user.
Jun 29, 1988 The associated INPUTs are now conditional on the version
value (defined by you in member IMACIMS macro _IMSVERS).
Thanks to U. Guenschman, GEZ, Cologne, GERMANY.
Change 06.087 The MONITOR from Landmark accumulated CICS system data in
TYPEMONI MONISYST data set, which is deaccumulated into the actual
Jun 29, 1988 interval values by the ANALMON logic. This logic fails if
multiple CICS system's data was dumped (individually) and
then concatenated as input to MXG, because there is no
flag in the Landmark data to indicate a monitor startup.
This contributed change replaces the existing ANALMON and
heuristically detects a change in system to correctly
deaccumulate multiple-systems MONITOR data. (Note that
the original ANALMON macro still exists in TYPEMONI, but
the new macro (with the same name) is redefined after the
original definition. SAS uses the last macro definition
encountered.)
Thanks to John Leath, Fleet Information Inc, USA.
Change 06.086 The SORT order of the PDB.PRINT data set was incorrect in
MONTHBLD both MONTHBLD and WEEKBLD and in the PDB.PRINT section of
WEEKBLD Chapter 40 of the MXG Supplement. The actual order is:
Jun 29, 1988 READTIME JOB JESNR PRINTIME PRENTIME OUTDEVCE SYSTEM.
Only one run at one site actually had an error, but the
correct sort order is now used in these two members.
Thanks to Jim Bentley, US National Bank, USA.
Change 06.085 The IDMS Performance Monitor data has been enhanced and
TYPERTEJ further compared with the Cullinet reports. Their reports
VMACRTE are wrong. Their "Start Time" is actually the End of the
Jun 29, 1988 interval. Many report fields are 4 or 5 print positions;
Cullinet truncates the high order characters, which made
30652 Storage Gets (MXG value) print as only 652! Labels
for PGMOVLU, PGMOVLIU, and PGMOVLNU were changed after a
phone call to Cullinet corrected the documentation. The
storage and program pool sizes in their reports may be
wrong. the data (and hence MXG values) are pages, yet it
seems they have 4K pages and 1/2K pages in their reports.
However, not only Cullinet made mistakes. The label for
ARAFNAME is now FILE, not FIELD, and variable IHDRCVN,
the Central Version Number, was added to all IDMS data
sets (to separate different IDMS regions internally).
Finally, for IDMS journal (rather than SMF recording),
RTLHDRST should have been RT1HDRST in TYPERTEJ.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 06.084 Offsets for the EXD data in the SAR SMF record (which is
IMACEXD either type 6 or a user record) were low by 2. Offsets
Jun 29, 1988 are now 91, 103, 111, 121.
Thanks to Cathy Hellums, U.S. Sprint, USA.
Change 06.083 Sample Turnaround report failed if job had not actually
ANALTURN terminated. IF SUBSTR(INBITS,3,1)='J'; test was added to
Jun 29, 1988 keep only jobs which had a 30 subtype 5 term record.
Thanks to Cathy Hellums, U.S. Sprint, USA.
Change 06.082 Sample NETSPY reports raised SORT order error. SMFTIME in
ANALNSPY the SORT BY statements should have been DATE, to agree
Jun 29, 1988 with the PROC PRINT BY statements.
Thanks to Rick M. Odegard, Kimberly-Clark, USA.
Change 06.081 Inclusion of STOPX37 record processing in BUILDPDB/3
VMACX37 caused a SAS 353 error about arrays if the _CDEX37 entry
Jun 28, 1988 in PDB exit EXPDBCDE was not the last _CDE.... entry.
The semi-colon at the end of the (KEEP= ...) statement in
VMACX37 should not have been there, was the culprit, and
no longer exists.
Thanks to Paula Lamphear, The Strohs Brewery, USA.
Change 06.080 Decoding of CICS variable UOWID into its actual time
TYPEMONI stamp variable UOWTIME (Change 6.016) was revised when
VMAC110 yet another undocumented timestamp format was found. The
Jun 28, 1988 non-fatal "INVALID DATA FOR INPUT FUNCTION" note and the
hex dump of the record resulted, setting UOWTIME missing.
Multiple Region Option (MRO) CICS environments should
find that the combination of NETSNAME UOWTIME is constant
for the same transaction across the CICS regions (TOR,
AOR, FOR) for the same "Unit of Work". While the MXG
UOWTIME is constant, the 8-byte UOWID variable will only
be constant in the first six bytes; the last two bytes of
UOWID increment at SYNC points. This revised algorithm
now checks times for valid format, rather than trying to
guess where the time stamp should be! The change applies
to both IBM CMF type 110 and Landmark's Monitor data.
Thanks to Daniel Engstrom, Continuum, USA.
Change 06.079 Continued DB2 enhancements in testing:
ANALDB2R 1. ANALDB2R enhanced with additional DB2PM report from 100.
IMACDB2T 2. Preliminary testing of SMF type 102 DB2 Trace record is
TYPE102 provided by this MAJOR contribution from this user. Many
VMAC102 new T102Snnn data sets are created by TYPE102, which uses
Jun 10, 1988 the macros defined in VMAC102 that are re-defined and
controlled (to select desired trace CLASS) in IMACDB2T.
Not all of the subtypes coded herein have been validated.
Thanks to Scott Peterson, Southern California Edison, USA.
Change 06.078 VM/XA validation continues.
VMACVMXA 1.SYSZONE is added to MRHDRTOD and all TODSTAMP8. variables
Jun 15, 1988 to convert GMT to local time in all MXG datetime stamps.
2.DM=3 RC=9 code SKIP+48 in line 2972 vice SKIP+40.
3.USEINT divide by HF counts protected for zero divide.
4.CALMPNTC respelled as CALMPNCT. (July 5, 1988).
Change 06.077 MVS 2.2 uses JFCRSV38 bit (JFCDSEQN, data set sequence
VMAC1415 number was coded on label parameter) which was a reserved
Jun 7, 1988 bit in the field decoded in to variable LABEL. This fix
tests bit values rather than hex byte value, so that the
variable LABEL is corrected.
Thanks to Howard R. Stenzel, Financial Data Products, Inc, USA.
Change 06.076 DB2 Version/Release QWHSRELN is PK1.1 vice PIB1., and no
VMACDB2 /16 operation (four places). QWHSRELN will now contain a
Jun 7, 1988 value of 1.2, 1.3, etc.
Thanks to Scott Peterson, Southern California Edison, USA.
Change 06.075 The user type 'C0' VM/Account record created for RSCS is
TYPEVM decoded into the new VMRSCS data set, due to this user
EXVMRSCS provided enhancement. Also, tape attach records with zero
Jun 7, 1988 connect time from CA's DYNAMCMS are no longer OUTPUT.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 06.074 Several changes from one user:
FORMATS: 1.3240 should have been 3420 (VM Tape format)
TYPERTEJ: 1.SYSTEM $CHAR4. added to FORMAT statement.
2.After line 18, IF LGRTYPE NE 6 THEN DELETE: added.
Jun 7, 1988
Thanks to Dick Whiting, Precision Castparts, USA.
Change 06.073 Calculation of CU602LEN should have set values of 9, 10,
VMACVMON or 11. Cause last device to be lost from data set.
Jun 7, 1988
Thanks to Rachel Billington, British Telecom, ENGLAND.
Thanks to Dick Whiting, Precision Castparts, USA.
Change 06.072 More IMS cleanup:
ANALDB2R 1.IF SXNUM GT should be IF SXNUM GE.
EXIMSOUT 1.IMSTRPNO spelled IMSTAPNO, MSGTRAN spelled MSGTRANS and
IMSRECNO added to DROP= list.
JCLUXREF 1.Comments improved, VERS5 changed to VERS.
TYPEIMS 1.Move INCONT,LOGONID,MSGLEN and ORGENT initializations to
before their respective conditional assignment.
2.M014 should be M0114 at line 468 (made MSGSZIN wrong).
3.NODENAME added to RETAIN at line 766.
VMACIMS 1.COMPCODE is now a $CHAR4. formatted $HEX8. The last byte
was lost when it was stored as a four byte numeric. (SAS
needs one byte for exponent if the field is numeric).
Jun 7, 1988
Thanks to Pete Shepard, Ashland Oil, USA.
Change 06.071 NPM 1.3 type 28 record Stop Collection (Subtype=2) record
VMAC28 has a shorter PMC section, causing STOPOVER. At line 825,
Jun 7, 1988 conditionally INPUT NPMDATA thru NPMUPPER IF LENTOF GE 34
Thanks to Barry Pieper, FBS Info Services, USA.
Change 06.070 Now LRECL=32760 is specified for input SMF file. The old
VMACSMF value of 32756 solved a problem introduced with SAM/E and
Jun 7, 1988 documented at that time; somewhere in the intervening 10
years, IBM lifted the constraint and now the correct SMF
LRECL=32760 is required (LRECL=32756 causes a STOPOVER
condition if data is really LRECL=32760).
Thanks to J. Cary Jones, Philip Morris, USA.
Change 06.069 Variable TYPEIOML in data sets TYPE75 and TYPE77 now is
VMAC75 updated to recognize 309x processors; it is not used in
VMAC77 MXG and this change should have little visible impact.
Jun 7, 1988
Thanks to Richard Evans, Mervyn's, USA.
Change 06.068 RMF 3.5 support for PR/SM and other MVS 2.2 changes that
EXTY70PR related to expanded JESNR range to 99,999 were added.
VMAC26J2 1.Support for 99999 JESNR from JBID added to VMAC26J2 and
VMAC26J3 VMAC26J3 for JES2 and JES3 purge records.
VMAC30 2.Support for 99999 JESNR from JBID added to VMAC6 for PSF,
VMAC434 JES2, JES3, and EXTWTR type 6 records. The OUTPUT for the
VMAC6 EXTWTR was relocated to follow the creation of JESNR.
VMAC7072 3.Support for 99999 JESNR and revision of TYPETASK decode
VMAC71 (still $CHAR4 long, but fourth position will be blank for
VMAC74 99999 JESNR in all type 30 data sets.
Jun 2, 1988 4.New variable TERMNAME (Terminal Symbolic Name) created in
all type 30, type 4 and type 34 data sets.
5.New variable DSSIZHWM (Data Space Storage, highwater mark
used during the step) only in TYPE30_4 data set.
6.New documentation notes for TYPE30_4, PDB.STEPS, etc:
IOTMTOTL: For a DIV object, this includes the IO connect
time for READs, WRITEs and REREADs. This I/O .
connect time for DIV objects is only captured
for the address space, and not by DDNAME.
IOTMTODD: The connect time from each DDNAME does not
include DIV connect time, but a DDNAME for DIV
could record connect time if it were accessed
with a VSAM utility.
IOTMNODD: Will now include the DIV I/O connect time (i.e.
NOT captured at the DD level is in NODD vars.)
7.Support for PR/SM hardware and RMF PTFs in VMAC7072 with
new member EXTY70PR.
a. New data set TYPE70PR created, one obs for each LCPU
(Logical processor) in each LPAR (Logical partition).
This PR/SM data set reports on all defined partitions
and is the only source of total hardware CPU active.
b. PR/SM changes how TYPE70 captures CPU wait and busy.
Read the Partition Data Report field descriptions in
the RMF User's Guide. The variables CPUWAITM/PCTCPUBY
(and the individual CPU 0-8 values) are recalculated
by this change from the PR/SM data sections for the
LPAR this MVS is executing in. TYPE70 data under the
PR/SM hardware now only reports this MVS's usage, and
no longer reports total (real) hardware CPU active.
Summing TYPE70PR variable LCPUPDTM by STARTIME will
provide total (real) hardware CPU activity during the
interval by ALL partitions.
c. TYPE72 variable ACTFRMTM is the resident page-seconds
sum of Central Store (CS) and Expanded Store (ES). The
ratio of ACTFRMTM/RESIDTM is the average total number
of pages (frames) in CS+ES for this performance group
period. TYPE72 variable PGPAGEIN is the number of page
ins in this performance group period.
8.Additional Paging data in TYPE71 supported. New variables
EXTREADS, SQARE.., SQAEX.., LPAEX.., CSAEX.., LSQARE..,
LSQAEX.. and REGSEX.. added.
9.Additonal SMS data in TYPE74 supported. New variables are
DASDRCFG & STORGRUP, and AVDSOPEN in RMF 3.5.0+ contains
count of allocations, rather than data sets open.
Change 06.067 This member lists all %INCLUDES for each MXG member. It
DOCINCLD is now automatically created from each new MXG version by
Jun 2, 1988 a smart SAS program.
Change 06.066 The MXG FMXGUCBL SAS function which dynamically allocates
FMXGUCB7 all online DASD for VTOC processing was for MVS/XA only.
Jun 2, 1988 This new member provides the same function under MVS/370.
Thanks to ???, ???, AUSTRALIA.
Change 06.065 STOPX37 Product Release 3.2 is now supported. Record was
VMACX37 completely reordered but essentially the same variables
Jun 2, 1988 exist.
-------Changes through 6.064 completed the Pre-release MXG 6.2-------
Change 06.064 STOPX37 product changed SMF record format. Temp fix to
VMACX37 avoid STOPOVER ABEND was added, but does not support the
May 2, 1988 new format in their Release 3.2, which will be in the
next pre-release of MXG.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.063 Final beta tests of 6.2-minus uncovered these errors:
TYPEIMS -MSGSZOUT spelled once in error as MSGSZOU.
EXIMSOUT -TRANCLAS spelled in error as TRANCLS.
JCLUXREF -Unnecessary PROC COPY removed from TESTUSER step and 2nd
Apr 27, 1988 DCLOG DD DUMMY was supposed to be EPILOG DD DUMMY (slow
response after SPF replicate subcommand caused error).
Thanks to Pete Shepard, Ashland Oil, USA.
Change 06.062 Support for VM/XA SP 1 accounting card data (described in
TYPEVM SC23-0353, pages 126-128). Only the VMSESSN, VMDEVICE and
Apr 27, 1988 VMUSRDAT datasets are created by VM/XA. Data set VMDEVICE
variables DEVICECL, DEVICETY, MODEL, & FEATURE are now
reserved fields! Two new variables for vector CPU time,
VECVITM and VECVIRTM, are created for VM/XA and VM/SP
account cards. The card format is essentially the same as
VM/SP so this member now supports VM/SP or VM/XA records.
Change 06.061 Variables LPAPGMN,MX,AV, CSAPGMN,MX,AV, and PRVPGMN,MX,AV
VMAC71 in TYPE71 are correct, but their label was "PAGEABLE" and
Apr 27, 1988 is now "TOTAL". Page 410 of the MXG Supplement is correct
(except for the mispelling of private as privage!) which
corrects page 706 in the MXG Guide! Change 4.34 made the
values correct, but overlooked the change in labels.
Thanks to Roger Crabb, British Telecom Red Lion Square, ENGLAND.
Change 06.060 -Variable NPMLOST should have been PIB4. vice $CHAR8.
VMAC28 -For all date fields INPUT with PD4 format were protected
Apr 27, 1988 from a null (hex zeros) value causing INVALID DATA by the
addition of ?? between variable and PD4. (which causes
the value to be set missing without the hex dump and the
error message). Nulls were found for OGNSDATE & OGNEDATE.
-LDRTIME is reported always zero, IBM suggested UY18442 is
the fix, but that is in doubt and unconfirmed.
Thanks to Barry Pieper, FBS Informations Services, USA.
Thanks to Craig Feistner, CITICORP South Dakota, USA.
Change 06.059 Variable DOWNTM in TYPE0 data set was sometimes set to
VMACSMF missing when it could have been calculated, because the
Apr 27, 1988 PREVSYS and PREVTIME temporary variables in this member
were not RETAINed. They are now.
Thanks to Mike Heffler, Department of Defense, Ft Meade, MD, USA.
Change 06.058 Beta test of VM/XA SP 1 Monitor Records completed. See
DOCVER the sparce documentation in comments in VMACVMXA and
EXdddrrr examine the structure of the _TESTVM macro to see the
FORMATS slight changes in overall MXG structure necessary to
IMACVMXA accomodate the need to de-accumulate. Instead of the
UTILGEVX _VAR.... and _CDE.... MXG macro names, the _Vdddrrr and
UTILVB _Cdddrrr MXG VM/XA macros descrive the VXdddrrr data set
VMACVMXA created from Monitor Domain ddd and Record rrr records.
Apr 27, 1988 Seventy-five MXG SAS data sets are created with 1393
variables. Member DOCVER documents these MXG data sets.
In the author's opinion, this is the best MXG code ever written!
But that's not surprising with the good documentation and SAS,
and especially since the choice of IBM field names were
sufficiently "human-engineered" and self-consistent that I chose
to use them as the MXG variable name. This will completely avoid
the past difficulty of multiple names for the same field (such as
the CP, MON, and VM MAP triplets for identical fields). The
design left 5 positions for a reasonably un-cryptic name, and
wise person(s) picked good, usable and understandable names.
IBM Kingston: Thanks, you really did this one right!
========Changes thru 6.057 were printed in NEWSLETTER TWELVE==========
========Changes thru 6.057 were printed in NEWSLETTER TWELVE===========
Change 06.057 New exit IMAC434D was added to support modeling from
IMAC434D type 4, 34, and 40 records. Since BUILDPDB only uses
VMACEXCP type 30 records, this should not be important to many,
but it was added upon request for consistency with the
IMAC30DD similar-purpose exit for type 30 SMF records.
Apr 7, 1988
Thanks to Andrea Glaser, Performance Systems, Inc, USA.
Change 06.056 Complete internal rewrite of db2pm-like reports as new
ANALDB2R style macro, which supports reporting for multiple db2
systems, with a brand new report, is described in the
comments in this revised member. more still to come.
Apr 6, 1988
Change 06.055 $AVRS (SYSOUT Accumulation and Viewing System), Confident
IMACSAVR Software, Inc, creates a user SMF record which is now
TYPESAVR supported. You specify the SMF TYPE in IMACSAVR.
VMACSAVR
Apr 4, 1988
Thanks to Vern F. Berkquist, Bradford Exchange, USA.
Change 06.054 Landmark's CICS code was not updated for decoding of new
TYPEMONI UOWTIME format, causing an "INVALID DATA FOR INPUT FUNCT"
Apr 2, 1988 message (simply setting UOWTIME missing and continued).
Change 6.016 should have been made to Landmark as well.
Thanks to Bill Border, Apollo Computer, USA.
Change 06.053 -IMS Log processing with MXG now really matches DFSILTA0
EXIMSOUT counting of transactions! This supplements the comments
IMACIMS in Change 6.22. Lots of additional research by Pete shows
TYPEIMS that the "minor glitches" turned out to be "page scrolls"
VMACIMS (PA1 key, or retrieval of multiple screens) which MXG put
your IMSJCL in the MSGONLY data set. Pete has added new algorithms in
Apr 1, 1988 EXIMSOUT which recognizes and moves them from MSGONLY to
the IMSTRANS data set. With this change, MXG now matches
exactly to 99.5% of IBM's DFSILTA0 program (which ,may be
the culprit, since it doesn't start counting transactions
until an IMS checkpoint record is found, while MXG begins
with the first record on the IMS log.)
-You must add a new DDNAME to the JCL which uses TYPEIMS
(this has been done to step TESTOTHR in JCLTEST):
//INSTREAM DD UNIT=SYSDA,SPACE=(CYL,(1,1))
which is used in the new EXIMSOUT exit for the "instream"
creation of the $TEMPIMS. tempory SAS FORMAT.
-All references to the unnecessary and redundant _IMSWORK
macro were removed to avoid confusion. Since IMS log data
is processed in a separate step from other data records,
there is no need for a work DD name other than WORK.
Thanks to Pete Shepard, Ashland Oil, USA.
for lots of arduous work.
Change 06.052 -TYPE78.. data sets variables INSTALL, ONLINE, VARIED,
VMAC78 OFFLINE, INVLID, PCTPTHBY, NOSTCPS, NOUCBFND, NOHDWMES
Apr 1, 1988 were not set blank by an ELSE clause if the bit test was
false, which could cause the 'Y' value to be propagated
(incorrectly) into the next segment in the record.
(Change 5.27 fixed this for VMAC74 but overlooked VMAC78.
-Labels for NRIOPENQ and NRIOPREQ were reversed.
Thanks to Stephen Geard, Commonwealth Bank of Australia, AUSTRALIA.
Change 06.051 When the SORT list for BUILDPDB data sets was expanded to
WEEKBLD handle the NODUP option in MXG 4.4, weekly and monthly
MONTHBLD members BY lists were not updated. While only one user
Apr 1, 1988 noticed this oversight, now the BYLISTs agree with the
PDB order as documented in the MXG supplement pp263ff.
Thanks to Marge Hagen, GTE Marina del Rey, USA.
Change 06.050 Comments were re-written to better describe the default
TYPEROSC ROSCOE data sets created by this member. No code changed.
Mar 31, 1988
Thanks to Craig Feistner, CITICORP South Dakota, USA.
Change 06.049 SYNCSORT SMF record had minor exposure in calculating the
VMACSYNC date part of SORTEND datetime stamp for sort which began
Mar 31, 1988 on one day and ended on the next day. Lines 260-261 were
reversed; the IF test precedes the calculation.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.048 RACF type 80 format TYPE80ER was not correct (and caused
VMAC80 an overlooked note on the SAS log). It is now.
Mar 31, 1988 Add one new line after 1261:
@; IF LENAOF GE 76 THEN INPUT
b.Change three occurrences of NPN to NPM.
Thanks to Mark Bercov, Canadian Occidental Petroleum, CANADA.
Change 06.047 This change consolidates all current reported errors in
ANALNPM support for the new type 28 SMF record. The comments at
VMAC28 the beginning of VMAC28 are now enhanced and provide a
Mar 17, 1988 cross reference of the type 38 variables with their new
Mar 31, 1988 type 28 replacements: TYPE38EX in NPMEVNCP & NPMEVNET,
TYPE38IN in NPMINLU & NPMINPU, and TYPE38NC in NPMINNCP.
a.These five new data sets are not exact replacements for
the three TYPE38.. data sets, and for consistency all of
the old NPA prefixes were changed to NPM (NPA was the old
IBM FDP, which died a graceful death). Your TYPE38..
reports will need to be changed; use the aforementioned
cross reference of new/old variables and data sets in the
comments at the beginning of VMAC28.
b.NPM 1.3 type 28 record creates two lengthed NAD segments
and the shorter length caused an INPUT STATEMENT EXCEEDED
RECORD LENGTH error. Add one new line after 1261:
@; IF LENAOF GE 76 THEN INPUT
c.Changed three mis-spellings from NPN to NPM.
d.Exchanged 20 and 30 in line pairs 24,25 and 1424,1427.
(This will exchange observations in NPMINSES & NPMINRTM.)
e.Repeated line 731 as 731.1 with 0F5X setting NND.
f.Added new line 779.2 with +2 (missed reserve field).
g.Added new line 1201.1 to set AOFTYPE='NAC' with OR
(NPMSUBTY EQ 18X AND NPMTYPE EQ 81X).
Added new line 1202.1 to set AOFTYPE='NAD' with OR
(NPMSUBTY EQ 18X and NPMTYPE NE 81X).
h.Renumbered VMAC28 and ANALNPM to "level set" for future.
i.You can see that many users helped in the validation
of the 6.1 pre-release of SMF 28 support. There still
may be record combinations which have not been tested,
and there are not really any reports yet, especially from
the new data sets, but (to paraphrase SAS' Robert Cross
at 1988 SUGI, about the major SAS re-design, MVA for
Multi Vendor Architecture which was only a concept last
SUGI): "Now it works!" Thanks for all who helped:
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Thanks to Rodney L. Reisch, General Electric Silicon Products, USA.
Thanks to Barry Pieper, FBS Information Services, USA.
Thanks to Matt Cody, Jostens, USA.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Rodney L. Reisch, General Electric Silicon Products, USA.
Thanks to Mike Pichowicz, U.S. Trust, USA.
Thanks to Billy Westland, Candle Corporation, USA.
Thanks to Robert Bunn, IBM NPM Level 2, USA.
Change 06.046 This MXG system for measuring your DASD farm (data set
FMXGUCBL sizes from VTOCs) now supports the 3375 DASD device.
VMXGVTOC
Mar 17, 1988
Thanks to Chuck Rexroad, Perpetual Savings Bank, USA.
Change 06.045 -Cosmetic clean-up in JCLTEST member in step TESTUSER adds
JCLTEST the EPILOG DDNAME. In TESTUSER member, %INCLUDE TYPESYNC
TESTUSER was added to create and test SYNCSORT data set. We use
VMXGUSE JCLTEST to create MXG's cross-reference that is input to
Mar 17, 1988 both the auto documentation (DOCVER, DOCVERnn) and the
conflict analysis (variable names, types, formats, etc).
XREF and DOCVER are the final runs before a pre-release
of MXG Software is ready for shipment.
-A new style macro %VMXGUSE was contributed by Dan Kaberon
that builds an MXG execution for a specific subset of SMF
records. This is provided as an example only. The MXG
development of a code generator to trivialize that task
is ongoing, but not with the %MACRO facility. Consider:
BUILD XAONLY 30.4 30.5 26 ADD=MYVAR DROP=OLD1 OLD2
for you to create the TYPE30_4, TYPE30_5, TYPE26 datasets
with the MXG default variables (but only from MVS/XA) and
with trivial tailoring of kept variables through ADD= and
DROP= syntax. This is a list processing problem, where
the input lists are a tested, changing part of MXG code.
A data step seems to be the only right way to implement
this design, but don't look for it before 1989! Another
MXG user has shown me his proprietary solution which is
based on a data dictionary, implemented with macros. It
is also under consideration. Then also, SAS Institute
announced at SUGI 88 that the SAS/AF CPE Reporting System
(currently free upon request) will be automatically on
SAS 5.18. That is likely to be the test bed for any such
MXG offering.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 06.044 The optional DL/I counters and clocks which can be added
IMACICDL to your CICSTRAN data set from type 110 SMF records may
Mar 8, 1988 not be labeled. The LABEL statement is inside the 1.6
comment block, but not in the 1.7 comment block. If you
enabled both 1.6 and 1.7 DLI counting, your labels are
fine, but if you enabled only 1.7 DLI counts, you should
copy the LABEL statement from in the 1.6 code in IMACICDL
into the same place in the 1.7 code.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 06.043 This ASM program and associated REXX EXEC is for VM/SP
ASMVMCOPY and VM/SP HPO sites who do not have a CMS SAS license,
REXXCOPY who want to copy the VM/Monitor spool data records to a
Mar 8, 1988 CMS file (typically to then be processed by MXG under the
MVS SAS System). The EXEC should be self explanatory, and
the ASM source program needs only compiled and linkedited
to be useful. (If you have the CMS SAS System, the Infile
Exit named MONITOR allows the copy of Monitor Spool Class
data directly, without ASMVMCOPY program.) This program
is functionally equivalent to the VM MAP MONDISK/MONTAPE
routines.
Change 06.042 Support for RMDS Release 3.0. One MXG Format, new values
FORMATS for existing formats, and a new Macro in IMACRMDS is now
IMACRMDS required to tell MXG whether its RMDS release 2 or 3, as
VMACRMDS there is no version indicator in the data records.
Mar 8, 1988 self-recognition.
Thanks to Randy Graves, City of Albuquerque, USA.
Change 06.041 Reserved Change number.
Mar 8, 1988
Change 06.040 Support for the SMF record created by Goal System's
ANALPDSM PDSMAN/SP product. This code was written in Germany and
EXTYPDSM donated to MXG. It was slightly restructured, and thus
IMACPDSM any errors are my fault, not theirs.
TYPEPDSM This implementation (which started with functioning code)
VMACPDSM produced a "typical" MXG support set for an SMF record:
Mar 7, 1988 Five new source members, 250 SAS source lines, one SAS
data set with 21 variables and one new MXG format.
Thanks to Engelbert Smets, Provinzia Versicherungsanstalten, GERMANY.
Change 06.039 Member ANALDB2R produces DB2PM-like summary reports. They
ANALDB2 have been further validated by detail comparison and now
ANALDB2R they should be reliable. This validation uncovered an MXG
Mar 7, 1988 error in member ANALDB2R which affected variable QXFETCH
in DB2STAT1 data set, because Change 5.144 (which changed
QXQUERY to QXFETCH) was not applied to ANALDB2R.
The ANALDB2R report has been re-written as four new-style
%macros and support reports by DB2 system. Comments in
that member describe the selection criteria. Another DB2
report has been added also. Expect more DB2 reports in
the next prerelease (which hopefully will support the SMF
type 102 DB2 record as well)!
Five SQL values in the Accounting summary were close, but
were nevertheless wrong. Most of the other differences
between DB2PM and MXG reports came from these factors:
a. IBM uses a slightly different value for interval in the
denominator of all rates (still under investigation,
but it looks like IBM modulos minimum to adjacent 10
minute TOD, modulos maximum SMF time up to its 10 min
TOD and then takes difference as interval).
b. A difference of one in the last digit almost always is
noted. IBM truncates, MXG rounds.
c. IBM averages include zero values but MXG used to use a
SAS missing value. MXG now sets zero to agree with IBM.
d. Errors (in my opinion, still under investigation) in
their DB2PM Statistics Summary report code:
1. Buffer Pool "Current Active Buffers" is actually the
maximum number of buffers, and the Max/Min numbers do
exist, even though not printed by DB2PM.
2. Service Controller "Datasets Open - Current" is larger
than "Datasets Open - Maximum" and not equal to either
current or maximum in SMF record. SMF=MXG looks right
now. This was reported in Change 5.89d.
3. Still as reported in Change 5.89a, EDM Pool "FREE PG
IN FREE CHANGE" and adjacent AVERAGE values are wrong
because QISEFREE is (incorrectly) the value from the
preceding record.
4. Change 5.89e (Agents Services and Storage Manager)
fields (QVASX... and QSST...) have not been confirmed
as corrected.
5. System Events "Abends EOT" shows zero even though the
next page, Subsystem Service Component "Subsystem
Allied Memory EOT" value is 203.
e. Additional changes in the Accounting Summary report:
-Group total line printed only when there was a group!
This will reduce the size of the MXG report by half as
many pages as it was.
-RATE/HR and %DYNSQL report fields are now calculated.
-The average values in this report now agree with IBM's.
Five fields (ABNRM TERM thru OTHER MANIP) disagreed. The
1st was wrong, the others were different because IBM's
averages included 0 values, while MXG used missing value
There was no error in the MXG DB2ACCT data set, only in
this ANALDB2R report program.
This change required 16 dedicated hours.
Thanks to Louis Eliscu, Continental Insurance Company, USA.
Thanks to Ralph A. Pepe, Connecticut Bank & Trust Company, USA.
Change 06.038 Continued validation of MXG VM/Monitor data sets shows a
ANALVMOS numeric difference on some average values. These design
VMACVMON considerations caused the variations:
Mar 05, 1988 -MXG set values to missing, while IBM sets everything to 0
(which changes the Number of observations in the Mean).
-MXG defined ACTIVE if the USER used any CPU time during
the interval while IBM tested only the virtual CPU time.
There are lots of user records (for PROFS users maybe?)
with CPUSVITM zero but with CPUSTOTM non zero that MXG
formerly counted ACTIVE. CPUSTOTM non-zero with CPUSVITM
non-zero means CP CPU time with no VTIME. This may be a
result of PROFS machines, actually inactive during the
interval, whose "display clocks" must nevertheless be
updated (or something like that) causing measured CP CPU
time during the interval. In any event, MXG now counts
ACTIVE just like IBM.
-MXG deleted all records in the first two intervals. This
was done in initial testing when large CPU time values
were found in the first few records, and because the 1st
record will eventually be deleted (can't calculate delta
'til you get the second record). However, the real cause
of those "bad" CPU times turned out to have been fixed
by Change 5.133 (negative decremented counter reset)!
-In summary, MXG now keeps the second interval, uses zeros
and IBM's ACTIVE calculation to more closely match VMMAP
reports. The detail data was never really wrong.
a.ANALVMOS needed PROC SORTS and some new calculations for
the Paging and Swapping Volume data sets to be right in
the summary reports and data sets.
b.VMACVMON revisions include:
-Logic which used to output observations after the second
interval (INTRVCNT GT 2) was changed to (INTRVCNT GT 0)
so that all records initially create an observation.
-Final MERGE to build VMONPERF data set now does delete
the first interval (after delta calculation). This was a
result of the previous logic change.
-Additional logic sets missing values to zeros for those
queue stats (cpuq defrq ioq pageq pswait runq stgq swapq,
and their derived percentages).
Thanks to Steve Glick, Southern Methodist University, USA.
Thanks to James Farnsworth, Carolina Power & Light Company, USA.
Thanks to Jeff McCourt, The Continuum Company, USA.
Change 06.037 This change revises and replaces 6.011, which added only
IMACCADI the EXD support. SYSOUT handling products CA-DISPATCH and
IMACEXD EXD create modified type 6 SMF records. This change adds
VMAC6 support for those modified record, but the user who does
Mar 05, 1988 not have those products will not see the new variables in
her TYPE6 data. The algorithm to accomplish this task is:
The new variables are already in the KEEP= list in the
definition of _VAR6 macro in member VMAC6, but the code
that references the new variables are commented out in
the associated IMAC.... member. To create either set of
variables, you need only copy the appropriate IMAC.... to
your USERID.SOURCLIB, remove the comments and TYPE6 will
contain the new variables. If you also want them in your
PDB.PRINT data set, you need also edit IMACPDB and add
the variables to _PDB_6 definition therein.
Thanks to Larry Miller, First American National Bank, USA.
Change 06.036 The JOB variable has been added to the new type 41 (DIV,
VMAC41 Data-In-Virtual) SMF record by IBM, but I can't find the
Mar 05, 1988 APAR/PTF which made the change. Only the JOB was added;
the READTIME is still not there, so you can not merge a
TYPE41 with the other SMF records of a job! This will be
an important record in MVS/ESA in the future, as DIV is
the primary physical implementation for the data spaces
announced in MVS 3.0. At least I think thats right. If
you are testing DIV, you should see APAR OY09833 which
fixes a DIV problem with missed RPS revolutions (and the
concomitant elapsed time elongation) with 3380s behind
Model 23 cache controllers!
Change 06.035 The VVR decoding worked perfectly, unless the ENTRNAME is
VMAC60 exactly 44 bytes (which caused "SUBSTR ARGUMENT INVALID"
Mar 05, 1988 message). To repair, replace existing lines 76 thru 83
(that's 8 lines) with these seven (renumbered) lines:
INPUT @OFFPROD+179+VVRCMPNL VVRKEYL PIB1. @; 0076
VVRKEYL=VVRKEYL-1; 0077
INPUT VVRKEY $VARYING44. VVRKEYL 0078
+1 0079
VVRCATNL PIB1. 0080
VVRCATNM $VARYING44. VVRCATNL 0081
@; 0082
Thanks to Thomas Frenkel, CITIBANK N.A. New York, USA.
Change 06.034 The VMSORT product from VMSI can cause a spurious Detach
VM or your 190 disk. The Vendor fix is S140520.
Mar 05, 1988
Thanks to ???, ???.
Change 06.033 The references on pages 247 and 252 of the MXG Supplement
TYPEMONI concerning the count of Landmark CICS transactions in the
Mar 05, 1988 history summary records should read that TATASKNR (and
not the other variable TASKNR) contains the total count.
Thanks to William Pedilla, Farmers Insurance, USA.
Change 06.032 This is hopefully the final hit on the IDMS Performance
VMACRTE Monitor (RTE) data sets. The INPUT TAWPGMLL statement at
Mar 05, 1988 line 964 needed to be INPUT +4 TAWPGMLL to skip over the
TASKID. This only affected the first six copies of 6.1.
Thanks to Rodney L. Reisch, General Electric Silocon Products, USA.
Change 06.031 This logic change in SPINCNT logic really only affects a
BUILDPDB site which wanted to SPIN once and only once (to BUILDPDB
BUILDPD3 once a month, for example). The old algoritm would SPIN
Feb 17, 1988 on the first day (_SPINCNT = 0) or on the third day
(_SPINCNT = 1), but it would not SPIN on the second day.
Change 5.134 attempted to address this problem, but it
did not help. This piece of logic has always been wrong
in MXG, but Leigh tracked it down and fixed the problem
for all of us.
The SPINCNT logic is described in Chapter Thirty-Three.
Start first with the Supplement, then the earlier Guide.
There will be a slight impact on current PDB users, as
this correct algorithm PDBs (verb) the data on the day
it should have, which is one day earlier than before:
IMACSPIN
_SPINCNT Old Algorithm Correct Algorithm
0 PDBs today, PDBs today,
No SPIN. No SPIN.
(No change here).
1 SPINs twice, SPINs today,
PDBs third time. PDBs tomorrow.
2 SPINs thrice, SPINs twice,
PDBs fourth time. PDBs third time.
.......
10 SPINs eleven days, SPINs ten days,
PDBs twelfth day. PDBs eleventh day.
BUILDPDB BUILDPD3 From To
line 375 385 SUM( ,0.5); SUM( ,0);
line 380 390 GT GE
Thanks to Leigh Miller, GRE Insurance Ltd, Camberwell, VIC, Australia
Change 06.030 ANALMNTS adds a new capability to MXG by providing a way
ANALMNTS to calculate a useful "typical" average time per tape
EXTY74 mount for each tape drive for each hour when there were
Feb 16, 1988 mounts on that tape drive. ANALMNTS merges the TYPE74
mount pending durtion with the TYPE21 count of dismounts
during the RMF interval to calculate AVGMNTTM for each
hour for each device. Because TYPE21's timestamp is the
dismount (could be much later than mount timestamp), the
values calculated do have some ambiguity - occasionally
very large differences are observed between the actual
mount time and that calculated by this algorithm. More
on the validation of this algorithm later. Call if you
want to use it.
In developing ANALMNTS, the MXG Default for TYPE74 which
creates observations only if PCTDVUSE or SIO74CNT are non
zero (Default in EXTY74) was enhanced to OUTPUT TYPE74 if
mounts were pending, even if nothing else happened. This
change in MXG default is needed if you create type 74 RMF
records for TAPE and want to use ANALTAPE to estimate the
mount time. The number of additional observations should
be minimal (but their absence added 6 hours to validate
ANALMNTS!)
Thanks to Dan Kaberon, Hewitt Associates, USA.
whose originally proposed the algorithm last year, and who helped me
with this one. He has given IBM a suggestion to add two fields,
total mount and number of mounts, to the TYPE74 interval record,
which would (if IBM responds) permit un-ambiguous average tape mount
time calculations from TYPE74 records directly for each RMF interval
for each device.
Change 06.029 NLDM TYPE39 variables TBYT.... and CBYT...., Text/Control
VMAC39 bytes between primary and secondary were reversed. The
Feb 16, 1988 .BYTPRSC variables should have been .BYTSCPR and vice
versa.
Line 306 should be ....PRSC
Line 308 should be ....SCPR
Line 310 should be ....PRSC
Line 312 should be ....SCPR.
Thanks to Mike Paller, Harris Corporation, USA.
Change 06.028 TYPE71 variables PAGBLMN and PAGBLMX (min and max number
VMAC71 of pageable frames) for MVS/XA have always been reversed.
Feb 16, 1988 (I guess this has been overlooked since almost everyone
looks at fixed pages rather than pageable; also, PAGBLAV
(average number of pageable frames) was always correct.
Lines 545 should be: PAGBLMN=PAGBLMN-FIXEDMX;
Lines 546 should be: PAGBLMX=PAGBLMX-FIXEDMN;
because in MVS/XA, the inputted PAGBL.. field is actually
the total frames, and max PAGBL is when FIXED is minimum.
Thanks to Kathy Manos, Stroh Brewery Company, USA.
Change 06.027 Syntax errors which slipped into the first pre-release of
VMAC28 NPM 1.3 support in MXG 6.1. Affected only 5 pioneers.
IMACROSC a.VMAC28:
Feb 15, 1988 Line 576, remove BINDCODE (from the $HEX2. line).
Line 577, add BINDCODE (to the HEX2. line).
Line 582, %%INCLUDE vice %INCLUDE SOURCLIB(IMACSHFT).
b.IMACROSC:
Restore MACRO _ROSCDDN WORK % which had been deleted
in error.
c.NPMFCCCT was renamed to NPMFCCTM to be consistent with
NPA names and meanings, and the PCTBUSY and PCTSLOW
variables were added to the NCP statistics, PCTBUSY to
the other interval data sets. With these additions, the
NPM data sets should be usable in place of TYPE38 data.
(I'll try to get a mapping together in the next release).
This paragraph added March 7, 1988.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Rodney L. Reisch, General Electric Silicon Products, USA.
Change 06.026 The Compatibility notes in MXG Version 5.5 should have
TYPE74 noted that TYPE74 data set will usually have fewer OBS
Feb 9, 1988 under 5.5 than with 4.4. TYPE74 only contains OBS if the
device was busy (PCTDVUSE), but a 4.4 error carried this
to the next device, causing 4.4 to output an extra OBS
for a device which had had no activity. No big deal here,
except for the time it took this user to validate that
the change was correct and for the good!
Thanks to Barry Pieper, First Bank Systems, USA.
The previously thanked Tom Frenkel gets to see his name now correctly
spelled, and his company as Citibank, and not its competitor!
=============Changes thru 6.025 as of Feb 4, 1988 ===================
======First pre=release of 6.1 included Changes through 6.023=========
Change 06.025 A new MXG Exit for the PDB has been created. EXPDBSPN is
BUILDPDB taken after yesterday's SPIN data sets and today's new
BUILDPD3 SMF data sets have been interleaved, but before the MERGE
EXPDBSPN in which the decision TO SPIN or NOT TO SPIN is made. It
Feb 4, 1988 may be necessary for NJE sites, where NJE creates type 6
records for the same job with multiple JES numbers. One
site is trying to use this exit to find the correct JESNR
(from the type 26 original JESNR) and store it into TYPE6
so that MXG will then assemble them all into the one JOBS
observation for the job. It may have other uses, too.
Change 06.024 DISP=(MOD,CATLG) is used in JCL examples to show you how
Feb 4, 1988 to create the data set if it doesn't exist and to use the
DOC existing copy if there is one, and to not have to EDIT a
JCL file. It turns out that if the VOL=SER parameter is
also on the DD card, the job dies with a 213-04 ABEND!
It's not clear why, but that's the way it is with JCL.
(Actually, if your installation uses the VOL=SER for you
to specify a generic for a group of volumes, MOD,CATLG
may still work, since that installation modification does
not actually send a VOLSER over to the JES Converter.)
The moral is, don't specify VOLSER and MOD,CATLG works!
Thanks to Jim Groseman, Duquesne Systems, USA.
Change 06.023 VM/Monitor data on Jan 30, 1988 from 21:29:55.02 until
Feb 4, 1988 the monitor was stopped will have STARTIME beginning at
VMACVMON 06:46:48.97 on July 11, 1987, 203.613 days earlier. The
VM/Monitor records contain only five bytes of the actual
8-byte TOD datetime stamp. Five bytes holds 203.613 days.
MXG implemented a slick algorithm to figure out exactly
when the current 203-day interval began (BASETIME) so the
5-byte MNHTOD could be added to create STARTIME. (You can
not just use the COLLTIME in the 0.97 record because it
is only accurate to a full second.) Once the BASETIME had
been set by the first record, however, MXG failed to test
to see if MNHTOD had wrapped into the next interval! This
could easily have been missed, since Jan 30 was a Sat.
(The next exposure is 21AUG88:12:13:00.97, a Sunday!)
-Add LASTHALF to the retain statement at line 284.
-Replace THEN BASETIME=BASETIME-FFFFF; in two places, in
lines 275 and 2025 with
THEN DO;
BASETIME=BASETIME-FFFFF;
LASTHALF=1;
END:
-Insert after line 278
IF LASTHALF AND MNHTOD LT FFFFF/2 THEN DO;
BASETIME-BASETIME-FFFFF;
LASTHALF=0;
END;
Change 06.022 -Further validation of MXG IMS log data sets with the IBM
Feb 3, 1988 utility's output by Pete uncovered several enhancements,
TYPEIMS as well as legitimate differences in transaction counts.
VMACIMS The IBM utility does not begin counting transactions til
it finds an IMS checkpoint record, but MXG starts with
the first 07 record found. If the IMS log tape does not
start with IMS startup, MXG will count all, IBM won't!
Pete also improved the match-up logic, using DLRTOKEN in
addition to PSTNUMBER TRANSACT. Additionally, variables
APPLID, MSGSZIN, MSGSZOUT, NODENAME, and TRANCLAS were
added to the IMSTRAN data set. There still may be minor
glitches in MXG, but the quality of the data gets better
each time someone like Pete really digs in.
-Member EXIMSCDE was deleted from the SOURCLIB. It was a
test member, and should have not been in 5.5. References
Thanks to Pete Shepard, Ashland Oil, USA.
Change 06.021 SYNCSORT sort SMF record timestamps SORTEND and SORTBEGN
Feb 3, 1988 and calculated ELAPSTM were incorrect. BEGIN and END were
VMACSYNC four PK1. fields with HH,MM,SS,TT and ELAPSTM relocated.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.020 -The technique (described on page 10 of MXG Newsletter 11)
Feb 3, 1988 to build the month PDB using only one tape drive should
MONTHBLD have the DCB=TAPETEMP added on the FILE MONTH statement
at line 144:
FILE MONTH MOD CLOSE=LEAVE DCB=TAPETEMP;
(If you specified a DCB on the MONTH DD card, you did
not notice the problem. Without a DCB parameter, SAS
uses the FILE BLOCKSIZE, which defaults to 6400 bytes.
As long as the internal length of a SAS observation is
less than 6400 bytes, no problem, but TYPE78VS data set
(among others) is larger than 6400 bytes. This change
uses the build data set block size for the MONTH file.)
-A new line (95.1) should be inserted before the percent
sign which terminates the MACRO _MNTHBLD definition:
PROC DATASETS NOLIST;DELETE DUMMY._DSET;
This will keep the size of the DUMMY allocation within
its 3-track allocation.
Thanks to Lee Salley, Westinghouse, USA.
Change 06.019 This MXG function dynamically allocates all online DASD
Feb 3, 1988 volumes in preparation for VTOC reading. This function
FMXGUCBL uses MVS/XA UCB look-up logic, and thus the function does
not work under MVS/SP at the present time. If you fix it
to execute under MVS/370, let us know and we'll share.
Change 06.018 Lines printed by VPS (SYSOUT spooling product) are seen
Jan 27, 1988 in PDB.PRINT as external writer lines rather than print
VMAC6 lines because VPS product does not store printer name in
output device field. VPS records contain string "VPS" in
the UCS field. This change recognizes VPS type 6 record
and sets DEVICE to PRINTER so that BUILDPDB will put the
VPS lines in PRLINES variable. Expand the IF statement at
line 148 by adding OR UCS=:'VPS'
(to set DEVICE='PRINTER') for the VPS type 6 record.
Thanks to Rodney L. Reisch, General Electric Silicon Products, USA.
Change 06.017 Support for Version 7.1 of Landmark's Monitor added. The
Jan 26, 1988 MXG 5.5 code will execute without error, but this change
TYPEMONI adds three one-character "Y" flags, HITASKS, MILLENUM,
and PSBPWAIT to MONITASK. The ELAPSUM variable (their
field MFSTTIM), total elapsed time of all transactions in
the interval, could overflow its 4-byte size. To prevent
overflow, you can specify TMRL=Y in your SIT to cause
MFSTTIM to use "Optional Time Resolution". MXG recognizes
TMRL is on and stores the correct duration in ELAPSUM.
The other changes introduced in 7.1 were already in place
in MXG (they had been added to support SPECIAL78 zap).
Landmark gave me plenty of lead time for this change.
Change 06.016 The creation of UOWTIME (CICS 1.7) from UOWID caused the
Feb 3, 1988 "Invalid Data for Input Function ..." SAS message (which
Feb 19, 1988 was non-fatal and simply sets UOWTIME to be missing). It
VMAC110 turns out there are three different formats/locations for
the time stamp associated with the creation of this task:
NETSNAME UOWID TIME IS FOUND IN
PRODCICS000000000000 TTTTTT0002 UOWID PIB6.
LIGAB3Z6.G.GAB3ZNNNN HHMMSS0001 UOWID HHMMSS6.
.AUB001B-07.08.07000 00 0001 NETSNAME HHMMSS8.
1.CCCCCCCHH.MM.SS000 00 000N NETSNAME HHMMSS8.
DVRHLC5.IRC000000000 092111000N UOWID HHMMSS6. *
0 = '00'X (NULL)
. = '4B'X (PERIOD) *see change 6.080
The new algorithm replaces the ELSE DO; group at lines
720-728 with this logic:
ELSE IF SUBSTR(NETSNAME,18,3)='000000'X THEN DO:
HH=.;MM=.;SS=.;
HH=INPUT(SUBSTR(NETSNAME,10,2),2.);
MM=INPUT(SUBSTR(NETSNAME,13,2),2.);
SS=INPUT(SUBSTR(NETSNAME,16,2),2.);
END;
ELSE DO;
HH=.;MM=.;SS=.;
HH=INPUT(SUBSTR(UOWID,1,2),2.);
MM=INPUT(SUBSTR(UOWID,3,2),2.);
SS=INPUT(SUBSTR(UOWID,5,2),2.);
END;
Thanks to C. J. Legrand, Tenngasco Corp, USA.
Thanks to Steve Lottich, University Hospitals of Iowa, USA.
Change 06.015 VM/Monitor variable APTCPU is missing because WTSIO1TM
Feb 3, 1988 in line 1205.1 should have been spelled WTIOS1TM.
VMACVMON
Thanks to Steve Glick, Southern Methodist University, USA.
Change 06.014 VM/Monitor summarization dies with SAS 180 syntax error
Feb 3, 1988 because:there should be two percent signs instead of one
ANALVMOS a.line 5430 should be %%INCLUDE instead of %INCLUDE
b.lines 5940 and 6050 should be 1 PCT of vice 1 % of
(when I wrapped substitution MACRO definitions around
Steve's code, I failed to test sufficiently and the
single percent signs, even in comments, terminate the
MACRO definition pre-maturely).
c.Insert new line 158.1 (after IOS=CNTVIOCT;):
IF DEVTYPE=0810X THEN VOLSER='*TAPE*';
to cause tape devices to be reported in addition to DASD.
Thanks to Steve Glick, Southern Methodist University, USA.
Change 06.013 EPILOG records (from Candle) code has been executed by
Jan 26, 1988 two users and their changes implemented. Read the notes
IMACEPIL at the beginning of member VMACEPIL. Note that member
TYPEEPIL IMACEPIL is deleted by this change, it is not needed as
VMACEPIL the data is not written to SMF after all, but only to a
FB, LRECL=600 sequential file! The real heart of this
change was to replace _SMF reference in TYPEEPIL with a
INFILE EPILOG LENGTH=LENGTH COL=COL; statement! Also,
TODSTAMP8. format on line 336 for BICPUTIM should be
MSEC8. A final cosmetic change in MXG was to split
CICPUID into CIMODEL, CIID, and CISERIAL.
Thanks to Merrick Dean, MONY, USA.
Thanks to Warren Hayward, NY, USA.
Change 06.012 I almost hate to waste your time with this obsolete SMF
Jan 26, 1988 type 4 or 34 record change. By now you really should be
VMAC434 using the type 30, and with MVS/XA 2.2 you must use 30s.!
Change 5.19, which changed the format of PVTBOT, PVTTOP,
and REGREQST to use the MG078CV. "Meg/K/Bytes" storage
value format, was only partially applied to VMAC434. The
three variables need to be each multiplied by 1024 after
they are read in. VMAC30 can be used as an example if it
is really important to you to fix.
Thanks to Kevin Wise, Allegheny Power, USA.
Change 06.011 Support for EXD (Express Deliveries) SYSOUT product from
Jan 26, 1988 SAR was added. This change was revised and replaced by
Change 6.037.
Change 06.010 -DD card for DCLOG (IDMS DC LOG) was missing in JCLUXREF
Jan 26, 1988 (the MXG Cross Reference Utility).
JCLUXREF -TYPEDOS internally overrided the LENGTH of the variable
TYPEDOS SHIFT, which should be set in IMACSHFT. Now, there is
UTILCICS no LENGTH for SHIFT forced by TYPEDOS.
-UTILCICS cosmetically improved in listing the contents of
CICS 1.7 Dictionary records.
Thanks to Mark Bercov, Canadian Occidental Petroleum, CANADA.
Change 06.009 -Lines 211 and 961 should have _DB2R. following the DATA=
Jan 26, 1988 and preceding the DB2..... (This only caused a problem
ANALDB2R when MXG DB2 data sets were built with BUILDPDB.)
-All occurrences of 'BY QWHSSSID' should be changed to
'BY SYSTEM QWHSSSID'. (This only caused a problem if DB2
executes on more than one MVS system.)
Thanks to Bill Border, Apollo Computer, USA.
Thanks to Jim Groseman, Duquesne Systems, USA.
Change 06.008 Labels for DB2SRBTM and DB2TCBTM are reversed in lines
Jan 26, 1988 167 and 168.
VMACDB2
Thanks to Jim Groseman, Duquesne Systems, USA.
Change 06.007 Support for the type 28 SMF record from NPM 1.3. This new
Jan 20, 1988 SMF record consolidates the data formerly in TYPE38 and
EX028... TYPE39 (NPM and NLDM records) and the VSAM Session Stats
FORMATS file created by NPM (supported by MXG XNPMSESS member).
TYPE28 There are two APARs, one documentation (OY11468) and one
VMAC28 correcting short record (OY11641) affecting the type 28.
MXG creates twenty-four NPM..... data sets which are
listed in comments at the beginning of VMAC28 member.
You will find no announcement of this record in any NPM
product announcement!
Thanks to Mike Pichowicz, U.S. Trust, USA.
Thanks to Billy Westland, Candle Corporation, USA.
Thanks to Robert Bunn, IBM NPM Level 2, USA.
especially.
Change 06.006 Documentation of TYPE1415 variable RECIND1 on page 494 of
Jan 12, 1988 the MXG Book is one bit off. First, the variable name is
MXG Guide actually RECIND1, and bits 1 thru 7 should be renumbered
as bits 2 thru 8, and bit 1 - reserved should be added.
The code in VMAC1415 was correct.
Thanks to Michael Doyle, Arizona Department Economic Security, USA.
Change 06.005 IDMS Performance Monitor from Cullinet was massively
Jan 12, 1988 enhanced in IDMS 10.1. This change affects only the new
VMACRTE IDMS.... data sets created from their new subtypes.
The TYPERTE data set was not in error.
a.IDMS Performance Monitor Wait times (the new variables
introduced in IDMS 10.1) were off by 10000:
Change all seventy occurrences of PIB8. to MSEC8., and
delete all seventy lines containing 409600.
b.Several BUFF variables were corrected to ARAS, and some
variables were added to TIME12.2 format.
c.Two of the new subtypes of the record (IHDRTYPE=1 and =2)
are segmented records, but the segments were not always
in the correct order, and sometimes were duplicated! MXG
5.5 avoided the problem by skipping over type 1, but it
hit problems with the type 2. With further pressure on
Cullinet and further investigation by all three thankees,
(real cooperative work here, each one found a piece),
Cullinet apparently has PTFs now to fix their broken
records. There may still be sequence problems with their
PTFs, but MXG will reconstruct the real logical record
even when the segments arrive out of order! (Segmenting
is necessary because their journal record size maximum is
256 bytes, but the total SMF data is 500-600 bytes.)
Make sure you have installed the January, 1988, Cullinet
maintenance tape to avoid any problems, and validate!
d.An MXG error in IHDRTYPE=10 subtraction was also fixed.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Thanks to Gayle Bartel, Pizza Hut, USA.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Change 06.004 TYPERTEJ processes IDMS Performance data from a Journal
Jan 12, 1988 File (TYPERTE reads the same data from SMF). TYPERTEJ was
TYPERTEJ off by two bytes, and did not format/length SMFTIME.
Change line 17 from +2 to +4 temporarily fixes the error;
several additional cleanups were also added.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 06.003 a. The labels for CICSTRAN variables SCWTECN and SCWTETM
Jan 11, 1988 should be exchanged (lines 1511-1512).
VMAC110 b. CICS 1.7 increased OPERATOR from 3 to 4 bytes and SIT
from 2 to 4 bytes. MXG correctly read in these variables,
but their stored length is set by its first occurrence
(in 1.6 code!) To correct, insert after line 244 :
INFORMAT OPERATOR SIT $CHAR4.;
Thanks to Mark Bercov, Canadian Occidental Petroleum, CANADA.
Thanks to Richard Evans, Mervyn's, USA.
Change 06.002 Landmark's The MONITOR records can be corrupted by a CICS
Jan 7, 1988 transaction ABEND. The corrupted records confuse the MXG
TYPEMONI test for compressed record format (which formerly issued
a SAS ABORT ABEND 99, to terminate the job). With this
change, neither bad records nor compressed data without
the EXITMONI will cause an ABORT. The first twenty bad
records will be hex printed on the SAS log, but the job
will proceed to read all other records in the input file.
Thanks to John Leath, Fleet Services, USA.
Change 06.001 Variable AVGSWPMS in TYPE75 data set was wrong for swap
Jan 7, 1988 data sets. MXG used DSBUSY (SMF75USE) in this calculation
VMAC75 but NRSAMREQ (SMF75REQ) must be used because swap data
XMAC75 sets use multiple IORBs. The IBM description (SMF manual,
SMF75REQ) and RMF footnote for the equation for AVGSWPMS,
(which allude only to multiple exposure devices) will be
revised to include swap data sets as well. While only the
swap service time was in error, this change protects the
future by also using NRSAMREQ in AVGPAGMS calculation.
Replace DSBUSY with NRSAMREQ in lines 109, 113, 188 and 192.
Thanks to Ken Thomas, Maryland Casualty Company, USA.
LASTCHANGE: Version 6
=========================member=CHANGE05================================
/* COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS */
This is MXG Version 5.5, the production release of MXG Version 5.
MXG Software Status as of December 17, 1987, thru Change 5.173.
What's new in Version 5.
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.
What did not get completed in MXG Version 5.5:
1. VM HPO Release 5 has not been tested. IBM documentation indicates
no change in the data, but no user has confirmed this to be true.
2. BUILDPDB enhancements (which will use the new macro facility) to
more easily control variable selection (eg, XA only, etc.) were not
completed. IMACPDB externalized the controls for you to give you
control without the additional complications and naming conventions
needed when we actually do this enhancement. It is still planned.
3. The MVS Tape Mount Monitor code is not yet operational. The ASM
source code (ASMONTAP) is on this library, but needs modifications.
One volunteer will examine the code next spring.
4. TYPE64 data (see technical note, below) has not yet been added to
ANALDSET algorithms to resolve the incorrect type 64 counts.
5. IMS log processing puts waiting for input transactions in IMSMSGOT
Other 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.
The 5.1 tape was tested for forty days and nites at forty sites.
The 5.2 tape has been executing at over 75 sites since August. All
problems reported were fixed in the 5.3 tape, sent to an additionaly
30 sites. The 5.4 tape was the final pre-release before production,
ans was sent to an additional 30 sites. As promised in Newsletter TEN
(June, 1987), MXG Version 5 production was built before the end of
Fall, 1987 (which ends December 21, 1987). Merry Christmas!!!
TRIVIA: Halloween is equal to Christmas:
OCT 31 = DEC 25
Think about it!
The changes described in this member are already in this MXG version.
They are listed below, after the technical notes. You must read each
description of all changes to ensure that you understand their impact
on your installation. Changes thru 5.99 were on the 5.1 pre-release,
the 5.2 pre-release include changes thru 5.125, 5.3 was thru 5.143,
and changes through 5.165. Changes 5.1 through 5.74 were printed in
Newsletter TEN, and changes 5.75 through 5.166 were printed in the
Newsletter ELEVEN. Changes 5.167 through 5.173 were added after the
newsletter went to press.
COMPATIBILITY EXPOSURES:
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, is defined
in IMACVMON which must be changed if the interval between VM/Monitor
records is not the one minute default set by MXG.
3. BUILDPDB/3 users who have modified those members will find IMACPDB
now contains (hopefully) all the definitions to allow you to locate
your tailoring external (in IMACPDB) instead of internally.
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 supercedes 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.
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.
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.
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).
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).
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 SSQ field can wrap in NCP.
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.
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 millennium, UCC7 designers are looking
for an alternative.
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.
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.
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, SAS rewinds to the beginning of the tape, and
searches for the desired data set. When a SAS DATA step writes a SAS
data set to tape, the tape is first rewound to the beginning, and SAS
searches for the data set name. If no match is found, SAS puts the new
data set at the end of the tape. (If a match is found, SAS starts the
new data set where the old one was found, erasing all old data sets
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 a second tape volume, each rewind
(i.e., each new SAS data set) causes the second volume to be
dismounted, the first volume to be mounted and searched, and then the
second volume remounted and searched, and finally the new data set is
laid down at the end of the tape! This always occurs when SAS DATA
steps 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 "tape format" is created if the DDNAME of the SAS data
set being created starts with TAPE...., and is necessary 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,GEN=0,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))
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.
c. SAS Options which you should be aware of.
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.
==========================Changes======================================
The following changes are already in the Production MXG 5.5 library.
Some of the changes contain the code with line numbers, because those
changes were originally distributed (via prior newsletter, telephone
or telefax to correct immediate problems. Just for your information,
lines to be inserted have a period after the line number they are to
follow; existing lines which needed no change (usually included to
locate the change) have no period in their line number.
While this newsletter hits the high spots, you must read each change
description to ensure that you understand their potential impact to
your installation.
ALWAYS read member CHANGES for last minute changes and notes. This
newsletter is mostly an editied version of CHANGES slightly before
the production library is created.
ALWAYS read each member listed under an impacting change for
additiona comments, notes, and any last minute documentation.
Members DOCVER and DOCVER05 document the entire collection of data
sets created by MXG (DOCVER), and the delta-documentation of data
sets and variables changed between MXG Version 4.4 and 5.5.
NEXTCHANGE: Version 5
=============Changes thru 5.173 as of Dec 17, 1987 ===================
==================completed MXG Version 5.5.==========================
--Changes 5.167-5.173 were added after Newsletter ELEVEN was printed--
Change 05.173 Processing of IMF (Control/IMS) records from Boole &
Dec 17, 1987 Babbage with IMS Release 2.0+ was failing. The test of
VMACCIMS IMSLEVEL NE:'13' caused old format INPUT statement to
be executed. Test is now either LT:'13' or GE:'13'.
Thanks to Dave Lawrence, NCNB of Florida, USA.
Change 05.172 CICS 1.6 dictionary entry for USER field with length
Dec 17, 1987 of zero (i.e., no USER field in your data) caused an
UTILCICS unnecessary, incorrect and superfulous MXG message.
Change 05.171 Support for CICS 1.7 PTF UL14896 (which adds a new
Dec 16, 1987 SCWTETIM field to CICSEXCE exception data set). MXG
IMACPTF creates variables SCWTETM and SCWTECN for the field,
UTILCICS which reports time in suspend because unconditional
VMAC110 storage request was not satisfied.
Thanks to Joe Faska, Chemical Bank, USA.
Change 05.170 Some complexity-level-4 variables had level-3 in their
Dec 16, 1987 labels. Labels are now correct. Member ANALRTM1 (only
ANALROSC existed in pre-releases) was eliminated by rewrite of
IMACROSC ANALROSC. Read important comments in ANALROSC, as it
TYPEROSC now deletes "useless" ROSC.... and RRTM.... data sets.
VMACROSC New macro _ROSCDDN is now defined in memeber IMACROSC
to name the DD to which final ROSCOE data sets are to
be written: _ROSCDDN.ROSCOE, _ROSCDDN.RRTMPSE and the
_ROSCDDN.ROSCAWS "important" data sets. Less important
data sets ROSCOAUD, ROSCOSHU, and ROSCOVPE are left in
the work file.
Thanks to Terry Trevier, Naval Construction Battalion Center, USA.
Change 05.169 The SMF interval recording INTERVAL variable was read
Dec 15, 1987 with TODSTAMP8. (an IBM TOD datetime value) instead of
VMAC90 with MSEC8. (a TOD time value). As a result, it was
printed as -525935 hours and 25 minutes - the correct
number of hours backwards from 01JAN1960 (SAS's zero
datetime) to 01JAN1900 (IBM's zero datetime).It now
will correctly print 00:30:00 for thirty minutes
Thanks to Shawn Wikle, Citibank South Dakota, USA.
Change 05.168 The %%INCLUDE which should have been %INCLUDE now is.
Dec 15, 1987
VMXGVTOC
Thanks to Chuck Rexroad, Perpetual Savings Bank, USA.
Change 05.167 The NETSPY support (Change 5.164) was written with no
Dec 15, 1987 knowledge that Duquesne provided sample SAS code with
ANALNSPY the product. With Duquesne approval, NETSPY support
EXNSPYAP now uses almost all of their variable names, so as to
EXNSPYLU preserve any reports you might have already written.
EXNSPYLI The MXG data sets created are different than in 5.4:
EXNSPYNC NSPYAPPL, NSPYLINE, NSPYLU, and NSPYNCP are now the
VMACNSPY four data sets created. Exits EXNSPYSE and EXNSPYTE
were deleted and EXNSPYLU and EXNSPYLI now exist. Data
from NETSPY 3.0 has now been tested. The default PROC
PRINT reports from Duquesne's sample are in ANALNSPY.
Thanks to Andy Schoentrup, Public Service of Indiana, USA.
Thanks to Luis Motles, Duquesne, USA.
==========Newsletter ELEVEN printed changes through 5.166=============
=============Changes thru 5.166 as of Nov 24, 1987 ==================
Change 05.166 The monthly MXG job can cause lots of tape mounts and
Nov 24, 1987 rewinds when a SAS DATA step writes multiple data sets
MONTHBLD to tape (SAS is preventing duplicate named data sets).
this change is a circumvention which writes the new
data sets first to a temporary disk file, but by using
a DDNAME starting with TAPE...., the data set is built
in "SAS tape format", which can then be copied from
the temporary disk file to the monthly tape with an
INFILE/FILE pair, which eliminates the rewinds. The
temporary TAPETEMP file only needs to be as large as
the largest single data set to be created. See the
code and comments in this member and MXG NL ELEVEN.
Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
==========The 5.4 Pre=Release included changes through 5.165=========
Change 05.165 This change will not affect many sites. It will be
Nov 22, 1987 needed ONLY if you receive the "Compiler Limit is
XMAC7072 Exceeded" error message from SAS on the SAS log.
XMAC71 This error does not occur with BUILDPDB unless you
XMAC73 have added many other SMF records with the PDB Exit
XMAC74 facility. (Only the world's largest PDB builder has
XMAC75 encountered the problem). The compiler limit problem
can not be fixed by SAS until Version 6, but we have
several circumventions available. The compiler has
a 4K table (cannot be expanded, thats the problem)
which sets an upper limit on the number of "Iterative"
DO statements (i.e., DO I=1 to something, DO WHILE,
DO UNTIL, but not DO groups like IF x THEN DO which
predominate in MXG code). There is an upper limit of
99 "Iterative" DO statements in a data step, but the
4K table is used by other SAS statements. The default
BUILDPDB has an actual upper limit of 56, but the MXG
default SMF record proccssing macros only use 24.
These new members are MVS/XA-only copies of their
corresponding VMAC.... member. By stripping out the
MVS/370 code, we reduced the number of "Iterative DOs"
these members would consume. This is only a temporary
solution. In our next version, we will begin to employ
the "new" SAS macros and will dynamically select the
MXG code which will be passed to the compiler, which
should stave off any compiler limit long before SAS
Version 6 is available on mainframes.
Thanks to David Daner, Sun Company, USA, USA.
Change 05.164 Support for the Duquesne network monitor NETSPY user
Nov 22, 1987 SMF record was added. Data for Release 2.3 and 3.0 has
EXNSPYAP been tested, but this still is our first support. s
EXNSPYNC Data sets NSPYAPPL, NSPYNCP, NSPYSESS and NSPYTERM are
EXNSPYSE created; member IMACNSPY sets the SMF record ID.
EXNSPYTE
IMACNSPY
TYPENSPY
VMACNSPY
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.163 Pre-release code for Candle's EPILOG 100 SMF data. The
Nov 22, 1987 MXG redesign of the SAS code provided by Candle has
EXTYEPIL not been tested with data. Only one data set is now t
IMACEPIL created, but this may be changed once real data volume
TYPEEPIL and data structure is known. Call for status before
VMACEPIL you execute this code.
Change 05.162 New member IMACPDB externalizes MXG code which was in
Nov 20, 1987 BUILDPDB/3. The control of the NODUP option, and the
BUILDPDB macro definitions for the MXG variables which will be
BUILDPD3 kept in the PDB data sets was moved to this member, so
IMACPDB that you can tailor PDB function in the IMACPDB exit.
UNLESS YOU HAVE MODIFIED BUILDPDB/3, THIS CHANGE WILL
HAVE NO EFFECT ON YOUR INSTALLATION. Only minor logic
changes were made in this relocation of code. The PROC
MEANS logic which SUMs, MINs, and MAXs variables into
PDB.JOBS from STEPS is now a macro (_PDBSUMS) defined
in IMACPDB, and two macros, _PDB26J2 and PDB26J3 (for
type 26 variables), replace the previous single _PDB26
definition.This is the first step in planned changes
to BUILDPDB to externalize variable selection and to
make user tailoring even easier. IMACPDB will be the
control point for these future enhancements. This is a
good time to say to the original suggestor of NODUP
logic, the formerly "unknown Australian",
Thanks to Phil Bailey, NRMA Data Processing, AUSTRALIA.
Change 05.161 Support for optional Hogan function code data for
Nov 20, 1987 Hogan System application transactions under CICS is
IMACICUS now described and implemented in this member.
Thanks to Chester W. Sutton, Sears Consumer Financial Corp, USA.
Change 05.160 Titles were cleaned up to be more descriptive, and the
Nov 19, 1987 (seldom needed) debug option TYPE110-4 is supported.
UTILCICS
Thanks to Pete Shepard, Ashland Oil, USA.
Change 05.159 ACF2 data for type "T" records has been debugged and
Nov 19, 1987 the pre-release's "congratulations, you found the
VMACACF2 untested code" message has been eliminated. Also, the
ACTFMTOD field is PIB4.2 and FORMAT TIME12.2 and
length 4, as it turns out to be only a time, not a
datetime.
Thanks to Pete Shepard, Ashland Oil, USA.
Change 05.158 CICS 1.7 monitor facility permits your installation
Nov 19, 1987 to EXCLUDE fields in the CICS type 110 records. It is
VMAC110 not my opinion that EXCLUDE is wise (almost for sure,
the variable you exclude will be the one you need),
but this enhancement provides support for CICS 1.7
transaction records created with the EXCLUDE option.
The instructions for using this MXG enhancement are
described by comments in member VMAC110. Search for
the string CICS1.7EXCLUDE (two hits).
Thanks to Dale Mattison, Shared Medical Systems, USA.
Change 05.157 IDMS Performance Monitor (formerly RTE) data can now
Nov 19, 1987 be processed from journal file with member TYPERTEJ as
TYPERTEJ well as from SMF file with member TYPERTE.
VMACRTE
Thanks to Jim Lawrence, Central and South West Services, USA.
Change 05.156 Type 24 SMF (JES2 SPOOL Transfer) records have now
Nov 18, 1987 been validated (and code corrected). SMF24CNT is PIB4.
FORMATS vice PIB1. Format MG024BC: new values for 'A0'X and
VMAC24 'C0'x were added. Format MG024SF: new values for '44'X
and '24'X were added. The value of variable SMF24EOJ
is always zero unless this is the last SYSOUT outgroup
of this job. In that instance, SMF24BCF will contain a
'..1.....'B ('20'X or '24'X), and only then will the
variable SMF24EOJ contain true End-Of-Job condition.
Thanks to John Dundas, International Flavors & Fragrances, USA.
Change 05.155 NETVIEW changes to original type 39 NLDM record were
Nov 18, 1987 not completely corrected by Change 5.57. SCS length is
VMAC39 actually 117 vice 118, because BINDCODE is PIB1. not
PIB2. This well documented change is with
Thanks to Mark Shephard, Dun & Bradstreet EBIC, ENGLAND.
Change 05.154 IMS Log variables DESTLINE and DESTTERM should have
Nov 18, 1987 been read as PIB4. vice PIB2., with HEX8. format.
VMACIMS
Thanks to Freddy Simberg, PK Banken Stockholm, SWEDEN.
Change 05.153 Several changes to Landmark's MONITOR for CICS:
Nov 18, 1987 1.Landmark's MONITOR summary history file records caused
TYPEMONI "Invalid data for TASKNR" because summary record has
nulls (hex 0) value. Error message eliminated and the
variable MONIRECD now correctly contains 'H' for the
History (Summary) observations and 'D' for Detail.
2.Observations in MONIDBDS and MONIUSER will now occur
only if the segment actually contains data. FATNUM
counts DBD segments in record, not the number which
contain data, and UTNUM counts the user segments, but
not the number which contain data.
3.Support for Landmark's SPECIAL 78 optional zap to
TMON Version 7.0 creates CICS 1.7 variables UOWID,
UOWTIME, USER, and NETSNAME in MONITASK data set.
Supplement pages 170-171 describe these variables.
UOWTIME is the decoded time stamp from first 6 bytes
of UOWID). Variable SYSTEM was also added to both
MONITASK and MONISYST data sets with this zap.
4.Initialization of all character values set by bit
testing and SKIP logic for any new data was added
5.Variable DURATM in MONITASK was not calculated for
the first interval during re-processing with DIF().
Two elegant algorithms were provided by two users,
and the shorter one (using POINT= to read ahead to
the next record) was chosen.
Thanks to Kathy Manos, The Stroh Brewery Co, USA.
Thanks to Robert Lewis, Landmark Systems Corporation, USA.
Thanks to Chuck Rexroad, Perpetual Savings Bank, USA.
Thanks to Simon Hendy, British Telecom, ENGLAND.
Thanks to Steve Morton, SAS Institute, ENGLAND.
Change 05.152 The CPU-specific variables PCTCPBYx "defaulted" to
Nov 16, 1987 100% busy for offline CPUs. This had minor impact,
VMAC7072 since variable NRCPUS showed how many were online,
amd also since CAIx flags each CPU as to on/offline
status. Furthermore, PCTCPUBY always accurately had
the true percent of online cpus time which was busy.
Nevertheless, the misleading 100% for PCTCPBYx has
been replaced with a missing value for CPUs which
were not online for the entire interval. (With this
change, the MVS/370 record logic was changed to use
the more robust MVS/XA technique.)
Thanks to Stephen Geard, Commonwealth Bank of Australia, AUSTRALIA.
Change 05.151 I finally accept the need to use the new SAS Macro
Nov 16, 1987 Facility. This change establishes naming conventions
for MXG members. The %MACRO facility works best if
the macro name is the same as the member name (then
AUTOCALL can be used). To facilitate this feature,
MXG will hereafter use names starting with VMXG....
TYPEVTOC for both the member and macro name of MXG-supplied
VMXGVTOC new style macros. To balance this "theft", MXG will
hereafter not use member names starting with USR....
or USER.... - these will always be available to you.
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
who's comment on "using VMACVTOC (now VMXGVTOC) to graze the disk
farm" was under study when this choice was made.
Change 05.150 IMACFILE, taken after an SMF record has been read by
Nov 16, 1987 any MXG code, is self-documented, and is used for many
IMACFILE purposes, including deleting bad SMF records, printing
VMACSMF a "defective" SMF record, etc. IMACFILE is invoked by
VMACSMF. This change "cleans up" comments in VMACSMF,
and now new comments in IMACFILE identify all of the
variables which exist when IMACFILE is taken.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 05.149 Variable ZDATE was added to VMONUSRS, the one-per-user
Nov 16, 1987 summary data set. This provides the date of MXG run,
VMACVMON not the processing date of the data. VMONUSRS is the
summary of all observations in VMONUSRD (which could
be daily, weekly, etc.). Tailored summary (by hour, by
day, etc.) can be done in your code from VMONUSRD.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 05.148 CICS 1.7 UOWTIME was not properly decoded in the pre
Nov 16, 1987 releases of MXG for terminal tasks. Now it is. (Note
VMAC110 that UOWID, the 8-byte character string by which MRO
transactions can be collected was always correct; only
the extraction of its timestamp was in error).
Thanks to Bernadette Young, First Virginia, USA.
Change 05.147 MVS 2.2's catalog address space creates a type 30
Nov 16, 1987 interval record with JOB=IEESYSAS & TYPETASK=CATALOG
VMAC30 which caused "Invalid JESNR" message (no error set).
This change tests for IEESYSAS (system address space)
job name to avoid missing JES number for address
spaces which start before SMF is started.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 05.146 Variable DEN (tape density) in TYPE1415 data was not
Nov 13, 1987 decoded for 3480 (density=38000) devices. Now it is.
VMAC1415
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.145 Variables ROSJOB, ROSTIME, SMFTIME and SYSTEM only are
Nov 13, 1987 in ROSCOE 5.5 and later. The ANALRRTM reports, however
ANALRRTM used these variables, which were not defined in this
VMACROSC member (used only for ROSCOE 5.4A and earlier). This
VMACRRTM change initializes these four variables to blanks or
missing values so that ANALRRTM will work with either
ROSCOE 5.4, 5.4A, or 5.5 RRTM data.
Variable ZDATE was added to all ROSCOE data sets too,
and the code was prettied up.
Thanks to Rich Surgener, Security National Bank, USA.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 05.144 Change 5.44 should have also applied to ANALDB2. The
Nov 13, 1987 variable QXQUERY is now QXSELECT and QXALTBF is now
ANALDB2 QXFETCH in lines 331 and 354 respectively.
Thanks to David Daner, Sun Company, USA.
----Changes thru 5.143 as of Oct 22, 1987 were included in MXG 5.3a--
Change 05.143 Two syntax errors slipped into 5.3. prerelease tape.
Oct 22, 1987 1. Added semicolon to the end of line 2182.1 in member
VMACVMON VMACVMON.
VMACCIMS 2. Added DBDNAME $8. to line 180 (before semicolon)
in member VMACCIMS.
----Changes thru 5.142 as of Oct 15, 1987 were included in MXG 5.3---
Change 05.142 ROSCOE 5.5 support, including the AUDIT record and the
Oct 14, 1987 RRTM (response time) data, has now been added. This
TYPEROSC changes most of the ROSCOE members, and adds several
et. all. new data sets from accounting data. The RRTM records
are now a subtype of the SMF record, and the RRTM data
sets are now built by TYPEROSC. (Member TYPERRTM is
still in MXG if you are not yet on ROSCOE 5.5). Data
for all 5.5 records has been tested, except for the
5.5 Audit record (but that's not likely to cause you
any problem - ADR doesn't document how to enable that
new record, though they will tell you how by phone!)
Change 05.141 Boole & Babbage's IMF (formerly Control/IMS)
Oct 14, 1987 optionally will capture I/O at the DDNAME within
VMACCIMS DBDNAME for those DBDNAMEs with multiple DDNAMES. This
change adds the new variable DDNAME to the CIMSDBDS
data set. If the DDNAME is not blank, this is a DD
entry, otherwise it's a DBD.
Thanks to Ron Root, Sun Company, USA.
Change 05.140 The subtype 1 IDMS Performance Monitor record from
Oct 14, 1987 the new PMAM available in IDMS 10.1 is being created
VMACRTE in error. This change skips over the subtype 1 PMAM
data until Cullinet provides a modification (accepted
but not yet available) to correct their error.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Change 05.139 The BDT (Bulk Data Transfer) record has now been
Oct 14, 1987 tested with real type 59 SMF records. Two changes were
VMAC59 required to VMAC59: line 1620, TRANTYID replaced
SMF59TID in the test, and line 1670's SMF59OFG field
is now input with a $CHAR1 instead of the incorrect
$CHAR4.
Thanks to Doris Burdick, U.S. Department of Defence, USA.
Change 05.138 The IMS log processing with TYPEIMS from MXG 4.4
Oct 11, 1987 fails. Most transactions were being thrown away
IMACIMS because of the changes in the IMS records introduced
TYPEIMS in 1.3 and 2.1. The pre-releases 5.1 and 5.2 modified
VMACIMS the MXG 4.4 code to stop deleting records, and did
correctly capture all resource data, but introduced
occasional transposition of the LTERM and TRANSACT
values. Most of all, I just did not understand the
logic of the donated code. This change marks the first
IMS log processing code which I actually wrote and
understand. The only original code in TYPEIMS/VMACIMS
now is the merge of the 07-08 log records. Larry
Alexander's fine IMS paper and 2.1 data were used to
now properly assemble all simple IMS transactions
perfectly. The existence of an 07/08 causes an
observation in IMSTRAN to be created, and if an 01
record was found, the message queue records (01,03,31,
35, and 36 are then collected under the transaction's
LTS (line, terminal, sequence) by their message queue
DRRN (dataset and record number) and the time stamps
(ARRVTIME,ENQTIME,GUTIME,STRTTIME,TMCNTIME, GUOUTIME,
ENDTIME and DEQTIME) are captured. Variables INBITS
and INCNTS identify which and how many IMS log records
were collected for this observation in IMS tran. This
code has processed many IMS log records, and seems to
be correct in assembling matching sequences. For some
very complicated sequences (those which do create an
01 for each 07, for example) will be fully assembled
into IMSTRAN for resource measurement and transaction
counting. The worst that can happen is that some of
the time stamps may be missing if MXG can't find the
message records corresponding to the 07 and 08 log
records. I am still investigating WFI (wait for
input) transactions, and may provide additional code
in the future to re-examine IMSTRAN see if the IMS
response for these unique transactions can also be
measured. In summary, the 5.3 IMS code is thought to
be completely accurate for resources and counting, and
either captures the correct response time, or sets the
response time missing. It's not done, but it's so
much better than anything before that it should be
used now for any IMS log processing.
Thanks to John D. Pike, American Airlines, USA.
Thanks to John Lemkelde, Pennsylvania Blue Shield, USA.
Thanks to Finn Poulsen, DANFOSS A/S, DENMARK.
Change 05.137 A syntax error resulted from a missing AXIS2 statement
Oct 11, 1987 in a PROC GPLOT. New line 370.1 should be:
GRAFRMFI AXIS2 COLOR=WHITE LABEL=('LOGICAL SWAP')
Thanks to John Potter, Mitsubishi Electronics, USA.
Change 05.136 ROSCOE 5.5 TERMNAME variable is now only in the signon
Oct 4, 1987 record, but 5.4 had it also in the logoff record. The
ANALROSC result was a blank value for TERMNAME. To correct,
change line 8 to now read:
PROC SORT DATA=ROSCOFF (DROP=TERMNAME);
Thanks to Richard Olimpio, O. M. Scott, USA.
Change 05.135 RMF Cache Reporter records which have only one storage
Oct 4, 1987 director segment caused INPUT STATEMENT EXCEEDED
VMACACHE RECORD LENGTH, "STOPOVER" condition. (All data tested
had two!) These changes were made:
Insert new lines:
@15+OFFSTAT GSLEN PIB2. 237.1
@; IF GSLEN=80 THEN INPUT 245.1
(SD2ID=SD2IDCU OR GSLEN=40) ); 258.1
Remove the "SD2ID=SD2IDCU);" at end of line 258.
Thanks to Benny J. Arnold, Kansas City Computer Center, USA.
Thanks to Don Tuttle, Kansas City Computer Center, USA.
Change 05.134 If you wanted to build the PDB data sets and only want
Oct 4, 1987 to spin once (for example, building from a monthly SMF
BUILDPDB file), you could not. Setting IMACSPIN to 1 caused the
BUILDPD3 un-matched records to be spun twice, since _SPINCNT
was compared with "1" in line 375/385 (BUILDPDB/3).
Changing the "1" to "0.5" solves this inconsistency.
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
Change 05.133 1.VM/Monitor USER records contain no logon flag. MXG
Sep 23, 1987 can recognize a logon if any of the DIF()'d counters
Nov 29, 1987 went negative, but that is not always the case. Now,
ANALVMON MXG compares the delta minutes since the last record
IMACVMON for this user with a new macro (_INTRVL, in IMACVMON)
VMACVMON in which you specify your expected interval duration.
If more than two expected intervals have been missed,
MXG assumes a LOGON and reinitializes. (Note that if
suspension occurs, records can be skipped.) The actual
comparison is IF DIF(STARTIME) GT 2 * _INTRVL THEN ...
The default value for _INTRVL is 1 minute. If you are
writing 10 minute intervals and you do not change the
value of _INTRVL in IMACVMON, all data will be zeros.
2.Twenty-one VM/Monitor durations (CPU times, Page and
I/O waits, etc.) are in counters which decrement from
a large positive number down to zero. MXG did not get
the correct value for the zero-crossing interval. The
problem only occurs when the system stays up for more
than a day (after 38 hours at 50% IDLETM, it resets).
The error caused the zero-crossing variable to contain
a very large negative value for that one interval. The
decrementing counters are identified by the syntax of
y=-DIF(x)/4096, which calculates the negative delta of
counter x into variable y. This change inserts a new
test for negative y following each -DIF() to correct:
y=-DIF(x)/4096;
IF . LT y LT 0 THEN y=y + 1E-6*16**9;
This fix was revised Nov 29, when IBM Level 2 made
it clear: six bytes of FFFFFFFFFFFF is stored. MXG
5.3 incorrectly used just 16**9, the 5.4 temporary
circumvention used x/4096 pending this truth. Note
that computerese 1E-6*16**9 is simply 16 to the 9th
divided by a million, but the 68719.476736 decimal
equivalent leaves me cold. (Six bytes of FF, INPUT
as PIB6.6 is decimal 281474976; divided by 4096 to
get seconds, becomes 16 to the 9th over a million!)
3.I/O counts in VMONDEV are accumulated by DEVADDR since
last IPL, and MXG failed to de-accumulate the variable
CNTVIOCT. Macro _ANALDEV is now defined in VMACVMON
to sort and correctly calculate CNTVIOCT into VMONDEV.
(Note for recipients of pre-releases 5.1 or 5.2: This
de-accumulation WAS correct in the VMPDB.DEV data set
built by ANALVMOS. Now, the de-accumulation is done
in building VMONDEV). This change could impact the
compatibility of MXG. If you used VMONDEV from MXG 4.4
you probably did your own de-accumulation, and now you
will need to remove that de-accumulation.
Thanks to George Moskwa, Cole National, USA.
Change 05.132 If SAS OPTION NOTEXT82 is in effect, a syntax error in
Sep 23, 1987 creating the temporary $TCLASS reporting format in one
ANALCICS of these sample CICS reports. The right hand side of
the format values must be enclosed in single quotes,
or OPTIONS TEXT82 can be specified.(Our testing now
specifies NOTEXT82!)
Change 05.131 Variables INCONT, LOGONID, MSGLEN and ORGENT in the
Sep 23, 1987 TYPEIMS data set (from IMS Log records), which exist
VMACIMS in the RACF segment if you have RACF or ACF2 with IMS,
but were not in the KEEP list for IMS0103 data set.
As a result, they were blank. (FYI, they are defined
in member EXITRACF.)
Thanks to John Lemkelde, Pennsylvania Blue Cross, USA.
Change 05.130 TSO/MON 5.1 support has now been validated with data
Sep 21, 1987 containing the optional ACCOUNTing fields. Without
VMACTSOM this change, STOPOVER abend occurred if the additional
optional data was present in the record.
Line 2417 changed to INPUT NRACCTFL PIB1. @;
Lines 24192 and 24193 were deleted. (MINUS8= and INPUT)
Thanks to John Leath, Fleet Information, USA.
Change 05.129 The MONIUSER data set from Landmark's MONITOR has now
Sep 21, 1987 been validated. CLOCKTM is now calculated by 1E4, and
TYPEMONI the code was restructured to properly initialize.
Thanks to Chuck Comstock, Hallmark Cards, USA.
Change 05.128 Jobs with JCL errors in PDB.JOBS had blank value for
Sep 18, 1987 TYPETASK because it was not in KEEP list for the type
BUILDPDB 26 data. TYPETASK was added to _PDB_26 definition.
BUILDPD3
Thanks to Lee Salley, Westinghouse, USA.
Change 05.127 Several minor changes.
Sep 16, 1987 1.ANALAUDT and ANALDB2R were restructured to contain
ANALAUDT both JCL and SAS code. With the SAS JCLEXCL option:
ANALCICS %INCLUDE SOURCLIB(ANALDB2R)/JCLEXCL;
ANALDB2R SAS will skip over the JCL and execute the SAS code.
EXITMONI Alternatively, the JCL can be edited and submitted to
produce the report from either an MXG PDB library or
directly from SMF data. Both ANALAUDT and ANALDB2R now
permit date selection via the SYSPARM parameter on the
EXEC statement, as described in the comments. MXG will
use this pattern in future ANAL.... members.
2.ANALCICS PROC FORMAT at line 465 needed quotes on the
right hand side if SAS OPTION NOTEXT82 is specified.
3.EXITMONI installation instructions were improved.
Change 05.126 MXG Format $MGIMFFP was defined in lines 411-414 of
Sep 14, 1987 this member in MXG 4.4, but is not in MXG 5.2 member.
FORMATS If you use the first step of JCLTEST to add formats to
your existing SASLIB data set, you will not see this
error. However, if you create a new SASLIB using the
5.2 FORMATS member, the format will not exist. (Since
I tested by adding the new formats, my testing failed
to catch the error - guess who's testing philosophy
has been changed!). To correct the 5.2 FORMATS member,
copy lines 411-414 of 4.4 FORMATS member after line
615 of 5.2 FORMATS member.
----Changes thru 5.125 as of Sep 10, 1987 were included in MXG 5.2---
Change 05.125 JES2 sites using NJE will now find the PDB.NJEPURGE
Sep 10, 1987 data set automatically built by BUILDPDB will contain
BUILDPDB the non-execution purge records for NJE jobs. All SR
(SYSOUT Receiver) purge records and JR (job transmit)
purge records which do not represent actual execution
will be in this PDB data set. (Formerly, these purge
records were deleted by BUILDPDB). This data set may
be useful in tracking NJE job transmission input
delays as well as NJE SYSOUT delays. Additional work
in this NJE measurement area can be expected.
Thanks to Gary Zolweg, National Semiconductor, USA.
Change 05.124 Support for ROSCOE 5.5 Accounting records was added.
Sep 10, 1987 The ROSCOE Response Time Monitor (RRTM) data is now a
EXROSALL subtype of the 5.5 account records written to SMF.
EXROSATT Several new ROS..... data sets are created from the
EXROSCON new ROSCOE 5.5 account records. On October 11, 1987
EXROSDSF (in MXG 5.3), RRTM record support for ROSCOE 5.5 was
EXROSHEX added to these members, and the RRTM data sets are now
EXROSLIB created with TYPE/VMACROSC. The AUDIT record (new in
EXROSPUR ROSCOE 5.5) support was also added, but no audit data
EXROSSHU records have been available to test yet.
EXROSSOR
EXROSVPE
IMACROSC
VMACROSC
Change 05.123 VM Monitor summarization & documentation were cleaned
Sep 10, 1987 up in testing 5.1. The SEEKRPRT has been added and the
ANALVMOS documentation improved. VM Execs referenced in the MXG
DOCVMOS supplement now exist. EXECTEST is the VM equivalent of
EXECPDB JCLTEST, EXECPDB tests the MVS PDB building under VM,
EXECTEST and EXECEMAC provides an easy way to edit MACLIBs.
EXECEMAC
Change 05.122 Installation modifications to type 26 records caused
Sep 9, 1987 MXG problems because section lengths were not used to
VMAC26J2 +SKIP over new data. This change redesigns TYPE26J2 to
fully use the section lengths for immunity to change.
Thanks to Rob Clairmont, The Laurier Group Ottawa, CANADA.
Change 05.121 Several ANAL.... report members created unnecessary
Sep 9, 1987 messages (not referenced, uninitialized, etc.) which
ANALPROG were irritating but not critical errors to new users.
ANALESV
ANALTAPE
Thanks to Kathleen A. Morrison, Hit or Miss Inc, USA.
Change 05.120 The IDMS Performance Monitor (Change 5.95) did not
Sep 9, 1987 process the second subtype 1 record, which is now
VMACRTE recognized and creates the IDMSTASK data set.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Change 05.119 Variables EXCPTODD/EXCPNODD and IOTMTODD/IOTMNODD in
Sep 9, 1987 TYPE30 data sets are missing if the program had no DD
VMAC30 cards. Uncommon, it does happen. MXG moved several
lines outside the NUMDD=0 do group to set these four
variables zero rather than missing in this instance.
Thanks to Kenneth D. Jones, Maritime Telephone and Telegraph, CANADA.
Change 05.118 Only for the TYPE74 data set and only under MVS/370,
Sep 9, 1987 the variable DEVNR (the MVS/XA and BUILDPDB/3 expected
VMAC74 variable name for the old UNITADR MVS/370 variable) is
missing. Correct for MVS/370 with the new line:
DEVNR=UNITADR; 172.1
to store unit address in DEVNR. MVS/370 sites would be
wise to position for MVS/XA by changing UNITADR to
DEVNR now in all programs using MXG data sets.UNITADR
does not exist under MVS/XA, DEVNR replaced it.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 05.117 VM Account support for the type 08 (user disconnect
Sep 9, 1987 or log off) account card record was added, creating
TYPEVM new data set VMLOGOFF. Variable LUNAME was also added
EXVMLOFF to the VMDISK, VMLINK, VMLOGON and VMLOGOFF data sets.
FORMATS LUNAME will contain the SNA (VTAM) terminal name for
SNA terminals, useful for identification of terminals
being used by VM users. In VMDEVICE data set, variable
DEVICECL is now decoded by new format $MGVMADV, which
permitted reducing DEVICECL from 8 to 1 byte.
Change 05.116 The format used in the PUT function at line 46 was
Sep 9, 1987 corrected from WEEKDAY3. to WEEKDATE3. to create the
MONTHBLD name of the day of the week as a character variable.
Thanks to Barry Lampkin, Blue Cross of Mass, USA.
Change 05.115 MXG error messages VMAC110.2 and .3 were revised to be
Sep 3, 1987 more descriptive when MXG detects a change in record
VMAC110 format due to CICS maintenance.
Thanks to Laurie Bigelow, UCCEL, USA.
Change 05.114 Variable SD2DEVNR was mis-spelled in the KEEP list for
Sep 3, 1987 CACHETY data set, and was thus not kept. Correct the
VMACACHE obvious mis-spelling.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Change 05.113 PGBLPGS, STGUTIL, and DRUMUTIL variables in VMONPERF
Aug 31, 1987 were not calculated in non-HPO data. COPY lines
VMACVMON 1545-1546 to become 1113.1 and 1113.2. MOVE line 1547
to 1113.3. Change 1113.1 to be: PGBLPGS=MAXSIZEP;
Thanks to ???, ???.
Change 05.112 This simple example of reading SYSLOG to track IEF244I
Aug 21, 1987 (job delayed due to tape allocation) messages from the
XSYSLOG JES2 SYSLOG file to create MXG dataset IEF244I will be
expanded in future versions of MXG to provide extended
analysis of important SYSLOG messages. Suggestions for
other events which are only available from SYSLOG are
solicited. This will not be expanded until Version 6.
Thanks to John Maher, American Honda Motor Company, USA.
Change 05.111 The bit testing to create TYPE25 (JES3 only) variables
Aug 21, 1987 ALOCBYDD and ALOCAUTO were reversed. Reverse the 0 and
VMAC25 1 values in lines 57-58 and lines 61-62.
Thanks to Miss C. Keelan, Commonwealth Bank of Australia, AUSTRALIA.
Thanks to Stephen Geard, Commonwealth Bank of Australia, AUSTRALIA.
Change 05.110 The decode of RECFM in both VTOC and TYPE1415 logic is
Aug 19, 1987 moved to new member VMACRCFM, and additional record
VMAC1415 formats (formerly OTHR, like FBA, FBS, etc.) have been
VMACRCFM added to (hopefully) completely decode RECFM and to
VMXGVTOC eliminate blank or OTHR values.
Thanks to John Potter, Mitsubishi Electronics, USA.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.109 This change fixes an error which only existed in the
Aug 19, 1987 pre-release 5.1. For jobs which went through the SPIN
BUILDPDB data set, the variable SYSTEM was usually blank. The
BUILDPD3 change affected the five data sets built at line 284
(JES2, line 294 JES3). IN= logic was added to TYPE....
in the SET statement and the storing of SYSTEM into
the five SYSxxx variables was made conditional.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.108 Some MXG modules now use the "new macro, or %macro"
Sep 3, 1987 facility of the SAS System. (MXG has always used many
JCLUXREF "substitution" or old-style SAS macros). The use of
VMXGVTOC the "new macros" requires the SAS system option MACRO
to be enabled (SAS 5.16 defaults to NOMACRO). This is
done either by adding MACRO to the OPTION list on the
EXEC SAS statement for a step, or by changing the SAS
system default (PROC SETINIT by the SAS installer.)
The listed members used the "new macro" facility and
their JCL example now specifies MACRO. Hereafter, all
MXG members that define "new macros" will be so noted.
Thanks to Ray Dickensheets, Yellow Freight System, USA.
Thanks to John Potter, Mitsubishi Electronics, USA.
Thanks to Rob Ray, EUA Service Corporation, USA.
Change 05.107 The variables TAPE3420 and TAPE3480 are now included
Aug 14, 1987 in the PDB.STEPS and PDB.JOBS data sets. Both members
BUILDPDB were re-numbered
BUILDPD3
Thanks to Dennis Dwyer, CITICORP, USA.
Change 05.106 The type 128 record which can be created by NPM is
Aug 14, 1987 actually supplied by IBM as source code for the exit.
IMACNPM Since the record id is not fixed at 128, this change
VMAC128 adds member IMACNPM in which you tell MXG the actual
record ID of the NPM VTAM Session records.
Thanks to Joe Faska, Chemical Bank, USA.
Change 05.105 Support for SYNCSORT user SMF record was added. The
Aug 14, 1987 SYNCSORT data set is created. These members replace
EXSYNSOR XMACSYNC (Change 5.39).
IMACSYNC
TYPESYNC
VMACSYNC
Change 05.104 Support for CINCOM SUPRA 1.1 System log file produces
Aug 14, 1987 three data sets, SUPRDBMX, SUPRFILE, and SUPRINIT.
ANALSUPR Sample reports are in member ANALSUPR.
EXSUPDBM
EXSUPFIL
EXSUPINT
TYPESUPR
Thanks to Mark Degner, Navy Finance Center, USA.
Change 05.103 VM/Monitor Seek Analysis had one too few percent signs
Aug 12, 1987 which caused syntax errors. In line 459, change the
ANALVMOS '%' to '%%'.
Thanks to Steve Smith, Hammermill Paper, USA.
Change 05.102 Default SMF record id numbers for ACF2, MODEL204,
Aug 10, 1987 ROSCOE, and TSO/MON were changed to the inpossible
IMACACF2 values of 512 or higher, to prevent STOPOVER ABEND in
IMACM204 new sites testing JCLTEST.
IMACROSC
IMACTSOM
Thanks to Joe Faska, Chemical Bank, USA.
Change 05.101 Format for CPUWAIT4-8 and PCTCPBY4-8 was not provided.
Aug 10, 1987 This only affected the 5.1 tapes. Change the CPUWAIT3
VMAC7072 in line 298 to CPUWAIT8. Change the PCTCPBY3 in line
316 to PCTCPBU8. Change CPUWAIT3 in line 479 to read
CPUWAIT8, only for looks since 370 can't run on 3090.
Thanks to Ruth Heidel, UCCEL, USA.
Change 05.100 CICS 1.6.1 FCGETCN field is increased from two to four
Jul 31, 1987 bytes by PTF UL10276.
IMACPTF IMACPTF - Replicate the logic for AP40463, and change
UTILCICS AP40463 to UL10276.
VMAC110 UTILCICS- Replicate lines 354-357 (for AP40463) and
change the test to 'FC-GET-COUNT' and set
PTF='UL10276';
VMAC110 - Replace lines 546-547:
FCGETCN PIB2.
FCPUTCN PIB2.
With these four lines:
@;
IF _UL10276 THEN INPUT FCGETCN PIB4. @;
ELSE INPUT FCGETCN PIB2. @;
INPUT FCPUTCN PIB2.
Thanks to Malcolm Morgan, Wachovia Bank, USA.
Thanks to Dave Feigenbaum, UPS, USA.
******Changes through 5.99 were on the first pre-release of MXG 5.1 ****
Change 05.99 The two new SMF records created with MVS 2.2 are now
Jul 31, 1987 available. A type 36 is written for each import/export
TYPE36 of the ICF catalog. The type 41 is written for each
VMAC36 access to a Data-In-Virtual object. The type 41 is
EXTY36 currently incomplete; the job name, readtime, etc of
TYPE41 the task using the DIV object was inadvertently left
VMAC41 out of the SMF record in ESP. A PTF is expected that
EXTY41 will add the data and probably break the VMAC31 code,
but I don't have the PTF number or change info yet.
With this change, MXG Version 5.1 Supports MVS 2.2.
Change 05.98 Minor, cosmetic change in creating SMF71IS1 and IS2
Jul 31, 1987 field names from the SMF71AVA field, none of which are
VMAC71 kept.
Change 05.97 This standalone JCL and program will decode the SAR
Jul 26, 1987 account records from its non-SMF journal file.
XMACSAR
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.96 MXG DASD Storage Measurement is now supported by these
Jul 26, 1987 new members. The earlier XMAPVTOC program has been up
FMXGUCBL dated and is now an executable (new style) SAS macro
VMXGVTOC %VMXGVTOC, which produces the VTOC and FREE data sets
TYPEVTOC from the DDNAME of DISK. These two data sets describe
the contents of that volume for billing DASD storage
and/or DASD capacity measurement. To measure all DASD
volumes in one execution, and to avoid JCL errors due
to offline volumes, the MXG-provided SAS function
FMXGUCBL dynamically allocates all online DASD volumes
to DDNAMES of DDnnnnnnn, and returns the number of
volumes found online. The example program in VMXGVTOC
can be executed to create the MXGVTOC and MXGFREE data
sets from all online DASD volumes.
Change 05.95 Support for IDMS 10.1 (pre-release) completed. The new
Jul 26, 1987 new "Application Monitor" record subtypes create ten
VMACRTE new IDMS.... data sets. The original TYPERTE data set
EXRTEARA is now created from the subtype 1 record. See comments
EXRTEBUF in VMACRTE for documentation and comments about data.
EXRTECDM MXG variable names are the same as the Culprit names
EXRTEDBK used in Cullinet's PMIRPT00 example report program for
EXRTEERU this IDMS Performance Monitor (formerly the Run Time
EXRTEINT Evaluator product, hence the RTE acronym). See Change
EXRTEJRN 5.120.
EXRTEPGM
EXRTESTG
EXRTETPI
Thanks to Terry Layman, Cullinet, USA.
Change 05.94 Validation of ACF2 record support has been completed.
Jul 22, 1987 See updated description of change 5.68.
Change 05.93 PDB.JOBS variables RACFGRUP RACFTERM and RACFUSER were
Jul 22, 1987 kept in _PDB30_4 instead of _PDB30_5. Thus these three
BUILDPDB variables in PDB.JOBS came only from the initiate 30_1
BUILDPD3 data set. A value placed in RACFTERM by an SMF exit at
terminate was not picked up by MXG. With this change,
the three RACF variables in PDB.JOBS will have their
value from the 30_5 if it exists, or from the 30_1 if
no job termination record was found. It was supposed
to have been this way all along!
Change: blank the three variables in line 84 and add
the three variables in lines 102-103.
Thanks to Kenneth D. Jones, Maritime Telegraph and Telephone, CANADA.
Change 05.92 RMFINTRV standalone execution had an extra semi-colon
Jul 21, 1987 in an include in the commented out code. Fixed.
RMFINTRV
Thanks to Steve Glick, Southern Methodist University, USA.
Change 05.91 If SRBCOEFF is zero, a division exception occurred in
Jul 21, 1987 MVS/XA. The division is now protected.
VMAC7072
Thanks to John Mueller, ARMCO Steel, USA.
Change 05.90 The CICS 1.6 variables ICV and ICVTSD were incorrectly
Jul 21, 1987 calculated. ICV=ICV/76.8 and ICVTSD=10*ICVTSD/3 in the
VMAC110 1.6 code only.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.89 The variables QISEDBD and QISEPAGE in DB2STAT1 dataset
Jul 14, 1987 were wrong. Delete the two lines in ANALDB2:
ANALDB2 QISEDBD =DIF(QISEDBD);
QISEPAGE=DIF(QISEPAGE);
because these two variables are not accumulated.
Several other discrepancies between MXG and DB2PM are:
a. QISEFREE "FREE PG IN FREE CHAIN" reported in DB2PM
is (incorrectly) the value from the previous record.
b. DB2PM "Record Time" is QWHSSTCK-DURATM, the start
time of the interval, not the SMF record timestamp.
c. The DB2PM calculations for EDM Pool percentages are
frequently total several percent more than 100. This
is because QISEFREE is from the previous interval, as
noted above.
d. DB2PM reported "datasets open - current" is always
greater than the "maximum" value reported, and the
"current" number equals both QTDSOPN and QDDSMAX in
the record (which seems in error itself). The value
under "maximum" seems close to current; in most of
intervals it is equal to QB1TDSO (and there were no
higher buffer pools used). In other intervals the
printed "current" value is 2, QB1TDSO is 1 and no
other buffer pools were used.
e. DB2PM is flat wrong on the report page which has
both "AGENTS SERVICES - EXECUTION UNIT SWITCH" (for
QVASX... fields) and "STORAGE MANAGER (QSST.. fields).
The first six lines of the report are repeated in
lines 7-12 (which should be the first six S.M. lines).
Lines 13-19 contain what should be in lines 7-13.
What should be in lines 14-19 does not exist in DB2PM!
f. Other than that, DB2PM agrees with MXG.
Thanks to Martha Hall, Metropolitan Life, USA.
Change 05.88 The new IMS log processing logic (MXG Change 5.66) was
Jul 14, 1987 validated in detail by three sequential transactions
TYPEIMS under IMS 2.1. The new logic stood up to the test. The
only data we seem to loose now is the data from the
IMS type 36X log record, DEQTIME. The MSGDRRN value of
the 36 record is different than the MSGDRRN in the
0103 record; this prevents the 36 from matching. This
matter is under discussion with IBM. For now, IMS 2.1
is supported by MXG, but the three DEQ.... variables
are missing in the IMSTRAN data set from IMS log data.
Thanks to John D. Pike, American Airlines, USA.
Change 05.87 Support for the SMF record written by the STOPX37
Jul 12, 1987 product.
EXTYX37
IMACX37
TYPEX37
VMACX37
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.86 The labels for variables READY11 thru READY15 were all
Jul 11, 1987 for READY11 in the TYPE70 data set.
VMAC7072
Thanks to Ruth Heidel, UCCEL, USA.
Change 05.85 The RMF CACHE Report SMF support added by Change 5.31
Jul 07, 1987 provides correct device segment data, but only the 1st
VMACACHE control unit segment was read. Major logic changes are
in the logic to associate the control unit segments
properly with their device segments. MXG has now been
tested with REPORLVL data values of 17 and 18.
Thanks to Jon Sahl, New York Life, USA.
Change 05.84 For CICS 1.7, the CICSYSTM (global performance data)
Jul 01, 1987 variables CPUTCBTM and OWSTCPTM were wrong. This had
VMAC110 no effect on the CICSTRAN data set variables. A minor
error in calculation of TASKCPTM in CICSYSTM was also
corrected by this change. The figure on page 66 of
the MXG Supplement is accurate for CICS 1.6; the below
figure is correct for CICS 1.7 and uses the CICSPARS
descriptions of maintask, subtask, etc., values:
CPUTCBTM SRB
|-----------------------------------------------| |--|
MAINCPTM SUBTCPTM
|--------------------------------------|--------|
KCCPUTM USRCPUTM OSWTCPTM
|-------|------------------------------|--------|
| JCCPUTM TCCPUTM TASKCPTM |
|---------|---------|----------|
"CICS" "APPL"
|---------------------------|----------|
1. Change both occurrances (lines 821 and 884),
TASKCPTM=USRCPUTM-TCCPUTM;
to read
TASKCPTM=USRCPUTM-TCCPUTM-JCCPUTM;
2. Change line 883, which now reads
CPUTCBTM=SUM(KCCPUTM,OSWTCPTM,USRCPUTM);
to read:
CPUTCBTM=OSWTCPTM;
3. Insert after line 884 these five lines:
CICSCPTM=KCCPUTM+TCCPUTM+JCCPUTM;
MAINCPTM=TASKCPTM+CICSCPTM;
SUBTCPTM=OSWTCPTM-MAINCPTM;
OSWTCPTM=SUBTCPTM;
TOTLCPTM=MAINCPTM+SUBTCPTM+CPUSRBTM;
4. Add these five new variable names to the KEEP=
list (lines 66-81) for _CICOTHR.CICSYSTM.
Thanks to Joe Faska, Chemical Bank, USA.
Change 05.83 CICS 1.7 sites with a large number of user clocks or
Jun 29, 1987 counters added to their type 110 SMF record received
VMAC110 the "Invalid task number" MXG error message because of
UTILCICS an MXG error. The string of connectors can be over 200
bytes, but MXG had only a 200-byte character variable.
The confirming symptom of this error is MCTSSDCN, the
number of "connectors", will have a value over 100 in
the MXG error message. Additional lines were changed
UTILCICS and VMAC110; only the execution-critical code
changes are printed here:
After line 493 (END;) and before line 494 (ELSE INPUT)
insert the following five lines:
ELSE IF CONNBYTE GT 200 THEN DO; 493.1
INPUT CICTRANV $CHAR200. @; 493.2
SKIP=CONNBYTE-200; 493.3
INPUT +SKIP @; 493.4
END; 493.5
Thanks to Shawn Weikel, CITIBANK, USA.
Change 05.82 Support for the modified type 6 SMF record written by
Jun 29, 1987 the SAR (SYSOUT Archival and Retreival) product from
VMAC6 Central Software and the VPS (Virtual Printer Support)
product from 1:
New line 111.1:
ELSE IF SUBS=50658 THEN SUBSYS='SAR';
Change line 137:
ELSE IF SUBSYS='JES3' THEN DO;
To read:
ELSE IF SUBSYS='JES3' OR SUBSYS='SAR' THEN
Thanks to Frank Bolan, Bergan Brunswig, USA.
Change 05.81 The CICS 1.7 variable UOWID (which ties a transaction
Jun 24, 1987 in an MRO Terminal Owning Region to the same logical
VMAC110 transaction in other Application Owning Regions) is
now formatted as a $HEX16 so it prints "better". The
first six bytes are the timestamp of attach and they
are now decoded into new variable UOWTIME. (For DL/I
batch jobs, only the time, HHMMSS, is actually in the
data record. The SMF record date is used for DL/I.)
Change 05.80 The interval of aggregation of the RMFINTRV data set
Jun 16, 1987 (set by macro _DURSET) is now defined in IMACRMFI so
IMACRMFI that inline changes do not have to be made. This is
RMFINTRV consistent with the description in the MXG Supplement.
Change 05.79 XMACVTOC now supports 3380 devices. This "extra" MXG
Jun 14, 1987 program reads the VTOC of a device pointed to by the
XMACVTOC DISK ddname, and provides the mapping of the disk
size and physical location of all data sets and free
spaces on a volume. You should compare this program
with MAPDISK on the SAS Sample library. This member
was replaced July 31, 1987 by Change 5.96.
Change 05.78 Support for DFSORT Release 9 which added new variables
Jun 14, 1987 to the type 16 SMF record. Access methods used, start
VMAC16 and end of sort timestamps, SRB CPU time, work data
set tracks and extents, I/O counts (SORTIN, SORTOUT
and total work), and sort return/reason codes are now
available for each sort execution. This member was
renumbered.
Change 05.77 1.The SYSTEM variable in PDB.PRINT will frequently be
Jun 10, 1987 wrong; usually the value of SYSTEM in PDB.PRINT was
BUILDPDB from the Step (30_4) record. This change corrects this
BUILDPD3 error and creates variables SYSINT, SYSSTP, SYSJOB,
SYSPUR and SYSPRN in PDB.JOBS to identify the system
from which each of the five records was found. As a
result of this redesign, SYSTEM in PDB.JOBS will come
from the first non-blank value in this ordered list:
SYSSTP, SYSJOB, SYSINT, SYSPUR, or SYSPRN to ensure
SYSTEM is non-blank and contains execution system if
execution records were found, otherwise it contains
the purge or print system id.
2.JOBCLASS was added to the PDB.PRINT and PDB.STEPS
data sets (from the PDB.JOBS) at the request of many.
3.PROTECT=ZZZZZ was added to the three CICS data sets
built by BUILDPD3 so that it would be consistent with
the JES2 version BUILDPDB, which has always used the
PROTECT= keyword.
Thanks to Georg Simon, Prudential, USA.
Change 05.76 The value of IRESPTM in CICSTRAN was set to missing if
Jun 10, 1987 any bit was on in TASERRFG, as these bits indicated an
VMAC110 error in timings. The bit meanings have been changed
FORMATS in CICS 1.6.1 and CICS 1.7 and CMF no longer corrupts
its timings. Therefore, IRESPTM is no longer dependent
on TASERRFG, and will always be calculated as ELAPSTM
minus WTTCIOTM. Format MG110ER has been changed to now
properly decode the new bit meanings of TASERRFG.
Thanks to Jo Engles, Virgina Light and Power, USA.
Change 05.75 Labels in VMAC110 were alphabetized. JCLUXREF needed a
Jun 10, 1987 DCLOG DD, and /* in JCL was changed to //* comments.
VMAC110 Option ERRORABEND was added to JCLPDB. All MXG
JCLUXREF production jobs must specify OPTION ERRORABEND to
JCLPDB protect you from yourself. ERRORABEND causes any SAS
error condition (but not warnings) to immediately
terminate the execution with a USER 999 abend. The
actual error condition will be printed on the log.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
for alpha testing.
==========Changes thru 5.74 were published in Newsletter TEN===========
Change 05.74 Summarization and accumulation of VM/Monitor data a la
Jun 9, 1987 RMFINTRV into hourly (default) performance data with a
ANALVMOS small number of critical variables kept allows a years
DOCVMOS data in a small file for trending. Additionally, seek
EXECDALY histograms for VM disks is provided.
Member names have changed since Newsletter TEN.
Thanks to Steve Glick, Southern Methodist University, USA.
Change 05.73 Several minor cleanups detected in alpha testing of a
Jun 9, 1987 pre-release of Version 5:
VMAC128 a. VMAC128, two DOs removed and an END; removed.
TESTUSER b. TESTUSER, changed RMDSDATA to TYPERMDS (all).
TYPEDISO c. TYPEDISO needed quotes around SPLIT='*'.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.72 The VM/Monitor TOD time stamp is written in GMT time,
Jun 9, 1987 but the Start Collection time stamp is in local time.
VMACVMON Local time is offset from GMT by the SYSTIME parameter
ZONE in DMKSYS. Some sites (my test site included) set
ZONE=0 and the operators enter local time. This causes
the TOD time stamp to be local time. However, if your
site uses a nonzero value for ZONE, the STARTIME value
produced by MXG for each record was in GMT zone. This
change corrects this MXG oversite by using the Start
Collection (Class 0 Code 97) record to calculate the
time zone difference and set MXG times to local time.
The following lines inserted/changed will correct the
MXG time stamps. (SAS 5.16 under CMS will not accept
nulls in the DHMS function, while MVS SAS will. Line
2025 replaces the nulls with zeros for this reason.)
TIMEZONE=0; 276.1
STARTIME=16*MNHTOD+BASETIME-TIMEZONE; 279
RETAIN BASETIME INTERVAL STARTIME TIMEZONE ZDATE; 284
COLLTIME=DHMS(DATTODCL,0,0,TIMTODCL); 2025
DELTATOD=(16*MNHTOD+BASETIME)-COLLTIME; 2025.1
TIMEZONE=3600*FLOOR((ABS(DELTATOD)+99)/3600); 2025.2
IF TIMEZONE GT 0 AND DELTATOD LT 0 THEN TIMEZONE=-TIMEZONE; 2025.3
STARTIME=16*MNHTOD+BASETIME-TIMEZONE; 2025.4
The actual change in Version 5 is more extensive, and
warns you if a 0/97 record was not found. It also will
process VM/Monitor data from any time period, as long
as the monitor data includes a 0/97 (formerly, only
data within the last 203 days, the wrap time of the 5
byte TOD field, could be accurately processed). If the
first record is not a 0/97, MXG defaults the time zone
to zero and what you get could be either local or GMT.
Thanks to Terry Magill, NAS, USA.
Thanks to Steve Glick, Southern Methodist University, USA.
Change 05.71 Variables VECTUTM, VECTU0TM and VECTU1TM, VM/Monitor
Jun 9, 1987 reported Vector Facility Usage time (total, CPU, APU)
VMACVMON were added to VMONPERF data set. Note that only the
usage time is reported, and only globally; there is
no vector usage time reported by user in VM. The MXG
supplement discusses the vector Facility measurements.
Change 05.70 Variable INTERVAL was added to all of the VM/Monitor
Jun 9, 1987 data sets.
VMACVMON
Thanks to Steve Glick, Southern Methodist University, USA.
Change 05.69 In these sample reports, transactions with blanks for
Jun 9, 1987 OPERATOR were not counted in some reports, because by
ANALCICS default PROC SUMMARY treats a blank value of a CLASS
variable as a missing value. These transactions will
be counted if you add the MISSING operand to line 50:
PROC SUMMARY DATA=CICSTRAN MISSING;BY APPLID;
Thanks to Jim Enia, Allied Signal, USA.
Change 05.68 Added support for ACF2 user (default=196) SMF record.
Jul 21, 1987 Ten ACF2... data sets are created. The ... suffix of
EXACFAR data set name is the same as the parameter name in the
EXACFCR ACF2 Utilities Manual, page 74 (1/15/85 revision). No
EXACFDR reports are written or planned. Half of the data sets
EXACFER have been validated with actual data. Only Release 4.0
EXACFJR and later ACF2 releases will be supported.
EXACFNRA
EXACFNRB ACF2 is a product of UCCEL Corporation, maintained by
EXACFPR their Chicago Development and Support Center.
EXACFTR
EXACFVR
IMACACF2
TYPEACF2
VMACACF2
Thanks to Jill Raudabaugh, Whirlpool Corporation, USA.
Change 05.67 Changed references to SMF59TID to correct variable
Jun 4, 1987 TRANTYID to eliminate "uninitialized variable" note.
VMAC59
Thanks to John Mueller, ARMCO Steel, USA.
Change 05.66 Support for IMS 2.1 log record processing and a major
Jun 4, 1987 redesign of the logic for building IMSTRAN. Previously
EXIMSOUT the algorithm threw away transactions that were not
IMACIMS perfectly matched. Now, an observation will be placed
TYPEIMS in IMSTRAN if a '07' IMS log record is found, even if
VMACIMS not all of the other possible log records exist. This
provides complete accounting for the existence and the
resource accounting of the transaction, but may cause
missing value for response time and some time stamps.
Since IBM does not put a version number in the IMS log
you must change the _IMSVERS macro (which is defined
in member IMACIMS) from its default of 1.3 if you wish
to process IMS 2.1 log records. This re-design has
been moderately well validated by comparison with data
from the IMF product, but as with any new design (and
especially with the undocumented state of the IMS log)
you should be alert for any idiosyncrasies. This
change includes and superceedes Change 5.46. The code
in EXIMSOUT which formerly replaced IMSCPUTM with the
average cpu time per transaction has been eliminated.
Now, IMSCPUTM is the actual message region CPU time.
Thanks to John D. Pike, American Airlines, USA.
Change 05.65 Support for MVS 2.2 changes as announced in the MVS/XA
Jun 1, 1987 Conversion Notebook, Volume 2 (GC28-1411-0). Untested.
1. VMAC30. DIVRREAD, the 'ASID TOTAL*DIV REREAD*COUNT' is
added to the TYPE30_V, TYPE30_4, TYPE30_5 and TYPE30_6
data sets to report the new DIV (Data in Virtual) use
at the interval, step, and job level of detail.
2. VMAC7072. Three new variables added to TYPE72 data set
ACTFRMTM='ACTIVE*FRAME*TIME'
PERFACCT='PERFGRP*SET FROM*ACCOUNT?'
PGPAGEIN='PAGE INS*BY THIS*PERF GROUP PERIOD'
Note that ACTFRMTM and PGPAGEIN report memory and page
in counts by each period of each performance group!
3. VMAC90 and FORMATS. New subtype 17 (SET PFK) added to
the TYPE90 data set.
Change 05.64 Variable UCBTYPE was increased from 4 bytes to 5 bytes
Jun 1, 1987 to eliminate truncation of the last byte. Even though
VMAC21 the field is only 4 bytes, because it is stored as a
VMAC64 numeric in SAS, 5 bytes are required for resolution of
VMAC74 all four hex bytes. The change to a 4-byte character
VMAC75 variable was considered, but would be catastrophic on
any report program now using UCBTYPE. If you combine
your daily, weekly and monthly PDBs as recommended in
Chapter Thirty-Five using SET statements, there will
be no impact. However, if you use PROC APPEND on the
TYPE21 or PDB.TAPES, TYPE64, TYPE74, or TYPE75 data
sets, you will encounter an error message due to the
change in length. You could specify FORCE on the PROC
APPEND statement to force the joining of the old and
new, but that will keep the old length of 4 bytes. To
use PROC APPEND without error, you must re-create the
BASE= data set(s) with length 5:
DATA BASE.xxxx; LENGTH UCBTYPE 5; SET BASE.xxxx;
and then the PROC APPEND will succeed. (These are
some of the reasons MXG does not recommend the use of
PROC APPEND.)
Note: UCBTYPE is not a commonly needed variable, and
since it has never been right, probably is not used in
your report programs. DEVICE is decoded from UCBTYPE
and should be used instead.
Thanks to Bill Mullen, BGS, USA.
Change 05.63 TYPE30 variables JINTTIME,INTETIME,JTRMTIME,JINITIME,
Jun 1, 1987 SELAPSTM,JELAPSTM, and INTRVLTM are now created before
VMAC30 any MXG exits are taken. Formerly, they were created
just before the output exit of their respective data
set.
Thanks to Bill Mullen, BGS, USA.
Change 05.62 RACF Type 80 record with a zero length data segment
Jun 1, 1987 caused STOPOVER abend. Insert new lines 70.1, 70.2 and
VMAC80 72.1 after lines 70 and 72 in VMAC80:
@; 70.1
IF 0 LT RACFDLN LE 200 THEN INPUT 70.2
INPUT RACFDATA $CHAR200. @; 72.1
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.61 Untested assembly code for the tape mount monitor. Do
May 21, 1987 not use, as it has not been tested.
ASMONTAP
Change 05.60 JCL errors were not kept in PDB.JOBS from JES2. Code
May 20, 1987 to delete the multiple JES2 purge records in an NJE
BUILDPDB environment also deleted the JCL error's purge record.
1.Add variable INREASON to the _PDB26 keep list in
line 37.
2.Replace line 222:
IF SYSEXEC GT ' ';
with these two lines:
IF INREASON='SR' OR
(INREASON='JR' AND SYSEXEC LT ' ' THEN DELETE;
Thanks to M. N. Woolley, Dept of Finance, AUSTRALIA
Thanks to Cathy Ellis, Dept of Finance, AUSTRALIA
Change 05.59 TYPE64 only contains data on the first 3 extents of
May 20, 1987 a VSAM entry. This change creates an additional data
EXTY64X set TYPE64X which contains the information on all of
VMAC64 the extents. (TYPE64 is unchanged and still will have
the data on the first three extents).
Thanks to Willie Antman, Federal Deposit Insurance Corp., USA.
Change 05.58 This change makes full use of the relocatable record
May 20, 1987 length information to protect MXG from any IBM changes
VMAC7072 to the performance group data. Insert two new lines
after line 1169:
SKIP=LENPGPS-56;
IF SKIP GT 0 THEN INPUT +SKIP @;
This change replaced by change 5.65, June 1, 1987.
Change 05.57 Support for NETVIEW changes to the type 39 record.
May 20, 1987 Without this change, some variables will be missing.
VMAC39 1.Change line 206 from:
IF VERSNLDM GE 000DX THEN INPUT
to read:
IF VERSNLDM GE 000DX OR PRODUCT='NETV' THEN INPUT
2.Change line 241 from:
IF VERSNLDM GE 000DX THEN INPUT
to read:
IF LENSCS GE 118 THEN INPUT
Thanks to John Fleig, Rochester Gas and Electric, USA.
Change 05.56 Devices offline at the end of the interval and any
May 20, 1987 device with CMBINVLD='Y' (indicating invalid data
VMAC74 from the hardware monitor in the channels) had none
of their utilizations calculated, but had some data
carried forward from the previous device. Delete
line 356 and line 379 so that utilizations will
always be calculated for all devices.
Thanks to MP Welch, Sisters of Charity of the Incarnate Word, USA.
Change 05.55 IBM's Report Management & Distribution System,
May 19, 1987 RMDS FDP creates a (default) type 217 SMF record,
EXTYRMDS which is supported by these new members. Data set
IMACRMDS TYPERMDS is created.
TYPERMDS
VMACRMDS
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.54 RACF records with identical SMFTIME values could
May 18, 1987 not be ordered as they occurred. A new variable,
VMAC80 RECIDNO was added to the KEEP= list and created
ANALAUDT with one new line inserted after line 45 in VMAC80:
RECIDNO = _N_ ; 45.1
ANALAUDT was also modified to use RECIDNO in creating
the Auditor reports.
Thanks to David D. Anderson, U.S. Bancorp, USA.
Thanks to Jim Bentley, U.S. Bancorp, USA.
Change 05.53 1.IDMS Performance Monitor (formerly RTE) records
May 18, 1987 now decode the RT1 variable data area (ERUS Batch,
VMACRTE ERUS CICS, and DC information). Ten new variables
are created: RT1DCTC RT1CDLT RT1DCUI RT1DCPN
RT1EBJN RT1EBNAF RT1EBALN RT1EBAFN RT1EBPN and
RT1MSSEV, due to Rod. This member will be
renumbered in MXG Version 5.
2.IDMS-PM records were changed incompatibly in
IDMS Version 10.1, and many new data segments now
exist in the RTE record, based on test data sent
by Dennis. The following changes are required to
process IDMS Version 10.1 RTE records:
a. Insert one new line after line 141:
IF RT1HDRVN EQ 1 THEN DO; 141.1
b. Insert five new lines after line 216:
@; 216.1
IF RT1HDRTL EQ 252 THEN INPUT 216.2
RT1MSRS2 $CHAR4. 216.3
@; 216.4
ELSE INPUT 216.5
c. Insert five new lines after line 220:
END; 220.1
ELSE DO: 220.2
SKIP=RT1HDRTL-16; 220.3
INPUT +SKIP @; 220.4
END; 220.5
Once Cullinet provides the formats of the PMIM
record types, they will be supported by MXG.
See Change 5.95.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Thanks to Dennis Pugh, Browning Ferris Industries, USA.
Change 05.52 Several minor errors in the VM/Account data sets are
May 15, 1987 corrected by this contribution.
TYPEVM a. Variable TERMADDR should be read in with $CHAR4. in
lines 237 247 and 256 (instead of PIB4.).
b. Variable MINIADDR should be $CHAR4. instead of PIB4.
in line 249.
c. Variable MINIADDR should be $CHAR3. instead of PIB4.
in line 259.
d. Add new line after line 224 (1077052512 is the value
when four blanks are read with a PIB4. format).
IF BLOCKS=1077952512 THEN BLOCKS=.; 224.1
Thanks to Jan Van Lent, Fokker BV, NETHERLANDS.
Change 05.51 A fine set of DB2 reports, similar to those produced
May 14, 1987 by the DB2PM product, were provided by Tony. This
ANALDB2R member generates the reports, with selection by DB2
system as well as reporting time selection as shown
in the comments at the beginning of the member.
Thanks to Tony Shaftel, Farmers Insurance, USA.
Change 05.50 TYPE6 data set variable CONTRIND could not decode the
May 14, 1987 multiple bit conditions which sometimes occur. This
VMAC6 variable has been replaced by nine one-byte variables,
CONTRIN0 through CONTRIN9, containing a "Y" if the
condition described by the variable's label did occur.
This also takes less storage (9 bytes versus 22). Most
sites do not actually used these flags which identify
certain operator actions to the print file.
Thanks to P. J. Lines, Centre-File Limited, ENGLAND.
Change 05.49 IBM documentation error caused variable DVQUQCNT in
May 14, 1987 VMON602 data set to be incorrect. The variable is
VMACVMON only one byte for all releases of VM. Delete lines
2487 thru 2490.
Thanks to Steve Glick, Southern Methodist University, USA.
Change 05.48 TYPE78PA (Private Area virtual storage of monitored
May 14, 1987 jobs) variables suffixed with 9 were not calculated
VMAC78 as averages. Replicate lines 1638 through 1645 and
then change both occurrences of 4 in each line to 9.
Thanks to Rodney L. Reisch, General Electric Silicon Division, USA.
Change 05.47 VM Account record type 07 (VCNA) caused a STOPOVER SAS
May 14, 1987 error condition. Line 157
TYPEVM INPUT
should be change to
INPUT @9 ACCOUNT $CHAR8.
Thanks to Jim Gilbert, Texas Utilities, USA.
Change 05.46 IMS transactions were not properly assembled when the
May 14, 1987 record counter for the log is reset. It used to be
IMACIMS reset with each new log tape, but it is not clear now
TYPEIMS exactly when the reset occurs. The variable IMSTAPNO
VMACIMS (which was in the original European code but removed
by mistake) has been restored to resolve the reset.
There are many lines changed.
June 3, 1987. Change 5.66 superceeds this change.
Thanks to Lee Adams, United Telephone System, USA.
Change 05.45 Reading type 78 records from the VSAM SMF file causes
Apr 25, 1987 a STOPOVER abend. (There is no problem with reading
VMAC78 the normal dumped BSAM SMF file.). To read the type 78
VSAM format data, add +OFFSMF to lines 1668, 1695, and
1731. (OFFSMF is set by the _SMF macro in VMACSMF and
is 4 if a VSAM file is being read, 0 otherwise.)
Thanks to Wing Louie, Metropolitan Life Insurance, USA.
Change 05.44 DB2 Release 1 fields QXQUERY and QXALTBF were changed
Apr 25, 1987 in Release 2 and are now QXSELECT and QXFETCH in MXG.
VMACDB2 (QXALTBF was reserved, and QXQUERY was split into the
two query types SELECT and FETCH.) Change all five
occurrences of QXQUERY to QXSELECT and change the
label to read "SELECT*STATEMENTS". Change all five
occurrences of QXALTBF to QXFETCH and change the
label to read "FETCH*STATEMENTS".
Thanks to A. Williams, Shell U.K, ENGLAND.
Thanks to Richard Whitnable, State of Wisconsin, USA.
Thanks to Martha Hall, Metropolitan, USA.
Change 05.43 QTXA... variables in DB2ACCT are missing because the
Apr 25, 1987 length of the lock segment was changed, causing MXG to
VMACDB2 not read them in. Line 1238 should be changed from
ELSE IF LENLOCK GE 28 THEN
to read
ELSE IF LENLOCK GE 24 THEN
Thanks to Tom Frankle, Chemical Bank, USA.
Change 05.42 More than 200 bytes of user data (counter, clocks, or
Apr 21, 1987 characters) added to the CICSTRAN data caused the MXG
VMAC110 error message "data format has changed". MXG will now
input the first 200 bytes and skip over any excess.
The member IMACICUS can be used to actually decode
any local counters. (The optional DL/I counters are
decoded in IMACICDL.)
Thanks to Shawn Weikel, CITIBANK, USA.
Change 05.41 Reserved Change Number.
Mar 19, 1987
Thanks to Jon Sahl, New York Life, USA.
Change 05.40 Durations and counts for CICSEXCE exceptions were not
Mar 16, 1987 being calculated for CICS 1.7 exceptions. MSWAITTM,
VMAC110 TSWAITTM, and VSWAITTM are set to ENDTIME-STRTTIME.
The existence of the exception is still the important
event. (VSAM waits are usually due to insufficient
LSR buffers).
Thanks to Tom Wiebe, NERCO, USA.
Change 05.39 Preliminary re-write of SYNCSORT support, will become
Mar 11, 1987 VMACSYNC when tested.
XMACSYNC
Thanks to Jill Raudabaugh, Whirlpool Corporation, USA.
Change 05.38 Record subtype, SUBTYPE, is now created in _SMF macro
Mar 11, 1987 and is available to exit IMACFILE, for those records
VMACSMF which contain a subtype. END=ENDOFSMF and an include
for IMACFILE were added to _JOURNAL macro (for type
110 records in CICS journal format) so that it is now
consistent with the _SMF macro.
Thanks to Mark Nelson, UCCEL, USA.
Change 05.37 Revised installation instructions for the IDMSSTAT
Feb 2, 1987 program (which writes SMF records from IDMS) were
IDMSEXIT added. No change to the ASM source code was made.
Thanks to Ron Szczepanski, Whirlpool Corporation, USA.
Thanks to Keith Stout, Municipality of Anchorage, USA.
Change 05.36 A set of ten reports for the EDP Auditor, from RACF
Feb 2, 1987 TYPE80 data, was provided by its author, and with
ANALAUDT minor revisions was added as member ANALAUDT.
Thanks to David D. Anderson, U.S. Bancorp, USA.
Change 05.35 Variable VTAMCPUI, the CPUID*FROM*SYSTEM, at the end
Jan 29, 1987 of this VTAM SMF Accounting Record is now created by
VMAC128 MXG.
Change 05.34 To protect users from accidentally truncating the WORK
Jan 28, 1987 variable (which defines worktype and is expected by
IMACWORK RMFINTRV to be $CHAR5.), INFORMAT WORK $CHAR5. was
added. This is a minor change.
Thanks to Brian Cooper, Franklin Mint, USA.
Change 05.33 Announcement of the 3090-600 suggests there really is
Jan 27, 1987 going to be a 3090-800. TYPE70 data set was modified
VMAC7072 to support nine engines (numbered 0 thru 8 inclusive).
The eight CPU-specific variables (CAIn, CPUSERn, VFONn
CPUWAITn, IORATEn, PCTCPBYn, PCTTPIn, VFAFFTMn) now
exist for n=0 thru 8. This change supercedes change
5.1. These variables are not typically important; most
sites won't need to know these CPU-specific values.
The overall system measures related to these values
(CPUWAITM, IORATE, PCTCPUBY, PCTTPI) are correct with
or without changes 5.32 and/or 5.1.
Change 05.32 Support for the Online Business System WYLBUR Session
Jan 26, 1987 SMF record was added. One record per WYLBUR session
TYPEWYLB is written containing CPU, I/O and counts of some
VMACWYLB activities.
IMACWYLB
EXTYWYLB
Change 05.31 Support for the Cache RMF Reporter (IBM Program Number
Jan 25, 1987 5798-DQD) SMF records (default 244, 245) which invokes
TYPECACH AMS LISTDATA to extract counters for Cache DASD 3380
VMACACHE control units (models 11,21,13,and 23) was added. This
IMACACHE code was originally written in Germany and contributed
EXCAPAG to MXG. The code was revised and consolidated into the
EXCACHE members indicated, and has been tested with type 245
SMF records.
Thanks to ???, DZ/SP-CM Gotaher Verischerung VVAG, GERMANY.
for the original code,
Thanks to Kirby Kern, Commercial Federal S & L Omaha, USA.
for test data.
Change 05.30 Format MG078CV., which is used in many MXG data sets
Jan 24, 1987 to convert bytes to nnnK or nnnM printout was refined
FORMATS so that 16777216 bytes prints as 16MB (before this
change, the value had to be 16777222 before the format
changed from 15M to 16M). Correct this minor error by
changing .0009766 to .0009765625 in line 163, and by
changing .000000953674 to .00000095367432 in line 164.
Change 05.29 Support for TSO/MON Version 5.0 coded. Accounting
Jan 23, 1987 variables added to TSOMCALL and TSOMSYST. A new data
VMACTSOM set, TSOMDSNS captures data set names and members
which were accessed by commands captured in TSOMCALL,
if new TSO/MON option to do so was enabled. MXG 4.4
supports TSO/MON Version 5.0 without error, but if you
want the data new in TSO/MON Version 5.0 before we
ship MXG Version 5, call us. Too many lines changed
to provide here.
Change 05.28 The equation for PCTCUBSY (percent control unit busy
Jan 14, 1987 in TYPE78CF for 3090s) is incorrect in the RMF manual
VMAC78 on page 374. The minus is actually a plus.
The value of AVGCUHQL (CU-HDR queue in TYPE78CU) was
incorrectly calculated. The equation was corrected.
Source statement Line number
PCTCUBSY=100*PCTCUBSY/CHPIDTKN+PCTCUBSY); 1724
IF NRCUHREQ GT 0 THEN AVGCUHQL=(NRCUHENQ-NRCUHREQ)/NRCUHREQ; 1748
ELSE DO; 1749
NRCUHENQ=.; 1749.1
AVGCUHQL=.; 1749.2
END; 1749.3
Change 05.27 After each statement in which INVALID,VARIED,ONLINE,
Jan 14, 1987 LCI, and IDWRONG is set equal to 'Y', add a statement
VMAC73 ELSE XXXXXXXX=' '; where XXXXXXXX is the name of
the variable being set to 'Y'. Without these new ELSE
statements, once any of these variables were set to a
value 'Y', the value remained 'Y' for the rest of the
observations created from that type 73 record.
Thanks to Paul Larson, Marine Bank Services, USA.
Change 05.26 New variables SWAP EXTAUX LOGAUX LOGEXT PHYAUX and
Jan 14, 1987 PHYEXT are created, each containing the total swap
VMAC71 rate for tha swap transition. This total is created by
summing all eleven swap reason codes for a particular
swap transition. Insert after line 742, these lines: ,
SWAP =SUM(SWAPAS, SWAPDW, SWAPEX, SWAPNQ, SWAPNS, SWAPRS,
SWAPTI, SWAPTO, SWAPUS, SWAPVR, SWAPWT);
EXTAUX=SUM(EXTAUXAS,EXTAUXDW,EXTAUXEX,EXTAUXNQ,EXTAUXNS,EXTAUXRS,
EXTAUXTI,EXTAUXTO,EXTAUXUS,EXTAUXVR,EXTAUXWT);
LOGAUX=SUM(LOGAUXAS,LOGAUXDW,LOGAUXEX,LOGAUXNQ,LOGAUXNS,LOGAUXRS,
LOGAUXTI,LOGAUXTO,LOGAUXUS,LOGAUXVR,LOGAUXWT);
LOGEXT=SUM(LOGEXTAS,LOGEXTDW,LOGEXTEX,LOGEXTNQ,LOGEXTNS,LOGEXTRS,
LOGEXTTI,LOGEXTTO,LOGEXTUS,LOGEXTVR,LOGEXTWT);
PHYAUX=SUM(PHYAUXAS,PHYAUXDW,PHYAUXEX,PHYAUXNQ,PHYAUXNS,PHYAUXRS,
PHYAUXTI,PHYAUXTO,PHYAUXUS,PHYAUXVR,PHYAUXWT);
PHYEXT=SUM(PHYEXTAS,PHYEXTDW,PHYEXTEX,PHYEXTNQ,PHYEXTNS,PHYEXTRS,
PHYEXTTI,PHYEXTTO,PHYEXTUS,PHYEXTVR,PHYEXTWT);
MXG Version 5 goes further and sets all seventy two of
swap rate variables to missing if there are no swap
transitions for that swap reason code. This will cause
PROC PRINTs and MEANS to highlight only the transition
and reason codes which actually occurred.
Change 05.25 Variables VECTORON and VECONSAM were replaced with
Jan 14, 1987 VFON0 thru VFON3 and VFAFFTM0 thru VFAFFTM3 to track
VMAC7072 Vector Facility Online and Affinity by processor.
Change 05.24 Variable ABNDRSNC (abend reason code) was added to
Jan 7, 1987 TYPE30_4 and TYPE30_5 KEEPs, and new lines inserted
VMAC30 after lines 147, 326, and 487:
Source statement Line number
ABNDRSNC='ABEND*REASON*CODE' 145.1
ABNDRSNC $HEX8. 323.1
IF LENCOMP GE 8 THEN INPUT ABNDRSNC $CHAR8. @; 483.1
Change 05.23 Class 1 record with LENDATA=0 causes STOPOVER ABEND
Jan 7, 1987 because $VARYING is not smart enough to handle zero.
VMACVMON Lines 2087-2088 should be changed to:
Source statement Line number
INPUT @19 LENDATA PIB1. @; /*MN10YCNT*/ 2087
IF LENDATA GE 1 THEN 2087.1
INPUT @20 DATALINE $VARYING128. LENDATA /*MN10YI0*/ 2088
Thanks to Bill Cohen, Drexel Burnham, USA.
Change 05.22 OBJVALUE was ten times too large. Line 288 should be
Jan 7, 1987 OBJVALUE PIB4.1 instead of PIB4.
VMAC39
Change 05.21 The 3480 data fields were never read in, due to wrong
Jan 4, 1987 test value in line 68. New variables DEVICE and OPEN
Jan 26, 1987 are added. TAPUNSER was incorrectly decoded as numeric
ANALESV but is actually a character string in hex format. To
VMAC21 avoid conflict, new character variable TAPCUSER now
replaces TAPUNSER. For 3480s TAPCUSER contains the
last four digits of control unit serial number and the
single hex digit of the actual drive within that CU on
which the tape volume being dismounted was created.
For 3420s it contains the creation tape drive serial.
UCBTYPEs length is increased to 5 to avoid truncation.
Member ANALESV was also modified to print 3480 values;
those report changes are not given here.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
The following change to VMAC21 is only needed if you are interested
in analyzing 3480 tape errors. It will be automatically installed in
MXG Version 5, as are the changes to ANALESV.
The change alters four existing lines and inserts twelve new lines.
The line numbers of the changes/inserts are shown below. Inserts have
a period after the line number they are to be inserted after. Changed
lines have no period.
Source statement Line number
DCBOFLG DENSITY DEVICE DEVNR 0007
OPEN 0010.1
TAPCUSER TEMP.... (rest unchanged) 0013
DEVICE ='DEVICE*TYPE ' 0027.1
OPEN ='TYPE*OF*OPEN ' 0032.1
LENGTH DEFAULT=4 UCBTYPE 5 SMFTIME 8; 0048
TAPCUSER $HEX6. 0051.1
@27+OFFSMF DEVCLASS PIB1. 0055.1
@28+OFFSMF DEVTYPE PIB1. 0055.2
%%INCLUDE SOURCLIB(VMACUCB); 0067.1
IF LENGTH GE 58 THEN DO; 0068
@44+OFFSMF TAPCUSER $CHAR3. 0070
IF DCBOFLG='0.......'B THEN OPEN='INPUT '; 0076.1
ELSE IF DCBOFLG='1.......'B THEN OPEN='OUTPUT '; 0076.2
BYTEREAD=4096*BYTEREAD; 0076.3
BYTEWRIT=4096*BYTEWRIT; 0076.4
END; 0076.5
Original lines 86-87 MOVEed to new lines 76.3 and 76.4
Change 05.20 The "Total Recorded CICS CPU Time", created only in
Dec 23, 1986 MXG reports in ANALCICS, is incorrect. As described in
Jan 26, 1987 the MXG supplement, the total CPU time recorded in the
ANALCICS CICSYSTM data set should have been(line 88):
CPUTOTTM = SUM(CPUSRBTM,CPUTCBTM);
NOTE: This only affects ANALCICS reports, not the MXG
CICSYSTM data set. See Chapter 21 in MXG Supplement.
Thanks to Beth Asbury, Prudential Home Mortgage, USA.
Change 05.19 PVTBOT, PVTTOP, and REGREQST were converted to bytes
Dec 23, 1986 (their value was multiplied by 1024), and they are now
VMAC30 converted by MXG format MG078CV., which prints bytes
as K or M, depending on magnitude. This was done to
See also make PVTBOT, PVTTOP and REQREQST consistent with the
Change 6.13 other virtual storage measures in TYPE30 data sets,
LSQSZHI/LOW, PVTSZHI/LOW and USRSZHI/LOW.
Thanks to Norbert Riehout, Great Western, USA.
Change 05.18 DL/I Counter decoding was added for CICS 1.7. The same
Dec 23, 1986 four clocks and nine counters are decoded, but their
IMACICDL order in 1.7 is reversed from 1.6: the four clocks are
first, followed by the nine DLI counters, Also, the
four PIB2. count variables for the four clocks must be
changed to PIB4. Finally, the test for length of data
must be changed from 60 to 68. Copy the 1.6 decode to
the 1.7 logic area in IMACICDL and make these changes.
Thanks to Thomas Victor, Kaiser Data Center, USA.
Change 05.17 These new members provided by Gothaer Vershicherung in
Dec 15, 1986 1.TYPECACH member supports the 3880 Cache DASD RMF
TYPECACH Reporter FDP SMF records in two datasets for the model
VMACACHE 11/21 and 13/23 cache.
VMAC60 2.Member VMAC60 has been updated to decode the VSAM VVR
VMAC60 fields, although none of these variables are labeled
SYSLOGJ3 and some will need MXG formats.
UTILSPAC 3.SYSLOGJ3 processes the JES3 SYSLOG. Worth reading.
4.UTILSPAC collects DASD size (space) info from CVAF
VTOC's.
Change 05.16 Decode of MONIFLG2 is incorrect. Replace lines 428-430
Nov 24, 1986 with:
TYPEMONI '...1....' THEN MONIATI='Y';/*ATI*TASK*/
'....1...' THEN MONSWAIT='Y';/*VSAM*STRING*WAIT*/
'.....1..' THEN MONBWAIT='Y';/*VSAM SHARED*BUFFER*WAIT*/
Change MONDMONI to MONIATI in line 45, and replace 121
(MONDMONI label) with MONIATI='ATI*TASK'
Change 05.15 Replace lines 101-105 (HS,MS,SS,TS input) with:
Nov 24, 1986 STARTIME PIB4.2
TYPEDISO and remove line 126 (STARTIME=HMS...)
Change 05.14 Additional test to prevent STOPOVER abend with 1.6.1.
Nov 24, 1986 Add to present criteria for VMAC110.1 error message:
VMAC110 OR (CONNBYTE+TEMPBYTE GT TEMPLEN AND MCTSSDID NE 0)
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.13 Concatenated multiple VM Monitor files caused negative
Nov 24, 1986 CPU values at beginning of each group of monitor data.
VMACVMON To reset INTRVCNT when new BEGIN monitor (CL 0 CD 97)
record is encountered, insert new line:
ELSE INTRVCNT=0; 281.1
after line 281.(Change was revised Feb 16, 1987.)
Thanks to Tim O'Rourke, Bankers Trust NYC, USA.
Change 05.12 IRC Wait time in CICS 1.7 is located after SUSPNDCN.
VMAC110 a. Change line 678: WTIRIOCN PIB2. to WTIRIOCN PIB4.
Dec 15, 1986 b. Move lines 676 thru 679 (IF _PP43887 THEN thru @;)
immediately after line 688.
c. The actual CICS 1.7 APARS which add WTIRIOTM/CN are
APARs PP51612 and PP56560. To enable MXG for these
PTFs, however, you must enable the macro named
_PP43887 (the CICS 1.6 number) in IMACPTF.
d. UTILCICS will not detect the existence of the IRC
data fields. However, if IRIOWTT appears under the
column heading of CMODNAME on the dictionary print
from UTILCICS, then that CICS 1.7 APPLID must have
_PP43887 enabled in IMACPTF. UTILCICS will be
modified to check CICSDI17 to report this PTF.
Thanks to John Loo, Fluor, USA.
Thanks to Joe Faska, Chemical Bank, USA.
Change 05.11 MXG did not correctly initialize all variables. Under
Oct 31, 1986 some circumstances, character flags (eg, VARY, ONLINE)
VMAC73 could be erroneously carried to subsequent devices.
VMAC74
VMAC78
Thanks to Paul Larson, Marine Bank Services, USA.
Change 05.10 A bad CICS 1.6 data block could cause strange errors.
Oct 31, 1986 Further testing added to delete bad CICS blocks.
UTILCICS
Thanks to Kirby Hindin, Allnet Communication Services, USA.
Change 05.9 Would not read VSAM SMF records correct. +OFFSET was
Oct 31, 1986 missing in lines 303,314, and 334.
VMAC1415
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.8 Full duplex line utilization could exceed 100%, due to
Oct 22, 1986 CHRSPEED being the MAX of SEND or RECEIVE line speed.
VMAC38 HDX line has only SEND or RECEIVE non-zero.
To fix, change the CHRSPEED=MAX() to CHRSPEED=SUM().
Change LSPEED=MAX() to LSPEED=SUM().
Thanks to Marcia Geyer, City of New York FISA, USA.
Change 05.7 Syntax error due to line dropped after line 3200.
Oct 22, 1986 SET TYPE0; added following DATA statement.
ANALVARY
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.6 PDB.JOBS observation built from job which had no job
Oct 22, 1986 termination record (happens if SPINCNT=0) caused minor
ANALMPL anomaly in program. Now, INBITS tested for job term.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.5 If ANALDSET was used with the PDB.STEPS data (rather
Oct 22, 1986 than using the SMF file and TYPE30_4 as step input),
ANALDSET a syntax error occurred due to a misplaced semicolon.
Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 05.4 Variables TAPE3420 and TAPE3480 are now created and
Oct 22, 1986 count the number of 3420 and 3480 tape devices which
VMAC30 were allocated by each step. TAPEDRVS is still the
VMAC434 total number of tape drives allocated and is the sum
VMACEXC2 of TAPE3420 plus TAPE3480. ANALTAPE modified to report
ANALTAPE on total drives as well as 3420 and 3480 drives.Also,
a better estimate of drives waiting alocation is made.
a. Add TAPE3420 and TAPE3480 to _VAR30 macro KEEP= for
TYPE30_4, TYPE30_5, and TYPE30_V data sets.
b. In VMACEXC2, replace line 166:
IF TEMPNEW THEN TAPEDRVS=SUM(TAPEDRVS,1);
with these five lines:
IF TEMPNEW THEN DO;
TAPEDRVS=SUM(TAPEDRVS,1);
IF DEVTYPE = 80X THEN TAPE3480=SUM(TAPE3480,1);
ELSE TAPE3420=SUM(TAPE3420,1);
END;
Thanks to Martha Hall, Metropolitan Life, USA.
Thanks to Ken Dice, Community Mutual Insurance, USA.
for ANALTAPE ideas.
Change 05.3 Variable RSPTMEDF, the RTM "Response Time Definition"
Oct 21, 1986 was undocumented and originally read in a PIB1. field.
VMAC39 It turns out that it is a Character byte, containing
FORMATS F - First Character Received, K - Unlock Keyboard, or
C - Change of Direction and thus describes which of
these definitions is being used in this 3274 RTM.
RSPTMEDF was change to $CHAR1. with new MXG format
$MG039DF supplied to decode the one-byte characters.
Thanks to Jim Yoney, Allegheny Power, USA.
Change 05.2 TSO/MON Command counts were incorrect in MXG, because
Oct 21, 1986 MXG counted all entries in the FCB "Full Command"
VMACTSOM segments as commands. Actually, the FCBs contain Full
Commands, Dialog Manager Programs, Dialog Manager
Panels (and in TSO/MON Version 5, CLIST executions
will also be counted in FCB segments). Only Full
Commands and Dialog Manager Programs should be counted
as commands, and TSO/MON has already stuffed the count
of these two in a CCB bucket with comand type of null
(i.e., hex 00). Remove line 3910:
NRTRANS=NRTRANS+NRTIMES inside DO _I_=1 to NRFCBS
to correctly count commands as TSO/MON does.
Thanks to Chris Moyle, SCP- working for MOBIL, AUSTRALIA.
Change 05.1 IBM re-numbered CPUID in the 3090-400. Instead of 0-3
Oct 21, 1986 they are 1-4. With this change, the CPU 4 individual
VMAC7072 measures will be stored in CPU0 variable names on the
3090-400.
CHANGE both occurrences of
IF CPUID=0 THEN
to read
IF CPUID=0 OR CPUID=4 THEN
This change was enhanced with Change 5.33.
Thanks to Lucy Fukishima, State of California Health & Welfare, USA.
LASTCHANGE: Version 5
=========================member=CHANGE04================================
/* COPYRIGHT (C) 1986 BY MERRILL CONSULTANTS DALLAS TEXAS */
MXG Software Status as of September 26, 1986.
This is the production release of MXG VERSION 4.4
Major enhancements in Version 4 are listed below. Read this
entire member to determine its impact. New changes have been
added, and some Change descriptions have been reworded since part
of these new changes were printed in MXG NEWSLETTER EIGHT in May.
Major items in Version 4:
1.New member INSTALL contains installation instructions for MXG
under either MVS or CMS versions of SAS. The MXG Exit Facility
is also documented therein. This member MUST be read to ensure
MXG installs without error.
2.VM Monitor processing to create VMONaaaa data sets directly with
SAS with VM MAP variable names. See change 4.85, below.
3.Support for RMF 3.4 and MVS 2.1.7 and Vector Processor data
introduced with 3090 processors. SMF manual TNL's thru GN28-1061
are included in MXG Version 4. New TYPE78CU and TYPE78IO data
sets and new data in TYPE78CF result from 3090 I/O architecture
4.IMSLOG CODE enhancement (TYPEIMS) puts log trace records together
for IMS transaction response and resource measurement.
5.CICS 1.6.1 and CICS 1.7 are now supported in VMAC110 code. New
program UTILCICS may have to be run to determine which of the
impacting PTFs are installed so that you can update IMACPTF.
6.Support for Landmark's The Monitor for CICS records, including a
INFILE exit to process compressed format data. See Change 4.94.
7.Support for Cullinet's IDMS Performance Monitor records.
8 ASM source for an exit to IDMS which will write SMF records that
contain IDMS log data, and SAS code to process those MXG-created
IDMS-LOG-SMF records. SAS code to process the IDMS DCLOG directly.
9.Support for DOS POWER Version 2 account records. Impacting change
in V2 to DOSJOBS data, and five new DOS data sets now exits.
10.Support for DISOSS Version 3 Release 3 account records.
10.New member IMACPTF. Presently used only for CICS 1.6 records, this
new maintenance feature allows MXG code to be enabled to support
those (dumb) PTFs which ambiguously change data format.
11.DB2 processing revised to capture all data segments in Release 2.
12.Revised ANALTAPE routine now with accurate counts.
13.MODEL204 accounting information now defaults ON (EXM24ACT).
14.NODUP option implemented in BUILDPDB/3 to remove duplicate SMF
input data from PDB data sets. (Full implementation for all data
sets requires SAS Version 5.15. See Change 4.38-39).
15.Too much more to list here. Read all of these changes! MXG now
creates 168 MXG SAS Data Sets (Version 1 had 78) with its 466
source library members (Version 1 had 189) processing data from
24 products for MVS, VM and DOS data centers.
/* COPYRIGHT (C) 1986 BY MERRILL CONSULTANTS DALLAS TEXAS */
What was not quite finished when development was frozen for 4.4?
1. CMS still has some known data errors in some fields. As far as
we know, all discrepancies are documented in the comments at
the beginning of VMACVMON. There is very little CMS reporting,
and essentially no guidance as to which variables in which data
sets are important. We have only validated the PERFORM, USER,
and DASTAP classes, though others are coded, they may not work
(yet). A very small number of users have tested non-HPO systems
and UP systems - our primary validation was 03.34.0314 HPO 3.4
on an MP. None of the planned EXECs for testing were completed
yet. Because of the newness of MXG support for VM Monitor data,
users should validate the data carefully, and share with us any
discrepancies. We will send MXG NEWSLETTERS if necessary to
communicate major CMS enhancements/discoveries over the next few
months. Because the vast majority of the data is valid, we felt
you would prefer to have this now rather than later. Please help
us with your comments and expertise.
2. Documentation! MXG Version 4 will be eventually enhanced by the
printed MXG SUPPLEMENT (a 3-ring document bound like manuals
for IBM-PCs). The SUPPLEMENT will be indexed to the same chapters
as the MXG BOOK, and will provide new sections of Chapter FORTY
for new and updated MXG data sets, as well as updates to other
chapters from all past MXG newsletters. A significant poriton of
the MXG SUPPLEMENT will deal specifically with the analysis of
VM Monitor data.
Merrill Consultants will automatically send one copy of the MXG
SUPPLEMENT to all supported customers when it is completed, and
future MXG Newsletters will be sized to fit therein.
When completed, additional copies of the MXG SUPPLEMENT will be
available for purchase (at a mere pittance) from the Publications
Department of SAS Institute. Please don't hassle SAS about the
publication date - they are not the hold up. Call us in Dallas
if you must, but don't expect it before year end. (Which year?)
COMPATIBILITY EXPOSURES BETWEEN MXG VERSIONS 3 and 4:
1. EXTY72 and EXTY74 exit members were changed. If they exist in your
USERID.SOURCLIB, your changes will override MXG changes. Thus only if
you have these members in your USERID. library, must you re-fit your
exit code. (The change externalized control of observations which had
previously buried inline in the MXG VMAC7072 member).
2. TYPE72 data set may contain more observations with Version 4.
Previous versions only output if performance group received SERVICE,
but RPGNs can be defined to only count transactions; MXG missed those.
Version 4 now outputs TYPE72 observations if either SERVICE or TRANS
are non-zero. This logic is now in EXTY72, if you wish to override.
3. Version 3 and RMF 3.3 cause the first TYPE70 observation from each
day's processing to have a missing value for the variable SU_SEC. This
is because that value is now in the type 72 record (at long last) for
RMF 3.3+, but the type 70 record (from which we used to have to get
the number by table look up) always precedes its type 72. Should only
affect report programs which depend on non-missing SU_SEC in every
observation of TYPE70. You'll have to get SU_SEC from TYPE72 in the
future, since that's where it should have been all along.
4. ROSCOE users must note Change 4.76.
Please call if you experience any difficulties or problems. Barry
This member describes the changes made to the MXG Software since
Version 3 was shipped. Changes to variables and data sets between
Versions 3 and 4 are documented in member DOCVER04. The total list
of the contents of all data sets, new and old, created now by MXG
Version 4 is in member DOCVER. VMON data sets in DOCVER with numeric
suffixes are not finalized, and may change in name and contents.
Always look for additional documentation in comments at the beginning
of each member. Note that the members affected by each change, below,
are listed under the date of change. Read those members too.
Additional documentation is available in past and future issues of
the MXG Newsletter, sent by Merrill Consultants to their Supported
Customers. Newsletter EIGHT was published May 31, 1986.
Note these SAS Zaps which you may need to install:
Z5152456 - 0C4, 30A when over 20 variables on PLOT statement
Z5152254 - Protected data set errors after PROC DATASETS
Z5162525 - ABEND 999 with ERRORABEND when no variables in data
set for PROC CHART, PLOT, GPLOT and maybe others.
The following pages provide the sequential log of changes which have
been installed already in this MXG library. The most recent changes
are listed first.
NEXTCHANGE: Version 4
=====Changes thru 4.111 as of September 26, 1986======================
Change 04.111 A new IBM error in CICS CMF records has been uncovered
Sep 26, 1986 and circumvented. Problem only occurs after other PTFs
VMAC110 (PP43887 and/or AP40463) are installed. MCTSSDRL (the
data record length) is 2-8 bytes shorter than the real
data to be created. IBM truncates the data segment to
the (incorrect) length specified by MCTSSDRL. An APAR
will be issued next week. MXG circumvents by comparing
the expected length (EXPLEN, from IMACPTF status) with
MCTSSDRL. However, two fields SECOUCHR and PROGSTOR
are overlaid by next segment, and will be missing in
CICSTRAN data set when error is circumvented. Another
error, hit when over 100 bytes of user data is added
was found in MXG and was fixed.
Thanks to Thom Conley, Gold Circle Stores, USA.
Thanks to Kirby Kern, Commercial Federal Omaha, USA.
Change 04.110 SAS 5.15 ABENDs with 0C4 or 30-A when more than 20
Sep 24, 1986 variables are specified on a PLOT statement. While SAS
ANALDALY zap Z5152456 fixes the problem, the offending PLOT
statements were split in MXG to circumvent problem.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Thanks to Drew Pierson, PRC, USA.
Change 04.109 The JES 3 Accounting information in the type 26 purge
Sep 24, 1986 record was not handled correctly, occasionally causing
VMAC26J3 a STOPOVER ABEND. Now, ACCOUNT1 is parsed directly
from the 42-character field. The STOPOVER dump Dave
sent showed an undocumented field, OUTDEVCE, has been
added to the Print section added with MVS 2.1.7.
Thanks to Dave Harrison, Celenese, USA.
Change 04.108 VM Monitor validation completed for MXG Ver 4.4. See
Sep 21, 1986 details in member VMACVMON. Almost all variables are
VMACVMON exact when compared with detail VM MAP listing with
TYPEVMON VM 3.4 HPO. Test sites have validated with non-HPO
ANALVMON VM Version 4. HPO 4.2 has been coded, but the new
variables have not been verified. Highly usable, but
this gem is only faceted - polish will come in next
Version of MXG.
Change 04.107 ESP site input has further validated and enhanced the
Sep 21, 1986 IMS Log processing. Code now conforms to MXG Exit
TYPEIMS structure. RESPONSE time & components (when possible)
are calculated. John enhanced the data kept and also
captured local data from the RACF segments.
Thanks to John Loo, Fluor Corporation, USA.
Change 04.106 More IBM CICS errors. With PP43887 on CICS 1.6.1, the
Sep 19, 1986 record length MCTSSDRL is not always correct in the
VMAC110 CMF type 110 record. Problem at IBM Level 2. Has
caused specious 'missing TASKNR message'.
Transaction JC.. sometimes has nulls for TASKNR which
caused "missing TASKNR" message. Fix by message only
IF TASKNR=. AND TRANNAME NE 'JC..' THEN DO;
Thanks to Tom Koelle, Citicorp Information Systems Research, USA.
Thanks to Joe Faska, Chemical Bank, USA.
Thanks to Bill Cohen, Drexel, Burnaham and Lambert, USA.
Change 04.105 Validation of MXG DB2 data with DB2PRT caused fixes.
Sep 17, 1986 QTMAXDS=DIF(QTMAXDS) was deleted. MXG finds non-zero
ANALDB2 for QBnCRIO fields, which are zero on DB2PRT report.
QBnTCBA (n=1 to 4) disagree with DB2PRT at one site,.
but seem ok at another. Validate and call if you can.
SYSTEM added to SORT for DB2STAT1 and DB2STAT2 since
DB2 subsystem id (QWHSSSID) is not unique for SORT.
Thanks to Martha Hall, Metropolitan Life Insurance, USA.
Thanks to Scott Peterson, Southern California Edison, USA.
Change 04.104 VM Monitor cleanups
Sep 19, 1986 Non-HPO system: MN003CIE thru CSE do not exist. Fixed.
VMACVMON Used _HPO to test for class 0 code 3 to OUTPUT PERF &
VMONINST data sets after 0/03 record for non-HPO, but
OUTPUT them after class 0 code 4 for HPO systems.
Non-AP system does not write class 0 code 1 record.
Moved calculation of many variables to before OUTPUT.
Thanks to Wayne Kidd, SYNTEX, USA.
Change 04.103 MXG Lock manager data variables QTXA.... in DB2ACCT
Sep 16, 1986 have never been valid due to an MXG coding error. The
VMACDB2 QTXA.... variables in DB2STAT1 have been valid, tho
the IBM documentation is misleading. Now, QTXANPL
no longer exists in DB2STAT1 (it is only in ACCT) and
pointers to the six QTXA.... variables in DB2ACCT are
now read in from the correct offset. This fix was not
on 4.3 BETA tape.
Thanks to Sam Catalo, IBM Level 2, USA.
-----Changes thru 4.102 as of September 12, 1986 was the 4.3 BETA-----
Change 04.102 DISOSS Version 3 Release 3 Accounting record is now
Sep 12, 1986 supported. It provides more data than the perceeding
TYPEDISO record. See comments in TYPEDISO and DOCVER03.
FORMATS
Change 04.101 Turnaround example code now calculates in minutes to
Sep 8, 1986 be consistent with example in the book, and report
ANALTURN title identifies units.
Change 04.100 Cleanup of DATABASE data set built from TYPE1415 and
Sep 8, 1986 step records. Unreferenced variables from step record
ANALDSET are now deleted, saving space and avoiding confusion.
Thanks to Eustace Fernandez, Bow Valley Industries, CANADA.
Change 04.99 Support for IDMS log data and exit code to create SMF
Sep 21, 1986 records from IDMS log data. This is in addition to the
IDMSEXIT IDMS Performance Monitor SMF record supported by MXG
IDMSLOG Change 4.61. All documentation is in member IDMSEXIT,
IMACIDMS which contains the ASM source for an IDMS exit which
will create four SMF records with IDMS log-type data
VMAC200-203 without reading the IDMS DCLOG. Members TYPE200-3 will
TYPE200-203 create labeled MXG data sets from these MXG IDMS SMF
EXTY200-203 records. Member IDMSLOG will read the DCLOG itself,
but variables are not labelled (yet). Member IMACIDMS
defines the actual MXG IDMS SMF record IDs. There are
additional reports in IDMS.... members.
Thanks to Peter Bailey, Software Product Services, Woking, ENGLAND.
Change 04.98 Support for DOS POWER Version 2 coded, which contains
Sep 12, 1986 impacting changes in data format (DOSJOBS especially).
TYPEDOS Five new data sets are now created by MXG from V2:
FORMATS DOSBEGIN (startup statistics), DOSNET (network stats)
EXDOSBEG DOSPOOL (spool accounting), DOSXPCC (connection), and
EXDOSNET DOSXRC (transmit/receive spool). New member IMACDOSA
EXDOSPOL now defines DOSJOBS variable APLICATN; code had been
EXDOSXPC inline. Read comments at beginning of member TYPEDOS
IMACDOSA for all V2 documentation and DOS changes
Thanks to Paul Ehresmann, Compusource, USA.
Change 04.97 Several cleanup changes by 4.1 ESP user. TYPE75 data
Sep 6, 1986 not created if RMFINTRV run standalone. UTILCICS had
RMFINTRV missing semicolon in comments. Two CICSTRAN variables,
UTILCICS IWAITCN & IWAITTM were not in KEEP list (they exist
VMAC110 only if DLI counting is enabled in member IMACICDL).
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 04.96 Several 4.1 ESP changes. Inconsistency between JES2
Sep 6, 1986 and JES3 _NODUP macro corrected. OUTDEVCE & SYSTEM
BUILDPDB appended to TYPE6 bylist in NODUP SORT to avoid dupes
BUILDPD3 which had been encountered. Division by DURATM in type
VMAC74 74 protected for DURATM=0. CPUTM added to PDB.JOBS.
Thanks to Bill Cohen, Drexel Burnham, USA.
Thanks to M. Morris, Northern VA Highway Department, USA.
Change 04.95 TYPE 59 changes for NJE BDT in TNL GN28-1122 to SMF
Sep 6, 1986 manual were coded. I have never had type 59 records
VMAC59 to test, and no site has ever validated this code.
Change 04.94 The MONITOR FOR CICS from Landmark is now validated
Sep 6, 1986 and will now process compressed data, if the INFILE
EXITMONI exit TMON (JCL + SOURCE are in EXITMONI) is installed.
IMACMONI IMACMONI defaults to uncompressed format only. Once
TYPEMONI TMON is installed, either format is supported.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
(I can see why - they know he's so valuable you'll try to steal him).
Change 04.93 Test for CICTRANV at location 50 applied to CICS 1.6.1
Sep 5, 1986 without PP43887. Test should be at 51 with that PTF.
VMAC110 MXG was updated to test for PTF and then test at 50 or
51 as appropriate.
Thanks to Glen Wall, Databank, NEW ZEALAND.
Change 04.92 Calculation of some CPU variables was not perfect when
Sep 5, 1986 a 3084 was split into two 3081's. Only if the CPU was
VMAC7072 online during the entire interval will the CPU and its
contribution to wait be counted. If a processor is
offline at any time during the interval, it will not
be counted in NRCPUS and its wait will not be added to
CPUWAITM. Now, the CPUWAITn variable for that CPU will
contain the actual wait for that CPU (before this
change, it's CPUWAITM was set equal to DURATM).
Thanks to Andy Yu, B.C. Systems-Hi Tech Systems, CANADA.
Change 04.91 Substantial changes in DB2 data. MXG did not correctly
Sep 4, 1986 capture all of the DB2 data segments. See description
VMACDB2 in comments in VMACDB2.
ANALDB2
Thanks to Martha Hall, Metropolitan Life, USA.
Change 04.90 Type 40 (dynamic allocation) record did not include
Sep 4, 1986 +OFFSMF in line 67, causing error if VSAM SMF file
VMAC40 was read by MXG. Minimal impact, as 40 data is in 30
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
=====Changes thru 4.89 were ALPHA Version 4.2=========================
Change 04.89 Support for the ROSCOE Response Time Monitor records
Aug 4, 1986 (new in ROSCOE Release 5.4). Reports are provided,
TYPEROSC and Chuck Hopf's paper (in DOCRRTM) discusses the
VMACROSC good and the not so good of this response data. This
JCLROSC code is preliminary; variables are 8 rather than the
DOCROSC 4 bytes they will be, etc. The reports match okay.
Change 04.88 New routine analyzes SMF operator records 8,thru 11 to
Aug 4, 1986 detect when operators have varied tape drives online
ANALVARY simultaneously to multiple systems.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 04.87 SAS/GRAPH reports using RMFINTRV data were revised to
Aug 4, 1986 use SAS Version 5 Graphics catalogs. CLSTRPLY allows
GRAFRMFI TSO users to REPLAY these graphs.
CLSTRPLY
Change 04.86 Quotes were missing around the test value for CPUVERSN
Aug 4, 1986 in the example.
IMACPUXA
Thanks to Huddie Dean, Chilton Corp Dallas, USA.
Change 04.85 VM Monitor Support is now credible. The PERFORM, USER,
Aug 4, 1986 and DASTAP records are almost complete, and the VM MAP
TYPEVMON reports have been mostly validated. Read all of the
notes and comments in VMACVMON. More reports still
remain, and some important variables are not yet
deduced by MXG (help IS solicited), but tests under
VM HPO 3.4 look good. No HPO 4.2 data has been tested,
but I think the code will work for VM Release 3 and 4,
with or without HPO.
Thanks to Allan Russell, SAS Institute Europe, GERMANY.
Thanks to Daniel Delorge, SAS Institute, FRANCE.
Change 04.84 Validation of THE MONITOR FOR CICS (Landmark Corp's
Aug 3, 1986 product) data uncovered a few errors which are fixed.
TYPEMONI Most of the variables are already documented in MXG
Book Chapter 40 (CICSTRAN and CICSYSTM sections), but
also note that THE MONITOR only provides the elapsed
(attach to detach) response time; the IRESP (internal
response, ELAPSED-WTTCIOTM, which excludes the user
think and typing time) is not captured by THE MONITOR.
This change affected many lines to the MXG 4.1 code.
Thanks to Neil Ervin, Borg Warner Chemicals, USA.
Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 04.83 Some type 80s do not have the RACFTYPE and RACFDATA
Jul 17, 1986 segment, which was required for OUTPUT. This fix adds
VMAC80 %%INCLUDE SOURCLIB(EXTY8) to handle these cases.
Thanks to Tom Wiebe, NERCO, USA.
Change 04.82 INPUT statement did not include +OFFSMF offset to read
Jul 11, 1986 VSAM SMF data correctly. Normal SMF data was handled
VMAC8911 okay.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 04.81 VMONCU data was incorrectly documented by IBM. An obs
Jul 10, 1986 will be created only if the device actually had busy
VMACVMON measured from CPU or from APU.
Thanks to Terry Magill, NAS, USA.
Change 04.80 CICSTRAN IRESPTM (Internal response) was non-zero even
Jun 30, 1986 if ERRFLAG was on, because it was carried from prior
VMAC110 transaction, because it was not initialized to missing
before each calculation.
Thanks to Evangeline Jacobs, Stearns Catalytic, USA.
Thanks to James Tummins, Stearns Catalytic, USA.
Change 04.79 GDGATTR changed to PIB1., HEX2. from character, as
Jun 22, 1986 it conflicted with VMAC6367. (Not caught by UTILXREF
VMAC6156 because neither variable is actually KEPT, and only
caused problem if 6156 and 6367 simultaneously built.)
Thanks to Malcolm Morgan, Wachovia Bank, USA.
Thanks to Norbert Riehout, Great Western, USA.
-----Changes thru 4.78 were in Pre-Release of Version 4.1.
Change 04.78 Correction to Change 4.55 for RACF 1.7. The OFFSET
Jun 9, 1986 equations added by 4.55 was restored to the original:
VMAC80 OFFSET=OFFSET+1+OFFSMF;
Type 80s from TOPSECRET need OFFSET=OFFSET-3+OFFSMF,
still under investigation with that vendor.
Thanks to Tom Weibe, NERCO, USA.
Change 04.77 CICS Transaction variable TRMCHRCN, total characters
Jun 9, 1986 in and out, was not created for CICS 1.7. (It was an
VMAC110 INPUTed variable in 1.6).
Thanks to Barbara Watters, EXXON Houston, USA.
-----Changes thru 4.76 completed May 31, 1986 Release of Version 4.1.
Change 04.76 Variable CPUTM in the ROSCO... data sets was renamed
May 31, 1986 to CPUTCBTM to be consistent with its meaning. Note
VMACROSC that CPUTM was removed, which may cause your ROSCO...
report programs (other than ANALROSC, which we fixed
to use CPUTCBTM) to fail. (We had to correct this one,
because the ROSCO label for CPUTM could override the
correct TYPE30 label.) Sorry I didn't catch this one
when I validated the original ROSCOE code.
Change 04.75 Queueing percentages are now correct. EVENTS should
May 31, 1986 have been the divident instead of NRSAMPLES.
VMAC77
Change 04.74 Conflicts in LABELs for variables with the same name
May 31, 1986 in different MXG data sets were resolved. Changes in
DOC LABEL were to clarify and be consistent, but should
not really be noticed; PHYSICAL*BLOCK SIZE*(BYTES)
replaced BLOCK*SIZE, for example.
Change 04.73 Change 4.65 was redesigned, and its description below
May 31, 1986 was changed after printing of MXG Newsletter EIGHT.
VMAC110
Change 04.72 VM Account Card data set VMVCNA was all wrong (though
May 29, 1986 it didn't raise an error) due to IBM format changes we
TYPEVM overlooked.
Thanks to Jonathan Aliber, Fidelity Systems, USA.
Change 04.71 Test for blank SYSEXEC to delete non-execution purge
May 28, 1986 records was expanded to also test for nulls (hex 0) as
BUILDPDB NJE purge records are null, whereas JES are blank.
Thanks to Al Loyd, DOD, Ft. Meade, Md, USA.
Change 04.70 AVGRSPTM (average response time) variable added to the
May 28, 1986 NLDM Type 39 data sets.
VMAC39
Change 04.69 You should know this already, if you read INSTALL like
May 27, 1986 you were supposed to (first). MXG EXIT Facility is now
INSTALL documented in member INSTALL (essentially as it will
be in Chapter 33 of the MXG Supplement). Additional
sections in INSTALL cross reference member to product
to MXG data set created to EXIT member names. Read it.
Change 04.68 Member TYPEDOS was restructured to extend the MXG EXIT
May 27, 1986 facility to DOS. See comments in TYPEDOS, and INSTALL.
TYPEDOS It should not impact present DOS data sets in any way,
EXDOS... unless you choose to enable it.
Thanks to Barry Lewis, CIA, USA.
Change 04.67 Standalone execution of RMFINTRV (by removal of the
May 27, 1986 comment block around the SMF processing) did not keep
RMFINTRV all of the RMF data sets which are kept when RMFINTRV
is invoked by BUILDPDB. Standalone RMFINTRV now agrees
Thanks to Barry Lewis, CIA, USA.
Change 04.66 JES3 clock differences between LOCAL and GLOBAL
May 27, 1986 processors can cause BUILDPD3 to not recognize that
BUILDPD3 the job is complete. _TIMEDIF macro is now defined
IMACTIME in IMACTIME to allow installations to specify a time
"fuzziness" for BUILDPD3 logic. Read IMACTIME.
Thanks to Barry Lewis, CIA, USA.
Change 04.65 Incorrect PTF information in IMACPTF can cause CICS
May 31, 1986 data sets to be built with no apparent error, but
VMAC110 containing invalid data (notably, TASKNR missing.)
This was because MXG used the ?? marker to supress
the dump of the record, the error message and _ERROR_
set by SAS for TASKNR. The ?? has been retained, but
an MXG ERROR MESSAGE now notifies you that the CMF
data format has been changes, and suggests you run
UTILCICS which will identify your PTF level by APPLID.
THE BAD OBSERVATIONS (TASKNR=.) ARE NOW DELETED FROM
CICSTRAN.
Thanks to Joe Faska, Chemical Bank, USA.
for lots of good input here.
Change 04.64 Minor changes during testing of 4.61 (IDMS-RTE)
May 19, 1986 Insert RT1DCDTW=DATEJUL(RT1DCDTW); Format 12.2 of
VMACRTE RT1DCTIT,TTT changed to 8., TST,TUT,TWT to 14.4;
IO is PAGES READ + PAGES WRITTEN; BST reports show
BATCH for Program Type when Type Task is Batch.
-----Changes thru 4.63 completed the first pre-release of Version 4.1.
Change 04.63 Support for The Monitor for CICS product of Landmark
May 13, 1986 Systems. Variable names were taken from existing MXG
TYPEMONI data sets CICSTRAN and CICSYSTM (book, page 398) when
FORMATS possible. The code has only been syntax checked; the
MONITOR data tape did not arrive. Two test sites will
validate before you read this; call before believing.
Change 04.62 Split into five steps and better documented. Version 4
May 13, 1986 broke the SAS limit of 32768 SYSIN cards (it is fixed
JCLTEST in SAS Version 5.15). JCLTEST MUST BE EXECUTED WITH A
TESTIBM NEW VERSION OF MXG. Self documenting. New naming code:
TESTUSER members used to test MXG will begin with TEST.
TESTOTHR Old MXG testing members TYPETEST,OTHRTEST,TYPEPRNT, &
OTHRPRNT are deleted in Version 4 to force the issue.
Change 04.61 Support for Cullinet's IDMS Performance Monitor SMF
May 12, 1986 record. Called RTE because it was born as the Run Time
TYPERTE Evaluator product of Business Software Technology. The
FORMATS SMF record type (their default 230) must be enabled in
EXTYRTE IMACRTE. The monitor provides task level resource data
IMACRTE
Thanks to Myles McCarthy, Fidelity Systems, USA.
Change 04.60 Support for RMF System Availability Management data
May 12, 1986 records. Three data sets SAMINFO, SAMTERM & SAMSKED
TYPESAM can be built from data captured by the new RMF/SAM
component introduced in RMF 3.4. SAMTERM & SAMSKED
are from installation data, SAMINFO is created from
RMF data sent to the SAM Info/MGT data base, extracted
with a SAM supplied utility. SAM detects system level
availability events (IPLs, WAITs, LOOPs), and step
terminations, but nothing at the subsystem level.
Change 04.59 Corrected calculation of OSWAITTM variable (which
May 12, 1986 had omitted multiply by 16). In the process, all
VMAC110 duration (TM) variables which had been created by
(PIB4., then /62500) are now instead created with
the equivalent (PIB4.6, then *16) for consistency.
Thanks to Barbara Watters, EXXON Houston, USA.
Change 04.58 Support for type 24 JES2 SPOOL OFFLOAD Program
May 12, 1986 Product. Separate information for jobs offloaded
VMAC24 and SYSOUT files offloaded from SPOOL.
FORMATS
Change 04.57 Support for additional segment (CTC) in type 50 SMF
May 12, 1986 VTAM Tuning Statistics record. The existing SNA VTAM
VMAC50 data is supplemented with new data for VTAM CTC use.
Change 04.56 Support for BDT (Bulk Data Transfer) type 59 SMF
May 10, 1986 record has been coded. It has not been validated by
VMAC59 actual data records. Call if you have verified it.
Change 04.55 Support for RACF 1.7 type 80 SMF record. Fields are
May 9, 1986 decoded with several new formats.
VMAC80
FORMATS
Change 04.54 Consolidation of the multiple LABEL, FORMAT, & LENGTH
May 8, 1986 statements to avoid redundant SAS statements. This
DOC has the added advantage that these MXG data sets
will now have all variables in alphabetic order.
VMAC7072 VMAC71 VMAC73 VMAC74 VMAC75 VMAC76 VMAC77
VMAC78 VMAC30
Change 04.53 New variables AVGPAGMS and AVGSWPMS are now created to
May 7, 1986 match RMF reports of same values.
VMAC75
Change 04.52 Final validation of RMF 3.4 data showed three wrong
May 6, 1986 values which are now corrected. EXTFRMON is PIB4.0,
VMAC71 not PIB4.1; MIGAGEAV is PIB4.1, not PIB4.0; and
PVTMVTOT is now a rate per second with correct label.
Change 04.51 New documentation shows the new measure of all path
May 6, 1986 busy should be PCTPTHBY=100*PCTPTHBY/NRCMPTSM;
VMAC78 Comparison of MXG PCTCUBSY (using RMF manual equation)
does not exactly match % CU BUSY field on RMF report;
usually close, sometimes MXG shows 26% while RMF only
has 17%. Checking with IBM, think we are right.
Thanks to Jan Van Lent, Fokker BV, Schiphol, THE NETHERLANDS.
Change 04.50 STARTIME in the TYPE38IN interval data set had the
May 6, 1986 prior day's date if the interval ended after midnight.
VMAC38 Subtract NPATM from SMFTIME inside DATEPART function.
Thanks to Roger Konydyk, Steelcase, USA.
Change 04.49 IMACPTF added. A new maintenance facility for MXG in
May 6, 1986 which MXG code to support certain IBM PTFs (Program
IMACPTF Temporary Fixes) is enabled. Currently used only by
VMAC110 to support CICS PTFs. Check here first if
you find a PTF which changes data; it may already be
supported in MXG, awaiting only your enablement here.
Change 04.48 CICS PTF PP43887 adds new field in middle of record.
May 6, 1986 For sites using CICS IRC (Inter Region Communication)
VMAC110 the new variables WTIRIOTM and WTIRIOCN give the total
time (and count of times) that this transaction waited
for IO from the other CICS IRC region. You must update
IMACPTF to enable _PP43887 when this PTF is installed.
With the PTF installed and not enabled in MXG, the
data in CICSTRAN variables will be wrong.
Thanks to Sheldon Auerbach, AmeriTrust Cleveland, USA.
Change 04.47 IMACKEEP (which contains your re-definitions of the
May 6, 1986 MXG _VAR.... macro which contains KEEP= list for all
BUILDPDB/3 MXG data sets) must be INCLUDEd after EXPDBINC.
Thanks to Malcolm Morgan, Wachovia Bank, USA.
Change 04.46 Line 73 assumed OFFSET was from beginning of QSAM
May 6, 1986 data, but it is from beginning of the BSAM record.
VMAC80 Change +1 to -3 (to account 4-byte RDW difference).
Thanks to Craig Feitzner, Citicorp, USA.
Change 04.45 Support for Database 2 Release 2 changes to type 100
Apr 22, 1986 and 101 SMF records.
VMACDB2 DB2STAT0: Q9STCTRC, QWSDCKPT, QWSDINV1-4
FORMATS DB2STAT1: QBSTIMW,"SEQ,"SPP,"SPD,"REE,"WEE,"DWT."DMC
QISECT,"CTL,"CTG,"DBD,"DBDG,"DBDL,"FREE,
"SKCT,"FAIL,"PAGE,
QXALABON
QTXALES,"LEN,"NPL
DB2ACCT : QWACAJST,"ARNA,"ARNE,"ASC,"ASRB,"AWTI,"AWTL
QXALABON
QTXALES,"LEN,"NPL
QBACSEQ
The new type 102 SMF record written by DB2 trace is not presently
decoded by MXG; when pushed by a user with data in hand, we will
investigate its complexity and eventually support it.
Change 04.44 Support for the NPDA type 37 SMF record.
Apr 21, 1986
TYPE37
VMAC37
FORMATS
Change 04.43 CMS Support, for the execution of MXG under CMS SAS.
Apr 8, 1986 Installation instructions are contained in this new
INSTALL member.
Change 04.42 VM Monitor data support. The VMONnnnn data sets which
Apr 8, 1986 can be created from VM monitor records are documented
TYPEVMON in INSTALL. All other documentation is in VMACVMON
VMACVMON comments. Note that you must have SAS Version 5.12
or later to read Monitor data from the virtual reader
(which needs MONITOR exit, new with 5.12).
Change 04.41 All PROC DELETE's were changed to PROC DATASETS NOLIST
Apr 8, 1986 because SAS no longer supports PROC DELETE.
DOC BUILDPDB/3 ANALDB2,DOS,ESV,ROSC
Change 04.40 The FWINDEX calculation for overflow DLI call counting
Apr 7, 1986 was incorrect; when overflow occurred (almost never,
VMACCIMS except for occasional big BMPs), overflow count was
added to wrong bucket.
Thanks to Ron Root, Sun Company Dallas, USA.
Change 04.39 Duplicate data removal (Change 4.38) was disabled due
Apr 7, 1986 to a SAS error in the NODUP option of PROC SORT when
BUILDPDB NODUP and KEEP= or DROP= were used. NODUP compared the
BUILDPD3 records (wrongly) using the output buffer length. With
KEEP or DROP, the output record is shorter than input,
causing SAS to falsely detect and delete non-duplicate
records. SAS HAS FIXED THE PROBLEM IN 5.15 AND LATER.
(See SAS usage note 2079 for 5.08 and earlier).
To enable duplicate data removal for all SORTS after
you install SAS 5.15, EDIT BUILDPDB/3 and change the
MACRO _NODUP % to MACRO _NODUP NODUP % as described
in comments.
This disabling of the NODUP option only affects the
job records (6, 26, and 30); the majority of the PROC
SORTs in BUILDPDB do not use KEEP= and thus NODUP is
enabled. When duplicate records are encountered by
the NODUP options, SAS tells you with a log NOTE.
Thanks to Dale Ingold, SAS Institute Cary, USA.
for quick response and repair.
Change 04.38 1. Duplicate data records in the input SMF file will now
Mar 26, 1986 be automatically deleted from the PDB files, and a
BUILDPDB SAS NOTE on the LOG will tell you that duplicate data
BUILDPD3 was found and deleted for each SAS data set.
Note that this will still only remove identical SMF
data in today's input SMF file. Re-processing data
today (which was previously processed) would not be
detectable by the NODUP options. This enhancement
provides most of the function which the non-existent
ANALDUPE member was intended to perform.
Removal of duplicate data is done by the addition of
the SAS NODUP option to the first SORT of the input
data sets, and by adding variables to the BY list to
force uniqueness for the NODUP option. Since the high
level BY variables in those SORTs were not changed,
your present reporting should not be impacted. You may
want to take advantage of the new sort order, since it
ususally will eliminate a sort in your reporting.
Because CICSTRAN data set is created direct from the
SMF data, there is no SORT in BUILDPDB/3 and there is
no automatic duplicate removal in BUILDPDB/3. In your
CICSTRAN report programs you normally must sort the
data anyhow. To remove dupes, simply add NODUP to the
PROC SORT and expand the BY list to include all the
variables in the CICSACCT By list, below.
The following list shows the original sort order with
a + to indicate where new sort variables were added.
Dataset BY Variables
CICSACCT APPLID+ TERMINAL OPERATOR USER TRANTYPE TRANNAME ENDTIME
CICSEXCE APPLID+ TERMINAL OPERATOR USER TRANTYPE TRANNAME ENDTIME
CICSYSTM APPLID STRTTIME+ ENDTIME
TYPE0 SYSTEM+ IPLTIME
TYPE21 SYSTEM+ SMFTIME DEVNR
TYPE70 SYSTEM STARTIME+ SMFTIME
TYPE71 SYSTEM STARTIME+ SMFTIME
TYPE72 SYSTEM STARTIME+ PERFGRP PERIOD SMFTIME
TYPE73 SYSTEM STARTIME+ CHPID SMFTIME
TYPE73P SYSTEM STARTIME+ CHAN SMFTIME
TYPE73L SYSTEM STARTIME+ LCHAN SMFTIME
TYPE74 SYSTEM STARTIME+ DEVNR SMFTIME
TYPE75 SYSTEM STARTIME+ DEVNR PAGEDSN SMFTIME
TYPE78 SYSTEM STARTIME+ LCUID SMFTIME
TYPE78CF SYSTEM STARTIME+ LCUID CHPID SMFTIME
TYPE78CU SYSTEM STARTIME+ LCUID SMFTIME
TYPE78IO SYSTEM STARTIME+ IOPIQID SMFTIME
TYPE78PA SYSTEM STARTIME+ READTIME JOB SMFTIME
TYPE78SP SYSTEM STARTIME+ READTIME JOB SMFTIME
TYPE78VS SYSTEM STARTIME+ SMFTIME
TYPE30_D READTIME JOB JESNR+ INITTIME INTBTIME SMFTIME
TYPE30_V READTIME JOB JESNR+ INTBTIME INTETIME
TYPE30_1 READTIME JOB JESNR JINTTIME+
TYPE30_4 READTIME JOB JESNR TERMTIME+
TYPE30_5 READTIME JOB JESNR DESCENDING JTRMTIME+
TYPE6 READTIME JOB JESNR PRINTIME+ PRENTIME OUTDEVCE SYSTEM
TYPE26 READTIME JOB JESNR+ JPURTIME SYSEXEC
Thanks to ???, NRMA, AUSTRALIA.
who suggested this in 1984.
Change 04.37 Variable EXCPRMF in type 30 data sets is calculated
Mar 26, 1986 from data in the 30 (IOUNITS) and from the IOCCOEFF
VMAC30 coefficient in the type 72. If a 30 was encountered
VMAC7072 before a 72, EXCPRMF would be missing. However, if
duplicate 30 records were separated by a 72, the
first 30 had missing EXCPRMF, while the duplicate had
a value, which prevented NODUP option in SORT from
recognizing the true duplicate. Now, IOCSYSTM is
retained from 72 and compared with SYSTEM in 30 to
only create EXCPRMF when preceding 72 is from same
system, and thus allow NODUP option to delete dupes.
Change 04.36 When the EJST,SRBT suffix variables from QWSA were
Apr 07, 1986 split into QWS1 and QWS2, and when ISEQ,SBNA,SCF,
ANALDB2 SRND,SRNW,SRSW,OTH1,OTH2 suffix variables from QWSC
were split into QWS1, QWS2 and QWS3 prefixes, the
DIF() operations necessary to make the DB2 data
meaningful were overlooked in ANALDB2, which affects
those variables (and CPUTM) in DB2STAT0 data set.
New variables DB2TCBTM,DB2SRBTM,ELAPSTM,JOB are now
created in DB2ACCT.
Remember, ANALDB2 is not optional; it is automatically
invoked by TYPEDB2, and must be included in EXPDBCDE
if you create DB2 data sets with BUILDPDB.
Thanks to Mike Schilling, NORWEST Information Services, USA.
Change 04.35 TERMADDR and MINIADDR in several VM data sets built
Mar 24, 1986 from VM Accounting Card data should not be $HEX6. as
TYPEVM they were characters all along. Remove from FORMAT.
Thanks to ???, ???.
Change 04.34 Under XA only, the PAG values in SMF are the sum of
Mar 24, 1986 PAG + FIX, but MXG did not recognize that fact. With
VMAC71 this change, the MXG value of PAG variables will be
correct (and are less than the MXG V3 values).
Thanks to Les Czegel, CIL, CANADA.
Change 04.33 Interval begin time INTBTIME added to the TYPE30_D DD
Mar 24, 1986 level data set, so that DD observations from different
VMAC30 intervals of the same step (i.e., same INITTIME) can
be recognized.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 04.32 1. The Vector Processor accounting times (VPU & VPI) for
Mar 24, 1986 USE and AFFinity were added to PDB.JOBS and PDB.STEPS.
BUILDPDB 2. INTBTIME (interval begin time) was added to the BY
BUILDPD3 list (READTIME JOB JESNR INTBTIME INTETIME) for
TYPE30_V (now that RMF 3.3 provides INTBTIME).
4. SMFTIME was appended to the BY list (READTIME JOB
JESNR INITTIME SMFTIME) for TYPE30_D (DD statistics)
so DD records from different intervals (which will
have same INITTIME) can be identified and ordered.
Change 04.31 New data in TYPE21 record now supported. New counts
Apr 4, 1986 of errors for 3480, tape unit serial number, DCBOFLG,
VMAC21 and separate counts of bytes written and read added.
See TNL GN28-1095 for PTF OZ89909, Jan 16, 1986.
Change 04.30 Data sets TYPE78PA, TYPE78SP, and TYPE78VS were not
Mar 20, 1986 created by BUILDPDB (but were for BUILDPD3). This
BUILDPDB change adds those three (small) data sets to the PDB.
Thanks to Wing Louie, Metropolitan Life, USA.
Change 04.29 ZDATE ("Zee date zee data was added to zee PDB") was
Mar 20, 1986 added to _JOURNAL macro for CICS journal format data.
RMFINTRV ZDATE was also added to the KEEP list for RMFINTRV.
VMACSMF
Thanks to Cathy Hellums, Aristar, USA.
Change 04.28 TYPE72 and TYPE74 data sets do not always contain all
Mar 20, 1986 possible observations. Only if SERVICE or SIOCOUNT was
VMAC7072 non-zero would MXG OUTPUT, and the control logic was
EXTY72 in the VMAC member. Now, the control logic for their
VMAC74 OUTPUT statement has been moved to their EXTYnn member
EXTY74 so that sites which want all observations can make
the change in their exit code. Sites which use TYPE74
for availability want all observations, and sites that
use report perf. groups but capture only transactions
may want all TYPE72 observations. The default was not
changed, only the location of the default logic was.
Thanks to Barbara Watters, EXXON Houston, USA
Change 04.27 PRQUETM is now correct for JES3. For JES2, the start
Mar 20, 1986 of print queue time is JFINTIME, but JES3 does not
BUILDPD3 terminate output processing (JFINTIME) until purge.
Thus JPRNTIME (start of output processing) must be
uses for JES3 start of print queue time.
Change 04.26 4381-III CPU factor (pre-RMF 3.3) for single CPU is
Mar 20, 1986 now correct. 4381 de-rates UP by 85% when MP'ed, but
VMAC7072 all other MVS machines de-rate 95%, 92% and 89% when
2, 3, or 4 processors are online.
Thanks to David Belsham, Lloyds Corporation.
Change 04.25 Inconsistent RMF data caused NOTSORTED error in one
Mar 20, 1986 site because BY statement was missing. Additional
RMFINTRV check added to advise if RMF data was inconsistent.
Thanks to Pat Goetzinger, Northwestern Bell (of Nebraska!), USA.
Change 04.24 Production version of RMF 3.3 relocated LCUID field
Mar 4, 1986 in TYPE78 data set (only for 3090 CPUs).
VMAC78
Thanks to Greg Scriba, First National of Chicago, USA.
-----Changes thru 4.23 completed first PRE-RELEASE of Version 4.0-----
Change 04.23 Partitioning 3084s into 3081s, etc., caused MXG to
Jan 31, 1986 incorrectly calculate PCTCPUBY after splitting the
VMAC7072 CPUs. Beautiful fix (print of source, highlighted
with his changes, and with two pages of descriptive
documentation) was supplied by, and therefore
Thanks to Stephen Secher-Jensen, ANZ Bank, Melbourne, AUSTRALIA.
Change 04.22 The current version of MODEL 204 now contains the
Jan 27, 1986 M24ACCT and M24USER by default, so the exit is now
EXM24ACT set to default ON (was OFF). See member.
Thanks to David Daner, Sun Company, USA.
Change 04.21 IMS Log processing code. IMSTRAN and IMSMISS data sets
Jan 22, 1986 are built from sequences of IMS log records. This code
TYPEIMS was originally written and tested in Europe. It seems
IMACIMS to handle IMS 1.3 quite well, and is self-documenting.
EXIMSTRN Wherever possible, variable names of IMS Log data are
EXIMSMIS the same as those used for the IMF/Control IMS data
set CIMSTRAN, page 413.
Thanks to Allan Russell, SAS Institute Europe, GERMANY.
Change 04.20 JES3 BUILDPDB ABEND and CONDCODE "fixes" were not
Jan 22, 1986 completed with change 4.xx. Variables ABEND and
BUILDPD3 CONDCODE were added following KEEP= _PDB30_5 in
PROC SORT DATA=TYPE30_5 OUT=TYPE30_5 (KEEP= ....
Thanks to Bill Cohen, Drexel, Burnham, Lambert, USA.
Change 04.19 The catalog record at the end of the 61,65 and 66
Jan 15, 1986 records was not decoded. The program will now (if
VMAC6156 you choose) decode and print (but not add to the
TYPE6156 data set) these catalog segments. See the
'how to' comments in the member itself.
Thanks to Gary Bortner, Lucky Stores, USA.
Thanks to John Lemkelde, Pennsylvania Blue Shield, USA.
Change 04.18 Added five more work groups OTH1-OTH5 to RMFINTRV
Jan 8, 1986 data set. Added Exit EXRMFINT so you can label the
RMFINTRV variables to describe that OTH1 is IDMS, etc.
EXRMFINT Comments added to IMACWORK to show how to use.
IMACWORK March 20, calculation code finally added!
Thanks to George Scott, Rockwell International Corporation, USA.
Thanks to Greg Scriba, First National of Chicago, USA.
Change 04.17 Support for CICS 1.7. Major changes in internal data
Jan 8, 1986 format, with some new variables, but minimal impact
VMAC110 on your programs. Will be discussed in future issue
FORMATS of MXG Newsletter. Do not gen CICS 1.7 with EXCLUDEs.
Change 04.16 Input format for OFFDATE in DOSRJE is MMDDYY6., and
Jan 8, 1986 PRTYJOB=MOD(PRTYJOB,16) replaced PRTY=MOD(PRTY,16).
TYPEDOS
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 04.15 PTF UZ90402 for RMF 3.3 alters MVS/XA RMF format for
Dec 29, 1985 Vector Processors, even if you don't have one! The
following changes were published in MXG NEWSLETTER
SEVEN prior to availability of Version 4.1. Actual
code in Version 4 is more comprehensive that the
quick fix printed in Newsletter Eight.
VMAC7072 a. VECONSAM and VECTORON variables added to TYPE70.
VMAC22 b. VECTORON added.
VMAC30 c. Step level vector utilization variables added.
VPUUSETM
VPIUSETM
VPUAFFTM
VPIAFFTM
d. Interval begin time, INTBTIME, finally put in
the subtype 2 and 3 interval records by IBM.
Thanks to George Scott, Rockwell International Corporation, USA.
Change 04.14 Constant 000000954 should be 000000953674. Causes a
Dec 29, 1985 very small rounding error. Almost a nit.
FORMATS
Thanks to Joe Faska, Chemical Bank, USA.
Change 04.13 Standard deviation of response time calculation can
Dec 26, 1985 cause negative square root. Test added to avoid the
VMAC7072 illegal argument error message. SSQELAP wraps inside
RMF, creating above problem. IBM has been notified.
Change 04.12 RMF 3.3 expanded LCUID to two bytes in the subtype 1
Dec 18, 1985 record. MXG V3 missed this change, causing LCUID to
VMAC78 be zero in TYPE78CF.
Thanks to Joe Faska, Chemical Bank, USA.
Change 04.11 SAS Version 5 requires quotes around all character
Dec 02, 1985 strings. LABEL and FORMAT statements had been fixed,
TYPEPRNT but execution with NOTEXT82 option suraced others.
OTHRPRNT Quotes in SPLIT='*' and quotes around hex character
FORMATS values in PROC FORMAT were added to these members:
BUILDPD3 (Also removed superfulous PROC PRINT from BUILDPD3)
ANALCICS ANALCONT ANALDALY ANALDOS ANALESV
ANALPROG ANALTSOR ANALTURN ANALVM
Thanks to David Henley, Blue Cross, USA.
Change 04.10 INTRVAVG is always missing. Change equations (two)
Dec 02, 1985 which calculate INTRVAVG to use INTRVSUM as first
VMAC76 term on right side of equation.
Thanks to Kenneth D. Jones, Maritime Telegraph and Telephone, CANADA.
Change 04.09 RESPAVG and RESPSTD and AVGMEMSZ values were carried
Dec 02, 1985 into next PERFGRP.PERIOD if TRANS=0 or CPUUNITS=0.
VMAC7072 After each of the 6 IF statements which calculate
these variables, insert 'ELSE variable=.;' to set
the value to missing.
Thanks to Sue Rosansky, Metropolitan Life, USA.
Change 04.08 Logic to set return code to 4096 or less was added
Nov 19, 1985 to parallel type 4, 30 and 34 records as well.
VMAC535
Thanks to Sam Ferrarelli, Philadelphia Electric, USA.
Change 04.07 Additional tests for zero denominator added for the
Nov 19, 1985 variable NRSAMPLE (which strangely is sometimes 0).
VMAC74
Thanks to Joe Faska, Chemical Bank, USA.
Change 04.06 Change 2.22(a) was not completely applied for JES3.
Nov 19, 1985
BUILDPD3
a. Find the three lines which create TYPE30_5 from the
SET TYPE30_5 SPIN30_5; statement.
Replace those three lines with the similar eight
lines from member BUILDPDB.
b. Find MACRO _SUMSTP. Remove the variable TAPEDRVS in
that macro definition by blanking it out.
c. Find DATA ONE30_5, then find FORMAT CONDCODE HEX4.
insert two lines: ABEND=ABEND5; CONDCODE=CONDCOD5;
Thanks to George Scott, Rockwell International Corporation, USA.
Thanks to Martin Hamburg,Johns Hopkins Univ Applied Physics Lab, USA.
Change 04.05 Five new variables (RMF 3.3 only) were INPUT out of
Nov 18, 1985 order. Starting at OFFPGDS+392, variables should be
VMAC71 MIGAGEMN,MX,AV, and EXTFRMIN,ON.
Thanks to Sue Rosansky, Metropolitan Life, USA.
Change 04.04 Removed lower case from IMACINTV, as it caused SPF
Nov 6, 1985 to change case and data values became lower case!
IMACINTV
Thanks to Dennis Dwyer, CITICORP Person-to Person, USA.
Change 04.03 Minor correction to MG078CV format to add HIGH.
Nov 6, 1985
FORMATS
Thanks to Joe Faska, Chemical Bank, USA.
Change 04.02 Corrected algorithm for counting tape drives used
Nov 4, 1985 and added count of tape drives potentially needed.
ANALTAPE Many lines involved. Call for information.
Thanks to Robin Templer, SAS Institute, AUSTRALIA.
Change 04.01 Backed out 2.3. Default record ID from TSO/MON and
Nov 4, 1985 MXG now agree (they're alphanumeric: CMD - SYS for
IMACTSOM 199 and 200 respectively).
Thanks to Ray Dickensheets, Yellow Freight System, USA.
LASTCHANGE: Version 4
=========================member=CHANGE03================================
/* COPYRIGHT (C) 1985 BY MERRILL CONSULTANTS DALLAS TEXAS */
MXG Software Status as of November 1, 1985
This is MXG Version 3.
This member describes the changes made to the MXG Software since
Version 2 was shipped. The documentation of new data sets and new
variables created by Version 3 is contained in member DOCVER03. The
changes previously introduced by Version 2 are in member DOCVER02.
Additional documentation is available in past and future issues of
the MXG Newsletter, sent by Merrill Consultants to their Supported
Customers. Newsletter SIX was published concurrent with Version 3.
NEXTCHANGE: Version 3
=============Changes thru 3.10 complete Version 3.2==================
Change 03.10 Format DATE9. added for DATE in RMFINTRV data set.
Oct 30, 1985
RMFINTRV
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 03.09 Error in reading TPUTHOLD variable in TSO/MON 4.3
Oct 30, 1985
VMACTSOM
Thanks to Gayle Bartel, Pizza Hut, USA.
Change 03.08 LOGAUX... variables missing in TYPE71 with RMF 3.3
Oct 30, 1985
VMAC71
Thanks to Sue Rosansky, Metropolitan Life, USA.
=============Changes thru 3.07 were in Version 3.1===================
Change 03.07 Added format MG078CV. to map bytes to K or Meg for
Oct 18, 1985 PVTSZHI/LOW, LSQSZHI/LOW and USRSZHI/LOW. Midnight
VMAC30 logic error corrected.
Change 03.05 Error introduced in Change 2.19 caused all of the
Oct 17, 1985 TYPE70 variables .....AVG to be 100 times too big.
VMAC7072
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 03.04 Error introduced in Change 2.24 caused loss of type
Oct 15, 1985 30 data sets observations.
VMAC30
Thanks to Roman Gudz, Leaseway, USA.
Change 03.03 IBM offset values were wrong (from start of logical
Oct 15, 1985 record) but MXG coded for it. Now IBM PSF changes
VMAC5234 for 3820 changes PROD offset, but left ID offset
still wrong. MXG now forces the OFFPROD and OFFID
values, since data location is unchanged.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 03.02 CICS PTF UP90227/UP90228 for APAR PP41582, an SPE
Oct 15, 1985 for CICS 1.6.1, changes CMF record version from 2
VMAC110 to 3.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 03.01 Undocumented field, QBACRIO, DB2 Synchronous Read
Oct 15, 1985 I/O requests was discovered and now in the DB2ACCT
VMACDB2 data set.
Thanks to Ron Root, Sun Company, USA.
LASTCHANGE: Version 3
NEXTCHANGE: Version 2
=============Changes thru 2.25 were in Version 3.0===================
Change 02.25 MVS 2.1.3 increased the size of MPL, WEIGHT, AOBJ,
Sep 20, 1985 DOBJ and DFWK values from one to two bytes.
TYPE90
Change 02.24 Condition code (return code) must be less than 4096.
Sep 9, 1985 Some accounting systems exploit this and use upper
TYPE30_4 bits of the two byte field. MXG decoded the entire
TYPE30_5 return code, producing invalid values. Now only the
TYPE434 rightmost bits are used for return code value.
Thanks to John Zupan, STC, USA.
Change 02.23 Variables AVG and INTRVAVG were added.
Sep 9, 1985
TYPE76
Thanks to Debby Blackey, Fidelity Savings, USA.
Change 02.22 Several enhancements made to BUILDPDB/BUILDPD3.
Sep 9, 1985 a. ABEND and CONDCODE in the JOBS data set is now the
BUILDPDB job completion status for the last job termination
BUILDPD3 (subtype 5) record. Formerly, it was the last step
termination and was misleading (i.e., ABEND would
be FLUSH for a flushed step in the JOBS dataset).
b. EXCP and IOTM for tapes 3420 and 3480 added.
c. SPINCNT (the number of times partially-completed
jobs will be held in the SPIN file awaiting their
purge record) is now set by member IMACSPIN.
d. TYPE78CF, TYPE78CU and TYPE78IO now in PDB.
e. SAS5FIX1 module created to correct the SAS error
in SAS VERSION 5 until SAS provides the first
maintenance release to VERSION 5. If you execute
BUILDPDB/BUILDPD3 under SAS VERSION 5, you must
tack SAS5FIX1 on after the PDB is built. See the
comments in SAS5FIX1.
Thanks to Malcolm Morgan, Wachovia Bank, USA.
Thanks to Georg Simon, Prudential Insurance, USA.
Change 02.21 Support for RMF Version 3.3.0, which is required for
Sep 1, 1985 3090 processors. See DOCVER03 for more details:
TYPE7072 Service unit per second constant (SU_SEC) is now in
the TYPE72 record.
TYPE71 Many new variables describing swapping between the new
extended storage and auxiliary storage, migration age
etc. Swap reasons count expanded to identify where the
various swaps are occurring.
TYPE74 Three new variable describe the components of device
pending time. Both overflow conditions (308x only)
now identified.
TYPE78CF Configuration data set now contains utilization data.
TYPE78CU New data set describes CUHDR queue length and rate.
TYPE78IO New data set describes IOP initiative queue stats.
Change 02.20 The calculation of ALOCTIME and LOADTIME in TYPE30_4
VMAC30 were corrected (as had been done in TYPE434) to add
Sep 1, 1985 a day if the job allocation/load time of day was less
than the initiate time of day.
Change 02.19 The _VAR70 ARRAY in processing type 70 records was
VMAC7072 replaced with direct assignment after a European
Sep 1, 1985 customer first noted a siginifcant increase in CPU
time of MXG TYPE70 when compared to the original
MG TYPE70, and research confirmed the ARRAY was
more CPU costly than direct assignments.
Change 02.18 New format, MG078CV. converts byte values to Kilo
FORMATS or Mega bytes, with K or M suffix. Makes the data
Sep 1, 1985 in TYPE78VS (virtual storage) easily read.
Thanks to Joe Faska, Chemical Bank, USA.
Change 02.18A New data set created by RMF 3.3 for extended storage.
TYPE22_9
Change 02.17 The value of SPINCNT, which sets the number of
IMACSPIN executions that BUILDPDB will wait for a job's purge
Aug 30, 1985 record, was externalized to IMACSPIN, consistent
with moving all installation-unique values to IMAC's.
Change 02.16 The routine worked when all input was SMF, but use
ANALDSET with the PDB as input for the Step records failed
Aug 30, 1985 because of a missing RENAME.
Thanks to ???, ???.
Change 02.15 This module to process VS1 SMF records is an 'extra'
XTYPEVS1 module, undocumented and with unlabeled variables
Aug 15, 1985 but it also would not run. Removal of an unnecessary
%INCLUDE and proper calculation of NUMDD now makes it
usable for VS1 data.
Thanks to Fritz Ederer, SAS Institute, GERMANY.
and a German VS1 site.
Change 02.14 Step 3 of JCLTEST was broken into two steps, because
JCLTEST the SAS limit of 32768 SYSIN card images was exceeded.
OTHRPRNT TYPETEST/TYPEPRNT now operate on SMF records, while
OTHRTEST OTHRTEST/OTHRPRNT operate on non-SMF records. Member
PRINTING PRINTING was deleted.
TYPEPRNT
TYPETEST
Jun 30, 1985
Thanks to Joe Faska, Chemical Bank, USA.
Change 02.13 Two new exits were created (for 370 or XA) to set the
IMACPUSU value of SU_SEC (CPU Factor, or the Machine Dependent
IMACPUXA Constant) when a new model CPU which is not in the
VMAC7072 table in VMAC7072 is installed. Under MVS/370, it is
Jun 30, 1985 used to separate different CPU versions.
Change 02.12 Support for Release 4.3 of the TSO/MON Product. Eight
VMACTSOM new variables: ATMAXUTM, NETDLYTM, PANELCNT, SRMTRANS,
Jun 30, 1985 TPUTHOLD, TSMSMTHK, and TSMSNMTK were added; and the
value of USRTHKTM was corrected.
Change 02.11 Added new ROSCOE monitor command AMS and protected for
VMACROSC future new command names.
Jun 30, 1985
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 02.10 Variables RESPAVG and RESPSTD, average and standard
VMAC7072 deviation of response time per ended transaction were
Jun 30, 1985 added and SSQELAP was re-formatted and corrected. For
period 1 TSO transactions, RESPAVG is the trivial TSO
response time measurement used by IBM.
Thanks to Tom Incorvia, Macy's California, USA.
Change 02.9 LABELS were enhanced to reflect that many variables
RMFINTRV are rates per second. Labels for variables ending with
Jun 30, 1985 SWAP, TRAN, EXCP, IOTM, ACTV, RESD, and SERV now have
"per second" in their label.
Change 02.8 The test IF MCTSSDRL - COL GE 60 THEN ... should have
IMACICDL been IF MCTSSDRL - (COL-SEGSTRT) GE 60 THEN ... All
Jun 30, 1985 DL/I variables now have non-missing values.
Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
and others.
Change 02.7 Macro _CICOTHR is defined in IMACCICS and used in the
ANALCICS other members to control the ddname to which the data
BUILDPDB sets CICSACCT, CICSEXCE, and CICSYSTM are written.
BUILDPD3 This is for consistency with the _CICTRAN macro which
IMACCICS controls for the ddname of the CICSTRAN data set.
VMAC110
Jun 30, 1985
Thanks to Tom Hanson, Bradford Exchange, USA.
and others.
Change 02.6 Support for the new restructured type 6 record from
TYPE6 both JES2 and JES3. See WSCF-8518 for the complete
FORMATS list of PTFs which create this new record. New 3820
Jun 30, 1985 printer creates new variables.
Thanks to Craig Feistner, CITICORP, USA.
Thanks to Sam Sheinfeld, Kraft General Foods, USA.
Change 02.5 Support for the NLDM Release 3, which contains both
TYPE39 variables and corrections, and more subtypes tested.
FORMATS (Minor change was also made on Sep 3 for MXG 3B).
Jun 30, 1985
Thanks to Mike Healey, Celenese, USA.
Change 02.4 Support for the DISOSS Accounting Log Records.
TYPEDISO
FORMATS
May 30, 1985
Change 02.3 The default record ID numbers for TSO/MON records were
IMACTSOM interchanged. This caused a STOPOVER Abend when the
Apr 23, 1985 TSO/MON data was read.
a. All occurrences of 199 and 0C7 are replaced with 200 and 0C8. The
original occurrences of 200 and 0C8 are replaced with 199 and 0C7.
Thanks to John Lemkelde, Pennsylvania Blue Shield, USA.
Change 02.2 Model 204 records cause STOPOVER ABEND. The MXG test
VMACM204 site had modified the SMF record format, and MXG was
Apr 23, 1985 expecting the modified record format.
Thanks to Mark Hoff, American President Lines, USA.
Change 02.1A Errors in processing IFCID and ASID segments of the
VMACDB2 type 100 subtype 0 (MXG dataset DB2STAT0) were fixed.
Apr 23, 1985
a. The Address space CPU variables QWSAEJST and QWSASRBT captured
only the first address space TCB and SRB times. These variables
are replaced by QWS1EJST, QWS1SRBT, QWS2EJST, and QWS2SRBT, and
QWSAPROC is replaced by QWS1PROC and QWS2PROC to provide the
task name which produced the corresponding CPU time. All four
CPU variables are summed into the new variable CPUTM.
b. There are multiple IFCID sections. The original nine variables,
QWSCIID, QWSCISEC, QWSCSRSW, QWSCSRNW, QWSCSRND, QWSCRBNA,
QWSCSCF, QWSCOTH1, and QWSCOTH2 are expanded into three sets of
variables, with QWSC replaced by QWS1, QWS2, and QWS3 for the
same suffixed variables for the three IFCID sections.
c. Variables QSSTCONT, QSSTCRIT, and QSSTABND are totally invalid
until the PTF UP59374 for APAR PP42547 is installed.
d. Removed unnecessary variables from LENGTH 8 statement.
Change 02.1A Errors in processing IFCID and ASID segments of the
VMACDB2 type 100 subtype 0 (MXG dataset DB2STAT0) were fixed.
Apr 23, 1985 Formerly "Nits & Bits" with no change number:
ANALCICS TAMP corrected to TEMP in label
ANALVM All references to VMSESS were corrected to VMSESSN.
MONTHBLD Syntax error in first PUT corrected.
VMACCIMS Label for SYSTEM made consistent.
VMAC6 Label for NODE is now NJE NODE NUMBER
VMAC10 Format HEX2. applied to LCU, for consistency.
VMAC1415 Label spelling LIMIE corrected to LIMIT.
VMAC30 Format TIME12.2 applied to ALOCTM, DSENQTM, IOTM3420,
VMAC74 IOTM3480 and RDRTM for consistency.
VMAC80 Format HEX2. applied to LCHAN for consistency.
UTILGETM Added test to ensure NRSET is greater than zero.
Added selection for type 22 record subtypes.
LASTCHANGE: Version 2
=========================member=CHANGE02================================
/* COPYRIGHT (C) 1985 BY MERRILL CONSULTANTS DALLAS TEXAS */
This WAS the member CHANGES with Version 2. It is here for historical
purposes. Current changes are always in member CHANGES.
When Version 2 shipped, member CHANGES contained the following:
MXG Software Status as of March 24, 1985:
This is MXG Version 2.
This member describes the changes made to the MXG software since
Version 1. The documentation of those changes is in member DOCVER02.
I. NEW MEMBERS OF MXG.SOURCLIB IN VERSION 2.
ANALCONT PROC CONTENTs and PROC PRINT which were formerly a part of
BUILDPDB were moved to streamline JCLPDB, since some users
did not need these PROCs executed in their production PDB.
ANALDB2 Routine which processes the raw DB2 data sets built by MXG
module VMACDB2 into the PDB, and converts the accumulated
counters in the raw records into actual useable values.
DOCINCLD Documentation which cross references all included modules,
idenfitying which module includes which.
DOCVER02 Documentation of the new variables in existing data sets
and the contents of data sets which are new in Version 2.
ESCHANGE Documentation of the changes made during the Early Ship
Program of the MXG product, kept here for SMF archivists.
EX...... A part of the MXG EXIT facility, there are 115 new members
which begin with EX......, one corresponding to each of the
MXG data sets.. All OUTPUT statements in MXG code have been
replaced by %INCLUDE SOURCLIB(EX......); so that you can
make user modifications to the contents of the MXG data
external to the MXG code. Once your modifications are made,
future versions of MXG can be installed without any review
of your local modifications. The exits are transparent to
you until you choose to use them.
IMACFILE A part of the MXG EXIT facility which is taken after each
SMF record has been identified. In this exit, bad records
can be deleted (perhaps to correct a STOPOVER condition),
or the exit can be used to select SMF records to be sent
to an OS file for processing by other programs.
IMACICDL Supports processing of the optional DL/1 counters in the
CICS type 110 transaction record.
IMACINTV Member IMACINTV was blank in Version 1. It determines if
observations will be created in data set TYPE30_V and it is
self documenting.
Thanks to Patricia McKenzie, B.C. Systems, CANADA.
IMACKEEP A part of the MXG EXIT facility which will override any
of the _VAR.... definitions, providing for easy tailoring
of the KEEP= list to locally determine which variables are
kept in the MXG data sets. Even the data set name can be
altered through this exit.
IMACM204 Defines the SMF Record Id of MODEL 204 record to MXG.
IMACPUSU Used only under MVS/370 to set CPU speed factor (SU_SEC).
This allows installation to override the table of SU_SEC
under 370 (which does not provide the CPU Version) if you
have different versions of the same CPU.
IMACPUXA Used only under MVS/XA to set CPU speed factor (SU_SEC).
This should be needed only if you install a brand new CPU
before the next Version of MXG is shipped.
IMACROSC Defines the SMF Record Id of ROSCOE record to MXG.
MONBLD Members WEEKBLD MONBLD described in text did not exist.
WEEKBLD These members were printed in Chapter 35 (although not
specifically identified) and are now included in MXG. Both
are used in creating the weekly and monthly PDB data sets.
Thanks to Patricia McKenzie, B.C. Systems, CANADA.
TYPEDB2 Process the type 100 and 101 SMF records created by IBM's
VMACDB2 DATABASE TWO, or DB2 product.
TYPEM204 Process the SMF records written by Computer Corporation
VMACM204 of America's MODEL 204 product.
TYPEROSC New Member TYPEROSC and VMACROSC process the SMF records
TYPEROSJ written by ROSCOE. Member TYPEROSJ processes the ROSCOE
VMACROSC records written to a journal file.
TYPE39 Process the SMF records written by NLDM, which gathers
VMAC39 the hardware monitor response time counters collected in
the 3274 control unit.
TYPE128 Supports IBM's Network Performance Monitor (NPM) Type 128
VMAC128 record, which allows tracking of VTAM Session Connect time.
The type 128 record was previously created by IMB's FDB
VTAMPARS, which was merged with the NPA FDP to form NPM.
Thanks to Edgar Ortiz, Citicorp Denver, USA.
UDOCHECK A debugging utility which will read a SAS source program or
SYSOUT listing to locate un-matched DO-END pairs. You will
probably never need it, but it can save hours if you do.
II. CHANGES TO MXG.SOURCLIB WHICH HAVE BEEN MADE:
NEXTCHANGE: Version 1
Change 01.41 Macro added to name the DD of the CICSYSTM, CICSEXCE,
ANALCICS and CICSACCT data sets for consistency with JCLTEST.
Mar 29, 1985
Change 01.40 Member TYPE80 and VMAC80 now process most of the info in
TYPE80 the type 80 record written by RACF.
Mar 25, 1985
Change 01.39 Support for the optional DL/1 activity counters in the
VMAC110 type 110 record was added. MXG module IMACICDL must be
Mar 25, 1985 enabled to create the seventeen new variables.
Thanks to Louis Eliscu, Continental Insurance Company, USA.
Change 01.38 This change documents many minor changes.
DOC a. VMACEXC2, VMAC434, VMAC40. SUBTYPE was added to the
Mar 25, 1985 INVALID DEVICE message for identification of which
type 30 subtype was involved. Since SUBTYPE doesn't
exist in 4,34 or 40's, SUBTYPE is set to 434 or 40
before calling VMACEXCP from those modules.
b. TYPE38. Label NPARBC was corrected from PIU to BYTE
count, and other label spellings were corrected.
c. JCLTEST. The JOB card was removed and the SMFOUT DD
card was corrected.
d. IMACCHAN. The comments which described the example
now describe the example.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Thanks to David Stern, 1st Atlanta, USA.
Change 01.37 CICS monitor facility data now contains a negative value
VMAC110 for the dictionary records for MCTSSDRL, which should be
Feb 15, 1985 the length of the data segment. IBM states that this value
signifies a variable length segment. This caused a message
"Invalid type 110 record" because MCTSSDRL was used to
check for invalid length records (which has occurred if
CICS PTF's have not been installed). This check for valid
length now disregards MCTSSDRL if this is a dictionary
record (MCTSSDID=0).
Thanks to Malcolm Morgan, Wachovia Bank, USA.
Thanks to Bill Gibson, SAS Australia for seeing it first.
Change 01.36 Decoding of density was in error; true value of 6250 was
VMAC1415 decoded as 1600. Test was corrected.
Feb 15, 1985
Thanks to David Henley, HEALTHNET, USA.
Change 01.35 VSPC creates two type 44 records; only one format was
VMAC43PC recognized by MXG with the other producing a STOPOVER
Feb 15, 1985 condition. Fix eliminates STOPOVER for the VSPC type 44
record written for alter/define.
Thanks to Ron Greve, South Dakota State University, USA.
Change 01.34 This module, used in JCLTEST to select 10 SMF records of
UTILGETM each type, was expanded to select record ID's of 0 to 255.
Feb 15, 1985
Change 01.33 PRTY was corrected, and three new variables added.
VMAC26J2 a. The FLOOR function on PRTY divided by 16 gave the value
Feb 15, 1985 of priority as an integer, but JES2 ages by adding 1 to
the right nybble until it overflows. Thus priority is
not an integer when ageing is used. The FLOOR function
was removed.
b. The INROUTE, PRROUTE and PUROUTE fields contain their
associated node number, but it was thrown away in MXG.
They are now decoded into variables INNODE, PRNODE, and
PUNODE.
Thanks to Gary Zolweg, National Semiconductor, USA.
Change 01.32 Support for TSO/MON release 4.2 was added. in addition
VMACTSOM to several new variables in the previous two datasets,
Feb 15, 1985 a new data set, TSOMCMND records each command name in
each user segment (either full command name or tso/mon
command abbreviation). this permits analysis of actual
commands issued by individuals.
a. Data set TSOMCMND is created by outputting each command
type segment in each user segment in each system record.
This permits identification of what commands users use.
The data set is optional, and the default is zero obs.
b. TSOMSYST data set enhanced with MINSMCI, OVRMAXCN,
OVERMAXTM, SMDRPCNT, TERMNAME, TERMTYPE, USRTHKTM
variables.
c. TSOMCALL data set enhanced with COMNDTYP, TERMNAME, and
TERMTYPE variables.
d. Formats $MGTSOCD and $MGTSOTE added to FORMATS.
Thanks to Milt Weinberger, Information Services International, USA.
Change 01.31 Support added for IMS 1.3 records written by Control/IMS,
VMACCIMS IMS Measurement Facility, a Boole and Babbage Product.
Feb 14, 1985 See MXG NEWSLETTER for a discussion of technical changes.
a. Exits added (EXIMFPGM, EXIMFTRN, EXIMFDBD).
b. Additional formats were added to FORMATS (note that this
requires users to re-execute step one of JCLTEST to load
these new formats in MXG.SASLIB).
c. IMACCIMS was corrected and better documented.
Change 01.30 Two occurrences of '1to' were changed to '1 to', VMAC76.
Nits ABEND value of CANCEXIT is only 7 characters, CANCEXI,
Feb 14, 1985 in VMAC30
Change 01.29 Changes introduced in the updates SMF manual were added.
VMAC26J3 Variables SPOOLREC, ESTBYTE, ACTBYTE, ESTPAGE, and ACTPAGE
Feb 11, 1984 now exist.
Change 01.28 Changes introduced in the updated SMF manual (now -2) are
VMAC6 added. MVS/370 variable DATAERR now exists in MVS/XA. For
Feb 14, 1985 JES3, variables FONT, OVLY, and PAGE are created.
Change 01.27 Many enhancements were made:
BUILDPDB a. Exits added: EXPDB... where ... is VAR, CDE, OUT, JOB
BUILDPD3 STP, and PRT. See Exit discussion in MXG NEWSLETTER.
Feb 15, 1985 b. Data sets TYPE78VS, TYPE78SP, and TYPE78PA were added to
the PDB, and then dropped from WORK.
c. Data sets TYPE21, TYPE78CF, CICSACCT, CICSEXCE, and
CICSYST are deleted from WORK.
d. ABEND values JCL, CRSH, and NOTP, discussed on p.335
were added to PDB.JOBS
e. ZDATE was added to all PDB data sets.
f. PERFGRP is finally correct in PDB.JOBS and PDB.STEPS.
g. PROC CONTENTS and PRINT which were at the end of the
module were moved to member ANALCONT, which was also
added to SYSIN concatenation in JCLPDB.
h. LENGTH statements were added to force a length of 4
for variables created by PROC MEANS. This will save
disk storage space required by the PDB data.
i. Second READTIME in BY list merging TYPE26Jx SPIN26
was removed.
j. TYPRUN was added to PDB.JOBS for JES2.
Change 01.26 Variables BATCHMAX, STCMAX, and TSOMAX are now created;
RMFINTRV temporary data sets RMFCOMMN, RMF78D0, and R78HOUR are now
Feb 14, 1985 deleted.
Thanks to ???, SAS Australia.
Change 01.25 Data sets TYPE78PA and TYPE78SP (virtual stor monitoring
VMAC78 of specific jobs) were coded but not tested, due to lack of
Feb 14, 1985 specific records. Several coding problems were corrected:
a. LENPASS and NRPASS were read in reverse order.
b. OFFPASS was being decremented incorrectly (in a loop!).
c. Average values are RB4. vice PIB4.
d. Loop added around divide by NRPASAMP to avoid division
by zero error message.
e. For tasks with no sub pool data, the beginning offset to
the subpool data is non-zero. MXG now checks the ending
offset for non-zero before reading!
f. SMFTIME, STARTIME, and SYSTEM added to TYPE78PA and
TYPE78SP to permit matching of observations.
g. Format added for duration variables ending in 6 or 8,
variables in TYPE78PA, and length=8 specified for time
stamp variables previously overlooked.
Data set TYPE78CF was incorrect. Essentially only the data
for the first LCU was valid due to incorrect calculation
of the offset.
Thanks to Joe Faska, Chemical Bank, USA.
Change 01.24 The reference to this member in the book should have been
JCLDBANL to ANALDSET. Comment added in JCLDBANL to that effect.
Feb 14, 1985
Change 01.23 Version 5 of SAS will not permit multiple variables with
ANALBNCH the same name, as was done frequently with PROC MEANS and
ANALDOS an OUTPUT statement with variable name X repeated and then
ANALMPL dropped with a single DROP=X operand. All occurrences of
BUILDPDB this syntax were changed to create unique variable names
BUILDPD3 (eg., X1-Xn), which are then dropped.
RMFINTRV
Feb 14, 1985
Change 01.22 DOWNTM calculation now made only if the previous record
VMAC0 was from the same system, and the result is non-negative.
Feb 14, 1985 The variable is also formatted TIME12.2.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 01.21 TYPETASK value for JES3 now consistent with JES2 values.
VMAC30 JES2 JOBID begins with JOB, TSU or STC but JES3 JOBID
Feb 14, 1985 has JOB, JOBI, or JOB0. The SUBSYS field was used to
correctly identify the type of task for JES3.
Thanks to Don Hardman, National Advanced Semiconductor, USA.
Change 01.20 CPU support for 4381's (I, II, and the mp-III) added, as
VMAC7072 was support for the Performance Improvement Feature (an
Feb 14, 1985 Engineering Change) speed-ups for the 308x processors. The
PIF EC makes the 308x processors almost as fast as the new
"X" series processors. These factors were tabulated in MXG
NEWSLETTER I.3. Additionally, the CPU factors for the 3081
K and G machines (all versions) were corrected for the case
in which only one CPU was online.
Change 01.19 Include for IMACJBCK the Job Check Exitg to select only
VMAC16 certain Jobnames, Readtime, etc., was added.
Feb 14, 1985
Change 01.18 To support new 3480 tape drive, EXCP and IOTM variables
VMACEXC2 were added. EXCPTAPE and IOTMTAPE continue to contain the
VMAC30 total EXCP count and IOTM connect seconds for tape devices.
VMAC40 In addition, variables EXCP3420, EXCP3480, IOTM3420, and
VMAC434 IOTM3480 provide subtotals by actual device type to aid in
Oct 11, 1984 measuring migration.
Change 01.17 Device type for 3420 and 3480 tape drives is now decoded
VMACUCB into values '3420' or '3480' replacing value of 'TAPE'.
Feb 14, 1985 This affects only TYPE1415 variable DEVICE.
Change 01.16 Comments were corrected. This undocumented eXtra module
XTEACH shows how to used SAS to interact with a person at a TSO
Feb 14, 1985 terminal (in this case, to teach arithmetic).
Change 01.15 Added variable TASKCPTM to CICSYSTM data set. See MXG
VMAC110 NEWSLETTER for a discussion of CPU measures in CICS
Feb 14, 1985 monitoring facility data.
Change 01.14 Cross reference utility was cleaned up, reports were
UTILXREF re-ordered, and the reports titled.
Feb 14, 1985
Change 01.13 Enhancements to support Version Two
VMACSMF a. END=ENDOFSMF added to INFILE statement. This can be used
Feb 14, 1985 to check for the end of the SMF file in user exits.
b. Corrected error in Change 1.8. The end of file mark in
the VSAM SMF data is either :'SMF EOF' or :'SMFEOF'.
c. ZDATE variable (zee date zee data was processed by zee
MXG code) created and formatted. ZDATE was also added
to the KEEP list for all MXG data sets. ZDATE is used
to define the date of an observation, as discussed in
Chapter Thirty-Five, in building weekly and monthly PDB.
d. IMACFILE include added to allow selection of SMF records
to an OS file during MXG processing. See comments in the
member for further uses (like deleting bad SMF records).
e. PREVTIME, which contains the time stamp of the previous
SMF record, is no longer updated for type 2 or 3 records
because their timestamp is always out of sequence. This
will improve the accuracy of DOWNTM in TYPE0 data set.
f. SYSTEM changes to $CHAR4. vice $4 (because it is faster
and more accurate) and an INFORMAT added (to prevent an
obscure potential error).
Change 01.12 Device VIO and MSS not properly decoded.
VMACUCB
Oct 11, 1984 a. In lines 14 and 16, replace IF with ELSE IF.
Thanks to Sun Mei DeGrange, Shared Medical Systems, USA.
Change 01.11 Average working set size variables (...WKST) are wrong.
RMFINTRV a. In lines 240, 253, 271, 2, 84, and 297, change
Oct 11, 1984 IF MSOCOEFF GT 0 THEN ...WKST=4*MSOUNITS/(MSOCOEFF*50);
to read:
IF MSOCOEFF GT 0 THEN ...WKST=200*MSOUNITS/(MSOCOEFF*SSEC);
Thanks to Leo Zimmerman, DuPont, USA.
Change 01.10 DEVNR altered incorrectly for VIO, MSS in MVS/370.
IMACCHAN a. Change line 31 from
NEWSLTRS IF NOT MVSXA THEN DO:
Oct 3, 1984 to read:
IF NOT MVSXA AND DEVICE NE 'VIO ' AND DEVICE NE 'MSS ' THEN DO;
b. In NEWSLETTER I.3, the four blanks were not printed,
which caused DEVICE name in TYPE1415 to be truncated.
Thanks to Sun Mei DeGrange, Shared Medical Systems, USA.
Change 01.9 PCTTRIV is uninitialized in the RMFINTRV data set.
RMFINTRV
Sep 26, 1984 a. insert new line after line 497:
IF TSOTRAN GT 0 THEN PCTTRIV=100*TRIVTRAN/TSOTRAN;
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 01.8 End of file mark in the VSAM SMF file was changed by IBM
VMACSMF to be SMFEOFMARK as expected.
Sep 26, 1984 -Change line 39 to test for SMFEOFM instead of SMFEOF.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 01.7 CPU Type 3081-D under MVS/XA produced MXG error message.
VMAC7072 The CPU version number value in the code was misspelled.
Sep 25, 1984 -Change line 863 to test for CPUVERSN=03 instead of the
test for CPUVERSN=02 to set the SSEC value of 276.3.
Thanks to Ron Hensley, State of Alaska, USA.
Change 01.6 VMAC110 data sets built from a CICS Journal file (instead
VMACSMF of from SMF) contain invalid SYSTEM value.
Sep 25, 1984 a. Change @4+OFFSMF SYSTEM to @11+OFFSMF SYSTEM in line
570.
Thanks to Howard Winestock, Florida Light & Power, USA.
Change 01.5 Variable VIRTREAL should not exist in TYPE35 data set;
VMAC30 it has meaning only in the step records in TYPE34.
Sep 25, 1984 -Remove variable VIRTREAL from line 111 (which is part
of the KEEP list for data set TYPE35).
-Remove line 514, which is the label for VIRTREAL in the
TYPE35 label statement.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 01.4 Average Device Service time not calculated for MVS/370.
VMAC74 a. Insert new line after line 144:
Sep 25, 1984 AVGRSPMS=10*DURATM*DEVBUSY/SIO74CNT;
b. On page 740, variable AVGRSPMS description, replace the
MVS/XA note with: This is the average device service time
per SIO.
Thanks to David Henley, Healthnet, USA.
Change 01.3 TSO/MON Variable CPUTM was never defined.
VMACTSOM
Sep 25, 1984 a. Insert new line after line 322:
CPUTM=CPUTCBTM+CPUSRBTM;
Thanks to Shirley Linde, Mitre at NASA, USA.
Change 01.2 Control/IMS has been renamed by Boole and Babbage to the
VMACCIMS IMS Performance Reporter. Several variables were wrong.
Sep 25, 1984 a. Offsets for the time part of ARRVTIME are in error.
Lines 202-204 now read: Must be changed to read:
@79+OFFIMS HR PK1. @81+OFFIMS HR PK1.
@80+OFFIMS MIN PK1. @82+OFFIMS MIN PK1.
@81+OFFIMS SEC PD2.1 @83+OFFIMS SEC PD2.1
b. CPUCDLTM incorrectly set to missing some times.
Change line 256 from IF CPUMOPTM=0 THEN CPUCDLTM=.; to
IF CPUMOPTM=0 THEN CPUMOPTM=.;
Thanks to Shirley Linde, Mitre at NASA, USA.
Change 01.1 Reference to member JCLDBANL on page 815 is now deleted,
ANALDSET as the JCL for data set analysis is in the member ANALDSET.
JCLDBANL The following changes must be made to member ANALDSET:
Sep 25, 1984 a. After SYSIN DD for Step STEPSMF, in the BY statement,
change SORTTIME to INITTIME.
b. After SYSIN DD for Step STEPPDB, in the PROC SORT
statement, change SORTSTEP.STEPS to SORTSTEP.SORTSTEP.
c. After SYSIN DD for Step COMBINE, in the SET statement,
change SORTSTEP.STEPS to SORTSTEP.SORTSTEP.
Thanks to Henry Staffi, Carborundum, USA.
LASTCHANGE: Version 1
III. TYPOGRAPHIC CORRECTIONS TO MXG CODE CONTAINED IN VERSION 2.
ANALBNCH - Replace IN in line 3300 with MIN.
CLSTIMER - Replace EIGHTEEN in line 500 with TWENTY.
JCLUXREF - Replace STEP2 in line 300 with STEP1.
UTILPRAL - Replace 3200 in line 1100 with 3400.
UTILXREF - Replace DDDNAME in line 3400 with DDNAME.
UTILXREF - Insert ) in line 4100 before BY.
UTILXREF - Replace PDB in lines 2200 & 2300 with DATABAS1.
VMAC30 - Replace LITTERAL in line 79100 with LITERAL.
IV. CUMULATIVE 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 refering to JCLDBANL.
****END OF CHANGES. MXG VERSION 2***********
=========================member=CHANGE01================================
/* COPYRIGHT (C) 1985 BY MERRILL CONSULTANTS dallas texas */
This member contains the complete set of changes made during the
Early Shipment Program (November 1983 to August 1984). It is kept
only for historical purposes. All of these changes were made before
the MXG production software was shipped, starting in August, 1984.
/* COPYRIGHT (C) 1984 BY SAS INSTITUTE Inc, CARY N.C. AND
BY MERRILL CONSULTANTS, DALLAS, TEXAS */
MXG Software Status as of August 9, 1984:
No Temporary Changes have been made to this source library.
No Support Subscription Updates have been issued.
This is the MXG production software.
This member will contain the change status (i.e., last change number)
when the library was shipped to you. It will be updated (by complete
replacement) when you receive MXG Support Subscription Updates (SSU)
from Merrill Consultants, 10717 Cromwell Drive, Dallas Tx 75229,
214-351-1966. Between SSU's, fixes will be provided as "Temporary
Changes" in printed form. You should update this member after you
install any temporary changes.
EARLY SHIPMENT CHANGES
Listed below are all of the changes were applied to the early shipment
software (Nov 1, 1983 to Aug 15, 1984). These changes have already been
made to this library, but are included here for information.
Change 00.50 PERFGRP was removed from keep list for macro _PDB30_1.
BUILDPDB For Started Tasks and TSO Users, the value of PERFGRP
BUILDPD3 in the subtype 1 type 30 record is zero, which caused
Aug 8, 1984 PERFGRP in STEPS data set to be wrong if the step was
TYPETASK=STC or TSU and a subtype 1 record was found.
This is a circumvention, until the value of PERFGRP in
the subtype 1 (Job Init) is corrected by IBM.
Thanks to Georg Simon, Prudential, USA.
Change 00.49 Advised that variable RECORDS can have a negative value.
VMAC64 Altered the input format from PIB to IB to handle these
Aug 6, 1984 potential negative values, but have not yet determined
the intrepretation of these negative values.
Thanks to Geoff Neal, Health Insurance Comm., AUSTRALIA
Change 00.48 Created member to process CICS Monitor Facility records
TYPE110J which were written to a journal file, as described in
Aug 6, 1984 the Chapter on CICS.
Thanks to Debby Blackey, Fidelity Savings, USA.
Change 00.47 Corrected spelling errors and inconsistencies in labels
DOC which the super proofreaders at SAS found in reading the
Aug 6, 1984 text at the galley stage.
Thanks to ???, SAS proofreaders, USA.
Change 00.46 Corrected spelling errors in comments in describing the
BUILDPDB SPIN logic and added a comment line where default number
Aug 6, 1984 of days to spin is set.
Thanks to Patricia McKenzie, B.C. Systems, CANADA.
Change 00.45 Test to define DEVICE variable expanded to include JES3
VMAC6 printers (which have PRTnnnnn format for OUTDEVCE value.
Aug 6, 1984
Thanks to Paul Walker, IBM, USA.
Change 00.44 CPU busy is now zeroed and CPUWAITM set to the duration
VMAC7072 of the interval if either the CPU was offline at the end
Aug 6, 1984 of interval, or for an interval during which the CPU was
varied on or off line. Early shipment code only tested
for offline at end of interval.
Thanks to Patricia McKenzie, B.C. Systems, CANADA.
Change 00.43 A nit. IMACUCB in the comments was changed to VMACUCB.
VMACUCB Even nits require a change, and thus are documented here.
Aug 6, 1984 Thanks for my primary nitpicker!
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 00.42 The page fault rate variables (SYSPFR for system areas,
VMAC71 and LCLPFR for local area) were slightly in error. SYSPFR
Aug 6, 1984 included LPAGINS twice (because PVTCAIN already includes
LPAGINS), which caused LCLPFR to be smaller by a LPAGINS.
Variables PFRATE and PAGING are replicated as variables
PTR and DPR for report program compatability. PFRATE and
PAGING existed before MVS/SE1 introduced PTR and DPR as
"Happy Value" SRM measures. Note there is a significant
change in TYPE71 in MXG when compared with the original
MG code. In MXG the paging variables are now calculated
as rates per second, whereas the original code variables
contained total pages during the RMF interval. You will
have to check report programs which use TYPE71 data and
will likely need to modify your SAS program.
Thanks to Wayne Lauck, Central Data Processing, USA.
Change 00.41 The variable names starting with LOG.... were changed to
ANALNPA begin with NPA.... to agree with the names in TYPE38.
Aug 6, 1984
Change 00.40 Format for timestamps in subtype 1 and 2 records was not
VMAC90 correct in SMF manual; documentation APAR OZ81250 will be
Aug 6, 1984 issued by IBM to correct the manual. MXG was corrected to
decode fields as data actually exists. Structure of code
was altered to prevent possible errors when no active SMF
data set is given in a type 90 record, and variable BITS
was assigned format $HEX64.
Thanks to Paul Walker, IBM, USA.
Change 00.39 Variable IPLTIME, with length 8, was added to the LENGTH
VMAC0 statement. Timestamp variable must be length 8 to prevent
May 31, 1984 loss of minutes and seconds of precision.
Thanks to Paul Walker, IBM, USA.
Change 00.38 The error handling of CICS CMF records introduced in ES23
VMAC110 creates *ERROR.VMAC110.1 for all dictionary entries. The
May 28, 1984 dictionary entry is identifiable by the value of zero for
variable MCTSSDID in the second line after the "SECTION
HEADER DESCRIPTOR." The error message has no effect on
the data, but is eliminated by changing the test for this
error message from
OR SECTLLBB LT TEMPBYTE
to
OR (SECTLLBB LT TEMPBYTE AND MCTSSDID NE 0)
Additionally, CICS 1.6.1 has some initial data values in
error which cause IRESPTM, the internal response time, to
be very negative. Variable WTTCIOCN is 65535 and WTTCIOTM
is completely invalid. In all cases observed so far, the
value of TASERRFG was non zero for these values, and thus
the calculation of IRESPTM is now only calculated as:
IF TASERRFG EQ 0 THEN IRESPTM=ELAPSTM-WTTCIOTM;
There may in fact be PTFs which have not been applied at
my CICS 1.6.1 test site which cause these data values. It
is still wise to calculate the response only when it is
valid to do so!
Change 00.37 TWO NEW VALUES WERE ADDED TO THE MG110ER FORMAT, DUE TO
FORMATS new error flag values appearing in CICS 1.6.1:
May 28, 1984 00X=' '
50X='50X:INVALID CLOCK AND INTERNAL ERROR'
OTHER='OTHER ERROR'
Change 00.36 VARIABLE ALLOCATN IS REPLACED BY THREE ONE-BYTE VARIABLES
VMAC25 describing how this allocation was made: ALOCBYDD ('Y' by
May 25, 1984 DD, 'N' for dynamic), ALOCATLG ('Y' if Catalog used, 'N'
if not), and ALOCAUTO ('Y' if automatic, 'N' if manual).
Thanks to Paul Walker, IBM, USA.
Change 00.35 STATEMENT SWAPRATE=SWAPRATE*INVTIME; WAS REPEATED IN BOTH
VMAC71 the MVS/370 and MVS/XA segments. The second occurrence was
May 25, 1984 deleted in both segments.
Thanks to Jim Trenkle, Safeway, USA.
Change 00.34 VARIABLE TYPETASK UNDER JES3 CONTAINS A ZERO RATHER THAN
VMAC26J3 blank for the fourth position. A blank is now forced into
May 25, 1984 the fourth position. It was not shortened to three-bytes
to maintain consistency with TYPETASK in other data sets.
Thanks to Jim Trenkle, Safeway, USA.
Change 00.33 WORKLOAD VARIABLES WHICH WERE INCORRECTLY CALCULATED WERE
RMFINTRV corrected as described in NEWSLETTER Volume I Number Two.
May 25, 1984
Change 00.32 VARIABLE JOBID WAS REMOVED FROM KEEP LIST. IT HAD BEEN
VMAC26J3 replaced by variables TYPETASK and JESNR and should never
May 20, 1984 have appeared in the KEEP statement.
Thanks to Paul Walker, IBM, USA.
Change 00.31 NEW MODULE, FOR TYPE 110 CICS RECORD WHICH SETS THE SIZE
IMACICUS of the USERCHAR variable in CICSTRAN. If you want account
May 20, 1984 data on CICS transactions, you must use the optional user
character field. Default is for a one-byte field. See the
discussion in the member, and more in Newsletter #2.
Change 00.30 NEW MODULE, FOR JES3. IT BUILDS THE PDB JUST AS BUILDPDB
BUILDPD3 for JES2, but this module also gets the account fields in
May 20, 1984 TYPE26J3 and uses them if there was no type 30 record for
the job (as happens with JCL error).
Change 00.29 CLEANUP CHANGE. EXCP AND IOTM FIELDS ADDED TO KEEP LIST
ANALRMFI for TYPE30_5. LABEL statement was too long for ONLINE in
VMAC30 TYPE73 and TYPE78, and for AVGDSOPN in TYPE74. One title
VMAC73 was incorrect in ANALRMFI.
VMAC74
VMAC78
May 20, 1984
Change 00.28 CORRECTED VALUE FOR MG090CM FORMAT (TYPE90 DATA SET) TO
FORMATS 6:SWITCH SMF.
May 10, 1984
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 00.27 FOR IPL PROMPT, THE OPERATOR CAN REPLY WITH THE DURATION
VMAC90 of the outage, or "U". MXG raised "invalid function call"
May 10, 1984 error if "U" was response. Code now checks for "U" before
attempting to convert string to duration. Also changed
TOD to EVENTIME for several events so that time of event
would actually be kept.
Thanks to Paul Walker, IBM, USA.
Change 00.26 VARIABLE SMF49L CORRECTED TO SMF49LN IN THREE PLACES TO
VMAC4789 correct error. JES3 Type 48 records for SNA were found to
May 10, 1984 be incorrectly documented in the SMF manual, resulting in
a STOPOVER Abend. After reaching Level II, the code was
fixed and a document APAR from IBM can be expected. At the
same time another of my errors was corrected.
Thanks to Paul Walker, IBM, USA.
Change 00.25 INVALID TYPE 30 RECORDS HAVE BEEN CREATED BY MVS WITH THE
VMAC30 'triplets' (the three values of offset, length, and number
Apr 26, 1984 of relocatable sections) overlaid with blanks. This caused
a STOPOVER abend when the blanks were read in as PIB4! The
offset value plus length of the relocatable section is now
compared with the LENGTH of the record, and the invalid
records will be printed in hex on the log.
Change 00.24 OCCASIONALLY, THE NUMBER OF SAMPLES NRSAMPLE WILL BE ZERO
VMAC7072 in a type 70 record. It appears this can happen if the
Apr 26, 1984 operator issues a Modify command at startup, although it
may be due to other phenomena. The records have a very
short duration, and have little other effect, but the
division by zero caused an abend. This change tests for
nonzero value of NRSAMPLE before division. Additionally,
the divisions by CPUCOEFF and SRBCOEFF are also now tested
for nonzero for CPUTCBTM and CPUSRBTM in TYPE72 data set.
Finally, the error messages for a missing value of SU_SEC,
(the service units per CPU second) were cleaned up.
Thanks to Sue Rosansky, Metropolitan Life, USA.
Change 00.23 CHANGES TO SUPPORT CICS VERSION 1.6.1
VMAC110 Seven new variables in data set CICSTRAN:
Apr 25, 1984 MAXTASK Maxtask condition occurred?
PRIINCHR Primary input character count
PRIOUCHR Primary output character count
PROGSTOR Program storage used
SECINCHR Secondary input character count
SECOUCHR Secondary output character count
SHRTSTOR Short on storage condition occurred?
One new variable in data set CICSYSTM:
PROGCOMP Amount of storage deleted by CICS program
compression dynamically because system storage
was overloaded.
Much better detection of invalid segments. Prior error
handling deleted remainder of physical record when an
invalid header was encountered. Now, the invalid section
header is skipped, but subsequent valid sections are
processed.
Change 00.22 CHANGES TO SUPPORT MVS/SP VERSION 2 RELEASE 1.2:
VMAC434 REGREQST created from four byte field, replacing old
Apr 20, 1984 two byte field, PVTAREA:
PVTAREA - Now zero (see REGREQST)
REGREQST - REGION requested (from JCL)
VMAC6 Nine new variables to support 3800-3 printer are added:
Apr 20, 1984 DOCLENFT - Length of document printed, in feet.
FONTLOAD - Number of Fonts Loaded.
FONTUSED - Number of Fonts Used.
FORMDEFS - Number of FORMDEFs Used.
OVLYLOAD - Number of Overlays Loaded.
OVLYUSED - Number of Overlays Used.
PAGEDEFS - Number of PAGEDEFs Used.
PGSGLOAD - Number of Page Segments Loaded.
PGSGUSED - Number of Page Segments Used.
Additionally, FORM is now character length eight (it used
to be only four).
VMAC426J 2 OUTFORM is now eight bytes (increased from four).
Apr 20, 1984
VMAC30 Six overlooked variables and the new one added (REGREQST)
Apr 20, 1984 are added to data sets TYPE30_V, TYPE30_4, TYPE30_5 and
TYPE30_6:
LSQSZHI - LSQA+SWA Subpools above 16MB
LSQSZLOW - LSQA+SWA Subpools below 16MB
PVTSZHI - Private Area size above 16MB
PVTSZLOW - Private Area size below 16MB
USRSZHI - User sub pools above 16MB
USRSZLOW - User sub pools below 16MB
PVTAREA - Now zero (see REGREQST)
REGREQST - REGION requested (from JCL)
Change 00.21 IBM PTF WILL BE ISSUED TO CHANGE END OF FILE TEXT IN THE
VMACSMF VSAM SMF data from "SMF EOF MA" to "SMFEOFMARK". Test was
Apr 14, 1984 altered to support either string.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 00.20 TYPE 30 RECORD STOPOVER DUE TO INVALID EXCP SEGMENT
VMAC30 description. There should have been 251 22-byte segments,
Apr 14, 1984 but record was only 1800 butes. A new check was added to
verify the record length could be read before reading EXCP
data, and an error message put to the log, with dump of
record, if same type of invalid record is encountered.
The problem will be persued with IBM to uncover their
cause of the bad records. At same time, error messages in
VMACEXC2 were numbered and enhanced.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 00.19 OFFSET VALUE FOR THREE VARIABLES WAS WRONG FOR TYPE 77
VMAC77 MVS/XA segment.
Apr 12, 1984 Variable @was @change to
OFFEDSS 33 41
LENEDSS 37 45
NRSECT 39 47
Change 00.18 BUILDPDB FAILED AFTER CHANGE ES11 BECAUSE VARIABLES IN BY
BUILDPDB list were not in the _NULL_ data set (which replaced the
Apr 12, 1984 SPIN.SPINnn data sets due to OPTIONS NODSNFERR). Fix
required minor redesign of the interleave of today's and
yesterday's (i.e., SPIN) data sets. If you do not ever
use the SPIN data sets, a short fix is to precede OPTIONS
NODSNFERR statement with an /* and to follow the
subsequent OPTIONS DSNFERR statement with an */, which
comments out the interleave of TYPEnnnn and SPIN.SPINnnnn
data sets.
Thanks to Bob Warren, Wachovia Bank, USA.
Change 00.17 VARIABLE CPUCPTM WAS NOT IN KEEP LIST FOR VMSESSN.
TYPEVM
Apr 10, 1984
Change 00.16 DIVISION BY ZERO WHEN SRBCOEFF IS ZERO. CORRECTED BY TEST
VMAC7072 for zero before division.
Apr 10, 1984
Thanks to Bob Warren, Wachovia Bank, USA.
Change 00.15 CREATION OF CHARACTER VARIABLE TIME FROM STRTTIME RESULTS
ANALCICS in invalid sort sequence when month boundary was crossed.
Apr 1, 1984 Reconstructed as a DATETIME value.
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 00.14 CPU FACTORS FOR THE GX,KX,BX,EX, AND QX 308X PROCESSORS
VMAC7072 were added and comments added to the MVS/370 section Minor
Mar 31, 1984 corrections to some values, based on IBM publication TNL
GN28-0912 (Jan 31,1984) to GC28-1149-1 were also made.
Change 00.13 FORMATS FOR CONTROL/IMS ADDED TO MEMBER FORMATS.
FORMATS
Mar 31, 1984
Change 00.12 TYPETASK='TSO' CORRECTED TO TYPETASK='TSU'.
VMAC30
Mar 31, 1984
Thanks to Chuck Hopf, Computer Language Research (FASTAX), USA.
Change 00.11 IN INTERLEAVING TYPE30_1 AND SPIN.SPIN30_1, THE BY
BUILDPDB statement had JINTTIME misspelled as JINITIME. At the
Mar 31, 1984 same time, MACRO _SECOND and its percent sign were
replaced by OPTIONS NODSNFERR and OPTIONS DSNFERR as
described in Chapter 32.
Thanks to Steve Glick, NTSU, USA.
See Change ES18.
Change 00.10 MANY LABELS WERE RESPELLED (CORRECTLY THIS TIME), AND ALL
VMAC.all occurrences of the following labels were made consistent:
Mar 31, 1984 DATASET to DATA SET
TIMESTAMP to TIME STAMP
JOBNAME to JOB NAME
Thanks to ???, SAS proofreaders, USA.
Change 00.09 THE LENGTH VALUE USED TO READ IN THE SIGNON VARIABLE
VMAC4789 includes the two bytes of length itself, causing a
Mar 31, 1984 STOPOVER abend. Code restructured to subtract two from
length before executing the $VARYING60. INPUT statement.
Additionally, the offset @41 in ID=49 code was typographic
and should be @51.
Thanks to Allan Russell, SAS Institute Europe, GERMANY.
Change 00.08 RMV VERSION 3.2.1 CHANGED RMF VERSION FROM 2 BYTE EBCDIC
VMAC7072 to a 2 byte packed decimal. Now version can print as 321
VMAC73 whereas before it was limited to 32.
VMAC74
VMAC75
VMAC76
VMAC77
VMAC78
Feb 4, 1984
Change 00.07 SUPPORT FOR RMF VERSION 3 RELEASE 2 MODIFICATION LEVEL 1
VMAC78 installed. RMF 3.2 added TYPE78VS, TYPE78SP and TYPE78
Feb 4, 1984 data sets and 3.2.1 added support for 4381 processor
types. Only TYPE78VS data set has actually been
validated.
Change 00.06 IMPROVED ERROR HANDLING FOR INVALID RECORDS NOW PROVIDES
VMAC110 diagnostic messages and a dump of the type 110 record when
Feb 4, 1984 invalid data is encounterd. This will eliminate STOPOVER
abends in type 110.
Change 00.05 AVGWKSET VARIABLE REPLACED AVGMEMSZ WITH NEW DESCRIPTION
VMAC7072 and discussion in TYPE72 section of Chapter Forty.
Jan 15, 1984
Change 00.04 AVGWKSET LABELS WERE CORRECTED TO UNITS OF (K-BYTES) AND
VMAC30 the calculations made consistent in these data sets.
VMAC434
VMAC48PC
Jan 15, 1984
Change 00.03 REPEAT (LOGICALLY) CHANGE ES2 FOR SIO74CNT, SSCHSAMP AND
VMAC74 IORATE.
Dec 23, 1983
Change 00.02 SEVERAL VARIABLES WERE NOT SET TO MISSING WHEN NRSTCPS,
VMAC73 the number of samples, was zero, and thus had the value of
Dec 23, 1983 value of the previous calculation.
Change 00.01 DELETE OBSERVATION FROM SET PDB.TYPE72 WHEN IT WAS FROM A
RMFINTRV report performance group. To correctly calculate overhead
Dec 23, 1983 CPU time, the sum of only the control performance groups
is used.
END OF Early Shipment Changes, December 23, 1983.