COPYRIGHT (C) 1984-2010 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 28.04
/* COPYRIGHT (C) 1984-2010 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 28.04 is 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/ship_current_version
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 28.04 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.04.
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.04 dated Jul 5, 2010, thru Change 28.152.
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 Subtpe 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, $MGDDDDD 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 Storage Tek 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.04 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. 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.
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) 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 both V9.1.3 and V9.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 WPS Support Statement.
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*
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 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 28.04.
1. Incompatibilities introduced in MXG 28.04:
a- Changes in MXG architecture made between 28.04 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 28.04 after MXG 27.27:
Dataset/
Member Change Description
ANALDB2R 28.004 Extreme Detail DB2 Trace Report PMTRC01 revised.
ANALDB2R 28.146 Major enhancement to DB2PM-like reporting.
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.
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.
BLDSMPDB 28.125 Support for Week/Month if first-day-of-week NOT MON.
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.
CONFIGVx 28.128 ERROR APPARENT MACRO TRIM NOT RESOVED: DOCUMENTATION.
EXIT112 28.027* Do NOT assemble EXIT112 for SMF 110/112, use EXITCICS
FIXTRNCD 28.049 TRANSCODE attribute can be added to old PDBs
FORMATS 28.082 UDDDDDD, $MGDDDDD and $MGDDDSN updated.
IMACICMR 28.032 Protect 200-byte CMRDATA on CICS/TS 3.2 (s/b 256).
MXGSAS92 28.070 SAS 9.2 TS2M2 DSNAMES may have changed
READDB2 28.083 READDB2/ANALDB2R did not honor MACDB2H/MACKEEP.
SMFRECNT 28.089 BUILDPDBs PDB.SMFRECNT now has bytes and counts.
TYPE0 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 fixed.
TYPE102 28.116 Support for SMF 102 IFCID 263 decodes unique fields.
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.
TYPE113 28.075 John Burg formulas for TYPE113 HIS data are added.
TYPE113 28.140 Major revision to SMF 113 support, TYPE70PR vars add.
TYPE120 28.038 SMF 120 SUBTYPE 9 INPUT STATEMENT EXCEEDED RECORD
TYPE120 28.133 Support for WebSphere SMF 120 Subtype 20, untested.
TYPE30 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71.
TYPE42 28.072 TYPE42X4 Above the BAR LRU dataset variables wrong.
TYPE7072 28.099 Variable CPULHKTM, CPU TIME Lock Promoted, TYPE72GO.
TYPE74 28.039 R7451RID now one byte, R7451FLG/TYPE74CA overlays.
TYPE80A 28.107 TOKDANAM LDAPHOST,BINDDN,BINDPW,APPLNAM,UTYPE,JPNUM.
TYPE84 28.077 Support for all JES3 JMF TYPE84 subtypes.
TYPE89 28.015 Support for z/TPM SMF 89 record, subtype wrong byte.
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.
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.
TYPEEDGR 28.029 RMM datetime vars have always been wrong time zone.
TYPEIMFS 28.137 Support for BMC IMF records written in SMF format.
TYPEIMS 28.131 IMS Log 56X record subtype 15x INVALID DATA/STOPOVER.
TYPEIMS7 28.066 Support for IMS Version 11 (INCOMPATIBLE).
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.
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.
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 Storage Tek VSM Version 6.2 and 7.0.
TYPESTC 28.005 Support for Sun StorageTek Version 6.2 and 7.0
TYPESVIE 28.138 Support for SysView Subtpe 3 records.
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.
TYPEVMXA 28.025 MXG CPU Loop in TYPEVMXA, new CEX3C PRCAPMCT=9 crypto
TYPEWPMO 28.086 Support for Windows Performance Monitor PERFMON file.
TYPEZTPF 28.043* zTPF has major revisions in Performance Data
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.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE:
====== 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
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 -Correction to PDB.DB2STATS interval logic.
TRNDDBAA
VGETOBS -Number of SORTBY= variables for PMACC02 increased to 12.
VMACDB2 -Reports now as close to current as V7 DB2PM documents.
VMACDB2H -Future maintenance greatly simplified.
VMXGDBAA
VMXGDBSS -All summarization of accounting data now performed by
Jul 4, 2010 new VMXGDBAA internal macro, used in ANALDB2R and in
ASUMDBAA, TRNDDBAA.
-FIXDB2A will report from old ASUMDB2A/TRNDDB2A datasets
as close as possible to the new architecture, but many
new fields will be missing.
-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
changes 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 uneeded, now, resummarization.
-The four sets of Buffer Pool variables QBnCxxx in DB2ACCT
DB2ACCTP and DB2STATS are redefined and contents changed.
QB1Cxxx variables contain the 4K Buffer Size counters,
QB2Cxxx variables contain the 8K Buffer Size counters,
QB3Cxxx variables contain the 16K Buffer Size counters
and QB4Cxxx variables now contain 32K Buffer counters.
Originally, the four sets of counters were for BP0, BP1,
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.
-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 algorithem 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.
Thanks to Chuck Hopf, Independent Consultant, USA.
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 Reserved Change Number.
Jul 4, 2010
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 a CP that 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
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 Örjan, 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 Reserved Change.
Jul 4, 2010
Change 28.128 ERROR: APPARENT INVOCATION OF MACRO TRIM NOT RESOLVED
CONFIGV8 There are several "opportunities" for this error:
Jun 9, 2010 -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.
-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.
-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 it's 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
Jun 7, 2010 by pushing the daily top 10 back thru ANALRANK. Using
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.
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
VMXGINIT
May 31, 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 Manger 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 ID 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 convertered 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 had been added to TYPE30_1, and 'pseudo' duplicates
had different ASIDs and thus were not duplicates.
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 Exernal Subsystems but 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 statments that
defined or referenced the XXXX product suffix, the DDDDDD
dataset suffix token, or that contained the DATASET name.
Programatically 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 Glen 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 elimiminated 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 Glen 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 Mike 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 chagned 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, GERMANY.
Thanks to Sieghart Seith, FIDUCIA, 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 it's 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 ommission 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.
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 Mike 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 useing %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
EXTPFMU 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* CA-1 (TMS) adds extensions to TMC Volume & DSNB records.
VMACTMS5 -The Retention Record Extension adds 36 bytes to the TMC
Mar 5, 2010 Volume and DSNB records created by CA-1 utility programs
TMSCLEAN, TMSCYCLE, TMSEXPDT, TMSCTLG, length 376.
-The VMRECORD Extension adds 56 bytes to the TMC Volume
Record created by utility program TMSVMVLT, length 396.
-On z/OS, the new LRECL will be handled automatically but
on ASCII, you will need to provide the explicit LRECL of
these fixed length records.
-This is ONLY an ALERT that there is new data; MXG support
won't exist until a customer who has enabled these new
data extensions sends test records for validation.
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 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
VMXGVMXA 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
VMXGxxxx 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
Thanks 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, UCH, 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
GRAFxxxx to a terrible choice that produces unreadable patterns.
Feb 6, 2010 Investigating alternatives.
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 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 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 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.
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'
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.