COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 25.25
=========================member=CHANGE25================================
/* COPYRIGHT (C) 1984-2008 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 25.25 is dated Jan 28, 2008, thru Change 25.309
First MXG Version 25.25 was dated Jan 21, 2008, thru Change 25.302
MXG Version 25.12 was dated Jan 21, 2008, thru Change 25.294
MXG Version 25.11 was dated Dec 7, 2007, thru Change 25.268
First MXG Version 25.11 was dated Nov 22, 2007, thru Change 25.256
MXG Version 25.10 was dated Oct 7, 2007, thru Change 25.215
MXG Version 25.09 was dated Sep 17, 2007, thru Change 25.199
MXG Version 25.08 was dated Sep 5, 2007, thru Change 25.187
First MXG Version 25.08 was dated Sep 4, 2007, thru Change 25.182
MXG Version 25.07 was dated Aug 10, 2007, thru Change 25.161
MXG Version 25.06 was dated Jul 4, 2007, thru Change 25.134
MXG Version 25.05 was dated Jun 7, 2007, thru Change 25.107
MXG Version 25.04 was dated May 7, 2007, thru Change 25.086
Second MXG Version 25.03 was dated Apr 12, 2007, thru Change 25.058
First MXG Version 25.03 was dated Apr 10, 2007, thru Change 25.057
MXG Version 25.02 was dated Mar 10, 2007, thru Change 25.033
MXG Version 25.01 was dated Mar 5, 2007, thru Change 25.025
MXG Version 24.24 was dated Feb 5, 2007, thru Change 24.306
MXG Newsletter FORTY-NINE was dated Feb 5, 2007
MXG 25.25 is the 2008 "Annual Version", dated January 28, 2008.
Instructions for ftp download of MXG 25.25 were mailed to all licensees,
but you can always request ftp download instructions using the form at
http://www.mxg.com/ship_current_version
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. Current MXG Software Version 25.25 is available upon request.
II. Incompatibilities and Installation of MXG 25.25.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Version 25.25, now re-dated Jan 28, 2008.
Minor cosmetic corrections in MXG 25.25, re-dated Jan 28, 2008
TYPEXAM 25.307 Extraneous PUT from testing removed.
ASUM70PR 25.303 Extraneous PROC PRINT from testing was removed.
Minor enhancements in MXG 25.25, re-dated Jan 28, 2008
TYPERMFV 25.309 Support for RMF III CPD, Channel Path Data Table.
TYPE102 25.306 IBM SMF 102 IFCID 22 APAR PK38803 wrong, supported.
TYPE30 25.304 Support for APAR OA23679, BLKSIZE might be wrong.
COMPINTV 25.302 Capture/Compare ALL CPU times in 30/70/72/100/101/110
Major enhancements added in MXG 25.25, dated Jan 21, 2008
ADOCs 25.296 All ADOCxxxx member's CONTENTS were updated.
Major enhancements added in MXG 25.12, dated Jan 21, 2008
TYPEDB2 25.265 DB2TCBTM Correction for DB2 V9.1, REQUIRED.
TYPEDB2 25.291 DB2ACCT variable QWACUDCP CPU time added in DB2TCBTM.
TYPE122 25.287 Support for SMF 122, Tivoli Tape Allocation Manager
TYPEITRF 25.286 Support for ITRF DCR77/DCR78 additions.
TYPENTSM 25.282 Support for new NTSMF Objects, Database Mirroring.
TYPEMQLG 25.280 Support for MQ V6 System Admin Accounting Queue Log.
TYPE85 25.279 Support for subtypes 38, 39 and 40 for ID=85 OAM.
TYPEPSYC 25.277 Support for PSYNCH/390 SMF record.
TYPE22 25.276 Support for APAR OA20043 Dynamic Volume Expansion
TYPE102 25.306 Support for APAR PK38803 INCOMPAT SMF 102 IFCID 22.
TYPE50 25.269 Support for OSA-MPC VTAM SMF 50 subtype 4 record.
TYPETIMS 25.271 Revisions for TMON/IMS support
ASUM70PR 25.270 INTERVAL=DURSET cannot be used.
CONFIGV9 25.267 VALIDVARNAME=V7 added to SAS CONFIGs.
ITRMTNG 25.262 233 DDU files to create ITRM definitions for TYPETNG.
Major enhancements added in MXG 25.11 dated Dec 7, 2007.
TYPE111 25.241 Support for CICS CTG 7.1.0 new SMF 111 record.
TYPE110 25.240 Full Support for CICS/TS 3.2 Compressed Data
EXITCICS 25.240 New "CICS" INFILE EXIT for CICS compressed SMF data.
TYPE7072 25.224 CPUTYPE tests are replaced with ZARCHMDE tests.
This means that with MXG 25.11 or later, a new IBM
CPUTYPE will NOT require a new MXG Version.
TYPETPMX 25.239 Support for Thruput Manager SLM and DB2 data.
TYPE82 25.257 Support for ISCF HCR7750 TKE Logging update.
TYPEEVTA 25.255 Support for Action Software's EventAction user SMF.
TYPE85 25.234 New variables in OAM subtype 32-35 records.
TYPE78 25.236 Zero obs in TYPE78IO with Change 24.171 if z/OS 1.7.
TYPEEVTA 25.255 Support for Action Sofware's EventAction SMF record.
TYPERMFV 25.246 Updates for CPU Segmentation changes.
TYPENTSM 25.253 Support for new NTSMF objects for MSSQL.
TYPETNG 25.221 Support for VM Ware VSX Systems in CA NSM records.
TYPETNG 25.235 New Solaris, AIX, and many RedHat objects added.
VMXGSUM 25.248 New &LNSUMOUT=8 will make all output to length 8.
UTILEXCL 25.256 Macro variable &MXGDEBUG revised for IMACEXCL plus!
EXITCICS 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
TYPE110 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
UPRINDOC 25.226 Utility prints NAME and LABEL of all variables.
TYPE30 25.260 MXG 25.10, INTRVLTM missing for TYPETASK='OMVS'
ANALACTP 25.254 Sample report summarizes DB2 Package data to UOW.
CONFIGW2 25.252 MXG updates for testing MXG Execution under WPS.
Major enhancements added in MXG 25.10.
TYPE7072 25.205 Support for z/OS 1.9, up to 54 CPUs per MVS, INCOMPAT
TYPERMFV 25.204 CFI Segmentation eliminates RMF III skipped CF data.
ANALDB2R 25.202 VARIABLE QBnTDPIO NOT FOUND error corrected.
TYPE70 25.211 ZIPACTTM, PCTZIPBY corrected for Dedicated zIIPs.
ASUMCELP 25.209 Duplicate observations in PDB.ASUMCELP eliminated.
TIMEBILD 25.209 Optional SYNC59 timeshifting using TIMETABL.
Major enhancements added in MXG 25.09.
IMPORTANT CHANGES:
Almost none! Only UTILEXCL in 25.08 had an error, but these other
fixes/enhancements are now ready for prime time:
UTILEXCL 25.193 MXG 25.08 ONLY: LABEL IMACICU3 NOT FOUND.
TYPERMFV 25.191 Support for RMF Monitor III CFI table enhancements.
TYPESRDF 25.195 Support for EMC's SRDF/A user SMF record.
READDB2 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
ANALDB2R 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
RMFINTRV 25.199 SMF70GIE now reset to 00/15 if SYNC59=YES is used.
TYPE89 25.198 SMF89HOF,SMF89DTO were incorrect due to typo.
UTILCSV 25.197 %UTILCSV creates a CSV (or TAB) Delimited flat file.
UTILBLDP 25.196 Large &MACKEEP string caused strange results.
TYPE92 25.192 New ID=92 ST=14 INPUT EXCEEDED if not a RENAME.
Major enhancements added in MXG 25.08.
IMPORTANT CHANGES:
TYPETNG 25.181 Support for CA NSM RedHat 4.01 Linux perf cube.
TYPE7072 25.176 Support for APAR OA18244, Blocked Workload z/OS 1.9.
TYPE7072 25.163 Support for Capacity Groups variables in TYPE70.
ASUM70PR 25.163 Capacity Group summarization, PDB.ASUM70GC/ASUM70GL.
TYPEQACS 25.178 AS400 APAR QAPMDISK with LRECL=456 added new data.
ADOCDB2 25.172 Example to process DB2 datasets to separate DDNAMES.
TYPEDB2 25.169 _RDB2ACC DB2 Parallel event "analysis" example.
Many 25.179 %UPCASE,%LOWCASE,%STR,%BQUOTE,%QUOTE, etc.
Doc 25.179 Use %LET MACxxxx= %STR( text ) ; to pass text.
Major enhancements added in MXG 25.07.
CRITICAL CHANGE:
TYPE78 25.141 APAR OA21799 for HiperPAV, ABEND, SMF78HIX invalid.
Installing HyperPAV can create invalid RMF 78-3's
that cause BUILDPDB to ABEND as it reads RMF 78's.
Change 25.141 will detect bad records and avoid the
ABEND, but you will need to install the IBM PTF for
the APAR to correct the invalid data values.
IMPORTANT CHANGES/ENHANCEMENTS:
Many 25.140 Prelim z/OS 1.9 (fails if 54-CPs, See Ch 25.205)
TYPECIMS 25.139 Support for IMF Version 4.3 (INCOMPATIBLE).
TYPE74 25.140 APAR OA17070 supports CF Level 15 measurements.
TYPE89 25.138 Support for APAR OA20314 new SMF89LPN/SMF89ZNA.
TYPE80A 25.137 Support for unknown TOKDANAMs, prevents ABEND.
UTILLPDS 25.136 Utility to count used/defined PDS Directory Blocks.
TYPE7072 25.135A LCPUCAP/LCPUCAPC Labels include "Hard CAP".
TYPE42 25.153 MXG 25.06 only, false INVALID TYPE42 SUBTYPE 5 error.
TYPEVMXA 25.151 180 Error _MPRCAPC not found, DEBUG prints removed.
ASUM70PR 25.150 ASUM70PR created PCTCPUBY GT 100%, final fix?
ASUM70PR 25.150 ASUM70PR now supports INTERVAL/CECINTRV=SHIFT.
ADOCITRM 25.149 Doc. Maps ITRM dataset names to MXG name.
ADOCDB2 25.148 Doc. How to create DB2ACCTB/DB2ACCTP in separate DDs.
ANALRMFR 25.146 ERROR: NO DATASETS TO LOOKUP correction.
TYPERMFV 25.145 RMF III dataset ZRBLCP missing obs for many LPARs.
UPCMEMDZ 25.144 ASCII utility to determine memory available to MXG.
TYPE71 25.143 SWAPrates were set missing if zero, now can be zero.
VMXGINIT 25.143 New MXGMISS macro variable changes TYPE71 SWAPrates.
Major enhancements added in MXG 25.06.
TYPE30 25.116 MXG 25.05, negative EXECTM, INTRVLTM, GMTOFF30 wrong.
TYPE110 25.041 Support for CICS/TS 3.2 (INCOMPATIBLE), Uncompressed.
TYPEBTE 25.107 Support for CA Brightstor Tape Encryption SMF.
TYPE80A 25.131 Support for CRL PUBLISH and SET UID RACFEVNT 52, 79.
TYPEFERT 25.133 Support for Williams Data FERRET product user SMF.
TYPECLAR 25.130 Support for Clarion Disk Array flat files.
TYPE119 25.119 SMF 119 from z/OS 1.8 caused INVALID DATA messages.
TYPESYNC 25.117 INVALID ARGUMENT due to incorrect HEX4/HEX3 formats.
ASUMUOW 25.121 Enhanced to keep each CICS segment response time.
ASUMHSM 25.113 HSM Summary enhanced with "HSM COMPLEX" HSMPLEX.
IHDRIDMS 25.112 CA IDMS PerfMon support enhanced with "IHDR" exit.
TYPENMON 25.110 Support for DISKBUSYn for all NMON Disk Monitoring.
TYPERACF 25.134 Support for IRRDBU00 record types 0560,0561,0562.
TYPE80A 25.131 Support for TOP SECRET (INCOMPAT) '90'x,'00'x VRSN.
MXG Version 25.05, dated Jun 7, 2007.
Major enhancements added in MXG 25.05.
TYPEITRF 25.103 Support for IBM OMEGAMON TRF ITRF V550 and V560.
TYPENMON 25.104 Full support for NMON, Nigel's Monitor for AIX/unix.
TYPEDB2 25.090 Support for PK37354 SMF 101 Subtype 4 in DB2 9.
TYPEDB2 25.097 Variable THREADTY blank if non-DDF transaction.
TYPE30 25.089 GMTOFF30 calculation corrections and problems.
CONFIGV9 25.101 MEMLEAVE=10M SORTBLOCKMODE now set in CONFIGV9
UTILBLDP 25.098 %UTILBLDP(BUILDPDB=JES3 ... enhancement.
Major enhancements added in MXG 25.04.
TYPE21 25.083 Fix for support for APAR OA20077 Device Bytes TYPE21.
TYPEXAM 25.082 Support for XAM Release 3.6, many new data.
TYPENMON 25.073 Support for LPAR and IOADAPTR Nigel's NMON data.
SYSLOG 25.070 Support for SYSLOG file enhanced, all records output.
TYPENDM 25.081 Support for NDM-CD type 'NM' records creates NDMNM.
DALYTAPE 25.072 Sample tape reports from STC VTS SMF + MXGTMNT.
TYPERMFV 25.079 ZRBLCP dataset had only first LPARs observations.
TYPEDB2 25.064 Several QISE variables were wrong.
TYPEDB2 25.075 QBGL variables in DB2 V8.1 now supported, were wrong.
TYPETMS5 25.084 FILSEQ in TMS.DSNBRECD could be wrong, mult-vol-file.
ANALDB2R 25.068 SQL Text QW0141TX was not printed, coding error.
UTILBLDP 25.071 Products that need deaccumulation now protected.
UTILBLDP 25.065 Default list of ASUMxxx to be included, MXGINCL=.
VMXGRMFI 25.069 Service Class Names can be "wild-carded"
VMXGUSE 25.067 Revised to invoke _STY70; UTILBLDP recommended.
FORMATS 25.063 Additional SWAP reason codes added to $MG079SR.
Doc 25.078 List of MXG-issued USER ABEND values & source member.
Major enhancements added in MXG 25.03.
CONFIGV8 25.037 SORTEQUALS should NOT have been in CONFIGV8, V9 only.
TYPE119 25.035 Support for SMF 119 for z/OS 1.8 (INCOMPATIBLE).
TYPE1415 25.047 Support for APAR OA19502, SMF14KET Key Exchange Time
TYPE21 25.040 Support for APAR OA20077, uncompress read/write bytes
TYPEAIXT 25.039 Support for AIX Tapas-C performance data files.
TYPESAMS 25.055 Support for SAMS objects 2151,2226,2229 and 2231.
TYPETDS 25.052 Support for TDSLink Version 630 ZCOST datasets.
TYPECSM 25.050 Support for CrossSysplexManager user SMF record.
TYPSCOCR 25.034 Support for CopyCross (now VTF Mainframe 2.1.0) SMF.
VMXGDUR 25.044 Interval= QUARTER, SEMIANN, ANNUAL now supported.
TYPEHSM 25.042 Process HSM with different SMF IDs/different SYSTEMs.
ASUMTAPE 25.040 Uncompress read/write SMF21DBR/DBW kept in ASUMTAPE.
ASUMUOW 25.054 QWACSPCP,QWACTRET added to PDB.ASUMUOW for OTE.
ASUMCEC 25.053 PDB.ASUMCEC, PCTCPUBY GT 100%, DURATM LT CECINTRV.
BLDSMPDB 25.048 Corrections to BLDSMPDB, new SORTEDBY= option.
Major enhancements added in MXG 25.02.
MXG 25.02 was created to protect sites who set the NOSORTEQUALS
option (i.e., changed the SORTEQUALS default). NOSORTEQUALS causes
invalid data in ASUM70PR-built datasets.
CONFIGV9 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
VMXG70PR 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
Other New Support and corrections added in MXG 25.02:
ASMTAPEE 25.033 Support for ASMTAPEE ML-40 assembly under z/OS 1.8.
ANALRMFR 25.032 IRD corrections to RMF reports.
TYPE42DS 25.030 TYPE42DS had carried-forward IOCOUNT and other vars.
TYPE70 25.028 IORATEn per-engine I/Os corrected for IRD.
VMXGPRAL 25.028 Print All utility now compares all datasets in LIBs.
UCOMPSOE 25.028 Utility to compare SORTEQUALS and NOSORTEQUALS output
ANALFIOE 25.026 Divide by zero message protected.
Major enhancements added in MXG 25.01.
The MXG 24.24 Annual Version is VERY solid, with only these three
relatively minor corrections:
TYPENTSM 25.015 INCOMPAT MXG CHANGE for NTSM WEEKly requires action.
TYPE7072 25.013 PCTMVSBY in PDB.TYPE70PR was wrong if IRD was active.
ASUM70PR 25.001 NRICFCPU,NRIFLCPU were wrong if you have more than 1.
Other New Support and corrections added in MXG 25.01:
TYPEIMS7 25.006 Support for IMS Version 10 (INCOMPATIBLE) IMS log.
TYPEBVIR 25.011A Support for TS7700 SMF records.
TYPE7 25.025 Support for APAR OA19453 for 4-byte LOSTRECS count.
TYPE74 25.003 NREXPOSR was wrong for HyperPAV devices.
IMACICMR 25.007 Optional CICS CMRDATA, CMDUDATA/CMDDBCCP reversed.
IMACICOB 25.008 Optional CICS OMDBDB2LN now spelled as OMBDB2LN.
IMACICOM 25.008 Optional CICS OMMLN now spelled as OMMQLN.
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements in MXG 22.08" in CHANGES, above, for the major
items, then search Newsletters for V9 for all of the minor items.
MXG executes under SAS V8.2 and SAS V9.1.3, but MXG is no longer
supported under SAS V6. The "PDB" libraries written to by MXG
must have been created by V8/V9 (i.e, if ENGINE=V6 is shown in the
PROC CONTENTS output, you must convert that data library to the
current ENGINE=BASE by PROC COPYing it under SAS V8 or V9.
For SAS V9.1.3 on z/OS with Service Pack 4:
There are no reported errors, and MXG's CONFIGV9 now specifies
V9SEQ instead of V6SEQ. As V6SEQ does not support long length
character variables, it should not be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) is required
to be completely safe. No earlier Version 8's were supported.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it is now the default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG New-Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on Windows XP with SAS V9.1.3. But previous QA tests
have been run with all SAS releases on z/OS, SAS V8.2 and V9.1 on
Linux RH8 on Intel, with V9.1 on Solaris v2.8 on Model V880, and
V9.1 on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V8.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
Availability dates for the IBM products and MXG version required for
the processing of that product's data records:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990 8.8
MVS/ESA 4.2 Mar 29, 1991 9.9
MVS/ESA 4.2.2 Aug 15, 1991 9.9
MVS/ESA 4.3 Mar 23, 1993 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30, 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28, 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28, 1997 15.02
OS/390 2.4.0 Sep 28, 1997 15.06
OS/390 2.5.0 Feb 24, 1998 15.06
OS/390 2.6.0 Sep 24, 1998 16.04
OS/390 2.7.0 Mar 26, 1999 16.09
OS/390 2.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Oct 5, 2007 25.10
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DB2 6.1.0 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DFSMS/MVS 1.1 Mar 13, 1993 11.11
DFSMS/MVS 1.2 Jun 24, 1994 12.02
DFSMS/MVS 1.3 Dec 29, 1995 13.09
DFSMS/MVS 1.4 Sep 28, 1997 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998 16.04
DFSMS/MVS 1.5 ??? ??, 1999 16.04
DFSORT SMF V1R5 Mar 1, 2006 24.02
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
MQ Series 2.1.0 Oct 2, 1999 17.07
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
NETVIEW 3.1 type 37 ??? ??, 1996 14.03
NPM 2.0 Dec 17, 1993 12.03
NPM 2.2 Aug 29, 1994 12.05
NPM 2.3 ??? ??, 1996 15.08
NPM 2.4 Nov 18, 1998 17.01
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
DOS/VSE POWER V6.3.0 Dec 19, 1998 16.08
VM/ESA 2.0 Dec 23, 1992 10.04
VM/ESA 2.1 Jun 27, 1993 12.02
VM/ESA 2.2 Nov 22, 1994 12.06
VM/ESA 2.3 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 Jan 22, 2007 25.04
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Dec ??, 2004 22.08
IMS log 10.0 Feb 27, 2007 25.01
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
AS400 4.4.0 Sep 27, 1999 17.07
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 20.04
The Monitor for DB2 Version 4.0 22.10
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including cics/ts 3.1 22.08
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
The Monitor for MVS/ESA 3.0 - 19.19
The Monitor for CICS/TS V2.3 for CICS/TS 3.1 22.08
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 User SMF 13.06
Omegamon for CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for CICS V500 User SMF 18.01
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for IMS V550/V560 (ITRF) 25.05
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for VTAM V400 15.15
Omegamon for VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1+) 16.04
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 22.08
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 25.04
II. Incompatibilities and Installation of MXG 25.11.
1. Incompatibilities introduced in MXG 25.11:
a- Changes in MXG architecture made between 25.11 and prior versions
that can introduce known incompatibilities.
NTSMF Weekly/Monthly processing will fail on BLKBERRY dataset due
to new variable in the BY list. See Change 25.015 for required
actions you must take prior to running the Weekly/Monthly. The
incompatibility was introduced by Change 24.162 in MXG 24.06.
Change 25.189 revised %READDB2/%ANALDB2R when PDBOUT=, is null.
Now, ALL output datasets are written to //WORK, which was intended
when PDBOUT=null, but that did not always happen.
The error corrected was that a simple report with %ANALDB2R
failed if there was no //PDB DD name, because MXG tried used the
default DDnames, and did not force them to //WORK as desired.
That correction created a new exposure if you actually did have
a //PDB DD name, if you had changed DDNAME defaults with
%LET PDB2ACC or MACRO _LDB2ACC or _WDB2ACC,
and if you did not specify PDBOUT=PDB; Change 25.189 now caused
zero observations in PDB.DB2ACCT.
So if you want output datasets created by %READDB2/%ANALDB2R, you
must specify
PDBOUT=PDB (which works as documented, output all to //PDB), or
PDBOUT=YES (which outputs to the (tailored) default DDNames, or
PDBOUT=ZZZ (which outputs everything to ZZZ DDname).
Change 25.284, in MXG 25.25, corrected the original Change 25.189.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINST9 for
SAS Version 9.1.3 (JCLINST8 for SAS Version 8.2).
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
A change that alters any previously kept variable is
INCOMPATIBLE, and requires the new version to be used.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes in MXG 25.06 after MXG 24.24:
Dataset/
Member Change Description
Many 25.140 Support for z/OS 1.9 (COMPAT, minor SMF additions).
Many 25.179 %UPCASE,%LOWCASE,%STR,%BQUOTE,%QUOTE, etc.
ADOCDB2 25.172 Example to process DB2 datasets to separate DDNAMES.
ADOCDB2 25.148 Doc. How to create DB2ACCTB/DB2ACCTP in separate DDs.
ADOCITRM 25.149 Doc. Maps ITRM dataset names to MXG name.
ANALACTP 25.254 Sample report summarizes DB2 Package data to UOW.
ANALDB2R 25.202 VARIABLE QBnTDPIO NOT FOUND error corrected.
ANALDB2R 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
ANALDB2R 25.068 SQL Text QW0141TX was not printed, coding error.
ANALFIOE 25.026 Divide by zero message protected.
ANALRMFR 25.146 ERROR: NO DATASETS TO LOOKUP correction.
ANALRMFR 25.032 IRD corrections to RMF reports.
ASMTAPEE 25.033 Support for ASMTAPEE ML-40 assembly under z/OS 1.8.
ASUM70PR 25.303 Extraneous PROC PRINT from testing was removed.
ASUM70PR 25.270 INTERVAL=DURSET cannot be used.
ASUM70PR 25.163 Capacity Group summarization, PDB.ASUM70GC/ASUM70GL.
ASUM70PR 25.150 ASUM70PR created PCTCPUBY GT 100%, final fix?
ASUM70PR 25.150 ASUM70PR now supports INTERVAL/CECINTRV=SHIFT.
ASUM70PR 25.001 NRICFCPU,NRIFLCPU were wrong if there was more than 1
ASUMCEC 25.053 PDB.ASUMCEC, PCTCPUBY GT 100%, DURATM LT CECINTRV.
ASUMCELP 25.209 Duplicate observations in PDB.ASUMCELP eliminated.
ASUMHSM 25.113 HSM Summary enhanced with "HSM COMPLEX" HSMPLEX.
ASUMTAPE 25.300 Blank SYSTEM, missing DEVNR in PDB.ASUMTAPE fixed.
ASUMTAPE 25.040 Uncompress read/write SMF21DBR/DBW kept in ASUMTAPE.
ASUMUOW 25.121 Enhanced to keep each CICS segment response time.
ASUMUOW 25.054 QWACSPCP,QWACTRET added to PDB.ASUMUOW for OTE.
BLDSMPDB 25.048 Corrections to BLDSMPDB, new SORTEDBY= option.
COMPINTV 25.302 Capture/Compare ALL CPU times in 30/70/72/100/101/110
CONFIGV8 25.037 SORTEQUALS should NOT have been in CONFIGV8, V9 only.
CONFIGV9 25.267 VALIDVARNAME=V7 added to SAS CONFIGs.
CONFIGV9 25.101 MEMLEAVE=10M SORTBLOCKMODE now set in CONFIGV9
CONFIGV9 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
CONFIGW2 25.252 MXG updates for testing MXG Execution under WPS.
DALYTAPE 25.072 Sample tape reports from STC VTS SMF + MXGTMNT.
Doc 25.179 Use %LET MACxxxx= %STR( text ) ; to pass text.
Doc 25.078 List of MXG-issued USER ABEND values & source member.
EXITCICS 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
EXITCICS 25.017 SAS INFILE EXIT for compressed CICS SMF 110-1 data.
FORMATS 25.063 Additional SWAP reason codes added to $MG079SR.
IHDRIDMS 25.112 CA IDMS PerfMon support enhanced with "IHDR" exit.
IMACICMR 25.007 CMRDATA, CMDUDATA/CMDDBCCP reversed.
IMACICOB 25.238 OMEGAMON did NOT increase time-duration to 12 bytes.
IMACICOB 25.008 OMDBDB2LN now spelled as OMBDB2LN.
IMACICOM 25.008 OMMLN now spelled as OMMQLN.
ITRMTNG 25.262 233 DDU files to create ITRM definitions for TYPETNG.
MXGWPSV2 25.252 Revised JCL Procedure for MXG Execution under WPS.
READDB2 25.189 New PDBOUT=YES, old PDBOUT= changed, writes to WORK.
RMFINTRV 25.199 SMF70GIE now reset to 00/15 if SYNC59=YES is used.
RMFINTRV 25.177 ARRAY SUBSCRIPT OUT OF RANGE, 9999 LIMIT externalized
SYSLOG 25.070 Major revisions to SYSLOG program, will be renamed.
TIMEBILD 25.209 Optional SYNC59 timeshifting using TIMETABL.
TYPE102 25.306 Support for APAR PK38803 INCOMPAT SMF 102 IFCID 22.
TYPE102 25.306 IBM SMF 102 IFCID 22 APAR PK38803 wrong, supported.
TYPE102 25.129 IFCID=224 updated with QW0224PN and QW0224CI.
TYPE110 25.240 MCTSSCRL now tested vs MCTMNOPN for CICS Compressed.
TYPE119 25.119 SMF 119 from z/OS 1.8 caused INVALID DATA messages.
TYPE119 25.119 Support for SMF 119 for z/OS 1.8 (INCOMPATIBLE).
TYPE120 25.247 SM120SNT=2 (two heap ids) caused INPUT EXCEEDED.
TYPE122 25.287 Support for SMF 122, Tivoli Tape Allocation Manager
TYPE1415 25.047 Support for APAR OA19502, SMF14KET Key Exchange Time
TYPE21 25.083 Actual support for APAR OA20077 Device Bytes TYPE21.
TYPE21 25.040 Support for APAR OA20077, uncompress read/write byte
TYPE22 25.276 Support for APAR OA20043 Dynamic Volume Expansion
TYPE30 25.304 Support for APAR OA23679, BLKSIZE might be wrong.
TYPE30 25.260 MXG 25.10, INTRVLTM missing for TYPETASK='OMVS'
TYPE30 25.116 MXG 25.05, negative EXECTM, INTRVLTM, GMTOFF30 wrong.
TYPE30 25.089 GMTOFF30 calculation corrections and problems.
TYPE42 25.153 MXG 25.06 only, false INVALID TYPE42 SUBTYPE 5 error.
TYPE42DS 25.030 TYPE42DS had carried-forward IOCOUNT and other vars.
TYPE50 25.269 Support for OSA-MPC VTAM SMF 50 subtype 4 record.
TYPE70 25.211 ZIPACTTM, PCTZIPBY corrected for Dedicated zIIPs.
TYPE70 25.028 IORATEn per-engine I/Os corrected for IRD.
TYPE7072 25.237 LCPUWAIT was accidentally not kept in TYPE70.
TYPE7072 25.227 Variable RPRTCLAS now kept in TYPE72DL dataset.
TYPE7072 25.224 CPUTYPE tests are replaced with ZARCHMDE tests.
TYPE7072 25.205 Support for z/OS 1.9 54 CP engines per MVS, INCOMPAT
TYPE7072 25.176 Support for APAR OA18244, Blocked Workload z/OS 1.9.
TYPE7072 25.163 Support for Capacity Groups variables in TYPE70.
TYPE7072 25.135A LCPUCAP/LCPUCAPC Labels include "Hard CAP".
TYPE7072 25.013 PCTMVSBY in PDB.TYPE70PR was wrong if IRD was active.
TYPE70PR 25.051 NRIFACPU now populated for z990/2084 CPUTYPE.
TYPE71 25.143 SWAPrates were set missing if zero, now can be zero.
TYPE71 25.109 UIC variables changed meaning in z/OS 1.8.
TYPE74 25.140 APAR OA17070 supports CF Level 15 measurements.
TYPE74 25.140 Support for APAR OA17070 RMF 74-4 Coupling Facility
TYPE74 25.108 R748CSER/CTYP/CDML now kept in TYPE748 dataset.
TYPE74 25.003 NREXPOSR was wrong for HyperPAV devices.
TYPE78 25.236 Zero obs in TYPE78IO with Change 24.171 if z/OS 1.7.
TYPE78 25.141 APAR OA21799 prevents ABEND, SMF78HIX invalid.
TYPE80A 25.137 Support for unknown TOKDANAMs, prevents ABEND.
TYPE80A 25.131 Support for CRL PUBLISH and SET UID RACFEVNT 52, 79.
TYPE80A 25.131 Support for TOP SECRET (INCOMPAT) '90'x,'00'x VRSN.
TYPE80A 25.111 TYPE80xx variable TYPSTRNG wrong after Change 25.024.
TYPE82 25.257 Support for ISCF HCR7750 TKE Logging update.
TYPE85 25.279 Support for subtypes 38, 39 and 40 for ID=85 OAM.
TYPE85 25.234 New variables in OAM subtype 32-35 records.
TYPE89 25.198 SMF89HOF,SMF89DTO were incorrect due to typo.
TYPE89 25.138 Support for APAR OA20314 new SMF89LPN/SMF89ZNA.
TYPE92 25.192 New ID=92 ST=14 INPUT EXCEEDED if not a RENAME.
TYPE99 25.012 SMF 99 with only Trace, INPUT STATEMENT EXCEEDED.
TYPEAIXT 25.039 Support for AIX Tapas-C performance data files.
TYPEBTE 25.107 Support for CA Brightstor Tape Encryption SMF.
TYPEBVIR 25.011A Support for TS7700 SMF records.
TYPECIMS 25.230 IMF 4.2 PTF BQI0129 caused INPUT EXCEEDED error.
TYPECIMS 25.139 Support for IMF Version 4.3 (INCOMPATIBLE).
TYPECLAR 25.130 Support for Clarion Disk Array flat files.
TYPECSM 25.050 Support for CrossSysplexManager user SMF record.
TYPEDB2 25.291 DB2ACCT variable QWACUDCP CPU time added in DB2TCBTM.
TYPEDB2 25.265 DB2TCBTM Correction for DB2 V9.1, REQUIRED.
TYPEDB2 25.169 _RDB2ACC DB2 Parallel event "analysis" example.
TYPEDB2 25.097 Variable THREADTY blank if non-DDF transaction.
TYPEDB2 25.090 Support for PK37354 SMF 101 Subtype 4 in DB2 9.
TYPEDB2 25.064 Several QISE variables were wrong.
TYPEDB2 25.020 DB2STATS, QWS3, QWS4 may have reversed contents.
TYPEEVTA 25.255 Support for Action Software's EventAction user SMF.
TYPEEVTA 25.255 Support for Action Sofware's EventAction SMF record.
TYPEFERT 25.133 Support for Williams Data FERRET product user SMF.
TYPEHSM 25.042 Process HSM with different SMF IDs/different SYSTEMs.
TYPEIMS7 25.006 Support for IMS Version 10 (INCOMPATIBLE) IMS log.
TYPEITRF 25.286 Support for ITRF DCR77/DCR78 additions.
TYPEITRF 25.103 Support for IBM OMEGAMON TRF ITRF V550 and V560.
TYPEMQLG 25.280 Support for MQ V6 System Admin Accounting Queue Log.
TYPENDM 25.242 NDM record 'UC' is now output in NDMAE dataset.
TYPENDM 25.081 NDM-CD type 'NM' records now decided into NDMNM.
TYPENDM 25.014 No observations in NDMRT due to incomplete comment.
TYPENMON 25.229 NMON for AIX CPUnn records vary in number.
TYPENMON 25.110 Support for DISKBUSYn for all NMON Disk Monitoring.
TYPENMON 25.104 Full support for NMON, Nigel's Monitor for AIX/unix.
TYPENMON 25.073 Support for LPAR and IOADAPTR Nigel's NMON data.
TYPENTSM 25.282 Support for new NTSMF Objects, Database Mirroring.
TYPENTSM 25.253 Support for new NTSMF objects for MSSQL.
TYPENTSM 25.015 INCOMPATIBLE MXG CHANGE for NTSM WEEK/MONTH BUILDs.
TYPEORAC 25.127 No change in Oracle Version 10, but data is trash.
TYPEPDSM 25.245 CA PDSMAN diagnostic trace records filled //WORK.
TYPEPSYC 25.277 Support for PSYNCH/390 SMF record.
TYPEQACS 25.178 AS400 APAR QAPMDISK with LRECL=456 added new data.
TYPEQACS 25.132 Revisions to AS400 TYPECONF GDES variables.
TYPERACF 25.244 IRRDBU00 Unload '0200' record has two lengths.
TYPERACF 25.134 Support for IRRDBU00 record types 0560,0561,0562.
TYPERMFV 25.309 Support for RMF III CPD, Channel Path Data Table.
TYPERMFV 25.246 Updates for CPU Segmentation changes.
TYPERMFV 25.225 Variable ENCCPUT corrected with zIIP time removed.
TYPERMFV 25.204 CFI Segmentation eliminates RMF III skipped CF data.
TYPERMFV 25.191 Support for RMF Monitor III CFI table enhancements.
TYPERMFV 25.145 RMF III dataset ZRBLCP missing obs for many LPARs.
TYPERMFV 25.079 ZRBLCP dataset had only first LPARs observations.
TYPESAMS 25.055 Support for SAMS objects 2151,2226,2229 and 2231.
TYPESRDF 25.195 Support for EMC's SRDF/A user SMF record.
TYPESYNC 25.117 INVALID ARGUMENT due to incorrect HEX4/HEX3 formats.
TYPETDS 25.052 Support for TDSLink Version 630 ZCOST datasets.
TYPETIMS 25.271 Revisions for TMON/IMS support
TYPETMS5 25.126 Circumvention skip new TMC 'FF20'x Vol Def record.
TYPETMS5 25.084 FILSEQ in TMS.DSNBRECD could be wrong, mult-vol-file.
TYPETNG 25.243 Automatic PROC DELETE of UNKNOWN dataset removed.
TYPETNG 25.235 New Solaris, AIX, and many RedHat objects added.
TYPETNG 25.221 Support for VM Ware VSX Systems in CA NSM records.
TYPETNG 25.181 Support for CA NSM RedHat 4.01 Linux perf cube.
TYPETNG 25.181 Support for CA Unicenter NSM is in MXG "TNG" product.
TYPETPMX 25.239 Support for Thruput Manager SLM and DB2 data.
TYPEVMXA 25.151 180 Error _MPRCAPC not found, DEBUG prints removed.
TYPEVMXA 25.043 Reserved Change Number.
TYPEXAM 25.307 Extraneous PUT from testing removed.
TYPEXAM 25.115 Incorrect memory variables in XMUCDSYS in MXG code.
TYPEXAM 25.082 Support for XAM Release 3.6, many new data.
TYPSCOCR 25.034 Support for CopyCross (now VTF Mainframe 2.1.0) SMF.
UCICSCNT 25.120 CICS record counting separates Resource segments.
UCOMPSOE 25.028 Utility to compare SORTEQUALS and NOSORTEQUALS output
UPCMEMDZ 25.144 ASCII utility to determine memory available to MXG.
UPRINDOC 25.226 Utility prints NAME and LABEL of all variables.
UTILBLDP 25.196 Large &MACKEEP string caused strange results.
UTILBLDP 25.098 %UTILBLDP(BUILDPDB=JES3 ... enhancement.
UTILBLDP 25.071 Products that need deaccumulation now protected.
UTILBLDP 25.065 Default list of ASUMxxx to be included, MXGINCL=.
UTILCSV 25.197 %UTILCSV creates a CSV (or TAB) Delimited flat file.
UTILEXCL 25.256 Macro variable &MXGDEBUG revised for IMACEXCL plus!
UTILEXCL 25.193 MXG 25.08 ONLY: LABEL IMACICU3 NOT FOUND.
UTILLPDS 25.136 Utility to count used/defined PDS Directory Blocks.
VMAC110 25.041 Reserved Change Number.
VMACDB2 25.075 QBGL variables in DB2 V8.1 supported, were wrong.
VMXG70PR 25.293 SMF70GIE is now set from STARTIME=DURATM after shifts
VMXG70PR 25.028 OPTION NOSORTEQUALS caused errors in ASUM70PR.
VMXGDUR 25.044 Interval= QUARTER, SEMIANN, ANNUAL now supported.
VMXGINIT 25.231 Unresolved &ARRAYRMF is SAS V8.1 or WPS was used.
VMXGINIT 25.143 New MXGMISS macro variable changes TYPE71 SWAPrates.
VMXGPRAL 25.028 Print All utility now compares all datasets in LIBs.
VMXGRMFI 25.069 Service Class Names can be "wild-carded"
VMXGSUM 25.248 New &LNSUMOUT=8 will make all output to length 8.
VMXGUSE 25.067 Revised to invoke _STY70; UTILBLDP recommended.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 25.
====== Changes thru 25.309 were in MXG 25.25 dated Jan 28, 2008=========
Change 25.309 Support for RMF III CPD, Channel Path Data Table, creates
ASMRMFV new ZRBCPD dataset.
CLRMFV
ADOCRMFV The RMFV documentation in DOCRMFV and the documentation
EXZRBCPD in the CLRMFV CLIST (without any code changes in CLIST)
IMACRMFV have been updated to match ASMRMFV's updated.
VMACRMFV
VMXGINIT
Jan 28, 2008
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.308 SAS V8.2-V9.1 %MACRO compiler accepts %ELSE %THEN %DO;
ANALDB2R syntax, but the documented syntax is only %ELSE %DO;
VMACMVCI The SAS Language compiler never accepted ELSE THEN DO;
VMXGSUM In early tests of SAS V9.2, its %MACRO compiler rejected
Jan 28, 2008 the extra %THEN, so all three accidental, unintended MXG
Sep 16, 2008 %ELSE %THEN %DO statements have been corrected.
If you have an old member in your "USERID.SOURCLIB", the
error message you will get with SAS V9.2 will be:
ERROR: THERE IS NO MATCHING %IF STATEMENT FOR THE %THEN.
A DUMMY MACRO WILL BE COMPILED.
Thanks to MP Welch, SPRINT, USA.
Change 25.307 Debugging PUT printed _N_= COL=nnnn PRCAPM for every one
VMACXAM of those segments, but had no impact on output data.
Jan 25, 2008 Remove the PUT statement after WHERE ('PRCAPM').
Thanks to Rodger Foreman, TransUnion, USA.
Change 25.306 Change was in error, did not support PK38033, and was
VMAC102 replaced by Change 26.011 which does support the APAR.
Jan 23, 2008 And the original change text was WRONG, as there was
Feb 8, 2008 NOTHING wrong with IBM SMF 102 IFCID 22 with PK38803
records; the records matched the DSECT which I misread.
Change 25.305 Error in %UTILBLDP with USERADD=TMNT/nnn + BUILDPDB=YES.
UTILBLDP Because TMNT processing is already in BUILDPDB, there was
Jan 23, 2008 special handling in the USERADD= logic, but in this case
Jan 27, 2008 it incorrectly didn't create the MACRO _IDTMNT nnn % that
it should have, so, while all TMNT datasets were created,
they all had zero observations, unless you had defined
your TMNT Record ID _IDTMNT in IMACKEEP/IMACTMNT.
The logic in UTILBLDP is corrected for all USERADDs,
whether or not they are already in BUILDPDB:
USERADD=TMNT/nnn, creates MACRO _IDTMNT nnn %
which will override any IMAC tailoring.
USERADD=TMNT, does not create _IDTMNT, but ensures
TMNT records are processed.
-Jan 27: Added support for USERADD=100 101 alias for DB2.
-In testing the UTILBLDP invocation in the new COMPINTV, I
had %MACRO errors about non-numeric in a %EVAL, (whose
clarity may be a separate SAS issue!), but which were the
result of incorrect code ordering in my COMPINTV program.
When %UTILBLDP has MACKEEPX= argument text with old-style
macros that you want to redefine AND execute in this one
step, then your MACRO _XXXXXXX ... % statements must
be located after the %UTILBLDP(); statement and before
the %INCLUDE statement that executes the UTILBLDP output:
statement that executes the UTILBLDP output:
%UTILBLDP(MACKEEPX= MACRO _ETY70 _SETTIME %, .... );
RUN:
MACRO _SETTIME STARTIME=FLOOR(STARTIME/900); %
RUN;
%INCLUDE INSTREAM;
If the old style macros are defined before %UTILBLDP is
executed, then they are expanded inside the macro
language when the %MACRO UTILBLDP is being compiled,
which can result in unexpected failures. If you move the
definition to after %UTILBLDP, only the name of the macro
is passed to the UTILBLDP output which works as expected.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 25.304 APAR OA23679 documents possible errors in BLKSIZE in SMF
VMACEXC1 30 records when DDCONS=YES is specified. Since MXG has
Jan 23, 2008 ALWAYS recommended DDCONS=NO and NEVER to use DDCONS=YES,
this shouldn't have impact. But when YES is specified,
IBM now says the consolidated SMF 30 record contains the
first non-zero BLKSIZE value from those DDs in SMF30BSZ,
the original 4-byte blocksize field, but the newer 7-byte
SMF30BXS blocksize field, contains the BLKSIZE value from
the last DD in the consolidation, which could be valid or
zero. MXG stored SMF30BSZ into BLKSIZE, but then INPUT
BLKSIZE from SMF30BXS when it existed, even when zero.
Now, BLKSIZE is set to SMF30BXS ONLY when it is larger
than SMF30BSZ.
Change 25.303 -Extraneous PROC PRINT from testing was removed.
VMXG70PR -Calculation of LPARCPUS could be non-integer value, for
Jan 22, 2008 example, 11.99995682 instead of 12. Algorithm refined.
Jan 28, 2008
Thanks to Clayton Buck, UniGroup, USA.
Thanks to William Wai Lun WONG, HSBC, HONG KONG.
====== Changes thru 25.302 were in MXG 25.25 dated Jan 21, 2008=========
Change 25.302 Compare all CPU variables from SMF 30,70,72,100,101,110s.
COMPINTV Single pass of SMF creates only the needed datasets with
UTILEXCL a "fast read" of SMF records keeping only the CPU and key
Jan 21, 2008 variables to minimize the run with a tailored %UTILBLDP
Jan 27, 2008 and MACKEEPX overrides to create two summary datasets:
Jan 30, 2008 PDB.INTVSRVC by SYSTEM STARTIME SRVCLASS 30+72
PDB.IN307072 by SYSTEM STARTIME 30+70+72
PDB.INALLCPU by SYSTEM STARTIME 30+70+72+100+101+110
Fast read: 6 GB SMF data, 2 Minutes CPU, 10 Min Elapsed
The type 30 SMF interval and type 72 RMF service class
create the PDB.INTVSRVC with CPU times by service class.
Those data and the CPUACVTM from TYPE70 are combined into
the PDB.IN307072 SMF+RMF CPU time for each interval. Then
the CICSTRAN and DB2ACCT transaction CPU times plus the
interval CICDS dispatcher and DB2STATS statistics CPU
times are added from the 100, 101, and 110 records to
create the PDB.INALLCPU with ALL possible CPU variables,
summed for each SYSTEM for each STARTIME.
Several PROC MEANS summary output reports are printed.
The SRVCLASS-level SMF30 and RMF72 summary CPU times
should match closely for most service classes, but there
can be significant differences in which "SRVCLASS" CPU
time is recorded. For example Enclave CPU time in SMF
may be in the SRVCLASS of the address space that started
the enclave, but in RMF that same enclave CPU time gets
put in the SRVCLASS where that enclave was classified.
And we've seen enclaves in two SRVCLASS in SMF30 while
spread across three SRVCLASS in RMF72. It can get messy!
The STARTIME-level interval summary should match RMF and
SMF totals, for the CPU fields that we expect to match,
and will show how much of that CPU time is captured in
the DB2 and CICS interval data as well, but its accuracy,
and the accuracy of the SRVCLASS-level data is dependent
on the synchronization of your SMF and RMF data.
The MACRO _SETTIME default expects 15 minute intervals
and SYNC(0), but can be tailored to your intervals.
You can get the totals of all CPU times for all of SMF
records in a single output observation per SYSTEM by
setting STARTIME to a single value for all records.
But the summary of the CICSTRAN and DB2ACCT times
can always be skewed by a long-running transaction,
or if SYNC59 is in the data (because not all CPU
records obey SYNC - RMF/SMF 30 does, CICS doesn't.
Jan 30: If you use COMPINTV and have an IMACEXCL member,
COMPINTV fails when it sees the second _VCICTRN
definition in your IMACEXCL. If you will insert
MACRO _VCICTRN _VCICTRN %
immediately before the existing MACRO _VCICTRN,
then COMPINTV will not fail. And, fortunately,
by accident, the MACRO _VCICTRN defined in the
MACKEEPX in UTILBLDP will be used for CICSTRAN,
(and it's required for the rename of STRTTIME to
STARTIME and to minimize disk space), because
MACKEEPX is instanced after IMACEXCL was read.
Syntax corrected in Change 26.020.
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.301 Due to typos that had DB where OB should have been, all
VMAC102 of the QW1145OB-QWF145OB variables were wrong (they had
Jan 21, 2008 the DB database value instead of the OB Object value).
Thanks to Giuseppe Giacomodonato, E.P.V. Technologies, ITALY.
Change 25.300 PDB.ASUMTAPE could have blank SYSTEM and VOLSER, DEVNR
ASUMTAPE missing when the SYSLOG Mount and Keep messages had the
Jan 21, 2008 same timestamp, and the Keep was seen first. Adding the
variables SMFTIME SYSLTEXT forces the KEEP to be first
to complete the prior event, but adding .001 seconds to
IF SYSLTMNT GT . THEN EVENTIME=SYSLTMNG+.001;
was also needed to force the correct sequence.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.299 Type 42 Subtype 18 CF Cache Partition Summary Section for
EXTY42P3 Directory/Element Ratio Data now creates new dataset:
IMAC42 DDDDDD DATASET Description
VMAC42 TY42P3 TYPE42P3 RLS CF DIRECTORY/ELEMENT RATIO
VMXGINIT which had been added in z/OS 1.8 but overlooked.
Jan 21, 2008
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.298 ADOCxxxx members that existed have been updated with new
ADOCs variables. New ADOCS member lists the VMACxxxx products
Jan 20, 2008 for which an ADOC member does not exist.
Change 25.297 Change 25.196 caused ERROR: CHAR OPERAND IN THE %EVAL ...
UTILBLDP when either or both MACFILE and MACKEEP were used and had
Jan 19, 2008 more than 65 characters of text.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.296 All ADOCxxxx members were updated with current CONTENTS.
ADOCs
Jan 19, 2008
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 25.295 The COMPALL program compiles all of the VMACs for all SMF
COMPALL records in a single data step, and is back in MXG's QA
VMACIPAC tests, now that it can be compiled! It was used in early
VMACOMCI MXG Versions, testing only the IBM SMF records, by about
VMACSAMS Version 3 (1987!), it needed more virtual storage than I
Jan 19, 2008 could get back then, and it was set aside. It now brings
in all of the VMACs for all IBM and USER SMF records, and
it detected numeric-character variable conflicts in one
temp variable that was renamed in VMACIPAC, and two kept
variables were renamed to avoid the exposure to error,
if you were to add these and certain other SMF records to
your BUILDPDB job:
-VMACSAMS. Variable CLUSTR replaces numeric CLUSTER.
-VMACOMCI. Variable DIFTYPEF replaces char DIFTYPE.
The current COMPALL requires an 1150 MB Region on z/OS.
====== Changes thru 25.294 were in MXG 25.12 dated Jan 17, 2008=========
Change 25.294 Label PARTNCPU='TOTAL*NUMBER OF*CPUS*IN THE CEC' replaces
VMAC7072 the previous confusing "CPUS IN THE PARTITION" text that
VMXG70PR goes back to the days when we "physically partitioned" a
Jan 17, 2008 "hardware platform". The variables PARTNCPU PLATCPUS,
NUCPSCPU and temp variable NRCPSCPU have always counted
the CP/CPU engines in this CEC/CPC/platform/box/etc.
If there are no LPARNAME='PHYSICAL' records in TYPE70PR
(because your outsourcer turned them off?), the variables
PARTNCPU, PLATCPUS, NUCPSCPU and CPCNRCPU will be zero.
And the specialty engine counters NRIFACPU, NRZIPCPU, etc
will also always be zero. And, in the ASUM70PR/ASUMCEC
datasets, only your own LPARn variables are populated.
Finally (?), CPCMSU in PDB.RMFINTRV is also zero.
Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.
Change 25.293 SMF70GIE is now set from STARTIME+DURATM after SYNC59 to
VMXG70PR provide a more stable and consistent value for the
Jan 17, 2008 expected end of the interval. See Change 25.270.
Change 25.292 Internal logic was revised so when INTERVAL= is used, the
ANALRMFR variables LRDY00-LRDY11 are added to the MEAN= parm for
Jan 17, 2008 Cpu Reports.
Dollarsigns were needed in the below array definitions.
-ARRAY INICT05 $ STFBIT05(' ') ;
-ARRAY INICT05 $ STFBIT06(' ') ;
-Also, updated for 54 engines z/OS 1.9.
Thanks to Clay Duncan, Toyota, USA.
Thanks to Jerry Cobb, American Century, USA.
Change 25.291 DB2ACCT variable QWACUDCP, CPU time in DB2 User Functions
VMACDB2 is now included in MXG variable DB2TCBTM, as documented
Jan 17, 2008 in DB2 Technical Note 4 (PAR.TASKS) in Newsletter FIFTY.
Change 25.290 Variable JOBCLASS is $8 in JES3 and $1 in JES2, but MXG
BUIL3005 had INPUTs with both lengths, and that caused SAS WARNING
VMAC26J2 messages that the variable's length was CHANGED; these
VMAC26J3 warnings will set Return Code 4 in SAS Version 9.2, so
VMAC30 this change revised how MXG handles JOBCLASS for JES3
Jan 17, 2008 to keep the full 8-byte length. The contents of the
Jan 20, 2008 SPIN library are also changed; JOBCLASS is no longer kept
in SPIN26, and JOBCLAS8 is kept instead of JOBCLASS in
SPIN30_1, SPIN30_4, and SPIN30_5.
Note: This change was revised in MXG 25.25.
Do NOT use MXG 25.12 with JES3 BUILDPD3.
Thanks to MP Welch, SPRINT, USA.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.289 -Nigel's Monitor for AIX/LINUX variable NRCPUS in NMONINTV
VMACNMON dataset was one-tenth correct; the INFORMAT 6.1 should be
Jan 17, 2008 6.0. The AAACPU2 count was correct in NMONAAA dataset.
-Support for ERROR: records, sort of: they are printed on
the log in full when read.
Thanks to Michael W. Wolke, Boeing, USA.
Thanks to Steve Olmstead, Northwestern Mutual Trust, USA.
Change 25.288 Variable SMF70GJT is already on Local zone, so the adding
VMAC7072 of the GMT offset in MXG created incorrect datetimes.
Jan 16, 2008 Jan 26: a second instance was removed.
Jan 26, 2008
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.287 Support for SMF 122, Tivioli Allocation Record creates
EXT122IT six new datasets:
EXT122AL DDDDDD DATASET DESCRIPTION SUBTYPE
EXT122WA
EXT122FA T122IT T122INIT ATAM ASID INIT/TERM 0,4
EXT122DY T122AL T122ALOC ATAM SUCCESSFUL ALLOCATE 1
EXT122ON T122WA T122WAIT ATAM WAIT/NOHOLD/ALOCFAIL 2,3,5
IMAC122 T122FA T122FAIL ATAM VARY ONLINE FAILURE 6
TYPE122 T122DY T122DYNA ATAM UNSUPPORTED DYNALLOC 7
TYPS122 T122ON T122VONL ATAM VARY ONLINE TO WAIT 8
VMAC122
VMXGINIT
Jan 16, 2008
Change 25.286 Support for new ITRF variables in subtype '10'x and '18'x
EXITRCRG records and new subtype '20'x created by ITRF DCR77/DCR78
EXITRCRG (PTFs UA36089,UA37073). New variables added:
IMACITRF Dataset New Variables
VMACITRF ITRFMSG
VMXGINIT RECTOK ='FULL*RECOVERY*TOKEN'
Jan 16, 2008 IMSID ='IMS*ID'
COMN ='COMMITS*DURING*THIS*SCHEDULE'
OASN ='ORIGIN*APPLICATION*SEQUENCE*NUMBER'
SUSEC ='SERVICE*UNITS*PER*SECOND'
ITRFDB2
CPUDB2TM='IN DB2*CPU*TIME'
New dataset ITRFCRGN, 'CONTROL REGION CPU TIME', which is
created once each 24 hours with the daily total CPU Time
in the IMS Control Region:
Dataset New Variables
ITRFCRGN
CPUCRGTM='CONTROL*REGION*DAILY*CPU TIME'
IMSNAME ='IMSID*FOR THE*IMS SYSTEM'
INTBTIME='INTERVAL*START*DATETIME'
INTENDTM='INTERVAL*END*TIME'
The IMSNAME is retained from the prior ITRF record, as
the '20'x record contains only the time fields.
Change 25.285 The VALIDVARNAME=V7 option added by Change 25.267 to WPS
CONFIGW2 CONFIGW2 file caused ERROR: OPTION VALIDVARNAME NOT KNOWN
Jan 15, 2008 so it has been removed from CONFIGW2 member. That option
is the internal WPS default, but the option name is not
supported by WPS.
Change 25.284 Change 25.189 was not completely implemented.
ANALDB2R -Using %ANALDB2R with new PDBOUT=YES printed COPIED TO YES
READDB2 and did not perform as documented; an additional test for
VFMT102 AND &PDBOUT NE YES was required to support the new YES.
Jan 16, 2008 But then using PDBOUT=YES caused messages:
ERROR: Libname PDB is not assigned.
ERROR: Libname _VDB2A is not assigned.
when no //PDB DD or LIBNAME PDB was allocated.
That is an error. When PDBOUT=YES is specified, it
writes all DB2 output datasets to their default (or the
tailored) DDname, and PDB is the default for sorted DB2
datasets.
-But then using no PDBOUT operand, which should write
all DB2 output to //WORK, still caused
ERROR: Libname PDB is not assigned.
because READDB2 had an old segment of code that should
have been removed by Change 25.189, now corrected, so
that PDBOUT= null does NOW write only to //WORK.
-Warnings about T102S017 DOES NOT EXIST are removed with
enhancements made in VFMT102.
Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA.
Thanks to Robert Carballo, Office Depot, USA.
Change 25.283 An extraneous ); was inserted in %UTILBLDP output (on a
UTILBLDP separate line several lines after %LET EPDBOUT= text) if
Jan 15, 2008 both EXPDBOUT= and INCLAFTR= were specified.
Thanks to Robert Carballo, Office Depot, USA.
Change 25.282 Support for seven new NTSMF Objects:
EXNTCICP DDDDDD DATASET DESCRIPTION
EXNTCILI NTCICP CITRIXCP CITRIX CPU UTILIZATION MGMT USER
EXNTHSMG NTCILI CITRIXLI CITRIX LICENSING
EXNTHSRV NTHSMG HEALMGMT HEALTH SERVICE MANAGEMENT GROUPS
EXNTOPSM NTHSRV HEALSERV HEALTH SERVICE
EXNTSECT NTOPSM OPSMGRCN OPSMGR CONNECTOR
EXNTSQDM NTSECT SECTIKAU SECURE TICKET AUTHORITY
IMACNTSM NTSQDM SQLDATMI SQLSERVER:DATABASE MIRRORING
VMACNTSM or MSSQL:DATABASE MIRRORING
VMXGINIT The SQLSERVER and MSSQL Database Mirroring records are
Jan 15, 2008 both output in SQLDATMI dataset. The MSSQL records will
populate variable SQLDBNAM='SQL*SERVER*DATABASE*NAME'
while SQLDBNAM will be blank in the SQLSERVER records.
Thanks to Roger Zimmerman, Hewitt Associates, USA.
Change 25.281 Cosmetic. If RMFINTRV definitions fall thru to create any
VMXGRMFI work in "OTHER", a new MXG NOTE alerts you to the SYSTEM
Jan 15, 2008 and SRVCLASS that fell thru your workload definitions.
Jan 28, 2008 This is not an error, but it is recommended that all of
your work be mapped to a unique workload variable in the
RMFINTRV dataset. The first ten workload names that fell
thru are printed on the SAS log.
-Cosmetic. Some ERROR:NEGATIVE CPU OVERHEAD for RMF 70-72s
were in intervals in which a Policy Activation occurred,
and data for those intervals are always wise to ignore.
There is no flag bit that activation occurred during this
interval, but the time of policy activation, R723MTPA, is
now printed along with STARTIME and DURATM of the raw RMF
record, so you can see if there was a policy activation
to blame. Variable CPUOVHTM in PDB.RMFINTRV will be
negative, non-missing value. to identify the intervals
that printed that log message.
This message may also be seen in intervals in which the
number of hardware CPUs was altered.
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.280 Support for Websphere MQ V6 System Admin Account Queue
EXMQLGMD MQMD Structure in MQ Accounting Log non-SMF file creates
IMACMQLG the new MQLGMQMD Dataset with the Descriptor fields for
TYPEMQLG each event. This structure is documented on page 51 in
TYPSMQLG Chapter 7.
VMACMQLG
VMXGINIT
Jan 11, 2008
Change 25.279 SMF 85 subtypes 38, 39, and 40 now create three datasets
EXTY85RE TYPE85RE, TYPE85IB, and TYPE85TR. Archaic test records
EXTY85IB from year 2000 with shorter records were protected.
EXTY85TR
VMAC85
VMXGINIT
Jan 10, 2008
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.278 PDB.TYPE70 variables PCTZIBYx were created in MXG 24.02
VMAC7072 but were accidentally not kept after MXG 24.06; they are
Jan 10, 2008 now reinstated. PCTZIBYx/PCTIFBYx are the "MVS" values,
variables PCTCIBYx/IFATYPE are "LPAR" values for zIIP and
zAAP usage as noted in Change 24.184.
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.277 Support for PSYNCH/390 SMF Record from M-Tech product
EXPSYC39 creates PSYNC390 dataset.
FORMATS Only one of the four flag variables will have a value in
IMACPSYC one record, but it's now too late to change the MXG code.
TYPEPSYC May 5: Formats were updated.
TYPSPSYC
VMACPSYC
VMXGINIT
Jan 10, 2008
May 5, 2008
Thanks to Joe Faska, Depository Trust, USA.
Change 25.276 Support for APAR OA20043 DFSMS DYNAMIC VOLUME EXPANSION
VMAC22 adds these two variables:
Jan 9, 2008 SMF22CYL='DEVICE*HIGH*CYLINDER'
SMF22PCP='DEVICE*HIGH*CYLINDER*PREVIOUS'
to the TYPE22_A dataset.
Change 25.275 -Strange error messages can occur if you did not update
VMACTPMX your IMACTPMX member with your SYSPLEX and SYSTEM names
Jan 4, 2008 and mapping tables; messages like these:
Jan 9, 2008 >>ERROR>> MXG/SAS VARIABLE TPMXPLEX NOT ASSIGNED
CORRECTLY USING LOCAL PROC FORMAT $MXTPMPX IN
>>ERROR>> EXIT MEMBER MXG.PROD.USERID.SOURCLIB(IMACTPMX).
>>ERROR>> RUN ABORTED. CORRECT THE FORMAT AND RESTART.
resulted when data from SYSTEMs not in IMACTPMX was read.
Adding an entry for each SYSPLEX and for its SYSTEMs in
IMACTPMX solved those errors.
-Variable JXJBSJ4 was incorrectly input as $EBCDIC, but it
is a hex flag field, now input and formatted $HEX8.
Jan 9: A debugging PUT was removed, VGETJESN %INCLUDEd to
create variable JESNR from JCTJOBID for subtype=5.
The current level: TM V6R1.2 at PTF TMT6116; the
fix for the truncated records is APAR TR61390, but
you are at PTF TMT6118, the APAR is TR61391.
Thanks to James D. Lieser, UHC, USA.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.274 A GDG member that had DSNAME .VnnnnGOO' (alpha oh) caused
VMAC6156 INVALID DATA warning message when MXG INPUT the oh's as a
Jan 2, 2008 numeric. Adding the double question mark modifier to the
INPUT function eliminates the warning and causes GENNO to
be a missing value:
IF ENTTYPID='H' THEN DO; /*GDG, GET GOOVO GEN/VER NUM*/
GDGLEN=LENGTH(ENTRNAME);
VCK =SUBSTR(ENTRNAME,GDGLEN-2,1);
DOTGCK=SUBSTR(ENTRNAME,GDGLEN-8,2);
IF DOTGCK='.G' AND VCK='V' THEN DO;
GENNO=INPUT(SUBSTR(ENTRNAME,GDGLEN-6,4),?? 4.);
VERNO=INPUT(SUBSTR(ENTRNAME,GDGLEN-1,2),?? 2.);
END;
END;
Scott had provided this elegant alternative that uses the
TRANSLATE and SCAN functions, worthy of sharing:
IF ENTTYPID='H' THEN DO; /*GDG, GET GOOVO GEN/VER NUM*/
LASTNODE = SCAN(ENTRNAME,-1,'.');
IF TRANSLATE(LASTNODE,'%%%%%%%%%%','0123456789') =
'G%%%%V%%' THEN DO;
GENNO=INPUT(SUBSTR(LASTNODE,2,4),4.);
VERNO=INPUT(SUBSTR(LASTNODE,7,2),2.);
END;
END;
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.273 APAR PK38803 incompatibly alters SMF 102 IFCID 22 Record.
VMAC102 -These variables were INPUT as fixed length text, but they
Jan 2, 2008 can be longer, and can be relocated in the SMF record.
MXG now detects the new OFFSETs and INPUTs $VARYING32:
Variable Fixed Length Label
QW0022CN $EBCDIC18. /*TABLE*CORRELATION*NAME*/
QW0022CR $EBCDIC8. /*TABLE*CREATOR*/
QW0022TN $EBCDIC18. /*TABLE*NAME*/
QW0022AC $EBCDIC8. /*QW0022XC:ACC INDEX CREATOR*/
QW0022AN $EBCDIC18. /*qw0022XN:INDEX NAME*/
(Note: 22AC and 22AN were original DSECT names)
Debugging is enabled for the first 10 instances that have
varying length fields on the MXG log, so I can validate.
-Records with QW0022PL=. have many missing values, and the
$CHAR vars formatted with $HEX have '20'x vice '00'x. The
obs was created from a second record, after a legitimate
instance with 6 observations, and has only R1O segment.
-_S102022 SORT MACRO revised and tested for dupe removal.
Jan 23, 2008: Change 25.306 is now required for PK38803.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.272 The Group Capacity Name SMF70GNM is now populated only if
VMAC7072 bit 1 of SMF70PFL is ONE, as that bit indicates this LPAR
Dec 21, 2007 is part of a capacity group of that name. If bit 1 is
zero, SMF70GNM is blanked, because some z/OS 1.8 data had
non-blank SMF70GNM when bit 1 was zero. While I could
have created a separate variable for bit 1 to identify
this LPAR is in a capacity group, with this change there
is no need for a second variable; now, IF SMF70GNM GT ' '
then this LPAR is in that Capacity Group, otherwise not.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.271 Corrections for TMON/IMS support.
VMACTIMS -CM5612TM is a datetime variable, now format DATETIME21.2.
Dec 21, 2007 -CMCOMP, CPCOMP are formatted HEX8.
-XXTOKN Token variables are LENGTH 5 and HEX8 format.
-CMGMTA value's second division by 4096 was removed.
-ENDTIME is already on Local time, its GMT correction was
removed.
-These variables were incorrectly input as &PIB.8.6 vice
&PD.8.6, causing too-large values when non-zero:
TIMSCH: CMTMEIO CMTMEPL CMMINT CMMPOL CMMSCH
TIMSCM: CMTMEIO CMTMEPL CMMINT CMMPOL CMMSCH
TIMSCN: CNTMEIO CNTMEPL CNMINT CNMPOL CNMSCH
TIMSCP: CPTMEIO CPTMEPL CPMINT CPMPOL CPMSCH
TIMSCT: CTTMEIO CTTMEPL CTMINT CTMPOL CTMSCH
These fields were correctly documented as Packed in the
DSECT, but overlooked originally as they all were zero.
-Variables input &PIB.8.6 that are NOT GMT offsets are NOT
then divided by 4096: e.g., CTRSPTME when CTSDATE and
CTSPDATE are both non-missing matches their delta.
However, when CTSDATE is missing, CTRSPTME contains
the value of CTSPDATE shifted right by three nybbles,
i.e. a very large and very invalid data.
This problem will be passed to Landmark for correction,
but is circumvented by MXG setting CTRSPTME to missing.
-Five CPU variables are documented on the DSECT as (MILS)
for milliseconds and have always been input as &PIB.4.3:
CHCUMCPU CMCUMCPU CNCUMCPU CPCUMCPU CTCUMCPU
-But eleven REGION*CPU*TIME variables have no clue as to
their decimal place location:
CHCTCPUT CHDBCPUT CHDLCPUT CHIRCPUT CHCQCPUT
CJTXNCPU
CNCTCPUT CNDBCPUT CNDLCPUT CNIRCPUT CNCQCPUT
I have arbitrarily input them as &PIB.4.3 (MIL) but this
must be validated.
-These variables are assumed input of &PIB.4.6 to be like
their xxDUR counterparts, but this must be validated:
CMSQ6GM CMACCQ6 CNSQ6TM CNACCQ6 CPSQ6GM CPACCQ6
CUSQ6GM CUACCQ6
Thanks to Warren Waid, JC Penny, USA.
Change 25.270 For ASUM70PR, IMACRMFI tailoring with INTERVAL=DURSET
ASUM70PR can NOT be used, and output datasets created with that
VMXG70PR tailoring will be invalid if STARTIME is changed in your
Dec 19, 2007 IMACRMFI member and you used the default ASUM70PR, which
specified INTERVAL=DURSET as its default prior to this
change. You must use INTERVAL=HOUR, QTRHOUR, etc. in
in your %VMXG70PR invocation in your ASUM70PR member to
specify the desired interval.
For RMFINTRV, you can still use IMACRMFI/DURSET, because
it is a per-SYSTEM dataset, but I still recommend you use
INTERVAL=xxxx and not use IMACRMFI, for clarity.
Here's the problem with DURSET/IMACRMFI for ASUM70PR:
Because ASUM70PR summarization combines SYSTEMs that
can have different STARTIME, it uses and resets the
value in SMF70GIE. When I detect INTERVAL=DURSET, I
have to detect if STARTIME was changed in IMACRMFI, and
if so, then MXGDURTM (that you added in your IMACRMFI
per Change 25.150) must be added to STARTIME to create
SMF70GIE. I though I could use this code:
OLDSTART=STARTIME;
_DURSET;
IF STARTIME NE OLDSTART THEN DO;
and that worked with the first test case.
However, I now discover that the test will always fail
if STARTIME is already exactly on the interval, i.e.
STARTIME=DHMS(DATE,HOUR,0,0); for HOURly intervals will
equal OLDSTART when OLDSTART is exactly on the hour.
Since I can only detect some, but not all, changed obs,
I cannot support IMACRMFI and DURSET in ASUM70PR.
This is a rare problem; using INTERVAL=value in the
ASUM70PR invocations of %VMXG70PR and RMFINTRV invokes
of %VMXGRMFI is self-documenting and works safely,
so this change is mostly this change text and updates
to the INTERVAL= documentation comments in the cited
members.
Change 25.269 Support for SMF 50 subtype 4 OSA-MPC VTAM record adds new
EXTY50 observations with ATTCHTYP=4 to TYPE50 dataset, but only
FORMATS if this DEV had activity during this interval; the logic
VMAC50 that deletes zero-activity intervals is in the EXTY50
Dec 22, 2007 if you should want to output all of those observations.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
====== Changes thru 25.268 were in MXG 25.11 dated Dec 7, 2007=========
Change 25.268 The date in MXG 25.11 was typo'ed as year 2006 in several
AAAAAAAA members, but the member CHANGES was correct with 2007.
COPYRITE The dates were corrected and the ftp site was refreshed
Dec 7, 2007 on Tuesday with the Dec 7, 2007 date.
Thanks to Mike Ryan, Acxiom, USA.
Change 25.267 If the option VALIDVARNAME=V6 is set in your site's SAS
AUTOEXEC options, a temporary variable in VMAC78 caused
AUTOEXEU ERROR: The variable named N78HCNTCN contains more than
AUTOEXEW 8 characters
CONFIGV8 because the V6 value restricts the length of variable's
CONFIGV9 names to be 8 bytes or less.
VMAC78 MXG tests with the default VALIDVARNAME=V7, which allows
Dec 7, 2007 variable names to be up to 32 characters.
But almost all MXG variables will always be 8-bytes or
less, because I think shorter, encoded, albeit cryptic,
variable names are easier for PROGRAMMERs to work with.
But because some new open systems code was written with
their long names, and because change the default in the
MXG members can do no harm but can avoid future errors,
VALIDVARNAME=V7 has been added to MXG CONFIGVx and the
AUTOEXEx members.
Thanks to Andreas von Imhof, Rabobank Nederland, THE NETHERLANDS.
Change 25.266 The MXG ERROR.VMAC110... messages are updated to print
VMAC110 the CICS/TS 3.2 expected values.
Dec 6, 2007
Thanks to MP Welch, SPRINT, USA.
Change 25.265 Required for DB2 Version 9.1, DB2TCBTM correction.
VMACDB2 DB2TCBTM could be significantly less than it should be in
Dec 7, 2007 non-rollup observations in DB2ACCT. The CPU time delta
QWACEJST-QWACBJST was NOT included in DB2TCBTM when
QWACBJST was zero (and DB2PARTY NE 'R') in DB2ACCT.
And the loss has only been reported at sites with zIIP
engines for their DB2 systems.
Prior to DB2 V1.9, IBM DSNWMSGS documentation noted that
QWACBJST=0 meant that CPU timing was in error, and so MXG
had always NOT included that QWACEJST-QWACBJST delta in
MXG's DB2TCBTM variable. Accidentally, DB2TCBTM for the
Rollup Records (i.e., DB2PARTY='R") has always included
the QWACEJST when QWACBJST=0.
Note that
DB2TCBTM=SUM(DB2TCBTM,QWACSPCP,QWACTRTE);
is the final value output in DB2ACCT dataset.
Now, IBM DB2 Level 2 Support has confirmed in a reply to
an MXG site that QWACBJST=0 is valid and the QWACEJST in
those records should be included in DB2TCBTM, adding that
"If we have an agent running 100% on a zIIP, QWACBJST
will be zero." It was only after that reply from IBM DB2
Support that I looked to see the CPU timing not is not in
DSNWMSGS in the DB2 V 1.9 Macro Library.
To see if this change impacts your DB2ACCT dataset, you
can measure how much DB2TCBTM was lost with
PROC MEANS SUM DATA=PDB.DB2ACCT
(WHERE= (DB2PARTY NE 'R' AND QWACBJST=0));
VARIABLES QWACEJST;
TITLE TOTAL QWACEJST NOT INCLUDED IN DB2TCBTM;
If no observations are selected, no CPU time was lost.
Several folks at DB2 Support were ultimately involved in
the problem, providing this information about PK46171:
- Class 1 CP, zIIP, and elapsed times could be incorrect.
Because we don't get a 'start accounting' call:
1. QWACBSC would be from the last transaction to see a
start
2. QWACBJST would be the CP time from the last
transaction to see a start -- this can result in
this number being unrelated to QWACEJST
3. QWACCLSL_ZIIP would be effected similarly to
(QWACEJST - QWACBJST) since it is internally
calculated from a start ziip time that can be
unrelated to the end time
4. QWACAJST and QWACCLS2_ZIIP are probably not
noticeably effected although there could be an
extremely small amount of time that is not counted.
Above symptoms only occur in DRDA work when
connection-reuse is in effect. I can't see any
record said lacking of PK46171 will directly make
qwacbjst to zero.
- And this note on why QWACBJST can validly be zero.
From dump, we can see CPUTIME is 0 but zIIP time is >0
and this is a zIIP eligible distributed SRB. Thus
this is working as expected. The CP time can be 0
since all time might be on a zIIP at the time of the
first clocking. As long as either the CP or the zIIP
time > 0, that is normal.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY
Thanks to Derrick Haugan, MetLife, USA.
Thanks to Lisa Ouellette, Wachovia, USA.
Thanks to Jim Lazowski, NAV-INTERNATIONAL, USA.
Thanks to Uncha, DB2 Level 2 Support, GERMANY.
Thanks to Ronald Lobodzinski, DB2 Level 2 Support, USA.
Change 25.264 For consistency with MXG tailoring macro variables, new
IMACSPCK &MACSPCK is defined in VMXGINIT and referenced in the
VMXGINIT IMACSPCK tailoring member, though unlikely to be used.
Dec 5, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.263 Some DD DUMMY statements for INFILEs for new products
JCLTEST8 were missing in the TESTOTHR/TESSOTHR steps, and there
JCLTESS8 were inconsistencies in the TEST vs TESS members that
JCLTEST9 were corrected in these four test members. The main
JCLTESS9 purpose of these TEST/TESS jobs is to confirm that your
Dec 4, 2007 "USERID.SOURCLIB" tailoring did not cause any errors in
the TESTIBMx steps, so a failure in a subsequent step due
to a missing DD statement should not prevent you from
moving to JCLPDB8/JCLPDB9 testing.
Thanks to Eric Barnes, Scottish and Southern Energy, SCOTLAND.
Change 25.262 The 233 DDU files needed for ITRM sites to create ITRM
TYPETNG table definitions for each of the 233 datasets built
Dec 4, 2007 by MXG's TYPETNG (for CA's NSM product, formerly TNG).
There is also the cpddudef.sas program that is used
to generate all table definitions,. You will need to
replace &YOUR_PDB_PATH & Your_DDU_PATH in cpududef.sas
with your paths. The creation was run under a SAS ITRM
interactive session.
The itrmtng.sas file contains all 234 files in IEBUPDTE
format; the individual files can be created by using the
IEBUPDTE.SAS program in the MXG Source Library with the
itrmtng.sas file as it's input.
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.261 Variable LGGLGDEF in CICS dataset CICLGG is the Log Write
VMAC110 Defer Interval, the value specified in the site's LGDFINT
Nov 29, 2007 parameter, but the MXG format only printed 2 decimals;
the value is normally in milliseconds, so the format
TIME13.3 is now used so a value of 5 ms will print as
00:00:00.005.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.260 ITRTVLTM in TYPE30_V or PDB.SMFINTRV could be missing
VMAC30 for TYPETASK='OMVS' record; it is now protected twice,
Dec 1, 2007 in the SUBSTEP loop, and at the OUTPUT statement.
Thanks to Carl Sablon, KBC, BELGIUM.
Change 25.259 VMXGALOC bumped to the next week's PDB one day early, and
VMXGALOC could do even worse if the week-start-day was not Monday.
Nov 29, 2007 The logic was revised for both errors by this CodeShark.
Thanks to Patrick Holloman, Zions Bank Corporation, USA.
Change 25.258 Intentionally Blank Change (a/k/a skipped).
Change 25.257 Support for ICSF HCR7750 SMF Logging Update for TKE adds
FORMATS these new variables to SMF type 82 subtype 16 TYPE8216:
VMAC82 SMF82PAL='LENGTH OF*FIXED*AUDIT*DATA*'
Nov 29, 2007 SMF82PDE='DESCRIPTION'
SMF82PFI='FUNCTION*ID'
SMF82PFR='FUNCTION*RETURN*CODE'
SMF82PTA='TKE*AUTHORITY'
SMF82PUS='USER ID*NONCE*TSN'
and incorrectly spelled SMF82PDK is now SMF82PBK.
New MG082RC format decodes SMF82PFR.
Thanks to Greg Burt, Fifth Third Bank, USA.
====== Changes thru 25.256 were in MXG 25.11 dated Nov 22, 2007=========
Change 25.256 Macro variable &MXGDEBUG is revised for internal debugs.
TIMEBILD It's value is now the name of the member, suffixed with a
UTILRMFI numeric value when multiple values are needed. Previously
VMXGRMFI tests were for a simple numeric value, which triggered
VMXGSUM unwanted debugging diagnostics from other code members.
VMXGSUME And, UTILEXCL now exploits &MXGDEBUG with BEFORE/AFTER
UTILEXCL location for each of the optional CICS data segments, so
Nov 21, 2007 diagnosis of user tailoring errors will be faster!
For example, you could use:
OPTIONS FIRSTOBS=3800 OBS=3800;
%LET MXGDEBUG=IMACEXCL;
%INCLUDE SOURCLIB(TYPE110);
if you had an error after IMACEXCL/IMACICxx members
were tailored, and the error was in _N_=3800th record.
Change 25.255 Support for Action Software's EventAction SMF User Record
EXEVTA00 creates new datasets:
EXEVTA01 DDDDDD DATASET DESCRIPTION
EXEVTA02
EXEVTA03 EVTA00 EVTA00 DATASET CHANGE OR REFERENCE
EXEVTA04 EVTA01 EVTA01 CHANGESMXSMF)
EXEVTA05 EVTA02 EVTA02 REFERENCES MZSMF)
EXEVTA06 EVTA03 EVTA03 CHANGE ACTION CONTROLS
EXEVTA07 EVTA04 EVTA04 TEST ACTION C506)
EXEVTA08 EVTA05 EVTA05 COMMAND CONTROL C507)
EXEVTA09 EVTA06 EVTA06 CHG.DISTRIB TRANSMITS MZSMF)
EXEVTA0A EVTA07 EVTA07 REF.TRACKING BY MEMBERS CS501)
EXEVTA0B EVTA08 EVTA08 UPDATE TO EXCLUDES TABLE C41E)
EXEVTA0C EVTA09 EVTA09 UPDATE TO BLACKOUT TABLE C427)
EXEVTA0D EVTA0A EVTA0A UPDATE TO DATASET OPTIONS C404)
EXEVTA0E EVTA0B EVTA0B UPDATE TO MEMBER OVERRIDE C405)
EXEVTA0F EVTA0C EVTA0C OPTIONS AT OID LEVEL C40F)
EXEVTA10 EVTA0D EVTA0D GLOBAL PARMS C401)
EXEVTA11 EVTA0E EVTA0E DATA SET GLOBAL OPTIONS C401)
EXEVTA12 EVTA0F EVTA0F PXC
EXEVTA40 EVTA10 EVTA10 UPDATE TO USER GROUP
EXEVTA50 EVTA11 EVTA11 EXCLUDES NOT REF.TRK)
EXEVTA51 EVTA12 EVTA12 UPDATE TO CMD>TRACK OPTIONS
EXEVTAF0 EVTA40 EVTA40 CHANGE REQUEST DELETE
EXEVTAF1 EVTA50 EVTA50 USS CONTROLS
IMACEVTA EVTA51 EVTA51 USS EXCLUDES
TYPEEVTA EVTAF0 EVTAF0 ACCOUNTING RECORDS C50C)
TYPSEVTA EVTAF1 EVTAF1 USS CHANGS AND REFERENCES
VMACEVTA
VMXGINIT
FORMATS
Nov 18, 2007
Thanks to Craig Collins, State of Wisconsin DOA DET, USA.
Change 25.254 New sample report summarizes the DB2 Package data to the
ANALACTP UOW level keeping track of total response and CPU,
Nov 18, 2007 the longest package, the first 10 packages.
Jan 8, 2008 Jan 8: Typos in the untested code were discovered/fixed.
Example expected UOWIDCHR variable had been added
to your DB2ACCTP dataset, but didn't show how to,
or note it could be removed from ANALACTP example.
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Change 25.253 Support for new NTSMF MSSQL Objects.
EXNTQLBA DDDDDD DATASET DESCRIPTION
EXNTQLBN
EXNTQLBS NTQLBA MSQBROAC MSSQL:BROKER ACTIVATION
EXNTQLBT NTQLBN MSQBUFND MSSQL:BUFFER NODE
EXNTQLCA NTQLBS MSQBROST MSSQL:BROKER STATISTICS
EXNTQLCL NTQLBT MSQBRODT MSSQL:BROKER/DBM TRANSPORT
EXNTQLCT NTQLCL MSQCLR MSSQL:CLR
EXNTQLCU NTQLCA MSQCATME MSSQL:CATALOG METADATA
EXNTQLES NTQLCU MSQCURMG MSSQL:CURSOR MANAGER TOTAL
EXNTQLPC NTQLCT MSQCURTY MSSQL:CURSOR MANAGER BY TYPE
EXNTQLSR NTQLES MSQEXECS MSSQL:EXEC STATISTICS
EXNTQLTR NTQLPC MSQPLANC MSSQL:PLAN CACHE
EXNTQLWS NTQLSR MSQSQLER MSSQL:SQL ERRORS
IMACNTSM NTQLTR MSQTRANS MSSQL:TRANSACTIONS
VMACNTSM NTQLWS MSQWAITS MSSQL:WAIT STATISTICS
VMXGINIT
Nov 18, 2007
Thanks to Bob Gauthier, Albertsons, USA.
Change 25.252 Changes for testing MXG execution under WPS:
CONFIGW2 -MXGWPSV2. JCL procedure updated for WPS under z/OS
MXGWPSV2 -VMXGINIT. Test for identification of WPS revised, code
VMXGINIT was relocated to after TAPENGN was set for SAS:
VMXGPRAL %IF %SYSPROD(WPS) EQ 1 %THEN %DO;
ANALDB2K %LET WPSVER=&SYSVER;
ANALHTML %LET SASVER=8;
ANALMQMC %LET TAPENGN=WPDSEQ;
ASUM42DS %END;
ASUMCACH -CONFIGW2. CONFIG options now specify SEQENGINE=WPDSEQ.
ASUMHSM -VMXGPRAL. Tests for ENGINE adds WPDSEQ to list of seqs.
ASUMTALO Unrelated, SUM was added to PROC MEANS output.
CICSTRAN -VMXGINIT. WPS does not yet support VIEWS; all members
DB2PDB with /VIEW=XXXXXX were replaced with &VWxxxxxx
GRAFRAID macro variables that are %LET to the correct
JCLUOWP View-NAME under SAS but blanked under WPS.
JCLUOWV This change will be reversed when WPS has
UTILRMFI added support for Views.
UTILUOW -ANALDB2K thru VMXGUOWT listed at left were "View-Revixed".
VMXGCAPT WPS Level Tested successfully was Build (8460).
VMXGSUM
VMXGSUME MXG Newsletter FIFTY-ONE, VI.A WPS Technical Note reports
VMXGUOTT 1. Current status of MXG Testing under WPS Betas Nov 2007.
1.j. MXG Support Position for testing of WPS Release.
VMXGUOW 2. Run time comparisons.
VMXGUOWT 3. Revision to SAS Clones article in MXG Newsletter FIFTY.
Nov 19, 2007 4. Summary and statistics
Jan 30, 2008 Jan 30: typo VMUM corrected to VWUM.
Thanks to Brian Carter, EDS, UK.
Change 25.251 Several variables starting with R7021xxx had '2048-BIT'
VMAC7072 in their labels, but those are all '1024-BIT' counts and
Nov 17, 2007 durations; their labels are now corrected.
Thanks to Miguel F. Monferrer Carvajal, SPAIN.
Change 25.250 Variable TARCELAP is now FORMATed TIME12.2.
VMACTMNT
Nov 17, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.249 Variable TAUSRDAT was INPUT as $EBCDIC32. but can have up
VMACTMO2 to 240 bytes of data; INPUT statement was revised to use
Nov 17, 2007 TAUSRLEN to determine the length of user data input.
Thanks to Rodger Foreman, Acxiom, USA.
Change 25.248 The current VMXGSUM creates output variables with stored
VMXGINIT LENGTH of 5 (z/OS) or 6 (ASCII), based on the value of
VMXGSUM &MXGLEN (set in VMXGINIT), unless they are used in the
Nov 18, 2007 SUMLONG=, MAXTIME=, OR MINTIME= arguments, which always
create LENGTH 8 variables. You could change those lengths
with an explicit LENGTH statement in OUTCODE=, or you
could change the &MXGLEN value, but that would also
change subsequent LENGTHs of all defaulting variables in
subsequent steps in the same SAS session/step.
The SUMBY= and ID variables are output in the same length
they were in the input dataset, or in the INCODE= code if
that is where they were created. They could be changes
in the ORDER= argument.
This change creates macro variable &LNSUMOUT which will
only apply to VMXGSUM and makes all variables on which we
do mathematical operations to be LENGTH 8.
The default value of LNSUMOUT is blank, so the variables
will have the original (shorter) length unless you set
%LET LNSUMOUT=8; in your //SYSIN stream.
Apr 2008: DO NOT USE LNSUMOUT. See Change 26.065.
Thanks to MP Welch, SPRINT, USA.
Change 25.247 WebSphere SMF 120 Subtype 3 with two heap ids SM120SNT=2
VMAC120 caused INPUT STATEMENT EXCEEDED RECORD or INVALID DO LOOP
Nov 13, 2007 CONTROL error; only SM120SNT=1 records had been read and
this condition exposed an MXG logic error, now corrected.
Thanks to Bjorn Helgestad, VPS ASA, NORWAY.
Change 25.246 A CFI record with only a header segment caused ASMRMFV
ASMRMFV to burp and die with an 0C4; this revision protects.
Nov 13, 2007 Additional enhancements are noted in the changes in the
Nov 17, 2007 ASM source comments.
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.245 CA PDSMAN product's SMF record created megabytes of data
VMACPDSM when diagnostic trace records (LGRTYPE='D') were enabled,
Nov 12, 2007 and CA's recommendation was to suppress them and also the
Resource Monitoring (LGRTYPE='M') record processing.
Thanks to Sudie Wulfert-Shcickendanz, Anheuser-Busch, USA.
Change 25.244 The IRRDBU00 RACF DATABASE UNLOAD record '0200' comes in
VMACRACF two different lengths, 540 and 549, but MXG expected the
Nov 12, 2007 549 length record, which caused INPUT RECORD EXCEEDED
error when the shorter record was read. Both lengths are
now supported.
Thanks to Sean Angley, IBM, CANADA
Change 25.243 The automatic PROC DELETE of the WORK.UNKNOWN dataset is
TYPETNG removed, so that that dataset will exist after TYPETNG or
TYPSTNG TYPSTNG program is used to process CA NSM (old TNG) data.
Nov 6, 2007 If there are non-zero observations in WORK.UNKNOWN, it is
very possible that some or all data will not have been
output by MXG logic, so leaving WORK.UKNOWN will allow
it to be tested for possible unknown data records.
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.242 NDM record 'UC' is now output in NDMAE dataset.
VMACNDM
Nov 5, 2007
Change 25.241 Support for CICS Transaction Gateway 7.1.0 new SMF 111
EX111CM statistics record:
EX111CM datasets:
EX111CS DDDDDD MXG MXG
EX111CXE DATASET DATASET DATASET
EX111CXI SUFFIX NAME LABEL
EX111GD
EX111PH 111CM T111CM CICS CTG COMMUNICATIONS MANAGER
EX111SE 111CS T111CX CICS CTG CICS SERVER
EX111WT 111CXE T111CXE CICS CTG EXCI SERVER INSTANCE
IMAC111 111CXI T111CXI CICS CTG IPIC SERVER INSTANCE
VMAC111 111GD T111GD CICS CTG GATEWAY DAEMON
VMXGINIT 111PH T111PH CICS CTG PROTOCOL HANDLER
Nov 5, 2007 111SE T111SE CICS CTG SYSTEM ENVIRONMENT
Nov 21, 2007 111WT T111WT CICS CTG WORKER THREADS
Change 25.240 Full Support for CICS/TS 3.2 Compressed Data.
EXITCICS MXG incorrectly believed that '20'x bit in MCTMNOPN was
VMAC110 true when CICS/TS 3.2 SMF 110-1 records are internally
VMAC112 compressed, but that bit only indicates that the compress
Nov 3, 2007 option was enabled for this CICS region. This caused MXG
Nov 13, 2007 to falsely report the EXITCICS decompression exit was not
correctly installed, when Dictionary Records (MNSEGCL=1),
which are never compressed, were read. MXG now tests for
non-zero MCTSSCRL, which is the documented condition for
a compressed CICS SMF 110 or 112 record.
-VMAC112 was similarly changed to test for non-zero OMSPCL
to detect compressed SMF 112 records.
-This incorrect assumption had also been passed in my spec
for the EXITCICS logic, which had just turned off that
'20'x bit in its decompressed output. Now, EXITCICS sets
MCTSSCRL or OMSPCL to zero after decompression.
-If you previously assembled EXITCICS prior to this change
you must reassemble with this revised EXITCICS member AND
use the revised MXG's VMAC to read compressed records.
Change 25.239 -Support for new THRUPUT MANAGER variables in TYPETPMX:
EXTPMALG JXSLMCC ='JXSLM*CONTROL*CENTER'
EXTPMDBS JXSLMCC ='JXSLM*CONTROL*CENTER'
EXTPMSLM -New SLM JOB Statistics subtype 5 creates TPMSLM dataset.
FORMATS -New DBS POOL subtype 240 creates two new datasets:
IMACTPMX TPMALG - Algorithm data
VMACTPMX TPMDBS - DBS Pool data
VMXGINIT -Jan 4: Variables JESNR JCTJOBID added to TPMSLM dataset.
Nov 3, 2007 -Jan 9: GA records have corrected ETP truncation that was
Jan 4, 2008 originally reported here.
Jan 9, 2008
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.238 Optional OMEGAMON BSC segment for CICS/TS 3.2 did NOT
IMACICOB increase time-duration/count fields to the full 12-byte
IMACICOC resolution that I had ASS-U-Med, which caused MXG ERROR
IMACICO2 message INVALID STRTTIME. I made the same assumption for
Nov 2, 2007 all three Omegamon segments with time/count fields, so I
now assumed that the other two segments also have 8-byte
fields (IMACICOB for OMEGDB2, IMACICO2 for OMEGAMON), so
those two members also are reverted. And, of course, if
Omegamon does increase their fields to full 12-bytes,
yet another MXG change will be required.
Thanks to Ray Dunn, CIGNA, USA.
Change 25.237 Variable LCPUWAIT='LCPU 28*WAIT*COMPLETE?' in PDB.TYPE70
VMAC7072 was not kept after MXG 23.09, but the same named variable
Nov 1, 2007 LCPUWAIT='LPAR*WAIT*COMPLETION?' in PDB.TYPE70PR was, and
that was the source of the problem. Now, a rename fixes
this error, which was introduced in the infamous SPLIT70
rewrite.
Thanks to Enzo Rossi, Demand Technology Software, ITALY.
Change 25.236 Change 24.141 with z/OS at 1.7 or earlier caused TYPE78IO
VMAC78 dataset to have zero observations; MXG tested SMF78RSQ
Oct 31, 2007 for zero or one, but SMF78RSQ does not exist when the
Nov 1, 2007 RMF product segment is only 104 bytes. The test was
revised to output TYPE78 for missing value, zero or one.
But then, the duplicate observations created were NOT
removed by the NODUP option, because the SMFTIME in the
second or third replicates was not exactly the same value
as the first, so the _STY78IO sort macro was rewritten to
remove those with identical SMFTIMEs, and an extra DATA
step is used to keep only the FIRST.SMFTIME instance.
(The additional logic is invoked, but not needed, when
the SPLIT 78 records have a valid SMF78RSQ value.)
Thanks to Peter B. Hopper, CSC, AUSTRALIA.
Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 25.235 -Support for new Solaris CA CUBE STORE GROUP object and
EXTSO030 new variables in existing Solaris MIB-2.
EXTAI027 -Support for two new AIX Objects.
EXTAI028 -Support for 10 new RedHeat Objects, many new Metrics
EXTRH020 for existing RedHat Objects.
EXTRH021
EXTRH022
EXTRH023
EXTRH024
EXTRH025
EXTRH026
EXTRH027
EXTRH028
EXTRH029
FORMATS
VMACTNG
VMXGINIT
Oct 31, 2007
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.234 New variables added to OAM SMF 85 subtype 32-35 record
VMAC85 by z/OS 1.7 are now input and kept in TYPE85ST dataset:
Oct 28, 2007 R85B2ODK='BACKUP2*BYTES*DELETED FROF*OPTICAL'
Nov 1, 2007 R85B2ODO='BACKUP2*OBJECTS*DELETED FROM*OPTICAL'
R85B2ORK='BACKUP2*BYTES*READ FROM*OPTICAL'
R85B2ORO='BACKUP2*OBJECTS*READ FROM*OPTICAL'
R85B2OWK='BACKUP2*BYTES*WRITTEN TO*OPTICAL'
R85B2OWO='BACKUP2*OBJECTS*WRITTEN TO*OPTICAL'
R85B2TDK='BACKUP2*BYTES*DELETED FROF*TAPE'
R85B2TDO='BACKUP2*OBJECTS*DELETED FROM*TAPE'
R85B2TRK='BACKUP2*BYTES*READ FROM*TAPE'
R85B2TRO='BACKUP2*OBJECTS*READ FROM*TAPE'
R85B2TWK='BACKUP2*BYTES*WRITTEN TO*TAPE'
R85B2TWO='BACKUP2*OBJECTS*WRITTEN TO*TAPE'
R85NTE ='TAPE*VOLUMES*EXPIRED'
R85RCLD ='RECALLED*OBJECTS*PROCESSED*THIS CYCLE'
R85RCLK ='BYTES OF*RECALLED*OBJECTES*THIS CYCLE'
and these variables added by z/OS 1.8 are input/kept:
R85LOBD ='ROWS*DELETED*FROM LOB*STRUCTURE'
R85LOBI ='ROWS*INSERTED*INTO LOB*STRUCTURE'
Thanks to Harald Seifert, HUK-COBURG, GERMANY.
Change 25.233 The COMPRESSED RECORD FOUND error was printed for a CICS
VMAC110 dictionary record, but the MNSEGCL flag that identifies
Oct 27, 2007 the record IS a dictionary record was not printed.
Change 25.232 Change 25.124 added preliminary support for WPS execution
VMXGINIT but it forced WPSVER=2; now, the actual WPSVER is stored
Oct 26, 2007 in &WPSVER.
Change 25.231 Change 25.177 created new macro variable &ARRAYRMF, but
VMXGINIT the location in VMXGINIT was inside a DO GROUP that was
Oct 26, 2007 only executed for SAS V8.2, causing UNRESOLVED MACRO when
MXG executed under SAS Version 8.1. The statement was
relocated so it is always executed, no matter what SAS
version is used.
Thanks to John Compton, ACS, USA.
Change 25.230 MXG support for IMF 4.3 used the new offset field to the
VMACCIMS DBD segments when it was non-zero, but PTF BQI0129 for
Oct 23, 2007 IMF 4.2 populated that previously reserved field, which
caused INPUT EXCEEDED error and this error message:
INVALID IMS TRANSACTION RECORD LENGTH=836 WITH xxx
48-BYTE DBDS EXPECTED AFTER COL=32765 _N_=1
Now, MXG only uses the 4.3 offset to DBDs when the IMF
version is 4.3 or greater.
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 25.229 -NMON data for AIX for PDB.NMONCPUD records can have the
VMACNMON number of CPUnn records increase and decrease as AIX adds
Oct 23, 2007 or subtracts "virtual" CPUs, and when a CPUnn goes away,
Nov 2, 2007 NMON wrote a short record, which caused INPUT EXCEEDED
error. Now, MXG detects and deletes these short records.
Note that the PDB.NMONINTV dataset, in NRCPUS variable,
has the number of "real" CPUs. However, in this case,
the value of NRCPUS was always 6, even though there were
CPUnn segments with CPU14 (i.e., there should have been
NRCPUS=7, as there are 2 "virtual" CPUs for each "real".
-Temporary variables WORD11-WORD24 were not set to LENGTH
$128, so they took the SAS default of 8-bytes for CHARs,
causing character variables stored from them to also have
a stored length of 8 bytes. Now, all WORDnn are $128,
and specific LENGTHs for kept variables are used where
needed.
-Variables NRCPU, PID, and PPID are now numerics.
-NMON data value 'nan' is 'Not a Number' and is stored in
the data records, causing INVALID DATA messages until
each instance is protected with double question marks!!
Sometimes spelled NaN.
Thanks to Mike Woelke, Boeing, USA.
Change 25.228 Protection for invalid SMF 14 record that had NUCB=2 but
VMAC1415 only one actual UCB segment. This record caused ERROR:
Oct 17, 2007 INPUT STATEMENT EXCEEDED RECORD LENGTH. Protection will
print error message for first three bad instances.
Thanks to William Carrol, Grange Insurance, USA.
Change 25.227 Variable RPRTCLAS is now kept in TYPE72DL dataset to flag
VMAC7072 a Service Class versus a Reporting Class observation. It
Oct 16, 2007 was not kept previously because the SMF manual mentioned
only service classes, but actual data shows TYPE72DL can
contain both Service and Reporting Class observations.
Thanks to Harald Seifert, HUK-COBURG, GERMANY
Change 25.226 UPRINDOC will PROC PRINT the NAME and LABEL of variables
UPRINDOC and is used to create the example output in the ADOCxxxx
Oct 16, 2007 members, and it also PROC MEANS all numeric variables.
It's been in MXG for years, but never documented.
Change 25.225 RMF III variable ENCCPUT is labeled 'CP*ENGINE*CPU TIME'
VMACRMFV now, because it is recalculated to remove zIIP CPU time:
Oct 16, 2007 ENCCPUT=ENCCPUT-ENCSUPT;
Oct 31, 2007 when it was found (and confirmed by RMF support) that it
contained both CP and zIIP Engine CPU time, but MXG will
always preserve the CP-Engine CPU times separately from
the zIIP and/or zAAP engine CPU times.
Thanks to Rodger Foreman, Acxiom, USA.
Change 25.224 The tests for CPUTYPE IN ('2064'X ...) are revised to now
VMAC7072 alternatively test for ZARCHMDE='Y', so that a new value
VMXGRMFI for CPUTYPE does NOT have to be added to MXG's table.
Oct 16, 2007 Previously, an unknown CPUTYPE was INCOMPATIBLE until
Oct 27, 2007 it was added to the tables in these two members.
The tests for CPUTYPE were needed to identify which data
exists in some of the early CPU types, but now that IBM
has added the bit for ZARCHMDE, it eliminates the need
for a new MXG version when IBM has a new CPUTYPE.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.223 The variable HOST is increased to 32 bytes; the original
VMACNMON length of 8 is insufficient for unix/AIX/linux host name.
Oct 15, 2007
Thanks to Michael W. Wolke, Boeing, USA.
Change 25.222 EXIT112 is the enhanced CICS INFILE EXIT for z/OS MXG
EXIT112 that reads compressed SMF 110 and SMF 112 records, but it
Oct 13, 2007 is temporary, as it will replace EXITCICS when a site
reports successful production sites with both records.
EXITCICS is running in production at several sites.
EXIT112 is an extension to EXITCICS, and EXIT112 has been
tested, but only with a small SMF file. I recommend that
EXIT112 be installed instead of EXITICS, and ask that you
confirm successful processing compressed 110 and 112 data
so that I can remove EXIT112 and rewrite this change.
Change 25.221 Support for CA NSM data from VM Ware VSX Systems creates
EXTVW001- ten new datasets. Many VMW metrics are the same as their
EXTVW010 Solaris and RedHat Linux counterparts, but with different
FORMATS variable names because not all exist and they are created
IMACTNG in different orders. While "TNG" still must be the suffix
VMACTNG for the MXG code members, the dataset labels of all "TNG"
VMXGINIT datasets are now changed to "NSM". New VM Ware datasets:
Oct 13, 2007 DATASET DDDDDD DESCRIPTION
VW001 VW001 NSM CA CPU GROUP
VW002 VW002 NSM CA FILE SYSTEM
VW003 VW003 NSM CA INTERFACE GROUP
VW004 VW004 NSM CA KERNEL CONFIG GROUP
VW005 VW005 NSM CA MEMORY GROUP
VW005 VW005 NSM CA NETWORK GROUP
VW007 VW007 NSM CA PER CPU GROUP
VW008 VW008 NSM CA SWAP GROUP
VW009 VW009 NSM CA PROCESS GROUP
VW010 VW010 NSM VIRTUALIZED ENVIRONMENT
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.220 The LABEL for SMF91OW was correct in TYPE91 datasets, but
ANAL91 it was changed in ANAL91, incorrectly, in an unneeded and
Oct 11, 2007 redundant and now removed LABEL statement.
Thanks to Dave Krouse, IBM, USA.
Change 25.219 TYPE74CA variable FWDC was replaced some time ago, but
VMAC74 the label was not corrected; the variable is labeled now:
Oct 11, 2007 FWDC ='DASD F/W*BYPASS*COUNT*R745DFWB'
Thanks to Ed Woodward, UPS, USA.
Change 25.218 Support for local CICS USER field CMODHEAD,CMODNAME=TRADE
IMACICU5 creates variable TRADEU5 in CICSTRAN, when enabled.
VMAC110 Jul 3, 2008: Field was increased to 80 bytes; the test
UTILEXCL and INPUT were also increased to 80.
Oct 11, 2007
Jul 3, 2008
Thanks to Leendert Keesmaat, UBS, SWITZERLAND.
Change 25.217 VMACPRPR was revised, in June, but the Change text was
VMACPRPR lost. Originally support for the '1620' record was added
Oct 10, 2007 June 12, and test records had different delimiters in
date/time fields, so INPUTs were changed in MXG, but now
I see that no other record's date/times were changed.
This change, which was included in MXG 25.10, reverted
date/times for all other records to the original format,
but created a separate path to decode 1620 subtypes.
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 25.216 The MXG support for optional CICS EZA01/EZA02 fields has
IMACICEZ been enhanced and documentation revised for clarity:
IMACICE1
IMACICE2 -IMACICEZ always has these 5 fields, identified by their
VMAC110 CMODNAME='EZA01' and CMODTYPE='S':
Oct 11, 2007
Jun 13, 2008 EZA01 S 001 12 ooo INIT
EZA01 S 002 12 ooo READ
EZA01 S 003 12 ooo WRITE
EZA01 S 004 12 ooo SELECT
EZA01 S 005 12 ooo OTHER
The CMODLENG=12 is from CICS/3.2; earlier CICS had only
CMODLENG=8, but IMACICEZ supports both lengths, so you
just remove the comment block to tailor IMACICEZ and it
will process data with either or both lengths.
-IMACICE1 can have up to 13 fields, identified by their
CMODNAME='EZA01' and CMODTYPE='A' (yes, CMODNAME is the
same 'EZA01' as IMACICEZ, but the CMODTYPE is different):
EZA01 A 001 4 ooo TINIT
EZA01 A 002 4 ooo TREAD
EZA01 A 003 4 ooo TWRITE
EZA01 A 004 4 ooo TSELECT
EZA01 A 005 4 ooo TOTHER
EZA01 A 006 4 ooo REUSABLE
EZA01 A 007 4 ooo ATTACHED
EZA01 A 008 4 ooo OPENAPI
EZA01 A 009 4 ooo TCBLIM
EZA01 A 010 4 ooo TREUSABL
EZA01 A 011 4 ooo TATTACHE
EZA01 A 012 4 ooo TOPENAPI
EZA01 A 013 4 ooo TTCBLIM
You will have to examine REPORT THREE (which may have the
last CMODHEAD field 'EZA01' instead of the names shown)
to know how many fields are in your data. If you have the
expected 13 fields, then you just remove the one comment
block. If you have fewer fields, then:
- Change the IF xxxx GE 52 THEN DO; statement so its
test value is 4 times the number of fields, e.g.
with seven fields change the "52" to "28".
- Change the INPUT statement's suffix from EZA01A13 to
the number of fields you have; if there are seven:
INPUT (EZA01A01-EZA01A07) (&PIB.4.) @;
- Delete the LABELs for variables that don't exist.
-IMACICE2 has 22 fields with z/OS 1.7 TCP/IP data, but had
only 11 fields with z/OS 1.4, which are identified by the
CMODNAME='EZA02' and CMODTYPE='A:
EZA02 A 001 4 330 CONN
EZA02 A 002 4 331 STARTED
EZA02 A 003 4 332 INVALID
EZA02 A 004 4 333 DISTRAN
EZA02 A 005 4 334 DISPROG
EZA02 A 006 4 335 GIVESOKT
EZA02 A 007 4 336 SECEXIT
EZA02 A 008 4 337 NOTAUTH
EZA02 A 009 4 338 IOERR
EZA02 A 010 4 339 NOSPACE
EZA02 A 011 4 340 LENERR
EZA02 A 012 4 341 TCONN
EZA02 A 013 4 342 TSTARTED
EZA02 A 014 4 343 TINVALID
EZA02 A 015 4 344 TDISTRAN
EZA02 A 016 4 345 TDISPROG
EZA02 A 017 4 346 TGIVESOK
EZA02 A 018 4 347 TSECEXIT
EZA02 A 019 4 348 TNOTAUTH
EZA02 A 020 4 349 TIOERR
EZA02 A 021 4 350 TNOSPACE
EZA02 A 022 4 351 TLENERR
You will HAVE to look at UTILEXCL REPORT THREE to confirm
if you have 22 or 11 fields, and remove only one of the
two comment blocks in IMACICE2 to tailor it.
-You create REPORT THREE with the _RPTEXCL macro run
with or after your UTILEXCL execution:
//SYSIN DD *
%INCLUDE SOURCLIB(UTILEXCL);
_BLDDICT;
_BLDEXCL;
_RPTEXCL;
-The only actual change made was to update VMAC110 to keep
the EXA01A13 13th variable.
-The text of this change was revised in June, 2008.
Thanks to Jane Dickerson, PRODUBAN, ENGLAND.
====== Changes thru 25.215 were in MXG 25.10 dated Oct 7, 2007=========
Change 25.215 Change 25.179 broke VMXGUOW, some overrides of _LDB2ACC
VMXGUOW caused CHARACTER OPERAND IN %EVAL FUNCTION errors.
Oct 7, 2007 Also, parameter HOWDEEP added to set kept array sizes.
Change 25.214 An example that finds all TSO and IDMS USERID that logged
TSOIDMS on,using IBM SMF 30 and IDMS PERFMON USER SMF records.
Oct 6, 2007
Thanks to Pat Curren, Supervalu, USA.
Change 25.213 Documentation only. DB2 variable THREADTY shouldn't have
VMACDB2 been added to DB2ACCTP dataset (Change 25.097), because
Oct 7, 2007 DB2 V8.1 writes all Package data in IFCID=239 (ID=101.1)
records, which do not contain a QLAC segment, and IBM's
THREADTY definition (in comments for QWHDRQNM field in
their DSNWMSGS member of the DB2 Macro Library) compares
QWHDRQNM with QLACLOCN. Since I can never safely remove
a variable, it will still exist in DB2ACCTP, but it will
always be blank in that dataset. No code was changed.
Change 25.212 -SYNCSORT variable SYNCUSET is now documented to be the
VMACSYNC sum of VSCORET plus the GDSM Adjustment, so its label
Oct 6, 2007 is revised to be:
Nov 17, 2007 SYNCUSET='CORE USED*TOTAL*VSCORET*PLUS GDSM ADJ'
-SYNCSORT added a new field, which MXG decodes as:
SYNHWMPF='HIGHWATERMARK*PAGEFIXED*STORAGE*USED'
where the old HPALLOC/HPUSED ESTORE BLOCKS was located.
-All reserved and unknown fields in SYNCSORT SMF record
are decoded, but none of these variables are kept:
/* SYNRSV41-SYNRSV45 SYNUNK01-SYNUNK15 */
/* SYNCHFUT SYNCBFUT SYNXXXX1 SYNSPARE */
Change 25.211 PDB.TYPE70 variables ZIPACTTM, PCTZIPBY, PCTCIBYn are now
VMAC7072 corrected for Dedicated zIIP Engines. For Shared zIIPs,
Oct 5, 2007 the LPAR Dispatch time is valid, but Dedicated engines
report 100% dispatch. For TYPE70, the ZIPWAITM is used
to correct ZIPACTTM, which corrects the other variables.
Thanks to Jerry Cobb, American Century, USA.
Change 25.210 -WARNING: LENGTH OF CHARACTER VARIABLE ACCOUNT1 HAS BEEN
VMACSFTA SET under SAS V9 is issued ONLY when a LENGTH statement
VMACDB2 changes the length of a character variable, and, like all
VMACOPC WARNING: messages in SAS V9, z/OS sets Condition Code 4.
VMACBE97 (Under V8, this specific WARNING did NOT set CC=4,
VMAC7072 but V9 has tightened specs so WARNINGS always CC=4.)
TRNDDB2S But it should never occur in MXG code: although there are
ANALCISH multiple LENGTH statements, they should always set the
Oct 4, 2007 same value.
But it did occur when VMACSFTA was executed standalone,
because the statement ACCOUNT1=XPUPNOAC; was located
prior to the %INCLUDE of IMACACCT, which is where the
LENGTH of ACCOUNT1 should always be defined. Relocating
that ACCOUNT1=XPUPNOAC; statement eliminated the WARNING.
-When WARNING for numeric vars (eg. QB1TALX) were printed,
I discovered there were six members that had hard-coded
values for LENGTH DEFAULT=4 that should have been changed
to LENGTH DEFAULT= &MXGLEN; the were overlooked or added
after Change 19.272, but now all are consistent so that
numeric variables are stored 5 on z/OS and 6 on ASCII,
except for the specific cases where length 8 is required.
Thanks to Ron van der Zande, KLM Info Services, THE NETHERLANDS.
Thanks to MP Welch, SPRINT, USA.
Change 25.209 -TIMEBILD/TIMETABL is enhanced to support the selective
TIMEBILD application by SYSTEM of "SYNC59" timeshifting logic:
TIMETABL - TIMEBILD now reads columns 71-72 of TIMETABL to INPUT
VMXGTIME the (+ or -) number of minutes to be added for SYNC59.
VMXGINIT That value is a part of the format built by TIMEBILD.
VMXG70PR - %TIMEBILD must be executed first to create the table.
Oct 5, 2007 - To enable the addition of SYNC59 offset, you must set
%LET MXGTIM59=YES;
and then you would run the program whose datetimes
are to be shifted by both TIMEBILD zones and SYNC59.
- The "SYNC59" option is intended to be used ONLY with
RMF/CMF data, and in particular, for data from a CEC
that has some systems SYNC59 and some SYNC00. It may
not work with other programs, including BUILDPDB, as
you may not want all records SYNC59'ed. And, if you
now use the SYNC59 option in TIMEBILD, you must also
change your ASUMxxx, TRNDxxxx, VMXGxxxx tailored code
to now specify SYNC59=NO to prevent a double shift.
- To process only the RMF data with a TIMETABL that has
been updated to include the SYNC59 flag, you could use
%LET MXGTIM59=YES;
%TIMEBILD;
%UTILBLDP ( BUILDPDB=NO,
USERADD=70 71 72 73 74 75 76 77 78,
ZEROOBS=74.1 74.5,
INCLAFTR=RMFINTRV ASUM70PR,
OUTFILE=INSTREAM);
%INCLUDE INSTREAM;
to build you RMF-only PDB Library (which will be small,
as that example does NOT create observations in the two
big TYPE74 and TYPE74CA datasets due to that ZEROOBS=).
- TIMEBILD will PROC PRINT the input TIMETABL and the
output TIMEBILD datasets by enabling MXGDEBUG:
//SYSIN DD *
%LET MXGDEBUG=1;
%LET MXGTIM59=YES;
%TIMEBILD;
RUN;
%LET MXGDEBUG=0;
- You can conditionally reset MXGTIME59 for some SMF data
and not for others; for example, to enable for59 add,
and you do NOT have to rerun TIMEBILD.
%TIMEBILD(TIMEBILD=YES);
%LET MACFILE=%QUOTE(
IF ID=30 THEN CALL SYMPUT('MXGTIM59','NO');
ELSE CALL SYMPUT('MXGTIM59','YES');
);
%UTILBLDP(USERADD=7072 30,BUILDPDB=NO);
%INCLUDE INSTREAM;
-Once TIMEBILD worked to selectively SYNC59, the original
problem, duplicate observations in PDB.ASUMCELP, could be
diagnosed: while BY variable GMTOFFTM is correctly used
to creating the "per-SYSTEM" datasets, it can never be
used in the "per-CEC" datasets, because they are built
from multiple SYSTEM's data, which can have multiple
values in GMTOFFTM. Removing GMTOFFTM from the creation
of PDB.ASUMCELP has eliminated the duplicates; I should
remove GMTOFFTM where it makes no sense, but instead, I
have set GMTOFFTM=. in ASUMCEC and ASUMCELP, so it will
not create a VARIABLE NOT FOUND ERROR.
Thanks to Ingegerd Jannson, Volvo, SWEDEN
Change 25.208 CICS local user field CMONDNAME DAT008 CMODHEAD ENTRADA
IMACICU4 creates new variable ENTRADA.
VMAC110
UTILEXCL
Oct 1, 2007
Thanks to Jane Dickenson, Santander Produban UK, ENGLAND.
Change 25.207 The NTSMF dataset LOGLDISK had the variables FREESPAC
VMACNTSM (FREE MEGABYTES and PCTFRESP (PCT Free space) but the
Sep 27, 2007 size of the volume did not exist until now, with the
new DISKSIZE variable.
Thanks to Michael Ryan, Acxiom, USA.
Change 25.206 MXG 25.09 only. If the SAS-provided default CONFIG member
FORMATS was not in your //CONFIG DD statement in your MXGSASV9
CONFIGV8 JCL procedure, the PROC FORMAT failed to build MXGTNGON,
CONFIGV9 because lines 12092 thru 12099 in FORMATS were low-case
Oct 3, 2007 duplicates of preceding lines, that should not have been
have been there, but they caused no error when the CONFIG
member was present. Since they also caused the error if
they were UPPERCASED, I assume the absence of the SAS
CONFIG member caused them to be treated as UPCASE. Also,
there were Macro Variable error messages because MERROR
is a required option that is normally set in SAS CONFIG.
To protect, MERROR is now added to CONFIGV9 and CONFIGV9.
Thanks to Jim Wertenberger, Antares Solutions, USA.
Change 25.205 Support for z/OS 1.9 54 CP engines - INCOMPATIBLE.
VMAC7072 Z/OS 1.9 allows up to 54 CP engines in a single image,
Sep 27, 2007 but SMF 70 records with CPUID=33 or higer caused ARRAY
Oct 4, 2007 SIZE EXCEEDED with MXG 25.09 or prior. Now, CPUs with
CPUID=33 thru CPUID=53 are supported in the PDB.TYPE70
dataset (the only MXG dataset altered due to 54-CPUs).
Each CPUID has a set of variables in PDB.TYPE70; existing
0-32 CPUIDs variable names were created with suffix 0-9
and A thru X. Now, Y and Z are used for 33-34, and ZA
thru ZS suffix are used for CPUIDs 35-53 variables.
Where the variable name is 8 characters, that "Za" had
to overlay the penultimate character in the name.
To operate on these CPU-specific variable names, they
are all defined in VMAC7072 with an ARRAY statement
that you can cut and paste into your program to avoid
spelling all those names.
-Unrelated, discovered in testing: APAR OA18244 documented
that the CPUC segment was increased to 116 bytes, but the
APAR actually increased its length to 160 bytes, causing
SMF70GJT and following variables to be missing value, as
the MXG test was for EQ 116 (without APAR is EQ 102).
Now, the test is for GE 160, as IBM RMF Development has
confirmed the correct length, to be documented, is 160,
adding 44 unused bytes of zeroes. This APAR applies to
both z/OS 1.8 and z/OS 1.9.
Thanks to Tony Curry, BMC, USA.
Change 25.204 CFI Segmentation feature added for RMF III VSAM support,
ASMRMFV which now eliminates the possibility of skipped CF data,
VMACRMFV new ASM symbolics for tailoring, and additional items.
Sep 25, 2007 Issues Resolved:
Oct 3, 2007 -PROCCFI is now a subroutine to conserve the mainline
Dec 4, 2007 base register.
-CFI Table output is now segmented in response to
reported problems by MXG users. This removes a long
standing restriction that the size of the CFI table
could not exceeding the 32K LRECL output maximum without
data loss.
-The RMFV005E error message could have overlaid text when
multiple ASMRMFV parameter errors were detected.
-Several problems with index data fields in the CFI table
output record either not being set or set incorrectly
that caused PDB build errors in VMACRMFV have been fixed
during alpha code testing.
Enhancements:
-There are a pair of new option keywords BYTES/NOBYTES.
These specify whether ASMRMFV should or should not
provide byte counts for 5 categories of data read,
decompressed, written, filtered, and skipped. The
counts are provided in each RMF data set detail report
and also as totals in the summary report. This feature
is intended to aid users to understand the volume of
data being processed by ASMRMFV, as a coarse comparison
tool when using different versions of (or sets of
keyword options with) ASMRMFV, and finally as a possible
diagnostic aid. The alias for BYTES is BY and the
aliases for NOBYTES is NOBY or -BY. The byte counts
now appear in message RMFV104I and the former RMFV104I
message is now RMFV105I. The distributed default is
BYTES Packed decimal arithmetic is used for these
counters to allow up to 15 decimal digits in magnitude
or up to a value of 999,999,999,999,999 bytes. The
assembler symbolic variable &BYTES is provided to allow
the user to change the default for BYTES/NOBYTES to
NOBYTES in the ASMRMFV source code. The distributed
default is 'Y' meaning that BYTES is the default. These
counters take little overhead to maintain and display.
So there is little benefit in suppressing them except to
reduce output report volume by 2 lines per data set.
But that choice is certainly available.
-A pair of new option keywords CFALL/CFMASTER is added in
support of the CFI segmentation support. CFALL
specifies that CFI tables from all input RMF III LPARs
are to be output as in prior versions of ASMRMFV.
CFMASTER specifies that by testing a particular flag
that only data from the LPAR designated as RMF III
Master Gatherer is to be output. The distributed
default is CFALL. Effective use of CFMASTER requires
that the RMF III parameter CFDETAIL be in effect in all
LPARs in the Sysplex. Due to the IBM usage of this
flag, using the CFMASTER option when RMF III NOCFDETAIL
is in effect (IBM default) will cause all CFI records to
be filtered out by ASMRMFV. CFALL has no alias.
Aliases for CFMASTER are CFMAST and CFM. With CFDETAIL
in effect only the single LPAR determined by RMF III to
be the Master Gatherer collects all Coupling Facility
detail data. So including incomplete CF data from the
remaining LPARs may be an unnecessary and redundant
overhead. The intent of CFMASTER is to automatically
exclude this extra data. The &CFALL assembler symbolic
is also provided to change the CFALL default in ASMRMFV
source code if needed. The &CFALL symbolic can be
changed in the ASMRMFV source to 'N' prior to assembly
to permanently enable CFMASTER processing. The
distributed default is 'Y'. Do not make this change
unless using CFDETAIL on all LPARs being input to
ASMRMFV.
-When CFMASTER is in effect the CFI table id in
the RMFV105I message displays as CFIM instead of the
usual CFI to indicate this option is in effect.
-When the BUFFERS option is in effect the RMFV102I
message will now display a count of both buffers
available and used for each buffer pool type. This
feature was intended mainly to enable MXG users to
intelligently size the large VSAM LSR buffer pool used
to optimize random RMF III data set read access by
ASMRMFV. The distributed default is 5000.
Unfortunately, at this time the VSAM SHOWCB macro
seems to always return a 1 for actual buffers used in
the LSR pool. Given the number of random I/Os
typically issued this value seems suspect and
requires further investigation.
-Program logic for both buffer pool accounting and
normal/filtered/skipped record output has been improved.
-Documentation on the contents of fields for several
messages has been improved to provide more details on
their content and meaning.
-ASMRMFV program prologue documentation is upgraded to
document all related program changes.
-Oct 3: corrected INPUT STATEMENT EXCEEDED; 1.8 CFI data
ends with CFISCCOC in member VMACRMFV.
-Dec 4: VMACRMFV restructured to output only the first
CPUG3 segment to ZRBCPU; the ASMRMFV CPU segmentation
creates a CPUG3 segment for each LPARNAME, which caused
duplicate observations in WORK.ZRBCPU; using TYPSRMFV
to sort ZRBCPU did remove those duplicate obs, but this
change compares CPUHNAME with LPARNAME an outputs only
the first instance for each interval.
Thanks to Jerry Urbaniak, Acxiom, USA.
Thanks to Ben Romano, Hewitt Associates, USA.
Thanks to Lawrence Jermyn of Fidelity Investments, USA.
Change 25.203 OPTIONS COMPRESS=NO was inserted in ASUMTALO back in 1995
ASUMTALO by Change 12.273, because the first (temporary) DATA step
Sep 25, 2007 was extremely expensive, but then Change 12.273 was not
recalled when MXG set COMPRESS=YES as the default value,
so INCLUDEing ASUMTALO turned off compression for any
subsequent programs. Now, VMXGOPTR is invoked to store
your current value of the COMPRESS option, which is then
reset prior to the creation of PDB.ASUMTALO, so it will
be compress based on your choice of the COMPRSS option.
Thanks to Patrick Holloman, Zions Bank Corp, USA.
Change 25.202 ANALDB2R Statistics Reports VARIABLE QBnTDPIO NOT FOUND
ANALDB2R and VARIABLE QLSTCRSR NOT FOUND errors because those
Sep 22, 2007 variable names should never have been in the VMXGSUM
Oct 4, 2007 invocation for the statistics reports.
Thanks to Clayton Buck, UniGroup, USA.
Thanks to Yaohua Hu, ISO, USA.
Change 25.201 -Unexpected FILESYSTEM data with characers caused errors
EXTRH019 INVALID ARGUMENT FOR FUNCTION, temporarily circumvented,
FORMATS but the circumvention causes RH017001 to be a mising
IMACTNG value until further investigation of the strange data.
VMACTNG -Unrelated, Red Hat object USERS is supported in the new
VMXGINIT RH019 dataset created by this change.
Sep 24,2007
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.200 Use of %LET mackeep= whatever ; was not supported.
READDB2
Sep 18, 2007
Thanks to Gary Diehl, Sun MicroSystems/STK, USA.
====== Changes thru 25.199 were in MXG 25.09 dated Sep 17, 2007=========
Change 25.199 If SYNC59=YES was specified in your %VMXGRMFI invocation
VMXGRMFI to create PDB.RMFINTRV, the STARTIME was reset to 00/15
Sep 15, 2007 but SMF70GIE was not. Now it is, so PDB.RMFINTRV will be
consistent with PDB.ASUM70PR/ASUM70LP/ASUMCEC/ASUMCELP.
Thanks to Douglas C. Walter, Citicorp, USA.
Thanks to Brent Turner, Citicorp, USA.
Thanks to Tom Koelle, Citicorp, USA.
Change 25.198 TYPE89 variable SMF89HOF (HYPERVISOR DATATIME OFFSET) and
VMAC89 SMF89DTO were wrong because the comment for SMF89PFL was
Sep 15, 2007 not present.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.197 %UTILCSV creates a CSV (Comma Separated Values/Variables)
UTILCSV or TAB or ANY-character-DELIMITED "text file" from any
Sep 14, 2007 SAS dataset, with the ability to order left-to-right and
to use FORMAT statements to control the output text.
Change 25.196 If you set %LET MACKEEP= %STR( lots of lines of text );
UTILBLDP before invoking %UTILBLDP, some of your MACKEEP code may
Sep 14, 2007 not get executed, leading to strange errors or unexpected
results. We now parse the text inside the macro language
into line-sized chunks to eliminate the exposure.
And while we were at it, we've created new arguments that
you can use for tailoring, as an alternative to using
%LET's for these macro variables:
Macro Variable Name Macro Argument Name
macfile macfilex
mackeep mackeepx
ihdrdb2h macdb2hx
ihdr110 mac110hx
One reason to use the Macro Argument in your UTILBLDP
rather than a %LET statement is that macro argument are
significantly more robust in that they do not need to
be wrapped in %STR() and we have NOT been able to find
any text string the argument couldn't handle, vs the
many combinations that have broken %QUOTE, etc. in %LETs!
However, you can use both a %LET macxxxx= and macxxxxx=
argument; the text in your %LET will preceed any text you
passed in the corresponding argument.
And, just to be sure, we now "chunk" any EXPDBOUT text.
Thanks to Michael Creech, Fidelity National Information Svcs, USA.
Change 25.195 Support for EMC's SRDF/A user SMF record.
VMACSRDF
VMXGINIT
EXSRDFAA
TYPESRDF
TYPSSRDF
IMACSRDF
Sep 13, 2007
Change 25.194 Variable SJGRQRST='JVM*REQUESTS*WITH RESET' in CICTCPSJ
VMAC110 CICS Statistics dataset is now created; while it does not
Sep 13, 2007 exist in CICS/TS 3.2 (resettable JVMs were withdrawn in
3.2 because continuous use JVMs save lots of CPU), it is
useful for detecting these bad guys in 2.3 and 3.1.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.193 MXG 25.08 Change 25.182 was incomplete, which caused the
IMACEXCL ERROR: LABEL IMACICU3 NOT FOUND when UTILEXCL was run.
UTILEXCL
Sep 13, 2007
Thanks to Christelle Abily, Groupe Informatique Credit Mutuel, FRANCE
Change 25.192 INPUT STATEMENT EXCEEDED RECORD LENGTH SMF ID=92 ST=14
VMAC92 because the SMF92DNR/SMF92DRN Rename Length/Name fields
Sep 11, 2007 only exist when the file is RENAMEd, and because the SMF
manual did not document that feature. Now, MXG confirms
that data exists prior to its INPUT.
Thanks to John Schoenbeck, AT&T Services, Inc, USA
Change 25.191 Support for RMF Monitor III CFI table segmentation in the
ASMRMFV ASMRMFV, and their input in VMACRMFV. New datasets
EXZRBCFC ZRBCFC is created from the CFICONNUS Connection Table,
IMACRMFV and the new variables in the CFISTRES Table are created
VMACRMFV when they exist (i.e., when CFIDETAIL was specified in
VMXGINIT RMF III parameters).
Sep 10, 2007
Sep 14, 2007
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.190 Variable QDBPPFIX='PGFIX*ATTRIBUTE' is now kept in the
VMACDB2 DB2STAT2 dataset; it was added in DB2 V8.1, in the same
Sep 8, 2007 location as QDBPVTPT, which is now always blank.
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 25.189 Revision to PDBOUT= options, when PDB=SMF is specified,
READDB2 and possible INCOMPATIBILITY when PDBOUT was null. Now,
ANALDB2R these options for PDBOUT= control output destination:
Sep 11, 2007 PDBOUT=, All datasets written to //WORK, always.
Sep 17, 2007 PDBOUT=PDB All datasets written to //PDB.
Sep 24, 2007 PDBOUT=YES All datasets written to their default
destination, with user tailoring honored.
PDBOUT=XXX ALL datasets written to //XXX.
This change could cause perfectly running jobs to fail,
if PDBOUT=, was specified and you had tailoring that
redirected the output dataset destinations. Sorry for
that, but using PDBOUT=YES instead of PDBOUT=PDB is now
the DOCUMENTED and SUPPORTED option to create output.
This revision was precipitated when ANALDB2R had been
invoked with PDBOUT=, and it failed with DDNAME PDB NOT
FOUND and _VDB2A UNDEFINED errors when no //PDB DD
existed.
Note: Only READDB2's code was changed; ANALDB2R calls
READDB2 with the same possible PDBOUT= argument,
so it is listed here for documentation
(that you'll only find after the error?).
Text revised Sep 17 for PDBOUT=PDB description.
-MXG 25.08 only, bit test for SADUCL=6 was one bit short;
only the list of Audit Trace Classes might be incorrect.
This was accidentally corrected in this change. 24Sep07.
Thanks to R. Berry, Internal Revenue Service, USA.
Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 25.188 If RMFINTRV=NO and BUILDPDB=YES and ASUM70PR included,
UTILBLDP the invocation failed because the TYPE70xx datasets were
Sep 7, 2007 not sorted into the PDB due to the RMFINTRV=NO. Now, as
expected, BUILDPDB=YES sorts them into the PDB library.
Thanks to Trevor Holland, ANZ, AUSTRALIA
====== Changes thru 25.186 were in MXG 25.08 dated Sep 5, 2007=========
Change 25.187 IBM SMF Manual incorrectly documented SMF92RVN value of 3
VMAC92 but that was corrected in z/OS 1.9 manual to correct 2,
Sep 5, 2007 so two MXG tests for SMF92RVN GE 3 were change to GE 2.
This corrected the bit variables SMF92MFG and SMF92MF2.
Variable SMF9PPN is a path name so it was increased to
$VARYING1024. with input length set by SMF92PPL.
Thanks to Hyrum E. Smith, Charles Schwab & Co., USA
Change 25.186 Variable DB2PARTY not found when PMACC02 requested and
ANALDB2R PDB.ASUMDB2A existed was corrected with a compiler faker.
Sep 5, 2007
Change 25.185 New Capacity Group datasets created by Change 25.163 did
IMACSHFT not have a DURATM variable for the ASUM70GC and ASUM70GL
VMXGDUR datasets; the interval is forced to HOURLY, but interval
VMXG70PR datasets should always have a DURATM variable.
Sep 5, 2007 I tested this change with %VMXG70PR(INTERVAL=SHIFT,...)
and found it caused VARIABLE MXGDURTM UNINITIALIZED notes
because MXGDURTM was not defined in IMACSHFT example, and
MXGDURTM was not always protected in VMXGDUR.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 25.184 RMF Capacity Group reports added to ANALRMFR. Support for
ANALRMFR new data was added by MXG Change 25.163.
Sep 5, 2007
Change 25.183 These WORK library datasets are now deleted; several PROC
TYPETMS5 DELETEs commented out for testing are now uncommented.
Sep 5, 2007 CHANGED DSNBREC DSNBRECS DSNBRECT DSNBRECU
DSNBRECV DSNBRECW MGTMSVL TMSREC TMSRECS
Thanks to John Shuck, Sun Trust, USA.
Thanks to Stan Helms, Sun Trust, USA.
Thanks to Mike Duwve, Sun Trust, USA.
====== Changes thru 25.182 were in MXG 25.08 dated Sep 5, 2007=========
Change 25.182 Support for CICS User Field ARZAL (CMODNAME='ARZAL' and
IMACICU3 CMODHEAD='APPLINFO' is added.
UTILEXCL
Sep 2, 2007
Thanks to Peter Gschirr, ARZ, AUSTRIA.
Change 25.181 Support for CA Unicenter NSM has been in MXG under "TNG"
EXTAI026 for years, because TNG was NSM's original name, and the
EXTNT132 "performance cube" format was not changed at name change.
EXTRH001 Support for CA NSM PLATFORM='RHEL401', RedHat 4.01 Linux
EXTRH002 performance cube is added by this change, which initially
EXTRH003 populates the Solaris "SOnnn" datasets, as they exist and
EXTRH004 have the most objects/metrics in common with Linux, but
EXTRH005 there are Solaris-only variables that have missing values
EXTRH006 and there are RHEL objects/metrics not yet supported.
EXTRH007
EXTRH008 This change also externalizes the list of PLATFORM names
EXTRH009 that map to AIX or SOLARIS with new _AIPLAT and _SOPLAT
EXTRH010 macros (like the existing _NTPLAT macro). And, that test
EXTRH011 is now IF PLATFORM IN : ( _NTPLAT ) THEN DO; with the
EXTRH012 "colon modifier" inserted so the test matches only the
EXTRH013 starting characters of the platform names. I did this
EXTRH014 when I thought RHEL was a user-assigned name, which it
EXTRH015 isn't, but these macros are no-cost tokens that will make
EXTRH016 my testing easier for new PLATFORM names.
EXTRH017
EXTRH018 New variables were added to these existing datasets:
IMACTNG Dataset Description
VMACTNG AI019 AIX - CA MEMORY GROUP
VMXGINIT NT035 NT - PROCESS
Sep 2, 2007 New datasets are created from these new objects:
Dataset Object Name
AI026 AIX - PROCESS
NT132 NT - CA CUBE STORE GROUP
-New datasets are created from Red Hat Platform Objects:
Dataset Object Name
RH001 RH - CA CPU GROUP
RH002 RH - CA INTERRUPT
RH003 RH - CA CUBE STORE GROUP
RH004 RH - CA PER CPU GROUP
RH005 RH - CONTEXT SWITCHING
RH006 RH - INTERRUPTS
RH007 RH - PAGING
RH008 RH - PROCESS CREATION
RH009 RH - SWAPPING
RH010 RH - CA DISK GROUP
RH011 RH - CA FILE SYSTEM GROUP
RH012 RH - CA INTERFACE GROUP
RH013 RH - CA MEMORY GROUP
RH014 RH - CA PROCESS GROUP
RH015 RH - CA SWAP GROUP
RH016 RH - CPU
RH017 RH - FILESYSTEM
RH018 RH - NETWORK
Thanks to Xiaobo Zhang, CheckFree, USA.
Change 25.180 The Omegamon OMCI subtype 203 is now written in SMF 112s,
VMACOMCI but can still be created in the old User SMF record; MXG
Aug 29, 2007 Change 25.099 moved the 203 code into VMAC112, but also
disabled subtype 203 in VMACOMCI. This corrects.
But now see Change 26.257, which revised support.
Thanks to Tom Kelman, Commerce Bank of Kansas, USA.
Change 25.179 Protection for %UPCASE() and %LOWCASE() for literals.
ANALDBTR Almost all of the SAS code in MXG is in UPPER CASE, but
BLDSMPDB some members are mixed case, with "case sensitive" noted
GRAFHSM in their comments, but that did not prevent accidental
GRAFLPAR low-case-ing some lines in BLDSMPDB that contained tests
GRAFTALO if %upcase(something) eq yes %then %do;
GRAFTMNT which failed because the yes value was now lower case.
GRAFTRND Macro variable tests are in many MXG members, especially
GRAFWORK those that define %MACROS where user-typed input text is
GRAFWORX shifted with %UPCASE() for consistent testing, but I had
GRAFWRKX never thought to protect the text being compared!
PRINTNL
READDB2 Now, all members were examined that used %UPCASE/%LOWCASE
UTILBLDP and those that tested for literal text values now use
UTILCONT
UTILDUMP if %upcase(something) eq %upcase(yes) %then %do;
VMACMWNT
VMXGALOC The DATA step UPCASE() function is also used in even more
VMXGDEL members, but as those values are not 'human-typed', I did
VMXGGETM not see the need for also wrapping those text values.
VMXGSUM
VMXGSUME New MXG Recommendation: Use %LET MACxxxx= %STR( text ) ;
VMXGUOW with blanks as shown, when storing any text string that
Aug 28, 2007 can contain semi-colons, into those MXG tailoring macro
variables, since those macro variables will be resolved
at "compile time", which is where %STR() is to be used.
Previously I suggested using %QUOTE() or %BQUOTE() to
pass text with semi-colons, but they are not resolved
until "execute time", and, while QUOTE/BQUOTE frequently
did work, the use of %STR, especially for MACKEEP/MACFILE
macros is the more appropriate among the many functions.
Thanks to Tom kelman, Commerce Bank of Kansas, USA.
Change 25.178 Support for V5R4MO QAPMDISK with LRECL=456 adds these 20
VMACQACS variables:
Aug 28, 2007 DSBKCT1='BUCKET*1*OPERATIONS'
DSBKCT2='BUCKET*2*OPERATIONS'
DSBKCT3='BUCKET*3*OPERATIONS'
DSBKCT4='BUCKET*4*OPERATIONS'
DSBKCT5='BUCKET*5*OPERATIONS'
DSBKCT6='BUCKET*6*OPERATIONS'
DSBKRT1='BUCKET*1*RESPONSE*TIME'
DSBKRT2='BUCKET*2*RESPONSE*TIME'
DSBKRT3='BUCKET*1*RESPONSE*TIME'
DSBKRT4='BUCKET*4*RESPONSE*TIME'
DSBKRT5='BUCKET*5*RESPONSE*TIME'
DSBKRT6='BUCKET*6*RESPONSE*TIME'
DSBKST1='BUCKET*1*SERVICE*TIME'
DSBKST2='BUCKET*2*SERVICE*TIME'
DSBKST3='BUCKET*3*SERVICE*TIME'
DSBKST4='BUCKET*4*SERVICE*TIME'
DSBKST5='BUCKET*5*SERVICE*TIME'
DSBKST6='BUCKET*6*SERVICE*TIME'
DSSRVT ='DISK*SERVICE*TIME'
DSWT ='DISK*WAIT*TIME'
Thanks to Clayton Buck, UniGroup, Inc, USA.
Change 25.177 ERROR: ARRAY SUBSCRIPT OUT OF RANGE in BUILDPDB/RMFINTRV
VMXGINIT with a month's SMF data from scores of systems. The
VMXGRMFI culprit is the MXG algorithm to calculate MSU4HRAV, the
Aug 24, 2007 rolling hourly average MSU over the past four hours,
created in RMFINTRV before IBM added the SMF70LAC value
(and SMF70LAC is the variable to use, not my MSU4HRAV,
as SMF70LAC is IBM's calculation that is used in WLM
capping decisions, and it is slightly different than the
MSU4HRAV, where I used total CPU and IBM didn't, and
where I calculate true average even across an IPL and
they don't!).
When MSU4HRAV was created, the size was set for a daily
or weekly RMFINTRV creation, so an array size of 9999
elements would hold hourly data for:
over 100 system's daily data at 15 minute intervals
over 14 system's weekly data at 15 minute intervals
but
only 3 system's monthly data at 15 minute intervals!
(and this site had 5 minute intervals!).
This is one of the MANY reasons why I avoid ARRAYs; while
increasing the ARRAY size will hold more system's data,
that requires more virtual storage, and that will grow as
the number of systems increase, exchanging OUT-OF-MEMORY
errors for OUT OF RANGE.
The immediate user circumvention was to process the SMF
data one week at a time, which worked just fine.
Though hopefully unneeded, I have externalized the size
of the three temporary arrays with new macro variable
with default value of %LET ARRAYRMF=9999; unchanged.
I have also inserted a trap to detect the array size was
exceeded and inform you via an ERROR message on the log.
Change 25.176 Support for APAR OA18244, Blocked Workload metrics, adds
VMAC7072 -These variables to the TYPE70 dataset:
Aug 24, 2007 SMF70PMI='AVG*BLKED*DISPATCH*UNITS*MAY GET'
SMF70PML='OPT*PARAMETER*BLWLINTHD'
SMF70PMP='MAX*DISPATCH*UNITS*BEING*BLOCKED'
SMF70PMT='OPT*PARAMETER*BLWLTRPCT'
(Note: The default you type is "5", but that will be
a value of .005 in SMF70PMT, i.e. one-half of a
percent. RMF reports that a .5% but the variable
is NOT labelled Percent so you need to know that
.005 is one-half percent default.
SMF70PMU='BLKED*DISPATCH*UNITS*PROMOTED*PERSEC'
SMF70PMW='AVG*DISPATCH*UNITS*BEING*BLOCKED'
STFBIT05='OPT PARM*BLWLTRPCT*CHANGED?
STFBIT06='OPT PARM*BLWLINTHD*CHANGED?
-This variable, previously added to the TYPE72GO dataset
by Change 25.140 is populated by this APAR:
R723TPDP='CPU TIME*AT PROMOTED*DISPATCH*PRTY'
and this new flag variable is created by this APAR:
ZIPHONPR='ZIP*HONOR*PRIORITY?'
Change 25.175 Internal logic was revised so when INTERVAL= is used, the
ANALRMFR variables LPARCPUX and SMF70BDA are added to the ID= parm
Aug 24, 2007 for Cluster Reports.
-Also, MVSCHRLV and NCYCLE are added to report headings.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.174 Corrections discovered by SAS/ITRM validation during the
ASUMTAPE build of their dictionary.
VMAC7072 -Variable JBACPU dataset QAPMJOBL now FORMATed TIME13.3.
VMACQACS -Variable MAXVLSEQ is no longer created/kept in TYPETMS5.
VMACTMS5 -Variables for CP/ICF/IFL/IFA/ZIP counts/time are labeled
VMXG70PR in VMXG70PR & VMAC7072, PROC DELETEs uncommented to clean
VMAC110 up WORK file. Variables IFAWSTTM,ZIPWSTTM formatted.
VMACDB2 -ASUMTAPE variables BEGTMNT, ENDTMNT, TOTMNTTM labeled.
VMACSTC -CICSDS variables DSGEJST DSGSRBT labeled and formatted;
Sep 5, 2007 they are the total TCB for all CICS TCBs and total SRB
for all SRBs in the interval.
-DB2ACCT variable QWHUCPU formatted.
-TYPESTC variable STC15CTP label corrected.
Sep 6 changes, not in 25.08:
-TYPE7072 - variables NRPHYCPX, NRPRCX no longer kept.
- variable GMTOFF70 GMTOFF72 formatted.
-TYPE85 - variables R85ST74F, R85ST78F labeled.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 25.173 -Support for NMON "CPU_VP_USE" and "CPU_EC_USE" objects
VMACNMON (Virtual Processor and Entitled Capacity) adds these new
Sep 1, 2007 variables to NMONINTV dataset:
NRECUS='CPU_EC_USE*COUNT'
NRVPUS='CPU_VP_USE*COUNT'
PCPUUSER='CPU_ALL*USER*PERCENT'
PECTOTAL='CPU_EC_USE*TOTAL*PERCENT'
PECUBUSY='CPU_EC_USE*BUSY*PERCENT'
PECUIDLE='CPU_EC_USE*IDLE*PERCENT'
PECUSYS='CPU_EC_USE*SYSTEM*PERCENT'
PECUUSER='CPU_EC_USE*USER*PERCENT'
PECUWAIT='CPU_EC_USE*WAIT*PERCENT'
PVPUBUSY='CPU_VP_USE*BUSY*PERCENT'
PVPUIDLE='CPU_VP_USE*IDLE*PERCENT'
PVPUSYS='CPU_VP_USE*SYSTEM*PERCENT'
PVPUUSER='CPU_VP_USE*USER*PERCENT'
PVPUWAIT='CPU_VP_USE*WAIT*PERCENT'
-Support for NMON NETSIZE object adds thes new variables
to NMONNETW dataset:
NETSRDRT='NETSIZE*READS/S'
NETSWRRT='NETSIZE*WRITE/S'
-The count of JFSFILE fields drops to less than the count
in the header record, occasionally, causing MXG to have
to delete of that record with an MXG ERROR MESSAGE on the
log. Under investigation with NMON support.
-The "UNKNOWN RECTYPE=" message for Nigel's Monitor NMON
is clarified to indicate it's not an error, but a new
monitor record that is not yet supported by MXG, but
will be if you send the input data file to MXG support.
Thanks to Michael W. Woelke, Boeing, USA.
Thanks to John Keenan, Boeing, USA.
Change 25.172 Example to process DB2 datasets to separate DDNAMES:
ADOCDB2 libname db2acctp 'c:\mxg\db2acctp\';
Aug 20, 2007 libname db2acctb 'c:\mxg\db2acctg\';
libname db2acctg 'c:\mxg\db2acctb\';
libname db2acct 'c:\mxg\db2acct\';
libname db2gbpat 'c:\mxg\db2gbpat\';
libname db2gbpst 'c:\mxg\db2gbpst\';
/* unsorted, written directly to individual DDNAME for parallelism */
%LET WDB2ACP=DB2ACCTP;
%LET WDB2ACB=DB2ACCTB;
%LET WDB2ACG=DB2ACCTG;
%LET WDB2PAT=DB2GBPAT;
%LET WDB2PST=DB2GBPST;
%LET PDB2ACC=DB2ACCT;
/* deflected to work, as they are combined into db2stats */
%LET PDB2STO=WORK;
%LET PDB2ST1=WORK;
/* sent to pdb, stats, should be small in size */
%LET PDB2ST2=PDB;
%LET PDB2ST4=PDB;
%LET PDB2STS=PDB;
%LET PDB2STB=PDB;
%LET PDB2STR=PDB;
%LET MACKEEP=
%BQUOTE(
MACRO _SDB2ACp %
MACRO _SDB2ACb %
MACRO _SDB2ACg %
MACRO _SDB2pat %
MACRO _SDB2pst %
MACRO _SDB2ACc %
);
%INCLUDE SOURCLIB(TYPEDB2);
or could be
%INCLUDE SOURCLIB(BUILDPDB);
or could be
%ANALDB2R(PDB=SMF);
Change 25.171 Documentation. The DOCVER and DOCVERnn text printed only
UTILVREF 3 positions for LENGTHs, causing a 32000-byte variable to
Aug 20, 2007 be printed as 3E4 in exponential format. While I can't
expand LENGTH to print 5 digits without truncating LABEL,
I now detect the TYPE='NUM' and print four positions for
those variables to be more accurate where I can. You can
always use PROC CONTENTS DATA=whatever; to see the actual
stored LENGTH of each variable.
See MXG Technical Note 2 in Newsletter FIFTY for a list
of "Very Long Stored Length" variables created by MXG.
Change 25.170 If there no Mount-Related SYSLOG messages were captured
ASUMTAPE by ASMTAPEE/MXGTMNT, i.e. TYPESYMT has zero observations
Aug 20, 2007 then there were no observations created in PDB.ASUMTAPE,
even though the TYPETMNT and TYPE21 records matched.
The missing SYSLOG records was due to backlevel ASMTAPEE
at ML-38 that missed messages now captured in ML-39, but
this revision tests for zero obs in TYPESYMT dataset, and
forces the OUTPUT of PDB.ASUMTAPE in that case. Note
that this only works when all systems do not capture the
SYSLOG data; if some systems do and others don't, this
revision will NOT work, and only systems with obs in the
TYPESYMT dataset will have output in PDB.ASUMTAPE.
Thanks to John Doherty, Capita, SCOTLAND.
Change 25.169 New DB2 Parallel event "analysis" selects all DB2ACCT obs
VMACDB2 for each "ACE group" that had any parallel activity,
Aug 18, 2007 (i.e., had one or more DB2ACCT obs with DB2PARTY=O/P/R),
keeps a large but manageable set of important variables,
and then PRINTs the detail DB2ACCT observations for each
"ACE Group", in time sequence, where each unique set of
values of these BY variables defines an "ACE Group":
SYSTEM QWHSSSID QWHSLOCN QLACLOCN QWHCCV QWHCCN ACE
and where ACE is either QWHSACE (S/O) or QWACPACE (P/R).
BUILDPDB does not sort PDB.DB2ACCT automatically, due to
it's size, but that turns out fortunate, as the default
sort order defined in MACRO _BDB2ACC in VMACDB2:
SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN QWHCCV
QLACLOCN QWHCCN QWACBSC QWHSSTCK,
is just fine for duplicate removal, so it's not "wrong",
but it is NOT the correct order to group all DB2ACCT obs
into their "ACE Group". Instead, the new report uses
uses this sort order (MACRO _XDB2ACC):
SYSTEM QWHSSSID QWHSLOCN QLACLOCN QWHCCV QWHCCN ACE
QWACBSC QWHSSTCK QWHCPLAN QWHCAID
that does correctly sort DB2ACCT into each "ACE Group".
This iteration defines old-style MACROs _Q, _X, _Y, _X
which are used by the MACRO _RDB2ACC that you execute:
// EXEC MXGSASV9
//PDB DD DSN=YOUR.DB2ACCT.PDB,DISP=SHR
//SYSIN DD *
%INCLUDE SOURCLIB(VMACDB2);
_RDB2ACC
This report was used for diagnostic understanding of the
events in DB2 Parallel, and thus is not likely to be used
by many MXG users, but it's there if needed. Also, the
structure of selecting all of a group that has one of
something (DB2 Parallel Transaction, in this case) could
easily be extended to select by some other criteria.
Change 25.168 Using %ANALDB2R(PDB=PDB,PMSTA02=YES); caused VMXGSUM to
VMXGSUM fail with ERROR: VARIABLE STRTTIME NOT FOUND. In this
Aug 17, 2007 one place in ANALDB2R, VMXGSUM was invoked with variable
STRTTIME used in the INCODE's internal DATA/PROC steps,
and it was in the KEEPIN= list, but STRTTIME was NOT in
any of the VMXGSUM output parameters. Now, variables in
the KEEPIN= list are added to the generated KEEP list to
protect for this unique VMXGSUM invocation.
The problem was introduced in MXG 25.04 VMXGSUM changes.
Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
Change 25.167 Variable FCUSERID='LOGIN*USER ID*OR NAME' is INPUT and
VMAC119 kept in the TYP11903 dataset.
Aug 16, 2007
Thanks to Jim Kovarik, Aegon, USA.
Change 25.166 Trending example for DB2ACCTP dataset.
TRNDDB2P
Aug 16, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.165 The IMF FB Program Record is updated with new variables:
VMACCIMS PGMSAD56='SADFLAG5*AND*SADFLAG6'
Aug 14, 2007 FLGSPCHR='PROGRAM*SUBTYPE'
The $MGIMFCS format decodes FLGSPCHR, which is OUTPUT
in both CIMSTRAN and CIMSPROG, but only the first
three values of J, K, or O exist in CICSPROG:
VALUE $MGIMFCS
'O'='O:ODBA'
'J'='J:JMP'
'K'='K:JBP'
'Q'='Q:PSEUDO WFI'
'W'='W:WFI(WAIT FOR INPUT)'
;
SAPEXIT ='SAP*PGM*USING*SAPEXIT?'
OTMATRAN='OTMA*TRAN?'
The offset to SRVCLASS was also corrected.
Thanks to Doug Johnson, Blue Cross Blue Shield of Kansas, USA.
Change 25.164 The _VNDMRJ macro token was missing in the _WNDMRJ part
VMACNDM of the _VARNDM macro definition, so the NDMRJ datasets
Aug 14, 2007 kept ALL MXG VARIABLES IN THE DATA STEP, 7062 variables
to be exact, when NDM code was added to BUILDPDB in ITRM
tests!
Thanks to Chris Weston, SAS Institute, USA.
Change 25.163 Support for Capacity Group analysis. z/OS 1.8 added the
VMAC7072 SMF70GNM='CAPACITY GROUP NAME'
VMXG70PR SMF70GMU='MAXIMUM LICENSE UNITS OF GROUP;
VMXGINIT variables, but Change 24.092 output them in TYPE70, when
Aug 20, 2007 they should have been output in PDB.TYPE70PR dataset, as
they are LPAR-level capacity limits.
-ASUM70PR now creates two new Group Capacity datasets
PDB.ASUM70GC - CEC Totals for each Capacity Group
PDB.ASUM70GL - LPAR Detail within each Capacity Group
Dataset ASUM70GL matches the RMF Group Capacity Report,
while dataset SUM70GC provides the total MSU usage for
each Group, and the percent of Group capacity limit used.
Both new datasets are created with fixed INTERVAL=HOUR,
to match SMF70GMU capacity units of MSU per hour.
Thanks to Jim Dammeyer, State Farm Insurance, USA.
Change 25.162 The final example in comments was missing a close-paren.
UTILBLDP
Aug 12, 2007
Thanks to Trevor Holland, ANZ, AUSTRALIA
====== Changes thru 25.161 were in MXG 25.07 dated Aug 10, 2007=========
Change 25.161 Support for new z/OS 1.9 RMF III and APAR OA17070 fields.
VMACRMFV New variables INPUT from the CFIG3 Header Section are
Aug 9, 2007 added to the ZRBCFI dataset:
CFIRANGE='REPORTING*RANGE*SECONDS'
CFIPONAM='POLICY*NAME'
CFIPOACT='POLICY*ACTIVATION*TIME'
CFIPREQS='NOT ALL*STRUCTURES*CONTAINED'
CFIPREQC='NOT ALL*CONNECTIONS*CONTAINED'
New variables INPUT from the CFIG3 Entry Section are
added to the ZRBCFI dataset:
CFIENSCN='CONNECTED*MVS*SYSTEM*COUNT'
CFIENSTI='STRUCTURE*COUNT*IN*POLICY'
CFIENSTO='STRUCTURE*COUNT*OUT*POLICY'
CFIENTCS='TOTAL*CONTROL*SPACE'
CFIENFCS='FREE*CONTROL*SPACE'
CFIENTDS='TOTAL*DUMP*SPACE'
CFIENFDS='FREE*DUMP*SPACE'
CFIENSCT='SUM WAIT*FREE FOR*SYNCH IMMED'
CFIENFOC='COUNT*OF TIMES*FOR UNSUCCESSFUL'
CFIENFOT='SUM OF*SERVICE*FOR*UNSUCCESSFUL'
CFIENPDE='DEDICATED*PROCESSORS'
CFIENPSH='SHARED*PROCESSORS'
CFIENPWG='SHARED*PROCESSOR*AVERAGE*WEIGHT'
New variables INPUT from the CFIG3 Table Entry Section
are added to the ZRBCFI dataset:
CFISTCOM='MAX*CONNECTIONS*ALLOWED'
CFISTCOT='TOTAL*CONNECTIONS*TO*STRUCTURE*
CFISTCOP='CONNECTIONS*WITH*PROBLEMS'
CFISTQTM='SERVICETM*SUM FOR*QUEUED*REQUESTS.
CFISTFLE='STATUS*FLAGS*EXTENDED'
CFISTRBP='REBUILDPERCENT*IN ACTIVE*CFRM'
CFISTPL ='CF*PREFERENCE*LIST'
CFISTXL ='STRUCTURE*EXCLUSION*LIST'
CFISTETM='STRUCURE*EXECUTION*TIME*SUM'
Change 25.160 Sample reports for Velocity Software data.
ANALXAMR
Aug 9, 2007
Thanks to Robert Obee, IMS Health(R), USA.
Change 25.159 Support for APAR OA12865 for RMF 79 Subtype 9 Device
VMAC79 Activity added variable R799PSM='SUCCESSFUL*PAV*SAMPLES'
Aug 9, 2007 and relabeled variable R799PCT='UNSUCCESSFUL*PAV*SAMPLES'
and now INPUTs R799NDA as 4 bytes instead of 2, so that
variables R799NDA,R799DPB,R799CMR,R799PCT,R799PSM now are
correct, and variable R799CNX6='HYPERPAV*BASE*DEVICE?' is
created.
-RMF II 79 subtype 9 records written at 1 minute intervals
have the accumulated values reset when RMF Monitor I pops
its interval, which caused MXG to set the DIF()'d
values missing; now, only the first observation for each
device will have missing values for the deaccumlations,
since I don't know the prior value from yesterday!
-R799NUX required special handling as it is accumulated
if the device is HyperPav, and is not otherwise.
Thanks to Mike Romeo, Schwab, USA.
Change 25.158 The %QUOTE function had to be replaced with the %BQUOTE
UTILBLDP function, because %QUOTE does not "mask" percent signs,
Aug 8, 2007 and the user-provided text can contain percent signs
that needed to be masked. When a user sets the text
%LET MACKEEP= MACRO _S110 %; and executes %UTILBLDP(...)
this %LET MACBLDP= %QUOTE(&MACKEEP); created the MACBLDP
with MACRO _S110 ) instead of MACRO _S110 % because the
%QUOTE function saw the end of the text as %) and that
pair of adjacent characters are a "special character"
that is, by design, changed to a single paren by %QUOTE.
The %BQUOTE masks these characters that aren't by %QUOTE:
unmarked percent signs
unmatched, unmarked single and double quotation marks
unmatched, unmarked opening and closing parentheses
This issue comes up most often in the %LET MACKEEP= text,
as its usage can have a wide range of character text.
I have previously suggested that when setting MACKEEP to
text that can contain a semicolon, you must use %QUOTE(),
but for old-style macro redefinitions like _S110, there
was no need for the complexity of the %QUOTE() syntax.
And it appears if there happened to be blanks in the
right places, even percent signs could be passed without
either function. Now, if you have semicolons or percents
depending on the context and state of the macro language,
%BQUOTEs may be required in your %LET statements.
Specifically this is required:
%LET MACKEEP=%BQUOTE( MACRO _S110 %) ;
Thanks to Carmen Vitullo, Acxiom IT Outsourcing, USA.
Change 25.157 Change 24.064 added &MXGNOBY operand to circumvent errors
MONTHDSK NOT SORTED, but the invocation of &MXGNOBY was not added
MONTHWEK the WEEKBLDT and MONTHDSK members, where it didn't work!
WEEKBLDT
Aug 6, 2007
Thanks to Randy Parker, Trustmark National Bank, USA.
Change 25.156 The ARRAY LWAI(33) $ LCPUWAI0-9 + were one-byte lengths,
VMAC7072 but ARRAY LDED(33) $ LCPUDED0-9 + were eight bytes long,
Aug 6, 2007 and I cannot see why they are different, but as they are
one-byte variables, their ARRAY statement now explicitly
sets their length with ARRAY xxxx (33) $1;
Change 25.155 Variables created with the SCAN() function are set by SAS
VMACCLAR to character length of $200, even though the input length
VMACNMON is only $128. While I believe SAS should set the output
Aug 6, 2007 length to $128, as WPS does, adding LENGTH statements did
circumvent this SAS problem. Other character handling
functions, like SUBSTR() do set the new variable's length
from the input variable's length.
Change 25.154 PROC MEANS does not pass variable attributes (LENGTH etc)
VMXG70PR to the output dataset unless / INHERIT is added to the
Aug 6, 2007 OUTPUT statement; MXG normally uses %VMXGSUM, which does
specify INHERIT, but the two new PROC MEANS added for the
new IFA/ZIP variables did not specify INHERIT, causing
wrong or blank LENGTH/LABEL/FORMATs for those variables.
Change 25.153 False ERROR: INVALID TYPE42 SUBTYPE 5 RECORD DELETED
VMAC42 were printed because the tests revised by Change 25.095
Aug 3, 2007 should be OFF+LEN GT LENGTH+1 vice GT LENGTH. The
record was valid, but, as the message stated, it was
deleted.
Thanks to Joachim Mayr, Amadeus, GERMANY.
Change 25.152 The analysis of input queue time for Duplicate JOB HOLD
ANALINIT used LASTEND=LAG(JINTTIME) for the start of the input
Aug 3, 2007 queue delay of the next Duplicate JOB NAME, but JINTTIME
is the Start Time of the last job, and, as documented in
Change 12.274, that LAG() function statement
(which returns the value of that variable from the
prior observation)
should have been LASTEND=LAG(JTRMTIME), so that this
job's delay is calculated from the End of Execution of
the prior job.
Thanks to Larry Riggen, OneAmerica, USA.
Change 25.151 The example JCLVMXA invokes PROC MEANS for all datasets,
VMACVMXA that would not normally be executed except for the first
Aug 3, 2007 test, but it failed be cause _MPRCAPC and _MPRCAPM were
not defined (those macro names in lines 20396,20397 were
misspelled). The MONWRITE datasets were correctly built;
Also, MXG 25.06 had a DEBUG=1; statement left from tests
that printed a lot of messages on the SAS log, but with
no impact on the SAS datasets that MXG created.
Thanks to Yaohua Hu, ISO, USA.
Change 25.150 The ASUM70PR summarization could (still!) create PCTCPUBY
VMXG70PR over 100%, if adjacent intervals being summarized had the
Aug 3, 2007 exact same value of STARTIME SMF70GIE and DURATM after
the INTERVAL= operand had reset STARTIME and SMF70GIE.
These DURATM was also incorrect (too small) in these bad
observations, but ALL OTHER VARIABLES ARE CORRECT.
It was the heuristic use of DURATM that seemed to work,
but is now recognized as the culprit, as it failed when
two adjacent DURATMs were identical. Now, by instead
using the OLDSTART, the original unmodified interval
start, and inserting it in internal sorts in place of
DURATM, and testing IF FIRST.OLDSTART vice FIRST.DURATM
there's a clean algorithm for new intervals and this old
recurring problem should be fixed for good.
-Summarization with INTERVAL=SHIFT did not work, because
MXG can not know the duration of each of your shifts, and
message VARIABLE MXGDURTM UNINITIALIZED was printed.
However, if you will add a statement in your IMACSHFT
tailoring member for each shift, that sets then variable
MXGDURTM=nnnnn;, where nnnnn is the duration in seconds
(e.g., MXGDURTM=28800; for an 8-hour shift), then you can
INTERVAL=SHIFT to summarize PDB.ASUM70PR & PDB.ASUM70LP
to your shift definitions.
-Summarization with CECINTRV=SHIFT is also now supported,
proved you tailor IMACSHFT to set MXGDURTM, as above.
The MXG note that SHIFT could not be used is removed.
Thanks to Debby Blackey, HCA HealthCare, USA.
Change 25.149 The SAS/ITRM product (formerly SAS/ITSV) executes MXG to
ADOCITRM create its SAS datasets, but the MXG dataset names are
Aug 2, 2007 changed by ITRM. This member's table maps the ITRM names
to the original MXG dataset name.
Change 25.148 A tutorial on how MXG normally creates SORTed datasets,
ADOCDB2 two exceptions, and an MXG tailoring example that writes
Aug 1, 2007 the DB2ACCTB and DB2ACCTP datasets to separate DDNAMES,
also bypassing their SORTs.
MXG normally builds datasets that are PROC SORTed, and
the sort order can be exploited in subsequent programs
to avoid unneeded sorts. MXG's SORTs specify the NODUP
SAS option, which removes any duplicate SMF records.
However, two datasets, DB2ACCT and CICSTRAN have never
been SORTed by default, as they were always known to be
very large. So their "dataset sort _Sdddddd" tokens,
_SDB2ACC and _SCICTRN, were NOT in the default list of
datasets to be sorted in VMACDB2 and VMAC110 defaults.
With hindsight, I should also have NOT included SORTs of
the DB2 per-buffer (DB2ACCTB) and per-package (DB2ACCTP)
datasets, which now can be as large or larger than, their
DB2ACCT counterpart!
But now that MXG has sorted those datasets by default,
I can not safely remove those SORTs, without high risk
of causing a user program to unnecessarily fail. But,
you can use this MXG tailoring example to write them
to separate DDnames, and bypass their dataset sorts:
// EXEC MXGSASV9
//SMF DD DSN=YOUR.SMF,DISP=SHR
//DB2ACCT DD DSN=YOUR.DB2ACCT,DISP=(,CATLG),...
//DB2ACCTB DD DSN=YOUR.DB2ACCTB,DISP=(,CATLG),...
//DB2ACCTP DD DSN=YOUR.DB2ACCTP,DISP=(,CATLG),...
//PDB DD DSN=YOUR.OTHER.DB2.STUFF,DISP=(,CATLG),..
//SYSIN DD *
%LET WDB2ACC=DB2ACCT; /*DDNAME for DB2ACCT */
%LET WDB2ACB=DB2ACCTB; /*DDNAME for DB2ACCTB*/
%LET WDB2ACP=DB2ACCTP; /*DDNAME for DB2ACCTP*/
%LET MACKEEP=
MACRO _SDB2ACB % /*BYPASS DB2ACCTB SORT*/
MACRO _SDB2ACP % /*BYPASS DB2ACCTP SORT*/
;
%INCLUDE SOURCLIB(BUILDPDB);
RUN;
This same tailoring, using a %LET Wdddddd=DDNAME;
statement to name the output DDname for the "Work"
copy of a dataset, and using %LET MACKEEP= as shown to
define MACRO _Sdddddd % (i.e., to a blank value) can be
used for any other large dataset that you want written
to a separate DDNAME, unsorted, as your SMF data is read.
Change 25.147 Almost cosmetic. The IMACxxxx/MACxxxx tokens that were
VMACQACS defined for VMACQACS were the old IMACQAPM/MACQAPM tokens
VMXGINIT from when AS/400 support was in VMACQAPM, and I decided
Aug 1, 2007 to change the VMAC to QACS but still use the QAPM token
so existing AS/400 tailoring wouldn't need to be changed.
However, this is inconsistent for new users, so this
change adds the include of IMACQACS and created MACQACS,
so the expected token names are found, but the old tokens
are still invoked, so existing tailoring still works.
Thanks to Philip Downes, Fortis Bank, BELGIUM.
Change 25.146 Using PDB=SMF could cause ERROR: NO DATASETS TO LOOKUP
ANALRMFR because SPLIT70 changes were not fully implemented.
Aug 1, 2007 A circumvention was to use TYPS7072 first to create the
PDB datasets, and then use PDB=PDB in the %ANALRMFR,
but this change corrects the error.
Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA.
Change 25.145 RMF III dataset ZRBLCP might have no observations for
VMACRMFV many LPARs, due to an MXG error in its "SKIP" logic that
Aug 1, 2007 prematurely ended the scan over all LPARs.
The statement SKIP=CPUCPLEN-32-1280; was replaced with
the statement SKIP=CPUCPLEN-LPARPROF-LPARPRLN*LPARPRNR;
Thanks to Erik Torp, IMT Nordic IBM, DENMARK.
Change 25.144 For ASCII execution, the FULLSTIMER option (MXG default)
UPCMEMSZ will print the memory used by each DATA/PROC step. One
Jul 31, 2007 way to determine how much virtual memory is available to
your MXG programs is to execute this new utility
%INCLUDE SOURCLIB(UPCMEMSZ);
which iterates the number of variables allocated in a
temporary array of 32K-length-character-variables so the
array size varies from 150MB up to 3GB. You look on the
log for the last successful step prior to the ERRORs:
FATAL: Insufficient memory to execute data step
program. Aborted during the COMPILATION phase.
NOTE: The SAS System stopped processing this step
because of insufficient memory.
In my Windows/XP system with SAS 9.1.3, that last step
allocated ARRAY TESTMEMSIZE (30000) $32000 _TEMPORARY_;
and used 938,107 kbytes, or 916 MegaBytes
Change 25.143 MXG sets each of the 135 SWAP rate variables in TYPE71 to
VMAC71 a missing value if that field was zero and the field was
VMXGINIT INPUT, but that design is inconsistent with MXG's use of
Jul 29, 2007 missing values. Normally, an MXG variable has a missing
value, a value different from a "zero", when:
- the event didn't happen, like a datetimestamp JSTRTIME
for a JCL error - the job never "started".
- a new variable is not INPUT, because that new product
is not yet installed at your site.
- an old variable that no longer exists (like PERFGRP)
is no longer INPUT because the record segment is no
longer written.
This design is not perfect; if the new variable is INPUT
because it was added to an already-existing-segment, or
if the old variable is still INPUT because it's segment
exists, they will have a zero value instead of a missing
value, but examination of missing values with PROC MEANS
is used in MXG validation and technical support.
Back when these swap rates were added to the TYPE71,
most were zero, but I wanted blanks when PROC PRINTed,
so by setting their zero values to a missing value, and
using an OPTIONS MISSING=' '; statement, SAS printed
blanks instead of a sea of zeros or periods.
Since TYPE71 always been this way, I'm reluctant to make
changes to my default, but new &MXGMISS macro variable is
now defined in VMXGINIT:
%LET MXGMISS = GT 0 ;
and it referenced in VMAC71 for each swaprate with logic
IF variable &MXGMISS THEN variable=variable*INTTIME;
ELSE variable=.'
so you can put this statement in your IMACKEEP or SYSIN
%LET MXGMISS = GE 0 ;
and any zero values will no longer be missing values.
Advanced SAS notes:
a. I first defined MACRO _GT0 GT 0 % in VMAC71 member,
so it could be redefined with the MACKEEP, but its
re-execution caused unrelated code with ' GT 0 ' to
be seen as ' GT 0 0 ', causing compiler errors.
b. I tested IF X &MXGMISS THEN ... syntax for the case
when the variable MXGMISS was not defined, which
would happen if your site (unwisely) has a tailored
VMXGINIT member. Although there are UNRESOLVED
MACRO VARIABLE messages and one NOTE: VARIABLE
MXGMISS IS UNINITIALIZED, the end result
I also discovered that the value of &MXGMISS macro
variable, when it is undefined, is the MXGMISS text,
rather than the blank value I had assumed/presumed!
Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.142 Change 18.211 identified most _xxxxID macro tokens that
IMACIPAC are "reversed" from the normal _IDxxxx syntax, but that
VMACIPAC change only updated member UTILBLDP so it would know of
Jul 29, 2007 those inconsistent _ID macro names. This change defines
new, "correct" _IDxxxx macro names for those products,
and modifies the SMF Record ID test syntax to
IF ID=_IDxxxx OR ID=_xxxxID THEN DO;
so that your old definition in your IMACKEEP tailoring
with MACRO _xxxxID nnn % does NOT need to be changed, but
more importantly, so that new users who use the expected
MACRO _IDxxxx nnn % will never find out about this MXG
inconsistency. These members were identified:
ARB, DLMN, DMON, HBUF, HURN, IPAC, M204, NSPY, PDSM,
RMDS, ROSC, RTE, SYNC, TSOM, VVDS, WYLA, WYLB, X37.
Thus far, this change has only been made to these xxxx:
IPAC
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 25.141 IBM APAR OA21799 corrects invalid values for SMF78HIX,
VMAC78 the offset to the new-with-HYPERPAV (SMF78HPS) segments
Jul 27, 2007 in RMF 78 Subtype 3 records. The value in SMF78HIX:
-sometimes exceeded the physical record length, causing
the MXG job to ABEND with this error message:
INPUT STATEMENT EXCEEDED RECORD LENGTH
-sometimes pointed to the wrong LCUID. MXG compares the
LCUID/R783ID2 from the old SMF78ASS segment with the
R783HLCU from the new SMF78HPS, and printed messages:
***ERROR.VMAC78 LCUID=002E DOES NOT MATCH R783HLCU=002F
HyperPAV support was shipped by IBM with APAR OA12865.
This change prevents the ABEND without the APAR installed
by validating SMF78HIX before the INPUT of the HYPERPAV
variables. Also, these new HyperPav variables:
R783HLCU R783HCU R783HNAI R783HTIO R783HAIU
R783HCAD R783HIOQ
are set missing when LCUID mismatch or beyond-record-HIX
is detected. Only 10 error messages will be printed.
-The actual records that contained invalid SMF78HIX values
happened to also be "SPLIT 78" records, i.e., multiple
records written for an interval when the data won't fit
in one 32K SMF record.
But split 78 records are not new; even before HyperPav,
records are split if there are more than 80 LCUIDs.
Fortunately, MXG has always created observations in the
TYPE78CF (Configuration, from the SMF78DCS segments, and
TYPE78CU (Control Unit, from the SMF78ASS and SMF78HPS
segments), since split records are fully self-contained
for each group of LCUIDs for those three segments that
create those two datasets.
But, UnFortunately, when 78 records are split, the 588
byte I/O Queue Global segment (pointed to SMF78QDS) is
repeated in each split record, causing duplicate,
triplicate, or more replicas of each interval's data to
be output in the TYPE78IO per-IOPIQID dataset. I think
the SMF78QDS data should have been written only in the
first split record, but now that I see what IBM does, the
change now only outputs TYPE78IO when SMF78RSQ is zero or
one; zero is the value in an un-split record, one is the
first record when records are split.
P.S. Because the split records have slightly different
values in SMFTIME, these duplicates cannot be
automatically recognized as dupes with the NODUP
option in PROC SORT after the fact; they must be
prevented up front.
-No one has noticed/reported the duplicate TYPE78IO data,
and only two sites encountered the ABEND in their daily
BUILDPDB due to the invalid SMF78HIX, but IBM immediately
accepted the problem and created the APAR to correct the
error. But RMF 78s are automatically processed by MXG's
BUILDPDB job, so the behind-the-scene installation of
HyperPAV might cause a fine-running-daily-accounting-JOB
to ABEND, so do not overlook this Change and/or APAR.
Thanks to Sam Knutson, Geico, USA.
Thanks to Mike Lewellen, Charles Schwab & Co., USA.
Change 25.140 Support for z/OS 1.9 (very minor additions, COMPATIBLE).
ADOC6 - Variables SMF22ETY and SMF22FNC values are formatted
EXTY8223 and decoded by existing MG022FN, MG022ET formats.
EXTY9214 - Variable R723TPDP='CPU TIME AT*PROMOTED*DISPATCH*PRTY'
IMAC82 is added to TYPE72GO dataset.
IMAC92 - Variables
VMAC1718 R742PSTM='MORE*PATH*STATUS*FLAGS'
VMAC22 R742PRCT='PATH*RETRY*COUNT'
VMAC30 R742PPND='CURR*PENDING*SIGNALS*OUTBOUND'
VMAC7072 R742PUSE='CURRENT*BLOCKS OF*BUFF SPACE*USED'
VMAC71 are added to the TYPE74PA dataset.
VMAC74 - Variables
VMAC79 R742MST1='EXTENDED*MEMBER*STATE*ONE'
VMAC82 R742MST2='EXTENDED*MEMBER*STATE*TWO'
VMAC92 R742MINT='STATUS*CHECKING*INTERVAL'
VMXGINIT R742MJOB='JOB THAT*JOINED*MEMBER'
Jul 26, 2007 are added to the TYPE74ME dataset.
- Variables
R744FPSN='NUMBER OF*SHARED*CF*PROCESSORS'
R744FPDN='NUMBER OF*DEDICATED*CF*PROCESSORS'
CFPTYP01='1ST CF*CPU*PROCESSOR*TYPE' thru
CFPTYP16='16TH CF*CPU*PROCESSOR*TYPE'
CFPWGT01='1ST CF*SHARED*PROCESSOR*WEIGHT' thru
CFPWGT16='16TH CF*SHARED*PROCESSOR*WEIGHT'
are added to the TYPE74CF dataset.
- Variable
R744SETM='STRUCTURE*EXECUTION*TIME'
are added to the TYPE74ST dataset.
- Variable
R791EXCW='EXCP*COUNT'
are added to the TYPE791 dataset.
- Variable
R792EXCW='EXCP*COUNT'
are added to the TYPE792 dataset.
- Variable
SMF82TKS='TKDS NAME'
are added to the TYPE8201 dataset.
- New dataset TYPE8223 dataset contains
SMF82TKF='TKDS*BITS'
SMF82TKH='TKDS*HANDLE*BEING*PROCESSED'
SMF82TKN='TKDS*NAME'
- New dataset TYPE9214 dataset contains
SMF92DDN='UNIQUE*DEVICE*NUMBER*FOR FILE'
SMF92DFG='FLAGS*80X=*RENAME'
SMF92DFN='NAME OF FILE*DELETED OR*RENAMED'
SMF92DFS='FILE*SYSTEM*NAME/
SMF92DFT='DATETIME OF*DELETE'
SMF92DIN='FILE*SERIAL*NUMBER'
SMF92DIP='FILE*SERIAL*NUMBER*OF PARENT'
SMF92DNL='LENGTH OF*FILE NAME*FOR DELETE'
SMF92DNR='LENGTH OF*FILE NAME*FOR RENAME'
SMF92DRN='NEW NAME*THAT WAS*RENAMED'
SMF92DTY='FILE TYPE*AS DEFINED IN*BPXYFTYP'
new variables.
-APAR OA17070 Additions to RMF 74-4 Coupling Facility CF
records provides the RMF support for accounting and the
measurement extensions of CF level 15. The COMPATIBLE
record change to RMF 74 records added these new data:
- Variables
R744FPSN='NUMBER OF*SHARED*CF*PROCESSORS'
R744FPDN='NUMBER OF*DEDICATED*CF*PROCESSORS'
CFPTYP01='1ST CF*CPU*PROCESSOR*TYPE'
thru
CFPTYP16='16TH CF*CPU*PROCESSOR*TYPE'
CFPWGT01='1ST CF*SHARED*PROCESSOR*WEIGHT'
thru
CFPWGT16='16TH CF*SHARED*PROCESSOR*WEIGHT'
are added to the TYPE74CF dataset.
- Variable
R744SETM='STRUCTURE*EXECUTION*TIME'
are added to the TYPE74ST dataset.
Change 25.139 Support for IMF Version 4.3 (INCOMPATIBLE). Part of that
VMACCIMS incompatibility was because MXG tested IMSVERS LT '13'
Jul 14, 2007 (because CIMS/Boole made major record format changes when
IMS 1.3 replaced IMS 1.2 years ago), but now, IMSVERS has
'1010' for IMS Version 10, causing MXG to try to read the
current records with ancient 1.2 code. However, many new
new fields were inserted by IMF 4.3, which relocated the
DBD segments incompatibly; this won't happen again, as
one of the new fields added is the OFFDBTRL, the offset
to the DBD segments. These new variables are created
in the CIMSTRAN dataset:
TRNARVTH TRNARVTJ TRNE1STD TRNEAPPL TRNEAPPU TRNEDB2
TRNEDB2U TRNEDLDB TRNEDLTM TRNEF2 TRNELDLI TRNEMQS
TRNEMQSU TRNEOESS TRNEOESU TRNEOPCL TRNESYNC TRNETFLG
TRNETIME TRNEWLMC TRNMODET TRNMSCTH TRNMSCTJ TRNMSCUT
TRNNUOWP TRNOTCLF TRNOTCLN TRNOTCON TRNOTCOR TRNOTIP
TRNOTMAM TRNOTMAP TRNOTPRT TRNOTSCF TRNOTSLF TRNOTSOC
TRNOTSTC TRNOTSTF TRNOTSYF TRNOTUSR TRNRSENM TRNSMQGN
TRNSTCKE TRNSTOPA TRNSTOPU TRNSTRTA TRNSTRTU TRNTCPU
TRNUOW TRNW1OTH TRNW2IOO TRNW2IOV TRNW2LCH TRNW2OTH
TRNW3LCH TRNW3OTH TRNW4DBR TRNW4IO TRNW4OTH TRNW5IOD
TRNW5IOO TRNW5IOV TRNW5LCH TRNW5LCK TRNW5OTH TRNWLMRE
TRNWLMRT TRNWLMSC TRNWLMZR TRNXCKPC TRNXCKPM TRNXCKPT
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 25.138 Support for APAR OA20314 which adds two variables
VMAC89 SMF89LPN='LPAR*NAME'
Jul 14, 2007 SMF89ZNA='LICENSE*ZNALC*IN*EFFECT?'
to both TYPE89 and TYPE892 datasets.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.137 INPUT STATEMENT EXCEEDED RECORD LENGTH error with SMF 80
VMAC80A record that contained new TOKDANAMs CPUTIMEMAX,
Jul 13, 2007 ASSIZEMAX and FILEPROCMAX segments, because MXG did not
protect for unknown tokens. This fix protects so the
record will be read and the new tokens will be skipped.
This change and text will be revised to support those
three new tokens.
Thanks to Gerald Nagao, University of California, USA.
Change 25.136 Two utility programs to count PDS Directory Blocks used
TYPELPDS and defined.
UTILLPDS The first example, in TYPELPDS, uses IBM LISTVTOC and
Jul 4, 2007 LISTPDS programs to create flatfiles that are then read
Aug 7, 2007 in a second SAS step (so this could be used by sites with
SAS only on ASCII), and it captures all PDS on a volume,
with no prior knowledge of their DSNAMES.
The second example, in UTILLPDS, is a SAS example that
gets the blocks for a single dataset.
Christa requested the facility. Chuck wrote TYPELPDS.
Geert contributed UTILLPDS. I wrote the change/comments.
Thanks to Chuck Hopf, Bank of America, USA.
Thanks to Christa Neven, KBC Bankverzekerinngsholding, BELGIUM.
Thanks to Geert De Batselier KBC Bankverzekerinngsholding, BELGIUM.
Change 25.135A The label for TYPE70PR variables LCPUCAP and LCPUCAPC now
TYPE7072 include "Hard CAP" because those flag variables are set
Jul 4, 2007 'Y' when Hard Capping was specified when the LPAR was
defined (LCPUCAP) or if the Hard Capping status of the
LPAR was changed during this interval (LCPUCAPC). Hard
Capping tells PR/SM to cap resources delivered to that
LPAR at that LPAR's Designated Share (which is derived
from the weight given to this LPAR versus the total of
the weights you gave all of the other LPARs in the CEC).
Once an LPAR specified as hard capped reaches its
designated share, that LPAR is then "hard capped" and
normally does not receive more than its share of total
CEC resources.
Soft capping of an LPAR is done by WLM in response to
license manager determining that the LPAR's rolling
4-hour average MSU has exceeded the MSU specified for the
LPAR. A Soft Capped LPAR will have PDB.TYPE70PR variable
LPARNSW='PERCENT*LPAR SOFT*CAPPED' nonzero in soft capped
intervals (and LPnNSW variables nonzero in PDB.ASUM70xx
ASUMCExx summary datasets).
To further confuse the issue, there can be resource group
capping of service classes based on Resource Group
specifications.
Even more confusing is that Discretionary Management
algorithms can cap a service class period that is a
candidate for Discretionary Mangement if it significantly
exceeds its performance goal (PI LT 0.71), and this
Discretionary Management cap will show up even though the
service class is not assigned a Resource Group cap.
Thanks to ???, ???, FRANCE, for asking why LCPUCAP was never 'Y'.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
the above answers.
Change 25.135 %ANALRMFR(PDB=PDB,REPORT=DEVC,DEVICEC=20) caused several
ANALRMFR errors (variables CPUTYPE CPUVERSN, variable CAIM NOT
Jul 4, 2007 FOUND). A list with dashed names CPUSER0-CPUSER9 was
enumerated and CAIM was removed (no such variable), and
UNINITIALIZED VARIABLES SMF70CPA and SMF70WLA were fixed
by their addition to ID statements where needed. But the
removal of CPUTYPE and CPUVERSN from the TEMP74 ID list
was the correct revision, because the don't exist when
a report for only RMF 74 records is requested.
Thanks to Esti Sas, Bank Lemui, ISRAEL.
====== Changes thru 25.134 were in MXG 25.06 dated Jul 4, 2007=========
Change 25.134 Support for IRRDBU00 record types 0560, 0561, 0562 and
EXRAC560 05C0 create four new datasets (all of which, unlike prior
EXRAC561 IRRDBU00 records, contain multiple segments per record).
EXRAC562 dddddd Dataset Description
IMACRACF RAC560 RACF0560 GEN RES CERTIFICATE DATA
VMACRACF RAC561 RACF0561 GEN RES CERTIFICATE REFERENCE
VMXGINIT RAC562 RACF0562 GEN RES KEY RING DATA
Jul 3, 2007 RAC5C0 RACF05C0 GEN RES CDTINFO DATA
Thanks to Aimee Steele, Euroclear, BELGIUM.
Change 25.133 Support for Williams Data Systems FERRET product user SMF
EXFERTCP creates three new datasets:
EXFERTEE
EXFERTRT DDDDDD MXG MXG
IMACFERT DATASET DATASET DATASET
TYPEFERT SUFFIX NAME LABEL
TYPSFERT
VMACFERT FERTCP FERRETCP FERRET CP SUBTYPE 1
VMXGINIT FERTEE FERRETEE FERRET EE SUBTYPE 2
Jun 30, 2007 FERTRT FERRETRT FERRET RTP SUBTYPE 3
Change 25.132 AS400 TYPECONF variables GDESCL,GDESCN,GDESED,GDESET, and
VMACQACS GDES91 are now kept, GDES2 is formatted TIME8, and GDES3
Jun 30, 2007 is now INPUT as $7 (Model+System-TYPE - e.g., 8709406).
Date/Time variables GDESED, GDESET are character text, so
they cannot be formatted, but new GDESEDD and GDESETT are
numeric variables with DATE9 and TIME8 formats.
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND.
Change 25.131 -Support for RACFEVNTs 52 (SET UID) and 79 (CRL PUBLISH)
EXTY8052 creates two new datasets from SMF 80 records:
EXTY8079 DDDDDD MXG MXG
IMAC80A DATASET DATASET DATASET
VMAC80A TY8052 TYPE8052 RACF EVT 52 SET UID
VMXGINIT TY8079 TYPE8079 RACF EVT 79 CRL PUBLISH
Jun 30, 2007 -Support for TOP SECRET records with RACFVRSN '90'x.
Jul 2, 2007 The '90'x records contain ONLY the "standard" relocate
sections (they have SMF80DTP=RACFTYPE values 1-255, there
are NRSET sections, and they are located at OFFSET), and
the header ends at SMF80VER/RACFVRSN, the "short" CA SMF
80 header, which is different than the "standard" IBM 80
record header; MXG has always detected IBM vs TOP SECRET
format based on RACFVRSN and found the short header.
-Support for TOP SECRET records with RACFVRSN '00'x is an
INCOMPATIBLE change that required new logic to detect the
new and different format. The '00'x records contain ONLY
the "extended" relocate sections (they have segment type
SMF80TP2=EXTLNTYP values of 256-65535, there are SMF80OC2
sections, and they are located at SMF80OC2), but the '00'
records now have the "full" IBM header (thru SMF80RSV).
And, of course, CA changed the SMF80OC2 offset value in
the '00'x, but not in the '90'x, to match the way IBM
has always (incorrectly!) set OFFSET and SMF80OC2:
In all other IBM SMF records, offsets are from the RDW
and the INPUT is @OFFSET-3, but the IBM SMF 80s have
always required @OFFSET+1. The original and '90'x Top
Secret records require -3, the new ones require +1.
-The MXG code that formerly created TYPE80A and TYPE80CM
datasets has been changed, and there now should never be
any observations written to those datasets. Previously,
TYPE80A was OUTPUT if NRSET=0 (e.g., RACFEVNT=79 that
has only extended relocate segments), and TYPE80CM was
OUTPUT when an unknown SMF80DTP segment type was found.
TYPE80A now will contain obs only if the SMF 80 records
has no segments: OUTPUT only if NRSET=0 AND SMF80OC2=0.
TYPE80CM will contain obs only if SMF 80 records contain
relocate sections (standard or extended) that MXG does
not (yet) decode, but if you send your SMF records to
support@mxg.com, those segments will be decoded and those
observations will go away.
-Top Secret Documentation: MXG decodes the Top-Secret-Only
SMF80DTP segment values of 103, 104, 105, 109, and 114,
and outputs one observation in the TYPE80TS for each
segment (i.e., multiple observations from one SMF 80
record). MXG also outputs one observation per record to
the appropriate TYPE80xx dataset for that RACFEVNT=xx,
with all the "IBM" variables from the relocatable DTP/DT2
segments.
-New Top Secret DTP=115 and DTP=116 segments will be
decoded and output to TYPE80TS when documentation is
received; this text will be updated when completed.
Thanks to Greg Burt, Fifth Third Bank, USA.
Change 25.130 Support for Clarion Disk Array flat files creates new
EXCLARDI datasets:
EXCLARLU DDDDDD MXG MXG
EXCLARPO DATASET DATASET DATASET
EXCLARRA SUFFIX NAME LABEL
EXCLARSA
EXCLARSN CLARDI CLARDISK CLARION ARRAY DISK DATA
EXCLARSP CLARLU CLARLUN CLARION ARRAY LUN DATA
IMACCLAR CLARPO CLARPORT CLARION ARRAY PORT DATA
TYPECLAR CLARRA CLARRAID CLARION ARRAY RAID DATA
TYPSCLAR CLARSA CLARSAN CLARION ARRAY SAN DATA
VMACCLAR CLARSN CLARSNAP CLARION ARRAY SNAP DATA
VMXGINIT CLARSP CLARSP CLARION ARRAY SP DATA
Jun 29, 2007 Jul 5: Variable OBJECT removed from BY lists as it is
Jul 5, 2007 subordinate to their OWNERNAM, and it's parsed pieces
are already available in the other BY variables.
Thanks to Jim Quigley, ConEd, USA.
Change 25.129 Variable QW0224PN and QW0224CI are now created in the
VMAC102 T102S224 DB2 Trace IFCID=224 dataset.
Jun 29, 2007
Thanks to Christa Neven, KBC Bankverzekerinngsholding, BELGIUM.
Change 25.128 Variable UBRECRD is now formatted with $MGDCORF, and is
VMACDCOL INPUT as $CHAR1 instead of $EBCDIC1 so it is valid on the
Jun 27, 2007 ASCII platform as well as on EBDIC, and it is set to
LENGTH $1 (without the LENGTH set to $1, the length of
the format item, $MGDCORF, is used by SAS for the length
of the variable, wasting space).
Thanks to Trevor Ede, EDS New Zealand Limited, NEW ZEALAND.
Change 25.127 Support for Oracle Version 10 has been in place since MXG
VMACORAC Version 24.06, as there were no changes in the physical
Jun 27, 2007 contents of their user SMF record. However, V10 data for
Oct 16, 2008 the Kernel fields (MXG variables LOGREADS PHYREADS
LOGWRTS DMLCOMIT DMLROLLS DEADLOCK) is trashed with very
large values in the initial test records; a problem has
been opened with Oracle Technical Support and this note
will be updated when a fix is available from Oracle.
Oct 2008 update:
The incorrect I/O counts appear to have been fixed in
Oracle 10.2.0.3. The SMF fix 6725982 also requires fix
6138068 and 6646861.
Thanks to Sudie Wulfert-Shcickendanz, Anheuser-Busch, USA.
Change 25.126 Circumvention to skip new TMC 'FF20'x Volume Definition
VMACTMS5 record, awaiting doc and data to decode.
Aug 7, 2007
Change 25.125 VGETOBS added conditional use a DATA step for testing,
VGETOBS but that revision was removed and would not be executed.
Aug 7, 2007
Change 25.124 Preliminary changes to support testing of MXG under WPS.
AUTOEXEW -Member CONFIGW2 defines the SAS options for WPS execution
CONFIGW2 on z/OS platforms. Some SAS options do not yet exist in
MXGWPSV2 WPS, and some are no longer needed or are not changeable.
VMXGINIT It must be the last dataset in the //CONFIG DD in your
Jun 25, 2007 MXGWPSV2 JCL procedure.
Aug 8, 2007 -Member AUTOEXEW defines the SAS options for WPS execution
Sep 25, 2007 on ASCII platforms.
VMACSMF -VMXGINIT set new GLOBALed macro variable &WPSVER=2 when
execution under WPS V2 is detected, and sets the existing
macro variable &SASVER=8, so that MXG will generate code
for the SAS V8 environment that WPS V2 replicates.
Sep 25: test for SASVER EQ 2.00 in VMXGINIT was changed
to LT 6 when WPS changed version to 2.01.
-VMACSMF updated to protect FILENAME= option not in WPS.
Change 25.123 An undetected DIVIDE BY ZERO in VMXGRMFI occurred in the
VMXGRMFI PGPERBLK=PGPERBLK/BLKSAUIN calculation, but I do not know
Jun 25, 2007 why SAS did not detect and report the error (which is
inside the OUTCODE= of a PROC MEANS inside VMXGSUM). The
division is now protected.
Change 25.122 If BUILDPDB=NO, USERADD didn't function correctly for the
UTILBLDP TMNT, 5, 26J2, or 30 "products".
Jun 25, 2007
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.121 PDB.ASUMUOW dataset is enhanced to keep the response time
VMXGUOW of each of the CICS segments in the Unit of Work.
Jun 22, 2007
Change 25.120 Utility for counting CICS record, bytes, transactions for
UCICSCNT each region and subtype now separates CICS Resource field
Jun 22, 2007 segments from CICS Transaction segments in counts, and
report titles and labels were clarified.
Change 25.119 SMF 119 with (new in z/OS 1.8) IPV6 ICMP segments caused
VMAC119 INVALID DATA error messages due to blanks where &PIB.4.
Jun 20, 2007 should have been for the INFORMAT of several variables
in the TYP11905 dataset (after @OFF11907).
Thanks to Marty Rhodes, Hertz Corporation, USA.
Change 25.118 DEVMODEL='3380K' caused INVALID ARGUMENT error as noted
ASUMCACH in Change 23.073; logic revised to set MODEL=3380 when
Jun 20, 2007 DEVMODEL=:'3380' to circumvent.
Thanks to Tom Heller, Cincom Systems, Inc, USA.
Change 25.117 INVALID ARGUMENT TO FUNCTION INPUT reading SYNCSORT SMF
VMACSYNC records were due to incorrect HEX4 and HEX3 informats
Jun 19, 2007 that should have been HEX8 and HEX6, and (on ASCII only)
SYNSRTOU was input as $CHAR instead of $EBCDIC. The
variables that were wrong were Device Addresses
SIDEVNR and SODEVNR.
Thanks to Patrick Holloman, Zions Management Services Co., USA.
Change 25.116 MXG 25.05 GMTOFF30 was still wrong because Change 25.089
VMAC30 for TYPE30U6 GMTOFF30/INTETIME/INTBTIME was still wrong
VMAC30 in some cases; those variables are now created in the
Jun 19, 2007 _STY30U6 logic based on SMFTIME and the EXECTM; variable
SYNCTIME sometimes exists, and if it does, it is reset
from GMT; otherwise, it is set to INTETIME. With 25.05
TYPE30_V/SMFINTRV has negative EXECTM and ITRVLTM values.
With MXG 25.05,
Thanks to Rudolf Sauer, T-Systems Enterprise Services, GERMANY.
Change 25.115 Incorrect values for memory variables in XMUCDSYS were
VMACXAM the result of my inability to recognize PL/1 source, so
Jun 15, 2007 I overlooked several fields in this Linux under VM data.
Thanks to Robert Obee, IMS Health, USA.
Change 25.114 -The XCOM support is revised to conform to Change 18.338
VMACNDM by defining the MACRO _VTYXCOM for this product. Over
VMACSOLV time, all members will be revised to provide this option,
VMACXCOM but I tend to get motivated only when someone asks.
Jun 14, 2007 -Jun 27: SOLV enhanced to define _VTYSOLV, _VTYSOL1 macros
Jun 27, 2007 -Jun 27: NDM now defines _VNDMxx macro for all datasets.
Thanks to Trevor Ede, EDS, New Zealand.
Change 25.113 The HSM support is enhanced to create an "HSM COMPLEX"
ASUMHSM variable, HSMPLEX, for the HSM Summarization logic to
Jun 14, 2007 support sites with multiple DFHSM-managed storage
environment. HSMPLEX is blank by default, but the new
MACRO _ESUHSM has a commented exmaple on how you might
create values in HSMPLEX for your DFHSM data.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.112 The CA IDMS Performance Monitor support is enhanced with
IHDRIDMS the insertion of an INCLUDE for IHDRIDMS member after the
VMACIDMS IDMS header variables have been input. New &MACIDMSH
VMXGINIT macro variable is defined so either the IHDRIDMS member
Jun 14, 2007 or it can be used to access the header variables.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.111 A misplaced end comment after PUT 'DEBUG TWO' statement
VMAC80A after Change 25.024 caused variable TYPSTRNG to be wrong.
Jun 13, 2007 TYPSTRNG is an MXG-created variable that identifies which
RACFTYPE subtypes were found for this RACF event.
Thanks to John Hammonds, Texas Comptroller of Public Accounts, USA.
Change 25.110 -When there are more than some number of disks, NMON will
VMACNMON create additional objects DISKBUSY1/DISKREADn etc; they
Jun 12, 2007 are now supported.
-Inconsistent sort order BY statement were revised.
-JFSFILE name was increased in size to $128 to prevent
false duplicates
Change 25.109 z/OS 1.8 changed the meaning of UIC values in SMF71Uxx
VMAC71 variables to now represent the time for one steal cycle
Jun 14, 2007 through the whole storage area, with a range of values
from 0 to 65535 (18 hours). As before, low UIC implies
higher storage contention. The new UIC metrics for
Current UIC are calculated every second, while Min and
Max are the lowest/highest UIC during the last walk thru
the storage area. IBM has kept the old form of UIC
(values 0-2054) in SMF71LIC/HIC/ACA, MXG variables
HIUICMN/MX/AV, but this change now stores the new
SMF71Uxx values in the three old UIC MXG variables
HIUICMN/HIUICMX/HIUICAV variables, as their value has no
meaning with z/OS 1.8.
See Change 26.069, which corrected HIUICMN and HIUICMX.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.108 Unused Change.
====== Changes thru 25.107 were in MXG 25.05 dated Jun 7, 2007=========
Change 25.107 Support for CA Brightstor Tape Encryption user SMF record
EXBTENCR creates two new datasets:
EXBTEN32 DDDDDD MXG MXG
IMACBTE DATASET DATASET DATASET REC
TYPEBTE SUFFIX NAME LABEL St
TYPSBTE BTENCR BTENCRYP BTENCR: BRIGHTSTOR TAPE ENCRYPTION all
VMACBTE BTEN32 BETNCR32 BTEN32: BRIGHTSTOR SUBTYPE 32
VMXGINIT but this change was not included in MXG 25.05; 25.06+ is
Jun 7, 2007 needed for these data. See also Change 25.143.
Jun 14, 2007
Thanks to Ray Dunn, CIGNA, USA.
Change 25.106 MXG 25.04 only. Zero obs in TMSTMS due to a debug test
TYPETMS5 IF DSN='DB2SPEC.DBBKUP.ONSITE.CSTDB21R.CSTTSP10' THEN
Jun 5, 2007 statement that should have been deleted.
Thanks to Jan Bigalke, AGIS Allianz Dresdner Infosys, GERMANY.
Change 25.105 -Variable PARTNCPU contains the number of CP Engines, but
VMAC7072 the "in what" is different in different MXG datasets:
VMXG70PR In ASUMCEC and ASUMCELP the label now reads:
Jun 5, 2007 PARTNCPU='NUMBER OF*CP ENGINES*IN CEC'
in TYPE70PR, ASUM70PR, and ASUM70LP, the label now reads:
PARTNCPU='NUMBER OF*CP ENGINES*IN PARTITION'
For example, you could see PDB.ASUMCEC with
NRPRCS=5 NRPHYCPS=4 NRICFCPU=2 PARTNCPU=2
and PARTNCPU is thus the correct number of CP engines for
any "CPU Busy" calculations.
-Variable MXGCIN was not always set correctly for 'ICF's;
fortunately, there was no impact on other variables.
-If you should accidentally/incorrectly run ASUM70PR with
incorrect CECINTRV=QTRHOUR reading DURATM=30 Minute data,
then, as should be expected, the ASUMCEC output dataset
is invalid, and had many PCTCPU's much greater than 100%.
Change 25.104 Full support for NMON, Nigel's Monitor for AIX/unix. All
EXNMONAA OBJECTs are now supported; an NMONxxxx dataset is created
EXNMONCD from each OBJECT that has multiple instances per interval
EXNMONDS (e.g. NMONDISK has an observation for each DISKNAME), and
EXNMONIN
EXNMONIO NMONINTV dataset has all metrics from all OBJECTs that
EXNMONJF have only one instance per interval.
EXNMONNT
EXNMONFS These datasets are now created from NMON records:
EXNMONTO DDDDDD MXG MXG
EXNMONUA DATASET DATASET DATASET
EXNMONVG SUFFIX NAME LABEL Instance
EXNMONWL
IMACNMON NMONAA NMONAAA NIGELS MONITOR AAA CONFIG none
VMACNMON NMONCD NMONCPUD NMON CPU DETAIL CPUNR
VMXGINIT NMONDS NMONDISK NMON DISK DISKNAME
Jun 5, 2007 NMONIN NMONINTV NIGELS MONITOR INTERVAL none
NMONIO NMONIOAD NMON IOADAPTER IOADAPTR
NMONJF NMONJFSF NMON JFSFILE JFSFIL
NMONNT NMONNETW NMON NETWORK NETNAME
NMONFS NMONNFS NMON NFS CLIENT AND SERVER NFSTYPE
NMONTO NMONTOP NMON TOP PROCESS PID
NMONUA NMONUARG NMON UARG PROCESS PID PPID
NMONVG NMONVG NMON VOLUME GROUP VOLGROUP
NMONWL NMONWLM NMON WLM WLMCLASS
This table maps the objects to each MXG dataset:
DDDDDD MXG MXG The OBJECTs that create
DATASET DATASET DATASET are listed.
SUFFIX NAME LABEL
NMONAA NMONAAA NIGELS MONITOR AAA CONFIGURATION
OBJECTS: AAA
NMONCD NMONCPUD NMON CPU DETAIL
OBJECTS: CPUnn
NMONDS NMONDISK NMON DISK
OBJECTS: DISKBUSY DISKREAD DISKWRITE
OBJECTS: DISKXFER DISKBSIZE
NMONIO NMONIOAD NMON IOADAPTER
OBJECTS: IOADAPT
NMONJF NMONJFSF NMON JFSFILE
OBJECTS: JFSFILE JFSINODE
NMONNT NMONNETW NMON NETWORK
OBJECTS: NET NETPACKET NETERROR
NMONFS NMONNFSS NMON NFS CLIENT AND SERVER
OBJECTS: NFSCLIV2 NFSCLIV3
OBJECTS: NFSSVRV2 NFSSVRV3
NMONTO NMONTOP NMON TOP PROCESS
OBJECTS: TOP
NMONUA NMONUARG NMON UARG PROCESS
OBJECTS: UARG
NMONVG NMONVG NMON VOLUME GROUP
OBJECTS: VGBUSY VGREAD VGWRITE
OBJECTS: VGXFER VGSIZE
NMONWL NMONWLM NMON WLM
OBJECTS: WLMCPU WLMBIO WLMMEM
NMONIN NMONINTV NIGELS MONITOR INTERVAL
OBJECTS: CPU_ALL
VARS: PCPUUSER PCPUSYS PCPUWAIT
VARS: PCPUIDLE PCPUBUSY NRCPUS
OBJECTS: MEM
VARS: REALFREE VIRTFREE REMBFREE
VARS: VIMBFREE REMBTOTL VIMBTOTL
OBJECTS: MEMNEW
VARS: MNPROCPC MNFSCAPC MNSYSTPC
VARS: MNFREEPC MNPINNPC MNUSERPC
OBJECTS: MEMUSE
VARS: MUNUMPPC MUMINPPC MUMAXPPC
VARS: MUMINFPC MUMAXFPC
OBJECTS: PAGE
VARS: PGFAULTS PGIN PGOUT PGSIN
VARS: PGSOUT RECLAIMS SCANS CYCLES
OBJECTS: PAGING
VARS: PGMBFREE
OBJECTS: LARGEPAGE
VARS: FREEPAGE USEDPAGE PAGES
VARS: HIGHPAGE SIZEMB
OBJECTS: PROC
VARS: RUNNABLE SWAPIN PSWITCH
VARS: READ WRITE FORK EXEC SEM MSG
VARS: SYSCALL
OBJECTS: PROCAIO
VARS: AIOPROCS AIORUNNG AIOCPU
OBJECTS: FILE
VARS: IGET NAMEI DIRBLK READCH
VARS: WRITECH
VARS: TTYRAWCH TTYCANCH TTYOUTCH
OBJECTS: LPAR
VARS: PHYSICPU VIRTCPUS LOGLCPUS
VARS: POOLCPUS ENTITLED WEIGHT
VARS: POOLIDLE USEDALL USEDPOOL
VARS: SHARECPU
The JFSFILE and JFSINODE objects have errors in one file
out of many; after many intervals, the number of data
fields in those object records is smaller than the number
of file names in the "dictionary" record. Logic in MXG
detects and reports these bad records on the log, and
deletes the defective records. If a fix from Nigel is
forthcoming, this note will be updated.
Thanks to Steve Olmstead, Northwestern Mutual Trust, USA.
Thanks to Henry Steinhauer, Northwestern Mutual Trust, USA.
Change 25.103 Support for IBM OMEGAMON TRF ITRF V550 and V560.
EXITRMST -Many new variables added to datasets ITRFMSG & ITRFMSGO.
IMACITRF -Variables LOCLTIME and PSTNR added to all ITRF datasets.
VMACITRF -New ITRFMSGT dataset is created from subtype 12 with the
VMXGINIT text of the DFS554A message.
Jun 4, 2007 -There is a known error now fixed in APAR CCnnnnn; a few
'10'x records (39 out of 10000) are misaligned, causing
very high CPU time (1E13) and missing value in LOCLTIME.
Use PROC MEANS N MIN MAX SUM DATA=ITRFMSG; to examine
the maximum value of ACCPU and SRBTIME and LOCLTIME to
see if it has any missing values.
Thanks to Guenter Rucks, FinanzIT GmbH, GERMANY.
Thanks to John Maher, IBM Tivoli, USA.
Thanks to Bert Winberg, IBM Nordic Processor, DENMARK.
Change 25.102 The erase of the old month directory syntax was wrong;
VMXGALOC statement %let killmo="&basedir.w%trim(&killmnth)\*.*";
Jun 2, 2007 is now %let killmo="&basedir.m%trim(&killmnth)\*.*";
Thanks to Patrick Holloman, Zions Management Service Company, USA.
Change 25.101 MXG 25.04 only. Back in Change 25.085, I added options
MEMLEAVE=25M NOSORTBLKMODE in CONFIGV9 because they did
CONFIGV9 correct an error, but those values were suggested for the
Jun 1, 2007 diagnostics; this change restores SORTBLOCKMODE because
it is used by DFSORT for significant improvement in sort
performance, and it is the SAS default, so it no longer
set in MXG's CONFIGV9.
MEMLEAVE protects a virtual storage area used only by SAS
(especially needed when SAS calls an external product,
like a host sort program), but MEMLEAVE is taken from the
REGION size of the JOB; if you had an old job with the
prior-recommended-by-MXG of REGION=64M, with MEMLEAVE=25M
you only had 39M for the MXG job. Additionally, the SAS
recommended value is 10% of the REGION size, and almost
all of MXG will execute in a REGION=100M, changing the
value to MEMLEAVE=10M is more correct.
But what about REGION=0M, didn't that solve the need to
periodically increase any static REGION=nnnM values in
your JCL? Yes, it did, prior to the new Threaded Kernel
Memory architecture in SAS V9, which operates independent
of the prior "SAS Proper" WM Memory architecture, but the
existence of two independent memory managers in one ASID
has uncovered memory exposures if and only if REGION=0M
is specified. While a future version of SAS may resolve,
the safest recommendation now is to set REGION=100M on
your job card, with this revised CONFIGV9 member in use.
(MXG also sets NOTHREADS because there are exposures to
the use of THREADS on z/OS at this time that need to be
understood, so I leave it to you to decide to THREADS,
but even with NOTHREADS, the REGION=0M exposure exists,
because SAS V9 itself is threaded.)
Thanks to Jim Hayes, Huntington, USA.
Change 25.100 Documentation. References to JCLINSTL were changed to
INSTALL JCLINST9 for SAS V9.1.3 or JCLINST8 for SAS V8.2; the
JCLINSTx JCLINSTL member no longer exists because it didn't work
Jun 1, 2007 for both SAS versions, but I failed to update the doc.
Thanks to Allan Hardman, Co-Operative Bank, ENGLAND.
Change 25.099 Sub-subtype '4000'x (DLI) caused INPUT STATEMENT EXCEEDED
VMAC112 ERROR and/or incorrect values in T112DLI and T112DLIT
VMACOMCI datasets; an 8-byte field was overlooked.
May 31, 2007 -Jun 28: Detection of unknown TTYPE added for safety.
Jun 28, 2007 -The SMF 112 record replaced the OMEGAMON for CICS user
Jun 30, 2007 SMF record, but only the SUBTYPE=203 "ONDV" record is
processed by TYPE112, because that is the useful data,
because only the subtype 203 can be compressed, and
because the existing TYPEOMCI/TYPSOMCI code will read the
other two subtypes:
200 - SYST
201 - INTR
in a standalone job from SMF with this example
// EXEC MXGSASV9
//SMF
//PDB
//SYSIN DD *
%LET MACKEEP= MACRO _IDOMCI 112 %
%INCLUDE SOURCLIB(TYPSOMCI);
so you can investigate if the other two subtypes contain
data of interest. You could easily add processing of the
SMF 112 and OMCI records to your BUILDPDB, using:
%LET MACFILE=
%QUOTE( IF ID=112 THEN DO;
INPUT @OFFSMF+19 SUBTYPE &PIB.2. @;
IF SUBTYPE IN (200,201) THEN ID=299;
END;
);
%LET MACKEEP= MACRO _IDOMCI 299 % ;
%UTILBLDP(BUILDPDB=YES,USERADD=112 OMCI);
%INCLUDE INSTREAM;
Because the TYPE112 code now processes the subtype 203,
VMACOMCI now only reads subtype 200 and 201 records, it
was updated to accept V560 version, and the four bytes
inserted for compression statistics are skipped.
But see Change 26.257, which revised OMCI and 112 code.
Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.
Thanks to Ray Dunn, CIGNA, USA.
Change 25.098 %UTILBLDP is enhanced with new option BUILDPDB=JES3 to
UTILBLDP generate an %INCLUDE for BUILDPD3 instead of BUILDPDB to
May 31, 2007 create a PDB library with JES3 instead of JES2 records.
Thanks to Julian Smailes, Experian, ENGLAND.
Change 25.097 MXG-created DB2-variable THREADTY was blank if there was
VMACDB2 no QLAC segment (i.e., non-DDF), because the MXG code to
May 28, 2007 create THREADTY was located inside the QLAC processing,
Jun 6, 2007 because the logic needs to test QLACLOCN. The code block
was relocated to after the QLAC processing, and THREADTY
should, now, always be populated.
-THREADTY added to DB2ACCTP dataset default KEEP list.
Thanks to Eileen F. Van Etten, Bank of America, USA.
Change 25.096 Using an IMAC7072 tailoring that had an old _STY70 caused
IMAC7072 ERROR: VARIABLE LPARNAME NOT FOUND. from within a VMXGSUM
May 28, 2007 that was "INVOKED BY VMXGRMFI TYPE70 - R70HOUR", although
the real error was back when PDB.TYPE70 was created, as
it had zero observations because the new "SPLIT70" _STY70
must be executed, now, to create observations in TYPE70.
Removing the IMAC7072 corrected the error; it has been
the MXG recommendation to remove all of the old IMACnnnn
"product tailoring" members, and use only IMACKEEP to
redefine macros you know you want to change.
Long ago, the IMACxxxx members actually defined the
_L, _K, _S, _B etc macros, but those definitions moved
into the VMACxxxx member precisely because of these
exposures when I have to make an incompatible change
in MXG architecture.
Thanks to Jim Hayes, Huntington, USA.
Change 25.095 Reading VSAM SMF with TYPE42 caused false MXG messages
VMAC42 **ERROR SHORT SMF 42 SUBTYPE 6 ACCESS METHOD SECTION
May 28, 2007 (OFFDSAM=1 confirms it's a false message) and
**ERROR INVALID TYPE42 SUBTYPE 5 RECORD
(COL=229,S42VTVDO=228 confirms false message).
and these records were incorrectly deleted, but only when
the (undumped) VSAM SMF file is read; when the (normal,
dumped) BSAM SMF file is read, there are no errors.
Logic to handle OFFSMF for subtype 5 and OFFDSAM revised.
Thanks to Jim Poletti, Edward Jones, USA.
Change 25.094 Harmless divide by zero when EXCPDASD was zero; the obs
ANALBLSR is now deleted since it can't be a BLSR candidate.
May 28, 2007
Thanks to Rodger Foreman, TransUnion, USA.
Change 25.093 With BUILDPDB=YES,SUPPRESS=DB2, an %INCLUDE for ASUMCICX
UTILBLDP was generated, but the prerequisite %INCLUDE for ASUMUOW
May 22, 2007 was not generated, causing ASUMCICX to fail in a SORT.
Thanks to Robert Sample, Atlanta Journal Constitution, USA.
Change 25.092 Doc only. The example in the comments to run ASUM70PR
ASUM70PR against SMF data was incorrect; the corrected example is:
VMXG70PR %INCLUDE SOURCLIB(TYPS7072,ASUM70PR);
May 21, 2007 Error Dataset PDB.TYPE70PR NOT FOUND resulted if you used
the example in the comments.
Thanks to Art Cuneo, Health Care Services, USA.
Change 25.091 After MXG 25.04 QA completed, but before it was packaged,
TESSOTHR a untested TESSOTHR member was copied into SOURCLIB; the
May 15, 2007 PROC COPY that causes the ERROR in JCLTEST9 is removed.
Thanks to Randy Parker, Trustmark National Bank, USA.
Change 25.090 -Support for PK37354 SMF 100 Subtype 4 in DB2 V1.9, which
EXDB2ST4 will contain the old IFCID=225 (ID=102 Subtype 225) data.
IMACDB2 This makes my head hurt, because I can't safely use the
VMACDB2 old T102S225 dataset name: combining 100 and 102 records
VMAC102 in the same DATA step would cause SAS to fail due to the
VMXGINIT duplicate output dataset names. So the old IFCID=225
May 15, 2007 data will be output in new DB2STAT4 dataset.
-NEW QW0225BB='STORAGE POOL*MANAGER*BLOCKS BELOW*THE LINE'
was also added by this APAR, for both DB2 V1.8 and 1.9,
and it is INPUT and kept in T102S225 and DB2STAT4.
Apr 8, 2008: QW0225BB was only added to T102S225 by this
change. Change 26.057 added it to DB2STAT4.
Change 25.089 GMTOFF30 must be calculated because IBM does not put it
VMAC30 in SMF 30 records; it can only be calculated from the
May 14, 2007 subtype 2 or 3 interval records, which contain interval
May 31, 2007 start on both local and GMT clocks (SMF30IST is local and
Jun 1, 2007 SMF3ISS is GMT), and then GMTOFF30 was used to create the
Jun 18, 2007 local zone INTBTIME & INTETIME interval start/end times.
It was also RETAINed to convert INTETIME in the subtype 6
record, which has no local counterpart, and from which
INTBTIME will be created when TYPE30_6 is deaccumulated.
These problems existed prior to this change:
- Subtype 6 logic caused GMTOFF30 to be zero, causing
INTBTIME/INTETIME in TYPE30_6 to be wrong. Worse,
if the next subtype 2/3 did not have a CPU segment,
(MULTIDD='Y' observations have no CPU segment and
thus SMF30IST is a missing value), that RETAINed zero
GMTOFF30 value was used, causing INTBTIME/INTETIME
in TYPE30_V and PDB.SMFINTRV datasets to be wrong.
- Subtype 2 and 3 records for OMVS tasks do NOT have the
interval start time in SMF30IST (they appear to have
the original substep initiate time, not the current
interval's start time; this undocumented feature
caused very large GMTOFF30 values (like -29 hours).
This change revised the subtype=6 logic so GMTOFF30=0 is
not created, and the OMVS records (SUBSTEP GT 0) are not
used to calculate GMTOFF30; instead, they use the RETAIN
value of GMTOFF30 to recalculate INTBTIME and INTETIME.
There can still be errors in the value of GMTOFF30, or
INTBTIME or INTETIME because of the need to RETAIN the
GMT offset from prior records, but many records do not
have the needed data. These design errors exist in 30s:
- SMF30IST is wrong in OMVS (SUBSTEP GT 0) records.
- SMF30IST is not populated in subtype 6 records.
- SMF30IST is not populated in records with no CPU
segment, notably MULTIDD='Y' records with only EXCPs,
or records with more MULC segments than fit in one
physical SMF 30 record.
The only solution for auditable SMF 30 data is for IBM to
add the GMT Offset value in EVERY type 30 record.
-May 31, 2007: Variable INTRVLTM was missing after May 14
change, only for SUBSTEP GT 0 (USS - OMVS) tasks, because
it wasn't calculated in that revised code block.
-Jun 1, 2007: Variables SMF30IET/INTETIME/SYNCTIME with a
fixed datetime value of '17SEP2042:23:53:47.37' in all
subtype 6 records was found at one site; the hex value of
the field showed it was actually a negative binary value
of -22 (the number of leap seconds of offset!) when it
was INPUT as &IB.8.6 and then divided by 4096, which is
the TODSTAMP algorithm for negative values.
IBM's SMF manual only documents SMF30IST/SMF30IET for the
subtype 2 and 3 records; in subtype 6, SMF30IST is always
missing, but previously SMF30IET was the valid end time.
Now, additional logic detects the duration rather than
datetime in SMF30IET, and sets SMF30IET from SMFTIME in
those cases in TYPE30_6 observations.
-Jun 18, 2007: IF TST30IET GT 0 THEN test was corrected
of IF TST30IET LT -30 THEN because valid TODSTAMP values
have first bit on, which causes TST30IET to be always be
negative, but the -30 test detects the invalid values of
IET that contained leap seconds and not a valid time.
Thanks to Douglas C. Walter, Citicorp, USA.
Thanks to Rudolf Sauer, T-Systems Enterprise Services, GERMANY.
Change 25.088 The &VMXGVERS as the last line should have been %VMXGVERS
VGETDDS
May 10, 2007
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 25.087 BROKEN CONTROL RECORD error caused by DMN=10 RC=2 record
VMACVMXA for MDGPROD=:'5739A03RM0000000' logic, now corrected.
May 10, 2007
Thanks to Tom Draeger, Aurora, USA.
====== Changes thru 25.086 were in MXG 25.04 dated May 7, 2007=========
Change 25.086 New Analysis of CEC-level z/OS Capture Ratio combines PDB
ASUMCAPT ASUMCEC and RMFINTRV datasets, summing workload CPU & TCB
VMXGCAPT time for all Service Classes in all z/OS LPARS in the CEC
May 6, 2007 to create new dataset PDB.ASUMCAPT with total CPUACTTM
from PDB.ASUMCEC and total CPU72TM from PDB.RMFINTRV for
new variable CECAPTRT='CEC*CAPTURE*RATIO' to be created
CECAPTRT=100*CPU72TM/CPUACTTM;
You can simply add %INCLUDE SOURCLIB(ASUMCAPT); after the
your %INCLUDE SOURCLIB(ASUM70PR); in your BUILDPDB job.
The default summarization is by HOUR.
This hour's data shows how 17532 CPU Seconds of CEC Busy
time ends up as only 16389 CPU seconds captured in RMF 72
Service Class records, for a CECAPTRT=93.48 for the CEC:
__________________________________________________________
| ASUMCEC | RMFINTRV | RMFINTRV | RMFINTRV | RMFINTRV |
| CPUACTTM | CPUMVSTM | RMFACTTM | CPUEFFTM | CPU72TM |
| 17532 | 17500 | 17448 | 17389 | 16389 |
| | | | | |
| | | | | __16389__ |
| | | | / |
| | | |__17389__/| |
| | | /| | |
| | |__17448__/ | | |
| | /| | | |
| |__17500__/ | | | UNCAPTURED|
| /| ??Phys?? | PHYSICAL | CPUOVHTM | |
|__17532__/ |__ 32__ | __ 84__ | __ 143__|__ 1143__ |
Of those 16389 CPUTM seconds, only 14086 was CPUTCBTM,
showing why you MUST use total CPUTM and not just TCB.
Change 25.085 Strange V9.1.3 z/OS memory failures in the SAS Internal
CONFIGV9 SORT (no error message on SAS log nor in JOBLOG, even no
May 4, 2007 end of step IEF374I message, but SYSLOG shows the job was
placed in HOLD by JES after a S0F9 ABEND; system couldn't
acquire storage for an SVRB. The error was in _BLDEXCL
of UTILEXCL's sort to create dataset UNIQUE, which must
use internal SAS sort because its BY list is way over the
4092 character limit of host sort packages. By using a
REGION=256M (not REGION=0M, NO LONGER SAS-RECOMMENDED)
and by using these replacement values in CONFIGV9 that
were recommended by SAS Technical Support:
MEMLEAVE=25M
NOSORTBLKMODE
the error was eliminated. So I have added those option
values to the CONFIGV9 member in this change.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Change 25.084 Variable FILSEQ was wrong in TMS.DSNBRECD observations
TYPETMS5 created from the VOL record, for multi-volume, multi-file
VMACTMS5 tapes. FILSEQ does not exist in the VOL record, but MXG
May 4, 2007 creates a pseudo-DSNBRECD obs with the DSNAME in the VOL
May 29, 2007 record; MXG logic did not handle these cases correctly.
VMACTMS5 changed only cosmetic DEBUG statements.
May 29: TYPETMS5 member in MXG 25.04 did NOT contain this
correction; the member copied into MXG 25.04 was not the
tested member that is now updated and redated May 29.
Thanks to Tim Hare, Florida Department of Transportation, USA.
Thanks to Paul Naddeo, FiServ, USA.
Change 25.083 MXG 25.03 only. APAR OA20077 SMF 21 new compressed bytes
VMAC21 SMF21DBR and SMF21DBW were still wrong after two tries.
May 3, 2007 I missed the 4096 multiplier, and I reversed the label
text COMPRESSED/UNCOMPRESSED in all four variables.
Worse, the customer actually had to go to IBM Support,
who quickly and politely diagnosed my coding errors.
These old variables always had correct value:
BYTEREAD='UNCOMPRESSED*CHANNEL*BYTES*READ'
BYTEWRIT='UNCOMPRESSED*CHANNEL*BYTES*WRITTEN'
These new variables were wrong prior to this change:
SMF21DBR='COMPRESSED*DEVICE*BYTES*READ'
SMF21DBW='COMPRESSED*DEVICE*BYTES*WRITTEN'
These two new compression ratio variables are created:
SMF21CRR='READ*COMPRESSION*RATIO'
SMF21CRW='WRITE*COMPRESSION*RATIO'
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Ken C. Jobbitt, IBM Support, USA.
Change 25.082 Support for new XAMAP segments HSTAPP,VSIAPP,VSINAP,
EXXMHAPP VSISFT,VSISYS,VSIUSR and STOSCS creates new VMXHSTAPP,
EXXMHAPP XMVSIAPP,XMVSINAP,XMVSISFT,XMVSISYS,XMVSIUSR, and
EXXMOSCS XMSTOSCS datasets. Variables fron new segments SYTSXP
EXXMVNAP and SYTSXP are added to XAMCPUBY/XAMCPUTO datasets, new
EXXMVSFT variables from old segments SUBSUM,SYTRSG,SYTXSG,MTRMEM,
EXXMVSYS STORSG and SYTCPU are added to XAMSYS dataset, variables
EXXMVUSR from new segments PRCAPC,PRCAPM,SYTSXG,STOSXG are added
IMACXAM to XAMSYS dataset, new vars from IODVSW,USRCON,USRACT
VMACXAM will be decoded.
VMXGINIT
May 1, 2007
Thanks to Robert Obee, IMS Health, USA.
Change 25.081 NDM 'NM' records are now decoded, and output in NDMNM
VMACNDM dataset (previously output, but with only the header
May 1, 2007 variables). Variable NDMTIME is kept but it is not
populated in the sample SMF record.
Thanks to Trevor Ede, EDS New Zealand, NEW ZEALAND.
Change 25.080 Cosmetic protection for a user syntax error if the user
VMXGDUR failed to specify a DATETIME= variable that cause strange
VMXGSUM syntax errors. Now, MXG issues USER ABEND 1916 when that
May 1, 2007 required operand is missing.
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.079 MXG RMF III code only output the first LPAR's data in the
VMACRMFV ZRBLCP dataset, which now has one observation for each
May 1, 2007 LCPUADDR for each LPARNAME that has engines assigned.
Thanks to Jerry Urbaniak, Acxiom, USA.
Thanks to Sam Knutson, Geico, USA.
Change 25.078 Documentation. These MXG members issue USER ABENDs with
INSTALL an ABORT ABEND nnnn; statement, so these programs could
May 1, 2007 ABEND with the listed User Abend Code:
Feb 1, 2015
USER Member USER Member
ABEND ABEND
1 VMACTMV2 1234 VMACTMS5
69 VMACSMF 1911 VMXGRMFI
69 VMACTMV2 1912 VMXGRMFI
69 VMACTMVS 1913 VMXGRMFI
99 VMACCADM 1914 VMACSET
99 VMXGVTOC 1914 VMXGSET
99 VMXGVTOF 1915 VMACSET
111 VMACTNG 1916 VMMXGDUR
666 UTILDUMP 1917 UTILBLDP
666 UTILDUMP 1918 UTILBLDP
666 VGETALOC 1919 UTILBLDP
666 VMACMVCI 1954 BLDSMPDB
666 VMACXAM 2098 VMACTMVT
666 VMXGALOC 2099 VMACTMD8
666 VMXGSUM 2099 VMACTMDB
666 VMXGSUME 2099 VMACTMDC
990 VMACRMFI 2099 VMACTMDQ
991 IHDRTMS5 2099 VMACTMTC
992 IHDRTMS5 8888 VGETOBS
0001 VMACTMV2 8888 VGETOBS
0010 VMACPKSZ MXGABND VMAC110
0069 VMACTMV2 MXGABND VMACSMF
0666 IMACNORM MXGABND VMACSMF
1099 TYPEMOND MXGABND VMACTMS5
1099 TYPETMON MXGABND VMXGRMFI
1099 VMACMON8
1099 VMACTIMS
1099 VMACTMO2
1111 MONTHASC
1111 MONTHBL3
1111 MONTHBLD
1111 MONTHBLS
1111 MONTHDSK
See text of Changes 23.184, 29.290, 29.304, 33.020 36.136
for syntax/usage of &MXGABND USER ABEND macro variable.
Change 25.075 DB2 V8.1 incompatibly changed the QBGL Group Buffer Stats
VMACDB2 segment, making these nine fields now reserved:
Apr 30, 2007 QBGLAD QBGLAN QBGLAR QBGLAZ QBGLMN QBGLRB QBGLRF
QBGLSU QBGLXN
and adding five new variables to PDB.DB2GBPST dataset:
QBGLCM QBGLCR QBGLMW QBGLWP QBGLWS
Thanks to Martin Packer, IBM, WORLDWIDE.
Change 25.074 Extraneous DATA; SET; BY ...; statements, left over from
VMAC7072 debugging the SPLIT70 logic, is removed.
Apr 30, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.073 Enhancement to "Nigel's Monitor for AIX and Linux' adds
EXNMONAA variables HOST and INTERVAL to NMONINTV dataset, decodes
IMACNMON the IOADAPTR and LPAR data types, and creates new NMONAAA
VMACNMON dataset with the "AAA" configuration records information.
VMXGINIT
Apr 29, 2007
Thanks to Massimo Pugliese, ELSAG Spa, ITALY.
Change 25.072 Sample tape statistics reports using STC VTS SMF records
DALYTAPE and the MXGTMNT tape mount and allocation records. Can
Apr 26, 2007 be used after a modified BUILDPDB, or with the %UTILBLDP
example in the comments, the reports can be created from
an SMF data file.
Change 25.071 MXG 25.03 only UTILBLDP: did not generate the _Sxxxx sort
UTILBLDP macros when BUILDPDB=NO was specified due to a typo; the
Apr 26, 2007 USERADD= datasets were not sorted into the PDB library.
May 7, 2007 Additionally, these products that need deaccumulation and
require their _Sxxxx product sort macros to be invoked:
7072 DB2 HSM NTCP ROSC TMDB TPX 103 28
will now have those macros invoked whenever USERADD= is
invoked for them.
-May 7: Support for SMF ID=102 record, which requires the
_HDR102, _END102 macros. With over 300 IFCID/subtypes,
you can select which T102Snnn datasets are created using
USERADD=102.63 102.106 102.141 102.142 syntax. The 102
tokens must be contiguous in your USERADD= parameter, but
do not need to be continuously numbered, nor do they need
to be in numeric order in your USERADD= in you %UTILBLDP.
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.070 -MXG's SYSLOG-reading program failed, INVALID ARGUMENT TO
SYSLOG FUNCTION INPUT, because the final tested changed member
Apr 25, 2007 was still in my "USERID.SOURCLIB" from Nov, 2005, when it
Apr 28, 2007 should have been moved into the MXG source library. The
Apr 29, 2007 output dataset TYPETMSG contains an observation for each
SYSLOG event (but not for each physical record in SYSLOG:
records starting with "S" are continuation records, and
their text is appended in the variable TMTGMTXT so that
only one output observation is created for these events.
-Variable TMTGMTXT was increased to $120 from $80, which
caused text for "S" records to be truncated.
-In addition to using thid code to read SYSLOG messages,
you can also write any SYSLOG message to SMF, using the
MXGTMNT Tape Mount Monitor program (in ASMTAPEE), which
with then be output in BUILDPDB's TYPESYSL dataset.
Thanks to MP Welch, SPRINT, USA.
Thanks to Stephen Van Scyoc, SPRINT, USA.
Change 25.069 Service Class names can be "wild-carded" using the colon
UTILRMFI symbol, if you have similarly named Service or Reporting
VMXGRMFI Class names to map to workloads in your WORKnn= argument.
Apr 24, 2007
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.068 The SQL text from QW0141TX was not printed if the length
ANALDB2R of text was less that 60 bytes, due to a typo; the line
Apr 23, 2007 ELSE TEXT=QW0141TX; is corrected to ELSE TEXT1=QW0141TX;
Thanks to Michael Gebbia, Eddie Bauer, USA.
Change 25.067 The VMXGUSE macro is updated to add the _STY70 macro if
VMXGUSE processing of the SMF 70 records was requested; VMXGUSE
UTILBLDP is still supported, but the newer UTILBLDP is recommended
Apr 20, 2007 as the better tool, as it offers many more options; it
was also updated to ensure _STY70 is invoked when needed.
-MXG25.03 also had double percent instead of %VMXGVERS.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.066 DB2 SMF 102 IFCID=225 record with invalid header offset
VMACDB2H of '0CB5'x, 3253 decimal, for QWHCEUID_Off, but with its
Apr 20, 2007 LRECL of only 486 bytes, caused INPUT STATEMENT EXCEEDED.
The input now validates that the offset is LE LENGTH.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 25.065 Enhancement to UTILBLDP to select the ASUMxxxx members to
UTILBLDP be executed when BUILDPDB=YES is specified. The default
Apr 18, 2007 list of members %INCLUDEd after BUILDPDB is not changed,
but they are now set in the new MXGINCL= argument:
MXGINCL=
ASUMUOW ASUMCICX ASUM70PR ASUMCACH ASUMTAPE
ASUMTMNT ASUMTALO ASUMDB2A ASUMDB2B,
so you can now remove any unwanted ASUMs.
Thanks to Tom Kelman, Commerce Bank of Kansas, USA.
Change 25.064 Several QISE variables should have been DIF()'ed as they
VMACDB2 contained accumulated values; now all QISE variables are
Apr 17, 2007 DIF()'d except for those that contain counts of pages or
statements, in creating the PDB.DB2STATS dataset from the
SMF 100 Subtype 1 DB2 Statistics records. Also, QISExxxx
labels with "Dataspace" were corrected to "DBD POOLS".
Thanks to Lori Masulis, Fidelity Systems, USA.
Change 25.063 Additional SWAP resaons codes were added to $MGO79SR
ADOC71 format and in the ADOC71 member documentation.
FORMATS VALUE $MG079SR
Apr 17, 2007 '00'X='00X:UNKNOWN'
'AS ='AS:AUXSTOR SHORTAGE (VERY UNLIKELY)'
'AW'='AW:APPC WAIT'
'DW'='DW:DETECTED WAIT'
'EX'='EX:CAP EXCHANGE'
'IC'='IC:IMPROVE CSTORE'
'IP'='IP:IMPROVE PAGING'
'IW'='IW:OMVS INPUT'
'LW'='LW:LONG WAIT'
'MR'='MR:MAKE ROOM'
'NQ'='NQ:CAP ENQUEUE'
'NS'='NS:TRANSITION TO NON-SWAPPABLE'
'OW'='OW:OMVS OUTPUT'
'RQ'='RQ:REQUEST SWAP'
'RS'='RS:REAL STORAGE SHORTAGE'
'SR'='SR:IN-REAL'
'TI'='TI:TERMINAL INPUT'
'TO'='TO:TERMINAL OUTPUT'
'TS'='TS:TRANSITION'
'US'='US:CAP UNILATERAL'
'VR'='VR:VIRTUAL REAL REQUEST'
'WT'='LW:LONG WAIT'
'XS'='XS:AUX STORAGE SHORTAGE'
;
Thanks to Warren Hayward, TJX, USA.
Change 25.062 Protection for truncates RMF ID=72 SUBTYPE=7 LENGTH=78.
VMAC7072 while the site examines logs for x37 ABENDS and/or opens
Apr 16, 2007 a problem report with IBM.
Thanks to Ravi Kumar, CSC, USA.
Change 25.061 Variable SMF12WIC is padded with '00'x instead of blanks;
VMAC120 those '00'x are now translated to blanks.
Apr 15, 2007
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA
Change 25.060 Using TYPSTPF invoked very old PROC SORTs that still had
VMXGTPFI invocations of %VMXGFOR, long ago archaic and no longer
VMXGFOR needed, but they caused a 180 Syntax error for "FORCE".
Apr 12, 2007 The %VMXGFOR calls were removed from VMXGTPFI, and that
member was revised to "FORCE" is only created for SAS
V5 and V6 where it was originally required.
Change 20.327 in 2003 documented the removal of FORCE.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.059 All %VMXGVERS(25.03,MEMBER) invocations were typo'ed as
DOC %VMXGVERS(25.03MEMBER);. Wrong syntax, but, fortunately
Apr 12, 2007 there was no error; the old macros would still be noted
in the messages to the log, which still had the right
information, albeit slightly different than expected.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
====== Changes thru 25.058 were in MXG 25.03 dated Apr 12, 2007=========
Change 25.058 Variable NDMSNODE appeared twice in the _BNDMCT by list.
VMACNDM
Apr 12, 2007
Thanks to Trevor Ede, EDS New Zealand, NEW ZEALAND.
====== Changes thru 25.057 were in MXG 25.03 dated Apr 10, 2007=========
Change 25.057 The 9672x CPUTYPE without APAR OW37565 does not populate
VMAC7072 SMF70CIN, causing PARTNCPU to be zero. Now, MXG forces
Apr 10, 2007 SMF70CIN='CP' when CPUTYPE='9672'X and NRCIXGTO=0.
Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.
Change 25.056 DB2STATS SMF 100 Subtype 1 Language Environment QLExxxxx
VMACDB2 LE variables have always been wrong, partially due to MXG
Apr 10, 2007 code errors (I assumed the 8-byte fields contained both a
duration and a count, and deaccumulated some fields that
were not accumulated), and partially because IBM's record
is incorrectly written and does not agree with the DSECT.
The 8-byte header (normally has the 'QLES' eye catcher)
doesn't exist, but LENQLES=168, and visual examination of
hex dumps showed the extra 8 bytes are inserted between
QLELOWIM and QLESTG1M fields. DB2 Versions 1.6 thru 1.8
SMF records all have LENQLES=168 and the inserted field.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 25.055 Support for SAMS objects 2151,2226,2229 and 2231 has been
EXSAM151 validated and new datasets created.
EXSAM226 -Many variables in many of the existing SAMSnnnn datasets
EXSAM229 were renamed to avoid conflict with same-named variables
EXSAM231 created from other SMF records.
IMACSAMS
VMACSAMS
VMXGINIT
Apr 8, 2007
Change 25.054 DB2TCBTM in DB2ACCT/ASUMUOW includes QWACSPCP,QWACTRET
VMXGUOW CPU times, but with OTE, the DB2TCBTM includes some of
Apr 6, 2007 the CPU time already recorded in the CICSTRAN's TASCPUTM;
using PDB.ASUMUOW, the correct CPU metric would be the
sum of TASCPUTM from CICSTRAN and QWACSPCP and QWACTRET
from DB2ACCT. This change SUMs QWACSPCP and QWACTRET
into PDB.ASUMUOW so that you can add those DB2 CPU times
to the CICS CPU times with no overlap.
Change 25.053 Variable PCTCPUBY greater than 100% in PDB.ASUMCEC, but
VMXG70PR only in hour intervals when LPARs were started/stopped,
Apr 5, 2007 and only if the DURATM of the last LPAR (alphabetically)
was less than the full hour. DURATM was intended to be
set to CECINTRV, but MXG set it only for FIRST.SMF70GIE;
it was then being output from the DURATM of that last
LPARNAME. DURATM=CECINTRV is now set unconditionally.
Thanks to David Bixler, FISERV, USA.
Thanks to Randy Shumate, Lexus-Nexus, USA.
Change 25.052 Support for TDSLink Version 630 adds new ZCOST datasets
EXTDS16 from subtypes 16x, 17x, 18x and 19x:
EXTDS17 dddddd dataset description
EXTDS18 TDS16 TDSL16 ZCOST CPC
EXTDS19 TDS17 TDSL17 ZCOST LPAR
IMACTDSL TDS18 TDSL18 ZCOST SYSPLEX
VMACTDSL TDS19 TDSL19 ZCOST SYSPLEX/CPC
VMXGINIT
Apr 5, 2007
Change 25.051 Change 24.116 reported NRIFACPU for z990/2084 CPUTYPE was
VMAC7072 not countable - SMF70CIN='ICF' in LPARNAME='PHYSICAL' in
Apr 6, 2007 RMF 70 records instead of 'IFA' - and created the macro
variable CECIFANR so you could set NRIFACPU if needed.
Now, Al has found a way using the non-PHYSICAL-LPARNAME
segments (that do have SMF70CIN='IFA' for IFAs!) to count
and populate variable NRIFACPU for z990s with IFAs.
-New field SMF70CTN, the total count of engines of that
SMF70CIN type (CP,IFL,etc), in the CEC was incorrectly
INPUT, but it was not kept nor used. It still is not used
for NRxxxCPU in ASUM70PR, but now it is input correctly
and kept in PDB.TYPE70PR dataset. It will have the same
value in all obs of that engine type, so a 27-engine CEC
will have SMF70CTN=27 in all obs with SMF70CIN='CP', both
in both the LPARNAME='PHYSICAL' and LPARNAME='real' obs.
Thanks to Al Sherkow, I/S Management Strategies, USA.
Change 25.050 Support for CrossSysplexManager user SMF record (Skill
EXCSMDDN Software) creates two new datasets:
EXCSMJOB CSMDDN CSMDDN CROSS SYSPLEX DDNAME
IMACCSM CSMJOB CSMJOB CROSS SYSPLEX JOB
TYPECSM
TYPSCSM
VMACCSM
VMXGINIT
Apr 4, 2007
Thanks to ???, ???, Italy.
Change 25.049 Format $MGSASPR, which maps SAS Procedure Name in the SAS
FORMATS "USER" SMF record, has new QUANTREG and ROBUSTRE values
Apr 2, 2007 added for SAS STAT product.
Thanks to Len Rugen, University of Missouri, USA.
Change 25.048 Corrections to MXG 25.02 included correction for the
BLDSMPDB libname=PDB operand, the CALL SYMPUT('SRTDSN',SORTDBY)
DOC spelling, and logic related to VGETSORT invocation.
Apr 1, 2007 References to WEEK1 were replaced with WEEK.
Apr 17, 2007 New SORTEDBY= option can be set to sortedby=no to bypass
the requirement for input weekly/daily datsets to be
sorted. 17Apr07: Null input library protected with msg.
Thanks to Loren Mitchell, Los Angeles Couty Office of Education,USA.
Change 25.047 -Support for APAR OA19502, adds SMF14KET, the Key Exchange
FORMATS Time (Encryption Overhead). This time is only recorded
VMAC1415 in SMF 15 output records and only for a CLOSE processing
Apr 1, 2007 after a non-parallel OPEN writing file sequence one from
the loadpoint. Otherwise, SMF14KET is zero. This is the
elapsed "wall clock" duration, and is NOT a CPU time
metric. A "non-parallel OPEN" is when the parameter list
passed to OPEN includes only 1 DCB or ACB.
-New $MG014CD format decodes the SMF14CD1 and SMF14CD2
Encoding Mechanisms:
L:LABEL - the key label itself is to be stored as part
of the EEDK structure on the tape cartridge.
H:HASH - "Public Key HASH" - a hash of the public key
referenced by the key label is to be stored
on the cartridge rather than the key label
itself. Storing the hash value rather than the
key label itself allows for greater flexibility
when tapes are exported to another location,
especially if that location may be using a
different key label (than the originating site)
to refer to the same key.
Thanks to Jack Muehl, CitiGroup, USA.
Change 25.046 Cosmetic. INVALID DATA FOR MDY message and hex dumps of
VMACSTC the first two instances are printed when the LSBTIME date
Mar 31, 2007 field contains zeros. Now, LSBTIME is only created when
the data exists. These records with no date also have
zeros in all other fields, and so the defective records
were not output into the STCLMU dataset, either before or
after this change.
Thanks to David Kaplan, Depository Trust, USA.
Change 25.045 Variable TTTOD was not kept in TPFDH, TPFKC, or TPFSB
VMACTPF datasets, but were referenced in BY statement in _STPFKC.
Mar 30, 2007 Now, that retained variable is kept in those datasets.
Thanks to Chris Weston, SAS Institute, USA.
Change 25.044 New intervals (obviously for TRENDing, and not tactical!)
VMXGDUR of QUARTER, SEMIANN, and ANNUAL will create summary data
VMXGSUM when those arguments are used. The code change was in
Mar 28, 2007 VMXGDUR; only comments were changed in VMXGSUM.
Thanks to Nalini Elkins, Inside Products, USA.
Change 25.043 Support for z/VM 5.3.
EXIODHPC (Apr 12 changes were moved Apr 17, were not in 25.03.)
EXIODHPP
EXIODLPT
EXMTRHPP
EXPRCAPC
EXPRCAPM
EXPRCDIA
EXPRCINS
EXSAMSDT
EXSCLSCA
EXSTOSCS
EXSTOSXG
EXSTOSXP
EXSYTLCK
EXSYTSPT
EXSYTSXG
EXSYTSXP
EXVNDLSD
EXVNDLSU
EXVNDSES
IMACVMXA
VMACVMXA
VMXGINIT
Mar 28, 2007
Apr 12, 2007
Change 25.042 Enhancement to support HSM records with different SMF IDs
VMACHSM perhaps from different systems. HSM writes 2 SMF records
Mar 28, 2007 with and ID and ID+1 architecture, and MXG defined two ID
macros that you tailored with your SMF TYPE numbers:
MACRO _IDHSMDS 224 %
MACRO _IDHSMDS1 225 %
But I have redefined the second ID macro to now be
MACRO _IDSHMDS1 _IDHSMDS+1 %
which has no impact on your existing IMACKEEP tailoring,
but now, you could use this logic to redefine them:
MACRO _IDHSMDS 512 OR (ID=224 AND SYSTEM='SYS1')
OR (ID=229 AND SYSTEM='SYS2') %
MACRO _IDHSMDS1 512 OR (ID=225 AND SYSTEM='SYS1')
OR (ID=230 AND SYSTEM='SYS2') %
and MXG will process both pairs of HSM records.
This works because the reference syntax in VMACHSM is
IF _IDHSMDS THEN DO; IF _IDHSMDS1 THEN DO;
Thanks to Chuck Hopf, Bank of America, USA.
Change 25.041 Support for CICS/TS 3.2 (INCOMPATIBLE).
EXCICDHD -Major Change: All CICS CPU times are expanded to 8 bytes
EXCICISR with significant increase in captured TASCPUTM possible.
EXCICLDB -CICS Transaction Segments in SMF 110 subtype 1 can be
EXITCICS compressed; the new MXG member EXITCICS is the ASM code
IMAC110 to create a SAS Infile Exit (named "CICS") that will read
UTILEXCL the compressed (or uncompressed) records. To install,
VMAC110 you ASM and LinkEdit the EXITCICS code into a load module
VMXGINIT that you put in a load library you add to the //STEPLIB,
Apr 7, 2006 and tell MXG using %LET SMFEXIT=CICS; in your //SYSIN.
Sep 19, 2006 Test records were reduced from 32K to about 6K bytes, but
Oct 14, 2006 only the 110-1 records are compressible.
Mar 27, 2007 -UTILEXCL updated with new CICSTRAN fields added in 3.2.
Apr 12, 2007 -Updates for the changed Statistics Subtypes:
Jun 29, 2007 (INCOMPATIBLE except for DST, DSR, and MNG):
STID DSNAME New Variables added.
- 2 SMS
==> Nothing New in DSECT.
- 64 CICDST DSTCIUHI DSTCIULO DSTNIUHI
DSTNIULO
==> But 20 bytes added are not doc'd.
- 65 CICDSR DSRCIULO DSRCIUHI
==> But 20 bytes added are not doc'd.
- 67 CICFCR DFHA17DS DSECT.
==> Nothing New in DSECT
- 74 MQG MQ Connection Statistics Global
New
==> DFHMQGDS DSECT does not exist
- 81 MNG New Compression Variables
==> DFHMNGDS DSECT is not current.
-109 ISR IP Connection (Resource)
New
==> DFHUSRDS DSECT does not exist
-117 SJG
==> Nothing New in DSECT.
-117 SJR
==> Nothing New in DSECT.
MXG 25.03 contained the critical compatibility changes,
but MXG 25.07 contains the full support for compressed
ID=110 Subtype=1 CICS/TS 3.2 SMF records.
Change 25.040 Support for APAR OA20077, adds UNCOMPRESSED tape device
VMAC21 read/write bytes to TYPE21/PDB.TAPES, complementing the
ASUMTAPE existing COMPRESSED tape channel read/write bytes that
Mar 21, 2007 have always been in SMF type 21 records:
Apr 10, 2007 BYTEREAD='COMPRESSED*CHANNEL*BYTES*READ'
BYTEWRIT='COMPRESSED*CHANNEL*BYTES*WRITTEN'
SMF21DBR='UNCOMPRESSED*DEVICE*BYTES*READ'
SMF21DBW='UNCOMPRESSED*DEVICE*BYTES*WRITTEN'
-Apr 10: ASUMTAPE updated to keep SMF21DBR/SMF21DBW.
Change 25.039 Support for AIX Tapas-C performance data creates these
EXAXTCPS datasets:
EXAXTCPU dddddd DATASET Description
EXAXTDSK AXTCPS AIXTCPUS CPUS
EXAXTFS AXTCPU AIXTCPU CPU INTERVAL
EXAXTFSS AXTDSK AIXTDSK DISK
EXAXTIP AXTFS AIXTFS FS
EXAXTIPS AXTFSS AIXTFSS FS-S
EXAXTLAN AXTIP AIXTIP IP
EXAXTLPA AXTIPS AIXTIPS IPS
EXAXTMEM AXTLAN AIXTLAN LAN
EXAXTNFS AXTLPA AIXTLPA LPARS
EXAXTPGI AXTMEM AIXTMEM MEM
EXAXTPGS AXTNFS AIXTNFS NFS
EXAXTPRO AXTPGI AIXTPGI PAGSP-S
EXAXTSYC AXTPGS AIXTPGS PAGSP
EXAXTSYI AXTPRO AIXTPRO PROC
EXAXTTCP AXTSYC AIXTSYC SYSCALL
EXAXTUDP AXTSYI AIXTSYI SYSIO
EXAXTWLM AXTTCP AIXTTCP TCP
EXAXTWLS AXTUDP AIXTUDP UDP
VMACAIXT AXTWLM AIXTWLM WLM
IMACAIXT AXTWLS AIXTWLS WLMS
VMXGINIT
TYPEAIXT
TYPSAIXT
Mar 16, 2007
Change 25.038 TMON/DB2-created SMF 101 Subtype 1 caused INPUT STATEMENT
VMACDB2 ERROR because the record is defective; LENQPAC=390 but
Mar 16, 2007 there were only 358 bytes of data in the segment. This
INPUT EXCEEDED error is now protected, but the data in
second and subsequent observations in DB2ACCTP dataset
will be trashed.
Thanks to Robert McElhaney, Texas Workers Commission, USA.
Change 25.037 SORTEQUALS option should NOT have been added to CONFIGV8,
CONFIGV8 (MXG 25.02 only, Change 25.028) as that option was added
Mar 16, 2007 in SAS V9, and did not exist in SAS V8.
Thanks to Alan Gray, CareFirst, USA.
Change 25.036 INPUT EXCEEDED for SMF 1415 in MXG 24.24, when subtype=7
VMAC1415 encrypted tape segment exists; line 743 should have been
Mar 14, 2007 -130 and not -32. And now, with data, I can see that the
Encoding Mechanism Key 1 and 2 fields, SMF14CD1/SMF14CD2
actually contain EBCDIC characters (L, H), although IBM
still has not answered my queries as to how to decode the
field or what it contained. Also, the Key Label 1/2,
SMF14KL1/KL2 are now FORMATed $HEX128.
See Change 24.047 additions in MXG 25.03.
Thanks to Douglas C. Walter, Citicorp, USA.
Change 25.035 Support for SMF 119 for z/OS 1.8 (INCOMPATIBLE, because
VMAC119 MXG INPUT statements for subtype 70 were missing OFF119xx
Mar 14, 2007 to relocate the pointer). New fields were added to many
datasets by z/OS 1.8, as noted in the comments.
Thanks to Marty Rhodes, The Hertz Corporation, USA.
Change 25.034 Support for CopyCross SMF event record, with mounted and
EXCOPYCR unloaded datetimestamps, VOLSER, data volumes in and out,
IMACCOCR in the CPYCROSS dataset. CopyCross was formerly an EMC
VMACCOCR product, but now is a Diligent product which is named
TYPECOCR VTF Mainframe 2.1.0 (Virtual Tape Facility Mainframe
TYPSCOCR Systems.
VMXGINIT
Mar 14, 2007
Thanks to Brian Felix, Wachovia, USA.
Thanks to James Bentley, Wachovia, USA.
Thanks to Lana McCormick, Wachovia, USA.
====== Changes thru 25.033 were in MXG 25.02 dated Mar 10, 2007=========
Change 25.033 Support for ASMTAPEE assembly under z/OS 1.8. IBM has
ASMTAPEE deleted fields in internal macro definitions that caused
Mar 10, 2007 "NOT FOUND" errors when assembled under z/OS 1.8. This
revision only removed those references, but had no impact
on the actual execution of MXGTMNT.
Change 25.032 RMF-like "CPU Activity" report was incorrect when IRD was
ANALRMFR active (ONLINE TIME, MVS BUSY TIME, CPU NUM), in the
Mar 10, 2007 "Partition Data" report, WGT PROCESSOR NUM, LOGICAL
Apr 10, 2007 Processors effective were incorrect, and in the "LPAR
Cluster" report, LPARCPUS was incorrect.
-Missing comma in 25.02 after MAX=NRICFCPU ... , added.
Thanks to David Klein, DOITT City of New York, USA.
Change 25.031 Variable CA7INID was not kept, because it was misspelled
VMACTPMX as CAC7IDID in the KEEP list.
Mar 7, 2007
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 25.030 TYPE42DS variables from Data Set I/O Statistics Section,
VMAC42 input when OFFDSIO is non-zero for this observation:
Mar 7, 2007 AVGCONMS AVGCUQMS AVGDAOMS AVGDISMS AVGIOQMS AVGPNDMS
CACHCAND CACHHITS CACHRATE CHITPCT CIOPCT DASDMPL
DASDRATE DCMEPCT HITPCT ICLS IOCOUNT MAXRSPTM
MAXSRVTM RCIPCT RDHITPCT RESPTIME RLCS SEQIOS
WRITCAND WRITHITS
were incorrectly carried forward into the next physical
TYPE42DS observation, if it did not have a Data Set I/O
Statistics Section. Now, IF OFFDSIO=0, those variables
are set missing. Note that these variables TYPE42DS
S42AMSRB S42AMSRR S42AMSWB S42AMSWR S42AMDRB
S42AMDRR S42AMDWB S42AMDWR S42AMZRB S42AMZRR
S42AMZWB S42AMZWR
are only populated when the Access Method Statistics
Section exists, i.e., when OFFDSAM is non-zero.
I do not know why some DSNAME observations contain both
or only DSIO, or only DSAM data, but this sample had:
DSIO and DSAM 15808
DSAM only 914
DSIO only 6112
Thanks to Diane Eppestine, AT&T Services, Inc, USA
Change 25.029 The individual IORATEn per-engine I/O rates in PDB.TYPE70
VMAC7072 were divided by DURATM, but IBM Reports use the SMF70ONT
Mar 7, 2007 UpTime as the denominator, so the IORATEn variables are .
now changed to match the RMF Reports. The total IORATE
variable, however, is NOT changed, and is still divided
by the DURATM, to be consistent with total IORATE data
in TYPE74, TYPE78, and other data sources that don't have
and idea about individual CPU engine up times.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 25.028 Changing the SAS default option to NOSORTEQUALS created
AUTOEXEC incorrect values in PDB.ASUM70PR/PDB.ASUMCEC datasets for
CONFIGV9 DURATM,PCTCPUBY,plus, but there was no error message. A
VMXG70PR code change in MXG 24.07 in ASUM70PR is the real culprit,
VMXGPRAL but the code works perfectly with the default SORTEQUALS.
UCOMPSOE Please run PROC OPTIONS to confirm you have SORTEQUALS.
Mar 10, 2007 If not, then you should use this IMMEDIATE CIRCUMVENTION:
Mar 13, 2007 Change the option for the MXG job that runs ASUM70PR.
Mar 16, 2007 You can change the option:
- on the // EXEC statement:
//MXGSTEP EXEC MXGSASV9,OPTIONS='SORTEQUALS'
or you can change the option
- in your SYSIN stream, with an OPTIONS statement;
//SYSIN DD *
OPTIONS SORTEQUALS;
%INCLUDE SOURCLIB(....);
I didn't really know any of this stuff until this error:
When SORTEQUALS is specified, SAS ensures that the input
order is preserved when BY variables have equal values.
In the SPLIT70 redesign, I added logic that depended on
LCPUADDR to be ascending order, but I failed to made sure
it was; with SORTEQUALS, since the original PDB.TYPE70PR
was in LCPUADDR order, the new logic worked just fine.
However, when NOSORTEQUALS is specified, you have told
SAS to not spend any more resources to preserve the input
order, and, in this case, the output data was no longer
in LCPUADDR order when NOSORTEQUALS was specified.
The MXG coding error is now corrected, by adding LCPUADDR
to the BY LISTs for the CPS70PRn sorts, so the ASUM70PR
logic works with SORTEQUALS or NOSORTEQUALS.
-However, now that I have seen this error, and even though
it's extremely unlikely to occur elsewhere in MXG code,
since MXG has always used only the SORTEQUALS option, I
have added SORTEQUALS to CONFIGV9 and AUTOEXEC members,
to protect for any other exposures. At worst, changing
NOSORTEQUALS to SORTEQUALS might make the SORT use a few
more CPU cycles and do a few more I/O.
-Since the error results in very bad values, it looks like
most sites still have the SAS default of SORTEQUALS, or
this error would have surfaced during earlier testing.
-Summary of MXG setting of SAS options:
For z/OS execution of MXG, CONFIGV9 sets MXG SAS options:
MXG's CONFIGV9 member still specifies NOTHREADS due to
old SAS 9.1.2 errors; see Change 22.207. However,
THREADS is primarily useful in non-z/OS; running
multiple z/OS jobs in parallel on multi-engine boxes
is essentially what THREADS is all about!
MXG's CONFIGV9 member now specifies SORTEQUALS.
For ASCII execution, AUTOEXEC sets MXG SAS options:
MXG's AUTOEXEC member has never specified THREADS, so
you get your site's default.
MXG's AUOTEXEC now specifies SORTEQUALS;
-An unrelated, harmless DIVIDE BY ZERO message if PARTNCPU
was zero is now protected. Only occurred with old 1999
test data that was itself defective, but the exposure is
corrected.
-The VMXGPRAL ("Print ALL") utility was revised to invoke
PROC COMPARE on all datasets in two libraries.
-Why choose NOSORTEQUALS? It might save a few CPU cycles
and a few I/Os, since it just merges the final sort segs,
instead of sorting, but, according to informal feedback
from SAS folks, it's only really required if you are use
the THREADS option on ASCII platforms where you have more
than one CPU. So what to do if your SAS folks demand you
don't change NOSORTEQUALS? The new UCOMPSOE utility will
run two PDB-builds, with NOSORTEQUALS & SORTEQUALS, and
then uses the (enhanced) VMXGPRAL to PROC COMPARE each
datasets in the two PDB's for differences. Unfortunately,
PROC COMPARE will report all datasets with different sort
order, even though the two dataset's values are the same.
You use the PROC COMPARE output to identify differences,
and then use PROC MEANS N MIN MAX SUM DATA= OLD/ NEW to
verify that the numeric contents are the same.
For example, MXG 25.02 found these datasets were built
in different order with the two options in effect:
TYPE70 TYPE70PR TYPE74CO TYPE74DU TYPE74PA
TYPE74ST TYPE77
but the PROC MEANS showed no actual value differences.
Mar 16: Find four lines with BWM. Delete the line which
has PROC PRINT and printed lots of useless output.
Thanks to Salis Gross Curdin, Credit-Suisse, SWITZERLAND.
Thanks to MP Welch, SPRINT, USA.
Change 25.027 JCLTESTx only. INPUT DATASET PDBMONIDBDS DOES NOT EXIST
VMACMONI error in no-longer-used VMACMONI due to missing second
Mar 7, 2007 period; the correct syntax is
MACRO _LMONDBD &PMONDBD..MONIDBDS %
Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND.
Change 25.026 Cosmetic. DIVISION BY ZERO message if IORATE was zero;
ANALFIOE now, that denominator is tested prior to the division.
Mar 6, 2007
Thanks to James Majeski, AT&T Services, Inc, USA
====== Changes thru 25.025 were in MXG 25.01 dated Mar 5, 2007=========
Change 25.025 Support for APAR OA19453, which adds a new 4-byte counter
VMAC7 (SMF7NROX) that is now used instead of the 2-byte SMF7NRO
Mar 6, 2007 count of lost SMF records when SMF 7 data lost record is
written. The MXG Variable LOSTRECS is populated from the
new SMF7NROX field if it is present and SMF7FL1 bit is
set that NROX is populated.
Change 25.024 INPUT STATEMENT EXCEEDED for RACF 80 WHEN (301) Extension
VMAC80A segment for OMVS and PROXY, but neither had any of the
Mar 2, 2007 expected data segments. Now, LENLEFT is calculated and
tested prior to the INPUT.
Thanks to Robert Sample, Atlanta Journal-Constitution, USA.
Change 25.023 The two examples that construct datetime ranges from one
ANAL16 dataset, to build a format for selection from a second
ANAL30 dataset used DATETIME21.2 characters in the format, but
Mar 2, 2007 that failed when months were crossed due to month names.
This redesign uses PUT(datetime,13.2) to create the text
(number of seconds since 1/1/1960) for the format item.
Less pretty when printed, but it will always work.
Thanks to Tom Elbert, Assurant, USA.
Change 25.022 The RMF III ENC extension was usually not INPUT because
VMACRMFV the ENCG3XEO offset does not point to the extension that
Mar 1, 2007 was added to the end of the record ASMRMFV creates. That
extension is located at ENCG3XEO=ENCG3DEO+ENCD3DEL which
is now used to INPUT Service and Reporting Class
information from the ENC Extension.
Thanks to Brenda Rabinowitz, Merrill Lynch, USA.
Change 25.021 UTILEXCL messages are enhanced if the IMACICEZ EZA fields
UTILEXCL are found, to point you to read the text of Change 24.033
Mar 1, 2007 because there are multiple EZA segments created, and that
Apr 17, 2007 change text has tailoring instructions. IMACICE2 message
for EZ2 fields now also point you to read Change 24.033.
Change 25.020 The QWS3xxxx and QWS4xxxx variables are labeled IRLM and
VMACDB2 DDF (DIST), but the data could be reversed, with the DIST
Feb 28, 2007 data values in the QWS3xxxx variables and IRLM in the 4th
set of variables, because IBM has changed which data is
in which segment. This change tests the QWSnPROC name to
determine which data is present, so that the QWS3xxxx are
now ALWAYS the IRLM and QWS4xxxx is now ALWAYS the DDF
data, so the data always matches the variable labels, no
matter which segment had that ASID's data. Variables
QWSnASCB,ASID,EJST,PROC,PSRB,SRBT,QWSnZSRB are created
in PDB.DB2STATS from QWSA segments in SMF 100 records.
Thanks to Rachel Holt, Fidelity Systems, USA.
Thanks to Lori A. Masulis, Fidelity Systems, USA.
Change 25.019 The RACF 0900-series IRRHFSU Unix System Services unload
VMACRACF fields all contain EBCDIC, rather than ASCII text. The
Feb 28, 2007 test data had been converted to ASCII when it was sent;
all of the $ASCII inputs are changed to $EBCDIC now.
Change 25.018 Support for eleven more optional CICS EZA02 fields with
IMACICE2 these similar names:
VMAC110 EZA0TCON EZA0TSTA EZA0TINV EZA0TDIT EZA0TDIP
Feb 28, 2007 EZA0TGIV EZA0TSEC EZA0TA08 EZA0TA09 EZA0TA10
Apr 16, 2007 EZA0TA11
because I assumed they were now the default set of fields
in that optional segment. However, as I have not seen
them at other sites, I suspect they were accidentally
created at this site, and thus not likely to exist in
your EZA02 fields. As documented in Change 24.033, you
must look at the output report from UTILEXCL to see what
EZAxxxxx fields exist in your data, and then EDIT the
IMACICE2 to only INPUT and LABEL those in your records.
Text was revised Apr 16, 2007. No code change.
Thanks to Paul C. Gordon, Bank of America, USA.
Thanks to Peter Krijger, ANZ National Bank, NEW ZEALAND.
Change 25.017 EXITCICS is the Assembly code for a SAS INFILE EXIT that
EXITCICS will read and uncompress SMF 110 subtype 1 records as
Feb 28, 2007 they are read. You assemble/link edit the ASM code in
Mar 7, 2007 the EXITCICS member to create a load module CICSIFUE in
MaR 10, 2007 a Load Library, concatenate that DSNAME to //STEPLIB DD
in your MXGSASV9 JCL procedure, and then tell MXG you
have the INFILE exit installed, using the (new in 24.24)
SMFEXIT macro variable:
//SYSIN DD *
%LET SMFEXIT=CICS;
%INCLUDE SOURCLIB(TYPE110);
and MXG will read compressed and/or uncompressed records
transparently. You can alternatively use ENGINE=CICS in
your FILENAME statement to invoke the INFILE exit.
- The LOAD MODULE must be named CICSIFUE.
- The INFILE EXIT/ENGINE name is CICS.
You need EXITCICS dated Mar 7. the Feb 28 didn't work.
Thanks especially:
Thanks to Rich Anderson, SAS Technical Support, USA, for
his extensive testing and investigation that made this work!
Change 25.016 Cosmetic. Variable SMFTIME was added to EXCLUDED FIELDS
VMAC110 FOUND error message to identify when the record was
Feb 27, 2007 written, so it could be compared with the time when the
CICS Dictionary Records had been written.
Thanks to Shirly Fung, HSBC, HONG KONG.
Change 25.015 ERROR: BY VARIABLE BLKBINST IS NOT ON INPUT WEEK.BLKBERRY
VMACNTSM is an INCOMPATIBILITY created by MXG Change 24.162, when
Feb 25, 2007 the new variable BLKBINST was added to the BY list for
the NTSM dataset BLKBERRY. The error only occurs in your
WEEKly or MONTHly PDB build, and only when you have one
or more PDBs that were created with the prior MXG version
(i.e., the variable does not exist in the old datasets).
Mini-tutorial on BY list variables in MXG:
Adding a new variable to the BY list for an existing MXG
dataset is done ONLY when it is absolutely needed. The
primary reason MXG has a BY list for each dataset is to
protect for duplicate records in the input file, When MXG
uses the NODUP option in PROC SORTing from the "WORK" to
the "PDB" library. The BY list must be complete so that
duplicate observations are adjacent. A secondary reason
is for retrieval performance; by creating datasets in
sorted order, an extra SORT can be avoided in your report
programs.
Error correction techniques:
-Fix it permanently now, by adding the new variable to all
of the old, existing DAYly and/or WEEKly PDBs that will
be needed to build the new WEEKly and/or MONTHly PDBs,
creating the variable with blanks for Character or a
missing value for Numeric variables. You will need to
look up the variable in the DOCVER member to find its
DATASET, then the variable name in the listing to find
the CHAR/NUM type and the LENGTH of the new variable,
and then add that variable to all of the prior-built PDBs
using this syntax:
For a character variable:
DATA OLDPDB.BLKBERRY;
SET OLDPDB.BLKBERRY;
LENGTH BLKBINST $32;
BLKBINST=' ';
or for a numeric variable:
DATA OLDPDB.BLKBERRY;
SET OLDPDB.BLKBERRY;
LENGTH BLKBNUMR 4;
BLKBNUMR=.;
You will need to point "OLDPDB" to one of the prior PDB
libraries that does not contain the new variable and
run the datastep, then change "OLDPDB" to the next PDB,
until all of the INPUT PDBs (dailies for WEEKBLD, or
weeklies and dailies for MONTHBLD).
And if the OLDPDB is a data library on TAPE media,
it gets more complicated; you cannot have a TAPE
PDB open for both INPUT and OUTPUT, and you cannot
replace-in-place a dataset in a Tape media library,
so you would need to use this syntax for each "PDB":
PROC DELETE DATA=WORK._ALL_;
PROC COPY IN=OLDTAPE OUT=WORK;
DATA WORK.BLKBERRY;
SET WORK.BLKBERRY;
LENGTH BLKBINST $32;
BLKBINST=' ';
PROC DELETE DATA=OLDTAPE._ALL_;
PROC COPY IN=WORK OUT=OLDTAPE;
Once you have added the new variable to all of the INPUT
PDB libraries, you can then rerun the WEEKBLD/MONTHBLD.
-Fix it temporarily by redefining the _Bdddddd macro so it
does not reference the variable for the WEEKBLD/MONTHBLD
job:
-Look in the IMACxxxx member to find the "dddddd" text
for the dataset with the error. In IMACNTSM, it lists
that dddddd=NTBLKB for BLKBERRY dataset.
-Then, look in he VMACxxxx member for _Bdddddd to find
the BY list variables. In VMACNTSM, _BNTBLKB has
MACRO _BNTBLKB DOMAIN SYSTEM BLKBINST STARTIME %
-Then, in the //SYSIN for the WEEKly/MONTHly job, you
would redefine the _Bdddddd macro with that variable
removed:
//SYSIN DD *
%LET MACKEEP=
MACRO _BNTBLKB DOMAIN SYSTEM STARTIME %
;
%BLDNTPDB(your arguments for WEEKly/MONTHly);
Since the new variable does exist in one of the INPUT
data sets, it will be propagated into the new WEEKly
PDB, so you would only need to use this circumvention for
a maximum of five weeks, and then all of your Weekly PDBs
will contain the new variable, and the redefintion of the
MACRO _Bdddddd can be removed from your Monthly Job.
However, this circumvention might fail due to NOTSORTED
condition, (only if the "PDB" dataset had more than one
value in BLKBINST variable); in that case, you would need
to re-SORT those datasets using the _Sdddddd dataset SORT
macro with the new _Bdddddd BY list definition:
//SYSIN DD *
%INCLUDE SOURCLIB(VMACNTSM);/*get _Sdddddd def*/
%LET MACKEEP=
MACRO _BNTBLKB DOMAIN SYSTEM STARTIME %
;
DATA WORK.BLKBERRY;
SET PDB.BLKBERRY;
_SNTBLKB
NOTE BENE: It is always STRONGLY recommended that you
install a new version of MXG on the first day of your
week, so that all of that week's daily PDBs are built
with the same MXG Version. It just works better!
Thanks to Terry Hein, ECOLAB, USA.
Change 25.014 No observations were output in NDMRT because of a missing
VMACNDM end of comment */ text.
Feb 23, 2007
Thanks to Michael Creech, Fidelity National Information Svcs, Ind.
Change 25.013 The PCTMVSBY in PDB.TYPE70PR when IRD was active and the
VMAC7072 engine was not online for the entire interval were wrong;
Feb 23, 2007 This also impacted the SHORTCPS value as well. Now, the
SMF70ONT is used instead of DURATM for PCTMVSBY.
Thanks to John A. Doan, T-SYS, USA.
Change 25.012 INPUT STATEMENT EXCEEDED RECORD for IBM ID=99 Subtype=1
VMAC99 because MXG thought there would always be a System State
Feb 21, 2007 Information Section, but this record had none. The offset
and segment length fields were populated, but the number
of segments contained zero. Now, MXG tests segment count
non-zero before reading that segment, and before OUTPUT
of the TYPE99_1 dataset. This record contained Trace
Table entries, so was thus a legitimate record.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Thanks to Warren Cravey, Fidelity Systems, USA.
Change 25.011A IBM Virtualization Engine TS7700 Series Statistics data
TYPEBVIR can now be created as a RECFM=U or RECFM=VB History file,
TYPSBVIR or those data can be written to SMF; this change supports
VMACBVIR both the SMF and History file records. By default, MXG
Feb 19, 2007 reads SMF data, but you must add MACRO _IDBVIR nnn % in
Feb 26, 2007 IMACKEEP tailoring member to define your SMF record ID.
To process the History File, change _SMF to _HISTFI in
your TYPEBVIR or TYPSBVIR member. The Point in Time
subtypes (01,02,10,11) are not written to the SMF file.
Change 25.011 The preliminary ANALMQMC member should no longer be used;
ANALMQMC it was preliminary and was replaced by revisions to the
Feb 21, 2007 ASUMUOW program. The dataset MQMUOW is no longer created
by ANALMQMC, as that logic is in a comment block, and now
only ASUMUOW is executed with ANALMQMC is executed.
Comments in the member were revised.
Thanks to Harald Seifert, HUK-COBERG, GERMANY.
Change 25.010 Support for TELEVIEW Release 4.4 was already in place;
VMACTELE there were no changes to their SMF record.
Feb 21, 2007
Thanks to Lawrence Hogg, NYU, USA.
Change 25.009 The new ERASEPDB option was not set to a default; it is
BLDSMPDB now set to YES.
Feb 15, 2007
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 25.008 -In IMACICOB, OMDBDB2LN should have been spelled OMBDB2LN.
IMACICOB -In IMACICOM, QMMLN should have been spelled OMMQLN.
IMACICOM
Feb 15, 2007
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 25.007 The optional CICS BMC CMRDATA has variables CMDUDATA and
IMACICMR CMDDBCCP reversed; the correct order is CMDUDATA first.
Feb 15, 2007
Thanks to Bill Keezer, SAS Institute, USA.
Change 25.006 Support for MXG IMS Log processing for IMS Version 10:
VMACIMS -For users of TYPEIMS7, members VMACIMS and TYPEIMS7 with
TYPEIMS7 this Change 25.006 (in MXG 25.01) are required, and you
ASMIMSL6 must update the _IMSVERS to 10.0 in IMACIMS7 in your
JCLIMSL6 "USERID.IMSV10.SOURCLIB(IMACIMS7)" tailoring.
Feb 19, 2007 -For users of ASMIMSL6,TYPEIMSA,JCLIMSL6 job stream, you
Feb 27, 2007 reassemble ASMIMSL6 with the IBM IMS V10 macro library to
create the "USERID.IMSV10.LOADLIB(MXGIMSL6)" for the
PGM=MXGIMSL6 for your V10 jobstream.
-Because there is no Version number in IMS log records,
separate job streams for each IMS version's log file is
required, so creating V10-only "USERID" and "LOADLIB"
datasets is required, along with associated JCL DSNAME=
changes will, unfortunately, also be required.
Updates were required to support new fields INCOMPATIBLY
that were inserted in IMS log 07 and 08 records, and new
variables are created in IMS0708 and IMSSUMRY datasets.
There is a new CPU metric, DLREXETM, that is documented
as the total CPU time from 08 to 07, but in test data,
it was very close to IMSCPUTM in three BMP transactions
but on BMP that ABENDed had much smaller DLREXETM than
the IMSCPUTM value, so it is somewhat suspect.
Other IMS log records will be validated shortly.
Thanks to Curdin Salis Gross, Credit-Suisse, SWITZERLAND.
Change 25.005 SQLServer:Replication objects now have instance names, so
VMACNTSM KNOWN SORA OBJECT. UNEXPECTED NRDATA message is gone and
Feb 12, 2007 variables SQRSNAME SQRMNAME SQRLNAME SQRDNAME SQRANAME
Feb 19, 2007 are now created. Labels for four cachxxxx were added.
Thanks to Bob Gauthier, Albertsons, USA.
Change 25.004 Change 24.159 added TWOHOUR, FOURHOUR, EIGHTHR arguments
VMXGDUR to VMXGCICI for CICS summarization; those INTERVAL values
VMXGSUM are now also supported in VMXGSUM and VMXGDUR %macros.
Feb 11, 2007
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 25.003 Variable NREXPOSR is INCOMPATIBLY changed by IBM for HPAV
VMAC74 to contain the accumulated product of UCBs and samples in
Feb 8, 2007 SMF74PSM. Now, MXG recalculates for HyperPav using:
IF HYPERPAV='Y' THEN NREXPOSR=NREXPOSR/SMF74PSM;
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Gilles Lachassagne, CA, FRANCE.
Change 25.002 VMACMWUX in MXG 24.24 was restored from the last changed
VMACMWUX member from MXG 22.22; somehow, I replaced MWUX with an
Feb 8, 2007 older and archaic member.
Thanks to Roman Gudz, Penske, USA.
Change 25.001 Correction to NRICFCPU and NRIFLCPU in ASUM70PR/ASUMCEC
VMXG70PR datasets, if you had more than one. The MAX= statement
Feb 8, 2007 in line 295 should have been
SUM=X NRICFCPU NRIFACPU NRIFLCPU NRZIPCPU;
The counts in NRIFACPU and NRZIPCPU were correct because
they are recalculated to be the Average number based on
those engines UP-time, in case IRD takes control
LASTCHANGE: Version 25.