COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 30.30
=========================member=CHANGE30================================
/* COPYRIGHT (C) 1984-2013 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 30.30 was dated Jan 21, 2013, thru Change 30.292.
MXG Newsletter SIXTY-ONE was dated Jan 21, 2013.
MXG Version 30.10 was dated Jan 3, 2013, thru Change 30.274.
MXG Version 30.09 was dated Dec 4, 2012, thru Change 30.253.
First MXG Version 30.09 was dated Dec 3, 2012, thru Change 30.252.
MXG Version 30.08 was dated Nov 7, 2012, thru Change 30.235.
First MXG Version 30.08 was dated Nov 5, 2012, thru Change 30.230.
MXG Version 30.07 was dated Oct 3, 2012, thru Change 30.200.
Second MXG Version 30.07 was dated Oct 2, 2012, thru Change 30.199.
DONTUSE MXG Version 30.07 dated Oct 1, 2012, thru Change 30.198.
MXG Version 30.06 was dated Sep 1, 2012, thru Change 30.177.
Second MXG Version 30.05 was dated Aug 8, 2012, thru Change 30.153.
First MXG Version 30.05 was dated Aug 6, 2012, thru Change 30.151.
MXG Newsletter SIXTY is dated Aug 6, 2012.
MXG Version 30.04 was dated Jul 4, 2012, thru Change 30.124.
First MXG Version 30.04 was dated Jul 2, 2012, thru Change 30.122.
MXG Version 30.03 was dated May 30, 2012, thru Change 30.096.
MXG Version 30.02 was dated Apr 15, 2012, thru Change 30.062.
MXG Version 30.01 was dated Feb 13, 2012, thru Change 30.021.
Annual MXG Version 29.29 was dated Jan 23, 2012, thru Change 29.307.
Instructions for ftp download can be requested by using this form:
http://www.mxg.com/Software_Download_Request
Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 30.30 is available upon request.
II. SAS Version requirement information.
III. WPS Version requirement information.
IV. MXG Version Required for Hardware, Operating System Release, etc.
V. Incompatibilities and Installation of MXG 30.30.
VI. Online Documentation of MXG Software.
VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest
and is updated with new notes frequently. All Newsletters are online
at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.
Member CHANGESS contains all changes that have ever been made to MXG.
All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================
I. MXG Version 30.30 dated Jan 21, 2013, thru Change 30.292.
Major enhancements/corrections added in MXG 30.30, dated Jan 21, 2013:
ANALCOMP 30.286 Graphic comparison of values over time.
TYPE110 30.278 TASZIPTM and TASELGTM documented, TASELGTM corrected.
TYPETMO2 30.277 Support for TMON CICS 3.4 for CICS/TS 5.1 INCOMPAT.
TYPEMVCI 30.276 Support for Mainview CICS 6.5 for TS 5.1 COMPATIBLE.
TYPEBETA 30.285 Support for BETA93 subtype 51.
TYPETAPR 30.284 Support for additional PHYSVOL/VOLUME file fields.
UTILEXCL 30.278 MXGNOTE on log identifies create date of IMACEXCL.
JCLSPLIT 30.287 Examples DECOMPRESS CICS/DB2 on z/OS for ASCII MXG.
UTILEXCL 30.283 Better support for UNKNOWN FIELDS to prevent 180.
READDB2 30.280 MXG 30.10 IFCID=STATS could still fail.
VFMT102 30.279 VFMT102 mapping DBID/OBID/PSID safer algorithm.
MXGNAMES 30.275 MXGNAMES/CONFIMXG supports a USER FORMAT library.
Major enhancements/corrections added in MXG 30.10, dated Jan 3, 2013:
VMXGALOC 30.273 SERIOUS ERROR if MONTH is used with VMXGALOC/UTILBLDP
TYPE7072 30.264 Support for APAR OA39562 new TYPE70Y3 PKCS11 CEX4P.
TYPE99 30.259 Support for SMF 99 Subtype 12 and 14 HiperDispatch.
TYPEVMXA 30.254 Support for zVM new CRYPTO TYPE PRCAPMCT=10.
TYPEVMXA 30.254 Support for zVM new HIS (SMF113) counters, zEC12.
TYPE102 30.265 Support for DB2 Trace IFCIDs 361 and 362 populated.
TYPEIDMS 30.270 Support for IDMS PERFMON Version 17 and 18.
READDB2 30.257 IFCIDS=STATS fixed, use instead of IFCIDS=STATISTICS.
BUILDPDB 30.260 PDB.JOBS variable ABENDS count included some RETURNs.
BLDSMPDB 30.255 WEEKKEEP, WEEKDROP now work as documented.
ASUM70PR 30.266 Variable LFARIFLS added to ASUM70PR datasets.
TYPE113 30.274 Correction to DWINSORM/DWDASORM for one book CEC.
SMFSRCH 30.269 Incorrectly tried to write to USERID.SMFOUT.DATA.
TYPE80A 30.268 RACF317 detect BPX.DEFAULT.USER, invalid in z/OS 2.1.
Major enhancements/corrections added in MXG 30.09, dated Dec 3, 2012:
TYPE120 30.244 Support for WebSphere Version 8 ID=120 Subtype 10.
TYPECIMS 30.245 Support for BMC Mainview IMS 4.6 a/k/a IMF, CIMS.
TYPEEJES 30.238 Support for Phoenix Software (E)JES SMF record.
TYPEBETA 30.237 Support for BETA93/97 Version 4.3.0 (INCOMPATIBLE).
TYPE119 30.249 SMF ID-119 SUBTYPE=51 INPUT STATEMENT EXCEEDED.
TYPEDB2 30.246 DB2STATS QWOSxxxx wrong if ZOSMETRICS=YES not set.
VMXG2DTE 30.242 New CRITERIA= parameter inserts selection SAS code.
ANALDB2R 30.241 Revised mapping of DBID and OBID objects to names.
VFMT102 30.241 Revised mapping of DBID and OBID objects to names.
GRAFDB2B 30.240 Graphic/tabular DB2 Buffer Size reports, ODS or GRAPH
VMXGCOPY 30.243 VMXGCOPY copies SAS datasets from multiple LIBNAMEs.
TYPE113 30.236 Spurious DEACCUMULATION RESET message not printed.
Major enhancements/corrections added in MXG 30.08, dated Nov 7, 2012:
If you downloaded MXG 30.08 dated Nov 5, please refresh with Nov 7:
Change 30.234 is REQUIRED with APAR OA37826 (z/EC12 TYPE74); it was
NOT in MXG 30.08 dated Nov 5. Use only the Nov 7 Version 30.08 if
you have installed that APAR:
TYPE74 30.234 ERROR: INVALID DATA FOR CHAR4, STOPOVER, APAR OA37826
TYPE110 30.228 Support for CICS/TS 5.1 INCOMPATIBLE - 30.08 REQUIRED
TYPEDB2 30.229 Support for DB2 NETEZZA optional data corrections.
TYPE113 30.201 Support for HIS zEC12 new Extended Counters, calcs.
TYPE7072 30.212 Support for zEC12 CRYPTO EXPRESS4S APAR OA37016.
TYPE74 30.209 Support for APAR OA37826 Channel Path Types CIB, CFP.
TYPE70 30.208 Support for APAR OA37803 Warning Track Interrupt.
TYPE74 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE79 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE71 30.206 Support for APAR OA38660 eC12 SCM and Pgbl Large.
TYPE78 30.206 Support for APAR OA38660 TYPE78PA additions.
TYPEDCOL 30.204 Support for APAR OA38980 ZFS dataset flag, FREEs.
ASUMTAPE 30.203 Support for JES3 Main Device Scheduler IAT5210/5918.
ASUMTAPE 30.203 INCOMPATIBLE: PDB.ASUMTAPE SORT ORDER CHANGED.
TYPENMON 30.226 Support for MEMAMS Memory Object, French text.
TYPENDM 30.220 Support for NDM-CD Subtype CX creates NDMCX dataset.
TYPE110 30.213 MXG 30.07 only. CICS STID=30 WARNING message fixed.
TYPEDB2 30.210 DB2 V10 APAR PN29124 detects IBM BIF INCOMPATIBLE.
TYPETPMX 30.216 MVS Solutions Thruput Manager SMF subtype 5 updates.
ASMRMFV 30.202 RMF III Enhancements and Fixes.
TYPERMFV 30.217 Reading RMF III data on ASCII - INVALID date message.
TYPEVMXA 30.215 z/VM BROKE CONTROL record when MONWRITE concatenated.
TYPEDB2 30.211 QISTCOLS now deaccumulated again.
TYPEDB2 30.222 IFCID=239 DB2ACCTP sets DB2PARTY, QPACROLL, QPACRUSM.
VFMT102 30.219 NODUPKEY temp circumvention for overlapped range.
TYPE70 30.233 TYPE70 CPUWAITM incorrect, greater than CPUUPTM
TYPETMS5 30.205 Variable ACTVOL added to TMS.TMS dataset.
ANALDB2R 30.219 Mapping of dBID/OBID values to names revised.
ANALDB2R 30.218 INTERVAL=xxxx wasn't supported, VMXGUM MXGERROR.
VMXGFIND 30.214 VMXGFIND to print all datasets had wrong title.
Many 30.225 New MXGEXIMSG macro variable for diagnostics.
Major enhancements/corrections added in MXG 30.07, dated Oct 3, 2012:
TYPE7072 30.182 Support for zNEXT EC12 processors with 101 engines.
ASMTAPEE 30.193 MXGTMNT Tape Mount Monitor no longer PINs UCBs.
TYPEVMXA 30.192 z/VM Linux Processor VXAPLSL0 dataset wrong values.
TYPEVMXA 30.190 z/VM 6.1 BROKEN CONTROL RECORD if STSI is 152 bytes.
TYPEDB2 30.194 QMDAACCT field LENACCT=246 caused INVALID 3rd SUBSTR.
TYPE119 30.188 Support for SMF 119 subtype 48 thru 52 (SMTP).
ANALDB2R 30.185 Redesign to execute VFMT102 only once per ANALDB2R.
ANALDB2R 30.186 New "MXG" DB2 reports MXGACC01 and MXGACC02.
VFMT102 30.183 30.05/30.06 VFMT102 could have overlapped range.
VMAC113 30.179 Formula changes from John Burg's SHARE presentation.
BLDFORMT 30.191 JCL Example using CONFIMXG to create FORMAT library.
VMXGSUM 30.189 Use of %CMPRES replaced by %SYSFUNC which is in base.
Major enhancements/corrections added in MXG 30.06, dated Sep 1, 2012:
TYPE120 30.155 Support WebSphere Asynchronous Section 120 Subtype 9.
TYPETAPR 30.164 Support for Tandem Prognosis data files.
TYPEZVPS 30.154 Support XAM/ZVPS VCPU Virtual CPU segment XMUSVCPU
TYPE102 30.175 Support for IFCID=271 DB2 AUDIT PERMISSIONS trace.
TYPE102 30.169 Invalid IFCID=145 QWT02R1L=0 caused ABEND & LOOP.
TYPENTSM 30.159 Support MicroSoft Exchange 2010 incompat changes.
TYPENMON 30.137 Updates to NMON/TOPAS Monitor for AIX and LINUX.
UTILEXCL 30.157 New REPORT THREE-A IMACICEZ, IMACICE1, and IMACICE2.
TYPERACF 30.162 RACF AUDITFID is RACF264 (TYPE80A) or AUDITID (RACF)
TYPE120 30.155 Variable SM1209CX incorrect in TYP1209E.
ASUMUOW 30.166 Optional add PROGRAM and PROG1-PROGnn to PDB.ASUMUOW.
TYPEWWW 30.163 Windows IIS Server Log, strange URIQUERY, looped.
TYPENTSM 30.156 Terminal Service object fields reversed, 2003vs2008R.
ASMRMFV 30.161 RMF III protection/messages for VSAM read I/O error.
TYPERMFV 30.172 RMF III Enhancements.
TYPEDB2 30.173 Spurious INVALID QMDA SEGMENT message eliminated.
VMXGINIT 30.171 Macro variables &PCICMNR and &WCICMNR reinstated.
TYPE110 30.170 Obs count in CICLDR reduced from 1.7M to 70,000.
VGETOBS 30.177 SAS 9.2 z/OS ONLY VGETOBS didn't recognize tape dset.
Major enhancements/corrections added in MXG 30.05, dated Aug 8, 2012:
EXITCICS 30.130 DB2 V10 compressed records "enhanced": NOW WORKS!
(And this VERSION 3 DOES NOT NEED CICS MACRO LIBRARY).
ANALDB2R 30.147 DB2 AUDIT reports updated for DB2PM Version 4.2
TYPE102 30.140 Support for IFCID 269,270 Audit, decodes uniques.
TYPEDB2 30.133 Support for (optional) DB2 Netezza Accelerator data.
TYPEDB2 30.138 ASG TMON/DB2 PTF TE03737 corrects INVALID DB2 RECORD.
VGETALOC 30.135 Dynamic allocation of AUTOALOC=YES LIBNAMEs.
VMXGALOC 30.131 New READONLY and CLEARLL parameters.
TYPE21 30.132 Corrections to SMF 21 calculations of compression.
ANALGRID 30.126 Date range selection did not work.
TYPERMFV 30.151 Additional Enhancements for RMF III processing.
Major enhancements/corrections added in MXG 30.04, dated Jul 4, 2012:
UTILEXCL 30.100 DO NOT USE UTILEXCL in MXG 30.03, "NON-FIRST" error.
TYPE30 30.119 Support for APAR OA39629 HICPUPCT/HICPUPGM TYPE30.
TYPEMVCI 30.109 Support for Mainview CICS v64 CICS/TS 4.2 (COMPAT).
TYPETMD2 30.107 Support for ASG/Landmark TMON DB2 PTFs TE03699/03718.
ASMRMFV 30.105 Support for RMF III ASIG3 segments '13'x and '14'x.
TYPE119 30.099 Support for CO:Z SMF 119 Subtypes 192 and 193.
TYPE1415 30.103 Support for z/OS 1.13-added RAS segment (COMPATIBLE).
TYPERACF 30.120 Support for RACF database Record 02G1.
TYPEDB2 30.113 Support for DB2 V10 restructured QIST statistics.
TYPEZPRO 30.116 Support for Voltage SecureData for z/OS z/Protect.
ASUM70PR 30.106 zIIP SHARE WEIGHTS calculated for each LPAR.
TYPEDCOL 30.098 DCOLLECT BKUP fields added by z/OS 1.11 supported.
TYPE70EN 30.104 Variable SMF70CIN in TYPE70EN was 'ZIP', now 'IIP'.
TYPE119 30.121 Additional formats to decode TYPE119 SSH fields.
TRNDRMFI 30.115 Revisions for TRNDRMFI using VGETWKLD.
TYPESASU 30.114 SAS User Records with SASPROC='SQL (63)' protected.
TYPEPMX 30.112 Variables TPMAJCT/TPMSCT too large by 100.
TYPE80A 30.111 Debugging PUT 'DEBUG 1' is now disabled.
TYPEWPMO 30.110 Windows PERFMON data now supports any delimiter.
Major enhancements/corrections added in MXG 30.03, dated May 30, 2012:
ASMRMFV 30.095 Major RMF Enhancements.
ANALID 30.042 SMF AUDIT REPORT - MAJOR ENHANCEMENT - IN BUILDPDB.
TYPEDB2 30.089 Support for DB2 V10 APAR PM24723 adds data IFCID=225.
TYPE105 30.080 Support for GDPS SMF 105 now validated with SMF data.
TYPESAMS 30.073 Support for CA Vantage Stor Resc MGR 12.6.00 INCOMAT.
TYPE74 30.072 Support for RMF 74 APAR OA36831 (COMPAT) SMF74NSS.
TYPECMA 30.070 Support for CA-Spool Subtype 12 (partial).
TYPEFERT 30.066 Support for new subtype 1 and 4 FERRET SMF records.
TYPE115 30.064 Support for MQ QJST 7.01B Statistics Block.
TYPE117 30.063 SMF 117 IMFL subtype SM17ACCT kept in WS 7.0.0.3 SMF.
UTILEXCL 30.092 WMQGETTM, others, incorrectly multiplied by 16.
TYPE60 30.082 INPUT EXCEEDED for ID=60 with no VVR segment.
BLDSMPDB 30.081 Enhancement adds rundays=mon tue ... to list days.
TYPE110 30.078 SMSxxxxx variables were 1024 times large.
READDB2 30.077 Cleanup of WANTONLY, IFCID=STATS, 106, etc.
TYPETPMX 30.075 READTIME kept in all, JOB/JESNR/JBL24 in TPMJBL24
TYPE7072 30.069 New 1.13 CPUPDPTM/R723RTDM/RTDC/RTDT now populated.
DAILYDSN 30.068 DAILYDSN now uses EDGRXEXT instead of EDGRDEXT.
TYPE71 30.083 ERROR: DOMAIN ERROR, SAS 9.1.3 SP4 Only.
Major enhancements/corrections added in MXG 30.02, dated Apr 15, 2012:
BUILDPDB 30.042 SMF AUDIT REPORT
Many 30.012 RUN STATEMENT HAS NO EFFECT message is removed.
READDB2 30.031 Requesting IFCIDS=ACCOUNT with IFCIDS from SMF 102
TYPE0 30.040 Variable DOWNTM was a missing value in PDB.IPLS.
TYPE102 30.037 Support for BMC APPTUNE V6R3 SMF 102 records INCOMPAT
TYPE102 30.038 Support for DB2 IFCIDs 357 and 358.
TYPE102 30.055 Support for DB2 APAR PM37956 to SMF 102 IFCID 25
TYPE110 30.008 CICS/TS 4.2 INVALID STILEN STID=116, zero obs STISJS
TYPE119 30.009 Support for SMF 119 ST 6 z/OS 1.13 (INCOMPAT).
TYPE21 30.014 Support for APAR OA33947 for TS1140 Tape Drive
TYPE71 30.058 New vars added to RMF TYPE71 dataset by z/OS 1.13
TYPE73 30.004 Some FICON-related variables were wrong values.
TYPE73 30.054 ERROR: Zero divide in SMF 73 records, new FICON data.
TYPE85 30.050 Support for SMF 85 records from z/OS 1.13 (INCOMPAT,
TYPEBBMQ 30.047 Support for BMC Mainview for MQ Version 5.1 (INCOMPAT
TYPEBVIR 30.057 Support for TS7700 Version 2.0a (INCOMPATIBLE)
TYPEDB2 30.032 DB2 variable QWHDRQNM can contain an ipv6 address.
TYPEEZSM 30.041 Support for EMC EzSM z/OS Storage Manager SMF record
TYPEHSM 30.006 Support for HSM SMF z/OS 1.12 changes (COMPATIBLE)
TYPEM204 30.002 MODEL 204 records could be output to wrong dataset.
TYPENDM 30.039 NDM-CDI record 'XO' caused "UNKNOWN SUBTYPE" message.
TYPENTSM 30.044 Updates to D062, D063, D060, VWRP, D059, D057, VWVS.
TYPERMFV 30.043 Updates for RMF III RCD records without....
TYPERSDA 30.035 RSD/FOLDERS name fields were increased to $250.
TYPESVIE 30.051 Support for SYSVIEW PTF Test APAR TSD0145, for IMS.
TYPETMD2 30.060 Support for TMON/DB2 V5, INCOMPATIBLE, for DB2 V10.
TYPETMMQ 30.025 Support for TMON for MQ Version 2.2/2.3/2.4 INCOMPAT
TYPEXAM 30.003 Spurious XAM INVALID CPU RECORD messages.
UTILCPLG 30.026 %UTILCPLG will copy your .LOG and .LST files.
VMACSMF 30.023 A third-party product creates invalid DB2 ID=101
VMXGGETM 30.034 VMXGGETM only supported 512 subtypes.
Major enhancements/corrections added in MXG 30.01, dated Feb 13, 2012:
BUIL3005 30.011 MXG 29.29 BUILDPD3 for JES3 CRITICAL ERROR, REQUIRED.
PDB.JOBS incorrectly built with 29.29. JES 3 ONLY.
This change motivated the release of MXG 30.01.
TYPE119 30.009 Support for SMF 119 ST 6 z/OS 1.13 (INCOMPAT).
No execution error, but data in TYP11906 is wrong.
TYPE110 30.008 CICS/TS 4.2 INVALID STILEN STID=116, zero obs STISJS
Possible loss of subsequent statistics subtypes.
TYPE21 30.014 Support for APAR OA33947 for TS1140 Tape Drive
TYPE73 30.004 Some FICON-related variables were wrong values.
TYPE102 30.001 QW0319FL, Encryption Type, format AES/DES reversed.
ANALDB2R 30.007 PMSTA01/PMSTA02 DB2 Statistics, INTERVAL=DATE fixed.
TYPEM204 30.002 MODEL 204 records could be output to wrong dataset.
TYPEHSM 30.006 Support for HSM SMF z/OS 1.12 changes (COMPATIBLE)
Please read CHANGESS for the complete list of major enhancements.
See member NEWSLTRS or the Newsletters frame at http://www.mxg.com for
current MXG Technical Notes.
All of these enhancements are described in the Change Log, below.
II. SAS Version requirement information:
SAS Version 9.3 TS1M1 is RECOMMENDED for all PLATFORMS, because
SAS Version 9.3 TS1M0 REQUIRES THE HOT FIX in SAS NOTE SN43828
(for all platforms), and TS1M1 contains that Hot Fix.
***************************************************************
As documented in Change 27.356, with SAS V9.3):
The standard SAS JCL Procedure can be used for MXG:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
or you can continue to use the MXGSAS93 JCL Procedure example.
***************************************************************
MXG 26.03 thru MXG 30.30 will execute under SAS Version 9.3, on
all supported platforms, but as noted above, you need TS1M1. With
TS1M0, then the Hot Fix in SAS Problem Note SN43828 is REQUIRED to
correct an error in the %MACRO compiler, which is SAS portable
code, so that Hot Fix is required for ALL platforms.
The %MACRO compiler error is in processing %LET statements. While
only two MXG members failed repeatedly in MXG QA tests on z/OS,
there were random %LET errors in ASCII QA tests, so ANY use of
%LET statement on ANY platform are vulnerable to this error, as
the %MACRO compiler is SAS portable code, used on all platforms.
So this is NOT just an MXG error, but impacts ALL SAS programs.
With the Hot Fix on TS1M0, the full MXG QA test stream executed,
and there were no new warnings on z/OS.
Unrelated to the above SAS Note/Hot Fix, ODS users will want to
use MXG 29.06+, because SAS V9.3 did expose incompatibilities in
MXG code for ODS reporting, that were fixed in MXG Version 29.06.
See Changes 29.159 and 29.169.
MXG 26.03 thru MXG 30.30 will execute under SAS V9.2, or with
SAS V9.1.3 with Service Pack 4, on all supported SAS platform.
SAS Hot Fix for SAS Note 37166 is required to use a VIEW with
the MXG EXITCICS/CICSFIUE CICS/DB2 Decompression Infile Exit.
SAS V9.1.3 is NOT supported by SAS on Windows SEVEN platform,
but SAS V9.2 does execute on that platform.
And, only for z/OS 1.10 with SAS V9.1.3 with ANY version of MXG,
the SAS Hot Fix for SN-35332 is REQUIRED (to be completely safe).
Without this Hot Fix, "LIBREF XXXXXXXX IS NOT ASSIGNED" errors
can occur even though //XXXXXXXX DD is a valid SAS Data Library.
This error ONLY occurs with z/OS 1.10 and SAS V9.1.3; it does
NOT occur with SAS V9.2, nor with z/OS 1.9. It can be
circumvented by adding a LIBNAME statement that specifies the
ENGINE name. See the Technical Note in Newsletters for SN-35332.
Note that SAS V9.1.3 is now at "Level B" Support from SAS.
Old MXG code may continue to execute with SAS V8.2, but V8 is now
"Level C" support from SAS Institute, and there are known errors
in V8.2 that are only fixed in SAS V9. I no longer QA with V8.2;
While many MXG programs (accidentally) will still execute under
V8.2, I can not guarantee that all of MXG executes error free.
PLEASE INSTALL V9.2/V9.3, FOR BOTH OF US, TO AVOID FIXED PROBLEMS.
MXG Software has not executed under SAS V6 in many years.
The "PDB" libraries (i.e., SAS data libraries) must be created by
SAS V8 or later, but any of those data libraries can be read or
updated by the SAS Versions that MXG Supports, above.
For SAS Version V9.3:
SAS 93 TS1M1 is RECOMMENDED; for TS1M0, SAS Hot Fix in SAS Note
SN43828 is REQUIRED. See text of Change 29.159.
With SAS 93 TS1M1, (or TS1M0 with that Hot Fix) MXG
Version 26.03 or later execute under SAS V9.3 on all platforms.
SAS Data Libraries created by SAS V8.2, V9.1.3, V9.2 and V9.3
are interchangeable and can be read/written by any of those
versions, provided they are on the same platform.
BUT: on ASCII, the 32-bit and 64-bit SAS versions are NOT the
same "platform" and attempting to read/use the FORMAT catalog
created on one of those "platforms" on the other "platform"
will error out to remind you of that difference!
SAS V9.3 did change ODS processing defaults and syntax that
might cause errors with MXG 29.05 or earlier; MXG 29.06,
Change 29.160 documents the major revisions made in MXG to fully
support V9.3 ODS, and MXG 29.06 is STRONGLY recommended for ODS
with SAS V9.3.
For SAS Version V9.2 (TS1M0):
Big Picture: SAS Version V9.2 is COMPATIBLE with MXG Software.
On z/OS, SAS changed the DSNAMES for some of the SAS libraries,
so you do need to use the new MXGSAS92 JCL Procedure for MXG,
but it still uses the CONFIGV9 configuration file.
****************************************************************
However, NEW, and documented in Change 27.356, with SAS V9.2+:
The standard SAS JCL Procedure can be used for MXG:
// EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
instead of using the MXGSAS92 JCL Procedure example.
****************************************************************
SAS Data Libraries are compatible for V8.2, V9.1.3, and V9.2.
V9.2-created "PDBs" can be read/written by SAS V8.2 or V9.1.3,
and vice versa.
MXG Versions 26.03+ execute with SAS V9.2 with NO (new) WARNINGS
and with NO ERRORS reported.
Pre-MXG 26.03, SAS Hot Fix F9BA07 was required to suppress a
new SAS V9.2 WARNING, that on z/OS, set CC=4 (condition/return
code). That warning is harmless (to MXG code) and all MXG
created SAS datasets were correct, even with that warning.
The ONLY exposure was ONLY on z/OS, and ONLY if condition code
tests are used in your MXG jobstreams.
SAS Version 9.2 requires z/OS 1.7 or later, both officially as
documented by SAS Institute, and actually as V9.2 fails with 0C4
under z/OS 1.4.
For SAS V9.1.3 on z/OS with Service Pack 4:
On z/OS 1.10, Hot Fix SN-35332 is REQUIRED.
CONFIGV9 now specifies V9SEQ instead of V6SEQ. As V6SEQ does
not support long length character variables, it can't be used.
SAS V9.1.3 with current Service Pack 4 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with tape engines V7SEQ, V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are back at SAS V9.1 or V9.1.2
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 (or later) was required
as an absolute minimum level when that SAS Version was last
supported by MXG Software. PLEASE INSTALL SAS V9.x ASAP.
Sequential Engine Status:
V9SEQ was fixed in V9.1.3; it has been default in CONFIGV9.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
V6SEQ, if used under V9.1.2, requires SN-013514, but V6SEQ
should no longer be used, as it does not support long
length variables.
MXG QA tests are executed on z/OS with SAS V9.1.3 and V9.2 and
on Windows XP with 32-bit INTEL, and on Windows Seven Ultimate
32-bit and 64-bit OS on 64-bit hardware, but MXG is installed
on many more hardware and software platforms: since they all work,
we don't need to list them. If SAS executes so does MXG.
Prior QA tests have been run with all SAS releases available at
that time on Linux RH8 on Intel, on Solaris v2.8 on a Model V880,
and on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V9.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
III. WPS Version requirement information:
WPS Version 2.4 requires MXG 27.09 (see Change 27.239).
WPS Version 2.3.5 required MXG 27.05.
See NEWSLETTERS for "MXG Support for WPS Software"
IV. MXG Version Required for Hardware, Operating System Release, etc.
Availability dates for the IBM products and MXG version required for
error-free processing of that product's data records:
Product's
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990 8.8
MVS/ESA 4.2 Mar 29, 1991 9.9
MVS/ESA 4.2.2 Aug 15, 1991 9.9
MVS/ESA 4.3 Mar 23, 1993 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30, 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28, 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28, 1997 15.02
OS/390 2.4.0 Sep 28, 1997 15.06
OS/390 2.5.0 Feb 24, 1998 15.06
OS/390 2.6.0 Sep 24, 1998 16.04
OS/390 2.7.0 Mar 26, 1999 16.09
OS/390 2.7.0 APAR OW41318 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 *24.10
z/OS IRD TYPE70PR Mar 11, 2004 *24.10
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 *24.10
z/OS 1.7 (SPLIT70 CORRECTION) Sep 30, 2005 *24.10
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03
z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06
z/OS More than 32 LPARs Jan 30, 2006 *24.24
z/OS SPLIT RMF 70 records Jan 30, 2006 *24.24
z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02
z/OS IRD errors corrected May 15, 2006 24.03
z/OS ASUMCEC errors corrected May 15, 2006 *24.24
z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24
z/OS zIIP Processor Support Jun 22, 2006 *24.24
z/OS Dedicated zIIP Support Mar 8, 2008 *26.01
z/OS Dedicated zAAP Support Mar 8, 2008 26.01
z/OS 1.8 (COMPATIBLE CHANGES) Sep 20, 2006 *24.24
z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 2007 25.10
z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 2007 25.10
z/OS new z10 variables Mar 5, 2008 26.01
z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 2008 26.07
z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10
z/OS 1.10 RMF III, SMF 119 Jul 20, 2009 27.05
z/OS 1.11 Sep 2, 2009 27.08
z/OS 1.11 New 30 variables Apr 14, 2010 *28.02
z/OS 1.12 Aug 17, 2010 *28.05
z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03
z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06
z/OS 1.13 Sep 30, 2011 29.03
z/OS 1.13 - MXGTMNT only Dec 15, 2011 29.08
z/OS 1.13 SMF 119 ST 6 INCOMPAT Feb 7, 2012 30.01
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24
z9EC CPUs - CPUTYPE '2094'x:
with 64-bit z/OS - no change required *24.24
with 32-bit z/OS only: Aug 26, 2006 24.06
z9BC CPUs - CPUTYPE '2096'x:
with 64-bit z/OS - no change required 24.01
with 32-bit z/OS only: Jul 27, 2006 *24.24
z10 CPUs - CPUTYPE '2097'x Dec 7, 2008 25.11
z10 HiperDispatch/Parked Time Mar 3, 2008 *26.10
z196 (INCOMPAT IF GT 64 ENG) Aug 17, 2010 28.05
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS V2R2 CICS/TS 2.2 Feb 9, 2002 19.19
CICS-TS V2R3 CICS/TS 2.3 Aug 13, 2004 22.04
CICS-TS V3R1 CICS/TS 3.1 Jan 18, 2005 22.22
CICS-TS V3R2 CICS/TS 3.2 Dec 6, 2007 25.11
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
CICS-TS for Z/OS Version 3.2 Jun 29, 2007 25.03
CICS-TS/3.2 Compressed Records Nov 3, 2007 25.11
CICS-TS/4.1 (CICSTRAN INCOMPAT) Mar 13, 2009 27.01
CICS-TS/4.1 (STATISTICS ST=2) Sep 18, 2009 27.08
CICS-TS/4.2 CICSTRAN/STATISTICS Jun 24, 2011 29.03
CICS-TS/4.2 CICSRDS MNSEGCL=5 Jun 24, 2011 29.05*
CICS-TS/4.2 INVALID STID=116 Jan 31, 2012 30.01*
CICS-TS/5.1 (INCOMPATIBLE) Dec 14, 2012 30.08
CICS-TS/5.1 for valid TASZIP/ELG Jan 21, 2013 30.30
DB2 2.3.0 Oct 28, 1991 10.01
DB2 3.1.0 Dec 17, 1993 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 1997 15.02
DB2 6.1.0 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
DB2 8.1 with all zIIP Variables Sep 30, 2006 24.08
DB2 8.1 +PK47659 Sep 12, 2008 26.08
DB2 9.1 See Change 25.265. Dec 7, 2007 25.11
DB2 9.1 Full Support +PK/56356 Sep 12, 2008 26.08
DB2 10.1 Tolerate Oct 1, 2010 28.06
DB2 10.1 Full plus Compressed. Nov 1, 2010 28.07*
DB2 10.1 Invalid Header pre APAR Jan 12, 2011 28.28*
DB2 10.1 IFCID=225 INCOMPAT Sep 23, 2011 29.07*
DB2 10.1 QWHCCV for QWHCATYP=8 Oct 3, 2011 30.07*
DB2 10.1 DBID/OBID decode Jan 21, 2013 30.30*
DFSMS/MVS 1.1 Mar 13, 1993 11.11
DFSMS/MVS 1.2 Jun 24, 1994 12.02
DFSMS/MVS 1.3 Dec 29, 1995 13.09
DFSMS/MVS 1.4 Sep 28, 1997 15.04
DFSMS/MVS 1.4 HSM Sep 23, 1998 16.04
DFSMS/MVS 1.5 ??? ??, 1999 16.04
DFSORT SMF V1R5 Mar 1, 2006 24.02
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
MQ Series 2.1.0 Oct 2, 1999 17.07
MQ Series 5.2 Dec 16, 2000 18.10
MQ Series 5.3 Dec 16, 2002 21.05
MQ Series 6.0 Feb 14, 2006 23.23
Webshpere MQ Series 7.0 ??? ??, 2009 *28.06
Websphere MQ Series 7.1 MAR 12, 2011 29.03
Websphere MQ Series 8.0 Jun 24, 2011 29.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
WebSphere 7.0 Oct 7, 2010 28.06
WebSphere 8.0 Jul 17, 2011 29.05
DOS/VSE POWER V6.3.0 Dec 19, 1998 16.08
VM/ESA 2.0 Dec 23, 1992 10.04
VM/ESA 2.1 Jun 27, 1993 12.02
VM/ESA 2.2 Nov 22, 1994 12.06
VM/ESA 2.3 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
z/VM 5.2 Jan 22, 2006 24.01
z/VM 5.3 TOLERATE Jun 7, 2007 25.05
z/VM 5.3 NEW VARIABLES Sep 12, 2008 26.08
z/VM 5.4 (COMPATIBLE) Sep 12, 2008 27.01*
z/VM 6.1 (NO CHANGES) Jul 7, 2008 27.01
z/VM 6.2 Dec 2, 2011 29.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 Mar 96, 2004 26.01*
IMS log 10.0 Mar 06, 2007 26.01*
IMS log 11.0 Apr 1, 2010 28.02*
IMS log 12.0 Jan 23, 2012 29.29*
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
AS400 4.4.0 Sep 27, 1999 17.07
AS400 4.5.0 Jul 27, 2000 18.07
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
AS400 5.4.0 Aug 26, 2006 24.06
AS400 6.1.0 Jun 29, 2008 26.05
Note: Asterisk by the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's data records.
Or a coding error in MXG could be the reason for the change!
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
NTSMF Version 2.3 17.10
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
NTSMF 3.1.4 Mar 15, 2009 27.01
NTSMF 4.0 Mar 15, 2011 29.03
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 DB2 Version 5.0 30.02
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for CICS/ESA 2.0 - 15.06
The Monitor for CICS TCE 2.1 - 20.04
The Monitor for CICS TCE 2.2 - 20.335, 21.134 21.04
The Monitor for CICS TCE 2.3 including CICS/TS 3.1 22.08
The Monitor for CICS TCE 3.2 (almost all) 25.11
The Monitor for CICS TCE 3.2 (almost all) 27.01
The Monitor for CICS TCE 3.3 (for CICS/TS 4.1,4.2) 29.07
The Monitor for CICS TCE 3.4 (for CICS/TS 5.1) 30.30
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
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
APPTUNE V6R3 SMF 102 30.037
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1+) 16.04
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 26.02*
IMF 4.4 (for IMS 9.1) 27.07*
IMF 4.5 (for IMS 11.1) (No change since 4.4) 27.07
IMF 4.6 a/k/a Mainview IMS 30.09
Mainview for MQ Version 4.4 29.03
Mainview for MQ Version 5.1 30.02
Mainview for CICS Version 6.5 (CICS/TS 5.1) 30.30
Mainview for CICS Version 6.4 (CICS/TS 4.2) 30.04
Mainview for CICS Version 6.1 26.26
Mainview Auto Operator data file 28.28
Mainview for DB2 THRDHIST file 20.20
Mainview for TCP/IP 20.20
Mainview for Batch Optimizer 19.19
Memorex/Telex
LMS 3.1 12.12A
Oracle V9, V10 24.06
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
XAMAP 3406 24.03
XAMAP 3.7 27.10
XAMAP 4.1 Now Renamed to ZVPS 4.1 29.07
V. Incompatibilities and Installation of MXG 30.30.
1. Incompatibilities introduced in MXG 30.30:
a- Changes in MXG architecture made between 30.30 and prior versions
that can introduce known incompatibilities.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTT for
SAS Version 9.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
COMPAT the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
VI. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
VII. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes in MXG 30.30 after MXG 29.29:
Dataset/
Member Change Description
ANALCOMP 30.286 Graphic comparison of values over time.
ANALDB2R 30.007 PMSTA01/PMSTA02 DB2 Statistics, INTERVAL=DATE fixed.
ANALDB2R 30.147 DB2 AUDIT reports updated for DB2PM Version 4.2
ANALDB2R 30.176 New AUDIT= parms, PMACC02 standalone error fixed.
ANALDB2R 30.185 Redesign to execute VFMT102 only once per ANALDB2R.
ANALDB2R 30.186 New "MXG" DB2 reports MXGACC01 and MXGACC02.
ANALDB2R 30.218 INTERVAL=xxxx wasn't supported, VMXGUM MXGERROR.
ANALDB2R 30.219 Mapping of dBID/OBID values to names revised.
ANALDB2R 30.241 Revised mapping of DBID and OBID objects to names.
ANALGRID 30.126 Date range selection did not work.
ANALID 30.042 SMF AUDIT REPORT - MAJOR ENHANCEMENT - IN BUILDPDB.
ASMDBLKU 30.168 Enhancement to ASM program that recreates VB & VBS.
ASMRMFV 30.105 Support for RMF III ASIG3 segments '13'x and '14'x.
ASMRMFV 30.161 RMF III protection/messages for VSAM read I/O error.
ASMRMFV 30.202 RMF III Enhancements and Fixes.
ASMTAPEE 30.193 MXGTMNT Tape Mount Monitor no longer PINs UCBs.
ASUM70PR 30.106 zIIP SHARE WEIGHTS calculated for each LPAR.
ASUM70PR 30.266 LPARIFLS variable counts IFL engines in each LPAR.
ASUM70PR 30.266 Variable LFARIFLS added to ASUM70PR datasets.
ASUMDBSS 30.282 Revised comments and examples.
ASUMTAPE 30.203 Support for JES3 Main Device Scheduler IAT5210/5918.
ASUMUOW 30.166 Optional add PROGRAM and PROG1-PROGnn to PDB.ASUMUOW.
BLDFORMT 30.191 JCL Example using CONFIMXG to create FORMAT library.
BLDSMPDB 30.005 Using MXGINCL parameter was ignored.
BLDSMPDB 30.081 Enhancement adds rundays=mon tue ... to list days.
BLDSMPDB 30.255 WEEKKEEP, WEEKDROP now work as documented.
BUIL3005 30.011 MXG 29.29 BUILDPD3 for JES3 CRITICAL ERROR, REQUIRED.
BUILDPDB 30.042 SMF AUDIT REPORT
BUILDPDB 30.260 PDB.JOBS variable ABENDS included some RETURNs.
DAILYDSN 30.068 DAILYDSN now uses EDGRXEXT instead of EDGRDEXT.
EXITCICS 30.130 DB2 V10 compressed record SUPPORT - "enhanced"-works!
FORMATS 30.024 New format MG073FE decodes SMF73GEN and R79CGEN FICON
GRAFDB2B 30.240 Graphic/tabular DB2 Buffer Size reports, ODS or GRAPH
JCLSPLIT 30.287 Examples DECOMPRESS CICS/DB2 on z/OS for ASCII MXG.
MXGNAMES 30.275 MXGNAMES/CONFIMXG supports a USER FORMAT library.
Many 30.012 RUN STATEMENT HAS NO EFFECT message is removed.
Many 30.225 New MXGEXIMSG macro variable for diagnostics.
READDB2 30.031 Requesting IFCIDS=ACCOUNT with IFCIDS from SMF 102.
READDB2 30.077 Cleanup of WANTONLY, IFCID=STATS, 106, etc.
READDB2 30.144 PDBOUT with specific IFCIDS did not copy T102Sxxx.
READDB2 30.257 IFCIDS=STATS fixed, use instead of IFCIDS=STATISTICS.
READDB2 30.280 MXG 30.10 IFCID=STATS could still fail.
SMFSRCH 30.269 Incorrectly tried to write to USERID.SMFOUT.DATA.
TRNDRMFI 30.115 Revisions for TRNDRMFI using VGETWKLD.
TYPE0 30.040 -Variable DOWNTM was a missing value in PDB.IPLS.
TYPE102 30.001 QW0319FL, Encryption Type, format AES/DES reversed.
TYPE102 30.037 Support for BMC APPTUNE V6R3 SMF 102 records INCOMPAT
TYPE102 30.038 Support for DB2 IFCIDs 357 and 358.
TYPE102 30.055 -Support for DB2 APAR PM37956 to SMF 102 IFCID 25.
TYPE102 30.140 Support for IFCID 269,270 Audit, decodes uniques.
TYPE102 30.169 Invalid IFCID=145 QWT02R1L=0 caused ABEND & LOOP.
TYPE102 30.175 Support for IFCID=271 DB2 AUDIT PERMISSIONS trace.
TYPE102 30.265 Support for DB2 Trace IFCIDs 361 and 362 populated.
TYPE105 30.080 Support for GDPS SMF 105 now validated with SMF data.
TYPE110 30.008 CICS/TS 4.2 INVALID STILEN STID=116, zero obs STISJS.
TYPE110 30.078 SMSxxxxx variables were 1024 times large.
TYPE110 30.170 Obs count in CICLDR reduced from 1.7M to 70,000.
TYPE110 30.213 MXG 30.07 only. CICS STID=30 WARNING message.
TYPE110 30.278 TASZIPTM and TASELGTM documented, TASELGTM corrected.
TYPE113 30.179 Formula changes from John Burg's SHARE presentation.
TYPE113 30.201 Support for HIS zEC12 new Extended Counters, calcs.
TYPE113 30.236 Spurious DEACCUMULATION RESET message not printed.
TYPE113 30.274 Correction to DWINSORM/DWDASORM for one book CEC.
TYPE115 30.064 Support for MQ QJST 7.01B Statistics Block.
TYPE117 30.063 SMF 117 IMFL subtype SM17ACCT kept in WS 7.0.0.3 SMF.
TYPE119 30.009 Support for SMF 119 ST 6 z/OS 1.13 (INCOMPAT).
TYPE119 30.099 Support for CO:Z SMF 119 Subtypes 192 and 193.
TYPE119 30.121 Additional formats to decode TYPE119 SSH fields.
TYPE119 30.188 Support for SMF 119 subtype 48 thru 52 (SMTP).
TYPE119 30.249 SMF ID-119 SUBTYPE=51 INPUT STATEMENT EXCEEDED.
TYPE120 30.155 Support WebSphere Asynchronous Section 120 Subtype 9.
TYPE120 30.155 Variable SM1209CX incorrect in TYP1209E.
TYPE120 30.244 Support for WebSphere Version 8 ID=120 Subtype 10.
TYPE1415 30.103 Support for z/OS 1.13-added RAS segment (COMPATIBLE).
TYPE21 30.014 Support for APAR OA33947 for TS1140 Tape Drive.
TYPE21 30.132 Corrections to SMF 21 calculations of compression.
TYPE30 30.045 Debugging PUT _N_= CPUUNITS= CPUTCBTM= removed.
TYPE30 30.119 Support for APAR OA39629 HICPUPCT/HICPUPGM TYPE30.
TYPE60 30.082 INPUT EXCEEDED for ID=60 with no VVR segment.
TYPE70 30.208 Support for APAR OA37803 Warning Track Interrupt.
TYPE7072 30.069 New 1.13 CPUPDPTM/R723RTDM/RTDC/RTDT now populated.
TYPE7072 30.182 Support for zNEXT EC12 processors with 101 engines.
TYPE7072 30.212 Support for eC12 CRYPTO EXPRESS4S APAR OA37016.
TYPE7072 30.264 Support for APAR OA39562 new TYPE70Y3 PKCS11 CEX4P.
TYPE70EN 30.104 Variable SMF70CIN in TYPE70EN was 'ZIP', now 'IIP'.
TYPE71 30.058 -New variables added to RMF TYPE71 dataset by z/OS 1.1
TYPE71 30.083 ERROR: DOMAIN ERROR, SAS 9.1.3 SP4 Only.
TYPE71 30.206 Support for APAR OA38660 eC12 SCM and Pgbl Large.
TYPE73 30.004 Some FICON-related variables were wrong values.
TYPE73 30.054 -ERROR: Divide by zero in SMF 73 records, new FICON
TYPE74 30.072 Support for RMF 74 APAR OA36831 (COMPAT) SMF74NSS.
TYPE74 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE74 30.209 Support for APAR OA37826 Channel Path Types CIB, CFP.
TYPE79 30.207 Support for APAR OA39993 Interrupt Delay Time
TYPE80A 30.111 Debugging PUT 'DEBUG 1' is now disabled.
TYPE80A 30.268 RACF317 detect BPX.DEFAULT.USER, invalid in z/OS 2.1.
TYPE85 30.050 Support for SMF 85 records from z/OS 1.13 (INCOMPAT)
TYPE99 30.259 Support for SMF 99 Subtype 12 and 14 HiperDispatch.
TYPEBBMQ 30.047 Support for BMC Mainview for MQ Version 5.1 INCOMPAT
TYPEBETA 30.237 Support for BETA93/97 Version 4.3.0 (INCOMPATIBLE).
TYPEBETA 30.285 Support for BETA93 subtype 51.
TYPEBVIR 30.057 Support for TS7700 Version 2.0a (INCOMPATIBLE).
TYPECIMS 30.245 Support for BMC Mainview IMS 4.6 a/k/a IMF, CIMS.
TYPECMA 30.070 Support for CA-Spool Subtype 12 (partial).
TYPEDB2 30.032 DB2 variable QWHDRQNM can now contain an ipv6 address
TYPEDB2 30.089 Support for DB2 V10 APAR PM24723 adds data IFCID=225.
TYPEDB2 30.113 Support for DB2 V10 restructured QIST statistics.
TYPEDB2 30.128 DB2 v10 QPACFLGS bit map revisions.
TYPEDB2 30.133 Support for (optional) DB2 Netezza Accelerator data.
TYPEDB2 30.138 ASG TMON/DB2 PTF TE03737 corrects INVALID DB2 RECORD.
TYPEDB2 30.145 Variables CORRNAME/CORRNUM incorrect for QWHCATYP=4.
TYPEDB2 30.173 Spurious INVALID QMDA SEGMENT message eliminated.
TYPEDB2 30.194 QMDAACCT field LENACCT=246 caused INVALID 3rd SUBSTR.
TYPEDB2 30.210 DB2 V10 APAR PN29124 detects IBM BIF INCOMPATIBLE.
TYPEDB2 30.211 QISTCOLS now deaccumulated again.
TYPEDB2 30.222 IFCID=239 DB2ACCTP sets DB2PARTY, QPACROLL, QPACRUSM.
TYPEDB2 30.246 DB2STATS QWOSxxxx wrong if ZOSMETRICS=YES not set.
TYPEDCOL 30.098 DCOLLECT BKUP fields added by z/OS 1.11 supported.
TYPEDCOL 30.204 Support for APAR OA38980 ZFS dataset flag, FREEs.
TYPEEJES 30.238 Support for Phoenix Software (E)JES SMF record.
TYPEEZSM 30.041 Support for EMC EzSM z/OS Storage Manager SMF record.
TYPEFERT 30.066 Support for new subtype 1 and 4 FERRET SMF records.
TYPEHSM 30.006 Support for HSM SMF z/OS 1.12 changes (COMPATIBLE)
TYPEIDMS 30.270 Corrections for IDMS PERFMON Version 17 and 18.
TYPEM204 30.002 MODEL 204 records could be output to wrong dataset.
TYPEMVCI 30.109 Support for Mainview CICS v64 CICS/TS 4.2 (COMPAT).
TYPEMVCI 30.276 Support for Mainview CICS 6.5 for TS 5.1 COMPATIBLE.
TYPENDM 30.039 NDM-CDI record 'XO' caused "UNKNOWN SUBTYPE" message.
TYPENDM 30.220 Support for NDM-CD Subtype CX creates NDMCX dataset.
TYPENMON 30.137 Updates to NMON/TOPAS Monitor for AIX and LINUX.
TYPENMON 30.226 Support for MEMAMS Memory Object, French text.
TYPENTSM 30.044 -Updates to D062, D063, D060, VWRP, D059, D057, VWVS.
TYPENTSM 30.156 Terminal Service object fields reversed, 2003vs2008R.
TYPENTSM 30.159 Support MicroSoft Exchange 2010 incompat changes.
TYPEPMX 30.112 Variables TPMAJCT/TPMSCT too large by 100.
TYPERACF 30.120 Support for RACF database Record 02G1.
TYPERACF 30.162 RACF AUDITFID is RACF264 (TYPE80A) or AUDITID (RACF)
TYPERMFV 30.043 Updates for RMF III RCD records.
TYPERMFV 30.151 Additional Enhancements for RMF III processing.
TYPERMFV 30.172 RMF III Enhancements.
TYPERMFV 30.217 Reading RMF III data on ASCII - INVALID date message.
TYPERSDA 30.035 RSD/FOLDERS name fields were increased to $250.
TYPESAMS 30.073 Support for CA Vantage Stor Resc MGR 12.6.00 INCOMAT.
TYPESASU 30.114 SAS User Records with SASPROC='SQL (63)' protected.
TYPESVIE 30.051 Support for SYSVIEW PTF Test APAR TSD0145, for IMS.
TYPETAPR 30.164 Support for six Tandem Prognosis data files.
TYPETAPR 30.284 Support for additional PHYSVOL/VOLUME file fields.
TYPETMD2 30.060 Support for TMON/DB2 V5, INCOMPATIBLE, for DB2 V10/
TYPETMD2 30.107 Support for ASG/Landmark TMON DB2 PTFs TE03699/03718.
TYPETMMQ 30.025 Support for TMON for MQ Version 2.2/2.3/2.4 INCOMPAT
TYPETMO2 30.277 Support for TMON CICS 3.4 for CICS/TS 5.1 INCOMPAT.
TYPETMS5 30.205 Variable ACTVOL added to TMS.TMS dataset.
TYPETPMX 30.075 READTIME kept in all, JOB/JESNR/JBL24 in TPMJBL24
TYPETPMX 30.216 MVS Solutions Thruput Manager SMF subtype 5 updates.
TYPEVMXA 30.190 z/VM 6.1 BROKEN CONTROL RECORD if STSI is 152 bytes.
TYPEVMXA 30.192 z/VM Linux Processor VXAPLSL0 dataset wrong values.
TYPEVMXA 30.215 z/VM BROKE CONTROL record when MONWRITE concatenated.
TYPEVMXA 30.254 Support for zVM new CRYPTO TYPE PRCAPMCT=10.
TYPEVMXA 30.254 Support for zVM new HIS (SMF113) counters, zEC12.
TYPEWPMO 30.110 Windows PERFMON data now supports any delimiter.
TYPEWWW 30.163 Windows IIS Server Log, strange URIQUERY, looped.
TYPEXAM 30.003 Spurious XAM INVALID CPU RECORD messages.
TYPEZPRO 30.116 Support for Voltage SecureData for z/OS z/Protect.
TYPEZVPS 30.154 Support XAM/ZVPS VCPU Virtual CPU segment XMUSVCPU
VMXGCOPY 30.243 VMXGCOPY copies SAS datasets from multiple LIBNAMEs.
UTILCPLG 30.026 %UTILCPLG will copy your .LOG and .LST files.
UTILEXCL 30.092 WMQGETTM, others, incorrectly multiplied by 16.
UTILEXCL 30.100 DO NOT USE UTILEXCL in MXG 30.03, "NON-FIRST" error.
UTILEXCL 30.157 REPORT THREE-A IMACICEZ, IMACICE1, and IMACICE2.
UTILEXCL 30.278 MXGNOTE on log identifies create date of IMACEXCL.
UTILEXCL 30.283 Better support for UNKNOWN FIELDS to prevent 180.
VFMT102 30.183 30.05/30.06 VFMT102 could have overlapped range.
VFMT102 30.241 Revised mapping of DBID and OBID objects to names.
VFMT102 30.279 VFMT102 mapping DBID/OBID/PSID safer algorithm.
VGETALOC 30.135 Dynamic allocation of AUTOALOC=YES LIBNAMEs.
VGETOBS 30.177 SAS 9.2 z/OS ONLY VGETOBS didn't recognize tape dset.
VMACSMF 30.023 A third-party product creates invalid DB2 ID=101.
VMXG2DTE 30.242 New CRITERIA= parameter inserts selection SAS code.
VMXGALOC 30.131 New READONLY and CLEARLL parameters.
VMXGALOC 30.273 SERIOUS ERROR if MONTH is used with VMXGALOC/UTILBLDP
VMXGFIND 30.214 VMXGFIND to print all datasets had wrong title.
VMXGGETM 30.034 VMXGGETM only supported 512 subtypes.
VMXGINIT 30.148 FIXORDER dataset only created for dynamic allocate.
VMXGINIT 30.171 Macro variables &PCICMNR and &WCICMNR reinstated.
VMXGSUM 30.189 Use of %CMPRES replaced by %SYSFUNC which is in base.
See member CHANGESS for all changes ever made to MXG Software.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 30.
====== Changes thru 30.292 were in MXG 30.30 dated Jan 21, 2013=========
Change 30.292 -JCL Proc Examples and Config members were added/aligned.
CONFIGN9 JCL Proc Examples MXGSAS92 and MXGSAS93 invoke CONFIGV9,
CONFIG9N which has set option NLSCOMPATMODE for many years, but
CONFIGV9 now, SAS prints a warning when that option is enabled:
Jan 19, 2013 WARNING: SAS HAS BEEN STARTED IN NLS COMPATIBILITY MODE
Feb 18, 2013 NLSCOMPATMODE OPTION MAY BE DEPRECATED. ETC.
CONTACT YOUR SAS ADMMINISTRATOR. ETC.
-Instead of MXGSASxx JCL PROC, using MXGNAMES/CONFIMXG in
Change 27.356 has been the MXG JCL recommendation since
that change, as it executes the site's SAS JCL procedure
and uses the site's default options, and it does not
print that warning message. But MXGNAMES/CONFIG text
must be used around // EXEC SAS in every MXG Job's JCL.
-So you may still have to EDIT the MXGSAS92/MXGSAS93 JCL
Proclib members to use the desired CONFIGxx member:
CONFIGV9 which sets NLSCOMPATMODE, unchanged.
CONFIGN9 which doesn't set that option, new in 30.30.
CONFIG9N which sets NONLSCOMPATMODE, new in 31.01.
-So why set NONLSCOMPATMODE? Because SAS V9.2 ABENDED
underscoring CALL SYMPUT$ text that is CALL SYMPUT( in
code (deep inside VMXGSUM deep inside VMXGRMFI) and SAS
Technical Support identified the error as documented in
SAS Note 37974 (for SAS V9.2 only) which documents:
"NLSCOMPATMODE causes some CALL routines to generate
errors on MVS in some non-English environments. To
reproduce the error invoke SAS using the command below
and submit the statements that follow it.
===> THE EXAMPLE IS A CALL SYMPUT <===
Currently the only fix for this is to issue the option
NONLSCOMPATMODE"
So the new CONFIG9N member exists to set that option if
you encounter this error. The failure occurred at a site
which had specified default values of:
NLSCOMPATMODE
LOCALE=EN_GB
and all NLS issues to date impacted only sites outside
the US that do not have LOCALE=EN_US.
Change 30.291 VPS Subsystem SMF ID=6 NOTE: INVALID ARGUMENT INPUT FUNCT
VMAC6 because SMF6RST/SMF6RSD contain 'C540404000000000'x which
Jan 18, 2013 isn't a valid SMFSTAMP8 value (time and julian date).
The error message and the hex dump of the SMF record is
now prevented by adding the double question mark to the
informat side of the INPUT function in VMAC6. The value
in variable READTIME in TYPE6 and PDB.PRINT datasets will
be a missing value until a fix is available from VPS.
This text will be update when that happens. Discovered
late on Friday, too late for VPS response for MXG 30.30.
Thanks to William M. Orrach, LMCo, USA.
Change 30.290A Variable LSPRWKLD='LSPR*WORKLOAD*MATCH' created and kept
ASUM113 in ASUM113 dataset.
Jan 16, 2013
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 30.290 Corrections after ITRM review for MXG 30.30:
VMAC90 -VMAC90 variable DOWNTM and IPLTIME labeled and formatted.
VMAC119 -VMAC119 TYP11997 variable SSH_FCRIPV6 kept in place of
VMACVMXA incorrectly spelled/kept SSH_FSRIPV6.
VMACBETA -VMACVMXA STOLMODE is labeled.
ASUMTAPE -VMACBETA Dataset Labels clarified for BETA7, BETA8 and
ASUM113 BETA22. Variable BETARTIME is now the datetime value with
Jan 16, 2013 BETARDATE no longer kept in BETA51 dataset.
-ASUMTAPE Temporary dataset JES3MNTS is now deleted.
-VMAC99 Variable S99CCCCECUTIL label, asterisk removed.
-ASUM113 Variables SMF70CIN/CIX/CPA/HDM/ONT/PAT/CECSER
CPUTYPE LPARWLMG are labeld, PAT and ONT formatted.
Thanks to Chris Weston, SAS ITRM, USA.
Change 30.289 -RMF III Performance Enhancements, blocking, and Fixes
ASMRMFV -INCOMPATIBLE. ASMRMFV & VMACRMFV should always be used
EXZRBUWX from the same MXG Version. Using a new VMACRMFV to read
IMACRMFV data created by an old ASMRMFV may not work. Specifically
JCLCRMFV with this change, to populate the new variables in the
JCLRMFV UWD files, you must use ASMRMFV and VMACRMFV with 30.289.
VMACRMFV See MXG SOURCLIB member JCLASM3 for the example JCL to
VMXGINIT assemble and link-edit the ASMRMFV program. Skipping this
Jan 20, 2013 action will result in many missing UWD file variables and
is not recommended.
-The SHD (Sample Header), RED (Resource Data), and UWD
(USE/WAIT) RMF III tables are now blocked in the RMFBSAM
output file by ASMRMFV for improved I/O performance.
-UWD records are now extended with related data based on
type to make them useful. In the past these records had
no identification of the address space, device, nor the
enqueue that related to the USE/WAIT counts. The table
name now displays as UWDX in ASMRMFV output.
-VMACRMFV has been changed to support these new blocked
tables and the new UWD extended data.
-NOTE: VMACRMFV will no longer accept old unblocked UWD
records. If found, these are deleted and an MXGERROR
message issued once. Processing continues. The old
records had no information to show which address space
the USE/WAIT record was for and so had no practical
value.
-There is a new ZRBUWXCF dataset for UWD type X'0A' XCF
Message entries that includes new variables:
UWDXCDEV='DEV NUM*OF PATH*W MSG PENDING'
UWDXCMAS='ASID OF*MEMBER*SENDING*MSG'
UWDXCHAS='ASID THAT*INITIATED*MSG OUT'
-Validation of UWD entry flags and entry types is
improved. The UWD entry will be skipped for invalid data
and no Abend will occur.
-All ZRBUW* files include the following new variables:
UWDDELAY='DELAY*SAMPLES'
UWDREDID='PARENT*RED ID'
UWDSSN ='UWD*SAMPLE*SEQUENCE*NUMBER'
UWDUSING='USING*SAMPLES'
UWDUWDLE='UWD*BASE*LENGTH'
UWDUWDLX='UWD*EXTENDED*LENGTH'
UWDVERG3='UWD*VERSION*NUMBER'
-All ZRBUW* files now have the following address space
variables from the related ASI table entry added:
ASIENIDX ASIJOBNA ASIASINR ASIFLAG1 ASIJCLAS ASIJOBS
ASIJESID ASIMSTS TYPETASK
-ZRBUWDEV, ZRBUWSTO, and ZRBUWMNT files now have the
following variables from the related DVT table entry
added:
DVTVOLI DVTENIDX DVTDEVNR DVTFLAG1 DVTFLAG2 DVTMEXN
DVTTYP DVTIDEN DVTCUID DVTLCUNR DVTFLAG3 DVTHPCO
DEVTYPE DEVPLPA DEVCOMM DEVLOCL DEVSWAP DVTHPAV
-The ZRBUWENQ file now has the following variables from
the related ENT table entry added:
ENTENIDX ENTMAJNA ENTMINNA ENTSCOPE ENTFLAGS
-The ZRBASI file has two new variables for Memory Object
analysis:
ASITMO ='TOTAL*MEMORY*OBJECTS'
ASITMOBY='TOTAL*MEMORY*OBJECT*BYTES'
-The ZRBASM file has four new variables added in support
of UWD extensions:
ASMUWDHL='UWD*HEADER*LENGTH'
ASMUWDAL='UWD ASI*EXTENSION*LENGTH'
ASMUWDDL='UWD DEV*EXTENSION*LENGTH'
ASMUWDEL='UWD ENQ*EXTENSION*LENGTH'
-The RMFBASM file version is raised to X'02' from X'01';
-A new final message RMFV999I is now issued at the end of
ASMRMFV processsing. The message shows the total number
of WARNINGS, ERRORS, SEVERES (severe errors), and the
final Return Code. In the case of an abend the Abend
Code and Reason Code are also shown. The message appears
in both SYSPRINT and in the JES JOB log. This provides
one message to check to get the final status of ASMRMFV.
-A BYTES WRITTEN column is added to all ASMRMFV RMFV105I
messages for each combination of DATA ACTION and RMF III
table. The column is displayed regardless of the
BYTES/NOBYTES parameter setting. This shows what tables
are contributing most to the RMFBSAM output file size.
The byte count doesn't include the 4 bytes for each BDW
(block descriptor word).
-Support for the RMF III ARCHAIC PGP table is suppressed,
but could be enabled if needed. The PGP does NOT appear
in ASMRMFV detail and summary reports when disabled. The
PGP is only generated and available in z/OS Compatibility
Mode. IBM support for Compatibility Mode ended in March
2002 with the release of z/OS 1.3 as Goal Mode became
required. But it was safer to just suppress than to
remove code that will never be executed.
-ASMRMFV no longer abends when an invalid RED entry is
found. Instead the record is skipped.
-ASMRMFV message RMFV014I is now always issued regardless
of the DETAIL/NODETAIL setting.
-New ASMRMFV message RMFV035E is now issued when errors
are detected processing the SPG, RED, UWD, DSH, or SSH
tables. These are intended to attract the attention of
the support person who might otherwise overlook the less
obvious record SKIP counts.
-NOTE: Message RMFV035E can occur when the ERBRMFxx
PARMLIB member for RMF Monitor specifies a non-existent
Storage Group in the SGSPACE ADD parameter. RMF Monitor
III message ERB329I indicates this condition: ERB329I
III: ONE OR MORE STORAGE GROUP NAMES ARE NOT DEFINED IN
SMS. In this case the entire SPG table is skipped as the
integrity of the entries cannot be trusted as confirmed
by RMF Support. Correct the ERBRMFxx start up member for
RMF III as soon as possible and modify or restart RMF III
to restore SPG table processing. Corrupted SPG tables
cannot be processed by TYPERMFV.
-ASMRMFV message RMFV033E is now RMFV033S to indicate a
severe error when an I/O error occurs.
-The handling of unsigned halfword binary integers in RMF
III table fields by ASMRMFV is corrected when the high
order bit is on.
-Prologue documentation in the ASMRMFV source has been
updated to provide detail on BYTES WRITTEN column and the
skipping of UWD records.
-Member JCLRMFV in MXG SOURCLIB now shows examples of
building an RMF Monitor III PDB by the Direct JCL method.
-Member JCLCRMFV in MXG SOURCLIB now shows examples of
building an RMF Monitor III PDB by the Batch TSO CLIST
method.
Thanks to Steve Dyck, The Canadian Depository for Securities, Canada
Thanks to Neil Ervin, Wells Fargo, USA
Change 30.288 Velocity Software zVPS (a/k/a XAM) records are Variable
UXAMNRDW Length CMS files but when first copied to their ftp site
Jan 15, 2013 so I could ftp to ASCII to test new data, the two-byte
CMS record length field had been stripped, so I wrote
this heuristic that uses the structure of the first 16
bytes of each XAM logical record to create a readable
"z/OS" VB file. However, here is the correct way to
create a "RECFMU" file from a CMS variable file. This
note has been added to the MXG member FTPING:
23. Syntax to copy the XAM z/VM CMS Variable File to
RECFMU on z/VM:
z/VM exec to pipe the XAM CMS Variable data file (which
contains a two-byte record length) thru the BLOCK command
to create a file with the two four-byte z/OS BDW and RDW
fields; that output file can then be downloaded by ftp as
BINARY to an ASCII system where the file can be read with
SAS INFILE with RECFM=S370VBS and LRECL=32760. The
output filetype "RECFMU" is used as this data is the same
date with preserved BDW/RDW on z/OS created with
DCB=RECFM=U.
parse arg fn ft fm
'ACC FTPPOOL:MXG.XAMDATA x (FORCERW'
'pipe < 'fn ft fm,
' | block 32760 V',
' | >' fn 'RECFMU X'
1) The Parse arg fn ft fm is actual code.
It assumes you would start executing the EXEC with:
inputfilename inputfiletype inputfilemode
Parse arg pulls in the filename/type/mode that you
specified when you started the EXEC.
2) Looking at FTPPOOL:MXG.XAMDATA,
FTPPOOL is the SFS filepool name.
MXG is the filespace name (USERID)
XAMDATA is the subdirectory under the FTPPOOL root
Maybe a good PC analogy would be
filepool name = drive letter (such as C:);
USERID = a directory under C:(such as MXG)
subdirectory something under MXG (C:\MXG\XAMDATA)
Thanks to Dewayne Thomas, Velocity Software, USA.
Change 30.287 Executing MXG on ASCII to read compressed CICS/DB2 SMF is
JCLSPLIT generally much faster if you FIRST decompress SMF records
JCLSPLT1 on z/OS (using IBM ASM PGM=DFH$MOLS, PGM=DSNTSMFD, or SAS
JCLSPLT2 and EXITCICS - all call IBM's CSRCESRV ASM service to do
DFH$MOLS the decompression) and then SECOND, you run MXG on ASCII
DSNTSMFD to read that uncompressed SMF file. The simpler process
Jan 19, 2013 of running MXG on ASCII to directly both read compressed
SMF data AND to uncompress it is MUCH slower because the
CSRCESRV doesn't exist on ASCII and the ASCII alternative
byte-by-byte SAS code decompress algorithm is functional
but it is VERY CPU intensive (by a factor of MANY times).
Newsletter SIXTY-ONE had execution comparison results.
Only if you have network contention when MXG reads the
uncompressed data might your results be different; you
should at least test this alternative.
These members provide examples of how to parallelize
the MXG "BUILDPDB" process and first decompress on z/OS.
JCLSPLIT - changes are primarily comments but the split
of IO and MQ data is commented out as well as
the SYSIN for those datasets
JCLSPLT1 - the same as JCLSPLIT but also contains steps
for DFH$MOLS and DSNTSMFD
JCLSPLT2 - the same as JCLSPLT1 but uses temp dataset
names for the outputs, runs DFH$MOLS, DSNTSMFD
and then combines all the temp datasets with
IFASMFDP to be fed to MXG
DFH$MOLS - JCL to run DFH$MOLS
DSNTSMFD - JCL to run DSNTSMFD
Change 30.286 A new program that graphically compares values over time.
ANALCOMP Any number of variables from any number of SAS datasets
Jan 14, 2013 are aligned for starting days, weeks, months, or years,
with ODS Graphic's PROC SGPLOT (included in Base V9.3).
V9.2 SGPLOT does require SAS/GRAPH. One of many examples:
Compare hourly CPU time for each Service and Reporting
Class, for two weeks in November, from MONTH.TYPE72GO:
%ANALCOMP(INDATA=MONTH.TYPE72GO,
VARS=CPUTM,
COMPINTV=WEEK,
COMPARE=11NOV12 18NOV12,
SUMMARY=YES,
XAXIS=HOUR,
DATETIME=STARTIME,
SORTBY=SYSTEM RPRTCLAS SRVCLASS);
Change 30.285 Support for BETA93 subtype 51 which had been overlooked.
EXTYBETJ This record has 10 possible field formats, so there are
IMACBETA ten variables BETAFIELDC/H/I/V/D/T/S/B/F/P created for
VMACBETA Character/Hex/Integer/Variable/Date/Time/Small/Byte/Flag/
VMACBETA Pool which are populated based on BETAFTYPE value. But,
Jan 14, 2013 the Character type has both EBCDIC and HEX values so it
must be displayed as a hex string, since the vendor does
not identify which Field Names are text versus hex.
Change 30.284 Support for additional fields in PHYSVOL and VOLUME file.
VMACTAPR Now, PHYSVOL has 67 variables and VOLUME has 71.
Jan 11, 2013
Thanks to Xiaobo Zhang, Fiserv, USA.
Change 30.283 When UTILEXCL found an UNKNOWN FIELD, the circumvention
UTILEXCL to skip over that field could generate 180 syntax errors,
Jan 11, 2013 depending on the syntax generated for the prior and/or
the subsequent field. This update revises the logic to
provide a more reliable circumvention. UNKNOWN FIELD
message can occur when a back-level of UTILEXCL is used
to process a new CICS version's dictionary, or when there
are "user" fields created by the site with names other
than "USER". Sending the UTILEXCL log executed with
_BLDDICT; _BLDEXCL; _RPTEXCL ; to support@mxg.com
is the correct "circumvention", as that allows MXG to
add support for a user field or detect back-level.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.282 Comments updated to document all parameters. The default
ASUMDBSS SUMBY list includes SHIFT, so if you change the interval
VMXGDBSS value to DATE, wanting one observation per day, you get
Jan 10, 2013 multiple observations for each SHIFT value. You need to
remove SHIFT from the SUMBY list to get daily output:
%VMXGDBSS(
D2STATIN=&PDBMXG..DB2STATS,
D2STATOT=&PDBMXG..ASUMDBSS,
D2GBPSIN=&PDBMXG..DB2GBPST,
D2GBPSOT=&PDBMXG..ASUMDBSG,
D2BPSIN =&PDBMXG..DB2STATB,
D2BPSOT =&PDBMXG..ASUMDBSB,
ASUMINTV=DATE,
SUMBY=QWHSSSID BEGTIME,
INVKBY=DAILYDBSS
);
Thanks to Stu Samuels, Blue Cross Blue Shield of Illinois, USA.
Change 30.281 -BUILD005/BUIL3005 used in ONLYJOBS (create only PDB.JOBS)
BUILD005 set a return/condition code four for a PROC COPY message
BUIL3005 "WARNING: IN= and OUT= are the same" that is eliminated
ONLYJOBS by this change that creates an internal %SPINCOPY macro
ONLYJOBZ that conditionally issues the PROC COPY only when they
Jan 19, 2013 are different (as they are in all other uses of BUILD005)
For ONLYJOBS, they are correctly the same and the COPY
is not needed nor wanted.
-The original ONLYJOBS is now stored as ONLYJOBZ as a fine
example of how to tailor BUILDPDB using the old-style
macros, because the new ONLYJOBS now uses the newer and
more powerful %UTILBLDP macro (but still needing some of
those old-style macros) to create ONLY the datasets that
are actually needed by BUILD005.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 30.280 -MXG 30.10 iteration, IFCIDS=STATS still failed even after
READDB2 Change 30.257, generating DB2STAT4 NOT SORTED ERROR, due
Jan 9, 2013 to my insufficient testing with only OBS=0. You can use
IFCIDS=STATISTICS with 30.10 to circumvent this error.
-And the intended change to NOT create T102S106 unless it
was requested went too far, since it was NOT created when
106 was in the list of requested IFCIDS. (30.01 can be
circumvented by adding T102106=YES as an argument).
Thanks to Rachel Holt, Fidelity Systems, USA.
Change 30.279 The VFMT102 mapping of DBID/OBID/PSID value to the DB2
VFMT102 name has been reset to the safer algorithm that uses
Jan 8, 2013 PROC SORT to remove duplicate values; recent attempts to
construct the format and/or to use a MERGE have never
completely removed the overlap in values; that code is
kept in ZFMT102 from the last try until time and more
guidance from IBM DB2 support is available.
Change 30.278 -The MXG-created TASZIPTM/TASELGTM variables in CICSTRAN,
VMAC110 CICS/TS 5.1, were only populated when UTILEXCL was used
UTILEXCL to create an IMACEXCL, but are now populated in default
VMXGUOW 5.1 VMAC110 code, from IBM CPUTONCP/OFFLCPUT fields also
Jan 7, 2013 used to create CPUTONTM/CPUTONCN/OFFLCPUTM/OFFLCPCN in
Jan 13, 2013 Change 30.228 (CICS/TS 5.1 and APAR OA38409 is required).
Labels are corrected to provide clearer documentation:
CPUTONTM='TASK TOTAL*CPU TCB TIME*ON CP ONLY'
CPUTONCN='TASK TOTAL*DISPATCHES*ON CP ONLY'
TASCPUTM='TASK TOTAL*CPU TCB TIME*ON BOTH*CP+ZIIP'
(This is NOT NEW - has always been the sum of
CP and (normalized) zIIP CPU time).
TASDSPCN='TASK TOTAL*DISPATCHES*ON BOTH*CP+ZIIP'
TASZIPTM='TASK*ZIIP ONLY*CPU TCB*TIME'
TASELGTM='TASK*ZIIP-ELIGIBLE*RAN ON CP*CPU TCB TIME'
OFFLCPTM='TASK*ZIIP-ELIGIBLE*RAN ON CP*CPU TCB TIME'
OFFLCPCN='TASK*ZIP-ELIGIBLE*RAN ON CP*DISPATCHES'
-The calculation of TASZIPTM and TASELGTM were not shown,
and TASELGTM WAS WRONGLY CALCULATED prior to this change;
TASELGTM is equal to OFFLCPTM, but having created it, I'm
now compelled to keep the two identical variables:
TASELGTM=OFFLCPTM;
TASZIPTM=TASCPUTM-CPUTONTM;
-UTILEXCL now creates a new MXGNOTE in the IMACEXCL that
identifies the creation date of that IMACEXCL on the SAS
log when it is included, to confirm there is a tailored
IMACEXCL in use.
-ASUMUOW now keeps TASZIPTM TASELGTM and CPUTONTM.
Change 30.277 Support for TMON for CICS Release 3.4 for CICS/TS 5.1
EXMONTV INCOMPATIBLY adds variables to existing datasets and
IMACTMO2 creates one new dataset:
VMACTMO2 DDDDDD DATASET DESCRIPTION
VMXGINIT MONTV MONITV JVM SERVER STATISTICS
Jan 6, 2013 -Dataset MONITASK new variables:
TAU64HWM='USER 64 POOL HWM'
TAC64HWM='CICS 64 POOL HWM'
TASTCPUT='STANDARD*CP*CPU*TIME'
TASTCPUC='STANDARD*CP*COUNT'
TASTCPOT='OFFLOAD*ON*STD*CPU'
TASTCPOC='OFFLOAD*ON*STD*COUNT'
-Dataset MONISYST new variables:
TIENCCTM TIHU64ID TIU64HWM TIHC64ID TIC64HWM TISTCPUT
TISTCPUC TISTCPOT TISTCPOC
-Dataset MONIPA new variables:
PAACAPPL PAACMAJV PAACMICV PAACMINV PAACOPER PAACPLAT
PACECMCH PACECMDL PACLIPPO PACURTAS PAISIPNM PAMAXTAS
PAOADAT1 PAOADAT2 PAOADAT3 PAOADID PAOAPPL PAOASTRT
PAOCLIPA PAOCLIPP PAOFCTNM PAONETWK PAOPORTN PAOTCPSV
PAOTRAN PAOTRNUM PAOUSER PAOUSRCO PAPHAPPL PAPHCNT
PAPHNTWK PAPHSTRT PAPHTRAN PAPHTRNO PASOCIPH PAWBATNM
PAWBPINM PAWBPRON PAWBSVCN PAWBSVON PAWBURNM PASC64CC
PASC64CH PASC64FS PASC64GS PASC64SC PASC64UC PASC64UH
PADHDLC PAWMQREC PACPUTOC PACPUTOT PAOFFLCC PAOFFLCT
PAMQGETC PAMQGETT PAMQGETC PAMQGETT PACLIPAD PAFCVSWC
PAFCVSWT PAFCXCWC PAFCXCWT PAISALWC PAISALWT PAISIOWC
PAISIOWT PAJVMTHC PAJVMTHT PAMQSRBC PAMQSRBT PAMXDLYC
PAMXDLYT PAROMODC PAROMODT PASOMODC PASOMODT PAT8CPUC
PAT8CPUT PATCALWC PATCALWT PATDELWC PATDELWT PATDILWC
PATDILWT PABFDGSC PABFTOTC PAECEFOC PAECEVNC PAECSEVC
PAECSIGC PAEICTOC PAISALOC PAMLXMLC PAMLXSSL PAPGCSTH
PATIASKC PATITOTC PAWBISSC PAWBSFCC PAWBSFTC PAWBSREL
PAWBSRSL PAWSACBC PAWSACGC PAWSAEPC PAWSATOC
-Dataset MONIPI new variables:
PIPCDLL PIPCDRL PIPCLCC PIPCXCC PIPCDCC PIPCRCC
PIPCRCL PIICSCC PIICSCD PIICSRC PIICSRD PIWBROC
PIWBWOC PIWBIRC PIWBI1C PIWBOSC PIWBO1C PIWBPRC
PIWBBOC PIWBIWC PIWBRDL PIWBWDL PIPGCTC PIPGBCC
PIPGGCC PIPGPCC PIPGMCC PIPGGCL PIPGPCL PIPGCCC
PIISALOC PIEICTOC PIECSIGC PIECEFOC PIECEVNC PIECSEVC
PITIASKC PITITOTC PIBFDGSC PIBFTOTC PIMLXMLC PIWSACBC
PIWSACGC PIWSAEPC PIWSATOC PIWBSFCC PIWBSFTC PIWBISSC
PIPRTXCD PIL9CPUC PIL9CPUT PIX8CPUT PIX8CPUC PIX9CPUT
PIX9CPUC PIT8CPUC PIT8CPUT PIXTDLYT PIXTDLYC PISTDLYT
PISTDLYC PIMXDLYC PIMXDLYT PICMDLYC PICMDLYT PIFCXCWC
PIFCXCWT PIFCVSWC PIFCVSWT PIISIOWC PIISIOWT PIJVMTHC
PIJVMTHT PIMQSRBC PIMQSRBT PITDILWC PITDILWT PITDELWC
PITDELWT PIROMODC PIROMODT PISOMODC PISOMODT PIMQGETC
PIMQGETT PIISALWC PIISALWT PITCALWC PITCALWT PICPUTOC
PICPUTOT PIOFFLCC PIOFFLCT PIPHCNT PISC64CC PISC64FS
PISC64GS PISC64SC PISC64UC PIWMQREC
-The SMF format SMF 110 "CICSTRAN" records that can be
created by TMON don't contain the eight DFHRMI S001-S008
fields, previously optional, now created by default in
the IBM CICS/TS 5.1 SMF 110 records and thus expected in
the default MXG VMAC110 code for 5.1, so you will need to
use the UTILEXCL program to create a tailored IMACEXCL to
process these SMF records from TMON Version 3.4.
Change 30.276 Support for Mainview for CICS Release 6.5 for CICS/TS 5.1
EXMVCITD COMPATIBLY adds variables to CMRDETL and creates these
EXMVCITS two new datasets:
IMACMVCI DDDDDD DATASET DESCRIPTION
VMACMVCI MVCITD MVCITDQU TD QUEUE
VMXGINIT MVCITS MVCITSQU TS QUEUE
Jan 6, 2013 -New variables in CMRDETL for CICS/TS 3.2 and later:
T6EXCFLC='CFDT*LOCK*WAIT*COUNT'
T6EXCFLT='CFDT*LOCK*WAIT*TIME'
T6EXCFNC='CFDT*NONLOCK*WAIT*COUNT'
T6EXCFNT='CFDT*NONLOCK*WAIT*TIME'
T6EXLBC ='LSR*BUFFER*WAIT*COUNT'
T6EXLBT ='LSR*BUFFER*WAIT*TIME'
T6EXLSC ='LSR*STRING*WAIT*COUNT'
T6EXLST ='LSR*STRING*WAIT*TIME'
T6EXSTGC='STORAGE*WAIT*COUNT'
T6EXSTGT='STORAGE*WAIT*TIME'
T6EXTBC ='TS*BUFFER*WAIT*COUNT'
T6EXTBT ='TS*BUFFER*WAIT*TIME'
T6EXTMPC='TEMP*STG*WAIT*COUNT'
T6EXTMPT='TEMP*STG*WAIT*TIME'
and new CMRDETL variables populated only in CICS/TS 5.1:
T6E68XCT='68*EXTENSIONS'
T6EAPPLN='APPLICATION*NAME'
T6ECECID='CEC*MODEL*ID'
T6ECECTP='CEC*MACHINE*TYPE'
T6ECHWMG='GCDSA*HWM'
T6ECTSKS='CURRENT*TASKS AT*TRAN*ATTACH'
T6EFCSWC='FC VSAM*STRING*WAIT*COUNT'
T6EFCSWF='FC VSAM*STRING*WAIT*FLAG'
T6EFCSWT='FC VSAM*STRING*WAIT*TIME'
T6EFCXWC='FC*EXCLUSIVE*WAIT*COUNT'
T6EFCXWF='FC*EXCLUSIVE*WAIT*FLAG'
T6EFCXWT='FC*EXCLUSIVE*WAIT*TIME'
T6EISAWC='IS*ALLOCATE*WAIT*COUNT'
T6EISAWF='IS*ALLOCATE*WAIT*FLAG'
T6EISAWT='IS*ALLOCATE*WAIT*TIME'
T6EMAJVR='APPL*MAJOR*VERSION*NUMBER'
T6EMICVR='APPL*MICRO*VERSION*NUMBER'
T6EMINVR='APPL*MINOR*VERSION*NUMBER'
T6EMPPTX='POLICY*THRESHOLDS*EXCEEDED'
T6EMTSKS='MXT*AT*TRAN*ATTACH'
T6EOFCPC='ELIGIBLE*CPU TIME*COUNT'
T6EOFCPF='ELIGIBLE*CPU TIME*FLAG'
T6EOFCPT='ELIGIBLE*CPU TIME'
T6EONCPC='STD*PROC*CPU TIME*COUNT'
T6EONCPF='STD*PROC*CPU TIME*FLAG'
T6EONCPT='STD*PROC*CPU*TIME'
T6EOPERN='OPERATION*NAME'
T6EPLATN='PLATFORM*NAME'
T6ERODLC='RO*TCB*DELAY*COUNT'
T6ERODLF='RO*TCB*DELAY*FLAG'
T6ERODLT='RO*TCB*DELAY*TIME'
T6ESC64F='TOTAL*BYTES*FREED'
T6ESC64G='TOTAL*BYTES*OBTAINED'
T6ESC64S='SHARED*STORAGE*GET MAINS'
T6ESCCGG='GCDSA*GET*MAINS'
T6ESCUGG='GUDSA*GET*MAINS'
T6ESOCPH='CIPHER*SELECTED'
T6ESODLC='SO*TCB*DELAY*COUNT'
T6ESODLF='SO*TCB*DELAY*FLAG'
T6ESODLT='SO*TCB*DELAY*TIME'
T6ETCAWC='TC*ALLOCATE*WAIT*COUNT'
T6ETCAWF='TC*ALLOCATE*WAIT*FLAG'
T6ETCAWT='TC*ALLOCATE*WAIT*TIME'
T6ETDELC='TD*EXTRA*LOCK*COUNT'
T6ETDELF='TD*EXTRA*LOCK*FLAG'
T6ETDELT='TD*EXTRA*LOCK*TIME'
T6ETDILC='TD*INTRA*LOCK*COUNT'
T6ETDILF='TD*INTRA*LOCK*FLAG'
T6ETDILT='TD*INTRA*LOCK*TIME'
T6EUHWMG='GUDSA*HWM'
-An existing INVALID DATA error for T6ECNCNT, was found in
MXG code and corrected; it did not affect anything else.
Change 30.275 MXGNAMES/CONFIMXG adds support for a USER FORMAT library.
VMXGCNFG %LET MXGFMTU=DSNAME; dynamically allocates //USRFORMAT
Jan 5, 2013 and sets OPTIONS FMTSEARCH=(USRFORMAT LIBRARY) to search
the user formats first, before the MXG format library.
If you use CONFIMXG and you have an MXGNAMES DD in a PROC
pointed pointed at a dataset AND you override the
MXGNAMES DD with //MXGNAMES DD * the following message
will be in the JOBLOG - but it is not a failure
IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED
====== Changes thru 30.274 were in MXG 30.10 dated Jan 3, 2013=========
Change 30.274 Variables DWINSORM & DWDASORM are set to zero in TYPE113
ASUM113 if this is a one book machine, if L4RP LE 0 (one book) or
VMAC113 SM1132MM='M10' (2818 - z114).
Jan 2, 2013
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.273 MXG 30.05-30.09. VMXGALOC with MONTH argument did not
VMXGALOC correctly calculate the preceding month; when run with
Jan 2, 2013 normal _TODAY, on Jan 1, 2013, the monthly data was
written to November instead of December. Using FORCEDAY
of 1JAN2013 with MONTH did copy correctly.
Thanks to Richard Krueger, Sentry Insurance, USA.
Change 30.272 MXG 30.09 only. ERROR 48-59 FORMAT EBCDIC WAS NOT FOUND,
VMAC102 flagging the input of QWHSSSID. This occurred only in a
VMACDB2 user-constructed program that %INCLUDEd VMAC102 alone, or
Jan 2, 2013 before VMACDB2 (but that SHOULD have worked correctly!).
QWHSSSID and QWHSRELN were added to a PUT in DB2DECOM
to identify the system/release, but they had not been
input until after DB2DECOM. In VMACDB2 there happened to
be a LENGTH QWHSSSID $4 statement that avoided the error
when it was %INCLUDEd first. But now, both variables are
removed from that diagnostic PUT statement.
Thanks to Paul Volpi, UHC, USA.
Change 30.271 -Most of the _S102nnn dataset sort macros didn't delete
VMAC102 the _Wdddddd dataset after _Ldddddd dataset was built;
Jan 2, 2013 the %VMXGDEL(DDDDDD=102nnn) invocation was added to each
of the _S102nnn macros. Note that most of these "sort"
macros for ID=102 DB2 Trace don't actually sort the data;
most only copy the dataset with a DATA step, because the
NODUP duplicate-removal that is normal in _Sdddddd macros
requires data and time to validate the completeness of
the BY list, but over time, all _S102nnn dataset sort
macros will be changed to use PROC SORT NODUP.
Change 30.270 IDMS PERFMON Version 18 has a second segment subtype=4
VMACIDMS record which was previously unknown and was creating an
Dec 27, 2012 additional observation in IDMSINS that had all of the
Jan 2, 2013 variable names from the first segment. Second segment
is now decoded and new variables kept in IDMSIMS dataset:
INSSYTI ='CPU*TIME'
INSCPTI ='SRB*TIME*ON CP'
INSZPTI ='SRB*TIME*ON ZIP'
INSUSTI ='USER*MODE*CPU*TIME'
INSENTI ='TOTAL*ENCLAVE*SRB*CPU*TIME'
-Short third segment (PMHRLEN=68) from IDMS Version 17 is
now protected.
Thanks to Kim Westcott, NYS Office of Technology, USA.
Change 30.269 -SMFSRCH failed, writing to USERID.SMFOUT.DATA due to an
SMFSRCH error in VMXGGETM introduced in Change 30.224 which lost
VMXGGETM lost the & ahead of &SMFOUT, and testing of that change
VMXGSRCH overrode SMFOUT= so the missing & was not detected.
Dec 27, 2012 -Then, an extraneous PUT statement in VMXGSRCH caused a
22-322 syntax error (but the program continued to run).
The PRINTIT parameter was not correctly implemented, with
both a PROC PRINT and VMXGPRAL of the data found being
printed. Now only VMXGPRAL is printed if PRINTIT=YES.
Thanks to Dan Case, Mayo Clinic, USA.
Change 30.268 RACF317='BPX*DEFAULT*USER*USED?' is added to TYPE8028
VMAC80A thru TYPE8065 to identify if the FACILITY class profile
Dec 25, 2012 BPX.DEFAULT.USER is being used; that facility will NOT
exist in z/OS 2.1 (because it allowed many users of UNIX
system services to share a UID and GID, no longer a good
idea and FACILITY class profile BPX.UNIQUE.USER or other
alternatives are REQUIRED with z/OS 2.1). RACF317 will be
Y/N if a SMF80DTP=317 segment exists, otherwise, blank.
Note that APAR OA37164 added detection in the Health and
Migration Checks, for an alternative to determine if the
profile is being used.
Thanks to Randy Shumate, Reed Elsevier Technology Services, USA.
Change 30.267 -New IFCID 361 Audit Admin Authority (new with DB2 V10)
ANALDB2R added to Audit reports with new AUDIT= parameter value
Dec 24, 2012 of ADMIN.
-A fault in the logic for the multiple possible database
and object names in the IFCID 145 records was fixed.
Change 30.266 -New variable LPARIFLS in PDB.ASUM70LP and PDB.ASUMCELP
VMXG70PR and variables LPnIFLS in PDB.ASUM70PR and PDB.ASUMCEC now
Dec 23, 2012 counts the number of IFL engines allocated to each LPAR.
Dec 28, 2012 The existing NRIFLCPU variable is the number of IFLs
in the CEC.
DEDICATED IFL, OR SHARED IFL WITH WAIT COMPLETE=YES ARE
ALWAYS 100% BUSY IN RMF TYPE 70 (TYPE70PR/ASUM70PR) DATA.
For those environmens, z/VM MONWRITE (MXG TYPEVMXA) must
be used to measure IFL utilization.
For SHARED IFL with WAITCOMPLETE=NO, RMF 70 does capture
actual utilization of IFL engines.
See Newsletter FIFTY-EIGHT "1. MONWRITE" for comparison.
The Wait Complete=YES is set when the box "Do not end
time slice if a partition enters a wait state" was
checked.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 30.265 Support for DB2 Trace IFCIDs 361 and 362 populates the
FORMATS existing T102S361 and T102362 datasets.
VMAC102
Dec 22, 2012
Change 30.264 Support for APAR OA39562 creates new TYPE70Y3 dataset for
EXTY70Y3 zEC12 processors new PKCS11 Crypto Co-Processor providing
VMAC7072 CEX4P measurements. (Input statement corrected Jan 3
VMXGINIT after IBM support finally clarified the 10 was 10'x.)
Jan 3, 2013
Change 30.263 For CICS records with multiple USER segments that are no
IMACICUS longer populated nor needed, you can cause them to be
UTILEXCL skipped (so variable USERCHAR will be blank) simply by
Dec 21, 2012 creating an IMACICUS member in your "USERID.SOURCLIB"
that has only a comment to document that you are skipping
over the USER segments. This is only documentation.
Thanks to James Olson, Dominion Resource Services, Inc, USA.
Change 30.262 TYPE1052 variable SM105LID is now converted to a one-byte
VMAC105 numeric hex value; IBM documented the two bytes as binary
Dec 19, 2012 but the actual field contains two EBCDIC characters for
a one byte hex value (e.g., 'F1C1'x for 1Ax; the original
MXG input as PIB2 created SMF105LID=61889 from 'F1C1'x.
Thanks to Jeffrey A. Johns, UHC, USA.
Change 30.261 TMON/MQ latency variables QAMINLAT/MAXLAT/TOTLAT are now
VMACTMMQ correctly input as STCK time values, and formatted with
Dec 19, 2012 TIME13.3, now that TMON support informed me they are STCK
Jan 17, 2013 units (so the values input with PIB8.6 informat are now
divided to 4096 to convert from STCK).
Thanks to Homayoun Riaza, United Health Group, USA.
Change 30.260 The count in variable ABENDS in PDB.JOBS was incorrect as
BUILD005 it could include jobs that ended with ABEND='RETURN'. It
BUIL3005 now contains the correct count of STEPS that had either
Dec 13, 2012 a 'SYSTEM' or a 'USER' ABEND code, plus a count of one is
added for jobs that had a PRE-EXECUTION error in a step
(i.e., the step initiated but either was not allocated or
was not program-loaded, ALOCTIME or LOADTIME are missing)
and for this instance, variable ABEND='PREEXEC' is set.
Thanks to Louis Deledalle, BNP Paribas, FRANCE.
Change 30.259A Formats $MG119ME and $MG119PM did not decode the
FORMATS FCMechanism value A='A:AT_TLS' and $MG119ME value of 'T'
Dec 13, 2012 is corrected to T:TLS.
Thanks to Richard Wendland, USBank, USA.
Change 30.259 Support for SMF 99 Subtype 12 and 14 HiperDispatch data.
EXTY99CC New datasets created:
EXTY99CI Subtype DDDDDD DATASET DESCRIPTION
EXTY99CP 12 TY99CI TYPE99CI HD INTERVAL
EXTY99EH 12 TY99CC TYPE99CC HD CAPACITY
EXTY99EM 12 TY99CP TYPE99CP HD PROCESSOR
EXTY99EN 14 TY99EH TYPE99EH HD HEADER
EXTY99EP 14 TY99EP TYPE99EP HD PROCESSOR
EXTY99EQ 14 TY99EN TYPE99EN HD NODES
IMAC99 14 TY99EM TYPE99EM HD MQWP
VMAC99 14 TY99EQ TYPE99EQ HD MPWQ HNODE
VMXGINIT These datasets have been tested with z/OS 1.12 data.
Dec 12, 2012 Every 10 seconds, five subtype 12 records are written
Jan 2, 2013 with the same SMFTIME but each is a 2 second duration
with S99CCITOD containing the start of each interval.
-Initially, a pair of subtype 14 records are written every
five minutes, but APAR OA39058 changes that architecture
to write only one record each interval. Until I have
test data with that APAR, the duplicate removal for
TYPE99EH/EM/EQ in their _Sdddddd macro is not validated.
-The IBM labels for S99EEPNL1/NL2 are reversed, so the MXG
labels are now corrected to match data vs documentation:
S99EEPNL1 ='TOPOLOGY*NESTING*LEVEL 1*BOOK'
S99EEPNL2 ='TOPOLOGY*NESTING*LEVEL 2*CHIP'
Thanks to Dave Cogar, Wells Fargo, USA.
Change 30.258 Duplicate obs were not removed from BVIR21 dataset by the
VMACBVIR NODUP option in the PROC SORT in macro _SBVIR21 because
Dec 11, 2012 the BY list did not include ADHBAD and ADHSLOT.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY
Change 30.257 -If you specified IFCIDS=STATS, the sorts of the datasets
READDB2 input to the DB2STATS dataset were suppressed and steps
Dec 11, 2012 failed with variables not in order. You SHOULD use the
Jan 1, 2013 IFCIDS=STATS instead of IFCID=STATISTICS because STATS
creates ONLY DB2STATS/DB2STATR/DB2STATB/DB2GBPST whereas
IFCID=STATISTICS also writes these redundant datasets
DB2STAT0/DB2STAT1/DB2STAT4/DB2ST225/DB2STATB) that are
completely contained in PDB.DB2STATS; IFCIDS=STATS is now
set as default instead of IFCID=STATISTICS.
-READDB2 now invokes the _S102nnn sort macros so that the
work copy is deleted after copy to minimize disk space.
But this creates 23 lines of log messages for each data
set instead of proc copy's two lines per data set.
See Change 30.271.
-Comments document where data is written for combinations
of PDBOUT= and ACCTSORT= and IFCIDS=.
-If you asked for IFCIDS=261, sorts on statistics caused
errors when those dataset did not exist. The test on the
macro variable was checking the length and should have
been checking the value.
Thanks to Alyona Bertneski, JPM Chase, USA.
Change 30.256 Briefly, this change created variable MSUHARD, but that
VMAC30 was removed as a bad idea.
Dec 10, 2012
Dec 16, 2012
====== Changes thru 30.256 were in MXG 30.09 dated Dec 8, 2012=========
Change 30.255 If you used WEEKKEEP or WEEKDROP parameters and the
BLDSMPDB length of the dataset name(s) specified was longer than
Dec 7, 2012 the current dataset name being checked (for example you
said TYPE64: and the current dataset was IPLS) then the
length of the first was greater than the second and an
invalid substr length message was created. Everything
still ran correctly since it created a FALSE on the
condition being tested but it did generate a bad return
code when run in the background. A check on the length is
now used in addition to comparing the values.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 30.254 -Support for new CRYPTO TYPE PRCAPMCT=10 in VXPRCAPM. The
VMACVMXA UNDECODED message was printed, but then MXG failed with
Dec 5, 2012 INVALID BLOCK messages because the undecoded detection
Dec 19, 2012 didn't properly set the SKIP value, so subsequent INPUTs
Dec 20, 2012 were misaligned. There are three sub-subtype values in
PRCAPMMT of 8, 9, and 10, but only 10 has new variables
now kept in VXPRCAPM dataset, and only sub-subtype 9 has
been "data-tested".
Previous Crypto cards have names for values in PRCAPMCT:
PCICC PCICA PCIXCC CEX2A CEX2C CEX3A CEX3C
3 4 5 6 7 8 9
but no names are identified for the new Crypto Type 10
nor its three sub-subtypes in PRCAPMMT.
The new PRCAPMCT=10 was observed on zEC12 processors and
is thought to be a Crypto Express 4S.
-Dec 20: PRCAPM support for PRCAPML4=0 records corrected a
program loop.
-Support for new HIS (SMF113) counters in zEC12 processor,
eliminates "ERROR. PRCMFC HARDWARE COUNTER UNEXPECTED",
message with CFVN=1 and CXVN=3, which fortunately was
harmless to the rest of zVM processing.
Thanks to Kim Morrell, Royal Canadian Mounted Police, CANADA.
Thanks to Jim Dammeyer, State Farm Mutual Auto Insurance, USA.
====== Changes thru 30.253 were in MXG 30.09 dated Dec 4, 2012=========
Change 30.253 ONLY Dec 3 ASCII MXG 30.09, ONLY if MXG runs on AIX/unix.
dir3009.zip That DIR3009.ZIP distribution file dated Dec 3 has files
Dec 4, 2012 that end with a single X'1A (EOF) character. While that
character is ignored on Windows, when that unzipped 30.09
directory's files were copied from Windows to unix, those
X'1A' characters were preserved, and when read on unix by
SAS %INCLUDE, they caused SAS 180 SYNTAX errors (and may
have printed a left-arrow for that character). All X'1A'
characters were removed from this Dec 4 DIR3009.ZIP file.
Those X'1A characters are ERRORS in MY EDITing and should
NOT exist (created when I mix up LF and CRLF profiles),
and since I have done this before, the PROCSRCE program
that creates the other MXG distribution files has a test
for X'1A' characters, so those files are not exposed, but
that dir3009.zip file is a direct zip of the .sas files
in the MXG Sourclib directory.
But, how did they slip thru?
X'1A' are usually created AND detected when I email ASCII
new/updated code to a z/OS test site, and that test fails
when the translated X'1A' on EBCDIC is read by %INCLUDE.
I correct these updated files, and then search all of MXG
files for any others overlooked since the last search.
But why didn't PROCSRCE's test find them in 30.09 QA?
Because I've just discovered that X'1A' is IGNORED by
SAS V9 on Windows, whether read by %INCLUDE or an INFILE.
(And, since they ARE End Of File Markers, on Windows,
when found at the END of the file, they should be.)
I cannot prove that PROCSRCE ever found a match; perhaps
that test was added for safety, not realizing it wouldn't
ever be true on Windows SAS.
So I now searched all 30.09 files using SPF/PRO, and it
DID find 5 files, but did NOT find EXTY74HO that caused
the error! BUT: EDITing EXTY74HO in that same session
showed there WAS an X'1A' at the end of that file. Now,
it was clear that SPF/PRO can not be trusted to find all
instances of '1A'x in a large directory. But SPF/PRO is
ancient, so I searched with nearly-as-old SPF/SE and it
found these files in dir3009.zip that all ended with
an X'1A' character, and which were all removed Dec 4:
aaaaaaaa achap32 achap99 asmrmfv asmtapee copyrite
copywrit docver docver30 doqa9364 ex102366 exty74ho
imac102 jcltes92 jcltess8 jcltess9 jcltest6 jcltest8
jcltest9 qa9364 qa93641 qa93642 qa93643 qa93644
qa93645 qa93646 qa93647 qa93648 qa93649 qadoc
qawps qawps1 qawps2 qawps3 qawps4 qawps5
qawps6 qawps7 qawps8 tessothr tessusr1 testothr
testusr1 typetmo2 typetms5 vmac79 vmacbbmq vmacdb2
vmacdcol vmacommq vmactmnt vmactms5 vmacvmxa
Thanks to Sterling James, DST Systems, USA.
====== Changes thru 30.252 were in MXG 30.09 dated Dec 3, 2012=========
Change 30.252 Variable R748AAS0 was created from R748AAST but was not
VMAC74 formatted with $MG0748C, nor was it LENGTH $1 nor was it
Dec 03, 2012 in the &MXGNOTRA list of character hex variables.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 30.251 ANALCPU compares two different week's TYPE72GO CPU time,
ANALCPU creating one plot for each Service and Reporting Class,
Dec 03, 2012 with one line for each week, showing CPUTM vs STARTIME,
which is aligned to midnight Sunday of each week. These
plots could show which service class CPU time increased
or decreased, and show if he shape of the daily profile
had changed between the two weeks.
SAS/GRAPH is not used, but SAS Version 9 is because the \
plots are created with PROC SGPLOT in Base SAS V9.
Change 30.250 Hardcoded PDB. in ANALZIPC caused ITSV with %CPSTART to
ANALZIPC fail. Change 15.320 stated all hardcoded "PDB." LIBNAMEs
Nov 30, 2012 were to be replaced with "&PDBMXG.." to interface with
ITSV, but these members have been overlooked and are now
revised with no hardcoded PDB libnames:
ANAL113 ANAL120 ANAL307X ANAL4HRS ANAL72GO ANAL80A
ANAL91 ANALAAAA ANALABND ANALACF2 ANALALOC ANALAVAI
ANALAVAL ANALBLSR ANALBNC1 ANALBNCH ANALCACH ANALCAPD
ANALCISH ANALCPUV ANALDATE ANALDB2R ANALDB2T ANALDB2V
ANALDBJO ANALDBJS ANALDBTR ANALDMON ANALEAS ANALFIOE
ANALGRID ANALHPCS ANALHTML ANALNAT ANALNPMR ANALNSPY
ANALPGM ANALRACF ANALRAID ANALRMFR ANALS225 ANALSRVC
ANALTMVT ANALUAFF ANALUOW ANALUSAG ANALWHO ANALXAMR
ANALZIPC ANALZIPU ASUM4HRS ASUM72GO ASUM78CF ASUM94
ASUMCICR ASUMCLDR ASUMRAID ASUMSMFI ASUMSTC ASUMSTGP
ASUMSYTA ASUMTAPE ASUMTCPT ASUMV11 ASUMV14 ASUMVMNT
ASUMVTVM CHANGES CICSSTAT COMPINTV COMPIPLS DB2PDB
MRGDB2 NEWSLTRS VMXGINIT
Thanks to Christelle Abily, Groupe Informatique Credit Mutuel, FRANCE
Change 30.249 SMF ID=119 Subtype=51 INPUT STATEMENT EXCEEDED RECORD due
VMAC119 to 80 byte fifth segment when MXG expected 88 bytes. The
Nov 28, 2012 last two fields are now conditionally input.
Thanks to Robert B. Richards, US Office of Personal Management, USA.
Change 30.248 Cosmetic. SMF Header Messages didn't clearly identify
VMACSMF back-to-back header/trailer nor header-to-trailer with no
Nov 27, 2012 intervening SMF record; text in messages was clarified.
Change 30.247 -Variable SMF70NRM (zIIP Normalization Factor) is now kept
VMAC7072 in TYPE70PR dataset.
VMAC78 -Variables R783PB, R783CUB, R783zzz in TYPE78CF are kept
Nov 22, 2012 so those raw values are available.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 30.246 -DB2STATS QWOSxxxx variables have value 4294967295 decimal
VMACDB2 ('FFFFFFFF'x) and variable QWOSFLG='F2'x, but IBM did not
Nov 22, 2012 document those bit values nor document the FFFFx values.
Nov 28, 2012 Change 26.201 has IBM notes about the proper APAR install
to capture this RMF data, but it didn't note that you
must set the DB2 option ZOSMETRICS=YES to populate them.
-This change tests the first variables for the large value
and if both are found, all 14 QWOSxxxx are set missing.
-The four utilization values have values greater than 100
as input, and there is no IBM documentation that the must
be divided by ten, but now they are.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 30.245 -Support for BMC Mainview IMS 4.6, a/k/a IMF, a/k/a CIMS,
VMACCIMS adds new zIIP and zAAP metrics to the CIMSTRAN dataset:
VMACIMS TRXZTCPU='TOTAL*DEP RGN*APPL CPU'
Nov 21, 2012 TRXZONCP='TOTAL*DEP RGN*APPL CPU*ON CP'
TRXZAOCP='DEP RGN*ZAAP ELIGIBLE*RAN ON CP'
TRXZIOCP='DEP RGN*ZIIP ELIGIBLE*RAN ON CP'
TRXZFL1 ='TRXZFL1*FLAG'
TRXZTCPU='TOTAL*DEP RGN*APPL CPU'
TRXZONCP='TOTAL*DEP RGN*APPL CPU*ON CP'
TRXZAOCP='DEP RGN*ZAAP ELIGIBLE*RAN ON CP '
TRXZIOCP='DEP RGN*ZIIP ELIGIBLE*RAN ON CP'
-The zIIP/zAAP values are NORMALIZED to the speed of the
CP engines if your CPs are slower than Specialty Engines.
-Note that ZTIME=YES must be specified in BBPARM IMFECP00
member to populate zIIP/zAAP fields in the IMF records;
the default value is NO.
-Some missing value calculations observed in testing that
could be protected in VMACCIMS and VMACIMS now are.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
Change 30.244 Support for WebSphere Version 8 ID=120 Subtype 10 record
EXT12010 creates new TYP12010 dataset.
FORMATS
IMAC120
VMAC120
VMXGINIT
Nov 20, 2012
Thanks to Mark Wittie, Fidelity Systems, USA.
Change 30.243 VMXGCOPY copies SAS datasets from MULTIPLE input LIBNAMES
VMXGCOPY whereas PROC COPY only allows from a single input ddname.
Nov 20, 2012 Parameters:
LIBNAMES= One or more SAS data libraries to be read.
Each value is a "starting with" string, so PDB
reads ALL LIBNAMEs starting with PDB.
On zOS each libname must have been opened with
either a LIBNAME statement or a data step, or
it will not be found.
OUTDD= The output LIBNAME where output is written.
Default is WORK.
DATASETS= One or more SAS dataset names to be copied.
Each value is a "starting with" string, so the
string TYPE will select ALL datasets starting
with TYPE. If a dataset is in multiple inputs
the output will contain ALL observations from
ALL of those datasets.
NOBS= the number of OBS to copy
ZEROOBS YES, all datasets are copied. NO, datasets
with zero observations are NOT copied and
won't exist in the output LIBNAME.
INCODE= Optional argument with your SAS code to select
which observations to copy, PROVIDED THAT THE
variable(s) you use exist in ALL datasets.
For example,
INCODE= IF SYSTEM=:'ABCD';
Change 30.242 New parameter CRITERIA= inserts SAS code for selection.
VMXG2DTE For example, if you want to keep SMFINTRV data ONLY for
Nov 15, 2012 your started tasks, at a weekly or monthly level, and you
want APPEND the new data, you would use:
%VMXG2DTE(DDIN=WEEK,DDOUT=WEEK,PDB=PDB,
DATASET=SMFINTRV,CRITERIA=TYPETASK=:'STC',APPEND=YES);
or, if you want to use GDGs and a DATA step, use:
%VMXG2DTE(DDIN=WEEKIN,DDOUT=WEEK,PDB=PDB,
DATASET=SMFINTRV,CRITERIA=TYPETASK=:'STC');
In either case, you don't supply the IF or the ending
semi-colon; the text of CRITERIA= just needs to be a SAS
expression that is TRUE for observations you want kept.
Change 30.241 There are cases where the object name can change within
ANALDB2R a database ID and object ID and possibly cases where
VFMT102 the database name might change so timestamps are needed
Nov 21, 2012 to correctly build the formats to extract the correct
database name and object name from the IFCID 105 and 107
records. This can create a massive format that requires
a large amount of memory. In one case on zOS with 16M
input records it required 862MB to create the format
and nearly as much to load it. But, the only time you
might need all of the records is when you are running
an IO trace. In the case of an Audit trace, you have
to build an Audit table to tell DB2 which things you
want to audit. So, selection criteria for DBNAME and
OBNAME are added to ANALDB2R to reduce the volume of
records input to VFMT102. You can select based on:
SYSTEM DB2 DBNAME and OBNAME
By selecting only the needed DBNAMEs, the virtual storage
needed for the format was less than 50 MB, so selection
is ALWAYS wise to do.
In addition, SYSTEM (z/OS execution system) is added as a
criteria for ALL ANALDB2R reports (DBNAME and OBNAME are
only available to VFMT102 datasets with DBID or OBID).
Don't know what DBNAME/OBNAME(s) you have? New report
MXGDBIDS=ONLY provides the list of all combinations
of SYSTEM QWHSSSID (DB2 SUBSYSTEM)DBNAME OBNAME using:
%ANALDB2R(PDB=SMF,MXGDBIDS=ONLY);
RUN;
-Unrelated, new parameter MXGACC01OUT creates an output
dataset that you name in that parameter from the MXGACC01
PROC TABULATE.
Change 30.240 Graphic and tabular reports of DB2 buffer size and max
GRAFDB2B usage, by DB2 Subsystem and Buffer Pool. Will use either
NOV 10, 2012 SAS/GRAPH or ODS GRAPHICS for graphs and PROC TABULATE to
create a tabular report.
Documentation of parameters:
PDB=PDB One or more PDB DD NAMES (LIBNAMEs)
SASGRAPH=NO Create bar charts with SAS/GRAPH
ODSGRAPH=YES Create bar charts with ODS Graphics
TABULATE=NO Create a tabular report
INTERVAL=QTRHOUR Any valid interval value
SAS versions 9.2 and earlier will not work for ODS; 9.3
is required for ODS graphics. If you are at 9.2 and don't
specify SASGRAPH=YES, the tabulate report will be created
instead. If you specify SASGRAPH=YES but it is not
installed, on SAS 9.3 or above, ODS GRAPHICS are used.
Otherwise, only the PROC TABULATE report is created.
Change 30.239 -VMACIMS IMS Eyecatcher variables STREQxxxx had $HEX40.
VMACIMS format but were correctly input as $EBCDIC4; the format
VMACRMFV and listing in NOTRAN were removed. Purely cosmetic.
VMAC120 -VMACRMFV variable ASMVER00 is now correctly INPUT $CHAR1
Nov 10, 2012 instead of $EBCDIC1 as it contains HEX text characters.
-VMAC120 variable SM1209GS is now correctly INPUT $CHAR8
instead of $EBCDIC1 as it contains HEX text characters.
(Note: $CHARn is REQUIRED only for MXG execution on ASCII
platforms - on z/OS $CHAR and $EBCDIC are identical.)
Change 30.238 Support for Phoenix Software International (E)JES SMF
EXTYEJES Accounting Record creates new EJESSMF dataset. MXG reads
IMACEJES either the unique date format for ESMFTBGN or, after
TYPEEJES EJES/14242 update, in (E)JES V5R3, the SMFSTAMP format,
TYPSEJES transparently.
VMACEJES New dataset:
VMXGINIT dddddd dataset description
Nov 11, 2012 TYEJES EJESSMF (E)JES SMF ACCOUNTING
Thanks to Mike Moyne, HHSYS, USA.
Change 30.237 Support for Version 4.3.0 BETA93/BETA97 (INCOMPATIBLE).
EXTYB97M -BETA93: New variables added to BETA1 dataset:
EXTYB97N BETAATYP='SEND*AS'
EXTYB97O BETABODY='BODY*TEMPLATE*MEMBER'
EXTYB97P BETABTYP='OUTPUT*TYPE'
EXTYBET7 BETABUFS='MAXIMUM*BUFFER*SIZE'
EXTYBET8 BETADCR ='DCR*NAME'
EXTYBETH BETAFILE='MAIL*FILE*NAME'
EXTYBETI BETAFROM='MAIL*FROM'
FORMATS BETAIPAD='IP*ADDRESS'
IMACBE97 BETALINK='LINK*TEMPLATE*MEMBER'
IMACBETA BETALTKN='LTOKEN*LIST*TOKEN'
VMACBE97 BETAMAXA='MAXIMUM*MAIL*ADDRESSES'
VMACBETA BETAPORT='PORT*NUMBER'
VMXGINIT BETARPLY='MAIL*REPLYTO'
Nov 13, 2012 BETASEXT='SOURCE*EXTENSION*NAME'
BETASFRM='SOURCE*FORM*NAME'
BETASUBJ='MAIL*SUBJECT'
BETATRMD='TRANSLATION*MODULE'
BETATRTB='TRANSLATION*TABLE'
-BETA93: New $MGBETPT format maps these values of BETAPTYP
in BETA1 dataset, which describes which of the sets of
variables exist in this record:
'80'X='80X:DCR OF TYPE SYSOUT'
'40'X='40X:DCR OF TYPE MAIL'
'20'X='20X:DCR OF TYPE CLIST'
'10'X='10X:PRE-ALLOCATED DD NAME'
'08'X='08X:DCR OF TYPE VTAM/APPC'
'04'X='04X:DCR OF TYPE SUBSYS'
'02'X='02X:DCR OF TYPE TCP/IP'
-BETA93: New Subtypes 7, 8, and 22 are documented but only
the header variables exist in the new BETA7 BETA9 BETA22
datasets until actual records are available.
-BETA93: New Subtype 49 creates BETA49 dataset for Batch.
-BETA97: New Subtype 25 creates BETA9725 dataset.
-BETA97: New Subtype 50 creates BETA9750 dataset.
-BETA97: New Subtypes 49 and 51 create BETA0751 but only
header variables are created, awaiting test records.
Thanks to Mrs. Karen Sendelback, Finanz Informatik, GERMANY.
Change 30.236 Cosmetic, spurious messages. TYPE113 processing printed
VMAC113 messages ERROR: DEACCUMULATION DETECTED RESET when HIS
Nov 8, 2012 sampling was enabled for one minute every five minutes,
because MXG did not use the SM113CF1 Start of Interval
flag to bypass the test for negative deltas that printed
these messages. However, both TYPE113 and ASUM113 were
correctly created because MXG's test for the output did
work as designed. Now, SM1113CF1 flag is used to bypass
the creation of these messages.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
====== Changes thru 30.235 were in MXG 30.08 dated Nov 7, 2012=========
Change 30.235 Variable CFWAITTO='TOTAL CF*CPU*WAIT TIME' is created in
VMAC74 dataset TYPE74CF as the SUM OF(CFWAIT01-CFWAIT15) to
Nov 7, 2012 match existing CFBUSYTO total CPU busy time.
Thanks to Joe Faska, Depository Trust, USA.
Change 30.234 First MXG 30.08, zEC12 ONLY, and ONLY with APAR OA37826,
VMAC74 which added the HO segment to the RMF 74 subtype 4 record
Nov 7, 2012 ERROR: INVALID DATA FOR CHAR4
INPUT STATEMENT EXCEEDED RECORD LENGTH.
because that code was only syntax checked, awaiting data
with that APAR installed, and CHAR4/ passed syntax but
failed when data was read, as it should have been CHAR4.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 30.233 -TYPE70 variable CPUWAITM was wrong and was larger than
ADOC7072 CPUUPTM when HiperDispatch was active (SMF70PAT GT 0) but
VMAC7072 IRD was not active (SMF70ONT=DURATM for all engines).
Nov 7, 2012 MXG did not subtract parked time from CPUWAITM, BUT ONLY
Apr 1, 2013 CPUWAITM was wrong, and since CPUWAITM is NOT used in any
other metrics, they WERE correct. Only if you compared
CPUUPTM with CPUWAITM would the error have been observed.
This error was only significant at low utilizations when
CP engines were parked; during peak intervals when all CP
engines were NOT parked, the CPUWAITM value was correct.
-But in examining the 70 records, observations in TYPE70PR
have been found with SMF70PAT greater than SMF70ONT and
DURATM by over 5 seconds; new code detects and resets
SMF70PAT to SMF70ONT and zeros CPUWAITM when a small
negative value (less than 0.10 seconds) is calculated.
So both NEWWAIT and SMF70PAT in TYPE70PR are different.
RMF development has confirmed that because ONT and PAT
are retrieved independently with DIAGNOSE instructions,
the can have different values, and RMF Reports use the
same heuristic I implemented, to store ONT in PAT when
PAT is greater than ONT.
-Inserted Apr 2013: A "WARNING. SMF70PAT GT ONT" message
was previously printed, but since there is nothing that
you can do with that information, as of MXG 31.02, it is
no longer printed.
-Variable CPUUPTM is now documented in ADOC7072:
"Originally the CPU "UP" duration for calculation of
available capacity of all CP engines, and was the
product of NRCPUS*DURATM, but that was back when the
number of CP engines were static, at least between
IPLs. Now, with IRD and HiperDispatch "varying" or
"parking" engines, NRCPUS is the AVERAGE (and
fractional) number of CP engines that were ONLINE
during this interval, i.e., that that were made
available to this z/OS system during this interval, so
the CPUUPTM=NRCPUS*DURATM now will vary and it is no
longer the "available for static capacity" up time."
Thanks to Mark Cohen, EPVTECH, ITALY
Change 30.232 Hiperdispatch introduces some vagaries into percent CPU
GRAFWRKX measurements. PCTCPUBY in RMFINTRV is calculated based
Nov 6, 2012 on the average number of CPUs online but that may be
something less than the actual number of CPs assigned
to the LPAR. GRAFWRKX now produces 3 different CPU busy
by workload charts.
% of the average number of CPUs online
% of the CPUs assigned to the LPAR
% of the LPAR SHARE (this can exceed 100% if an LPAR
is 'stealing' from other LPARs.)
Thanks to Mark WIlliams, Marks and Spencer
Change 30.231 -Support for IFCID 219 populates existing T102S219 dataset
VMAC102 with new QW0219xx IFCID-specific variables.
Nov 5, 2012 -Support for IFCID 220 populates existing T102S220 dataset
Nov 8, 2012 with new QW0220xx IFCID-specific variables, but there are
discrepancies between the IBM DSECT and the actual DATA
and a PMR is opened with IBM to resolve. See Ch 33.064.
-Support for IFCID 402 populates existing T102S402 dataset
with new QW0402xx IFCID-specific variables, but IFCID 402
is a statistics interval record with accumulated values,
so you MUST invoke TYPS102 or use %READDB2 with PDBOUT=,
or invoke _S102402 after dataset T102S402 is created, to
do the deaccumulation. And unlike the other DB2 V10
interval statistics records, IFCID=402 is written at 15
minute instead of 1 minute intervals.
-Support for 4TH Waiter in T102S196 dataset added Nov 8.
====== Changes thru 30.230 were in MXG 30.08 dated Nov 5, 2012=========
Change 30.230 Variables LPnPAT were missing in PDB.ASUM70PR,PDB.ASUMCEC
VMXG70PR (but SMF70PAT parked time was valid in PDB.ASUM70LP and
Nov 3, 2012 PDB.ASUMCELP datasets). The LPnPAT variables were not in
the RETAIN statements for the two datasets, so they have
always been missing; this is not a new error!
Thanks to Wayne Bell, UniGroup, USA.
Change 30.229 Support for DB2 NETEZZA Optional data has been read and
IMACDBNZ some corrections were made in the DB2STATS/DB2NETZA.
VMACDB2 -These DB2STATS variables
Nov 2, 2012 Q8STSCPU Q8STSELA Q8STTCPU Q8STTELA Q8STACPU Q8STAELA
were not divided by 4096.
-These DB2STATS variables
Q8STACTV Q8STCCPU Q8STWCPU Q8STQUEM
were incorrectly de-accumulated.
-The Q8AC triplet was incorrectly input, causing all of
the Q8ACxxxx variables in DB2ACCT (when enabled by the
removal of the comment block in IMACDBNZ) to be wrong.
And, the Q8ACNAME field is now INPUT and populated.
IBM DB2 Analytics Accelerator IDAA uses Netezza.
Thanks to Victoria Lepak, Aetna, USA.
Thanks to William E. Howard, Aetna, USA.
Change 30.228 Support for CICS/TS 5.1, INCOMPATIBLE CHANGES, INSERTS.
UTILEXCL -CICSTRAN has new fields inserted at the end of each
VMAC110 segment. The RMI fields that were formerly optional
Dec 30, 2011 are now created by default. CMODIDNT
Apr 25, 2012 TDILWTTM='TDILWTT*DURATION' 403
May 28, 2012 TDILWTCN='TDILWTT*COUNT' 403
Sep 25, 2012 TDELWTTM='TDELWTT*DURATION' 404
Oct 15, 2012 TDELWTCN='TDELWTT*COUNT' 404
Nov 1, 2012 ROMODDTM='ROMODDLY*DURATION' 348
ROMODDCN='ROMODDLY*COUNT' 348
SOMODDTM='SOMODDLY*DURATION' 349
SOMODDCN='SOMODDLY*COUNT' 349
ISALWTTM='ISALWTT*DURATION' 319
ISALWTCN='ISALWTT*COUNT' 319
TCALWTTM='TCALWTT*DURATION' 343
TCALWTCN='TCALWTT*COUNT' 343
SOCIPHER='SOCIPHER*COUNT' 320
CECMCHTP='CECMCHTP*NAME' 430
CECMDLID='CECMDLID*NAME' 431
MAXTASKS='MAXTASKS*COUNT' 433
CURTASKS='CURTASKS*COUNT' 434
SC64CGCT='64-BIT*C*GETMAINS' 441
SC64CHWM='64-BIT*C*STORAGE*HWM' 442
SC64UGCT='64-BIT*USER*STORAGE*GETMAINS' 443
SC64UHWM='64-BIT*USER*STORAGE*HWM' 444
SC64SGCT='64-BIT*SHARED*GETMAINS' 445
SC64GSHR='64-BIT*SHARED*BYTES*GETMAINED' 446
SC64FSHR='64-BIT*SHARED*BYTES*FREEMAINED' 447
TASZIPTM='TASK*ZIP*CPU*TIME' MXG-Created
TASELGTM='TASK*ZIP*ELIGIBLE*CPU TIME' MXG-Created
CPUTONTM='TASK*TOTAL*CPU TIME*ON ZIP' 436
CPUTONCN='TASK*TOTAL*DISPATCHES*ON ZIP' 436
OFFLCPTM='TASK*ZIP*ELIGIBLE*RAN ON ZIP*CPU TIME' 437
OFFLCPCN='TASK*ZIP*ELIGIBLE*RAN ON ZIP*DISPATCHES' 437
ACAPPLNM='APPLICATION IN*APPLICATION*CONTEXT*DATA' 451
ACPLATNM='PLATFORM IN*APPLICATION*CONTEXT*DATA' 452
ACMAJVER='MAJOR VERSION IN*APPLICATION*CONTEXT*DATA'453
ACMINVER='MINOR VERSION IN*APPLICATION*CONTEXT*DATA'454
ACMICVER='MICRO VERSION IN*APPLICATION*CONTEXT*DATA'455
ACOPERNM='OPERATION IN*APPLICATION*CONTEXT*DATA' 456
MPPRTXCD='MPPRTXDC' 449
FCXCWTTM='WAIT TIME*FOR EXCLUSIVE*VSAM CI' 426
FCXCWTCN='WAIT COUNT*FOR EXCLUSIVE*VSAM CI' 426
FCVSWTTM='WAIT TIME*FOR*VSAM*STRING' 427
FCVSWTCN='WAIT COUNT*FOR VSAM*STRING' 427
-TASCPUTM has always included the CPU time on zIIP/zAAPs,
and thus can EXCEED the elapsed time when the specialty
engine is faster than the CP engines, as documented in
Change 29.076, and because previously the TASZIPTM was
not separately recorded in CICSTRAN. Even though 5.1 DOES
have the separate field, I chose to NOT change TASCPUTM,
even though that is inconsistent with the "normal" MXG
implementation of keeping the CP and zIIP/zAAP times in
separate variables, because it seemed changing the value
in TASCPUTM would have caused more impact to you.
-CICSTRAN fields not created in 5.1 (are missing values)
DB2WAITM/DB2WAICN 189
J8CPUTM/J8CPUCN 260
J9CPUTM/J9CPUCN 267
MAXJTDTM/MAXJTDCN 277
CBSRVRNM 311
EJBSACCT 312
EJBSPACT 313
EJBCRECT 314
EJBREMCT 315
EJBMTHCT 316
EJBTOTCT 317
MLXSSCTM/MLXSSCCN 411 (not documented as gone by IBM)
-CICSTRAN fields in 5.1 that have altered meaning:
These fields now include the new GET64 CONTAINER and the
PUT64 CONTAINER data values:
PGGETCCT 323
PGPUTCCT 324
PGGETCDL 326
PGPUTCDL 327
PGCRECCT 328
-CICSEXCE dataset has two new values of EXCMNRIX of
GUDSA - Wait for GUDSA Storage
GSDSA - Wait for GSDSA Storage
-CICS Statistics Interval now defaults to 1 hour versus 3.
-CICLDG variables added:
LDGLLRRO='LIBRARY*LOAD*REQUESTS*RO TCB'
LDGLLTRO='TOTAL*LOADING*TIME*RO TCB'
-CICM variables added:
MNGCECTP='CEC*MACHINE*TYPE'
MNGCECID='CEC*MODEL*NUMBER'
-New STID=62, same as STID=60, outputs CICDS dataset.
Eighteen TCBs exist in TS/5.1, but none are new. The MXG
TCB variables in CICDS dataset all have the two-character
"TCB Name" text in their labels, and the MXG variable's
suffixes (DSG, DS1, DS2 ... for QR, RO, CO ...) are
listed in this table mapping the IBM 5.1 TCB Numbers:
TCB Name: QR RO CO SZ RP FO SL SO SP EP TP D2 S8 L8 L9 X8 X9 T8
IBM TCB NR: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
MXG Suffix: G 2 3 4 5 6 7 8 H M N D B A I J K L
-STID=101 adds two new variables to dataset CICWBG:
WBGATOMS='ATOMSERVICE*REQUESTS'
WBGJVMSV='JVMSERVER*REQUESTS'
Change 30.227 Documentation updates, to give better examples of how to
ADOCRMFI define workloads in RMFINTRV.
UTILWORK
Oct 31, 2012
Change 30.226 -Support for AIX/LINUX NMON data with FRENCH language text
VMACNMON and with fractional numbers with commas instead of the
Nov 1, 2012 expected period, found (so far ONLY) in "BBBP" records.
-Support for MEMAMS Memory Object adds MSxxxxxx variables
to the NMONINTV dataset.
Thanks to Atsou Toulabo, GMF, FRANCE.
Thanks to Giles Fontanini, GMF, FRANCE.
Thanks to Olivier Fy, GMF, FRANCE.
Change 30.225 With more than about 40 workloads defined in RMFINTRV,
ANAL72GO VMXGRMFI could fail due to macro variable string length
ANALDB2R limits on list of variables. And, if you workload prefix
ANALID was too long, VMXGSUM (called by VMXGRMFI) could fail on
ASUM113 truncated variable names, causing variable not FOUND.
MULTIPDB New MXGEXIMSG macro variable replaces all hardcoded
READDB2 arguments so that, when directed by support@mxg.com, you
SMFSRCH can use this syntax
UTILNPRT %LET MXGEXIMSG=YES;
VGETENG to enable (logs) of print lines for diagnostics.
VGETLIBS
VGETOBS
VGETSORT
VGETWKLD
VMACID
VMXGFIND
VMXGINIT
VMXGOPTR
VMXGPRA1
VMXGPRNT
VMXGRMFI
VMXGSRCH
VMXGSUM
VMXGSUM
VMXGUOW
VMXGWORL
Oct 30, 2012
Change 30.224 -Documentation note on SMF backup when execution on ASCII.
ChangeS Change 23.090 provided this technique to back up the SMF
VMXGGETM file when executing MXG on ASCII (and note the file name
Nov 1, 2012 of the backup has the date/time):
DATA _NULL_;
DATE=TODAY();
TIME=TIME();
DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!
PUT(HOUR(TIME),Z2.)!!'-'!!
PUT(MINUTE(TIME),Z2.);
CALL SYMPUT('DATETXT',DATETXT);
RUN;
FILENAME SMF FTP ("'SYS4.SMF.YOUR.DAILY(0)'")
USER='xxxxxx'
HOST='xxxxxxxx'
DEBUG
S370VS
RCMD='SITE RDW READTAPEFORMAT=S BUFNO=35' /*for tape*/
LRECL=32760
PASS='xxxxxxxx';
FILENAME SMFBKUP
"D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&DATETXT";
%LET MACFILE=
%QUOTE(
RDW=LENGTH+4;
BDW=RDW+4;
FILE SMFBKUP RECFM=N LRECL=32760;
PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X
SMFINFILE @;
);
RUN;
%INCLUDE SOURCLIB(BUILDPDB);
RUN;
That is STILL the correct (and only SAFE way) to back up
the file being read, in spite of a post to MXG-L that
reported this error message using that technique:
"ERROR: The '/' INPUT/PUT statement option is
inconsistent with binary mode I/O. The execution of
the DATA STEP is being terminated".
And, that text was found in SAS Note 3404, an ancient
note that was fixed in SAS Version 8.2.
That error message was NOT due to the backup technique;
there was a prior and unrelated syntax error that was the
true cause of that binary mode I/O error message.
But, a subsequent post suggested that RECFM=S370VBS could
be used to create the ASCII backup file, BUT:
YOU CAN NOT USE RECFM=S370VBS on ASCII for OUTPUT.
While you can write with that RECFM with no errors on the
log, THE OUTPUT FILE CANNOT RELIABLY BE READ. Sometimes
it is valid, sometimes it is not, and there is no clue,
until you try to read the backup file.
-VMXGGETM is revised to support RECFM=N write of VBS data
when it is executed on ASCII, so you could use
FILENAME SMFBKUP
"D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&DATETXT";
%VMXGGETM(SMFOUT=SMFBKUP,NRECORD=MAX);
as a standalone program to create a backup of your SMF.
Thanks to Michael Mayne, HHSYS, USA.
Change 30.223 Support for user-created CICS variables TRANSU, PGMU,
UTILEXCL USERU and USERDATU. UTILEXCL must be executed to create
VMAC110 the IMACEXCL to input those fields, and the four IMACICxx
IMACICUW members must be copied into your "USERID.SOURLIB" and the
Oct 26, 2012
Thanks to Randall R. Schlueter, FirstData, USA.
Thanks to Joan E. Nielsen, FirstData, USA.
Change 30.222 IFCID=239 DB2ACCTP observations did not set DB2PARTY nor
VMACDB2 QPACROLL nor QPACRUSM for the ID=101 SUBTYPE=1 records.
Oct 26, 2012
Change 30.221 Example HSM reports 3 and 4, Concurrent HSM Activity and
ANALHSM Concurrent HSM Queued, are now sorted by datetime within
Oct 25, 2012 each HSM Function.
Thanks to Rick Ralston, Humana, USA.
Change 30.220 Support for NDM-CD Subtype CX Certificate Expire subtype
EXNDMCX creates new NDMCX dataset.
IMACNDM
VMACNDM
VMXGINIT
Oct 24, 2012
Thanks to Douglas C. Walter, CitiBank, USA.
Thanks to Brent Turner, CitiBank, USA.
Change 30.219 The mapping of DBID/OBID hex values to the actual name of
ANALDB2R the database or table were not always decoded correctly
VFMT102 by the format created by VFMT102. In some cases IFCID 105
Oct 21, 2012 was written up to 30 seconds AFTER the trace record that
Nov 5, 2012 needed the 105 values, so a format based on timestamps
cannot be used. This iteration creates the format based
on variables SYSTEM DB2SSSID QWHSACE DBID (or DBID OBID).
NOTE: REGION=200M or larger may be required because this
format is MUCH larger; the size is related to the number
of observations in T102S105 and T102S107 datasets.
Nov 4: The Oct 21 iteration could cause duplicate values
error when building the format; NODUPKEY replaced NODUP
to circumvent the error, but this could cause some DBID
and OBID values to remain HEX (i.e., unmapped). We are
still redesigning the entire mapping algorithm but not
in time for today's MXG 30.08. Contact support@mxg.com if
you want the redesigned mapping when it's ready.
Thanks to Alyona Bertneski, JPM Chase, USA.
Change 30.218 In ANALDB2R, INTERVAL=xxxx wasn't supported, causing
ANALDB2R MXGERROR: YOU SPECIFIED INTERVAL=HOUR
Oct 19, 2012 MXGERROR: AND DATETIME=QWACBSC BUT THAT
MXGERROR: DATETIME VARIABLE IS NOT IN THE SUMBY LIST
MXGERROR: VMXGSUM TERMINATED EXECUTION
if you were using MXG 30.05 or earlier. With later MXG
versions INTERVAL= was ignored for the Accounting reports
with no error message. Now, if INTERVAL= is specified,
but the correct datetime variable is not in your SORTBY=
parameter, the datetime variable is added to SORTBY list.
-But for DB2ACCTP, intervals are still calculated based on
QWHSSTCK (the end of the interval), because QPACSCB did
not exist originally. While it could be now used, that
would require significant updates to the ASUM and TRND
members, and it is still possible for the PLAN/PACKAGE
to fall into different intervals.
-Statistic data is always summed using QWHSSTCK; since the
interval duration for statistics in DB2 V10 is now fixed
at one minute, changing to start versus end would not
make much difference.
Thanks to Ron Wells, Springleaf Financial Services, USA.
Change 30.217 -Reading RMF III data on ASCII platform generated INVALID
VMACRMFV data messages when the (new) MXG00 record (created by the
Oct 18, 2012 new ASMRMFV to document its version) was read, but there
were no errors in the other MXG-build RMF III datasets.
-Unrelated, new variable INFILENX contains the DSNAME or
ASCII filename of the input RMFBSAM file being read.
-Macro variable &VMXGJFCB is created to extract the JFCB
when TYPERMFV is executed on z/OS and to specify the
RECFM=S370VBS and LRECL=3270 when executed on ASCII so
those DCB attributes are not required on the FILENAME.
Thanks to James Sterling, DST Systems, USA.
Change 30.216 Updates to MXG code for MVS Solutions Thruput Manager SMF
VMACTPMX subtype 5 record added new fields to the SLMSLPER dataset
Oct 16, 2012 with SLM Job statistics, and corrected the input and the
format for some duration variables that were resolved to
seconds (TIME8. instead of my TIME12.2).
Thanks to Ken Deering, MVS Solutions, Inc, USA.
Change 30.215 z/VM BROKEN CONTROL record error only when MONWRITE input
VMACVMXA files were concatenated (but not always!) due to logic
Oct 16, 2012 error in MTREPR record's SKIP bytes handling.
Thanks to David Campbell, SunTrust, USA.
Thanks to Shannon Collinson, SunTrust, USA.
Change 30.214 Using VXMGFIND to print all datasets obs with found value
VMXGFIND (e.g., all observations with JESNR=12345) selected all of
Oct 11, 2012 the desired observations, but the name of the dataset in
title of each output were off by one dataset - the first
didn't have a dataset name, and the name in the second
title was the name of the first dataset, etc., due to a
mislocated RUN; statement.
Change 30.213 MXG 30.07 only. CICS STID=30 WARNING messages were caused
VMAC110 by incorrectly inserted code, which also corrupted the
Oct 10, 2012 CICLDG statistics dataset.
Thanks to Leonard DiCristofano, Anixter Inc, USA
Change 30.212 Support for APAR OA37016 for zEC12 CRYPTO EXPRESS4S adds
FORMATS a new value 10 for Crypto Processor Type CEX4C, which is
VMAC7072 added to be decoded by the existing $MGRMFCX format, and,
Oct 11, 2012 unrelated, two instances of 'F5'x were changed to dashes.
-New variable R7023MSK='VALIDITY*BIT*MASK' is created in
dataset TYPE7002.
Change 30.211 Change 30.113 accidentally removed the de-accumulation of
VMACDB2 DB2STATS variable QISTCOLS in MXG 30.04, when three other
Oct 9, 2012 QISTxxxx variables were correctly removed. QISTCOLS is
now again de-accumulated.
Thanks to Glenn Bowman, Wakefern, USA.
Change 30.210 Support for APAR PN29124 adds IFCID=366 BIF INCOMPATIBLE.
EX102366 The CHAR(decimal) function in DB2 V10 returns different
FORMATS data than the same function in DB2 V9, and the IFCID=366
IMAC102 records identify SQL source code that MUST be changed to
VMAC102 support the new format. The BIF INCOMPATIBLE option will
VMXGINIT restore the CHAR function to its V9 behavior while your
READDB2 SQL guru's change their code for DB2 V10.
Oct 10, 2012 -READDB2's previous max IFCID of 350 raised now to 450.
Thanks to Tony Anderson, Blue Cross Blue Shield of Alabama, USA.
Thanks to David McGrady, Blue Cross Blue Shield of Alabama, USA.
Change 30.209 Support for APAR OA37826 adds Channel Path Types CIB and
EXTY74HO CFP Coupling Facility data in new TYPE74HO dataset with
FORMATS both Local and Remote Channel Path Data for CIB & CFP.
VMAC74 -New Data Set TYPE74HO:
VMXGINIT R744HAID='HOST*CHANNEL*ADAPTER*ID'
Oct 7, 2012 R744HAPN='HOST*CHANNEL*ADAPTER*PORT'
R744HCHF='R744HCHF*STATUS*FLAGS'
R744HCPI='CHANNEL*PATH*IDENTIFIER'
R744HFLA='R744HFLA*VALIDITY*BIT*MASK'
R744HLAT='CHANNEL*PATH*LATENCY*TIME'
R744HOPM='CHANNEL*PATH*OPERATION*MODE'
R744HPCP='PHYSICAL*CHANNEL*ID*PCHID'
R744HSAP='FOUR*I/O PROCESSOR*ACCESSIBLE'
R744HTAP='CHANNEL*PATH*TYPE*ACRONYM'
Change 30.208 Support for APAR OA37803 which adds Warning Track
VMAC7072 Interrupt Facility.
Oct 6, 2012 -TYPE70EC and TYPE70PR new variables:
SMF70WTI='DURATION*LP WAS YIELDED*DUE TO WTI'
SMF70WTS='WTI-S*RETURNED*WITHIN*GRACE*PERIOD'
SMF70WTU='WTI-S*UNABLE*TO RETURN*IN GRACE'
Change 30.207 Support for APAR OA39993 which adds Interrupt Delay Time
VMAC74 Facility duration.
VMAC79 -TYPE74 new variable:
Oct 6, 2012 SMF74IDT='INTERRUPT*DELAY*TIME*DURATION'
Jan 3, 2012 AVG74IDT='AVERAGE*INTERRUPT*DELAY*TIME*MILLISEC'
-TYPE79 new variable:
SMF79IDT='Interrupt*Delay*Time*Duration'
Change 30.206 Support for APAR OA38660 which adds Storage Class Memory
VMAC71 (SCM) and Pageable Large Pages on EC12 (zEC12) Server,
VMAC75 which are also called "FLASH MEMORY".
VMAC78 -TYPE71 new variables:
Oct 6, 2012 SMF71ASM='MIN*AVAILABLE*NOT USED*SCM BLOCKS'
Nov 13, 2012 SMF71ASV='AVG*AVAILABLE*NOT USED*SCM BLOCKS'
Dec 25, 2012 SMF71ASX='MAX*AVAILABLE*NOT USED*SCM BLOCKS'
SMF71BSA='AVG*BAD*SCM BLOCKS'
SMF71BSM='MIN*BAD*SCM BLOCKS'
SMF71BSX='MAX*BAD*SCM BLOCKS'
SMF71C1A='AVG*HIGH VIRTUAL*COMMON*MEM PAGES'
SMF71C1M='MIN*HIGH VIRTUAL*COMMON*MEM PAGES'
SMF71C1X='MAX*HIGH VIRTUAL*COMMON*MEM PAGES'
SMF71C4A='AVG*HIGH VIRTUAL*COMMON*ON SCM'
SMF71C4M='MIN*HIGH VIRTUAL*COMMON*ON SCM'
SMF71C4X='MAX*HIGH VIRTUAL*COMMON*ON SCM'
SMF71L1A='AVG*1MB FRAMES*CANBE*USED*FIXED MEMOBJ'
SMF71L1M='MIN*1MB FRAMES*CANBE*USED*FIXED MEMOBJ'
SMF71L1X='MAX*1MB FRAMES*CANBE*USED*FIXED MEMOBJ'
SMF71L2A='AVG*1MB FRAMES*NOT USED*IN LFAREA'
SMF71L2M='MIN*1MB FRAMES*NOT USED*IN LFAREA'
SMF71L2X='MAX*1MB FRAMES*NOT USED*IN LFAREA'
SMF71L3A='AVG*1MB FRAMES*IN USE*IN LFAREA*BY FMEMOBJ'
SMF71L3M='MIN*1MB FRAMES*IN USE*IN LFAREA*BY FMEMOBJ'
SMF71L3X='MAX*1MB FRAMES*IN USE*IN LFAREA*BY FMEMOBJ'
SMF71L4A='AVG*1MB FRAMES*CANBE*USED*PAGEABLE/DREF'
SMF71L4M='MIN*1MB FRAMES*CANBE*USED*PAGEABLE/DREF'
SMF71L4X='MAX*1MB FRAMES*CANBE*USED*PAGEABLE/DREF'
SMF71L5A='AVG*1MB FRAMES*NOT USED*PAGEABLE/DREF'
SMF71L5M='MIN*1MB FRAMES*NOT USED*PAGEABLE/DREF'
SMF71L5X='MAX*1MB FRAMES*NOT USED*PAGEABLE/DREF'
SMF71L6A='AVG*1MB FRAMES*USED BY*PAGEABLE/DREF'
SMF71L6M='MIN*1MB FRAMES*USED BY*PAGEABLE/DREF'
SMF71L6X='MAX*1MB FRAMES*USED BY*PAGEABLE/DREF'
SMF71S1A='AVG*HIGH VIRTUAL*SHARED*MEM PAGES'
SMF71S1M='MIN*HIGH VIRTUAL*SHARED*MEM PAGES'
SMF71S1X='MAX*HIGH VIRTUAL*SHARED*MEM PAGES'
SMF71S5A='AVG*AUX SLOTS*HIGH*SHARED MEM ON DASD'
SMF71S5M='MIN*AUX SLOTS*HIGH*SHARED MEM ON DASD'
SMF71S5X='MAX*AUX SLOTS*HIGH*SHARED MEM ON DASD'
SMF71S6A='AVG*HIGH VIRTUAL*SHARED MEM*ON SCM'
SMF71S6M='MIN*HIGH VIRTUAL*SHARED MEM*ON SCM'
SMF71S6X='MAX*HIGH VIRTUAL*SHARED MEM*ON SCM'
SMF71TSA='AVG*4K SCM*BLOCKS AVAIL*TO ASM'
SMF71TSM='MIN*4K SCM*BLOCKS AVAIL*TO ASM'
SMF71TSX='MAX*4K SCM*BLOCKS AVAIL*TO ASM'
SMF71USA='AVG*SCM BLOCKS*IN USE'
SMF71USM='MIN*SCM BLOCKS*IN USE'
SMF71USX='MAX*SCM BLOCKS*IN USE'
-TYPE75 new flag variables are created for bits, but only
SCMPGTYP was added by this APAR - the other bits had not
been previously decoded into flag variables:
MULTEXPO='MULTIPLE*EXPOSURE*DEVICE?'
DEVALTCU='DEVICE HAS*ALTERNATE*CONTROL*UNIT'
DEVVALID='DEVMODEL*IS VALID?'
SCMPGTYP='PAGE*SPACE*TYPE IS*SCM?'
Nov 13: The four variables were added to the KEEP list.
-TYPE78PA dataset, new variables added Dec 25:
R782FIFRMIN ='MIN FRAMES*CAN BE USED*FIXED*MEMOBJ'
R782FIFRNTME='TIME STAMP*OF MIN*FIXED*MEMOBJ'
R782FIFRMAX ='MAX FRAMES*CAN BE USED*FIXED*MEMOBJ'
R782FIFRXTME='TIME STAMP*OF MAX*FIXED*MEMOBJ'
R782FIFRAVG ='AVG FRAMES*CAN BE USED*FIXED*MEMOBJ'
R782PAFRMIN ='MIN FRAMES*ARE USED*PAXED*MEMOBJ'
R782PAFRNTME='TIME STAMP*OF MIN*PGBL/DREF*MEMOBJ'
R782PAFRMAX ='MAX FRAMES*ARE USED*PGBL/DREF*MEMOBJ'
R782PAFRXTME='TIME STAMP*OF MAX*PGBL/DREF*MEMOBJ'
R782PAFRAVG ='AVG FRAMES*ARE USED*PGBL/DREF*MEMOBJ'
-TYPE78PA dataset, these new AVG value variables should
have been created, instead of their TOTL value variables,
but their TOTL variables are still kept, to be safe.
SHBYAVG ='AVG*SHARED*ABOVE 2GB'
TOBYAVG ='AVG*ABOVE 2GB'
COBYAVG ='AVG*64BIT COMMON 2GB'
COMOAVG ='AVG*64BIT*COMMON'
LGMOAVG ='AVG*LARGE*MEMOBJ'
SHBYAVG ='AVG*SHARED*ABOVE 2GB'
SHMOAVG ='AVG*SHARED*ABOVE 2GB'
TOBYAVG ='AVG*ABOVE 2GB'
TOFRAVG ='AVG*1MB*FRAMES'
TOMOAVG ='AVG*64 BIT PRIVATE'
-The APAR lists 79.11 as changed, but the APAR did not
provide any details at that time. This text will be
revised when the APAR text has been updated by IBM.
Change 30.205 Variable ACTVOL is added to TMS.TMS dataset:
TYPETMS5 ACTVOL ='ACTUAL*PHYSICAL*WHERE*VIRTUAL*OFFLOADED'
VMACTMS5 The '20'x bit in FLAG5 is also set when ACTVOL is
Oct 6, 2012 populated, but as that is redundant I did not create a
new variable for that bit.
Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 30.204 Support for APAR OA38980 adds new variable to DCOLCLUS:
VMACDCOL DCAZFS ='ZFS*DATA*SET?'
Oct 6, 2012 and two new variables to DCOLVOLS dataset:
DCVFCYLS='FREE*CYLINDERS*ON VOLUME'
DCVFTRKS='FREE*TRACKS*ON*VOLUME'
Thanks to Michael R. Mayne, Huntsville Hospital System, USA.
Change 30.203 Support for JES3 Main Device Scheduler IAT5210 & IAT5918
ASMTAPEE mount messages adds these new variables to PDB.ASUMTAPE
ASUMTAPE FIRST5210='FIRST*JES3*IAT5210*DATETIME'
VMACTMNT LAST5210='LAST*JES3*IAT5210*RECORD'
Oct 8, 2012 NR5210 ='NUMBER*OF JES3*IAT5210*MESSAGES'
Nov 30, 2012 VOLF5210='FIRST*JES3*IAT5210*VOLSER'
Apr 10, 2013 VOLL5210='LAST*JES3*IAT5210*VOLSER'
FIRST5918='FIRST*JES3*IAT5918*DATETIME'
LAST5918='LAST*JES3*IAT5918*RECORD'
NR5918 ='NUMBER*OF JES3*IAT5918*MESSAGES'
to measure the delay from JES3 MDS Mount/Allocate and the
dismount event for those pre-execution JES3 tape mounts.
The MXGTMNT monitor itself never sees those mounts, which
occur prior to the job's execution on z/OS, but the above
SYSLOG messages, plus the TYPE21 dismount records provide
improved tracking of JES3 mount events.
-ASMTAPEE was updated to create SMF subtype 8 records for
these messages in this enhancement, which is ML-50.
-Only data from the first and last of these JES3 messages
are kept in PDB.ASUMTAPE, but you can create subtype 9
records for each of these records if you need to see all
of them, using the //MXGMSGID DD documented in ASMTAPEE.
-Debugging PROC PRINTs in ASUMTAPE were removed Nov 30.
-Added April 2013:
INCOMPATIBLE: SORT ORDER OF PDB.ASUMTAPE was changed
from BY DEVNR EVENTIME to BY JESNR DEVNR EVENTIME which
could cause WEEKBLD/MONTHBLD to NOTSORTED fail, but only
if your WEEKBLD/MONTHBLD is prior to Change 29.008, 20.01
which made the NOBY option the default to eliminate all
BY statements in those programs). Just remove the
BY statement in your tailored WEEKBLD/MONTHBLD.
Thanks to Jim Dammeyer, State Farm Mutual Auto Insurance, USA.
Thanks to Doug Medland, IBM Canada, CANADA.
Thanks to Paul Williams, The Capital Group, USA.
Change 30.202 -RMF III Enhancements and Fixes
ASMRMFV -Fix for invalid I/O error with messages RMFV033E and
Oct 3, 2012 RMFV007S and subsequent U0998 Abend. There is a time
Oct 6, 2012 window where RMF III has opened a VSAM data set but not
yet written the first sample set. In this situation the
number of sample sets is zero, but ASMRMFV did not
correctly handle the condition and attempted to read a
non-existent sample set causing the error. In this
condition the first and last sample timestamps are zero
indicating a date of 1900.001. ASMRMFV will now
correctly issue message RMFV014I as it does for all
date/time selection mismatch conditions and proceed
without error to the next RMF III data set.
-A new parameter SIZE (alias SZ) is added. This option
provides all the features of the existing NONE option
that suppresses all output but in addition avoids reading
any RMF III tables as input (except the DSH table). The
purpose of SIZE is to provide both RMF III index and disk
space usage to allow optimum sizing of RMF III VSAM data
sets. Options INDEXES and SPACE are forced when SIZE is
coded. The I/O activity and reporting with SIZE is much
less compared to use of NONE. NONE was intended to also
provide a table contents inventory and so may still be
useful in some scenarios.
-The entire DSH table of 32756 bytes is now output not
just the 256 byte header. There is just one DSH record
for each RMF III VSAM data set.
-The Create Date is now added to message RMFV008I for
non-VSAM data sets. The JFCB (Job File Control Block)
that is the source of this data always has the current
date for all VSAM files and so Create Date is suppressed
for them.
-A new message RMFV034I will be produced to show the date
and time of the LAST CLOSE for each RMF III VSAM file.
Although the source field DSIGTODC in the DSH table is
documented as "Time data set was created", it is clear
from the begin and end sample time stamps that this date
stamp is always later than end sample time stamp and so
is consistent with a file being closed, not one that was
just created.
-The SAMPLES FILTERED count in message RMFV103I could be
incorrect when an entire data set was filtered by date
and time selection.
-Prologue documentation in the ASMRMFV source has been
updated to provide detail on the NONE and SIZE
parameters.
-Oct 6: Cosmetic: Message RMFV034I shows OPEN timestamp in
the local time zone, and imbedded blanks in 9 other date
and time fields.
Thanks to Rodger Foreman, Trans Union, USA
Thanks to Susan Graham, CapGemini, USA
Change 30.201 Variables SM1132MT and SM1132MM were blank because a test
VMAC113 for debugging (IF SYSTEM='MVSA' ...) was not removed, but
Oct 4, 2012 they were also not kept until now!
Oct 9. 2012 -Oct 9: Change 30.129 text is now available.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY
====== Changes thru 30.200 were in MXG 30.07 dated Oct 3, 2012=========
Change 30.200 DB2 V10 variable QWHCCV was incorrectly replaced by the
VMACDB2 value in new variable QWHCCTKN when the CTKN offset was
VMACDB2H non-zero. QWHCCTKN is an IP address in this format with
Oct 2, 2012 an IP address, Port Number, and a timestamp:
162.123.25.218.44485.120605112901
-------------- ----- ------------
| | |
| | |-- Unique field ( timestamp real
| |
| |-- Port address
|
|- Requester IP Address
-Only QWHCATYP=8 (REMOTE UOW) obs have QWHCCTKN in several
test SMF files, and many of those =8 observations do not
have a value, so MXG's incorrect value in QWHCCV does not
appear to have been pervasive.
-Previously, there was no "truncated offset" field for
QWHCCV, the Correlation ID, and when IBM added the
truncated offset field for QWHCCTKN, I misread the DSECT
and thought that offset was for the Correlation ID so I
INPUTed the new field at that offset into QWHCCV. I now
realize that that INPUT was for the new Correlation TOKEN
field, QWHCCTKN, which is now correctly INPUTed and KEPT.
-Now that QWHCCV has no truncated offset, it's length is
restored to $12 instead of $128.
Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
====== Changes thru 30.199 were in MXG 30.07 dated Oct 2, 2012=========
Change 30.199 DO NOT USE MXG 30.07 DATED OCT 1 OR EARLIER. THOSE WERE
EXTY70PR TEST ITERATIONS THAT UNFORTUNATELY HAD A SERIOUS ERROR
Oct 2, 2012 AND CREATED ZERO OBSERVATIONS IN TYPE70PR DATASET AND
WAY TOO MANY OBS IN TYPE70SP, DUE TO MY ERROR IN MY QA.
The EXTY70PR member OUTPUT to _WTY70SP incorrectly; that
should have been (AND IS NOW) OUTPUT to _WTY70PR.
====== Changes thru 30.198 were in MXG 30.07 dated Oct 1, 2012=========
Change 30.198 These labels for these variable in VMACNMON are
VMACNMON misleading and incorrect: they indicate "percentages"
Oct 1, 2012 APCPUUSER='PCPU_ALL*USER*PERCENT'
APCPUSYS ='PCPU_ALL*SYSTEM*PERCENT'
APCPUWAIT='PCPU_ALL*WAIT*PERCENT'
APCPUIDLE='PCPU_ALL*IDLE*PERCENT'
APCPUBUSY='PCPU_ALL*BUSY'
but they are PHYSICAL CP counts: Their labels are now
corrected to:
APCPUUSER='PHYSICAL*CP*USER'
APCPUSYS ='PHYSICAL*CP*SYSTEM'
APCPUWAIT='PHYSICAL*CP*WAIT'
APCPUIDLE='PHYSICAL*CP*IDLE'
APCPUBUSY='PHYSICAL*CP*ENTITLED'
Thanks to Lennon L. Marchang, Coca-Cola Company, USA
Change 30.197 Support for user-created CICS variables TRANSU, PGMU,
UTILEXCL USERU and USERDATU. UTILEXCL must be executed to create
VMAC110 the IMACEXCL to input those fields, and the four IMACICxx
IMACICUR members must be copied into your "USERID.SOURLIB" and the
IMACICUT comment block therein removed.
IMACICUU
IMACICUV
Sep 25, 2012
Thanks to Alex B. Nielsen, KMD, DENMARK.
Thanks to Noach Holger, KMD, DENMARK.
Change 30.196 Variable QW0247DA was truncated to 8 bytes because it was
VMAC102 assigned $HEX16. format and only the first 200 bytes were
Sep 24, 2012 input with $VARYING200., but actual data length can be up
to 4096, so the INPUT and FORMAT were revised.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, Australia
Change 30.195 Optional DB2 variable CORRNAME is created in the _DB2CORR
VMACDB2 macro defined in VMACDB2, with CORRNAME=SUBSTR(QHWCCV) so
Sep 24, 2012 its length was $12 when QWHCCV is $12. But Change 30.032
(incorrectly!) increased QWHCCV to $128, causing CORRNAME
to increase, which then could print warning messages
about MULTIPLE LENGTHs. Adding a LENGTH CORRNAME $8;
statement to the MACRO _DB2CORR definition in VMACDB2
corrected. However, you should copy that definition into
your IMACKEEP member so the same definition is always
used at your site, and because some sites have needed to
tailor the actual substringing.
-Change 30.200 restored QWHCCV to the correct $12 length.
Thanks to Alyona Bertneski, JP Morgan, USA.
Change 30.194 DB2 QMDAACCT field LENACCT1=246 caused the error message:
VMACDB2 INVALID THIRD ARGUMENT for SUBSTR(QMDAACCT,BEG,LENACCT1)
Sep 21, 2012 because the QMDAACCT INPUT was $VARYING200. LENACCT1 so
the length of QMDAACCT was restricted by the $VARYING200.
Thanks to Stephen Donahue, Fidelity Investments, USA.
Change 30.193 The MXGTMNT (ASMTAPEE) Tape Mount and Tape Allocation
ASMTAPEE and SYSLOG monitor program has been enhanced. The ML-49
Sep 20, 2012 level removes the requirement of having the tape UCBs
PINNed. This eliminates the previous requirement that
your operators had to stop and restart the monitor when
your tape drive configuration changed, and it eliminates
the need for documenting that procedure for operators.
The new monitor will now detect that a configuration
change has been successfully completed and determine
whether or not a tape device was involved. If so, the
monitor will automatically suspend processing, rescan the
tape device's UCBs, and restart monitoring without user
intervention. Old and new levels of MXGTMNT can exist on
multiple z/OS systems that share tape devices. Systems
with ML-49 will automatically detect the change, systems
with prior versions will still need operator intervention
when the tape device configuration is changed.
Change 30.192 zVM MONWRITE dataset VXAPLSL0 Linux Processor Utilization
VMACVMXA variables PCTSYST PCTIDLE PCTINTR PCTSOFT PCTIOWT were
Sep 19, 2012 all incorrect, because the right-hand variable for each
Sep 20, 2012 of those percent calculations was NICEMODE instead of the
individual xxxxMODE variable.
-Variables PCTUSER/PCTNICE/USERMODE/NICEMODE were reversed
in the INPUT statement so they too were wrong.
-New PCTSTOL/STOLEMODE is created with the time when the
z/VM Hypervisor had stolen the clock ticks.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.191 JOB to create/update the MXG FORMAT library when you use
BLDFORMT CONFIMXG configuration with // EXEC SAS93, needed because
Sep 18, 2012 CONFIMXG sets DISP=SHR for LIBNAME LIBRARY:
//S1 EXEC SAS93,CONFIG='MXG.SOURCLIB(CONFIMXG)'
//MXGNAMES DD DSN=MXG.USERID.SOURCLIB(MXGNAMES),DISP=SHR
//SYSIN DD *
LIBNAME LIBRARY CLEAR;
LIBNAME LIBRARY "&MXGFORMT" DISP=OLD;
%INCLUDE SOURCLIB(FORMATS);
Change 30.190 z/VM 6.1 data caused BROKEN CONTROL RECORD error because
VMACVMXA the length of STSI in VXMTRTOP was increased from 40 to
Sep 17, 2012 at least 152 and MXG had $VARYING40., now $VARYING255.
Change 30.189 Use of %CMPRES in VMXGSUM was removed by Change 29.154 to
VMXGSUM avoid APPARENT INVOCATION OF CMPRES MACRO messages (z/OS)
Sep 17, 2012 but unfortunately Change 30.158 (MXG 30.06) slipped its
use back in VMXGSUM, so this change was going to just
remove it and live with lots of blank in the error text
we were compressing. However, we have discovered that
the %CMPRES macro can be replaced using %SYSFUNC:
%LET MESSAGE=%SYSFUNC(COMPBL(&MESSAGE));
which eliminated the reference to SASAUTOS.
However, the actual cause of this error is that your MXG
was incorrectly installed; either your JCL or your CONFIG
options are preventing MXG from accessing that macro from
the SAS-provided SASAUTOS library. Change 28.128 lists
the many ways to correct this install error, but you MUST
correct your JCL/CONFIG, as many other MXG programs
depend on SASAUTOS. VMXGSUM is protected ONLY because
%CMPRES again was not required and could be removed, and
because VMXGSUM is used in BUILDPDB and ASUMxxxx members
that build PDBs.
Change 30.188 Support for SMF 119 Subtypes 48 thru 52 populate the SMTP
FORMATS variables in those existing datasets.
VMAC119 -Oct 1: some datetime variables were not length 8.
Sep 16, 2012
Oct 1, 2012
Thanks to Randy Shumate, Reed Elsevier Technical Services, USA.
Thanks to Tom Erwin, Reed Elsevier Technical Services, USA.
Change 30.187 Variables CMF06SPL & CMF06SPH are input &PIB.2.1 because
VMACCMF they were ten times too large in CMF06GDA dataset.
Sep 15, 2012
Thanks to Alfred Sau, TJX, USA.
Thanks to Kevin Luey, TJX, USA.
Change 30.186 Two "MXG" DB2 reports are added that are not in DB2PM.
ANALDB2R -MXGACC01 is an interval summary report with your choice
Sep 15, 2012 of selection criteria that provides total and average
Sep 17, 2012 values for the important CPU and suspend and get-page
variables for the buffer pools with average and max
elapsed times. MXGACC01=YES creates a summary by
QWHSSTCK QWHSSSID QWHCATYP and QWHCAID. The datetime
value will reflect the value in the interval parameter.
If you use an interval of DATE/WEEK/MONTH the format of
QWHSSTCK is adjusted to DATETIME7. and any other interval
value it is adjusted to DATETIME13. If no interval is
specified it is adjusted to datetime16.
Example 1:
%ANALDB2R(MXGACC01=YES,INTERVAL=DATE,
PMACC01=NO,PMACC02=NO,PMSTA02=NO);
creates a summary of all DB2ACCT records in the input
PDB.DB2ACCT dataset, at date interval.
Example 2:
%ANALDB2R(MXGACC01= IF QWHCATYP=4; ,INTERVAL=DATE,
PMACC01=NO,PMACC02=NO,PMSTA02=NO);
creates a summary of all CICS DB2 account records with
an interval of date.
-MXGACC02=YES creates an unsorted detail report for every
record in DB2ACCT. Given the volume this is most likely
NOT what you want to do, without some selection criteria.
Example 1:
%ANALDB2R(MXGACC02=IF ELAPSTM GT 60 AND QWHCATYP=4;,
PMACC01=NO,PMACC02=NO,PMSTA02=NO);
creates the detail report, but only for CICS DB2 that
executed for over 60 seconds.
Thanks to Ron Wells, Springleaf Financial Services, USA.
Thanks to Richard Brooks, Springleaf Financial Services, USA.
Change 30.185 -VFMT102 is invoked by READDB2/ANALDB2R to build formats
ANALDB2R to decode the hex DBID and OBID values in the DB2 IFCID
READDB2 105/107 records, but it could be executed many times if
VFMT102 multiple IFCIDS or multiple reports were requested. This
VMXGINIT change prevents multiple executions within a single pass
Sep 15, 2012 of data by setting the global macro variable VFMT102 when
it is run the first time, and testing it to prevent the
re-execution. If ANALDB2R/READDB2 is restarted in the
same SAS session (possibly pointing to different data),
VFMT102 will be re-executed.
-Variable QW0145LN is printed instead of QW0145LO and $4.
format is added for QW0145SC in ANALDB2R audit reports.
Change 30.184 New INCODE= parameter added to permit input selection.
ANALINIT For example:
Sep 12, 2012 %ANALINIT(INCODE=IF DATEPART(READTIME) GE TODAY()-1;);
would report on only jobs submitted since yesterday.
Change 30.183 MXG 30.05/30.06. PROC FORMAT overlapping range error can
DOC occur with READDB2/ANALDB2R. Change 30.140 removed the
Sep 15, 2012 datetime from the format, but duplicates can exist if the
input spans a very large time frame. VFMT102 in 30.04 or
earlier can be used, so it is stored in the new VFMT102X,
created ONLY so that support@mxg.com can send that one
(renamed) member if you encounter the error. The VFMT102
was altered in Change 30.185 so it cannot be sent without
sending additional members to circumvent this error.
But: VFMT102X was removed in MXG 30.30.
Change 30.182 Support for zNEXT EC12 processors with 101 engines.
VMAC7072 There are no new variables kept in TYPE70 since all of
Sep 8, 2012 the CPU-specific variables for CPU 64 or higher have been
output in TYPE70EN dataset since Change 28.175.
Change 30.181 The "Split 70" logic did not provide exits for four data
EXTY70EC sets TYPE70EC, TYPE70EL, TYPE70EN, and TYPE70SP because
EXTY70EL they were thought to be internal and temporary, but they
EXTY70EN now have exits implemented so that users can make changes
EXTY70SP to those four datasets if needed.
VMAC7072
Sep 7, 2012
Thanks to Ruth Leonhardt, Xerox, USA.
Change 30.180 -Two problems both found in testing that does not impact
VMXGSUM the output but can improve efficiency of execution.
Sep 7, 2012 Case 1:
%VMXGSUM(INDATA=PDB.DB2ACCT,
OUTDATA=DB2SUM,
SUMBY=QWHSSSID,
SUM=DB2TCBTM,
MAX=MAXCPU,
INCODE=MAXCPU=DB2TCBTM;
);
In this case, the MXGSUM1 dataset contained all 500+
variables from DB2ACCT when only 3 were needed, because
the KEEP= list was not being applied to the output
dataset. Now, all variables in the parameter lists is
added as a KEEP statement to reduce DASD space required.
Case 2:
%VMXGSUM(INDATA=PDB.DB2ACCT,
OUTDATA=DB2SUM,
SUM=DB2TCBTM,
MAX=MAXCPU
);
In this case, the MXGSUM2 dataset was created by the
SORT and since there was no INCODE, the MAXCPU variable
did not exist so the PROC MEANS failed with a variable
not found error. Now, the KEEP logic after the SORT is
NOT suppressed when there is no first DATA step.
-Cosmetic. Deletion of temporary datasets used during the
course of VMXGSUM moved from the end to the points in the
code where they are no longer needed avoiding confusion
of the programmer on when/where they should be deleted.
Change 30.179 Formula changes from John Burg's SHARE presentation. For
ASUM113 the z196 (VN=2) 0.59 replaced 0.57, 1.67 replaced 1.6, &
VMAC113 0.61 replaced 1.00; the z10 (VN=1) 0.31 replaced 1.00.
Sep 3, 2012
Sep 17, 2012
Change 30.178 -Using a numeric variable in your SORTBY= tailoring option
ANALDB2R caused ERROR 48-59 citing PUT @1 &SORT $CHAR16 text. That
Sep 2, 2012 $CHAR format is not only NOT needed here (prints SORTBY=
Sep 4, 2012 variable's value, format not needed because all possible
variables here are MXG-formatted), it is THE PRESENCE of
the $CHAR format that causes this error, so its REMOVAL
eliminates this unintended consequence and oversight, and
now numeric variables like CONNTYPE and QWHCATYP that
exposed the error can be used in your SORTEDBY list, and
they will be added in a new QA test of ANALDB2R.
-In testing this change it was discovered that if you
ran PMACC03 without all of the input datasets (DB2ACCTP,
DB2ACCTB, DB2ACCTG) it would fail calling ASUMDB2p/b/g
members for those datasets. If the datasets do not exist
now, there will be an MXGNOTE printed on the log telling
you what was found, with processing to continue without
the missing datasets.
Thanks to Howard L. Curtis, Duke Energy, USA.
====== Changes thru 30.177 were in MXG 30.06 dated Sep 1, 2012=========
Change 30.177 SAS 9.2 z/OS ONLY VGETOBS didn't recognize tape datasets.
VGETOBS On z/OS, SAS 9.2 returns a blank in DICTIONARY.TABLES for
Aug 30, 2012 the number of OBS in a tape dataset, which caused VGETOBS
to return a blank value, but both SAS 9.1.3 and SAS 9.3
returned a bogus set of non-blank characters that proved
there was a tape dataset, so VGETOBS returned a one value
(it found a tape dataset), and VGETOBS could print a log
message that it had detected non-blank non-numeric text,
(but only if the NOEXIMSG internal option was enabled to
print suppressed log notes). Now, a blank value invokes a
new test (VGETDSN length GT 0) for the dataset name that
is used to return a value of one for a tape dataset.
Thanks to Robert Stoffregen, Great Lakes Educational Loan Svcs, USA.
Change 30.176 -Some cosmetic changes to better document the records that
ANALDB2R are being reported, and new options for the AUDIT= parm:
Aug 28, 2012 AUDIT=DML < runs as it currently does uses 143 and 144
Aug 31, 2012 AUDIT=DMLREAD - processes only IFCID 144 for DML
AUDIT=DMLWRIT - processes only IFCID 143 for DML
and a missing semicolon was found.
-Requesting PMACC02=YES by itself, after reading SMF plus
executing the ASUMDB2x members, resulted in overlaying
many old-style macros that caused error messages. Those
old-style substitution macros are now cleared in PMACC02.
Change 30.175 Support for IFCID=271 DB2 AUDIT PERMISSIONS trace record.
VMAC102 Dataset existed but none of the IFCID-specific fields
Aug 28, 2012 were input.
Change 30.174 -Allocation utilities VMXGALOC & VGETALOC permitted 8-byte
VGETALOC dates formats for mmddyy, ddmmyy, and yymmdd, but mmddyy
VMXGALOC and ddmmyy generate slashes in the constructed directory
Aug 28, 2012 names; this change allows 6 8 and 10 byte formats for the
Sep 16, 2012 mmddyy and ddmmyy but will replace them with the formats
mmddyyd and ddmmyyd that use a - rather than a /, like
the yymmdd format that already uses a - as documented.
-VGETALOC uses %LEFT %macro supplied by SAS in SASAUTOS
directory and MXG options in AUTOEXEU.SAS or AUTOEXEC.SAS
include SASAUTOS and MAUTOSOURCE to "autocall" it, but
%LEFT was not actually required in VGETALOC, so it was
removed so VGETALOC would not fail even if the site did
not have their SASAUTOS correctly allocated in AUTOEXEU.
-GETDATERANGE= parameter will now accept a number of days
relative to today to search. For example:
%VGETALOC(GETDATERANGE=-5 -9,BASEDIR=C:\MXG,
DATEFMT=YYMMDD.);
will look for directories in C:\MXG with dates of
12-09-06 thru 12-09-02 inclusive.
There is now also an MXGNOTE if any directories are not
found.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 30.173 WARNING: "INVALID QMDA SEGMENT ACCOUNT values are blank"
VMACDB2 for records with QMDALEN=258, but QMDAASLN=110 (so there
Aug 27, 2012 really were only 110-56=54 possible data bytes remaining)
were printed because MXG incorrectly used QMDASFLN=247 as
the length of accounting data. But these records don't
contain JOB accounting data: text after QMDASFLN is an
exact repeat of the first 28 bytes of the QMDA segment,
QMDAPTYP,QMDAPVER,QMDAPREL,QMDAPMOD, and QMDAPLAT.
Now, MXG uses QMDAASLN instead of QMDASFLN to print any
warnings (so these false positives won't print), and the
text that follows QMDASFLN is INPUT into QMDAACCT based
on QMDAASLN. But, since QMDAACCT has never been KEPT in
PDB.DB2ACCT this change was really just cosmetic so the
false warning won't be printed on the log.
Thanks to Paul Billick, QVC, USA.
Change 30.172 -RMF III Enhancements, more:
VMACRMFV -New variables are added to the ZRBCPU file:
Aug 28, 2012 CPUCAPAD CAPACITY*ADJUSTMENT*INDICATION
CPUCAPRS CAPACITY*CHANGE*REASON
CPUDTIME TIME*DELTA*BETWEEN 2*DIAG CALLS
CPUIMMSU IMAGE*CAPACITY*MSU*LIMIT
NOTE: CPUDTIME will be missing for LPARs running as VM
Guests.
-New variables are added to the ZRBLCP file:
LPARCLUS LPAR*CLUSTER*NAME
LPARGRPM GROUP*MAXIMUM*LICENSE*UNITS
LPARGRPN CAPACITY*GROUP*NAME*FOR*LPAR
LPARONCS CENTRAL*STORAGE*ONLINE*IN MB
LPAROSNA OS*INSTANCE*NAME
LPARUPID USER*PARTITION*ID
NOTE: Variables LPARCLUS, LPARGRPN, LPARGRPM, LPARONCS
require RMF Monitor III data at the z/OS 1.12 Level to
be populated.
-Change 29.013 for CPCGRPLM, text and the INPUT statement,
were both reversed; the four byte variable is input first
and then the reserved four bytes are skipped.
Change 30.171 I had removed references to CICS stats dataset CICMNR, as
VMXGINIT IBM had never externalized that DSECT, so MXG had never
Aug 27, 2012 created any observations, and because it kept showing up
as an exception on QA reports. However, I also removed
the dataset token macro variables &PCICMNR and &WCICMNR
from VMXGINIT, which cause UNRESOLVED MACRO ERROR when
the new VMXGINIT was used with MXG 30.02 or earlier.
I should never have removed those macro variables and so
they are restored to be defined in VMXGINIT.
Thanks to Pat Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
Change 30.170 Large increase in CICLDR observations count, 1,700,000,
EXCICLDR with only 70,000 CICSTRAN observations; there is one obs
Aug 27, 2012 for each program that has been active, but almost all of
the observations have zero Fetch Count (LDRFC) so this
change now output CICLDR observations ONLY if LDRFC is
no zero; that test is located in the EXCICLDR exit member
in case you ever want to change and output them all.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 30.169 -Dataset T102S083, IFCID=83, always had zero observations
FORMATS due to an LE test for QWHSRELN that should have been GE.
VMAC102 -IFCID=145 record with unexpected QWT02R1L=0 ABENDed with
Aug 25, 2012 invalid DO loop value. The records are continuations for
Oct 12, 2012 an SQL command with a total of 98,567 characters, so that
multiple SMF record are written, and the continuation SMF
records do not contain the expected R2O segment, so MXG's
logic was revised. However, a problem has been opened
with DB2 Support because the QW0145LE length-field is not
correct, and there is no explicit offset field to the SQL
text in both the initial and continuation records, so the
MXG input is heuristic based on the available records and
the actual SQL text length in each observation is in the
MXG-calculated QW0145LNTXT variable.
-Oct 12: IBM APAR PM74186 corrects the SQL length error.
-These new-in-DB2-V10 QW0145 fields are INPUT and kept:
QW0145IS QW0145SI QW0145OBNUM QW0145ACNUM
QW0145LL QW0145LNTXT
and format $MGD145I decodes the Isolation Level QW0145IS.
Thanks to Chuck Hopf, Independent Consultant, USA.
Change 30.168 Enhancement to ASM program that recreates RECFM=VB or VBS
ASMDBLKU data from downloaded ASCII "RECFM=U" that is now reloaded
Aug 24, 2012 back to z/OS into 32760 byte chunks that ASMDBLKU reads
Aug 29, 2012 to reconstruct the original VB/VBS file (perhaps so you
can terse it and send it on to a vendor), for sites that
don't have SAS on z/OS (when you would instead use the
MXG UDEBLOCK program to recreate valid VB/VBS files).
-JCL PARM field values of PARM=VB or PARM=VBS are now
supported. The default is VBS if no PARM field is coded.
PARM=VB creates RECFM=VB,LRECL=32756,BLKSIZE=0, while
PARM=VBS creates RECFM=VBS,LRECL=32760,BLKSIZE=0 as in
prior versions of ASMDBLKU. Any other PARM field values
will result in error message DBLKU29S and termination
with Return Code 16.
-New message DBLKU29I shows PARM field value if present.
-Message DBLKU25I now also shows the average LRECL of the
input SMFIN file.
-Message DBLKU26I now also shows the average LRECL of the
output SMFOUT file.
-New message DBLKU27I shows the number of input SMFIN file
records that were read at the minimum and maximum LRECL
values. This provides an idea if the record lengths on
input were biased toward these values.
-New message DBLKU28I shows the number of output SMFOUT
file records that were written at the minimum and maximum
LRECL values. This provides an idea if the record
lengths on output were biased toward these values.
-Maximum LRECL value for the output SMFOUT file was
incorrect in message DBLKU26I.
Change 30.167 MXG 30.04-30.05. The Debugging PUT _N_= YYYYDDD= at line
VMACIMS 3826 is deleted, to eliminate the unwanted log messages.
Aug 24, 2012
Thanks to David J. Schumann, Blue Cross of Minnesota, USA.
Change 30.166 Change 30.153 supported keeping PROGRAM and PROG1-PROGnn
ASUMCICX variables in PDB.ASUMUOW, but its tailoring instructions
ASUMUOW were incomplete, and you may need this updated IMACUOW.
IMACUOW To add PROGRAM (and optional PROG1-PROGnn variables):
VMXGUOW - you must update ASUMUOW to add (only) variable PROGRAM
Aug 24, 2012 to the MACRO _KUOWIDC definition,
- you must update ASUMUOW to add PROGRAM, plus any of the
PROG1-PROGnn variables that you want kept, into your
MACRO _KUOWPTH definition,
- if the PROGRAM name you want/need isn't the PROGRAM in
that last CICSTRAN in this UOW, then you will need to
use this new IMACUOW tailoring and start with Case 5 as
your MACRO _TRANUOW selection, but be aware there still
could be additional site-dependent mods required.
This example adds PROGRAM and PROG1-PROG3:
%LET MACKEEP=%QUOTE(
MACRO _YESOBS %
MACRO _NOOBS %
MACRO _KUOWPTH
EXECAPPL PROGRAM PROG1-PROG3 %
MACRO _KUOWIDC
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
PROGRAM
%
);
%INCLUDE SOURCLIB(VMXGUOW);
_NOOBS
OPTIONS NODSNFERR NOVNFERR;
_SUOWCIC /*SORT CICSTRAN DATA */
_SUOWDB2 /*SORT DB2 DATA */
_SUOWMQ /*SORT MQ SERIES DATA */
_SUOWSPN /* CREATE ASUMUOW DATASET */
%VMXGUOW;
_YESOBS
OPTIONS DSNFERR VNFERR;
If you use ASUMCICX to summarize the PDB.ASUMUOW CICS in
PDB.CICS output dataset, you may need to add PROGRAM to
the _BSUxxxx macro, as also now documented in comments.
The only code changed in this change was in IMACUOW, but
that is only the addition of the new Case 5 example.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 30.165 Cosmetic. Existing $MGTMDAC format assigned to QW0142AC,
VMAC102 to decode A/C/D to ALTER/CREATE/DROP. Note that when an
Aug 23, 2012 MXG $MGxxxxx character format is assigned to a variable,
that variable must be in a LENGTH statement with the
input length; in the absence of a LENGTH statement, the
old $1 character variable is changed to the length of the
longest text in the $VALUE statement for that format.
Change 30.164 Support for six Tandem Prognosis data files creates these
EXTAPCPU six datasets;
EXTAPIPU
EXTAPJOB DDDDDD MXG MXG CREATED
EXTAPOBJ DATASET DATASET DATASET FROM
EXTAPPHY SUFFIX NAME LABEL INFILE
EXTAPVOL
IMACTAPR TAPCPU TAPRCPU TANDEM PROGNOSIS CPU TAPRCPU
TYPETAPR TAPIPU TAPRIPU TANDEM PROGNOSIS IPU TAPRIPU
TYPSTAPR TAPJOB TAPRJOBS TANDEM PROGNOSIS JOBS TAPRJOB
VMACTAPR TAPOBJ TAPROBJECT TANDEM PROGNOSIS OBJECT TAPROBJ
VMXGINIT TAPPHY TAPRPHYSVOL TANDEM PROGNOSIS PHYSVOL TAPRPHY
Aug 24, 2012 TAPVOL TAPRVOLUME TANDEM PROGNOSIS VOLUME TAPRVOL
JCLTEST9
Aug 26, 2012 The TYPETAPR or TYPSTAPR members will create all six MXG
Aug 31, 2012 datasets, reading each of the six input files, but the
Sep 25, 2012 individual datasets can be created with the _Tdddddd
to create and the _Sdddddd token to sort each one. See
examples in comments in VMACTAPR.
-Sep 25: DD MON YYYY HH:MM:SS format for CPU001 supported.
-These problems need to be resolved by Prognosis vendor:
JOBS fields: 014,034,040-044,082,083:
a. Invalid values in 014 - IR_ELAPTIME_STRING
1:29
109-05:50:31
48
b. Invalid values in 034 - IR_STARTTIM_STRING
Values of 19 AUG 2012 and 02 MAY 2012 but the
IR_STARTTIM_TIMESTAMP is the same these records.
c. What are the units, where's the decimal, one obs has:
040 IR_SENDRESP value 0.0185
042 IR_PERFORM value 0.0104
043 IR_RESPTIME value 0.0185
044 IR_CPUSECS value 133877 - if in microseconds,
then 0.133877 is larger than response.
d. Range of values are strange:
082 IR_SEQNUM - 1617862657, 8, and 1628929
083 IR_ANCSEQNO - 1617861633, 0, and 1895169
VOL fields: 061,062,063
e. 061 IR_FULLTIME_STRING 21 OCT 2605: 20:52:57
062 IR_FULLTIME_TIMESTAMP 0
063 IR_FULLTIME_GMT_OFFSET 0
CPU fields 001/002 string and timestamp inconsistency:
f. CPU has IR Time String format 8/20/12 with the time
0:00 (no seconds), but format 20 Aug 2012 0:00:00 is
used in the other records.
g. CPU has IR Timestamp value 2.12212E+17, which doesn't
have enough digits to decode correctly; other records
have 212212195260000000 microseconds, which does have
enough digits and after adding the Tandem constant to
convert from proleptic time, is a valid GMT datetime.
-Notes on data structure issues that are circumvented:
-The record delimiter in the tandem file is the unix "LF"
but that is changed to "CRLF" if the file is copied to a
Windows platform. Macro variable MXGCRLF transparently
sets the TERMSTR option of the INFILE statement to use
the correct delimiter. It is set to TERMSTR=CRLF on WIN
platforms, to TERMSTR=LF on all other ASCII platforms,
and it is blank on z/OS. It can be changed with %LET.
-The clue you have the wrong record delimiter is an error
"ARRAY EXCEEDED" that prints the first two records where
you can see the text date field after the last IR header
name is listed as another field in that first record.
-The JOBS "comma-delimited" file has double quotes around
all character fields, and some contain embedded commas,
which required special handling due to MXG's use of SCAN
function which has no DSD option. A vendor option to
to change the delimiter to a tab would have been nice.
Double quotes were removed, and the commas restored.
-GMT Offset is not provided in the IPU record.
-All fields with "PERC" are labeled (MXG-style) "PCT".
Change 30.163 Windows IIS Server Log record with strange URIQUERY value
VMACWWW C63BCB3DB05CA94A1ECF2B1C13C048097E3456C966691FE6EEB4168
Aug 21, 2012 D55EB32905A6221CB8CA5C525
Sep 28, 2012 that did not contain the expected equal sign caused MXG
to loop; that unexpected text value is now protected.
-Data records with ^M (CR) were created when IIS file was
moved to AIX could be stripped using DOS2UNIX command,
but can also be read with MXG using
%LET MXGCRLF = TERMSTR= CRLF ;
before the %INCLUDE of TYPEWWW, because this change added
&MXGCRLF in the INFILE statement in VMACWWW.
Thanks to Xiaobo Zhang, FISERV, USA.
Change 30.162 Documentation. The RACF field AUDITFID is MXG variable
VMAC80A RACF264 in RACF event datasets TYPE8028/29/30/44/45/8055,
VMACRACF created from SMF 80 records, a 16-byte $HEX32 formatted
Aug 21, 2012 variable because it contains both hex and text:
e.g.: 'C8C6E2F0F0F93D0B00000000004D385B'X.
and the RACF field AUDITFID is MXG variable AUDITID in
dataset RACF0900 from IRRDBU00 RACF UNLOAD UTILITY data,
a $32 character variable with the above hex as text.
Both variables have been in MXG for years, but I have
added "AUDITFID" text to both variable's label.
Thanks to Mark Jacobs, Time Customer Service, USA.
Change 30.161 -RMF III Further Enhancements:
ASMRMFV -A new message RMFV033E is issued when a VSAM Read Error
Aug 19, 2012 occurs to show the current and maximum Relative Record
Number, RRN, of the RMF III record being read, and the
return/reason codes from the failed read operation. This
message will aid in the investigation of sporadic VSAM
read I/O errors that go away when ASMRMFV is rerun. We
will use these messages to circumvent the error.
-NOTE: We have never had a VSAM Read error repeat with a
rerun; if you error with ABREAD please add a //SYSUDUMP,
and send the dump to support@mxg.com so we can resolve.
-The SHOWCB macro calls that collect RMF III VSAM file
attributes have been consolidated to a single call to
reduce code path length.
-New parameter ABREAD/NOABREAD lets you control ASMRMFV's
action when a VSAM read I/O error does occur:
-ABREAD is the default and duplicates the current ASMRMFV
behavior: a USER 0998 abend occurs on the first instance
of a VSAM read I/O error and no further data is written
to the RMFBSAM output file by ASMRMFV. Alias is ABR.
-NOABREAD suppresses the above abend and the action taken
depends on the data being read. Alias is NOABR. On the
first read of an RMF III VSAM data set the action is to
close this VSAM dataset and then open the next RMF VSAM
file (if any). Otherwise, if the error occurs on a
subsequent read for sample set data, the problem sample
set is skipped and ASMRMFV attempts to read the next
sample set from the same data set (if any).
-ASMRMFV ends with Return Code=12 if NOABREAD is in
effect and a read I/O error has occurred.
-Program prologue documentation is updated to discuss
ABREAD and NOABREAD and new Return Code 12.
-With either ABREAD or NOABREAD, the output RMFBSAM file
is likely to be missing data after a read I/O error.
-NOTE: When ASMRMFV is being executed under the CLRMFV
CLIST, the abend (if ABREAD in effect) is trapped, and
with either ABREAD or NOABREAD, CLRMFV will eventually
end with Return Code=12 after a VSAM read I/O error.
You could use the JCL COND parm to test for RC=12 in the
subsequent PDB build, if you want to also terminate the
creation of the RMF III PDB datasets after a VSAM error.
Thanks to Rodger Foreman, TransUnion, USA
Thanks to Betty Wong, Bank of America, USA
Change 30.160 -ASMIMSL7: ASMIMSL6, to bypass 0C7 ABEND due to ARRVDATE
ASMIMSL7 containing invalid Packed Decimal data, by skipping the
ASMIMSL8 0C7'ing-records so the rest of the log can be read. If
Aug 18, 2012 invalid ARRVDATE is found, a new error "NOPD" message
Aug 30, 2012 will be written to the job log with the first 25 bytes of
the record in hex. Since we have added this diagnostic,
no reports of NOPD messages have been reported.
-ASMIMSL8: ASMIMSL7 ABEND 0C4 occurred when an INQUEUE
record had zero record length in the first four bytes, in
a record that was to be discarded due to other errors
(dupe key). This iteration deletes the defective record
without the 0C4 ABEND.
-We have been unable to replicate either the 0C4 or 0C7
condition with files from three runs, so it appears the
source is a corrupted INQUEUE file, and since a VERY
small number of records are being recycled, the safest
solution now would be to eliminate the use of INQUEUE
for a few cycles to confirm that was the culprit, and
then it can be reintroduced while watching the job logs
for MXG error messages, in case the corruption reoccurs.
Change 30.159 Support for Microsoft Exchange 2010 incompatible changes
VMACNTSM to MSEXCHANGEIS and MSEXCHANGEIS MAILBOX objects. Creates
Aug 18, 2012 variables MSIS0001-MSIS0051 MSISCQTH in MSEXCHIS dataset,
and in dataset MSEXCHPU variables MSPU0001-MSPU0074 and
new per-second rate variables MSGDLVPS MSGRECPS MSGSNTPS
MSGSUBPS (whose new per-sec values are also converted to
per-minute and stored in the existing per-minute
variables MSGDLVPM MSGRECPM MSGSNTPM MSGSUBPM).
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 30.158 -VMXGSUM in 30.05 could leave temporary datasets KEEPDATA
VMXGSUM KEEPERS VAR1 VARS or VAR2 in the //WORK library, which
Aug 15, 2012 had no impact on your MXG programs, but as they were also
Sep 4, 2012 left behind in the MXG QA job, they were seen as "real"
MXG datasets and created DOCVER entries.
-New handling of error conditions when interactive: rather
than terminating the SAS Session, global macro MXGOPTKILL
that is set in VMXGOPTK (the macro that drives the keep
logic and is part of VMXGSUM) gracefully shuts down the
VMXGSUM execution but preserves the interactive session.
-Messages about too-long-text were revised.
Change 30.157 New REPORT THREE-A for IMACICEZ, IMACICE1, and IMACICE2
UTILEXCL tailoring members now identifies the number of fields and
Aug 13, 2012 the lengths that must be updated in those three members.
It may be necessary to use the MCTSSDRL field in the DO
groups for these three optional segments.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.156 -Variables TOTLSESS ACTVSESS INACSESS in TERMSERV dataset
EXNTICAS for the Terminal Services object were input in that order
IMACNTSM in Windows Server 2003 (NTVERSN='5.2'). In Windows Server
VMACNTSM 2008-R2 (NTVERSN='6.1') the order was changed to ACTVSESS
VMXGINIT INACSESS TOTLSESS, so now, one of two INPUT statements is
Aug 10, 2012 executed, based on NTVERSN.
-Support for ICA Session object creates ICASESSN dataset.
dddddd dataset description
NTICAS ICASESSN ICA Session
Thanks to ???, ???, ???
Thanks to Mark Friedman, Demand Technology, USA.
Change 30.155 -Support for the WebSphere Asynchronous Section in subtype
EXT1209A nine records creates new TYP1209A dataset
IMAC120 dddddd dataset description
VMAC120 T1209A TYP1209A WebSphere Subtype 9 ASYNC
VMXGINIT These variables in TYP1209A and TYP1209E correspond and
Aug 9, 2012 can be used to compare observations in those datasets:
Oct 16, 2012 TYP1209A TYP1209E
SM1209GP SM1209CG
SM1209GQ SM1209CR
SM1209GR SM1209CS
SM1209GT SM1209CU
SM1209GV SM1209CV
-Unrelated, variable SM1209CX was found to have been
incorrectly divided by 4096, in TYP1209E dataset.
-Oct 16: The August change also corrected variables
SM1209DL, SM1209DM, and SM1209DN service units.
Thanks to Joseph L. Babcock, JPM Chase, USA.
Thanks to Tom Bubnash, SSA, USA.
Thanks to Babatunde Ashiru, SSA, USA.
Thanks to Jim Hare, Shared Services, CANADA.
Change 30.154 Velocity Software ZVPS (a/k/a XAM) new User Record with
EXXAMUSV with USERTYPE='VCPU' creates new dataset:
FORMATS dddddd dataset description
IMACXAM XAMUSV XMUSVCPU Virtual CPU per User Statistics
VMACXAM Dataset XMUSVCPU contains the USEACT and USEINT variables
VMXGINIT plus Virtual CPU Address (VMDCPUAD) and Engine Type in
Aug 9, 2012 VMDPUTYP, decoded by new MGXAMTY format (CP, ZIIP, etc),
so there is one observation for each USERID and VMDCPUAD
for each MONWRITE interval.
Thanks to Patricia Hansen, ADP, USA.
Thanks to Mike Chaves, ADP, USA.
====== Changes thru 30.153 were in MXG 30.05 dated Aug 8, 2012=========
Change 30.153 -See Change 30.166. Documentation updated.
VMXGUOW -PROGRAM names PROG1-PROGnn are created (TRAN1-TRANnn),
Aug 8, 2012 with the HOWDEEP= argument (default 10) setting the "nn"
to be created, but you must also use KUOWIDC to list the
variables you want to be kept. You can put the statement
MACRO _KUOWIDC PROG1=PROG9 % in IMACKEEP tailoring, or
use %LET MACKEEP= MACRO _KUOWIDC PROG1-PROG9 %; in SYSIN.
-Documentation of CICS transaction counts:
An observation in CICSTRAN cay be only one of many CICS
"segments" that make up a "unit of work", UOW, a "real"
transaction. Counting the number of observations in the
CICSTRAN dataset does NOT tell you how many actual CICS
Thanks to Charles Savikas, DCF, State of Florida, USA.
"transactions", or "units-of-work" were executed.
MRO trans typically have at least two observations in
the CICSTRAN dataset for a unit of work: one is from
the TOR region/applid and one is from the AOR region.
In ASUMCICS dataset (summarized CICSTRAN), the variable
NUMTRANS is the number of CICSTRAN observations, i.e.,
the inflated count of MRO CICS segments.
In ASUMCICX dataset (summarized ASUMUOW), the variable
NUMTRANS is the number of ASUMUOW observations, i.e.,
the "correct" count of transactions/units-of-work).
In ASUMUOW dataset, (created from CICSTRAN/DB2ACCT/MQ):
MROTRAN - Count of CICSTRAN observations in this UOW,
inflated segment count.
DB2TRAN - Count of DB2ACCT observations in this UOW.
MQTRAN - Count of MQMACCT/MQMACCTQ obs in this UOW.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.152 A strange SAS compiler error, if you used the _KDCODSN
VMACDCOL "KEEP= exit" for dataset DCOLDSET, intending to add some
Aug 6, 2012 new variables and to DROP= some existing variables:
MACRO _KDCODSN NEWVAR1 NEWVAR2 DROP= OLDVAR1 OLDVAR2 %
This compiler error is unique to the VMACDCOL structure,
and is circumvented by relocating the &MXGFILNM macro
variable to a different place in the source code.
-The SAS compiler erroneously expanded that _KDCODSN macro
token TWICE, causing the first instance of DROP= to apply
to all of the NEW variables in the second instance of the
expansion, so NONE of the new variables were kept. This
error was precipitated by Change 29.296, which added a
new-style macro variable token, &MXGFILNM, at the end of
each KEEP= list (so you could add variable INFILENM to
all DCOLLECT datasets). Apparently, even when &MXGFILNM
is blank, when it is the last token before the _KDCODSN
token, then if _KDCODSN is not blank, the SAS old-style
macro compiler expanded that macro token TWICE. But, by
relocating that &MXGFILNM text to a separate line, before
the last variable line in the MACRO _VDCODSN KEEP= list,
so it is no longer immediately prior to _KDCODSN token,
that second unwanted expansion is avoided and your normal
_Kdddddd tailoring works as expected. The error was in
both SAS 9.2 and 9.3 on Windows and z/OS SAS 9.1.3 SP4.
Thanks to Paul Maradin, HP, USA.
====== Changes thru 30.151 were in MXG 30.05 dated Aug 6, 2012=========
Change 30.151 Additional Enhancements for RMF III processing.
VMACRMFV -ZRBASM file was not output to the PDB when TYPSRMFV
Aug 4, 2012 member was used to build an RMF Monitor III PDB.
-Macro call to _SZRBASM was missing from _SRMFV macro.
-_BZRBASM macro for ZRBASM file misspelled ASMJESID
variable as ASIJESID causing SAS error during PDB build.
-Change 27.100 altered the EXZRBLCP macro to conserve disk
space for inactive logical processors by suppressing
output to the ZRBLCP file when LCPUPDTM was zero (which
includes LPARs that are categorized as PHYSICAL).
However, all processor entries for PHYSICAL LPARs are
required to determine the number of physical engines on a
CEC for an engine type such as a ZAAP or ZIIP. One or
more of these can legitimately be inactive during an RMF
III MINTIME interval. The number of physical engines for
each engine type is required to compute Physical % UTIL
as in the RMF III CPC panel. Entries for PHYSICAL
LPARs are now always output regardless of activity.
-Variable SSHRMFVN (RMF version number) added to these MXG
created RMF III "PDB" SAS datasets:
ZRBSVPP, ZRBSVPW, ZRBSVPC, ZRBSVPZ, ZRBSVPR, ZRBSVPG.
-Variable SSHSMPNR (number of valid MINTIME samples) added
to these RMF III PDB datasets:
ZRBGEI, ZRBCFC, ZRBCFI, ZRBCPD, ZRBCPU,
ZRBLCP, ZRBCSR, ZRBDVT, ZRBENC, ZRBENT,
ZRBSHD, ZRBPGP, ZRBRED, ZRBRCDB, ZRBRCDS,
ZRBRCDR, ZRBOPD, ZRBSPG, ZRBSVPP, ZRBSVPW,
ZRBSVPC, ZRBSVPZ, ZRBSVPR, ZRBSVPG, ZRBUWDEV,
ZRBUWSTO, ZRBUWJES, ZRBUWHSM, ZRBUWENQ, ZRBUWMNT,
ZRBUWMSG.
-Variable SSHGOMNT (Gatherer MINTIME option) added to
these RMF III PDB files:
ZRBGEI, ZRBASI, ZRBCFC, ZRBCFI, ZRBCPD,
ZRBCPU, ZRBLCP, ZRBCSR, ZRBDVT, ZRBENC,
ZRBENT, ZRBSHD, ZRBPGP, ZRBRED, ZRBRCDB,
ZRBRCDS, ZRBRCDR, ZRBRCDT, ZRBRCDX, ZRBRCDD,
ZRBOPD, ZRBSPG, ZRBSVPP, ZRBSVPW, ZRBSVPC,
ZRBSVPZ, ZRBSVPR, ZRBSVPG, ZRBUWDEV, ZRBUWSTO,
ZRBUWJES, ZRBUWHSM, ZRBUWENQ, ZRBUWMNT, ZRBUWMSG.
Thanks to Randy Hewitt, HP Canada, Canada
Change 30.150 NDM-CDI record 'EX' caused "UNKNOWN SUBTYPE" log messages
VMACNDM and no DSECT is yet received to decode the 40 bytes of
Aug 3, 2012 hex zeros at the end of the record, but the front end has
the same fields as the NDMDT record so the 'EX' record is
output in NDMDT, pending receipt of documentation.
Thanks to Paul Volpi, UHC, USA.
Change 30.149 The KEEPALL=YES default is used in most MXG code because
VMXGSUM it is usually safer, as it protects if there is an INCODE=
Aug 3, 2012 argument that can reference a variable that is not in one
Aug 7, 2012 of the parameter lists. However, in some invocations of
VMXGSUM, it caused a VARIABLE NOT FOUND error that caused
PROC MEANS to fail, when a variable did not exist, due to
an error in the VMXGSUM logic that only rebuilt the KEEP
list after the first data step when KEEPALL=NO. Now, that
rebuild is always executed with either NO or YES.
-VMXGSUM was redated Aug 7; the above logic was revised.
Thanks to Robert Kirkland, MedMutual, USA.
Change 30.148 The %SYMEXIST() function now detects that macro variable
VMXGINIT MXGSOURC exists ("MXGNAMES" dynamic allocation was used,
Aug 1, 2012 which requires FIXORDER dataset to be created to print
the //SOURCLIB DSNAMEs messages at MXG startup), so the
FIXORDER creation can be bypassed for static allocation.
And FIXORDER is not compressed when it is created, to
suppress a cosmetic warning messages about size increase.
Change 30.147 The DB2 AUDIT reports were reformatted to match reports
ANALDB2R in OMEGAMON XE for DB2 Performance Monitor Version 4.2.
VFMT102 Since the detail and trace formats are essentially the
Jul 31, 2012 same, PMAUD03 now simply invokes PMAUD02.
AUDIT= parameter is expanded to support these options:
DDFTRAN - DDF TRANSLATION .
ESTTRST - Establish Trusted Context
CRTTRST - Create Trusted Context
KERBERO - KERBEROS/ENCRYPTED Connection
Change 30.140 revised VFMT102 to eliminate time; this
change removes the timestamp when VFMT102 is called.
The LINESIZE option is now set to 200 at the beginning
and then reset to the original value at the end of
ANALDB2R, as some of the reports can get very wide.
Thanks to Alyona Bertneski, JPMorgan, USA.
Change 30.146 Cosmetic/maybe. The %DO loop variable &I was changed to
VMXGDSNL the more "unique" &DSNL to possibly avoid conflict with
Jul 31, 2012 user code that was wrapped around VMXGDSNL in TYPEQACS.
Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
Change 30.145 Variable CORRNAME and CORRNUM were incorrectly decoded
VMACDB2 for QWACATYP=4 (CICS) connections.
Jul 31, 2012
Change 30.144 -If you specified PDBOUT=PDB and asked for specific IFCIDS
READDB2 e.g. IFCIDS=ACCOUNT 105 107 269, the T102Sxxx datasets
Jul 31, 2012 were not copied to the PDBOUT= destination.
-If you used the LDB2xxx parameters to limit the variables
kept or dropped and used the syntax:
LDB2ACC=PDB//KEEP/varlist
the // did not work as documented; a space was required,
but this change now properly supports // or / / as the
null argument.
Change 30.143 -These variables, which should have been a MAX value, were
VMXGDBSS incorrectly summed:
Jul 31, 2012 ASUMDBSS - QB1TVPL QB2TVPL QB3TVPL QB4TVPL QB1TCBA
QB2TCBA QB3TCBA QB4TCBA
ASUMDBSB - QBSTVPL QBSTCBA
They now contain the MAX value of the end-of-interval
values, across each summary interval.
-In addition, because DB2 V10 writes fixed one-minute data
and so those variables are end-of-interval values, these
average value variables are now created:
ASUMDBSS - AVG1VPL AVG2VPL AVGTVPL AVGTVPL AVG1CBA
AVG2CBA AVGTCBA AVGTCBA
ASUMDBSB - AVGTVPL AVGTCBA
-Labels were created for these four variables:
ASUMDBSS - THRDFTPT THRDUSE TOTTHRD
ASUMDBSB - READS
Change 30.142 %VMXGPRNT, which "PROC PRINTs" with both the LABEL and
VMXGPRNT VARIABLE as heading, is enhanced to allow FMTLST= option
Jul 31, 2012 to specify the printed format. See ANAL113 for example.
Change 30.141 -XAM/ZVPS XAMTCP record contains 0.0.0.0 for IPADDR in all
VMACXAM observations as that is what is in the record.
Jul 31, 2012 -Values in AVERAGTM='TOTALTIME/TOTALACKED IN FAL' and the
values in TOTALTIM='TOT ROUND TRIP TIME(MS)' in XMTCPAPP
dataset are large negative values in many records.
-Both problems will be forwarded to the vendor.
-Variable NAMENODE is now kept in XMTCPAPP dataset.
Thanks to Andrew Petersen, CSC, AUSTRALIA.
Change 30.140 -Support for IFCID 269 and 270 populates existing T102S269
FORMATS and T102S270 datasets with QW0269xx/QW0270xx variables.
VFMT102 -Formats created for some QW0269xx/QW0270xx variables.
VMAC102 -VFMT102 revised to eliminate the time values.
Jul 31, 2012 -SQL Text long-variables have multiple blanks removed with
COMPBL function.
Thanks to Alyona Bertneski, JPMorgan, USA.
Change 30.139 The label for PIRSHELF is corrected to "SHELF", which I
VMAC110 now know is a z/OS Unix name for a directory, primarily
Jul 30, 2012 used for Web service binding files.
Thanks to Dale Slaughter, Transamerica, USA.
Change 30.138 ASG TMON/DB2 creates invalid DB2 101 records that causes
VMACDB2H MXG to print ERROR: INVALID DB2 101 RECORD messages, but
Jul 27, 2012 since the ASG records have their header segment at the
Aug 3, 2012 start of the record, whereas IBM's header segment is at
the end of the record, I've updated these error messages
to identify "ASG-CREATED" and to identify the ASG fix of
TE03737 in the error messages. These records are DELETED.
Change 30.023 detected these errors, but printed ALL of
the defective records; this change limits printing to 3.
Thanks to Marty Pruden, Purina Nestle, USA.
Change 30.137 Updates to NMON/TOPAS Monitor for AIX and LINUX.
EXNMONDF -All BBBP single-value-per-line configuration entries for
EXNMONEN the lsconf, lparstat, lsattr EL, vmstat V, and vmstat S
EXNMONLP subtypes are now output in NMONBBBP dataset. All labels
EXNMONMP now contain the subtype name. Variables from each subtype
EXNMONVM are grouped in the LABEL statement so they are adjacent
IMACNMON when printed. Variables BBBP001-BBBP0146 now exist.
VMACNMON -These "BBBP,ending" multi-value-per-line entries are
VMXGINIT output in these new datasets:
Jul 28, 2012 DDDDDD DATASET DESCRIPTION
Aug 17, 2012 NMONDF NMONBBBPENDDF BBBP,ending df m
Sep 13, 2012 NMONLP NMONBBBPENDLP BBBP,ending lparstat h
NMONMP NMONBBBPENDMP BBBP,ending mpstat d
NMONVM NMONBBBPENDVM BBBP,ending vmstat i
-The "BBBP,ending" single-value-per-line entries from the
"ending vmstat v" and "ending vmstat s" subtypes are
output in this new dataset:
DDDDDD DATASET DESCRIPTION
NMONDF NMONBBBPENDING BBBP,ending vmstat v and s
-Entries PCPUnn and SCPUnn create TEMPCPUNP and TEMPCPUNS
that are merged into existing NMONCPUD, detail CPU
metrics by CPUNR.
-Entries PCPU_ALL and SCPU_ALL_ are input and variables
retained and added to NMONINTV.
-Entries DISKRIO, DISKWIO, DISKAVGRIO, DISKAVGWIO are now
supported, and variables of the same name are added to
the NMONDISK dataset.
-The internal logic for the DISKxxxxN "suffixed" records,
written when there are more disk devices than will fit on
a single record, is restructured to use a 2-elment array
instead of a separate explicit DO group for each suffix.
These arrays support 50 suffixed records with 512 devices
per record, versus the original fixed 21 suffixes.
-ERROR: ARRAY Subscript Out Of Range - DISKSERV DISKSVCTM
DISKWAIT DISKWAITTM objects corrected, and protection for
"NANQ" text for "not a number" for BBBPENDLP04, Aug 17.
-Sep 13: BBBPENDVM05 increased to 64 bytes.
Change 30.136 These TYPE50 OSA/Express READ variables (ATTCHTYP=4 only)
VMAC50 TY50PCIR TY50PCIV TY50PCIT TY50PCIU TY50PDFR
Jul 25, 2012 are missing if SUBCHPOL is not 'READ'; IBM had changed
the value to "RD/n" without documentation. The MXG test
is now revised to detect READ if SUBCHPOL starts with RD.
Thanks to John McLaughlin, Bank of America, USA.
Change 30.135 %VGETALOC is a new macro for use with AUTOALOC=YES (that
VGETALOC VMXGALOC option creates directory names containing date)
Jul 24, 2012 that lets you select (getdaterange=,typeofdata=) a group
of "PDBs"/directories that are to be read, constructing
a "SET" statement in a DATA-step using VMXGSET.
For example:
%vgetaloc(getdaterange=01jul12 24jul12,
typeofdata=daily,
basedir=c:\mxg,
datefmt=date7.
);
data jobs;
%vmxgset(dataset=jobs);
will search the c:\mxg directory for all directories with
a name that contains a date in ddmmmyy format, selects
those with date between 01Jul12 and 24Jul12 inclusive,
and allocates them as PDB1- PDB24 as there are 24 dates
in your selection criteria. These libnames are passed to
VMXGSET which build the logical SET statement to read all
24 LIBNAMEs for the JOBS dataset you requested in VMXGSET
set pdb1.jobs pdb2.jobs pdb3.jobs ... pdb24.jobs;
(i.e., the number of libnames found by vgetaloc).
Change 30.134 Cosmetic/Spurious. ANALDB2R printed note from VMXGVERS
ANALDB2R that you were using a backlevel ANALDB2R, because that
Jul 24, 2012 statement at the bottom of ANALDB2R still had 30.02 in
both 30.03 and 30.04. While the MXG QA stream has a test
for VMXGVERS value, the line was in lower case and the QA
test expected upper case. Now, the QA test looks first
for lower case and then for version number.
Since there is a %PUT with the ANALDB2R last update date,
the currency of this ANALDB2R member was confirmed on the
SAS log, so this was only a cosmetic error. But it gets
this change text because the user had to waste his time
to report the potential problem due to my error!
Thanks to R. van der Zande, KLM, THE NETHERLANDS.
Change 30.133 Support for (optional) DB2 Netezza for Accelerator data.
IMACDBNZ IBM DB2 Analytics Accelerator IDAA product uses Netezza.
VMACDB2 -Similar to MXG support for optional CICS data segments,
Jul 23, 2012 support for optional Q8AC DB2 Accounting variables is in
a comment block in the new IMACDBNZ member that contains
the code, labels, and formats, so none of the Netezza
variables will exist in DB2ACCT, until you copy IMACDBNZ
into your "USERID.SOURCLIB tailoring library and then
remove that comment block.
-Because the volume of DB2 statistics records is small,
the Netezza Q8ST DB2 Statistics variables are created in
the DB2STATS dataset (so you can tell if the Netezza APAR
PM50434 has been installed!) as well as in DB2NETZA.
-See Change 30.229.
Thanks to Jan Tielmans, KBC, BELGIUM.
Thanks to Christa Neven, KBC, BELGIUM.
Change 30.132 Corrections to SMF 21 calculations for compression ratios
VMAC21 and circumvention for records with byte count fields that
Jul 22, 2012 unexpectedly contain zeros. When the compressed bytes in
Aug 7, 2012 SMF21MDR or SMF21MDW are zero, the compression ratio can
not be calculated. In some records, uncompressed bytes in
SMF21BR/DBR/MCR and SMF21BW/DBW/MCW are zero, which also
caused confusion as to which variable should be used.
This was circumvented by calculating the uncompressed
byte counts as:
BYTEREAD=MAX(BYTEREAD,SMF21DBR,SMF21MCR,0);
BYTEWRIT=MAX(BYTEWRIT,SMF21DBW,SMF21MCW,0);
and using those values as the numerator of SMF21CRR/CRW,
when SMF21MDR/SMF21MDW are nonzero.
A problem is opened with IBM to understand the zeroes.
-Aug 7: Variable OPEN is always blank may not be new.
Sites have DCBOFLG='00'X in ID=21 SMF records, but the
ID=14/15 DCBOFLGS field is valid. The 14/15 is written
at z/OS CLOSE, but your CA-1/RMM/TLMS tape management
product still owns the DCB, so they may be clearing the
DCB byte before the type 21 record is written (which can
be HOURS later than the CLOSE event). The type 21 write
only copies control block values with no logic/changes.
In TYPE21 DCBOFLG is only used to populate variable OPEN
with INPUT or OUTPUT, so now, the BYTEWRIT and BYTEREAD
counts are compared and OPEN is populated based on the
larger of the two values. Zero or equal will blank OPEN.
Thanks to Scott Barry, SBBWorks Inc, USA.
Thanks to Michael Creech, Lender Processing Services, USA.
Change 30.131 Two new parameters are added to enhance VMXGALOC:
VMXGALOC READONLY - if set to YES the code that deletes old
BLDSMPDB directories is suppressed.
IMACINIT CLEARALL - if set to YES, ALL previously allocated
Jul 22, 2012 LIBNAMEs are cleared. YES is the default.
Sep 16, 2012
With these changes, you can do reporting for multiple
days/weeks in a single SAS session.
Examples:
-To run reports based on today's runs:
%VMXGALOC(BASEDIR=xxx,READONLY=YES,CLEARALL=YES,
TRENDING=DAILY);
which allocates all of the current LIBNAMES that were
created with today's run, then you can run your reports.
-To go back to an earlier date, like June 11, 2012:
%VMXGALOC(BASEDIR=xxx,READONLY=YES,CLEARALL=YES,
TRENDING=DAILY,FORCEDAY=11JUN12);
which clears all of "todays" allocation and the correct
LIBNAMEs for June 11, are then allocated.
FORCEDAY will now accept a relative number of days as
TODAY()-NN where NN is the number of days to go back.
BLDSMPDB - z/OS only, if you asked to WTD or MTD and also
asked to use WEEKTAPE or MNTHTAPE, an ABEND will now be
generated since this structure is not supported by the
sequential engine on z/OS. Also, if you were running WTD,
BLDSMPDB incorrectly tried to start the week one day too
early; that has been corrected. No data was lost but the
data may not have been in the week where you expected to
find it for the first day of the week.
IMACINIT - applies only if you are running BLDSMPDB with
AUTOALOC=YES. A new example VMXGALOC invocation is in
comments in the IMACINIT member. Copy IMACINIT into your
"USERID.SOURCLIB" tailoring library, REMOVE the comments
around that VMXGALOC invocation, EDIT it to match your
BLDSMPDB arguments, and then, since IMACINIT is always
invoked at MXG startup, all of these "PDB" LIBNAMEs
PDB MON TUE WED THU FRI SAT SUN SPIN
WEEK1-WEEK5 MONTH TREND SPIN CICSTRAN DB2ACCT
will always be allocated.
-Sep 16: Comments updated, no code was changed.
Thanks to Mynard Holloway, Spectrum Health, USA.
Thanks to Robb Hermes, Sentry Insurance, USA.
Change 30.130 -EXITCICS Version 3 correctly decompresses DB2 compressed
EXITCICS SMF records (which version 1 didn't always do), continues
Jul 19, 2012 to also decompress CICS SMF records, and this version no
Aug 4, 2012 longer needs the IBM CICS macro library for the assembly.
-EXITCICS is the z/OS ASM source code and ASM/LKED steps
that create the CICSIFUE "Infile Exit" load module that
decompresses DB2 V10 and/or CICS/TS 3.2+ compressed SMF
records. It has never failed for CICS records, and while
many DB2 sites have used it successfully, a small number
of DB2 sites had errors reading compressed records; those
errors are corrected in this updated EXITCICS member. The
complete instructions for creating and installing the
exit are in the comments in the EXITCICS member.
-Version 2 briefly existed and it corrected the DB2 errors
but it still needed the DFHSMFDS macro.
Thanks to Richard Anderson, SAS z/OS Technical Support CARY, USA.
Change 30.129 Support for new zNEXT CPU MF counters EXTEND157-EXTND207
ASUM113 and revised calculations for all of the formulas.
VMAC113 There were 48 EXTEND counters initially and now there are
Jul 20, 2012 80 EXTEND counters, thru EXTND207.
Aug 31, 2012 -Calculations updated from JP Burg's August 29 2012 text.
Sep 17, 2012 -Corrections made Sep 17:
Oct 9, 2012 1. Line 271 in VMAC113 was missing the 0.65.
2. Labels in VMAC113 for EXTND159-162 are now L4 vs L$.
3. The 151- and 148= typos in both ASUM113 and VMAC113
for the MEMP calculation are corrected.
4. The LPBUSY in ASUM113 was changed to LPARBUSY; LPBUSY
is the variable in VMAC113 but it's LPARBUSY in
ASUM113 as documented in Change 28.226.
Oct 9 update:
-Labels for the EXTNDnnn counters were revised based on
SA23-2261-02. Note that there are three sets of labels
for the z/10, z/196 and z/114, and the zEC12, but SAS can
only use the last label for a variable, the active labels
are now for the zEC12, but the other labels can be seen
in the VMAC113 LABEL statement.
-z/EC12 only defines counters thru counter 179, but MXG
was misled to create counters up to 207, but since they
will likely exist sometime, variables thru EXTND207 are
created by this change, IN 30.05 AND REQUIRED FOR z/EC12
processors - an "ARRAY SUBSCRIPT OUT OF RANGE" error will
occur without this change.
Change 30.128 -DB2 V10 changed the QPACFLGS bit map; variables QPACDBRM
VMACDB2 and QPACPACK no longer exist (so they are always blank in
Jul 16, 2012 QWHSRELN GE 10 observations), and new flag variable, only
in Version 10 and later are created and populated:
Variable Label from QPACFLGS
QPACROLL='THIS IS A*ROLLUP*QPAC?' 01X bit
QPACRUSM='THIS IS A*SUMMARY*ROLLUP*QPAC?' 02X bit
-Documented in DB2 Macro Library member DSNDQWAS:
If QPACROLL is on, the Package Record contains ONLY
the QPKG and QPAC segments, but the QXPK, QBAX and QTXA
segments do not exist, so a ROLLUP record will always
have missing values for these SQL/DML QXPK variables
QPSELECT QPINSRT QPUPDTE QPDELET QPDESC QPPREP
QPOPEN QPCLOSE QPFETCH QPLOCK QPCALL
and QBAC and QTXA fields will also be missing values in
the DB2ACCTP dataset.
-Documented in DB2 Macro Library member DSNDQPAC:
If QPACRUSM = ON, the following fields are invalid:
QPACCRNT QPACINSP QPACPAC QPACPKNM QPACCOLN QPACPKID
QPACCONT QPACSCB QPACSCE QPACBJST QPACEJST QPACASCH
QPACAANM QPACAAFG
IF QPACRUSM = OFF, the following fields are invalid:
QPACCRNT QPACPAC QPACSCB QPACSCE QPACBJST QPACEJST
IF QPACRUSM = OFF, the following fields are the last
non-zero value for a thread rolling data into this QPAC
QPACASCH QPACAANM QPACAAFG
Thanks to Jane Stock, USPS, USA.
Change 30.127 Variable BLKSIZE was missing when SMF21LB bit was not on.
VMAC21
Jul 13, 2012
Change 30.126 Selection of data by a range of explicit DATE values did
ANALGRID not work, but all of the keywords for date selection were
Jul 12, 2012 correct.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 30.125 Variable UMLRECL in dataset DCOLMIGS, LRECL of the
VMACDCOL migrated dataset, is now INPUT and kept. It was
Jul 10, 2012 added by z/OS 1.12 but overlooked.
Thanks to Brian Harvey, HCL America, USA.
====== Changes thru 30.124 were in MXG 30.04 dated Jul 4, 2012=========
Change 30.124 z/VM variable VMDFLREO should not have been divided by
VMACVMXA DELTATM (which is normally 60 seconds, so the values in
Jul 3, 2012 VMDFLREO were 1/60th, or 1/DELTATM too small).
Thanks to Sam Bass, McLane Company, USA.
Change 30.123 -Change 28.226 noted that TYPE113 variable SM113CPT is
VMAC113 only populated if SM113VN2 GE 2 (i.e., z196 or later) but
VMAC7072 that change did not note that as a result, SMF70CIN is
Jul 3, 2012 also blank when SM113VN2 is not 2. However, if both 113
and RMF 70 records are processed together, (or as long as
PDB.TYPE70PR exists when ASUM113 is executed), then the
merge of the 70 data with the 113 data will populate both
SMF70CIN and SM113VN2.
-In investigating the above, TYPE113 variable DELTATM was
found to sometimes be too small; MXG must calculate the
interval duration from adjacent records because IBM does
not create it, and the incorrect use of FLOOR(DIF(x)) was
found to be the culprit; DELTATM is now correct but is no
longer "made pretty" with an integer value. The small
value for DELTATM caused both the count in LPARCPUS to be
grossly wrong in some cases (12 vs 2!) and LPBUSY could
also be incorrect.
-But, "valid" small values of DELTATM have been observed
in some as-yet-not-fully-understood cases where SMF 113
records are written extremely close in time. While the
deaccumulated counters look to be correct in these cases,
as they are not full intervals, I recommend that all of
your observations in PDB.ASUM113 that have DELTATM less
than the expected interval duration (e.g., DELTATM LT 890
if the expected data is 15 minute interval) be deleted
before you analyze the HIS data. USE TYPS113E vs TYPS113.
-VMAC7072: Cosmetic. Change 30.106 typo in the LABEL for
ZIPSHARE caused UNINIT VARIABLE ZPTSHARE that is fixed.
Thanks to Roger Lowe, Northern Territory Government, AUSTRALIA
====== Changes thru 30.122 were in MXG 30.04 dated Jul 4, 2012=========
Change 30.122 NRECORD=MAX generated an error; the code was looking for
VMXGGETM a null value but now accepts MAX and either null or MAX
Jul 2, 2012 will set the counter to the value of MXGOBS.
Change 30.121 Enhancements/Additions to $MG119xx FORMATS for TYPE119.
FORMATS New formats $MG119CI $MG119CO $MG119MA $MG119MO $MG119TY
VMAC119 are created and assigned to appropriate variables. Some
Jun 29, 2012 old formats $MG119AM $MG119CC $MG119PL $MG119ST $MG119RF
were defined, but not assigned to all variables. Formats
$MG119CC and $MG119PL are identical, but as they were
assigned separately to different variables, they have to
be kept in FORMATS. $MG119FA and $MG119RF were also
identical, but neither was assigned so $MG119FA has been
removed from FORMATS.
Thanks to Martyn Jones, Deutsch Bank, GERMANY.
Change 30.120 Support for RACF Database Record 02G1 creates RACF02G1
EXRAC2G1 dataset with Custom User Data.
IMACRACF
VMACRACF
VMXGINIT
Jun 28, 2012
Thanks to Steve Carlson, Univ of California Office of President, USA.
Change 30.119 Support for APAR OA39629 adds two variables to SMF 30
BUILD005 subtypes 2,3,4,5 (kept in TYPE30_V/TYPE30_4/TYE30_5 and
BUIL3005 in PDB.SMFINTRV, PDB.STEPS and PDB.JOBS datasets):
VMAC30 HICPUPCT='HIGH*TASK*CPU*PECENT'
Jun 28, 2012 -For interval records, the largest percentage of CPU
time used by any task in this address space, rounded
to the nearest integer. A value of 25 indicates that
the most CPU intensive task in this address space was
dispatched on a physical processor for 25% of the SMF
interval time.
-For step-end, the value is the largest reported
interval if the step crosses an interval boundary.
-For job-end, the value is the largest reported
interval value for any step.
-The percentage value in the record is calculates as:
TCB time * 100/ interval time.
HICPUPGM='HIGH*TASK*PROGRAM*NAME'
-Program name running in the task that used the largest
percentage of CPU time in this address space. This
field corresponds to HICPUPCT.
-A value of blanks indicates that no task reported any
CPU time in the address space, or that the CPU time
could not be obtained.
-A value of '????????' indicates that the program name
could not be obtained for the task that reported the
highest percentage of CPU time.
-Additional information from IBM in the APAR text:
-These new fields are intended to identify the
largest consuming task when multiple tasks are
active in an address space. One may compute the
address space task percentage from existing fields
in the SMF 30 record but one has no insight
currently into usage within the address space. If
the total CPU percentage is on the order of 50%, the
task may struggle to be served well particularly if
it has a mediocre dispatching priority or the system
is running in horizontal mode (HiperDispatch not
enabled). If the address space percentage is 50% and
the largest task percentage is 15%, there is little
concern that the task will be unable to progress as
long as it is properly classified in WLM.
-IBM will provide guidance to our customers that
establishing a list of candidates to monitor and
determining any increase in percent dispatched for
the evolving list over time (perhaps every six to
twelve months) should be part of the capacity
planning process. Our current recommendation is to
take note of address spaces with programs that are
dispatched at least 25% of an interval for intervals
of at least 5 minutes.
Change 30.118 Unused Change Number.
Change 30.117 Documentation of MXG internal syntax. The example code
UDDDDDD in VMACXXXX shows this syntax for the dataset label
UTILVREF (LABEL='dddddd: description of dataset'
VMACXXXX but it was never documented that the "dddddd" token in
Jun 25, 2012 the label can NOT contain a blank (a blank causes the
UDDDDDD program to fail building $MGDDDDD and $MGDDDSN
formats). A comment was added in the VMACXXXX example,
test for a blank was added to both UDDDDDD and UTILVREF,
but as these programs are ONLY used internally during the
MXG QA process to create documentation, these errors
won't be observed by MXG users.
Change 30.116 Support for Voltage SecureData for z/OS z/Protect SMF.
EXZPR01 These new datasets are created:
EXZPR02
EXZPR03 DDDDDD MXG MXG
EXZPR04 DATASET DATASET DATASET
EXZPR05 SUFFIX NAME LABEL
EXZPR16
FORMATS ZPR01 ZPRO01 ZPR01: Z/PROTECT DISPATCHER STARTUP
IMACZPRO ZPR02 ZPRO02 ZPR03: Z/PROTECT SHUTDOWN EVENT
TYPEZPRO ZPR03 ZPRO03 ZPR03: Z/PROTECT OPERATOR COMMAND EVENT
TYPSZPRO ZPR04 ZPRO04 ZPR04: Z/PROTECT ABEND EVENT
VMACZPRO ZPR05 ZPRO05 ZPR05: Z/PROTECT RAW OPERATION DATA
VMXGINIT ZPR16 ZPRO16 ZPR16: Z/PROTECT INTERVAL AGGREGATIONS
Jun 30, 2012 In dataset ZPRO16, variable ZPRTTYPE identifies which of
the seven possible aggregates is reported:
1='1:OVERALL TOTALS'
2='2:TOTALS BY USER'
3='3:TOTALS BY CRYPTID'
4='4:TOTALS BY JOBNAME'
5='5:TOTALS BY USERID AND CRYPTID'
6='6:TOTALS BY JOBNAME AND CRYPTID'
7='7:TOTALS BY USERID AND JOBNAME'
Change 30.115 -VMXGRMFI - The TRENDING section of VMXGRMFI now uses
ADOCTRND VGETWKLD to ensure that all workloads, old and new, are
GRAFTRND preserved. This allows you to add new workloads but then
GRAFWRKX remove or rename old workloads, while preserving your
MNTHRMFI historical data for the old workloads that may no longer
TRNDRMFI exist in RMFINTRV, but will still exist in TRNDRMFI.
UTILBLDP -VGETWKLD - Now will get the workload names, labels and
UTILCPLG periods for use in VMXGRMFI from multiple sources. New
VGETWKLD parameter datasets lets you specify as many datasets for
VMXGALOC input as may be needed, but the purpose is to allow the
VMXGRMFI specification of DATASETS=WORK.RMFINTRV TREND.TRNDRMFI so
Jun 21, 2012 that if you have added or deleted or renamed workloads,
Jun 26, 2012 the old ones in TREND will be carried forward, rather
Jul 2, 2012 than being dropped. New design is also used in GRAFWRKX,
but this is intended for internal MXG usage.
-ADOCTRND - New documentation section 4 showing how to
backload past RMFINTRV data into TRNDRMFI.
-GRAFTRND now is only an invocation of GRAFWRKX with
appropriate arguments.
-GRAFWRKX - sort order for TRNDRMFI was incompatible with
the SORT order for GRAFWRKX so a PROC SORT was added.
-MNTHRMFI now is only an invocation of VMXGRMFI with
appropriate arguments.
-TRNDRMFI now is only an invocation of VMXGRMFI with
appropriate arguments.
-TRNDRMFN now is only an invocation of VMXGRMFI with
appropriate arguments.
-UTILBLDP - COSMETIC ONLY - realign code to make it easier
to understand
-UTILCPLG - did not correctly parse out the LOG/LIST names
and if not preceded by a RUN; statement it could execute
at unexpected times because of timing issues in the macro
language.
If the directory pointed to did not contain a \ or a /
(os dependent) it was not added and could result in an
error during the copy process.
-VMXGALOC - If you specified FIRSTRUN=YES and also were
trying to run with WTD processing, the allocation of the
WEEK libname for the current week did not happen.
Thanks to Mynard Holloway, Spectrum Health
Change 30.114 SAS User SMF Records with SASPROC='SQL (63)', 'APPEND ('
VMACSASU values were unexpected (and unknown to SAS Support) and
Jun 19, 2011 caused SASPROD='UNKNOWN'. Now, the paren is detected and
only the SAS Procedure text name is stored in SASPROC, so
the SASPROD will be "known".
Thanks to Erling Andersen, SMT, DENMARK.
Change 30.113 -DB2 V10 restructured the DB2STATS (100-1) QIST segment,
VMACDB2 but this was overlooked (perhaps because there are no
Jun 19, 2011 vertical change bars in IBM DB2 DSECTS!) causing invalid
values for QIST variables. The restructure removed these
QIST variables so they will have missing value in V10:
QISTWFMU QISTWFCU QISTWFCK QISTWFMX QISTWF04 QISTW04K
QISTWF32 QISTW32T
and V10 created these new variables in PDB.DB2STATS:
QISTIMAC QISTIMSC QISTIMAH QISTIMSH QISTSIAC QISTSISC
QISTSIAH QISTSISH QISTWFRHIG QISTWFRCUR
-In validating this change, these QIST and QISE variables
should not have been deaccumulated:
QISTWCTO QISTW32K QISTW4K
QISEDLRU QISESQCA QISESQKB QISESQKA QISESQCB QISEKSPG
QISEKSPA
The IBM DB2 DSECTs don't always identify which fields are
accumulated; only actual data driven thru the DIF() logic
will prove or disprove field contents (a negative value
or 4x10**9 value prove the field is NOT accumulated), so
data with non-zero values are required to validate MXG.
Thanks to Victoria Lepak, Aetna, USA.
Thanks to Valerie J. Chisholm, Aetna, USA.
Change 30.112 -Thruput Manager datasets TPM16S and TPM16J, variables
VMACTPMX TPMAJCT and TPMSCT were too large by 100; they were INPUT
Jun 19, 2012 as PIB4. but are now input as PIB4.2.
-In addition, TPMAJCT in TYPE16S is an accumulated value,
but the value in TPMSCT will be the step value (with PTF
TMT6218) so there is no real need to deaccumulatate
TPMAJCT to get the individual step CPU time in TPMSCT.
However, now realizing TPMAJCT is accumulated, if you use
TYPSTPMX or _STPM16S to sort dataset TPM16S, this change
will deaccumulate TPMAJCT, and the TPM16S label will
indicate that its value is deaccumulated.
Change 30.111 RACF TYPE801 debugging PUT 'DEBUG 1' was not disabled.
VMAC80A
Jun 19, 2012
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Thanks to Jens Mohring, Huk-Coburg, GERMANY.
Change 30.110 Only Windows PERFMON data that was comma-delimited was
VMACWPMO correctly decoded; a hard-coded ',' is now &DLMWPMO so
Jun 17, 2012 that your delimiter is always used in parsing text.
Thanks to Florent Boulesteix Inovans, Ca-Caagis, FRANCE.
Change 30.109 Support for Mainview CICS v64 CICS/TS 4.2 (COMPATIBLE).
EXMVCICP -New variables added to dataset CMRDETL dataset:
IMACMVCI T6ERSFLG1 T6ERSFLG2 T6ERSFNCNT T6E67ID T6E67XCT
VMACMVCI T6EECSEC T6EPHNWD T6EPHAPL T6EPHATT T6EPHTSN T6EPHTID
VMXGINIT T6EPHCNT T6EADPID T6EADPD1 T6EADPD2 T6EADPD3
Jun 16, 2012 -New dataset decoded for File Segment for PROGRAM:
dddddd dataset description
MVCICP CMRFPROG MAINVIEW CICS FILE PROGRAM
Change 30.108 Reading RMM EDGS records on ASCII caused INPUT STATEMENT
VMACEDGS EXCEEDED RECORD LENGTH error if MORTYPE='FFFFFFFFFF'X.
Jun 15, 2012 The $EBCDIC8 input set the value '000000000000'X, so now
a separate input with $CHAR8 is used for those tests.
Thanks to Rick Raiton, US Airways, USA.
Change 30.107 Support for ASG/Landmark TMON DB2 PTFs TE03699/TE03718
EXTMD2XB which add segments to the PK, TB, and TG records creating
EXTMD2XG these three new datasets:
EXTMD2XK DDDDDD Dataset Description
IMACTMD2 TMD2XK TMD2PKS Thread Package Accounting Segments
VMACTMD2 TMD2XB TMD2TBS Thread BP Accounting Segments
VMXGINIT TMD2XG TMD2TGS Thread GBP Accounting Segments
Jun 10, 2012
Change 30.106 zIIP SHARE WEIGHTS are now calculated for each LPAR in
VMAC7072 all four datasets created by ASUM70PR.
VMXG70PR -For the ASUM70PR and ASUMCEC datasets, with different
Jun 9, 2012 variable names for each LPAR, the variable names are
LPnZHARC ='LPAR n*ZIP SHARE*CURRENT*WEIGHT*PCT'
LPnZHARE ='LPAR n*ZIP SHARE*INITIAL*WEIGHT*PCT'
-For the ASUM70LP and ASUMCELP datasets, with only one
set of variables, the names are:
ZIPSHARE='ZIP*INITIAL*SHARE*WEIGHT'
ZIPSHARC='ZIP*CURRENT*SHARE*WEIGHT'
Since SMF70ACS is currently always zero for zIIPs, the
two variables have the same value, but logic is in place
that will use SMF70ACS if it is non-zero.
Thanks to Rodger Foreman, TransUnion Corp, USA.
Thanks to Lindholm Orjan, VOLVO, SWEDEN.
Change 30.105 Support for RMF III ASIG3 segments with '13'x and '14'x
ASMRMFV segment level that is undocumented and added 376 bytes.
VMACRMFV This caused MXG variables for Service Class, Report
Jun 8, 2012 Class, Workload, and Resource Group data extensions to be
invalid.
-ASMRMFV space message RMFV030I could have invalid values
for HARBA, HURBA, and AVAIL fields when the input RMF
Monitor III VSAM data set was non-EF and exceeded 2 GB in
size. Subsequent message RMFV031I would have invalid
percentages for USED and AVAIL fields possibly exceeding
100 percent. NOTE: Assembly and link-edit of ASMRMFV is
optional for MXG users with only EF RMF III VSAM data
sets or only non-EF data sets not exceeding 2 GB in size.
Otherwise, reinstall of ASMRMFV is strongly recommended
to resolve this issue. o Warren Cravey, Fidelity
Thanks to Warren Cravey, Fidelity, USA.
Change 30.104 -Variable SMF70CIN in TYPE70EN was incorrectly set to the
VMAC7072 value 'ZIP', but that is now SMF70CIN='IIP', consistent
Jun 8, 2012 with SMF70CIN in other MXG datasets.
-For zIIP engines, in dataset PDB.TYPE70PR, the variable
NEWWAIT contains the CPUWAITM for SMF70CIN='IIP'.
-In PDB.TYPE70EN, variable CPUWAITM is valid for CP and
IIP engine's wait time.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 30.103 -Support for z/OS 1.13-added (COMPAT) RAS (Reliability,
VMAC1415 Availability, Serviceability) segment adds flag variables
Jun 5, 2012 that are $HEX2. formatted. Because I don't expect these
new variables to be of great import, separate bit-level
variables aren't created, but these are the values:
SMF14RFG0
'1.......'B='DCBE reject flags present'
'.1......'B='PARTREL flags present'
SMF14RASDATA0
'1.......'B='DCBE invalidated because EXCP and no
foundation extension present.
'.1......'B='DCBE invalidated because DSORG is not PS,
PO OR DA.
'..1.....'B='DCBE invalidated because storage is not
addressable.
'...1....'B='DCBE invalidated because DCBE storage is
not in key of caller.
'....1...'B='DCBE invalidated because the DCBEID is not
'DCBE'.
'.....1..'B='DCBE invalidated because it is not at least
the minimum length required (56 bytes)
'......1.'B='DCBEHIARC flags set but DCBDCBE is zeros.
SMF14RASDATA1
'1.......'0=Partial release not called by CLOSE because
VIO data set
'.1......'1=Partial release not called by CLOSE because
task is abending.
'..1.....'2=Partial release not called by CLOSE because
not opened for output
'...1....'3=Partial release not called by CLOSE because
EXCP DCB but no direct access device section
present.
'....1...'4=Partial release not called by CLOSE because
even though opened for output, last I/O was
not output
'.....1..'5=Partial release had an I/O error
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.102 These DB2xxxxx variables were not MGBYTES formatted, and
VMACDB2 had incorrect labels.
Jun 5, 2012 NDB2STOR ALLOWSTR THRDUSE QWOSDRSU QWOSDVSU
Thanks to Robert M. Dahlia, SunTrust, USA.
Change 30.101 The TITLE7 statement was repeated, so the title line that
ANALDDCN should have reported duplicate bytes DUPBYTES was not
Jun 4, 2012 printed.
Thanks to Tom White, Dell, USA.
Change 30.100 UTILEXCL in MXG 30.03 was defective and the IMACEXCL that
UTILEXCL it created did not input JMVTIMCN which caused errors,
Jun 4, 2012 usually the "NON-FIRST-TRANSACTION RECORD NUMBER" error.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.099 Support for CO:Z SMF 119 Subtypes 192 and 193 records.
EXT119X2 Four new datasets are created:
EXT119X3 DDDDDD DATASET DESCRIPTION
EXT119M2 T119X2 TY119192 CO:Z SFTP SERVER LOG
EXT119M3 T119M2 TY119M92 CO:Z SFTP SERVER LOG MESSAGES
IMAC119 T119X3 TY119193 CO:Z SFTP CLIENT LOG
VMAC119 T119M3 TY119M93 CO:Z SFTP CLIENT LOG MESSAGES
VMXGINIT Jun 18: RACFUSER added to KEEP for T119M2/T119M3 as it is
Jun 3, 2012 in the BY list for both datasets.
Jun 18, 2012
Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 30.098 New fields added to DCOLLECT BKUP records (COMPATIBLY) by
VMACDCOL z/OS 1.11 are now created in DCOLBKUP dataset:
Jun 2, 2012 UBLFS ='LARGE*FORMAT*SEQ*DATASET?'
UBNEWNM='NEWNAME*SPECIFIED?'
UBF_RETAIN_SPCD='RETAIN*SPECIFIED?'
UBF_NEVER_EXP='NEVER*EXPIRE?'
UB_RETAINDAYS='SPECIFIED*RETAINDAYS*VALUE'
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.097 Velocity Software XAMCPUTO dataset contains totals, but
VMACXAM did not contain a count of CPUS. Variable NRCPUS is now
Jun 2, 2012 created, and forced to be an integer using
NRCPUS=FLOOR(0.1+(DURATM/(STOPTIME-STARTIME)));
Thanks to Andrew Petersen, CSC, AUSTRALIA.
====== Changes thru 30.096 were in MXG 30.03 dated May 30, 2012=========
Change 30.096 Support for ZEN OSA MONITOR PTF ZOM1322 that INCOMPATIBLY
VMACZOSA increased the length of ZOSALINK from 13 to 17 bytes.
May 29, 2012
Jun 1, 2012
Change 30.095 RMF III Enhancements.
ASMRMFV -A new table called MXG is now created which contains
VMACRMFV ASMRMFV assembly and execution data. The MXG table is
EXZRBASM created internally by ASMRMFV and is not a true RMF
VMXGINIT Monitor III table. The MXG table contains 49 variables
May 29, 2012 that describe both the assembly and the execution
environment of ASMRMFV. This data can be used either as
an audit trail or as a problem diagnostic aid. VMACRMFV
can also use this data for conditional logic decisions.
Only 1 MXG table observation will appear in the new
ZRBASM file for each run of ASMRMFV, so there is minimal
overhead.
-Two new extensions are added by ASMRMFV to the ASI
(address space) and ENC (enclave) table records with
WORKLOAD and RESOURCE GROUP information. These are in
addition to existing extensions for SERVICE CLASS and
REPORT CLASS data. VMACRMFV adds a total of 14
variables for this new information to the ZRBASI and
ZRBENC files.
-New ZRBASI variables are: ASIWNM ASIWDE ASIGNM ASIGDE
ASIGMN ASIGMX ASIGLT.
-New ZRBENC variables are: ENCWNM ENCWDE ENCGNM ENCGDE
ENCGMN ENCGMX ENCGLT.
-All ASMRMFV added data extensions now only include the
part of the information that is actually documented. In
some cases internal control block values specified a much
greater length and caused problems in VMACRMFV.
-ASMRMFV message RMFV000I now contains information on the
environment at the time of assembly.
-ASMRMFV message RMFV001I now contains information on the
environment at the time of execution.
-Corrected ASMRMFV comments to note that the optional
RMFFILT output data set can NOT be used as input to a MXG
PDB build. RMFFILT does not contain any DSH or SSH
records that would be needed.
-ASI table data extensions for very old releases of RMF
Monitor III V4.3.0 or below (pre 1994) will no longer be
attempted by ASMRMFV. ASI table data will still be
output but without the extensions in this case. The
header structure of these ancient records is not
compatible with the data extension process.
-Corrected a problem where SERVICE CLASS or REPORT CLASS
extensions for ASI or ENC table were incorrect when the
respective data indexes were zero. These values should
have been missing, but instead were populated with data
from the prior ASI entry. This was a limited condition.
-Code path length reductions were made to two subroutines
for ASI and ENC table processing in ASMRMFV by using
existing FINDxx subroutines.
-The ASIENTMX and ASIENTLN fields are now corrected in
ASMRMFV to show the true count and length in an ASI table
record.
-The ENCG3TLN field is now corrected in ASMRMFV to show
the true total length in an ENC table record.
-ASMRMFV now validates that input data sets are VSAM RRDS
with warning message RMFV017W issued if a data set is
non-VSAM or is VSAM but a non-RRDS type. In this case no
abend occurs, but final return code CC=4 is set, and
processing of the next input data set continues.
-ASMRMFV now issues warning message RMFV017W if an input
VSAM data set has a non-standard CISIZE or RECSIZE. IBM
intends that RMF Monitor III data sets be allocated with
the ERBVSDEF Clist which specifies the correct CISIZE and
RECSIZE values of 32768 and 32752 respectively. Use of
other values can result in a file that is unusable by RMF
Monitor III.
-A S0C4 Abend in ASMRMFV CPU table processing is corrected
that occurred when no other LPAR data was present. This
was most likely when a z/OS guest was running under z/VM.
-VMACRMFV did not correctly input the OSDKASID and
OSDPLIST fields from Summary Information section in the
OPD table.
-The following RMF Monitor III table records are now
blocked for efficiency in ASMRMFV output: CPD, CSR, ENT,
OPD, and SPG. This improvement results in up to 90%
reduction or more in output record count. However, this
means there are multiple data segments in each record
which can affect existing logic in any user modified
EXZRBxxx exit routines for the respective table.
VMACRMFV is upgraded to handle the additional data
entries in the blocked tables.
-Tutorial: Your tailoring logic in EXdddddd dataset exits
to control output of an MXG dataset needs this structure
to always be safe:
IF something THEN DO;
OUTPUT _Wdddddd;
END;
and can't use a DELETE, RETURN, nor "IF something;" logic
because when "something" is true, they stop the read of
this current record, skipping any un-read segments from
being tested for "something".
-Validity checking for the CPD, CSR, DVT, ENT, OPD, and
SPG tables in ASMRMFV for excessive or invalid header and
entry length is improved. When anomalies are detected
the entire table will be skipped. This should be a very
rare event.
-Prologue documentation in ASMRMFV source code has been
updated as needed including more discussion on skipped
records and entry blocking.
-NOTE: An assembly and link of each new ASMRMFV member is
ALWAYS STRONGLY recommended, keeping ASMRMFV and VMACRMFV
in sync, to create AND populate the new variables, enable
table record entry blocking, and implement other related
fixes/enhancements in this change.
-HOWEVER: Using the new VMACRMFV to process RMFBSAM data
created with the prior ASMRMFV program should not fail
unless invalid records are found, but all new variables
will have missing values.
Change 30.094 -SMF 113 counters were stored in the MXG DEFAULT=5 length,
ASUM113 but the four sets of counters can contain very large data
VMAC113 values, so variables BASICnn,PROBSTnn,CRYPTOnn,EXTNDnnne
May 28, 2012 are now stored in LENGTH 8, and the PROC MEANs in both
VMAC113 and ASUM113 now specify /INHERIT so the longer
length attribute will be preserved; comparison of short
and long length showed the longer length was needed as
there were some (smaller) values with shorter length.
-Variable SM113CST is removed from BY macro _BTY113 and
that macro matches the final sort order of PDB.TYPE113.
SM113CST was needed in the BY list for the intermediate
sorts but did not exist in the final PDB.TYPE113.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.093 If production jobs create reports that are sent to a data
ANALDB2R set or a report archive facility, but there was no data
May 28, 2012 matching your selections, the result is an empty file or
a nonexistent report. While MXG's SASLOG tells you that
happened (obscurely?), now, a message that no report was
produced is written to the output destination for these
reports: PMACC01 PMACC02 PMSTA02 PMAUD01 PMAUD02 PMAUD03
Change 30.092 If you have IMACEXCL in your "USERID.SOURCLIB", these new
UTILEXCL CICSTRAN duration variables were 16 times too large:
May 24, 2012 ISIOWTTM WMQGETTM MAXTTDTM T8CPUTTM MLXSSCTM JVMTHDTM
WMQASRTM RMITOTTM RMIOTHTM RMIDB2TM RMIDBCTM RMIEXDTM
RMIMQMTM RMICPSTM RMITCPTM
because UTILEXCL had generated incorrect code to convert.
Durations input as &PIB.4.6 use X=16*X;
Durations input as &PIB.8.6 use X=X/4096;
The incorrect syntax was X=16*X/4096; for 8.6.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.091 Typoed character P in column one caused INPUT EXCEEDED in
VMACSVIE SVSUBTYP=27 records that had segment 21 data.
May 24, 2012
Jun 5, 2012
Thanks to Sam Knutson, GEICO, USA.
Change 30.090 Variable FERTREMI incorrectly contained the Local instead
VMACFERT of the Remote IP Address.
May 22, 2012
Thanks to Terry Back, Experian, USA.
Thanks to Jerome Vitner, Experian, USA.
Change 30.089 Support for DB2 V10 APAR PM24723 for IFCID=225 SMF ID=100
VMACDB2 Subtype=4, which COMPATIBLY adds new storage metrics that
May 22, 2012 are output in both DB2ST225 and DB2STATS datasets.
Thanks to Kerry J. Sommers, John Deere, USA.
Thanks to Ralph Baechle, John Deere, USA.
Change 30.088 MQMLOG datetime variables were on GMT clock; there is no
VMAC115 offset field, but these maximum values must be less than
May 17, 2012 the SMFTIME, so the variable GMT115TM is calculated from
SMFTIME-QJSTIOMAXIOT1 and used to adjust datetimestamps
to the local time zone.
Thanks to Joe Faska, Depository Trust, USA.
Change 30.087 Variable TOTDEVHR in TYPE74CA had non-missing values that
VMAC74 were wrong when CACHIOTT was zero or missing; an MXG typo
May 14, 2012 set non-existent variable name TOTDEVNR to missing when
variable TOTDEVHR should have been set to missing value.
Thanks to Sharon Moir, JP Morgan Chase Bank, USA.
Change 30.086 Change 28.276 added BEGTIME= ENDTIME= parameters to
ANALHSM ANALHSM but, in the first step, the BEGTIME and ENDTIME
May 12, 2012 MACRO variables were set to the beginning of the data
and the end of the data so that those values could be
placed in the title lines of the reports. So all
subsequent use of those macro variables and checks for
their existence would be based on the timespan of the
actual data. To make matters worse, in REPORT 5 and
REPORT 6, the BEGTIME and ENDTIME datetime values were
being compared to TIME values for FSRTIMR and FSRTIME
so no data could ever be selected for those reports.
With this change the date/times for the report headings
are changed to BEGREPT and ENDREPT avoiding the
conflict with BEGTIME and ENDTIME selection and in
reports 5 and 6 datetime values are constructed as
they are in ASUMHSM so that the correct data can be
selected for the reports. There are also now MXGNOTEs
that will tell you when you have started processing the
data for each report and another if no data was found
for the report.
Thanks to Paul Volpi, UHC, USA.
Change 30.085 Cosmetic. UNMODSMF time is now aligned under SMFTIME to
VMACSMF make comparisons easier, and the _N_ value of LAST RECORD
May 9, 2012 IN GROUP message is no longer a missing value.
Change 30.084 ODS operator RS=NONE added to prevent wrapping of HTML
VMXGODSO statements (specific to z/OS but causes no problem for
May 9, 2012 ASCII ODS operations; only set for HTML output).
Change 30.083 -MXG 30.02, z/OS Only, SAS 9.1.3 SP4 Only:
VMAC71 ERROR: DOMAIN ERROR.
May 9, 2012 ERROR: TERMINATION DUE TO FLOATING POINT EXCEPTION
occurred in a PROC MEANS of DATA=TYPE71 in JCLTEST9.
This error did NOT occur with SAS 9.3 nor on ASCII SAS.
The Floating Point Exception resulted from MXG INPUTing
SMF71TLS field as RB4 when the field is binary (PIB4),
and a value of '00000AD1'x read as RB4 produced a value
that was a negative with E75 exponent, but it was only
when that value was subsequently read by PROC MEANS that
the error surfaced.
Thanks to John Loch, HP, USA.
Change 30.082 Type 60 record with no VVR segment (for a VVDS) caused an
VMAC60 INPUT EXCEEDED RECORD LENGTH error on 3 days, and then
May 7, 2012 didn't. MXG now tests to verify a VVR segment exists (and
VVRLEN will be a missing value in these observations) but
why these records were created is unknown.
Thanks to Peter Krijger, ANZ National, NEW ZEALAND.
Change 30.081 Enhancement adds rundays=mon tue wed ... to list the days
BLDSMPDB of the week when BLDSMPDB is to actually be executed; on
May 7, 2012 any other day, the program will terminate with MXGNOTEs.
The default, daily, is unchanged.
Thanks to Mynard Holloway, Spectrum Health, USA.
Change 30.080 Actual GDPS records exposed wrong guesses I made when I
VMAC105 wrote code from the documentation: GDPS datetimestamps in
May 4, 2012 SM105STM/DTM/SST/SCT are reversed-SMFSTAMP8 with DATE
Jun 4, 2012 first, so simple SMFSTAMP8 format can't be used; DURATM
field is packed decimal not binary and needs divide by an
undocumented 10; the two RPO duration variables SM105SAR
and SM105SIR also needed an undocumented divide by ten;
the Product section's two variables are input and kept.
-Jun 4: IBM stored blanks for SM105SCD and SM105SCT which
caused INVALID data error. Test for blanks circumvents,
while a PMR is opened for the invalid data.
Thanks to Jeffrey A. Johns, UHC, USA.
Thanks to Paul Volpi, UHC, USA.
Change 30.079 Cosmetic. Using EXEC SAS,CONFIG=CONFIMXG and MXGNAMES,
VMXGINIT DSNAMES in the //SOURCLIB concatenation are dynamically
May 4, 2012 allocated in reverse order to their concatenated order,
and dataset SASHELP.VEXTFL, which MXG reads to print the
DSNAMES on the log at initialization, is also reversed.
A PROC SORT of VEXTFL by DESCENDING LEVEL was inserted to
get the MXG list in correct order when CONFIMXG was used.
When MXGSAS93 and "static" allocation is done in JCL, the
value of LEVEL is zero and the DSNAMES are in the right
order; the sort doesn't alter that correct listing order.
Change 30.078 CICS Statistics storage variables in Change 29.221 were
VMAC110 thought to be in GB, and were multiplied by 1073741824,
May 28, 2012 but they are in MB, so they were 1024 times too large.
These variables are now multiplied by only 1048576 to
convert MB to bytes for the MGBYTES format:
SMSDSASZ SMSHWMDS SMSCSIZE SMSFSTG SMSHWMFS SMSLWMFS
SMSLFA SMSGDCUL SMSGDHWL SMSGDCUR SMSGDHWM SMTHWMPS
Thanks to Homayoun Riaza, United Health Group, USA.
Change 30.077 -READDB2 internal parsing was revised to correctly process
READDB2 %LET MACKEEP=
May 3, 2012 MACRO _WDB2ACP DB2ACCTP.DB2ACCTP %
MACRO _SDB2ACP %
;
%READDB2(IFCIDS=ACCOUNT STATS,
WANTONLY=DB2ACCT DB2ACCTP DB2STATS DB2STATB,
PDBOUT=YES,LDB2ACC=DB2ACCT,LDB2STB=PDB);
to create only DB2ACCT.DB2ACCT, DB2ACCTP.DB2ACCTP,
PDB.DB2STATS and PDB.DB2STATB datasets in those LIBNAMEs.
-IFCID=STATS creates only/both PDB.DB2STATS & PDB.DB2STATB
but Change 27.322 incorrectly listed only DB2STATS so the
comments in READDB2 were clarified.
-Minor logic changes: DB2STATB routing was suppressed with
STATS, and SMF IDs to be read message only showed 101.
-Cleanup 106 message, detritus in WORK when IFCID=STATS is
used (newish STATS creates ONLY the PDB.DB2STATS dataset)
with PDBOUT=YES.
Change 30.076 If USERADD= specified 102.xxx, but the length of xxx was
UTILBLDP less than 3 (e.g. 102.23 instead of 102.023), incorrect
May 2, 2012 macro token _C10223 instead of _C102023 was created which
caused unreferenced macro error. Not reported by a user.
Correction was when &LENGTH(&STRING2) was 1 or 2.
Change 30.075 -Variables JOB JESNR JBL24 are now kept in TPMJBL24.
VMACTPMX -Variable READTIME is now kept in all TPMJBLxx datasets,
May 2, 2012 since READTIME as well as JOB and JESNR are required to
uniquely identify a "JOB".
-Variable TPMPCSDIFFER is now input as IB because it can
contain negative values.
Thanks to Scott Barry, SBBWorks Inc, USA.
Change 30.074 Cosmetic. WARNING: MULTIPLE LENGTHS FOR BY VARIABLE LCU
ANALFIOE is removed with LENGTH DEFAULT=&MXGLEN added in the DATA
Apr 28, 2012 step that creates LCU from LCUID in TYPE78CF. There was
no error because the two lengths were 5 and 8 and LCU is
only a 2-byte binary number.
Thanks to Dan Case, Mayo Clinic, USA.
Change 30.073 Support for CA Vantage Storage Resource Manager 12.6.00,
VMACSAMS INCOMPAT: SAMSLGVR='X' in new records; MXG tested GE '6'
May 29, 2012 when SAMS code was last updated. SAMSPOOL fields were
restructured, from 4 to 8 bytes, some from PD to PIB.
New variables created in SAMSPOOL dataset:
SAMSSYSP='SYSPLEX*WHERE*VANTAGE*RUNS'
SAMSLPAR='LPAR NAME*WHERE*VANTAGE*RUNS'
SAMSSUBS='SUBSYSTEM*WHERE*VANTAGE*RUNS'
SAMSHASL='LOCAL*HASH*VALUE'
SAMSHASG='GLOBAL*HASH*VALUE'
Thanks to Robert Brosnan, Goldman Sachs & Co., USA.
Change 30.072 Support for RMF 74 APAR OA36831 which COMPATIBLY adds new
VMAC74 SMF74NSS='SKIPPED*SAMPS*INVALID*DELTA VALUE'
Apr 21, 2012 to TYPE74 dataset.
Change 30.071 VMACTPX, written before _Vdddddd old-style macro were
VMACTPX designed, is updated to define and use those alternative
Apr 21, 2012 tokens to control what's kept in MXG datasets.
Thanks to Erling Andersen, SMT Data, DENMARK.
Change 30.070 Support for CA-Spool Subtype 12 creates CNA9CX dataset,
EXCMA0CX but only creates the seven variables that were recognized
IMACCMA by format and content with the subtype 11. Additional
VMACCMA data fields will be decoded when documentation received.
VMXGINIT
Apr 21, 2012
Thanks to Orjan Lindholm, Volvo, SWEDEN.
Change 30.069 These new in z/OS 1.13 TYPE72GO vars were not populated
VMAC7072 CPUPDPTM R723RTDM R723RTDC R723RTDT
Apr 20, 2012 because the test was 32 when only 24 bytes were added.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 30.068 RMM dataset EDGRDEXT was expected, but the "D" and "V"
VMXGDSN records were combined into the "X" record, so DAILYDSN
Apr 20, 2012 was revised to use EDGRXEXT instead of EDGRDEXT.
Thanks to Jeff Dyke, USDA, USA.
Change 30.067 LUNAME added where possible to SMF ID=119 example report.
ANAL119
Apr 19, 2012
Change 30.066 New version of Ferret record is supported for subtype 1
VMACFERT and 4, based on test data without the vendor's DSECT.
Apr 20, 2012 -FERRET subtype 1 record with length of third triplet 80
caused INPUT STATEMENT EXCEEDED because that segment was
82 bytes in prior records. A LENLEFT test to protect was
added, but removing the +2 appears to realign subtype 1.
-FERRET subtype 4 record removed the +6 bytes at start.
Thanks to Bruce Sloss, PNC Bank, USA.
Change 30.065 Vendor segment for ETFR ID=80 SMF record caused MXG to
VMAC80A have INPUT STATEMENT EXCEEDED RECORD. Previous FRI=02
Apr 18, 2012 had an extra byte (in 2004 when ETFR segment was last
updated!) that is not there now, DO Group bypassed.
Thanks to J. Grasing, Metropolitan Life, USA.
Change 30.064 Support for new MQ QJST 7.01B Stats Block adds 4 sets of
VMAC115 ten variables with log statistics for each of up to four
Apr 18, 2012 logs in the MQLOG dataset.
Thanks to Joe Faska, Depository Trust, USA.
Change 30.063 The SMF 117 subtype 'IMFL' new variable SM17ACCT with the
VMAC117 'ACCOUNT*ORIGIN' is input and kept when it exists in the
Apr 17, 2012 WebSphere 7.0.0.3 SMF record.
Thanks to Fabio Ottaviani, EPVTECH, ITALY.
====== Changes thru 30.062 were in MXG 30.02 dated Apr 15, 2012=========
Change 30.062 TYPE70 variable ENHDATAR='ENHANCED*DAT*ARCHITECTURE?" is
VMAC7072 now created from Bit 7 of SMF70PRF.
Apr 12, 2012
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 30.061 BETA93 subtype 25 records support is revised to match the
VMACBETA data records. The documentation for 4.1 release is wrong,
Apr 12, 2012 as there are not 256 reserved bytes at the end, which
caused INVALID DATA FOR BETASTRT messages, and support
for the 4.2 was wrong, causing INPUT STATEMENT EXCEEDED
RECORD LENGTH errors.
Change 30.060 Support for TMON/DB2 V5, INCOMPATIBLE, only for DB2 V10.
EXTMD2BA Completely restructured records with new dataset names
EXTMD2BB and new variable names, so your reports will have to be
EXTMD2BC revised to use new MXG dataset names and variable names.
EXTMD2BD The new product suffix is TMD2, replacing TMDB, so you
EXTMD2BE will need to change your input DDname to //TMD2IN and
EXTMD2BF your MXG %INCLUDEd program to TYPETMD2 or TYPSTMD2.
EXTMD2BG
EXTMD2BH DDDDDD MXG MXG SIMILAR TO
EXTMD2BJ DATASET DATASET DATASET OLD TMDB
EXTMD2BK SUFFIX NAME LABEL DATASET
EXTMD2BL
EXTMD2DA TMD2BA TMD2BA SET CURRENT SQLID
EXTMD2DB TMD2BB TMD2BB End of Identify
EXTMD2DC TMD2BC TMD2BC End of Signon
EXTMD2DE TMD2BD TMD2BD Authorization Failure
EXTMD2DW TMD2BE TMD2BE Explicit GRANT/REVOKE
EXTMD2IB TMD2BF TMD2BF DDL on Audited Object
EXTMD2ID TMD2BG TMD2BG Write on Audited Object
EXTMD2IG TMD2BH TMD2BH Read on Audited Object
EXTMD2II TMD2BJ TMD2BJ Utility started
EXTMD2IP TMD2BK TMD2BK Utility Change
EXTMD2IT TMD2BL TMD2BL Utility End
EXTMD2PK TMD2DA TMD2DA INTERVAL SYSTEM STATISTICS TMDBDA
EXTMD2QS TMD2DB TMD2DB Thread Accounting Data TMDBDB
EXTMD2SD TMD2DC TMD2DC DB2 Command Activity
EXTMD2SL TMD2DE TMD2DE Exception Definition/Event
EXTMD2ST TMD2DW TMD2DW DB2/IRLM Messages
EXTMD2TB TMD2IB TMD2IB Interval BP Statistics TMDBDAB
EXTMD2TD TMD2ID TMD2ID Interval DDF Statistics TMDBDAF
EXTMD2TG TMD2IG TMD2IG Interval GBP Statistics
IMACTMD2 TMD2II TMD2II Interval IFCID Statistics
TYPETMD2 TMD2IP TMD2IP Interval Data Set Statistics
TYPSTMD2 TMD2IT TMD2IT Interval IFI Trace Dest
VMACTMD2 TMD2PK TMD2PK Thread Package Accounting TMDBDBK
VMXGINIT TMD2QS TMD2QS SQL Analyzer Statistics
Apr 10, 2012 TMD2SD TMD2SD System Deadlock Detail
TMD2SL TMD2SL System Deadlock/Timeout Victim
TMD2ST TMD2ST System Timeout Detail
TMD2TB TMD2TB Thread BP Accounting TMDBDBB
TMD2TD TMD2TD Thread DDF Accounting TMDBDBF
TMD2TG TMD2TG Thread GBP Accounting
All datasets have been extensively validated with test
data records, but with 10,000 new lines of source code,
there is some possibility of overlooked items.
The original VM/XA MONWRITE support was also 10K lines
and took 150 hours across 10 days. This project took
only 5 days and about 50 hours, in part because you
can teach an old dog new tricks, but also because the
vendor "$$" aggregation file was used to generate each
INPUT line for each variable, with its INFORMAT and
LABEL; most of the rest of the time was spent
comparing each line with the DSECTS to find the
reserved fields that were not in the $$ file and to
find the undocumented bytes added for fullword
alignment.
MXG previous support for pre-V5 TMON/DB2 did not support
any of the 'Bx' records (because no one sent sample data
records indicating they wanted those records supported!),
but since ASG Technical Support provided samples of EVERY
record type, ALL records, including the records that are
new in V5 (DB2 Command, Deadlock/Timeout, DataSet Status,
and the new Interval and Thread data) are supported and
ALL have been data-tested (so hex-containing strings, the
times and datetimes should be correctly formatted).
Check with ASG Customer Support that you have all PTF's
installed; not all datetimestamps were converted to the
local time zone, and some alignment corrections in new
records.
Change 30.059 -BLDSMPDB uses an execution of VGETSORT to build a list of
BLDSMPDB the datasets for weekly and monthly processing. In the
Apr 9, 2011 case of monthly it was looking at the WEEK LIBNAME rather
than the WEEK1 LIBNAME. On ASCII this was not a problem
since both WEEK and WEEK1 existed albeit pointing at the
same directory, but on zOS that was not necessarily the
case. VGETSORT was changed to point at WEEK1.
-When monthly/weekly was not being run and AUTOALOC was
set to NO, BLDSMPDB displayed a message that WEEK and
month LIBNAMES contained a date range that could have
been in error or not even existence. Message is now
suppressed when AUTOALOC=NO.
-Value of SORTEDBY is forced to NO when the length of
MXGNOBY is greater than 0 to suppress the BY statements
in WEEKLY/MONTHLY processing to optimize performance.
Change 29.008 removed BY processing for WEEK/MONTH in
old WEEKBLD/MONTHBLD logic, so BLDSMPDB is consistent.
Change 30.058 -New variables added to RMF TYPE71 dataset by z/OS 1.13
VMAC71 that were overlooked:
Apr 2, 2012 SMF71L7M='MIN 1MB*FIXED*FRAMES*NOT IN USE'
SMF71L7X='MAX 1MB*FIXED*FRAMES*NOT IN USE'
SMF71L7A='AVG 1MB*FIXED*FRAMES*NOT IN USE'
SMF71TLS='TOTAL*NUMBER OF*LOGICAL*SWAPS'
-SMF71LFA, added in MXG 30.01 was incorrectly aligned.
-And, starting with z/OS 1.13 the Swap Placement Section
does not exist, so the below 66 variables won't exist, so
you could DROP them all from your TYPE71 dataset when all
your systems are at that level, with this statement in
the //SYSIN stream that builds your TYPE71 dataset:
%LET MACKEEP= MACRO _KTY71 DROP=
SWAPTO PHYAUXTO LOGEXTTO LOGAUXTO PHYEXTTO EXTAUXTO
SWAPTI PHYAUXTI LOGEXTTI LOGAUXTI PHYEXTTI EXTAUXTI
SWAPWT PHYAUXWT LOGEXTWT LOGAUXWT PHYEXTWT EXTAUXWT
SWAPAS PHYAUXAS LOGEXTAS LOGAUXAS PHYEXTAS EXTAUXAS
SWAPRS PHYAUXRS LOGEXTRS LOGAUXRS PHYEXTRS EXTAUXRS
SWAPDW PHYAUXDW LOGEXTDW LOGAUXDW PHYEXTDW EXTAUXDW
SWAPVR PHYAUXVR LOGEXTVR LOGAUXVR PHYEXTVR EXTAUXVR
SWAPNQ PHYAUXNQ LOGEXTNQ LOGAUXNQ PHYEXTNQ EXTAUXNQ
SWAPEX PHYAUXEX LOGEXTEX LOGAUXEX PHYEXTEX EXTAUXEX
SWAPUS PHYAUXUS LOGEXTUS LOGAUXUS PHYEXTUS EXTAUXUS
SWAPNS PHYAUXNS LOGEXTNS LOGAUXNS PHYEXTNS EXTAUXNS
% ;
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 30.057 Support for TS7700 Version 2.0a (INCOMPATIBLE, due to
FORMATS insertion of new fields and increases in lengths of some
VMACBVIR existing fields, impacting BVIR30 and BVIR32 datasets).
Apr 1, 2012 -New variable in dataset BVIR30:
AVGCPUSE='CPU*USAGE*PERCENT*AT END OF*INTERVAL'
-New variables in dataset BVIR33:
DVMECC00='00*MEDIA*TYPE*CONTAINER*COUNT'
5 more new variables
DVMECC07='07*MEDIA*TYPE*CONTAINER*COUNT'
DVMTC010='POOL 01 MEDIA 0*MEDIA*TYPE*CONTAINER*COUNT'
254 more new variables
DVMTC327='POOL 32 MEDIA 7*MEDIA*TYPE*CONTAINER*COUNT'
-FORMATS was updated for new media types JC, JY and JK.
Thanks to Louis Deledalle, BNPPARIABAS, FRANCE
Thanks to Perry Lim, Union Bank, USA.
Change 30.056 -The DSNBRECD observation for a VOLSER created from the
TYPETMS5 first DSNB record could have wrong values for variables
VMACTMS5 DSNBUSRU DSNBTMSI DSNBECAT DSNBABND DSNBISCA DSNBDFXU
Apr 4, 2012 DSNBWSCA DSNBDFLT
because those variables had values from the TMSREC-DSNB.
Now, the DSNB values are temporarily stored, the DSNB for
the TMSREC DSN is created with those variables populated
from the corresponding TMSREC variables, and then the
DSNB variables are restored from temp storage.
-The values for DSNBECAT and DSNBWSCA in the DSNB created
from the TMSREC were reversed.
-Value for TRTCH 'D0'x set DEVTYPE of 3590 but it's 9840,
and some additional DEVTYPE values were enhanced to show
the EF3/EF3M/EF3X/EE3/EE3M/etc descriptor text.
-In diagnosing the error, I also observed an inconsistency
in MXG logic for TMSREC observations that have SCR='Y',
i.e., Scratch List VOLSERs: MXG did not create the pseudo
DSNB observation for the TMSREC DSN for scratched volumes
but all of the real DSNB observations are output, with no
flag they are on a Scratch Volume, as that is a TMSREC
and not a DSNBREC attribute. Now, that pseudo DSNB obs
is created for SCR='Y' volumes, and new variable SCRFLAG
is created in DSNBRECD so DSNBs on Scratch volumes can
be identified.
Thanks to Scott Rowe, Social Security Administration, USA.
Change 30.055 -Support for DB2 APAR PM37956 to SMF 102 IFCID 25 added
FORMATS several new variables, two of which are decoded by new
VMAC102 formats.
VMACDB2H -Cosmetic: VMACDB2H updated to prevent two "MISSING" value
Mar 28, 2012 calculation messages.
Thanks to Paul J. Larsson, Aetna, USA.
Thanks to Victoria Lepak, Aetna, USA.
Change 30.054 -ERROR: Divide by zero in SMF 73 records occurred in the
VMAC73 new FICON Extended Data segment when SMF73PTI=0, which
Mar 29, 2012 occurs for CHPIDs that are not ONLINE. The new MXG code
failed to test SMF73PTI before the division (even though
all other divides where!). Because TYPE73 observations
WERE only output if ONLINE='Y' and VALIDPTH='Y', these
segments that caused the divide by zero were not output,
so there was no impact on the contents of TYPE73 dataset.
All SMF73PTI divides are now protected.
-HOWEVER: The IBM Channel Path report does list CHPIDs
that are OFFLINE but have VALIDPTH='Y', so the logic in
VMAC73 is changed so that observations with EITHER the
ONLINE='Y' OR the VALIDPTH='Y' are output, in case you
actually need to see that a CHPID is offline. This will
cause a small increase in the number of observations that
are output in TYPE73 (256 CHPIDs are possible; in this
site's data, 59 were online and valid path, and 7 more
were valid path only that are now also output).
Thanks to Christine Ya DeClercq, DEXIA, BELGIUM.
Change 30.053 -Two variables were named CALTYPE, one in dataset VXSYTSPT
VMACVMXA that is a one-byte flag, and one in VXMTRPAG & VXSTOATC
Mar 21, 2012 which is a four byte field containing PAGE or SPOL, but
Apr 2, 2012 the second was truncated to one byte by the first. Since
CALTYPE in VXSYTSPT is a flag that is unlikely to be used
I have renamed it to CALTYPEP to eliminate truncation.
-Variable HFQUCT in VXBYUSR wasn't properly deaccumulated.
Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.
Change 30.052 Some packed decimal variables notably TPTDBIO were not
VMACIMS protected for a full hex-zero field value; the needed
VMACIMSA "double question mark" has been inserted in each INPUT.
Mar 21, 2012 Where the value is hex zero (because IBM did NOT prime
the field as a valid PD field) there is no impact on the
value of those variables as they will be a missing value
with or without the ??, but this change will eliminate
the INVALID DATA message and associated hex record dump.
Thanks to Paul Volpi, UHC, USA.
Change 30.051 Support for SYSVIEW PTF Test APAR TSD0144, for IMS data.
EXSV34ES Only SYSVIEW IMS records with that APAR can be read with
EXSV34SU this update; revisions to subtypes 34 and 35 were made.
IMACSVIE -New SV34ESS and SV34SUMM datasets are created.
VMACSVIE -Change 29.273 found LTERM names 'FDFFFFFF'x, which is the
VMXGINIT indicator the transaction originated in MQ and entered
Mar 30, 2012 IMS via OTMA: in this case, there isn't an LTERM, but the
Apr 2, 2012 next 8 bytes is the TPIPE name (e.g. CSQ800B9, which is
Apr 26, 2012 in LUNAME field), so that TPIPE name is now used for the
Jun 4, 2012 LTERM name. Some records for OTMA transactions have the
LTERM name for TCP/IP port number. MXG keeps the hex
value in IMTR_TRN_LTERM_HEX and stores LUNAME into LTERM.
-In IMS V9, DBIOTIME and LOCKTIME fields are only valid in
records from DBCTL subsystems, so those fields are set to
a missing value when they are not valid.
-Jun 4: two variables are no longer divided by /4096 :
IMTR_CLK_MPP_CPU
MQRR_OBJ_INTERVAL
Thanks to Martin Trinkler, CSC, ENGLAND
Thanks to Arthur G. Hurlston, CSC, ENGLAND
Change 30.050 Support for SMF 85 records from z/OS 1.13 (INCOMPAT, due
VMAC85 to new value of R85PVRM='1130'.
Mar 20, 2012
Thanks to Joachim Sarkoschits, DATAEV eg, GERMANY.
Change 30.049 An extra semi-colon in the non-graphics PROC PLOT caused
ANALCNCR an error and was removed.
Mar 19, 2012
Thanks to Steve Dyck, Canadian Depository, CANADA.
Change 30.048 If you specified a 9-character SAS date literal value, eg
VGETDDS 12MAR2012, only the first 7 characters were used, causing
Mar 19, 2012 the constructed Julian Date to be incorrect as 2020072.
Thanks to Brian Harvey, HCL America, USA.
Change 30.047 Support for BMC Mainview for MQ Version 5.1 (INCOMPAT).
EXBBMQAL MXG did not protect for changed segment lengths so this
IMACBBMQ update is required to read 5.1 data records. The new
VMACBBMQ RTIN='EA'x record has not been tested, but it will create
VMXGINIT observations in new dataset BBMQALTS; some variables will
Mar 18, 2012 be changed to datetime variables instead of character
when test data is available.
Change 30.046 -If you specified SUPPRESS=110, that did not suppress the
UTILBLDP creation of CICSTRAN, which requires //CICSTRAN to exist.
Mar 18, 2012 -If CICSTRAN was suppressed, ASUMUOW/ASUMCICX were still
invoked, causing errors.
-New values for suppress of DB2STAT CICSSTAT were added so
you can separately suppress the statistical datasets.
Thanks to Chip Parsons Ingram Books, USA.
Thanks to Paul Volpi, UHC, USA.
Change 30.045 Debugging PUT _N_= CPUUNITS= CPUTCBTM= removed; added for
VMAC30 testing of Change 29.025.
Mar 14, 2011
Thanks to Murali K. Inuguru, CSC, India.
Change 30.044 -Updates to D062, D063, D060, VWRP, D059, D057, VWVS.
VMACNTSM -VMware.Guest.CPU
EXNTDTAL VWGCUSPC doesn't exist, removed.
EXNTDIRS VWGCSWTM /*SWAP*WAIT*(MILLISECONDS) */ added.
EXNTSRMD -VMware.Host.CPU - the two Core utilization fields
IMACNTSM VWHCCORA and VWHCCORB were mislabeled as CPU utilization
VMACNTSM Pending newdata/newnames updates to QLSS QLSE
VMXGINIT QLSS: MSSQL:SQL STATISTICS
Mar 11, 2012 QLSE: MSSQL:USER SETTABLE
Apr 15, 2012 New objects are now supported in Apr 15 iteration:
NTDTAL DTS.ALERTEVENT - 4 DTAL.... vars
NTDIRS DIRECTORYSERVICES - 164 DIRS.... vars
NTSRMD SERVICEMODELSERVICE 3.0.0.0 - 33 SRMD.... vars
User-found corrections after Mar 11 iteration:
vmware_guest_virtualdisk - keep D0590007-13.
vmware_host_storagepath - length of D0630009
changed to $128. This is actually the concatenation of
three 32+ byte worldwide names (WWN). In my data they
are delimited by periods but I'm not sure that will
always be the case so let the user parse.
VMware.Host.Aggregate - Add VWGCVMGU to keep list
VMWARE.GUEST.RESCPU - ELSE removed, dropped host/guest.
VMware.Host.CPU - Changed VWHCCPU to integer
VMWARE.HOST.MEMORY - vwhmtotc was too large
Thanks to Jim Quigley, ConEd, USA.
Change 30.043 RMF III dataset ZRBASI Report Class Name/Description vars
VMACRMFV ASIRNM and ASIRDE can have hex zero values, because IBM
Apr 13, 2012 relocated the fields; SVPDCL is now 144 vs the documented
and expected length of 76. Now, ASIRNM is tested for hex
zero and the INPUT moved when found true.
-Same change made for ZRBENC for ENCRNM and ENCRDE.
-Compatibility fix for RCDSDI field in RCD table record.
In older versions of ASMRMFV the offset to the RCDSD
(Subsystem Delay) section of the RCD record can be
incorrect causing an INPUT LENGTH EXCEEDED error and
VMACRMFV termination. This fix recalculates the value of
RCDSDI using other known valid fields.
-RCD table flag variable RCDEFLAG is input as character,
but is actually a hexadecimal value. Format $HEX2. is
added for this variable for a correct display. NOTE:
Variable RCDSDPH contains the decoded value of RCDEFLAG
for ease of use.
-Compatibility fix for ASIRNM/ASIRDE variables in ZRBASI
file and ENCRNM/ENCRDE variables in the ZRBENC file. The
Service Class data extension used to build these files
can have a length of 144 bytes instead of the documented
length of 76 bytes. This caused VMACRMFV to input the
following Report Class data extension incorrectly so that
these fields had bad values. This fix accommodates a
length of 144 or 76 for the Service Class extension.
-The indexing variable to input the RCDSD array entries
was _I_ when it should have been _J_. The _I_ subscript
was already being actively used.
-Length checks used to validate input for the Service
Class and Report Class data extensions in the RCD table
were too short.
Thanks to Matthew Chappell, Dept. of Transport Main Roads, Australia
Change 30.042 -SMF AUDIT REPORT. The existing _RPTID report in BUILDPDB
ANALID is significantly enhanced, and new variables are created
FORMATS in the PDB.SMFRECNT to provide more detail of counts and
IMACSMFF percentages of records and bytes in your SMF data. Each
VMACID obs summarizes an ID.SUBTYPE (described by new $MGSMFID
VMACSMF format), but records with Subsystem or Product Version
VMXGINIT (DB2A V10, CICSPROD TS4.2, RMF 1.12) are reported at that
Apr 14, 2012 level of detail. Plus, all obs have the min/max SMF time,
May 12, 2012 and any compressed records (DB2,CICS) are flagged!
May 28, 2012 -The temporary WORK.ID dataset is created and summarized
Jul 4, 2012 to create the PDB.SMFRECNT used for the report, and the
May 6, 2013 new variables increase its size, but it is temporary, so
only //WORK space is used. For BUILDPDB, the INCREASE in
work space required is 25 CYL per Million SMF records.
When %ANALID(PDB=SMF) is executed standalone, 60 CYL of
//WORK space is needed per Million SMF records.
That small increase in BUILDPDB is because the old ID
dataset was compressed by default when it should not
have been; compression doubled its size (due to the small
number of variables), but even the new ID is 9% larger if
compressed, so the COMPRESS=NO Dataset Option is used for
the WORK.ID dataset to minimize its space requirement.
-If work space is an issue, you can disable creation of
the WORK.ID dataset with %LET SMFAUDIT=ZEROID in //SYSIN.
-If you want the original ID dataset without new variables
and you are not changing the MACRO _KTYID, then you would
use %LET SMFAUDIT=NO; in //SYSIN.
-If you want to add new or drop existing variables in the
ID dataset, or you want to change the MACRO _KTYID, you
MUST use the SMFAUDIT=YES default, and use MACRO _KTYID
to KEEP new or DROP old variables, and you must add the
COMPRESS=NO option in your replacement MACRO _KTYID as
shown below. To create new variables, your SAS code to
create them would be in MACRO _ETYID, as shown in this
syntax example (and as documented in member DOCMXG):
%LET MACID=
%QUOTE(MACRO _KTYID
DATE TIME
DROP=SMFTIME
COMPRESS=NO
%
MACRO _ETYID
DATE=DATEPART(SMFTIME);
TIME=TIMEPART(SMFTIME);
FORMAT DATE DATE9. TIME TIME12.2;
OUTPUT _WTYID;
%
);
%INCLUDE SOURCLIB(TYPEID);
RUN;
Note that %QUOTE() must be used; %STR() fails.
-The new Audit Report goes to PRINT by default, but it can
be redirected to ODS, on ASCII with this //SYSIN syntax:
%LET MACKEEP=%QUOTE(
MACRO _RPDBID
%ANALID(ODSTYPE=HTML,ODSPATH=E:,ODSFILE=ANALID.HTML);
%
);
%INCLUDE SOURCLIB(BUILDPDB);
or on z/OS, you would use this syntax:
%LET MACKEEP=%QUOTE(
MACRO _RPDBID
%ANALID(ODSTYPE=HTML,ODSPATH=MY.PDSE,ODSFILE=ANALID);
%
);
%INCLUDE SOURCLIB(BUILDPDB);
-You can also produce the SMF AUDIT REPORT directly from
an SMF file using:
%ANALID(READSMF=YES,PRINT=YES,PERCENTS=YES,PDBOUT=PDB)
to create all reports and the PDB.SMFRECNT dataset, and
additional arguments ODSTYPE=,ODSPATH=,ODSFILE= can be
specified on the %ANALID invocation for ODS/HTML output.
-VMACSMF was revised to create variable SUBSYSTEM for DB2,
CICS, MQ records (100-102,110,115-116), for 26's (JES2/3)
for 30s (JES3,TSO,STC,OMVS,etc.), for 6's (JES2/JES3/EXTW
PSF/PRINTWAY/CADI/BUNDLE/SAR/EXD), and PRODVERSION for
DB2 (V10), CICS (TS/4.2), RMF (ZV011300), and MQ (7.10).
This means that those variables are populated when the
IMACFILE/&IMACFILE exit is taken, so you can use them to
select those records by SUBSYSTEM/PRODVERSION either for
MXG processing, or if you want to write SMF records out
to a separate SMF file; see comments in IMACFILE.
Note May 6 2013: other attributes, such as COMPRESSED and
DB2 ACCUMAC status have been added to the report but this
text may not always be timely.
-Format $MGSMFID maps IBM SMF TYPE numbers and Subtype to
describe each record/subtype. User SMF records will be
counted by ID and subtype (if the subtype bit is on in
the USER record's SMF header), but with no explanation,
or counted just by ID if the subtype bit is NOT on in the
USER SMF record, but you can create your own description
of USER SMF record that will be added to $MGSMFID format
by using the IMACSMFF member in your tailoring library,
following it's comments for syntax of your USER records.
After you SAVE your IMACSMFF member into your tailoring
library, you then need to update the MXG format library
by running
//LIBRARY DD DISP=OLD
%INCLUDE SOURCLIB(FORMATS);
which will update the MXG Format Library.
If you can not update the site's format library, you
can create this new format in a separate dataset and
use OPTIONS FMTSEARCH=(MYLIB LIBRARY); in the ANALID job.
-Macro variable SMFAUDIT is defined in VMXGINIT.
-To summarize the overall options:
READSMF=YES read SMF, create WORK.ID or PDB.ID, create
PDB.SMFRECNT, delete WORK.ID or keep
PDB.ID.
READSMF=NO read WORK.ID/PDB.ID, create PDB.SMFRECNT,
delete WORK.ID or keep PDB.ID.
PRINT=ONLY read only PDB.SMFRECNT to print report.
-This rewrite of the _RPTID report was precipitated by:
The previously posted error that caused LARGE INCREASE
in elapsed run time when BUILDPDB had any output "PDB"
data libraries (//PDB, //CICSTRAN, //DB2ACCT, etc.) on
on tape or in sequential format.
That error is corrected in this change.
But, to document the error and a circumvention:
VERY long elapsed times in BUILDPDB if output PDB data
libraries (//PDB, //CICSTRAN, //DB2ACCT) are on TAPE:
PROC SQL reads the DICTIONARY.COLUMNS internal dataset,
but if any LIBNAME is on tape, the ENTIRE tape is read.
Site with 35 million CICSTRAN observations on tape took
3.5 hours to read SMF and then spend 3.1 hours in this
PROC SQL, just to create the report of ID counts; this
problem was introduced in MXG 29.03, Change 28.089.
If you do not have MXG 30.02 with this Change 30.042,
this Circumvention eliminates long elapsed times:
Insert this statement
%LET MACKEEP= MACRO _RPDBID _RPDBIDO % ;
in your //SYSIN DD input, or this macro definition
MACRO _RPDBID _RPDBIDO %
in your IMACKEEP tailoring member. This will revert
the SMF TYPE report to only count records.
-This change replaced PROC SQL with %VMXGOBS to correct
the elapsed run time error, and all other uses of PROC
SQL with DICTIONARY.COLUMNS have a specific LIBNAME, so
they had no exposure.
Thanks to Jim Hayes, Huntington National Bank, USA.
Thanks to Marty Pruden, Purina Nestle, USA.
Thanks to Michael Rhoades, Purina Nestle, USA.
Thanks to Michael Oujesky, Bank of America, USA.
Thanks to MP Welch, SAS Institute, USA.
Change 30.041 Support for EMC EzSM (z/OS Storage Manager) SMF record.
EXEZSM01 Preliminary support - problems in record have opened a
EXEZSM02 discussion with the vendor, but still no response when
EXEZSM03 MXG 30.02 was created.
EXEZSM04
EXEZSM05
EXEZSM06
EXEZSM07
IMACEZSM
TYPEEZSM
TYPSEZSM
VMACEZSM
VMXGINIT
Mar 7, 2012
Change 30.040 -Variable DOWNTM was a missing value in PDB.IPLS dataset
VMAC0 after Change 29.032 used only ID=90 ST=8/10 to identify
VMAC90A a true system IPL; the DOWNTM=IPLTIME-PREVTIME was not
VMACSMF calculated for subtype 10 and the operator entered DTIME
Mar 9, 2012 value was incorrectly used for the subtype 8 IPL PROMPT.
-Examination of events at a true IPL show that SMF records
0 8 22 90 are written prior to the IPL event, and ID 2,3
can be written on other systems at other times, so these
records are all NOT used to set PREVSYS/PREVTIME.
-VMAC90A was updated to contain DOWNTM and IPLTIME in the
TYPE9008 and TYPE9010 datasets, for consistency.
-Dataset PDB.IPLS was revised to contain the old variables
from the ID=0, even though it is created from ID=90/8-10.
Thanks to Jorge Fong, NYC Information Technology, USA.
Change 30.039 NDM-CDI record 'XO' caused "UNKNOWN SUBTYPE" log messages
VMACNDM because 'XO' was not in the test for supported subtypes,
Mar 6, 2012 but code was in place to output them in NDMDT dataset, as
it is the same record structure. Now, they are output.
Thanks to Betty Wong, Bank of America, USA.
Change 30.038 Support for DB2 IFCIDs 357 and 358; those datasets are
VMAC102 now populated with the IFCID-specific variables.
Mar 6, 2012
Thanks to Terry L. Berman, DST Systems, USA.
Change 30.037 Support for BMC APPTUNE V6R3 SMF 102 records (INCOMPAT).
VMAC102 These numeric variables were increased from 2 to 4 bytes
Mar 6, 2012 causing mis-alignment of all subsequent variables:
QBMCSCTN QBMCSTMT QBMCSOPN QBMCOPNN
and these two new variables are inserted and now input:
QBMCTXTH='SQL*TEXT*HASH'
QBMCIMPK='IMPLICIT*QUALIFIER*KEY'
and QBMCSQID QBMCIMPQ contain ASCII rather than EBCDIC.
BMC APPTUNE ID=102 IFCIDS are 8004x-800Bx & 8133x-8136x.
Only the 8133x record has been validated.
Thanks to Christa Neven, KBC, BELGIUM.
Change 30.036 On the first day of the month, the MTD value was
VMXGALOC calculated correctly but the MONTH value was the prior
Mar 2, 2012 month.
Thanks to Ruth Larsen, Computer Associates, USA.
Change 30.035 RSD/FOLDERS name fields were increased to $250, causing
VMACRSDA the AUDDNAME and other AUDDxxxx fields to be missing as
Mar 2, 2012 those fields were located after the AUDFxxxx variables.
Thanks to Christa Neven, KBC, BELGIUM.
Thanks to Marc Heremans, KBC, BELGIUM.
Change 30.034 VMXGGETM is used to select SMF records by ID and SUBTYPE,
VMXGGETM but only supported 512 subtypes; BMC's APPTUNE product
Mar 2, 2012 creates SMF 102 records with IFCIDS 8000x to 8136x which
caused VMXGGETM to fail with ARRAY ERROR. This change
increases the array to support 33078 (8136x) to protect
the BMC records, keeping the REGION size to about 84MB.
(VMXGGETM is also used in JCLTESTx to create SMFSMALL, so
I don't want new users to die with insufficient REGION in
their first MXG test job. Setting the array size to the
max possible 65536 for the two-byte field needed 150MB.)
Thanks to Christa Neven, KBC, BELGIUM.
Thanks to Wim Hermans, KBC, BELGIUM.
Change 30.033 Cosmetic. Missing value calculation for PHSTARTM when it
VMAC110 was missing is protected for ID=110 MNSEGCL=5 Resource
Mar 1, 2012 Record (dataset CICSRDS).
Thanks to Tom Buie, Southern California Edison, USA.
Change 30.032 -Stored LENGTH of QWHxxxxx variables now $128 in DB2ACCT.
VMACDB2 This text was re-written Mar 27, but no code was changed.
VMACDB2H These DB2 Variables are all now stored as LENGTH $128:
Feb 29, 2012 QLACLOCN QLSTLOCN QMDALOCN QPACAANM QPACASCH QPACCOLN
Mar 4, 2012 QPACLOCN QPACPKID QWHCAID QWHCCTKN QWHCEUID QWHCOAUD
Jun 8, 2012 QWHCOPID QWHCROLE QWHCTCXT QWHDRQNM QWHDSVNM QWHSLOCN
Oct 3, 2012 because IBM has increased those lengths (history below)
Mar 28, 2013 and now many of these variables do contain more than
eight bytes, especially if you have distributed systems
with those long open-system name fields.
But with the (MXG DEFAULT) COMPRESS=YES option enabled,
these stored lengths can be increased, so no data values
are truncated, without significant DASD space increase,
since most of those nine-plus bytes are still blank.
-However, you can change those lengths if, for example,
the CPU cost of compress is more expensive than the DASD
disk space cost. See NEWSLETTER SIXTY, Section VI.7,
in member NEWSLTRS for the complete documentation in
"Changing the length of MXG variables", which shows
this syntax can be used (only) for character variables.
//SYSIN DD *
%LET MACFILE=
%QUOTE( LENGTH
VAR1 VAR2 VAR3
$8 ;
);
%INCLUDE SOURCLIB(whatever);
Some History:
In 2004, IBM increased the length of several fields and
MXG Change 22.196 in 2004 increased INPUT to $128 for
QWHSLOCN QWHCAID QWHCOPID QWHCEUID QWHDRQNM QWHDSVNM
but that change noted that they were not stored as $128,
because in 2004 some MXG sites still had SAS V6 that did
not support COMPRESS=YES, which is required to increase
stored length without DASD increases (as most bytes are
still blanks).
Sometime after 2004, IBM increased header variables
QWHSLOCN and QWHDSVNM and MXG increased INPUT length.
MXG Change 24.136 in 2006 increased these INPUTs to $128
QWHCAID QWHCOPID QPACCOLN QPACLOCN QPACPKID
QLACLOCN QLSTLOCN QMDALOCN QWACNID
This change, 30.032 increased these INPUTs to $128
QWHCEUID QWHCTCXT QWHCROLE QWHCOAUD QWHDRQNM
QPACASCH QPACAANM
This change, 30.032 increased the stored lengths of all
of the DB2 variables listed above that were not already
kept as $128.
-Note added Jun 8: Some DB2 fields can contain an IP
address, Port Number, and a timestamp in this format:
162.123.25.218.44485.120605112901
-------------- ----- ------------
| | |
| | |-- Unique field ( timestamp real
| |
| |-- Port address
|
|- Requester IP Address
One example is QWHCCTKN the new Correlation Token in V10.
-Note added Oct 3, 2012: QWHCCV was restored to $12 by
Change 30.200.
-DB2 variable QWHDRQNM can now contain an ipv6 address,
which is longer than the default kept $16 length, causing
right-most characters to be truncated. Change 22.196 in
Thanks to Fred Wondra, Balboa Insurance, USA.
Thanks to Mark Nakatani, WiPRO, USA.
Thanks to Jim Meurer, Transamerica, USA.
Change 30.031 Requesting IFCIDS=ACCOUNT with IFCIDS from SMF 102 could
READDB2 cause zero observations in some or all of the T102Snnn
VMXGDEL datasets that were requested. This error was in 29.29
Feb 24, 2012 and probably earlier MXG READDB2s.
Mar 4, 2012 -Cosmetic. READDB2 accepts IFCIDS=1 or 2 for STATISTICS
and 3 for ACCOUNT and prints all selected IFCIDS in its
feedback list of what will be selected by READDB2.
Requesting ACCOUNT processes IFCIDs 3 and 239.
Requesting Statistics processes IFCIDs 1 2 202 225 230.
-A strange compiler error, only in SAS V9.2, inserted a
blank when MACRO _LDB2PAT &PDBOUT..DB2GBPAT % was at the
bottom of that list of macro definitions, causing compare
of WORK .DB2GBPAT with WORK.DB2GBPAT to be different, so
VMXGDEL incorrectly deleted that dataset. Relocating that
one line to the top of the list of MACROs happened to
circumvent the error, but that was far too fragile, since
another line relocation could reinstate the error, and as
VMXGDEL is the only part of MXG that does exact compares
of dataset macro tokens that could be impacted by a blank
after the DDNAME/LIBNAME, it now removes the blank.
Thanks to Christopher Bray, Experian Information Solutions, USA.
Change 30.030 Variable VMDSTATE is now decoded by $MGVXADS format.
FORMATS VALUE $MGVXADS
VMACVMXA '00'X='00X:IDLE'
Feb 23, 2012 '08'X='08X:SUSPENDED'
'2C'X='2CX:UNKNOWN'
'37'X='37X:TEST IDLE'
'42'X='42X:READY FOR SELECTION'
'4D'X='4DX:SELECTED FOR PROCESSING'
'58'X='58X:REVIEW IDLE'
'63'X='63X:REVIEW SUSPENDED'
OTHER=?< $HEX2. ?>
;
Thanks to Joe Faska, Depository Trust, USA.
Change 30.029 ODS macro enhanced with USERTEXT= argument so you can add
VMXGODSO options to the generated ODS statement.
Feb 23, 2012
Change 30.028 RMF III dataset ZRBASI Report Class Name/Description vars
VMACRMFV ASIRNM and ASIRDE can have hex zero values, because IBM
Feb 23, 2012 relocated the fields; SVPDCL is now 144 vs the documented
and expected length of 76. Now, ASIRNM is tested for hex
zero and the INPUT moved when found true.
-Same change made for ZRBENC for ENCRNM and ENCRDE.
Change 30.027 Variable SM1209BM, WebSphere Version Number, defaulted to
VMAC120 length $7 from the original equation, but as it can now
Feb 22, 2012 have a value of '7.0.0.15', its length is now set to $8.
Thanks to Rudolf Sauer, T-Systems International GmbH, GERMANY
Change 30.026 %UTILCPLG will copy your .LOG and .LST files, adding the
UTILCPLG date-time into the new file name, when you run MXG on
Feb 17, 2012 Windows or Unix platforms in BATCH execution, so you can
archive and identify each MXG job's log/list files.
The %UTILCPLG; statement must be the last statement in
your xxxxxxxx.sas batch program; the log filename will be
xxxxxxxx-16FEB12-19-51.LOG. The new named files are kept
in the execution directory by default, but arguments let
you store them in other destinations.
Thanks to Chip Parsons, Ingram Books, USA.
Change 30.025 Support for TMON for MQ Version 2.2/2.3/2.4 INCOMPATIBLE.
VMACTMMQ All three version's LMRKVRSN field changed from binary to
Feb 16, 2012 EBCDIC. Version 2.4 changed the fixed offset of @37 to
Feb 24, 2012 @81 but that was NOT documented. The actual data segments
Mar 1, 2012 content was not changed in these three iterations, and
Mar 5, 2012 only Version 2.2 and 2.4 have been validated with data.
-ASG TMON for MQ variables REGNTIME,QAINTS,QAINTE,QAOPENTM
and QACLOSTM were all on the GMT clock, while all other
datetimestamps are on the LOCAL clock. This change uses
the ENDTIME (LOCAL) and the REGNTIME (GMT) to calculate
the GMT offset (REGNTIME can be scores of milliseconds
later than ENDTIME due to differing resolutions):
GMTOFFTM=100*FLOOR((REGNTIME-ENDTIME+10)/100);
and then the GMT datetimes are converted to LOCAL using
REGNTIME=REGNTIME-GMTOFFTM;
-The label for REGNTIME was wrong; it is corrected to be:
REGNTIME='DACLK*WHEN RECORD*WAS WRITTEN'
Thanks to Homayoun Riazi, UHC, USA.
Thanks to Paul Volpi, UHC, USA.
Thanks to Michael Ellingson, UHC, USA.
Thanks to James D. Lieser, UHC, USA.
Change 30.024 New format MG073FE decodes SMF73GEN and R79CGEN FICON
FORMATS Express "Generation", precipitated by Martin's MXG-L post
VMAC73 and Pat's update request and Brian's reminder to include
VMAC79 79's, with some values below provided by Cathy.
Feb 17, 2012 Dec 2: IBM confirmed reports print the hex value, so MXG
Nov 5, 2012 now formats SMF73GEN as hex to be consistent with that
Dec 2, 2012 undocumented-by-IBM design, but RMF Level 2 has NOT been
able to document if any of the unknown values below exist
01X='01X:FEX OP@1GBPS'
02X='02X:FEX OP@2GBPS'
03X='03X:FEX2/FEX4 AUTO@1GBPS'
04X='04X:FEX2/FEX4 AUTO@2GBPS'
05X='05X:FEX4 OP@4GBPS'
06X='06X:????'
07X='07X:FEX8 AUTO@2GBPS'
08X='08X:FEX8 AUTO@4GBPS'
09X='09X:FEX8 OP@8GBPS'
0AX='0AX:????'
0BX='0BX:????'
0CX='0CX:????'
0DX='0DX:????'
0EX='0EX:????'
0FX='0FX:????'
10X='10X:????'
11X='11X:FC_S'
12X='12X:????'
13X='13X:FC_S*FICON EXPRESS8S'
Nov 5: Decimal value 17 and 19 were found by IBM's Martin
Packer although others in IBM support are apparently not
aware of those undocumented values.
Dec 2: APAR OA40204 reports 'FC_?' or blank value may be
printed for channels dynamically added; restart of the
RMF address space will correct to FC_S.
Dec 11: IBM RMF Level 2 confirmed that RMF reports show
value '13' unexplained for FICON Express 8S so the MXG
format was expanded to include that descriptions in the
FORMATS member and above.
Thanks to Dr. H. Pat Artis, Performance Associated, USA.
Thanks to Brian Currah, Independent Consultant, CANADA.
Thanks to Martin Packer, IBM, ENGLAND.
Thanks to Cathy Cronin, IBM, USA.
Thanks to Linda Berkeley, DISA, USA
Change 30.023 A third-party product creates invalid DB2 ID=101 records.
VMACDB2 MXG's error message cites 1994's Change 12.220 and APARs,
VMACSMF because IBM made the same error (IFCID=239 as subtype 0
Feb 14, 2012 versus correct subtype=1) back then. This change reads
the DB2 Header and uses the IFCID to set the SUBTYPE for
ID=101 to circumvent the product's error, so the customer
won't have to wait for their vendor to fix their record.
The error occurs in both DB2 V9.1 and DB2 V10.1 records;
in V10.1, IBM (finally!) populates the first byte of the
SMF header for ID=100/101 with the "record has subtypes"
bit, but that enhancement was not made in this product.
The MXG customer chose to not identify the third-party.
March 7: MXG customer reports vendor corrected the error.
But this change is robust and will be left in place.
July 27: See Change 30.137. This change was NOT robust!
Change 30.022 Cosmetic. Format $MGDB2PK was associated with variable
VMACDB2 QPACAAFG but was lost in 29.29 and 30.01. It is restored
Feb 14, 2012 now but FORMAT QPACAAFG $MGDB2PK.; can be used in your
DB2 reports to "print pretty".
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
====== Changes thru 30.021 were in MXG 30.01 dated Feb 13, 2012=========
Change 30.021 -Numerous updates for processing RACF Unload under ASCII.
EXRAC130 Variables input as $EBCDIC should have been $CHAR in 0500
EXRAC207 and later records; double-question-mark protection for
EXRAC208 missing values has been added.
EXRAC280 -New ACCOUNT variable is created in RACF0220 and RACF0260
EXRAC2B0 as length $40 containing both ACCOUNT1 and ACCOUNT2.
EXRAC508 -Structural support for new RECTYPE values defines all the
EXRAC5B0 macros and creates/updates the members to create datasets
IMACRACF for 0130,0207,0208,0280,02B0,0508 and 05B0, but in this
VMACRACF iteration, none of those records are yet decoded; only
VMXGINIT variable ZDATE is kept in those new datasets.
Feb 12, 2012
Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA
Change 30.020 Support for MacKinney Systems VTAM SWITCH USER SMF RECORD
EXVTSW01 creates these four datasets:
EXVTSW02 DDDDDD DATASET DESCRIPTION
EXVTSW03
EXVTSW04 VTSW01 VTAMSW01 USER SIGNON EVENT
IMACVTSW VTSW02 VTAMSW02 USER SIGNOFF EVENT
TYPEVTSW VTSW03 VTAMSW03 SESSION START EVENT
TYPSVTSW VTSW04 VTAMSW04 SESSION STOP EVENT
VMACVTSW This support has not yet been data-validated.
VMXGINIT
Feb 10, 2012
Thanks to Eric R. Carlson, Kroger
Change 30.019 Cosmetic. Both members incorrectly had RACFIN as the DD
TYPERACF name, but the correct DDNAME was always IRDBU00 to read
TYPSRACF the unloaded RACF Database, as that is also the program
Feb 10, 2012 name used to create the unloaded file.
Thanks to Donald Williams, UNC Health Care System, USA.
Change 30.018 -Cosmetic, but confusing. The label for TYPE4224 variable
VMAC42 AORMEMNM contained "RENAMED" but the corrected label and
Feb 9, 2012 events are AORMEMNM='ADDED OR*REPLACED*MEMBER*NAME'.
-New variable ADDREPLA contains A or R for ADD/REPLACED.
-Dataset TYPE4225 is created for RENAMEs.
Thanks to Joe Kimberly, Yellow Freight, USA.
Change 30.017 MXG 29.29 ITRM. ERROR: DATASET DB2ST225 IS NOT SORTED.
DOC ITRM SAS Note 45583 documents the error and ultimate fix,
Feb 9, 2012 but it is circumvented, simply, by inserting
%LET EPDBOUT=_SDB2225;
as the first statement in your //SYSIN DD.
Change 30.016 RMF III dataset ZRBLCP did not remove duplicates when it
VMACRMFV was sorted; variables LPARNAME LPARNUM LCPUADDR were
Feb 8, 2012 added at the end of MACRO _BZRBLCP to correct.
Thanks to Wayne Bell, UniGroup, USA.
Change 30.015 MXG 29.29. JCL Proc examples had a trailing comma on the
MXGSAS new (unused, for the future) //MXGTEMP DD statement that
Jan 24, 2012 needed to be removed.
Change 30.014 -Support for APAR OA33947/OA339448 which adds four fields
ASUMTAPE to the TYPE21/PDB.TAPES (tape dismount) dataset:
VMAC21 SMF21MCR='BYTES*READ*BY*CHANNEL'
Feb 8, 2012 SMF21MCW='BYTES*WRITTEN*BY*CHANNEL'
SMF21MDR='BYTES*READ*BY*DEVICE'
SMF21MDW='BYTES*WRITTEN*BY*DEVICE'
-ASUMTAPE was enhanced to also add these four variables,
plus SMF21CRR and SMF21CRW to PDB.ASUMTAPE.
-These fields exist with the APAR (record is longer), but
they are only populated for IBM System Storage TS1140
Tape Drive, device type 3592 Model E07, which has three
new 3592 media types (MEDIA11/12/13) and two new
recording formats EFMT4 (enterprise format 4) and EEFMT4
(enterprise encrypted format 4). MEDIA11/MEDIA12 have a
non-compressed capacity of 4000 GB and MEDIA13 500 GB.
Thanks to Scott S. Throckmorton, SPRINT, USA.
Thanks to John A. Napuarno, SPRINT, USA.
Change 30.013 If you specified RUNWEEK=YES on zOS you may have gotten
BLDSMPDB an MXGWARN message about overlaying weekly datasets. If
Feb 8, 2012 you are using fixed allocations for your weekly datasets
this is normal and can be ignore but, if you are using
GDGs (recommended) and/or putting the weekly to tape it
is not needed. BLDSMPDB now looks (on zOS) to see if
you specified WEEKTAPE=YES or are writing to a GDG and
then suppresses the copying of the weekly PDBs.
Thanks to Peter Farrell, Commerce Bank of Kansas, USA.
Change 30.012 Cosmetic. Removal of the annoying and useless SAS note
VGETOBS RUN STATEMENT HAS NO EFFECT ON PROC SQL, by the insertion
Feb 8, 2012 of a QUIT statement after each PROC SQL. Members touched:
VGETFMT VGETLABL VGETLEN VGETLIBS VGETOBS VGETVAR
VMXGCNFG VMXGDSNL VMXGENG VMXGLBIN VMXGOPTR VMXGPPDS
VMXGUOW ANALID
Thanks to Nick Johns, Sainsbury's Supermarkets Ltd, ENGLAND.
Change 30.011 CRITICAL ERRROR FOR JES3 BUILDPD3 users with MXG 29.29:
BUIL3005 Line 483 in BUIL3005 MUST BE CHANGED TO (MULTIDD=' ').
Feb 8, 2012 That line in 29.29 had MULTIDD='Y' which caused the PDB
library datasets PDB.JOBS/PDB.STEPS/PDB.PRINT to all be
COMPLETELY WRONG. Change 29.263 correctly made the change
to the BUILD005 member for JES2 but was reversed in the
JES3 BUIL3005 member.
Thanks to Rob Hermes, Sentry Insurance, USA.
Change 30.010 Variable STFBIT06 was incorrectly set equal to STFBIT05.
VMAC7072 Variable STFBIT07='SMF70GAU*VALID?' is created and kept.
Feb 8, 2012
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 30.009 -Support for SMF 119 Subtype 6 z/OS 1.13 INCOMPAT. Doesn't
VMAC119 cause an error, but values in 2nd and subsequent segments
VMXGIPV6 are trashed because MXG did not protect for a change in
Jan 31, 2012 length of the subtype 6 record.
Feb 7, 2012 -Subtype 2 TTAPLDAT variable supported.
Jul 12, 2012 -Support for all IPV6 addresses in TYPE119 datasets, using
the VMXGIPV6 %macro to convert the $CHAR16 hex field into
the 39-character format. Some IPV6 addresses did exist in
variables with names ending in 6, but this new suite of
variable's names end with IPV6.
-Only these SMF 119 subtypes have been validated with data
1,2,3,5,6,7,10,20,21,70 and 72.
-The subtype 2 record has an old note suggesting that
Because this information duplicates all information
contained in the TCP connection initiation (subtype 1)
record, only collect the TCP connection termination
record (subtype 2).
-Jul 13: Variable UCLIPV6 was not kept until now; it was
incorrectly spelled UCLIPB6 but could be added using
_KT11910.
Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Thanks to Robert Hamilton, Chemical Abstracts Service, USA.
Thanks to Jose Neto, Public Authority Civil Info, KUWAIT.
Thanks to Arylon Brooks, Verizon Wireless, USA.
Thanks to Scott S. Throckmorton, SPRINT, USA.
Change 30.008 CICS/TS 4.2 ERROR INVALID STILEN for STID=116 Statistics
VMAC110 record was an MXG coding error exposed by the 156 bytes
Jan 31, 2012 of new data that MXG had overlooked, causing the CICSJS
dataset to have no observations created, and possible MXG
skipping subsequent statistics segments in that record.
New variables added to CICSJS dataset are:
SJSGCPOL='GC*POLICY'
SJSHEAPC='CURRENT*HEAP'
SJSHEAPI='INITIAL*HEAP'
SJSHEAPM='MAXIMUM*HEAP'
SJSHEAPO='HEAP*OCCUPANCY'
SJSHEAPP='PEAK*HEAP'
SJSHVMCL='JVM*CREATION*DATETIME*LOCAL'
SJSJVMCG='JVM*CREATION*DATETIME*GMT'
SJSMAJCP='TOTAL*CPU IN*MAJOR*GC'
SJSMAJFR='STORAGE*FREED*BY*MAJOR GC'
SJSMAJGC='MAJOR*GC*COLLECTIONS'
SJSMINCP='TOTAL*CPU IN*MINOR*GC'
SJSMINFR='STORAGE*FREED*BY*MINOR GC'
SJSMINGC='MINOR*GC*COLLECTIONS'
SJSSYTHN='NR WAITING*ON*SYS*THREAD'
SJSSYTHP='PEAK*WAITING*ON SYS*THREAD'
SJSSYTHU='SYSTEM*THREAD*USE*COUNT'
SJSSYTTM='TOTAL*WAIT*SYSTEM*THREAD'
SJSSYTCN='WAITS ON*SYSTEM*THREAD'
Thanks to Thomas H. Puddicombe, CSC, USA.
Change 30.007 PMSTA01/PMSTA02 DB2 Statistics reports with INTERVAL=DATE
ANALDB2R created multiple observations for each date because SHIFT
VMXGDBSS was in the SUMBY= list in VMXGDBSS. That SUMBY argument
Jan 29, 2012 is now a parameter with the current default values and
uses the new parameter in ANALDB2R when required by the
requested INTERVAL value. Also, errors in page numbering
were cosmetic - no data was skipped - just page numbers
were, due to an extra LINK in the heading routine.
Thanks to Charles Savikas, DCF, State of Florida, USA.
Change 30.006 Support HSM USER SMF changes (COMPATIBLE) in z/OS 1.12.
VMACHSM -Dataset HSMDSRST:
Jan 29, 2012 DSRFRBKT DSRFRBKF DSRFRRCT DSRFRRCF
-Dataset HSMFSRBO:
FSRF9ATT FSRSRCDV FSRRETDY FSRDLMD FSRDLUD FSRBDATE
FSRDATRD FSRDLMD DSRDATED
-Dataset HSMFSRST:
FSRF9ATT FSRSRCDV FSRRETDY
FSRDLMD FSRDLUD FSRBDATD FSRDATRD FSRDLMD
-Dataset HSMVSRST:
VSRFRBKT VSRFRBKF VSRFRRCT VSRFRRCF VSRDATED
-Dataset HSMWWFSR:
WFSRCONT WFSRDATR WFSRRMTS WFSRDATE WFSRDATS WFSRRSTS
WFSRRETS WFSRXMNT WFSRHOST WFSRF9AT
-These existing variables still contain julian date values
DSRDATE FSRDLM FSRDLU FSRBDATE FSRDATR VSRDATE
but new corresponding SAS DATE variables are now created
with DATE9. format (prints 29JAN2012) for prettiness and
so they can be directly subtracted for delta-days:
DSRDATED FSRDLMD FSRDLUD FSRBDATD FSRDATRD VSRDATED
These date variables were never kept; they are now kept
and are now SAS Date Variables with DATE9. format.
WFSRDATR WFSRDATS WFSRDATE
Variable FSRDATE is always missing; it was sometimes
missing and sometimes 0 (which printed 01JAN1960).
-Datasets HSMFSRTP and HSMWWVOL had no observations so
they have not been validated.
Thanks to Randall R. Schlueter, First Data Corporation, USA.
Change 30.005 If you used UTILBLDP to create your BUILDPDB code and
UTILBLDP you used the MXGINCL parameter to include members that
BLDSMPDB were not in the default list, they were ignored. Now
Jan 29, 2012 they will not be ignored. They can alternatively be in
the INCLAFTR= parameter (where they wouldn't have been
ignored). When BLDSMPDB used the output of UTILBLDP as
as the source of the BUILDPDB code, it didn't use the
AUTOINC= parameter, but now it does. With this change
members can be included after the BUILDPDB step from one
one of these three parameters:
UTILBLDP - MXGINCL or INCLAFTR
BLDSMPDB - AUTOINC
But, if the same member appears in more than one it will
be executed more than once.
-MXGINCL should primarily be used to remove these members
that are automatically included:
ASUMUOW ASUMCICX ASUM70PR ASUMCACH ASUMTAPE
ASUMTMNT ASUMTALO ASUMDBAA ASUMDBSS
One or more can be removed if you choose. The same is
true of the AUTOINC parameter in BLDSMPDB, but when you
build the BUILDPDB code with UTILBLDP, that parameter is
not used.
Thanks to Peter Farrell, Commerce Bank of Kansas, USA.
Change 30.004 Some FICON-related variables values were wrong in TYPE73.
VMAC73 RMF documentation implied that DURATM should be used for
Jan 27, 2012 the interval duration, but the Channel Path Measurement
Interval SMF73PTI should have been used, and subtraction
from EOC and ETC were also wrong. Fortunately, the input
variables to these calculated variables are in dataset
TYPE73 so they can be recalculated with this SAS code:
CHFRATE=SMF73EOC/SMF73PTI;
IF SMF73EOC GT 0 THEN CHFACTV=SMF73EOS/SMF73EOC;
ELSE SMF73EOC=.;
CHFDFER=SMF73EOD/SMF73PTI;
CHFXRATE=SMF73ETC/DURATM;
IF SMF73ETC GT 0 THEN CHFXACTV=SMF73ETS/SMF73ETC;
ELSE SMF73ETC=.;
CHFXDFER=SMF73ETD/SMF73PTI;
without rebuilding the TYPE73 dataset from SMF records.
And the RMF documentation will (hopefully) be revised.
Thanks to Steve Olenik, IBM System z Processor Performance, USA.
Change 30.003 Spurious XAM INVALID CPU RECORD messages were due to a
VMACXAM mislocated SKIP=0; statement if SEGLEN=100. This MXG
Jan 27, 2012 error caused XAMCPUBY to have only one observation.
Thanks to Robert Obee, IMSHealth, USA.
Change 30.002 Change 29.238 typo in line 250:
VMACM204 IF ID= _M204LOG OR _IDM204L THEN DO;
Jan 27, 2012 was corrected to
IF ID= _M204LOG OR ID= _IDM204L THEN DO;
So that the correct Model 204 dataset was output.
Thanks to Steve Bagshaw, Marks & Spencer, ENGLAND.
Change 30.001 MXG Format MGD319F had reversed decoding the Encryption
FORMATS type. The correct values are: '00'X:DES, '40'X:AES.
VMAC102 -Variable QW0319UR is created from first bit of QW0319FL,
Jan 25, 2012 QW0319FLL is now used for the input of QW0319FL (so that
any new bits are available), and QW0319FL will be either
'00'X or '40'X (unless IBM changes its definition).
Thanks to Jason Bierman, Great Lakes Educational Loan Services, USA.
LASTCHANGE: Version 30.