COPYRIGHT (C) 1984-2010 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 28.01
MXG Version 28.01 is 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.01 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 28.01.
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.01 dated Mar 9, 2010, thru Change 28.047.
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.01 executes best with SAS V9.2, or with SAS V9.1.3 with
Service Pack 4, on any supported SAS platform.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS Decompression Infile Exit.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2 nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level B" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. PLEASE INSTALL V9.2 ASAP,
FOR BOTH OF US, TO AVOID FIXED PROBLEMS. MXG Software has not
executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
one of those listed SAS versions, but any of those data libraries
can be read or updated by any of those versions.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
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) is required
to be completely safe. No earlier Version 8's were supported.
BUT, PLEASE INSTALL V9.x ASAP, FOR BOTH OF US. V8.2 IS ARCHAIC.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG QA tests have executed on z/OS with SAS V9.1.3 and V9.2 and
also both V9.1.3 and V9.2 on Windows XP.
(I can no longer run QA tests with "archaic" SAS Version 8.2.)
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.4 requires MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for 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 Mar 06, 2007 26.01
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
AS400 4.4.0 Sep 27, 1999 17.07
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1+) 16.04
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
V. Incompatibilities and Installation of MXG 28.01.
1. Incompatibilities introduced in MXG 28.01:
a- Changes in MXG architecture made between 28.01 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.01 after MXG 27.27:
Dataset/
Member Change Description
ASUMTAPE 28.008 SPIN.SPINSYSL dataset could grow forever.
TYPESTC 28.005 Support for Sun Storage Tek VSM Version 6.2 and 7.0.
ANALDB2R 28.004 Extreme Detail DB2 Trace Report PMTRC01 revised.
TYPEZTPF 28.043* zTPF has major revisions in Performance Data
TYPENTSM 28.042 New Sentry VM 3.1.4.3 adds VMWARE objects/metrics.
ASMTAPEE 28.041 Do NOT use ASMTAPEE ML-45/46, CPU SPIKE: ML-47 fixed.
EXIT112 28.027* Do NOT assemble EXIT112 for SMF 110/112, use EXITCICS
TYPETMS 28.040* CA-1 Retention and VMRECORD extensions, need data.
TYPE74 28.039 R7451RID now one byte, R7451FLG/TYPE74CA overlays.
TYPE120 28.038 SMF 120 SUBTYPE 9 INPUT STATEMENT EXCEEDED RECORD
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).
TYPE30 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71.
TYPEEDGR 28.029 RMM datetime vars have always been wrong time zone.
TYPECIMS 28.028 BMC IMF INPUT STATEMENT EXCEEDED, short record.
TYPEVMXA 28.025 MXG CPU Loop in TYPEVMXA, new CEX3C PRCAPMCT=9 crypto
VMXGINIT 28.023 MXGERROR/USER ABEND 990 if NOWORKINIT is enabled.
ANALZPCR 28.021 Major fixes/enhancements for complex zPCR models.
TYPE89 28.015 Support for z/TPM SMF 89 record, subtype wrong byte.
VGETDDS 28.014 Colon in DDNAMES= worked only with DDNAMES=PDB:)
VMXGFIND 28.012 Kewl tool, find all obs in all datasets meeting test.
TYPEDB2 28.010 Variable SHIFT (from QWHSSTCK, END) kept in datasets.
TYPE0 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 fixed.
ASUMTAPE 28.008 Large size SPIN.SPINMOUN,SPIN.SPINSYSL found, shrunk.
TYPESTC 28.005 Support for Sun StorageTek Version 6.2 and 7.0
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE:
====== 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 cause 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.)
Thanks to Atle Mjelde, ErgoGroup, NORWAY.
Change 28.043* zTPF has major revisions in Performance Data, with many
TYPEZTPF old variables removed and new record types; while the new
Mar 5, 2010 support is in new members TYPEZTPF/TYPSZTPF/VMACZTPF and
not an updated TYPETPF, old DATASET and VARIABLE names
that exist are unchanged, and TPF is still the prefix for
the new dataset names.
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.
Until we fix EXIT112, you can use the IBM DFHMOLS program
to decompress the 112 Omegamon records.
-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.
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 their models 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);
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.