COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 28.28
=========================member=CHANGE28================================
/* COPYRIGHT (C) 1984-2011 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 28.28 is dated Jan 18, 2011, thru Change 28.331.
MXG Newsletter FIFTY-SEVEN is dated Jan 18, 2011.
Prelim MXG Version 28.28 was dated Jan 12, 2011, thru Change 28.326.
Interim MXG Version 28.09 was dated Jan 11, 2011, thru Change 28.325.
MXG Version 28.08 was dated Dec 13, 2010, thru Change 28.297.
MXG Version 28.07 was dated Nov 5, 2010, thru Change 28.265.
MXG Version 28.06 was dated Oct 7, 2010, thru Change 28.239.
MXG Version 28.05 was dated Aug 18, 2010, thru Change 28.187.
MXG Newsletter FIFTY-SIX was dated Aug 18, 2010.
First MXG Version 28.05 was dated Aug 17, 2010, thru Change 28.186.
MXG Version 28.04 was dated Jul 5, 2010, thru Change 28.152.
MXG Version 28.03 was dated May 25, 2010, thru Change 28.114.
MXG Version 28.02 was dated Apr 14, 2010, thru Change 28.081.
MXG Version 28.01 was dated Mar 9, 2010, thru Change 28.047.
MXG Version 27.27 was dated Jan 20, 2010, thru Change 27.361.
MXG Version 27.27 was the 2010 "Annual Version".
MXG Newsletter FIFTY-FIVE was dated Jan 20, 2010.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 28.28 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 28.28.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================
I. MXG Version 28.28 dated Jan 18, 2011, thru Change 28.331.
Major enhancements added in MXG 28.28, dated Jan 18, 2011
TYPEDB2 28.326 Invalid DB2 V10 Distributed Header protected in MXG.
There will be an IBM APAR, but this change is needed
to avoid the ABEND with earlier MXG versions, so, now
MXG 28.28 IS NOW REQUIRED FOR DB2 V10.1
to ensure your daily jobs doesn't ABEND.
APAR PM32425 has been opened, no PTF as of Feb 21.
WEEKBLD 28.324 Weekly exposure to DATASET TYPE72DL NOT SORTED.
MONTHBLD 28.324 Monthly exposure to DATASET TYPE72DL NOT SORTED.
BLDSMPDB 28.324 BLDSMPDB exposure to DATASET TYPE72DL NOT SORTED.
-If you have tailored those members and TYPE72DL is
built, you need to EDIT those members per the text
in that Change to avoid the possible ABEND of your
weekly or monthly build jobs.
EXITCICS 28.298 EXITCICS decompresses SMF 100,101,102,110 and 112.
MXG enhanced INFILE exit for CICS now supports DB2.
TYPE89 28.331 INVALID DATA FOR SMF89CZT if APAR OA31615 installed.
TYPE111 28.329 CTG records had zero observations in TY111CXI "IPIC".
JCLINSTT 28.328 Complete JCL example to ftp/unterse/install on z/OS.
TYPENDM 28.327 Connect Direct/NDM 'RT' record INCOMPATIBLY changed.
TYPE102 28.325 DB2 SQL-text variables only 100 bytes if COMPRESS=NO.
TYPEIMSA 28.311 Support for IMS/DBCTL transactions in IMSTRAN.
TYPEIMS7 28.310 Support for IMS/DBCTL transactions in IMS0708.
TYPE0 28.313 Variable CVTTZ in TYPE0 could be one second wrong.
BUILDPDB 28.305 PDB.NJEPURGE did not contain all NJE-variables.
ANALDUPE 28.308 Removal of Duplicate SMF (or any) records.
TYPEVMXA 28.315 PFXCPUAD in VXSYTCUM is the LCPUADDR, no CPUID.
TYPEVMXA 28.307 Short LINUXKRNL MONWRITE record caused errors.
UTILGETM 28.312 No Reporting Class data in SMFSMALL with NRECORD=10.
TYPE89 28.304 SMF 89 with no usage segment INPUT EXCEEDED error.
TYPE30 28.302 TYPE30MU duplicate records exist, non-dupes removed.
TYPETCP 28.300 TYPETCP (SMF 118) Port Numbers (Dec) wrong on ASCII.
TYPE70EN 28.299 Wrong values for CPUID=0 in PDB.TYPE70EN.
Major enhancements added in MXG 28.08, dated Dec 13, 2010
TYPE119 28.293 Support for OpenSSH SMF 119 subtypes 96-98.
TYPE113 28.279 "Near duplicate" ASUM113 intervals are corrected.
TYPE89 28,282 Support for APAR OA31615, adds zIIP/zAAP CPU times.
TYPENMON 28.275 Support for NMON FCREAD/FCWRITE/XFERIN/XFEROUT record
TYPETNG 28.273 Support for more than 9999 instances in CA NSM/TNG.
TYPETMVT 28.287 Support for ASG-TMON for VTAM subtype 'SX' record.
TYPE110 28.285 CICS Statistics Subtype 2 STID=143 corrected.
ASUMUOWT 28.284 ASUMUOWT (for ASG-TMON MRO) revised to use VMXGUOW.
ASUMCICR 28.281 Count/average response time by DATE for each APPLID.
DB2ACCT 28.277 NETSNAME/UOWTIME only created for QWHCATYP=4 (CICS).
TYPE89 28.272 SMF89HOF/SMF89DTO for SCRT don't use last 3 nybbles.
WEEKBLD 28.269 TYPE72DL NOT SORTED after Clock Set Back.
ANALDBJS 28.290 DB2 analysis adds JESNR and REAdTIME to DB2ACCT.
TYPE6156 28.289 Variables GATLIMIT and GATCNT added to TYPE6156.
UTILNPRT 28.268 Identify non-print chars, for SAS Enterprise Guide.
Major enhancements added in MXG 28.07, dated Nov 5, 2010
TYPEDB2 28.264 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE:
MXG 28.06 was required to process the V10 data, but
now, MXG 28.07 has full support plus the below
documentation.
TYPEOMMQ 28.263 Support for IBM/OMEGAMON XW MQ flat file (INCOMPAT)
TYPEMIM 28.262 Support for CA MIM RESOURCE SHARING R11.7 (COMPAT)
GRAFCEC 28.261 SAS/GRAPH example charts CEC Utilization by engine
TYPETPX 28.260 IP address and Port Number now decoded in TPX SMF.
UTILEXCL 28.259 Spurious "WRONG LENGTH OF 200 FOR CMRDATA"
TYPE120 28.258 Support for WebSphere ID=120 SUBTYPE=20 records
ANALID 28.257 ERROR: VARIABLE IDANDSUM ... with PDB,DISP=OLD
EXITCICS 28.251 ASMA144E Begin-to-continue due to char in col 72.
READDB2 28.250 COPYONLY logic now works.
VMXGSUM 28.249 VMXGSUM enhanced with MODE and MEDIAN statistics
TYPE110 28.247A Example using _Kdddddd to create new datasets revised
TYPE30 28.246 New CPITCxTM/CPISRxTM wrong in MXG 28.06.
TYPE7072 28.246 CP eng 64-95 vars shouldn't have been kept in TYPE70.
TYPESTC 28.244 STC/STK/Oracle VSM user SMF records support revised.
TYPE7072 28.242 In-Ready Work Unit SMF70U00-U15, etc were all wrong.
Major enhancements added in MXG 28.06, dated Oct 7, 2010
TYPEWSMQ 28.233 Support for WebSphere MQ Version 7 Accounting Data
TYPEDB2 28.222 ITRM only, DB2STAT4 NOT SORTED ERROR.
ASUMDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
TRNDDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
EXITCICS 28.223 Support for DB2 V10 Compressed SMF records.
DFH$MOLS 28.223 JCL example to use IBM CICS decompression utility.
TYPEITRF 28.227 INPUT STATEMENT EXCEEDED RECORD LENGTH type=17x.
TYPEIMFS 28.193 Full support for IMF records in SMF format.
TYPE113 28.226 Variable LPBUSY,LPARBUSY replaced LPARCPU.
TYPE74 28.212 TYPE74ID (small) created, saves pass of TYPE74CA.
Major enhancements added in MXG 28.05, dated Aug 18, 2010
The z196 processor with more than 64 engines REQUIRES MXG 28.05.
A z196 with LESS THAN 64 engines DOES NOT require MXG 28.05, as
long as the operating system is z/OS 1.11 or earlier.
z/OS 1.12 REQUIRES MXG 28.05.
DO NOT USE MXG 28.04 WITH z/OS 1.12 RMF data records.
IBM Maintenance APARs OA30563,OA33976 REQUIRES MXG 28.05.
Many 28.175 Support for z/OS 1.12 (REQUIRES MXG 28.05).
DO NOT USE MXG 28.04 WITH z/OS 1.12 DATA - INCOMPAT.
TYPE70 28.175 Support for z196: REQUIRED ONLY WITH GT 64 ENGINES.
(Lots of new data added compatibly.)
TYPE113 28.166 Major revision - TYPE113 - John Burg's SHARE 2010.
(Calculation of RNI, new z196 fields, new metrics).
TYPE119 28.175 Support for SMF 119 new subtypes 32-37 and 48-52.
TYPEITRF 28.162 Support for ITRF V420 IF2 (COMPATIBLE).
TYPECTCP 28.160 Support for CleverView GMT offset, CTCPIPAD fixed.
TYPE42 28.158 Support for APAR OA31648 TYPE42D1/D3 buff get retries
TYPEVM 28.157 Support for VM ACCOUNT ID='09' ISFC record.
TYPE102 28.156 Support for IFCID=27 specific variables.
TYPENMON 28.176 Support for SARMON - Solaris SAR in NMON format.
IMACCADI 28.172 Support for CA-Dispatch V11 SMF 6 INCOMPATIBLE.
TYPETPFC 28.152 Support for zTPFC TPF Continuous Monitoring updates.
TYPEZCOS 28.151 Support for zCost AutoSoftcapping V 1.5.00 SMF.
UTILPDSL 28.179 Utility to read PDS/PDSE directories of a concat.
BLDSMPDB 28.177 Continued minor enhancements.
IMACZDAT 28.174 Example to set ZDATE when you rebuild a past PDB.
ANALCAPD 28.169 Estimate the impact of a Defined Capacity Limit.
MULTIPDB 28.168 Create a PDB library with all datasets from many PDBs
TYPEIMS 28.165 LCODE=56x TPCPSSTY09x INPUT STATEMENT EXCEEDED.
TYPE110 28.154 Improved detection of EXCLUDED CICS fields.
TYPEXAM 28.153 XAM TCP dataset's TOTCPU incorrectly divided by 100.
TYPE42 28.150 Type 42 subtype 15 correction for TYPE42S1 dataset.
Major enhancements added in MXG 28.04, dated Jul 5, 2010
TYPE113 28.140 Major revision to SMF 113 support, TYPE70PR vars add.
ANALDB2R 28.146 Major enhancement to DB2PM-like reporting.
TYPESVIE 28.138 Support for SysView Subtype 3 records.
TYPEIMFS 28.137 Support for BMC IMF records written in SMF format.
TYPE120 28.133 Support for WebSphere SMF 120 Subtype 20, untested.
TYPESAVR 28.127 Support for revised CA $AVERS SMF record (INCOMPAT).
TYPEMXI 28.126 Support for Rocket Software MXG User SMF record.
TYPENTSM 28.119 Support for Performance Sentry NTSMF Version 3.1.4.4.
TYPEMVAO 28.118 Support for BMC Mainview Auto Operator data file.
TYPE102 28.116 Support for SMF 102 IFCID 263 decodes unique fields.
BLDSMPDB 28.125 Support for Week/Month if first-day-of-week NOT MON.
CONFIGVx 28.128 ERROR APPARENT MACRO TRIM NOT RESOVED: DOCUMENTATION.
VMXGSRCH 28.147 Kewl Tool. Find all instances of VARIABLE='VALUE'.
BUILDPDB 28.139 Recently added SMF30xxx variables kept in PDB.STEPS.
UTILWORK 28.123 Utility for TYPE72GO to assist workload definitions.
Major enhancements added in MXG 28.03, dated May 25, 2010
TYPEWPMO 28.086 Support for Windows Performance Monitor PERFMON file.
TYPECTCP 28.108 Support for CleverView for TCP/IP TN3270 SMF subtype.
TYPE80A 28.107 TOKDANAM LDAPHOST,BINDDN,BINDPW,APPLNAM,UTYPE,JPNUM.
TYPE92 28.106 SMF92PPN, Path Name, was blank.
VMXGSUM 28.105 Optional KEEPWEEK/MNTH/YEAR/DAYS/AFTER keeps TRENDs.
TYPE7072 28.099 Variable CPULHKTM, CPU TIME Lock Promoted, TYPE72GO.
VMXGSET 28.098 DSETOPT= optional argument for data set options.
SMFRECNT 28.089 BUILDPDBs PDB.SMFRECNT now has bytes and counts.
TYPE110 28.087 Internal Decompression Algorithm use now ERROR:'d.
TYPECIMS 28.084 BMC IMF INPUTCLS and LASTCLAS variables restored.
READDB2 28.083 READDB2/ANALDB2R did not honor MACDB2H/MACKEEP.
FORMATS 28.082 UDDDDDD, all and $MGDDDSN updated.
Major enhancements added in MXG 28.02, dated Apr 14, 2010
TYPE113 28.075 John Burg formulas for TYPE113 HIS data are added.
VMXGINIT 28.079A Test for NOWORKINIT and USER ABEND 990 were REMOVED.
VMXGINIT 28.081 OPTIONS VARLENCHK=NOWARN eliminates SAS V9.2 WARNINGS
VMXGINIT 28.057 ERROR MACRO %ABORT IS NOT IMPLEMENTD, SAS 8.2 ONLY.
TYPE84 28.077 Support for all JES3 JMF TYPE84 subtypes.
ASMIMSL6 28.066 Support for IMS Version 11 (INCOMPATIBLE).
TYPEIMS7 28.066 Support for IMS Version 11 (INCOMPATIBLE).
TYPEMVCI 28.065 Support for BMC CICS CMRDETL C660 for CICS/TS 4.1
TYPEDB2 28.051 Support for DB2 APAR PK62161 new SQL Counters.
TYPETMNT 28.079 WARNING: TOTAL LENGTH OF VARIABLES MUST BE LT 32760.
TYPEDB2 28.073 DB2STATS had missing values for QW0225 variables.
TYPE42 28.072 TYPE42X4 Above the BAR LRU dataset variables wrong.
BUILDPDB 28.071 PDB.STEPS/PDB.JOBS duplicates if FLUSHED steps.
MXGSAS92 28.070 SAS 9.2 TS2M2 DSNAMES may have changed
TYPERMVV 28.048 RMFV CPUG3 was misaligned in z/OS 1.11
Major enhancements added in MXG 28.01, dated Mar 9, 2010
Error circumvention:
EXIT112 28.027* Do NOT assemble EXIT112 for SMF 110/112, use EXITCICS
Errors fixed:
ASMTAPEE 28.041 Do NOT use ASMTAPEE ML-45/46, CPU SPIKE: ML-47 fixed.
TYPEVMXA 28.025 MXG CPU Loop in TYPEVMXA, new CEX3C PRCAPMCT=9 crypto
TYPECIMS 28.028 BMC IMF INPUT STATEMENT EXCEEDED, short record.
TYPEEDGR 28.029 RMM datetime vars have always been wrong time zone.
TYPE120 28.038 SMF 120 SUBTYPE 9 INPUT STATEMENT EXCEEDED RECORD
ANALZPCR 28.021 Major fixes/enhancements for complex zPCR models.
TYPE0 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 fixed.
ASUMTAPE 28.008 SPIN.SPINSYSL dataset could grow forever.
New stuff:
VMXGFIND 28.012 Kewl tool, find all obs in all datasets meeting test,
(like all obs with JOB='CICS' in all PDB datasets).
TYPESTC 28.005 Support for Sun StorageTek VSM Version 6.2 and 7.0.
TYPE89 28.015 Support for z/TPM SMF 89 record, subtype wrong byte.
TYPENTSM 28.042 New Sentry VM 3.1.4.3 adds VMWARE objects/metrics.
TYPE30 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71.
VMXGINIT 28.023 New MXGERROR/USER ABEND 990 if NOWORKINIT is enabled.
TYPEZTPF 28.043* zTPF has major revisions in Performance Data
TYPETMS 28.040 CA-1 Retention and VMRECORD extensions, need data.
Changes:
TYPE74 28.039 R7451RID now one byte, R7451FLG/TYPE74CA overlays.
BUILDPDB 28.037 PDB.SMFINTRV will have EXCP/IOTM counts for FLUSHED.
TYPE103 28.036 TYPE1032 deaccum needed PORTNR, label changed.
VGETOBS 28.034 %TRIM() references here removed, still in VMXGSUM.
IMACICMR 28.032 Protect 200-byte CMRDATA on CICS/TS 3.2 (s/b 256).
VGETDDS 28.014 Colon in DDNAMES= worked only with DDNAMES=PDB:)
TYPEDB2 28.010 Variable SHIFT (from QWHSSTCK, END) kept in datasets.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
MXG 28.28 executes best with SAS V9.2, or with SAS V9.1.3 with
Service Pack 4, on any supported SAS platform.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS/DB2 Decompression Infile Exit.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level B" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I can not guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2 ASAP, FOR BOTH OF US, TO AVOID FIXED PROBLEMS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2:
The standard SAS JCL Procedure can be used for MXG:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
instead of using the MXGSAS92 JCL Procedure example.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, and V9.2.
V9.2-created "PDBs" can be read/written by SAS V8.2 or V9.1.3,
and vice versa.
MXG Versions 26.03+ execute with SAS V9.2 with NO (new) WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as a absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG QA tests are executed on z/OS with SAS V9.1.3 and V9.2 and
on Windows XP with 32-bit INTEL, and on Windows Seven Ultimate
both 32-bit and 64-bit OS on 64-bit hardware, but MXG is installed
on many more hardware and software platforms: since they all work,
we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.4 requires MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for "MXG Support for WPS Software"
IV. MXG Version Required for Hardware, Operating System Release, etc.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990 8.8
MVS/ESA 4.2 Mar 29, 1991 9.9
MVS/ESA 4.2.2 Aug 15, 1991 9.9
MVS/ESA 4.3 Mar 23, 1993 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30, 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28, 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28, 1997 15.02
OS/390 2.4.0 Sep 28, 1997 15.06
OS/390 2.5.0 Feb 24, 1998 15.06
OS/390 2.6.0 Sep 24, 1998 16.04
OS/390 2.7.0 Mar 26, 1999 16.09
OS/390 2.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DB2 6.1.0 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 Full plus Compressed. Nov 1, 2010 28.07*
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 28.28
DFSMS/MVS 1.1 Mar 13, 1993 11.11
DFSMS/MVS 1.2 Jun 24, 1994 12.02
DFSMS/MVS 1.3 Dec 29, 1995 13.09
DFSMS/MVS 1.4 Sep 28, 1997 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998 16.04
DFSMS/MVS 1.5 ??? ??, 1999 16.04
DFSORT SMF V1R5 Mar 1, 2006 24.02
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
MQ Series 2.1.0 Oct 2, 1999 17.07
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
MQ Series 7.0 ??? ??, 2009 *28.06
NETVIEW 3.1 type 37 ??? ??, 1996 14.03
NPM 2.0 Dec 17, 1993 12.03
NPM 2.2 Aug 29, 1994 12.05
NPM 2.3 ??? ??, 1996 15.08
NPM 2.4 Nov 18, 1998 17.01
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
WebSphere 7.0 Oct 7, 2010 28.06
DOS/VSE POWER V6.3.0 Dec 19, 1998 16.08
VM/ESA 2.0 Dec 23, 1992 10.04
VM/ESA 2.1 Jun 27, 1993 12.02
VM/ESA 2.2 Nov 22, 1994 12.06
VM/ESA 2.3 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
IMS log 11.0 Apr 1, 2010 28.02*
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
AS400 4.4.0 Sep 27, 1999 17.07
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1+) 16.04
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
V. Incompatibilities and Installation of MXG 28.28.
1. Incompatibilities introduced in MXG 28.28:
a- Changes in MXG architecture made between 28.28 and prior versions
that can introduce known incompatibilities.
1. -The WEEKBLD/MONTHBLD may fail with TYPE72DL NOT SORTED if you
have a tailored WEEKBLD/MONTHBLD that references TYPE72DL. The
only prevention is to change the sort order in WEEKBLD/MONTHBLD
BEFORE you create your weekly with 28.28 to this order:
MACRO _DSET TYPE72DL %
MACRO _BYLIST SYSPLEX SYSTEM SYSNAME STARTIME %
to eliminate the exposure to this rare possible error.
-Or, the WEEKBLD/MONTHBLD sort order testing can be disabled
(as documented in comments) using:
//SYSIN DD *
%LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;
%INCLUDE SOURCLIB(MONTHBLD);
-Or with BLDSMPDB, specify SORTEDBY=NO to disable the sort test.
See Change 28.324.
2. -If you use ASUMDB2x or ASUMDBSx datasets, see Change 28.220.
3. -If you have tailored MXG DB2 Processing using _NDB2 and then
invoke _SDB2STS (to create PDB.DB2STATS), you must also have
MACRO _WDB2ST4 DB2STAT4 % inserted AFTER the _NDB2 so that
the PDB.DB2STAT4 dataset exists when PDB.DB2STATS is created.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINST9 for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes in MXG 28.28 after MXG 27.27:
Dataset/
Member Change Description
Many 28.175 Support for z/OS 1.12 (COMPATIBLE)
ANALCAPD 28.169 Estimate the impact of a Defined Capacity Limit.
ANALDB2R 28.004 Extreme Detail DB2 Trace Report PMTRC01 revised.
ANALDB2R 28.146 Major enhancement to DB2PM-like reporting.
ANALDB2R 28.214 ANALDB2R report select did not honor BEGTIME/ENDTIME.
ANALDBJS 28.290 DB2 analysis adds JESNR and REAdTIME to DB2ACCT.
ANALDUPE 28.308 Removal of Duplicate SMF (or any) records.
ANALID 28.257 ERROR: VARIABLE IDANDSUM ... with PDB,DISP=OLD
ANALZPCR 28.021 Major fixes/enhancements for complex zPCR models.
ASMIMSL6 28.066 Support for IMS Version 11 (INCOMPATIBLE).
ASMTAPEE 28.041 Do NOT use ASMTAPEE ML-45/46, CPU SPIKE: ML-47 fixed.
ASUMCICR 28.281 Count/average response time by DATE for each APPLID.
ASUMDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
ASUMTAPE 28.008 Large size SPIN.SPINMOUN,SPIN.SPINSYSL found, shrunk.
ASUMTAPE 28.008 SPIN.SPINSYSL dataset could grow forever.
ASUMUOW 28.124 WTIRIOTM in PDB.ASUMUOW could be larger than IRESPTM.
ASUMUOWT 28.284 ASUMUOWT (for ASG-TMON MRO) revised to use VMXGUOW.
BLDSMPDB 28.125 Support for Week/Month if first-day-of-week NOT MON.
BLDSMPDB 28.177 Continued minor enhancements.
BLDSMPDB 28.218 Includes ASUMDBAA/TRNDDBAA caused errors, replaced.
BUILDPDB 28.037 PDB.SMFINTRV will have EXCP/IOTM counts for FLUSHED.
BUILDPDB 28.071 PDB.STEPS/PDB.JOBS duplicates if FLUSHED steps.
BUILDPDB 28.139 Recently added SMF30xxx variables kept in PDB.STEPS.
BUILDPDB 28.305 PDB.NJEPURGE did not contain all NJE-variables.
CONFIGVx 28.128 ERROR APPARENT MACRO TRIM NOT RESOVED: DOCUMENTATION.
DB2ACCT 28.277 NETSNAME/UOWTIME only created for QWHCATYP=4 (CICS).
DFH$MOLS 28.223 JCL example to use IBM CICS decompression utility.
EXIT112 28.027* Do NOT assemble EXIT112 for SMF 110/112, use EXITCICS
EXITCICS 28.223 Support for DB2 V10 Compressed SMF records.
EXITCICS 28.251 ASMA144E Begin-to-continue due to char in col 72.
EXITCICS 28.298 EXITCICS decompresses SMF 100,101,102,110 and 112.
FIXTRNCD 28.049 TRANSCODE attribute can be added to old PDBs
FORMATS 28.082 UDDDDDD, $MGDDDDD and $MGDDDSN updated.
GRAFCEC 28.261 SAS/GRAPH example charts CEC Utilization by engine
IMACCADI 28.172 Support for CA-Dispatch V11 SMF 6 INCOMPATIBLE.
IMACICMR 28.032 Protect 200-byte CMRDATA on CICS/TS 3.2 (s/b 256).
IMACZDAT 28.174 Example to set ZDATE when you rebuild a past PDB.
JCLINSTT 28.328 Complete JCL example to ftp/unterse/install on z/OS.
JCLTEST9 28.330 Prelim 28.28 only, default ASUMUOW could fail.
MULTIPDB 28.168 Create a PDB library with all datasets from many PDBs
MXGSAS92 28.070 SAS 9.2 TS2M2 DSNAMES may have changed
READDB2 28.083 READDB2/ANALDB2R did not honor MACDB2H/MACKEEP.
READDB2 28.211 COPYONLY argument wrote ALL SMF records.
READDB2 28.250 COPYONLY logic now works.
SASAUTOS 28.194 Invalid 'BA'x in TRIM member on z/OS ERROR 22.
SMFRECNT 28.089 BUILDPDBs PDB.SMFRECNT now has bytes and counts.
TRNDDB2- 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx revisions.
TYPE0 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 fixed.
TYPE0 28.313 Variable CVTTZ in TYPE0 could be one second wrong.
TYPE102 28,206 APPTUNE SMF 102 IFCID 8133 invalid offset ERROR.
TYPE102 28.116 Support for SMF 102 IFCID 263 decodes unique fields.
TYPE102 28.156 Support for IFCID=27 specific variables.
TYPE102 28.325 DB2 SQL-text variables only 100 bytes if COMPRESS=NO.
TYPE103 28.036 TYPE1032 deaccum needed PORTNR, label changed.
TYPE110 28.087 Internal Decompression Algorithm use now ERROR:'d.
TYPE110 28.134 INVALID STIDLEN=0 after STID=116 was harmless, fixed.
TYPE110 28.154 Improved detection of EXCLUDED CICS fields.
TYPE110 28.247A Example using _Kdddddd to create new datasets revised
TYPE110 28.285 CICS Statistics Subtype 2 STID=143 corrected.
TYPE111 28.329 CTG records had zero observations in TY111CXI "IPIC".
TYPE113 28.075 John Burg formulas for TYPE113 HIS data are added.
TYPE113 28.140 Major revision to SMF 113 support, TYPE70PR vars add.
TYPE113 28.166 Major revision - TYPE113 - John Burg's SHARE 2010.
TYPE113 28.226 Variable LPBUSY,LPARBUSY replaced LPARCPU.
TYPE113 28.279 "Near duplicate" ASUM113 intervals are corrected.
TYPE116 28.221 WebSphere MQ 7.01 INVALID WQ SEGMENT error messages.
TYPE119 28.175 Support for SMF 119 new subtypes 32-37 and 48-52.
TYPE119 28.293 Support for OpenSSH SMF 119 subtypes 96-98.
TYPE120 28.038 SMF 120 SUBTYPE 9 INPUT STATEMENT EXCEEDED RECORD
TYPE120 28.133 Support for WebSphere SMF 120 Subtype 20, untested.
TYPE120 28.258 Support for WebSphere ID=120 SUBTYPE=20 records
TYPE30 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71.
TYPE30 28.246 New CPITCxTM/CPISRxTM wrong in MXG 28.06.
TYPE30 28.302 TYPE30MU duplicate records exist, non-dupes removed.
TYPE42 28.072 TYPE42X4 Above the BAR LRU dataset variables wrong.
TYPE42 28.150 Type 42 subtype 15 correction for TYPE42S1 dataset.
TYPE42 28.158 Support for APAR OA31648 TYPE42D1/D3 buff get retries
TYPE6156 28.289 Variables GATLIMIT and GATCNT added to TYPE6156.
TYPE70 28.175 Support for z196: INCOMPAT ONLY WITH GT 64 ENGINES.
TYPE7072 28.099 Variable CPULHKTM, CPU TIME Lock Promoted, TYPE72GO.
TYPE7072 28.242 In-Ready Work Unit SMF70U00-U15, etc were all wrong.
TYPE7072 28.246 CP eng 64-95 vars shouldn't have been kept in TYPE70.
TYPE70EN 28.224 TYPE70EN PCTCPUBY was 100% for a parked CP engine.
TYPE70EN 28.299 Wrong values for CPUID=0 in PDB.TYPE70EN.
TYPE74 28.039 R7451RID now one byte, R7451FLG/TYPE74CA overlays.
TYPE74 28.208 R7451TIM wrong, R7451CT3/CT4/PRT/PWT also wrong.
TYPE74 28.212 TYPE74ID (small) created, saves pass of TYPE74CA.
TYPE80A 28.107 TOKDANAM LDAPHOST,BINDDN,BINDPW,APPLNAM,UTYPE,JPNUM.
TYPE84 28.077 Support for all JES3 JMF TYPE84 subtypes.
TYPE89 28,282 Support for APAR OA31615, adds zIIP/zAAP CPU times.
TYPE89 28.015 Support for z/TPM SMF 89 record, subtype wrong byte.
TYPE89 28.272 SMF89HOF/SMF89DTO for SCRT don't use last 3 nybbles.
TYPE89 28.304 SMF 89 with no usage segment INPUT EXCEEDED error.
TYPE89 28.331 INVALID DATA FOR SMF89CZT if APAR OA31615 installed.
TYPE92 28.106 SMF92PPN, Path Name, was blank.
TYPECIMS 28.028 BMC IMF INPUT STATEMENT EXCEEDED, short record.
TYPECIMS 28.084 BMC IMF INPUTCLS and LASTCLAS variables restored.
TYPECTCP 28.108 Support for CleverView for TCP/IP TN3270 SMF subtype.
TYPECTCP 28.160 Support for CleverView GMT offset, CTCPIPAD fixed.
TYPEDB2 28.010 Variable SHIFT (from QWHSSTCK, END) kept in datasets.
TYPEDB2 28.051 Support for DB2 APAR PK62161 new SQL Counters.
TYPEDB2 28.073 DB2STATS had missing values for QW0225 variables.
TYPEDB2 28.222 ITRM only, DB2STAT4 NOT SORTED ERROR.
TYPEDB2 28.264 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE.
TYPEDB2 28.326 Invalid DB2 V10 Distributed Header protected in MXG.
TYPEEDGR 28.029 RMM datetime vars have always been wrong time zone.
TYPEIMFS 28.137 Support for BMC IMF records written in SMF format.
TYPEIMFS 28.193 Full support for IMF records in SMF format.
TYPEIMS 28.131 IMS Log 56X record subtype 15x INVALID DATA/STOPOVER.
TYPEIMS 28.165 LCODE=56x TPCPSSTY09x INPUT STATEMENT EXCEEDED.
TYPEIMS7 28.066 Support for IMS Version 11 (INCOMPATIBLE).
TYPEIMS7 28.310 Support for IMS/DBCTL transactions in IMS0708.
TYPEIMSA 28.311 Support for IMS/DBCTL transactions in IMSTRAN.
TYPEITRF 28.162 Support for ITRF V420 IF2 (COMPATIBLE).
TYPEITRF 28.227 INPUT STATEMENT EXCEEDED RECORD LENGTH type=17x.
TYPEMIM 28.262 Support for CA MIM RESOURCE SHARING R11.7 (COMPAT)
TYPEMVAO 28.118 Support for BMC Mainview Auto Operator data file.
TYPEMVCI 28.065 Support for BMC CICS CMRDETL C660 for CICS/TS 4.1
TYPEMXI 28.126 Support for Rocket Software MXG User SMF record.
TYPENDM 28.327 Connect Direct/NDM 'RT' record INCOMPATIBLY changed.
TYPENMON 28.176 Support for SARMON - Solaris SAR in NMON format.
TYPENMON 28.275 Support for NMON FCREAD/FCWRITE/XFERIN/XFEROUT record
TYPENTSM 28.042 New Sentry VM 3.1.4.3 adds VMWARE objects/metrics.
TYPENTSM 28.119 Support for Performance Sentry NTSMF Version 3.1.4.4.
TYPEOMMQ 28.263 Support for IBM/OMEGAMON XW MQ flat file (INCOMPAT)
TYPERMVV 28.048 RMFV CPUG3 was misaligned in z/OS 1.11
TYPESAVR 28.127 Support for revised CA $AVERS SMF record (INCOMPAT).
TYPESTC 28.005 Support for Sun StorageTek VSM Version 6.2 and 7.0.
TYPESTC 28.005 Support for Sun StorageTek Version 6.2 and 7.0
TYPESTC 28.244 STC/STK/Oracle VSM user SMF records support revised.
TYPESVIE 28.138 Support for SysView Subtype 3 records.
TYPETCP 28.300 TYPETCP (SMF 118) Port Numbers (Dec) wrong on ASCII.
TYPETMNT 28.079 WARNING: TOTAL LENGTH OF VARIABLES MUST BE LT 32760.
TYPETMS 28.040 CA-1 Retention and VMRECORD extensions, need data.
TYPETMS5 28.148 TMS DEVTYPE was blank for TRTCH 'F0'x thru 'FF'x.
TYPETMVT 28.287 Support for ASG-TMON for VTAM subtype 'SX' record.
TYPETNG 28.216 NSM RH018 defective records with zero values.
TYPETNG 28.273 Support for more than 9999 instances in CA NSM/TNG.
TYPETPFC 28.152 Support for zTPFC TPF Continuous Monitoring updates.
TYPETPX 28.260 IP address and Port Number now decoded in TPX SMF.
TYPEVM 28.157 Support for VM ACCOUNT ID='09' ISFC record.
TYPEVMXA 28.025 MXG CPU Loop in TYPEVMXA, new CEX3C PRCAPMCT=9 crypto
TYPEVMXA 28.307 Short LINUXKRNL MONWRITE record caused errors.
TYPEVMXA 28.315 PFXCPUAD in VXSYTCUM is the LCPUADDR, no CPUID.
TYPEWPMO 28.086 Support for Windows Performance Monitor PERFMON file.
TYPEXAM 28.153 XAM TCP dataset's TOTCPU incorrectly divided by 100.
TYPEZCOS 28.151 Support for zCost AutoSoftcapping V 1.5.00 SMF.
TYPEZTPF 28.043* zTPF has major revisions in Performance Data
UTILBLDP 28.209 INCLAFTR=BUILD005,BUILDPDB=NO failed.
UTILEXCL 28.259 Spurious "WRONG LENGTH OF 200 FOR CMRDATA"
UTILGETM 28.312 No Reporting Class data in SMFSMALL with NRECORD=10.
UTILNPRT 28.268 Identify non-print chars, for SAS Enterprise Guide.
UTILPDSL 28.179 Utility to read PDS/PDSE directories of a concat.
UTILWORK 28.123 Utility for TYPE72GO to assist workload definitions.
VGETDDS 28.014 Colon in DDNAMES= worked only with DDNAMES=PDB:)
VGETOBS 28.034 %TRIM() references here removed, still in VMXGSUM.
VMXGFIND 28.012 Kewl tool, find all obs in all datasets meeting test.
VMXGINIT 28.023 MXGERROR/USER ABEND 990 if NOWORKINIT is enabled.
VMXGINIT 28.057 ERROR MACRO %ABORT IS NOT IMPLEMENTD, SAS 8.2 ONLY.
VMXGINIT 28.081 OPTIONS VARLENCHK=NOWARN eliminates SAS V9.2 WARNINGS
VMXGSET 28.098 DSETOPT= optional argument for data set options.
VMXGSRCH 28.147 Kewl Tool. Find all instances of VARIABLE='VALUE'.
VMXGSUM 28.105 Optional KEEPWEEK/MNTH/YEAR/DAYS/AFTER keeps TRENDs.
VMXGSUM 28.249 VMXGSUM enhanced with MODE and MEDIAN statistics
WEEKBLD 28.324 WEEKBLD/MONTHBLD/BLDSMPDB dataset TYPE72DL NOT SORTED
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 28.
====== Changes thru 28.331 were in MXG 28.28 dated Jan 18, 2011=========
Change 28.331 INVALID DATA FOR SMF89CZT if APAR OA31615 is installed.
VMAC89 Change 28.282 claimed support, but without test data, and
Jan 15, 2011 the error was because MXG input SMF89CNO as two bytes but
it is a four byte field, causing the misalignment.
Jan 19: I didn't get records in time for 28.28 and this
change did NOT correct this error, but Change 29.002 did.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.330 Prelim 28.28 default ASUMUOW in JCLTEST9 (does NOT read
VMXGUOW ANY input) failed, on all platforms with SAS V9.1.3 or on
Jan 15, 2011 SAS V9.2 on z/OS. There is NO error if you have IMACUOW
tailored to create observations in PDB.ASUMUOW. The
error message is a NO BY VARIABLES ERROR, but the actual
error was a DATA SET NOT FOUND error that was masked by
the OPTIONS NODSNFERR in VMXGUOW. Changes 28.316/28.284
added logic to print an MXGWARN when there was no input,
by creating a second dataset in an existing DATA step,
but that second dataset is NOT created when OPTIONS OBS=0
is set and the first dataset is a /VIEW, unless SAS V9.2
on Windows/Unix is used. The SAS defect was fixed only
for ASCII V9.2, but is now reopened by SAS Tech Support.
But MXG code was revised to eliminate the second dataset,
and tests now are for dataset existence rather than for
non-zero observations.
And why didn't MXG QA catch the error? Because we tailor
IMACUOW to create observations, which didn't fail.
Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA
Change 28.329 CTG records had zero observations in TY111CXI "IPIC"
VMAC111 because MXG's length test was incorrect. The Version 8
Jan 14, 2011 documentation has several new fields that are now input
Jan 19, 2011 if the record length test is satisfied.
Jan 19: The VMAC111 was NOT updated in time for MXG 28.28
because I had no test data for validation; this update is
now made, but there are still no observations in either
TY111CXI or TY111CXE datasets because there are no SMF
data with values CTGRECID=2 being created.
Thanks to Jim Poletti, Edward Jones, USA.
Change 28.328 New JCLINSTT member is the recommended z/OS install JCL
JCLINSTT with these four steps to "drop-in" the new version
INSTALL FTPMXG
Jan 13, 2011 FTP DOWNLOAD TER2828.TER FILE FROM THE MXG FTP SITE.
UNTERSE
UNTERSE THE DOWNLOADED TER2828.TER FILE.
ALOCUSID
ALLOCATE THE MXG.V2828.USERID.SOURCLIB PDS LIBRARY.
FORMATS
ALLOCATE AND CREATE MXG.V2828.MXG.FORMATS LIBRARY.
Change 28.327 -Connect Direct 'RT' record's format was changed; while
VMACNDM offsets for the PACCT and SACCT exist and are populated,
Jan 12, 2011 the ACCT fields do NOT exist, and instead a text string
Jan 13, 2011 inside double quotes ('7F'x) is at the end of the record.
This change detects the quote pair and stores that text
in new NDMRTDAT text variable. However, some 'RT' don't
have the quote pair, so a length test will skip over the
data at the end but will still output the RT record.
-And short RT records, less than the 216 bytes have been
found and are printed on the log and skipped.
-The 'AE' family of records UID and XUSER fields are now
input $EBCDIC64 as they were expanded.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Thanks to G. Bosker, Rabobank Nederland, THE NETHERLANDS.
====== Changes thru 28.326 were in Prelim MXG 28.28 dated Jan 12, 2011==
Change 28.326 Invalid DB2 Distributed Header has QWHDPRID shifted right
VMACDB2H by two bytes, causing INPUT EXCEEDED error when QWHDPRID
Jan 12, 2011 had non-null value in the last two bytes, as those bytes
were expected to contain the OFFSET to QWHDRQNM when they
are non-zero. The defective records are now detected by
'0000'X value in the first two bytes of QWHDPRID, the
header is skipped, new variable QWHDBAD is set to one,
and an error message is printed for the first three.
IBM has accepted a PMR and will have an APAR to correct.
This change protects the Invalid Header so the APAR is
NOT required for MXG.
APAR PM32425 corrected the problem.
Thanks to Joe Babcock, JPMC, USA.
Change 28.325 Since Change 22.108, DB2 SQL-text variables are only 100
VMAC102 bytes if COMPRESS=NO is specified. The normal length of
Jan 11, 2011 32000 with YES must be reduced with NO because massive
disk space could be required.
But you can change this behavior by using
//SYSIN DD *
%LET SASCHRLN=32000;
even if you have specified COMPRESS=NO.
-Two variables had default lengths of 4000 and 5000 set by
&SASC4000 and &SASC5000, but they now use &SASCHRLN to be
consistent.
-The list of variables was updated in the text of 22.108.
Thanks to Joachim Sarkoschits, DATAEV eG, GERMANY.
Change 28.324 -WEEKBLD/MONTHBLD dataset TYPE72DL NOT SORTED ERROR, if a
MONTHASC WEEKBLD/MONTHBLD member is in your "USERID.SOURCLIB".
-Inserted Jan 24, 2011, after MXG 28.28 was created:
Similar DB2STATS NOT-SORTED ERROR in Change 29.008, but
you can Circumvent/eliminate sorting as shown below.
MONTHASW The TYPE72DL wasn't reported by a user, but was found in
MONTHBL3 in QA tests when PDBs built by old and new versions were
MONTHBLD combined, because the sort order in WEEKBLD/MONTHBLD for
MONTHBLS TYPE72DL was erroneously different in VMAC7072/BUILDPDB.
MONTHDSK The only prevention, if WEEKBLD/MONTHBLD exists in your
MONTHWEK USERID.SOURCLIB, is to change the _BYLIST, before you run
WEEKBL3 WEEKBLD or MONTHBLD with MXG 28.28, to this order
WEEKBL3D MACRO _DSET TYPE72DL %
WEEKBL3T MACRO _BYLIST SYSPLEX SYSTEM SYSNAME STARTIME %
WEEKBLD which is the new default in MXG's WEEKBLD/MONTHBLDs.
WEEKBLDD -Alternatively, you can disable sort order and tests in
WEEKBLDT WEEKBLD/MONTHBLD using this example (from comments):
Jan 10, 2011 //SYSIN DD *
Jan 15, 2011 %LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;
Jan 16, 2011 %INCLUDE SOURCLIB(WEEKBLD);
-With BLDSMPDB, add SORTEDBY=NO, to bypass sort test.
-MONTHWEK was updated Jan 15 with a RUN; added.
Change 28.323 -New SX record support caused DIVISION BY ZERO because of
VMACTMVT a typo that caused SXHRTA to be a missing value.
Jan 10, 2011 -SXBV1/BV2/BV3/BV4/HRTD/NRTTD/HRT/SXNRTT variable were
incorrectly input as PIB4 vs PIB4.6 and were incorrectly
converted (i.e., the 1024 multiplier to convert those
durations into seconds/fractions was nonexistent for SX,
but was in place for the existing SI variables.)
Thanks to Paul Volpi, UHC, USA.
Change 28.322 z/TPF records SB, DB, and DE had incorrect length for
VMACZTPF reserved fields that are now corrected and validated
Jan 10, 2011 with data records.
Thanks to Bob Wilcox, HP, USA.
Change 28.321 Harmless DIVIDE BY ZERO in a 7-second-long RMF interval
VMAC7072 when there was a WLM Policy switch that causes SMF70DSA
Jan 9, 2011 sample count to be zero; all divides are now protected.
Harmless because the created variable was not used in a
subsequent calculation, and is missing either way.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 28.320 -LPARBUSY calculation in PDB.ASUM113 was wrong if the CPs
ASUM113 are slower than your zAAPs/zIIPs, because the SM1132CP
Jan 7, 2011 (speed) of the last engine (the zIIP or zAAP) was used.
And with multiple engine types, even at same speed, it
makes more sense to create separate observations for
each SMF70CIN/SM113CPT engine type for each interval.
But SM113CPT is only populated in 113s from z196, and
SMF70CIN is only populated if there's PDB.TYPE70PR data,
so the actual separation is by SM113CPT and SM1132SP to
ensure the correct speed is used to calculate LPARBUSY.
-For z10, SMF70CIN in PDB.ASUM113 is populated from the
TYPE70PR data, but the logic was not always correct. Now
SYSTEM=SMF70STN is used to select the correct LCPUADDR,
the sort order was changed to match correctly, and then
the SMF70CIN value is used to populate SM113CPT for the
z10 processors. (For z196 SM113CPT is already there.)
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 28.319 Support for IODQDS segment in Velocity Software XAM data
EXXAMQDS creates new XMIODQDS dataset.
IMACXAM
VMACXAM
VMXGINIT
Jan 6, 2011
Thanks to Francois VanCoppenolle, PVGROUP, BELGIUM
Change 28.318 MXGs test for EXCLUDEd fields in CICS/TS 4.1 tested for
VMAC110 LT 330 fields OR LT 2640 bytes, but since the default
Jan 5, 2011 record has 337 fields and 2668 bytes, a false detection
of EXCLUDED fields was not possible. Additionally, the
primary flag of EXCLUDEd fields is an invalid TASKNR, as
it is a packed decimal field whose shift is detectable.
But, the MXG test and comments were corrected.
Thanks to Patricia Hansen, ADP, USA.
Change 28.317 In analysis of the impact of possible capping values, if
ANALCAPD the desired CAP was exceeded, those excess MSU had to go
Jan 5, 2011 somewhere: this modification keeps track of the excess
MSU and spreads them out across the following intervals
up to the level of the desired CAP until they are all
used up.
Thanks to Dick Arnold, Commerce Bank of Kansas, USA.
Change 28.316 If you fail to reset the _NOOBS and _YESOBS tokens before
VMXGUOW you run ASUMUOW, no observations were processed, but with
Jan 5, 2011 no explanation. Now, when zero observations are detected
an MXGWARN message is printed to explain why there was no
output observations created in ASUMUOW.
Change 28.315 -The "CPU ADDRESS" PFXCPUAD in dataset VXSYTCUM is not the
VMACVMXA "VM" CP address of 00-0Fx, but is the LCPUADDR in the CEC
Jan 5, 2011 causing VXSUMCPU to contain many spurious observations.
This correction for the unexpected PFXCPUAD values is to
deaccumulate by PFXCPUAD, but then sum by ENDTIME for the
merge to create VMXAINTV. Fortunately, the only variable
in VXSYTCUM is the LPAR Management Time LCUMGTM, and in
spite of the spurious observations, the value in VMXAINTV
was correct before and after this change; the increase in
observations during summarization just looked wrong!
-Division by zero in creating VXAPLTCB was because the BY
list did not include SUBTASKN.
Thanks to Frank Bright, MEDCO, USA.
Thanks to Nick Said, MEDCO, USA.
Change 28.314 -%UTILBLDP(SUPPRESS= 6 26 30 110 DB2,BUILDPDB=YES) caused
UTILBLDP ERROR: FILE WORK.TYPE30MR DOES NOT EXIST. TYPE30MR is
Jan 4, 2011 now protected when SUPPRESS 30 is requested.
-If SMF 6 26J2/26J3 AND 30 are suppressed, BUILD005 is not
executed.
-If 26 (instead of 26J2/26J3) is specified, 26J2 is used,
with a note.
-A new QA report now compares the suppressed records list
of dddddd tokens with the list of datasets created by the
SMF record to ensure UTILBLDP is updated when needed.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 28.313 -Variable CVTTZ in TYPE0 could be one second wrong, for
TYPE0 some time zones, because the CEIL/FLOOR functions that
TYPE28 are needed in MXG to create integer Time Zone deltas were
TYPEEPIL omitted when CVTTZ was added to the record. The CVTTZ
TYPEHPDM field is documented in the CVT as if it is the actual GMT
TYPEMVCI offset, but its value of 1.048576 seconds per binary bit
TYPENTCP is not an integer value; IBM actually uses the 8-bytes in
TYPEOMCI CVTLDTO with 1 microsecond resolution for the GMT offset.
TYPETIMS -The CVTTZ field is the first 4 bytes of CVTLDTO, so those
TYPETMDB CEIL/FLOOR functions are used to create exact GMT Offset;
TYPETPX their absence in TYPE0 caused a search for all MXG code
Jan 3, 2011 with CVTTZ-based GMT offset, which found some members
needed corrections. Luckily, some of the vendor records
store an integer value, so MXG's use of CEIL/FLOOR is not
always required, but MXG now uses them consistently.
Fortunately, in most cases below, the GMT Offset was not
used to convert (when all timestamps are already LOCAL),
so only the GMT Offset variable might have been wrong.
And by only one second:
-VMAC0: CVTTZ had no CEIL/FLOOR.
-VMAC28: NPMGMTTZ had only (wrong) PIB.4., no floor.
-VMACEPIL OMGMTOFF CEIL/FLOOR functions reversed.
-VMACHPDM SOVHTZOS no 1.048576 multiply, no CEIL/FLOOR
-VMACMVCI T6ECVTTZ CEIL/FLOOR functions reversed.
-VMACNTCP MONCVTTZ only PIB.4, no multiply, no CEIL.
-VMACOMCI SMCVTTZ CEIL/FLOOR functions reversed.
-VMACTIMS CHGMTA no CEIL/FLOOR
-VMACTMDB GMTOFFTM no CEIL/FLOOR
-VMACTPS TPXCVTTZ CEIL/FLOOR functions reversed.
Note: CVTLDTO is not externalized; APAR OA23267 listed a
value of FFFE6053 1927B4DE for a 31 hour offset, but that
value is 30.99500413 hours, .005 hours or 0.35 seconds
instead of the one microsecond resolution expected. But,
the error in that APAR apparently impacted both the hour
and the seconds; examination of current CVTLDTO values
FFFFAF88 -6 hours FFFFAF88 A2800000 -21600.000000
FFFFBCF1 -5 hours FFFFBCF1 DCC00000 -18000.000000
FFFFCA5B -4 hours
show full microsecond resolution produces exact integers.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 28.312 The default "SMFSMALL" file for testing SMF processing
UTILGETM created by UTILGETM writes only 10 records for each SMF
Dec 31, 2010 ID and SUBYTPE, so the TYPE72GO dataset had only the
first 10 service classes and NO reporting classes. The
default NRECORD=50 is now set so there should be at least
some Reporting Class observations in SMFSMALL (which was
increased from 4 to only 19 cyl, so it's still SMALL).
Thanks to Ken Jones, Xwave, CANADA.
Change 28.311 Support for IMS/DBCTL transactions made in Change 28.310
TYPEIMSA are implemented in the JCLIMSL6/ASMIMSL6 IMS processing.
TYPEIMSB -TYPEIMSA was revised to split and separately process the
VMACIMSA IMS/TM from the IMS/DBCTL transactions.
Dec 31, 2010 -TYPEIMSB was corrected to correctly work on ASCII SAS,
and ancient code blocks were removed for IMS Version 5!
-VMACIMSA revised to create IMS07D/IMS08D for DBCTL.
-Some code blocks for _IMSVERS LE 6.1 were removed.
Thanks to Ojnan Lindholm, Volvo, SWEDEN.
Change 28.310 Support for IMS/DBCTL transactions created by TYPEIMS7 in
EXIMS07D IMSTRAN.IMS0708 is revised. While IMS/DBCTL transactions
EXIMS08D were correct, identifiable by PROGTYPE='D', DBCTL records
FORMATS also created thousands of spurious observations that had
TYPEIMS7 PROGTYPE=' ', but, fortunately, had no resources, so they
TYPEIMSD only wasted disk space! Now, VMACIMS splits the 07/08
VMACIMS records (DLRUSSN GT 0 for DBCTL) to create separate pairs
VMXGINIT in IMS07/IMS08 and IMS07D/IMS08D datasets that are then
Dec 31, 2010 separately sorted and combined by different algorithms to
eliminate the spurious observations. TYPEIMS7 can create
datasets for all IMS log records, or you can select which
records are read to populate only desired IMS datasets.
These tailoring macros allow you to define the LIBNAMEs
that will be used; all default to WORK. See examples in
the comments in TYPEIMS7 member.
DDNAME DDNAME.DATASET DATASET DESCRIPTION
TOKEN
&WIMS78 IMS0708.IMS0708 IMS/TM,IMS/DBCTL TRANS
&WIMSBMP IMSBMPS.IMSBMPS BMP EXECUTIONS
&WIMSA78 IMS0A78.IMS0A78 IMS/TM CPIC TRANSACTIONS
&WIMSOTH IMSOTHER.IMSOTHER ALL OTHER IMS LOG RECORD
-VMACIMS creates the new IMS07D and IMS08D datasets from
which the IMSDBCTL dataset is created by TYPEIMSD.
-FORMAT $MGIMFPT adds ' '='BLANK:UNMATCHED', because the
mismatched 08/07s can exist and now will be output and
can be seen with that value if you print PROGTYPE.
However, if you want to tabulate PROGTYPE, because it
is a character variable, you must add the /MISSING
option to see the formatted value tabulated:
PROC FREQ DATA=IMSTRAN.IMS0708;TABLES PROGTYPE/MISSING;
-Some code blocks for _IMSVERS LE 6.1 were removed.
-Member TYPEIMSD is replaced by TYPEIMS7 and contains only
comments. The original TYPEIMSD had the IMS/DBCTL logic
for the 07/08, but it did not handle IMS/TM transactions.
Thanks to Ojnan Lindholm, Volvo, SWEDEN.
Change 28.309 The Raid Rank ID variables R745RRID and R748RRID are now
VMAC74 formatted with HEX4. as both RMF and HDS internals show
Dec 27, 2010 the hex value in printed reports.
Thanks to Ron Hawkins, HDS, USA.
Change 28.308 Removal of duplicate SMF records (now, ANY non-VSAM z/OS
ANALDUPE data file). See MXG Newsletter FIFTY-SEVEN, MXG TECH NOTE
UNDUPSMF TWO for benchmarks of the four alternatives, and read the
Dec 23, 2010 ANALDUPE discussion of why MP's discovery that the SAS
MD5 Hash Function is an elegant and efficient solution to
remove duplicates from ANY z/OS file, not just SMF data.
For comparison, see the timings in UNDUPSMF, the original
de-dupe program.
Thanks to MP Welch, Aprize, Inc, USA.
Change 28.307 A short LINUXKRNL'02'x20101 MONWRITE segment caused error
VMACVMXA messages on the log of broken data, but MXG recovery was
Dec 23, 2010 successful. The invalid segment had MRHDRLEN=140 with
NRCPUS=2, so it had only 44 bytes for the two sets of 9
4-byte per-CPU counters. The short record is detected and
the second CPU observation is not output, but there are
no MXG messages on the log; if/when a user notices the
same problem we'll then pursue a problem report with IBM.
Thanks to MP Welch, Aprize, Inc, USA.
Change 28.306 Change 28.277 corrected NETSNAME from QWHCTOKN when there
VMAC116 was no period in QWHCTOKN; that same correction is now
Dec 21, 2010 made in SMF 116 when there is no period in QWHCNID.
Thanks to Nick Varvarigos, IBM Global Services, CANADA.
Change 28.305 -PDB.NJEPURGE did not contain all NJE-related SMF 26 Purge
BUILD005 records; MXG only output INREASON=JR or JT records into
VMAC26J2 that dataset, so INREASON=SR records were not output.
Dec 21, 2010 Now, all TYPE26J2 with SYSEXEC blank and any JES2 Offload
Jan 3, 2010 Purge Records are output in PDB.NJEPURGE.
-All TYPE26J2 variables are now kept in PDB.NJEPURGE.
-Variable INREASON='RD' is now set for purge records that
have INDEVICE of INTRDR, STCIRDR and TSOINRDR; previously
INREASON was blank.
-Blank INREASON will now print the first three instances.
-Jan 3: BUILD005 revised; it had added all of the _NJE26
variables to the PDB.JOBS dataset, wasting space, and the
dataset SPIN26 had also kept RDRTM SUBSYS.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.304 SMF 89 subtype 1 with no usage segment had INPUT EXCEEDED
VMAC89 RECORD LENGTH error, because Change 28.282 added test for
Dec 20, 2010 new data in line 390, but the test was GE 195 but should
have been GE 205. Only one record with no usage occurred
in 160,000+ records, but MXG now detects and output these
records in TYPE89. They can be identified because both
PRODTCB and PRODSRB are missing values. If a problem is
opened with IBM and a response is received, this note
will be updated.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 28.303 Printed output location was shifted to accommodate longer
ANAL119 host names and URLs, and to avoid print overlay of the
Dec 17, 2010 remote IP address on detail reports when reading IPHOSTS.
Thanks to Dave Ireland, USDA National IT Center, USA.
Change 28.302 The BY list for dataset TYPE30MU was insufficient and it
VMAC30 removed some non-duplicated observations. Adding vars
Dec 17, 2010 STEPNR STEPNAME PRODTCB PRODSRB SMFRECNR MULCEGNR to the
BY list eliminates the false duplicate removal, and by
adding after SMFTIME, they won't cause NOTSORTED errors.
However, there ARE duplicate TYPE30MU segments from the
same SMF record that are now kept only because MULCEGNR,
(segment position in each record) are different. You can
examine these duplicated segments with this example:
%INCLUDE SOURCLIB(TYPE30);
PROC SORT DATA=TYPE30MU OUT=SORT30MU;
BY READTIME JOB JESNR INITTIME SUBTYPE
PRODOWNR PRODNAME PRODQUAL PRODID
SMFTIME STEPNR STEPNAME PRODTCB PRODSRB;
DATA DUPES;
SET SORT30MU;
BY READTIME JOB JESNR INITTIME SUBTYPE
PRODOWNR PRODNAME PRODQUAL PRODID
SMFTIME STEPNR STEPNAME PRODTCB PRODSRB;
IF FIRST.PRODSRB AND LAST.PRODSRB THEN DELETE;
PROC PRINT;
TITLE DUPLICATE SEGMENTS IN TYPE30MU;
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.301 WPS does not provide the %DATATYP %macro, added in 28.06
VMXGGETM to detect non-numeric typed values for NRECORD argument
Dec 20, 2010 in %VMXGGETM call. VMXGGETM is used only to create the
SMFSMALL file or to count records/bytes in an SMF file.
That change was only to replace an obscure failure with
a successful run by forcing NRECORD to the OBS value.
That enhancement is now bypassed when executed under WPS.
Thanks to Matt Henson, McMaster-Carr Supply Co., USA.
Change 28.300 TYPETCP (SMF 118) Port Numbers (IN DECIMAL) were wrong if
VMACTCP MXG was executed on ASCII because the input was PIB2. but
Dec 14, 2010 must be the &PIB.2. macro variable to resolve correctly.
Having found this one exposure precipitated a search of
all MXG members and these members also had to be fixed;
fortunately, almost all of these members are ancient and
no longer used so there was no impact except consistency:
TTXPDS XIBMFDP XGTFANAL TYPSIMS1 TYPEIMS1 VMACZTPF
VMACTPF VMACTMVS VMACSMSX TYPESRLI PRODTESW PRODTEST
IDMSLOG IDMSLO57 IDMSJRLN ANALCM29 ANALCM27
Thanks to Cristian Molero, MConsulting Bvba, BELGIUM
Change 28.299 Wrong values (neg PCTCPUBY +) in PDB.TYPE70EN for CPUID=0
VMAC7072 if SMF70PAT was non-zero in any engine, because SMF70PAT
Dec 14, 2010 was kept in both TYPE70EC and TYPE70EL, which are MERGEd
to create PDB.TYPE70EL, but it only should have been kept
in TYPE70EC. Having the same named variables in datasets
that are merged can have unintended consequences if they
are not in the BY list for the merge.
Fortunately, the PDB.TYPE70EN (one obs per engine) is not
(yet) used to create the per-engine values in PDB.TYPE70.
And, only software developers like Don are even likely to
ever need the level of detail from RMF 70s in TYPE70EN.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.298 -EXITCICS decompresses SMF 100,101,102,110 & 112 records,
EXITCICS The previously reported errors with SMF 112s and EXIT112
EXIT112 were not in the CICSIFUE exit code, but in VMAC112 due to
VMAC112 IBM's change of FOCVER='V560' backwards to FOCVER='V420'
Dec 18, 2010 (with NO change in the record itself), which caused MXG's
tests for GE 'V560' to fail and misalign the decompressed
record. With the exit, the ABEND was incorrectly blamed
on the Exit, or, processing uncompressed records caused
zero observations in the T112xxxx datasets.
Member EXITCICS invokes the CSRCESRV function; this note
here so a search for it will find this change text.
-VMAC112 was revised for FOCVER='V420'.
-The EXIT112 member is now only comments to use EXITCICS.
-EXITCICS added DB2 100,101,102s support in MXG 28.06.
Thanks to Dick Arnold, Commerce Bank of Kansas City, USA
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA
====== Changes thru 28.297 were in MXG 28.08 dated Dec 13, 2010=========
Change 28.297 WANTONLY=DB2ACCT, now works; it worked fine if there was
READDB2 a blank before the comma. Now in QA TESTREAL. Found this
TESTREAL when I tried to use it in ANALDBUT, so Tom gets 2nd cite!
Dec 12, 2010
Thanks to Tom Glaser, MasterCard, USA.
Change 28.296 Analysis of DB2 DSNUTIL executions, by combining DB2ACCT
ANALDBUT observations with QWHSPLAN='DSNUTIL' with DB2 Trace data
Dec 12, 2010 IFCIDs 23,24,25 to add UTILNAME, UTILPHAS, and UTILID
variables to the DB2ACCT observation for each DSNUTIL
execution. The output WORK.DSNUTIL dataset is created.
Thanks to Tom Glaser, MasterCard, USA.
Change 28.295 Analysis of WHO deleted your DB2 data, combining TYPE6156
ANALWHO and DB2ACCT. If you have the DDL Audit Trace its easy:
Dec 10, 2010 %ANALDB2R(PMACC01=NO,PMACC02=NO,
PMSTA02=NO,PMAUD02=YES,AUDIT=DDL);
and this program would not be needed.
However, ANALWHO selects the z/OS Dataset name from
the TYPE6156 datasets, from which you can find the time
when the z/OS dataset was deleted, but those records will
have only the job name of the DB2 DBM1 address space.
By adding DB2ACCT you can narrow in on who did it to the
DB2 table in that time period, with QXDRPDB or QXDRPTA or
QXDRPIC GT 0.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.294 Variables CPUZIETM and CPUIFETM added to summarization
ASUMSMFI of PDB.SMFINTRV to create PDB.ASUMSMFI.
Dec 10, 2010
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.293 -Support for OPENSSH SMF 119 subtypes 96-98 creates new
VMAC119 dataset ddddd description
VMACSMF TYP11996 T11996 OpenSSH Server Transfer Complete
Dec 9, 2010 TYP11997 T11997 OpenSSH Client Transfer Complete
TYP11998 T11998 OpenSSH Login Failure
-Technically, these new subtypes are INVALID SMF records
because BIT 1 in SMFxFLG, which is the IBM indicator that
the record contains subtypes, is not ON, causing VMACSMF
to see these as SUBTYPE=0. Now, VMACSMF forces the input
of SUBTYPE for ALL SMF ID=119 records.
Thanks to John McKown, Health Markets, USA.
Change 28.292 New MODATE option PROC PRINTs the found datasets in order
VMXGSRCH of the Modify date, so the search results are printed in
Dec 8, 2010 the same order they appear on the SAS log. The MODATE=NO
default prints the datasets alphabetically, as before.
MODATE=YES was used to debug the multi-step TYPETMS5 code
by selecting a VOLSER to follow, especially since the
variable name that contains "volser" is different in
different temporary WORK datasets.
Additional parameters were also added to allow you to
limit which datasets and which variables to be searched
and printed, if you don't want to see all of them.
New parameters:
MODATE=NO Change to YES to sort on modify datetime
DATASET= A list of full or partial datasets to be
searched for the string
VARS= A list of full or partial variable names
to be searched/printed
Change 28.291 -Cosmetic. SUBTYPE for DB2 ID=102 can be greater than 255,
VMACSMF but previously they were set to missing value so UTILGETM
Dec 8, 2010 did not report them. For actual ID=102 processing, MXG
uses the IFCID value so this had no real impact.
-Cosmetic. Back-to-back ID=2 did not print the LAST RECORD
IN GROUP message. SMFHDRCN now keeps track.
-Reminder for reading only part of an SMF file:
While using OPTIONS FIRSTOBS=100 OBS=500; can sometimes
used, to read only those input records, if there is any
post-processing (deaccumulate, sort, etc.) it won't work!
Instead, use %LET SMFEXIT= FIRSTOBS=100 OBS=500; which
will used those on the INFILE and thus only impact which
records are read, not touching the global options.
Change 28.290 New DB2 analysis adds JESNR and READTIME to DB2ACCT by
ANALDBJS reading PDB.JOBS and PDB.JESNR and sequencing DB2ACCT
Dec 8, 2010 by JOB and SMFTIME to propagate those variables.
Thanks to Jane Stock, USPS, USA.
Change 28.289 Variables GATLIMIT and GATCNT are now KEPT in TYPE6156 so
VMAC6156 that changes in GDG limits can be observed.
Dec 8, 2010
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 28.288 Cosmetic. If no observations are found with the searched
VMXGSRCH values, now, a note that no observations were found is
Dec 7, 2010 printed on the log.
Change 28.287 Support for ASG-TMON for VTAM subtype 'SX' creates new
ANALTMVT TMVTSX dataset with the "Session Extended Information".
EXTMVTSX New member ANALTMVT replicates for ASG-TMON VTAM reports.
IMACTMVT
VMACTMVT
VMXGINIT
Dec 6, 2010
Change 28.286 Variables QAINTS and QAINTE, interval start/end datetimes
VMACTMMQ should have been kept in TMMQQAA dataset, and now are.
Dec 6, 2010
Thanks to Homayoun Riazi, United Health Group, USA.
Change 28.285 CICS STID=143 sub-subtype printed message that six bytes
VMAC110 of new data was skipped, but there was no new data; MXG
Dec 3, 2010 incorrectly input ECCEVCAP as only 4 bytes, when it is 8,
so ECCEVCAP/ECCCAPFA/ECCEMIFA in CICECC Statistics Data
set were wrong, and the subtract of 146 is now 152 after
that correction.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.284 -VMXGUOW was enhanced to detect that all input tokens
ASUMUOWT (_LCICTRN _LMONTSK _LDB2ACC) do not exist, or it will
VMXGUOW construct the macros based on the presence or absence
VGETENG of the corresponding &P****** macro. If for example
Dec 3, 2010 &PCICTRN is empty or the DDNAME is not found, the
_LCICTRN macro is set to CICSTRAN. If it is found,
the macro is set to &PCICTRN..CICSTRAN. If neither
CICSTRAN nor MONITASK exist, a warning is printed,
but the output ASUMUOW dataset is created with OBS=0.
-ASUMUOWT (for TMON instead of CICSTRAN input) will now
call VMXGUOW, so there is only one macro to maintain;
this obsoletes VMXGUOWT as no longer required.
-VGETENG NOEXIMSG=YES added as a default. NOEXIMSG=NO
suppresses the MXGNOTE on the log as it does in the
other %VGET macros.
Thanks to Ken Goodis, Emblem Health, USA.
Change 28.283 Many RACF segments have a variable containing CLASS*NAME
VMAC80A for that specific RACFTYPE/SMF80DTP, but some had only
Dec 2, 2010 "CLASS*NAME" for their label value. Now, the RACFTYPE
value is included to make the LABEL value unique.
Thanks to John Matson, EPSON, USA.
Change 28.282 -Support for APAR OA31615 which adds zIIP & zAAP CPU TIME
EXTY89I to dataset TYPE89, and which adds new Intersect Data that
IMAC89 creates new TYPE89I dataset for Measured Usage reporting.
VMAC89 -Variable SMF89SYN is added to each of the BY lists as the
VMXGINIT last variable; if you have duplicate SYSTEM names in your
Dec 2, 2010 SYSPLEX, then SMF89SYN will be different than SYSTEM.
Change 28.281 PDB.ASUMCICR dataset contains the count/average response
ASUMCICR time by DATE for each REGION/APPLID, and can be created
Dec 1, 2010 from transaction detail MONITASK or CICSTRAN or ASUMUOW
datasets, or the summary PDB.CICS dataset (built by
ASUMCICS/ASUMCICX), or, if the input is WEEK.ASUMCICR or
if INDATA= MON.ASUMCICR ... SUN.ASUMCICR, the prior sums
will be re-summed to include partial days for each DATE.
And, if NODATE=YES, is specified, whatever input is in
the INDATA= argument will be summarized only by APPLID,
(in case your manager thinks a weekly average of all of
the week's transactions in a region is a useful metric!).
The PDB.ASUMCICR dataset also summarizes TASCPUTM.
Note: These values may be of little use, if your site
uses Multi-Region-Option MRO and you read transaction
detail datasets (MONITASK/CICSTRAN), where the counts
will be inflated and false, since each one of the
multiple observations of an MRO transaction (one TOR,
one-to-many AOR, one-to-many DOR/FOR obs) will each be
counted as a separate "transaction", which they aren't!
On the other hand, if there are very few MRO trans, and
your APPLIDs are stable, these counts/averages might be
useful for tracking quantity and response.
Thanks to Ken Goodis, Emblem Health, USA.
Change 28.280 The XCF Path report added the TRANSFER TIME column, and
ANALRMFR some BY lists with repeats of SYSNAME were corrected.
Nov 30, 2010
Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.
Change 28.279 ASUM113 used SMFTIME to define each interval, but SMFTIME
VMAC113 can have multiple values in the records for an interval;
Nov 29, 2010 it can take a second to write all of the records for one
interval. If SMFTIME had different .01 second values,
ASUM113 incorrectly created "near duplicate" observations
with wrong values. As no "start of interval" flag exists
in SMF 113 records, this revision uses the time value in
the SM113CPU=0 and SM113CST=1 and SM113CPT=0 observation
to populate SM113STM, the Interval Start Time, for each
interval. An additional error when the GMT OFFSET was
was positive that could cause a one-second error in the
converted timestamps was corrected.
Thanks to Adnan Can, Garanti Teknoloji, TURKEY.
Change 28.278 Cosmetic. Variable CPGRPJOI is FORMATed DATETIME21.2.
VMACRMFV
Nov 28, 2010
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 28.277 Variables NETSNAME and UOWTIME are created in DB2ACCT so
VMACDB2H that DB2 observations with QWHCATYP=4, i.e., CICS, can be
Nov 25, 2010 merged with CICSTRAN to create PDB.ASUMUOW. Those vars
Nov 29, 2010 are now populated ONLY for DB2ACCT observations from CICS
(i.e. QWHCATYP=4). Changes to NETSNAME creation in DB2
in MXG 28.05 caused non-CICS DB2ACCT obs to have changed
values in last 4 characters that caused no harm except
to show up as differences in PROC COMPARE, but as there
is no value in creating NETSNAME for these observations,
to avoid confusion, they are no longer populated.
-However, some values of NETSNAME were not correctly
created, if the last four characters happened to contain
a period in those hex values. The logic was revised to
only scan the first 16 bytes of QWHCTOKN for the period.
-Also, if there WAS a period in the first 16 bytes, then
the resultant NETSNAME value was non-blank in the last
four bytes; now it is populated with only the first 16
bytes of QWHCTOKN in that instance.
-These MXG errors could cause PDB.ASUMUOW to have fewer
observations than it should.
Thanks to Paul Volpi, UHC, USA.
Thanks to Matthew Chappell, Queensland Dept of Transport, AUSTRALIA.
Change 28.276 ASUMHSM enhanced with optional macro to select HSM data
ANALHSM to be summarized, and ANALHSM also enhanced to support
ASUMHSM selection with BEGTIME/ENDTIME.
Nov 18, 2010
Dec 11, 2010
Thanks to Doug Medland, IBM Global Services, USA.
Change 28.275 -Support for NMON FCREAD/FCWRITE/XFERIN/XFEROUT records
EXNMONFC creates new dataset PDB.NMONFC for the Fibre Channel data
VMACNMON for AIX and Linux.
VMXGINIT -Support for NMON DISKXRFER (disk transfer reads per sec)
Nov 17, 2010 creates new variable DISKXRFR in PDB.NMONDISK.
Dec 2, 2010 -Support for DISKBUSY/READ/WRITE/XFER/BSIZE/SERV/WAIT with
Dec 9, 2010 suffixes thru 21.
-Invalid UARG record with only four fields and the fourth
containing text of PPID COMMAND THCNT USER GROUP COMMAND
is detected and printed on the log and deleted.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.274 NMON variables COMMMAND and FULLCOMD lengths increased to
VMACNMON 512 bytes to capture the full text of commands, and the
Nov 17, 2010 elements of the WORDS array are also increased to $512.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.273 MXG support for CA NSM/TNG only output 4-digit values in
VMACTNG the generated %LET statements with number of Instances,
Nov 13, 2010 creating %LET xxxxxx=12E3; which is not valid syntax for
the macro language. The %LET counters now put 6 digits.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.272 SMF fields SMF70HOF/SMF89HOF/SMF89DTO for SCRT are NOT
VMAC7072 documented that the last 3 nybbles of those 8-byte TOD
VMAC89 Clock fields can be non-zero but are NOT used by SCRT.
Nov 13, 2010 MXG input those fields, which caused fractional seconds
that did not exactly match SCRT reports. Now knowing the
idiosyncrasy of these fields, MXG now zeros those last
three nybbles prior to their input to match SCRT.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Charles E. Hackett, SCRT-IBM, USA.
Change 28.271 Site tailoring created temporary variable named COUNTER
VMAC113 in CICS exit years ago, but when they added SMF 113 to
Nov 11, 2010 their daily BUILDPDB, it died because that name was used
as an ARRAY name in VMAC113, an unacceptable use.
While the site easily renamed their temporary variable to
avoid the conflict, I changed COUNTER to CNTR113.
Change 28.270 Documentation. The successful JCLTEST9 execution prints
JCLTEST9 UNINITIALIZED variable messages in two places. There are
Nov 11, 2010 335, mostly with variable names AD0nnxxx immediately
prior to NOTE: Dataset WORK.SV01EV01 has 0 observations.
There are 120 more with various names before the
NOTE: Dataset WORK.AIXPTXIN has 0 observations.
Thanks to Andrew Woods, Interactive Data, ENGLAND.
Change 28.269 TYPE72DL NOT SORTED error after setting the Clock Back
WEEKBL3 for DST, combining daily PDBs all created by the same MXG
WEEKBL3D Version! Discovered GMTOFF72 was in BY list in VMAC7072
WEEKBLDD for TYPE72DL/TYPE72GO/TYPE72MN/TYPE72SC datasets, but not
WEEKBLDT in the WEEKBLDs. Have now added GMTOFF72 after STARTIME
WEEKBLD in all WEEKBLDs.
Nov 8, 2010 Jan 16,2011: Now, see Change 28.324.
Change 28.268 Utility program identifies all non-printable characters
UTILNPRT in the formatted value of all character variables in all
Nov 8, 2010 SAS datasets in a SAS data library. SAS Enterprise Guide
before 4.22 failed on non-printable DB2 data, so this was
written to examine what variables could cause problems.
Most variables that contain hex data in characters
are formatted with $HEX precisely to eliminate the
non-printables, or $EBCDIC field's '00'x are changed
by MXG to blanks. But some variables have mixtures of
EBCDIC and HEX; while these could be formatted $HEX,
sometimes that EBCDIC text is useful in PROC PRINTs,
and it would be lost in hex characters with $HEX, so
I leave the variable unformatted, leading to this kind
of exposure, hence the utility.
If you have a problem, just add a FORMAT vvvvvvvv $HEXnn.
statement in the EXdddddd exit for the dataset, where nn
is twice the length of the character variable.
Thanks to Stephen Hughes, Excellus, USA.
Change 28.267 Optional argument NOEXIMSG=YES added so that messages
VGETENG could be suppressed when not wanted, used internally by
Nov 5, 2010 other MXG programs that use VGETENG.
Change 28.266 MXG's IEBUPDTE-for-ASCII SAS program to create a source
IEBUPDTE directory of files from an IEBUPDTE-format input file now
Nov 4, 2010 looks for either './ ' or '.XY' in columns 1-3 to flag a
new "member", so the PRODTEST member can be read directly
without EDITing those '.XY' into the './ ' that is needed
by the z/OS PGM=IEBUPDTE.
The MXG source library has to have '.XY' inside these
members that contain a PDS in IEBUPDTE-format, because
there might still be someone actually using
PGM=IEBUPDTE on z/OS to create their MXG.SOURCLIB PDS,
if they chose to download the (ARCHAIC) ebcvvnn.ebc
EBCDIC MXG install file to z/OS, as those './ ' would
create unwanted new PDS members on z/OS.
On z/OS the tervvnn.ter tersed-PDS MXG Install File
should be downloaded instead.
-The SHAREBUFFERS options caused no harm but no value as
it's for performance when writing in-place, so it was
removed.
-The INFILE option TERMSTR=CRLF is now in comments, as it
doesn't exist in SAS V9.1.3 nor WPS, and it is only
needed if this IEBUPDTE program is executed on unix to
read a windows-created CRLF-terminated text file.
On unix, TERMSTR=LF is the default text line terminator.
Thanks to MP Welch, Aprize, Inc, USA.
====== Changes thru 28.265 were in MXG 28.07 dated Nov 5, 2010=========
Change 28.265 ASUMCACH failed INVALID ARGUMENT TO FUNCTION INPUT with
ASUMCACH DEVMODEL='3380K' (i.e., with alpha character) when the
Nov 4, 2010 new statement MODEL=INPUT(DEVMODEL,HEX8.) was executed.
Now, that statement is protected if DEVMODEL is not a hex
value (e.g., MODEL=3380x for DEVMODEL='3380K'.
Thanks to Tom Heller, CINCOM, USA.
Change 28.264 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE:
EXDB2ACR MXG 28.06 was required to process the V10 data, but now,
EXDB2ACW MXG 28.07 has full support plus the below documentation.
FORMATS
IMACDB2 -DB2 V10 Records can be compressed. Member EXITCICS is
VMACDB2 updated to decompress SMF 110-1 and SMF 100,101,102s.
VMACDB2H
VMACSMF -INVALID DATA FOR QWHSRELN is proof you have DB2 V10 SMF;
VMXGINIT QWHSRELN is not a valid "PK" value; it now has 'A1'x, so
VMXGWORL VMACDB2H was revised. The value is 10.1, not 10.0.
Jun 16, 2010 -And INPUT STATEMENT EXCEEDS RECORD error ABENDs may occur
Jun 19, 2010 because fields were inserted rather than added at the end
Jun 21, 2010 where MXG would have automatically skipped them.
Nov 4, 2010
-Subtype in SMF Header INCOMPATIBLY increased from one to
two bytes (because that's what it should have been all
along. However, only SMF 100 and 101 records populate
the subtype in the SMF Header. VMACSMF was updated to get
the DB2 version and then input the subtype correctly.
(MXG has always stored the IFCID value in SUBTYPE for the
DB2 102 trace records, since they don't have a subtype.)
-New DB2ACCGW dataset is created for each QWAR segment,
which can be used to correlate rollup records.
-Multiple SMF 100 Subtype 1 (DB2STAT1) IFCID=2 records are
now supported. These records contain only QBST or QBGL
segments and are written when more than 25 buffer pools
are used in an interval.
-Macro _SDB2STS was redesigned to correct DUPLICATE MERGE
VALUES errors that occurred only if DB2 was restarted, by
removing QWHSACE QWHSMTN from the _BDB2STS "BY list", by
interleaving the four input datasets to create STATSGROUP
to use as merge variable (QWHSSTCK cannot be used as it
not exact in all four records for each interval), and by
conditionally merging T102S225 (DB2 V8) if it exists.
The _SDB2STY macro is now a null macro and no longer
used. The new sort order for the PDB.DB2STATS dataset is
now SYSTEM QWHSSSID QWHSSTCK. A cosmetic enhancement to
VMXGWORL, NOWARN=YES, is used to suppress the MXGNOTEs
when a tested dataset is known to not always exist (used
for T102S225 in this change).
-Many new variables added to DB2ACCTx/DB2STATx by V10:
DB2ACCT:
QLACRLNU QWACPCTT
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPQRY QWACAWLH QWACARLH
DB2ACCTB:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTG:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2STAT0:
Q9STCDMD QDSTNQWC QDSTNARD QDSTMARD
D64POST A64POST A64WAIT M64DISNU M64DISPG SGETR64
SGETEXT6 SGETDEXT SFREER64 SFREEDEX DISCARDM
QWS1MCPU QWS2MCPU QWS3MCPU QWS4MCPU
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STAT1:
QISEKSPG QISEKSPA QISEKLRU QISEDLRU QISESQCB QISESQKB
QISESQCA QISESQKA
QISTRCCI QISTRCCD QISTRCCU QISTWMXA QISTWMXU QISTWCTO
QISTW4K QISTW32K
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STATB:
QBSTFLG
DB2GBPST:
QBSTFLG
-SMF 102 IFCIDs 172 and 196 were compatibly updated.
-SMF 102 IFCIDs 267, 268, 317, and 337 are now decoded.
New formats are created by the updated FORMATS member.
-These other IFCIDs in user-sent SMF files are presumably
the trace records that are normally written or needed.
They have been examined and none were change in V10:
4,5,55,87,105,140,141,173,196,199,250,254,258,261,262
-See the text of Change 28.146, which made changes to DB2
processing that were independent of the Beta.
Thanks to IBM DB2 V10 Beta for both EARLY DATA AND DOCUMENTATION!!
Change 28.263 Support for IBM/OMEGAMON XW MQ flat file (INCOMPAT) adds
VMACOMMQ new formats for UTF-8 data, and MXG only tested for up to
Nov 2, 2010 20 datasets, but there can be 26 in total.
Thanks to Michael Reffler, Credit-Suisse, USA
Change 28.262 Support for CA MIM RESOURCE SHARING R11.7 (COMPAT) adds
VMACMIM new variables to several datasets, and many variables
Nov 2, 2010 are now correctly input and formatted, especially times
in MIMCF dataset. Subtypes 0/1/2/4/5/7/8/9/256 and 256
have been tested.
Thanks to Tony Curry, BMC, USA.
Change 28.261 SAS/GRAPH example that uses PDB.ASUMCELP (LPAR-CEC level)
GRAFCEC (built by ASUM70PR) to create charts of CEC Utilization
Nov 1, 2010 for each of the engine types (CP,IFA,ZIP,IFL).
Change 28.260 IP address (45 character text) and IP Port Number were in
VMACTPX TPX Version 4.0 but were overlooked; now they are input
Oct 29, 2010 in 05/06/07/08 subtypes, when possible:
-Invalid subtype 7 records, LENGTH=101, LRECL=104, with
LEN07=93 in bytes 58-59 of the data portion indicating
the record should contain IP Address and Port, but the
record has only 44 bytes remaining in the record, i.e.
the IP Address/Port field are not present.
-Subtype 8 record with a IP Port field that is not a valid
EBCDIC numeric (>?01) with an IP Address with manually
typed all text characters (ABCDEFGHI...) caused hex dump
and error message, now both suppressed with ?? modifier.
-These records were supposedly created by TPX 5.3, but the
Version value in the records is 4.0.
Thanks to Dennis Longnecker, State of Washington Courts, USA.
Change 28.259 Pairs of spurious "WRONG LENGTH OF 200 FOR CMRDATA" log
UTILEXCL messages were printed by _BLDEXCL because only the first
Oct 29, 2010 to the three repeated (for emphasis) PUT statements was
conditional; the 2nd-3rd PUTs always printed a pair of
this warning message. Only if there are THREE adjacent
warning messages (then and now) does the warning apply.
The three PUTs are now inside a conditional DO-Group.
Thanks to Mrs. Brigitte Wallbaum, FINANZ INFORMATIK GMBH, GERMANY.
Thanks to Mr. Dieter Haak of FINANZ INFORMATIK GMBH, GERMANY.
Change 28.258 -Support for WebSphere ID=120 SUBTYPE=20 records has now
VMAC120 been validated (and rewritten) with actual data records.
VMACSMF -ID=120 SUBTYPE=20 records are INVALID because they do NOT
Nov 1, 2010 set the "RECORD CONTAINS SUBTYPES" bit in Byte One of the
SMF header (all other 120 subtypes DO set that bit), so
VMACSMF had a missing value for SUBTYPE for ID=120-20s.
Now, VMACSMF always reads the 2-byte subtype for 120s,
whether or not the bit is enabled.
-Dataset TY12020 is now populated, and the Start and Last
Datetimes are converted from GMT to Local Time Zone.
-There is an undocumented duration field SM120XZ at the
end of the subtype 20 record, following SM120XP; its has
a value about a third of the CPU duration in SM120XP.
-The offset values in the documentation are bogus; they
implied the character variables were fixed length, but in
fact, the data shows the fields are only as long as the
value in their preceding length field
-There are pairs of duplicate Subtype 20 records with all
fields except SMFTIME identical. They are not adjacent,
with 8 subtype 9 records and 3.34 seconds between them.
-Variable SM120SMF is the delay from XL Last Referenced
datetime to SMFTIME, and is as much as 10 seconds, which
is a VERY significant and unexplained delay.
The problem with a big delta is that SMFTIME must be
compared with XL to calculate the GMT Offset, because
there is no GMT Offset value in WebSphere SMF 120s.
Thanks to Paul Gordon, Bank of America, USA.
Change 28.257 ERROR: VARIABLE IDANDSUB ... with BUILDPDB will occur if
ANALID you reuse the same DSNAME with DISP=OLD for your //PDB,
Oct 28, 2010 and your old PDB library was created before MXG 27.27,
and there is a dataset PDB.ID in your old PDB library.
You need to delete that old PDB.ID dataset, e.g.:
// EXEC MXGSASV9
//PDB DD DSN=YOUR.PDB,DISP=OLD
//SYSIN DD *
PROC DELETE DATA=PDB.ID;RUN;
Prior to MXG 27.01, BUILDPDB created the PDB.ID dataset
to count SMF records, but Change 27.005 instead created
the new PDB.SMFRECNT (smaller but more information), and
left the ID dataset (which now had new variables) in the
WORK file by default. But Change 28.148 created ANALID
member to externalize the creation of PDB.SMFRECNT, which
uses %VMXGWORL to locate the ID dataset, since you could
could have tailored MXG to still keep the new ID dataset
in your PDB library. Unfortunately, if the old PDB.ID
dataset exists, the above error occurs.
-Initially, I said:
While it would be possible to detect and delete the
old PDB.ID dataset, that would require you to install
at one new MXG code member, so the simple delete above
is far simpler and safer. That the error has only
occurred once suggests that most MXG sites create a
new DSNAME (GDG or date-in-name) for each daily PDB
library (required for some job sked pkgs), or that
sites that do use DISP=OLD on their //PDB also use
PROC DELETE DATA=PDB._ALL_; before each BUILDPDB.
-However, this Change looks first for WORK.ID and variable
IDANDSUB or second for PDB.ID with that variable to build
PDB.SMFRECNT; otherwise a zero obs PDB.SMFRECNT is built.
P.S. Change 28.148 for ANALID/BUILD001/BUIL3001 was never
written up in CHANGES; a separate change got that number.
Thanks to Alan Gray, CareFirst, USA.
Change 28.256 You should not use a variable named "DATETIME" in MXG
ASUMDB2A reports, because there is always a named variable, like
ASUMDB2B QWACBSC, that is self-documenting and code-clarifying.
ASUMDB2G Variable DATETIME was intended to be a temporary token
ASUMDB2P and shouldn't have been kept, but where it slipped thru
Oct 27, 2010 and ended up being kept in MXG-built datasets, it now has
to be kept and populated. The quick fix, added in
MXG 28.06, to insert a "compiler faker" to suppress an
uninit warning, caused DATETIME to be a missing value.
The first three member's faker was replaced by code to
create/populate DATETIME, and the faker was removed from
ASUMDB2P where it was never kept.
Feb 4: Cosmetic. Variable DATETIME is now length 8.
Thanks to Jim Kovarik, AEGON USA, USA.
Change 28.255 Variable SMF30DAS='EXCP*SEGMENTS*THAT WERE*SUPPRESSED'
VMAC30 was INPUT but not kept. EXCP segments can be suppressed
Oct 27, 2010 with EMPTYEXCPSEC(SUPPRESS) option in SYS1.PARMLIB, or
by DB2 V10 APAR PM17542 which enables S99DASUP.
Change 28.254 The protection for OFF42S3 NE 108 added in Change 28.093
VMAC42 was no protection as it caused misalignment and is now
Oct 26, 2010 removed. With that protection removed, reading the old
data, I now detect, legitimately, an invalid S4 record
with 21 segments totaling 27888 starting at 4053 for an
expected 31944 bytes but the record LENGTH is only 31832.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 28.253 Variables R85STOUT, R85OLRD and R85NLRD are created in
VMAC85 TYPE85AC dataset.
Oct 26, 2010
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Thanks to Jens Mohring, Huk-Coburg, GERMANY.
Change 28.252 Missing semicolon after PROC DATASETS caused Accounting
ANALDB2R reports fields AUTHID DB2 CONNID CORRED to not be
Oct 26, 2010 correctly translated and propagated, and caused attempt
to delete dataset named RUN;
ACCTSORT option added.
Change 28.251 -Assembly of MXG 28.06 EXITCICS fails with this message:
EXITCICS 346 * DC XL2'0000' For Debug purposes RHA
Oct 26, 2010 JZ OPENX no...
** ASMA144E Begin-to-continue columns not blank - JZ
because I had accidentally moved that RHA text in source
line 361 in EXITCICS into column 72, making the statement
a continuation.
code and the decompression exit, when storing into the
MXG Source Library.
-SYSLIB DD needed a third concatenation for the site's
CICS Macro Library.
Thanks to Ken Goodis, Emblem Health, USA.
Change 28.250 -COPYONLY= logic was still dysfunctional. Change 28.211
READDB2 did not proper locate the selection by IFCID, and now the
Oct 26, 2010 SUBTYPE, decoded by VMACSMF, is used for COPYONLY.
-NOTE: VARIABLE QWHCCCN UNINITIALIZED because it should
have been spelled QWHCCN. If CONNID=xxxxxxx selection
was requested in ANALDB2R, this error caused zero obs
to be selected.
-Option UNIQUE will write each DB2 dataset to its unique
DDNAME (e.g., DB2ACCTP to DB2ACCTP.DB2ACCTP) for all of
the datasets that would likely be kept.
Thanks to Larry Stahl, IBM Global Services, USA.
Change 28.249 VMXGSUM is enhanced with MODE= and MEDIAN= added so those
VMXGSUM statistics can be created. The complete list of all of
OCT 20, 2010 the statistics that VMXGSUM can be created:
MEAN MEAN (AVG) P1 PERCENTILE 1%
MIN MINIMUM P5 PERCENTILE 5%
MINLONG MINIMUM 8 BYTE P10 PERCENTILE 10%
MAX MAXIMUM P25 PERCENTILE 25%
MAXLONG MAXIMUM 8 BYTE P50 PERCENTILE 50%
SUM SUM 4 BYTES P75 PERCENTILE 75%
SUMLONG SUM 8 BYTES P90 PERCENTILE 90%
FREQ NUMBER OBS P95 PERCENTILE 95%
STD STANDARD DEVIATION P99 PERCENTILE 99%
VAR variance T Students T
CV coeff of Variation STDERR Standard Error
MEDIAN median KURTOSIS Kurtosis
MODE= mode
With AUTONAME=YES the variables will be named
variable-name_statistic-name e.g., XXXXXXXX_SUM
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.247A The DOCMXG example using _Kdddddd to create a new dataset
VMAC110 is revised so it works, and its exceptions documented:
Oct 20, 2010 1. The %QUOTE(text) function is needed around text that
contains semicolons (which would otherwise end the
%LET statement).
2. But %QUOTE(text) cannot be used if a close paren is in
the text.
3. So the macros with no semicolons are first, followed
by those that contain semicolons in the %QUOTE(text).
4. When redefining MACRO _Edddddd you can use syntax of
a. %%%INCLUDE of the EXdddddd member, and whatever
logic is in that Exit member will then determine
which obs are output. I can't explain why THREE
percent signs are required here, but they are.
b. OUTPUT ddname.dataset syntax to output all obs
to both datasets, or you can use the IF condition
DO group to select which obs to output.
c. NEVER use a DELETE; statement in _Edddddd exits.
Always use a positive IF condition THEN DO; group.
The DELETE statement terminates reading of the SMF
record, which would prevent the reading of any of
the additional repeated segments.
5. You can also specify COMPRESS=NO in the _Kdddddd to
override the MXG COMPRESS=YES default, by putting
COMPRESS=NO before the close paren for that dataset.
6. The example uses _N110 to null all of the 110 datasets
so that ONLY the datasets "reinstated" by defining
their _Wdddddd macro will be created.
%LET MACKEEP=
_N110
MACRO _KCICTRN COMPRESS=NO)
&PDB..NEWDS (KEEP=ABCODE APPLID ENDTIME
FCTOTCN PROGRAM SYSTEM
STRTTIME TASCPUTM TDTOTCN
TRANNAME TSTOTCN
%
MACRO _WCICTRN CICSTRAN.CICSTRAN %
%QUOTE(
MACRO _ECICTRN
%%%INCLUDE SOURCLIB(EXCICTRN);
IF CONDITION THEN DO;
OUTPUT &PDB..NEWDS;
END;
%
);
%INCLUDE SOURCLIB(TYPE110);
-The _N110 macro in VMAC110 was updated in this change to
also null the CICSBAD dataset, which had been overlooked.
Thanks to Brian A. Harvey, HCL America, USA.
Change 28.247 GRAPHICS=NO/YES added as an option. If you do not have
ANALCAPD SAS/GRAPH it will automatically be set to NO, but if we
OCT 19, 2010 detect SAS/GRAPH but you only want a printer plot, you
Oct 26, 2010 can specify GRAPHICS=NO. For readable non-graphics plots
the values being generated by the PROC FORMAT for TYPE
now use the first character.
-Oct 26: Uninitialized LQxLAC, LQxMSU & LQxMSU70 variables
were harmless variables that didn't exist in ASUMCEC.
Thanks to Michael Marcus, ATOS Origin, USA.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 28.246 -ITRM Validation of MXG 28.06 for their next dictionary
VMAC30 precipitated these discoveries and corrections:
VMAC7072 -VMAC30: New Initiator CPU time at INIT and TERM variables
VMACDB2 CPITCTTM CPITCITM CPISRTTM CPISRITM
VMACIMSA were wrong in 28.06; they were INFORMATed and FORMATed
VMACNTSM incorrectly with PIB4.6 instead of PIB4.2 and TIME12.2.
Oct 22, 2010 The wrong FORMAT caused their values to print as trash,
ASUMMIPS the wrong INFORMAT caused their value to be wrong, too
Oct 28, 2010 small by a factor of 10**4.
Nov 14, 2010 These four new CPI CPU times are important and discussed
in Change 28.175.
-VMAC7072: Counter NBKDUPE should not have been kept in
dataset TYPE70EN, and now isn't.
And all of these variables for Engines 64-95 should never
have been kept in PDB.TYPE70 and are now DROPped:
CAIVA -CAIVI CAIYD -CAIYZ
CPUEDTVA CPUEDTVI CPUEDTYD-CPUEDTYZ
CPUPATVA-CPUPATVI CPUPATYD-CPUPATYZ
CPUPDTVA-CPUPDTVI CPUPDTYD-CPUPDTYZ
CPUWAIVA-CPUWAIVI CPUWAIYD-CPUWAIYZ
IFATYPVA-IFATYPVI IFATYPYD-IFATYPYZ
IFAWAIVA-IFAWAIVI IFAWAIYD-IFAWAIYZ
IORATEVA-IORATEVI IORATEYD-IORATEYZ
MVSWAIVA-MVSWAIVI MVSWAIYD-MVSWAIYZ
PCTCIBXD-PCTCIBxz PCTCIBUa-PCTCIBUi
LCPUDEXD-LCPUDExz LCPUDEUa-LCPUDEUi
LCPUWAXD-LCPUWAxz LCPUWAUa-LCPUWAUi
PCTCPBXD-PCTCPBxz PCTCPBUa-PCTCPBUi
PCTONLVA-PCTONLVI PCTONLYD-PCTONLYZ
ZIPWAIVA-ZIPWAIVI ZIPWAIYD-ZIPWAIYZ
If OPTIONS DKROCOND=WARN is used, there will be
messages on the log:
WARNING: variable LCPUDExx in the DROP KEEP...
WARNING: variable LCPUWAxx in the DROP KEEP...
that are not errors and are normal.
-VMACDB2: Variables QWARACE/QWARBSC/QWARESC are Labeled in
new in Version 10 dataset DB2ACCTW. Variable DB2START is
now labeled, and STA0DUR and STA1DUR are formatted.
-SAPIMSBA, SAPIMSON, SAPIMSSP datasets created by TYPEIMSA
processing in JCLIMSLx/ASMIMSLx IMS Log Processing kept
ALL-POSSIBLE 937 variables instead of 31/33/30 kept; MXG
Change 28.066 updated VMACIMSA to use the three _VSAPxxx
macro tokens for their KEEP=list, but then failed to fill
them with the KEEP= syntax and the list of variables to
be kept. Now, only the intended SAP variables are kept
in the three (optional) datasets. And variable IMSRECCH
is now labeled IMS*RECORD*NUMBER*AS HEX CHAR.
-VMACNTSM: Variable VWGRACQP was corrected to VWGRAC1P.
-ASUMMIPS: Datasets/variables were labeled/formatted.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 28.245 MXG 28.06 added ASUMDB2G/ASUMDB2P/ASUMDBSB/ASUMDBSS to
WEEKBLD WEEKBLD, but are now removed. None of those optional data
BLDSMPDB sets should have been added, since neither was previously
Oct 19, 2010 created by prior JCLPDB6 examples. If your BUILDPDB JOB
didn't create them, then WEEKBLD in 28.06 failed with
ERROR: VARIABLE SYSTEM NOT FOUND ON MON.ASUMDB2G
-I had presumed you would EDIT your WEEKBLD to remove
datasets you don't want weekly, and would use EXPDBWEK
exit to add any new datasets to your WEEKBLD output.
-But henceforth, I will NOT add any new optional datasets
to the defaults in WEEKBLD and MONTHBLD examples.
-There is an alternative to WEEKBLD and MONTHBLD to use:
The BLDSMPDB example can EASILY be set up to run daily
to create your daily PDB, and it dynamically creates your
weekly PDB from whatever datasets exist in your daily PDB
libraries, and similarly creates your monthly PDB from
whatever datasets are found in its weekly/daily PDBs.
And you can drop unwanted datasets easily as well.
Thanks to William Edwards, Blue Cross and Blue Shield of Florida, USA
Change 28.244 STC/STK/Oracle VSM "user" SMF records support revised.
VMACSTC -Most datetime variables are changed from GMT to LOCAL.
Oct 19, 2010 These were overlooked. MXG always converts datetimes on
GMT to LOCAL zone, when the GMT offset is known or can be
determined (i.e., when the records have a GMT END time to
match with the always-LOCAL-zone SMFTIME).
Dataset Variables now on LOCAL
STCVSM13 STC13MET STC13MST STC13TIM
STCVSM14 STC14TIM STC14RUN
STCVSM16 STC16MET STC13MST
STCVSM18 STC18MET STC13MST
STCVSM19 STC19TIM STC19RET STC19RST
STCVSM20 STC20MET STC20MST
These variables are now in %VMXGTIME with GMT=YES.
But these datetimes are for events that can be days or
weeks earlier, and the GMT Offset can't be known from the
SMF record, so they are left on GMT, but their LABEL now
contains "ON GMT" to flag them as still on GMT:
Dataset Variables
STCVSM15 STC15LTR STC15TIM
STCVSM25 STC25LUT STC25LWT
STCVSM27 STC27LUS STC27TIM
These variables are now in %VMXGTIME with GMT=YES.
Yes, this is INCOMPATIBLE, if your reporting code changes
the time zone for those former GMT-containing variables.
-STC/STK/Oracle VSM SMF records' _SSTCvvv macros are now
correctly implemented with PROC SORT NODUP and with BY
lists that remove duplicates (and datasets STCVSM25 and
STCVSM27 appear to have occasional fully duplicated SMF
records that are detected and deleted).
-Datasets STCVSM10, STCVSM11, and STCVSM20 are interval
datasets, and their _S Sort Macros create new variables
STCSTRTM='INTERVAL*STARTIME' DELTATM='INTERVAL*DURATION'.
-But Dataset STCVSM20, the Interval RTD utilization data,
which was the actual purpose of this examination of STC
data, has serious holes. The STC20ATM Device Available
time is frequently zero for several 15-minute intervals
but then the next interval record has what appears to be
the total Available Time since the last interval record
with a non-zero value. This means that individual hour
intervals can't be safely analyzed, but by summing the
interval data to the SHIFT or DATE level should provide
reasonable valid data. A problem report will be opened
with Oracle technical support.
Change 28.243 Cosmetic. The MXGNOTE that a SEQUENTIAL or EXPORT format
VGETOBS dataset was found by VGETOBS was revised; that note is
VMXGSUM harmless and is only printed to be in the log in case of
Oct 15, 2010 a subsequent error; in some reports with multiple inputs,
"TAPE" data libraries cannot be used, and this message is
useful to diagnose those (rare) problems. But also, the
call to VGETOBS in VMXGSUM suppresses the message for the
many cases where we know it doesn't matter.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 28.242 The New-in-z/OS 1.12 "In-Ready Work Unit" SMF70U00-U15
VMAC7072 distribution variables (which include ALL engine types)
VMXGRMFI and the three average variables for each engine type
Oct 26,2010 SMF70CTT='AVG*WORK UNITS*FOR CP-S'
SMF70DTT='AVG*WORK UNITS*FOR ZAAPS'
SMF70ETT='AVG*WORK UNITS*FOR ZIIPS'
were not divided by SMF70SRM (sample count) in TYPE70.
These should replace the old READYAVG metrics, per Don:
Be aware that READYAVG deals only with ready address
spaces. The number of ready address spaces can present
a seriously misleading impression of the work on the
system and work being delayed, because READYAVG does
not measure total dispatachable work units. Both the
ready address spaces and the ready enclaves must be
included to count the total dispatachable work units,
and new-in-z/OS-1.12, the above variables provide the
min/max/avg number of work units for CP-s,zAAPs/ZIIPS
and the new PCTWUQWT and SMF70U00-SMF70U15 metrics for
dispatchable work units, quite similar to the original
measures for ready ASIDs.
In addition to correcting the values, this change adds
those min/max/avg Work Unit variables to RMFINTRV, and
three percentage waiting variables are now created from
the three distributions (READYxx, SMF70Qxx, SMF70Uxx)
and are kept in both TYPE70 and RMFINTRV datasets.
PCTRDYWT='PERCENT WHEN*READY TASKS*ARE WAITING'
PCTRDQWT='PERCENT WHEN*IN READY TASKS*ARE WAITING'
PCTWUQWT='PERCENT WHEN*WORK UNITS*ARE WAITING'
These new work unit distributions are only kept in TYPE70
and they include the waiting and active work units for
all engine types, so my labels are revised. The N value
is the count of ALL online engines, except that when
HyperDispatch is active, only the non-parked engines of
ALLl types are included in the N being compared.
SMF70U00='PCT WHEN*WORK UNITS*WAS LE N ONLINE'
SMF70U01='PCT WHEN*WORK UNITS*WAS N+1 ONLINE'
SMF70U02='PCT WHEN*WORK UNITS*WAS N+2 ONLINE'
SMF70U03='PCT WHEN*WORK UNITS*WAS N+3 ONLINE'
SMF70U04='PCT WHEN*WORK UNITS*WAS N+4-5 ONLINE'
SMF70U05='PCT WHEN*WORK UNITS*WAS N+6-10 ONLINE'
SMF70U06='PCT WHEN*WORK UNITS*WAS N+11-15 ONLINE'
SMF70U07='PCT WHEN*WORK UNITS*WAS N+16-20 ONLINE'
SMF70U08='PCT WHEN*WORK UNITS*WAS N+21-30 ONLINE'
SMF70U09='PCT WHEN*WORK UNITS*WAS N+31-40 ONLINE'
SMF70U10='PCT WHEN*WORK UNITS*WAS N+41-60 ONLINE'
SMF70U11='PCT WHEN*WORK UNITS*WAS N+61-80 ONLINE'
SMF70U12='PCT WHEN*WORK UNITS*WAS N+81-100 ONLINE'
SMF70U13='PCT WHEN*WORK UNITS*WAS N+101-120 ONLINE'
SMF70U14='PCT WHEN*WORK UNITS*WAS N+121-150 ONLINE'
SMF70U15='PCT WHEN*WORK UNITS*WAS GT N+150 ONLINE'
They can be compared with the existing distributions in
READY00-READY15,SMF70Q00-SMF70Q12 in TYPE70 dataset.
-VMXGRMFI was also corrected to support R70MIN, which has
been defined, but as it had a null value, the absence of
its invocation was never noticed until now.
-In testing this change, Jim noticed SMF70NCA needed to be
multiplied by 100 as it is 'PCT WHEN*CAPPING*LIMITED...'.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.241 -Variable CPUWAIYA (CPU WAIT*DURATION*CPU 61) was wrong.
VMAC7072 The typo'd CPUWAIYA=MVSWAITA is now CPUWAIYA=MVSWAIYA.
Oct 14, 2010
Thanks to Heimir Hauksson, Barclays, ENGLAND.
Change 28.240 -UTILEXCL could create wrong values in PDB.CICSDICT if
IMACICUN CICS dictionary entries with the same "triplet" values
IMACICUO RVR/DCN/DRL have the same CMODIDNT (field number) in
IMACICUP different orders (could be in different or same APPLID).
UTILEXCL These wrong values were then used to create the IMACEXCL
VMAC110 tailoring member, but that caused no execution error.
Oct 13, 2010 But the wrong variable(s) in CICSTRAN were populated or
IMACICUQ had missing values when they should have been populated.
Oct 14, 2010
Dec 22, 2010 But even after installing this change, and rerunning the
new UTILEXCL's _BLDDICT to build the correct PDB.CICSDICT
observations, your IMACEXCL could still be wrong, because
_BLDDICT appends the new dictionary records to the old in
its replacement of PDB.CICSDICT, so both good and bad
records were still being used, causing that same error.
If you have the SMF records for all your current CICSs,
then you can simply use PROC DELETE DATA=PDB.CICSDICT;
to delete that dataset, and then rerun _BLDDICT, etc.
PROC DELETE DATA=PDB.CICSDICT;
and then _BLDDICT _BLDEXCL _RPTEXCL
to use only the fixed PDB.CICSDICT records to build your
tailored IMACEXCL.
Dec 22: Above paragraph was added, no code was changed.
-Dictionary records with duplicate RVR/DCN/DRL. but with
different field order are now detected and printed by the
macro _BLDEXCL when it creates the IMACEXCL, but UTILEXCL
cannot support two different records differently; as only
the RVR/DCN/DRL exist in the CICSTRAN records. UTILEXCL
can only create one "do group" from the first dictionary
record and that IMACEXCL will create CICSTRAN for all SMF
records that RVR/DCN/DRL, with no execution errors, but
all variables from the fields/segments that are different
in the second dictionary record will be wrong. MXG can't
fix this error because only the RVR/DCN/DRL exist in the
CICSTRAN records. Your CICS guru will have to correct the
DFHMCT text so all structures with the same number and
length of fields have their fields in the same order.
-Support for more Optional CICS fields, UTILEXCL Error.
Member Variable Label
IMACICUN SCBKPOUN Application*USER*AREA*ONE
IMACICUO SCBKNUMB Application*USER*AREA*TWO
IMACICUP CIBIZID Application*USER*AREA*THREE
-Support for another optional CICS field
Member Variable Label
IMACICUQ CANUE1 CANUE1
Thanks to Tony Hirst, Wells Fargo, USA.
Thanks to Henry Steinhauer, Northwestern Mutual, USA.
Thanks to James Hein, Erie Indemnity Company, USA.
====== Changes thru 28.239 were in MXG 28.06 dated Oct 7, 2010=========
Change 28.239 Documentation Notes only. Using the _N7072 "null" macro
VMAC7072 to create ONLY the PDB.TYPE70 dataset caused errors
Oct 7, 2010 NO DATA SET OPEN TO LOOK UP VARIABLES
when PROC SORT DATA=_NULL_ (were _NULL_ replace TYPE70EC)
caused SAS to error (in spite of _NULL_, PROC SORT still
looked for BY variables). Recent changes in SMF 70s now
requires datasets TYPE70SP/EC/EL to be created when the
SMF data is processed, the TYPE70PR data values are used
to create TYPE70, and the new TYPE70EN dataset must be
created from the (temporary) TYPE70EN/EL data if you have
more than 64 engines, since only the first 64 engine's
per-engine-detail is kept in TYPE70.
But the below tailoring example shows how these old-style
substitution macros are used to create only the datasets
PDB.TYPE70 and PDB.TYPE70EN, by reinstating the _Wdddddd
dataset tokens to be created when SMF is read, and the
two _Ldddddd output dataset tokens for clarity.
%LET MACKEEP=%QUOTE(
_N7072
MACRO _WTY70 TYPE70 %
MACRO _WTY70PR TYPE70PR %
MACRO _WTY70SP TYPE70SP %
MACRO _WTY70EC TYPE70EC %
MACRO _WTY70EL TYPE70EL %
MACRO _LTY70 PDB.TYPE70 %
MACRO _LTY70EN PDB.TYPE70EN%
);
%INCLUDE SOURCLIB(VMACSMF,VMAC7072,IMACKEEP);
DATA
_VAR7072
_SMF
_CDE7072
_STY70
Or, you could use the %UTILBLDP macro to generate and
execute the code to create only those two datasets:
%LET PTY70PR =WORK; %LET PTY7002 =WORK;
%LET PTY70X2 =WORK; %LET PTY70Y2 =WORK;
%LET PTY72 =WORK; %LET PTY72DL =WORK;
%LET PTY72GO =WORK; %LET PTY7204 =WORK;
%LET PTY72MN =WORK; %LET PTY72SC =WORK;
%UTILBLDP(BUILDPDB=NO,USERADD=7072,OUTFILE=INSTREAM);
The %UTILBLDP macro is STRONGLY recommended for any SMF
processing that needs tailoring.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.238 MXG 28.03-28.05. THE SMF FILE CONTAINED xxx BYTES note on
VMACSMF the SAS log was wrong if BUILDPDB was used; Change 28.089
Oct 7, 2010 modified VMACID to output SMFBYTES, but that variable was
used internally in VMACSMF to total the byte count for
that log message. The byte counter in VMACSMF is changed
to SMFBYTOT to correct the message and not impact ID.
When wrong, xxx had the record length of the LAST record.
Thanks to Rudol Sauer, T-Systems International GmbH, GERMANY.
Change 28.237 Variable R792PRFX was labeled FRAMES (MB) but was not
VMAC79 converted from frames. While the (MB) in the LABEL should
Oct 7, 2010 document when frame counts are converted to bytes, those
variables must also have MGBYTES. format to confirm that
the contents of the variable is bytes and "prints pretty"
with K/M/G/T suffix with that format.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 28.236 With some of the features of Thruput Manager, some shops
ANALINIT run all jobs in the same job class. That makes ANALINIT
Oct 5, 2010 by jobclass mostly meaningless since TPM will prioritize
work based on service class and other criteria given it
via parameter. This change allows you to choose the
variable to use for breaking the report down. The default
value for SORTBY is JOBCLASS but you might find in these
cases that SRVCLASS or RPTCLASS have more meaning.
-HTMLDEST is also added as a parameter to send the output
to HTML and the MEAN/MAX input queue delays are added to
the final report.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.235 Using %VGETDDS(GOOVOO=gdgbase) caused ERROR: LIBRARY DOES
VGETDDS NOT EXIST. The wrong macro variable &GDGBASE was used
Oct 4, 2010 where &GOOVOO was required.
Thanks to Brian A. Harvey, HCL America, USA.
Thanks to Rhonda Martin, USAA, USA.
Change 28.234 Variables input with $EBCDIC informat that contain $HEX
VMAC102 data are corrected to $CHAR informat, but that is only
VMACCIMS impacting if MXG is executed on ASCII platforms to read
VMACORAC SMF data. Detected in Freddie's final QA tests.
Oct 4, 2010 -VMAC102: QW0022LM QW0022PA QBMCRLIR
-VMACCIMS: RECSTAT
-VMACORAC: ORALOGON
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 28.233 Support for WebSphere MQ Version 7 Accounting Records.
EXWSMQMQ Two datasets are created:
EXWSMQQ dddddd Dataset Description
IMACWSMQ WSMQMQ WSMQMQI Accounting MQI
TYPEWSMQ WSMQQ WSMQQ Accounting Q
TYPSWSMQ See Monitoring WebSphere MQ Version 7, SC34-6937, for the
VMACWSMQ documentation on these data, which are written to the
VMXGINIT SYSTEM.ADMIN.ACCOUNTING.QUEUE.
Oct 2, 2010
Change 28.232 -ANALRMFR failed when PDB=SMF was use with some reports;
ANALRMFR Change 28.155 revised token names for TYPE70EN, and some
Oct 6, 2010 resets of _WTY70PR were missing.
-While PDBOUT=PDB worked, PDBOUT=XXXX failed because the
new TYPE70EN dataset was written to PDB instead of XXXX.
Thanks to Russ Alexander, OIT Service Delivery, USA.
Change 28.231 NDM-CDI NDRMTYPE='RT' record INPUT STATEMENT EXCEEDED
VMACNDM error when NDMOFFPA was non-zero, a condition not seen
Oct 1, 2010 before, and my guess about the order of the optional
segments was wrong.
Thanks to Douglas C. Walter, Citigroup, USA.
Thanks to Brent Turner, Citigroup, USA.
Change 28.230 FORMAT MG070CR decodes SMF70CCR to identify the Capacity
FORMATS Change Reason:
VMAC7072 SMF70CCR Formatted Value
Oct 1, 2010 0 0:NO CHANGE
1 1:POWERSAVE
2 2:CYCLE STEERING
3 3:EXTERNAL
4 4:EXTERNAL
Change 28.229 MXG Search tool did not select CHAR variables because the
VMXGSRCH TYPE field was not UPCASED, and if the last variable in a
Sep 30, 2010 dataset is numeric, the generated code did not wrap to
close the continuation correctly; these are now fixed.
Also, MXG 28.05 updates added the capability to search
for text in Labels and for format names.
On a positive note, Scott commented:
I really do get a lot of benefit using VMXGSRCH when
looking for evidence of a dataset or USERID or a CICS
terminal-name. It's a great tool, particularly where I
needed to find evidence of a CICS terminal in some CICS
PA report, but looking in MXG for it CICS STATS.
And VMXGSRCH is not only for MXG built datasets. VMXGSRCH
will search ALL of the SAS datasets in ANY data library,
searching ALL variables in those datasets for ANY value,
printing the found observations. See Change 28.147.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.228 Variable NRCPUS wrong in PDB.RMFINTRV with HiperDispatch.
VMXGRMFI It had the number of installed processors because parked
Sep 29, 2010 time, CPUPATTM, was not kept nor subtracted from SMF70ONT
when NRCPUS, the average number of ONLINE CP engines was
calculated.
Thanks to Richard Schwartz, State Street Bank, USA.
Thanks to Brian Kruse, State Street Bank, USA.
Change 28.227 TYPEITRF INPUT STATEMENT EXCEEDED RECORD LENGTH type=17x.
VMACITRF because Change 28.197 didn't correctly INPUT these fields
Sep 27, 2010 CORDBI CORDBP CORDBT that were added.
Thanks to Lindholm Orjan, Volvo, SWEDEN.
Change 28.226 -TYPE113 variable LPBUSY replaces wrong-named LPARCPU, as
ASUM113 percent busy in TYPE113 is for each Logical Processor.
VMAC113 -ASUM113 variable LPARBUSY replaces LPARCPU since there,
Sep 23, 2010 the percent busy is for the LPAR. New variable LPARCPUS
Oct 4, 2010 counts the number of LPs active in this LPAR.
Normally, I'm reluctant to change variable names, but
the SMF 113 is new so only a few "early adopters" will
be effected, and the old names were deceptively wrong.
-LPARCPUS is the true Average Number of ONLINE Engines, as
it is calculated as SMF70ONT/DELTATM.
-Variables from TYPE70PR that were added to the dataset
PDB.TYPE113 are also now added to PDB.ASUM113.
-ASUM113 corrected to not fail when PDB.TYPE70PR doesn't
exist, but all variables that are merged in from 70PR
will always exist in PDB.ASUM113, with missing values if
there was not 70PR dataset.
-SM113CPT is only populated if SM113VN2 GE 2, i.e., z196.
(See Change 30.123 for revision).
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.225 Macro variable VGETCRDT is created, contains the datetime
VGETOBS in character when the SAS dataset was created, and macro
Sep 23, 2010 variable VGETMTYP is the type of dataset (data/view/etc).
Oct 5, 2010 VGETCRDT is only populated under SAS; it is not in WPS.
Thanks to MP Welch, Aprize, Inc, USA.
Change 28.224 New TYPE70EN dataset (per-Engine TYPE70 detail) had 100%
VMAC7072 PCTCPUBY for Parked Engines; PCTCPUBY is now recalculated
Sep 23, 2010 using SMF70PAT. Also, SMF70CIN was blank, now is not.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.223 Support for DB2 V10 Compressed SMF records has been added
DFH$MOLS inside the existing EXITCICS member, which is the ASM
EXITCICS source that creates a SAS INFILE EXIT named CICSIFUE.
Sep 23, 2010 Once assembled into a load module placed in //STEPLIB,
and enabled with %LET SMFEXIT=CICS; in your //SYSIN,
the exit will be used for either CICS or DB2 records,
processing either compressed or uncompressed SMF records.
Full documentation is in the comments in EXITCICS member.
While IBM CICS provides their DFH$MOLS program that will
decompress CICS records (JCL example in that MXG member),
IBM initially chose NOT to provide a DB2 decompression
utility, but in Feb, 2011, APAR PM27872 announced that
the DSNTSMFD sample program was available to decompress.
Note: IF THE EXIT DOES NOT EXIST, INTERNAL SAS CODE IN
MXG WILL BE USED TO DECOMPRESS EITHER CICS OR DB2
DATA, BUT THAT CODE IS EXTREMELY CPU EXPENSIVE.
MXG messages warn you to instead use EXITCICS.
Note: See MXG Newsletter FIFTY-SEVEN for comparisons
processing compressed and uncompressed CICS data
with DFH$MOLS versus EXITCICS versus SAS code.
Thanks to Rich Anderson, SAS Institute, USA.
Change 28.222 ITRM only, MXG 28.04-later, DB2STAT4 NOT SORTED ERROR.
VMACDB2 The circumvention is to insert this statement in SYSIN:
Sep 22, 2010 %LET EPDBOUT= _SDB2ST4 ;
so that the DB2STAT4 dataset is sorted before _SDB2STS
is executed. _SDB2STS creates DB2STATS from STAT0/1/4;
The MXG logic in _SDB2STS was revised in 28.04, and the
PROC SORT DATA=_LDB2ST4 that had been in _SDB2STS was
removed, because MXG executes _SDB2ST4 before _SDB2STS,
so that sort was no longer needed. But ITRM did not
execute the _SDB2ST4 macro. In ITRM, the dataset tokens
_WDB2ST4 and _LDB2ST4 are the same dataset when _SDB2STS
is executed, so that old PROC SORT DATA=_LDB2ST4 had put
DB2STAT4 in the right order, so there was no error, but
without MY sort, the unsorted DB2STAT4 exposed my error.
-ITRM Support will have a Hot Fix to insert the _SDB2ST4
sort prior to the _SDB2STS execution; fortunately, this
circumvention AND that hot fix insertion can coexist.
Change 28.221 MXG 28.05-minus, an INCORRECT note "INVALID WQ SEGMENT"
VMAC116 is harmless and there is no loss of data when the records
Oct 7, 2010 originally described below are found. IBM MQ Support has
confirmed Qsegment records with no WQ Segments can
happen in V6 and V7 if a thread has exactly 9 queues.
The next overflow SMF record/segment is allocated in
anticipation of the transaction a 10th queue. With
exactly 9, a 10th wasn't opened, so the second segment
was left empty.
Oct 20, IBM APAR PM24302 confirms that statement, quoting
from my original change text in the problem description.
Below is the Sep 22 original change text on this message:
WebSphere MQ 7.01 INVALID WQ SEGMENT error messages were
due to SMF 116 subtype 2 records that contained only the
WTID (thread identification) segment and did NOT contain
any WQ (queue-level accounting) segments. The ONLY
purpose of subtype 2 records is for additional WQ
segments that wouldn't fit in previous subtype 1 record.
In addition, the QWHCXTYP field contained a zero, which
is not a documented connecting system type code. But,
MXG printed that message because it expected the WQ
triplet in the subtype 2 and unconditionally input it.
The code was restructured to input the common header and
use QWHSNSDA, the number of triplets, to conditionally
now input the triplets. Subtype 2 records with no WQ
segment can be detected because all WQxxxxxx variables in
dataset MQMACCTQ will be blank or missing values, but the
"INVALID" "INVALID WQ SEGMENT" message is gone.
Thanks to Victoria Lepak, Aetna, USA.
Change 28.220 DB2 Summary ASUMDBxx and Trending TRNDDBxx members are
ANALDB2R revised to create consistent names, as well as adding
ASUMDB2A new DB2 V9 and DB2 V10 variables and externalizing the
ASUMDB2B interval value:
ASUMDB2G -Default interval for both statistics and accounting is
ASUMDB2P now set by macroUvariable &INTASUM (default=HOUR), so
ASUMDB2R youTcanDchangeTthatBdefaultSinterval externally, without
ASUMDB2S EDITing the ASUMxxxxSinto yourDUSERID.SOURCLIB, using
ASUMDBAA %LET INTASUM=yourchoice;SUtoBset your chosen interval.
ASUMDBSB -Statistic dataset changes:
ASUMDBSS -Datasets ASUMDBBS/TRNDDBBS renamed to ASUMDBSB/TRNDDBSB.
TRNDDB2A -Datasets ASUMDB2S/ASUMDB2G/ASUMDB2B/ASUMDBSB that were
TRNDDB2A created by members ASUMDB2S/ASUMDB2G/ASUMDB2B/ASUMDBSB
TRNDDB2B no longer exist; datasets TRNDDB2X/TRDDDBBS/TRNDDB2S
TRNDDB2G no longer exist.
TRNDDB2P -Members ASUMDBSS/TRNDDBSS create these sets of the three
TRNDDB2R statistics summary datasets:
TRNDDB2S Member Dataset Created from
TRNDDBAA ASUMDBSS ASUMDBSS DB2STATS
TRNDDBSS " ASUMDBSB DB2STATB
Oct 3, 2010 " ASUMDBSG DB2GBPST
Dec 28, 2010 TRNDDBSS TRNDDBSS ASUMDBSS
" TRNDDBSB ASUMDBSB
" TRNDDBSG ASUMDBSG
-Accounting dataset changes:
-Members ASUMDB2S/ASUMDBSB contain only comments that the
member ASUMDBSS should be used in place of both members.
-Members ASUMDB2G/ASUMDB2B were a mess. Previously they
summed DB2GBPST/DB2STATB into ASUMDB2G/ASUMDB2B datasets
but those names were also used for DB2ACCTG/DB2ACCTB
summarization. Now they process only Account datasets.
-WEEKBLD's BY list for these three DB2 Stat ASUMs have
SHIFT removed; those datasets are summarized by HOUR so
SHIFT was not used, but was inconsistently kept, so its
removal prevents NOT SORTED errors.
-Accounting dataset changes:
-Member VMXGDBAA, previously used in ASUMDBAA/ANALDB2R
no longer is used and is archaic. Member ASUMDBAA can
still be used, if you want ALL of the DB2ACCTx datasets
summarized, but it now is only a series of individual
%INCLUDEs of these members:
Member Dataset Created from
ASUMDB2A ASUMDB2A DB2ACCT
ASUMDB2B ASUMDB2B DB2ACCTB
ASUMDB2G ASUMDB2G DB2GBPST
ASUMDB2P ASUMDB2P DB2ACCTP
ASUMDB2R ASUMDB2R DB2ACCTR
-Trending of individual ASUMDB2x Account datasets:
Member Dataset Created from or
TRNDDB2A TRNDDB2A ASUMDB2A DB2ACCT
TRNDDB2B TRNDDB2B ASUMDB2B DB2ACCTB
TRNDDB2G TRNDDB2G ASUMDB2G DB2GBPST
TRNDDB2P TRNDDB2P ASUMDB2P DB2ACCTP
TRNDDB2R TRNDDB2R ASUMDB2R DB2ACCTR
-Additional corrections:
-ASUMDB2A. Two variables QTXANPL and QXCASCDP were in the
SUM list are moved to the MAX list. They were incorrect
in datasets built by the old ASUM/TRND members.
-TRNDDB2A. Looked for DB2ACCT first, but now it uses
ASUMDB2A first if it exists.
-VMACDB2 common variables added to new DB2ACCTR "Remote".
-Dec 28: ASUMDB2R INTERVAL now set by &INTASUM.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.219 Cosmetic. If DATETIME argument was missing, the ABORT
VMXGDUR statement blew away a Windows session so you never saw
VMXGSUM the error message. Now, the error is printed and the
Sep 22, 2010 invocation is ended without the ABORT. This error can
Oct 7, 2010 only occur when testing a new VMXGSUM invocation; that
DATETIME argument is always required, except when the
INTERVAL=NONE argument is specified.
-VMXGDUR, Oct 7:
WARNING message for invalid interval= values updated
To include all possible valid values.
Change 28.218 Includes of ASUMDBAA/TRNDDBAA added in MXG 28.05 caused
BLDSMPDB errors and were replaced by includes of ASUMDB2A/TRNDDB2A
Sep 21, 2010 and ASUMDB2B/TRNDDB2B.
Oct 5, 2010 -Oct 5: If AUTOALOC EQ NO and FIRSTRUN EQ YES then all of
the directories needed are tested and created if the do
not already exist.
Thanks to Cletus McGee, ALFA Insurance, USA.
Thanks to Mary Kay Pettengill, MSI, USA.
Change 28.217 The CPUID section is now protected for a truncated ID=70
VMAC7072 subtype 1 record (created by B37 ABEND in SMF dumping).
Sep 21, 2010 Other sections were already protected.
Change 28.216 Invalid raw data for RH018 with zero values caused very
VMACTNG large positive or negative values. While the error is in
Sep 16, 2010 the NSM cube itself, a possible circumvention is to us
IF RH018001 GT 0 AND RH018002 GT 0 THEN DO;
OUTPUT _WTRH018; /* RH018 , DEFINED IN VMACTNG*/
END;
in the EXTRH018 exit member; this will cause the DELTATM
between intervals calculated by MXG to be twice DURATM,
so these intervals can be identified.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 28.215 NOTES: FIRST/LAST UNINITIALIZED with BAR=TIME had no
GRAFLPAR impact as they are not used with that option, but they
Sep 15, 2010 are no longer printed. Arguments DEVICE/DISPLAY were
removed, as your current site defaults will be used.
Thanks to Cletus McGee, ALFA Insurance, USA.
Change 28.214 ANALDB2R report selection didn't honor BEGTIME/ENDTIME.
ANALDB2R Starting with MXG 28.05, ANALDB2R passed those selection
Sep 14, 2010 criteria to READDB2 so that if PDB=SMF was used (so that
READDB2 was called) BEGTIME/ENDTIME were used for select.
Now, PDB=PDB or PDB=SMF honors BEGTIME/ENDTIME selection.
Thanks to Betty Wong, Bank of America, USA.
Change 28.213 This Change was replaced by 28.220.
Change 28.212 -New (very small) TYPE74ID dataset is now created when the
ANALRAID TYPE74 or TYPE74CA are output, so the mapping format that
ASUMCACH ASUMCACH requires can be automagically built in ASUMCACH,
EXTY74ID eliminating a full pass of TYPE74CA dataset.
VMAC74 -PDB.ASUMCACH now contains variables character DEVMODEL
VMXGINIT and its numeric version in variable MODEL.
VMXGSUM -ANALRAID now uses 8-character DEVMODEL, instead of MODEL
Sep 13, 2010 with 3-byte numeric in HEX6 formatted value, to support
Oct 29, 2010 newer, longer (3390A) control unit model names.
-If TYPE74ID is does not exist, ASUMCACH uses TYPE74CA, as
before, but DEVMODEL will contain 3390??.
-In testing this change, numerous Missing Value messages
were printed on the SAS log, all from VMXGSUM NORMn=
arguments that had valid missing values. VMXGSUM was
revised to test and suppress those cosmetic messages.
-In testing this VMXGSUM revision for the NORMn arguments:
-It was discovered that NORMn=A/B syntax, with only one
variable A that had only one character name, was never
being normalized. Fortunately, there was no instance
of this syntax in MXG code, but it is now corrected.
-Also, if B was missing or zero (with any length "A"),
so the division was never executed, the value output for
"A" output was SUM(A). Now, A is a missing value.
-Oct 29: %VMXGOPTR relocated to prevent warning message.
Change 28.211 Using COPYONLY argument wrote ALL SMF records; the
READDB2 selection criteria were not used for the COPYONLY writes.
Sep 11, 2010
Thanks to Larry Stahl, IBM Global Services, USA.
Change 28.210 DB2 V8.1-DB2 V9, MXG 28.02-28.05, DB2ACCT and DB2ACCTP,
VMACDB2 these variables added by APAR PK62161, MXG Change 28.051:
Sep 10, 2010 QXRWSFET QXRWSINS QXRWSUPD QXRWSDEL
were wrong because the prior field, QXSTXMLV, was
increased to 8 bytes but that increase was overlooked,
causing the subsequent fields to be misaligned/trashed.
Thanks to Betty Wong, Bank of America, USA.
Change 28.209 If INCLAFTR=BUILD005,BUILDPDB=NO is used to build only
UTILBLDP the PDB.JOBS/STEPS/PRINT/NJEPURGE/SPUNJOBS datasets,
Sep 9, 2010 the TYPE30xx,TYPE6,TYPE26J2 inputs for BUILD005 were
Jul 7, 2011 sorted into the PDB library, which caused BUILD005 to
fail, as it expected inputs to be in WORK library.
But since the purpose of INCLAFTR=BUILD005 should be to
create the above PDB datasets, this change removes the
sort of those input datasets into the PDB data library.
Jul 2011: If you really do want any or all of those raw
TYPE30xx, TYPE6, and/or TYPE26J2 to be kept in the PDB,
you can add these PROC SORTs to the EXPDBOUT= argument:
PROC SORT NODUP DATA= _WTY30U1 OUT= _LTY30U1 ;
BY _BTY30U1 ;
PROC SORT NODUP DATA= _WTY30U4 OUT= _LTY30U4 ;
BY _BTY30U4 ;
PROC SORT NODUP DATA= _WTY30U5 OUT= _LTY30U5 ;
BY _BTY30U5 ;
PROC SORT NODUP DATA=_WTY6 OUT=_LTY6 ;
BY _BTY6 ;
PROC SORT NODUP DATA= _WTY26J2 OUT= _LTY26J2 ;
BY _BTY26J2 ;
Or, if INCLAFTR=BUIL3005, for TYPE26J3, use:
PROC SORT NODUP DATA=_WTY25 OUT=_LTY25 ;
BY _BTY25 ;
PROC SORT NODUP DATA= _WTY26J3 OUT= _LTY26J3 ;
BY _BTY26J3 ;
Change 28.208 MXG incorrectly set R7451TIM to 16 microseconds when
VMAC74 it should have been 16 milliseconds; the variables
Sep 9, 2010 R7451CT3, R7451CT4, R7452PRT, R7452PWT are divided by
R7451TIM, and thus were wrong.
Thanks to Rick Southby, Insurance Australia Group, AUSTRALIA.
Change 28.207 Unused Change.
Change 28.206 Invalid APPTUNE SMF 102 IFCID 8133 record had invalid
VMAC102 offset of '7532'x for QBMCRQLO in APPTUNE Segment 9 for
Sep 7, 2010 Long Names, causing INPUT STATEMENT EXCEEDED ERROR.
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.205 Julian Date variables with FORMAT 6. were increased to 7.
VMACACF2 so the full seven digits can be seen (e.g. 2010099):
VMACEPIL -VMACEPIL - OMJULDAT
VMAC6367 -VMACACF2 - LIDCDATE LIDIPDAT LIDADATE LIDDXPDT
VMACHSM - LIDATIME is now a datetime variable when both
Sep 6, 2010 LIDADATE and LIDATIME are GT 0.
Sep 18, 2010 -VMACHSM - MCDJDATE
-VMAC6367 - DSCRDT DSEXTD
Change 28.204 Support for local installation optional USERSTR field in
IMACICUM CICSTRAN dataset from SMF 110 subtype 1 modified records.
IMACEXCL
VMAC110
Sep 3, 2010
Change 28.203 Variable LIDATIME was not formatted, but now contains
VMACACF2 the datetimestamp value (DATETIME21.2) of last access.
Sep 1, 2010 Date variables LIDCDATE LIDIPDAT LIDADATE LIDDXPDT all
contain Julian Dates YYYYDDD and are cannot be formatted
as a SAS Date variable.
Change 28.202 Support for RACF EVENT 82 (PTCREATE) creates TYPE8082
EXTY8082 dataset.
IMAC80A
VMAC80A
VMXGINIT
Sep 1, 2010
Thanks to Bill Arrowsmith, EuroClear, BELGIUM.
Change 28.201 MXG 28.05 only. GOPTIONS DEVICE=GIF was added in VMXGINIT
VMXGINIT but could change the size of your graphs. Now, GOPTIONS
Aug 31, 2010 only sets default COLORs and PATTERNs.
Change 28.200 z/OS utility to construct VBS blocks in RECFM=U format
UDEBLOCK from a PC/ASCII VBS file failed when only one byte was
Aug 31, 2010 left at the end of a block, since that would be the first
byte of the two-byte length field. MXG logic worked with
zero or two-or-more, but not one; an extensive rewrite of
the program was required. This uploaded file had a series
of 32760 byte blocks, but then one block of 32759 bytes
that contained parts of three blocks, with only one byte
of the next block at the end, which exposed the error.
Thanks to Carl Sommer, SAS Institute, USA.
Change 28.199 -Variables added from PDB.TYPE70PR are now populated ONLY
ASUM113 when the SM113CTM end time is within one hour of STARTIME
VMAC113 of the RMF data; previously, any 70 from the same SYSTEM
Sep 2, 2010 was used. APAR OA30486 will synchronize 113 intervals
with SMF, so eventually an exact merge can be used.
-LPARNAME is added to PDB.TYPE113, but will be populated
only if matching PDB.TYPE70PR observations exist.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.198 -CA-NSM/TNG datasets RH021 thru RH030 had only variables
VMACTNG from the header and RH020xxx, because of incorrect KEEP=
Aug 26, 2010 arguments.
Sep 1, 2010 -Variable INSTANCE was not kept nor in BY list for AI010.
-Packet counters in AI010 and RH018 are accumulated, so
the SORT macros _STAI010 and _STRH018 are rewritten to
deaccumulate those four variables. You will need to use
%INCLUDE SOURCLIB(TYPSTNG); to create PDB.AI010/RH018 to
contain the interval (deaccumulated) values, or use
%LET PTAI010=WORK;
%LET PTRH018=WORK;
%INC SOURCLIB(TYPESTNG);
_STAI010;
_STRH018;
if you want the interval datasets in the //WORK library.
Thanks to Xiabo Zhang, FISERV, USA.
Change 28.197 INVALID DATA FOR CHAR1 caused INPUT STATEMENT EXCEEDED.
VMACITRF The INPUT of VER with $CHAR1 was corrected to $CHAR1.
Aug 26, 2010 (i.e., missing period was added to the informat) in two
places. But Change 28.227 is also needed for VER='01'x.
Thanks to David J. Schumann, Blue Cross of Minnesota, USA.
Change 28.196 If you asked for IFCIDS=STATISTICS and WANTONLY a list of
READDB2 DB2STA* datasets, macro variable KILLSORT showed up as
Aug 25, 2010 unreferenced in DB2PST where it did not belong.
Thanks to Dan Case, Mayo Foundation, USA.
Change 28.195 If NRECORD was a null value or an alpha string, VMXGGETM
VMXGGETM failed with an invalid numeric value. Now, if an invalid
Aug 24, 2010 string is detected, NRECORD is set to the then current
value of the OBS option. This change uses the %DATATYP
macro provided by SAS, in their autocall library.
Change 28.194 Using ONLY the MXG-supplied CONFIGV9 and NOT having the
CONFIGV9 SAS-supplied DSNAME=SASHLQ..CNTL(BAT&YY) in //CONFIG DD
SASAUTOS caused the SAS default LOCALE=ENGLISH_UNITEDSTATES to be
TRIM used, instead of the LOCALE=ENGLISH_UNITEDKINGDOM that
Aug 2, 2010 was required for this English Site. The result was that
Sep 24, 2010 MXG saw an invalid 'BA'x character (for NOT symbol) in
Sep 30, 2010 the TRIM member of the SAS-supplied SASAUTOS PDS, that
had been built with the UNITEDKINGDOM LOCALE, instead of
the expected '5F'x with LOCALE=ENGLISH_UNITEDSTATES.
MXG's CONFIGV9 intentionally does NOT specify LOCALE, as
that should be picked up from the site's BAT&YY member.
The error was in the %TRIM macro (now used in VMXGSUM),
but it caused this completely-off-the-wall error:
NOTE: LINE GENERATED BY THE INVOKED MACRO "VMXGEXP".
&WORD = &WORD * &BY ;
_
22
(Long ago, problems with character conversion of the
NOT symbol caused me to NEVER use that symbol, and
instead MXG uses NE or NOT character text.)
-SAS did detect the incorrect LOCALE setting, printing
WARNING: There is an incompatibility between session
encoding and the SASHELP encoding. When such a
mismatch occurs, some features may not behave as
expected. For additional information, contact your Site
Administrator
-The original text of this change INCORRECTLY blamed the
error on the DSN=*.NULLPDS syntax in their //SASAUTOS DD
//SASAUTOS DD DSN=*.NULLPDS,DISP=SHR
// DD DSN=SAS.yadayada.SASAUTOS
which was INCORRECTLY thought to have prevented the %TRIM
macro from being resolved. While *.NULLPDS in MXGSASxx
JCL examples was removed in Change 27.108 in MXG 27.05,
because it was no longer needed and MIGHT cause errors,
in fact its removal, while recommended, is not required.
Thanks to George Canning, Produban UK, ENGLAND.
Thanks to Mark Dawson, SAS Institute, ENGLAND.
Change 28.193 -Full support for IMF records in SMF format, so IMF SMF
VMACCIMS records can be processed with BUILDPDB. Change 28.137
TYPEIMFS created TYPEIMFS to process IMF-SMF data, but was only
Aug 23, 2010 for "stand-alone" execution. This update to VMACCIMS
moved the "IMF-SMF-unique" logic inside the _CDECIMS code
and (transparently) recognizes the input file is SMF or
IMSLOG. Member TYPEIMFS was then updated/simplified.
-To add IMF processing to your BUILDPDB, you use the four
EXPDBxxx exit members, with this syntax:
EXPDBINC: %INCLUDE SOURCLIB(VMACCIMS);
EXPDBVAR: MACRO _VARUSER _VARCIMS ... %
EXPDBCDE: MACRO _CDEUSER _CDECIMS ... %
EXPDBOUT: _CHAIN
_SIMFDBD
_SIMFDB2
_SIMFPGM
and you must define the output DDNAME/DDNAMES for the
one or four data libraries where you want your output
datasets written, before the include of BUILDPDB?
- If you output to Disk, the same DDNAME can be used
for all four datasets, but,
- if you want to write your IMF data to tape, you must
have a separate DDNAME and DSNAME for each dataset
(because, internally, for performance run times, MXG
must open two of those datasets simultaneously, and
z/OS does not allow more than one dataset opened on
tape media).
%LET PIMFDBD=CIMSDBDS; /*DEFINE OUTPUT DDNAMES */
%LET PIMFDB2=CIMSDB2;
%LET PIMFPGM=CIMSPROG;
%LET PIMFTRN=CIMSTRAN;
Thanks to Denise Willers, Infocrossing, USA.
Thanks to Ken Steiner, Infocrossing, USA.
Change 28.191 Cosmetic cleanup when ITRM validated MXG 28.05:
ASUM113 -VMAC84 variables R84FN, R84DMA and R84GMSMIN are now
CREATEBC spelled R84FNFW, R84DMAV and R84_GMSMIN in the KEEP=. Two
PROCSRCE instances of '97'x (ASCII) or '00'x (EBCDIC) are removed.
VMAC7072 -Detection of ASCII '97'x (long dash) added in PROCSRCE.
VMAC84 -And, detection of '00'x in the EBCDIC output created by
Aug 23, 2010 CREATEBC converts it to blank (in case the PROCSRCE error
messages added above were overlooked!).
-Temporary datasets ZxTYxxx created by TYPE113/ASUM113 are
deleted. Temporary dataset BADINTRV is left intentionally
in case you need to see which intervals were dropped.
-Temporary TYPE70EC/TYPE70EL datasets are deleted; they
are used to create the new PDB.TYPE70EN.
-TYPE80A variable RACF329 is now spelled RACF320.
Thanks to Chris Weston, SAS ITRM Development, USA.
Change 28.190 MXG 28.05, QLACLOCN wrong if it is longer than 16 bytes.
VMACDB2 There is a fixed 16-byte field for QLACLOCN, but if that
Aug 20, 2010 remote location address is longer, it is "truncated", and
a non-zero offset to the full "un-truncated" field exists
but 28.05 incorrectly INPUT that longer field. This has
ONLY been seen with DB2 V9 with IPV6 IP addresses, which
are usually 17-20 bytes long, but can be up to 39 bytes.
2012: Not noted in 2010, QLACLOCN/QWHDSVNM were increased
to $128.
Change 28.189 The COMPALL program requires REGION=1700MB to compile all
COMPALL MXG members that process SMF records (to verify that they
VMACCMHM can all be combined without conflicts for any temporary
Aug 20, 2010 variables). The program contained 407,097 source lines.
It also exposed an error in VMACCMHM that did not have an
IF ID=_IDCMHM THEN DO; code block.
Change 28.188 RMM INVALID NUMERIC DATA NE notes are produced when the
VMACEDGR expiration date is "PERMANENT". The DATE fields will be
Aug 19, 2010 missing values, like other non-date-expiration-dates, but
the variables RDEXPDCH,RVEXPDTO, the "ORIGINAL*CHARACTER"
expiration dates will contain PERMANENT, with no NOTES.
Thanks to Sam Bass, McLane Co., USA.
====== Changes thru 28.187 were in MXG 28.05 dated Aug 18, 2010=========
Change 28.187 -First 28.05, JCLTESTx jobs only, VARIABLES NOT FOUND in
ASUM113 ASUM113 which is included automatically by TYPE113.
Aug 18, 2010 The ASUM113 member adds data from TYPE70PR when it is
found, but incorrect logic in the new ASUM113 failed when
there was no TYPE70PR dataset found. ASUM113 was revised.
SMF records. The error was missed because JCLQASAS is the
primary z/OS QA job now, and it (accidentally) always had
a PDB.TYPE70PR created when the ASUM113 was executed.
I'll now ensure JCLTESTx is also tested for z/OS QA.
-NEWSLETTER FIFTY-SIX is now dated August 18, 2010, as it
should have been.
====== Changes thru 28.186 were in MXG 28.05 dated Aug 17, 2010=========
Change 28.186 Support for ThruPut Manager V6.2(PTF 6209) adds these
VMACTPMX variables to dataset TYPETPMX:
Aug 17, 2010 DBS_SDBL DBS_SDPA DBS_SDPL PCS_EP PCS_MP PCS_PPSQ
Other new fields could be created, but I can only
update MXG for the data fields that exist in sample
SMF records.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to Rick Ralston, Humana, USA.
Change 28.185 Cosmetic. TYPETMNT records with unexpected MSGID printed
VMACTMNT log messages for every instance; now, only the first 10
Aug 17, 2010 instances will be printed.
Thanks to Linda S. Berkley, DISA, USA.
Change 28.184 The syntax LIBNAME TYPE30 'D:\MXG\ANALDSET\TYPE30 \'; is
ANALDSET not valid on PC SAS; the blanks before the back-slash
Aug 17, 2010 must be removed.
Thanks to Sarel Swanepoel, South African Revenue, South Africa
Change 28.183 Documentation and cosmetic changes to DB2 102 data.
VMAC102 -QWP1IXPX contains the name of the default Buffer Pool; it
Aug 16, 2010 is $EBCDIC6 and replaced QWP1IXPL which was only $EBCDIC4
Aug 24, 2010 -QWP9MISC is now formatted $HEX2.
-QWP1SCER, QWP4STHT, QWP4STRL, QWPBDB2S are now $EBCDIC1.
instead of $CHAR1. and no longer formatted $HEX2., and
their labels now contain ? to indicate they are Y/Ns.
-QWP1BDUR/QWP1URCK/QWPBDLEN/QWPBTLEN/QWP1FLBX are CHAR
variables with $HEX format, but they contain numbers.
Rather than create a conflict of CHAR vs NUM variables,
they are expanded to 3 bytes and the numeric value is now
carried in the character variable.
-QWP4ESC now formatted $HEX2. instead of $HEX4.
-QWP4RMAX is the maximum number of RID blocks, for example
147. TMON reported QWP4RMAX=4,816,896, which (I think)
is the number of bytes, because 147*32768=4,816,896.
-IFCID=106 fields that are now input:
QWP4MIS5 QWP4MS4B QWP4MS4D QWP4MS4E QWP4METR QWP4CHEC
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 28.182 MXG 28.05 is REQUIRED for APAR OA30563 and APAR OA33976,
VMAC30 which increased Service Unit fields in SMF 30 records to
Aug 16, 2010 8-bytes, but MXG 27.10 thru MXG 28.04 were in error and
Sep 9, 2010 caused VERY LARGE SERVUNIT values and in these variables
SERVUNIT CPUUNITS SRBUNITS IOUNITS MSOUNITS ENCLCPSU
IFEUNITS IFAUNITS ZIPUNITS ZIEUNITS
and the CPU times that are calculated from Service Units
CPUTOTTM/SRVTCBTM/SRVSRBTM
to all be extremely wrong when those APARs are installed.
The variables are in TYPE30_4/TYPE30_5/TYPE30_V/TYPE30_6
and PDB.JOBS/PDB.STEPS/PDB.SMFINTRV datasets.
MXG 28.05 is required to support OA30563 and OA33976.
FORTUNATELY: the SRVTCBTM/SRVSRBTM/CPUTOTTM time that are
calculated from Service Units were created in MXG only
for comparison with the real CPUTM/CPUTCBTM/CPUSRBTM time
and are not used in any MXG reporting
-because long ago it was claimed that using service units
to calculate CPU times (TCB and SRB and TOTAL) was more
accurate than the CPUTCBTM/CPUSRBTM/CPUTM variables that
are in the SMF 30 record, a claim I have never been able
to verify, as I have only seen VERY small differences
between CPUTM and CPUTOTTM.
Only these three calculated CPU times are wrong:
CPUTOTTM/SRVTCBTM/SRVSRBTM
ALL other CPU time variables are correct and are NOT
impacted by this error in service units in TYPE30.
Originally, APAR OA26832 added 8-byte service unit fields
to the PERF segment, increasing LENPERF to 192, but MXG
Change 27.122 was wrong, testing for LENPERF GE 196, so
that new code block was never being executed, and the
new, longer service unit fields were never being input.
But when OA30563/OA33976 added more fields that increased
LENPERF to 211, so the code block was now executed, that
exposed a second error in Change 27.122, where a +3 was
coded instead of +6 to skip reserved field SMF30RS6,
causing all variables after that +3 to be misaligned,
with VERY large values in those service unit fields,
which are used to calculate the service-unit-based CPU
time variables CPUTOTTM, SRVTCBTM, and SRVSRBTM.
The original change text cited RSU1006 as the cause, but
that is not true; the two APARs happened to be installed
along with RSU1006, causing the incorrect citation.
Thanks to Jerry Urbaniak, Acxiom, USA.
Thanks to Cheryl Watson, Watson and Walker, USA.
Change 28.181 Updates made as a result of MXG 28.05 QA jobstream:
ANALCAPD -CLEARDB2 updated for new datasets created from DB2 SMF.
ANALRAID -READDB2 suppresses sorts when PDBOUT=WORK, suppressed
ASUMCACH sort of DB2GBPST, and some of the variables needed by the
ASUMDBAA ANALDB2R program are created in the _S macros.
CLEARDB2 -ASUMCACH did not support DEVMODEL='3390A'; to avoid full
EXZCO02 sort of both TYPE74 and TYPE74CA, variable MODEL was
READDB2 created as a numeric, MAXed to carry thru in lieu of ID.
TRNDDBAA But '3390A' caused INVALID ARGUMENT as it's not numeric.
VMAC42 Conflict resolved internally by making MODEL a HEX value
VMAC7072 and that will work until '3390G' DEVMODEL shows up.
VMAC74 -ANALRAID had site-specific ODS token
VMACDB2 -Cosmetic updates to ANALCAPD/ASUMDBAA/TRNDDBAA/VMXGDBAA
VMXGSRCH VMXGSRCH/VMAC42/EXZCO02 and updates to VMAC7072/VMAC74.
Aug 15, 2010
Change 28.180 -Support for user-created MQNAME segment that creates the
IMACICUL optional MQNAMECI variable in CICSTRAN dataset.
UTILEXCL
VMAC110
Aug 13, 2010
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 28.179 Utility to read PDS/PDSE directories of a concatenation,
UTILPDSL assigning the level from 1 to X (x being the number of
Aug 11, 2010 libraries in the concatenation) to each member of each
library, so a pair (for example, two JES2 PROCLIBs or
two STEPLIBs, etc.) can be compared for member matches.
Place your concatenation in the JCL (in the example it
is a PROCLIB concatenation copied from SYS1.PROCLIB
member JES2) and point the PDS= parameter at that DD.
If you want the second report to contain ONLY those
cases where a member first appears in a specific PDS,
count down from the top of the concatenation to that
PDS and use that as the LEVEL= parameter. If that
LEVEL= is empty, all members will be listed in the
second of the two reports. This could be used to
determine if a PROCLIB (for example) has members that
are being used. If you specify LEVEL= and the second
report is not there, then no members in that PDS are
being referenced in this particular concatenation.
Reports:
1) The datasets in the concatenation
2) The PDS members, the dataset, and the level in
concatenation from whence they came.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.178 Comments had the correct output FILENAME UOUT but the
UDEBLOCK actual code had the FILENAME misspelled as UOW. ALL of
Aug 9, 2010 the references are now corrected to UOUT.
Thanks to Carl Sommer, SAS Institute, USA.
Change 28.177 -Modified to carry the SORTEDBY values into the output
BLDSMPDB datasets. In addition, now uses the datasets in the
VMXGALOC MON LIBNAME to determine which datasets will be kept
Aug 9, 2010 and the sort orders, and uses the WEEK1 LIBNAME for
ASUMDBSS monthly processing.
ASUMDBAA -If you need to build old data, you can use BLDSMPDB
Sep 9, 2010 but you need to specify RUNDAY=PDB,RERUN=ddmmmyy
where ddmmmyy is the SAS date value you want to have
in ZDATE. ZTIME will be set to midnight of that day.
-ASUMDB2A and ASUMDB2B members have ASUMDBAA and
ASUMDBSS alternates.
-VMXGALOC did not allocate CICSTRAN and DB2ACCT libs
as the doc said they did. Now it does. They are
allocated as:
CICSTRAN is allocated as basedir\cicsddmmmyy
DB2ACCT as basedir\db2ddmmmyy
both are retained based on the number of days specified
by DB2KEEP and CICSKEEP, with defaults of 14.
Change 28.176 Support for SARMON, a free tool that converts SOLARIS SAR
EXNMONIS data into the NMON format. The home page of the tool is:
VMACNMON http://www.geckotechnology.com/sarmon
VMXGINIT Some changes were required to MXG to support SARMON data:
Aug 8, 2010 -TOP record with 'NaN' (a UNIX unique "NOT A NUMBER")
which required protection with double question marks.
-Array size of WORDS increased from 255 to 1024 because
the SARMON 'IOSTATxxxx' records all contained 340 words.
-NMON or SARMON data could be incorrectly processed if
"descriptor records" were longer than 2048 bytes; the
NMONTEXT INPUT was increased to $VARYING32000.
-DISNAME was increased from $20 to $64 because SARMON
DATA had longer "disk" names for the IOSTAT data.
-SARMON RECTYPE=DISKSVCTM and DISKWAITTM are the same as
NMON DISKSERV and DISKWAIT, with different WORD2 names.
-Other SARMON DISKxxxx RECTYPEs have same spelling for
both RECTYPE and WORD2 so they were automatically output
and combined to create PDB.NMONDISK dataset.
-Seven IOSTAT (BUSY/READ/WRITE/XFER/BSIZ/SERV/WAIT) data
are supported and create new PDB.NMONIOST dataset with
I/O statistics for the non-disk I/O.
-SARMON objects WLMPROJECTCPU,WLMPROJECTMEM,WLMZONECPU,
WLMZONEMEM, and PROCSOL are supported and those variables
are output in the PDB.NMONINTV dataset.
Thanks to Marc-Antoine Gouillart, AMF, FRANCE.
Change 28.175 -Support of z196 WITH MORE THAN 64 ENGINES REQUIRES 28.05.
EXT11904 (Earlier MXGs will NOT contain any CPU data for engines
EXT11932 64-95 in TYPE70 and RMFINTRV datasets.
EXT11933 -A z196 with LESS THAN 64 engines with z/OS 1.11-1.09 does
EXT11934 NOT require MXG 28.05.
EXT11935 -Support of z/OS 1.12 enhancements requires MXG 28.05.
EXT11935 -DO NOT USE MXG 28.04 to read z/OS 1.12 RMF data, due to
EXT11936 errors (including ARRAY SUBSCRIPT OUT OF RANGE in ID=70),
EXT11937 and other errors in VMAC74 processing with MXG 28.04.
EXT11948 -MXG 28.03 and earlier MXG Versions that support 1.11 data
EXT11949 TOLERATE z/OS 1.12 records, but with no new data fields.
EXT11950
EXT11951 -The TYPE70 architecture is revised for z196s with 64 plus
EXT11952 engines. Sixty-four sets of variables for CPUs 0-63 are
EXT11973 still in TYPE70, but no new variables for CPUs 64+ were
EXT11974 created in this change. Instead, the new PDB. YPE70EN
EXT11975 "CPU Engine" dataset is created with one set of names and
EXT11976 with one observation for EACH engine, with no limit to
EXT11977 the number of engines, ever, should you actually need to
EXT11978 know the metrics for a specific MVS TYPE70 CPUID.
EXT11979 -The PDB.TYPE70PR dataset will also contain an observation
EXT11980 for every LCPUADDR.
EXTY4226
EXTY9033 All of the z/OS 1.12 changes are COMPATIBLY made.
EXTY9034
FORMATS -TYPE7 New variables:
VMAC113 SMF7DTYP SMF7LSD SMF7DRP SMF7LSN
VMAC30 -TYPE30 New variables:
VMAC42 The CPITCBTM and CPISRBTM "Initiator" CPI CPU times
VMAC64 are split into their "INIT" versus "TERM" events in
VMAC7 four new CPI variables in TYPE30_4/STEPS data:
VMAC7072 CPISRITM='CPI*SRB*STEP*INIT'
VMAC74 CPISRTTM='CPI*SRB*STEP*TERM' (Sum is CPISRBTM)
VMAC89 CPITCITM='CPI*TCB*STEP*INIT'
VMAC90A CPITCTTM='CPI*TCB*STEP*TERM' (Sum is CPITCBTM)
VMACDCOL SMF30CAI='CAPACITY*ADJUSTMENT*IND'
VMXGINIT SMF30CCR='CAPACITY*CHANGE*REASON'
Aug 8, 2010 SMF30CHC='CAPACITY*CHANGE*CNT'
Aug 15, 2010 SMF30ACR='RCTPCPUA*ACTUAL'
SMF30NCR='RCTPCPUA*NOMINAL'
SMF30SCF='RCTPCPUA*SCALING*FACTOR'
SMF30PCF='CAPACITY*FLAGS'
Note that these CPI times are NOT captured in RMF 72s,
and previously the INIT/TERM CPU times were lumped into
one bucked. Now, you can assign the "INIT" CPU time
to the INITTIME interval and the "TERM" CPU time to the
TERMTIME interval and improve the capture ratio.
-TYPE42 New Dataset: TYPE4226 NFS CREATE/DELETE/RENAME
The documentation of the subtype 7 and 8 and the new 26
are in the Network File System Guide and Reference.
-TYPE42 New variables:
Dataset: TYPE42VS:
SMF42VNL='VOLUME NAME LIST'
Dataset: TYPE42NF and TYPE42NU:
SMF42CI6='IPV6*ADDRESS*OF CLIENT HOST'
-TYPE64 New variables:
SMF64FD1 SMF64FD2 SMF64DAU
-TYPE70 New variables:
SMF70CR SMF70ZEI
SMF70NCR SMF70NPR SMF70NTR SMF70CAI SMF70CCR
SMF70SRM SMF70CMN SMF70CMM SMF70CTT SMF70DMN SMF70DMM
SMF70DTT SMF70EMN SMF70EMM SMF70ETT SMF70U00-SMF70U15
-TYPE70PR New variables:
SMF70TCB SMF70SRB SMF70NIO SMF70SIG SMF70WTD
APAR OA29820 also added SMF70WTD "LPAR Overhead"
-TYPE70X2 New variables:
R7024MSK R7023MET R7023MEC
-TYPE72GO New variables:
R723NADJ R723CECA
-TYPE74CA New variables:
R7451CT5 R7451CT6
-TYPE747P New variables:
R747PAND
-TYPE748 New variables:
R748LFLF R748LFLY R748LFLS R748LFPQ R748LFIT R748LFCR
R748LFR1 R748LFR2 R748LFIF R748LFOD R748LFOA R748LFDF
R748LFIO R748LFTC R748LFBC
-TYPE748A New variables:
R748AAS0 R748AAS2 R748AAS3 R748AAS4
-TYPE748R New variables:
R748RTQ
-TYPE748X New variables:
R748XPTQ
-TYPE89 New variables:
SMF89CHC SMF89ACR SMF89NCR SMF89SCF SMF89CAI
SMF89CCR SMF89PCF
-TYPE9033 New dataset with variables
SMF9033T SMF9033N SMF9033S
-TYPE9034 New dataset with variables
SMF9034T SMF9034F SMF9034A SMF9034N SMF9034S SMF9034I
SMF9034R SMF9034F
-TYPE113 New variables, but see also Change 28.166.
SM113CPT
-TYPE119 New Datasets:
T11904 TYP11904 TCP PROFILE INFORMATION FOR STACK
T11932 TYP11932 DVIPA STATUS CHANGE
T11933 TYP11933 DVIPA REMOVED
T11934 TYP11934 DVIPA TARGET ADDED
T11935 TYP11935 DVIPA TARGET REMOVED
T11936 TYP11936 DVIPA TARGET SERVER STARTED
T11937 TYP11937 DVIPA TARGET SERVER ENDED
T11948 TYP11948 CSSMTP CONFIGURATION DATA
T11949 TYP11949 CSSMTP TARGET SERVER CONNECTION
T11950 TYP11950 CSSMTP MAIL
T11951 TYP11951 CSSMTP SPOOL
T11952 TYP11952 CSSMTP STATISTICS
T11973 TYP11973 IPSEC IKE TUNNEL ACTIVATE
T11974 TYP11974 IPSEC IKE TUNNEL DEACTIVATE
T11975 TYP11975 IPSEC DYNAMIC TUNNEL ACTIVATE
T11976 TYP11976 IPSEC DYNAMIC TUNNEL DEACTIVATE
T11977 TYP11977 IPSEC DYNAMIC TUNNEL ADDED
T11978 TYP11978 IPSEC DYNAMIC TUNNEL REMOVED
T11979 TYP11979 IPSEC MANUAL TUNNEL ACTIVATE
T11980 TYP11980 IPSEC MANUAL TUNNEL DEACTIVATE
-TYP11904 dataset is NOT decoded, it has 21 sections
and I hope NO ONE EVERY wants it decoded, but if you
REALLY do, then please send an example SMF record.
-TYP11948-TYP11952 CSSMTP common segments are decoded
but not all subtype-specific segments are, since I
have no data records.
-TYP11948-TYP11952 IPSEC common segments are decoded
but not all subtype-specific segments are, since I
have no data records.
-Many of the new 119 datasets contain IPV6 IP addresses,
which are a $CHAR16. field with hexadecimal values that
are expanded to a 39-byte text field with colons.
This 16-byte hex value in the SMF record
'0123456789ABCDEF0123456789abcdef'X
'7CC3C1E2000000050000000000003000'X
is printed in ftp connection messages as
0123 4567 89ABCDEF cdef
7CC3:c1e2:00000005::3000
is expanded to this 39-character text field in MXG:
0123:4567:89AB:CDEF:0123:4567:89AB:CDEF
This code creates the 39-byte recognizable text value:
INPUT CHAR16IP $CHAR16. @;
IPADR6=PUT(INPUT(SUBSTR(CHAR16IP,1,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,3,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,5,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,7,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,9,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,11,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,13,2),$CHAR2.),$HEX4.)
!!':'!!
PUT(INPUT(SUBSTR(CHAR16IP,15,2),$CHAR2.),$HEX4.);
-TYPE119 New Variables:
TYP11902: TTTTLSFP
TYP11903: FCCCONID FCDCONID
-DCOLLECT: Added to DCOLDSET:
DCDDS9F1 DCDJBNMC DSCSTNMC DCDTIMEC
-DCOLLECT: Added to DCOLDC:
DDCFCT DDCBLMT DDCCFS DDCDVCS DDCFSCAL
DDCFRLOG DDCFRLGS DDCFEXTC DDCFA2GB DDCFPSEG
DDCFKYL1 DDCFKYC1 DDCFKYL2 DDCFKYC2 DDCFVSP DDCFSDB
DDCFVORD DDCFCAR
DDCCT DDCDSCF DDCRBYTE DDCBLKLM DDCBSZLM DDCTAPE1
DDCPSCA DDCPSEG DDCVSP DDCVSPV DDCKLBL1 DDCKLBN1
DDCKYCD1 DDCKLBL2 DDCKLBN2 DDCKYCD2
-Internally, in VMAC7072, thirty-two sets of variables ARE
created for engines 64-95 and used to create the TYPE70
measurements, with these variable name suffixes:
Variables CPUID SUFFIX CPUID SUFFIX CPUID SUFFIX
(All other) 00-09 D0-D9 10-21 DA-DL 22-34 DN-DZ
35-60 ZA-ZZ 61-86 YA-YZ 87-95 VA-VI
Variables
PCTxxxBss 00-09 Y0-Y9 10-21 YA-YL 22-34 YN-YZ
where xxx= CPB CIB IFB ZIB (all other PCT are above).
And four new formats are created that map these pairs of
suffix and CPU numbers (but probably will never be used):
$MG070SC maps suffix to "all other" variable CPU Number
$MG070CS maps CPU number to "all other" suffix
$MG070SP maps suffix to "four PCT" variable CPU Number
$MG070PS maps CPU Number to "four PCT variable suffix
Change 28.174 The variable ZDATE in all MXG datasets is "ZEE DATE WHEN
IMACZDAT ZEE OBS WAS CREATED" and it is used as both an audit date
Aug 6, 2010 and for selection of which observations are kept in MONTH
PDB's in MONTHBLD and BLDSMPDB. If you have to rebuild
a PDB library, you must change the ZDATE to have the
correct date, or data can be lost when in the MONTH PDB.
Previously, you had to EDIT the IMACZDAT member, but you
can instead use this DATA step to set the ZDATE value:
DATA _NULL_;
DATE='01JUL2010'D;
TIME=PUT(DHMS(DATE,0,0,0),32.);
DATEC=PUT(DATE,16.);
CALL SYMPUT('ZDATE',DATEC);
CALL SYMPUT('ZTIME',TIME);
RUN;
%LET MXGZDATE=%QUOTE(
ZDATE=&ZDATE;
ZTIME=&ZTIME'
);
%INCLUDE SOURCLIB(BUILDPDB);
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.173 Variable ZIPTM was used in GRAFWRKX to carry the zIIP
GRAFWRKX time, but it already existed in RMFINTRV as the total of
Aug 5, 2010 the TYPE72GO zIIP time, it was included as uncaptured
zIIP time on the bar charts. Now the uncaptured zIIP and
IFA/zAAP times are correctly calculated for the charts.
Change 28.172 CA-Dispatch Version 11 type SMF 6 INCOMPATIBLY CHANGED by
IMACCADI the insertion of fields, causing INVALID JESNR messages.
VMAC6 There is no "version" field in CA's record, so a test for
Aug 5, 2010 LENGTH=347 AND SMF6LN1=287 is used to identify V11 data.
These new variables are created:
CADIATYP CADIDJDC CADIDPLX CADIEFRM CADIJDEI
CADIJDLI CADIOLVR CADIPASS CADIPCR CADIPRTR CADIXFRM
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.171 IFLs only, MXG 28.01+, STARTIME was a missing value in
VMXG70PR the PDB.ASUM70LP dataset.
Aug 3, 2010
Thanks to William Edwards, Blue Cross Blue Shield of Florida, USA.
Thanks to Bob Maple, Blue Cross Blue Shield of Florida, USA.
Change 28.170 Cosmetic. LOG=NO and NOEXIMSG=NO added to VGETOBS to
VMXGFIND suppress unneeded/unwanted log messages, and MXGNOTE
Jul 29, 2010 added at the end to report how many datasets were found
with matching values.
Change 28.169 -New ANALCAPD analysis will estimate the impact of setting
ANALCAPD a Defined Capacity limit, at the CEC level, with both a
Jul 29, 2010 text report and a graph (if SAS/GRAPH is found) or plot
Aug 14, 2010 (if no SAS/GRAPH) of the intervals which might be limited
by a cap, i.e., intervals where the rolling four hour
average exceeded the Cap value that you specified.
Arguments:
PDB=PDB Libname where the ASUMCEC dataset is found
DEFCAP=130 MSU Value of the CAP you want to examine
INTERVAL=HOUR Must match the ASUMCEC interval
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.168 -New MULTIPDB utility will creates a new SAS DATA library
MULTIPDB with ALL of the datasets that exist in the list of input
VGETSORT data libraries to be read. If a dataset is sorted in all
VGETLIBS of the input data libraries, the output dataset will also
Jul 27, 2010 be sorted. Options for KEEPing or DROPing datasets by
Aug 9, 2010 name is supported, and the input list can use a colon as
a wildcard to read all DDs starting with that string.
// EXEC MXGSAS
//PDB1 DD DSN=PDB(0),DISP=SHR
//PDB2 DD DSN=PDB(-1),DISP=SHR
//PDB3 DD DSN=PDB(-2),DISP=SHR
//PDB4 DD DSN=PDB(-3),DISP=SHR
//MON DD DSN=PDB.MON,DISP=SHR
//TUE DD DSN=PDB.TUE,DISP=SHR
//NEW DD DSN=PDB.COMBINED,DISP=(,CATLG)......
%MULTIPDB(INLIBS=PDB: MON TUE,OUTLIB=NEW);
will create all datasets found in all of the INLIBS= into
the //NEW data library.
-VGETSORT added parameters for efficiency and to reduce
the number of messages written to the SAS log.
-New VGETLIBS %MACRO will take a list of LIBNAMEs and see
if they exist and what engine they were created by.
The list of libnames and engines are returned, and used
by MULTIPDB to determine if the INLIBS= libnames exist.
If none of the LIBNAMES in INLIBS= are found, MULTIPDB
terminates.
Change 28.167 Variables NDMCERT and NDMCERI are added to NDMCT dataset.
VMACNDM
Jul 27, 2010
Change 28.166 Revised, enhanced support for TYPE113 SMF records, based
ASUM113 on John Burg's SHARE Boston 2010 Presentation.
FORMATS -PDB.TYPE113 dataset contains the complete detail level,
VMAC113 with an observation for each CPU Address, while the new
TYPS113 PDB.ASUM113 dataset, created by revised ASUM113, has all
TYPS113E of the counters summed for each LPAR for each interval;
Jul 27, 2010 This PDB.ASUM113-level is used to calculate the RNI for
Aug 12, 2010 each LPAR for zPCR; while all the new variables are also
created in TYPE113 dataset, IBM recommends that the LPAR
summary PDB.ASUM113 data be normally used.
-The ASUM113 program will look for PDB.TYPE70PR dataset in
the same PDB library as TYPE113, and if found, it is used
to add variables CPUTYPE CECSER LPARWLMG and SMF70HDM in
both PDB.TYPE113 and PDB.ASUM113.
-The TYPS113E "Enhanced" standalone program reads 70 & 113
SMF to create both PDB.TYPE113 and PDB.ASUM113 with the
TYPE70PR variables added.
- New RNI metric is created in TYPE 113, additional metrics
are calculated, and SM113VN2 is formatted to identify if
the processor type is z10 or a new z196.
-SM113VN2=1 for z10, SM113VN2=2 for z196; new MG113VN
format will print z10 or z196.
-Relative Nest Intensity calculations for the z10 and z196
are added to dataset TYPE113 using these two algorithms,
but only the new variable RNI is actually created:
Z10RNI =(1.0*L2LP+2.4*L2RP+7.5*MEMP)/100.
Z196RNI=1.6*(0.4*L3P+1.0*L4LP+2.4*L4RP+7.5*MEMP)/100
-Users will need to know the RNI to determine the correct
LSPR workload for the latest LSPRs, which is documented
in the new LSPR Manual on ResourceLink:
https://www-304.ibm.com/servers/resourcelink/lib03060.nsf
/pages/lsprindexpdf/$file/SC28118714_20100714.pdf
-New variables are created in TYPE113:
z196 only:
L2P ='PERCENT*SOURCED*FROM*L2*CACHE'
L3P ='PERCENT*SOURCED*FROM*L3*CACHE'
L4LP='PERCENT*SOURCED*FROM*L4*SAME BOOK'
L4RP='PERCENT*SOURCED*FROM*L4*DIFFERENT*BOOK'
z10 and z196, but different equations for each CEC:
ESTICCPI='ESTIMATED*INSTRUCTION*COMPLEXITY*CPI'
ESTFINCP='ESTIMATED*CPI FROM*FINITE*CACHE/MEM'
ESTSCP1M='ESTIMATED*SOURCING*CYCLES*PER L1 MISS'
RNI ='RELATIVE*NEST*INTENSITY'
EFFGHZ ='EFFECTIVE*GIGAHERTZ*CYCLES*PER NANO'
TLB1MISS='TLB*CPU MISS*PERCENT OF*TOTAL CPU'
TLB1CYCL='CYCLES*PER*TLB*MISS'
PTEPCTMI='PAGETABLE*ENTRY*PCT OF TLB*MISSES'
-These z10-only variables have missing values (i.e., not
calculated for z196): L15P L2LP L2RP. (Added 26Aug2011).
-SM113CPT was not kept in the TYPE113 dataset.
-If a counter reset is found in one counter, that entire
interval from that SYSTEM/LPAR is deleted.
-The original logic attempted to correct when counters
wrapped, by creating the value of a full 8-bytes 'FF'x,
to add when wrap was detected:
IF EIGHTFFF=. THEN DO;
CHAR8FFF='FFFFFFFFFFFFFFFF'X;
EIGHTFFF=INPUT(CHAR8FFF,&PIB.8.);
RETAIN EIGHTFFF;
DROP CHAR8FFF;
END;
and that worked fine on PC SAS. But on z/OS, the value of
EIGHTFFF is ZERO, instead of the expected 1.8E+19 value.
SAS Support has recognized this as a defect (that has
been that way since SAS V6 on z/OS), so this iteration
will just delete intervals if the counter wrapped.
-John's SHARE paper had some missing counters for the z196
equations that are included in this MXG update and will
be in his final version of that paper:
L4LP adds EXTND152 and EXTND155
L4RP adds EXTND134 and EXTND143
MEMP subtracts EXTND134 and EXTND143
-The ANAL113 program print's the report on page 26 of his
paper, and also prints the counters that are used to
create that report for each LPAR for each interval, using
the PDB.ASUM113 dataset as input.
-I will update MXG ANALZPCR to use RNI in a later change.
-APAR OA30486 became available in Oct, 2010, back to z/OS
1.10, adding SMFINTVAL=SYNC so that SMF 113 records can
be synchronized with your SMF and RMF interval data.
Thanks to Cheryl Watson, Watson & Walker, USA.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to John Burg, IBM, USA.
Thanks to Tony Hirst, Wells Fargo, USA.
Thanks to Richard Schwartz, State Street Bank, USA.
Change 28.165 IMS Statistics Log Record LCODE=56x TPCPSSTY='09'X record
VMACIMS caused INPUT STATEMENT EXCEEDED RECORD LENGTH. The DO
Jul 26, 2010 group for the '09'x subtype was incorrectly located.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Change 28.164 Support for SMF 119 new subtypes 32-37 and 48-52.
EXT11932 Nineteen new datasets are created (but not yet data'd).
EXT11933
EXT11934 dddddd Dataset Description
EXT11935 T11932 TYP11932 DVIPA STATUS CHANGE
EXT11936 T11933 TYP11933 DVIPA REMOVED
EXT11937 T11934 TYP11934 DVIPA TARGET ADDED
EXT11948 T11935 TYP11935 DVIPA TARGET REMOVED
EXT11949 T11936 TYP11936 DVIPA TARGET SERVER STARTED
EXT11950 T11937 TYP11937 DVIPA TARGET SERVER ENDED
EXT11951 T11948 TYP11948 CSSMTP CONFIGURATION DATA
EXT11952 T11949 TYP11949 CSSMTP TARGET SERVER CONNECTION
EXT11973 T11950 TYP11950 CSSMTP MAIL
EXT11974 T11951 TYP11951 CSSMTP SPOOL
EXT11975 T11952 TYP11952 CSSMTP STATISTICS
EXT11976 T11973 TYP11973 IPSEC IKE TUNNEL ACTIVATE
EXT11977 T11974 TYP11974 IPSEC IKE TUNNEL DEACTIVATE
EXT11978 T11975 TYP11975 IPSEC DYNAMIC TUNNEL ACTIVATE
EXT11979 T11976 TYP11976 IPSEC DYNAMIC TUNNEL DEACTIVATE
EXT11980 T11977 TYP11977 IPSEC DYNAMIC TUNNEL ADDED
VMAC119 T11978 TYP11978 IPSEC DYNAMIC TUNNEL REMOVED
VMXGINIT T11979 TYP11979 IPSEC MANUAL TUNNEL ACTIVATE
Jul 25, 2010 T11980 TYP11980 IPSEC MANUAL TUNNEL DEACTIVATE
Change 28.163 The code for TMON/DB2 has been updated to "standard" MXG
VMACTMDB structure; the original code did not define the _Vdddddd
Jul 23, 2010 macros, and the _Sdddddd dataset sort macros were DATA
steps rather than PROC SORTS.
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 28.162 Support for ITRF adds variables to ITRFDATA and ITRFSUM
VMACITRF datasets to support ITRF V420 IF2.
Jul 22, 2010
Change 28.161 Example 3 was missing the second close-paren in both of
TIMEBILD the %TIMEBILD invocations. The execution just hung with
Jul 21, 2010 no error message nor clue, except for an astute user.
Thanks to Graham Cornwall, Donovan Data Systems, ENGLAND.
Change 28.160 -CleverView for TCP/IP TN3270 variable CTCPIPAD was wrong,
VMACCTCP with constant value of 64.64.64.64, now corrected.
Jul 21, 2010 -The CVTTZ GMT Offset field was added to the SMF record,
and when it exists is used to correct the CTCPTIME STCK
value to the local clock. CTCPTIME is the Start Time of
the session and will be constant for all intervals for
that session.
-The interval records cannot be SYNC'd with SMF intervals.
-The CTCPHOST (HOST APPLICATION NAME) can be blank, when
the user has not yet logged on.
Thanks to John Howard, Florida Northwood Shared Center, USA.
Change 28.159 This example to use BLDSMPDB to write daily PDBs to a GDG
GDGDAILY did not pick up yesterday's SPIN data library.
Jul 20, 2010
Change 28.158 Support for APAR OA31648 adds new counters to show how
VMAC42 many retries were performed to obtain buffer latches to
Jul 19, 2010 satisfy record management requests. From APAR text:
-If a client has a serious application contention issue
while accessing buffers to read data, there is no
external indication or measurement data to show this
reason for delay.
-While primary serialization in RLS is at the record
level, there is still a need for SMSVSAM to perform
very short term serialization of the local buffer
containing the CI in order to maintain integrity of the
local buffer pool.
-When contention is excessive, a single record
management request may need to retry an obtain for the
buffer latch many times. A small amount of contention
is normal, so displaying latches at a given point in
time does not give an indicator of how long a request
may have been delayed.
Variables SMF42GRW and SMFA2GRW are added to datasets
TYPE42D1 and TYPE42D3 respectively.
Change 28.157 Support for VM ACCOUNT ID='09' for ISFC (Inter-System
EXVMISFA For Communications) record creates five datasets:
EXVMISFE
EXVMISFI dddddd Dataset Description
EXVMISFL VMISFA VMISFA ISFC ACTIVE CONVERSATION
EXVMISFS VMISFE VMISFE ISFC END CONVERSATION
FORMATS VMISFI VMISFI ISFC INITIATE CONVERSATION
VMXGINIT VMISFL VMISFL ISFC LINK STATISTICS
TYPEVM VMISFS VMISFS ISFC START CONVERSATION
Jul 19, 2010
Thanks to Greg Reed, Travelport GDS, USA.
Thanks to Rick Stuchell, Travelport GDS, USA.
Change 28.156 Support for IFCID=27 decodes QW0027SP and QW0027NR and
FORMATS decodes and formats QW0027OZ.
VMAC102
Jul 18, 2010
Thanks to Victoria Lepak, Aetna, USA.
Change 28.155 MXG 28.04, only if _N7072 is used. The output of the new
VMAC7072 temporary TYPE70EC and TYPE70EL datasets now names their
Jul 17, 2010 _WTY70EC and _WTY70EL tokens so that _N7072 can be used.
Thanks to Kim Westcott, State of New York, USA.
Change 28.154 -MXG detection of inserted or excluded fields in CICS 110
VMAC110 is enhanced by test for CPUTM GT 2*ELAPSTM that prints
Jul 18, 2010 error messages if true. Previous IF TASKNR=. tested the
Jul 21, 2010 only Packed Decimal field, which is a missing value if
MXG was out of alignment, but that could overlook new
inserted fields after the location of Task Number.
-Spurious message that STID=110 had skipped data removed;
the SKIP=SKIP-604 should have been SKIP=SKIP-652, but the
CICW2R dataset was correct in spite of that message.
-Variable PGDPGM, Program Name, was not kept in dataset
CICPGD, nor was it labeled, a major oversight as all of
the information in CICPGD Statistics are for the program!
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Gerard Bosker, Rabobank Nederland, THE NETHERLANDS.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 28.153 XAM TCP datasets TOTCPU were incorrectly divided by 100.
VMACXAM
Aug 15, 2010
====== Changes thru 28.152 were in MXG 28.04 dated Jul 5, 2010========
Change 28.152 Support for zTPFC, TPF Continuous Monitoring has a few
EXTPFC92 fields added to existing datasets and two new datasets
EXTPFC98 added by this change
IMACTPFC
VMACTPFC DDDDDD DATASET Description
Jul 2, 2010
Jul 21, 2010 TPFC92 TPFC92 LPAR UTILIZATION
TPFC98 TPFC98 DASD SERVICE TIME
Thanks to Bob Wilcox, HP, USA.
Change 28.151 Support for zCost AutoSoftCapping V 1.5.00 user SMF
EXZCO01 record, which replaces the TDSL product with these three
EXZCO02 new datasets:
EXZCO03
IMACZCOS dddddd dataset description
TYPEZCOS
TYPSZCOS ZCO01 ZCOS01 ZCOST CPC
VMACZCOS ZCO02 ZCOS02 ZCOST LPAR
VMXGINIT ZCO03 ZCOS03 ZCOST SYSPLEX/CPC
Jul 2, 2010
Thanks to Alan Delaroche, zCostServices, FRANCE.
Change 28.150 Type 42 subtype 15 did not protect for new data, and the
VMAC42 addition of variables SMF42FAI and SMF42FAJ caused the
Jul 1, 2010 second and subsequent segments to be misaligned with bad
data values resulting in TYPE42S1 dataset.
Thanks to Michael Friske, FMR, USA.
Change 28.149 Sample reports had typos, corrected.
ANAL119
Jun 30, 2010
Change 28.148 TMS DEVTYPE was blank for TRTCH 'F0'X thru 'FF'x, which
VMACTMS5 are now decoded as 3592 or Titanium devices.
Jun 28, 2010
Thanks to Scott Barry, SBBWorks, USA.
Change 28.147 Another kewl tool. Will search data libraries for all
VMXGSRCH variables that match a specific character string.
Jul 4, 2010 You can:
-PRINT X OBS of every dataset where any variable has
a match
-PRINT X OBS of every dataset where any variable has
a match and copy all of the OBS to some other DD
-or just get a count of the number of variables and
datasets and obs that have a match.
Example 1: PRINT ALL OBS IN ALL DATASETS WHERE
the value of any variable is CHUCK.
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=PRINT,VALUE=CHUCK);
Example 2: PRINT/copy ALL OBS IN ALL DATASETS WHERE
the value of any variable is CHUCK.
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=PRINT,VALUE=CHUCK,
COPYTO=WORK);
Example 3: PRINT/copy ALL OBS IN ALL DATASETS WHERE
the value of any variable is CHUCK, but suppress
the NOTES on the log (and there are LOTS of them).
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=PRINT,VALUE=CHUCK,
COPYTO=WORK,LOG=NO);
Example 4: COUNT just tell me how many variables
in how many datasets and obs have a match.
%VMXGSRCH(LIBNAME=_ALL_,RESULTS=COUNT,VALUE=CHUCK,
LOG=NO);
Thanks to Chuck Hopf, Independent Consultant, USA.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.146 -Major enhancement to DB2PM-like reporting in ANALDB2R
ANALDB2R which has been upgraded to support DB2 V9 data, and is
ASUMDBAA internally completely revised to make maintenance simple
EXDB2ACR in the future.
FIXDB2A -And, a MAJOR change in PDB.DB2ACCT Buffer Pool data:
TRNDDBAA Four sets of DB2 Buffer Pool variables QBnCxxx in DB2ACCT
VGETOBS DB2ACCTP and DB2STATS are redefined and contents changed.
VMACDB2 QB1Cxxx variables contain the 4K Buffer Size counters,
VMACDB2H QB2Cxxx variables contain the 8K Buffer Size counters,
VMXGDBAA QB3Cxxx variables contain the 16K Buffer Size counters
VMXGDBSS and QB4Cxxx variables now contain 32K Buffer counters.
Jul 4, 2010 Originally, the four sets of counters were for BP0, BP1,
Aug 14, 2010 all 4K, and all 32K, but then 8K and 16K counters were
added into the QB4Cxxx variables, making a real mess.
Individual Buffer Pool Statistics for EACH Buffer Pool
are available in the DB2ACCTB and DB2STATB datasets.
-New DB2ACCTR dataset is created with an observation for
each QLAC segment (for each Remote Location) in the
Accounting Records. The QLACxxxx variables in DB2ACCT
were previously from the first QLAC segment, but with
this change, those variables will be from the last one.
With hindsight, had I known there could be multiple QLACs
in an accounting record, I would have created ONLY this
DB2ACCTR dataset and would have not kept any QLACxxxx
variables in DB2ACCT. If there was only one Remote QLAC
segment, then there is no change in DB2ACCT.
*-All summarization of DB2ACCTx datasets now performed by
new VMXGDBAA internal macro, called by ANALDB2R and
ASUMDBxx and TRNDDBxx, replacing ASUMDB2A and ASUMDB2B.
*-All summarization of DB2STATx datasets now performed by
new VMXGDBSS internal macro, called by ANALDB2R and
ASUMDBSS and TRNDDBSS.
*-If you use the new ANALDB2R against old PDBs that do not
contain ASUMDBAA or ASUMDBSS datasets, the FIXDB2A can
be used to report from old ASUMDB2A/TRNDDB2A datasets, as
close as possible to the new architecture, but many new
report fields will be missing.
-Correction to PDB.DB2STATS interval logic.
-Number of SORTBY= variables for PMACC02 increased to 12.
-Reports now as close to current as V7 DB2PM documents.
-Future maintenance greatly simplified.
-In prior releases if you asked for both PMACC01 and
PMACC02 the input data was summarized twice. Now only
one summarization is needed.
-PMACC01/PMACC02 will look for the ASUMDBAA or ASUMDBSS
datasets and use them instead of the detail DB2ACCTx or
DB2STATS dataset if they exist.
-The original version of the accounting long report was
written to output a full line at a time with a _NULL_
data step. But, DB2PM was written in sections and IBM
could insert lines in different sections with each new
release making maintenance a real nightmare. Inserting a
line in one section could result in touching hundreds of
lines of the code. PMACC02 is completely rewritten using
the same structure - in sections - and outputs a page at
a time rather than a line, which should make future
enhancements much simpler. Code comments indicate what
section is being invoked.
-And PMACC01 was rewritten, although it remains a line
mode coding and report. All four Accounting reports
PMACC01/PMACC02/PMACC03/PMACC04 use the same inputs, and
new VMXGDBAA summarizes all accounting data with datasets
held in work to avoid an unneeded, now, resummarization.
-Numerous glitches were found in the logic to create the
PDB.DB2STATS dataset (from DB2STAT0/1/4/T102S225) that
have been corrected.
- GMTOFFDB calculation occasionally returned -14399.99
instead of -14400 due to the different resolutions of
QWHSSTCK (microseconds) and SMFTIME (10 milliseconds)
and truncation in the floating point representation.
GMTOFFDB algorithm enhanced to force exact hour.
This error caused the Local Time QWHSSTCK in DB2STAT0
to be later than the Local Time QWHSSTCK in DB2STAT1,
which caused me to believe that was an IBM error,
until I was corrected by DB2 Support that the subtype 0
is ALWAYS written first in each interval (when QWSDRINV
is '10'x, timer caused record to be written).
- Logic in VMACDB2H to force QWHSSTCK to be the same for
each interval as SMF records were read was invalid when
multiple subsystems records were simultaneously written
with all the subtype 0's in a group, then their 1's.
Logic was removed, so the PDB.DB2STAT0/1/4 QWHSSTCK are
now the actual value in those datasets. In PDB.DB2STATS
the value from DB2STAT0 is propagated, and DB2START is
created with the "start time" of each stat interval.
-NETSNAME construction was revised to test for FIRST8 to
also test LOCPERIO EQ 0 to populate NETSNAME correctly
when there was no period in the QWHCTOKN.
-VMACDB2 corrected: DB2 V9.1 data with more than one QLAC
segment caused "BAD TMON SUBTYPE 101 RECORD" message but
the record was IBMs and the error was mine. Length when
there length in header was zero was not handled correctly
for the second and subsequent QLAC sections.
Change 28.145 Cosmetic. Enabling SAS Option MSGLEVEL=I printed four
VMAC7072 INFO: messages that are now eliminated just to avoid
VMXG70PR confusion, as, (fortunately) there was no actual problem.
Jun 28, 2010 I have also added MSGLEVEL=I to the QASAS job.
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 28.144 The VMXGPRNT utility that prints a single dataset with
VMXGPRNT variable name and variable label as headers is enhanced
Jul 4, 2010 to allow you to select which variables are printed.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.143 Support for z196 processor. This Change is REQUIRED FOR
VMAC7072 more than 64 engines, and the support was in MXG 28.04.
Jul 4, 2010 See Change 28.175 for full documentation, and more.
Change 28.142 Variable
VMAC7072 SMF70NCA='PCT WHEN*CAPPING*LIMITED*THIS ENGINE'
Jun 23, 2010 is now kept in TYPE70 dataset.
Thanks to Deb Soricelli, CIGNA, USA.
Change 28.141 Cosmetic. The Last Updated Date/Change of UTILEXCL will
UTILEXCL now be in a comment in the IMACEXCL member it creates.
Jun 23, 2010
Change 28.140 Major revision to SMF 113 support.
ASUM113 -TYPE113 now creates one obs per interval, with all four
VMAC113 sets of counters in one observation (instead of four obs,
Jun 23, 2010 each with one set of BASIC/PROGST/CRYPTO/EXTND counters).
Jun 28, 2010 -With all four counter sets in one obs, missing values in
variables added in Change 28.075 are eliminated.
-New variable SM113STM, Interval Start Time is created.
-New variable MIPSEXEC, Executed Million Instructions/sec
is created (but don't expect it to match published MIPS
"speed" values). (Thanks: Peter Enrico).
-The _STY113 dataset sort macro now tests //WORK and //PDB
and if TYPE70PR exists, adds variables CPUTYPE (2098),
SMF70CIN (Engine Type), CECSER, LPARWLMG (IRD FLAG),
SMF70CPA (SU_SEC), SMF70HDM (HiperDispatch Active?), and
SMF70CIX (Pool Number) to enhance PDB.TYPE113 dataset.
-New ASUM113 accomplishes the same enhancement as _STY113,
enhancing PDB.TYPE113 with those variables from TYPE70PR,
if you have old TYPE113 and TYPE70PR in the same PDB.
-The TYPE113 records are not synchronized with RMF/SMF so
the Polarity value of each engine is not yet added, nor
NRCPUS nor other non-static variables (i.e. can vary with
time), but IBM plans an APAR that will sync the 113's
with RMF/SMF, and MXG will add other TYPE70 variables and
new TYPE73 variable to TYPE 113 when that APAR is GA.
-The sort order of the PDB.TYPE113 dataset is now BY
SYSTEM READTIME JOB SM113STM.
-Occasional counter reset without a new interval flag have
been observed and are now protected (by deletion of that
interval) and detected (by printing an error message).
This error can be the result of two known causes:
1) Down level on the z10 micro-code.
The z10 needs to be at Driver 76 (GA2) and at least
at Bundle 20, as documented in John Burg's SHARE
paper. Bundle 20 also fixed some counter errors.
2) When IRD gets involved and varies off a CPU. Varying
off by IRD does NOT cut a final record; instead, when
it is finally varied back on you get an Intermediate
record for that interval, and over an hour elapsed
has been observed before that intermediate record was
written when the CP came back online.
(Thanks: John Burg).
-If you want create the enhanced PDB.TYPE113 dataset, and
only create that one output dataset in the //PDB library:
// EXEC MXGSASV9
//SMF DD DSN=YOUR.SMF,DISP=SHR
//PDB DD DSN=YOUR.TYPE113.PDB,DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(25,25))
//SYSIN DD *
%LET PTY70=WORK; %LET PTY70PR=WORK;
%LET PTY7002=WORK; %LET PTY70X2=WORK;
%LET PTY70Y2=WORK; %LET PTY72=WORK;
%LET PTY72DL=WORK; %LET PTY72GO=WORK;
%LET PTY7204=WORK; %LET PTY72MN=WORK;
%LET PTY72SC=WORK;
%UTILBLDP(BUILDPDB=NO,
USERADD=7072 113,
ZEROOBS=70.2 72,
OUTFILE=INSTREAM);
%INCLUDE INSTREAM; RUN;
PROC DATSETS DDNAME=WORK MT=DATA NOLIST;
DELETE TYPE7:;RUN;
Thanks to Richard Schwartz, State Street Bank, USA.
Change 28.139 These "recently" added SMF30xxx variables are now kept in
BUILD005 the PDB.STEPS dataset (but are not carried forward into
BUIL3005 the PDB.JOBS dataset, but might be in the future, based
Jun 23, 2010 on feedback from this change).
SMF30AIC='DASD CONNECT*ASID PLUS*DEPENDENT'
SMF30AID='DASD DISCONNECT*ASID PLUS*DEPENDENT'
SMF30AIS='DASD SSCH*ASID PLUS*DEPENDENT'
SMF30AIW='DASD PEND+CU*ASID PLUS*DEPENDENT'
SMF30ASP='ASID*DESIGNATED*STORAGE-CRITICAL?'
SMF30CCP='SRVCLASS*DESIGNATED*CPU-CRITICAL?'
SMF30CPR='ASID*CURRENTLY*CPU-PROTECTED?'
SMF30CSP='SRVCLASS*DESIGNATED*STOR-CRITICAL?'
SMF30EIC='DASD CONNECT*INDEPENDENT*ENCLAVES'
SMF30EID='DASD DISCONNECT*INDEPENDENT*ENCLAVES'
SMF30EIS='DASD SSCH*INDEPENDENT*ENCLAVES'
SMF30EIW='DASD PEND+CU*INDEPENDENT*ENCLAVES'
SMF30HSH='HWM*USABLE BYTES*IN 64-BIT*SHARED'
SMF30HSO='BYTES IN*64-BIT*SHARED*STORAGE'
SMF30HVA='HWM*AUX*SLOTS*BACK*64-BIT'
SMF30HVH='HWM*USABLE BYTES*IN 64-BIT*OBTAINED'
SMF30HVO='BYTES IN*64-BIT*STORAGE*OBTAINED'
SMF30HVR='HWM*REAL*FRAMES*BACK*64-BIT'
SMF30JPN='SUBCOLN*FROM*IWMCLSFY'
SMF30MRA='CPU*RATE*SU_SEC*FACTOR'
SMF30MRD='DEPENDENT*ENCLAVES*CPU*TIME'
SMF30MRI='INDEPENDENT*ENCLAVES*CPU*TIME'
SMF30MRS='SYSTEM*NAME*WHERE*ENCLAVES*RAN'
SMF30MSI='REMOTE*SYSTEM*DATA*INCOMPLETE?'
SMF30PFR='SRVCLASS*WAS MODIFIED*DURING*EXECUTION?'
SMF30SNF='ZIIP NORMALIZATION FACTOR'
SMF30SPR='ASID*CURRENTLY*STORAGE-PROTECTED?'
SMF30WMI='EXECUTING*IN*WLM*INITIATOR?'
SMF30ZNF='ZAAP NORMALIZATION FACTOR'
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 28.138 Support for SysView Subtype 3 record creates new dataset
EXSVTH03 SV03THRE='SYSVIEW THRESHOLD EXCEPTION 03'.
FORMATS
IMACSVIE
VMACSVIE
VMXGINIT
Jun 21, 2010
Thanks to Mike Paladino, Progressive Insurance, USA.
Change 28.137 Support for BMC IMF records written in SMF Format in new
TYPEIMFS member TYPEIMFS, which handles the SMF header, and sets
VMACCIMS OFFIMS, and in updates to VMACCIMS, as not all of its
Jun 20, 2010 INPUTs and LENGTH tests included OFFIMS. This iteration
will ONLY process IMF 'FA'x and 'F9'x SMF record IDs in
the infile SMF dataset. TYPEIMFS creates the same MXG
datasets in the same default LIBNAMEs as member TYPECIMS.
Thanks to Denise Willers, Infocrossing, USA.
Thanks to Ken Steiner, Infocrossing, USA.
Change 28.136 Variable R748CSER, the Controller Serial Number is now
VMAC74 kept in TYPE74A, TYPE748R and TYPE74X datasets.
Jun 24, 2010
Thanks to Pat Jones, DST, Inc, USA.
Change 28.135 Cosmetic. MXG Error messages when bad EXCP segments are
VMAC30 found now print the ABEND, CONDCODE, and ABNDRSNC values.
VMACEXC2 Precipitated by a series of error messages with bad EXCP
Jun 17, 2010 and MULC segments for jobs with SYSTEM 0D5 ABENDS.
Jun 24, 2010 The PUT of ABNDRSNC caused it to be defined as numeric
when ANALALL was executed, because the VMACEXC2 was used
first in SMF 4 record code, before ABNDRSNC was INPUT.
Using PUT ... ABNDRSNC= $8; resolved that weird error.
Thanks to Trevor Ede, HP, NEW ZEALAND.
Change 28.134 CICS Statistics Record INVALID STILEN=0 fortunately was
VMAC110 harmless, as it occurred after the STID=116 segment had
Jun 16, 2010 been output CICSJS. MXG had read only 156 bytes of the
164 bytes of STID=116, causing the error, now fixed.
Thanks to Tom Buie, Southern California Edison, USA.
Change 28.133 Support for WebSphere SMF 120 Subtype 20 Job Usage data.
EXT12020 Has only been coded, records skipped until test data
VMAC120 exists for validation.
Jun 16, 2010 See Change 28.258.
Change 28.132 Replaced by Change 28.146.
Change 28.131 IMS Log 56x record subtype 15x caused INVALID DATA or
VMACIMS INPUT STATEMENT EXCEEDED RECORD LENGTH errors. code was
VMACIMSA relocated. Only the 15x variables are now kept in IMS56F
Jun 14, 2010 dataset. STIMSID removed from all IMS56x datasets.
Thanks to Lindholm Orjan, Volvo, SWEDEN.
Change 28.130 Correction to calculation of index space; value in the
ASMRMFV RMFV018I message was slightly low, as 1111 was used in
Jun 10, 2010 the denominator instead the correct value of 1110.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 28.129 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE:
EXDB2ACR -All three DB2 records (100,101,102) can be compressed;
EXDB2ACW For z/OS execution, the EXITCICS member's INFILE exit
FORMATS now decompresses both DB2 and the original CICS records.
IMACDB2 For ASCII SAS, where there are no INFILE exits, or for
VMACDB2 z/OS without the exit installed, records are decompressed
VMACDB2H with internal SAS code, but that is EXTREMELY EXPENSIVE
VMACSMF on z/OS compared with using the INFILE exit, so MXG warns
VMXGINIT that you should install the exit to save CPU time.
VMXGWORL
Jun 16, 2010
Jun 19, 2010
Jun 21, 2010
-INVALID DATA FOR QWHSRELN is proof you have DB2 V10 SMF;
QWHSRELN is not a valid "PK" value; it now has 'A1'x, so
VMACDB2H was revised. The value is 10.1, not 10.0.
-And INPUT STATEMENT EXCEEDS RECORD error ABENDs may occur
because fields were inserted rather than added at the end
where MXG would have automatically skipped them.
-Subtype in SMF Header INCOMPATIBLY increased from one to
two bytes (because that's what it should have been all
along. However, only SMF 100 and 101 records populate
the subtype in the SMF Header. VMACSMF was updated to get
the DB2 version and then input the subtype correctly.
(MXG has always stored the IFCID value in SUBTYPE for the
DB2 102 trace records, since they don't have a subtype.)
-New DB2ACCGW dataset is created for each QWAR segment,
which can be used to correlate rollup records.
-Multiple SMF 100 Subtype 1 (DB2STAT1) IFCID=2 records are
now supported (Jun 21 2010). These records contain only
QBST or QBGL segments and are written when more than 25
buffer pools are used in an interval.
-Macro _SDB2STS was redesigned to correct DUPLICATE MERGE
VALUES errors that occur only if DB2 was restarted, by
removing QWHSACE QWHSMTN from the _BDB2STS "BY list", by
interleaving the four input datasets to create STATSGROUP
to use as merge variable (QWHSSTCK cannot be used as it
not exact in all four records for each interval), and by
conditionally merging T102S225 (DB2 V8) if it exists.
The _SDB2STY macro is now a null macro and no longer
used. The new sort order for the PDB.DB2STATS dataset is
now SYSTEM QWHSSSID QWHSSTCK. A cosmetic enhancement to
VMXGWORL, NOWARN=YES, is used to suppress the MXGNOTEs
when a tested dataset is known to not always exist (used
for T102S225 in this change).
-Many new variables added to DB2ACCTx/DB2STATx by V10:
DB2ACCT:
QLACRLNU
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTB:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTP:
QPACAWLH QPACANLH QPACRLNU
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2ACCTG:
QWACPCTT QWACPQRY QWACAWLH QWACARLH
DB2STAT0:
Q9STCDMD QDSTNQWC QDSTNARD QDSTMARD
D64POST A64POST A64WAIT M64DISNU M64DISPG SGETR64
SGETEXT6 SGETDEXT SFREER64 SFREEDEX DISCARDM
QWS1MCPU QWS2MCPU QWS3MCPU QWS4MCPU
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STAT1:
QISEKSPG QISEKSPA QISEKLRU QISEDLRU QISESQCB QISESQKB
QISESQCA QISESQKA
QISTRCCI QISTRCCD QISTRCCU QISTWMXA QISTWMXU QISTWCTO
QISTW4K QISTW32K
QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD
DB2STATB:
QBSTFLG
DB2GBPST:
QBSTFLG
-SMF 102 IFCIDs 172 and 196 were compatibly updated.
-SMF 102 IFCIDs 267, 268, 317, and 337 are now decoded.
New formats are created by the updated FORMATS member.
-These other IFCIDs in user-sent SMF files are presumably
the trace records that are normally written or needed.
They have been examined and none were change in V10:
4,5,55,87,105,140,141,173,196,199,250,254,258,261,262
-See the text of Change 28.146, which made changes to DB2
processing that were independent of the Beta, including
fixing the PDB.DB2STATS interval issue that was first
discussed in this change text, but was not V10 related.
Change 28.128 WARNING: APPARENT INVOCATION OF MACRO TRIM NOT RESOLVED
CONFIGV8 WARNING: APPARENT INVOCATION OF MACRO CMPRES NOT RESOLVED
CONFIGV9 Other: References to MACRO DATATYP in an EVAL statement
Jun 9, 2010 which may be followed by
ERROR: A character operand was found in %EVAL function
or %IF where a numeric operand is required ....
There are several "opportunities" for this error:
-These options must be in effect to resolve %TRIM:
OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS);
They are normally set in MXG CONFIGVn, but we have seen
instances in which (typically very old) user code has
changed those options, causing the error.
-The //SASAUTOS DD must point to the "AUTOCALL" dataset
(SAS-provided PDS) that contains the TRIM member.
-Ancient MXGSASxx JCL procs defined &SASAUTOS which was
&NULLPDS, and also had //SASAUTOS DD &SASAUTOS
// DD DSN=....
but that was replaced years ago; look at MXGSAS92 for
SAS V9.2 or MXGSASV9 for SAS V9.1.3 for correct JCL.
-OPTIONS S2=0 must be specified; it is set in CONFIGV9,
but I just discovered that CONFIGV8 still had S2=72;
that was corrected to S2=0 by this change.
-Additionally, the incorrect LOCALE can cause failures
with entirely different error messages when %TRIM is
used, due to the NOT symbol's mis-translation with the
wrong LOCALE. See Change 28.194 documentation.
-To diagnose, use // EXEC MXGSASV9,OPTIONS='VERBOSE'
and OPTIONS SOURCE SOURCE2 MACROGEN MPRINT SYMBOLGEN;
as the first //SYSIN DD statement, and send the FULL
job log.
Change 28.127 Support for revised CA $AVERS SMF record (INCOMPATIBLE)
VMACSAVR increased field lengths, and added new data. Dataset
Jun 8, 2010 contains new variables JCTJOBID, TYPETASK, SAVRACCT.
Thanks to Clement Turner, DC Government, USA.
Thanks to Edouard A. Myers, DC Government, USA.
Thanks to Roger B. Legerwood, DC Government, USA.
Change 28.126 Support for Rocket Software MXI User SMF record creates
EXMXIST1 three datasets:
EXMXIST2
EXMXIST3 dddddd Dataset Description
IMACMXI
TYPEMXI MXIST1 MXIONE MXIST1: INITIALIZED
TYPSMXI MXIST2 MXITWO MXIST2: TERMINATED
VMACMXI MXIST3 MXITHREE MXIST3: COMMAND AUDITED
VMXGINIT
Jun 8, 2010
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 28.125 Enhancement to support building weekly and monthly PDBs
BLDNTPDB when your first-day-of-week is not the MXG "MON" default.
BLDSMPDB -VSETMNTH utility correctly determines which daily PDBs
MONTHASC are to be read in building week/month; the decision is
MONTHBL3 based on TODAY() and the "STARTDAY" of your week.
MONTHBLD
MONTHDSK -New macro variable STARTDAY sets the "first day of week"
VMXG2DTE default to MON (no change), and is now used internally in
VMXGDUR all MXG programs, so that you can externally change that
VMXGLBIN first day of week if you do not build your WEEKLY/MONTLY
VMXGSUM with MONDAY as the first day.
VSETMNTH
Jun 17, 2010 -However, the %BLDSMPDB can be used as your "MONTHBLD" or
Jun 28, 2010 WEEKBLD program, and its WEEKSTRT argument can specify
the different start day of week if desired:
Weekly job:
%BLDSMPDB(WEEKSTRT=SUN,RUNDAY=NO,RUNWEEK=YES,RUNMNTH=NO,
WEEKKEEP=list of datasets);
add WEEKTAPE=YES, if WEEK PDB is to be written to tape.
Monthly job:
%BLDSMPDB(WEEKSTRT=SUN,RUNDAY=NO,RUNweek=no,RUNMNTH=YES,
MNTHKEEP=list of datasets);
add MNTHTAPE=YES, if MONTH PDB is to be written to tape.
WEEKKEEP/MNTHKEEP are only necessary if you wish to
keep only specific datasets in the WEEK/MONTH PDB (the
default is _ALL_.) There is also WEEKDROP/MNTHDROP to
drop specific datasets (and it defaults to dropping any
SPIN* SPUN* datasets). BLDSMPDB will use the SORTEDBY
option in the dataset directory to construct a BY list
if present but can also parametrically be told to
ignore the SORTEDBY.
Thanks to Jim Agrippe, Cleveland Clinic, USA.
Thanks to Ron Wells, American General Finance, USA.
Change 28.124 The WTIRIOTM in PDB.ASUMUOW could be larger than IRESPTM.
VMXGUOW Change 17.324 corrected the problem (WTIRIOTM was the sum
VMXGUOWT of WTIRIOTM's from ALL of the CICSTRAN obs in the UOW),
VMXGUOTT but a subsequent update in Change 18.204 lost that fix.
Jun 4, 2010 It is now the MAXIMUM value from all of the CICSTRAN obs.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 28.123 Utility program to examine TYPE72GO dataset to assist in
UTILWORK creating or investigating workload definitions for the
Jun 7, 2010 RMFINTRV.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.122 Logic revised to use DATEJUL to parse the date, but if
ASUMHSM the FSRDATR field is not a valid Julian Date, it is left
Jun 7, 2010 as a missing value.
Thanks to Tobias Cafiero, DTCC, USA.
Change 28.121 -ANALRANK is enhanced to add an output dataset option. By
ANALRANK using this you can get the top 10 each day, by appending
VGETLABL daily data you can quickly get the top 10 for the month
VGETFMT by pushing the daily top 10 back thru ANALRANK. Using
Jun 4, 2010 VGETLABL, the labels in ANALRANK are enhanced so that the
label of RANKxx variable contains the original variable's
label plus the word rank. So the label for CPUTM would
become 'TOTAL*CPU TIME*CAPTURED*RANK'.
-VGETLABL - New utility to GET the LABEL of a variable.
-VGETFMT - New utility to GET the FORMAT of a variable.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.120 -Variable QBACPID, Buffer Pool ID, is removed from dataset
VMACDB2 DB2ACCTP where it never belonged; packages can use many
Jun 3, 2010 buffer pools. The other QBACxxxx variables exist, but are
only non-missing (i.e., populated) if DB2 Accounting
Class 10 is enabled.
-DB2ACCTB - QLACCNVR didn't belong in KEEP list.
-DB2ACCTG - QLACCNVR didn't belong in KEEP list.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.119 Support for Performance Sentry NTSMF Version 3.1.4.4.
EXNTGENE -Existing objects were modified:
EXNTIPA4 Dataset - Object Name
EXNTIPA6 IPSECDRI - IPsec Driver - fields removed
EXNTIPK4 VMGUESTA - VMWARE.Guest.Aggregate - fields added
EXNTIPK6 VMGUUCPU - VMWARE.Guest.CPU - field added
IMACNTSM VMGUUMEM - VMWARE.Guest.Memory - fields added
VMACNTSM VMHOSTAG - VMWARE.Host.Aggregate - fields added
VMXGINIT VMWHOCPU - VMWARE.Host.CPU fields added
JUN 7, 2010 VMWHOMEM - VMWARE.Host.Memory fields added
VMWHONET - VMWARE.Host.Net fields added
VMWHOSYS - VMWARE.Host.SYS fields added
-New objects supported:
dddddd Dataset Object Name
NTGENE GENERIKE GENERIC IKE AND AUTHIP
NTIPA4 IPAUTHV4 IPSEC AUTHIPV4
NTIPA6 IPAUTHV6 IPSEC AUTHIPV6
NTIPK4 IPSECIK4 IPSEC IKEV4
NTIPK6 IPSECIK6 IPSEC IKEV6
-These xxxxINST variables were increased to $64:
MLLOINST QLWGINST SAALINST VWHCINST VWHDINST
Change 28.118 Support for BMC Mainview Auto Operator data creates nine
EXMVAOAC datasets:
EXMVAOAL
EXMVAOEV dddddd Dataset Description
EXMVAOEX MVAOAC MVAOACTN MV AUTO OPERATOR ACTN
EXMVAORE MVAOAL MVAOALRT MV AUTO OPERATOR ALRT
EXMVAORU MVAOEV MVAOEVNT MV AUTO OPERATOR EVNT
EXMVAORA MVAOEX MVAOEXEC MV AUTO OPERATOR EXEC
EXMVAORS MVAORE MVAORES MV AUTO OPERATOR RES
EXMVAOTA MVAORU MVAORULE MV AUTO OPERATOR RULE
IMACMVAO MVAORA MVAORUAU MV AUTO OPERATOR RULESET AUTO
TYPEMVAO MVAORS MVAORUSE MV AUTO OPERATOR RULESET SET
TYPSMVAO MVAOTA MVAOTAPE MV AUTO OPERATOR TAPE
VMACMVAO Aug 5: TAKETOTL removed from KEEP=, second "HANDLED" was
VMXGINIT removed from LABEL, and all %VMXGDEL(DDDDDD= corrected.
May 31, 2010
Aug 5, 2010
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.117 Change 28.039 changed R7451RID to be the first byte due
VMAC74 to values observed in SMF 74 Subtype 5 records from IBM
Jun 1, 2010 sites, but those observed values are not consistent in
other records from other sites, which have the RID in the
second byte and a zero in the first byte so this change
sets R7451RID to the second byte of that 2-byte field, if
if the first byte is zero. Additionally, fields listed in
notes 2 and 3 of the SMF manual are set missing based on
the value in R7451FLG.
Thanks to Melanie Hitchings, BT, ENGLAND.
Change 28.116 Support for SMF 102 IFCID 263 now decodes the unique data
VMAC102 fields; previously, only Header variables were output
May 27, 2010
Jun 11, 2010
Thanks to Christa Neven, KBC Global Services, BELGIUM.
Change 28.115 ANAL42DS failed with Data Set _NULL_ Not Found, because
ANAL42DS an _NULL_ is needed after the DATA statement.
May 26, 2010
Thanks to Sam Bass, McLane Co., USA.
====== Changes thru 28.114 were in MXG 28.03 dated May 25, 2010========
Change 28.114 Additional diagnostics to show which service classes and
UTILRMFI which reporting classes have missing data using SMFINTRV
May 25, 2010 dataset.
Change 28.113 New analysis of each DB2 Buffer Pool in DB2ACCTB dataset
ANALDB2B including a buffer hit ratio calculation.
May 25, 2010
Thanks to Santosh Kandi, JC Penney, USA.
Change 28.112 UTILRMFI failed because macro variable VWDUPES has been
VMXGINIT truncated to WDUPES in the %GLOBAL statement in VMXGINIT.
May 25, 2010
Thanks to David Young, University of California Office of Pres, USA.
Change 28.111 ThruPut Manager field REGIONSZ and $JXDBSPR/WW/UU fields
VMACTPMX were reported as UNKNOWN due to typo's in text tests,
May 24, 2010 and $JXDBSUN is now created.
Thanks to Paul Volpi, UHC, USA.
Change 28.110 The last "response" bucket created by VMXGRESP utility
ASUMDB2 (number specified plus 1) was never right, because every
VMXGRESP count that was GT was already put in the last bucket.
May 22, 2010 -Enhancement to include bucket values in labels, and a new
UNITS parameter describes the units (seconds/jobs/mounts)
that are being measured.
-ASUMDB2 implements the new UNITS= parameter.
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 28.109 -WPS %MACRO Language Compiler Error in READDB2, the error
ANALINIT cites a problem with %INCLUDE, but the statement that is
EMAIL flagged is the percent sign in %STR(MACRO _Edddddd ....
READDB2 (The _Edddddd generates %%INCLUDE SOURCLIB(EXDDDDDD);.)
UTILCONT A guess, to replace %STR() with %QUOTE() in statements
VFMT102 with that syntax DID circumvent the WPS compiler error!
May 21, 2010 -This same error can occur with ANALDB2R if (PDB=SMF,...)
is used, since ANALDB2R calls READDB2 to "READ" DB2 SMF.
-But, since READDB2 generates MACRO _Edddddd references
only when one of the optional/rare dataset sub-tokens is
used to select the observations, for example /DB2ACCT in
%READDB2(IFCIDS=ACCOUNT,DB2ACCT=YES/IF QWHSSSID='XYZ';);
so it was safer to replace %%INCLUDE SOURCLIB(EXDDDDDD);
statements with OUTPUT _WDDDDDD; to both circumvent
the Compiler error, and because the EXDDDDDD should not
have been created in READDB2 in the first place.
-An unrelated error when the dataset sub-token was used is
also corrected.
-The WANTONLY subarguments were further validated.
-In validating this READDB2 change, additional exposures
were corrected:
-VFMT102: If T102S105 and T102S107 did not exist, logic
to build OBIDS/DBIDS dataset failed: the &VGETOBS NE 0
test was changed to VGETDSN=datasetname, as it is the
existence of, and not the number of observations in,
that is the needed conditional test.
But this caused investigation of other &VGETOBS NE 0:
-ANALINIT: VGETOBS test changed to VGETDSN.
-EMAIL: VGETOBS NE 0 changed to GE 0.
-UTILCONT: VGETOBS NE 0 change to GT 0
Change 28.108 Support for CleverView for TCP/IP TN3270 Performance Data
EXCTCPTN in new SUBTYPE=21 SMF User Record, creates new CTCPTN32
IMACCTCP dataset with the existing TYPECTCP/TYPSCTCP programs.
VMACCTCP
VMXGINIT
May 20, 2010
Thanks to John Howard, Florida Northwood Shared Center, USA.
Change 28.107 -RACF INPUT STATEMENT EXCEEDED with RACFEVNT=21 LDAPHOST
VMAC80A in TOKDANAM; MXG coded for only a 32-byte LDAP Host Name,
May 19, 2010 but length was 35. Now protected for any length.
-In records with LDAPHOST, new TOKDANAM BINDDN and BINDPW
were found and decoded into variables TOKBINDD TOKBINPW.
Yes, "PW" is a Password, but, no, it doesn't appear to be
an exposure, as the value is populated with asterisks.
-TOKDANAM='APPLNAM ' text is now decoded into TOKAPLNM.
-TOKDANAM='UTYPE', 'JPNUM', numerics in TOKUTYPE/TOKJPNUM.
Thanks to Phil Grasser, Norfolk Southern, USA.
Change 28.106 The offset SMF92MPF to the Path name length SMF92PPL was
VMAC92 incorrect, causing SMF92PPN, Path Name to be blank and
May 19, 2010 SMF92PPL contained a large and wrong value.
Thanks to David Young, University of California Office of Pres, USA.
Change 28.105 -Optional TRENDing enhancement lets you tell VMXGSUM how
VMXGSUM many KEEPWEEK=/KEEPMNTH=/KEEPYEAR=/KEEPDAYS='s you want
May 19, 2010 kept in TREND output, or KEEPAFTR=01JAN2010 can be used
to output only observations GE that DATE.
-The KEEPxxxx options are only valid when DATETIME= is
used, and the value of the DATETIME= variable is tested
for each observation if it is to be output.
-A KEEPxxxx argument forces an INCODE= to be created if
one was not present; all MXG TRNDxxxx members already
have an INCODE= argument, and INCODE normally VIEWs, so
this should have minimal impact.
-Messages are not written that obs were not output.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 28.104 Support for field inserted at start of NDM-CD record.
VMACNDM New MACRO _NDMADD defaults to 0, but you can use MACKEEP
May 17, 2010 to change _NDMADD to 8 to skip 8 bytes after SYSTEM (and
to set the SMF TYPE of your NDM-CD record in _NDMID):
%LET MACKEEP=
MACRO _NDMADD 8 %
MACRO _NDMID 0FAX %
;
%INCLUDE SOURCLIB(TYPSNDM/BUILDPDB);
Eight bytes can't just be added to OFFSMF in MACFILE for
NDM-CD SMF because VMACSMF RETAINs OFFSMF, so new OFFNDM
replaced OFFSMF in VMACSMF after the first INPUT.
Thanks to Fred Buerger, Visa, Inc, USA.
Change 28.103 Support for TOKDANAM='SHARED' token, output in TYPE80TK.
VMAC80A
May 12, 2010
Thanks to Jacky Kwoka, SNCF, FRANCE.
Change 28.102 Support for user-created ECPAUDIT optional CICS variable.
IMACAAAA
IMACICUK
UTILEXCL
VMAC110
May 12, 2010
Thanks to Matt Feeney, DoD, AUSTRALIA.
Change 28.101 -IMS56xx datasets were not output because the variable for
VMACIMS subtype test should have been TPCPSSTY, and not TPCPSBCD,
VMACIMSA and the subtype test is for only one byte.
May 11, 2010 -Subtype 56x SSTY 11x INPUT STATEMENT EXCEEDED exposed MXG
May 18, 2010 mis-alignment; the +(-16) before TPIMSID does not exist,
and the +36 segment after the "NID" is conditionally read
as it doesn't exist in SSTY=0FAx records.
-In validating the printed output, the SYNCTIME in TYPE59x
datasets was not converted to local time.
-Multiple separate code stubs to calculate IMSSTCK were
replaced with LINK IMSSTCK; statements.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Change 28.100 MXG 27.07 removed 13 duplicates in TYPE30_1 for an STC
BUILDPDB that were (correctly!) NOT removed by MXG 28.02. Variable
May 10, 2010 ASID has been added to TYPE30_1, and 'pseudo' duplicates
had different ASIDs and thus were not duplicates.
Oct 2010: See MXG Newsletter 57, DUPLICATE JESNR.
Thanks to Paul Volpi, UHC, USA.
Change 28.099 Variable CPULHKTM, CPU Time When Promoted due to Lock
VMAC7072 HOLD, is now INPUT and kept in TYPE72GO; it was added by
May 10, 2010 z/OS 1.11 as IBM field R723LPDP.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 28.098 The %VMXGSET macro is enhanced with DSETOPT= argument so
VMXGSET SAS Data Set Options (DROP/KEEP/RENAME/etc) can be added
May 4, 2010 to each data set that will be "SET". This example syntax
%VMXGSET(DATASET=JOBS,DSETOPT=KEEP=JOB READTIME JESNR CPUTM);
will keep only those four variables when xxx.JOBS dataset
is read. Surprisingly, using a KEEP= on a SET statement
has minimal impact on CPU time, saving 7 out of 86 secs.
But using DSETOPT to RENAME variables could be useful.
Thanks to George Pandzik, USAA, USA.
Thanks to Brian A. Harvey, HCL America, USA.
Change 28.097 Type 74 subtype 8 R748LERT,R748LEWT,R748LPST variables
VMAC74 are correct in MXG; they are documented as accumulated
May 4, 2010 values in the SMF manual, but actual data values are not.
Variable R748LAID, the Interface ID is added at the end
of the _BTY748 BY list to ensure NODUP works when sorted.
To verify non-accumulation, it was necessary to insert
R748LAID before STARTIME, to group the observations to
see if the values were always-increasing, and that is
where it really belongs in the BY list, but inserting a
variable in an existing BY list is LETHAL for someone,
somewhere, who's already (accidentally?) combining days
and weeks PDBs, so it is added at the end for NODUP, as
that doesn't create a not-sorted exposure.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.096 When the LIB is in sequential or xport format, that type
VGETOBS was identified, but only now is the dataset name printed.
Apr 30, 2010
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.095 Elegant logic using the FINDW() function to parse the
VMACAIX AIX record's changed format for the HOSTNAME field
May 21, 2010 UPCRECRD=UPCASE(RECORD);
LOCHOST=FINDW(UPCRECRD,'HOSTNAME:',' ','E') +1 ;
HOSTNAME=SCAN(RECORD,LOCHOST,' ');
HOSTNAME=TRANSLATE(HOSTNAME,' ','"');
cannot be used with SAS 9.1.3 nor with WPS 2.4.0.1,
because the FINDW() function only exists in SAS V9.2.
The old SCAN() function was used with less elegance.
Change 28.094 XAMSYS variables CALAVGM1 CALTOTM1 CALAVGM2 CALTOTM2
VMACXAM record units are 16 microseconds, so they are now INPUT
Apr 29, 2010 by &RB4.6 and multiplied by 16, so they are seconds and
fractions of a second, and are FORMATed with TIME16.6, an
MXG convention so you know these are duration variables,
and so full resolution is printed, so 416 microseconds is
printed as 0:00:00.000416.
Variable SRMTSLIC is in TOD duration record units, so it
is now INPUT by &PIB.8.6 and divided by 4096 into seconds
and fractions and also FORMATed with TIME16.6.
Variable SRBABSDL is a percentage, but scaled by 65536,
so it is now divided by 65535.
Thanks to Dave Sadler, United Health Group, USA.
Thanks to Rob van der Heij, Velocity Software, THE NETHERLANDS.
Change 28.093 Circumvention for SMF 42 Subtype 15 INVALID OFFSETS. The
VMAC42 record has OFF42S3=216 and OFF42S4=4056, but the data are
Apr 28, 2010 at 108 and 3948. MXG forces S3=108 and calculates S4.
Thanks to Michael Friske, FMR, USA.
Change 28.092 This ancient program to create a z/OS PDS from the MXG
IEBUPDTE IEBUPDTE-format source file had defined values for the
Apr 28, 2010 input and output, which required you to EDIT and SAVE
and then %INCLUDE SOURCLIB(IEBUDTE); to execute, but
those three macro variables are no longer set to any
value, so you can set them to your choice and then run.
Thanks to Bernhard Babblok, Allianz ASIC SE, GERMANY.
Change 28.091 -MXG 28.02. IMS record 55x subtype 01x from IMS 9.1 caused
VMACIMS INPUT STATEMENT EXCEEDED RECORD LENGTH; support for 55x
Apr 26, 2010 was added, but only tested with IMS 10 and 11. The 55x
record is for External Subsystems. The 01x record isn't
described in the DSECT, so it is now deleted.
-The 35X record with ENQFLAG=2F and FLAG2=00X or 08X is
now output in IMS35P dataset.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Change 28.090 Variable FIXEDSTO was incorrectly input as &RB.4. It is
VMACXAM a &PIB.4. INFORMAT now. Variable MONEVNTS is an address
Apr 25, 2010 so it is now formatted HEX8.
Thanks to Paul Volpi, UHC, USA.
Change 28.089 The PDB.SMFRECNT dataset and its report only counted SMF
BUIL3001 records; this enhancement provides both the record count
BUILD001 and the byte count for each SMF record and Subtype for
BUILDPD3 each SYSTEM, in both PDB.SMFRECNT and the report.
BUILDPDB If you want to revert to the count-only report, use
TYPSID %LET MACKEEP= MACRO _RPDBID _RPDBIDO % ;
VMACID Variable SMFBYTES was added to the TYPEID dataset and is
Apr 24, 2010 the bytes variable in PDB.SMFRECNT summary dataset.
Thanks to Diane Eppestine, IBM Global Services, USA.
Change 28.088 MXG 28.01-28.02, z/OS 1.9 and 1.10, INPUT EXCEEDED ERROR.
VMACRMFV Change 28.048 inserted temp skip of +192 for z/OS 1.11 to
Apr 25, 2010 align, but should have been skipped only if CPUHOLEN=672;
earlier z/OS have CPUHOLEN=480. Now, SKIP=CPUHOLEN-480.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 28.087 -Cosmetic. Spurious message for STID=110 "SKIPPED FIELDS"
VMAC110 because SKIP=SKIP-580 should have been SKIP=SKIP-612. No
Apr 23, 2010 fields were skipped and dataset CICRLR was just fine.
-Use of internal SAS decompression code on z/OS instead of
the ASM code in the INFILE exit in member EXITCICS caused
CPU time to increase from .5 to 6 HOURS with 45 GB of SMF
records, so the "MXGNOTE" that the SAS code was used is
now elevated to a repeated "ERROR:" message under z/OS.
Under ASCII, a single note that compressed data was found
is printed. Change 27.260 documented a smaller increase!
Thanks to Joachim Sarkoschits, DATAEV eG, GERMANY.
Change 28.086 Support for Windows Performance Monitor PERFMON csv/tab
ADOCWPMO log file creates 123 new datasets, each named WPMOddd, to
EXWPMddd correspond with the DDDDDD=WPMddd token for each dataset.
IMACWPMO The DataSet Label is the Object Name, and member IMACWPMO
MAKEWPMO has the full list of DDDDDD, DATASET, and Object Name and
TYPEWPMO will be updated as new Objects are supported.
TYPSWPMO The PERFMON data files can be concatenated, and can have
VMACWPMO different sets of fields. The ADOCWPMO member documents
VMXGINIT how Glenn has set up his PERFMON data management.
May 22, 2010
With all possible objects were enabled, with all threads
and instances captured, on a Small Business Server, the
PERFMON descriptor record was 861,481 bytes long, way too
long to be read on z/OS with its 32760 maximum LRECL, so
MXG PERFMON support may require execution on ASCII, where
SAS V9.1.3 allows LRECL=1024000, and SAS V9.2, LRECL=4GB.
This design is also another significant MXG enhancement:
The new MXG code that you execute to process PERFMON data
was generated by MXG's MAKEWPMO program, which reads the
header record field descriptions, parses/translates them
to create open-systems-friendly, 32-byte variable names,
with underscore-connectors, builds variable labels from
those variable names, changing underscores to asterisks,
uses the Object Name for the Dataset Label, and writes
out the dozen text files that are then manually cut/paste
into VMACWPMO or the other MXG code members.
While still a two-step process, this automation makes it
easy for MXG to support new objects. MAKExxxx programs
have been used for some time to create chunks of MXG code
for product XXXX, but only for the static statements that
defined or referenced the XXXX product suffix, the DDDDDD
dataset suffix token, or that contained the DATASET name.
Programmatically creating variable names, labels, and the
INPUT code is a BIG step forward in minimizing MY effort
to support future "open systems" data or sources that
have similar data structures. Since these data don't
have a construct of a short field name, but only the long
description, using the descriptions as variable name does
make sense for this audience, and REALLY saves me TIME!!
Each "item" in the header description has this format:
"\\SERVER\OBJECT(INSTANCE)\METRIC"
and there can be tens of thousands of items. SERVER is
variable SERVER, the server name, OBJECT maps to the MXG
dataset, and the Object Name (PROCESS) is the Label of
the MXG Dataset Name (WPMOPRO), INSTANCE is the instance
(e.g., process EXPLORER.EXE), and each separate METRIC
item (e.g. HANDLE_COUNT) is a variable in the WPMOOBJ
dataset.
While ASCII's max LRECL is 4GB, records cannot be stored
in a character variable, with SAS's 32K limit, so the
record is brute-force read, byte-by-byte, and parsed for
the delimiters to create each "item".
Microsoft claims to create comma-delimited data, but a
single comma cannot be safely used to parse because
the "items" can contain embedded commas!
And, while each item is bounded by double quotes, the
double quote also cannot be used as a delimiter, as
"items" can also contain embedded double quotes!
So the MXG default "comma-separated-value" delimiter is
the three-character-string "," set in VMXGINIT with
%LET DLMWPMO='","';
If you have "tab-delimited" PERFMON files, then you
need to use %LET DLMWPMO='09'x; before your %INCLUDE.
Once an "item" is parsed, normal SAS character functions
are used to create the SERVER, OBJECT, INSTANCE and the
METRIC values, and output the WINPERFMON dataset that is
subsequently read to output all of the WPMOddd datasets.
If there are obs in OBJUNKNOWN or METUNKNOWN datasets,
please send the PERFMON file to support@mxg.com,
so MXG can be updated to support the new data.
Some characters in the descriptions have to be converted
because blanks, back-slashes, dashes, parens, periods,
pound-signs, etc., can't be used in SAS variable names;
underscores are used in the variable name to connect the
pieces.
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.085 Obscure. VMXGSUM is protected if you had parenthesis in
VMXGSUM the OUTDATA= argument (for a LABEL= or SORTEDBY=). If a
Apr 20, 2010 last data step wasn't needed, parens caused an even more
obscure ABEND. While now protected, using the DSNLABEL=
or SORTEDBY= argument in the VMXGSUM invocation is safer.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.084 BMC IMF product's INPUTCLS and LASTCLAS variables are now
VMACCIMS restored to one-byte length with $HEX2. format, and new
Apr 20, 2010 variables INPUTCL2 and LASTCLA2 are two-bytes with $HEX4.
While IMS 9.1 and later define Input Class as two bytes,
it appears that no one is using that length, and MXG's
changes (27.230,26.058) that expanded the length of those
original INPUTCLS/LASTCLAS variables caused existing
reports to be incorrect.
Thanks to Jim Dammeyer, State Farm Mutual Insurance, USA.
Thanks to Mike Stogsdill, State Farm Mutual Insurance, USA.
Change 28.083 MXG 28.02-03. READB2/ANALDB2R didn't honor %LET MACDB2H
ANALDB2R nor %LET MACKEEP tailoring: Change 28.055 added %CLEARDB2
READDB2 (to reset old-style macros for multiple executions, used
Apr 17, 2010 previously only in the MXG QA), but CLEARDB2 also clears
Apr 21, 2010 both MACDB2H and MACKEEP. The %CLEARDB2; statement was
Apr 22, 2010 removed from both members by this change.
Apr 24, 2010 Circumvention with 28.02: Create a member named CLEARDB2
Apr 25, 2010 in your "USERID.SOURCLIB" with a blank line.
Apr 26, 2010 No one has asked to execute READDB2/ANALDB2R twice,
Jun 17, 2010 but it can still be done, by invoking %CLEARDB2;
externally, between the multiple executions:
%READDB2 ( WHATEVER );
%LET MYKEEP=%BQUOTE(&MACKEEP);
%LET MYDB2H=%BQUOTE(&MACDB2H);
%CLEARDB2;
%LET MACKEEP=%BQUOTE(&MYKEEP);
%LET MACDB2H=%BQUOTE(&MACDB2H);
%READDB2 (WHATEVER DIFF);
-MXG 28.01-28.02 only. Short Trace report failed with
BY VARIABLES NOT SORTED ON DATASET WORK.REPORT; example
in Change 28.004 that revised that report DOES NOT FAIL,
but removing the CONNTYPE=4 selection exposes the missing
BY statement that was added by this change.
-Audit report corrections, all prior versions:
-The BIND code was inside the loop for DML (should not
have been).
-PMAUD02/PMAUD03 reports did not agree with doc; they
were only produced when you used the AUDIT= subparm,
but now, as documented, ALL possible Audit classes
will be reported with the default AUDIT=, value.
-SQL Text printed for 141 and 145x Audit records.
-Divide by ZERO when GETS=0 is now protected.
-Cosmetic: SUDIT now correctly spelled AUDIT.
MXGWARN that PDB.ASUMDB2x NOT FOUND have been removed.
ANALDB2R first looks for the ASUMDB2x dataset for a
report request, as that saves I/O and CPU time, but
warning that it wasn't found was confusing, especially
when you knew nothing about that internal design.
-Jun 17: MACDB2H was not honored until this date.
Thanks to Jim Kovarik, AEGON USA, USA.
Thanks to Stephen Root, Harry and David, USA.
Change 28.082 MXG Formats $MGDDDDD and $MGDDDSN map the "dddddd" token
FORMATS to each "dataset" and vice versa, but the UDDDDDD program
UDDDDDD missed some of the "dddddd" values, in particular, CICTRN
Apr 18, 2010 and DB2ACC, and not all datasets were identified, as that
old logic read selected source members for the _Wdddddd,
which doesn't exist for all datasets. Now, UDDDDDD reads
DOCVER to capture ALL dataset names, and labels for all
datasets now contain "DDDDDD:" in their dataset label.
UDDDDDD is also added to QASAS so those formats will be
updated with each new version; DOCVER is already heavily
validated in post-QA reports. These members were updated
to revise/add unique DDDDDD: to their dataset labels:
ANALVM ASUM94 ASUMCIMS ASUMDB2P ASUMDB2S ASUMMWUX
ASUMSTC ASUMTALO BUIL3001 BUILD001 BUILDPD3 BUILDPDB
DIFFROSC MNTHDB2S TRNDDB2A TRNDDB2B TRNDDB2G TRNDDB2P
TRNDDB2S TRNDDB2X TRNDSTC TYPEPDL TYPEVLFC TYPEZARA
VMAC0 VMAC110 VMAC21 VMAC30 VMAC84 VMACCIMS
VMACCRAy VMACMWUX VMACNMON VMACVMON VMACVMXA VMXGCICI
VMXGDBSS VMXGHSM VMXGRMFI
Thanks to Francine Gheyle, Dexia Bank, BELGIUM.
====== Changes thru 28.081 were in MXG 28.02 dated Apr 14, 2010========
Change 28.081B PRO/SMF dataset PRORECOV was misaligned after the INPUT
VMXGINIT of variable GWMSGED.
Apr 14, 2010
Change 28.081A PRO/SMF dataset PRORECOV was misaligned after the INPUT
VMACPROS of variable GWMSGED.
Apr 14, 2010
Thanks to Perry Lim, Union Bank, USA.
Change 28.081 OPTIONS VARLENCHK=NOWARN is reinstated in VMXGINIT if the
VMXGINIT SAS Version is 9.2 TS2M0 or later to eliminate the new
Apr 12, 2010 WARNING: MULTIPLE LENGTHS WERE SPECIFIED FOR THE VARIABLE
that is discussed MANY times in several NEWSLTRS. While
MXG 26.03 eliminated the warning in internal code,
user code is now protected, and future changes in lengths
of IBM fields (e.g., CLIPADDR increased from 16 to 40 to
support IPV6) will not produce that WARNING, nor a Return
Condition Code of 4. (One cause of the warning is the
use of PROC MEANS to create an output dataset without the
option /INHERIT at the end of its OUTPUT statement.)
Thanks to John Kim, ATCO I-tek, CANADA.
Change 28.080 z/OS 1.11 adds new variable to TYPE70 dataset
VMAC7072 SMF70GAU='CAPACITY GROUP AVAILABLE MSU
Apr 12, 2010 which is documented as
-Long-term average of CPU service in millions of
service units which would be allowed by the limit of
the capacity group but is not used by its members.
-If the value is negative, the group is capped.
So, this variable is input with &IB.4. since in this rare
case, a negative value is not only possible, it is now
very useful as an indication that the Capacity Group is
Capped.
Thanks to Scott Barry, SBBWorks, USA.
Change 28.079A This change WAS included in MXG 28.02, but this text was
VMXGINIT not: the test for NOWORKINIT was removed in MXG 28.02.
Apr 14, 2010 Change 28.023 added that test and a USER ABEND 990 if
OPTION NOWORKINIT was enabled, but my cure was worse
than the disease. There IS a serious exposure in MXG
if NOWORKINIT is enabled, but I know now it is ONLY in
a second MXG step, and only after a first-step error,
and the real exposure is only MY time in diagnosing!.
Some SAS sites have now ABENDed (unnecessarily) because
that option is enabled in their SAS tailoring, and WPS
set NOWORKINIT as default (when WORK was temporary and
did not need to be INIT, and their INIT process was
inefficient, but their INIT is improved and WORKINIT is
to be the default in their next GA), and now that I
know that NOWORKINIT, of itself, does not create a
problem for MXG code, my test and USER ABEND 990 were
removed in MXG 28.02.
Change 28.079 MXG 27.11-28.01, ONLY with the MXGTMNT Tape Monitor data:
VMACTMNT SAS has had a limit on the length of an observation of
Apr 12, 2010 32760 bytes, which prevents the Host Sort from being used
if exceeded, with this SAS Warning printed on the log:
The total length of all variables must be less than or
equal to 32760 bytes. The host sort cannot be used.
The internal SAS sort will be used; this may impact
performance. Adjacent to TYPESYSL dataset references.
(An increase in CPU time of about 37% was observed.)
Change 27.336 increased the length of variable SYSLTEXT,
the SYSLOG Message Text, from 1024 to 32384, but that was
needed/intended ONLY for the TYPESYSL dataset (which can
OPTIONALLY capture any SYSLOG message); that length is
for the largest possible multi-line SYSLOG message. BUT:
variable SYSLTEXT was also accidentally increased in the
TYPESYMT dataset, used ONLY for Tape-Mount-Event-Related
SYSLOG messages, needing a SYSLTEXT length of only $256.
Even worse, new variable SYSLENCR, to identify Encrypted
Tapes, was created as SYSLENCR=SUBSTR(SYSLTEXT,x,16), but
because I failed to put the new variable in a LENGTH $16
statement, it got the 32384 byte length of SYSLTEXT. So
with SYSLTEXT and SYSLENCR, TYPESYMT had an observation
length of 65183, causing the preceding WARNING message.
This change restores the length of SYSLTEXT to $256, and
the TYPESYSL dataset's variable is now named SYSLLONG.
Note that the SPINSYSL dataset created with 27.11-28.01
by the %INCLUDE SOURCLIB(ASUMTAPE); that should always be
used to create the PDB.ASUMTAPE Tape Mount Event dataset
also exceeded 32760, with observation length 65198, but
it is not sorted, and its observation length is corrected
when this change is implemented.
Thanks to Siegfried Trantes, Gothaer-Systems, GERMANY.
Thanks to Richard Sabine, Gothaer-Systems, GERMANY.
Thanks to Willi Weinberger, Gothaer-Systems, GERMANY.
Change 28.078 VMXGGETM reports SMF record counts and bytes by SUBTYPE
VMXGGETM and ID, but DB2 100 and 101 records subtypes were changed
VMACSMF to their IFCID; now their actual SMF SUBTYPE is printed.
Apr 11, 2010 (For the DB2 102 record, which does NOT have a SUBTYPE in
the SMF Header, the IFCID is still used for SUBTYPE.)
-The setting of SUBTYPE logic was removed to VMACSMF.
Thanks to Tom White, Dell, USA.
Change 28.077 Support for JES 3 JMF TYPE84 records; previously only the
VMAC84 header was supported for subtype 5; this update supports
Apr 10, 2010 all ten subtypes.
Change 28.076 Variable CECSER is now added to PDB.RMFINTRV, but this
VMXGRMFI change was NOT moved into MXG 28.02.
Apr 18, 2010
Change 28.075 IBM's John Burg presentation at 2010 Seattle SHARE in
VMAC113 session 2113 provided insight into the new TYPE113 HIS
Apr 9, 2010 monitor data, and these new variables are created:
CPI='CYCLES*PER*INSTRUCTION'
PRBSTATE='PERCENT*PROBLEM*STATE'
L1MP='LEVEL*1*MISS*PERCENT'
L15P='PERCENT*SOURCED*FROM*L1.5*CACHE'
L2LP='PERCENT*SOURCED*FROM*L2*SAME BOOK'
L2RP='PERCENT*SOURCED*FROM*L2*DIFFEERNT*BOOK'
MEMP='PERCENT*SOURCED*FROM*MEMORY'
LPARCPU='APPL*PERCENT*CAPTURED AND*UNCAPTURED'
-John's presentation is also available at Techdocs:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TC000041
-Using %INCLUDE SOURCLIB(TYPE113); _RPT113 ; RUN;
will replicate his example report.
-Variable SM1132CP, CPU Speed, was INPUT but not carried
into the TYPE113 dataset.
-A subsequent update will look for PDB.TYPE70 dataset, and
will use it to identify the type of each CPU in TYPE113.
Thanks to John Burg, IBM, USA.
Thanks to Graham Harris, Royal Bank of Scotland, SCOTLAND.
Change 28.074 Support for CA-Dispatch Audit User SMF record creates:
EXCADISP dddddd dataset description
IMACCADS CADISP CADISPCH CA Dispatch User SMF Record.
TYPECADS Note this is NOT the modified type 6 that can be created
TYPSCADS with the IMACCADI optional member enabled.
VMACCADS
VMXGINIT
Apr 14, 2010
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.073 In new DB2 V9.1 data records, QWHSISEQ in SMF 100 Subtype
VMACDB2 0 and 1 records no longer matches QWHSISEQ in Subtype 4
Apr 8, 2010 records, causing all of the QW0225xx variables to have a
missing value in PDB.DB2STATS when DB2STAT4 is merged.
The use of QWHSISEQ was previously "safe", but must have
been a fortunate accident, since IBM documentation for
ISEQ implies it is a sequence number for the IFCID, and
not, as I had assumed, the interval's sequence number.
This change creates TEMPISEQ dataset with QWHSISEQ taken
from the DB2STAT0/DB2STAT1/DB2STATB merge, renames the
ENDTIME to QWHSSTCK, so that TEMPISEQ is then interleaved
with DB2STAT4 to store that "interval" QWHSISEQ, which
is then used in the original merge using _BDB2STS.
(Since the problem has only occurred with DB2STAT4 and
not with the T102S225 that was created in DB2 V8., that
logic was not revised).
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 28.072 Dataset TYPE42X4 (Above the Bar LRU Statistics) variables
VMAC42 SMFA2JQG-SMFA2JQN (Buffer Size Goal and Buffer Sizes) are
Apr 8, 2010 now correctly INPUT as &PIB.8., instead of &PIB.4. This
caused variables SMFJQO01-SMFJQO16, SMFA2JSA-SMFA2JSP to
also be mis-aligned and wrong, and the IF test for 864 is
corrected to test for GE 896 due to the misalignment.
-In addition, new variables SMF42JP6 and SMFA2JP6 (Write
Requests) are INPUT and kept in datasets TYPE42X2 (Below)
and TYPE42X4 (Above) as they too had been overlooked.
-Note that MXG variable names SMFA2xxx correspond to IBM
field names of SMF2Axxx.
Thanks to Ambat Ravi Nair, CitiGroup, SINGAPORE.
Change 28.071 PDB.STEPS could contain duplicate observations, and the
BUILD005 resources in those duplicates were summed into PDB.JOBS,
BUIL3005 if two steps had the same TERMTIME (because the first was
ANAL30DD a FLUSHED step). Change 18.344 corrected this error in
Apr 7, 2010 TYPS30, by adding INITTIME to the _BTY30U4 BY list, but
that change was also needed in BUILD001/BUILD001, which
have their own BY list in the NODUP step.
All other programs that SORT the TYPE30_4 data were now
examined; ANAL30DD's BY list was updated, but it was the
only one that sorts all variables; these other programs
currently do NOT protect for duplicate SMF records
ANAL30 ANALDDCN ANALDSET ANALJOBE ANALMULT ANALVTS
TAPEVENT UTILRMFI
because they do not keep all of the variables that are
required for duplicate removal, and adding that logic
would be very expensive: unneeded variables and an extra
PROC SORT would be required and the report program would
have to be restructured. Since the TYPS30 program WILL
remove ANY duplicates, the solution would be to use it to
create the TYPE30xx datasets first, and then those report
programs will not need revisions.
Thanks to Michael Oujesky, Bank of America, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 28.070 SAS Version 9.2 TS2M2 may have changed DSNAMEs/MEMBERs in
MXGSAS92 their //CONFIG DD. As always, you MUST look at the SAS
Apr 2, 2010 JCL procedure example that was created by your SAS
Installer to know what DSNAME/MEMBERs were created; those
DDs must be the first in the //CONFIG DD, then the MXG
CONFIG member must be the last "real" DD, followed by the
// DD DSN=&CONFIG as the final DD in the //CONFIG concat.
These two variants are listed in the MXGSAS92 example.
//CONFIG DD DISP=SHR,DSN=&SASHLQ..V92DYJJJ.CNTL(BATCH)
// DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9)
// DD DISP=SHR,DSN=&CONFIG
//CONFIG DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(BATCH)
// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(COMMON)
// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(&XX.&YY.)
// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(SITE)
// DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9)
// DD DISP=SHR,DSN=&CONFIG
Thanks to Ernie Amador, UC Davis Health System, USA.
Change 28.069 Two instances of -60 were changed to -56 for the SMF 112,
EXIT112 but the exit to decompress SMF 112s does not work and can
Apr 1, 2010 not be used. IBM does not provide a utility program that
May 17, 2010 will decompress the SMF 112s (DFH$MOLS only reads 110s),
so I have no way to correct and validate the MXG Exit.
DO NOT USE EXIT112.
Change 28.068 Change 27.111 added support for multiple CA-1/TMS catalog
TYPETMS5 inputs, but inadvertently changed the length of VOLSER to
Apr 1, 2010 $20, whereas it should have been $6. There was no error
in the contents of variable VOLSER, but if you tried to
combine new and old datasets, you receive a SAS WARNING
of the dissimilar lengths. This change restores VOLSER
to the original $6 length.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 28.067 The final example invocation of %VMXGRMFI(....) failed
RMFINTRV because there was a comma prior to the close-paren. All
Apr 1, 2010 %MACRO invocations have commas separating arguments,
but there can not be a comma after the last argument.
Thanks to Carolyn E. Saul, West Virginia Office of Technology, USA.
Change 28.066 Support for IMS Version 11 (INCOMPATIBLE), support for
ASMIMSL6 55x/56x Statistics Log Records, validation of 45x log
TYPEIMS7 records, and TYPSIMS7 removes duplicate log records.
TYPSIMS7 -Insertion of 16-byte LINTUTKN field in 08x log record
VMACIMS in IMS 11 makes this change required to eliminate error
VMACIMSA that YYYY has invalid value, in VMACIMS and VMACIMSA.
VMXGINIT -ASMIMSL6 is updated to pass the 55x and 56x log records.
Apr 4, 2010 -45x Statistics records have been validated with data,
except for IMS4513 which had zero observations.
-55x and 56x records are now supported and validated; the
"56" names contain "55x" and "56x" records:
DDDDDD DATASET CREATED FROM SUB-SUBTYPE
IMS560 IMS5600 00x-08x,10x,12x-14x,37x-38x
IMS569 IMS5609 09x
IMS56B IMS5611 11x,16x
IMS56F IMS5615 15x
IMS56G IMS56FA FAx
-The 45x and 55/56x datasets are left in //WORK so you can
decide to copy them, or not.
-TYPSIMS7 now uses PROC SORT NODUP to remove duplicates,
and outputs ALL datasets to the //IMSTRAN DD name.
This required creation of variable IMSRECCH $CHAR8. to
contain the IMS Logical Sequence Number as character to
use in NODUP sorts. IMSRECNO was input with PIB8., but
it failed in NODUP sorts, because values were truncated
if the first byte was non-zero. IBM stores a value of
'F1'x in the 1st byte for the 1st merged file, a 'F2'x
for the 2nd merged file, etc., but when a numeric field
is INPUT with PIB8, if the field contains a non-zero
first byte, the result is truncated because SAS needs
one byte for exponent, leaving only 7 bytes for
mantissa, which caused duplicate values for IMSRECNO,
which caused the NODUP to fail to recognize true
duplicates. Now, the 8-byte Character variable
IMSRECCH is used in all BY-lists to successfully remove
duplicates and the numeric IMSRECNO is now input from
only the last seven bytes, with PIB7.
-35x record has undocumented bits in QLNQFLGS/ENQFLAG.
IMS 11 DSECT only document '10'x,'02'x,' 01'x bits,
but data contains '80'x,'40'x,'08'x,and '04'x bits on.
QLNQFLGS values '0C'x,'4C'x,'8C'x,'8E'x, and '9C'x bits.
-01x record now conditionally inputs Extended Segment,
eliminating missing value messages.
Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.
Thanks to Lars Fleischer, SMT Data A/S, DENMARK.
Change 28.065 Support for BMC CICS CMRDETL C660 for CICS/TS 4.1 adds
VMACMVCI these new variables COMPATIBLY:
Mar 30, 2010 T6E66XCT T6EATMSN T6EBFDGC T6EBFTC T6EECEVC T6EECFOC
T6EECSGE T6EEICTC T6EIPA T6EJSTWC T6EJSTWT T6EMLCTC
T6EMLCTT T6EMLTDL T6EMLXTC T6EMQASC T6EMQAST T6EOIPA
T6EPIPLN T6ET8PTC T6ET8PTT T6ETIATC T6ETITC T6ETTDLC
T6ETTDLT T6EURIMN T6EWPBNM T6EWSATC T6EWSCBC T6EWSCGC
T6EWSEPC T6EWSFCC T6EWSFTC T6EWSOPN T6EWSQBL T6EWSRBL
T6EWSSFC T6EWSVCN TESTC660 UDAT2
Change 28.064 A semicolon was missing at the end of the statement
JCLIMSL6 %LET MACKEEP= MACRO _IMSVERS 10 % ;
Mar 26, 2010 causing the job to stop after MXG initialization.
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND
Thanks to Brian Sanger, Zurich Insurance Company, SWITZERLAND
Change 28.063 ASUM70LP and ASUMCELP had IFLACTTM,PCTIFLBY missing if
VMXG70PR the IFL was Dedicated, LCPUDED='Y' because ORIGWAIT was
Mar 25, 2010 subtracted from LCPUPDTM even when ORIGWAIT was missing.
Now, MAX(ORIGWAIT,0) is subtracted.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.062 NetSPY percentage calculations use TOTRSPNO or NETSRPNO
VMACNSPY in the denominator, based on the '.1.....'B XDOMAIN value
Mar 25, 2010 for Host-Only or Not, respectively. New TARGRESP variable
is now set by that XDOMAIN value to make it clearer which
denominator was used for the TnRSPPC calculations.
Thanks to Charles Savikas, DFS State of Florida, USA.
Change 28.061 MXG changes the TMS variable BLKCNT to a missing value,
VMACTMS5 when it detects an invalid BLKCNT value. Previously, the
Mar 25, 2010 BLKCNT value was output as 4,294,967,xxx decimal, because
the value in the TMS record was 'FFFFFFFC'x, which MXG
INPUT with PIB4. INFORMAT, because Block Count must be a
positive value, and I feel leaving that large value means
it can't be easily overlooked as an error. For a field
that can be positive or negative, then the first bit is
a sign bit, and the above, when INPUT with IB instead PIB
is a decimal -4, still a clearly wrong negative value.
The TMS Report prints a +4 for BLKCNT for that value!
And, from TMS Support, they confirm that:
- There is no logic in TMS-Reporting, but if the
high-orderbit is on, they interpret the negative
value as a positive number in their print routine.
- The record seems to be wrong, they had some few
similar cases in the past
In fairness to TMS, I don't think these large BLKCNT
values are their fault; I think they just pick up that
counter and output it. Occasionally, fields with values
'FFFF...'X have shown up in SMF I/O fields like EXCP
BLOCK, SIO, etc. whose counters are in the address space.
They result from the subtraction of a counter with a
larger value from a counter with a smaller value, and
thus ultimately are the result of a programming error
deep in whatever system-level code used the wrong
internal counters. Some of these errors have been
tracked down, and fixed, but it can take significant
effort, multiple vendors, and even SLIP traps.
And many of these "bad" values can be traced back to an
ABEND in the address space that overwrote one or both of
the subtraction input counters!
-So I've changed the input for BLKCNT so the value is set
to a missing value instead of that large value when the
first byte is an 'FF'x. This way, you can use
PROC MEANS N NMISS DATA=TMS.DSNBRECD;
to count the number of DSNs with invalid BLKCNT values.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 28.060 Change 27.289 added CPUZIPTM for SYNCSORT that was added
VMACSYNC in an existing reserved area, but SYNCSORT 1.2 did not
Mar 24, 2010 have that expected reserved area, causing MXG to ERROR:
INPUT EXCEEDED RECORD LENGTH. CPUZIPTM is now INPUT
conditionally when the reserved area exists. Note that
the current SYNCSORT version is 1.3; they renumbered.
Thanks to David Bixler, FISERV, USA.
Change 28.059 -RMF III variable ASIASSTA (ADDITIONAL*SRB*TIME) is now
VMACRMFV correctly divided by 1000 in its INFORMAT.
Mar 24, 2010
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 28.058 AS400 Version 5.4.0 creates invalid records that do not
VMACQACS contain the "Century" value and a 2-byte POOL Number that
Mar 24, 2010 caused MXG to be misaligned, and all values were wrong!
The missing Century value is now forced for 5.4.0 records
so that dates and values are correct in QAPMPOLB dataset.
Thanks to Karen Florup, Bank of America, USA.
Change 28.057 MXG 28.01, SAS V8.2 ONLY: ERROR: MACRO KEYWORD ABORT IS
VMXGINIT NOT YET IMPLEMENTED. Change 28.023 added %ABORT statement
Mar 22, 2010 for obscure NOWORKINIT detection, but we no longer QA MXG
under SAS V8.2 so the omission was missed. This change
replaced %ABORT with a DATA STEP for sites still stuck in
that ancient and archaic version of SAS.
See Change 28.079A, which removed NOWORKINIT detection.
Note: This MACRO KEYWORD error also caused FORMATS to
error with ' 22 ' under the OTHER= argument, but the
VMXGINIT correction eliminated that spurious error.
Note: As a reminder, MXG does not fully support V8;
there are other errors that require SAS V9, but this
is not one of them.
Thanks to Teuvo Virsu, Tieto, FINLAND.
Change 28.056 Format MG099TC for variable S99TCOD had spelling errors:
FORMATS Action Code 3560: Change REV to REC.
Mar 22, 2010 Action Code 8975: Change NO to NA.
Thanks to Dick Arnold, Commerce Bank, USA.
Change 28.055 Using PDB=GTF to read DB2 GTF data did not always work.
ANALDB2R Multiple includes of VMACDB2 and VMAC102 could occur,
READDB2 the logic of which records were to be read was not always
Mar 22, 2010 correct, an unneeded data step was eliminated, and the
old-style macros are cleared with %CLEARDB2 so that you
can execute ANALDB2R multiple times (which also protects
PDB=SMF and PDB=PDB).
Apr 17: See Change 28.083. CLEARDB2 REMOVED.
Thanks to Tony Curry, BMC, USA.
Change 28.054 Variables TSQIOSTM and TSQIOWTM in CICSRDQU dataset from
VMAC110 Resource Class SMF 110 SUBTYPE=1 MNSEGCL=5 records were
Mar 20, 2010 wrong, and the count portion of those two "clocks" is now
input into new variables TSQIOSCN and TSQIOWCN.
Thanks to Danny Sun, IBM Global Services, AUSTRALIA.
Thanks to Tony Delmenico, IBM Global Services, AUSTRALIA.
Change 28.053 Executing TYPEQACS on ASCII caused OPTION JFCB UNKNOWN.
VMXGDSNL The VMXGDSNL macro is revised so that
Mar 19, 2010 - It works without referencing a JFCB
- Works on ASCII to find the part of the dataset between
the . and the / or the \.
- Continues to function as before to capture the
penultimate token of a GDG DSNAME.
Thanks to Paul Naddeo, FISERV, USA.
Change 28.052 Cosmetic. Fourteen misspellings of CONTENTION corrected.
VMAC42
Mar 16, 2010
Thanks to Miguel A. Fernandez, CitiGroup, USA.
Change 28.051 DB2 APAR PK62161 adds four important SQL counters that
VMACDB2 are output in DB2ACCT, DB2ACCTP, and DB2STATS:
Mar 16, 2010 QXRWSFET='ROWS*FETCHED'
QXRWSINS='ROWS*INSERTED'
QXRWSUPD='ROWS*UPDATED'
QXRWSDEL='ROWS*DELETED'
The APAR adds the fields to both DB2 V8 and DB2 V9.
Thanks to Terry L. Berman, DST Systems, USA.
Change 28.050 Documentation. If you want to reset the value of the
VMXGINIT OPTIONS USER=xxx;, then you MUST reinvoke VMXGINIT after
Mar 16, 2010 setting your desired LIBNAME:
OPTIONS USER=MYPDB;
%VMXGINIT;
%INCLUDE SOURCLIB(TYPEDB2,ASUMDB2A);
Thanks to Lars Fleischer, SMT Data, SWEDEN.
Change 28.049 -If you APPEND PDB datasets, you may receive warnings that
FIXTRNCD the old dataset did not have TRANSCODE attribute set.
Mar 16, 2010 These warnings are only cosmetic, and will go away when
Apr 29, 2010 you reset the MTD or WTD dataset with only the new MXG.
But, those warnings can be eliminated with the attached
FIXTRNCD program which adds the TRANSCODE=NO attribute to
all $HEX-formatted CHAR variables in the OLD MDT/WTD.
-MXG 28.01/28.02. Original FIXTRNCD program did not work.
Revised and tested Apr 29, 2010.
Thanks to Jan Hess, USAirways, USA.
Thanks to Doug Medland, IBM Global Services, USA.
Change 28.048 RMFV CPUG3 record has +192 bytes in z/OS 1.11.
VMACRMFV Temporary skip realigns data.
Mar 15, 2010
Thanks to Miguel Barrios, SSA, USA.
====== Changes thru 28.047 were in MXG 28.01 dated Mar 9, 2010========
Change Numbers with an asterisk are still OPEN, their text may change,
and the listed members might not have been updated yet in this release.
Contact support@mxg.com for current status of those changes.
Change 28.047 User defined CICS segment supported. Names similar to
IMACICUJ the expected names for IMACICDL caused this particular
UTILEXCL user segment to not be recognized, causing ERRORs when
Mar 9, 2010 SMF data was processed.
Thanks to Paul Baquet, Duke University, USA.
Change 28.046 Documentation. The summarization INTERVAL= request must
ASUM70PR be GREATER THAN OR EQUAL TO the RMF interval duration.
Mar 9, 2010 The default ASUM70PR has INTERVAL=QTRHOUR, but if that is
used with data that was created HOURLY, the output
ASUM70PR dataset(s) can have PCTCPUBY,PCTLnBY, etc.
percentages greater than 100, and there's nothing I can
do to correct those values with the incorrect INTERVAL=.
Change 28.045 The TIMEBILD table was arbitrarily limited to 99 entries;
TIMEBILD keeping ancient systems in the table caused an error when
Mar 8, 2010 the limit was exceeded; the limit is increased to 999.
Thanks to Betty Wong, Bank of America, USA.
Thanks to Michael Oujesky, Bank of America, USA.
Change 28.044 WPS failed with a compiler error in VGETOBS, reported as
VGETOBS UNRESOLVED MACRO %TRIM, but the error, documented in WPS
Mar 6, 2010 item 8385, was not in %TRIM, but was in the parsing of a
Mar 8, 2010 %VGETOBS value that had a plus sign (e.g. 1234e+56). WPS
maintenance 14690 corrected the compiler error, but now
we understand the code syntax that exposes the problem,
by adding %QUOTE() function around the %VGETOBS text, the
exposure is circumvented, without installing WPS 14690.
(First attempt using %STR() around %VGETOBS failed;
%STR is evaluated at compile time, %QUOTE is evaluated
at execute time, which is required here. Two other
%STR were changed to %QUOTE just for consistency.)
(Second attempt did not correctly parse a period that
was returned when the SAS Data Library was in XPORT
format.)
(Third attempt used %INDEX to solve the problem.)
Thanks to Atle Mjelde, ErgoGroup, NORWAY.
Change 28.043 zTPF has major revisions in Performance Data, with many
EXTPFCC old variables removed and new record types; while the new
EXTPFCF support is in new members TYPEZTPF/TYPSZTPF/VMACZTPF and
EXTPFCL not an updated TYPETPF, old DATASET and VARIABLE names
EXTPFCW that exist are unchanged, and TPF is still the prefix for
EXTPFCY the new dataset names.
EXTPFCZ Status
EXTPFGL TPFID DSECT DATA RECORD DATA IN DATA RECORD
EXTPFHP CC NO YES NO
EXTPFMT CF YES YES NO
EXTPFMT CL YES YES NO
EXTPFSF CW COMPLETED
EXTPFSI CY NO YES NO
EXTPFTH CZ NO YES NO
EXTPFUC GL YES YES NO
EXTPFVC HP YES YES NO
EXTPFVF MT COMPLETED
TYPEZTPF MU NO NO NO
VMACZTPF SF NO YES YES
VMXGZTPF SI COMPLETED
Mar 5, 2010 TH NO YES NO
Mar 30, 2010 UC YES YES NO
Apr 5, 2010 VC NO NO NO
VF NO YES YES
Thanks to Bob Wilcox, HP, USA.
Change 28.042 New Sentry VM 3.1.4.3 adds new objects and metrics:
EXNTAPOW dddddd Dataset Name Object
EXNTEVFS
EXNTEVFW NTAPOW APOOLWAS APP_POOL_WAS
EXNTHSRQ NTEVFS EVTRACWS EVENT TRACING FOR WINDOWS SESS
EXNTHSUG NTEVFW EVTRACWI EVENT TRACING FOR WINDOWS
EXNTIPDP NTHSRQ HTTPSRQU HTTP SERVICE REQUEST QUEUES
EXNTIPDR NTHSUG HTTPSUGR HTTP SERVICE URL GROUPS
EXNTIPGL NTIPDP IPSECDOS IPSEC DOS PROTECTION
EXNTPPAC NTIPDR IPSECDRI IPSEC DRIVER
EXNTPPIC NTIPGL IPHTTPSG IPHTTPS GLOBAL
EXNTPRIN NTPPAC PPNETACC PER PROCESSOR NETWORK ACTIVITY
EXNTSYNC NTPPIC PPNETINC PER PROCESSOR NETWORK INTERFAC
EXNTTECL NTPRIN PROCINFO PROCESSOR INFORMATION
EXNTTECL NTSYNC SYNCHRON SYNCHRONIZATION
EXNTTESE NTTECL TERECLIE TEREDO CLIENT
EXNTVWGA NTTECL TERERELY TEREDO RELAY
EXNTVWHA NTTESE TERESERV TEREDO SERVER
EXNTWFP NTVWGA VMGUESTA VMWARE.GUEST.AGGREGATE
EXNTWFPV6 NTVWHA VMHOSTAG VMWARE.HOST.AGGREGATE
EXNTWPFV4 NTWFP WFP WFP
EXNTWSMAN NTWFPV6 WFPTV6 WFPV6
IMACNTSM NTWPFV4 WFPV4 WFPV4
VMACNTSM NTWSMAN WSMANQUS WSMAN QUOTA STATISTICS
Mar 7, 2010
Change 28.041 Do NOT use ASMTAPEE ML-45/46; it caused CPU spikes in the
ASMTAPEE in the MXGTMNT address space (minutes vs fractions of a
Mar 9, 2010 second) that are now corrected by this new ML-47 release.
ML-45 was in MXG 27.10, ML-46 was in MXG 27.11/MXG 27.27.
Just in case, member ASMTAP44 contains ML-44.
Change 28.040 This original change text was wrong and replaced in 2011.
VMACTMS5 The new TMS Extended Format TMC did NOT change ANY size
Mar 5, 2010 of the TMC 340 byte records. The new Extended Format is
Dec 7, 2011 COMPLETELY COMPATIBLE WITH ALL VERSIONS OF MXG SOFTWARE.
See Change 29.274.
Change 28.039 -Dataset TYPE74CA variable R7451RID, the Rank ID, is input
VMAC74 from two bytes, but that produced values in the thousands
Mar 5, 2010 while the values in R748ARID and R748RRID in TYPE748A and
TYPE748R have values up to only 15. The observed values
in the first byte of R7451RID are between 1 and 15, and
and the second byte is 1 or 2, so (guessing), R7451RID is
now input from only the first byte and new R7451RI2 has
the value in the second byte, perhaps the Rank Group.
IBM RMF support observed the same values, but they only
get the two bytes from the interface.
-The Raid Rank segment has fields overlaid that populated
multiple variables, but variable R7451FLG is now used to
set missing values for the variables that don't exist.
This table identifies which R7451xxx variables have value
for each value of R7451FLG, which should be used to group
these three different sets of metrics in TYPE74CA.
R7451FLG
0=No Information, 1=Raid Rank Data, 2=Extent Pool Data
0 1 2
RID XID
HDD HDD XTY
RTY XFL
HSS
RRQ RRQ PRO
WRQ WRQ PWO
SR SR PBR
SW SW PBW
RRT RRT PRT
WRT WRT PWT
-Documentation. The three type 74 subtype 5 LSA Segments
(LO,RO,VO) added in OS/390 Release 2.10 in Change 18.134
were removed by IBM in z/OS 1.1, so these variables will
always be a missing value:
R745DCIR R745LFRE R745LKBF R745LKBR R745RBYF R745RBYS
R745RRID R745VBYW R745VFLG R745VNTR R745VNUM R745VSER
Thanks to Deb Soricelli, CIGNA, USA.
Change 28.038 SMF 120 SUBTYPE 9 caused INPUT STATEMENT EXCEEDED RECORD
VMAC120 because MXG thought variable SM1209ES was 128 bytes long,
Mar 3, 2010 when it should have been INPUT as 64 bytes long.
Thanks to Clayton Buck, UniGroup, USA.
Change 28.037 PDB.SMFINTRV will have EXCP/IOTM counts for FLUSHED steps
BUILD005 that have ZERO elapsed time (for example, steps bypassed
BUIL3005 execution due to JCL Condition Code Tests) if this causes
BUIL3005 the flushed step and the NEXT step to have identical time
Mar 3, 2010 in INITTIME and INTBTIME (step init, interval begin, to
.01 second resolution). Those NEXT step EXCPs/IOTMs were
incorrectly output in that FLUSHED step observation, and
the NEXT step observation had zero EXCP/IOTM counts.
The PDB.STEPS and PDB.JOBS datasets were correct, because
they don't use interval data.
And, in PDB.SMFINTRV, since those EXCPs were valid, but
just in the wrong step, both the JOB and INTERVAL totals
were always just fine.
-Adding INTETIME, the interval end time, in the BY lists
in SORTS and MERGES and KEEP= and in FIRST. and LAST. in
the MULTIDD algorithm corrects the error; it's now clear
they were always required for uniqueness.
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 28.036 -TYPE1032 from SMF 103 subtype 2 did not deaccumulate
VMAC103 correctly if PORTNR was not unique; variable JOB was
Mar 2, 2010 added to the BY list for uniqueness to correct.
-"SINCE*STARTUP" removed from label of variable TIMEOUTS,
as it is now the interval value, after deaccumulation.
Thanks to Matthew Chappell, Queensland Dept of Transport, AUSTRALIA.
Change 28.035 Cosmetic, a numeric to character conversion note was
VMXG2DTE eliminated.
Feb 28, 2010
Change 28.034 The references to %TRIM() function are not required, and
VGETOBS their removal may avoid UNRESOLVED MACRO TRIM errors.
Feb 28, 2010
Change 28.033 Incorrect MXG test for SEGLEN=220 for XAMSYS records in
VMACXAM the SUBSUM segment caused alignment ERRORS on the log.
Feb 28, 2010 Correct tests are for 224 and 228.
Thanks to Frank Bereznay, IBM Global Services, USA.
Thanks to Raff Rushton, IBM Global Services, USA.
Change 28.032 -IBM/CANDLE/OMEGAMON optional CMRDATA segment (IMACICMR)
IMACICMR was increased to 256 bytes in CICS/TS 3.2 (SMFPSRVR=65),
UTILEXCL and MXG tests that CICS version in IMACICMR, but records
Feb 27, 2010 from CICS/TS 3.2 with the old 200-byte length are still
created (presumably, the OMEGAMON exit for that segment
was not reassembled with CICS/TS 3.2 macros). While the
segment length of an optional CICS segment is not in the
CICSTRAN SMF record, if the MR segment happens to be the
LAST segment, this change invokes the old short-record
INPUT when less than 256 bytes are left and it's 3.2.
If the CMRDATA segment is not the last segment, the short
segment ultimately (hopefully) causes some sort of ERROR
(in this case, INVALID TASKNR DETECTED with a VERY large
value, due to the misalignment of the short record).
-While I can't tell segment length when creating CICSTRAN,
UTILEXCL will now detect the short CMRDATA segment under
CICS/TS 3.2 and print error messages on its log.
Thanks to Atle Mjelde, ERGO Group, NORWAY.
Change 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71, but I
VMAC30 had not re-examined the final SMF manual. Now added:
VMAC71 Dataset TYPE71:
Feb 25, 2010 SMF711RN='FIRST*REFERENCE*FAULTS'
SMF71FBN='FRAMES*BACKED*DURING*GETMAINS'
SMF71FFN='FRAMES*REQUESTED*TO BE FIXED*BELOW 2GB'
SMF71FRN='FIX*REQUESTS*BELOW*2GB'
SMF71GRN='GETMAIN*REQUESTS*ISSUED'
SMF71NRN='NON-FIRST*REFERENCE*FAULTS'
Datasets TYPE30_4,TYPE30_5,SMFINTRV,TYPE30_6:
SMF30HSH='HWM*USABLE BYTES*IN 64-BIT*SHARED'
SMF30HSO='BYTES IN*64-BIT*SHARED*STORAGE'
SMF30HVA='HWM*AUX*SLOTS*BACK*64-BIT'
SMF30HVH='HWM*USABLE BYTES*IN 64-BIT*OBTAINED'
SMF30HVO='BYTES IN*64-BIT*STORAGE*OBTAINED'
SMF30HVR='HWM*REAL*FRAMES*BACK*64-BIT'
Thanks to Don Deese, CPExpert, Computer Management Sciences, USA.
Change 28.030 Support for IMS Log 55x Statistics records, may not
VMACIMS have been tested with actual records.
Feb 24, 2010
Change 28.029 RMM datetime vars have always been wrong time zone. MXG
VMACEDGR assumed that the existence of a GMTOFF value in a Header
Feb 24, 2010 record extracted by EDGHSKP meant that the values in the
Mar 5, 2010 records were on GMT, so MXG added the GMTOFF, intending
Mar 8, 2010 to convert to local, but that incorrectly converted times
back to GMT time zone values. IBM rmm support confirms
that, since z/OS 1.8, extract records ALMOST ALWAYS have
the local time zone, even if the new Common Time UTC(YES)
option is enabled. However, if the RHTZNAME field in the
header record is non-blank, then the user specified the
TZ operand of the RPTEXT command, and times IN the record
were created on that time zone; in this case, MXG does
use the GMTOFF to convert record times to local time zone
and MXG prints a message when this is detected.
-The MXG support for all possible data formats added in
Change yy.xxx requires a Header Record to define the date
formats (Julian, American, European, etc.), but if there
was no Header record, all of the date/times were missing.
This change prints an error message if no "H" Header was
found as the first record in the file, and sets the date
format to the Julian (arbitrary, but most common), with
no guarantee that valid times will be created.
Thanks to Jorge Fong, NYC Information Technology, USA.
Thanks to Phillip Moore, UHC, USA.
Thanks to Robert Chavez, Florida Power and Light, USA.
Change 28.028 BMC IMF INPUT STATEMENT EXCEEDED RECORD LENGTH when a
VMACCIMS shorter than expected TRNEXTEN segment of only 16 bytes
Feb 24, 2010 was found; MXG expected 52 bytes. What's sad is that
I only input that segment, and didn't keep it, so it is
not even important, but now, the length remaining is
validated prior to the INPUT of that segment. BMC support
has acknowledge the error: "MVIMS should clear TRNEXTEN
and TRNEXTLN when it strips off the extension. A PTF will
be created to correct the problem.
Thanks to Lorena Ortenzi, UniCredit Global Info Services, ITALY.
Thanks to Paolo Uguccioni, UniCredit Global Info Services, ITALY.
Change 28.027 Do not use the EXIT112 ASM program to decompress CICS SMF
EXIT112 110 records: instead, use the EXITCICS ASM program to
Feb 23, 2010 create the CICSIFUE infile exit to process CICS/TS 3.2
VMAC110 compressed SMF records. As noted in the original change
text, EXIT112 was supposed to handle both 110 and 112
compressed records, and it was tested in 2007, but it now
fails with either 110 or 112 compressed records.
I thought you could use the IBM DFH$MOLS program to
decompress the 112 Omegamon records, but you can't.
-MXG VMAC110 was updated to print a message when the
internal SAS decompression code was executed because the
CICSIFUE exit was not installed.
Change 28.026 Only for consistency, SUMBY= argument changed to STARTIME
TRND71 in place of the now-archaic DATETIME symbol.
Feb 23, 2010
Change 28.025 New Crypto Type CEX3C PRCAPMCT=9 caused MXG to CPU LOOP
FORMATS on the DM=5 RC=10 PRCAPM segment, with no clue unless you
VMACVMXA enabled DEBUG=2 to see the last record before the loop.
Feb 22, 2010 -MXG now protects any unknown PRCAPMCT value with MXGERROR
messages for the first 3 records, and no CPU loop!
-PRCAPMCT values 3,5,7,9 have one structure, and 4,6,8
have a second structure (and 4 has 5 engines, while 6,8
have only one engine). All seven values are now decoded.
-Variable PRCAPMCT is now formatted with new MGVXACX
to map the value to the Crypto Type processor:
3='3:PCICC'
4='4:PCICA'
5='5:PCIXCC'
6='6:CEX2A'
7='7:CEX2C'
8='8:CEX3A'
9='9:CEX3C'
Thanks to Jim Kovarik, AEGON USA, USA.
Change 28.024 Variable BYTESIN is now MGBYTES formatted, rather than
VMACAIX MGBYTRT formatted, as it contains bytes, not a rate.
Feb 18, 2010
Thanks to Glenn Bowman, Wakefern, USA.
Change 28.023 -New MXGERROR and USER ABEND 990 if NOWORKINIT is enabled.
VMXGINIT Unlikely/obscure, but if //WORK is a Permanent DSNAME and
Feb 18, 2010 has DISP=OLD, that NOWORKINIT option skips initialization
of the (normally temporary) //WORK library, so whatever
temporary stuff (macros, catalogs, tables, datasets) was
left from the last SAS step will be used for this step.
While there may be some applications that can use this
"feature", MXG is NOT one of them. When an ITRM site
with that environment upgraded to 27.27, the SAS Compiler
initially had UNRESOLVED MACRO VARIABLE TEMP1ENG errors
in the first execution of VMXGSUM in BUILDPDB, but a job
to enable diagnostics had a typo that caused an error,
but when fixed and diagnostics were enabled, yet another
compiler error was encountered, and three subsequent runs
all failed with different errors. It was only when one
error reported CORRUPTED MACROs that we spotted the reuse
of the //WORK DD in the JCL, and only because diagnostic
option VERBOSE had been turned on that we saw the CONFIG
in use had specified the NOWORKINIT option.
That original unresolved macro error was false; there was
no error in MXG code, but was the result of a conflict
between the old, compiled, %VMXGSUM macro in //WORK that
was compiled from the old MXG, with the invocation in the
new MXG that expected the new definition. Changes were
made to VMXGSUM between the two versions.
This change causes a USER ABEND 990 and MXGERROR messages
if the NOWORKINIT is enabled at MXG Initialization.
-All VMXGxxxx members that define volatile %MACROs print a
single MXGNOTE: VMXGxxxx LAST UPDATED...., when the macro
is compiled; this will avoid a rerun just to determine if
an old macro is in use when there are errors.
-But, see Change 28.079A
Change 28.022 -ML-47 of ASMTAPEE/MXGTMNT protects for diagnostic ABEND.
ASMTAPEE If diagnostic trap IEAINITREGSTASK is enabled, it causes
Feb 13, 2010 a recoverable ABEND 0E0-28 for each XMEM Cross-Memory
call, with a loss of data fields in some MXGTMNT records,
and the unwanted overhead of triggering that trap.
Diagnostic traps like this are enabled, usually only on
test systems, but especially on new z/OS system tests,
to expose existing or potential coding errors. The fact
that this trap caused an abend doesn't necessarily mean
there is an error.
The idea behind this one is that if a program does not
properly set a register, then any use of that register
could potentially lead to a storage overlay. Storage
overlays are some of the most difficult problems to
diagnose because you don't get an abend when the storage
is overlaid: the abend only comes later when subsequent
code attempts to use that storage and comes across that
now-corrupted area. The abend could happen immediately,
or hours later.
This trap places x'FF' in all registers, including access
registers, at task initialization, with the expectation
that the task will clear all access registers before it
goes into AR cross memory mode. The 'FF'x will cause the
code that is using the register without clearing it to
immediately abend, making this storage overlay error much
easier to find. There are several IBM APARs for various
products that had identical S0E0 ABENDS.
Newer sections of MXGTMNT do clear all ARs, but the older
code, pre ML-29, only cleared the ARs that were actually
used, leaving the unused ARs with the x'FF' value.
What is the exposure for MXGTMNT? There isn't any. This
trap exposes, at most, a bad programming practice, maybe!
The trap ABEND is caused by the access registers being
set to x'FF's. Access registers are used for access via
cross memory, and the trap sets them when the task is
first created and entered.
Since MXGTMNT is the first task there is no chance that a
previous task left any unwanted data in the access
registers. But even though there is no exposure, we have
no choice but to add code to clear all ARs; otherwise
anyone who runs MXGTMNT with that diagnostic trap enabled
will encounter these abends.
See Change 28.041 text for ML-47 status.
Thanks to Ginny Nugent, SAS Institute, USA.
Thanks to Ed Webb, SAS Institute, USA
and to my "asmguy", who provided the explanations and the update.
Change 28.021 The zPCR program works fine for simple configurations,
ANALZPCR but with missing data, or multiple, complex, sysplexes
Feb 13, 2010 the ANALZPCR program could fail, the MXG-created .zpcr
Feb 16, 2010 file load could fail, or a model that would load without
Feb 25, 2010 an error could have SYSTEMs in the wrong SYSPLEX.
Feb 28, 2010 -The SYSPLEX value in PDB.TYPE70PR is NOT the SYSPLEX of
Mar 4, 2010 the LPARNAME, but, rather, is the SYSPLEX on which that
Mar 5, 2010 SMF record was written, a fact overlooked in ANALZPCR,
which needs to correctly associate LPARNAME to SYSPLEX.
Depending on the alphabetical ordering of your SYSTEM and
SYSPLEX names, ANALZPCR sometimes accidentally had the
right SYSTEM in the right SYSPLEX, but not always.
Now, PDB.TYPE70, whose SYSTEM-SYSPLEX pairing is always
right, is read to create a format mapping SYSTEM to its
SYSPLEX (in addition to the existing format that maps the
SYSTEM to MVSLEVEL). Then, PDB.TYPE70PR is read, values
of MVSLEVEL/SYSPLEX are set from SMF70STN format lookups,
and the WORK.TYPE70PR dataset has correct SYSPLEX and
MVSLEVEL for LPARNAME, so ANALZPCR now always is right.
-zPCR load fails with MXG-created .zpcr file if incomplete
SMF/PDB data input was read and SCP created.
The input SMF or PDB must have TYPE70 observations for
every SYSTEM to get the MVSLEVEL, which is used to set
the SCP tag from SMF70STN in TYPE70PR. If a system's
data doesn't have TYPE70 data and is only in the TYPE70PR
LPAR data, the SCP tag value 'z/OS-MXG**' has always been
created in the .zpcr file, but not documented, and that
tag value must be changed for zPCR to load the text file.
Now, there are ERROR messages when you have missing data
telling you MUST change those SCP tag values before using
the .zpcr file. Output reports also are enhanced to show
the MVSLEVEL and SMF70STN for each LPAR.
-ANALZPCR program fails with overlapping FORMAT values if
the SMF/PDB input has data with multiple MVSLEVELS from
the same SYSTEM. ANALZPCR will now detect and continue
to execute, and will use the LAST MVSLEVEL for SCP tag,
but will also print ERROR messages when this is detected.
ANALZPCR can't easily be redesigned to support this
multiplicity, but you can split your input and run the
ANALZPCR twice to create each of the two .zpcr files.
-When ANALZPCR is run on ASCII, to read a PDB.TYPE70 that
was CIMPORTed from z/OS and that had been created on z/OS
"before" the TRANSCODE attribute was added by MXG 27.01
(Change 27.014) to all HEX-containing-$CHAR-variables,
variable CPUTYPE will have been converted to '886D'x for
a true CPUTYPE='2094'x. ANALZPCR now tests CPUTYPE for
these "wrong" values: 886D/886F/8870/8871x in CPUTYPE
and corrects them to: 2094/2096/2097/2098x so that the
NAME tag that zpcr expects is created in the .zpcr file.
-When PDB=SMF was used, DASDIORT counted only DASD I/O by
selecting only DEVCLASS=20X when SMF was read. But when
PDB=PDB was used, but only if your PDB.TYPE74 dataset had
other DEVCLASS's captured, DASDIORT was the total I/O.
Now, the PDB=PDB logic selects only DEVCLASS=20X counts.
-MXG uses LCPUSHAR, the Initial Shared LPAR Weight, but if
IRD is active (LPARWLMG='Y'), zPCR expects SMF70ACS, the
Current Shared Weight.
-The message for Linux LPARs that you have to manually put
the SCP type printed the SYSTEM instead of the LPARNAME.
-When PDB=CECTIME was used, specialty engine and ICF's
could have been miscounted.
-SELECT PEAKTIME or PEAKPCT only summarize zOS SYSTEMs,
and they do NOT contain IFLs, nor ICF partitions, and
thus are unlikely to be used. CECTIME is DEFAULT.
-Mar 4, 2010. zPCR Release 6.3a failed to load a model
with CPUTYPE 2094-722; IBM zPCR support
created an updated zPCR program with same-day-service!
With that new release, the Book Configuration, which is
now VERY important, can be specified in the pull-down.
Thanks to Frank Bereznay, IBM Global Services, USA.
Thanks to Raff Rushton, IBM Global Services, USA.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 28.020 Variable QAQSGDSP, Sharing Group Dispositions, in dataset
FORMATS TMMQQAA is now decoded by new FORMAT $MGTMQDI.
VMACTMMQ
Feb 12, 2010
Thanks to Paul Volpi, UHC, USA.
Change 28.019 INVALID DATA FOR RVTRERR in EDGHSKP records is caused by
VMACEDGR IBM writing a question-mark character instead of a count
Feb 10, 2010 of errors as an &NUM4. field. This change eliminates
that NOTE and the HEX record dump for all four xxxxERR
variables (by changing the INPUT to use ?? &NUM.4.), but
IBM will be contacted for an explanation; perhaps they
store a question mark when the error count is larger than
the maximum of 99999 that fits in that 4-byte field.
These instance of invalid data values can be identified
because RVTRERR will be a missing value in the EDGRXEXT
or EDGRVEXT dataset.
Thanks to Paul Volpi, UHC, USA.
Change 28.018 All of the duration/clock values are in 1024 microsecond
VMACTMVT units and not the 64 microsecond units MXG had coded; the
Feb 10, 2010 correct 1024 multiplier is now used. The FORMAT TIME13.3
will still display decimals the maximum resolution of one
millisecond (0.001 seconds), since 1024 microseconds is
just at teeny bit more than one millisecond.
Thanks to Paul Volpi, UHC, USA.
Change 28.017 CICS Optional 'PSB SCHL', a mis-spelling of the expected
UTILEXCL 'PSB SCHD' field name, is now recognized and supported.
Feb 8, 2010
Thanks to Thomas E. Porta, TYCO Electronics, USA.
Change 28.016 SAS Version 9.2 changed the PROC GCHART's PATTERN default
DOC to a terrible choice that produces unreadable patterns.
Feb 6, 2010 Feb: Investigating alternatives.
Aug 9, 2010 Aug: Better definition of color/patterns now defined as
default in VMXGINIT, but if you choose your own,
yours will instead be used.
Change 28.015 Support for z/TPF SMF 89 record; z/TPF put the subtype in
VMAC89 byte 19 rather than bytes 19-20 as documented for z/OS.
Feb 3, 2010 MXG protects either z/OS or z/TPF SMF ID=89 records now.
Thanks to Paul J. Westerhout, KLM, THE NETHERLANDS.
Change 28.014 MXG 27.10-MXG 27.27. The wildcard colon-suffix in the
VGETDDS DDNAMES= argument, to allocate all DDNAMEs starting with
Feb 3, 2010 those characters (%VGETDDS,DDNAMES=PDB:); worked ONLY for
DDNAMES=PDB:). Any OTHER prefix characters ahead of that
colon caused syntax errors. And, DDNAMES=ALLDAYS or even
a list of specific DDNAMES=MON TUE WED names also failed,
with LIBNAME PDBx NOT ASSIGNED because a separate error
sent VMXGDDS to try to allocate LIBNAMES starting with
PDBn, no matter what names you used in your DDNAMES=.
Note: If the DATASET you will look for in VMXGSET might
not exist in all of the LIBNAMES you specify, you
can use OPTIONS NODSNFERR; and only the found
datasets will be read by VMXGSET, and the SAS log
will indicate which DDnames had the DATASET.
Thanks to Paul Naddeo, FISERV, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.013 Variables QW0127FG/QW0127PG/QW0128FG/QW0128PG are INPUT
FORMATS and kept in T102S127 and T102S128 datasets. The "PG"
VMAC102 variables are four-byte replacements for the three-byte
Jan 30, 2010 existing "PN" page number variables.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.012 Very kewl tool, %VMXGFIND searches a SAS data library to
VMXGFIND FIND all observations in all datasets that meet your test
VGETVAR criteria, outputs those selected obs into a separate SAS
VMXGPRNT data library, and prints all selected obs (all variables,
Jan 31, 2010 with the variable's name AND label as heading).
For example:
%VMXGFIND(
PDB=PDB,
PDBOUT=PDBOUT,
KEEPIN=JOB,
FIND= IF JOB='MXGBUILD'; ,
PRINT=YES);
finds all obs with JOB='MXGBUILD' in all of the datasets
in the PDB input library, and outputs those obs into
their datasets in the PDBOUT data library, and prints.
In your KEEPIN= argument, you list all of the variables
that will be used in the SAS code in your FIND= argument.
Only the datasets with one or more of those variables are
read, and the FIND= logic is used to output the selected.
You can test with complex logic with multiple variables
that don't exist in all of the dataset. For example:
%VMXGFIND(
PDB=PDB,
PDBOUT=PDBOUT,
KEEPIN=STARTIME STRTTIME INTBTIME,
FIND= IF ('31JAN2010:15:00:00'DT LE STARTIME LT
'31JAN2010:16:00:00'DT )
OR ('31JAN2010:15:00:00'DT LE STRTTIME LT
'31JAN2010:16:00:00'DT )
OR ('31JAN2010:15:00:00'DT LE INTBTIME LT
'31JAN2010:16:00:00'DT ) ;,
PRINT=100);
selects all interval observations that started in the 3PM
hour, from RMFINTRV plus all detail RMF datasets, from
CICINTRV and any other CICxxxxx interval datasets, from
DB2STATx interval datasets, from the SMFINTRV dataset,
and from ANY other PDB dataset with ANY of those three
variables meeting the test. There will be log messages
UNINITIALIZED VARIABLE printed when a dataset being read
doesn't contain all KEEPIN= variables, but they are
harmless and unavoidable.
Or, this example
%VMXGFIND(PDB=PDB,PDBOUT=PDBOUT,
KEEPIN=RACFUSER QWHCAID FSRUID,
FIND=IF RACFUSER=::'JOE" OR
QWHCAID=:'JOE' OR
FSRUID=:'JOE';,
PRINT=YES );
will find all observations from user "JOE".
New %VGETVAR(DDNAME=,DATASET=,VARNAME=), used in VMXGFIND
determines if variable VARNAME exists in DDNAME.DATASET.
VMXGPRNT now deletes WORK.TMPPRNT (previously WORK.SP_L).
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.011 Reading VSAM SMF for type 119 records failed; the OFFSMF
VMAC119 was not added to all of the offsets.
Jan 29, 2010
Thanks to Kim Westcott, State of New York, USA.
Change 28.010 Variable SHIFT is created from the QWHSSTCK (END TIME) in
VMACDB2H the DB2 Header for all DB2 records, and SHIFT is now kept
VMACDB2 in all of the datasets created from SMF 100 and 101 data.
Jan 28, 2010
Thanks to Atle Mjelde, ErgoGroup, NORWAY
Change 28.009 INVALID DATA FOR CVTTZ in z/OS 1.11 Type 0 record is due
VMAC0 to absence of &IB.4. in its INPUT statement, but as this
Jan 28, 2010 new variable is not used elsewhere, this had no impact,
except the waste of your time chasing this message down.
I missed this because there were no IPL records in any of
my z/OS 1.11 test SMF data, and because the absence of an
INFORMAT in an INPUT statement is not a syntax error.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 28.008 The SPIN.SPINMOUN and SPIN.SPINSYSL dataset could grow to
ASUMTAPE massive size (1.8 million obs in SPINSYSL) because there
Jan 26, 2010 was no test to stop their spinning after some number of
days. Now, IMACSPIN is read and its value of _SPINCNT is
used to determine when a still-unmatched syslog message
should be "spun" again. When observations are deleted
due to their age, the count is printed on the SAS log.
The default IMACSPIN has _SPINCNT of zero, because if
you failed to read INSTALL's instructions on how to
EDIT your IMACSPIN member, at least then when you run
your first BUILDPDB, all of the jobs in SMF are output
to the PDB library, with none output to SPIN, so you
will find all your jobs, complete and incomplete, in
that first PDB. Then, when you ask about all those
incomplete jobs, tech support will point you back to
read INSTALL and IMACSPIN to set _SPINCNT.
But for ASUMTAPE, I will always spin the incomplete
mount events at least one day, using _SPINCNT+1, which
should allow most incomplete mounts today to match up
tomorrow, even if you haven't changed IMACSPIN.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 28.006 An example Ranking analysis, a PROC RANK on steroids.
ANALRANK
Jan 25, 2010
Change 28.005 -Support for Sun StorageTek Enterprise Library Software
VMACSTC Version 6.2 and Version 7.0. Version 6.2 adds new field
Jan 25, 2010 STC14N4K, the number of 4K blocks, used to re-calculate
Feb 2, 2010 STC14VSZ, which was previously limited to a max of 4GB.
Sep 16, 2010 Variables marked with * below, are only in Version 7.
-New variables added to STCVSM13 dataset;
*STC13PLX='TAPEPLEX*FROM WHICH*VTV RECEIVED'
-New variables added to STCVSM14 dataset;
STC14SRS='SYNCHRONOUS*REPLICATION*STATUS'
STC14RUN='REWIND*UNLOAD*RECEIVED*DATETIME'
*STC14PLX='TAPEPLEX*FROM WHICH*VTV RECEIVED'
-New variables added to STCVSM16 dataset;
STC16INF='RTD*CHANNEL*INTERFACE*ID'
STC16ADR='MVS*ADDRESS*OF*RTD'
-New variables added to STCVSM17 dataset;
STC17INF='RTD*CHANNEL*INTERFACE*ID'
STC17ADR='MVS*ADDRESS*OF*RTD'
*STC17DFL='DISMOUNT*FLAG'
-New variables added to STCVSM18 dataset;
STC18INF='RTD*CHANNEL*INTERFACE*ID'
STC18ADR='MVS*ADDRESS*OF*RTD'
-New variables added to STCVSM19 dataset;
STC19INF='RTD*CHANNEL*INTERFACE*ID'
STC19ADR='MVS*ADDRESS*OF*RTD'
-New variables added to STCVSM25 dataset;
STC25SCL='MVS*STORAGE*CLASS'
STC25TUS='SPACE*USED BY*CURRENT*VTVS'
STC25NDV='NUMBER*OF HOLES*DELETED*VTVS'
STC25LUT='MVC*LAST*USED*DATETIME'
STC25LWT='MVC*LAST*UPDATED*DATETIME'
-New variables added to STCVSM26 dataset;
STC26MGT='VTV*MANAGEMENT*CLASS'
-New variables added to STCVSM27 dataset;
STC27CTP='CARTRIDGE*TYPE'
STC27MV3='VOLSER OF*MVC3*CONTAINING*THE VTV'
STC27MV4='VOLSER OF*MVC4*CONTAINING*THE VTV'
-New variables added to STCVSM28 dataset;
STC28RUN='REWIND*UNLOAD*RECEIVED*DATETIME'
*STC28PLX='TARGET*TAPEPLEX*FOR*EXPORT'
-Sep 16: No code change, but with this change there were
obs created from subtype 7 records in STCHSC dataset
with the Oracle SL8500 hardware, whereas MXG 27.05
created zero observations in STCHSC.
Thanks to Davide Marone, SGS S.p.a. ITALY
Thanks to Carlo Gavinelli, SGS S.p.a. ITALY
Thanks to Gianvittorio Negri, SAS Institute, ITALY.
Change 28.004 The EXTREMELY DETAIL DB2 Trace Report PMTRC01 is revised
ANALDB2R for efficiency, keeping track of which of 350 possible
Jan 25, 2010 trace datasets are actually populated, and only using
Feb 22, 2010 their variables. Some uninitialized variables messages
and character to numeric conversions were eliminated.
Note that your DBA needs to enable all of these IFCIDs to
cover all I/O and SQL calls:
IO 6 7 8 9 10 29 30 34 35 36 37 38 39 40 41 105 107
114 115 116 119 120
SQL 6 7 8 9 10 11 12 15 16 17 18 19 20 22 44 45 53 55
58 59 60 61 62 63 64 65 66 68 69 70 71 73 74 75 76
77 78 79 86 87 88 89 95 96 105 107 125 157 158 159
160 163 174 175 177 183 ACCOUNT
With CONNTYPE=4 in the argument list, only records from
CICS Connection will be reported, so if both I/O and SQL
traces are enabled, you can see what DB2 Tables/DBIDs are
touched for each transaction, and can what types of SQL
calls were made for each transaction. Unfortunately, you
can NOT map SQL calls to each DB2 Table that was used.
%ANALDB2R(PDB=SMF,PMACC01=NO,PMACC02=NO,
PMSTA02=NO,PMSPR01=NO,
PMTRC01=YES,CONNTYPE=4);
See correction in Change 28.083.
Thanks to Paul Volpi, UHC, USA.
Change 28.003 Summary of (archaic) SMF 118 records in ANALTCP and of
ANALTCP current SMF 119 records failed if PDB was on TAPE.
ANAL119
Jan 21, 2010
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.002 Variables CPUZIPTM and CPUIFATM added to this example
ASUMSMFI summarization of PDB.SMFINTRV.
Jan 21, 2010
Thanks to Frank Lund, EDB Business Partner Norge AS, NORWAY
Change 28.001 Unused Change.
LASTCHANGE: Version 28.