COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 24.24
MXG 24.24 is the 2007 "Annual Version", dated February 5, 2007.
MXG Version 24.24 is dated Feb 5, 2007, thru Change 24.306
MXG Version 24.11 was dated Feb 3, 2007, thru Change 24.304
Fourth MXG Version 24.10 was dated Jan 31, 2007, thru Change 24.300
Third MXG Version 24.10 was dated Jan 28, 2007, thru Change 24.293
Second MXG Version 24.10 was dated Jan 22, 2007, thru Change 24.282
First MXG Version 24.10 was dated Jan 21, 2007, thru Change 24.279
MXG Version 24.09 was dated Dec 20, 2006, thru Change 24.251
MXG Version 24.08 was dated Oct 18, 2006, thru Change 24.216
First MXG Version 24.08 was dated Oct 17, 2006, thru Change 24.214
MXG Version 24.07 was dated Sep 22, 2006, thru Change 24.186
First MXG Version 24.07 was dated Sep 21, 2006, thru Change 24.185
MXG Version 24.06 was dated Aug 30, 2006, thru Change 24.165
MXG Version 24.05 was dated Jul 3, 2006, thru Change 24.120
MXG Version 24.04 was dated Jun 22, 2006, thru Change 24.109
MXG Version 24.03 was dated May 15, 2006, thru Change 24.075
First MXG Version 24.03 was dated May 13, 2006, thru Change 24.073
Second MXG Version 24.02 was dated Apr 26, 2006, thru Change 24.057
First MXG Version 24.02 was dated Apr 24, 2006, thru Change 24.050
MXG Version 24.01 was dated Mar 1, 2006, thru Change 24.012
MXG Newsletter FORTY-EIGHT was dated Feb 20, 20056
The instructions for ftp download of MXG 24.24 was mailed to all sites.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. 2007 Annual MXG Software Version 24.24 instructions were sent.
II. Incompatibilities and Installation of MXG 24.24.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Version 24.24, dated Feb 5, 2007 - the Annual Version for 2007.
Major enhancements added in MXG 24.24.
TYPENMON 24.296 Support for NMON (free from IBM) AIX/Linus Monitor.
TYPE1415 24.295 Support for APAR OA17569 Tape Encryption new fields
TYPE112 24.294 Support for SMF ID=112 CICS ONDV record.
TYPESFTA 24.303 Support for Tivoli License Compliance Manger 4.2
TYPERMFV 24.302 Support for additional zIIP data in RMF III ZRBENC.
TYPEEDGR 24.299 Support for z/OS (COMPATIBLE) changes to RMM data.
TYPE1415 24.295 Support for APAR OA17569, Encrypted Tape Keys/Mech.
TYPEWMQA 24.292 Support for WebSphere MQ V6.0 OPEN SYSTEMS acct/stats
TYPE119 24.289 Support for FTP Client Security fields in TYP11903.
IMACICO2 24.297 Support for CMODHEAD=OMEGAMON segment.
TYPEBBMQ 24.281 Support for BMC Mainview for MQ Series VSAM History.
TYPESAMS 24.279 Support for SAMS Vantage Version 6; new datasets.
TYPE116 24.203 Support for NETSNAME/UOWTIME from QWHCNID in SMF 116.
TYPETAND 24.286 Support for Tandem H06 release.
TYPETPF 24.283 Support for TPF thru PUT19.
ANALS225 24.282 New "DB2 Storage Analysis" uses IFCID 225+DB2STATS.
TYPE7072 24.290 Circumvention for invalid CPURCTTM in 72 and 30s.
IMACICOM 24.287 BMC CANMQ CICSTRAN MQTOTTM invalid due to MXG error.
TYPE102 24.291 Correction for SMF 102 IFCID 22.
TYPEBVIR 24.305 Support for IBM BVIR History for TS7700 VTS System.
BLDSMPDB 24.298 New BUILDPDB=COPYONLY option enhancement.
IMACICO2 24.297 Support for new CMODHEAD='OMEGAMON' CICS segment.
Major enhancements added in MXG 24.10.
ASUMTAPE 24.265 Critical correction for ASUMTAPE for IBM Volume Exit
UTILEXCL 24.254 Support for all Omegamon/Candle optional CICS data
TYPERMFV 24.272 Support for RMF III VSAM ENC Extension segment.
TYPEMVCI 24.264 Support for CMRDETL for Mainview for CICS V 5.9.00.
TYPEBETA 24.257 Support for Beta 93 Version 3.6.1
ADOC30 24.269 Schematic documentation of zIIP CPU variables.
VMXGSUM 24.267 New MINLONG=,MAXLONG= arguments created for 8-byters.
TYPEPROS 24.258 Product section character variables were wrong.
TYPE102 24.256 IFCID 226 and 227 new variables added.
TYPEIPAC 24.259 Mobius Subtype 8 INPUT STATEMENT EXCEEDED.
ASCISMFC 24.274 ASCII execution utility to create SMF subset from ftp
VMXG70PR 24.278 More ASUM70PR touch-up, dedicated CPUs, etc.
ANALCISH 24.277 Updated for dropped variableS MNGSYSER/MNGSYSEE.
Major enhancements added in MXG 24.09.
TYPE74 24.228 Support for HyperPAV APAR OA12865.
TYPE78 24.228 Support for HyperPAV APAR OA12865.
IMACEXD 24.221 Support for SAR/EXD SMF type 6 optional data.
TYPENTSM 24.218 Support for NTSM Beta Version 3.0.0.8 (COMPATIBLE).
TYPENSPY 24.212 Support for NetSpy Version 11 was added Aug, 2005.
TYPE99 24.210 Support for SMF 99 Resource Group, TYPE99RG dataset.
ASUMDB2G 24.244 New PDB.ASUMDB2G summary for DB2 Global Buffers.
VMXGINIT 24.242 Revisions for SAS V9 BI SAS/ITRM anticipated changes.
IMAC6ESS 24.227 Optional ESS GPARMKEY='4A'x caused INPUT error.
TYPE70 24.225 LPARs with no current weight has LPARSHAR=0.
TYPE7072 24.224 Fall Clock "Set Back" protection for dupe STARTIME.
TYPE78 24.223 Virtual Storage Above the Bar Shared not Input.
TYPE110 24.222 Stat vars DSGEJST,DSGSRBT now kept in CICDS.
TYPENTSM 24.220 NTSMF Object 'DATABASE ==> INSTANCES" new DATABASI.
TYPE119 24.215 Vars TSICDUTM thru TSICOUAR were incorrect in MXG.
ASMRMFV 24.214 Protection for z/OS 1.6 which had no SPG records.
TYPE7072 24.208 LPAR SHARE variables were wrong with Dedicated CPs.
MXGSASVn 24.246 REGION=0M added to MXG JCL procedure examples.
Major enhancements added in MXG 24.08.
CRITICAL: Final corrections to "SPLIT70" redesign in Change 24.207.
All SPLIT70 errors in MXG 23.23 thru MXG 24.07 have been corrected.
MXG 24.08 is required for z/OS 1.7 now because of these corrections.
MXG 23.23 thru MXG 24.07 should be replaced by MXG 24.08 or later.
TYPETPMX 24.199 Support for ThruPut Manger Version 6 new variables.
TYPENTSM 24.206 Support for NTSMF Version 3.0.0.7.
TYPEMPLX 24.204 Support for IMPLEX Version 4.10 (INCOMPATIBLE).
TYPEMWNT 24.191 Support for HP MeasureWare for Windows/NT.
TYPETNG 24.188 Support for new TNG object (NT and Solaris).
TYPETHAL 24.201 Support for E-Thales Security five user SMF records.
TYPE82 24.200 Support for SMF 82 subtype 22, correction to st 21.
VMACSMF 24.202 &SMFEXIT macro variable added to INFILE &SMF.
TYPE30 24.198 INTETIME in TYPE30_6 was wrong if GMT offset nonzero.
TYPE1415 24.196 TYPE1415 INPUT EXCEEDED with z/OS 1.7/1.8 PDSE data.
TYPEDB2 24.194 DB2STATS variables CPUTM, QWSnXXXX corrected.
Many 24.193 Support for 3592 Tapes, no change, they're 3590s.
ASUM70PR 24.187 INTERVAL=HOUR could create obs with smaller DURATM.
Major enhancements added in MXG 24.07.
ASMHSCEX 24.092 Support for z/OS 1.8 (COMPATIBLE).
ASMHSCEX 24.171 Support for CrossCopy in MXGTMNT HSC Exit.
TYPERMFV 24.181 Support for RMF III OPGG3, SPGG3, zips in CPUG3.
TYPE70 24.184 PCTIFBYn/PCTZIBYn are "MVS", new PCTCIBYn is "LPAR".
TYPERACF 24.178 Support for IRRHFSU (Unix z/OS file permissions).
VMACNDM 24.182 NDMCPUTM and NDMCPU now validated and correct.
TYPE1415 24.170 MXG 24.06 only. NO MATCHING IF error.
TYPEDB2 24.177 INPUT EXCEDED ID=100 SUBTYPE=0 more than 1 QLST.
TYPE110 24.166 Support for BMC Mainview/CICS optional DB2 and CMR.
VMAC110 24.185 Support for DMF Product's SMF 110 (CICS 4.1!) data.
Major enhancements added in MXG 24.06.
TYPENTSM 24.162 Support for NTSMF 3.0.0, also 35 new objects.
TYPEQACS 24.161 Support for i/Series QACS AS/400 Release 5.4.0.
TYPECMHM 24.153 Support for EMC's Centera Mainframe HSM Migrator SMF.
TYPEPRPR 24.145 Support for Oce's Prisma Print '9901' USER record.
TYPENDM 24.144 Support for NDM/Connect-Direct Release 4.3/4.5.
TYPE72GO 24.125 New ZIP variables were not kept in TYPE72GO.
BUILDPDB 24.128 New ZIP variables are now kept in PDB.STEPS/JOBS.
TYPE70 24.142 PCTRDYWT, new SMF70Qnn wrong, new PCTRDQWT created.
FORMATS 24.163 Support for z9EC on 32-bit; no change for 64-bit.
TYPEDB2 24.141 QLESxxxx DB2 statistics variables corrected.
ANALDEVN 24.157 Example to identify all devices allocated by a JOB.
CICSBAD 24.155 Not all PROGRAM='########' should be in CICSBAD?
TYPE80A 24.152 Protection for $VARYINGnn. mm input with nn GT mm.
VMXG70PR 24.124 Variables SHIFT, ZDATE, ZTIME in ASUM70LP fixed.
UTILEXCL 24.140 Support for ARZGEOS/FACHG, ARGZD/GSACCT optionals.
TYPEDB2 24.136 Support for DB2 V8 UIFCIDS=YES ASCII test.
ANALDB2R 24.138 Incorrect Plan counts, DB2PARTY='R" were summed.
TYPEXAM 24.135 MTRSYS variables were wrong after SYSTMID.
UTILEXCL 24.131 Candle short CICS dictionary record supported.
TYPEORAC 24.130 Oracle support is no longer subsystem dependent.
ASUMUOW 24.129 PDB.ASUMUOW support for 10 CICS ABCODE values.
IMAC6ESS 24.127 Support for GEPARMKY='4D'x and '4A'x
TYPE102 24.121 Support for IFCID=350, replaces IFCID=63, long SQL.
Major enhancements added in MXG 24.05.
ASUM70PR default restored to INTERVAL=DURSET
RMFINTRV enhanced to support SYNC59
WEEKBLD/WEEKBLDT typos (only in 24.04) corrected.
Major enhancements added in MXG 24.04.
TYPE7072 24.110 Support for z9BC Processor (COMPAT if 64-bit z/OS)
TYPE30 24.046 Support for zIIP-ZIP engines.
TYPE7072 24.046 Support for zIIP-ZIP engines.
TYPEDB2 24.046 Support for zIIP-ZIP engines.
TYPERMFV 24.046 Support for zIIP-ZIP engines.
ASUM70PR 24.105 Corrections, revisions, ASUM70PR, ZIP and IFAs.
ASUM70PR 24.105 INTERVAL=QTRHOUR is new default for ASUM70PR/70LP.
TYPE1415 24.094 Support for PDSE Caching statistics APAR OA12857
ASUMTAPE 24.102 PDB.ASUMTAPE will have zero obs if SYSLMNT has 0 obs.
ASUMTAPE 24.102 PDB.ASUMTAPE BEGTMNT, ENDTMNT, TOTMNTTM created.
ASMHSCEX 24.096 Revised STK Exit UX01 adds logic to save registers.
ASMRMFV 24.091 RMF III enhancement, ENC data, Index usage.
TYPERMFV 24.090 RMF III RESOURCE TYPE MISMATCH corrected for UWDG3.
RMFINTRV 24.079 New NOTYPE74= option will skip TYPE74 processing.
TYPEVMXA 24.078 All z/VM MONWRITE datasets have variable SYSTEM.
VMXGDUR 24.105 New MXGDURTM variable is created.
Major enhancements added in MXG 24.03.
ASUM70PR 24.064 Redesign of ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP code.
Corrects errors, supports different DURATMs in CEC.
Extensive discussion of CEC metrics in change text.
This change is required if you use these datasets.
TYPE89 24.063 TYPE89/TYPE892 MACHTIME calculation revised.
ANALRMFR 24.060 RMF CPU Activity Report updated for IFAs and IFLs.
WEEKBLxx 24.058 SORT order of PDB.ASUMTAPE was inconsistent.
WEEKBLxx 24.064 New &MXGNOBY to circumvent NOT SORTED in WEEKBLD.
MONTHxxx 24.064 New &MXGNOBY to circumvent NOT SORTED in MONTHLD.
ASMTAPEE 24.075 ML-39 of MXGTMNT, gets suppressed SYSLOG messages.
Major enhancements added in MXG 24.02.
Two more IMPORTANT/CRITICAL corrections to the "SPLIT70" redesign:
TYPE7072 24.032 PCTCPUBY/PCTMVSBY in TYPE70 wrong when IRD active.
TYPE7072 24.043 PCTCPUBY/CPUACTTM missing in non-LPAR'd system.
Other, less critical enhancements:
TYPERMFV 24.042 Support for CPC RMF III report data.
TYPETIAO 24.045 Support for APAR UK12301 (Tivoli Alloc Optimizer)
TYPEDB2 24.028 Support for APAR PK15468, adds QWSnPSRB.
TYPE16 24.013 Support for New Memory Object Data in DFSORT.
TYPE102 24.027 SQL Text missing in AUDIT trace 140-145 IFCIDs.
TYPESYNC 24.025 8-byte variables replaced 4-byte variables.
E2dddddd 24.024 New E2dddddd members for "2 Phase" tailoring.
VMXGINIT 24.023 MXG Default APENGN is now V9SEQ.
MONTHBLD 24.022 ASUMDB2B BY list did not match weekly BY list.
TYPE80 24.018 RACF Reloate 301 section INPUT STATEMENT EXCEEDED.
TYPEDB2 24.044 BEGTIME missing in DB2STATB dataset.
TYPE30 24.053 Negative CPUUNITS error suppressed if delta is small.
Major enhancements added in MXG 24.01 - 2006 Annual MXG Version
TYPEVMXA 24.003 Toleration Support for z/VM 5.2 (INCOMPATIBLE).
TYPE102 24.001 Support for truncated SQL Text in DB2 Audit Trace.
TYPE30 24.005 Support for APAR OA14340, adds 8-byte EXCPTOTL field.
TYPE70 24.010 Array subscript out of range with 60 LPARs.
TYPE30 24.011 Negative/missing values in PDB.TYPE30_6.
TYPE30 24.009 Variable AVGWKSET/PAGESECS accumed over TCB+IFA.
TYPE102 24.001 INPUT EXCEEDED SMF 102 truncated SQL text fields.
TYPE70 24.010 Variable LPARNSW in RMFINTRV/TYPE70 could be zero.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements in MXG 22.08" in CHANGES, above, for the major
items, then search Newsletters for V9 for all of the minor items.
MXG executes under SAS V8.2 and SAS V9.1.3, but MXG is no longer
supported under SAS V6. The "PDB" libraries written to by MXG
must have been created by V8/V9 (i.e, if ENGINE=V6 is shown in the
PROC CONTENTS output, you must convert that data library to the
current ENGINE=BASE by PROC COPYing it under SAS V8 or V9.
For SAS V9.1.3 on z/OS with Service Pack 4:
There are no reported errors, and MXG's CONFIGV9 now specifies
V9SEQ instead of V6SEQ. As V6SEQ does not support long length
character variables, it should not be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are still SAS V9.1 or V9.1.2,
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) is required
to be completely safe. No earlier Version 8's were supported.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it is now the default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG New-Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on Windows XP with SAS V9.1.3. But previous QA tests
have been run with all SAS releases on z/OS, SAS V8.2 and V9.1 on
Linux RH8 on Intel, with V9.1 on Solaris v2.8 on Model V880, and
V9.1 on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V8.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
Availability dates for the IBM products and MXG version required for
the processing of that product's data records:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990 8.8
MVS/ESA 4.2 Mar 29, 1991 9.9
MVS/ESA 4.2.2 Aug 15, 1991 9.9
MVS/ESA 4.3 Mar 23, 1993 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30, 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28, 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28, 1997 15.02
OS/390 2.4.0 Sep 28, 1997 15.06
OS/390 2.5.0 Feb 24, 1998 15.06
OS/390 2.6.0 Sep 24, 1998 16.04
OS/390 2.7.0 Mar 26, 1999 16.09
OS/390 2.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 Sep 30, 2005 *24.24
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS ZIP Processor Support Jun 22, 2006 *24.24
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 ??? 15, 2006 24.??
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DB2 6.1.0 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DFSMS/MVS 1.1 Mar 13, 1993 11.11
DFSMS/MVS 1.2 Jun 24, 1994 12.02
DFSMS/MVS 1.3 Dec 29, 1995 13.09
DFSMS/MVS 1.4 Sep 28, 1997 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998 16.04
DFSMS/MVS 1.5 ??? ??, 1999 16.04
DFSORT SMF V1R5 Mar 1, 2006 24.02
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
MQ Series 2.1.0 Oct 2, 1999 17.07
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
NETVIEW 3.1 type 37 ??? ??, 1996 14.03
NPM 2.0 Dec 17, 1993 12.03
NPM 2.2 Aug 29, 1994 12.05
NPM 2.3 ??? ??, 1996 15.08
NPM 2.4 Nov 18, 1998 17.01
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
DOS/VSE POWER V6.3.0 Dec 19, 1998 16.08
VM/ESA 2.0 Dec 23, 1992 10.04
VM/ESA 2.1 Jun 27, 1993 12.02
VM/ESA 2.2 Nov 22, 1994 12.06
VM/ESA 2.3 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Dec ??, 2004? 22.08
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
AS400 4.4.0 Sep 27, 1999 17.07
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including cics/ts 3.1 22.08
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1+) 16.04
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 22.08
Memorex/Telex
LMS 3.1 12.12A
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
II. Incompatibilities and Installation of MXG 24.10.
1. Incompatibilities introduced in MXG 24.24 (since Annual MXG 24.01):
a- Changes in MXG architecture made between 24.24 and prior versions
that can introduce known incompatibilities.
ITRM Sites MAY have to add _STY70 invocation in their EXPDBOUT
exit member, but only if they run BUILDPDB without RMFINTRV.
See Change 23.321.
If you use MXG _VAR7072 and _CDE7072 in your own program to read
RMF 70s, you MUST now invoke _STY70 after your data step due
to MXG support for split SMF 70 records. Change 23.321.
If you used EXTY70 or EXTY70PR to create new variables, you must
now use the E2TY70 or E2TY70PR "Second Phase" exit members.
See Change 24.024.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
A change that alters any previously kept variable is
INCOMPATIBLE, and requires the new version to be used.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
_PAGE_ 8
Alphabetical list of important changes in MXG 24.10 after MXG 24.01:
Dataset/
Member Change Description
ANALDB2R 24.138 Incorrect Plan counts, DB2PARTY='R" were summed.
ANALDEVN 24.157 Example to identify all devices allocated by a JOB.
ANALRMFR 24.060 RMF CPU Activity Report updated for IFAs and IFLs.
ASMHSCEX 24.096 Revised STK Exit UX01 adds logic to save registers.
ASMHSCEX 24.171 Support for CrossCopy in MXGTMNT HSC Exit.
ASMRMFV 24.091 RMF III enhancement, ENC data, Index usage.
ASMRMFV 24.214 Protection for z/OS 1.6 which had no SPG records.
ASMTAPEE 24.075 ML-39 of MXGTMNT, gets suppressed SYSLOG messages.
ASUM70PR 24.064 Redesign of ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP code.
ASUM70PR 24.095 Variables LPCTBY LPCTOV PCTLPBY PCTLPOV missing.
ASUM70PR 24.105 INTERVAL=QTRHOUR is new default for ASUM70PR/70LP.
ASUM70PR 24.187 INTERVAL=HOUR could create obs with smaller DURATM.
ASUMDB2G 24.244 New PDB.ASUMDB2G summary for DB2 Global Buffers.
ASUMMIPS 24.080 _SYNC59 option added to MIPS/MSU analysis.
ASUMRAID 24.057 New RAID Analysis, all VOLSERs on each CSSSID.
ASUMTAPE 24.102 PDB.ASUMTAPE BEGTMNT, ENDTMNT, TOTMNTTM created.
ASUMTAPE 24.102 PDB.ASUMTAPE will have zero obs if SYSLMNT has 0 obs.
ASUMUOW 24.129 PDB.ASUMUOW support for 10 CICS ABCODE values.
BLDSMPDB 24.298 New BUILDPDB=COPYONLY option enhancement.
BUILDPDB 24.128 New ZIP variables are now kept in PDB.STEPS/JOBS.
CICSBAD 24.155 Not all PROGRAM='########' should be in CICSBAD?
CLRMFV 24.037 New version of CLRMFV TSO CLIST for RMF III.
Doc 24.015 Identifying CRYPTO users and usage.
Doc 24.034 Example to create numeric hex from character hex.
E2TY70 24.024 New E2TY70 member for tailoring PDB.TYPE70 dataset.
E2TY70PR 24.024 New E2TY70PR member for tailoring PDB.TYPE70PR.
E2dddddd 24.024 New E2dddddd members for "2 Phase" tailoring.
EXPDB30V 24.158 Doc: how to drop variables from PDB.SMFINTRV.
FORMATS 24.163 Support for z9EC on 32-bit; no change for 64-bit.
IMAC6ESS 24.127 Support for GEPARMKY='4D'x and '4A'x
IMAC6ESS 24.227 Optional ESS GPARMKEY='4A'x caused INPUT error.
IMACEXD 24.221 Support for SAR/EXD SMF type 6 optional data.
IMACICE2 24.033 Documentation of different EZA01 fields in CICS
IMACICO2 24.297 Support for CMODHEAD=OMEGAMON segment.
IMACICO2 24.297 Support for new CMODHEAD='OMEGAMON' CICS segment.
JCLMNTHW 24.039 Example creates MONTH PDB from last six WEEK PDBs.
MONTHBLD 24.022 ASUMDB2B BY list did not match weekly BY list.
MXGSASVn 24.246 REGION=0M added to MXG JCL procedure examples.
Many 24.193 Support for 3592 Tapes, no change, they're 3590s.
READDB2 24.006 APPARENT MACRO MAC102S error with ANALDB2R/READDB2.
RMFINTRV 24.079 New NOTYPE74= option will skip TYPE74 processing.
TYPE102 24.001 INPUT EXCEEDED SMF 102 truncated SQL text fields.
TYPE102 24.001 Support for truncated SQL Text in DB2 Audit Trace.
TYPE102 24.027 SQL Text missing in AUDIT trace 140-145 IFCIDs.
TYPE102 24.121 Support for IFCID=350, replaces IFCID=63, long SQL.
TYPE102 24.256 IFCID 226 and 227 new variables added.
TYPE110 24.166 Support for BMC Mainview/CICS optional DB2 and CMR.
TYPE110 24.222 Stat vars DSGEJST,DSGSRBT now kept in CICDS.
TYPE110J 24.104 BMC CMRDETL converted to SMF 110 DOS Journal Format.
TYPE112 24.294 Support for SMF ID=112 "ONDV" CICS record.
TYPE112 24.294 Support for SMF ID=112 CICS ONDV record.
TYPE116 24.203 Support for NETSNAME/UOWTIME from QWHCNID in SMF 116.
TYPE119 24.215 Vars TSICDUTM thru TSICOUAR were incorrect in MXG.
TYPE1415 24.094 Support for PDSE Caching statistics APAR OA12857
TYPE1415 24.170 MXG 24.06 only. NO MATCHING IF error.
TYPE1415 24.196 TYPE1415 INPUT EXCEEDED with z/OS 1.7/1.8 PDSE data.
TYPE1415 24.295 Support for APAR OA17569 Tape Encryption new fields
TYPE1415 24.295 Support for APAR OA17569, Encrypted Tape Keys/Mech.
TYPE16 24.013 Support for New Memory Object Data in DFSORT.
TYPE16 24.071 DFSORT MEMOBJUS variable corrected.
TYPE23 24.065 TYPE23 STARTIME/SYNCTIME were GMT, now LOCAL zone.
TYPE30 24.005 Support for APAR OA14340, adds 8-byte EXCPTOTL field.
TYPE30 24.009 Variable AVGWKSET/PAGESECS accumed over TCB+IFA.
TYPE30 24.011 Negative/missing values in PDB.TYPE30_6.
TYPE30 24.046 Support for zIIP-ZIP engines.
TYPE30 24.053 Negative CPUUNITS error suppressed if delta is small.
TYPE30 24.198 INTETIME in TYPE30_6 was wrong if GMT offset nonzero.
TYPE70 24.010 Array subscript out of range with 60 LPARs.
TYPE70 24.010 Variable LPARNSW in RMFINTRV/TYPE70 could be zero.
TYPE70 24.142 PCTRDYWT, new SMF70Qnn wrong, new PCTRDQWT created.
TYPE70 24.184 PCTIFBYn/PCTZIBYn are "MVS", new PCTCIBYn is "LPAR".
TYPE70 24.225 LPARs with no current weight has LPARSHAR=0.
TYPE7072 24.032 PCTCPUBY/PCTMVSBY in TYPE70 wrong when IRD active.
TYPE7072 24.043 PCTCPUBY/CPUACTTM missing in non-LPAR'd system.
TYPE7072 24.046 Support for zIIP-ZIP engines.
TYPE7072 24.208 LPAR SHARE variables were wrong with Dedicated CPs.
TYPE7072 24.224 Fall Clock "Set Back" protection for dupe STARTIME.
TYPE72GO 24.125 New ZIP variables were not kept in TYPE72GO.
TYPE74 24.228 Support for HyperPAV APAR OA12865.
TYPE78 24.223 Virtual Storage Above the Bar Shared not Input.
TYPE78 24.228 Support for HyperPAV APAR OA12865.
TYPE80 24.018 RACF Reloate 301 section INPUT STATEMENT EXCEEDED.
TYPE80A 24.097 INPUT EXCEEDED if more than six RACFTYPE=42 segments.
TYPE80A 24.098 Support for RACF DCE segment from RACFTYPE 301 seg.
TYPE80A 24.152 Protection for $VARYINGnn. mm input with nn GT mm.
TYPE82 24.200 Support for SMF 82 subtype 22, correction to st 21.
TYPE89 24.063 TYPE89/TYPE892 MACHTIME calculation revised.
TYPE99 24.210 Support for SMF 99 Resource Group, TYPE99RG dataset.
TYPEBETA 24.257 Support for Beta 93 Version 3.6.1
TYPEBVIR 24.305 Support for IBM BVIR History for TS7700 VTS System.
TYPECMHM 24.153 Support for EMC's Centera Mainframe HSM Migrator SMF.
TYPEDB2 24.028 Support for APAR PK15468, adds QWSnPSRB.
TYPEDB2 24.044 BEGTIME missing in DB2STATB dataset.
TYPEDB2 24.046 Support for zIIP-ZIP engines.
TYPEDB2 24.051 QISEDBW, QISEDSC, QISESTMT corrected, other QISEs.
TYPEDB2 24.088 Vars QJSTCIWR QJSTLOGW QJSTLSUS QJSTSERW/THRW wrong.
TYPEDB2 24.136 Support for DB2 V8 UIFCIDS=YES ASCII test.
TYPEDB2 24.141 QLESxxxx DB2 statistics variables corrected.
TYPEDB2 24.177 INPUT EXCEDED ID=100 SUBTYPE=0 more than 1 QLST.
TYPEDB2 24.194 DB2STATS variables CPUTM, QWSnXXXX corrected.
TYPEEDGR 24.299 Support for z/OS (COMPATIBLE) changes to RMM data.
TYPEHURN 24.150 HURN49 variables HU49BJOB,HU49BSET not kept.
TYPEIPAC 24.259 Mobius Subtype 8 INPUT STATEMENT EXCEEDED.
TYPEMPLX 24.204 Support for IMPLEX Version 4.10 (INCOMPATIBLE).
TYPEMVCI 24.264 Support for CMRDETL for Mainview for CICS V 5.9.00.
TYPEMWNT 24.191 Support for HP MeasureWare for Windows/NT.
TYPENDM 24.144 Support for NDM/Connect-Direct Release 4.3/4.5.
TYPENDM 24.160 Corrections (again, final?) for NDMCPUTM/NDMCPU.
TYPENMON 24.296 Support for NMON (free from IBM) AIX/Linus Monitor.
TYPENSPY 24.212 Support for NetSpy Version 11 was added Aug, 2005.
TYPENTSM 24.162 Support for NTSMF 3.0.0, also 35 new objects.
TYPENTSM 24.206 Support for NTSMF Version 3.0.0.7.
TYPENTSM 24.218 Support for NTSM Beta Version 3.0.0.8 (COMPATIBLE).
TYPENTSM 24.220 NTSMF Object 'DATABASE ==> INSTANCES" new DATABASI.
TYPEORAC 24.130 Oracle support is no longer subsystem dependent.
TYPEPROS 24.258 Product section character variables were wrong.
TYPEPRPR 24.145 Support for Oce's Prisma Print '9901' USER record.
TYPEQACS 24.161 Support for i/Series QACS AS/400 Release 5.4.0.
TYPERACF 24.178 Support for IRRHFSU (Unix z/OS file permissions).
TYPERMFV 24.042 Support for CPC RMF III report data.
TYPERMFV 24.046 Support for ZIIP-ZIP engines.
TYPERMFV 24.090 RMF III RESOURCE TYPE MISMATCH corrected for UWDG3.
TYPERMFV 24.181 Support for RMF III OPGG3, SPGG3, zips in CPUG3.
TYPERMFV 24.302 Support for additional zIIP data in RMF III ZRBENC.
TYPESFTA 24.303 Support for Tivoli License Compliance Manger 4.2
TYPESYNC 24.025 8-byte variables replaced 4-byte variables.
TYPESYSI 24.240 All times were 1000 times too large.
TYPETHAL 24.201 Support for E-Thales Security five user SMF records.
TYPETIAO 24.045 Support for APAR UK12301 (Tivoli Alloc Optimizer)
TYPETMS5 24.418 DATECLN was not converted to yyyyddd format.
TYPETNG 24.188 Support for new TNG object (NT and Solaris).
TYPETPMX 24.199 Support for ThruPut Manger Version 6 new variables.
TYPEVMXA 24.003 Toleration Support for z/VM 5.2 (INCOMPATIBLE).
TYPEVMXA 24.078 All z/VM MONWRITE datasets have variable SYSTEM.
TYPEXAM 24.035 XAM SYS error INPUT STATEMENT EXCEEDED due to FFFFx.
TYPEXAM 24.068 SHORT SEGMENT MXG error corrected for SYTCPC/STOSHR.
TYPEXAM 24.072 INVALID DATA FOR SYTNLPMG/SYTACTM with XAMSYS.
TYPEXAM 24.135 MTRSYS variables were wrong after SYSTMID.
UTILEXCL 24.131 Candle short CICS dictionary record supported.
UTILEXCL 24.140 Support for ARZGEOS/FACHG, ARGZD/GSACCT optionals.
UTILEXCL 24.254 Support for all Omegamon/Candle optional CICS data
VMAC110 24.185 Support for DMF Product's SMF 110 (CICS 4.1!) data.
VMACNDM 24.182 NDMCPUTM and NDMCPU now validated and correct.
VMACSMF 24.202 &SMFEXIT macro variable added to INFILE &SMF.
VMXG70PR 24.105 Corrections, revisions, ASUM70PR, ZIP and IFAs.
VMXG70PR 24.124 Variables SHIFT, ZDATE, ZTIME in ASUM70LP fixed.
VMXGDUR 24.105 New MXGDURTM variable is created.
VMXGINIT 24.023 MXG Default TAPENGN is now V9SEQ.
VMXGINIT 24.242 Revisions for SAS V9 BI SAS/ITRM anticipated changes.
WEEKBLxx 24.058 SORT order of PDB.ASUMTAPE was inconsistent.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 24.
====== Changes thru 24.306 were in MXG 24.24 dated Feb 5, 2007=========
Change 24.306 Support for IMS Version 10 (INCOMPAT) IMS log records,
VMACIMS which has these new data inserted in the 07 and 07 log
Feb 5, 2007 log records:
Dataset IMS07
DLRABRSN='ABEND*REASON*CODE'
DLRCPUID='CPU ID*PLACE*HOLDER'
DLRESAF ='ESAF*CALLS'
DLRFLD ='FASTPATH*FLD*CALLS'
DLRNWID ='NETWORK*IDETIFIER*OF LAST*MESSAGE'
DLROSAMR='OSAM*IO*READS'
DLROSAMW='OSAM*IO*WRITES'
DLRPOS ='FASTPATHP*POS*CALLS'
DLRRLSE ='RLSE*CALLS'
DLRTOTIO='TOTAL*DL/I*OSAM+VSAM*CALLS'
DLRVSAMR='VSAM*IO*READS'
DLRVSAMW='VSAM*IO*WRITES'
DLRXCOPY='COPY*CALLS*(XQUERY)'
DLRXRSTR='RSTR*CALLS*(XQUERY)'
DLRXSAVE='SAVE*CALLS*(XQUERY)'
Dataset IMS08
LINTCLAS='TRAN*CLASS'
LINTSY2 ='TRANCODE OR DBNAME'
LINTPGM ='PROGRAM*NAME'
LINTPSB ='PSB*NAME'
LINTFLG1='FLAG*1'
This change had not been tested with actual V10 records,
and there is a new 09 statistics record that will be
supported in the future, but this change protects the
TYPEIMS7 member that used VMACIMS.
Users of the ASMIMSLx/JCLIMSLx architecture will hav to
reassemble with the IMS 10 Macro Library.
Change 24.305 Support for IBM's BVIR History for TS7700 VTS System.
EXBVIR01 DDDDDD MXG MXG
EXBVIR02 DATASET DATASET DATASET
EXBVIR10 SUFFIX NAME LABEL
EXBVIR11
EXBVIR20 BVIR01 BVIR01 BVIR01: VNODE VIRTUAL DEVICE PIT
EXBVIR21 BVIR02 BVIR01 BVIR02: VNODE ADAPTER POINT IN TI
EXBVIR30 BVIR20 BVIR20 BVIR20: VNODE VIRTUAL DEVICE HIST
EXBVIR31 BVIR21 BVIR21 BVIR21: VNODE ADAPTER HISTORY
EXBVIR32 BVIR10 BVIR10 BVIR10: HNODE HSM POINT IN TIME
EXBVIR33 BVIR11 BVIR11 BVIR11: HNODE GRID POINT IN TIME
IMACBVIR BVIR30 BVIR30 BVIR30: HNODE HSM HISTORY
TYPEBVIR BVIR31 BVIR31 BVIR31: HNODE RESERVED
TYPSBVIR BVIR32 BVIR32 BVIR32: HNODE LIBRARY HISTORY
VMACBVIR BVIR33 BVIR33 BVIR33: HNODE GRID HISTORY
VMXGINIT IBM creates the data file as RECFM=U, without BDW or RDW,
Feb 4, 2007 so processing this data on ASCII may require the data to
be converted to VB, before download, using SAS on z/OS:
DATA _NULL_;
INFILE BVIRDATA RECFM=U BLKSIZE=32760;
FILE BVIRHIST RECFM=VB LRECL=32756 BLKSIZE=32760;
INPUT ; PUT _INFILE_; RUN;
Change 24.304 Support for IBM's TLCM 4.2 (formerly ISOGON's SoftAudit)
VMACSFTA which is now Tivoli License Compliance Manager for z/OS,
Feb 3, 2007 eliminates old tests for record length, which caused zero
observations to be created in SOFTMODS dataset, and adds
new variables:
Dataset SOFTPROD - Installed Products:
XPUPDEPR='DELETED*PRODUCT*INDICATOR'
XPUPFEAT='IBM*FEATURE*NUMBER'
XPUPPEEF='PRODUCT*ENABLEMENT*ELIGIBILITY*FLAG'
XPUPPRRL='PRODUCT*RELEASE'
Dataset SOFTMODS - Installed Load Modules:
XPMDELLI='DELETED*LIBRARY*INDICATOR'
XPMDELLM='DELETED*LOAD*MODULE*INDICATOR'
XPMDELPR='DELETED*PRODUCT*INDICATOR'
XPMPTHLN='LENGTH*OF FULL*PATHNAME*FOLLOWING'
XPMRECFM='RECORD*FORMAT*CODE'
XPMPTHNM='FULL*PATHNAME'
Dataset SOFTAUDM - Load Module Usage
XPUDELLM='DELETE*MODULE*INDICATOR'
XPUDELPR='DELETE*PRODUCT*INDICATOR'
XPUMLDEL='LIBRARY*DELETED?'
Dataset SOFTAUDP - Product Usage
XPUDELPR='DELETED*PRODUCT*INDICATOR'
***ERROR.IMACACCT.ACCOUNT FIELD 1 LENGTH WRONG
messages were due to records with the accounting
field containing "* NOT AVAILABLE" instead of normal
job accounting information (which always starts with
a length field; these data do not). Now, MXG looks
for this text and avoids calling IMACACCT to eliminate
the essentially spurious message.
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND.
Change 24.303 -Where Clauses were added to PROC PLOTS to circumvent an
ANALRMFI error when variables are missing in ANALRMFI,ANALDALY.
ANALDALY -
Feb 4, 2007
Change 24.303 The CPU Report had extra PHYSICAL lines printed if there
ANALRMFR were ICF processors.
Feb 4, 2007
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 24.302 -RMF III dataset ZRBDVT is enhanced with new calculated
VMACRMFV variables that have been found to be useful in reporting;
Feb 3, 2007 their names, labels, and formats match their RMF I TYPE74
counterparts and are in the same units:
AVGCMRMS='AVERAGE*COMMAND*RESPONSE*MSEC PER SSCH'
AVGCONMS='AVERAGE*I/O CONNECT*MSEC PER SSCH '
AVGDISMS='AVERAGE*I/O DISCONNECT*MSEC PER SSCH'
AVGIOQMS='AVERAGE*IOS QUEUE*MSEC PER SSCH'
AVGPNCUB='AVG (MS)*PEND DUE TO*CU BUSY'
AVGPNDEV='AVG (MS)*PEND DUE TO*DEVICE BUSY'
AVGPNDMS='AVERAGE*I/O PENDING*MSEC PER SSCH'
AVGPNSWP='AVG (MS)*PEND DUE TO*SWITCH PORT BUSY'
DURATM ='DURATION*OF*INTERVAL'
-The ZRBENC dataset supports these new zIIP fields that
were added by APAR OA13499:
ENCDECP ='DELAY*COUNT*CP'
ENCDESUP='DELAY*COUNT*ZIIP'
ENCDMSUP='DELAY*COUNT*ZIIP*(MULTI)'
ENCSUCT ='ZIIP*ON*CP*TIME'
ENCSUPT ='ZIIP*TIME'
ENCTSUCT='ZIIP*TIME ON*CP*SINCE*CREATION'
ENCTSUPT='ZIIP*TIME*SINCE*ENCLAVE*CREATION'
ENCUMSUC='USING*COUNT*ZIIP*ON CP*(MULTI)'
ENCUMSUP='USING*COUNT*ZIIP*(MULTI)'
ENCUSCP ='USING*COUNT*CP'
ENCUSSUC='USING*COUNT*ZIIP*ON CP'
ENCUSSUP='USING*COUNT*ZIIP'
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.301 -Yet another "SPLIT70" correction; actual split records
VMAC7072 had incorrect NRPHYCPS values in PDB.TYPE70PR because the
Feb 2, 2007 PHYSICAL segments came in the second, not first, record.
An extra SORT and MEANS were required to correct these
values in TYPE70PR dataset.
-Variable PARTNCPU was incorrect as it could sometimes
still include counts for non-CP engines.
-This change also corrected CPU count variables in the
ASUM70PR output datasets (ASUM70PR/70LP/CEC/ASUMCELP).
-TYPE70PR observations with LPARCPUX=0, and offline LPAR,
had values in SMF70WST/LAC/MSU/NSW/PMA that were carried
forward because they were not reset. Now, the variables
are set to missing values.
Thanks to Rudolf Sauer, T-Systems, GERMANY
Thanks to Martin Brauer, T-Systems, GERMANY.
Thanks to Don Deese, Computer Management Sciences, USA.
====== Changes thru 24.300 were in MXG 24.11 dated Feb 1, 2007=========
Change 24.300 Using the MXG "TAPETEMP" techinque to build PDBs on tape
WEEKBLDT without rewind/backspace has worked for years without any
WEEKBLDD glitches, but that's because no one had tried to stack
WEEKBL3D multiple "WEEK" PDBs in a separate LABEL=(SL,2) tape DSN.
WEEKBL3T That caused ABEND A13-10 when the Second Tape Label was
MONTHWEK opened. The circumvention required these code changes:
MONTHBLS - The MOD in the FILE WEEK MOD .. and FILE MONTH MOD..
MONTHBLD were replaced with new local macro variable &MXGMOD.
MONTHBL3 - A %LET MXGMOD=; is inserted BEFORE the first invoke
Feb 4, 2007 of either _WEEKBLD or _MNTHBLD, and
- After the FIRST invocation of _WEEKBLD or _MNTHBLD,
a %LET MXGMOD=MOD; is inserted.
The setting of MOD only after the first dataset has been
created has circumvented what appears to be a failure by
SAS to close the dataset; this logic eliminates the ABEND
when you stack multiple PDB libraries in separate tape
data sets on a single tape volume.
-An alternative circumvention was to create a dataset on
the output tape before the first invocation of the build,
and then to CLEAR the LIBNAME, as shown below, but the
MOD technique is more elegant and more robust.
DATA WEEK.MXGDUMMY; RUN;
LIBNAME WEEK CLEAR;
Thanks to Robbie McCOY, Salt River Project, USA.
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to Richard Anderson, SAS Institute Cary, USA.
Change 24.299 Support for z/OS 1.8 changed (COMPATIBLE) to RMM Extract
VMACEDGR data:
Jan 31, 2007 Dataset EDGGOEXT - New variable
ROOWNEML='OWNER*EMAIL*ADDRESS'
Dataset EDGGVEXT - New variables
RVCAPACI='VOLUME CAPACITY IN MBYTES'
RVDCRSID='FIRST FILE CREATION SYSTEM ID'
RVDESTBI='DESTINATION BIN NUMBER'
RVDESTBN='DESTINATION BIN MEDIA NAME'
RVDSNNO ='NUMBER OF DATASETS ON VOLUME'
RVEXPTOK='UNIQUE VALUE AT START'
RVLABNO1='LABEL NO OF FIRST FILE'
RVPERCEN='VOLUME PERCENTAGE FULL'
RVPRERR ='PERMANENT READ ERRORS'
RVPWERR ='PERMANENT WRITE ERRORS'
RVRBYSET='VOLUME RETAINED BY SET?'
RVSTACKE='COUNT OF VOLUMES STACKED'
RVSTACKV='STACKED VOLUME ENABLED?'
RVTRERR ='TEMPORARY READ ERRORS'
RVTWERR ='TEMPORARY WRITE ERRORS'
RVVENDOR='VENDOR INFORMATION'
RVVOL1 ='VOL1 LABEL VOLSER'
RVVWMC ='WRITE MOUNT COUNT'
RVWWID ='UNIQUE WORLD WIDE IDENTIFIER'
The five *ERRORS fields did previously exist in 4-bytes;
they are now 5-bytes, but since they were originally kept
as characters, they remain character variables; you can
easily convert to a number with NR=INPUT(XXXXERR,5.);
-Feb 2: Type H added flag to identify the Date Format
(JULIAN, EUROPEAN, AMERICAN), and the GMT Offset.
When present, the GMTOFF is used to change the XXXXDATE
and XXXXTIME variables to their local values.
Thanks to Reinhard Nitsche, GAVI, GERMANY.
Change 24.298 The BLDSMPDB utility new option BUILDPDB=COPYONLY can be
BLDSMPDB used to copy/manage the daily/weekly/wtd PDB libraries
Jan 31, 2007 for non-SMF data. For example you could build a PDB with
TMS and DCOLLECT data and manage it with COPYONLY:
%INCLUDE SOURCLIB(TYPSDCOL);
%INCLUDE SOURCLIB(TYPSTMS5);
%BLDSMPDB(BUILDPDB=COPYONLY);
In addition, new option ERASEPDB=NO prevents the deletion
of all of the pre-existing datasets in the PDB library,
so you could process TMC, DCOLLECT, and SMF data into the
day-of-week datasets using
%INCLUDE SOURCLIB(TYPSDCOL);
%INCLUDE SOURCLIB(TYPSTMS5);
%BLDSMPDB(BUILDPDB=buildpdb,erasepdb=no);
====== Changes thru 24.297 were in MXG 24.10 dated Jan 30, 2007=========
Change 24.297 Support for optional CMODHEAD='OMEGAMON' CICS segment,
IMACICO2 adds duration/counts for ADABAS, IDMS, SUPRA, DATACOM and
UTILEXCL a user defined vent. The duration fields are in the new
VMAC110 CICS/TS 3.2 format, with 8 bytes for duration.
Jan 30, 2007
Change 24.296 Support for NMON for AIX/Linux, "Nigel's Monitor", a free
EXNMONIN monitor from IBM. That product's home page is located at
IMACNMON http://www-941.haw.ibm.com/collaboration/wiki/display/
TYPENMON wikiptype/nmon
TYPSNMON This is the first iteration, and some of the static info
VMACNMON (count of disks, disk names, directory names, etc) was
VMXGINIT hand coded for this site's choices, and the startup data
Jan 30, 2007 is not decoded yet, so this support will evolve, There
is a massive amount of documentation about data values
at the NMON web site, so this looks to be a very good
data source for AIX and Linus.
Dataset NMONINTV contains interval observations with all
of the interval metrics that were in the test file.
Thanks to Steve Ko, Honda Canada, CANADA.
Change 24.295 Support for APAR OA17569, new SMF 14/15 subtype=7 adds
VMAC1415 four variables that describe the Key Labels and Encoding
Jan 29, 2007 Mechanism for Encrypted Tape Data Sets.
SMF14CD1='ENCODING*MECHANISM*KEY 1'
SMF14CD2='ENCODING*MECHANISM*KEY 2'
SMF14KL1='KEY*LABEL*1'
SMF14KL2='KEY*LABEL*2'
Change 24.294 Support for SMF ID=112 record, the "ONDV" data that was
VMAC112 in the Omegamon User SMF record supported in TYPEOMCI.
Jan 29, 2007 This new record is completely restructured, with changed
clocks and counters, but the same twelve datasets are
created with most of the same variable names unchanged:
DDDDDD MXG MXG
DATASET DATASET DATASET
SUFFIX NAME LABEL
OMCADA OMCIADA OMEGAMON CICS ADABAS DETAIL
OMCADT OMCIADAT OMEGAMON CICS ADABAS TOTALS
OMCDLI OMCIDLI OMEGAMON CICS DL/I DETAIL
OMCDLT OMCIDLIT OMEGAMON CICS DL/I TOTALS
OMCDTC OMCIDTCO OMEGAMON CICS DATACOM DETAIL
OMCDTT OMCIDTCT OMEGAMON CICS DATACOM TOTALS
omcidm OMCIIDMS OMEGAMON CICS IDMS DETAIL
omcidt OMCIIDMT OMEGAMON CICS IDMS TOTALS
OMCSUP OMCISUPR OMEGAMON CICS SUPRA DETAIL
OMCSUT OMCISUPT OMEGAMON CICS SUPRA TOTALS
OMCVSA OMCIVSAM OMEGAMON CICS VSAM FILE DETAIL
OMCVST OMCIVSAT OMEGAMON CICS VSAM TOTALS
====== Changes thru 24.293 were in MXG 24.10 dated Jan 28, 2007=========
Change 24.293 IBM note "Correlating MQSeries Accounting Data to CICS"
VMAC116 from 2004 documents that while QWHCTOKN is not populated
Jan 28, 2007 in SMF 116 records, MQSeries V5.R2 added QWHCNID which is
populated with the NETSNAME/UOWID/UOWTIME data that MXG
normally extracts from QWHCTOKN in CICS records. Now, MXG
creates NETSNAME, UOWID, and UOWIDCHR from QWHCNID when
it is populated.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 24.292 Support for IBM WebSphere MQ V6.0 Open Systems Accounting
VMACWMQA and Statistics is preliminary; this iteration reads the
EXWMQMQI output file created by IBM's "amqsmon" program, but the
EXWMQMQI support will be changed to read the raw messages from the
EXWMQQUE open systems accounting and statistics queues. These
IMACWMQA five data sets are created from either input:
TYPEWMQA dddddd Dataset Description
TYPSWMQA WMQMQA MQIACTNG MQI ACCOUNTING
VMXGINIT WMQQUA QUEACTNG QUEUE ACCOUNTING
Jan 26, 2007 WMQMQS MQISTATS MQI STATISTICS
WMQQUS QUESTATS QUEUE STATISTICS
WMQCHS CHNSTATS CHANNEL STATISTICS
Thanks to Milt Weinberger, Metropolitan Life, USA>
Change 24.291 DB2 SMF 102 IFCID 22 dataset T102S022 variables were bad
VMAC102 after QW0022VN which was read with $VARYING64. QW0022VL;
Jan 25, 2007 IBM writes all 64 bytes, not just the expected QW0022VL
length-of-field bytes, so MXG was always misaligned, as
QW0022VN is always 26 characters. Now 64-22VN is SKIPed.
This was accidentally discovered in SMF data sent for an
unrelated question, so I suspect few have used T102S022.
Thanks to Rachel Holt, Fidelity, USA.
Change 24.290 APAR OA12597 caused invalid and large CPURCTTM values in
VMXGRMFI both RMF 72 and SMF 30, but APAR OA19282 appears to be
VMAC7072 the correction. The original error causes, among other
VMAC30 things, ERROR: NEGATIVE UNCAPTURED-CPU-TIME message
Jan 26, 2007 when RMFINTRV processes these data. But the error didn't
print the five components of the CPU72TM, and the message
text referenced ancient APARs. The revised message text
gives clearer instructions and prints the CPU components.
If you find these error conditions, prior to OA19292:
a. Correct your PDB library data without rereading SMF
with these DATA steps:
DATA PDB.TYPE72GO; SET PDB.TYPE72GO;
CPUTM=CPUTM-CPURCTTM;
DATA PDB.STEPS; SET PDB.STEPS;
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
DATA PDB.JOBS; SET PDB.JOBS;
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
DATA PDB.SMFINTRV; SET PDB.SMFINTRV;
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
or
b. Correct when your MXG program reads SMF 30 or 70 data
records (whether by BUILDPDB, TYPS30, TYPS7072, etc):
Insert the below statements before the OUTPUT in the
MXG Exit Members (you copy the EXdddddd from the MXG
Source into your "USERID.SOURCLIB(EXdddddd)":
In member EXTY72GO:
CPUTM=CPUTM-CPURCTTM;
In members EXTY30U4, EXTY30U5, EXTY30U6, IMACINTV:
CPUTM=CPUTM-CPURCTTM;
CPUTOTTM=CPUTOTTM-CPURCTTM;
Thanks to Pat Curren, Supervalu, USA.
Change 24.289 FTP Client Security fields are now added to TYP11903:
FORMATS FCCIPHER='CIPHER*SPECIFICATION'
VMAC119 FCCPROTE='CONTROL*CONNECTION*PROTECTION*LEVEL'
Jan 25, 2007 FCDPROTE='DATA*CONNECTION*PROTECTION*LEVEL'
FCLOGINM='LOGIN*METHOD'
FCMECHAN=*PROTECTION*MECHANISM'
FCPROTBU='NEGOTIATED*PROTECTION*BUFFER*SIZE'
FCPROTOL='PROTOCOL*LEVEL'
FTP Server Security fields were added by Change 23.146.
Thanks to Debbie Shugerts, Verizon, USA.
Change 24.288 -Corrections to the sample VTS analyis report. The PUT
ANAL94 format for seven variables is $5 in place of 5 as they
VMAC94 are character variables. TOTPHYMT includes suffix 2s.
Jan 24, 2007 -SMF94VCA is zero after F/C 4001, so it is recalculated
Jan 31, 2007 as SMF94VCA=SUM(OF S94VCA41-S94VCA48)/8; when VCA=0.
Feb 2, 2007 -Feb 2: $5 changed to $13 to display full DEV name.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 24.287 Variable MQTOTTM in CICSTRAN from CANMQ segment was wrong
IMACICOM because it was missing the multiply-by-16 to convert the
Jan 25, 2007 inputted PIB4.6 value to the correct time units.
The missing MQTOTTM=16*MQTOTTM; statement was added; your
existing CICSTRAN data is valid if you multiply MQTOTTM
by 16.
In the process of finding this MXG error, I realized that
I could detect an error in your CICS tailoring, at least
if you had the optional CANNQ segment, by validating that
its expected length of 76 was in fact found as expecte.
If you have only optional CICS segments, but no EXCLUDEd
fields, and you didn't tailor all of the needed IMACICxx
members for all of your optional segments that exist, and
if you didn't use UTILEXCL to create an IMACEXCL for your
optional CICS segments, then you could have no errors on
the log (because MXG can only detect EXCLUDEd fields),
but your CANMQ data (in this case) would be trashed as it
was read from the wrong part of the SMF 110 record.
At least for the CANMQ segment, the length of the segment
is contained in the record, so the IMACICOM member that
you tailor (by removing the comment block) will detect if
it doesn't find the correct length of 76 at the start.
Unfortunately, I had to not-ERROR on zero length, as
all of the records from an APPLID will have the 76 byte
segment, but if the transaction was not involved in MQ,
those bytes are all hex zeroes.
Although UTILEXCL has always been required for EXCLUDEd
fields, it really is required, to be completely safe,
even if you ONLY have optional CICS segments, with no
excluded fields. If you just manually update all of the
IMACICxx members for all of your SEGMENTS, but do not
have a UTILEXCL-created IMACEXCL in effect, then the
optioal segments are input in the default static order in
the IMACICDA member, which applies to ALL of your
records, so you could have data out of order, if all
regions don't have the same group of optional segments.
By using UTILEXCL, its IMACEXCL only calls the right
segment for each record, and MXG cannot get out of
alignment.
In any case, this change will detect an out of order
condition, and let you know you need to run UTILEXCL.
P.S. Perry's tailoring was correct; in examining the
CANMQ data, which appears to be incorrect, I
realized the exposure and made this change.
Thanks to Perry Lim, Union Bank of California, USA.
Change 24.286 Support for Tandem H06 release added variables compatibly
VMACTAND to the TANDPROC, provided you still create the "old" data
Jan 24, 2007 record format.
Thanks to Harriet Sollod, Wells Fargo Bank, USA.
Change 24.285 Comments in JCLWEEK were correct that that example is for
JCLWEEK building a weekly PDB on DISK, with daily PDBs on DISK,
Jan 23, 2007 but the //WEEK DD erroneously had UNIT=TAPE. JCL Example
is corrected.
Thanks to Lisa L. Lawyer, Lands End, USA.
Change 24.284 My attempt to add REGION=0 to the // PROC JCL statement
MXGSASV9 in Change 24.246 was wrong, generating JCL errors that
MXGSASV8 EXEC STATEMENT KEYWORDS ARE RESERVED AND CANNOT BE USED.
Jan 23, 2007 That REGION=0M belongs on the // EXEC PGM= JCL statement
inside the JCL Procedure, and not on the PROC definition.
Thanks to MP Welch, SPRINT, USA.
Change 24.283 Support for TPF thru PUT19 adds two new datasets
VMXGINIT dddddd dataset description
EXTPFKC TPFKC
EXTPFSB TPFSB
VMACTPF and additions to existing datasets:
VMXGTPFI - TCPIP Message counters (SXTCPIN) added to SS/SR/ST
Jan 23, 2007 - Multiple Systems with Same CPUID supported
- Label and KEEP for PUT12 implementation corrected
- Update to FF processing for PUT19 (IBM vanilla)
- Update SPX PUT15 Dispensed & Returned Counters
and new fields added in PUT15.
- Added SPXSS for "PS" processing, due to multiple
datasets (SPXSS) on FCA.
Thanks to Bob Wilcox, EDS, USA.
====== Changes thru 24.282 were in MXG 24.10 dated Jan 22, 2007=========
Change 24.282 A new report, "DB2 Storage Analysis" uses IFCID 225 and
ANALS225 the DB2STATS dataset to report on storage used by each
Jan 22, 2007 DB2 subsystem, above and below the line and above the
bar. The report creates an HTML report; the destination
must be a PDSE with LRECL=8000, LKSIZE=8004, and required
MXG 24.08 or later for the enhanced T102S225
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.281 -Support for BMC Mainview for MQ Series V4.2 VSAM History
ASMMNVW file; record changes caused MXG to not output any obs
EXBBMQAS with the new BMC version. Many new variables are now
EXBBMQCF created by this change.
EXBBMQDB -BMC's BBMQVSAM record are compressed, and member ASMMNVW
EXBBMQQU has the "MNVW" Infile Exit that you install to read BMC
IMACBBMQ compressed data, but I did not test for compressed data;
VMACBBMQ now, if you try to read compressed records without having
VMXGINIT the MNVW exit installed, you'll get an MXG message that
Jan 24, 2007 tells you what to do.
-Support for 'E6'x QUEUE STATISTICS RECORD creates new
BBMQQUES dataset with 187 variables.
-Support for 'E7'x DB2 MANAGER RECORD creates new
BBMQDB2M dataset with 445 variables.
-Support for 'E8'x COUPLING FACILITY RECORD creates new
BBMQCFAC dataset with 81 variables.
-Support for 'E9'x APPLICATION STATISTICS RECORD creates
new BBMQAPPL dataset with 200 variables.
-Jan 27: corrected variables with 9-byte names.
Thanks to Stuart Wildey, Morgan Stanley, USA.
Thanks to Patrick E. Fortune, Morgan Stanley, USA.
Thanks to Jeff Sorokin, Morgan Stanley, USA.
Change 24.280 An undocumented change in MXG 24.02 corrected variable
VMACICE name VDEVNAME to VDEVFDID in dataset ICEBRGUT, and also
Jan 22, 2007 revised the text in several variable's labels.
This is an INCOMPATIBLE change, if your reports use the
old variable name. My apologies: first, for spelling it
wrong, and second for not documenting it last year!
Thanks to Yves Terweduwe, CIPAL, BELGIUM
====== Changes thru 24.279 were in MXG 24.10 dated Jan 21, 2007=========
Change 24.279 -Support for SAMS Vantage (INCOMPATIBLE) changes in their
EXSAM099 Version 6.x. The new "POOLVOLS" segment appears to have
EXSAM100 exactly the same data as the old "LSPACEPO" segment, so
EXSAM101 they are OUTPUT in the same SAMSLSPC dataset.
EXSAM102 -Support for new SAMS DTOC and eight OBJ02nnn subtypes:
EXSAM103 SAMSDT SAMSDTOC SAMS DTOC RECORD DTOC
EXSAM119 SAM099 SAMO2099 SAMS 2099 EMC SYSTEMS OBJ2099
EXSAM120 SAM100 SAMO2100 SAMS 2100 EMC CHANNEL DIRECTOR OBJ2100
EXSAM121 SAM101 SAMO2101 SAMS 2101 EMC DISK DIRECTORS OBJ2101
EXSAM122 SAM102 SAMO2102 SAMS 2102 EMC PHYSICAL DEVICES OBJ2102
EXSAM129 SAM103 SAMO2103 SAMS 2103 EMC LOGICAL VOLUMES OBJ2103
EXSAM150 SAM119 SAMO2119 SAMS 2119 IBM ESS SUBSYSTEM OBJ2225
EXSAM225 SAM120 SAMO2120 SAMS 2120 IBM ESS SSIDS OBJ2225
EXSAM227 SAM121 SAMO2121 SAMS 2121 IBM ESS LOGICAL PATHS OBJ2225
EXSAM230 SAM122 SAMO2122 SAMS 2122 IBM ESS VOLUMES OBJ2227
IMACSAMS SAM129 SAMO2129 SAMS 2129 IBM ESS RAID RANKS OBJ2227
VMACSAMS SAM150 SAMO2150 SAMS 2150 IBM ESS PPRC INFO OBJ2227
VMXGINIT SAM225 SAMO2225 SAMS 2225 EMC ALL DEVICES OBJ2227
Jan 19, 2007 SAM227 SAMO2227 SAMS 2227 EMC RDF DEVICES OBJ2227
Jan 28, 2007 SAM230 SAMO2230 SAMS 2230 EMC BCV DEVICES OBJ2230
Jan 31, 2007
Thanks to Mark Daly, CitiGroup, USA.
Change 24.278 Further ASUM70PR summarization corrections,redesign:
VMAC7072 -In PDB.ASUM70LP dataset, variables LPCTBY/LPCTOV were
VMXG70PR slightly wrong (13.087 vs 13.705) with IRD because the
Jan 22, 2007 old integer LPARCPUS value was used; now, the actual
Jan 26, 2007 average number of CPs online is calculated in the
Jan 30, 2007 LPnPREC variables from SMF70ONT/DURATM in PDB.ASUM70LP,
and LPARCPUS in PDB.TYPE70PR is unchanged, containing
the maximum number of CPs online during the interval.
It was only those variables in PDB.ASUM70LP that were
slightly wrong; their counterpart variables LPCTnBY and
LPCTnOV in the PDB.ASUM70PR dataset were just fine.
Note that you cannot use SMF70BDA as it includes the
count of CPs plus any IFAs plus ZIPs.
-Variable LPnCHG, (Nr CPUs Changed?) is now always blank.
The variable was always 'Y' for IRD, and always blank if
you didn't summarize in ASUM70PR, and with IRD there's no
need, since LPnNRPRC is the average count that interval
-CURSHARE and SYSSHARE were corrected for Dedicated CPs.
-If all your systems are on the same time zone, GMTOFFTM
is valid in the ASUM70PR-created summary datasets, and
Change 24.xxx's use of GMTOFFTM to protect setting of the
system clock ahead/behind on an active system was fine.
Even if you have systems with different GMTOFFTM values
(i.e., some systems local, some systems GMT), the system-
level PDB.ASUM70PR/PDB.ASUM70LP dataset are fine, but
that change was removed for the PDB.ASUMCEC/PDB.ASUMCELP
CEC-level summary datasets, where it created invalid and
extra observations where there were multiple values of
GMTOFFTM in a CEC. With its removal from the BY list,
those datasets are now valid; however, the actual value
in GMTOFFTM in those two datasets may or may not be the
actual GMTOFFTM of the datetimestamps, and there may not
be a way for MXG to actually know what that true GMTOFF
value is from those two datasets. If this is a problem,
please discuss with support@mxg.com, but it should be a
minor nit for only a small number of sites.
-Jan 30: CURRSHARE corrected for non-IRD managed LPArs.
Thanks to Bill McDonald, KCC, USA, for the original error, and,
for testing several iterations of this significant exposure:
Thanks to Don Deese, Computer Management Sciences, USA.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 24.277 The CICS Shutdown Report ANALCISH was revised to support
ANALCISH variables dropped by MXG (MNGSYSER and MNGSYSEE), and new
Jan 18, 2007 variables MNGRR and MNGRRS were added to the MONITOR
Feb 4, 2007 report. A04VADQK moved from SUM= to MAX= and AO4SKINS
was added to the ID= statement.
-New CICLGG Logstream Global Statistics added.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 24.276 Systems with Dedicated CP engines had variables PCTONLNx
ANALRMFR (Percent Online) always missing in PDB.TYPE70, which then
VMAC7072 caused ANALRMFR CPU Activity Report to have blank values.
Jan 19, 2007 Fortunately, the other variables in PDB.TYPE70 were okay;
this is NOW the final "SPLIT70" correction, and is needed
for z/OS 1.7 and later, if you have Dedicated z/OS CPUs.
-Unrelated, accidentally observed and corrected, the CPU
Number printed by ANALRMFR on the CPU Activity Report was
often incorrect.
Thanks to Bob Keller, Safeway, USA.
Change 24.275 ERROR.MORE THAN 255 STRUCTURES was due to an archaic test
VMAC74 for 255; the arrays had been increased to 1024, but the
Jan 18, 2007 test value and error message text were not revised.
Thanks to Bill McDonald, KCC, USA.
Change 24.274 Utility for ASCII execution to read SMF data via ftp and
ASCISMFC create a local disk file of only selected SMF records.
Jan 17, 2007
Thanks to Bill McDonald, KCC, USA.
Change 24.273 Extraneous '60'x character in column 1 of line 140 caused
WEKBLDD a syntax error, now removed.
Jan 17, 2007
Thanks to Lisa Lawver, Land's End, USA.
Change 24.272 -Enhancement to ASMRMFV RMF III adds ENC Extension feature
ASMRMFV and ASM symbolics to let users tailor the ASMRMFV default
VMACRMFV parameters were added.
Jan 18, 2007 -Enhancement to VMACRMFV to decode the ENC Extension,
which adds these new variables to the ZRBENC dataset:
ENCCNM ='SERVICE*CLASS*NAME'
ENCCDE ='SERVICE*CLASS*DESCRIPTION'
ENCCWN ='ASSOCIATED*WORKLOAD*NAME'
ENCCRN ='ASSOCIATED*RESOURCE*GROUP'
ENCCPO ='OFFSET TO*SERVICE*CLASS*PERIOD ENTRY'
ENCCPN ='NUMBER OF*SERVICE*CLASS*PERIODS'
ENCCGI ='RESOURCE*GROUP*INDEX*IN ENCRG'
ENCCWI ='WORKLOAD*INDEX*IN ENCWD'
ENCCRC ='PERIODS*WITH*RESPONSE*TIME GOAL'
ENCRNM ='REPORT*CLASS*NAME'
ENCRDE ='REPORT*CLASS*DESCRIPTION'
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.271 -Variables AVGRSPMS, DEVACTTM, and DEVIOQTM are created in
VMACRMFV RMF III dataset ZRBDVT to match IBM response metrics, and
Jan 17, 2007 variable SWPODLTM is now kept.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.270 Variable GDESDP2 was incorrectly input @11 instead of @9,
VMACQACS causing a value of 16,448 for available processors.
Jan 16, 2007
Thanks to Robert Gilbert, Fortis Bank, BELGIUM.
Change 24.269 This is the schematic of zIIP CPU time variables in the
ADOC30 TYPE30xx, JOBS, STEPS datasets. zIIP CPU time is always
Jan 16, 2007 in separate variables that are never included in the old
"CPU" variables that, then and now, contain ONLY the time
spent on "CP Engines".
CPUZIPTM /*SMF30_TIME_ON_ZIIP*/
CPUDZITM /*SMF30_DEP_ENCLAVE_TIME_ON_ZIIP*/
CPUEZITM /*SMF30_IND_ENCLAVE_TIME_ON_ZIIP*/
CPUZIETM /*SMF30_ELIGIBLE*TIME_ZIIP_ON_CP*/
CPUDZETM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_ON_CP*/
CPUEZETM /*SMF30_IND_ENCLAVE_TIME_ZIIP_ON_CP*/
CPUEZQTM /*SMF30_IND_ENCLAVE_TIME_ZIIP_QUAL*/
CPUDZQTM /*SMF30_DEP_ENCLAVE_TIME_ZIIP_QUAL*/
CPU TIME ON ZIIP ENGINES CPU TIME ON CP ENGINES
"Actual" "Eligible"
|--------CPUZIPTM---------| |--------CPUZIETM---------|
|--CPUDZITM--|--CPUEZITM--| |--CPUDZETM--|--CPUEZETM--|
(DEP) (IND) (DEP) (IND)
"Qualified - Dependent Enclave"
(Sum of DEP Actual and Eligible)
|-------CPUDZQTM----------|
|--CPUDZITM--|--CPUDZETM--|
"Qualified - Independent Enclave"
(Sum of IND Actual and Eligible)
|-------CPUEZQTM----------|
|--CPUEZITM--|--CPUEZETM--|
See also MXG Technical Note 31 in Newsletter FORTY-NINE,
"zIIP CPU Time Comparisons between TYPE72GO and TYPE30_V".
Thanks to Bob Keller, Safeway, USA.
Change 24.268 Variables SMF70GIE and STARTIME were not kept as 8-bytes
VMXG70PR in ASUMCEC and ASUM70LP datasets; now, using the new
Jan 15, 2007 MINLONG= argument added to VMXGSUM, they are.
Change 24.267 New MINLONG= and MAXLONG= arguments are added to create
VMXGSUM min/max output that are 8-bytes long, like the existing
Jan 15, 2007 SUMLONG= argument.
Change 24.266 If you change macro _IMSWORK in IMACIMS, TYPEIMS7 failed,
TYPEIMS7 dataset IMS07 NOT FOUND, because _IMSWORK was not used in
Jan 14, 2007 TYPEIMS7. Now, the syntax is consistent.
Thanks to Erling Anderson, SMT Data, DENMARK.
Change 24.265 MXG 24.04-24.09. PDB.ASUMTAPE lost many observations,
ASUMTAPE only for TMNTEXIT='IBM'. Change 24.109 added incorrect
Jan 14, 2007 logic to propagate READTIME into 2nd-vol (HAVEMNT=501A)
events that are always missed by TMNT. Propagation is
now corrected, but there can ALWAYS be missing values
in many of the variables in PDB.ASUMTAPE, depending on
which events were found for this mount (which combines
TMNT Mount, Syslog Mount or Keep, SMF21 dismount events.)
An output from PROC MEANS N DATA=PDB.ASUMTAPE shows:
Variable N Implication
ZDATE 4030 Total mount event obs created
READTIME 1675 Mounts for jobs with a TMNT record
TAPMNTTM 1328 Mounts with a TMNT record
BYTES 3866 Mounts with matching TYPE21
TAPMTDTM 3615 Mounts with BEGTMNT/ENDTMNT
-If TMS9 message was first, with no prior SYSLOG MOUNT,
the TOTMNDTM duration was negative, SYLMTIME was wrong,
and there were other defects. This happens when SYSLOG
mount event was in yesterday's event for a long running
task that's writing lots of datasets (TMS9 for each one).
-When SYLMTIME is missing, EVENTIME=SYLKTIME-5 is now set
with a 5 second adjustment; SYLKTIME can be fractions of
a second later than TY21TIME, and this ensures TMNT will
be seen before SYSL in the merge.
-When TMS9 message was first, retained times were not
clearedl
Thanks to Doug Medland, IBM Canada, CANADA.
Change 24.264 Support for CMRDETL (T6E) records for Mainview for CICS
VMACMVCI Version 5.9.00 adds (COMPATIBLY) 132 new variables to the
Jan 12, 2007 CMRDETL dataset.
Change 24.263 Comments only; if you want to use VMXGGETM's arguments to
UTILGETM select SMF data, you need to invoke %VMXGGETM (... ) ;
Jan 11, 2007 as UTILGETM will not accept arguments.
Thanks to Flavio Lima, Bank of America, USA.
Change 24.262 If you want to know how many bytes of SMF data is written
Example for each of your CICS regions, by subtype, this example:
Jan 11, 2007 //SMF DD
//SYSIN DD *
%LET MACKEEP=
MACRO _KCICTRN )
CICSHDR (KEEP=APPLID MEGABYTE SUBTYPE
%
_N110
;
%LET MAC110H=
%QUOTE(MEGABYTE=LENGTH/1048576; OUTPUT CICSHDR;)
;
%INCLUDE SOURCLIB(TYPE110);
PROC FREQ DATA=CICSHDR;
TABLES APPLID*SUBTYPE;
WEIGHT MEGABYTE;
TITLE SMF 110 MEGABYTES BY SUBTYPE FOR EACH APPLID;
Thanks to Bruce Sloss, PNC, USA.
Change 24.261 Analysis of CPU variability as a function of NRCPUS for
ANALCPUV investigation of IRD impact. Reads PDB.TYPE70 to create
Jan 9, 2007 a temporary format $MGNRCPU with NRCPUS for each STARTIME
interval, uses that format to add the variable NRCPUS to
to each PDB.SMFINTRV observation, also finds each JOB's
MINCPUTM and MAXCPUTM, used to calculate each interval's
PCTOVRMN (Percent CPU TCB was above minimum recorded) and
PCTBLOMX (Percent CPU TCB was below maximum recorded).
The intent is to analyze benchmark data in which the same
job is run multiple times on a system with wide range of
IRD-controlled NRCPUS, to see if there is a measurable
impact on recorded CPU TCB time due to IRD.
It is theorized that the recorded CPU seconds should
be smaller when NRCPUS is small, and larger when the
NRCPUS is large, because of the "MP effect", partly
because the SU_SEC used to calculate service units
is NOT adjusted when IRD changes NRCPUS.
This program is ready to test that theory, and will
quantify the observed variability in CPU times, if
any is observed.
Let's discuss, before you run your benchmark.
Change 24.260 Documentation. Variable SUBMUSER was not in Dataset JOBS
DOCVER in the DOCVER documentation, because JOBS/STEPS/PRINT in
QAJOBXX DOCVER were all from the JES3 BUILDPD3, but SUBMUSER is a
Jan 8, 2007 JES2-only variable. While I figure out how to change the
descriptions in DOCVER, where same-named datasets with
different variables are created by MXG, moving the JES3
BUILDPD3 ahead of the JES2 BUILDPDB in the QAJOBXX QA
job will cause DOCVER to contain the descriptions of the
datasets built by the JES2 BUILDPDB.
Change 24.259 Mobius Subtype 8 record caused INPUT STATEMENT EXCEEDED
VMACIPAC error, because the final field, IPPACCES was only 4 bytes
Jan 5, 2007 while MXG expected 8. Both lengths are now protected.
This change also added support for R6.3.
Thanks to Jolene Halibry, Nationwide, USA.
Change 24.258 Product section character variables after PROPMPRE (most
VMACPROS of them!) were wrong because MXG's INPUT statement was
Jan 5, 2007 off by one byte. Some character variables with hex data
were not formatted but now are.
Thanks to John Kim, ATCO I-Tek, USA.
Change 24.257 Support for Beta 93 (Report/Print) Version 3.6.1 SMF; new
VMACBETA variables were added compatibly for tested subtypes:
Jan 4, 2007 Subtype 0: BETA0 dataset:
BETACTYP='CLEANUP*TYPE'
BETARCME='ARCHIVE*MEDIA*TYPE'
BETARETA='ARCHIVE*RETENTION*PERIOD'
Subtype 1: BETA1 dataset: no changes.
New subtypes 10, 51, and 52 are documented but will only
be supported when they are available for validation.
Thanks to Engelbert Smets, Provinzial, GERMANY.
Change 24.256 New variables added to IFCID 226 and 227 are supported.
VMAC102 Variables QW0226PN/QW0227PN are now character zeros, as
FORMATS new QW0226PG/QW0227PG variables now contain page number,
Jan 3, 2007 new QW0226FG/QW0227FG contain table space type, which is
decoded by new MGD226S format.
Thanks to Bill Schray, IBM Global Services, USA.
Thanks to Ted Blank, IBM Global Services, USA.
Change 24.255 Cosmetic, but may be useful. The MXG Messages printed on
VMACSMF the log at the end of SMF input are enhanced with elapsed
Dec 29, 2006 duration and the read rate of the input data:
*******************************************************
*** MXG 24.09 SUCCESSFULLY COMPLETED READING SMF.***
26750 LOGICAL SMF RECORDS WERE READ.
THE SMF FILE CONTAINED 325,284,835 BYTES,
WHICH IS 310MB.
MINIMUM SMF RECORD TIMESTAMP WAS 02SEP2004:09:00:00.04.
MAXIMUM SMF RECORD TIMESTAMP WAS 02SEP2004:09:34:57.14.
MXG FINISHED READING SMF FILE AT 29DEC2006:15:54:40.06.
ELAPSED TIME TO READ SMF FILE 0:00:08.69.
SMF READ RATE PER ELAPSED TIME 35MB/SEC.
*******************************************************
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.254 -Support for the rest of the Candle/IBM optional CICS data
IMACICC5 segments are added to UTILEXCL:
IMACICC6 IMACICC5 CANSUPRN SUPRA*TOTAL*REQUESTS
IMACICC7 IMACICC6 CANSUPRT SUPRA*TOTAL*DURATION
IMACICC8 IMACICC7 CANDCOMN DATACOM*TOTAL*REQUESTS
IMACICC9 IMACICC8 CANDCOMT DATACOM*TOTAL*REQUESTS
IMACICE3 IMACICC9 CANRES01 VSAM*TOTAL*REQUESTS
IMACICE4 IMACICE3 CANIDMSN IDMS*TOTAL*REQUESTS
UTILEXCL IMACICE4 CANIDMSN IDMS*TOTAL*REQUESTS
VMAC110 -Validation discovered that the CANGMTOF GMT offset was
Dec 24 2006 never correct, but IMACICC1 is now revised to correctly
IMACICC1 decode the partial TOD stamp into the offset duration.
Dec 28, 2006
Technical Note ons tailoring CICS IMACICxx members:
When you use UTILEXCL to create IMACEXCL (RECOMMENDED!!),
you can remove Comment Blocks in ALL of your IMACICxx
members, because IMACEXCL's code only %INCLUDEs the IMACs
needed for each "DO GROUP" found in your PDB.CICSDICT.
Each execution of _BLDDICT appends new CICS dictionary
records found in SMF to the old PDB.CICSDICT dataset,
which is then read by _BLDEXCL to create the IMACEXCL
code that will read your SMF 110 CICSTRAN records.
The KEEP= list in IMACEXCL has only those variables that
exist in your PDB.CICSDICT records. Or, the KEEP= list
could have ALL of the hundreds of optional variables and
now defunct variables, if you have a old CICS dictionary
record from a test system long ago in your PDB.CICSDICT.
You may PROC DELETE DATA=PDB.CICSDICT; and create a new
IMACEXCL based only on today's CICS dictionary records.
And/or you can delete unwanted APPLIDs from PDB.CICSDICT
before you run the _BLDEXCL.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 24.253 Internal macro variable WORD4 was never set to a value,
READDB2 due to a typo.
Dec 23, 2006
Thanks to R. Narruli, DST Systems, USA.
Change 24.252 The eight-byte EXCP count in SMF33EXX that replaces the
VMAC33 four-byte SMF33EXP count is now INPUT when it exists.
Dec 23, 2006
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
====== Changes thru 24.251 were in MXG 24.09 dated Dec 20, 2006=========
Change 24.251 Protection for Mainview MQ records RTIN='26'x that didn't
VMACBBMQ contain the ISHD header segment that MXG thought would
Dec 20, 2006 always be there. Variables DURATM ENTC and GMTOFF might
be missing when there is no ISHD header segment.
Thanks to Stuart Wildey, Morgan Stanley, ENGLAND.
Change 24.250 Protection for Export date format of DDMMYY instead of
VMACMWNT expected MMDDYY requires you to set new &DATEFMT macro
VMXGINIT %LET DATEFMT=DDMMYY;
Dec 19, 2006 %INCLUDE SOURCLIB(TYPSMWNT);
if the "MWA EXPORT DD/MM/YY" text in the first record has
that format.
-The INPUT of SOFTWARE and RELEASE was revised to protect
for a Logfile name that contains blanks.
Thanks to Dominik Covens, KBC, BELGIUM.
Change 24.249 The old MACRO _DIFFHSM definition did not add _Sdddddd
VMACHSM sort macros for HSMWWFSR and HSMWWVOL datasets, probably
Dec 18, 2006 because the _Sxxxx Product Sort macro had replaced the
early "DIFF" nomenclature, and _DIFFHSM was overlooked.
Now, those two datasets are included when _DIFFHSM is
invoked, but the preferred name to use in your EXPDBOUT
member is to have a _Sxxxx statement for each VMACxxxx
that you %INCLUDed in your EXPDBINC tailoring member.
Then, MXG is responsible for any deaccumulation as well
as adding any new datasets into your PDB library as part
of your BUILDPDB job.
Thanks to Dwain Majak, B, B, and T, USA.
Change 24.248 Enhancement to the "BUILD PDB EXAMPLE", BLDSMPDB, adds
BLDSMPDB optional processing of DCOLLECT and TMS/CA-1 records into
Dec 18, 2006 the daily PDB library, so they can also then be created
Dec 20, 2006 in your weekly and monthly PDB libraries.
New argments:
DCOLLECT=DCOLLECT - read INFILE DCOLLECT output PDB
=dsname - alloc FILENAME DCOLLECT to dsname
all output to PDB
TMC =TMC - read INFILE TMC output PDB
dsname - allocates FILENAME TMC to dsname
Additionally, SMF data weekly/monthly processing can be
weekly/wtd, and monthly/mtd. Weekly/Monthly will copy
all, or only selected, datasets. Exits were added for
flexibility during weekly/monthly/trend processing.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.247 Inconsistent macro definitions for _Vdddddd, _Wdddddd:
VMACCMA -VMACCMA User SMF record now have the standard, expected
VMACQACS macro token names and definitions for the syntax for
VMACTNG "Single Infile, Multiple Datasets Per Product" data:
VMACTMO2 For each output dataset:
VMACCIMS MACRO _Vdddddd
Dec 19, 2006 KEEP= list of variables
%
MACRO _Wdddddd &Wdddddd..DATASET %
MACRO _Kdddddd %
Output all datasets for the product:
MACRO _VARXXXX
_Wdddddd
(LABEL='dddddd: description'
_Vdddddd _Kdddddd
)
....
_Wdddddd repeat for each product dataset.
%
-VMACTMO2 User SMF record updated with standard, expected
macro token names, as above for "Single Infile, Multiple
Datasets Per Product" data.
-VMACCIMS User log record updated with standard, expected
macro token names, as above for "Single Infile, Multiple
Datasets Per Product" data.
-VMACTNG macro _NTNG had incorrect syntax, with the text
"MACRO" missing from each statement; it would have failed
if it had been used!
-But even though they are inconsistent naming conventions
now, the VMACQACS AS/400 macro names _VQAPxxx _CQAPxxx
cannot be changed without serious exposure to existing,
fine running jobs. For the record, for these datasets
from "MULTIPLE INFILES, ONE OUTPUT PER INFILE" data:
For each output dataset:
MACRO _TQAPxxx
DATA
_VQAPxxx
_CQAPxxx
%
MACRO _WQAPddd &Wdddddd..DATASET %
MACRO _Kdddddd %
Where the _VQAPxxx was already defined as:
MACRO _VQAPxxx
_Wdddddd
(LABEL='QAPxxx: description'
KEEP= list of variables
)
%
So your tailoring syntax is slightly different here, but
that's the lesser of causing production job failures!
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 24.246 REGION=0M added to MXGSASV9/MXGSASV8 JCL PROC examples to
MXGSASV8 protect sites that did not specify a REGION on their JOB
MXGSASV9 card. (The MXG JCL examples do show REGION=0M on JOB.)
Dec 15, 2006 -When REGION=0M is specified on the JOB JCL statement, the
job gets your installation default REGION size, typically
100MB-300MB, which is quite sufficient for most MXG jobs.
-With any REGION= value specified on the JOB card, all of
the steps get that REGION size, even if there is a larger
or smaller REGION= value on a STEP card.
-If both the JOB and the STEP cards do not have a REGION=
parameter, the job gets a default region of only about
40MB (9MB Private Area + 32MB Above the Line). While
much of MXG 24.08 does run in a 40MB REGION, (including
the JCLINSTL job that successfully created the MXG Format
Library), the BUILDPDB job failed when run in only 40MB,
with SAS FORMAT NOT FOUND errors (but each individual
formats was there and usable by itself). There wasn't
enough region for the "big DATA step", which first
allocates virtual storage for all of the output buffers
for all of the datasets to be created, and then loads all
referenced formats into virtual storage.
-The default BUILDPDB needs more like a 64MB REGION, and
may need 100MB+, if you have tailored your BUILDPDB to
process additional SMF records.
Thanks to Donald Likens, Combined Insurance, USA.
Change 24.245 DVTG3 table had new fields added in 1.7 and 1.8 that are
VMACRMFV now kept:
Dec 18, 2006 CMRTM Command*Response*TIME
DVTCUQTP Control Unit Queueing Time Previous
DVTCUQTN Accum CU Wait for non-FICON devices
DVTCUQTF Accum CU Wait for FICON devices.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.244 New PDB.ASUMDB2G summary dataset for DB2 Global Buffers
ASUMDB2G is created from PDB.DB2ACCTG dataset by ASUMDB2G member.
VMXGINIT
Dec 13, 2006
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Change 24.243 The test for which DB2ACCT observations are counted as
ASUMDB2A NORMAL was revised to include QWACRINV=4 thru 16 and 40
Dec 12, 2006 as NORMAL and all other QWACRINV values as ABNORMAL, to
be consistent with the formatted values of QWACRINV in
the MGDB2RC format.
Thanks to Nigel D. Greenwood, EDS, ENGLAND.
Change 24.242 Revisions to force TEMPxx macro variable explicitly to a
VMXGINIT value of WORK, and revised setting of SASSWORK, etc., for
VMXGSUM anticipated SAS/ITRM changes to support SAS V9 BI.
Dec 12, 2006
Change 24.241 Keyword parameter WORK73 was accidentally typo/deleted in
VMXGRMFI the macro definition, causing an error only if there were
Dec 11, 2006 73 or more workload's defined.
Thanks to Clayton Buck, UniGroup, USA.
Change 24.240 -All durations were 1000 times too large; I assumed the
VMACSYSI times were in 256*milliseconds, like most prior IMS data,
Dec 7, 2006 but data and documentation show they are 256*microsecs,
so all &PIB.4.3 informats were changed to &PIB.4.6.
Thanks to Betra Reeves, Infocrossing, USA.
Thanks to Joel Medberry, Infocrossing, USA.
Change 24.239 MACRO _ROSCDDN has not been used since the &Pdddddd and
VMACROSC &Wdddddd macro variables were defined, but comments in
Dec 6, 2006 IMACROSC and VMACROSC were still present/confusing.
To send all of the ROSCOE datasets to the //PDB DD, use
%INCLUDE SOURCLIB(TYPSROSC) which will sort, remove any
duplicates, and output them to //PDB.
Thanks to Lori Martin, Lockheed Martin, USA.
Change 24.238 RMF III variables ENCTCPUT and ENCCPUT are in millisecs
VMACRMFV in the RMF III record, but are not documented as such.
Dec 5, 2006 They are now corrected in their INPUT, and I have also
made the assumption that these IFA time variables in the
same segment are also in millisecs in the record, and are
also corrected in their INPUT informat.
ENCTIFAT ENCTIFCT ENCIFAT ENCIFCT
Thanks to Brenda Rabinowitz, Merrill Lynch, USA.
Change 24.237 Label for NRZIPCPU and NRIFAS in PDB.RMFINTRV had text of
VMXGRMFI "IN THE BOX", but as RMFINTRV is a PER-SYSTEM dataset,
Dec 1, 2006 the label is changed to "FOR THIS SYSTEM'.
Thanks to Douglas Walker, Citigroup, USA.
Change 24.236 Reserved Change.
EXITCICS
VMACSMF
Nov 30, 2006
Change 24.235 EJBCRECT was input twice, the second time where EJBREMCT
UTILEXCL was located, so EJBCRECT was wrong and EJBREMCT did not
Nov 30, 2006 exist when UTILEXCL was used to process CICS data.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 24.234 If you specified %LET MACKEEP ahead of UTILBLDP, it may
UTILBLDP be ignored if you are also adding records in a BUILDPDB
Nov 21, 2006 process. This change puts your MACKEEP values inside of
the MACKEEP being generated by UTILBLDP. Note however
the error message that your use of MACKEEP here may
defeat something UTILBLDP is trying to do so use it with
caution.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 24.233 MXGERROR: More than 70 200 Byte Strings is circumvented
VMXGSUM by increasing the MXG default to 99 200 byte strings for
Nov 21, 2006 the variable lists (SUM=, etc.) that VMXGSUM must parse.
Using the full line for your variables, up to 72 bytes,
will maximize the number of variables that will fit in
the 99*200=19800 bytes for each argument, enough for 2200
variables with 8-byte names.
Change 24.232 The last field in subtype 2, ACTRREPQ is only 45 bytes,
VMACENTX not the 48 bytes documented by the vendor.
Nov 20, 2006
Thanks to Chris Taylor, GMAC Insurance, USA.
Change 24.231 Label for variables SOV2WMNT was corrected to read:
VMACHPDM SOV2WMNT='ACCUM*DELAY*WAITING*FOR MOUNT'
Nov 18, 2006
Thanks to Tom Elbert, Assurant, USA.
Change 24.230 SAS procedures BLKCOPY & FCOPY (used during Installation
FORMATS and Service Pack Updates, and MIGRATE are now recognized
Nov 14, 2006 by the $MGSASPR format. Even though the official SAS doc
(only found deep in the SAS Support site) says you cannot
use PROC MIGRATE from SAS 6.09E to SAS 9, that particular
conversion IS supported, but only under SAS on z/OS.
Thanks to Jim Horne, Lowe's Companies, USA.
Change 24.229 The program worked fine if output to //WORK was used, but
TYPEIMS7 if you used either of the examples in the comments, to
Nov 9, 2006 send either IMS0708 or IMSSUMRY to the //IMSTRAN ddname,
that failed with ERROR 455-185 DATA SET WAS NOT SPECIFIED
ON DATA STATEMENT.
Thanks to Denise L. Jeffers, CIGNA, USA.
Change 24.228 Support for HyperPAV APAR OA12865.
VMAC74 -TYPE74 dataset: New variables created:
VMAC78 HYPERPAV='HYPERPAV*BASE*DEVICE?'
Nov 11, 2006 SMF74HPC='HYPERPAV*ALIASES*CONFIGURED*THIS LSS'
SMF74PSM='SUCCESSFUL*PAV*SAMPLE*COUNTS'
Variable SMF74TMS is deleted, as it never existed and was
input by MXG in error.
-TYPE78CU dataset: New variables added for each LCUID:
R783HCU ='HYPERPAV CU IDENTIFIER'
R783HNAI='TIMES I/O NO START*NO HYPERPAV*AVAILABLE'
R783HTIO='HYPERPAV I/O*REQUESTS*FOR THE LSS'
R783HAIU='HWM*IN-USE*HYPERPAV*ALIASES'
R783HCAD='HWM*ALIASES*IN USE*ONE BASE'
R783HIOQ='HWM*OF IO-S QUEUED'
Variable PCTALLBY set missing, per Change 19.203, instead
of generating a missing value note for each TYPE78CU obs.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 24.227 Optional ESS GPARMKEY='4A'x caused INPUT STATEMENT
IMAC6ESS EXCEEDED LENGTH error if there were more than one
VMAC6 addressee. MXG now keeps four (ESSMACC1-ESSMACC4)
Nov 7, 2006 and alerts you if there were more, with a note.
Nov 8, 2006 -Support for ESS GPARMKEY='4C'x creates ESSMFROM variable
Nov 9, 2006 and for ESS GEPARMKY='42'x creates ESSOFSYF variable.
-Support for ESS GEPARMKY='2023'x creates ESSOUTBN.
-Length of DEPT, TITLE, BUILDING increased to $60.
Thanks to Alexander Raeder, ATOS ORIGIN, GERMANY.
Change 24.226 Variable QWACWLME, Service Class Name, is now kept in the
VMACDB2 PDB.DB2ACCTP dataset for analysis.
Nov 7, 2006
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.225 LPARs with no current share (no current weight points)
VMAC7072 had LPARSHAR=0 in PDB.TYPE70. Those LPARs are treated
Nov 7, 2006 now as Current Share = Initial Share.
Thanks to Rudolf Sauer, T-Systems Enterprise Services GmbH, GERMANY.
Change 24.224 Setting the Clock Back an hour, without quiescing for an
VMAC7072 hour, produces duplicate values of STARTIME in all RMF
VMXG70PR datasets, plus negative execution/elapsed/durations/etc
Nov 7, 2006 in many other records, and in many cases it is impossible
Nov 17, 2006 to even recognize the duplication/overlap.
However, for the 70 and 72 records, adding GMTOFFTM to BY
lists, after SMF70GIE, and to the KEEP= lists, appears to
prevent the duplicate STARTIME values from being summed
(which caused doubling of the values of PARTNCPU and
CPCMUS, among other errors), although duplicates will
still exist in these datasets.
Nov 17: Typo, APPCLAX in KEEP= in VMAC7072 should have
been APPCMAX, which caused APPCMAX to be not kept.
Jan 21: See Change 24.
Thanks to Rudolf Sauer, T-Systems Enterprise Services GmbH, GERMANY.
Thanks to Jim Horne, Lowe's Companies, USA.
Change 24.223 Total Virtual Storage Above the Bar was captured in the
VMAC78 VSDGxxxx variables in TYPE78VS dataset, but the Shared
Nov 7, 2006 bytes were not INPUT. And because IBM reused the VSDG
Dec 19, 2006 prefix for both sets of variables, this change changes
the variables VSDGxxxx to TOBYxxxx for the Total Byte
fields, and now creates SHBYxxxx variables for Shared
byte fields above the bar.
Dec 19: Corrected long line for R783HNAI input.
Thanks to Ralph C. Baechle, John Deere, USA.
Change 24.222 CICS Statistics variables DSGEJST and DSGSRBT were INPUT,
VMAC110 and correctly calculated/formatted, but were not KEPT in
Oct 24, 2006 the CICDS dataset.
Thanks to Helmut Rose, Com-Software, GERMANY.
Change 24.221 -Support for changed field lengths in SAR/EXD SMF type 6
IMACEXD optional data.
Oct 24, 2006
Thanks to Joe Kimberly, Kansas City Southern, USA.
Change 24.220 -Support for NTSMF OBJECT='DATABASE ==> INSTANCES creates
EXNTDATI new DATABASI dataset; previously, those objects were
IMACNTSM output into the DATABASE dataset, which caused nearly-
VMACNTSM duplicate observations.
VMXGINIT -Support for DATABASE object with NRDATA=191.
Oct 25, 2006
Thanks to Paul Billick, Harleysville Insurance, USA.
Change 24.219 The optional ARZGS GSACCT segment for CICS can have any
UTILEXCL length; MXG's INPUT statement expected 8, which caused
Oct 21, 2006 errors when the real length was 12. Now, UTILEXCL prints
the CMODLENG and a message to compare your actual length
with MXG's, and to change IMACICU2 if needed.
Thanks to Richard Hilber, Allgemeines Rechenzentrum GmbH, AUSTRIA.
Thanks to Peter Gschirr, Allgemeines Rechenzentrum GmbH, AUSTRIA.
Change 24.218 Support for NTSM Beta Version 3.0.0.8 (COMPATIBLE), adds
VMACNTSM SUMRYINT and ORGANIZN to NTCONFIG dataset.
Oct 18, 2006
Change 24.217 If you want to process on the CICSTRAN data to create the
ASUMUOW PDB.ASUMUOW dataset without reading DB2ACCT, when there
Oct 18, 2006 are observations in DB2ACCT, you can use
%INCLUDE SOURCLIB(BUILDPDB);RUN;
%LET MACKEEP=
MACRO _NOOBS % MACRO _YESOBS % ;
MACRO _LDB2ACC WORK.DB2ACCT %
;
%INCLUDE SOURCLIB(ASUMUOW);
and MXG will use only CICSTRAN as input to PDB.ASUMUOW.
Thank to Christian Hodel, SwissCom, SWITZERLAND.
====== Changes thru 24.216 were in MXG 24.08 dated Oct 18, 2006=========
Change 24.216 Using SUPPRESS with TYPETMNT failed; logic in UTILBLDP
UTILBLDP didn't protect non-standard-named-tokens, now corrected.
Oct 18, 2006
Thank to Robbie McCOY, Salt River Project, USA.
Change 24.215 Incorrect values for ICMP Statistics variables TSICDUTM
VMAC119 thru TSICOUAR, because -3 was incorrectly subtracted
Oct 18, 2006 twice from OFF11905 when subtype 6 logic was added.
Thank to Thomas Heitlinger, Fiducia, GERMANY.
====== Changes thru 24.214 were in MXG 24.08 dated Oct 17, 2006=========
Change 24.214 Processing z/OS 1.6 with SPG processing enabled failed
ASMRMFV with an 0C4, as there were no SPG records in z/OS 1.6.
Oct 16, 2006 Correction bypasses SPG for old versions.
Thank to Betty Wong, Bank of America, USA.
Change 24.213 Variable MCDFBID is now formatted HEX8. vice HEX4.; the
VMXGHSM field was INPUT as PIB4.
Oct 16, 2006
Thank to Sam Bass, McLane Company, USA.
Change 24.212 Support for NetSpy Version 11 was added in August, 2005,
VMACNSPY when test data validated that records were unchanged.
Oct 16, 2006
Thank to Brian Conway, IBM Global Services, CANADA.
Change 24.211 INVALID DATA messages for SCBGN, SYSIUL, SYSCIU because
VMACQACS MXG had &NUM vice &PD, and incorrect lengths for those
Oct 15, 2006 QAPMSYST variables.
Thanks to Jim Wertenberger, Antares Solutions, USA.
Change 24.210 Support for SMF 99 Resource Group section now creates new
EXTY99RG TYPE99RG dataset.
IMAC99
VMAC99
VMXGINIT
Oct 13, 2006
Thanks to Claude Breault, Centre de Services Partages Quebec, CANADA.
Change 24.209 Syntax error corrected; the previous circumvention to run
UTILBLDP as a two step process should no longer be required with
Oct 13, 2006 the Oct 17th edition.
Oct 17, 2006
Thanks to Ralph Gifford, AIG, USA.
Thanks to Bruce Whittington, TIAA-CREF,USA.
Change 24.208 LPAR share variables were destroyed by Dedicated CPUs;
VMAC7072 the test was expanded for their calculation to bypass:
Oct 13, 2006 IF SMF70CIN='CP' AND LCPUSHAR NE 0FFFFX THEN DO;
These variables were impacted if you have Dedicateds:
TOTSHARE TOTSHARC LPARNSW LPARSHAR LPARSHAC
Thanks to Rudolf Sauer, T-Systems Enterprise Services GmbH, GERMANY.
Change 24.207 TYPE72GO CPUTCBTM (and hence CPUTM) will incorrectly have
VMAC7072 included the zAAP CPU time, if zIIP APAR OA13499 was put
Oct 13, 2006 on, but you did not also install the z/OS web-deliverable
FMID JBB722S (or JBB66S9) for that zIIP APAR. The APAR
extended the segment to 576 bytes, adding zIIP fields,
but also two new IFA Service Units in R723CIFA,R723CIFC.
The two IFA fields are created by the APAR, but with only
the APAR installed, they are always zero. IBM says this
is working as designed, that I should only use the new
fields if they are non-zero. Unfortunately, IBM did not
document that "design" feature in the SMF manual!
Prior to the INPUT of R723CIFA/CIFC, MXG created IFAUNITS
from the CPUIFATM, but then the zero in R723CIFA was put
in IFAUNITS, so those service units were not subtracted
from the raw CPUUNITS, causing CPUTCBTM/CPUTM to include
CPUIFATM. This condition can be detected in your data,
and/or corrected in PDB.TYPE72GO with this test/logic:
DATA TYPE72GO;
SET PDB.TYPE72GO;
IF IFAUNITS=0 AND CPUIFATM GT 0 THEN DO;
NFOUND+1;
IF NFOUND=1 PUT 'INCLUDED ZAAP TIME WAS FOUND';
CPUTCBTM=CPUTCBTM-CPUIFATM;
CPUTM=CPUTM-CPUIFATM;
END;
Jan 18: This change in MXG 24.08 was a CRITICAL CHANGE,
and was the final change to the SPLIT70 redesign. For one
site, it corrected negative CPUOVHTM in PDB.RMFINTRV and
the associated error messages RMFINTRV was created that
could occur with MXG 23.23 thru MXG 24.07.
Thanks to Tom Draeger, Aurora, USA.
Thanks to Heimir Hauksson, Barclays Bank, UK.
Change 24.206 Support for NTSMF Version 3.0.0.7 adds two new objects:
EXNTDTBU NTDTBU DTSBUFFU NT DTS.BUFFER USAGE
EXNTDTPL NTDTPL DTSPERFL NT DTS.PERFORMANCE LIBRARY
IMACNTSM
VMACNTSM
VMXGINIT
Oct 11, 2006
Change 24.205 Support for DATABASE ==> INSTANCES object with NRDAT=152.
VMACNTSM Two new variables created in NTSMF dataset DATABASE:
Oct 11, 2006 LOGCKPDP='LOG*GENERATION*CHECKPOINT*DEPTH'
SBPRDRT ='STREAMING*BACKUP*PAGES*READ PERSEC'
Thanks to Paul Billick, Harleysville Insurance, USA.
Change 24.204 Support for IMPLEX Version 4.10 (INCOMPATIBLE, fields are
EXMPLXAR expanded and new ones were inserted), with new variables
IMACMPLX and new IMPLEXAR dataset for the subtype 8 Alert Record.
VMACMPLX Sorts were updated to ensure duplicates are removed.
VMXGINIT
Oct 11. 2006
Change 24.203 If the number of workloads requested to be graphed in the
GRAFWRKX sample program exceeded 20, the program failed, and the
Oct 9. 2006 values for 21,31,41,51,61,71,81, and 91 were not defined.
Change 24.202 -New macro variable &SMFEXIT is added in VMACSMF to each
VMXGINIT statement INFILE &SMF &SMFEXIT .... in preparation for
VMACSMF MXG support for compressed SMF records. Soon, &SMFEXIT
Oct 7, 2006 will name the to-be-provided "INFILE EXIT" that will
Jan 28, 2007 decompress SMF records "on the fly". &SMFEXIT defaults
to blank in VMXGINIT. Stay tuned for a later change.
Note, however, SAS Infile Exits only exist under z/OS.
-While intended for a different purpose, this new macro
variable, since it is inside the MXG INFILE statement,
can be used also to pass INFILE options. In particular,
you can limit the observations that will be READ from the
SMF file, using
%LET SMFEXIT FIRSTOBS=nnn OBS=mmm;
%INCLUDE SOURCLIB(....);
This is very useful for MXG members that have to invoke
PROC SORTs to deaccumulate (like TYPEDB2,TYPEVMXA, etc),
because you can NOT use an OPTIONS FIRSTOBS=mmm OBS=nnn
global statement with those code members; the global will
restrict the INFILE processing, but they then need to be
reset to FIRSTOBS=1 and OBS=MAX prior to the SORTs, and
there is not simple way to do that for these members.
But now, you can use the preceeding example to restrict
the INFILE but not the subsequent PROC SORTs.
Change 24.201 Support for E-Thales Security product's five user SMF
EXTHALCD records (poor choice: they should have created a single
EXTHALEX SMF record and used five subtypes!) creates these seven
EXTHALHS datasets:
EXTHALSA DDDDDD MXG MXG
EXTHALSD DATASET DATASET DATASET
EXTHALSN SUFFIX NAME LABEL
EXTHALVI
IMACTHAL THALCD THALCDS CDS PARAMETER RECORD
TYPETHAL THALHS THALHSMD HSMD ENTRY IN CDS RECORD
TYPSTHAL THALEX THALEXCE DETAIL EXCEPTION RECORD
VMACTHAL THALVI THALVIOL SECURITY VIOLATION RECORD
VMXGINIT THALSA THALSUMA APPL IN SUMMARY RECORD
Oct 5, 2006 THALSD THALSUMD DEVICE IN SUMMARY RECORD
THALSN THALSNAP SRM SNAPSHOT RECORD
Thanks to ??? , Public Bank, MALAYASIA
Thanks to Patrick Yap Chee Keong, SAS Institute, MALAYASIA
Change 24.200 Support for SMF 82 Subtype 22 (TRUSTED BLOCK CREATE CALL)
EXTY8222 creates TYPE8222 dataset.
IMAC82 Variable SMF82SXT in Subtype 21 is now input as numeric
VMAC82 numeric variable, and formated with DATETIME21.2, as the
VMXGINIT time value is TODSTAMP and not the documented $CHAR8.
Oct 10, 2006
Thanks to Greg Burt, 5th3rd Bank, USA.
Change 24.199 -Support for ThruPut Manager Version 6 adds new variables
VMACTPMX for IBM/STK/VTAPE/COPYCROSS virtual tape usage, and new
Oct 5, 2006 "Drive Booking Services":
CAC7IDID CA7INALI JXDBSPR JXDBSUU JXDBSWG JXSERVIC
JXIMPORT VOLVIBM VOLVIBMR VOLVIBMN VOLVSTK VOLVSTKR
VOLVSTKN VOLVVTS VOLVVTSI VOLVVTSN VOLVCPC VOLVCPCO
VOLVCPCM
-Change 24.147 incorrectly inserted NOT in the test for
JBAFF; that NOT is removed, that change text updated.
If the two formats in your IMACTPMX do not correctly
map your SYSPLEX and SYSTEMs, that will cause JBAFF to
be blank, but the original MXG logic is correct.
Thanks to Scott Barry, SBBWorks, Inc.
Change 24.198 Variable INTETIME (Interval End) in TYPE30_6 was wrong
VMAC30 if GMT offset was non-zero; the subtype 6 doesn't contain
Oct 4, 2006 SMF30IST, which was used to calculate GMTOFF30. Now, that
is calculated as GMTOFF30=SMFTIME-INTETIME for subtype 6.
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Thanks to Michel Denervaud, UBS, SWITZERLAND.
Change 24.197 Variables DCVDVTYP DCVDPTYP from the VOLS record are now
VMACDCOL kept in both DCOLDSET and DCOLCLUS datasets, so the type
Oct 3, 2006 of device is known. For example,
DCVDVTYP='3390' DCVDPTYP='33909'
DCVDVTYP='3390' DCVDPTYP='2105'
Thanks to Brian Harvey, Blue Cross Blue Shield of Illinois, USA.
Change 24.196 TYPE1415 INPUT STATEMENT EXCEEDED RECORD with z/OS 1.7
VMAC1415 plus ptf's, or with z/OS 1.8 due to MXG coding error that
Oct 3, 2006 was introduced in Change 24.094 for new PDSE Cache Stats.
Dec 5, 2006 SKIP=SKIP-32; is required in place of the SKIP=SKIP-16
added by Change 24.094 (in MXG 24.04).
Thanks to Diane Eppestine, AT&T, USA.
Thanks to Frank Debree, Dexia, BELGIUM.
Change 24.195 Variables QW0143UR and QW0144UR printed funny values.
VMAC102 They are now FORMATted $HEX12. and input as $CHAR6.
Oct 2, 2006 instead of $EBCDIC6. (required for ASCII execution, makes
no difference when executing MXG on z/OS), like the other
QW0nnnUR Unit Recovery Token variables.
Thanks to Lawrence Stahl, IBM Global Services, USA.
Change 24.194 -CPUTM and QWSnXXXX variables in PDB.DB2STATS Statistics
VMACDB2 dataset was wrong, with large positive or negative values
Sep 29, 2006 due to incorrect login in MXG code.
Oct 10, 2006 -New QWSnZSRB variable, Preemptable SRB Time on zIIP is
now created and kept in the PDB.DB2STATS dataset.
-ADOCDB2 CPU variables were updated to indicate whether or
not they contained zIIP CPU time.
-Variable QWHUCPU is now kept in DB2ACCT.
-zIIP variables QW0231ZI and QW0231ZE for IFCID 231 are
now created and kept in T102S231.
Thanks to Jim Robson, HighMark, USA.
Thanks to John Paul, HighMark, USA.
Change 24.193 Support for 3592 Tape Devices (no change); they have the
VMAC30 same DEVTYPE as the 3590s, so usage will automatically
Sep 27, 2006 be stored in the xxxx3590 variables.
Change 24.192 Using %READDB2, you could not override the output DDNAME
READDB2 using %LET PDB2ACC=DB2ACCT; %READDB2(WANTONLY=ACCOUNT);
Sep 27, 2006 to create observations only in DB2ACCT.DB2ACCT. Now, if
PDBOUT= argument is null, the original _Ldddddd defs will
be used, so the %LETs can be used to changed output DD.
Change 24.191 Support for HP MeasureWare for Windows/NT for Collector
EXMWNTAP Versions C.03.65.00 and C.04.50.00. C.04 has additional
EXMWNTCO variables that will be missing with C.03 data records.
EXMWNTDS These datasets are created:
EXMWNTGL DDDDDD DATASET DATASET
EXMWNTLA SUFFIX NAME LABEL
EXMWNTPR MWNTAP MWNTAPPL HPMWA MWNT APPL RESOURCES
EXMWNTTT MWNTCO MWNTCONF HPMWA MWNT CONFIGURATION
EXMWNTVL MWNTDS MWNTDSK HPMWA MWNT DSK ACTVTY FRM DIS
IMACMWNT MWNTGL MWNTGLOB HPMWA MWNT GLOBAL ACTIVITY
TYPEMWNT MWNTLA MWNTLANS HPMWA MWNT LANS
TYPSMWNT MWNTPR MWNTPROC HPMWA MWNT PROCESS RESOURCES
VMACMWNT MWNTTT MWNTTRAN HPMWA MWNT TRANSACTION TRACKER
VMXGINIT MWNTVL MWNTVOLS HPMWA MWNT VOLUME ACTIVITY
Oct 2, 2006
Thanks to Bobby Greer, Automobile Association of Michigan, USA.
Thanks to Dominik Covens, KBC Bankverzekeringsholding, BELGIUM
Change 24.190 Executing the output of %UTILBLDP as a separate step, if
UTILBLDP you specified both BUILDPDB=YES and EXPDBOUT= text that
Sep 25, 2006 had a %INCLUDE, caused an error deep inside SAS, either
a syntax error, or expression exceeded 64000 bytes error.
If you use %UTILBLDP this way in the two-step process,
then you must add this statement at the first //SYSIN
in the saved output that will be executed:
%LET BLDPOUT= xxxxxx ;
where xxxxx is the text in the EXPDBOUT= argument.
Thanks to Robert Carballo, Office Depot, USA.
Change 24.189 The options NOOPD and NOSPG did not suppress the OPD/SPG
ASMRMFV records, causing OPD or SPG records to be output when you
Sep 25, 2006 had intended to not write them. And, the NOCSR flag was
incorrectly set when NOSPG was specified.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.188 Support for new TNG object from NT and SOLARIS platforms:
EXTNT131 dddddd Dataset Description
EXTSO029 TNT131 NT131 SLM METRICS
IMACTNG TSO029 SO029 CA PROCESS GROUP
VMACTNG and additional variables in AI019, AI022, AI024, and the
VMXGINIT NT035 datasets, and labels were corrected.
Sep 26, 2006
Thanks to Michael Kynch, International Paper, USA.
Change 24.187 ASUM70PR with INTERVAL=HOUR (or any duration) can create
VMXG70PR observations with incorrect DURATM (50 vice 60 minutes,
Sep 23, 2006 which then caused PCTCPUBY and PCTOVHD to be too large),
Oct 8, 2006 because MXG's heuristic test IF FIRST.DURATM to recognize
a new group to store SYSDUR failed when adjacent DURATMs
happened to be identical. That test is enhanced to also
recognize a group when the new LCPUADDR is less than the
old LCPUADDR, a far more robust criteria. This error can
NOT occur with the defauit INTERVAL=DURSET in ASUM70PR,
which does not summarize by time, so this error can occur
only if you have a tailored ASUM70PR member. Five out of
twenty-four intervals were wrong in one day's data, but
only those three variables were wrong; all of the other
data were correct.
-Oct 8: Notes about uninit OLDSTART, OLD70GIE eliminated.
Thanks to Scott Weiner, WPS Insurance Corporation, USA.
====== Changes thru 24.186 were in MXG 24.07 dated Sep 22, 2006=========
Change 24.186 Support for zIIP variables in PDB.RMFINTRV dataset; I had
VMXGRMFI overlooked this addition. MXG 24.07 was redated with the
Sep 17, 2006 change so all of the "mainstream" MXG datasets now have
the additional sets of ZIP/ZIE variables.
Thanks to Jonathan M. Miller5, JohnDeere, USA.
====== Changes thru 24.185 were in MXG 24.07 dated Sep 21, 2006=========
Change 24.185 Support for DMF Product that creates SMF 110 records with
VMAC110 SMFPSRVR=41.1, i.e., CICS/ESA 4.1.1 (from 1994). While
Sep 17, 2006 MXG supported 4.1.0 and 5.1.0, there never was an MXG
site with 41.1, and it may be their creation, as it has a
seventh TCB, while 5.1.0 only had six.
Thanks to Vernon Stanton, Government of South Australia, AUSTRALIA.
Change 24.184 -Variables ORIGWAIT in PDB.TYPE70PR was not populated for
VMAC7072 IFAs and ZIPs, but it is needed so that both the "CPU"
Sep 17, 2006 busy (LCPUPDTM-based) and the "MVS" busy (ORIGWAIT-based)
can be calculated for analysis of logical ready queues.
Now, in the observations with PARTISHN=LPARNUM ("this"),
ORIGWAIT will be populated for SMF70CIN='IFA' or 'ZIP'.
-PDB.TYPE70 existing variables PCTIFBYx and PCTZIBYx are
the "MVS" percentages, but MXG did not create the "CPU"
(LCPUPDTM-based) percentage for IFAs nor ZIPs. Now, new
PCTCIBYx variables are created with the "CPU"/"Logical"
percentages, for the IFA or ZIPs, and variable IFATYPx
identifies if the CPU is an IFA or a ZIP. This permits
the analysis of Logical Ready Queuing for IFAs and ZIPs,
as well as for CPs.
Thanks to Don Deese, Computer Management Sciences, USA.
Change 24.183 Variables Q3STHWIB, Q3STHWIF, and Q3STHWCT are high water
VMACDB2 mark values and should not have been de-accumulated.
Sep 16, 2006 Oct 5: Also, variable QDSTMIN2.
Oct 5, 2006
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Ralph Baechle, John Deere, USA.
Change 24.182 -NDMCPUTM (created from the text string CPUTIME=) had a
VMACNDM few small negatives, because the BY list was insufficient
Sep 12, 2006 to force the correct order for de-accumulation.
Sep 13, 2006 The time sequence within NDMPRCNO was different when
Sep 14, 2006 sorted by NDMTIME vs SMFTIME; each created a different
group of observations with negative NDMCPUTM. Using
the raw NDMCPUTM value in place of time of day appears
of have corrected the negative values; but check your
own data to be sure.
-Change 24.144 created new variable NDMCPU when the DSECT
showed a four-byte "CPU TIMEUSED" field added in NDM 4.3,
but it took us several iterations to INPUT the field from
the right place with the (undocumented) correct decimal,
in part because with NDM 4.5, the first-bit of NZMZFMT is
off, indicating an 8-byte UID, but the record has the
64-byte Expanded UID. I assume it is always present in
the current versions, so MXG now always INPUTs 64-bytes.
And one site's network group validated the MXG NDMCPU
value, so the NDMCPU variable may be valid. Sterling
says the field was populated in Version 4.4.
Thanks to Roger Foreman, Acxiom, USA.
Thanks to David Kaplan, Depository Trust & Clearing Corporation, USA.
Thanks to Rob Hollingum, HSBC, ENGLAND.
Change 24.181 -Support for OPDG3 and SPGG3 RMF III segments required
ASMRMFV updates to ASMRMFV and revision to MXG code to create:
EXZRBOPD ddddd Dataset Descriptino0
EXZRBSPG ZRBSPG ZRBSPG RMFIII STORAGE GROUP AND VOLUME DATA
IMACRMFV ZRBOPD ZRBOPD RMFIII OMVS PROCESS DATA TABLE
VMACRMFV -Support for zIIP data added to ASIG3 segment:
VMXGINIT ASIMCDLY='MULTI STATE*PROCESSOR*DELAY*PCT'
Sep 12, 2006 ASIMCUSE='MULTI STATE*PROCESSOR*USING*PCT'
Sep 16, 2006 ASIPHTZA='PREEMPTABLE*SRB*FOR ZAAPS'
Sep 19, 2006 ASIPHTZI='PREEMPTABLE*SRB*FOR ZIIPS'
ASISDCCP='PCT*DELAYED*BY CP*PROCESSOR'
ASISDCSP='PCT SINGLE STATE*SAMPLES*DELAYED*BY ZIIP'
ASISUCCP='PCT SINGLE STATE*SAMPLES*USING*CP'
ASISUCSC='PCT SINGLE STATE*SAMPLES*USING*ZIIP*ON CP'
ASISUCSP='PCT SINGLE STATE*SAMPLES*USING*ZIIP'
ASITIIP ='ACCUMULATED*ZIIP*TIME'
ASITIIPC='ACCUMULATED*ZIIP*ON CP*TIME'
-Support for new zIIP/zAAP data in RCDG3 segment:
RCDHST ='HIPERSPACE*CPU*TIME'
RCDIFACP='ZAAP*SERVICE*UNITS*ON CP'
RCDIFASU='ZAAP*SERVICE*UNITS'
RCDIFAT ='ZAAP*SERVICE*TIME'
RCDIFCT ='ZAAP*SERVICE*TIME*ON CP'
RCDIIT ='IO*INTERRUPT*CPU*TIME'
RCDRCT ='REGION*CONTRAL*TASK*CPU*TIME'
RCDSUPCP='ZIIP*SERVICE*UNITS*ON CP'
RCDSUPSU='ZIIP*SERVICE*UNITS'
-Support for new zIIP/zAAP data in CPUG3 segment:
CPUIFCOL='ACCUM*ONLINE*ZAAPS'
CPUIFCON='ZAAPS*ONLINE*AT END'
CPULOGIF='ZAAP*LOGICAL*CPU*TIME'
CPULOGZI='ZIIP*LOGICAL*CPU*TIME'
CPUONTIF='ACCUM*ZAAP*ONLINE*TIME'
CPUONTZI='ACCUM*ZIIP*ONLINE*TIME'
CPUPHYIF='ZAAP*PHYSICAL*CPU*TIME'
CPUPHYZI='ZIIP*PHYSICAL*CPU*TIME'
CPUZICOL='ACCUM*ONLINE*ZIIPS'
CPUZICON='ZIIPS*ONLINE*AT END'
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.180 Labels for IFATYPnn now contain IFA, ZIP, and CP text.
VMAC7072 Labels for SMF70Q01-Q11 were misleading, implying the.
Sep 11, 2006 values were cumulative, but they are discrete percents
when In-Ready WAS N+1, rather than In-Ready LE N+1.
Thanks to Don Deese, Computer Management Sciences, USA.
Change 24.179 Cosmetic. Labels for HSM datasets HSMWWFSR and HSMWWVOL
VMACHSM were not propagated in their _Sdddddd dataset sort macro.
Sep 11, 2006
Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM.
Change 24.178 Support for IRRHFSU unload utility; Unix System Services
EXRAC900 for z/OS file-permissions are a "IRRDBU00-format" RACF
EXRAC901 0900-0903 records. While these new records contain only
EXRAC902 ASCII data, and the IRRDBU00 records contain only EBCDIC,
EXRAC903 this implementation supports either file or concatenation
IMACRACF of both record types, and can be executed under ASCII or
VMACRACF EBCDIC SAS systems. New datasets created are these:
VMXGINIT dddddd Dataset Description
Sep 10, 2006 RAC900 RACF0900 USS RACF BASIC RECORD
Sep 26, 2006 RAC901 RACF0901 USS RACF FILE ACCESS
RAC902 RACF0902 USS RACF DEFAULT ACCESS
RAC903 RACF0903 USS RACF DIRECTORY DEFAULT ACCESS
-Sep 26 Variables RECNR/RECTYPE added to RAC09xx datasets.
Variables GRNAME GRMEMBAL INTRNVOL input length expanded.
Variable ATTRIBS created for RACF0200
Variable TYPE0901 rename GRPORUSR.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Aimee Steel, Euroclear, BELGIUM.
Change 24.177 DB2 Statistics ID=100 SUBTYPE=0 caused INPUT EXCEEDED if
VMACDB2 there is more than one QLST segment, and LENQLST=0 in the
Sep 8, 2006 triplets, which is IBM's new way to read the length field
at the OFFQLST offset. But this record is in error; its
length field contains 176, when the actual segment length
is 178 bytes; this LENxxxx field does not contain itself,
but in all other LENxxxx=0 segments, the length at the
OFFxxxx contains the 2 byte of that field. Circumvention
code was added to protect the QLST segment for the
unexpected (incorrect?) length field value.
Thanks to Ray Dunn, CIGNA, USA.
Change 24.176 DB2 Statistics variable QISTRHIG was incorrectly DIF()'d;
VMACDB2 it is a maximum value, and is not accumulated, so that
Sep 8, 2006 variable is no longer deaccumulated.
Thanks to Steve Morris, State of Ohio BWC, USA.
Change 24.175 For PDB.ASUMTAPE with STATUS='TY21ONLY', the DSNAME field
ASUMTAPE should be blank, but it was populated with a DSNAME from
Sep 7, 2006 a prior job. Now, it will be blank as expected.
Thanks to Geoges Rondeau, Amicam, FRANCE.
Change 24.174 The new Release 4.3 fields, including NDMCPU and NDMRIP
VMACNDM were incorrectly INPUT due to undocumented alignment data
Sep 7, 2006 bytes in the record. See Change 24.182.
Thanks to Rob Hollingum, HSBC, ENGLAND.
Thanks to David Kaplan, Depository Trust & Clearing Corporation, USA.
Change 24.173 Documentation only. IBM VMA product incorrectly decoded
IMACACCT SMF ACCOUNTn fields that contained an underscore. APAR
Sep 6, 2006 OA17684 list the ACCOUNTn characters they consider valid:
Letters A thru Z, numbers 0 thru 9, space, period, dollar
sign, asterisk, dash, slash, comma, at-sign, pound-sign
(a/k/a hash mark), equal sign, and now, with that APAR,
an underscore.
Change 24.172 Using %UTILBLDP with EXPDBOUT= that has a %INCLUDE caused
UTILBLDP a syntax error if the output was directly executed; there
Sep 6, 2006 was no error with the output, so running it as a two-step
build-and-then-execute circumvented. See Change 24.190.
Thanks to Robert Carballo, Office Depot, USA.
Change 24.171 CopyCross+HSC caused MXGTMNT Tape Mount Monitor to stop
ASMHSCEX writing SMF records. Apparently, CopyCross alters the
Sep 4, 2006 JFCB, which we use to get the DSNAME of the tape mount,
and apparently the JFCB address in the TIOT is not valid;
MXGTMNT took five internal S0B0 ABENDS, the error from
the IBM service that reads data from SWA (IEFQMREQ) when
the data we've pointed to is not in SWA, and assumed we
had a real problem, and turned the monitor off.
We know that HSC mounts do not go thru the IBM Volume
Mount Exit; we assume in the HSC exit that if we didn't
see it in the IBM exit that it must be HSC controlled,
so we were seeing the CopyCross mounts in the HSC exit.
There doesn't seem to be a way to identify these mounts
as CopyCross, but "asmguy" as figured a way to obtain the
DSNAME so that the abend won't occur, and thus MXGTMNT
will now capture the CopyCross mounts thru HSC exit.
Thanks to Brian Felix, Wachovia Corporation, USA.
Change 24.170 A debugging PUT statement at line 664: IF SMF14TY NOT ...
VMAC1415 is deleted. It was also truncated and had no semi-colon,
Sep 1, 2006 which caused NO MATCHING IF error in TESTIBM in JCLTEST.
Thanks to Bernd Klawa, Stadtwerke Bielefeld, GERMANY.
Change 24.169 Format $MGTMDAC was not built, and $MGTIVSA was wrong;
FORMATS the semi-colon to end the $MGTIVSA format was missing.
Aug 31, 2006 Inserting the semicolon corrected both formats.
Thanks to Nick Johns, Sainsbury's Supermarkets LTD, ENGLAND.
Change 24.168 Variable CPUTYPE was blank in PDB.ASUMCEC (because the
VMXG70PR HOLD7CPT temp variable was not in the RETAIN statement).
Aug 31, 2006 Fortunately, variable CPFCNAME='2084-308' does have the
CPUTYPE in character, but CPUTYPE is now corrected.
Thanks to Curdin Salis Gross, Credit Suisse, SWITZERLAND.
Change 24.167 Support for MEMORY object with NRDATA=35 caused message
VMACNTSM KNOWN MEM OBJECT UNEXPECTED NRDATA/NRNAMES. DELETED
Aug 31, 2006 and MXG skipped the record. NRDATA=35 is now supported.
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 24.166 Support for BMC Mainview for CICS Optional DB2 and CMR.
IMACICDA -The existing IMACICMR for the CMRDATA segment was updated
IMACICMR with four new pairs of counts/times variables for ADABAS,
IMACICMD DATACOM, IDMS, and MQSeries.
UTILEXCL -The optional CMRDB2 data enabled by BMC BBSAMP CMR$2MCTs
VMAC110 is supported in IMACICMD optional member.
Aug 31, 2006 -UTILEXCL was updated to support the CMRDB2 segment and
Nov 7, 2006 the eight new variables in the CMRDATA segment.
-IMACICDA, used only for non-UTILEXCL segment processing
was updated to add the include for IMACICMD after the
existing IMACICMR, an assumed order that may need to be
reversed, if you don't use UTILEXCL.
-Unrelatedly, variables in Change 24.140 were still in the
FORMAT statement, causing UNITIALIZED VARIABLE ARZGEOS
(harmless), but they are now removed in VMAC110.
Thanks to Jane Dickenson, Santander Produban UK, ENGLAND.
====== Changes thru 24.165 were in MXG 24.06 dated Aug 30, 2006=========
Change 24.165 Variables CPUIFATM and CPUZIPTM are added to TRNDSMFI.
TRNDSMFI
Aug 29, 2006
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 24.164 IMACJBCK (the JOB-check exit for selection of SMF records
VMAC6 by JOB/READTIME/SYSTEM/etc.), for SMF 6 and 26 records,
VMAC26J2 was called before the JESNR had been INPUT. The %INCLUDE
VMAC26J3 was moved until after JESNR has been created, so it can
Aug 28, 2006 be used for selection, as documented in IMACJBCK.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 24.163 Support for z9EC processors. MXG 23.09+ supported 64-bit
FORMATS z/OS on z9 and z9EC; this change is required ONLY if you
Aug 27, 2006 are using a 32-bit z/OS (See Change 24.110 for impact).
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 24.162 Support for NTSMF Version 3.0.0, new objects & variables.
EXNTARMA -Dataset SYSTEM new variable:
EXNTARMP RDYTHPER='READY*THREADS*PER*PROCESSOR'
EXNTASPA -Dataset MEMORY new variables:
EXNTASPN PCTAVLBY='PCT*AVAILABLE*BYTES'
EXNTASPS VTORATIO='V TO R*RATIO'
EXNTCCMQ -Dataset NETWINTR new variable
EXNTCIPS PCTNETBY='PCT*NETWORK*UTILIZATION'
EXNTIPV6 -Dataset DTSCPU new variables
EXNTNECD DTCPNCOS='SUPPORTED*CORES'
EXNTNECE DTCPNCOA='ACTIVE*CORES'
EXNTNECI -Dataset BLKBERRY has new instance variable, if there is
EXNTNECJ more than one blackberry server:
EXNTNECL BLKBINST='INSTANCE*NAME*FOR*ANTIGEN SCAN'
EXNTNECM -Datasets MSQBUFMG and SQLBUFMG no longer populate the
EXNTNECR variable CACHSIZE, although it will continue to exist
EXNTNECS in MXG with a missing value.
EXNTNECT -Dataset MSQGENST and SQLGENST new variables:
EXNTPSPI ACTMPTBL='ACTIVE TEMP TABLES'
EXNTSAAL TMTACRDT='TEMP TABLES CREATION RATE'
EXNTSAJO LOGLCONN='LOGICAL CONNECTIONS'
EXNTSAJS TRANSACT='TRANSACTIONS'
EXNTSAST NATOMYRT='NON-ATOMIC YIELD RATE'
EXNTSQBA MARSDEAD='MARS DEADLOCKS'
EXNTSQBN HTTPAURQ='HTTP AUTHENTICATED REQUESTS'
EXNTSQBR SOAPMTRQ='SOAP EMPTY REQUESTS'
EXNTSQBS SOAPSQRQ='SOAP SQL REQUESTS'
EXNTSQCA SOAPMEIN='SOAP METHOD INVOCATIONS'
EXNTSQCL SOAPWSRQ='SOAP WSDL REQUESTS'
EXNTSQCT SOAPSEIR='SOAP SESSION INITIATE REQUESTS'
EXNTSQCY SOAPSETR='SOAP SESSION TERMINATE REQUESTS'
EXNTSQES PROCBLKD='PROCESSES BLOCKED'
EXNTSQPC TMTADEST='TEMP TABLES FOR DESTRUCTION'
EXNTSQSP EVNODLDR='EVENT NOTIFICATIONS DELAYED DROP'
EXNTSQSR TREVBIQU='TRACE EVENT NOTIFICATION QUEUE'
EXNTSQST SQTRPRLW='SQL TRACE IO PROVIDER LOCK WAITS'
EXNTSQWS -Dataset MSQLOCKS and SQLLOCK new variable:
EXNTTCV6 LOKTIMEO='LOCK*TIMEOUTS'
EXNTUDV6 -Dataset MSQLATCH and SQLLATCH new variables
IMACNTSM SUPRLACN='NUMBER OF*SUPERLATCHES'
VMACNTSM SUPRPRRT='SUPERLATCH*PROMOTIONS*PER SEC'
VMXGINIT SUPRDERT='SUPERLATCH*DEMOTIONS*PER SEC'
Aug 26, 2006 -Dataset MSQACCES and SQLACCES new variables
DEDRROST='DEFERRED DROPPED ROWSETS'
DRROCLRT='DROPPED ROWSET CLEANUPS/SEC'
DRROSKRT='DROPPED ROWSETS SKIPPED/SEC'
DEDRAUS ='DEFERRED DROPPED AUS'
AUCLUPRT='AU CLEANUPS/SEC'
AUCLBART='AU CLEANUP BATCHES/SEC'
FACLBART='FAILED AU CLEANUP BATCHES/SEC'
USTRPACO='USED TREE PAGE COOKIE'
FATRPACO='FAILED TREE PAGE COOKIE'
USLEPACO='USED LEAF PAGE COOKIE'
FALEPACO='FAILED LEAF PAGE COOKIE'
LOPRCRCN='LOBSS PROVIDER CREATE COUNT'
LOPRDECN='LOBSS PROVIDER DESTROY COUNT'
LOPRTRCN='LOBSS PROVIDER TRUNCATION COUNT'
LOBHCRCN='LOBHANDLE CREATE COUNT'
LOBHDECN='LOBHANDLE DESTROY COUNT'
BYLOCRCN='BY-REFERENCE LOB CREATE COUNT'
BYLOUSCN='BY-REFERENCE LOB USE COUNT'
PUOFROCN='COUNT PUSH OFF ROW'
PUINROCN='COUNT PULL IN ROW'
LOREAHCN='COUNT LOB READAHEAD'
-Dataset MSQSTATS and SQLSTATS new variables:
FRCPRMRT='FORCED*PARAMETERIZATIONS*PER SEC'
SQLATTRT='SQL*ATTENTION*RATE'
-And support for these 37 new objects:
DDDDDD DATASET OBJECT
NTARMA ASPNET ARMTECH APPLICATION
NTARMP ASPNETAP ARMTECH PROCESS
NTASPN ASPNET ASP.NET
NTASPA ASPNETAP ASP.NET APPLICATIONS
NTASPS ASPNETSS ASP.NETSTATESERVICE
NTCCMQ CCMSGQUE CCM MESSAGE QUEUE
NTCIPS CITRIXPS CITRIX METAFRAME PRESENTATION SERVER
NTNECD NETCLRDT .NET CLR DATA
NTNECI NETCLRIN .NET CLR INTEROP
NTNECJ NETCLRJI .NET CLR JIT
NTNECL NETCLRLO .NET CLR LOADING
NTNECT NETCLRLK .NET CLR LOCKSANDTHREADS
NTNECM NETCLRME .NET CLR MEMORY
NTNECS NETCLRSE .NET CLR SECURITY
NTNECE NETCLREX .NETCLREXCEPTIONS
NTNECR NETCLRRE .NETCLRREMOTING
NTIPV6 IPV6 NT IPV6
NTSAAL SAALERTS SQLAGENT:ALERTS
NTSAJS SAJOBSTP SQLAGENT:JOBSTEPS
NTSAJO SAJOBS SQLAGENT:JOBS
NTSAST SASTATS SQLAGENT:STATISTICS
NTSQBA SQLBRKAC SQLSERVER:BROKER ACTIVATION
NTSQBN SQLBUFND SQLSERVER:BUFFER NODE
NTSQBR SQLBRDBM SQLSERVER:BROKER/DBM TRANSPORT
NTSQBS SQLBRSTA SQLSERVER:BROKER STATISTICS
NTSQCA SQLCATMD SQLSERVER:CATALOG METADATA
NTSQCL SQLCLR SQLSERVER:CLR
NTSQCT SQLCURTO SQLSERVER:CURSOR MANAGER TOTAL
NTSQCY SQLCURTY SQLSERVER:CURSOR MANAGER BY TYPE
NTSQES SQLEXECS SQLSERVER:EXEC STATISTICS
NTSQPC SQLPLNCA SQLSERVER:PLAN CACHE
NTSQSR SQLSQLER SQLSERVER:SQL ERRORS
NTSQSP SQLSPIPE SQLSERVER:SSIS PIPELINE
NTSQST SQLTRANS SQLSERVER:TRANSACTIONS
NTSQWS SQLWAITS SQLSERVER:WAIT STATISTICS
NTTCV6 TCPV6 NT TCPV6
NTUDV6 UDPV6 NT UDPV6
-The _UNTDISC logic to recognize new DISCOVERY record was
revised to protect multiple systems (data with very old
and new NTSMF interleaved caused variable DISCOVRY to not
always be incremented; now, it will always be, but it can
skip a value, which is ok, as it is only for grouping).
-NTCONFIG dataset variable SUMRYVER could be incorrectly
carried forward if you have new and then old NTSMF data.
Thanks to Jim Quigley, CONED, USA.
Change 24.161 Support for i/Series QACS/QAPM AS/400 Release 5.4.0, is
VMACQACS INCOMPATIBLE, because when new data is added, the LRECL
Aug 26, 2006 in your JCL/FILENAME must be changed to read the new data
records. The comments in VMACQACS list the new LRECLs:
File LRECL Change
QAPMDISK 376 +3
QAPMJOBL 1116 +31
QAPMJOBM 542 +31
QAPMLPAR 172 +92
QAPMPOLB 83 +5
QAPMSYSL 3367 +23
QAPMSYST 555 +20
-Dataset QAPMCONF supports GKEY='21' to create new vars:
GDES21 ='GDES21*ASP*CAPACITY*IN*BYTES'
New GDKEYs 'B1' thru 'B5' create GDESB1N-GDESB5N numeric
and GDESB1C-GDESB5C character variables, awaiting doc to
properly label them.
-Dataset QAPMDISK new variables:
DSRDT ='RAID TYPE?*0=RAID 5*1=RAID 6'
DSIOPF ='MANAGED*BY IOP?*0=NO*1=YES'
DSCAT ='DISK*UNIT*CATEGORY?*0=NO*1=EXTERNAL'
-Dataset QAPMJOBM and QAPMJOBL new variables:
JBACPU ='ACCUMULATED*JOB CPU*TIME'
JBIPAF ='IP TYPE*02X=IPV4*18X=IPV6'
JBIPAD ='IP ADDRESS BINARY'
JBIPPT ='IP PORT*NUMBER'
-Dataset QAPMSYS and QAPMSYSL and QAPMSYST new variables:
SYVCPU ='VIRTUAL*PROCESSOR*TIME*CONFIGURED'
SYDPCH ='TOTAL*DISPATCH*TIME'
SYSHRF ='SHARED*PROCESSOR*FLAG 0=NO*1=YES'
-Dataset QAPMPOLB new variables:
POUNAL ='UNALLOCATED*POOL*SPACE'
-Dataset QAPMSYSL variables previously overlooked:
SYNUAL SYIFTA SYSPTU SYCTA SYUTA SYNUTC SYNPLU SYNPLA
-Dataset QAPMLPAR new variables decoded, but not yet
tested with data.
LPDDTM ='DATETIME*WHEN DISK*DATA WAS*COLLECTED'
LPCAP ='TOTAL*DISK*CAPACITY'
LPAVL ='TOTAL*DISK*CAPACITY*AVAILABLE'
LPBSY ='DISK*BUSY*TIME'
LPRSP ='DISK*RESPONSE*TIME'
LPRDS ='DISK*READ*COMMANDS'
LPWRTS ='DISK*WRITE*COMMANDS'
LPDISK ='NUMBER OF*SELECTED*DISKS'
LPMEM ='TOTAL*MEMORY*IN SYSTEM'
Thanks to Jim Wertenberger, Antares Management Solutions, USA.
Thanks to Tim Follen, Antares Management Solutions, USA.
Change 24.160 -NDMCPUTM could still be wrong, if the NDMLENPA/NDMLENSA
VMACNDM field lengths were more than the arbitrary $VARYING48 I
Aug 25, 2006 chose, thinking ACCT data would be an MVS 44-byte account
field, but the "ACCT" data is text. With lengths of 89
I arbitrarily increased the length to 256 byts, but, more
more importantly, longer lengths are protected.
-The INPUT for NDMCPUTM itself was revised to validate
that CPUTIME= text exists immediately prior to the INPUT
location.
-Code was revised to be independent of the order of the
four optional segments (SVOL,PVOL,SACCT,PACCT).
-NDMOFF43 and NDMLEN43 logic was removed, as the segment
is always present in current NDM-Connect Direct records.
-Some CT records contain nonzero NDMCTDOF (*P.DTOTAL) that
is the offset to an 80-byte "TOTALS (IF RESTARTED)" area,
from which I create NDMTOT01-NDMTOT20 variables, pending
finding documentation of what these totals are.
-Invalid date/times in 'MC' record is under investigation.
Thanks to David Kaplan, Depository Trust & Clearing Corporation, USA.
Change 24.159 Support added for CICS Statistics Intervals option values
VMXGCICI of TWOHOUR, FOURHOUR, and EIGHTHR.
Aug 25, 2006
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.158 Attempting to use MACRO _VTY30UV to DROP variables caused
EXPDB30V ERROR: VARIABLE EXCP2305 NOT FOUND; you cannot use that
Aug 23, 2006 macro to drop variables from PDB.SMFINTRV. Furthermore,
you must use BUILDPDB, BUILDPD3, or ONLINTV to create the
PDB.SMFINTRV dataset, as only those programs have logic
that combines the MULTIDD='Y' observations into a single
PDB.SMFINTRV observation; while %INCLUDE of TYPS30 does
create a dataset named PDB.SMFINTRV, that dataset will
still have multiple MULTIDD='Y' observations.
But, you can instead use the EXPDB30V exit member and use
a DROP statement to drop variables from the summarized
PDB.SMFINTRV dataset.
Thanks to Colin Bowen, CSC, SOUTH AFRICA.
Change 24.157 Analysis example to identify all jobs/STCs that allocated
ANALDEVN a DEVNR range or a DEVICE types, by creating only the
Aug 23, 2006 TYPE30_D dataset for selected DEVNR/DEVICEes.
Thanks to Yaohua Hu, ISO, USA.
Change 24.156 Corrections to reported ANALDB2 errors/omissions:
ANALDB2R -"STMT #: 4040 was printed instead of the correct 16448
Aug 21, 2006 for the statement number.
Thanks to ???, ???, ???
Change 24.155 The CICSBAD dataset added by Change 23.312 could contain
CICSBAD legitimate transactions; the test for PROGRAM='########'
EXCICBAD previously identified invalid CICS transaction names that
Aug 21, 2006 did not have a program name (i.e., typo'd TRANNAME).
However, some sites have chosen to use ######## to make
their transaction routing easier, which caused millions
of transactions to be output to CICSBAD, when this site
wanted them output to CICSTRAN. MXG's test for EXCICBAD
IF PROGRAM='########' OR
SUBSTR(TRANFLAG,6,1)='......1.'B THEN DO;
will %INCLUDE the EXCICBAD exit, so you can tailor the
code in your EXCICBAD member to decide which, if any,
transactions are output to CICSBAD or to CICSTRAN.
In this particular case, the site observed that all of
their TOR regions' transactions had PROGRAM='########',
but they also all had RSYSID NE '00000000'X, so the site
could use this logic in their EXCICBAD tailoring member:
IF PROGRAM='########' AND RSYSID NE '00000000'X THEN DO;
OUTPUT _WCICTRN;
END;
ELSE DO;
OUTPUT _WCICBAD;
END;
to output real bad to CICSBAD and the rest to CICSTRAN.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 24.154 -ERROR: VARIABLE THREADTY NOT FOUND if both DB2ACCT and
ANALDB2R ASUMDB2A existed in the "PDB" with PMACC03/PMACC04=YES.
Aug 18, 2006 The PMACC03 and PMACC04 reports require detail data, but
the logic incorrectly used ASUMDB2A.
-In addition, references to ASUMDB2P dataset are commented
out, as that dataset does not (yet?) exist.
Thanks to Steve Olmstead, Northwestern Mutual Company, USA.
Change 24.153 Support for EMC's Centera Mainframe HSM Migrator user SMF
EXCMHMEV records. New CMHMEVNT dataset for each recall or migrate
IMACAAAA with start, end, and elapsed duration, dataset size, and
IMACCMHM attributes of the dataset.
TYPECMHM This support is preliminary, as both the contents of the
VMACCMHM new SMF record, and how MXG handles the data, may be
VMXGINIT changed when user's get their hands on the new product
Aug 18, 2006 and its SMF data.
Change 24.152 SMF 80 INPUT STATEMENT EXCEEDED RECORD LENGTH because MXG
VMAC80A did not protect $VARYINGnn lenmm for the case when lenmm
Aug 18, 2006 was greater than nn. While many RACF fields have a true
Oct 13, 2006 maximum nn (like 44 for DSNAMEs), some fields were INPUT
with $VARYING200. because no max was known or documented.
And 200 was used because SAS V6 was limited to 200 bytes
for character variables. But MXG no longer executes with
SAS V6, so all of the $VARYING200. are now $VARYING255,
and they are all protected if the text exceeds 255, with
a message and hex dump on the log printed if the length
exceeds MXG's expectation. Fields protected: RACF263,
RACF295, RACF298, TOKDANAM TOKHOME, TOKPROG, and TOKLDAP.
This was tested in Aug, but VMAC80A was not updated until
October.
Thanks to Kim Nguyen, National Australia Bank, AUSTRALIA.
Change 24.151 The _VMINPUT macro, to read z/VM MONWRITE data converted
VMACVMXA from it's native RECFM=U to RECFM=VB, did not include the
Aug 18, 2006 IMACVMXA member nor execute the &MACVMXA macro variable.
Thanks to Steven Clark, DHL, USA.
Change 24.150 Typo in the KEEP= list for dataset HURN49, and the label
VMACHURN statement had HU47BJOB and HU47BSTP, instead of correct
Aug 17, 2006 names of HU49BJOB and HU49BSTP, added by Change 20.248.
Thanks to Colin Bowen, CSC Computer Sciences, SOUTH AFRICA.
Change 24.149 -New variables in VTCS Subtype 15 are now decoded:
VMACSTC STC15CTP='*S-CART*OR*E-CART?'
Aug 17, 2006 STC15LRI='HSTRESIDENCY*RECALL OR*CREATE?'
Aug 21, 2006 -The _VSTCV13 keep list now keeps STC13MRC instead
of STC15MRC.
Rudolf Sauer, T-Systems, GERMANY.
Change 24.148 Variable DATECLN was not converted from the raw record's
VMACTMS5 cyyddd format, so the julian date of 2004241 printed as
Aug 17, 2006 104241. Now, like other TMS dates, DATECLN is converted
to yyyyddd format.
And if you need to see that as a "real date", you can
use CLNDATE=DATEJUL(DATECLN);
FORMAT CLNDATE DATE9.;
and see that 2004241 julian was 28AUG2004.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 24.147 -Variable JBAFF in dataset TPMJBAFF was blank when it
VMACTPMX should have been populated, and populated when it should
Aug 16, 2006 not have been; the IF test missing the NOT now is coded:
IF SYSAFF NOT = : TPMXTEST THEN SYSAFF=' ';
NOTEBENE: THIS AUG CHANGE WAS WRONG, THE NOT DOES NOT
BELONG, AND THE CODE WAS CORRECTED IN CHANGE 24.199.
The two FORMATS in your IMACTPMX must match your SYSPLEX
and AFFINITY systems, for JBAFF to be correct. The MXG
logic was originally correct, and now is after Oct 5.
-Variables UMANUAL, UME, UMB now all contain "MANUAL" in
their labels.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 24.146 The TRANSLATE(TRANSACT,' ','00'x) statement was relocated
VMACTMO2 so both TRANNAME and TRANSACT have those nonprintable
Aug 15, 2006 characters changed to blanks. TRANSACT was named from
the Landmark DSECT when TYPEMONI was written, but now,
with hindsight, I should have use TRANNAME as the name
for all Transaction Names. TRANNAME was added to the
MONITASK dataset because CICSTRAN users expected it when
they switched to TMON for CICS.
Thanks to Salis Gross Kurdin, Credit-Suisse, SWITZERLAND.
Change 24.145 Support for optional PRPRTYPE='9901' User Log Record in
VMACPRPR Oce's Prisma Print product log records creates new
VMXGINIT dataset PR9901 with variable PRPR9901 containing all of
EXPR9901 the text after ACCOUNT, and variable LEN9901 has the
IMACPRPR length of that text.
Aug 15, 2006
Thanks to Engelbert Smtes, Provinzial, GERMANY.
Change 24.144 Reading NDM Log records (instead of SMF format), record
VMACNDM NDMRTYPE='RJ' caused INPUT STATEMENT EXCEEDED record
VMACSMF error; the OFFTODSN,OFFPACCT,OFFRSACCT offsets did not
Aug 16, 2006 include +OFFSMF in their calculation (for normal dumped
SMF records, OFFSMF=0, so the logic error was missed,
until the log-format records were read.
-NDM Logs with a single 13-byte '***NO DATA***' record are
now detected and deleted in the _LOGSMF macro defined in
VMACSMF, but only used by TYPENDML to read //LOGSMF DD.
-NDMCPUTM could be wrong and very large, when the VLR data
section was after the VLS data section, because MXG code
expected VLR first; now, the INPUT is reset correctly no
matter which order the segments are found.
Note: Change 24.160 corrected NDMCPUTM.
-Support for new variables that were added by 4.3 to the
NDMCT dataset:
NDMCKPI ='CHECKPOINT*INTERVAL'
NDMCPU ='CPU TIME*OF STEP*VIA*TIMEUSED'
NDMDBPAD='DBCS*PAD*CHAR'
NDMDBSI ='DBCS*SHIFT-IN*CHAR'
NDMDBSO ='DBCS*SHIFT-OUT*CHAR'
NDMDBTAB='DBCS*TABLE*NAME'
NDMRIPCH='INBOUND*OUTBOUND*IP ADDRESS'
NDMRPOR ='OUTBOUND*PORT'
In my small number of test records, the new NDMCPU
CPU time was zero, and NDMCPUTM was always missing.
Further investigation is needed. See Change 24.182.
-Perhaps support for 4.5. There is a bit flag in the DMRCT
DSECT for new fields added in 4.5, but there are no new
data fields described in that DSECT, so I believe this is
all that is required to support NDM/Connect Direct 4.5.
Thanks to Rob Hollingum, HSBC, ENGLAND.
Change 24.143 Format MGPLOT is added to FORMATS; it is used in ANALDB2R
FORMATS to generate text lines for some reports.
Aug 11, 2006
Change 24.142 -PDB.TYPE70 variables SMF70Q00-SMF70Q12 values were wrong,
VMAC7072 because they were missing the factor of 100 to convert to
Aug 11, 2006 percentages, and their labels, starting with SMF70Q04 had
the wrong +n values in the N+n part of the label. Correct
labels are belos (e.g., SMF70Q08 is the percentage of
time when the number of IN-AND-READY ASIDs was between
21 and 30 larger than the number of CPUs that were online
to this z/OS system when this sample was taken):
SMF70Q00='PERCENT*WHEN*IN READY*LE N CP-S'
SMF70Q01='PERCENT*WHEN*IN READY*LE N+1 CP-S'
SMF70Q02='PERCENT*WHEN*IN READY*LE N+2 CP-S'
SMF70Q03='PERCENT*WHEN*IN READY*LE N+3 CP-S'
SMF70Q04='PERCENT*WHEN*IN READY*LE N+4-5 CP-S'
SMF70Q05='PERCENT*WHEN*IN READY*LE N+6-10 CP-S'
SMF70Q06='PERCENT*WHEN*IN READY*LE N+11-15 CP-S'
SMF70Q07='PERCENT*WHEN*IN READY*LE N+16-20 CP-S'
SMF70Q08='PERCENT*WHEN*IN READY*LE N+21-30 CP-S'
SMF70Q09='PERCENT*WHEN*IN READY*LE N+31-40 CP-S'
SMF70Q10='PERCENT*WHEN*IN READY*LE N+41-60 CP-S'
SMF70Q11='PERCENT*WHEN*IN READY*LE N+61-80 CP-S'
SMF70Q12='PERCENT*WHEN*IN READY*GT N+80 CP-S'
-PDB.TYPE70 PCTRDYWT, the percentage of time there were
more READY asids than NRCPUS (used to estimate latent
demand), is calculated from the READY00-READY15 variables
summing READYnn's for nn's GE NRCPU, but there are only
14 READYnn buckets, so PCTRDYWT will always be missing
when NRCPUS is more than 14 in your SYSTEM.
-New variable PCTRDQWT may be used in place of PCTRDYWT,
as it's upper bucket is 80 ASIDs more than your NRCPUS,
and is quite easily calculated directly using
PCTRDQWT=100-SMF70Q00;
but PCTRDQWT is counting the IN-and-READY users, whereas
the PCTRDYWT was counting the READY ASIDs.
-PDB.TYPE70 labels for all of the READYnn variables are
corrected to "READY" instead of "IN READY", and
READY15 ='PERCENT*WHEN 15*OR MORE*READY'
is now that label.
-Observations were output in PDB.TYPE70PR for spare IFAs,
but my intention was not to output any spare segments, so
the test "OR SMF70CIN NE 'CP'" was removed, and now,
only if SMF70ONT NE 0 OR LPARNAME='PHYSICAL' will the
segment be OUTPUT in PDB.TYPE70PR.
Thanks to Jim Horne, Lowe's Companies, USA.
Thanks to Andrew Hebden, Barclay's, ENGLAND.
Change 24.141 Processing of DB2 data written to GTF was inconsistent,
UDB2GTF sometimes failed completely, or sometimes skipped data.
UDB2GTFA -The MXG utility UDB2GTFA, for MXG execution under ASCII
VMACDB2 SAS to convert the 256-byte DB2 GTF records into
Aug 10, 2006 legitimate complete DB2 SMF records from those itty-bitty
pieces, only worked for the first record. Revisions
correct that problem, and added more debugging facilities
to ease validation.
-The UDB2GTF utility for EBCDIC SAS execution was fine;
the only change was to enhance its debugging messages.
-For GTF input, VMACDB2 was resetting OFFSMF back to zero
too early for the 100-1 and 101-1 records, causing the
triplets for QBGN, QTGS, and QLES (DB2STATS) and for
QXPK, QBAC, QTXA (DB2ACCTP only) to be incorrect, which
could cause those variables to either be missing or to
be horiffically wrong, but with no error in either case.
Those triplets are now correctly input with OFFSMF=12 for
GTF, and OFFSMF is now correctly reset only after all of
the triplets have been input.
-For SMF or GTF input, VMACDB2 INPUT the QLES triplet from
the wrong (preceeding) location, causing those statistics
variables to be incorrect. The QLExxxxx variables are
now also labeled.
Thanks to Thomas Heitlinger, FIducia, GERMANY.
Change 24.140 Support for optional user-created CICS fields with
IMACICU1 CMODNAME='ARZGEOS',CMODHEAD='FACHG' (IMACICU1) and
IMACICU2 CMODNAME='ARZGS',CMODHEAD='GSACCT' (IMACICU2).
UTILEXCL The UTILEXCL member must be used to create IMACEXCL
VMAC110 and the comment block in each of the IMACICU1/IMACICU2
Aug 9, 2006 members must be EDITED for those variables to exist.
Aug 10, 2006 -On Aug 9, I noticed that these optional variables
MQGETWTM MQGETWCN MQREQS MQWTCBUS MQONTCBU MQREQUS
created by a user-created CMODNAME='MQSeries' segment,
could be kept in CICSTRAN, when they shouldn't have been
(they were in the "compiler faker" block, not used for
optionals). They were removed from the faker block
today, today when John saw them present and wanted to
know why they were all blank; quite timely!
Thanks to Richard Hilber, Allgemeines Rechenzentrum GmbH, AUSTRIA.
Thanks to John Ferguson, Washington Mutual, USA.
Change 24.139 If there were no observations in TYPETALO but SPINTALO
ASUMTALO had observations, a strange syntax error was generated
Aug 8, 2006 about (LOWTIME='141515...'DT) being invalid due to a
PUT statement without DATETIME21.2 format.
(The actual error occurred in ANALCNCR text, but the
call was from ASUMTALO, which needed the correction.)
Thanks to Edward M. Burns, Blue Cross Blue Shield of Nebraska, USA.
Change 24.138 Incorrect inclusion of DB2PARTY='R' Rollup observations
ANALDB2R in creating accounting summary report caused average
Aug 4, 2006 values to be wrong; the R record was counted as a PLAN
(doubling the denominator when there was one execution).
Also, the in-DB2 elapsed time could be larger than total
elapsed time: ELAPSTM is missing in the R record, so the
average elapsed was one half the base record's elapsed
duration eg: ( 4 + 0 )/2 = 2 hr. avg total elapsed.
But both had QWACASC in-DB2-elapsed time which were then
averaged eg: ( 3 + 2 )/2 = 2.5 hr avg in-DB2 elapsed!
Clearly, including the elapsed and in-DB2 time from the
Rollup record, and counting it as a plan, created invalid
average values in the summary reports; now, for Rollups,
the count of plans is not incremented, and QWACASC is set
to zero in the sum, so the average class 2 elapsed in-DB2
time reflects the base transaction(s).
Thanks to Yaohua Hu, Insurance Service Office, USA.
Thanks to Issac Lukach, Insurance Service Office, USA.
Change 24.137 MXG Variable PRODUCT in the PDB.TYPE70 dataset identifies
VMACSMF "RMF" or "CMF=." as the creator of the 70-79 SMF records.
Aug 3, 2006 To identify CMF from RMF records in case both are being
created, you could test PRODUCT=:'CMF' in each of the
EXTY7xxx exit members, but you can alternatively use this
logic to input the RMF Product Segment header and skip
the CMF records:
%LET MACFILE=
%QUOTE(
IF 70 LE ID LE 78 THEN DO;
INPUT @25+OFFSMF OFFRMFP &PIB.4. /*SMF70PRS*/
@29+OFFSMF LENRMFP &PIB.2. /*SMF70PRL*/
@31+OFFSMF NRRMFP &PIB.2. /*SMF70PRN*/
@;
OFFRMFP=OFFRMFP-3+OFFSMF;
INPUT @OFFRMFP+28 SMF70RV6 &PIB.2. @;
IF SMF70RV6='........1.......'B THEN
PRODUCT='CMF-CPM';
ELSE IF SMF70RV6='.........1......'B THEN
PRODUCT='CMF-IPM';
IF PRODUCT=:'CMF' THEN DELETE;
END;
);
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 24.136 When DB2 V8 option UIFCIDS=YES is used, many text fields
VMACDB2 in DB2 SMF records that used to contain EBCDIC characters
VMACDB2H will instead contain ASCII text, which, when INPUT by MXG
Aug 4, 2006 with $EBCDICnn INFORMAT, creates unprintable text data.
IBM puts %U in the DSECTS for these ASCII fields, and
in DSNDQWHS %U is described as UniCode UTF-8, but UTF-8
is just simple ASCII text. A few fields with ASCII text
were already supported in MXG, but with UIFCIDS=YES on,
all of these variables were found to contain ASCII text:
%U Header variables QWHCAID QWHCOPID
%U Package variables QPACCOLN QPACLOCN QPACPKID
%U Location variables QLACLOCN QLSTLOCN
%U in DSNDQMDA only QMDALOCN
%U nowhere, but ASCII: QWACNID
Except for QWACNID, all above have %U in their DSECT and
have offsets to their 128-byte extended area, so they now
must be increased to LENGTH $128. QWACNID was found with
ASCII text, but it is not listed as %U in DSNDQWAC nor
DSNDWMSG, and it has no extended area documented, so it
remains unchanged at LENGTH $16.
IBM sets QWHSFLAG='80'x if the %U fields contain Unicode,
and MXG sets variable DB2UNICD='Y' (now kept in DB2ACCT
and DB2ACCTP) to conditionally INPUT these fields as
EBCDIC or ASCII, so the resultant variable will always
contain printable characters.
While these %U variables must be LENGTH $128, MXG's sets
COMPRESS=YES to compress out those blanks, and so there
should not be any increase in disk space required.
This change supports all of the %U fields in the SMF 100
(Statistics) and SMF 101 (Accounting) records, and in the
DB2 Header for all DB2 SMF records, but there are many
other %U fields in the DB2 Trace IFCIDS that are written
in SMF 102 records; these will also eventually be fixed,
initially on an I-have-this-trash-in-this-IFCID basis.
Thanks to John Hammond, Texas State Comptroller of Public Accts, USA.
Change 24.135 XAM variables from the MTRSYS segment, starting with the
VMACXAM SYSTMID (system) variable were all incorrect; the +2 that
Jul 30, 2006 skip 2 bytes before SYSTMID was INPUT do not exist, and
that statement was removed by this change. These are the
variables that were wrong:
CPUCAPAB CPUCFGCT CPUCFGCX CPUCHAR CPUCOUNT
CPUCOUNX CPUDEDCT CPURESVD CPURESVX CPUSHARD
CPUSTNBX CPUSTNBY DEDCNT IOPCNT LPARCAF
LPARNAME LPNUMBER SCPCAPAB SYSCKVOL SYSMMODL
SYSMPOM SYSMSEQC SYSMTYPE SYSTMID SYSWMVOL
VL3CAF VL3CFGCT VL3COUNT VL3CPNAM VL3DBCT
VL3MNAME VL3RESVD VL3STNBY
Thanks to Mike Salyer, Citigroup Technology Infrastucture, USA.
Thanks to Bob Bates, Citigroup Technology Infrastucture, USA.
Change 24.134 If USEREPRT=COMPAT or USECNTRL=COMPAT was specified, no
VMXGRMFI values were created in any workloads. Change 24.079 had
Jul 30, 2006 removed that option, but a test for this option was left
that caused the deletion of all TYPE72GO obs. Only with
MPRINT turned on was it revealed that the statement
IF SYSTEM NE: 'COMPAT' THEN DELETE; was in the generated
code, so the code assumed that COMPAT was a system name.
Now if COMPAT is specified, and MXGWARN message will be
printed indicating that COMPAT is no longer supported,
and processing then continues.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.133 The IMACKEEP include was relocated so it is now after the
ASUMMIPS macro definitions, so they can be changed. And the MIPS
Jul 30, 2006 factor's comments are revised to now read:
THE MIPS CALCULATION DEFAULT IS A CONSTANT OF 5.8 TIMES MSU.
HOWEVER, THAT IS A SPECIFIC VALUE AT ONE POINT IN TIME FOR
ONE PROCESSOR, AND BY NO MEANS IS THAT A "RECOMMENDED" VALUE.
SINCE 'MIPS' ARE DEFINED BY YOU, AND NOT MXG, YOU CAN USE
WHATEVER VALUE YOU/YOUR-MANAGEMENT DECIDE IS THE APPROPRIATE
CONVERSION FACTOR TO GET MIPS FROM MSU.
THAT'S PRECISELY WHY THE FACTOR IS DEFINED IN THE _MIPSMSU
MACRO, SO YOU CAN CHANGE IT TO YOUR VALUE, AS SHOWN BELOW.
Thanks to Wayne Bell, UniGroup, USA.
Change 24.132 Analysis of DD segment counts was revised to use "new"
ANALDDCN MXG exit facility, instead of the old IEBUPDTE technique
Jul 30, 2006 to tailor the analysis program.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.131 INPUT STATEMENT EXCEEDED RECORD LENGTH error because the
UTILEXCL Omegamon/Candle type 110 dictionary entry is truncated if
Jul 30, 2006 the CMODHEAD field name of the last of their optional
fields is not 8 bytes. The dictionary entry is supposed
to always be fixed (MCTSSDRL=26), but in this case, the
last field name was OMEGDB2 and the last dictionary entry
was only 25 bytes. MXG now tests for the field length
and protects for the invalid dictionary record.
Thanks to Burt.Allen, Harris County ITC, USA.
Change 24.130 Support for Oracle was revised to support only current
VMACORAC versions, so I could eliminate the test for Subsystem.
Jul 22, 2006 Previously, if Subsystem ID changed but MXG's macro was
Dec 19, 2006 not updated, almost all variables were missing. These
ANALORAC pre-V9 variables have always been missing and are now
removed (not KEPT) from the ORACLE dataset:
CPUCICTM CPUSRBTM CPUTCBTM CPUTIMER DDLCOMIT DDLROLLS
ENDSRB ENDTCB ORACMSB PCCOUNT STRTSRB STRTTCB
SWTCHCNT TCBADDR
-Dec 19, 2006: ANALORAC updated to remove references to
the variables that were DROPed.
Thanks to Huug Tempelmans-Plat, CORUS Group, ENGLAND.
Change 24.129 Support for up to 10 CICS ABCODE values in PDB.ASUMUOW.
VMXGUOW The ASUMUOW program logic keeps three sets of ten arrays
Jul 19, 2006 one for transaction name, one for APPLID, one for ABCODE,
which can optionally be kept by adding a KEEP statement
in the TRANUOW macro in your tailored IMACUOW member.
The base variables are TRAN1-TRAN10, PATH1-PATH10, and
new ABEND1-ABEND10.
By default, the first blank ABENDn value is kept in the
ABCODE variable, but you can alter the logic in TRANUOW
as needed.
Thanks to Stan Adriaensen, Axa-Tech, BELGIUM.
Change 24.128 The new ZIP variables from SMF 30s were not kept in the
ASUMDB2A PDB.STEPS and PDB.JOBS variables, but are now added to
BUIL3005 both datasets. And, the DB2ACCT zip variables are now
BUILD005 summarized in ASUMDB2A.
Jul 22, 2006
Thanks to Jim Kovarik, AegonUSA, USA.
Change 24.127 Support for fourth GEPARMKY='4D'x and GEPARMKY='4A'x adds
IMAC6ESS optional variables ESSMAIL5 and ESSMACC1 respectively to
VMAC6 both TYPE6 and TYPE57 datasets. Also, the KEEP= list for
VMAC57 TYPE57 was updated to list all of the possible IMAC6ESS
Jul 19, 2006 variables, which had not been updated since 2004.
Thanks to Alexander Raeder, ATOS ORIGIN, GERMANY.
Change 24.126 Variables NDMPRCNM NDMPRCNO NDMSTEP NDMUNODE are now kept
VMACNDM in the NDMFI dataset, so that NDMFI can be matched to the
Jul 16, 2006 NDMCT record to obtain the full file name.
Thanks to Mary Lou Arredondo, Federal Reserve, USA.
Change 24.125 ZIP variables were not kept in TYPE72GO dataset; IBM had
VMAC7072 used different names in early and later documentation,
Jul 13, 2006 and I was awaiting a reply as to which set was actually
going to appear in the SMF manual, and I expected their
reply would trigger my revision of names, but no reply
was received, and I forgot to go back and add the names
that I had started with. These are the new variables
that are now kept in TYPE72GO dataset for zip data:
R723NFFS CPUZIETM CPUZIPTM R723CIFA R723CIFC R723CSUC
R723CSUP R723SUCU R723SUPD R723SUPU ZIEUNITS ZIPUNITS
But the error was mine, not IBMs; my ESP contact had said
that because it was "only a documentation/naming query,
that I should not expect a fast reply".
Thanks to Scott Wigg, USBank, USA.
Change 24.124 -Warnings ZDATE and ZTIME in DROP/KEEP/RENAME not being
VMXG70PR referenced for the FINL70LP dataset because the call to
Jul 13, 2006 include IMACZDAT to create them was missing. That also
caused those variables to NOT be populated in ASUM70LP,
and also impacted variable SHIFT.
-All four datasets default output token are now consistent
(all use the _LSUxxxx macro token, which has the same
default value, so this should be a transparent change,
but now the actual output agrees with the revised doc in
the comments.
Thanks to Paul Gillis, Pacific Systems Management Pty., AUSTRALIA
Thanks to Ken Jones, Xwave, CANADA.
Change 24.123 The debugging PROC PRINT DATA=R73HOUR; statement was
VMXGRMFI removed.
Jul 13, 2006
Thanks to Tom Kelman, Commerce Bank - Missouri, USA.
Change 24.122 Variable R85FLGS is now decoded for the TYPE85RQ,TYPE85TP
FORMATS datasets in new R85ST74F,R85ST78F variables by formats
VMAC85 $MG085DM and $MG085TM for optical disk and tape mounts:
Jul 13, 2006 VALUE $MG085DM
'80'X='80X:MOUNT NOT REQUIRED'
'40'X='40X:FLIP DISK REQUIRED'
'20'X='20X:MOUNT ON EMPTY'
'10'X='10X:DISMOUNT REQUIRED'
;
VALUE $MG085TM
'80'X='80X:MOUNT NOT REQUIRED'
'40'X='40X:MOUNT ON EMPTY'
'10'X='10X:ATL TAPE USED'
'20'X='20X:DISMOUNT REQUIRED'
;
Thanks to Betra Reeves, Infocrossing, USA.
Change 24.121 Support for IFCID=350, the SQL statement produced by the
VMAC102 parser written during the bind of dynamic or static SQL;
Jul 7, 2006 this IFCID can be activated with Trace Class 32 for 350.
Jul 13, 2006 The IFCID=350 replaces the IFCID=63 record because the
SQL text in the IFCID=63 record was limited to 5000 bytes
and any additional text was truncated. Instead now, DB2
writes multiple IFCID=350 records with 5000 bytes each if
the SQL text exceeds 5000 bytes.
Thanks to Christian Vandenbossche, Societe Generale, FRANCE.
====== Changes thru 24.120 were in MXG 24.05 dated Jul 3, 2006=========
Change 24.120 Internal utility used only in MXG QA revised to exeute on
UTILVREF ASCII or EBCDIC systems; previously, a manually edited
Jul 2, 2006 version was required to run on ASCII.
Change 24.119 Typos introduced in Change 24.064 had _WKBLD instead of
WEEKBL3D _WEEKBLD for the new datasets, causing 180 syntax errors.
WEEKBL3T
WEEKBLDD
WEEKBLDT
Jul 1, 2006
Thanks to Art Hunter, Penn Mutual, USA.
Change 24.118 The INTERVAL=DURSET default is restored in ASUM70PR, as
VMXG70PR it was in MXG 24.03 and earlier, so PDB.ASUM70PR/ASUM70LP
Jul 1, 2006 will again have the same STARTIME as RMFINTRV when both
have DURSET defaults. I changed the default in MXG 24.04
to QTRHOUR because with DURSET, the ASUMCEC/ASUMCELP
datasets sometimes had wrong STARTIME/SMF70GIE/DURATMs,
but 24.04 was needed for its zIIP engine support. Now,
with the other enhancements in 24.111 to support SYNC59
along with DURSET, VMXG70PR has again been revised so the
original MXG default can be restored safely.
Defaults are: INTERVAL=DURSET,CECINTRV=HOUR.
Change 24.117 Variables IFAUNITS IFEUNITS CPUIFATM and CPUIFETM are now
TRND72GO created in the TREND.TRND72GO dataset.
Jun 30, 2006
Thanks to Stan Dylnicki, Royal Bank of Canada, CANDAD.
Change 24.116 z990/2084 CPUs don't have 'IFA' in LPARNAME='PHYSICAL'
VMAC7072 segments, which caused NRIFACPU count in LPAR datasets
VMXGINIT (TYPE70PR,ASUM70PR,ASUMCEC) to be zero. The IFA variables
Jun 29, 2006 in System datasets TYPE70 and RMFINTRV is fine, because
they count the IFAs assigned to each SYSTEM, but RMF 70s
for z990s do not contain the number of installed IFAs in
your CEC (later hardware/software does). So, if you have
IFAs on z990s, you will have to tell MXG how many IFAs
you have, by setting a text value in new macro variable
with a %LET statement, in IMACKEEP or //SYSIN DD stream:
- If you have the same number of IFA engines in all of
your CECs, then you would use this statement:
%LET CECIFANR= %QUOTE( CECIFANR=1; );
which stores the text "CECIFANR=1;" (which is a SAS
statement to set variable CECIFANR to 1), in the macro
variable &CECIFANR. When executed, CECIFANR=1 causes
MXG to change SMF70CIN='ICF' to SMF70CIN='IFA' in that
many LPARNAME='PHYSICAL' segments in each interval;
these are output in the PDB.TYPE70PR dataset.
- If you have different numbers of IFAs in different CECs
you will need to tell MXG how many IFAs you have on
each of your CECs, by CECSER, using this logic:
%LET CECIFANR =
%QUOTE (
CECIFANR=0;
IF CECSER='ABCD' TEHN CECIFANR=1;
ELSE IF CECSER='1234' TEHN CECIFANR=2;
);
so that MXG will change 'ICF' to 'IFA' in the correct
number of TYPE70PR observations.
-Once you have created PDB.TYPE70PR with this change,
you can rerun your %INCLUDE SOURCLIB(ASUM70PR) program
to create the corrected ASUM70PR/ASUMCEC/etc summaries.
-VMXGINIT GLOBALs macro variable CECIFANR with blanks.
Thanks to Jan Bigalke, Allianz, GERMANY.
Change 24.115 CICSTRAN variable WTUNIOTM was not kept when UTILEXCL was
UTILEXCL executed; the logic to calculate it was correct, but the
Jun 28, 2006 added code that is needed in UTILEXCL to KEEP a cacluated
variable was missing in UTILEXCL.
Thanks to Robert Blackburn, Dominion Resources, USA.
Change 24.114 The "bucket" variables S94ADV00-S94ADV95 with the number
ASUM94 of volumes containing 0-5 pct, 5-10, etc, are shifted so
VMAC94 their values match S94AD00-S94AD95, and labels now are:
Jun 28, 2006 S94ADV00='VOLUMES*CONTAINING*0-5PCT*ACTIVE'
S94ADV95='VOLUMES*CONTAINING*95-100PCT*ACTIVE'
Those distribution values were incorrectly SUMmed in the
ASUM94 program; now, their MAX value is output in the
summary dataset.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Change 24.113 The DTF segment was changed, causing invalid data values
VMACOMCI for DTFCKLnn and DTFCNTnn variables (but no error message
Jun 27, 2006 was printed. Segment increased from 140 to 172 bytes,
which now is the expected length.
Thanks to Karl B. Schweitzer, State Street Bank, USA.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 24.112 Variable RESIND is a bit map, now decoded into:
VMAC77 RESIND00='RESOURCE*STILL IN*CONTENTION?'
Jun 27, 2006 RESIND01='SCOPE OF*SYSTEMS(A)*OR SYSTEM(B)?'
RESIND02='OWNER*HAD EXCLUSIVE*OR SHARED?'
RESIND03='FIRST JOB*WAITING*EXCLUSIVE*OR SHARED?'
RESIND04='SECOND JOB*WAITING*EXCLUSIVE*OR SHARED?'
RESIND05='RESOURCE*IS*GLOBAL?'
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.111 RMFINTRV is enhanced to support SYNC59 if INTERVAL=DURSET
VMXGRMFI is specified, provided that your IMACRMFI member _DURSET
VMXG70PR logic does NOT alter the value of STARTIME (i.e., the MXG
VMAC7072 default IMACRMFI is used). With INTERVAL=DURSET the
VMXGINIT STARTIME/SMF70GIE timestamps in RMFINTRV, ASUM70PR,
Jun 27, 2006 ASUM70LP, ASUMCEC, and ASUMCELP will be the original time
Jun 29, 2006 values of your RMF data, and you can now use SYNC59= in
Jul 1, 2006 both RMFINTRV and ASUM70PR members to shift times so the
times in the summary datasets are "exact and pretty".
Change 24.110 Support for z9BC processor CPUTYPE='2096'x, COMPATIBLE if
FORMATS your z/OS is 64-bit. If your z/OS is NOT 64-bit, this
VMAC7072 change is required so that variables SMF70CPA, which
VMXGRMFI becomes CECSUSEC, the SU_SEC value of the hardware CEC,
Jun 27, 2006 will be set by table lookup in the MG070CP format, which
was also updated by this change to contain the 2096 SUs.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
====== Changes thru 24.109 were in MXG 24.04 dated Jun 22, 2006=========
Change 24.109 -ASUMTAPE enhancement for MXGTMNT with IBM Volume Mount
ASUMTAPE Exit enabled now populates these job-level variables:
VMACTMNT ASID INITTIME JOBCLASS LOCLINFO PGMRNAME RACFTERM
Jun 22, 2006 RACFUSER READTIME STEPNAME STEPNR TMNTEXIT
from the first-volume mount, which goes thru that exit
and is captured by MXGTMNT, into subsequent multi-volume
mounts, that do not go thru IBM's exit, and thus are not
captured by MXGTMNT. This enhancement populates the job
variables, but the TAPMNTTM (MXGTMNT monitor mount time
duration) will still be missing in the second and later
multi-volume mounts. However, the new TOTMNTTM added by
Change 24.102, created from MAX of the SYSLOG or MXGTMNT
mount delay, is populated for these multi-volume mounts,
so the new BEGTMNT and ENDTMNT datetime values should now
be used for the start and end times of mount events.
The SYSLOG mount time is earlier than the mount start the
MXGTMNT monitor captures, and the SYSLOG mount verifiy is
later than the MXGTMNT end time, so the new TOTMNTTM is
a more accurate measure of tape mount delay to each job.
-The SORT order of PDB.ASUMTAPE is changed
from BY DEVNR DESCENDING EVENTIME;
to BY DEVNR EVENTIME;
but as the expected SORT order in WEEKBLD/MONTHBLD is
just BY DEVNR
the change from DESCENDING to ASCENDING order should have
no impact and is the more righteous order, anyhow.
-Note that the IBM Volume Mount Exit still misses mounts
issued by some programs: DFHSM, OPC, and DMS jobs have
mounted tapes that MXGTMNT did not see in the IBM exit,
and many of those missed mounts created a type 21 record
with a blank volume serial, and these missed do not have
the standard SYSLOG mount messages. But with those few
exceptions, this iteration of the ASMTAPEE/MXGTMNT
monitor and ASUMTAPE summary program captures all
possible IBM controlled tape mounts, to virtual or real
devices, and populates all possible job-related variables
in ASUMTAPE.
-VMACTMNT correction; SYSLOG records with INVALID MSGID
notes were due to incorrect processing of the IEC235D
WAITING FOR VOLUMES message, so those events were not
output in TYPESYMT dataset. However, as the IEC235D
message does not contain a DEVNR, it cannot be stored
in the PDB.ASUMTAPE dataset.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Paul Naddeo, FISERV, USA.
Change 24.108 Variable TSUDRECD and TSUDXMDA, Datagrams Received/Sent
VMAC119 were incorrectly read as 4-bytes, but they are documented
Jun 22, 2006 as 8 byte binary fields.
Thanks to Al Smye, IBM Canada at PWGSC, CANADA.
Change 24.107 Variable CPUCEPTM is now kept in PDB.STEPS and PDB.JOBS;
BUILD005 it was already included by IBM in CPUTCBTM, but should
BUIL3005 have been kept when created, since BUILDPDB intends to
Jun 22, 2006 keep all of the CPU time component variables.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.106 Heuristic revisions to calculation of WAITTOTM total wait
VMXGUOW time of the constructed PDB.ASUMUOW event; the original
Jun 22, 2006 estimate included WTDISPTM and WTLMIOTM but data suggests
those wait durations are overlapped with other delays.
The total count of wait events WAITTOTL was also revised.
And RCT time should not be included; consider the MRO
TOR/AOR/DOR combination; the transaction starts in the
TOR, moves to AOR, then moves to DOR. While the tran
is not in TOR, the TOR CICSTRAN still clocks RCT wait,
even while the AOR may be waiting on something else.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Thanks to Tom Kelman, Commerce Bank - Missouri, USA.
Change 24.105 Corrections, enhancements for ASUM70PR zIIP and zAAPs.
ASYN70PR -If you had more than one IFA or more than one ZIP, the
VMXG70PR counts NRIFACPU/NRZIPCPU and uptimes IFAUPTM/ZIPUPTM
VMXGDUR in PDB.ASUM70PR and PDB.ASUMCEC summary datasets were
Jun 20, 2006 wrong, but all other IFA/ZIP CPU times were summarized
Jun 22, 2006 correctly, and all of the individual LPAR data values
(LPnXXXX variables in PDB.ASUM70PR/ASUMCEC datasets, and
all of PDB.ASUM70LP and PDB.ASUMCELP datasets) were fine.
-SYNC59 logic (for ex-MICS sites!) was imperfect and did
not always create the expected shifted exact datetime.
-Note: See Change 24.118, which reversed the change in the
default for INTERVAL: The discussion is correct, but
the default was only changed in 24.04, then restored to
the original INTERVAL=DURSET in MXG 24.05.
-The INTERVAL=DURSET default for the summary interval for
PDB.ASUM70PR and PDB.ASUM70LP datasets only works if the
_DURSET macro does NOT change the value of STARTIME. If
the value is changed, there is no way that I can tell the
desired interval, and the logic to build the
PDB.ASUMCEC/ASUMCELP datasets requires knowledge of their
INTERVAL.
DURSET says to use the _DURSET macro definition in
the IMACRMFI member to redefine the STARTIME value,
but if you do change STARTIME therein, I cannot tell
what summary interval you wanted, and if you leave
STARTIME unchanged (MXG's IMACRMFI default) I still
can't tell what is your minimum RMF interval.
The DURSET can still be used to create PDB.ASUM70PR
and PDB.ASUM70LP datasets with their original STARTIME
values, but the PDB.ASUMCEC and PDB.ASUMCELP datasets
may not be completely valie. It may be possible to
figure out a way to safely use DURSET and still have
the correct DURATM values in ASUMCEC, but for now the
safe resolution is to require you to specify the
INTERVAL= and CECINTRV= values in your ASUM70PR member
and then I can build all four datasets without errors.
-Internal VMXGDUR invocations invoke SYNC59=YES only for
the ASUM70PR/ASUM70LP creation; the second invocations
for ASUMCEC/ASUMCELP specify SYNC59=NO because times have
already been shifted.
-Change: Variables IFAWSTTM and ZIPWSTTM are now set to
a missing value in the PDB.ASUM70PR/PDB.ASUMCEC datasets
as they are overlapped wait times across all LPARs that
had an IFA or a ZIP, and really are meaningless totals.
-LPMSUHR was actually per second rather than per hour,
not fixed until Jun 22.
-LPCTBY and LPCTOV were wrong in PDB.ASUM70LP as they were
not divided by LPARCPUS.
-Enhancement: Variables NRIFACPU and NRZIPCPU are added
to the PDB.ASUM70LP and PDB.ASUMCELP dataset, calculated
from IFAUPTM or ZIPUPTM divided by DURATM.
-Some Labels and Formats were revised, including remvoal
of *PCT from the Current and Initial SHARE WEIGHTs.
-This change has been extensively tested but only with Z9
processors that populate SMF70CIN. There may still be
a problem counting IFAs on earlier hardware that did not
populate SMF70CIN.
-VMXGDUR: Variable MXGDURTM is created/dropped for time
intervals and used to reset SMF70GIE after STARTIME has
been SYNC59'd/FLOORed back to start of final interval.
-Jun 22: Variables LPSHARE, LPSHARC, TOTSHARE, TOTSHARC
were sometimes incorrect but the LPnSHARE/LPnSHARC values
were correct.
-SMF70LAC was wrong (zero) in PDB.ASUM70PR and PDB.ASUMCEC
datasets (but LPnLAC values were valid for all LPARs).
Now, the LPnLAC values are summed to create the total of
the 4-hour Average MSU values back into SMF70LAC. But
SMF70LAC isn't an LPAR variable; it comes from the "this
system" segment of the TYPE70 record, and while it is
always valid in per-system TYPE70 & RMFINTRV datasets,
in the LPAR data in PDB.TYPE70PR, SMF70LAC is non-zero
ONLY in the "this system" observations, so this is just
one more variable that requires your ASUM70PR program to
read the PDB.TYPE70PR with data from ALL of your SYSTEMs
to create correct data in the CEC-level summary datasets
PDB.ASUMCEC and PDB.ASUMCELP.
Thanks to Nathan Loewenthal, CitiGroup, USA.
Thanks to Douglas Walter, CitiGroup, USA.
Thanks to Michael Salyer, CitiGroup, USA.
Thanks to Brent Turner, CitiGroup, USA.
Thanks to Tom Koelle, CitiGroup, USA.
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA
Thanks to Tom Kelman, Commerce Bank - Missouri, USA.
Thanks to Deborah L. Soricelli, CIGNA, USA.
Thanks to Ray Dunn, CIGNA, USA.
Change 24.104 BMC CMRDETL data file is created by their CMRCMPW program
TYPE110J but the output format is determined by a control card.
TYPEMVCI When FORMAT=CMR is specified, the output format is the
Jun 19, 2006 decompressed T6E record that MXG's TYPEMVCI processes.
When FORMAT=2.2 or FORMAT=2.2Y is specified, the output
format is an SMF 110 record, but written as RECFM=U that
does NOT contain valid BDW/RDWs, and instead has only a
4-byte record length field; this is the old "DOS JOURNAL"
type 110 format, which is processed by MXG's TYPE110J.
Thanks to Pat Perecca, Pershing, USA.
Change 24.103 Variable QWHCCV was misspelled in READB2 as QWHCCCV,
ADOCDB2 which caused selection by CORRID to fail. The variable
READDB2 was also misspelled in ADOCDB2 documentation.
Jun 17, 2006
Thanks to Julain Smailes, Experian, ENGLAND.
Change 24.102 Documentation: PDB.ASUMTAPE will have zero observations
ASUMTAPE if you do not have any observations in SYSLMNT dataset.
Jun 15, 2006 You must install ASMTAPEE (MXGTMNT) monitor at ML-38 or
later, which captures the SYSLOG mount information, now
required by the ASUMTAPE logic to create PDB.ASUMTAPE.
-New variables BEGTMNT, ENDTMNT, the begin and end times
of each tape mount event, and TOTTMNTM, total duration of
the tape mount are created:
BEGTMNT is SYLMTIME (SYSLOG Mount Start), which is
usually fractions of a second earlier than the
TMNTTIME when MXGTMNT saw the mount start, but
TMNTTIME is used if SYLMTIME is missing.
ENDTMNT is SYL5TIME (SYSLOG IEC705I Label Written) that
is usually fractions of a second later than the
TENDTIME when MXGTMNT saw the mount end, but
TENDTIME is used if SYL5TIME is missing.
TOTMNTTM=ENDTMNT-BEGTMNT, the mount delay to the job.
Change 24.101 Flag variable FSRFALT='WRITTEN*IN*DUPLEX*MODE?' is added
VMACHSM to the HSMFSRTP dataset.
Jun 14, 2006
Thanks to Michael E. Friske, Fidelity Systems, USA.
Change 24.100 Utility to get the ENGINE type of a SAS data library was
VGETENG revised to use PROC SQL instead of VGETOBS, to eliminate
Jun 14, 2006 the annoying MXGWARN that MXGENG datasets doesn't exist.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.099 Format MG116TY for SMF 116 MQSeries type was updated to
FORMATS add 0:INTERNAL TASK and 8:IGQ AGENT values, and to revise
Jun 14, 2006 so now 2:BATCH OR TSO.
Thanks to Scott Barry, SBBWorks, Inc., USA.
Change 24.098 Support for the DCE segment in RACFTYPE 301 segment will
VMAC80A populate TOKDCE variable in the many events that can
Jun 14, 2006 have a DCE segment.
Thanks to Colin Wessels, Unicible, SWITZERLAND
Thanks to Pierre Beda, Unicible, SWITZERLAND
Change 24.097 More than six RACFTYPE=42 CLASS NAME segments caused MXG
VMAC80A to get INPUT STATEMENT EXCEEDED error, the "TRUNCATED
Jun 13, 2006 RECORD FOUND" that was added by Change 24.021. This
change added protection to skip over extra segments for
RACFTYPE 33, 42, and 43 segments.
Thanks to Michael Yuan, University of California Office of Pres, USA.
Change 24.096 Revised STK Exit UX01 protects a local UX01 exit that
ASMHSCEX does not save registers and status. This enhancement is
Jun 13, 2006 for sites that specify SYSPARM(Y) to include their local
UX01 exit in our link-edit step.
Change 24.095 PDB.ASUM70LP variables LPCTBY LPCTOV PCTLPBY PCTLPOV
VMXG70PR were always missing values because the DURATM=SYSDUR
Jun 10, 2006 statement was mis-located, and LPARDUR for PHYSICAL LPAR
was zero, now is set to DURATM*NRPHYCPS.
Thanks to Steve Olmstead, Northwestern Mutual Company, USA.
Change 24.094 Support for APAR OA12857 which adds PDSE Caching stats to
VMAC1415 the type 14/15 SMF records, with these new variables:
Jun 9, 2006 SMF14DRD ='PDSE*DIRECTORY*READ*REQUEST*COUNT'
SMF14DRDH='PDSE*DIRECTORY*READ*HIT*COUNT'
SMF14MCE ='PDSE*MEMBER*CACHE*ELIGIBLE*COUNT'
SMF14MCF ='PDSE*MEMBER*ELIGIBLE*CACHE FULL*COUNT'
SMF14MNC ='PDSE*MEMBER*ELIGIBLE*NOT CACHED*COUNT'
SMF14MRD ='PDSE*MEMBER*READ*REQUEST*COUNT'
SMF14MRDH='PDSE*MEMBER*READ*HIT*COUNT'
SMF14MST ='PDSE*MEMBER*CACHE*STOLEN*COUNT'
But see Change 24.196; it is required to avoid ABENDs.
Change 24.093 New variables added to EDALOGOF dataset:
VMACEDA EDACOMPL='COMP'
Jun 6, 2006 EDAOFA40='FULL*ACCOUNT*NUMBER'
EDAOFID1='SYSPLEX*ID1'
EDAOFID2='SYSPLEX*ID2'
EDAOFPID='POOLED*USERID'
EDAPRTY ='PRIORITY'
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Change 24.092 z/OS 1.8 support (COMPATIBLE).
FORMATS -TYPE30 new EXSRMERR flag variable if SRM is unable to
VMAC108 return the SMF30AIx and SMF30EIx variables, and the
VMAC30 EXCPERR flag for over 4 Billion EXCP logic was revised.
VMAC7072 -SMF30MLS new value 10 decoded by MG030ML format.
VMAC71 -TYPE70 new variables:
VMAC74 SMF70CSC='SEQUENCE*CODE*OF*CONFIGURATION'
VMAC80 SMF70GJT='TIME WHEN*PARTISHN*JOINED*CAPACITY GROUP'
Jun 5, 2006 SMF70GMU='MAXIMUM*LICENSE*UNITS*OF A GROUP'
Jun 22, 2006 SMF70GNM='CAPACITY*GROUP*NAME'
SMF70POM='PLANT*CODE*OF*MANUFACTURE'
-TYPE71 new variables for UIC statistics:
SMF71ULM LOWEST*MINIMUM*SYSTEM*UIC
SMF71ULC LOWEST*CURRENT*SYSTEM*UIC
SMF71UHC HIGHEST*CURRENT*SYSTEM*UIC
SMF71UHX HIGHEST*MAXIMUM*SYSTEM*UIC
SMF71UAM AVERAGE*MINIMUM*SYSTEM*UIC
SMF71UAC AVERAGE*CURRENT*SYSTEM*UIC
SMF71UAX AVERAGE*MAXIMUM*SYSTEMI*UIC
-TYPE72GO new Resource Group Capacity variables
R723GMLP='PERCENT*CAPACITY*OF LPAR?'
R723GMSS='PERCENT*CAPACITY*OF SINGLE*SYSTEM?'
-TYPE72DL new Resource Manager state samples
R723BPMI='BUFFER*POOL*IO*MISSES*SAMPLES'
R723RW05-R723RW15 'RESOURCE TYPE NN SAMPLES'
-TYPE74 new flag variable
IOTMERR ='CONNECT*TIME*IN ERROR?'
-TYPE74CF variable R744VLVL corrected to R744FLVL.
New variable R744FMPC with Plant Code of CF.
New variable R744FSEQ with CF Sequence Number.
-TYPE88 new variable
SMF88GRP='GROUP*VALUE*FOR THE*LOG STREAM'
-TYPE108, new transaction type values in MG108TR format.
-Jun 22: IBM confirmed SMF70GMU is binary, and not the
EBCDIC format in the pre-GA documentation.
Change 24.091 Revision to RMF III VSAM decompression utility corrects
ASMRMFV processing of the ENCG3 table for the ENC option, adds
DOCLRMFV reporting of the RMF III Index usages, and contains the
Jun 2, 2006 CPUG3 record size reduction.
-The CPUG3 Table output record is reduced in size to
contain only the data that is currently documented by
IBM; previously, a large number of LPARs/LCPUADDR could
generate a record that was greater than 32K.
-New optional messages RMFVO28I and RMFV029I report the
usage of RMF III Index; see prolog in ASMRMFV.
-DOCLRMFV documentation of the CLIST is updated.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.090 RMF III RESOURCE TYPE AND USE/WAIT TYPE MISMATCH messages
VMACRMFV caused ZRBUWENQ dataset to be incomplete or wrong; the
Jun 2, 2006 MXG code for REDG3 and UWDG3 segments was revised.
Thanks to Betty Wong, Bank of America, USA.
Change 24.089 MXGWARN: INTERVAL IS NOT A VALID VALUE FOR INTERVAL= may
VMXG70PR occur if you changed the default INTERVAL=DURSET in your
Jun 2, 2006 own %VMXG70PR invocation. The error was due to line 304
which should have had INTERVAL=&INTERVAL, syntax.
Thanks to David J Schumann, Blue Cross of Minnesota, USA.
Change 24.088 Variables QJSTCIWR QJSTLOGW QJSTLSUS QJSTSERW QJSTTHRW
VMACDB2 in the DB2STATS dataset have been wrong since they were
May 30, 2006 added by Change 18.305; the wrong variable name was used
in MXG's deaccumulation logic.
Thanks to Erling Andersen, SMT, DENMARK.
Change 24.087 Auditors requested the values of QW0141AC be formatted,
FORMATS so format $MGD141A now exists and it decodes:
VMAC102 'G'='G:GRANT'
May 30, 2006 'R'='R:REVOKE'
Thanks to Mike Duffy, LLoyds, ENGLAND.
Change 24.086 New variable R783CSSC is a character variable with $HEX2.
VMAC78 format that contains the value of R783CSs, which is a
May 26, 2006 numeric variable with HEX2. format, so that the TYPE78IO
R783CSSC and the TYPE73 SMF73CSS are both characters, so
they can be used without conversion to MERGE the two data
sets by Channel Subsystem ID.
Thanks to Bill Cool, EDS, USA.
Change 24.085 -Invalid values for NDMCPUTM because MXG read only the
VMACNDM first VOLSER in the Receiving or Sending VOLSER list.
May 26, 2006 -New values set for bits in NDMBYTE1 for NDMCOMPR:
NDMCOMPR='T' - COMPACTED?
NDMCOMPR='E' - COMPRS EXT?
NDMCOMPR='X' - DMDSSIOX
Thanks to John Shuck, SunTrust, USA.
Thanks to Srinivas Guntapalli, Citigroup, USA.
Change 24.084 Support for optional CICS fields with CMODHEAD/CMODNAME
IMACICMN values of MSGNAME and MSGTYPE.
IMACICMT
VMAC110
UTILEXCL
May 26, 2006
Thanks to Alan O'Hara, HBOS plc, SCOTLAND.
Change 24.083 Documentation. The ASUM70PR in MXG 24.03 can't summarize
ASUM70PR old PDB libraries built prior to MXG 23.23, because the
May 22, 2006 SMF70GIE variable was NOT kept in all RMF datasets until
Change 23.231. YOu can use ASUM70PR to summarize PDBs
built with 23.23-24.02, but you must add this OPTIONS:
OPTIONS DKRICOND=NOWARN;
%INCLUDE SOURCLIB(ASUM70PR);
Thanks to Jim Horne, Lowe's Companies, Inc., USA.
Change 24.082 RACF formats MG080EV for Event and MG080QU for Qualifier
FORMATS decoding were updated with new values of both Events and
May 22, 2006 Qualifiers.
Thanks to Linda Berkley, DISA, USA.
Change 24.081 -MXG 24.03 did not have ZDATE kept in PDB.ASUM70LP nor in
VMXG70PR PDB.ASUMCELP, which will cause an error if MONTHBLD from
May 19, 2006 24.03 is used, because those datasets were added to the
MONTHLY PDB, but ZDATE is used to select observations.
(The error message only occurs if ALL of your WEEK/DAY
datasets were created by MXG 24.03; if any PDB used in
the MONTH job was created with this change, then that
MONTHBLD run will not fail with an error; however, the
two output datasets will still be incomplete and wrong.)
-Since those two datasets never existed in the MONTH PDB
previously, you could use the prior MONTHBLD until all of
your DAY/WEEK PDBs have been created with this change.
Thanks to Jim Horne, Lowe's Companies, Inc., USA.
Change 24.080 Analysis of MIPS/MSU from SMF 30 and RMF 72 by SRVCLASS
ASUMMIPS adds _SYNC59 macro for sites still stuck with the unwise
May 23, 2006 SYNCVAL(59) SMF option that was only required by MICS and
is unneeded and unwise if you no longer have MICS, and a
new _INTVAL macro so you can change the summary interval.
The default _INTVAL is HOUR, and _SYNC59 is NO.
Thanks to Pat Curren, SuperValu, USA.
Change 24.079 -New NOTYPE74=YES (DEFAULT) option skips PDB.TYPE74 data
VMXGRMFI when creating PDB.RMFINTRV dataset. Only these variables
May 18, 2006 AVGRSPMS DEVACTTM DEVCONTM DEVDISTM DEVPNDTM
SIO74CNT SIO74TAP
in PDB.RMFINTRV come from TYPE74 data, and they are total
across ALL of your DASD devices, so they have very little
value if you have ESCON and FICON channels, or have both
Cache/Non-Cache Controllers, or have different devices;
they will all have missing values with the YES default.
The new default can significantly reduce the run time and
CPU time of your RMFINTRV execution, but if you need the
above variables, specify NOTYPE74=NO in your RMFINTRV
will read the PDB.TYPE74 dataset and populate them.
-Datasets PDB.TYPE72 and PDB.TYPE73P are no longer used as
those datasets now always have zero observations.
-Comments document the only PDB datasets required are
TYPE70 TYPE71 TYPE72GO TYPE74 TYPE75 TYPE78 TYPE78IO.
Thanks to Steve Olmstead, Northwestern Mutual Company, USA.
Change 24.078 All z/VM MONWRITE datasets now have variable SYSTEM, that
VMACVMXA was previously only in the VMMTRSYS configuration dataset
May 18, 2006 from the 1.4 record, so you can combine MONWRITE data and
SORT/REPORT by each of your z/VM SYSTEMs.
Thanks to Barbara Nitz, Deutsche-Boerse, GERMANY.
Change 24.077 Value QLIM and MDC for SAS/ETS product were added to the
FORMATS $MGSASPR format that maps SAS Procedure Name to the SAS
May 17, 2006 product that "owns" that procedure, for the decoding in
the TYPESASU SAS User Record dataset.
Thanks to Len Rugen, University of Missouri, USA.
Change 24.076 -WARNING: VARIABLE CPCFNAME IN THE DROP KEEP RENAME LIST
VMXG70PR HAS NEVER BEEN REFERENCED (and the same warning for the
May 16, 2006 variables SMF70CPA, SYSDUR, MAXCPUS, MINCPUS, SYSSHARE
May 19, 2006 and CURSHARE), fortunately, does NOT impact the output.
These variables were left in DROP statements from an
earlier iteration of the redesign, but were not used in
the DATA steps that produced the warning message.
These messages are not printed using the MXG default
OPTIONS DKROCOND=NOWARN; using DKROCOND=WARN will cause
the above messages to be printed on the log, and if you
set OPTIONS DKROCOND=ERROR, my failure to remove them
will cause your job to fail with ERRORs.
-Variable DURATM in ASUMCELP is again TIME12.2 format.
Thanks to Randy Shumate, LexisNexis, USA.
====== Changes thru 24.075 were in MXG 24.03 dated May 15, 2006=========
Change 24.075 ML-39 of MXGTMNT Tape Mount Monitor enhancements include:
ASMTAPEE - support for the hardcopy message set, which allows for
May 15, 2006 the monitor to capture suppressed SYSLOG messages.
(Previously, if console messages were suppressed,
MXGTMNT didn't capture SYSLOG messages, and there
were zero observations in TYPESYMT dataset.)
- eliminates S0C4 ABEND in IEAQPGTM+01E6, which occurred
only at shutdown of the MXGTMNT task, with no impact
on the monitor's records. Because it was unexpected,
and appeared to be circumvented by changing the SYSOUT
class of the SYSUDUMP DD, IBM Support was invoked, but
their SLIP trap proved the error was, as they had said
before the SLIP trap, in our code!
- provides protection for future z/OS releases which may
enforce the No User Key CSA rule, by eliminating the
use of CSA Key 8 virtual storage in MXGTMNT coding.
While ASMTAPEE requested SP 241 in Key 0, it was
being ignored and the storage was allocated instead
in Key 8, which, while still "legal", is undesired.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Ed Webb, SAS Institute z/OS, USA.
Thanks to Eladio Aviles, Arizona Public Services, USA
Thanks to George Kozakos, IBM Support, AUSTRALIA.
Change 24.074 Variables INTBTIME and INTETIME, Interval Begin and End,
VMAC30 were never defined for the TYPE30_4 and TYPE30_5 step and
May 15, 2006 job termination events, because they were previously only
output in the TYPE30_V Interval dataset. For the subtype
4 & 5 records, not only were they on the GMT clock, their
times were for the last interval, but for step and jobs,
the interval of the data is the step or job itself.
Fortunately, only the TYPE30TD dataset contained the two
variables from the subtype 4/5 records, and TYPE30TD is
only used internally in BUILDPDB to count tape drives,
and MXG's logic didn't use those timestamps; it was only
if you investigated the WORK.TYPE30TD dataset that you
could have observed the incorrect values. Now, for the
step and job termination records, the two variables are
now set as INTBTIME=INITTIME and INTETIME=SMFTIME, so the
variables describe the data interval in all cases.
Thanks to Mike O'Brien, Bank of America, USA.
Thanks to Betty Wong, Bank of America, USA.
====== Changes thru 24.073 were in MXG 24.03 dated May 13, 2006=========
Change 24.073 Change 23.334 caused type 30 interval records to always
IMACINTV be created, without having to edit IMACINTV, by removing
May 12, 2006 the old comment block around the OUTPUT statement. But,
the &MACINTV macro variable was located physically after
the OUTPUT statement, so it could not be used to alter
the TYPE30_V - PDB.SMFINTRV datasets as intended.
The &MACINTV statement was relocated ahead of the OUTPUT.
Thanks to Willy Iven, Fortis Bank Belgium, BELGIUM.
Change 24.072 INVALID DATA FOR SYTNLPMG/SYTACTM with XAMSYS 3507 data.
VMACXAM MXG used the TOTALs SEGLEN (if GE 48) to INPUT the two
May 11, 2006 percent SYTPCTBY/SYTPCTOV fields that may or may not be
present, and that worked for prior test data, but this
new data has SEGLEN=40 in TOTALs for its 1 LPAR, so the
LENDATA=12 (bytes after DURATM, so PCT fields are NOT in
the TOTALs section, but the LPARA section has LPAR count
of six with SEGLEN=168, but there are seven "buckets" of
LPAR data, so the LENDATA=20, and the "real" LPAR data
does have the PCT fields, while the TOTALs doesn't.
That 7th LPAR segment has a Partition Number of '0040'x.
To process these records and protect for the future, MXG
code now recalculates LENDATA for each SYTCUP record, no
longer retaining the value from the TOTALS record, and
used LENDATA to conditionally input the two fields.
May 13: Barton acknowledges the undocumented seventh LPAR
is actually a sub-total for that LPAR, with the
'40'x the LPARNUM of decimal 64 as his flag.
Outputting totals and details to the same dataset
is exposed to reporting errors, and since only
detail LPAR data was previously output to XAMSYT
dataset, this change does NOT output the new LPAR
sub-total section. The decision is internal now,
but could be externalized to EXXAMSYT if someone
convinces me they need that facility.
Thanks to Michael J. Salyer, CitiGroup, USA.
Change 24.071 The SMF manual mis-documented DFSORT bit 6 in ICEFLBY3 to
VMAC16 set new MEMOBJUS='Y' when a Memory Object is USED, but
May 10, 2006 SMF data shows MEMOBJUS must be IBM bit 7 (last), and the
updated DFSORT Installation and Customization Guide, pub
SC26-7524-00, page 212) confirms that bit, as well as
documenting that ICEMON is a 2-byte field at offset 438,
but MXG had input it as a 4-byte field at offset 436.
Fortunately, offset 436 and 437 are reserved and zeros so
ICEMON's value was correct, but MXG code is now revised.
Thanks to Diane Eppestine, AT&T, USA.
Thanks to Gennady Katsnelson, AT&T, USA.
Change 24.070 The right-hand-value of format MG074PT for values of 3 is
FORMATS changed to '03'X='3:LIST STRUCTURE'
May 10, 2006 instead of '03'X='1:LIST STRUCTURE'
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Thom Kight, Fidelity Systems, USA.
Change 24.069 Comments only. ARRAY EXCEEDED error when running _BLDDICT
UTILEXCL if the PGM=DFHMNDUP was used to create CICS Dictionary
May 10, 2006 "SMF" records for five executing regions, but each of the
SMF files were read in five separate _BLDDICT executions.
The SMFTIMEs of DFHMNDUP were all the same (and in 1906!)
and because the records were processed one at a time, the
NREC variable was the same in all of the records, so the
MXG sort on SMFTIME NREC saw way too many entries.
If the five "SMF" files had been concatenated in one run
of _BLDDICT, the problem does not exist, even with same
SMF value, because they will get a different NREC when
there are five records read by _BLDDICT.
However, a new example in comments in UTILEXCL show
how you can correct an existing PDB.CICSDICT dataset
without going back to re-read the SMF data.
Thanks to Doug Jones, T-SYS, USA.
Change 24.068 -SHORT SEGMENT error messages in SYTCPC & STOSHR segments
VMACXAM are corrected; MXG logic did not protect for new fields.
May 9, 2006 The SHORT SEGMENT message is a real error in MXG code
that must be fixed, because that means that observations
were NOT output. Contact support@mxg.com if these occur.
-There were UNKNOWN SEGMENT xxxxx messages printed on the
SAS log that are NOT real errors; they are simply MXG
notes that new segments exist in the XAM data that are
not yet decoded, but the record was still output.
-The text of both messages was rewritten to clarify which
is an error (and what to do), and which is just a note.
-New segments are always supported when a user asks for
the new data, as I prefer to have real data and a real
user to validate new stuff, especially in zVM.
Thanks to Pat Curren, SuperValu, USA.
Change 24.067 Additional INTERVAL=DETAIL value is now supported, which
VMXGDUR will cause DATETIME value to be the original, raw, value
May 6, 2006 to be output, unmodified.
Change 24.066 Variables SYTPCTBY,SYTPCTOV, added by MXG Change 24.017,
VMACXAM were always expected, but they did not exist in Release
May 5, 2006 3507 of XAM. Logic revised to keep the SEGLEN of the
"Total" segment and use to INPUT the two fields that
were found in Release 3519.
Thanks to Michael J. Salyer, CitiCorp, USA.
Change 24.065 Variables STARTIME and SYNCTIME in TYPE23 were in the GMT
ADOC23 timezone while SMFTIME was (always) in Local time, but
VMAC23 the only documentation clue was that third argument "GMT"
May 4, 2006 in the %VMXGTIME(SYNCTIME,SYSTEM,GMT); statement
used only by the optional TIMEBILD facility, and only
when there was no GMT offset in the SMF record.
However, the PROC PRINT of TYPE23 (from 1999!!) in the
ADOC23 member clearly shows an exact 6-hour difference
between SMFTIME and SYNCTIME, so the GMTOFF23 can now be
calculated and used to convert SYNCTIME and STARTIME to
the local time zone. GMTOFF23 is kept in TYPE23, and if
it is non-missing, then STARTIME/SYNCTIME were converted
from GMT to local time zone.
I think this was not done before because nobody asked,
and maybe because SYNCTIME was not always present in
SMF 23 records way back end.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.064 Redesign of ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP creation.
VMAC7072 Major changes, perhaps incompatible:
VMXG70PR - ASUMCEC/ASUMCELP default summary interval is HOURLY.
VMXGINIT - ASUM70PR/ASUM70LP interval no longer set by IMACRMFI
WEEKBL* so you may have to add INTERVAL= in your ASUM70PR.
MONTHBL* - BY List variables were changed for all four datasets.
VMXGINIT
TRNDCEC This redesign is required becasue the old BY list of MXG
May 9, 2006 variables that I thought were sufficient to identify a
May 11, 2006 unique "SYSTEM", for summarization, these variables:
May 13, 2006 SYSPLEX SYSTEM SYSNAME STARTIME
are not sufficient, and cause incorrect output.
The new BY variables required to identify a "SYSTEM"
CECSER SYSPLEX SYSTEM SYSNAME LPARNUM LPARNAME SMF70GIE
are used in VMXG70PR logic to group, but you would use
CECSER SYSPLEX SYSTEM SYSNAME LPARNUM LPARNAME STARTIME
for your reports by Start time, and any other summaries.
-The ASUM70PR/ASUM70LP "SYSTEM" and "SYSTEM-LPAR" summary
data were less exposed to serious errors (because they
are per system with less time variance) than were the
ASUMCEC/ASUMCELP "CEC" and "CEC-LPAR" datasets, which
were very wrong when DURATM and/or STARTIME values were
not the same for all SYSPLEX and SYSTEMS in a CEC, but
all four datasets could be in error with the old "BYs".
And even with the revision, you need to remember that the
"SYSTEM" and "SYSTEM-LPAR" datasets have observations for
each interval from every SYSTEM in each SYSPLEX, so they
have duplicate and replicated data, and you must always
select which "SYSTEM" to use.
-While I do find a PROC PRINT of PDB.ASUM70PR/PDB.ASUMCEC
datasets can be useful to get a snapshot of overall usage
for each LPARs, those two datasets are very unwieldy for
reports, with their 61 sets of different variable names
to deal with. Furthermore, the "LPARNUM" bucket-number
changes with new LPARs so it's not really stable for long
term comparisons.
-Instead, the best datasets to use for LPAR analysis are
the ASUM70LP or ASUMCELP, as they have only one set of
variable names, and you can select and sort by LPARNAME
or SYSTEM, etc., without scanning 61 possible variables.
-The errors that were found in the old ASUMCEC/ASUMCELP
logic could result in multiple observations with slightly
different STARTIME or SMF70GIE values, and/or you could
have duplicate, overlapping, or incorrect data:
-The SPLIT70 rewrite correctly used SMF70GIE to group
by the end of interval for all "BY SYSPLEX-SYSTEM"
(TYPE70,RMFINTRV,ASUM70PR/ASUM70LP) datasets, but it
cannot be used (as-is) to group "BY CECSER", because
SMF70GIE is not the same value in all LPARs in a CEC
for a particular interval, and it caused multiple
observations with overlapping STARTIME to SMF70GIE.
-The DURATM of ASUMCEC was wrong when there were LPARs
with different interval durations. The minimum DURATM
for CEC summary must be at least the largest DURATM,
but for some DURATM values, it must be larger still.
It must be the Least Common Denominator of all of
your DURATMs, so with 10 and 15 minute DURATMs,
your minimum summary interval is 30 minutes.
-Interval DURATM values are very "fuzzy", even for the
"interval pop" observations that you expected to have
the exact INTERVAL you requested (10, 15, or 30 min).
Here's some reality from four CECs that share SYSPLEX:
Interval DURATM
Min Max
CECONE 14:58.99-15:53.26
CECTWO 14:59.62-15:00.50
29:59.88-30:00.11
CECTHREE 09:59:54-10:00.74
14:59.24-15:23.17
CECFOUR 14:59.75-15:00.23
28:54.08-30:00.08
And there are always intervals of much smaller DURATM:
the first RMF interval's end is forced so the next is
synchronized with time of day, so any value of DURATM
less than the maximum can occur in SMF data, which
prevents using the data to set the summary interval.
-CECs with LPARs with both SYNC(0) and SYNC(59) have
some SMF70GIE values of 00/15/30/45 minutes and some
with values of 59/14/29/44 minutes, so it's impossible
to exactly summarize that data to a true CEC interval.
-Inexactness of DURATM across LPARs in a CEC caused the
STARTIME=SMF70GIE-DURATM; to be as inexact as DURATM,
so STARTIME can not be used, either.
-With these inconsistent/fuzzy times, creating a perfect
CEC-LPAR summary dataset for each LPAR in each CEC is not
possible, but we can create a very-good summary dataset,
that gets to be nearly-perfect if all of your systems are
on the same SYNC() and INTERVAL() specifications in RMF.
But you still may occasionally get percentages over 100%!
-The PDB.ASUM70PR and PDB.ASUM70LP datasets summary DURATM
used to be set by the IMACRMFI member's _DURSET macro, so
the interval of those two datasets matched your RMFINTRV.
And this still works fine, if your _DURSET macro made no
change in STARTIME (i.e., your RMFINTRV/ASUM70PR/ASUM70LP
were at the original, raw datetimes of your RMF data).
But if you have used _DURSET to change the STARTIME of
PDB.RMFINTRV to a summary interval, I can't tell what you
wanted for your interval, so I will now print a message
that I have to build those two datasets a detail level,
and telling you to use the INTERVAL= parameter in your
ASUM70PR member, instead of IMACRMFI, to define interval.
-The redesign creates the CEC-level by-LPAR summary data
in the PDB.ASUMCELP ("CEC-LPAR") dataset, starting with
the just=built PDB.ASUM70LP ("per-SYSTEM-LPAR"
resources for each "LPAR" for each "STARTIME" within each
"CECSER" box, with the new duration DURATM = "CECINTRV":
"LPAR" - Variables SYSPLEX LPARNUM LPARNAME are
used to uniquely define each "LPAR", as
the same LPARNUM and/or LPARNAME can be
used in different SYSPLEX on same CECSER.
"STARTIME" - STARTIME and SMF70GIE are shifted to the
"expected, exact" time of day value for
CECINTRV interval. See algorithm below.
"CECINTRV" - Default summary interval is 60 minutes,
so STARTIME/SMF70GIE will be on the hour.
As noted above, the CEC summary interval
MUST be the Least Common Denominator of
all of your DURATMs, so using 60 minutes
safely summarizes every RMF Interval that
I've ever used (1,3,5,10,15,20,30,60).
You can use a smaller value for CECINTRV
only if it is equal to the LCD of all of
your DURATM values for all of your LPARs.
- SMF70GIE is changed to be the "correct" interval end
time of day for the CECINTRV duration. One minute is
added if SYNC(59) minutes of 14,29,44 or 59 are found,
other endtimes are pushed to the correct TOD value.
So the CEC-summary data can still be slightly wrong
because two slightly different intervals are summed
together, but that's all that can be done, unless
you change all of your interval and SYNCs to be the
same!
Each SMF70GIE and LPARNAME is summarized to combine the
short intervals into the summary interval, using
BY CECSER SYSPLEX LPARNUM LPARNAME SYSTEM SYSNAME
(revised) SMF70GIE
That summary of each LPARNAME is then sorted
BY CECSER SMF70GIE LPARNUM LPARNAME
DESCENDING SMF70LAC DESCENDING DURATM,
and the the first instance of each LPARNAME is output
to create the PDB.ASUMCELP dataset, with the total
resoures consumed by each LPAR in that CEC for the
constructed CEC Interval. Variable STARTIME is
recalculated as SMF70GIE-CECINTRV so all of the obs
will have the same "pseudo" STARTIME for reporting.
-While the new sort order BY CECSER SYSPLEX .... is used
inside VMXG70PR to ensure correct assembly and summary,
at the end, the four output datasets are sorted back to
their old sort order, with the new variables added at the
end, hopefully to avoid NOTSORTED errors in your weekly
and/or monthly jobs that combine ASUMs built with both
the old and new logic. The final sort order is:
ASUM70LP:
BY SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER
LPARNAME LPARNUM
ASUM70PR:
BY SYSPLEX SYSTEM SYSNAME STARTIME SHIFT CECSER
ASUMCELP:
BY CECSER STARTIME SHIFT LPARNAME LPARNUM
ASUMCEC:
BY CECSER STARTIME SHIFT
-A new macro variable, &MXGNOBY, is created for NOTSORTED
circumvention in each of the WEEKxxxx/MONTHxxx members.
The current circumvention, documented in comments in each
of those members, still works fine, but it requires you
to EDIT your WEEKxxx/MONTHxxx member to insert:
MACRO _BY % MACRO _SORTBY %
which disables the BY processing in the SET statements.
Without the BY processing, the output dataset is not
in sort order, but instead is the concatenation of
the input datasets, but there is no requirement that
the datasets be sorted (except in MXG's MONTHxxx and
WEEKxxx code!!). Even though MXG normally builds its
datasets sorted, you should never make that assumption
and thus should always sort the input data yourself;
however, if the dataset is already sorted in the same
order, SAS will bypass your sort. Thus having output
of the weekly or monthly only impacts run times, but
not the contents of the output datasets.
This new &MXGNOBY macro variable is located so that it
can be used in your //SYSIN to disable BY processing,
without EDITing your WEEKxxx/MONTHxxx member, using
%LET MXGNOBY = MACRO _BY % MACRO _SORTBY % ;
%INCLUDE SOURCLIB(MONTHBLD);
And, then remove the %LET before the next MONTHBLD!
-May 11:
Variable LPARWAIT was incorrectly kept in ASUMCEC/TRNDCEC
but it is an LPAR-specific field that was stored into its
LCPUWAIn variable, so LPARWAIT is not kept in ASUMCEC nor
TRNDCEC. The labels for the LCPUWAITn variable now are
'LCPU n*WAIT*COMPLETE?'.
-May 13:
The variables NRIFCCPU/NRIFACPU/NRIFLCPU/NRZIPCPU that
count the number of "specialty engines" was sometimes
incorrect in the PDB.ASUMCEC and PDB.ASUM70PR datasets.
They are corrected, and documented as to when they will
be zero and when they won't:
For the "this system" PDB.TYPE70 dataset, SMF70CIN='IFA'
is used to count the NRIFAS available to "this system";
but even when SMF70CIN is not populated with that new
value, the original MXG heuristic algorithm detects and
counts IFAs, and populates CPUIFATM and the other IFA
durations. The "this system" datasets PDB.TYPE70 and
PDB.RMFINTRV do not depend on new values in SMF70CIN.
However, for "LPAR summary" PDB.ASUM70PR & PDB.ASUMCEC
datasets, SMF70CIN must be populated with "IFA" to count
each type of "specialty engines". But SMF70CIN is only
populated with new 'IFL' or 'IFA' values on z9 and later
processors, so only z9+ systems will have the correct
count values in all four NRxxxCPU counters. Pre-z9
systems have only 'CP' or 'ICF' in SMF70CIN so they will
have zeros in NRIFACPU and NRIFLCPU, and the NRICFCPU
variable will contain the total count of all of the
specialty engines in that CEC.
But it is only the NRxxxCPU counters that may be zeroed.
Whether it's a z9+ or not, the IFACPUTM,IFAUPTM,IFAWSTTM
duration variables were correct when an IFA is used, and
you can have NRIFACPU=0 with IFACPUTM non-zero pre-z9's!
Change 24.063 The calculation of MACHTIME in TYPE89 & TYPE892 datasets
VMAC89 was revised with SMF data that had SMF89DTO and SMF89HOF
Apr 29, 2006 populated. Now, MACHTIME=SMF89UET-SMF89DTO-SMF89HOF, and
May 4, 2006 it is the "TRUE" GMT Clock datetime when the actual usage
occured to be used by IBM for usage charges. MACHTIME is
needed for IBM to charge you correctly, since you can IPL
IPL with any date/time/offset, as you did for Y2K tests,
and may to do again for Y2042 testing (8-byte STCK fields
will wrap at 23:53:48 on Sep 17, 2042, but must be fixed
prior to 2012, because tape retention can be 30 years.)
Only MACHTIME is is adjusted, as all of the other times,
SMF89UST, SMF89IST, SMF89IET, SMF89UET and SMFTIME are
always on the same (local) time zone.
And SMF89DTO, unlike all other SMF GMT Offset fields,
is the offset from local back to GMT.
The SMF89IST/SMF89IET times are the start/end of the
interval of data (twelve 5-minute intervals in an hour),
while the SMF89UST/UET are always the hourly start/end
of each usage hour, so they have the same value in all
twelve detail observations for that hour.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Stephen H. Hodges, OneBeacon, USA.
Change 24.062 SAS ERROR: BIT CONSTANTS ARE NOT SUPPORTED BY SQL because
MXGSASV9 the Service Pack SASMSG DSN was not first in the //SASMSG
Apr 27, 2006 concatenation. When you install a SAS Service Pack, the
new SASMSG DSNAME contains ...SL..., and that DSNAME must
be first in the //SASMSG DD concatenation. This change
adds a ...SL... DD/DSNAME to the MXG Example JCL Proc.
Due to how SAS messages are built, if the wrong SASMSG
is first, you can get all types of failures, including
ABENDS. Many times there will be a message text that
makes no sense (there are no BIT tests in any of the
code that produced the above error), because the SAS
message formatting is processing the wrong message ID,
due to the incorrect library being first.
Thanks to Jim Horne, Lowe's Companies, Inc., USA.
Change 24.061 Revised to work on ASCII systems; SAS WENT TO A NEW LINE
TIMEBILD error message if there was no data in the OFFGMT column.
Apr 26, 2006 On z/OS, TIMETABL is a RECFM=F/FB file, so there always
May 22, 2006 is at least a blank in column 64, where OFFGMT was read,
but on ASCII, the text file is variable length, and that
unconditional INPUT @64 with no data caused SAS to skip
the next line in TIMETABL. The INPUT @64 OFFGMT is now
conditionally executed only if there is data there.
The error was observed when the time stamps on systems
that were listed in TIMETABL were not being changed.
-May 22: The LRECL=72 in the INFILE &TIMETABL statement
left during testing this change was removed.
It caused an OPEN ERROR if the &TIMETABL DD
pointed to an LRECL=80 dataset (i.e. SOURCLIB).
Thanks to Ingegerd Jansson, Volvo, SWEDEN.
Change 24.060 The RMF-like CPU Activity Report is updated for IFAs and
ANALRMFR IFL engines.
Apr 26, 2006
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 24.059 For z/890's only, the three IFA CPU Time variables in the
VMAC30 TYPE30/STEPS/JOBS, CPUIFATM, CPUIFETM CPUIFDTM, were the
Apr 26, 2006 "measured" rather than "normalized to CP seconds" in MXG,
and thus their values werr too large on z/890s. The
three times are now revised to be the "normalized" time:
CPUIFATM=CPUIFATM*SMF30ZNF/256;
CPUIFETM=CPUIEATM*SMF30ZNF/256;
CPUIFDTM=CPUIDATM*SMF30ZNF/256;
and those equations could be used to correct existing
MXG datasets.
Change 24.058 -The SORT order of PDB.ASUMTAPE was changed in MXG 23.09
ASUMTAPE (Change 23.300) to BY "LOCATION" DEVNR. Previously, it
WEEKBLxx was BY SYSTEM DEVNR, but it was never correct to include
Apr 26, 2006 SYSTEM if you shared tape devices across systems. One of
the major corrections in Change 23.300 was the removal of
SYSTEM from the ordering (and the creation the optional
"LOCATION" to support multiple locations with the same
DEVNR for two different devices), as well as the addition
of the SYSLOG mount-related messages in the redesign.
Unfortunately, I did not document this change in the sort
order of PDB.ASUMTAPE, and I failed to update the WEEKBLD
programs, which still had the old BY statement. SYSTEM
has now been removed from the BYLIST in those WEEKBLx's.
-Macro _GRPMNCD to define the optional "LOCATION" was not
invoked in the ASUMTAPE member (which only proves that no
one yet had tried to use that option!), but now it can be
used if needed.
====== Changes thru 24.057 were in MXG 24.02 dated Apr 26, 2006=========
Change 24.057 New analysis of RAID boxes, creates new PDB.RAIDMAP and
ASUMCACH PDB.CSSSID datasets that shows, for each CSSID, all of
ASUMRAID the volumes on that CSSSID (typically 80 to 256). Some
GRAFRAID user tailoring of the ASUMRAID member will be required;
Apr 25, 2006 read the comments in ASUMRAID.
-The ASUMRAID analysis requires ASUMCACH to have been run
to create PDB.ASUMCACH; this change cleaned up ASUMCACH
so it won't fail even if there was no TYPE74CA dataset
observations.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.056 New GLOBAL macro variable MGCMPNY is now defined as null
VMXGINIT in VMXGINIT, but it will be used in MXG reports so your
Apr 25, 2006 Company Name can be printed on reports. You could set it
permanently in IMACINIT, with
%LET COMPANY='MERRILL CONSULTANTS;
or you could just put that %LET in your //SYSIN stream.
The reports that have been revised to use &MGCMPNY will
be added to this list:
ASUMRAID
Change 24.055 See Change 24.063.
VMAC89
Apr 25, 2006
Change 24.054 This example, which reads SMF data to run ASUMTAPE, was
ASMFTAPE not updated for the new SYSLOG Messages dataset, which
Apr 24, 2006 caused FILE PDB.TYPESYMT NOT FOUND error. The example
was revised to use the _STMNT product sort macro so that
all present and future TMNT datasets are sorted.
Thanks to Andre Vossen, ABN AMRO Bank, THE NETHERLANDS.
Change 24.053 Error messages printed for negative CPUUNITS are now only
VMAC30 printed if the delta is 1000 unweighted service units, or
Apr 24, 2006 about 0.05 CPU seconds on an SU_SEC=25000 machine. The
messages were added by Change 23.323 when the cause was
not known, but new analysis of a full day's SMF interval
records had only 56 records which had IFAUNITS greater
than ORGUNITS, but the max delta was only 650 units, or
0.03 seconds on the SU_SEC=25000 machine. The CPUTCBTM
was 0.00 or 0.01 CPU seconds, and CPUIFATM was between
0.25 to 0.44 CPU seconds for the 30 minute intervals.
MXG's value of CPUUNITS will not be changed, so you can
see if this occurs, but the MXG Error Message will only
be printed when the negative delta is significant.
After discussions of this data with IBM, I agree that
these negative values are the result of imprecision in
CPU timings (.01 resolution) and in the way Service Units
are calculated (remainders are discarded in some fields,
rounding is done in others) and are not a problem to be
immediately corrected, although IBM does plan to review
their remaindering/rounding logic.
Jul 27, 2006: It appears the correction to IBM Service
Unit remaindering is corrected by APAR OA16005.
Change 24.052 Debugging PUT statement removed.
VMACFILA
Apr 24, 2006
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 24.051 In DB2 V8.1, QISEDBW was missing but shouldn't have been,
VMACDB2 QISEDSC should have been but wasn't, and these four new
Apr 24, 2006 variables are now INPUT for the DB2ACCT dataset.
Apr 25, 2006 QISEDYNP QISECFAL QISECPGE QISECFRE
Apr 27, 2006 And, QISESTMT should not have been de-accumulated.
And, QISEDSI and QISEDSG are now de-accumulated.
Thanks to Clayton Buck, UniGroup, iNC.
====== Changes thru 24.050 were in MXG 24.02 dated Apr 24, 2006=========
Change 24.050 New variables INDXUSED and POLYUSED are created from DSIG
VMACRMFV offset variables that are now kept in ZRBBDSHI dataset,
Apr 23, 2006 to detect and eliminate "dead space" in RMF VSAM files.
RMF Monitor III "indexes" each Sample Set in the DSH
table; a sample set is written for each MINTIME interval
and the index provides the offset into the data set for
each sample. But the max DSH is 32K long; the fixed DSH
header is 256 bytes, leaving 32512 bytes for the 28-byte
indexes, for a maximum possible of 1161 indexes; Cheryl
Watson reported 50 are saved for Policy Indexes, leaving
1111 indexes for the actual sample data indexes. In the
past sites had cumbersome calculations to insure the RMF
III VSAM files were not too large; otherwise, those 1111
index entries could be exhausted. But with the INDXUSED
calculation, Jerry found they were only using 80-95 of
the indexes on each dataset because their sample sets are
so large. With RMF III data sets of only 2250 tracks
each, they would exhaust space long before running out of
indexes. The datasest could be made much bigger, keeping
more data online for interactive analysis, and still not
risk creating any "dead space". And adding new RMF III
datasets may not be an option, as there is a hard limit
of 100 datasets.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.049 Variables WTASFLAG and WTASFLG2 are now kept in MQMQUEUE
VMAC116 dataset, from MQMACCTQ segment, and new variable SM116EVT
Apr 23, 2006 is created to distinguish between records written at the
Apr 25, 2006 end of each thread from records written at interval end.
Data showed that the thread end had WTASFLAG='30'x and
the interval end had WTASFLAG '00'x or '20'x.
IBM now provided these bit explanations:
WTASFLAG
WTASERR 0 set if an error occurred
WTASLAT 1 Latency Error
WTASAEOT 2 Accounting End of Thread
WTASDEAL 3 Thread Deallocated
WTASFLA2
WTASHERE 8 WTASHERE Block has been used
So new MXG variable SM116EVT is now created, with
LABEL S116VENT='EVENT*I=INTERVAL*T=THREAD END';
IF WTASFLAG='..11....'B THEN SM116EVT='T';
ELSE SM116EVT='I';
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.048 A new version of the CLRMFV TSO Clist, the driver for the
CLRMFV ASMRMFV RMF Monitor III decompression utility, adds new
DOCLRMFV options to provide better support for the single large
Apr 23, 2006 output file if can now create with CALLBY(ALL):
-OUTSCL() SMS STORCLAS, now default is null.
-OUTMCL() SMF MGMTCLAS, now default is null
-OUTMLQ() to specify middle level qualifier for RMF dsn.
-OUTRLSE() to specify YES or NO (YES is default)
-OUTTYPE() to specify DSNTYPE.
See DOCLRMFV for full description and usage notes.
A special thanks to Acxiom leadership for allowing this
effort to continue to go forward.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.047 LABEL statements with duplicated variable names are now
Apr 23, 2006 detected in MXG's QA stream, and all have now been fixed.
Many In some cases, this was a real error: two different data
fields were stored in the same variable, so a new named
variable had to be created for that second field. All of
the other cases were examined and the "better" label was
kept. SAS uses the last label it compiles, so if "last"
was "better", then there was no change, but some labels
will now be different (and, hopefully, "better').
Change 24.046 zIIP support. (APAR OA13499, z/OS 1.6, 1.7, and 1.8).
VMAC30 The metrics and variables for the new zIIP engines are
VMAC7072 very much like the metrics for IFA/zAAP engines.
VMACDB2 -TYPE30 New Variables:
VMACRMFV CPUZIPTM='TOTAL*EQUIVALENT*CPU TIME*ON_ZIP'
VMXG70PR CPUEZITM='INDEPENDENT*ENCLAVE*CPU TIME*ON ZIP'
Apr 20, 2006 CPUDZITM='DEPENDENT*ENCLAVE*CPU TIME*ON ZIP'
Jun 5, 2006 CPUZIETM='ZIP-ELIGIBLE*CPU TIME*ON CP'
Jun 13, 2006 CPUEZETM='ZIP-ELIGIBLE*IND ENCLAVE*CPU TIME*ON CP'
Jun 14, 2006 CPUDZETM='ZIP-ELIGIBLE*DEP ENCLAVE*CPU TIME*ON CP'
Jun 15, 2006 CPUEZQTM='ZIP-QUALIFIED*IND ENCLAVE*CPU TIME'
Jun 22, 2006 CPUDZQTM='ZIP-QUALIFIED*DEP ENCLAVE*CPU TIME'
Oct 13, 2006 ZIPUNITS='ZIP-EQUIVALENT*CPU*SERVICE*UNITS'
ZIEUNITS='ZIP-ELIGIBLE*CPU*SERVICE*UNITS'
-TYPE70 New Variables
NRZIPCPU='NUMBER OF*ZIP*ENGINES*AVAILABLE'
Oct 13, 2006 Note: Originally spelled NRZIPS in
this text, I chose NRZIPCPU for the new name in all
TYPE70/RMFINTRV/ASUM70PR/ASUMCEC/etc datasets.
Since NRIFAS already existed in TYPE70/RMFINTRV,
I had to leave that spelling in those datasets, but
I used NRIFACPU in the ASUM70PR/ASUMCEC/.. datasets
which previously didn't have a count of IFAs.
SMF70SUP='ZIP PROCESSORS*ONLINE*AT END OF*INTERVAL'
PCTZIPBY='ALL ZIPS*PERCENT*BUSY (DISPATCHED)'
ZIPAVAIL='ZIP*PROCESSOR*AVAILABLE?'
ZIPACTTM='ZIP ENGINE*EXECUTING*(ACTIVE) CPU TIME'
ZIPUPTM ='ZIP ENGINE*AVAILABLE*(UP) TIME'
ZIPWAITM='TOTAL*ZIP WAIT*DURATION'
ZIPWAIT0='ZIP WAIT*DURATION*ZIP 0'
ZIPWAIT1='ZIP WAIT*DURATION*ZIP 1'
ZIPWAIT2='ZIP WAIT*DURATION*ZIP 2'
... 3 thru 30 ...
ZIPWAITW='ZIP WAIT*DURATION*ZIP 31'
ZIPWAITX='ZIP WAIT*DURATION*ZIP 32'
PCTZIBY0='ZIP 0*PERCENT*CPU BUSY TIME'
PCTZIBY1='ZIP 1*PERCENT*CPU BUSY TIME'
PCTZIBY2='ZIP 2*PERCENT*CPU BUSY TIME'
... 3 thru 30 ...
PCTZIBYW='ZIP 31*PERCENT*CPU BUSY TIME'
PCTZIBYX='ZIP 32*PERCENT*CPU BUSY TIME'
-TYPE72GO New Variables
CPUZIETM='ZIP*ELIGIBLE*CPU*TIME'
CPUZIPTM='ZIP*CPU*TIME'
R723CIFA='IFA*SERVICE*UNIT'
R723CIFC='IFA-ELIGIBLE*SERVICE*UNITS'
R723CSUC='ZIP-ELIGIBLE*SERVICE*UNITS'
R723CSUP='ZIP*SERVICE*UNITS'
R723SUCU='ZIP-ELIGIBLE*ON CP*USING SAMP'
R723SUPD='ZIP*DELAY*SAMPLES'
R723SUPU='ZIP*USING*SAMPLES'
ZIEUNITS='ZIP*ELIGIBLE*UNITS'
ZIPUNITS='ZIP*SERVICE*UNITS'
-DB2 CPU Time fields added to DB2ACCT (APAR PK18454).
QWACZIEL='CPU TIME*ZIP ELIGIBLE*ON CP*ENGINE'
QWACZIS1='CPU TIME*EXECUTING*ON ZIIP'
QWACZIS2='CPU TIME*IN DB2*EXECUTING*ON ZIIP'
QWACZITR='CPU TIME*IN TRIGGERS*EXECUTING*ON ZIIP'
-DB2 CPU Time field QPACZITM for Package ZIP execution:
QPACZITM='CPU TIME*
-RMF Monitor III fields added to CPUG3 segment for zips:
CPUITSUP='LOGICAL CPU*TIME ON*ZIP*PROCESSORS'
CPUPRSUP='ONLINE*TIME ON ZIP*PROCESSORS'
CPUSTSUP='PHYSICAL CPU*TIME ON*ZIP*PROCESSORS'
CPUSUCOL='AVERAGE*ZIPS*ONLINE*DURING*INTERVAL'
CPUSUCON='ZIP ENGINES*ONLINE*AT END'
See Change 24.181 for more RMF III zIIPs data.
-ASUMCEC new calculated variables:
PCTIFABY='ALL IFAS*PERCENT*BUSY (DISPATCHED)'
PCTZIPBY='ALL ZIPS*PERCENT*BUSY (DISPATCHED)'
Jun 5: VMAC7072 was revised to correctly input variables
R723SUP/R723CSUC/R723CIFA/R723CIFC.
Jun 13: Some 70 zIIP variables had IFA in their labels.
Jun 14: Some 30 zIIP variables had IFA in their labels.
Jun 15: DB2 zIIP variables created in DB2ACCT,DB2ACCTP
Jun 15: TYPE72GO fields added to KEEP=, LABEL.
Jun 20: Change 24.105 revised ASUM70PR for zIIPs.
Jun 22: VMACRMFV updated for RMF Monitor III Zip data.
-And now that IFA/ZIP text is in all MXG variable labels,
the APAR documents that IBM has changed RMF reports to
now print 'AAP' for IFA/zAAPs and 'IIP' for zIIPs, but
I am not going to change either those existing labels nor
the variable names that already exist.
Change 24.045 Support for APAR UK12301 (Tivoli Allocation Optimizer SMF
VMACTIAO record) adds flag bit for Not Cataloged 2 error condition
Apr 19, 2006 (which only applies to non-SMS-managed datasets!), and
new TIAOVOL variable if Not Cataloged bit is on, with the
VOLSER of the dataset in error.
Change 24.044 Variable BEGTIME was missing in DB2STATB dataset for the
VMACDB2 startup record (QWHSISEQ=1), which is now corrected (by
Apr 19, 2006 setting BEGTIME=ENDTIME=QWHSSTCK and DURATM=0). But for
the first instance of each Buffer Pool that was not a
startup record, not only was BEGTIME a missing value,
but also the rest of the variables were trash, because
the accumulated values were output. A long term solution
would be to introduce "SPIN" logic into DB2 processing,
but as no one has noticed the trashed data, and as the
introduction of the need for the //SPIN DD into stanalone
DB2 processing could cause well-running programs to fail,
my present solution is to not output that first instance,
and if that observation is truly ever needed for ad hoc
problem analysis, using the prior day's SMF data and
today's SMF data, concatenated as input, will completely
provide correct data, without a redesign to use SPINing.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 24.043 Variables PCTCPUBY=. and CPUACTTM=. in PDB.TYPE70 dataset
VMAC7072 if the SYSTEM is is not-LPARed, but instead only exists
Apr 7, 2006 as a single image. This case is now detected and the
code sets PCTCPUBY=PCTMVSBY, and CPUACTTM=CPUMVSTM.
Thanks to Ronald Kveton, Experian, USA.
Thanks to William Whitehead, Experian, USA.
Thanks to John Rourke, Experian, USA.
Change 24.042 Support for CPC RMF III report data, which is now INPUT
EXZRBLCP from the ERBCPUG3 segment; some of the variables are
IMACRMFV output into the existing ZRBCPU dataset, but the LCPUADDR
VMACRMFV details are output in the ZRBLCP dataset.
VMXGINIT Five of the new fields in ZRBCPU dataset are accumulated:
Apr 7, 2006 CPUPRIFA, CPUWEICD, CPUWEIND, CPUUNCTD and CPUCAPTD and
a revision to this change will be made shortly to sort
and deaccumulate those values, and this text will be
revised when that logic has been added and tested.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 24.041 As noted in Change 23.132, the new MACHTIME variable was
VMAC7072 created but not validated, and my guess to add SMF70HOF
VMAC89 was incorrect; test data shows that SMF70HOF is to be
Apr 7, 2006 subtracted in VMAC7072 to get back to true GMT.
May 1, 2006 May 1: test 89 data confirmed SMF89HOF is also to be
subtracted in VMAC89 to create MACHTIME; Change 24.063.
Thanks to Manfred Giezendanner, Credit Suisse, SWITZERLAND.
Thanks to Gion Cabernard, Credit Suisse, SWITZERLAND.
Change 24.040 Reserved Change Number.
Apr 7, 2006
Change 24.039 New example program to create a Monthly PDB from only the
JCLMNTHW six weekly PDBs that might be required to span the prior
MONTHWEK month when only WEEK PDBs are to be read. This example
MONTHWEK can be run on any day of the next month to create last
Apr 7, 2006 Month's PDB library. You would still need to tailor:
May 4, 2006 JCLMNTHW - the _SELDSN macro to list only the datassets
that you want created, and
MONTHWEK - delete two lines (MACRO _DSET, MACRO _BYLIST)
for each dataset that you do not want created.
May 4: Revised to read 6 weekly files; while only five
are needed for the normal MONTHBLD on the first of
the month, some months (July 2006) would need to
read six weekly PDBs to create that month's PDB
if only the week PDBs were to be read.
Thanks to William Carroll, Grange Insurance, USA.
Thanks to Jim Horne, Lowe's Companies, Inc., USA.
Change 24.038 "ERROR: UNABLE TO CREATE PDB.MXGENG.DATA BECAUSE VIEW
VMXGENG PDB.MXGENG.VIEW ALREADY EXISTS" with MXG 24.01 BUILDPDB
Apr 5, 2006 occurs only if OPTIONS='USER=PDB' was specified
For BUILDPDB that option should never be used. It
tells SAS to write all datasets that would have been
written to the //WORK DDname, to instead be writeen
to the //PDB DD. But the BUILDPDB design is to write
first to the //WORK DD, sort and write the output to
the //PDB DD, so you can get I/O between volumes and
not hammer the //PDB DATASET by read and write to a
single PDB library for both work and output.
The VMXGENG code used to create MXGENG as a VIEW, and
with USER=PDB, that created PDB.MXGENG.VIEW in the //PDB
library each day, but you can replace a SAS VIEW with a
SAS VIEW of the same name. But Change 23.328 revised
VMXGENG to create a DATASET of the same name, rather than
a VIEW, and (for reasons I don't understand) SAS will not
let you replace a VIEW with a DATASET, so this error
occurred when the new MXG Version wrote to a //PDB that
had been created by the prior version, that still had the
VIEW. By removing the USER=PDB option, the MXGENG and
similar MXG internal facilities' data will be written to
//WORK which is temporary and goes away at job step end,
so the replacement of a VIEW with a DATASET never is an
issue.
Thanks to Karen Fry, Comerica, USA.
Thanks to Theresa Johnston, Comerica, USA.
Change 24.037 A new version of the CLRMFV TSO Clist, the driver for the
CLRMFV ASMRMFV RMF Monitor III decompression utility, plus major
DOCLRMFV enhancements in the documentation in the DOCLRMFV member.
Apr 4, 2006
This CLRMFV version reduces the number of ASMRMFV calls
for users with many LPARs, and provides more flexibility
to specify the input and output data sets, so perhaps it
reduces the need to tailor CLRMFV or at least is easier.
There are no changes required for the ASMRMFV program.
Enhancements:
A new parameter CALLBY() lets the user control the
granularity of the RMF Monitor III data passed to ASMRMFV
in each call. CALLBY(DSN) invokes ASMRMFV once for each
and every RMF Monitor III data set. This setting is NOT
recommended due to overhead and is only included for
compatibility with earlier versions of CLRMFV.
CALLBY(SID) invokes ASMRMFV once for each unique LPAR and
is compatible with CLRMFV default behavior in prior
versions. CALLBY(ALL) invokes ASMRMFV once for all LPARs
and is ideal for users (such as our installation) who
want to process many LPARs at once with ASMRMFV with
minimal overhead. CALLBY(ALL) is the new default.
The ONECALL() parameter is now obsolete. If ONECALL(NO)
is coded, it is converted to CALLBY(DSN). If ONECALL(YES)
is coded it is converted to CALLBY(ALL). ONECALL() will
be removed entirely in a future version of CLRMFV, but is
here so you have plenty of time to remove it and use the
CALLBY() instead.
A new parameter INLLQ() lets the user specify the low
level qualifier if needed for the input RMF Monitor III
data set names. The default is null. Similarly a new
parameter OUTLLQ() lets the user specify the low level
qualifer for the output sequential data set(s). The
default is OUTLLQ(RMFIII) and produces the same data set
name as in prior CLRMFV versions.
A new parameter OUTDISP() gives the user more control on
the allocation method for the output data set(s). There
are three possible values: NEW, MOD, and OLD. The default
is OUTDISP(NEW) and produces the same behavior as prior
CLRMFV versions. See the DOCLRMFV documentation member
for more details. Regardless of this parameter setting
ASMRMFV always appends data from multiple input files
into the output file(s). Only the initial output file
allocation procedure is affected by OUTDISP().
A new parameter OUTDCL() allows the user to specify an
SMS Data Class for the output file(s). The default is
null. This is a companion to OUTMCL() and OUTSCL()
parameters which were available in the prior version for
SMS Management Class and SMS Storage Class respectively.
A new parameter OUTVOL() allows the user to specify a
non-SMS volume serial(s) for the output file(s). The
default is null.
A new parameter OUTVOL#() allows the user to specify a
maximum volume count for the output file(s). The
default is null. The z/OS maximum is allowed 255 and
CLRMFV will validate the value.
A new parameter OUTDEV#() allows the user to specify a
device count for the output file(s). The default is
null. The z/OS maximum allowed is 59 and CLRMFV will
validate the value.
A new parameter TS() allows the user to specify time
stamping on CLRMFV messages. The default is TS(NO) and
only the very first and last messages are time stamped.
TS(YES) causes all CLRMFV generated messages to be time
stamped and so provides the behavior in prior CLRMFV
releases. TS(NO) reduces CLIST overhead.
CLRMFV will now validate that the length of the total
PARM field passed to ASMRMFV does not exceed z/OS 100
character maximum and fail if this is not the case. As
before the //SYSIN DD in JCL can be use to provide
additional ASMRMFV parameters to overcome this z/OS
limitation.
The DOCLRMFV documentation member is enhanced, expanded,
and clarified to explain all the new parameters.
Migration Issues:
With the new CLRMFV default of CALLBY(ALL) the single
output file size will be now the sum of space used for
all the prior LPAR files with the old CLRMFV version .
The SPACE() parameter will need to be increased
substantially if output is to DASD to avoid SB37 abends
or alternately the output file will have to be directed
to tape. The new OUTDEV#() parameter can also help with
the additional space needs by spreading the space needed
over multiple volumes.
The benefit is a reduction in CPU usage by ASMRMFV
because initialization, termination, and summary code is
only used once instead of once for each LPAR. Users who
prefer not to make changes to support CALLBY(ALL) should
specify CALLBY(SID) to get the prior behavior.
With CALLBY(ALL) the single output data set name will be
of the form &OUTHLQ.ALL.&OUTLLQ where &OUTHLQ is the
value of OUTHLQ() and &OUTLLQ will be the value of
OUTLLQ(). So DSN= on the //RMFBSAM DD statement in the
MXG RMF III PDB Build step will need to be changed
accordingly. A DD concatenation of files from multiple
LPARs will no longer be required and the extra DDs should
be removed.
Since all RMF Monitor III data sets will be dynamically
allocated at once with CALLBY(ALL), users may need to
substantially increase the value of DYNAMNBR= in their
JCL invoking CLRMFV. Otherwise the Dynamic Allocations
done by CLRMFV can fail. The TIOT SIZE parameter in the
ALLOCxx member in SYS1.PARMLIB ultimately determines the
maximum size value allowed for DYNAMNBR=. This is
discussed in the DOCLRMFV member.
As a side effect since CALLBY(ALL) results in ASMRMFV
being invoked only once, the ASMRMFV summary report
produced will be for the grand totals from all LPARs
instead of 1 summary report per LPAR as in the prior
version. Users who want the earlier behavior should use
CALLBY(SID).
A special thanks to Acxiom leadership for allowing this
effort to continue to go forward.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 24.036 An extra, undocumented 8 bytes have been added to the
VMACRMFV RMF III ASI table in z/OS 1.7, although IBM will issue
Apr 4, 2006 a documentation change in the future. This change tests
for ASIVERE3 GE '10'X to skip the extra 8 bytes.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Roger Foreman, Acxiom CDC, USA.
Change 24.035 XAM SYS error INPUT STATEMENT EXCEECED LENGTH was caused
VMACXAM by an unexpected value of 'FFFF'x in the NSIMBUSY field,
Apr 4, 2006 or 65536 decimal, for the number of fields in the array
HFCHSIM that follow this count, which MXG tried to read
when there were no fields following.
Now, MXG detects this value, and bypasses the logic to
read any elements of HFCHSIM array.
The 'FFFF'x value is actually -1 if input as Integer
Binary, and is set by XAM because IBM no longer keeps
track of concurrent channels in use, so there no longer
is an HFCHSIM array to INPUT.
Thanks to Brian Carter, EDS UK Mainframe Hosting Services, ENGLAND.
Thanks to Jeff Gribbin, EDS UK Mainframe Hosting Services, ENGLAND.
Change 24.034 Converting a character variable that contains a hex value
Documentation (e.g., a four-byte character variable DEVCHAR='1F1A')
Apr 4, 2006 into a numeric variable that contains that hex value
Apr 20, 2006 (e.g., a two-byte numeric variable DEVNR=1F1Ax when it is
FORMATed as hex4.) can be done using the HEXnn INFORMAT
in an INPUT function:
DATA;
DEVCHAR='1F1A';
DEVNR=INPUT(DEVCHAR,HEX4.);
FORMAT DEVNR HEX4.;
will store the decimal value 7962 in DEVNR, which will be
printed as 1F1A with the HEX4. format.
This change was rewritten on April 20, when the HEXnn.
format was suggested in a SAS-L posting by Jiann-Shiun
Huang. Below, is the original April 4 change text:
The format $MGHEXC can be used to convert a character
variable that contains a hex value in EBCDIC text into a
numeric variable with the value formatted as HEX.
For example, if DEVCHAR='1F1A' is DEVNR='1F1A'x, then
this code will create numeric variable DEVNR:
DEVNR= 4096*INPUT(PUT(SUBSTR(DEVCHAR,1,1),$MGHEXC.),2.)+
256*INPUT(PUT(SUBSTR(DEVCHAR,2,1),$MGHEXC.),2.)+
16*INPUT(PUT(SUBSTR(DEVCHAR,3,1),$MGHEXC.),2.)+
INPUT(PUT(SUBSTR(DEVCHAR,4,1),$MGHEXC.),2.);
The $MGHEXC format was created to decode SYSLOG character
Device Number, but can be used for any hex-text .
Thanks to DJ Chen, Florida Department of Corrections, USA.
Thanks to J S Huang, AmerUs Group, USA.
Thanks to Nick Johns, Sainsbury, ENGLAND.
Change 24.033 When UTILEXCL detects CMODNAMEs of EZA01 and EZA02, you
IMACICE2 must tailor members IMACICEZ, IMACICE1, and IMACICE2 to
Apr 4, 2006 process those data. The fields INPUT in IMACICEZ and E2
are consistent at all sites, but the number of fields in
the IMACICE1 exit varies from site to site, so if MXG's
REPORT ONE lists IMACICE1 to be tailored, you must then
look at REPORT THREE to see exactly which fields are in
your data, and will have to change the INPUT and LABEL
statements if your data does not contain all twelve of
those fields. This list is an excerpt of REPORT THREE
that is overlaid with the MXG variables that are INPUT.
MEMBER=IMACICEZ:
CMODHEAD CMODNAME MXG VARIABLES
EZA01 INIT S 001 8 TCPINITM TCPINICN
EZA01 READ S 002 8 TCPREATM TCPREACN
EZA01 WRITE S 003 8 TCPWRITM TCPWRICN
EZA01 SELECT S 004 8 TCPSELTM TCPSELCN
EZA01 OTHER S 005 8 TCPOTHTM TCPOTHCN
MEMBER=IMACICE1:
CMODHEAD CMODNAME MXG VARIABLES
EZA01 EZA01 A 001 4 EZA01A01
EZA01 EZA01 A 002 4 EZA01A02
EZA01 EZA01 A 003 4 EZA01A03
EZA01 EZA01 A 004 4 EZA01A04
EZA01 EZA01 A 005 4 EZA01A05
EZA01 REUSABLE A 006 4 EZA01A06
EZA01 ATTACHED A 007 4 EZA01A07
EZA01 EZA01 A 008 4 EZA01A08
EZA01 EZA01 A 009 4 EZA01A09
EZA01 EZA01 A 010 4 EZA01A10
EZA01 EZA01 A 011 4 EZA01A11
EZA01 EZA01 A 012 4 EZA01A12
MEMBER=IMACICE2:
CMODHEAD CMODNAME MXG VARIABLES
EZA02 CONN A 001 4 EZA02CON
EZA02 STARTED A 002 4 EZA02STA
EZA02 INVALID A 003 4 EZA02INV
EZA02 DISTRAN A 004 4 EZA02DIT
EZA02 DISPROG A 005 4 EZA02DIP
EZA02 GIVESOKT A 006 4 EZA02GIV
EZA02 SECEXIT A 007 4 EZA02SEC
EZA02 NOTAUTH A 008 4 EZA02A08
EZA02 IOERR A 009 4 EZA02A09
EZA02 NOSPACE A 010 4 EZA02A10
EZA02 LENERR A 011 4 EZA02A11
If your REPORT THREE contains all of the above fields,
then the default MXG EZ,E1,and E2 members can be used,
but if your REPORT THREE shows for the IMACICE1 list that
"ATTACHED" is the last field (i.e, there are only 7 data
EZA01 fields), then you will need to EDIT the IMACICE1
member so it only INPUTs what's in your data:
-change the length test to GE 28 instead of GE 44
-delete the LABELs for variables EZA01A08 thru A12
-change the INPUT statement to read
INPUT (EZA01A01-EZA01A07) (&PIB.4.) @;
-You create REPORT THREE with the _RPTEXCL macro run with
or after your UTILEXCL execution:
//SYSIN DD *
%INCLUDE SOURCLIB(UTILEXCL);
_BLDDICT;
_BLDEXCL;
_RPTEXCL;
-This change added text in labels for EZA02A08-EZA02A11
with their contents (NOTAUTH,IOERR,NOSPACE,LENERR).
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 24.032 -SPLIT70 rewrite could cause PCTCPUBY/PCTMVSBY in TYPE70
VMAC7072 to be too small, for CPs that were not online for a full
Apr 3, 2006 interval. The recalculated PCTCPUBY used DURATM in the
Apr 5, 2006 denominator instead of SMF70ONT for these CPs.
-NRCPUS was wrong if an LPAR is WLM Managed AND the LPAR
has any IFAs, which affected many PCT calculations. When
an LPAR is WLM Managed, (LPARWLMG='Y'), MXG used variable
SMF70BDA=SMF70BDA/SMF70DSA, documented as the average
number of engines under WLM control, as NRCPUS, but
impossible values of 10.27 for a system in a CEC with
only 10 CP engines was observed. Using the sum of
SMF70ONT (online time of each engine) showed there were
only 8.27 CP engines online during that interval, and
IBM's own Partition Data Report had 8.3 for the Average
Processor NUM for that LPAR for that interval. In reply
to my "impossible" value allegation, IBM RMF Development
replied that SMF70BDA samples include both CPs and IFAs,
and thus the 10.27 value was not impossible, as there
were 8.27 CPs and 2 IFAs online; however it is a
completely useless value to use for anything.
As a result, the MXG calculation of NRCPUS is now always
calculated from the sum of SMF70ONT for CP engines, and
SMF70BDA is no longer used for NRCPUS.
And SMF70BDA will also include zIIPs, if any exist.
Thanks to Marco A. Micchia, Uniocredit Global Info Services, ITALY.
Change 24.031 Cosmetic cleanup of MXG variables during ITRM validation
ASUMTAPE for their dictionary updates:
VMAC80A -VMACTMNT: Variables SYSLDDN,SYSLDSN now labeled.
VMAC94 -VMAC80A : Variables TSREADTI,TSTIME now formatted, TSTIME
VMACTMNT is now KEPT in TYPE80TS dataset.
VMXG70PR Variable TOKDANAM now labeled.
VMACTMO2 -VMXG70PR: Formats for new variables added for 60 LPARs
Apr 3, 2006 were missing in ASUMCEC dataset.
Apr 10, 2006 Sort order in _BSU70PR was incorrect, but it
was not used, so only caused confusion and
deceptive documentation. Correct BY list is
SYSPLEX SYSTEM SYSNAME SMF70GIE
-ASUMTAPE: Instances of %VMXGWORL inside the MACRO _DEBUG
require double percent signs.
-VMAC79: Variables R799CNX2-5 were incorrectly decoded.
R799CNX is now labeled even though its decoded.
-VMAC94: Variables S94XLCSI/S94XLCLS are now kept; they
had been misspelled as XCLSI/SCLSL.
-VMACTMO2: Label for TAWRDCT corrected; QA stream now
tests for duplicate/different labels.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.030 Solaris 9 changed the format of the year in sar data from
TYPEUSAR YY to YYYY; code was revised to support either format.
Apr 3, 2006
Thanks to Greg Meyer, ITresources, USA.
Change 24.029 ERROR.CMRFILE. FILE SEGMENT LENGTH IS 16 BUT 220 EXPECTED
VMACMVCI messages are eliminated. The two file segment sizes are
Apr 2, 2006 supported. The short segment will cause missing values
in most variables in CMRFILE, but the data is valid.
Thanks to Alexander Raeder, ATOS ORIGIN, GERMANY.
Change 24.028 Support for APAR PK15468, which adds variable QWSnPSRB,
VMACDB2 Preemptable SRB CPU Time consumed by SRBs in the Address
Apr 1, 2006 Space named in QWSnASID. Note that this SRB CPU time in
the new QWSnPSRB variable is included in QWSnSRBT.
Thanks to Roger L. Rush, Nav-International, USA.
Thanks to James S. Lazowski, Nav-International, USA.
Change 24.027 SQL Text in DB2 102 Audit Trace IFCIDs 140,141,142,145
VMAC102 was missing after Change 24.01, for DB2 Version 7 and
Apr 1, 2006 earlier, because QW014nLE was only INPUT for DB2 8.1.
Now, IF QW014nLE=. THEN QW014nLE=QW014nLL; corrects.
Thanks to Jim Kovarik, AEGON USA, USA.
Change 24.026 Equal signs were missing from most of the value in the
FORMATS $MGSYSIP format definition.
Apr 1, 2006
Thanks to Lars-Olof Thellenberg, Svenska Handelsbanken, SWEDEN.
Change 24.025 Five 4-byte SYNCSORT fields had expanded 8-byte fields
VMACSYNC that MXG failed to use when the 4-byte fields were full.
Apr 1, 2006 These variables are now reset if their 8-byte field is
greater than their 4-byte field:
CHARACTS INRECS OUTRECS INSERTS DELETES
Unfortunately, the input and output byte count variables,
SIBYTES and SOBYTES exist only as 4-byte fields and do
not have 8-byte counterparts.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 24.024 New E2dddddd members created for "2 Phase" MXG datasets:
E2TY70 -Most MXG datasets are "SIMPLE" or "One Phase": obs are
E2TY70PR OUTPUT to a _Wdddddd dataset in the _Edddddd exit macro
VMAC7072 (which %INCs the EXdddddd exit member) from the raw data,
Apr 1, 2006 then _Wdddddd is sorted to create the _Ldddddd (PDB).
May 1, 2006 For those datasets, code in the EXdddddd member can be
used to create new variables and label them, and the
_Kdddddd macro is used to KEEP those new variables.
-But when datasets are created in a "Second Phase", those
original EXdddddd/_Kdddddd exits/macros cannot be used to
add variables. Instead, a new exit member must be used.
The "Second Phase" exit member in named E2dddddd, to be
somewhat consistent with the original EXdddddd naming,
and you would put your SAS code to create your variables,
and their LABEL and FORMAT statements, in the E2dddddd
exit member.
Note: all variables you create in that exit member
will automatically be KEPT, so you do not need to list
them to be kept. In fact, if you create any temporary
variables in your exit code, you would need to DROP
them so they won't be kept in the output dataset.
-The old EXdddddd exit member has a macro counterpart,
the MACRO _Edddddd, which could be redefined in your
IMACKEEP member, so this new "Second Phase" exit member
also has a macro counterpart, named MACRO _2dddddd, which
can alternatively be used to tailor these datasets.
-The SPLIT70 redesign changed the creation of TYPE70 and
TYPE70PR datasets from "SIMPLE" to "SECOND PHASE", and
thus invalided the use of EXTY70/EXTY70PR exit members
to add variables to the TYPE70 and TYPE70PR datasets, so
this first implemenatation of "Second Phase" exits are
the E2TY70 and E2TY70PR members added by this change.
May 1: SPLIT70 redesign documentation, related note:
You cannot drop these variables
SYSPLEX SYSNAME SMF70GIE SMFTIME
from TYPE7xxx RMF datasets. They are required
to reassemble the pieces, and the MXG logic.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Warren Cravey, Fidelity Systems, USA.
Change 24.023 The default value of macro variable &TAPENGN, used for
VMXGINIT the engine for the TAPETEMP DD in Weekly/Monthly examples
Apr 1, 2006 that output to tape, is now changed to V9SEQ if executing
Jun 24, 2006 MXG under SAS V9, or to V8SEQ if executing under SAS V8.
This should have been done back in Change 23.061, which
changed CONFIGV9 to set the MXG default SEQENGINE=V9SEQ,
(it previously had been V6 due to SAS errors in V9SEQ),
but changing TAPENGN default was overlooked. The V6SEQ
engine does not support character variables longer than
200 bytes, and there are now many long variables in MXG.
Jun 24: The April change caused UNKNOWN ENGINE V9SEQ when
the Weekly or Monthly job was run for the first
time under SAS V8. new logic now tests the
&SASVERS to set V8SEQ or V9SEQ as appropriate.
Thanks to Robbie McCoy, Salt River Project, USA.
Change 24.022 The BY list in the default MONTHBLD example for ASUMDB2B
WEEKBLD now ends with ... QBACPID QWACBSC SHIFT to match the BY
MONTHBLD list used to build PDB.ASUMDB2B.
Mar 31, 2006 Jul 3: Unfortunately, the March change incorrectly had
Jul 3, 2006 MONTHBLD with QWACPID instead of QBACPID, and
WEEKBLD had QWACPID QBACBSC, and the preceeding
change test also had incorrect spellings.
Now, all BYs agree with line 2 of this change.
Thanks to Mike Creech, Fidelity National Information Services, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 24.021 A invalid RACF SMF 80 record with NRSEGS=252 but that had
VMAC80A only 235 actual segments caused INPUT STATEMENT EXCEEDED.
Mar 31, 2006 The last segment was complete, and the RDW matched the
size of the actual SMF record, so this was not a record
that had been truncated in SMF post-processing. MXG now
prints an error message and hex dump on the log for each
instance of this type of invalid SMF record, so you can
send to IBM RACF Support if you choose to resolve their
invalid record. Jun 13, 2006: See Change 24.097.
Thanks to Randy Shumate, LexisNexis, USA.
Change 24.020 ASUMTAPE is still in development, pending STK reply to
ASUMTAPE our problem with their exit, but I accidentally made it
Mar 7, 2006 fail if run under ITRM; I replaced the previous use of
%VMXGWORL macro (to find the location, WORK or PDB, of
the input datasets) with hardcoded &MXGPDB..TAPES and
similar references. Now, the use of %VMXGWORL is
reinstated.
Thanks to Dan Squillace, SAS Institute ITRM, USA.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.019 MXG set OPTIONS DKROCOND=NOWARN in BUILD001/BUILD005/3005
BUILD001 to prevent WARNING: VARIABLES NOT REFERERENCED messages,
BUILD005 as those members execute code with many optional variable
BUIL3005 names in its KEEP= lists, but in BUILD005/3005 the option
Mar 7, 2006 was reset back to DKROCOND=WARN, and if your code had the
condition, the warning message caused condition code 4.
So the hardcoded reset changed the MXG DKROCOND=NOWARN
that is set by CONFIGVn/AUTOEXEC at initialization.
Now, %VMXGOPTR is used to store the original value of the
DKROCOND option, and the hardcode reset is change to now
restore the original value of the option.
And so you won't see any of these messages, unless you
change the OPTION after MXG initialization, in your
code or in mine.
Thanks to H.E. Tempelmans Plat, Corus, THE NETHERLANDS.
Change 24.018 INPUT STATEMENT EXCEEDED in RACF Extended Relocate 301
VMAC80A SMF30TP2 because new TOKSUBSY='PROXY' records were not
Mar 6, 2006 supported.
Thanks to Fred Schmidt, Northern Territory Government, AUSTRALIA.
Change 24.017 Two four-byte fields were inserted in the SYTCUP segment,
VMACXAM causing INVALID DATA FOR SYTNLPMG messages, and trashed
Mar 5, 2006 data in some SYTxxxxx variables. New variables SYTPCTBY
and SYTPCTOV for each LCUCPUID are now created and kept
in the XAMSYT dataset.
-IODQDS segment no longer flagged as UNKNOWN.
Thanks to Tony Curry, BMC, USA.
Change 24.016 Datetimestamp variables WTNIDTIM, WTUOWTIM and QWHSSTCK
VMAC116 were not called by %VMXGTIME, which is used to shift date
Mar 2, 2006 time variable's values to a common time zone, if you have
LPARs or SYSTEMs on different time zones.
Note that while UOWTIME contains a datetime value, it is
never shifted, because it is used as a token to match to
other records; this part of Change 19.286 is added in the
comments in VMXGTIME as a self-reminder:
Two very important "token" variables that are necessary
to match records together, READTIME and UOWTIME, are
NOT converted by VMXGTIME.
Thanks to Chuck Hopf, Bank of America, USA.
Change 24.015 Documentation only. Identifying CRYPTO users and usage.
VMAC30 -TYPE30 variable ICSFSCNT/SMF30CSC may or may not identify
VMAC7072 crypto users. It is the number of crypto instructions
Mar 1, 2006 executed on behalf of the caller (within that caller's
address space). However, new machine instructions are
available on T-Rex processors with the CPACF feature that
provide clear key DES/TDES functions as well as hashing
functions, and applications can call these functions
directly, bypassing ICSF, and those application calls
would NOT be included in this count.
-TYPE70Y2 Crypto dataset variables added by OA10556 in
MXG 23.05 do record these CPACF function statistics:
R702NH2B='SHA-256*DATA*BYTES*HASH'
R702NH2C='SHA-256*CALLS*TO*HASH'
R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH'
-There is no separate SMF field that tells you how much
CPU time is consumed to do this encryption. However,
since the TCP/IP address space is doing the instructions
for encryption, the CPU time consumed would be included
in the regular SMF fields for that Address Space, i.e.,
both TYPE30 for the ASID and TYPE72GO for its Service
Class and Reporting Class. The CPU time consumed by the
PCIXX engine (the handshake part) will be reported in the
TYPE70Y2 dataset (from RMF 70 subtype 2 crypto records).
-The above notes were extracted from a lengthy and very
informative IBM note ASKQQA Item BDC000034378, in reply
to the question "Is there a way to measure encryption
overhead in TLS/SSL for TN3270.
Change 24.014 Support for new QWSnPSRB DB2 Address Space preemptable
VMACDB2 and non-preemptable SRB CPU time in PDB.DB2STATS dataset.
Mar 1, 2006 Variables QWSnSRBT have always contained the SRB time for
DB2 Address spaces and for the IRLM Address space, and
included both preemptable and non-preemptable SRB time.
New variables QWSnPSRB will now contain only the SRB CPU
time consumed by preemptable SRBs in the address space
specified by QWHAASID.
Note: CHANGE was made in Change 24.028.
Change 24.013 Support for new memory object data in DFSORT records:
VMAC16 ICEMON - MEMORY OBJECTS ALLOCATED
Mar 1, 2006 ICEMOUSE - MEGABYTES USED FOR MEMORY OBJECTS
ICEMOSIZ - MOSIZE VALUE IN EFFECT
MEMOBJUS - MEMORY OBJECT USED?
These data were added in z/OS DFSORT V1R5
Thanks to Rob D'Andrea, Royal Bank of Scotland, UNITED KINGDOM.
====== Changes thru 24.012 were in MXG 24.01 dated Mar 1, 2006=========
Change 24.012 INPUT STATEMENT EXCEEDED in RACF Extended Relocate 301
VMAC80A SMF30TP2 because MXG only expected 8 bytes for TOKDANAM.
Feb 27, 2006 Field expanded to 80. Values of NOCPUTIMAX, NOASSIZMAX,
NOFILEPROCMAX NOPROCUSERMAX NOTHREADSMAX NOMMAPAREAMAX
are observed as values for TOKDANAM, with no values after
the TOKDANAM field.
Thanks to Fred Schmidt, Northern Territory Government, AUSTRALIA.
Thanks to Andrew Krink, Northern Territory Government, AUSTRALIA.
Thanks to Scott Thomson, Northern Territory Government, AUSTRALIA.
Change 24.011 Negative and missing values were created in PDB.TYPE30_6
VMAC30 after Change 23.296 revised the deaccumulation logic to
Feb 27, 2006 support wrapping of ACTIVETM/RESIDTM. Additionally, the
coversion of GMT timestamps to local using GMTOFF30 fails
when ONLY subtype 6 records are read; subtype 6 records
don't contain the SYNCTIME value needed calculate the GMT
offset, so MXG gets the RETAINed GMTOFF30 from the prior
SMF 30 record of different subtype.
-The errors could also cause fewer observations to be
created in PDB.TYPE30_6.
-However, variable GMTOFF30 will still be missing value in
PDB.TYPE30_6 if no prior 30s were found, and that will be
the only clue that the INTBTIME/INTETIME/SYNCTIME values
that MXG created (for symmetry with PDB.SMFINTRV) are not
on local time, but are still on GMT.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Change 24.010 Variable LPARNSW (percent when capped) in RMF/NTRV and
VMAC7072 TYPE70 datasets could be zero when capping was active,
Feb 26, 2006 due to an error in the SPLIT70 redesign. The statement
LPARNSW=SMF70NSW should only have been executed when the
LPARNUM=PARTISHN, but it was mislocated and executed for
the last LPARNUM. And, of course, my test data did have
PARTISHN equal to the last LPARNUM, so the error was not
caught sooner.
-Array subscript out of range with exactly 60 LPARS. The
S70LPCP array was defined with 60 elements, but 61 are
needed to account for the PHYSICAL LPAR. I had assumed
than only 59 real LPARs plus the PHYSICAL was the limit.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 24.009 Variable AVGWKSET in TYPE30 datasets was too large if you
VMAC30 have IFAs, because I didn't know that PAGESECS, which is
Feb 27, 2006 the source of AVGWKSET, is based on service, and IFA time
and TCB time are included in service. IBM separates the
IFA and TCB time in RMF for performance management, and
in SMF for charge back, but doesn't separate them in the
Service Units, nor for TIME= on JCL, or in the CPUTIMER
or TIMEUSED services. zIIPs will be handled the same
way. This would be important if AVGWKSET and PAGESECS
had any real use in memory utilization measurmement, but
they don't, as PAGESECS only counts the memory frames
owned by the task when it is executing TCB or IFA. All
of the pages owned by the task while in wait state
(wait for CPU dispatch, page fault, I/O, cross memory)
are NOT counted in PAGESECS. In addition, AVGWKSET by
itself is a poor metric, because it only measures the
average number of pages that might be swapped out; it
does NOT measure memory utilization because it does NOT
indicate how LONG those pages were held. Why does the
AVGWKSET exist? Primarily for modelling programs, which
can take that as a metric, and inside the model, multiply
by the modeled duration, so the model program can measure
memory utilization (like old K-Core HOURS) and compare
with the memory capacity (GIGABYTES times 24 Hours).
And finally, tasks don't "OWN" real memory; z/OS decides
how much memory to dole out to tasks based on service
objectives, so whatever memory utilization might be
measured is not because the task 'wanted' that memory,
but because z/OS decided to give it that memory.
-Variable CSTORE30 should never have been created as such.
It does not measure CSTORE pages, but only measures the
IARVSERV Shared Pages used by this task, and thus it is
almost always zero, except for tasks that share pages.
Shared segments allow two address spaces to have
addressability to the same data, like a private CSA,
and was added for posix compliance. The shared areas
must be overtly set up by applications and I'm not
aware of any current exploiters.
To avoid confusion, and hopefully to draw your attention
to this change, CSTORE30 is now set to a missing value.
Thanks to Gennady Katsnelson, AT&T Services, Inc, USA.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Thanks to Jack Hudnall, AT&T Services, Inc, USA.
Change 24.008 Corrections for TPF Continuous Monitor date; the "QUICK
UTILTPFC FIX" that reset 3827 to 3826 was removed, since it fixed
VMACTPFC nothing and created errors. Debugging PUT statements in
Feb 23, 2006 UTILTPFC and VMACTPFC members were commented out.
-BY variables were corrected from SYSTEM SMFTIME (MVS!!)
to the TPFC variables TPFCSS TPFCSSU TPFCTIME.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.007 Support for the "Memory Monitor" that writes an SMF
ASMUSR1 record that tracks the memory object sizes by JOB.
EXUSR1ME This is in intial testing.
FORMATS You must run FORMATS and then update IMACKEEP with the
IMACUSR1 MACRO _IDUSR1 nnn %
TYPEUSR1 definition to set the SMF record number.
TYPSUSR1
VMACUSR1
VMXGINIT
Feb 22, 2006
Thanks to Dean Montevago, Visiting Nurse Service of New York, USA.
Change 24.006 APPARENT MACRO MAC102S error with ANALDB2R or READDB2 is
READDB2 corrected with this revision, although we have NOT been
Feb 22, 2006 able to replicate the error, we know the code was wrong.
Thanks to Jim Nickolas, LEXIS-NEXIS, USA.
Change 24.005 Support for APAR OA14340 (follow on the OA11675) which
VMAC30 now creates an 8-byte field (SMF30TEX) to replace 4-byte
Feb 22, 2006 SMF30TEP when TEP overflows. Variable EXCPERR=Y is set
if bit SMF30TEF is on by OA11675, but with OA14340, MXG
stores SMF30TEX in EXCPTOTL instead of SMF30TEP, and the
EXCPERR is blanked, since EXCPTOTL is now valid.
Similar change made to SMF32 fields also.
Change 24.004 ASUMTMNT failed if _GRPMNNM and _GRPMNCD were used to
ASUMTMNT define "Locations" for tape devices; Change 23.253 had
Feb 23, 2006 changed to those macro names, but ASUMTMNT still had the
initial _Gxxxxxx names that were later changed.
Thanks to Paul Bennett, JPMorganChase, ENGLAND.
Change 24.003 Toleration support for z/VM 5.2 (INCOMPATIBLE). The 10.1
VMACVMXA Application Server 10.2 record was changed from 24 to 28
Feb 23, 2006 bytes, but there is no field with the number of entries,
nor the length of the entries, so a MOD(CALDATLN,24) and
MOD(CALDATLN,28) to create LEN0D of 24 or 28 is inserted
to figure out which length is present.
Without this correction, BROKEN CONTROL RECORD messages
are printed on the log.
There are many new data fields added to the MONWRITE data
in z/VM 5.2, and these data are not yet supported in this
change. The known records and new data lengths are here
so I can whittle them down over time:
REC SKIP REC SKIP REC SKIP REC SKIP REC SKIP
1.6 12 0.22 64 3.1 220 3.14 20 6.21 8
1.14 2 0.3 96 3.19 68 3.18 40 4.9 20
4.9 20 0.21 64 3.2 80 4.3 20
0.4 12 3.3 12 3.20 108 5.9 92
Thanks to Pat Curren, SuperValu, USA.
Change 24.002 The ML-38 default DEBUG=YES should be changed to DEBUG=NO
ASMTAPEE (unless you are specifically working with MXG support).
Feb 20, 2006 The DEBUG=YES option was intended only for investigation
Apr 7, 2006 of STK HSC exit code, and should not have been enabled,
as DEBUG=YES causes a dump for any ABEND the monitor
encounters, even ones that we know can happen.
One specific known ABEND occurs when we are in cross
memory and running TIOT entries, and the chain has
been modified while we're in it: with DEBUG=NO, that
ABEND is ignored and suppressed and our code recovers
and then continues, minus only the information we now
can't find in the modified TIOT.
However, there is NO loss of data; the SMF records were
written and the monitor continued to monitor; it is only
to suppress the unneeded dumps.
While this change was dated in Feb, and should have been
made in the ASMTAPEE member in MXG 24.01, the actual
debug option was not disabled until April 7, 2006, which
is now the LAST CHANGED date in ASMTAPEE. Only if your
ASMTAPEE is dated earlier, would you need to change the
line 3248 in that ASMTAPEE at ML-38, from what was there:
DODEBUG EQU B'00001000' DO DEBUGGING STUFF
to now read:
DODEBUG EQU B'00000000' DO DEBUGGING STUFF
and then reassemble ASMTAPEE to disable DEBUG=YES.
Thanks to Alexander Raeder, ATOS ORIGIN, GERMANY.
Thanks to Beau Chavis, Bank of America, GERMANY.
Change 24.001 The DB2 Audit Trace IFCIDs 140, 141, 142, and 145 caused
VMAC102 INPUT STATEMENT EXCEEDED error if the SQL Text length was
Feb 20, 2006 more than 4000 bytes. MXG used length field QW014nLL in
its INPUT QW014nTX $VARYING. QW014nLL, but the ERROR made
me RTFM ("F=Fine"), amd I found that IBM did document the
truncation, providing adjacent QW014nLE field with the
length of the truncated SQL text in the record, so it is
now used for the SQL text INPUTs.
And IBM doesn't always store exactly the first 4000;
one record had QW0145LL=13120, but QW0145LE=3980.
Thanks to Bjorn Helgestad, VPS ASA, NORWAY.
Thanks to Steinar Amot, VPS ASA, NORWAY.
LASTCHANGE: Version 24.